Update BIND to version 9.6.1rc1. This version has better performance and

lots of new features compared to 9.4.x, including:

	Full NSEC3 support
	Automatic zone re-signing
	New update-policy methods tcp-self and 6to4-self
	DHCID support.
	More detailed statistics counters including those supported in BIND 8.
	Faster ACL processing.
	Efficient LRU cache-cleaning mechanism.
	NSID support.

1216 files changed, 58176 insertions, 230497 deletions

diff --git a/contrib/bind9/CHANGES b/contrib/bind9/CHANGES
index 8d1f22b..4f55ca2 100644
--- a/contrib/bind9/CHANGES
+++ b/contrib/bind9/CHANGES
@@ -1,18 +1,258 @@
-	--- 9.4.3-P2 released ---
+
+	--- 9.6.1rc1 released ---
+
+2599.	[bug]		Address rapid memory growth when validation fails.
+			[RT #19654]
+
+2597.	[bug]		Handle a validation failure with a insecure delegation
+			from a NSEC3 signed master/slave zone.  [RT #19464]
+
+2596.	[bug]		Stale tree nodes of cache/dynamic rbtdb could stay
+			long, leading to inefficient memory usage or rejecting
+			newer cache entries in the worst case. [RT #19563]
+
+2595.	[bug]		Fix unknown extended rcodes in dig. [RT #19625]
+
+2592.	[bug]		Treat "any" as a type in nsupdate. [RT #19455]
+
+2591.	[bug]		named could die when processing a update in
+			removed_orphaned_ds(). [RT #19507]
+
+2588.	[bug]		SO_REUSEADDR could be set unconditionally after failure
+			of bind(2) call.  This should be rare and mostly
+			harmless, but may cause interference with other
+			processes that happen to use the same port. [RT #19642]
+
+2586.	[bug]		Missing cleanup of SIG rdataset in searching a DLZ DB
+			or SDB. [RT #19577]
+
+2585.	[bug]		Uninitialized socket name could be referenced via a
+			statistics channel, triggering an assertion failure in
+			XML rendering. [RT #19427]
+
+2584.	[bug]		alpha: gcc optimization could break atomic operations.
+			[RT #19227]
+
+2583.	[port]		netbsd: provide a control to not add the compile
+			date to the version string, -DNO_VERSION_DATE.
+
+2582.	[bug]		Don't emit warning log message when we attempt to
+			remove non-existant journal. [RT #19516]
 
 2579.	[bug]		DNSSEC lookaside validation failed to handle unknown
 			algorithms. [RT #19479]
 
-	--- 9.4.3-P1 released ---
+2578.	[bug]		Changed default sig-signing-type to 65534, because
+			65535 turns out to be reserved.  [RT #19477]
+
+2499.	[port]		solaris: lib/lwres/getaddrinfo.c namespace clash.
+			[RT #18837]
+
+	--- 9.6.1b1 released ---
+
+2577.	[doc]		Clarified some statistics counters. [RT #19454]
+
+2576.	[bug]		NSEC record were not being correctly signed when
+			a zone transitions from insecure to secure.
+			Handle such incorrectly signed zones. [RT #19114]
+
+2574.	[doc]		Document nsupdate -g and -o. [RT #19351]
+
+2573.	[bug]		Replacing a non-CNAME record with a CNAME record in a
+			single transaction in a signed zone failed. [RT #19397]
+
+2568.	[bug]		Report when the write to indicate a otherwise
+			successful start fails. [RT #19360]
+
+2567.	[bug]		dst__privstruct_writefile() could miss write errors.
+			write_public_key() could miss write errors.
+			dnssec-dsfromkey could miss write errors.
+			[RT #19360]
+
+2564.	[bug]		Only take EDNS fallback steps when processing timeouts.
+			[RT #19405]
+
+2563.	[bug]		Dig could leak a socket causing it to wait forever
+			to exit. [RT #19359]
+
+2562.	[doc]		ARM: miscellaneous improvements, reorganization,
+			and some new content.
+
+2561.	[doc]		Add isc-config.sh(1) man page. [RT #16378]
+
+2560.	[bug]		Add #include <config.h> to iptable.c. [RT #18258]
+
+2559.	[bug]		dnssec-dsfromkey could compute bad DS records when
+			reading from a K* files.  [RT #19357]
+
+2557.	[cleanup]	PCI compliance:
+			* new libisc log module file
+			* isc_dir_chroot() now also changes the working
+			  directory to "/".
+			* additional INSISTs
+			* additional logging when files can't be removed.
+
+2556.	[port]		Solaris: mkdir(2) on tmpfs filesystems does not do the
+			error checks in the correct order resulting in the
+			wrong error code sometimes being returned. [RT #19249]
+			
+2554.	[bug]		Validation of uppercase queries from NSEC3 zones could
+			fail. [RT #19297]
+
+2553.	[bug]		Reference leak on DNSSEC validation errors. [RT #19291]
+
+2552.	[bug]		zero-no-soa-ttl-cache was not being honoured.
+			[RT #19340]
+
+2551.	[bug]		Potential Reference leak on return. [RT #19341]
+
+2550.	[bug]		Check --with-openssl=<path> finds <openssl/opensslv.h>.
+			[RT #19343]
+
+2549.	[port]		linux: define NR_OPEN if not currently defined.
+			[RT #19344]
+
+2548.	[bug]		Install iterated_hash.h. [RT #19335]
+
+2547.	[bug]		openssl_link.c:mem_realloc() could reference an
+			out-of-range area of the source buffer.  New public
+			function isc_mem_reallocate() was introduced to address
+			this bug. [RT #19313]
+
+2545.	[doc]		ARM: Legal hostname checking (check-names) is
+			for SRV RDATA too. [RT #19304]
+
+2544.	[cleanup]	Removed unused structure members in adb.c. [RT #19225]
+
+2543.	[contrib]	Update contrib/zkt to version 0.98. [RT #19113]
+
+2542.	[doc]		Update the description of dig +adflag. [RT #19290]
+
+2541.	[bug]		Conditionally update dispatch manager statistics.
+			[RT #19247]
+
+2539.	[security]	Update the interaction between recursion, allow-query,
+			allow-query-cache and allow-recursion.  [RT #19198]
+
+2538.	[bug]		cache/ADB memory could grow over max-cache-size,
+			especially with threads and smaller max-cache-size
+			values. [RT #19240]
+
+2537.	[experimental]	Added more statistics counters including those on socket
+			I/O events and query RTT histograms. [RT #18802]
+
+2536.	[cleanup]	Silence some warnings when -Werror=format-security is
+			specified. [RT #19083]
+
+2535.	[bug]		dig +showsearh and +trace interacted badly. [RT #19091]
+
+2532.	[bug]		dig: check the question section of the response to
+			see if it matches the asked question. [RT #18495]
+
+2531.	[bug]		Change #2207 was incomplete. [RT #19098]
+
+2530.	[bug]		named failed to reject insecure to secure transitions
+			via UPDATE. [RT #19101]
+
+2529.	[cleanup]	Upgrade libtool to silence complaints from recent
+			version of autoconf. [RT #18657]
+
+2528.   [cleanup]       Silence spurious configure warning about
+                        --datarootdir [RT #19096]
+
+2527.	[bug]		named could reuse cache on reload with
+			enabling/disabling validation. [RT #19119]
+
+2525.	[experimental]	New logging category "query-errors" to provide detailed
+			internal information about query failures, especially
+			about server failures. [RT #19027]
+
+2524.	[port]		sunos: dnssec-signzone needs strtoul(). [RT #19129]
+
+2523.	[bug]		Random type rdata freed by dns_nsec_typepresent().
+			[RT #19112]
+
+2522.	[security]	Handle -1 from DSA_do_verify() and EVP_VerifyFinal().
+
+2521.	[bug]		Improve epoll cross compilation support. [RT #19047]
+
+2519.	[bug]		dig/host with -4 or -6 didn't work if more than two
+			nameserver addresses of the excluded address family
+			preceded in resolv.conf. [RT #19081]
+
+2517.	[bug]		dig +trace with -4 or -6 failed when it chose a
+			nameserver address of the excluded address.
+			[RT #18843]
+
+2516.	[bug]		glue sort for responses was performed even when not
+			needed. [RT #19039]
+
+2514.	[bug]		dig/host failed with -4 or -6 when resolv.conf contains
+			a nameserver of the excluded address family.
+			[RT #18848]
+
+2511.	[cleanup]	dns_rdata_tofmttext() add const to linebreak.
+			[RT #18885]
+
+2506.	[port]		solaris: Check at configure time if 
+			hack_shutup_pthreadonceinit is needed. [RT #19037]
+
+2505.	[port]		Treat amd64 similarly to x86_64 when determining
+			atomic operation support. [RT #19031]
+
+2503.	[port]		linux: improve compatibility with Linux Standard
+			Base. [RT #18793]
+
+2502.	[cleanup]	isc_radix: Improve compliance with coding style,
+			document function in <isc/radix.h>. [RT #18534]
+
+	--- 9.6.0 released ---
+
+2520.	[bug]		Update xml statistics version number to 2.0 as change
+			#2388 made the schema incompatible to the previous
+			version. [RT #19080]
+
+	--- 9.6.0rc2 released ---
+
+2515.	[port]		win32: build dnssec-dsfromkey and dnssec-keyfromlabel.
+			[RT #19063]
+
+2513	[bug]		Fix windows cli build. [RT #19062]
+
+2510.	[bug]		"dig +sigchase" could trigger REQUIRE failures.
+			[RT #19033]
+
+2509.	[bug]		Specifying a fixed query source port was broken.
+			[RT #19051]
+
+2504.	[bug]		Address race condition in the socket code. [RT #18899]
 
-2522.	[security]	Handle -1 from DSA_do_verify().
+	--- 9.6.0rc1 released ---
 
 2498.	[bug]		Removed a bogus function argument used with
 			ISC_SOCKET_USE_POLLWATCH: it could cause compiler
 			warning or crash named with the debug 1 level
 			of logging. [RT #18917]
 
-	--- 9.4.3 released ---
+2497.	[bug]		Don't add RRSIG bit to NSEC3 bit map for insecure
+			delegation.
+
+2496.	[bug]		Add sanity length checks to NSID option. [RT #18813]
+
+2495.	[bug]		Tighten RRSIG checks. [RT #18795]
+
+2494.	[bug]		isc/radix.h, dns/sdlz.h and dns/dlz.h were not being
+			installed. [RT #18826]
+
+2493.	[bug]		The linux capabilities code was not correctly cleaning
+			up after itself. [RT #18767]
+
+2492.	[func]		Rndc status now reports the number of cpus discovered
+			and the number of worker threads when running
+			multi-threaded. [RT #18273]
+
+2491.	[func]		Attempt to re-use a local port if we are already using
+			the port. [RT #18548]
 
 2490.	[port]		aix: work around a kernel bug where IPV6_RECVPKTINFO
 			is cleared when IPV6_V6ONLY is set. [RT #18785]
@@ -23,7 +263,58 @@
 			Define ISC_SOCKET_USE_POLLWATCH at build time to enable
 			this workaround. [RT #18870]
 
-	--- 9.4.3rc1 released ---
+2488.	[func]		Added a tool, dnssec-dsfromkey, to generate DS records
+			from keyset and .key files. [RT #18694]
+
+2487.	[bug]		Give TCP connections longer to complete. [RT #18675]
+
+2486.	[func]		The default locations for named.pid and lwresd.pid
+			are now /var/run/named/named.pid and
+			/var/run/lwresd/lwresd.pid respectively.
+
+			This allows the owner of the containing directory
+			to be set, for "named -u" support, and allows there
+			to be a permanent symbolic link in the path, for
+			"named -t" support.  [RT #18306]
+
+2485.	[bug]		Change update's the handling of obscured RRSIG
+			records.  Not all orphaned DS records were being
+			removed. [RT #18828]
+
+2484.	[bug]		It was possible to trigger a REQUIRE failure when
+			adding NSEC3 proofs to the response in
+			query_addwildcardproof().  [RT #18828]
+
+2483.	[port]		win32: chroot() is not supported. [RT #18805]
+
+2482.	[port]		libxml2: support versions 2.7.* in addition
+			to 2.6.*. [RT #18806]
+
+	--- 9.6.0b1 released ---
+
+2481.	[bug]		rbtdb.c:matchparams() failed to handle NSEC3 chain
+			collisions.  [RT #18812]
+
+2480.	[bug]		named could fail to emit all the required NSEC3
+			records.  [RT #18812]
+
+2479.	[bug]		xfrout:covers was not properly initialized. [RT #18801]
+
+2478.	[bug]		'addresses' could be used uninitialized in
+			configure_forward(). [RT #18800]
+	
+2477.	[bug]		dig: the global option to print the command line is
+			+cmd not print_cmd.  Update the output to reflect
+			this. [RT #17008]
+
+2476.	[doc]		ARM: improve documentation for max-journal-size and
+			ixfr-from-differences. [RT #15909] [RT #18541]
+
+2475.	[bug]		LRU cache cleanup under overmem condition could purge
+			particular entries more aggressively. [RT #17628]
+
+2474.	[bug]		ACL structures could be allocated with insufficient
+			space, causing an array overrun. [RT #18765]
 
 2473.	[port]		linux: raise the limit on open files to the possible
 			maximum value before spawning threads; 'files'
@@ -33,9 +324,12 @@
 2472.	[port]		linux: check the number of available cpu's before
 			calling chroot as it depends on "/proc". [RT #16923]
 
-2471.	[bug]		named-checkzone was not reporting missing manditory
+2471.	[bug]		named-checkzone was not reporting missing mandatory
 			glue when sibling checks were disabled. [RT #18768]
 
+2470.	[bug]		Elements of the isc_radix_node_t could be incorrectly
+			overwritten.  [RT# 18719]
+
 2469.	[port]		solaris: Work around Solaris's select() limitations.
 			[RT #18769]
 
@@ -50,10 +344,14 @@
 2465.	[bug]		Adb's handling of lame addresses was different
 			for IPv4 and IPv6. [RT #18738]
 
+2464.	[port]		linux: check that a capability is present before
+			trying to set it. [RT #18135]
+
 2463.   [port]          linux: POSIX doesn't include the IPv6 Advanced Socket
 			API and glibc hides parts of the IPv6 Advanced Socket
 			API as a result.  This is stupid as it breaks how the
-			two halves (Basic and Advanced) of the IPv6 Socket API				were designed to be used but we have to live with it.
+			two halves (Basic and Advanced) of the IPv6 Socket API
+			were designed to be used but we have to live with it.
 			Define _GNU_SOURCE to pull in the IPv6 Advanced Socket
 			API. [RT #18388]
 
@@ -62,17 +360,48 @@
 
 2461.	[port]		sunos: Change #2363 was not complete. [RT #17513]
 
+	--- 9.6.0a1 released ---
+
+2460.	[bug]		Don't call dns_db_getnsec3parameters() on the cache.
+			[RT #18697]
+
+2459.	[contrib]	Import dnssec-zkt to contrib/zkt. [RT #18448]
+
 2458.	[doc]		ARM: update and correction for max-cache-size.
 			[RT #18294]
 
-2455.	[bug]		Stop metadata being transfered via axfr/ixfr.
+2457.	[tuning]	max-cache-size is reverted to 0, the previous
+			default.  It should be safe because expired cache
+			entries are also purged. [RT #18684]
+
+2456.	[bug]		In ACLs, ::/0 and 0.0.0.0/0 would both match any
+			address, regardless of family.  They now correctly
+			distinguish IPv4 from IPv6.  [RT #18559]
+                        
+2455.	[bug]		Stop metadata being transferred via axfr/ixfr.
 			[RT #18639]
 
+2454.	[func]		nsupdate: you can now set a default ttl. [RT #18317]
+
 2453.	[bug]		Remove NULL pointer dereference in dns_journal_print().
 			[RT #18316]
 
-2449.	[bug]		libbind: Out of bounds reference in dns_ho.c:addrsort.
-			[RT #18044]
+2452.	[func]		Improve bin/test/journalprint. [RT #18316]
+
+2451.	[port]		solaris: handle runtime linking better. [RT #18356]
+
+2450.	[doc]		Fix lwresd docbook problem for manual page.
+			[RT #18672]
+
+2449.	[placeholder]
+
+2448.	[func]		Add NSEC3 support. [RT #15452]
+
+2447.	[cleanup]	libbind has been split out as a separate product.
+
+2446.	[func]		Add a new log message about build options on startup.
+			A new command-line option '-V' for named is also
+			provided to show this information. [RT# 18645]
 
 2445.	[doc]		ARM out-of-date on empty reverse zones (list includes
 			RFC1918 address, but these are not yet compiled in).
@@ -81,31 +410,46 @@
 2444.	[port]		Linux, FreeBSD, AIX: Turn off path mtu discovery
 			(clear DF) for UDP responses and requests.
 
-	--- 9.4.3b3 released ---
-
 2443.	[bug]		win32: UDP connect() would not generate an event,
 			and so connected UDP sockets would never clean up.
 			Fix this by doing an immediate WSAConnect() rather
 			than an io completion port type for UDP.
 
-2438.	[bug]		Timeouts could be logged incorrectly under win32.
-			[RT #18617]
+2442.	[bug]		A lock could be destroyed twice. [RT# 18626]
+
+2441.   [bug]           isc_radix_insert() could copy radix tree nodes
+			incompletely. [RT #18573]
+
+2440.   [bug]		named-checkconf used an incorrect test to determine
+			if an ACL was set to none.
+
+2439.   [bug]		Potential NULL dereference in dns_acl_isanyornone().
+			[RT #18559]
+
+2438.   [bug]		Timeouts could be logged incorrectly under win32.
 
 2437.	[bug]		Sockets could be closed too early, leading to
 			inconsistent states in the socket module. [RT #18298]
 
 2436.	[security]	win32: UDP client handler can be shutdown. [RT #18576]
 
+2435.	[bug]		Fixed an ACL memory leak affecting win32.
+
+2434.	[bug]		Fixed a minor error-reporting bug in
+			lib/isc/win32/socket.c.
+
 2433.	[tuning]	Set initial timeout to 800ms.
 
-2432.	[bug]		More Windows socket handling improvements.  Stop
+2432.   [bug]		More Windows socket handling improvements.  Stop
 			using I/O events and use IO Completion Ports
 			throughout.  Rewrite the receive path logic to make
 			it easier to support multiple simultaneous
-			requestrs in the future.  Add stricter consistency
+			requesters in the future.  Add stricter consistency
 			checking as a compile-time option (define
 			ISC_SOCKET_CONSISTENCY_CHECKS; defaults to off).
 
+2431.	[bug]		Acl processing could leak memory. [RT #18323]
+
 2430.	[bug]		win32: isc_interval_set() could round down to
 			zero if the input was less than NS_INTERVAL
 			nanoseconds.  Round up instead. [RT #18549]
@@ -113,8 +457,14 @@
 2429.	[doc]		nsupdate should be in section 1 of the man pages.
 			[RT #18283]
 
+2428.	[bug]		dns_iptable_merge() mishandled merges of negative
+			tables. [RT #18409]
+
+2427.	[func]		Treat DNSKEY queries as if "minimal-response yes;"
+			was set. [RT #18528]
+
 2426.	[bug]		libbind: inet_net_pton() can sometimes return the
-			wrong value if excessively large netmasks are
+			wrong value if excessively large net masks are
 			supplied. [RT #18512]
 
 2425.	[bug]		named didn't detect unavailable query source addresses
@@ -125,6 +475,12 @@
 			epoll and /dev/poll to be selected at compile
 			time. [RT #18277]
 			
+2423.   [security]	Randomize server selection on queries, so as to
+                        make forgery a little more difficult.  Instead of
+                        always preferring the server with the lowest RTT,
+                        pick a server with RTT within the same 128
+                        millisecond band.  [RT #18441]
+
 2422.	[bug]		Handle the special return value of a empty node as
 			if it was a NXRRSET in the validator. [RT #18447]
 
@@ -133,13 +489,20 @@
 			Use caution: this option may not work for some
 			operating systems without rebuilding named.
 
-2420.	[bug]		Windows socket handling cleanup.  Let the io
-			completion event send out cancelled read/write
-			done events, which keeps us from writing to memeory
+2420.   [bug]		Windows socket handling cleanup.  Let the io
+			completion event send out canceled read/write
+			done events, which keeps us from writing to memory
 			we no longer have ownership of.  Add debugging
 			socket_log() function.  Rework TCP socket handling
 			to not leak sockets.
 
+2419.	[cleanup]	Document that isc_socket_create() and isc_socket_open()
+			should not be used for isc_sockettype_fdwatch sockets.
+			[RT #18521]
+
+2418.	[bug]		AXFR request on a DLZ could trigger a REQUIRE failure
+			[RT #18430]
+
 2417.	[bug]		Connecting UDP sockets for outgoing queries could
 			unexpectedly fail with an 'address already in use'
 			error. [RT #18411]
@@ -147,26 +510,42 @@
 2416.	[func]		Log file descriptors that cause exceeding the
 			internal maximum. [RT #18460]
 
+2415.	[bug]		'rndc dumpdb' could trigger various assertion failures
+			in rbtdb.c. [RT #18455]
+
 2414.	[bug]		A masterdump context held the database lock too long,
 			causing various troubles such as dead lock and
 			recursive lock acquisition. [RT #18311, #18456]
 
 2413.	[bug]		Fixed an unreachable code path in socket.c. [RT #18442]
 
-2412.	[bug]		win32: address a resourse leak. [RT #18374]
+2412.	[bug]		win32: address a resource leak. [RT #18374]
 
 2411.	[bug]		Allow using a larger number of sockets than FD_SETSIZE
 			for select().  To enable this, set ISC_SOCKET_MAXSOCKETS
 			at compilation time.  [RT #18433]
 
+			Note: with changes #2469 and #2421 above, there is no
+			need to tweak ISC_SOCKET_MAXSOCKETS at compilation time
+			any more.
+
 2410.	[bug]		Correctly delete m_versionInfo. [RT #18432]
 
+2409.	[bug]		Only log that we disabled EDNS processing if we were
+			subsequently successful.  [RT #18029]
+
 2408.	[bug]		A duplicate TCP dispatch event could be sent, which
 			could then trigger an assertion failure in
 			resquery_response().  [RT #18275]
 
 2407.	[port]		hpux: test for sys/dyntune.h. [RT #18421]
 
+2406.	[placeholder]
+
+2405.   [cleanup]       The default value for dnssec-validation was changed to
+                        "yes" in 9.5.0-P1 and all subsequent releases; this
+                        was inadvertently omitted from CHANGES at the time.
+
 2404.	[port]		hpux: files unlimited support.
 
 2403.	[bug]		TSIG context leak. [RT #18341]
@@ -176,13 +555,17 @@
 2401.	[bug]		Expect to get E[MN]FILE errno internal_accept()
 			(from accept() or fcntl() system calls). [RT #18358]
 
-2399.	[bug]		Abort timeout queries to reduce the number of open
-			UDP sockets. [RT #18367]
+2400.	[bug]		Log if kqueue()/epoll_create()/open(/dev/poll) fails.
+			[RT #18297]
+
+2399.	[placeholder]
 
 2398.	[bug]           Improve file descriptor management.  New,
 			temporary, named.conf option reserved-sockets,
 			default 512. [RT #18344]
 
+2397.	[bug]		gssapi_functions had too many elements. [RT #18355]
+
 2396.	[bug]		Don't set SO_REUSEADDR for randomized ports.
 			[RT #18336]
 
@@ -193,35 +576,42 @@
 			open files to 'unlimited' as described in the
 			documentation. [RT #18331]
 
+2393.	[bug]		nested acls containing keys could trigger an
+			assertion in acl.c. [RT #18166]
+
 2392.	[bug]		remove 'grep -q' from acl test script, some platforms
 			don't support it. [RT #18253]
 
-2391	[port]		hpux: cover additional recvmsg() error codes.
+2391.	[port]		hpux: cover additional recvmsg() error codes.
 			[RT #18301]
 
-2390	[bug]		dispatch.c could make a false warning on 'odd socket'.
+2390.	[bug]		dispatch.c could make a false warning on 'odd socket'.
 			[RT #18301].
 
-2389	[bug]		Move the "working directory writable" check to after
+2389.	[bug]		Move the "working directory writable" check to after
 			the ns_os_changeuser() call. [RT #18326]
 
+2388.	[bug]		Avoid using tables for layout purposes in
+			statistics XSL [RT #18159].
+
+2387.	[bug]		Silence compiler warnings in lib/isc/radix.c.
+			[RT #18147] [RT #18258]
+
 2386.	[func]		Add warning about too small 'open files' limit.
 			[RT #18269]
 
-	--- 9.4.3b2 released ---
-
 2385.	[bug]		A condition variable in socket.c could leak in
 			rare error handling [RT #17968].
 
-2384.	[security]	Additional support for query port randomization (change
-			#2375) including performance improvement and port range
-			specification.  [RT #17949, #18098]
+2384.	[security]	Fully randomize UDP query ports to improve
+			forgery resilience. [RT #17949, #18098]
 
 2383.	[bug]		named could double queries when they resulted in
 			SERVFAIL due to overkilling EDNS0 failure detection.
 			[RT #18182]
 
-2382.	[doc]		Add descriptions of IPSECKEY, SPF and SSHFP to ARM.
+2382.	[doc]		Add descriptions of DHCID, IPSECKEY, SPF and SSHFP
+			to ARM.
 
 2381.	[port]		dlz/mysql: support multiple install layouts for
 			mysql.  <prefix>/include/{,mysql/}mysql.h and
@@ -235,41 +625,104 @@
 2379.	[contrib]	queryperf/gen-data-queryperf.py: removed redundant
 			TLDs and supported RRs with TTLs [RT #17972]
 
+2378.	[bug]		gssapi_functions{} had a redundant member in BIND 9.5.
+			[RT #18169]
+
 2377.	[bug]		Address race condition in dnssec-signzone. [RT #18142]
 
 2376.	[bug]		Change #2144 was not complete.
 
-2375.	[security]	Fully randomize UDP query ports to improve
-			forgery resilience. [RT #17949]
+2375.	[placeholder]
+
+2374.	[bug]		"blackhole" ACLs could cause named to segfault due
+			to some uninitialized memory. [RT #18095]
+
+2373.	[bug]		Default values of zone ACLs were re-parsed each time a
+			new zone was configured, causing an overconsumption
+			of memory. [RT #18092]
+
+2372.	[bug]		Fixed incorrect TAG_HMACSHA256_BITS value [RT #18047]
 
-2372.	[bug]		fixed incorrect TAG_HMACSHA256_BITS value [RT #18047]
+2371.	[doc]		Add +nsid option to dig man page. [RT #18039]
+
+2370.	[bug]		"rndc freeze" could trigger an assertion in named
+			when called on a nonexistent zone. [RT #18050]
 
 2369.	[bug]		libbind: Array bounds overrun on read in bitncmp().
 			[RT #18054]
 
+2368.	[port]		Linux: use libcap for capability management if
+			possible. [RT# 18026]
+
+2367.	[bug]		Improve counting of dns_resstatscounter_retry
+			[RT #18030]
+
+2366.	[bug]		Adb shutdown race. [RT #18021]
+
+2365.	[bug]		Fix a bug that caused dns_acl_isany() to return
+			spurious results. [RT #18000]
+
 2364.	[bug]		named could trigger a assertion when serving a
 			malformed signed zone. [RT #17828]
 
 2363.	[port]		sunos: pre-set "lt_cv_sys_max_cmd_len=4096;".
 			[RT #17513]
 
+2362.   [cleanup]	Make "rrset-order fixed" a compile-time option.
+			settable by "./configure --enable-fixed-rrset".
+			Disabled by default. [RT #17977]
+
 2361.	[bug]		"recursion" statistics counter could be counted
 			multiple times for a single query.  [RT #17990]
 
-	--- 9.4.3b1 released ---
+2360.	[bug]		Fix a condition where we release a database version
+			(which may acquire a lock) while holding the lock.
+
+2359.	[bug]		Fix NSID bug. [RT #17942]
 
 2358.	[doc]		Update host's default query description. [RT #17934]
 
+2357.	[port]		Don't use OpenSSL's engine support in versions before
+			OpenSSL 0.9.7f. [RT #17922]
+
 2356.	[bug]		Built in mutex profiler was not scalable enough.
 			[RT #17436]
 
-2353.	[func]		libbind: nsid support. [RT #17091]
+2355.	[func]		Extend the number statistics counters available.
+			[RT #17590]
+
+2354.	[bug]		Failed to initialize some rdatasetheader_t elements.
+			[RT #17927]
+
+2353.	[func]		Add support for Name Server ID (RFC 5001).
+			'dig +nsid' requests NSID from server.
+			'request-nsid yes;' causes recursive server to send
+			NSID requests to upstream servers.  Server responds
+			to NSID requests with the string configured by
+			'server-id' option.  [RT #17091]
+
+2352.	[bug]		Various GSS_API fixups. [RT #17729]
+
+2351.	[bug]		convertxsl.pl generated very long lines. [RT #17906]
 
 2350.	[port]		win32: IPv6 support. [RT #17797]
 
+2349.	[func]		Provide incremental re-signing support for secure
+			dynamic zones. [RT #1091]
+
+2348.	[func]		Use the EVP interface to OpenSSL. Add PKCS#11 support.
+			Documentation is in the new README.pkcs11 file.
+			New tool, dnssec-keyfromlabel, which takes the
+			label of a key pair in a HSM and constructs a DNS
+			key pair for use by named and dnssec-signzone.
+			[RT #16844]
+
 2347.	[bug]		Delete now traverses the RB tree in the canonical
 			order. [RT #17451]
 
+2346.	[func]		Memory statistics now cover all active memory contexts
+			in increased detail. [RT #17580]
+
 2345.	[bug]		named-checkconf failed to detect when forwarders
 			were set at both the options/view level and in
 			a root zone. [RT #17671]
@@ -280,6 +733,8 @@
 2343.	[bug]		(Seemingly) duplicate IPv6 entries could be
 			created in ADB. [RT #17837]
 
+2342.	[func]		Use getifaddrs() if available under Linux. [RT #17224]
+
 2341.	[bug]		libbind: add missing -I../include for off source
 			tree builds. [RT #17606]
 
@@ -292,12 +747,16 @@
 
 2337.	[bug]		BUILD_LDFLAGS was not being correctly set.  [RT #17614]
 
-2335.	[port]		sunos:  libbind and *printf() support for long long.
+2336.	[func]		If "named -6" is specified then listen on all IPv6
+			interfaces if there are not listen-on-v6 clauses in
+			named.conf.  [RT #17581]
+
+2335.	[port]		sunos:  libbind and *printf() support for long long. 
 			[RT #17513]
 
 2334.	[bug]		Bad REQUIRES in fromstruct_in_naptr(),  off by one
 			bug in fromstruct_txt(). [RT #17609]
-
+			
 2333.	[bug]		Fix off by one error in isc_time_nowplusinterval().
 			[RT #17608]
 
@@ -321,21 +780,40 @@
 			J.ROOT-SERVERS.NET, K.ROOT-SERVERS.NET and
 			M.ROOT-SERVERS.NET.
 
+2327.	[bug]		It was possible to dereference a NULL pointer in
+			rbtdb.c.  Implement dead node processing in zones as
+			we do for caches. [RT #17312]
+
 2326.	[bug]		It was possible to trigger a INSIST in the acache
 			processing.
 
 2325.	[port]		Linux: use capset() function if available. [RT #17557]
 
+2324.	[bug]		Fix IPv6 matching against "any;". [RT #17533]
+
 2323.	[port]		tru64: namespace clash. [RT #17547]
 
 2322.	[port]		MacOS: work around the limitation of setrlimit()
 			for RLIMIT_NOFILE. [RT #17526]
 
-2319.	[bug]		Silence Coverity warnings in
+2321.	[placeholder]
+
+2320.	[func]		Make statistics counters thread-safe for platforms
+			that support certain atomic operations. [RT #17466]
+
+2319.	[bug]		Silence Coverity warnings in 
 			lib/dns/rdata/in_1/apl_42.c. [RT #17469]
 
 2318.	[port]		sunos fixes for libbind.  [RT #17514]
 
+2317.	[bug]		"make distclean" removed bind9.xsl.h. [RT #17518]
+
+2316.	[port]		Missing #include <isc/print.h> in lib/dns/gssapictx.c.
+			[RT #17513]
+
+2315.   [bug]           Used incorrect address family for mapped IPv4
+                        addresses in acl.c. [RT #17519]
+
 2314.	[bug]		Uninitialized memory use on error path in
 			bin/named/lwdnoop.c.  [RT #17476]
 
@@ -345,11 +823,15 @@
 2312.	[cleanup]	Silence Coverity warning in lib/isc/unix/socket.c.
 			[RT #17458]
 
-2311.	[func]		Update ACL regression test. [RT #17462]
+2311.   [bug]           IPv6 addresses could match IPv4 ACL entries and
+                        vice versa. [RT #17462]
 
 2310.	[bug]		dig, host, nslookup: flush stdout before emitting
 			debug/fatal messages.  [RT #17501]
 
+2309.   [cleanup]       Fix Coverity warnings in lib/dns/acl.c and iptable.c.
+                        [RT #17455]
+
 2308.	[cleanup]	Silence Coverity warning in bin/named/controlconf.c.
 			[RT #17495]
 
@@ -371,7 +853,7 @@
 2301.	[bug]		Remove resource leak and fix error messages in
 			bin/tests/system/lwresd/lwtest.c. [RT #17474]
 
-2300.	[bug]		Fixed failure to close open file in
+2300.	[bug]		Fixed failure to close open file in 
 			bin/tests/names/t_names.c. [RT #17473]
 
 2299.	[bug]		Remove unnecessary NULL check in
@@ -389,22 +871,39 @@
 2295.	[bug]		Silence static overrun error in bin/named/lwaddr.c.
 			[RT #17459]
 
+2294.	[func]		Allow the experimental statistics channels to have
+			multiple connections and ACL.
+			Note: the stats-server and stats-server-v6 options
+			available in the previous beta releases are replaced
+			with the generic statistics-channels statement.
+
 2293.	[func]		Add ACL regression test. [RT #17375]
 
 2292.	[bug]		Log if the working directory is not writable.
 			[RT #17312]
 
-2291.	[bug]		PR_SET_DUMPABLE may be set too late.  Also report
+2291.   [bug]           PR_SET_DUMPABLE may be set too late.  Also report
 			failure to set PR_SET_DUMPABLE. [RT #17312]
 
 2290.	[bug]		Let AD in the query signal that the client wants AD
 			set in the response. [RT #17301]
 
+2289.	[func]		named-checkzone now reports the out-of-zone CNAME
+			found. [RT #17309]
+
 2288.	[port]		win32: mark service as running when we have finished
 			loading.  [RT #17441]
 
 2287.	[bug]		Use 'volatile' if the compiler supports it. [RT #17413]
 
+2286.	[func]		Allow a TCP connection to be used as a weak
+			authentication method for reverse zones.
+			New update-policy methods tcp-self and 6to4-self.
+			[RT #17378]
+
+2285.	[func]		Test framework for client memory context management.
+			[RT #17377]
+
 2284.	[bug]		Memory leak in UPDATE prerequisite processing.
 			[RT #17377]
 
@@ -413,7 +912,15 @@
 			memory context rather than the clients memory
 			context. [RT #17377]
 
-2279.	[bug]		Use setsockopt(SO_NOSIGPIPE), when available,
+2282.	[bug]		Acl code fixups. [RT #17346] [RT #17374]
+
+2281.	[bug]		Attempts to use undefined acls were not being logged.
+			[RT #17307]
+
+2280.	[func]		Allow the experimental http server to be reached
+			over IPv6 as well as IPv4. [RT #17332]
+
+2279.   [bug]           Use setsockopt(SO_NOSIGPIPE), when available,
 			to protect applications from receiving spurious
 			SIGPIPE signals when using the resolver.
 
@@ -423,12 +930,21 @@
 2277.	[bug]		Empty zone names were not correctly being caught at
 			in the post parse checks. [RT #17357]
 
+2276.	[bug]		Install <dst/gssapi.h>.  [RT# 17359]
+
+2275.	[func]		Add support to dig to perform IXFR queries over UDP.
+			[RT #17235]
+
+2274.	[func]		Log zone transfer statistics. [RT #17336]
+
 2273.	[bug]		Adjust log level to WARNING when saving inconsistent
 			stub/slave master and journal files. [RT# 17279]
 
 2272.	[bug]		Handle illegal dnssec-lookaside trust-anchor names.
 			[RT #17262]
 
+2271.	[bug]		Fix a memory leak in http server code [RT #17100]
+
 2270.	[bug]		dns_db_closeversion() version->writer could be reset
 			before it is tested. [RT #17290]
 
@@ -437,6 +953,12 @@
 2268.	[bug]		0.IN-ADDR.ARPA was missing from the empty zones
 			list.
 
+	--- 9.5.0b1 released ---
+
+2267.   [bug]           Radix tree node_num value could be set incorrectly,
+                        causing positive ACL matches to look like negative
+                        ones.  [RT #17311]
+
 2266.	[bug]		client.c:get_clientmctx() returned the same mctx
 			once the pool of mctx's was filled. [RT #17218]
 
@@ -451,21 +973,14 @@
 2262.	[bug]		Error status from all but the last view could be
 			lost. [RT #17292]
 
-2260.	[bug]		Reported wrong clients-per-query when increasing the
-			value. [RT #17236]
-
-2247.	[doc]		Sort doc/misc/options. [RT #17067]
+2261.   [bug]           Fix memory leak with "any" and "none" ACLs [RT #17272]
 
-2246.	[bug]		Make the startup of test servers (ans.pl) more
-			robust. [RT #17147]
-
-	--- 9.4.2 released ---
+2260.	[bug]		Reported wrong clients-per-query when increasing the
+                        value. [RT #17236]
 
-	--- 9.4.2rc2 released ---
+2259.	[placeholder]
 
-2259.	[bug]		Reverse incorrect LIBINTERFACE bump of libisc
-			in 9.4.2rc1.  Applications built against 9.4.2rc1
-			will need to be rebuilt.
+	--- 9.5.0a7 released ---
 
 2258.	[bug]		Fallback from IXFR/TSIG to SOA/AXFR/TSIG broken.
 			[RT #17241]
@@ -483,20 +998,52 @@
 			intermediate values as timer->idle was reset by
 			isc_timer_touch(). [RT #17243]
 
-	--- 9.4.2rc1 released ---
+2253.	[func]	 	"max-cache-size" defaults to 32M.
+			"max-acache-size" defaults to 16M.
 
-2251.	[doc]		Update memstatistics-file documentation to reflect
-			reality. Note there is behaviour change for BIND 9.5.
-			[RT #17113]
+2252.   [bug]           Fixed errors in sortlist code [RT #17216]
 
-2249.	[bug]		Only set Authentic Data bit if client requested
-			DNSSEC, per RFC 3655 [RT #17175]
+2251.	[placeholder]
+
+2250.	[func]		New flag 'memstatistics' to state whether the
+			memory statistics file should be written or not.
+			Additionally named's -m option will cause the
+			statistics file to be written. [RT #17113]
+			
+2249.   [bug]           Only set Authentic Data bit if client requested
+                        DNSSEC, per RFC 3655 [RT #17175]
 
-2248.	[cleanup]	Fix several errors reported by Coverity. [RT #17160]
+2248.   [cleanup]       Fix several errors reported by Coverity. [RT #17160]
+
+2247.	[doc]		Sort doc/misc/options. [RT #17067]
+
+2246.	[bug]		Make the startup of test servers (ans.pl) more
+			robust. [RT #17147]
 
 2245.	[bug]		Validating lack of DS records at trust anchors wasn't
 			working. [RT #17151]
 
+2244.	[func]		Allow the check of nameserver names against the
+			SOA MNAME field to be disabled by specifying
+			'notify-to-soa yes;'.  [RT #17073]
+
+2243.	[func]		Configuration files without a newline at the end now
+			parse without error. [RT #17120]
+
+2242.	[bug]		nsupdate: GSS-TSIG support using the Heimdal Kerberos
+			library could require a source of random data.
+			[RT #17127]
+
+2241.	[func]		nsupdate: add a interactive 'help' command. [RT #17099]
+
+2240.	[bug]		Cleanup nsupdates GSS-TSIG support.  Convert
+			a number of INSIST()s into plain fatal() errors
+			which report the triggering result code.
+			The 'key' command wasn't disabling GSS-TSIG.
+			[RT #17099]
+
+2239.	[func]		Ship a pre built bin/named/bind9.xsl.h. [RT #17114]
+
 2238.	[bug]		It was possible to trigger a REQUIRE when a
 			validation was canceled. [RT #17106]
 
@@ -507,7 +1054,11 @@
 
 2235.	[bug]		<isc/atomic.h> was not being installed. [RT #17135]
 
-2234.	[port]		Correct some compiler warnings on SCO OSr5 [RT #17134]
+2234.   [port]          Correct some compiler warnings on SCO OSr5 [RT #17134]
+  
+2233.   [func]          Add support for O(1) ACL processing, based on
+                        radix tree code originally written by Kevin
+                        Brintnall. [RT #16288]
 
 2232.	[bug]		dns_adb_findaddrinfo() could fail and return
 			ISC_R_SUCCESS. [RT #17137]
@@ -518,34 +1069,44 @@
 2230.	[bug]		We could INSIST reading a corrupted journal.
 			[RT #17132]
 
+2229.	[bug]		Null pointer dereference on query pool creation
+			failure. [RT #17133]
+
 2228.	[contrib]	contrib: Change 2188 was incomplete.
 
 2227.	[cleanup]	Tidied up the FAQ. [RT #17121]
 
+2226.	[placeholder]
+
 2225.	[bug]		More support for systems with no IPv4 addresses.
-			[RT #17111]
+		        [RT #17111]
 
 2224.	[bug]		Defer journal compaction if a xfrin is in progress.
 			[RT #17119]
 
 2223.	[bug]		Make a new journal when compacting. [RT #17119]
 
+2222.	[func]		named-checkconf now checks server key references.
+		        [RT #17097]
+
 2221.	[bug]		Set the event result code to reflect the actual
-			record returned to caller when a cache update is
+			record turned to caller when a cache update is
 			rejected due to a more credible answer existing.
 			[RT #17017]
 
 2220.	[bug]		win32: Address a race condition in final shutdown of
 			the Windows socket code. [RT #17028]
-
+			
 2219.	[bug]		Apply zone consistency checks to additions, not
 			removals, when updating. [RT #17049]
 
 2218.	[bug]		Remove unnecessary REQUIRE from dns_validator_create().
 			[RT #16976]
 
+2217.	[func]		Adjust update log levels. [RT #17092]
+
 2216.	[cleanup]	Fix a number of errors reported by Coverity.
-			[RT #17094]
+		        [RT #17094]
 
 2215.	[bug]		Bad REQUIRE check isc_hmacsha1_verify(). [RT #17094]
 
@@ -559,6 +1120,9 @@
 2212.	[func]		'host -m' now causes memory statistics and active
 			memory to be printed at exit. [RT 17028]
 
+2211.	[func]		Update "dynamic update temporarily disabled" message.
+			[RT #17065]
+
 2210.	[bug]		Deleting class specific records via UPDATE could
 			fail.  [RT #17074]
 
@@ -572,7 +1136,7 @@
 2207.	[port]		Some implementations of getaddrinfo() fail to set
 			ai_canonname correctly. [RT #17061]
 
-	--- 9.4.2b1 released ---
+	--- 9.5.0a6 released ---
 
 2206.	[security]	"allow-query-cache" and "allow-recursion" now
 			cross inherit from each other.
@@ -588,15 +1152,21 @@
 			localhost;) is used.
 
 			[RT #16987]
-
+	
 2205.	[bug]		libbind: change #2119 broke thread support. [RT #16982]
 
+2204.	[bug]		"rndc flushanme name unknown-view" caused named
+			to crash. [RT #16984]
+
 2203.	[security]	Query id generation was cryptographically weak.
 			[RT # 16915]
 
 2202.	[security]	The default acls for allow-query-cache and
 			allow-recursion were not being applied. [RT #16960]
 
+2201.	[bug]		The build failed in a separate object directory.
+			[RT #16943]
+
 2200.	[bug]		The search for cached NSEC records was stopping to
 			early leading to excessive DLV queries. [RT #16930]
 
@@ -613,8 +1183,13 @@
 2196.	[port]		win32: yield processor while waiting for once to
 			to complete. [RT #16958]
 
+2195.	[func]		dnssec-keygen now defaults to nametype "ZONE"
+			when generating DNSKEYs. [RT #16954]
+
 2194.	[bug]		Close journal before calling 'done' in xfrin.c.
 
+	--- 9.5.0a5 released ---
+
 2193.	[port]		win32: BINDInstall.exe is now linked statically.
 			[RT #16906]
 
@@ -622,6 +1197,17 @@
 			Studio's redistributable dlls if building with
 			Visual Stdio 2005 or later.
 
+2191.	[func]		named-checkzone now allows dumping to stdout (-).
+			named-checkconf now has -h for help.
+			named-checkzone now has -h for help.
+			rndc now has -h for help.
+			Better handling of '-?' for usage summaries.
+			[RT #16707]
+
+2190.	[func]		Make fallback to plain DNS from EDNS due to timeouts
+			more visible.  New logging category "edns-disabled".
+			[RT #16871]
+
 2189.	[bug]		Handle socket() returning EINTR. [RT #15949]
 
 2188.	[contrib]	queryperf: autoconf changes to make the search for
@@ -637,6 +1223,9 @@
 2185.	[port]		sunos: libbind: check for ssize_t, memmove() and
 			memchr(). [RT #16463]
 
+2184.	[bug]		bind9.xsl.h didn't build out of the source tree.
+			[RT #16830]
+
 2183.	[bug]		dnssec-signzone didn't handle offline private keys
 			well.  [RT #16832]
 
@@ -649,6 +1238,9 @@
 2180.	[cleanup]	Remove bit test from 'compress_test' as they
 			are no longer needed. [RT #16497]
 
+2179.	[func]		'rndc command zone' will now find 'zone' if it is
+			unique to all the views. [RT #16821]
+
 2178.	[bug]		'rndc reload' of a slave or stub zone resulted in
 			a reference leak. [RT #16867]
 
@@ -667,6 +1259,11 @@
 2173.	[port]		win32: When compiling with MSVS 2005 SP1 we also
 			need to ship Microsoft.VC80.MFCLOC.
 
+	--- 9.5.0a4 released ---
+
+2172.	[bug]		query_addsoa() was being called with a non zone db.
+			[RT #16834]
+
 2171.	[bug]		Handle breaks in DNSSEC trust chains where the parent
 			servers are not DS aware (DS queries to the parent
 			return a referral to the child).
@@ -683,27 +1280,43 @@
 2167.	[bug]		When re-using a automatic zone named failed to
 			attach it to the new view. [RT #16786]
 
+	--- 9.5.0a3 released ---
+
 2166.	[bug]		When running in batch mode, dig could misinterpret
 			a server address as a name to be looked up, causing
 			unexpected output. [RT #16743]
 
-2164.	[bug]		The code to determine how named-checkzone /
+2165.	[func]		Allow the destination address of a query to determine
+			if we will answer the query or recurse.
+			allow-query-on, allow-recursion-on and
+			allow-query-cache-on. [RT #16291]
+
+2164.	[bug]		The code to determine how named-checkzone / 
 			named-compilezone was called failed under windows.
 			[RT #16764]
 
+2163.	[bug]		If only one of query-source and query-source-v6
+			specified a port the query pools code broke (change
+			2129).  [RT #16768]
+
 2162.	[func]		Allow "rrset-order fixed" to be disabled at compile
 			time. [RT #16665]
 
-2161.	[bug]		'rndc flush' could report a false success. [RT #16698]
+2161.	[bug]		Fix which log messages are emitted for 'rndc flush'.
+			[RT #16698]
 
 2160.	[bug]		libisc wasn't handling NULL ifa_addr pointers returned
 			from getifaddrs(). [RT #16708]
 
+	--- 9.5.0a2 released ---
+
 2159.	[bug]		Array bounds overrun in acache processing. [RT #16710]
 
 2158.	[bug]		ns_client_isself() failed to initialize key
 			leading to a REQUIRE failure. [RT #16688]
 
+2157.	[func]		dns_db_transfernode() created. [RT #16685]
+
 2156.	[bug]		Fix node reference leaks in lookup.c:lookup_find(),
 			resolver.c:validated() and resolver.c:cache_name().
 			Fix a memory leak in rbtdb.c:free_noqname().
@@ -713,6 +1326,9 @@
 2155.	[contrib]	SQLite sdb module from jaboydjr@netwalk.com.
 			[RT #16694]
 
+2154.	[func]		Scoped (e.g. IPv6 link-local) addresses may now be
+			matched in acls by omitting the scope. [RT #16599]
+
 2153.	[bug]		nsupdate could leak memory. [RT #16691]
 
 2152.	[cleanup]	Use sizeof(buf) instead of fixed number in
@@ -729,6 +1345,8 @@
 			if there were still active memory contexts.
 			[RT #16672]
 
+2148.	[func]		Add positive logging for rndc commands. [RT #14623]
+
 2147.	[bug]		libbind: remove potential buffer overflow from
 			hmac_link.c. [RT #16437]
 
@@ -757,17 +1375,6 @@
 2139.	[bug]		dns_view_find() was being called with wrong type
 			in adb.c. [RT #16670]
 
-2119.	[compat]	libbind: allow res_init() to succeed enough to
-			return the default domain even if it was unable
-			to allocate memory.
-
-	--- 9.4.1 released ---
-
-2172.	[bug]		query_addsoa() was being called with a non zone db.
-			[RT #16834]
-
-	--- 9.4.0 released ---
-
 2138.	[bug]		Lock order reversal in resolver.c. [RT #16653]
 
 2137.	[port]		Mips little endian and/or mips 64 bit are now
@@ -778,6 +1385,8 @@
 
 2135.	[bug]		Uninitialized rdataset in sdlz.c. [RT# 16656]
 
+2134.	[func]		Additional statistics support. [RT #16666]
+
 2133.	[port]		powerpc:  Support both IBM and MacOS Power PC
 			assembler syntaxes. [RT #16647]
 
@@ -786,9 +1395,13 @@
 
 2131.	[contrib]	dlz/mysql: AXFR was broken. [RT #16630]
 
-2128.	[doc]		xsltproc --nonet, update DTD versions.  [RT #16635]
+2130.	[func]		Log if CD or DO were set. [RT #16640]
 
-	--- 9.4.0rc2 released ---
+2129.	[func]		Provide a pool of UDP sockets for queries to be
+			made over. See use-queryport-pool, queryport-pool-ports
+			and queryport-pool-updateinterval.  [RT #16415]
+
+2128.	[doc]		xsltproc --nonet, update DTD versions.  [RT #16635]
 
 2127.	[port]		Improved OpenSSL 0.9.8 support. [RT #16563]
 
@@ -800,9 +1413,22 @@
 2124.	[security]	It was possible to dereference a freed fetch
 			context. [RT #16584]
 
+	--- 9.5.0a1 released ---
+
+2123.	[func]		Use Doxygen to generate internal documentation.
+			[RT #11398]
+
+2122.	[func]		Experimental http server and statistics support
+			for named via xml.
+
+2121.	[func]		Add a 10 slot dead masters cache (LRU) with a 600
+			second timeout. [RT #16553]
+
 2120.	[doc]		Fix markup on nsupdate man page. [RT #16556]
 
-	--- 9.4.0rc1 released ---
+2119.	[compat]	libbind: allow res_init() to succeed enough to
+			return the default domain even if it was unable
+			to allocate memory.
 
 2118.	[bug]		Handle response with long chains of domain name
 			compression pointers which point to other compression
@@ -837,8 +1463,14 @@
 
 2109.	[port]		libbind: silence aix 5.3 compiler warnings. [RT #16502]
 
+2108.	[func]		DHCID support. [RT #16456]
+
 2107.	[bug]		dighost.c: more cleanup of buffers. [RT #16499]
 
+2106.	[func]		'rndc status' now reports named's version. [RT #16426]
+
+2105.	[func]		GSS-TSIG support (RFC 3645).
+
 2104.	[port]		Fix Solaris SMF error message.
 
 2103.	[port]		Add /usr/sfw to list of locations for OpenSSL
@@ -846,8 +1478,6 @@
 
 2102.	[port]		Silence Solaris 10 warnings.
 
-	--- 9.4.0b4 released ---
-
 2101.	[bug]		OpenSSL version checks were not quite right.
 			[RT #16476]
 
@@ -860,8 +1490,6 @@
 			triggered an INSIST failure about the node lock
 			reference.  [RT #16411]
 
-	--- 9.4.0b3 released ---
-
 2097.	[bug]		named could reference a destroyed memory context
 			after being reloaded / reconfigured. [RT #16428]
 
@@ -870,14 +1498,14 @@
 
 2095.	[port]		libbind: alway prototype inet_cidr_ntop_ipv6() and
 			net_cidr_ntop_ipv6(). [RT #16388]
-
+ 
 2094.	[contrib]	Update named-bootconf.  [RT# 16404]
 
 2093.	[bug]		named-checkzone -s was broken.
 
 2092.	[bug]		win32: dig, host, nslookup.  Use registry config
 			if resolv.conf does not exist or no nameservers
-			listed. [RT #15877]
+			listed. [RT #15877] 
 
 2091.	[port]		dighost.c: race condition on cleanup. [RT #16417]
 
@@ -906,8 +1534,6 @@
 
 2082.	[doc]		Document 'cache-file' as a test only option.
 
-	--- 9.4.0b2 released ---
-
 2081.	[port]		libbind: minor 64-bit portability fix in memcluster.c.
 			[RT #16360]
 
@@ -971,8 +1597,6 @@
 2060.	[bug]		Enabling DLZ support could leave views partially
 			configured. [RT #16295]
 
-	--- 9.4.0b1 released ---
-
 2059.	[bug]		Search into cache rbtdb could trigger an INSIST
 			failure while cleaning up a stale rdataset.
 			[RT #16292]
@@ -1052,13 +1676,15 @@
 2036.	[bug]		'rndc recursing' could cause trigger a REQUIRE.
 			[RT #16075]
 
+2035.	[func]		Make falling back to TCP on UDP refresh failure
+			optional. Default "try-tcp-refresh yes;" for BIND 8
+			compatibility. [RT #16123]
+
 2034.	[bug]		gcc: set -fno-strict-aliasing. [RT #16124]
 
 2033.	[bug]		We weren't creating multiple client memory contexts
 			on demand as expected. [RT #16095]
 
-	--- 9.4.0a6 released ---
-
 2032.	[bug]		Remove a INSIST in query_addadditional2(). [RT #16074]
 
 2031.	[bug]		Emit a error message when "rndc refresh" is called on
@@ -1105,8 +1731,6 @@
 			allowed but requested and we had the answer
 			to the original qname. [RT #15945]
 
-	--- 9.4.0a5 released ---
-
 2015.	[cleanup]	use-additional-cache is now acache-enable for
 			consistency.  Default acache-enable off in BIND 9.4
 			as it requires memory usage to be configured.
@@ -1126,7 +1750,7 @@
 			the signed zone, either as an increment or as the
 			system time(). [RT #15633]
 
-	--- 9.4.0a4 released ---
+2010.	[placeholder]	rt15958
 
 2009.	[bug]		libbind: Coverity fixes. [RT #15808]
 
@@ -1280,12 +1904,12 @@
 1966.	[bug]		Don't set CD when we have fallen back to plain DNS.
 			[RT #15727]
 
-1965.	[func]		Suppress spurious "recusion requested but not
+1965.	[func]		Suppress spurious "recursion requested but not
 			available" warning with 'dig +qr'. [RT #15780].
 
 1964.	[func]		Separate out MX and SRV to CNAME checks. [RT #15723]
 
-1963.	[port]		Tru64 4.0E doesn't support send() and recv().
+1963.	[port]		Tru64 4.0E doesn't support send() and recv(). 
 			[RT #15586]
 
 1962.	[bug]		Named failed to clear old update-policy when it
@@ -1328,7 +1952,7 @@
 1951.	[security]	Drop queries from particular well known ports.
 			Don't return FORMERR to queries from particular
 			well known ports.  [RT #15636]
-
+			
 1950.	[port]		Solaris 2.5.1 and earlier cannot bind() then connect()
 			a TCP socket. This prevents the source address being
 			set for TCP connections. [RT #15628]
@@ -1350,19 +1974,13 @@
 1945.	[cleanup]	dnssec-keygen: RSA (RSAMD5) is no longer recommended.
 			To generate a RSAMD5 key you must explicitly request
 			RSAMD5. [RT #13780]
-
+			
 1944.	[cleanup]	isc_hash_create() does not need a read/write lock.
 			[RT #15522]
 
 1943.	[bug]		Set the loadtime after rolling forward the journal.
 			[RT #15647]
 
-1597.	[func]		Allow notify-source and query-source to be specified
-			on a per server basis similar to transfer-source.
-			[RT #6496]
-
-	--- 9.4.0a3 released ---
-
 1942.	[bug]		If the name of a DNSKEY match that of one in
 			trusted-keys do not attempt to validate the DNSKEY
 			using the parents DS RRset. [RT #15649]
@@ -1390,12 +2008,6 @@
 			prior to returning them if it can be done without
 			requiring DNSKEYs to be fetched.  [RT #15430]
 
-1919.	[contrib]	queryperf: a set of new features: collecting/printing
-			response delays, printing intermediate results, and
-			adjusting query rate for the "target" qps.
-
-	--- 9.4.0a2 released ---
-
 1933.	[bug]		dump_rdataset_raw() had a incorrect INSIST. [RT #15534]
 
 1932.	[bug]		hpux: LDFLAGS was getting corrupted. [RT #15530]
@@ -1434,7 +2046,9 @@
 			have the desired performance characteristics.
 			[RT #15454]
 
-	--- 9.4.0a1 released ---
+1919.	[contrib]	queryperf: a set of new features: collecting/printing
+			response delays, printing intermediate results, and
+			adjusting query rate for the "target" qps.
 
 1918.	[bug]		Memory leak when checking acls. [RT #15391]
 
@@ -1472,7 +2086,7 @@
 			[RT #15034]
 
 1905.	[bug]		Strings returned from cfg_obj_asstring() should be
-			treated as read-only.  The prototype for
+			treated as read-only.  The prototype for 
 			cfg_obj_asstring() has been updated to reflect this.
 			[RT #15256]
 
@@ -1577,6 +2191,8 @@
 
 1872.	[port]		win32: Handle ERROR_NETNAME_DELETED.  [RT #13753]
 
+1871.	[placeholder]
+
 1870.	[func]		Added framework for handling multiple EDNS versions.
 			[RT #14873]
 
@@ -1602,10 +2218,10 @@
 1863.	[bug]		rrset-order "fixed" error messages not complete.
 
 1862.	[func]		Add additional zone data constancy checks.
-			named-checkzone has extended checking of NS, MX and
+			named-checkzone has extended checking of NS, MX and 
 			SRV record and the hosts they reference.
 			named has extended post zone load checks.
-			New zone options: check-mx and integrity-check.
+			New zone options: check-mx and integrity-check. 
 			[RT #4940]
 
 1861.	[bug]		dig could trigger a INSIST on certain malformed
@@ -1648,9 +2264,9 @@
 1848.	[bug]		Improve SMF integration. [RT #13238]
 
 1847.	[bug]		isc_ondestroy_init() is called too late in
-			dns_rbtdb_create()/dns_rbtdb64_create().
+			dns_rbtdb_create()/dns_rbtdb64_create(). 
 			[RT #13661]
-
+			
 1846.	[contrib]	query-loc-0.3.0 from Stephane Bortzmeyer
 			<bortzmeyer@nic.fr>.
 
@@ -1721,6 +2337,8 @@
 
 1822.	[bug]		check-names test for RT was reversed. [RT #13382]
 
+1821.	[placeholder]
+
 1820.	[bug]		Gracefully handle acl loops. [RT #13659]
 
 1819.	[bug]		The validator needed to check both the algorithm and
@@ -1870,6 +2488,10 @@
 
 1773.	[bug]		Fast retry on host / net unreachable. [RT #13153]
 
+1772.	[placeholder]
+
+1771.	[placeholder]
+
 1770.	[bug]		named-checkconf failed to report missing a missing
 			file clause for rbt{64} master/hint zones. [RT#13009]
 
@@ -1936,7 +2558,7 @@
 			[RT #12866]
 
 1748.	[func]		dig now returns the byte count for axfr/ixfr.
-
+			
 1747.	[bug]		BIND 8 compatibility: named/named-checkconf failed
 			to parse "host-statistics-max" in named.conf.
 
@@ -1954,7 +2576,7 @@
 			requested number of worker threads then destruction
 			of the manager would trigger an INSIST() failure.
 			[RT #12790]
-
+			
 1742.	[bug]		Deleting all records at a node then adding a
 			previously existing record, in a single UPDATE
 			transaction, failed to leave / regenerate the
@@ -1965,7 +2587,7 @@
 
 1740.	[bug]		Replace rbt's hash algorithm as it performed badly
 			with certain zones. [RT #12729]
-
+			
 			NOTE: a hash context now needs to be established
 			via isc_hash_create() if the application was not
 			already doing this.
@@ -1980,7 +2602,7 @@
 
 1736.	[bug]		dst_key_fromnamedfile() could fail to read a
 			public key. [RT #12687]
-
+			
 1735.	[bug]		'dig +sigtrace' could die with a REQUIRE failure.
 			[RE #12688]
 
@@ -2157,7 +2779,7 @@
 
 1675.	[bug]		named would sometimes add extra NSEC records to
 			the authority section.
-
+			
 1674.	[port]		linux: increase buffer size used to scan
 			/proc/net/if_inet6.
 
@@ -2173,6 +2795,8 @@
 1670.	[func]		Log UPDATE requests to slave zones without an acl as
 			"disabled" at debug level 3. [RT# 11657]
 
+1669.	[placeholder]
+
 1668.	[bug]		DIG_SIGCHASE was making bin/dig/host dump core.
 
 1667.	[port]		linux: not all versions have IF_NAMESIZE.
@@ -2229,7 +2853,7 @@
 
 1648.	[func]		Update dnssec-lookaside named.conf syntax to support
 			multiple dnssec-lookaside namespaces (not yet
-			implemented).
+			implemented).  
 
 1647.	[bug]		It was possible trigger a INSIST when chasing a DS
 			record that required walking back over a empty node.
@@ -2259,7 +2883,7 @@
 
 1638.	[bug]		"ixfr-from-differences" could generate a REQUIRE
 			failure if the journal open failed. [RT #11347]
-
+			
 1637.	[bug]		Node reference leak on error in addnoqname().
 
 1636.	[bug]		The dump done callback could get ISC_R_SUCCESS even if
@@ -2353,21 +2977,21 @@
 1607.	[bug]		dig, host and nslookup were still using random()
 			to generate query ids. [RT# 11013]
 
-1606.	[bug]		DLV insecurity proof was failing.
+1606.	[bug]	 	DLV insecurity proof was failing.
 
 1605.	[func]		New dns_db_find() option DNS_DBFIND_COVERINGNSEC.
 
 1604.	[bug]		A xfrout_ctx_create() failure would result in
 			xfrout_ctx_destroy() being called with a
 			partially initialized structure.
-
+			
 1603.	[bug]		nsupdate: set interactive based on isatty().
 			[RT# 10929]
 
 1602.	[bug]		Logging to a file failed unless a size was specified.
 			[RT# 10925]
 
-1601.	[bug]		Silence spurious warning 'both "recursion no;" and
+1601.	[bug]		Silence spurious warning 'both "recursion no;" and 
 			"allow-recursion" active' warning from view "_bind".
 			[RT# 10920]
 
@@ -2379,6 +3003,10 @@
 1598.	[func]		Specify that certain parts of the namespace must
 			be secure (dnssec-must-be-secure).
 
+1597.	[func]		Allow notify-source and query-source to be specified
+			on a per server basis similar to transfer-source.
+			[RT #6496]
+
 1596.	[func]		Accept 'notify-source' style syntax for query-source.
 
 1595.	[func]		New notify type 'master-only'.  Enable notify for
@@ -4280,7 +4908,7 @@
  963.	[bug]		Bad ISC_LANG_ENDDECLS. [RT #1645]
 
  962.	[bug]		libbind: bad "#undef", don't attempt to install
-			non-existant nlist.h. [RT #1640]
+			non-existent nlist.h. [RT #1640]
 
  961.	[bug]		Tried to use a IPV6 feature when ISC_PLATFORM_HAVEIPV6
 			was not defined. [RT #1482]
@@ -6918,7 +7546,7 @@
  188.	[func]		Log a warning message when an incoming zone transfer
 			contains out-of-zone data.
 
- 187.	[func]		isc_ratelimter_enqueue() has an additional argument
+ 187.	[func]		isc_ratelimiter_enqueue() has an additional argument
 			'task'.
 
  186.	[func]		dns_request_getresponse() has an additional argument
@@ -7061,7 +7689,7 @@
 
 				masters [ port xxx ] { y.y.y.y [ port zzz ] ; }
 
- 149.	[cleanup]	Removed usused argument 'olist' from
+ 149.	[cleanup]	Removed unused argument 'olist' from
 			dns_c_view_unsetordering().
 
  148.	[cleanup]	Stop issuing some warnings about some configuration
@@ -7137,7 +7765,7 @@
  128.	[cleanup]	<isc/dir.h> had ISC_LANG_BEGINDECLS instead of
 			ISC_LANG_ENDDECLS at end of header.
 
- 127.	[cleanup]	The contracts for the comparision routines
+ 127.	[cleanup]	The contracts for the comparison routines
 			dns_name_fullcompare(), dns_name_compare(),
 			dns_name_rdatacompare(), and dns_rdata_compare() now
 			specify that the order value returned is < 0, 0, or > 0
diff --git a/contrib/bind9/COPYRIGHT b/contrib/bind9/COPYRIGHT
index 8d6a0ce..620ee98 100644
--- a/contrib/bind9/COPYRIGHT
+++ b/contrib/bind9/COPYRIGHT
@@ -1,4 +1,4 @@
-Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
 Copyright (C) 1996-2003  Internet Software Consortium.
 
 Permission to use, copy, modify, and/or distribute this software for any
@@ -13,7 +13,7 @@ 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: COPYRIGHT,v 1.9.18.5 2008/01/02 23:46:02 tbox Exp $
+$Id: COPYRIGHT,v 1.14.176.1 2009/01/05 23:47:22 tbox Exp $
 
 Portions Copyright (C) 1996-2001  Nominum, Inc.
 
diff --git a/contrib/bind9/FAQ b/contrib/bind9/FAQ
index 2c333be..2846b31 100644
--- a/contrib/bind9/FAQ
+++ b/contrib/bind9/FAQ
@@ -1,6 +1,6 @@
 Frequently Asked Questions about BIND 9
 
-Copyright © 2004-2008 Internet Systems Consortium, Inc. ("ISC")
+Copyright © 2004-2009 Internet Systems Consortium, Inc. ("ISC")
 
 Copyright © 2000-2003 Internet Software Consortium.
 
@@ -600,7 +600,7 @@ Q: Why do queries for NSEC3 records fail to return the NSEC3 record?
 
 A: NSEC3 records are strictly meta data and can only be returned in the
    authority section. This is done so that signing the zone using NSEC3
-   records does not bring names into existance that do not exist in the
+   records does not bring names into existence that do not exist in the
    unsigned version of the zone.
 
 5. Operating-System Specific Questions
@@ -825,7 +825,6 @@ 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>.
diff --git a/contrib/bind9/FAQ.xml b/contrib/bind9/FAQ.xml
index b624d06..95346f7 100644
--- a/contrib/bind9/FAQ.xml
+++ b/contrib/bind9/FAQ.xml
@@ -1,7 +1,7 @@
 <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
        "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" []>
 <!--
- - Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -17,7 +17,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: FAQ.xml,v 1.4.4.24 2008/09/10 01:32:25 tbox Exp $ -->
+<!-- $Id: FAQ.xml,v 1.46.56.4 2009/02/19 01:51:58 tbox Exp $ -->
 
 <article class="faq">
   <title>Frequently Asked Questions about BIND 9</title>
@@ -28,6 +28,7 @@
       <year>2006</year>
       <year>2007</year>
       <year>2008</year>
+      <year>2009</year>
       <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
     </copyright>
     <copyright>
@@ -1067,7 +1068,7 @@ empty:
 	  NSEC3 records are strictly meta data and can only be
 	  returned in the authority section.  This is done so that
 	  signing the zone using NSEC3 records does not bring names
-	  into existance that do not exist in the unsigned version
+	  into existence that do not exist in the unsigned version
 	  of the zone.
 	</para>
       </answer>
@@ -1470,7 +1471,6 @@ options {
 	</para>
 	<informalexample>
 	  <programlisting>
-/etc/rc.conf
 rand_irqs="3 14 15"</programlisting>
 	</informalexample>
 	<para>
diff --git a/contrib/bind9/Makefile.in b/contrib/bind9/Makefile.in
index 9ff0f64..662ee0f 100644
--- a/contrib/bind9/Makefile.in
+++ b/contrib/bind9/Makefile.in
@@ -1,4 +1,4 @@
-# Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1998-2002  Internet Software Consortium.
 #
 # Permission to use, copy, modify, and/or 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.43.18.6 2007/09/03 23:46:21 tbox Exp $
+# $Id: Makefile.in,v 1.52.48.2 2009/02/20 23:47:23 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -21,17 +21,16 @@ top_srcdir =	@top_srcdir@
 
 @BIND9_VERSION@
 
-SUBDIRS =	make lib bin doc @LIBBIND@
+SUBDIRS =	make lib bin doc
 TARGETS =
 
-@BIND9_MAKE_RULES@
+MANPAGES =	isc-config.sh.1
+ 
+HTMLPAGES =	isc-config.sh.html
+ 
+MANOBJS =	${MANPAGES} ${HTMLPAGES}
 
-distclean::
-	@if [ "X@LIBBIND@" = "X" ] ; then \
-		i=lib/bind; \
-		echo "making $@ in `pwd`/$$i"; \
-		(cd $$i; ${MAKE} ${MAKEDEFS} $@) || exit 1; \
-	fi
+@BIND9_MAKE_RULES@
 
 distclean::
 	rm -f config.cache config.h config.log config.status TAGS
@@ -43,12 +42,19 @@ distclean::
 maintainer-clean::
 	rm -f configure
 
+docclean manclean maintainer-clean::
+	rm -f ${MANOBJS}
+
+doc man:: ${MANOBJS}
+
 installdirs:
 	$(SHELL) ${top_srcdir}/mkinstalldirs ${DESTDIR}${bindir} \
 	${DESTDIR}${localstatedir}/run ${DESTDIR}${sysconfdir}
+	$(SHELL) ${top_srcdir}/mkinstalldirs ${DESTDIR}${mandir}/man1
 
 install:: isc-config.sh installdirs
 	${INSTALL_SCRIPT} isc-config.sh ${DESTDIR}${bindir}
+	${INSTALL_DATA} ${srcdir}/isc-config.sh.1 ${DESTDIR}${mandir}/man1
 
 tags:
 	rm -f TAGS
diff --git a/contrib/bind9/NSEC3-NOTES b/contrib/bind9/NSEC3-NOTES
new file mode 100644
index 0000000..d23b20e
--- /dev/null
+++ b/contrib/bind9/NSEC3-NOTES
@@ -0,0 +1,128 @@
+
+			DNSSEC and UPDATE
+
+		Converting from insecure to secure
+
+As of BIND 9.6.0 it is possible to move a zone between being insecure
+to secure and back again.  A secure zone can be using NSEC or NSEC3.
+
+To move a zone from insecure to secure you need to configure named
+so that it can see the K* files which contain the public and private
+parts of the keys that will be used to sign the zone.  These files
+will have been generated by dnssec-keygen.  You can do this by
+placing them in the key-directory as specified in named.conf.
+
+	zone example.net {
+		type master;
+		allow-update { .... };
+		file "dynamic/example.net/example.net";
+		key-directory "dynamic/example.net";
+	};
+
+Assuming one KSK and one ZSK DNSKEY key have been generated.  Then
+this will cause the zone to be signed with the ZSK and the DNSKEY
+RRset to be signed with the KSK DNSKEY.  A NSEC chain will also be
+generated as part of the initial signing process.
+
+	% nsupdate
+	> ttl 3600
+	> update add example.net DNSKEY 256 3 7 AwEAAZn17pUF0KpbPA2c7Gz76Vb18v0teKT3EyAGfBfL8eQ8al35zz3Y I1m/SAQBxIqMfLtIwqWPdgthsu36azGQAX8=
+	> update add example.net DNSKEY 257 3 7 AwEAAd/7odU/64o2LGsifbLtQmtO8dFDtTAZXSX2+X3e/UNlq9IHq3Y0 XtC0Iuawl/qkaKVxXe2lo8Ct+dM6UehyCqk=
+	> send
+
+While the update request will complete almost immediately the zone
+will not be completely signed until named has had time to walk the
+zone and generate the NSEC and RRSIG records.  Initially the NSEC
+record at the zone apex will have the OPT bit set.  When the NSEC
+chain is complete the OPT bit will be cleared.  Additionally when
+the zone is fully signed the private type (default TYPE65535) records
+will have a non zero value for the final octet. 
+
+The private type record has 5 octets.
+	algorithm (octet 1)
+	key id in network order (octet 2 and 3)
+	removal flag (octet 4)
+	complete flag (octet 5)
+
+If you wish to go straight to a secure zone using NSEC3 you should
+also add a NSECPARAM record to the update request with the flags
+field set to indicate whether the NSEC3 chain will have the OPTOUT
+bit set or not.
+
+	% nsupdate
+	> ttl 3600
+	> update add example.net DNSKEY 256 3 7 AwEAAZn17pUF0KpbPA2c7Gz76Vb18v0teKT3EyAGfBfL8eQ8al35zz3Y I1m/SAQBxIqMfLtIwqWPdgthsu36azGQAX8=
+	> update add example.net DNSKEY 257 3 7 AwEAAd/7odU/64o2LGsifbLtQmtO8dFDtTAZXSX2+X3e/UNlq9IHq3Y0 XtC0Iuawl/qkaKVxXe2lo8Ct+dM6UehyCqk=
+	> update add example.net NSEC3PARAM 1 1 100 1234567890
+	> send
+
+Again the update request will complete almost immediately however the
+NSEC3PARAM record will have additional flag bits set indicating that the
+NSEC3 chain is under construction.  When the NSEC3 chain is complete the
+flags field will be set to zero. 
+
+While the initial signing and NSEC/NSEC3 chain generation is happening
+other updates are possible.
+
+		DNSKEY roll overs via UPDATE
+
+It is possible to perform key rollovers via update.  You need to
+add the K* files for the new keys so that named can find them.  You
+can then add the new DNSKEY RRs via update.  Named will then cause
+the zone to be signed with the new keys.  When the signing is
+complete the private type records will be updated so that the last
+octet is non zero.
+
+If this is for a KSK you need to inform the parent and any trust
+anchor repositories of the new KSK.
+
+You should then wait for the maximum TLL in the zone before removing the
+old DNSKEY.  If it is a KSK that is being updated you also need to wait
+for the DS RRset in the parent to be updated and its TTL to expire.
+This ensures that all clients will be able to verify at least a signature
+when you remove the old DNSKEY.
+
+The old DNSKEY can be removed via UPDATE.  Take care to specify
+the correct key.  Named will clean out any signatures generated by
+the old key after the update completes.
+
+		NSEC3PARAM rollovers via UPDATE.
+
+Add the new NSEC3PARAM record via update.  When the new NSEC3 chain
+has been generated the NSEC3PARAM flag field will be zero.  At this
+point you can remove the old NSEC3PARAM record.  The old chain will
+be removed after the update request completes.
+
+		Converting from NSEC to NSEC3
+
+To do this you just need to add a NSEC3PARAM record.  When the
+conversion is complete the NSEC chain will have been removed and
+the NSEC3PARAM record will have a zero flag field.  The NSEC3 chain
+will be generated before the NSEC chain is destroyed.
+
+		Converting from NSEC3 to NSEC
+
+To do this remove all NSEC3PARAM records with a zero flag field.  The
+NSEC chain will be generated before the NSEC3 chain is removed.
+
+		Converting from secure to insecure
+
+To do this remove all the DNSKEY records.  Any NSEC or NSEC3 chains
+will be removed as well as associated NSEC3PARAM records.  This will
+take place after the update requests completes.
+
+		Periodic re-signing.
+
+Named will periodically re-sign RRsets which have not been re-signed
+as a result of some update action.  The signature lifetimes will
+be adjusted so as to spread the re-sign load over time rather than
+all at once.
+
+		NSEC3 and OPTOUT
+
+Named only supports creating new NSEC3 chains where all the NSEC3
+records in the zone have the same OPTOUT state.  Named supports
+UPDATES to zones where the NSEC3 records in the chain have mixed
+OPTOUT state.  Named does not support changing the OPTOUT state of
+an individual NSEC3 record, the entire chain needs to be changed if
+the OPTOUT state of an individual NSEC3 needs to be changed.
diff --git a/contrib/bind9/README b/contrib/bind9/README
index 0a0bc9e..d151988 100644
--- a/contrib/bind9/README
+++ b/contrib/bind9/README
@@ -42,29 +42,50 @@ BIND 9
 		Stichting NLnet - NLnet Foundation
 		Nominum, Inc.
 
-BIND 9.4.3
+BIND 9.6.0
 
-	BIND 9.4.3 is a maintenance release, fixing bugs in 9.4.2.
+        BIND 9.6.0 includes a number of changes from BIND 9.5 and earlier
+        releases, including:
 
-BIND 9.4.2
+        Full NSEC3 support
 
-	BIND 9.4.2 is a maintenance release, containing fixes for
-	a number of bugs in 9.4.1.
+        Automatic zone re-signing
 
-	Warning: If you installed BIND 9.4.2rc1 then any applications
-	linked against this release candidate will need to be rebuilt.
+	New update-policy methods tcp-self and 6to4-self
 
-BIND 9.4.1
+        The BIND 8 resolver library, libbind, has been removed from the
+        BIND 9 distribution and is now available as a separate download.
 
-	BIND 9.4.1 is a security release, containing a fix for
-	a security bugs in 9.4.0.
+	Change the default pid file location from /var/run to
+	/var/run/{named,lwresd} for improved chroot/setuid support.
+
+BIND 9.5.0
+
+	BIND 9.5.0 has a number of new features over 9.4,
+	including:
+
+	GSS-TSIG support (RFC 3645).
+
+	DHCID support.
+
+	Experimental http server and statistics support for named via xml.
+
+	More detailed statistics counters including those supported in BIND 8.
+
+	Faster ACL processing.
+
+	Use Doxygen to generate internal documentation.
+
+        Efficient LRU cache-cleaning mechanism.
+
+        NSID support.
 
 BIND 9.4.0
 
 	BIND 9.4.0 has a number of new features over 9.3,
 	including:
 
-	Implemented "additional section caching" (or "acache"), an
+	Implemented "additional section caching (or acache)", an
 	internal cache framework for additional section content to
 	improve response performance.  Several configuration options
 	were provided to control the behavior.
@@ -76,13 +97,14 @@ BIND 9.4.0
 
 	rndc now allows addresses to be set in the server clauses.
 
-	New option "allow-query-cache".  This lets allow-query be
-	used to specify the default zone access level rather than
-	having to have every zone override the global value.
-	allow-query-cache can be set at both the options and view
-	levels. If allow-query-cache is not set then allow-recursion
-	is used if set, otherwise allow-query is used if set, otherwise
-	the default (localhost; localnets;) is used.
+	New option "allow-query-cache".  This lets "allow-query"
+	be used to specify the default zone access level rather
+	than having to have every zone override the global value.
+	"allow-query-cache" can be set at both the options and view
+	levels.  If "allow-query-cache" is not set then "allow-recursion"
+	is used if set, otherwise "allow-query" is used if set
+	unless "recursion no;" is set in which case "none;" is used,
+	otherwise the default (localhost; localnets;) is used.
 
 	rndc: the source address can now be specified.
 
@@ -155,11 +177,12 @@ BIND 9.4.0
 
 	Add support for CH A record.
 
-	Add additional zone data consistancy checks.  named-checkzone
+	Add additional zone data constancy checks.  named-checkzone
 	has extended checking of NS, MX and SRV record and the hosts
 	they reference.  named has extended post zone load checks.
 	New zone options: check-mx and integrity-check.
 
+
 	edns-udp-size can now be overridden on a per server basis.
 
 	dig can now specify the EDNS version when making a query.
@@ -172,7 +195,7 @@ BIND 9.4.0
 	Detect duplicates of UDP queries we are recursing on and
 	drop them.  New stats category "duplicates".
 
-	Memory management. "USE INTERNAL MALLOC" is now runtime selectable.
+	"USE INTERNAL MALLOC" is now runtime selectable.
 
 	The lame cache is now done on a <qname,qclass,qtype> basis
 	as some servers only appear to be lame for certain query
@@ -187,9 +210,9 @@ BIND 9.4.0
 
 	Support for IPSECKEY rdata type.
 
-	Raise the UDP receive buffer size to 32k if it is less than 32k.
+	Raise the UDP recieve buffer size to 32k if it is less than 32k.
 
-	x86 and x86_64 now have separate atomic locking implementations.
+	x86 and x86_64 now have seperate atomic locking implementations.
 
 	named-checkconf now validates update-policy entries.
 
@@ -217,69 +240,9 @@ BIND 9.4.0
 	to set 'RA' when 'RD' is set unless a server is explicitly
 	set.
 
-	Integrate contributed DLZ code into named.
-
-	Integrate contributed IDN code from JPNIC.
-
-	Validate pending NS RRsets, in the authority section, prior
-	to returning them if it can be done without requiring DNSKEYs
-	to be fetched.
-
-	It is now possible to configure named to accept expired
-	RRSIGs.  Default "dnssec-accept-expired no;".  Setting
-	"dnssec-accept-expired yes;" leaves named vulnerable to
-	replay attacks.
+	Integrate contibuted DLZ code into named.
 
-	Additional memory leakage checks.
-
-	The maximum EDNS UDP response named will send can now be
-	set in named.conf (max-udp-size).  This is independent of
-	the advertised receive buffer (edns-udp-size).
-
-	Named now falls back to advertising EDNS with a 512 byte
-	receive buffer if the initial EDNS queries fail.
-
-	Control the zeroing of the negative response TTL to a soa
-	query.  Defaults "zero-no-soa-ttl yes;" and
-	"zero-no-soa-ttl-cache no;".
-			
-	Separate out MX and SRV to CNAME checks.
-
-	dig/nslookup/host: warn about missing "QR".
-
-	TSIG HMACSHA1, HMACSHA224, HMACSHA256, HMACSHA384 and
-	HMACSHA512 support.
-
-	dnssec-signzone: output the SOA record as the first record
-	in the signed zone.
-
-	Two new update policies.  "selfsub" and "selfwild".
-
-	dig, nslookup and host now advertise a 4096 byte EDNS UDP
-	buffer size by default.
-
-	Report when a zone is removed.
-
-	DS/DLV SHA256 digest algorithm support.
-
-	Implement "rrset-order fixed".
-
-	Check the KSK flag when updating a secure dynamic zone.
-	New zone option "update-check-ksk yes;".
-
-	It is now possible to explicitly enable DNSSEC validation.
-	default dnssec-validation no; to be changed to yes in 9.5.0.
-
-	It is now possible to enable/disable DNSSEC validation
-	from rndc.  This is useful for the mobile hosts where the
-	current connection point breaks DNSSEC (firewall/proxy).
-
-		rndc validation newstate [view]
-
-	dnssec-signzone can now update the SOA record of the signed
-	zone, either as an increment or as the system time().
-
-	Statistics about acache now recorded and sent to log.
+	Integrate contibuted IDN code from JPNIC.
 
 	libbind: corresponds to that from BIND 8.4.7.
 
@@ -423,31 +386,35 @@ Building
 	We've had successful builds and tests on the following systems:
 
 		COMPAQ Tru64 UNIX 5.1B
+		Fedora Core 6
 		FreeBSD 4.10, 5.2.1, 6.2
 		HP-UX 11.11
-		NetBSD 1.5
-		Slackware Linux 8.1
-		Solaris 8, 9, 9 (x86)
+		Mac OS X 10.5
+		NetBSD 3.x and 4.0-beta
+		OpenBSD 3.3 and up
+		Solaris 8, 9, 9 (x86), 10
+		Ubuntu 7.04, 7.10
 		Windows XP/2003/2008
 
         NOTE:  As of BIND 9.5.1, 9.4.3, and 9.3.6, older versions of
         Windows, including Windows NT and Windows 2000, are no longer
         supported.
 
-	Additionally, we have unverified reports of success building
-	previous versions of BIND 9 from users of the following systems:
-
-		AIX 5L
-		SuSE Linux 7.0
-		Slackware Linux 7.x, 8.0
-	        Red Hat Linux 7.1
-		Debian GNU/Linux 2.2 and 3.0
-		Mandrake 8.1
-		OpenBSD 2.6, 2.8, 2.9, 3.1, 3.6, 3.8
-		UnixWare 7.1.1
-		HP-UX 10.20
-		BSD/OS 4.2
-		Mac OS X 10.1, 10.3.8
+	We have recent reports from the user community that a supported
+	version of BIND will build and run on the following systems:
+
+		AIX 4.3, 5L
+		CentOS 4, 4.5, 5
+		Darwin 9.0.0d1/ARM
+		Debian 4
+		Fedora Core 5, 7
+		FreeBSD 6.1
+		HP-UX 11.23 PA
+		MacOS X 10.4, 10.5
+		Red Hat Enterprise Linux 4, 5
+		SCO OpenServer 5.0.6
+		Slackware 9, 10
+		SuSE 9, 10
 
 	To build, just
 
@@ -484,12 +451,13 @@ Building
 				    -DDIG_SIGCHASE_BU=1)
 		Disable dropping queries from particular well known ports.
 		  -DNS_CLIENT_DROPPORT=0
-		Disable support for "rrset-order fixed".
-		  -DDNS_RDATASET_FIXED=0
-		Sibling glue checking in named-checkzone is enabled by default.
+	        Sibling glue checking in named-checkzone is enabled by default.
 		To disable the default check set.  -DCHECK_SIBLING=0
 		named-checkzone checks out-of-zone addresses by default.
 		To disable this default set.  -DCHECK_LOCAL=0
+		To create the default pid files in ${localstatedir}/run rather
+		than ${localstatedir}/run/{named,lwresd}/ set.
+		  -DNS_RUN_PID_DIR=0
 		Enable workaround for Solaris kernel bug about /dev/poll
 		  -DISC_SOCKET_USE_POLLWATCH=1
 		  The watch timeout is also configurable, e.g.,
@@ -519,9 +487,6 @@ Building
 	a nonstandard prefix, you can tell configure where to
 	look for it using "--with-openssl=/prefix".
 
-	To build libbind (the BIND 8 resolver library), specify
-	"--enable-libbind" on the configure command line.
-
 	On some platforms it is necessary to explictly request large
 	file support to handle files bigger than 2GB.  This can be
 	done by "--enable-largefile" on the configure command line.
@@ -533,6 +498,11 @@ Building
 	on the configure command line.  The default is operating
 	system dependent.
 
+        Support for the "fixed" rrset-order option can be enabled
+        or disabled by specifying "--enable-fixed-rrset" or
+        "--disable-fixed-rrset" on the configure command line.
+        The default is "disabled", to reduce memory footprint.
+
 	If your operating system has integrated support for IPv6, it
 	will be used automatically.  If you have installed KAME IPv6
 	separately, use "--with-kame[=PATH]" to specify its location.
@@ -613,8 +583,9 @@ Bug Reports and Mailing Lists
 		http://www.isc.org/ops/lists/
 
 	If you're planning on making changes to the BIND 9 source
-	code, you might want to join the BIND Forum as a Worker.
-	This gives you access to the bind-workers@isc.org mailing
-	list and pre-release access to the code.
+	code, you might want to join the BIND Workers mailing list.
+	Send mail to
+
+		bind-workers-request@isc.org
+
 
-		http://www.isc.org/sw/guild/bf/
diff --git a/contrib/bind9/README.idnkit b/contrib/bind9/README.idnkit
index 316f879..0eda0a5 100644
--- a/contrib/bind9/README.idnkit
+++ b/contrib/bind9/README.idnkit
@@ -55,7 +55,7 @@ at least specify `--with-idn' option to enable IDN support.
 
 	`--with-libiconv' assumes that your C compiler has `-R'
 	option, and that the option adds the specified run-time path
-	to an exacutable binary.  If `-R' option of your compiler has
+	to an executable binary.  If `-R' option of your compiler has
 	different meaning, or your compiler lacks the option, you
 	should use `--with-iconv' option instead.  Binary command
 	without run-time path information might be unexecutable.
@@ -68,7 +68,7 @@ at least specify `--with-idn' option to enable IDN support.
 	specified, `--with-iconv' is prior to `--with-libiconv'.
 
     --with-iconv=ICONV_LIBSPEC
-	If your libc doens't provide iconv(), you need to specify the
+	If your libc doesn't provide iconv(), you need to specify the
 	library containing iconv() with this option.  `ICONV_LIBSPEC'
 	is the argument(s) to `cc' or `ld' to link the library, for
 	example, `--with-iconv="-L/usr/local/lib -liconv"'.
@@ -82,7 +82,7 @@ at least specify `--with-idn' option to enable IDN support.
 	this option is not specified, `-L${PREFIX}/lib -lidnkit' is
 	assumed, where ${PREFIX} is the installation prefix specified
 	with `--with-idn' option above.  You may need to use this
-	option to specify extra argments, for example,
+	option to specify extra arguments, for example,
 	`--with-idnlib="-L/usr/local/lib -R/usr/local/lib -lidnkit"'.
 
 Please consult `README' for other configuration options.
@@ -109,4 +109,4 @@ about idnkit and this patch.
 Bug reports and comments on this kit should be sent to
 mdnkit-bugs@nic.ad.jp and idn-cmt@nic.ad.jp, respectively.
 
-; $Id: README.idnkit,v 1.2.2.2 2005/09/12 02:12:08 marka Exp $
+; $Id: README.idnkit,v 1.2.762.1 2009/01/18 23:25:14 marka Exp $
diff --git a/contrib/bind9/README.pkcs11 b/contrib/bind9/README.pkcs11
new file mode 100644
index 0000000..b58640d
--- /dev/null
+++ b/contrib/bind9/README.pkcs11
@@ -0,0 +1,61 @@
+
+			BIND-9 PKCS#11 support
+
+Prerequisite
+
+The PKCS#11 support needs a PKCS#11 OpenSSL engine based on the Solaris one,
+released the 2007-11-21 for OpenSSL 0.9.8g, with a bug fix (call to free)
+and some improvements, including user friendly PIN management.
+
+Compilation
+
+"configure --with-pkcs11 ..."
+
+PKCS#11 Libraries
+
+Tested with Solaris one with a SCA board and with openCryptoki with the
+software token.
+
+OpenSSL Engines
+
+With PKCS#11 support the PKCS#11 engine is statically loaded but at its
+initialization it dynamically loads the PKCS#11 objects.
+Even the pre commands are therefore unused they are defined with:
+ SO_PATH:
+   define: PKCS11_SO_PATH
+   default: /usr/local/lib/engines/engine_pkcs11.so
+ MODULE_PATH:
+   define: PKCS11_MODULE_PATH
+   default: /usr/lib/libpkcs11.so
+Without PKCS#11 support, a specific OpenSSL engine can be still used
+by defining ENGINE_ID at compile time.
+
+PKCS#11 tools
+
+The contrib/pkcs11-keygen directory contains a set of experimental tools
+to handle keys stored in a Hardware Security Module at the benefit of BIND.
+
+The patch for OpenSSL 0.9.8g is in this directory. Read its README.pkcs11
+for the way to use it (these are the original notes so with the original
+path, etc. Define OPENCRYPTOKI to use it with openCryptoki.)
+
+PIN management
+
+With the just fixed PKCS#11 OpenSSL engine, the PIN should be entered
+each time it is required. With the improved engine, the PIN should be
+entered the first time it is required or can be configured in the
+OpenSSL configuration file (aka. openssl.cnf) by adding in it:
+ - at the beginning:
+	openssl_conf = openssl_def
+ - at any place these sections:
+	[ openssl_def ]
+	engines = engine_section
+	[ engine_section ]
+	pkcs11 = pkcs11_section
+	[ pkcs11_section ]
+	PIN = put__your__pin__value__here
+
+Note
+
+Some names here are registered trademarks, at least Solaris is a trademark
+of Sun Microsystems Inc...
diff --git a/contrib/bind9/acconfig.h b/contrib/bind9/acconfig.h
index e8f7d52..eb19150 100644
--- a/contrib/bind9/acconfig.h
+++ b/contrib/bind9/acconfig.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: acconfig.h,v 1.44.18.5 2005/04/29 00:15:20 marka Exp $ */
+/* $Id: acconfig.h,v 1.51.334.2 2009/02/16 23:47:15 tbox Exp $ */
 
 /*! \file */
 
@@ -25,9 +25,6 @@
  ***/
 @TOP@
 
-/** define to `int' if <sys/types.h> doesn't define.  */
-#undef ssize_t
-
 /** define on DEC OSF to enable 4.4BSD style sa_len support */
 #undef _SOCKADDR_LEN
 
@@ -61,9 +58,6 @@
 /** define if you have the NET_RT_IFLIST sysctl variable and sys/sysctl.h */
 #undef HAVE_IFLIST_SYSCTL
 
-/** define if chroot() is available */
-#undef HAVE_CHROOT
-
 /** define if tzset() is available */
 #undef HAVE_TZSET
 
@@ -115,7 +109,7 @@ int sigwait(const unsigned int *set, int *sig);
  * The silly continuation line is to keep configure from
  * commenting out the #undef.
  */
- 
+
 #undef \
 	va_start
 #define	va_start(ap, last) \
diff --git a/contrib/bind9/bin/Makefile.in b/contrib/bind9/bin/Makefile.in
index 2e29f94..ef28e0c 100644
--- a/contrib/bind9/bin/Makefile.in
+++ b/contrib/bind9/bin/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1998-2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.23 2004/03/05 04:57:10 marka Exp $
+# $Id: Makefile.in,v 1.25 2007/06/19 23:46:59 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/bin/check/Makefile.in b/contrib/bind9/bin/check/Makefile.in
index cd9ecf6..06f5541 100644
--- a/contrib/bind9/bin/check/Makefile.in
+++ b/contrib/bind9/bin/check/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2000-2003  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.24.18.6 2006/06/09 00:54:08 marka Exp $
+# $Id: Makefile.in,v 1.32 2007/06/19 23:46:59 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/bin/check/check-tool.c b/contrib/bind9/bin/check/check-tool.c
index 2136a63..e0a7208 100644
--- a/contrib/bind9/bin/check/check-tool.c
+++ b/contrib/bind9/bin/check/check-tool.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: check-tool.c,v 1.10.18.20 2008/10/24 01:43:17 tbox Exp $ */
+/* $Id: check-tool.c,v 1.35.36.3 2009/01/20 02:03:18 marka Exp $ */
 
 /*! \file */
 
@@ -24,16 +24,17 @@
 #include <stdio.h>
 
 #include "check-tool.h"
-#include <isc/util.h>
-
 #include <isc/buffer.h>
 #include <isc/log.h>
-#include <isc/net.h>
+#include <isc/mem.h>
 #include <isc/netdb.h>
+#include <isc/net.h>
 #include <isc/region.h>
 #include <isc/stdio.h>
 #include <isc/string.h>
+#include <isc/symtab.h>
 #include <isc/types.h>
+#include <isc/util.h>
 
 #include <dns/fixedname.h>
 #include <dns/log.h>
@@ -69,6 +70,15 @@
 			goto cleanup; \
 	} while (0)
 
+#define ERR_IS_CNAME 1
+#define ERR_NO_ADDRESSES 2
+#define ERR_LOOKUP_FAILURE 3
+#define ERR_EXTRA_A 4
+#define ERR_EXTRA_AAAA 5
+#define ERR_MISSING_GLUE 5
+#define ERR_IS_MXCNAME 6
+#define ERR_IS_SRVCNAME 7
+
 static const char *dbtype[] = { "rbt" };
 
 int debug = 0;
@@ -105,9 +115,62 @@ static isc_logcategory_t categories[] = {
 	{ "queries",	     0 },
 	{ "unmatched", 	     0 },
 	{ "update-security", 0 },
+	{ "query-errors",    0 },
 	{ NULL,		     0 }
 };
 
+static isc_symtab_t *symtab = NULL;
+static isc_mem_t *sym_mctx;
+
+static void
+freekey(char *key, unsigned int type, isc_symvalue_t value, void *userarg) {
+	UNUSED(type);
+	UNUSED(value);
+	isc_mem_free(userarg, key);
+}
+
+static void
+add(char *key, int value) {
+	isc_result_t result;
+	isc_symvalue_t symvalue;
+
+	if (sym_mctx == NULL) {
+		result = isc_mem_create(0, 0, &sym_mctx);
+		if (result != ISC_R_SUCCESS)
+			return;
+	}
+
+	if (symtab == NULL) {
+		result = isc_symtab_create(sym_mctx, 100, freekey, sym_mctx,
+					   ISC_FALSE, &symtab);
+		if (result != ISC_R_SUCCESS)
+			return;
+	}
+
+	key = isc_mem_strdup(sym_mctx, key);
+	if (key == NULL)
+		return;
+
+	symvalue.as_pointer = NULL;
+	result = isc_symtab_define(symtab, key, value, symvalue,
+				   isc_symexists_reject);
+	if (result != ISC_R_SUCCESS)
+		isc_mem_free(sym_mctx, key);
+}
+
+static isc_boolean_t
+logged(char *key, int value) {
+	isc_result_t result;
+
+	if (symtab == NULL)
+		return (ISC_FALSE);
+
+	result = isc_symtab_lookup(symtab, key, value, NULL);
+	if (result == ISC_R_SUCCESS)
+		return (ISC_TRUE);
+	return (ISC_FALSE);
+}
+
 static isc_boolean_t
 checkns(dns_zone_t *zone, dns_name_t *name, dns_name_t *owner,
 	dns_rdataset_t *a, dns_rdataset_t *aaaa)
@@ -156,29 +219,39 @@ checkns(dns_zone_t *zone, dns_name_t *name, dns_name_t *owner,
 		       cur->ai_next != NULL)
 			cur = cur->ai_next;
 		if (cur != NULL && cur->ai_canonname != NULL &&
-		    strcasecmp(ai->ai_canonname, namebuf) != 0) {
+		    strcasecmp(cur->ai_canonname, namebuf) != 0 &&
+		    !logged(namebuf, ERR_IS_CNAME)) {
 			dns_zone_log(zone, ISC_LOG_ERROR,
 				     "%s/NS '%s' (out of zone) "
-				     "is a CNAME (illegal)",
-				     ownerbuf, namebuf);
+				     "is a CNAME '%s' (illegal)",
+				     ownerbuf, namebuf,
+				     cur->ai_canonname);
 			/* XXX950 make fatal for 9.5.0 */
 			/* answer = ISC_FALSE; */
+			add(namebuf, ERR_IS_CNAME);
 		}
 		break;
 	case EAI_NONAME:
 #if defined(EAI_NODATA) && (EAI_NODATA != EAI_NONAME)
 	case EAI_NODATA:
 #endif
-		dns_zone_log(zone, ISC_LOG_ERROR, "%s/NS '%s' (out of zone) "
-			     "has no addresses records (A or AAAA)",
-			     ownerbuf, namebuf);
+		if (!logged(namebuf, ERR_NO_ADDRESSES)) {
+			dns_zone_log(zone, ISC_LOG_ERROR,
+				     "%s/NS '%s' (out of zone) "
+				     "has no addresses records (A or AAAA)",
+				     ownerbuf, namebuf);
+			add(namebuf, ERR_NO_ADDRESSES);
+		}
 		/* XXX950 make fatal for 9.5.0 */
 		return (ISC_TRUE);
 
 	default:
-		dns_zone_log(zone, ISC_LOG_WARNING,
-			     "getaddrinfo(%s) failed: %s",
-			     namebuf, gai_strerror(result));
+		if (!logged(namebuf, ERR_LOOKUP_FAILURE)) {
+			dns_zone_log(zone, ISC_LOG_WARNING,
+				     "getaddrinfo(%s) failed: %s",
+				     namebuf, gai_strerror(result));
+			add(namebuf, ERR_LOOKUP_FAILURE);
+		}
 		return (ISC_TRUE);
 	}
 	if (a == NULL || aaaa == NULL)
@@ -201,12 +274,13 @@ checkns(dns_zone_t *zone, dns_name_t *name, dns_name_t *owner,
 				break;
 			}
 		}
-		if (!match) {
+		if (!match && !logged(namebuf, ERR_EXTRA_A)) {
 			dns_zone_log(zone, ISC_LOG_ERROR, "%s/NS '%s' "
 				     "extra GLUE A record (%s)",
 				     ownerbuf, namebuf,
 				     inet_ntop(AF_INET, rdata.data,
 					       addrbuf, sizeof(addrbuf)));
+			add(namebuf, ERR_EXTRA_A);
 			/* XXX950 make fatal for 9.5.0 */
 			/* answer = ISC_FALSE; */
 		}
@@ -230,12 +304,13 @@ checkns(dns_zone_t *zone, dns_name_t *name, dns_name_t *owner,
 				break;
 			}
 		}
-		if (!match) {
+		if (!match && !logged(namebuf, ERR_EXTRA_AAAA)) {
 			dns_zone_log(zone, ISC_LOG_ERROR, "%s/NS '%s' "
 				     "extra GLUE AAAA record (%s)",
 				     ownerbuf, namebuf,
 				     inet_ntop(AF_INET6, rdata.data,
 					       addrbuf, sizeof(addrbuf)));
+			add(namebuf, ERR_EXTRA_AAAA);
 			/* XXX950 make fatal for 9.5.0. */
 			/* answer = ISC_FALSE; */
 		}
@@ -247,42 +322,48 @@ checkns(dns_zone_t *zone, dns_name_t *name, dns_name_t *owner,
 	/*
 	 * Check that all addresses appear in the glue.
 	 */
-	for (cur = ai; cur != NULL; cur = cur->ai_next) {
-		switch (cur->ai_family) {
-		case AF_INET:
-			rdataset = a;
-			ptr = &((struct sockaddr_in *)(cur->ai_addr))->sin_addr;
-			type = "A";
-			break;
-		case AF_INET6:
-			rdataset = aaaa;
-			ptr = &((struct sockaddr_in6 *)(cur->ai_addr))->sin6_addr;
-			type = "AAAA";
-			break;
-		default:
-			 continue;
-		}
-		match = ISC_FALSE;
-		if (dns_rdataset_isassociated(rdataset))
-			result = dns_rdataset_first(rdataset);
-		else
-			result = ISC_R_FAILURE;
-		while (result == ISC_R_SUCCESS && !match) {
-			dns_rdataset_current(rdataset, &rdata);
-			if (memcmp(ptr, rdata.data, rdata.length) == 0)
-				match = ISC_TRUE;
-			dns_rdata_reset(&rdata);
-			result = dns_rdataset_next(rdataset);
-		}
-		if (!match) {
-			dns_zone_log(zone, ISC_LOG_ERROR, "%s/NS '%s' "
-				     "missing GLUE %s record (%s)",
-				     ownerbuf, namebuf, type,
-				     inet_ntop(cur->ai_family, ptr,
-					       addrbuf, sizeof(addrbuf)));
-			/* XXX950 make fatal for 9.5.0. */
-			/* answer = ISC_FALSE; */
+	if (!logged(namebuf, ERR_MISSING_GLUE)) {
+		isc_boolean_t missing_glue = ISC_FALSE;
+		for (cur = ai; cur != NULL; cur = cur->ai_next) {
+			switch (cur->ai_family) {
+			case AF_INET:
+				rdataset = a;
+				ptr = &((struct sockaddr_in *)(cur->ai_addr))->sin_addr;
+				type = "A";
+				break;
+			case AF_INET6:
+				rdataset = aaaa;
+				ptr = &((struct sockaddr_in6 *)(cur->ai_addr))->sin6_addr;
+				type = "AAAA";
+				break;
+			default:
+				 continue;
+			}
+			match = ISC_FALSE;
+			if (dns_rdataset_isassociated(rdataset))
+				result = dns_rdataset_first(rdataset);
+			else
+				result = ISC_R_FAILURE;
+			while (result == ISC_R_SUCCESS && !match) {
+				dns_rdataset_current(rdataset, &rdata);
+				if (memcmp(ptr, rdata.data, rdata.length) == 0)
+					match = ISC_TRUE;
+				dns_rdata_reset(&rdata);
+				result = dns_rdataset_next(rdataset);
+			}
+			if (!match) {
+				dns_zone_log(zone, ISC_LOG_ERROR, "%s/NS '%s' "
+					     "missing GLUE %s record (%s)",
+					     ownerbuf, namebuf, type,
+					     inet_ntop(cur->ai_family, ptr,
+						       addrbuf, sizeof(addrbuf)));
+				/* XXX950 make fatal for 9.5.0. */
+				/* answer = ISC_FALSE; */
+				missing_glue = ISC_TRUE;
+			}
 		}
+		if (missing_glue)
+			add(namebuf, ERR_MISSING_GLUE);
 	}
 	freeaddrinfo(ai);
 	return (answer);
@@ -332,10 +413,15 @@ checkmx(dns_zone_t *zone, dns_name_t *name, dns_name_t *owner) {
 			if ((zone_options & DNS_ZONEOPT_WARNMXCNAME) != 0)
 				level = ISC_LOG_WARNING;
 			if ((zone_options & DNS_ZONEOPT_IGNOREMXCNAME) == 0) {
-				dns_zone_log(zone, ISC_LOG_WARNING,
-					     "%s/MX '%s' (out of zone) "
-					     "is a CNAME (illegal)",
-					     ownerbuf, namebuf);
+				if (!logged(namebuf, ERR_IS_MXCNAME)) {
+					dns_zone_log(zone, level,
+						     "%s/MX '%s' (out of zone)"
+						     " is a CNAME '%s' "
+						     "(illegal)",
+						     ownerbuf, namebuf,
+						     cur->ai_canonname);
+					add(namebuf, ERR_IS_MXCNAME);
+				}
 				if (level == ISC_LOG_ERROR)
 					answer = ISC_FALSE;
 			}
@@ -347,16 +433,23 @@ checkmx(dns_zone_t *zone, dns_name_t *name, dns_name_t *owner) {
 #if defined(EAI_NODATA) && (EAI_NODATA != EAI_NONAME)
 	case EAI_NODATA:
 #endif
-		dns_zone_log(zone, ISC_LOG_ERROR, "%s/MX '%s' (out of zone) "
-			     "has no addresses records (A or AAAA)",
-			     ownerbuf, namebuf);
+		if (!logged(namebuf, ERR_NO_ADDRESSES)) {
+			dns_zone_log(zone, ISC_LOG_ERROR,
+				     "%s/MX '%s' (out of zone) "
+				     "has no addresses records (A or AAAA)",
+				     ownerbuf, namebuf);
+			add(namebuf, ERR_NO_ADDRESSES);
+		}
 		/* XXX950 make fatal for 9.5.0. */
 		return (ISC_TRUE);
 
 	default:
-		dns_zone_log(zone, ISC_LOG_WARNING,
+		if (!logged(namebuf, ERR_LOOKUP_FAILURE)) {
+			dns_zone_log(zone, ISC_LOG_WARNING,
 			     "getaddrinfo(%s) failed: %s",
 			     namebuf, gai_strerror(result));
+			add(namebuf, ERR_LOOKUP_FAILURE);
+		}
 		return (ISC_TRUE);
 	}
 #else
@@ -405,10 +498,14 @@ checksrv(dns_zone_t *zone, dns_name_t *name, dns_name_t *owner) {
 			if ((zone_options & DNS_ZONEOPT_WARNSRVCNAME) != 0)
 				level = ISC_LOG_WARNING;
 			if ((zone_options & DNS_ZONEOPT_IGNORESRVCNAME) == 0) {
-				dns_zone_log(zone, level,
-					     "%s/SRV '%s' (out of zone) "
-					     "is a CNAME (illegal)",
-					     ownerbuf, namebuf);
+				if (!logged(namebuf, ERR_IS_SRVCNAME)) {
+					dns_zone_log(zone, level, "%s/SRV '%s'"
+						     " (out of zone) is a "
+						     "CNAME '%s' (illegal)",
+						     ownerbuf, namebuf,
+						     cur->ai_canonname);
+					add(namebuf, ERR_IS_SRVCNAME);
+				}
 				if (level == ISC_LOG_ERROR)
 					answer = ISC_FALSE;
 			}
@@ -420,16 +517,23 @@ checksrv(dns_zone_t *zone, dns_name_t *name, dns_name_t *owner) {
 #if defined(EAI_NODATA) && (EAI_NODATA != EAI_NONAME)
 	case EAI_NODATA:
 #endif
-		dns_zone_log(zone, ISC_LOG_ERROR, "%s/SRV '%s' (out of zone) "
-			     "has no addresses records (A or AAAA)",
-			     ownerbuf, namebuf);
+		if (!logged(namebuf, ERR_NO_ADDRESSES)) {
+			dns_zone_log(zone, ISC_LOG_ERROR,
+				     "%s/SRV '%s' (out of zone) "
+				     "has no addresses records (A or AAAA)",
+				     ownerbuf, namebuf);
+			add(namebuf, ERR_NO_ADDRESSES);
+		}
 		/* XXX950 make fatal for 9.5.0. */
 		return (ISC_TRUE);
 
 	default:
-		dns_zone_log(zone, ISC_LOG_WARNING,
-			     "getaddrinfo(%s) failed: %s",
-			     namebuf, gai_strerror(result));
+		if (!logged(namebuf, ERR_LOOKUP_FAILURE)) {
+			dns_zone_log(zone, ISC_LOG_WARNING,
+				     "getaddrinfo(%s) failed: %s",
+				     namebuf, gai_strerror(result));
+			add(namebuf, ERR_LOOKUP_FAILURE);
+		}
 		return (ISC_TRUE);
 	}
 #else
@@ -438,7 +542,7 @@ checksrv(dns_zone_t *zone, dns_name_t *name, dns_name_t *owner) {
 }
 
 isc_result_t
-setup_logging(isc_mem_t *mctx, isc_log_t **logp) {
+setup_logging(isc_mem_t *mctx, FILE *errout, isc_log_t **logp) {
 	isc_logdestination_t destination;
 	isc_logconfig_t *logconfig = NULL;
 	isc_log_t *log = NULL;
@@ -450,7 +554,7 @@ setup_logging(isc_mem_t *mctx, isc_log_t **logp) {
 	dns_log_setcontext(log);
 	cfg_log_init(log);
 
-	destination.file.stream = stdout;
+	destination.file.stream = errout;
 	destination.file.name = NULL;
 	destination.file.versions = ISC_LOG_ROLLNEVER;
 	destination.file.maximum_size = 0;
@@ -534,14 +638,14 @@ dump_zone(const char *zonename, dns_zone_t *zone, const char *filename,
 	FILE *output = stdout;
 
 	if (debug) {
-		if (filename != NULL)
+		if (filename != NULL && strcmp(filename, "-") != 0)
 			fprintf(stderr, "dumping \"%s\" to \"%s\"\n",
 				zonename, filename);
 		else
 			fprintf(stderr, "dumping \"%s\"\n", zonename);
 	}
 
-	if (filename != NULL) {
+	if (filename != NULL && strcmp(filename, "-") != 0) {
 		result = isc_stdio_open(filename, "w+", &output);
 
 		if (result != ISC_R_SUCCESS) {
@@ -553,7 +657,7 @@ dump_zone(const char *zonename, dns_zone_t *zone, const char *filename,
 
 	result = dns_zone_dumptostream2(zone, output, fileformat, style);
 
-	if (filename != NULL)
+	if (output != stdout)
 		(void)isc_stdio_close(output);
 
 	return (result);
diff --git a/contrib/bind9/bin/check/check-tool.h b/contrib/bind9/bin/check/check-tool.h
index ef9017f..b0ba7e0 100644
--- a/contrib/bind9/bin/check/check-tool.h
+++ b/contrib/bind9/bin/check/check-tool.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: check-tool.h,v 1.7.18.4 2005/06/20 01:19:25 marka Exp $ */
+/* $Id: check-tool.h,v 1.14 2007/06/18 23:47:17 tbox Exp $ */
 
 #ifndef CHECK_TOOL_H
 #define CHECK_TOOL_H
@@ -23,6 +23,7 @@
 /*! \file */
 
 #include <isc/lang.h>
+#include <isc/stdio.h>
 #include <isc/types.h>
 
 #include <dns/masterdump.h>
@@ -31,7 +32,7 @@
 ISC_LANG_BEGINDECLS
 
 isc_result_t
-setup_logging(isc_mem_t *mctx, isc_log_t **logp);
+setup_logging(isc_mem_t *mctx, FILE *errout, isc_log_t **logp);
 
 isc_result_t
 load_zone(isc_mem_t *mctx, const char *zonename, const char *filename,
diff --git a/contrib/bind9/bin/check/named-checkconf.8 b/contrib/bind9/bin/check/named-checkconf.8
index 364e6b9..852b133 100644
--- a/contrib/bind9/bin/check/named-checkconf.8
+++ b/contrib/bind9/bin/check/named-checkconf.8
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: named-checkconf.8,v 1.16.18.13 2007/06/20 02:26:58 marka Exp $
+.\" $Id: named-checkconf.8,v 1.30 2007/06/20 02:27:32 marka Exp $
 .\"
 .hy 0
 .ad l
@@ -33,13 +33,18 @@
 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]
+\fBnamed\-checkconf\fR [\fB\-h\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.
 .SH "OPTIONS"
 .PP
+\-h
+.RS 4
+Print the usage summary and exit.
+.RE
+.PP
 \-t \fIdirectory\fR
 .RS 4
 Chroot to
diff --git a/contrib/bind9/bin/check/named-checkconf.c b/contrib/bind9/bin/check/named-checkconf.c
index 96efd79..eba0d93 100644
--- a/contrib/bind9/bin/check/named-checkconf.c
+++ b/contrib/bind9/bin/check/named-checkconf.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: named-checkconf.c,v 1.28.18.16 2007/11/26 23:46:18 tbox Exp $ */
+/* $Id: named-checkconf.c,v 1.46.222.2 2009/02/16 23:47:15 tbox Exp $ */
 
 /*! \file */
 
@@ -47,6 +47,8 @@
 
 #include "check-tool.h"
 
+static const char *program = "named-checkconf";
+
 isc_log_t *logc = NULL;
 
 #define CHECK(r)\
@@ -59,9 +61,9 @@ isc_log_t *logc = NULL;
 /*% usage */
 static void
 usage(void) {
-        fprintf(stderr, "usage: named-checkconf [-j] [-v] [-z] [-t directory] "
-		"[named.conf]\n");
-        exit(1);
+	fprintf(stderr, "usage: %s [-h] [-j] [-v] [-z] [-t directory] "
+		"[named.conf]\n", program);
+	exit(1);
 }
 
 /*% directory callback */
@@ -171,9 +173,9 @@ configure_zone(const char *vclass, const char *view,
 
 	zname = cfg_obj_asstring(cfg_tuple_get(zconfig, "name"));
 	classobj = cfg_tuple_get(zconfig, "class");
-        if (!cfg_obj_isstring(classobj))
-                zclass = vclass;
-        else
+	if (!cfg_obj_isstring(classobj))
+		zclass = vclass;
+	else
 		zclass = cfg_obj_asstring(classobj);
 
 	zoptions = cfg_tuple_get(zconfig, "options");
@@ -192,9 +194,9 @@ configure_zone(const char *vclass, const char *view,
 		return (ISC_R_FAILURE);
 	if (strcasecmp(cfg_obj_asstring(typeobj), "master") != 0)
 		return (ISC_R_SUCCESS);
-        cfg_map_get(zoptions, "database", &dbobj);
-        if (dbobj != NULL)
-                return (ISC_R_SUCCESS);
+	cfg_map_get(zoptions, "database", &dbobj);
+	if (dbobj != NULL)
+		return (ISC_R_SUCCESS);
 	cfg_map_get(zoptions, "file", &fileobj);
 	if (fileobj == NULL)
 		return (ISC_R_FAILURE);
@@ -285,8 +287,8 @@ configure_zone(const char *vclass, const char *view,
 		} else
 			INSIST(0);
 	} else {
-               zone_options |= DNS_ZONEOPT_CHECKNAMES;
-               zone_options |= DNS_ZONEOPT_CHECKNAMESFAIL;
+	       zone_options |= DNS_ZONEOPT_CHECKNAMES;
+	       zone_options |= DNS_ZONEOPT_CHECKNAMESFAIL;
 	}
 
 	masterformat = dns_masterformat_text;
@@ -397,8 +399,10 @@ main(int argc, char **argv) {
 	int exit_status = 0;
 	isc_entropy_t *ectx = NULL;
 	isc_boolean_t load_zones = ISC_FALSE;
-	
-	while ((c = isc_commandline_parse(argc, argv, "djt:vz")) != EOF) {
+
+	isc_commandline_errprint = ISC_FALSE;
+
+	while ((c = isc_commandline_parse(argc, argv, "dhjt:vz")) != EOF) {
 		switch (c) {
 		case 'd':
 			debug++;
@@ -415,12 +419,6 @@ main(int argc, char **argv) {
 					isc_result_totext(result));
 				exit(1);
 			}
-			result = isc_dir_chdir("/");
-			if (result != ISC_R_SUCCESS) {
-				fprintf(stderr, "isc_dir_chdir: %s\n",
-					isc_result_totext(result));
-				exit(1);
-			}
 			break;
 
 		case 'v':
@@ -434,11 +432,22 @@ main(int argc, char **argv) {
 			dochecksrv = ISC_FALSE;
 			break;
 
-		default:
+		case '?':
+			if (isc_commandline_option != '?')
+				fprintf(stderr, "%s: invalid argument -%c\n",
+					program, isc_commandline_option);
+		case 'h':
 			usage();
+
+		default:
+			fprintf(stderr, "%s: unhandled option -%c\n",
+				program, isc_commandline_option);
+			exit(1);
 		}
 	}
 
+	if (isc_commandline_index + 1 < argc)
+		usage();
 	if (argv[isc_commandline_index] != NULL)
 		conffile = argv[isc_commandline_index];
 	if (conffile == NULL || conffile[0] == '\0')
@@ -446,7 +455,7 @@ main(int argc, char **argv) {
 
 	RUNTIME_CHECK(isc_mem_create(0, 0, &mctx) == ISC_R_SUCCESS);
 
-	RUNTIME_CHECK(setup_logging(mctx, &logc) == ISC_R_SUCCESS);
+	RUNTIME_CHECK(setup_logging(mctx, stdout, &logc) == ISC_R_SUCCESS);
 
 	RUNTIME_CHECK(isc_entropy_create(mctx, &ectx) == ISC_R_SUCCESS);
 	RUNTIME_CHECK(isc_hash_create(mctx, ectx, DNS_NAME_MAXWIRE)
diff --git a/contrib/bind9/bin/check/named-checkconf.docbook b/contrib/bind9/bin/check/named-checkconf.docbook
index af7a73d..5359239 100644
--- a/contrib/bind9/bin/check/named-checkconf.docbook
+++ b/contrib/bind9/bin/check/named-checkconf.docbook
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: named-checkconf.docbook,v 1.8.18.10 2007/08/28 07:19:55 tbox Exp $ -->
+<!-- $Id: named-checkconf.docbook,v 1.19 2007/06/19 06:58:03 marka Exp $ -->
 <refentry id="man.named-checkconf">
   <refentryinfo>
     <date>June 14, 2000</date>
@@ -53,6 +53,7 @@
   <refsynopsisdiv>
     <cmdsynopsis>
       <command>named-checkconf</command>
+      <arg><option>-h</option></arg>
       <arg><option>-v</option></arg>
       <arg><option>-j</option></arg>
       <arg><option>-t <replaceable class="parameter">directory</replaceable></option></arg>
@@ -74,6 +75,15 @@
 
     <variablelist>
       <varlistentry>
+        <term>-h</term>
+        <listitem>
+          <para>
+            Print the usage summary and exit.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
         <term>-t <replaceable class="parameter">directory</replaceable></term>
         <listitem>
           <para>
diff --git a/contrib/bind9/bin/check/named-checkconf.html b/contrib/bind9/bin/check/named-checkconf.html
index 910df0d..34bec80 100644
--- a/contrib/bind9/bin/check/named-checkconf.html
+++ b/contrib/bind9/bin/check/named-checkconf.html
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: named-checkconf.html,v 1.9.18.20 2007/06/20 02:26:58 marka Exp $ -->
+<!-- $Id: named-checkconf.html,v 1.30 2007/06/20 02:27:32 marka Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -29,18 +29,22 @@
 </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 class="cmdsynopsis"><p><code class="command">named-checkconf</code>  [<code class="option">-h</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="id2543383"></a><h2>DESCRIPTION</h2>
+<a name="id2543387"></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" lang="en">
-<a name="id2543395"></a><h2>OPTIONS</h2>
+<a name="id2543399"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
+<dt><span class="term">-h</span></dt>
+<dd><p>
+            Print the usage summary and exit.
+          </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
@@ -70,21 +74,21 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2543489"></a><h2>RETURN VALUES</h2>
+<a name="id2543507"></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" lang="en">
-<a name="id2543500"></a><h2>SEE ALSO</h2>
+<a name="id2543518"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
       <span class="citerefentry"><span class="refentrytitle">named-checkzone</span>(8)</span>,
       <em class="citetitle">BIND 9 Administrator Reference Manual</em>.
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2543530"></a><h2>AUTHOR</h2>
+<a name="id2543548"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
diff --git a/contrib/bind9/bin/check/named-checkzone.8 b/contrib/bind9/bin/check/named-checkzone.8
index bd538ac..5520da3 100644
--- a/contrib/bind9/bin/check/named-checkzone.8
+++ b/contrib/bind9/bin/check/named-checkzone.8
@@ -1,4 +1,4 @@
-.\" Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2004-2007, 2009 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: named-checkzone.8,v 1.18.18.23 2007/06/20 02:26:58 marka Exp $
+.\" $Id: named-checkzone.8,v 1.42.334.1 2009/01/23 01:53:33 tbox Exp $
 .\"
 .hy 0
 .ad l
@@ -33,7 +33,7 @@
 named\-checkzone, named\-compilezone \- zone file validity checking or converting 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\-f\ \fR\fB\fIformat\fR\fR] [\fB\-F\ \fR\fB\fIformat\fR\fR] [\fB\-i\ \fR\fB\fImode\fR\fR] [\fB\-k\ \fR\fB\fImode\fR\fR] [\fB\-m\ \fR\fB\fImode\fR\fR] [\fB\-M\ \fR\fB\fImode\fR\fR] [\fB\-n\ \fR\fB\fImode\fR\fR] [\fB\-o\ \fR\fB\fIfilename\fR\fR] [\fB\-s\ \fR\fB\fIstyle\fR\fR] [\fB\-S\ \fR\fB\fImode\fR\fR] [\fB\-t\ \fR\fB\fIdirectory\fR\fR] [\fB\-w\ \fR\fB\fIdirectory\fR\fR] [\fB\-D\fR] [\fB\-W\ \fR\fB\fImode\fR\fR] {zonename} {filename}
+\fBnamed\-checkzone\fR [\fB\-d\fR] [\fB\-h\fR] [\fB\-j\fR] [\fB\-q\fR] [\fB\-v\fR] [\fB\-c\ \fR\fB\fIclass\fR\fR] [\fB\-f\ \fR\fB\fIformat\fR\fR] [\fB\-F\ \fR\fB\fIformat\fR\fR] [\fB\-i\ \fR\fB\fImode\fR\fR] [\fB\-k\ \fR\fB\fImode\fR\fR] [\fB\-m\ \fR\fB\fImode\fR\fR] [\fB\-M\ \fR\fB\fImode\fR\fR] [\fB\-n\ \fR\fB\fImode\fR\fR] [\fB\-o\ \fR\fB\fIfilename\fR\fR] [\fB\-s\ \fR\fB\fIstyle\fR\fR] [\fB\-S\ \fR\fB\fImode\fR\fR] [\fB\-t\ \fR\fB\fIdirectory\fR\fR] [\fB\-w\ \fR\fB\fIdirectory\fR\fR] [\fB\-D\fR] [\fB\-W\ \fR\fB\fImode\fR\fR] {zonename} {filename}
 .HP 18
 \fBnamed\-compilezone\fR [\fB\-d\fR] [\fB\-j\fR] [\fB\-q\fR] [\fB\-v\fR] [\fB\-c\ \fR\fB\fIclass\fR\fR] [\fB\-C\ \fR\fB\fImode\fR\fR] [\fB\-f\ \fR\fB\fIformat\fR\fR] [\fB\-F\ \fR\fB\fIformat\fR\fR] [\fB\-i\ \fR\fB\fImode\fR\fR] [\fB\-k\ \fR\fB\fImode\fR\fR] [\fB\-m\ \fR\fB\fImode\fR\fR] [\fB\-n\ \fR\fB\fImode\fR\fR] [\fB\-o\ \fR\fB\fIfilename\fR\fR] [\fB\-s\ \fR\fB\fIstyle\fR\fR] [\fB\-t\ \fR\fB\fIdirectory\fR\fR] [\fB\-w\ \fR\fB\fIdirectory\fR\fR] [\fB\-D\fR] [\fB\-W\ \fR\fB\fImode\fR\fR] {zonename} {filename}
 .SH "DESCRIPTION"
@@ -58,6 +58,11 @@ configuration file.
 Enable debugging.
 .RE
 .PP
+\-h
+.RS 4
+Print the usage summary and exit.
+.RE
+.PP
 \-q
 .RS 4
 Quiet mode \- exit code only.
@@ -77,7 +82,7 @@ When loading the zone file read the journal if it exists.
 .PP
 \-c \fIclass\fR
 .RS 4
-Specify the class of the zone. If not specified "IN" is assumed.
+Specify the class of the zone. If not specified, "IN" is assumed.
 .RE
 .PP
 \-i \fImode\fR
@@ -188,7 +193,11 @@ Specify whether NS records should be checked to see if they are addresses. Possi
 \-o \fIfilename\fR
 .RS 4
 Write zone output to
-\fIfilename\fR. This is mandatory for
+\fIfilename\fR. If
+\fIfilename\fR
+is
+\fI\-\fR
+then write to standard out. This is mandatory for
 \fBnamed\-compilezone\fR.
 .RE
 .PP
@@ -263,7 +272,7 @@ BIND 9 Administrator Reference Manual.
 .PP
 Internet Systems Consortium
 .SH "COPYRIGHT"
-Copyright \(co 2004\-2007 Internet Systems Consortium, Inc. ("ISC")
+Copyright \(co 2004\-2007, 2009 Internet Systems Consortium, Inc. ("ISC")
 .br
 Copyright \(co 2000\-2002 Internet Software Consortium.
 .br
diff --git a/contrib/bind9/bin/check/named-checkzone.c b/contrib/bind9/bin/check/named-checkzone.c
index f16053b..e91cbea 100644
--- a/contrib/bind9/bin/check/named-checkzone.c
+++ b/contrib/bind9/bin/check/named-checkzone.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: named-checkzone.c,v 1.29.18.21 2008/10/24 01:43:17 tbox Exp $ */
+/* $Id: named-checkzone.c,v 1.51.34.2 2009/02/16 23:47:15 tbox Exp $ */
 
 /*! \file */
 
@@ -106,6 +106,7 @@ main(int argc, char **argv) {
 	const char *outputformatstr = NULL;
 	dns_masterformat_t inputformat = dns_masterformat_text;
 	dns_masterformat_t outputformat = dns_masterformat_text;
+	FILE *errout = stdout;
 
 	outputstyle = &dns_master_style_full;
 
@@ -140,8 +141,10 @@ main(int argc, char **argv) {
 
 #define ARGCMP(X) (strcmp(isc_commandline_argument, X) == 0)
 
+	isc_commandline_errprint = ISC_FALSE;
+
 	while ((c = isc_commandline_parse(argc, argv,
-					  "c:df:i:jk:m:n:qs:t:o:vw:DF:M:S:W:"))
+					 "c:df:hi:jk:m:n:qs:t:o:vw:DF:M:S:W:"))
 	       != EOF) {
 		switch (c) {
 		case 'c':
@@ -265,12 +268,6 @@ main(int argc, char **argv) {
 					isc_result_totext(result));
 				exit(1);
 			}
-			result = isc_dir_chdir("/");
-			if (result != ISC_R_SUCCESS) {
-				fprintf(stderr, "isc_dir_chdir: %s\n",
-					isc_result_totext(result));
-				exit(1);
-			}
 			break;
 
 		case 's':
@@ -343,17 +340,17 @@ main(int argc, char **argv) {
 				zone_options &= ~DNS_ZONEOPT_CHECKWILDCARD;
 			break;
 
-		default:
+		case '?':
+			if (isc_commandline_option != '?')
+				fprintf(stderr, "%s: invalid argument -%c\n",
+					prog_name, isc_commandline_option);
+		case 'h':
 			usage();
-		}
-	}
 
-	if (progmode == progmode_compile) {
-		dumpzone = 1;	/* always dump */
-		if (output_filename == NULL) {
-			fprintf(stderr,
-				"output file required, but not specified\n");
-			usage();
+		default:
+			fprintf(stderr, "%s: unhandled option -%c\n",
+				prog_name, isc_commandline_option);
+			exit(1);
 		}
 	}
 
@@ -390,12 +387,36 @@ main(int argc, char **argv) {
 		}
 	}
 
-	if (isc_commandline_index + 2 > argc)
+	if (progmode == progmode_compile) {
+		dumpzone = 1;	/* always dump */
+		if (output_filename == NULL) {
+			fprintf(stderr,
+				"output file required, but not specified\n");
+			usage();
+		}
+	}
+
+	if (output_filename != NULL)
+		dumpzone = 1;
+
+	/*
+	 * If we are outputing to stdout then send the informational
+	 * output to stderr.
+	 */
+	if (dumpzone &&
+	    (output_filename == NULL ||
+	     strcmp(output_filename, "-") == 0 ||
+	     strcmp(output_filename, "/dev/fd/1") == 0 ||
+	     strcmp(output_filename, "/dev/stdout") == 0))
+		errout = stderr;
+
+	if (isc_commandline_index + 2 != argc)
 		usage();
 
 	RUNTIME_CHECK(isc_mem_create(0, 0, &mctx) == ISC_R_SUCCESS);
 	if (!quiet)
-		RUNTIME_CHECK(setup_logging(mctx, &lctx) == ISC_R_SUCCESS);
+		RUNTIME_CHECK(setup_logging(mctx, errout, &lctx)
+			      == ISC_R_SUCCESS);
 	RUNTIME_CHECK(isc_entropy_create(mctx, &ectx) == ISC_R_SUCCESS);
 	RUNTIME_CHECK(isc_hash_create(mctx, ectx, DNS_NAME_MAXWIRE)
 		      == ISC_R_SUCCESS);
@@ -409,17 +430,17 @@ main(int argc, char **argv) {
 
 	if (result == ISC_R_SUCCESS && dumpzone) {
 		if (!quiet && progmode == progmode_compile) {
-			fprintf(stdout, "dump zone to %s...", output_filename);
-			fflush(stdout);
+			fprintf(errout, "dump zone to %s...", output_filename);
+			fflush(errout);
 		}
 		result = dump_zone(origin, zone, output_filename,
 				   outputformat, outputstyle);
 		if (!quiet && progmode == progmode_compile)
-			fprintf(stdout, "done\n");
+			fprintf(errout, "done\n");
 	}
 
 	if (!quiet && result == ISC_R_SUCCESS)
-		fprintf(stdout, "OK\n");
+		fprintf(errout, "OK\n");
 	destroy();
 	if (lctx != NULL)
 		isc_log_destroy(&lctx);
diff --git a/contrib/bind9/bin/check/named-checkzone.docbook b/contrib/bind9/bin/check/named-checkzone.docbook
index 11b85ef..d863447 100644
--- a/contrib/bind9/bin/check/named-checkzone.docbook
+++ b/contrib/bind9/bin/check/named-checkzone.docbook
@@ -2,7 +2,7 @@
                "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
 	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2002  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: named-checkzone.docbook,v 1.11.18.21 2007/08/28 07:19:55 tbox Exp $ -->
+<!-- $Id: named-checkzone.docbook,v 1.34.334.2 2009/01/22 23:47:04 tbox Exp $ -->
 <refentry id="man.named-checkzone">
   <refentryinfo>
     <date>June 13, 2000</date>
@@ -36,6 +36,7 @@
       <year>2005</year>
       <year>2006</year>
       <year>2007</year>
+      <year>2009</year>
       <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
     </copyright>
     <copyright>
@@ -56,6 +57,7 @@
     <cmdsynopsis>
       <command>named-checkzone</command>
       <arg><option>-d</option></arg>
+      <arg><option>-h</option></arg>
       <arg><option>-j</option></arg>
       <arg><option>-q</option></arg>
       <arg><option>-v</option></arg>
@@ -137,6 +139,15 @@
       </varlistentry>
 
       <varlistentry>
+        <term>-h</term>
+        <listitem>
+          <para>
+            Print the usage summary and exit.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
         <term>-q</term>
         <listitem>
           <para>
@@ -168,7 +179,7 @@
         <term>-c <replaceable class="parameter">class</replaceable></term>
         <listitem>
           <para>
-            Specify the class of the zone.  If not specified "IN" is assumed.
+            Specify the class of the zone.  If not specified, "IN" is assumed.
           </para>
         </listitem>
       </varlistentry>
@@ -301,6 +312,8 @@
         <listitem>
           <para>
             Write zone output to <filename>filename</filename>.
+	    If <filename>filename</filename> is <filename>-</filename> then
+	    write to standard out.
 	    This is mandatory for <command>named-compilezone</command>.
           </para>
         </listitem>
diff --git a/contrib/bind9/bin/check/named-checkzone.html b/contrib/bind9/bin/check/named-checkzone.html
index 0e1015d..71dc445 100644
--- a/contrib/bind9/bin/check/named-checkzone.html
+++ b/contrib/bind9/bin/check/named-checkzone.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2007 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2007, 2009 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2002 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: named-checkzone.html,v 1.11.18.30 2007/06/20 02:26:58 marka Exp $ -->
+<!-- $Id: named-checkzone.html,v 1.42.334.1 2009/01/23 01:53:33 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -29,11 +29,11 @@
 </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">-f <em class="replaceable"><code>format</code></em></code>] [<code class="option">-F <em class="replaceable"><code>format</code></em></code>] [<code class="option">-i <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-k <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-m <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-M <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">-s <em class="replaceable"><code>style</code></em></code>] [<code class="option">-S <em class="replaceable"><code>mode</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>] [<code class="option">-W <em class="replaceable"><code>mode</code></em></code>] {zonename} {filename}</p></div>
+<div class="cmdsynopsis"><p><code class="command">named-checkzone</code>  [<code class="option">-d</code>] [<code class="option">-h</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">-f <em class="replaceable"><code>format</code></em></code>] [<code class="option">-F <em class="replaceable"><code>format</code></em></code>] [<code class="option">-i <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-k <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-m <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-M <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">-s <em class="replaceable"><code>style</code></em></code>] [<code class="option">-S <em class="replaceable"><code>mode</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>] [<code class="option">-W <em class="replaceable"><code>mode</code></em></code>] {zonename} {filename}</p></div>
 <div class="cmdsynopsis"><p><code class="command">named-compilezone</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">-C <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-f <em class="replaceable"><code>format</code></em></code>] [<code class="option">-F <em class="replaceable"><code>format</code></em></code>] [<code class="option">-i <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-k <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-m <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">-s <em class="replaceable"><code>style</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>] [<code class="option">-W <em class="replaceable"><code>mode</code></em></code>] {zonename} {filename}</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2543665"></a><h2>DESCRIPTION</h2>
+<a name="id2543672"></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
@@ -53,12 +53,16 @@
      </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2543700"></a><h2>OPTIONS</h2>
+<a name="id2543707"></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">-h</span></dt>
+<dd><p>
+            Print the usage summary and exit.
+          </p></dd>
 <dt><span class="term">-q</span></dt>
 <dd><p>
             Quiet mode - exit code only.
@@ -74,7 +78,7 @@
           </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.
+            Specify the class of the zone.  If not specified, "IN" is assumed.
           </p></dd>
 <dt><span class="term">-i <em class="replaceable"><code>mode</code></em></span></dt>
 <dd>
@@ -169,6 +173,8 @@
 <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>.
+	    If <code class="filename">filename</code> is <code class="filename">-</code> then
+	    write to standard out.
 	    This is mandatory for <span><strong class="command">named-compilezone</strong></span>.
           </p></dd>
 <dt><span class="term">-s <em class="replaceable"><code>style</code></em></span></dt>
@@ -233,14 +239,14 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2544299"></a><h2>RETURN VALUES</h2>
+<a name="id2544328"></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" lang="en">
-<a name="id2544311"></a><h2>SEE ALSO</h2>
+<a name="id2544340"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
       <span class="citerefentry"><span class="refentrytitle">named-checkconf</span>(8)</span>,
       <em class="citetitle">RFC 1035</em>,
@@ -248,7 +254,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2544344"></a><h2>AUTHOR</h2>
+<a name="id2544373"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
diff --git a/contrib/bind9/bin/dig/Makefile.in b/contrib/bind9/bin/dig/Makefile.in
index 836b7f2..bc9d34f 100644
--- a/contrib/bind9/bin/dig/Makefile.in
+++ b/contrib/bind9/bin/dig/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2000-2002  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.33.18.6 2005/09/09 14:11:04 marka Exp $
+# $Id: Makefile.in,v 1.41 2007/06/19 23:46:59 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/bin/dig/dig.1 b/contrib/bind9/bin/dig/dig.1
index c9df21e..f7f4370 100644
--- a/contrib/bind9/bin/dig/dig.1
+++ b/contrib/bind9/bin/dig/dig.1
@@ -1,4 +1,4 @@
-.\" Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
 .\" Copyright (C) 2000-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: dig.1,v 1.23.18.24 2008/10/14 01:30:11 tbox Exp $
+.\" $Id: dig.1,v 1.50.44.2 2009/02/03 01:52:10 tbox Exp $
 .\"
 .hy 0
 .ad l
@@ -291,7 +291,7 @@ A synonym for
 .PP
 \fB+[no]adflag\fR
 .RS 4
-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. This requests the server to return whether all of the answer and authority sections have all been validated as secure according to the security policy of the server. AD=1 indicates that all records have been validated as secure and the answer is not from a OPT\-OUT range. AD=0 indicate that some part of the answer was insecure or not validated.
 .RE
 .PP
 \fB+[no]cdflag\fR
@@ -480,7 +480,7 @@ Chase DNSSEC signature chains. Requires dig be compiled with \-DDIG_SIGCHASE.
 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
+If not specified,
 \fBdig\fR
 will look for
 \fI/etc/trusted\-key.key\fR
@@ -495,6 +495,11 @@ Requires dig be compiled with \-DDIG_SIGCHASE.
 .RS 4
 When chasing DNSSEC signature chains perform a top\-down validation. Requires dig be compiled with \-DDIG_SIGCHASE.
 .RE
+.PP
+\fB+[no]nsid\fR
+.RS 4
+Include an EDNS name server ID request when sending a query.
+.RE
 .SH "MULTIPLE QUERIES"
 .PP
 The BIND 9 implementation of
@@ -557,7 +562,7 @@ RFC1035.
 .PP
 There are probably too many query options.
 .SH "COPYRIGHT"
-Copyright \(co 2004\-2008 Internet Systems Consortium, Inc. ("ISC")
+Copyright \(co 2004\-2009 Internet Systems Consortium, Inc. ("ISC")
 .br
 Copyright \(co 2000\-2003 Internet Software Consortium.
 .br
diff --git a/contrib/bind9/bin/dig/dig.c b/contrib/bind9/bin/dig/dig.c
index 5cde9c4..f740a1d 100644
--- a/contrib/bind9/bin/dig/dig.c
+++ b/contrib/bind9/bin/dig/dig.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dig.c,v 1.186.18.33 2008/10/15 02:19:18 marka Exp $ */
+/* $Id: dig.c,v 1.225.26.4 2009/05/06 10:18:33 fdupont Exp $ */
 
 /*! \file */
 
@@ -111,6 +111,24 @@ static const char * const rcodetext[] = {
 	"BADVERS"
 };
 
+/*% safe rcodetext[] */
+static char *
+rcode_totext(dns_rcode_t rcode)
+{
+	static char buf[sizeof("?65535")];
+	union {
+		const char *consttext;
+		char *deconsttext;
+	} totext;
+
+	if (rcode >= (sizeof(rcodetext)/sizeof(rcodetext[0]))) {
+		snprintf(buf, sizeof(buf), "?%u", rcode);
+		totext.deconsttext = buf;
+	} else
+		totext.consttext = rcodetext[rcode];
+	return totext.deconsttext;
+}
+
 /*% print usage */
 static void
 print_usage(FILE *fp) {
@@ -195,6 +213,7 @@ help(void) {
 "                 +[no]identify       (ID responders in short answers)\n"
 "                 +[no]trace          (Trace delegation down from root)\n"
 "                 +[no]dnssec         (Request DNSSEC records)\n"
+"                 +[no]nsid           (Request Name Server ID)\n"
 #ifdef DIG_SIGCHASE
 "                 +[no]sigchase       (Chase DNSSEC signatures)\n"
 "                 +trusted-key=####   (Trusted Key when chasing DNSSEC sigs)\n"
@@ -468,7 +487,8 @@ printmessage(dig_query_t *query, dns_message_t *msg, isc_boolean_t headers) {
 		if (headers) {
 			printf(";; ->>HEADER<<- opcode: %s, status: %s, "
 			       "id: %u\n",
-			       opcodetext[msg->opcode], rcodetext[msg->rcode],
+			       opcodetext[msg->opcode],
+			       rcode_totext(msg->rcode),
 			       msg->id);
 			printf(";; flags:");
 			if ((msg->flags & DNS_MESSAGEFLAG_QR) != 0)
@@ -640,9 +660,9 @@ printgreeting(int argc, char **argv, dig_lookup_t *lookup) {
 		}
 		if (first) {
 			snprintf(append, sizeof(append),
-				 ";; global options: %s %s\n",
-			       short_form ? "short_form" : "",
-			       printcmd ? "printcmd" : "");
+				 ";; global options:%s%s\n",
+				 short_form ? " +short" : "",
+				 printcmd ? " +cmd" : "");
 			first = ISC_FALSE;
 			remaining = sizeof(lookup->cmdline) -
 				    strlen(lookup->cmdline) - 1;
@@ -800,7 +820,9 @@ plus_option(char *option, isc_boolean_t is_batchfile,
 		switch (cmd[1]) {
 		case 'e': /* defname */
 			FULLCHECK("defname");
-			usesearch = state;
+			if (!lookup->trace) {
+				usesearch = state;
+			}
 			break;
 		case 'n': /* dnssec */
 			FULLCHECK("dnssec");
@@ -842,7 +864,7 @@ plus_option(char *option, isc_boolean_t is_batchfile,
 			lookup->identify = state;
 			break;
 		case 'g': /* ignore */
-		default: /* Inherets default for compatibility */
+		default: /* Inherits default for compatibility */
 			FULLCHECK("ignore");
 			lookup->ignore = ISC_TRUE;
 		}
@@ -861,21 +883,33 @@ plus_option(char *option, isc_boolean_t is_batchfile,
 				goto invalid_option;
 			ndots = parse_uint(value, "ndots", MAXNDOTS);
 			break;
-		case 's': /* nssearch */
-			FULLCHECK("nssearch");
-			lookup->ns_search_only = state;
-			if (state) {
-				lookup->trace_root = ISC_TRUE;
-				lookup->recurse = ISC_TRUE;
-				lookup->identify = ISC_TRUE;
-				lookup->stats = ISC_FALSE;
-				lookup->comments = ISC_FALSE;
-				lookup->section_additional = ISC_FALSE;
-				lookup->section_authority = ISC_FALSE;
-				lookup->section_question = ISC_FALSE;
-				lookup->rdtype = dns_rdatatype_ns;
-				lookup->rdtypeset = ISC_TRUE;
-				short_form = ISC_TRUE;
+		case 's':
+			switch (cmd[2]) {
+			case 'i': /* nsid */
+				FULLCHECK("nsid");
+				if (state && lookup->edns == -1)
+					lookup->edns = 0;
+				lookup->nsid = state;
+				break;
+			case 's': /* nssearch */
+				FULLCHECK("nssearch");
+				lookup->ns_search_only = state;
+				if (state) {
+					lookup->trace_root = ISC_TRUE;
+					lookup->recurse = ISC_TRUE;
+					lookup->identify = ISC_TRUE;
+					lookup->stats = ISC_FALSE;
+					lookup->comments = ISC_FALSE;
+					lookup->section_additional = ISC_FALSE;
+					lookup->section_authority = ISC_FALSE;
+					lookup->section_question = ISC_FALSE;
+					lookup->rdtype = dns_rdatatype_ns;
+					lookup->rdtypeset = ISC_TRUE;
+					short_form = ISC_TRUE;
+				}
+				break;
+			default:
+				goto invalid_option;
 			}
 			break;
 		default:
@@ -928,7 +962,9 @@ plus_option(char *option, isc_boolean_t is_batchfile,
 		switch (cmd[1]) {
 		case 'e': /* search */
 			FULLCHECK("search");
-			usesearch = state;
+			if (!lookup->trace) {
+				usesearch = state;
+			}
 			break;
 		case 'h':
 			if (cmd[2] != 'o')
@@ -949,8 +985,10 @@ plus_option(char *option, isc_boolean_t is_batchfile,
 				break;
 			case 'w': /* showsearch */
 				FULLCHECK("showsearch");
-				showsearch = state;
-				usesearch = state;
+				if (!lookup->trace) {
+					showsearch = state;
+					usesearch = state;
+				}
 				break;
 			default:
 				goto invalid_option;
@@ -1009,6 +1047,7 @@ plus_option(char *option, isc_boolean_t is_batchfile,
 					lookup->section_additional = ISC_FALSE;
 					lookup->section_authority = ISC_TRUE;
 					lookup->section_question = ISC_FALSE;
+					usesearch = ISC_FALSE;
 				}
 				break;
 			case 'i': /* tries */
@@ -1254,6 +1293,7 @@ dash_option(char *option, char *next, dig_lookup_t **lookup,
 						MAXSERIAL);
 				(*lookup)->section_question = plusquest;
 				(*lookup)->comments = pluscomm;
+				(*lookup)->tcp_mode = ISC_TRUE;
 			} else {
 				(*lookup)->rdtype = rdtype;
 				(*lookup)->rdtypeset = ISC_TRUE;
@@ -1594,6 +1634,7 @@ parse_args(isc_boolean_t is_batchfile, isc_boolean_t config_only,
 						lookup->section_question =
 							plusquest;
 						lookup->comments = pluscomm;
+						lookup->tcp_mode = ISC_TRUE;
 					} else {
 						lookup->rdtype = rdtype;
 						lookup->rdtypeset = ISC_TRUE;
diff --git a/contrib/bind9/bin/dig/dig.docbook b/contrib/bind9/bin/dig/dig.docbook
index 92be180..f987465b 100644
--- a/contrib/bind9/bin/dig/dig.docbook
+++ b/contrib/bind9/bin/dig/dig.docbook
@@ -2,7 +2,7 @@
                "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
 	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: dig.docbook,v 1.17.18.24 2008/10/14 00:54:40 marka Exp $ -->
+<!-- $Id: dig.docbook,v 1.42.44.3 2009/02/02 04:42:48 marka Exp $ -->
 <refentry id="man.dig">
 
   <refentryinfo>
@@ -43,6 +43,7 @@
       <year>2006</year>
       <year>2007</year>
       <year>2008</year>
+      <year>2009</year>
       <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
     </copyright>
     <copyright>
@@ -449,17 +450,19 @@
 
         <varlistentry>
           <term><option>+[no]adflag</option></term>
-          <listitem>
-            <para>
-              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.
-            </para>
-          </listitem>
-        </varlistentry>
+	  <listitem>
+	    <para>
+	      Set [do not set] the AD (authentic data) bit in the
+	      query.  This requests the server to return whether
+	      all of the answer and authority sections have all
+	      been validated as secure according to the security
+	      policy of the server.  AD=1 indicates that all records
+	      have been validated as secure and the answer is not
+	      from a OPT-OUT range.  AD=0 indicate that some part
+	      of the answer was insecure or not validated.
+	    </para>
+	  </listitem>
+	</varlistentry>
 
         <varlistentry>
           <term><option>+[no]cdflag</option></term>
@@ -816,7 +819,7 @@
 	      on its own line.
             </para>
 	    <para>
-	      If not specified <command>dig</command> will look for
+	      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>
@@ -837,6 +840,14 @@
           </listitem>
         </varlistentry>
 
+        <varlistentry>
+          <term><option>+[no]nsid</option></term>
+          <listitem>
+            <para>
+              Include an EDNS name server ID request when sending a query.
+            </para>
+          </listitem>
+        </varlistentry>
 
 
       </variablelist>
diff --git a/contrib/bind9/bin/dig/dig.html b/contrib/bind9/bin/dig/dig.html
index a8c4594..11b55cc 100644
--- a/contrib/bind9/bin/dig/dig.html
+++ b/contrib/bind9/bin/dig/dig.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: dig.html,v 1.13.18.30 2008/10/14 01:30:11 tbox Exp $ -->
+<!-- $Id: dig.html,v 1.45.44.2 2009/02/03 01:52:10 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -34,7 +34,7 @@
 <div class="cmdsynopsis"><p><code class="command">dig</code>  [global-queryopt...] [query...]</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2543515"></a><h2>DESCRIPTION</h2>
+<a name="id2543518"></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
@@ -80,7 +80,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2543589"></a><h2>SIMPLE USAGE</h2>
+<a name="id2543592"></a><h2>SIMPLE USAGE</h2>
 <p>
       A typical invocation of <span><strong class="command">dig</strong></span> looks like:
       </p>
@@ -126,7 +126,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2543680"></a><h2>OPTIONS</h2>
+<a name="id2543683"></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
@@ -230,7 +230,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2544028"></a><h2>QUERY OPTIONS</h2>
+<a name="id2544032"></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
@@ -308,13 +308,15 @@
             </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>
+	      Set [do not set] the AD (authentic data) bit in the
+	      query.  This requests the server to return whether
+	      all of the answer and authority sections have all
+	      been validated as secure according to the security
+	      policy of the server.  AD=1 indicates that all records
+	      have been validated as secure and the answer is not
+	      from a OPT-OUT range.  AD=0 indicate that some part
+	      of the answer was insecure or not validated.
+	    </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.
@@ -529,7 +531,7 @@
 	      on its own line.
             </p>
 <p>
-	      If not specified <span><strong class="command">dig</strong></span> will look for
+	      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>
@@ -543,13 +545,17 @@
               validation.
               Requires dig be compiled with -DDIG_SIGCHASE.
             </p></dd>
+<dt><span class="term"><code class="option">+[no]nsid</code></span></dt>
+<dd><p>
+              Include an EDNS name server ID request when sending a query.
+            </p></dd>
 </dl></div>
 <p>
 
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2545149"></a><h2>MULTIPLE QUERIES</h2>
+<a name="id2545166"></a><h2>MULTIPLE QUERIES</h2>
 <p>
       The BIND 9 implementation of <span><strong class="command">dig </strong></span>
       supports
@@ -595,7 +601,7 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2545211"></a><h2>IDN SUPPORT</h2>
+<a name="id2545228"></a><h2>IDN SUPPORT</h2>
 <p>
       If <span><strong class="command">dig</strong></span> has been built with IDN (internationalized
       domain name) support, it can accept and display non-ASCII domain names.
@@ -609,14 +615,14 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2545234"></a><h2>FILES</h2>
+<a name="id2545251"></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="id2545251"></a><h2>SEE ALSO</h2>
+<a name="id2545336"></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>,
@@ -624,7 +630,7 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2545356"></a><h2>BUGS</h2>
+<a name="id2545373"></a><h2>BUGS</h2>
 <p>
       There are probably too many query options.
     </p>
diff --git a/contrib/bind9/bin/dig/dighost.c b/contrib/bind9/bin/dig/dighost.c
index 8736c0c..470261c 100644
--- a/contrib/bind9/bin/dig/dighost.c
+++ b/contrib/bind9/bin/dig/dighost.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dighost.c,v 1.259.18.49 2008/07/23 23:33:02 marka Exp $ */
+/* $Id: dighost.c,v 1.311.70.8 2009/02/25 02:39:21 marka Exp $ */
 
 /*! \file
  *  \note
@@ -583,6 +583,11 @@ copy_server_list(lwres_conf_t *confdata, dig_serverlist_t *dest) {
 	for (i = 0; i < confdata->nsnext; i++) {
 		af = addr2af(confdata->nameservers[i].family);
 
+		if (af == AF_INET && !have_ipv4)
+			continue;
+		if (af == AF_INET6 && !have_ipv6)
+			continue;
+
 		lwres_net_ntop(af, confdata->nameservers[i].address,
 				   tmp, sizeof(tmp));
 		newsrv = make_server(tmp, tmp);
@@ -724,6 +729,7 @@ make_empty_lookup(void) {
 	looknew->servfail_stops = ISC_TRUE;
 	looknew->besteffort = ISC_TRUE;
 	looknew->dnssec = ISC_FALSE;
+	looknew->nsid = ISC_FALSE;
 #ifdef DIG_SIGCHASE
 	looknew->sigchase = ISC_FALSE;
 #if DIG_SIGCHASE_TD
@@ -770,7 +776,7 @@ make_empty_lookup(void) {
  * the query list, since it will be regenerated by the setup_lookup()
  * function, nor does it queue up the new lookup for processing.
  * Caution: If you don't clone the servers, you MUST clone the server
- * list seperately from somewhere else, or construct it by hand.
+ * list separately from somewhere else, or construct it by hand.
  */
 dig_lookup_t *
 clone_lookup(dig_lookup_t *lookold, isc_boolean_t servers) {
@@ -803,6 +809,7 @@ clone_lookup(dig_lookup_t *lookold, isc_boolean_t servers) {
 	looknew->servfail_stops = lookold->servfail_stops;
 	looknew->besteffort = lookold->besteffort;
 	looknew->dnssec = lookold->dnssec;
+	looknew->nsid = lookold->nsid;
 #ifdef DIG_SIGCHASE
 	looknew->sigchase = lookold->sigchase;
 #if DIG_SIGCHASE_TD
@@ -1004,10 +1011,18 @@ void
 setup_system(void) {
 	dig_searchlist_t *domain = NULL;
 	lwres_result_t lwresult;
+	unsigned int lwresflags;
 
 	debug("setup_system()");
 
-	lwresult = lwres_context_create(&lwctx, mctx, mem_alloc, mem_free, 1);
+	lwresflags = LWRES_CONTEXT_SERVERMODE;
+	if (have_ipv4)
+		lwresflags |= LWRES_CONTEXT_USEIPV4;
+	if (have_ipv6)
+		lwresflags |= LWRES_CONTEXT_USEIPV6;
+
+	lwresult = lwres_context_create(&lwctx, mctx, mem_alloc, mem_free,
+					lwresflags);
 	if (lwresult != LWRES_R_SUCCESS)
 		fatal("lwres_context_create failed");
 
@@ -1033,8 +1048,10 @@ setup_system(void) {
 		debug("ndots is %d.", ndots);
 	}
 
+	copy_server_list(lwconf, &server_list);
+
 	/* If we don't find a nameserver fall back to localhost */
-	if (lwconf->nsnext == 0) {
+	if (ISC_LIST_EMPTY(server_list)) {
 		if (have_ipv4) {
 			lwresult = add_nameserver(lwconf, "127.0.0.1", AF_INET);
 			if (lwresult != ISC_R_SUCCESS)
@@ -1045,10 +1062,9 @@ setup_system(void) {
 			if (lwresult != ISC_R_SUCCESS)
 				fatal("add_nameserver failed");
 		}
-	}
 
-	if (ISC_LIST_EMPTY(server_list))
 		copy_server_list(lwconf, &server_list);
+	}
 
 #ifdef WITH_IDN
 	initialize_idn();
@@ -1155,11 +1171,11 @@ setup_libs(void) {
 
 /*%
  * Add EDNS0 option record to a message.  Currently, the only supported
- * options are UDP buffer size and the DO bit.
+ * options are UDP buffer size, the DO bit, and NSID request.
  */
 static void
 add_opt(dns_message_t *msg, isc_uint16_t udpsize, isc_uint16_t edns,
-	isc_boolean_t dnssec)
+	isc_boolean_t dnssec, isc_boolean_t nsid)
 {
 	dns_rdataset_t *rdataset = NULL;
 	dns_rdatalist_t *rdatalist = NULL;
@@ -1182,8 +1198,19 @@ add_opt(dns_message_t *msg, isc_uint16_t udpsize, isc_uint16_t edns,
 	rdatalist->ttl = edns << 16;
 	if (dnssec)
 		rdatalist->ttl |= DNS_MESSAGEEXTFLAG_DO;
-	rdata->data = NULL;
-	rdata->length = 0;
+	if (nsid) {
+		unsigned char data[4];
+		isc_buffer_t buf;
+
+		isc_buffer_init(&buf, data, sizeof(data));
+		isc_buffer_putuint16(&buf, DNS_OPT_NSID);
+		isc_buffer_putuint16(&buf, 0);
+		rdata->data = data;
+		rdata->length = sizeof(data);
+	} else {
+		rdata->data = NULL;
+		rdata->length = 0;
+	}
 	ISC_LIST_INIT(rdatalist->rdata);
 	ISC_LIST_APPEND(rdatalist->rdata, rdata, link);
 	dns_rdatalist_tordataset(rdatalist, rdataset);
@@ -1387,7 +1414,7 @@ start_lookup(void) {
 							 key_name) == ISC_TRUE)
 					trustedkey = tk_list.key[i];
 				/*
-				 * Verifier que la temp est bien la plus basse
+				 * Verify temp is really the lowest
 				 * WARNING
 				 */
 			}
@@ -1848,7 +1875,7 @@ setup_lookup(dig_lookup_t *lookup) {
 						&lookup->name);
 			dns_message_puttempname(lookup->sendmsg,
 						&lookup->oname);
-			fatal("Origin '%s' is not in legal name syntax (%s)",
+			fatal("'%s' is not in legal name syntax (%s)",
 			      lookup->origin->origin,
 			      isc_result_totext(result));
 		}
@@ -1953,12 +1980,15 @@ setup_lookup(dig_lookup_t *lookup) {
 
 	if ((lookup->rdtype == dns_rdatatype_axfr) ||
 	    (lookup->rdtype == dns_rdatatype_ixfr)) {
-		lookup->doing_xfr = ISC_TRUE;
 		/*
-		 * Force TCP mode if we're doing an xfr.
-		 * XXX UDP ixfr's would be useful
+		 * Force TCP mode if we're doing an axfr.
 		 */
-		lookup->tcp_mode = ISC_TRUE;
+		if (lookup->rdtype == dns_rdatatype_axfr) {
+			lookup->doing_xfr = ISC_TRUE;
+			lookup->tcp_mode = ISC_TRUE;
+		} else if (lookup->tcp_mode) {
+			lookup->doing_xfr = ISC_TRUE;
+		}
 	}
 
 	add_question(lookup->sendmsg, lookup->name, lookup->rdclass,
@@ -1995,7 +2025,7 @@ setup_lookup(dig_lookup_t *lookup) {
 		if (lookup->edns < 0)
 			lookup->edns = 0;
 		add_opt(lookup->sendmsg, lookup->udpsize,
-			lookup->edns, lookup->dnssec);
+			lookup->edns, lookup->dnssec, lookup->nsid);
 	}
 
 	result = dns_message_rendersection(lookup->sendmsg,
@@ -2175,6 +2205,21 @@ bringup_timer(dig_query_t *query, unsigned int default_timeout) {
 }
 
 static void
+force_timeout(dig_lookup_t *l, dig_query_t *query) {
+	isc_event_t *event;
+
+	event = isc_event_allocate(mctx, query, ISC_TIMEREVENT_IDLE,
+				   connect_timeout, l,
+				   sizeof(isc_event_t));
+	if (event == NULL) {
+		fatal("isc_event_allocate: %s",
+		      isc_result_totext(ISC_R_NOMEMORY));
+	}
+	isc_task_send(global_task, &event);
+}
+
+
+static void
 connect_done(isc_task_t *task, isc_event_t *event);
 
 /*%
@@ -2193,7 +2238,16 @@ send_tcp_connect(dig_query_t *query) {
 	l = query->lookup;
 	query->waiting_connect = ISC_TRUE;
 	query->lookup->current_query = query;
-	get_address(query->servname, port, &query->sockaddr);
+	result = get_address(query->servname, port, &query->sockaddr);
+	if (result == ISC_R_NOTFOUND) {
+		/*
+		 * This servname doesn't have an address.  Try the next server
+		 * by triggering an immediate 'timeout' (we lie, but the effect
+		 * is the same).
+		 */
+		force_timeout(l, query);
+		return;
+	}
 
 	if (specified_source &&
 	    (isc_sockaddr_pf(&query->sockaddr) !=
@@ -2266,7 +2320,12 @@ send_udp(dig_query_t *query) {
 	if (!query->recv_made) {
 		/* XXX Check the sense of this, need assertion? */
 		query->waiting_connect = ISC_FALSE;
-		get_address(query->servname, port, &query->sockaddr);
+		result = get_address(query->servname, port, &query->sockaddr);
+		if (result == ISC_R_NOTFOUND) {
+			/* This servname doesn't have an address. */
+			force_timeout(l, query);
+			return;
+		}
 
 		result = isc_socket_create(socketmgr,
 					   isc_sockaddr_pf(&query->sockaddr),
@@ -2337,8 +2396,14 @@ connect_timeout(isc_task_t *task, isc_event_t *event) {
 		cq = query->lookup->current_query;
 		if (!l->tcp_mode)
 			send_udp(ISC_LIST_NEXT(cq, link));
-		else
+		else {
+			isc_socket_cancel(query->sock, NULL,
+					  ISC_SOCKCANCEL_ALL);
+			isc_socket_detach(&query->sock);
+			sockcount--;
+			debug("sockcount=%d", sockcount);
 			send_tcp_connect(ISC_LIST_NEXT(cq, link));
+		}
 		UNLOCK_LOOKUP;
 		return;
 	}
@@ -2892,18 +2957,8 @@ recv_done(isc_task_t *task, isc_event_t *event) {
 	if (result == ISC_R_SUCCESS && (msgflags & DNS_MESSAGEFLAG_QR) == 0)
 		printf(";; Warning: query response not set\n");
 
-	if (!match) {
-		isc_buffer_invalidate(&query->recvbuf);
-		isc_buffer_init(&query->recvbuf, query->recvspace, COMMSIZE);
-		ISC_LIST_ENQUEUE(query->recvlist, &query->recvbuf, link);
-		result = isc_socket_recvv(query->sock, &query->recvlist, 1,
-					  global_task, recv_done, query);
-		check_result(result, "isc_socket_recvv");
-		recvcount++;
-		isc_event_free(&event);
-		UNLOCK_LOOKUP;
-		return;
-	}
+	if (!match)
+		goto udp_mismatch;
 
 	result = dns_message_create(mctx, DNS_MESSAGE_INTENTPARSE, &msg);
 	check_result(result, "dns_message_create");
@@ -2958,6 +3013,52 @@ recv_done(isc_task_t *task, isc_event_t *event) {
 		UNLOCK_LOOKUP;
 		return;
 	}
+	if (msg->counts[DNS_SECTION_QUESTION] != 0) {
+		match = ISC_TRUE;
+		for (result = dns_message_firstname(msg, DNS_SECTION_QUESTION);
+		     result == ISC_R_SUCCESS && match;
+		     result = dns_message_nextname(msg, DNS_SECTION_QUESTION)) {
+			dns_name_t *name = NULL;
+			dns_rdataset_t *rdataset;
+
+			dns_message_currentname(msg, DNS_SECTION_QUESTION,
+						&name);
+			for (rdataset = ISC_LIST_HEAD(name->list);
+			     rdataset != NULL;
+			     rdataset = ISC_LIST_NEXT(rdataset, link)) {
+				if (l->rdtype != rdataset->type ||
+				    l->rdclass != rdataset->rdclass ||
+				    !dns_name_equal(l->name, name)) {
+					char namestr[DNS_NAME_FORMATSIZE];
+					char typebuf[DNS_RDATATYPE_FORMATSIZE];
+					char classbuf[DNS_RDATACLASS_FORMATSIZE];
+					dns_name_format(name, namestr,
+							sizeof(namestr));
+					dns_rdatatype_format(rdataset->type,
+							     typebuf,
+							     sizeof(typebuf));
+					dns_rdataclass_format(rdataset->rdclass,
+							      classbuf,
+							      sizeof(classbuf));
+					printf(";; Question section mismatch: "
+					       "got %s/%s/%s\n",
+					       namestr, typebuf, classbuf);
+					match = ISC_FALSE;
+				}
+			}
+		}
+		if (!match) {
+			dns_message_destroy(&msg);
+			if (l->tcp_mode) {
+				isc_event_free(&event);
+				clear_query(query);
+				check_next_lookup(l);
+				UNLOCK_LOOKUP;
+				return;
+			} else
+				goto udp_mismatch;
+		}
+	}
 	if ((msg->flags & DNS_MESSAGEFLAG_TC) != 0 &&
 	    !l->ignore && !l->tcp_mode) {
 		printf(";; Truncated, retrying in TCP mode.\n");
@@ -3212,6 +3313,19 @@ recv_done(isc_task_t *task, isc_event_t *event) {
 	}
 	isc_event_free(&event);
 	UNLOCK_LOOKUP;
+	return;
+
+ udp_mismatch:
+	isc_buffer_invalidate(&query->recvbuf);
+	isc_buffer_init(&query->recvbuf, query->recvspace, COMMSIZE);
+	ISC_LIST_ENQUEUE(query->recvlist, &query->recvbuf, link);
+	result = isc_socket_recvv(query->sock, &query->recvlist, 1,
+				  global_task, recv_done, query);
+	check_result(result, "isc_socket_recvv");
+	recvcount++;
+	isc_event_free(&event);
+	UNLOCK_LOOKUP;
+	return;
 }
 
 /*%
@@ -3219,7 +3333,7 @@ recv_done(isc_task_t *task, isc_event_t *event) {
  * used in looking up server names, etc... and needs to use system-supplied
  * routines, since they may be using a non-DNS system for these lookups.
  */
-void
+isc_result_t
 get_address(char *host, in_port_t port, isc_sockaddr_t *sockaddr) {
 	int count;
 	isc_result_t result;
@@ -3228,9 +3342,11 @@ get_address(char *host, in_port_t port, isc_sockaddr_t *sockaddr) {
 	result = bind9_getaddresses(host, port, sockaddr, 1, &count);
 	isc_app_unblock();
 	if (result != ISC_R_SUCCESS)
-		fatal("couldn't get address for '%s': %s",
-		      host, isc_result_totext(result));
+		return (result);
+
 	INSIST(count == 1);
+
+	return (ISC_R_SUCCESS);
 }
 
 /*%
@@ -3284,7 +3400,7 @@ cancel_all(void) {
 			isc_timer_detach(&current_lookup->timer);
 		q = ISC_LIST_HEAD(current_lookup->q);
 		while (q != NULL) {
-			debug("cancelling query %p, belonging to %p",
+			debug("canceling query %p, belonging to %p",
 			      q, current_lookup);
 			nq = ISC_LIST_NEXT(q, link);
 			if (q->sock != NULL) {
@@ -3600,7 +3716,7 @@ 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;
+	dns_rdata_t sigrdata = DNS_RDATA_INIT;
 	isc_result_t result;
 
 	for (rdataset = ISC_LIST_HEAD(name->list); rdataset != NULL;
@@ -3610,7 +3726,6 @@ search_type(dns_name_t *name, dns_rdatatype_t type, dns_rdatatype_t covers) {
 				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");
 			dns_rdataset_current(rdataset, &sigrdata);
@@ -4133,7 +4248,7 @@ isc_result_t
 grandfather_pb_test(dns_name_t *zone_name, dns_rdataset_t  *sigrdataset)
 {
 	isc_result_t result;
-	dns_rdata_t sigrdata;
+	dns_rdata_t sigrdata = DNS_RDATA_INIT;
 	dns_rdata_sig_t siginfo;
 
 	result = dns_rdataset_first(sigrdataset);
@@ -4153,6 +4268,7 @@ grandfather_pb_test(dns_name_t *zone_name, dns_rdataset_t  *sigrdataset)
 		}
 
 		dns_rdata_freestruct(&siginfo);
+		dns_rdata_reset(&sigrdata);
 
 	} while (dns_rdataset_next(chase_sigkeyrdataset) == ISC_R_SUCCESS);
 
@@ -4239,7 +4355,7 @@ contains_trusted_key(dns_name_t *name, dns_rdataset_t *rdataset,
 		     isc_mem_t *mctx)
 {
 	isc_result_t result;
-	dns_rdata_t rdata;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
 	dst_key_t *trustedKey = NULL;
 	dst_key_t *dnsseckey = NULL;
 	int i;
@@ -4249,7 +4365,6 @@ contains_trusted_key(dns_name_t *name, dns_rdataset_t *rdataset,
 
 	result = dns_rdataset_first(rdataset);
 	check_result(result, "empty rdataset");
-	dns_rdata_init(&rdata);
 
 	do {
 		dns_rdataset_current(rdataset, &rdata);
@@ -4299,7 +4414,7 @@ sigchase_verify_sig(dns_name_t *name, dns_rdataset_t *rdataset,
 		    isc_mem_t *mctx)
 {
 	isc_result_t result;
-	dns_rdata_t keyrdata;
+	dns_rdata_t keyrdata = DNS_RDATA_INIT;
 	dst_key_t *dnsseckey = NULL;
 
 	result = dns_rdataset_first(keyrdataset);
@@ -4322,6 +4437,7 @@ sigchase_verify_sig(dns_name_t *name, dns_rdataset_t *rdataset,
 			return (ISC_R_SUCCESS);
 		}
 		dst_key_free(&dnsseckey);
+		dns_rdata_reset(&keyrdata);
 	} while (dns_rdataset_next(chase_keyrdataset) == ISC_R_SUCCESS);
 
 	dns_rdata_reset(&keyrdata);
@@ -4335,7 +4451,7 @@ sigchase_verify_sig_key(dns_name_t *name, dns_rdataset_t *rdataset,
 			isc_mem_t *mctx)
 {
 	isc_result_t result;
-	dns_rdata_t sigrdata;
+	dns_rdata_t sigrdata = DNS_RDATA_INIT;
 	dns_rdata_sig_t siginfo;
 
 	result = dns_rdataset_first(sigrdataset);
@@ -4373,6 +4489,7 @@ sigchase_verify_sig_key(dns_name_t *name, dns_rdataset_t *rdataset,
 			}
 		}
 		dns_rdata_freestruct(&siginfo);
+		dns_rdata_reset(&sigrdata);
 
 	} while (dns_rdataset_next(chase_sigkeyrdataset) == ISC_R_SUCCESS);
 
@@ -4387,25 +4504,23 @@ sigchase_verify_ds(dns_name_t *name, dns_rdataset_t *keyrdataset,
 		   dns_rdataset_t *dsrdataset, isc_mem_t *mctx)
 {
 	isc_result_t result;
-	dns_rdata_t keyrdata;
-	dns_rdata_t newdsrdata;
-	dns_rdata_t dsrdata;
+	dns_rdata_t keyrdata = DNS_RDATA_INIT;
+	dns_rdata_t newdsrdata = DNS_RDATA_INIT;
+	dns_rdata_t dsrdata = DNS_RDATA_INIT;
 	dns_rdata_ds_t dsinfo;
 	dst_key_t *dnsseckey = NULL;
 	unsigned char dsbuf[DNS_DS_BUFFERSIZE];
 
 	result = dns_rdataset_first(dsrdataset);
 	check_result(result, "empty DSset dataset");
-	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");
+		check_result(result, "dns_rdata_tostruct for DS");
 
 		result = dns_rdataset_first(keyrdataset);
 		check_result(result, "empty KEY dataset");
-		dns_rdata_init(&keyrdata);
 
 		do {
 			dns_rdataset_current(keyrdataset, &keyrdata);
@@ -4420,7 +4535,6 @@ sigchase_verify_ds(dns_name_t *name, dns_rdataset_t *keyrdataset,
 			 * id of DNSKEY referenced by the DS
 			 */
 			if (dsinfo.key_tag == dst_key_id(dnsseckey)) {
-				dns_rdata_init(&newdsrdata);
 
 				result = dns_ds_buildrdata(name, &keyrdata,
 							   dsinfo.digest_type,
@@ -4468,14 +4582,16 @@ sigchase_verify_ds(dns_name_t *name, dns_rdataset_t *keyrdataset,
 				dns_rdata_reset(&newdsrdata);
 			}
 			dst_key_free(&dnsseckey);
+			dns_rdata_reset(&keyrdata);
 			dnsseckey = NULL;
 		} while (dns_rdataset_next(chase_keyrdataset) == ISC_R_SUCCESS);
-		dns_rdata_reset(&keyrdata);
+		dns_rdata_reset(&dsrdata);
 
 	} while (dns_rdataset_next(chase_dsrdataset) == ISC_R_SUCCESS);
-#if 0
-	dns_rdata_reset(&dsrdata); WARNING
-#endif
+
+	dns_rdata_reset(&keyrdata);
+	dns_rdata_reset(&newdsrdata);
+	dns_rdata_reset(&dsrdata);
 
 	return (ISC_R_NOTFOUND);
 }
@@ -4868,7 +4984,7 @@ getneededrr(dns_message_t *msg)
 {
 	isc_result_t result;
 	dns_name_t *name = NULL;
-	dns_rdata_t sigrdata;
+	dns_rdata_t sigrdata = DNS_RDATA_INIT;
 	dns_rdata_sig_t siginfo;
 	isc_boolean_t   true = ISC_TRUE;
 
@@ -4922,7 +5038,6 @@ getneededrr(dns_message_t *msg)
 	/* first find the DNSKEY name */
 	result = dns_rdataset_first(chase_sigrdataset);
 	check_result(result, "empty RRSIG dataset");
-	dns_rdata_init(&sigrdata);
 	dns_rdataset_current(chase_sigrdataset, &sigrdata);
 	result = dns_rdata_tostruct(&sigrdata, &siginfo, NULL);
 	check_result(result, "sigrdata tostruct siginfo");
@@ -5300,6 +5415,7 @@ prove_nx_domain(dns_message_t *msg,
 			}
 
 			dns_rdata_freestruct(&nsecstruct);
+			dns_rdata_reset(&nsec);
 		}
 	} while (dns_message_nextname(msg, DNS_SECTION_AUTHORITY)
 		 == ISC_R_SUCCESS);
@@ -5367,7 +5483,7 @@ prove_nx(dns_message_t *msg, dns_name_t *name, dns_rdataclass_t class,
 	isc_result_t ret;
 	dns_rdataset_t *nsecset = NULL;
 
-	printf("We want to prove the non-existance of a type of rdata %d"
+	printf("We want to prove the non-existence of a type of rdata %d"
 	       " or of the zone: \n", type);
 
 	if ((ret = dns_message_firstname(msg, DNS_SECTION_AUTHORITY))
diff --git a/contrib/bind9/bin/dig/host.1 b/contrib/bind9/bin/dig/host.1
index 9993c0e..eebdad8 100644
--- a/contrib/bind9/bin/dig/host.1
+++ b/contrib/bind9/bin/dig/host.1
@@ -1,4 +1,4 @@
-.\" Copyright (C) 2004, 2005, 2007, 2008 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2004, 2005, 2007-2009 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: host.1,v 1.14.18.16 2008/04/06 01:31:04 tbox Exp $
+.\" $Id: host.1,v 1.29.114.1 2009/01/23 01:53:33 tbox Exp $
 .\"
 .hy 0
 .ad l
@@ -132,7 +132,7 @@ option enables
 \fBhost\fR
 to mimic the behavior 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
+By default,
 \fBhost\fR
 uses UDP when making queries. The
 \fB\-T\fR
@@ -154,7 +154,7 @@ option is used to select the query type.
 \fItype\fR
 can be any recognized 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, AAAA, and MX records, but if the
+automatically selects an appropriate query type. By default, it looks for A, AAAA, and MX records, but if the
 \fB\-C\fR
 option was given, queries will be made for SOA records, and if
 \fIname\fR
@@ -213,7 +213,7 @@ runs.
 \fBdig\fR(1),
 \fBnamed\fR(8).
 .SH "COPYRIGHT"
-Copyright \(co 2004, 2005, 2007, 2008 Internet Systems Consortium, Inc. ("ISC")
+Copyright \(co 2004, 2005, 2007\-2009 Internet Systems Consortium, Inc. ("ISC")
 .br
 Copyright \(co 2000\-2002 Internet Software Consortium.
 .br
diff --git a/contrib/bind9/bin/dig/host.c b/contrib/bind9/bin/dig/host.c
index 33025d5..9f30206 100644
--- a/contrib/bind9/bin/dig/host.c
+++ b/contrib/bind9/bin/dig/host.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: host.c,v 1.94.18.19 2007/08/28 07:19:55 tbox Exp $ */
+/* $Id: host.c,v 1.116.216.2 2009/05/06 23:47:18 tbox Exp $ */
 
 /*! \file */
 
@@ -124,6 +124,23 @@ struct rtype rtypes[] = {
 	{ 0, NULL }
 };
 
+static char *
+rcode_totext(dns_rcode_t rcode)
+{
+	static char buf[sizeof("?65535")];
+	union {
+		const char *consttext;
+		char *deconsttext;
+	} totext;
+
+	if (rcode >= (sizeof(rcodetext)/sizeof(rcodetext[0]))) {
+		snprintf(buf, sizeof(buf), "?%u", rcode);
+		totext.deconsttext = buf;
+	} else
+		totext.consttext = rcodetext[rcode];
+	return totext.deconsttext;
+}
+
 static void
 show_usage(void) {
 	fputs(
@@ -270,10 +287,10 @@ printsection(dns_message_t *msg, dns_section_t sectionid,
 			if (query->lookup->rdtype == dns_rdatatype_axfr &&
 			    !((!list_addresses &&
 			       (list_type == dns_rdatatype_any ||
-			        rdataset->type == list_type)) ||
+				rdataset->type == list_type)) ||
 			      (list_addresses &&
 			       (rdataset->type == dns_rdatatype_a ||
-			        rdataset->type == dns_rdatatype_aaaa ||
+				rdataset->type == dns_rdatatype_aaaa ||
 				rdataset->type == dns_rdatatype_ns ||
 				rdataset->type == dns_rdatatype_ptr))))
 				continue;
@@ -377,7 +394,7 @@ chase_cnamechain(dns_message_t *msg, dns_name_t *qname) {
 	dns_rdata_t rdata = DNS_RDATA_INIT;
 	unsigned int i = msg->counts[DNS_SECTION_ANSWER];
 
- 	while (i-- > 0) {
+	while (i-- > 0) {
 		rdataset = NULL;
 		result = dns_message_findname(msg, DNS_SECTION_ANSWER, qname,
 					      dns_rdatatype_cname, 0, NULL,
@@ -429,7 +446,7 @@ printmessage(dig_query_t *query, dns_message_t *msg, isc_boolean_t headers) {
 		printf("Host %s not found: %d(%s)\n",
 		       (msg->rcode != dns_rcode_nxdomain) ? namestr :
 		       query->lookup->textname, msg->rcode,
-		       rcodetext[msg->rcode]);
+		       rcode_totext(msg->rcode));
 		return (ISC_R_SUCCESS);
 	}
 
@@ -451,7 +468,7 @@ printmessage(dig_query_t *query, dns_message_t *msg, isc_boolean_t headers) {
 				sizeof(lookup->textname));
 			lookup->textname[sizeof(lookup->textname)-1] = 0;
 			lookup->rdtype = dns_rdatatype_aaaa;
-                        lookup->rdtypeset = ISC_TRUE;
+			lookup->rdtypeset = ISC_TRUE;
 			lookup->origin = NULL;
 			lookup->retries = tries;
 			ISC_LIST_APPEND(lookup_list, lookup, link);
@@ -462,7 +479,7 @@ printmessage(dig_query_t *query, dns_message_t *msg, isc_boolean_t headers) {
 				sizeof(lookup->textname));
 			lookup->textname[sizeof(lookup->textname)-1] = 0;
 			lookup->rdtype = dns_rdatatype_mx;
-                        lookup->rdtypeset = ISC_TRUE;
+			lookup->rdtypeset = ISC_TRUE;
 			lookup->origin = NULL;
 			lookup->retries = tries;
 			ISC_LIST_APPEND(lookup_list, lookup, link);
@@ -471,7 +488,7 @@ printmessage(dig_query_t *query, dns_message_t *msg, isc_boolean_t headers) {
 
 	if (!short_form) {
 		printf(";; ->>HEADER<<- opcode: %s, status: %s, id: %u\n",
-		       opcodetext[msg->opcode], rcodetext[msg->rcode],
+		       opcodetext[msg->opcode], rcode_totext(msg->rcode),
 		       msg->id);
 		printf(";; flags: ");
 		if ((msg->flags & DNS_MESSAGEFLAG_QR) != 0) {
@@ -689,6 +706,7 @@ parse_args(isc_boolean_t is_batchfile, int argc, char **argv) {
 				lookup->tcp_mode = ISC_TRUE;
 			} else if (rdtype == dns_rdatatype_ixfr) {
 				lookup->ixfr_serial = serial;
+				lookup->tcp_mode = ISC_TRUE;
 				list_type = rdtype;
 #ifdef WITH_IDN
 			} else if (rdtype == dns_rdatatype_a ||
@@ -837,7 +855,7 @@ main(int argc, char **argv) {
 	ISC_LIST_INIT(lookup_list);
 	ISC_LIST_INIT(server_list);
 	ISC_LIST_INIT(search_list);
-	
+
 	fatalexit = 1;
 #ifdef WITH_IDN
 	idnoptions = IDN_ASCCHECK;
diff --git a/contrib/bind9/bin/dig/host.docbook b/contrib/bind9/bin/dig/host.docbook
index 2c0ad3d..3e75b05 100644
--- a/contrib/bind9/bin/dig/host.docbook
+++ b/contrib/bind9/bin/dig/host.docbook
@@ -2,7 +2,7 @@
                "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
 	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004, 2005, 2007-2009  Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2002  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: host.docbook,v 1.5.18.13 2008/04/05 23:46:04 tbox Exp $ -->
+<!-- $Id: host.docbook,v 1.18.114.2 2009/01/22 23:47:05 tbox Exp $ -->
 <refentry id="man.host">
 
   <refentryinfo>
@@ -42,6 +42,7 @@
       <year>2005</year>
       <year>2007</year>
       <year>2008</year>
+      <year>2009</year>
       <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
     </copyright>
     <copyright>
@@ -180,7 +181,7 @@
     </para>
 
     <para>
-      By default <command>host</command> uses UDP when making
+      By default, <command>host</command> uses UDP when making
       queries.  The
       <option>-T</option> option makes it use a TCP connection when querying
       the name server.  TCP will be automatically selected for queries that
@@ -200,7 +201,7 @@
       NS, SOA, SIG, KEY, AXFR, etc.  When no query type is specified,
       <command>host</command> automatically selects an appropriate
       query
-      type.  By default it looks for A, AAAA, and MX records, but if the
+      type.  By default, it looks for A, AAAA, and MX records, but if the
       <option>-C</option> option was given, queries will be made for SOA
       records, and if <parameter>name</parameter> is a
       dotted-decimal IPv4
diff --git a/contrib/bind9/bin/dig/host.html b/contrib/bind9/bin/dig/host.html
index 88cd830..f210731 100644
--- a/contrib/bind9/bin/dig/host.html
+++ b/contrib/bind9/bin/dig/host.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004, 2005, 2007, 2008 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004, 2005, 2007-2009 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2002 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: host.html,v 1.7.18.22 2008/04/06 01:31:04 tbox Exp $ -->
+<!-- $Id: host.html,v 1.28.114.1 2009/01/23 01:53:33 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -32,7 +32,7 @@
 <div class="cmdsynopsis"><p><code class="command">host</code>  [<code class="option">-aCdlnrsTwv</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">-m <em class="replaceable"><code>flag</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="id2543431"></a><h2>DESCRIPTION</h2>
+<a name="id2543434"></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.
@@ -130,7 +130,7 @@
       referrals to other name servers.
     </p>
 <p>
-      By default <span><strong class="command">host</strong></span> uses UDP when making
+      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
@@ -148,7 +148,7 @@
       NS, SOA, SIG, KEY, AXFR, etc.  When no query type is specified,
       <span><strong class="command">host</strong></span> automatically selects an appropriate
       query
-      type.  By default it looks for A, AAAA, and MX records, but if the
+      type.  By default, it looks for A, AAAA, and MX records, but if the
       <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
@@ -184,7 +184,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2543797"></a><h2>IDN SUPPORT</h2>
+<a name="id2543800"></a><h2>IDN SUPPORT</h2>
 <p>
       If <span><strong class="command">host</strong></span> has been built with IDN (internationalized
       domain name) support, it can accept and display non-ASCII domain names. 
@@ -198,12 +198,12 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2543819"></a><h2>FILES</h2>
+<a name="id2543822"></a><h2>FILES</h2>
 <p><code class="filename">/etc/resolv.conf</code>
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2543831"></a><h2>SEE ALSO</h2>
+<a name="id2543834"></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>
diff --git a/contrib/bind9/bin/dig/include/dig/dig.h b/contrib/bind9/bin/dig/include/dig/dig.h
index 02ae4d2..d9ee757 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-2007  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dig.h,v 1.82.18.23 2007/08/28 07:19:55 tbox Exp $ */
+/* $Id: dig.h,v 1.107.120.2 2009/01/06 23:47:26 tbox Exp $ */
 
 #ifndef DIG_H
 #define DIG_H
@@ -102,7 +102,7 @@ typedef struct dig_searchlist dig_searchlist_t;
 /*% The dig_lookup structure */
 struct dig_lookup {
 	isc_boolean_t
-	        pending, /*%< Pending a successful answer */
+		pending, /*%< Pending a successful answer */
 		waiting_connect,
 		doing_xfr,
 		ns_search_only, /*%< dig +nssearch, host -C */
@@ -129,27 +129,28 @@ struct dig_lookup {
 		need_search,
 		done_as_is,
 		besteffort,
-		dnssec;
+		dnssec,
+		nsid;   /*% Name Server ID (RFC 5001) */
 #ifdef DIG_SIGCHASE
 isc_boolean_t	sigchase;
 #if DIG_SIGCHASE_TD
- 	isc_boolean_t do_topdown,
-	        trace_root_sigchase,
-	        rdtype_sigchaseset,
-	        rdclass_sigchaseset;
+	isc_boolean_t do_topdown,
+		trace_root_sigchase,
+		rdtype_sigchaseset,
+		rdclass_sigchaseset;
 	/* Name we are going to validate RRset */
-  	char textnamesigchase[MXNAME];
+	char textnamesigchase[MXNAME];
 #endif
 #endif
-	
+
 	char textname[MXNAME]; /*% Name we're going to be looking up */
 	char cmdline[MXNAME];
 	dns_rdatatype_t rdtype;
 	dns_rdatatype_t qrdtype;
 #if DIG_SIGCHASE_TD
-        dns_rdatatype_t rdtype_sigchase;
-        dns_rdatatype_t qrdtype_sigchase;
-        dns_rdataclass_t rdclass_sigchase;
+	dns_rdatatype_t rdtype_sigchase;
+	dns_rdatatype_t qrdtype_sigchase;
+	dns_rdataclass_t rdclass_sigchase;
 #endif
 	dns_rdataclass_t rdclass;
 	isc_boolean_t rdtypeset;
@@ -231,7 +232,7 @@ struct dig_searchlist {
 };
 #ifdef DIG_SIGCHASE
 struct dig_message {
-	        dns_message_t *msg;
+		dns_message_t *msg;
 		ISC_LINK(dig_message_t) link;
 };
 #endif
@@ -249,7 +250,7 @@ extern dig_searchlistlist_t search_list;
 extern unsigned int extrabytes;
 
 extern isc_boolean_t check_ra, have_ipv4, have_ipv6, specified_source,
-        usesearch, showsearch, qr;
+	usesearch, showsearch, qr;
 extern in_port_t port;
 extern unsigned int timeout;
 extern isc_mem_t *mctx;
@@ -284,7 +285,7 @@ extern int idnoptions;
 /*
  * Routines in dighost.c.
  */
-void
+isc_result_t
 get_address(char *host, in_port_t port, isc_sockaddr_t *sockaddr);
 
 isc_result_t
diff --git a/contrib/bind9/bin/dig/nslookup.1 b/contrib/bind9/bin/dig/nslookup.1
index a453c2f..2d19534 100644
--- a/contrib/bind9/bin/dig/nslookup.1
+++ b/contrib/bind9/bin/dig/nslookup.1
@@ -12,7 +12,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: nslookup.1,v 1.1.10.14 2007/05/16 06:11:27 marka Exp $
+.\" $Id: nslookup.1,v 1.14 2007/05/16 06:12:01 marka Exp $
 .\"
 .hy 0
 .ad l
diff --git a/contrib/bind9/bin/dig/nslookup.c b/contrib/bind9/bin/dig/nslookup.c
index 3327c6e..5679626 100644
--- a/contrib/bind9/bin/dig/nslookup.c
+++ b/contrib/bind9/bin/dig/nslookup.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: nslookup.c,v 1.101.18.15 2007/08/28 07:19:55 tbox Exp $ */
+/* $Id: nslookup.c,v 1.117.334.4 2009/05/06 11:41:57 fdupont Exp $ */
 
 #include <config.h>
 
@@ -26,6 +26,7 @@
 #include <isc/commandline.h>
 #include <isc/event.h>
 #include <isc/parseint.h>
+#include <isc/print.h>
 #include <isc/string.h>
 #include <isc/timer.h>
 #include <isc/util.h>
@@ -129,6 +130,23 @@ static const char *rtypetext[] = {
 static void flush_lookup_list(void);
 static void getinput(isc_task_t *task, isc_event_t *event);
 
+static char *
+rcode_totext(dns_rcode_t rcode)
+{
+	static char buf[sizeof("?65535")];
+	union {
+		const char *consttext;
+		char *deconsttext;
+	} totext;
+
+	if (rcode >= (sizeof(rcodetext)/sizeof(rcodetext[0]))) {
+		snprintf(buf, sizeof(buf), "?%u", rcode);
+		totext.deconsttext = buf;
+	} else
+		totext.consttext = rcodetext[rcode];
+	return totext.deconsttext;
+}
+
 void
 dighost_shutdown(void) {
 	isc_event_t *event = global_event;
@@ -385,14 +403,14 @@ trying(char *frm, dig_lookup_t *lookup) {
 
 isc_result_t
 printmessage(dig_query_t *query, dns_message_t *msg, isc_boolean_t headers) {
-	char servtext[ISC_SOCKADDR_FORMATSIZE];	
+	char servtext[ISC_SOCKADDR_FORMATSIZE];
 
 	debug("printmessage()");
 
 	isc_sockaddr_format(&query->sockaddr, servtext, sizeof(servtext));
 	printf("Server:\t\t%s\n", query->userarg);
 	printf("Address:\t%s\n", servtext);
-	
+
 	puts("");
 
 	if (!short_form) {
@@ -412,7 +430,7 @@ printmessage(dig_query_t *query, dns_message_t *msg, isc_boolean_t headers) {
 				nametext, sizeof(nametext));
 		printf("** server can't find %s: %s\n",
 		       (msg->rcode != dns_rcode_nxdomain) ? nametext :
-		       query->lookup->textname, rcodetext[msg->rcode]);
+		       query->lookup->textname, rcode_totext(msg->rcode));
 		debug("returning with rcode == 0");
 		return (ISC_R_SUCCESS);
 	}
@@ -441,13 +459,16 @@ show_settings(isc_boolean_t full, isc_boolean_t serv_only) {
 	dig_server_t *srv;
 	isc_sockaddr_t sockaddr;
 	dig_searchlist_t *listent;
+	isc_result_t result;
 
 	srv = ISC_LIST_HEAD(server_list);
 
 	while (srv != NULL) {
 		char sockstr[ISC_SOCKADDR_FORMATSIZE];
 
-		get_address(srv->servername, port, &sockaddr);
+		result = get_address(srv->servername, port, &sockaddr);
+		check_result(result, "get_address");
+
 		isc_sockaddr_format(&sockaddr, sockstr, sizeof(sockstr));
 		printf("Default server: %s\nAddress: %s\n",
 			srv->userarg, sockstr);
@@ -505,7 +526,7 @@ testclass(char *typetext) {
 	tr.base = typetext;
 	tr.length = strlen(typetext);
 	result = dns_rdataclass_fromtext(&rdclass, &tr);
-	if (result == ISC_R_SUCCESS) 
+	if (result == ISC_R_SUCCESS)
 		return (ISC_TRUE);
 	else {
 		printf("unknown query class: %s\n", typetext);
@@ -603,7 +624,7 @@ setoption(char *opt) {
 		set_timeout(&opt[8]);
 	} else if (strncasecmp(opt, "t=", 2) == 0) {
 		set_timeout(&opt[2]);
- 	} else if (strncasecmp(opt, "rec", 3) == 0) {
+	} else if (strncasecmp(opt, "rec", 3) == 0) {
 		recurse = ISC_TRUE;
 	} else if (strncasecmp(opt, "norec", 5) == 0) {
 		recurse = ISC_FALSE;
@@ -611,21 +632,21 @@ setoption(char *opt) {
 		set_tries(&opt[6]);
 	} else if (strncasecmp(opt, "ret=", 4) == 0) {
 		set_tries(&opt[4]);
- 	} else if (strncasecmp(opt, "def", 3) == 0) {
+	} else if (strncasecmp(opt, "def", 3) == 0) {
 		usesearch = ISC_TRUE;
 	} else if (strncasecmp(opt, "nodef", 5) == 0) {
 		usesearch = ISC_FALSE;
- 	} else if (strncasecmp(opt, "vc", 3) == 0) {
+	} else if (strncasecmp(opt, "vc", 3) == 0) {
 		tcpmode = ISC_TRUE;
 	} else if (strncasecmp(opt, "novc", 5) == 0) {
 		tcpmode = ISC_FALSE;
- 	} else if (strncasecmp(opt, "deb", 3) == 0) {
+	} else if (strncasecmp(opt, "deb", 3) == 0) {
 		short_form = ISC_FALSE;
 		showsearch = ISC_TRUE;
 	} else if (strncasecmp(opt, "nodeb", 5) == 0) {
 		short_form = ISC_TRUE;
 		showsearch = ISC_FALSE;
- 	} else if (strncasecmp(opt, "d2", 2) == 0) {
+	} else if (strncasecmp(opt, "d2", 2) == 0) {
 		debugging = ISC_TRUE;
 	} else if (strncasecmp(opt, "nod2", 4) == 0) {
 		debugging = ISC_FALSE;
@@ -640,7 +661,7 @@ setoption(char *opt) {
 	} else if (strncasecmp(opt, "nofail", 3) == 0) {
 		nofail=ISC_TRUE;
 	} else {
-		printf("*** Invalid option: %s\n", opt);	
+		printf("*** Invalid option: %s\n", opt);
 	}
 }
 
diff --git a/contrib/bind9/bin/dig/nslookup.docbook b/contrib/bind9/bin/dig/nslookup.docbook
index dff5fa3..6c94809 100644
--- a/contrib/bind9/bin/dig/nslookup.docbook
+++ b/contrib/bind9/bin/dig/nslookup.docbook
@@ -17,7 +17,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: nslookup.docbook,v 1.4.2.13 2007/08/28 07:19:55 tbox Exp $ -->
+<!-- $Id: nslookup.docbook,v 1.16 2007/06/18 23:47:17 tbox Exp $ -->
 <!--
  - Copyright (c) 1985, 1989
  -    The Regents of the University of California.  All rights reserved.
diff --git a/contrib/bind9/bin/dig/nslookup.html b/contrib/bind9/bin/dig/nslookup.html
index 46ae43c..0f38176 100644
--- a/contrib/bind9/bin/dig/nslookup.html
+++ b/contrib/bind9/bin/dig/nslookup.html
@@ -13,7 +13,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: nslookup.html,v 1.1.10.21 2007/05/16 06:11:27 marka Exp $ -->
+<!-- $Id: nslookup.html,v 1.21 2007/05/16 06:12:01 marka Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
diff --git a/contrib/bind9/bin/dnssec/Makefile.in b/contrib/bind9/bin/dnssec/Makefile.in
index b94dca7..d59a38fb 100644
--- a/contrib/bind9/bin/dnssec/Makefile.in
+++ b/contrib/bind9/bin/dnssec/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2000-2002  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.26.18.4 2005/05/02 00:26:11 marka Exp $
+# $Id: Makefile.in,v 1.35 2008/11/07 02:28:49 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -39,20 +39,32 @@ DEPLIBS =	${DNSDEPLIBS} ${ISCDEPLIBS}
 LIBS =		${DNSLIBS} ${ISCLIBS} @LIBS@
 
 # Alphabetically
-TARGETS =	dnssec-keygen@EXEEXT@ dnssec-signzone@EXEEXT@
+TARGETS =	dnssec-keygen@EXEEXT@ dnssec-signzone@EXEEXT@ \
+		dnssec-keyfromlabel@EXEEXT@ dnssec-dsfromkey@EXEEXT@
 
 OBJS =		dnssectool.@O@
 
-SRCS =		dnssec-keygen.c dnssec-signzone.c dnssectool.c
+SRCS =		dnssec-dsfromkey.c dnssec-keyfromlabel.c dnssec-keygen.c \
+		dnssec-signzone.c dnssectool.c
 
-MANPAGES =	dnssec-keygen.8 dnssec-signzone.8
+MANPAGES =	dnssec-dsfromkey.8 dnssec-keyfromlabel.8 dnssec-keygen.8 \
+		dnssec-signzone.8
 
-HTMLPAGES =	dnssec-keygen.html dnssec-signzone.html
+HTMLPAGES =	dnssec-dsfromkey.html dnssec-keyfromlabel.html \
+		dnssec-keygen.html dnssec-signzone.html 
 
 MANOBJS =	${MANPAGES} ${HTMLPAGES}
 
 @BIND9_MAKE_RULES@
 
+dnssec-dsfromkey@EXEEXT@: dnssec-dsfromkey.@O@ ${OBJS} ${DEPLIBS}
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ \
+	dnssec-dsfromkey.@O@ ${OBJS} ${LIBS}
+
+dnssec-keyfromlabel@EXEEXT@: dnssec-keyfromlabel.@O@ ${OBJS} ${DEPLIBS}
+	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ \
+	dnssec-keyfromlabel.@O@ ${OBJS} ${LIBS}
+
 dnssec-keygen@EXEEXT@: dnssec-keygen.@O@ ${OBJS} ${DEPLIBS}
 	${LIBTOOL_MODE_LINK} ${PURIFY} ${CC} ${CFLAGS} ${LDFLAGS} -o $@ \
 	dnssec-keygen.@O@ ${OBJS} ${LIBS}
diff --git a/contrib/bind9/bin/dnssec/dnssec-dsfromkey.8 b/contrib/bind9/bin/dnssec/dnssec-dsfromkey.8
new file mode 100644
index 0000000..4d4cbc9
--- /dev/null
+++ b/contrib/bind9/bin/dnssec/dnssec-dsfromkey.8
@@ -0,0 +1,124 @@
+.\" Copyright (C) 2008  Internet Systems Consortium, Inc. ("ISC")
+.\"
+.\" Permission to use, copy, modify, and/or 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-dsfromkey.8,v 1.5 2008/11/08 01:11:47 tbox Exp $
+.\"
+.hy 0
+.ad l
+.\"     Title: dnssec\-dsfromkey
+.\"    Author: 
+.\" Generator: DocBook XSL Stylesheets v1.71.1 <http://docbook.sf.net/>
+.\"      Date: November 29, 2008
+.\"    Manual: BIND9
+.\"    Source: BIND9
+.\"
+.TH "DNSSEC\-DSFROMKEY" "8" "November 29, 2008" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
+dnssec\-dsfromkey \- DNSSEC DS RR generation tool
+.SH "SYNOPSIS"
+.HP 17
+\fBdnssec\-dsfromkey\fR [\fB\-v\ \fR\fB\fIlevel\fR\fR] [\fB\-1\fR] [\fB\-2\fR] [\fB\-a\ \fR\fB\fIalg\fR\fR] {keyfile}
+.HP 17
+\fBdnssec\-dsfromkey\fR {\-s} [\fB\-v\ \fR\fB\fIlevel\fR\fR] [\fB\-1\fR] [\fB\-2\fR] [\fB\-a\ \fR\fB\fIalg\fR\fR] [\fB\-c\ \fR\fB\fIclass\fR\fR] [\fB\-d\ \fR\fB\fIdir\fR\fR] {dnsname}
+.SH "DESCRIPTION"
+.PP
+\fBdnssec\-dsfromkey\fR
+outputs the Delegation Signer (DS) resource record (RR), as defined in RFC 3658 and RFC 4509, for the given key(s).
+.SH "OPTIONS"
+.PP
+\-1
+.RS 4
+Use SHA\-1 as the digest algorithm (the default is to use both SHA\-1 and SHA\-256).
+.RE
+.PP
+\-2
+.RS 4
+Use SHA\-256 as the digest algorithm.
+.RE
+.PP
+\-a \fIalgorithm\fR
+.RS 4
+Select the digest algorithm. The value of
+\fBalgorithm\fR
+must be one of SHA\-1 (SHA1) or SHA\-256 (SHA256). These values are case insensitive.
+.RE
+.PP
+\-v \fIlevel\fR
+.RS 4
+Sets the debugging level.
+.RE
+.PP
+\-s
+.RS 4
+Keyset mode: in place of the keyfile name, the argument is the DNS domain name of a keyset file. Following options make sense only in this mode.
+.RE
+.PP
+\-c \fIclass\fR
+.RS 4
+Specifies the DNS class (default is IN), useful only in the keyset mode.
+.RE
+.PP
+\-d \fIdirectory\fR
+.RS 4
+Look for
+\fIkeyset\fR
+files in
+\fBdirectory\fR
+as the directory, ignored when not in the keyset mode.
+.RE
+.SH "EXAMPLE"
+.PP
+To build the SHA\-256 DS RR from the
+\fBKexample.com.+003+26160\fR
+keyfile name, the following command would be issued:
+.PP
+\fBdnssec\-dsfromkey \-2 Kexample.com.+003+26160\fR
+.PP
+The command would print something like:
+.PP
+\fBexample.com. IN DS 26160 5 2 3A1EADA7A74B8D0BA86726B0C227AA85AB8BBD2B2004F41A868A54F0 C5EA0B94\fR
+.SH "FILES"
+.PP
+The keyfile can be designed by the key identification
+\fIKnnnn.+aaa+iiiii\fR
+or the full file name
+\fIKnnnn.+aaa+iiiii.key\fR
+as generated by
+dnssec\-keygen(8).
+.PP
+The keyset file name is built from the
+\fBdirectory\fR, the string
+\fIkeyset\-\fR
+and the
+\fBdnsname\fR.
+.SH "CAVEAT"
+.PP
+A keyfile error can give a "file not found" even if the file exists.
+.SH "SEE ALSO"
+.PP
+\fBdnssec\-keygen\fR(8),
+\fBdnssec\-signzone\fR(8),
+BIND 9 Administrator Reference Manual,
+RFC 3658,
+RFC 4509.
+.SH "AUTHOR"
+.PP
+Internet Systems Consortium
+.SH "COPYRIGHT"
+Copyright \(co 2008 Internet Systems Consortium, Inc. ("ISC")
+.br
diff --git a/contrib/bind9/bin/dnssec/dnssec-dsfromkey.c b/contrib/bind9/bin/dnssec/dnssec-dsfromkey.c
new file mode 100644
index 0000000..653aa3e
--- /dev/null
+++ b/contrib/bind9/bin/dnssec/dnssec-dsfromkey.c
@@ -0,0 +1,396 @@
+/*
+ * Copyright (C) 2008, 2009  Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or 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-dsfromkey.c,v 1.2.14.3 2009/03/02 02:54:15 marka Exp $ */
+
+/*! \file */
+
+#include <config.h>
+
+#include <stdlib.h>
+
+#include <isc/buffer.h>
+#include <isc/commandline.h>
+#include <isc/entropy.h>
+#include <isc/hash.h>
+#include <isc/mem.h>
+#include <isc/print.h>
+#include <isc/string.h>
+#include <isc/util.h>
+
+#include <dns/db.h>
+#include <dns/dbiterator.h>
+#include <dns/ds.h>
+#include <dns/fixedname.h>
+#include <dns/log.h>
+#include <dns/name.h>
+#include <dns/rdata.h>
+#include <dns/rdataclass.h>
+#include <dns/rdataset.h>
+#include <dns/rdatasetiter.h>
+#include <dns/rdatatype.h>
+#include <dns/result.h>
+
+#include <dst/dst.h>
+
+#include "dnssectool.h"
+
+const char *program = "dnssec-dsfromkey";
+int verbose;
+
+static dns_rdataclass_t rdclass;
+static dns_fixedname_t  fixed;
+static dns_name_t       *name = NULL;
+static dns_db_t         *db = NULL;
+static dns_dbnode_t     *node = NULL;
+static dns_rdataset_t   keyset;
+static isc_mem_t        *mctx = NULL;
+
+static void
+loadkeys(char *dirname, char *setname)
+{
+	isc_result_t     result;
+	char             filename[1024];
+	isc_buffer_t     buf;
+
+	dns_rdataset_init(&keyset);
+	dns_fixedname_init(&fixed);
+	name = dns_fixedname_name(&fixed);
+
+	isc_buffer_init(&buf, setname, strlen(setname));
+	isc_buffer_add(&buf, strlen(setname));
+	result = dns_name_fromtext(name, &buf, dns_rootname, ISC_FALSE, NULL);
+	if (result != ISC_R_SUCCESS)
+		fatal("can't convert DNS name %s", setname);
+
+	isc_buffer_init(&buf, filename, sizeof(filename));
+	if (dirname != NULL) {
+		isc_buffer_putstr(&buf, dirname);
+		if (dirname[strlen(dirname) - 1] != '/')
+			isc_buffer_putstr(&buf, "/");
+	}
+	isc_buffer_putstr(&buf, "keyset-");
+	result = dns_name_tofilenametext(name, ISC_FALSE, &buf);
+	check_result(result, "dns_name_tofilenametext()");
+	if (isc_buffer_availablelength(&buf) == 0)
+		fatal("name %s too long", setname);
+	isc_buffer_putuint8(&buf, 0);
+
+	result = dns_db_create(mctx, "rbt", name, dns_dbtype_zone,
+			       rdclass, 0, NULL, &db);
+	if (result != ISC_R_SUCCESS)
+		fatal("can't create database");
+
+	result = dns_db_load(db, filename);
+	if (result != ISC_R_SUCCESS && result != DNS_R_SEENINCLUDE)
+		fatal("can't load %s: %s", filename, isc_result_totext(result));
+
+	result = dns_db_findnode(db, name, ISC_FALSE, &node);
+	if (result != ISC_R_SUCCESS)
+		fatal("can't find %s node in %s", setname, filename);
+
+	result = dns_db_findrdataset(db, node, NULL, dns_rdatatype_dnskey,
+				     0, 0, &keyset, NULL);
+	if (result == ISC_R_NOTFOUND)
+		fatal("no DNSKEY RR for %s in %s", setname, filename);
+	else if (result != ISC_R_SUCCESS)
+		fatal("dns_db_findrdataset");
+}
+
+static void
+loadkey(char *filename, unsigned char *key_buf, unsigned int key_buf_size,
+	dns_rdata_t *rdata)
+{
+	isc_result_t  result;
+	dst_key_t     *key = NULL;
+	isc_buffer_t  keyb;
+	isc_region_t  r;
+
+	dns_rdataset_init(&keyset);
+	dns_rdata_init(rdata);
+
+	isc_buffer_init(&keyb, key_buf, key_buf_size);
+
+	result = dst_key_fromnamedfile(filename, DST_TYPE_PUBLIC, mctx, &key);
+	if (result != ISC_R_SUCCESS)
+		fatal("invalid keyfile name %s: %s",
+		      filename, isc_result_totext(result));
+
+	if (verbose > 2) {
+		char keystr[KEY_FORMATSIZE];
+
+		key_format(key, keystr, sizeof(keystr));
+		fprintf(stderr, "%s: %s\n", program, keystr);
+	}
+
+	result = dst_key_todns(key, &keyb);
+	if (result != ISC_R_SUCCESS)
+		fatal("can't decode key");
+
+	isc_buffer_usedregion(&keyb, &r);
+	dns_rdata_fromregion(rdata, dst_key_class(key),
+			     dns_rdatatype_dnskey, &r);
+
+	rdclass = dst_key_class(key);
+
+	dns_fixedname_init(&fixed);
+	name = dns_fixedname_name(&fixed);
+	result = dns_name_copy(dst_key_name(key), name, NULL);
+	if (result != ISC_R_SUCCESS)
+		fatal("can't copy name");
+
+	dst_key_free(&key);
+}
+
+static void
+logkey(dns_rdata_t *rdata)
+{
+	isc_result_t result;
+	dst_key_t    *key = NULL;
+	isc_buffer_t buf;
+	char         keystr[KEY_FORMATSIZE];
+
+	isc_buffer_init(&buf, rdata->data, rdata->length);
+	isc_buffer_add(&buf, rdata->length);
+	result = dst_key_fromdns(name, rdclass, &buf, mctx, &key);
+	if (result != ISC_R_SUCCESS)
+		return;
+
+	key_format(key, keystr, sizeof(keystr));
+	fprintf(stderr, "%s: %s\n", program, keystr);
+
+	dst_key_free(&key);
+}
+
+static void
+emitds(unsigned int dtype, dns_rdata_t *rdata)
+{
+	isc_result_t   result;
+	unsigned char  buf[DNS_DS_BUFFERSIZE];
+	char           text_buf[DST_KEY_MAXTEXTSIZE];
+	char           class_buf[10];
+	isc_buffer_t   textb, classb;
+	isc_region_t   r;
+	dns_rdata_t    ds;
+
+	isc_buffer_init(&textb, text_buf, sizeof(text_buf));
+	isc_buffer_init(&classb, class_buf, sizeof(class_buf));
+
+	dns_rdata_init(&ds);
+
+	result = dns_ds_buildrdata(name, rdata, dtype, buf, &ds);
+	if (result != ISC_R_SUCCESS)
+		fatal("can't build DS");
+
+	result = dns_rdata_totext(&ds, (dns_name_t *) NULL, &textb);
+	if (result != ISC_R_SUCCESS)
+		fatal("can't print DS rdata");
+
+	result = dns_rdataclass_totext(rdclass, &classb);
+	if (result != ISC_R_SUCCESS)
+		fatal("can't print DS class");
+
+	result = dns_name_print(name, stdout);
+	if (result != ISC_R_SUCCESS)
+		fatal("can't print DS name");
+
+	putchar(' ');
+
+	isc_buffer_usedregion(&classb, &r);
+	fwrite(r.base, 1, r.length, stdout);
+
+	printf(" DS ");
+
+	isc_buffer_usedregion(&textb, &r);
+	fwrite(r.base, 1, r.length, stdout);
+	putchar('\n');
+}
+
+static void
+usage(void) {
+	fprintf(stderr, "Usage:\n");
+	fprintf(stderr,	"    %s options keyfile\n\n", program);
+	fprintf(stderr, "    %s options [-c class] [-d dir] -s dnsname\n\n",
+		program);
+	fprintf(stderr, "Version: %s\n", VERSION);
+	fprintf(stderr, "Options:\n");
+	fprintf(stderr, "    -v <verbose level>\n");
+	fprintf(stderr, "    -1: use SHA-1\n");
+	fprintf(stderr, "    -2: use SHA-256\n");
+	fprintf(stderr, "    -a algorithm: use algorithm\n");
+	fprintf(stderr, "Keyset options:\n");
+	fprintf(stderr, "    -s: keyset mode\n");
+	fprintf(stderr, "    -c class\n");
+	fprintf(stderr, "    -d directory\n");
+	fprintf(stderr, "Output: DS RRs\n");
+
+	exit (-1);
+}
+
+int
+main(int argc, char **argv) {
+	char           *algname = NULL, *classname = NULL, *dirname = NULL;
+	char           *endp;
+	int            ch;
+	unsigned int   dtype = DNS_DSDIGEST_SHA1;
+	isc_boolean_t  both = ISC_TRUE;
+	isc_boolean_t  usekeyset = ISC_FALSE;
+	isc_result_t   result;
+	isc_log_t      *log = NULL;
+	isc_entropy_t  *ectx = NULL;
+	dns_rdata_t    rdata;
+
+	dns_rdata_init(&rdata);
+
+	if (argc == 1)
+		usage();
+
+	result = isc_mem_create(0, 0, &mctx);
+	if (result != ISC_R_SUCCESS)
+		fatal("out of memory");
+
+	dns_result_register();
+
+	isc_commandline_errprint = ISC_FALSE;
+
+	while ((ch = isc_commandline_parse(argc, argv,
+					   "12a:c:d:sv:h")) != -1) {
+		switch (ch) {
+		case '1':
+			dtype = DNS_DSDIGEST_SHA1;
+			both = ISC_FALSE;
+			break;
+		case '2':
+			dtype = DNS_DSDIGEST_SHA256;
+			both = ISC_FALSE;
+			break;
+		case 'a':
+			algname = isc_commandline_argument;
+			both = ISC_FALSE;
+			break;
+		case 'c':
+			classname = isc_commandline_argument;
+			break;
+		case 'd':
+			dirname = isc_commandline_argument;
+			break;
+		case 's':
+			usekeyset = ISC_TRUE;
+			break;
+		case 'v':
+			verbose = strtol(isc_commandline_argument, &endp, 0);
+			if (*endp != '\0')
+				fatal("-v must be followed by a number");
+			break;
+		case '?':
+			if (isc_commandline_option != '?')
+				fprintf(stderr, "%s: invalid argument -%c\n",
+					program, isc_commandline_option);
+			/* Falls into */
+		case 'h':
+			usage();
+
+		default:
+			fprintf(stderr, "%s: unhandled option -%c\n",
+				program, isc_commandline_option);
+			exit(1);
+		}
+	}
+
+	if (algname != NULL) {
+		if (strcasecmp(algname, "SHA1") == 0 ||
+		    strcasecmp(algname, "SHA-1") == 0)
+			dtype = DNS_DSDIGEST_SHA1;
+		else if (strcasecmp(algname, "SHA256") == 0 ||
+			 strcasecmp(algname, "SHA-256") == 0)
+			dtype = DNS_DSDIGEST_SHA256;
+		else
+			fatal("unknown algorithm %s", algname);
+	}
+
+	rdclass = strtoclass(classname);
+
+	if (argc < isc_commandline_index + 1)
+		fatal("the key file name was not specified");
+	if (argc > isc_commandline_index + 1)
+		fatal("extraneous arguments");
+
+	if (ectx == NULL)
+		setup_entropy(mctx, NULL, &ectx);
+	result = isc_hash_create(mctx, ectx, DNS_NAME_MAXWIRE);
+	if (result != ISC_R_SUCCESS)
+		fatal("could not initialize hash");
+	result = dst_lib_init(mctx, ectx,
+			      ISC_ENTROPY_BLOCKING | ISC_ENTROPY_GOODONLY);
+	if (result != ISC_R_SUCCESS)
+		fatal("could not initialize dst");
+	isc_entropy_stopcallbacksources(ectx);
+
+	setup_logging(verbose, mctx, &log);
+
+	if (usekeyset) {
+		loadkeys(dirname, argv[isc_commandline_index]);
+
+		for (result = dns_rdataset_first(&keyset);
+		     result == ISC_R_SUCCESS;
+		     result = dns_rdataset_next(&keyset)) {
+			dns_rdata_init(&rdata);
+			dns_rdataset_current(&keyset, &rdata);
+
+			if (verbose > 2)
+				logkey(&rdata);
+
+			if (both) {
+				emitds(DNS_DSDIGEST_SHA1, &rdata);
+				emitds(DNS_DSDIGEST_SHA256, &rdata);
+			} else
+				emitds(dtype, &rdata);
+		}
+	} else {
+		unsigned char key_buf[DST_KEY_MAXSIZE];
+
+		loadkey(argv[isc_commandline_index], key_buf,
+			DST_KEY_MAXSIZE, &rdata);
+
+		if (both) {
+			emitds(DNS_DSDIGEST_SHA1, &rdata);
+			emitds(DNS_DSDIGEST_SHA256, &rdata);
+		} else
+			emitds(dtype, &rdata);
+	}
+
+	if (dns_rdataset_isassociated(&keyset))
+		dns_rdataset_disassociate(&keyset);
+	if (node != NULL)
+		dns_db_detachnode(db, &node);
+	if (db != NULL)
+		dns_db_detach(&db);
+	cleanup_logging(&log);
+	dst_lib_destroy();
+	isc_hash_destroy();
+	cleanup_entropy(&ectx);
+	dns_name_destroy();
+	if (verbose > 10)
+		isc_mem_stats(mctx, stdout);
+	isc_mem_destroy(&mctx);
+
+	fflush(stdout);
+	if (ferror(stdout)) {
+		fprintf(stderr, "write error\n");
+		return (1);
+	} else
+		return (0);
+}
diff --git a/contrib/bind9/bin/dnssec/dnssec-dsfromkey.docbook b/contrib/bind9/bin/dnssec/dnssec-dsfromkey.docbook
new file mode 100644
index 0000000..c2c6b85
--- /dev/null
+++ b/contrib/bind9/bin/dnssec/dnssec-dsfromkey.docbook
@@ -0,0 +1,214 @@
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+               "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+               [<!ENTITY mdash "&#8212;">]>
+<!--
+ - Copyright (C) 2008  Internet Systems Consortium, Inc. ("ISC")
+ -
+ - Permission to use, copy, modify, and/or 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-dsfromkey.docbook,v 1.6 2008/11/07 13:54:11 jreed Exp $ -->
+<refentry id="man.dnssec-dsfromkey">
+  <refentryinfo>
+    <date>November 29, 2008</date>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle><application>dnssec-dsfromkey</application></refentrytitle>
+    <manvolnum>8</manvolnum>
+    <refmiscinfo>BIND9</refmiscinfo>
+  </refmeta>
+
+  <refnamediv>
+    <refname><application>dnssec-dsfromkey</application></refname>
+    <refpurpose>DNSSEC DS RR generation tool</refpurpose>
+  </refnamediv>
+
+  <docinfo>
+    <copyright>
+      <year>2008</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+  </docinfo>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>dnssec-dsfromkey</command>
+      <arg><option>-v <replaceable class="parameter">level</replaceable></option></arg>
+      <arg><option>-1</option></arg>
+      <arg><option>-2</option></arg>
+      <arg><option>-a <replaceable class="parameter">alg</replaceable></option></arg>
+      <arg choice="req">keyfile</arg>
+    </cmdsynopsis>
+    <cmdsynopsis>
+      <command>dnssec-dsfromkey</command>
+      <arg choice="req">-s</arg>
+      <arg><option>-v <replaceable class="parameter">level</replaceable></option></arg>
+      <arg><option>-1</option></arg>
+      <arg><option>-2</option></arg>
+      <arg><option>-a <replaceable class="parameter">alg</replaceable></option></arg>
+      <arg><option>-c <replaceable class="parameter">class</replaceable></option></arg>
+      <arg><option>-d <replaceable class="parameter">dir</replaceable></option></arg>
+      <arg choice="req">dnsname</arg>
+   </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>DESCRIPTION</title>
+    <para><command>dnssec-dsfromkey</command>
+      outputs the Delegation Signer (DS) resource record (RR), as defined in
+      RFC 3658 and RFC 4509, for the given key(s).
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>OPTIONS</title>
+
+    <variablelist>
+      <varlistentry>
+        <term>-1</term>
+        <listitem>
+          <para>
+            Use SHA-1 as the digest algorithm (the default is to use
+            both SHA-1 and SHA-256).
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>-2</term>
+        <listitem>
+          <para>
+            Use SHA-256 as the digest algorithm.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>-a <replaceable class="parameter">algorithm</replaceable></term>
+        <listitem>
+          <para>
+            Select the digest algorithm. The value of
+            <option>algorithm</option> must be one of SHA-1 (SHA1) or
+            SHA-256 (SHA256). These values are case insensitive.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>-v <replaceable class="parameter">level</replaceable></term>
+        <listitem>
+          <para>
+            Sets the debugging level.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>-s</term>
+        <listitem>
+          <para>
+            Keyset mode: in place of the keyfile name, the argument is
+            the DNS domain name of a keyset file. Following options make sense
+            only in this mode.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>-c <replaceable class="parameter">class</replaceable></term>
+        <listitem>
+          <para>
+            Specifies the DNS class (default is IN), useful only
+            in the keyset mode.
+          </para>
+	  </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>-d <replaceable class="parameter">directory</replaceable></term>
+        <listitem>
+          <para>
+            Look for <filename>keyset</filename> files in
+            <option>directory</option> as the directory, ignored when
+            not in the keyset mode.
+          </para>
+        </listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>EXAMPLE</title>
+    <para>
+      To build the SHA-256 DS RR from the
+      <userinput>Kexample.com.+003+26160</userinput>
+      keyfile name, the following command would be issued:
+    </para>
+    <para><userinput>dnssec-dsfromkey -2 Kexample.com.+003+26160</userinput>
+    </para>
+    <para>
+      The command would print something like:
+    </para>
+    <para><userinput>example.com. IN DS 26160 5 2 3A1EADA7A74B8D0BA86726B0C227AA85AB8BBD2B2004F41A868A54F0 C5EA0B94</userinput>
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>FILES</title>
+    <para>
+      The keyfile can be designed by the key identification
+      <filename>Knnnn.+aaa+iiiii</filename> or the full file name
+      <filename>Knnnn.+aaa+iiiii.key</filename> as generated by
+      <refentrytitle>dnssec-keygen</refentrytitle><manvolnum>8</manvolnum>.
+    </para>
+    <para>
+      The keyset file name is built from the <option>directory</option>,
+      the string <filename>keyset-</filename> and the
+      <option>dnsname</option>.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>CAVEAT</title>
+    <para>
+      A keyfile error can give a "file not found" even if the file exists.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>SEE ALSO</title>
+    <para><citerefentry>
+        <refentrytitle>dnssec-keygen</refentrytitle><manvolnum>8</manvolnum>
+      </citerefentry>,
+      <citerefentry>
+        <refentrytitle>dnssec-signzone</refentrytitle><manvolnum>8</manvolnum>
+      </citerefentry>,
+      <citetitle>BIND 9 Administrator Reference Manual</citetitle>,
+      <citetitle>RFC 3658</citetitle>,
+      <citetitle>RFC 4509</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-dsfromkey.html b/contrib/bind9/bin/dnssec/dnssec-dsfromkey.html
new file mode 100644
index 0000000..72dfd3a
--- /dev/null
+++ b/contrib/bind9/bin/dnssec/dnssec-dsfromkey.html
@@ -0,0 +1,133 @@
+<!--
+ - Copyright (C) 2008  Internet Systems Consortium, Inc. ("ISC")
+ -
+ - Permission to use, copy, modify, and/or 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-dsfromkey.html,v 1.5 2008/11/08 01:11:47 tbox Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>dnssec-dsfromkey</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="man.dnssec-dsfromkey"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p><span class="application">dnssec-dsfromkey</span> &#8212; DNSSEC DS RR generation tool</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="cmdsynopsis"><p><code class="command">dnssec-dsfromkey</code>  [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] [<code class="option">-1</code>] [<code class="option">-2</code>] [<code class="option">-a <em class="replaceable"><code>alg</code></em></code>] {keyfile}</p></div>
+<div class="cmdsynopsis"><p><code class="command">dnssec-dsfromkey</code>  {-s} [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] [<code class="option">-1</code>] [<code class="option">-2</code>] [<code class="option">-a <em class="replaceable"><code>alg</code></em></code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-d <em class="replaceable"><code>dir</code></em></code>] {dnsname}</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2543424"></a><h2>DESCRIPTION</h2>
+<p><span><strong class="command">dnssec-dsfromkey</strong></span>
+      outputs the Delegation Signer (DS) resource record (RR), as defined in
+      RFC 3658 and RFC 4509, for the given key(s).
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2543435"></a><h2>OPTIONS</h2>
+<div class="variablelist"><dl>
+<dt><span class="term">-1</span></dt>
+<dd><p>
+            Use SHA-1 as the digest algorithm (the default is to use
+            both SHA-1 and SHA-256).
+          </p></dd>
+<dt><span class="term">-2</span></dt>
+<dd><p>
+            Use SHA-256 as the digest algorithm.
+          </p></dd>
+<dt><span class="term">-a <em class="replaceable"><code>algorithm</code></em></span></dt>
+<dd><p>
+            Select the digest algorithm. The value of
+            <code class="option">algorithm</code> must be one of SHA-1 (SHA1) or
+            SHA-256 (SHA256). These values are case insensitive.
+          </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><span class="term">-s</span></dt>
+<dd><p>
+            Keyset mode: in place of the keyfile name, the argument is
+            the DNS domain name of a keyset file. Following options make sense
+            only in this mode.
+          </p></dd>
+<dt><span class="term">-c <em class="replaceable"><code>class</code></em></span></dt>
+<dd><p>
+            Specifies the DNS class (default is IN), useful only
+            in the keyset mode.
+          </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, ignored when
+            not in the keyset mode.
+          </p></dd>
+</dl></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2543563"></a><h2>EXAMPLE</h2>
+<p>
+      To build the SHA-256 DS RR from the
+      <strong class="userinput"><code>Kexample.com.+003+26160</code></strong>
+      keyfile name, the following command would be issued:
+    </p>
+<p><strong class="userinput"><code>dnssec-dsfromkey -2 Kexample.com.+003+26160</code></strong>
+    </p>
+<p>
+      The command would print something like:
+    </p>
+<p><strong class="userinput"><code>example.com. IN DS 26160 5 2 3A1EADA7A74B8D0BA86726B0C227AA85AB8BBD2B2004F41A868A54F0 C5EA0B94</code></strong>
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2543593"></a><h2>FILES</h2>
+<p>
+      The keyfile can be designed by the key identification
+      <code class="filename">Knnnn.+aaa+iiiii</code> or the full file name
+      <code class="filename">Knnnn.+aaa+iiiii.key</code> as generated by
+      <span class="refentrytitle">dnssec-keygen</span>(8).
+    </p>
+<p>
+      The keyset file name is built from the <code class="option">directory</code>,
+      the string <code class="filename">keyset-</code> and the
+      <code class="option">dnsname</code>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2543628"></a><h2>CAVEAT</h2>
+<p>
+      A keyfile error can give a "file not found" even if the file exists.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2543638"></a><h2>SEE ALSO</h2>
+<p><span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>,
+      <span class="citerefentry"><span class="refentrytitle">dnssec-signzone</span>(8)</span>,
+      <em class="citetitle">BIND 9 Administrator Reference Manual</em>,
+      <em class="citetitle">RFC 3658</em>,
+      <em class="citetitle">RFC 4509</em>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2543674"></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-keyfromlabel.8 b/contrib/bind9/bin/dnssec/dnssec-keyfromlabel.8
new file mode 100644
index 0000000..6222058
--- /dev/null
+++ b/contrib/bind9/bin/dnssec/dnssec-keyfromlabel.8
@@ -0,0 +1,149 @@
+.\" Copyright (C) 2008 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,
+.\" 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-keyfromlabel.8,v 1.6 2008/11/08 01:11:47 tbox Exp $
+.\"
+.hy 0
+.ad l
+.\"     Title: dnssec\-keyfromlabel
+.\"    Author: 
+.\" Generator: DocBook XSL Stylesheets v1.71.1 <http://docbook.sf.net/>
+.\"      Date: February 8, 2008
+.\"    Manual: BIND9
+.\"    Source: BIND9
+.\"
+.TH "DNSSEC\-KEYFROMLABEL" "8" "February 8, 2008" "BIND9" "BIND9"
+.\" disable hyphenation
+.nh
+.\" disable justification (adjust text to left margin only)
+.ad l
+.SH "NAME"
+dnssec\-keyfromlabel \- DNSSEC key generation tool
+.SH "SYNOPSIS"
+.HP 20
+\fBdnssec\-keyfromlabel\fR {\-a\ \fIalgorithm\fR} {\-l\ \fIlabel\fR} [\fB\-c\ \fR\fB\fIclass\fR\fR] [\fB\-f\ \fR\fB\fIflag\fR\fR] [\fB\-k\fR] [\fB\-n\ \fR\fB\fInametype\fR\fR] [\fB\-p\ \fR\fB\fIprotocol\fR\fR] [\fB\-t\ \fR\fB\fItype\fR\fR] [\fB\-v\ \fR\fB\fIlevel\fR\fR] {name}
+.SH "DESCRIPTION"
+.PP
+\fBdnssec\-keyfromlabel\fR
+gets keys with the given label from a crypto hardware and builds key files for DNSSEC (Secure DNS), as defined in RFC 2535 and RFC 4034.
+.SH "OPTIONS"
+.PP
+\-a \fIalgorithm\fR
+.RS 4
+Selects the cryptographic algorithm. The value of
+\fBalgorithm\fR
+must be one of RSAMD5 (RSA) or RSASHA1, DSA, NSEC3RSASHA1, NSEC3DSA or DH (Diffie Hellman). These values are case insensitive.
+.sp
+Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement algorithm, and DSA is recommended.
+.sp
+Note 2: DH automatically sets the \-k flag.
+.RE
+.PP
+\-l \fIlabel\fR
+.RS 4
+Specifies the label of keys in the crypto hardware (PKCS#11 device).
+.RE
+.PP
+\-n \fInametype\fR
+.RS 4
+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.
+.RE
+.PP
+\-c \fIclass\fR
+.RS 4
+Indicates that the DNS record containing the key should have the specified class. If not specified, class IN is used.
+.RE
+.PP
+\-f \fIflag\fR
+.RS 4
+Set the specified flag in the flag field of the KEY/DNSKEY record. The only recognized flag is KSK (Key Signing Key) DNSKEY.
+.RE
+.PP
+\-h
+.RS 4
+Prints a short summary of the options and arguments to
+\fBdnssec\-keygen\fR.
+.RE
+.PP
+\-k
+.RS 4
+Generate KEY records rather than DNSKEY records.
+.RE
+.PP
+\-p \fIprotocol\fR
+.RS 4
+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.
+.RE
+.PP
+\-t \fItype\fR
+.RS 4
+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.
+.RE
+.PP
+\-v \fIlevel\fR
+.RS 4
+Sets the debugging level.
+.RE
+.SH "GENERATED KEY FILES"
+.PP
+When
+\fBdnssec\-keyfromlabel\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 files it has generated.
+.TP 4
+\(bu
+\fInnnn\fR
+is the key name.
+.TP 4
+\(bu
+\fIaaa\fR
+is the numeric representation of the algorithm.
+.TP 4
+\(bu
+\fIiiiii\fR
+is the key identifier (or footprint).
+.PP
+\fBdnssec\-keyfromlabel\fR
+creates two files, 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
+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.
+.SH "SEE ALSO"
+.PP
+\fBdnssec\-keygen\fR(8),
+\fBdnssec\-signzone\fR(8),
+BIND 9 Administrator Reference Manual,
+RFC 2539,
+RFC 2845,
+RFC 4033.
+.SH "AUTHOR"
+.PP
+Internet Systems Consortium
+.SH "COPYRIGHT"
+Copyright \(co 2008 Internet Systems Consortium, Inc. ("ISC")
+.br
diff --git a/contrib/bind9/bin/dnssec/dnssec-keyfromlabel.c b/contrib/bind9/bin/dnssec/dnssec-keyfromlabel.c
new file mode 100644
index 0000000..e7587c3
--- /dev/null
+++ b/contrib/bind9/bin/dnssec/dnssec-keyfromlabel.c
@@ -0,0 +1,327 @@
+/*
+ * Copyright (C) 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or 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-keyfromlabel.c,v 1.4 2008/09/24 02:46:21 marka Exp $ */
+
+/*! \file */
+
+#include <config.h>
+
+#include <stdlib.h>
+
+#include <isc/buffer.h>
+#include <isc/commandline.h>
+#include <isc/entropy.h>
+#include <isc/mem.h>
+#include <isc/region.h>
+#include <isc/string.h>
+#include <isc/util.h>
+
+#include <dns/fixedname.h>
+#include <dns/keyvalues.h>
+#include <dns/log.h>
+#include <dns/name.h>
+#include <dns/rdataclass.h>
+#include <dns/result.h>
+#include <dns/secalg.h>
+
+#include <dst/dst.h>
+
+#include "dnssectool.h"
+
+#define MAX_RSA 4096 /* should be long enough... */
+
+const char *program = "dnssec-keyfromlabel";
+int verbose;
+
+static const char *algs = "RSA | RSAMD5 | DH | DSA | RSASHA1 |"
+			  " NSEC3DSA | NSEC3RSASHA1";
+
+static void
+usage(void) {
+	fprintf(stderr, "Usage:\n");
+	fprintf(stderr, "    %s -a alg -l label [options] name\n\n",
+		program);
+	fprintf(stderr, "Version: %s\n", VERSION);
+	fprintf(stderr, "Required options:\n");
+	fprintf(stderr, "    -a algorithm: %s\n", algs);
+	fprintf(stderr, "    -l label: label of the key\n");
+	fprintf(stderr, "    name: owner of the key\n");
+	fprintf(stderr, "Other options:\n");
+	fprintf(stderr, "    -n nametype: ZONE | HOST | ENTITY | USER | OTHER\n");
+	fprintf(stderr, "        (DNSKEY generation defaults to ZONE\n");
+	fprintf(stderr, "    -c <class> (default: IN)\n");
+	fprintf(stderr, "    -f keyflag: KSK\n");
+	fprintf(stderr, "    -t <type>: "
+		"AUTHCONF | NOAUTHCONF | NOAUTH | NOCONF "
+		"(default: AUTHCONF)\n");
+	fprintf(stderr, "    -p <protocol>: "
+	       "default: 3 [dnssec]\n");
+	fprintf(stderr, "    -v <verbose level>\n");
+	fprintf(stderr, "    -k : generate a TYPE=KEY key\n");
+	fprintf(stderr, "Output:\n");
+	fprintf(stderr, "     K<name>+<alg>+<id>.key, "
+		"K<name>+<alg>+<id>.private\n");
+
+	exit (-1);
+}
+
+int
+main(int argc, char **argv) {
+	char		*algname = NULL, *nametype = NULL, *type = NULL;
+	char		*classname = NULL;
+	char		*endp;
+	dst_key_t	*key = NULL, *oldkey;
+	dns_fixedname_t	fname;
+	dns_name_t	*name;
+	isc_uint16_t	flags = 0, ksk = 0;
+	dns_secalg_t	alg;
+	isc_boolean_t	null_key = ISC_FALSE;
+	isc_mem_t	*mctx = NULL;
+	int		ch;
+	int		protocol = -1, signatory = 0;
+	isc_result_t	ret;
+	isc_textregion_t r;
+	char		filename[255];
+	isc_buffer_t	buf;
+	isc_log_t	*log = NULL;
+	isc_entropy_t	*ectx = NULL;
+	dns_rdataclass_t rdclass;
+	int		options = DST_TYPE_PRIVATE | DST_TYPE_PUBLIC;
+	char		*label = NULL;
+
+	if (argc == 1)
+		usage();
+
+	RUNTIME_CHECK(isc_mem_create(0, 0, &mctx) == ISC_R_SUCCESS);
+
+	dns_result_register();
+
+	isc_commandline_errprint = ISC_FALSE;
+
+	while ((ch = isc_commandline_parse(argc, argv,
+					 "a:c:f:kl:n:p:t:v:h")) != -1)
+	{
+	    switch (ch) {
+		case 'a':
+			algname = isc_commandline_argument;
+			break;
+		case 'c':
+			classname = isc_commandline_argument;
+			break;
+		case 'f':
+			if (strcasecmp(isc_commandline_argument, "KSK") == 0)
+				ksk = DNS_KEYFLAG_KSK;
+			else
+				fatal("unknown flag '%s'",
+				      isc_commandline_argument);
+			break;
+		case 'k':
+			options |= DST_TYPE_KEY;
+			break;
+		case 'l':
+			label = isc_commandline_argument;
+			break;
+		case 'n':
+			nametype = isc_commandline_argument;
+			break;
+		case 'p':
+			protocol = strtol(isc_commandline_argument, &endp, 10);
+			if (*endp != '\0' || protocol < 0 || protocol > 255)
+				fatal("-p must be followed by a number "
+				      "[0..255]");
+			break;
+		case 't':
+			type = isc_commandline_argument;
+			break;
+		case 'v':
+			verbose = strtol(isc_commandline_argument, &endp, 0);
+			if (*endp != '\0')
+				fatal("-v must be followed by a number");
+			break;
+
+		case '?':
+			if (isc_commandline_option != '?')
+				fprintf(stderr, "%s: invalid argument -%c\n",
+					program, isc_commandline_option);
+		case 'h':
+			usage();
+
+		default:
+			fprintf(stderr, "%s: unhandled option -%c\n",
+				program, isc_commandline_option);
+			exit(1);
+		}
+	}
+
+	if (ectx == NULL)
+		setup_entropy(mctx, NULL, &ectx);
+	ret = dst_lib_init(mctx, ectx,
+			   ISC_ENTROPY_BLOCKING | ISC_ENTROPY_GOODONLY);
+	if (ret != ISC_R_SUCCESS)
+		fatal("could not initialize dst");
+
+	setup_logging(verbose, mctx, &log);
+
+	if (label == NULL)
+		fatal("the key label was not specified");
+	if (argc < isc_commandline_index + 1)
+		fatal("the key name was not specified");
+	if (argc > isc_commandline_index + 1)
+		fatal("extraneous arguments");
+
+	if (algname == NULL)
+		fatal("no algorithm was specified");
+	if (strcasecmp(algname, "RSA") == 0) {
+		fprintf(stderr, "The use of RSA (RSAMD5) is not recommended.\n"
+				"If you still wish to use RSA (RSAMD5) please "
+				"specify \"-a RSAMD5\"\n");
+		return (1);
+	} else {
+		r.base = algname;
+		r.length = strlen(algname);
+		ret = dns_secalg_fromtext(&alg, &r);
+		if (ret != ISC_R_SUCCESS)
+			fatal("unknown algorithm %s", algname);
+		if (alg == DST_ALG_DH)
+			options |= DST_TYPE_KEY;
+	}
+
+	if (type != NULL && (options & DST_TYPE_KEY) != 0) {
+		if (strcasecmp(type, "NOAUTH") == 0)
+			flags |= DNS_KEYTYPE_NOAUTH;
+		else if (strcasecmp(type, "NOCONF") == 0)
+			flags |= DNS_KEYTYPE_NOCONF;
+		else if (strcasecmp(type, "NOAUTHCONF") == 0) {
+			flags |= (DNS_KEYTYPE_NOAUTH | DNS_KEYTYPE_NOCONF);
+		}
+		else if (strcasecmp(type, "AUTHCONF") == 0)
+			/* nothing */;
+		else
+			fatal("invalid type %s", type);
+	}
+
+	if (nametype == NULL) {
+		if ((options & DST_TYPE_KEY) != 0) /* KEY */
+			fatal("no nametype specified");
+		flags |= DNS_KEYOWNER_ZONE;	/* DNSKEY */
+	} else if (strcasecmp(nametype, "zone") == 0)
+		flags |= DNS_KEYOWNER_ZONE;
+	else if ((options & DST_TYPE_KEY) != 0)	{ /* KEY */
+		if (strcasecmp(nametype, "host") == 0 ||
+			 strcasecmp(nametype, "entity") == 0)
+			flags |= DNS_KEYOWNER_ENTITY;
+		else if (strcasecmp(nametype, "user") == 0)
+			flags |= DNS_KEYOWNER_USER;
+		else
+			fatal("invalid KEY nametype %s", nametype);
+	} else if (strcasecmp(nametype, "other") != 0) /* DNSKEY */
+		fatal("invalid DNSKEY nametype %s", nametype);
+
+	rdclass = strtoclass(classname);
+
+	if ((options & DST_TYPE_KEY) != 0)  /* KEY */
+		flags |= signatory;
+	else if ((flags & DNS_KEYOWNER_ZONE) != 0) /* DNSKEY */
+		flags |= ksk;
+
+	if (protocol == -1)
+		protocol = DNS_KEYPROTO_DNSSEC;
+	else if ((options & DST_TYPE_KEY) == 0 &&
+		 protocol != DNS_KEYPROTO_DNSSEC)
+		fatal("invalid DNSKEY protocol: %d", protocol);
+
+	if ((flags & DNS_KEYFLAG_TYPEMASK) == DNS_KEYTYPE_NOKEY) {
+		if ((flags & DNS_KEYFLAG_SIGNATORYMASK) != 0)
+			fatal("specified null key with signing authority");
+	}
+
+	if ((flags & DNS_KEYFLAG_OWNERMASK) == DNS_KEYOWNER_ZONE &&
+	    alg == DNS_KEYALG_DH)
+		fatal("a key with algorithm '%s' cannot be a zone key",
+		      algname);
+
+	dns_fixedname_init(&fname);
+	name = dns_fixedname_name(&fname);
+	isc_buffer_init(&buf, argv[isc_commandline_index],
+			strlen(argv[isc_commandline_index]));
+	isc_buffer_add(&buf, strlen(argv[isc_commandline_index]));
+	ret = dns_name_fromtext(name, &buf, dns_rootname, ISC_FALSE, NULL);
+	if (ret != ISC_R_SUCCESS)
+		fatal("invalid key name %s: %s", argv[isc_commandline_index],
+		      isc_result_totext(ret));
+
+	if ((flags & DNS_KEYFLAG_TYPEMASK) == DNS_KEYTYPE_NOKEY)
+		null_key = ISC_TRUE;
+
+	isc_buffer_init(&buf, filename, sizeof(filename) - 1);
+
+	/* associate the key */
+	ret = dst_key_fromlabel(name, alg, flags, protocol,
+				rdclass, "", label, NULL, mctx, &key);
+	isc_entropy_stopcallbacksources(ectx);
+
+	if (ret != ISC_R_SUCCESS) {
+		char namestr[DNS_NAME_FORMATSIZE];
+		char algstr[ALG_FORMATSIZE];
+		dns_name_format(name, namestr, sizeof(namestr));
+		alg_format(alg, algstr, sizeof(algstr));
+		fatal("failed to generate key %s/%s: %s\n",
+		      namestr, algstr, isc_result_totext(ret));
+		exit(-1);
+	}
+
+	/*
+	 * Try to read a key with the same name, alg and id from disk.
+	 * If there is one we must continue generating a new one
+	 * unless we were asked to generate a null key, in which
+	 * case we return failure.
+	 */
+	ret = dst_key_fromfile(name, dst_key_id(key), alg,
+			       DST_TYPE_PRIVATE, NULL, mctx, &oldkey);
+	/* do not overwrite an existing key  */
+	if (ret == ISC_R_SUCCESS) {
+		isc_buffer_clear(&buf);
+		ret = dst_key_buildfilename(key, 0, NULL, &buf);
+		fprintf(stderr, "%s: %s already exists\n",
+			program, filename);
+		dst_key_free(&key);
+		exit (1);
+	}
+
+	ret = dst_key_tofile(key, options, NULL);
+	if (ret != ISC_R_SUCCESS) {
+		char keystr[KEY_FORMATSIZE];
+		key_format(key, keystr, sizeof(keystr));
+		fatal("failed to write key %s: %s\n", keystr,
+		      isc_result_totext(ret));
+	}
+
+	isc_buffer_clear(&buf);
+	ret = dst_key_buildfilename(key, 0, NULL, &buf);
+	printf("%s\n", filename);
+	dst_key_free(&key);
+
+	cleanup_logging(&log);
+	cleanup_entropy(&ectx);
+	dst_lib_destroy();
+	dns_name_destroy();
+	if (verbose > 10)
+		isc_mem_stats(mctx, stdout);
+	isc_mem_destroy(&mctx);
+
+	return (0);
+}
diff --git a/contrib/bind9/bin/dnssec/dnssec-keyfromlabel.docbook b/contrib/bind9/bin/dnssec/dnssec-keyfromlabel.docbook
new file mode 100644
index 0000000..2bcf0a4
--- /dev/null
+++ b/contrib/bind9/bin/dnssec/dnssec-keyfromlabel.docbook
@@ -0,0 +1,265 @@
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+               "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+	       [<!ENTITY mdash "&#8212;">]>
+<!--
+ - Copyright (C) 2008  Internet Systems Consortium, Inc. ("ISC")
+ -
+ - Permission to use, copy, modify, and/or 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-keyfromlabel.docbook,v 1.6 2008/11/07 13:54:11 jreed Exp $ -->
+<refentry id="man.dnssec-keyfromlabel">
+  <refentryinfo>
+    <date>February 8, 2008</date>
+  </refentryinfo>
+
+  <refmeta>
+    <refentrytitle><application>dnssec-keyfromlabel</application></refentrytitle>
+    <manvolnum>8</manvolnum>
+    <refmiscinfo>BIND9</refmiscinfo>
+  </refmeta>
+
+  <refnamediv>
+    <refname><application>dnssec-keyfromlabel</application></refname>
+    <refpurpose>DNSSEC key generation tool</refpurpose>
+  </refnamediv>
+
+  <docinfo>
+    <copyright>
+      <year>2008</year>
+      <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
+    </copyright>
+  </docinfo>
+
+  <refsynopsisdiv>
+    <cmdsynopsis>
+      <command>dnssec-keyfromlabel</command>
+      <arg choice="req">-a <replaceable class="parameter">algorithm</replaceable></arg>
+      <arg choice="req">-l <replaceable class="parameter">label</replaceable></arg>
+      <arg><option>-c <replaceable class="parameter">class</replaceable></option></arg>
+      <arg><option>-f <replaceable class="parameter">flag</replaceable></option></arg>
+      <arg><option>-k</option></arg>
+      <arg><option>-n <replaceable class="parameter">nametype</replaceable></option></arg>
+      <arg><option>-p <replaceable class="parameter">protocol</replaceable></option></arg>
+      <arg><option>-t <replaceable class="parameter">type</replaceable></option></arg>
+      <arg><option>-v <replaceable class="parameter">level</replaceable></option></arg>
+      <arg choice="req">name</arg>
+    </cmdsynopsis>
+  </refsynopsisdiv>
+
+  <refsect1>
+    <title>DESCRIPTION</title>
+    <para><command>dnssec-keyfromlabel</command>
+      gets keys with the given label from a crypto hardware and builds
+      key files for DNSSEC (Secure DNS), as defined in RFC 2535
+      and RFC 4034.  
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>OPTIONS</title>
+
+    <variablelist>
+      <varlistentry>
+        <term>-a <replaceable class="parameter">algorithm</replaceable></term>
+        <listitem>
+	  <para>
+	    Selects the cryptographic algorithm.  The value of
+	    <option>algorithm</option> must be one of RSAMD5 (RSA)
+	    or RSASHA1, DSA, NSEC3RSASHA1, NSEC3DSA or DH (Diffie Hellman).
+	    These values are case insensitive.
+	  </para>
+          <para>
+            Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement
+            algorithm, and DSA is recommended.
+          </para>
+          <para>
+            Note 2: DH automatically sets the -k flag.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>-l <replaceable class="parameter">label</replaceable></term>
+        <listitem>
+          <para>
+            Specifies the label of keys in the crypto hardware
+            (PKCS#11 device).
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>-n <replaceable class="parameter">nametype</replaceable></term>
+        <listitem>
+          <para>
+            Specifies the owner type of the key.  The value of
+            <option>nametype</option> 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.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>-c <replaceable class="parameter">class</replaceable></term>
+        <listitem>
+          <para>
+            Indicates that the DNS record containing the key should have
+            the specified class.  If not specified, class IN is used.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>-f <replaceable class="parameter">flag</replaceable></term>
+        <listitem>
+          <para>
+            Set the specified flag in the flag field of the KEY/DNSKEY record.
+            The only recognized flag is KSK (Key Signing Key) DNSKEY.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>-h</term>
+        <listitem>
+          <para>
+            Prints a short summary of the options and arguments to
+            <command>dnssec-keygen</command>.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>-k</term>
+        <listitem>
+          <para>
+            Generate KEY records rather than DNSKEY records.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>-p <replaceable class="parameter">protocol</replaceable></term>
+        <listitem>
+          <para>
+            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.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>-t <replaceable class="parameter">type</replaceable></term>
+        <listitem>
+          <para>
+            Indicates the use of the key.  <option>type</option> 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.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>-v <replaceable class="parameter">level</replaceable></term>
+        <listitem>
+          <para>
+            Sets the debugging level.
+          </para>
+        </listitem>
+      </varlistentry>
+
+    </variablelist>
+  </refsect1>
+
+  <refsect1>
+    <title>GENERATED KEY FILES</title>
+    <para>
+      When <command>dnssec-keyfromlabel</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 files it has generated.
+    </para>
+    <itemizedlist>
+      <listitem>
+        <para><filename>nnnn</filename> is the key name.
+        </para>
+      </listitem>
+      <listitem>
+        <para><filename>aaa</filename> is the numeric representation
+          of the
+          algorithm.
+        </para>
+      </listitem>
+      <listitem>
+        <para><filename>iiiii</filename> is the key identifier (or
+          footprint).
+        </para>
+      </listitem>
+    </itemizedlist>
+    <para><command>dnssec-keyfromlabel</command> 
+      creates two files, with names based
+      on the printed string.  <filename>Knnnn.+aaa+iiiii.key</filename>
+      contains the public key, and
+      <filename>Knnnn.+aaa+iiiii.private</filename> contains the
+      private
+      key.
+    </para>
+    <para>
+      The <filename>.key</filename> file contains a DNS KEY record
+      that
+      can be inserted into a zone file (directly or with a $INCLUDE
+      statement).
+    </para>
+    <para>
+      The <filename>.private</filename> file contains algorithm
+      specific
+      fields.  For obvious security reasons, this file does not have
+      general read permission.
+    </para>
+  </refsect1>
+
+  <refsect1>
+    <title>SEE ALSO</title>
+    <para><citerefentry>
+        <refentrytitle>dnssec-keygen</refentrytitle><manvolnum>8</manvolnum>
+      </citerefentry>,
+      <citerefentry>
+        <refentrytitle>dnssec-signzone</refentrytitle><manvolnum>8</manvolnum>
+      </citerefentry>,
+      <citetitle>BIND 9 Administrator Reference Manual</citetitle>,
+      <citetitle>RFC 2539</citetitle>,
+      <citetitle>RFC 2845</citetitle>,
+      <citetitle>RFC 4033</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-keyfromlabel.html b/contrib/bind9/bin/dnssec/dnssec-keyfromlabel.html
new file mode 100644
index 0000000..cbea64b
--- /dev/null
+++ b/contrib/bind9/bin/dnssec/dnssec-keyfromlabel.html
@@ -0,0 +1,171 @@
+<!--
+ - Copyright (C) 2008 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,
+ - 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-keyfromlabel.html,v 1.5 2008/10/15 01:11:35 tbox Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>dnssec-keyfromlabel</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
+</head>
+<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
+<a name="man.dnssec-keyfromlabel"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p><span class="application">dnssec-keyfromlabel</span> &#8212; DNSSEC key generation tool</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="cmdsynopsis"><p><code class="command">dnssec-keyfromlabel</code>  {-a <em class="replaceable"><code>algorithm</code></em>} {-l <em class="replaceable"><code>label</code></em>} [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-f <em class="replaceable"><code>flag</code></em></code>] [<code class="option">-k</code>] [<code class="option">-n <em class="replaceable"><code>nametype</code></em></code>] [<code class="option">-p <em class="replaceable"><code>protocol</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="id2543413"></a><h2>DESCRIPTION</h2>
+<p><span><strong class="command">dnssec-keyfromlabel</strong></span>
+      gets keys with the given label from a crypto hardware and builds
+      key files for DNSSEC (Secure DNS), as defined in RFC 2535
+      and RFC 4034.  
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2543425"></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, NSEC3RSASHA1, NSEC3DSA or DH (Diffie Hellman).
+	    These values are case insensitive.
+	  </p>
+<p>
+            Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement
+            algorithm, and DSA is recommended.
+          </p>
+<p>
+            Note 2: DH automatically sets the -k flag.
+          </p>
+</dd>
+<dt><span class="term">-l <em class="replaceable"><code>label</code></em></span></dt>
+<dd><p>
+            Specifies the label of keys in the crypto hardware
+            (PKCS#11 device).
+          </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><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><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><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><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><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="id2543619"></a><h2>GENERATED KEY FILES</h2>
+<p>
+      When <span><strong class="command">dnssec-keyfromlabel</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 files 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><code class="filename">iiiii</code> is the key identifier (or
+          footprint).
+        </p></li>
+</ul></div>
+<p><span><strong class="command">dnssec-keyfromlabel</strong></span> 
+      creates two files, with names based
+      on the printed string.  <code class="filename">Knnnn.+aaa+iiiii.key</code>
+      contains the public key, and
+      <code class="filename">Knnnn.+aaa+iiiii.private</code> contains the
+      private
+      key.
+    </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 <code class="filename">.private</code> file contains algorithm
+      specific
+      fields.  For obvious security reasons, this file does not have
+      general read permission.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2543691"></a><h2>SEE ALSO</h2>
+<p><span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>,
+      <span class="citerefentry"><span class="refentrytitle">dnssec-signzone</span>(8)</span>,
+      <em class="citetitle">BIND 9 Administrator Reference Manual</em>,
+      <em class="citetitle">RFC 2539</em>,
+      <em class="citetitle">RFC 2845</em>,
+      <em class="citetitle">RFC 4033</em>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2543731"></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-keygen.8 b/contrib/bind9/bin/dnssec/dnssec-keygen.8
index e667ba9..13db3d9 100644
--- a/contrib/bind9/bin/dnssec/dnssec-keygen.8
+++ b/contrib/bind9/bin/dnssec/dnssec-keygen.8
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: dnssec-keygen.8,v 1.23.18.16 2008/10/16 01:29:40 tbox Exp $
+.\" $Id: dnssec-keygen.8,v 1.40 2008/10/15 01:11:35 tbox Exp $
 .\"
 .hy 0
 .ad l
@@ -44,7 +44,7 @@ generates keys for DNSSEC (Secure DNS), as defined in RFC 2535 and RFC 4034. It
 .RS 4
 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.
+must be one of RSAMD5 (RSA) or RSASHA1, DSA, NSEC3RSASHA1, NSEC3DSA, 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
@@ -60,7 +60,7 @@ Specifies the number of bits in the key. The choice of key size depends on the a
 .RS 4
 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.
+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. Defaults to ZONE for DNSKEY generation.
 .RE
 .PP
 \-c \fIclass\fR
diff --git a/contrib/bind9/bin/dnssec/dnssec-keygen.c b/contrib/bind9/bin/dnssec/dnssec-keygen.c
index 0b57f6d..614d388 100644
--- a/contrib/bind9/bin/dnssec/dnssec-keygen.c
+++ b/contrib/bind9/bin/dnssec/dnssec-keygen.c
@@ -1,6 +1,19 @@
 /*
- * Portions Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 1999-2003  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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.
+ *
  * Portions Copyright (C) 1995-2000 by Network Associates, Inc.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -16,7 +29,7 @@
  * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dnssec-keygen.c,v 1.66.18.10 2007/08/28 07:19:55 tbox Exp $ */
+/* $Id: dnssec-keygen.c,v 1.81 2008/09/25 04:02:38 tbox Exp $ */
 
 /*! \file */
 
@@ -49,8 +62,9 @@
 const char *program = "dnssec-keygen";
 int verbose;
 
-static const char *algs = "RSA | RSAMD5 | DH | DSA | RSASHA1 | HMAC-MD5 |"
-			  " HMAC-SHA1 | HMAC-SHA224 | HMAC-SHA256 | "
+static const char *algs = "RSA | RSAMD5 | DH | DSA | RSASHA1 | NSEC3DSA |"
+			  " NSEC3RSASHA1 | HMAC-MD5 |"
+			  " HMAC-SHA1 | HMAC-SHA224 | HMAC-SHA256 |"
 			  " HMAC-SHA384 | HMAC-SHA512";
 
 static isc_boolean_t
@@ -61,7 +75,7 @@ dsa_size_ok(int size) {
 static void
 usage(void) {
 	fprintf(stderr, "Usage:\n");
-	fprintf(stderr, "    %s -a alg -b bits -n type [options] name\n\n",
+	fprintf(stderr, "    %s -a alg -b bits [-n type] [options] name\n\n",
 		program);
 	fprintf(stderr, "Version: %s\n", VERSION);
 	fprintf(stderr, "Required options:\n");
@@ -69,8 +83,10 @@ usage(void) {
 	fprintf(stderr, "    -b key size, in bits:\n");
 	fprintf(stderr, "        RSAMD5:\t\t[512..%d]\n", MAX_RSA);
 	fprintf(stderr, "        RSASHA1:\t\t[512..%d]\n", MAX_RSA);
+	fprintf(stderr, "        NSEC3RSASHA1:\t\t[512..%d]\n", MAX_RSA);
 	fprintf(stderr, "        DH:\t\t[128..4096]\n");
 	fprintf(stderr, "        DSA:\t\t[512..1024] and divisible by 64\n");
+	fprintf(stderr, "        NSEC3DSA:\t\t[512..1024] and divisible by 64\n");
 	fprintf(stderr, "        HMAC-MD5:\t[1..512]\n");
 	fprintf(stderr, "        HMAC-SHA1:\t[1..160]\n");
 	fprintf(stderr, "        HMAC-SHA224:\t[1..224]\n");
@@ -78,6 +94,7 @@ usage(void) {
 	fprintf(stderr, "        HMAC-SHA384:\t[1..384]\n");
 	fprintf(stderr, "        HMAC-SHA512:\t[1..512]\n");
 	fprintf(stderr, "    -n nametype: ZONE | HOST | ENTITY | USER | OTHER\n");
+	fprintf(stderr, "        (DNSKEY generation defaults to ZONE\n");
 	fprintf(stderr, "    name: owner of the key\n");
 	fprintf(stderr, "Other options:\n");
 	fprintf(stderr, "    -c <class> (default: IN)\n");
@@ -134,8 +151,10 @@ main(int argc, char **argv) {
 
 	dns_result_register();
 
+	isc_commandline_errprint = ISC_FALSE;
+
 	while ((ch = isc_commandline_parse(argc, argv,
-					   "a:b:c:d:ef:g:kn:t:p:s:r:v:h")) != -1)
+					 "a:b:c:d:ef:g:kn:t:p:s:r:v:h")) != -1)
 	{
 	    switch (ch) {
 		case 'a':
@@ -202,12 +221,17 @@ main(int argc, char **argv) {
 				fatal("-v must be followed by a number");
 			break;
 
+		case '?':
+			if (isc_commandline_option != '?')
+				fprintf(stderr, "%s: invalid argument -%c\n",
+					program, isc_commandline_option);
 		case 'h':
 			usage();
+
 		default:
-			fprintf(stderr, "%s: invalid argument -%c\n",
-				program, ch);
-			usage();
+			fprintf(stderr, "%s: unhandled option -%c\n",
+				program, isc_commandline_option);
+			exit(1);
 		}
 	}
 
@@ -282,6 +306,7 @@ main(int argc, char **argv) {
 	switch (alg) {
 	case DNS_KEYALG_RSAMD5:
 	case DNS_KEYALG_RSASHA1:
+	case DNS_KEYALG_NSEC3RSASHA1:
 		if (size != 0 && (size < 512 || size > MAX_RSA))
 			fatal("RSA key size %d out of range", size);
 		break;
@@ -290,6 +315,7 @@ main(int argc, char **argv) {
 			fatal("DH key size %d out of range", size);
 		break;
 	case DNS_KEYALG_DSA:
+	case DNS_KEYALG_NSEC3DSA:
 		if (size != 0 && !dsa_size_ok(size))
 			fatal("invalid DSS key size: %d", size);
 		break;
@@ -349,18 +375,20 @@ main(int argc, char **argv) {
 		break;
 	}
 
-	if (!(alg == DNS_KEYALG_RSAMD5 || alg == DNS_KEYALG_RSASHA1) &&
-	    rsa_exp != 0)
+	if (!(alg == DNS_KEYALG_RSAMD5 || alg == DNS_KEYALG_RSASHA1 ||
+	      alg == DNS_KEYALG_NSEC3RSASHA1) && rsa_exp != 0)
 		fatal("specified RSA exponent for a non-RSA key");
 
 	if (alg != DNS_KEYALG_DH && generator != 0)
 		fatal("specified DH generator for a non-DH key");
 
-	if (nametype == NULL)
-		fatal("no nametype specified");
-	if (strcasecmp(nametype, "zone") == 0)
+	if (nametype == NULL) {
+		if ((options & DST_TYPE_KEY) != 0) /* KEY / HMAC */
+			fatal("no nametype specified");
+		flags |= DNS_KEYOWNER_ZONE;	/* DNSKEY */
+	} else if (strcasecmp(nametype, "zone") == 0)
 		flags |= DNS_KEYOWNER_ZONE;
-	else if ((options & DST_TYPE_KEY) != 0)	{ /* KEY */
+	else if ((options & DST_TYPE_KEY) != 0)	{ /* KEY / HMAC */
 		if (strcasecmp(nametype, "host") == 0 ||
 			 strcasecmp(nametype, "entity") == 0)
 			flags |= DNS_KEYOWNER_ENTITY;
@@ -373,7 +401,7 @@ main(int argc, char **argv) {
 
 	rdclass = strtoclass(classname);
 
-	if ((options & DST_TYPE_KEY) != 0)  /* KEY */
+	if ((options & DST_TYPE_KEY) != 0)  /* KEY / HMAC */
 		flags |= signatory;
 	else if ((flags & DNS_KEYOWNER_ZONE) != 0) /* DNSKEY */
 		flags |= ksk;
diff --git a/contrib/bind9/bin/dnssec/dnssec-keygen.docbook b/contrib/bind9/bin/dnssec/dnssec-keygen.docbook
index ec7b69b..c267a1b 100644
--- a/contrib/bind9/bin/dnssec/dnssec-keygen.docbook
+++ b/contrib/bind9/bin/dnssec/dnssec-keygen.docbook
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: dnssec-keygen.docbook,v 1.7.18.13 2008/10/15 23:46:06 tbox Exp $ -->
+<!-- $Id: dnssec-keygen.docbook,v 1.22 2008/10/14 14:32:50 jreed Exp $ -->
 <refentry id="man.dnssec-keygen">
   <refentryinfo>
     <date>June 30, 2000</date>
@@ -92,13 +92,13 @@
           <para>
             Selects the cryptographic algorithm.  The value of
             <option>algorithm</option> must be one of RSAMD5 (RSA) or RSASHA1,
-            	      DSA, DH (Diffie Hellman), or HMAC-MD5.  These values
-            are case insensitive.
+	    DSA, NSEC3RSASHA1, NSEC3DSA, DH (Diffie Hellman), or HMAC-MD5.
+	    These values are case insensitive.
           </para>
           <para>
             Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement
-            algorithm,
-            and DSA is recommended.  For TSIG, HMAC-MD5 is mandatory.
+            algorithm, and DSA is recommended.  For TSIG, HMAC-MD5 is
+	    mandatory.
           </para>
           <para>
             Note 2: HMAC-MD5 and DH automatically set the -k flag.
@@ -130,8 +130,8 @@
             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.
+            These values are case insensitive.  Defaults to ZONE for DNSKEY
+	    generation.
           </para>
         </listitem>
       </varlistentry>
diff --git a/contrib/bind9/bin/dnssec/dnssec-keygen.html b/contrib/bind9/bin/dnssec/dnssec-keygen.html
index e0b0bfe..696ef88 100644
--- a/contrib/bind9/bin/dnssec/dnssec-keygen.html
+++ b/contrib/bind9/bin/dnssec/dnssec-keygen.html
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: dnssec-keygen.html,v 1.9.18.22 2008/10/16 01:29:40 tbox Exp $ -->
+<!-- $Id: dnssec-keygen.html,v 1.32 2008/10/15 01:11:35 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -47,13 +47,13 @@
 <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.
+	    DSA, NSEC3RSASHA1, NSEC3DSA, 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,
-            and DSA is recommended.  For TSIG, HMAC-MD5 is mandatory.
+            algorithm, and DSA is recommended.  For TSIG, HMAC-MD5 is
+	    mandatory.
           </p>
 <p>
             Note 2: HMAC-MD5 and DH automatically set the -k flag.
@@ -76,8 +76,8 @@
             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.
+            These values are case insensitive.  Defaults to ZONE for DNSKEY
+	    generation.
           </p></dd>
 <dt><span class="term">-c <em class="replaceable"><code>class</code></em></span></dt>
 <dd><p>
diff --git a/contrib/bind9/bin/dnssec/dnssec-signzone.8 b/contrib/bind9/bin/dnssec/dnssec-signzone.8
index 680960a..ca0ed36 100644
--- a/contrib/bind9/bin/dnssec/dnssec-signzone.8
+++ b/contrib/bind9/bin/dnssec/dnssec-signzone.8
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: dnssec-signzone.8,v 1.28.18.19 2008/10/16 01:29:40 tbox Exp $
+.\" $Id: dnssec-signzone.8,v 1.47 2008/10/15 01:11:35 tbox Exp $
 .\"
 .hy 0
 .ad l
@@ -33,7 +33,7 @@
 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\-I\ \fR\fB\fIinput\-format\fR\fR] [\fB\-j\ \fR\fB\fIjitter\fR\fR] [\fB\-N\ \fR\fB\fIsoa\-serial\-format\fR\fR] [\fB\-o\ \fR\fB\fIorigin\fR\fR] [\fB\-O\ \fR\fB\fIoutput\-format\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...]
+\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\-I\ \fR\fB\fIinput\-format\fR\fR] [\fB\-j\ \fR\fB\fIjitter\fR\fR] [\fB\-N\ \fR\fB\fIsoa\-serial\-format\fR\fR] [\fB\-o\ \fR\fB\fIorigin\fR\fR] [\fB\-O\ \fR\fB\fIoutput\-format\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] [\fB\-3\ \fR\fB\fIsalt\fR\fR] [\fB\-H\ \fR\fB\fIiterations\fR\fR] [\fB\-A\fR] {zonefile} [key...]
 .SH "DESCRIPTION"
 .PP
 \fBdnssec\-signzone\fR
@@ -212,6 +212,21 @@ Sets the debugging level.
 Ignore KSK flag on key when determining what to sign.
 .RE
 .PP
+\-3 \fIsalt\fR
+.RS 4
+Generate a NSEC3 chain with the given hex encoded salt. A dash (\fIsalt\fR) can be used to indicate that no salt is to be used when generating the NSEC3 chain.
+.RE
+.PP
+\-H \fIiterations\fR
+.RS 4
+When generating a NSEC3 chain use this many interations. The default is 100.
+.RE
+.PP
+\-A
+.RS 4
+When generating a NSEC3 chain set the OPTOUT flag on all NSEC3 records and do not generate NSEC3 records for insecure delegations.
+.RE
+.PP
 zonefile
 .RS 4
 The file containing the zone to be signed.
diff --git a/contrib/bind9/bin/dnssec/dnssec-signzone.c b/contrib/bind9/bin/dnssec/dnssec-signzone.c
index 9b49169..1da280f 100644
--- a/contrib/bind9/bin/dnssec/dnssec-signzone.c
+++ b/contrib/bind9/bin/dnssec/dnssec-signzone.c
@@ -1,6 +1,19 @@
 /*
- * Portions Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 1999-2003  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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.
+ *
  * Portions Copyright (C) 1995-2000 by Network Associates, Inc.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -16,7 +29,7 @@
  * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dnssec-signzone.c,v 1.177.18.26 2008/06/02 23:46:01 tbox Exp $ */
+/* $Id: dnssec-signzone.c,v 1.209.12.3 2009/01/18 23:25:15 marka Exp $ */
 
 /*! \file */
 
@@ -26,11 +39,13 @@
 #include <time.h>
 
 #include <isc/app.h>
+#include <isc/base32.h>
 #include <isc/commandline.h>
 #include <isc/entropy.h>
 #include <isc/event.h>
 #include <isc/file.h>
 #include <isc/hash.h>
+#include <isc/hex.h>
 #include <isc/mem.h>
 #include <isc/mutex.h>
 #include <isc/os.h>
@@ -38,10 +53,11 @@
 #include <isc/random.h>
 #include <isc/serial.h>
 #include <isc/stdio.h>
+#include <isc/stdlib.h>
 #include <isc/string.h>
 #include <isc/task.h>
-#include <isc/util.h>
 #include <isc/time.h>
+#include <isc/util.h>
 
 #include <dns/db.h>
 #include <dns/dbiterator.h>
@@ -54,7 +70,9 @@
 #include <dns/master.h>
 #include <dns/masterdump.h>
 #include <dns/nsec.h>
+#include <dns/nsec3.h>
 #include <dns/rdata.h>
+#include <dns/rdatalist.h>
 #include <dns/rdataset.h>
 #include <dns/rdataclass.h>
 #include <dns/rdatasetiter.h>
@@ -71,6 +89,13 @@
 const char *program = "dnssec-signzone";
 int verbose;
 
+typedef struct hashlist hashlist_t;
+
+static int nsec_datatype = dns_rdatatype_nsec;
+
+#define IS_NSEC3	(nsec_datatype == dns_rdatatype_nsec3)
+#define OPTOUT(x)	(((x) & DNS_NSEC3FLAG_OPTOUT) != 0)
+
 #define BUFSIZE 2048
 #define MAXDSKEYS 8
 
@@ -125,6 +150,7 @@ static dns_dbversion_t *gversion;	/* The database version */
 static dns_dbiterator_t *gdbiter;	/* The database iterator */
 static dns_rdataclass_t gclass;		/* The class */
 static dns_name_t *gorigin;		/* The database origin */
+static int nsec3flags = 0;
 static isc_task_t *master = NULL;
 static unsigned int ntasks = 0;
 static isc_boolean_t shuttingdown = ISC_FALSE, finished = ISC_FALSE;
@@ -136,6 +162,8 @@ static dns_name_t *dlv = NULL;
 static dns_fixedname_t dlv_fixed;
 static dns_master_style_t *dsstyle = NULL;
 static unsigned int serialformat = SOA_SERIAL_KEEP;
+static unsigned int hash_length = 0;
+static isc_boolean_t unknownalg = ISC_FALSE;
 
 #define INCSTAT(counter)		\
 	if (printstats) {		\
@@ -147,19 +175,8 @@ static unsigned int serialformat = SOA_SERIAL_KEEP;
 static void
 sign(isc_task_t *task, isc_event_t *event);
 
-
-static inline void
-set_bit(unsigned char *array, unsigned int index, unsigned int bit) {
-	unsigned int shift, mask;
-
-	shift = 7 - (index % 8);
-	mask = 1 << shift;
-
-	if (bit != 0)
-		array[index / 8] |= mask;
-	else
-		array[index / 8] &= (~mask & 0xFF);
-}
+static isc_boolean_t
+nsec3only(dns_dbnode_t *node);
 
 static void
 dumpnode(dns_name_t *name, dns_dbnode_t *node) {
@@ -549,6 +566,169 @@ signset(dns_diff_t *del, dns_diff_t *add, dns_dbnode_t *node, dns_name_t *name,
 	isc_mem_put(mctx, nowsignedby, arraysize * sizeof(isc_boolean_t));
 }
 
+struct hashlist {
+	unsigned char *hashbuf;
+	size_t entries;
+	size_t size;
+	size_t length;
+};
+
+static void
+hashlist_init(hashlist_t *l, unsigned int nodes, unsigned int length) {
+
+	l->entries = 0;
+	l->length = length + 1;
+
+	if (nodes != 0) {
+		l->size = nodes;
+		l->hashbuf = malloc(l->size * l->length);
+		if (l->hashbuf == NULL)
+			l->size = 0;
+	} else {
+		l->size = 0;
+		l->hashbuf = NULL;
+	}
+}
+
+static void
+hashlist_add(hashlist_t *l, const unsigned char *hash, size_t len)
+{
+
+	REQUIRE(len <= l->length);
+
+	if (l->entries == l->size) {
+		l->size = l->size * 2 + 100;
+		l->hashbuf = realloc(l->hashbuf, l->size * l->length);
+	}
+	memset(l->hashbuf + l->entries * l->length, 0, l->length);
+	memcpy(l->hashbuf + l->entries * l->length, hash, len);
+	l->entries++;
+}
+
+static void
+hashlist_add_dns_name(hashlist_t *l, /*const*/ dns_name_t *name,
+		      unsigned int hashalg, unsigned int iterations,
+		      const unsigned char *salt, size_t salt_length,
+		      isc_boolean_t speculative)
+{
+	char nametext[DNS_NAME_FORMATSIZE];
+	unsigned char hash[NSEC3_MAX_HASH_LENGTH + 1];
+	unsigned int len;
+	size_t i;
+
+	len = isc_iterated_hash(hash, hashalg, iterations, salt, salt_length,
+				name->ndata, name->length);
+	if (verbose) {
+		dns_name_format(name, nametext, sizeof nametext);
+		for (i = 0 ; i < len; i++)
+			fprintf(stderr, "%02x", hash[i]);
+		fprintf(stderr, " %s\n", nametext);
+	}
+	hash[len++] = speculative ? 1 : 0;
+	hashlist_add(l, hash, len);
+}
+
+static int
+hashlist_comp(const void *a, const void *b) {
+	return (memcmp(a, b, hash_length + 1));
+}
+
+static void
+hashlist_sort(hashlist_t *l) {
+	qsort(l->hashbuf, l->entries, l->length, hashlist_comp);
+}
+
+static isc_boolean_t
+hashlist_hasdup(hashlist_t *l) {
+	unsigned char *current;
+	unsigned char *next = l->hashbuf;
+	size_t entries = l->entries;
+
+	/*
+	 * Skip initial speculative wild card hashs.
+	 */
+	while (entries > 0U && next[l->length-1] != 0U) {
+		next += l->length;
+		entries--;
+	}
+
+	current = next;
+	while (entries-- > 1U) {
+		next += l->length;
+		if (next[l->length-1] != 0)
+			continue;
+		if (memcmp(current, next, l->length - 1) == 0)
+			return (ISC_TRUE);
+		current = next;
+	}
+	return (ISC_FALSE);
+}
+
+static const unsigned char *
+hashlist_findnext(const hashlist_t *l,
+		  const unsigned char hash[NSEC3_MAX_HASH_LENGTH])
+{
+	unsigned int entries = l->entries;
+	const unsigned char *next = bsearch(hash, l->hashbuf, l->entries,
+					    l->length, hashlist_comp);
+	INSIST(next != NULL);
+
+	do {
+		if (next < l->hashbuf + (l->entries - 1) * l->length)
+			next += l->length;
+		else
+			next = l->hashbuf;
+		if (next[l->length - 1] == 0)
+			break;
+	} while (entries-- > 1);
+	INSIST(entries != 0);
+	return (next);
+}
+
+static isc_boolean_t
+hashlist_exists(const hashlist_t *l,
+		const unsigned char hash[NSEC3_MAX_HASH_LENGTH])
+{
+	if (bsearch(hash, l->hashbuf, l->entries, l->length, hashlist_comp))
+		return (ISC_TRUE);
+	else
+		return (ISC_FALSE);
+}
+
+static void
+addnowildcardhash(hashlist_t *l, /*const*/ dns_name_t *name,
+		  unsigned int hashalg, unsigned int iterations,
+		  const unsigned char *salt, size_t salt_length)
+{
+	dns_fixedname_t fixed;
+	dns_name_t *wild;
+	dns_dbnode_t *node = NULL;
+	isc_result_t result;
+	char namestr[DNS_NAME_FORMATSIZE];
+
+	dns_fixedname_init(&fixed);
+	wild = dns_fixedname_name(&fixed);
+
+	result = dns_name_concatenate(dns_wildcardname, name, wild, NULL);
+	if (result == ISC_R_NOSPACE)
+		return;
+	check_result(result,"addnowildcardhash: dns_name_concatenate()");
+
+	result = dns_db_findnode(gdb, wild, ISC_FALSE, &node);
+	if (result == ISC_R_SUCCESS) {
+		dns_db_detachnode(gdb, &node);
+		return;
+	}
+
+	if (verbose) {
+		dns_name_format(wild, namestr, sizeof(namestr));
+		fprintf(stderr, "adding no-wildcardhash for %s\n", namestr);
+	}
+
+	hashlist_add_dns_name(l, wild, hashalg, iterations, salt, salt_length,
+			      ISC_TRUE);
+}
+
 static void
 opendb(const char *prefix, dns_name_t *name, dns_rdataclass_t rdclass,
        dns_db_t **dbp)
@@ -665,91 +845,6 @@ loadds(dns_name_t *name, isc_uint32_t ttl, dns_rdataset_t *dsset) {
 }
 
 static isc_boolean_t
-nsec_setbit(dns_name_t *name, dns_rdataset_t *rdataset, dns_rdatatype_t type,
-	   unsigned int val)
-{
-	isc_result_t result;
-	dns_rdata_t rdata = DNS_RDATA_INIT;
-	dns_rdata_nsec_t nsec;
-	unsigned int newlen;
-	unsigned char bitmap[8192 + 512];
-	unsigned char nsecdata[8192 + 512 + DNS_NAME_MAXWIRE];
-	isc_boolean_t answer = ISC_FALSE;
-	unsigned int i, len, window;
-	int octet;
-
-	result = dns_rdataset_first(rdataset);
-	check_result(result, "dns_rdataset_first()");
-	dns_rdataset_current(rdataset, &rdata);
-	result = dns_rdata_tostruct(&rdata, &nsec, NULL);
-	check_result(result, "dns_rdata_tostruct");
-
-	INSIST(nsec.len <= sizeof(bitmap));
-
-	newlen = 0;
-
-	memset(bitmap, 0, sizeof(bitmap));
-	for (i = 0; i < nsec.len; i += len) {
-		INSIST(i + 2 <= nsec.len);
-		window = nsec.typebits[i];
-		len = nsec.typebits[i+1];
-		i += 2;
-		INSIST(len > 0 && len <= 32);
-		INSIST(i + len <= nsec.len);
-		memmove(&bitmap[window * 32 + 512], &nsec.typebits[i], len);
-	}
-	set_bit(bitmap + 512, type, val);
-	for (window = 0; window < 256; window++) {
-		for (octet = 31; octet >= 0; octet--)
-			if (bitmap[window * 32 + 512 + octet] != 0)
-				break;
-		if (octet < 0)
-			continue;
-		bitmap[newlen] = window;
-		bitmap[newlen + 1] = octet + 1;
-		newlen += 2;
-		/*
-		 * Overlapping move.
-		 */
-		memmove(&bitmap[newlen], &bitmap[window * 32 + 512], octet + 1);
-		newlen += octet + 1;
-	}
-	if (newlen != nsec.len ||
-	    memcmp(nsec.typebits, bitmap, newlen) != 0) {
-		dns_rdata_t newrdata = DNS_RDATA_INIT;
-		isc_buffer_t b;
-		dns_diff_t diff;
-		dns_difftuple_t *tuple = NULL;
-
-		dns_diff_init(mctx, &diff);
-		result = dns_difftuple_create(mctx, DNS_DIFFOP_DEL, name,
-					      rdataset->ttl, &rdata, &tuple);
-		check_result(result, "dns_difftuple_create");
-		dns_diff_append(&diff, &tuple);
-
-		nsec.typebits = bitmap;
-		nsec.len = newlen;
-		isc_buffer_init(&b, nsecdata, sizeof(nsecdata));
-		result = dns_rdata_fromstruct(&newrdata, rdata.rdclass,
-					      dns_rdatatype_nsec, &nsec,
-					      &b);
-		check_result(result, "dns_rdata_fromstruct");
-
-		result = dns_difftuple_create(mctx, DNS_DIFFOP_ADD,
-					      name, rdataset->ttl,
-					      &newrdata, &tuple);
-		check_result(result, "dns_difftuple_create");
-		dns_diff_append(&diff, &tuple);
-		result = dns_diff_apply(&diff, gdb, gversion);
-		check_result(result, "dns_difftuple_apply");
-		dns_diff_clear(&diff);
-		answer = ISC_TRUE;
-	}
-	dns_rdata_freestruct(&nsec);
-	return (answer);
-}
-
-static isc_boolean_t
 delegation(dns_name_t *name, dns_dbnode_t *node, isc_uint32_t *ttlp) {
 	dns_rdataset_t nsset;
 	isc_result_t result;
@@ -769,10 +864,25 @@ delegation(dns_name_t *name, dns_dbnode_t *node, isc_uint32_t *ttlp) {
 	return (ISC_TF(result == ISC_R_SUCCESS));
 }
 
+static isc_boolean_t
+secure(dns_name_t *name, dns_dbnode_t *node) {
+	dns_rdataset_t dsset;
+	isc_result_t result;
+
+	if (dns_name_equal(name, gorigin))
+		return (ISC_FALSE);
+
+	dns_rdataset_init(&dsset);
+	result = dns_db_findrdataset(gdb, node, gversion, dns_rdatatype_ds,
+				     0, 0, &dsset, NULL);
+	if (dns_rdataset_isassociated(&dsset))
+		dns_rdataset_disassociate(&dsset);
+
+	return (ISC_TF(result == ISC_R_SUCCESS));
+}
+
 /*%
- * Signs all records at a name.  This mostly just signs each set individually,
- * but also adds the RRSIG bit to any NSECs generated earlier, deals with
- * parent/child KEY signatures, and handles other exceptional cases.
+ * Signs all records at a name.
  */
 static void
 signname(dns_dbnode_t *node, dns_name_t *name) {
@@ -780,89 +890,19 @@ signname(dns_dbnode_t *node, dns_name_t *name) {
 	dns_rdataset_t rdataset;
 	dns_rdatasetiter_t *rdsiter;
 	isc_boolean_t isdelegation = ISC_FALSE;
-	isc_boolean_t hasds = ISC_FALSE;
-	isc_boolean_t changed = ISC_FALSE;
 	dns_diff_t del, add;
 	char namestr[DNS_NAME_FORMATSIZE];
-	isc_uint32_t nsttl = 0;
 
+	dns_rdataset_init(&rdataset);
 	dns_name_format(name, namestr, sizeof(namestr));
 
 	/*
 	 * Determine if this is a delegation point.
 	 */
-	if (delegation(name, node, &nsttl))
+	if (delegation(name, node, NULL))
 		isdelegation = ISC_TRUE;
 
 	/*
-	 * If this is a delegation point, look for a DS set.
-	 */
-	if (isdelegation) {
-		dns_rdataset_t dsset;
-		dns_rdataset_t sigdsset;
-
-		dns_rdataset_init(&dsset);
-		dns_rdataset_init(&sigdsset);
-		result = dns_db_findrdataset(gdb, node, gversion,
-					     dns_rdatatype_ds,
-					     0, 0, &dsset, &sigdsset);
-		if (result == ISC_R_SUCCESS) {
-			dns_rdataset_disassociate(&dsset);
-			if (generateds) {
-				result = dns_db_deleterdataset(gdb, node,
-							       gversion,
-							       dns_rdatatype_ds,
-							       0);
-				check_result(result, "dns_db_deleterdataset");
-			} else
-				hasds = ISC_TRUE;
-		}
-		if (generateds) {
-			result = loadds(name, nsttl, &dsset);
-			if (result == ISC_R_SUCCESS) {
-				result = dns_db_addrdataset(gdb, node,
-							    gversion, 0,
-							    &dsset, 0, NULL);
-				check_result(result, "dns_db_addrdataset");
-				hasds = ISC_TRUE;
-				dns_rdataset_disassociate(&dsset);
-				if (dns_rdataset_isassociated(&sigdsset))
-					dns_rdataset_disassociate(&sigdsset);
-			} else if (dns_rdataset_isassociated(&sigdsset)) {
-				result = dns_db_deleterdataset(gdb, node,
-							    gversion,
-							    dns_rdatatype_rrsig,
-							    dns_rdatatype_ds);
-				check_result(result, "dns_db_deleterdataset");
-				dns_rdataset_disassociate(&sigdsset);
-			}
-		} else if (dns_rdataset_isassociated(&sigdsset))
-			dns_rdataset_disassociate(&sigdsset);
-	}
-
-	/*
-	 * Make sure that NSEC bits are appropriately set.
-	 */
-	dns_rdataset_init(&rdataset);
-	RUNTIME_CHECK(dns_db_findrdataset(gdb, node, gversion,
-					  dns_rdatatype_nsec, 0, 0, &rdataset,
-					  NULL) == ISC_R_SUCCESS);
-	if (!nokeys)
-		changed = nsec_setbit(name, &rdataset, dns_rdatatype_rrsig, 1);
-	if (changed) {
-		dns_rdataset_disassociate(&rdataset);
-		RUNTIME_CHECK(dns_db_findrdataset(gdb, node, gversion,
-						  dns_rdatatype_nsec, 0, 0,
-						  &rdataset,
-						  NULL) == ISC_R_SUCCESS);
-	}
-	if (hasds)
-		(void)nsec_setbit(name, &rdataset, dns_rdatatype_ds, 1);
-	else
-		(void)nsec_setbit(name, &rdataset, dns_rdatatype_ds, 0);
-	dns_rdataset_disassociate(&rdataset);
-
-	/*
 	 * Now iterate through the rdatasets.
 	 */
 	dns_diff_init(mctx, &del);
@@ -884,7 +924,7 @@ signname(dns_dbnode_t *node, dns_name_t *name) {
 		 * isn't a DS record.
 		 */
 		if (isdelegation) {
-			if (rdataset.type != dns_rdatatype_nsec &&
+			if (rdataset.type != nsec_datatype &&
 			    rdataset.type != dns_rdatatype_ds)
 				goto skip;
 		} else if (rdataset.type == dns_rdatatype_ds) {
@@ -938,6 +978,7 @@ active_node(dns_dbnode_t *node) {
 	while (result == ISC_R_SUCCESS) {
 		dns_rdatasetiter_current(rdsiter, &rdataset);
 		if (rdataset.type != dns_rdatatype_nsec &&
+		    rdataset.type != dns_rdatatype_nsec3 &&
 		    rdataset.type != dns_rdatatype_rrsig)
 			active = ISC_TRUE;
 		dns_rdataset_disassociate(&rdataset);
@@ -950,7 +991,7 @@ active_node(dns_dbnode_t *node) {
 		fatal("rdataset iteration failed: %s",
 		      isc_result_totext(result));
 
-	if (!active) {
+	if (!active && nsec_datatype == dns_rdatatype_nsec) {
 		/*%
 		 * The node is empty of everything but NSEC / RRSIG records.
 		 */
@@ -1009,6 +1050,32 @@ active_node(dns_dbnode_t *node) {
 			fatal("rdataset iteration failed: %s",
 			      isc_result_totext(result));
 		dns_rdatasetiter_destroy(&rdsiter2);
+
+#if 0
+		/*
+		 * Delete all NSEC records and RRSIG(NSEC) if we are in
+		 * NSEC3 mode and vica versa.
+		 */
+		for (result = dns_rdatasetiter_first(rdsiter2);
+		     result == ISC_R_SUCCESS;
+		     result = dns_rdatasetiter_next(rdsiter2)) {
+			dns_rdatasetiter_current(rdsiter, &rdataset);
+			type = rdataset.type;
+			covers = rdataset.covers;
+			if (type == dns_rdatatype_rrsig)
+				type = covers;
+			dns_rdataset_disassociate(&rdataset);
+			if (type == nsec_datatype ||
+			    (type != dns_rdatatype_nsec &&
+			     type != dns_rdatatype_nsec3))
+				continue;
+			if (covers != 0)
+				type = dns_rdatatype_rrsig;
+			result = dns_db_deleterdataset(gdb, node, gversion,
+						       type, covers);
+			check_result(result, "dns_db_deleterdataset()");
+		}
+#endif
 	}
 	dns_rdatasetiter_destroy(&rdsiter);
 
@@ -1169,11 +1236,8 @@ presign(void) {
 	isc_result_t result;
 
 	gdbiter = NULL;
-	result = dns_db_createiterator(gdb, ISC_FALSE, &gdbiter);
+	result = dns_db_createiterator(gdb, 0, &gdbiter);
 	check_result(result, "dns_db_createiterator()");
-
-	result = dns_dbiterator_first(gdbiter);
-	check_result(result, "dns_dbiterator_first()");
 }
 
 /*%
@@ -1186,6 +1250,8 @@ postsign(void) {
 
 /*%
  * Sign the apex of the zone.
+ * Note the origin may not be the first node if there are out of zone
+ * records.
  */
 static void
 signapex(void) {
@@ -1196,13 +1262,15 @@ signapex(void) {
 
 	dns_fixedname_init(&fixed);
 	name = dns_fixedname_name(&fixed);
+	result = dns_dbiterator_seek(gdbiter, gorigin);
+	check_result(result, "dns_dbiterator_seek()");
 	result = dns_dbiterator_current(gdbiter, &node, name);
 	check_result(result, "dns_dbiterator_current()");
 	signname(node, name);
 	dumpnode(name, node);
 	cleannode(gdb, gversion, node);
 	dns_db_detachnode(gdb, &node);
-	result = dns_dbiterator_next(gdbiter);
+	result = dns_dbiterator_first(gdbiter);
 	if (result == ISC_R_NOMORE)
 		finished = ISC_TRUE;
 	else if (result != ISC_R_SUCCESS)
@@ -1223,6 +1291,8 @@ assignwork(isc_task_t *task, isc_task_t *worker) {
 	dns_rdataset_t nsec;
 	isc_boolean_t found;
 	isc_result_t result;
+	static dns_name_t *zonecut = NULL;	/* Protected by namelock. */
+	static dns_fixedname_t fzonecut;	/* Protected by namelock. */
 	static unsigned int ended = 0;		/* Protected by namelock. */
 
 	if (shuttingdown)
@@ -1250,19 +1320,51 @@ assignwork(isc_task_t *task, isc_task_t *worker) {
 		if (result != ISC_R_SUCCESS)
 			fatal("failure iterating database: %s",
 			      isc_result_totext(result));
+		/*
+		 * The origin was handled by signapex().
+		 */
+		if (dns_name_equal(name, gorigin)) {
+			dns_db_detachnode(gdb, &node);
+			goto next;
+		}
+		/*
+		 * Sort the zone data from the glue and out-of-zone data.
+		 * For NSEC zones nodes with zone data have NSEC records.
+		 * For NSEC3 zones the NSEC3 nodes are zone data but
+		 * outside of the zone name space.  For the rest we need
+		 * to track the bottom of zone cuts.
+		 * Nodes which don't need to be signed are dumped here.
+		 */
 		dns_rdataset_init(&nsec);
 		result = dns_db_findrdataset(gdb, node, gversion,
-					     dns_rdatatype_nsec, 0, 0,
+					     nsec_datatype, 0, 0,
 					     &nsec, NULL);
-		if (result == ISC_R_SUCCESS)
-			found = ISC_TRUE;
-		else
-			dumpnode(name, node);
 		if (dns_rdataset_isassociated(&nsec))
 			dns_rdataset_disassociate(&nsec);
-		if (!found)
+		if (result == ISC_R_SUCCESS) {
+			found = ISC_TRUE;
+		} else if (nsec_datatype == dns_rdatatype_nsec3) {
+			if (dns_name_issubdomain(name, gorigin) &&
+			    (zonecut == NULL ||
+			     !dns_name_issubdomain(name, zonecut))) {
+				if (delegation(name, node, NULL)) {
+					dns_fixedname_init(&fzonecut);
+					zonecut = dns_fixedname_name(&fzonecut);
+					dns_name_copy(name, zonecut, NULL);
+					if (!OPTOUT(nsec3flags) ||
+					    secure(name, node))
+						found = ISC_TRUE;
+				} else
+					found = ISC_TRUE;
+			}
+		}
+
+		if (!found) {
+			dumpnode(name, node);
 			dns_db_detachnode(gdb, &node);
+		}
 
+ next:
 		result = dns_dbiterator_next(gdbiter);
 		if (result == ISC_R_NOMORE) {
 			finished = ISC_TRUE;
@@ -1348,6 +1450,43 @@ sign(isc_task_t *task, isc_event_t *event) {
 }
 
 /*%
+ * Update / remove the DS RRset.  Preserve RRSIG(DS) if possible.
+ */
+static void
+add_ds(dns_name_t *name, dns_dbnode_t *node, isc_uint32_t nsttl) {
+	dns_rdataset_t dsset;
+	dns_rdataset_t sigdsset;
+	isc_result_t result;
+
+	dns_rdataset_init(&dsset);
+	dns_rdataset_init(&sigdsset);
+	result = dns_db_findrdataset(gdb, node, gversion,
+				     dns_rdatatype_ds,
+				     0, 0, &dsset, &sigdsset);
+	if (result == ISC_R_SUCCESS) {
+		dns_rdataset_disassociate(&dsset);
+		result = dns_db_deleterdataset(gdb, node, gversion,
+					       dns_rdatatype_ds, 0);
+		check_result(result, "dns_db_deleterdataset");
+	}
+	result = loadds(name, nsttl, &dsset);
+	if (result == ISC_R_SUCCESS) {
+		result = dns_db_addrdataset(gdb, node, gversion, 0,
+					    &dsset, 0, NULL);
+		check_result(result, "dns_db_addrdataset");
+		dns_rdataset_disassociate(&dsset);
+		if (dns_rdataset_isassociated(&sigdsset))
+			dns_rdataset_disassociate(&sigdsset);
+	} else if (dns_rdataset_isassociated(&sigdsset)) {
+		result = dns_db_deleterdataset(gdb, node, gversion,
+					       dns_rdatatype_rrsig,
+					       dns_rdatatype_ds);
+		check_result(result, "dns_db_deleterdataset");
+		dns_rdataset_disassociate(&sigdsset);
+	}
+}
+
+/*%
  * Generate NSEC records for the zone.
  */
 static void
@@ -1358,6 +1497,7 @@ nsecify(void) {
 	dns_name_t *name, *nextname, *zonecut;
 	isc_boolean_t done = ISC_FALSE;
 	isc_result_t result;
+	isc_uint32_t nsttl = 0;
 
 	dns_fixedname_init(&fname);
 	name = dns_fixedname_name(&fname);
@@ -1366,7 +1506,7 @@ nsecify(void) {
 	dns_fixedname_init(&fzonecut);
 	zonecut = NULL;
 
-	result = dns_db_createiterator(gdb, ISC_FALSE, &dbiter);
+	result = dns_db_createiterator(gdb, DNS_DB_NONSEC3, &dbiter);
 	check_result(result, "dns_db_createiterator()");
 
 	result = dns_dbiterator_first(dbiter);
@@ -1374,9 +1514,11 @@ nsecify(void) {
 
 	while (!done) {
 		dns_dbiterator_current(dbiter, &node, name);
-		if (delegation(name, node, NULL)) {
+		if (delegation(name, node, &nsttl)) {
 			zonecut = dns_fixedname_name(&fzonecut);
 			dns_name_copy(name, zonecut, NULL);
+			if (generateds)
+				add_ds(name, node, nsttl);
 		}
 		result = dns_dbiterator_next(dbiter);
 		nextnode = NULL;
@@ -1419,6 +1561,451 @@ nsecify(void) {
 }
 
 /*%
+ * Does this node only contain NSEC3 records or RRSIG records or is empty.
+ */
+static isc_boolean_t
+nsec3only(dns_dbnode_t *node) {
+	dns_rdatasetiter_t *rdsiter = NULL;
+	isc_result_t result;
+	dns_rdataset_t rdataset;
+	isc_boolean_t answer = ISC_TRUE;
+
+	dns_rdataset_init(&rdataset);
+	result = dns_db_allrdatasets(gdb, node, gversion, 0, &rdsiter);
+	check_result(result, "dns_db_allrdatasets()");
+	result = dns_rdatasetiter_first(rdsiter);
+	while (result == ISC_R_SUCCESS) {
+		dns_rdatasetiter_current(rdsiter, &rdataset);
+		if (rdataset.type != dns_rdatatype_nsec3 &&
+		    rdataset.type != dns_rdatatype_rrsig) {
+			answer = ISC_FALSE;
+			result = ISC_R_NOMORE;
+		} else
+			result = dns_rdatasetiter_next(rdsiter);
+		dns_rdataset_disassociate(&rdataset);
+	}
+	if (result != ISC_R_NOMORE)
+		fatal("rdataset iteration failed: %s",
+		      isc_result_totext(result));
+	dns_rdatasetiter_destroy(&rdsiter);
+	return (answer);
+}
+
+static void
+addnsec3param(const unsigned char *salt, size_t salt_length,
+	      unsigned int iterations)
+{
+	dns_dbnode_t *node = NULL;
+	dns_rdata_nsec3param_t nsec3param;
+	unsigned char nsec3parambuf[5 + 255];
+	dns_rdatalist_t rdatalist;
+	dns_rdataset_t rdataset;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	isc_buffer_t b;
+	isc_result_t result;
+
+	dns_rdataset_init(&rdataset);
+
+	nsec3param.common.rdclass = gclass;
+	nsec3param.common.rdtype = dns_rdatatype_nsec3param;
+	ISC_LINK_INIT(&nsec3param.common, link);
+	nsec3param.mctx = NULL;
+	nsec3param.flags = 0;
+	nsec3param.hash = unknownalg ? DNS_NSEC3_UNKNOWNALG : dns_hash_sha1;
+	nsec3param.iterations = iterations;
+	nsec3param.salt_length = salt_length;
+	DE_CONST(salt, nsec3param.salt);
+
+	isc_buffer_init(&b, nsec3parambuf, sizeof(nsec3parambuf));
+	result = dns_rdata_fromstruct(&rdata, gclass,
+				      dns_rdatatype_nsec3param,
+				      &nsec3param, &b);
+	rdatalist.rdclass = rdata.rdclass;
+	rdatalist.type = rdata.type;
+	rdatalist.covers = 0;
+	rdatalist.ttl = 0;
+	ISC_LIST_INIT(rdatalist.rdata);
+	ISC_LIST_APPEND(rdatalist.rdata, &rdata, link);
+	result = dns_rdatalist_tordataset(&rdatalist, &rdataset);
+	check_result(result, "dns_rdatalist_tordataset()");
+
+	result = dns_db_findnode(gdb, gorigin, ISC_TRUE, &node);
+	check_result(result, "dns_db_find(gorigin)");
+	result = dns_db_addrdataset(gdb, node, gversion, 0, &rdataset,
+				    DNS_DBADD_MERGE, NULL);
+	if (result == DNS_R_UNCHANGED)
+		result = ISC_R_SUCCESS;
+	check_result(result, "addnsec3param: dns_db_addrdataset()");
+	dns_db_detachnode(gdb, &node);
+}
+
+static void
+addnsec3(dns_name_t *name, dns_dbnode_t *node,
+	 const unsigned char *salt, size_t salt_length,
+	 unsigned int iterations, hashlist_t *hashlist,
+	 dns_ttl_t ttl)
+{
+	unsigned char hash[NSEC3_MAX_HASH_LENGTH];
+	const unsigned char *nexthash;
+	unsigned char nsec3buffer[DNS_NSEC3_BUFFERSIZE];
+	dns_fixedname_t hashname;
+	dns_rdatalist_t rdatalist;
+	dns_rdataset_t rdataset;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	isc_result_t result;
+	dns_dbnode_t *nsec3node = NULL;
+	char namebuf[DNS_NAME_FORMATSIZE];
+	size_t hash_length;
+
+	dns_name_format(name, namebuf, sizeof(namebuf));
+
+	dns_fixedname_init(&hashname);
+	dns_rdataset_init(&rdataset);
+
+	dns_name_downcase(name, name, NULL);
+	result = dns_nsec3_hashname(&hashname, hash, &hash_length,
+				    name, gorigin, dns_hash_sha1, iterations,
+				    salt, salt_length);
+	check_result(result, "addnsec3: dns_nsec3_hashname()");
+	nexthash = hashlist_findnext(hashlist, hash);
+	result = dns_nsec3_buildrdata(gdb, gversion, node,
+				      unknownalg ?
+					  DNS_NSEC3_UNKNOWNALG : dns_hash_sha1,
+				      nsec3flags, iterations,
+				      salt, salt_length,
+				      nexthash, ISC_SHA1_DIGESTLENGTH,
+				      nsec3buffer, &rdata);
+	check_result(result, "addnsec3: dns_nsec3_buildrdata()");
+	rdatalist.rdclass = rdata.rdclass;
+	rdatalist.type = rdata.type;
+	rdatalist.covers = 0;
+	rdatalist.ttl = ttl;
+	ISC_LIST_INIT(rdatalist.rdata);
+	ISC_LIST_APPEND(rdatalist.rdata, &rdata, link);
+	result = dns_rdatalist_tordataset(&rdatalist, &rdataset);
+	check_result(result, "dns_rdatalist_tordataset()");
+	result = dns_db_findnsec3node(gdb, dns_fixedname_name(&hashname),
+				      ISC_TRUE, &nsec3node);
+	check_result(result, "addnsec3: dns_db_findnode()");
+	result = dns_db_addrdataset(gdb, nsec3node, gversion, 0, &rdataset,
+				    0, NULL);
+	if (result == DNS_R_UNCHANGED)
+		result = ISC_R_SUCCESS;
+	check_result(result, "addnsec3: dns_db_addrdataset()");
+	dns_db_detachnode(gdb, &nsec3node);
+}
+
+/*%
+ * Clean out NSEC3 record and RRSIG(NSEC3) that are not in the hash list.
+ *
+ * Extract the hash from the first label of 'name' then see if it
+ * is in hashlist.  If 'name' is not in the hashlist then delete the
+ * any NSEC3 records which have the same parameters as the chain we
+ * are building.
+ *
+ * XXXMPA Should we also check that it of the form <hash>.<origin>?
+ */
+static void
+nsec3clean(dns_name_t *name, dns_dbnode_t *node,
+	   unsigned int hashalg, unsigned int iterations,
+	   const unsigned char *salt, size_t salt_length, hashlist_t *hashlist)
+{
+	dns_label_t label;
+	dns_rdata_nsec3_t nsec3;
+	dns_rdata_t rdata, delrdata;
+	dns_rdatalist_t rdatalist;
+	dns_rdataset_t rdataset, delrdataset;
+	isc_boolean_t delete_rrsigs = ISC_FALSE;
+	isc_buffer_t target;
+	isc_result_t result;
+	unsigned char hash[NSEC3_MAX_HASH_LENGTH + 1];
+
+	/*
+	 * Get the first label.
+	 */
+	dns_name_getlabel(name, 0, &label);
+
+	/*
+	 * We want just the label contents.
+	 */
+	isc_region_consume(&label, 1);
+
+	/*
+	 * Decode base32hex string.
+	 */
+	isc_buffer_init(&target, hash, sizeof(hash) - 1);
+	result = isc_base32hex_decoderegion(&label, &target);
+	if (result != ISC_R_SUCCESS)
+		return;
+
+	hash[isc_buffer_usedlength(&target)] = 0;
+
+	if (hashlist_exists(hashlist, hash))
+		return;
+
+	/*
+	 * Verify that the NSEC3 parameters match the current ones
+	 * otherwise we are dealing with a different NSEC3 chain.
+	 */
+	dns_rdataset_init(&rdataset);
+	dns_rdataset_init(&delrdataset);
+
+	result = dns_db_findrdataset(gdb, node, gversion, dns_rdatatype_nsec3,
+				     0, 0, &rdataset, NULL);
+	if (result != ISC_R_SUCCESS)
+		return;
+
+	/*
+	 * Delete any matching NSEC3 records which have parameters that
+	 * match the NSEC3 chain we are building.
+	 */
+	for (result = dns_rdataset_first(&rdataset);
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdataset_next(&rdataset)) {
+		dns_rdata_init(&rdata);
+		dns_rdataset_current(&rdataset, &rdata);
+		dns_rdata_tostruct(&rdata, &nsec3, NULL);
+		if (nsec3.hash == hashalg &&
+		    nsec3.iterations == iterations &&
+		    nsec3.salt_length == salt_length &&
+		    !memcmp(nsec3.salt, salt, salt_length))
+			break;
+		rdatalist.rdclass = rdata.rdclass;
+		rdatalist.type = rdata.type;
+		rdatalist.covers = 0;
+		rdatalist.ttl = rdataset.ttl;
+		ISC_LIST_INIT(rdatalist.rdata);
+		dns_rdata_init(&delrdata);
+		dns_rdata_clone(&rdata, &delrdata);
+		ISC_LIST_APPEND(rdatalist.rdata, &delrdata, link);
+		result = dns_rdatalist_tordataset(&rdatalist, &delrdataset);
+		check_result(result, "dns_rdatalist_tordataset()");
+		result = dns_db_subtractrdataset(gdb, node, gversion,
+						 &delrdataset, 0, NULL);
+		dns_rdataset_disassociate(&delrdataset);
+		if (result != ISC_R_SUCCESS && result != DNS_R_UNCHANGED)
+			check_result(result, "dns_db_subtractrdataset(NSEC3)");
+		delete_rrsigs = ISC_TRUE;
+	}
+	dns_rdataset_disassociate(&rdataset);
+	if (result != ISC_R_NOMORE)
+		check_result(result, "dns_rdataset_first/next");
+
+	if (!delete_rrsigs)
+		return;
+	/*
+	 * Delete the NSEC3 RRSIGs
+	 */
+	result = dns_db_deleterdataset(gdb, node, gversion,
+				       dns_rdatatype_rrsig,
+				       dns_rdatatype_nsec3);
+	if (result != ISC_R_SUCCESS && result != DNS_R_UNCHANGED)
+		check_result(result, "dns_db_deleterdataset(RRSIG(NSEC3))");
+}
+
+/*
+ * Generate NSEC3 records for the zone.
+ */
+static void
+nsec3ify(unsigned int hashalg, unsigned int iterations,
+	 const unsigned char *salt, size_t salt_length, hashlist_t *hashlist)
+{
+	dns_dbiterator_t *dbiter = NULL;
+	dns_dbnode_t *node = NULL, *nextnode = NULL;
+	dns_fixedname_t fname, fnextname, fzonecut;
+	dns_name_t *name, *nextname, *zonecut;
+	isc_boolean_t done = ISC_FALSE;
+	isc_result_t result;
+	isc_boolean_t active;
+	isc_uint32_t nsttl = 0;
+	unsigned int count, nlabels;
+	int order;
+
+	dns_fixedname_init(&fname);
+	name = dns_fixedname_name(&fname);
+	dns_fixedname_init(&fnextname);
+	nextname = dns_fixedname_name(&fnextname);
+	dns_fixedname_init(&fzonecut);
+	zonecut = NULL;
+
+	/*
+	 * Walk the zone generating the hash names.
+	 */
+	result = dns_db_createiterator(gdb, DNS_DB_NONSEC3, &dbiter);
+	check_result(result, "dns_db_createiterator()");
+
+	result = dns_dbiterator_first(dbiter);
+	check_result(result, "dns_dbiterator_first()");
+
+	while (!done) {
+		dns_dbiterator_current(dbiter, &node, name);
+		result = dns_dbiterator_next(dbiter);
+		nextnode = NULL;
+		while (result == ISC_R_SUCCESS) {
+			result = dns_dbiterator_current(dbiter, &nextnode,
+							nextname);
+			if (result != ISC_R_SUCCESS)
+				break;
+			active = active_node(nextnode);
+			if (!active) {
+				dns_db_detachnode(gdb, &nextnode);
+				result = dns_dbiterator_next(dbiter);
+				continue;
+			}
+			if (!dns_name_issubdomain(nextname, gorigin) ||
+			    (zonecut != NULL &&
+			     dns_name_issubdomain(nextname, zonecut))) {
+				dns_db_detachnode(gdb, &nextnode);
+				result = dns_dbiterator_next(dbiter);
+				continue;
+			}
+			if (delegation(nextname, nextnode, &nsttl)) {
+				zonecut = dns_fixedname_name(&fzonecut);
+				dns_name_copy(nextname, zonecut, NULL);
+				if (generateds)
+					add_ds(nextname, nextnode, nsttl);
+				if (OPTOUT(nsec3flags) &&
+				    !secure(nextname, nextnode)) {
+					dns_db_detachnode(gdb, &nextnode);
+					result = dns_dbiterator_next(dbiter);
+					continue;
+				}
+			}
+			dns_db_detachnode(gdb, &nextnode);
+			break;
+		}
+		if (result == ISC_R_NOMORE) {
+			dns_name_copy(gorigin, nextname, NULL);
+			done = ISC_TRUE;
+		} else if (result != ISC_R_SUCCESS)
+			fatal("iterating through the database failed: %s",
+			      isc_result_totext(result));
+		dns_name_downcase(name, name, NULL);
+		hashlist_add_dns_name(hashlist, name, hashalg, iterations,
+				      salt, salt_length, ISC_FALSE);
+		dns_db_detachnode(gdb, &node);
+		/*
+		 * Add hashs for empty nodes.  Use closest encloser logic.
+		 * The closest encloser either has data or is a empty
+		 * node for another <name,nextname> span so we don't add
+		 * it here.  Empty labels on nextname are within the span.
+		 */
+		dns_name_downcase(nextname, nextname, NULL);
+		dns_name_fullcompare(name, nextname, &order, &nlabels);
+		addnowildcardhash(hashlist, name, hashalg, iterations,
+				  salt, salt_length);
+		count = dns_name_countlabels(nextname);
+		while (count > nlabels + 1) {
+			count--;
+			dns_name_split(nextname, count, NULL, nextname);
+			hashlist_add_dns_name(hashlist, nextname, hashalg,
+					      iterations, salt, salt_length,
+					      ISC_FALSE);
+			addnowildcardhash(hashlist, nextname, hashalg,
+					  iterations, salt, salt_length);
+		}
+	}
+	dns_dbiterator_destroy(&dbiter);
+
+	/*
+	 * We have all the hashes now so we can sort them.
+	 */
+	hashlist_sort(hashlist);
+
+	/*
+	 * Check for duplicate hashes.  If found the salt needs to
+	 * be changed.
+	 */
+	if (hashlist_hasdup(hashlist))
+		fatal("Duplicate hash detected. Pick a different salt.");
+
+	/*
+	 * Generate the nsec3 records.
+	 */
+	zonecut = NULL;
+	done = ISC_FALSE;
+
+	addnsec3param(salt, salt_length, iterations);
+
+	result = dns_db_createiterator(gdb, DNS_DB_NONSEC3, &dbiter);
+	check_result(result, "dns_db_createiterator()");
+
+	result = dns_dbiterator_first(dbiter);
+	check_result(result, "dns_dbiterator_first()");
+
+	while (!done) {
+		dns_dbiterator_current(dbiter, &node, name);
+		result = dns_dbiterator_next(dbiter);
+		nextnode = NULL;
+		while (result == ISC_R_SUCCESS) {
+			result = dns_dbiterator_current(dbiter, &nextnode,
+							nextname);
+			if (result != ISC_R_SUCCESS)
+				break;
+			/*
+			 * Cleanout NSEC3 RRsets which don't exist in the
+			 * hash table.
+			 */
+			nsec3clean(nextname, nextnode, hashalg, iterations,
+				   salt, salt_length, hashlist);
+			/*
+			 * Skip NSEC3 only nodes when looking for the next
+			 * node in the zone.  Also skips now empty nodes.
+			 */
+			if (nsec3only(nextnode)) {
+				dns_db_detachnode(gdb, &nextnode);
+				result = dns_dbiterator_next(dbiter);
+				continue;
+			}
+			if (!dns_name_issubdomain(nextname, gorigin) ||
+			    (zonecut != NULL &&
+			     dns_name_issubdomain(nextname, zonecut))) {
+				dns_db_detachnode(gdb, &nextnode);
+				result = dns_dbiterator_next(dbiter);
+				continue;
+			}
+			if (delegation(nextname, nextnode, NULL)) {
+				zonecut = dns_fixedname_name(&fzonecut);
+				dns_name_copy(nextname, zonecut, NULL);
+				if (OPTOUT(nsec3flags) &&
+				    !secure(nextname, nextnode)) {
+					dns_db_detachnode(gdb, &nextnode);
+					result = dns_dbiterator_next(dbiter);
+					continue;
+				}
+			}
+			dns_db_detachnode(gdb, &nextnode);
+			break;
+		}
+		if (result == ISC_R_NOMORE) {
+			dns_name_copy(gorigin, nextname, NULL);
+			done = ISC_TRUE;
+		} else if (result != ISC_R_SUCCESS)
+			fatal("iterating through the database failed: %s",
+			      isc_result_totext(result));
+		/*
+		 * We need to pause here to release the lock on the database.
+		 */
+		dns_dbiterator_pause(dbiter);
+		addnsec3(name, node, salt, salt_length, iterations,
+			 hashlist, zonettl);
+		dns_db_detachnode(gdb, &node);
+		/*
+		 * Add NSEC3's for empty nodes.  Use closest encloser logic.
+		 */
+		dns_name_fullcompare(name, nextname, &order, &nlabels);
+		count = dns_name_countlabels(nextname);
+		while (count > nlabels + 1) {
+			count--;
+			dns_name_split(nextname, count, NULL, nextname);
+			addnsec3(nextname, NULL, salt, salt_length,
+				 iterations, hashlist, zonettl);
+		}
+	}
+	dns_dbiterator_destroy(&dbiter);
+}
+
+/*%
  * Load the zone file from disk
  */
 static void
@@ -1788,6 +2375,9 @@ usage(void) {
 	fprintf(stderr, "\t-n ncpus (number of cpus present)\n");
 	fprintf(stderr, "\t-k key_signing_key\n");
 	fprintf(stderr, "\t-l lookasidezone\n");
+	fprintf(stderr, "\t-3 salt (NSEC3 salt)\n");
+	fprintf(stderr, "\t-H iterations (NSEC3 iterations)\n");
+	fprintf(stderr, "\t-A (NSEC3 optout)\n");
 	fprintf(stderr, "\t-z:\t");
 	fprintf(stderr, "ignore KSK flag in DNSKEYs");
 
@@ -1852,6 +2442,36 @@ main(int argc, char *argv[]) {
 	isc_task_t **tasks = NULL;
 	isc_buffer_t b;
 	int len;
+	unsigned int iterations = 100U;
+	const unsigned char *salt = NULL;
+	size_t salt_length = 0;
+	unsigned char saltbuf[255];
+	hashlist_t hashlist;
+
+#define CMDLINE_FLAGS "3:aAc:d:e:f:ghH:i:I:j:k:l:m:n:N:o:O:pr:s:StUv:z"
+
+	/*
+	 * Process memory debugging argument first.
+	 */
+	while ((ch = isc_commandline_parse(argc, argv, CMDLINE_FLAGS)) != -1) {
+		switch (ch) {
+		case 'm':
+			if (strcasecmp(isc_commandline_argument, "record") == 0)
+				isc_mem_debugging |= ISC_MEM_DEBUGRECORD;
+			if (strcasecmp(isc_commandline_argument, "trace") == 0)
+				isc_mem_debugging |= ISC_MEM_DEBUGTRACE;
+			if (strcasecmp(isc_commandline_argument, "usage") == 0)
+				isc_mem_debugging |= ISC_MEM_DEBUGUSAGE;
+			if (strcasecmp(isc_commandline_argument, "size") == 0)
+				isc_mem_debugging |= ISC_MEM_DEBUGSIZE;
+			if (strcasecmp(isc_commandline_argument, "mctx") == 0)
+				isc_mem_debugging |= ISC_MEM_DEBUGCTX;
+			break;
+		default:
+			break;
+		}
+	}
+	isc_commandline_reset = ISC_TRUE;
 
 	masterstyle = &dns_master_style_explicitttl;
 
@@ -1863,10 +2483,34 @@ main(int argc, char *argv[]) {
 
 	dns_result_register();
 
-	while ((ch = isc_commandline_parse(argc, argv,
-					   "ac:d:e:f:ghi:I:j:k:l:n:N:o:O:pr:s:Stv:z"))
-	       != -1) {
+	isc_commandline_errprint = ISC_FALSE;
+
+	while ((ch = isc_commandline_parse(argc, argv, CMDLINE_FLAGS)) != -1) {
 		switch (ch) {
+		case '3':
+			if (strcmp(isc_commandline_argument, "-")) {
+				isc_buffer_t target;
+				char *sarg;
+
+				sarg = isc_commandline_argument;
+				isc_buffer_init(&target, saltbuf,
+						sizeof(saltbuf));
+				result = isc_hex_decodestring(sarg, &target);
+				check_result(result,
+					     "isc_hex_decodestring(salt)");
+				salt = saltbuf;
+				salt_length = isc_buffer_usedlength(&target);
+			} else {
+				salt = saltbuf;
+				salt_length = 0;
+			}
+			nsec_datatype = dns_rdatatype_nsec3;
+			break;
+
+		case 'A':
+			nsec3flags |= DNS_NSEC3FLAG_OPTOUT;
+			break;
+
 		case 'a':
 			tryverify = ISC_TRUE;
 			break;
@@ -1891,11 +2535,19 @@ main(int argc, char *argv[]) {
 			generateds = ISC_TRUE;
 			break;
 
+		case '?':
+			if (isc_commandline_option != '?')
+				fprintf(stderr, "%s: invalid argument -%c\n",
+					program, isc_commandline_option);
 		case 'h':
-		default:
 			usage();
 			break;
 
+		default:
+			fprintf(stderr, "%s: unhandled option -%c\n",
+				program, isc_commandline_option);
+			exit(1);
+
 		case 'i':
 			endp = NULL;
 			cycle = strtol(isc_commandline_argument, &endp, 0);
@@ -1934,6 +2586,9 @@ main(int argc, char *argv[]) {
 			dskeyfile[ndskeys++] = isc_commandline_argument;
 			break;
 
+		case 'm':
+			break;
+
 		case 'n':
 			endp = NULL;
 			ntasks = strtol(isc_commandline_argument, &endp, 0);
@@ -1945,6 +2600,15 @@ main(int argc, char *argv[]) {
 			serialformatstr = isc_commandline_argument;
 			break;
 
+		case 'H':
+			iterations = strtoul(isc_commandline_argument,
+					     &endp, 0);
+			if (*endp != '\0')
+				fatal("iterations must be numeric");
+			if (iterations > 0xffffU)
+				fatal("iterations too big");
+			break;
+
 		case 'o':
 			origin = isc_commandline_argument;
 			break;
@@ -1975,6 +2639,10 @@ main(int argc, char *argv[]) {
 			printstats = ISC_TRUE;
 			break;
 
+		case 'U':	/* Undocumented for testing only. */
+			unknownalg = ISC_TRUE;
+			break;
+
 		case 'v':
 			endp = NULL;
 			verbose = strtol(isc_commandline_argument, &endp, 0);
@@ -2018,7 +2686,7 @@ main(int argc, char *argv[]) {
 		cycle = (endtime - starttime) / 4;
 
 	if (ntasks == 0)
-		ntasks = isc_os_ncpus();
+		ntasks = isc_os_ncpus() * 2;
 	vbprintf(4, "using %d cpus\n", ntasks);
 
 	rdclass = strtoclass(classname);
@@ -2082,7 +2750,6 @@ main(int argc, char *argv[]) {
 					0, 24, 0, 0, 0, 8, mctx);
 	check_result(result, "dns_master_stylecreate");
 
-
 	gdb = NULL;
 	TIME_NOW(&timer_start);
 	loadzone(file, origin, rdclass, &gdb);
@@ -2090,6 +2757,18 @@ main(int argc, char *argv[]) {
 	gclass = dns_db_class(gdb);
 	zonettl = soattl();
 
+	if (IS_NSEC3) {
+		isc_boolean_t answer;
+		hash_length = dns_nsec3_hashlength(dns_hash_sha1);
+		hashlist_init(&hashlist, dns_db_nodecount(gdb) * 2,
+			      hash_length);
+		result = dns_nsec_nseconly(gdb, gversion, &answer);
+		check_result(result, "dns_nsec_nseconly");
+		if (answer)
+			fatal("NSEC3 generation requested with "
+			      "NSEC only DNSKEY");
+	}
+
 	ISC_LIST_INIT(keylist);
 
 	if (argc == 0) {
@@ -2106,6 +2785,9 @@ main(int argc, char *argv[]) {
 				fatal("cannot load dnskey %s: %s", argv[i],
 				      isc_result_totext(result));
 
+			if (!dns_name_equal(gorigin, dst_key_name(newkey)))
+				fatal("key %s not at origin\n", argv[i]);
+
 			key = ISC_LIST_HEAD(keylist);
 			while (key != NULL) {
 				dst_key_t *dkey = key->key;
@@ -2143,6 +2825,9 @@ main(int argc, char *argv[]) {
 			fatal("cannot load dnskey %s: %s", dskeyfile[i],
 			      isc_result_totext(result));
 
+		if (!dns_name_equal(gorigin, dst_key_name(newkey)))
+			fatal("key %s not at origin\n", dskeyfile[i]);
+
 		key = ISC_LIST_HEAD(keylist);
 		while (key != NULL) {
 			dst_key_t *dkey = key->key;
@@ -2176,6 +2861,15 @@ main(int argc, char *argv[]) {
 		nokeys = ISC_TRUE;
 	}
 
+	if (IS_NSEC3) {
+		unsigned int max;
+		result = dns_nsec3_maxiterations(gdb, NULL, mctx, &max);
+		check_result(result, "dns_nsec3_maxiterations()");
+		if (iterations > max)
+			fatal("NSEC3 iterations too big for weakest DNSKEY "
+			      "strength. Maximum iterations allowed %u.", max);
+	}
+
 	warnifallksk(gdb);
 
 	gversion = NULL;
@@ -2195,7 +2889,11 @@ main(int argc, char *argv[]) {
 			break;
 	}
 
-	nsecify();
+	if (IS_NSEC3)
+		nsec3ify(dns_hash_sha1, iterations, salt, salt_length,
+			 &hashlist);
+	else
+		nsecify();
 
 	if (!nokeys) {
 		writeset("keyset-", dns_rdatatype_dnskey);
diff --git a/contrib/bind9/bin/dnssec/dnssec-signzone.docbook b/contrib/bind9/bin/dnssec/dnssec-signzone.docbook
index 67eacc1..2f26ba4 100644
--- a/contrib/bind9/bin/dnssec/dnssec-signzone.docbook
+++ b/contrib/bind9/bin/dnssec/dnssec-signzone.docbook
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: dnssec-signzone.docbook,v 1.10.18.19 2008/10/15 23:46:06 tbox Exp $ -->
+<!-- $Id: dnssec-signzone.docbook,v 1.31 2008/10/14 14:28:25 jreed Exp $ -->
 <refentry id="man.dnssec-signzone">
   <refentryinfo>
     <date>June 30, 2000</date>
@@ -77,6 +77,9 @@
       <arg><option>-t</option></arg>
       <arg><option>-v <replaceable class="parameter">level</replaceable></option></arg>
       <arg><option>-z</option></arg>
+      <arg><option>-3 <replaceable class="parameter">salt</replaceable></option></arg>
+      <arg><option>-H <replaceable class="parameter">iterations</replaceable></option></arg>
+      <arg><option>-A</option></arg>
       <arg choice="req">zonefile</arg>
       <arg rep="repeat">key</arg>
     </cmdsynopsis>
@@ -400,6 +403,38 @@
       </varlistentry>
 
       <varlistentry>
+        <term>-3 <replaceable class="parameter">salt</replaceable></term>
+        <listitem>
+          <para>
+            Generate a NSEC3 chain with the given hex encoded salt.
+	    A dash (<replaceable class="parameter">salt</replaceable>) can
+	    be used to indicate that no salt is to be used when generating		    the NSEC3 chain.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>-H <replaceable class="parameter">iterations</replaceable></term>
+        <listitem>
+          <para>
+	    When generating a NSEC3 chain use this many interations.  The
+	    default is 100.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
+        <term>-A</term>
+        <listitem>
+          <para>
+	    When generating a NSEC3 chain set the OPTOUT flag on all
+	    NSEC3 records and do not generate NSEC3 records for insecure
+	    delegations.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
         <term>zonefile</term>
         <listitem>
           <para>
diff --git a/contrib/bind9/bin/dnssec/dnssec-signzone.html b/contrib/bind9/bin/dnssec/dnssec-signzone.html
index 18d851d..6548d84 100644
--- a/contrib/bind9/bin/dnssec/dnssec-signzone.html
+++ b/contrib/bind9/bin/dnssec/dnssec-signzone.html
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: dnssec-signzone.html,v 1.8.18.25 2008/10/16 01:29:40 tbox Exp $ -->
+<!-- $Id: dnssec-signzone.html,v 1.33 2008/10/15 01:11:35 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -29,10 +29,10 @@
 </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">-I <em class="replaceable"><code>input-format</code></em></code>] [<code class="option">-j <em class="replaceable"><code>jitter</code></em></code>] [<code class="option">-N <em class="replaceable"><code>soa-serial-format</code></em></code>] [<code class="option">-o <em class="replaceable"><code>origin</code></em></code>] [<code class="option">-O <em class="replaceable"><code>output-format</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 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">-I <em class="replaceable"><code>input-format</code></em></code>] [<code class="option">-j <em class="replaceable"><code>jitter</code></em></code>] [<code class="option">-N <em class="replaceable"><code>soa-serial-format</code></em></code>] [<code class="option">-o <em class="replaceable"><code>origin</code></em></code>] [<code class="option">-O <em class="replaceable"><code>output-format</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>] [<code class="option">-3 <em class="replaceable"><code>salt</code></em></code>] [<code class="option">-H <em class="replaceable"><code>iterations</code></em></code>] [<code class="option">-A</code>] {zonefile} [key...]</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2543529"></a><h2>DESCRIPTION</h2>
+<a name="id2543550"></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
@@ -43,7 +43,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2543544"></a><h2>OPTIONS</h2>
+<a name="id2543565"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-a</span></dt>
 <dd><p>
@@ -226,6 +226,23 @@
 <dd><p>
             Ignore KSK flag on key when determining what to sign.
           </p></dd>
+<dt><span class="term">-3 <em class="replaceable"><code>salt</code></em></span></dt>
+<dd><p>
+            Generate a NSEC3 chain with the given hex encoded salt.
+	    A dash (<em class="replaceable"><code>salt</code></em>) can
+	    be used to indicate that no salt is to be used when generating		    the NSEC3 chain.
+          </p></dd>
+<dt><span class="term">-H <em class="replaceable"><code>iterations</code></em></span></dt>
+<dd><p>
+	    When generating a NSEC3 chain use this many interations.  The
+	    default is 100.
+          </p></dd>
+<dt><span class="term">-A</span></dt>
+<dd><p>
+	    When generating a NSEC3 chain set the OPTOUT flag on all
+	    NSEC3 records and do not generate NSEC3 records for insecure
+	    delegations.
+          </p></dd>
 <dt><span class="term">zonefile</span></dt>
 <dd><p>
             The file containing the zone to be signed.
@@ -241,7 +258,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2544330"></a><h2>EXAMPLE</h2>
+<a name="id2544404"></a><h2>EXAMPLE</h2>
 <p>
       The following command signs the <strong class="userinput"><code>example.com</code></strong>
       zone with the DSA key generated by <span><strong class="command">dnssec-keygen</strong></span>
@@ -270,14 +287,14 @@ db.example.com.signed
 %</pre>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2544381"></a><h2>SEE ALSO</h2>
+<a name="id2544523"></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 4033</em>.
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2544406"></a><h2>AUTHOR</h2>
+<a name="id2544548"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
diff --git a/contrib/bind9/bin/dnssec/dnssectool.c b/contrib/bind9/bin/dnssec/dnssectool.c
index 4f95540..e933a06 100644
--- a/contrib/bind9/bin/dnssec/dnssectool.c
+++ b/contrib/bind9/bin/dnssec/dnssectool.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dnssectool.c,v 1.40.18.3 2005/07/01 03:55:28 marka Exp $ */
+/* $Id: dnssectool.c,v 1.45 2007/06/19 23:46:59 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/bin/dnssec/dnssectool.h b/contrib/bind9/bin/dnssec/dnssectool.h
index c5f3648..ee476f4 100644
--- a/contrib/bind9/bin/dnssec/dnssectool.h
+++ b/contrib/bind9/bin/dnssec/dnssectool.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dnssectool.h,v 1.18 2004/03/05 04:57:41 marka Exp $ */
+/* $Id: dnssectool.h,v 1.22 2008/09/25 04:02:38 tbox Exp $ */
 
 #ifndef DNSSECTOOL_H
 #define DNSSECTOOL_H 1
@@ -41,7 +41,7 @@ vbprintf(int level, const char *fmt, ...) ISC_FORMAT_PRINTF(2, 3);
 
 void
 type_format(const dns_rdatatype_t type, char *cp, unsigned int size);
-#define TYPE_FORMATSIZE 10
+#define TYPE_FORMATSIZE 20
 
 void
 alg_format(const dns_secalg_t alg, char *cp, unsigned int size);
diff --git a/contrib/bind9/bin/named/Makefile.in b/contrib/bind9/bin/named/Makefile.in
index a809e59c..4d800a6 100644
--- a/contrib/bind9/bin/named/Makefile.in
+++ b/contrib/bind9/bin/named/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1998-2002  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.80.18.7 2005/09/05 00:18:10 marka Exp $
+# $Id: Makefile.in,v 1.101 2008/09/23 17:25:47 jinmei Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -21,6 +21,8 @@ top_srcdir =	@top_srcdir@
 
 @BIND9_VERSION@
 
+@BIND9_CONFIGARGS@
+
 @BIND9_MAKE_INCLUDES@
 
 #
@@ -38,7 +40,7 @@ DLZDRIVER_SRCS =	@DLZ_DRIVER_SRCS@
 DLZDRIVER_INCLUDES =	@DLZ_DRIVER_INCLUDES@
 DLZDRIVER_LIBS =	@DLZ_DRIVER_LIBS@
 
-CINCLUDES =	-I${srcdir}/include -I${srcdir}/unix/include \
+CINCLUDES =	-I${srcdir}/include -I${srcdir}/unix/include -I. \
 		${LWRES_INCLUDES} ${DNS_INCLUDES} ${BIND9_INCLUDES} \
 		${ISCCFG_INCLUDES} ${ISCCC_INCLUDES} ${ISC_INCLUDES} \
 		${DLZDRIVER_INCLUDES} ${DBDRIVER_INCLUDES}
@@ -75,7 +77,7 @@ TARGETS =	named@EXEEXT@ lwresd@EXEEXT@
 OBJS =		builtin.@O@ client.@O@ config.@O@ control.@O@ \
 		controlconf.@O@ interfacemgr.@O@ \
 		listenlist.@O@ log.@O@ logconf.@O@ main.@O@ notify.@O@ \
-		query.@O@ server.@O@ sortlist.@O@ \
+		query.@O@ server.@O@ sortlist.@O@ statschannel.@O@ \
 		tkeyconf.@O@ tsigconf.@O@ update.@O@ xfrout.@O@ \
 		zoneconf.@O@ \
 		lwaddr.@O@ lwresd.@O@ lwdclient.@O@ lwderror.@O@ lwdgabn.@O@ \
@@ -87,7 +89,7 @@ UOBJS =		unix/os.@O@
 SRCS =		builtin.c client.c config.c control.c \
 		controlconf.c interfacemgr.c \
 		listenlist.c log.c logconf.c main.c notify.c \
-		query.c server.c sortlist.c \
+		query.c server.c sortlist.c statschannel.c \
 		tkeyconf.c tsigconf.c update.c xfrout.c \
 		zoneconf.c \
 		lwaddr.c lwresd.c lwdclient.c lwderror.c lwdgabn.c \
@@ -105,6 +107,7 @@ MANOBJS =	${MANPAGES} ${HTMLPAGES}
 main.@O@: main.c
 	${LIBTOOL_MODE_COMPILE} ${CC} ${ALL_CFLAGS} \
 		-DVERSION=\"${VERSION}\" \
+		-DCONFIGARGS="\"${CONFIGARGS}\"" \
 		-DNS_LOCALSTATEDIR=\"${localstatedir}\" \
 		-DNS_SYSCONFDIR=\"${sysconfdir}\" -c ${srcdir}/main.c
 
@@ -130,6 +133,12 @@ docclean manclean maintainer-clean::
 clean distclean maintainer-clean::
 	rm -f ${TARGETS} ${OBJS}
 
+bind9.xsl.h: bind9.xsl convertxsl.pl
+	${PERL} ${srcdir}/convertxsl.pl < ${srcdir}/bind9.xsl > bind9.xsl.h
+
+depend: bind9.xsl.h
+statschannel.@O@: bind9.xsl.h
+
 installdirs:
 	$(SHELL) ${top_srcdir}/mkinstalldirs ${DESTDIR}${sbindir}
 	$(SHELL) ${top_srcdir}/mkinstalldirs ${DESTDIR}${mandir}/man5
diff --git a/contrib/bind9/bin/named/bind9.xsl b/contrib/bind9/bin/named/bind9.xsl
new file mode 100644
index 0000000..2cadbfd
--- /dev/null
+++ b/contrib/bind9/bin/named/bind9.xsl
@@ -0,0 +1,492 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!--
+ - Copyright (C) 2006-2009  Internet Systems Consortium, Inc. ("ISC")
+ -
+ - Permission to use, copy, modify, and/or 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: bind9.xsl,v 1.19.82.2 2009/01/29 23:47:43 tbox Exp $ -->
+
+<xsl:stylesheet version="1.0"
+   xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+   xmlns="http://www.w3.org/1999/xhtml">
+  <xsl:template match="isc/bind/statistics">
+    <html>
+      <head>
+        <style type="text/css">
+body {
+	font-family: sans-serif;
+	background-color: #ffffff;
+	color: #000000;
+}
+
+table {
+	border-collapse: collapse;
+}
+
+tr.rowh {
+	text-align: center;
+	border: 1px solid #000000;
+	background-color: #8080ff;
+	color: #ffffff;
+}
+
+tr.row {
+	text-align: right;
+	border: 1px solid #000000;
+	background-color: teal;
+	color: #ffffff;
+}
+
+tr.lrow {
+	text-align: left;
+	border: 1px solid #000000;
+	background-color: teal;
+	color: #ffffff;
+}
+
+td, th {
+	padding-right: 5px;
+	padding-left: 5px;
+}
+
+.header h1 {
+	background-color: teal;
+	color: #ffffff;
+	padding: 4px;
+}
+
+.content {
+	background-color: #ffffff;
+	color: #000000;
+	padding: 4px;
+}
+
+.item {
+	padding: 4px;
+	align: right;
+}
+
+.value {
+	padding: 4px;
+	font-weight: bold;
+}
+
+div.statcounter h2 {
+	text-align: center;
+	font-size: large;
+	border: 1px solid #000000;
+	background-color: #8080ff;
+	color: #ffffff;
+}
+
+div.statcounter dl {
+	float: left;
+	margin-top: 0;
+	margin-bottom: 0;
+	margin-left: 0;
+	margin-right: 0;
+}
+
+div.statcounter dt {
+	width: 200px;
+	text-align: center;
+	font-weight: bold;
+	border: 0.5px solid #000000;
+	background-color: #8080ff;
+	color: #ffffff;
+}
+
+div.statcounter dd {
+	width: 200px;
+	text-align: right;
+	border: 0.5px solid #000000;
+	background-color: teal;
+	color: #ffffff;
+	margin-left: 0;
+	margin-right: 0;
+}
+
+div.statcounter br {
+	clear: left;
+}
+        </style>
+        <title>BIND 9 Statistics</title>
+      </head>
+      <body>
+	<div class="header">
+	  <h1>Bind 9 Configuration and Statistics</h1>
+	</div>
+
+	<br/>
+
+	<table>
+	  <tr class="rowh"><th colspan="2">Times</th></tr>
+	  <tr class="lrow">
+	    <td>boot-time</td>
+	    <td><xsl:value-of select="server/boot-time"/></td>
+	  </tr>
+	  <tr class="lrow">
+	    <td>current-time</td>
+	    <td><xsl:value-of select="server/current-time"/></td>
+	  </tr>
+	</table>
+
+	<br/>
+
+	<table>
+	  <tr class="rowh"><th colspan="2">Incoming Requests</th></tr>
+	  <xsl:for-each select="server/requests/opcode">
+	    <tr class="lrow">
+	      <td><xsl:value-of select="name"/></td>
+	      <td><xsl:value-of select="counter"/></td>
+	    </tr>
+	  </xsl:for-each>
+	</table>
+
+	<br/>
+
+	<table>
+	  <tr class="rowh"><th colspan="2">Incoming Queries</th></tr>
+	  <xsl:for-each select="server/queries-in/rdtype">
+	    <tr class="lrow">
+	      <td><xsl:value-of select="name"/></td>
+	      <td><xsl:value-of select="counter"/></td>
+	    </tr>
+	  </xsl:for-each>
+	</table>
+
+	<br/>
+
+	<xsl:for-each select="views/view">
+	  <table>
+	    <tr class="rowh">
+	      <th colspan="2">Outgoing Queries from View <xsl:value-of select="name"/></th>
+	    </tr>
+	    <xsl:for-each select="rdtype">
+	      <tr class="lrow">
+		<td><xsl:value-of select="name"/></td>
+		<td><xsl:value-of select="counter"/></td>
+	      </tr>
+	    </xsl:for-each>
+	  </table>
+	  <br/>
+	</xsl:for-each>
+
+	<br/>
+
+	<div class="statcounter">
+	  <h2>Server Statistics</h2>
+	  <xsl:for-each select="server/nsstat">
+	    <dl>
+	      <dt><xsl:value-of select="name"/></dt>
+	      <dd><xsl:value-of select="counter"/></dd>
+	    </dl>
+	  </xsl:for-each>
+	  <br/>
+	</div>
+
+	<div class="statcounter">
+	  <h2>Zone Maintenance Statistics</h2>
+	  <xsl:for-each select="server/zonestat">
+	    <dl>
+	      <dt><xsl:value-of select="name"/></dt>
+	      <dd><xsl:value-of select="counter"/></dd>
+	    </dl>
+	  </xsl:for-each>
+	  <br />
+	</div>
+
+	<div class="statcounter">
+	  <h2>Resolver Statistics (Common)</h2>
+	  <xsl:for-each select="server/resstat">
+	    <dl>
+	      <dt><xsl:value-of select="name"/></dt>
+	      <dd><xsl:value-of select="counter"/></dd>
+	    </dl>
+	  </xsl:for-each>
+	  <br />
+	</div>
+
+	<xsl:for-each select="views/view">
+	  <div class="statcounter">
+	    <h2>Resolver Statistics for View <xsl:value-of select="name"/></h2>
+	    <xsl:for-each select="resstat">
+	      <dl>
+		<dt><xsl:value-of select="name"/></dt>
+		<dd><xsl:value-of select="counter"/></dd>
+	      </dl>
+	    </xsl:for-each>
+	    <br />
+	  </div>
+	</xsl:for-each>
+
+	<br />
+
+	<xsl:for-each select="views/view">
+	  <table>
+	    <tr class="rowh">
+	      <th colspan="2">Cache DB RRsets for View <xsl:value-of select="name"/></th>
+	    </tr>
+	    <xsl:for-each select="cache/rrset">
+	      <tr class="lrow">
+		<td><xsl:value-of select="name"/></td>
+		<td><xsl:value-of select="counter"/></td>
+	      </tr>
+	    </xsl:for-each>
+	  </table>
+	  <br/>
+	</xsl:for-each>
+
+	<div class="statcounter">
+	  <h2>Socket I/O Statistics</h2>
+	  <xsl:for-each select="server/sockstat">
+	    <dl>
+	      <dt><xsl:value-of select="name"/></dt>
+	      <dd><xsl:value-of select="counter"/></dd>
+	    </dl>
+	  </xsl:for-each>
+	  <br/>
+	</div>
+
+	<br/>
+
+        <xsl:for-each select="views/view">
+          <table>
+            <tr class="rowh">
+              <th colspan="10">Zones for View <xsl:value-of select="name"/></th>
+            </tr>
+            <tr class="rowh">
+              <th>Name</th>
+              <th>Class</th>
+              <th>Serial</th>
+              <th>Success</th>
+              <th>Referral</th>
+              <th>NXRRSET</th>
+              <th>NXDOMAIN</th>
+              <th>Failure</th>
+	      <th>XfrReqDone</th>
+	      <th>XfrRej</th>
+            </tr>
+            <xsl:for-each select="zones/zone">
+              <tr class="lrow">
+                <td>
+                  <xsl:value-of select="name"/>
+                </td>
+                <td>
+                  <xsl:value-of select="rdataclass"/>
+                </td>
+                <td>
+                  <xsl:value-of select="serial"/>
+                </td>
+                <td>
+                  <xsl:value-of select="counters/QrySuccess"/>
+                </td>
+                <td>
+                  <xsl:value-of select="counters/QryReferral"/>
+                </td>
+                <td>
+                  <xsl:value-of select="counters/QryNxrrset"/>
+                </td>
+                <td>
+                  <xsl:value-of select="counters/QryNXDOMAIN"/>
+                </td>
+                <td>
+                  <xsl:value-of select="counters/QryFailure"/>
+                </td>
+                <td>
+                  <xsl:value-of select="counters/XfrReqDone"/>
+                </td>
+                <td>
+                  <xsl:value-of select="counters/XfrRej"/>
+                </td>
+              </tr>
+            </xsl:for-each>
+          </table>
+          <br/>
+        </xsl:for-each>
+
+        <br/>
+
+        <table>
+          <tr class="rowh">
+            <th colspan="7">Network Status</th>
+          </tr>
+          <tr class="rowh">
+            <th>ID</th>
+	    <th>Name</th>
+            <th>Type</th>
+            <th>References</th>
+            <th>LocalAddress</th>
+            <th>PeerAddress</th>
+            <th>State</th>
+          </tr>
+          <xsl:for-each select="socketmgr/sockets/socket">
+            <tr class="lrow">
+              <td>
+                <xsl:value-of select="id"/>
+              </td>
+              <td>
+                <xsl:value-of select="name"/>
+              </td>
+              <td>
+                <xsl:value-of select="type"/>
+              </td>
+              <td>
+                <xsl:value-of select="references"/>
+              </td>
+              <td>
+                <xsl:value-of select="local-address"/>
+              </td>
+              <td>
+                <xsl:value-of select="peer-address"/>
+              </td>
+              <td>
+                <xsl:for-each select="states">
+                  <xsl:value-of select="."/>
+                </xsl:for-each>
+              </td>
+            </tr>
+          </xsl:for-each>
+        </table>
+        <br/>
+        <table>
+          <tr class="rowh">
+            <th colspan="2">Task Manager Configuration</th>
+          </tr>
+          <tr class="lrow">
+            <td>Thread-Model</td>
+            <td>
+              <xsl:value-of select="taskmgr/thread-model/type"/>
+            </td>
+          </tr>
+          <tr class="lrow">
+            <td>Worker Threads</td>
+            <td>
+              <xsl:value-of select="taskmgr/thread-model/worker-threads"/>
+            </td>
+          </tr>
+          <tr class="lrow">
+            <td>Default Quantum</td>
+            <td>
+              <xsl:value-of select="taskmgr/thread-model/default-quantum"/>
+            </td>
+          </tr>
+          <tr class="lrow">
+            <td>Tasks Running</td>
+            <td>
+              <xsl:value-of select="taskmgr/thread-model/tasks-running"/>
+            </td>
+          </tr>
+        </table>
+        <br/>
+        <table>
+          <tr class="rowh">
+            <th colspan="5">Tasks</th>
+          </tr>
+          <tr class="rowh">
+            <th>ID</th>
+            <th>Name</th>
+            <th>References</th>
+            <th>State</th>
+            <th>Quantum</th>
+          </tr>
+          <xsl:for-each select="taskmgr/tasks/task">
+            <tr class="lrow">
+              <td>
+                <xsl:value-of select="id"/>
+              </td>
+              <td>
+                <xsl:value-of select="name"/>
+              </td>
+              <td>
+                <xsl:value-of select="references"/>
+              </td>
+              <td>
+                <xsl:value-of select="state"/>
+              </td>
+              <td>
+                <xsl:value-of select="quantum"/>
+              </td>
+            </tr>
+          </xsl:for-each>
+        </table>
+	<br />
+	<table>
+          <tr class="rowh">
+            <th colspan="4">Memory Usage Summary</th>
+          </tr>
+	  <xsl:for-each select="memory/summary/*">
+	    <tr class="lrow">
+	      <td><xsl:value-of select="name()"/></td>
+	      <td><xsl:value-of select="."/></td>
+	    </tr>
+	  </xsl:for-each>
+	</table>
+	<br />
+	<table>
+          <tr class="rowh">
+            <th colspan="10">Memory Contexts</th>
+          </tr>
+	  <tr class="rowh">
+	    <th>ID</th>
+	    <th>Name</th>
+	    <th>References</th>
+	    <th>TotalUse</th>
+	    <th>InUse</th>
+	    <th>MaxUse</th>
+	    <th>BlockSize</th>
+	    <th>Pools</th>
+	    <th>HiWater</th>
+	    <th>LoWater</th>
+	  </tr>
+	  <xsl:for-each select="memory/contexts/context">
+	    <tr class="lrow">
+	      <td>
+		<xsl:value-of select="id"/>
+	      </td>
+              <td>
+                <xsl:value-of select="name"/>
+              </td>
+	      <td>
+		<xsl:value-of select="references"/>
+	      </td>
+	      <td>
+		<xsl:value-of select="total"/>
+	      </td>
+	      <td>
+		<xsl:value-of select="inuse"/>
+	      </td>
+	      <td>
+		<xsl:value-of select="maxinuse"/>
+	      </td>
+	      <td>
+		<xsl:value-of select="blocksize"/>
+	      </td>
+	      <td>
+		<xsl:value-of select="pools"/>
+	      </td>
+	      <td>
+		<xsl:value-of select="hiwater"/>
+	      </td>
+	      <td>
+		<xsl:value-of select="lowater"/>
+	      </td>
+	    </tr>
+	  </xsl:for-each>
+	</table>
+
+      </body>
+    </html>
+  </xsl:template>
+</xsl:stylesheet>
diff --git a/contrib/bind9/bin/named/bind9.xsl.h b/contrib/bind9/bin/named/bind9.xsl.h
new file mode 100644
index 0000000..e42fda0
--- /dev/null
+++ b/contrib/bind9/bin/named/bind9.xsl.h
@@ -0,0 +1,497 @@
+/*
+ * Generated by convertxsl.pl 1.14 2008/07/17 23:43:26 jinmei Exp  
+ * From bind9.xsl 1.19.82.2 2009/01/29 23:47:43 tbox Exp 
+ */
+static char xslmsg[] =
+	"<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n"
+	"<!--\n"
+	" - Copyright (C) 2006-2009 Internet Systems Consortium, Inc. (\"ISC\")\n"
+	" -\n"
+	" - Permission to use, copy, modify, and/or distribute this software for any\n"
+	" - purpose with or without fee is hereby granted, provided that the above\n"
+	" - copyright notice and this permission notice appear in all copies.\n"
+	" -\n"
+	" - THE SOFTWARE IS PROVIDED \"AS IS\" AND ISC DISCLAIMS ALL WARRANTIES WITH\n"
+	" - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY\n"
+	" - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT,\n"
+	" - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM\n"
+	" - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE\n"
+	" - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR\n"
+	" - PERFORMANCE OF THIS SOFTWARE.\n"
+	"-->\n"
+	"\n"
+	"<!-- \045Id: bind9.xsl,v 1.19.82.2 2009/01/29 23:47:43 tbox Exp \045 -->\n"
+	"\n"
+	"<xsl:stylesheet version=\"1.0\"\n"
+	" xmlns:xsl=\"http://www.w3.org/1999/XSL/Transform\"\n"
+	" xmlns=\"http://www.w3.org/1999/xhtml\">\n"
+	" <xsl:template match=\"isc/bind/statistics\">\n"
+	" <html>\n"
+	" <head>\n"
+	" <style type=\"text/css\">\n"
+	"body {\n"
+	" font-family: sans-serif;\n"
+	" background-color: #ffffff;\n"
+	" color: #000000;\n"
+	"}\n"
+	"\n"
+	"table {\n"
+	" border-collapse: collapse;\n"
+	"}\n"
+	"\n"
+	"tr.rowh {\n"
+	" text-align: center;\n"
+	" border: 1px solid #000000;\n"
+	" background-color: #8080ff;\n"
+	" color: #ffffff;\n"
+	"}\n"
+	"\n"
+	"tr.row {\n"
+	" text-align: right;\n"
+	" border: 1px solid #000000;\n"
+	" background-color: teal;\n"
+	" color: #ffffff;\n"
+	"}\n"
+	"\n"
+	"tr.lrow {\n"
+	" text-align: left;\n"
+	" border: 1px solid #000000;\n"
+	" background-color: teal;\n"
+	" color: #ffffff;\n"
+	"}\n"
+	"\n"
+	"td, th {\n"
+	" padding-right: 5px;\n"
+	" padding-left: 5px;\n"
+	"}\n"
+	"\n"
+	".header h1 {\n"
+	" background-color: teal;\n"
+	" color: #ffffff;\n"
+	" padding: 4px;\n"
+	"}\n"
+	"\n"
+	".content {\n"
+	" background-color: #ffffff;\n"
+	" color: #000000;\n"
+	" padding: 4px;\n"
+	"}\n"
+	"\n"
+	".item {\n"
+	" padding: 4px;\n"
+	" align: right;\n"
+	"}\n"
+	"\n"
+	".value {\n"
+	" padding: 4px;\n"
+	" font-weight: bold;\n"
+	"}\n"
+	"\n"
+	"div.statcounter h2 {\n"
+	" text-align: center;\n"
+	" font-size: large;\n"
+	" border: 1px solid #000000;\n"
+	" background-color: #8080ff;\n"
+	" color: #ffffff;\n"
+	"}\n"
+	"\n"
+	"div.statcounter dl {\n"
+	" float: left;\n"
+	" margin-top: 0;\n"
+	" margin-bottom: 0;\n"
+	" margin-left: 0;\n"
+	" margin-right: 0;\n"
+	"}\n"
+	"\n"
+	"div.statcounter dt {\n"
+	" width: 200px;\n"
+	" text-align: center;\n"
+	" font-weight: bold;\n"
+	" border: 0.5px solid #000000;\n"
+	" background-color: #8080ff;\n"
+	" color: #ffffff;\n"
+	"}\n"
+	"\n"
+	"div.statcounter dd {\n"
+	" width: 200px;\n"
+	" text-align: right;\n"
+	" border: 0.5px solid #000000;\n"
+	" background-color: teal;\n"
+	" color: #ffffff;\n"
+	" margin-left: 0;\n"
+	" margin-right: 0;\n"
+	"}\n"
+	"\n"
+	"div.statcounter br {\n"
+	" clear: left;\n"
+	"}\n"
+	" </style>\n"
+	" <title>BIND 9 Statistics</title>\n"
+	" </head>\n"
+	" <body>\n"
+	" <div class=\"header\">\n"
+	" <h1>Bind 9 Configuration and Statistics</h1>\n"
+	" </div>\n"
+	"\n"
+	" <br/>\n"
+	"\n"
+	" <table>\n"
+	" <tr class=\"rowh\"><th colspan=\"2\">Times</th></tr>\n"
+	" <tr class=\"lrow\">\n"
+	" <td>boot-time</td>\n"
+	" <td><xsl:value-of select=\"server/boot-time\"/></td>\n"
+	" </tr>\n"
+	" <tr class=\"lrow\">\n"
+	" <td>current-time</td>\n"
+	" <td><xsl:value-of select=\"server/current-time\"/></td>\n"
+	" </tr>\n"
+	" </table>\n"
+	"\n"
+	" <br/>\n"
+	"\n"
+	" <table>\n"
+	" <tr class=\"rowh\"><th colspan=\"2\">Incoming Requests</th></tr>\n"
+	" <xsl:for-each select=\"server/requests/opcode\">\n"
+	" <tr class=\"lrow\">\n"
+	" <td><xsl:value-of select=\"name\"/></td>\n"
+	" <td><xsl:value-of select=\"counter\"/></td>\n"
+	" </tr>\n"
+	" </xsl:for-each>\n"
+	" </table>\n"
+	"\n"
+	" <br/>\n"
+	"\n"
+	" <table>\n"
+	" <tr class=\"rowh\"><th colspan=\"2\">Incoming Queries</th></tr>\n"
+	" <xsl:for-each select=\"server/queries-in/rdtype\">\n"
+	" <tr class=\"lrow\">\n"
+	" <td><xsl:value-of select=\"name\"/></td>\n"
+	" <td><xsl:value-of select=\"counter\"/></td>\n"
+	" </tr>\n"
+	" </xsl:for-each>\n"
+	" </table>\n"
+	"\n"
+	" <br/>\n"
+	"\n"
+	" <xsl:for-each select=\"views/view\">\n"
+	" <table>\n"
+	" <tr class=\"rowh\">\n"
+	" <th colspan=\"2\">Outgoing Queries from View <xsl:value-of select=\"name\"/></th>\n"
+	" </tr>\n"
+	" <xsl:for-each select=\"rdtype\">\n"
+	" <tr class=\"lrow\">\n"
+	" <td><xsl:value-of select=\"name\"/></td>\n"
+	" <td><xsl:value-of select=\"counter\"/></td>\n"
+	" </tr>\n"
+	" </xsl:for-each>\n"
+	" </table>\n"
+	" <br/>\n"
+	" </xsl:for-each>\n"
+	"\n"
+	" <br/>\n"
+	"\n"
+	" <div class=\"statcounter\">\n"
+	" <h2>Server Statistics</h2>\n"
+	" <xsl:for-each select=\"server/nsstat\">\n"
+	" <dl>\n"
+	" <dt><xsl:value-of select=\"name\"/></dt>\n"
+	" <dd><xsl:value-of select=\"counter\"/></dd>\n"
+	" </dl>\n"
+	" </xsl:for-each>\n"
+	" <br/>\n"
+	" </div>\n"
+	"\n"
+	" <div class=\"statcounter\">\n"
+	" <h2>Zone Maintenance Statistics</h2>\n"
+	" <xsl:for-each select=\"server/zonestat\">\n"
+	" <dl>\n"
+	" <dt><xsl:value-of select=\"name\"/></dt>\n"
+	" <dd><xsl:value-of select=\"counter\"/></dd>\n"
+	" </dl>\n"
+	" </xsl:for-each>\n"
+	" <br />\n"
+	" </div>\n"
+	"\n"
+	" <div class=\"statcounter\">\n"
+	" <h2>Resolver Statistics (Common)</h2>\n"
+	" <xsl:for-each select=\"server/resstat\">\n"
+	" <dl>\n"
+	" <dt><xsl:value-of select=\"name\"/></dt>\n"
+	" <dd><xsl:value-of select=\"counter\"/></dd>\n"
+	" </dl>\n"
+	" </xsl:for-each>\n"
+	" <br />\n"
+	" </div>\n"
+	"\n"
+	" <xsl:for-each select=\"views/view\">\n"
+	" <div class=\"statcounter\">\n"
+	" <h2>Resolver Statistics for View <xsl:value-of select=\"name\"/></h2>\n"
+	" <xsl:for-each select=\"resstat\">\n"
+	" <dl>\n"
+	" <dt><xsl:value-of select=\"name\"/></dt>\n"
+	" <dd><xsl:value-of select=\"counter\"/></dd>\n"
+	" </dl>\n"
+	" </xsl:for-each>\n"
+	" <br />\n"
+	" </div>\n"
+	" </xsl:for-each>\n"
+	"\n"
+	" <br />\n"
+	"\n"
+	" <xsl:for-each select=\"views/view\">\n"
+	" <table>\n"
+	" <tr class=\"rowh\">\n"
+	" <th colspan=\"2\">Cache DB RRsets for View <xsl:value-of select=\"name\"/></th>\n"
+	" </tr>\n"
+	" <xsl:for-each select=\"cache/rrset\">\n"
+	" <tr class=\"lrow\">\n"
+	" <td><xsl:value-of select=\"name\"/></td>\n"
+	" <td><xsl:value-of select=\"counter\"/></td>\n"
+	" </tr>\n"
+	" </xsl:for-each>\n"
+	" </table>\n"
+	" <br/>\n"
+	" </xsl:for-each>\n"
+	"\n"
+	" <div class=\"statcounter\">\n"
+	" <h2>Socket I/O Statistics</h2>\n"
+	" <xsl:for-each select=\"server/sockstat\">\n"
+	" <dl>\n"
+	" <dt><xsl:value-of select=\"name\"/></dt>\n"
+	" <dd><xsl:value-of select=\"counter\"/></dd>\n"
+	" </dl>\n"
+	" </xsl:for-each>\n"
+	" <br/>\n"
+	" </div>\n"
+	"\n"
+	" <br/>\n"
+	"\n"
+	" <xsl:for-each select=\"views/view\">\n"
+	" <table>\n"
+	" <tr class=\"rowh\">\n"
+	" <th colspan=\"10\">Zones for View <xsl:value-of select=\"name\"/></th>\n"
+	" </tr>\n"
+	" <tr class=\"rowh\">\n"
+	" <th>Name</th>\n"
+	" <th>Class</th>\n"
+	" <th>Serial</th>\n"
+	" <th>Success</th>\n"
+	" <th>Referral</th>\n"
+	" <th>NXRRSET</th>\n"
+	" <th>NXDOMAIN</th>\n"
+	" <th>Failure</th>\n"
+	" <th>XfrReqDone</th>\n"
+	" <th>XfrRej</th>\n"
+	" </tr>\n"
+	" <xsl:for-each select=\"zones/zone\">\n"
+	" <tr class=\"lrow\">\n"
+	" <td>\n"
+	" <xsl:value-of select=\"name\"/>\n"
+	" </td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"rdataclass\"/>\n"
+	" </td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"serial\"/>\n"
+	" </td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"counters/QrySuccess\"/>\n"
+	" </td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"counters/QryReferral\"/>\n"
+	" </td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"counters/QryNxrrset\"/>\n"
+	" </td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"counters/QryNXDOMAIN\"/>\n"
+	" </td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"counters/QryFailure\"/>\n"
+	" </td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"counters/XfrReqDone\"/>\n"
+	" </td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"counters/XfrRej\"/>\n"
+	" </td>\n"
+	" </tr>\n"
+	" </xsl:for-each>\n"
+	" </table>\n"
+	" <br/>\n"
+	" </xsl:for-each>\n"
+	"\n"
+	" <br/>\n"
+	"\n"
+	" <table>\n"
+	" <tr class=\"rowh\">\n"
+	" <th colspan=\"7\">Network Status</th>\n"
+	" </tr>\n"
+	" <tr class=\"rowh\">\n"
+	" <th>ID</th>\n"
+	" <th>Name</th>\n"
+	" <th>Type</th>\n"
+	" <th>References</th>\n"
+	" <th>LocalAddress</th>\n"
+	" <th>PeerAddress</th>\n"
+	" <th>State</th>\n"
+	" </tr>\n"
+	" <xsl:for-each select=\"socketmgr/sockets/socket\">\n"
+	" <tr class=\"lrow\">\n"
+	" <td>\n"
+	" <xsl:value-of select=\"id\"/>\n"
+	" </td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"name\"/>\n"
+	" </td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"type\"/>\n"
+	" </td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"references\"/>\n"
+	" </td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"local-address\"/>\n"
+	" </td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"peer-address\"/>\n"
+	" </td>\n"
+	" <td>\n"
+	" <xsl:for-each select=\"states\">\n"
+	" <xsl:value-of select=\".\"/>\n"
+	" </xsl:for-each>\n"
+	" </td>\n"
+	" </tr>\n"
+	" </xsl:for-each>\n"
+	" </table>\n"
+	" <br/>\n"
+	" <table>\n"
+	" <tr class=\"rowh\">\n"
+	" <th colspan=\"2\">Task Manager Configuration</th>\n"
+	" </tr>\n"
+	" <tr class=\"lrow\">\n"
+	" <td>Thread-Model</td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"taskmgr/thread-model/type\"/>\n"
+	" </td>\n"
+	" </tr>\n"
+	" <tr class=\"lrow\">\n"
+	" <td>Worker Threads</td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"taskmgr/thread-model/worker-threads\"/>\n"
+	" </td>\n"
+	" </tr>\n"
+	" <tr class=\"lrow\">\n"
+	" <td>Default Quantum</td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"taskmgr/thread-model/default-quantum\"/>\n"
+	" </td>\n"
+	" </tr>\n"
+	" <tr class=\"lrow\">\n"
+	" <td>Tasks Running</td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"taskmgr/thread-model/tasks-running\"/>\n"
+	" </td>\n"
+	" </tr>\n"
+	" </table>\n"
+	" <br/>\n"
+	" <table>\n"
+	" <tr class=\"rowh\">\n"
+	" <th colspan=\"5\">Tasks</th>\n"
+	" </tr>\n"
+	" <tr class=\"rowh\">\n"
+	" <th>ID</th>\n"
+	" <th>Name</th>\n"
+	" <th>References</th>\n"
+	" <th>State</th>\n"
+	" <th>Quantum</th>\n"
+	" </tr>\n"
+	" <xsl:for-each select=\"taskmgr/tasks/task\">\n"
+	" <tr class=\"lrow\">\n"
+	" <td>\n"
+	" <xsl:value-of select=\"id\"/>\n"
+	" </td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"name\"/>\n"
+	" </td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"references\"/>\n"
+	" </td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"state\"/>\n"
+	" </td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"quantum\"/>\n"
+	" </td>\n"
+	" </tr>\n"
+	" </xsl:for-each>\n"
+	" </table>\n"
+	" <br />\n"
+	" <table>\n"
+	" <tr class=\"rowh\">\n"
+	" <th colspan=\"4\">Memory Usage Summary</th>\n"
+	" </tr>\n"
+	" <xsl:for-each select=\"memory/summary/*\">\n"
+	" <tr class=\"lrow\">\n"
+	" <td><xsl:value-of select=\"name()\"/></td>\n"
+	" <td><xsl:value-of select=\".\"/></td>\n"
+	" </tr>\n"
+	" </xsl:for-each>\n"
+	" </table>\n"
+	" <br />\n"
+	" <table>\n"
+	" <tr class=\"rowh\">\n"
+	" <th colspan=\"10\">Memory Contexts</th>\n"
+	" </tr>\n"
+	" <tr class=\"rowh\">\n"
+	" <th>ID</th>\n"
+	" <th>Name</th>\n"
+	" <th>References</th>\n"
+	" <th>TotalUse</th>\n"
+	" <th>InUse</th>\n"
+	" <th>MaxUse</th>\n"
+	" <th>BlockSize</th>\n"
+	" <th>Pools</th>\n"
+	" <th>HiWater</th>\n"
+	" <th>LoWater</th>\n"
+	" </tr>\n"
+	" <xsl:for-each select=\"memory/contexts/context\">\n"
+	" <tr class=\"lrow\">\n"
+	" <td>\n"
+	" <xsl:value-of select=\"id\"/>\n"
+	" </td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"name\"/>\n"
+	" </td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"references\"/>\n"
+	" </td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"total\"/>\n"
+	" </td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"inuse\"/>\n"
+	" </td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"maxinuse\"/>\n"
+	" </td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"blocksize\"/>\n"
+	" </td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"pools\"/>\n"
+	" </td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"hiwater\"/>\n"
+	" </td>\n"
+	" <td>\n"
+	" <xsl:value-of select=\"lowater\"/>\n"
+	" </td>\n"
+	" </tr>\n"
+	" </xsl:for-each>\n"
+	" </table>\n"
+	"\n"
+	" </body>\n"
+	" </html>\n"
+	" </xsl:template>\n"
+	"</xsl:stylesheet>\n";
diff --git a/contrib/bind9/bin/named/builtin.c b/contrib/bind9/bin/named/builtin.c
index 06cbd4a..7927737 100644
--- a/contrib/bind9/bin/named/builtin.c
+++ b/contrib/bind9/bin/named/builtin.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: builtin.c,v 1.5.18.5 2005/08/23 04:12:38 marka Exp $ */
+/* $Id: builtin.c,v 1.12 2007/06/19 23:46:59 tbox Exp $ */
 
 /*! \file
  * \brief
diff --git a/contrib/bind9/bin/named/client.c b/contrib/bind9/bin/named/client.c
index 03cfdb6..ae5386c 100644
--- a/contrib/bind9/bin/named/client.c
+++ b/contrib/bind9/bin/named/client.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: client.c,v 1.219.18.31 2008/05/22 23:46:03 tbox Exp $ */
+/* $Id: client.c,v 1.259.12.3 2009/01/29 22:40:33 jinmei Exp $ */
 
 #include <config.h>
 
@@ -24,6 +24,7 @@
 #include <isc/once.h>
 #include <isc/platform.h>
 #include <isc/print.h>
+#include <isc/stats.h>
 #include <isc/stdio.h>
 #include <isc/string.h>
 #include <isc/task.h>
@@ -41,6 +42,7 @@
 #include <dns/rdatalist.h>
 #include <dns/rdataset.h>
 #include <dns/resolver.h>
+#include <dns/stats.h>
 #include <dns/tsig.h>
 #include <dns/view.h>
 #include <dns/zone.h>
@@ -48,6 +50,7 @@
 #include <named/interfacemgr.h>
 #include <named/log.h>
 #include <named/notify.h>
+#include <named/os.h>
 #include <named/server.h>
 #include <named/update.h>
 
@@ -119,9 +122,9 @@ struct ns_clientmgr {
 	isc_mutex_t			lock;
 	/* Locked by lock. */
 	isc_boolean_t			exiting;
-	client_list_t			active; 	/*%< Active clients */
-	client_list_t			recursing; 	/*%< Recursing clients */
-	client_list_t 			inactive;	/*%< To be recycled */
+	client_list_t			active;		/*%< Active clients */
+	client_list_t			recursing;	/*%< Recursing clients */
+	client_list_t			inactive;	/*%< To be recycled */
 #if NMCTXS > 0
 	/*%< mctx pool for clients. */
 	unsigned int			nextmctx;
@@ -463,6 +466,8 @@ exit_check(ns_client_t *client) {
 
 		if (client->state == client->newstate) {
 			client->newstate = NS_CLIENTSTATE_MAX;
+			if (client->needshutdown)
+				isc_task_shutdown(client->task);
 			goto unlock;
 		}
 	}
@@ -519,6 +524,14 @@ exit_check(ns_client_t *client) {
 
 		CTRACE("free");
 		client->magic = 0;
+		/*
+		 * Check that there are no other external references to
+		 * the memory context.
+		 */
+		if (ns_g_clienttest && isc_mem_references(client->mctx) != 1) {
+			isc_mem_stats(client->mctx, stderr);
+			INSIST(0);
+		}
 		isc_mem_putanddetach(&client->mctx, client, sizeof(*client));
 
 		goto unlock;
@@ -592,6 +605,7 @@ client_shutdown(isc_task_t *task, isc_event_t *event) {
 	}
 
 	client->newstate = NS_CLIENTSTATE_FREED;
+	client->needshutdown = ISC_FALSE;
 	(void)exit_check(client);
 }
 
@@ -640,11 +654,11 @@ ns_client_checkactive(ns_client_t *client) {
 		/*
 		 * This client object should normally go inactive
 		 * at this point, but if we have fewer active client
-		 * objects than  desired due to earlier quota exhaustion,
+		 * objects than desired due to earlier quota exhaustion,
 		 * keep it active to make up for the shortage.
 		 */
 		isc_boolean_t need_another_client = ISC_FALSE;
-		if (TCP_CLIENT(client)) {
+		if (TCP_CLIENT(client) && !ns_g_clienttest) {
 			LOCK(&client->interface->lock);
 			if (client->interface->ntcpcurrent <
 			    client->interface->ntcptarget)
@@ -906,6 +920,7 @@ ns_client_send(ns_client_t *client) {
 	unsigned char sendbuf[SEND_BUFFER_SIZE];
 	unsigned int dnssec_opts;
 	unsigned int preferred_glue;
+	isc_boolean_t opt_included = ISC_FALSE;
 
 	REQUIRE(NS_CLIENT_VALID(client));
 
@@ -943,11 +958,10 @@ ns_client_send(ns_client_t *client) {
 	result = dns_message_renderbegin(client->message, &cctx, &buffer);
 	if (result != ISC_R_SUCCESS)
 		goto done;
+
 	if (client->opt != NULL) {
 		result = dns_message_setopt(client->message, client->opt);
-		/*
-		 * XXXRTH dns_message_setopt() should probably do this...
-		 */
+		opt_included = ISC_TRUE;
 		client->opt = NULL;
 		if (result != ISC_R_SUCCESS)
 			goto done;
@@ -1003,6 +1017,25 @@ ns_client_send(ns_client_t *client) {
 		result = client_sendpkg(client, &tcpbuffer);
 	} else
 		result = client_sendpkg(client, &buffer);
+
+	/* update statistics (XXXJT: is it okay to access message->xxxkey?) */
+	isc_stats_increment(ns_g_server->nsstats, dns_nsstatscounter_response);
+	if (opt_included) {
+		isc_stats_increment(ns_g_server->nsstats,
+				    dns_nsstatscounter_edns0out);
+	}
+	if (client->message->tsigkey != NULL) {
+		isc_stats_increment(ns_g_server->nsstats,
+				    dns_nsstatscounter_tsigout);
+	}
+	if (client->message->sig0key != NULL) {
+		isc_stats_increment(ns_g_server->nsstats,
+				    dns_nsstatscounter_sig0out);
+	}
+	if ((client->message->flags & DNS_MESSAGEFLAG_TC) != 0)
+		isc_stats_increment(ns_g_server->nsstats,
+				    dns_nsstatscounter_truncatedresp);
+
 	if (result == ISC_R_SUCCESS)
 		return;
 
@@ -1179,11 +1212,46 @@ client_addopt(ns_client_t *client) {
 	 */
 	rdatalist->ttl = (client->extflags & DNS_MESSAGEEXTFLAG_REPLYPRESERVE);
 
-	/*
-	 * No EDNS options in the default case.
-	 */
-	rdata->data = NULL;
-	rdata->length = 0;
+	/* Set EDNS options if applicable */
+	if (client->attributes & NS_CLIENTATTR_WANTNSID &&
+	    (ns_g_server->server_id != NULL ||
+	     ns_g_server->server_usehostname)) {
+		/*
+		 * Space required for NSID data:
+		 *   2 bytes for opt code
+		 * + 2 bytes for NSID length
+		 * + NSID itself
+		 */
+		char nsid[BUFSIZ], *nsidp;
+		isc_buffer_t *buffer = NULL;
+
+		if (ns_g_server->server_usehostname) {
+			isc_result_t result;
+			result = ns_os_gethostname(nsid, sizeof(nsid));
+			if (result != ISC_R_SUCCESS) {
+				goto no_nsid;
+			}
+			nsidp = nsid;
+		} else
+			nsidp = ns_g_server->server_id;
+
+		rdata->length = strlen(nsidp) + 4;
+		result = isc_buffer_allocate(client->mctx, &buffer,
+					     rdata->length);
+		if (result != ISC_R_SUCCESS)
+			goto no_nsid;
+
+		isc_buffer_putuint16(buffer, DNS_OPT_NSID);
+		isc_buffer_putuint16(buffer, strlen(nsidp));
+		isc_buffer_putstr(buffer, nsidp);
+		rdata->data = buffer->base;
+		dns_message_takebuffer(client->message, &buffer);
+	} else {
+no_nsid:
+		rdata->data = NULL;
+		rdata->length = 0;
+	}
+
 	rdata->rdclass = rdatalist->rdclass;
 	rdata->type = rdatalist->type;
 	rdata->flags = 0;
@@ -1218,7 +1286,7 @@ allowed(isc_netaddr_t *addr, dns_name_t *signer, dns_acl_t *acl) {
  * delivered to 'myview'.
  *
  * We run this unlocked as both the view list and the interface list
- * are updated when the approprite task has exclusivity.
+ * are updated when the appropriate task has exclusivity.
  */
 isc_boolean_t
 ns_client_isself(dns_view_t *myview, dns_tsigkey_t *mykey,
@@ -1253,14 +1321,14 @@ ns_client_isself(dns_view_t *myview, dns_tsigkey_t *mykey,
 			isc_boolean_t match;
 			isc_result_t result;
 
-			tsig = &mykey->name;
-			result = dns_view_gettsig(view, tsig, &key);
+			result = dns_view_gettsig(view, &mykey->name, &key);
 			if (result != ISC_R_SUCCESS)
 				continue;
 			match = dst_key_compare(mykey->key, key->key);
 			dns_tsigkey_detach(&key);
 			if (!match)
 				continue;
+			tsig = dns_tsigkey_identity(mykey);
 		}
 
 		if (allowed(&netsrc, tsig, view->matchclients) &&
@@ -1284,13 +1352,16 @@ client_request(isc_task_t *task, isc_event_t *event) {
 	isc_buffer_t tbuffer;
 	dns_view_t *view;
 	dns_rdataset_t *opt;
-	isc_boolean_t ra; 	/* Recursion available. */
+	dns_name_t *signame;
+	isc_boolean_t ra;	/* Recursion available. */
 	isc_netaddr_t netaddr;
 	isc_netaddr_t destaddr;
 	int match;
 	dns_messageid_t id;
 	unsigned int flags;
 	isc_boolean_t notimp;
+	dns_rdata_t rdata;
+	isc_uint16_t optcode;
 
 	REQUIRE(event != NULL);
 	client = event->ev_arg;
@@ -1440,6 +1511,20 @@ client_request(isc_task_t *task, isc_event_t *event) {
 	}
 
 	/*
+	 * Update some statistics counters.  Don't count responses.
+	 */
+	if (isc_sockaddr_pf(&client->peeraddr) == PF_INET) {
+		isc_stats_increment(ns_g_server->nsstats,
+				    dns_nsstatscounter_requestv4);
+	} else {
+		isc_stats_increment(ns_g_server->nsstats,
+				    dns_nsstatscounter_requestv6);
+	}
+	if (TCP_CLIENT(client))
+		isc_stats_increment(ns_g_server->nsstats,
+				    dns_nsstatscounter_tcp);
+
+	/*
 	 * It's a request.  Parse it.
 	 */
 	result = dns_message_parse(client->message, buffer, 0);
@@ -1452,6 +1537,8 @@ client_request(isc_task_t *task, isc_event_t *event) {
 		goto cleanup;
 	}
 
+	dns_opcodestats_increment(ns_g_server->opcodestats,
+				  client->message->opcode);
 	switch (client->message->opcode) {
 	case dns_opcode_query:
 	case dns_opcode_update:
@@ -1499,12 +1586,35 @@ client_request(isc_task_t *task, isc_event_t *event) {
 		 */
 		client->ednsversion = (opt->ttl & 0x00FF0000) >> 16;
 		if (client->ednsversion > 0) {
+			isc_stats_increment(ns_g_server->nsstats,
+					    dns_nsstatscounter_badednsver);
 			result = client_addopt(client);
 			if (result == ISC_R_SUCCESS)
 				result = DNS_R_BADVERS;
 			ns_client_error(client, result);
 			goto cleanup;
 		}
+
+		/* Check for NSID request */
+		result = dns_rdataset_first(opt);
+		if (result == ISC_R_SUCCESS) {
+			dns_rdata_init(&rdata);
+			dns_rdataset_current(opt, &rdata);
+			if (rdata.length >= 2) {
+				isc_buffer_t nsidbuf;
+				isc_buffer_init(&nsidbuf,
+						rdata.data, rdata.length);
+				isc_buffer_add(&nsidbuf, rdata.length);
+				optcode = isc_buffer_getuint16(&nsidbuf);
+				if (optcode == DNS_OPT_NSID)
+					client->attributes |=
+						NS_CLIENTATTR_WANTNSID;
+			}
+		}
+
+		isc_stats_increment(ns_g_server->nsstats,
+				    dns_nsstatscounter_edns0in);
+
 		/*
 		 * Create an OPT for our reply.
 		 */
@@ -1591,10 +1701,11 @@ client_request(isc_task_t *task, isc_event_t *event) {
 		    client->message->rdclass == dns_rdataclass_any)
 		{
 			dns_name_t *tsig = NULL;
+
 			sigresult = dns_message_rechecksig(client->message,
 							   view);
 			if (sigresult == ISC_R_SUCCESS)
-				tsig = client->message->tsigname;
+				tsig = dns_tsigkey_identity(client->message->tsigkey);
 
 			if (allowed(&netaddr, tsig, view->matchclients) &&
 			    allowed(&destaddr, tsig, view->matchdestinations) &&
@@ -1648,6 +1759,17 @@ client_request(isc_task_t *task, isc_event_t *event) {
 	client->signer = NULL;
 	dns_name_init(&client->signername, NULL);
 	result = dns_message_signer(client->message, &client->signername);
+	if (result != ISC_R_NOTFOUND) {
+		signame = NULL;
+		if (dns_message_gettsig(client->message, &signame) != NULL) {
+			isc_stats_increment(ns_g_server->nsstats,
+					    dns_nsstatscounter_tsigin);
+		} else {
+			isc_stats_increment(ns_g_server->nsstats,
+					    dns_nsstatscounter_sig0in);
+		}
+
+	}
 	if (result == ISC_R_SUCCESS) {
 		ns_client_log(client, DNS_LOGCATEGORY_SECURITY,
 			      NS_LOGMODULE_CLIENT, ISC_LOG_DEBUG(3),
@@ -1664,24 +1786,42 @@ client_request(isc_task_t *task, isc_event_t *event) {
 	} else {
 		char tsigrcode[64];
 		isc_buffer_t b;
-		dns_name_t *name = NULL;
 		dns_rcode_t status;
 		isc_result_t tresult;
 
 		/* There is a signature, but it is bad. */
-		if (dns_message_gettsig(client->message, &name) != NULL) {
+		isc_stats_increment(ns_g_server->nsstats,
+				    dns_nsstatscounter_invalidsig);
+		signame = NULL;
+		if (dns_message_gettsig(client->message, &signame) != NULL) {
 			char namebuf[DNS_NAME_FORMATSIZE];
-			dns_name_format(name, namebuf, sizeof(namebuf));
+			char cnamebuf[DNS_NAME_FORMATSIZE];
+			dns_name_format(signame, namebuf, sizeof(namebuf));
 			status = client->message->tsigstatus;
 			isc_buffer_init(&b, tsigrcode, sizeof(tsigrcode) - 1);
 			tresult = dns_tsigrcode_totext(status, &b);
 			INSIST(tresult == ISC_R_SUCCESS);
 			tsigrcode[isc_buffer_usedlength(&b)] = '\0';
-			ns_client_log(client, DNS_LOGCATEGORY_SECURITY,
-				      NS_LOGMODULE_CLIENT, ISC_LOG_ERROR,
-				      "request has invalid signature: "
-				      "TSIG %s: %s (%s)", namebuf,
-				      isc_result_totext(result), tsigrcode);
+			if (client->message->tsigkey->generated) {
+				dns_name_format(client->message->tsigkey->creator,
+						cnamebuf, sizeof(cnamebuf));
+				ns_client_log(client, DNS_LOGCATEGORY_SECURITY,
+					      NS_LOGMODULE_CLIENT,
+					      ISC_LOG_ERROR,
+					      "request has invalid signature: "
+					      "TSIG %s (%s): %s (%s)", namebuf,
+					      cnamebuf,
+					      isc_result_totext(result),
+					      tsigrcode);
+			} else {
+				ns_client_log(client, DNS_LOGCATEGORY_SECURITY,
+					      NS_LOGMODULE_CLIENT,
+					      ISC_LOG_ERROR,
+					      "request has invalid signature: "
+					      "TSIG %s: %s (%s)", namebuf,
+					      isc_result_totext(result),
+					      tsigrcode);
+			}
 		} else {
 			status = client->message->sig0status;
 			isc_buffer_init(&b, tsigrcode, sizeof(tsigrcode) - 1);
@@ -1715,9 +1855,17 @@ client_request(isc_task_t *task, isc_event_t *event) {
 	ra = ISC_FALSE;
 	if (client->view->resolver != NULL &&
 	    client->view->recursion == ISC_TRUE &&
-	    ns_client_checkaclsilent(client, client->view->recursionacl,
+	    ns_client_checkaclsilent(client, NULL,
+				     client->view->recursionacl,
+				     ISC_TRUE) == ISC_R_SUCCESS &&
+	    ns_client_checkaclsilent(client, NULL,
+				     client->view->queryacl,
+				     ISC_TRUE) == ISC_R_SUCCESS &&
+	    ns_client_checkaclsilent(client, &client->interface->addr,
+				     client->view->recursiononacl,
 				     ISC_TRUE) == ISC_R_SUCCESS &&
-	    ns_client_checkaclsilent(client, client->view->queryacl,
+	    ns_client_checkaclsilent(client, &client->interface->addr,
+				     client->view->queryonacl,
 				     ISC_TRUE) == ISC_R_SUCCESS)
 		ra = ISC_TRUE;
 
@@ -1804,13 +1952,17 @@ client_timeout(isc_task_t *task, isc_event_t *event) {
 static isc_result_t
 get_clientmctx(ns_clientmgr_t *manager, isc_mem_t **mctxp) {
 	isc_mem_t *clientmctx;
-#if NMCTXS > 0
 	isc_result_t result;
-#endif
 
 	/*
 	 * Caller must be holding the manager lock.
 	 */
+	if (ns_g_clienttest) {
+		result = isc_mem_create(0, 0, mctxp);
+		if (result == ISC_R_SUCCESS)
+			isc_mem_setname(*mctxp, "client", NULL);
+		return (result);
+	}
 #if NMCTXS > 0
 	INSIST(manager->nextmctx < NMCTXS);
 	clientmctx = manager->mctxpool[manager->nextmctx];
@@ -1818,6 +1970,7 @@ get_clientmctx(ns_clientmgr_t *manager, isc_mem_t **mctxp) {
 		result = isc_mem_create(0, 0, &clientmctx);
 		if (result != ISC_R_SUCCESS)
 			return (result);
+		isc_mem_setname(clientmctx, "client", NULL);
 
 		manager->mctxpool[manager->nextmctx] = clientmctx;
 	}
@@ -1966,6 +2119,8 @@ client_create(ns_clientmgr_t *manager, ns_client_t **clientp) {
 	if (result != ISC_R_SUCCESS)
 		goto cleanup_query;
 
+	client->needshutdown = ns_g_clienttest;
+
 	CTRACE("create");
 
 	*clientp = client;
@@ -2056,6 +2211,7 @@ client_newconn(isc_task_t *task, isc_event_t *event) {
 	 */
 	if (nevent->result == ISC_R_SUCCESS) {
 		client->tcpsocket = nevent->newsocket;
+		isc_socket_setname(client->tcpsocket, "client-tcp", NULL);
 		client->state = NS_CLIENTSTATE_READING;
 		INSIST(client->recursionquota == NULL);
 
@@ -2068,7 +2224,7 @@ client_newconn(isc_task_t *task, isc_event_t *event) {
 	} else {
 		/*
 		 * XXXRTH  What should we do?  We're trying to accept but
-		 *         it didn't work.  If we just give up, then TCP
+		 *	   it didn't work.  If we just give up, then TCP
 		 *	   service may eventually stop.
 		 *
 		 *	   For now, we just go idle.
@@ -2115,7 +2271,7 @@ client_newconn(isc_task_t *task, isc_event_t *event) {
 		 * Let a new client take our place immediately, before
 		 * we wait for a request packet.  If we don't,
 		 * telnetting to port 53 (once per CPU) will
-		 * deny service to legititmate TCP clients.
+		 * deny service to legitimate TCP clients.
 		 */
 		result = isc_quota_attach(&ns_g_server->tcpquota,
 					  &client->tcpquota);
@@ -2149,7 +2305,7 @@ client_accept(ns_client_t *client) {
 				 isc_result_totext(result));
 		/*
 		 * XXXRTH  What should we do?  We're trying to accept but
-		 *         it didn't work.  If we just give up, then TCP
+		 *	   it didn't work.  If we just give up, then TCP
 		 *	   service may eventually stop.
 		 *
 		 *	   For now, we just go idle.
@@ -2386,7 +2542,9 @@ ns_clientmgr_createclients(ns_clientmgr_t *manager, unsigned int n,
 		 * Allocate a client.  First try to get a recycled one;
 		 * if that fails, make a new one.
 		 */
-		client = ISC_LIST_HEAD(manager->inactive);
+		client = NULL;
+		if (!ns_g_clienttest)
+			client = ISC_LIST_HEAD(manager->inactive);
 		if (client != NULL) {
 			MTRACE("recycle");
 			ISC_LIST_UNLINK(manager->inactive, client, link);
@@ -2442,8 +2600,8 @@ ns_client_getsockaddr(ns_client_t *client) {
 }
 
 isc_result_t
-ns_client_checkaclsilent(ns_client_t *client, dns_acl_t *acl,
-			 isc_boolean_t default_allow)
+ns_client_checkaclsilent(ns_client_t *client, isc_sockaddr_t *sockaddr,
+			 dns_acl_t *acl, isc_boolean_t default_allow)
 {
 	isc_result_t result;
 	int match;
@@ -2456,11 +2614,16 @@ ns_client_checkaclsilent(ns_client_t *client, dns_acl_t *acl,
 			goto deny;
 	}
 
-	isc_netaddr_fromsockaddr(&netaddr, &client->peeraddr);
+
+	if (sockaddr == NULL)
+		isc_netaddr_fromsockaddr(&netaddr, &client->peeraddr);
+	else
+		isc_netaddr_fromsockaddr(&netaddr, sockaddr);
 
 	result = dns_acl_match(&netaddr, client->signer, acl,
 			       &ns_g_server->aclenv,
 			       &match, NULL);
+
 	if (result != ISC_R_SUCCESS)
 		goto deny; /* Internal error, already logged. */
 	if (match > 0)
@@ -2475,12 +2638,12 @@ ns_client_checkaclsilent(ns_client_t *client, dns_acl_t *acl,
 }
 
 isc_result_t
-ns_client_checkacl(ns_client_t *client,
+ns_client_checkacl(ns_client_t *client, isc_sockaddr_t *sockaddr,
 		   const char *opname, dns_acl_t *acl,
 		   isc_boolean_t default_allow, int log_level)
 {
 	isc_result_t result =
-		ns_client_checkaclsilent(client, acl, default_allow);
+		ns_client_checkaclsilent(client, sockaddr, acl, default_allow);
 
 	if (result == ISC_R_SUCCESS)
 		ns_client_log(client, DNS_LOGCATEGORY_SECURITY,
@@ -2503,7 +2666,7 @@ ns_client_name(ns_client_t *client, char *peerbuf, size_t len) {
 
 void
 ns_client_logv(ns_client_t *client, isc_logcategory_t *category,
-	   isc_logmodule_t *module, int level, const char *fmt, va_list ap)
+	       isc_logmodule_t *module, int level, const char *fmt, va_list ap)
 {
 	char msgbuf[2048];
 	char peerbuf[ISC_SOCKADDR_FORMATSIZE];
diff --git a/contrib/bind9/bin/named/config.c b/contrib/bind9/bin/named/config.c
index 233d9e0..8b96050 100644
--- a/contrib/bind9/bin/named/config.c
+++ b/contrib/bind9/bin/named/config.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: config.c,v 1.47.18.35 2008/09/04 08:03:07 marka Exp $ */
+/* $Id: config.c,v 1.93.14.2 2009/03/17 23:47:28 tbox Exp $ */
 
 /*! \file */
 
@@ -69,7 +69,7 @@ options {\n\
 	memstatistics-file \"named.memstats\";\n\
 	multiple-cnames no;\n\
 #	named-xfer <obsolete>;\n\
-#	pid-file \"" NS_LOCALSTATEDIR "/named.pid\"; /* or /lwresd.pid */\n\
+#	pid-file \"" NS_LOCALSTATEDIR "/run/named/named.pid\"; /* or /lwresd.pid */\n\
 	port 53;\n\
 	recursing-file \"named.recursing\";\n\
 "
@@ -99,13 +99,16 @@ options {\n\
 	use-ixfr true;\n\
 	edns-udp-size 4096;\n\
 	max-udp-size 4096;\n\
+	request-nsid false;\n\
 	reserved-sockets 512;\n\
 \n\
 	/* view */\n\
 	allow-notify {none;};\n\
 	allow-update-forwarding {none;};\n\
 	allow-query-cache { localnets; localhost; };\n\
+	allow-query-cache-on { any; };\n\
 	allow-recursion { localnets; localhost; };\n\
+	allow-recursion-on { any; };\n\
 #	allow-v6-synthesis <obsolete>;\n\
 #	sortlist <none>\n\
 #	topology <none>\n\
@@ -122,7 +125,7 @@ options {\n\
 	query-source-v6 address *;\n\
 	notify-source *;\n\
 	notify-source-v6 *;\n\
-	cleaning-interval 60;\n\
+	cleaning-interval 0;  /* now meaningless */\n\
 	min-roots 2;\n\
 	lame-ttl 600;\n\
 	max-ncache-ttl 10800; /* 3 hours */\n\
@@ -135,21 +138,24 @@ options {\n\
 	check-mx warn;\n\
 	acache-enable no;\n\
 	acache-cleaning-interval 60;\n\
-	max-acache-size 0;\n\
+	max-acache-size 16M;\n\
 	dnssec-enable yes;\n\
-	dnssec-validation no; /* Make yes for 9.5. */ \n\
+	dnssec-validation yes; \n\
 	dnssec-accept-expired no;\n\
 	clients-per-query 10;\n\
 	max-clients-per-query 100;\n\
 	zero-no-soa-ttl-cache no;\n\
+	nsec3-test-zone no;\n\
 "
 
 "	/* zone */\n\
 	allow-query {any;};\n\
+	allow-query-on {any;};\n\
 	allow-transfer {any;};\n\
 	notify yes;\n\
 #	also-notify <none>\n\
 	notify-delay 5;\n\
+	notify-to-soa no;\n\
 	dialup no;\n\
 #	forward <none>\n\
 #	forwarders <none>\n\
@@ -169,6 +175,9 @@ options {\n\
 	min-refresh-time 300;\n\
 	multi-master no;\n\
 	sig-validity-interval 30; /* days */\n\
+	sig-signing-nodes 100;\n\
+	sig-signing-signatures 10;\n\
+	sig-signing-type 65534;\n\
 	zone-statistics false;\n\
 	max-journal-size unlimited;\n\
 	ixfr-from-differences false;\n\
@@ -179,6 +188,7 @@ options {\n\
 	check-srv-cname warn;\n\
 	zero-no-soa-ttl yes;\n\
 	update-check-ksk yes;\n\
+	try-tcp-refresh yes; /* BIND 8 compat */\n\
 };\n\
 "
 
diff --git a/contrib/bind9/bin/named/control.c b/contrib/bind9/bin/named/control.c
index 3f2d52e..8bd8f6c 100644
--- a/contrib/bind9/bin/named/control.c
+++ b/contrib/bind9/bin/named/control.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: control.c,v 1.20.10.10 2007/09/13 23:46:26 tbox Exp $ */
+/* $Id: control.c,v 1.33 2007/09/13 04:45:18 each Exp $ */
 
 /*! \file */
 
@@ -63,6 +63,7 @@ ns_control_docommand(isccc_sexpr_t *message, isc_buffer_t *text) {
 	isccc_sexpr_t *data;
 	char *command;
 	isc_result_t result;
+	int log_level;
 #ifdef HAVE_LIBSCF
 	ns_smf_want_disable = 0;
 #endif
@@ -83,14 +84,20 @@ ns_control_docommand(isccc_sexpr_t *message, isc_buffer_t *text) {
 		return (result);
 	}
 
+	/*
+	 * Compare the 'command' parameter against all known control commands.
+	 */
+	if (command_compare(command, NS_COMMAND_NULL) ||
+	    command_compare(command, NS_COMMAND_STATUS)) {
+		log_level = ISC_LOG_DEBUG(1);
+	} else {
+		log_level = ISC_LOG_INFO;
+	}
 	isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
-		      NS_LOGMODULE_CONTROL, ISC_LOG_DEBUG(1),
+		      NS_LOGMODULE_CONTROL, log_level,
 		      "received control channel command '%s'",
 		      command);
 
-	/*
-	 * Compare the 'command' parameter against all known control commands.
-	 */
 	if (command_compare(command, NS_COMMAND_RELOAD)) {
 		result = ns_server_reloadcommand(ns_g_server, command, text);
 	} else if (command_compare(command, NS_COMMAND_RECONFIG)) {
@@ -158,6 +165,10 @@ ns_control_docommand(isccc_sexpr_t *message, isc_buffer_t *text) {
 		result = ns_server_flushname(ns_g_server, command);
 	} else if (command_compare(command, NS_COMMAND_STATUS)) {
 		result = ns_server_status(ns_g_server, text);
+	} else if (command_compare(command, NS_COMMAND_TSIGLIST)) {
+		result = ns_server_tsiglist(ns_g_server, text);
+	} else if (command_compare(command, NS_COMMAND_TSIGDELETE)) {
+		result = ns_server_tsigdelete(ns_g_server, command, text);
 	} else if (command_compare(command, NS_COMMAND_FREEZE)) {
 		result = ns_server_freeze(ns_g_server, ISC_TRUE, command);
 	} else if (command_compare(command, NS_COMMAND_UNFREEZE) ||
diff --git a/contrib/bind9/bin/named/controlconf.c b/contrib/bind9/bin/named/controlconf.c
index e8e36f3..766f013 100644
--- a/contrib/bind9/bin/named/controlconf.c
+++ b/contrib/bind9/bin/named/controlconf.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: controlconf.c,v 1.40.18.14 2008/07/23 23:33:02 marka Exp $ */
+/* $Id: controlconf.c,v 1.60 2008/07/23 23:27:54 marka Exp $ */
 
 /*! \file */
 
@@ -597,6 +597,7 @@ control_newconn(isc_task_t *task, isc_event_t *event) {
 	}
 
 	sock = nevent->newsocket;
+	isc_socket_setname(sock, "control", NULL);
 	(void)isc_socket_getpeername(sock, &peeraddr);
 	if (listener->type == isc_sockettype_tcp &&
 	    !address_ok(&peeraddr, listener->acl)) {
@@ -1007,7 +1008,7 @@ update_listener(ns_controls_t *cp, controllistener_t **listenerp,
 	if (control != NULL && type == isc_sockettype_tcp) {
 		allow = cfg_tuple_get(control, "allow");
 		result = cfg_acl_fromconfig(allow, config, ns_g_lctx,
-					    aclconfctx, listener->mctx,
+					    aclconfctx, listener->mctx, 0,
 					    &new_acl);
 	} else {
 		result = dns_acl_any(listener->mctx, &new_acl);
@@ -1094,7 +1095,8 @@ add_listener(ns_controls_t *cp, controllistener_t **listenerp,
 		if (control != NULL && type == isc_sockettype_tcp) {
 			allow = cfg_tuple_get(control, "allow");
 			result = cfg_acl_fromconfig(allow, config, ns_g_lctx,
-						    aclconfctx, mctx, &new_acl);
+						    aclconfctx, mctx, 0,
+						    &new_acl);
 		} else {
 			result = dns_acl_any(mctx, &new_acl);
 		}
@@ -1143,6 +1145,8 @@ add_listener(ns_controls_t *cp, controllistener_t **listenerp,
 		result = isc_socket_create(ns_g_socketmgr,
 					   isc_sockaddr_pf(&listener->address),
 					   type, &listener->sock);
+	if (result == ISC_R_SUCCESS)
+		isc_socket_setname(listener->sock, "control", NULL);
 
 	if (result == ISC_R_SUCCESS)
 		result = isc_socket_bind(listener->sock, &listener->address,
diff --git a/contrib/bind9/bin/named/convertxsl.pl b/contrib/bind9/bin/named/convertxsl.pl
new file mode 100755
index 0000000..87550b3
--- /dev/null
+++ b/contrib/bind9/bin/named/convertxsl.pl
@@ -0,0 +1,57 @@
+#!/usr/bin/env perl
+#
+# Copyright (C) 2006-2008  Internet Systems Consortium, Inc. ("ISC")
+#
+# Permission to use, copy, modify, and/or 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: convertxsl.pl,v 1.14 2008/07/17 23:43:26 jinmei Exp $
+
+use strict;
+use warnings;
+
+my $rev = '$Id: convertxsl.pl,v 1.14 2008/07/17 23:43:26 jinmei Exp $';
+$rev =~ s/\$//g;
+$rev =~ s/,v//g;
+$rev =~ s/Id: //;
+
+my $xsl = "unknown";
+my $lines = '';
+
+while (<>) {
+    chomp;
+    # pickout the id for comment.
+    $xsl = $_ if (/<!-- .Id:.* -->/);
+    # convert Id string to a form not recognisable by cvs.
+    $_ =~ s/<!-- .Id:(.*). -->/<!-- \\045Id: $1\\045 -->/;
+    s/[\ \t]+/ /g;
+    s/\>\ \</\>\</g;
+    s/\"/\\\"/g;
+    s/^/\t\"/;
+    s/$/\\n\"/;
+    if ($lines eq "") {
+	    $lines .= $_;
+    } else {
+	    $lines .= "\n" . $_;
+    }
+}
+
+$xsl =~ s/\$//g;
+$xsl =~ s/<!-- Id: //;
+$xsl =~ s/ -->.*//;
+$xsl =~ s/,v//;
+
+print "/*\n * Generated by $rev \n * From $xsl\n */\n";
+print 'static char xslmsg[] =',"\n";
+print $lines;
+
+print ';', "\n";
diff --git a/contrib/bind9/bin/named/include/named/builtin.h b/contrib/bind9/bin/named/include/named/builtin.h
index 37a3e76..a5185ba 100644
--- a/contrib/bind9/bin/named/include/named/builtin.h
+++ b/contrib/bind9/bin/named/include/named/builtin.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: builtin.h,v 1.2.18.2 2005/04/29 00:15:34 marka Exp $ */
+/* $Id: builtin.h,v 1.6 2007/06/19 23:46:59 tbox Exp $ */
 
 #ifndef NAMED_BUILTIN_H
 #define NAMED_BUILTIN_H 1
diff --git a/contrib/bind9/bin/named/include/named/client.h b/contrib/bind9/bin/named/include/named/client.h
index 0cf7985..3ebed3f 100644
--- a/contrib/bind9/bin/named/include/named/client.h
+++ b/contrib/bind9/bin/named/include/named/client.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: client.h,v 1.69.18.9 2006/06/06 00:11:41 marka Exp $ */
+/* $Id: client.h,v 1.86.120.2 2009/01/18 23:47:34 tbox Exp $ */
 
 #ifndef NAMED_CLIENT_H
 #define NAMED_CLIENT_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file 
+/*! \file
  * \brief
  * This module defines two objects, ns_client_t and ns_clientmgr_t.
  *
@@ -97,6 +97,13 @@ struct ns_client {
 	int			nupdates;
 	int			nctls;
 	int			references;
+	isc_boolean_t		needshutdown; 	/*
+						 * Used by clienttest to get
+						 * the client to go from
+						 * inactive to free state
+						 * by shutting down the
+						 * client's task.
+						 */
 	unsigned int		attributes;
 	isc_task_t *		task;
 	dns_view_t *		view;
@@ -155,10 +162,11 @@ struct ns_client {
 #define NS_CLIENT_VALID(c)		ISC_MAGIC_VALID(c, NS_CLIENT_MAGIC)
 
 #define NS_CLIENTATTR_TCP		0x01
-#define NS_CLIENTATTR_RA		0x02 /*%< Client gets recusive service */
+#define NS_CLIENTATTR_RA		0x02 /*%< Client gets recursive service */
 #define NS_CLIENTATTR_PKTINFO		0x04 /*%< pktinfo is valid */
 #define NS_CLIENTATTR_MULTICAST		0x08 /*%< recv'd from multicast */
 #define NS_CLIENTATTR_WANTDNSSEC	0x10 /*%< include dnssec records */
+#define NS_CLIENTATTR_WANTNSID          0x20 /*%< include nameserver ID */
 
 extern unsigned int ns_client_requests;
 
@@ -266,7 +274,9 @@ ns_client_getsockaddr(ns_client_t *client);
  */
 
 isc_result_t
-ns_client_checkaclsilent(ns_client_t  *client,dns_acl_t *acl,
+ns_client_checkaclsilent(ns_client_t *client,
+			 isc_sockaddr_t *sockaddr,
+			 dns_acl_t *acl,
 			 isc_boolean_t default_allow);
 
 /*%
@@ -274,6 +284,8 @@ ns_client_checkaclsilent(ns_client_t  *client,dns_acl_t *acl,
  *
  * Check the current client request against 'acl'.  If 'acl'
  * is NULL, allow the request iff 'default_allow' is ISC_TRUE.
+ * If netaddr is NULL, check the ACL against client->peeraddr;
+ * otherwise check it against netaddr.
  *
  * Notes:
  *\li	This is appropriate for checking allow-update,
@@ -284,6 +296,7 @@ ns_client_checkaclsilent(ns_client_t  *client,dns_acl_t *acl,
  *
  * Requires:
  *\li	'client' points to a valid client.
+ *\li	'sockaddr' points to a valid address, or is NULL.
  *\li	'acl' points to a valid ACL, or is NULL.
  *
  * Returns:
@@ -294,18 +307,19 @@ ns_client_checkaclsilent(ns_client_t  *client,dns_acl_t *acl,
 
 isc_result_t
 ns_client_checkacl(ns_client_t  *client,
+		   isc_sockaddr_t *sockaddr,
 		   const char *opname, dns_acl_t *acl,
 		   isc_boolean_t default_allow,
 		   int log_level);
 /*%
- * Like ns_client_checkacl, but also logs the outcome of the
- * check at log level 'log_level' if denied, and at debug 3
- * if approved.  Log messages will refer to the request as
- * an 'opname' request.
+ * Like ns_client_checkaclsilent, except the outcome of the check is
+ * logged at log level 'log_level' if denied, and at debug 3 if approved.
+ * Log messages will refer to the request as an 'opname' request.
  *
  * Requires:
- *\li	Those of ns_client_checkaclsilent(), and:
- *
+ *\li	'client' points to a valid client.
+ *\li	'sockaddr' points to a valid address, or is NULL.
+ *\li	'acl' points to a valid ACL, or is NULL.
  *\li	'opname' points to a null-terminated string.
  */
 
@@ -352,8 +366,8 @@ ns_client_qnamereplace(ns_client_t *client, dns_name_t *name);
 
 isc_boolean_t
 ns_client_isself(dns_view_t *myview, dns_tsigkey_t *mykey,
-                 isc_sockaddr_t *srcaddr, isc_sockaddr_t *destaddr,
-                 dns_rdataclass_t rdclass, void *arg);
+		 isc_sockaddr_t *srcaddr, isc_sockaddr_t *destaddr,
+		 dns_rdataclass_t rdclass, void *arg);
 /*%
  * Isself callback.
  */
diff --git a/contrib/bind9/bin/named/include/named/config.h b/contrib/bind9/bin/named/include/named/config.h
index e8e6038..f7ceed8 100644
--- a/contrib/bind9/bin/named/include/named/config.h
+++ b/contrib/bind9/bin/named/include/named/config.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001, 2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: config.h,v 1.6.18.6 2006/02/28 03:10:47 marka Exp $ */
+/* $Id: config.h,v 1.14 2007/06/19 23:46:59 tbox Exp $ */
 
 #ifndef NAMED_CONFIG_H
 #define NAMED_CONFIG_H 1
diff --git a/contrib/bind9/bin/named/include/named/control.h b/contrib/bind9/bin/named/include/named/control.h
index 5b7e5f4..d382ffe 100644
--- a/contrib/bind9/bin/named/include/named/control.h
+++ b/contrib/bind9/bin/named/include/named/control.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: control.h,v 1.14.18.8 2006/03/09 23:46:20 marka Exp $ */
+/* $Id: control.h,v 1.25 2007/06/19 23:46:59 tbox Exp $ */
 
 #ifndef NAMED_CONTROL_H
 #define NAMED_CONTROL_H 1
@@ -47,6 +47,8 @@
 #define NS_COMMAND_FLUSH	"flush"
 #define NS_COMMAND_FLUSHNAME	"flushname"
 #define NS_COMMAND_STATUS	"status"
+#define NS_COMMAND_TSIGLIST	"tsig-list"
+#define NS_COMMAND_TSIGDELETE	"tsig-delete"
 #define NS_COMMAND_FREEZE	"freeze"
 #define NS_COMMAND_UNFREEZE	"unfreeze"
 #define NS_COMMAND_THAW		"thaw"
diff --git a/contrib/bind9/bin/named/include/named/globals.h b/contrib/bind9/bin/named/include/named/globals.h
index 9c86afd..6040dc3 100644
--- a/contrib/bind9/bin/named/include/named/globals.h
+++ b/contrib/bind9/bin/named/include/named/globals.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: globals.h,v 1.64.18.6 2008/10/24 01:43:17 tbox Exp $ */
+/* $Id: globals.h,v 1.80 2008/11/16 22:49:18 marka Exp $ */
 
 #ifndef NAMED_GLOBALS_H
 #define NAMED_GLOBALS_H 1
@@ -42,6 +42,10 @@
 #define INIT(v)
 #endif
 
+#ifndef NS_RUN_PID_DIR
+#define NS_RUN_PID_DIR 1
+#endif
+
 EXTERN isc_mem_t *		ns_g_mctx		INIT(NULL);
 EXTERN unsigned int		ns_g_cpus		INIT(0);
 EXTERN isc_taskmgr_t *		ns_g_taskmgr		INIT(NULL);
@@ -59,6 +63,7 @@ EXTERN isc_timermgr_t *		ns_g_timermgr		INIT(NULL);
 EXTERN isc_socketmgr_t *	ns_g_socketmgr		INIT(NULL);
 EXTERN cfg_parser_t *		ns_g_parser		INIT(NULL);
 EXTERN const char *		ns_g_version		INIT(VERSION);
+EXTERN const char *		ns_g_configargs		INIT(CONFIGARGS);
 EXTERN in_port_t		ns_g_port		INIT(0);
 EXTERN in_port_t		lwresd_g_listenport	INIT(0);
 
@@ -107,13 +112,26 @@ EXTERN const char *		ns_g_chrootdir		INIT(NULL);
 EXTERN isc_boolean_t		ns_g_foreground		INIT(ISC_FALSE);
 EXTERN isc_boolean_t		ns_g_logstderr		INIT(ISC_FALSE);
 
+#if NS_RUN_PID_DIR
+EXTERN const char *		ns_g_defaultpidfile 	INIT(NS_LOCALSTATEDIR
+							     "/run/named/"
+							     "named.pid");
+EXTERN const char *		lwresd_g_defaultpidfile INIT(NS_LOCALSTATEDIR
+							     "/run/lwresd/"
+							     "lwresd.pid");
+#else
 EXTERN const char *		ns_g_defaultpidfile 	INIT(NS_LOCALSTATEDIR
 							     "/run/named.pid");
 EXTERN const char *		lwresd_g_defaultpidfile INIT(NS_LOCALSTATEDIR
-							    "/run/lwresd.pid");
+							     "/run/lwresd.pid");
+#endif
+
 EXTERN const char *		ns_g_username		INIT(NULL);
 
 EXTERN int			ns_g_listen		INIT(3);
+EXTERN isc_time_t		ns_g_boottime;
+EXTERN isc_boolean_t		ns_g_memstatistics	INIT(ISC_FALSE);
+EXTERN isc_boolean_t		ns_g_clienttest		INIT(ISC_FALSE);
 
 #undef EXTERN
 #undef INIT
diff --git a/contrib/bind9/bin/named/include/named/interfacemgr.h b/contrib/bind9/bin/named/include/named/interfacemgr.h
index 42279ff..2724c39 100644
--- a/contrib/bind9/bin/named/include/named/interfacemgr.h
+++ b/contrib/bind9/bin/named/include/named/interfacemgr.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: interfacemgr.h,v 1.26.18.4 2005/04/27 05:00:35 sra Exp $ */
+/* $Id: interfacemgr.h,v 1.33 2007/06/19 23:46:59 tbox Exp $ */
 
 #ifndef NAMED_INTERFACEMGR_H
 #define NAMED_INTERFACEMGR_H 1
diff --git a/contrib/bind9/bin/named/include/named/listenlist.h b/contrib/bind9/bin/named/include/named/listenlist.h
index cdca026..9e65d5d 100644
--- a/contrib/bind9/bin/named/include/named/listenlist.h
+++ b/contrib/bind9/bin/named/include/named/listenlist.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: listenlist.h,v 1.11.18.2 2005/04/29 00:15:34 marka Exp $ */
+/* $Id: listenlist.h,v 1.15 2007/06/19 23:46:59 tbox Exp $ */
 
 #ifndef NAMED_LISTENLIST_H
 #define NAMED_LISTENLIST_H 1
diff --git a/contrib/bind9/bin/named/include/named/log.h b/contrib/bind9/bin/named/include/named/log.h
index 6d6e648..444fe50 100644
--- a/contrib/bind9/bin/named/include/named/log.h
+++ b/contrib/bind9/bin/named/include/named/log.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: log.h,v 1.21.18.2 2005/04/29 00:15:35 marka Exp $ */
+/* $Id: log.h,v 1.25.332.2 2009/01/07 23:47:16 tbox Exp $ */
 
 #ifndef NAMED_LOG_H
 #define NAMED_LOG_H 1
@@ -36,6 +36,7 @@
 #define NS_LOGCATEGORY_QUERIES		(&ns_g_categories[4])
 #define NS_LOGCATEGORY_UNMATCHED	(&ns_g_categories[5])
 #define NS_LOGCATEGORY_UPDATE_SECURITY	(&ns_g_categories[6])
+#define NS_LOGCATEGORY_QUERY_EERRORS	(&ns_g_categories[7])
 
 /*
  * Backwards compatibility.
diff --git a/contrib/bind9/bin/named/include/named/logconf.h b/contrib/bind9/bin/named/include/named/logconf.h
index 79df5c6..0354345 100644
--- a/contrib/bind9/bin/named/include/named/logconf.h
+++ b/contrib/bind9/bin/named/include/named/logconf.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: logconf.h,v 1.11.18.4 2006/03/02 00:37:21 marka Exp $ */
+/* $Id: logconf.h,v 1.17 2007/06/19 23:46:59 tbox Exp $ */
 
 #ifndef NAMED_LOGCONF_H
 #define NAMED_LOGCONF_H 1
diff --git a/contrib/bind9/bin/named/include/named/lwaddr.h b/contrib/bind9/bin/named/include/named/lwaddr.h
index 552d1d4..962aa91 100644
--- a/contrib/bind9/bin/named/include/named/lwaddr.h
+++ b/contrib/bind9/bin/named/include/named/lwaddr.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lwaddr.h,v 1.4.18.2 2005/04/29 00:15:35 marka Exp $ */
+/* $Id: lwaddr.h,v 1.8 2007/06/19 23:46:59 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/bin/named/include/named/lwdclient.h b/contrib/bind9/bin/named/include/named/lwdclient.h
index 591b86c..f0ab057 100644
--- a/contrib/bind9/bin/named/include/named/lwdclient.h
+++ b/contrib/bind9/bin/named/include/named/lwdclient.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lwdclient.h,v 1.14.18.2 2005/04/29 00:15:36 marka Exp $ */
+/* $Id: lwdclient.h,v 1.18.332.2 2009/01/18 23:47:34 tbox Exp $ */
 
 #ifndef NAMED_LWDCLIENT_H
 #define NAMED_LWDCLIENT_H 1
@@ -39,7 +39,7 @@
 
 #define LWRD_SHUTDOWN		(LWRD_EVENTCLASS + 0x0001)
 
-/*% Lighweight Resolver Daemon Client */
+/*% Lightweight Resolver Daemon Client */
 struct ns_lwdclient {
 	isc_sockaddr_t		address;	/*%< where to reply */
 	struct in6_pktinfo	pktinfo;
diff --git a/contrib/bind9/bin/named/include/named/lwresd.h b/contrib/bind9/bin/named/include/named/lwresd.h
index ef93fcd..565e58d 100644
--- a/contrib/bind9/bin/named/include/named/lwresd.h
+++ b/contrib/bind9/bin/named/include/named/lwresd.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lwresd.h,v 1.13.18.4 2006/03/02 00:37:21 marka Exp $ */
+/* $Id: lwresd.h,v 1.19 2007/06/19 23:46:59 tbox Exp $ */
 
 #ifndef NAMED_LWRESD_H
 #define NAMED_LWRESD_H 1
diff --git a/contrib/bind9/bin/named/include/named/lwsearch.h b/contrib/bind9/bin/named/include/named/lwsearch.h
index b85e401..c1b4f48 100644
--- a/contrib/bind9/bin/named/include/named/lwsearch.h
+++ b/contrib/bind9/bin/named/include/named/lwsearch.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lwsearch.h,v 1.5.18.2 2005/04/29 00:15:36 marka Exp $ */
+/* $Id: lwsearch.h,v 1.9 2007/06/19 23:46:59 tbox Exp $ */
 
 #ifndef NAMED_LWSEARCH_H
 #define NAMED_LWSEARCH_H 1
diff --git a/contrib/bind9/bin/named/include/named/main.h b/contrib/bind9/bin/named/include/named/main.h
index dd4fe8c..e834539 100644
--- a/contrib/bind9/bin/named/include/named/main.h
+++ b/contrib/bind9/bin/named/include/named/main.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: main.h,v 1.11.18.2 2005/04/29 00:15:37 marka Exp $ */
+/* $Id: main.h,v 1.15 2007/06/19 23:46:59 tbox Exp $ */
 
 #ifndef NAMED_MAIN_H
 #define NAMED_MAIN_H 1
diff --git a/contrib/bind9/bin/named/include/named/notify.h b/contrib/bind9/bin/named/include/named/notify.h
index 106d70c..e8df0a1 100644
--- a/contrib/bind9/bin/named/include/named/notify.h
+++ b/contrib/bind9/bin/named/include/named/notify.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: notify.h,v 1.10.18.2 2005/04/29 00:15:37 marka Exp $ */
+/* $Id: notify.h,v 1.14.332.2 2009/01/18 23:47:34 tbox Exp $ */
 
 #ifndef NAMED_NOTIFY_H
 #define NAMED_NOTIFY_H 1
@@ -41,7 +41,7 @@ void
 ns_notify_start(ns_client_t *client);
 
 /*%<
- *	Examines the incoming message to determine apporiate zone.
+ *	Examines the incoming message to determine appropriate zone.
  *	Returns FORMERR if there is not exactly one question.
  *	Returns REFUSED if we do not serve the listed zone.
  *	Pass the message to the zone module for processing
diff --git a/contrib/bind9/bin/named/include/named/ns_smf_globals.h b/contrib/bind9/bin/named/include/named/ns_smf_globals.h
index 06df2ba..3a35743 100644
--- a/contrib/bind9/bin/named/include/named/ns_smf_globals.h
+++ b/contrib/bind9/bin/named/include/named/ns_smf_globals.h
@@ -1,7 +1,7 @@
 /*
- * Copyright (C) 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ns_smf_globals.h,v 1.2.2.4 2005/05/13 01:32:46 marka Exp $ */
+/* $Id: ns_smf_globals.h,v 1.7 2007/06/19 23:46:59 tbox Exp $ */
 
 #ifndef NS_SMF_GLOBALS_H
 #define NS_SMF_GLOBALS_H 1
diff --git a/contrib/bind9/bin/named/include/named/query.h b/contrib/bind9/bin/named/include/named/query.h
index 741212f..500b577 100644
--- a/contrib/bind9/bin/named/include/named/query.h
+++ b/contrib/bind9/bin/named/include/named/query.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: query.h,v 1.36.18.2 2005/04/29 00:15:37 marka Exp $ */
+/* $Id: query.h,v 1.40 2007/06/19 23:46:59 tbox Exp $ */
 
 #ifndef NAMED_QUERY_H
 #define NAMED_QUERY_H 1
diff --git a/contrib/bind9/bin/named/include/named/server.h b/contrib/bind9/bin/named/include/named/server.h
index 54d1dae..43eccc4 100644
--- a/contrib/bind9/bin/named/include/named/server.h
+++ b/contrib/bind9/bin/named/include/named/server.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: server.h,v 1.73.18.8 2006/03/09 23:46:20 marka Exp $ */
+/* $Id: server.h,v 1.93.120.2 2009/01/29 23:47:44 tbox Exp $ */
 
 #ifndef NAMED_SERVER_H
 #define NAMED_SERVER_H 1
@@ -23,13 +23,14 @@
 /*! \file */
 
 #include <isc/log.h>
-#include <isc/sockaddr.h>
 #include <isc/magic.h>
-#include <isc/types.h>
 #include <isc/quota.h>
+#include <isc/sockaddr.h>
+#include <isc/types.h>
+#include <isc/xml.h>
 
-#include <dns/types.h>
 #include <dns/acl.h>
+#include <dns/types.h>
 
 #include <named/types.h>
 
@@ -62,7 +63,7 @@ struct ns_server {
 	isc_boolean_t		server_usehostname;
 	char *			server_id;	/*%< User-specified server id */
 
-        /*%
+	/*%
 	 * Current ACL environment.  This defines the
 	 * current values of the localhost and localnets
 	 * ACLs.
@@ -90,18 +91,74 @@ struct ns_server {
 	isc_boolean_t		flushonshutdown;
 	isc_boolean_t		log_queries;	/*%< For BIND 8 compatibility */
 
-	isc_uint64_t *		querystats;	/*%< Query statistics counters */
+	isc_stats_t *		nsstats;	/*%< Server statistics */
+	dns_stats_t *		rcvquerystats;	/*% Incoming query statistics */
+	dns_stats_t *		opcodestats;	/*%< Incoming message statistics */
+	isc_stats_t *		zonestats;	/*% Zone management statistics */
+	isc_stats_t *		resolverstats;	/*% Resolver statistics */
 
+	isc_stats_t *		sockstats;	/*%< Socket statistics */
 	ns_controls_t *		controls;	/*%< Control channels */
 	unsigned int		dispatchgen;
 	ns_dispatchlist_t	dispatches;
 
 	dns_acache_t		*acache;
+
+	ns_statschannellist_t	statschannels;
 };
 
 #define NS_SERVER_MAGIC			ISC_MAGIC('S','V','E','R')
 #define NS_SERVER_VALID(s)		ISC_MAGIC_VALID(s, NS_SERVER_MAGIC)
 
+/*%
+ * Server statistics counters.  Used as isc_statscounter_t values.
+ */
+enum {
+	dns_nsstatscounter_requestv4 = 0,
+	dns_nsstatscounter_requestv6 = 1,
+	dns_nsstatscounter_edns0in = 2,
+	dns_nsstatscounter_badednsver = 3,
+	dns_nsstatscounter_tsigin = 4,
+	dns_nsstatscounter_sig0in = 5,
+	dns_nsstatscounter_invalidsig = 6,
+	dns_nsstatscounter_tcp = 7,
+
+	dns_nsstatscounter_authrej = 8,
+	dns_nsstatscounter_recurserej = 9,
+	dns_nsstatscounter_xfrrej = 10,
+	dns_nsstatscounter_updaterej = 11,
+
+	dns_nsstatscounter_response = 12,
+	dns_nsstatscounter_truncatedresp = 13,
+	dns_nsstatscounter_edns0out = 14,
+	dns_nsstatscounter_tsigout = 15,
+	dns_nsstatscounter_sig0out = 16,
+
+	dns_nsstatscounter_success = 17,
+	dns_nsstatscounter_authans = 18,
+	dns_nsstatscounter_nonauthans = 19,
+	dns_nsstatscounter_referral = 20,
+	dns_nsstatscounter_nxrrset = 21,
+	dns_nsstatscounter_servfail = 22,
+	dns_nsstatscounter_formerr = 23,
+	dns_nsstatscounter_nxdomain = 24,
+	dns_nsstatscounter_recursion = 25,
+	dns_nsstatscounter_duplicate = 26,
+	dns_nsstatscounter_dropped = 27,
+	dns_nsstatscounter_failure = 28,
+
+	dns_nsstatscounter_xfrdone = 29,
+
+	dns_nsstatscounter_updatereqfwd = 30,
+	dns_nsstatscounter_updaterespfwd = 31,
+	dns_nsstatscounter_updatefwdfail = 32,
+	dns_nsstatscounter_updatedone = 33,
+	dns_nsstatscounter_updatefail = 34,
+	dns_nsstatscounter_updatebadprereq = 35,
+
+	dns_nsstatscounter_max = 36
+};
+
 void
 ns_server_create(isc_mem_t *mctx, ns_server_t **serverp);
 /*%<
@@ -204,6 +261,18 @@ isc_result_t
 ns_server_status(ns_server_t *server, isc_buffer_t *text);
 
 /*%
+ * Report a list of dynamic and static tsig keys, per view.
+ */
+isc_result_t
+ns_server_tsiglist(ns_server_t *server, isc_buffer_t *text);
+
+/*%
+ * Delete a specific key (with optional view).
+ */
+isc_result_t
+ns_server_tsigdelete(ns_server_t *server, char *command, isc_buffer_t *text);
+
+/*%
  * Enable or disable updates for a zone.
  */
 isc_result_t
diff --git a/contrib/bind9/bin/named/include/named/sortlist.h b/contrib/bind9/bin/named/include/named/sortlist.h
index f849be2..b9f6076 100644
--- a/contrib/bind9/bin/named/include/named/sortlist.h
+++ b/contrib/bind9/bin/named/include/named/sortlist.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: sortlist.h,v 1.5.18.4 2006/03/02 00:37:21 marka Exp $ */
+/* $Id: sortlist.h,v 1.11 2007/06/19 23:46:59 tbox Exp $ */
 
 #ifndef NAMED_SORTLIST_H
 #define NAMED_SORTLIST_H 1
diff --git a/contrib/bind9/bin/named/include/named/statschannel.h b/contrib/bind9/bin/named/include/named/statschannel.h
new file mode 100644
index 0000000..0c36d8c
--- /dev/null
+++ b/contrib/bind9/bin/named/include/named/statschannel.h
@@ -0,0 +1,61 @@
+/*
+ * Copyright (C) 2008  Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or 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: statschannel.h,v 1.3 2008/04/03 05:55:51 marka Exp $ */
+
+#ifndef NAMED_STATSCHANNEL_H
+#define NAMED_STATSCHANNEL_H 1
+
+/*! \file
+ * \brief
+ * The statistics channels built-in the name server.
+ */
+
+#include <isccc/types.h>
+
+#include <isccfg/aclconf.h>
+
+#include <named/types.h>
+
+#define NS_STATSCHANNEL_HTTPPORT		80
+
+isc_result_t
+ns_statschannels_configure(ns_server_t *server, const cfg_obj_t *config,
+			   cfg_aclconfctx_t *aclconfctx);
+/*%<
+ * [Re]configure the statistics channels.
+ *
+ * If it is no longer there but was previously configured, destroy
+ * it here.
+ *
+ * If the IP address or port has changed, destroy the old server
+ * and create a new one.
+ */
+
+
+void
+ns_statschannels_shutdown(ns_server_t *server);
+/*%<
+ * Initiate shutdown of all the statistics channel listeners.
+ */
+
+isc_result_t
+ns_stats_dump(ns_server_t *server, FILE *fp);
+/*%<
+ * Dump statistics counters managed by the server to the file fp.
+ */
+
+#endif	/* NAMED_STATSCHANNEL_H */
diff --git a/contrib/bind9/bin/named/include/named/tkeyconf.h b/contrib/bind9/bin/named/include/named/tkeyconf.h
index 946944d..02bd718 100644
--- a/contrib/bind9/bin/named/include/named/tkeyconf.h
+++ b/contrib/bind9/bin/named/include/named/tkeyconf.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: tkeyconf.h,v 1.10.18.4 2006/03/02 00:37:21 marka Exp $ */
+/* $Id: tkeyconf.h,v 1.16 2007/06/19 23:46:59 tbox Exp $ */
 
 #ifndef NS_TKEYCONF_H
 #define NS_TKEYCONF_H 1
diff --git a/contrib/bind9/bin/named/include/named/tsigconf.h b/contrib/bind9/bin/named/include/named/tsigconf.h
index a18eede..49ad82a 100644
--- a/contrib/bind9/bin/named/include/named/tsigconf.h
+++ b/contrib/bind9/bin/named/include/named/tsigconf.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: tsigconf.h,v 1.10.18.4 2006/03/02 00:37:21 marka Exp $ */
+/* $Id: tsigconf.h,v 1.16 2007/06/19 23:46:59 tbox Exp $ */
 
 #ifndef NS_TSIGCONF_H
 #define NS_TSIGCONF_H 1
diff --git a/contrib/bind9/bin/named/include/named/types.h b/contrib/bind9/bin/named/include/named/types.h
index abc25d5..eb25520 100644
--- a/contrib/bind9/bin/named/include/named/types.h
+++ b/contrib/bind9/bin/named/include/named/types.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: types.h,v 1.21.18.2 2005/04/29 00:15:38 marka Exp $ */
+/* $Id: types.h,v 1.29 2008/01/17 23:46:59 tbox Exp $ */
 
 #ifndef NAMED_TYPES_H
 #define NAMED_TYPES_H 1
@@ -28,6 +28,8 @@ typedef struct ns_client		ns_client_t;
 typedef struct ns_clientmgr		ns_clientmgr_t;
 typedef struct ns_query			ns_query_t;
 typedef struct ns_server 		ns_server_t;
+typedef struct ns_xmld			ns_xmld_t;
+typedef struct ns_xmldmgr		ns_xmldmgr_t;
 typedef struct ns_interface 		ns_interface_t;
 typedef struct ns_interfacemgr		ns_interfacemgr_t;
 typedef struct ns_lwresd		ns_lwresd_t;
@@ -39,5 +41,6 @@ typedef struct ns_lwsearchctx		ns_lwsearchctx_t;
 typedef struct ns_controls		ns_controls_t;
 typedef struct ns_dispatch		ns_dispatch_t;
 typedef ISC_LIST(ns_dispatch_t)		ns_dispatchlist_t;
-
+typedef struct ns_statschannel		ns_statschannel_t;
+typedef ISC_LIST(ns_statschannel_t)	ns_statschannellist_t;
 #endif /* NAMED_TYPES_H */
diff --git a/contrib/bind9/bin/named/include/named/update.h b/contrib/bind9/bin/named/include/named/update.h
index 37daa95..a34570c 100644
--- a/contrib/bind9/bin/named/include/named/update.h
+++ b/contrib/bind9/bin/named/include/named/update.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: update.h,v 1.9.18.2 2005/04/29 00:15:39 marka Exp $ */
+/* $Id: update.h,v 1.13 2007/06/19 23:46:59 tbox Exp $ */
 
 #ifndef NAMED_UPDATE_H
 #define NAMED_UPDATE_H 1
diff --git a/contrib/bind9/bin/named/include/named/xfrout.h b/contrib/bind9/bin/named/include/named/xfrout.h
index 82e0e66..4bb79a3 100644
--- a/contrib/bind9/bin/named/include/named/xfrout.h
+++ b/contrib/bind9/bin/named/include/named/xfrout.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: xfrout.h,v 1.8.18.2 2005/04/29 00:15:39 marka Exp $ */
+/* $Id: xfrout.h,v 1.12 2007/06/19 23:46:59 tbox Exp $ */
 
 #ifndef NAMED_XFROUT_H
 #define NAMED_XFROUT_H 1
diff --git a/contrib/bind9/bin/named/include/named/zoneconf.h b/contrib/bind9/bin/named/include/named/zoneconf.h
index 61737a2..b973013 100644
--- a/contrib/bind9/bin/named/include/named/zoneconf.h
+++ b/contrib/bind9/bin/named/include/named/zoneconf.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: zoneconf.h,v 1.19.18.5 2006/03/02 00:37:21 marka Exp $ */
+/* $Id: zoneconf.h,v 1.26 2007/06/19 23:46:59 tbox Exp $ */
 
 #ifndef NS_ZONECONF_H
 #define NS_ZONECONF_H 1
diff --git a/contrib/bind9/bin/named/interfacemgr.c b/contrib/bind9/bin/named/interfacemgr.c
index 08d33d9..46eb96e 100644
--- a/contrib/bind9/bin/named/interfacemgr.c
+++ b/contrib/bind9/bin/named/interfacemgr.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: interfacemgr.c,v 1.76.18.11 2008/07/23 23:33:02 marka Exp $ */
+/* $Id: interfacemgr.c,v 1.93.70.2 2009/01/18 23:47:34 tbox Exp $ */
 
 /*! \file */
 
@@ -304,6 +304,7 @@ ns_interface_accepttcp(ns_interface_t *ifp) {
 				 isc_result_totext(result));
 		goto tcp_socket_failure;
 	}
+	isc_socket_setname(ifp->tcpsocket, "dispatcher", NULL);
 #ifndef ISC_ALLOW_MAPPED
 	isc_socket_ipv6only(ifp->tcpsocket, ISC_TRUE);
 #endif
@@ -483,7 +484,7 @@ static isc_result_t
 clearacl(isc_mem_t *mctx, dns_acl_t **aclp) {
 	dns_acl_t *newacl = NULL;
 	isc_result_t result;
-	result = dns_acl_create(mctx, 10, &newacl);
+	result = dns_acl_create(mctx, 0, &newacl);
 	if (result != ISC_R_SUCCESS)
 		return (result);
 	dns_acl_detach(aclp);
@@ -494,36 +495,31 @@ clearacl(isc_mem_t *mctx, dns_acl_t **aclp) {
 
 static isc_boolean_t
 listenon_is_ip6_any(ns_listenelt_t *elt) {
-	if (elt->acl->length != 1)
-		return (ISC_FALSE);
-	if (elt->acl->elements[0].negative == ISC_FALSE &&
-	    elt->acl->elements[0].type == dns_aclelementtype_any)
-		return (ISC_TRUE);  /* listen-on-v6 { any; } */
-	return (ISC_FALSE); /* All others */
+	REQUIRE(elt && elt->acl);
+	return dns_acl_isany(elt->acl);
 }
 
 static isc_result_t
 setup_locals(ns_interfacemgr_t *mgr, isc_interface_t *interface) {
 	isc_result_t result;
-	dns_aclelement_t elt;
-	unsigned int family;
 	unsigned int prefixlen;
+	isc_netaddr_t *netaddr;
 
-	family = interface->address.family;
+	netaddr = &interface->address;
 
-	elt.type = dns_aclelementtype_ipprefix;
-	elt.negative = ISC_FALSE;
-	elt.u.ip_prefix.address = interface->address;
-	elt.u.ip_prefix.prefixlen = (family == AF_INET) ? 32 : 128;
-	result = dns_acl_appendelement(mgr->aclenv.localhost, &elt);
+	/* First add localhost address */
+	prefixlen = (netaddr->family == AF_INET) ? 32 : 128;
+	result = dns_iptable_addprefix(mgr->aclenv.localhost->iptable,
+				       netaddr, prefixlen, ISC_TRUE);
 	if (result != ISC_R_SUCCESS)
 		return (result);
 
+	/* Then add localnets prefix */
 	result = isc_netaddr_masktoprefixlen(&interface->netmask,
 					     &prefixlen);
 
-	/* Non contigious netmasks not allowed by IPv6 arch. */
-	if (result != ISC_R_SUCCESS && family == AF_INET6)
+	/* Non contiguous netmasks not allowed by IPv6 arch. */
+	if (result != ISC_R_SUCCESS && netaddr->family == AF_INET6)
 		return (result);
 
 	if (result != ISC_R_SUCCESS) {
@@ -533,17 +529,14 @@ setup_locals(ns_interfacemgr_t *mgr, isc_interface_t *interface) {
 			      "localnets ACL: %s",
 			      interface->name,
 			      isc_result_totext(result));
-	} else {
-		elt.u.ip_prefix.prefixlen = prefixlen;
-		if (dns_acl_elementmatch(mgr->aclenv.localnets, &elt,
-					 NULL) == ISC_R_NOTFOUND) {
-			result = dns_acl_appendelement(mgr->aclenv.localnets,
-						       &elt);
-			if (result != ISC_R_SUCCESS)
-				return (result);
-		}
+		return (ISC_R_SUCCESS);
 	}
 
+	result = dns_iptable_addprefix(mgr->aclenv.localnets->iptable,
+				       netaddr, prefixlen, ISC_TRUE);
+	if (result != ISC_R_SUCCESS)
+		return (result);
+
 	return (ISC_R_SUCCESS);
 }
 
@@ -803,7 +796,9 @@ do_scan(ns_interfacemgr_t *mgr, ns_listenlist_t *ext_listen,
 					(void)dns_acl_match(&listen_netaddr,
 							    NULL, ele->acl,
 							    NULL, &match, NULL);
-					if (match > 0 && ele->port == le->port)
+					if (match > 0 &&
+					    (ele->port == le->port ||
+					    ele->port == 0))
 						break;
 					else
 						match = 0;
diff --git a/contrib/bind9/bin/named/listenlist.c b/contrib/bind9/bin/named/listenlist.c
index 7e70ac9..513fe9c 100644
--- a/contrib/bind9/bin/named/listenlist.c
+++ b/contrib/bind9/bin/named/listenlist.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: listenlist.c,v 1.10.18.2 2005/04/29 00:15:22 marka Exp $ */
+/* $Id: listenlist.c,v 1.14 2007/06/19 23:46:59 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/bin/named/log.c b/contrib/bind9/bin/named/log.c
index af75bab..359ab9f 100644
--- a/contrib/bind9/bin/named/log.c
+++ b/contrib/bind9/bin/named/log.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: log.c,v 1.37.18.6 2006/06/09 00:54:08 marka Exp $ */
+/* $Id: log.c,v 1.46.334.3 2009/01/07 01:50:14 jinmei Exp $ */
 
 /*! \file */
 
@@ -33,7 +33,7 @@
 
 /*%
  * When adding a new category, be sure to add the appropriate
- * #define to <named/log.h> and to update the list in
+ * \#define to <named/log.h> and to update the list in
  * bin/check/check-tool.c.
  */
 static isc_logcategory_t categories[] = {
@@ -44,12 +44,13 @@ static isc_logcategory_t categories[] = {
 	{ "queries",	 		0 },
 	{ "unmatched",	 		0 },
 	{ "update-security",		0 },
+	{ "query-errors",		0 },
 	{ NULL, 			0 }
 };
 
 /*%
  * When adding a new module, be sure to add the appropriate
- * #define to <dns/log.h>.
+ * \#define to <dns/log.h>.
  */
 static isc_logmodule_t modules[] = {
 	{ "main",	 		0 },
@@ -120,7 +121,7 @@ ns_log_setdefaultchannels(isc_logconfig_t *lcfg) {
 	/*
 	 * By default, the logging library makes "default_debug" log to
 	 * stderr.  In BIND, we want to override this and log to named.run
-	 * instead, unless the the -g option was given.
+	 * instead, unless the -g option was given.
 	 */
 	if (! ns_g_logstderr) {
 		destination.file.stream = NULL;
diff --git a/contrib/bind9/bin/named/logconf.c b/contrib/bind9/bin/named/logconf.c
index ce815f4..e324965 100644
--- a/contrib/bind9/bin/named/logconf.c
+++ b/contrib/bind9/bin/named/logconf.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: logconf.c,v 1.35.18.5 2006/03/02 00:37:21 marka Exp $ */
+/* $Id: logconf.c,v 1.42 2007/06/19 23:46:59 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/bin/named/lwaddr.c b/contrib/bind9/bin/named/lwaddr.c
index 02e8f4d..ed7880a 100644
--- a/contrib/bind9/bin/named/lwaddr.c
+++ b/contrib/bind9/bin/named/lwaddr.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lwaddr.c,v 1.4.18.4 2008/01/11 23:45:59 tbox Exp $ */
+/* $Id: lwaddr.c,v 1.10 2008/01/11 23:46:56 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/bin/named/lwdclient.c b/contrib/bind9/bin/named/lwdclient.c
index 68069ed..a843134 100644
--- a/contrib/bind9/bin/named/lwdclient.c
+++ b/contrib/bind9/bin/named/lwdclient.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lwdclient.c,v 1.17.18.2 2005/04/29 00:15:23 marka Exp $ */
+/* $Id: lwdclient.c,v 1.22 2007/06/18 23:47:18 tbox Exp $ */
 
 /*! \file */
 
@@ -102,6 +102,7 @@ ns_lwdclientmgr_create(ns_lwreslistener_t *listener, unsigned int nclients,
 	result = isc_task_create(taskmgr, 0, &cm->task);
 	if (result != ISC_R_SUCCESS)
 		goto errout;
+	isc_task_setname(cm->task, "lwdclient", NULL);
 
 	/*
 	 * This MUST be last, since there is no way to cancel an onshutdown...
diff --git a/contrib/bind9/bin/named/lwderror.c b/contrib/bind9/bin/named/lwderror.c
index db25824..33f247a 100644
--- a/contrib/bind9/bin/named/lwderror.c
+++ b/contrib/bind9/bin/named/lwderror.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lwderror.c,v 1.8.18.2 2005/04/29 00:15:24 marka Exp $ */
+/* $Id: lwderror.c,v 1.12 2007/06/19 23:46:59 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/bin/named/lwdgabn.c b/contrib/bind9/bin/named/lwdgabn.c
index 454d4df..dec1e1a 100644
--- a/contrib/bind9/bin/named/lwdgabn.c
+++ b/contrib/bind9/bin/named/lwdgabn.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lwdgabn.c,v 1.15.18.5 2006/03/02 00:37:21 marka Exp $ */
+/* $Id: lwdgabn.c,v 1.22 2007/06/19 23:46:59 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/bin/named/lwdgnba.c b/contrib/bind9/bin/named/lwdgnba.c
index a54d443..dfc2ad6 100644
--- a/contrib/bind9/bin/named/lwdgnba.c
+++ b/contrib/bind9/bin/named/lwdgnba.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lwdgnba.c,v 1.16.18.4 2008/01/14 23:45:59 tbox Exp $ */
+/* $Id: lwdgnba.c,v 1.22 2008/01/14 23:46:56 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/bin/named/lwdgrbn.c b/contrib/bind9/bin/named/lwdgrbn.c
index c1b2b1e..b54e83d 100644
--- a/contrib/bind9/bin/named/lwdgrbn.c
+++ b/contrib/bind9/bin/named/lwdgrbn.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lwdgrbn.c,v 1.13.18.5 2006/12/07 23:57:58 marka Exp $ */
+/* $Id: lwdgrbn.c,v 1.20 2007/06/19 23:46:59 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/bin/named/lwdnoop.c b/contrib/bind9/bin/named/lwdnoop.c
index 69cc957..14d8e0c 100644
--- a/contrib/bind9/bin/named/lwdnoop.c
+++ b/contrib/bind9/bin/named/lwdnoop.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lwdnoop.c,v 1.7.18.4 2008/01/22 23:27:05 tbox Exp $ */
+/* $Id: lwdnoop.c,v 1.13 2008/01/22 23:28:04 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/bin/named/lwresd.8 b/contrib/bind9/bin/named/lwresd.8
index 827edcd..c0862aa 100644
--- a/contrib/bind9/bin/named/lwresd.8
+++ b/contrib/bind9/bin/named/lwresd.8
@@ -1,4 +1,4 @@
-.\" Copyright (C) 2004, 2005, 2007, 2008 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2004, 2005, 2007-2009 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: lwresd.8,v 1.15.18.13 2008/10/17 01:29:23 tbox Exp $
+.\" $Id: lwresd.8,v 1.29.14.1 2009/01/23 01:53:33 tbox Exp $
 .\"
 .hy 0
 .ad l
@@ -42,7 +42,7 @@ is the daemon providing name lookup services to clients that use the BIND 9 ligh
 \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.
+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
@@ -125,7 +125,7 @@ Run the server in the foreground and force all logging to
 Use
 \fIpid\-file\fR
 as the PID file instead of the default,
-\fI/var/run/lwresd.pid\fR.
+\fI/var/run/lwresd/lwresd.pid\fR.
 .RE
 .PP
 \-m \fIflag\fR
@@ -217,7 +217,7 @@ The default process\-id file.
 .PP
 Internet Systems Consortium
 .SH "COPYRIGHT"
-Copyright \(co 2004, 2005, 2007, 2008 Internet Systems Consortium, Inc. ("ISC")
+Copyright \(co 2004, 2005, 2007\-2009 Internet Systems Consortium, Inc. ("ISC")
 .br
 Copyright \(co 2000, 2001 Internet Software Consortium.
 .br
diff --git a/contrib/bind9/bin/named/lwresd.c b/contrib/bind9/bin/named/lwresd.c
index 8a89b1c..4e245fd 100644
--- a/contrib/bind9/bin/named/lwresd.c
+++ b/contrib/bind9/bin/named/lwresd.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lwresd.c,v 1.46.18.10 2008/07/23 23:33:02 marka Exp $ */
+/* $Id: lwresd.c,v 1.58 2008/07/23 23:27:54 marka Exp $ */
 
 /*! \file
  * \brief
diff --git a/contrib/bind9/bin/named/lwresd.docbook b/contrib/bind9/bin/named/lwresd.docbook
index 6dd2c40..8d9985a 100644
--- a/contrib/bind9/bin/named/lwresd.docbook
+++ b/contrib/bind9/bin/named/lwresd.docbook
@@ -2,7 +2,7 @@
                "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
 	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004, 2005, 2007-2009  Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000, 2001  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwresd.docbook,v 1.7.18.10 2008/10/16 23:46:00 tbox Exp $ -->
+<!-- $Id: lwresd.docbook,v 1.18.14.2 2009/01/22 23:47:05 tbox Exp $ -->
 <refentry>
   <refentryinfo>
     <date>June 30, 2000</date>
@@ -41,6 +41,7 @@
       <year>2005</year>
       <year>2007</year>
       <year>2008</year>
+      <year>2009</year>
       <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
     </copyright>
     <copyright>
@@ -87,7 +88,7 @@
       listens for resolver queries on a
       UDP port on the IPv4 loopback interface, 127.0.0.1.  This
       means that <command>lwresd</command> can only be used by
-      processes running on the local machine.  By default UDP port
+      processes running on the local machine.  By default, UDP port
       number 921 is used for lightweight resolver requests and
       responses.
     </para>
@@ -199,7 +200,7 @@
           <para>
             Use <replaceable class="parameter">pid-file</replaceable> as the
             PID file instead of the default,
-            <filename>/var/run/lwresd.pid</filename>.
+            <filename>/var/run/lwresd/lwresd.pid</filename>.
           </para>
         </listitem>
       </varlistentry>
diff --git a/contrib/bind9/bin/named/lwresd.html b/contrib/bind9/bin/named/lwresd.html
index 463e6b0..4c2b059 100644
--- a/contrib/bind9/bin/named/lwresd.html
+++ b/contrib/bind9/bin/named/lwresd.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004, 2005, 2007, 2008 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004, 2005, 2007-2009 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000, 2001 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: lwresd.html,v 1.5.18.19 2008/10/17 01:29:23 tbox Exp $ -->
+<!-- $Id: lwresd.html,v 1.25.14.1 2009/01/23 01:53:33 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -32,7 +32,7 @@
 <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">-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">-m <em class="replaceable"><code>flag</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>] [<code class="option">-4</code>] [<code class="option">-6</code>]</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2543464"></a><h2>DESCRIPTION</h2>
+<a name="id2543467"></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
@@ -44,7 +44,7 @@
       listens for resolver queries on a
       UDP port on the IPv4 loopback interface, 127.0.0.1.  This
       means that <span><strong class="command">lwresd</strong></span> can only be used by
-      processes running on the local machine.  By default UDP port
+      processes running on the local machine.  By default, UDP port
       number 921 is used for lightweight resolver requests and
       responses.
     </p>
@@ -67,7 +67,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2543511"></a><h2>OPTIONS</h2>
+<a name="id2543514"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-4</span></dt>
 <dd><p>
@@ -115,7 +115,7 @@
 <dd><p>
             Use <em class="replaceable"><code>pid-file</code></em> as the
             PID file instead of the default,
-            <code class="filename">/var/run/lwresd.pid</code>.
+            <code class="filename">/var/run/lwresd/lwresd.pid</code>.
           </p></dd>
 <dt><span class="term">-m <em class="replaceable"><code>flag</code></em></span></dt>
 <dd><p>
@@ -197,7 +197,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2543928"></a><h2>FILES</h2>
+<a name="id2543931"></a><h2>FILES</h2>
 <div class="variablelist"><dl>
 <dt><span class="term"><code class="filename">/etc/resolv.conf</code></span></dt>
 <dd><p>
@@ -210,14 +210,14 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2543968"></a><h2>SEE ALSO</h2>
+<a name="id2543971"></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="id2544002"></a><h2>AUTHOR</h2>
+<a name="id2544005"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
diff --git a/contrib/bind9/bin/named/lwsearch.c b/contrib/bind9/bin/named/lwsearch.c
index 4a61f96..6754c98 100644
--- a/contrib/bind9/bin/named/lwsearch.c
+++ b/contrib/bind9/bin/named/lwsearch.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lwsearch.c,v 1.8.18.3 2005/07/12 01:22:17 marka Exp $ */
+/* $Id: lwsearch.c,v 1.13 2007/06/19 23:46:59 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/bin/named/main.c b/contrib/bind9/bin/named/main.c
index d8b0a33..f97ab45 100644
--- a/contrib/bind9/bin/named/main.c
+++ b/contrib/bind9/bin/named/main.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: main.c,v 1.136.18.21 2008/10/24 01:28:08 marka Exp $ */
+/* $Id: main.c,v 1.166.34.3 2009/04/03 20:18:59 marka Exp $ */
 
 /*! \file */
 
@@ -139,7 +139,7 @@ assertion_failed(const char *file, int line, isc_assertiontype_t type,
 
 	if (ns_g_lctx != NULL) {
 		/*
-		 * Reset the assetion callback in case it is the log
+		 * Reset the assertion callback in case it is the log
 		 * routines causing the assertion.
 		 */
 		isc_assertion_setcallback(NULL);
@@ -359,7 +359,7 @@ parse_command_line(int argc, char *argv[]) {
 	isc_commandline_errprint = ISC_FALSE;
 	while ((ch = isc_commandline_parse(argc, argv,
 					   "46c:C:d:fgi:lm:n:N:p:P:"
-					   "sS:t:u:vx:")) != -1) {
+					   "sS:t:T:u:vVx:")) != -1) {
 		switch (ch) {
 		case '4':
 			if (disable4)
@@ -446,14 +446,31 @@ parse_command_line(int argc, char *argv[]) {
 			/* XXXJAB should we make a copy? */
 			ns_g_chrootdir = isc_commandline_argument;
 			break;
+		case 'T':
+			/*
+			 * clienttest: make clients single shot with their
+			 * 	       own memory context.
+			 */
+			if (strcmp(isc_commandline_argument, "clienttest") == 0)
+				ns_g_clienttest = ISC_TRUE;
+			else
+				fprintf(stderr, "unknown -T flag '%s\n",
+					isc_commandline_argument);
+			break;
 		case 'u':
 			ns_g_username = isc_commandline_argument;
 			break;
 		case 'v':
 			printf("BIND %s\n", ns_g_version);
 			exit(0);
+		case 'V':
+			printf("BIND %s built with %s\n", ns_g_version,
+				ns_g_configargs);
+			exit(0);
 		case '?':
 			usage();
+			if (isc_commandline_option == '?')
+				exit(0);
 			ns_main_earlyfatal("unknown option '-%c'",
 					   isc_commandline_option);
 		default:
@@ -661,6 +678,9 @@ setup(void) {
 		      ISC_LOG_NOTICE, "starting BIND %s%s", ns_g_version,
 		      saved_command_line);
 
+	isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL, NS_LOGMODULE_MAIN,
+		      ISC_LOG_NOTICE, "built with %s", ns_g_configargs);
+
 	/*
 	 * Get the initial resource limits.
 	 */
@@ -705,6 +725,14 @@ setup(void) {
 		ns_g_conffile = absolute_conffile;
 	}
 
+	/*
+	 * Record the server's startup time.
+	 */
+	result = isc_time_now(&ns_g_boottime);
+	if (result != ISC_R_SUCCESS)
+		ns_main_earlyfatal("isc_time_now() failed: %s",
+				   isc_result_totext(result));
+
 	result = create_managers();
 	if (result != ISC_R_SUCCESS)
 		ns_main_earlyfatal("create_managers() failed: %s",
@@ -719,7 +747,7 @@ setup(void) {
 
 #ifdef DLZ
 	/*
-	 * Registyer any DLZ drivers.
+	 * Register any DLZ drivers.
 	 */
 	result = dlz_drivers_init();
 	if (result != ISC_R_SUCCESS)
@@ -851,10 +879,10 @@ main(int argc, char *argv[]) {
 	 * strings named.core | grep "named version:"
 	 */
 	strlcat(version,
-#ifdef __DATE__
-		"named version: BIND " VERSION " (" __DATE__ ")",
-#else
+#if defined(NO_VERSION_DATE) || !defined(__DATE__)
 		"named version: BIND " VERSION,
+#else
+		"named version: BIND " VERSION " (" __DATE__ ")",
 #endif
 		sizeof(version));
 	result = isc_file_progname(*argv, program_name, sizeof(program_name));
@@ -892,6 +920,7 @@ main(int argc, char *argv[]) {
 	if (result != ISC_R_SUCCESS)
 		ns_main_earlyfatal("isc_mem_create() failed: %s",
 				   isc_result_totext(result));
+	isc_mem_setname(ns_g_mctx, "main", NULL);
 
 	setup();
 
@@ -937,7 +966,8 @@ main(int argc, char *argv[]) {
 		isc_mem_stats(ns_g_mctx, stdout);
 		isc_mutex_stats(stdout);
 	}
-	if (memstats != NULL) {
+
+	if (ns_g_memstatistics && memstats != NULL) {
 		FILE *fp = NULL;
 		result = isc_stdio_open(memstats, "w", &fp);
 		if (result == ISC_R_SUCCESS) {
diff --git a/contrib/bind9/bin/named/named.8 b/contrib/bind9/bin/named/named.8
index 9487dac..3408403 100644
--- a/contrib/bind9/bin/named/named.8
+++ b/contrib/bind9/bin/named/named.8
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: named.8,v 1.20.18.16 2008/09/01 02:29:00 tbox Exp $
+.\" $Id: named.8,v 1.38 2008/11/07 01:11:19 tbox Exp $
 .\"
 .hy 0
 .ad l
@@ -33,7 +33,7 @@
 named \- Internet domain name server
 .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\-m\ \fR\fB\fIflag\fR\fR] [\fB\-n\ \fR\fB\fI#cpus\fR\fR] [\fB\-p\ \fR\fB\fIport\fR\fR] [\fB\-s\fR] [\fB\-S\ \fR\fB\fI#max\-socks\fR\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]
+\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\-m\ \fR\fB\fIflag\fR\fR] [\fB\-n\ \fR\fB\fI#cpus\fR\fR] [\fB\-p\ \fR\fB\fIport\fR\fR] [\fB\-s\fR] [\fB\-S\ \fR\fB\fI#max\-socks\fR\fR] [\fB\-t\ \fR\fB\fIdirectory\fR\fR] [\fB\-u\ \fR\fB\fIuser\fR\fR] [\fB\-v\fR] [\fB\-V\fR] [\fB\-x\ \fR\fB\fIcache\-file\fR\fR]
 .SH "DESCRIPTION"
 .PP
 \fBnamed\fR
@@ -186,6 +186,11 @@ is run on kernel 2.2.18 or later, or kernel 2.3.99\-pre3 or later, since previou
 Report the version number and exit.
 .RE
 .PP
+\-V
+.RS 4
+Report the version number and build options, and exit.
+.RE
+.PP
 \-x \fIcache\-file\fR
 .RS 4
 Load data from
@@ -226,7 +231,7 @@ BIND 9 Administrator Reference Manual.
 The default configuration file.
 .RE
 .PP
-\fI/var/run/named.pid\fR
+\fI/var/run/named/named.pid\fR
 .RS 4
 The default process\-id file.
 .RE
diff --git a/contrib/bind9/bin/named/named.conf.5 b/contrib/bind9/bin/named/named.conf.5
index a2ccbe0..039c795 100644
--- a/contrib/bind9/bin/named/named.conf.5
+++ b/contrib/bind9/bin/named/named.conf.5
@@ -12,7 +12,7 @@
 .\" 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.2.27 2008/09/05 01:32:08 tbox Exp $
+.\" $Id: named.conf.5,v 1.36 2008/09/25 04:45:04 tbox Exp $
 .\"
 .hy 0
 .ad l
@@ -193,6 +193,7 @@ options {
 	use\-ixfr \fIboolean\fR;
 	version ( \fIquoted_string\fR | none );
 	allow\-recursion { \fIaddress_match_element\fR; ... };
+	allow\-recursion\-on { \fIaddress_match_element\fR; ... };
 	sortlist { \fIaddress_match_element\fR; ... };
 	topology { \fIaddress_match_element\fR; ... }; // not implemented
 	auth\-nxdomain \fIboolean\fR; // default changed
@@ -209,14 +210,17 @@ options {
 	additional\-from\-cache \fIboolean\fR;
 	query\-source ( ( \fIipv4_address\fR | * ) | [ address ( \fIipv4_address\fR | * ) ] ) [ port ( \fIinteger\fR | * ) ];
 	query\-source\-v6 ( ( \fIipv6_address\fR | * ) | [ address ( \fIipv6_address\fR | * ) ] ) [ port ( \fIinteger\fR | * ) ];
+	use\-queryport\-pool \fIboolean\fR;
+	queryport\-pool\-ports \fIinteger\fR;
+	queryport\-pool\-updateinterval \fIinteger\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;
-	max\-acache\-size \fIsize_no_default\fR;
+	max\-cache\-size \fIsize\fR;
+	max\-acache\-size \fIsize\fR;
 	clients\-per\-query \fInumber\fR;
 	max\-clients\-per\-query \fInumber\fR;
 	check\-names ( master | slave | response )
@@ -249,7 +253,9 @@ options {
 	dialup \fIdialuptype\fR;
 	ixfr\-from\-differences \fIixfrdiff\fR;
 	allow\-query { \fIaddress_match_element\fR; ... };
+	allow\-query\-on { \fIaddress_match_element\fR; ... };
 	allow\-query\-cache { \fIaddress_match_element\fR; ... };
+	allow\-query\-cache\-on { \fIaddress_match_element\fR; ... };
 	allow\-transfer { \fIaddress_match_element\fR; ... };
 	allow\-update { \fIaddress_match_element\fR; ... };
 	allow\-update\-forwarding { \fIaddress_match_element\fR; ... };
@@ -259,6 +265,7 @@ options {
 	notify\-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
 	notify\-source\-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
 	notify\-delay \fIseconds\fR;
+	notify\-to\-soa \fIboolean\fR;
 	also\-notify [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR )
 		[ port \fIinteger\fR ]; ... };
 	allow\-notify { \fIaddress_match_element\fR; ... };
@@ -277,6 +284,10 @@ options {
 	min\-refresh\-time \fIinteger\fR;
 	multi\-master \fIboolean\fR;
 	sig\-validity\-interval \fIinteger\fR;
+	sig\-re\-signing\-interval \fIinteger\fR;
+	sig\-signing\-nodes \fIinteger\fR;
+	sig\-signing\-signatures \fIinteger\fR;
+	sig\-signing\-type \fIinteger\fR;
 	transfer\-source ( \fIipv4_address\fR | * )
 		[ port ( \fIinteger\fR | * ) ];
 	transfer\-source\-v6 ( \fIipv6_address\fR | * )
@@ -288,8 +299,10 @@ options {
 	use\-alt\-transfer\-source \fIboolean\fR;
 	zone\-statistics \fIboolean\fR;
 	key\-directory \fIquoted_string\fR;
+	try\-tcp\-refresh \fIboolean\fR;
 	zero\-no\-soa\-ttl \fIboolean\fR;
 	zero\-no\-soa\-ttl\-cache \fIboolean\fR;
+	nsec3\-test\-zone \fIboolean\fR;  // testing only
 	allow\-v6\-synthesis { \fIaddress_match_element\fR; ... }; // obsolete
 	deallocate\-on\-exit \fIboolean\fR; // obsolete
 	fake\-iquery \fIboolean\fR; // obsolete
@@ -327,6 +340,7 @@ view \fIstring\fR \fIoptional_class\fR {
 		\fIstring\fR \fIinteger\fR \fIinteger\fR \fIinteger\fR \fIquoted_string\fR; ...
 	};
 	allow\-recursion { \fIaddress_match_element\fR; ... };
+	allow\-recursion\-on { \fIaddress_match_element\fR; ... };
 	sortlist { \fIaddress_match_element\fR; ... };
 	topology { \fIaddress_match_element\fR; ... }; // not implemented
 	auth\-nxdomain \fIboolean\fR; // default changed
@@ -343,14 +357,17 @@ view \fIstring\fR \fIoptional_class\fR {
 	additional\-from\-cache \fIboolean\fR;
 	query\-source ( ( \fIipv4_address\fR | * ) | [ address ( \fIipv4_address\fR | * ) ] ) [ port ( \fIinteger\fR | * ) ];
 	query\-source\-v6 ( ( \fIipv6_address\fR | * ) | [ address ( \fIipv6_address\fR | * ) ] ) [ port ( \fIinteger\fR | * ) ];
+	use\-queryport\-pool \fIboolean\fR;
+	queryport\-pool\-ports \fIinteger\fR;
+	queryport\-pool\-updateinterval \fIinteger\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;
-	max\-acache\-size \fIsize_no_default\fR;
+	max\-cache\-size \fIsize\fR;
+	max\-acache\-size \fIsize\fR;
 	clients\-per\-query \fInumber\fR;
 	max\-clients\-per\-query \fInumber\fR;
 	check\-names ( master | slave | response )
@@ -383,7 +400,9 @@ view \fIstring\fR \fIoptional_class\fR {
 	dialup \fIdialuptype\fR;
 	ixfr\-from\-differences \fIixfrdiff\fR;
 	allow\-query { \fIaddress_match_element\fR; ... };
+	allow\-query\-on { \fIaddress_match_element\fR; ... };
 	allow\-query\-cache { \fIaddress_match_element\fR; ... };
+	allow\-query\-cache\-on { \fIaddress_match_element\fR; ... };
 	allow\-transfer { \fIaddress_match_element\fR; ... };
 	allow\-update { \fIaddress_match_element\fR; ... };
 	allow\-update\-forwarding { \fIaddress_match_element\fR; ... };
@@ -393,6 +412,7 @@ view \fIstring\fR \fIoptional_class\fR {
 	notify\-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
 	notify\-source\-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
 	notify\-delay \fIseconds\fR;
+	notify\-to\-soa \fIboolean\fR;
 	also\-notify [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR )
 		[ port \fIinteger\fR ]; ... };
 	allow\-notify { \fIaddress_match_element\fR; ... };
@@ -421,6 +441,7 @@ view \fIstring\fR \fIoptional_class\fR {
 		[ port ( \fIinteger\fR | * ) ];
 	use\-alt\-transfer\-source \fIboolean\fR;
 	zone\-statistics \fIboolean\fR;
+	try\-tcp\-refresh \fIboolean\fR;
 	key\-directory \fIquoted_string\fR;
 	zero\-no\-soa\-ttl \fIboolean\fR;
 	zero\-no\-soa\-ttl\-cache \fIboolean\fR;
@@ -456,12 +477,15 @@ zone \fIstring\fR \fIoptional_class\fR {
 	journal \fIquoted_string\fR;
 	zero\-no\-soa\-ttl \fIboolean\fR;
 	allow\-query { \fIaddress_match_element\fR; ... };
+	allow\-query\-on { \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
+		( name | subdomain | wildcard | self | selfsub | selfwild |
+                  krb5\-self | ms\-self | krb5\-subdomain | ms\-subdomain |
+		  tcp\-self | 6to4\-self ) \fIstring\fR
 		\fIrrtypelist\fR; ...
 	};
 	update\-check\-ksk \fIboolean\fR;
@@ -470,6 +494,7 @@ zone \fIstring\fR \fIoptional_class\fR {
 	notify\-source ( \fIipv4_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
 	notify\-source\-v6 ( \fIipv6_address\fR | * ) [ port ( \fIinteger\fR | * ) ];
 	notify\-delay \fIseconds\fR;
+	notify\-to\-soa \fIboolean\fR;
 	also\-notify [ port \fIinteger\fR ] { ( \fIipv4_address\fR | \fIipv6_address\fR )
 		[ port \fIinteger\fR ]; ... };
 	allow\-notify { \fIaddress_match_element\fR; ... };
@@ -498,7 +523,9 @@ zone \fIstring\fR \fIoptional_class\fR {
 		[ port ( \fIinteger\fR | * ) ];
 	use\-alt\-transfer\-source \fIboolean\fR;
 	zone\-statistics \fIboolean\fR;
+	try\-tcp\-refresh \fIboolean\fR;
 	key\-directory \fIquoted_string\fR;
+	nsec3\-test\-zone \fIboolean\fR;  // testing only
 	ixfr\-base \fIquoted_string\fR; // obsolete
 	ixfr\-tmp\-file \fIquoted_string\fR; // obsolete
 	maintain\-ixfr\-base \fIboolean\fR; // obsolete
diff --git a/contrib/bind9/bin/named/named.conf.docbook b/contrib/bind9/bin/named/named.conf.docbook
index 32aa537..a4a8044 100644
--- a/contrib/bind9/bin/named/named.conf.docbook
+++ b/contrib/bind9/bin/named/named.conf.docbook
@@ -17,7 +17,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: named.conf.docbook,v 1.1.2.31 2008/09/04 23:46:08 tbox Exp $ -->
+<!-- $Id: named.conf.docbook,v 1.39 2008/09/24 02:46:21 marka Exp $ -->
 <refentry>
   <refentryinfo>
     <date>Aug 13, 2004</date>
@@ -221,6 +221,7 @@ options {
 	use-ixfr <replaceable>boolean</replaceable>;
 	version ( <replaceable>quoted_string</replaceable> | none );
 	allow-recursion { <replaceable>address_match_element</replaceable>; ... };
+	allow-recursion-on { <replaceable>address_match_element</replaceable>; ... };
 	sortlist { <replaceable>address_match_element</replaceable>; ... };
 	topology { <replaceable>address_match_element</replaceable>; ... }; // not implemented
 	auth-nxdomain <replaceable>boolean</replaceable>; // default changed
@@ -237,14 +238,17 @@ options {
 	additional-from-cache <replaceable>boolean</replaceable>;
 	query-source ( ( <replaceable>ipv4_address</replaceable> | * ) | <optional> address ( <replaceable>ipv4_address</replaceable> | * ) </optional> ) <optional> port ( <replaceable>integer</replaceable> | * ) </optional>;
 	query-source-v6 ( ( <replaceable>ipv6_address</replaceable> | * ) | <optional> address ( <replaceable>ipv6_address</replaceable> | * ) </optional> ) <optional> port ( <replaceable>integer</replaceable> | * ) </optional>;
+	use-queryport-pool <replaceable>boolean</replaceable>;
+	queryport-pool-ports <replaceable>integer</replaceable>;
+	queryport-pool-updateinterval <replaceable>integer</replaceable>;
 	cleaning-interval <replaceable>integer</replaceable>;
 	min-roots <replaceable>integer</replaceable>; // not implemented
 	lame-ttl <replaceable>integer</replaceable>;
 	max-ncache-ttl <replaceable>integer</replaceable>;
 	max-cache-ttl <replaceable>integer</replaceable>;
 	transfer-format ( many-answers | one-answer );
-	max-cache-size <replaceable>size_no_default</replaceable>;
-	max-acache-size <replaceable>size_no_default</replaceable>;
+	max-cache-size <replaceable>size</replaceable>;
+	max-acache-size <replaceable>size</replaceable>;
 	clients-per-query <replaceable>number</replaceable>;
 	max-clients-per-query <replaceable>number</replaceable>;
 	check-names ( master | slave | response )
@@ -280,7 +284,9 @@ options {
 	ixfr-from-differences <replaceable>ixfrdiff</replaceable>;
 
 	allow-query { <replaceable>address_match_element</replaceable>; ... };
+	allow-query-on { <replaceable>address_match_element</replaceable>; ... };
 	allow-query-cache { <replaceable>address_match_element</replaceable>; ... };
+	allow-query-cache-on { <replaceable>address_match_element</replaceable>; ... };
 	allow-transfer { <replaceable>address_match_element</replaceable>; ... };
 	allow-update { <replaceable>address_match_element</replaceable>; ... };
 	allow-update-forwarding { <replaceable>address_match_element</replaceable>; ... };
@@ -291,6 +297,7 @@ options {
 	notify-source ( <replaceable>ipv4_address</replaceable> | * ) <optional> port ( <replaceable>integer</replaceable> | * ) </optional>;
 	notify-source-v6 ( <replaceable>ipv6_address</replaceable> | * ) <optional> port ( <replaceable>integer</replaceable> | * ) </optional>;
 	notify-delay <replaceable>seconds</replaceable>;
+	notify-to-soa <replaceable>boolean</replaceable>;
 	also-notify <optional> port <replaceable>integer</replaceable> </optional> { ( <replaceable>ipv4_address</replaceable> | <replaceable>ipv6_address</replaceable> )
 		<optional> port <replaceable>integer</replaceable> </optional>; ... };
 	allow-notify { <replaceable>address_match_element</replaceable>; ... };
@@ -310,7 +317,12 @@ options {
 	max-refresh-time <replaceable>integer</replaceable>;
 	min-refresh-time <replaceable>integer</replaceable>;
 	multi-master <replaceable>boolean</replaceable>;
+
 	sig-validity-interval <replaceable>integer</replaceable>;
+	sig-re-signing-interval <replaceable>integer</replaceable>;
+	sig-signing-nodes <replaceable>integer</replaceable>;
+	sig-signing-signatures <replaceable>integer</replaceable>;
+	sig-signing-type <replaceable>integer</replaceable>;
 
 	transfer-source ( <replaceable>ipv4_address</replaceable> | * )
 		<optional> port ( <replaceable>integer</replaceable> | * ) </optional>;
@@ -325,9 +337,12 @@ options {
 
 	zone-statistics <replaceable>boolean</replaceable>;
 	key-directory <replaceable>quoted_string</replaceable>;
+	try-tcp-refresh <replaceable>boolean</replaceable>;
 	zero-no-soa-ttl <replaceable>boolean</replaceable>;
 	zero-no-soa-ttl-cache <replaceable>boolean</replaceable>;
 
+	nsec3-test-zone <replaceable>boolean</replaceable>;  // testing only
+
 	allow-v6-synthesis { <replaceable>address_match_element</replaceable>; ... }; // obsolete
 	deallocate-on-exit <replaceable>boolean</replaceable>; // obsolete
 	fake-iquery <replaceable>boolean</replaceable>; // obsolete
@@ -370,6 +385,7 @@ view <replaceable>string</replaceable> <replaceable>optional_class</replaceable>
 	};
 
 	allow-recursion { <replaceable>address_match_element</replaceable>; ... };
+	allow-recursion-on { <replaceable>address_match_element</replaceable>; ... };
 	sortlist { <replaceable>address_match_element</replaceable>; ... };
 	topology { <replaceable>address_match_element</replaceable>; ... }; // not implemented
 	auth-nxdomain <replaceable>boolean</replaceable>; // default changed
@@ -386,14 +402,17 @@ view <replaceable>string</replaceable> <replaceable>optional_class</replaceable>
 	additional-from-cache <replaceable>boolean</replaceable>;
 	query-source ( ( <replaceable>ipv4_address</replaceable> | * ) | <optional> address ( <replaceable>ipv4_address</replaceable> | * ) </optional> ) <optional> port ( <replaceable>integer</replaceable> | * ) </optional>;
 	query-source-v6 ( ( <replaceable>ipv6_address</replaceable> | * ) | <optional> address ( <replaceable>ipv6_address</replaceable> | * ) </optional> ) <optional> port ( <replaceable>integer</replaceable> | * ) </optional>;
+	use-queryport-pool <replaceable>boolean</replaceable>;
+	queryport-pool-ports <replaceable>integer</replaceable>;
+	queryport-pool-updateinterval <replaceable>integer</replaceable>;
 	cleaning-interval <replaceable>integer</replaceable>;
 	min-roots <replaceable>integer</replaceable>; // not implemented
 	lame-ttl <replaceable>integer</replaceable>;
 	max-ncache-ttl <replaceable>integer</replaceable>;
 	max-cache-ttl <replaceable>integer</replaceable>;
 	transfer-format ( many-answers | one-answer );
-	max-cache-size <replaceable>size_no_default</replaceable>;
-	max-acache-size <replaceable>size_no_default</replaceable>;
+	max-cache-size <replaceable>size</replaceable>;
+	max-acache-size <replaceable>size</replaceable>;
 	clients-per-query <replaceable>number</replaceable>;
 	max-clients-per-query <replaceable>number</replaceable>;
 	check-names ( master | slave | response )
@@ -429,7 +448,9 @@ view <replaceable>string</replaceable> <replaceable>optional_class</replaceable>
 	ixfr-from-differences <replaceable>ixfrdiff</replaceable>;
 
 	allow-query { <replaceable>address_match_element</replaceable>; ... };
+	allow-query-on { <replaceable>address_match_element</replaceable>; ... };
 	allow-query-cache { <replaceable>address_match_element</replaceable>; ... };
+	allow-query-cache-on { <replaceable>address_match_element</replaceable>; ... };
 	allow-transfer { <replaceable>address_match_element</replaceable>; ... };
 	allow-update { <replaceable>address_match_element</replaceable>; ... };
 	allow-update-forwarding { <replaceable>address_match_element</replaceable>; ... };
@@ -440,6 +461,7 @@ view <replaceable>string</replaceable> <replaceable>optional_class</replaceable>
 	notify-source ( <replaceable>ipv4_address</replaceable> | * ) <optional> port ( <replaceable>integer</replaceable> | * ) </optional>;
 	notify-source-v6 ( <replaceable>ipv6_address</replaceable> | * ) <optional> port ( <replaceable>integer</replaceable> | * ) </optional>;
 	notify-delay <replaceable>seconds</replaceable>;
+	notify-to-soa <replaceable>boolean</replaceable>;
 	also-notify <optional> port <replaceable>integer</replaceable> </optional> { ( <replaceable>ipv4_address</replaceable> | <replaceable>ipv6_address</replaceable> )
 		<optional> port <replaceable>integer</replaceable> </optional>; ... };
 	allow-notify { <replaceable>address_match_element</replaceable>; ... };
@@ -473,6 +495,7 @@ view <replaceable>string</replaceable> <replaceable>optional_class</replaceable>
 	use-alt-transfer-source <replaceable>boolean</replaceable>;
 
 	zone-statistics <replaceable>boolean</replaceable>;
+	try-tcp-refresh <replaceable>boolean</replaceable>;
 	key-directory <replaceable>quoted_string</replaceable>;
 	zero-no-soa-ttl <replaceable>boolean</replaceable>;
 	zero-no-soa-ttl-cache <replaceable>boolean</replaceable>;
@@ -512,12 +535,15 @@ zone <replaceable>string</replaceable> <replaceable>optional_class</replaceable>
 	zero-no-soa-ttl <replaceable>boolean</replaceable>;
 
 	allow-query { <replaceable>address_match_element</replaceable>; ... };
+	allow-query-on { <replaceable>address_match_element</replaceable>; ... };
 	allow-transfer { <replaceable>address_match_element</replaceable>; ... };
 	allow-update { <replaceable>address_match_element</replaceable>; ... };
 	allow-update-forwarding { <replaceable>address_match_element</replaceable>; ... };
 	update-policy {
 		( grant | deny ) <replaceable>string</replaceable>
-		( name | subdomain | wildcard | self ) <replaceable>string</replaceable>
+		( name | subdomain | wildcard | self | selfsub | selfwild |
+                  krb5-self | ms-self | krb5-subdomain | ms-subdomain |
+		  tcp-self | 6to4-self ) <replaceable>string</replaceable>
 		<replaceable>rrtypelist</replaceable>; ...
 	};
 	update-check-ksk <replaceable>boolean</replaceable>;
@@ -527,6 +553,7 @@ zone <replaceable>string</replaceable> <replaceable>optional_class</replaceable>
 	notify-source ( <replaceable>ipv4_address</replaceable> | * ) <optional> port ( <replaceable>integer</replaceable> | * ) </optional>;
 	notify-source-v6 ( <replaceable>ipv6_address</replaceable> | * ) <optional> port ( <replaceable>integer</replaceable> | * ) </optional>;
 	notify-delay <replaceable>seconds</replaceable>;
+	notify-to-soa <replaceable>boolean</replaceable>;
 	also-notify <optional> port <replaceable>integer</replaceable> </optional> { ( <replaceable>ipv4_address</replaceable> | <replaceable>ipv6_address</replaceable> )
 		<optional> port <replaceable>integer</replaceable> </optional>; ... };
 	allow-notify { <replaceable>address_match_element</replaceable>; ... };
@@ -560,8 +587,11 @@ zone <replaceable>string</replaceable> <replaceable>optional_class</replaceable>
 	use-alt-transfer-source <replaceable>boolean</replaceable>;
 
 	zone-statistics <replaceable>boolean</replaceable>;
+	try-tcp-refresh <replaceable>boolean</replaceable>;
 	key-directory <replaceable>quoted_string</replaceable>;
 
+	nsec3-test-zone <replaceable>boolean</replaceable>;  // testing only
+
 	ixfr-base <replaceable>quoted_string</replaceable>; // obsolete
 	ixfr-tmp-file <replaceable>quoted_string</replaceable>; // obsolete
 	maintain-ixfr-base <replaceable>boolean</replaceable>; // obsolete
diff --git a/contrib/bind9/bin/named/named.conf.html b/contrib/bind9/bin/named/named.conf.html
index f729988..7bbbd0a 100644
--- a/contrib/bind9/bin/named/named.conf.html
+++ b/contrib/bind9/bin/named/named.conf.html
@@ -13,7 +13,7 @@
  - 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.2.36 2008/09/05 01:32:08 tbox Exp $ -->
+<!-- $Id: named.conf.html,v 1.45 2008/09/25 04:45:04 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -191,6 +191,7 @@ options {<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>
+	allow-recursion-on { <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>
@@ -207,14 +208,17 @@ options {<br>
 	additional-from-cache <em class="replaceable"><code>boolean</code></em>;<br>
 	query-source ( ( <em class="replaceable"><code>ipv4_address</code></em> | * ) | [<span class="optional"> address ( <em class="replaceable"><code>ipv4_address</code></em> | * ) </span>] ) [<span class="optional"> port ( <em class="replaceable"><code>integer</code></em> | * ) </span>];<br>
 	query-source-v6 ( ( <em class="replaceable"><code>ipv6_address</code></em> | * ) | [<span class="optional"> address ( <em class="replaceable"><code>ipv6_address</code></em> | * ) </span>] ) [<span class="optional"> port ( <em class="replaceable"><code>integer</code></em> | * ) </span>];<br>
+	use-queryport-pool <em class="replaceable"><code>boolean</code></em>;<br>
+	queryport-pool-ports <em class="replaceable"><code>integer</code></em>;<br>
+	queryport-pool-updateinterval <em class="replaceable"><code>integer</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>
-	max-acache-size <em class="replaceable"><code>size_no_default</code></em>;<br>
+	max-cache-size <em class="replaceable"><code>size</code></em>;<br>
+	max-acache-size <em class="replaceable"><code>size</code></em>;<br>
 	clients-per-query <em class="replaceable"><code>number</code></em>;<br>
 	max-clients-per-query <em class="replaceable"><code>number</code></em>;<br>
 	check-names ( master | slave | response )<br>
@@ -250,7 +254,9 @@ options {<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-query-on { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
 	allow-query-cache { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
+	allow-query-cache-on { <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>
@@ -261,6 +267,7 @@ options {<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>
 	notify-delay <em class="replaceable"><code>seconds</code></em>;<br>
+	notify-to-soa <em class="replaceable"><code>boolean</code></em>;<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>
@@ -280,7 +287,12 @@ options {<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>
+<br>
 	sig-validity-interval <em class="replaceable"><code>integer</code></em>;<br>
+	sig-re-signing-interval <em class="replaceable"><code>integer</code></em>;<br>
+	sig-signing-nodes <em class="replaceable"><code>integer</code></em>;<br>
+	sig-signing-signatures <em class="replaceable"><code>integer</code></em>;<br>
+	sig-signing-type <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>
@@ -295,9 +307,12 @@ options {<br>
 <br>
 	zone-statistics <em class="replaceable"><code>boolean</code></em>;<br>
 	key-directory <em class="replaceable"><code>quoted_string</code></em>;<br>
+	try-tcp-refresh <em class="replaceable"><code>boolean</code></em>;<br>
 	zero-no-soa-ttl <em class="replaceable"><code>boolean</code></em>;<br>
 	zero-no-soa-ttl-cache <em class="replaceable"><code>boolean</code></em>;<br>
 <br>
+	nsec3-test-zone <em class="replaceable"><code>boolean</code></em>;  // testing only<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>
@@ -314,7 +329,7 @@ options {<br>
 </p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2544407"></a><h2>VIEW</h2>
+<a name="id2544452"></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>
@@ -339,6 +354,7 @@ view <em class="replaceable"><code>string</code></em> <em class="replaceable"><c
 	};<br>
 <br>
 	allow-recursion { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
+	allow-recursion-on { <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>
@@ -355,14 +371,17 @@ view <em class="replaceable"><code>string</code></em> <em class="replaceable"><c
 	additional-from-cache <em class="replaceable"><code>boolean</code></em>;<br>
 	query-source ( ( <em class="replaceable"><code>ipv4_address</code></em> | * ) | [<span class="optional"> address ( <em class="replaceable"><code>ipv4_address</code></em> | * ) </span>] ) [<span class="optional"> port ( <em class="replaceable"><code>integer</code></em> | * ) </span>];<br>
 	query-source-v6 ( ( <em class="replaceable"><code>ipv6_address</code></em> | * ) | [<span class="optional"> address ( <em class="replaceable"><code>ipv6_address</code></em> | * ) </span>] ) [<span class="optional"> port ( <em class="replaceable"><code>integer</code></em> | * ) </span>];<br>
+	use-queryport-pool <em class="replaceable"><code>boolean</code></em>;<br>
+	queryport-pool-ports <em class="replaceable"><code>integer</code></em>;<br>
+	queryport-pool-updateinterval <em class="replaceable"><code>integer</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>
-	max-acache-size <em class="replaceable"><code>size_no_default</code></em>;<br>
+	max-cache-size <em class="replaceable"><code>size</code></em>;<br>
+	max-acache-size <em class="replaceable"><code>size</code></em>;<br>
 	clients-per-query <em class="replaceable"><code>number</code></em>;<br>
 	max-clients-per-query <em class="replaceable"><code>number</code></em>;<br>
 	check-names ( master | slave | response )<br>
@@ -398,7 +417,9 @@ view <em class="replaceable"><code>string</code></em> <em class="replaceable"><c
 	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-query-on { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
 	allow-query-cache { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
+	allow-query-cache-on { <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>
@@ -409,6 +430,7 @@ view <em class="replaceable"><code>string</code></em> <em class="replaceable"><c
 	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>
 	notify-delay <em class="replaceable"><code>seconds</code></em>;<br>
+	notify-to-soa <em class="replaceable"><code>boolean</code></em>;<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>
@@ -442,6 +464,7 @@ view <em class="replaceable"><code>string</code></em> <em class="replaceable"><c
 	use-alt-transfer-source <em class="replaceable"><code>boolean</code></em>;<br>
 <br>
 	zone-statistics <em class="replaceable"><code>boolean</code></em>;<br>
+	try-tcp-refresh <em class="replaceable"><code>boolean</code></em>;<br>
 	key-directory <em class="replaceable"><code>quoted_string</code></em>;<br>
 	zero-no-soa-ttl <em class="replaceable"><code>boolean</code></em>;<br>
 	zero-no-soa-ttl-cache <em class="replaceable"><code>boolean</code></em>;<br>
@@ -454,7 +477,7 @@ view <em class="replaceable"><code>string</code></em> <em class="replaceable"><c
 </p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2544972"></a><h2>ZONE</h2>
+<a name="id2545113"></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>
@@ -480,12 +503,15 @@ zone <em class="replaceable"><code>string</code></em> <em class="replaceable"><c
 	zero-no-soa-ttl <em class="replaceable"><code>boolean</code></em>;<br>
 <br>
 	allow-query { <em class="replaceable"><code>address_match_element</code></em>; ... };<br>
+	allow-query-on { <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>
+		( name | subdomain | wildcard | self | selfsub | selfwild |<br>
+                  krb5-self | ms-self | krb5-subdomain | ms-subdomain |<br>
+		  tcp-self | 6to4-self ) <em class="replaceable"><code>string</code></em><br>
 		<em class="replaceable"><code>rrtypelist</code></em>; ...<br>
 	};<br>
 	update-check-ksk <em class="replaceable"><code>boolean</code></em>;<br>
@@ -495,6 +521,7 @@ zone <em class="replaceable"><code>string</code></em> <em class="replaceable"><c
 	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>
 	notify-delay <em class="replaceable"><code>seconds</code></em>;<br>
+	notify-to-soa <em class="replaceable"><code>boolean</code></em>;<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>
@@ -528,8 +555,11 @@ zone <em class="replaceable"><code>string</code></em> <em class="replaceable"><c
 	use-alt-transfer-source <em class="replaceable"><code>boolean</code></em>;<br>
 <br>
 	zone-statistics <em class="replaceable"><code>boolean</code></em>;<br>
+	try-tcp-refresh <em class="replaceable"><code>boolean</code></em>;<br>
 	key-directory <em class="replaceable"><code>quoted_string</code></em>;<br>
 <br>
+	nsec3-test-zone <em class="replaceable"><code>boolean</code></em>;  // testing only<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>
@@ -539,12 +569,12 @@ zone <em class="replaceable"><code>string</code></em> <em class="replaceable"><c
 </p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2545325"></a><h2>FILES</h2>
+<a name="id2545410"></a><h2>FILES</h2>
 <p><code class="filename">/etc/named.conf</code>
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2545337"></a><h2>SEE ALSO</h2>
+<a name="id2545421"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
       <span class="citerefentry"><span class="refentrytitle">named-checkconf</span>(8)</span>,
       <span class="citerefentry"><span class="refentrytitle">rndc</span>(8)</span>,
diff --git a/contrib/bind9/bin/named/named.docbook b/contrib/bind9/bin/named/named.docbook
index 15d554c..f47eae1 100644
--- a/contrib/bind9/bin/named/named.docbook
+++ b/contrib/bind9/bin/named/named.docbook
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: named.docbook,v 1.7.18.14 2008/08/21 23:46:01 tbox Exp $ -->
+<!-- $Id: named.docbook,v 1.23 2008/11/06 05:30:24 marka Exp $ -->
 <refentry id="man.named">
   <refentryinfo>
     <date>June 30, 2000</date>
@@ -69,6 +69,7 @@
       <arg><option>-t <replaceable class="parameter">directory</replaceable></option></arg>
       <arg><option>-u <replaceable class="parameter">user</replaceable></option></arg>
       <arg><option>-v</option></arg>
+      <arg><option>-V</option></arg>
       <arg><option>-x <replaceable class="parameter">cache-file</replaceable></option></arg>
     </cmdsynopsis>
   </refsynopsisdiv>
@@ -300,6 +301,15 @@
       </varlistentry>
 
       <varlistentry>
+        <term>-V</term>
+        <listitem>
+          <para>
+            Report the version number and build options, and exit.
+          </para>
+        </listitem>
+      </varlistentry>
+
+      <varlistentry>
         <term>-x <replaceable class="parameter">cache-file</replaceable></term>
         <listitem>
           <para>
@@ -381,7 +391,7 @@
       </varlistentry>
 
       <varlistentry>
-        <term><filename>/var/run/named.pid</filename></term>
+        <term><filename>/var/run/named/named.pid</filename></term>
         <listitem>
           <para>
             The default process-id file.
diff --git a/contrib/bind9/bin/named/named.html b/contrib/bind9/bin/named/named.html
index ed4f16a..23c9a7c 100644
--- a/contrib/bind9/bin/named/named.html
+++ b/contrib/bind9/bin/named/named.html
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: named.html,v 1.6.18.22 2008/09/01 02:29:00 tbox Exp $ -->
+<!-- $Id: named.html,v 1.30 2008/11/07 01:11:19 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -29,10 +29,10 @@
 </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">-m <em class="replaceable"><code>flag</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">-s</code>] [<code class="option">-S <em class="replaceable"><code>#max-socks</code></em></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 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">-m <em class="replaceable"><code>flag</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">-s</code>] [<code class="option">-S <em class="replaceable"><code>#max-socks</code></em></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">-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="id2543464"></a><h2>DESCRIPTION</h2>
+<a name="id2543468"></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
@@ -47,7 +47,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2543489"></a><h2>OPTIONS</h2>
+<a name="id2543493"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-4</span></dt>
 <dd><p>
@@ -198,6 +198,10 @@
 <dd><p>
             Report the version number and exit.
           </p></dd>
+<dt><span class="term">-V</span></dt>
+<dd><p>
+            Report the version number and build options, and exit.
+          </p></dd>
 <dt><span class="term">-x <em class="replaceable"><code>cache-file</code></em></span></dt>
 <dd>
 <p>
@@ -216,7 +220,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2543911"></a><h2>SIGNALS</h2>
+<a name="id2543928"></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
@@ -237,7 +241,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2543959"></a><h2>CONFIGURATION</h2>
+<a name="id2543976"></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
@@ -246,20 +250,20 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2543976"></a><h2>FILES</h2>
+<a name="id2543993"></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>
+<dt><span class="term"><code class="filename">/var/run/named/named.pid</code></span></dt>
 <dd><p>
             The default process-id file.
           </p></dd>
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2544016"></a><h2>SEE ALSO</h2>
+<a name="id2544033"></a><h2>SEE ALSO</h2>
 <p><em class="citetitle">RFC 1033</em>,
       <em class="citetitle">RFC 1034</em>,
       <em class="citetitle">RFC 1035</em>,
@@ -272,7 +276,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2544086"></a><h2>AUTHOR</h2>
+<a name="id2544171"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
diff --git a/contrib/bind9/bin/named/notify.c b/contrib/bind9/bin/named/notify.c
index db2be71..de52b8c 100644
--- a/contrib/bind9/bin/named/notify.c
+++ b/contrib/bind9/bin/named/notify.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: notify.c,v 1.30.18.3 2005/04/29 00:15:26 marka Exp $ */
+/* $Id: notify.c,v 1.37 2007/06/19 23:46:59 tbox Exp $ */
 
 #include <config.h>
 
@@ -25,6 +25,7 @@
 #include <dns/message.h>
 #include <dns/rdataset.h>
 #include <dns/result.h>
+#include <dns/tsig.h>
 #include <dns/view.h>
 #include <dns/zone.h>
 #include <dns/zt.h>
@@ -80,7 +81,7 @@ ns_notify_start(ns_client_t *client) {
 	dns_zone_t *zone = NULL;
 	char namebuf[DNS_NAME_FORMATSIZE];
 	char tsigbuf[DNS_NAME_FORMATSIZE + sizeof(": TSIG ''")];
-	dns_name_t *tsigname;
+	dns_tsigkey_t *tsigkey;
 
 	/*
 	 * Interpret the question section.
@@ -119,10 +120,20 @@ ns_notify_start(ns_client_t *client) {
 		goto formerr;
 	}
 
-	tsigname = NULL;
-	if (dns_message_gettsig(request, &tsigname) != NULL) {
-		dns_name_format(tsigname, namebuf, sizeof(namebuf));
-		snprintf(tsigbuf, sizeof(tsigbuf), ": TSIG '%s'", namebuf);
+	tsigkey = dns_message_gettsigkey(request);
+	if (tsigkey != NULL) {
+		dns_name_format(&tsigkey->name, namebuf, sizeof(namebuf));
+
+		if (tsigkey->generated) {
+			char cnamebuf[DNS_NAME_FORMATSIZE];
+			dns_name_format(tsigkey->creator, cnamebuf,
+					sizeof(cnamebuf));
+			snprintf(tsigbuf, sizeof(tsigbuf), ": TSIG '%s' (%s)",
+				 namebuf, cnamebuf);
+		} else {
+			snprintf(tsigbuf, sizeof(tsigbuf), ": TSIG '%s'",
+				 namebuf);
+		}
 	} else
 		tsigbuf[0] = '\0';
 	dns_name_format(zonename, namebuf, sizeof(namebuf));
diff --git a/contrib/bind9/bin/named/query.c b/contrib/bind9/bin/named/query.c
index 5cafbc9..ffd9b35 100644
--- a/contrib/bind9/bin/named/query.c
+++ b/contrib/bind9/bin/named/query.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: query.c,v 1.257.18.46 2008/10/15 22:33:01 marka Exp $ */
+/* $Id: query.c,v 1.313.20.7 2009/03/13 01:38:51 marka Exp $ */
 
 /*! \file */
 
@@ -23,7 +23,9 @@
 
 #include <string.h>
 
+#include <isc/hex.h>
 #include <isc/mem.h>
+#include <isc/stats.h>
 #include <isc/util.h>
 
 #include <dns/adb.h>
@@ -36,6 +38,7 @@
 #include <dns/events.h>
 #include <dns/message.h>
 #include <dns/ncache.h>
+#include <dns/nsec3.h>
 #include <dns/order.h>
 #include <dns/rdata.h>
 #include <dns/rdataclass.h>
@@ -89,6 +92,10 @@
 #define SECURE(c)		(((c)->query.attributes & \
 				  NS_QUERYATTR_SECURE) != 0)
 
+/*% No QNAME Proof? */
+#define NOQNAME(r)		(((r)->attributes & \
+				  DNS_RDATASETATTR_NOQNAME) != 0)
+
 #if 0
 #define CTRACE(m)       isc_log_write(ns_g_lctx, \
 				      NS_LOGCATEGORY_CLIENT, \
@@ -114,68 +121,96 @@ typedef struct client_additionalctx {
 	dns_rdataset_t *rdataset;
 } client_additionalctx_t;
 
-static void
+static isc_result_t
 query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype);
 
 static isc_boolean_t
 validate(ns_client_t *client, dns_db_t *db, dns_name_t *name,
 	 dns_rdataset_t *rdataset, dns_rdataset_t *sigrdataset);
 
+static void
+query_findclosestnsec3(dns_name_t *qname, dns_db_t *db,
+		       dns_dbversion_t *version, ns_client_t *client,
+		       dns_rdataset_t *rdataset, dns_rdataset_t *sigrdataset,
+		       dns_name_t *fname, isc_boolean_t exact,
+		       dns_name_t *found);
+
+static inline void
+log_queryerror(ns_client_t *client, isc_result_t result, int line, int level);
+
 /*%
  * Increment query statistics counters.
  */
 static inline void
-inc_stats(ns_client_t *client, dns_statscounter_t counter) {
+inc_stats(ns_client_t *client, isc_statscounter_t counter) {
 	dns_zone_t *zone = client->query.authzone;
 
-	REQUIRE(counter < DNS_STATS_NCOUNTERS);
-
-	ns_g_server->querystats[counter]++;
+	isc_stats_increment(ns_g_server->nsstats, counter);
 
 	if (zone != NULL) {
-		isc_uint64_t *zonestats = dns_zone_getstatscounters(zone);
+		isc_stats_t *zonestats = dns_zone_getrequeststats(zone);
 		if (zonestats != NULL)
-			zonestats[counter]++;
+			isc_stats_increment(zonestats, counter);
 	}
 }
 
 static void
 query_send(ns_client_t *client) {
-	dns_statscounter_t counter;
+	isc_statscounter_t counter;
+	if ((client->message->flags & DNS_MESSAGEFLAG_AA) == 0)
+		inc_stats(client, dns_nsstatscounter_nonauthans);
+	else
+		inc_stats(client, dns_nsstatscounter_authans);
 	if (client->message->rcode == dns_rcode_noerror) {
 		if (ISC_LIST_EMPTY(client->message->sections[DNS_SECTION_ANSWER])) {
 			if (client->query.isreferral) {
-				counter = dns_statscounter_referral;
+				counter = dns_nsstatscounter_referral;
 			} else {
-				counter = dns_statscounter_nxrrset;
+				counter = dns_nsstatscounter_nxrrset;
 			}
 		} else {
-			counter = dns_statscounter_success;
+			counter = dns_nsstatscounter_success;
 		}
 	} else if (client->message->rcode == dns_rcode_nxdomain) {
-		counter = dns_statscounter_nxdomain;
+		counter = dns_nsstatscounter_nxdomain;
 	} else {
 		/* We end up here in case of YXDOMAIN, and maybe others */
-		counter = dns_statscounter_failure;
+		counter = dns_nsstatscounter_failure;
 	}
 	inc_stats(client, counter);
 	ns_client_send(client);
 }
 
 static void
-query_error(ns_client_t *client, isc_result_t result) {
-	inc_stats(client, dns_statscounter_failure);
+query_error(ns_client_t *client, isc_result_t result, int line) {
+	int loglevel = ISC_LOG_DEBUG(3);
+
+	switch (result) {
+	case DNS_R_SERVFAIL:
+		loglevel = ISC_LOG_DEBUG(1);
+		inc_stats(client, dns_nsstatscounter_servfail);
+		break;
+	case DNS_R_FORMERR:
+		inc_stats(client, dns_nsstatscounter_formerr);
+		break;
+	default:
+		inc_stats(client, dns_nsstatscounter_failure);
+		break;
+	}
+
+	log_queryerror(client, result, line, loglevel);
+
 	ns_client_error(client, result);
 }
 
 static void
 query_next(ns_client_t *client, isc_result_t result) {
 	if (result == DNS_R_DUPLICATE)
-		inc_stats(client, dns_statscounter_duplicate);
+		inc_stats(client, dns_nsstatscounter_duplicate);
 	else if (result == DNS_R_DROP)
-		inc_stats(client, dns_statscounter_dropped);
+		inc_stats(client, dns_nsstatscounter_dropped);
 	else
-		inc_stats(client, dns_statscounter_failure);
+		inc_stats(client, dns_nsstatscounter_failure);
 	ns_client_next(client, result);
 }
 
@@ -640,7 +675,8 @@ query_validatezonedb(ns_client_t *client, dns_name_t *name,
 	if (check_acl) {
 		isc_boolean_t log = ISC_TF((options & DNS_GETDB_NOLOG) == 0);
 
-		result = ns_client_checkaclsilent(client, queryacl, ISC_TRUE);
+		result = ns_client_checkaclsilent(client, NULL, queryacl,
+						  ISC_TRUE);
 		if (log) {
 			char msg[NS_CLIENT_ACLMSGSIZE("query")];
 			if (result == ISC_R_SUCCESS) {
@@ -804,7 +840,7 @@ query_getcachedb(ns_client_t *client, dns_name_t *name, dns_rdatatype_t qtype,
 		isc_boolean_t log = ISC_TF((options & DNS_GETDB_NOLOG) == 0);
 		char msg[NS_CLIENT_ACLMSGSIZE("query (cache)")];
 
-		result = ns_client_checkaclsilent(client,
+		result = ns_client_checkaclsilent(client, NULL,
 						  client->view->queryacl,
 						  ISC_TRUE);
 		if (result == ISC_R_SUCCESS) {
@@ -940,7 +976,7 @@ query_getdb(ns_client_t *client, dns_name_t *name, dns_rdatatype_t qtype,
 				 zonep, dbp, versionp);
 #endif
 
-	/* If successfull, Transfer ownership of zone. */
+	/* If successful, Transfer ownership of zone. */
 	if (result == ISC_R_SUCCESS) {
 #ifdef DLZ
 		*zonep = zone;
@@ -1086,8 +1122,12 @@ query_addadditional(void *arg, dns_name_t *name, dns_rdatatype_t qtype) {
 	result = dns_db_find(db, name, version, type, client->query.dboptions,
 			     client->now, &node, fname, rdataset,
 			     sigrdataset);
-	if (result == ISC_R_SUCCESS)
+	if (result == ISC_R_SUCCESS) {
+		if (sigrdataset != NULL && !dns_db_issecure(db) &&
+		    dns_rdataset_isassociated(sigrdataset))
+			dns_rdataset_disassociate(sigrdataset);
 		goto found;
+	}
 
 	if (dns_rdataset_isassociated(rdataset))
 		dns_rdataset_disassociate(rdataset);
@@ -1157,7 +1197,7 @@ query_addadditional(void *arg, dns_name_t *name, dns_rdatatype_t qtype) {
 		goto cleanup;
 
 	/*
-	 * Don't poision caches using the bailiwick protection model.
+	 * Don't poison caches using the bailiwick protection model.
 	 */
 	if (!dns_name_issubdomain(name, dns_db_origin(client->query.gluedb)))
 		goto cleanup;
@@ -1631,7 +1671,7 @@ query_addadditional2(void *arg, dns_name_t *name, dns_rdatatype_t qtype) {
 		goto cleanup;
 
 	/*
-	 * Don't poision caches using the bailiwick protection model.
+	 * Don't poison caches using the bailiwick protection model.
 	 */
 	if (!dns_name_issubdomain(name, dns_db_origin(client->query.gluedb)))
 		goto cleanup;
@@ -2024,7 +2064,7 @@ query_addsoa(ns_client_t *client, dns_db_t *db, dns_dbversion_t *version,
 		eresult = DNS_R_SERVFAIL;
 		goto cleanup;
 	}
-	if (WANTDNSSEC(client)) {
+	if (WANTDNSSEC(client) && dns_db_issecure(db)) {
 		sigrdataset = query_newrdataset(client);
 		if (sigrdataset == NULL) {
 			eresult = DNS_R_SERVFAIL;
@@ -2142,7 +2182,7 @@ query_addns(ns_client_t *client, dns_db_t *db, dns_dbversion_t *version) {
 		eresult = DNS_R_SERVFAIL;
 		goto cleanup;
 	}
-	if (WANTDNSSEC(client)) {
+	if (WANTDNSSEC(client) && dns_db_issecure(db)) {
 		sigrdataset = query_newrdataset(client);
 		if (sigrdataset == NULL) {
 			CTRACE("query_addns: query_newrdataset failed");
@@ -2268,7 +2308,8 @@ query_addcnamelike(ns_client_t *client, dns_name_t *qname, dns_name_t *tname,
  */
 static void
 mark_secure(ns_client_t *client, dns_db_t *db, dns_name_t *name,
-	    dns_rdataset_t *rdataset, dns_rdataset_t *sigrdataset)
+	    isc_uint32_t ttl, dns_rdataset_t *rdataset,
+	    dns_rdataset_t *sigrdataset)
 {
 	isc_result_t result;
 	dns_dbnode_t *node = NULL;
@@ -2282,6 +2323,18 @@ mark_secure(ns_client_t *client, dns_db_t *db, dns_name_t *name,
 	result = dns_db_findnode(db, name, ISC_TRUE, &node);
 	if (result != ISC_R_SUCCESS)
 		return;
+	/*
+	 * Bound the validated ttls then minimise.
+	 */
+	if (sigrdataset->ttl > ttl)
+		sigrdataset->ttl = ttl;
+	if (rdataset->ttl > ttl)
+		rdataset->ttl = ttl;
+	if (rdataset->ttl > sigrdataset->ttl)
+		rdataset->ttl = sigrdataset->ttl;
+	else
+		sigrdataset->ttl = rdataset->ttl;
+
 	(void)dns_db_addrdataset(db, node, NULL, client->now, rdataset,
 				 0, NULL);
 	(void)dns_db_addrdataset(db, node, NULL, client->now, sigrdataset,
@@ -2291,7 +2344,7 @@ mark_secure(ns_client_t *client, dns_db_t *db, dns_name_t *name,
 
 /*
  * Find the secure key that corresponds to rrsig.
- * Note: 'keyrdataset' maintains state between sucessive calls,
+ * Note: 'keyrdataset' maintains state between successive calls,
  * there may be multiple keys with the same keyid.
  * Return ISC_FALSE if we have exhausted all the possible keys.
  */
@@ -2405,8 +2458,9 @@ validate(ns_client_t *client, dns_db_t *db, dns_name_t *name,
 				   client->view->acceptexpired)) {
 				dst_key_free(&key);
 				dns_rdataset_disassociate(&keyrdataset);
-				mark_secure(client, db, name, rdataset,
-					    sigrdataset);
+				mark_secure(client, db, name,
+					    rrsig.originalttl,
+					    rdataset, sigrdataset);
 				return (ISC_TRUE);
 			}
 			dst_key_free(&key);
@@ -2592,12 +2646,36 @@ query_addbestns(ns_client_t *client) {
 }
 
 static void
+fixrdataset(ns_client_t *client, dns_rdataset_t **rdataset) {
+	if (*rdataset == NULL)
+		*rdataset = query_newrdataset(client);
+	else  if (dns_rdataset_isassociated(*rdataset))
+		dns_rdataset_disassociate(*rdataset);
+}
+
+static void
+fixfname(ns_client_t *client, dns_name_t **fname, isc_buffer_t **dbuf,
+	 isc_buffer_t *nbuf)
+{
+	if (*fname == NULL) {
+		*dbuf = query_getnamebuf(client);
+		if (*dbuf == NULL)
+			return;
+		*fname = query_newname(client, *dbuf, nbuf);
+	}
+}
+
+static void
 query_addds(ns_client_t *client, dns_db_t *db, dns_dbnode_t *node,
-	    dns_dbversion_t *version)
+	    dns_dbversion_t *version, dns_name_t *name)
 {
+	dns_fixedname_t fixed;
+	dns_name_t *fname = NULL;
 	dns_name_t *rname;
 	dns_rdataset_t *rdataset, *sigrdataset;
+	isc_buffer_t *dbuf, b;
 	isc_result_t result;
+	unsigned int count;
 
 	CTRACE("query_addds");
 	rname = NULL;
@@ -2618,16 +2696,17 @@ query_addds(ns_client_t *client, dns_db_t *db, dns_dbnode_t *node,
 	result = dns_db_findrdataset(db, node, version, dns_rdatatype_ds, 0,
 				     client->now, rdataset, sigrdataset);
 	/*
-	 * If we didn't find it, look for an NSEC. */
+	 * If we didn't find it, look for an NSEC.
+	 */
 	if (result == ISC_R_NOTFOUND)
 		result = dns_db_findrdataset(db, node, version,
 					     dns_rdatatype_nsec, 0, client->now,
 					     rdataset, sigrdataset);
 	if (result != ISC_R_SUCCESS && result != ISC_R_NOTFOUND)
-		goto cleanup;
+		goto addnsec3;
 	if (!dns_rdataset_isassociated(rdataset) ||
 	    !dns_rdataset_isassociated(sigrdataset))
-		goto cleanup;
+		goto addnsec3;
 
 	/*
 	 * We've already added the NS record, so if the name's not there,
@@ -2649,12 +2728,60 @@ query_addds(ns_client_t *client, dns_db_t *db, dns_dbnode_t *node,
 	ISC_LIST_APPEND(rname->list, sigrdataset, link);
 	rdataset = NULL;
 	sigrdataset = NULL;
+	return;
+
+   addnsec3:
+	if (dns_db_iscache(db))
+		goto cleanup;
+	/*
+	 * Add the NSEC3 which proves the DS does not exist.
+	 */
+	dbuf = query_getnamebuf(client);
+	if (dbuf == NULL)
+		goto cleanup;
+	fname = query_newname(client, dbuf, &b);
+	dns_fixedname_init(&fixed);
+	if (dns_rdataset_isassociated(rdataset))
+		dns_rdataset_disassociate(rdataset);
+	if (dns_rdataset_isassociated(sigrdataset))
+		dns_rdataset_disassociate(sigrdataset);
+	query_findclosestnsec3(name, db, version, client, rdataset,
+			       sigrdataset, fname, ISC_TRUE,
+			       dns_fixedname_name(&fixed));
+	if (!dns_rdataset_isassociated(rdataset))
+		goto cleanup;
+	query_addrrset(client, &fname, &rdataset, &sigrdataset, dbuf,
+		       DNS_SECTION_AUTHORITY);
+	/*
+	 * Did we find the closest provable encloser instead?
+	 * If so add the nearest to the closest provable encloser.
+	 */
+	if (!dns_name_equal(name, dns_fixedname_name(&fixed))) {
+		count = dns_name_countlabels(dns_fixedname_name(&fixed)) + 1;
+		dns_name_getlabelsequence(name,
+					  dns_name_countlabels(name) - count,
+					  count, dns_fixedname_name(&fixed));
+		fixfname(client, &fname, &dbuf, &b);
+		fixrdataset(client, &rdataset);
+		fixrdataset(client, &sigrdataset);
+		if (fname == NULL || rdataset == NULL || sigrdataset == NULL)
+				goto cleanup;
+		query_findclosestnsec3(dns_fixedname_name(&fixed), db, version,
+				       client, rdataset, sigrdataset, fname,
+				       ISC_FALSE, NULL);
+		if (!dns_rdataset_isassociated(rdataset))
+			goto cleanup;
+		query_addrrset(client, &fname, &rdataset, &sigrdataset, dbuf,
+			       DNS_SECTION_AUTHORITY);
+	}
 
  cleanup:
 	if (rdataset != NULL)
 		query_putrdataset(client, &rdataset);
 	if (sigrdataset != NULL)
 		query_putrdataset(client, &sigrdataset);
+	if (fname != NULL)
+		query_releasename(client, &fname);
 }
 
 static void
@@ -2669,12 +2796,14 @@ query_addwildcardproof(ns_client_t *client, dns_db_t *db,
 	dns_name_t *wname;
 	dns_dbnode_t *node;
 	unsigned int options;
-	unsigned int olabels, nlabels;
+	unsigned int olabels, nlabels, labels;
 	isc_result_t result;
 	dns_rdata_t rdata = DNS_RDATA_INIT;
 	dns_rdata_nsec_t nsec;
 	isc_boolean_t have_wname;
 	int order;
+	dns_fixedname_t cfixed;
+	dns_name_t *cname;
 
 	CTRACE("query_addwildcardproof");
 	fname = NULL;
@@ -2683,7 +2812,7 @@ query_addwildcardproof(ns_client_t *client, dns_db_t *db,
 	node = NULL;
 
 	/*
-	 * Get the NOQNAME proof then if !ispositve
+	 * Get the NOQNAME proof then if !ispositive
 	 * get the NOWILDCARD proof.
 	 *
 	 * DNS_DBFIND_NOWILD finds the NSEC records that covers the
@@ -2745,7 +2874,115 @@ query_addwildcardproof(ns_client_t *client, dns_db_t *db,
 			     0, &node, fname, rdataset, sigrdataset);
 	if (node != NULL)
 		dns_db_detachnode(db, &node);
-	if (result == DNS_R_NXDOMAIN) {
+
+	if (!dns_rdataset_isassociated(rdataset)) {
+		/*
+		 * No NSEC proof available, return NSEC3 proofs instead.
+		 */
+		dns_fixedname_init(&cfixed);
+		cname = dns_fixedname_name(&cfixed);
+		/*
+		 * Find the closest encloser.
+		 */
+		dns_name_copy(name, cname, NULL);
+		while (result == DNS_R_NXDOMAIN) {
+			labels = dns_name_countlabels(cname) - 1;
+			dns_name_split(cname, labels, NULL, cname);
+			result = dns_db_find(db, cname, version,
+					     dns_rdatatype_nsec,
+					     options, 0, NULL, fname,
+					     NULL, NULL);
+		}
+		/*
+		 * Add closest (provable) encloser NSEC3.
+		 */
+		query_findclosestnsec3(cname, db, NULL, client, rdataset,
+				       sigrdataset, fname, ISC_TRUE, cname);
+		if (!dns_rdataset_isassociated(rdataset))
+			goto cleanup;
+		query_addrrset(client, &fname, &rdataset, &sigrdataset,
+			       dbuf, DNS_SECTION_AUTHORITY);
+
+		/*
+		 * Replace resources which were consumed by query_addrrset.
+		 */
+		if (fname == NULL) {
+			dbuf = query_getnamebuf(client);
+			if (dbuf == NULL)
+				goto cleanup;
+			fname = query_newname(client, dbuf, &b);
+		}
+
+		if (rdataset == NULL)
+			rdataset = query_newrdataset(client);
+		else if (dns_rdataset_isassociated(rdataset))
+			dns_rdataset_disassociate(rdataset);
+
+		if (sigrdataset == NULL)
+			sigrdataset = query_newrdataset(client);
+		else if (dns_rdataset_isassociated(sigrdataset))
+			dns_rdataset_disassociate(sigrdataset);
+
+		if (fname == NULL || rdataset == NULL || sigrdataset == NULL)
+			goto cleanup;
+		/*
+		 * Add no qname proof.
+		 */
+		labels = dns_name_countlabels(cname) + 1;
+		if (dns_name_countlabels(name) == labels)
+			dns_name_copy(name, wname, NULL);
+		else
+			dns_name_split(name, labels, NULL, wname);
+
+		query_findclosestnsec3(wname, db, NULL, client, rdataset,
+				       sigrdataset, fname, ISC_FALSE, NULL);
+		if (!dns_rdataset_isassociated(rdataset))
+			goto cleanup;
+		query_addrrset(client, &fname, &rdataset, &sigrdataset,
+			       dbuf, DNS_SECTION_AUTHORITY);
+
+		if (ispositive)
+			goto cleanup;
+
+		/*
+		 * Replace resources which were consumed by query_addrrset.
+		 */
+		if (fname == NULL) {
+			dbuf = query_getnamebuf(client);
+			if (dbuf == NULL)
+				goto cleanup;
+			fname = query_newname(client, dbuf, &b);
+		}
+
+		if (rdataset == NULL)
+			rdataset = query_newrdataset(client);
+		else if (dns_rdataset_isassociated(rdataset))
+			dns_rdataset_disassociate(rdataset);
+
+		if (sigrdataset == NULL)
+			sigrdataset = query_newrdataset(client);
+		else if (dns_rdataset_isassociated(sigrdataset))
+			dns_rdataset_disassociate(sigrdataset);
+
+		if (fname == NULL || rdataset == NULL || sigrdataset == NULL)
+			goto cleanup;
+		/*
+		 * Add the no wildcard proof.
+		 */
+		result = dns_name_concatenate(dns_wildcardname,
+					      cname, wname, NULL);
+		if (result != ISC_R_SUCCESS)
+			goto cleanup;
+
+		query_findclosestnsec3(wname, db, NULL, client, rdataset,
+				       sigrdataset, fname, ISC_FALSE, NULL);
+		if (!dns_rdataset_isassociated(rdataset))
+			goto cleanup;
+		query_addrrset(client, &fname, &rdataset, &sigrdataset,
+			       dbuf, DNS_SECTION_AUTHORITY);
+
+		goto cleanup;
+	} else if (result == DNS_R_NXDOMAIN) {
 		if (!ispositive)
 			result = dns_rdataset_first(rdataset);
 		if (result == ISC_R_SUCCESS) {
@@ -2822,6 +3059,7 @@ query_addnxrrsetnsec(ns_client_t *client, dns_db_t *db,
 
 	if (sigrdatasetp == NULL)
 		return;
+
 	sigrdataset = *sigrdatasetp;
 	if (sigrdataset == NULL || !dns_rdataset_isassociated(sigrdataset))
 		return;
@@ -2862,8 +3100,12 @@ query_addnxrrsetnsec(ns_client_t *client, dns_db_t *db,
 static void
 query_resume(isc_task_t *task, isc_event_t *event) {
 	dns_fetchevent_t *devent = (dns_fetchevent_t *)event;
+	dns_fetch_t *fetch;
 	ns_client_t *client;
-	isc_boolean_t fetch_cancelled, client_shuttingdown;
+	isc_boolean_t fetch_canceled, client_shuttingdown;
+	isc_result_t result;
+	isc_logcategory_t *logcategory = NS_LOGCATEGORY_QUERY_EERRORS;
+	int errorloglevel;
 
 	/*
 	 * Resume a query after recursion.
@@ -2884,30 +3126,31 @@ query_resume(isc_task_t *task, isc_event_t *event) {
 		 */
 		INSIST(devent->fetch == client->query.fetch);
 		client->query.fetch = NULL;
-		fetch_cancelled = ISC_FALSE;
+		fetch_canceled = ISC_FALSE;
 		/*
 		 * Update client->now.
 		 */
 		isc_stdtime_get(&client->now);
 	} else {
 		/*
-		 * This is a fetch completion event for a cancelled fetch.
+		 * This is a fetch completion event for a canceled fetch.
 		 * Clean up and don't resume the find.
 		 */
-		fetch_cancelled = ISC_TRUE;
+		fetch_canceled = ISC_TRUE;
 	}
 	UNLOCK(&client->query.fetchlock);
 	INSIST(client->query.fetch == NULL);
 
 	client->query.attributes &= ~NS_QUERYATTR_RECURSING;
-	dns_resolver_destroyfetch(&devent->fetch);
+	fetch = devent->fetch;
+	devent->fetch = NULL;
 
 	/*
 	 * If this client is shutting down, or this transaction
 	 * has timed out, do not resume the find.
 	 */
 	client_shuttingdown = ns_client_shuttingdown(client);
-	if (fetch_cancelled || client_shuttingdown) {
+	if (fetch_canceled || client_shuttingdown) {
 		if (devent->node != NULL)
 			dns_db_detachnode(devent->db, &devent->node);
 		if (devent->db != NULL)
@@ -2916,8 +3159,8 @@ query_resume(isc_task_t *task, isc_event_t *event) {
 		if (devent->sigrdataset != NULL)
 			query_putrdataset(client, &devent->sigrdataset);
 		isc_event_free(&event);
-		if (fetch_cancelled)
-			query_error(client, DNS_R_SERVFAIL);
+		if (fetch_canceled)
+			query_error(client, DNS_R_SERVFAIL, __LINE__);
 		else
 			query_next(client, ISC_R_CANCELED);
 		/*
@@ -2925,8 +3168,22 @@ query_resume(isc_task_t *task, isc_event_t *event) {
 		 */
 		ns_client_detach(&client);
 	} else {
-		query_find(client, devent, 0);
+		result = query_find(client, devent, 0);
+		if (result != ISC_R_SUCCESS) {
+			if (result == DNS_R_SERVFAIL)
+				errorloglevel = ISC_LOG_DEBUG(2);
+			else
+				errorloglevel = ISC_LOG_DEBUG(4);
+			if (isc_log_wouldlog(ns_g_lctx, errorloglevel)) {
+				dns_resolver_logfetch(fetch, ns_g_lctx,
+						      logcategory,
+						      NS_LOGMODULE_QUERY,
+						      errorloglevel, ISC_FALSE);
+			}
+		}
 	}
+
+	dns_resolver_destroyfetch(&fetch);
 }
 
 static isc_result_t
@@ -2938,7 +3195,7 @@ query_recurse(ns_client_t *client, dns_rdatatype_t qtype, dns_name_t *qdomain,
 	isc_sockaddr_t *peeraddr;
 
 	if (!resuming)
-		inc_stats(client, dns_statscounter_recursion);
+		inc_stats(client, dns_nsstatscounter_recursion);
 
 	/*
 	 * We are about to recurse, which means that this client will
@@ -3053,6 +3310,7 @@ query_recurse(ns_client_t *client, dns_rdatatype_t qtype, dns_name_t *qdomain,
 do { \
 	eresult = r; \
 	want_restart = ISC_FALSE; \
+	line = __LINE__; \
 } while (0)
 
 /*
@@ -3144,35 +3402,60 @@ static void
 query_addnoqnameproof(ns_client_t *client, dns_rdataset_t *rdataset) {
 	isc_buffer_t *dbuf, b;
 	dns_name_t *fname;
-	dns_rdataset_t *nsec, *nsecsig;
+	dns_rdataset_t *neg, *negsig;
 	isc_result_t result = ISC_R_NOMEMORY;
 
 	CTRACE("query_addnoqnameproof");
 
 	fname = NULL;
-	nsec = NULL;
-	nsecsig = NULL;
+	neg = NULL;
+	negsig = NULL;
 
 	dbuf = query_getnamebuf(client);
 	if (dbuf == NULL)
 		goto cleanup;
 	fname = query_newname(client, dbuf, &b);
-	nsec = query_newrdataset(client);
-	nsecsig = query_newrdataset(client);
-	if (fname == NULL || nsec == NULL || nsecsig == NULL)
+	neg = query_newrdataset(client);
+	negsig = query_newrdataset(client);
+	if (fname == NULL || neg == NULL || negsig == NULL)
 		goto cleanup;
 
-	result = dns_rdataset_getnoqname(rdataset, fname, nsec, nsecsig);
+	result = dns_rdataset_getnoqname(rdataset, fname, neg, negsig);
 	RUNTIME_CHECK(result == ISC_R_SUCCESS);
 
-	query_addrrset(client, &fname, &nsec, &nsecsig, dbuf,
+	query_addrrset(client, &fname, &neg, &negsig, dbuf,
+		       DNS_SECTION_AUTHORITY);
+
+	if ((rdataset->attributes & DNS_RDATASETATTR_CLOSEST) == 0)
+		goto cleanup;
+
+	if (fname == NULL) {
+		dbuf = query_getnamebuf(client);
+		if (dbuf == NULL)
+			goto cleanup;
+		fname = query_newname(client, dbuf, &b);
+	}
+	if (neg == NULL)
+		neg = query_newrdataset(client);
+	else if (dns_rdataset_isassociated(neg))
+		dns_rdataset_disassociate(neg);
+	if (negsig == NULL)
+		negsig = query_newrdataset(client);
+	else if (dns_rdataset_isassociated(negsig))
+		dns_rdataset_disassociate(negsig);
+	if (fname == NULL || neg == NULL || negsig == NULL)
+		goto cleanup;
+	result = dns_rdataset_getclosest(rdataset, fname, neg, negsig);
+	RUNTIME_CHECK(result == ISC_R_SUCCESS);
+
+	query_addrrset(client, &fname, &neg, &negsig, dbuf,
 		       DNS_SECTION_AUTHORITY);
 
  cleanup:
-	if (nsec != NULL)
-		query_putrdataset(client, &nsec);
-	if (nsecsig != NULL)
-		query_putrdataset(client, &nsecsig);
+	if (neg != NULL)
+		query_putrdataset(client, &neg);
+	if (negsig != NULL)
+		query_putrdataset(client, &negsig);
 	if (fname != NULL)
 		query_releasename(client, &fname);
 }
@@ -3292,8 +3575,7 @@ warn_rfc1918(ns_client_t *client, dns_name_t *fname, dns_rdataset_t *rdataset) {
 			RUNTIME_CHECK(result == ISC_R_SUCCESS);
 			dns_rdataset_current(&found, &rdata);
 			result = dns_rdata_tostruct(&rdata, &soa, NULL);
-			if (result != ISC_R_SUCCESS)
-				return;
+			RUNTIME_CHECK(result == ISC_R_SUCCESS);
 			if (dns_name_equal(&soa.origin, &prisoner) &&
 			    dns_name_equal(&soa.contact, &hostmaster)) {
 				char buf[DNS_NAME_FORMATSIZE];
@@ -3310,12 +3592,101 @@ warn_rfc1918(ns_client_t *client, dns_name_t *fname, dns_rdataset_t *rdataset) {
 	}
 }
 
+static void
+query_findclosestnsec3(dns_name_t *qname, dns_db_t *db,
+		       dns_dbversion_t *version, ns_client_t *client,
+		       dns_rdataset_t *rdataset, dns_rdataset_t *sigrdataset,
+		       dns_name_t *fname, isc_boolean_t exact,
+		       dns_name_t *found)
+{
+	unsigned char salt[256];
+	size_t salt_length = sizeof(salt);
+	isc_uint16_t iterations;
+	isc_result_t result;
+	unsigned int dboptions;
+	dns_fixedname_t fixed;
+	dns_hash_t hash;
+	dns_name_t name;
+	int order;
+	unsigned int count;
+	dns_rdata_nsec3_t nsec3;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	isc_boolean_t optout;
+
+	salt_length = sizeof(salt);
+	result = dns_db_getnsec3parameters(db, version, &hash, NULL,
+					   &iterations, salt, &salt_length);
+	if (result != ISC_R_SUCCESS)
+		return;
+
+	dns_name_init(&name, NULL);
+	dns_name_clone(qname, &name);
+
+	/*
+	 * Map unknown algorithm to known value.
+	 */
+	if (hash == DNS_NSEC3_UNKNOWNALG)
+		hash = 1;
+
+ again:
+	dns_fixedname_init(&fixed);
+	result = dns_nsec3_hashname(&fixed, NULL, NULL, &name,
+				    dns_db_origin(db), hash,
+				    iterations, salt, salt_length);
+	if (result != ISC_R_SUCCESS)
+		return;
+
+	dboptions = client->query.dboptions | DNS_DBFIND_FORCENSEC3;
+	result = dns_db_find(db, dns_fixedname_name(&fixed), version,
+			     dns_rdatatype_nsec3, dboptions, client->now,
+			     NULL, fname, rdataset, sigrdataset);
+
+	if (result == DNS_R_NXDOMAIN) {
+		if (!dns_rdataset_isassociated(rdataset)) {
+			return;
+		}
+		result = dns_rdataset_first(rdataset);
+		INSIST(result == ISC_R_SUCCESS);
+		dns_rdataset_current(rdataset, &rdata);
+		dns_rdata_tostruct(&rdata, &nsec3, NULL);
+		dns_rdata_reset(&rdata);
+		optout = ISC_TF((nsec3.flags & DNS_NSEC3FLAG_OPTOUT) != 0);
+		if (found != NULL && optout &&
+		    dns_name_fullcompare(&name, dns_db_origin(db), &order,
+					 &count) == dns_namereln_subdomain) {
+			dns_rdataset_disassociate(rdataset);
+			if (dns_rdataset_isassociated(sigrdataset))
+				dns_rdataset_disassociate(sigrdataset);
+			count = dns_name_countlabels(&name) - 1;
+			dns_name_getlabelsequence(&name, 1, count, &name);
+			ns_client_log(client, DNS_LOGCATEGORY_DNSSEC,
+				      NS_LOGMODULE_QUERY, ISC_LOG_DEBUG(3),
+				      "looking for closest provable encloser");
+			goto again;
+		}
+		if (exact)
+			ns_client_log(client, DNS_LOGCATEGORY_DNSSEC,
+				      NS_LOGMODULE_QUERY, ISC_LOG_WARNING,
+				      "expected a exact match NSEC3, got "
+				      "a covering record");
+
+	} else if (result != ISC_R_SUCCESS) {
+		return;
+	} else if (!exact)
+		ns_client_log(client, DNS_LOGCATEGORY_DNSSEC,
+			      NS_LOGMODULE_QUERY, ISC_LOG_WARNING,
+			      "expected covering NSEC3, got an exact match");
+	if (found != NULL)
+		dns_name_copy(&name, found, NULL);
+	return;
+}
+
 /*
  * Do the bulk of query processing for the current query of 'client'.
  * If 'event' is non-NULL, we are returning from recursion and 'qtype'
  * is ignored.  Otherwise, 'qtype' is the query type.
  */
-static void
+static isc_result_t
 query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 {
 	dns_db_t *db, *zdb;
@@ -3336,7 +3707,7 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 	isc_result_t result, eresult;
 	dns_fixedname_t fixed;
 	dns_fixedname_t wildcardname;
-	dns_dbversion_t *version;
+	dns_dbversion_t *version, *zversion;
 	dns_zone_t *zone;
 	dns_rdata_cname_t cname;
 	dns_rdata_dname_t dname;
@@ -3344,6 +3715,7 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 	isc_boolean_t empty_wild;
 	dns_rdataset_t *noqname;
 	isc_boolean_t resuming;
+	int line = -1;
 
 	CTRACE("query_find");
 
@@ -3361,6 +3733,7 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 	zrdataset = NULL;
 	sigrdataset = NULL;
 	zsigrdataset = NULL;
+	zversion = NULL;
 	node = NULL;
 	db = NULL;
 	zdb = NULL;
@@ -3500,6 +3873,11 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 	}
 	if (result != ISC_R_SUCCESS) {
 		if (result == DNS_R_REFUSED) {
+			if (WANTRECURSION(client)) {
+				inc_stats(client,
+					  dns_nsstatscounter_recurserej);
+			} else
+				inc_stats(client, dns_nsstatscounter_authrej);
 			if (!PARTIALANSWER(client))
 				QUERY_ERROR(DNS_R_REFUSED);
 		} else
@@ -3544,7 +3922,7 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 		QUERY_ERROR(DNS_R_SERVFAIL);
 		goto cleanup;
 	}
-	if (WANTDNSSEC(client)) {
+	if (WANTDNSSEC(client) && (!is_zone || dns_db_issecure(db))) {
 		sigrdataset = query_newrdataset(client);
 		if (sigrdataset == NULL) {
 			QUERY_ERROR(DNS_R_SERVFAIL);
@@ -3685,6 +4063,12 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 			 * We're authoritative for an ancestor of QNAME.
 			 */
 			if (!USECACHE(client) || !RECURSIONOK(client)) {
+				dns_fixedname_t fixed;
+
+				dns_fixedname_init(&fixed);
+				dns_name_copy(fname,
+					      dns_fixedname_name(&fixed), NULL);
+
 				/*
 				 * If we don't have a cache, this is the best
 				 * answer.
@@ -3718,8 +4102,9 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 					       &rdataset, sigrdatasetp,
 					       dbuf, DNS_SECTION_AUTHORITY);
 				client->query.gluedb = NULL;
-				if (WANTDNSSEC(client) && dns_db_issecure(db))
-					query_addds(client, db, node, version);
+				if (WANTDNSSEC(client))
+					query_addds(client, db, node, version,
+						   dns_fixedname_name(&fixed));
 			} else {
 				/*
 				 * We might have a better answer or delegation
@@ -3738,6 +4123,7 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 				zsigrdataset = sigrdataset;
 				sigrdataset = NULL;
 				dns_db_detachnode(db, &node);
+				zversion = version;
 				version = NULL;
 				db = NULL;
 				dns_db_attach(client->view->cachedb, &db);
@@ -3771,6 +4157,8 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 				zrdataset = NULL;
 				sigrdataset = zsigrdataset;
 				zsigrdataset = NULL;
+				version = zversion;
+				zversion = NULL;
 				/*
 				 * We don't clean up zdb here because we
 				 * may still need it.  It will get cleaned
@@ -3799,6 +4187,11 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 				else
 					QUERY_ERROR(DNS_R_SERVFAIL);
 			} else {
+				dns_fixedname_t fixed;
+
+				dns_fixedname_init(&fixed);
+				dns_name_copy(fname,
+					      dns_fixedname_name(&fixed), NULL);
 				/*
 				 * This is the best answer.
 				 */
@@ -3825,7 +4218,8 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 				client->query.attributes &=
 					~NS_QUERYATTR_CACHEGLUEOK;
 				if (WANTDNSSEC(client))
-					query_addds(client, db, node, version);
+					query_addds(client, db, node, version,
+						   dns_fixedname_name(&fixed));
 			}
 		}
 		goto cleanup;
@@ -3834,6 +4228,80 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 		/* FALLTHROUGH */
 	case DNS_R_NXRRSET:
 		INSIST(is_zone);
+		/*
+		 * Look for a NSEC3 record if we don't have a NSEC record.
+		 */
+		if (!dns_rdataset_isassociated(rdataset) &&
+		     WANTDNSSEC(client)) {
+			if ((fname->attributes & DNS_NAMEATTR_WILDCARD) == 0) {
+				dns_name_t *found;
+				dns_name_t *qname;
+
+				dns_fixedname_init(&fixed);
+				found = dns_fixedname_name(&fixed);
+				qname = client->query.qname;
+
+				query_findclosestnsec3(qname, db, version,
+						       client, rdataset,
+						       sigrdataset, fname,
+						       ISC_TRUE, found);
+				/*
+				 * Did we find the closest provable encloser
+				 * instead? If so add the nearest to the
+				 * closest provable encloser.
+				 */
+				if (found &&
+				    dns_rdataset_isassociated(rdataset) &&
+				    !dns_name_equal(qname, found))
+				{
+					unsigned int count;
+					unsigned int skip;
+
+					/*
+					 * Add the closest provable encloser.
+					 */
+					query_addrrset(client, &fname,
+						       &rdataset, &sigrdataset,
+						       dbuf,
+						       DNS_SECTION_AUTHORITY);
+
+					count = dns_name_countlabels(found)
+							 + 1;
+					skip = dns_name_countlabels(qname) -
+							 count;
+					dns_name_getlabelsequence(qname, skip,
+								  count,
+								  found);
+
+					fixfname(client, &fname, &dbuf, &b);
+					fixrdataset(client, &rdataset);
+					fixrdataset(client, &sigrdataset);
+					if (fname == NULL ||
+					    rdataset == NULL ||
+					    sigrdataset == NULL) {
+						QUERY_ERROR(DNS_R_SERVFAIL);
+						goto cleanup;
+					}
+					/*
+					 * 'nearest' doesn't exist so
+					 * 'exist' is set to ISC_FALSE.
+					 */
+					query_findclosestnsec3(found, db,
+							       version,
+							       client,
+							       rdataset,
+							       sigrdataset,
+							       fname,
+							       ISC_FALSE,
+							       NULL);
+				}
+			} else {
+				query_releasename(client, &fname);
+				query_addwildcardproof(client, db, version,
+						       client->query.qname,
+						       ISC_FALSE);
+			}
+		}
 		if (dns_rdataset_isassociated(rdataset)) {
 			/*
 			 * If we've got a NSEC record, we need to save the
@@ -3841,7 +4309,7 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 			 * below, and it needs to use the name buffer.
 			 */
 			query_keepname(client, fname, dbuf);
-		} else {
+		} else if (fname != NULL) {
 			/*
 			 * We're not going to use fname, and need to release
 			 * our hold on the name buffer so query_addsoa()
@@ -3867,9 +4335,11 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 						     &sigrdataset);
 		}
 		goto cleanup;
+
 	case DNS_R_EMPTYWILD:
 		empty_wild = ISC_TRUE;
 		/* FALLTHROUGH */
+
 	case DNS_R_NXDOMAIN:
 		INSIST(is_zone);
 		if (dns_rdataset_isassociated(rdataset)) {
@@ -3879,7 +4349,7 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 			 * below, and it needs to use the name buffer.
 			 */
 			query_keepname(client, fname, dbuf);
-		} else {
+		} else if (fname != NULL) {
 			/*
 			 * We're not going to use fname, and need to release
 			 * our hold on the name buffer so query_addsoa()
@@ -3905,19 +4375,19 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 			QUERY_ERROR(result);
 			goto cleanup;
 		}
-		/*
-		 * Add NSEC record if we found one.
-		 */
-		if (dns_rdataset_isassociated(rdataset)) {
-			if (WANTDNSSEC(client)) {
+
+		if (WANTDNSSEC(client)) {
+			/*
+			 * Add NSEC record if we found one.
+			 */
+			if (dns_rdataset_isassociated(rdataset))
 				query_addrrset(client, &fname, &rdataset,
 					       &sigrdataset,
 					       NULL, DNS_SECTION_AUTHORITY);
-				query_addwildcardproof(client, db, version,
-						       client->query.qname,
-						       ISC_FALSE);
-			}
+			query_addwildcardproof(client, db, version,
+					       client->query.qname, ISC_FALSE);
 		}
+
 		/*
 		 * Set message rcode.
 		 */
@@ -3926,6 +4396,7 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 		else
 			client->message->rcode = dns_rcode_nxdomain;
 		goto cleanup;
+
 	case DNS_R_NCACHENXDOMAIN:
 	case DNS_R_NCACHENXRRSET:
 		INSIST(!is_zone);
@@ -3954,6 +4425,7 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 		fname = NULL;
 		rdataset = NULL;
 		goto cleanup;
+
 	case DNS_R_CNAME:
 		/*
 		 * Keep a copy of the rdataset.  We have to do this because
@@ -3976,8 +4448,7 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 				      NULL);
 			need_wildcardproof = ISC_TRUE;
 		}
-		if ((rdataset->attributes & DNS_RDATASETATTR_NOQNAME) != 0 &&
-		     WANTDNSSEC(client))
+		if (NOQNAME(rdataset) && WANTDNSSEC(client))
 			noqname = rdataset;
 		else
 			noqname = NULL;
@@ -4185,17 +4656,32 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 		result = dns_rdatasetiter_first(rdsiter);
 		while (result == ISC_R_SUCCESS) {
 			dns_rdatasetiter_current(rdsiter, rdataset);
-			if ((qtype == dns_rdatatype_any ||
+			if (is_zone && qtype == dns_rdatatype_any &&
+			    !dns_db_issecure(db) &&
+			    dns_rdatatype_isdnssec(rdataset->type)) {
+				/*
+				 * The zone is transitioning from insecure
+				 * to secure. Hide the dnssec records from
+				 * ANY queries.
+				 */
+				dns_rdataset_disassociate(rdataset);
+			} else if ((qtype == dns_rdatatype_any ||
 			     rdataset->type == qtype) && rdataset->type != 0) {
+				if (NOQNAME(rdataset) && WANTDNSSEC(client))
+					noqname = rdataset;
+				else
+					noqname = NULL;
 				query_addrrset(client,
 					       fname != NULL ? &fname : &tname,
 					       &rdataset, NULL,
 					       NULL, DNS_SECTION_ANSWER);
+				if (noqname != NULL)
+					query_addnoqnameproof(client, noqname);
 				n++;
 				INSIST(tname != NULL);
 				/*
-				 * rdataset is non-NULL only in certain pathological
-				 * cases involving DNAMEs.
+				 * rdataset is non-NULL only in certain
+				 * pathological cases involving DNAMEs.
 				 */
 				if (rdataset != NULL)
 					query_putrdataset(client, &rdataset);
@@ -4214,7 +4700,7 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 		if (fname != NULL)
 			dns_message_puttempname(client->message, &fname);
 
-		if (n == 0) {
+		if (n == 0 && is_zone) {
 			/*
 			 * We didn't match any rdatasets.
 			 */
@@ -4275,8 +4761,7 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 			sigrdatasetp = &sigrdataset;
 		else
 			sigrdatasetp = NULL;
-		if ((rdataset->attributes & DNS_RDATASETATTR_NOQNAME) != 0 &&
-		     WANTDNSSEC(client))
+		if (NOQNAME(rdataset) && WANTDNSSEC(client))
 			noqname = rdataset;
 		else
 			noqname = NULL;
@@ -4388,7 +4873,8 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 			 * or if the client requested recursion and thus wanted
 			 * the complete answer, send an error response.
 			 */
-			query_error(client, eresult);
+			INSIST(line >= 0);
+			query_error(client, eresult, line);
 		}
 		ns_client_detach(&client);
 	} else if (!RECURSING(client)) {
@@ -4405,7 +4891,7 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 		 * is in the glue sort it to the start of the additional
 		 * section.
 		 */
-		if (client->message->counts[DNS_SECTION_ANSWER] == 0 &&
+		if (ISC_LIST_EMPTY(client->message->sections[DNS_SECTION_ANSWER]) &&
 		    client->message->rcode == dns_rcode_noerror &&
 		    (qtype == dns_rdatatype_a || qtype == dns_rdatatype_aaaa))
 			answer_in_glue(client, qtype);
@@ -4414,14 +4900,26 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
 		    client->view->auth_nxdomain == ISC_TRUE)
 			client->message->flags |= DNS_MESSAGEFLAG_AA;
 
+		/*
+		 * If the response is somehow unexpected for the client and this
+		 * is a result of recursion, return an error to the caller
+		 * to indicate it may need to be logged.
+		 */
+		if (resuming &&
+		    (ISC_LIST_EMPTY(client->message->sections[DNS_SECTION_ANSWER]) ||
+		     client->message->rcode != dns_rcode_noerror))
+			eresult = ISC_R_FAILURE;
+
 		query_send(client);
 		ns_client_detach(&client);
 	}
 	CTRACE("query_find: done");
+
+	return (eresult);
 }
 
 static inline void
-log_query(ns_client_t *client) {
+log_query(ns_client_t *client, unsigned int flags, unsigned int extflags) {
 	char namebuf[DNS_NAME_FORMATSIZE];
 	char typename[DNS_RDATATYPE_FORMATSIZE];
 	char classname[DNS_RDATACLASS_FORMATSIZE];
@@ -4438,10 +4936,54 @@ log_query(ns_client_t *client) {
 	dns_rdatatype_format(rdataset->type, typename, sizeof(typename));
 
 	ns_client_log(client, NS_LOGCATEGORY_QUERIES, NS_LOGMODULE_QUERY,
-		      level, "query: %s %s %s %s%s%s", namebuf, classname,
+		      level, "query: %s %s %s %s%s%s%s%s", namebuf, classname,
 		      typename, WANTRECURSION(client) ? "+" : "-",
 		      (client->signer != NULL) ? "S": "",
-		      (client->opt != NULL) ? "E" : "");
+		      (client->opt != NULL) ? "E" : "",
+		      ((extflags & DNS_MESSAGEEXTFLAG_DO) != 0) ? "D" : "",
+		      ((flags & DNS_MESSAGEFLAG_CD) != 0) ? "C" : "");
+}
+
+static inline void
+log_queryerror(ns_client_t *client, isc_result_t result, int line, int level) {
+	char namebuf[DNS_NAME_FORMATSIZE];
+	char typename[DNS_RDATATYPE_FORMATSIZE];
+	char classname[DNS_RDATACLASS_FORMATSIZE];
+	const char *namep, *typep, *classp, *sep1, *sep2;
+	dns_rdataset_t *rdataset;
+
+	if (!isc_log_wouldlog(ns_g_lctx, level))
+		return;
+
+	namep = typep = classp = sep1 = sep2 = "";
+
+	/*
+	 * Query errors can happen for various reasons.  In some cases we cannot
+	 * even assume the query contains a valid question section, so we should
+	 * expect exceptional cases.
+	 */
+	if (client->query.origqname != NULL) {
+		dns_name_format(client->query.origqname, namebuf,
+				sizeof(namebuf));
+		namep = namebuf;
+		sep1 = " for ";
+
+		rdataset = ISC_LIST_HEAD(client->query.origqname->list);
+		if (rdataset != NULL) {
+			dns_rdataclass_format(rdataset->rdclass, classname,
+					      sizeof(classname));
+			classp = classname;
+			dns_rdatatype_format(rdataset->type, typename,
+					     sizeof(typename));
+			typep = typename;
+			sep2 = "/";
+		}
+	}
+
+	ns_client_log(client, NS_LOGCATEGORY_QUERY_EERRORS, NS_LOGMODULE_QUERY,
+		      level, "query failed (%s)%s%s%s%s%s%s at %s:%d",
+		      isc_result_totext(result), sep1, namep, sep2,
+		      classp, sep2, typep, __FILE__, line);
 }
 
 void
@@ -4451,11 +4993,19 @@ ns_query_start(ns_client_t *client) {
 	dns_rdataset_t *rdataset;
 	ns_client_t *qclient;
 	dns_rdatatype_t qtype;
+	unsigned int saved_extflags = client->extflags;
+	unsigned int saved_flags = client->message->flags;
 	isc_boolean_t want_ad;
 
 	CTRACE("ns_query_start");
 
 	/*
+	 * Test only.
+	 */
+	if (ns_g_clienttest && (client->attributes & NS_CLIENTATTR_TCP) == 0)
+		RUNTIME_CHECK(ns_client_replace(client) == ISC_R_SUCCESS);
+
+	/*
 	 * Ensure that appropriate cleanups occur.
 	 */
 	client->next = query_next_callback;
@@ -4504,7 +5054,7 @@ ns_query_start(ns_client_t *client) {
 	 */
 	result = dns_message_firstname(message, DNS_SECTION_QUESTION);
 	if (result != ISC_R_SUCCESS) {
-		query_error(client, result);
+		query_error(client, result, __LINE__);
 		return;
 	}
 	dns_message_currentname(message, DNS_SECTION_QUESTION,
@@ -4517,20 +5067,20 @@ ns_query_start(ns_client_t *client) {
 			 * There's more than one QNAME in the question
 			 * section.
 			 */
-			query_error(client, DNS_R_FORMERR);
+			query_error(client, DNS_R_FORMERR, __LINE__);
 		} else
-			query_error(client, result);
+			query_error(client, result, __LINE__);
 		return;
 	}
 
 	if (ns_g_server->log_queries)
-		log_query(client);
+		log_query(client, saved_flags, saved_extflags);
 
 	/*
 	 * Check for multiple question queries, since edns1 is dead.
 	 */
 	if (message->counts[DNS_SECTION_QUESTION] > 1) {
-		query_error(client, DNS_R_FORMERR);
+		query_error(client, DNS_R_FORMERR, __LINE__);
 		return;
 	}
 
@@ -4540,6 +5090,7 @@ ns_query_start(ns_client_t *client) {
 	rdataset = ISC_LIST_HEAD(client->query.qname->list);
 	INSIST(rdataset != NULL);
 	qtype = rdataset->type;
+	dns_rdatatypestats_increment(ns_g_server->rcvquerystats, qtype);
 	if (dns_rdatatype_ismeta(qtype)) {
 		switch (qtype) {
 		case dns_rdatatype_any:
@@ -4550,7 +5101,7 @@ ns_query_start(ns_client_t *client) {
 			return;
 		case dns_rdatatype_maila:
 		case dns_rdatatype_mailb:
-			query_error(client, DNS_R_NOTIMP);
+			query_error(client, DNS_R_NOTIMP, __LINE__);
 			return;
 		case dns_rdatatype_tkey:
 			result = dns_tkey_processquery(client->message,
@@ -4559,15 +5110,22 @@ ns_query_start(ns_client_t *client) {
 			if (result == ISC_R_SUCCESS)
 				query_send(client);
 			else
-				query_error(client, result);
+				query_error(client, result, __LINE__);
 			return;
 		default: /* TSIG, etc. */
-			query_error(client, DNS_R_FORMERR);
+			query_error(client, DNS_R_FORMERR, __LINE__);
 			return;
 		}
 	}
 
 	/*
+	 * Turn on minimal response for DNSKEY queries.
+	 */
+	if (qtype == dns_rdatatype_dnskey)
+		client->query.attributes |= (NS_QUERYATTR_NOAUTHORITY |
+					     NS_QUERYATTR_NOADDITIONAL);
+
+	/*
 	 * If the client has requested that DNSSEC checking be disabled,
 	 * allow lookups to return pending data and instruct the resolver
 	 * to return data before validation has completed.
@@ -4623,5 +5181,5 @@ ns_query_start(ns_client_t *client) {
 
 	qclient = NULL;
 	ns_client_attach(client, &qclient);
-	query_find(qclient, NULL, qtype);
+	(void)query_find(qclient, NULL, qtype);
 }
diff --git a/contrib/bind9/bin/named/server.c b/contrib/bind9/bin/named/server.c
index 784ff94..e685e18 100644
--- a/contrib/bind9/bin/named/server.c
+++ b/contrib/bind9/bin/named/server.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: server.c,v 1.419.18.68 2008/09/04 23:46:08 tbox Exp $ */
+/* $Id: server.c,v 1.520.12.7 2009/01/30 03:53:38 marka Exp $ */
 
 /*! \file */
 
@@ -30,17 +30,20 @@
 #include <isc/entropy.h>
 #include <isc/file.h>
 #include <isc/hash.h>
+#include <isc/httpd.h>
 #include <isc/lex.h>
 #include <isc/parseint.h>
 #include <isc/portset.h>
 #include <isc/print.h>
 #include <isc/resource.h>
 #include <isc/socket.h>
+#include <isc/stats.h>
 #include <isc/stdio.h>
 #include <isc/string.h>
 #include <isc/task.h>
 #include <isc/timer.h>
 #include <isc/util.h>
+#include <isc/xml.h>
 
 #include <isccfg/namedconf.h>
 
@@ -63,6 +66,7 @@
 #include <dns/order.h>
 #include <dns/peer.h>
 #include <dns/portlist.h>
+#include <dns/rbt.h>
 #include <dns/rdataclass.h>
 #include <dns/rdataset.h>
 #include <dns/rdatastruct.h>
@@ -71,6 +75,7 @@
 #include <dns/secalg.h>
 #include <dns/stats.h>
 #include <dns/tkey.h>
+#include <dns/tsig.h>
 #include <dns/view.h>
 #include <dns/zone.h>
 #include <dns/zt.h>
@@ -88,6 +93,7 @@
 #include <named/main.h>
 #include <named/os.h>
 #include <named/server.h>
+#include <named/statschannel.h>
 #include <named/tkeyconf.h>
 #include <named/tsigconf.h>
 #include <named/zoneconf.h>
@@ -101,12 +107,12 @@
  * using it has a 'result' variable and a 'cleanup' label.
  */
 #define CHECK(op) \
-	do { result = (op); 				  	 \
-	       if (result != ISC_R_SUCCESS) goto cleanup; 	 \
+	do { result = (op);					 \
+	       if (result != ISC_R_SUCCESS) goto cleanup;	 \
 	} while (0)
 
 #define CHECKM(op, msg) \
-	do { result = (op); 				  	  \
+	do { result = (op);					  \
 	       if (result != ISC_R_SUCCESS) {			  \
 			isc_log_write(ns_g_lctx,		  \
 				      NS_LOGCATEGORY_GENERAL,	  \
@@ -119,7 +125,7 @@
 	} while (0)						  \
 
 #define CHECKMF(op, msg, file) \
-	do { result = (op); 				  	  \
+	do { result = (op);					  \
 	       if (result != ISC_R_SUCCESS) {			  \
 			isc_log_write(ns_g_lctx,		  \
 				      NS_LOGCATEGORY_GENERAL,	  \
@@ -132,7 +138,7 @@
 	} while (0)						  \
 
 #define CHECKFATAL(op, msg) \
-	do { result = (op); 				  	  \
+	do { result = (op);					  \
 	       if (result != ISC_R_SUCCESS)			  \
 			fatal(msg, result);			  \
 	} while (0)						  \
@@ -209,7 +215,7 @@ static const struct {
 	/* Local IPv6 Unicast Addresses */
 	{ "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA", ISC_FALSE },
 	{ "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA", ISC_FALSE },
-	/* LOCALLY ASSIGNED LOCAL ADDRES S SCOPE */
+	/* LOCALLY ASSIGNED LOCAL ADDRESS SCOPE */
 	{ "D.F.IP6.ARPA", ISC_FALSE },
 	{ "8.E.F.IP6.ARPA", ISC_FALSE },	/* LINK LOCAL */
 	{ "9.E.F.IP6.ARPA", ISC_FALSE },	/* LINK LOCAL */
@@ -251,9 +257,8 @@ static void
 end_reserved_dispatches(ns_server_t *server, isc_boolean_t all);
 
 /*%
- * Configure a single view ACL at '*aclp'.  Get its configuration by
- * calling 'getvcacl' (for per-view configuration) and maybe 'getscacl'
- * (for a global default).
+ * Configure a single view ACL at '*aclp'.  Get its configuration from
+ * 'vconfig' (for per-view configuration) and maybe from 'config'
  */
 static isc_result_t
 configure_view_acl(const cfg_obj_t *vconfig, const cfg_obj_t *config,
@@ -280,12 +285,56 @@ configure_view_acl(const cfg_obj_t *vconfig, const cfg_obj_t *config,
 	(void)ns_config_get(maps, aclname, &aclobj);
 	if (aclobj == NULL)
 		/*
-		 * No value available.  *aclp == NULL.
+		 * No value available.	*aclp == NULL.
 		 */
 		return (ISC_R_SUCCESS);
 
 	result = cfg_acl_fromconfig(aclobj, config, ns_g_lctx,
-				    actx, mctx, aclp);
+				    actx, mctx, 0, aclp);
+
+	return (result);
+}
+
+
+/*%
+ * Configure a sortlist at '*aclp'.  Essentially the same as
+ * configure_view_acl() except it calls cfg_acl_fromconfig with a
+ * nest_level value of 2.
+ */
+static isc_result_t
+configure_view_sortlist(const cfg_obj_t *vconfig, const cfg_obj_t *config,
+			cfg_aclconfctx_t *actx, isc_mem_t *mctx,
+			dns_acl_t **aclp)
+{
+	isc_result_t result;
+	const cfg_obj_t *maps[3];
+	const cfg_obj_t *aclobj = NULL;
+	int i = 0;
+
+	if (*aclp != NULL)
+		dns_acl_detach(aclp);
+	if (vconfig != NULL)
+		maps[i++] = cfg_tuple_get(vconfig, "options");
+	if (config != NULL) {
+		const cfg_obj_t *options = NULL;
+		(void)cfg_map_get(config, "options", &options);
+		if (options != NULL)
+			maps[i++] = options;
+	}
+	maps[i] = NULL;
+
+	(void)ns_config_get(maps, "sortlist", &aclobj);
+	if (aclobj == NULL)
+		return (ISC_R_SUCCESS);
+
+	/*
+	 * Use a nest level of 3 for the "top level" of the sortlist;
+	 * this means each entry in the top three levels will be stored
+	 * as lists of separate, nested ACLs, rather than merged together
+	 * into IP tables as is usually done with ACLs.
+	 */
+	result = cfg_acl_fromconfig(aclobj, config, ns_g_lctx,
+				    actx, mctx, 3, aclp);
 
 	return (result);
 }
@@ -398,7 +447,7 @@ configure_view_dnsseckey(const cfg_obj_t *vconfig, const cfg_obj_t *key,
  * the security roots.
  *
  * The per-view configuration values and the server-global defaults are read
- * from 'vconfig' and 'config'.  The variable to be configured is '*target'.
+ * from 'vconfig' and 'config'.	 The variable to be configured is '*target'.
  */
 static isc_result_t
 configure_view_dnsseckeys(const cfg_obj_t *vconfig, const cfg_obj_t *config,
@@ -694,6 +743,11 @@ configure_peer(const cfg_obj_t *cpeer, isc_mem_t *mctx, dns_peer_t **peerp) {
 		CHECK(dns_peer_setrequestixfr(peer, cfg_obj_asboolean(obj)));
 
 	obj = NULL;
+	(void)cfg_map_get(cpeer, "request-nsid", &obj);
+	if (obj != NULL)
+		CHECK(dns_peer_setrequestnsid(peer, cfg_obj_asboolean(obj)));
+
+	obj = NULL;
 	(void)cfg_map_get(cpeer, "edns", &obj);
 	if (obj != NULL)
 		CHECK(dns_peer_setsupportedns(peer, cfg_obj_asboolean(obj)));
@@ -901,6 +955,41 @@ check_dbtype(dns_zone_t **zonep, unsigned int dbtypec, const char **dbargv,
 	isc_mem_free(mctx, argv);
 }
 
+static isc_result_t
+setquerystats(dns_zone_t *zone, isc_mem_t *mctx, isc_boolean_t on) {
+	isc_result_t result;
+	isc_stats_t *zoneqrystats;
+
+	zoneqrystats = NULL;
+	if (on) {
+		result = isc_stats_create(mctx, &zoneqrystats,
+					  dns_nsstatscounter_max);
+		if (result != ISC_R_SUCCESS)
+			return (result);
+	}
+	dns_zone_setrequeststats(zone, zoneqrystats);
+	if (zoneqrystats != NULL)
+		isc_stats_detach(&zoneqrystats);
+
+	return (ISC_R_SUCCESS);
+}
+
+static isc_boolean_t
+cache_reusable(dns_view_t *originview, dns_view_t *view,
+	       isc_boolean_t new_zero_no_soattl)
+{
+	if (originview->checknames != view->checknames ||
+	    dns_resolver_getzeronosoattl(originview->resolver) !=
+	    new_zero_no_soattl ||
+	    originview->acceptexpired != view->acceptexpired ||
+	    originview->enablevalidation != view->enablevalidation ||
+	    originview->maxcachettl != view->maxcachettl ||
+	    originview->maxncachettl != view->maxncachettl) {
+		return (ISC_FALSE);
+	}
+
+	return (ISC_TRUE);
+}
 
 /*
  * Configure 'view' according to 'vconfig', taking defaults from 'config'
@@ -947,7 +1036,7 @@ configure_view(dns_view_t *view, const cfg_obj_t *config,
 	const char *str;
 	dns_order_t *order = NULL;
 	isc_uint32_t udpsize;
-	unsigned int check = 0;
+	unsigned int resopts = 0;
 	dns_zone_t *zone = NULL;
 	isc_uint32_t max_clients_per_query;
 	const char *sep = ": view ";
@@ -956,6 +1045,9 @@ configure_view(dns_view_t *view, const cfg_obj_t *config,
 	isc_boolean_t rfc1918;
 	isc_boolean_t empty_zones_enable;
 	const cfg_obj_t *disablelist = NULL;
+	isc_stats_t *resstats = NULL;
+	dns_stats_t *resquerystats = NULL;
+	isc_boolean_t zero_no_soattl;
 
 	REQUIRE(DNS_VIEW_VALID(view));
 
@@ -1005,6 +1097,7 @@ configure_view(dns_view_t *view, const cfg_obj_t *config,
 		CHECK(isc_mem_create(0, 0, &cmctx));
 		CHECK(dns_acache_create(&view->acache, cmctx, ns_g_taskmgr,
 					ns_g_timermgr));
+		isc_mem_setname(cmctx, "acache", NULL);
 		isc_mem_detach(&cmctx);
 	}
 	if (view->acache != NULL) {
@@ -1096,17 +1189,70 @@ configure_view(dns_view_t *view, const cfg_obj_t *config,
 #endif
 
 	/*
+	 * Obtain configuration parameters that affect the decision of whether
+	 * we can reuse/share an existing cache.
+	 */
+	/* Check-names. */
+	obj = NULL;
+	result = ns_checknames_get(maps, "response", &obj);
+	INSIST(result == ISC_R_SUCCESS);
+
+	str = cfg_obj_asstring(obj);
+	if (strcasecmp(str, "fail") == 0) {
+		resopts |= DNS_RESOLVER_CHECKNAMES |
+			DNS_RESOLVER_CHECKNAMESFAIL;
+		view->checknames = ISC_TRUE;
+	} else if (strcasecmp(str, "warn") == 0) {
+		resopts |= DNS_RESOLVER_CHECKNAMES;
+		view->checknames = ISC_FALSE;
+	} else if (strcasecmp(str, "ignore") == 0) {
+		view->checknames = ISC_FALSE;
+	} else
+		INSIST(0);
+
+	obj = NULL;
+	result = ns_config_get(maps, "zero-no-soa-ttl-cache", &obj);
+	INSIST(result == ISC_R_SUCCESS);
+	zero_no_soattl = cfg_obj_asboolean(obj);
+
+	obj = NULL;
+	result = ns_config_get(maps, "dnssec-accept-expired", &obj);
+	INSIST(result == ISC_R_SUCCESS);
+	view->acceptexpired = cfg_obj_asboolean(obj);
+
+	obj = NULL;
+	result = ns_config_get(maps, "dnssec-validation", &obj);
+	INSIST(result == ISC_R_SUCCESS);
+	view->enablevalidation = cfg_obj_asboolean(obj);
+
+	obj = NULL;
+	result = ns_config_get(maps, "max-cache-ttl", &obj);
+	INSIST(result == ISC_R_SUCCESS);
+	view->maxcachettl = cfg_obj_asuint32(obj);
+
+	obj = NULL;
+	result = ns_config_get(maps, "max-ncache-ttl", &obj);
+	INSIST(result == ISC_R_SUCCESS);
+	view->maxncachettl = cfg_obj_asuint32(obj);
+	if (view->maxncachettl > 7 * 24 * 3600)
+		view->maxncachettl = 7 * 24 * 3600;
+
+	/*
 	 * Configure the view's cache.  Try to reuse an existing
 	 * cache if possible, otherwise create a new cache.
 	 * Note that the ADB is not preserved in either case.
+	 * When a matching view is found, the associated statistics are
+	 * also retrieved and reused.
 	 *
-	 * XXX Determining when it is safe to reuse a cache is
-	 * tricky.  When the view's configuration changes, the cached
-	 * data may become invalid because it reflects our old
-	 * view of the world.  As more view attributes become
-	 * configurable, we will have to add code here to check
-	 * whether they have changed in ways that could
-	 * invalidate the cache.
+	 * XXX Determining when it is safe to reuse a cache is tricky.
+	 * When the view's configuration changes, the cached data may become
+	 * invalid because it reflects our old view of the world.  We check
+	 * some of the configuration parameters that could invalidate the cache,
+	 * but there are other configuration options that should be checked.
+	 * For example, if a view uses a forwarder, changes in the forwarder
+	 * configuration may invalidate the cache.  At the moment, it's the
+	 * administrator's responsibility to ensure these configuration options
+	 * don't invalidate reusing.
 	 */
 	result = dns_viewlist_find(&ns_g_server->viewlist,
 				   view->name, view->rdclass,
@@ -1114,17 +1260,29 @@ configure_view(dns_view_t *view, const cfg_obj_t *config,
 	if (result != ISC_R_NOTFOUND && result != ISC_R_SUCCESS)
 		goto cleanup;
 	if (pview != NULL) {
-		INSIST(pview->cache != NULL);
-		isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
-			      NS_LOGMODULE_SERVER, ISC_LOG_DEBUG(3),
-			      "reusing existing cache");
-		reused_cache = ISC_TRUE;
-		dns_cache_attach(pview->cache, &cache);
+		if (cache_reusable(pview, view, zero_no_soattl)) {
+			INSIST(pview->cache != NULL);
+			isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
+				      NS_LOGMODULE_SERVER, ISC_LOG_DEBUG(3),
+				      "reusing existing cache");
+			reused_cache = ISC_TRUE;
+			dns_cache_attach(pview->cache, &cache);
+		} else {
+			isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
+				      NS_LOGMODULE_SERVER, ISC_LOG_DEBUG(1),
+				      "cache cannot be reused for view %s "
+				      "due to configuration parameter mismatch",
+				      view->name);
+		}
+		dns_view_getresstats(pview, &resstats);
+		dns_view_getresquerystats(pview, &resquerystats);
 		dns_view_detach(&pview);
-	} else {
+	}
+	if (cache == NULL) {
 		CHECK(isc_mem_create(0, 0, &cmctx));
 		CHECK(dns_cache_create(cmctx, ns_g_taskmgr, ns_g_timermgr,
 				       view->rdclass, "rbt", 0, NULL, &cache));
+		isc_mem_setname(cmctx, "cache", NULL);
 	}
 	dns_view_setcache(view, cache);
 
@@ -1170,27 +1328,6 @@ configure_view(dns_view_t *view, const cfg_obj_t *config,
 	dns_cache_detach(&cache);
 
 	/*
-	 * Check-names.
-	 */
-	obj = NULL;
-	result = ns_checknames_get(maps, "response", &obj);
-	INSIST(result == ISC_R_SUCCESS);
-
-	str = cfg_obj_asstring(obj);
-	if (strcasecmp(str, "fail") == 0) {
-		check = DNS_RESOLVER_CHECKNAMES |
-			DNS_RESOLVER_CHECKNAMESFAIL;
-		view->checknames = ISC_TRUE;
-	} else if (strcasecmp(str, "warn") == 0) {
-		check = DNS_RESOLVER_CHECKNAMES;
-		view->checknames = ISC_FALSE;
-	} else if (strcasecmp(str, "ignore") == 0) {
-		check = 0;
-		view->checknames = ISC_FALSE;
-	} else
-		INSIST(0);
-
-	/*
 	 * Resolver.
 	 *
 	 * XXXRTH  Hardwired number of tasks.
@@ -1210,9 +1347,18 @@ configure_view(dns_view_t *view, const cfg_obj_t *config,
 	}
 	CHECK(dns_view_createresolver(view, ns_g_taskmgr, 31,
 				      ns_g_socketmgr, ns_g_timermgr,
-				      check, ns_g_dispatchmgr,
+				      resopts, ns_g_dispatchmgr,
 				      dispatch4, dispatch6));
 
+	if (resstats == NULL) {
+		CHECK(isc_stats_create(mctx, &resstats,
+				       dns_resstatscounter_max));
+	}
+	dns_view_setresstats(view, resstats);
+	if (resquerystats == NULL)
+		CHECK(dns_rdatatypestats_create(mctx, &resquerystats));
+	dns_view_setresquerystats(view, resquerystats);
+
 	/*
 	 * Set the ADB cache size to 1/8th of the max-cache-size.
 	 */
@@ -1235,11 +1381,6 @@ configure_view(dns_view_t *view, const cfg_obj_t *config,
 		lame_ttl = 1800;
 	dns_resolver_setlamettl(view->resolver, lame_ttl);
 
-	obj = NULL;
-	result = ns_config_get(maps, "zero-no-soa-ttl-cache", &obj);
-	INSIST(result == ISC_R_SUCCESS);
-	dns_resolver_setzeronosoattl(view->resolver, cfg_obj_asboolean(obj));
-
 	/*
 	 * Set the resolver's EDNS UDP size.
 	 */
@@ -1460,28 +1601,26 @@ configure_view(dns_view_t *view, const cfg_obj_t *config,
 	}
 
 	/*
-	 * Set "allow-query-cache" and "allow-recursion" acls if
+	 * Set "allow-query-cache", "allow-query-cache-on",
+	 * "allow-recursion", and "allow-recursion-on" acls if
 	 * configured in named.conf.
 	 */
 	CHECK(configure_view_acl(vconfig, config, "allow-query-cache",
 				 actx, ns_g_mctx, &view->queryacl));
-
-	if (strcmp(view->name, "_bind") != 0)
+	CHECK(configure_view_acl(vconfig, config, "allow-query-cache-on",
+				 actx, ns_g_mctx, &view->queryonacl));
+	if (view->queryonacl == NULL)
+		CHECK(configure_view_acl(NULL, ns_g_config,
+					 "allow-query-cache-on", actx,
+					 ns_g_mctx, &view->queryonacl));
+	if (strcmp(view->name, "_bind") != 0) {
 		CHECK(configure_view_acl(vconfig, config, "allow-recursion",
-					 actx, ns_g_mctx, &view->recursionacl));
-
-	/*
-	 * Warning if both "recursion no;" and allow-recursion are active
-	 * except for "allow-recursion { none; };".
-	 */
-	if (!view->recursion && view->recursionacl != NULL &&
-	    (view->recursionacl->length != 1 ||
-	     view->recursionacl->elements[0].type != dns_aclelementtype_any ||
-	     view->recursionacl->elements[0].negative != ISC_TRUE))
-		isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
-			      NS_LOGMODULE_SERVER, ISC_LOG_WARNING,
-			      "both \"recursion no;\" and \"allow-recursion\" "
-			      "active%s%s", forview, viewname);
+					 actx, ns_g_mctx,
+					 &view->recursionacl));
+		CHECK(configure_view_acl(vconfig, config, "allow-recursion-on",
+					 actx, ns_g_mctx,
+					 &view->recursiononacl));
+	}
 
 	/*
 	 * "allow-query-cache" inherits from "allow-recursion" if set,
@@ -1491,25 +1630,66 @@ configure_view(dns_view_t *view, const cfg_obj_t *config,
 	 */
 	if (view->queryacl == NULL && view->recursionacl != NULL)
 		dns_acl_attach(view->recursionacl, &view->queryacl);
-	if (view->queryacl == NULL)
+	if (view->queryacl == NULL && view->recursion)
 		CHECK(configure_view_acl(vconfig, config, "allow-query",
 					 actx, ns_g_mctx, &view->queryacl));
-	if (view->recursionacl == NULL && view->queryacl != NULL)
+	if (view->recursion &&
+	    view->recursionacl == NULL && view->queryacl != NULL)
 		dns_acl_attach(view->queryacl, &view->recursionacl);
 
 	/*
-	 * Set default "allow-recursion" and "allow-query-cache" acls.
+	 * Set default "allow-recursion", "allow-recursion-on" and
+	 * "allow-query-cache" acls.
 	 */
 	if (view->recursionacl == NULL && view->recursion)
-		CHECK(configure_view_acl(NULL, ns_g_config, "allow-recursion",
-					 actx, ns_g_mctx, &view->recursionacl));
-	if (view->queryacl == NULL)
 		CHECK(configure_view_acl(NULL, ns_g_config,
-					 "allow-query-cache", actx,
-					 ns_g_mctx, &view->queryacl));
+					 "allow-recursion",
+					 actx, ns_g_mctx,
+					 &view->recursionacl));
+	if (view->recursiononacl == NULL && view->recursion)
+		CHECK(configure_view_acl(NULL, ns_g_config,
+					 "allow-recursion-on",
+					 actx, ns_g_mctx,
+					 &view->recursiononacl));
+	if (view->queryacl == NULL) {
+		if (view->recursion)
+			CHECK(configure_view_acl(NULL, ns_g_config,
+						 "allow-query-cache", actx,
+						 ns_g_mctx, &view->queryacl));
+		else {
+			if (view->queryacl != NULL)
+				dns_acl_detach(&view->queryacl);
+			CHECK(dns_acl_none(ns_g_mctx, &view->queryacl));
+		}
+	}
+
+	/*
+	 * Configure sortlist, if set
+	 */
+	CHECK(configure_view_sortlist(vconfig, config, actx, ns_g_mctx,
+				      &view->sortlist));
 
-	CHECK(configure_view_acl(vconfig, config, "sortlist",
-				 actx, ns_g_mctx, &view->sortlist));
+	/*
+	 * Configure default allow-transfer, allow-notify, allow-update
+	 * and allow-update-forwarding ACLs, if set, so they can be
+	 * inherited by zones.
+	 */
+	if (view->notifyacl == NULL)
+		CHECK(configure_view_acl(NULL, ns_g_config,
+					 "allow-notify", actx,
+					 ns_g_mctx, &view->notifyacl));
+	if (view->transferacl == NULL)
+		CHECK(configure_view_acl(NULL, ns_g_config,
+					 "allow-transfer", actx,
+					 ns_g_mctx, &view->transferacl));
+	if (view->updateacl == NULL)
+		CHECK(configure_view_acl(NULL, ns_g_config,
+					 "allow-update", actx,
+					 ns_g_mctx, &view->updateacl));
+	if (view->upfwdacl == NULL)
+		CHECK(configure_view_acl(NULL, ns_g_config,
+					 "allow-update-forwarding", actx,
+					 ns_g_mctx, &view->upfwdacl));
 
 	obj = NULL;
 	result = ns_config_get(maps, "request-ixfr", &obj);
@@ -1522,6 +1702,11 @@ configure_view(dns_view_t *view, const cfg_obj_t *config,
 	view->provideixfr = cfg_obj_asboolean(obj);
 
 	obj = NULL;
+	result = ns_config_get(maps, "request-nsid", &obj);
+	INSIST(result == ISC_R_SUCCESS);
+	view->requestnsid = cfg_obj_asboolean(obj);
+
+	obj = NULL;
 	result = ns_config_get(maps, "max-clients-per-query", &obj);
 	INSIST(result == ISC_R_SUCCESS);
 	max_clients_per_query = cfg_obj_asuint32(obj);
@@ -1539,16 +1724,6 @@ configure_view(dns_view_t *view, const cfg_obj_t *config,
 	view->enablednssec = cfg_obj_asboolean(obj);
 
 	obj = NULL;
-	result = ns_config_get(maps, "dnssec-accept-expired", &obj);
-	INSIST(result == ISC_R_SUCCESS);
-	view->acceptexpired = cfg_obj_asboolean(obj);
-
-	obj = NULL;
-	result = ns_config_get(maps, "dnssec-validation", &obj);
-	INSIST(result == ISC_R_SUCCESS);
-	view->enablevalidation = cfg_obj_asboolean(obj);
-
-	obj = NULL;
 	result = ns_config_get(maps, "dnssec-lookaside", &obj);
 	if (result == ISC_R_SUCCESS) {
 		for (element = cfg_list_first(obj);
@@ -1603,18 +1778,6 @@ configure_view(dns_view_t *view, const cfg_obj_t *config,
 		CHECK(mustbesecure(obj, view->resolver));
 
 	obj = NULL;
-	result = ns_config_get(maps, "max-cache-ttl", &obj);
-	INSIST(result == ISC_R_SUCCESS);
-	view->maxcachettl = cfg_obj_asuint32(obj);
-
-	obj = NULL;
-	result = ns_config_get(maps, "max-ncache-ttl", &obj);
-	INSIST(result == ISC_R_SUCCESS);
-	view->maxncachettl = cfg_obj_asuint32(obj);
-	if (view->maxncachettl > 7 * 24 * 3600)
-		view->maxncachettl = 7 * 24 * 3600;
-
-	obj = NULL;
 	result = ns_config_get(maps, "preferred-glue", &obj);
 	if (result == ISC_R_SUCCESS) {
 		str = cfg_obj_asstring(obj);
@@ -1690,6 +1853,7 @@ configure_view(dns_view_t *view, const cfg_obj_t *config,
 		const char *empty_dbtype[4] =
 				    { "_builtin", "empty", NULL, NULL };
 		int empty_dbtypec = 4;
+		isc_boolean_t zonestats_on;
 
 		dns_fixedname_init(&fixed);
 		name = dns_fixedname_name(&fixed);
@@ -1724,6 +1888,11 @@ configure_view(dns_view_t *view, const cfg_obj_t *config,
 		} else
 			empty_dbtype[3] = ".";
 
+		obj = NULL;
+		result = ns_config_get(maps, "zone-statistics", &obj);
+		INSIST(result == ISC_R_SUCCESS);
+		zonestats_on = cfg_obj_asboolean(obj);
+
 		logit = ISC_TRUE;
 		for (empty = empty_zones[empty_zone].zone;
 		     empty != NULL;
@@ -1748,6 +1917,7 @@ configure_view(dns_view_t *view, const cfg_obj_t *config,
 			 */
 			(void)dns_view_findzone(view, name, &zone);
 			if (zone != NULL) {
+				CHECK(setquerystats(zone, mctx, zonestats_on));
 				dns_zone_detach(&zone);
 				continue;
 			}
@@ -1798,6 +1968,8 @@ configure_view(dns_view_t *view, const cfg_obj_t *config,
 				if (zone != NULL) {
 					dns_zone_setview(zone, view);
 					CHECK(dns_view_addzone(view, zone));
+					CHECK(setquerystats(zone, mctx,
+							    zonestats_on));
 					dns_zone_detach(&zone);
 					continue;
 				}
@@ -1809,14 +1981,18 @@ configure_view(dns_view_t *view, const cfg_obj_t *config,
 			CHECK(dns_zonemgr_managezone(ns_g_server->zonemgr, zone));
 			dns_zone_setclass(zone, view->rdclass);
 			dns_zone_settype(zone, dns_zone_master);
+			dns_zone_setstats(zone, ns_g_server->zonestats);
 			CHECK(dns_zone_setdbtype(zone, empty_dbtypec,
 						 empty_dbtype));
 			if (view->queryacl != NULL)
 				dns_zone_setqueryacl(zone, view->queryacl);
+			if (view->queryonacl != NULL)
+				dns_zone_setqueryonacl(zone, view->queryonacl);
 			dns_zone_setdialup(zone, dns_dialuptype_no);
 			dns_zone_setnotifytype(zone, dns_notifytype_no);
 			dns_zone_setoption(zone, DNS_ZONEOPT_NOCHECKNS,
 					   ISC_TRUE);
+			CHECK(setquerystats(zone, mctx, zonestats_on));
 			CHECK(dns_view_addzone(view, zone));
 			isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
 				      NS_LOGMODULE_SERVER, ISC_LOG_INFO,
@@ -1835,6 +2011,10 @@ configure_view(dns_view_t *view, const cfg_obj_t *config,
 		dns_dispatch_detach(&dispatch4);
 	if (dispatch6 != NULL)
 		dns_dispatch_detach(&dispatch6);
+	if (resstats != NULL)
+		isc_stats_detach(&resstats);
+	if (resquerystats != NULL)
+		dns_stats_detach(&resquerystats);
 	if (order != NULL)
 		dns_order_detach(&order);
 	if (cmctx != NULL)
@@ -1959,6 +2139,8 @@ configure_forward(const cfg_obj_t *config, dns_view_t *view, dns_name_t *origin,
 	isc_result_t result;
 	in_port_t port;
 
+	ISC_LIST_INIT(addresses);
+
 	/*
 	 * Determine which port to send forwarded requests to.
 	 */
@@ -1984,8 +2166,6 @@ configure_forward(const cfg_obj_t *config, dns_view_t *view, dns_name_t *origin,
 	if (forwarders != NULL)
 		faddresses = cfg_tuple_get(forwarders, "addresses");
 
-	ISC_LIST_INIT(addresses);
-
 	for (element = cfg_list_first(faddresses);
 	     element != NULL;
 	     element = cfg_list_next(element))
@@ -2283,6 +2463,7 @@ configure_zone(const cfg_obj_t *config, const cfg_obj_t *zconfig,
 		if (view->acache != NULL)
 			dns_zone_setacache(zone, view->acache);
 		CHECK(dns_zonemgr_managezone(ns_g_server->zonemgr, zone));
+		dns_zone_setstats(zone, ns_g_server->zonestats);
 	}
 
 	/*
@@ -2398,25 +2579,23 @@ add_listenelt(isc_mem_t *mctx, ns_listenlist_t *list, isc_sockaddr_t *addr,
 {
 	ns_listenelt_t *lelt = NULL;
 	dns_acl_t *src_acl = NULL;
-	dns_aclelement_t aelt;
 	isc_result_t result;
 	isc_sockaddr_t any_sa6;
+	isc_netaddr_t netaddr;
 
 	REQUIRE(isc_sockaddr_pf(addr) == AF_INET6);
 
 	isc_sockaddr_any6(&any_sa6);
 	if (!isc_sockaddr_equal(&any_sa6, addr) &&
 	    (wcardport_ok || isc_sockaddr_getport(addr) != 0)) {
-		aelt.type = dns_aclelementtype_ipprefix;
-		aelt.negative = ISC_FALSE;
-		aelt.u.ip_prefix.prefixlen = 128;
-		isc_netaddr_fromin6(&aelt.u.ip_prefix.address,
-				    &addr->type.sin6.sin6_addr);
+		isc_netaddr_fromin6(&netaddr, &addr->type.sin6.sin6_addr);
 
-		result = dns_acl_create(mctx, 1, &src_acl);
+		result = dns_acl_create(mctx, 0, &src_acl);
 		if (result != ISC_R_SUCCESS)
 			return (result);
-		result = dns_acl_appendelement(src_acl, &aelt);
+
+		result = dns_iptable_addprefix(src_acl->iptable,
+					       &netaddr, 128, ISC_TRUE);
 		if (result != ISC_R_SUCCESS)
 			goto clean;
 
@@ -2900,6 +3079,9 @@ load_configuration(const char *filename, ns_server_t *server,
 	INSIST(result == ISC_R_SUCCESS);
 	server->aclenv.match_mapped = cfg_obj_asboolean(obj);
 
+	CHECKM(ns_statschannels_configure(ns_g_server, config, &aclconfctx),
+	       "configuring statistics server(s)");
+
 	/*
 	 * Configure sets of UDP query source ports.
 	 */
@@ -3059,11 +3241,13 @@ load_configuration(const char *filename, ns_server_t *server,
 							  ns_g_mctx,
 							  &listenon);
 		} else if (!ns_g_lwresdonly) {
+			isc_boolean_t enable;
 			/*
 			 * Not specified, use default.
 			 */
+			enable = ISC_TF(isc_net_probeipv4() != ISC_R_SUCCESS);
 			CHECK(ns_listenlist_default(ns_g_mctx, listen_port,
-						    ISC_FALSE, &listenon));
+						    enable, &listenon));
 		}
 		if (listenon != NULL) {
 			ns_interfacemgr_setlistenon6(server->interfacemgr,
@@ -3370,8 +3554,17 @@ load_configuration(const char *filename, ns_server_t *server,
 
 	obj = NULL;
 	if (options != NULL &&
-	    cfg_map_get(options, "memstatistics-file", &obj) == ISC_R_SUCCESS)
+	    cfg_map_get(options, "memstatistics", &obj) == ISC_R_SUCCESS)
+		ns_g_memstatistics = cfg_obj_asboolean(obj);
+	else
+		ns_g_memstatistics =
+			ISC_TF((isc_mem_debugging & ISC_MEM_DEBUGRECORD) != 0);
+
+	obj = NULL;
+	if (ns_config_get(maps, "memstatistics-file", &obj) == ISC_R_SUCCESS)
 		ns_main_setmemstats(cfg_obj_asstring(obj));
+	else if (ns_g_memstatistics)
+		ns_main_setmemstats("named.memstats");
 	else
 		ns_main_setmemstats(NULL);
 
@@ -3415,8 +3608,12 @@ load_configuration(const char *filename, ns_server_t *server,
 	result = ns_config_get(maps, "server-id", &obj);
 	server->server_usehostname = ISC_FALSE;
 	if (result == ISC_R_SUCCESS && cfg_obj_isboolean(obj)) {
-		server->server_usehostname = ISC_TRUE;
+		/* The parser translates "hostname" to ISC_TRUE */
+		server->server_usehostname = cfg_obj_asboolean(obj);
+		result = setstring(server, &server->server_id, NULL);
+		RUNTIME_CHECK(result == ISC_R_SUCCESS);
 	} else if (result == ISC_R_SUCCESS) {
+		/* Found a quoted string */
 		CHECKM(setoptstring(server, &server->server_id, obj), "strdup");
 	} else {
 		result = setstring(server, &server->server_id, NULL);
@@ -3555,6 +3752,8 @@ run_server(isc_task_t *task, isc_event_t *event) {
 					  &ns_g_dispatchmgr),
 		   "creating dispatch manager");
 
+	dns_dispatchmgr_setstats(ns_g_dispatchmgr, server->resolverstats);
+
 	CHECKFATAL(ns_interfacemgr_create(ns_g_mctx, ns_g_taskmgr,
 					  ns_g_socketmgr, ns_g_dispatchmgr,
 					  &server->interfacemgr),
@@ -3622,6 +3821,7 @@ shutdown_server(isc_task_t *task, isc_event_t *event) {
 		      ISC_LOG_INFO, "shutting down%s",
 		      flush ? ": flushing changes" : "");
 
+	ns_statschannels_shutdown(server);
 	ns_controls_shutdown(server->controls);
 	end_reserved_dispatches(server, ISC_TRUE);
 
@@ -3742,7 +3942,16 @@ ns_server_create(isc_mem_t *mctx, ns_server_t **serverp) {
 	server->statsfile = isc_mem_strdup(server->mctx, "named.stats");
 	CHECKFATAL(server->statsfile == NULL ? ISC_R_NOMEMORY : ISC_R_SUCCESS,
 		   "isc_mem_strdup");
-	server->querystats = NULL;
+	server->nsstats = NULL;
+	server->rcvquerystats = NULL;
+	server->opcodestats = NULL;
+	server->zonestats = NULL;
+	server->resolverstats = NULL;
+	server->sockstats = NULL;
+	CHECKFATAL(isc_stats_create(server->mctx, &server->sockstats,
+				    isc_sockstatscounter_max),
+		   "isc_stats_create");
+	isc_socketmgr_setstats(ns_g_socketmgr, server->sockstats);
 
 	server->dumpfile = isc_mem_strdup(server->mctx, "named_dump.db");
 	CHECKFATAL(server->dumpfile == NULL ? ISC_R_NOMEMORY : ISC_R_SUCCESS,
@@ -3759,8 +3968,24 @@ ns_server_create(isc_mem_t *mctx, ns_server_t **serverp) {
 	server->server_usehostname = ISC_FALSE;
 	server->server_id = NULL;
 
-	CHECKFATAL(dns_stats_alloccounters(ns_g_mctx, &server->querystats),
-		   "dns_stats_alloccounters");
+	CHECKFATAL(isc_stats_create(ns_g_mctx, &server->nsstats,
+				    dns_nsstatscounter_max),
+		   "dns_stats_create (server)");
+
+	CHECKFATAL(dns_rdatatypestats_create(ns_g_mctx,
+					     &server->rcvquerystats),
+		   "dns_stats_create (rcvquery)");
+
+	CHECKFATAL(dns_opcodestats_create(ns_g_mctx, &server->opcodestats),
+		   "dns_stats_create (opcode)");
+
+	CHECKFATAL(isc_stats_create(ns_g_mctx, &server->zonestats,
+				    dns_zonestatscounter_max),
+		   "dns_stats_create (zone)");
+
+	CHECKFATAL(isc_stats_create(ns_g_mctx, &server->resolverstats,
+				    dns_resstatscounter_max),
+		   "dns_stats_create (resolver)");
 
 	server->flushonshutdown = ISC_FALSE;
 	server->log_queries = ISC_FALSE;
@@ -3771,6 +3996,8 @@ ns_server_create(isc_mem_t *mctx, ns_server_t **serverp) {
 	server->dispatchgen = 0;
 	ISC_LIST_INIT(server->dispatches);
 
+	ISC_LIST_INIT(server->statschannels);
+
 	server->magic = NS_SERVER_MAGIC;
 	*serverp = server;
 }
@@ -3782,7 +4009,12 @@ ns_server_destroy(ns_server_t **serverp) {
 
 	ns_controls_destroy(&server->controls);
 
-	dns_stats_freecounters(server->mctx, &server->querystats);
+	isc_stats_detach(&server->nsstats);
+	dns_stats_detach(&server->rcvquerystats);
+	dns_stats_detach(&server->opcodestats);
+	isc_stats_detach(&server->zonestats);
+	isc_stats_detach(&server->resolverstats);
+	isc_stats_detach(&server->sockstats);
 
 	isc_mem_free(server->mctx, server->statsfile);
 	isc_mem_free(server->mctx, server->dumpfile);
@@ -3936,13 +4168,17 @@ loadconfig(ns_server_t *server) {
 	result = load_configuration(ns_g_lwresdonly ?
 				    lwresd_g_conffile : ns_g_conffile,
 				    server, ISC_FALSE);
-	if (result == ISC_R_SUCCESS)
+	if (result == ISC_R_SUCCESS) {
 		end_reserved_dispatches(server, ISC_FALSE);
-	else
+		isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
+			      NS_LOGMODULE_SERVER, ISC_LOG_INFO,
+			      "reloading configuration succeeded");
+	} else {
 		isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
 			      NS_LOGMODULE_SERVER, ISC_LOG_ERROR,
 			      "reloading configuration failed: %s",
 			      isc_result_totext(result));
+	}
 	return (result);
 }
 
@@ -3952,12 +4188,16 @@ reload(ns_server_t *server) {
 	CHECK(loadconfig(server));
 
 	result = load_zones(server, ISC_FALSE);
-	if (result != ISC_R_SUCCESS) {
+	if (result == ISC_R_SUCCESS)
+		isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
+			      NS_LOGMODULE_SERVER, ISC_LOG_INFO,
+			      "reloading zones succeeded");
+	else
 		isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
 			      NS_LOGMODULE_SERVER, ISC_LOG_ERROR,
 			      "reloading zones failed: %s",
 			      isc_result_totext(result));
-	}
+
  cleanup:
 	return (result);
 }
@@ -3968,12 +4208,16 @@ reconfig(ns_server_t *server) {
 	CHECK(loadconfig(server));
 
 	result = load_new_zones(server, ISC_FALSE);
-	if (result != ISC_R_SUCCESS) {
+	if (result == ISC_R_SUCCESS)
+		isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
+			      NS_LOGMODULE_SERVER, ISC_LOG_INFO,
+			      "any newly configured zones are now loaded");
+	else
 		isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
 			      NS_LOGMODULE_SERVER, ISC_LOG_ERROR,
 			      "loading new zones failed: %s",
 			      isc_result_totext(result));
-	}
+
  cleanup: ;
 }
 
@@ -3987,6 +4231,9 @@ ns_server_reload(isc_task_t *task, isc_event_t *event) {
 	INSIST(task = server->task);
 	UNUSED(task);
 
+	isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
+		      NS_LOGMODULE_SERVER, ISC_LOG_INFO,
+		      "received SIGHUP signal to reload zones");
 	(void)reload(server);
 
 	LOCK(&server->reload_event_lock);
@@ -4068,23 +4315,28 @@ zone_from_args(ns_server_t *server, char *args, dns_zone_t **zonep) {
 		result = dns_rdataclass_fromtext(&rdclass, &r);
 		if (result != ISC_R_SUCCESS)
 			goto fail1;
-	} else {
+	} else
 		rdclass = dns_rdataclass_in;
-	}
 
-	if (viewtxt == NULL)
-		viewtxt = "_default";
-	result = dns_viewlist_find(&server->viewlist, viewtxt,
-				   rdclass, &view);
-	if (result != ISC_R_SUCCESS)
-		goto fail1;
+	if (viewtxt == NULL) {
+		result = dns_viewlist_findzone(&server->viewlist,
+					       dns_fixedname_name(&name),
+					       ISC_TF(classtxt == NULL),
+					       rdclass, zonep);
+	} else {
+		result = dns_viewlist_find(&server->viewlist, viewtxt,
+					   rdclass, &view);
+		if (result != ISC_R_SUCCESS)
+			goto fail1;
+
+		result = dns_zt_find(view->zonetable, dns_fixedname_name(&name),
+				     0, NULL, zonep);
+		dns_view_detach(&view);
+	}
 
-	result = dns_zt_find(view->zonetable, dns_fixedname_name(&name),
-			     0, NULL, zonep);
 	/* Partial match? */
 	if (result != ISC_R_SUCCESS && *zonep != NULL)
 		dns_zone_detach(zonep);
-	dns_view_detach(&view);
  fail1:
 	return (result);
 }
@@ -4313,7 +4565,8 @@ ns_listenelt_fromconfig(const cfg_obj_t *listener, const cfg_obj_t *config,
 		return (result);
 
 	result = cfg_acl_fromconfig(cfg_tuple_get(listener, "acl"),
-				   config, ns_g_lctx, actx, mctx, &delt->acl);
+				   config, ns_g_lctx, actx, mctx, 0,
+				   &delt->acl);
 	if (result != ISC_R_SUCCESS) {
 		ns_listenelt_destroy(delt);
 		return (result);
@@ -4325,61 +4578,26 @@ ns_listenelt_fromconfig(const cfg_obj_t *listener, const cfg_obj_t *config,
 isc_result_t
 ns_server_dumpstats(ns_server_t *server) {
 	isc_result_t result;
-	dns_zone_t *zone, *next;
-	isc_stdtime_t now;
 	FILE *fp = NULL;
-	int i;
-	int ncounters;
-
-	isc_stdtime_get(&now);
 
 	CHECKMF(isc_stdio_open(server->statsfile, "a", &fp),
 		"could not open statistics dump file", server->statsfile);
 
-	ncounters = DNS_STATS_NCOUNTERS;
-	fprintf(fp, "+++ Statistics Dump +++ (%lu)\n", (unsigned long)now);
-
-	for (i = 0; i < ncounters; i++)
-		fprintf(fp, "%s %" ISC_PRINT_QUADFORMAT "u\n",
-			dns_statscounter_names[i],
-			server->querystats[i]);
-
-	zone = NULL;
-	for (result = dns_zone_first(server->zonemgr, &zone);
-	     result == ISC_R_SUCCESS;
-	     next = NULL, result = dns_zone_next(zone, &next), zone = next)
-	{
-		isc_uint64_t *zonestats = dns_zone_getstatscounters(zone);
-		if (zonestats != NULL) {
-			char zonename[DNS_NAME_FORMATSIZE];
-			dns_view_t *view;
-			char *viewname;
-
-			dns_name_format(dns_zone_getorigin(zone),
-					zonename, sizeof(zonename));
-			view = dns_zone_getview(zone);
-			viewname = view->name;
-			for (i = 0; i < ncounters; i++) {
-				fprintf(fp, "%s %" ISC_PRINT_QUADFORMAT
-					"u %s",
-					dns_statscounter_names[i],
-					zonestats[i],
-					zonename);
-				if (strcmp(viewname, "_default") != 0)
-					fprintf(fp, " %s", viewname);
-				fprintf(fp, "\n");
-			}
-		}
-	}
-	if (result == ISC_R_NOMORE)
-		result = ISC_R_SUCCESS;
+	result = ns_stats_dump(server, fp);
 	CHECK(result);
 
-	fprintf(fp, "--- Statistics Dump --- (%lu)\n", (unsigned long)now);
-
  cleanup:
 	if (fp != NULL)
 		(void)isc_stdio_close(fp);
+	if (result == ISC_R_SUCCESS)
+		isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
+			      NS_LOGMODULE_SERVER, ISC_LOG_INFO,
+			      "dumpstats complete");
+	else
+		isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
+			      NS_LOGMODULE_SERVER, ISC_LOG_ERROR,
+			      "dumpstats failed: %s",
+			      dns_result_totext(result));
 	return (result);
 }
 
@@ -4564,7 +4782,7 @@ dumpdone(void *arg, isc_result_t result) {
  cleanup:
 	if (result != ISC_R_SUCCESS)
 		isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
-			      NS_LOGMODULE_SERVER, ISC_LOG_INFO,
+			      NS_LOGMODULE_SERVER, ISC_LOG_ERROR,
 			      "dumpdb failed: %s", dns_result_totext(result));
 	dumpcontext_destroy(dctx);
 }
@@ -4661,6 +4879,15 @@ ns_server_dumprecursing(ns_server_t *server) {
  cleanup:
 	if (fp != NULL)
 		result = isc_stdio_close(fp);
+	if (result == ISC_R_SUCCESS)
+		isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
+			      NS_LOGMODULE_SERVER, ISC_LOG_INFO,
+			      "dumprecursing complete");
+	else
+		isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
+			      NS_LOGMODULE_SERVER, ISC_LOG_ERROR,
+			      "dumprecursing failed: %s",
+			      dns_result_totext(result));
 	return (result);
 }
 
@@ -4690,6 +4917,9 @@ ns_server_setdebuglevel(ns_server_t *server, char *args) {
 		ns_g_debuglevel = (unsigned int)newlevel;
 	}
 	isc_log_setdebuglevel(ns_g_lctx, ns_g_debuglevel);
+	isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
+		      NS_LOGMODULE_SERVER, ISC_LOG_INFO,
+		      "debug level is now %d", ns_g_debuglevel);
 	return (ISC_R_SUCCESS);
 }
 
@@ -4774,15 +5004,33 @@ ns_server_flushcache(ns_server_t *server, char *args) {
 			continue;
 		found = ISC_TRUE;
 		result = dns_view_flushcache(view);
-		if (result != ISC_R_SUCCESS)
+		if (result != ISC_R_SUCCESS) {
 			flushed = ISC_FALSE;
+			isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
+				      NS_LOGMODULE_SERVER, ISC_LOG_ERROR,
+				      "flushing cache in view '%s' failed: %s",
+				      view->name, isc_result_totext(result));
+		}
 	}
 	if (flushed && found) {
+		if (viewname != NULL)
+			isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
+				      NS_LOGMODULE_SERVER, ISC_LOG_INFO,
+				      "flushing cache in view '%s' succeeded",
+				      viewname);
+		else
+			isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
+				      NS_LOGMODULE_SERVER, ISC_LOG_INFO,
+				      "flushing caches in all views succeeded");
 		result = ISC_R_SUCCESS;
 	} else {
-		if (!found)
+		if (!found) {
+			isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
+				      NS_LOGMODULE_SERVER, ISC_LOG_ERROR,
+				      "flushing cache in view '%s' failed: "
+				      "view not found", viewname);
 			result = ISC_R_NOTFOUND;
-		else
+		} else
 			result = ISC_R_FAILURE;
 	}
 	isc_task_endexclusive(server->task);
@@ -4833,15 +5081,36 @@ ns_server_flushname(ns_server_t *server, char *args) {
 			continue;
 		found = ISC_TRUE;
 		result = dns_view_flushname(view, name);
-		if (result != ISC_R_SUCCESS)
+		if (result != ISC_R_SUCCESS) {
 			flushed = ISC_FALSE;
+			isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
+				      NS_LOGMODULE_SERVER, ISC_LOG_ERROR,
+				      "flushing name '%s' in cache view '%s' "
+				      "failed: %s", target, view->name,
+				      isc_result_totext(result));
+		}
 	}
-	if (flushed && found)
+	if (flushed && found) {
+		if (viewname != NULL)
+			isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
+				      NS_LOGMODULE_SERVER, ISC_LOG_INFO,
+				      "flushing name '%s' in cache view '%s' "
+				      "succeeded", target, viewname);
+		else
+			isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
+				      NS_LOGMODULE_SERVER, ISC_LOG_INFO,
+				      "flushing name '%s' in all cache views "
+				      "succeeded", target);
 		result = ISC_R_SUCCESS;
-	else if (!found)
-		result = ISC_R_NOTFOUND;
-	else
+	} else {
+		if (!found)
+			isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
+				      NS_LOGMODULE_SERVER, ISC_LOG_ERROR,
+				      "flushing name '%s' in cache view '%s' "
+				      "failed: view not found", target,
+				      viewname);
 		result = ISC_R_FAILURE;
+	}
 	isc_task_endexclusive(server->task);
 	return (result);
 }
@@ -4850,7 +5119,16 @@ isc_result_t
 ns_server_status(ns_server_t *server, isc_buffer_t *text) {
 	int zonecount, xferrunning, xferdeferred, soaqueries;
 	unsigned int n;
+	const char *ob = "", *cb = "", *alt = "";
 
+	if (ns_g_server->version_set) {
+		ob = " (";
+		cb = ")";
+		if (ns_g_server->version == NULL)
+			alt = "version.bind/txt/ch disabled";
+		else
+			alt = ns_g_server->version;
+	}
 	zonecount = dns_zonemgr_getcount(server->zonemgr, DNS_ZONESTATE_ANY);
 	xferrunning = dns_zonemgr_getcount(server->zonemgr,
 					   DNS_ZONESTATE_XFERRUNNING);
@@ -4858,8 +5136,14 @@ ns_server_status(ns_server_t *server, isc_buffer_t *text) {
 					    DNS_ZONESTATE_XFERDEFERRED);
 	soaqueries = dns_zonemgr_getcount(server->zonemgr,
 					  DNS_ZONESTATE_SOAQUERY);
+
 	n = snprintf((char *)isc_buffer_used(text),
 		     isc_buffer_availablelength(text),
+		     "version: %s%s%s%s\n"
+#ifdef ISC_PLATFORM_USETHREADS
+		     "CPUs found: %u\n"
+		     "worker threads: %u\n"
+#endif
 		     "number of zones: %u\n"
 		     "debug level: %d\n"
 		     "xfers running: %u\n"
@@ -4869,6 +5153,10 @@ ns_server_status(ns_server_t *server, isc_buffer_t *text) {
 		     "recursive clients: %d/%d/%d\n"
 		     "tcp clients: %d/%d\n"
 		     "server is up and running",
+		     ns_g_version, ob, alt, cb,
+#ifdef ISC_PLATFORM_USETHREADS
+		     ns_g_cpus_detected, ns_g_cpus,
+#endif
 		     zonecount, ns_g_debuglevel, xferrunning, xferdeferred,
 		     soaqueries, server->log_queries ? "ON" : "OFF",
 		     server->recursionquota.used, server->recursionquota.soft,
@@ -4880,6 +5168,235 @@ ns_server_status(ns_server_t *server, isc_buffer_t *text) {
 	return (ISC_R_SUCCESS);
 }
 
+static isc_result_t
+delete_keynames(dns_tsig_keyring_t *ring, char *target,
+		unsigned int *foundkeys)
+{
+	char namestr[DNS_NAME_FORMATSIZE];
+	isc_result_t result;
+	dns_rbtnodechain_t chain;
+	dns_name_t foundname;
+	dns_fixedname_t fixedorigin;
+	dns_name_t *origin;
+	dns_rbtnode_t *node;
+	dns_tsigkey_t *tkey;
+
+	dns_name_init(&foundname, NULL);
+	dns_fixedname_init(&fixedorigin);
+	origin = dns_fixedname_name(&fixedorigin);
+
+ again:
+	dns_rbtnodechain_init(&chain, ring->mctx);
+	result = dns_rbtnodechain_first(&chain, ring->keys, &foundname,
+					origin);
+	if (result == ISC_R_NOTFOUND) {
+		dns_rbtnodechain_invalidate(&chain);
+		return (ISC_R_SUCCESS);
+	}
+	if (result != ISC_R_SUCCESS && result != DNS_R_NEWORIGIN) {
+		dns_rbtnodechain_invalidate(&chain);
+		return (result);
+	}
+
+	for (;;) {
+		node = NULL;
+		dns_rbtnodechain_current(&chain, &foundname, origin, &node);
+		tkey = node->data;
+
+		if (tkey != NULL) {
+			if (!tkey->generated)
+				goto nextkey;
+
+			dns_name_format(&tkey->name, namestr, sizeof(namestr));
+			if (strcmp(namestr, target) == 0) {
+				(*foundkeys)++;
+				dns_rbtnodechain_invalidate(&chain);
+				(void)dns_rbt_deletename(ring->keys,
+							 &tkey->name,
+							 ISC_FALSE);
+				goto again;
+			}
+		}
+
+	nextkey:
+		result = dns_rbtnodechain_next(&chain, &foundname, origin);
+		if (result == ISC_R_NOMORE)
+			break;
+		if (result != ISC_R_SUCCESS && result != DNS_R_NEWORIGIN) {
+			dns_rbtnodechain_invalidate(&chain);
+			return (result);
+		}
+	}
+
+	return (ISC_R_SUCCESS);
+}
+
+isc_result_t
+ns_server_tsigdelete(ns_server_t *server, char *command, isc_buffer_t *text) {
+	isc_result_t result;
+	unsigned int n;
+	dns_view_t *view;
+	unsigned int foundkeys = 0;
+	char *target;
+	char *viewname;
+
+	(void)next_token(&command, " \t");  /* skip command name */
+	target = next_token(&command, " \t");
+	if (target == NULL)
+		return (ISC_R_UNEXPECTEDEND);
+	viewname = next_token(&command, " \t");
+
+	result = isc_task_beginexclusive(server->task);
+	RUNTIME_CHECK(result == ISC_R_SUCCESS);
+	for (view = ISC_LIST_HEAD(server->viewlist);
+	     view != NULL;
+	     view = ISC_LIST_NEXT(view, link)) {
+		if (viewname == NULL || strcmp(view->name, viewname) == 0) {
+			RWLOCK(&view->dynamickeys->lock, isc_rwlocktype_write);
+			result = delete_keynames(view->dynamickeys, target,
+						 &foundkeys);
+			RWUNLOCK(&view->dynamickeys->lock,
+				 isc_rwlocktype_write);
+			if (result != ISC_R_SUCCESS) {
+				isc_task_endexclusive(server->task);
+				return (result);
+			}
+		}
+	}
+	isc_task_endexclusive(server->task);
+
+	n = snprintf((char *)isc_buffer_used(text),
+		     isc_buffer_availablelength(text),
+		     "%d tsig keys deleted.\n", foundkeys);
+	if (n >= isc_buffer_availablelength(text)) {
+		isc_task_endexclusive(server->task);
+		return (ISC_R_NOSPACE);
+	}
+	isc_buffer_add(text, n);
+
+	return (ISC_R_SUCCESS);
+}
+
+static isc_result_t
+list_keynames(dns_view_t *view, dns_tsig_keyring_t *ring, isc_buffer_t *text,
+	     unsigned int *foundkeys)
+{
+	char namestr[DNS_NAME_FORMATSIZE];
+	char creatorstr[DNS_NAME_FORMATSIZE];
+	isc_result_t result;
+	dns_rbtnodechain_t chain;
+	dns_name_t foundname;
+	dns_fixedname_t fixedorigin;
+	dns_name_t *origin;
+	dns_rbtnode_t *node;
+	dns_tsigkey_t *tkey;
+	unsigned int n;
+	const char *viewname;
+
+	if (view != NULL)
+		viewname = view->name;
+	else
+		viewname = "(global)";
+
+	dns_name_init(&foundname, NULL);
+	dns_fixedname_init(&fixedorigin);
+	origin = dns_fixedname_name(&fixedorigin);
+	dns_rbtnodechain_init(&chain, ring->mctx);
+	result = dns_rbtnodechain_first(&chain, ring->keys, &foundname,
+					origin);
+	if (result == ISC_R_NOTFOUND) {
+		dns_rbtnodechain_invalidate(&chain);
+		return (ISC_R_SUCCESS);
+	}
+	if (result != ISC_R_SUCCESS && result != DNS_R_NEWORIGIN) {
+		dns_rbtnodechain_invalidate(&chain);
+		return (result);
+	}
+
+	for (;;) {
+		node = NULL;
+		dns_rbtnodechain_current(&chain, &foundname, origin, &node);
+		tkey = node->data;
+
+		if (tkey != NULL) {
+			(*foundkeys)++;
+			dns_name_format(&tkey->name, namestr, sizeof(namestr));
+			if (tkey->generated) {
+				dns_name_format(tkey->creator, creatorstr,
+						sizeof(creatorstr));
+				n = snprintf((char *)isc_buffer_used(text),
+					     isc_buffer_availablelength(text),
+					     "view \"%s\"; type \"dynamic\"; key \"%s\"; creator \"%s\";\n",
+					     viewname, namestr, creatorstr);
+			} else {
+				n = snprintf((char *)isc_buffer_used(text),
+					     isc_buffer_availablelength(text),
+					     "view \"%s\"; type \"static\"; key \"%s\";\n",
+					     viewname, namestr);
+			}
+			if (n >= isc_buffer_availablelength(text)) {
+				dns_rbtnodechain_invalidate(&chain);
+				return (ISC_R_NOSPACE);
+			}
+			isc_buffer_add(text, n);
+		}
+		result = dns_rbtnodechain_next(&chain, &foundname, origin);
+		if (result == ISC_R_NOMORE)
+			break;
+		if (result != ISC_R_SUCCESS && result != DNS_R_NEWORIGIN) {
+			dns_rbtnodechain_invalidate(&chain);
+			return (result);
+		}
+	}
+
+	return (ISC_R_SUCCESS);
+}
+
+isc_result_t
+ns_server_tsiglist(ns_server_t *server, isc_buffer_t *text) {
+	isc_result_t result;
+	unsigned int n;
+	dns_view_t *view;
+	unsigned int foundkeys = 0;
+
+	result = isc_task_beginexclusive(server->task);
+	RUNTIME_CHECK(result == ISC_R_SUCCESS);
+	for (view = ISC_LIST_HEAD(server->viewlist);
+	     view != NULL;
+	     view = ISC_LIST_NEXT(view, link)) {
+		RWLOCK(&view->statickeys->lock, isc_rwlocktype_read);
+		result = list_keynames(view, view->statickeys, text,
+				       &foundkeys);
+		RWUNLOCK(&view->statickeys->lock, isc_rwlocktype_read);
+		if (result != ISC_R_SUCCESS) {
+			isc_task_endexclusive(server->task);
+			return (result);
+		}
+		RWLOCK(&view->dynamickeys->lock, isc_rwlocktype_read);
+		result = list_keynames(view, view->dynamickeys, text,
+				       &foundkeys);
+		RWUNLOCK(&view->dynamickeys->lock, isc_rwlocktype_read);
+		if (result != ISC_R_SUCCESS) {
+			isc_task_endexclusive(server->task);
+			return (result);
+		}
+	}
+	isc_task_endexclusive(server->task);
+
+	if (foundkeys == 0) {
+		n = snprintf((char *)isc_buffer_used(text),
+			     isc_buffer_availablelength(text),
+			     "no tsig keys found.\n");
+		if (n >= isc_buffer_availablelength(text)) {
+			isc_task_endexclusive(server->task);
+			return (ISC_R_NOSPACE);
+		}
+		isc_buffer_add(text, n);
+	}
+
+	return (ISC_R_SUCCESS);
+}
+
 /*
  * Act on a "freeze" or "thaw" command from the command channel.
  */
diff --git a/contrib/bind9/bin/named/sortlist.c b/contrib/bind9/bin/named/sortlist.c
index 28f0360..daefa07 100644
--- a/contrib/bind9/bin/named/sortlist.c
+++ b/contrib/bind9/bin/named/sortlist.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: sortlist.c,v 1.9.18.4 2006/03/02 00:37:21 marka Exp $ */
+/* $Id: sortlist.c,v 1.17 2007/09/14 01:46:05 marka Exp $ */
 
 /*! \file */
 
@@ -51,15 +51,19 @@ ns_sortlist_setup(dns_acl_t *acl, isc_netaddr_t *clientaddr,
 		const dns_aclelement_t *matched_elt = NULL;
 
 		if (e->type == dns_aclelementtype_nestedacl) {
-			dns_acl_t *inner = e->u.nestedacl;
+			dns_acl_t *inner = e->nestedacl;
 
-			if (inner->length < 1 || inner->length > 2)
+			if (inner->length == 0)
+				try_elt = e;
+			else if (inner->length > 2)
 				goto dont_sort;
-			if (inner->elements[0].negative)
+			else if (inner->elements[0].negative)
 				goto dont_sort;
-			try_elt = &inner->elements[0];
-			if (inner->length == 2)
-				order_elt = &inner->elements[1];
+			else {
+				try_elt = &inner->elements[0];
+				if (inner->length == 2)
+					order_elt = &inner->elements[1];
+			}
 		} else {
 			/*
 			 * BIND 8 allows bare elements at the top level
@@ -74,7 +78,7 @@ ns_sortlist_setup(dns_acl_t *acl, isc_netaddr_t *clientaddr,
 			if (order_elt != NULL) {
 				if (order_elt->type ==
 				    dns_aclelementtype_nestedacl) {
-					*argp = order_elt->u.nestedacl;
+					*argp = order_elt->nestedacl;
 					return (NS_SORTLISTTYPE_2ELEMENT);
 				} else if (order_elt->type ==
 					   dns_aclelementtype_localhost &&
diff --git a/contrib/bind9/bin/named/statschannel.c b/contrib/bind9/bin/named/statschannel.c
new file mode 100644
index 0000000..81f40bb
--- /dev/null
+++ b/contrib/bind9/bin/named/statschannel.c
@@ -0,0 +1,1355 @@
+/*
+ * Copyright (C) 2008, 2009  Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or 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: statschannel.c,v 1.14.64.6 2009/02/17 03:43:07 marka Exp $ */
+
+/*! \file */
+
+#include <config.h>
+
+#include <isc/buffer.h>
+#include <isc/httpd.h>
+#include <isc/mem.h>
+#include <isc/once.h>
+#include <isc/print.h>
+#include <isc/socket.h>
+#include <isc/stats.h>
+#include <isc/task.h>
+
+#include <dns/db.h>
+#include <dns/opcode.h>
+#include <dns/resolver.h>
+#include <dns/rdataclass.h>
+#include <dns/rdatatype.h>
+#include <dns/stats.h>
+#include <dns/view.h>
+#include <dns/zt.h>
+
+#include <named/log.h>
+#include <named/server.h>
+#include <named/statschannel.h>
+
+#include "bind9.xsl.h"
+
+struct ns_statschannel {
+	/* Unlocked */
+	isc_httpdmgr_t				*httpdmgr;
+	isc_sockaddr_t				address;
+	isc_mem_t				*mctx;
+
+	/*
+	 * Locked by channel lock: can be referenced and modified by both
+	 * the server task and the channel task.
+	 */
+	isc_mutex_t				lock;
+	dns_acl_t				*acl;
+
+	/* Locked by server task */
+	ISC_LINK(struct ns_statschannel)	link;
+};
+
+typedef enum { statsformat_file, statsformat_xml } statsformat_t;
+
+typedef struct
+stats_dumparg {
+	statsformat_t	type;
+	void		*arg;		/* type dependent argument */
+	int		ncounters;	/* used for general statistics */
+	int		*counterindices; /* used for general statistics */
+	isc_uint64_t	*countervalues;	 /* used for general statistics */
+} stats_dumparg_t;
+
+static isc_once_t once = ISC_ONCE_INIT;
+
+/*%
+ * Statistics descriptions.  These could be statistically initialized at
+ * compile time, but we configure them run time in the init_desc() function
+ * below so that they'll be less susceptible to counter name changes.
+ */
+static const char *nsstats_desc[dns_nsstatscounter_max];
+static const char *resstats_desc[dns_resstatscounter_max];
+static const char *zonestats_desc[dns_zonestatscounter_max];
+static const char *sockstats_desc[isc_sockstatscounter_max];
+#ifdef HAVE_LIBXML2
+static const char *nsstats_xmldesc[dns_nsstatscounter_max];
+static const char *resstats_xmldesc[dns_resstatscounter_max];
+static const char *zonestats_xmldesc[dns_zonestatscounter_max];
+static const char *sockstats_xmldesc[isc_sockstatscounter_max];
+#else
+#define nsstats_xmldesc NULL
+#define resstats_xmldesc NULL
+#define zonestats_xmldesc NULL
+#define sockstats_xmldesc NULL
+#endif	/* HAVE_LIBXML2 */
+
+/*%
+ * Mapping arrays to represent statistics counters in the order of our
+ * preference, regardless of the order of counter indices.  For example,
+ * nsstats_desc[nsstats_index[0]] will be the description that is shown first.
+ */
+static int nsstats_index[dns_nsstatscounter_max];
+static int resstats_index[dns_resstatscounter_max];
+static int zonestats_index[dns_zonestatscounter_max];
+static int sockstats_index[isc_sockstatscounter_max];
+
+static inline void
+set_desc(int counter, int maxcounter, const char *fdesc, const char **fdescs,
+	 const char *xdesc, const char **xdescs)
+{
+	REQUIRE(counter < maxcounter);
+	REQUIRE(fdescs[counter] == NULL);
+#ifdef HAVE_LIBXML2
+	REQUIRE(xdescs[counter] == NULL);
+#endif
+
+	fdescs[counter] = fdesc;
+#ifdef HAVE_LIBXML2
+	xdescs[counter] = xdesc;
+#else
+	UNUSED(xdesc);
+	UNUSED(xdescs);
+#endif
+}
+
+static void
+init_desc(void) {
+	int i;
+
+	/* Initialize name server statistics */
+	memset((void *)nsstats_desc, 0,
+	       dns_nsstatscounter_max * sizeof(nsstats_desc[0]));
+#ifdef HAVE_LIBXML2
+	memset((void *)nsstats_xmldesc, 0,
+	       dns_nsstatscounter_max * sizeof(nsstats_xmldesc[0]));
+#endif
+
+#define SET_NSSTATDESC(counterid, desc, xmldesc) \
+	do { \
+		set_desc(dns_nsstatscounter_ ## counterid, \
+			 dns_nsstatscounter_max, \
+			 desc, nsstats_desc, xmldesc, nsstats_xmldesc); \
+		nsstats_index[i++] = dns_nsstatscounter_ ## counterid; \
+	} while (0)
+
+	i = 0;
+	SET_NSSTATDESC(requestv4, "IPv4 requests received", "Requestv4");
+	SET_NSSTATDESC(requestv6, "IPv6 requests received", "Requestv6");
+	SET_NSSTATDESC(edns0in, "requests with EDNS(0) received", "ReqEdns0");
+	SET_NSSTATDESC(badednsver,
+		       "requests with unsupported EDNS version received",
+		       "ReqBadEDNSVer");
+	SET_NSSTATDESC(tsigin, "requests with TSIG received", "ReqTSIG");
+	SET_NSSTATDESC(sig0in, "requests with SIG(0) received", "ReqSIG0");
+	SET_NSSTATDESC(invalidsig, "requests with invalid signature",
+		       "ReqBadSIG");
+	SET_NSSTATDESC(tcp, "TCP requests received", "ReqTCP");
+	SET_NSSTATDESC(authrej, "auth queries rejected", "AuthQryRej");
+	SET_NSSTATDESC(recurserej, "recursive queries rejected", "RecQryRej");
+	SET_NSSTATDESC(xfrrej, "transfer requests rejected", "XfrRej");
+	SET_NSSTATDESC(updaterej, "update requests rejected", "UpdateRej");
+	SET_NSSTATDESC(response, "responses sent", "Response");
+	SET_NSSTATDESC(truncatedresp, "truncated responses sent",
+		       "TruncatedResp");
+	SET_NSSTATDESC(edns0out, "responses with EDNS(0) sent", "RespEDNS0");
+	SET_NSSTATDESC(tsigout, "responses with TSIG sent", "RespTSIG");
+	SET_NSSTATDESC(sig0out, "responses with SIG(0) sent", "RespSIG0");
+	SET_NSSTATDESC(success, "queries resulted in successful answer",
+		       "QrySuccess");
+	SET_NSSTATDESC(authans, "queries resulted in authoritative answer",
+		       "QryAuthAns");
+	SET_NSSTATDESC(nonauthans,
+		       "queries resulted in non authoritative answer",
+		       "QryNoauthAns");
+	SET_NSSTATDESC(referral, "queries resulted in referral answer",
+		       "QryReferral");
+	SET_NSSTATDESC(nxrrset, "queries resulted in nxrrset", "QryNxrrset");
+	SET_NSSTATDESC(servfail, "queries resulted in SERVFAIL", "QrySERVFAIL");
+	SET_NSSTATDESC(formerr, "queries resulted in FORMERR", "QryFORMERR");
+	SET_NSSTATDESC(nxdomain, "queries resulted in NXDOMAIN", "QryNXDOMAIN");
+	SET_NSSTATDESC(recursion, "queries caused recursion","QryRecursion");
+	SET_NSSTATDESC(duplicate, "duplicate queries received", "QryDuplicate");
+	SET_NSSTATDESC(dropped, "queries dropped", "QryDropped");
+	SET_NSSTATDESC(failure, "other query failures", "QryFailure");
+	SET_NSSTATDESC(xfrdone, "requested transfers completed", "XfrReqDone");
+	SET_NSSTATDESC(updatereqfwd, "update requests forwarded",
+		       "UpdateReqFwd");
+	SET_NSSTATDESC(updaterespfwd, "update responses forwarded",
+		       "UpdateRespFwd");
+	SET_NSSTATDESC(updatefwdfail, "update forward failed", "UpdateFwdFail");
+	SET_NSSTATDESC(updatedone, "updates completed", "UpdateDone");
+	SET_NSSTATDESC(updatefail, "updates failed", "UpdateFail");
+	SET_NSSTATDESC(updatebadprereq,
+		       "updates rejected due to prerequisite failure",
+		       "UpdateBadPrereq");
+	INSIST(i == dns_nsstatscounter_max);
+
+	/* Initialize resolver statistics */
+	memset((void *)resstats_desc, 0,
+	       dns_resstatscounter_max * sizeof(resstats_desc[0]));
+#ifdef  HAVE_LIBXML2
+	memset((void *)resstats_xmldesc, 0,
+	       dns_resstatscounter_max * sizeof(resstats_xmldesc[0]));
+#endif
+
+#define SET_RESSTATDESC(counterid, desc, xmldesc) \
+	do { \
+		set_desc(dns_resstatscounter_ ## counterid, \
+			 dns_resstatscounter_max, \
+			 desc, resstats_desc, xmldesc, resstats_xmldesc); \
+		resstats_index[i++] = dns_resstatscounter_ ## counterid; \
+	} while (0)
+
+	i = 0;
+	SET_RESSTATDESC(queryv4, "IPv4 queries sent", "Queryv4");
+	SET_RESSTATDESC(queryv6, "IPv6 queries sent", "Queryv6");
+	SET_RESSTATDESC(responsev4, "IPv4 responses received", "Responsev4");
+	SET_RESSTATDESC(responsev6, "IPv6 responses received", "Responsev6");
+	SET_RESSTATDESC(nxdomain, "NXDOMAIN received", "NXDOMAIN");
+	SET_RESSTATDESC(servfail, "SERVFAIL received", "SERVFAIL");
+	SET_RESSTATDESC(formerr, "FORMERR received", "FORMERR");
+	SET_RESSTATDESC(othererror, "other errors received", "OtherError");
+	SET_RESSTATDESC(edns0fail, "EDNS(0) query failures", "EDNS0Fail");
+	SET_RESSTATDESC(mismatch, "mismatch responses received", "Mismatch");
+	SET_RESSTATDESC(truncated, "truncated responses received", "Truncated");
+	SET_RESSTATDESC(lame, "lame delegations received", "Lame");
+	SET_RESSTATDESC(retry, "query retries", "Retry");
+	SET_RESSTATDESC(dispabort, "queries aborted due to quota",
+			"QueryAbort");
+	SET_RESSTATDESC(dispsockfail, "failures in opening query sockets",
+			"QuerySockFail");
+	SET_RESSTATDESC(querytimeout, "query timeouts", "QueryTimeout");
+	SET_RESSTATDESC(gluefetchv4, "IPv4 NS address fetches", "GlueFetchv4");
+	SET_RESSTATDESC(gluefetchv6, "IPv6 NS address fetches", "GlueFetchv6");
+	SET_RESSTATDESC(gluefetchv4fail, "IPv4 NS address fetch failed",
+			"GlueFetchv4Fail");
+	SET_RESSTATDESC(gluefetchv6fail, "IPv6 NS address fetch failed",
+			"GlueFetchv6Fail");
+	SET_RESSTATDESC(val, "DNSSEC validation attempted", "ValAttempt");
+	SET_RESSTATDESC(valsuccess, "DNSSEC validation succeeded", "ValOk");
+	SET_RESSTATDESC(valnegsuccess, "DNSSEC NX validation succeeded",
+			"ValNegOk");
+	SET_RESSTATDESC(valfail, "DNSSEC validation failed", "ValFail");
+	SET_RESSTATDESC(queryrtt0, "queries with RTT < "
+			DNS_RESOLVER_QRYRTTCLASS0STR "ms",
+			"QryRTT" DNS_RESOLVER_QRYRTTCLASS0STR);
+	SET_RESSTATDESC(queryrtt1, "queries with RTT "
+			DNS_RESOLVER_QRYRTTCLASS0STR "-"
+			DNS_RESOLVER_QRYRTTCLASS1STR "ms",
+			"QryRTT" DNS_RESOLVER_QRYRTTCLASS1STR);
+	SET_RESSTATDESC(queryrtt2, "queries with RTT "
+			DNS_RESOLVER_QRYRTTCLASS1STR "-"
+			DNS_RESOLVER_QRYRTTCLASS2STR "ms",
+			"QryRTT" DNS_RESOLVER_QRYRTTCLASS2STR);
+	SET_RESSTATDESC(queryrtt3, "queries with RTT "
+			DNS_RESOLVER_QRYRTTCLASS2STR "-"
+			DNS_RESOLVER_QRYRTTCLASS3STR "ms",
+			"QryRTT" DNS_RESOLVER_QRYRTTCLASS3STR);
+	SET_RESSTATDESC(queryrtt4, "queries with RTT "
+			DNS_RESOLVER_QRYRTTCLASS3STR "-"
+			DNS_RESOLVER_QRYRTTCLASS4STR "ms",
+			"QryRTT" DNS_RESOLVER_QRYRTTCLASS4STR);
+	SET_RESSTATDESC(queryrtt5, "queries with RTT > "
+			DNS_RESOLVER_QRYRTTCLASS4STR "ms",
+			"QryRTT" DNS_RESOLVER_QRYRTTCLASS4STR "+");
+	INSIST(i == dns_resstatscounter_max);
+
+	/* Initialize zone statistics */
+	memset((void *)zonestats_desc, 0,
+	       dns_zonestatscounter_max * sizeof(zonestats_desc[0]));
+#ifdef  HAVE_LIBXML2
+	memset((void *)zonestats_xmldesc, 0,
+	       dns_zonestatscounter_max * sizeof(zonestats_xmldesc[0]));
+#endif
+
+#define SET_ZONESTATDESC(counterid, desc, xmldesc) \
+	do { \
+		set_desc(dns_zonestatscounter_ ## counterid, \
+			 dns_zonestatscounter_max, \
+			 desc, zonestats_desc, xmldesc, zonestats_xmldesc); \
+		zonestats_index[i++] = dns_zonestatscounter_ ## counterid; \
+	} while (0)
+
+	i = 0;
+	SET_ZONESTATDESC(notifyoutv4, "IPv4 notifies sent", "NotifyOutv4");
+	SET_ZONESTATDESC(notifyoutv6, "IPv6 notifies sent", "NotifyOutv6");
+	SET_ZONESTATDESC(notifyinv4, "IPv4 notifies received", "NotifyInv4");
+	SET_ZONESTATDESC(notifyinv6, "IPv6 notifies received", "NotifyInv6");
+	SET_ZONESTATDESC(notifyrej, "notifies rejected", "NotifyRej");
+	SET_ZONESTATDESC(soaoutv4, "IPv4 SOA queries sent", "SOAOutv4");
+	SET_ZONESTATDESC(soaoutv6, "IPv6 SOA queries sent", "SOAOutv6");
+	SET_ZONESTATDESC(axfrreqv4, "IPv4 AXFR requested", "AXFRReqv4");
+	SET_ZONESTATDESC(axfrreqv6, "IPv6 AXFR requested", "AXFRReqv6");
+	SET_ZONESTATDESC(ixfrreqv4, "IPv4 IXFR requested", "IXFRReqv4");
+	SET_ZONESTATDESC(ixfrreqv6, "IPv6 IXFR requested", "IXFRReqv6");
+	SET_ZONESTATDESC(xfrsuccess, "transfer requests succeeded","XfrSuccess");
+	SET_ZONESTATDESC(xfrfail, "transfer requests failed", "XfrFail");
+	INSIST(i == dns_zonestatscounter_max);
+
+	/* Initialize socket statistics */
+	memset((void *)sockstats_desc, 0,
+	       isc_sockstatscounter_max * sizeof(sockstats_desc[0]));
+#ifdef  HAVE_LIBXML2
+	memset((void *)sockstats_xmldesc, 0,
+	       isc_sockstatscounter_max * sizeof(sockstats_xmldesc[0]));
+#endif
+
+#define SET_SOCKSTATDESC(counterid, desc, xmldesc) \
+	do { \
+		set_desc(isc_sockstatscounter_ ## counterid, \
+			 isc_sockstatscounter_max, \
+			 desc, sockstats_desc, xmldesc, sockstats_xmldesc); \
+		sockstats_index[i++] = isc_sockstatscounter_ ## counterid; \
+	} while (0)
+
+	i = 0;
+	SET_SOCKSTATDESC(udp4open, "UDP/IPv4 sockets opened", "UDP4Open");
+	SET_SOCKSTATDESC(udp6open, "UDP/IPv6 sockets opened", "UDP6Open");
+	SET_SOCKSTATDESC(tcp4open, "TCP/IPv4 sockets opened", "TCP4Open");
+	SET_SOCKSTATDESC(tcp6open, "TCP/IPv6 sockets opened", "TCP6Open");
+	SET_SOCKSTATDESC(unixopen, "Unix domain sockets opened", "UnixOpen");
+	SET_SOCKSTATDESC(udp4openfail, "UDP/IPv4 socket open failures",
+			 "UDP4OpenFail");
+	SET_SOCKSTATDESC(udp6openfail, "UDP/IPv6 socket open failures",
+			 "UDP6OpenFail");
+	SET_SOCKSTATDESC(tcp4openfail, "TCP/IPv4 socket open failures",
+			 "TCP4OpenFail");
+	SET_SOCKSTATDESC(tcp6openfail, "TCP/IPv6 socket open failures",
+			 "TCP6OpenFail");
+	SET_SOCKSTATDESC(unixopenfail, "Unix domain socket open failures",
+			 "UnixOpenFail");
+	SET_SOCKSTATDESC(udp4close, "UDP/IPv4 sockets closed", "UDP4Close");
+	SET_SOCKSTATDESC(udp6close, "UDP/IPv6 sockets closed", "UDP6Close");
+	SET_SOCKSTATDESC(tcp4close, "TCP/IPv4 sockets closed", "TCP4Close");
+	SET_SOCKSTATDESC(tcp6close, "TCP/IPv6 sockets closed", "TCP6Close");
+	SET_SOCKSTATDESC(unixclose, "Unix domain sockets closed", "UnixClose");
+	SET_SOCKSTATDESC(fdwatchclose, "FDwatch sockets closed",
+			 "FDWatchClose");
+	SET_SOCKSTATDESC(udp4bindfail, "UDP/IPv4 socket bind failures",
+			 "UDP4BindFail");
+	SET_SOCKSTATDESC(udp6bindfail, "UDP/IPv6 socket bind failures",
+			 "UDP6BindFail");
+	SET_SOCKSTATDESC(tcp4bindfail, "TCP/IPv4 socket bind failures",
+			 "TCP4BindFail");
+	SET_SOCKSTATDESC(tcp6bindfail, "TCP/IPv6 socket bind failures",
+			 "TCP6BindFail");
+	SET_SOCKSTATDESC(unixbindfail, "Unix domain socket bind failures",
+			 "UnixBindFail");
+	SET_SOCKSTATDESC(fdwatchbindfail, "FDwatch socket bind failures",
+			 "FdwatchBindFail");
+	SET_SOCKSTATDESC(udp4connectfail, "UDP/IPv4 socket connect failures",
+			 "UDP4ConnFail");
+	SET_SOCKSTATDESC(udp6connectfail, "UDP/IPv6 socket connect failures",
+			 "UDP6ConnFail");
+	SET_SOCKSTATDESC(tcp4connectfail, "TCP/IPv4 socket connect failures",
+			 "TCP4ConnFail");
+	SET_SOCKSTATDESC(tcp6connectfail, "TCP/IPv6 socket connect failures",
+			 "TCP6ConnFail");
+	SET_SOCKSTATDESC(unixconnectfail, "Unix domain socket connect failures",
+			 "UnixConnFail");
+	SET_SOCKSTATDESC(fdwatchconnectfail, "FDwatch socket connect failures",
+			 "FDwatchConnFail");
+	SET_SOCKSTATDESC(udp4connect, "UDP/IPv4 connections established",
+			 "UDP4Conn");
+	SET_SOCKSTATDESC(udp6connect, "UDP/IPv6 connections established",
+			 "UDP6Conn");
+	SET_SOCKSTATDESC(tcp4connect, "TCP/IPv4 connections established",
+			 "TCP4Conn");
+	SET_SOCKSTATDESC(tcp6connect, "TCP/IPv6 connections established",
+			 "TCP6Conn");
+	SET_SOCKSTATDESC(unixconnect, "Unix domain connections established",
+			 "UnixConn");
+	SET_SOCKSTATDESC(fdwatchconnect,
+			 "FDwatch domain connections established",
+			 "FDwatchConn");
+	SET_SOCKSTATDESC(tcp4acceptfail, "TCP/IPv4 connection accept failures",
+			 "TCP4AcceptFail");
+	SET_SOCKSTATDESC(tcp6acceptfail, "TCP/IPv6 connection accept failures",
+			 "TCP6AcceptFail");
+	SET_SOCKSTATDESC(unixacceptfail,
+			 "Unix domain connection accept failures",
+			 "UnixAcceptFail");
+	SET_SOCKSTATDESC(tcp4accept, "TCP/IPv4 connections accepted",
+			 "TCP4Accept");
+	SET_SOCKSTATDESC(tcp6accept, "TCP/IPv6 connections accepted",
+			 "TCP6Accept");
+	SET_SOCKSTATDESC(unixaccept, "Unix domain connections accepted",
+			 "UnixAccept");
+	SET_SOCKSTATDESC(udp4sendfail, "UDP/IPv4 send errors", "UDP4SendErr");
+	SET_SOCKSTATDESC(udp6sendfail, "UDP/IPv6 send errors", "UDP6SendErr");
+	SET_SOCKSTATDESC(tcp4sendfail, "TCP/IPv4 send errors", "TCP4SendErr");
+	SET_SOCKSTATDESC(tcp6sendfail, "TCP/IPv6 send errors", "TCP6SendErr");
+	SET_SOCKSTATDESC(unixsendfail, "Unix domain send errors",
+			 "UnixSendErr");
+	SET_SOCKSTATDESC(fdwatchsendfail, "FDwatch send errors",
+			 "FDwatchSendErr");
+	SET_SOCKSTATDESC(udp4recvfail, "UDP/IPv4 recv errors", "UDP4RecvErr");
+	SET_SOCKSTATDESC(udp6recvfail, "UDP/IPv6 recv errors", "UDP6RecvErr");
+	SET_SOCKSTATDESC(tcp4recvfail, "TCP/IPv4 recv errors", "TCP4RecvErr");
+	SET_SOCKSTATDESC(tcp6recvfail, "TCP/IPv6 recv errors", "TCP6RecvErr");
+	SET_SOCKSTATDESC(unixrecvfail, "Unix domain recv errors",
+			 "UnixRecvErr");
+	SET_SOCKSTATDESC(fdwatchrecvfail, "FDwatch recv errors",
+			 "FDwatchRecvErr");
+	INSIST(i == isc_sockstatscounter_max);
+
+	/* Sanity check */
+	for (i = 0; i < dns_nsstatscounter_max; i++)
+		INSIST(nsstats_desc[i] != NULL);
+	for (i = 0; i < dns_resstatscounter_max; i++)
+		INSIST(resstats_desc[i] != NULL);
+	for (i = 0; i < dns_zonestatscounter_max; i++)
+		INSIST(zonestats_desc[i] != NULL);
+	for (i = 0; i < isc_sockstatscounter_max; i++)
+		INSIST(sockstats_desc[i] != NULL);
+#ifdef  HAVE_LIBXML2
+	for (i = 0; i < dns_nsstatscounter_max; i++)
+		INSIST(nsstats_xmldesc[i] != NULL);
+	for (i = 0; i < dns_resstatscounter_max; i++)
+		INSIST(resstats_xmldesc[i] != NULL);
+	for (i = 0; i < dns_zonestatscounter_max; i++)
+		INSIST(zonestats_xmldesc[i] != NULL);
+	for (i = 0; i < isc_sockstatscounter_max; i++)
+		INSIST(sockstats_xmldesc[i] != NULL);
+#endif
+}
+
+/*%
+ * Dump callback functions.
+ */
+static void
+generalstat_dump(isc_statscounter_t counter, isc_uint64_t val, void *arg) {
+	stats_dumparg_t *dumparg = arg;
+
+	REQUIRE(counter < dumparg->ncounters);
+	dumparg->countervalues[counter] = val;
+}
+
+static void
+dump_counters(isc_stats_t *stats, statsformat_t type, void *arg,
+	      const char *category, const char **desc, int ncounters,
+	      int *indices, isc_uint64_t *values, int options)
+{
+	int i, index;
+	isc_uint64_t value;
+	stats_dumparg_t dumparg;
+	FILE *fp;
+#ifdef HAVE_LIBXML2
+	xmlTextWriterPtr writer;
+#endif
+
+#ifndef HAVE_LIBXML2
+	UNUSED(category);
+#endif
+
+	dumparg.type = type;
+	dumparg.ncounters = ncounters;
+	dumparg.counterindices = indices;
+	dumparg.countervalues = values;
+
+	memset(values, 0, sizeof(values[0]) * ncounters);
+	isc_stats_dump(stats, generalstat_dump, &dumparg, options);
+
+	for (i = 0; i < ncounters; i++) {
+		index = indices[i];
+		value = values[index];
+
+		if (value == 0 && (options & ISC_STATSDUMP_VERBOSE) == 0)
+			continue;
+
+		switch (dumparg.type) {
+		case statsformat_file:
+			fp = arg;
+			fprintf(fp, "%20" ISC_PRINT_QUADFORMAT "u %s\n",
+				value, desc[index]);
+			break;
+		case statsformat_xml:
+#ifdef HAVE_LIBXML2
+			writer = arg;
+
+			if (category != NULL) {
+				xmlTextWriterStartElement(writer,
+							  ISC_XMLCHAR
+							  category);
+				xmlTextWriterStartElement(writer,
+							  ISC_XMLCHAR "name");
+				xmlTextWriterWriteString(writer, ISC_XMLCHAR
+							desc[index]);
+				xmlTextWriterEndElement(writer); /* name */
+
+				xmlTextWriterStartElement(writer, ISC_XMLCHAR
+							  "counter");
+			} else {
+				xmlTextWriterStartElement(writer, ISC_XMLCHAR
+							  desc[index]);
+			}
+			xmlTextWriterWriteFormatString(writer,
+						       "%" ISC_PRINT_QUADFORMAT
+						       "u", value);
+			xmlTextWriterEndElement(writer); /* counter */
+			if (category != NULL)
+				xmlTextWriterEndElement(writer); /* category */
+#endif
+			break;
+		}
+	}
+}
+
+static void
+rdtypestat_dump(dns_rdatastatstype_t type, isc_uint64_t val, void *arg) {
+	char typebuf[64];
+	const char *typestr;
+	stats_dumparg_t *dumparg = arg;
+	FILE *fp;
+#ifdef HAVE_LIBXML2
+	xmlTextWriterPtr writer;
+#endif
+
+	if ((DNS_RDATASTATSTYPE_ATTR(type) & DNS_RDATASTATSTYPE_ATTR_OTHERTYPE)
+	    == 0) {
+		dns_rdatatype_format(DNS_RDATASTATSTYPE_BASE(type), typebuf,
+				     sizeof(typebuf));
+		typestr = typebuf;
+	} else
+		typestr = "Others";
+
+	switch (dumparg->type) {
+	case statsformat_file:
+		fp = dumparg->arg;
+		fprintf(fp, "%20" ISC_PRINT_QUADFORMAT "u %s\n", val, typestr);
+		break;
+	case statsformat_xml:
+#ifdef HAVE_LIBXML2
+		writer = dumparg->arg;
+
+		xmlTextWriterStartElement(writer, ISC_XMLCHAR "rdtype");
+
+		xmlTextWriterStartElement(writer, ISC_XMLCHAR "name");
+		xmlTextWriterWriteString(writer, ISC_XMLCHAR typestr);
+		xmlTextWriterEndElement(writer); /* name */
+
+		xmlTextWriterStartElement(writer, ISC_XMLCHAR "counter");
+		xmlTextWriterWriteFormatString(writer,
+					       "%" ISC_PRINT_QUADFORMAT "u",
+					       val);
+		xmlTextWriterEndElement(writer); /* counter */
+
+		xmlTextWriterEndElement(writer); /* rdtype */
+#endif
+		break;
+	}
+}
+
+static void
+rdatasetstats_dump(dns_rdatastatstype_t type, isc_uint64_t val, void *arg) {
+	stats_dumparg_t *dumparg = arg;
+	FILE *fp;
+	char typebuf[64];
+	const char *typestr;
+	isc_boolean_t nxrrset = ISC_FALSE;
+#ifdef HAVE_LIBXML2
+	xmlTextWriterPtr writer;
+#endif
+
+	if ((DNS_RDATASTATSTYPE_ATTR(type) & DNS_RDATASTATSTYPE_ATTR_NXDOMAIN)
+	    != 0) {
+		typestr = "NXDOMAIN";
+	} else if ((DNS_RDATASTATSTYPE_ATTR(type) &
+		    DNS_RDATASTATSTYPE_ATTR_OTHERTYPE) != 0) {
+		typestr = "Others";
+	} else {
+		dns_rdatatype_format(DNS_RDATASTATSTYPE_BASE(type), typebuf,
+				     sizeof(typebuf));
+		typestr = typebuf;
+	}
+
+	if ((DNS_RDATASTATSTYPE_ATTR(type) & DNS_RDATASTATSTYPE_ATTR_NXRRSET)
+	    != 0)
+		nxrrset = ISC_TRUE;
+
+	switch (dumparg->type) {
+	case statsformat_file:
+		fp = dumparg->arg;
+		fprintf(fp, "%20" ISC_PRINT_QUADFORMAT "u %s%s\n", val,
+			nxrrset ? "!" : "", typestr);
+		break;
+	case statsformat_xml:
+#ifdef HAVE_LIBXML2
+		writer = dumparg->arg;
+
+		xmlTextWriterStartElement(writer, ISC_XMLCHAR "rrset");
+		xmlTextWriterStartElement(writer, ISC_XMLCHAR "name");
+		xmlTextWriterWriteFormatString(writer, "%s%s",
+					       nxrrset ? "!" : "", typestr);
+		xmlTextWriterEndElement(writer); /* name */
+
+		xmlTextWriterStartElement(writer, ISC_XMLCHAR "counter");
+		xmlTextWriterWriteFormatString(writer,
+					       "%" ISC_PRINT_QUADFORMAT "u",
+					       val);
+		xmlTextWriterEndElement(writer); /* counter */
+
+		xmlTextWriterEndElement(writer); /* rrset */
+#endif
+		break;
+	}
+}
+
+static void
+opcodestat_dump(dns_opcode_t code, isc_uint64_t val, void *arg) {
+	FILE *fp = arg;
+	isc_buffer_t b;
+	char codebuf[64];
+	stats_dumparg_t *dumparg = arg;
+#ifdef HAVE_LIBXML2
+	xmlTextWriterPtr writer;
+#endif
+
+	isc_buffer_init(&b, codebuf, sizeof(codebuf) - 1);
+	dns_opcode_totext(code, &b);
+	codebuf[isc_buffer_usedlength(&b)] = '\0';
+
+	switch (dumparg->type) {
+	case statsformat_file:
+		fp = dumparg->arg;
+		fprintf(fp, "%20" ISC_PRINT_QUADFORMAT "u %s\n", val, codebuf);
+		break;
+	case statsformat_xml:
+#ifdef HAVE_LIBXML2
+		writer = dumparg->arg;
+
+		xmlTextWriterStartElement(writer, ISC_XMLCHAR "opcode");
+
+		xmlTextWriterStartElement(writer, ISC_XMLCHAR "name");
+		xmlTextWriterWriteString(writer, ISC_XMLCHAR codebuf);
+		xmlTextWriterEndElement(writer); /* name */
+
+		xmlTextWriterStartElement(writer, ISC_XMLCHAR "counter");
+		xmlTextWriterWriteFormatString(writer,
+					       "%" ISC_PRINT_QUADFORMAT "u",
+					       val);
+		xmlTextWriterEndElement(writer); /* counter */
+
+		xmlTextWriterEndElement(writer); /* opcode */
+#endif
+		break;
+	}
+}
+
+#ifdef HAVE_LIBXML2
+
+/* XXXMLG below here sucks. */
+
+#define TRY(a) do { result = (a); INSIST(result == ISC_R_SUCCESS); } while(0);
+#define TRY0(a) do { xmlrc = (a); INSIST(xmlrc >= 0); } while(0);
+
+static isc_result_t
+zone_xmlrender(dns_zone_t *zone, void *arg) {
+	char buf[1024 + 32];	/* sufficiently large for zone name and class */
+	dns_rdataclass_t rdclass;
+	isc_uint32_t serial;
+	xmlTextWriterPtr writer = arg;
+	isc_stats_t *zonestats;
+	isc_uint64_t nsstat_values[dns_nsstatscounter_max];
+
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "zone");
+
+	dns_zone_name(zone, buf, sizeof(buf));
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "name");
+	xmlTextWriterWriteString(writer, ISC_XMLCHAR buf);
+	xmlTextWriterEndElement(writer);
+
+	rdclass = dns_zone_getclass(zone);
+	dns_rdataclass_format(rdclass, buf, sizeof(buf));
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "rdataclass");
+	xmlTextWriterWriteString(writer, ISC_XMLCHAR buf);
+	xmlTextWriterEndElement(writer);
+
+	serial = dns_zone_getserial(zone);
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "serial");
+	xmlTextWriterWriteFormatString(writer, "%u", serial);
+	xmlTextWriterEndElement(writer);
+
+	zonestats = dns_zone_getrequeststats(zone);
+	if (zonestats != NULL) {
+		xmlTextWriterStartElement(writer, ISC_XMLCHAR "counters");
+		dump_counters(zonestats, statsformat_xml, writer, NULL,
+			      nsstats_xmldesc, dns_nsstatscounter_max,
+			      nsstats_index, nsstat_values,
+			      ISC_STATSDUMP_VERBOSE);
+		xmlTextWriterEndElement(writer); /* counters */
+	}
+
+	xmlTextWriterEndElement(writer); /* zone */
+
+	return (ISC_R_SUCCESS);
+}
+
+static void
+generatexml(ns_server_t *server, int *buflen, xmlChar **buf) {
+	char boottime[sizeof "yyyy-mm-ddThh:mm:ssZ"];
+	char nowstr[sizeof "yyyy-mm-ddThh:mm:ssZ"];
+	isc_time_t now;
+	xmlTextWriterPtr writer;
+	xmlDocPtr doc;
+	int xmlrc;
+	dns_view_t *view;
+	stats_dumparg_t dumparg;
+	dns_stats_t *cachestats;
+	isc_uint64_t nsstat_values[dns_nsstatscounter_max];
+	isc_uint64_t resstat_values[dns_resstatscounter_max];
+	isc_uint64_t zonestat_values[dns_zonestatscounter_max];
+	isc_uint64_t sockstat_values[isc_sockstatscounter_max];
+
+	isc_time_now(&now);
+	isc_time_formatISO8601(&ns_g_boottime, boottime, sizeof boottime);
+	isc_time_formatISO8601(&now, nowstr, sizeof nowstr);
+
+	writer = xmlNewTextWriterDoc(&doc, 0);
+	TRY0(xmlTextWriterStartDocument(writer, NULL, "UTF-8", NULL));
+	TRY0(xmlTextWriterWritePI(writer, ISC_XMLCHAR "xml-stylesheet",
+			ISC_XMLCHAR "type=\"text/xsl\" href=\"/bind9.xsl\""));
+	TRY0(xmlTextWriterStartElement(writer, ISC_XMLCHAR "isc"));
+	TRY0(xmlTextWriterWriteAttribute(writer, ISC_XMLCHAR "version",
+					 ISC_XMLCHAR "1.0"));
+
+	TRY0(xmlTextWriterStartElement(writer, ISC_XMLCHAR "bind"));
+	TRY0(xmlTextWriterStartElement(writer, ISC_XMLCHAR "statistics"));
+	TRY0(xmlTextWriterWriteAttribute(writer, ISC_XMLCHAR "version",
+					 ISC_XMLCHAR "2.0"));
+
+	/* Set common fields for statistics dump */
+	dumparg.type = statsformat_xml;
+	dumparg.arg = writer;
+
+	/*
+	 * Start by rendering the views we know of here.  For each view we
+	 * know of, call its rendering function.
+	 */
+	view = ISC_LIST_HEAD(server->viewlist);
+	TRY0(xmlTextWriterStartElement(writer, ISC_XMLCHAR "views"));
+	while (view != NULL) {
+		xmlTextWriterStartElement(writer, ISC_XMLCHAR "view");
+
+		xmlTextWriterStartElement(writer, ISC_XMLCHAR "name");
+		xmlTextWriterWriteString(writer, ISC_XMLCHAR view->name);
+		xmlTextWriterEndElement(writer);
+
+		xmlTextWriterStartElement(writer, ISC_XMLCHAR "zones");
+		dns_zt_apply(view->zonetable, ISC_FALSE, zone_xmlrender,
+			     writer);
+		xmlTextWriterEndElement(writer);
+
+		if (view->resquerystats != NULL) {
+			dns_rdatatypestats_dump(view->resquerystats,
+						rdtypestat_dump, &dumparg, 0);
+		}
+
+		if (view->resstats != NULL) {
+			dump_counters(view->resstats, statsformat_xml, writer,
+				      "resstat", resstats_xmldesc,
+				      dns_resstatscounter_max, resstats_index,
+				      resstat_values, ISC_STATSDUMP_VERBOSE);
+		}
+
+		cachestats = dns_db_getrrsetstats(view->cachedb);
+		if (cachestats != NULL) {
+			xmlTextWriterStartElement(writer,
+						  ISC_XMLCHAR "cache");
+			dns_rdatasetstats_dump(cachestats, rdatasetstats_dump,
+					       &dumparg, 0);
+			xmlTextWriterEndElement(writer); /* cache */
+		}
+
+		xmlTextWriterEndElement(writer); /* view */
+
+		view = ISC_LIST_NEXT(view, link);
+	}
+	TRY0(xmlTextWriterEndElement(writer)); /* views */
+
+	TRY0(xmlTextWriterStartElement(writer, ISC_XMLCHAR "socketmgr"));
+	isc_socketmgr_renderxml(ns_g_socketmgr, writer);
+	TRY0(xmlTextWriterEndElement(writer)); /* socketmgr */
+
+	TRY0(xmlTextWriterStartElement(writer, ISC_XMLCHAR "taskmgr"));
+	isc_taskmgr_renderxml(ns_g_taskmgr, writer);
+	TRY0(xmlTextWriterEndElement(writer)); /* taskmgr */
+
+	TRY0(xmlTextWriterStartElement(writer, ISC_XMLCHAR "server"));
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "boot-time");
+	xmlTextWriterWriteString(writer, ISC_XMLCHAR boottime);
+	xmlTextWriterEndElement(writer);
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "current-time");
+	xmlTextWriterWriteString(writer, ISC_XMLCHAR nowstr);
+	xmlTextWriterEndElement(writer);
+
+	TRY0(xmlTextWriterStartElement(writer, ISC_XMLCHAR "requests"));
+	dns_opcodestats_dump(server->opcodestats, opcodestat_dump, &dumparg,
+			     0);
+	xmlTextWriterEndElement(writer); /* requests */
+
+	TRY0(xmlTextWriterStartElement(writer, ISC_XMLCHAR "queries-in"));
+	dns_rdatatypestats_dump(server->rcvquerystats, rdtypestat_dump,
+				&dumparg, 0);
+	xmlTextWriterEndElement(writer); /* queries-in */
+
+	dump_counters(server->nsstats, statsformat_xml, writer,
+		      "nsstat", nsstats_xmldesc, dns_nsstatscounter_max,
+		      nsstats_index, nsstat_values, ISC_STATSDUMP_VERBOSE);
+
+	dump_counters(server->zonestats, statsformat_xml, writer, "zonestat",
+		      zonestats_xmldesc, dns_zonestatscounter_max,
+		      zonestats_index, zonestat_values, ISC_STATSDUMP_VERBOSE);
+
+	/*
+	 * Most of the common resolver statistics entries are 0, so we don't
+	 * use the verbose dump here.
+	 */
+	dump_counters(server->resolverstats, statsformat_xml, writer, "resstat",
+		      resstats_xmldesc, dns_resstatscounter_max, resstats_index,
+		      resstat_values, 0);
+
+	dump_counters(server->sockstats, statsformat_xml, writer, "sockstat",
+		      sockstats_xmldesc, isc_sockstatscounter_max,
+		      sockstats_index, sockstat_values, ISC_STATSDUMP_VERBOSE);
+
+	xmlTextWriterEndElement(writer); /* server */
+
+	TRY0(xmlTextWriterStartElement(writer, ISC_XMLCHAR "memory"));
+	isc_mem_renderxml(writer);
+	TRY0(xmlTextWriterEndElement(writer)); /* memory */
+
+	TRY0(xmlTextWriterEndElement(writer)); /* statistics */
+	TRY0(xmlTextWriterEndElement(writer)); /* bind */
+	TRY0(xmlTextWriterEndElement(writer)); /* isc */
+
+	TRY0(xmlTextWriterEndDocument(writer));
+
+	xmlFreeTextWriter(writer);
+
+	xmlDocDumpFormatMemoryEnc(doc, buf, buflen, "UTF-8", 1);
+	xmlFreeDoc(doc);
+}
+
+static void
+wrap_xmlfree(isc_buffer_t *buffer, void *arg) {
+	UNUSED(arg);
+
+	xmlFree(isc_buffer_base(buffer));
+}
+
+static isc_result_t
+render_index(const char *url, const char *querystring, void *arg,
+	     unsigned int *retcode, const char **retmsg, const char **mimetype,
+	     isc_buffer_t *b, isc_httpdfree_t **freecb,
+	     void **freecb_args)
+{
+	unsigned char *msg;
+	int msglen;
+	ns_server_t *server = arg;
+
+	UNUSED(url);
+	UNUSED(querystring);
+
+	generatexml(server, &msglen, &msg);
+
+	*retcode = 200;
+	*retmsg = "OK";
+	*mimetype = "text/xml";
+	isc_buffer_reinit(b, msg, msglen);
+	isc_buffer_add(b, msglen);
+	*freecb = wrap_xmlfree;
+	*freecb_args = NULL;
+
+	return (ISC_R_SUCCESS);
+}
+
+#endif	/* HAVE_LIBXML2 */
+
+static isc_result_t
+render_xsl(const char *url, const char *querystring, void *args,
+	   unsigned int *retcode, const char **retmsg, const char **mimetype,
+	   isc_buffer_t *b, isc_httpdfree_t **freecb,
+	   void **freecb_args)
+{
+	UNUSED(url);
+	UNUSED(querystring);
+	UNUSED(args);
+
+	*retcode = 200;
+	*retmsg = "OK";
+	*mimetype = "text/xslt+xml";
+	isc_buffer_reinit(b, xslmsg, strlen(xslmsg));
+	isc_buffer_add(b, strlen(xslmsg));
+	*freecb = NULL;
+	*freecb_args = NULL;
+
+	return (ISC_R_SUCCESS);
+}
+
+static void
+shutdown_listener(ns_statschannel_t *listener) {
+	char socktext[ISC_SOCKADDR_FORMATSIZE];
+	isc_sockaddr_format(&listener->address, socktext, sizeof(socktext));
+	isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,NS_LOGMODULE_SERVER,
+		      ISC_LOG_NOTICE, "stopping statistics channel on %s",
+		      socktext);
+
+	isc_httpdmgr_shutdown(&listener->httpdmgr);
+}
+
+static isc_boolean_t
+client_ok(const isc_sockaddr_t *fromaddr, void *arg) {
+	ns_statschannel_t *listener = arg;
+	isc_netaddr_t netaddr;
+	char socktext[ISC_SOCKADDR_FORMATSIZE];
+	int match;
+
+	REQUIRE(listener != NULL);
+
+	isc_netaddr_fromsockaddr(&netaddr, fromaddr);
+
+	LOCK(&listener->lock);
+	if (dns_acl_match(&netaddr, NULL, listener->acl, &ns_g_server->aclenv,
+			  &match, NULL) == ISC_R_SUCCESS && match > 0) {
+		UNLOCK(&listener->lock);
+		return (ISC_TRUE);
+	}
+	UNLOCK(&listener->lock);
+
+	isc_sockaddr_format(fromaddr, socktext, sizeof(socktext));
+	isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
+		      NS_LOGMODULE_SERVER, ISC_LOG_WARNING,
+		      "rejected statistics connection from %s", socktext);
+
+	return (ISC_FALSE);
+}
+
+static void
+destroy_listener(void *arg) {
+	ns_statschannel_t *listener = arg;
+
+	REQUIRE(listener != NULL);
+	REQUIRE(!ISC_LINK_LINKED(listener, link));
+
+	/* We don't have to acquire the lock here since it's already unlinked */
+	dns_acl_detach(&listener->acl);
+
+	DESTROYLOCK(&listener->lock);
+	isc_mem_putanddetach(&listener->mctx, listener, sizeof(*listener));
+}
+
+static isc_result_t
+add_listener(ns_server_t *server, ns_statschannel_t **listenerp,
+	     const cfg_obj_t *listen_params, const cfg_obj_t *config,
+	     isc_sockaddr_t *addr, cfg_aclconfctx_t *aclconfctx,
+	     const char *socktext)
+{
+	isc_result_t result;
+	ns_statschannel_t *listener;
+	isc_task_t *task = NULL;
+	isc_socket_t *sock = NULL;
+	const cfg_obj_t *allow;
+	dns_acl_t *new_acl = NULL;
+
+	listener = isc_mem_get(server->mctx, sizeof(*listener));
+	if (listener == NULL)
+		return (ISC_R_NOMEMORY);
+
+	listener->httpdmgr = NULL;
+	listener->address = *addr;
+	listener->acl = NULL;
+	listener->mctx = NULL;
+	ISC_LINK_INIT(listener, link);
+
+	result = isc_mutex_init(&listener->lock);
+	if (result != ISC_R_SUCCESS) {
+		isc_mem_put(server->mctx, listener, sizeof(*listener));
+		return (ISC_R_FAILURE);
+	}
+
+	isc_mem_attach(server->mctx, &listener->mctx);
+
+	allow = cfg_tuple_get(listen_params, "allow");
+	if (allow != NULL && cfg_obj_islist(allow)) {
+		result = cfg_acl_fromconfig(allow, config, ns_g_lctx,
+					    aclconfctx, listener->mctx, 0,
+					    &new_acl);
+	} else
+		result = dns_acl_any(listener->mctx, &new_acl);
+	if (result != ISC_R_SUCCESS)
+		goto cleanup;
+	dns_acl_attach(new_acl, &listener->acl);
+	dns_acl_detach(&new_acl);
+
+	result = isc_task_create(ns_g_taskmgr, 0, &task);
+	if (result != ISC_R_SUCCESS)
+		goto cleanup;
+	isc_task_setname(task, "statchannel", NULL);
+
+	result = isc_socket_create(ns_g_socketmgr, isc_sockaddr_pf(addr),
+				   isc_sockettype_tcp, &sock);
+	if (result != ISC_R_SUCCESS)
+		goto cleanup;
+	isc_socket_setname(sock, "statchannel", NULL);
+
+#ifndef ISC_ALLOW_MAPPED
+	isc_socket_ipv6only(sock, ISC_TRUE);
+#endif
+
+	result = isc_socket_bind(sock, addr, ISC_SOCKET_REUSEADDRESS);
+	if (result != ISC_R_SUCCESS)
+		goto cleanup;
+
+	result = isc_httpdmgr_create(server->mctx, sock, task, client_ok,
+				     destroy_listener, listener, ns_g_timermgr,
+				     &listener->httpdmgr);
+	if (result != ISC_R_SUCCESS)
+		goto cleanup;
+
+#ifdef HAVE_LIBXML2
+	isc_httpdmgr_addurl(listener->httpdmgr, "/", render_index, server);
+#endif
+	isc_httpdmgr_addurl(listener->httpdmgr, "/bind9.xsl", render_xsl,
+			    server);
+
+	*listenerp = listener;
+	isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
+		      NS_LOGMODULE_SERVER, ISC_LOG_NOTICE,
+		      "statistics channel listening on %s", socktext);
+
+cleanup:
+	if (result != ISC_R_SUCCESS) {
+		if (listener->acl != NULL)
+			dns_acl_detach(&listener->acl);
+		DESTROYLOCK(&listener->lock);
+		isc_mem_putanddetach(&listener->mctx, listener,
+				     sizeof(*listener));
+	}
+	if (task != NULL)
+		isc_task_detach(&task);
+	if (sock != NULL)
+		isc_socket_detach(&sock);
+
+	return (result);
+}
+
+static void
+update_listener(ns_server_t *server, ns_statschannel_t **listenerp,
+		const cfg_obj_t *listen_params, const cfg_obj_t *config,
+		isc_sockaddr_t *addr, cfg_aclconfctx_t *aclconfctx,
+		const char *socktext)
+{
+	ns_statschannel_t *listener;
+	const cfg_obj_t *allow = NULL;
+	dns_acl_t *new_acl = NULL;
+	isc_result_t result = ISC_R_SUCCESS;
+
+	for (listener = ISC_LIST_HEAD(server->statschannels);
+	     listener != NULL;
+	     listener = ISC_LIST_NEXT(listener, link))
+		if (isc_sockaddr_equal(addr, &listener->address))
+			break;
+
+	if (listener == NULL) {
+		*listenerp = NULL;
+		return;
+	}
+
+	/*
+	 * Now, keep the old access list unless a new one can be made.
+	 */
+	allow = cfg_tuple_get(listen_params, "allow");
+	if (allow != NULL && cfg_obj_islist(allow)) {
+		result = cfg_acl_fromconfig(allow, config, ns_g_lctx,
+					    aclconfctx, listener->mctx, 0,
+					    &new_acl);
+	} else
+		result = dns_acl_any(listener->mctx, &new_acl);
+
+	if (result == ISC_R_SUCCESS) {
+		LOCK(&listener->lock);
+
+		dns_acl_detach(&listener->acl);
+		dns_acl_attach(new_acl, &listener->acl);
+		dns_acl_detach(&new_acl);
+
+		UNLOCK(&listener->lock);
+	} else {
+		cfg_obj_log(listen_params, ns_g_lctx, ISC_LOG_WARNING,
+			    "couldn't install new acl for "
+			    "statistics channel %s: %s",
+			    socktext, isc_result_totext(result));
+	}
+
+	*listenerp = listener;
+}
+
+isc_result_t
+ns_statschannels_configure(ns_server_t *server, const cfg_obj_t *config,
+			 cfg_aclconfctx_t *aclconfctx)
+{
+	ns_statschannel_t *listener, *listener_next;
+	ns_statschannellist_t new_listeners;
+	const cfg_obj_t *statschannellist = NULL;
+	const cfg_listelt_t *element, *element2;
+	char socktext[ISC_SOCKADDR_FORMATSIZE];
+
+	RUNTIME_CHECK(isc_once_do(&once, init_desc) == ISC_R_SUCCESS);
+
+	ISC_LIST_INIT(new_listeners);
+
+	/*
+	 * Get the list of named.conf 'statistics-channels' statements.
+	 */
+	(void)cfg_map_get(config, "statistics-channels", &statschannellist);
+
+	/*
+	 * Run through the new address/port list, noting sockets that are
+	 * already being listened on and moving them to the new list.
+	 *
+	 * Identifying duplicate addr/port combinations is left to either
+	 * the underlying config code, or to the bind attempt getting an
+	 * address-in-use error.
+	 */
+	if (statschannellist != NULL) {
+#ifndef HAVE_LIBXML2
+		isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
+			      NS_LOGMODULE_SERVER, ISC_LOG_WARNING,
+			      "statistics-channels specified but not effective "
+			      "due to missing XML library");
+#endif
+
+		for (element = cfg_list_first(statschannellist);
+		     element != NULL;
+		     element = cfg_list_next(element)) {
+			const cfg_obj_t *statschannel;
+			const cfg_obj_t *listenercfg = NULL;
+
+			statschannel = cfg_listelt_value(element);
+			(void)cfg_map_get(statschannel, "inet",
+					  &listenercfg);
+			if (listenercfg == NULL)
+				continue;
+
+			for (element2 = cfg_list_first(listenercfg);
+			     element2 != NULL;
+			     element2 = cfg_list_next(element2)) {
+				const cfg_obj_t *listen_params;
+				const cfg_obj_t *obj;
+				isc_sockaddr_t addr;
+
+				listen_params = cfg_listelt_value(element2);
+
+				obj = cfg_tuple_get(listen_params, "address");
+				addr = *cfg_obj_assockaddr(obj);
+				if (isc_sockaddr_getport(&addr) == 0)
+					isc_sockaddr_setport(&addr, NS_STATSCHANNEL_HTTPPORT);
+
+				isc_sockaddr_format(&addr, socktext,
+						    sizeof(socktext));
+
+				isc_log_write(ns_g_lctx,
+					      NS_LOGCATEGORY_GENERAL,
+					      NS_LOGMODULE_SERVER,
+					      ISC_LOG_DEBUG(9),
+					      "processing statistics "
+					      "channel %s",
+					      socktext);
+
+				update_listener(server, &listener,
+						listen_params, config, &addr,
+						aclconfctx, socktext);
+
+				if (listener != NULL) {
+					/*
+					 * Remove the listener from the old
+					 * list, so it won't be shut down.
+					 */
+					ISC_LIST_UNLINK(server->statschannels,
+							listener, link);
+				} else {
+					/*
+					 * This is a new listener.
+					 */
+					isc_result_t r;
+
+					r = add_listener(server, &listener,
+							 listen_params, config,
+							 &addr, aclconfctx,
+							 socktext);
+					if (r != ISC_R_SUCCESS) {
+						cfg_obj_log(listen_params,
+							    ns_g_lctx,
+							    ISC_LOG_WARNING,
+							    "couldn't allocate "
+							    "statistics channel"
+							    " %s: %s",
+							    socktext,
+							    isc_result_totext(r));
+					}
+				}
+
+				if (listener != NULL)
+					ISC_LIST_APPEND(new_listeners, listener,
+							link);
+			}
+		}
+	}
+
+	for (listener = ISC_LIST_HEAD(server->statschannels);
+	     listener != NULL;
+	     listener = listener_next) {
+		listener_next = ISC_LIST_NEXT(listener, link);
+		ISC_LIST_UNLINK(server->statschannels, listener, link);
+		shutdown_listener(listener);
+	}
+
+	ISC_LIST_APPENDLIST(server->statschannels, new_listeners, link);
+	return (ISC_R_SUCCESS);
+}
+
+void
+ns_statschannels_shutdown(ns_server_t *server) {
+	ns_statschannel_t *listener;
+
+	while ((listener = ISC_LIST_HEAD(server->statschannels)) != NULL) {
+		ISC_LIST_UNLINK(server->statschannels, listener, link);
+		shutdown_listener(listener);
+	}
+}
+
+isc_result_t
+ns_stats_dump(ns_server_t *server, FILE *fp) {
+	isc_stdtime_t now;
+	isc_result_t result;
+	dns_view_t *view;
+	dns_zone_t *zone, *next;
+	stats_dumparg_t dumparg;
+	isc_uint64_t nsstat_values[dns_nsstatscounter_max];
+	isc_uint64_t resstat_values[dns_resstatscounter_max];
+	isc_uint64_t zonestat_values[dns_zonestatscounter_max];
+	isc_uint64_t sockstat_values[isc_sockstatscounter_max];
+
+	RUNTIME_CHECK(isc_once_do(&once, init_desc) == ISC_R_SUCCESS);
+
+	/* Set common fields */
+	dumparg.type = statsformat_file;
+	dumparg.arg = fp;
+
+	isc_stdtime_get(&now);
+	fprintf(fp, "+++ Statistics Dump +++ (%lu)\n", (unsigned long)now);
+
+	fprintf(fp, "++ Incoming Requests ++\n");
+	dns_opcodestats_dump(server->opcodestats, opcodestat_dump, &dumparg, 0);
+
+	fprintf(fp, "++ Incoming Queries ++\n");
+	dns_rdatatypestats_dump(server->rcvquerystats, rdtypestat_dump,
+				&dumparg, 0);
+
+	fprintf(fp, "++ Outgoing Queries ++\n");
+	for (view = ISC_LIST_HEAD(server->viewlist);
+	     view != NULL;
+	     view = ISC_LIST_NEXT(view, link)) {
+		if (view->resquerystats == NULL)
+			continue;
+		if (strcmp(view->name, "_default") == 0)
+			fprintf(fp, "[View: default]\n");
+		else
+			fprintf(fp, "[View: %s]\n", view->name);
+		dns_rdatatypestats_dump(view->resquerystats, rdtypestat_dump,
+					&dumparg, 0);
+	}
+
+	fprintf(fp, "++ Name Server Statistics ++\n");
+	dump_counters(server->nsstats, statsformat_file, fp, NULL,
+		      nsstats_desc, dns_nsstatscounter_max, nsstats_index,
+		      nsstat_values, 0);
+
+	fprintf(fp, "++ Zone Maintenance Statistics ++\n");
+	dump_counters(server->zonestats, statsformat_file, fp, NULL,
+		      zonestats_desc, dns_zonestatscounter_max,
+		      zonestats_index, zonestat_values, 0);
+
+	fprintf(fp, "++ Resolver Statistics ++\n");
+	fprintf(fp, "[Common]\n");
+	dump_counters(server->resolverstats, statsformat_file, fp, NULL,
+		      resstats_desc, dns_resstatscounter_max, resstats_index,
+		      resstat_values, 0);
+	for (view = ISC_LIST_HEAD(server->viewlist);
+	     view != NULL;
+	     view = ISC_LIST_NEXT(view, link)) {
+		if (view->resstats == NULL)
+			continue;
+		if (strcmp(view->name, "_default") == 0)
+			fprintf(fp, "[View: default]\n");
+		else
+			fprintf(fp, "[View: %s]\n", view->name);
+		dump_counters(view->resstats, statsformat_file, fp, NULL,
+			      resstats_desc, dns_resstatscounter_max,
+			      resstats_index, resstat_values, 0);
+	}
+
+	fprintf(fp, "++ Cache DB RRsets ++\n");
+	for (view = ISC_LIST_HEAD(server->viewlist);
+	     view != NULL;
+	     view = ISC_LIST_NEXT(view, link)) {
+		dns_stats_t *cachestats;
+
+		cachestats = dns_db_getrrsetstats(view->cachedb);
+		if (cachestats == NULL)
+			continue;
+		if (strcmp(view->name, "_default") == 0)
+			fprintf(fp, "[View: default]\n");
+		else
+			fprintf(fp, "[View: %s]\n", view->name);
+		dns_rdatasetstats_dump(cachestats, rdatasetstats_dump, &dumparg,
+				       0);
+	}
+
+	fprintf(fp, "++ Socket I/O Statistics ++\n");
+	dump_counters(server->sockstats, statsformat_file, fp, NULL,
+		      sockstats_desc, isc_sockstatscounter_max, sockstats_index,
+		      sockstat_values, 0);
+
+	fprintf(fp, "++ Per Zone Query Statistics ++\n");
+	zone = NULL;
+	for (result = dns_zone_first(server->zonemgr, &zone);
+	     result == ISC_R_SUCCESS;
+	     next = NULL, result = dns_zone_next(zone, &next), zone = next)
+	{
+		isc_stats_t *zonestats = dns_zone_getrequeststats(zone);
+		if (zonestats != NULL) {
+			char zonename[DNS_NAME_FORMATSIZE];
+
+			dns_name_format(dns_zone_getorigin(zone),
+					zonename, sizeof(zonename));
+			view = dns_zone_getview(zone);
+
+			fprintf(fp, "[%s", zonename);
+			if (strcmp(view->name, "_default") != 0)
+				fprintf(fp, " (view: %s)", view->name);
+			fprintf(fp, "]\n");
+
+			dump_counters(zonestats, statsformat_file, fp, NULL,
+				      nsstats_desc, dns_nsstatscounter_max,
+				      nsstats_index, nsstat_values, 0);
+		}
+	}
+
+	fprintf(fp, "--- Statistics Dump --- (%lu)\n", (unsigned long)now);
+
+	return (ISC_R_SUCCESS);	/* this function currently always succeeds */
+}
diff --git a/contrib/bind9/bin/named/tkeyconf.c b/contrib/bind9/bin/named/tkeyconf.c
index 3c843ac..82cf573 100644
--- a/contrib/bind9/bin/named/tkeyconf.c
+++ b/contrib/bind9/bin/named/tkeyconf.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: tkeyconf.c,v 1.20.18.6 2006/03/02 00:37:21 marka Exp $ */
+/* $Id: tkeyconf.c,v 1.29 2007/06/19 23:46:59 tbox Exp $ */
 
 /*! \file */
 
@@ -42,6 +42,13 @@
 		goto failure; \
 	} while (0)
 
+#include<named/log.h>
+#define LOG(msg) \
+	isc_log_write(ns_g_lctx, \
+	NS_LOGCATEGORY_GENERAL, \
+	NS_LOGMODULE_SERVER, \
+	ISC_LOG_ERROR, \
+	"%s", msg)
 
 isc_result_t
 ns_tkeyctx_fromconfig(const cfg_obj_t *options, isc_mem_t *mctx,
@@ -100,6 +107,7 @@ ns_tkeyctx_fromconfig(const cfg_obj_t *options, isc_mem_t *mctx,
 	result = cfg_map_get(options, "tkey-gssapi-credential", &obj);
 	if (result == ISC_R_SUCCESS) {
 		s = cfg_obj_asstring(obj);
+
 		isc_buffer_init(&b, s, strlen(s));
 		isc_buffer_add(&b, strlen(s));
 		dns_fixedname_init(&fname);
diff --git a/contrib/bind9/bin/named/tsigconf.c b/contrib/bind9/bin/named/tsigconf.c
index 7fa7fe5..b3c6e02 100644
--- a/contrib/bind9/bin/named/tsigconf.c
+++ b/contrib/bind9/bin/named/tsigconf.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: tsigconf.c,v 1.22.18.6 2006/02/28 03:10:47 marka Exp $ */
+/* $Id: tsigconf.c,v 1.30 2007/06/19 23:46:59 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/bin/named/unix/Makefile.in b/contrib/bind9/bin/named/unix/Makefile.in
index a18351a..5092834 100644
--- a/contrib/bind9/bin/named/unix/Makefile.in
+++ b/contrib/bind9/bin/named/unix/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1999-2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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 2004/03/05 04:58:01 marka Exp $
+# $Id: Makefile.in,v 1.10 2007/06/19 23:46:59 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/bin/named/unix/include/named/os.h b/contrib/bind9/bin/named/unix/include/named/os.h
index 6c603dc..d03bf75 100644
--- a/contrib/bind9/bin/named/unix/include/named/os.h
+++ b/contrib/bind9/bin/named/unix/include/named/os.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: os.h,v 1.22.18.5 2008/10/24 01:43:17 tbox Exp $ */
+/* $Id: os.h,v 1.29 2008/10/24 01:44:48 tbox Exp $ */
 
 #ifndef NS_OS_H
 #define NS_OS_H 1
diff --git a/contrib/bind9/bin/named/unix/os.c b/contrib/bind9/bin/named/unix/os.c
index ad26a8e..5e6b98f 100644
--- a/contrib/bind9/bin/named/unix/os.c
+++ b/contrib/bind9/bin/named/unix/os.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: os.c,v 1.66.18.17 2008/10/24 01:43:17 tbox Exp $ */
+/* $Id: os.c,v 1.89.12.5 2009/03/02 03:03:54 marka Exp $ */
 
 /*! \file */
 
@@ -70,7 +70,7 @@ static int devnullfd = -1;
 /*
  * Linux defines:
  *	(T) HAVE_LINUXTHREADS
- *	(C) HAVE_LINUX_CAPABILITY_H
+ *	(C) HAVE_SYS_CAPABILITY_H (or HAVE_LINUX_CAPABILITY_H)
  *	(P) HAVE_SYS_PRCTL_H
  * The possible cases are:
  *	none:	setuid() normally
@@ -117,16 +117,9 @@ static int dfd[2] = { -1, -1 };
 static isc_boolean_t non_root = ISC_FALSE;
 static isc_boolean_t non_root_caps = ISC_FALSE;
 
-#if defined(HAVE_CAPSET)
-#undef _POSIX_SOURCE
 #ifdef HAVE_SYS_CAPABILITY_H
 #include <sys/capability.h>
 #else
-#include <linux/capability.h>
-int capset(cap_user_header_t hdrp, const cap_user_data_t datap);
-#endif
-#include <sys/prctl.h>
-#else
 /*%
  * We define _LINUX_FS_H to prevent it from being included.  We don't need
  * anything from it, and the files it includes cause warnings with 2.2
@@ -134,9 +127,15 @@ int capset(cap_user_header_t hdrp, const cap_user_data_t datap);
  * and <string.h>) on 2.3 kernels.
  */
 #define _LINUX_FS_H
-
-#include <sys/syscall.h>	/* Required for syscall(). */
-#include <linux/capability.h>	/* Required for _LINUX_CAPABILITY_VERSION. */
+#include <linux/capability.h>
+#include <syscall.h>
+#ifndef SYS_capset
+#ifndef __NR_capset
+#include <asm/unistd.h> /* Slackware 4.0 needs this. */
+#endif /* __NR_capset */
+#define SYS_capset __NR_capset
+#endif /* SYS_capset */
+#endif /* HAVE_SYS_CAPABILITY_H */
 
 #ifdef HAVE_SYS_PRCTL_H
 #include <sys/prctl.h>		/* Required for prctl(). */
@@ -153,23 +152,24 @@ int capset(cap_user_header_t hdrp, const cap_user_data_t datap);
 
 #endif /* HAVE_SYS_PRCTL_H */
 
-#ifndef SYS_capset
-#ifndef __NR_capset
-#include <asm/unistd.h> /* Slackware 4.0 needs this. */
-#endif
-#define SYS_capset __NR_capset
-#endif
-#endif
+#ifdef HAVE_LIBCAP
+#define SETCAPS_FUNC "cap_set_proc "
+#else
+typedef unsigned int cap_t;
+#define SETCAPS_FUNC "syscall(capset) "
+#endif /* HAVE_LIBCAP */
 
 static void
-linux_setcaps(unsigned int caps) {
+linux_setcaps(cap_t caps) {
+#ifndef HAVE_LIBCAP
 	struct __user_cap_header_struct caphead;
 	struct __user_cap_data_struct cap;
+#endif
 	char strbuf[ISC_STRERRORSIZE];
 
 	if ((getuid() != 0 && !non_root_caps) || non_root)
 		return;
-
+#ifndef HAVE_LIBCAP
 	memset(&caphead, 0, sizeof(caphead));
 	caphead.version = _LINUX_CAPABILITY_VERSION;
 	caphead.pid = 0;
@@ -177,46 +177,89 @@ linux_setcaps(unsigned int caps) {
 	cap.effective = caps;
 	cap.permitted = caps;
 	cap.inheritable = 0;
-#ifdef HAVE_CAPSET
-	if (capset(&caphead, &cap) < 0 ) {
-		isc__strerror(errno, strbuf, sizeof(strbuf));
-		ns_main_earlyfatal("capset failed: %s:"
-				   " please ensure that the capset kernel"
-				   " module is loaded.  see insmod(8)",
-				   strbuf);
-	}
+#endif
+#ifdef HAVE_LIBCAP
+	if (cap_set_proc(caps) < 0) {
 #else
 	if (syscall(SYS_capset, &caphead, &cap) < 0) {
+#endif
 		isc__strerror(errno, strbuf, sizeof(strbuf));
-		ns_main_earlyfatal("syscall(capset) failed: %s:"
+		ns_main_earlyfatal(SETCAPS_FUNC "failed: %s:"
 				   " please ensure that the capset kernel"
 				   " module is loaded.  see insmod(8)",
 				   strbuf);
 	}
-#endif
 }
 
+#ifdef HAVE_LIBCAP
+#define SET_CAP(flag) \
+	do { \
+		capval = (flag); \
+		cap_flag_value_t curval; \
+		err = cap_get_flag(curcaps, capval, CAP_PERMITTED, &curval); \
+		if (err != -1 && curval) { \
+			err = cap_set_flag(caps, CAP_EFFECTIVE, 1, &capval, CAP_SET); \
+			if (err == -1) { \
+				isc__strerror(errno, strbuf, sizeof(strbuf)); \
+				ns_main_earlyfatal("cap_set_proc failed: %s", strbuf); \
+			} \
+			\
+			err = cap_set_flag(caps, CAP_PERMITTED, 1, &capval, CAP_SET); \
+			if (err == -1) { \
+				isc__strerror(errno, strbuf, sizeof(strbuf)); \
+				ns_main_earlyfatal("cap_set_proc failed: %s", strbuf); \
+			} \
+		} \
+	} while (0)
+#define INIT_CAP \
+	do { \
+		caps = cap_init(); \
+		if (caps == NULL) { \
+			isc__strerror(errno, strbuf, sizeof(strbuf)); \
+			ns_main_earlyfatal("cap_init failed: %s", strbuf); \
+		} \
+		curcaps = cap_get_proc(); \
+		if (curcaps == NULL) { \
+			isc__strerror(errno, strbuf, sizeof(strbuf)); \
+			ns_main_earlyfatal("cap_get_proc failed: %s", strbuf); \
+		} \
+	} while (0)
+#define FREE_CAP \
+	{ \
+		cap_free(caps); \
+		cap_free(curcaps); \
+	} while (0)
+#else
+#define SET_CAP(flag) do { caps |= (1 << (flag)); } while (0)
+#define INIT_CAP do { caps = 0; } while (0)
+#endif /* HAVE_LIBCAP */
+
 static void
 linux_initialprivs(void) {
-	unsigned int caps;
+	cap_t caps;
+#ifdef HAVE_LIBCAP
+	cap_t curcaps;
+	cap_value_t capval;
+	char strbuf[ISC_STRERRORSIZE];
+	int err;
+#endif
 
 	/*%
 	 * We don't need most privileges, so we drop them right away.
 	 * Later on linux_minprivs() will be called, which will drop our
 	 * capabilities to the minimum needed to run the server.
 	 */
-
-	caps = 0;
+	INIT_CAP;
 
 	/*
 	 * We need to be able to bind() to privileged ports, notably port 53!
 	 */
-	caps |= (1 << CAP_NET_BIND_SERVICE);
+	SET_CAP(CAP_NET_BIND_SERVICE);
 
 	/*
 	 * We need chroot() initially too.
 	 */
-	caps |= (1 << CAP_SYS_CHROOT);
+	SET_CAP(CAP_SYS_CHROOT);
 
 #if defined(HAVE_SYS_PRCTL_H) || !defined(HAVE_LINUXTHREADS)
 	/*
@@ -225,19 +268,19 @@ linux_initialprivs(void) {
 	 * tried) or we're not using threads.  If either of these is
 	 * true, we want the setuid capability.
 	 */
-	caps |= (1 << CAP_SETUID);
+	SET_CAP(CAP_SETUID);
 #endif
 
 	/*
 	 * Since we call initgroups, we need this.
 	 */
-	caps |= (1 << CAP_SETGID);
+	SET_CAP(CAP_SETGID);
 
 	/*
 	 * Without this, we run into problems reading a configuration file
 	 * owned by a non-root user and non-world-readable on startup.
 	 */
-	caps |= (1 << CAP_DAC_READ_SEARCH);
+	SET_CAP(CAP_DAC_READ_SEARCH);
 
 	/*
 	 * XXX  We might want to add CAP_SYS_RESOURCE, though it's not
@@ -246,15 +289,26 @@ linux_initialprivs(void) {
 	 * of files, the stack size, data size, and core dump size to
 	 * support named.conf options, this is now being added to test.
 	 */
-	caps |= (1 << CAP_SYS_RESOURCE);
+	SET_CAP(CAP_SYS_RESOURCE);
 
 	linux_setcaps(caps);
+
+#ifdef HAVE_LIBCAP
+	FREE_CAP;
+#endif
 }
 
 static void
 linux_minprivs(void) {
-	unsigned int caps;
+	cap_t caps;
+#ifdef HAVE_LIBCAP
+	cap_t curcaps;
+	cap_value_t capval;
+	char strbuf[ISC_STRERRORSIZE];
+	int err;
+#endif
 
+	INIT_CAP;
 	/*%
 	 * Drop all privileges except the ability to bind() to privileged
 	 * ports.
@@ -263,8 +317,7 @@ linux_minprivs(void) {
 	 * chroot() could be used to escape from the chrooted area.
 	 */
 
-	caps = 0;
-	caps |= (1 << CAP_NET_BIND_SERVICE);
+	SET_CAP(CAP_NET_BIND_SERVICE);
 
 	/*
 	 * XXX  We might want to add CAP_SYS_RESOURCE, though it's not
@@ -273,9 +326,13 @@ linux_minprivs(void) {
 	 * of files, the stack size, data size, and core dump size to
 	 * support named.conf options, this is now being added to test.
 	 */
-	caps |= (1 << CAP_SYS_RESOURCE);
+	SET_CAP(CAP_SYS_RESOURCE);
 
 	linux_setcaps(caps);
+
+#ifdef HAVE_LIBCAP
+	FREE_CAP;
+#endif
 }
 
 #ifdef HAVE_SYS_PRCTL_H
@@ -405,10 +462,12 @@ ns_os_started(void) {
 	char buf = 0;
 
 	/*
-	 * Signal to the parent that we stated successfully.
+	 * Signal to the parent that we started successfully.
 	 */
 	if (dfd[0] != -1 && dfd[1] != -1) {
-		write(dfd[1], &buf, 1);
+		if (write(dfd[1], &buf, 1) != 1)
+			ns_main_earlyfatal("unable to signal parent that we "
+					   "otherwise started successfully.");
 		close(dfd[1]);
 		dfd[0] = dfd[1] = -1;
 	}
@@ -448,10 +507,14 @@ ns_os_chroot(const char *root) {
 	ns_smf_chroot = 0;
 #endif
 	if (root != NULL) {
+#ifdef HAVE_CHROOT
 		if (chroot(root) < 0) {
 			isc__strerror(errno, strbuf, sizeof(strbuf));
 			ns_main_earlyfatal("chroot(): %s", strbuf);
 		}
+#else
+		ns_main_earlyfatal("chroot(): disabled");
+#endif
 		if (chdir("/") < 0) {
 			isc__strerror(errno, strbuf, sizeof(strbuf));
 			ns_main_earlyfatal("chdir(/): %s", strbuf);
@@ -584,7 +647,8 @@ safe_open(const char *filename, isc_boolean_t append) {
 		fd = open(filename, O_WRONLY|O_CREAT|O_APPEND,
 			  S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH);
 	else {
-		(void)unlink(filename);
+		if (unlink(filename) < 0 && errno != ENOENT)
+			return (-1);
 		fd = open(filename, O_WRONLY|O_CREAT|O_EXCL,
 			  S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH);
 	}
@@ -593,13 +657,54 @@ safe_open(const char *filename, isc_boolean_t append) {
 
 static void
 cleanup_pidfile(void) {
+	int n;
 	if (pidfile != NULL) {
-		(void)unlink(pidfile);
+		n = unlink(pidfile);
+		if (n == -1 && errno != ENOENT)
+			ns_main_earlywarning("unlink '%s': failed", pidfile);
 		free(pidfile);
 	}
 	pidfile = NULL;
 }
 
+static int
+mkdirpath(char *filename, void (*report)(const char *, ...)) {
+	char *slash = strrchr(filename, '/');
+	char strbuf[ISC_STRERRORSIZE];
+	unsigned int mode;
+
+	if (slash != NULL && slash != filename) {
+		struct stat sb;
+		*slash = '\0';
+
+		if (stat(filename, &sb) == -1) {
+			if (errno != ENOENT) {
+				isc__strerror(errno, strbuf, sizeof(strbuf));
+				(*report)("couldn't stat '%s': %s", filename,
+					  strbuf);
+				goto error;
+			}
+			if (mkdirpath(filename, report) == -1)
+				goto error;
+			mode = S_IRUSR | S_IWUSR | S_IXUSR;	/* u=rwx */
+			mode |= S_IRGRP | S_IXGRP;		/* g=rx */
+			mode |= S_IROTH | S_IXOTH;		/* o=rx */
+			if (mkdir(filename, mode) == -1) {
+				isc__strerror(errno, strbuf, sizeof(strbuf));
+				(*report)("couldn't mkdir '%s': %s", filename,
+					  strbuf);
+				goto error;
+			}
+		}
+		*slash = '/';
+	}
+	return (0);
+
+ error:
+	*slash = '/';
+	return (-1);
+}
+
 void
 ns_os_writepidfile(const char *filename, isc_boolean_t first_time) {
 	int fd;
@@ -627,9 +732,19 @@ ns_os_writepidfile(const char *filename, isc_boolean_t first_time) {
 		(*report)("couldn't malloc '%s': %s", filename, strbuf);
 		return;
 	}
+
 	/* This is safe. */
 	strcpy(pidfile, filename);
 
+	/*
+	 * Make the containing directory if it doesn't exist.
+	 */
+	if (mkdirpath(pidfile, report) == -1) {
+		free(pidfile);
+		pidfile = NULL;
+		return;
+	}
+
 	fd = safe_open(filename, ISC_FALSE);
 	if (fd < 0) {
 		isc__strerror(errno, strbuf, sizeof(strbuf));
diff --git a/contrib/bind9/bin/named/update.c b/contrib/bind9/bin/named/update.c
index fb6dec2..ff07311 100644
--- a/contrib/bind9/bin/named/update.c
+++ b/contrib/bind9/bin/named/update.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,11 +15,14 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: update.c,v 1.109.18.27 2008/02/07 03:16:08 marka Exp $ */
+/* $Id: update.c,v 1.151.12.5 2009/04/30 07:03:37 marka Exp $ */
 
 #include <config.h>
 
+#include <isc/netaddr.h>
 #include <isc/print.h>
+#include <isc/serial.h>
+#include <isc/stats.h>
 #include <isc/string.h>
 #include <isc/taskpool.h>
 #include <isc/util.h>
@@ -34,6 +37,7 @@
 #include <dns/keyvalues.h>
 #include <dns/message.h>
 #include <dns/nsec.h>
+#include <dns/nsec3.h>
 #include <dns/rdataclass.h>
 #include <dns/rdataset.h>
 #include <dns/rdatasetiter.h>
@@ -47,6 +51,7 @@
 
 #include <named/client.h>
 #include <named/log.h>
+#include <named/server.h>
 #include <named/update.h>
 
 /*! \file
@@ -55,9 +60,9 @@
  */
 
 /*
-  XXX TODO:
-  - document strict minimality
-*/
+ *  XXX TODO:
+ * - document strict minimality
+ */
 
 /**************************************************************************/
 
@@ -69,7 +74,7 @@
 /*%
  * Log level for low-level debug tracing.
  */
-#define LOGLEVEL_DEBUG 		ISC_LOG_DEBUG(8)
+#define LOGLEVEL_DEBUG		ISC_LOG_DEBUG(8)
 
 /*%
  * Check an operation for failure.  These macros all assume that
@@ -77,8 +82,8 @@
  * label.
  */
 #define CHECK(op) \
-	do { result = (op); 				  	 \
-	       if (result != ISC_R_SUCCESS) goto failure; 	 \
+	do { result = (op); \
+		if (result != ISC_R_SUCCESS) goto failure; \
 	} while (0)
 
 /*%
@@ -112,11 +117,16 @@
 		case DNS_R_NXRRSET:				\
 			_what = "unsuccessful";			\
 		}						\
-		update_log(client, zone, LOGLEVEL_PROTOCOL,   	\
-			      "update %s: %s (%s)", _what,	\
-			      msg, isc_result_totext(result));	\
+		update_log(client, zone, LOGLEVEL_PROTOCOL,	\
+			   "update %s: %s (%s)", _what,		\
+			   msg, isc_result_totext(result));	\
 		if (result != ISC_R_SUCCESS) goto failure;	\
 	} while (0)
+#define PREREQFAILC(code, msg) \
+	do {							\
+		inc_stats(zone, dns_nsstatscounter_updatebadprereq); \
+		FAILC(code, msg);				\
+	} while (0)
 
 #define FAILN(code, name, msg) \
 	do {								\
@@ -132,12 +142,17 @@
 		if (isc_log_wouldlog(ns_g_lctx, LOGLEVEL_PROTOCOL)) {	\
 			char _nbuf[DNS_NAME_FORMATSIZE];		\
 			dns_name_format(name, _nbuf, sizeof(_nbuf));	\
-			update_log(client, zone, LOGLEVEL_PROTOCOL,   	\
+			update_log(client, zone, LOGLEVEL_PROTOCOL,	\
 				   "update %s: %s: %s (%s)", _what, _nbuf, \
 				   msg, isc_result_totext(result));	\
 		}							\
 		if (result != ISC_R_SUCCESS) goto failure;		\
 	} while (0)
+#define PREREQFAILN(code, name, msg) \
+	do {								\
+		inc_stats(zone, dns_nsstatscounter_updatebadprereq); \
+		FAILN(code, name, msg);					\
+	} while (0)
 
 #define FAILNT(code, name, type, msg) \
 	do {								\
@@ -155,13 +170,19 @@
 			char _tbuf[DNS_RDATATYPE_FORMATSIZE];		\
 			dns_name_format(name, _nbuf, sizeof(_nbuf));	\
 			dns_rdatatype_format(type, _tbuf, sizeof(_tbuf)); \
-			update_log(client, zone, LOGLEVEL_PROTOCOL,   	\
+			update_log(client, zone, LOGLEVEL_PROTOCOL,	\
 				   "update %s: %s/%s: %s (%s)",		\
 				   _what, _nbuf, _tbuf, msg,		\
 				   isc_result_totext(result));		\
 		}							\
 		if (result != ISC_R_SUCCESS) goto failure;		\
 	} while (0)
+#define PREREQFAILNT(code, name, type, msg)				\
+	do {								\
+		inc_stats(zone, dns_nsstatscounter_updatebadprereq); \
+		FAILNT(code, name, type, msg);				\
+	} while (0)
+
 /*%
  * Fail unconditionally and log as a server error.
  * The test against ISC_R_SUCCESS is there to keep the Solaris compiler
@@ -171,26 +192,31 @@
 	do {							\
 		result = (code);				\
 		update_log(client, zone, LOGLEVEL_PROTOCOL,	\
-			      "error: %s: %s", 			\
-			      msg, isc_result_totext(result));	\
+			   "error: %s: %s",			\
+			   msg, isc_result_totext(result));	\
 		if (result != ISC_R_SUCCESS) goto failure;	\
 	} while (0)
 
+/*
+ * Return TRUE if NS_CLIENTATTR_TCP is set in the attributes other FALSE.
+ */
+#define TCPCLIENT(client) (((client)->attributes & NS_CLIENTATTR_TCP) != 0)
+
 /**************************************************************************/
 
 typedef struct rr rr_t;
 
 struct rr {
 	/* dns_name_t name; */
-	isc_uint32_t 		ttl;
-	dns_rdata_t 		rdata;
+	isc_uint32_t		ttl;
+	dns_rdata_t		rdata;
 };
 
 typedef struct update_event update_event_t;
 
 struct update_event {
 	ISC_EVENT_COMMON(update_event_t);
-	dns_zone_t 		*zone;
+	dns_zone_t		*zone;
 	isc_result_t		result;
 	dns_message_t		*answer;
 };
@@ -240,9 +266,38 @@ update_log(ns_client_t *client, dns_zone_t *zone,
 		      namebuf, classbuf, message);
 }
 
+/*%
+ * Increment updated-related statistics counters.
+ */
+static inline void
+inc_stats(dns_zone_t *zone, isc_statscounter_t counter) {
+	isc_stats_increment(ns_g_server->nsstats, counter);
+
+	if (zone != NULL) {
+		isc_stats_t *zonestats = dns_zone_getrequeststats(zone);
+		if (zonestats != NULL)
+			isc_stats_increment(zonestats, counter);
+	}
+}
+
+/*%
+ * Override the default acl logging when checking whether a client
+ * can update the zone or whether we can forward the request to the
+ * master based on IP address.
+ *
+ * 'message' contains the type of operation that is being attempted.
+ * 'slave' indicates if this is a slave zone.  If 'acl' is NULL then
+ * log at debug=3.
+ * If the zone has no access controls configured ('acl' == NULL &&
+ * 'has_ssutable == ISC_FALS) log the attempt at info, otherwise
+ * at error.
+ *
+ * If the request was signed log that we received it.
+ */
 static isc_result_t
 checkupdateacl(ns_client_t *client, dns_acl_t *acl, const char *message,
-	       dns_name_t *zonename, isc_boolean_t slave)
+	       dns_name_t *zonename, isc_boolean_t slave,
+	       isc_boolean_t has_ssutable)
 {
 	char namebuf[DNS_NAME_FORMATSIZE];
 	char classbuf[DNS_RDATACLASS_FORMATSIZE];
@@ -254,12 +309,21 @@ checkupdateacl(ns_client_t *client, dns_acl_t *acl, const char *message,
 		result = DNS_R_NOTIMP;
 		level = ISC_LOG_DEBUG(3);
 		msg = "disabled";
-	} else
-		result = ns_client_checkaclsilent(client, acl, ISC_FALSE);
+	} else {
+		result = ns_client_checkaclsilent(client, NULL, acl, ISC_FALSE);
+		if (result == ISC_R_SUCCESS) {
+			level = ISC_LOG_DEBUG(3);
+			msg = "approved";
+		} else if (acl == NULL && !has_ssutable) {
+			level = ISC_LOG_INFO;
+		}
+	}
 
-	if (result == ISC_R_SUCCESS) {
-		level = ISC_LOG_DEBUG(3);
-		msg = "approved";
+	if (client->signer != NULL) {
+		dns_name_format(client->signer, namebuf, sizeof(namebuf));
+		ns_client_log(client, NS_LOGCATEGORY_UPDATE_SECURITY,
+			      NS_LOGMODULE_UPDATE, ISC_LOG_INFO,
+			      "signer \"%s\" %s", namebuf, msg);
 	}
 
 	dns_name_format(zonename, namebuf, sizeof(namebuf));
@@ -267,8 +331,8 @@ checkupdateacl(ns_client_t *client, dns_acl_t *acl, const char *message,
 			      sizeof(classbuf));
 
 	ns_client_log(client, NS_LOGCATEGORY_UPDATE_SECURITY,
-			      NS_LOGMODULE_UPDATE, level, "%s '%s/%s' %s",
-			      message, namebuf, classbuf, msg);
+		      NS_LOGMODULE_UPDATE, level, "%s '%s/%s' %s",
+		      message, namebuf, classbuf, msg);
 	return (result);
 }
 
@@ -277,12 +341,11 @@ checkupdateacl(ns_client_t *client, dns_acl_t *acl, const char *message,
  * update in 'diff'.
  *
  * Ensures:
- * \li  '*tuple' == NULL.  Either the tuple is freed, or its
- *         ownership has been transferred to the diff.
+ * \li	'*tuple' == NULL.  Either the tuple is freed, or its
+ *	ownership has been transferred to the diff.
  */
 static isc_result_t
-do_one_tuple(dns_difftuple_t **tuple,
-	     dns_db_t *db, dns_dbversion_t *ver,
+do_one_tuple(dns_difftuple_t **tuple, dns_db_t *db, dns_dbversion_t *ver,
 	     dns_diff_t *diff)
 {
 	dns_diff_t temp_diff;
@@ -292,6 +355,7 @@ do_one_tuple(dns_difftuple_t **tuple,
 	 * Create a singleton diff.
 	 */
 	dns_diff_init(diff->mctx, &temp_diff);
+	temp_diff.resign = diff->resign;
 	ISC_LIST_APPEND(temp_diff.tuples, *tuple, link);
 
 	/*
@@ -320,7 +384,7 @@ do_one_tuple(dns_difftuple_t **tuple,
  * update in 'diff'.
  *
  * Ensures:
- * \li  'updates' is empty.
+ * \li	'updates' is empty.
  */
 static isc_result_t
 do_diff(dns_diff_t *updates, dns_db_t *db, dns_dbversion_t *ver,
@@ -341,8 +405,8 @@ do_diff(dns_diff_t *updates, dns_db_t *db, dns_dbversion_t *ver,
 
 static isc_result_t
 update_one_rr(dns_db_t *db, dns_dbversion_t *ver, dns_diff_t *diff,
-	      dns_diffop_t op, dns_name_t *name,
-	      dns_ttl_t ttl, dns_rdata_t *rdata)
+	      dns_diffop_t op, dns_name_t *name, dns_ttl_t ttl,
+	      dns_rdata_t *rdata)
 {
 	dns_difftuple_t *tuple = NULL;
 	isc_result_t result;
@@ -423,11 +487,8 @@ foreach_node_rr_action(void *data, dns_rdataset_t *rdataset) {
  * If 'action' returns an error, abort iteration and return the error.
  */
 static isc_result_t
-foreach_rrset(dns_db_t *db,
-	      dns_dbversion_t *ver,
-	      dns_name_t *name,
-	      rrset_func *action,
-	      void *action_data)
+foreach_rrset(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name,
+	      rrset_func *action, void *action_data)
 {
 	isc_result_t result;
 	dns_dbnode_t *node;
@@ -482,11 +543,8 @@ foreach_rrset(dns_db_t *db,
  * and return the error.
  */
 static isc_result_t
-foreach_node_rr(dns_db_t *db,
-	    dns_dbversion_t *ver,
-	    dns_name_t *name,
-	    rr_func *rr_action,
-	    void *rr_action_data)
+foreach_node_rr(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name,
+		rr_func *rr_action, void *rr_action_data)
 {
 	foreach_node_rr_ctx_t ctx;
 	ctx.rr_action = rr_action;
@@ -506,12 +564,8 @@ foreach_node_rr(dns_db_t *db,
  * If 'action' returns an error, abort iteration and return the error.
  */
 static isc_result_t
-foreach_rr(dns_db_t *db,
-	   dns_dbversion_t *ver,
-	   dns_name_t *name,
-	   dns_rdatatype_t type,
-	   dns_rdatatype_t covers,
-	   rr_func *rr_action,
+foreach_rr(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name,
+	   dns_rdatatype_t type, dns_rdatatype_t covers, rr_func *rr_action,
 	   void *rr_action_data)
 {
 
@@ -524,7 +578,11 @@ foreach_rr(dns_db_t *db,
 					rr_action, rr_action_data));
 
 	node = NULL;
-	result = dns_db_findnode(db, name, ISC_FALSE, &node);
+	if (type == dns_rdatatype_nsec3 ||
+	    (type == dns_rdatatype_rrsig && covers == dns_rdatatype_nsec3))
+		result = dns_db_findnsec3node(db, name, ISC_FALSE, &node);
+	else
+		result = dns_db_findnode(db, name, ISC_FALSE, &node);
 	if (result == ISC_R_NOTFOUND)
 		return (ISC_R_SUCCESS);
 	if (result != ISC_R_SUCCESS)
@@ -597,9 +655,9 @@ rrset_exists_action(void *data, rr_t *rr) {
  * This would be more readable as "do { if ... } while(0)",
  * but that form generates tons of warnings on Solaris 2.6.
  */
-#define RETURN_EXISTENCE_FLAG 				\
-	return ((result == ISC_R_EXISTS) ? 		\
-		(*exists = ISC_TRUE, ISC_R_SUCCESS) : 	\
+#define RETURN_EXISTENCE_FLAG				\
+	return ((result == ISC_R_EXISTS) ?		\
+		(*exists = ISC_TRUE, ISC_R_SUCCESS) :	\
 		((result == ISC_R_SUCCESS) ?		\
 		 (*exists = ISC_FALSE, ISC_R_SUCCESS) :	\
 		 result))
@@ -609,8 +667,8 @@ rrset_exists_action(void *data, rr_t *rr) {
  * to false otherwise.
  */
 static isc_result_t
-rrset_exists(dns_db_t *db, dns_dbversion_t *ver,
-	     dns_name_t *name, dns_rdatatype_t type, dns_rdatatype_t covers,
+rrset_exists(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name,
+	     dns_rdatatype_t type, dns_rdatatype_t covers,
 	     isc_boolean_t *exists)
 {
 	isc_result_t result;
@@ -620,6 +678,45 @@ rrset_exists(dns_db_t *db, dns_dbversion_t *ver,
 }
 
 /*%
+ * Set '*visible' to true if the RRset exists and is part of the
+ * visible zone.  Otherwise '*visible' is set to false unless a
+ * error occurs.
+ */
+static isc_result_t
+rrset_visible(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name,
+	      dns_rdatatype_t type, isc_boolean_t *visible)
+{
+	isc_result_t result;
+	dns_fixedname_t fixed;
+
+	dns_fixedname_init(&fixed);
+	result = dns_db_find(db, name, ver, type, DNS_DBFIND_NOWILD,
+			     (isc_stdtime_t) 0, NULL,
+			     dns_fixedname_name(&fixed), NULL, NULL);
+	switch (result) {
+	case ISC_R_SUCCESS:
+		*visible = ISC_TRUE;
+		break;
+	/*
+	 * Glue, obscured, deleted or replaced records.
+	 */
+	case DNS_R_DELEGATION:
+	case DNS_R_DNAME:
+	case DNS_R_CNAME:
+	case DNS_R_NXDOMAIN:
+	case DNS_R_NXRRSET:
+	case DNS_R_EMPTYNAME:
+	case DNS_R_COVERINGNSEC:
+		*visible = ISC_FALSE;
+		result = ISC_R_SUCCESS;
+		break;
+	default:
+		break;
+	}
+	return (result);
+}
+
+/*%
  * Helper function for cname_incompatible_rrset_exists.
  */
 static isc_result_t
@@ -695,8 +792,22 @@ name_exists(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name,
 	RETURN_EXISTENCE_FLAG;
 }
 
+/*
+ *	'ssu_check_t' is used to pass the arguments to
+ *	dns_ssutable_checkrules() to the callback function
+ *	ssu_checkrule().
+ */
 typedef struct {
-	dns_name_t *name, *signer;
+	/* The ownername of the record to be updated. */
+	dns_name_t *name;
+
+	/* The signature's name if the request was signed. */
+	dns_name_t *signer;
+
+	/* The address of the client if the request was received via TCP. */
+	isc_netaddr_t *tcpaddr;
+
+	/* The ssu table to check against. */
 	dns_ssutable_t *table;
 } ssu_check_t;
 
@@ -713,13 +824,15 @@ ssu_checkrule(void *data, dns_rdataset_t *rrset) {
 	    rrset->type == dns_rdatatype_nsec)
 		return (ISC_R_SUCCESS);
 	result = dns_ssutable_checkrules(ssuinfo->table, ssuinfo->signer,
-					 ssuinfo->name, rrset->type);
+					 ssuinfo->name, ssuinfo->tcpaddr,
+					 rrset->type);
 	return (result == ISC_TRUE ? ISC_R_SUCCESS : ISC_R_FAILURE);
 }
 
 static isc_boolean_t
 ssu_checkall(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name,
-	     dns_ssutable_t *ssutable, dns_name_t *signer)
+	     dns_ssutable_t *ssutable, dns_name_t *signer,
+	     isc_netaddr_t *tcpaddr)
 {
 	isc_result_t result;
 	ssu_check_t ssuinfo;
@@ -727,6 +840,7 @@ ssu_checkall(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name,
 	ssuinfo.name = name;
 	ssuinfo.table = ssutable;
 	ssuinfo.signer = signer;
+	ssuinfo.tcpaddr = tcpaddr;
 	result = foreach_rrset(db, ver, name, ssu_checkrule, &ssuinfo);
 	return (ISC_TF(result == ISC_R_SUCCESS));
 }
@@ -738,8 +852,8 @@ ssu_checkall(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name,
  * In the RFC2136 section 3.2.5, this is the pseudocode involving
  * a variable called "temp", a mapping of <name, type> tuples to rrsets.
  *
- * Here, we represent the "temp" data structure as (non-minimial) "dns_diff_t"
- * where each typle has op==DNS_DIFFOP_EXISTS.
+ * Here, we represent the "temp" data structure as (non-minimal) "dns_diff_t"
+ * where each tuple has op==DNS_DIFFOP_EXISTS.
  */
 
 
@@ -754,7 +868,7 @@ temp_append(dns_diff_t *diff, dns_name_t *name, dns_rdata_t *rdata) {
 
 	REQUIRE(DNS_DIFF_VALID(diff));
 	CHECK(dns_difftuple_create(diff->mctx, DNS_DIFFOP_EXISTS,
-				      name, 0, rdata, &tuple));
+				   name, 0, rdata, &tuple));
 	ISC_LIST_APPEND(diff->tuples, tuple, link);
  failure:
 	return (result);
@@ -974,13 +1088,14 @@ typedef struct {
 
 /*%
  * Return true iff 'db_rr' is neither a SOA nor an NS RR nor
- * an RRSIG nor a NSEC.
+ * an RRSIG nor an NSEC3PARAM nor a NSEC.
  */
 static isc_boolean_t
 type_not_soa_nor_ns_p(dns_rdata_t *update_rr, dns_rdata_t *db_rr) {
 	UNUSED(update_rr);
 	return ((db_rr->type != dns_rdatatype_soa &&
 		 db_rr->type != dns_rdatatype_ns &&
+		 db_rr->type != dns_rdatatype_nsec3param &&
 		 db_rr->type != dns_rdatatype_rrsig &&
 		 db_rr->type != dns_rdatatype_nsec) ?
 		ISC_TRUE : ISC_FALSE);
@@ -1008,6 +1123,16 @@ true_p(dns_rdata_t *update_rr, dns_rdata_t *db_rr) {
 }
 
 /*%
+ * Return true if the record is a RRSIG.
+ */
+static isc_boolean_t
+rrsig_p(dns_rdata_t *update_rr, dns_rdata_t *db_rr) {
+	UNUSED(update_rr);
+	return ((db_rr->type == dns_rdatatype_rrsig) ?
+		ISC_TRUE : ISC_FALSE);
+}
+
+/*%
  * Return true iff the two RRs have identical rdata.
  */
 static isc_boolean_t
@@ -1027,9 +1152,17 @@ rr_equal_p(dns_rdata_t *update_rr, dns_rdata_t *db_rr) {
  *
  * RFC2136 does not mention NSEC or DNAME, but multiple NSECs or DNAMEs
  * make little sense, so we replace those, too.
+ *
+ * Additionally replace RRSIG that have been generated by the same key
+ * for the same type.  This simplifies refreshing a offline KSK by not
+ * requiring that the old RRSIG be deleted.  It also simplifies key
+ * rollover by only requiring that the new RRSIG be added.
  */
 static isc_boolean_t
 replaces_p(dns_rdata_t *update_rr, dns_rdata_t *db_rr) {
+	dns_rdata_rrsig_t updatesig, dbsig;
+	isc_result_t result;
+
 	if (db_rr->type != update_rr->type)
 		return (ISC_FALSE);
 	if (db_rr->type == dns_rdatatype_cname)
@@ -1040,18 +1173,46 @@ replaces_p(dns_rdata_t *update_rr, dns_rdata_t *db_rr) {
 		return (ISC_TRUE);
 	if (db_rr->type == dns_rdatatype_nsec)
 		return (ISC_TRUE);
+	if (db_rr->type == dns_rdatatype_rrsig) {
+		/*
+		 * Replace existing RRSIG with the same keyid,
+		 * covered and algorithm.
+		 */
+		result = dns_rdata_tostruct(db_rr, &dbsig, NULL);
+		RUNTIME_CHECK(result == ISC_R_SUCCESS);
+		result = dns_rdata_tostruct(update_rr, &updatesig, NULL);
+		RUNTIME_CHECK(result == ISC_R_SUCCESS);
+		if (dbsig.keyid == updatesig.keyid &&
+		    dbsig.covered == updatesig.covered &&
+		    dbsig.algorithm == updatesig.algorithm)
+			return (ISC_TRUE);
+	}
 	if (db_rr->type == dns_rdatatype_wks) {
 		/*
 		 * Compare the address and protocol fields only.  These
 		 * form the first five bytes of the RR data.  Do a
 		 * raw binary comparison; unpacking the WKS RRs using
-		 * dns_rdata_tostruct() might be cleaner in some ways,
-		 * but it would require us to pass around an mctx.
+		 * dns_rdata_tostruct() might be cleaner in some ways.
 		 */
 		INSIST(db_rr->length >= 5 && update_rr->length >= 5);
 		return (memcmp(db_rr->data, update_rr->data, 5) == 0 ?
 			ISC_TRUE : ISC_FALSE);
 	}
+
+	if (db_rr->type == dns_rdatatype_nsec3param) {
+		if (db_rr->length != update_rr->length)
+			return (ISC_FALSE);
+		INSIST(db_rr->length >= 4 && update_rr->length >= 4);
+		/*
+		 * Replace records added in this UPDATE request.
+		 */
+		if (db_rr->data[0] == update_rr->data[0] &&
+		    db_rr->data[1] & DNS_NSEC3FLAG_UPDATE &&
+		    update_rr->data[1] & DNS_NSEC3FLAG_UPDATE &&
+		    memcmp(db_rr->data+2, update_rr->data+2,
+			   update_rr->length - 2) == 0)
+			return (ISC_TRUE);
+	}
 	return (ISC_FALSE);
 }
 
@@ -1080,14 +1241,9 @@ delete_if_action(void *data, rr_t *rr) {
  * deletions in 'diff'.
  */
 static isc_result_t
-delete_if(rr_predicate *predicate,
-	  dns_db_t *db,
-	  dns_dbversion_t *ver,
-	  dns_name_t *name,
-	  dns_rdatatype_t type,
-	  dns_rdatatype_t covers,
-	  dns_rdata_t *update_rr,
-	  dns_diff_t *diff)
+delete_if(rr_predicate *predicate, dns_db_t *db, dns_dbversion_t *ver,
+	  dns_name_t *name, dns_rdatatype_t type, dns_rdatatype_t covers,
+	  dns_rdata_t *update_rr, dns_diff_t *diff)
 {
 	conditional_delete_ctx_t ctx;
 	ctx.predicate = predicate;
@@ -1144,10 +1300,8 @@ add_rr_prepare_action(void *data, rr_t *rr) {
 	 * be deleted before the update RR is added.
 	 */
 	if (replaces_p(ctx->update_rr, &rr->rdata)) {
-		CHECK(dns_difftuple_create(ctx->del_diff.mctx,
-					   DNS_DIFFOP_DEL, ctx->name,
-					   rr->ttl,
-					   &rr->rdata,
+		CHECK(dns_difftuple_create(ctx->del_diff.mctx, DNS_DIFFOP_DEL,
+					   ctx->name, rr->ttl, &rr->rdata,
 					   &tuple));
 		dns_diff_append(&ctx->del_diff, &tuple);
 		return (ISC_R_SUCCESS);
@@ -1158,18 +1312,15 @@ add_rr_prepare_action(void *data, rr_t *rr) {
 	 * its TTL must be adjusted.
 	 */
 	if (rr->ttl != ctx->update_rr_ttl) {
-		CHECK(dns_difftuple_create(ctx->del_diff.mctx,
-					   DNS_DIFFOP_DEL, ctx->name,
-					   rr->ttl,
-					   &rr->rdata,
+		CHECK(dns_difftuple_create(ctx->del_diff.mctx, DNS_DIFFOP_DEL,
+					   ctx->name, rr->ttl, &rr->rdata,
 					   &tuple));
 		dns_diff_append(&ctx->del_diff, &tuple);
 		if (!equal) {
 			CHECK(dns_difftuple_create(ctx->add_diff.mctx,
 						   DNS_DIFFOP_ADD, ctx->name,
 						   ctx->update_rr_ttl,
-						   &rr->rdata,
-						   &tuple));
+						   &rr->rdata, &tuple));
 			dns_diff_append(&ctx->add_diff, &tuple);
 		}
 	}
@@ -1191,10 +1342,9 @@ add_rr_prepare_action(void *data, rr_t *rr) {
  */
 static void
 get_current_rr(dns_message_t *msg, dns_section_t section,
-	       dns_rdataclass_t zoneclass,
-	       dns_name_t **name, dns_rdata_t *rdata, dns_rdatatype_t *covers,
-	       dns_ttl_t *ttl,
-	       dns_rdataclass_t *update_class)
+	       dns_rdataclass_t zoneclass, dns_name_t **name,
+	       dns_rdata_t *rdata, dns_rdatatype_t *covers,
+	       dns_ttl_t *ttl, dns_rdataclass_t *update_class)
 {
 	dns_rdataset_t *rdataset;
 	isc_result_t result;
@@ -1279,8 +1429,7 @@ increment_soa_serial(dns_db_t *db, dns_dbversion_t *ver,
  */
 static isc_result_t
 check_soa_increment(dns_db_t *db, dns_dbversion_t *ver,
-		    dns_rdata_t *update_rdata,
-		    isc_boolean_t *ok)
+		    dns_rdata_t *update_rdata, isc_boolean_t *ok)
 {
 	isc_uint32_t db_serial;
 	isc_uint32_t update_serial;
@@ -1337,7 +1486,7 @@ namelist_append_subdomain(dns_db_t *db, dns_name_t *name, dns_diff_t *affected)
 	dns_fixedname_init(&fixedname);
 	child = dns_fixedname_name(&fixedname);
 
-	CHECK(dns_db_createiterator(db, ISC_FALSE, &dbit));
+	CHECK(dns_db_createiterator(db, DNS_DB_NONSEC3, &dbit));
 
 	for (result = dns_dbiterator_seek(dbit, name);
 	     result == ISC_R_SUCCESS;
@@ -1367,8 +1516,10 @@ static isc_result_t
 is_non_nsec_action(void *data, dns_rdataset_t *rrset) {
 	UNUSED(data);
 	if (!(rrset->type == dns_rdatatype_nsec ||
+	      rrset->type == dns_rdatatype_nsec3 ||
 	      (rrset->type == dns_rdatatype_rrsig &&
-	       rrset->covers == dns_rdatatype_nsec)))
+	       (rrset->covers == dns_rdatatype_nsec ||
+		rrset->covers == dns_rdatatype_nsec3))))
 		return (ISC_R_EXISTS);
 	return (ISC_R_SUCCESS);
 }
@@ -1386,8 +1537,7 @@ non_nsec_rrset_exists(dns_db_t *db, dns_dbversion_t *ver,
 		     dns_name_t *name, isc_boolean_t *exists)
 {
 	isc_result_t result;
-	result = foreach_rrset(db, ver, name,
-			       is_non_nsec_action, NULL);
+	result = foreach_rrset(db, ver, name, is_non_nsec_action, NULL);
 	RETURN_EXISTENCE_FLAG;
 }
 
@@ -1425,10 +1575,9 @@ uniqify_name_list(dns_diff_t *list) {
 	return (result);
 }
 
-
 static isc_result_t
-is_glue(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name,
-	isc_boolean_t *flag)
+is_active(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name,
+	  isc_boolean_t *flag, isc_boolean_t *cut, isc_boolean_t *unsecure)
 {
 	isc_result_t result;
 	dns_fixedname_t foundname;
@@ -1438,20 +1587,44 @@ is_glue(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name,
 			     (isc_stdtime_t) 0, NULL,
 			     dns_fixedname_name(&foundname),
 			     NULL, NULL);
-	if (result == ISC_R_SUCCESS) {
-		*flag = ISC_FALSE;
+	if (result == ISC_R_SUCCESS || result == DNS_R_EMPTYNAME) {
+		*flag = ISC_TRUE;
+		*cut = ISC_FALSE;
+		if (unsecure != NULL)
+			*unsecure = ISC_FALSE;
 		return (ISC_R_SUCCESS);
 	} else if (result == DNS_R_ZONECUT) {
-		/*
-		 * We are at the zonecut.  The name will have an NSEC, but
-		 * non-delegation will be omitted from the type bit map.
-		 */
-		*flag = ISC_FALSE;
-		return (ISC_R_SUCCESS);
-	} else if (result == DNS_R_GLUE || result == DNS_R_DNAME) {
 		*flag = ISC_TRUE;
+		*cut = ISC_TRUE;
+		if (unsecure != NULL) {
+			/*
+			 * We are at the zonecut.  Check to see if there
+			 * is a DS RRset.
+			 */
+			if (dns_db_find(db, name, ver, dns_rdatatype_ds, 0,
+					(isc_stdtime_t) 0, NULL,
+					dns_fixedname_name(&foundname),
+					NULL, NULL) == DNS_R_NXRRSET)
+				*unsecure = ISC_TRUE;
+			else
+				*unsecure = ISC_FALSE;
+		}
+		return (ISC_R_SUCCESS);
+	} else if (result == DNS_R_GLUE || result == DNS_R_DNAME ||
+		   result == DNS_R_DELEGATION || result == DNS_R_NXDOMAIN) {
+		*flag = ISC_FALSE;
+		*cut = ISC_FALSE;
+		if (unsecure != NULL)
+			*unsecure = ISC_FALSE;
 		return (ISC_R_SUCCESS);
 	} else {
+		/*
+		 * Silence compiler.
+		 */
+		*flag = ISC_FALSE;
+		*cut = ISC_FALSE;
+		if (unsecure != NULL)
+			*unsecure = ISC_FALSE;
 		return (result);
 	}
 }
@@ -1471,8 +1644,9 @@ next_active(ns_client_t *client, dns_zone_t *zone, dns_db_t *db,
 	dns_dbiterator_t *dbit = NULL;
 	isc_boolean_t has_nsec;
 	unsigned int wraps = 0;
+	isc_boolean_t secure = dns_db_issecure(db);
 
-	CHECK(dns_db_createiterator(db, ISC_FALSE, &dbit));
+	CHECK(dns_db_createiterator(db, 0, &dbit));
 
 	CHECK(dns_dbiterator_seek(dbit, oldname));
 	do {
@@ -1508,9 +1682,29 @@ next_active(ns_client_t *client, dns_zone_t *zone, dns_db_t *db,
 		 * we must pause the iterator first.
 		 */
 		CHECK(dns_dbiterator_pause(dbit));
-		CHECK(rrset_exists(db, ver, newname,
-				   dns_rdatatype_nsec, 0, &has_nsec));
-
+		if (secure) {
+			CHECK(rrset_exists(db, ver, newname,
+					   dns_rdatatype_nsec, 0, &has_nsec));
+		} else {
+			dns_fixedname_t ffound;
+			dns_name_t *found;
+			dns_fixedname_init(&ffound);
+			found = dns_fixedname_name(&ffound);
+			result = dns_db_find(db, newname, ver,
+					     dns_rdatatype_soa,
+					     DNS_DBFIND_NOWILD, 0, NULL, found,
+					     NULL, NULL);
+			if (result == ISC_R_SUCCESS ||
+			    result == DNS_R_EMPTYNAME ||
+			    result == DNS_R_NXRRSET ||
+			    result == DNS_R_CNAME ||
+			    (result == DNS_R_DELEGATION &&
+			     dns_name_equal(newname, found))) {
+				has_nsec = ISC_TRUE;
+				result = ISC_R_SUCCESS;
+			} else if (result != DNS_R_NXDOMAIN)
+				break;
+		}
 	} while (! has_nsec);
  failure:
 	if (dbit != NULL)
@@ -1519,6 +1713,35 @@ next_active(ns_client_t *client, dns_zone_t *zone, dns_db_t *db,
 	return (result);
 }
 
+static isc_boolean_t
+has_opt_bit(dns_db_t *db, dns_dbversion_t *version, dns_dbnode_t *node) {
+	isc_result_t result;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	dns_rdataset_t rdataset;
+	isc_boolean_t has_bit = ISC_FALSE;
+
+	dns_rdataset_init(&rdataset);
+	CHECK(dns_db_findrdataset(db, node, version, dns_rdatatype_nsec,
+				  dns_rdatatype_none, 0, &rdataset, NULL));
+	CHECK(dns_rdataset_first(&rdataset));
+	dns_rdataset_current(&rdataset, &rdata);
+	has_bit = dns_nsec_typepresent(&rdata, dns_rdatatype_opt);
+ failure:
+	if (dns_rdataset_isassociated(&rdataset))
+		dns_rdataset_disassociate(&rdataset);
+	return (has_bit);
+}
+
+static void
+set_bit(unsigned char *array, unsigned int index) {
+	unsigned int shift, bit;
+
+	shift = 7 - (index % 8);
+	bit = 1 << shift;
+
+	array[index / 8] |= bit;
+}
+
 /*%
  * Add a NSEC record for "name", recording the change in "diff".
  * The existing NSEC is removed.
@@ -1550,6 +1773,24 @@ add_nsec(ns_client_t *client, dns_zone_t *zone, dns_db_t *db,
 	CHECK(dns_db_findnode(db, name, ISC_FALSE, &node));
 	dns_rdata_init(&rdata);
 	CHECK(dns_nsec_buildrdata(db, ver, node, target, buffer, &rdata));
+	/*
+	 * Preserve the status of the OPT bit in the origin's NSEC record.
+	 */
+	if (dns_name_equal(dns_db_origin(db), name) &&
+	    has_opt_bit(db, ver, node))
+	{
+			isc_region_t region;
+			dns_name_t next;
+
+			dns_name_init(&next, NULL);
+			dns_rdata_toregion(&rdata, &region);
+			dns_name_fromregion(&next, &region);
+			isc_region_consume(&region, next.length);
+			INSIST(region.length > (2 + dns_rdatatype_opt / 8) &&
+			       region.base[0] == 0 &&
+			       region.base[1] > dns_rdatatype_opt / 8);
+			set_bit(region.base + 2, dns_rdatatype_opt);
+	}
 	dns_db_detachnode(db, &node);
 
 	/*
@@ -1576,7 +1817,8 @@ add_nsec(ns_client_t *client, dns_zone_t *zone, dns_db_t *db,
  */
 static isc_result_t
 add_placeholder_nsec(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name,
-		    dns_diff_t *diff) {
+		     dns_diff_t *diff)
+{
 	isc_result_t result;
 	dns_difftuple_t *tuple = NULL;
 	isc_region_t r;
@@ -1655,7 +1897,7 @@ static isc_result_t
 add_sigs(ns_client_t *client, dns_zone_t *zone, dns_db_t *db,
 	 dns_dbversion_t *ver, dns_name_t *name, dns_rdatatype_t type,
 	 dns_diff_t *diff, dst_key_t **keys, unsigned int nkeys,
-	 isc_mem_t *mctx, isc_stdtime_t inception, isc_stdtime_t expire,
+	 isc_stdtime_t inception, isc_stdtime_t expire,
 	 isc_boolean_t check_ksk)
 {
 	isc_result_t result;
@@ -1666,15 +1908,18 @@ add_sigs(ns_client_t *client, dns_zone_t *zone, dns_db_t *db,
 	unsigned char data[1024]; /* XXX */
 	unsigned int i;
 	isc_boolean_t added_sig = ISC_FALSE;
+	isc_mem_t *mctx = client->mctx;
 
 	dns_rdataset_init(&rdataset);
 	isc_buffer_init(&buffer, data, sizeof(data));
 
 	/* Get the rdataset to sign. */
-	CHECK(dns_db_findnode(db, name, ISC_FALSE, &node));
+	if (type == dns_rdatatype_nsec3)
+		CHECK(dns_db_findnsec3node(db, name, ISC_FALSE, &node));
+	else
+		CHECK(dns_db_findnode(db, name, ISC_FALSE, &node));
 	CHECK(dns_db_findrdataset(db, node, ver, type, 0,
-				  (isc_stdtime_t) 0,
-				  &rdataset, NULL));
+				  (isc_stdtime_t) 0, &rdataset, NULL));
 	dns_db_detachnode(db, &node);
 
 	for (i = 0; i < nkeys; i++) {
@@ -1693,7 +1938,7 @@ add_sigs(ns_client_t *client, dns_zone_t *zone, dns_db_t *db,
 
 		/* Update the database and journal with the RRSIG. */
 		/* XXX inefficient - will cause dataset merging */
-		CHECK(update_one_rr(db, ver, diff, DNS_DIFFOP_ADD, name,
+		CHECK(update_one_rr(db, ver, diff, DNS_DIFFOP_ADDRESIGN, name,
 				    rdataset.ttl, &sig_rdata));
 		dns_rdata_reset(&sig_rdata);
 		added_sig = ISC_TRUE;
@@ -1713,13 +1958,156 @@ add_sigs(ns_client_t *client, dns_zone_t *zone, dns_db_t *db,
 	return (result);
 }
 
+/*
+ * Delete expired RRsigs and any RRsigs we are about to re-sign.
+ * See also zone.c:del_sigs().
+ */
+static isc_result_t
+del_keysigs(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name,
+	    dns_diff_t *diff, dst_key_t **keys, unsigned int nkeys)
+{
+	isc_result_t result;
+	dns_dbnode_t *node = NULL;
+	dns_rdataset_t rdataset;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	unsigned int i;
+	dns_rdata_rrsig_t rrsig;
+	isc_boolean_t found;
+
+	dns_rdataset_init(&rdataset);
+
+	result = dns_db_findnode(db, name, ISC_FALSE, &node);
+	if (result == ISC_R_NOTFOUND)
+		return (ISC_R_SUCCESS);
+	if (result != ISC_R_SUCCESS)
+		goto failure;
+	result = dns_db_findrdataset(db, node, ver, dns_rdatatype_rrsig,
+				     dns_rdatatype_dnskey, (isc_stdtime_t) 0,
+				     &rdataset, NULL);
+	dns_db_detachnode(db, &node);
+
+	if (result == ISC_R_NOTFOUND)
+		return (ISC_R_SUCCESS);
+	if (result != ISC_R_SUCCESS)
+		goto failure;
+
+	for (result = dns_rdataset_first(&rdataset);
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdataset_next(&rdataset)) {
+		dns_rdataset_current(&rdataset, &rdata);
+		result = dns_rdata_tostruct(&rdata, &rrsig, NULL);
+		RUNTIME_CHECK(result == ISC_R_SUCCESS);
+		found = ISC_FALSE;
+		for (i = 0; i < nkeys; i++) {
+			if (rrsig.keyid == dst_key_id(keys[i])) {
+				found = ISC_TRUE;
+				if (!dst_key_isprivate(keys[i])) {
+					/*
+					 * The re-signing code in zone.c
+					 * will mark this as offline.
+					 * Just skip the record for now.
+					 */
+					break;
+				}
+				result = update_one_rr(db, ver, diff,
+						       DNS_DIFFOP_DEL, name,
+						       rdataset.ttl, &rdata);
+				break;
+			}
+		}
+		/*
+		 * If there is not a matching DNSKEY then delete the RRSIG.
+		 */
+		if (!found)
+			result = update_one_rr(db, ver, diff, DNS_DIFFOP_DEL,
+					       name, rdataset.ttl, &rdata);
+		dns_rdata_reset(&rdata);
+		if (result != ISC_R_SUCCESS)
+			break;
+	}
+	dns_rdataset_disassociate(&rdataset);
+	if (result == ISC_R_NOMORE)
+		result = ISC_R_SUCCESS;
+failure:
+	if (node != NULL)
+		dns_db_detachnode(db, &node);
+	return (result);
+}
+
+static isc_result_t
+add_exposed_sigs(ns_client_t *client, dns_zone_t *zone, dns_db_t *db,
+		 dns_dbversion_t *ver, dns_name_t *name, isc_boolean_t cut,
+		 dns_diff_t *diff, dst_key_t **keys, unsigned int nkeys,
+		 isc_stdtime_t inception, isc_stdtime_t expire,
+		 isc_boolean_t check_ksk)
+{
+	isc_result_t result;
+	dns_dbnode_t *node;
+	dns_rdatasetiter_t *iter;
+
+	node = NULL;
+	result = dns_db_findnode(db, name, ISC_FALSE, &node);
+	if (result == ISC_R_NOTFOUND)
+		return (ISC_R_SUCCESS);
+	if (result != ISC_R_SUCCESS)
+		return (result);
+
+	iter = NULL;
+	result = dns_db_allrdatasets(db, node, ver,
+				     (isc_stdtime_t) 0, &iter);
+	if (result != ISC_R_SUCCESS)
+		goto cleanup_node;
+
+	for (result = dns_rdatasetiter_first(iter);
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdatasetiter_next(iter))
+	{
+		dns_rdataset_t rdataset;
+		dns_rdatatype_t type;
+		isc_boolean_t flag;
+
+		dns_rdataset_init(&rdataset);
+		dns_rdatasetiter_current(iter, &rdataset);
+		type = rdataset.type;
+		dns_rdataset_disassociate(&rdataset);
+
+		/*
+		 * We don't need to sign unsigned NSEC records at the cut
+		 * as they are handled elsewhere.
+		 */
+		if ((type == dns_rdatatype_rrsig) ||
+		    (cut && type != dns_rdatatype_ds))
+			continue;
+		result = rrset_exists(db, ver, name, dns_rdatatype_rrsig,
+				      type, &flag);
+		if (result != ISC_R_SUCCESS)
+			goto cleanup_iterator;
+		if (flag)
+			continue;;
+		result = add_sigs(client, zone, db, ver, name, type, diff,
+				  keys, nkeys, inception, expire, check_ksk);
+		if (result != ISC_R_SUCCESS)
+			goto cleanup_iterator;
+	}
+	if (result == ISC_R_NOMORE)
+		result = ISC_R_SUCCESS;
+
+ cleanup_iterator:
+	dns_rdatasetiter_destroy(&iter);
+
+ cleanup_node:
+	dns_db_detachnode(db, &node);
+
+	return (result);
+}
+
 /*%
- * Update RRSIG and NSEC records affected by an update.  The original
- * update, including the SOA serial update but exluding the RRSIG & NSEC
+ * Update RRSIG, NSEC and NSEC3 records affected by an update.  The original
+ * update, including the SOA serial update but excluding the RRSIG & NSEC
  * changes, is in "diff" and has already been applied to "newver" of "db".
  * The database version prior to the update is "oldver".
  *
- * The necessary RRSIG and NSEC changes will be applied to "newver"
+ * The necessary RRSIG, NSEC and NSEC3 changes will be applied to "newver"
  * and added (as a minimal diff) to "diff".
  *
  * The RRSIGs generated will be valid for 'sigvalidityinterval' seconds.
@@ -1727,7 +2115,8 @@ add_sigs(ns_client_t *client, dns_zone_t *zone, dns_db_t *db,
 static isc_result_t
 update_signatures(ns_client_t *client, dns_zone_t *zone, dns_db_t *db,
 		  dns_dbversion_t *oldver, dns_dbversion_t *newver,
-		  dns_diff_t *diff, isc_uint32_t sigvalidityinterval)
+		  dns_diff_t *diff, isc_uint32_t sigvalidityinterval,
+		  isc_boolean_t *deleted_zsk)
 {
 	isc_result_t result;
 	dns_difftuple_t *t;
@@ -1747,11 +2136,14 @@ update_signatures(ns_client_t *client, dns_zone_t *zone, dns_db_t *db,
 	dns_rdataset_t rdataset;
 	dns_dbnode_t *node = NULL;
 	isc_boolean_t check_ksk;
+	isc_boolean_t unsecure;
+	isc_boolean_t cut;
 
 	dns_diff_init(client->mctx, &diffnames);
 	dns_diff_init(client->mctx, &affected);
 
 	dns_diff_init(client->mctx, &sig_diff);
+	sig_diff.resign = dns_zone_getsigresigninginterval(zone);
 	dns_diff_init(client->mctx, &nsec_diff);
 	dns_diff_init(client->mctx, &nsec_mindiff);
 
@@ -1770,16 +2162,35 @@ update_signatures(ns_client_t *client, dns_zone_t *zone, dns_db_t *db,
 	/*
 	 * Do we look at the KSK flag on the DNSKEY to determining which
 	 * keys sign which RRsets?  First check the zone option then
-	 * check the keys flags to make sure atleast one has a ksk set
+	 * check the keys flags to make sure at least one has a ksk set
 	 * and one doesn't.
 	 */
 	check_ksk = ISC_TF((dns_zone_getoptions(zone) &
 			    DNS_ZONEOPT_UPDATECHECKKSK) != 0);
-	if (check_ksk)
+	/*
+	 * If we are not checking the ZSK flag then all DNSKEY's are
+	 * already signing all RRsets so we don't need to trigger special
+	 * changes.
+	 */
+	if (*deleted_zsk && (!check_ksk || !ksk_sanity(db, oldver)))
+		*deleted_zsk = ISC_FALSE;
+
+	if (check_ksk) {
 		check_ksk = ksk_sanity(db, newver);
+		if (!check_ksk && ksk_sanity(db, oldver))
+			update_log(client, zone, ISC_LOG_WARNING,
+				   "disabling update-check-ksk");
+	}
 
 	/*
-	 * Get the NSEC's TTL from the SOA MINIMUM field.
+	 * If we have deleted a ZSK and we we still have some ZSK's
+	 * we don't need to convert the KSK's to a ZSK's.
+	 */
+	if (*deleted_zsk && check_ksk)
+		*deleted_zsk = ISC_FALSE;
+
+	/*
+	 * Get the NSEC/NSEC3 TTL from the SOA MINIMUM field.
 	 */
 	CHECK(dns_db_findnode(db, dns_db_origin(db), ISC_FALSE, &node));
 	dns_rdataset_init(&rdataset);
@@ -1823,21 +2234,27 @@ update_signatures(ns_client_t *client, dns_zone_t *zone, dns_db_t *db,
 			 * Delete all old RRSIGs covering this type, since they
 			 * are all invalid when the signed RRset has changed.
 			 * We may not be able to recreate all of them - tough.
+			 * Special case changes to the zone's DNSKEY records
+			 * to support offline KSKs.
 			 */
-			CHECK(delete_if(true_p, db, newver, name,
-					dns_rdatatype_rrsig, type,
-					NULL, &sig_diff));
+			if (type == dns_rdatatype_dnskey)
+				del_keysigs(db, newver, name, &sig_diff,
+					    zone_keys, nkeys);
+			else
+				CHECK(delete_if(true_p, db, newver, name,
+						dns_rdatatype_rrsig, type,
+						NULL, &sig_diff));
 
 			/*
-			 * If this RRset still exists after the update,
+			 * If this RRset is still visible after the update,
 			 * add a new signature for it.
 			 */
-			CHECK(rrset_exists(db, newver, name, type, 0, &flag));
+			CHECK(rrset_visible(db, newver, name, type, &flag));
 			if (flag) {
 				CHECK(add_sigs(client, zone, db, newver, name,
 					       type, &sig_diff, zone_keys,
-					       nkeys, client->mctx, inception,
-					       expire, check_ksk));
+					       nkeys, inception, expire,
+					       check_ksk));
 			}
 		skip:
 			/* Skip any other updates to the same RRset. */
@@ -1849,6 +2266,7 @@ update_signatures(ns_client_t *client, dns_zone_t *zone, dns_db_t *db,
 			}
 		}
 	}
+	update_log(client, zone, ISC_LOG_DEBUG(3), "updated data signatures");
 
 	/* Remove orphaned NSECs and RRSIG NSECs. */
 	for (t = ISC_LIST_HEAD(diffnames.tuples);
@@ -1862,6 +2280,19 @@ update_signatures(ns_client_t *client, dns_zone_t *zone, dns_db_t *db,
 					NULL, &sig_diff));
 		}
 	}
+	update_log(client, zone, ISC_LOG_DEBUG(3),
+		   "removed any orphaned NSEC records");
+
+	/*
+	 * If we don't have a NSEC record at the origin then we need to
+	 * update the NSEC3 records.
+	 */
+	CHECK(rrset_exists(db, newver, dns_db_origin(db), dns_rdatatype_nsec,
+			   0, &flag));
+	if (!flag)
+		goto update_nsec3;
+
+	update_log(client, zone, ISC_LOG_DEBUG(3), "rebuilding NSEC chain");
 
 	/*
 	 * When a name is created or deleted, its predecessor needs to
@@ -1944,27 +2375,34 @@ update_signatures(ns_client_t *client, dns_zone_t *zone, dns_db_t *db,
 	     t = ISC_LIST_NEXT(t, link))
 	{
 		isc_boolean_t exists;
-		CHECK(name_exists(db, newver, &t->name, &exists));
+		dns_name_t *name = &t->name;
+
+		CHECK(name_exists(db, newver, name, &exists));
 		if (! exists)
 			continue;
-		CHECK(is_glue(db, newver, &t->name, &flag));
-		if (flag) {
+		CHECK(is_active(db, newver, name, &flag, &cut, NULL));
+		if (!flag) {
 			/*
 			 * This name is obscured.  Delete any
 			 * existing NSEC record.
 			 */
-			CHECK(delete_if(true_p, db, newver, &t->name,
+			CHECK(delete_if(true_p, db, newver, name,
 					dns_rdatatype_nsec, 0,
 					NULL, &nsec_diff));
+			CHECK(delete_if(rrsig_p, db, newver, name,
+					dns_rdatatype_any, 0, NULL, diff));
 		} else {
 			/*
 			 * This name is not obscured.  It should have a NSEC.
 			 */
-			CHECK(rrset_exists(db, newver, &t->name,
+			CHECK(rrset_exists(db, newver, name,
 					   dns_rdatatype_nsec, 0, &flag));
 			if (! flag)
-				CHECK(add_placeholder_nsec(db, newver, &t->name,
-							  diff));
+				CHECK(add_placeholder_nsec(db, newver, name,
+							   diff));
+			CHECK(add_exposed_sigs(client, zone, db, newver, name,
+					       cut, diff, zone_keys, nkeys,
+					       inception, expire, check_ksk));
 		}
 	}
 
@@ -2010,6 +2448,9 @@ update_signatures(ns_client_t *client, dns_zone_t *zone, dns_db_t *db,
 		dns_diff_appendminimal(&nsec_mindiff, &t);
 	}
 
+	update_log(client, zone, ISC_LOG_DEBUG(3),
+		   "signing rebuilt NSEC chain");
+
 	/* Update RRSIG NSECs. */
 	for (t = ISC_LIST_HEAD(nsec_mindiff.tuples);
 	     t != NULL;
@@ -2022,7 +2463,139 @@ update_signatures(ns_client_t *client, dns_zone_t *zone, dns_db_t *db,
 		} else if (t->op == DNS_DIFFOP_ADD) {
 			CHECK(add_sigs(client, zone, db, newver, &t->name,
 				       dns_rdatatype_nsec, &sig_diff,
-				       zone_keys, nkeys, client->mctx,
+				       zone_keys, nkeys, inception, expire,
+				       check_ksk));
+		} else {
+			INSIST(0);
+		}
+	}
+
+ update_nsec3:
+
+	/* Record our changes for the journal. */
+	while ((t = ISC_LIST_HEAD(sig_diff.tuples)) != NULL) {
+		ISC_LIST_UNLINK(sig_diff.tuples, t, link);
+		dns_diff_appendminimal(diff, &t);
+	}
+	while ((t = ISC_LIST_HEAD(nsec_mindiff.tuples)) != NULL) {
+		ISC_LIST_UNLINK(nsec_mindiff.tuples, t, link);
+		dns_diff_appendminimal(diff, &t);
+	}
+
+	INSIST(ISC_LIST_EMPTY(sig_diff.tuples));
+	INSIST(ISC_LIST_EMPTY(nsec_diff.tuples));
+	INSIST(ISC_LIST_EMPTY(nsec_mindiff.tuples));
+
+	/*
+	 * Check if we have any active NSEC3 chains by looking for a
+	 * NSEC3PARAM RRset.
+	 */
+	CHECK(rrset_exists(db, newver, dns_db_origin(db),
+			   dns_rdatatype_nsec3param, 0, &flag));
+	if (!flag) {
+		update_log(client, zone, ISC_LOG_DEBUG(3),
+			   "no NSEC3 chains to rebuild");
+		goto failure;
+	}
+
+	update_log(client, zone, ISC_LOG_DEBUG(3), "rebuilding NSEC3 chains");
+
+	dns_diff_clear(&diffnames);
+	dns_diff_clear(&affected);
+
+	CHECK(dns_diff_sort(diff, temp_order));
+
+	/*
+	 * Find names potentially affected by delegation changes
+	 * (obscured by adding an NS or DNAME, or unobscured by
+	 * removing one).
+	 */
+	t = ISC_LIST_HEAD(diff->tuples);
+	while (t != NULL) {
+		dns_name_t *name = &t->name;
+
+		isc_boolean_t ns_existed, dname_existed;
+		isc_boolean_t ns_exists, dname_exists;
+
+		if (t->rdata.type == dns_rdatatype_nsec ||
+		    t->rdata.type == dns_rdatatype_rrsig) {
+			t = ISC_LIST_NEXT(t, link);
+			continue;
+		}
+
+		CHECK(namelist_append_name(&affected, name));
+
+		CHECK(rrset_exists(db, oldver, name, dns_rdatatype_ns, 0,
+				   &ns_existed));
+		CHECK(rrset_exists(db, oldver, name, dns_rdatatype_dname, 0,
+				   &dname_existed));
+		CHECK(rrset_exists(db, newver, name, dns_rdatatype_ns, 0,
+				   &ns_exists));
+		CHECK(rrset_exists(db, newver, name, dns_rdatatype_dname, 0,
+				   &dname_exists));
+
+		if ((ns_exists || dname_exists) == (ns_existed || dname_existed))
+			goto nextname;
+		/*
+		 * There was a delegation change.  Mark all subdomains
+		 * of t->name as potentially needing a NSEC3 update.
+		 */
+		CHECK(namelist_append_subdomain(db, name, &affected));
+
+	nextname:
+		while (t != NULL && dns_name_equal(&t->name, name))
+			t = ISC_LIST_NEXT(t, link);
+	}
+
+	for (t = ISC_LIST_HEAD(affected.tuples);
+	     t != NULL;
+	     t = ISC_LIST_NEXT(t, link)) {
+		dns_name_t *name = &t->name;
+
+		unsecure = ISC_FALSE;	/* Silence compiler warning. */
+		CHECK(is_active(db, newver, name, &flag, &cut, &unsecure));
+
+		if (!flag) {
+			CHECK(delete_if(rrsig_p, db, newver, name,
+					dns_rdatatype_any, 0, NULL, diff));
+			CHECK(dns_nsec3_delnsec3s(db, newver, name,
+						  &nsec_diff));
+		} else {
+			CHECK(add_exposed_sigs(client, zone, db, newver, name,
+					       cut, diff, zone_keys, nkeys,
+					       inception, expire, check_ksk));
+			CHECK(dns_nsec3_addnsec3s(db, newver, name, nsecttl,
+						  unsecure, &nsec_diff));
+		}
+	}
+
+	/*
+	 * Minimize the set of NSEC3 updates so that we don't
+	 * have to regenerate the RRSIG NSEC3s for NSEC3s that were
+	 * replaced with identical ones.
+	 */
+	while ((t = ISC_LIST_HEAD(nsec_diff.tuples)) != NULL) {
+		ISC_LIST_UNLINK(nsec_diff.tuples, t, link);
+		dns_diff_appendminimal(&nsec_mindiff, &t);
+	}
+
+	update_log(client, zone, ISC_LOG_DEBUG(3),
+		   "signing rebuilt NSEC3 chain");
+
+	/* Update RRSIG NSEC3s. */
+	for (t = ISC_LIST_HEAD(nsec_mindiff.tuples);
+	     t != NULL;
+	     t = ISC_LIST_NEXT(t, link))
+	{
+		if (t->op == DNS_DIFFOP_DEL) {
+			CHECK(delete_if(true_p, db, newver, &t->name,
+					dns_rdatatype_rrsig,
+					dns_rdatatype_nsec3,
+					NULL, &sig_diff));
+		} else if (t->op == DNS_DIFFOP_ADD) {
+			CHECK(add_sigs(client, zone, db, newver, &t->name,
+				       dns_rdatatype_nsec3,
+				       &sig_diff, zone_keys, nkeys,
 				       inception, expire, check_ksk));
 		} else {
 			INSIST(0);
@@ -2127,8 +2700,7 @@ ns_update_start(ns_client_t *client, isc_result_t sigresult) {
 	 */
 	result = dns_message_firstname(request, DNS_SECTION_ZONE);
 	if (result != ISC_R_SUCCESS)
-		FAILC(DNS_R_FORMERR,
-		      "update zone section empty");
+		FAILC(DNS_R_FORMERR, "update zone section empty");
 
 	/*
 	 * The zone section must contain exactly one "question", and
@@ -2153,8 +2725,7 @@ ns_update_start(ns_client_t *client, isc_result_t sigresult) {
 	result = dns_zt_find(client->view->zonetable, zonename, 0, NULL,
 			     &zone);
 	if (result != ISC_R_SUCCESS)
-		FAILC(DNS_R_NOTAUTH,
-		      "not authoritative for update zone");
+		FAILC(DNS_R_NOTAUTH, "not authoritative for update zone");
 
 	switch(dns_zone_gettype(zone)) {
 	case dns_zone_master:
@@ -2168,16 +2739,20 @@ ns_update_start(ns_client_t *client, isc_result_t sigresult) {
 		break;
 	case dns_zone_slave:
 		CHECK(checkupdateacl(client, dns_zone_getforwardacl(zone),
-				     "update forwarding", zonename, ISC_TRUE));
+				     "update forwarding", zonename, ISC_TRUE,
+				     ISC_FALSE));
 		CHECK(send_forward_event(client, zone));
 		break;
 	default:
-		FAILC(DNS_R_NOTAUTH,
-		      "not authoritative for update zone");
+		FAILC(DNS_R_NOTAUTH, "not authoritative for update zone");
 	}
 	return;
 
  failure:
+	if (result == DNS_R_REFUSED) {
+		INSIST(dns_zone_gettype(zone) == dns_zone_slave);
+		inc_stats(zone, dns_nsstatscounter_updaterej);
+	}
 	/*
 	 * We failed without having sent an update event to the zone.
 	 * We are still in the client task context, so we can
@@ -2190,36 +2765,44 @@ ns_update_start(ns_client_t *client, isc_result_t sigresult) {
 
 /*%
  * DS records are not allowed to exist without corresponding NS records,
- * draft-ietf-dnsext-delegation-signer-11.txt, 2.2 Protocol Change,
+ * RFC 3658, 2.2 Protocol Change,
  * "DS RRsets MUST NOT appear at non-delegation points or at a zone's apex".
  */
 
 static isc_result_t
 remove_orphaned_ds(dns_db_t *db, dns_dbversion_t *newver, dns_diff_t *diff) {
 	isc_result_t result;
-	isc_boolean_t ns_exists, ds_exists;
-	dns_difftuple_t *t;
+	isc_boolean_t ns_exists;
+	dns_difftuple_t *tupple;
+	dns_diff_t temp_diff;
 
-	for (t = ISC_LIST_HEAD(diff->tuples);
-	     t != NULL;
-	     t = ISC_LIST_NEXT(t, link)) {
-		if (t->op != DNS_DIFFOP_ADD ||
-		    t->rdata.type != dns_rdatatype_ns)
-			continue;
-		CHECK(rrset_exists(db, newver, &t->name, dns_rdatatype_ns, 0,
-				   &ns_exists));
-		if (ns_exists)
+	dns_diff_init(diff->mctx, &temp_diff);
+
+	for (tupple = ISC_LIST_HEAD(diff->tuples);
+	     tupple != NULL;
+	     tupple = ISC_LIST_NEXT(tupple, link)) {
+		if (!((tupple->op == DNS_DIFFOP_DEL &&
+		       tupple->rdata.type == dns_rdatatype_ns) ||
+		      (tupple->op == DNS_DIFFOP_ADD &&
+		       tupple->rdata.type == dns_rdatatype_ds)))
 			continue;
-		CHECK(rrset_exists(db, newver, &t->name, dns_rdatatype_ds, 0,
-				   &ds_exists));
-		if (!ds_exists)
+		CHECK(rrset_exists(db, newver, &tupple->name,
+				   dns_rdatatype_ns, 0, &ns_exists));
+		if (ns_exists &&
+		    !dns_name_equal(&tupple->name, dns_db_origin(db)))
 			continue;
-		CHECK(delete_if(true_p, db, newver, &t->name,
-				dns_rdatatype_ds, 0, NULL, diff));
+		CHECK(delete_if(true_p, db, newver, &tupple->name,
+				dns_rdatatype_ds, 0, NULL, &temp_diff));
 	}
-	return (ISC_R_SUCCESS);
+	result = ISC_R_SUCCESS;
 
  failure:
+	for (tupple = ISC_LIST_HEAD(temp_diff.tuples);
+	     tupple != NULL;
+	     tupple = ISC_LIST_HEAD(temp_diff.tuples)) {
+		ISC_LIST_UNLINK(temp_diff.tuples, tupple, link);
+		dns_diff_appendminimal(diff, &tupple);
+	}
 	return (result);
 }
 
@@ -2329,6 +2912,463 @@ check_mx(ns_client_t *client, dns_zone_t *zone,
 	return (ok ? ISC_R_SUCCESS : DNS_R_REFUSED);
 }
 
+static isc_result_t
+rr_exists(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name,
+	  const dns_rdata_t *rdata, isc_boolean_t *flag)
+{
+	dns_rdataset_t rdataset;
+	dns_dbnode_t *node = NULL;
+	isc_result_t result;
+
+	dns_rdataset_init(&rdataset);
+	if (rdata->type == dns_rdatatype_nsec3)
+		CHECK(dns_db_findnsec3node(db, name, ISC_FALSE, &node));
+	else
+		CHECK(dns_db_findnode(db, name, ISC_FALSE, &node));
+	result = dns_db_findrdataset(db, node, ver, rdata->type, 0,
+				     (isc_stdtime_t) 0, &rdataset, NULL);
+	if (result == ISC_R_NOTFOUND) {
+		*flag = ISC_FALSE;
+		result = ISC_R_SUCCESS;
+		goto failure;
+	}
+
+	for (result = dns_rdataset_first(&rdataset);
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdataset_next(&rdataset)) {
+		dns_rdata_t myrdata = DNS_RDATA_INIT;
+		dns_rdataset_current(&rdataset, &myrdata);
+		if (!dns_rdata_compare(&myrdata, rdata))
+			break;
+	}
+	dns_rdataset_disassociate(&rdataset);
+	if (result == ISC_R_SUCCESS) {
+		*flag = ISC_TRUE;
+	} else if (result == ISC_R_NOMORE) {
+		*flag = ISC_FALSE;
+		result = ISC_R_SUCCESS;
+	}
+
+ failure:
+	if (node != NULL)
+		dns_db_detachnode(db, &node);
+	return (result);
+}
+
+static isc_result_t
+get_iterations(dns_db_t *db, dns_dbversion_t *ver, unsigned int *iterationsp) {
+	dns_dbnode_t *node = NULL;
+	dns_rdata_nsec3param_t nsec3param;
+	dns_rdataset_t rdataset;
+	isc_result_t result;
+	unsigned int iterations = 0;
+
+	dns_rdataset_init(&rdataset);
+
+	result = dns_db_getoriginnode(db, &node);
+	if (result != ISC_R_SUCCESS)
+		return (result);
+	result = dns_db_findrdataset(db, node, ver, dns_rdatatype_nsec3param,
+				     0, (isc_stdtime_t) 0, &rdataset, NULL);
+	dns_db_detachnode(db, &node);
+	if (result == ISC_R_NOTFOUND)
+		goto success;
+	if (result != ISC_R_SUCCESS)
+		goto failure;
+
+	for (result = dns_rdataset_first(&rdataset);
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdataset_next(&rdataset)) {
+		dns_rdata_t rdata = DNS_RDATA_INIT;
+		dns_rdataset_current(&rdataset, &rdata);
+		CHECK(dns_rdata_tostruct(&rdata, &nsec3param, NULL));
+		if ((nsec3param.flags & DNS_NSEC3FLAG_REMOVE) != 0)
+			continue;
+		if (nsec3param.iterations > iterations)
+			iterations = nsec3param.iterations;
+	}
+	if (result != ISC_R_NOMORE)
+		goto failure;
+
+ success:
+	*iterationsp = iterations;
+	result = ISC_R_SUCCESS;
+
+ failure:
+	if (dns_rdataset_isassociated(&rdataset))
+		dns_rdataset_disassociate(&rdataset);
+	return (result);
+}
+
+/*
+ * Prevent the zone entering a inconsistent state where
+ * NSEC only DNSKEYs are present with NSEC3 chains.
+ */
+static isc_result_t
+check_dnssec(ns_client_t *client, dns_zone_t *zone, dns_db_t *db,
+	     dns_dbversion_t *ver, dns_diff_t *diff)
+{
+	dns_diff_t temp_diff;
+	dns_diffop_t op;
+	dns_difftuple_t *tuple, *newtuple = NULL, *next;
+	isc_boolean_t flag;
+	isc_result_t result;
+	unsigned int iterations = 0, max;
+
+	dns_diff_init(diff->mctx, &temp_diff);
+
+	CHECK(dns_nsec_nseconly(db, ver, &flag));
+
+	if (flag)
+		CHECK(dns_nsec3_active(db, ver, ISC_FALSE, &flag));
+	if (flag) {
+		update_log(client, zone, ISC_LOG_WARNING,
+			   "NSEC only DNSKEYs and NSEC3 chains not allowed");
+	} else {
+		CHECK(get_iterations(db, ver, &iterations));
+		CHECK(dns_nsec3_maxiterations(db, ver, client->mctx, &max));
+		if (iterations > max) {
+			flag = ISC_TRUE;
+			update_log(client, zone, ISC_LOG_WARNING,
+				   "too many NSEC3 iterations (%u) for "
+				   "weakest DNSKEY (%u)", iterations, max);
+		}
+	}
+	if (flag) {
+		for (tuple = ISC_LIST_HEAD(diff->tuples);
+		     tuple != NULL;
+		     tuple = next) {
+			next = ISC_LIST_NEXT(tuple, link);
+			if (tuple->rdata.type != dns_rdatatype_dnskey &&
+			    tuple->rdata.type != dns_rdatatype_nsec3param)
+				continue;
+			op = (tuple->op == DNS_DIFFOP_DEL) ?
+			     DNS_DIFFOP_ADD : DNS_DIFFOP_DEL;
+			CHECK(dns_difftuple_create(temp_diff.mctx, op,
+						   &tuple->name, tuple->ttl,
+						   &tuple->rdata, &newtuple));
+			CHECK(do_one_tuple(&newtuple, db, ver, &temp_diff));
+			INSIST(newtuple == NULL);
+		}
+		for (tuple = ISC_LIST_HEAD(temp_diff.tuples);
+		     tuple != NULL;
+		     tuple = ISC_LIST_HEAD(temp_diff.tuples)) {
+			ISC_LIST_UNLINK(temp_diff.tuples, tuple, link);
+			dns_diff_appendminimal(diff, &tuple);
+		}
+	}
+
+
+ failure:
+	dns_diff_clear(&temp_diff);
+	return (result);
+}
+
+#ifdef ALLOW_NSEC3PARAM_UPDATE
+/*
+ * Delay NSEC3PARAM changes as they need to be applied to the whole zone.
+ */
+static isc_result_t
+add_nsec3param_records(ns_client_t *client, dns_zone_t *zone, dns_db_t *db,
+		       dns_name_t *name, dns_dbversion_t *ver, dns_diff_t *diff)
+{
+	isc_result_t result = ISC_R_SUCCESS;
+	dns_difftuple_t *tuple, *newtuple = NULL, *next;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	unsigned char buf[DNS_NSEC3PARAM_BUFFERSIZE];
+	dns_diff_t temp_diff;
+	dns_diffop_t op;
+	isc_boolean_t flag;
+
+	update_log(client, zone, ISC_LOG_DEBUG(3),
+		    "checking for NSEC3PARAM changes");
+
+	dns_diff_init(diff->mctx, &temp_diff);
+
+	/*
+	 * Extract NSEC3PARAM tuples from list.
+	 */
+	for (tuple = ISC_LIST_HEAD(diff->tuples);
+	     tuple != NULL;
+	     tuple = next) {
+
+		next = ISC_LIST_NEXT(tuple, link);
+
+		if (tuple->rdata.type != dns_rdatatype_nsec3param ||
+		    !dns_name_equal(name, &tuple->name))
+			continue;
+		ISC_LIST_UNLINK(diff->tuples, tuple, link);
+		ISC_LIST_APPEND(temp_diff.tuples, tuple, link);
+	}
+
+	for (tuple = ISC_LIST_HEAD(temp_diff.tuples);
+	     tuple != NULL; tuple = next) {
+
+		if (tuple->op == DNS_DIFFOP_ADD) {
+			next = ISC_LIST_NEXT(tuple, link);
+			while (next != NULL) {
+				unsigned char *next_data = next->rdata.data;
+				unsigned char *tuple_data = tuple->rdata.data;
+				if (next_data[0] != tuple_data[0] ||
+					/* Ignore flags. */
+				    next_data[2] != tuple_data[2] ||
+				    next_data[3] != tuple_data[3] ||
+				    next_data[4] != tuple_data[4] ||
+				    !memcmp(&next_data[5], &tuple_data[5],
+					    tuple_data[4])) {
+					next = ISC_LIST_NEXT(next, link);
+					continue;
+				}
+				op = (next->op == DNS_DIFFOP_DEL) ?
+				     DNS_DIFFOP_ADD : DNS_DIFFOP_DEL;
+				CHECK(dns_difftuple_create(diff->mctx, op,
+							   name, next->ttl,
+							   &next->rdata,
+							   &newtuple));
+				CHECK(do_one_tuple(&newtuple, db, ver, diff));
+				ISC_LIST_UNLINK(temp_diff.tuples, next, link);
+				dns_diff_appendminimal(diff, &next);
+				next = ISC_LIST_NEXT(tuple, link);
+			}
+
+			INSIST(tuple->rdata.data[1] & DNS_NSEC3FLAG_UPDATE);
+
+			/*
+			 * See if we already have a CREATE request in progress.
+			 */
+			dns_rdata_clone(&tuple->rdata, &rdata);
+			INSIST(rdata.length <= sizeof(buf));
+			memcpy(buf, rdata.data, rdata.length);
+			buf[1] |= DNS_NSEC3FLAG_CREATE;
+			buf[1] &= ~DNS_NSEC3FLAG_UPDATE;
+			rdata.data = buf;
+
+			CHECK(rr_exists(db, ver, name, &rdata, &flag));
+
+			if (!flag) {
+				CHECK(dns_difftuple_create(diff->mctx,
+							   DNS_DIFFOP_ADD,
+							   name, tuple->ttl,
+							   &rdata,
+							   &newtuple));
+				CHECK(do_one_tuple(&newtuple, db, ver, diff));
+			}
+			/*
+			 * Remove the temporary add record.
+			 */
+			CHECK(dns_difftuple_create(diff->mctx, DNS_DIFFOP_DEL,
+						   name, tuple->ttl,
+						   &tuple->rdata, &newtuple));
+			CHECK(do_one_tuple(&newtuple, db, ver, diff));
+			next = ISC_LIST_NEXT(tuple, link);
+			ISC_LIST_UNLINK(temp_diff.tuples, tuple, link);
+			dns_diff_appendminimal(diff, &tuple);
+			dns_rdata_reset(&rdata);
+		} else
+			next = ISC_LIST_NEXT(tuple, link);
+	}
+
+	/*
+	 * Reverse any pending changes.
+	 */
+	for (tuple = ISC_LIST_HEAD(temp_diff.tuples);
+	     tuple != NULL; tuple = next) {
+		next = ISC_LIST_NEXT(tuple, link);
+		if ((tuple->rdata.data[1] & ~DNS_NSEC3FLAG_OPTOUT) != 0) {
+			op = (tuple->op == DNS_DIFFOP_DEL) ?
+			     DNS_DIFFOP_ADD : DNS_DIFFOP_DEL;
+			CHECK(dns_difftuple_create(diff->mctx, op, name,
+						   tuple->ttl, &tuple->rdata,
+						   &newtuple));
+			CHECK(do_one_tuple(&newtuple, db, ver, diff));
+			ISC_LIST_UNLINK(temp_diff.tuples, tuple, link);
+			dns_diff_appendminimal(diff, &tuple);
+		}
+	}
+
+	/*
+	 * Convert deletions into delayed deletions.
+	 */
+	for (tuple = ISC_LIST_HEAD(temp_diff.tuples);
+	     tuple != NULL; tuple = next) {
+		next = ISC_LIST_NEXT(tuple, link);
+		/*
+		 * See if we already have a REMOVE request in progress.
+		 */
+		dns_rdata_clone(&tuple->rdata, &rdata);
+		INSIST(rdata.length <= sizeof(buf));
+		memcpy(buf, rdata.data, rdata.length);
+		buf[1] |= DNS_NSEC3FLAG_REMOVE;
+		rdata.data = buf;
+
+		CHECK(rr_exists(db, ver, name, &rdata, &flag));
+
+		if (!flag) {
+			CHECK(dns_difftuple_create(diff->mctx, DNS_DIFFOP_ADD,
+						   name, tuple->ttl, &rdata,
+						   &newtuple));
+			CHECK(do_one_tuple(&newtuple, db, ver, diff));
+		}
+		CHECK(dns_difftuple_create(diff->mctx, DNS_DIFFOP_ADD, name,
+					   tuple->ttl, &tuple->rdata,
+					   &newtuple));
+		CHECK(do_one_tuple(&newtuple, db, ver, diff));
+		ISC_LIST_UNLINK(temp_diff.tuples, tuple, link);
+		dns_diff_appendminimal(diff, &tuple);
+		dns_rdata_reset(&rdata);
+	}
+
+	result = ISC_R_SUCCESS;
+ failure:
+	dns_diff_clear(&temp_diff);
+	return (result);
+}
+#endif
+
+/*
+ * Add records to cause the delayed signing of the zone by added DNSKEY
+ * to remove the RRSIG records generated by a deleted DNSKEY.
+ */
+static isc_result_t
+add_signing_records(dns_db_t *db, dns_name_t *name, dns_dbversion_t *ver,
+		    dns_rdatatype_t privatetype, dns_diff_t *diff)
+{
+	dns_difftuple_t *tuple, *newtuple = NULL;
+	dns_rdata_dnskey_t dnskey;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	isc_boolean_t flag;
+	isc_region_t r;
+	isc_result_t result = ISC_R_SUCCESS;
+	isc_uint16_t keyid;
+	unsigned char buf[5];
+
+	for (tuple = ISC_LIST_HEAD(diff->tuples);
+	     tuple != NULL;
+	     tuple = ISC_LIST_NEXT(tuple, link)) {
+		if (tuple->rdata.type != dns_rdatatype_dnskey)
+			continue;
+
+		dns_rdata_tostruct(&tuple->rdata, &dnskey, NULL);
+		if ((dnskey.flags &
+		     (DNS_KEYFLAG_OWNERMASK|DNS_KEYTYPE_NOAUTH))
+			 != DNS_KEYOWNER_ZONE)
+			continue;
+
+		dns_rdata_toregion(&tuple->rdata, &r);
+		keyid = dst_region_computeid(&r, dnskey.algorithm);
+
+		buf[0] = dnskey.algorithm;
+		buf[1] = (keyid & 0xff00) >> 8;
+		buf[2] = (keyid & 0xff);
+		buf[3] = (tuple->op == DNS_DIFFOP_ADD) ? 0 : 1;
+		buf[4] = 0;
+		rdata.data = buf;
+		rdata.length = sizeof(buf);
+		rdata.type = privatetype;
+		rdata.rdclass = tuple->rdata.rdclass;
+
+		CHECK(rr_exists(db, ver, name, &rdata, &flag));
+		if (flag)
+			continue;
+		CHECK(dns_difftuple_create(diff->mctx, DNS_DIFFOP_ADD,
+					   name, 0, &rdata, &newtuple));
+		CHECK(do_one_tuple(&newtuple, db, ver, diff));
+		INSIST(newtuple == NULL);
+		/*
+		 * Remove any record which says this operation has already
+		 * completed.
+		 */
+		buf[4] = 1;
+		CHECK(rr_exists(db, ver, name, &rdata, &flag));
+		if (flag) {
+			CHECK(dns_difftuple_create(diff->mctx, DNS_DIFFOP_DEL,
+						   name, 0, &rdata, &newtuple));
+			CHECK(do_one_tuple(&newtuple, db, ver, diff));
+			INSIST(newtuple == NULL);
+		}
+	}
+ failure:
+	return (result);
+}
+
+#ifdef ALLOW_NSEC3PARAM_UPDATE
+/*
+ * Mark all NSEC3 chains for deletion without creating a NSEC chain as
+ * a side effect of deleting the last chain.
+ */
+static isc_result_t
+delete_chains(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *origin,
+	      dns_diff_t *diff)
+{
+	dns_dbnode_t *node = NULL;
+	dns_difftuple_t *tuple = NULL;
+	dns_name_t next;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	dns_rdataset_t rdataset;
+	isc_boolean_t flag;
+	isc_result_t result = ISC_R_SUCCESS;
+	unsigned char buf[DNS_NSEC3PARAM_BUFFERSIZE];
+
+	dns_name_init(&next, NULL);
+	dns_rdataset_init(&rdataset);
+
+	result = dns_db_getoriginnode(db, &node);
+	if (result != ISC_R_SUCCESS)
+		return (result);
+
+	/*
+	 * Cause all NSEC3 chains to be deleted.
+	 */
+	result = dns_db_findrdataset(db, node, ver, dns_rdatatype_nsec3param,
+				     0, (isc_stdtime_t) 0, &rdataset, NULL);
+	if (result == ISC_R_NOTFOUND)
+		goto success;
+	if (result != ISC_R_SUCCESS)
+		goto failure;
+
+	for (result = dns_rdataset_first(&rdataset);
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdataset_next(&rdataset)) {
+		dns_rdataset_current(&rdataset, &rdata);
+		INSIST(rdata.length <= sizeof(buf));
+		memcpy(buf, rdata.data, rdata.length);
+
+		if (buf[1] == (DNS_NSEC3FLAG_REMOVE | DNS_NSEC3FLAG_NONSEC)) {
+			dns_rdata_reset(&rdata);
+			continue;
+		}
+
+		CHECK(dns_difftuple_create(diff->mctx, DNS_DIFFOP_DEL,
+					   origin, 0, &rdata, &tuple));
+		CHECK(do_one_tuple(&tuple, db, ver, diff));
+		INSIST(tuple == NULL);
+
+		buf[1] = DNS_NSEC3FLAG_REMOVE | DNS_NSEC3FLAG_NONSEC;
+		rdata.data = buf;
+
+		CHECK(rr_exists(db, ver, origin, &rdata, &flag));
+
+		if (!flag) {
+			CHECK(dns_difftuple_create(diff->mctx, DNS_DIFFOP_ADD,
+						   origin, 0, &rdata, &tuple));
+			CHECK(do_one_tuple(&tuple, db, ver, diff));
+			INSIST(tuple == NULL);
+		}
+		dns_rdata_reset(&rdata);
+	}
+	if (result != ISC_R_NOMORE)
+		goto failure;
+ success:
+	result = ISC_R_SUCCESS;
+
+ failure:
+	if (dns_rdataset_isassociated(&rdataset))
+		dns_rdataset_disassociate(&rdataset);
+	dns_db_detachnode(db, &node);
+	return (result);
+}
+#endif
+
 static void
 update_action(isc_task_t *task, isc_event_t *event) {
 	update_event_t *uev = (update_event_t *) event;
@@ -2339,8 +3379,8 @@ update_action(isc_task_t *task, isc_event_t *event) {
 	dns_db_t *db = NULL;
 	dns_dbversion_t *oldver = NULL;
 	dns_dbversion_t *ver = NULL;
-	dns_diff_t diff; 	/* Pending updates. */
-	dns_diff_t temp; 	/* Pending RR existence assertions. */
+	dns_diff_t diff;	/* Pending updates. */
+	dns_diff_t temp;	/* Pending RR existence assertions. */
 	isc_boolean_t soa_serial_changed = ISC_FALSE;
 	isc_mem_t *mctx = client->mctx;
 	dns_rdatatype_t covers;
@@ -2351,6 +3391,15 @@ update_action(isc_task_t *task, isc_event_t *event) {
 	dns_fixedname_t tmpnamefixed;
 	dns_name_t *tmpname = NULL;
 	unsigned int options;
+	isc_boolean_t deleted_zsk;
+	dns_difftuple_t *tuple;
+	dns_rdata_dnskey_t dnskey;
+#ifdef ALLOW_NSEC3PARAM_UPDATE
+	unsigned char buf[DNS_NSEC3PARAM_BUFFERSIZE];
+#endif
+#if !defined(ALLOW_SECURE_TO_INSECURE) || !defined(ALLOW_INSECURE_TO_SECURE)
+	isc_boolean_t had_dnskey;
+#endif
 
 	INSIST(event->ev_type == DNS_EVENT_UPDATE);
 
@@ -2382,54 +3431,59 @@ update_action(isc_task_t *task, isc_event_t *event) {
 			       &name, &rdata, &covers, &ttl, &update_class);
 
 		if (ttl != 0)
-			FAILC(DNS_R_FORMERR, "prerequisite TTL is not zero");
+			PREREQFAILC(DNS_R_FORMERR,
+				    "prerequisite TTL is not zero");
 
 		if (! dns_name_issubdomain(name, zonename))
-			FAILN(DNS_R_NOTZONE, name,
-				"prerequisite name is out of zone");
+			PREREQFAILN(DNS_R_NOTZONE, name,
+				    "prerequisite name is out of zone");
 
 		if (update_class == dns_rdataclass_any) {
 			if (rdata.length != 0)
-				FAILC(DNS_R_FORMERR,
+				PREREQFAILC(DNS_R_FORMERR,
 				      "class ANY prerequisite "
 				      "RDATA is not empty");
 			if (rdata.type == dns_rdatatype_any) {
 				CHECK(name_exists(db, ver, name, &flag));
 				if (! flag) {
-					FAILN(DNS_R_NXDOMAIN, name,
-					      "'name in use' prerequisite "
-					      "not satisfied");
+					PREREQFAILN(DNS_R_NXDOMAIN, name,
+						    "'name in use' "
+						    "prerequisite not "
+						    "satisfied");
 				}
 			} else {
 				CHECK(rrset_exists(db, ver, name,
 						   rdata.type, covers, &flag));
 				if (! flag) {
 					/* RRset does not exist. */
-					FAILNT(DNS_R_NXRRSET, name, rdata.type,
+					PREREQFAILNT(DNS_R_NXRRSET, name, rdata.type,
 					"'rrset exists (value independent)' "
 					"prerequisite not satisfied");
 				}
 			}
 		} else if (update_class == dns_rdataclass_none) {
 			if (rdata.length != 0)
-				FAILC(DNS_R_FORMERR,
-				      "class NONE prerequisite "
-				      "RDATA is not empty");
+				PREREQFAILC(DNS_R_FORMERR,
+					    "class NONE prerequisite "
+					    "RDATA is not empty");
 			if (rdata.type == dns_rdatatype_any) {
 				CHECK(name_exists(db, ver, name, &flag));
 				if (flag) {
-					FAILN(DNS_R_YXDOMAIN, name,
-					      "'name not in use' prerequisite "
-					      "not satisfied");
+					PREREQFAILN(DNS_R_YXDOMAIN, name,
+						    "'name not in use' "
+						    "prerequisite not "
+						    "satisfied");
 				}
 			} else {
 				CHECK(rrset_exists(db, ver, name,
 						   rdata.type, covers, &flag));
 				if (flag) {
 					/* RRset exists. */
-					FAILNT(DNS_R_YXRRSET, name, rdata.type,
-					       "'rrset does not exist' "
-					       "prerequisite not satisfied");
+					PREREQFAILNT(DNS_R_YXRRSET, name,
+						     rdata.type,
+						     "'rrset does not exist' "
+						     "prerequisite not "
+						     "satisfied");
 				}
 			}
 		} else if (update_class == zoneclass) {
@@ -2442,7 +3496,7 @@ update_action(isc_task_t *task, isc_event_t *event) {
 				FAIL(ISC_R_UNEXPECTED);
 			}
 		} else {
-			FAILC(DNS_R_FORMERR, "malformed prerequisite");
+			PREREQFAILC(DNS_R_FORMERR, "malformed prerequisite");
 		}
 	}
 	if (result != ISC_R_NOMORE)
@@ -2484,13 +3538,15 @@ update_action(isc_task_t *task, isc_event_t *event) {
 	result = ISC_R_SUCCESS;
 	if (ssutable == NULL)
 		CHECK(checkupdateacl(client, dns_zone_getupdateacl(zone),
-				     "update", zonename, ISC_FALSE));
-	else if (client->signer == NULL)
+				     "update", zonename, ISC_FALSE, ISC_FALSE));
+	else if (client->signer == NULL && !TCPCLIENT(client))
 		CHECK(checkupdateacl(client, NULL, "update", zonename,
-				     ISC_FALSE));
+				     ISC_FALSE, ISC_TRUE));
 
 	if (dns_zone_getupdatedisabled(zone))
-		FAILC(DNS_R_REFUSED, "dynamic update temporarily disabled");
+		FAILC(DNS_R_REFUSED, "dynamic update temporarily disabled "
+				     "because the zone is frozen.  Use "
+				     "'rndc thaw' to re-enable updates.");
 
 	/*
 	 * Perform the Update Section Prescan.
@@ -2546,29 +3602,47 @@ update_action(isc_task_t *task, isc_event_t *event) {
 		 * is forbidden from updating NSEC records."
 		 */
 		if (dns_db_issecure(db)) {
-			if (rdata.type == dns_rdatatype_nsec) {
+			if (rdata.type == dns_rdatatype_nsec3) {
+				FAILC(DNS_R_REFUSED,
+				      "explicit NSEC3 updates are not allowed "
+				      "in secure zones");
+			} else if (rdata.type == dns_rdatatype_nsec) {
 				FAILC(DNS_R_REFUSED,
 				      "explicit NSEC updates are not allowed "
 				      "in secure zones");
-			}
-			else if (rdata.type == dns_rdatatype_rrsig) {
+			} else if (rdata.type == dns_rdatatype_rrsig &&
+				   !dns_name_equal(name, zonename)) {
 				FAILC(DNS_R_REFUSED,
-				      "explicit RRSIG updates are currently not "
-				      "supported in secure zones");
+				      "explicit RRSIG updates are currently "
+				      "not supported in secure zones except "
+				      "at the apex");
 			}
 		}
 
-		if (ssutable != NULL && client->signer != NULL) {
+		if (ssutable != NULL) {
+			isc_netaddr_t *tcpaddr, netaddr;
+			/*
+			 * If this is a TCP connection then pass the
+			 * address of the client through for tcp-self
+			 * and 6to4-self otherwise pass NULL.  This
+			 * provides weak address based authentication.
+			 */
+			if (TCPCLIENT(client)) {
+				isc_netaddr_fromsockaddr(&netaddr,
+							 &client->peeraddr);
+				tcpaddr = &netaddr;
+			} else
+				tcpaddr = NULL;
 			if (rdata.type != dns_rdatatype_any) {
 				if (!dns_ssutable_checkrules(ssutable,
 							     client->signer,
-							     name, rdata.type))
+							     name, tcpaddr,
+							     rdata.type))
 					FAILC(DNS_R_REFUSED,
 					      "rejected by secure update");
-			}
-			else {
+			} else {
 				if (!ssu_checkall(db, ver, name, ssutable,
-						  client->signer))
+						  client->signer, tcpaddr))
 					FAILC(DNS_R_REFUSED,
 					      "rejected by secure update");
 			}
@@ -2613,12 +3687,17 @@ update_action(isc_task_t *task, isc_event_t *event) {
 					   typebuf);
 				continue;
 			}
-			if (rdata.type == dns_rdatatype_ns &&
+			if ((rdata.type == dns_rdatatype_ns ||
+			     rdata.type == dns_rdatatype_dname) &&
 			    dns_name_iswildcard(name)) {
+				char typebuf[DNS_RDATATYPE_FORMATSIZE];
+
+				dns_rdatatype_format(rdata.type, typebuf,
+						     sizeof(typebuf));
 				update_log(client, zone,
 					   LOGLEVEL_PROTOCOL,
-					   "attempt to add wildcard NS record"
-					   "ignored");
+					   "attempt to add wildcard %s record "
+					   "ignored", typebuf);
 				continue;
 			}
 			if (rdata.type == dns_rdatatype_cname) {
@@ -2671,6 +3750,43 @@ update_action(isc_task_t *task, isc_event_t *event) {
 				}
 				soa_serial_changed = ISC_TRUE;
 			}
+
+#ifdef ALLOW_NSEC3PARAM_UPDATE
+			if (rdata.type == dns_rdatatype_nsec3param) {
+				/*
+				 * Ignore attempts to add NSEC3PARAM records
+				 * with any flags other than OPTOUT.
+				 */
+				if ((rdata.data[1] & ~DNS_NSEC3FLAG_OPTOUT) != 0) {
+					update_log(client, zone,
+						   LOGLEVEL_PROTOCOL,
+						   "attempt to add NSEC3PARAM "
+						   "record with non OPTOUT "
+						   "flag");
+					continue;
+				}
+
+				/*
+				 * Set the NSEC3CHAIN creation flag.
+				 */
+				INSIST(rdata.length <= sizeof(buf));
+				memcpy(buf, rdata.data, rdata.length);
+				buf[1] |= DNS_NSEC3FLAG_UPDATE;
+				rdata.data = buf;
+				/*
+				 * Force the TTL to zero for NSEC3PARAM records.
+				 */
+				ttl = 0;
+			}
+#else
+			if (rdata.type == dns_rdatatype_nsec3param) {
+				update_log(client, zone, LOGLEVEL_PROTOCOL,
+					   "attempt to add NSEC3PARAM "
+					   "record ignored");
+				continue;
+			};
+#endif
+
 			if ((options & DNS_ZONEOPT_CHECKWILDCARD) != 0 &&
 			    dns_name_internalwildcard(name)) {
 				char namestr[DNS_NAME_FORMATSIZE];
@@ -2688,8 +3804,7 @@ update_action(isc_task_t *task, isc_event_t *event) {
 						sizeof(namestr));
 				dns_rdatatype_format(rdata.type, typestr,
 						     sizeof(typestr));
-				update_log(client, zone,
-					   LOGLEVEL_PROTOCOL,
+				update_log(client, zone, LOGLEVEL_PROTOCOL,
 					   "adding an RR at '%s' %s",
 					   namestr, typestr);
 			}
@@ -2714,8 +3829,10 @@ update_action(isc_task_t *task, isc_event_t *event) {
 					dns_diff_clear(&ctx.del_diff);
 					dns_diff_clear(&ctx.add_diff);
 				} else {
-					CHECK(do_diff(&ctx.del_diff, db, ver, &diff));
-					CHECK(do_diff(&ctx.add_diff, db, ver, &diff));
+					CHECK(do_diff(&ctx.del_diff, db, ver,
+						      &diff));
+					CHECK(do_diff(&ctx.add_diff, db, ver,
+						      &diff));
 					CHECK(update_one_rr(db, ver, &diff,
 							    DNS_DIFFOP_ADD,
 							    name, ttl, &rdata));
@@ -2745,11 +3862,17 @@ update_action(isc_task_t *task, isc_event_t *event) {
 							dns_rdatatype_any, 0,
 							&rdata, &diff));
 				}
+#ifndef ALLOW_NSEC3PARAM_UPDATE
+			} else if (rdata.type == dns_rdatatype_nsec3param) {
+				update_log(client, zone, LOGLEVEL_PROTOCOL,
+					   "attempt to delete a NSEC3PARAM "
+					   "records ignored");
+				continue;
+#endif
 			} else if (dns_name_equal(name, zonename) &&
 				   (rdata.type == dns_rdatatype_soa ||
 				    rdata.type == dns_rdatatype_ns)) {
-				update_log(client, zone,
-					   LOGLEVEL_PROTOCOL,
+				update_log(client, zone, LOGLEVEL_PROTOCOL,
 					   "attempt to delete all SOA "
 					   "or NS records ignored");
 				continue;
@@ -2812,6 +3935,14 @@ update_action(isc_task_t *task, isc_event_t *event) {
 		FAIL(result);
 
 	/*
+	 * Check that any changes to DNSKEY/NSEC3PARAM records make sense.
+	 * If they don't then back out all changes to DNSKEY/NSEC3PARAM
+	 * records.
+	 */
+	if (! ISC_LIST_EMPTY(diff.tuples))
+		CHECK(check_dnssec(client, zone, db, ver, &diff));
+
+	/*
 	 * If any changes were made, increment the SOA serial number,
 	 * update RRSIGs and NSECs (if zone is secure), and write the update
 	 * to the journal.
@@ -2819,6 +3950,7 @@ update_action(isc_task_t *task, isc_event_t *event) {
 	if (! ISC_LIST_EMPTY(diff.tuples)) {
 		char *journalfile;
 		dns_journal_t *journal;
+		isc_boolean_t has_dnskey;
 
 		/*
 		 * Increment the SOA serial, but only if it was not
@@ -2832,14 +3964,61 @@ update_action(isc_task_t *task, isc_event_t *event) {
 
 		CHECK(remove_orphaned_ds(db, ver, &diff));
 
-		if (dns_db_issecure(db)) {
+		CHECK(rrset_exists(db, ver, zonename, dns_rdatatype_dnskey,
+				   0, &has_dnskey));
+
+#if !defined(ALLOW_SECURE_TO_INSECURE) || !defined(ALLOW_INSECURE_TO_SECURE)
+		CHECK(rrset_exists(db, oldver, zonename, dns_rdatatype_dnskey,
+				   0, &had_dnskey));
+
+#ifndef ALLOW_SECURE_TO_INSECURE
+		if (had_dnskey && !has_dnskey) {
+			update_log(client, zone, LOGLEVEL_PROTOCOL,
+				   "update rejected: all DNSKEY records "
+				   "removed");
+			result = DNS_R_REFUSED;
+			goto failure;
+		}
+#endif
+#ifndef ALLOW_INSECURE_TO_SECURE
+		if (!had_dnskey && has_dnskey) {
+			update_log(client, zone, LOGLEVEL_PROTOCOL,
+				   "update rejected: DNSKEY record added");
+			result = DNS_R_REFUSED;
+			goto failure;
+		}
+#endif
+#endif
+
+		CHECK(add_signing_records(db, zonename, ver,
+					  dns_zone_getprivatetype(zone),
+					  &diff));
+
+#ifdef ALLOW_NSEC3PARAM_UPDATE
+		CHECK(add_nsec3param_records(client, zone, db, zonename,
+					     ver, &diff));
+#endif
+
+		if (!has_dnskey) {
+			/*
+			 * We are transitioning from secure to insecure.
+			 * Cause all NSEC3 chains to be deleted.  When the
+			 * the last signature for the DNSKEY records are
+			 * remove any NSEC chain present will also be removed.
+			 */
+#ifdef ALLOW_NSEC3PARAM_UPDATE
+			 CHECK(delete_chains(db, ver, zonename, &diff));
+#endif
+		} else if (has_dnskey && dns_db_isdnssec(db)) {
+			isc_uint32_t interval;
+			interval = dns_zone_getsigvalidityinterval(zone);
 			result = update_signatures(client, zone, db, oldver,
-						   ver, &diff,
-					 dns_zone_getsigvalidityinterval(zone));
+						   ver, &diff, interval,
+						   &deleted_zsk);
 			if (result != ISC_R_SUCCESS) {
 				update_log(client, zone,
 					   ISC_LOG_ERROR,
-					   "RRSIG/NSEC update failed: %s",
+					   "RRSIG/NSEC/NSEC3 update failed: %s",
 					   isc_result_totext(result));
 				goto failure;
 			}
@@ -2872,6 +4051,7 @@ update_action(isc_task_t *task, isc_event_t *event) {
 		 */
 		update_log(client, zone, LOGLEVEL_DEBUG,
 			   "committing update transaction");
+
 		dns_db_closeversion(db, &ver, ISC_TRUE);
 
 		/*
@@ -2883,6 +4063,71 @@ update_action(isc_task_t *task, isc_event_t *event) {
 		 * Notify slaves of the change we just made.
 		 */
 		dns_zone_notify(zone);
+
+		/*
+		 * Cause the zone to be signed with the key that we
+		 * have just added or have the corresponding signatures
+		 * deleted.
+		 *
+		 * Note: we are already committed to this course of action.
+		 */
+		for (tuple = ISC_LIST_HEAD(diff.tuples);
+		     tuple != NULL;
+		     tuple = ISC_LIST_NEXT(tuple, link)) {
+			isc_region_t r;
+			dns_secalg_t algorithm;
+			isc_uint16_t keyid;
+
+			if (tuple->rdata.type != dns_rdatatype_dnskey)
+				continue;
+
+			dns_rdata_tostruct(&tuple->rdata, &dnskey, NULL);
+			if ((dnskey.flags &
+			     (DNS_KEYFLAG_OWNERMASK|DNS_KEYTYPE_NOAUTH))
+				 != DNS_KEYOWNER_ZONE)
+				continue;
+
+			dns_rdata_toregion(&tuple->rdata, &r);
+			algorithm = dnskey.algorithm;
+			keyid = dst_region_computeid(&r, algorithm);
+
+			result = dns_zone_signwithkey(zone, algorithm, keyid,
+					ISC_TF(tuple->op == DNS_DIFFOP_DEL));
+			if (result != ISC_R_SUCCESS) {
+				update_log(client, zone, ISC_LOG_ERROR,
+					   "dns_zone_signwithkey failed: %s",
+					   dns_result_totext(result));
+			}
+		}
+
+#ifdef ALLOW_NSEC3PARAM_UPDATE
+		/*
+		 * Cause the zone to add/delete NSEC3 chains for the
+		 * deferred NSEC3PARAM changes.
+		 *
+		 * Note: we are already committed to this course of action.
+		 */
+		for (tuple = ISC_LIST_HEAD(diff.tuples);
+		     tuple != NULL;
+		     tuple = ISC_LIST_NEXT(tuple, link)) {
+			dns_rdata_nsec3param_t nsec3param;
+
+			if (tuple->rdata.type != dns_rdatatype_nsec3param ||
+			    tuple->op != DNS_DIFFOP_ADD)
+				continue;
+
+			dns_rdata_tostruct(&tuple->rdata, &nsec3param, NULL);
+			if (nsec3param.flags == 0)
+				continue;
+
+			result = dns_zone_addnsec3chain(zone, &nsec3param);
+			if (result != ISC_R_SUCCESS) {
+				update_log(client, zone, ISC_LOG_ERROR,
+					   "dns_zone_addnsec3chain failed: %s",
+					   dns_result_totext(result));
+			}
+		}
+#endif
 	} else {
 		update_log(client, zone, LOGLEVEL_DEBUG, "redundant request");
 		dns_db_closeversion(db, &ver, ISC_TRUE);
@@ -2891,6 +4136,9 @@ update_action(isc_task_t *task, isc_event_t *event) {
 	goto common;
 
  failure:
+	if (result == DNS_R_REFUSED)
+		inc_stats(zone, dns_nsstatscounter_updaterej);
+
 	/*
 	 * The reason for failure should have been logged at this point.
 	 */
@@ -2913,11 +4161,10 @@ update_action(isc_task_t *task, isc_event_t *event) {
 	if (ssutable != NULL)
 		dns_ssutable_detach(&ssutable);
 
-	if (zone != NULL)
-		dns_zone_detach(&zone);
-
 	isc_task_detach(&task);
 	uev->result = result;
+	if (zone != NULL)
+		INSIST(uev->zone == zone); /* we use this later */
 	uev->ev_type = DNS_EVENT_UPDATEDONE;
 	uev->ev_action = updatedone_action;
 	isc_task_send(client->task, &event);
@@ -2935,6 +4182,19 @@ updatedone_action(isc_task_t *task, isc_event_t *event) {
 	INSIST(task == client->task);
 
 	INSIST(client->nupdates > 0);
+	switch (uev->result) {
+	case ISC_R_SUCCESS:
+		inc_stats(uev->zone, dns_nsstatscounter_updatedone);
+		break;
+	case DNS_R_REFUSED:
+		inc_stats(uev->zone, dns_nsstatscounter_updaterej);
+		break;
+	default:
+		inc_stats(uev->zone, dns_nsstatscounter_updatefail);
+		break;
+	}
+	if (uev->zone != NULL)
+		dns_zone_detach(&uev->zone);
 	client->nupdates--;
 	respond(client, uev->result);
 	isc_event_free(&event);
@@ -2963,17 +4223,21 @@ static void
 forward_callback(void *arg, isc_result_t result, dns_message_t *answer) {
 	update_event_t *uev = arg;
 	ns_client_t *client = uev->ev_arg;
+	dns_zone_t *zone = uev->zone;
 
 	if (result != ISC_R_SUCCESS) {
 		INSIST(answer == NULL);
 		uev->ev_type = DNS_EVENT_UPDATEDONE;
 		uev->ev_action = forward_fail;
+		inc_stats(zone, dns_nsstatscounter_updatefwdfail);
 	} else {
 		uev->ev_type = DNS_EVENT_UPDATEDONE;
 		uev->ev_action = forward_done;
 		uev->answer = answer;
+		inc_stats(zone, dns_nsstatscounter_updaterespfwd);
 	}
 	isc_task_send(client->task, ISC_EVENT_PTR(&uev));
+	dns_zone_detach(&zone);
 }
 
 static void
@@ -3004,8 +4268,10 @@ forward_action(isc_task_t *task, isc_event_t *event) {
 		uev->ev_type = DNS_EVENT_UPDATEDONE;
 		uev->ev_action = forward_fail;
 		isc_task_send(client->task, &event);
-	}
-	dns_zone_detach(&zone);
+		inc_stats(zone, dns_nsstatscounter_updatefwdfail);
+		dns_zone_detach(&zone);
+	} else
+		inc_stats(zone, dns_nsstatscounter_updatereqfwd);
 	isc_task_detach(&task);
 }
 
diff --git a/contrib/bind9/bin/named/xfrout.c b/contrib/bind9/bin/named/xfrout.c
index 9fe90a2..0aa6f79 100644
--- a/contrib/bind9/bin/named/xfrout.c
+++ b/contrib/bind9/bin/named/xfrout.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: xfrout.c,v 1.115.18.8 2006/03/05 23:58:51 marka Exp $ */
+/* $Id: xfrout.c,v 1.131.26.4 2009/01/29 22:40:34 jinmei Exp $ */
 
 #include <config.h>
 
@@ -23,6 +23,7 @@
 #include <isc/mem.h>
 #include <isc/timer.h>
 #include <isc/print.h>
+#include <isc/stats.h>
 #include <isc/util.h>
 
 #include <dns/db.h>
@@ -40,6 +41,7 @@
 #include <dns/rdatasetiter.h>
 #include <dns/result.h>
 #include <dns/soa.h>
+#include <dns/stats.h>
 #include <dns/timer.h>
 #include <dns/tsig.h>
 #include <dns/view.h>
@@ -51,7 +53,7 @@
 #include <named/server.h>
 #include <named/xfrout.h>
 
-/*! \file 
+/*! \file
  * \brief
  * Outgoing AXFR and IXFR.
  */
@@ -86,7 +88,7 @@
 		ns_client_log(client, DNS_LOGCATEGORY_XFER_OUT, \
 			   NS_LOGMODULE_XFER_OUT, ISC_LOG_INFO, \
 			   "bad zone transfer request: %s (%s)", \
-		      	   msg, isc_result_totext(code));	\
+			   msg, isc_result_totext(code));	\
 		if (result != ISC_R_SUCCESS) goto failure;	\
 	} while (0)
 
@@ -100,12 +102,12 @@
 		ns_client_log(client, DNS_LOGCATEGORY_XFER_OUT, \
 			   NS_LOGMODULE_XFER_OUT, ISC_LOG_INFO, \
 			   "bad zone transfer request: '%s/%s': %s (%s)", \
-		      	   _buf1, _buf2, msg, isc_result_totext(code));	\
+			   _buf1, _buf2, msg, isc_result_totext(code));	\
 		if (result != ISC_R_SUCCESS) goto failure;	\
 	} while (0)
 
 #define CHECK(op) \
-     	do { result = (op); 					\
+	do { result = (op); 					\
 		if (result != ISC_R_SUCCESS) goto failure; 	\
 	} while (0)
 
@@ -121,12 +123,12 @@ typedef struct db_rr_iterator db_rr_iterator_t;
 struct db_rr_iterator {
 	isc_result_t		result;
 	dns_db_t		*db;
-    	dns_dbiterator_t 	*dbit;
+	dns_dbiterator_t 	*dbit;
 	dns_dbversion_t 	*ver;
 	isc_stdtime_t		now;
 	dns_dbnode_t		*node;
 	dns_fixedname_t		fixedname;
-    	dns_rdatasetiter_t 	*rdatasetit;
+	dns_rdatasetiter_t 	*rdatasetit;
 	dns_rdataset_t 		rdataset;
 	dns_rdata_t		rdata;
 };
@@ -148,6 +150,16 @@ db_rr_iterator_current(db_rr_iterator_t *it, dns_name_t **name,
 static void
 db_rr_iterator_destroy(db_rr_iterator_t *it);
 
+static inline void
+inc_stats(dns_zone_t *zone, isc_statscounter_t counter) {
+	isc_stats_increment(ns_g_server->nsstats, counter);
+	if (zone != NULL) {
+		isc_stats_t *zonestats = dns_zone_getrequeststats(zone);
+		if (zonestats != NULL)
+			isc_stats_increment(zonestats, counter);
+	}
+}
+
 static isc_result_t
 db_rr_iterator_init(db_rr_iterator_t *it, dns_db_t *db, dns_dbversion_t *ver,
 		    isc_stdtime_t now)
@@ -158,7 +170,7 @@ db_rr_iterator_init(db_rr_iterator_t *it, dns_db_t *db, dns_dbversion_t *ver,
 	it->ver = ver;
 	it->now = now;
 	it->node = NULL;
-	result = dns_db_createiterator(it->db, ISC_FALSE, &it->dbit);
+	result = dns_db_createiterator(it->db, 0, &it->dbit);
 	if (result != ISC_R_SUCCESS)
 		return (result);
 	it->rdatasetit = NULL;
@@ -303,6 +315,11 @@ log_rr(dns_name_t *name, dns_rdata_t *rdata, isc_uint32_t ttl) {
 	rdl.type = rdata->type;
 	rdl.rdclass = rdata->rdclass;
 	rdl.ttl = ttl;
+	if (rdata->type == dns_rdatatype_sig ||
+	    rdata->type == dns_rdatatype_rrsig)
+		rdl.covers = dns_rdata_covers(rdata);
+	else
+		rdl.covers = dns_rdatatype_none;
 	ISC_LIST_INIT(rdl.rdata);
 	ISC_LINK_INIT(&rdl, link);
 	dns_rdataset_init(&rds);
@@ -326,7 +343,7 @@ log_rr(dns_name_t *name, dns_rdata_t *rdata, isc_uint32_t ttl) {
 		INSIST(buf.used >= 1 &&
 		       ((char *) buf.base)[buf.used - 1] == '\n');
 		buf.used--;
-		
+
 		isc_log_write(XFROUT_RR_LOGARGS, "%.*s",
 			      (int)isc_buffer_usedlength(&buf),
 			      (char *)isc_buffer_base(&buf));
@@ -818,6 +835,7 @@ typedef struct {
 	dns_name_t		*qname;		/* Question name of request */
 	dns_rdatatype_t		qtype;		/* dns_rdatatype_{a,i}xfr */
 	dns_rdataclass_t	qclass;
+	dns_zone_t 		*zone;		/* (necessary for stats) */
 	dns_db_t 		*db;
 	dns_dbversion_t 	*ver;
 	isc_quota_t		*quota;
@@ -841,7 +859,7 @@ typedef struct {
 static isc_result_t
 xfrout_ctx_create(isc_mem_t *mctx, ns_client_t *client,
 		  unsigned int id, dns_name_t *qname, dns_rdatatype_t qtype,
-		  dns_rdataclass_t qclass,
+		  dns_rdataclass_t qclass, dns_zone_t *zone,
 		  dns_db_t *db, dns_dbversion_t *ver, isc_quota_t *quota,
 		  rrstream_t *stream, dns_tsigkey_t *tsigkey,
 		  isc_buffer_t *lasttsig,
@@ -969,7 +987,7 @@ ns_xfr_start(ns_client_t *client, dns_rdatatype_t reqtype) {
 		/*
 		 * Normal zone table does not have a match.  Try the DLZ database
 		 */
-	    	if (client->view->dlzdatabase != NULL) {
+		if (client->view->dlzdatabase != NULL) {
 			result = dns_dlzallowzonexfr(client->view,
 						     question_name, &client->peeraddr,
 						     &db);
@@ -1006,7 +1024,7 @@ ns_xfr_start(ns_client_t *client, dns_rdatatype_t reqtype) {
 
 		} else {
 			/*
-		 	 * not DLZ and not in normal zone table, we are
+			 * not DLZ and not in normal zone table, we are
 			 * not authoritative
 			 */
 			FAILQ(DNS_R_NOTAUTH, "non-authoritative zone",
@@ -1090,9 +1108,9 @@ ns_xfr_start(ns_client_t *client, dns_rdatatype_t reqtype) {
 #endif
 		ns_client_aclmsg("zone transfer", question_name, reqtype,
 				 client->view->rdclass, msg, sizeof(msg));
-		CHECK(ns_client_checkacl(client, msg,
-					 dns_zone_getxfracl(zone), ISC_TRUE,
-					 ISC_LOG_ERROR));
+		CHECK(ns_client_checkacl(client, NULL, msg,
+					 dns_zone_getxfracl(zone),
+					 ISC_TRUE, ISC_LOG_ERROR));
 #ifdef DLZ
 	}
 #endif
@@ -1191,7 +1209,7 @@ ns_xfr_start(ns_client_t *client, dns_rdatatype_t reqtype) {
 	}
 
 	/*
-	 * Bracket the the data stream with SOAs.
+	 * Bracket the data stream with SOAs.
 	 */
 	CHECK(soa_rrstream_create(mctx, db, ver, &soa_stream));
 	CHECK(compound_rrstream_create(mctx, &soa_stream, &data_stream,
@@ -1210,26 +1228,28 @@ ns_xfr_start(ns_client_t *client, dns_rdatatype_t reqtype) {
 
 #ifdef DLZ
 	if (is_dlz)
- 		CHECK(xfrout_ctx_create(mctx, client, request->id, question_name,
- 					reqtype, question_class, db, ver, quota,
- 					stream, dns_message_gettsigkey(request),
- 					tsigbuf,
- 					3600,
- 					3600,
- 					(format == dns_many_answers) ?
-  					ISC_TRUE : ISC_FALSE,
- 					&xfr));
- 	else
+		CHECK(xfrout_ctx_create(mctx, client, request->id, question_name,
+					reqtype, question_class, zone, db, ver,
+					quota, stream,
+					dns_message_gettsigkey(request),
+					tsigbuf,
+					3600,
+					3600,
+					(format == dns_many_answers) ?
+					ISC_TRUE : ISC_FALSE,
+					&xfr));
+	else
 #endif
- 		CHECK(xfrout_ctx_create(mctx, client, request->id, question_name,
- 					reqtype, question_class, db, ver, quota,
- 					stream, dns_message_gettsigkey(request),
- 					tsigbuf,
- 					dns_zone_getmaxxfrout(zone),
- 					dns_zone_getidleout(zone),
- 					(format == dns_many_answers) ?
- 					ISC_TRUE : ISC_FALSE,
- 					&xfr));
+		CHECK(xfrout_ctx_create(mctx, client, request->id, question_name,
+					reqtype, question_class, zone, db, ver,
+					quota, stream,
+					dns_message_gettsigkey(request),
+					tsigbuf,
+					dns_zone_getmaxxfrout(zone),
+					dns_zone_getidleout(zone),
+					(format == dns_many_answers) ?
+					ISC_TRUE : ISC_FALSE,
+					&xfr));
 
 	xfr->mnemonic = mnemonic;
 	stream = NULL;
@@ -1261,6 +1281,8 @@ ns_xfr_start(ns_client_t *client, dns_rdatatype_t reqtype) {
 	result = ISC_R_SUCCESS;
 
  failure:
+	if (result == DNS_R_REFUSED)
+		inc_stats(zone, dns_nsstatscounter_xfrrej);
 	if (quota != NULL)
 		isc_quota_detach(&quota);
 	if (current_soa_tuple != NULL)
@@ -1291,7 +1313,7 @@ ns_xfr_start(ns_client_t *client, dns_rdatatype_t reqtype) {
 static isc_result_t
 xfrout_ctx_create(isc_mem_t *mctx, ns_client_t *client, unsigned int id,
 		  dns_name_t *qname, dns_rdatatype_t qtype,
-		  dns_rdataclass_t qclass,
+		  dns_rdataclass_t qclass, dns_zone_t *zone,
 		  dns_db_t *db, dns_dbversion_t *ver, isc_quota_t *quota,
 		  rrstream_t *stream, dns_tsigkey_t *tsigkey,
 		  isc_buffer_t *lasttsig, unsigned int maxtime,
@@ -1314,8 +1336,11 @@ xfrout_ctx_create(isc_mem_t *mctx, ns_client_t *client, unsigned int id,
 	xfr->qname = qname;
 	xfr->qtype = qtype;
 	xfr->qclass = qclass;
+	xfr->zone = NULL;
 	xfr->db = NULL;
 	xfr->ver = NULL;
+	if (zone != NULL)	/* zone will be NULL if it's DLZ */
+		dns_zone_attach(zone, &xfr->zone);
 	dns_db_attach(db, &xfr->db);
 	dns_db_attachversion(db, ver, &xfr->ver);
 	xfr->end_of_stream = ISC_FALSE;
@@ -1399,7 +1424,7 @@ failure:
  *
  * Requires:
  *	The stream iterator is initialized and points at an RR,
- *      or possiby at the end of the stream (that is, the
+ *      or possibly at the end of the stream (that is, the
  *      _first method of the iterator has been called).
  */
 static void
@@ -1573,6 +1598,11 @@ sendstream(xfrout_ctx_t *xfr) {
 		msgrdl->type = rdata->type;
 		msgrdl->rdclass = rdata->rdclass;
 		msgrdl->ttl = ttl;
+		if (rdata->type == dns_rdatatype_sig ||
+		    rdata->type == dns_rdatatype_rrsig)
+			msgrdl->covers = dns_rdata_covers(rdata);
+		else
+			msgrdl->covers = dns_rdatatype_none;
 		ISC_LINK_INIT(msgrdl, link);
 		ISC_LIST_INIT(msgrdl->rdata);
 		ISC_LIST_APPEND(msgrdl->rdata, msgrdata, link);
@@ -1663,7 +1693,7 @@ sendstream(xfrout_ctx_t *xfr) {
 	 * iterators before returning from the event handler.
 	 */
 	xfr->stream->methods->pause(xfr->stream);
-	
+
 	if (result == ISC_R_SUCCESS)
 		return;
 
@@ -1691,6 +1721,8 @@ xfrout_ctx_destroy(xfrout_ctx_t **xfrp) {
 		isc_quota_detach(&xfr->quota);
 	if (xfr->ver != NULL)
 		dns_db_closeversion(xfr->db, &xfr->ver, ISC_FALSE);
+	if (xfr->zone != NULL)
+		dns_zone_detach(&xfr->zone);
 	if (xfr->db != NULL)
 		dns_db_detach(&xfr->db);
 
@@ -1724,6 +1756,7 @@ xfrout_senddone(isc_task_t *task, isc_event_t *event) {
 		sendstream(xfr);
 	} else {
 		/* End of zone transfer stream. */
+		inc_stats(xfr->zone, dns_nsstatscounter_xfrdone);
 		xfrout_log(xfr, ISC_LOG_INFO, "%s ended", xfr->mnemonic);
 		ns_client_next(xfr->client, ISC_R_SUCCESS);
 		xfrout_ctx_destroy(&xfr);
diff --git a/contrib/bind9/bin/named/zoneconf.c b/contrib/bind9/bin/named/zoneconf.c
index a0c1bab..641831d 100644
--- a/contrib/bind9/bin/named/zoneconf.c
+++ b/contrib/bind9/bin/named/zoneconf.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: zoneconf.c,v 1.110.18.23 2006/05/16 03:39:57 marka Exp $ */
+/* $Id: zoneconf.c,v 1.147.50.2 2009/01/29 23:47:44 tbox Exp $ */
 
 /*% */
 
@@ -25,6 +25,7 @@
 #include <isc/file.h>
 #include <isc/mem.h>
 #include <isc/print.h>
+#include <isc/stats.h>
 #include <isc/string.h>		/* Required for HP/UX (and others?) */
 #include <isc/util.h>
 
@@ -34,6 +35,7 @@
 #include <dns/name.h>
 #include <dns/rdatatype.h>
 #include <dns/ssu.h>
+#include <dns/stats.h>
 #include <dns/view.h>
 #include <dns/zone.h>
 
@@ -44,6 +46,15 @@
 #include <named/server.h>
 #include <named/zoneconf.h>
 
+/* ACLs associated with zone */
+typedef enum {
+	allow_notify,
+	allow_query,
+	allow_transfer,
+	allow_update,
+	allow_update_forwarding
+} acl_type_t;
+
 /*%
  * These are BIND9 server defaults, not necessarily identical to the
  * library defaults defined in zone.c.
@@ -59,19 +70,69 @@
  */
 static isc_result_t
 configure_zone_acl(const cfg_obj_t *zconfig, const cfg_obj_t *vconfig,
-		   const cfg_obj_t *config, const char *aclname,
-		   cfg_aclconfctx_t *actx, dns_zone_t *zone, 
+		   const cfg_obj_t *config, acl_type_t acltype,
+		   cfg_aclconfctx_t *actx, dns_zone_t *zone,
 		   void (*setzacl)(dns_zone_t *, dns_acl_t *),
 		   void (*clearzacl)(dns_zone_t *))
 {
 	isc_result_t result;
-	const cfg_obj_t *maps[5];
+	const cfg_obj_t *maps[5] = {NULL, NULL, NULL, NULL, NULL};
 	const cfg_obj_t *aclobj = NULL;
 	int i = 0;
-	dns_acl_t *dacl = NULL;
+	dns_acl_t **aclp = NULL, *acl = NULL;
+	const char *aclname;
+	dns_view_t *view;
+
+	view = dns_zone_getview(zone);
+
+	switch (acltype) {
+	    case allow_notify:
+		if (view != NULL)
+			aclp = &view->notifyacl;
+		aclname = "allow-notify";
+		break;
+	    case allow_query:
+		if (view != NULL)
+			aclp = &view->queryacl;
+		aclname = "allow-query";
+		break;
+	    case allow_transfer:
+		if (view != NULL)
+			aclp = &view->transferacl;
+		aclname = "allow-transfer";
+		break;
+	    case allow_update:
+		if (view != NULL)
+			aclp = &view->updateacl;
+		aclname = "allow-update";
+		break;
+	    case allow_update_forwarding:
+		if (view != NULL)
+			aclp = &view->upfwdacl;
+		aclname = "allow-update-forwarding";
+		break;
+	    default:
+		INSIST(0);
+		return (ISC_R_FAILURE);
+	}
 
-	if (zconfig != NULL)
-		maps[i++] = cfg_tuple_get(zconfig, "options");
+	/* First check to see if ACL is defined within the zone */
+	if (zconfig != NULL) {
+		maps[0] = cfg_tuple_get(zconfig, "options");
+		ns_config_get(maps, aclname, &aclobj);
+		if (aclobj != NULL) {
+			aclp = NULL;
+			goto parse_acl;
+		}
+	}
+
+	/* Failing that, see if there's a default ACL already in the view */
+	if (aclp != NULL && *aclp != NULL) {
+		(*setzacl)(zone, *aclp);
+		return (ISC_R_SUCCESS);
+	}
+
+	/* Check for default ACLs that haven't been parsed yet */
 	if (vconfig != NULL)
 		maps[i++] = cfg_tuple_get(vconfig, "options");
 	if (config != NULL) {
@@ -89,12 +150,18 @@ configure_zone_acl(const cfg_obj_t *zconfig, const cfg_obj_t *vconfig,
 		return (ISC_R_SUCCESS);
 	}
 
+parse_acl:
 	result = cfg_acl_fromconfig(aclobj, config, ns_g_lctx, actx,
-				    dns_zone_getmctx(zone), &dacl);
+				    dns_zone_getmctx(zone), 0, &acl);
 	if (result != ISC_R_SUCCESS)
 		return (result);
-	(*setzacl)(zone, dacl);
-	dns_acl_detach(&dacl);
+	(*setzacl)(zone, acl);
+
+	/* Set the view default now */
+	if (aclp != NULL)
+		dns_acl_attach(acl, aclp);
+
+	dns_acl_detach(&acl);
 	return (ISC_R_SUCCESS);
 }
 
@@ -158,6 +225,18 @@ configure_zone_ssutable(const cfg_obj_t *zconfig, dns_zone_t *zone) {
 			mtype = DNS_SSUMATCHTYPE_SELFSUB;
 		else if (strcasecmp(str, "selfwild") == 0)
 			mtype = DNS_SSUMATCHTYPE_SELFWILD;
+		else if (strcasecmp(str, "ms-self") == 0)
+			mtype = DNS_SSUMATCHTYPE_SELFMS;
+		else if (strcasecmp(str, "krb5-self") == 0)
+			mtype = DNS_SSUMATCHTYPE_SELFKRB5;
+		else if (strcasecmp(str, "ms-subdomain") == 0)
+			mtype = DNS_SSUMATCHTYPE_SUBDOMAINMS;
+		else if (strcasecmp(str, "krb5-subdomain") == 0)
+			mtype = DNS_SSUMATCHTYPE_SUBDOMAINKRB5;
+		else if (strcasecmp(str, "tcp-self") == 0)
+			mtype = DNS_SSUMATCHTYPE_TCPSELF;
+		else if (strcasecmp(str, "6to4-self") == 0)
+			mtype = DNS_SSUMATCHTYPE_6TO4SELF;
 		else
 			INSIST(0);
 
@@ -264,11 +343,11 @@ strtoargvsub(isc_mem_t *mctx, char *s, unsigned int *argcp,
 	     char ***argvp, unsigned int n)
 {
 	isc_result_t result;
-	
+
 	/* Discard leading whitespace. */
 	while (*s == ' ' || *s == '\t')
 		s++;
-	
+
 	if (*s == '\0') {
 		/* We have reached the end of the string. */
 		*argcp = n;
@@ -353,6 +432,9 @@ ns_zone_configure(const cfg_obj_t *config, const cfg_obj_t *vconfig,
 	isc_boolean_t warn = ISC_FALSE, ignore = ISC_FALSE;
 	isc_boolean_t ixfrdiff;
 	dns_masterformat_t masterformat;
+	isc_stats_t *zoneqrystats;
+	isc_boolean_t zonestats_on;
+	int seconds;
 
 	i = 0;
 	if (zconfig != NULL) {
@@ -443,14 +525,14 @@ ns_zone_configure(const cfg_obj_t *config, const cfg_obj_t *vconfig,
 
 	if (ztype == dns_zone_slave)
 		RETERR(configure_zone_acl(zconfig, vconfig, config,
-					  "allow-notify", ac, zone,
+					  allow_notify, ac, zone,
 					  dns_zone_setnotifyacl,
 					  dns_zone_clearnotifyacl));
 	/*
 	 * XXXAG This probably does not make sense for stubs.
 	 */
 	RETERR(configure_zone_acl(zconfig, vconfig, config,
-				  "allow-query", ac, zone,
+				  allow_query, ac, zone,
 				  dns_zone_setqueryacl,
 				  dns_zone_clearqueryacl));
 
@@ -480,7 +562,15 @@ ns_zone_configure(const cfg_obj_t *config, const cfg_obj_t *vconfig,
 	obj = NULL;
 	result = ns_config_get(maps, "zone-statistics", &obj);
 	INSIST(result == ISC_R_SUCCESS);
-	RETERR(dns_zone_setstatistics(zone, cfg_obj_asboolean(obj)));
+	zonestats_on = cfg_obj_asboolean(obj);
+	zoneqrystats = NULL;
+	if (zonestats_on) {
+		RETERR(isc_stats_create(mctx, &zoneqrystats,
+					dns_nsstatscounter_max));
+	}
+	dns_zone_setrequeststats(zone, zoneqrystats);
+	if (zoneqrystats != NULL)
+		isc_stats_detach(&zoneqrystats);
 
 	/*
 	 * Configure master functionality.  This applies
@@ -536,10 +626,16 @@ ns_zone_configure(const cfg_obj_t *config, const cfg_obj_t *vconfig,
 		RETERR(dns_zone_setnotifysrc6(zone, cfg_obj_assockaddr(obj)));
 		ns_add_reserved_dispatch(ns_g_server, cfg_obj_assockaddr(obj));
 
+		obj = NULL;
+		result = ns_config_get(maps, "notify-to-soa", &obj);
+		INSIST(result == ISC_R_SUCCESS);
+		dns_zone_setoption(zone, DNS_ZONEOPT_NOTIFYTOSOA,
+				   cfg_obj_asboolean(obj));
+
 		dns_zone_setisself(zone, ns_client_isself, NULL);
 
 		RETERR(configure_zone_acl(zconfig, vconfig, config,
-					  "allow-transfer", ac, zone,
+					  allow_transfer, ac, zone,
 					  dns_zone_setxfracl,
 					  dns_zone_clearxfracl));
 
@@ -614,13 +710,19 @@ ns_zone_configure(const cfg_obj_t *config, const cfg_obj_t *vconfig,
 		obj = NULL;
 		result = ns_config_get(maps, "check-sibling", &obj);
 		INSIST(result == ISC_R_SUCCESS);
-		dns_zone_setoption(zone, DNS_ZONEOPT_CHECKSIBLING, 
+		dns_zone_setoption(zone, DNS_ZONEOPT_CHECKSIBLING,
 				   cfg_obj_asboolean(obj));
 
 		obj = NULL;
 		result = ns_config_get(maps, "zero-no-soa-ttl", &obj);
 		INSIST(result == ISC_R_SUCCESS);
 		dns_zone_setzeronosoattl(zone, cfg_obj_asboolean(obj));
+
+		obj = NULL;
+		result = ns_config_get(maps, "nsec3-test-zone", &obj);
+		INSIST(result == ISC_R_SUCCESS);
+		dns_zone_setoption(zone, DNS_ZONEOPT_NSEC3TESTZONE,
+				   cfg_obj_asboolean(obj));
 	}
 
 	/*
@@ -630,10 +732,10 @@ ns_zone_configure(const cfg_obj_t *config, const cfg_obj_t *vconfig,
 	if (ztype == dns_zone_master) {
 		dns_acl_t *updateacl;
 		RETERR(configure_zone_acl(zconfig, vconfig, config,
-					  "allow-update", ac, zone,
+					  allow_update, ac, zone,
 					  dns_zone_setupdateacl,
 					  dns_zone_clearupdateacl));
-		
+
 		updateacl = dns_zone_getupdateacl(zone);
 		if (updateacl != NULL  && dns_acl_isinsecure(updateacl))
 			isc_log_write(ns_g_lctx, DNS_LOGCATEGORY_SECURITY,
@@ -641,14 +743,32 @@ ns_zone_configure(const cfg_obj_t *config, const cfg_obj_t *vconfig,
 				      "zone '%s' allows updates by IP "
 				      "address, which is insecure",
 				      zname);
-		
+
 		RETERR(configure_zone_ssutable(zoptions, zone));
 
 		obj = NULL;
 		result = ns_config_get(maps, "sig-validity-interval", &obj);
 		INSIST(result == ISC_R_SUCCESS);
-		dns_zone_setsigvalidityinterval(zone,
-						cfg_obj_asuint32(obj) * 86400);
+		{
+			const cfg_obj_t *validity, *resign;
+
+			validity = cfg_tuple_get(obj, "validity");
+			seconds = cfg_obj_asuint32(validity) * 86400;
+			dns_zone_setsigvalidityinterval(zone, seconds);
+
+			resign = cfg_tuple_get(obj, "re-sign");
+			if (cfg_obj_isvoid(resign)) {
+				seconds /= 4;
+			} else {
+				if (seconds > 7 * 86400)
+					seconds = cfg_obj_asuint32(resign) *
+							86400;
+				else
+					seconds = cfg_obj_asuint32(resign) *
+							3600;
+			}
+			dns_zone_setsigresigninginterval(zone, seconds);
+		}
 
 		obj = NULL;
 		result = ns_config_get(maps, "key-directory", &obj);
@@ -664,6 +784,39 @@ ns_zone_configure(const cfg_obj_t *config, const cfg_obj_t *vconfig,
 		}
 
 		obj = NULL;
+		result = ns_config_get(maps, "sig-signing-signatures", &obj);
+		INSIST(result == ISC_R_SUCCESS);
+		dns_zone_setsignatures(zone, cfg_obj_asuint32(obj));
+
+		obj = NULL;
+		result = ns_config_get(maps, "sig-signing-nodes", &obj);
+		INSIST(result == ISC_R_SUCCESS);
+		dns_zone_setnodes(zone, cfg_obj_asuint32(obj));
+
+		obj = NULL;
+		result = ns_config_get(maps, "sig-signing-type", &obj);
+		INSIST(result == ISC_R_SUCCESS);
+		dns_zone_setprivatetype(zone, cfg_obj_asuint32(obj));
+
+		obj = NULL;
+		result = ns_config_get(maps, "update-check-ksk", &obj);
+		INSIST(result == ISC_R_SUCCESS);
+		dns_zone_setoption(zone, DNS_ZONEOPT_UPDATECHECKKSK,
+				   cfg_obj_asboolean(obj));
+
+	} else if (ztype == dns_zone_slave) {
+		RETERR(configure_zone_acl(zconfig, vconfig, config,
+					  allow_update_forwarding, ac, zone,
+					  dns_zone_setforwardacl,
+					  dns_zone_clearforwardacl));
+	}
+
+
+	/*%
+	 * Primary master functionality.
+	 */
+	if (ztype == dns_zone_master) {
+		obj = NULL;
 		result = ns_config_get(maps, "check-wildcard", &obj);
 		if (result == ISC_R_SUCCESS)
 			check = cfg_obj_asboolean(obj);
@@ -689,7 +842,7 @@ ns_zone_configure(const cfg_obj_t *config, const cfg_obj_t *vconfig,
 		obj = NULL;
 		result = ns_config_get(maps, "check-integrity", &obj);
 		INSIST(obj != NULL);
-		dns_zone_setoption(zone, DNS_ZONEOPT_CHECKINTEGRITY, 
+		dns_zone_setoption(zone, DNS_ZONEOPT_CHECKINTEGRITY,
 				   cfg_obj_asboolean(obj));
 
 		obj = NULL;
@@ -721,59 +874,6 @@ ns_zone_configure(const cfg_obj_t *config, const cfg_obj_t *vconfig,
 			INSIST(0);
 		dns_zone_setoption(zone, DNS_ZONEOPT_WARNSRVCNAME, warn);
 		dns_zone_setoption(zone, DNS_ZONEOPT_IGNORESRVCNAME, ignore);
-
-		obj = NULL;
-		result = ns_config_get(maps, "update-check-ksk", &obj);
-		INSIST(result == ISC_R_SUCCESS);
-		dns_zone_setoption(zone, DNS_ZONEOPT_UPDATECHECKKSK, 
-				   cfg_obj_asboolean(obj));
-	}
-
-	/*
-	 * Configure update-related options.  These apply to
-	 * primary masters only.
-	 */
-	if (ztype == dns_zone_master) {
-		dns_acl_t *updateacl;
-		RETERR(configure_zone_acl(zconfig, vconfig, config,
-					  "allow-update", ac, zone,
-					  dns_zone_setupdateacl,
-					  dns_zone_clearupdateacl));
-		
-		updateacl = dns_zone_getupdateacl(zone);
-		if (updateacl != NULL  && dns_acl_isinsecure(updateacl))
-			isc_log_write(ns_g_lctx, DNS_LOGCATEGORY_SECURITY,
-				      NS_LOGMODULE_SERVER, ISC_LOG_WARNING,
-				      "zone '%s' allows updates by IP "
-				      "address, which is insecure",
-				      zname);
-		
-		RETERR(configure_zone_ssutable(zoptions, zone));
-
-		obj = NULL;
-		result = ns_config_get(maps, "sig-validity-interval", &obj);
-		INSIST(result == ISC_R_SUCCESS);
-		dns_zone_setsigvalidityinterval(zone,
-						cfg_obj_asuint32(obj) * 86400);
-
-		obj = NULL;
-		result = ns_config_get(maps, "key-directory", &obj);
-		if (result == ISC_R_SUCCESS) {
-			filename = cfg_obj_asstring(obj);
-			if (!isc_file_isabsolute(filename)) {
-				cfg_obj_log(obj, ns_g_lctx, ISC_LOG_ERROR,
-					    "key-directory '%s' "
-					    "is not absolute", filename);
-				return (ISC_R_FAILURE);
-			}
-			RETERR(dns_zone_setkeydirectory(zone, filename));
-		}
-
-	} else if (ztype == dns_zone_slave) {
-		RETERR(configure_zone_acl(zconfig, vconfig, config,
-					  "allow-update-forwarding", ac, zone,
-					  dns_zone_setforwardacl,
-					  dns_zone_clearforwardacl));
 	}
 
 	/*
@@ -876,6 +976,10 @@ ns_zone_configure(const cfg_obj_t *config, const cfg_obj_t *vconfig,
 			alt = cfg_obj_asboolean(obj);
 		dns_zone_setoption(zone, DNS_ZONEOPT_USEALTXFRSRC, alt);
 
+		obj = NULL;
+		(void)ns_config_get(maps, "try-tcp-refresh", &obj);
+		dns_zone_setoption(zone, DNS_ZONEOPT_TRYTCPREFRESH,
+				   cfg_obj_asboolean(obj));
 		break;
 
 	default:
diff --git a/contrib/bind9/bin/nsupdate/Makefile.in b/contrib/bind9/bin/nsupdate/Makefile.in
index 713ec30..6d65697 100644
--- a/contrib/bind9/bin/nsupdate/Makefile.in
+++ b/contrib/bind9/bin/nsupdate/Makefile.in
@@ -1,4 +1,4 @@
-# Copyright (C) 2004, 2008  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2006-2008  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2000-2002  Internet Software Consortium.
 #
 # Permission to use, copy, modify, and/or 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.22.18.3 2008/08/29 23:46:16 tbox Exp $
+# $Id: Makefile.in,v 1.29 2008/08/29 23:47:22 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -24,9 +24,9 @@ top_srcdir =	@top_srcdir@
 @BIND9_MAKE_INCLUDES@
 
 CINCLUDES =	${LWRES_INCLUDES} ${DNS_INCLUDES} ${BIND9_INCLUDES} \
-		${ISC_INCLUDES}
+		${ISC_INCLUDES} @DST_GSSAPI_INC@
 
-CDEFINES =
+CDEFINES =	@USE_GSSAPI@
 CWARNINGS =
 
 LWRESLIBS =	../../lib/lwres/liblwres.@A@
diff --git a/contrib/bind9/bin/nsupdate/nsupdate.1 b/contrib/bind9/bin/nsupdate/nsupdate.1
index 454f505..b0688a3 100644
--- a/contrib/bind9/bin/nsupdate/nsupdate.1
+++ b/contrib/bind9/bin/nsupdate/nsupdate.1
@@ -1,4 +1,4 @@
-.\" Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
+.\" Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
 .\" Copyright (C) 2000-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: nsupdate.1,v 1.1.4.2 2008/09/01 02:29:00 tbox Exp $
+.\" $Id: nsupdate.1,v 1.3.48.2 2009/03/10 01:54:11 tbox Exp $
 .\"
 .hy 0
 .ad l
@@ -33,7 +33,7 @@
 nsupdate \- Dynamic DNS update utility
 .SH "SYNOPSIS"
 .HP 9
-\fBnsupdate\fR [\fB\-d\fR] [[\fB\-y\ \fR\fB\fI[hmac:]\fR\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]
+\fBnsupdate\fR [\fB\-d\fR] [\fB\-D\fR] [[\fB\-g\fR] | [\fB\-o\fR] | [\fB\-y\ \fR\fB\fI[hmac:]\fR\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\-R\ \fR\fB\fIrandomdev\fR\fR] [\fB\-v\fR] [filename]
 .SH "DESCRIPTION"
 .PP
 \fBnsupdate\fR
@@ -53,7 +53,14 @@ 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.
 .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
+The
+\fB\-D\fR
+option makes
+\fBnsupdate\fR
+report additional debugging information to
+\fB\-d\fR.
+.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 or GSS\-TSIG as described in RFC3645. 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
@@ -64,7 +71,7 @@ statements would be added to
 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.
+\fI/etc/named.conf\fR. GSS\-TSIG uses Kerberos credentials.
 .PP
 \fBnsupdate\fR
 uses the
@@ -96,7 +103,15 @@ 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
+The
+\fB\-g\fR
+and
+\fB\-o\fR
+specify that GSS\-TSIG is to be used. The
+\fB\-o\fR
+should only be used with old Microsoft Windows 2000 servers.
+.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
@@ -115,6 +130,16 @@ option sets the UDP retry interval. The default is 3 seconds. If zero, the inter
 The
 \fB\-r\fR
 option sets the number of UDP retries. The default is 3. If zero, only one update request will be made.
+.PP
+The
+\fB\-R \fR\fB\fIrandomdev\fR\fR
+option specifies a 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. This option may be specified multiple times.
 .SH "INPUT FORMAT"
 .PP
 \fBnsupdate\fR
@@ -168,6 +193,13 @@ is specified, the default class is
 \fIIN\fR.
 .RE
 .PP
+\fBttl\fR {seconds}
+.RS 4
+Specify the default time to live for records to be added. The value
+\fInone\fR
+will clear the default ttl.
+.RE
+.PP
 \fBkey\fR {name} {secret}
 .RS 4
 Specifies that all updates are to be TSIG\-signed using the
@@ -271,6 +303,11 @@ Sends the current message. This is equivalent to entering a blank line.
 Displays the answer.
 .RE
 .PP
+\fBdebug\fR
+.RS 4
+Turn on debugging.
+.RE
+.PP
 Lines beginning with a semicolon are comments and are ignored.
 .SH "EXAMPLES"
 .PP
@@ -342,7 +379,7 @@ base\-64 encoding of HMAC\-MD5 key created by
 .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.
 .SH "COPYRIGHT"
-Copyright \(co 2004\-2008 Internet Systems Consortium, Inc. ("ISC")
+Copyright \(co 2004\-2009 Internet Systems Consortium, Inc. ("ISC")
 .br
 Copyright \(co 2000\-2003 Internet Software Consortium.
 .br
diff --git a/contrib/bind9/bin/nsupdate/nsupdate.c b/contrib/bind9/bin/nsupdate/nsupdate.c
index 88749e6..6cf4cf4 100644
--- a/contrib/bind9/bin/nsupdate/nsupdate.c
+++ b/contrib/bind9/bin/nsupdate/nsupdate.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: nsupdate.c,v 1.130.18.22 2008/01/17 23:45:58 tbox Exp $ */
+/* $Id: nsupdate.c,v 1.163.48.3 2009/04/30 07:12:49 marka Exp $ */
 
 /*! \file */
 
@@ -35,8 +35,10 @@
 #include <isc/event.h>
 #include <isc/hash.h>
 #include <isc/lex.h>
+#include <isc/log.h>
 #include <isc/mem.h>
 #include <isc/parseint.h>
+#include <isc/random.h>
 #include <isc/region.h>
 #include <isc/sockaddr.h>
 #include <isc/socket.h>
@@ -52,6 +54,7 @@
 #include <dns/dnssec.h>
 #include <dns/events.h>
 #include <dns/fixedname.h>
+#include <dns/log.h>
 #include <dns/masterdump.h>
 #include <dns/message.h>
 #include <dns/name.h>
@@ -64,6 +67,7 @@
 #include <dns/rdatatype.h>
 #include <dns/request.h>
 #include <dns/result.h>
+#include <dns/tkey.h>
 #include <dns/tsig.h>
 
 #include <dst/dst.h>
@@ -71,8 +75,12 @@
 #include <lwres/lwres.h>
 #include <lwres/net.h>
 
+#ifdef GSSAPI
+#include <dst/gssapi.h>
+#endif
 #include <bind9/getaddresses.h>
 
+
 #ifdef HAVE_ADDRINFO
 #ifdef HAVE_GETADDRINFO
 #ifdef HAVE_GAISTRERROR
@@ -107,9 +115,13 @@ static isc_boolean_t have_ipv4 = ISC_FALSE;
 static isc_boolean_t have_ipv6 = ISC_FALSE;
 static isc_boolean_t is_dst_up = ISC_FALSE;
 static isc_boolean_t usevc = ISC_FALSE;
+static isc_boolean_t usegsstsig = ISC_FALSE;
+static isc_boolean_t use_win2k_gsstsig = ISC_FALSE;
+static isc_boolean_t tried_other_gsstsig = ISC_FALSE;
 static isc_taskmgr_t *taskmgr = NULL;
 static isc_task_t *global_task = NULL;
 static isc_event_t *global_event = NULL;
+static isc_log_t *lctx = NULL;
 static isc_mem_t *mctx = NULL;
 static dns_dispatchmgr_t *dispatchmgr = NULL;
 static dns_requestmgr_t *requestmgr = NULL;
@@ -120,6 +132,10 @@ static dns_dispatch_t *dispatchv6 = NULL;
 static dns_message_t *updatemsg = NULL;
 static dns_fixedname_t fuserzone;
 static dns_name_t *userzone = NULL;
+static dns_name_t *zonename = NULL;
+static dns_name_t tmpzonename;
+static dns_name_t restart_master;
+static dns_tsig_keyring_t *gssring = NULL;
 static dns_tsigkey_t *tsigkey = NULL;
 static dst_key_t *sig0key;
 static lwres_context_t *lwctx = NULL;
@@ -129,20 +145,25 @@ static int ns_inuse = 0;
 static int ns_total = 0;
 static isc_sockaddr_t *userserver = NULL;
 static isc_sockaddr_t *localaddr = NULL;
+static isc_sockaddr_t *serveraddr = NULL;
+static isc_sockaddr_t tempaddr;
 static char *keystr = NULL, *keyfile = NULL;
-static isc_entropy_t *entp = NULL;
+static isc_entropy_t *entropy = NULL;
 static isc_boolean_t shuttingdown = ISC_FALSE;
 static FILE *input;
 static isc_boolean_t interactive = ISC_TRUE;
 static isc_boolean_t seenerror = ISC_FALSE;
 static const dns_master_style_t *style;
 static int requests = 0;
+static unsigned int logdebuglevel = 0;
 static unsigned int timeout = 300;
 static unsigned int udp_timeout = 3;
 static unsigned int udp_retries = 3;
 static dns_rdataclass_t defaultclass = dns_rdataclass_in;
 static dns_rdataclass_t zoneclass = dns_rdataclass_none;
 static dns_message_t *answer = NULL;
+static isc_uint32_t default_ttl = 0;
+static isc_boolean_t default_ttl_set = ISC_FALSE;
 
 typedef struct nsu_requestinfo {
 	dns_message_t *msg;
@@ -161,6 +182,27 @@ debug(const char *format, ...) ISC_FORMAT_PRINTF(1, 2);
 static void
 ddebug(const char *format, ...) ISC_FORMAT_PRINTF(1, 2);
 
+#ifdef GSSAPI
+static dns_fixedname_t fkname;
+static isc_sockaddr_t *kserver = NULL;
+static char servicename[DNS_NAME_FORMATSIZE];
+static dns_name_t *keyname;
+typedef struct nsu_gssinfo {
+	dns_message_t *msg;
+	isc_sockaddr_t *addr;
+	gss_ctx_id_t context;
+} nsu_gssinfo_t;
+
+static void
+start_gssrequest(dns_name_t *master);
+static void
+send_gssrequest(isc_sockaddr_t *srcaddr, isc_sockaddr_t *destaddr,
+		dns_message_t *msg, dns_request_t **request,
+		gss_ctx_id_t context);
+static void
+recvgss(isc_task_t *task, isc_event_t *event);
+#endif /* GSSAPI */
+
 static void
 error(const char *format, ...) ISC_FORMAT_PRINTF(1, 2);
 
@@ -169,6 +211,69 @@ error(const char *format, ...) ISC_FORMAT_PRINTF(1, 2);
 #define STATUS_QUIT	(isc_uint16_t)2
 #define STATUS_SYNTAX	(isc_uint16_t)3
 
+typedef struct entropysource entropysource_t;
+
+struct entropysource {
+	isc_entropysource_t *source;
+	isc_mem_t *mctx;
+	ISC_LINK(entropysource_t) link;
+};
+
+static ISC_LIST(entropysource_t) sources;
+
+static void
+setup_entropy(isc_mem_t *mctx, const char *randomfile, isc_entropy_t **ectx)
+{
+	isc_result_t result;
+	isc_entropysource_t *source = NULL;
+	entropysource_t *elt;
+	int usekeyboard = ISC_ENTROPY_KEYBOARDMAYBE;
+
+	REQUIRE(ectx != NULL);
+
+	if (*ectx == NULL) {
+		result = isc_entropy_create(mctx, ectx);
+		if (result != ISC_R_SUCCESS)
+			fatal("could not create entropy object");
+		ISC_LIST_INIT(sources);
+	}
+
+	if (randomfile != NULL && strcmp(randomfile, "keyboard") == 0) {
+		usekeyboard = ISC_ENTROPY_KEYBOARDYES;
+		randomfile = NULL;
+	}
+
+	result = isc_entropy_usebestsource(*ectx, &source, randomfile,
+					   usekeyboard);
+
+	if (result != ISC_R_SUCCESS)
+		fatal("could not initialize entropy source: %s",
+		      isc_result_totext(result));
+
+	if (source != NULL) {
+		elt = isc_mem_get(mctx, sizeof(*elt));
+		if (elt == NULL)
+			fatal("out of memory");
+		elt->source = source;
+		elt->mctx = mctx;
+		ISC_LINK_INIT(elt, link);
+		ISC_LIST_APPEND(sources, elt, link);
+	}
+}
+
+static void
+cleanup_entropy(isc_entropy_t **ectx) {
+	entropysource_t *source;
+	while (!ISC_LIST_EMPTY(sources)) {
+		source = ISC_LIST_HEAD(sources);
+		ISC_LIST_UNLINK(sources, source, link);
+		isc_entropy_destroysource(&source->source);
+		isc_mem_put(source->mctx, source, sizeof(*source));
+	}
+	isc_entropy_detach(ectx);
+}
+
+
 static dns_rdataclass_t
 getzoneclass(void) {
 	if (zoneclass == dns_rdataclass_none)
@@ -295,6 +400,13 @@ reset_system(void) {
 		check_result(result, "dns_message_create");
 	}
 	updatemsg->opcode = dns_opcode_update;
+	if (usegsstsig) {
+		if (tsigkey != NULL)
+			dns_tsigkey_detach(&tsigkey);
+		if (gssring != NULL)
+			dns_tsigkeyring_destroy(&gssring);
+		tried_other_gsstsig = ISC_FALSE;
+	}
 }
 
 static isc_uint16_t
@@ -518,10 +630,7 @@ doshutdown(void) {
 		is_dst_up = ISC_FALSE;
 	}
 
-	if (entp != NULL) {
-		ddebug("Detach from entropy");
-		isc_entropy_detach(&entp);
-	}
+	cleanup_entropy(&entropy);
 
 	lwres_conf_clear(lwctx);
 	lwres_context_destroy(&lwctx);
@@ -572,6 +681,7 @@ setup_system(void) {
 	lwres_result_t lwresult;
 	unsigned int attrs, attrmask;
 	int i;
+	isc_logconfig_t *logconfig = NULL;
 
 	ddebug("setup_system()");
 
@@ -588,8 +698,17 @@ setup_system(void) {
 	if (!have_ipv4 && !have_ipv6)
 		fatal("could not find either IPv4 or IPv6");
 
-	result = isc_mem_create(0, 0, &mctx);
-	check_result(result, "isc_mem_create");
+	result = isc_log_create(mctx, &lctx, &logconfig);
+	check_result(result, "isc_log_create");
+
+	isc_log_setcontext(lctx);
+	dns_log_init(lctx);
+	dns_log_setcontext(lctx);
+
+	result = isc_log_usechannel(logconfig, "default_debug", NULL, NULL);
+	check_result(result, "isc_log_usechannel");
+
+	isc_log_setdebuglevel(lctx, logdebuglevel);
 
 	lwresult = lwres_context_create(&lwctx, mctx, mem_alloc, mem_free, 1);
 	if (lwresult != LWRES_R_SUCCESS)
@@ -626,14 +745,13 @@ setup_system(void) {
 		}
 	}
 
-	result = isc_entropy_create(mctx, &entp);
-	check_result(result, "isc_entropy_create");
+	setup_entropy(mctx, NULL, &entropy);
 
-	result = isc_hash_create(mctx, entp, DNS_NAME_MAXWIRE);
+	result = isc_hash_create(mctx, entropy, DNS_NAME_MAXWIRE);
 	check_result(result, "isc_hash_create");
 	isc_hash_init();
 
-	result = dns_dispatchmgr_create(mctx, entp, &dispatchmgr);
+	result = dns_dispatchmgr_create(mctx, entropy, &dispatchmgr);
 	check_result(result, "dns_dispatchmgr_create");
 
 	result = isc_socketmgr_create(mctx, &socketmgr);
@@ -651,7 +769,7 @@ setup_system(void) {
 	result = isc_task_onshutdown(global_task, shutdown_program, NULL);
 	check_result(result, "isc_task_onshutdown");
 
-	result = dst_lib_init(mctx, entp, 0);
+	result = dst_lib_init(mctx, entropy, 0);
 	check_result(result, "dst_lib_init");
 	is_dst_up = ISC_TRUE;
 
@@ -707,14 +825,47 @@ get_address(char *host, in_port_t port, isc_sockaddr_t *sockaddr) {
 	INSIST(count == 1);
 }
 
+#define PARSE_ARGS_FMT "dDMl:y:govk:rR::t:u:"
+
+static void
+pre_parse_args(int argc, char **argv) {
+	int ch;
+
+	while ((ch = isc_commandline_parse(argc, argv, PARSE_ARGS_FMT)) != -1) {
+		switch (ch) {
+		case 'M': /* was -dm */
+			debugging = ISC_TRUE;
+			ddebugging = ISC_TRUE;
+			memdebugging = ISC_TRUE;
+			isc_mem_debugging = ISC_MEM_DEBUGTRACE |
+					    ISC_MEM_DEBUGRECORD;
+			break;
+
+		case '?':
+			if (isc_commandline_option != '?')
+				fprintf(stderr, "%s: invalid argument -%c\n",
+					argv[0], isc_commandline_option);
+			fprintf(stderr, "usage: nsupdate [-d] "
+				"[-g | -o | -y keyname:secret | -k keyfile] "
+				"[-v] [filename]\n");
+			exit(1);
+
+		default:
+			break;
+		}
+	}
+	isc_commandline_reset = ISC_TRUE;
+	isc_commandline_index = 1;
+}
+
 static void
-parse_args(int argc, char **argv) {
+parse_args(int argc, char **argv, isc_mem_t *mctx, isc_entropy_t **ectx) {
 	int ch;
+	isc_uint32_t i;
 	isc_result_t result;
 
 	debug("parse_args");
-	while ((ch = isc_commandline_parse(argc, argv, "dDMy:vk:r:t:u:")) != -1)
-	{
+	while ((ch = isc_commandline_parse(argc, argv, PARSE_ARGS_FMT)) != -1) {
 		switch (ch) {
 		case 'd':
 			debugging = ISC_TRUE;
@@ -723,12 +874,17 @@ parse_args(int argc, char **argv) {
 			debugging = ISC_TRUE;
 			ddebugging = ISC_TRUE;
 			break;
-		case 'M': /* was -dm */
-			debugging = ISC_TRUE;
-			ddebugging = ISC_TRUE;
-			memdebugging = ISC_TRUE;
-			isc_mem_debugging = ISC_MEM_DEBUGTRACE |
-					    ISC_MEM_DEBUGRECORD;
+		case 'M':
+			break;
+		case 'l':
+			result = isc_parse_uint32(&i, isc_commandline_argument,
+						  10);
+			if (result != ISC_R_SUCCESS) {
+				fprintf(stderr, "bad library debug value "
+					"'%s'\n", isc_commandline_argument);
+				exit(1);
+			}
+			logdebuglevel = i;
 			break;
 		case 'y':
 			keystr = isc_commandline_argument;
@@ -739,6 +895,14 @@ parse_args(int argc, char **argv) {
 		case 'k':
 			keyfile = isc_commandline_argument;
 			break;
+		case 'g':
+			usegsstsig = ISC_TRUE;
+			use_win2k_gsstsig = ISC_FALSE;
+			break;
+		case 'o':
+			usegsstsig = ISC_TRUE;
+			use_win2k_gsstsig = ISC_TRUE;
+			break;
 		case 't':
 			result = isc_parse_uint32(&timeout,
 						  isc_commandline_argument, 10);
@@ -767,12 +931,14 @@ parse_args(int argc, char **argv) {
 				exit(1);
 			}
 			break;
+
+		case 'R':
+			setup_entropy(mctx, isc_commandline_argument, ectx);
+			break;
+
 		default:
-			fprintf(stderr, "%s: invalid argument -%c\n",
-				argv[0], ch);
-			fprintf(stderr, "usage: nsupdate [-d] "
-				"[-y keyname:secret | -k keyfile] [-v] "
-				"[filename]\n");
+			fprintf(stderr, "%s: unhandled option: %c\n",
+				argv[0], isc_commandline_option);
 			exit(1);
 		}
 	}
@@ -782,6 +948,21 @@ parse_args(int argc, char **argv) {
 		exit(1);
 	}
 
+#ifdef GSSAPI
+	if (usegsstsig && (keyfile != NULL || keystr != NULL)) {
+		fprintf(stderr, "%s: cannot specify -g with -k or -y\n",
+			argv[0]);
+		exit(1);
+	}
+#else
+	if (usegsstsig) {
+		fprintf(stderr, "%s: cannot specify -g  or -o, " \
+			"program not linked with GSS API Library\n",
+			argv[0]);
+		exit(1);
+	}
+#endif
+
 	if (argv[isc_commandline_index] != NULL) {
 		if (strcmp(argv[isc_commandline_index], "-") == 0) {
 			input = stdin;
@@ -853,7 +1034,7 @@ parse_rdata(char **cmdlinep, dns_rdataclass_t rdataclass,
 		check_result(result, "isc_lex_openbuffer");
 		result = isc_buffer_allocate(mctx, &buf, MAXWIRE);
 		check_result(result, "isc_buffer_allocate");
-		result = dns_rdata_fromtext(rdata, rdataclass, rdatatype, lex,
+		result = dns_rdata_fromtext(NULL, rdataclass, rdatatype, lex,
 					    dns_rootname, 0, mctx, buf,
 					    &callbacks);
 		isc_lex_destroy(&lex);
@@ -947,8 +1128,7 @@ make_prereq(char *cmdline, isc_boolean_t ispositive, isc_boolean_t isrrset) {
 	result = dns_message_gettemprdata(updatemsg, &rdata);
 	check_result(result, "dns_message_gettemprdata");
 
-	rdata->data = NULL;
-	rdata->length = 0;
+	dns_rdata_init(rdata);
 
 	if (isrrset && ispositive) {
 		retval = parse_rdata(&cmdline, rdataclass, rdatatype,
@@ -1209,6 +1389,39 @@ evaluate_zone(char *cmdline) {
 }
 
 static isc_uint16_t
+evaluate_ttl(char *cmdline) {
+	char *word;
+	isc_result_t result;
+	isc_uint32_t ttl;
+
+	word = nsu_strsep(&cmdline, " \t\r\n");
+	if (*word == 0) {
+		fprintf(stderr, "could not ttl\n");
+		return (STATUS_SYNTAX);
+	}
+
+	if (!strcasecmp(word, "none")) {
+		default_ttl = 0;
+		default_ttl_set = ISC_FALSE;
+		return (STATUS_MORE);
+	}
+
+	result = isc_parse_uint32(&ttl, word, 10);
+	if (result != ISC_R_SUCCESS)
+		return (STATUS_SYNTAX);
+
+	if (ttl > TTL_MAX) {
+		fprintf(stderr, "ttl '%s' is out of range (0 to %u)\n",
+			word, TTL_MAX);
+		return (STATUS_SYNTAX);
+	}
+	default_ttl = ttl;
+	default_ttl_set = ISC_TRUE;
+
+	return (STATUS_MORE);
+}
+
+static isc_uint16_t
 evaluate_class(char *cmdline) {
 	char *word;
 	isc_textregion_t r;
@@ -1267,10 +1480,7 @@ update_addordelete(char *cmdline, isc_boolean_t isdelete) {
 	result = dns_message_gettemprdata(updatemsg, &rdata);
 	check_result(result, "dns_message_gettemprdata");
 
-	rdata->rdclass = 0;
-	rdata->type = 0;
-	rdata->data = NULL;
-	rdata->length = 0;
+	dns_rdata_init(rdata);
 
 	/*
 	 * If this is an add, read the TTL and verify that it's in range.
@@ -1295,6 +1505,9 @@ update_addordelete(char *cmdline, isc_boolean_t isdelete) {
 		if (isdelete) {
 			ttl = 0;
 			goto parseclass;
+		} else if (default_ttl_set) {
+			ttl = default_ttl;
+			goto parseclass;
 		} else {
 			fprintf(stderr, "ttl '%s': %s\n", word,
 				isc_result_totext(result));
@@ -1328,8 +1541,9 @@ update_addordelete(char *cmdline, isc_boolean_t isdelete) {
 	}
 	region.base = word;
 	region.length = strlen(word);
+	rdataclass = dns_rdataclass_any;
 	result = dns_rdataclass_fromtext(&rdataclass, &region);
-	if (result == ISC_R_SUCCESS) {
+	if (result == ISC_R_SUCCESS && rdataclass != dns_rdataclass_any) {
 		if (!setzoneclass(rdataclass)) {
 			fprintf(stderr, "class mismatch: %s\n", word);
 			goto failure;
@@ -1469,7 +1683,7 @@ setzone(dns_name_t *zonename) {
 }
 
 static void
-show_message(dns_message_t *msg) {
+show_message(FILE *stream, dns_message_t *msg, const char *description) {
 	isc_result_t result;
 	isc_buffer_t *buf = NULL;
 	int bufsz;
@@ -1497,9 +1711,8 @@ show_message(dns_message_t *msg) {
 		isc_buffer_free(&buf);
 		return;
 	}
-	printf("Outgoing update query:\n%.*s",
-	       (int)isc_buffer_usedlength(buf),
-	       (char*)isc_buffer_base(buf));
+	fprintf(stream, "%s\n%.*s", description,
+	       (int)isc_buffer_usedlength(buf), (char*)isc_buffer_base(buf));
 	isc_buffer_free(&buf);
 }
 
@@ -1544,17 +1757,68 @@ get_next_command(void) {
 		return (evaluate_class(cmdline));
 	if (strcasecmp(word, "send") == 0)
 		return (STATUS_SEND);
+	if (strcasecmp(word, "debug") == 0) {
+		if (debugging)
+			ddebugging = ISC_TRUE;
+		else
+			debugging = ISC_TRUE;
+		return (STATUS_MORE);
+	}
+	if (strcasecmp(word, "ttl") == 0)
+		return (evaluate_ttl(cmdline));
 	if (strcasecmp(word, "show") == 0) {
-		show_message(updatemsg);
+		show_message(stdout, updatemsg, "Outgoing update query:");
 		return (STATUS_MORE);
 	}
 	if (strcasecmp(word, "answer") == 0) {
 		if (answer != NULL)
-			show_message(answer);
+			show_message(stdout, answer, "Answer:");
 		return (STATUS_MORE);
 	}
-	if (strcasecmp(word, "key") == 0)
+	if (strcasecmp(word, "key") == 0) {
+		usegsstsig = ISC_FALSE;
 		return (evaluate_key(cmdline));
+	}
+	if (strcasecmp(word, "gsstsig") == 0) {
+#ifdef GSSAPI
+		usegsstsig = ISC_TRUE;
+		use_win2k_gsstsig = ISC_FALSE;
+#else
+		fprintf(stderr, "gsstsig not supported\n");
+#endif
+		return (STATUS_MORE);
+	}
+	if (strcasecmp(word, "oldgsstsig") == 0) {
+#ifdef GSSAPI
+		usegsstsig = ISC_TRUE;
+		use_win2k_gsstsig = ISC_TRUE;
+#else
+		fprintf(stderr, "gsstsig not supported\n");
+#endif
+		return (STATUS_MORE);
+	}
+	if (strcasecmp(word, "help") == 0) {
+		fprintf(stdout,
+"local address [port]      (set local resolver)\n"
+"server address [port]     (set master server for zone)\n"
+"send                      (send the update request)\n"
+"show                      (show the update request)\n"
+"answer	                   (show the answer to the last request)\n"
+"quit                      (quit, any pending update is not sent\n"
+"help			   (display this message_\n"
+"key [hmac:]keyname secret (use TSIG to sign the request)\n"
+"gsstsig                   (use GSS_TSIG to sign the request)\n"
+"oldgsstsig                (use Microsoft's GSS_TSIG to sign the request)\n"
+"zone name                 (set the zone to be updated)\n"
+"class CLASS               (set the zone's DNS class, e.g. IN (default), CH)\n"
+"prereq nxdomain name      (does this name not exist)\n"
+"prereq yxdomain name      (does this name exist)\n"
+"prereq nxrrset ....       (does this RRset exist)\n"
+"prereq yxrrset ....       (does this RRset not exist)\n"
+"update add ....           (add the given record to the zone)\n"
+"update delete ....        (remove the given record(s) from the zone)\n");
+		return (STATUS_MORE);
+	}
 	fprintf(stderr, "incorrect section name: %s\n", word);
 	return (STATUS_SYNTAX);
 }
@@ -1641,12 +1905,23 @@ update_completed(isc_task_t *task, isc_event_t *event) {
 					 DNS_MESSAGEPARSE_PRESERVEORDER);
 	switch (result) {
 	case ISC_R_SUCCESS:
+		if (answer->verify_attempted)
+			ddebug("tsig verification successful");
 		break;
 	case DNS_R_CLOCKSKEW:
 	case DNS_R_EXPECTEDTSIG:
 	case DNS_R_TSIGERRORSET:
 	case DNS_R_TSIGVERIFYFAILURE:
 	case DNS_R_UNEXPECTEDTSIG:
+	case ISC_R_FAILURE:
+#if 0
+		if (usegsstsig && answer->rcode == dns_rcode_noerror) {
+			/*
+			 * For MS DNS that violates RFC 2845, section 4.2
+			 */
+			break;
+		}
+#endif
 		fprintf(stderr, "; TSIG error with server: %s\n",
 			isc_result_totext(result));
 		seenerror = ISC_TRUE;
@@ -1672,32 +1947,15 @@ update_completed(isc_task_t *task, isc_event_t *event) {
 				(int)isc_buffer_usedlength(&b), buf);
 		}
 	}
-	if (debugging) {
-		isc_buffer_t *buf = NULL;
-		int bufsz;
-
-		bufsz = INITTEXT;
-		do {
-			if (bufsz > MAXTEXT) {
-				fprintf(stderr, "could not allocate large "
-					"enough buffer to display message\n");
-				exit(1);
-			}
-			if (buf != NULL)
-				isc_buffer_free(&buf);
-			result = isc_buffer_allocate(mctx, &buf, bufsz);
-			check_result(result, "isc_buffer_allocate");
-			result = dns_message_totext(answer, style, 0, buf);
-			bufsz *= 2;
-		} while (result == ISC_R_NOSPACE);
-		check_result(result, "dns_message_totext");
-		fprintf(stderr, "\nReply from update query:\n%.*s\n",
-			(int)isc_buffer_usedlength(buf),
-			(char*)isc_buffer_base(buf));
-		isc_buffer_free(&buf);
-	}
+	if (debugging)
+		show_message(stderr, answer, "\nReply from update query:");
+
  done:
 	dns_request_destroy(&request);
+	if (usegsstsig) {
+		dns_name_free(&tmpzonename, mctx);
+		dns_name_free(&restart_master, mctx);
+	}
 	isc_event_free(&event);
 	done_update();
 }
@@ -1726,6 +1984,7 @@ send_update(dns_name_t *zonename, isc_sockaddr_t *master,
 		isc_sockaddr_format(master, addrbuf, sizeof(addrbuf));
 		fprintf(stderr, "Sending update to %s\n", addrbuf);
 	}
+
 	result = dns_request_createvia3(requestmgr, updatemsg, srcaddr,
 					master, options, tsigkey, timeout,
 					udp_timeout, udp_retries, global_task,
@@ -1733,7 +1992,7 @@ send_update(dns_name_t *zonename, isc_sockaddr_t *master,
 	check_result(result, "dns_request_createvia3");
 
 	if (debugging)
-		show_message(updatemsg);
+		show_message(stdout, updatemsg, "Outgoing update query:");
 
 	requests++;
 }
@@ -1751,8 +2010,6 @@ recvsoa(isc_task_t *task, isc_event_t *event) {
 	dns_rdata_t soarr = DNS_RDATA_INIT;
 	int pass = 0;
 	dns_name_t master;
-	isc_sockaddr_t *serveraddr, tempaddr;
-	dns_name_t *zonename;
 	nsu_requestinfo_t *reqinfo;
 	dns_message_t *soaquery = NULL;
 	isc_sockaddr_t *addr;
@@ -1788,7 +2045,7 @@ recvsoa(isc_task_t *task, isc_event_t *event) {
 
 		isc_sockaddr_format(addr, addrbuf, sizeof(addrbuf));
 		fprintf(stderr, "; Communication with %s failed: %s\n",
-		       addrbuf, isc_result_totext(eresult));
+			addrbuf, isc_result_totext(eresult));
 		if (userserver != NULL)
 			fatal("could not talk to specified name server");
 		else if (++ns_inuse >= lwconf->nsnext)
@@ -1837,28 +2094,8 @@ recvsoa(isc_task_t *task, isc_event_t *event) {
 	}
 	check_result(result, "dns_request_getresponse");
 	section = DNS_SECTION_ANSWER;
-	if (debugging) {
-		isc_buffer_t *buf = NULL;
-		int bufsz;
-		bufsz = INITTEXT;
-		do {
-			if (buf != NULL)
-				isc_buffer_free(&buf);
-			if (bufsz > MAXTEXT) {
-				fprintf(stderr, "could not allocate enough "
-					 "space for debugging message\n");
-				exit(1);
-			}
-			result = isc_buffer_allocate(mctx, &buf, bufsz);
-			check_result(result, "isc_buffer_allocate");
-			result = dns_message_totext(rcvmsg, style, 0, buf);
-		} while (result == ISC_R_NOSPACE);
-		check_result(result, "dns_message_totext");
-		fprintf(stderr, "Reply from SOA query:\n%.*s\n",
-			(int)isc_buffer_usedlength(buf),
-			(char*)isc_buffer_base(buf));
-		isc_buffer_free(&buf);
-	}
+	if (debugging)
+		show_message(stderr, rcvmsg, "Reply from SOA query:");
 
 	if (rcvmsg->rcode != dns_rcode_noerror &&
 	    rcvmsg->rcode != dns_rcode_nxdomain)
@@ -1901,12 +2138,9 @@ recvsoa(isc_task_t *task, isc_event_t *event) {
 		if (section == DNS_SECTION_ANSWER) {
 			dns_rdataset_t *tset = NULL;
 			if (dns_message_findtype(name, dns_rdatatype_cname, 0,
-						 &tset) == ISC_R_SUCCESS
-			    ||
+						 &tset) == ISC_R_SUCCESS ||
 			    dns_message_findtype(name, dns_rdatatype_dname, 0,
-						 &tset) == ISC_R_SUCCESS
-			    )
-			{
+						 &tset) == ISC_R_SUCCESS ) {
 				seencname = ISC_TRUE;
 				break;
 			}
@@ -1966,8 +2200,21 @@ recvsoa(isc_task_t *task, isc_event_t *event) {
 	}
 	dns_rdata_freestruct(&soa);
 
+#ifdef GSSAPI
+	if (usegsstsig) {
+		dns_name_init(&tmpzonename, NULL);
+		dns_name_dup(zonename, mctx, &tmpzonename);
+		dns_name_init(&restart_master, NULL);
+		dns_name_dup(&master, mctx, &restart_master);
+		start_gssrequest(&master);
+	} else {
+		send_update(zonename, serveraddr, localaddr);
+		setzoneclass(dns_rdataclass_none);
+	}
+#else
 	send_update(zonename, serveraddr, localaddr);
 	setzoneclass(dns_rdataclass_none);
+#endif
 
 	dns_message_destroy(&soaquery);
 	dns_request_destroy(&request);
@@ -1994,8 +2241,7 @@ recvsoa(isc_task_t *task, isc_event_t *event) {
 	if (userserver != NULL)
 		sendrequest(localaddr, userserver, soaquery, &request);
 	else
-		sendrequest(localaddr, &servers[ns_inuse], soaquery,
-			    &request);
+		sendrequest(localaddr, &servers[ns_inuse], soaquery, &request);
 	goto out;
 }
 
@@ -2019,6 +2265,286 @@ sendrequest(isc_sockaddr_t *srcaddr, isc_sockaddr_t *destaddr,
 	requests++;
 }
 
+#ifdef GSSAPI
+static void
+start_gssrequest(dns_name_t *master)
+{
+	gss_ctx_id_t context;
+	isc_buffer_t buf;
+	isc_result_t result;
+	isc_uint32_t val = 0;
+	dns_message_t *rmsg;
+	dns_request_t *request = NULL;
+	dns_name_t *servname;
+	dns_fixedname_t fname;
+	char namestr[DNS_NAME_FORMATSIZE];
+	char keystr[DNS_NAME_FORMATSIZE];
+
+	debug("start_gssrequest");
+	usevc = ISC_TRUE;
+
+	if (gssring != NULL)
+		dns_tsigkeyring_destroy(&gssring);
+	gssring = NULL;
+	result = dns_tsigkeyring_create(mctx, &gssring);
+
+	if (result != ISC_R_SUCCESS)
+		fatal("dns_tsigkeyring_create failed: %s",
+		      isc_result_totext(result));
+
+	dns_name_format(master, namestr, sizeof(namestr));
+	if (kserver == NULL) {
+		kserver = isc_mem_get(mctx, sizeof(isc_sockaddr_t));
+		if (kserver == NULL)
+			fatal("out of memory");
+	}
+	if (userserver == NULL)
+		get_address(namestr, DNSDEFAULTPORT, kserver);
+	else
+		(void)memcpy(kserver, userserver, sizeof(isc_sockaddr_t));
+
+	dns_fixedname_init(&fname);
+	servname = dns_fixedname_name(&fname);
+
+	result = isc_string_printf(servicename, sizeof(servicename),
+				   "DNS/%s", namestr);
+	if (result != ISC_R_SUCCESS)
+		fatal("isc_string_printf(servicename) failed: %s",
+		      isc_result_totext(result));
+	isc_buffer_init(&buf, servicename, strlen(servicename));
+	isc_buffer_add(&buf, strlen(servicename));
+	result = dns_name_fromtext(servname, &buf, dns_rootname,
+				   ISC_FALSE, NULL);
+	if (result != ISC_R_SUCCESS)
+		fatal("dns_name_fromtext(servname) failed: %s",
+		      isc_result_totext(result));
+
+	dns_fixedname_init(&fkname);
+	keyname = dns_fixedname_name(&fkname);
+
+	isc_random_get(&val);
+	result = isc_string_printf(keystr, sizeof(keystr), "%u.sig-%s",
+				   val, namestr);
+	if (result != ISC_R_SUCCESS)
+		fatal("isc_string_printf(keystr) failed: %s",
+		      isc_result_totext(result));
+	isc_buffer_init(&buf, keystr, strlen(keystr));
+	isc_buffer_add(&buf, strlen(keystr));
+
+	result = dns_name_fromtext(keyname, &buf, dns_rootname,
+				   ISC_FALSE, NULL);
+	if (result != ISC_R_SUCCESS)
+		fatal("dns_name_fromtext(keyname) failed: %s",
+		      isc_result_totext(result));
+
+	/* Windows doesn't recognize name compression in the key name. */
+	keyname->attributes |= DNS_NAMEATTR_NOCOMPRESS;
+
+	rmsg = NULL;
+	result = dns_message_create(mctx, DNS_MESSAGE_INTENTRENDER, &rmsg);
+	if (result != ISC_R_SUCCESS)
+		fatal("dns_message_create failed: %s",
+		      isc_result_totext(result));
+
+	/* Build first request. */
+
+	context = GSS_C_NO_CONTEXT;
+	result = dns_tkey_buildgssquery(rmsg, keyname, servname, NULL, 0,
+					&context, use_win2k_gsstsig);
+	if (result == ISC_R_FAILURE)
+		fatal("Check your Kerberos ticket, it may have expired.");
+	if (result != ISC_R_SUCCESS)
+		fatal("dns_tkey_buildgssquery failed: %s",
+		      isc_result_totext(result));
+
+	send_gssrequest(localaddr, kserver, rmsg, &request, context);
+}
+
+static void
+send_gssrequest(isc_sockaddr_t *srcaddr, isc_sockaddr_t *destaddr,
+		dns_message_t *msg, dns_request_t **request,
+		gss_ctx_id_t context)
+{
+	isc_result_t result;
+	nsu_gssinfo_t *reqinfo;
+	unsigned int options = 0;
+
+	debug("send_gssrequest");
+	reqinfo = isc_mem_get(mctx, sizeof(nsu_gssinfo_t));
+	if (reqinfo == NULL)
+		fatal("out of memory");
+	reqinfo->msg = msg;
+	reqinfo->addr = destaddr;
+	reqinfo->context = context;
+
+	options |= DNS_REQUESTOPT_TCP;
+	result = dns_request_createvia3(requestmgr, msg, srcaddr, destaddr,
+					options, tsigkey, FIND_TIMEOUT * 20,
+					FIND_TIMEOUT, 3, global_task, recvgss,
+					reqinfo, request);
+	check_result(result, "dns_request_createvia3");
+	if (debugging)
+		show_message(stdout, msg, "Outgoing update query:");
+	requests++;
+}
+
+static void
+recvgss(isc_task_t *task, isc_event_t *event) {
+	dns_requestevent_t *reqev = NULL;
+	dns_request_t *request = NULL;
+	isc_result_t result, eresult;
+	dns_message_t *rcvmsg = NULL;
+	nsu_gssinfo_t *reqinfo;
+	dns_message_t *tsigquery = NULL;
+	isc_sockaddr_t *addr;
+	gss_ctx_id_t context;
+	isc_buffer_t buf;
+	dns_name_t *servname;
+	dns_fixedname_t fname;
+
+	UNUSED(task);
+
+	ddebug("recvgss()");
+
+	requests--;
+
+	REQUIRE(event->ev_type == DNS_EVENT_REQUESTDONE);
+	reqev = (dns_requestevent_t *)event;
+	request = reqev->request;
+	eresult = reqev->result;
+	reqinfo = reqev->ev_arg;
+	tsigquery = reqinfo->msg;
+	context = reqinfo->context;
+	addr = reqinfo->addr;
+
+	if (shuttingdown) {
+		dns_request_destroy(&request);
+		dns_message_destroy(&tsigquery);
+		isc_mem_put(mctx, reqinfo, sizeof(nsu_gssinfo_t));
+		isc_event_free(&event);
+		maybeshutdown();
+		return;
+	}
+
+	if (eresult != ISC_R_SUCCESS) {
+		char addrbuf[ISC_SOCKADDR_FORMATSIZE];
+
+		isc_sockaddr_format(addr, addrbuf, sizeof(addrbuf));
+		fprintf(stderr, "; Communication with %s failed: %s\n",
+			addrbuf, isc_result_totext(eresult));
+		if (userserver != NULL)
+			fatal("could not talk to specified name server");
+		else if (++ns_inuse >= lwconf->nsnext)
+			fatal("could not talk to any default name server");
+		ddebug("Destroying request [%p]", request);
+		dns_request_destroy(&request);
+		dns_message_renderreset(tsigquery);
+		sendrequest(localaddr, &servers[ns_inuse], tsigquery,
+			    &request);
+		isc_mem_put(mctx, reqinfo, sizeof(nsu_gssinfo_t));
+		isc_event_free(&event);
+		return;
+	}
+	isc_mem_put(mctx, reqinfo, sizeof(nsu_gssinfo_t));
+
+	isc_event_free(&event);
+	reqev = NULL;
+
+	ddebug("recvgss creating rcvmsg");
+	result = dns_message_create(mctx, DNS_MESSAGE_INTENTPARSE, &rcvmsg);
+	check_result(result, "dns_message_create");
+
+	result = dns_request_getresponse(request, rcvmsg,
+					 DNS_MESSAGEPARSE_PRESERVEORDER);
+	check_result(result, "dns_request_getresponse");
+
+	if (debugging)
+		show_message(stderr, rcvmsg,
+			     "recvmsg reply from GSS-TSIG query");
+
+	if (rcvmsg->rcode == dns_rcode_formerr && !tried_other_gsstsig) {
+		ddebug("recvgss trying %s GSS-TSIG",
+		       use_win2k_gsstsig ? "Standard" : "Win2k");
+		if (use_win2k_gsstsig)
+			use_win2k_gsstsig = ISC_FALSE;
+		else
+			use_win2k_gsstsig = ISC_TRUE;
+		tried_other_gsstsig = ISC_TRUE;
+		start_gssrequest(&restart_master);
+		goto done;
+	}
+
+	if (rcvmsg->rcode != dns_rcode_noerror &&
+	    rcvmsg->rcode != dns_rcode_nxdomain)
+		fatal("response to GSS-TSIG query was unsuccessful");
+
+
+	dns_fixedname_init(&fname);
+	servname = dns_fixedname_name(&fname);
+	isc_buffer_init(&buf, servicename, strlen(servicename));
+	isc_buffer_add(&buf, strlen(servicename));
+	result = dns_name_fromtext(servname, &buf, dns_rootname,
+				   ISC_FALSE, NULL);
+	check_result(result, "dns_name_fromtext");
+
+	tsigkey = NULL;
+	result = dns_tkey_gssnegotiate(tsigquery, rcvmsg, servname,
+				       &context, &tsigkey, gssring,
+				       use_win2k_gsstsig);
+	switch (result) {
+
+	case DNS_R_CONTINUE:
+		send_gssrequest(localaddr, kserver, tsigquery, &request,
+				context);
+		break;
+
+	case ISC_R_SUCCESS:
+		/*
+		 * XXXSRA Waaay too much fun here.  There's no good
+		 * reason why we need a TSIG here (the people who put
+		 * it into the spec admitted at the time that it was
+		 * not a security issue), and Windows clients don't
+		 * seem to work if named complies with the spec and
+		 * includes the gratuitous TSIG.  So we're in the
+		 * bizarre situation of having to choose between
+		 * complying with a useless requirement in the spec
+		 * and interoperating.  This is nuts.  If we can
+		 * confirm this behavior, we should ask the WG to
+		 * consider removing the requirement for the
+		 * gratuitous TSIG here.  For the moment, we ignore
+		 * the TSIG -- this too is a spec violation, but it's
+		 * the least insane thing to do.
+		 */
+#if 0
+		/*
+		 * Verify the signature.
+		 */
+		rcvmsg->state = DNS_SECTION_ANY;
+		dns_message_setquerytsig(rcvmsg, NULL);
+		result = dns_message_settsigkey(rcvmsg, tsigkey);
+		check_result(result, "dns_message_settsigkey");
+		result = dns_message_checksig(rcvmsg, NULL);
+		ddebug("tsig verification: %s", dns_result_totext(result));
+		check_result(result, "dns_message_checksig");
+#endif /* 0 */
+
+		send_update(&tmpzonename, serveraddr, localaddr);
+		setzoneclass(dns_rdataclass_none);
+		break;
+
+	default:
+		fatal("dns_tkey_negotiategss: %s", isc_result_totext(result));
+	}
+
+ done:
+	dns_request_destroy(&request);
+	dns_message_destroy(&tsigquery);
+
+	dns_message_destroy(&rcvmsg);
+	ddebug("Out of recvgss");
+}
+#endif
+
 static void
 start_update(void) {
 	isc_result_t result;
@@ -2034,7 +2560,7 @@ start_update(void) {
 	if (answer != NULL)
 		dns_message_destroy(&answer);
 
-	if (userzone != NULL && userserver != NULL) {
+	if (userzone != NULL && userserver != NULL && ! usegsstsig) {
 		send_update(userzone, userserver, localaddr);
 		setzoneclass(dns_rdataclass_none);
 		return;
@@ -2096,6 +2622,22 @@ cleanup(void) {
 
 	if (answer != NULL)
 		dns_message_destroy(&answer);
+
+#ifdef GSSAPI
+	if (tsigkey != NULL) {
+		ddebug("detach tsigkey x%p", tsigkey);
+		dns_tsigkey_detach(&tsigkey);
+	}
+	if (gssring != NULL) {
+		ddebug("Destroying GSS-TSIG keyring");
+		dns_tsigkeyring_destroy(&gssring);
+	}
+	if (kserver != NULL) {
+		isc_mem_put(mctx, kserver, sizeof(isc_sockaddr_t));
+		kserver = NULL;
+	}
+#endif
+
 	ddebug("Shutting down task manager");
 	isc_taskmgr_destroy(&taskmgr);
 
@@ -2114,6 +2656,9 @@ cleanup(void) {
 	ddebug("Destroying name state");
 	dns_name_destroy();
 
+	ddebug("Removing log context");
+	isc_log_destroy(&lctx);
+
 	ddebug("Destroying memory context");
 	if (memdebugging)
 		isc_mem_stats(mctx, stderr);
@@ -2155,7 +2700,12 @@ main(int argc, char **argv) {
 
 	isc_app_start();
 
-	parse_args(argc, argv);
+	pre_parse_args(argc, argv);
+
+	result = isc_mem_create(0, 0, &mctx);
+	check_result(result, "isc_mem_create");
+
+	parse_args(argc, argv, mctx, &entropy);
 
 	setup_system();
 
diff --git a/contrib/bind9/bin/nsupdate/nsupdate.docbook b/contrib/bind9/bin/nsupdate/nsupdate.docbook
index 43fe69a..c42a053 100644
--- a/contrib/bind9/bin/nsupdate/nsupdate.docbook
+++ b/contrib/bind9/bin/nsupdate/nsupdate.docbook
@@ -2,7 +2,7 @@
                "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
 	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -18,18 +18,18 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: nsupdate.docbook,v 1.18.18.12 2008/08/29 23:46:16 tbox Exp $ -->
-<refentry>
+<!-- $Id: nsupdate.docbook,v 1.34.48.3 2009/03/09 04:21:56 marka Exp $ -->
+<refentry id="man.nsupdate">
   <refentryinfo>
     <date>Jun 30, 2000</date>
   </refentryinfo>
   <refmeta>
-    <refentrytitle>nsupdate</refentrytitle>
+    <refentrytitle><application>nsupdate</application></refentrytitle>
     <manvolnum>1</manvolnum>
     <refmiscinfo>BIND9</refmiscinfo>
   </refmeta>
   <refnamediv>
-    <refname>nsupdate</refname>
+    <refname><application>nsupdate</application></refname>
     <refpurpose>Dynamic DNS update utility</refpurpose>
   </refnamediv>
 
@@ -40,6 +40,7 @@
       <year>2006</year>
       <year>2007</year>
       <year>2008</year>
+      <year>2009</year>
       <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
     </copyright>
     <copyright>
@@ -55,13 +56,17 @@
     <cmdsynopsis>
       <command>nsupdate</command>
       <arg><option>-d</option></arg>
+      <arg><option>-D</option></arg>
       <group>
+	<arg><option>-g</option></arg>
+	<arg><option>-o</option></arg>
         <arg><option>-y <replaceable class="parameter"><optional>hmac:</optional>keyname:secret</replaceable></option></arg>
         <arg><option>-k <replaceable class="parameter">keyfile</replaceable></option></arg>
       </group>
       <arg><option>-t <replaceable class="parameter">timeout</replaceable></option></arg>
       <arg><option>-u <replaceable class="parameter">udptimeout</replaceable></option></arg>
       <arg><option>-r <replaceable class="parameter">udpretries</replaceable></option></arg>
+      <arg><option>-R <replaceable class="parameter">randomdev</replaceable></option></arg>
       <arg><option>-v</option></arg>
       <arg>filename</arg>
     </cmdsynopsis>
@@ -102,31 +107,31 @@
       made and the replies received from the name server.
     </para>
     <para>
-      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
-      <command>nsupdate</command> 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
-      <type>key</type>
-      and
-      <type>server</type>
-      statements would be added to
-      <filename>/etc/named.conf</filename>
-      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.
-      <command>nsupdate</command>
-      does not read
+      The <option>-D</option> option makes <command>nsupdate</command>
+      report additional debugging information to <option>-d</option>.
+    </para>
+    <para>
+      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 or GSS-TSIG as described in RFC3645.  TSIG relies on
+      a shared secret that should only be known to
+      <command>nsupdate</command> 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 <type>key</type> and
+      <type>server</type> statements would be added to
+      <filename>/etc/named.conf</filename> 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.
+      <command>nsupdate</command> does not read
       <filename>/etc/named.conf</filename>.
+      GSS-TSIG uses Kerberos credentials.
     </para>
     <para><command>nsupdate</command>
       uses the <option>-y</option> or <option>-k</option> option
@@ -159,7 +164,12 @@
       specified is not an HMAC-MD5 key.
     </para>
     <para>
-      By default
+      The <option>-g</option> and <option>-o</option> specify that
+      GSS-TSIG is to be used.  The <option>-o</option> should only
+      be used with old Microsoft Windows 2000 servers.
+    </para>
+    <para>
+      By default,
       <command>nsupdate</command>
       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.
@@ -189,6 +199,18 @@
       default is
       3.  If zero, only one update request will be made.
     </para>
+    <para>
+      The <option>-R <replaceable
+      class="parameter">randomdev</replaceable></option> option
+      specifies a 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.  This option may be specified multiple times.
+    </para>
   </refsect1>
 
   <refsect1>
@@ -307,6 +329,20 @@
 
         <varlistentry>
           <term>
+              <command>ttl</command>
+              <arg choice="req">seconds</arg>
+            </term>
+          <listitem>
+            <para>
+              Specify the default time to live for records to be added.
+	      The value <parameter>none</parameter> will clear the default
+	      ttl.
+            </para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term>
               <command>key</command>
               <arg choice="req">name</arg>
               <arg choice="req">secret</arg>
@@ -510,6 +546,17 @@
           </listitem>
         </varlistentry>
 
+        <varlistentry>
+          <term>
+              <command>debug</command>
+            </term>
+          <listitem>
+            <para>
+              Turn on debugging.
+            </para>
+          </listitem>
+        </varlistentry>
+
       </variablelist>
     </para>
 
diff --git a/contrib/bind9/bin/nsupdate/nsupdate.html b/contrib/bind9/bin/nsupdate/nsupdate.html
index 1fe0f9c..dab7f90 100644
--- a/contrib/bind9/bin/nsupdate/nsupdate.html
+++ b/contrib/bind9/bin/nsupdate/nsupdate.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: nsupdate.html,v 1.14.18.23 2008/09/01 02:29:00 tbox Exp $ -->
+<!-- $Id: nsupdate.html,v 1.40.48.2 2009/03/10 01:54:11 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -22,17 +22,17 @@
 <meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
 </head>
 <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
-<a name="id2476275"></a><div class="titlepage"></div>
+<a name="man.nsupdate"></a><div class="titlepage"></div>
 <div class="refnamediv">
 <h2>Name</h2>
-<p>nsupdate &#8212; Dynamic DNS update utility</p>
+<p><span class="application">nsupdate</span> &#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>[<span class="optional">hmac:</span>]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 class="cmdsynopsis"><p><code class="command">nsupdate</code>  [<code class="option">-d</code>] [<code class="option">-D</code>] [[<code class="option">-g</code>] |  [<code class="option">-o</code>] |  [<code class="option">-y <em class="replaceable"><code>[<span class="optional">hmac:</span>]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">-R <em class="replaceable"><code>randomdev</code></em></code>] [<code class="option">-v</code>] [filename]</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2543420"></a><h2>DESCRIPTION</h2>
+<a name="id2543449"></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.
@@ -66,31 +66,31 @@
       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
-      <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>
-      and
-      <span class="type">server</span>
-      statements would be added to
-      <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.
-      <span><strong class="command">nsupdate</strong></span>
-      does not read
+      The <code class="option">-D</code> option makes <span><strong class="command">nsupdate</strong></span>
+      report additional debugging information to <code class="option">-d</code>.
+    </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 or GSS-TSIG as described in RFC3645.  TSIG relies on
+      a shared secret that should only be known to
+      <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> and
+      <span class="type">server</span> statements would be added to
+      <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.
+      <span><strong class="command">nsupdate</strong></span> does not read
       <code class="filename">/etc/named.conf</code>.
+      GSS-TSIG uses Kerberos credentials.
     </p>
 <p><span><strong class="command">nsupdate</strong></span>
       uses the <code class="option">-y</code> or <code class="option">-k</code> option
@@ -121,7 +121,12 @@
       specified is not an HMAC-MD5 key.
     </p>
 <p>
-      By default
+      The <code class="option">-g</code> and <code class="option">-o</code> specify that
+      GSS-TSIG is to be used.  The <code class="option">-o</code> should only
+      be used with old Microsoft Windows 2000 servers.
+    </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.
@@ -151,9 +156,20 @@
       default is
       3.  If zero, only one update request will be made.
     </p>
+<p>
+      The <code class="option">-R <em class="replaceable"><code>randomdev</code></em></code> option
+      specifies a 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.  <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
+      <code class="filename">keyboard</code> indicates that keyboard input
+      should be used.  This option may be specified multiple times.
+    </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2543649"></a><h2>INPUT FORMAT</h2>
+<a name="id2543726"></a><h2>INPUT FORMAT</h2>
 <p><span><strong class="command">nsupdate</strong></span>
       reads input from
       <em class="parameter"><code>filename</code></em>
@@ -247,6 +263,15 @@
               <em class="parameter"><code>IN</code></em>.
             </p></dd>
 <dt><span class="term">
+              <span><strong class="command">ttl</strong></span>
+               {seconds}
+            </span></dt>
+<dd><p>
+              Specify the default time to live for records to be added.
+	      The value <em class="parameter"><code>none</code></em> will clear the default
+	      ttl.
+            </p></dd>
+<dt><span class="term">
               <span><strong class="command">key</strong></span>
                {name}
                {secret}
@@ -394,6 +419,12 @@
 <dd><p>
               Displays the answer.
             </p></dd>
+<dt><span class="term">
+              <span><strong class="command">debug</strong></span>
+            </span></dt>
+<dd><p>
+              Turn on debugging.
+            </p></dd>
 </dl></div>
 <p>
     </p>
@@ -402,7 +433,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2544446"></a><h2>EXAMPLES</h2>
+<a name="id2544567"></a><h2>EXAMPLES</h2>
 <p>
       The examples below show how
       <span><strong class="command">nsupdate</strong></span>
@@ -456,7 +487,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2544490"></a><h2>FILES</h2>
+<a name="id2544611"></a><h2>FILES</h2>
 <div class="variablelist"><dl>
 <dt><span class="term"><code class="constant">/etc/resolv.conf</code></span></dt>
 <dd><p>
@@ -475,7 +506,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2544560"></a><h2>SEE ALSO</h2>
+<a name="id2544680"></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>,
@@ -488,7 +519,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2542172"></a><h2>BUGS</h2>
+<a name="id2542156"></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
diff --git a/contrib/bind9/bin/rndc/Makefile.in b/contrib/bind9/bin/rndc/Makefile.in
index 3bc72b1..9b0e20d 100644
--- a/contrib/bind9/bin/rndc/Makefile.in
+++ b/contrib/bind9/bin/rndc/Makefile.in
@@ -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.40.18.4 2007/08/28 07:20:01 tbox Exp $
+# $Id: Makefile.in,v 1.44 2007/06/18 23:47:22 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/bin/rndc/include/rndc/os.h b/contrib/bind9/bin/rndc/include/rndc/os.h
index b5c1d24..253dcba 100644
--- a/contrib/bind9/bin/rndc/include/rndc/os.h
+++ b/contrib/bind9/bin/rndc/include/rndc/os.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: os.h,v 1.5.18.2 2005/04/29 00:15:41 marka Exp $ */
+/* $Id: os.h,v 1.9.332.2 2009/01/18 23:47:35 tbox Exp $ */
 
 /*! \file */
 
@@ -35,7 +35,7 @@ FILE *safe_create(const char *filename);
 
 int set_user(FILE *fd, const char *user);
 /*%<
- * Set the owner of the file refernced by 'fd' to 'user'.
+ * Set the owner of the file referenced by 'fd' to 'user'.
  * Returns:
  *   0 		success
  *   -1 	insufficient permissions, or 'user' does not exist.
diff --git a/contrib/bind9/bin/rndc/rndc-confgen.8 b/contrib/bind9/bin/rndc/rndc-confgen.8
index fe25a7b..440870a 100644
--- a/contrib/bind9/bin/rndc/rndc-confgen.8
+++ b/contrib/bind9/bin/rndc/rndc-confgen.8
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: rndc-confgen.8,v 1.9.18.11 2007/01/30 00:23:44 marka Exp $
+.\" $Id: rndc-confgen.8,v 1.20 2007/01/30 00:24:59 marka Exp $
 .\"
 .hy 0
 .ad l
diff --git a/contrib/bind9/bin/rndc/rndc-confgen.c b/contrib/bind9/bin/rndc/rndc-confgen.c
index bb7ba81..221135e 100644
--- a/contrib/bind9/bin/rndc/rndc-confgen.c
+++ b/contrib/bind9/bin/rndc/rndc-confgen.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001, 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rndc-confgen.c,v 1.18.18.5 2008/10/15 23:46:06 tbox Exp $ */
+/* $Id: rndc-confgen.c,v 1.26 2008/10/15 23:47:31 tbox Exp $ */
 
 /*! \file */
 
@@ -160,6 +160,8 @@ main(int argc, char **argv) {
 	serveraddr = DEFAULT_SERVER;
 	port = DEFAULT_PORT;
 
+	isc_commandline_errprint = ISC_FALSE;
+
 	while ((ch = isc_commandline_parse(argc, argv,
 					   "ab:c:hk:Mmp:r:s:t:u:Vy")) != -1) {
 		switch (ch) {
@@ -214,12 +216,17 @@ main(int argc, char **argv) {
 			verbose = ISC_TRUE;
 			break;
 		case '?':
-			usage(1);
+			if (isc_commandline_option != '?') {
+				fprintf(stderr, "%s: invalid argument -%c\n",
+					program, isc_commandline_option);
+				usage(1);
+			} else
+				usage(0);
 			break;
 		default:
-			fatal("unexpected error parsing command arguments: "
-			      "got %c\n", ch);
-			break;
+			fprintf(stderr, "%s: unhandled option -%c\n",
+				program, isc_commandline_option);
+			exit(1);
 		}
 	}
 
diff --git a/contrib/bind9/bin/rndc/rndc-confgen.docbook b/contrib/bind9/bin/rndc/rndc-confgen.docbook
index c694f4b..4c51da5 100644
--- a/contrib/bind9/bin/rndc/rndc-confgen.docbook
+++ b/contrib/bind9/bin/rndc/rndc-confgen.docbook
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: rndc-confgen.docbook,v 1.6.18.7 2007/08/28 07:20:01 tbox Exp $ -->
+<!-- $Id: rndc-confgen.docbook,v 1.13 2007/06/18 23:47:25 tbox Exp $ -->
 <refentry id="man.rndc-confgen">
   <refentryinfo>
     <date>Aug 27, 2001</date>
diff --git a/contrib/bind9/bin/rndc/rndc-confgen.html b/contrib/bind9/bin/rndc/rndc-confgen.html
index fd40a81..4be87af 100644
--- a/contrib/bind9/bin/rndc/rndc-confgen.html
+++ b/contrib/bind9/bin/rndc/rndc-confgen.html
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: rndc-confgen.html,v 1.8.18.17 2007/01/30 00:23:44 marka Exp $ -->
+<!-- $Id: rndc-confgen.html,v 1.25 2007/01/30 00:24:59 marka Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
diff --git a/contrib/bind9/bin/rndc/rndc.8 b/contrib/bind9/bin/rndc/rndc.8
index 6858ed7..7f0dea1 100644
--- a/contrib/bind9/bin/rndc/rndc.8
+++ b/contrib/bind9/bin/rndc/rndc.8
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: rndc.8,v 1.26.18.16 2007/12/14 22:37:16 marka Exp $
+.\" $Id: rndc.8,v 1.42 2007/12/14 22:37:22 marka Exp $
 .\"
 .hy 0
 .ad l
diff --git a/contrib/bind9/bin/rndc/rndc.c b/contrib/bind9/bin/rndc/rndc.c
index 772cc29..c3d4cb7 100644
--- a/contrib/bind9/bin/rndc/rndc.c
+++ b/contrib/bind9/bin/rndc/rndc.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rndc.c,v 1.96.18.21 2008/10/15 03:07:19 marka Exp $ */
+/* $Id: rndc.c,v 1.122.44.2 2009/01/18 23:47:35 tbox Exp $ */
 
 /*! \file */
 
@@ -200,7 +200,7 @@ rndc_recvdone(isc_task_t *task, isc_event_t *event) {
 		      "* the remote server is using an older version of"
 		      " the command protocol,\n"
 		      "* this host is not authorized to connect,\n"
-		      "* the clocks are not syncronized, or\n"
+		      "* the clocks are not synchronized, or\n"
 		      "* the key is invalid.");
 
 	if (ccmsg.result != ISC_R_SUCCESS)
@@ -263,7 +263,7 @@ rndc_recvnonce(isc_task_t *task, isc_event_t *event) {
 		      "* the remote server is using an older version of"
 		      " the command protocol,\n"
 		      "* this host is not authorized to connect,\n"
-		      "* the clocks are not syncronized, or\n"
+		      "* the clocks are not synchronized, or\n"
 		      "* the key is invalid.");
 
 	if (ccmsg.result != ISC_R_SUCCESS)
@@ -369,7 +369,7 @@ rndc_connected(isc_task_t *task, isc_event_t *event) {
 	r.base = databuf;
 
 	isccc_ccmsg_init(mctx, sock, &ccmsg);
-	isccc_ccmsg_setmaxsize(&ccmsg, 1024);
+	isccc_ccmsg_setmaxsize(&ccmsg, 1024 * 1024);
 
 	DO("schedule recv", isccc_ccmsg_readmessage(&ccmsg, task,
 						    rndc_recvnonce, NULL));
@@ -690,7 +690,9 @@ main(int argc, char **argv) {
 	if (result != ISC_R_SUCCESS)
 		fatal("isc_app_start() failed: %s", isc_result_totext(result));
 
-	while ((ch = isc_commandline_parse(argc, argv, "b:c:k:Mmp:s:Vy:"))
+	isc_commandline_errprint = ISC_FALSE;
+
+	while ((ch = isc_commandline_parse(argc, argv, "b:c:hk:Mmp:s:Vy:"))
 	       != -1) {
 		switch (ch) {
 		case 'b':
@@ -741,13 +743,18 @@ main(int argc, char **argv) {
 			break;
 
 		case '?':
+			if (isc_commandline_option != '?') {
+				fprintf(stderr, "%s: invalid argument -%c\n",
+					program, isc_commandline_option);
+				usage(1);
+			}
+		case 'h':
 			usage(0);
 			break;
-
 		default:
-			fatal("unexpected error parsing command arguments: "
-			      "got %c\n", ch);
-			break;
+			fprintf(stderr, "%s: unhandled option -%c\n",
+				program, isc_commandline_option);
+			exit(1);
 		}
 	}
 
diff --git a/contrib/bind9/bin/rndc/rndc.conf b/contrib/bind9/bin/rndc/rndc.conf
index e303535..67542b9 100644
--- a/contrib/bind9/bin/rndc/rndc.conf
+++ b/contrib/bind9/bin/rndc/rndc.conf
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rndc.conf,v 1.8.18.1 2004/06/18 04:39:39 marka Exp $ */
+/* $Id: rndc.conf,v 1.11 2007/06/19 23:46:59 tbox Exp $ */
 
 /*
  * Sample rndc configuration file.
diff --git a/contrib/bind9/bin/rndc/rndc.conf.5 b/contrib/bind9/bin/rndc/rndc.conf.5
index dbeb707..9e9bad4 100644
--- a/contrib/bind9/bin/rndc/rndc.conf.5
+++ b/contrib/bind9/bin/rndc/rndc.conf.5
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: rndc.conf.5,v 1.23.18.15 2007/05/09 13:35:47 marka Exp $
+.\" $Id: rndc.conf.5,v 1.38 2007/05/09 13:35:57 marka Exp $
 .\"
 .hy 0
 .ad l
diff --git a/contrib/bind9/bin/rndc/rndc.conf.docbook b/contrib/bind9/bin/rndc/rndc.conf.docbook
index ebea7af..9de19954 100644
--- a/contrib/bind9/bin/rndc/rndc.conf.docbook
+++ b/contrib/bind9/bin/rndc/rndc.conf.docbook
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: rndc.conf.docbook,v 1.5.18.12 2007/08/28 07:20:01 tbox Exp $ -->
+<!-- $Id: rndc.conf.docbook,v 1.17 2007/06/18 23:47:25 tbox Exp $ -->
 <refentry id="man.rndc.conf">
   <refentryinfo>
     <date>June 30, 2000</date>
diff --git a/contrib/bind9/bin/rndc/rndc.conf.html b/contrib/bind9/bin/rndc/rndc.conf.html
index d11f9df..144cd1c 100644
--- a/contrib/bind9/bin/rndc/rndc.conf.html
+++ b/contrib/bind9/bin/rndc/rndc.conf.html
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: rndc.conf.html,v 1.6.18.23 2007/05/09 13:35:47 marka Exp $ -->
+<!-- $Id: rndc.conf.html,v 1.29 2007/05/09 13:35:57 marka Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
diff --git a/contrib/bind9/bin/rndc/rndc.docbook b/contrib/bind9/bin/rndc/rndc.docbook
index f2f0a0d..d407f2b 100644
--- a/contrib/bind9/bin/rndc/rndc.docbook
+++ b/contrib/bind9/bin/rndc/rndc.docbook
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: rndc.docbook,v 1.8.18.13 2007/12/14 20:53:58 marka Exp $ -->
+<!-- $Id: rndc.docbook,v 1.21 2007/12/14 20:39:14 marka Exp $ -->
 <refentry id="man.rndc">
   <refentryinfo>
     <date>June 30, 2000</date>
diff --git a/contrib/bind9/bin/rndc/rndc.html b/contrib/bind9/bin/rndc/rndc.html
index c460225..a8d11c4 100644
--- a/contrib/bind9/bin/rndc/rndc.html
+++ b/contrib/bind9/bin/rndc/rndc.html
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: rndc.html,v 1.8.18.23 2007/12/14 22:37:16 marka Exp $ -->
+<!-- $Id: rndc.html,v 1.31 2007/12/14 22:37:22 marka Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
diff --git a/contrib/bind9/bin/rndc/unix/Makefile.in b/contrib/bind9/bin/rndc/unix/Makefile.in
index 6696c23..31a0532 100644
--- a/contrib/bind9/bin/rndc/unix/Makefile.in
+++ b/contrib/bind9/bin/rndc/unix/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.3 2004/03/05 04:58:29 marka Exp $
+# $Id: Makefile.in,v 1.5 2007/06/19 23:46:59 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/bin/rndc/unix/os.c b/contrib/bind9/bin/rndc/unix/os.c
index f5f6a91..ddf8259 100644
--- a/contrib/bind9/bin/rndc/unix/os.c
+++ b/contrib/bind9/bin/rndc/unix/os.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: os.c,v 1.6.18.2 2005/04/29 00:15:41 marka Exp $ */
+/* $Id: os.c,v 1.10 2007/06/19 23:46:59 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/bin/rndc/util.c b/contrib/bind9/bin/rndc/util.c
index c64add72..c654462 100644
--- a/contrib/bind9/bin/rndc/util.c
+++ b/contrib/bind9/bin/rndc/util.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: util.c,v 1.3.18.2 2005/04/29 00:15:40 marka Exp $ */
+/* $Id: util.c,v 1.7 2007/06/19 23:46:59 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/bin/rndc/util.h b/contrib/bind9/bin/rndc/util.h
index 6414861..7adcaa5 100644
--- a/contrib/bind9/bin/rndc/util.h
+++ b/contrib/bind9/bin/rndc/util.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: util.h,v 1.6.18.2 2005/04/29 00:15:41 marka Exp $ */
+/* $Id: util.h,v 1.10 2007/06/19 23:46:59 tbox Exp $ */
 
 #ifndef RNDC_UTIL_H
 #define RNDC_UTIL_H 1
diff --git a/contrib/bind9/config.guess b/contrib/bind9/config.guess
index 7d0185e..c79aebc 100644
--- a/contrib/bind9/config.guess
+++ b/contrib/bind9/config.guess
@@ -141,7 +141,7 @@ UNAME_VERSION=`(uname -v) 2>/dev/null` || UNAME_VERSION=unknown
 case "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" in
     *:NetBSD:*:*)
 	# NetBSD (nbsd) targets should (where applicable) match one or
-	# more of the tupples: *-*-netbsdelf*, *-*-netbsdaout*,
+	# more of the tuples: *-*-netbsdelf*, *-*-netbsdaout*,
 	# *-*-netbsdecoff* and *-*-netbsd*.  For targets that recently
 	# switched to ELF, *-*-netbsd* would select the old
 	# object file format.  This provides both forward
diff --git a/contrib/bind9/config.h.in b/contrib/bind9/config.h.in
index 210a079..97b13c4 100644
--- a/contrib/bind9/config.h.in
+++ b/contrib/bind9/config.h.in
@@ -1,9 +1,9 @@
 /* config.h.in.  Generated from configure.in by autoheader.  */
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -16,7 +16,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: config.h.in,v 1.60.18.34 2008/10/21 02:47:25 marka Exp $ */
+/* $Id: config.h.in,v 1.106.40.6 2009/03/13 05:35:43 marka Exp $ */
 
 /*! \file */
 
@@ -25,9 +25,6 @@
  *** it does not get installed.
  ***/
 
-/** define to `int' if <sys/types.h> doesn't define.  */
-#undef ssize_t
-
 /** define on DEC OSF to enable 4.4BSD style sa_len support */
 #undef _SOCKADDR_LEN
 
@@ -61,9 +58,6 @@
 /** define if you have the NET_RT_IFLIST sysctl variable and sys/sysctl.h */
 #undef HAVE_IFLIST_SYSCTL
 
-/** define if chroot() is available */
-#undef HAVE_CHROOT
-
 /** define if tzset() is available */
 #undef HAVE_TZSET
 
@@ -115,7 +109,7 @@ int sigwait(const unsigned int *set, int *sig);
  * The silly continuation line is to keep configure from
  * commenting out the #undef.
  */
- 
+
 #undef \
 	va_start
 #define	va_start(ap, last) \
@@ -157,11 +151,14 @@ int sigwait(const unsigned int *set, int *sig);
 /* Define if you cannot bind() before connect() for TCP sockets. */
 #undef BROKEN_TCP_BIND_BEFORE_CONNECT
 
+/* Define to enable "rrset-order fixed" syntax. */
+#undef DNS_RDATASET_FIXED
+
 /* Solaris hack to get select_large_fdset. */
 #undef FD_SETSIZE
 
-/* Define to 1 if you have the `capset' function. */
-#undef HAVE_CAPSET
+/* Define to 1 if you have the `chroot' function. */
+#undef HAVE_CHROOT
 
 /* Define to 1 if you have the <dlfcn.h> header file. */
 #undef HAVE_DLFCN_H
@@ -169,12 +166,21 @@ int sigwait(const unsigned int *set, int *sig);
 /* Define to 1 if you have the <fcntl.h> header file. */
 #undef HAVE_FCNTL_H
 
+/* Define to 1 if you have the <gssapi/gssapi.h> header file. */
+#undef HAVE_GSSAPI_GSSAPI_H
+
+/* Define to 1 if you have the <gssapi.h> header file. */
+#undef HAVE_GSSAPI_H
+
 /* Define to 1 if you have the <inttypes.h> header file. */
 #undef HAVE_INTTYPES_H
 
 /* Define to 1 if you have the `c' library (-lc). */
 #undef HAVE_LIBC
 
+/* Define to 1 if you have the `cap' library (-lcap). */
+#undef HAVE_LIBCAP
+
 /* Define to 1 if you have the `c_r' library (-lc_r). */
 #undef HAVE_LIBC_R
 
@@ -193,6 +199,9 @@ int sigwait(const unsigned int *set, int *sig);
 /* Define to 1 if you have the `thr' library (-lthr). */
 #undef HAVE_LIBTHR
 
+/* Define if libxml2 was found */
+#undef HAVE_LIBXML2
+
 /* Define to 1 if you have the <linux/capability.h> header file. */
 #undef HAVE_LINUX_CAPABILITY_H
 
@@ -202,6 +211,9 @@ int sigwait(const unsigned int *set, int *sig);
 /* Define to 1 if you have the <memory.h> header file. */
 #undef HAVE_MEMORY_H
 
+/* Define to 1 if you have the `nanosleep' function. */
+#undef HAVE_NANOSLEEP
+
 /* Define to 1 if you have the <net/if6.h> header file. */
 #undef HAVE_NET_IF6_H
 
@@ -301,9 +313,13 @@ int sigwait(const unsigned int *set, int *sig);
 /* define if idnkit support is to be included. */
 #undef WITH_IDN
 
-/* 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
+/* Define WORDS_BIGENDIAN to 1 if your processor stores words with the most
+   significant byte first (like Motorola and SPARC, unlike Intel and VAX). */
+#if defined __BIG_ENDIAN__
+# define WORDS_BIGENDIAN 1
+#elif ! defined __LITTLE_ENDIAN__
+# undef WORDS_BIGENDIAN
+#endif
 
 /* Define to empty if `const' does not conform to ANSI C. */
 #undef const
diff --git a/contrib/bind9/configure.in b/contrib/bind9/configure.in
index 6320b6a..6ebdfdd 100644
--- a/contrib/bind9/configure.in
+++ b/contrib/bind9/configure.in
@@ -1,4 +1,4 @@
-# Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1998-2003  Internet Software Consortium.
 #
 # Permission to use, copy, modify, and/or distribute this software for any
@@ -18,18 +18,17 @@ AC_DIVERT_PUSH(1)dnl
 esyscmd([sed "s/^/# /" COPYRIGHT])dnl
 AC_DIVERT_POP()dnl
 
-AC_REVISION($Revision: 1.355.18.85 $)
+AC_REVISION($Revision: 1.457.26.9 $)
 
 AC_INIT(lib/dns/name.c)
 AC_PREREQ(2.59)
 
 AC_CONFIG_HEADER(config.h)
-AC_CONFIG_SUBDIRS(lib/bind)
 
 AC_CANONICAL_HOST
 
 AC_PROG_MAKE_SET
-AC_PROG_RANLIB
+AC_PROG_LIBTOOL
 AC_PROG_INSTALL
 AC_PROG_LN_S
 
@@ -38,10 +37,23 @@ AC_SUBST(STD_CDEFINES)
 AC_SUBST(STD_CWARNINGS)
 AC_SUBST(CCOPT)
 
+# Warn if the user specified libbind, which is now deprecated
+AC_ARG_ENABLE(libbind, [  --enable-libbind	  deprecated])
+
+case "$enable_libbind" in
+	yes)
+		AC_MSG_ERROR(['libbind' is no longer part of the BIND 9 distribution.
+It is available from http://www.isc.org as a separate download.])
+		;;
+	no|'')
+		;;
+esac
+
+
 #
 # Make very sure that these are the first files processed by
 # config.status, since we use the processed output as the input for
-# AC_SUBST_FILE() subsitutions in other files.
+# AC_SUBST_FILE() substitutions in other files.
 #
 AC_CONFIG_FILES([make/rules make/includes])
 
@@ -112,18 +124,18 @@ AC_SUBST(PERL)
 # ./configure --prefix=/usr/local
 #
 case "$prefix" in
-        NONE)
-                case "$sysconfdir" in
-                        '${prefix}/etc')
-                                sysconfdir=/etc
-                                ;;
-                esac
-                case "$localstatedir" in
-                        '${prefix}/var')
-                                localstatedir=/var
-                                ;;
-                esac
-                ;;
+	NONE)
+		case "$sysconfdir" in
+			'${prefix}/etc')
+				sysconfdir=/etc
+				;;
+		esac
+		case "$localstatedir" in
+			'${prefix}/var')
+				localstatedir=/var
+				;;
+		esac
+		;;
 esac
 
 #
@@ -136,20 +148,20 @@ esac
 #
 case "$INSTALL" in
 	/*)
-                ;;
-        *)
-                #
-                # Not all systems have dirname.
-                #
-                changequote({, })
-                ac_dir="`echo $INSTALL | sed 's%/[^/]*$%%'`"
-                changequote([, ])
-
-                ac_prog="`echo $INSTALL | sed 's%.*/%%'`"
-                test "$ac_dir" = "$ac_prog" && ac_dir=.
-                test -d "$ac_dir" && ac_dir="`(cd \"$ac_dir\" && pwd)`"
-                INSTALL="$ac_dir/$ac_prog"
-                ;;
+		;;
+	*)
+		#
+		# Not all systems have dirname.
+		#
+		changequote({, })
+		ac_dir="`echo $INSTALL | sed 's%/[^/]*$%%'`"
+		changequote([, ])
+
+		ac_prog="`echo $INSTALL | sed 's%.*/%%'`"
+		test "$ac_dir" = "$ac_prog" && ac_dir=.
+		test -d "$ac_dir" && ac_dir="`(cd \"$ac_dir\" && pwd)`"
+		INSTALL="$ac_dir/$ac_prog"
+		;;
 esac
 
 #
@@ -166,12 +178,12 @@ if test "X$CC" = "X" ; then
 			CC="cc"
 			;;
 		*-solaris*)
-                        # Use Sun's cc if it is available, but watch
-                        # out for /usr/ucb/cc; it will never be the right
-                        # compiler to use.
-                        #
-                        # If setting CC here fails, the AC_PROG_CC done
-                        # below might still find gcc.
+			# Use Sun's cc if it is available, but watch
+			# out for /usr/ucb/cc; it will never be the right
+			# compiler to use.
+			#
+			# If setting CC here fails, the AC_PROG_CC done
+			# below might still find gcc.
 			IFS="${IFS=	}"; ac_save_ifs="$IFS"; IFS=":"
 			for ac_dir in $PATH; do
 				test -z "$ac_dir" && ac_dir=.
@@ -215,7 +227,7 @@ fi
 # OS dependent CC flags
 #
 case "$host" in
-	# OSF 5.0: recv/send are only avaliable with -D_POSIX_PII_SOCKET or
+	# OSF 5.0: recv/send are only available with -D_POSIX_PII_SOCKET or
 	# -D_XOPEN_SOURCE_EXTENDED.
 	*-dec-osf*)
 		STD_CDEFINES="$STD_CDEFINES -D_POSIX_PII_SOCKET"
@@ -275,7 +287,7 @@ AC_TRY_COMPILE(, [
 	],
 	[AC_MSG_RESULT(no)],
 	[AC_MSG_RESULT(yes)
-         AC_DEFINE(inline, )])
+	 AC_DEFINE(inline, )])
 
 AC_TYPE_SIZE_T
 AC_CHECK_TYPE(ssize_t, int)
@@ -355,10 +367,10 @@ AC_SUBST(ISC_PLATFORM_HAVEKQUEUE)
 # so we need to try running the code, not just test its existence.
 #
 AC_ARG_ENABLE(epoll,
-	[  --enable-epoll          use Linux epoll when available [[default=yes]]],
-	      want_epoll="$enableval",  want_epoll="yes")
+[  --enable-epoll          use Linux epoll when available [[default=auto]]],
+	      want_epoll="$enableval",  want_epoll="auto")
 case $want_epoll in
-yes)
+auto)
 	AC_MSG_CHECKING(epoll support)
 	AC_TRY_RUN([
 #include <sys/epoll.h>
@@ -373,6 +385,9 @@ int main() {
 	[AC_MSG_RESULT(no)
 	ISC_PLATFORM_HAVEEPOLL="#undef ISC_PLATFORM_HAVEEPOLL"])
 	;;
+yes)
+	ISC_PLATFORM_HAVEEPOLL="#define ISC_PLATFORM_HAVEEPOLL 1"
+	;;
 *)
 	ISC_PLATFORM_HAVEEPOLL="#undef ISC_PLATFORM_HAVEEPOLL"
 	;;
@@ -415,7 +430,7 @@ AC_TRY_COMPILE([
 	[AC_MSG_RESULT(no)
 	case $ac_cv_header_sys_select_h in
 	yes)
-         ISC_PLATFORM_NEEDSYSSELECTH="#define ISC_PLATFORM_NEEDSYSSELECTH 1"
+	 ISC_PLATFORM_NEEDSYSSELECTH="#define ISC_PLATFORM_NEEDSYSSELECTH 1"
 	 LWRES_PLATFORM_NEEDSYSSELECTH="#define LWRES_PLATFORM_NEEDSYSSELECTH 1"
 		;;
 	no)
@@ -427,7 +442,7 @@ AC_TRY_COMPILE([
 no)
 	case $ac_cv_header_sys_select_h in
 	yes)
-             ISC_PLATFORM_NEEDSYSSELECTH="#define ISC_PLATFORM_NEEDSYSSELECTH 1"
+	     ISC_PLATFORM_NEEDSYSSELECTH="#define ISC_PLATFORM_NEEDSYSSELECTH 1"
 	     LWRES_PLATFORM_NEEDSYSSELECTH="#define LWRES_PLATFORM_NEEDSYSSELECTH 1"
 		;;
 	no)
@@ -452,7 +467,7 @@ OPENSSL_WARNING=
 AC_MSG_CHECKING(for OpenSSL library)
 AC_ARG_WITH(openssl,
 [  --with-openssl[=PATH]   Build with OpenSSL [yes|no|path].
-                          (Required for DNSSEC)],
+			  (Required for DNSSEC)],
     use_openssl="$withval", use_openssl="auto")
 
 openssldirs="/usr /usr/local /usr/local/ssl /usr/pkg /usr/sfw"
@@ -481,21 +496,24 @@ case "$use_openssl" in
 	*)
 		if test "$use_openssl" = "yes"
 		then
-		    	# User did not specify a path - guess it
+			# User did not specify a path - guess it
 			for d in $openssldirs
 			do
 				if test -f $d/include/openssl/opensslv.h
 				then
-				 	use_openssl=$d
+					use_openssl=$d
 					break
 				fi
 			done
 			if test "$use_openssl" = "yes"
 			then
-			    	AC_MSG_RESULT(not found)
+				AC_MSG_RESULT(not found)
 				AC_MSG_ERROR(
 [OpenSSL was not found in any of $openssldirs; use --with-openssl=/path])
 			fi
+		elif ! test -f "$use_openssl"/include/openssl/opensslv.h
+		then
+			AC_MSG_ERROR(["$use_openssl/include/openssl/opensslv.h" not found])
 		fi
 		USE_OPENSSL='-DOPENSSL'
 		if test "$use_openssl" = "/usr"
@@ -531,7 +549,7 @@ case "$use_openssl" in
 				;;
 			esac
 		fi
-		AC_MSG_RESULT(using openssl from $use_openssl/lib and $use_openssl/include)
+		AC_MSG_RESULT(using OpenSSL from $use_openssl/lib and $use_openssl/include)
 
 		saved_cflags="$CFLAGS"
 		saved_libs="$LIBS"
@@ -545,7 +563,7 @@ int main() {
 	return (0);
 }
 ],
-	        [AC_MSG_RESULT(yes)],
+		[AC_MSG_RESULT(yes)],
 		[AC_MSG_RESULT(no)
 		 AC_MSG_ERROR(Could not run test program using OpenSSL from
 $use_openssl/lib and $use_openssl/include.
@@ -574,7 +592,7 @@ shared library configuration (e.g., LD_LIBRARY_PATH).)],
 		 
 AC_ARG_ENABLE(openssl-version-check,
 [AC_HELP_STRING([--enable-openssl-version-check],
-        [Check OpenSSL Version @<:@default=yes@:>@])])
+	[Check OpenSSL Version @<:@default=yes@:>@])])
 case "$enable_openssl_version_check" in
 yes|'')
 		AC_MSG_CHECKING(OpenSSL library version)
@@ -582,20 +600,20 @@ yes|'')
 #include <stdio.h>
 #include <openssl/opensslv.h>
 int main() {
-        if ((OPENSSL_VERSION_NUMBER >= 0x009070cfL &&
+	if ((OPENSSL_VERSION_NUMBER >= 0x009070cfL &&
 	     OPENSSL_VERSION_NUMBER < 0x00908000L) ||
 	     OPENSSL_VERSION_NUMBER >= 0x0090804fL)
-                return (0);
+		return (0);
 	printf("\n\nFound   OPENSSL_VERSION_NUMBER %#010x\n",
 		OPENSSL_VERSION_NUMBER);
 	printf("Require OPENSSL_VERSION_NUMBER 0x009070cf or greater (0.9.7l)\n"
 	       "Require OPENSSL_VERSION_NUMBER 0x0090804f or greater (0.9.8d)\n\n");
-        return (1);
+	return (1);
 }
 		],
-	        [AC_MSG_RESULT(ok)],
+		[AC_MSG_RESULT(ok)],
 		[AC_MSG_RESULT(not compatible)
-                 OPENSSL_WARNING=yes
+		 OPENSSL_WARNING=yes
 		],
 		[AC_MSG_RESULT(assuming target platform has compatible version)])
 ;;
@@ -627,38 +645,173 @@ AC_SUBST(DST_OPENSSL_INC)
 DNS_CRYPTO_LIBS="$DNS_CRYPTO_LIBS $DNS_OPENSSL_LIBS"
 
 #
-# was --with-gssapi specified?
-#
-#AC_MSG_CHECKING(for GSSAPI library)
-#AC_ARG_WITH(gssapi,
-#[  --with-gssapi=PATH   Specify path for system-supplied GSSAPI],
-#    use_gssapi="$withval", use_gssapi="no")
-#
-#case "$use_gssapi" in
-#	no)
-#		USE_GSSAPI=''
-#		DST_GSSAPI_INC=''
-#		DNS_GSSAPI_LIBS=''
-#		AC_MSG_RESULT(not specified)
-#		;;
-#	yes)
-#		AC_MSG_ERROR([--with-gssapi must specify a path])
-#		;;
-#	*)
-#		USE_GSSAPI='-DGSSAPI'
-#		DST_GSSAPI_INC="-I$use_gssapi/include"
-#		DNS_GSSAPI_LIBS="-L$use_gssapi/lib -lgssapi_krb5"
-#		AC_MSG_RESULT(using gssapi from $use_gssapi/lib and $use_gssapi/include)
-#		;;
-#esac
-
-USE_GSSAPI=''
-DST_GSSAPI_INC=''
-DNS_GSSAPI_LIBS=''
+# PKCS11 (aka crypto hardware) support
+#
+# This works only with the right OpenSSL with PKCS11 engine!
+#
+
+AC_MSG_CHECKING(for PKCS11 support)
+AC_ARG_WITH(pkcs11,
+[  --with-pkcs11     Build with PKCS11 support],
+   use_pkcs11="yes", use_pkcs11="no")
+
+case "$use_pkcs11" in
+	no)
+		AC_MSG_RESULT(disabled)
+		USE_PKCS11=""
+		;;
+	yes)
+		AC_MSG_RESULT(using OpenSSL with PKCS11 support)
+		USE_PKCS11='-DUSE_PKCS11'
+		;;
+esac
+
+AC_SUBST(USE_PKCS11)
+
+AC_MSG_CHECKING(for GSSAPI library)
+AC_ARG_WITH(gssapi,
+[  --with-gssapi=PATH   Specify path for system-supplied GSSAPI],
+    use_gssapi="$withval", use_gssapi="no")
+
+gssapidirs="/usr/local /usr/pkg /usr/kerberos /usr"
+if test "$use_gssapi" = "yes"
+then
+	for d in $gssapidirs
+	do
+		if test -f $d/include/gssapi/gssapi.h -o -f $d/include/gssapi.h
+		then
+			use_gssapi=$d
+			break
+		fi
+	done
+fi
+
+case "$use_gssapi" in
+	no)
+		AC_MSG_RESULT(disabled)
+		USE_GSSAPI=''
+		;;
+	yes)
+		AC_MSG_ERROR([--with-gssapi must specify a path])
+		;;
+	*)
+		AC_MSG_RESULT(looking in $use_gssapi/lib)
+		USE_GSSAPI='-DGSSAPI'
+		saved_cppflags="$CPPFLAGS"
+		CPPFLAGS="-I$use_gssapi/include $CPPFLAGS"
+		AC_CHECK_HEADERS(gssapi.h gssapi/gssapi.h,
+		    [ISC_PLATFORM_GSSAPIHEADER="#define ISC_PLATFORM_GSSAPIHEADER <$ac_header>"])
+
+		if test "$ISC_PLATFORM_GSSAPIHEADER" = ""; then
+		    AC_MSG_ERROR([gssapi.h not found])
+		fi
+
+		CPPFLAGS="$saved_cppflags"
+
+		#
+		# XXXDCL This probably doesn't work right on all systems.
+		# It will need to be worked on as problems become evident.
+		#
+		# Essentially the problems here relate to two different
+		# areas.  The first area is building with either KTH
+		# or MIT Kerberos, particularly when both are present on
+		# the machine.  The other is static versus dynamic linking.
+		#
+		# On the KTH vs MIT issue, Both have libkrb5 that can mess
+		# up the works if one implementation ends up trying to
+		# use the other's krb.  This is unfortunately a situation
+		# that very easily arises.
+		#
+		# Dynamic linking when the dependency information is built
+		# into MIT's libgssapi_krb5 or KTH's libgssapi magically makes
+		# all such problems go away, but when that setup is not
+		# present, because either the dynamic libraries lack
+		# dependencies or static linking is being done, then the
+		# problems start to show up.
+		saved_libs="$LIBS"
+		for TRY_LIBS in \
+		    "-lgssapi_krb5" \
+		    "-lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err" \
+		    "-lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -lresolv" \
+		    "-lgssapi" \
+		    "-lgssapi -lkrb5 -ldes -lcrypt -lasn1 -lroken -lcom_err" \
+		    "-lgssapi -lkrb5 -lcrypto -lcrypt -lasn1 -lroken -lcom_err" \
+		    "-lgss"
+		do
+		    # Note that this does not include $saved_libs, because
+		    # on FreeBSD machines this configure script has added
+		    # -L/usr/local/lib to LIBS, which can make the
+		    # -lgssapi_krb5 test succeed with shared libraries even
+		    # when you are trying to build with KTH in /usr/lib.
+		    LIBS="-L$use_gssapi/lib $TRY_LIBS"
+		    AC_MSG_CHECKING(linking as $TRY_LIBS)
+		    AC_TRY_LINK( , [gss_acquire_cred();],
+				gssapi_linked=yes, gssapi_linked=no)
+		    case $gssapi_linked in
+		    yes) AC_MSG_RESULT(yes); break ;;
+		    no)  AC_MSG_RESULT(no) ;;
+		    esac
+		done
+
+		case $gssapi_linked in
+		no) AC_MSG_ERROR(could not determine proper GSSAPI linkage) ;;
+		esac
+
+		#
+		# XXXDCL Major kludge.  Tries to cope with KTH in /usr/lib
+		# but MIT in /usr/local/lib and trying to build with KTH.
+		# /usr/local/lib can end up earlier on the link lines.
+		# Like most kludges, this one is not only inelegant it
+		# is also likely to be the wrong thing to do at least as
+		# many times as it is the right thing.  Something better
+		# needs to be done.
+		#
+		if test "$use_gssapi" = "/usr" -a \
+			-f /usr/local/lib/libkrb5.a; then
+		    FIX_KTH_VS_MIT=yes
+		fi
+
+		case "$FIX_KTH_VS_MIT" in
+		yes)
+		    case "$enable_static_linking" in
+		    yes) gssapi_lib_suffix=".a"  ;;
+		    *)   gssapi_lib_suffix=".so" ;;
+		    esac
+
+		    for lib in $LIBS; do
+			case $lib in
+			-L*)
+			    ;;
+			-l*)
+			    new_lib=`echo $lib |
+				     sed -e s%^-l%$use_gssapi/lib/lib% \
+					 -e s%$%$gssapi_lib_suffix%`
+			    NEW_LIBS="$NEW_LIBS $new_lib"
+			    ;;
+			*)
+			   AC_MSG_ERROR([KTH vs MIT Kerberos confusion!])
+			    ;;
+			esac
+		    done
+		    LIBS="$NEW_LIBS"
+		    ;;
+		esac
+
+		DST_GSSAPI_INC="-I$use_gssapi/include"
+		DNS_GSSAPI_LIBS="$LIBS"
+
+		AC_MSG_RESULT(using GSSAPI from $use_gssapi/lib and $use_gssapi/include)
+		LIBS="$saved_libs"
+		;;
+esac
+
+AC_SUBST(ISC_PLATFORM_HAVEGSSAPI)
+AC_SUBST(ISC_PLATFORM_GSSAPIHEADER)
 
 AC_SUBST(USE_GSSAPI)
 AC_SUBST(DST_GSSAPI_INC)
-DNS_CRYPTO_LIBS="$DNS_CRYPTO_LIBS $DNS_GSSAPI_LIBS"
+AC_SUBST(DNS_GSSAPI_LIBS)
+DNS_CRYPTO_LIBS="$DNS_GSSAPI_LIBS $DNS_CRYPTO_LIBS"
 
 #
 # Applications linking with libdns also need to link with these libraries.
@@ -764,7 +917,7 @@ then
 		      AC_CHECK_LIB(pthread, sigwait,
 				   AC_DEFINE(HAVE_SIGWAIT),
 				   AC_CHECK_LIB(pthread, _Psigwait,
-					        AC_DEFINE(HAVE_SIGWAIT),))))
+						AC_DEFINE(HAVE_SIGWAIT),))))
 
 	AC_CHECK_FUNC(pthread_attr_getstacksize,
 		      AC_DEFINE(HAVE_PTHREAD_ATTR_GETSTACKSIZE),)
@@ -840,6 +993,48 @@ ISC_THREAD_DIR=$thread_dir
 AC_SUBST(ISC_THREAD_DIR)
 
 #
+# was --with-libxml2 specified?
+#
+AC_MSG_CHECKING(for libxml2 library)
+AC_ARG_WITH(libxml2,
+[  --with-libxml2[=PATH]   Build with libxml2 library [yes|no|path]],
+    use_libxml2="$withval", use_libxml2="auto")
+
+case "$use_libxml2" in
+	no)
+		DST_LIBXML2_INC=""
+		;;
+	auto|yes)
+		case X`(xml2-config --version) 2>/dev/null` in
+		X2.[[67]].*)
+			libxml2_libs=`xml2-config --libs`
+			libxml2_cflags=`xml2-config --cflags`
+			;;
+		*)
+			libxml2_libs=
+			libxml2_cflags=
+			;;
+		esac
+		;;
+	*)
+		if test -f "$use_libxml2/bin/xml2-config" ; then
+			libxml2_libs=`$use_libxml2/bin/xml2-config --libs`
+			libxml2_cflags=`$use_libxml2/bin/xml2-config --cflags`
+		fi
+		;;
+esac
+
+if test "X$libxml2_libs" != "X"
+then
+	AC_MSG_RESULT(yes)
+	CFLAGS="$CFLAGS $libxml2_cflags"
+	LIBS="$LIBS $libxml2_libs"
+	AC_DEFINE(HAVE_LIBXML2, 1, [Define if libxml2 was found])
+else
+	AC_MSG_RESULT(no)
+fi
+
+#
 # In solaris 10, SMF can manage named service
 #
 AC_CHECK_LIB(scf, smf_enable_instance)
@@ -914,9 +1109,9 @@ else
 	*-hp-hpux*)
 		CC="$CC -Ae -z"
 		# The version of the C compiler that constantly warns about
-                # 'const' as well as alignment issues is unfortunately not
-                # able to be discerned via the version of the operating
-                # system, nor does cc have a version flag.
+		# 'const' as well as alignment issues is unfortunately not
+		# able to be discerned via the version of the operating
+		# system, nor does cc have a version flag.
 		case "`$CC +W 123 2>&1`" in
 		*Unknown?option*)
 			STD_CWARNINGS="+w1"
@@ -945,7 +1140,7 @@ else
 		MKDEPCFLAGS="-xM"
 		;;
 	*-sco-sysv*uw*|*-*-sysv*UnixWare*|*-*-sysv*OpenUNIX*)
-                # UnixWare
+		# UnixWare
 		CC="$CC -w"
 		;;
 	esac
@@ -966,7 +1161,6 @@ AC_CHECK_FUNC(catgets, AC_DEFINE(HAVE_CATGETS),)
 #
 # AC_CHECK_LIB(xnet, socket, ,
 #    AC_CHECK_LIB(socket, socket)
-#    AC_CHECK_LIB(nsl, inet_ntoa)
 # )
 #
 # Use this for now, instead:
@@ -974,9 +1168,11 @@ AC_CHECK_FUNC(catgets, AC_DEFINE(HAVE_CATGETS),)
 case "$host" in
 	mips-sgi-irix*)
 		;;
+	*-linux*)
+		;;
 	*)
 		AC_CHECK_LIB(socket, socket)
-		AC_CHECK_LIB(nsl, inet_ntoa)
+		AC_CHECK_LIB(nsl, inet_addr)
 		;;
 esac
 
@@ -1095,24 +1291,8 @@ AC_SUBST(LIBTOOL_ALLOW_UNDEFINED)
 AC_SUBST(LIBTOOL_IN_MAIN)
 
 #
-# build libbind?
-#
-AC_ARG_ENABLE(libbind,
-	[  --enable-libbind		build libbind [default=no]])
-
-case "$enable_libbind" in
-	yes)
-		LIBBIND=lib/bind
-		AC_SUBST(LIBBIND)
-		;;
-	no|'')
-		;;
-esac
-
-
-#
 # Here begins a very long section to determine the system's networking
-# capabilities.  The order of the tests is signficant.
+# capabilities.  The order of the tests is significant.
 #
 
 #
@@ -1211,16 +1391,16 @@ changequote([, ])
 #
 case "$host" in
 *-sco-sysv*uw*|*-*-sysv*UnixWare*|*-*-sysv*OpenUNIX*)
-        # UnixWare
+	# UnixWare
 	ISC_PLATFORM_NEEDNETINETIN6H="#define ISC_PLATFORM_NEEDNETINETIN6H 1"
 	LWRES_PLATFORM_NEEDNETINETIN6H="#define LWRES_PLATFORM_NEEDNETINETIN6H 1"
-        ISC_PLATFORM_FIXIN6ISADDR="#define ISC_PLATFORM_FIXIN6ISADDR 1"
+	ISC_PLATFORM_FIXIN6ISADDR="#define ISC_PLATFORM_FIXIN6ISADDR 1"
 	isc_netinetin6_hack="#include <netinet/in6.h>"
 	;;
 *)
 	ISC_PLATFORM_NEEDNETINETIN6H="#undef ISC_PLATFORM_NEEDNETINETIN6H"
 	LWRES_PLATFORM_NEEDNETINETIN6H="#undef LWRES_PLATFORM_NEEDNETINETIN6H"
-        ISC_PLATFORM_FIXIN6ISADDR="#undef ISC_PLATFORM_FIXIN6ISADDR"
+	ISC_PLATFORM_FIXIN6ISADDR="#undef ISC_PLATFORM_FIXIN6ISADDR"
 	isc_netinetin6_hack=""
 	;;
 esac
@@ -1389,17 +1569,17 @@ AC_TRY_RUN([
 #include <arpa/inet.h>
 main() {
 char a[16],b[64]; return(inet_ntop(AF_INET6, a, b, sizeof(b)) == (char*)0);}],
-        [AC_MSG_RESULT(yes)
-        ISC_PLATFORM_NEEDNTOP="#undef ISC_PLATFORM_NEEDNTOP"],
+	[AC_MSG_RESULT(yes)
+	ISC_PLATFORM_NEEDNTOP="#undef ISC_PLATFORM_NEEDNTOP"],
 
-        [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"])
+	[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"])
 
 
 # On NetBSD 1.4.2 and maybe others, inet_pton() incorrectly accepts
@@ -1415,38 +1595,23 @@ AC_TRY_RUN([
 main() { char a[16]; return (inet_pton(AF_INET, "1.2.3", a) == 1 ? 1 :
 			     inet_pton(AF_INET, "1.2.3.04", a) == 1 ? 1 : 
 			     (inet_pton(AF_INET6, "::1.2.3.4", a) != 1)); }],
-        [AC_MSG_RESULT(yes)
-        ISC_PLATFORM_NEEDPTON="#undef ISC_PLATFORM_NEEDPTON"],
-        [AC_MSG_RESULT(no)
-        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(yes)
+	ISC_PLATFORM_NEEDPTON="#undef ISC_PLATFORM_NEEDPTON"],
+	[AC_MSG_RESULT(no)
+	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_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([
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <arpa/inet.h>],
-        [struct in_addr in; inet_aton(0, &in); return (0);],
-        [AC_MSG_RESULT(yes)
-        ISC_PLATFORM_NEEDATON="#undef ISC_PLATFORM_NEEDATON"],
-
-        [AC_MSG_RESULT(no)
-        ISC_EXTRA_OBJS="$ISC_EXTRA_OBJS inet_aton.$O"
-        ISC_EXTRA_SRCS="$ISC_EXTRA_SRCS inet_aton.c"
-        ISC_PLATFORM_NEEDATON="#define ISC_PLATFORM_NEEDATON 1"])
+	[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_SUBST(ISC_PLATFORM_NEEDNTOP)
 AC_SUBST(ISC_PLATFORM_NEEDPTON)
-AC_SUBST(ISC_PLATFORM_NEEDATON)
 
 #
 # Look for a 4.4BSD-style sa_len member in struct sockaddr.
@@ -1496,7 +1661,7 @@ AC_TRY_COMPILE([
 [in_port_t port = 25; return (0);],
 	[AC_MSG_RESULT(yes)
 	ISC_PLATFORM_NEEDPORTT="#undef ISC_PLATFORM_NEEDPORTT"],
-        [AC_MSG_RESULT(no)
+	[AC_MSG_RESULT(no)
 	ISC_PLATFORM_NEEDPORTT="#define ISC_PLATFORM_NEEDPORTT 1"])
 AC_SUBST(ISC_PLATFORM_NEEDPORTT)
 
@@ -1600,53 +1765,36 @@ AC_TRY_COMPILE([
 AC_SUBST(ISC_LWRES_NEEDHERRNO)
 
 AC_CHECK_FUNC(getipnodebyname,
-        [ISC_LWRES_GETIPNODEPROTO="#undef ISC_LWRES_GETIPNODEPROTO"],
-        [ISC_LWRES_GETIPNODEPROTO="#define ISC_LWRES_GETIPNODEPROTO 1"])
+	[ISC_LWRES_GETIPNODEPROTO="#undef ISC_LWRES_GETIPNODEPROTO"],
+	[ISC_LWRES_GETIPNODEPROTO="#define ISC_LWRES_GETIPNODEPROTO 1"])
 AC_CHECK_FUNC(getnameinfo,
-        [ISC_LWRES_GETNAMEINFOPROTO="#undef ISC_LWRES_GETNAMEINFOPROTO"],
-        [ISC_LWRES_GETNAMEINFOPROTO="#define ISC_LWRES_GETNAMEINFOPROTO 1"])
+	[ISC_LWRES_GETNAMEINFOPROTO="#undef ISC_LWRES_GETNAMEINFOPROTO"],
+	[ISC_LWRES_GETNAMEINFOPROTO="#define ISC_LWRES_GETNAMEINFOPROTO 1"])
 AC_CHECK_FUNC(getaddrinfo,
-        [ISC_LWRES_GETADDRINFOPROTO="#undef ISC_LWRES_GETADDRINFOPROTO"
+	[ISC_LWRES_GETADDRINFOPROTO="#undef ISC_LWRES_GETADDRINFOPROTO"
 	AC_DEFINE(HAVE_GETADDRINFO)],
-        [ISC_LWRES_GETADDRINFOPROTO="#define ISC_LWRES_GETADDRINFOPROTO 1"])
+	[ISC_LWRES_GETADDRINFOPROTO="#define ISC_LWRES_GETADDRINFOPROTO 1"])
 AC_CHECK_FUNC(gai_strerror, AC_DEFINE(HAVE_GAISTRERROR))
 AC_SUBST(ISC_LWRES_GETIPNODEPROTO)
 AC_SUBST(ISC_LWRES_GETADDRINFOPROTO)
 AC_SUBST(ISC_LWRES_GETNAMEINFOPROTO)
 
 AC_ARG_ENABLE(getifaddrs,
-[  --enable-getifaddrs    Enable the use of getifaddrs() [[yes|no|glibc]].
-             glibc: Use getifaddrs() in glibc if you know it supports IPv6.],
+[  --enable-getifaddrs    Enable the use of getifaddrs() [[yes|no]].],
     want_getifaddrs="$enableval",  want_getifaddrs="yes")
 
-case $want_getifaddrs in
-yes|glibc)
-#
-# Do we have getifaddrs() ?
 #
-case $host in
-*-linux*)
-	# Some recent versions of glibc support getifaddrs() which does not
-	# provide AF_INET6 addresses while the function provided by the USAGI
-	# project handles the AF_INET6 case correctly.  We need to avoid
-	# using the former but prefer the latter unless overridden by
-	# --enable-getifaddrs=glibc.
-	if test $want_getifaddrs = glibc
-	then
-		AC_CHECK_FUNC(getifaddrs, AC_DEFINE(HAVE_GETIFADDRS))
-	else
-		save_LIBS="$LIBS"
-		LIBS="-L/usr/local/v6/lib $LIBS"
-		AC_CHECK_LIB(inet6, getifaddrs,
-			LIBS="$LIBS -linet6"
-			AC_DEFINE(HAVE_GETIFADDRS),
-			LIBS=${save_LIBS})
-	fi
-	;;
-*)
-	AC_CHECK_FUNC(getifaddrs, AC_DEFINE(HAVE_GETIFADDRS))
-	;;
-esac
+# This interface iteration code for getifaddrs() will fall back to using
+# /proc/net/if_inet6 if getifaddrs() in glibc doesn't return any IPv6
+# addresses.
+# 
+case $want_getifaddrs in
+glibc)
+AC_MSG_WARN("--enable-getifaddrs=glibc is no longer required")
+AC_CHECK_FUNC(getifaddrs, AC_DEFINE(HAVE_GETIFADDRS))
+;;
+yes)
+AC_CHECK_FUNC(getifaddrs, AC_DEFINE(HAVE_GETIFADDRS))
 ;;
 no)
 ;;
@@ -1750,11 +1898,37 @@ AC_CHECK_FUNC(strerror, AC_DEFINE(HAVE_STRERROR))
 AC_SUBST(ISC_EXTRA_OBJS)
 AC_SUBST(ISC_EXTRA_SRCS)
 
+#
+# Use our own SPNEGO implementation?
+#
+AC_ARG_ENABLE(isc-spnego,
+	[  --disable-isc-spnego		use SPNEGO from GSSAPI library])
+
+if test -n "$USE_GSSAPI"
+then
+	case "$enable_isc_spnego" in
+		yes|'')
+			USE_ISC_SPNEGO='-DUSE_ISC_SPNEGO'
+			DST_EXTRA_OBJS="$DST_EXTRA_OBJS spnego.$O"
+			DST_EXTRA_SRCS="$DST_EXTRA_SRCS spnego.c"
+			AC_MSG_RESULT(using SPNEGO from lib/dns)
+			;;
+		no)
+			AC_MSG_RESULT(using SPNEGO from GSSAPI library)
+			;;
+	esac
+fi
+
+AC_SUBST(USE_ISC_SPNEGO)
+
+AC_SUBST(DST_EXTRA_OBJS)
+AC_SUBST(DST_EXTRA_SRCS)
+
 # Determine the printf format characters to use when printing
 # values of type isc_int64_t. This will normally be "ll", but where
 # the compiler treats "long long" as a alias for "long" and printf
 # doesn't know about "long long" use "l".  Hopefully the sprintf
-# will produce a inconsistant result in the later case.  If the compiler
+# will produce a inconsistent 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
@@ -1790,13 +1964,23 @@ AC_SUBST(LWRES_PLATFORM_QUADFORMAT)
 #
 # Security Stuff
 #
-AC_CHECK_FUNC(chroot, AC_DEFINE(HAVE_CHROOT))
+# Note it is very recommended to *not* disable chroot(),
+# this is only because chroot() was made obsolete by Posix.
+AC_ARG_ENABLE(chroot,
+	[  --disable-chroot disable chroot])
+case "$enable_chroot" in
+	yes|'')
+		AC_CHECK_FUNCS(chroot)
+		;;
+	no)
+		;;
+esac
 AC_ARG_ENABLE(linux-caps,
 	[  --disable-linux-caps	disable linux capabilities])
 case "$enable_linux_caps" in
 	yes|'')
 		AC_CHECK_HEADERS(linux/capability.h sys/capability.h)
-		AC_CHECK_FUNCS(capset)
+		AC_CHECK_LIB(cap, cap_set_proc)
 		;;
 	no)
 		;;
@@ -1826,7 +2010,7 @@ esac
 #
 AC_CHECK_FUNC(tzset, AC_DEFINE(HAVE_TZSET))
 
-AC_MSG_CHECKING(for optarg decarartion)
+AC_MSG_CHECKING(for optarg declaration)
 AC_TRY_COMPILE([
 #include <unistd.h>
 ],
@@ -1953,7 +2137,7 @@ case "$host" in
 		hack_shutup_pthreadonceinit=yes
 		;;
 	*-solaris2.1[[0-9]])
-		hack_shutup_pthreadonceinit=yes
+		AC_TRY_COMPILE([ #include <pthread.h> ], [ static pthread_once_t once_test = { PTHREAD_ONCE_INIT }; ], [hack_shutup_pthreadonceinit=yes], )
 		;;
 esac
 
@@ -2008,11 +2192,11 @@ AC_CHECK_FUNC(if_nametoindex, ac_cv_have_if_nametoindex=yes,
 case $ac_cv_have_if_nametoindex in
 no)
 	case "$host" in
-  	*-hp-hpux*)
-  		AC_CHECK_LIB(ipv6, if_nametoindex,
+	*-hp-hpux*)
+		AC_CHECK_LIB(ipv6, if_nametoindex,
 				ac_cv_have_if_nametoindex=yes
 				LIBS="-lipv6 $LIBS",)
-  	;;
+	;;
 	esac
 esac
 case $ac_cv_have_if_nametoindex in
@@ -2025,12 +2209,14 @@ yes)
 esac
 AC_SUBST(ISC_PLATFORM_HAVEIFNAMETOINDEX)
 
+AC_CHECK_FUNCS(nanosleep)
+
 #
 # Machine architecture dependent features
 #
 AC_ARG_ENABLE(atomic,
 	[  --enable-atomic	enable machine specific atomic operations
-                        [[default=autodetect]]],
+			[[default=autodetect]]],
 			enable_atomic="$enableval",
 			enable_atomic="autodetect")
 case "$enable_atomic" in
@@ -2056,11 +2242,13 @@ main() {
 	exit((sizeof(void *) == 8) ? 0 : 1);
 }
 ],
-		[arch=x86_64],
+		[arch=x86_64
+		have_xaddq=yes],
 		[arch=x86_32],
-	        [arch=x86_32])
+		[arch=x86_32])
 	;;
-	x86_64-*)
+	x86_64-*|amd64-*)
+		have_xaddq=yes
 		arch=x86_64
 	;;
 	alpha*-*)
@@ -2165,7 +2353,14 @@ else
 	ISC_PLATFORM_HAVEATOMICSTORE="#undef ISC_PLATFORM_HAVEATOMICSTORE"
 fi
 
+if test "$have_xaddq" = "yes"; then
+        ISC_PLATFORM_HAVEXADDQ="#define ISC_PLATFORM_HAVEXADDQ 1"
+else
+        ISC_PLATFORM_HAVEXADDQ="#undef ISC_PLATFORM_HAVEXADDQ"
+fi
+
 AC_SUBST(ISC_PLATFORM_HAVEXADD)
+AC_SUBST(ISC_PLATFORM_HAVEXADDQ)
 AC_SUBST(ISC_PLATFORM_HAVECMPXCHG)
 AC_SUBST(ISC_PLATFORM_HAVEATOMICSTORE)
 
@@ -2178,6 +2373,25 @@ ISC_ARCH_DIR=$arch
 AC_SUBST(ISC_ARCH_DIR)
 
 #
+# Activate "rrset-order fixed" or not?
+#
+AC_ARG_ENABLE(fixed-rrset,
+	[  --enable-fixed-rrset        enable fixed rrset ordering
+			[[default=no]]],
+			enable_fixed="$enableval",
+			enable_fixed="no")
+case "$enable_fixed" in
+	yes)
+		AC_DEFINE(DNS_RDATASET_FIXED, 1,
+                          [Define to enable "rrset-order fixed" syntax.])
+		;;
+	no)
+		;;
+	*)
+		;;
+esac
+
+#
 #  The following sets up how non-blocking i/o is established.
 #  Sunos, cygwin and solaris 2.x (x<5) require special handling.
 #
@@ -2241,6 +2455,13 @@ AC_PATH_PROG(XMLLINT, xmllint, xmllint)
 AC_SUBST(XMLLINT)
 
 #
+# Look for Doxygen
+#
+
+AC_PATH_PROG(DOXYGEN, doxygen, doxygen)
+AC_SUBST(DOXYGEN)
+
+#
 # Subroutine for searching for an ordinary file (e.g., a stylesheet)
 # in a number of directories:
 #
@@ -2460,6 +2681,18 @@ BIND9_MAKE_RULES=$BIND9_TOP_BUILDDIR/make/rules
 BIND9_VERSION="VERSION=${MAJORVER}.${MINORVER}.${PATCHVER}${RELEASETYPE}${RELEASEVER}"
 AC_SUBST(BIND9_VERSION)
 
+if test -z "$ac_configure_args"; then
+	BIND9_CONFIGARGS="defaults"
+else
+	for a in $ac_configure_args
+	do
+		BIND9_CONFIGARGS="$BIND9_CONFIGARGS $a"
+	done
+fi
+BIND9_CONFIGARGS="`echo $BIND9_CONFIGARGS | sed 's/^ //'`"
+BIND9_CONFIGARGS="CONFIGARGS=${BIND9_CONFIGARGS}"
+AC_SUBST(BIND9_CONFIGARGS)
+
 AC_SUBST_FILE(LIBISC_API)
 LIBISC_API=$srcdir/lib/isc/api
 
@@ -2533,6 +2766,93 @@ else
 	BUILD_LIBS="$LIBS"
 fi
 
+NEWFLAGS=""
+for e in $BUILD_LDFLAGS ; do
+    case $e in
+	-L*)
+	    case $host_os in
+		netbsd*)
+		    ee=`echo $e | sed -e 's%^-L%-Wl,-rpath,%'`
+		    NEWFLAGS="$NEWFLAGS $e $ee"
+		    ;;
+		freebsd*)
+		    ee=`echo $e | sed -e 's%^-L%-Wl,-rpath,%'`
+		    NEWFLAGS="$NEWFLAGS $e $ee"
+		    ;;
+		solaris*)
+		    ee=`echo $e | sed -e 's%^-L%-R%'`
+		    NEWFLAGS="$NEWFLAGS $e $ee"
+		    ;;
+		*)
+		    NEWFLAGS="$NEWFLAGS $e"
+		    ;;
+		esac
+	    ;;
+	*)
+	    NEWFLAGS="$NEWFLAGS $e"
+	    ;;
+    esac
+done
+BUILD_LDFLAGS="$NEWFLAGS"
+
+NEWFLAGS=""
+for e in $DNS_GSSAPI_LIBS ; do
+    case $e in
+	-L*)
+	    case $host_os in
+		netbsd*)
+		    ee=`echo $e | sed -e 's%^-L%-Wl,-rpath,%'`
+		    NEWFLAGS="$NEWFLAGS $e $ee"
+		    ;;
+		freebsd*)
+		    ee=`echo $e | sed -e 's%^-L%-Wl,-rpath,%'`
+		    NEWFLAGS="$NEWFLAGS $e $ee"
+		    ;;
+		solaris*)
+		    ee=`echo $e | sed -e 's%^-L%-R%'`
+		    NEWFLAGS="$NEWFLAGS $e $ee"
+		    ;;
+		*)
+		    NEWFLAGS="$NEWFLAGS $e"
+		    ;;
+		esac
+	    ;;
+	*)
+	    NEWFLAGS="$NEWFLAGS $e"
+	    ;;
+    esac
+done
+DNS_GSSAPI_LIBS="$NEWFLAGS"
+
+NEWFLAGS=""
+for e in $DNS_CRYPTO_LIBS ; do
+    case $e in
+	-L*)
+	    case $host_os in
+		netbsd*)
+		    ee=`echo $e | sed -e 's%^-L%-Wl,-rpath,%'`
+		    NEWFLAGS="$NEWFLAGS $e $ee"
+		    ;;
+		freebsd*)
+		    ee=`echo $e | sed -e 's%^-L%-Wl,-rpath,%'`
+		    NEWFLAGS="$NEWFLAGS $e $ee"
+		    ;;
+		solaris*)
+		    ee=`echo $e | sed -e 's%^-L%-R%'`
+		    NEWFLAGS="$NEWFLAGS $e $ee"
+		    ;;
+		*)
+		    NEWFLAGS="$NEWFLAGS $e"
+		    ;;
+		esac
+	    ;;
+	*)
+	    NEWFLAGS="$NEWFLAGS $e"
+	    ;;
+    esac
+done
+DNS_CRYPTO_LIBS="$NEWFLAGS"
+
 AC_SUBST(BUILD_CC)
 AC_SUBST(BUILD_CFLAGS)
 AC_SUBST(BUILD_CPPFLAGS)
@@ -2547,7 +2867,7 @@ AC_SUBST(BUILD_LIBS)
 
 AC_CONFIG_COMMANDS(
 	[chmod],
-	[chmod a+x isc-config.sh])
+	[chmod a+x isc-config.sh doc/doxygen/doxygen-input-filter])
 
 #
 # Files to configure.  These are listed here because we used to
@@ -2633,6 +2953,9 @@ AC_CONFIG_FILES([
 	doc/xsl/isc-docbook-html.xsl
 	doc/xsl/isc-docbook-latex.xsl
 	doc/xsl/isc-manpage.xsl
+	doc/doxygen/Doxyfile
+	doc/doxygen/Makefile
+	doc/doxygen/doxygen-input-filter
 ])
 
 #
diff --git a/contrib/bind9/doc/Makefile.in b/contrib/bind9/doc/Makefile.in
index f307f41..14d35bc 100644
--- a/contrib/bind9/doc/Makefile.in
+++ b/contrib/bind9/doc/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2000, 2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.5.18.2 2005/07/23 04:35:12 marka Exp $
+# $Id: Makefile.in,v 1.11 2007/06/19 23:47:13 tbox 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 xsl
+SUBDIRS = arm misc xsl doxygen
 TARGETS =
 
 @BIND9_MAKE_RULES@
diff --git a/contrib/bind9/doc/arm/Bv9ARM-book.xml b/contrib/bind9/doc/arm/Bv9ARM-book.xml
index cdcb9d8..f3bfe0d 100644
--- a/contrib/bind9/doc/arm/Bv9ARM-book.xml
+++ b/contrib/bind9/doc/arm/Bv9ARM-book.xml
@@ -1,8 +1,8 @@
 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-               "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+              "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
 	       [<!ENTITY mdash "&#8212;">]>
 <!--
- - Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003  Internet Software Consortium.
  -
  - Permission to use, copy, modify, and/or distribute this software for any
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- File: $Id: Bv9ARM-book.xml,v 1.241.18.97 2008/10/17 19:37:35 jreed Exp $ -->
+<!-- File: $Id: Bv9ARM-book.xml,v 1.380.14.14 2009/04/02 15:30:12 jreed Exp $ -->
 <book xmlns:xi="http://www.w3.org/2001/XInclude">
   <title>BIND 9 Administrator Reference Manual</title>
 
@@ -29,6 +29,7 @@
       <year>2006</year>
       <year>2007</year>
       <year>2008</year>
+      <year>2009</year>
       <holder>Internet Systems Consortium, Inc. ("ISC")</holder>
     </copyright>
     <copyright>
@@ -67,30 +68,30 @@
       </para>
 
       <para>
-        This version of the manual corresponds to BIND version 9.4.
+        This version of the manual corresponds to BIND version 9.6.
       </para>
 
     </sect1>
     <sect1>
       <title>Organization of This Document</title>
       <para>
-        In this document, <emphasis>Section 1</emphasis> introduces
-        the basic <acronym>DNS</acronym> and <acronym>BIND</acronym> concepts. <emphasis>Section 2</emphasis>
+        In this document, <emphasis>Chapter 1</emphasis> introduces
+        the basic <acronym>DNS</acronym> and <acronym>BIND</acronym> concepts. <emphasis>Chapter 2</emphasis>
         describes resource requirements for running <acronym>BIND</acronym> in various
-        environments. Information in <emphasis>Section 3</emphasis> is
+        environments. Information in <emphasis>Chapter 3</emphasis> is
         <emphasis>task-oriented</emphasis> in its presentation and is
         organized functionally, to aid in the process of installing the
         <acronym>BIND</acronym> 9 software. The task-oriented
         section is followed by
-        <emphasis>Section 4</emphasis>, which contains more advanced
+        <emphasis>Chapter 4</emphasis>, which contains more advanced
         concepts that the system administrator may need for implementing
-        certain options. <emphasis>Section 5</emphasis>
+        certain options. <emphasis>Chapter 5</emphasis>
         describes the <acronym>BIND</acronym> 9 lightweight
-        resolver.  The contents of <emphasis>Section 6</emphasis> are
+        resolver.  The contents of <emphasis>Chapter 6</emphasis> are
         organized as in a reference manual to aid in the ongoing
-        maintenance of the software. <emphasis>Section 7</emphasis> addresses
+        maintenance of the software. <emphasis>Chapter 7</emphasis> addresses
         security considerations, and
-        <emphasis>Section 8</emphasis> contains troubleshooting help. The
+        <emphasis>Chapter 8</emphasis> contains troubleshooting help. The
         main body of the document is followed by several
         <emphasis>appendices</emphasis> which contain useful reference
         information, such as a <emphasis>bibliography</emphasis> and
@@ -253,8 +254,10 @@
           more <emphasis>name servers</emphasis> and interprets the responses.
           The <acronym>BIND</acronym> 9 software distribution
           contains a
-          name server, <command>named</command>, and two resolver
-          libraries, <command>liblwres</command> and <command>libbind</command>.
+          name server, <command>named</command>, and a resolver
+          library, <command>liblwres</command>.  The older
+          <command>libbind</command> resolver library is also available
+          from ISC as a separate download.
         </para>
 
         </sect2><sect2>
@@ -639,11 +642,13 @@
       <title>Supported Operating Systems</title>
       <para>
         ISC <acronym>BIND</acronym> 9 compiles and runs on a large
-        number of Unix-like operating systems, and on some versions of
-        Microsoft Windows including Windows XP, Windows 2003, and
-        Windows 2008.  For an up-to-date list of supported systems,
-        see the README file in the top level directory of the BIND 9
-        source distribution.
+        number
+        of Unix-like operating systems and on NT-derived versions of
+        Microsoft Windows such as Windows 2000 and Windows XP.  For an
+        up-to-date
+        list of supported systems, see the README file in the top level
+        directory
+        of the BIND 9 source distribution.
       </para>
     </sect1>
   </chapter>
@@ -651,7 +656,7 @@
   <chapter id="Bv9ARM.ch03">
     <title>Name Server Configuration</title>
     <para>
-      In this section we provide some suggested configurations along
+      In this chapter we provide some suggested configurations along
       with guidelines for their use.  We suggest reasonable values for
       certain option settings.
     </para>
@@ -928,7 +933,7 @@ zone "eng.example.com" {
                   <arg>%<replaceable>comment</replaceable></arg>
                 </cmdsynopsis>
                 <para>
-                  The usual simple use of dig will take the form
+                  The usual simple use of <command>dig</command> will take the form
                 </para>
                 <simpara>
                   <command>dig @server domain query-type query-class</command>
@@ -1068,7 +1073,7 @@ zone "eng.example.com" {
                 </cmdsynopsis>
               </listitem>
             </varlistentry>
-	    <varlistentry id="named-compilezone" xreflabel="Zone Compilation aplication">
+	    <varlistentry id="named-compilezone" xreflabel="Zone Compilation application">
 	      <term><command>named-compilezone</command></term>
 	      <listitem>
 		<para>
@@ -1271,8 +1276,8 @@ zone "eng.example.com" {
                         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.
-			If -p is specified named's process id is returned.
-			This allows an external process to determine when named
+			If <option>-p</option> is specified <command>named</command>'s process id is returned.
+			This allows an external process to determine when <command>named</command>
 			had completed stopping.
                       </para>
                     </listitem>
@@ -1286,8 +1291,8 @@ zone "eng.example.com" {
                         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.
-			If -p is specified named's process id is returned.
-			This allows an external process to determine when named
+			If <option>-p</option> is specified <command>named</command>'s process id is returned.
+			This allows an external process to determine when <command>named</command>
 			had completed halting.
                       </para>
                     </listitem>
@@ -1356,12 +1361,27 @@ zone "eng.example.com" {
                     <term><userinput>recursing</userinput></term>
                     <listitem>
                       <para>
-                        Dump the list of queries named is currently recursing
+                        Dump the list of queries <command>named</command> is currently recursing
                         on.
                       </para>
                     </listitem>
                   </varlistentry>
 
+                  <varlistentry>
+                    <term><userinput>validation
+                        <optional>on|off</optional>
+                        <optional><replaceable>view ...</replaceable></optional>
+                    </userinput></term>
+                    <listitem>
+                      <para>
+                        Enable or disable DNSSEC validation.
+                        Note <command>dnssec-enable</command> also needs to be
+                        set to <userinput>yes</userinput> to be effective.
+                        It defaults to enabled.
+                      </para>
+                    </listitem>
+                  </varlistentry>
+
                 </variablelist>
 
                 <para>
@@ -1426,7 +1446,7 @@ zone "eng.example.com" {
                   with
                   <command>named</command>.  Its syntax is
                   identical to the
-                  <command>key</command> statement in named.conf.
+                  <command>key</command> statement in <filename>named.conf</filename>.
                   The keyword <userinput>key</userinput> is
                   followed by a key name, which must be a valid
                   domain name, though it need not actually be hierarchical;
@@ -1599,10 +1619,10 @@ controls {
       </para>
 
       <note>
-	As a slave zone can also be a master to other slaves, named,
+	As a slave zone can also be a master to other slaves, <command>named</command>,
         by default, sends <command>NOTIFY</command> messages for every zone
 	it loads.  Specifying <command>notify master-only;</command> will
-	cause named to only send <command>NOTIFY</command> for master
+	cause <command>named</command> to only send <command>NOTIFY</command> for master
 	zones that it loads.
       </note>
 
@@ -1619,18 +1639,23 @@ controls {
       </para>
 
       <para>
-        Dynamic update is enabled by
-        including an <command>allow-update</command> or
-        <command>update-policy</command> clause in the
-        <command>zone</command> statement.
+	Dynamic update is enabled by including an
+	<command>allow-update</command> or <command>update-policy</command>
+	clause in the <command>zone</command> statement.  The
+	<command>tkey-gssapi-credential</command> and
+	<command>tkey-domain</command> clauses in the
+	<command>options</command>        statement enable the
+	server to negotiate keys that can be matched against those
+	in <command>update-policy</command> or
+	<command>allow-update</command>.
       </para>
 
       <para>
-        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.
+	Updating of secure zones (zones using DNSSEC) follows RFC
+	3007: RRSIG, NSEC and NSEC3 records affected by updates are
+	automatically regenerated by the server using an online
+	zone key.  Update authorization is based on transaction
+	signatures and an explicit server policy.
       </para>
 
       <sect2 id="journal">
@@ -2086,7 +2111,7 @@ key host1-host2. {
 </programlisting>
 
         <para>
-          The algorithm, hmac-md5, is the only one supported by <acronym>BIND</acronym>.
+          The algorithm, <literal>hmac-md5</literal>, is the only one supported by <acronym>BIND</acronym>.
           The secret is the one generated above. Since this is a secret, it
           is recommended that either <filename>named.conf</filename> be non-world
           readable, or the key directive be added to a non-world readable
@@ -2146,22 +2171,23 @@ server 10.1.2.3 {
           be denoted <command>key host1-host2.</command>
         </para>
         <para>
-          An example of an allow-update directive would be:
+          An example of an <command>allow-update</command> directive would be:
         </para>
 
 <programlisting>
 allow-update { key host1-host2. ;};
 </programlisting>
 
-        <para>
-          This allows dynamic updates to succeed only if the request
-          was signed by a key named
-          "<command>host1-host2.</command>".
-        </para>
 	<para>
-          You may want to read about the more
-          powerful <command>update-policy</command> statement in <xref linkend="dynamic_update_policies"/>.
-        </para>
+	  This allows dynamic updates to succeed only if the request
+	  was signed by a key named "<command>host1-host2.</command>".
+	</para>
+
+	<para>
+	  You may want to read about the more powerful
+	  <command>update-policy</command> statement in
+	  <xref linkend="dynamic_update_policies"/>.
+	</para>
 
       </sect2>
       <sect2>
@@ -2235,7 +2261,7 @@ allow-update { key host1-host2. ;};
 
       <para>
         <acronym>BIND</acronym> 9 partially supports DNSSEC SIG(0)
-            transaction signatures as specified in RFC 2535 and RFC2931.
+            transaction signatures as specified in RFC 2535 and RFC 2931.
         SIG(0)
         uses public/private keys to authenticate messages.  Access control
         is performed in the same manner as TSIG keys; privileges can be
@@ -2351,6 +2377,12 @@ allow-update { key host1-host2. ;};
         </para>
 
         <para>
+          The <command>dnssec-keyfromlabel</command> program is used
+          to get a key pair from a crypto hardware and build the key
+          files. Its usage is similar to <command>dnssec-keygen</command>.
+        </para>
+
+        <para>
           The public keys should be inserted into the zone file by
           including the <filename>.key</filename> files using
           <command>$INCLUDE</command> statements.
@@ -2360,23 +2392,21 @@ allow-update { key host1-host2. ;};
       <sect2>
         <title>Signing the Zone</title>
 
-        <para>
-          The <command>dnssec-signzone</command> program is used
-          to
-          sign a zone.
-        </para>
+	<para>
+	  The <command>dnssec-signzone</command> program is used
+	  to sign a zone.
+	</para>
 
-        <para>
-          Any <filename>keyset</filename> files corresponding
-          to secure subzones should be present.  The zone signer will
-          generate <literal>NSEC</literal> and <literal>RRSIG</literal>
-          records for the zone, as well as <literal>DS</literal>
-          for
-          the child zones if <literal>'-d'</literal> is specified.
-                If <literal>'-d'</literal> is not specified, then
-          DS RRsets for
-          the secure child zones need to be added manually.
-        </para>
+	<para>
+	  Any <filename>keyset</filename> files corresponding to
+	  secure subzones should be present.  The zone signer will
+	  generate <literal>NSEC</literal>, <literal>NSEC3</literal>
+	  and <literal>RRSIG</literal> records for the zone, as
+	  well as <literal>DS</literal> for the child zones if
+	  <literal>'-g'</literal> is specified.  If <literal>'-g'</literal>
+	  is not specified, then DS RRsets for the secure child
+	  zones need to be added manually.
+	</para>
 
         <para>
           The following command signs the zone, assuming it is in a
@@ -2452,7 +2482,7 @@ allow-update { key host1-host2. ;};
 	  more public keys for the root.  This allows answers from
 	  outside the organization to be validated.  It will also
 	  have several keys for parts of the namespace the organization
-	  controls.  These are here to ensure that named is immune
+	  controls.  These are here to ensure that <command>named</command> is immune
 	  to compromises in the DNSSEC components of the security
 	  of parent zones.
 	</para>
@@ -2791,33 +2821,29 @@ $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
                   <varname>ip6_addr</varname>
                 </para>
               </entry>
-              <entry colname="2">
-                <para>
-                  An IPv6 address, such as <command>2001:db8::1234</command>.
-                  IPv6 scoped addresses that have ambiguity on their scope
-                  zones must be
-                  disambiguated by an appropriate zone ID with the percent
-                  character
-                  (`%') as delimiter.
-                  It is strongly recommended to use string zone names rather
-                  than
-                  numeric identifiers, in order to be robust against system
-                  configuration changes.
-                  However, since there is no standard mapping for such names
-                  and
-                  identifier values, currently only interface names as link
-                  identifiers
-                  are supported, assuming one-to-one mapping between
-                  interfaces and links.
-                  For example, a link-local address <command>fe80::1</command> on the
-                  link attached to the interface <command>ne0</command>
-                  can be specified as <command>fe80::1%ne0</command>.
-                  Note that on most systems link-local addresses always have
-                  the
-                  ambiguity, and need to be disambiguated.
-                </para>
-              </entry>
-            </row>
+	      <entry colname="2">
+		<para>
+		  An IPv6 address, such as <command>2001:db8::1234</command>.
+		  IPv6 scoped addresses that have ambiguity on their
+		  scope zones must be disambiguated by an appropriate
+		  zone ID with the percent character (`%') as
+		  delimiter.  It is strongly recommended to use
+		  string zone names rather than numeric identifiers,
+		  in order to be robust against system configuration
+		  changes.  However, since there is no standard
+		  mapping for such names and identifier values,
+		  currently only interface names as link identifiers
+		  are supported, assuming one-to-one mapping between
+		  interfaces and links.  For example, a link-local
+		  address <command>fe80::1</command> on the link
+		  attached to the interface <command>ne0</command>
+		  can be specified as <command>fe80::1%ne0</command>.
+		  Note that on most systems link-local addresses
+		  always have the ambiguity, and need to be
+		  disambiguated.
+		</para>
+	      </entry>
+	    </row>
             <row rowsep="0">
               <entry colname="1">
                 <para>
@@ -2867,6 +2893,11 @@ $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
                   netmask <command>255.0.0.0</command> and <command>1.2.3.0/28</command> is
                   network <command>1.2.3.0</command> with netmask <command>255.255.255.240</command>.
                 </para>
+                <para>
+		  When specifying a prefix involving a IPv6 scoped address
+		  the scope may be omitted.  In that case the prefix will
+		  match packets from any scope.
+                </para>
               </entry>
             </row>
             <row rowsep="0">
@@ -3042,9 +3073,8 @@ $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
             Address match lists are primarily used to determine access
             control for various server operations. They are also used in
             the <command>listen-on</command> and <command>sortlist</command>
-            statements. The elements
-            which constitute an address match list can be any of the
-            following:
+            statements. The elements which constitute an address match
+            list can be any of the following:
           </para>
           <itemizedlist>
             <listitem>
@@ -3072,28 +3102,30 @@ $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
           <para>
             Elements can be negated with a leading exclamation mark (`!'),
             and the match list names "any", "none", "localhost", and
-            "localnets"
-            are predefined. More information on those names can be found in
-            the description of the acl statement.
+            "localnets" are predefined. More information on those names
+            can be found in the description of the acl statement.
           </para>
 
           <para>
             The addition of the key clause made the name of this syntactic
             element something of a misnomer, since security keys can be used
             to validate access without regard to a host or network address.
-            Nonetheless,
-            the term "address match list" is still used throughout the
-            documentation.
+            Nonetheless, the term "address match list" is still used
+            throughout the documentation.
           </para>
 
           <para>
             When a given IP address or prefix is compared to an address
-            match list, the list is traversed in order until an element
-            matches.
+            match list, the comparison takes place in approximately O(1)
+            time.  However, key comparisons require that the list of keys
+            be traversed until a matching key is found, and therefore may
+            be somewhat slower.
+          </para>
+
+          <para>
             The interpretation of a match depends on whether the list is being
-            used
-            for access control, defining listen-on ports, or in a sortlist,
-            and whether the element was negated.
+            used for access control, defining <command>listen-on</command> ports, or in a
+            <command>sortlist</command>, and whether the element was negated.
           </para>
 
 	  <para>
@@ -3101,30 +3133,36 @@ $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
 	    allows access and a negated match denies access. If
 	    there is no match, access is denied. The clauses
 	    <command>allow-notify</command>,
+	    <command>allow-recursion</command>,
+	    <command>allow-recursion-on</command>,
 	    <command>allow-query</command>,
+	    <command>allow-query-on</command>,
 	    <command>allow-query-cache</command>,
+	    <command>allow-query-cache-on</command>,
 	    <command>allow-transfer</command>,
 	    <command>allow-update</command>,
 	    <command>allow-update-forwarding</command>, and
 	    <command>blackhole</command> all use address match
-	    lists.  Similarly, the listen-on option will cause the
-	    server to not accept queries on any of the machine's
+	    lists.  Similarly, the <command>listen-on</command> option will cause the
+	    server to refuse queries on any of the machine's
 	    addresses which do not match the list.
 	  </para>
 
           <para>
-            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
-            <command>1.2.3/24; ! 1.2.3.13;</command> the 1.2.3.13
-            element is
-            completely useless because the algorithm will match any lookup for
-            1.2.3.13 to the 1.2.3/24 element.
-            Using <command>! 1.2.3.13; 1.2.3/24</command> fixes
-            that problem by having 1.2.3.13 blocked by the negation but all
-            other 1.2.3.* hosts fall through.
+            Order of insertion is significant.  If more than one element
+            in an ACL is found to match a given IP address or prefix,
+            preference will be given to the one that came
+            <emphasis>first</emphasis> in the ACL definition.
+            Because of this first-match behavior, an element that
+            defines a subset of another element in the list should
+            come before the broader element, regardless of whether
+            either is negated. For example, in
+            <command>1.2.3/24; ! 1.2.3.13;</command>
+            the 1.2.3.13 element is completely useless because the
+            algorithm will match any lookup for 1.2.3.13 to the 1.2.3/24
+            element.  Using <command>! 1.2.3.13; 1.2.3/24</command> fixes
+            that problem by having 1.2.3.13 blocked by the negation, but
+            all other 1.2.3.* hosts fall through.
           </para>
         </sect3>
       </sect2>
@@ -3180,8 +3218,6 @@ $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
             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.
-          </para>
-          <para>
             For example:
           </para>
           <para>
@@ -3197,8 +3233,6 @@ $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
             with the character <literal>#</literal> (number sign)
             and continue to the end of the
             physical line, as in C++ comments.
-          </para>
-          <para>
             For example:
           </para>
 
@@ -3344,6 +3378,17 @@ $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
             </row>
             <row rowsep="0">
               <entry colname="1">
+                <para><command>statistics-channels</command></para>
+              </entry>
+              <entry colname="2">
+                <para>
+		  declares communication channels to get access to
+		  <command>named</command> statistics.
+                </para>
+              </entry>
+            </row>
+            <row rowsep="0">
+              <entry colname="1">
                 <para><command>trusted-keys</command></para>
               </entry>
               <entry colname="2">
@@ -3405,8 +3450,7 @@ $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
         <para>
           Note that an address match list's name must be defined
           with <command>acl</command> before it can be used
-          elsewhere; no
-          forward references are allowed.
+          elsewhere; no forward references are allowed.
         </para>
 
         <para>
@@ -3688,7 +3732,7 @@ $ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
 
 <programlisting><command>logging</command> {
    [ <command>channel</command> <replaceable>channel_name</replaceable> {
-     ( <command>file</command> <replaceable>path name</replaceable>
+     ( <command>file</command> <replaceable>path_name</replaceable>
          [ <command>versions</command> ( <replaceable>number</replaceable> | <command>unlimited</command> ) ]
          [ <command>size</command> <replaceable>size spec</replaceable> ]
        | <command>syslog</command> <replaceable>syslog_facility</replaceable>
@@ -3922,7 +3966,7 @@ notrace</command>. All debugging messages in the server have a debug
             the date and time will be logged. <command>print-time</command> may
             be specified for a <command>syslog</command> channel,
             but is usually
-            pointless since <command>syslog</command> also prints
+            pointless since <command>syslog</command> also logs
             the date and
             time. If <command>print-category</command> is
             requested, then the
@@ -4168,7 +4212,7 @@ category notify { null; };
                   </entry>
                   <entry colname="2">
                     <para>
-                      Messages that named was unable to determine the
+                      Messages that <command>named</command> was unable to determine the
                       class of or for which there was no matching <command>view</command>.
                       A one line summary is also logged to the <command>client</command> category.
                       This category is best sent to a file or stderr, by
@@ -4220,15 +4264,18 @@ category notify { null; };
                       enable query logging unless <command>querylog</command> option has been
                       specified.
                     </para>
-                    <para>
-                      The query log entry reports the client's IP address and
-                      port number, and 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>
+
+		    <para>
+		      The query log entry reports the client's IP
+		      address and port number, and the query name,
+		      class and type.  It also reports whether the
+		      Recursion Desired flag was set (+ if set, -
+		      if not set), if the query was signed (S),
+		      EDNS was in use (E), if DO (DNSSEC Ok) was
+		      set (D), or if CD (Checking Disabled) was set
+		      (C).
+		    </para>
+
                     <para>
                       <computeroutput>client 127.0.0.1#62536: query: www.example.com IN AAAA +SE</computeroutput>
                     </para>
@@ -4239,6 +4286,17 @@ category notify { null; };
                 </row>
                 <row rowsep="0">
                   <entry colname="1">
+                    <para><command>query-errors</command></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+                      Information about queries that resulted in some
+                      failure.
+		    </para>
+		  </entry>
+		</row>
+                <row rowsep="0">
+                  <entry colname="1">
                     <para><command>dispatch</command></para>
                   </entry>
                   <entry colname="2">
@@ -4277,7 +4335,7 @@ category notify { null; };
                   </entry>
                   <entry colname="2">
                     <para>
-                      Delegation only.  Logs queries that have have
+                      Delegation only.  Logs queries that have
                       been forced to NXDOMAIN as the result of a
                       delegation-only zone or
                       a <command>delegation-only</command> in a
@@ -4285,10 +4343,264 @@ category notify { null; };
                     </para>
                   </entry>
                 </row>
-              </tbody>
-            </tgroup>
-          </informaltable>
-        </sect3>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><command>edns-disabled</command></para>
+                  </entry>
+		  <entry colname="2">
+		    <para>
+		      Log queries that have been forced to use plain
+		      DNS due to timeouts.  This is often due to
+		      the remote servers not being RFC 1034 compliant
+		      (not always returning FORMERR or similar to
+		      EDNS queries and other extensions to the DNS
+		      when they are not understood).  In other words, this is
+		      targeted at servers that fail to respond to
+		      DNS queries that they don't understand.
+		    </para>
+		    <para>
+		      Note: the log message can also be due to
+		      packet loss.  Before reporting servers for
+		      non-RFC 1034 compliance they should be re-tested
+		      to determine the nature of the non-compliance.
+		      This testing should prevent or reduce the
+		      number of false-positive reports.
+		    </para>
+		    <para>
+		      Note: eventually <command>named</command> will have to stop
+		      treating such timeouts as due to RFC 1034 non
+		      compliance and start treating it as plain
+		      packet loss.  Falsely classifying packet
+		      loss as due to RFC 1034 non compliance impacts
+		      on DNSSEC validation which requires EDNS for
+		      the DNSSEC records to be returned.
+		    </para>
+		  </entry>
+		</row>
+	      </tbody>
+	    </tgroup>
+	  </informaltable>
+	</sect3>
+	<sect3>
+	  <title>The <command>query-errors</command> Category</title>
+	  <para>
+	    The <command>query-errors</command> category is
+	    specifically intended for debugging purposes: To identify
+	    why and how specific queries result in responses which
+	    indicate an error.
+	    Messages of this category are therefore only logged
+	    with <command>debug</command> levels.
+	  </para>
+
+	  <para>
+	    At the debug levels of 1 or higher, each response with the
+	    rcode of SERVFAIL is logged as follows:
+	  </para>
+	  <para>
+	    <computeroutput>client 127.0.0.1#61502: query failed (SERVFAIL) for www.example.com/IN/AAAA at query.c:3880</computeroutput>
+	  </para>
+	  <para>
+	    This means an error resulting in SERVFAIL was
+	    detected at line 3880 of source file
+	    <filename>query.c</filename>.
+	    Log messages of this level will particularly
+	    help identify the cause of SERVFAIL for an
+	    authoritative server.
+	  </para>
+	  <para>
+	    At the debug levels of 2 or higher, detailed context
+	    information of recursive resolutions that resulted in
+	    SERVFAIL is logged.
+	    The log message will look like as follows:
+	  </para>
+	  <para>
+	    <computeroutput>fetch completed at resolver.c:2970 for www.example.com/A in 30.000183: timed out/success [domain:example.com,referral:2,restart:7,qrysent:8,timeout:5,lame:0,neterr:0,badresp:1,adberr:0,findfail:0,valfail:0]</computeroutput>
+	  </para>
+	  <para>
+	    The first part before the colon shows that a recursive
+	    resolution for AAAA records of www.example.com completed
+	    in 30.000183 seconds and the final result that led to the
+	    SERVFAIL was determined at line 2970 of source file
+	    <filename>resolver.c</filename>.
+	  </para>
+	  <para>
+	    The following part shows the detected final result and the
+	    latest result of DNSSEC validation.
+	    The latter is always success when no validation attempt
+	    is made.
+	    In this example, this query resulted in SERVFAIL probably
+	    because all name servers are down or unreachable, leading
+	    to a timeout in 30 seconds.
+	    DNSSEC validation was probably not attempted.
+	  </para>
+	  <para>
+	    The last part enclosed in square brackets shows statistics
+	    information collected for this particular resolution
+	    attempt.
+	    The <varname>domain</varname> field shows the deepest zone
+	    that the resolver reached;
+	    it is the zone where the error was finally detected.
+	    The meaning of the other fields is summarized in the
+	    following table.
+	  </para>
+
+          <informaltable colsep="0" rowsep="0">
+            <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
+              <colspec colname="1" colnum="1" colsep="0" />
+              <colspec colname="2" colnum="2" colsep="0" />
+              <tbody>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><varname>referral</varname></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+		      The number of referrals the resolver received
+		      throughout the resolution process.
+		      In the above example this is 2, which are most
+		      likely com and example.com.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><varname>restart</varname></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+		      The number of cycles that the resolver tried
+		      remote servers at the <varname>domain</varname>
+		      zone.
+		      In each cycle the resolver sends one query
+		      (possibly resending it, depending on the response)
+		      to each known name server of
+		      the <varname>domain</varname> zone.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><varname>qrysent</varname></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+		      The number of queries the resolver sent at the
+		      <varname>domain</varname> zone.
+                    </para>
+                  </entry>
+                </row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><varname>timeout</varname></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+		      The number of timeouts since the resolver
+		      received the last response.
+		    </para>
+		  </entry>
+		</row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><varname>lame</varname></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+		      The number of lame servers the resolver detected
+		      at the <varname>domain</varname> zone.
+		      A server is detected to be lame either by an
+		      invalid response or as a result of lookup in
+		      BIND9's address database (ADB), where lame
+		      servers are cached.
+		    </para>
+		  </entry>
+		</row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><varname>neterr</varname></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+		      The number of erroneous results that the
+		      resolver encountered in sending queries
+		      at the <varname>domain</varname> zone.
+		      One common case is the remote server is
+		      unreachable and the resolver receives an ICMP
+		      unreachable error message.
+		    </para>
+		  </entry>
+		</row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><varname>badresp</varname></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+		      The number of unexpected responses (other than
+		      <varname>lame</varname>) to queries sent by the
+		      resolver at the <varname>domain</varname> zone.
+		    </para>
+		  </entry>
+		</row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><varname>adberr</varname></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+		      Failures in finding remote server addresses
+		      of the <varname>domain</varname> zone in the ADB.
+		      One common case of this is that the remote
+		      server's name does not have any address records.
+		    </para>
+		  </entry>
+		</row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><varname>findfail</varname></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+		      Failures of resolving remote server addresses.
+		      This is a total number of failures throughout
+		      the resolution process.
+		    </para>
+		  </entry>
+		</row>
+                <row rowsep="0">
+                  <entry colname="1">
+                    <para><varname>valfail</varname></para>
+                  </entry>
+                  <entry colname="2">
+                    <para>
+		      Failures of DNSSEC validation.
+		      Validation failures are counted throughout
+		      the resolution process (not limited to
+		      the <varname>domain</varname> zone), but should
+		      only happen in <varname>domain</varname>.
+		    </para>
+		  </entry>
+		</row>
+	      </tbody>
+	    </tgroup>
+	  </informaltable>
+	  <para>
+	    At the debug levels of 3 or higher, the same messages
+	    as those at the debug 1 level are logged for other errors
+	    than SERVFAIL.
+	    Note that negative responses such as NXDOMAIN are not
+	    regarded as errors here.
+	  </para>
+	  <para>
+	    At the debug levels of 4 or higher, the same messages
+	    as those at the debug 2 level are logged for other errors
+	    than SERVFAIL.
+	    Unlike the above case of level 3, messages are logged for
+	    negative responses.
+	    This is because any unexpected results can be difficult to
+	    debug in the recursion case.
+	  </para>
+	</sect3>
       </sect2>
 
       <sect2>
@@ -4396,10 +4708,12 @@ category notify { null; };
     <optional> directory <replaceable>path_name</replaceable>; </optional>
     <optional> key-directory <replaceable>path_name</replaceable>; </optional>
     <optional> named-xfer <replaceable>path_name</replaceable>; </optional>
+    <optional> tkey-gssapi-credential <replaceable>principal</replaceable>; </optional>
     <optional> tkey-domain <replaceable>domainname</replaceable>; </optional>
     <optional> tkey-dhkey <replaceable>key_name</replaceable> <replaceable>key_tag</replaceable>; </optional>
     <optional> cache-file <replaceable>path_name</replaceable>; </optional>
     <optional> dump-file <replaceable>path_name</replaceable>; </optional>
+    <optional> memstatistics <replaceable>yes_or_no</replaceable>; </optional>
     <optional> memstatistics-file <replaceable>path_name</replaceable>; </optional>
     <optional> pid-file <replaceable>path_name</replaceable>; </optional>
     <optional> recursing-file <replaceable>path_name</replaceable>; </optional>
@@ -4421,6 +4735,7 @@ category notify { null; };
     <optional> rfc2308-type1 <replaceable>yes_or_no</replaceable>; </optional>
     <optional> use-id-pool <replaceable>yes_or_no</replaceable>; </optional>
     <optional> maintain-ixfr-base <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> ixfr-from-differences (<replaceable>yes_or_no</replaceable> | <constant>master</constant> | <constant>slave</constant>); </optional>
     <optional> dnssec-enable <replaceable>yes_or_no</replaceable>; </optional>
     <optional> dnssec-validation <replaceable>yes_or_no</replaceable>; </optional>
     <optional> dnssec-lookaside <replaceable>domain</replaceable> trust-anchor <replaceable>domain</replaceable>; </optional>
@@ -4442,12 +4757,16 @@ category notify { null; };
     <optional> check-sibling <replaceable>yes_or_no</replaceable>; </optional>
     <optional> allow-notify { <replaceable>address_match_list</replaceable> }; </optional>
     <optional> allow-query { <replaceable>address_match_list</replaceable> }; </optional>
+    <optional> allow-query-on { <replaceable>address_match_list</replaceable> }; </optional>
     <optional> allow-query-cache { <replaceable>address_match_list</replaceable> }; </optional>
+    <optional> allow-query-cache-on { <replaceable>address_match_list</replaceable> }; </optional>
     <optional> allow-transfer { <replaceable>address_match_list</replaceable> }; </optional>
     <optional> allow-recursion { <replaceable>address_match_list</replaceable> }; </optional>
+    <optional> allow-recursion-on { <replaceable>address_match_list</replaceable> }; </optional>
     <optional> allow-update { <replaceable>address_match_list</replaceable> }; </optional>
     <optional> allow-update-forwarding { <replaceable>address_match_list</replaceable> }; </optional>
     <optional> update-check-ksk <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> try-tcp-refresh <replaceable>yes_or_no</replaceable>; </optional>
     <optional> allow-v6-synthesis { <replaceable>address_match_list</replaceable> }; </optional>
     <optional> blackhole { <replaceable>address_match_list</replaceable> }; </optional>
     <optional> use-v4-udp-ports { <replaceable>port_list</replaceable> }; </optional>
@@ -4464,6 +4783,9 @@ category notify { null; };
 	<optional> port ( <replaceable>ip_port</replaceable> | <replaceable>*</replaceable> ) </optional> | 
 	<optional> address ( <replaceable>ip6_addr</replaceable> | <replaceable>*</replaceable> ) </optional> 
 	<optional> port ( <replaceable>ip_port</replaceable> | <replaceable>*</replaceable> ) </optional> ) ; </optional>
+    <optional> use-queryport-pool <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> queryport-pool-ports <replaceable>number</replaceable>; </optional>
+    <optional> queryport-pool-interval <replaceable>number</replaceable>; </optional>
     <optional> max-transfer-time-in <replaceable>number</replaceable>; </optional>
     <optional> max-transfer-time-out <replaceable>number</replaceable>; </optional>
     <optional> max-transfer-idle-in <replaceable>number</replaceable>; </optional>
@@ -4486,6 +4808,7 @@ category notify { null; };
     <optional> notify-delay <replaceable>seconds</replaceable> ; </optional>
     <optional> notify-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
     <optional> notify-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
+    <optional> notify-to-soa <replaceable>yes_or_no</replaceable> ; </optional>
     <optional> also-notify { <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> max-ixfr-log-size <replaceable>number</replaceable>; </optional>
     <optional> max-journal-size <replaceable>size_spec</replaceable>; </optional>
@@ -4504,6 +4827,9 @@ category notify { null; };
     <optional> max-ncache-ttl <replaceable>number</replaceable>; </optional>
     <optional> max-cache-ttl <replaceable>number</replaceable>; </optional>
     <optional> sig-validity-interval <replaceable>number</replaceable> ; </optional>
+    <optional> sig-signing-nodes <replaceable>number</replaceable> ; </optional>
+    <optional> sig-signing-signatures <replaceable>number</replaceable> ; </optional>
+    <optional> sig-signing-type <replaceable>number</replaceable> ; </optional>
     <optional> min-roots <replaceable>number</replaceable>; </optional>
     <optional> use-ixfr <replaceable>yes_or_no</replaceable> ; </optional>
     <optional> provide-ixfr <replaceable>yes_or_no</replaceable>; </optional>
@@ -4594,39 +4920,57 @@ category notify { null; };
 
           <varlistentry>
             <term><command>named-xfer</command></term>
-            <listitem>
-              <para>
-                <emphasis>This option is obsolete.</emphasis>
-                It was used in <acronym>BIND</acronym> 8 to
-                specify the pathname to the <command>named-xfer</command> program.
-                In <acronym>BIND</acronym> 9, no separate <command>named-xfer</command> program is
-                needed; its functionality is built into the name server.
-              </para>
+	    <listitem>
+	      <para>
+		<emphasis>This option is obsolete.</emphasis> It
+		was used in <acronym>BIND</acronym> 8 to specify
+		the pathname to the <command>named-xfer</command>
+		program.  In <acronym>BIND</acronym> 9, no separate
+		<command>named-xfer</command> program is needed;
+		its functionality is built into the name server.
+	      </para>
+	    </listitem>
+	  </varlistentry>
 
-            </listitem>
-          </varlistentry>
+	  <varlistentry>
+	    <term><command>tkey-gssapi-credential</command></term>
+	    <listitem>
+	      <para>
+		The security credential with which the server should
+		authenticate keys requested by the GSS-TSIG protocol.
+		Currently only Kerberos 5 authentication is available
+		and the credential is a Kerberos principal which
+		the server can acquire through the default system
+		key file, normally <filename>/etc/krb5.keytab</filename>.
+		Normally this principal is of the form
+		"<userinput>dns/</userinput><varname>server.domain</varname>".
+		To use GSS-TSIG, <command>tkey-domain</command>
+		must also be set.
+	      </para>
+	    </listitem>
+	  </varlistentry>
 
           <varlistentry>
             <term><command>tkey-domain</command></term>
-            <listitem>
-              <para>
-                The domain appended to the names of all
-                shared keys generated with
-                <command>TKEY</command>. When a client
-                requests a <command>TKEY</command> exchange, it
-                may or may not specify
-                the desired name for the key. If present, the name of the
-                shared
-                key will be "<varname>client specified part</varname>" +
-                "<varname>tkey-domain</varname>".
-                Otherwise, the name of the shared key will be "<varname>random hex
-digits</varname>" + "<varname>tkey-domain</varname>". In most cases,
-                the <command>domainname</command> should be the
-                server's domain
-                name.
-              </para>
-            </listitem>
-          </varlistentry>
+	    <listitem>
+	      <para>
+		The domain appended to the names of all shared keys
+		generated with <command>TKEY</command>.  When a
+		client requests a <command>TKEY</command> exchange,
+		it may or may not specify the desired name for the
+		key. If present, the name of the shared key will
+		be <varname>client specified part</varname> +
+		<varname>tkey-domain</varname>.  Otherwise, the
+		name of the shared key will be <varname>random hex
+		digits</varname> + <varname>tkey-domain</varname>.
+		In most cases, the <command>domainname</command>
+		should be the server's domain name, or an otherwise
+		non-existent subdomain like
+		"_tkey.<varname>domainname</varname>".  If you are
+		using GSS-TSIG, this variable must be defined.
+	      </para>
+	    </listitem>
+	  </varlistentry>
 
           <varlistentry>
             <term><command>tkey-dhkey</command></term>
@@ -4670,26 +5014,20 @@ digits</varname>" + "<varname>tkey-domain</varname>". In most cases,
             <listitem>
               <para>
                 The pathname of the file the server writes memory
-                usage statistics to on exit.  If specified the
-		statistics will be written to the file on exit.
+                usage statistics to on exit. If not specified,
+                the default is <filename>named.memstats</filename>.
               </para>
-	      <para>
-		In <acronym>BIND</acronym> 9.5 and later this will
-		default to <filename>named.memstats</filename>.
-		<acronym>BIND</acronym> 9.5 will also introduce
-		<command>memstatistics</command> to control the
-		writing.
-	      </para>
-	    </listitem>
-	  </varlistentry>
+            </listitem>
+          </varlistentry>
 
           <varlistentry>
             <term><command>pid-file</command></term>
             <listitem>
               <para>
                 The pathname of the file the server writes its process ID
-                in. If not specified, the default is <filename>/var/run/named.pid</filename>.
-                The pid-file is used by programs that want to send signals to
+                in. If not specified, the default is
+		<filename>/var/run/named/named.pid</filename>.
+                The PID file is used by programs that want to send signals to
                 the running
                 name server. Specifying <command>pid-file none</command> disables the
                 use of a PID file &mdash; no file will be written and any
@@ -4824,7 +5162,7 @@ options {
                 top of a zone.  When a DNSKEY is at or below a domain
                 specified by the
                 deepest <command>dnssec-lookaside</command>, and
-                the normal dnssec validation
+                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
@@ -4842,10 +5180,10 @@ options {
               <para>
                 Specify hierarchies which must be or may not be secure (signed and
                 validated).
-                If <userinput>yes</userinput>, then named will only accept
+                If <userinput>yes</userinput>, then <command>named</command> will only accept
                 answers if they
                 are secure.
-                If <userinput>no</userinput>, then normal dnssec validation
+                If <userinput>no</userinput>, then normal DNSSEC validation
                 applies
                 allowing for insecure answers to be accepted.
                 The specified domain must be under a <command>trusted-key</command> or
@@ -4891,6 +5229,19 @@ options {
             </varlistentry>
 
             <varlistentry>
+              <term><command>memstatistics</command></term>
+              <listitem>
+                <para>
+		  Write memory statistics to the file specified by
+		  <command>memstatistics-file</command> at exit.
+		  The default is <userinput>no</userinput> unless
+		  '-m record' is specified on the command line in
+		  which case it is <userinput>yes</userinput>.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
               <term><command>dialup</command></term>
               <listitem>
                 <para>
@@ -5259,6 +5610,22 @@ options {
             </varlistentry>
 
             <varlistentry>
+              <term><command>notify-to-soa</command></term>
+              <listitem>
+                <para>
+		  If <userinput>yes</userinput> do not check the nameservers
+		  in the NS RRset against the SOA MNAME.  Normally a NOTIFY
+		  message is not sent to the SOA MNAME (SOA ORIGIN) as it is
+		  supposed to contain the name of the ultimate master.
+		  Sometimes, however, a slave is listed as the SOA MNAME in
+		  hidden master configurations and in that case you would
+		  want the ultimate master to still send NOTIFY messages to
+		  all the nameservers listed in the NS RRset.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
               <term><command>recursion</command></term>
               <listitem>
                 <para>
@@ -5518,9 +5885,10 @@ options {
 		  also accepts <command>master</command> and
                   <command>slave</command> at the view and options
                   levels which causes
-                  <command>ixfr-from-differences</command> to apply to
+                  <command>ixfr-from-differences</command> to be enabled for
                   all <command>master</command> or
                   <command>slave</command> zones respectively.
+                  It is off by default.
                 </para>
               </listitem>
             </varlistentry>
@@ -5531,9 +5899,9 @@ options {
                 <para>
                   This should be set when you have multiple masters for a zone
                   and the
-                  addresses refer to different machines.  If <userinput>yes</userinput>, named will
+                  addresses refer to different machines.  If <userinput>yes</userinput>, <command>named</command> will
                   not log
-                  when the serial number on the master is less than what named
+                  when the serial number on the master is less than what <command>named</command>
                   currently
                   has.  The default is <userinput>no</userinput>.
                 </para>
@@ -5544,8 +5912,8 @@ options {
               <term><command>dnssec-enable</command></term>
               <listitem>
                 <para>
-                  Enable DNSSEC support in named.  Unless set to <userinput>yes</userinput>,
-                  named behaves as if it does not support DNSSEC.
+                  Enable DNSSEC support in <command>named</command>.  Unless set to <userinput>yes</userinput>,
+                  <command>named</command> behaves as if it does not support DNSSEC.
                   The default is <userinput>yes</userinput>.
                 </para>
               </listitem>
@@ -5555,10 +5923,10 @@ options {
               <term><command>dnssec-validation</command></term>
               <listitem>
                 <para>
-                  Enable DNSSEC validation in named.
+                  Enable DNSSEC validation in <command>named</command>.
 		  Note <command>dnssec-enable</command> also needs to be
 		  set to <userinput>yes</userinput> to be effective.
-                  The default is <userinput>no</userinput>.
+                  The default is <userinput>yes</userinput>.
                 </para>
               </listitem>
             </varlistentry>
@@ -5569,7 +5937,7 @@ options {
                 <para>
 		  Accept expired signatures when verifying DNSSEC signatures.
                   The default is <userinput>no</userinput>.
-		  Setting this option to "yes" leaves named vulnerable to replay attacks.
+		  Setting this option to "yes" leaves <command>named</command> vulnerable to replay attacks.
                 </para>
               </listitem>
             </varlistentry>
@@ -5578,7 +5946,7 @@ options {
               <term><command>querylog</command></term>
               <listitem>
                 <para>
-                  Specify whether query logging should be started when named
+                  Specify whether query logging should be started when <command>named</command>
                   starts.
                   If <command>querylog</command> is not specified,
                   then the query logging
@@ -5608,9 +5976,9 @@ options {
                   from RFC 952 and RFC 821 as modified by RFC 1123.
                 </para>
                 <para><command>check-names</command>
-		  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.
+		  applies to the owner names of A, AAAA and MX records.
+		  It also applies to the domain names in the RDATA of NS, SOA,
+		  MX, and SRV records.
 		  It also applies to the RDATA of PTR records where the owner
 		  name indicated that it is a reverse lookup of a hostname
 		  (the owner name ends in IN-ADDR.ARPA, IP6.ARPA, or IP6.INT).
@@ -5701,7 +6069,7 @@ options {
 	      <listitem>
 	        <para>
 		  When returning authoritative negative responses to
-		  SOA queries set the TTL of the SOA recored returned in
+		  SOA queries set the TTL of the SOA record returned in
 		  the authority section to zero.
 		  The default is <command>yes</command>.
 	        </para>
@@ -5734,6 +6102,17 @@ options {
 	      </listitem>
 	    </varlistentry>
 
+	    <varlistentry>
+	      <term><command>try-tcp-refresh</command></term>
+	      <listitem>
+	        <para>
+		  Try to refresh the zone using TCP if UDP queries fail.
+		  For BIND 8 compatibility, the default is
+		  <command>yes</command>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
           </variablelist>
 
         </sect3>
@@ -5874,6 +6253,35 @@ options {
 	    </varlistentry>
 
 	    <varlistentry>
+	      <term><command>allow-query-on</command></term>
+	      <listitem>
+		<para>
+		  Specifies which local addresses can accept ordinary
+		  DNS questions. This makes it possible, for instance,
+		  to allow queries on internal-facing interfaces but
+		  disallow them on external-facing ones, without
+		  necessarily knowing the internal network's addresses.
+		</para>
+		<para>
+		  <command>allow-query-on</command> may
+		  also be specified in the <command>zone</command>
+		  statement, in which case it overrides the
+		  <command>options allow-query-on</command> statement.
+		</para>
+		<para>
+		  If not specified, the default is to allow queries
+		  on all addresses.
+		</para>
+		<note>
+		  <para>
+		    <command>allow-query-cache</command> is
+		    used to specify access to the cache.
+		  </para>
+		</note>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
 	      <term><command>allow-query-cache</command></term>
 	      <listitem>
 		<para>
@@ -5881,13 +6289,27 @@ options {
 		  from the cache.  If <command>allow-query-cache</command>
 		  is not set then <command>allow-recursion</command>
 		  is used if set, otherwise <command>allow-query</command>
-		  is used if set, otherwise the default
-		  (<command>localnets;</command>
+		  is used if set unless <command>recursion no;</command> is
+		  set in which case <command>none;</command> is used,
+		  otherwise the default (<command>localnets;</command>
 		  <command>localhost;</command>) is used.
 		</para>
 	      </listitem>
 	    </varlistentry>
 
+	    <varlistentry>
+	      <term><command>allow-query-cache-on</command></term>
+	      <listitem>
+		<para>
+		  Specifies which local addresses can give answers
+		  from the cache.  If not specified, the default is
+		  to allow cache queries on any address,
+		  <command>localnets</command> and
+		  <command>localhost</command>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
             <varlistentry>
               <term><command>allow-recursion</command></term>
               <listitem>
@@ -5905,6 +6327,17 @@ options {
             </varlistentry>
 
             <varlistentry>
+              <term><command>allow-recursion-on</command></term>
+              <listitem>
+                <para>
+		  Specifies which local addresses can accept recursive
+		  queries.  If not specified, the default is to allow
+		  recursive queries on all addresses.
+                </para>
+              </listitem>
+            </varlistentry>
+
+            <varlistentry>
               <term><command>allow-update</command></term>
               <listitem>
                 <para>
@@ -6001,7 +6434,7 @@ options {
           <para>
             The interfaces and ports that the server will answer queries
             from may be specified using the <command>listen-on</command> option. <command>listen-on</command> takes
-            an optional port, and an <varname>address_match_list</varname>.
+            an optional port and an <varname>address_match_list</varname>.
             The server will listen on all interfaces allowed by the address
             match list. If a port is not specified, port 53 will be used.
           </para>
@@ -6023,7 +6456,7 @@ listen-on port 1234 { !1.2.3.4; 1.2/16; };
 
           <para>
             If no <command>listen-on</command> is specified, the
-            server will listen on port 53 on all interfaces.
+            server will listen on port 53 on all IPv4 interfaces.
           </para>
 
           <para>
@@ -6081,8 +6514,10 @@ listen-on-v6 port 1234 { !2001:db8::/32; any; };
 
           <para>
             If no <command>listen-on-v6</command> option is
-            specified,
-            the server will not listen on any IPv6 address.
+            specified, the server will not listen on any IPv6 address
+	    unless <command>-6</command> is specified when <command>named</command> is
+	    invoked.  If <command>-6</command> is specified then
+	    <command>named</command> will listen on port 53 on all IPv6 interfaces by default.
           </para>
         </sect3>
 
@@ -6176,20 +6611,52 @@ avoid-v6-udp-ports {};
 </programlisting>
 
 	  <para>
-	    Note: it is generally strongly discouraged to
+	    Note: BIND 9.5.0 introduced
+	    the <command>use-queryport-pool</command> 
+	    option to support a pool of such random ports, but this
+	    option is now obsolete because reusing the same ports in
+	    the pool may not be sufficiently secure.
+	    For the same reason, it is generally strongly discouraged to
             specify a particular port for the
 	    <command>query-source</command> or
 	    <command>query-source-v6</command> options;
-	    it implicitly disables the use of randomized port numbers
-	    and can be insecure.
+	    it implicitly disables the use of randomized port numbers.
           </para>
 
+          <variablelist>
+            <varlistentry>
+              <term><command>use-queryport-pool</command></term>
+              <listitem>
+                <para>
+		  This option is obsolete.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+            <varlistentry>
+              <term><command>queryport-pool-ports</command></term>
+              <listitem>
+                <para>
+		  This option is obsolete.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+            <varlistentry>
+              <term><command>queryport-pool-updateinterval</command></term>
+              <listitem>
+                <para>
+		  This option is obsolete.
+		</para>
+	      </listitem>
+	    </varlistentry>
+	    
+          </variablelist>
           <note>
             <para>
               The address specified in the <command>query-source</command> option
               is used for both UDP and TCP queries, but the port applies only
-              to
-              UDP queries.  TCP queries always use a random
+              to UDP queries.  TCP queries always use a random
               unprivileged port.
             </para>
           </note>
@@ -6228,7 +6695,12 @@ avoid-v6-udp-ports {};
                   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 <command>also-notify</command> list
+                  quickly converge on stealth servers.
+                  Optionally, a port may be specified with each
+                  <command>also-notify</command> address to send
+                  the notify messages to a port other than the
+                  default of 53.
+                  If an <command>also-notify</command> list
                   is given in a <command>zone</command> statement,
                   it will override
                   the <command>options also-notify</command>
@@ -6457,7 +6929,7 @@ avoid-v6-udp-ports {};
 		  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
+		  getting an answer back to the first refresh
 		  query.
 		</note>
               </listitem>
@@ -6657,7 +7129,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
         </sect3>
 
-        <sect3>
+        <sect3 id="server_resource_limits">
           <title>Server  Resource Limits</title>
 
           <para>
@@ -6691,6 +7163,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                   journal
                   will be automatically removed.  The default is
                   <literal>unlimited</literal>.
+                  This may also be set on a per-zone basis.
                 </para>
               </listitem>
             </varlistentry>
@@ -6741,7 +7214,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                 <para>
 		  The number of file descriptors reserved for TCP, stdio,
 		  etc.  This needs to be big enough to cover the number of
-		  interfaces named listens on, tcp-clients as well as
+		  interfaces <command>named</command> listens on, <command>tcp-clients</command> as well as
 		  to provide room for outgoing TCP queries and incoming zone
 		  transfers.  The default is <literal>512</literal>.
 		  The minimum value is <literal>128</literal> and the
@@ -6762,7 +7235,8 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                   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.
+                  prematurely based on an LRU based strategy so that
+                  the limit is not exceeded.
                   A value of 0 is special, meaning that
                   records are purged from the cache only when their
                   TTLs expire.
@@ -6809,11 +7283,14 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
               <term><command>cleaning-interval</command></term>
               <listitem>
                 <para>
-                  The server will remove expired resource records
+		  This interval is effectively obsolete.  Previously,
+		  the server would remove expired resource records
                   from the cache every <command>cleaning-interval</command> minutes.
-                  The default is 60 minutes.  The maximum value is 28 days
-                  (40320 minutes).
-                  If set to 0, no periodic cleaning will occur.
+		  <acronym>BIND</acronym> 9 now manages cache
+		  memory in a more sophisticated manner and does not
+		  rely on the periodic cleaning any more.
+		  Specifying this option therefore has no effect on
+		  the server's behavior.
                 </para>
               </listitem>
             </varlistentry>
@@ -7095,8 +7572,13 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                   </entry>
                   <entry colname="2">
                     <para>
-                      Records are returned in a round-robin
-                      order.
+                      Records are returned in a cyclic round-robin order.
+                    </para>
+                    <para>
+                      If <acronym>BIND</acronym> is configured with the
+                      "--enable-fixed-rrset" option at compile time, then
+                      the initial ordering of the RRset will match the
+                      one specified in the zone file.
                     </para>
                   </entry>
                 </row>
@@ -7127,9 +7609,11 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 
           <note>
             <simpara>
-              The <command>rrset-order</command> statement
-              is not yet fully implemented in <acronym>BIND</acronym> 9.
-              BIND 9 currently does not fully support "fixed" ordering.
+              In this release of <acronym>BIND</acronym> 9, the
+              <command>rrset-order</command> statement does not support
+              "fixed" ordering by default.  Fixed ordering can be enabled
+              at compile time by specifying "--enable-fixed-rrset" on
+              the "configure" command line.
             </simpara>
           </note>
         </sect3>
@@ -7203,22 +7687,76 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
               </listitem>
             </varlistentry>
 
-            <varlistentry>
-              <term><command>sig-validity-interval</command></term>
-              <listitem>
-                <para>
-                  Specifies the number of days into the
-                  future when DNSSEC signatures automatically generated as a
-                  result
-                  of dynamic updates (<xref linkend="dynamic_update"/>)
-                  will expire. The default is <literal>30</literal> 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.
-                </para>
-              </listitem>
-            </varlistentry>
+	    <varlistentry>
+	      <term><command>sig-validity-interval</command></term>
+	      <listitem>
+		<para>
+		  Specifies the number of days into the future when
+		  DNSSEC signatures automatically generated as a
+		  result of dynamic updates (<xref
+		  linkend="dynamic_update"/>) will expire.  There
+		  is a optional second field which specifies how
+		  long before expiry that the signatures will be
+		  regenerated.  If not specified, the signatures will
+		  be regenerated at 1/4 of base interval.  The second
+		  field is specified in days if the base interval is
+		  greater than 7 days otherwise it is specified in hours.
+		  The default base interval is <literal>30</literal> days
+		  giving a re-signing interval of 7 1/2 days.  The maximum
+		  values are 10 years (3660 days).
+		</para>
+		<para>
+		  The signature inception time is unconditionally
+		  set to one hour before the current time to allow
+		  for a limited amount of clock skew.
+		</para>
+		<para>
+		  The <command>sig-validity-interval</command>
+		  should be, at least, several multiples of the SOA
+		  expire interval to allow for reasonable interaction
+		  between the various timer and expiry dates.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>sig-signing-nodes</command></term>
+	      <listitem>
+		<para>
+		  Specify the maximum number of nodes to be
+		  examined in each quantum when signing a zone with
+		  a new DNSKEY. The default is
+		  <literal>100</literal>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>sig-signing-signatures</command></term>
+	      <listitem>
+		<para>
+		  Specify a threshold number of signatures that
+		  will terminate processing a quantum when signing
+		  a zone with a new DNSKEY.  The default is
+		  <literal>10</literal>.
+		</para>
+	      </listitem>
+	    </varlistentry>
+
+	    <varlistentry>
+	      <term><command>sig-signing-type</command></term>
+	      <listitem>
+		<para>
+		  Specify a private RDATA type to be used when generating
+		  key signing records.  The default is
+		  <literal>65535</literal>.
+		</para>
+		<para>
+		  It is expected that this parameter may be removed
+		  in a future version once there is a standard type.
+		</para>
+	      </listitem>
+	    </varlistentry>
 
             <varlistentry>
               <term><command>min-refresh-time</command></term>
@@ -7252,14 +7790,15 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
               <term><command>edns-udp-size</command></term>
               <listitem>
                 <para>
-		  Sets the advertised EDNS UDP buffer size in bytes.  Valid
-                  values are 512 to 4096 (values outside this range
-                  will be silently adjusted).  The default value is
-                  4096.  The usual reason for setting edns-udp-size to
-                  a non-default value is to get UDP answers to pass
-                  through broken firewalls that block fragmented
-                  packets and/or block UDP packets that are greater
-                  than 512 bytes.
+		  Sets the advertised EDNS UDP buffer size in bytes
+                  to control the size of packets received.
+                  Valid values are 512 to 4096 (values outside this range
+		  will be silently adjusted).  The default value
+		  is 4096.  The usual reason for setting
+		  <command>edns-udp-size</command> to a non-default
+		  value is to get UDP answers to pass through broken
+		  firewalls that block fragmented packets and/or
+		  block UDP packets that are greater than 512 bytes.
                 </para>
               </listitem>
             </varlistentry>
@@ -7268,11 +7807,11 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
               <term><command>max-udp-size</command></term>
               <listitem>
                 <para>
-		  Sets the maximum EDNS UDP message size named will
+		  Sets the maximum EDNS UDP message size <command>named</command> will
 		  send in bytes.  Valid values are 512 to 4096 (values outside
 		  this range will be silently adjusted).  The default
 		  value is 4096.  The usual reason for setting
-		  max-udp-size to a non-default value is to get UDP
+		  <command>max-udp-size</command> to a non-default value is to get UDP
 		  answers to pass through broken firewalls that
 		  block fragmented packets and/or block UDP packets
 		  that are greater than 512 bytes.
@@ -7312,22 +7851,22 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 	      </listitem>
 	    </varlistentry>
 
-	    <varlistentry>
+	    <varlistentry id="clients-per-query">
 	      <term><command>clients-per-query</command></term>
 	      <term><command>max-clients-per-query</command></term>
               <listitem>
 		<para>These set the
 		  initial value (minimum) and maximum number of recursive
-		  simultanious clients for any given query
+		  simultaneous clients for any given query
 		  (&lt;qname,qtype,qclass&gt;) that the server will accept
-		  before dropping additional clients.  named will attempt to
+		  before dropping additional clients.  <command>named</command> will attempt to
 		  self tune this value and changes will be logged.  The
 		  default values are 10 and 100.
 		</para>
 		<para>
 	          This value should reflect how many queries come in for
 		  a given name in the time it takes to resolve that name.
-		  If the number of queries exceed this value, named will
+		  If the number of queries exceed this value, <command>named</command> will
 		  assume that it is dealing with a non-responsive zone
 		  and will drop additional queries.  If it gets a response
 		  after dropping queries, it will raise the estimate.  The
@@ -7422,14 +7961,15 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
               <term><command>server-id</command></term>
               <listitem>
                 <para>
-                  The ID of the server should report via a query of
-                  the name <filename>ID.SERVER</filename>
-                  with type <command>TXT</command>, class <command>CHAOS</command>.
+                  The ID the server should report when receiving a Name
+                  Server Identifier (NSID) query, or a query of the name
+                  <filename>ID.SERVER</filename> with type
+                  <command>TXT</command>, class <command>CHAOS</command>.
                   The primary purpose of such queries is to
                   identify which of a group of anycast servers is actually
                   answering your queries.  Specifying <command>server-id none;</command>
                   disables processing of the queries.
-                  Specifying <command>server-id hostname;</command> will cause named to
+                  Specifying <command>server-id hostname;</command> will cause <command>named</command> to
                   use the hostname as found by the gethostname() function.
                   The default <command>server-id</command> is <command>none</command>.
                 </para>
@@ -7451,12 +7991,12 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 	    these cover the reverse namespace for addresses from RFC 1918 and
 	    RFC 3330.  They also include the reverse namespace for IPv6 local
 	    address (locally assigned), IPv6 link local addresses, the IPv6
-	    loopback address and the IPv6 unknown addresss.
+	    loopback address and the IPv6 unknown address.
 	  </para>
 	  <para>
-	    Named will attempt to determine if a built in zone already exists
+	    Named will attempt to determine if a built-in zone already exists
 	    or is active (covered by a forward-only forwarding declaration)
-	    and will not not create a empty zone in that case.
+	    and will not create a empty zone in that case.
 	  </para>
 	  <para>
 	    The current list of empty zones is:
@@ -7517,7 +8057,7 @@ XXX: end of RFC1918 addresses #defined out -->
 	  <note>
 	    The real parent servers for these zones should disable all
 	    empty zone under the parent zone they serve.  For the real
-	    root servers, this is all built in empty zones.  This will
+	    root servers, this is all built-in empty zones.  This will
 	    enable them to return referrals to deeper in the tree.
 	  </note>
           <variablelist>
@@ -7547,7 +8087,7 @@ XXX: end of RFC1918 addresses #defined out -->
 	      <term><command>empty-zones-enable</command></term>
 	      <listitem>
 	        <para>
-		  Enable or disable all empty zones.  By default they
+		  Enable or disable all empty zones.  By default, they
 		  are enabled.
 	        </para>
 	      </listitem>
@@ -7557,171 +8097,13 @@ XXX: end of RFC1918 addresses #defined out -->
 	    <term><command>disable-empty-zone</command></term>
 	      <listitem>
 	        <para>
-		  Disable individual empty zones.  By default none are
+		  Disable individual empty zones.  By default, none are
 		  disabled.  This option can be specified multiple times.
 	        </para>
 	      </listitem>
 	    </varlistentry>
           </variablelist>
         </sect3>
-  
-        <sect3 id="statsfile">
-          <title>The Statistics File</title>
-
-          <para>
-            The statistics file generated by <acronym>BIND</acronym> 9
-            is similar, but not identical, to that
-            generated by <acronym>BIND</acronym> 8.
-          </para>
-          <para>
-            The statistics dump begins with a line, like:
-	  </para>
-          <para>
-	    <command>+++ Statistics Dump +++ (973798949)</command>
-	  </para>
-	  <para>
-	    The number in parentheses is a standard
-            Unix-style timestamp, measured as seconds since January 1, 1970.
-            Following
-            that line 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).
-	  </para>
-	  <para>
-	    The statistics dump ends with the line where the
-            number is identical to the number in the beginning line; for example:
-          </para>
-          <para>
-	    <command>--- Statistics Dump --- (973798949)</command>
-          </para>
-          <para>
-            The following statistics counters are maintained:
-          </para>
-          <informaltable colsep="0" rowsep="0">
-            <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
-              <colspec colname="1" colnum="1" colsep="0" colwidth="1.150in"/>
-              <colspec colname="2" colnum="2" colsep="0" colwidth="3.350in"/>
-              <tbody>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>success</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      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.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>referral</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      The number of queries which resulted
-                      in referral responses.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>nxrrset</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      The number of queries which resulted in
-                      NOERROR responses with no data.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>nxdomain</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      The number
-                      of queries which resulted in NXDOMAIN responses.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>failure</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      The number of queries which resulted in a
-                      failure response other than those above.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>recursion</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      The number of queries which caused the server
-                      to perform recursion in order to find the final answer.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>duplicate</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-                      The number of queries which the server attempted to
-		      recurse but discover a existing query with the same
-		      IP address, port, query id, name, type and class
-		      already being processed.
-                    </para>
-                  </entry>
-                </row>
-                <row rowsep="0">
-                  <entry colname="1">
-                    <para><command>dropped</command></para>
-                  </entry>
-                  <entry colname="2">
-                    <para>
-		      The number of queries for which the server
-		      discovered a excessive number of existing
-		      recursive queries for the same name, type and
-		      class and were subsequently dropped.
-		    </para>
-		  </entry>
-		</row>
-              </tbody>
-            </tgroup>
-          </informaltable>
-
-          <para>
-            Each query received by the server will cause exactly one of
-            <command>success</command>,
-            <command>referral</command>,
-            <command>nxrrset</command>,
-            <command>nxdomain</command>,
-            <command>failure</command>,
-            <command>duplicate</command>, or
-            <command>dropped</command>
-            to be incremented, and may additionally cause the
-            <command>recursion</command> counter to be
-            incremented.
-          </para>
-
-        </sect3>
 
         <sect3 id="acache">
           <title>Additional Section Caching</title>
@@ -7829,10 +8211,7 @@ XXX: end of RFC1918 addresses #defined out -->
                   In a server with multiple views, the limit applies
                   separately to the
                   acache of each view.
-                  The default is <literal>unlimited</literal>,
-                  meaning that
-                  entries are purged from the acache only at the
-                  periodic cleaning time.
+                  The default is <literal>16M</literal>.
                 </para>
               </listitem>
             </varlistentry>
@@ -7862,6 +8241,9 @@ XXX: end of RFC1918 addresses #defined out -->
     <optional> notify-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
     <optional> query-source <optional> address ( <replaceable>ip_addr</replaceable> | <replaceable>*</replaceable> ) </optional> <optional> port ( <replaceable>ip_port</replaceable> | <replaceable>*</replaceable> ) </optional>; </optional>
     <optional> query-source-v6 <optional> address ( <replaceable>ip_addr</replaceable> | <replaceable>*</replaceable> ) </optional> <optional> port ( <replaceable>ip_port</replaceable> | <replaceable>*</replaceable> ) </optional>; </optional>
+    <optional> use-queryport-pool <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> queryport-pool-ports <replaceable>number</replaceable>; </optional>
+    <optional> queryport-pool-interval <replaceable>number</replaceable>; </optional>
 };
 </programlisting>
 
@@ -7953,7 +8335,7 @@ XXX: end of RFC1918 addresses #defined out -->
 
           <para>
             The <command>edns-udp-size</command> option sets the EDNS UDP size
-	    that is advertised by named when querying the remote server.
+	    that is advertised by <command>named</command> when querying the remote server.
 	    Valid values are 512 to 4096 bytes (values outside this range will be
 	    silently adjusted).  This option is useful when you wish to
 	    advertises a different value to this server than the value you
@@ -7963,11 +8345,11 @@ XXX: end of RFC1918 addresses #defined out -->
 
           <para>
 	    The <command>max-udp-size</command> option sets the
-	    maximum EDNS UDP message size named will send.  Valid
+	    maximum EDNS UDP message size <command>named</command> will send.  Valid
 	    values are 512 to 4096 bytes (values outside this range will
 	    be silently adjusted).  This option is useful when you
 	    know that there is a firewall that is blocking large
-	    replies from named.
+	    replies from <command>named</command>.
 	  </para>
 
           <para>
@@ -8052,6 +8434,74 @@ XXX: end of RFC1918 addresses #defined out -->
 
         </sect2>
 
+      <sect2 id="statschannels">
+        <title><command>statistics-channels</command> Statement Grammar</title>
+
+<programlisting><command>statistics-channels</command> {
+   [ inet ( ip_addr | * ) [ port ip_port ] [allow { <replaceable> address_match_list </replaceable> } ]; ]
+   [ inet ...; ]
+};
+</programlisting>
+      </sect2>
+
+      <sect2>
+          <title><command>statistics-channels</command> Statement Definition and
+            Usage</title>
+
+        <para>
+          The <command>statistics-channels</command> statement
+	  declares communication channels to be used by system
+	  administrators to get access to statistics information of
+	  the name server.
+        </para>
+
+        <para>
+	  This statement intends to be flexible to support multiple
+	  communication protocols in the future, but currently only
+	  HTTP access is supported.
+	  It requires that BIND 9 be compiled with libxml2;
+	  the <command>statistics-channels</command> statement is
+	  still accepted even if it is built without the library,
+	  but any HTTP access will fail with an error.
+        </para>
+
+        <para>
+          An <command>inet</command> control channel is a TCP socket
+	  listening at the specified <command>ip_port</command> on the
+	  specified <command>ip_addr</command>, which can be an IPv4 or IPv6
+	  address.  An <command>ip_addr</command> of <literal>*</literal> (asterisk) is
+	  interpreted as the IPv4 wildcard address; connections will be
+	  accepted on any of the system's IPv4 addresses.
+	  To listen on the IPv6 wildcard address,
+          use an <command>ip_addr</command> of <literal>::</literal>.
+        </para>
+
+        <para>
+          If no port is specified, port 80 is used for HTTP channels.
+	  The asterisk "<literal>*</literal>" cannot be used for
+	  <command>ip_port</command>.
+        </para>
+
+        <para>
+          The attempt of opening a statistics channel is
+          restricted by the optional <command>allow</command> clause.
+	  Connections to the statistics channel are permitted based on the
+          <command>address_match_list</command>.
+	  If no <command>allow</command> clause is present,
+	  <command>named</command> accepts connection
+	  attempts from any address; since the statistics may
+	  contain sensitive internal information, it is highly
+	  recommended to restrict the source of connection requests
+	  appropriately.
+        </para>
+
+        <para>
+          If no <command>statistics-channels</command> statement is present,
+          <command>named</command> will not open any communication channels.
+        </para>
+
+      </sect2>
+
         <sect2>
           <title><command>trusted-keys</command> Statement Grammar</title>
 
@@ -8090,6 +8540,9 @@ XXX: end of RFC1918 addresses #defined out -->
 	    multiple key entries, each consisting of the key's
 	    domain name, flags, protocol, algorithm, and the Base-64
 	    representation of the key data.
+	    Spaces, tabs, newlines and carriage returns are ignored
+	    in the key data, so the configuration may be split up into
+	    multiple lines.
 	  </para>
 	</sect2>
 
@@ -8240,6 +8693,7 @@ view "external" {
 <programlisting><command>zone</command> <replaceable>zone_name</replaceable> <optional><replaceable>class</replaceable></optional> {
     type master;
     <optional> allow-query { <replaceable>address_match_list</replaceable> }; </optional>
+    <optional> allow-query-on { <replaceable>address_match_list</replaceable> }; </optional>
     <optional> allow-transfer { <replaceable>address_match_list</replaceable> }; </optional>
     <optional> allow-update { <replaceable>address_match_list</replaceable> }; </optional>
     <optional> update-policy { <replaceable>update_policy_rule</replaceable> <optional>...</optional> }; </optional>
@@ -8252,9 +8706,11 @@ view "external" {
     <optional> file <replaceable>string</replaceable> ; </optional>
     <optional> masterfile-format (<constant>text</constant>|<constant>raw</constant>) ; </optional>
     <optional> journal <replaceable>string</replaceable> ; </optional>
+    <optional> max-journal-size <replaceable>size_spec</replaceable>; </optional>
     <optional> forward (<constant>only</constant>|<constant>first</constant>) ; </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-from-differences <replaceable>yes_or_no</replaceable>; </optional>
     <optional> ixfr-tmp-file <replaceable>string</replaceable> ; </optional>
     <optional> maintain-ixfr-base <replaceable>yes_or_no</replaceable> ; </optional>
     <optional> max-ixfr-log-size <replaceable>number</replaceable> ; </optional>
@@ -8262,11 +8718,15 @@ view "external" {
     <optional> max-transfer-time-out <replaceable>number</replaceable> ; </optional>
     <optional> notify <replaceable>yes_or_no</replaceable> | <replaceable>explicit</replaceable> | <replaceable>master-only</replaceable> ; </optional>
     <optional> notify-delay <replaceable>seconds</replaceable> ; </optional>
+    <optional> notify-to-soa <replaceable>yes_or_no</replaceable>; </optional>
     <optional> pubkey <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>string</replaceable> ; </optional>
     <optional> notify-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
     <optional> notify-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
     <optional> zone-statistics <replaceable>yes_or_no</replaceable> ; </optional>
     <optional> sig-validity-interval <replaceable>number</replaceable> ; </optional>
+    <optional> sig-signing-nodes <replaceable>number</replaceable> ; </optional>
+    <optional> sig-signing-signatures <replaceable>number</replaceable> ; </optional>
+    <optional> sig-signing-type <replaceable>number</replaceable> ; </optional>
     <optional> database <replaceable>string</replaceable> ; </optional>
     <optional> min-refresh-time <replaceable>number</replaceable> ; </optional>
     <optional> max-refresh-time <replaceable>number</replaceable> ; </optional>
@@ -8280,18 +8740,22 @@ zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replacea
     type slave;
     <optional> allow-notify { <replaceable>address_match_list</replaceable> }; </optional>
     <optional> allow-query { <replaceable>address_match_list</replaceable> }; </optional>
+    <optional> allow-query-on { <replaceable>address_match_list</replaceable> }; </optional>
     <optional> allow-transfer { <replaceable>address_match_list</replaceable> }; </optional>
     <optional> allow-update-forwarding { <replaceable>address_match_list</replaceable> }; </optional>
     <optional> update-check-ksk <replaceable>yes_or_no</replaceable>; </optional>
+    <optional> try-tcp-refresh <replaceable>yes_or_no</replaceable>; </optional>
     <optional> also-notify { <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> check-names (<constant>warn</constant>|<constant>fail</constant>|<constant>ignore</constant>) ; </optional>
     <optional> dialup <replaceable>dialup_option</replaceable> ; </optional>
     <optional> file <replaceable>string</replaceable> ; </optional>
     <optional> masterfile-format (<constant>text</constant>|<constant>raw</constant>) ; </optional>
     <optional> journal <replaceable>string</replaceable> ; </optional>
+    <optional> max-journal-size <replaceable>size_spec</replaceable>; </optional>
     <optional> forward (<constant>only</constant>|<constant>first</constant>) ; </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-from-differences <replaceable>yes_or_no</replaceable>; </optional>
     <optional> ixfr-tmp-file <replaceable>string</replaceable> ; </optional>
     <optional> maintain-ixfr-base <replaceable>yes_or_no</replaceable> ; </optional>
     <optional> masters <optional>port <replaceable>ip_port</replaceable></optional> { ( <replaceable>masters_list</replaceable> | <replaceable>ip_addr</replaceable> <optional>port <replaceable>ip_port</replaceable></optional> <optional>key <replaceable>key</replaceable></optional> ) ; <optional>...</optional> }; </optional>
@@ -8301,6 +8765,8 @@ zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replacea
     <optional> max-transfer-time-in <replaceable>number</replaceable> ; </optional>
     <optional> max-transfer-time-out <replaceable>number</replaceable> ; </optional>
     <optional> notify <replaceable>yes_or_no</replaceable> | <replaceable>explicit</replaceable> | <replaceable>master-only</replaceable> ; </optional>
+    <optional> notify-delay <replaceable>seconds</replaceable> ; </optional>
+    <optional> notify-to-soa <replaceable>yes_or_no</replaceable>; </optional>
     <optional> pubkey <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>number</replaceable> <replaceable>string</replaceable> ; </optional>
     <optional> transfer-source (<replaceable>ip4_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
     <optional> transfer-source-v6 (<replaceable>ip6_addr</replaceable> | <constant>*</constant>) <optional>port <replaceable>ip_port</replaceable></optional> ; </optional>
@@ -8329,6 +8795,7 @@ zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replacea
 zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replaceable></optional> {
     type stub;
     <optional> allow-query { <replaceable>address_match_list</replaceable> }; </optional>
+    <optional> allow-query-on { <replaceable>address_match_list</replaceable> }; </optional>
     <optional> check-names (<constant>warn</constant>|<constant>fail</constant>|<constant>ignore</constant>) ; </optional>
     <optional> dialup <replaceable>dialup_option</replaceable> ; </optional>
     <optional> delegation-only <replaceable>yes_or_no</replaceable> ; </optional>
@@ -8435,7 +8902,7 @@ zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replacea
                         <filename>ex/example.com</filename> where <filename>ex/</filename> is
                         just the first two letters of the zone name. (Most
                         operating systems
-                        behave very slowly if you put 100 000 files into
+                        behave very slowly if you put 100000 files into
                         a single directory.)
                       </para>
                     </entry>
@@ -8629,6 +9096,16 @@ zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replacea
               </varlistentry>
 
               <varlistentry>
+                <term><command>allow-query-on</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>allow-query-on</command> in <xref linkend="access_control"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
                 <term><command>allow-transfer</command></term>
                 <listitem>
                   <para>
@@ -8767,6 +9244,16 @@ zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replacea
                 </listitem>
               </varlistentry>
 
+	      <varlistentry>
+	        <term><command>try-tcp-refresh</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>try-tcp-refresh</command> in <xref linkend="boolean_options"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
               <varlistentry>
                 <term><command>database</command></term>
                 <listitem>
@@ -8882,6 +9369,16 @@ zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replacea
               </varlistentry>
 
               <varlistentry>
+                <term><command>max-journal-size</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>max-journal-size</command> in <xref linkend="server_resource_limits"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
                 <term><command>max-transfer-time-in</command></term>
                 <listitem>
                   <para>
@@ -8942,6 +9439,17 @@ zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replacea
               </varlistentry>
 
               <varlistentry>
+                <term><command>notify-to-soa</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>notify-to-soa</command> in
+		    <xref linkend="boolean_options"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
                 <term><command>pubkey</command></term>
                 <listitem>
                   <para>
@@ -8979,6 +9487,36 @@ zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replacea
               </varlistentry>
 
               <varlistentry>
+                <term><command>sig-signing-nodes</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>sig-signing-nodes</command> in <xref linkend="tuning"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>sig-signing-signatures</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>sig-signing-signatures</command> in <xref linkend="tuning"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
+                <term><command>sig-signing-type</command></term>
+                <listitem>
+                  <para>
+                    See the description of
+                    <command>sig-signing-type</command> in <xref linkend="tuning"/>.
+                  </para>
+                </listitem>
+              </varlistentry>
+
+              <varlistentry>
                 <term><command>transfer-source</command></term>
                 <listitem>
                   <para>
@@ -9067,6 +9605,10 @@ zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replacea
                   <para>
                     See the description of
                     <command>ixfr-from-differences</command> in <xref linkend="boolean_options"/>.
+		    (Note that the <command>ixfr-from-differences</command>
+		    <userinput>master</userinput> and
+		    <userinput>slave</userinput> choices are not
+		    available at the zone level.)
                   </para>
                 </listitem>
               </varlistentry>
@@ -9106,45 +9648,41 @@ zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replacea
           </sect3>
           <sect3 id="dynamic_update_policies">
             <title>Dynamic Update Policies</title>
-            <para>
-              <acronym>BIND</acronym> 9 supports two alternative
-              methods of granting clients
-              the right to perform dynamic updates to a zone,
-              configured by the <command>allow-update</command>
-              and
-              <command>update-policy</command> option,
-              respectively.
-            </para>
-            <para>
-              The <command>allow-update</command> clause works the
-              same
-              way as in previous versions of <acronym>BIND</acronym>. It grants given clients the
-              permission to update any record of any name in the zone.
-            </para>
-            <para>
-              The <command>update-policy</command> clause is new
-              in <acronym>BIND</acronym>
-              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.
-            </para>
-            <para>
-              Rules are specified in the <command>update-policy</command> zone
-              option, and are only meaningful for master zones.  When the <command>update-policy</command> statement
-              is present, it is a configuration error for the <command>allow-update</command> statement
-              to be present.  The <command>update-policy</command>
-              statement only
-              examines the signer of a message; the source address is not
-              relevant.
-            </para>
-            <para>
+	    <para><acronym>BIND</acronym> 9 supports two alternative
+	      methods of granting clients the right to perform
+	      dynamic updates to a zone, configured by the
+	      <command>allow-update</command> and
+	      <command>update-policy</command> option, respectively.
+	    </para>
+	    <para>
+	      The <command>allow-update</command> clause works the
+	      same way as in previous versions of <acronym>BIND</acronym>.
+	      It grants given clients the permission to update any
+	      record of any name in the zone.
+	    </para>
+	    <para>
+	      The <command>update-policy</command> clause is new
+	      in <acronym>BIND</acronym> 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.
+	    </para>
+	    <para>
+	      Rules are specified in the <command>update-policy</command>
+	      zone option, and are only meaningful for master zones.
+	      When the <command>update-policy</command> statement
+	      is present, it is a configuration error for the
+	      <command>allow-update</command> statement to be
+	      present.  The <command>update-policy</command> statement
+	      only examines the signer of a message; the source
+	      address is not relevant.
+	    </para>
+
+	    <para>
               This is how a rule definition looks:
             </para>
 
@@ -9162,29 +9700,40 @@ zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replacea
               matches
               the types specified in the type field.
             </para>
-
             <para>
-              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 <replaceable>identity</replaceable> field specifies a
-              wildcard name, it is subject to DNS wildcard expansion, so the
-              rule will apply
-              to multiple identities.  The <replaceable>identity</replaceable> field must
-              contain a fully-qualified domain name.
-            </para>
+	      No signer is required for <replaceable>tcp-self</replaceable>
+	      or <replaceable>6to4-self</replaceable> however the standard
+	      reverse mapping / prefix conversion must match the identity
+	      field.
+	    </para>
+	    <para>
+	      The identity field specifies a name or a wildcard
+	      name.  Normally, this is the name of the TSIG or
+	      SIG(0) key used to sign the update request.  When a
+	      TKEY exchange has been used to create a shared secret,
+	      the identity of the shared secret is the same as the
+	      identity of the key used to authenticate the TKEY
+	      exchange.  TKEY is also the negotiation method used
+	      by GSS-TSIG, which establishes an identity that is
+	      the Kerberos principal of the client, such as
+	      <userinput>"user@host.domain"</userinput>.  When the
+	      <replaceable>identity</replaceable> field specifies
+	      a wildcard name, it is subject to DNS wildcard
+	      expansion, so the rule will apply to multiple identities.
+	      The <replaceable>identity</replaceable> field must
+	      contain a fully-qualified domain name.
+	    </para>
 
             <para>
-              The <replaceable>nametype</replaceable> field has 6
+              The <replaceable>nametype</replaceable> field has 12
               values:
               <varname>name</varname>, <varname>subdomain</varname>,
               <varname>wildcard</varname>, <varname>self</varname>,
-	       <varname>selfsub</varname>, and <varname>selfwild</varname>.
+	      <varname>selfsub</varname>, <varname>selfwild</varname>,
+	      <varname>krb5-self</varname>, <varname>ms-self</varname>,
+	      <varname>krb5-subdomain</varname>,
+	      <varname>ms-subdomain</varname>,
+	      <varname>tcp-self</varname> and <varname>6to4-self</varname>.
             </para>
             <informaltable>
               <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
@@ -9283,6 +9832,43 @@ zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replacea
 		      </para>
 		    </entry>
 		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>tcp-self</varname>
+		      </para>
+		    </entry> <entry colname="2">
+		      <para>
+			Allow updates that have been sent via TCP and
+			for which the standard mapping from the initiating
+			IP address into the IN-ADDR.ARPA and IP6.ARPA
+			namespaces match the name to be updated.
+		      </para>
+		      <note>
+			It is theoretically possible to spoof these TCP
+			sessions.
+		      </note>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para>
+			<varname>6to4-self</varname>
+		      </para>
+		    </entry> <entry colname="2">
+		      <para>
+			Allow the 6to4 prefix to be update by any TCP
+			conection from the 6to4 network or from the
+			corresponding IPv4 address.  This is intended
+			to allow NS or DNAME RRsets to be added to the
+			reverse tree.
+		      </para>
+		      <note>
+			It is theoretically possible to spoof these TCP
+			sessions.
+		      </note>
+		    </entry>
+		  </row>
                 </tbody>
               </tgroup>
             </informaltable>
@@ -9293,16 +9879,15 @@ zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replacea
               specify a fully-qualified domain name.
             </para>
 
-            <para>
-              If no types are explicitly specified, this rule matches all
-              types except
-              RRSIG, NS, SOA, and NSEC. Types may be specified by name, including
-              "ANY" (ANY matches all types except NSEC, which can never be
-              updated).
-              Note that when an attempt is made to delete all records
-              associated with a
-              name, the rules are checked for each existing record type.
-            </para>
+	    <para>
+	      If no types are explicitly specified, this rule matches
+	      all types except RRSIG, NS, SOA, NSEC and NSEC3. Types
+	      may be specified by name, including "ANY" (ANY matches
+	      all types except NSEC and NSEC3, which can never be
+	      updated).  Note that when an attempt is made to delete
+	      all records associated with a name, the rules are
+	      checked for each existing record type.
+	    </para>
           </sect3>
         </sect2>
       </sect1>
@@ -9514,6 +10099,19 @@ zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replacea
                   <row rowsep="0">
                     <entry colname="1">
                       <para>
+                        DHCID
+                      </para>
+                    </entry>
+                    <entry colname="2">
+                      <para>
+			Is used for identifying which DHCP client is
+			associated with this name.  Described in RFC 4701.
+                      </para>
+                    </entry>
+                  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
                         DNAME
                       </para>
                     </entry>
@@ -9720,6 +10318,40 @@ zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replacea
                   <row rowsep="0">
                     <entry colname="1">
                       <para>
+                        NSEC3
+                      </para>
+                    </entry>
+		    <entry colname="2">
+		      <para>
+			Used in DNSSECbis to securely indicate that
+			RRs with an owner name in a certain name
+			interval do not exist in a zone and indicate
+			what RR types are present for an existing
+			name.  NSEC3 differs from NSEC in that it
+			prevents zone enumeration but is more
+			computationally expensive on both the server
+			and the client than NSEC.  Described in RFC
+			5155.
+		      </para>
+		    </entry>
+		  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
+                        NSEC3PARAM
+                      </para>
+                    </entry>
+		    <entry colname="2">
+		      <para>
+			Used in DNSSECbis to tell the authoritative
+			server which NSEC3 chains are available to use.
+			Described in RFC 5155.
+		      </para>
+		    </entry>
+		  </row>
+                  <row rowsep="0">
+                    <entry colname="1">
+                      <para>
                         NXT
                       </para>
                     </entry>
@@ -9865,7 +10497,7 @@ zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replacea
                     </entry>
                     <entry colname="2">
                       <para>
-			Provides a way to securly publish a secure shell key's
+			Provides a way to securely publish a secure shell key's
 			fingerprint.  Described in RFC 4255.
                       </para>
                     </entry>
@@ -10250,8 +10882,6 @@ zone <replaceable>zone_name</replaceable> <optional><replaceable>class</replacea
             the mail will be delivered to the server specified in the MX
             record
             pointed to by the CNAME.
-          </para>
-	  <para>
             For example:
           </para>
           <informaltable colsep="0" rowsep="0">
@@ -10690,7 +11320,7 @@ $GENERATE 1-127 $ CNAME $.0</programlisting>
 		      describes the owner name of the resource records
                       to be created.  Any single <command>$</command>
                       (dollar sign)
-                      symbols within the <command>lhs</command> side
+                      symbols within the <command>lhs</command> string
                       are replaced by the iterator value.
 
                       To get a $ in the output, you need to escape the
@@ -10734,7 +11364,7 @@ $GENERATE 1-127 $ CNAME $.0</programlisting>
                     <para>
 		      Specifies the time-to-live of the generated records. If
                       not specified this will be inherited using the
-                      normal ttl inheritance rules.
+                      normal TTL inheritance rules.
                     </para>
                     <para><command>class</command>
 		      and <command>ttl</command> can be
@@ -10834,15 +11464,1526 @@ $GENERATE 1-127 $ CNAME $.0</programlisting>
 	  </para>
 	</sect2>
       </sect1>
+
+      <sect1 id="statistics">
+        <title>BIND9 Statistics</title>
+        <para>
+	  <acronym>BIND</acronym> 9 maintains lots of statistics
+	  information and provides several interfaces for users to
+	  get access to the statistics.
+	  The available statistics include all statistics counters
+	  that were available in <acronym>BIND</acronym> 8 and
+	  are meaningful in <acronym>BIND</acronym> 9,
+	  and other information that is considered useful.
+        </para>
+
+        <para>
+	  The statistics information is categorized into the following
+	  sections.
+        </para>
+
+	<informaltable frame="all">
+          <tgroup cols="2">
+            <colspec colname="1" colnum="1" colsep="0" colwidth="3.300in"/>
+            <colspec colname="2" colnum="2" colsep="0" colwidth="2.625in"/>
+            <tbody>
+
+	      <row rowsep="0">
+                <entry colname="1">
+                  <para>Incoming Requests</para>
+                </entry>
+                <entry colname="2">
+                  <para>
+                    The number of incoming DNS requests for each OPCODE.
+                  </para>
+                </entry>
+	      </row>
+
+	      <row rowsep="0">
+                <entry colname="1">
+                  <para>Incoming Queries</para>
+                </entry>
+                <entry colname="2">
+                  <para>
+		    The number of incoming queries for each RR type.
+                  </para>
+                </entry>
+	      </row>
+
+	      <row rowsep="0">
+                <entry colname="1">
+                  <para>Outgoing Queries</para>
+                </entry>
+                <entry colname="2">
+                  <para>
+                    The number of outgoing queries for each RR
+                    type sent from the internal resolver.
+		    Maintained per view.
+                  </para>
+                </entry>
+	      </row>
+
+	      <row rowsep="0">
+                <entry colname="1">
+                  <para>Name Server Statistics</para>
+                </entry>
+                <entry colname="2">
+                  <para>
+                    Statistics counters about incoming request processing.
+                  </para>
+                </entry>
+	      </row>
+
+	      <row rowsep="0">
+                <entry colname="1">
+                  <para>Zone Maintenance Statistics</para>
+                </entry>
+                <entry colname="2">
+                  <para>
+                    Statistics counters regarding zone maintenance
+                    operations such as zone transfers.
+                  </para>
+                </entry>
+	      </row>
+
+	      <row rowsep="0">
+                <entry colname="1">
+                  <para>Resolver Statistics</para>
+                </entry>
+                <entry colname="2">
+                  <para>
+                    Statistics counters about name resolution
+                    performed in the internal resolver.
+		    Maintained per view.
+                  </para>
+                </entry>
+	      </row>
+
+	      <row rowsep="0">
+                <entry colname="1">
+                  <para>Cache DB RRsets</para>
+                </entry>
+                <entry colname="2">
+                  <para>
+                    The number of RRsets per RR type (positive
+                    or negative) and nonexistent names stored in the
+                    cache database.
+		    Maintained per view.
+                  </para>
+                </entry>
+	      </row>
+
+	      <row rowsep="0">
+                <entry colname="1">
+                  <para>Socket I/O Statistics</para>
+                </entry>
+                <entry colname="2">
+                  <para>
+                    Statistics counters about network related events.
+                  </para>
+                </entry>
+	      </row>
+
+	    </tbody>
+	  </tgroup>
+	</informaltable>
+
+	<para>
+	  A subset of Name Server Statistics is collected and shown
+	  per zone for which the server has the authority when
+	  <command>zone-statistics</command> is set to
+	  <userinput>yes</userinput>.
+	  These statistics counters are shown with their zone and view
+	  names.
+	  In some cases the view names are omitted for the default view.
+	</para>
+
+	<para>
+	  There are currently two user interfaces to get access to the
+	  statistics.
+	  One is in the plain text format dumped to the file specified
+	  by the <command>statistics-file</command> configuration option.
+	  The other is remotely accessible via a statistics channel
+	  when the <command>statistics-channels</command> statement
+	  is specified in the configuration file
+	  (see <xref linkend="statschannels"/>.)
+	</para>
+
+        <sect3 id="statsfile">
+          <title>The Statistics File</title>
+          <para>
+            The text format statistics dump begins with a line, like:
+	  </para>
+          <para>
+	    <command>+++ Statistics Dump +++ (973798949)</command>
+	  </para>
+	  <para>
+	    The number in parentheses is a standard
+            Unix-style timestamp, measured as seconds since January 1, 1970.
+
+            Following
+            that line is a set of statistics information, which is categorized
+            as described above.
+	    Each section begins with a line, like:
+	  </para>
+
+	  <para>
+	    <command>++ Name Server Statistics ++</command>
+	  </para>
+
+	  <para>
+	    Each section consists of lines, each containing the statistics
+	    counter value followed by its textual description.
+	    See below for available counters.
+	    For brevity, counters that have a value of 0 are not shown
+	    in the statistics file.
+	  </para>
+
+	  <para>
+	    The statistics dump ends with the line where the
+            number is identical to the number in the beginning line; for example:
+          </para>
+          <para>
+	    <command>--- Statistics Dump --- (973798949)</command>
+          </para>
+	</sect3>
+
+        <sect2 id="statistics_counters">
+	  <title>Statistics Counters</title>
+	  <para>
+	    The following tables summarize statistics counters that
+	    <acronym>BIND</acronym> 9 provides.
+	    For each row of the tables, the leftmost column is the
+	    abbreviated symbol name of that counter.
+	    These symbols are shown in the statistics information
+	    accessed via an HTTP statistics channel.
+	    The rightmost column gives the description of the counter,
+	    which is also shown in the statistics file
+	    (but, in this document, possibly with slight modification
+	    for better readability).
+	    Additional notes may also be provided in this column.
+	    When a middle column exists between these two columns,
+	    it gives the corresponding counter name of the
+	    <acronym>BIND</acronym> 8 statistics, if applicable.
+	  </para>
+
+	  <sect3>
+            <title>Name Server Statistics Counters</title>
+
+            <informaltable colsep="0" rowsep="0">
+              <tgroup cols="3" colsep="0" rowsep="0" tgroupstyle="4Level-table">
+		<colspec colname="1" colnum="1" colsep="0" colwidth="1.150in"/>
+		<colspec colname="2" colnum="2" colsep="0" colwidth="1.150in"/>
+		<colspec colname="3" colnum="3" colsep="0" colwidth="3.350in"/>
+		<tbody>
+		  <row>
+		    <entry colname="1">
+                      <para>
+			<emphasis>Symbol</emphasis>
+                      </para>
+		    </entry>
+		    <entry colname="2">
+                      <para>
+			<emphasis>BIND8 Symbol</emphasis>
+                      </para>
+		    </entry>
+		    <entry colname="3">
+                      <para>
+			<emphasis>Description</emphasis>
+                      </para>
+		    </entry>
+		  </row>
+
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>Requestv4</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RQ</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			IPv4 requests received.
+			Note: this also counts non query requests.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>Requestv6</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RQ</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			IPv6 requests received.
+			Note: this also counts non query requests.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>ReqEdns0</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Requests with EDNS(0) received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>ReqBadEDNSVer</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Requests with unsupported EDNS version received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>ReqTSIG</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Requests with TSIG received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>ReqSIG0</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Requests with SIG(0) received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>ReqBadSIG</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Requests with invalid (TSIG or SIG(0)) signature.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>ReqTCP</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RTCP</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			TCP requests received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>AuthQryRej</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RUQ</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Authoritative (non recursive) queries rejected.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>RecQryRej</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RURQ</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Recursive queries rejected.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>XfrRej</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RUXFR</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Zone transfer requests rejected.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>UpdateRej</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RUUpd</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Dynamic update requests rejected.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>Response</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>SAns</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Responses sent.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>RespTruncated</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Truncated responses sent.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>RespEDNS0</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Responses with EDNS(0) sent.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>RespTSIG</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Responses with TSIG sent.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>RespSIG0</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Responses with SIG(0) sent.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QrySuccess</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Queries resulted in a successful answer.
+			This means the query which returns a NOERROR response
+			with at least one answer RR.
+			This corresponds to the
+			<command>success</command> counter
+			of previous versions of
+			<acronym>BIND</acronym> 9.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QryAuthAns</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Queries resulted in authoritative answer.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QryNoauthAns</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>SNaAns</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Queries resulted in non authoritative answer.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QryReferral</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Queries resulted in referral answer.
+			This corresponds to the
+			<command>referral</command> counter
+			of previous versions of
+			<acronym>BIND</acronym> 9.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QryNxrrset</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Queries resulted in NOERROR responses with no data.
+			This corresponds to the
+			<command>nxrrset</command> counter
+			of previous versions of
+			<acronym>BIND</acronym> 9.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QrySERVFAIL</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>SFail</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Queries resulted in SERVFAIL.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QryFORMERR</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>SFErr</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Queries resulted in FORMERR.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QryNXDOMAIN</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>SNXD</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Queries resulted in NXDOMAIN.
+			This corresponds to the
+			<command>nxdomain</command> counter
+			of previous versions of
+			<acronym>BIND</acronym> 9.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QryRecursion</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RFwdQ</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Queries which caused the server
+			to perform recursion in order to find the final answer.
+			This corresponds to the
+			<command>recursion</command> counter
+			of previous versions of
+			<acronym>BIND</acronym> 9.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QryDuplicate</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RDupQ</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Queries which the server attempted to
+			recurse but discovered an existing query with the same
+			IP address, port, query ID, name, type and class
+			already being processed.
+			This corresponds to the
+			<command>duplicate</command> counter
+			of previous versions of
+			<acronym>BIND</acronym> 9.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QryDropped</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Recursive queries for which the server
+			discovered an excessive number of existing
+			recursive queries for the same name, type and
+			class and were subsequently dropped.
+			This is the number of dropped queries due to
+			the reason explained with the
+			<command>clients-per-query</command>
+			and
+			<command>max-clients-per-query</command>
+			options
+			(see the description about
+			<xref linkend="clients-per-query"/>.)
+			This corresponds to the
+			<command>dropped</command> counter
+			of previous versions of
+			<acronym>BIND</acronym> 9.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QryFailure</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Other query failures.
+			This corresponds to the
+			<command>failure</command> counter
+			of previous versions of
+			<acronym>BIND</acronym> 9.
+			Note: this counter is provided mainly for
+			backward compatibility with the previous versions.
+			Normally a more fine-grained counters such as
+			<command>AuthQryRej</command> and
+			<command>RecQryRej</command>
+			that would also fall into this counter are provided,
+			and so this counter would not be of much
+			interest in practice.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>XfrReqDone</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Requested zone transfers completed.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>UpdateReqFwd</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Update requests forwarded.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>UpdateRespFwd</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Update responses forwarded.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>UpdateFwdFail</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Dynamic update forward failed.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>UpdateDone</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Dynamic updates completed.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>UpdateFail</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Dynamic updates failed.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>UpdateBadPrereq</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Dynamic updates rejected due to prerequisite failure.
+		      </para>
+		    </entry>
+		  </row>
+		</tbody>
+              </tgroup>
+            </informaltable>
+          </sect3>
+
+	  <sect3>
+            <title>Zone Maintenance Statistics Counters</title>
+
+            <informaltable colsep="0" rowsep="0">
+              <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
+		<colspec colname="1" colnum="1" colsep="0" colwidth="1.150in"/>
+		<colspec colname="2" colnum="2" colsep="0" colwidth="3.350in"/>
+		<tbody>
+		  <row>
+		    <entry colname="1">
+                      <para>
+			<emphasis>Symbol</emphasis>
+                      </para>
+		    </entry>
+		    <entry colname="2">
+                      <para>
+			<emphasis>Description</emphasis>
+                      </para>
+		    </entry>
+		  </row>
+
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>NotifyOutv4</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			IPv4 notifies sent.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>NotifyOutv6</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			IPv6 notifies sent.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>NotifyInv4</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			IPv4 notifies received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>NotifyInv6</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			IPv6 notifies received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>NotifyRej</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Incoming notifies rejected.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>SOAOutv4</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			IPv4 SOA queries sent.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>SOAOutv6</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			IPv6 SOA queries sent.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>AXFRReqv4</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			IPv4 AXFR requested.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>AXFRReqv6</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			IPv6 AXFR requested.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>IXFRReqv4</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			IPv4 IXFR requested.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>IXFRReqv6</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			IPv6 IXFR requested.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>XfrSuccess</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Zone transfer requests succeeded.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>XfrFail</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Zone transfer requests failed.
+		      </para>
+		    </entry>
+		  </row>
+		</tbody>
+              </tgroup>
+            </informaltable>
+	  </sect3>
+
+	  <sect3>
+            <title>Resolver Statistics Counters</title>
+
+            <informaltable colsep="0" rowsep="0">
+              <tgroup cols="3" colsep="0" rowsep="0" tgroupstyle="4Level-table">
+		<colspec colname="1" colnum="1" colsep="0" colwidth="1.150in"/>
+		<colspec colname="2" colnum="2" colsep="0" colwidth="1.150in"/>
+		<colspec colname="3" colnum="3" colsep="0" colwidth="3.350in"/>
+		<tbody>
+		  <row>
+		    <entry colname="1">
+                      <para>
+			<emphasis>Symbol</emphasis>
+                      </para>
+		    </entry>
+		    <entry colname="2">
+                      <para>
+			<emphasis>BIND8 Symbol</emphasis>
+                      </para>
+		    </entry>
+		    <entry colname="3">
+                      <para>
+			<emphasis>Description</emphasis>
+                      </para>
+		    </entry>
+		  </row>
+
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>Queryv4</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>SFwdQ</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			IPv4 queries sent.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>Queryv6</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>SFwdQ</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			IPv6 queries sent.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>Responsev4</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RR</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			IPv4 responses received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>Responsev6</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RR</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			IPv6 responses received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>NXDOMAIN</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RNXD</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			NXDOMAIN received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>SERVFAIL</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RFail</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			SERVFAIL received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>FORMERR</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RFErr</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			FORMERR received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>OtherError</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RErr</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Other errors received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>EDNS0Fail</command></para>
+						 </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			EDNS(0) query failures.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>Mismatch</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RDupR</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Mismatch responses received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>Truncated</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Truncated responses received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>Lame</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>RLame</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Lame delegations received.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>Retry</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>SDupQ</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Query retries performed.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QueryAbort</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Queries aborted due to quota control.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QuerySockFail</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Failures in opening query sockets.
+			One common reason for such failures is a
+			failure of opening a new socket due to a
+			limitation on file descriptors.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QueryTimeout</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Query timeouts.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>GlueFetchv4</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>SSysQ</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			IPv4 NS address fetches invoked.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>GlueFetchv6</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command>SSysQ</command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			IPv6 NS address fetches invoked.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>GlueFetchv4Fail</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			IPv4 NS address fetch failed.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>GlueFetchv6Fail</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			IPv6 NS address fetch failed.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>ValAttempt</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			DNSSEC validation attempted.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>ValOk</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			DNSSEC validation succeeded.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>ValNegOk</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			DNSSEC validation on negative information succeeded.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>ValFail</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			DNSSEC validation failed.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>QryRTTnn</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para><command></command></para>
+		    </entry>
+		    <entry colname="3">
+		      <para>
+			Frequency table on round trip times (RTTs) of
+			queries.
+			Each <command>nn</command> specifies the corresponding
+			frequency.
+			In the sequence of
+			<command>nn_1</command>,
+			<command>nn_2</command>,
+			...,
+			<command>nn_m</command>,
+			the value of <command>nn_i</command> is the
+			number of queries whose RTTs are between
+			<command>nn_(i-1)</command> (inclusive) and
+			<command>nn_i</command> (exclusive) milliseconds.
+			For the sake of convenience we define
+			<command>nn_0</command> to be 0.
+			The last entry should be represented as
+			<command>nn_m+</command>, which means the
+			number of queries whose RTTs are equal to or over
+			<command>nn_m</command> milliseconds.
+		      </para>
+		    </entry>
+		  </row>
+		</tbody>
+              </tgroup>
+            </informaltable>
+
+	  </sect3>
+
+	  <sect3>
+            <title>Socket I/O Statistics Counters</title>
+
+	    <para>
+	      Socket I/O statistics counters are defined per socket
+	      types, which are
+	      <command>UDP4</command> (UDP/IPv4),
+	      <command>UDP6</command> (UDP/IPv6),
+	      <command>TCP4</command> (TCP/IPv4),
+	      <command>TCP6</command> (TCP/IPv6),
+	      <command>Unix</command> (Unix Domain), and
+	      <command>FDwatch</command> (sockets opened outside the
+	      socket module).
+	      In the following table <command>&lt;TYPE&gt;</command>
+	      represents a socket type.
+	      Not all counters are available for all socket types;
+	      exceptions are noted in the description field.
+	    </para>
+
+	    <informaltable colsep="0" rowsep="0">
+              <tgroup cols="2" colsep="0" rowsep="0" tgroupstyle="4Level-table">
+		<colspec colname="1" colnum="1" colsep="0" colwidth="1.150in"/>
+		<colspec colname="2" colnum="2" colsep="0" colwidth="3.350in"/>
+		<tbody>
+		  <row>
+		    <entry colname="1">
+                      <para>
+			<emphasis>Symbol</emphasis>
+                      </para>
+		    </entry>
+		    <entry colname="2">
+                      <para>
+			<emphasis>Description</emphasis>
+                      </para>
+		    </entry>
+		  </row>
+
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>&lt;TYPE&gt;Open</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Sockets opened successfully.
+			This counter is not applicable to the
+			<command>FDwatch</command> type.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>&lt;TYPE&gt;OpenFail</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Failures of opening sockets.
+			This counter is not applicable to the
+			<command>FDwatch</command> type.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>&lt;TYPE&gt;Close</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Sockets closed.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>&lt;TYPE&gt;BindFail</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Failures of binding sockets.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>&lt;TYPE&gt;ConnFail</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Failures of connecting sockets.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>&lt;TYPE&gt;Conn</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Connections established successfully.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>&lt;TYPE&gt;AcceptFail</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Failures of accepting incoming connection requests.
+			This counter is not applicable to the
+			<command>UDP</command> and
+			<command>FDwatch</command> types.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>&lt;TYPE&gt;Accept</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Incoming connections successfully accepted.
+			This counter is not applicable to the
+			<command>UDP</command> and
+			<command>FDwatch</command> types.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>&lt;TYPE&gt;SendErr</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Errors in socket send operations.
+			This counter corresponds
+			to <command>SErr</command> counter of
+			<command>BIND</command> 8.
+		      </para>
+		    </entry>
+		  </row>
+		  <row rowsep="0">
+		    <entry colname="1">
+		      <para><command>&lt;TYPE&gt;RecvErr</command></para>
+		    </entry>
+		    <entry colname="2">
+		      <para>
+			Errors in socket receive operations.
+			This includes errors of send operations on a
+			connected UDP socket notified by an ICMP error
+			message.
+		      </para>
+		    </entry>
+		  </row>
+		</tbody>
+              </tgroup>
+	    </informaltable>
+	  </sect3>
+	  <sect3>
+            <title>Compatibility with <emphasis>BIND</emphasis> 8 Counters</title>
+	    <para>
+	      Most statistics counters that were available
+	      in <command>BIND</command> 8 are also supported in
+	      <command>BIND</command> 9 as shown in the above tables.
+	      Here are notes about other counters that do not appear
+	      in these tables.
+	    </para>
+
+            <variablelist>
+              <varlistentry>
+		<term><command>RFwdR,SFwdR</command></term>
+		<listitem>
+		  <para>
+		    These counters are not supported
+		    because <command>BIND</command> 9 does not adopt
+		    the notion of <emphasis>forwarding</emphasis>
+		    as <command>BIND</command> 8 did.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+              <varlistentry>
+		<term><command>RAXFR</command></term>
+		<listitem>
+		  <para>
+		    This counter is accessible in the Incoming Queries section.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+              <varlistentry>
+		<term><command>RIQ</command></term>
+		<listitem>
+		  <para>
+		    This counter is accessible in the Incoming Requests section.
+		  </para>
+		</listitem>
+	      </varlistentry>
+
+              <varlistentry>
+		<term><command>ROpts</command></term>
+		<listitem>
+		  <para>
+		    This counter is not supported
+		    because <command>BIND</command> 9 does not care
+		    about IP options in the first place.
+		  </para>
+		</listitem>
+	      </varlistentry>
+	    </variablelist>
+	  </sect3>
+        </sect2>
+      </sect1>
+
     </chapter>
     <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
+          Access Control Lists (ACLs) are address match lists that
           you can set up and nickname for future use in <command>allow-notify</command>,
-          <command>allow-query</command>, <command>allow-recursion</command>,
+          <command>allow-query</command>, <command>allow-query-on</command>,
+	  <command>allow-recursion</command>, <command>allow-recursion-on</command>,
           <command>blackhole</command>, <command>allow-transfer</command>,
           etc.
         </para>
@@ -10904,11 +13045,13 @@ zone "example.com" {
       <sect1>
         <title><command>Chroot</command> and <command>Setuid</command></title>
         <para>
-          On UNIX servers, it is possible to run <acronym>BIND</acronym> in a <emphasis>chrooted</emphasis> environment
-          (using the <command>chroot()</command> function) by specifying the "<option>-t</option>"
-          option. This can help improve system security by placing <acronym>BIND</acronym> in
-          a "sandbox", which will limit the damage done if a server is
-          compromised.
+	  On UNIX servers, it is possible to run <acronym>BIND</acronym>
+	  in a <emphasis>chrooted</emphasis> environment (using
+	  the <command>chroot()</command> function) by specifying
+	  the "<option>-t</option>" option for <command>named</command>.
+	  This can help improve system security by placing
+	  <acronym>BIND</acronym> in a "sandbox", which will limit
+	  the damage done if a server is compromised.
         </para>
         <para>
           Another useful feature in the UNIX version of <acronym>BIND</acronym> is the
@@ -10921,7 +13064,7 @@ zone "example.com" {
           user 202:
         </para>
         <para>
-          <userinput>/usr/local/bin/named -u 202 -t /var/named</userinput>
+          <userinput>/usr/local/sbin/named -u 202 -t /var/named</userinput>
         </para>
 
         <sect2>
@@ -11187,11 +13330,9 @@ zone "example.com" {
 	    BIND architecture.
           </para>
           <para>
-	    BIND version 4 is officially deprecated and BIND version
-	    8 development is considered maintenance-only in favor
-	    of BIND version 9. No additional development is done
-	    on BIND version 4 or BIND version 8 other than for
-	    security-related patches.
+	    BIND versions 4 and 8 are officially deprecated.
+	    No additional development is done
+	    on BIND version 4 or BIND version 8.
           </para>
           <para>
             <acronym>BIND</acronym> development work is made
@@ -11554,7 +13695,7 @@ zone "example.com" {
 		<pubdate>March 2005</pubdate>
 	      </biblioentry>
 	      <biblioentry>
-	        <abbrev>RFC4044</abbrev>
+	        <abbrev>RFC4034</abbrev>
 	 	<authorgroup>
 		  <author>
 		    <firstname>R.</firstname>
@@ -12518,13 +14659,15 @@ zone "example.com" {
       <title>Manual pages</title>
       <xi:include href="../../bin/dig/dig.docbook"/>
       <xi:include href="../../bin/dig/host.docbook"/>
+      <xi:include href="../../bin/dnssec/dnssec-dsfromkey.docbook"/>
+      <xi:include href="../../bin/dnssec/dnssec-keyfromlabel.docbook"/>
       <xi:include href="../../bin/dnssec/dnssec-keygen.docbook"/>
       <xi:include href="../../bin/dnssec/dnssec-signzone.docbook"/>
       <xi:include href="../../bin/check/named-checkconf.docbook"/>
       <xi:include href="../../bin/check/named-checkzone.docbook"/>
       <xi:include href="../../bin/named/named.docbook"/>
       <!-- named.conf.docbook and others? -->
-      <!-- nsupdate gives db2latex indigestion, markup problems? -->
+      <xi:include href="../../bin/nsupdate/nsupdate.docbook"/>
       <xi:include href="../../bin/rndc/rndc.docbook"/>
       <xi:include href="../../bin/rndc/rndc.conf.docbook"/>
       <xi:include href="../../bin/rndc/rndc-confgen.docbook"/>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch01.html b/contrib/bind9/doc/arm/Bv9ARM.ch01.html
index 76a4bb7..320a867 100644
--- a/contrib/bind9/doc/arm/Bv9ARM.ch01.html
+++ b/contrib/bind9/doc/arm/Bv9ARM.ch01.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch01.html,v 1.16.18.26 2008/05/24 01:31:10 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch01.html,v 1.43.48.2 2009/04/03 01:52:22 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -45,17 +45,17 @@
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2563405">Scope of Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564385">Organization of This Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564524">Conventions Used in This Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564637">The Domain Name System (<acronym class="acronym">DNS</acronym>)</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2563409">Scope of Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564388">Organization of This Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564528">Conventions Used in This Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564641">The Domain Name System (<acronym class="acronym">DNS</acronym>)</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564659">DNS Fundamentals</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564693">Domains and Domain Names</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564845">Zones</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567243">Authoritative Name Servers</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567416">Caching Name Servers</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567546">Name Servers in Multiple Roles</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564662">DNS Fundamentals</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564696">Domains and Domain Names</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567170">Zones</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567246">Authoritative Name Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567419">Caching Name Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567549">Name Servers in Multiple Roles</a></span></dt>
 </dl></dd>
 </dl>
 </div>
@@ -71,7 +71,7 @@
     </p>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2563405"></a>Scope of Document</h2></div></div></div>
+<a name="id2563409"></a>Scope of Document</h2></div></div></div>
 <p>
         The Berkeley Internet Name Domain
         (<acronym class="acronym">BIND</acronym>) implements a
@@ -82,30 +82,30 @@
         system administrators.
       </p>
 <p>
-        This version of the manual corresponds to BIND version 9.4.
+        This version of the manual corresponds to BIND version 9.6.
       </p>
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2564385"></a>Organization of This Document</h2></div></div></div>
+<a name="id2564388"></a>Organization of This Document</h2></div></div></div>
 <p>
-        In this document, <span class="emphasis"><em>Section 1</em></span> introduces
-        the basic <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym> concepts. <span class="emphasis"><em>Section 2</em></span>
+        In this document, <span class="emphasis"><em>Chapter 1</em></span> introduces
+        the basic <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym> concepts. <span class="emphasis"><em>Chapter 2</em></span>
         describes resource requirements for running <acronym class="acronym">BIND</acronym> in various
-        environments. Information in <span class="emphasis"><em>Section 3</em></span> is
+        environments. Information in <span class="emphasis"><em>Chapter 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"><em>Section 4</em></span>, which contains more advanced
+        <span class="emphasis"><em>Chapter 4</em></span>, which contains more advanced
         concepts that the system administrator may need for implementing
-        certain options. <span class="emphasis"><em>Section 5</em></span>
+        certain options. <span class="emphasis"><em>Chapter 5</em></span>
         describes the <acronym class="acronym">BIND</acronym> 9 lightweight
-        resolver.  The contents of <span class="emphasis"><em>Section 6</em></span> are
+        resolver.  The contents of <span class="emphasis"><em>Chapter 6</em></span> are
         organized as in a reference manual to aid in the ongoing
-        maintenance of the software. <span class="emphasis"><em>Section 7</em></span> addresses
+        maintenance of the software. <span class="emphasis"><em>Chapter 7</em></span> addresses
         security considerations, and
-        <span class="emphasis"><em>Section 8</em></span> contains troubleshooting help. The
+        <span class="emphasis"><em>Chapter 8</em></span> contains troubleshooting help. The
         main body of the document is followed by several
         <span class="emphasis"><em>appendices</em></span> which contain useful reference
         information, such as a <span class="emphasis"><em>bibliography</em></span> and
@@ -116,7 +116,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2564524"></a>Conventions Used in This Document</h2></div></div></div>
+<a name="id2564528"></a>Conventions Used in This Document</h2></div></div></div>
 <p>
         In this document, we use the following general typographic
         conventions:
@@ -243,7 +243,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2564637"></a>The Domain Name System (<acronym class="acronym">DNS</acronym>)</h2></div></div></div>
+<a name="id2564641"></a>The Domain Name System (<acronym class="acronym">DNS</acronym>)</h2></div></div></div>
 <p>
         The purpose of this document is to explain the installation
         and upkeep of the <acronym class="acronym">BIND</acronym> (Berkeley Internet
@@ -253,7 +253,7 @@
       </p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2564659"></a>DNS Fundamentals</h3></div></div></div>
+<a name="id2564662"></a>DNS Fundamentals</h3></div></div></div>
 <p>
           The Domain Name System (DNS) is a hierarchical, distributed
           database.  It stores information for mapping Internet host names to
@@ -267,13 +267,15 @@
           more <span class="emphasis"><em>name servers</em></span> and interprets the responses.
           The <acronym class="acronym">BIND</acronym> 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>.
+          name server, <span><strong class="command">named</strong></span>, and a resolver
+          library, <span><strong class="command">liblwres</strong></span>.  The older
+          <span><strong class="command">libbind</strong></span> resolver library is also available
+          from ISC as a separate download.
         </p>
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2564693"></a>Domains and Domain Names</h3></div></div></div>
+<a name="id2564696"></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,
@@ -319,7 +321,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2564845"></a>Zones</h3></div></div></div>
+<a name="id2567170"></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>
@@ -372,7 +374,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2567243"></a>Authoritative Name Servers</h3></div></div></div>
+<a name="id2567246"></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>,
@@ -389,7 +391,7 @@
         </p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2567267"></a>The Primary Master</h4></div></div></div>
+<a name="id2567270"></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
@@ -409,7 +411,7 @@
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2567297"></a>Slave Servers</h4></div></div></div>
+<a name="id2567300"></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)
@@ -425,7 +427,7 @@
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2567386"></a>Stealth Servers</h4></div></div></div>
+<a name="id2567389"></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
@@ -460,7 +462,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2567416"></a>Caching Name Servers</h3></div></div></div>
+<a name="id2567419"></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
@@ -487,7 +489,7 @@
         </p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2567520"></a>Forwarding</h4></div></div></div>
+<a name="id2567523"></a>Forwarding</h4></div></div></div>
 <p>
             Even a caching name server does not necessarily perform
             the complete recursive lookup itself.  Instead, it can
@@ -514,7 +516,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2567546"></a>Name Servers in Multiple Roles</h3></div></div></div>
+<a name="id2567549"></a>Name Servers in Multiple Roles</h3></div></div></div>
 <p>
           The <acronym class="acronym">BIND</acronym> name server can
           simultaneously act as
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch02.html b/contrib/bind9/doc/arm/Bv9ARM.ch02.html
index f2abce4..831e7a1 100644
--- a/contrib/bind9/doc/arm/Bv9ARM.ch02.html
+++ b/contrib/bind9/doc/arm/Bv9ARM.ch02.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch02.html,v 1.13.18.28 2008/09/12 01:32:08 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch02.html,v 1.38.56.1 2009/01/08 01:50:59 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -45,16 +45,16 @@
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567580">Hardware requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567607">CPU Requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567620">Memory Requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567851">Name Server Intensive Environment Issues</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567862">Supported Operating Systems</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567584">Hardware requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567610">CPU Requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567623">Memory Requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567854">Name Server Intensive Environment Issues</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567865">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="id2567580"></a>Hardware requirements</h2></div></div></div>
+<a name="id2567584"></a>Hardware requirements</h2></div></div></div>
 <p>
         <acronym class="acronym">DNS</acronym> hardware requirements have
         traditionally been quite modest.
@@ -73,7 +73,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567607"></a>CPU Requirements</h2></div></div></div>
+<a name="id2567610"></a>CPU Requirements</h2></div></div></div>
 <p>
         CPU requirements for <acronym class="acronym">BIND</acronym> 9 range from
         i486-class machines
@@ -84,7 +84,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567620"></a>Memory Requirements</h2></div></div></div>
+<a name="id2567623"></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>
@@ -107,7 +107,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567851"></a>Name Server Intensive Environment Issues</h2></div></div></div>
+<a name="id2567854"></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
@@ -124,14 +124,16 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2567862"></a>Supported Operating Systems</h2></div></div></div>
+<a name="id2567865"></a>Supported Operating Systems</h2></div></div></div>
 <p>
         ISC <acronym class="acronym">BIND</acronym> 9 compiles and runs on a large
-        number of Unix-like operating systems, and on some versions of
-        Microsoft Windows including Windows XP, Windows 2003, and
-        Windows 2008.  For an up-to-date list of supported systems,
-        see the README file in the top level directory of the BIND 9
-        source distribution.
+        number
+        of Unix-like operating systems and on NT-derived versions of
+        Microsoft Windows such as Windows 2000 and Windows XP.  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>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch03.html b/contrib/bind9/doc/arm/Bv9ARM.ch03.html
index 4d39c51..9964823 100644
--- a/contrib/bind9/doc/arm/Bv9ARM.ch03.html
+++ b/contrib/bind9/doc/arm/Bv9ARM.ch03.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch03.html,v 1.35.18.36 2008/05/24 01:31:10 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch03.html,v 1.71.48.2 2009/04/03 01:52:21 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -47,19 +47,19 @@
 <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#id2567894">A Caching-only Name Server</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567910">An Authoritative-only Name Server</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567897">A Caching-only Name Server</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567913">An Authoritative-only Name Server</a></span></dt>
 </dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568001">Load Balancing</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568423">Name Server Operations</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568004">Load Balancing</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568358">Name Server Operations</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568428">Tools for Use With the Name Server Daemon</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2570142">Signals</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568363">Tools for Use With the Name Server Daemon</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2570071">Signals</a></span></dt>
 </dl></dd>
 </dl>
 </div>
 <p>
-      In this section we provide some suggested configurations along
+      In this chapter we provide some suggested configurations along
       with guidelines for their use.  We suggest reasonable values for
       certain option settings.
     </p>
@@ -68,7 +68,7 @@
 <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="id2567894"></a>A Caching-only Name Server</h3></div></div></div>
+<a name="id2567897"></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
@@ -95,7 +95,7 @@ zone "0.0.127.in-addr.arpa" {
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2567910"></a>An Authoritative-only Name Server</h3></div></div></div>
+<a name="id2567913"></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>"
@@ -137,7 +137,7 @@ zone "eng.example.com" {
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2568001"></a>Load Balancing</h2></div></div></div>
+<a name="id2568004"></a>Load Balancing</h2></div></div></div>
 <p>
         A primitive form of load balancing can be achieved in
         the <acronym class="acronym">DNS</acronym> by using multiple records
@@ -280,10 +280,10 @@ zone "eng.example.com" {
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2568423"></a>Name Server Operations</h2></div></div></div>
+<a name="id2568358"></a>Name Server Operations</h2></div></div></div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2568428"></a>Tools for Use With the Name Server Daemon</h3></div></div></div>
+<a name="id2568363"></a>Tools for Use With the Name Server Daemon</h3></div></div></div>
 <p>
           This section describes several indispensable diagnostic,
           administrative and monitoring tools available to the system
@@ -315,7 +315,7 @@ zone "eng.example.com" {
                 </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
+                  The usual simple use of <span><strong class="command">dig</strong></span> will take the form
                 </p>
 <p>
                   <span><strong class="command">dig @server domain query-type query-class</strong></span>
@@ -541,8 +541,8 @@ zone "eng.example.com" {
                         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.
-                        If -p is specified named's process id is returned.
-                        This allows an external process to determine when named
+                        If <code class="option">-p</code> is specified <span><strong class="command">named</strong></span>'s process id is returned.
+                        This allows an external process to determine when <span><strong class="command">named</strong></span>
                         had completed stopping.
                       </p></dd>
 <dt><span class="term"><strong class="userinput"><code>halt [<span class="optional">-p</span>]</code></strong></span></dt>
@@ -551,8 +551,8 @@ zone "eng.example.com" {
                         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.
-                        If -p is specified named's process id is returned.
-                        This allows an external process to determine when named
+                        If <code class="option">-p</code> is specified <span><strong class="command">named</strong></span>'s process id is returned.
+                        This allows an external process to determine when <span><strong class="command">named</strong></span>
                         had completed halting.
                       </p></dd>
 <dt><span class="term"><strong class="userinput"><code>trace</code></strong></span></dt>
@@ -586,9 +586,19 @@ zone "eng.example.com" {
                       </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
+                        Dump the list of queries <span><strong class="command">named</strong></span> is currently recursing
                         on.
                       </p></dd>
+<dt><span class="term"><strong class="userinput"><code>validation
+                        [<span class="optional">on|off</span>]
+                        [<span class="optional"><em class="replaceable"><code>view ...</code></em></span>]
+                    </code></strong></span></dt>
+<dd><p>
+                        Enable or disable DNSSEC validation.
+                        Note <span><strong class="command">dnssec-enable</strong></span> also needs to be
+                        set to <strong class="userinput"><code>yes</code></strong> to be effective.
+                        It defaults to enabled.
+                      </p></dd>
 </dl></div>
 <p>
                   A configuration file is required, since all
@@ -651,7 +661,7 @@ zone "eng.example.com" {
                   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.
+                  <span><strong class="command">key</strong></span> statement in <code class="filename">named.conf</code>.
                   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;
@@ -739,7 +749,7 @@ controls {
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2570142"></a>Signals</h3></div></div></div>
+<a name="id2570071"></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
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch04.html b/contrib/bind9/doc/arm/Bv9ARM.ch04.html
index e31d85d..123098e 100644
--- a/contrib/bind9/doc/arm/Bv9ARM.ch04.html
+++ b/contrib/bind9/doc/arm/Bv9ARM.ch04.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch04.html,v 1.40.18.46 2008/05/24 01:31:11 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch04.html,v 1.87.48.2 2009/04/03 01:52:21 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -49,29 +49,29 @@
 <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#id2570600">Split DNS</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2570618">Example split DNS setup</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2564066">Split DNS</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2564084">Example split DNS setup</a></span></dt></dl></dd>
 <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#id2570985">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571127">Copying the Shared Secret to Both Machines</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571138">Informing the Servers of the Key's Existence</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571177">Instructing the Server to Use the Key</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571303">TSIG Key Based Access Control</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571416">Errors</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571141">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571214">Copying the Shared Secret to Both Machines</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571225">Informing the Servers of the Key's Existence</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571268">Instructing the Server to Use the Key</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571325">TSIG Key Based Access Control</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571510">Errors</a></span></dt>
 </dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571430">TKEY</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571547">SIG(0)</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571524">TKEY</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571709">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#id2571684">Generating Keys</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571753">Signing the Zone</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571832">Configuring Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571778">Generating Keys</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571925">Signing the Zone</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572006">Configuring Servers</a></span></dt>
 </dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571975">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572220">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572173">Address Lookups Using AAAA Records</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572195">Address to Name Lookups Using Nibble Format</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572282">Address Lookups Using AAAA Records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572304">Address to Name Lookups Using Nibble Format</a></span></dt>
 </dl></dd>
 </dl>
 </div>
@@ -95,10 +95,10 @@
       </p>
 <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
 <h3 class="title">Note</h3>
-        As a slave zone can also be a master to other slaves, named,
+        As a slave zone can also be a master to other slaves, <span><strong class="command">named</strong></span>,
         by default, sends <span><strong class="command">NOTIFY</strong></span> messages for every zone
         it loads.  Specifying <span><strong class="command">notify master-only;</strong></span> will
-        cause named to only send <span><strong class="command">NOTIFY</strong></span> for master
+        cause <span><strong class="command">named</strong></span> to only send <span><strong class="command">NOTIFY</strong></span> for master
         zones that it loads.
       </div>
 </div>
@@ -112,17 +112,22 @@
         in RFC 2136.
       </p>
 <p>
-        Dynamic update is enabled 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.
+        Dynamic update is enabled 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.  The
+        <span><strong class="command">tkey-gssapi-credential</strong></span> and
+        <span><strong class="command">tkey-domain</strong></span> clauses in the
+        <span><strong class="command">options</strong></span>        statement enable the
+        server to negotiate keys that can be matched against those
+        in <span><strong class="command">update-policy</strong></span> or
+        <span><strong class="command">allow-update</strong></span>.
       </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.
+        Updating of secure zones (zones using DNSSEC) follows RFC
+        3007: RRSIG, NSEC and NSEC3 records affected by updates are
+        automatically regenerated by the server using an online
+        zone key.  Update authorization is based on transaction
+        signatures and an explicit server policy.
       </p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
@@ -205,7 +210,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2570600"></a>Split DNS</h2></div></div></div>
+<a name="id2564066"></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
@@ -235,7 +240,7 @@
       </p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2570618"></a>Example split DNS setup</h3></div></div></div>
+<a name="id2564084"></a>Example split DNS setup</h3></div></div></div>
 <p>
         Let's say a company named <span class="emphasis"><em>Example, Inc.</em></span>
         (<code class="literal">example.com</code>)
@@ -481,7 +486,7 @@ nameserver 172.16.72.4
       </p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2570985"></a>Generate Shared Keys for Each Pair of Hosts</h3></div></div></div>
+<a name="id2571141"></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
@@ -489,7 +494,7 @@ nameserver 172.16.72.4
         </p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2571070"></a>Automatic Generation</h4></div></div></div>
+<a name="id2571158"></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
@@ -514,7 +519,7 @@ nameserver 172.16.72.4
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2571109"></a>Manual Generation</h4></div></div></div>
+<a name="id2571196"></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
@@ -529,7 +534,7 @@ nameserver 172.16.72.4
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2571127"></a>Copying the Shared Secret to Both Machines</h3></div></div></div>
+<a name="id2571214"></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.
@@ -537,7 +542,7 @@ nameserver 172.16.72.4
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2571138"></a>Informing the Servers of the Key's Existence</h3></div></div></div>
+<a name="id2571225"></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
@@ -550,7 +555,7 @@ key host1-host2. {
 };
 </pre>
 <p>
-          The algorithm, hmac-md5, is the only one supported by <acronym class="acronym">BIND</acronym>.
+          The algorithm, <code class="literal">hmac-md5</code>, is the only one supported by <acronym class="acronym">BIND</acronym>.
           The secret is the one generated above. Since this is a secret, it
           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
@@ -566,7 +571,7 @@ key host1-host2. {
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2571177"></a>Instructing the Server to Use the Key</h3></div></div></div>
+<a name="id2571268"></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
@@ -598,7 +603,7 @@ server 10.1.2.3 {
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2571303"></a>TSIG Key Based Access Control</h3></div></div></div>
+<a name="id2571325"></a>TSIG Key Based Access Control</h3></div></div></div>
 <p>
           <acronym class="acronym">BIND</acronym> allows IP addresses and ranges
           to be specified in ACL
@@ -609,24 +614,24 @@ server 10.1.2.3 {
           be denoted <span><strong class="command">key host1-host2.</strong></span>
         </p>
 <p>
-          An example of an allow-update directive would be:
+          An example of an <span><strong class="command">allow-update</strong></span> 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
-          "<span><strong class="command">host1-host2.</strong></span>".
+          was signed by a key named "<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>.
+          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="id2571416"></a>Errors</h3></div></div></div>
+<a name="id2571510"></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
@@ -652,7 +657,7 @@ allow-update { key host1-host2. ;};
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2571430"></a>TKEY</h2></div></div></div>
+<a name="id2571524"></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
@@ -688,10 +693,10 @@ allow-update { key host1-host2. ;};
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2571547"></a>SIG(0)</h2></div></div></div>
+<a name="id2571709"></a>SIG(0)</h2></div></div></div>
 <p>
         <acronym class="acronym">BIND</acronym> 9 partially supports DNSSEC SIG(0)
-            transaction signatures as specified in RFC 2535 and RFC2931.
+            transaction signatures as specified in RFC 2535 and RFC 2931.
         SIG(0)
         uses public/private keys to authenticate messages.  Access control
         is performed in the same manner as TSIG keys; privileges can be
@@ -749,7 +754,7 @@ allow-update { key host1-host2. ;};
       </p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2571684"></a>Generating Keys</h3></div></div></div>
+<a name="id2571778"></a>Generating Keys</h3></div></div></div>
 <p>
           The <span><strong class="command">dnssec-keygen</strong></span> program is used to
           generate keys.
@@ -793,6 +798,11 @@ allow-update { key host1-host2. ;};
           a different key tag), repeat the above command.
         </p>
 <p>
+          The <span><strong class="command">dnssec-keyfromlabel</strong></span> program is used
+          to get a key pair from a crypto hardware and build the key
+          files. Its usage is similar to <span><strong class="command">dnssec-keygen</strong></span>.
+        </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.
@@ -800,22 +810,20 @@ allow-update { key host1-host2. ;};
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2571753"></a>Signing the Zone</h3></div></div></div>
+<a name="id2571925"></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.
+          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 <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.
+          Any <code class="filename">keyset</code> files corresponding to
+          secure subzones should be present.  The zone signer will
+          generate <code class="literal">NSEC</code>, <code class="literal">NSEC3</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">'-g'</code> is specified.  If <code class="literal">'-g'</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
@@ -844,7 +852,7 @@ allow-update { key host1-host2. ;};
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2571832"></a>Configuring Servers</h3></div></div></div>
+<a name="id2572006"></a>Configuring Servers</h3></div></div></div>
 <p>
           To enable <span><strong class="command">named</strong></span> to respond appropriately
           to DNS requests from DNSSEC aware clients,
@@ -881,7 +889,7 @@ allow-update { key host1-host2. ;};
           more public keys for the root.  This allows answers from
           outside the organization to be validated.  It will also
           have several keys for parts of the namespace the organization
-          controls.  These are here to ensure that named is immune
+          controls.  These are here to ensure that <span><strong class="command">named</strong></span> is immune
           to compromises in the DNSSEC components of the security
           of parent zones.
         </p>
@@ -932,7 +940,7 @@ options {
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2571975"></a>IPv6 Support in <acronym class="acronym">BIND</acronym> 9</h2></div></div></div>
+<a name="id2572220"></a>IPv6 Support in <acronym class="acronym">BIND</acronym> 9</h2></div></div></div>
 <p>
         <acronym class="acronym">BIND</acronym> 9 fully supports all currently
         defined forms of IPv6
@@ -971,7 +979,7 @@ options {
       </p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2572173"></a>Address Lookups Using AAAA Records</h3></div></div></div>
+<a name="id2572282"></a>Address Lookups Using AAAA Records</h3></div></div></div>
 <p>
           The IPv6 AAAA record is a parallel to the IPv4 A record,
           and, unlike the deprecated A6 record, specifies the entire
@@ -990,7 +998,7 @@ host            3600    IN      AAAA    2001:db8::1
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2572195"></a>Address to Name Lookups Using Nibble Format</h3></div></div></div>
+<a name="id2572304"></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
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch05.html b/contrib/bind9/doc/arm/Bv9ARM.ch05.html
index 33d1d0d..addc97a 100644
--- a/contrib/bind9/doc/arm/Bv9ARM.ch05.html
+++ b/contrib/bind9/doc/arm/Bv9ARM.ch05.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch05.html,v 1.33.18.38 2008/05/24 01:31:11 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch05.html,v 1.71.48.2 2009/04/03 01:52:21 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -45,13 +45,13 @@
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch05.html#id2572228">The Lightweight Resolver Library</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch05.html#id2572337">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="id2572228"></a>The Lightweight Resolver Library</h2></div></div></div>
+<a name="id2572337"></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
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch06.html b/contrib/bind9/doc/arm/Bv9ARM.ch06.html
index e292906..10b7fd5 100644
--- a/contrib/bind9/doc/arm/Bv9ARM.ch06.html
+++ b/contrib/bind9/doc/arm/Bv9ARM.ch06.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch06.html,v 1.82.18.88 2008/10/18 01:29:58 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch06.html,v 1.201.14.8 2009/04/03 01:52:21 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -48,54 +48,59 @@
 <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#id2573436">Comment Syntax</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2573716">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#id2574117"><span><strong class="command">acl</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574346"><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#id2574307"><span><strong class="command">controls</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574536"><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#id2574736"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574753"><span><strong class="command">include</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574965"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574982"><span><strong class="command">include</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574776"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574800"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574958"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575084"><span><strong class="command">logging</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575005"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575029"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575120"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575245"><span><strong class="command">logging</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576435"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576508"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576572"><span><strong class="command">masters</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576616"><span><strong class="command">masters</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577306"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577448"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577512"><span><strong class="command">masters</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577556"><span><strong class="command">masters</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576631"><span><strong class="command">options</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577571"><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#id2585614"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2585666"><span><strong class="command">trusted-keys</strong></span> Statement Definition
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#statschannels"><span><strong class="command">statistics-channels</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586754"><span><strong class="command">statistics-channels</strong></span> Statement Definition and
+            Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586908"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586960"><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#id2585748"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2587042"><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#id2587332"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588510"><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#id2589477">Zone File</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2591109">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#id2591500">Discussion of MX Records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2593203">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#id2592188">Inverse Mapping in IPv4</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592384">Other Zone File Directives</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592572"><acronym class="acronym">BIND</acronym> Master File Extension: the  <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2593886">Inverse Mapping in IPv4</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2594013">Other Zone File Directives</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2594270"><acronym class="acronym">BIND</acronym> Master File Extension: the  <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#zonefile_format">Additional File Formats</a></span></dt>
 </dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch06.html#statistics">BIND9 Statistics</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch06.html#statistics_counters">Statistics Counters</a></span></dt></dl></dd>
 </dl>
 </div>
 <p>
@@ -221,27 +226,23 @@
 <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.
-                  It is strongly recommended to use string zone names rather
-                  than
-                  numeric identifiers, in order to be robust against system
-                  configuration changes.
-                  However, since there is no standard mapping for such names
-                  and
-                  identifier values, currently only interface names as link
-                  identifiers
+                  IPv6 scoped addresses that have ambiguity on their
+                  scope zones must be disambiguated by an appropriate
+                  zone ID with the percent character (`%') as
+                  delimiter.  It is strongly recommended to use
+                  string zone names rather than numeric identifiers,
+                  in order to be robust against system configuration
+                  changes.  However, since there is no standard
+                  mapping for such names and identifier values,
+                  currently only interface names as link identifiers
                   are supported, assuming one-to-one mapping between
-                  interfaces and links.
-                  For example, a link-local address <span><strong class="command">fe80::1</strong></span> on the
-                  link attached to the interface <span><strong class="command">ne0</strong></span>
+                  interfaces and links.  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.
+                  Note that on most systems link-local addresses
+                  always have the ambiguity, and need to be
+                  disambiguated.
                 </p>
               </td>
 </tr>
@@ -294,6 +295,11 @@
                   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>
+                <p>
+                  When specifying a prefix involving a IPv6 scoped address
+                  the scope may be omitted.  In that case the prefix will
+                  match packets from any scope.
+                </p>
               </td>
 </tr>
 <tr>
@@ -455,7 +461,7 @@
 <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="id2573302"></a>Syntax</h4></div></div></div>
+<a name="id2573414"></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>] |
@@ -464,14 +470,13 @@
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2573330"></a>Definition and Usage</h4></div></div></div>
+<a name="id2573442"></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 <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:
+            statements. The elements 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>
@@ -488,61 +493,68 @@
 <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.
+            "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
             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.
+            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
-            match list, the list is traversed in order until an element
-            matches.
+            match list, the comparison takes place in approximately O(1)
+            time.  However, key comparisons require that the list of keys
+            be traversed until a matching key is found, and therefore may
+            be somewhat slower.
+          </p>
+<p>
             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.
+            used for access control, defining <span><strong class="command">listen-on</strong></span> ports, or in a
+            <span><strong class="command">sortlist</strong></span>, 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
             <span><strong class="command">allow-notify</strong></span>,
+            <span><strong class="command">allow-recursion</strong></span>,
+            <span><strong class="command">allow-recursion-on</strong></span>,
             <span><strong class="command">allow-query</strong></span>,
+            <span><strong class="command">allow-query-on</strong></span>,
             <span><strong class="command">allow-query-cache</strong></span>,
+            <span><strong class="command">allow-query-cache-on</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.  Similarly, the listen-on option will cause the
-            server to not accept queries on any of the machine's
+            lists.  Similarly, the <span><strong class="command">listen-on</strong></span> option will cause the
+            server to refuse 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
-            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
-            <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 <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.
+            Order of insertion is significant.  If more than one element
+            in an ACL is found to match a given IP address or prefix,
+            preference will be given to the one that came
+            <span class="emphasis"><em>first</em></span> in the ACL definition.
+            Because of this first-match behavior, an element that
+            defines a subset of another element in the list should
+            come before the broader element, regardless of whether
+            either is negated. For example, in
+            <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 <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" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2573436"></a>Comment Syntax</h3></div></div></div>
+<a name="id2573716"></a>Comment Syntax</h3></div></div></div>
 <p>
           The <acronym class="acronym">BIND</acronym> 9 comment syntax allows for
           comments to appear
@@ -552,7 +564,7 @@
         </p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2573588"></a>Syntax</h4></div></div></div>
+<a name="id2573731"></a>Syntax</h4></div></div></div>
 <p>
             </p>
 <pre class="programlisting">/* This is a <acronym class="acronym">BIND</acronym> comment as in C */</pre>
@@ -567,7 +579,7 @@
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2573618"></a>Definition and Usage</h4></div></div></div>
+<a name="id2573761"></a>Definition and Usage</h4></div></div></div>
 <p>
             Comments may appear anywhere that whitespace may appear in
             a <acronym class="acronym">BIND</acronym> configuration file.
@@ -598,8 +610,6 @@
             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>
@@ -617,8 +627,6 @@
             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>
 <p>
@@ -763,6 +771,17 @@
 </tr>
 <tr>
 <td>
+                <p><span><strong class="command">statistics-channels</strong></span></p>
+              </td>
+<td>
+                <p>
+                  declares communication channels to get access to
+                  <span><strong class="command">named</strong></span> statistics.
+                </p>
+              </td>
+</tr>
+<tr>
+<td>
                 <p><span><strong class="command">trusted-keys</strong></span></p>
               </td>
 <td>
@@ -801,7 +820,7 @@
       </p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2574117"></a><span><strong class="command">acl</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2574346"></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
 };
@@ -819,8 +838,7 @@
 <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.
+          elsewhere; no forward references are allowed.
         </p>
 <p>
           The following ACLs are built-in:
@@ -884,7 +902,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2574307"></a><span><strong class="command">controls</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2574536"></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 | * ) [ port ip_port ] allow { <em class="replaceable"><code> address_match_list </code></em> }
                 keys { <em class="replaceable"><code>key_list</code></em> }; ]
@@ -1006,12 +1024,12 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2574736"></a><span><strong class="command">include</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2574965"></a><span><strong class="command">include</strong></span> Statement Grammar</h3></div></div></div>
 <pre class="programlisting"><span><strong class="command">include</strong></span> <em class="replaceable"><code>filename</code></em>;</pre>
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2574753"></a><span><strong class="command">include</strong></span> Statement Definition and
+<a name="id2574982"></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
@@ -1026,7 +1044,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2574776"></a><span><strong class="command">key</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2575005"></a><span><strong class="command">key</strong></span> Statement Grammar</h3></div></div></div>
 <pre class="programlisting"><span><strong class="command">key</strong></span> <em class="replaceable"><code>key_id</code></em> {
     algorithm <em class="replaceable"><code>string</code></em>;
     secret <em class="replaceable"><code>string</code></em>;
@@ -1035,7 +1053,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2574800"></a><span><strong class="command">key</strong></span> Statement Definition and Usage</h3></div></div></div>
+<a name="id2575029"></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>)
@@ -1082,10 +1100,10 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2574958"></a><span><strong class="command">logging</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2575120"></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">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> | <span><strong class="command">unlimited</strong></span> ) ]
          [ <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>
@@ -1106,7 +1124,7 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2575084"></a><span><strong class="command">logging</strong></span> Statement Definition and
+<a name="id2575245"></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
@@ -1140,7 +1158,7 @@
         </p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2575137"></a>The <span><strong class="command">channel</strong></span> Phrase</h4></div></div></div>
+<a name="id2575298"></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.
@@ -1302,7 +1320,7 @@ notrace</strong></span>. All debugging messages in the server have a debug
             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
+            pointless since <span><strong class="command">syslog</strong></span> also logs
             the date and
             time. If <span><strong class="command">print-category</strong></span> is
             requested, then the
@@ -1536,7 +1554,7 @@ category notify { null; };
                   </td>
 <td>
                     <p>
-                      Messages that named was unable to determine the
+                      Messages that <span><strong class="command">named</strong></span> 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
@@ -1588,15 +1606,18 @@ category notify { null; };
                       enable query logging unless <span><strong class="command">querylog</strong></span> option has been
                       specified.
                     </p>
+
                     <p>
-                      The query log entry reports the client's IP address and
-                      port number, and 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).
+                      The query log entry reports the client's IP
+                      address and port number, and the query name,
+                      class and type.  It also reports whether the
+                      Recursion Desired flag was set (+ if set, -
+                      if not set), if the query was signed (S),
+                      EDNS was in use (E), if DO (DNSSEC Ok) was
+                      set (D), or if CD (Checking Disabled) was set
+                      (C).
                     </p>
+
                     <p>
                       <code class="computeroutput">client 127.0.0.1#62536: query: www.example.com IN AAAA +SE</code>
                     </p>
@@ -1607,6 +1628,17 @@ category notify { null; };
 </tr>
 <tr>
 <td>
+                    <p><span><strong class="command">query-errors</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      Information about queries that resulted in some
+                      failure.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
                     <p><span><strong class="command">dispatch</strong></span></p>
                   </td>
 <td>
@@ -1645,7 +1677,7 @@ category notify { null; };
                   </td>
 <td>
                     <p>
-                      Delegation only.  Logs queries that have have
+                      Delegation only.  Logs queries that have
                       been forced to NXDOMAIN as the result of a
                       delegation-only zone or
                       a <span><strong class="command">delegation-only</strong></span> in a
@@ -1653,13 +1685,266 @@ category notify { null; };
                     </p>
                   </td>
 </tr>
+<tr>
+<td>
+                    <p><span><strong class="command">edns-disabled</strong></span></p>
+                  </td>
+<td>
+                    <p>
+                      Log queries that have been forced to use plain
+                      DNS due to timeouts.  This is often due to
+                      the remote servers not being RFC 1034 compliant
+                      (not always returning FORMERR or similar to
+                      EDNS queries and other extensions to the DNS
+                      when they are not understood).  In other words, this is
+                      targeted at servers that fail to respond to
+                      DNS queries that they don't understand.
+                    </p>
+                    <p>
+                      Note: the log message can also be due to
+                      packet loss.  Before reporting servers for
+                      non-RFC 1034 compliance they should be re-tested
+                      to determine the nature of the non-compliance.
+                      This testing should prevent or reduce the
+                      number of false-positive reports.
+                    </p>
+                    <p>
+                      Note: eventually <span><strong class="command">named</strong></span> will have to stop
+                      treating such timeouts as due to RFC 1034 non
+                      compliance and start treating it as plain
+                      packet loss.  Falsely classifying packet
+                      loss as due to RFC 1034 non compliance impacts
+                      on DNSSEC validation which requires EDNS for
+                      the DNSSEC records to be returned.
+                    </p>
+                  </td>
+</tr>
+</tbody>
+</table></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2576793"></a>The <span><strong class="command">query-errors</strong></span> Category</h4></div></div></div>
+<p>
+            The <span><strong class="command">query-errors</strong></span> category is
+            specifically intended for debugging purposes: To identify
+            why and how specific queries result in responses which
+            indicate an error.
+            Messages of this category are therefore only logged
+            with <span><strong class="command">debug</strong></span> levels.
+          </p>
+<p>
+            At the debug levels of 1 or higher, each response with the
+            rcode of SERVFAIL is logged as follows:
+          </p>
+<p>
+            <code class="computeroutput">client 127.0.0.1#61502: query failed (SERVFAIL) for www.example.com/IN/AAAA at query.c:3880</code>
+          </p>
+<p>
+            This means an error resulting in SERVFAIL was
+            detected at line 3880 of source file
+            <code class="filename">query.c</code>.
+            Log messages of this level will particularly
+            help identify the cause of SERVFAIL for an
+            authoritative server.
+          </p>
+<p>
+            At the debug levels of 2 or higher, detailed context
+            information of recursive resolutions that resulted in
+            SERVFAIL is logged.
+            The log message will look like as follows:
+          </p>
+<p>
+            <code class="computeroutput">fetch completed at resolver.c:2970 for www.example.com/A in 30.000183: timed out/success [domain:example.com,referral:2,restart:7,qrysent:8,timeout:5,lame:0,neterr:0,badresp:1,adberr:0,findfail:0,valfail:0]</code>
+          </p>
+<p>
+            The first part before the colon shows that a recursive
+            resolution for AAAA records of www.example.com completed
+            in 30.000183 seconds and the final result that led to the
+            SERVFAIL was determined at line 2970 of source file
+            <code class="filename">resolver.c</code>.
+          </p>
+<p>
+            The following part shows the detected final result and the
+            latest result of DNSSEC validation.
+            The latter is always success when no validation attempt
+            is made.
+            In this example, this query resulted in SERVFAIL probably
+            because all name servers are down or unreachable, leading
+            to a timeout in 30 seconds.
+            DNSSEC validation was probably not attempted.
+          </p>
+<p>
+            The last part enclosed in square brackets shows statistics
+            information collected for this particular resolution
+            attempt.
+            The <code class="varname">domain</code> field shows the deepest zone
+            that the resolver reached;
+            it is the zone where the error was finally detected.
+            The meaning of the other fields is summarized in the
+            following table.
+          </p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+                    <p><code class="varname">referral</code></p>
+                  </td>
+<td>
+                    <p>
+                      The number of referrals the resolver received
+                      throughout the resolution process.
+                      In the above example this is 2, which are most
+                      likely com and example.com.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><code class="varname">restart</code></p>
+                  </td>
+<td>
+                    <p>
+                      The number of cycles that the resolver tried
+                      remote servers at the <code class="varname">domain</code>
+                      zone.
+                      In each cycle the resolver sends one query
+                      (possibly resending it, depending on the response)
+                      to each known name server of
+                      the <code class="varname">domain</code> zone.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><code class="varname">qrysent</code></p>
+                  </td>
+<td>
+                    <p>
+                      The number of queries the resolver sent at the
+                      <code class="varname">domain</code> zone.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><code class="varname">timeout</code></p>
+                  </td>
+<td>
+                    <p>
+                      The number of timeouts since the resolver
+                      received the last response.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><code class="varname">lame</code></p>
+                  </td>
+<td>
+                    <p>
+                      The number of lame servers the resolver detected
+                      at the <code class="varname">domain</code> zone.
+                      A server is detected to be lame either by an
+                      invalid response or as a result of lookup in
+                      BIND9's address database (ADB), where lame
+                      servers are cached.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><code class="varname">neterr</code></p>
+                  </td>
+<td>
+                    <p>
+                      The number of erroneous results that the
+                      resolver encountered in sending queries
+                      at the <code class="varname">domain</code> zone.
+                      One common case is the remote server is
+                      unreachable and the resolver receives an ICMP
+                      unreachable error message.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><code class="varname">badresp</code></p>
+                  </td>
+<td>
+                    <p>
+                      The number of unexpected responses (other than
+                      <code class="varname">lame</code>) to queries sent by the
+                      resolver at the <code class="varname">domain</code> zone.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><code class="varname">adberr</code></p>
+                  </td>
+<td>
+                    <p>
+                      Failures in finding remote server addresses
+                      of the <code class="varname">domain</code> zone in the ADB.
+                      One common case of this is that the remote
+                      server's name does not have any address records.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><code class="varname">findfail</code></p>
+                  </td>
+<td>
+                    <p>
+                      Failures of resolving remote server addresses.
+                      This is a total number of failures throughout
+                      the resolution process.
+                    </p>
+                  </td>
+</tr>
+<tr>
+<td>
+                    <p><code class="varname">valfail</code></p>
+                  </td>
+<td>
+                    <p>
+                      Failures of DNSSEC validation.
+                      Validation failures are counted throughout
+                      the resolution process (not limited to
+                      the <code class="varname">domain</code> zone), but should
+                      only happen in <code class="varname">domain</code>.
+                    </p>
+                  </td>
+</tr>
 </tbody>
 </table></div>
+<p>
+            At the debug levels of 3 or higher, the same messages
+            as those at the debug 1 level are logged for other errors
+            than SERVFAIL.
+            Note that negative responses such as NXDOMAIN are not
+            regarded as errors here.
+          </p>
+<p>
+            At the debug levels of 4 or higher, the same messages
+            as those at the debug 2 level are logged for other errors
+            than SERVFAIL.
+            Unlike the above case of level 3, messages are logged for
+            negative responses.
+            This is because any unexpected results can be difficult to
+            debug in the recursion case.
+          </p>
 </div>
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2576435"></a><span><strong class="command">lwres</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2577306"></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:
@@ -1674,7 +1959,7 @@ category notify { null; };
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2576508"></a><span><strong class="command">lwres</strong></span> Statement Definition and Usage</h3></div></div></div>
+<a name="id2577448"></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
@@ -1725,14 +2010,14 @@ category notify { null; };
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2576572"></a><span><strong class="command">masters</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2577512"></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="id2576616"></a><span><strong class="command">masters</strong></span> Statement Definition and
+<a name="id2577556"></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
@@ -1741,7 +2026,7 @@ category notify { null; };
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2576631"></a><span><strong class="command">options</strong></span> Statement Grammar</h3></div></div></div>
+<a name="id2577571"></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:
@@ -1753,10 +2038,12 @@ category notify { null; };
     [<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-gssapi-credential <em class="replaceable"><code>principal</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"> cache-file <em class="replaceable"><code>path_name</code></em>; </span>]
     [<span class="optional"> dump-file <em class="replaceable"><code>path_name</code></em>; </span>]
+    [<span class="optional"> memstatistics <em class="replaceable"><code>yes_or_no</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"> recursing-file <em class="replaceable"><code>path_name</code></em>; </span>]
@@ -1778,6 +2065,7 @@ category notify { null; };
     [<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"> ixfr-from-differences (<em class="replaceable"><code>yes_or_no</code></em> | <code class="constant">master</code> | <code class="constant">slave</code>); </span>]
     [<span class="optional"> dnssec-enable <em class="replaceable"><code>yes_or_no</code></em>; </span>]
     [<span class="optional"> dnssec-validation <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>]
@@ -1799,12 +2087,16 @@ category notify { null; };
     [<span class="optional"> check-sibling <em class="replaceable"><code>yes_or_no</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-query-on { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
     [<span class="optional"> allow-query-cache { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> allow-query-cache-on { <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-recursion-on { <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"> allow-update-forwarding { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
     [<span class="optional"> update-check-ksk <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> try-tcp-refresh <em class="replaceable"><code>yes_or_no</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"> use-v4-udp-ports { <em class="replaceable"><code>port_list</code></em> }; </span>]
@@ -1821,6 +2113,9 @@ category notify { null; };
         [<span class="optional"> port ( <em class="replaceable"><code>ip_port</code></em> | <em class="replaceable"><code>*</code></em> ) </span>] | 
         [<span class="optional"> address ( <em class="replaceable"><code>ip6_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"> use-queryport-pool <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> queryport-pool-ports <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> queryport-pool-interval <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"> max-transfer-idle-in <em class="replaceable"><code>number</code></em>; </span>]
@@ -1843,6 +2138,7 @@ category notify { null; };
     [<span class="optional"> notify-delay <em class="replaceable"><code>seconds</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"> notify-to-soa <em class="replaceable"><code>yes_or_no</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"> 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>]
@@ -1861,6 +2157,9 @@ category notify { null; };
     [<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"> sig-signing-nodes <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> sig-signing-signatures <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> sig-signing-type <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>]
@@ -1937,28 +2236,42 @@ category notify { null; };
               </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 <acronym class="acronym">BIND</acronym> 8 to
-                specify the pathname to the <span><strong class="command">named-xfer</strong></span> program.
-                In <acronym class="acronym">BIND</acronym> 9, no separate <span><strong class="command">named-xfer</strong></span> program is
-                needed; its functionality is built into the name server.
+                <span class="emphasis"><em>This option is obsolete.</em></span> It
+                was used in <acronym class="acronym">BIND</acronym> 8 to specify
+                the pathname to the <span><strong class="command">named-xfer</strong></span>
+                program.  In <acronym class="acronym">BIND</acronym> 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-gssapi-credential</strong></span></span></dt>
+<dd><p>
+                The security credential with which the server should
+                authenticate keys requested by the GSS-TSIG protocol.
+                Currently only Kerberos 5 authentication is available
+                and the credential is a Kerberos principal which
+                the server can acquire through the default system
+                key file, normally <code class="filename">/etc/krb5.keytab</code>.
+                Normally this principal is of the form
+                "<strong class="userinput"><code>dns/</code></strong><code class="varname">server.domain</code>".
+                To use GSS-TSIG, <span><strong class="command">tkey-domain</strong></span>
+                must also be set.
               </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 "<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.
+                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 <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, or an otherwise
+                non-existent subdomain like
+                "_tkey.<code class="varname">domainname</code>".  If you are
+                using GSS-TSIG, this variable must be defined.
               </p></dd>
 <dt><span class="term"><span><strong class="command">tkey-dhkey</strong></span></span></dt>
 <dd><p>
@@ -1983,25 +2296,17 @@ digits</code>" + "<code class="varname">tkey-domain</code>". In most cases,
                 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>
+<dd><p>
                 The pathname of the file the server writes memory
-                usage statistics to on exit.  If specified the
-                statistics will be written to the file on exit.
-              </p>
-<p>
-                In <acronym class="acronym">BIND</acronym> 9.5 and later this will
-                default to <code class="filename">named.memstats</code>.
-                <acronym class="acronym">BIND</acronym> 9.5 will also introduce
-                <span><strong class="command">memstatistics</strong></span> to control the
-                writing.
-              </p>
-</dd>
+                usage statistics to on exit. If not specified,
+                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
+                in. If not specified, the default is
+                <code class="filename">/var/run/named/named.pid</code>.
+                The PID file is used by programs that want to send signals to
                 the running
                 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
@@ -2096,7 +2401,7 @@ options {
                 top of a zone.  When a DNSKEY is at or below a domain
                 specified by the
                 deepest <span><strong class="command">dnssec-lookaside</strong></span>, and
-                the normal dnssec validation
+                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
@@ -2109,10 +2414,10 @@ options {
 <dd><p>
                 Specify hierarchies which must be or may not be secure (signed and
                 validated).
-                If <strong class="userinput"><code>yes</code></strong>, then named will only accept
+                If <strong class="userinput"><code>yes</code></strong>, then <span><strong class="command">named</strong></span> will only accept
                 answers if they
                 are secure.
-                If <strong class="userinput"><code>no</code></strong>, then normal dnssec validation
+                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 <span><strong class="command">trusted-key</strong></span> or
@@ -2142,6 +2447,14 @@ options {
                   for memory leaks on exit. <acronym class="acronym">BIND</acronym> 9 ignores the option and always performs
                   the checks.
                 </p></dd>
+<dt><span class="term"><span><strong class="command">memstatistics</strong></span></span></dt>
+<dd><p>
+                  Write memory statistics to the file specified by
+                  <span><strong class="command">memstatistics-file</strong></span> at exit.
+                  The default is <strong class="userinput"><code>no</code></strong> unless
+                  '-m record' is specified on the command line in
+                  which case it is <strong class="userinput"><code>yes</code></strong>.
+                </p></dd>
 <dt><span class="term"><span><strong class="command">dialup</strong></span></span></dt>
 <dd>
 <p>
@@ -2461,6 +2774,17 @@ options {
                   to crash.
                 </p>
 </dd>
+<dt><span class="term"><span><strong class="command">notify-to-soa</strong></span></span></dt>
+<dd><p>
+                  If <strong class="userinput"><code>yes</code></strong> do not check the nameservers
+                  in the NS RRset against the SOA MNAME.  Normally a NOTIFY
+                  message is not sent to the SOA MNAME (SOA ORIGIN) as it is
+                  supposed to contain the name of the ultimate master.
+                  Sometimes, however, a slave is listed as the SOA MNAME in
+                  hidden master configurations and in that case you would
+                  want the ultimate master to still send NOTIFY messages to
+                  all the nameservers listed in the NS RRset.
+                </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
@@ -2675,43 +2999,44 @@ options {
                   also accepts <span><strong class="command">master</strong></span> and
                   <span><strong class="command">slave</strong></span> at the view and options
                   levels which causes
-                  <span><strong class="command">ixfr-from-differences</strong></span> to apply to
+                  <span><strong class="command">ixfr-from-differences</strong></span> to be enabled for
                   all <span><strong class="command">master</strong></span> or
                   <span><strong class="command">slave</strong></span> zones respectively.
+                  It is off by default.
                 </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 <strong class="userinput"><code>yes</code></strong>, named will
+                  addresses refer to different machines.  If <strong class="userinput"><code>yes</code></strong>, <span><strong class="command">named</strong></span> will
                   not log
-                  when the serial number on the master is less than what named
+                  when the serial number on the master is less than what <span><strong class="command">named</strong></span>
                   currently
                   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.
+                  Enable DNSSEC support in <span><strong class="command">named</strong></span>.  Unless set to <strong class="userinput"><code>yes</code></strong>,
+                  <span><strong class="command">named</strong></span> behaves as if it does not support DNSSEC.
                   The default is <strong class="userinput"><code>yes</code></strong>.
                 </p></dd>
 <dt><span class="term"><span><strong class="command">dnssec-validation</strong></span></span></dt>
 <dd><p>
-                  Enable DNSSEC validation in named.
+                  Enable DNSSEC validation in <span><strong class="command">named</strong></span>.
                   Note <span><strong class="command">dnssec-enable</strong></span> also needs to be
                   set to <strong class="userinput"><code>yes</code></strong> to be effective.
-                  The default is <strong class="userinput"><code>no</code></strong>.
+                  The default is <strong class="userinput"><code>yes</code></strong>.
                 </p></dd>
 <dt><span class="term"><span><strong class="command">dnssec-accept-expired</strong></span></span></dt>
 <dd><p>
                   Accept expired signatures when verifying DNSSEC signatures.
                   The default is <strong class="userinput"><code>no</code></strong>.
-                  Setting this option to "yes" leaves named vulnerable to replay attacks.
+                  Setting this option to "yes" leaves <span><strong class="command">named</strong></span> vulnerable to replay attacks.
                 </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
+                  Specify whether query logging should be started when <span><strong class="command">named</strong></span>
                   starts.
                   If <span><strong class="command">querylog</strong></span> is not specified,
                   then the query logging
@@ -2737,9 +3062,9 @@ options {
                   from RFC 952 and RFC 821 as modified by RFC 1123.
                 </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.
+                  applies to the owner names of A, AAAA and MX records.
+                  It also applies to the domain names in the RDATA of NS, SOA,
+                  MX, and SRV records.
                   It also applies to the RDATA of PTR records where the owner
                   name indicated that it is a reverse lookup of a hostname
                   (the owner name ends in IN-ADDR.ARPA, IP6.ARPA, or IP6.INT).
@@ -2796,7 +3121,7 @@ options {
 <dt><span class="term"><span><strong class="command">zero-no-soa-ttl</strong></span></span></dt>
 <dd><p>
                   When returning authoritative negative responses to
-                  SOA queries set the TTL of the SOA recored returned in
+                  SOA queries set the TTL of the SOA record returned in
                   the authority section to zero.
                   The default is <span><strong class="command">yes</strong></span>.
                 </p></dd>
@@ -2816,11 +3141,17 @@ options {
                   a KSK.
                   The default is <span><strong class="command">yes</strong></span>.
                 </p></dd>
+<dt><span class="term"><span><strong class="command">try-tcp-refresh</strong></span></span></dt>
+<dd><p>
+                  Try to refresh the zone using TCP if UDP queries fail.
+                  For BIND 8 compatibility, the default is
+                  <span><strong class="command">yes</strong></span>.
+                </p></dd>
 </dl></div>
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2580525"></a>Forwarding</h4></div></div></div>
+<a name="id2581667"></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
@@ -2864,7 +3195,7 @@ options {
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2580721"></a>Dual-stack Servers</h4></div></div></div>
+<a name="id2581725"></a>Dual-stack Servers</h4></div></div></div>
 <p>
             Dual-stack servers are used as servers of last resort to work
             around
@@ -2929,16 +3260,52 @@ options {
                   </p>
 </div>
 </dd>
+<dt><span class="term"><span><strong class="command">allow-query-on</strong></span></span></dt>
+<dd>
+<p>
+                  Specifies which local addresses can accept ordinary
+                  DNS questions. This makes it possible, for instance,
+                  to allow queries on internal-facing interfaces but
+                  disallow them on external-facing ones, without
+                  necessarily knowing the internal network's addresses.
+                </p>
+<p>
+                  <span><strong class="command">allow-query-on</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-on</strong></span> statement.
+                </p>
+<p>
+                  If not specified, the default is to allow queries
+                  on all addresses.
+                </p>
+<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+<p>
+                    <span><strong class="command">allow-query-cache</strong></span> is
+                    used to specify access to the cache.
+                  </p>
+</div>
+</dd>
 <dt><span class="term"><span><strong class="command">allow-query-cache</strong></span></span></dt>
 <dd><p>
                   Specifies which hosts are allowed to get answers
                   from the cache.  If <span><strong class="command">allow-query-cache</strong></span>
                   is not set then <span><strong class="command">allow-recursion</strong></span>
                   is used if set, otherwise <span><strong class="command">allow-query</strong></span>
-                  is used if set, otherwise the default
-                  (<span><strong class="command">localnets;</strong></span>
+                  is used if set unless <span><strong class="command">recursion no;</strong></span> is
+                  set in which case <span><strong class="command">none;</strong></span> is used,
+                  otherwise the default (<span><strong class="command">localnets;</strong></span>
                   <span><strong class="command">localhost;</strong></span>) is used.
                 </p></dd>
+<dt><span class="term"><span><strong class="command">allow-query-cache-on</strong></span></span></dt>
+<dd><p>
+                  Specifies which local addresses can give answers
+                  from the cache.  If not specified, the default is
+                  to allow cache queries on any address,
+                  <span><strong class="command">localnets</strong></span> and
+                  <span><strong class="command">localhost</strong></span>.
+                </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
@@ -2950,6 +3317,12 @@ options {
                   (<span><strong class="command">localnets;</strong></span>
                   <span><strong class="command">localhost;</strong></span>) is used.
                 </p></dd>
+<dt><span class="term"><span><strong class="command">allow-recursion-on</strong></span></span></dt>
+<dd><p>
+                  Specifies which local addresses can accept recursive
+                  queries.  If not specified, the default is to allow
+                  recursive queries on all addresses.
+                </p></dd>
 <dt><span class="term"><span><strong class="command">allow-update</strong></span></span></dt>
 <dd><p>
                   Specifies which hosts are allowed to
@@ -3019,11 +3392,11 @@ options {
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2581142"></a>Interfaces</h4></div></div></div>
+<a name="id2582231"></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>.
+            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>
@@ -3042,7 +3415,7 @@ listen-on port 1234 { !1.2.3.4; 1.2/16; };
           </p>
 <p>
             If no <span><strong class="command">listen-on</strong></span> is specified, the
-            server will listen on port 53 on all interfaces.
+            server will listen on port 53 on all IPv4 interfaces.
           </p>
 <p>
             The <span><strong class="command">listen-on-v6</strong></span> option is used to
@@ -3093,8 +3466,10 @@ listen-on-v6 port 1234 { !2001:db8::/32; any; };
 </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.
+            specified, the server will not listen on any IPv6 address
+            unless <span><strong class="command">-6</strong></span> is specified when <span><strong class="command">named</strong></span> is
+            invoked.  If <span><strong class="command">-6</strong></span> is specified then
+            <span><strong class="command">named</strong></span> will listen on port 53 on all IPv6 interfaces by default.
           </p>
 </div>
 <div class="sect3" lang="en">
@@ -3178,20 +3553,37 @@ use-v6-udp-ports { range 1024 65535; };
 avoid-v6-udp-ports {};
 </pre>
 <p>
-            Note: it is generally strongly discouraged to
+            Note: BIND 9.5.0 introduced
+            the <span><strong class="command">use-queryport-pool</strong></span> 
+            option to support a pool of such random ports, but this
+            option is now obsolete because reusing the same ports in
+            the pool may not be sufficiently secure.
+            For the same reason, it is generally strongly discouraged to
             specify a particular port for the
             <span><strong class="command">query-source</strong></span> or
             <span><strong class="command">query-source-v6</strong></span> options;
-            it implicitly disables the use of randomized port numbers
-            and can be insecure.
+            it implicitly disables the use of randomized port numbers.
           </p>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">use-queryport-pool</strong></span></span></dt>
+<dd><p>
+                  This option is obsolete.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">queryport-pool-ports</strong></span></span></dt>
+<dd><p>
+                  This option is obsolete.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">queryport-pool-updateinterval</strong></span></span></dt>
+<dd><p>
+                  This option is obsolete.
+                </p></dd>
+</dl></div>
 <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
+              to UDP queries.  TCP queries always use a random
               unprivileged port.
             </p>
 </div>
@@ -3228,7 +3620,12 @@ avoid-v6-udp-ports {};
                   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 <span><strong class="command">also-notify</strong></span> list
+                  quickly converge on stealth servers.
+                  Optionally, 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.
+                  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>
@@ -3395,7 +3792,7 @@ avoid-v6-udp-ports {};
                   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
+                  getting an answer back to the first refresh
                   query.
                 </div>
 </dd>
@@ -3447,7 +3844,7 @@ avoid-v6-udp-ports {};
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2582140"></a>UDP Port Lists</h4></div></div></div>
+<a name="id2583571"></a>UDP Port Lists</h4></div></div></div>
 <p>
             <span><strong class="command">use-v4-udp-ports</strong></span>,
             <span><strong class="command">avoid-v4-udp-ports</strong></span>,
@@ -3489,7 +3886,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2582200"></a>Operating System Resource Limits</h4></div></div></div>
+<a name="id2583699"></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
@@ -3548,7 +3945,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2582452"></a>Server  Resource Limits</h4></div></div></div>
+<a name="server_resource_limits"></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
@@ -3571,6 +3968,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                   journal
                   will be automatically removed.  The default is
                   <code class="literal">unlimited</code>.
+                  This may also be set on a per-zone basis.
                 </p></dd>
 <dt><span class="term"><span><strong class="command">host-statistics-max</strong></span></span></dt>
 <dd><p>
@@ -3602,7 +4000,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 <p>
                   The number of file descriptors reserved for TCP, stdio,
                   etc.  This needs to be big enough to cover the number of
-                  interfaces named listens on, tcp-clients as well as
+                  interfaces <span><strong class="command">named</strong></span> listens on, <span><strong class="command">tcp-clients</strong></span> as well as
                   to provide room for outgoing TCP queries and incoming zone
                   transfers.  The default is <code class="literal">512</code>.
                   The minimum value is <code class="literal">128</code> and the
@@ -3619,7 +4017,8 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                   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.
+                  prematurely based on an LRU based strategy so that
+                  the limit is not exceeded.
                   A value of 0 is special, meaning that
                   records are purged from the cache only when their
                   TTLs expire.
@@ -3649,15 +4048,18 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2582682"></a>Periodic Task Intervals</h4></div></div></div>
+<a name="id2583985"></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
+                  This interval is effectively obsolete.  Previously,
+                  the server would 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.
+                  <acronym class="acronym">BIND</acronym> 9 now manages cache
+                  memory in a more sophisticated manner and does not
+                  rely on the periodic cleaning any more.
+                  Specifying this option therefore has no effect on
+                  the server's behavior.
                 </p></dd>
 <dt><span class="term"><span><strong class="command">heartbeat-interval</strong></span></span></dt>
 <dd><p>
@@ -3914,8 +4316,13 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                   </td>
 <td>
                     <p>
-                      Records are returned in a round-robin
-                      order.
+                      Records are returned in a cyclic round-robin order.
+                    </p>
+                    <p>
+                      If <acronym class="acronym">BIND</acronym> is configured with the
+                      "--enable-fixed-rrset" option at compile time, then
+                      the initial ordering of the RRset will match the
+                      one specified in the zone file.
                     </p>
                   </td>
 </tr>
@@ -3943,9 +4350,11 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 <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 <acronym class="acronym">BIND</acronym> 9.
-              BIND 9 currently does not fully support "fixed" ordering.
+              In this release of <acronym class="acronym">BIND</acronym> 9, the
+              <span><strong class="command">rrset-order</strong></span> statement does not support
+              "fixed" ordering by default.  Fixed ordering can be enabled
+              at compile time by specifying "--enable-fixed-rrset" on
+              the "configure" command line.
             </p>
 </div>
 </div>
@@ -4000,17 +4409,59 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 </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" title="Dynamic Update">the section called &#8220;Dynamic Update&#8221;</a>) will expire.  There
+                  is a optional second field which specifies how
+                  long before expiry that the signatures will be
+                  regenerated.  If not specified, the signatures will
+                  be regenerated at 1/4 of base interval.  The second
+                  field is specified in days if the base interval is
+                  greater than 7 days otherwise it is specified in hours.
+                  The default base interval is <code class="literal">30</code> days
+                  giving a re-signing interval of 7 1/2 days.  The maximum
+                  values are 10 years (3660 days).
+                </p>
+<p>
+                  The signature inception time is unconditionally
+                  set to one hour before the current time to allow
+                  for a limited amount of clock skew.
+                </p>
+<p>
+                  The <span><strong class="command">sig-validity-interval</strong></span>
+                  should be, at least, several multiples of the SOA
+                  expire interval to allow for reasonable interaction
+                  between the various timer and expiry dates.
+                </p>
+</dd>
+<dt><span class="term"><span><strong class="command">sig-signing-nodes</strong></span></span></dt>
+<dd><p>
+                  Specify the maximum number of nodes to be
+                  examined in each quantum when signing a zone with
+                  a new DNSKEY. The default is
+                  <code class="literal">100</code>.
+                </p></dd>
+<dt><span class="term"><span><strong class="command">sig-signing-signatures</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" 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.
+                  Specify a threshold number of signatures that
+                  will terminate processing a quantum when signing
+                  a zone with a new DNSKEY.  The default is
+                  <code class="literal">10</code>.
                 </p></dd>
+<dt><span class="term"><span><strong class="command">sig-signing-type</strong></span></span></dt>
+<dd>
+<p>
+                  Specify a private RDATA type to be used when generating
+                  key signing records.  The default is
+                  <code class="literal">65535</code>.
+                </p>
+<p>
+                  It is expected that this parameter may be removed
+                  in a future version once there is a standard type.
+                </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>
@@ -4037,22 +4488,23 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 </dd>
 <dt><span class="term"><span><strong class="command">edns-udp-size</strong></span></span></dt>
 <dd><p>
-                  Sets the advertised EDNS UDP buffer size in bytes.  Valid
-                  values are 512 to 4096 (values outside this range
-                  will be silently adjusted).  The default value is
-                  4096.  The usual reason for setting edns-udp-size to
-                  a non-default value is to get UDP answers to pass
-                  through broken firewalls that block fragmented
-                  packets and/or block UDP packets that are greater
-                  than 512 bytes.
+                  Sets the advertised EDNS UDP buffer size in bytes
+                  to control the size of packets received.
+                  Valid values are 512 to 4096 (values outside this range
+                  will be silently adjusted).  The default value
+                  is 4096.  The usual reason for setting
+                  <span><strong class="command">edns-udp-size</strong></span> to a non-default
+                  value is to get UDP answers to pass through broken
+                  firewalls that block fragmented packets and/or
+                  block UDP packets that are greater than 512 bytes.
                 </p></dd>
 <dt><span class="term"><span><strong class="command">max-udp-size</strong></span></span></dt>
 <dd><p>
-                  Sets the maximum EDNS UDP message size named will
+                  Sets the maximum EDNS UDP message size <span><strong class="command">named</strong></span> will
                   send in bytes.  Valid values are 512 to 4096 (values outside
                   this range will be silently adjusted).  The default
                   value is 4096.  The usual reason for setting
-                  max-udp-size to a non-default value is to get UDP
+                  <span><strong class="command">max-udp-size</strong></span> to a non-default value is to get UDP
                   answers to pass through broken firewalls that
                   block fragmented packets and/or block UDP packets
                   that are greater than 512 bytes.
@@ -4085,21 +4537,21 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                   file.
                 </p></dd>
 <dt>
-<span class="term"><span><strong class="command">clients-per-query</strong></span>, </span><span class="term"><span><strong class="command">max-clients-per-query</strong></span></span>
+<a name="clients-per-query"></a><span class="term"><span><strong class="command">clients-per-query</strong></span>, </span><span class="term"><span><strong class="command">max-clients-per-query</strong></span></span>
 </dt>
 <dd>
 <p>These set the
                   initial value (minimum) and maximum number of recursive
-                  simultanious clients for any given query
+                  simultaneous clients for any given query
                   (&lt;qname,qtype,qclass&gt;) that the server will accept
-                  before dropping additional clients.  named will attempt to
+                  before dropping additional clients.  <span><strong class="command">named</strong></span> will attempt to
                   self tune this value and changes will be logged.  The
                   default values are 10 and 100.
                 </p>
 <p>
                   This value should reflect how many queries come in for
                   a given name in the time it takes to resolve that name.
-                  If the number of queries exceed this value, named will
+                  If the number of queries exceed this value, <span><strong class="command">named</strong></span> will
                   assume that it is dealing with a non-responsive zone
                   and will drop additional queries.  If it gets a response
                   after dropping queries, it will raise the estimate.  The
@@ -4172,14 +4624,15 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                 </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 ID the server should report when receiving a Name
+                  Server Identifier (NSID) query, or 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 <span><strong class="command">server-id none;</strong></span>
                   disables processing of the queries.
-                  Specifying <span><strong class="command">server-id hostname;</strong></span> will cause named to
+                  Specifying <span><strong class="command">server-id hostname;</strong></span> will cause <span><strong class="command">named</strong></span> to
                   use the hostname as found by the gethostname() function.
                   The default <span><strong class="command">server-id</strong></span> is <span><strong class="command">none</strong></span>.
                 </p></dd>
@@ -4197,12 +4650,12 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
             these cover the reverse namespace for addresses from RFC 1918 and
             RFC 3330.  They also include the reverse namespace for IPv6 local
             address (locally assigned), IPv6 link local addresses, the IPv6
-            loopback address and the IPv6 unknown addresss.
+            loopback address and the IPv6 unknown address.
           </p>
 <p>
-            Named will attempt to determine if a built in zone already exists
+            Named will attempt to determine if a built-in zone already exists
             or is active (covered by a forward-only forwarding declaration)
-            and will not not create a empty zone in that case.
+            and will not create a empty zone in that case.
           </p>
 <p>
             The current list of empty zones is:
@@ -4248,7 +4701,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 <h3 class="title">Note</h3>
             The real parent servers for these zones should disable all
             empty zone under the parent zone they serve.  For the real
-            root servers, this is all built in empty zones.  This will
+            root servers, this is all built-in empty zones.  This will
             enable them to return referrals to deeper in the tree.
           </div>
 <div class="variablelist"><dl>
@@ -4266,173 +4719,18 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                 </p></dd>
 <dt><span class="term"><span><strong class="command">empty-zones-enable</strong></span></span></dt>
 <dd><p>
-                  Enable or disable all empty zones.  By default they
+                  Enable or disable all empty zones.  By default, they
                   are enabled.
                 </p></dd>
 <dt><span class="term"><span><strong class="command">disable-empty-zone</strong></span></span></dt>
 <dd><p>
-                  Disable individual empty zones.  By default none are
+                  Disable individual empty zones.  By default, none are
                   disabled.  This option can be specified multiple times.
                 </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 <acronym class="acronym">BIND</acronym> 9
-            is similar, but not identical, to that
-            generated by <acronym class="acronym">BIND</acronym> 8.
-          </p>
-<p>
-            The statistics dump begins with a line, like:
-          </p>
-<p>
-            <span><strong class="command">+++ Statistics Dump +++ (973798949)</strong></span>
-          </p>
-<p>
-            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).
-          </p>
-<p>
-            The statistics dump ends with the line where the
-            number is identical to the number in the beginning line; for example:
-          </p>
-<p>
-            <span><strong class="command">--- Statistics Dump --- (973798949)</strong></span>
-          </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><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>
-<tr>
-<td>
-                    <p><span><strong class="command">duplicate</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      The number of queries which the server attempted to
-                      recurse but discover a existing query with the same
-                      IP address, port, query id, name, type and class
-                      already being processed.
-                    </p>
-                  </td>
-</tr>
-<tr>
-<td>
-                    <p><span><strong class="command">dropped</strong></span></p>
-                  </td>
-<td>
-                    <p>
-                      The number of queries for which the server
-                      discovered a excessive number of existing
-                      recursive queries for the same name, type and
-                      class and were subsequently dropped.
-                    </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>,
-            <span><strong class="command">failure</strong></span>,
-            <span><strong class="command">duplicate</strong></span>, or
-            <span><strong class="command">dropped</strong></span>
-            to be incremented, and may additionally cause the
-            <span><strong class="command">recursion</strong></span> counter to be
-            incremented.
-          </p>
-</div>
-<div class="sect3" lang="en">
-<div class="titlepage"><div><div><h4 class="title">
 <a name="acache"></a>Additional Section Caching</h4></div></div></div>
 <p>
             The additional section cache, also called <span><strong class="command">acache</strong></span>,
@@ -4518,10 +4816,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
                   In a server with multiple views, the limit applies
                   separately to the
                   acache of each view.
-                  The default is <code class="literal">unlimited</code>,
-                  meaning that
-                  entries are purged from the acache only at the
-                  periodic cleaning time.
+                  The default is <code class="literal">16M</code>.
                 </p></dd>
 </dl></div>
 </div>
@@ -4545,6 +4840,9 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
     [<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"> 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"> use-queryport-pool <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> queryport-pool-ports <em class="replaceable"><code>number</code></em>; </span>]
+    [<span class="optional"> queryport-pool-interval <em class="replaceable"><code>number</code></em>; </span>]
 };
 </pre>
 </div>
@@ -4628,7 +4926,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
           </p>
 <p>
             The <span><strong class="command">edns-udp-size</strong></span> option sets the EDNS UDP size
-            that is advertised by named when querying the remote server.
+            that is advertised by <span><strong class="command">named</strong></span> when querying the remote server.
             Valid values are 512 to 4096 bytes (values outside this range will be
             silently adjusted).  This option is useful when you wish to
             advertises a different value to this server than the value you
@@ -4637,11 +4935,11 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
           </p>
 <p>
             The <span><strong class="command">max-udp-size</strong></span> option sets the
-            maximum EDNS UDP message size named will send.  Valid
+            maximum EDNS UDP message size <span><strong class="command">named</strong></span> will send.  Valid
             values are 512 to 4096 bytes (values outside this range will
             be silently adjusted).  This option is useful when you
             know that there is a firewall that is blocking large
-            replies from named.
+            replies from <span><strong class="command">named</strong></span>.
           </p>
 <p>
             The server supports two zone transfer methods. The first, <span><strong class="command">one-answer</strong></span>,
@@ -4719,7 +5017,67 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2585614"></a><span><strong class="command">trusted-keys</strong></span> Statement Grammar</h3></div></div></div>
+<a name="statschannels"></a><span><strong class="command">statistics-channels</strong></span> Statement Grammar</h3></div></div></div>
+<pre class="programlisting"><span><strong class="command">statistics-channels</strong></span> {
+   [ inet ( ip_addr | * ) [ port ip_port ] [allow { <em class="replaceable"><code> address_match_list </code></em> } ]; ]
+   [ inet ...; ]
+};
+</pre>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2586754"></a><span><strong class="command">statistics-channels</strong></span> Statement Definition and
+            Usage</h3></div></div></div>
+<p>
+          The <span><strong class="command">statistics-channels</strong></span> statement
+          declares communication channels to be used by system
+          administrators to get access to statistics information of
+          the name server.
+        </p>
+<p>
+          This statement intends to be flexible to support multiple
+          communication protocols in the future, but currently only
+          HTTP access is supported.
+          It requires that BIND 9 be compiled with libxml2;
+          the <span><strong class="command">statistics-channels</strong></span> statement is
+          still accepted even if it is built without the library,
+          but any HTTP access will fail with an error.
+        </p>
+<p>
+          An <span><strong class="command">inet</strong></span> control channel is a TCP socket
+          listening at the specified <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> (asterisk) is
+          interpreted as the IPv4 wildcard address; connections will be
+          accepted on any of the system's IPv4 addresses.
+          To listen on the IPv6 wildcard address,
+          use an <span><strong class="command">ip_addr</strong></span> of <code class="literal">::</code>.
+        </p>
+<p>
+          If no port is specified, port 80 is used for HTTP channels.
+          The asterisk "<code class="literal">*</code>" cannot be used for
+          <span><strong class="command">ip_port</strong></span>.
+        </p>
+<p>
+          The attempt of opening a statistics channel is
+          restricted by the optional <span><strong class="command">allow</strong></span> clause.
+          Connections to the statistics channel are permitted based on the
+          <span><strong class="command">address_match_list</strong></span>.
+          If no <span><strong class="command">allow</strong></span> clause is present,
+          <span><strong class="command">named</strong></span> accepts connection
+          attempts from any address; since the statistics may
+          contain sensitive internal information, it is highly
+          recommended to restrict the source of connection requests
+          appropriately.
+        </p>
+<p>
+          If no <span><strong class="command">statistics-channels</strong></span> statement is present,
+          <span><strong class="command">named</strong></span> will not open any communication channels.
+        </p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="id2586908"></a><span><strong class="command">trusted-keys</strong></span> Statement Grammar</h3></div></div></div>
 <pre class="programlisting"><span><strong class="command">trusted-keys</strong></span> {
     <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>]
@@ -4728,7 +5086,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2585666"></a><span><strong class="command">trusted-keys</strong></span> Statement Definition
+<a name="id2586960"></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
@@ -4754,6 +5112,9 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
             multiple key entries, each consisting of the key's
             domain name, flags, protocol, algorithm, and the Base-64
             representation of the key data.
+            Spaces, tabs, newlines and carriage returns are ignored
+            in the key data, so the configuration may be split up into
+            multiple lines.
           </p>
 </div>
 <div class="sect2" lang="en">
@@ -4771,7 +5132,7 @@ avoid-v6-udp-ports { 40000; range 50000 60000; };
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2585748"></a><span><strong class="command">view</strong></span> Statement Definition and Usage</h3></div></div></div>
+<a name="id2587042"></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
             feature
@@ -4894,6 +5255,7 @@ view "external" {
 <pre class="programlisting"><span><strong class="command">zone</strong></span> <em class="replaceable"><code>zone_name</code></em> [<span class="optional"><em class="replaceable"><code>class</code></em></span>] {
     type master;
     [<span class="optional"> allow-query { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> allow-query-on { <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>]
@@ -4906,9 +5268,11 @@ view "external" {
     [<span class="optional"> file <em class="replaceable"><code>string</code></em> ; </span>]
     [<span class="optional"> masterfile-format (<code class="constant">text</code>|<code class="constant">raw</code>) ; </span>]
     [<span class="optional"> journal <em class="replaceable"><code>string</code></em> ; </span>]
+    [<span class="optional"> max-journal-size <em class="replaceable"><code>size_spec</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-from-differences <em class="replaceable"><code>yes_or_no</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"> max-ixfr-log-size <em class="replaceable"><code>number</code></em> ; </span>]
@@ -4916,11 +5280,15 @@ view "external" {
     [<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> | <em class="replaceable"><code>master-only</code></em> ; </span>]
     [<span class="optional"> notify-delay <em class="replaceable"><code>seconds</code></em> ; </span>]
+    [<span class="optional"> notify-to-soa <em class="replaceable"><code>yes_or_no</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"> 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"> sig-signing-nodes <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> sig-signing-signatures <em class="replaceable"><code>number</code></em> ; </span>]
+    [<span class="optional"> sig-signing-type <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>]
@@ -4934,18 +5302,22 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
     type slave;
     [<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-query-on { <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-forwarding { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
     [<span class="optional"> update-check-ksk <em class="replaceable"><code>yes_or_no</code></em>; </span>]
+    [<span class="optional"> try-tcp-refresh <em class="replaceable"><code>yes_or_no</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"> file <em class="replaceable"><code>string</code></em> ; </span>]
     [<span class="optional"> masterfile-format (<code class="constant">text</code>|<code class="constant">raw</code>) ; </span>]
     [<span class="optional"> journal <em class="replaceable"><code>string</code></em> ; </span>]
+    [<span class="optional"> max-journal-size <em class="replaceable"><code>size_spec</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-from-differences <em class="replaceable"><code>yes_or_no</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>]
@@ -4955,6 +5327,8 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
     [<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> | <em class="replaceable"><code>master-only</code></em> ; </span>]
+    [<span class="optional"> notify-delay <em class="replaceable"><code>seconds</code></em> ; </span>]
+    [<span class="optional"> notify-to-soa <em class="replaceable"><code>yes_or_no</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>]
@@ -4983,6 +5357,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
 zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"><em class="replaceable"><code>class</code></em></span>] {
     type stub;
     [<span class="optional"> allow-query { <em class="replaceable"><code>address_match_list</code></em> }; </span>]
+    [<span class="optional"> allow-query-on { <em class="replaceable"><code>address_match_list</code></em> }; </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>]
@@ -5023,10 +5398,10 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2587332"></a><span><strong class="command">zone</strong></span> Statement Definition and Usage</h3></div></div></div>
+<a name="id2588510"></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="id2587339"></a>Zone Types</h4></div></div></div>
+<a name="id2588518"></a>Zone Types</h4></div></div></div>
 <div class="informaltable"><table border="1">
 <colgroup>
 <col>
@@ -5089,7 +5464,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
                         <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
+                        behave very slowly if you put 100000 files into
                         a single directory.)
                       </p>
                     </td>
@@ -5235,7 +5610,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2587690"></a>Class</h4></div></div></div>
+<a name="id2588937"></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>),
@@ -5257,7 +5632,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2587723"></a>Zone Options</h4></div></div></div>
+<a name="id2588970"></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>
@@ -5269,6 +5644,11 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
                     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-query-on</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">allow-query-on</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>
@@ -5348,6 +5728,11 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
                     See the description of
                     <span><strong class="command">update-check-ksk</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">try-tcp-refresh</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">try-tcp-refresh</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">database</strong></span></span></dt>
 <dd>
 <p>
@@ -5424,6 +5809,11 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
                     The default is the zone's filename with "<code class="filename">.jnl</code>" appended.
                     This is applicable to <span><strong class="command">master</strong></span> and <span><strong class="command">slave</strong></span> zones.
                   </p></dd>
+<dt><span class="term"><span><strong class="command">max-journal-size</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">max-journal-size</strong></span> in <a href="Bv9ARM.ch06.html#server_resource_limits" title="Server  Resource Limits">the section called &#8220;Server  Resource Limits&#8221;</a>.
+                  </p></dd>
 <dt><span class="term"><span><strong class="command">max-transfer-time-in</strong></span></span></dt>
 <dd><p>
                     See the description of
@@ -5454,6 +5844,12 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
                     See the description of
                     <span><strong class="command">notify-delay</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">notify-to-soa</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">notify-to-soa</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 <acronym class="acronym">BIND</acronym> 8, this option was
@@ -5476,6 +5872,21 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
                     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">sig-signing-nodes</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">sig-signing-nodes</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">sig-signing-signatures</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">sig-signing-signatures</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">sig-signing-type</strong></span></span></dt>
+<dd><p>
+                    See the description of
+                    <span><strong class="command">sig-signing-type</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
@@ -5521,6 +5932,10 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
 <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>.
+                    (Note that the <span><strong class="command">ixfr-from-differences</strong></span>
+                    <strong class="userinput"><code>master</code></strong> and
+                    <strong class="userinput"><code>slave</code></strong> choices are not
+                    available at the zone level.)
                   </p></dd>
 <dt><span class="term"><span><strong class="command">key-directory</strong></span></span></dt>
 <dd><p>
@@ -5544,43 +5959,38 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
 <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>
-              <acronym class="acronym">BIND</acronym> 9 supports two alternative
-              methods of granting clients
-              the right to perform dynamic updates to a zone,
-              configured by the <span><strong class="command">allow-update</strong></span>
-              and
-              <span><strong class="command">update-policy</strong></span> option,
-              respectively.
+<p><acronym class="acronym">BIND</acronym> 9 supports two alternative
+              methods of granting clients the right to perform
+              dynamic updates to a zone, 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 <acronym class="acronym">BIND</acronym>. It grants given clients the
-              permission to update any record of any name in the zone.
+              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 <span><strong class="command">update-policy</strong></span> clause is new
-              in <acronym class="acronym">BIND</acronym>
-              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.
+              in <acronym class="acronym">BIND</acronym> 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 <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.
+              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:
@@ -5599,26 +6009,38 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
               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 <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 <em class="replaceable"><code>identity</code></em> field must
+              No signer is required for <em class="replaceable"><code>tcp-self</code></em>
+              or <em class="replaceable"><code>6to4-self</code></em> however the standard
+              reverse mapping / prefix conversion must match the identity
+              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.  TKEY is also the negotiation method used
+              by GSS-TSIG, which establishes an identity that is
+              the Kerberos principal of the client, such as
+              <strong class="userinput"><code>"user@host.domain"</code></strong>.  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 <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 6
+              The <em class="replaceable"><code>nametype</code></em> field has 12
               values:
               <code class="varname">name</code>, <code class="varname">subdomain</code>,
               <code class="varname">wildcard</code>, <code class="varname">self</code>,
-               <code class="varname">selfsub</code>, and <code class="varname">selfwild</code>.
+              <code class="varname">selfsub</code>, <code class="varname">selfwild</code>,
+              <code class="varname">krb5-self</code>, <code class="varname">ms-self</code>,
+              <code class="varname">krb5-subdomain</code>,
+              <code class="varname">ms-subdomain</code>,
+              <code class="varname">tcp-self</code> and <code class="varname">6to4-self</code>.
             </p>
 <div class="informaltable"><table border="1">
 <colgroup>
@@ -5723,6 +6145,47 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
                       </p>
                     </td>
 </tr>
+<tr>
+<td>
+                      <p>
+                        <code class="varname">tcp-self</code>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Allow updates that have been sent via TCP and
+                        for which the standard mapping from the initiating
+                        IP address into the IN-ADDR.ARPA and IP6.ARPA
+                        namespaces match the name to be updated.
+                      </p>
+                      <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+                        It is theoretically possible to spoof these TCP
+                        sessions.
+                      </div>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        <code class="varname">6to4-self</code>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Allow the 6to4 prefix to be update by any TCP
+                        conection from the 6to4 network or from the
+                        corresponding IPv4 address.  This is intended
+                        to allow NS or DNAME RRsets to be added to the
+                        reverse tree.
+                      </p>
+                      <div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
+<h3 class="title">Note</h3>
+                        It is theoretically possible to spoof these TCP
+                        sessions.
+                      </div>
+                    </td>
+</tr>
 </tbody>
 </table></div>
 <p>
@@ -5731,21 +6194,20 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
               specify a fully-qualified domain name.
             </p>
 <p>
-              If no types are explicitly specified, this rule matches all
-              types except
-              RRSIG, NS, SOA, and NSEC. Types may be specified by name, including
-              "ANY" (ANY matches all types except NSEC, 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.
+              If no types are explicitly specified, this rule matches
+              all types except RRSIG, NS, SOA, NSEC and NSEC3. Types
+              may be specified by name, including "ANY" (ANY matches
+              all types except NSEC and NSEC3, which can never be
+              updated).  Note that when an attempt is made to delete
+              all records associated with a name, the rules are
+              checked for each existing record type.
             </p>
 </div>
 </div>
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2589477"></a>Zone File</h2></div></div></div>
+<a name="id2591109"></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>
@@ -5758,7 +6220,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
           </p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2589495"></a>Resource Records</h4></div></div></div>
+<a name="id2591127"></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
@@ -5953,6 +6415,19 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
 <tr>
 <td>
                       <p>
+                        DHCID
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Is used for identifying which DHCP client is
+                        associated with this name.  Described in RFC 4701.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
                         DNAME
                       </p>
                     </td>
@@ -6159,6 +6634,40 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
 <tr>
 <td>
                       <p>
+                        NSEC3
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Used in DNSSECbis to securely indicate that
+                        RRs with an owner name in a certain name
+                        interval do not exist in a zone and indicate
+                        what RR types are present for an existing
+                        name.  NSEC3 differs from NSEC in that it
+                        prevents zone enumeration but is more
+                        computationally expensive on both the server
+                        and the client than NSEC.  Described in RFC
+                        5155.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
+                        NSEC3PARAM
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        Used in DNSSECbis to tell the authoritative
+                        server which NSEC3 chains are available to use.
+                        Described in RFC 5155.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p>
                         NXT
                       </p>
                     </td>
@@ -6304,7 +6813,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
                     </td>
 <td>
                       <p>
-                        Provides a way to securly publish a secure shell key's
+                        Provides a way to securely publish a secure shell key's
                         fingerprint.  Described in RFC 4255.
                       </p>
                     </td>
@@ -6448,7 +6957,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2590912"></a>Textual expression of RRs</h4></div></div></div>
+<a name="id2592682"></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
@@ -6651,7 +7160,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2591500"></a>Discussion of MX Records</h3></div></div></div>
+<a name="id2593203"></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
@@ -6685,8 +7194,6 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
             the mail will be delivered to the server specified in the MX
             record
             pointed to by the CNAME.
-          </p>
-<p>
             For example:
           </p>
 <div class="informaltable"><table border="1">
@@ -6909,7 +7416,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2592188"></a>Inverse Mapping in IPv4</h3></div></div></div>
+<a name="id2593886"></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
@@ -6970,7 +7477,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2592384"></a>Other Zone File Directives</h3></div></div></div>
+<a name="id2594013"></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
@@ -6985,7 +7492,7 @@ zone <em class="replaceable"><code>zone_name</code></em> [<span class="optional"
           </p>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2592406"></a>The <span><strong class="command">$ORIGIN</strong></span> Directive</h4></div></div></div>
+<a name="id2594036"></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>
@@ -7013,7 +7520,7 @@ WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2592467"></a>The <span><strong class="command">$INCLUDE</strong></span> Directive</h4></div></div></div>
+<a name="id2594097"></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>
@@ -7049,7 +7556,7 @@ WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
 </div>
 <div class="sect3" lang="en">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2592536"></a>The <span><strong class="command">$TTL</strong></span> Directive</h4></div></div></div>
+<a name="id2594234"></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>
@@ -7068,7 +7575,7 @@ WWW.EXAMPLE.COM. CNAME MAIN-SERVER.EXAMPLE.COM.
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2592572"></a><acronym class="acronym">BIND</acronym> Master File Extension: the  <span><strong class="command">$GENERATE</strong></span> Directive</h3></div></div></div>
+<a name="id2594270"></a><acronym class="acronym">BIND</acronym> 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>
@@ -7128,7 +7635,7 @@ $GENERATE 1-127 $ CNAME $.0</pre>
                       describes the owner name of the resource records
                       to be created.  Any single <span><strong class="command">$</strong></span>
                       (dollar sign)
-                      symbols within the <span><strong class="command">lhs</strong></span> side
+                      symbols within the <span><strong class="command">lhs</strong></span> string
                       are replaced by the iterator value.
 
                       To get a $ in the output, you need to escape the
@@ -7172,7 +7679,7 @@ $GENERATE 1-127 $ CNAME $.0</pre>
                     <p>
                       Specifies the time-to-live of the generated records. If
                       not specified this will be inherited using the
-                      normal ttl inheritance rules.
+                      normal TTL inheritance rules.
                     </p>
                     <p><span><strong class="command">class</strong></span>
                       and <span><strong class="command">ttl</strong></span> can be
@@ -7271,6 +7778,1470 @@ $GENERATE 1-127 $ CNAME $.0</pre>
           </p>
 </div>
 </div>
+<div class="sect1" lang="en">
+<div class="titlepage"><div><div><h2 class="title" style="clear: both">
+<a name="statistics"></a>BIND9 Statistics</h2></div></div></div>
+<p>
+          <acronym class="acronym">BIND</acronym> 9 maintains lots of statistics
+          information and provides several interfaces for users to
+          get access to the statistics.
+          The available statistics include all statistics counters
+          that were available in <acronym class="acronym">BIND</acronym> 8 and
+          are meaningful in <acronym class="acronym">BIND</acronym> 9,
+          and other information that is considered useful.
+        </p>
+<p>
+          The statistics information is categorized into the following
+          sections.
+        </p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+                  <p>Incoming Requests</p>
+                </td>
+<td>
+                  <p>
+                    The number of incoming DNS requests for each OPCODE.
+                  </p>
+                </td>
+</tr>
+<tr>
+<td>
+                  <p>Incoming Queries</p>
+                </td>
+<td>
+                  <p>
+                    The number of incoming queries for each RR type.
+                  </p>
+                </td>
+</tr>
+<tr>
+<td>
+                  <p>Outgoing Queries</p>
+                </td>
+<td>
+                  <p>
+                    The number of outgoing queries for each RR
+                    type sent from the internal resolver.
+                    Maintained per view.
+                  </p>
+                </td>
+</tr>
+<tr>
+<td>
+                  <p>Name Server Statistics</p>
+                </td>
+<td>
+                  <p>
+                    Statistics counters about incoming request processing.
+                  </p>
+                </td>
+</tr>
+<tr>
+<td>
+                  <p>Zone Maintenance Statistics</p>
+                </td>
+<td>
+                  <p>
+                    Statistics counters regarding zone maintenance
+                    operations such as zone transfers.
+                  </p>
+                </td>
+</tr>
+<tr>
+<td>
+                  <p>Resolver Statistics</p>
+                </td>
+<td>
+                  <p>
+                    Statistics counters about name resolution
+                    performed in the internal resolver.
+                    Maintained per view.
+                  </p>
+                </td>
+</tr>
+<tr>
+<td>
+                  <p>Cache DB RRsets</p>
+                </td>
+<td>
+                  <p>
+                    The number of RRsets per RR type (positive
+                    or negative) and nonexistent names stored in the
+                    cache database.
+                    Maintained per view.
+                  </p>
+                </td>
+</tr>
+<tr>
+<td>
+                  <p>Socket I/O Statistics</p>
+                </td>
+<td>
+                  <p>
+                    Statistics counters about network related events.
+                  </p>
+                </td>
+</tr>
+</tbody>
+</table></div>
+<p>
+          A subset of Name Server Statistics is collected and shown
+          per zone for which the server has the authority when
+          <span><strong class="command">zone-statistics</strong></span> is set to
+          <strong class="userinput"><code>yes</code></strong>.
+          These statistics counters are shown with their zone and view
+          names.
+          In some cases the view names are omitted for the default view.
+        </p>
+<p>
+          There are currently two user interfaces to get access to the
+          statistics.
+          One is in the plain text format dumped to the file specified
+          by the <span><strong class="command">statistics-file</strong></span> configuration option.
+          The other is remotely accessible via a statistics channel
+          when the <span><strong class="command">statistics-channels</strong></span> statement
+          is specified in the configuration file
+          (see <a href="Bv9ARM.ch06.html#statschannels" title="statistics-channels Statement Grammar">the section called &#8220;<span><strong class="command">statistics-channels</strong></span> Statement Grammar&#8221;</a>.)
+        </p>
+<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 text format statistics dump begins with a line, like:
+          </p>
+<p>
+            <span><strong class="command">+++ Statistics Dump +++ (973798949)</strong></span>
+          </p>
+<p>
+            The number in parentheses is a standard
+            Unix-style timestamp, measured as seconds since January 1, 1970.
+
+            Following
+            that line is a set of statistics information, which is categorized
+            as described above.
+            Each section begins with a line, like:
+          </p>
+<p>
+            <span><strong class="command">++ Name Server Statistics ++</strong></span>
+          </p>
+<p>
+            Each section consists of lines, each containing the statistics
+            counter value followed by its textual description.
+            See below for available counters.
+            For brevity, counters that have a value of 0 are not shown
+            in the statistics file.
+          </p>
+<p>
+            The statistics dump ends with the line where the
+            number is identical to the number in the beginning line; for example:
+          </p>
+<p>
+            <span><strong class="command">--- Statistics Dump --- (973798949)</strong></span>
+          </p>
+</div>
+<div class="sect2" lang="en">
+<div class="titlepage"><div><div><h3 class="title">
+<a name="statistics_counters"></a>Statistics Counters</h3></div></div></div>
+<p>
+            The following tables summarize statistics counters that
+            <acronym class="acronym">BIND</acronym> 9 provides.
+            For each row of the tables, the leftmost column is the
+            abbreviated symbol name of that counter.
+            These symbols are shown in the statistics information
+            accessed via an HTTP statistics channel.
+            The rightmost column gives the description of the counter,
+            which is also shown in the statistics file
+            (but, in this document, possibly with slight modification
+            for better readability).
+            Additional notes may also be provided in this column.
+            When a middle column exists between these two columns,
+            it gives the corresponding counter name of the
+            <acronym class="acronym">BIND</acronym> 8 statistics, if applicable.
+          </p>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2595267"></a>Name Server Statistics Counters</h4></div></div></div>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+                      <p>
+                        <span class="emphasis"><em>Symbol</em></span>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        <span class="emphasis"><em>BIND8 Symbol</em></span>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        <span class="emphasis"><em>Description</em></span>
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">Requestv4</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command">RQ</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        IPv4 requests received.
+                        Note: this also counts non query requests.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">Requestv6</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command">RQ</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        IPv6 requests received.
+                        Note: this also counts non query requests.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">ReqEdns0</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Requests with EDNS(0) received.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">ReqBadEDNSVer</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Requests with unsupported EDNS version received.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">ReqTSIG</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Requests with TSIG received.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">ReqSIG0</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Requests with SIG(0) received.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">ReqBadSIG</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Requests with invalid (TSIG or SIG(0)) signature.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">ReqTCP</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command">RTCP</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        TCP requests received.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">AuthQryRej</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command">RUQ</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Authoritative (non recursive) queries rejected.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">RecQryRej</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command">RURQ</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Recursive queries rejected.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">XfrRej</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command">RUXFR</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Zone transfer requests rejected.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">UpdateRej</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command">RUUpd</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Dynamic update requests rejected.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">Response</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command">SAns</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Responses sent.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">RespTruncated</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Truncated responses sent.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">RespEDNS0</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Responses with EDNS(0) sent.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">RespTSIG</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Responses with TSIG sent.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">RespSIG0</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Responses with SIG(0) sent.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">QrySuccess</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Queries resulted in a successful answer.
+                        This means the query which returns a NOERROR response
+                        with at least one answer RR.
+                        This corresponds to the
+                        <span><strong class="command">success</strong></span> counter
+                        of previous versions of
+                        <acronym class="acronym">BIND</acronym> 9.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">QryAuthAns</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Queries resulted in authoritative answer.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">QryNoauthAns</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command">SNaAns</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Queries resulted in non authoritative answer.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">QryReferral</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Queries resulted in referral answer.
+                        This corresponds to the
+                        <span><strong class="command">referral</strong></span> counter
+                        of previous versions of
+                        <acronym class="acronym">BIND</acronym> 9.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">QryNxrrset</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Queries resulted in NOERROR responses with no data.
+                        This corresponds to the
+                        <span><strong class="command">nxrrset</strong></span> counter
+                        of previous versions of
+                        <acronym class="acronym">BIND</acronym> 9.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">QrySERVFAIL</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command">SFail</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Queries resulted in SERVFAIL.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">QryFORMERR</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command">SFErr</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Queries resulted in FORMERR.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">QryNXDOMAIN</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command">SNXD</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Queries resulted in NXDOMAIN.
+                        This corresponds to the
+                        <span><strong class="command">nxdomain</strong></span> counter
+                        of previous versions of
+                        <acronym class="acronym">BIND</acronym> 9.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">QryRecursion</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command">RFwdQ</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Queries which caused the server
+                        to perform recursion in order to find the final answer.
+                        This corresponds to the
+                        <span><strong class="command">recursion</strong></span> counter
+                        of previous versions of
+                        <acronym class="acronym">BIND</acronym> 9.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">QryDuplicate</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command">RDupQ</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Queries which the server attempted to
+                        recurse but discovered an existing query with the same
+                        IP address, port, query ID, name, type and class
+                        already being processed.
+                        This corresponds to the
+                        <span><strong class="command">duplicate</strong></span> counter
+                        of previous versions of
+                        <acronym class="acronym">BIND</acronym> 9.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">QryDropped</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Recursive queries for which the server
+                        discovered an excessive number of existing
+                        recursive queries for the same name, type and
+                        class and were subsequently dropped.
+                        This is the number of dropped queries due to
+                        the reason explained with the
+                        <span><strong class="command">clients-per-query</strong></span>
+                        and
+                        <span><strong class="command">max-clients-per-query</strong></span>
+                        options
+                        (see the description about
+                        <a href="Bv9ARM.ch06.html#clients-per-query"><span><strong class="command">clients-per-query</strong></span></a>.)
+                        This corresponds to the
+                        <span><strong class="command">dropped</strong></span> counter
+                        of previous versions of
+                        <acronym class="acronym">BIND</acronym> 9.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">QryFailure</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Other query failures.
+                        This corresponds to the
+                        <span><strong class="command">failure</strong></span> counter
+                        of previous versions of
+                        <acronym class="acronym">BIND</acronym> 9.
+                        Note: this counter is provided mainly for
+                        backward compatibility with the previous versions.
+                        Normally a more fine-grained counters such as
+                        <span><strong class="command">AuthQryRej</strong></span> and
+                        <span><strong class="command">RecQryRej</strong></span>
+                        that would also fall into this counter are provided,
+                        and so this counter would not be of much
+                        interest in practice.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">XfrReqDone</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Requested zone transfers completed.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">UpdateReqFwd</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Update requests forwarded.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">UpdateRespFwd</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Update responses forwarded.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">UpdateFwdFail</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Dynamic update forward failed.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">UpdateDone</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Dynamic updates completed.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">UpdateFail</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Dynamic updates failed.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">UpdateBadPrereq</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Dynamic updates rejected due to prerequisite failure.
+                      </p>
+                    </td>
+</tr>
+</tbody>
+</table></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2596808"></a>Zone Maintenance Statistics Counters</h4></div></div></div>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+                      <p>
+                        <span class="emphasis"><em>Symbol</em></span>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        <span class="emphasis"><em>Description</em></span>
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">NotifyOutv4</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        IPv4 notifies sent.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">NotifyOutv6</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        IPv6 notifies sent.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">NotifyInv4</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        IPv4 notifies received.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">NotifyInv6</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        IPv6 notifies received.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">NotifyRej</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Incoming notifies rejected.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">SOAOutv4</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        IPv4 SOA queries sent.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">SOAOutv6</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        IPv6 SOA queries sent.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">AXFRReqv4</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        IPv4 AXFR requested.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">AXFRReqv6</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        IPv6 AXFR requested.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">IXFRReqv4</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        IPv4 IXFR requested.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">IXFRReqv6</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        IPv6 IXFR requested.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">XfrSuccess</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Zone transfer requests succeeded.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">XfrFail</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Zone transfer requests failed.
+                      </p>
+                    </td>
+</tr>
+</tbody>
+</table></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2597191"></a>Resolver Statistics Counters</h4></div></div></div>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+                      <p>
+                        <span class="emphasis"><em>Symbol</em></span>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        <span class="emphasis"><em>BIND8 Symbol</em></span>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        <span class="emphasis"><em>Description</em></span>
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">Queryv4</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command">SFwdQ</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        IPv4 queries sent.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">Queryv6</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command">SFwdQ</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        IPv6 queries sent.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">Responsev4</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command">RR</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        IPv4 responses received.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">Responsev6</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command">RR</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        IPv6 responses received.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">NXDOMAIN</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command">RNXD</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        NXDOMAIN received.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">SERVFAIL</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command">RFail</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        SERVFAIL received.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">FORMERR</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command">RFErr</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        FORMERR received.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">OtherError</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command">RErr</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Other errors received.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">EDNS0Fail</strong></span></p>
+                                                 </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        EDNS(0) query failures.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">Mismatch</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command">RDupR</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Mismatch responses received.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">Truncated</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Truncated responses received.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">Lame</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command">RLame</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Lame delegations received.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">Retry</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command">SDupQ</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Query retries performed.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">QueryAbort</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Queries aborted due to quota control.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">QuerySockFail</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Failures in opening query sockets.
+                        One common reason for such failures is a
+                        failure of opening a new socket due to a
+                        limitation on file descriptors.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">QueryTimeout</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Query timeouts.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">GlueFetchv4</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command">SSysQ</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        IPv4 NS address fetches invoked.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">GlueFetchv6</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command">SSysQ</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        IPv6 NS address fetches invoked.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">GlueFetchv4Fail</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        IPv4 NS address fetch failed.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">GlueFetchv6Fail</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        IPv6 NS address fetch failed.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">ValAttempt</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        DNSSEC validation attempted.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">ValOk</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        DNSSEC validation succeeded.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">ValNegOk</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        DNSSEC validation on negative information succeeded.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">ValFail</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        DNSSEC validation failed.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">QryRTTnn</strong></span></p>
+                    </td>
+<td>
+                      <p><span><strong class="command"></strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Frequency table on round trip times (RTTs) of
+                        queries.
+                        Each <span><strong class="command">nn</strong></span> specifies the corresponding
+                        frequency.
+                        In the sequence of
+                        <span><strong class="command">nn_1</strong></span>,
+                        <span><strong class="command">nn_2</strong></span>,
+                        ...,
+                        <span><strong class="command">nn_m</strong></span>,
+                        the value of <span><strong class="command">nn_i</strong></span> is the
+                        number of queries whose RTTs are between
+                        <span><strong class="command">nn_(i-1)</strong></span> (inclusive) and
+                        <span><strong class="command">nn_i</strong></span> (exclusive) milliseconds.
+                        For the sake of convenience we define
+                        <span><strong class="command">nn_0</strong></span> to be 0.
+                        The last entry should be represented as
+                        <span><strong class="command">nn_m+</strong></span>, which means the
+                        number of queries whose RTTs are equal to or over
+                        <span><strong class="command">nn_m</strong></span> milliseconds.
+                      </p>
+                    </td>
+</tr>
+</tbody>
+</table></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2598210"></a>Socket I/O Statistics Counters</h4></div></div></div>
+<p>
+              Socket I/O statistics counters are defined per socket
+              types, which are
+              <span><strong class="command">UDP4</strong></span> (UDP/IPv4),
+              <span><strong class="command">UDP6</strong></span> (UDP/IPv6),
+              <span><strong class="command">TCP4</strong></span> (TCP/IPv4),
+              <span><strong class="command">TCP6</strong></span> (TCP/IPv6),
+              <span><strong class="command">Unix</strong></span> (Unix Domain), and
+              <span><strong class="command">FDwatch</strong></span> (sockets opened outside the
+              socket module).
+              In the following table <span><strong class="command">&lt;TYPE&gt;</strong></span>
+              represents a socket type.
+              Not all counters are available for all socket types;
+              exceptions are noted in the description field.
+            </p>
+<div class="informaltable"><table border="1">
+<colgroup>
+<col>
+<col>
+</colgroup>
+<tbody>
+<tr>
+<td>
+                      <p>
+                        <span class="emphasis"><em>Symbol</em></span>
+                      </p>
+                    </td>
+<td>
+                      <p>
+                        <span class="emphasis"><em>Description</em></span>
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">&lt;TYPE&gt;Open</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Sockets opened successfully.
+                        This counter is not applicable to the
+                        <span><strong class="command">FDwatch</strong></span> type.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">&lt;TYPE&gt;OpenFail</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Failures of opening sockets.
+                        This counter is not applicable to the
+                        <span><strong class="command">FDwatch</strong></span> type.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">&lt;TYPE&gt;Close</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Sockets closed.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">&lt;TYPE&gt;BindFail</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Failures of binding sockets.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">&lt;TYPE&gt;ConnFail</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Failures of connecting sockets.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">&lt;TYPE&gt;Conn</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Connections established successfully.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">&lt;TYPE&gt;AcceptFail</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Failures of accepting incoming connection requests.
+                        This counter is not applicable to the
+                        <span><strong class="command">UDP</strong></span> and
+                        <span><strong class="command">FDwatch</strong></span> types.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">&lt;TYPE&gt;Accept</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Incoming connections successfully accepted.
+                        This counter is not applicable to the
+                        <span><strong class="command">UDP</strong></span> and
+                        <span><strong class="command">FDwatch</strong></span> types.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">&lt;TYPE&gt;SendErr</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Errors in socket send operations.
+                        This counter corresponds
+                        to <span><strong class="command">SErr</strong></span> counter of
+                        <span><strong class="command">BIND</strong></span> 8.
+                      </p>
+                    </td>
+</tr>
+<tr>
+<td>
+                      <p><span><strong class="command">&lt;TYPE&gt;RecvErr</strong></span></p>
+                    </td>
+<td>
+                      <p>
+                        Errors in socket receive operations.
+                        This includes errors of send operations on a
+                        connected UDP socket notified by an ICMP error
+                        message.
+                      </p>
+                    </td>
+</tr>
+</tbody>
+</table></div>
+</div>
+<div class="sect3" lang="en">
+<div class="titlepage"><div><div><h4 class="title">
+<a name="id2598651"></a>Compatibility with <span class="emphasis"><em>BIND</em></span> 8 Counters</h4></div></div></div>
+<p>
+              Most statistics counters that were available
+              in <span><strong class="command">BIND</strong></span> 8 are also supported in
+              <span><strong class="command">BIND</strong></span> 9 as shown in the above tables.
+              Here are notes about other counters that do not appear
+              in these tables.
+            </p>
+<div class="variablelist"><dl>
+<dt><span class="term"><span><strong class="command">RFwdR,SFwdR</strong></span></span></dt>
+<dd><p>
+                    These counters are not supported
+                    because <span><strong class="command">BIND</strong></span> 9 does not adopt
+                    the notion of <span class="emphasis"><em>forwarding</em></span>
+                    as <span><strong class="command">BIND</strong></span> 8 did.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">RAXFR</strong></span></span></dt>
+<dd><p>
+                    This counter is accessible in the Incoming Queries section.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">RIQ</strong></span></span></dt>
+<dd><p>
+                    This counter is accessible in the Incoming Requests section.
+                  </p></dd>
+<dt><span class="term"><span><strong class="command">ROpts</strong></span></span></dt>
+<dd><p>
+                    This counter is not supported
+                    because <span><strong class="command">BIND</strong></span> 9 does not care
+                    about IP options in the first place.
+                  </p></dd>
+</dl></div>
+</div>
+</div>
+</div>
 </div>
 <div class="navfooter">
 <hr>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch07.html b/contrib/bind9/doc/arm/Bv9ARM.ch07.html
index 4ddbced..80ba6e3 100644
--- a/contrib/bind9/doc/arm/Bv9ARM.ch07.html
+++ b/contrib/bind9/doc/arm/Bv9ARM.ch07.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch07.html,v 1.75.18.76 2008/10/16 01:29:41 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch07.html,v 1.178.14.5 2009/04/03 01:52:22 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -46,10 +46,10 @@
 <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#id2593181"><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span></a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch07.html#id2598893"><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span></a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2593326">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2593386">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2598974">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2599034">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>
@@ -58,9 +58,10 @@
 <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
+          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">allow-query</strong></span>, <span><strong class="command">allow-query-on</strong></span>,
+          <span><strong class="command">allow-recursion</strong></span>, <span><strong class="command">allow-recursion-on</strong></span>,
           <span><strong class="command">blackhole</strong></span>, <span><strong class="command">allow-transfer</strong></span>,
           etc.
         </p>
@@ -118,14 +119,16 @@ zone "example.com" {
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2593181"></a><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span>
+<a name="id2598893"></a><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span>
 </h2></div></div></div>
 <p>
-          On UNIX servers, it is possible to run <acronym class="acronym">BIND</acronym> in a <span class="emphasis"><em>chrooted</em></span> environment
-          (using the <span><strong class="command">chroot()</strong></span> function) by specifying the "<code class="option">-t</code>"
-          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.
+          On UNIX servers, it is possible to run <acronym class="acronym">BIND</acronym>
+          in a <span class="emphasis"><em>chrooted</em></span> environment (using
+          the <span><strong class="command">chroot()</strong></span> function) by specifying
+          the "<code class="option">-t</code>" option for <span><strong class="command">named</strong></span>.
+          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
@@ -138,11 +141,11 @@ zone "example.com" {
           user 202:
         </p>
 <p>
-          <strong class="userinput"><code>/usr/local/bin/named -u 202 -t /var/named</code></strong>
+          <strong class="userinput"><code>/usr/local/sbin/named -u 202 -t /var/named</code></strong>
         </p>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2593326"></a>The <span><strong class="command">chroot</strong></span> Environment</h3></div></div></div>
+<a name="id2598974"></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
@@ -170,7 +173,7 @@ zone "example.com" {
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2593386"></a>Using the <span><strong class="command">setuid</strong></span> Function</h3></div></div></div>
+<a name="id2599034"></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
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch08.html b/contrib/bind9/doc/arm/Bv9ARM.ch08.html
index 65f8cec..65ca623 100644
--- a/contrib/bind9/doc/arm/Bv9ARM.ch08.html
+++ b/contrib/bind9/doc/arm/Bv9ARM.ch08.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch08.html,v 1.75.18.77 2008/10/16 01:29:41 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch08.html,v 1.178.14.5 2009/04/03 01:52:22 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -45,18 +45,18 @@
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2593466">Common Problems</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2593472">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#id2593483">Incrementing and Changing the Serial Number</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2593500">Where Can I Get Help?</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2599251">Common Problems</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2599324">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#id2599336">Incrementing and Changing the Serial Number</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2599353">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="id2593466"></a>Common Problems</h2></div></div></div>
+<a name="id2599251"></a>Common Problems</h2></div></div></div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2593472"></a>It's not working; how can I figure out what's wrong?</h3></div></div></div>
+<a name="id2599324"></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
@@ -68,7 +68,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2593483"></a>Incrementing and Changing the Serial Number</h2></div></div></div>
+<a name="id2599336"></a>Incrementing and Changing the Serial Number</h2></div></div></div>
 <p>
           Zone serial numbers are just numbers &#8212; they aren't
           date related.  A lot of people set them to a number that
@@ -95,7 +95,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2593500"></a>Where Can I Get Help?</h2></div></div></div>
+<a name="id2599353"></a>Where Can I Get Help?</h2></div></div></div>
 <p>
           The Internet Systems Consortium
           (<acronym class="acronym">ISC</acronym>) offers a wide range
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch09.html b/contrib/bind9/doc/arm/Bv9ARM.ch09.html
index 71ea617..3664b99 100644
--- a/contrib/bind9/doc/arm/Bv9ARM.ch09.html
+++ b/contrib/bind9/doc/arm/Bv9ARM.ch09.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch09.html,v 1.75.18.80 2008/10/18 01:29:59 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch09.html,v 1.180.16.5 2009/04/03 01:52:22 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -45,21 +45,21 @@
 <div class="toc">
 <p><b>Table of Contents</b></p>
 <dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2593630">Acknowledgments</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2599415">Acknowledgments</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#historical_dns_information">A Brief History of the <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym></a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2593802">General <acronym class="acronym">DNS</acronym> Reference Information</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2599587">General <acronym class="acronym">DNS</acronym> 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#id2597082">Other Documents About <acronym class="acronym">BIND</acronym></a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2602867">Other Documents About <acronym class="acronym">BIND</acronym></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="id2593630"></a>Acknowledgments</h2></div></div></div>
+<a name="id2599415"></a>Acknowledgments</h2></div></div></div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
 <a name="historical_dns_information"></a>A Brief History of the <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym>
@@ -148,11 +148,9 @@
             BIND architecture.
           </p>
 <p>
-            BIND version 4 is officially deprecated and BIND version
-            8 development is considered maintenance-only in favor
-            of BIND version 9. No additional development is done
-            on BIND version 4 or BIND version 8 other than for
-            security-related patches.
+            BIND versions 4 and 8 are officially deprecated.
+            No additional development is done
+            on BIND version 4 or BIND version 8.
           </p>
 <p>
             <acronym class="acronym">BIND</acronym> development work is made
@@ -164,7 +162,7 @@
 </div>
 <div class="sect1" lang="en">
 <div class="titlepage"><div><div><h2 class="title" style="clear: both">
-<a name="id2593802"></a>General <acronym class="acronym">DNS</acronym> Reference Information</h2></div></div></div>
+<a name="id2599587"></a>General <acronym class="acronym">DNS</acronym> 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>
@@ -252,17 +250,17 @@
           </p>
 <div class="bibliography">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2593990"></a>Bibliography</h4></div></div></div>
+<a name="id2599843"></a>Bibliography</h4></div></div></div>
 <div class="bibliodiv">
 <h3 class="title">Standards</h3>
 <div class="biblioentry">
-<a name="id2594001"></a><p>[<abbr class="abbrev">RFC974</abbr>] <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>
+<a name="id2599853"></a><p>[<abbr class="abbrev">RFC974</abbr>] <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">
-<a name="id2594024"></a><p>[<abbr class="abbrev">RFC1034</abbr>] <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>
+<a name="id2599877"></a><p>[<abbr class="abbrev">RFC1034</abbr>] <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">
-<a name="id2594048"></a><p>[<abbr class="abbrev">RFC1035</abbr>] <span class="author"><span class="firstname">P. V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i>Domain Names &#8212; Implementation and
+<a name="id2599900"></a><p>[<abbr class="abbrev">RFC1035</abbr>] <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>
@@ -270,42 +268,42 @@
 <h3 class="title">
 <a name="proposed_standards"></a>Proposed Standards</h3>
 <div class="biblioentry">
-<a name="id2594084"></a><p>[<abbr class="abbrev">RFC2181</abbr>] <span class="author"><span class="firstname">R., R. Bush</span> <span class="surname">Elz</span>. </span><span class="title"><i>Clarifications to the <acronym class="acronym">DNS</acronym>
+<a name="id2599937"></a><p>[<abbr class="abbrev">RFC2181</abbr>] <span class="author"><span class="firstname">R., R. Bush</span> <span class="surname">Elz</span>. </span><span class="title"><i>Clarifications to the <acronym class="acronym">DNS</acronym>
                   Specification</i>. </span><span class="pubdate">July 1997. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2594110"></a><p>[<abbr class="abbrev">RFC2308</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Andrews</span>. </span><span class="title"><i>Negative Caching of <acronym class="acronym">DNS</acronym>
+<a name="id2599963"></a><p>[<abbr class="abbrev">RFC2308</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Andrews</span>. </span><span class="title"><i>Negative Caching of <acronym class="acronym">DNS</acronym>
                   Queries</i>. </span><span class="pubdate">March 1998. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2594136"></a><p>[<abbr class="abbrev">RFC1995</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Ohta</span>. </span><span class="title"><i>Incremental Zone Transfer in <acronym class="acronym">DNS</acronym></i>. </span><span class="pubdate">August 1996. </span></p>
+<a name="id2599989"></a><p>[<abbr class="abbrev">RFC1995</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Ohta</span>. </span><span class="title"><i>Incremental Zone Transfer in <acronym class="acronym">DNS</acronym></i>. </span><span class="pubdate">August 1996. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2594161"></a><p>[<abbr class="abbrev">RFC1996</abbr>] <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>
+<a name="id2600013"></a><p>[<abbr class="abbrev">RFC1996</abbr>] <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">
-<a name="id2594184"></a><p>[<abbr class="abbrev">RFC2136</abbr>] <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>
+<a name="id2600037"></a><p>[<abbr class="abbrev">RFC2136</abbr>] <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">
-<a name="id2594240"></a><p>[<abbr class="abbrev">RFC2671</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Extension Mechanisms for DNS (EDNS0)</i>. </span><span class="pubdate">August 1997. </span></p>
+<a name="id2600092"></a><p>[<abbr class="abbrev">RFC2671</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="title"><i>Extension Mechanisms for DNS (EDNS0)</i>. </span><span class="pubdate">August 1997. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2594266"></a><p>[<abbr class="abbrev">RFC2672</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span>. </span><span class="title"><i>Non-Terminal DNS Name Redirection</i>. </span><span class="pubdate">August 1999. </span></p>
+<a name="id2600119"></a><p>[<abbr class="abbrev">RFC2672</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span>. </span><span class="title"><i>Non-Terminal DNS Name Redirection</i>. </span><span class="pubdate">August 1999. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2594293"></a><p>[<abbr class="abbrev">RFC2845</abbr>] <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 <acronym class="acronym">DNS</acronym> (TSIG)</i>. </span><span class="pubdate">May 2000. </span></p>
+<a name="id2600146"></a><p>[<abbr class="abbrev">RFC2845</abbr>] <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 <acronym class="acronym">DNS</acronym> (TSIG)</i>. </span><span class="pubdate">May 2000. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2594423"></a><p>[<abbr class="abbrev">RFC2930</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Secret Key Establishment for DNS (TKEY RR)</i>. </span><span class="pubdate">September 2000. </span></p>
+<a name="id2600208"></a><p>[<abbr class="abbrev">RFC2930</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Secret Key Establishment for DNS (TKEY RR)</i>. </span><span class="pubdate">September 2000. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2594453"></a><p>[<abbr class="abbrev">RFC2931</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>DNS Request and Transaction Signatures (SIG(0)s)</i>. </span><span class="pubdate">September 2000. </span></p>
+<a name="id2600237"></a><p>[<abbr class="abbrev">RFC2931</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>DNS Request and Transaction Signatures (SIG(0)s)</i>. </span><span class="pubdate">September 2000. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2594483"></a><p>[<abbr class="abbrev">RFC3007</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Secure Domain Name System (DNS) Dynamic Update</i>. </span><span class="pubdate">November 2000. </span></p>
+<a name="id2600267"></a><p>[<abbr class="abbrev">RFC3007</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Secure Domain Name System (DNS) Dynamic Update</i>. </span><span class="pubdate">November 2000. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2594509"></a><p>[<abbr class="abbrev">RFC3645</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Kwan</span>, <span class="firstname">P.</span> <span class="surname">Garg</span>, <span class="firstname">J.</span> <span class="surname">Gilroy</span>, <span class="firstname">L.</span> <span class="surname">Esibov</span>, <span class="firstname">J.</span> <span class="surname">Westhead</span>, and <span class="firstname">R.</span> <span class="surname">Hall</span>. </span><span class="title"><i>Generic Security Service Algorithm for Secret
+<a name="id2600294"></a><p>[<abbr class="abbrev">RFC3645</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Kwan</span>, <span class="firstname">P.</span> <span class="surname">Garg</span>, <span class="firstname">J.</span> <span class="surname">Gilroy</span>, <span class="firstname">L.</span> <span class="surname">Esibov</span>, <span class="firstname">J.</span> <span class="surname">Westhead</span>, and <span class="firstname">R.</span> <span class="surname">Hall</span>. </span><span class="title"><i>Generic Security Service Algorithm for Secret
                        Key Transaction Authentication for DNS
                        (GSS-TSIG)</i>. </span><span class="pubdate">October 2003. </span></p>
 </div>
@@ -314,19 +312,19 @@
 <h3 class="title">
 <acronym class="acronym">DNS</acronym> Security Proposed Standards</h3>
 <div class="biblioentry">
-<a name="id2594592"></a><p>[<abbr class="abbrev">RFC3225</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Conrad</span>. </span><span class="title"><i>Indicating Resolver Support of DNSSEC</i>. </span><span class="pubdate">December 2001. </span></p>
+<a name="id2600376"></a><p>[<abbr class="abbrev">RFC3225</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Conrad</span>. </span><span class="title"><i>Indicating Resolver Support of DNSSEC</i>. </span><span class="pubdate">December 2001. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2594618"></a><p>[<abbr class="abbrev">RFC3833</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Atkins</span> and <span class="firstname">R.</span> <span class="surname">Austein</span>. </span><span class="title"><i>Threat Analysis of the Domain Name System (DNS)</i>. </span><span class="pubdate">August 2004. </span></p>
+<a name="id2600403"></a><p>[<abbr class="abbrev">RFC3833</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Atkins</span> and <span class="firstname">R.</span> <span class="surname">Austein</span>. </span><span class="title"><i>Threat Analysis of the Domain Name System (DNS)</i>. </span><span class="pubdate">August 2004. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2594654"></a><p>[<abbr class="abbrev">RFC4033</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>DNS Security Introduction and Requirements</i>. </span><span class="pubdate">March 2005. </span></p>
+<a name="id2600439"></a><p>[<abbr class="abbrev">RFC4033</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>DNS Security Introduction and Requirements</i>. </span><span class="pubdate">March 2005. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2594720"></a><p>[<abbr class="abbrev">RFC4044</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Resource Records for the DNS Security Extensions</i>. </span><span class="pubdate">March 2005. </span></p>
+<a name="id2600504"></a><p>[<abbr class="abbrev">RFC4034</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Resource Records for the DNS Security Extensions</i>. </span><span class="pubdate">March 2005. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2594785"></a><p>[<abbr class="abbrev">RFC4035</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Protocol Modifications for the DNS
+<a name="id2600569"></a><p>[<abbr class="abbrev">RFC4035</abbr>] <span class="authorgroup"><span class="firstname">R.</span> <span class="surname">Arends</span>, <span class="firstname">R.</span> <span class="surname">Austein</span>, <span class="firstname">M.</span> <span class="surname">Larson</span>, <span class="firstname">D.</span> <span class="surname">Massey</span>, and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Protocol Modifications for the DNS
                        Security Extensions</i>. </span><span class="pubdate">March 2005. </span></p>
 </div>
 </div>
@@ -334,146 +332,146 @@
 <h3 class="title">Other Important RFCs About <acronym class="acronym">DNS</acronym>
                 Implementation</h3>
 <div class="biblioentry">
-<a name="id2594858"></a><p>[<abbr class="abbrev">RFC1535</abbr>] <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
+<a name="id2600643"></a><p>[<abbr class="abbrev">RFC1535</abbr>] <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 <acronym class="acronym">DNS</acronym> Software.</i>. </span><span class="pubdate">October 1993. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2594884"></a><p>[<abbr class="abbrev">RFC1536</abbr>] <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 <acronym class="acronym">DNS</acronym> Implementation
+<a name="id2600668"></a><p>[<abbr class="abbrev">RFC1536</abbr>] <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 <acronym class="acronym">DNS</acronym> Implementation
                   Errors and Suggested Fixes</i>. </span><span class="pubdate">October 1993. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2594952"></a><p>[<abbr class="abbrev">RFC1982</abbr>] <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>
+<a name="id2600737"></a><p>[<abbr class="abbrev">RFC1982</abbr>] <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 class="biblioentry">
-<a name="id2594987"></a><p>[<abbr class="abbrev">RFC4074</abbr>] <span class="authorgroup"><span class="firstname">Y.</span> <span class="surname">Morishita</span> and <span class="firstname">T.</span> <span class="surname">Jinmei</span>. </span><span class="title"><i>Common Misbehaviour Against <acronym class="acronym">DNS</acronym>
+<a name="id2600772"></a><p>[<abbr class="abbrev">RFC4074</abbr>] <span class="authorgroup"><span class="firstname">Y.</span> <span class="surname">Morishita</span> and <span class="firstname">T.</span> <span class="surname">Jinmei</span>. </span><span class="title"><i>Common Misbehaviour Against <acronym class="acronym">DNS</acronym>
                 Queries for IPv6 Addresses</i>. </span><span class="pubdate">May 2005. </span></p>
 </div>
 </div>
 <div class="bibliodiv">
 <h3 class="title">Resource Record Types</h3>
 <div class="biblioentry">
-<a name="id2595033"></a><p>[<abbr class="abbrev">RFC1183</abbr>] <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 <acronym class="acronym">DNS</acronym> RR Definitions</i>. </span><span class="pubdate">October 1990. </span></p>
+<a name="id2600818"></a><p>[<abbr class="abbrev">RFC1183</abbr>] <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 <acronym class="acronym">DNS</acronym> RR Definitions</i>. </span><span class="pubdate">October 1990. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595091"></a><p>[<abbr class="abbrev">RFC1706</abbr>] <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><acronym class="acronym">DNS</acronym> NSAP Resource Records</i>. </span><span class="pubdate">October 1994. </span></p>
+<a name="id2600875"></a><p>[<abbr class="abbrev">RFC1706</abbr>] <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><acronym class="acronym">DNS</acronym> NSAP Resource Records</i>. </span><span class="pubdate">October 1994. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595128"></a><p>[<abbr class="abbrev">RFC2168</abbr>] <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
+<a name="id2600913"></a><p>[<abbr class="abbrev">RFC2168</abbr>] <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">
-<a name="id2595163"></a><p>[<abbr class="abbrev">RFC1876</abbr>] <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
+<a name="id2600948"></a><p>[<abbr class="abbrev">RFC1876</abbr>] <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">
-<a name="id2595218"></a><p>[<abbr class="abbrev">RFC2052</abbr>] <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 <acronym class="acronym">DNS</acronym> RR for Specifying the
+<a name="id2601002"></a><p>[<abbr class="abbrev">RFC2052</abbr>] <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 <acronym class="acronym">DNS</acronym> RR for Specifying the
                   Location of
                   Services.</i>. </span><span class="pubdate">October 1996. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595256"></a><p>[<abbr class="abbrev">RFC2163</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Allocchio</span>. </span><span class="title"><i>Using the Internet <acronym class="acronym">DNS</acronym> to
+<a name="id2601041"></a><p>[<abbr class="abbrev">RFC2163</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Allocchio</span>. </span><span class="title"><i>Using the Internet <acronym class="acronym">DNS</acronym> to
                   Distribute MIXER
                   Conformant Global Address Mapping</i>. </span><span class="pubdate">January 1998. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595282"></a><p>[<abbr class="abbrev">RFC2230</abbr>] <span class="author"><span class="firstname">R.</span> <span class="surname">Atkinson</span>. </span><span class="title"><i>Key Exchange Delegation Record for the <acronym class="acronym">DNS</acronym></i>. </span><span class="pubdate">October 1997. </span></p>
+<a name="id2601066"></a><p>[<abbr class="abbrev">RFC2230</abbr>] <span class="author"><span class="firstname">R.</span> <span class="surname">Atkinson</span>. </span><span class="title"><i>Key Exchange Delegation Record for the <acronym class="acronym">DNS</acronym></i>. </span><span class="pubdate">October 1997. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595307"></a><p>[<abbr class="abbrev">RFC2536</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>DSA KEYs and SIGs in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
+<a name="id2601092"></a><p>[<abbr class="abbrev">RFC2536</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>DSA KEYs and SIGs in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595334"></a><p>[<abbr class="abbrev">RFC2537</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
+<a name="id2601118"></a><p>[<abbr class="abbrev">RFC2537</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595361"></a><p>[<abbr class="abbrev">RFC2538</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span> and <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Storing Certificates in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
+<a name="id2601145"></a><p>[<abbr class="abbrev">RFC2538</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span> and <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Storing Certificates in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595400"></a><p>[<abbr class="abbrev">RFC2539</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Storage of Diffie-Hellman Keys in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
+<a name="id2601185"></a><p>[<abbr class="abbrev">RFC2539</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Storage of Diffie-Hellman Keys in the Domain Name System (DNS)</i>. </span><span class="pubdate">March 1999. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595430"></a><p>[<abbr class="abbrev">RFC2540</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Detached Domain Name System (DNS) Information</i>. </span><span class="pubdate">March 1999. </span></p>
+<a name="id2601214"></a><p>[<abbr class="abbrev">RFC2540</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Detached Domain Name System (DNS) Information</i>. </span><span class="pubdate">March 1999. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595460"></a><p>[<abbr class="abbrev">RFC2782</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Gulbrandsen</span>. </span><span class="author"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="author"><span class="firstname">L.</span> <span class="surname">Esibov</span>. </span><span class="title"><i>A DNS RR for specifying the location of services (DNS SRV)</i>. </span><span class="pubdate">February 2000. </span></p>
+<a name="id2601244"></a><p>[<abbr class="abbrev">RFC2782</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Gulbrandsen</span>. </span><span class="author"><span class="firstname">P.</span> <span class="surname">Vixie</span>. </span><span class="author"><span class="firstname">L.</span> <span class="surname">Esibov</span>. </span><span class="title"><i>A DNS RR for specifying the location of services (DNS SRV)</i>. </span><span class="pubdate">February 2000. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595502"></a><p>[<abbr class="abbrev">RFC2915</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Mealling</span>. </span><span class="author"><span class="firstname">R.</span> <span class="surname">Daniel</span>. </span><span class="title"><i>The Naming Authority Pointer (NAPTR) DNS Resource Record</i>. </span><span class="pubdate">September 2000. </span></p>
+<a name="id2601287"></a><p>[<abbr class="abbrev">RFC2915</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Mealling</span>. </span><span class="author"><span class="firstname">R.</span> <span class="surname">Daniel</span>. </span><span class="title"><i>The Naming Authority Pointer (NAPTR) DNS Resource Record</i>. </span><span class="pubdate">September 2000. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595536"></a><p>[<abbr class="abbrev">RFC3110</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</i>. </span><span class="pubdate">May 2001. </span></p>
+<a name="id2601320"></a><p>[<abbr class="abbrev">RFC3110</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</i>. </span><span class="pubdate">May 2001. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595562"></a><p>[<abbr class="abbrev">RFC3123</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Koch</span>. </span><span class="title"><i>A DNS RR Type for Lists of Address Prefixes (APL RR)</i>. </span><span class="pubdate">June 2001. </span></p>
+<a name="id2601347"></a><p>[<abbr class="abbrev">RFC3123</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Koch</span>. </span><span class="title"><i>A DNS RR Type for Lists of Address Prefixes (APL RR)</i>. </span><span class="pubdate">June 2001. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595586"></a><p>[<abbr class="abbrev">RFC3596</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Thomson</span>, <span class="firstname">C.</span> <span class="surname">Huitema</span>, <span class="firstname">V.</span> <span class="surname">Ksinant</span>, and <span class="firstname">M.</span> <span class="surname">Souissi</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Extensions to support IP
+<a name="id2601370"></a><p>[<abbr class="abbrev">RFC3596</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Thomson</span>, <span class="firstname">C.</span> <span class="surname">Huitema</span>, <span class="firstname">V.</span> <span class="surname">Ksinant</span>, and <span class="firstname">M.</span> <span class="surname">Souissi</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Extensions to support IP
                   version 6</i>. </span><span class="pubdate">October 2003. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595643"></a><p>[<abbr class="abbrev">RFC3597</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Gustafsson</span>. </span><span class="title"><i>Handling of Unknown DNS Resource Record (RR) Types</i>. </span><span class="pubdate">September 2003. </span></p>
+<a name="id2601428"></a><p>[<abbr class="abbrev">RFC3597</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Gustafsson</span>. </span><span class="title"><i>Handling of Unknown DNS Resource Record (RR) Types</i>. </span><span class="pubdate">September 2003. </span></p>
 </div>
 </div>
 <div class="bibliodiv">
 <h3 class="title">
 <acronym class="acronym">DNS</acronym> and the Internet</h3>
 <div class="biblioentry">
-<a name="id2595675"></a><p>[<abbr class="abbrev">RFC1101</abbr>] <span class="author"><span class="firstname">P. V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Encoding of Network Names
+<a name="id2601460"></a><p>[<abbr class="abbrev">RFC1101</abbr>] <span class="author"><span class="firstname">P. V.</span> <span class="surname">Mockapetris</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Encoding of Network Names
                   and Other Types</i>. </span><span class="pubdate">April 1989. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595701"></a><p>[<abbr class="abbrev">RFC1123</abbr>] <span class="author"><span class="surname">Braden</span>. </span><span class="title"><i>Requirements for Internet Hosts - Application and
+<a name="id2601485"></a><p>[<abbr class="abbrev">RFC1123</abbr>] <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">
-<a name="id2595723"></a><p>[<abbr class="abbrev">RFC1591</abbr>] <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>
+<a name="id2601576"></a><p>[<abbr class="abbrev">RFC1591</abbr>] <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">
-<a name="id2595747"></a><p>[<abbr class="abbrev">RFC2317</abbr>] <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>
+<a name="id2601600"></a><p>[<abbr class="abbrev">RFC2317</abbr>] <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 class="biblioentry">
-<a name="id2595793"></a><p>[<abbr class="abbrev">RFC2826</abbr>] <span class="authorgroup"><span class="surname">Internet Architecture Board</span>. </span><span class="title"><i>IAB Technical Comment on the Unique DNS Root</i>. </span><span class="pubdate">May 2000. </span></p>
+<a name="id2601645"></a><p>[<abbr class="abbrev">RFC2826</abbr>] <span class="authorgroup"><span class="surname">Internet Architecture Board</span>. </span><span class="title"><i>IAB Technical Comment on the Unique DNS Root</i>. </span><span class="pubdate">May 2000. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595816"></a><p>[<abbr class="abbrev">RFC2929</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>, <span class="firstname">E.</span> <span class="surname">Brunner-Williams</span>, and <span class="firstname">B.</span> <span class="surname">Manning</span>. </span><span class="title"><i>Domain Name System (DNS) IANA Considerations</i>. </span><span class="pubdate">September 2000. </span></p>
+<a name="id2601669"></a><p>[<abbr class="abbrev">RFC2929</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>, <span class="firstname">E.</span> <span class="surname">Brunner-Williams</span>, and <span class="firstname">B.</span> <span class="surname">Manning</span>. </span><span class="title"><i>Domain Name System (DNS) IANA Considerations</i>. </span><span class="pubdate">September 2000. </span></p>
 </div>
 </div>
 <div class="bibliodiv">
 <h3 class="title">
 <acronym class="acronym">DNS</acronym> Operations</h3>
 <div class="biblioentry">
-<a name="id2595874"></a><p>[<abbr class="abbrev">RFC1033</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Lottor</span>. </span><span class="title"><i>Domain administrators operations guide.</i>. </span><span class="pubdate">November 1987. </span></p>
+<a name="id2601726"></a><p>[<abbr class="abbrev">RFC1033</abbr>] <span class="author"><span class="firstname">M.</span> <span class="surname">Lottor</span>. </span><span class="title"><i>Domain administrators operations guide.</i>. </span><span class="pubdate">November 1987. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595897"></a><p>[<abbr class="abbrev">RFC1537</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Beertema</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Data File
+<a name="id2601750"></a><p>[<abbr class="abbrev">RFC1537</abbr>] <span class="author"><span class="firstname">P.</span> <span class="surname">Beertema</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Data File
                   Configuration Errors</i>. </span><span class="pubdate">October 1993. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595924"></a><p>[<abbr class="abbrev">RFC1912</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Barr</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Operational and
+<a name="id2601777"></a><p>[<abbr class="abbrev">RFC1912</abbr>] <span class="author"><span class="firstname">D.</span> <span class="surname">Barr</span>. </span><span class="title"><i>Common <acronym class="acronym">DNS</acronym> Operational and
                   Configuration Errors</i>. </span><span class="pubdate">February 1996. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2595950"></a><p>[<abbr class="abbrev">RFC2010</abbr>] <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>
+<a name="id2601803"></a><p>[<abbr class="abbrev">RFC2010</abbr>] <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">
-<a name="id2595987"></a><p>[<abbr class="abbrev">RFC2219</abbr>] <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 <acronym class="acronym">DNS</acronym> Aliases for
+<a name="id2601840"></a><p>[<abbr class="abbrev">RFC2219</abbr>] <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 <acronym class="acronym">DNS</acronym> Aliases for
                   Network Services.</i>. </span><span class="pubdate">October 1997. </span></p>
 </div>
 </div>
 <div class="bibliodiv">
 <h3 class="title">Internationalized Domain Names</h3>
 <div class="biblioentry">
-<a name="id2596033"></a><p>[<abbr class="abbrev">RFC2825</abbr>] <span class="authorgroup"><span class="surname">IAB</span> and <span class="firstname">R.</span> <span class="surname">Daigle</span>. </span><span class="title"><i>A Tangled Web: Issues of I18N, Domain Names,
+<a name="id2601885"></a><p>[<abbr class="abbrev">RFC2825</abbr>] <span class="authorgroup"><span class="surname">IAB</span> and <span class="firstname">R.</span> <span class="surname">Daigle</span>. </span><span class="title"><i>A Tangled Web: Issues of I18N, Domain Names,
                        and the Other Internet protocols</i>. </span><span class="pubdate">May 2000. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596065"></a><p>[<abbr class="abbrev">RFC3490</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Faltstrom</span>, <span class="firstname">P.</span> <span class="surname">Hoffman</span>, and <span class="firstname">A.</span> <span class="surname">Costello</span>. </span><span class="title"><i>Internationalizing Domain Names in Applications (IDNA)</i>. </span><span class="pubdate">March 2003. </span></p>
+<a name="id2601917"></a><p>[<abbr class="abbrev">RFC3490</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Faltstrom</span>, <span class="firstname">P.</span> <span class="surname">Hoffman</span>, and <span class="firstname">A.</span> <span class="surname">Costello</span>. </span><span class="title"><i>Internationalizing Domain Names in Applications (IDNA)</i>. </span><span class="pubdate">March 2003. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596110"></a><p>[<abbr class="abbrev">RFC3491</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Hoffman</span> and <span class="firstname">M.</span> <span class="surname">Blanchet</span>. </span><span class="title"><i>Nameprep: A Stringprep Profile for Internationalized Domain Names</i>. </span><span class="pubdate">March 2003. </span></p>
+<a name="id2601963"></a><p>[<abbr class="abbrev">RFC3491</abbr>] <span class="authorgroup"><span class="firstname">P.</span> <span class="surname">Hoffman</span> and <span class="firstname">M.</span> <span class="surname">Blanchet</span>. </span><span class="title"><i>Nameprep: A Stringprep Profile for Internationalized Domain Names</i>. </span><span class="pubdate">March 2003. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596146"></a><p>[<abbr class="abbrev">RFC3492</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Costello</span>. </span><span class="title"><i>Punycode: A Bootstring encoding of Unicode
+<a name="id2601998"></a><p>[<abbr class="abbrev">RFC3492</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Costello</span>. </span><span class="title"><i>Punycode: A Bootstring encoding of Unicode
                        for Internationalized Domain Names in
                        Applications (IDNA)</i>. </span><span class="pubdate">March 2003. </span></p>
 </div>
@@ -489,47 +487,47 @@
                 </p>
 </div>
 <div class="biblioentry">
-<a name="id2596190"></a><p>[<abbr class="abbrev">RFC1464</abbr>] <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
+<a name="id2602043"></a><p>[<abbr class="abbrev">RFC1464</abbr>] <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">
-<a name="id2596213"></a><p>[<abbr class="abbrev">RFC1713</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Romao</span>. </span><span class="title"><i>Tools for <acronym class="acronym">DNS</acronym> Debugging</i>. </span><span class="pubdate">November 1994. </span></p>
+<a name="id2602066"></a><p>[<abbr class="abbrev">RFC1713</abbr>] <span class="author"><span class="firstname">A.</span> <span class="surname">Romao</span>. </span><span class="title"><i>Tools for <acronym class="acronym">DNS</acronym> Debugging</i>. </span><span class="pubdate">November 1994. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596238"></a><p>[<abbr class="abbrev">RFC1794</abbr>] <span class="author"><span class="firstname">T.</span> <span class="surname">Brisco</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Support for Load
+<a name="id2602091"></a><p>[<abbr class="abbrev">RFC1794</abbr>] <span class="author"><span class="firstname">T.</span> <span class="surname">Brisco</span>. </span><span class="title"><i><acronym class="acronym">DNS</acronym> Support for Load
                   Balancing</i>. </span><span class="pubdate">April 1995. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596332"></a><p>[<abbr class="abbrev">RFC2240</abbr>] <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>
+<a name="id2602117"></a><p>[<abbr class="abbrev">RFC2240</abbr>] <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">
-<a name="id2596356"></a><p>[<abbr class="abbrev">RFC2345</abbr>] <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>
+<a name="id2602140"></a><p>[<abbr class="abbrev">RFC2345</abbr>] <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">
-<a name="id2596402"></a><p>[<abbr class="abbrev">RFC2352</abbr>] <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>
+<a name="id2602186"></a><p>[<abbr class="abbrev">RFC2352</abbr>] <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 class="biblioentry">
-<a name="id2596425"></a><p>[<abbr class="abbrev">RFC3071</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Klensin</span>. </span><span class="title"><i>Reflections on the DNS, RFC 1591, and Categories of Domains</i>. </span><span class="pubdate">February 2001. </span></p>
+<a name="id2602210"></a><p>[<abbr class="abbrev">RFC3071</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Klensin</span>. </span><span class="title"><i>Reflections on the DNS, RFC 1591, and Categories of Domains</i>. </span><span class="pubdate">February 2001. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596452"></a><p>[<abbr class="abbrev">RFC3258</abbr>] <span class="authorgroup"><span class="firstname">T.</span> <span class="surname">Hardie</span>. </span><span class="title"><i>Distributing Authoritative Name Servers via
+<a name="id2602236"></a><p>[<abbr class="abbrev">RFC3258</abbr>] <span class="authorgroup"><span class="firstname">T.</span> <span class="surname">Hardie</span>. </span><span class="title"><i>Distributing Authoritative Name Servers via
                        Shared Unicast Addresses</i>. </span><span class="pubdate">April 2002. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596477"></a><p>[<abbr class="abbrev">RFC3901</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Durand</span> and <span class="firstname">J.</span> <span class="surname">Ihren</span>. </span><span class="title"><i>DNS IPv6 Transport Operational Guidelines</i>. </span><span class="pubdate">September 2004. </span></p>
+<a name="id2602262"></a><p>[<abbr class="abbrev">RFC3901</abbr>] <span class="authorgroup"><span class="firstname">A.</span> <span class="surname">Durand</span> and <span class="firstname">J.</span> <span class="surname">Ihren</span>. </span><span class="title"><i>DNS IPv6 Transport Operational Guidelines</i>. </span><span class="pubdate">September 2004. </span></p>
 </div>
 </div>
 <div class="bibliodiv">
 <h3 class="title">Obsolete and Unimplemented Experimental RFC</h3>
 <div class="biblioentry">
-<a name="id2596521"></a><p>[<abbr class="abbrev">RFC1712</abbr>] <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><acronym class="acronym">DNS</acronym> Encoding of Geographical
+<a name="id2602306"></a><p>[<abbr class="abbrev">RFC1712</abbr>] <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><acronym class="acronym">DNS</acronym> Encoding of Geographical
                   Location</i>. </span><span class="pubdate">November 1994. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596579"></a><p>[<abbr class="abbrev">RFC2673</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span>. </span><span class="title"><i>Binary Labels in the Domain Name System</i>. </span><span class="pubdate">August 1999. </span></p>
+<a name="id2602363"></a><p>[<abbr class="abbrev">RFC2673</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span>. </span><span class="title"><i>Binary Labels in the Domain Name System</i>. </span><span class="pubdate">August 1999. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596605"></a><p>[<abbr class="abbrev">RFC2874</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span> and <span class="firstname">C.</span> <span class="surname">Huitema</span>. </span><span class="title"><i>DNS Extensions to Support IPv6 Address Aggregation
+<a name="id2602390"></a><p>[<abbr class="abbrev">RFC2874</abbr>] <span class="authorgroup"><span class="firstname">M.</span> <span class="surname">Crawford</span> and <span class="firstname">C.</span> <span class="surname">Huitema</span>. </span><span class="title"><i>DNS Extensions to Support IPv6 Address Aggregation
                        and Renumbering</i>. </span><span class="pubdate">July 2000. </span></p>
 </div>
 </div>
@@ -543,39 +541,39 @@
                 </p>
 </div>
 <div class="biblioentry">
-<a name="id2596653"></a><p>[<abbr class="abbrev">RFC2065</abbr>] <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>
+<a name="id2602438"></a><p>[<abbr class="abbrev">RFC2065</abbr>] <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">
-<a name="id2596693"></a><p>[<abbr class="abbrev">RFC2137</abbr>] <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>
+<a name="id2602477"></a><p>[<abbr class="abbrev">RFC2137</abbr>] <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 class="biblioentry">
-<a name="id2596720"></a><p>[<abbr class="abbrev">RFC2535</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Domain Name System Security Extensions</i>. </span><span class="pubdate">March 1999. </span></p>
+<a name="id2602504"></a><p>[<abbr class="abbrev">RFC2535</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Eastlake</span>, <span class="lineage">3rd</span>. </span><span class="title"><i>Domain Name System Security Extensions</i>. </span><span class="pubdate">March 1999. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596818"></a><p>[<abbr class="abbrev">RFC3008</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Domain Name System Security (DNSSEC)
+<a name="id2602534"></a><p>[<abbr class="abbrev">RFC3008</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span>. </span><span class="title"><i>Domain Name System Security (DNSSEC)
                        Signing Authority</i>. </span><span class="pubdate">November 2000. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596843"></a><p>[<abbr class="abbrev">RFC3090</abbr>] <span class="authorgroup"><span class="firstname">E.</span> <span class="surname">Lewis</span>. </span><span class="title"><i>DNS Security Extension Clarification on Zone Status</i>. </span><span class="pubdate">March 2001. </span></p>
+<a name="id2602560"></a><p>[<abbr class="abbrev">RFC3090</abbr>] <span class="authorgroup"><span class="firstname">E.</span> <span class="surname">Lewis</span>. </span><span class="title"><i>DNS Security Extension Clarification on Zone Status</i>. </span><span class="pubdate">March 2001. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596870"></a><p>[<abbr class="abbrev">RFC3445</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Massey</span> and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Limiting the Scope of the KEY Resource Record (RR)</i>. </span><span class="pubdate">December 2002. </span></p>
+<a name="id2602586"></a><p>[<abbr class="abbrev">RFC3445</abbr>] <span class="authorgroup"><span class="firstname">D.</span> <span class="surname">Massey</span> and <span class="firstname">S.</span> <span class="surname">Rose</span>. </span><span class="title"><i>Limiting the Scope of the KEY Resource Record (RR)</i>. </span><span class="pubdate">December 2002. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596906"></a><p>[<abbr class="abbrev">RFC3655</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span> and <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Redefinition of DNS Authenticated Data (AD) bit</i>. </span><span class="pubdate">November 2003. </span></p>
+<a name="id2602691"></a><p>[<abbr class="abbrev">RFC3655</abbr>] <span class="authorgroup"><span class="firstname">B.</span> <span class="surname">Wellington</span> and <span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Redefinition of DNS Authenticated Data (AD) bit</i>. </span><span class="pubdate">November 2003. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596942"></a><p>[<abbr class="abbrev">RFC3658</abbr>] <span class="authorgroup"><span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Delegation Signer (DS) Resource Record (RR)</i>. </span><span class="pubdate">December 2003. </span></p>
+<a name="id2602727"></a><p>[<abbr class="abbrev">RFC3658</abbr>] <span class="authorgroup"><span class="firstname">O.</span> <span class="surname">Gudmundsson</span>. </span><span class="title"><i>Delegation Signer (DS) Resource Record (RR)</i>. </span><span class="pubdate">December 2003. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596969"></a><p>[<abbr class="abbrev">RFC3755</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Weiler</span>. </span><span class="title"><i>Legacy Resolver Compatibility for Delegation Signer (DS)</i>. </span><span class="pubdate">May 2004. </span></p>
+<a name="id2602754"></a><p>[<abbr class="abbrev">RFC3755</abbr>] <span class="authorgroup"><span class="firstname">S.</span> <span class="surname">Weiler</span>. </span><span class="title"><i>Legacy Resolver Compatibility for Delegation Signer (DS)</i>. </span><span class="pubdate">May 2004. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2596996"></a><p>[<abbr class="abbrev">RFC3757</abbr>] <span class="authorgroup"><span class="firstname">O.</span> <span class="surname">Kolkman</span>, <span class="firstname">J.</span> <span class="surname">Schlyter</span>, and <span class="firstname">E.</span> <span class="surname">Lewis</span>. </span><span class="title"><i>Domain Name System KEY (DNSKEY) Resource Record
+<a name="id2602780"></a><p>[<abbr class="abbrev">RFC3757</abbr>] <span class="authorgroup"><span class="firstname">O.</span> <span class="surname">Kolkman</span>, <span class="firstname">J.</span> <span class="surname">Schlyter</span>, and <span class="firstname">E.</span> <span class="surname">Lewis</span>. </span><span class="title"><i>Domain Name System KEY (DNSKEY) Resource Record
                       (RR) Secure Entry Point (SEP) Flag</i>. </span><span class="pubdate">April 2004. </span></p>
 </div>
 <div class="biblioentry">
-<a name="id2597041"></a><p>[<abbr class="abbrev">RFC3845</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Schlyter</span>. </span><span class="title"><i>DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format</i>. </span><span class="pubdate">August 2004. </span></p>
+<a name="id2602825"></a><p>[<abbr class="abbrev">RFC3845</abbr>] <span class="authorgroup"><span class="firstname">J.</span> <span class="surname">Schlyter</span>. </span><span class="title"><i>DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format</i>. </span><span class="pubdate">August 2004. </span></p>
 </div>
 </div>
 </div>
@@ -596,14 +594,14 @@
 </div>
 <div class="sect2" lang="en">
 <div class="titlepage"><div><div><h3 class="title">
-<a name="id2597082"></a>Other Documents About <acronym class="acronym">BIND</acronym>
+<a name="id2602867"></a>Other Documents About <acronym class="acronym">BIND</acronym>
 </h3></div></div></div>
 <p></p>
 <div class="bibliography">
 <div class="titlepage"><div><div><h4 class="title">
-<a name="id2597092"></a>Bibliography</h4></div></div></div>
+<a name="id2602876"></a>Bibliography</h4></div></div></div>
 <div class="biblioentry">
-<a name="id2597094"></a><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><acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym></i>. </span><span class="copyright">Copyright © 1998 Sebastopol, CA: O'Reilly and Associates. </span></p>
+<a name="id2602878"></a><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><acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym></i>. </span><span class="copyright">Copyright © 1998 Sebastopol, CA: O'Reilly and Associates. </span></p>
 </div>
 </div>
 </div>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.ch10.html b/contrib/bind9/doc/arm/Bv9ARM.ch10.html
index 892ab16..5fbeb3d 100644
--- a/contrib/bind9/doc/arm/Bv9ARM.ch10.html
+++ b/contrib/bind9/doc/arm/Bv9ARM.ch10.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.ch10.html,v 1.2.2.9 2008/05/24 01:31:12 tbox Exp $ -->
+<!-- $Id: Bv9ARM.ch10.html,v 1.11.14.1 2009/01/08 01:51:00 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -55,6 +55,12 @@
 <span class="refentrytitle"><a href="man.host.html">host</a></span><span class="refpurpose"> &#8212; DNS lookup utility</span>
 </dt>
 <dt>
+<span class="refentrytitle"><a href="man.dnssec-dsfromkey.html"><span class="application">dnssec-dsfromkey</span></a></span><span class="refpurpose"> &#8212; DNSSEC DS RR generation tool</span>
+</dt>
+<dt>
+<span class="refentrytitle"><a href="man.dnssec-keyfromlabel.html"><span class="application">dnssec-keyfromlabel</span></a></span><span class="refpurpose"> &#8212; DNSSEC key generation tool</span>
+</dt>
+<dt>
 <span class="refentrytitle"><a href="man.dnssec-keygen.html"><span class="application">dnssec-keygen</span></a></span><span class="refpurpose"> &#8212; DNSSEC key generation tool</span>
 </dt>
 <dt>
@@ -70,6 +76,9 @@
 <span class="refentrytitle"><a href="man.named.html"><span class="application">named</span></a></span><span class="refpurpose"> &#8212; Internet domain name server</span>
 </dt>
 <dt>
+<span class="refentrytitle"><a href="man.nsupdate.html"><span class="application">nsupdate</span></a></span><span class="refpurpose"> &#8212; Dynamic DNS update utility</span>
+</dt>
+<dt>
 <span class="refentrytitle"><a href="man.rndc.html"><span class="application">rndc</span></a></span><span class="refpurpose"> &#8212; name server control utility</span>
 </dt>
 <dt>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.html b/contrib/bind9/doc/arm/Bv9ARM.html
index 6de42bc..2349940 100644
--- a/contrib/bind9/doc/arm/Bv9ARM.html
+++ b/contrib/bind9/doc/arm/Bv9ARM.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: Bv9ARM.html,v 1.85.18.82 2008/10/18 01:29:59 tbox Exp $ -->
+<!-- $Id: Bv9ARM.html,v 1.193.14.5 2009/04/03 01:52:22 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -41,7 +41,7 @@
 <div>
 <div><h1 class="title">
 <a name="id2563174"></a>BIND 9 Administrator Reference Manual</h1></div>
-<div><p class="copyright">Copyright © 2004-2008 Internet Systems Consortium, Inc. ("ISC")</p></div>
+<div><p class="copyright">Copyright © 2004-2009 Internet Systems Consortium, Inc. ("ISC")</p></div>
 <div><p class="copyright">Copyright © 2000-2003 Internet Software Consortium.</p></div>
 </div>
 <hr>
@@ -51,39 +51,39 @@
 <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#id2563405">Scope of Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564385">Organization of This Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564524">Conventions Used in This Document</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564637">The Domain Name System (<acronym class="acronym">DNS</acronym>)</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2563409">Scope of Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564388">Organization of This Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564528">Conventions Used in This Document</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch01.html#id2564641">The Domain Name System (<acronym class="acronym">DNS</acronym>)</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564659">DNS Fundamentals</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564693">Domains and Domain Names</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564845">Zones</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567243">Authoritative Name Servers</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567416">Caching Name Servers</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567546">Name Servers in Multiple Roles</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564662">DNS Fundamentals</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2564696">Domains and Domain Names</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567170">Zones</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567246">Authoritative Name Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567419">Caching Name Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch01.html#id2567549">Name Servers in Multiple Roles</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="Bv9ARM.ch02.html">2. <acronym class="acronym">BIND</acronym> Resource Requirements</a></span></dt>
 <dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567580">Hardware requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567607">CPU Requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567620">Memory Requirements</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567851">Name Server Intensive Environment Issues</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567862">Supported Operating Systems</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567584">Hardware requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567610">CPU Requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567623">Memory Requirements</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567854">Name Server Intensive Environment Issues</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch02.html#id2567865">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#id2567894">A Caching-only Name Server</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567910">An Authoritative-only Name Server</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567897">A Caching-only Name Server</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2567913">An Authoritative-only Name Server</a></span></dt>
 </dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568001">Load Balancing</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568423">Name Server Operations</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568004">Load Balancing</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch03.html#id2568358">Name Server Operations</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568428">Tools for Use With the Name Server Daemon</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2570142">Signals</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2568363">Tools for Use With the Name Server Daemon</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch03.html#id2570071">Signals</a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="Bv9ARM.ch04.html">4. Advanced DNS Features</a></span></dt>
@@ -92,34 +92,34 @@
 <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#id2570600">Split DNS</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2570618">Example split DNS setup</a></span></dt></dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2564066">Split DNS</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2564084">Example split DNS setup</a></span></dt></dl></dd>
 <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#id2570985">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571127">Copying the Shared Secret to Both Machines</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571138">Informing the Servers of the Key's Existence</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571177">Instructing the Server to Use the Key</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571303">TSIG Key Based Access Control</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571416">Errors</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571141">Generate Shared Keys for Each Pair of Hosts</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571214">Copying the Shared Secret to Both Machines</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571225">Informing the Servers of the Key's Existence</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571268">Instructing the Server to Use the Key</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571325">TSIG Key Based Access Control</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571510">Errors</a></span></dt>
 </dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571430">TKEY</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571547">SIG(0)</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571524">TKEY</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571709">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#id2571684">Generating Keys</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571753">Signing the Zone</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571832">Configuring Servers</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571778">Generating Keys</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2571925">Signing the Zone</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572006">Configuring Servers</a></span></dt>
 </dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2571975">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch04.html#id2572220">IPv6 Support in <acronym class="acronym">BIND</acronym> 9</a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572173">Address Lookups Using AAAA Records</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572195">Address to Name Lookups Using Nibble Format</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572282">Address Lookups Using AAAA Records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch04.html#id2572304">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 <acronym class="acronym">BIND</acronym> 9 Lightweight Resolver</a></span></dt>
 <dd><dl>
-<dt><span class="sect1"><a href="Bv9ARM.ch05.html#id2572228">The Lightweight Resolver Library</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch05.html#id2572337">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. <acronym class="acronym">BIND</acronym> 9 Configuration Reference</a></span></dt>
@@ -127,83 +127,88 @@
 <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#id2573436">Comment Syntax</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2573716">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#id2574117"><span><strong class="command">acl</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574346"><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#id2574307"><span><strong class="command">controls</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574536"><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#id2574736"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574753"><span><strong class="command">include</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574965"><span><strong class="command">include</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574982"><span><strong class="command">include</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574776"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574800"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2574958"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575084"><span><strong class="command">logging</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575005"><span><strong class="command">key</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575029"><span><strong class="command">key</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575120"><span><strong class="command">logging</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2575245"><span><strong class="command">logging</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576435"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576508"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576572"><span><strong class="command">masters</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576616"><span><strong class="command">masters</strong></span> Statement Definition and
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577306"><span><strong class="command">lwres</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577448"><span><strong class="command">lwres</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577512"><span><strong class="command">masters</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577556"><span><strong class="command">masters</strong></span> Statement Definition and
           Usage</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2576631"><span><strong class="command">options</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2577571"><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#id2585614"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2585666"><span><strong class="command">trusted-keys</strong></span> Statement Definition
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#statschannels"><span><strong class="command">statistics-channels</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586754"><span><strong class="command">statistics-channels</strong></span> Statement Definition and
+            Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586908"><span><strong class="command">trusted-keys</strong></span> Statement Grammar</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2586960"><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#id2585748"><span><strong class="command">view</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2587042"><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#id2587332"><span><strong class="command">zone</strong></span> Statement Definition and Usage</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2588510"><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#id2589477">Zone File</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch06.html#id2591109">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#id2591500">Discussion of MX Records</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2593203">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#id2592188">Inverse Mapping in IPv4</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592384">Other Zone File Directives</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2592572"><acronym class="acronym">BIND</acronym> Master File Extension: the  <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2593886">Inverse Mapping in IPv4</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2594013">Other Zone File Directives</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch06.html#id2594270"><acronym class="acronym">BIND</acronym> Master File Extension: the  <span><strong class="command">$GENERATE</strong></span> Directive</a></span></dt>
 <dt><span class="sect2"><a href="Bv9ARM.ch06.html#zonefile_format">Additional File Formats</a></span></dt>
 </dl></dd>
+<dt><span class="sect1"><a href="Bv9ARM.ch06.html#statistics">BIND9 Statistics</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch06.html#statistics_counters">Statistics Counters</a></span></dt></dl></dd>
 </dl></dd>
 <dt><span class="chapter"><a href="Bv9ARM.ch07.html">7. <acronym class="acronym">BIND</acronym> 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#id2593181"><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span></a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch07.html#id2598893"><span><strong class="command">Chroot</strong></span> and <span><strong class="command">Setuid</strong></span></a></span></dt>
 <dd><dl>
-<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2593326">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
-<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2593386">Using the <span><strong class="command">setuid</strong></span> Function</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2598974">The <span><strong class="command">chroot</strong></span> Environment</a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch07.html#id2599034">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#id2593466">Common Problems</a></span></dt>
-<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2593472">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#id2593483">Incrementing and Changing the Serial Number</a></span></dt>
-<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2593500">Where Can I Get Help?</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2599251">Common Problems</a></span></dt>
+<dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch08.html#id2599324">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#id2599336">Incrementing and Changing the Serial Number</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch08.html#id2599353">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#id2593630">Acknowledgments</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2599415">Acknowledgments</a></span></dt>
 <dd><dl><dt><span class="sect2"><a href="Bv9ARM.ch09.html#historical_dns_information">A Brief History of the <acronym class="acronym">DNS</acronym> and <acronym class="acronym">BIND</acronym></a></span></dt></dl></dd>
-<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2593802">General <acronym class="acronym">DNS</acronym> Reference Information</a></span></dt>
+<dt><span class="sect1"><a href="Bv9ARM.ch09.html#id2599587">General <acronym class="acronym">DNS</acronym> 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#id2597082">Other Documents About <acronym class="acronym">BIND</acronym></a></span></dt>
+<dt><span class="sect2"><a href="Bv9ARM.ch09.html#id2602867">Other Documents About <acronym class="acronym">BIND</acronym></a></span></dt>
 </dl></dd>
 </dl></dd>
 <dt><span class="reference"><a href="Bv9ARM.ch10.html">I. Manual pages</a></span></dt>
@@ -215,6 +220,12 @@
 <span class="refentrytitle"><a href="man.host.html">host</a></span><span class="refpurpose"> &#8212; DNS lookup utility</span>
 </dt>
 <dt>
+<span class="refentrytitle"><a href="man.dnssec-dsfromkey.html"><span class="application">dnssec-dsfromkey</span></a></span><span class="refpurpose"> &#8212; DNSSEC DS RR generation tool</span>
+</dt>
+<dt>
+<span class="refentrytitle"><a href="man.dnssec-keyfromlabel.html"><span class="application">dnssec-keyfromlabel</span></a></span><span class="refpurpose"> &#8212; DNSSEC key generation tool</span>
+</dt>
+<dt>
 <span class="refentrytitle"><a href="man.dnssec-keygen.html"><span class="application">dnssec-keygen</span></a></span><span class="refpurpose"> &#8212; DNSSEC key generation tool</span>
 </dt>
 <dt>
@@ -230,6 +241,9 @@
 <span class="refentrytitle"><a href="man.named.html"><span class="application">named</span></a></span><span class="refpurpose"> &#8212; Internet domain name server</span>
 </dt>
 <dt>
+<span class="refentrytitle"><a href="man.nsupdate.html"><span class="application">nsupdate</span></a></span><span class="refpurpose"> &#8212; Dynamic DNS update utility</span>
+</dt>
+<dt>
 <span class="refentrytitle"><a href="man.rndc.html"><span class="application">rndc</span></a></span><span class="refpurpose"> &#8212; name server control utility</span>
 </dt>
 <dt>
diff --git a/contrib/bind9/doc/arm/Bv9ARM.pdf b/contrib/bind9/doc/arm/Bv9ARM.pdf
index 2963745..b56a05d 100644
--- a/contrib/bind9/doc/arm/Bv9ARM.pdf
+++ b/contrib/bind9/doc/arm/Bv9ARM.pdf
@@ -621,389 +621,455 @@ endobj
 << /S /GoTo /D (subsubsection.6.2.16.18) >>
 endobj
 420 0 obj
-(6.2.16.18 The Statistics File)
+(6.2.16.18 Additional Section Caching)
 endobj
 421 0 obj
-<< /S /GoTo /D (subsubsection.6.2.16.19) >>
+<< /S /GoTo /D (subsection.6.2.17) >>
 endobj
 424 0 obj
-(6.2.16.19 Additional Section Caching)
+(6.2.17 statistics-channels Statement Grammar)
 endobj
 425 0 obj
-<< /S /GoTo /D (subsection.6.2.17) >>
+<< /S /GoTo /D (subsection.6.2.18) >>
 endobj
 428 0 obj
-(6.2.17 server Statement Grammar)
+(6.2.18 statistics-channels Statement Definition and Usage)
 endobj
 429 0 obj
-<< /S /GoTo /D (subsection.6.2.18) >>
+<< /S /GoTo /D (subsection.6.2.19) >>
 endobj
 432 0 obj
-(6.2.18 server Statement Definition and Usage)
+(6.2.19 server Statement Grammar)
 endobj
 433 0 obj
-<< /S /GoTo /D (subsection.6.2.19) >>
+<< /S /GoTo /D (subsection.6.2.20) >>
 endobj
 436 0 obj
-(6.2.19 trusted-keys Statement Grammar)
+(6.2.20 server Statement Definition and Usage)
 endobj
 437 0 obj
-<< /S /GoTo /D (subsection.6.2.20) >>
+<< /S /GoTo /D (subsection.6.2.21) >>
 endobj
 440 0 obj
-(6.2.20 trusted-keys Statement Definition and Usage)
+(6.2.21 trusted-keys Statement Grammar)
 endobj
 441 0 obj
-<< /S /GoTo /D (subsection.6.2.21) >>
+<< /S /GoTo /D (subsection.6.2.22) >>
 endobj
 444 0 obj
-(6.2.21 view Statement Grammar)
+(6.2.22 trusted-keys Statement Definition and Usage)
 endobj
 445 0 obj
-<< /S /GoTo /D (subsection.6.2.22) >>
+<< /S /GoTo /D (subsection.6.2.23) >>
 endobj
 448 0 obj
-(6.2.22 view Statement Definition and Usage)
+(6.2.23 view Statement Grammar)
 endobj
 449 0 obj
-<< /S /GoTo /D (subsection.6.2.23) >>
+<< /S /GoTo /D (subsection.6.2.24) >>
 endobj
 452 0 obj
-(6.2.23 zone Statement Grammar)
+(6.2.24 view Statement Definition and Usage)
 endobj
 453 0 obj
-<< /S /GoTo /D (subsection.6.2.24) >>
+<< /S /GoTo /D (subsection.6.2.25) >>
 endobj
 456 0 obj
-(6.2.24 zone Statement Definition and Usage)
+(6.2.25 zone Statement Grammar)
 endobj
 457 0 obj
-<< /S /GoTo /D (subsubsection.6.2.24.1) >>
+<< /S /GoTo /D (subsection.6.2.26) >>
 endobj
 460 0 obj
-(6.2.24.1 Zone Types)
+(6.2.26 zone Statement Definition and Usage)
 endobj
 461 0 obj
-<< /S /GoTo /D (subsubsection.6.2.24.2) >>
+<< /S /GoTo /D (subsubsection.6.2.26.1) >>
 endobj
 464 0 obj
-(6.2.24.2 Class)
+(6.2.26.1 Zone Types)
 endobj
 465 0 obj
-<< /S /GoTo /D (subsubsection.6.2.24.3) >>
+<< /S /GoTo /D (subsubsection.6.2.26.2) >>
 endobj
 468 0 obj
-(6.2.24.3 Zone Options)
+(6.2.26.2 Class)
 endobj
 469 0 obj
-<< /S /GoTo /D (subsubsection.6.2.24.4) >>
+<< /S /GoTo /D (subsubsection.6.2.26.3) >>
 endobj
 472 0 obj
-(6.2.24.4 Dynamic Update Policies)
+(6.2.26.3 Zone Options)
 endobj
 473 0 obj
-<< /S /GoTo /D (section.6.3) >>
+<< /S /GoTo /D (subsubsection.6.2.26.4) >>
 endobj
 476 0 obj
-(6.3 Zone File)
+(6.2.26.4 Dynamic Update Policies)
 endobj
 477 0 obj
-<< /S /GoTo /D (subsection.6.3.1) >>
+<< /S /GoTo /D (section.6.3) >>
 endobj
 480 0 obj
-(6.3.1 Types of Resource Records and When to Use Them)
+(6.3 Zone File)
 endobj
 481 0 obj
-<< /S /GoTo /D (subsubsection.6.3.1.1) >>
+<< /S /GoTo /D (subsection.6.3.1) >>
 endobj
 484 0 obj
-(6.3.1.1 Resource Records)
+(6.3.1 Types of Resource Records and When to Use Them)
 endobj
 485 0 obj
-<< /S /GoTo /D (subsubsection.6.3.1.2) >>
+<< /S /GoTo /D (subsubsection.6.3.1.1) >>
 endobj
 488 0 obj
-(6.3.1.2 Textual expression of RRs)
+(6.3.1.1 Resource Records)
 endobj
 489 0 obj
-<< /S /GoTo /D (subsection.6.3.2) >>
+<< /S /GoTo /D (subsubsection.6.3.1.2) >>
 endobj
 492 0 obj
-(6.3.2 Discussion of MX Records)
+(6.3.1.2 Textual expression of RRs)
 endobj
 493 0 obj
-<< /S /GoTo /D (subsection.6.3.3) >>
+<< /S /GoTo /D (subsection.6.3.2) >>
 endobj
 496 0 obj
-(6.3.3 Setting TTLs)
+(6.3.2 Discussion of MX Records)
 endobj
 497 0 obj
-<< /S /GoTo /D (subsection.6.3.4) >>
+<< /S /GoTo /D (subsection.6.3.3) >>
 endobj
 500 0 obj
-(6.3.4 Inverse Mapping in IPv4)
+(6.3.3 Setting TTLs)
 endobj
 501 0 obj
-<< /S /GoTo /D (subsection.6.3.5) >>
+<< /S /GoTo /D (subsection.6.3.4) >>
 endobj
 504 0 obj
-(6.3.5 Other Zone File Directives)
+(6.3.4 Inverse Mapping in IPv4)
 endobj
 505 0 obj
-<< /S /GoTo /D (subsubsection.6.3.5.1) >>
+<< /S /GoTo /D (subsection.6.3.5) >>
 endobj
 508 0 obj
-(6.3.5.1 The \044ORIGIN Directive)
+(6.3.5 Other Zone File Directives)
 endobj
 509 0 obj
-<< /S /GoTo /D (subsubsection.6.3.5.2) >>
+<< /S /GoTo /D (subsubsection.6.3.5.1) >>
 endobj
 512 0 obj
-(6.3.5.2 The \044INCLUDE Directive)
+(6.3.5.1 The \044ORIGIN Directive)
 endobj
 513 0 obj
-<< /S /GoTo /D (subsubsection.6.3.5.3) >>
+<< /S /GoTo /D (subsubsection.6.3.5.2) >>
 endobj
 516 0 obj
-(6.3.5.3 The \044TTL Directive)
+(6.3.5.2 The \044INCLUDE Directive)
 endobj
 517 0 obj
-<< /S /GoTo /D (subsection.6.3.6) >>
+<< /S /GoTo /D (subsubsection.6.3.5.3) >>
 endobj
 520 0 obj
-(6.3.6 BIND Master File Extension: the \044GENERATE Directive)
+(6.3.5.3 The \044TTL Directive)
 endobj
 521 0 obj
-<< /S /GoTo /D (subsection.6.3.7) >>
+<< /S /GoTo /D (subsection.6.3.6) >>
 endobj
 524 0 obj
-(6.3.7 Additional File Formats)
+(6.3.6 BIND Master File Extension: the \044GENERATE Directive)
 endobj
 525 0 obj
-<< /S /GoTo /D (chapter.7) >>
+<< /S /GoTo /D (subsection.6.3.7) >>
 endobj
 528 0 obj
-(7 BIND 9 Security Considerations)
+(6.3.7 Additional File Formats)
 endobj
 529 0 obj
-<< /S /GoTo /D (section.7.1) >>
+<< /S /GoTo /D (section.6.4) >>
 endobj
 532 0 obj
-(7.1 Access Control Lists)
+(6.4 BIND9 Statistics)
 endobj
 533 0 obj
-<< /S /GoTo /D (section.7.2) >>
+<< /S /GoTo /D (subsubsection.6.4.0.1) >>
 endobj
 536 0 obj
-(7.2 Chroot and Setuid)
+(6.4.0.1 The Statistics File)
 endobj
 537 0 obj
-<< /S /GoTo /D (subsection.7.2.1) >>
+<< /S /GoTo /D (subsection.6.4.1) >>
 endobj
 540 0 obj
-(7.2.1 The chroot Environment)
+(6.4.1 Statistics Counters)
 endobj
 541 0 obj
-<< /S /GoTo /D (subsection.7.2.2) >>
+<< /S /GoTo /D (subsubsection.6.4.1.1) >>
 endobj
 544 0 obj
-(7.2.2 Using the setuid Function)
+(6.4.1.1 Name Server Statistics Counters)
 endobj
 545 0 obj
-<< /S /GoTo /D (section.7.3) >>
+<< /S /GoTo /D (subsubsection.6.4.1.2) >>
 endobj
 548 0 obj
-(7.3 Dynamic Update Security)
+(6.4.1.2 Zone Maintenance Statistics Counters)
 endobj
 549 0 obj
-<< /S /GoTo /D (chapter.8) >>
+<< /S /GoTo /D (subsubsection.6.4.1.3) >>
 endobj
 552 0 obj
-(8 Troubleshooting)
+(6.4.1.3 Resolver Statistics Counters)
 endobj
 553 0 obj
-<< /S /GoTo /D (section.8.1) >>
+<< /S /GoTo /D (subsubsection.6.4.1.4) >>
 endobj
 556 0 obj
-(8.1 Common Problems)
+(6.4.1.4 Compatibility with BIND 8 Counters)
 endobj
 557 0 obj
-<< /S /GoTo /D (subsection.8.1.1) >>
+<< /S /GoTo /D (chapter.7) >>
 endobj
 560 0 obj
-(8.1.1 It's not working; how can I figure out what's wrong?)
+(7 BIND 9 Security Considerations)
 endobj
 561 0 obj
-<< /S /GoTo /D (section.8.2) >>
+<< /S /GoTo /D (section.7.1) >>
 endobj
 564 0 obj
-(8.2 Incrementing and Changing the Serial Number)
+(7.1 Access Control Lists)
 endobj
 565 0 obj
-<< /S /GoTo /D (section.8.3) >>
+<< /S /GoTo /D (section.7.2) >>
 endobj
 568 0 obj
-(8.3 Where Can I Get Help?)
+(7.2 Chroot and Setuid)
 endobj
 569 0 obj
-<< /S /GoTo /D (appendix.A) >>
+<< /S /GoTo /D (subsection.7.2.1) >>
 endobj
 572 0 obj
-(A Appendices)
+(7.2.1 The chroot Environment)
 endobj
 573 0 obj
-<< /S /GoTo /D (section.A.1) >>
+<< /S /GoTo /D (subsection.7.2.2) >>
 endobj
 576 0 obj
-(A.1 Acknowledgments)
+(7.2.2 Using the setuid Function)
 endobj
 577 0 obj
-<< /S /GoTo /D (subsection.A.1.1) >>
+<< /S /GoTo /D (section.7.3) >>
 endobj
 580 0 obj
-(A.1.1 A Brief History of the DNS and BIND)
+(7.3 Dynamic Update Security)
 endobj
 581 0 obj
-<< /S /GoTo /D (section.A.2) >>
+<< /S /GoTo /D (chapter.8) >>
 endobj
 584 0 obj
-(A.2 General DNS Reference Information)
+(8 Troubleshooting)
 endobj
 585 0 obj
-<< /S /GoTo /D (subsection.A.2.1) >>
+<< /S /GoTo /D (section.8.1) >>
 endobj
 588 0 obj
-(A.2.1 IPv6 addresses \(AAAA\))
+(8.1 Common Problems)
 endobj
 589 0 obj
-<< /S /GoTo /D (section.A.3) >>
+<< /S /GoTo /D (subsection.8.1.1) >>
 endobj
 592 0 obj
-(A.3 Bibliography \(and Suggested Reading\))
+(8.1.1 It's not working; how can I figure out what's wrong?)
 endobj
 593 0 obj
-<< /S /GoTo /D (subsection.A.3.1) >>
+<< /S /GoTo /D (section.8.2) >>
 endobj
 596 0 obj
-(A.3.1 Request for Comments \(RFCs\))
+(8.2 Incrementing and Changing the Serial Number)
 endobj
 597 0 obj
-<< /S /GoTo /D (subsection.A.3.2) >>
+<< /S /GoTo /D (section.8.3) >>
 endobj
 600 0 obj
-(A.3.2 Internet Drafts)
+(8.3 Where Can I Get Help?)
 endobj
 601 0 obj
-<< /S /GoTo /D (subsection.A.3.3) >>
+<< /S /GoTo /D (appendix.A) >>
 endobj
 604 0 obj
-(A.3.3 Other Documents About BIND)
+(A Appendices)
 endobj
 605 0 obj
-<< /S /GoTo /D (appendix.B) >>
+<< /S /GoTo /D (section.A.1) >>
 endobj
 608 0 obj
-(B Manual pages)
+(A.1 Acknowledgments)
 endobj
 609 0 obj
-<< /S /GoTo /D (section.B.1) >>
+<< /S /GoTo /D (subsection.A.1.1) >>
 endobj
 612 0 obj
-(B.1 dig)
+(A.1.1 A Brief History of the DNS and BIND)
 endobj
 613 0 obj
-<< /S /GoTo /D (section.B.2) >>
+<< /S /GoTo /D (section.A.2) >>
 endobj
 616 0 obj
-(B.2 host)
+(A.2 General DNS Reference Information)
 endobj
 617 0 obj
-<< /S /GoTo /D (section.B.3) >>
+<< /S /GoTo /D (subsection.A.2.1) >>
 endobj
 620 0 obj
-(B.3 dnssec-keygen)
+(A.2.1 IPv6 addresses \(AAAA\))
 endobj
 621 0 obj
-<< /S /GoTo /D (section.B.4) >>
+<< /S /GoTo /D (section.A.3) >>
 endobj
 624 0 obj
-(B.4 dnssec-signzone)
+(A.3 Bibliography \(and Suggested Reading\))
 endobj
 625 0 obj
-<< /S /GoTo /D (section.B.5) >>
+<< /S /GoTo /D (subsection.A.3.1) >>
 endobj
 628 0 obj
-(B.5 named-checkconf)
+(A.3.1 Request for Comments \(RFCs\))
 endobj
 629 0 obj
-<< /S /GoTo /D (section.B.6) >>
+<< /S /GoTo /D (subsection.A.3.2) >>
 endobj
 632 0 obj
-(B.6 named-checkzone)
+(A.3.2 Internet Drafts)
 endobj
 633 0 obj
-<< /S /GoTo /D (section.B.7) >>
+<< /S /GoTo /D (subsection.A.3.3) >>
 endobj
 636 0 obj
-(B.7 named)
+(A.3.3 Other Documents About BIND)
 endobj
 637 0 obj
-<< /S /GoTo /D (section.B.8) >>
+<< /S /GoTo /D (appendix.B) >>
 endobj
 640 0 obj
-(B.8 rndc)
+(B Manual pages)
 endobj
 641 0 obj
-<< /S /GoTo /D (section.B.9) >>
+<< /S /GoTo /D (section.B.1) >>
 endobj
 644 0 obj
-(B.9 rndc.conf)
+(B.1 dig)
 endobj
 645 0 obj
-<< /S /GoTo /D (section.B.10) >>
+<< /S /GoTo /D (section.B.2) >>
 endobj
 648 0 obj
-(B.10 rndc-confgen)
+(B.2 host)
 endobj
 649 0 obj
-<< /S /GoTo /D [650 0 R  /FitH ] >>
+<< /S /GoTo /D (section.B.3) >>
+endobj
+652 0 obj
+(B.3 dnssec-dsfromkey)
+endobj
+653 0 obj
+<< /S /GoTo /D (section.B.4) >>
+endobj
+656 0 obj
+(B.4 dnssec-keyfromlabel)
+endobj
+657 0 obj
+<< /S /GoTo /D (section.B.5) >>
+endobj
+660 0 obj
+(B.5 dnssec-keygen)
+endobj
+661 0 obj
+<< /S /GoTo /D (section.B.6) >>
+endobj
+664 0 obj
+(B.6 dnssec-signzone)
+endobj
+665 0 obj
+<< /S /GoTo /D (section.B.7) >>
+endobj
+668 0 obj
+(B.7 named-checkconf)
+endobj
+669 0 obj
+<< /S /GoTo /D (section.B.8) >>
+endobj
+672 0 obj
+(B.8 named-checkzone)
+endobj
+673 0 obj
+<< /S /GoTo /D (section.B.9) >>
+endobj
+676 0 obj
+(B.9 named)
 endobj
-653 0 obj <<
+677 0 obj
+<< /S /GoTo /D (section.B.10) >>
+endobj
+680 0 obj
+(B.10 nsupdate)
+endobj
+681 0 obj
+<< /S /GoTo /D (section.B.11) >>
+endobj
+684 0 obj
+(B.11 rndc)
+endobj
+685 0 obj
+<< /S /GoTo /D (section.B.12) >>
+endobj
+688 0 obj
+(B.12 rndc.conf)
+endobj
+689 0 obj
+<< /S /GoTo /D (section.B.13) >>
+endobj
+692 0 obj
+(B.13 rndc-confgen)
+endobj
+693 0 obj
+<< /S /GoTo /D [694 0 R  /FitH ] >>
+endobj
+697 0 obj <<
 /Length 236       
 /Filter /FlateDecode
 >>
 stream
 xÚ��ÁJA†ïó9¶‡M'™d2s´T¥‚Beoâai·Rp·t­ïïÔÕ*êArÉÿ‘ü	�/A�}È–ՓºsžŠvíèƒ
¨B)þP+!ÃlQ¡bJÕÂwìNì1úÈP©)&>áóÚÍ®˜€-A½bEM¦pæêÍÃd¾¼[L+V?ÉcºØt»~÷ršã~[÷í¶Ú~ÝNë a¤(±ø˘’å÷9·MÿÚ<Ÿ
 endobj
-650 0 obj <<
+694 0 obj <<
 /Type /Page
-/Contents 653 0 R
-/Resources 652 0 R
+/Contents 697 0 R
+/Resources 696 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 659 0 R
+/Parent 703 0 R
 >> endobj
-651 0 obj <<
+695 0 obj <<
 /Type /XObject
 /Subtype /Form
 /FormType 1
 /PTEX.FileName (./isc-logo.pdf)
 /PTEX.PageNumber 1
-/PTEX.InfoDict 660 0 R 
+/PTEX.InfoDict 704 0 R 
 /Matrix [1.00000000 0.00000000 0.00000000 1.00000000 0.00000000 0.00000000]
 /BBox [0.00000000 0.00000000 255.00000000 149.00000000]
 /Resources <<
 /ProcSet [ /PDF /Text ]
 /ColorSpace <<
-/R15 661 0 R
-/R9 662 0 R
-/R11 663 0 R
-/R13 664 0 R
+/R15 705 0 R
+/R9 706 0 R
+/R11 707 0 R
+/R13 708 0 R
 >>/ExtGState <<
-/R17 665 0 R
-/R8 666 0 R
->>/Font << /R19 667 0 R >>
+/R17 709 0 R
+/R8 710 0 R
+>>/Font << /R19 711 0 R >>
 >>
-/Length 668 0 R
+/Length 712 0 R
 /Filter /FlateDecode
 >>
 stream
@@ -1019,7 +1085,7 @@ xœu˜;“d9…ýû+®Ùe´�R©—�
lG`XËkz#†10gwÙ~6ßÉ[53}+ˆ}tI%åóäÉT½ßs*{Ö?·¿××í'¿�ûŸ?
 FÑÞIca­Ç0Ú)	¹A¿+�ÇÀº
�¸|-Tuùa>‚s:½¯•~K
“ÒÞV�׋„OÒAŠI…
�ɪÁr2Q“°Ø¨Á>.z
 ÏÆ狼eÇNdæÌdï"gK2cëÉ—GoOá8GëÏϦ:B
Àht[
 endobj
-660 0 obj
+704 0 obj
 <<
 /Producer (AFPL Ghostscript 8.51)
 /CreationDate (D:20050606145621)
@@ -1029,46 +1095,46 @@ endobj
 /Author (Douglas E. Appelt)
 >>
 endobj
-661 0 obj
-[/Separation/PANTONE#201805#20C/DeviceCMYK 669 0 R]
+705 0 obj
+[/Separation/PANTONE#201805#20C/DeviceCMYK 713 0 R]
 endobj
-662 0 obj
-[/Separation/PANTONE#207506#20C/DeviceCMYK 670 0 R]
+706 0 obj
+[/Separation/PANTONE#207506#20C/DeviceCMYK 714 0 R]
 endobj
-663 0 obj
-[/Separation/PANTONE#20301#20C/DeviceCMYK 671 0 R]
+707 0 obj
+[/Separation/PANTONE#20301#20C/DeviceCMYK 715 0 R]
 endobj
-664 0 obj
-[/Separation/PANTONE#20871#20C/DeviceCMYK 672 0 R]
+708 0 obj
+[/Separation/PANTONE#20871#20C/DeviceCMYK 716 0 R]
 endobj
-665 0 obj
+709 0 obj
 <<
 /Type /ExtGState
 /SA true
 >>
 endobj
-666 0 obj
+710 0 obj
 <<
 /Type /ExtGState
 /OPM 1
 >>
 endobj
-667 0 obj
+711 0 obj
 <<
 /BaseFont /NVXWCK#2BTrajanPro-Bold
-/FontDescriptor 673 0 R
+/FontDescriptor 717 0 R
 /Type /Font
 /FirstChar 67
 /LastChar 136
 /Widths [ 800 0 0 0 0 0 452 0 0 0 0 0 0 0 0 0 582 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 841 633 576 686 590 540 923 827 407 760]
-/Encoding 674 0 R
+/Encoding 718 0 R
 /Subtype /Type1
 >>
 endobj
-668 0 obj
+712 0 obj
 2362
 endobj
-669 0 obj
+713 0 obj
 <<
 /Filter /FlateDecode
 /FunctionType 4
@@ -1079,7 +1145,7 @@ endobj
 stream
 xœ«N)-P0PÈ-ÍQH­HÎP
 endobj
-670 0 obj
+714 0 obj
 <<
 /Filter /FlateDecode
 /FunctionType 4
@@ -1090,7 +1156,7 @@ endobj
 stream
 xœ«N)-P0PÈ-ÍQH­HÎP
 endobj
-671 0 obj
+715 0 obj
 <<
 /Filter /FlateDecode
 /FunctionType 4
@@ -1101,7 +1167,7 @@ endobj
 stream
 xœ«N)-P0TÈ-ÍQH­HÎP
 endobj
-672 0 obj
+716 0 obj
 <<
 /Filter /FlateDecode
 /FunctionType 4
@@ -1112,7 +1178,7 @@ endobj
 stream
 xœ«N)-P0Ð365³TÈ-ÍQH­HÎP€Š™X ‹™›#Äô-,ŒÀüZ
 endobj
-673 0 obj
+717 0 obj
 <<
 /Type /FontDescriptor
 /FontName /NVXWCK#2BTrajanPro-Bold
@@ -1125,17 +1191,17 @@ endobj
 /StemV 138
 /MissingWidth 500
 /CharSet (/Msmall/C/Ysmall/Nsmall/Osmall/Esmall/Rsmall/S/Ssmall/I/Tsmall/Ismall/Usmall)
-/FontFile3 675 0 R
+/FontFile3 719 0 R
 >>
 endobj
-674 0 obj
+718 0 obj
 <<
 /Type /Encoding
 /BaseEncoding /WinAnsiEncoding
 /Differences [ 127/Nsmall/Tsmall/Esmall/Rsmall/Ysmall/Ssmall/Msmall/Osmall/Ismall/Usmall]
 >>
 endobj
-675 0 obj
+719 0 obj
 <<
 /Filter /FlateDecode
 /Subtype /Type1C
@@ -1158,18 +1224,18 @@ x¸
\3§gA34–ITž-‹R8õ-ǵÛö2ªWuÉ~Á!"(0Š*FÂ͢ùĨ¸SˆˆoÊQPˆ0¦šåiFäݸVN^_!Ô‚–b
 ȼLçÇ<;—*X³«¥×ÛGâ_Y1ET�ïƒ4ˆ
Ò-U…_>´üØ¢�æ}õï÷v¼
§ádù�#¹rÛŸå¥@ÔÁ\5l…hð<8Ús·
 »O·Øèv61Bá5*È<6ÞÍ,‡bh‘˜¶ž\Î]Çé#¹#ØÔÍ1Oúñ°Ï¤5oÂ]цÆß4}h˜î0$å,6ü¼”A,¯?/å;Rôcy6Ò½UJ¿§Y½X^é¶�ÙÉŸ‡‹º–�2¸K|o½Ø”/�Ȩ�/ƒ(Â2Ð#žNMKðrˆ
rœÛf9ËyZ¸Ú}$«Ö	õ–©) h`iÎGàAç÷´€H+Šˆ…Õ&*áX$žèìVŽhª”—›¾÷‡A1Ý£¤œÏ0‰÷—Hi éƒw~I(Áö2;à]¸L ™x4[¡OÜ,¾®ÆûÂQQ°”FdQ“ƒ¢�¬„%\î¢Åâ:Ó;ÈÑ”ÌEb1ž�’�¡ˆÿ§=$¸¥?Iš¿CÐõ�3¾C=VÐ'>·¯ôÌÒ+Ü~8	ç#;úÁ_£×á*qň+ô	8®‚ãÆpêŒ_YR”¾d%a	ç¡H\eÄõãDf£Ñ¨­ŽR[�kφG¸ù/WT®ò•A5”H¥ÛVoo8h�nû)¼ÞÃDn…ñ�ëqÌzfåhý&þcQbµXÇß‚çLŽúõ;{²Ðñðué¿ÊÛÙ†-©[SÄ-Û¼ÔyubÜ�ñhüm´œ4^Ë™ ääšLÿQ‹¡endstream
 endobj
-654 0 obj <<
-/D [650 0 R /XYZ 85.0394 794.5015 null]
+698 0 obj <<
+/D [694 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-655 0 obj <<
-/D [650 0 R /XYZ 85.0394 769.5949 null]
+699 0 obj <<
+/D [694 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-652 0 obj <<
-/Font << /F21 658 0 R >>
-/XObject << /Im1 651 0 R >>
+696 0 obj <<
+/Font << /F21 702 0 R >>
+/XObject << /Im1 695 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-678 0 obj <<
+722 0 obj <<
 /Length 999       
 /Filter /FlateDecode
 >>
@@ -1181,21 +1247,21 @@ xÚµV]“¢:}÷Wð¨UC6|å‘AT¶\À�ÚÚÝGq†ªQ¼‚;5ÿþ6$Qï¼lÝò!�ô±ûôI'„h~D3-dqÊ5›ÈÄÄÔÖ»

 CfIÜ(|é|
 ²™°ê&cq$á¢e¤_RÖ¨h6Sï��¼p9¢éUò`¾UË=&ñDŒs?ñfàÙÆÐ} ûÑÚ°³7[±#-»I�E~š"ÅAŒ‘äë÷!ž <ë)½%õ0pCiOâDe•éÓ…ïnø 4N|¯å¨nÛèf	B´
@029ç}=½8JýoK AeLwîNÏr\çïyŸfn“(Kc¨-Q˜.Ãvõ¬þ$‰ç²¶8ítnXa÷âÕ/S_•'·{ÐçM	b§Š‡�œôewÕèeAõwÊη'SäOÃ`êGžßÏ·‘ÛËÂ@Ô!¤¿å¢!“³¡àx™^攑Ý$HÏZÄˬO%¾¢
Ô"ÿ‚rw4Îgêmmsøá�Ðqá'Ð<s·«gòÙ©¹ù’¨73Qó4ºûSùþú¦«lºa#æ8ôþ—ˆ:ðŲٙTû]½!}N™Eï0ÿýžf�endstream
 endobj
-677 0 obj <<
+721 0 obj <<
 /Type /Page
-/Contents 678 0 R
-/Resources 676 0 R
+/Contents 722 0 R
+/Resources 720 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 659 0 R
+/Parent 703 0 R
 >> endobj
-679 0 obj <<
-/D [677 0 R /XYZ 56.6929 794.5015 null]
+723 0 obj <<
+/D [721 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-676 0 obj <<
-/Font << /F23 682 0 R /F14 685 0 R >>
+720 0 obj <<
+/Font << /F23 726 0 R /F14 729 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-688 0 obj <<
+732 0 obj <<
 /Length 2891      
 /Filter /FlateDecode
 >>
@@ -1213,1498 +1279,1594 @@ W±ïëå*¯úoÞæ®x­]Δܫ�!$j2È�¢
 2¤PÁjÉñ&ÔX*¤÷€ŠoL–BE]*w·Ë—Š©=ÔB¿åp2LfRŒa™)Æ"qPŒ‘Þ‡¹LpæÒ—
da.;ûÞ¯3×þ¬h6wm‰¤öHßd8�!–‡‚#é ‘¥Ls
u4G]^œ¿9ž»7Vb_mS$H1•3lHp¶%µ?ô�ÅApF{ƒ�H-S\
 øƒÿÝÙ/ËuS”탙‰0ß™æ�•Éš#CJsœuJóH”æ¤÷AsiX
 M…­æ:h¾nêãô¨ý�èá·oðÐkƒ
h—#öùlk…lMf
R,`5("qP,�Þ„b‰Ð
ø˜Ž~]í»=Ãמ,Åzž%húg°º
-ÁîGÓäm2ƒÅR…Bb7ŠÊõ
-RDaYåxÏN,Š)Ò;ì]¥3"�ÃÂÖÕ�gk›uÔaëê«m‘‚S)CvdXg‚±Hb¤k ,I˜†–D·œ…Ó™ó7íÉï�å4ψ}µ

™J²#HÃz¤E‚ þåzø”¦¤ð ¥Ð¯òîââìÔ-töã)˜o•OþT¦3)$¬´ÄßxÁPáïþÌeÆÒØ'�·ªïAœ+·üR#M.ŠgÎ×3ÿ¦þ�çñç/àJàí”s®Aendstream
+ÁîGÓäm2ƒÅREŽ7XD‚ ˆ \@pÁ,tûµDÀ'/œÕ½ÊýØø@Á_™'Hûd �!E–•B*Åéö®ÒŒ‘@�aaëêdz¿µÍ:ê°uõÕ¶HA‰©”!;2¬3ÁX$1Ò5–$LCK¢[ÎÂéÌù›ödŽ÷ÇršgľڀŠL%
Ù¤a½	Ò"AP‡…r=|Ê?SRxÐRèWywqqvê:ûñÌ7ƒÊ'*Sƒ�VZâï<Ž`¨ðwæ2ciìÈÛ
Õ÷ Ε[~©‘&Å3ç�ë™SÿÀóøóp%ðö?ž­®Bendstream
 endobj
-687 0 obj <<
+731 0 obj <<
 /Type /Page
-/Contents 688 0 R
-/Resources 686 0 R
+/Contents 732 0 R
+/Resources 730 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 659 0 R
-/Annots [ 691 0 R 692 0 R 693 0 R 694 0 R 695 0 R 696 0 R 697 0 R 698 0 R 699 0 R 700 0 R 701 0 R 702 0 R 703 0 R 704 0 R 705 0 R 706 0 R 707 0 R 708 0 R 709 0 R 710 0 R 711 0 R 712 0 R 713 0 R 714 0 R 715 0 R 716 0 R 717 0 R 718 0 R 719 0 R 720 0 R 721 0 R 722 0 R 723 0 R 724 0 R 725 0 R 726 0 R 727 0 R 728 0 R 729 0 R 730 0 R 731 0 R 732 0 R 733 0 R 734 0 R 735 0 R 736 0 R 737 0 R 738 0 R 739 0 R 740 0 R ]
+/Parent 703 0 R
+/Annots [ 735 0 R 736 0 R 737 0 R 738 0 R 739 0 R 740 0 R 741 0 R 742 0 R 743 0 R 744 0 R 745 0 R 746 0 R 747 0 R 748 0 R 749 0 R 750 0 R 751 0 R 752 0 R 753 0 R 754 0 R 755 0 R 756 0 R 757 0 R 758 0 R 759 0 R 760 0 R 761 0 R 762 0 R 763 0 R 764 0 R 765 0 R 766 0 R 767 0 R 768 0 R 769 0 R 770 0 R 771 0 R 772 0 R 773 0 R 774 0 R 775 0 R 776 0 R 777 0 R 778 0 R 779 0 R 780 0 R 781 0 R 782 0 R 783 0 R 784 0 R ]
 >> endobj
-691 0 obj <<
+735 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 688.709 539.579 697.2967]
 /Subtype /Link
 /A << /S /GoTo /D (chapter.1) >>
 >> endobj
-692 0 obj <<
+736 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 676.5858 539.579 685.4425]
 /Subtype /Link
 /A << /S /GoTo /D (section.1.1) >>
 >> endobj
-693 0 obj <<
+737 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 664.4876 539.579 673.3442]
 /Subtype /Link
 /A << /S /GoTo /D (section.1.2) >>
 >> endobj
-694 0 obj <<
+738 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 652.3894 539.579 661.246]
 /Subtype /Link
 /A << /S /GoTo /D (section.1.3) >>
 >> endobj
-695 0 obj <<
+739 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 640.1914 539.579 649.1477]
 /Subtype /Link
 /A << /S /GoTo /D (section.1.4) >>
 >> endobj
-696 0 obj <<
+740 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 628.0932 539.579 637.0495]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.1.4.1) >>
 >> endobj
-697 0 obj <<
+741 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 615.995 539.579 624.9512]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.1.4.2) >>
 >> endobj
-698 0 obj <<
+742 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 603.8967 539.579 612.853]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.1.4.3) >>
 >> endobj
-699 0 obj <<
+743 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 591.7985 539.579 600.7547]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.1.4.4) >>
 >> endobj
-700 0 obj <<
+744 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 579.7002 539.579 588.6565]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.1.4.4.1) >>
 >> endobj
-701 0 obj <<
+745 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 567.6019 539.579 576.5582]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.1.4.4.2) >>
 >> endobj
-702 0 obj <<
+746 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [532.6051 555.5037 539.579 564.46]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.1.4.4.3) >>
 >> endobj
-703 0 obj <<
+747 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 543.4055 539.579 552.5112]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.1.4.5) >>
 >> endobj
-704 0 obj <<
+748 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 531.3072 539.579 540.413]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.1.4.5.1) >>
 >> endobj
-705 0 obj <<
+749 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 519.209 539.579 528.3147]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.1.4.6) >>
 >> endobj
-706 0 obj <<
+750 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 496.7003 539.579 505.4125]
 /Subtype /Link
 /A << /S /GoTo /D (chapter.2) >>
 >> endobj
-707 0 obj <<
+751 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 484.5772 539.579 493.5832]
 /Subtype /Link
 /A << /S /GoTo /D (section.2.1) >>
 >> endobj
-708 0 obj <<
+752 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 472.4789 539.579 481.485]
 /Subtype /Link
 /A << /S /GoTo /D (section.2.2) >>
 >> endobj
-709 0 obj <<
+753 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 460.3806 539.579 469.3867]
 /Subtype /Link
 /A << /S /GoTo /D (section.2.3) >>
 >> endobj
-710 0 obj <<
+754 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 448.2824 539.579 457.2885]
 /Subtype /Link
 /A << /S /GoTo /D (section.2.4) >>
 >> endobj
-711 0 obj <<
+755 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 436.1841 539.579 445.1902]
 /Subtype /Link
 /A << /S /GoTo /D (section.2.5) >>
 >> endobj
-712 0 obj <<
+756 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 413.4314 539.579 422.288]
 /Subtype /Link
 /A << /S /GoTo /D (chapter.3) >>
 >> endobj
-713 0 obj <<
+757 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 401.353 539.579 410.4588]
 /Subtype /Link
 /A << /S /GoTo /D (section.3.1) >>
 >> endobj
-714 0 obj <<
+758 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 389.2548 539.579 398.3605]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.3.1.1) >>
 >> endobj
-715 0 obj <<
+759 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 377.1565 539.579 386.2623]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.3.1.2) >>
 >> endobj
-716 0 obj <<
+760 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 365.1579 539.579 374.164]
 /Subtype /Link
 /A << /S /GoTo /D (section.3.2) >>
 >> endobj
-717 0 obj <<
+761 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 353.0597 539.579 362.0658]
 /Subtype /Link
 /A << /S /GoTo /D (section.3.3) >>
 >> endobj
-718 0 obj <<
+762 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 340.9614 539.579 349.9675]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.3.3.1) >>
 >> endobj
-719 0 obj <<
+763 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 328.7635 539.579 337.8693]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.3.3.1.1) >>
 >> endobj
-720 0 obj <<
+764 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 316.6653 539.579 325.771]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.3.3.1.2) >>
 >> endobj
-721 0 obj <<
+765 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 304.567 539.579 313.6728]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.3.3.2) >>
 >> endobj
-722 0 obj <<
+766 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 281.9139 539.579 290.7706]
 /Subtype /Link
 /A << /S /GoTo /D (chapter.4) >>
 >> endobj
-723 0 obj <<
+767 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 269.8356 539.579 278.9413]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.1) >>
 >> endobj
-724 0 obj <<
+768 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 257.7373 539.579 266.8431]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.2) >>
 >> endobj
-725 0 obj <<
+769 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 245.6391 539.579 254.7448]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.2.1) >>
 >> endobj
-726 0 obj <<
+770 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 233.5408 539.579 242.4971]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.3) >>
 >> endobj
-727 0 obj <<
+771 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 221.4426 539.579 230.3988]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.4) >>
 >> endobj
-728 0 obj <<
+772 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 209.3443 539.579 218.3006]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.4.1) >>
 >> endobj
-729 0 obj <<
+773 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 197.2461 539.579 206.2023]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.5) >>
 >> endobj
-730 0 obj <<
+774 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 185.1478 539.579 194.1041]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.5.1) >>
 >> endobj
-731 0 obj <<
+775 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 173.0496 539.579 182.0058]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.4.5.1.1) >>
 >> endobj
-732 0 obj <<
+776 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 161.051 539.579 170.0571]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.4.5.1.2) >>
 >> endobj
-733 0 obj <<
+777 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 148.9527 539.579 157.9588]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.5.2) >>
 >> endobj
-734 0 obj <<
+778 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 136.8545 539.579 145.8606]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.5.3) >>
 >> endobj
-735 0 obj <<
+779 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 124.7562 539.579 133.7623]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.5.4) >>
 >> endobj
-736 0 obj <<
+780 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 112.658 539.579 121.6641]
+/Rect [527.6238 112.5583 539.579 121.5146]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.5.5) >>
 >> endobj
-737 0 obj <<
+781 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 100.4601 539.579 109.4163]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.5.6) >>
 >> endobj
-738 0 obj <<
+782 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 88.3618 539.579 97.3181]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.6) >>
 >> endobj
-739 0 obj <<
+783 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 76.2636 539.579 85.2199]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.7) >>
 >> endobj
-740 0 obj <<
+784 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 64.1653 539.579 73.1216]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.8) >>
 >> endobj
-689 0 obj <<
-/D [687 0 R /XYZ 85.0394 794.5015 null]
+733 0 obj <<
+/D [731 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-690 0 obj <<
-/D [687 0 R /XYZ 85.0394 711.9273 null]
+734 0 obj <<
+/D [731 0 R /XYZ 85.0394 711.9273 null]
 >> endobj
-686 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R >>
+730 0 obj <<
+/Font << /F21 702 0 R /F23 726 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-743 0 obj <<
-/Length 3152      
+787 0 obj <<
+/Length 3167      
 /Filter /FlateDecode
 >>
 stream
-xÚí�[wÛ6Çßý)ôh?‹ûå1מvw“4q_¶ÛVf�J¢W’›f?ý‚"
-pdìÖÙØR{Z;1‡3žÿO’lBý¿l¢4ÑŽ»‰q’(ÊÔd¶<£“kÿ³ïÎXÌ44…G=¿<ûËka&Ž8ÍõäòãD*E¸Ú�Ìj-›\^ý|þâí›ËWo.?\ürùÃÙ«ËxVè™QÑžò_g?ÿB'W>€Î(ΪÉgÿJ˜s|²<“J%…³8ûpöc<!øéÎ4û›0J¸Ð<ó«p
~•ö‡ŠMŒrDÿ“ö‘Äv1eœÒóïêU½®¶óÕõÅ”+zþ×úËæbj5?'Såx|_¤sÚÉîJM}Ö�Ð)Ÿ{Ú¬¯'Ý7ï¡ZÁn
+xÚí�[wÛ6Çßý)ôh?‹ûå1מvw“4q_¶ÛVf�J¢W’›Í~úEZàÈØ­ÓØR{Z;1‡3žÿO’lBý¿l¢4ÑŽ»‰q’(ÊÔd¶<£“kÿ³ïÎXÌ44…G=¿<ûËka&Ž8ÍõäòãD*E¸Ú�Ìj-›\^ý|þâí›ËWo.?\ürùÃÙ«ËxVè™QÑžò_g?ÿB'W>€Î(ΪÉgÿJ˜s|²<“J%…³8ûpöc<!øéÎ4û›0J¸Ð<ó«p
~•ö‡ŠMŒrDÿ“ö‘Äv1eœÒóïêU½®¶óÕõÅ”+zþ×úËæbj5?'Såx|_¤sØÉîJM}Ö�Ð)Ÿ{Ú¬¯'Ý7ï¡ZÁn
 
÷ÕÚ?«×{qõsq`¬ Þ+ÒM©Ž¬ðž•óëUeû©î¾ùG³òߪOÄ Ä„¬1b j1™80bPï�¡ˆÒÖEbDOÌ‹fõOJùõí:ró¡^ÿ^¯Û1†‰cEe”‘�ÇbF€!ÆÔ‰›qF2q`Œ Þ
óCŽöå‘ûª&ï!qêyøþÝïº'ãöæ¦Yo»?ÌWÝ×çß¿yÙ}ç
g�w�ù*
 0ÄH�ba¤dâÀHÙóžs%–ºSÝ�¹{Cmêàªí¼Yr>Öëz5«Ç3N~ïñ`ã-Z°ñŒ�Óa™ÚóšýL1KŒéW
uo³©y=s‹W‹zY¯¶~¢˜9Ö~e”��ÒâO0Ä>YP2Œ“L/¨÷0i¥š©UÀe¼Qù{µ�}
 EyÓ¢¢
?õ´wP	é,Fb¨@¹G%†
-ê�qM¤`r¢<4†I›`Ùá"Úõ�/«mõÇÅT8uZZ½(1•¥ @C”�T(¹8Ppï	ˉ¶‚
PxÊ˺­C«yªBÕê*ô½Õu»:ÿ-Ìô¿Æ*{ÌR1Àc
-�
-ƒ$F	ê=`¢(tRæ &¿Õ_rS__‚œ!ìiÕ7漘'`ˆñ5ÅxÊÄ�ñ„z<	KM£Ž}œ�8Š>½N*¤¶˜šd‡A„ãÛò3A`È`®1ÜsbXBÆDfÑ\_·;É2…Êø!Ï©Cë9JÕnØâbt€!Æ”ƒ'Fê=àä?Üé´HŠŸ{Ltþ?»¬þ´†;䲘`ˆqµÂ8ÉÄ�q‚z�W™$å„Sã
+ê�qM¤`r¢<4†I›`Ùá"Úõ�/«mõï‹©pê´´zPb*KA�†(©Prq  àÞ(–m ð”—u[‡VóT…ªÕUè{«ëvuþ[˜é�Uö˜¥b€!Æ
+0ÄP�ra¨dâÀPA½§áBY¢™3	–S]ù_A	©,b @©0P2q`  Þ(ReSsãA9Õ•}B–Š
+àñÉu³ÎÍt$%Úš;ðHj�ªBÅô–Â
xòI:
+O.Ü{_¡„±„I	*Ôá«U‹Ïë:·ÐÇ}}Š°ŒMo¸ÒG|Ý3¦»%`ˆ¡å”ã[ðrq`(¡ÞJZ{z8(aüAP:<Ó‘Ì=¡Ñ'¤µ`ˆ!eÃ�ÉÄ�!ƒzÈ(I¨e<!søJÕ²ÚlÛûãóócéôÁþJWõ
+9.æbü@
1~2q`ü Þ?’*�Jüȇâç>ý•{ÌýUÌe1'Àãj…q’‰ãõ8í„vW‡/U57­Ô›üëÏvðR;®©MÈq1?Àãjˆñ“‰ãõøa†8«A�ÒÅÏ}.XÉG]�B.‹9
†'P+9¾q"Æ	ê=µâT§$¨H:¬ã<ošE]õ¢¾íé˜*áŽøjSLW1Àƒ
Ê!Çsq`0 Þ#Ü	â8·†~]æu³þ\uOXÙÝv.)?ÝV0d#f¯”
hˆ°1PG�”\¸÷ĆõÕÂÁÖG·OkÙxy[-¦›m5ûíÎÁÄ·wËÒ×$bªŠA
+„L¨÷‚vÄ*7¨²áÙlo…~Ñn°kÇ‹fÑ�Ó}Ï)qÅX
+¤Æo1ÉÅ�á�zOxHEŒÓâ¡;<~¼­Û‡íè¨ Œ9QóVL0Ĩ€º`TdâÀ¨@½'*„ F»ÓQÑ=…¶…âòÂÑóuµÚ|ÜM*”a',b⊱
+!e?Ìuâ„+"Í�Ew <¿�/¶Óðš“
èWæ«�»×ÄÿiVíZ¸1îQY(Öb²<¾&™‹“õž4f‚Hy§19�_-o¶_Ò;³Ú«ßÐÔÃö !IÅ
+…Óú	iÝg£Xêd‡)
s=¾Ðœ	ÓsÝŽ+Á=H‡oÖßø†À7óÙfÚßÀ–Û.çû\©ì¡'ƒøIÉ##ÆØI,eØ!l$ß•	au^MeˆP
 endobj
-742 0 obj <<
+786 0 obj <<
 /Type /Page
-/Contents 743 0 R
-/Resources 741 0 R
+/Contents 787 0 R
+/Resources 785 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 659 0 R
-/Annots [ 748 0 R 749 0 R 750 0 R 751 0 R 752 0 R 753 0 R 754 0 R 755 0 R 756 0 R 757 0 R 758 0 R 759 0 R 760 0 R 761 0 R 762 0 R 763 0 R 764 0 R 765 0 R 766 0 R 767 0 R 768 0 R 769 0 R 770 0 R 771 0 R 772 0 R 773 0 R 774 0 R 775 0 R 776 0 R 777 0 R 778 0 R 779 0 R 780 0 R 781 0 R 782 0 R 783 0 R 784 0 R 785 0 R 786 0 R 787 0 R 788 0 R 789 0 R 790 0 R 791 0 R 792 0 R 793 0 R 794 0 R 795 0 R 796 0 R 797 0 R 798 0 R 799 0 R 800 0 R 801 0 R 802 0 R 803 0 R 804 0 R ]
+/Parent 703 0 R
+/Annots [ 792 0 R 793 0 R 794 0 R 795 0 R 796 0 R 797 0 R 798 0 R 799 0 R 800 0 R 801 0 R 802 0 R 803 0 R 804 0 R 805 0 R 806 0 R 807 0 R 808 0 R 809 0 R 810 0 R 811 0 R 812 0 R 813 0 R 814 0 R 815 0 R 816 0 R 817 0 R 818 0 R 819 0 R 820 0 R 821 0 R 822 0 R 823 0 R 824 0 R 825 0 R 826 0 R 827 0 R 828 0 R 829 0 R 830 0 R 831 0 R 832 0 R 833 0 R 834 0 R 835 0 R 836 0 R 837 0 R 838 0 R 839 0 R 840 0 R 841 0 R 842 0 R 843 0 R 844 0 R 845 0 R 846 0 R 847 0 R 848 0 R ]
 >> endobj
-748 0 obj <<
+792 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 758.4766 511.2325 767.4329]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.8.1) >>
 >> endobj
-749 0 obj <<
+793 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 746.445 511.2325 755.4012]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.8.2) >>
 >> endobj
-750 0 obj <<
+794 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 734.5129 511.2325 743.3696]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.8.3) >>
 >> endobj
-751 0 obj <<
+795 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 722.3816 511.2325 731.3379]
 /Subtype /Link
 /A << /S /GoTo /D (section.4.9) >>
 >> endobj
-752 0 obj <<
+796 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 710.3499 511.2325 719.3062]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.9.1) >>
 >> endobj
-753 0 obj <<
+797 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 698.3182 511.2325 707.2745]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.4.9.2) >>
 >> endobj
-754 0 obj <<
+798 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 675.998 511.2325 684.7301]
 /Subtype /Link
 /A << /S /GoTo /D (chapter.5) >>
 >> endobj
-755 0 obj <<
+799 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 663.9862 511.2325 672.9425]
 /Subtype /Link
 /A << /S /GoTo /D (section.5.1) >>
 >> endobj
-756 0 obj <<
+800 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 651.9545 511.2325 660.9108]
 /Subtype /Link
 /A << /S /GoTo /D (section.5.2) >>
 >> endobj
-757 0 obj <<
+801 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 629.6343 511.2325 638.4909]
 /Subtype /Link
 /A << /S /GoTo /D (chapter.6) >>
 >> endobj
-758 0 obj <<
+802 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 617.6225 511.2325 626.7282]
 /Subtype /Link
 /A << /S /GoTo /D (section.6.1) >>
 >> endobj
-759 0 obj <<
+803 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 605.5908 511.2325 614.5471]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.1.1) >>
 >> endobj
-760 0 obj <<
+804 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 593.5591 511.2325 602.5154]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.1.1.1) >>
 >> endobj
-761 0 obj <<
+805 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 581.5275 511.2325 590.4837]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.1.1.2) >>
 >> endobj
-762 0 obj <<
+806 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 569.4958 511.2325 578.4521]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.1.2) >>
 >> endobj
-763 0 obj <<
+807 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 557.4641 511.2325 566.4204]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.1.2.1) >>
 >> endobj
-764 0 obj <<
+808 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 545.4324 511.2325 554.3887]
+/Rect [499.2773 545.4324 511.2325 554.5382]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.1.2.2) >>
 >> endobj
-765 0 obj <<
+809 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 533.4007 511.2325 542.5065]
 /Subtype /Link
 /A << /S /GoTo /D (section.6.2) >>
 >> endobj
-766 0 obj <<
+810 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 521.3691 511.2325 530.3254]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.1) >>
 >> endobj
-767 0 obj <<
+811 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 509.3374 511.2325 518.2937]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.2) >>
 >> endobj
-768 0 obj <<
+812 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 497.3057 511.2325 506.262]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.3) >>
 >> endobj
-769 0 obj <<
+813 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 485.274 511.2325 494.2303]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.4) >>
 >> endobj
-770 0 obj <<
+814 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 473.2424 511.2325 482.1986]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.5) >>
 >> endobj
-771 0 obj <<
+815 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 461.2107 511.2325 470.167]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.6) >>
 >> endobj
-772 0 obj <<
+816 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 449.179 511.2325 458.1353]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.7) >>
 >> endobj
-773 0 obj <<
+817 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 437.1473 511.2325 446.1036]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.8) >>
 >> endobj
-774 0 obj <<
+818 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 425.1157 511.2325 434.0719]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.9) >>
 >> endobj
-775 0 obj <<
+819 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 413.084 511.2325 422.0403]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.10) >>
 >> endobj
-776 0 obj <<
+820 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 401.0523 511.2325 410.0086]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.10.1) >>
 >> endobj
-777 0 obj <<
+821 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 389.0206 511.2325 398.1264]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.10.2) >>
 >> endobj
-778 0 obj <<
+822 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 377.0886 511.2325 386.0947]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.11) >>
 >> endobj
-779 0 obj <<
+823 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 365.0569 511.2325 374.063]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.12) >>
 >> endobj
-780 0 obj <<
+824 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 353.0252 511.2325 362.0313]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.13) >>
 >> endobj
-781 0 obj <<
+825 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 340.9936 511.2325 349.9997]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.14) >>
 >> endobj
-782 0 obj <<
+826 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 328.9619 511.2325 337.968]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.15) >>
 >> endobj
-783 0 obj <<
+827 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 316.9302 511.2325 325.9363]
+/Rect [499.2773 316.8305 511.2325 325.9363]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.16) >>
 >> endobj
-784 0 obj <<
+828 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 304.7989 511.2325 313.9046]
+/Rect [499.2773 304.8985 511.2325 313.9046]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.1) >>
 >> endobj
-785 0 obj <<
+829 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 292.7672 511.2325 301.873]
+/Rect [499.2773 292.7672 511.2325 301.7235]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.2) >>
 >> endobj
-786 0 obj <<
+830 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 280.7355 511.2325 289.8413]
+/Rect [499.2773 280.7355 511.2325 289.6918]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.3) >>
 >> endobj
-787 0 obj <<
+831 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 268.7038 511.2325 277.8096]
+/Rect [499.2773 268.7038 511.2325 277.6601]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.4) >>
 >> endobj
-788 0 obj <<
+832 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 256.6722 511.2325 265.6285]
+/Rect [499.2773 256.6722 511.2325 265.7779]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.5) >>
 >> endobj
-789 0 obj <<
+833 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 244.6405 511.2325 253.5968]
+/Rect [499.2773 244.6405 511.2325 253.7462]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.6) >>
 >> endobj
-790 0 obj <<
+834 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 232.6088 511.2325 241.7146]
+/Rect [499.2773 232.6088 511.2325 241.5651]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.7) >>
 >> endobj
-791 0 obj <<
+835 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 220.5771 511.2325 229.5334]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.8) >>
 >> endobj
-792 0 obj <<
+836 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 208.5455 511.2325 217.5017]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.9) >>
 >> endobj
-793 0 obj <<
+837 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 196.5138 511.2325 205.4701]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.10) >>
 >> endobj
-794 0 obj <<
+838 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 184.4821 511.2325 193.4384]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.11) >>
 >> endobj
-795 0 obj <<
+839 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 172.4504 511.2325 181.4067]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.12) >>
 >> endobj
-796 0 obj <<
+840 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 160.4187 511.2325 169.375]
+/Rect [499.2773 160.4187 511.2325 169.5245]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.13) >>
 >> endobj
-797 0 obj <<
+841 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 148.3871 511.2325 157.3433]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.14) >>
 >> endobj
-798 0 obj <<
+842 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 136.3554 511.2325 145.4611]
+/Rect [499.2773 136.3554 511.2325 145.3117]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.15) >>
 >> endobj
-799 0 obj <<
+843 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 124.3237 511.2325 133.28]
+/Rect [499.2773 124.3237 511.2325 133.4295]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.16) >>
 >> endobj
-800 0 obj <<
+844 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 112.292 511.2325 121.2483]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.17) >>
 >> endobj
-801 0 obj <<
+845 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [499.2773 100.2604 511.2325 109.3661]
+/Rect [499.2773 100.2604 511.2325 109.2166]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.2.16.18) >>
 >> endobj
-802 0 obj <<
+846 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 88.2287 511.2325 97.185]
 /Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.16.19) >>
+/A << /S /GoTo /D (subsection.6.2.17) >>
 >> endobj
-803 0 obj <<
+847 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 76.197 511.2325 85.1533]
 /Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.17) >>
+/A << /S /GoTo /D (subsection.6.2.18) >>
 >> endobj
-804 0 obj <<
+848 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [499.2773 64.1653 511.2325 73.1216]
 /Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.18) >>
+/A << /S /GoTo /D (subsection.6.2.19) >>
 >> endobj
-744 0 obj <<
-/D [742 0 R /XYZ 56.6929 794.5015 null]
+788 0 obj <<
+/D [786 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-741 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R >>
+785 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-807 0 obj <<
-/Length 3350      
-/Filter /FlateDecode
->>
-stream
-xÚí�Ks7€ïú<¤j¥ƒ°x€ÝÖ^v”rd¯$W¶6É�&ÇËâPáÃŽ÷×/†`š"¦%8~È�J‘’¦§›Ýß4º
Ì�õ¨û�õŒ"TXÙÓVE™ê
&;´7r{¾Ãü1ûá }xÔáåÎߟ	ݳļè]¾ç2„Ãz—Ã_w�^ž]žœ]^ìý~ùÓÎÉe<)T̨¨ÏøÇί¿ÓÞÐéÿi‡a�ê}p?P¬å½ÉŽT‚()DøÍõÎÅοã	Á_W¢©¢„!Êp�ø$\€OÂ8'Æjg�²¤îoõG)wŠëâgàpÁˆ1T:õa‹Ùr¾(‡ûïÊ�s0<·2ÄrSøƒ/ýE9)«ÅÞ>Wt÷ù¬?™ôg{ûFÒ]²·¯èx‘Ö~ŠÜ­€+nHÁ)k}º¡Ù¨×¼9‡1rûPp3f›ç_ÅLoØHÙ�ƒjo‰‘šZ³H§_”˜ãò7Jy5^Œ§Uó›~5lÞ¼ž÷GeýV<LN:
	.Ìb€¬…
$aª½D(¢9³- ìN@Þ�Ë	0¸tH«;R‰âÁ¤’Ï™_î	Spw6L@ƒi-œL	;0˜Pí-L\]¦…‰˜îÎ2…-¾?v:¡	n͆bЬ…
�&a
ª½…†9+ZhÄ�ÐüoZ•ih¨¶ú®dÌcN=wÁÜ�
Ä`Z§í†)aª=ÂTXKŒ*d“ü"0Ý��´b�gØŠnÍ…
-"Ь…M³NhRv ÐàÚ™’Dkm{…ÑÄR&
-A(2
^ñ•úôN‚«²A
-nφ
-bPÁ°bP%ìÀ BµÇá•Ib¹ôK“q£ZçÖĶ¼Õªx⋃�ÀŸf1``Ì0`v`ÀlhOuAÂÖóþÎUã» Ë=ÆØîlº|s]ίÜøUç£.÷Ä3Ü·Ù�H³³nY÷*;<âŽM­©ëG7z+?E{�£édö]¼j†iç™I=M 嶵ɾ¢‚—s/( ‡\Ok1D¸Ù4ÃS‡tQXB­¿Óø
}«µõÅß|¯\Mýíg¦³wîºúgóÓÕôCófЋíÍK}�Ú¨ÙèsötÎpÕ�§ýà«ÇÑ¿\*gæ
�·Ñ'ÙÑ‚X¸×|ŽÄ;apT{ÌJ׫ú^zUÁÕ	ã´4«‹ùXÌÅݸGWýj´VãùÁx6S’gËÉ›z†Ú™ñ
-ùè¦l€ ÆÀZv` Ú#Rfü��&Ö\¿Ô;%Ú«öèÖuý¼ôWñ�åõ�»h¥ÜŽ÷B)x;% ˆ¡´M¥„JÚ“Õ„~BüÀerÎwnnÊj8”ÝóÍQìÞ%ÀJ0hŽí^¾�§Ã|°¡5y91FªñA=‚jí¼0xWM?\—ÃQ�Rë=ðÜn+¯ü«'87ûê
‚ØÕƒ‡“°#ÕË/nëù^#:5<¶¾„šL{8—~×ô�ãùb:û¸¾•:ÄÇg·Fìf]¨ ìñ �•‹DPX‚BÊ\{H"Üh"©`žÞ$‘çeUÎB…ƒ|^¾õ#uî¶9­Þ®‚WÓe…}ZëOÑwÙ`
-.fÑJ6q8\
«ÂîÇ£G•4¿Ÿ›_c<r¯;(ˆ\wkñF KÙ�À†k�°F´µÌÃÆØ®¦u
§ô–¶¯G› …0º
È}iórûP0EÛíó×
g´»HL‚ᆪ�¸–æáj°¯S[5Ÿ—ƒúÉì£ú™<Rª-SŸ	&ïîl–Z9%LFe7I›V` aº#GJãþy�äHóñ¨Z=þÖ¡$¶ýU†‚«³!‚E0”Œv×�)C0ŽPõ$©ˆ¢ð ©¤ª?)‡ûƒ«rðn0­ÞîÕÅÛôÉg1‚`í^¡N‚„ª�	A¬6¾s©o­¼E�OEj›ƒ>� àãl‚€ FŒ!cÝI‚„ª�qN(¡áÓ€ ×[µ-»¿BÙb�Mă1f)»†`„¡ê#aŒZ˜Ð噆°Y58ï2³mï¾:n! Ù¸
A7pƺoiL‚ᆪ¸YCéÌ™›°�74Ö’U�•xX
+851 0 obj <<
+/Length 3445      
+/Filter /FlateDecode
+>>
+stream
+xÚí�[SGÇßùzHÕ½}¿ì>laÀ){1©lm’YƒÊH"º@¼Ÿ~{4ÓÝG¨ç@oÖáW
+�æÌ9:ÿßœ¾Îˆõ¨ÿÇzV*œì'‰¢Lõã-Ú;óï½Ùbí1»á ]xÔ«Ó­¿¾¦çˆÓ\÷N?ƒsYB­e½ÓáÏÛûï�O�O?îüzúÃÖái<)t̨¨ÏøÛÖÏ¿ÒÞÐûÿa‹á¬ê]û_(aÎñÞxK*A”"üåbëãÖ?ã	Á»+ÓÜQÂe¹É|.À'aœëŒ�N9¢…¯þ(špÂiýAüá.±–Jï£>l^Í®ªY{<«ðqk­ÛÃ>.ú‹j\M;»\ÑíƒêJùd´M'Í_ú“aóâÇyÿ¬ÚÙµŽn“�]Eïå‡t®Èà†ÜŠ[¢9e)£úÌÎzÍ‹¨X°Û…†›Šmž¥˜Ýˆ#�‹ãõžx‘†(Eyâ…ÝÊËb¶œ/ªáî—êë<C�²ÄqÛAÍ›Y<îÏ<ò>áøc¨ÜFLÈi11À#fM3×ML&ŒÔ{"F("µÄðoJÌíu†+ñÈJJHa1 ÀdM"�L ¨÷DXÍ âV@®FÕu.ý2ê–R¢„x0¥äÿY_îSHw1LÀƒiMN¦LL¨÷cDP	`’ߦ۫Œvúñ±Ó	MHk14ÀƒfM6šL4¨÷�vηJ …R·2óŸé¤Ê3C�3· kŸrå¹…¥�íR”€BÔÒ°N�2A ¡®FÖ&Eú›Pt{å1Š=�æªMj1,Ñc%	fD7*`¤ ~™’ÄãzÚ(B•‘P!Ìq¼„ÿ®‰X‰yºã‡Ã_/«¹Ï�|à–{("!…Å`
+LWÎoc~:¯Ú‘Íb6¡S|^�ý
+ö,{!aÅ8
+ !BÁš–wR�‹¡
+xÛŒæƒeFîwÿÊy¯òß÷ÌzÌa1!À#j„’‰#õžÑæT$D´„|¬‹Ñä¬mÕOß®8�/ýËr~B†‹ù
†?PAÛ=–‹ãõžøñ
&ñ#[~Ž&WÕ,ô
+ßõ//#L£¶æ}¸òs+^†"1‹ÅŒ
+†á’‰Ãõžpa†8ÇÀ…—àrt¼ÿöǃÃÜÖ5E¨]¼pñôêJHe1(ÀJ…�’‰õž@¡Š8ê (¢ßóÍ­ÿkb¥ë€ÄÜÏ´üýu^BŠ‹
†@PB L@¨÷Øy‘N<�
+™OÿIãô.bªJA€†kRØ\¸÷‚eÄH•@0-{Ãáj¯O˜NK¼žÎÆý…ï¹j£_91�Åx
+';La�fLáÍ 0…1×IaΈÔ�8í‘&PßõG^ÆI2¨nÓÙ—–‡>�?r±˜ÀS¦Ôvß­›‹Óõž¥ŽpÅ¡ ìÚ¸¸Ãµj5Bµ9ä£Xm`ˆ©
ó�©�‰SõÕÎf¨jËVíýéøÒ+üit1Z|m$¾-Λ)
+w7uÞÏ–º·Fé—)Ë<0!§ÅÀ
+"—ÔšŒ;™80†Pï±a纞$â�¡Ø_<Zü¥0O¦íãJ®§³/þâú{óÛùôºy1è‡mÚÍ�ú™&gÍ]dmáž.ÃÎûñ´×mò쾞3û€Ý�’b½“&7H8¦öf˜Ø˜ëX/”"±Zð¶ZM�TuW>våâ
œûçýÉÙZ/,�Â.–ãåøS=ù,´{Ýø6IÅÚG3Lú$
+1Y¥(@C…51rq (àÞCaVÅ] �7EäM5©f¡_E>©>·-uܨq4ù¼Ú1¼š"Óîy­9Å܃
10 6®{é?ê=ÕÉ”í˜{Í~]#Ž>\éö¢ÃS³Y~ñº=ÿŸÿÉêE{ó²ë7汘`ˆQuÂ(ÉÄ�Q‚z�åCS"´
+�ˆ¦|¼}ºMÏfýË󯉋ØF|\ž�UõÃØCYéýÈ®AFpþLŠGÈ\1ÀÃ*ƒa‘‰ÃõžŠ‡ô#{ÛÞk¹×<Ë©.'ÕoK/}#¼o:ÂVˆqÛY
¬œ¼ÞŸ7@XÁŸG�3¦¬`ˆ

%Á€ÈÄ�
�zO@M|	Þ¶&õþ®IâÌúŸkœã/ÃŒA´°&eõ®Ì´v»Ð0ÇÌÍóת1ڽ̒ƒuŸ á’0ÖÞG¹×<ꥆ<…á`:X‚Ú±÷)Îñ6#ÅžzùR…\£
+™@06Üçæ{eDiÓÌY¾ª[±ý®?‰»ìŸå¦}BìÁú¶iŸ˜`�›ö¹yÞ&'ÝO)�çÃr±á6×粎H«ÚT¬Vᶇ£³'U6Ám\-AŽÒëØ!—#,ê;pf‘T´˜ñ³óiÝySæ…³?�³VŽRÌ’B�šQäûß6BÀ¾(qŸ+¬ˆà¡’‰¶’Mæój°;œnfÇ_*?ˆöûMAß Ms):ÉAHÈEžF~3„
tâ—QîrG¬µ¹ÆÒÿψSͽíì»/Ó7tÖ\²]ß)&¨ó‘SÙ«¿yL4׈B6Ó®‘ÿî£A{endstream
 endobj
-806 0 obj <<
+850 0 obj <<
 /Type /Page
-/Contents 807 0 R
-/Resources 805 0 R
+/Contents 851 0 R
+/Resources 849 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 659 0 R
-/Annots [ 809 0 R 810 0 R 811 0 R 812 0 R 813 0 R 814 0 R 815 0 R 816 0 R 817 0 R 818 0 R 819 0 R 820 0 R 821 0 R 822 0 R 823 0 R 824 0 R 825 0 R 826 0 R 827 0 R 828 0 R 829 0 R 830 0 R 831 0 R 832 0 R 833 0 R 834 0 R 835 0 R 836 0 R 837 0 R 838 0 R 839 0 R 840 0 R 841 0 R 842 0 R 843 0 R 844 0 R 845 0 R 846 0 R 847 0 R 848 0 R 849 0 R 850 0 R 851 0 R 852 0 R 853 0 R 854 0 R 855 0 R 856 0 R 857 0 R 858 0 R 859 0 R 860 0 R 864 0 R 865 0 R ]
+/Parent 703 0 R
+/Annots [ 853 0 R 854 0 R 855 0 R 856 0 R 857 0 R 858 0 R 859 0 R 860 0 R 861 0 R 862 0 R 863 0 R 864 0 R 865 0 R 866 0 R 867 0 R 868 0 R 869 0 R 870 0 R 871 0 R 872 0 R 873 0 R 874 0 R 875 0 R 876 0 R 877 0 R 878 0 R 879 0 R 880 0 R 881 0 R 882 0 R 886 0 R 887 0 R 888 0 R 889 0 R 890 0 R 891 0 R 892 0 R 893 0 R 894 0 R 895 0 R 896 0 R 897 0 R 898 0 R 899 0 R 900 0 R 901 0 R 902 0 R 903 0 R 904 0 R 905 0 R 906 0 R 907 0 R 908 0 R 909 0 R 910 0 R ]
 >> endobj
-809 0 obj <<
+853 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [527.6238 758.4766 539.579 767.4329]
 /Subtype /Link
-/A << /S /GoTo /D (subsection.6.2.19) >>
->> endobj
-810 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 746.5215 539.579 755.4777]
-/Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.20) >>
 >> endobj
-811 0 obj <<
+854 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 734.5663 539.579 743.5226]
+/Rect [527.6238 746.3946 539.579 755.3509]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.21) >>
 >> endobj
-812 0 obj <<
+855 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 722.6111 539.579 731.5674]
+/Rect [527.6238 734.3125 539.579 743.2688]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.22) >>
 >> endobj
-813 0 obj <<
+856 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 710.656 539.579 719.6122]
+/Rect [527.6238 722.2305 539.579 731.1868]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.23) >>
 >> endobj
-814 0 obj <<
+857 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 698.8005 539.579 707.8065]
+/Rect [527.6238 710.1484 539.579 719.1047]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.2.24) >>
 >> endobj
-815 0 obj <<
+858 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 686.8453 539.579 695.8514]
+/Rect [527.6238 698.1661 539.579 707.1721]
 /Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.24.1) >>
+/A << /S /GoTo /D (subsection.6.2.25) >>
 >> endobj
-816 0 obj <<
+859 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 674.8901 539.579 683.7467]
+/Rect [527.6238 685.9843 539.579 694.9406]
 /Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.24.2) >>
+/A << /S /GoTo /D (subsection.6.2.26) >>
 >> endobj
-817 0 obj <<
+860 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 662.8353 539.579 671.7916]
+/Rect [527.6238 673.9023 539.579 682.8586]
 /Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.24.3) >>
+/A << /S /GoTo /D (subsubsection.6.2.26.1) >>
 >> endobj
-818 0 obj <<
+861 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 650.8801 539.579 659.8364]
+/Rect [527.6238 661.9199 539.579 670.926]
 /Subtype /Link
-/A << /S /GoTo /D (subsubsection.6.2.24.4) >>
+/A << /S /GoTo /D (subsubsection.6.2.26.2) >>
 >> endobj
-819 0 obj <<
+862 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 649.7382 539.579 658.6945]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.2.26.3) >>
+>> endobj
+863 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 637.7558 539.579 646.6124]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.2.26.4) >>
+>> endobj
+864 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 638.925 539.579 647.8812]
+/Rect [527.6238 625.5741 539.579 634.5304]
 /Subtype /Link
 /A << /S /GoTo /D (section.6.3) >>
 >> endobj
-820 0 obj <<
+865 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 626.9698 539.579 635.9261]
+/Rect [527.6238 613.4921 539.579 622.4483]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.3.1) >>
 >> endobj
-821 0 obj <<
+866 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 615.0146 539.579 623.9709]
+/Rect [527.6238 601.41 539.579 610.3663]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.3.1.1) >>
 >> endobj
-822 0 obj <<
+867 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 603.0594 539.579 612.0157]
+/Rect [527.6238 589.328 539.579 598.2842]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.3.1.2) >>
 >> endobj
-823 0 obj <<
+868 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 591.1043 539.579 600.0606]
+/Rect [527.6238 577.2459 539.579 586.2022]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.3.2) >>
 >> endobj
-824 0 obj <<
+869 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 579.1491 539.579 588.1054]
+/Rect [527.6238 565.1639 539.579 574.1201]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.3.3) >>
 >> endobj
-825 0 obj <<
+870 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 567.1939 539.579 576.1502]
+/Rect [527.6238 553.0818 539.579 562.0381]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.3.4) >>
 >> endobj
-826 0 obj <<
+871 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 555.2388 539.579 564.3445]
+/Rect [527.6238 540.9998 539.579 550.1055]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.3.5) >>
 >> endobj
-827 0 obj <<
+872 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 543.2836 539.579 552.3894]
+/Rect [527.6238 528.9177 539.579 538.0235]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.3.5.1) >>
 >> endobj
-828 0 obj <<
+873 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 531.3284 539.579 540.4342]
+/Rect [527.6238 516.8357 539.579 525.9414]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.3.5.2) >>
 >> endobj
-829 0 obj <<
+874 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 519.3733 539.579 528.479]
+/Rect [527.6238 504.7536 539.579 513.8594]
 /Subtype /Link
 /A << /S /GoTo /D (subsubsection.6.3.5.3) >>
 >> endobj
-830 0 obj <<
+875 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 507.4181 539.579 516.5239]
+/Rect [527.6238 492.6716 539.579 501.6279]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.3.6) >>
 >> endobj
-831 0 obj <<
+876 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 495.4629 539.579 504.4192]
+/Rect [527.6238 480.5895 539.579 489.5458]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.6.3.7) >>
 >> endobj
-832 0 obj <<
+877 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 468.5075 539.579 477.4638]
+/Subtype /Link
+/A << /S /GoTo /D (section.6.4) >>
+>> endobj
+878 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 456.4254 539.579 465.3817]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.4.0.1) >>
+>> endobj
+879 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 444.3434 539.579 453.2997]
+/Subtype /Link
+/A << /S /GoTo /D (subsection.6.4.1) >>
+>> endobj
+880 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 432.2613 539.579 441.2176]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.4.1.1) >>
+>> endobj
+881 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 420.1793 539.579 429.1356]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.4.1.2) >>
+>> endobj
+882 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 408.0972 539.579 417.0535]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.4.1.3) >>
+>> endobj
+886 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 473.5253 539.579 482.2574]
+/Rect [527.6238 396.0152 539.579 404.9715]
+/Subtype /Link
+/A << /S /GoTo /D (subsubsection.6.4.1.4) >>
+>> endobj
+887 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [527.6238 373.4431 539.579 382.2997]
 /Subtype /Link
 /A << /S /GoTo /D (chapter.7) >>
 >> endobj
-833 0 obj <<
+888 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 461.59 539.579 470.5462]
+/Rect [527.6238 361.3809 539.579 370.4867]
 /Subtype /Link
 /A << /S /GoTo /D (section.7.1) >>
 >> endobj
-834 0 obj <<
+889 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 449.6348 539.579 458.5911]
+/Rect [527.6238 349.2989 539.579 358.2551]
 /Subtype /Link
 /A << /S /GoTo /D (section.7.2) >>
 >> endobj
-835 0 obj <<
+890 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 437.6796 539.579 446.6359]
+/Rect [527.6238 337.2168 539.579 346.1731]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.7.2.1) >>
 >> endobj
-836 0 obj <<
+891 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 425.7245 539.579 434.6807]
+/Rect [527.6238 325.1348 539.579 334.091]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.7.2.2) >>
 >> endobj
-837 0 obj <<
+892 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 413.7693 539.579 422.7256]
+/Rect [527.6238 313.0527 539.579 322.009]
 /Subtype /Link
 /A << /S /GoTo /D (section.7.3) >>
 >> endobj
-838 0 obj <<
+893 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 391.8316 539.579 400.5637]
+/Rect [527.6238 290.4806 539.579 299.2128]
 /Subtype /Link
 /A << /S /GoTo /D (chapter.8) >>
 >> endobj
-839 0 obj <<
+894 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 379.8963 539.579 388.8526]
+/Rect [527.6238 278.4184 539.579 287.3747]
 /Subtype /Link
 /A << /S /GoTo /D (section.8.1) >>
 >> endobj
-840 0 obj <<
+895 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 367.9411 539.579 376.8974]
+/Rect [527.6238 266.3364 539.579 275.2927]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.8.1.1) >>
 >> endobj
-841 0 obj <<
+896 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 355.986 539.579 364.9423]
+/Rect [527.6238 254.2544 539.579 263.2106]
 /Subtype /Link
 /A << /S /GoTo /D (section.8.2) >>
 >> endobj
-842 0 obj <<
+897 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 344.0308 539.579 352.9871]
+/Rect [527.6238 242.1723 539.579 251.1286]
 /Subtype /Link
 /A << /S /GoTo /D (section.8.3) >>
 >> endobj
-843 0 obj <<
+898 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 322.0931 539.579 330.9498]
+/Rect [527.6238 219.6002 539.579 228.3323]
 /Subtype /Link
 /A << /S /GoTo /D (appendix.A) >>
 >> endobj
-844 0 obj <<
+899 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 310.1578 539.579 319.2636]
+/Rect [527.6238 207.538 539.579 216.4943]
 /Subtype /Link
 /A << /S /GoTo /D (section.A.1) >>
 >> endobj
-845 0 obj <<
+900 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 298.2027 539.579 307.3084]
+/Rect [527.6238 195.456 539.579 204.4123]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.A.1.1) >>
 >> endobj
-846 0 obj <<
+901 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 286.2475 539.579 295.2038]
+/Rect [527.6238 183.3739 539.579 192.3302]
 /Subtype /Link
 /A << /S /GoTo /D (section.A.2) >>
 >> endobj
-847 0 obj <<
+902 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 274.2923 539.579 283.2486]
+/Rect [527.6238 171.2919 539.579 180.2482]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.A.2.1) >>
 >> endobj
-848 0 obj <<
+903 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 262.3372 539.579 271.2934]
+/Rect [527.6238 159.2098 539.579 168.1661]
 /Subtype /Link
 /A << /S /GoTo /D (section.A.3) >>
 >> endobj
-849 0 obj <<
+904 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 250.382 539.579 259.3383]
+/Rect [527.6238 147.1278 539.579 156.0841]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.A.3.1) >>
 >> endobj
-850 0 obj <<
+905 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 238.4268 539.579 247.3831]
+/Rect [522.6425 135.0457 539.579 144.1515]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.A.3.2) >>
 >> endobj
-851 0 obj <<
+906 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 226.4717 539.579 235.4279]
+/Rect [522.6425 122.9637 539.579 132.0694]
 /Subtype /Link
 /A << /S /GoTo /D (subsection.A.3.3) >>
 >> endobj
-852 0 obj <<
+907 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 204.534 539.579 213.2661]
+/Rect [522.6425 100.3916 539.579 109.2482]
 /Subtype /Link
 /A << /S /GoTo /D (appendix.B) >>
 >> endobj
-853 0 obj <<
+908 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [527.6238 192.5987 539.579 201.555]
+/Rect [522.6425 88.3294 539.579 97.4352]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.1) >>
 >> endobj
-854 0 obj <<
+909 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 180.6435 539.579 189.7493]
+/Rect [522.6425 76.2474 539.579 85.3531]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.2) >>
 >> endobj
-855 0 obj <<
+910 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 168.6883 539.579 177.7941]
+/Rect [522.6425 64.1653 539.579 73.2711]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.3) >>
 >> endobj
-856 0 obj <<
+852 0 obj <<
+/D [850 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+849 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F39 885 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+913 0 obj <<
+/Length 762       
+/Filter /FlateDecode
+>>
+stream
+xÚíÙKOÜ0
+*q jÉ
q »a[Á†–mUµ¿¾NˆƒaWá!$X¡aã±ÇžO–�qÿƒL0$ˆYR 9j¶Xœ­ü½ömÊШŒ[íUÅ»i
aXuÎ”Ö t×™î²jy2{ÿñ¨Ú?ªŽç§Õa±_
½Æ##—m—?Š“SΖ>�ƒ$§Ùoÿ$l](-A+)Ã7—Åqñiè0ºÛ…&g‚„4"1!£©X#�ON“¿ð·Ú™ì�š—$i¶l6›zQ^ÔίçèfWë˳/õå¼tœf0/5ç¯å—¢'˜Ñ½Ê+òNÈ/ê°º[¥º^±›‹ÏQñ†¸2Ü.Þvÿmõq‹`Ð�J$g';ü`GY0ÖboGß·³ª¿¾J¿21/§)¬÷dMQ`NS\OD9®)‘HNSvøA“Ô`R¯ÉÜÑ´ù¶jþ^5uëIî =RXêÉ�¢À¤¸”ˆzR"‘¤ìð$!ÁãzHöRs¶®—åâk½¸X\5çóÒh±ô`Aa�'Šs‚â"ºqA‰Dr‚²Ã‚Á!š^�ÛÔoEz·=\PXãÉ‚¢Àœ ¸†ˆ4.(‘HNPvø È�ÓFõ‚(äÑô–ŽDÏGë?†Lf„Ý©1
+1*,•HFX~øA˜³@Ãr¿¨-±Í¯ï˳Ÿ~wÒVíx='¯P€É¼¢À¯¸À(Ô8¯D"9^Ùá^V)žíü£eÇëºY.üº·¾�½€·P‘ÉÞ¢Àœ·¸â(Æ�\©DrÞ²ÃÞŒ"žþ°ÛMß(ŒÚ
+
„ª¢mÔR„î(ßµ¼Ó«Áö”gû–;£Oê0Tj²Ã(0ç0–€büà–J$ç0;üàPàR‡‡G”·û^ÙbëÞiI”»=îiQ…eŸŒ*
+Ì¡ŠËŠrüEi*‘-TËøÒ 
Ã…M½‹÷ÒÿæÿöÊ‚tN¤§+²’˜ÔÐöÕNÖŒNµoeþwã¹endstream
+endobj
+912 0 obj <<
+/Type /Page
+/Contents 913 0 R
+/Resources 911 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 703 0 R
+/Annots [ 915 0 R 916 0 R 917 0 R 918 0 R 919 0 R 920 0 R 921 0 R 922 0 R 926 0 R 927 0 R ]
+>> endobj
+915 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 156.7332 539.579 165.8389]
+/Rect [494.296 758.5763 511.2325 767.5824]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.4) >>
 >> endobj
-857 0 obj <<
+916 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 144.778 539.579 153.8838]
+/Rect [494.296 746.5215 511.2325 755.6272]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.5) >>
 >> endobj
-858 0 obj <<
+917 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 132.8228 539.579 141.9286]
+/Rect [494.296 734.5663 511.2325 743.672]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.6) >>
 >> endobj
-859 0 obj <<
+918 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 120.9673 539.579 129.9734]
+/Rect [494.296 722.6111 511.2325 731.7169]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.7) >>
 >> endobj
-860 0 obj <<
+919 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 108.9125 539.579 118.0182]
+/Rect [494.296 710.656 511.2325 719.7617]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.8) >>
 >> endobj
-864 0 obj <<
+920 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 96.9573 539.579 106.0631]
+/Rect [494.296 698.8005 511.2325 707.8065]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.9) >>
 >> endobj
-865 0 obj <<
+921 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [522.6425 85.0022 539.579 94.1079]
+/Rect [494.296 686.8453 511.2325 695.8514]
 /Subtype /Link
 /A << /S /GoTo /D (section.B.10) >>
 >> endobj
-808 0 obj <<
-/D [806 0 R /XYZ 85.0394 794.5015 null]
+922 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [494.296 674.7905 511.2325 683.8962]
+/Subtype /Link
+/A << /S /GoTo /D (section.B.11) >>
 >> endobj
-805 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
+926 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [494.296 662.8353 511.2325 671.941]
+/Subtype /Link
+/A << /S /GoTo /D (section.B.12) >>
 >> endobj
-868 0 obj <<
-/Length 69        
-/Filter /FlateDecode
->>
-stream
-xÚ3T0
-endobj
-867 0 obj <<
-/Type /Page
-/Contents 868 0 R
-/Resources 866 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 659 0 R
+927 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [494.296 650.8801 511.2325 659.9859]
+/Subtype /Link
+/A << /S /GoTo /D (section.B.13) >>
 >> endobj
-869 0 obj <<
-/D [867 0 R /XYZ 56.6929 794.5015 null]
+914 0 obj <<
+/D [912 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-866 0 obj <<
-/ProcSet [ /PDF ]
+911 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F41 925 0 R >>
+/ProcSet [ /PDF /Text ]
 >> endobj
-872 0 obj <<
+930 0 obj <<
 /Length 2197      
 /Filter /FlateDecode
 >>
 stream
-xÚÝYÝ�ã¶÷_áG-pfù)‘y¼»¦¸ ¸¢Ý
ò�æA+qmádÉÑÇnœ¿¾C)˶|wé-РX`M�†äpæ7¿ÚlMá�­µ"T¹ÎŒ$Š2µ.ö+ºÞ»¿­XБJ%…€‡…·%4QšgëÍ|‘·«¿|ÏÙšS’¦\­ž¦½ÒL#¤Y?”?'ïvùa°Ý݆+š°»_~Ài’d:cn…-ÉÕ~‡fèÚr,†ªm‚ºXbRžFí悹Nûagai�ºi¶kì€OïÛ}^58þ˜ïƒÎý±ìÇÿ¦Š¾ÿxÌ	²¤h›¾ê‡_·Oø9Äõûc3ä¿ad[TOÇÍö»XÅ6C5T(Í’êŽ%
Ý$8£;cÄ(Å£Âa§‰;ˆà,ÉñqWÙ.ïî˜NŠ]Uä5J÷yÓ€›3™¼
�Ðh�{ÓÝéd¬Ýæn‘±·%ÊŸÚ¥­í6ªfö‡]ÛU˜yDIûlƒ®?\Ø!oÂJa+Nò>;ó'ªö‡ÚîÁ¹�놃¡Ã.wáÊT’Ø×õåûüÐã(ºT¼ÏA4‹³›X–Þ¶ïmOÀ-ˆ*ª–ù�£ZÕÇ•+° jœܳ‡ˆ[·~­v< ¢·›@ÒU�ãàQKñpR·ùcî­Š˜g’™ò€bI	Obž
-ôœA)*ìaˆÔqf§†d
-DÖñ›Öñ 	R
-}å7A,û�+£c”ú…%%”Æ8yÿiU¢¿^OI¢�0SÔƒ©C�>”‚e”<÷á!8|V5T•Ëã­Wóø·áÕÓØøú*ÉsUž›�vð>¯Jœ‹–D‚A G
-OyùœCÖ•“¦Ï@´64* >2óNgÃŒ&ÌõÀçUlN¾.ÝR Ñ#ë›0Hõ§øn*·Ø†�¤°ÝàK­{hîôËŒ�B/-RvÍi¢n0‚b‰ÒHUéŒ�
-êj»^¬ûh‚*"¸‘K4Ñ·õ3v£®tgihM2îc`ˆŠw.°Ëº>,)…¼â`7!]
->YÉàT&³ëdQ¶®ÂŠ¾QaÁô'ìL,
-¸×S^ÛIÀ“ÿõ÷7¨¹kûa¦	¼VÇêvñÍA
DŠÑ
úþ®ø�}	°ÝþüUè[o#zvÊosÜÑ—žƒ[Ñ¢gžû¾úÍql
-ôûR•Ãî6x_ÍÞ?xc _‘©!RªôKàe‚PÁ#ĆSY
VébÍ;ŒŸÁÏl£WcÄK㡪/ágnü@?y
-š[}¡[Ày5sÿ,¸áî‹®Œ¥î
-ADÆåüg¿«Ÿÿ¸§` Ô
˜¯µ^ü�0þô·Š¸_Ñ# §r”\²+·Ç_O+ÅÝþ-Õ«endstream
+xÚÝYÝ�ã¶÷_áG-pfù)‘y¼»¦¸ ¸¢Ý
ò�æA+qmádÉÑÇnœ¿¾C)˶|wé-РX`M�†äpæ7¿ÚlMá�­µ"T¹ÎŒ$Š2µ.ö+ºÞ»¿­XБJ%…€‡…·%4QšgëÍ|‘·«¿|ÏÙšS’¦\­ž¦½ÒL#¤Y?”?'ïvùa°Ý݆+š°»_~Ài’d:cn…-ÉÕ~‡fèÚr,†ªm‚ºXbRžFí悹Nûagai�ºi¶kì€OïÛ}^58þ˜ïƒÎý±ìÇÿ¦Š¾ÿxÌ	²¤h›¾ê‡_·Oø9Äõûc3ä¿ad[TOÇÍö»XÅ6C5T(Í’êŽ%
Ý$8£;cÄ(Å£Âa§‰;ˆà,ÉñqWÙ.ïî˜NŠ]Uä5J÷yÓ€›3™¼
�Ðh�{ÓÝéd¬Ýæn‘±·%ÊŸÚ¥­í6ªfö‡]ÛU˜yDIûlƒ®?\Ø!oÂJa+Nò>;ó'ªö‡ÚîÁ¹�놃¡Ã.wáÊT’Ø×õåûüÐã(ºT¼ÏA4‹³›X–Þ¶ïmOÀ-ˆ*ª–ù�£ZÕÇ•+° jœܳ‡ˆ[·~­v< ¢·›@ÒU�ãàQKñpR·ùcî­Š˜g’™ò€bI	Obž
+¥ŽrÜ\AÕ„ 78Y˜ÙdÍHÊ%¬áƒh±ùùla+°_¥™ê@0ˆF(ažsý®7
°t2ÏRN†,
+ôœA)*ìaˆÔqf§†dJfKÖñ›Öñ 	R
+}å7A,û�+£c”ú…%%”Æ8yÿiU¢¿^OI¢
L�Q¦=úP
+F”Qò܇‡àðYÔ<P
T.�k´^Íã߆WOcãè«$cÌUynBÚÁû¼*q.Z	
+�
Œ=¾Aæ‘óB´f3bØ„ç̹ljj_jÊü¹×¼Kúydð„ S×íKTy<.E#¥Ðæ)¶`¹‘‘e1k½{Lò²ƒ&¦*v8
òÊUÿ
+½´HÙ5#¤‰ºÁFˆ%FH#U¥362(¨«ínx±î 	ªˆàF.ÑDßÖÏØ�ºÒ�¥¡5ɸ��m *Þ¹ À.ë2ø°¤òŠƒÝ„t)ø0dY$ƒS™Ì®“	Dyغ
++úF…ÓŸ°3±
+hÇqÕR®°„ë%KôMK¢á³´ýP>ÇG¸²ìÚÖçâMÎiªÏñ¶³õÁqØÚ_‘ĶV&�myœ³žŒ|ÖB‚¸
+ä8'&éˆÉK{h,$_ÆœQ“SÛ”•«ü‰—¦áöŒª/»ÀKÒ;
+Ãêó¥6ñLæÒ‰j6}u
gA˜�°Œ„«‡‘á¶ã[§pS‰•ïÊm‚+zz=ßâÛ¬ž–ü‚ÙÚFérúÌìŸî8MnÂ¥Žõõ!”ë�S¥^ñ’ÃÕƒBÖoÂÜÿœ8ð„øœ)θ	'DnŒ8}·)áäÚL‰l“»VXÂ=|عoBÝJ
÷zÊk;	xòã¿þþ5wm?Ì4�×êXÝ.¾9¨�H1ºAß_€Ã¿±/
¶ÛŸ¿
+}ëmDÏNùmŽ›!úÒsàž%DÏ<÷}õ›ãØè÷¥*‡Ým𾚽"ðÆ@¿"RC¤Té—ÀË¡‚Gˆ
§²¬ÒÅšw?ƒŸÙF¯Æˆ—ÆCU_ÂÏÜø€~ò
+B·€ójæþYpÃÝ]KÝ‚ˆŒËùÏ~W?ÿqOÁ@¨0_k½øaüéo#q¿$.¢G@
+Nå:(¹(dWn�¿6žVŠ»ýñG¬endstream
 endobj
-871 0 obj <<
+929 0 obj <<
 /Type /Page
-/Contents 872 0 R
-/Resources 870 0 R
+/Contents 930 0 R
+/Resources 928 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 886 0 R
+/Parent 941 0 R
 >> endobj
-873 0 obj <<
-/D [871 0 R /XYZ 85.0394 794.5015 null]
+931 0 obj <<
+/D [929 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 6 0 obj <<
-/D [871 0 R /XYZ 85.0394 769.5949 null]
+/D [929 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-874 0 obj <<
-/D [871 0 R /XYZ 85.0394 582.8476 null]
+932 0 obj <<
+/D [929 0 R /XYZ 85.0394 582.8476 null]
 >> endobj
 10 0 obj <<
-/D [871 0 R /XYZ 85.0394 512.9824 null]
+/D [929 0 R /XYZ 85.0394 512.9824 null]
 >> endobj
-875 0 obj <<
-/D [871 0 R /XYZ 85.0394 474.7837 null]
+933 0 obj <<
+/D [929 0 R /XYZ 85.0394 474.7837 null]
 >> endobj
 14 0 obj <<
-/D [871 0 R /XYZ 85.0394 399.5462 null]
+/D [929 0 R /XYZ 85.0394 399.5462 null]
 >> endobj
-876 0 obj <<
-/D [871 0 R /XYZ 85.0394 363.8828 null]
+934 0 obj <<
+/D [929 0 R /XYZ 85.0394 363.8828 null]
 >> endobj
 18 0 obj <<
-/D [871 0 R /XYZ 85.0394 223.0066 null]
+/D [929 0 R /XYZ 85.0394 223.0066 null]
 >> endobj
-880 0 obj <<
-/D [871 0 R /XYZ 85.0394 190.9009 null]
+935 0 obj <<
+/D [929 0 R /XYZ 85.0394 190.9009 null]
 >> endobj
-881 0 obj <<
-/D [871 0 R /XYZ 85.0394 170.4169 null]
+936 0 obj <<
+/D [929 0 R /XYZ 85.0394 170.4169 null]
 >> endobj
-882 0 obj <<
-/D [871 0 R /XYZ 85.0394 158.4617 null]
+937 0 obj <<
+/D [929 0 R /XYZ 85.0394 158.4617 null]
 >> endobj
-870 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R /F48 885 0 R >>
+928 0 obj <<
+/Font << /F21 702 0 R /F23 726 0 R /F39 885 0 R /F41 925 0 R /F48 940 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-889 0 obj <<
-/Length 3125      
-/Filter /FlateDecode
->>
-stream
-xÚÍ]“Û¶ñý~…u3‹~öíÛ�3“sb«“i�<P"¤ã˜"’:ùò뻋]P¤„³Ý6�fî�+`
ìö'þä"Šƒ8SÙ"É 2Zl7b±‡¹¿ÝHÆY9¤Õë›õÍ_^ëd‘Y¬âÅz7Ù+
DšÊźø°”AÜÂb¹þîÕíJEbùòíwoî	¾¿û�GßÿãýúÕÿ""ñòþ=|äíJÊ8Ëo¿»ûqýêÍKÞòÍýúÝÛ—ÿvýæíýí¯ëïo^­Gª§œI¡‘äßn>ü*0øý�t–F‹ü�Ì2µ8Ü„‘¢Pk7Rݼ¿ùiÜp2k—z%%E t¬<¢RÚ'ª(b
S(ªõƒ!övMU5§²ÞÓÏmS?šz(›º§�¼»•é’‘�½)*kú¦ßve;YÐìè;¸¾ysÿrÜü!ÔþØå¸ÀÉ_¨ÊüõR¤qÄR
-h�€½t+æ[­O«D« ’ᨯpjÚIdi²Ht¶$bR×­”rÙLe¾
™­dª´^þ|«ÄDEòï‡'�|Ã,	2™á9#-ÿw(G
wñ"0%‚(‚½½î$¦àö…Qh%öÑ<�k»E�¼ƒÿÈ&K”JèDa±_—ŸÐ²c!–?—Åðð¼´ˆ�ìO..
�
-3o­»Ë+ç	Ûã
-Ë~€Ìá8XWèE>䛼7�ãêìa á~ ÐizÚ®¬wMwp¦ð“fy»ò	¿%µbÞìl~ÉåCÓ4^c=�VÔˆú#!åEÁÇ÷…l
-€ÇrkëÑt}nS@FYѨ]؇ñü	íYŸ÷j@û�(ÚÀæ¸3ŽÈ{lØN&ü µm¶ùo0.ƒØŠÔ.û¶*AÿÖÚ¢eÕ4	:¶ô�KÖЗӷÈ\�[¹|"4ZqÊ�Ê­eÍrH…î=�CÙ,ͦ™yìPk/Z2rUB êžlÆù‚Î;�=Ði½©ææ·£éJ« @¡ëWµfº­…À÷À¦ä¡µ¨,‹æ¶S[“×ö°µì!|
-
‘(¶
-ÕVx ›–ÎC™k'HX-hÊ€®V±ŠèÊá$yI„2>zæäpd¼<VW8õÌ
-|	„S»P
-B
×ó9õÅ|›4´£xx qFPB¬ßæ©kɆO’ÉiišÁ#[	%J;…ûS8„J#E9%óhº¦\8ä̾¤rvÞe(GA„š¾§®Ã?0j”óúœ>è£mdØ
-¾•“Â` nç‰p�€rÿ0h…‚ÈfÇ#äbpÓæ`àn›À·h´p(©–w¾|È’@Ž©6®lꊓŠ�ëÞÔ%DU‚O%ìÌÊ�]]Ë7¿æüƒÏ›y¼¶÷2ŸòC[ÙËD.
G‹˜-R÷�[ÃXœ®áÀ@dB0°mm^ûÜœ‚h¡uì®ã«Ùñoêmà‹çI�ÆÚ¹Æms¬
-:fc<	
µ".ÆnŽÒ0Ÿ
Pæ3P©ƒ(	åxûÉ:#ˆ0fÚ:a^xNZæÝ̬T2Rê=@‘:Gƒ.³”D50˜WK#•yD«@ÐéÃ"6„Gi×5	Ò
-Xÿ»üGAfn˜cSï]Z0—.zSá8ä]}I�R™f\æD{Üœý0¸Í4	’0Œæ^
-b5:”ÀyÈ,º¸+¤€$u9@yß7Û’C.üƸH«#™D³dŒf
-Î
-J�}¹¯¹šÛù«Í˜Û2ñLM/ :i
5
-÷&M¾d)#þjºàZK×û^ÙÊ�ÏVøË8–rFÏõÛ‚Ãú×»=ßÆ@Š³8UWmÍmŒ>v/›øª„JÓ£¯mM‡ÅŽ lÛÖZe¶â×cú Å¬Õ+Ö4a“	XQБä5|ÔíC2:Íñ�¢Ü!;­õ–OÞ˜ád°>C$_œEI¾Ò“”×qHHS9kí=³¡­-¡:½Åø—êw½ypv»ï¸)
-S™ýä-ç깇bë¤Â�ˆ;=Ÿµmê®c?Ý*؇ñù	»”åþèmÓ+ô‚¥ÿ±%:W€Ï�$üE‰
+944 0 obj <<
+/Length 3187      
+/Filter /FlateDecode
+>>
+stream
+xÚÍÛrã¶õÝ_¡Gyf…àBðÒ7g/�3oºv'Ó&y EÈæ,E2"e­÷ë{Î
EJtvۦӌ
À¹ß`µ�ð§6q¦³E’EÂJeëí…\<ÀÚ_/ìÐjõíÝÅ7ïL²ÈDëxq·�•
+™¦jqWü¼T"—p‚\Þ}÷ör¥­\¾yÿÃÕõ
�o®~àÙÛÜÞ½ý�Æ¿H+ßÜÜÂG]®”Š¹|ýÝÕ�wo?кâ#¯oî>¼ó÷×w×ïo.½ûþâíÝ€õ˜2%
¢üÛÅÏ¿ÊE
~!…ÉR»8À)T–éÅö"²FØȘ0S]Ü^üm8p´ê·ÎrJI¡M¬gX¥Í«l&bKȪ»GGämšªjeý@?×Mýäê¾lêŽ&òÝ¥J—¼ï\A£²¦oáºõ®lGš
}ûp÷×7o†Ã‘R?ìw9nü—ºr9eiœŠXIÀ:ŠDøOu&™œðô?Ûð�P
+‘Yû;Ð>	gñ0옵
+4­£…UÑQµ³‘¼’Hdi²HLº$c×¥RjÙŒy~<[©T³üéRË‘ˆNøßõÏ3ü�²Dd*Ã{\þ;ê��lñÂ0-…µpö¬†Ži°¾ÈFžcÝó¡ñº[tHû7ï"5Ú¢uB7Jý®ü„šK¹ü©,úÇ—¹EˆdrvIIp˜¿Ë.¥á4Iþà)ß•ù}åþP^�°øóò*ÎÀ?F©ý}^Iôµ–ÂÌ{ïîò*xÂv߃%ÆFÚåÏw—™^ºO=¯±OtõºjÎ|g÷Û~â]ïwùú£ë»__äè×?Š£Çóÿp¯Zf"M€å+T2cÌ8Ô�…<�¤"J
„¼äg X¥¦*&‚x8Šy1œ*3ৠ'	z;D¿7Í6â¸É·<{ûÜõn{žxÓ˜¨D OfI6Šª©Y¶û]ÛtüÃGDøö�^R½,šõ~a–æiÖúºOmEXùM|JYw}^U!rÂL^tܾýè\{zïãð#$å[·ûè*÷L3×uïvµë‘²q¤CZ˜YÌL¢IgvÙ5›þpÔ\€hAqó÷êredÂxÁô�—ï݃'‡Ïtí~*§°DÃ`³¯‹Ù“WA{¢Æ ƒÜ`ì�@fú’)­é†(ùL#ÂøâgsL_‹^
æD²‡-c“ɧbý‚«hó»1)óêc…‰GÊGGâb¤
+Á7§õÇÒíH@ëÇr�W¯p"aÙõ�8ì{ï‰
+OåÚÔ“Ûu¹'LeE³~c³ï‡ûG¸{`s<«
áïhˆŒ |Š;c÷¬&#zP�Ú¶ûôWÛR¡UB>çuU‚ô½²ÙeÕ4i´oé;嬟 /go6¨XÎ¥Z>Ó$ZqÆnAä^¯&)¤FïžÆGlæfS
Ïf´Ðˆ.F1pUBÚ=û„óÝw
+^�0ö5žy ›–îCž›ÀH0Z�”Y­bmÉäp‘œ$Ž2¾zâãpf0/+œ�r¦Cå‹rúìcÆþ2‰€�Á}Œˆg&fƒ›‹9	I‘eà&ˆÞWc›°™7z›N¥ìg¦¢<Ç
JU‘@™y”|uع9~›²¥4 €îÂØEÁÞªbP¬ñùVŠ$Õ#ź/ëYò€I¤ç´uB‡ÿA9P]u
ÍäO`þ˜¼ÒÏ
ù€-ýº¾}Íðž.T:)¤ÖéTérNÉ\›ï†P4‡ºjòâkÝ¿îß;ðP@×Å|®ñu

’öNF%GÏ\Ð
+ž‡ß>€zw��È&Q`9�EvØžìÜd–Æf,‚‚QEðúTc%b;­Ì{‚?
`AØ>äuù9\Ÿ3bLQOàŒ~¾^sÑæý›'­¡/ͯXˆ6Ra"86O>$ç˜
í8U*¶e�«OœÝ7œÑ…�>G2[¾Í½—ƒ¥º)ÜéTÀ�0SÞûhŠ—ÌðÕèLòì	cϹ	;M;²p8<$†€sÈùèêî*FÕÄ3Å
+‘ëøžúd½ÍûGšÙ©
+FD|Lá¥sÎF
+œb’©±×hš~†·
+*‹$ÎϧP
EPŠ|J¦»£4=â¬
+¾$r,
)B€š¾‡]Ù÷Ž`D§QÎûsú`üðQÆž�ð­¯p
+N1({z¦ °Ûð9<Ÿ�ÿô|‹¦G
‡joy5—«yÈ-Õ.Ô¨M]qÂsKu	ŸÆ‡jveeÏŽ®e˯ûà=Qñf³¢wÞ.
!÷)߶•7&r	89h,ŒYc¡ªØ„=Å©$NôA*ëfÛæõœ›Ó”¨&æøvrýu½s¹F"ÒØ׸nöUA×Ü»™f‰É„N’pA³ß!ž‚é€Ùœ‚*#l©ÁúI;­ÒÄD;˜³ªi£³>�˜ÎÞC™Gƒ®²”Xå9¨WK3•{B­Àa�‡lŽRÂs”g°ùwé·ÂFYØêØÔÝ«9î¢7•�B>uæÄȈT¥Ù	•9áÞíï�~Üfšˆ$ŠN²P0Ðê”ÐÑ ÜˆÁ>Æ „WÇ$`F^ð*M¦¼š£áL2¢fÒà­‡ÆÅYïÝ3ŸÈÌ@�->¬œ¢Ádò$@â71:,ëS6/‡ûpÔAáÏCŸoÄÞô%
+ï}
æ#x<<%äÉ¡s&fF‰Ð&
ÕËg8k.
ÑZ(�’bDÒùîqëŸEàÝ=Yæ1˜JbO²oŠ<V…œMa'
+®µ”OiDõŽ
+œV`/ù†FxLGC*‚ŽÐ£¥£$×¢0$zýÐÓ€¾¢ gÛ³AŒ±ôc® ÂÃþ¹
+6èÍ8‡·#çÒÈ(t&ƒ�k›UMEd&y†‹P?¢!t,éü�Q	+��õ'êû™ËI|Öž¨æÓ

j�Fƒg:0µ›¾Y7Õœs·"ÖƒCÁ#(¡2{b+$€$
Íå]׬K¹ðã"�XÉ(š%C4K¸Š�ïD8Ï�}¸Œ³	�4µ(át”�ÖN{jþð4™u1›È'�ùÇ¡ÄÖÒ‡¶–Pñ²hyÛ¤½{aäˆQ‰±´'®³Û·m³ëƒ~Íà4̆lŸ%ûܺ¹gÇðàuTØ“¹NÀßCyª

(Àü3­í4ø0i#øjÞû?;ÕwÝúøv	5“P§È`ʯ‹ãÓÏZÙÔ�8?m¤¨:�²SezΩCB3ô^|¥U8ï7ÊŠ*±dÚ|òՙठޗ5Ws›ùj3æŒJf–ƈNÚ@

+W¹‡Ñ;ÓÙS×Q3„;W4{¼kÝÔØc7>JØÇái[¨åÃ~5gë@
+½þ`J9ÿd�ÑÆÇVþ¢Ì!ûȨÀÌB�Ö?e‘úñcΗ`ùX¹žŸš¦-zXæç-@fØ:\a½ã¶Gî7žÛù¨ß•=Éȧv)½»@2wl(kz+0h´zx6�éqŸSS>u»ž�Q¶àðI¼þ˜CÍ-í‚f¡œoMoqÓâ›äÚµ|Éï…�2VDÓWÜãÒ|ññþkÿ=êø_bP*˜4Õ/øÃ[Df@
+�ž!þ�êó
y©òendstream
 endobj
-888 0 obj <<
+943 0 obj <<
 /Type /Page
-/Contents 889 0 R
-/Resources 887 0 R
+/Contents 944 0 R
+/Resources 942 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 886 0 R
-/Annots [ 896 0 R 897 0 R ]
+/Parent 941 0 R
+/Annots [ 951 0 R 952 0 R ]
 >> endobj
-896 0 obj <<
+951 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [272.8897 210.0781 329.1084 222.1378]
+/Rect [272.8897 207.1951 329.1084 219.2548]
 /Subtype /Link
 /A << /S /GoTo /D (types_of_resource_records_and_when_to_use_them) >>
 >> endobj
-897 0 obj <<
+952 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [190.6691 182.1322 249.6573 191.5418]
+/Rect [190.6691 179.6723 249.6573 189.0819]
 /Subtype /Link
 /A << /S /GoTo /D (rfcs) >>
 >> endobj
-890 0 obj <<
-/D [888 0 R /XYZ 56.6929 794.5015 null]
+945 0 obj <<
+/D [943 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-891 0 obj <<
-/D [888 0 R /XYZ 56.6929 756.8229 null]
+946 0 obj <<
+/D [943 0 R /XYZ 56.6929 756.8229 null]
 >> endobj
-892 0 obj <<
-/D [888 0 R /XYZ 56.6929 744.8677 null]
+947 0 obj <<
+/D [943 0 R /XYZ 56.6929 744.8677 null]
 >> endobj
 22 0 obj <<
-/D [888 0 R /XYZ 56.6929 649.0335 null]
+/D [943 0 R /XYZ 56.6929 651.295 null]
 >> endobj
-893 0 obj <<
-/D [888 0 R /XYZ 56.6929 609.5205 null]
+948 0 obj <<
+/D [943 0 R /XYZ 56.6929 612.4036 null]
 >> endobj
 26 0 obj <<
-/D [888 0 R /XYZ 56.6929 551.1302 null]
+/D [943 0 R /XYZ 56.6929 555.4285 null]
 >> endobj
-894 0 obj <<
-/D [888 0 R /XYZ 56.6929 525.7505 null]
+949 0 obj <<
+/D [943 0 R /XYZ 56.6929 530.6703 null]
 >> endobj
 30 0 obj <<
-/D [888 0 R /XYZ 56.6929 422.4834 null]
+/D [943 0 R /XYZ 56.6929 416.0112 null]
 >> endobj
-895 0 obj <<
-/D [888 0 R /XYZ 56.6929 395.8284 null]
+950 0 obj <<
+/D [943 0 R /XYZ 56.6929 391.253 null]
 >> endobj
 34 0 obj <<
-/D [888 0 R /XYZ 56.6929 166.2827 null]
+/D [943 0 R /XYZ 56.6929 164.815 null]
 >> endobj
-898 0 obj <<
-/D [888 0 R /XYZ 56.6929 138.253 null]
+953 0 obj <<
+/D [943 0 R /XYZ 56.6929 137.4068 null]
 >> endobj
-887 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R /F21 658 0 R >>
+942 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F39 885 0 R /F41 925 0 R /F21 702 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-903 0 obj <<
-/Length 3414      
-/Filter /FlateDecode
->>
-stream
-xÚ¥ZKsã6¾ûWè¹jÍàA
-a²¢´á¦�f²”™ËÕW„\€Ž™ ®¯Ë÷tÎ
-Bƒc34ÏõÈå‰â‘=½ r‚
öÇÇGÒ}0N:
-$¿vG"‘ÂUk"þð}O-ˆÂ´7¤›9½D¸×ð”Q½X4


-Ú½¢¤bü²êÿr…û€º–Èuüç˜â�ÙK
Šy{„°ëÐÆáäÍ0Å#÷—Ì‚² _Xy‡«4Øòǧ�Çšh>½�§Ç*x¶uÕs¿K�Á¶ÑOuÊ-~Çf->øDÄ)Ày•ZNŽ/£øLeð~È¿Qt
œOpÈëj¨¨EçÄ#é˜,¬`ÎÊ9ntáæ‹ëRÍÑO8Xð„òuÇ ‰¢¤tm}¨|Bd®@
*�4‚I îêá¥;<õ¡jÚ#GCè‰c?ÐH¯4nã5ϯôÒQ£ã‰c†é©,é›RM•…#$΃B2Ü?Ô§ù"³Ü'
ýsÝï
ï(áqór·[|+ÎðÊÔÏûRÁ]Cñüâ3ttý�=FÜÞúÊ…ï_úxÉÏÏ
JÓŠqf–³ç–ºöÕê))ªz@¸4ºW@áüù÷1�Ýá•iQ ùÜ
È@}!´úº^‚ã'T�¯:Ø
-n±=*‚«w
zŒÐx¢KìÏñ¸‹¨i{
-˜0¸†¥^!ž¥ð
-ÍÈ)´c‘Â|Fæ�æ¡f63
-O=°& wœWðdcZ*…—™¤µùiÙȸýd‰ƒ6™Ì]Ь.dJÐæ&õÅYs™©MÔ>²�W˜S·ùñMš fHÁWUOA
-fD
-_tÀ€ÌvØüM„ù¹…S &cÃQðføˆ‘€:úMÏ£Î
-4´â9§îåÌüváâ}Ï1[,ò\\ÔG	S=Ÿ^ÌÉ:ÐmZc´“1àp¨­/÷‚ã~¤Fñ_	[€ƒUÁÁÒß.¨rlõØpŸ…Ô8èm¨þ�°�·ì§_Såþpäœþå‘óß-¦ëE*ý�CŸ«g
¶ÌŒÖgeŽÑAè)�èpÅÔ%_*{ Ðå7‚¤§ºÞûÀ(Þb1AÓ!ñG¢·Âñ¦+ܪ³_Ç¥÷uÍ7kÇ=uU+
-¢ü
XÇÃÕXT
�p~ÅCê,x^®¤zç;š›ˆ|¦„§¹`õ\5mµ)"_œâ€´íÙ$X5ìÆ‹¬¦j¹Ž8Bé…D›^¿šr
-¡‚—†HÙ[�‚ÿï”(L‰Xãÿ¿ÿV5þ»,w™.
-•®piQâEpd
-�£¼(
+958 0 obj <<
+/Length 3415      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥ZKsã6¾ûWè¹jÍàA
+J$”š.º\.³/ËA*™…_ÕÏ5ŠAç ãîøˆ›ÔoÉÛéÌ‚ÖþoâFð6ñ—·'\d"`X¦Ûµ¯Dí”»@/HhBg©3¡½¡&+JNaz
+¢â¥ 486Có\�\ž(ÙÓ*'Ø`||$Ý㤣@òkw$)\µ&òçß÷Ô‚(L{Cʱ™ÑK„{
OÙåÑ‹E 
pàg`6Ž;ð’è:×€4Î"ÈÆÇ8@Yƒ67¿	¡VÇvHÙ�	ÆÇåвº}³Júí{-Äü»�wï¨Eë�÷®ÚÖ[¸ 
Òoà<Ãã;[9´ÈʱÅ"µ7ìX×pºÔ܈Ó�S¸O‚gÚÓ2´é1Ì1„ÞðÛª<¼ ?çÇJûïÛêÙ�U­WmuÞHÇëÙ7ã
~]l/¸³5x‡ÝCÊ/ª¬ˆ&ˆçÑò¢ý¾^5¯´žß„WAê‰D¶VÜ›+çÿÙÔ;¢³ÆYMžˆÒw[ž5À*.Ð]Jpä./‹3{E
j,�®º§÷—¦mIµ0HèˆèÑÞ+z
Â
+�&‘|øD`ñ�‚ZÈ
+æ<ð¡œãFn¾¸.Õý„3€O(_Çq’(J@J×Ö‡Ê'D@öç
+Ô ÒH#˜â®^ºÃQª¦=r4„ž¸P�1ö�ôjAã6^óüJ/5:ž8f˜žÊ’¾I!ÕTY8Bâ,0($ÃýC}š/2Ë}Ð?×ýðŽ7 w»Å·âüàq
+p‘æPj¶]åK]¼´ç‡3õBypÀ&؈\û`‹æ€¹‰";$×ë†ê`Ð^²
+“©Ò�3
:­Ó8˜k8�¾óšlùø¿óå	¥BÐ=&óرk„Óâ¼nÍ€¨µ� Žöu“ S=qsz†€\…nß|
€ÅtMô=M¸ª{^!ȧï×¢Q%à�)Ì	€àà
¢úþ!éœœ‹Íåè,Œ-Ï�……(œ‹�,²2^
+�”r¬¾*{êÃÂ4Òçাc¡Z¯;	·]u�‹ο0b0–9›7Œ÷13;w|rQ'èú¾Yzlq\QF‡¤A_
)â)b—×i|H£>î’àœ‹˜¿„›#ÎJ*NUF+�	•¿šâ ªúºåL²xnô'sLÑÛof2ýqÉë6;„�7Öé¥`F¤ðE|
Èl‡ÍßD˜ŸûPˆ0b26o†�	¨£ßô<ê€Ì$Íòý1J4˜DôTE‡_Ÿ‚§OFŒ»¼ÂE6ÅÉ}b`¯OµFxìë8gâ¼//	•ó—vC3ÎÔR&Z¸Ì¨<V×ÇûÙ4zÉxõâ³ñi†Éá�²'ÉêdÀ¸?_VÍ+÷•|ÖŽ‚öƒÉšÔ(ò1-ucBj‘9=VÕä4†±jtòÐ&]Gû°ì·íB^ëd¨Ýž·W$/
+,Ê,ÿJ@T&¸«j_ÿ™¾,07šÈކС¶’Ûù/¾¶r$:]iYíEE¤Q°¸ñ]b¢o¸6wCûò¯¾(ÏsU#i[•¹Ü˜ókAº§ž˜
+¾P(Å& L®©§&à™`Â稙þ˜£­á
+?6`³<söÔq¿qÁâKNÿ¢@C+žsê^ÎÌo.Þ÷³Å"ÏÅE}”0Õó©áÅœ¬ݦ5F;Ž
+—%^G¦ð8Ê‹`øûÕ%çÿ^_'kendstream
 endobj
-902 0 obj <<
+957 0 obj <<
 /Type /Page
-/Contents 903 0 R
-/Resources 901 0 R
+/Contents 958 0 R
+/Resources 956 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 886 0 R
-/Annots [ 906 0 R 907 0 R ]
+/Parent 941 0 R
+/Annots [ 961 0 R 962 0 R ]
 >> endobj
-906 0 obj <<
+961 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [519.8432 463.1122 539.579 475.1718]
 /Subtype /Link
 /A << /S /GoTo /D (diagnostic_tools) >>
 >> endobj
-907 0 obj <<
+962 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [84.0431 451.8246 133.308 463.2167]
 /Subtype /Link
 /A << /S /GoTo /D (diagnostic_tools) >>
 >> endobj
-904 0 obj <<
-/D [902 0 R /XYZ 85.0394 794.5015 null]
+959 0 obj <<
+/D [957 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 38 0 obj <<
-/D [902 0 R /XYZ 85.0394 570.5252 null]
+/D [957 0 R /XYZ 85.0394 570.5252 null]
 >> endobj
-905 0 obj <<
-/D [902 0 R /XYZ 85.0394 541.3751 null]
+960 0 obj <<
+/D [957 0 R /XYZ 85.0394 541.3751 null]
 >> endobj
 42 0 obj <<
-/D [902 0 R /XYZ 85.0394 434.1868 null]
+/D [957 0 R /XYZ 85.0394 434.1868 null]
 >> endobj
-908 0 obj <<
-/D [902 0 R /XYZ 85.0394 406.5769 null]
+963 0 obj <<
+/D [957 0 R /XYZ 85.0394 406.5769 null]
 >> endobj
 46 0 obj <<
-/D [902 0 R /XYZ 85.0394 301.1559 null]
+/D [957 0 R /XYZ 85.0394 301.1559 null]
 >> endobj
-909 0 obj <<
-/D [902 0 R /XYZ 85.0394 276.6843 null]
+964 0 obj <<
+/D [957 0 R /XYZ 85.0394 276.6843 null]
 >> endobj
 50 0 obj <<
-/D [902 0 R /XYZ 85.0394 200.1512 null]
+/D [957 0 R /XYZ 85.0394 200.1512 null]
 >> endobj
-910 0 obj <<
-/D [902 0 R /XYZ 85.0394 175.6796 null]
+965 0 obj <<
+/D [957 0 R /XYZ 85.0394 175.6796 null]
 >> endobj
-901 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R /F21 658 0 R >>
+956 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F39 885 0 R /F41 925 0 R /F21 702 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-914 0 obj <<
+969 0 obj <<
 /Length 2458      
 /Filter /FlateDecode
 >>
 stream
 xڥ˒ã¶ñ>_¡[4Uš
-Yþýî×ßÂU	üù.TžÅ«LÂ@ä¹\5wQ¬‚8RÊCê»ç»Œg«n뢤DH•ÈQIµ$ª8K(ªwp9®‹®ý†òe8j[u-
O{s¼ÙÚÐÔîyp8V�>žiÒèÞš÷æøêÇ•íM½ãqO_ÍhÖèÚîö0^·³†y væHƒ’Yé˜ Û <á¯RFûª,a3(¤zò8–îªÌ6"
z]_ô«âhý¹5´<ô<ØuÈ_ƒ‡·[	H‹1Ê�!$2
-ëÖòT„
-‚>a·£ßÑÉå£-}ùÞý©àÓA"U¾x¬Û\wÝ·á°dý)^Üï¤`êðIxåº2­í6ð0
-¢,‚Ì&Ò W2%ÿ¿Ïåô£’l]5ÞÇ
rϸn&
™òšAÜÕs¨q;
-G·{¦Â
-jÛÓ
-ú.X�êïè÷�/Ž�'·Ÿ+`cÚ¸˜‰F¿r¤rrÙ(œóíl–(ÊG¡ã™¼¡cp€IÕZÈ/–?r鼿3ÎA"Á6�wÕ«€½0UohN`K½UnP*yí"¯Æ“2çâoÒ-ÆAžÇÙ•ãÌó›¯0ÕõÞgúsÛµç¦z�†€â U07'*fÒumÚªERR�aò*Y+Nûª`,M%Ü’`�>…­™#Y]µ†Qª–¾Ö3À–ˆ»èüñ„IP0a×…ÑT1¥\1e¨pKFå‚Ç‚ÍmÏW)}sÇëªgä^8þeôi¬‰7›_¨&&@(Mí£SßwEfW^×
F<òAspƒÂÌ¡^vS)q‘ý!Ï	1«è¡°àZâ§îxÒÇeó?놯d"	ÅÜd&U˜ø€˜ÌBqº.;ç–¸ÞYôV¨2¨HJf9&,Ô««Cm,Ïn¢d„ÆT"c¦�ù”Ñt‡ñY)Ÿn—ªì|ÒhŠ¯(›¥T
-�i�â;.Pw…°s7¨ì@Va$ê÷´DF…Þ˜óY€GZF£éKõê‰÷•]ÌÝÎ\‰)ZˆÂÒì²ÖEC•(_=HyrZ~DŠ­áefkŠ(Å6Ýá’P£0-$æçÔ
—‰µWìDh¢‰‰vh¶d¹×"o�èB­#®bê<‰&dg°¬[Ìx†ÙeÇêÞKÔØá¹}¾#Elr|¨¶uÏ«]|3–ϲ{ŠÃËÞ¡ýQcLÖÇÂ�JÍý
’<_±Z0F~tmŒ0Öºå’ñ+‹áE%\�!¥yNb<[:·;_�6IÁÔ~�Lô¥ÊO½U>Nšš÷ÿþÂÁÌ· ®CO8«Þ6åÔp…õ	êâêàŸ¾tµùÓ]{®x|zO#ßzͺŸ4dq#°jà Ý*à MïD7ÃE­SzHJgoO0¦J
	tžþ ”b„[@X¬õ«¹ÚÀiçfG»XGM	ƒ»µÙ³–K9*œæ�ÞØ�] õõì·FW5ìÇîd¦ÌI蓹õȹäW9œ6´6¬=M�»Ã:·Þ¾ËÆ%ÒŽ�Ûªà	9=lá»~Ý[½µUÌŸR®åXw/c|ÏpÛA¡”Ä‹I¥EÆ©#Í}¥� ]¾êÖê4‚¸@’bÿ–A€aØÞ44êÚË×ëWw/ãbmž»X›…ÎÓ—bgëŸf�NÎF“k
Ï_’IJF³Y®ìB©ü»ÑÅwöB³i–§¾Ês—`3„£ØÍ’QVäº=MnºOX,«C6¦ˆU¤Ì.ãíÔ�SѦÈ/1•ÞVueÏ$SBCÅCL
ÚCaå.§DãZFÎàK)I]Ù/€œ_Ñ1|žóç«£Ig8ºÐÙ‚v¯Ë÷<šé-W”Iòé]	@ì®wz]ª+chft¶ýð[
-ä4	Õ’BánUàhjU
-
e*Ñ�²€Ç,EJ¡¼Mq	9jÕäå/œÆGi²5—Žøy©Ö…¯¿«vzOÖSo9¯ÞøoÒþ!²ðOH8&ºÿû—éï§(
T–Éå¿TðA8Ê€3åRjxùÿƒæ–õÿ÷Å:êendstream
+Yþýî×ßÂU	üù.TžÅ«LÂ@ä¹\5wQ¬‚8RÊCê»ç»Œg«n뢤DH•ÈQIµ$ª8K(ªwp9®‹®ý†òe8j[u-
O{s¼ÙÚÐÔîyp8V�>žiÒèÞš÷æøêÇ•íM½ãqO_ÍhÖèÚîö0^·³†y væHƒ’Yé˜ Û <á¯RFûª,a3(¤zò8–îªÌ6"
z]_ô«âhý¹5´<ô<ØuÈ_ƒ‡·[	H‹1Ê�!$2
+…>°®Á€º}á’`
2™#Xô
++x¨mO+èG¸`=ª¿£ßw¾8tž@Ü~®€�iãb&ýÊy�ÊÉe£pη³-X¢(…Žgò.„ŽÁ
&Uk!¿X2üÈ¥óüÎ8‰Û0,@ÞYT¯öÂT½¡]8�-õV¹I@©äµ‹¼.OÈXxœ‹k¼I´ygWŽ3Ïo¾NÀT×{ŸéÏmמ›nèAŠƒ`TÁÜœ¨˜I×µi_¨II	@„É«d­08í«‚±4}XH”pK‚5úL¶fŽduÕF©ZúZÏ
+3‡zÙM¥ÄEö‡<'Ĭ¢‡Â‚k‰ŸºãIK”Íÿ¬>¼’‰$s“™Taâb2Åéºìœ[âzgy`Ð[¡Ê ")™å˜°P¬®µ±<»‰’	GS‰Œ™BæSF[ÐÆg¥@|º]ªJ°óI£)¾¢l–R
HE„cñÒáÍ‘*š8~±È$
+K³ËZ!U¢|õ },ä-T\Èiù)¶†—™M¬)¢Ût‡KBaŒÂ´�˜ŸS7`\&Ö^±¡‰&&Ú¡Ù’å^_ˆ¼=¢µŽ¸Š©/@ð$.˜��Á²n	0ãf—«{/Qc‡çöùŽ±Éñ¡ÚÖ=¯tñÍX>Ëî)z/{0„öG�1YC*5÷Hò|ÅjAÀùеa0ÂXë–KƯ,†•p=†”Fä9‰ñléÜî|uÚ$1Sû52Ñ”*?õVù8ijÞC@üû3ß‚ü¹=á¬zÛ”SsÀÖ'¨‹«ƒNøÒÕæOwíi¸þáñé=�|ë5ë~Ò�Å�Àª�ƒtk¨€ƒ6¼Ý]´Né!)�½=Á˜*5$Ðyúÿ�PŠrl
a±Ö¯æj§�›íb5%îÖfÏX.]äü©pšwzc4v�Ö׳Ü]Õ°»“™2_$¡OæÖ#ç’_åpÚÐØ°ö4uîëÜzû.—H38Bn«‚'äô°…ïúýuoõÖV1J¹–cݽŒñ=Ãm}„R/"$•§Ž4÷•>‚tùª[«_Ð@âIŠý[
†a{ÓШk/O \¯\iܽŒ‹µyîbm^`8O_Š�­j˜=:9M®<uH&)!Íf¹²E ¤òïFÜÙÍv¤Yžú*Ï]‚ÍŽb7KFY!�ëö4¹é>a±¬zÙ\˜"T‘2»Œ·SCNE˜"¿ÄTz[Õ•=�L	
A05h1„u”»œd�kM9C€/¥x$ue¿
+…3¸U�£©U
Pk\‘;cpËÜÓ…à8~*”©DGÊR
 endobj
-913 0 obj <<
+968 0 obj <<
 /Type /Page
-/Contents 914 0 R
-/Resources 912 0 R
+/Contents 969 0 R
+/Resources 967 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 886 0 R
+/Parent 941 0 R
 >> endobj
-915 0 obj <<
-/D [913 0 R /XYZ 56.6929 794.5015 null]
+970 0 obj <<
+/D [968 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 54 0 obj <<
-/D [913 0 R /XYZ 56.6929 717.7272 null]
+/D [968 0 R /XYZ 56.6929 717.7272 null]
 >> endobj
-916 0 obj <<
-/D [913 0 R /XYZ 56.6929 690.4227 null]
+971 0 obj <<
+/D [968 0 R /XYZ 56.6929 690.4227 null]
 >> endobj
 58 0 obj <<
-/D [913 0 R /XYZ 56.6929 550.0786 null]
+/D [968 0 R /XYZ 56.6929 550.0786 null]
 >> endobj
-917 0 obj <<
-/D [913 0 R /XYZ 56.6929 525.2967 null]
+972 0 obj <<
+/D [968 0 R /XYZ 56.6929 525.2967 null]
 >> endobj
 62 0 obj <<
-/D [913 0 R /XYZ 56.6929 393.0502 null]
+/D [968 0 R /XYZ 56.6929 393.0502 null]
 >> endobj
-918 0 obj <<
-/D [913 0 R /XYZ 56.6929 363.1913 null]
+973 0 obj <<
+/D [968 0 R /XYZ 56.6929 363.1913 null]
 >> endobj
-912 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F47 879 0 R >>
+967 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F39 885 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-921 0 obj <<
+976 0 obj <<
 /Length 2095      
 /Filter /FlateDecode
 >>
@@ -2716,212 +2878,214 @@ fhWü(½¾YhovçåvlŒ25©,*Yݳ÷›¦¿ªîÄqˆ�jØ|SüÍ‚Ø{©uÏ•cq�À]#Xg±¬,ÕI’Êøߨ	´8Í
 dXõcsý.Û~¸ý¿ Šç•‰×:%<ä7IE”èÚ–Ø’ª2yÑT
 hZvýxªY/ý‘áÝN6“dy 8xp]Óc~{î0¨”~‚’$¡½„3×|Ó$ý$ÈR¸2Æ/{ë³ý4±ò�Õc¯ÕW¹aµ¤ôó,ÎXT¦JP¶Ø¶ÖVDÙ6
 ^AÁ³"r�
-DŽ49œvDü¹„šný~¹� æÒû/å¢õ>ÉÃP©_¬MËZç¹—ù
+DŽ49œvDü¹„šný~¹� æÒû/å¢õ>ÉÃP©_¬MËZç¹—ù
 ÜѸU‚>Gy%â*哦�tð–RW8
 Ÿ¤IhsÜ]W‰y
 Õmíš™Q‘‚z
-â~ó
¯	fÙ"‡èâ9Lt¨ž¹£j¡	mK(ÈÏbµ
+â~ó
¯	fÙ"‡èâ9Lt¨ž¹£j¡	mK(ÈÏbµ
 endobj
-920 0 obj <<
+975 0 obj <<
 /Type /Page
-/Contents 921 0 R
-/Resources 919 0 R
+/Contents 976 0 R
+/Resources 974 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 886 0 R
-/Annots [ 927 0 R 928 0 R ]
+/Parent 941 0 R
+/Annots [ 982 0 R 983 0 R ]
 >> endobj
-927 0 obj <<
+982 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [519.8432 268.1131 539.579 280.1727]
 /Subtype /Link
 /A << /S /GoTo /D (acache) >>
 >> endobj
-928 0 obj <<
+983 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [84.0431 256.1579 143.5361 268.2175]
 /Subtype /Link
 /A << /S /GoTo /D (acache) >>
 >> endobj
-922 0 obj <<
-/D [920 0 R /XYZ 85.0394 794.5015 null]
+977 0 obj <<
+/D [975 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 66 0 obj <<
-/D [920 0 R /XYZ 85.0394 769.5949 null]
+/D [975 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-923 0 obj <<
-/D [920 0 R /XYZ 85.0394 574.3444 null]
+978 0 obj <<
+/D [975 0 R /XYZ 85.0394 574.3444 null]
 >> endobj
 70 0 obj <<
-/D [920 0 R /XYZ 85.0394 574.3444 null]
+/D [975 0 R /XYZ 85.0394 574.3444 null]
 >> endobj
-924 0 obj <<
-/D [920 0 R /XYZ 85.0394 540.5052 null]
+979 0 obj <<
+/D [975 0 R /XYZ 85.0394 540.5052 null]
 >> endobj
 74 0 obj <<
-/D [920 0 R /XYZ 85.0394 447.7637 null]
+/D [975 0 R /XYZ 85.0394 447.7637 null]
 >> endobj
-925 0 obj <<
-/D [920 0 R /XYZ 85.0394 410.3389 null]
+980 0 obj <<
+/D [975 0 R /XYZ 85.0394 410.3389 null]
 >> endobj
 78 0 obj <<
-/D [920 0 R /XYZ 85.0394 348.7624 null]
+/D [975 0 R /XYZ 85.0394 348.7624 null]
 >> endobj
-926 0 obj <<
-/D [920 0 R /XYZ 85.0394 311.223 null]
+981 0 obj <<
+/D [975 0 R /XYZ 85.0394 311.223 null]
 >> endobj
 82 0 obj <<
-/D [920 0 R /XYZ 85.0394 189.9853 null]
+/D [975 0 R /XYZ 85.0394 189.9853 null]
 >> endobj
-929 0 obj <<
-/D [920 0 R /XYZ 85.0394 156.0037 null]
+984 0 obj <<
+/D [975 0 R /XYZ 85.0394 156.0037 null]
 >> endobj
-919 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R >>
+974 0 obj <<
+/Font << /F21 702 0 R /F23 726 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-933 0 obj <<
-/Length 608       
+988 0 obj <<
+/Length 605       
 /Filter /FlateDecode
 >>
 stream
-xÚ¥TKs›0¾ó+8Š™ ê�@:&I�'ài;iŽ‘S¦¹<’æßW aÓÆ9uFûüv÷v‘~°ËB
-"ÜH�!ÌÜÍÎAî³ö];ØÆøc�?�ºÈœOW4r!	Ýl;ÁâqŽÝ,
-@6¿½6¦ô[šÅ‹Ôó©0˜}>_fqb\Ä]Ìom~§w«d�ÚýjžÄ‹ø6K½ÇìƉ³ÃÓ91¢ý
+xÚ¥TËr›0ÝóZŠ™¢ê�Œ´Ìƒ¤îŒÇài;iŽQ¦QIó÷HÄ$qW†A÷utî‘.`óÀgh&©‘Ç„ƒÝÞÃàÁÄ.=âr‚1)˜f�¦Þç
‰äŒÎ@z?ÁA@šÝ@Š8ò
†ÉfµºZû,‚i|î”cxµŠ×'~Ât¾¼´®äG’ƋĘ	<ûr²Jãµ
Qt:_ºúuœ\mÖgñh]oæëx/ÓÄ¿M¿zqúÚôO‚YßÀoïæƒÌ´ûÕÈIÁÁ³10"RR°÷BÎ=…—xׯ€“èPzT7‚e3zD8J
+4‹$
+ó}å*!²á]�ÖÑUA«ƒlÛ*kyÓÚË54<ªàmgvd¦gíTúä,¥ì¢}Tã�?9_¸ûÿcZ8^¾Klue…zR…]fù •Úµº~±®�Û´î0lÒqÐÝPµS#HÓÖù]ךÃ@ÿ;ÆQ?+G†Ä¼îPÿ{$ÿ©0BLz˜¶éTÐH PGª—œÐÌÇÙýHý/š�@endstream
 endobj
-932 0 obj <<
+987 0 obj <<
 /Type /Page
-/Contents 933 0 R
-/Resources 931 0 R
+/Contents 988 0 R
+/Resources 986 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 886 0 R
+/Parent 941 0 R
 >> endobj
-934 0 obj <<
-/D [932 0 R /XYZ 56.6929 794.5015 null]
+989 0 obj <<
+/D [987 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 86 0 obj <<
-/D [932 0 R /XYZ 56.6929 769.5949 null]
+/D [987 0 R /XYZ 56.6929 769.5949 null]
 >> endobj
-935 0 obj <<
-/D [932 0 R /XYZ 56.6929 744.7247 null]
+990 0 obj <<
+/D [987 0 R /XYZ 56.6929 744.7247 null]
 >> endobj
-931 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R >>
+986 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-938 0 obj <<
+993 0 obj <<
 /Length 1222      
 /Filter /FlateDecode
 >>
 stream
 xÚÍWI�ãD¾÷¯ˆúäH¸âZ¼©OÍ°‰Hs`8Tìrb�SeìrBƒæ¿ójs6sà
-©Ç¥·†EòS€Š2Of=§&ü¡W.tÀLFXôÚyÉß'1´¦÷fÓ¸<Žn§&=Z|KÁµ½áDnãÖ
[;ÑiteL-dçÞ^z@3Š Ñr0¡sSùØò¶Ð°´@EžQ/ëph‘@#†I¨„ƒÜkg+¡Û“€:cŒ£¯&L0À3LDc‚o`Â=æÕÔÕn¹ó"¦iâ$ü©ÏÍZ™Z}!W‰37µu£VDS' Ðò‡4A¤L\û6è@{{VnZ&ÜvœvR˜ò›ÍÙžÛñàVÚkÙRºåÜX³iuD·°qÅâUwñwñð—{à’ œˆ¡dCØËía~}øée	”®[³M#AJTyy+W·´@Aÿ­äóFèjc†£Þ=æ0Tè½>Ú˜ÍEq)·+\]gR½
=^Œl9¯ËσØÚ»Ç
-ÿ¨2ûù@[ –¤('ðVt„(þ°	F—7¯€ÑK‚sTRRx;Ö›#<鹎{žëøIÜý7¸Pé´«Õqþ›ð™˜1t6Ihb–{â^Ž­(áÏ!½Žm‰CÁe
-5€B=—âÿëÄæ�/n¸GÂä^xÞ`W>¾QAF?°9¯ª™Ù;ëƒû9âãòíÊwÁ®|»�0«ðœIª
Ÿ:½äÊ0
£•0ö1¦ÿ˜SM™^ÿ^r0m%©ßÑ1¡¨Ä	ûOèøéÛíü•¾]hŠÌ—ÐÒwP‰/2î#èñ4ÉPAÊ<2yazïmþ¤zt÷7¯Ì™øendstream
+©Ç¥·†EòS€Š2Of=§&ü¡W.tÀLFXôÚyÉß'1´¦÷fÓ¸<Žn§&=Z|KÁµ½áDnãÖ
[;ÑiteL-dçÞ^z@3Š Ñr0¡sSùØò¶Ð°´@EžQ/ëph‘@#†I¨„ƒÜkg+¡Û“€:cŒ£¯&L0À3LDc‚o`Â=æÕÔÕn¹ó"¦iâ$ü©ÏÍZ™Z}!W‰37µu£VDS' 0|‹Cš R&®}›
ô ½=+·-n;N;)LùÍæìÏíxp+íµl)Ýrn¬Ù4ƒ:¢[ظbñª»ø»xøË=pIÎ
+ÄP²!ìåö0¿>üô²J×­Ù¦‘ %*Š¼¼•«Û
Z  ÿVòy#tµ1ÃQïž�s*ô^
mÌ梸”Û®®³
+©Þ†/F¶œWˆåçÁ¿
líÝc
+q/ÇV”ðç�^Ƕġà2…¿@¡žKñÿ‹ubóÆ7Ü#ar/¼o°+ߨ £ØœWÕL
�ì�õ…Áýñqùvå»`W¾Ý@˜UxÎ$U‹†O�^re˜†ÑŽJûÓÌ©¿¦L¯
+/9ƒ¶‹Ô�ïè˜PTâ„ý'tüôívþÊ	ß.4EæKhé;(ˆÄ÷t�xšd¨ e™¼0½÷6R=ºû*Š™Üendstream
 endobj
-937 0 obj <<
+992 0 obj <<
 /Type /Page
-/Contents 938 0 R
-/Resources 936 0 R
+/Contents 993 0 R
+/Resources 991 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 944 0 R
+/Parent 999 0 R
 >> endobj
-939 0 obj <<
-/D [937 0 R /XYZ 85.0394 794.5015 null]
+994 0 obj <<
+/D [992 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 90 0 obj <<
-/D [937 0 R /XYZ 85.0394 769.5949 null]
+/D [992 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-940 0 obj <<
-/D [937 0 R /XYZ 85.0394 575.896 null]
+995 0 obj <<
+/D [992 0 R /XYZ 85.0394 575.896 null]
 >> endobj
 94 0 obj <<
-/D [937 0 R /XYZ 85.0394 529.2011 null]
+/D [992 0 R /XYZ 85.0394 529.2011 null]
 >> endobj
-941 0 obj <<
-/D [937 0 R /XYZ 85.0394 492.9468 null]
+996 0 obj <<
+/D [992 0 R /XYZ 85.0394 492.9468 null]
 >> endobj
 98 0 obj <<
-/D [937 0 R /XYZ 85.0394 492.9468 null]
+/D [992 0 R /XYZ 85.0394 492.9468 null]
 >> endobj
-942 0 obj <<
-/D [937 0 R /XYZ 85.0394 466.0581 null]
+997 0 obj <<
+/D [992 0 R /XYZ 85.0394 466.0581 null]
 >> endobj
 102 0 obj <<
-/D [937 0 R /XYZ 85.0394 237.1121 null]
+/D [992 0 R /XYZ 85.0394 237.1121 null]
 >> endobj
-943 0 obj <<
-/D [937 0 R /XYZ 85.0394 206.4074 null]
+998 0 obj <<
+/D [992 0 R /XYZ 85.0394 206.4074 null]
 >> endobj
-936 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
+991 0 obj <<
+/Font << /F21 702 0 R /F23 726 0 R /F41 925 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-947 0 obj <<
-/Length 1859      
+1002 0 obj <<
+/Length 1860      
 /Filter /FlateDecode
 >>
 stream
-xÚÍËrÛ6ð®¯àøDÍD0^$ÁæäÄvêL⸲RO'Í�"!‹>’²êvúï]<HQ2e»­gÚá
`±Ø]ì“ÄÁðÇó‘ÒÐ	BŽ<L<'ÎGع…½w#bq&-Ò¤�õf6:>g�¢Ð§¾3[ôh	„… Î,ùâ2ÄÐ(`÷òäãÙxB=ì^ŸMÇžçþƒžº:›žŒîÎ.>]^�'
¹ûöÇ“«Y‹ñ4�·Ÿ.Ï/Þ}ÞÒ�½�Í:)ú’Ì”ßG_¾b'
�ß�0b¡ðœ
L0"aH�|Ä=†<ÎX»’�®G?u{»úè æF”ùtHuá�ê¼ùŒ2­ºßËBŽ'>ÆîFÀ
PZL¢$©PT­¢#³÷‡Ô¡!"€'"…žG5�æ~e	äQÝÈêµFÅ»H‹4koÉÊ8Ê–eÝ JÞía›ç,Ê&]Üü¢4(“ÁËÿ¼íøØœ½±wF•šå«®eu׋Òò·(_eÅe>ÄaOk=Ì—WV�8JæÃÚj¥½¸²ÒÂÛɺ–µ™–+fÝɾÄv?ʲr#« ÒŽUTÔù”2¿šÂd÷È#: !EÄ<„
-Ô"xÈcÏxüçYyÜ2¢JÚ7‹â=¡�¾iìbÿóÐŒŠÐ·Ž]úhþíèQس�]ûØí�ŸÐ7Xu+žz¯L_›¥ïEzïu|N‰C8b„,¸È£ˆ’Іy:ž¤>”QbBò›(‹Š8-níqÖxpš
-ä¡	u'ã	ž»ªÒ<mRõÎj
-o›HiB�™&® yG\O㨰ëöl/Sy'-vjwu”QÀ©Ê3ÿތ뺣•¯³&]e³áʸÔcR›Å_±‡ëu¼´wÕƒªïÈ(eœ˜a�Ð!fCÛ±´�* ˆr‰:Â

-
4ás�*Xëü¯`R7]¨UîÞ—câ®
¼Ô>£p›¥¹Zš�››³Þ5Ù¤ÍÒì²Ù”Õ7³¬ŒR6¡Kí—³ETf‚Üdy°SjωÁ¶ËìÕ`Œ%bŒ4Ðo
ãCÅ+,£t€"½Ò>),,JìÌ+Â4—ôØ,#K;ÎRY4vy“f™].‹BÆGZ5ʨ½*WÆTØkÊh–©aÍðѲ­ø�²IsùÃ~M@Ú0u˜Oó9yVQB ìBì%ÿìTËG/ŽäÀœÃ@Ë‚­t»¤&­LÆCÄqØ<;þ/ÂÜgƒ†ž¯ut	?žpÁˆ;›}PøîÛ'×ÊWy@ÝÙ/WPþqB}w*ër­õ[™v¶bæÊG§Ó­‡�FM´ÿ
-ß×
-ÞƲƒZéÝ÷²ZyQ7$ºMñžÒ
-dŠx¦VØa­ôî{)­l;¬ÿ":RL� 8b ¸À¸AÛê=hùh
-€¬SËþ‘.oBff¾ï¾¹¸<5û6íµ˜e5²#’ÛÛUæîÝ¿*Û�
î–Ÿû–²*ÚÝ�ùAJ§A¨k35FfH Ž�]Õ®(ä¢Q%”E挄ڦR->‚‹Bá^ØÚؚȒœ—wº<Á6õ«
£Ak””yvog†A©KÐÞÂ0ÇÝ¥-s•á•Ö9ô•ý—ñÚŒÝÜŽÄ®›ª©¿aGªd&ØýºYÙÊ+@ëÚ¦Dà΅˜Ví©]™úkͺ*d²ÇF’ÖqÔÇí¨Zãhº*•BÃÑ«RÁrs‘4³D6Qš¸Tzät«>]¼Ñ³ƒŠS‰Ï¡Ä_ªÇ�¿kaº+Ù:%D!â3ÚÞ*¨*'e•˜æhß1ò|Á,n½ž×Êrcrp…~æƒW	h_0åöt¹jR`và检ᖣî
--”ªzå¡U$äÈ×™ÀìT·Ž
¦C¿æ¶Ø‡C�ÅQ|L§ºÞÖßúÚßã…@ŠczÌ<xΣ<ìSRL ¡¾r�©ï¡~ž!_´ý�hûKS$ê_€ö7€b%«¨ÿ¤Ë*¦Ûd~÷O’Xr³1!Ä-ˬÞëÃ>·Nt3f�k£¾ñóqÉÌz¸á…™g‹Î–©îBB°€Xñm&‰¬ã*�ëðŽì
á(3{i
ž¸’EÍuoªÐÓ趀h�Æ*ÊSÕ©åi‘Ö�ÒÅ�E2±
+xÚÍËrÛ6ð®¯àøDÍD0^$ÁæäÄvêL⸲RO'Í�"!‹>’²êvúï]<HQ2e»­gÚá
`±Ø]ì“ÄÁðÇó‘ÒÐ	BŽ<L<'ÎGع…½w#bq&-Ò¤�õf6:>g�¢Ð§¾3[ôh	„… Î,ùâ2ÄÐ(`÷òäãÙxB=ì^ŸMÇžçþƒžº:›žŒîÎ.>]^�'
¹ûöÇ“«Y‹ñ4�·Ÿ.Ï/Þ}ÞÒ�½�Í:)ú’Ì”ßG_¾b'
�ß�0b¡ðœ
L0"aH�|Ä=†<ÎX»’�®G?u{»úè æF”ùt@uœ©Î‘Ï(Óªû½,äxâcìa,Ð
+EÕ*:2{(A"!x"BPèyThîW–@Õ�¬^kT¼‹´H³ö–¬Œ£lYÖ
ªäÝѶy΢lÒŽÁ/Jƒ2¼üÏÁÛŽ�ÍÙ{gTY Yî°jàZVw-¼(- ‹òU&Q\æCö´ÖÃ|yeõˆ£d>¬­VÚ‹++-¼�¬kY›i¹°bfÑ�ìKl÷£,+72±
+*íXEE½�O)Ãð«)Lv�<¢RD|�ÀCø @-‚‡<öŒÇže�Ç-#: ¤}³(nÑÚè›Æ.öß1ÍÈ }ëØ¥�æߎõ‡=Ùµ�}ÑùÉ
+šwÄõ4Ž
+»nÏFñ2•wÒb§vWGœª<£ñï͸®;Zù:kÒUf1«1®ŒK=&µYü{¸^ÇK{W=¨úŽŒRƉö¨
b6´+@Û¨Š(—¨# �Ñ@>ר‚µÎÿ
+f!uÓ…Zåî}9&îÚÀKí3
+·Yš«¥Ù¸¹¹1ë]ÀQ“MÚ,Í~!›MY}3ËÊ(õaºÔ~¹0[De&ÈM–;¥ö\‘l»Ì^
Æ(P"æÀHc
+g:+Â`ón™é‚W­|_Ë*UiXMtÕ 
+n9ê®ÐB©ªWúQEBŽ|�	ÌNuë`:ôkn‹}8ÔXÅÇtªëmý÷­¯ý=^¤8æñ Ç̃€×á<ÊÃ>%Åê+'Йú>êçòE@Û߈¶¿4E¢þhh!V²ŠúO@º¬bºMæ
1áwÿ$‰%7BܲÌê½>ìsëD7c¸¦1êÿ0§‘ÌÁ¬‡^˜yö·èl™ê.$ˆßf’È:®Ò¹ïXÀŽ2³—à‰+YÔÑ\÷¦
+=�nˆi¬¢<U�ZžiÝ(]ÜY$Ë

 endobj
-946 0 obj <<
+1001 0 obj <<
 /Type /Page
-/Contents 947 0 R
-/Resources 945 0 R
+/Contents 1002 0 R
+/Resources 1000 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 944 0 R
-/Annots [ 952 0 R ]
+/Parent 999 0 R
+/Annots [ 1007 0 R ]
 >> endobj
-952 0 obj <<
+1007 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [55.6967 190.8043 126.3509 202.8639]
 /Subtype /Link
 /A << /S /GoTo /D (rrset_ordering) >>
 >> endobj
-948 0 obj <<
-/D [946 0 R /XYZ 56.6929 794.5015 null]
+1003 0 obj <<
+/D [1001 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 106 0 obj <<
-/D [946 0 R /XYZ 56.6929 480.2651 null]
+/D [1001 0 R /XYZ 56.6929 480.2651 null]
 >> endobj
-949 0 obj <<
-/D [946 0 R /XYZ 56.6929 441.7923 null]
+1004 0 obj <<
+/D [1001 0 R /XYZ 56.6929 441.7923 null]
 >> endobj
-950 0 obj <<
-/D [946 0 R /XYZ 56.6929 373.7178 null]
+1005 0 obj <<
+/D [1001 0 R /XYZ 56.6929 373.7178 null]
 >> endobj
-951 0 obj <<
-/D [946 0 R /XYZ 56.6929 361.7627 null]
+1006 0 obj <<
+/D [1001 0 R /XYZ 56.6929 361.7627 null]
 >> endobj
 110 0 obj <<
-/D [946 0 R /XYZ 56.6929 167.4388 null]
+/D [1001 0 R /XYZ 56.6929 167.4388 null]
 >> endobj
-953 0 obj <<
-/D [946 0 R /XYZ 56.6929 126.8733 null]
+1008 0 obj <<
+/D [1001 0 R /XYZ 56.6929 126.8733 null]
 >> endobj
 114 0 obj <<
-/D [946 0 R /XYZ 56.6929 126.8733 null]
+/D [1001 0 R /XYZ 56.6929 126.8733 null]
 >> endobj
-954 0 obj <<
-/D [946 0 R /XYZ 56.6929 98.4089 null]
+1009 0 obj <<
+/D [1001 0 R /XYZ 56.6929 98.4089 null]
 >> endobj
-945 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F21 658 0 R /F23 682 0 R >>
+1000 0 obj <<
+/Font << /F37 791 0 R /F41 925 0 R /F21 702 0 R /F23 726 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-958 0 obj <<
-/Length 2706      
+1013 0 obj <<
+/Length 2705      
 /Filter /FlateDecode
 >>
 stream
@@ -2929,207 +3093,216 @@ xÚÕZÝsÛ¸÷_¡—NåéÅA°O—Ë%×ÜÌ%×ÄiÒÌ”– ‰w©);Îô�ïÀ$EJÎø©ã
àò·ËÅ~f3
 l¦SBE.gY.IJY:[ì®èl
Ï~ºbž&	DI—ꇛ«¿¾Ù,'¹âjv³ê`iBµf³›å§ùË¿¿øõæÕû넧t.Èu’*:ûâ—W¸ò
¥éüŸ�âå»·¯ßüôñý‹ëLÎoÞ¼{{�d4—ðæåwßýúêñ½ןo~¾zu¿¢û¥Œ
 û	\}úLgKøàŸ¯(¹Ng÷0¡„å9Ÿí®d*H*…+Û«Wÿˆ€�§îÕ1Í¥B“TólDuœ�©.͉\8ÕÙof„]'ŒR:ÿ±,ÖUÝ´å¿öæš16¯ëmc¿ðD�ήHγÜ!ÝlŒ'ê2e9¡)³²Zše¹
b’äRhOóÝŠ$Z$Ø€€c(9*ã%á’Í‹j9Çaw¸–ž´j¶uýûq?‚)SÐ>Ë<áþpÍô¼^Š]ðBÏ·bì$ŸÛ-®.êÝÎ2v“mYµN�ŽtUp
èŽðÞÎþ8šÃCY­qV;�ܘÃ�94ÄJ8KÏ@ëvž1’§)êÀM[–++ÕÊp^VøÛ´[ƒC”õ±Ý[ƒP»¢%'6MaÁÑ”ÎÁ¸r6(éRM›`¤êE—g¯hÁÏóD#<{vAÁ¼”LûL­µ&œfóe½+œ†¨M¡ʺ‡kÜñ½S%ÌÿMS:fäR°6ñ
VH1Ë™·A¢�µo7²›Ò¸]
 Ü5XÛoMëéëUhü’7h7vfq�çjþÆoŠÆÛR
-’S¡ú¶ÔÞ×׉ DYšæo׉d|Þ”–)®—UkÅ¢-ïÌ#!Žœiˆ%ΰçðš³oRÀ=“øEöÉmÑ.6C¨ûMͳ8¶¦ÁYÑ…³ßAûò£{�I›Ât� ÀŸmÙx«wÚ³Þa@ÛÅ'ˆì)+cÕ'�¿Øž>¯÷Ö\�ã��,¦iÊÛàt+4¦Îp»að-<·S„TÇ5xƒTD0H‡#ÞÀ •ÂxÌU¼@Šèbœú'£0–ê‘“ÕæǦX›I™„$"ÕêY2u00ãçc2ªàb‰+ûô=ºZÚu5‘­ÒÔ»FO$ë!E8¸­'û<ŒÊû5†ŠS Ɉ–"
-Üx"âÂ×dU“
-¨€©¾PÕt©¦«šHÕ­R»LmÈ“T©ó\#Õ[1ŒÂ–Å=¾Óe8“ü|ÍÁ�iŒ‡G(<ÊÖU¦éÜìöP3”×lþÕ4¸ä¬¾\D_ñJHºÎ`ɬ€SØJÓùžxiVÅqÛÚÍPµ¸º¨+0ë¶Á·nM{oL…�6XÁ²-‹}õ"¡gR”‡Xƒ
-ˆöÆ)•ñÆY,—hÖMc‚Ñ݆ҷl½u®ŽÕšeá?Ýšo°£[o¡æKkª¥Y·n7g>‰
ÞÔ'{J9¡
-vòI´‹1�Ø#ÕÅÄ.sP.tIÏ‘©‹1�Ø#U4MïIñr¹­ÍÍý]ˆøÉb,�ð{-Cv›Ê�<‡&r˜B’·ˇjY·“x±)�€íEÀ‰ÄßÏ\ï_—ñÊ��>î	IÎC¾�„¼­‰Ê¹ì'îƒi¥ižŽ½»(îj[¬Ç>‚^¦ùOÆ‘+Ðzˆµ×4�‚dyD¿X¡}[ÉØ/xšð¹ÿ¯Éu:;è4ÚûÓ²«ä™=j’ç³k—j:»Fªá™M/Ãr
ýlÆÏsŽTX3H¬LÃNò>=/Ò:çE¶ËNx&°Ÿ¶ƒÐO‹4ë÷Ðö!nªºJ:OmêÔ>�ué±Qvon·õ}àµñ‹�…˜&UN˜à|Ðã;‘2["BVwÝ,Ìü™Œ¼@�s쩳ìÑfá™3[X+nk—JaxËÅ¡¬�þ=kM~è?Pù’Õ¯"®Šíðí¸TàŠwXpNA{�?&,„9º�ðŒ\÷žÍßöÕŠ„^‰@ëÎa`ô¶Ä‘“ž‰`é·cãG>Û‹ 2˽OÌÑÅA³@ÌæƯœ�‡c
-Ø¿±C_ñXgîUú“U„È8äAö¬*¢‹1]EDª‹U„P”¤\=ëÈ¢‹1]EDªž‹úÜ�á�Ù„ñ©†Z
-"U·FNÚ:Y•á¹ßújÂhpôÿ"ŸÄ³C×ù<ž Œ¦*ï%‡¾gë<%ŒœQ¯±$Ϊ–¸p¿q•qN!Zà
-ž=­�¶ámºKj
ðí1&Ú/L|)ŽoÌ:œ9{fغÂÈÕÀ¹+q—îsÄpÑ\£ˆ*VÆ–1å4ë¾ÀH‡.˜;ï…éæa�)ŠüŸäÏþØÔÒ8gë‚7ú‡å%l$·èu$xpŽ¢«Në0b:�Ä 3ãO@£A…™œ“äv�Nâ‘ài8ý„‘Øþb<²#T¨¹�\yfvÉ»Âïc×cg=aÙª‡+·Tãï­b](°¶®dù•£Q7˜–†
þ¢šað¸åöig[\G¨ý�
-<Cug*0‹›9xË?Ý›Ei‘Í��ßUù}�¨.Õ`ç¤ïO-ƒ13~Â>:º�V_Ó…ýuͤ ÜÐ?:Ÿ‘‘ÄnÒªXø7ñ«˜9ªÖ^
-!-h¢�è¾Þ®ÜšMqWÖN"{�ÎõüÞ#-½UíiÏÁ–(†/‡ßÛíZG®Ì4Éd,Ï•@P2©,ôYþàüccƯá4Ð~Ù
­)–d,a"·­­²IŒ(Édç~“ûûÍË]Y�*E¨
-=Ï‚PVx–%�ÿªt*úÿ
+’S¡ú¶ÔÞ×׉ DYšæo׉d|Þ”–)®—UkÅ¢-ïÌ#!Žœiˆ%ΰçðš³oRÀ=“øEöÉmÑ.6C¨ûMͳ8¶¦ÁYÑ…³ßAûò£{�I›Ât� ÀŸmÙx«wÚ³Þa@ÛÅ'ˆì)+cÕ'�¿Øž>¯÷Ö\�ã��,¦iÊÛàt+4¦Îp»að-<·S„TÇ5xƒTD0H‡#ÞÀ •ÂxÌU¼@Šèbœú'£0–ê‘“ÕæǦX›I™„$"ÕêY2u0œLrT¦@\,Q`eŸ¾GWK»®&R¢UšzWÃè‰d=d¡·õdŸG€‚Qy¿ÆPq
+$ÑR O#@)ɳLyg=Iû°7#X�œ³,ÕQ(üÊ1Ù ®{˜‹mÑ4# *%Y*ä
+›Ai:ÿÁ/ͪ8n[»ùJ WufÝ6øÖ­iï�©ðÑ‹"X¶e±¯^$ôLŠòkP
ÑÀÞØ"¥2Þ8‹åͺiL0ºÛPú–­·ÎÕ±ZX³,ü§[ó
vtë-Ô|iMµ4ËàÖífàÌ'1À›údbO)'TÁN>#‰v1¦{¤º˜ØeÊ….é92u1¦{¤Š¦‰á=)^.·Õ¡¹¹¿?YŒå
~¯eÈnS9�çÐDSHòöbùP-ëv/6¥°½8‘øû™+âýë2^¹3ÐÇ=!ÉyÈ÷#��·5Q9—ýÄ}0í¡4ÍÓ±wÅ]m‹õØçCÐË4âÉ8RcZ¯±¶ãšæ‘B�,�è+´o+ûeÏA3>÷ÿ5¹Ng�F{Zv•<³GMò|víRMg×H5<³éeX®¡ŸÍøyΑêk‰•iØÂIÞ§çEZçá¼ÈvÙ	ÏöÓvúi‘fýÚ>Ä̓AUWIç©M�Ú§³.=6ÊîÍí¶¾¼6~²Ð
Ó¤Ê	œz|'RfKDÈê®›…™?s‚‘w
hàqŽ=u–=Ú,<sfkÅmíR)ï`¹8”õÑ¿g­Éý*_²úUÄUQ ý
¾—
+\ñN
+µ#÷‚+ÏÌ.¹cWø}ìzì¬'¬#[õBcå–jü½õO¬ÖÖ•,¿r4êÓ’À°Á_T3·Ü>íl‹ëµ?P�gè£îLfq3où§{³(-²²ó»
+#¿UÃ¥ìœôý©e0fÆOØGG÷ãÑê‹aº°¿®™´”úGGà32’ØMZÿ&ƒÃ`3GÕÚK!¤M4�Ý×Û•[³)îÊÚIdÒ¹žß{¤¥—¡ª=-â9ØÅðEàð{»]ëÈ•™&™Œ%â¹J&•…>ËœlÌø5œÚo8Ó�¢¡5Å’Œ€%L䶵U6‰%™ìÜor¿ùb¹++På¡ÀSï8±;{?\ëÙZx[<„B<ø­YÇk…}qhû×ñÌ
+ÏÒ¡äñ_•NEÿ…6_0endstream
 endobj
-957 0 obj <<
+1012 0 obj <<
 /Type /Page
-/Contents 958 0 R
-/Resources 956 0 R
+/Contents 1013 0 R
+/Resources 1011 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 944 0 R
+/Parent 999 0 R
 >> endobj
-959 0 obj <<
-/D [957 0 R /XYZ 85.0394 794.5015 null]
+1014 0 obj <<
+/D [1012 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 118 0 obj <<
-/D [957 0 R /XYZ 85.0394 769.5949 null]
+/D [1012 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-911 0 obj <<
-/D [957 0 R /XYZ 85.0394 749.3395 null]
+966 0 obj <<
+/D [1012 0 R /XYZ 85.0394 749.3395 null]
 >> endobj
 122 0 obj <<
-/D [957 0 R /XYZ 85.0394 221.8894 null]
+/D [1012 0 R /XYZ 85.0394 221.8894 null]
 >> endobj
-963 0 obj <<
-/D [957 0 R /XYZ 85.0394 197.4323 null]
+1018 0 obj <<
+/D [1012 0 R /XYZ 85.0394 197.4323 null]
 >> endobj
-956 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F53 962 0 R >>
+1011 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R /F53 1017 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-966 0 obj <<
-/Length 3396      
-/Filter /FlateDecode
->>
-stream
-xÚå[Ý“Û¶¿¿BoáÍX>‚lŸœÄN�™Ú‰ïÒ´ãø�'RwŒ%R©;Ë“?¾»ø"!’’'éL;é܃Àår±X,~Ø]àØ‚Â[È„$Ï*‹‰¤L.VÛ+º¸‡wß^1˳tLË!×W·W_¾j‘‘,áÉâv=�•š¦lq[¼‹ä$Ðèõ󿿸^rI£›o¯¥Œþ
?úùÍ÷/Þ>¿VqtûêÍë›ë¥¢Y}ý·çßß:ŽË2¾~óúå«oìå\¿¿ýîêÅ­Åp¤Œ
-¯WïÞÓE
þ¥rñ”°,ã‹íU,‘±Ž²¹º¹úÁ¼ÕŸNY.–”HËÅRÄ$…þ§¸XB2‘HhO‰P 7K94dFÁEoül`ü”™erá¹Ðøu¾-‹åê¡\}øÔÔåõ2¡4z·,~ùõñ›÷îi…–úò¥iLÁ¼¡F(eµÉÛÖ0]òŒ¤©Ê,——×LÈF/�ÀæÐíÝ„Ä�ÍKì.J,ª}¹êšýqB¨ŒIÂ%;ú4!f	甩Œ1’IɯôUþ™JZÝ×;4¬,°ÆŒ¤±pR™ƉJTlžò}=!…’¡«¦”u^m@+67Õéé ë?á ÇþüÓ¤£ð”(šÆ¡£ü§‡û™ŠN¬_«”áÐkÿ’˜wb$É”JœåªM‰€2!)V$åT

- —ÅX²PT¥Ôôcy–&�rœMm1–i
-º¡»gqF“êlÿži¬@`XXï4S,Ðà¦ÚV›|‘�Qgñ/Ð;–„RæL}ËÏìÃ~Ò|Á[ôÐR¯ôo囧üØZqØîZCîJC3h�¤USweÝyÝÌçæ±Ý•«êgJyY 
-‹%§1á	eΫ™õjÊ7¥ÙfÑûã®Zå›ÍÑ�ªÚüæ槨Ö×,�ÖåL×@^7ûmÞ¡C“9÷HAÒKî1`šwÇ„ÚïëbuÚ£R„%2;Û£ã÷Ì',V"èñVÏBÊ#c�mÓÙg½z Å¢"rm¨8Cš³ÙÚx‡ŒŽÆ~Q»q�(Ä)A}<ü2#sgz¸ßç[C€ùkžZ£Mçn�mW:†b[ÕUÛísØùI»Ï”Æ(@;«Qmµ!,6»¤T8`Aã¨Y›ßÜü«*¢¶Ü?‚Û@
-uÖ˜HËÌïW_´Füê!¯ërc„o›¢çàõ¯ÖÆg1æK™„ wl¸ö×it˜RI(ˆüRyÁß84…Sû©êšƒEļ¶
-½Ñ
-ÓxÞB®3&r\¡�À	ålöÖgT�È M~7!E»òD]%�®¿Y1nE<VåÓ”.á‚%eö/
-þ}Þ–žklÌpŸÃè"KYhÍáÔ{÷¿¯˺ŸäÙ9Ž3J
-sÏ\Çð6ü½¾
-bXvÞ¨žklÕÐ/ j†¤�‡f½9´»·w!âè°+ò®lÍÖ„)KáOq¬ómµ2–2ᘰiRÝô¯L«²‚tAkiK‚Äâ´aª]˜§f½M×`¤Iýyjd¶–æÓVxh�òe�•	CĨã¼4R$xm}È­¤²¨:K6uÝ•æÕ6/ÊáS�K}ÙZ5–˰Ćc¡ajjl‡†½;â/C£AÎmíφ	µM Õí³I¾±µÊ­6?¶!A¾7LWó�h‹4ú¥9ìë|c\¨†œ�ugÛ#
-€¿±\¶4DÃy°ë{ɹ‹ù¸«CñAŸøàÃChk{
ç�}v¶G=1Øóó�ýÌ{>k˜oó®+·;=7ÜçÙœžÈ\ƒ}¬ZOÕfr­z8sÑ¿…µOe=‹_°0ˆL“ô<~
¹æñËsµò§yô
-å²ÿ+àåbÔ³í#Ù‘I§#ÙÀ¦/êüN;a’öØÅ“Ìx$sóØÏ»!÷^/-–‰$ÑX†ïë¦e(•ŒXæ L¤$NéÉ©d5À2å±L9,S¡.ðì±M
±
kô86�làíÙR�ø�-+W°0ÄÆ0a6Ô2;<SÃm>(ªöó)hÓP
+1021 0 obj <<
+/Length 3394      
+/Filter /FlateDecode
+>>
+stream
+xÚå[Ý“Û¶¿¿BoáÍX>‚lŸœÄN�™Ú‰ïÒ´ãø�'RwŒ%R©;Ë“?¾»ø")‚’'éL;é܃Àår±X,~Ø]àØ‚Â[È„$Ï*‹‰¤L.VÛ+º¸‡wß^1˳tLË!×W·W_¾j‘‘,áÉâv=�•š¦lq[¼‹ä$Ðèõ󿿸^rI£›o¯¥Œþ
?úùÍ÷/Þ>¿VqtûêÍë›ë¥¢Y}ý·çßß:ŽË2¾~óúå«oìå\¿¿ýîêÅ­Åp¤Œ
+¯WïÞÓE
þ¥rñ”°,ã‹íU,‘±Ž²¹º¹úÁ¼ÕŸ†,KJ¤Œåb)b’Bÿ!.–�L$Ú!
+ôf)‡†ÌH"¸ðÆ�ÙÀø)#2ËäÂs¡ñë|[ËÕC¹úð©©ËëeBiônYüòëã7ïÝÓ
+-õåK)Ò˜‚yC�PÊj“·­auÉ3’¦*³\^^�'$Œ^:�Í¡Ûº€Ä1›—Ø]”XTûrÕ5ûc@¨ŒIÂ%;ú
+³„sÊÔbÉɤä¿Wú‡‹*ÿL%­îëf_VXcFÒX8©¿„q¢[†§|_¤pA2tõÏ”²Î«
hÅæ¦:=dý'äÔŸ
+:
+O‰¢i<v”ÿôp?SÑÀúµJ½ö/‰y#I¦Tâ,WmJ”€¤X‘”S5Th½Œ(Æ’…¢’(¥Â{ŒåY˜4ÊqÚb,Ó
+¡~&�=Ÿ¡;Ðè顺fÑêÁ|üd‘À<国H‰¨n:«°™
+"¿T^ð7MáÔ~ªº‡æ`1¯-€6;\­ESûö©Bo4€Úî6ùq²‡6¿·ˆ¼-Ûþ!oÚêåý—	ÔBr€VL%”³ô¤#CS$véˆçÂáÿ¨�QIbÖ˜Àrùý*
EÌgHžËOÛ™Dr<Hg�ð­«ûPâ’ÈÅièØ^�-ä%róS‰»‹q)…‚½Q˜ìå/ÊûP†Òá¯Ì’ÏA-’†bÇ”p–±Ï�BÏÒñµe#„¼Á­Hc$F8ŠdiÖïØA0d‰��G�1PÁ¹ie— ‰À°±6¿f—õ‹³ªï'ËÓy²”÷²ÞÞ3gOCÎn™´¯—›&/&Ñ1"N
+þ}Þ–žkjÌñ>‡ÑE–²±5‡SïÝÿ¾z,ë~’gç8Î(
¼°
+†\ósì¹Ì¯! yMò(�=7É“´yvzþ˳C
+þä�o›W˜{æ:†·9àïõˆuy¦Ä_p�ñÇe|
œº]»=x4
	¤øÒ—Aÿî
+”¥ð§8Öù¶Z™K™pLØ4©núW¦UYAº µ´¥AbqZŠ0Õ.ÌS3�Þ¦k0Ò¤þ<52[Kói+<´Fù²ÀÊ‹!bÔq^
+)¼¶>äVRYT�%›º‰ŒîJój›åð�)È¥¾l­ËeXbñÐqjjl‡†½;â/C£AÎmíφ	µM Õí³I¾±µÊ­6?¶!A¾7LWó�h‹4ú¥9ìë|c\¨†œ�ugÛ#
+€¿±\¶4DÇó`×÷’sóqW‡âƒ>ñÁ‡‡ÐÖöÎ;ûì*l�zb°ççû™÷"|0Ö0ßæ]Wnwzn¸Ï³9=‘¹ûXµžªMp­z8sÑ¿…µOe=‹_°0ˆL“ô<~
¹æñËsµò§yô#Ê
+dÿWÀËŨg-ÚG²“†#Ù‘M_Ôù�vÂ$í±‹'™ñH æ江wCî½^Z,I¢±ß×MÿÊP*+±ÌA™HIœÒ“SÉj€eÊc™rX¦ÆºÀ³Ç65Ä6¬ÑãØ4²�·;dK=Fà¶D¬\ÁÂÃh„ÙPÈìðL
·yø ¨ÚÏBЦ¡
+À3¢MÙé¡J.£çî3®·ø±[
+ðVV4.&md#¦,C8à¦XÒ�oŒjxzšáwÓ
+¯ßܾzù¯Q�¶�KƒÎæ>KßbæjN?÷®3sï¸LîÓ×3G!˜Ö˜Ó={®i×ãš�ˆIŒw†F}ûÊ€HÜ©e¨
ÑoÿÐ6‘4ú�kpÝÐè†`(2w^šDEc¹KA<—«¶«êû^Æ°×ÖžPpó˜�¡ª4ÉL–Eby–â8Ž†ò�?–†fb+�­2qØŠß´æýÚÅA@¨©
57„õ
ðcZ—ä‚“8ñ§4Ã’ÕÈò‚AúêÏŸžœ¾ §‡ÿÌn8@ÎÍãÆì
úD
¨õa{gL±’iŽ‰“k¶|Œ‚n{ÑЦ÷Žñ‰FþØTE{âùuYºú�…Èò# ©§ú|°)ô~·Ô
»jë:œÔXÊØ©œ__”¼$jC®3ëËqéÚ~—wí´ÜÊ`/Wò|·žkÚïxq±\
 xÔñO˜7ï«ÎÚÂoÙØ�ÐãWíØêÞp§Æz³ÆËbT°Ó�kÞxžÇðë¡Ü7Í<8�í¹§I×apõ}{�ñ¨¹¿×™SFlÂê
 endobj
-965 0 obj <<
+1020 0 obj <<
 /Type /Page
-/Contents 966 0 R
-/Resources 964 0 R
+/Contents 1021 0 R
+/Resources 1019 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 944 0 R
+/Parent 999 0 R
 >> endobj
-967 0 obj <<
-/D [965 0 R /XYZ 56.6929 794.5015 null]
+1022 0 obj <<
+/D [1020 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-964 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F53 962 0 R /F14 685 0 R /F21 658 0 R /F23 682 0 R /F48 885 0 R /F55 970 0 R >>
+1019 0 obj <<
+/Font << /F37 791 0 R /F41 925 0 R /F53 1017 0 R /F14 729 0 R /F21 702 0 R /F23 726 0 R /F48 940 0 R /F55 1025 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-973 0 obj <<
-/Length 3750      
-/Filter /FlateDecode
->>
-stream
-xÚ­ksã¶ñ»…¿Už9ñð$ÁöÓå’K.3½¤wîc&Éth’¶Ø£HG¤Îqû绋@R‚$OÓñx‚‹ÝÅbß ¿fðǯ�N˜ÌÕu–«D3®¯Ëí»~€wß^q³ö@ë9ÔW·W¯ßÉì:OòT¤×·÷3\&aÆðëÛê§ÕÛïÞüxûÍÇ›µÐl%“›µNÙêÛ?C3Ÿà•Ö«¿yˆ·?|x÷þÛ¿~|s“©Õíû>ܬ3–+Xyyí?~3­ûtóËí÷Wß܆]ÌwÊ™Ä-üzõÓ/캂
Å™}ý,áy.®·WJËD+)ýL{õéê/
áì­]“œ–&ÑFdÑ	9—<1©4יΓTÂ;”]SݬejVÍ@¿»nVõ¸ßuuÒHS½ºÝø—EÛöO~ÜÑoýÛXﺢŧ|õh×÷e=8°±§ßª°mÓÕôø´©Ýú®ØÖŽ‡MQ–²ß>¶° B
Ã.ל'¹ÖÂr<ŒýãcÓ=$‡ÒçLÁfUv�ñ,‘"Ï£â
-Pë9˜—2sq1«tB†´7E;‚P[ý´~üåˆ�T&™Ròê˜�åy¥&É„>ààìTQÈÕ¸©q VC½ûRïh²Ù‚4›b¬ÛçÎù
-ŽP2¾úX—u7H¹)º‡ú†¯zÞUí1Òéí64Q=Ãé4%‘Ù?V€—^ôŽÜû¼ûhÏŽ
”‹›åQ¤MÀ׫®i0_ì‰ÃÐjW´œØÈ{ÁñÏŒ‰¶^Á“ä«»½[þÔ´-�îÜ"âºm=Öû~÷D¤+BO[GÔûW¿wš;Qs4H=ðB	Éå™ç©5‘;6êa,v£µ¥²Õû{z·~\Â�uÙ Iä_X3øÃ@+B𦊑
-VŠ”ÈJñeq³æ«˜Œס±âo0Öˆ]-‰‚¯ÃÃÁß™éâ#ÉGÎtqhM“éºùv<k«©æ	癸`«s°Ó¶ p?ã®(ë#º2OŒ”ùºê˜îÒD•Jù-¿ïJ:Ÿ-ÙŠrã„Gz3xÁÞí@<ôØÖ_ê–†wÏôÛwõÑ	–dÙ%Á 3b#˜…Ð^¿Óz*5˜7Ì0Eœò•é$Í!ú�ãËÃòµ«aIj˜™3ö©‡¨,!x«Õ.JÔ+sát·þí±mÊÆ�Ï—¢ÝŸ‘´ÎY¢„0d=;-í
-w»«Ëýn@ß~ª�9O;2G´ã…Ì‚ø×ûíãÁQ¶ÍàäÔ;™ÿº¯w�÷³tÓø'ùucû<xؘˢ*R40’å)°n ž”Ê¿�Dß̤›³ÃmQ€‰tM�¶6žÆ¯ûÆ”(ŠËP,k‚(l�K ÞH!�nÆ
�¨
(ïÏpÒ)öðºq©-l
-\5‚sÒ9¼¥i+,˜G–p¶ Çaã*¶Ê¡ª]&;¾Â‰Ô™ŸE8
-Ï‘œ¡7½ÅíÙîb¥
-IPHEŒ«ãÃÒWt¶VPÕ4ëý…]×öeX °n¤�+úü	0—€ït®b×UeÌŸˆÄ°ÔGØ_ÊñEãf �ŽÌš\Pïk�âu=–¯‘XÈî#�„d9åüiº)èt)6[B•Wźl
-`z&
P;š¾óAwQ³Âw0
-[ìCL7YêX[ÇäÅU¢“¤DúxdœQíì�øLÏ&¼
Ò„ñÒ'ÃÄ}¿ïªW‘³DáCEÃò¥!�:T™¨Lx&]‚q�ßÐÓ¨íûÏ4jºˆ$2•è”§GGú¹~Ž�({ð“úg¦*&"«©ÑS“€$•KåµfxP]ªfÁŸ
-pƒÚkÌS1òªFYvÖÙXZ¶#rS0øêý‡¯]»‡ñŠÞìPÁšu]bæ8ÐÁv8¶, c¸�j
i§V&;;!'HŠ@¨Y�“S稑øCÝÕ;òŸ8mËjøÝݘվë\ä;P
.t¢4Ëfô×(Ë›�ÂêuáNXpå3Ú<Št(wÍ�kd®e&“\è|)5Ò˜Eü¤‚éÀÙºŽ^î®iðq‰=üz¾ ‰�ðR!XNVB¢b¥½L_ð-î-Ô%.Ž°ÙüŒD”‚ð¹â>DÛWÖwËÔ:è-†
™RbŠs£yÀ
Ê+P[A€Ü6m±sË{¤x„3ý}Ì•i°`Åù¬rªN9d�£y™à�×°×¾ô-P§€>£Þw‘i‹û�Sp�’§ùa÷ÔKØiv"VAÊ•3¾ðªC„U‰$¡ã
-9dì,Ë^ŠÄ¥:^D×܃a¦±Í<Qyˆ®‰áÅÊÁ$3Œ, ä Pz
-�üôŸÕԲƗO”¤À¨†¾Ä¾:��€M‘Ëeô @eÒeJc2Ü@ol>„¿šÍ‚0ë*Ž6M¹!
-´6ÐÝôûÖI
-”µƒŒ¬ªfÚ©*Xª4\õ�v:æf}�YïÔ'r³ª)h³çàv…¯£z¨íéB7Oƒg_žKÈ�U$§;ßÓKš
Å­ŠD#ƒôXЩ9(P:G
¿1le P_#Ü€¦
-m^p´9÷úçnG‘øÔ¿¡N”‘¡�s¤CYÂD0	jtEÅœçAym•¯Þ�n³Ã3x½ß|¡�‚Tuæ¿è­*b‹Xíîàõ©¦‡áI†Î	öPå¤%Ó‘Xj‘™Rfü¬DH—Õ }r‰	!_v.
+ú'8à‰Jƒyù�Þ÷ø½ŠÍµ5¹$I¾ÏQ�{å«Z�䆧Kçs1aVÛ½
uÂ5E`¦ Ÿ/EkïèaXõÛÂ@n×ðòßUä+ÛЮ®Ý"Ê­_9î‹ÖöçfT6
”±VDåOîOÔË7{[HéùÆ),n›Ïu,�ûY´Â­Ë]?¼^S :0A‘
-ŠR
Õu
-zô¦è�\Ë)î•rt½Æò±W”³¢O~êiæ\¶
-¨RâyÑ>ô;ðÛQ•Aõ
-Í““Ô¡ÄäŽÅE‘&à8ÅäZPß4¾³æ?ƒÁÎ4ùß…JE:séê±Ø
6]S©OÒ`T”eý8ºq÷Lƒ ¶JSF¡|‰¤ÒÔQ¹*
-ßxá ¨ìè:
+1028 0 obj <<
+/Length 3881      
+/Filter /FlateDecode
+>>
+stream
+xÚ­ÙrÛ8òÝ_á·•«"'	î>erÌxª63›x�ª™<Ð$eqC‘‘ŠÇ[ûñÛ�x	’\5[©q4Ð�Fß�ù5ƒüÚèˆÉT]'©Š4ãú:ß]±ë˜ûþŠ;˜µZO¡¾»»zýA&×i”Æ"¾¾ÛLö23†_ß¿¬Þþðæç»÷ŸnÖB³•ŒnÖ:f«�oþúžF>Ô֫xˆ·?}üpûýß?½¹IÔêîö§�7ë„¥
+V^^ûÓÏïÇuŸo¾Üýxõþn8Åô¤œI<ÂoW¿|a×øÇ+ÉÔèë'è°ˆ§©¸Þ])-#­¤ô#õÕç«¿
NfíÒç´4‘6"	°NÈ	ë¸ä‘‰¥¹NtÅæ�wUq³–±YU}÷7ܬÊþ°oʸÇzu·õ“Y]·O¾Ýзü½/÷MVc/]=Úõm^v¬oé[”
+c«_Ö�_Žˆe”(%/à¡Ž	˜ßWl¢DèŸáô ŠB®úm‰
±êÊý·rOƒÕ¸Ye}Y?ßpÎWp…’ñÕ§2/›ž@òmÖ<”7|ÕQ—¥ß‘nïð°¥�ân§Ê	Íá±€}i¢uènÿõᓽ#¸6.næW•‘4

\¯š¶§F—}³7M+\ÑYp`—u=žÛ¿2&ê²{=ÉW÷·ü©ªkjÝ»EDu]û]7íþ‰P´ý† v©Göïöà$wÄæp�x:à™Ò5<Oc«:"ud”]Ÿí{«;J%«Û
Í­ç°Ýc™WˆiÆ	«ê¨3Ó"¯ŠªAKi)Nf7k¾ªá‚IYq*+~e
èÕ)Ø:¼üNT»Äl9ÕŦU]lŒªëÆëþ¬®Æ
__ÐÕ)Øi] ð<ý>ËË#¼2�Œ”é¼êï\E•ŠþÍß69ÝÏŽtY¹uÌ#¹é<cïÀêÖå·²¦æý3}Û¦<Ã:ž‚W`É%ÖMÀΰÎCÍX÷úƒÖ`©AÉa„Y(¢wI]¢£8xž:uLÝœÁ†E±afNÞç²ï‚|G®VºÈ]/Ø™“ãò÷ǺÊ+wWß²úp†ëÚ »•—¸>;Íõ

+�2(²šG‰IùÌêóœ£:Ž’„©9êÿGÙ¾éÇù6
;Ã7…ÄoêC·=©èçñŠ~„7¬è3ÄqùÆåY¾='R"†Fj.±fv†5j`
šé€2ƒ cR§ÌhF`
+V
BÐz¨cç<LuÄE¼ 0ÌÇêÛÔÉPkôâ�ß*�#‹Küž‚�æ÷
+ì&‡¸ü<buŒx¡Á,JR˜�a~Wu�u†nƒ	O†m·�0.²!\vE¨ÕǶwSý6ë}Ë
5‡Ý½
t`ÚJ¬þnÉí^5y}(|oXU5cœ
äó©Q¨AL8¹»¯šâõÛàôœRÆè$Ä<LAäÞ|Q(ÊMv€ýk*`æ=Wôúöc
+éô¢kŸ‚�ᮇÂBLQAöTµ�ËÛæ¿ífóÅõÖ™i‘J'Œßªò‰€£("ðVP*#Xì �2SaÒH$RŸ?â
+·ÂS$'Hh¦µ{{²›Pé€8‚B„«ãËÒ—#lùFAn_Ò¨wpv]ÝæÃ…Ej¸ŠÅB‘€¸ôÖ	ç¾)ò�‹È°Ø‡„
º”£‹Ú•Ó5Ed’Hê!¬|]öùkÄÁn›
+´ÈNAã»Û�ï\±’ñ(Ö<™+æý¡ªQ6ÐVá®Â‡fpŽ7ˆqï‚RÃ�Û1B£¢�à„ñÀÔdà“g©ùCÙ”{2 8l‹BðÝߘաi\¬¶t˜7(Í’	þ5òòÁæS°z�h�\y-¤Ã#K»|_Ý»2üZ&2J…^IÌ,ž.’j	Ä cÆ(‚&÷×Ôø4�¬<üzº ;íK¥‹|ÔzHi#*Iɘñ=Á’”…ºDÅÑn6£ ÅÀ|®øÜG[ë-ck¢wè8dL¹Žõ~òØ…”—
+ G.rWÕÙÞ-o	�<Ž´›�-ƒ¸H+Î'É~qÊ"ëõËy-Sáªï°}
ØÉ¥O°·
úd:âaï¤l£äqº|¼
yƺ(–õEœœðV�%¤ŒÏÌj(â’ˆ‚O}Çb
n$ñY_X
9$™,I^º‰v´0ð¯©ÃX#ÍF*Ü…Ë�C{Å hÊ_ÁÈ3t- å Pš
+àü8‡}5¾¸àä…)Ðʺ®ÍñYˆîFà‹&3ûGžÊÄó Æ$ȸŽflD„_M&õlu[Û*߀>ÓàHtveÖ¸íý¦÷ýÈ¡¥å©
+2<HØ'Ö
+oœ�{ŸZJ,Dõ`ÜÅË$ì+3bq=Zyœz(
kW¢Ì	º_­iÁ¾;@Õ»µÓkrI…
+IÅ!v!‡
+š*
xW½Èäq“ÚݤÞïC¹IÞ4H³çàönŸ
åPEàÛãøn–}~[è-!:V¡¨î„‡�/‰ä·*àŒÄ°£nF’sh�«t–¾à2lr P`Ô€¨
+m^p·)÷èž÷ùXáò©‘CçHˆ’ˆ‰A'¨:äsšÒkó¨tuÛ»ÃvÏ`ö~÷¹2R-R
Œ€Ñ\Dæ±ÚýˆDŸ*|%¸Á¹+Á¿Åd¼‹­!4cÐŒ¿‹ÒÅõ
+x¤âA¿üA7-þàÊFÛšl’$ãç°Ž„½ò‰­ŽRÃÞÀGc¬vëë„«‹ÀHF[�¥fÑî2«U
+¡B5p<º\ÈúòMX
ëÀB&«Lü’è	ØÕ˜ðÏóÖÃŽëé–�G
y©€{
+çâÕc¶ïl¼¦b¥A+Ëóò±wí晃Ø*M!…òI’Š—1£ryÎxæ ¨äè
@(·žíç�jË/ÑŒí.Ë×»B‡ïÈ!sp¢gÅåe¯q/k˜¾Ùßu
RçQ&™ãÄ¿gî-$ëÊu¬üóFÞþoàw¡ŠíÄÕúðÖýÖW+ãœ4wL¼ÈE|Ç3—b�M©
+!Ù˜Owd©2&?
ýi4	ã÷þ(Ù	'e‘¯}'TŽ–j¦ÈåÞ#-³g~ÈËü#»à®°^€ª”¾0»È⡺l=—àSÏ%¨r‰_ô\‚¹„(²Ç–­#Șpá�±�›
qÌ`	#yAhg’1p�¸v@fåÖ®aãlqò§“fÔ0u¾
+´VÀØ$	ÄÄá;çéĬņŸàl<Æñ')†íè°pp«l7ôhh›øÚ$4Ü5%®l9N¹ÐÔŽ´4pïÖPhŠ#®Ÿ¨é{"êƒ�¤÷D»¥«ÛÀáÐÆq€¯?ÿdi	hÔ���`/„]’¥é‚ãûÑäýÖ…Ú“÷Y˲Íó"]™`š‡âà Œ¾øþ6ç(Ë¢Ç#—eM8J•¦:âO¤Žðï	pøïäñÿÙÂø×èá�áRºd1é°#
+Í“%åÃß7“þ?(†�endstream
 endobj
-972 0 obj <<
+1027 0 obj <<
 /Type /Page
-/Contents 973 0 R
-/Resources 971 0 R
+/Contents 1028 0 R
+/Resources 1026 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 944 0 R
-/Annots [ 975 0 R ]
+/Parent 999 0 R
+/Annots [ 1030 0 R ]
 >> endobj
-975 0 obj <<
+1030 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [120.1376 365.8002 176.3563 375.0156]
+/Rect [120.1376 318.9001 176.3563 328.1154]
 /Subtype /Link
 /A << /S /GoTo /D (controls_statement_definition_and_usage) >>
 >> endobj
-974 0 obj <<
-/D [972 0 R /XYZ 85.0394 794.5015 null]
+1029 0 obj <<
+/D [1027 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-971 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F48 885 0 R /F55 970 0 R /F21 658 0 R /F39 863 0 R >>
+1026 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F48 940 0 R /F55 1025 0 R /F21 702 0 R /F41 925 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-979 0 obj <<
-/Length 1632      
+1034 0 obj <<
+/Length 1676      
 /Filter /FlateDecode
 >>
 stream
-xÚÝXmoÛ6þî_!û`Ãñmý”iêM»ÄÉÖvÅ HŠ-T–2Knýï;Š”,ÛLtÁ6þ`R<ÞŸ{îŽ	0üHÀšê@êqLx�,G8˜ÃÚɈ8™°
-‡RÏf£ƒçLiAE0»èR+E‚Yú~ÌCЀǧ‡¯Ž'!åx|~|6á||	íüõ›ã³Ã‰ŒÆ³éëÓóI(±ŽÆG/ßÌ:‰¯ë8z}ú|zr±Ñ3ù0{9:žõ§ž”`fŽðûèý¤pà—#Œ˜V<¸…	FDk,GgˆGŒuOŠÑùè§^á`µÝêEŽ`D™ >èô
-·£†1Ò¸„[�Y“ïPR•×CB
¬¸3x[­‹ÎHQT·vØ,2;Hªå2.Ó<æC¢€SJpI¤•­Þï¬h¤†©‰´”Â6.ZèWYQÅ©ÇÓÐmpŠ-bM.I.•e–4vÒ=ì£h§7ÕÊ	hÎì
-8PvH¹§H›âà-öa¯1ªÜ¯äTiĈËÆGsÀ}غ¬µç@®žQŽ'r;÷ÎzjÙÚj#ÃW€
-‹¨„¦ͳÒcZ0D¥ê„o,qç«xi-Üæ…	�†—Ÿ²2‡�wv-±é
�²±/DàbèÌ}Eú²ä½Û¶[C&ú­…»j
yÏ°vÌ2F‹º²x1&PD‰ÜÎè4¯oŠØxL¨+
-q†£>ÛÛËÚm'Pû#%†i‰"ÍÈCº	kß3øN?ù¶]�ƒk˽Ø}t¹a‡óNCëÎ2Å
Õ·³-5ERIÅNC1Š,cϧ'/.Þì‚D$!ÁY0Pø÷\ì5îû¸C�ˆIŒ-'�ûë�Ûô†ô¸/A®�¥¾LÔ‚H~C-èêÍæêºãJC:Äu¶G¶®7„èǃ‘i†$–
+xÚÝXmoÛ6þî_!û`ÃQ$×Oi�¦îдKœlmWŠ¤ØBõâYr³`èßQ$eÙ–Û ¶að‰Òñîx÷ÜsgÃ�x<D¡¢Ê*@îÅÅ{sxw6"VÆwB~_êÙltôœ	O!ÒЛÝötI„¥$Þ,y?fˆ¡	hÀãóãW§Ÿr<¾<½˜p>¾†K»~ýæôâx"‚ñlúúür⬂ñÉ‹ã73'ñu'¯ÏŸOÏ®6z&f/G§³îý“Ìô~½ÿ€½ür„S’{w°Àˆ(E½bp†xÀ˜{’�.G?u
+{oÛ­ƒ‘#QÒ�ÐQÖ�$ˆ+Å=Á
+¼Ò¡;6'«£b™§æ¾Èʬˆr³ˆ«òWŒé|½Šš¬*ÍCýÄIgµ¹Föz[åyuWÿ Csô< =°çS…¤”­å�éýÄ1¯Ê$þ­[ý©7zVÎ')ÎM–£|^­²fQÁ'‹"Šý"áOž¶[°“¦­t�Æ«´±¢1»¸¿¡¼œž]¯oØu�<+nØtþöòYóöç`þ¶¼ÆÓ3²xwv5W¨ûéÙé<¡J¿ûѪ÷·]2F>ï˜6ŽVKªúðyÌæ$½�Öyã×éêSº2Ò„
+„áGÏäv´Á¢A/vƒ>’ž�;Xp©ª•™-\Mj¿·¹½µ×²n¢<O“.ÕûÉ%#…
ó¸Õx”6ñ‘ö
‚n<�…@kÄ­Á»j�;#Fæ¶Y¤ŒE•É¶|"
û2äp'�bÔ€ì;+*û‚”¡5¬]´0Ló*J<õí«X´ûš
+\\×G™Æ�Y¸‡]ÍrY­¬€âÌÜÀ)ìþh]§v÷ÂÞ”Qaï4úÊW"Ç­¯:h’˜,i�_ÚÝ–nßH^ÅPã ƒªZd¥�ø]jÌ™Õj"Çë²Ìʹ}ÕدúîD¥i7V¹Å
+é„—¸óUTwY®S£B�ËOi™AJò{ó.6å
‰2ÑPŠÀ†}g‘"Ì‚wnwméì·î«5Ô=ÃÊ"KÍëÊÄ‹±”ˆí�dõ2�´Ç„Z ³2Î×˪Lt<÷ÃHHHæÖŸ®,÷gF
+åûÈmMF�±	ΛGeÚ6xÔÒ<‰’̓�C*Ì5Ç%ƒ¨�\vHjãwœ7骄æS
+¹#„@Ë1!ƒìTÛ•mÕLæªÔpßÔ8ÔBZ»Ï�\Ðüp—ç6ºàS[êë¥eˆ�Hh"
+•êƒi¸ 8”5!lK-ñX*+k°¨’ìö~ÀšVU”?$ì!E4�hÔtmuAë"M5À1
�óG„à°›äéća¦ïl^FƒhÓ C('骉²6Þd|u>ýÅÜÕv?,h×gá¹'ˆë”ZÔuJýº2;šè£{»LãL06ë(nç»ï�œ|	gu¼ÊnÌ�]¹Ü±¶Õ"µú›<EC
x¶Hk›©ÞzP¼qo»Þ°®»Ö;̇Pt…üQ3Ú
 endobj
-978 0 obj <<
+1033 0 obj <<
 /Type /Page
-/Contents 979 0 R
-/Resources 977 0 R
+/Contents 1034 0 R
+/Resources 1032 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 944 0 R
+/Parent 999 0 R
 >> endobj
-980 0 obj <<
-/D [978 0 R /XYZ 56.6929 794.5015 null]
+1035 0 obj <<
+/D [1033 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 126 0 obj <<
-/D [978 0 R /XYZ 56.6929 466.6686 null]
+/D [1033 0 R /XYZ 56.6929 424.8255 null]
 >> endobj
-981 0 obj <<
-/D [978 0 R /XYZ 56.6929 439.3642 null]
+1036 0 obj <<
+/D [1033 0 R /XYZ 56.6929 397.5211 null]
 >> endobj
-982 0 obj <<
-/D [978 0 R /XYZ 56.6929 409.8468 null]
+1037 0 obj <<
+/D [1033 0 R /XYZ 56.6929 368.0037 null]
 >> endobj
-983 0 obj <<
-/D [978 0 R /XYZ 56.6929 397.8916 null]
+1038 0 obj <<
+/D [1033 0 R /XYZ 56.6929 356.0485 null]
 >> endobj
-977 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F48 885 0 R /F21 658 0 R >>
+1032 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F41 925 0 R /F48 940 0 R /F21 702 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-987 0 obj <<
-/Length 2297      
-/Filter /FlateDecode
->>
-stream
-xڥ˒۸ñ>_¡[¨*K<ÉiãÇ–÷0®x&‡Ôz’šáš"µ"egüõéF7(JâØ©ÚR•Ø
-ë2‡‰�+>ÎBØ„¿™o vfÈWt‘—»º<1c…âÕ%KS”œŸð�Xú}Fb(59J“R`cÓ1'
-cß·C¿yQQ`MÖéh&×Ê�ˆ

-GID濯œ	3ßp-“kºgÊÁ«²rò+–
-Ìg]©†q~ÄÄ%d!ÄØ"¹_4Èt6ÏÍÿB�že´=…б/û–nâ¨pØ×eó)MdÈÙ´Í@*28²É¨•d>¾{M€tΊK±LV¦¥�tã?o~û=]U ž_oR¡]‘­¾Â @@­v7F*á\fâL{swó¯‰ D°BË%Â2-Ú—-ãŽsR›ÈÜF›ªŽ,›+dŠâÛ•ÃðR€Ë‚y9×
-ln¯·Ö&MN¾q&
ÈK&s’·«‡Ás1d’p^H”0¨q@܆ԙ„JKÏÄ‚XÍH߶÷U¸øo&er‡®µ}nºÇ~UjPY,Ða!‚6}×"Áç,ÜÂia
-�1�PÞ�몧LŸ—&¥?†
--/HØÁÎy&å»À®”N¤Vº)ì|O¼…p©ŽEÞ$P¤>ÙG~²­�Y¡Ê †¿3y^¦kWÔÀàÜ•ÿZtÀ8”9ëVÞû—c×yÀ‘ópÖmD4( ×p×b„âžãÍ3è«))êþ{_a
øãdÚd]Üàöáë鳫ǧ>ØBšlƒ’p­ªÀf±è„J’*Å}ëK´ã°ñªº­Çi–K*-+>&¤�ÙqQý
-oQÈ"ú5QÚìû¶)—ª:kE¦òXÕ•-Åä…£¹ ¼>Å‚3eSojÍkâ
-}FÇ>ŒÈ	E?n�gÊ�›Ìº­Eñß`{Ó¤p0ú¡†.�[$.d2ÐèSš¥ßbà2Éq˜öƒÍݽ}
ë’–¶=÷ò¸H¶
-–ýG[¨R¹b»ðŽàK¦`ý4ðÓmpp{ì÷J0	F¦åǺ«~F“‘þÅÉe‘<ßéuô…$ÒtŒ{„"ù\?¯%dCv¿)#Oý¡ùæcq™Å£=ø!zVl”C·ëc©Ž>Ø<vø¤Cní©þï̵a¯Ÿî0Û1q:½	�ªÂ+ca´)b|ž^…¦ˆòG<t1"a8h_
-Õø†¢fðçð,‘ÍÞdT†ÏUMÓ!EÃ×Ó'öûÙ¤
˜¬N9âD¦Iï°a¹ï¯h‘‚”�OöôÖȳ»X¾jPåp]RKœfb<‡ÆµYÒåÜâ¤NJb…­
&x�¸‘ú¤€¿>ÕÝÅ2~F�
-f2€ïFt-˜¢~¶åônwâ-ú¬;]àc×BλÈs¤Hz	ƒúÅå©9Eª;4UUw—iwÉIÎ’iÌ�œæšÎž¿“²‡§þØVÓcïb¢uÕŒ1tì|w|ON~™
ˆI›ÏŠ“<>Ú<¶=
-ö
+1042 0 obj <<
+/Length 2335      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥XKsÛF¾ëWð¶`•9™7€ä”õ#åœZK{ØJr
 „´#ÿúížžÁƒ„äT¥T%6æÑÓÓϯGl8ü‰MfW¹Þ¤¹f†³)7|ó
+>VfwFeÌd2ÝìæLþ}wóÝ;)6’3k¥ÙÜídzlš2#­ÜÜ•¿&¯Ýq¨NÛ�4<ÑÛßï~¦mš¥Y*p‡#R&r؉~,?»¶¨JÚñæÃ-ï*7œOU?rš)�‡xÖ0asã9h&¶;Á9O>tC½
+[Ô&g¹•6ìPœ¥:³~‡?E)›|øåîý»ÿ]÷ø›&Ž>UñèÚº?Ðçðè†0ß4Ý—>,r½¿,Ò}uú\�ÂÄÐÑâ–$
+,ª:®mÜçêj[št{Ä£ª^/†W‚åÆ�¾¿vmõ/X(•IJ78k¹IÞ·4tÚŠ,©úc×ö� 7üu£f'5	i™i‡ ï �kujÁ¬ViX¶÷‡t‡È×ÿDÍ MWܦ:y…j"Ì��üR7
QÅcU|Z
+ÛWQzo¤ê!ܵWwá¾ @TÒNؤ×](‹ÎïB­…VÇßqª8ŸHií@øpmù*lÜÓ/X8Ž´õP»!ðq—'
'×ö{ÒM™ƒWŠ„wzO“CGÐWÝî»ÓÁ
^p÷Ýy yÅŒî,uú-3*8œK–½"–^ÕHx� QV}qª�“
+º¢kèf>/�	ûcUÔ¿q.¡Bú̦ ô¥
+Ù"³Õ!?}|÷š¨¯–]ªeô2ÒàV¸òŸ7¿þÎ7%èççÎTž™ÍøàX¡åæp£…dyntinnoþ3r„–)fHXçEû8ð
+dܱdµ‹Òí”æp3µ°ÈxÙý&Çü’A̘’šböÃLÇÆj�4gÿ²ÝY‘ÜÁ™¼½ÔðÔDS¡	÷Qºùs#×y®hÑŒöw�tà¾{�›7Üh3»Td¼›sö—,3Oš)ã©
2È5†l„N�g¾–ä9VË­„‚´•‹Î|Ý
+È
+Ž…6 0i“‹`¸CÕ÷. !�øó|¥„�
+?HZ_;µÔL-¸ªè·é\é/
l„Hn1¶öOuû°"¯ä
+ǪÖÝ7È?PQ~²-š3é	‡Ý<Á4ö(„A_¹;?ç@V±Ô¤0€×�7ËDãš8íŽ]Sk°ÎZèÚÓ늆òJ‹ÊQ
Q^Ÿb!˜ÌØ\x°yÍ\bȨ˜Áû
%¡ì§e‘ùÒeÐn�ý5�uX¥
Gçy<uøT=íÀÒÇzWœªv£§]Ë!¸Â'Œ¸ÏÅܹÔ[άµÙœwÙ\Ý®i
ò™ÙBkèd™ Ÿ‚ßgÔ&™¹hwúµ¶`‚r®¹õ¢Àš|m:Æ!PCm‘:l±,¶¾Š`¯Z=t³.:v¿1ÐB
+ÐçÍÓôCÕV'wʼnü.·S�
+%8܇	’F¨É:@y¬Ú‹i<üä|�
+¾àæZÅZÖÍÀ
+@ׂ!z6šMAb™^‹'ÙâkR>3,OΈÀZøŠlIO°
+ù³/‹+'þ¹ö|endstream
 endobj
-986 0 obj <<
+1041 0 obj <<
 /Type /Page
-/Contents 987 0 R
-/Resources 985 0 R
+/Contents 1042 0 R
+/Resources 1040 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1001 0 R
-/Annots [ 991 0 R 992 0 R ]
+/Parent 1056 0 R
+/Annots [ 1046 0 R 1047 0 R ]
 >> endobj
-984 0 obj <<
+1039 0 obj <<
 /Type /XObject
 /Subtype /Form
 /FormType 1
 /PTEX.FileName (/usr/local/share/db2latex/xsl/figures/note.pdf)
 /PTEX.PageNumber 1
-/PTEX.InfoDict 1002 0 R 
+/PTEX.InfoDict 1057 0 R 
 /Matrix [1.00000000 0.00000000 0.00000000 1.00000000 0.00000000 0.00000000]
 /BBox [0.00000000 0.00000000 27.00000000 27.00000000]
 /Resources <<
 /ProcSet [ /PDF ]
 /ExtGState <<
-/R4 1003 0 R
+/R4 1058 0 R
 >>>>
-/Length 1004 0 R
+/Length 1059 0 R
 /Filter /FlateDecode
 >>
 stream
@@ -3142,12 +3315,12 @@ q�ª„Ñ«ò�^ÿï>‹«>÷—
.13×…Óƒ!¶3¢SËAÕ”ih¥Å¨Š^…(€<Îm䦽ªšÛÆlLÊâ³ò7Ù
 n*Œ1½÷¨¾x¥Æˆpîâ‹
&Xî
Ãœ§³±è\íD¤ß�ä0}#XŒûž˜‹¸À>#^V°¡|2Îi‰9ÊÎ�r)`˜¢Xh¡Ò& „hb—H°Œe"Ãê
 þrÓGçX5¾ûû8‡´ÕªOª«t–Ô³$Ây°‰—BÒ›ÀÄ5
©/¨�vp�÷o`kA“ôr±ñœÓ4N.4Žæ
 endobj
-1002 0 obj
+1057 0 obj
 <<
 /Producer (AFPL Ghostscript 6.50)
 >>
 endobj
-1003 0 obj
+1058 0 obj
 <<
 /Type /ExtGState
 /Name /R4
@@ -3157,487 +3330,505 @@ endobj
 /SA true
 >>
 endobj
-1004 0 obj
+1059 0 obj
 1049
 endobj
-991 0 obj <<
+1046 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [470.3398 482.8902 539.579 494.9499]
+/Rect [470.3398 477.3512 539.579 489.4108]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-992 0 obj <<
+1047 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [316.7164 470.9351 385.3363 482.9947]
+/Rect [316.7164 465.396 385.3363 477.4557]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-988 0 obj <<
-/D [986 0 R /XYZ 85.0394 794.5015 null]
+1043 0 obj <<
+/D [1041 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 130 0 obj <<
-/D [986 0 R /XYZ 85.0394 769.5949 null]
+/D [1041 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-989 0 obj <<
-/D [986 0 R /XYZ 85.0394 582.0558 null]
+1044 0 obj <<
+/D [1041 0 R /XYZ 85.0394 580.0302 null]
 >> endobj
 134 0 obj <<
-/D [986 0 R /XYZ 85.0394 582.0558 null]
+/D [1041 0 R /XYZ 85.0394 580.0302 null]
 >> endobj
-990 0 obj <<
-/D [986 0 R /XYZ 85.0394 543.4475 null]
+1045 0 obj <<
+/D [1041 0 R /XYZ 85.0394 539.9341 null]
 >> endobj
 138 0 obj <<
-/D [986 0 R /XYZ 85.0394 324.8439 null]
+/D [1041 0 R /XYZ 85.0394 315.9171 null]
 >> endobj
-999 0 obj <<
-/D [986 0 R /XYZ 85.0394 292.4184 null]
+1054 0 obj <<
+/D [1041 0 R /XYZ 85.0394 282.0038 null]
 >> endobj
 142 0 obj <<
-/D [986 0 R /XYZ 85.0394 174.5048 null]
+/D [1041 0 R /XYZ 85.0394 146.7217 null]
 >> endobj
-1000 0 obj <<
-/D [986 0 R /XYZ 85.0394 146.6189 null]
+1055 0 obj <<
+/D [1041 0 R /XYZ 85.0394 117.3479 null]
 >> endobj
-985 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R /F62 995 0 R /F63 998 0 R /F39 863 0 R >>
-/XObject << /Im2 984 0 R >>
+1040 0 obj <<
+/Font << /F21 702 0 R /F23 726 0 R /F62 1050 0 R /F63 1053 0 R /F41 925 0 R >>
+/XObject << /Im2 1039 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1009 0 obj <<
-/Length 3382      
-/Filter /FlateDecode
->>
-stream
-xÚ¥ZÝsã6Ï_‘·*3k�$’¢toénöšN›î%¾�Ùn‰ŽÕ•%W’ãõþõ >líõfnüÀ/Aà�rxÀ/¼V±§Qz­Sé« T×ùî*¸~�±¿]…L³rD«)Õ÷ë«¿¼ú:õÓ8Š¯×›	¯Ä’$¼^¿zÒþ
p¼û‡·�w?ß=¬o´ônºYE*ð>þòpGµõãíÃÓû»Ç'j~
-Tpÿï÷�P†7+¡eä½ýáöÃúî‘Æ%s½}÷Ï›0½Û‡·wïhèÝóxw‹k­ÿñx÷tóÛúÇ«»õ°©éÆÃ@àŽþ¸úõ·àº€ýÿxø"MÔõ�¦it½»’JøJ
-ázª«§«¿'£vê¢"ÃÀ�D-h2KšT©BMVY{&Þ‹�ÍE©÷µ©¹VvTöEÖ›‚Klþ8˜º¯NVE 1DÞ}Ýõ&+Þ
-VmeOÒ2e
-*ºrW¢—ØÆ1sV¿°¡5©AD|Ru7ê,Nu¶+󑶣þ<«ë¦§îºiw Ó‰Fž™±
“'1#òè-º“g‡ŽIáLxòdÛÈ·§Þ—CÚé
±hG6’7 W«�4æcNµ·kì1§Î^sÐ>µÇ­
Y>0Œ|Š"MÝý¶±BBç(4šÚn(.­9Y�îH™²Îg³�ÖyRv
è0uwà…f[¤X21sgÆ£
žu:¾Á.&§8�QvΕæØS�cN(ÜH{“x‡EÀ'€)éë8LAb´­^­ë›=ÓO
^F¾AÂäd¢¨
-Æ„‚[£ÌÈg?Töƈ—²šYo‡4ŽðLŽ½[©àN»7-
-›˜Ýt3Ä!Á†yZ¤Á¡½5�ËP)dâë@º�^~¡›ÓjÓ6»U
| 
B™:7ÝB0HÑ�”K6ËŽÝJƾŒ‚³ 3ÃÍ�8Éd–·B–)ætZ\
½
-U,
-JÎt…Gð‹
�œwúÞý@E‹Ó+/ëUJ?ÑQ2vØs>¿£Ÿ]kl ƒÝÐk–dY³®©;¯¦
r —¬.¿:W�Þcs¨
-"<fu?ß
tЋ"ÀgÏLY|TSè'€N3‡ì·îVþ__x~±¯…—7»�HOå§1Š50Ð9+Ã^+�¶I6é9‰NºvÔÉRhÁ)²æø mPc‚P°Ÿ`{Έ°NãÌWœAŒïhx„óÁò&¼„†{OU‚tÔhÀ,kª’}k|ôÅ)|vk5=q-yf×츧0Ï”EhpÍ(%$KýÖ¦'¸—öµ
-©I3S®8!À@bÉîGG‹»d¬ÎÒ)è¨Lö¹£ªÅb"¢rg_H±ÃDÖ_ËŒ2^aW
pUÄ„Ô¥ˆHñ%Ûí+Ã_ ƒ\™Û×4¬uÙëëé[ç±+Ë?g> •âƒ!N¤g*ËN¹¨ÌwH#'¢¯í³öш­6¬ßH`ðT…ö~hŽè­.?N´Sr^£‚|•À¬¬(­ºód�¶aãF"&؇­É�Oº×8èvöH­ÁmÃ=”¸¡
-9ÐìsÉ3ÛásLÜC¶;e/hÕÒç›™E=žÍ?¹êÜKüä8UàŽs’"ºÃ²	žP~(¥Ëý�sÃ;B^~:_ؤÍZ¾‘3JŸF�åO¦ÿÎ^
À3›ûkº}h´ù=˜'	hÃÅ™î’g¹U(@^�ºÇL­@|Ú󄈥¯¤žiU°ðâ+|j—Õs ñs
-õç씯•P#¿�DÞfno.5ÃÆä“"u%½©§Î—h¦µ»Ô¢=~Â"*•ñù�g8J=x&5Že¿¥ÚÜa°Ç)
ì‡ù㚦0|ÿ�_µrˆUp[¡rR4^žv˜ÂgmùÕ-ÆWx[¶ï~þHwö%h䂌٨9	³åBÊåg#Þø›óÏž.ÿ^s¾áû\�¥Ì¬ë•Gë2ù¦u…~¬¥3̧íÝ"¥¼YDÉìž’NRBþZ�å³!R’z:2‡& O
+1064 0 obj <<
+/Length 3348      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥Z[w£F~÷¯Ð[ð9#4Mþ93öÆ9‰3k{/'—‡6 ‹…k4¿~«ºªHÌæa�è{W×å«‹®øW2ñ“,ÊV*‹}„r•ï®‚Õ+Ìýý*ä5k·h=]õÝóÕ·wB­2?K¢dõ¼™œ•úAš†«çâW/ö…
'ÞýÃûÇÛŸnž¯UìÝüx½ŽdàýòóÃ-µžožînŸ¨û[ ƒûÿÜ=Â7¼^GÞûïo>>ß>Ò|̧Þ|ø×u†ÞÍÃûÛ4õá�ϸ»½Á»žÿùxûtýûóW·Ï㣦�/úóê×߃U
ïÿá*ðE–ÊÕ
:�fY´Ú]ÅRø2Â�ÔWOWÿœÌÚ­‹Œ?I´ÀÉH,qRf~"`
+9ù¼-áY‰òLÙ½•µU]SKצ¥V›çÚTm£ëúÈ«ºªçÍÈ×ߢ(.†Ý¿Ä_œéÝùy»Û×e?öš¾lzÃgoÎûB÷eA�/mc‡S¯gZ*·ÑN�€ë0ô3)#ûªß‚ ªKf,$<±ÂåYä¹oÓöÔ(èhœÚíÊ¢‚Kíë²ÐÓ›Þ²æJ�oyý±Ñ»*§ùô(ˆ¼—2׃áÃú­æíPtà‹›l[j˜º=ðªmÙPK/½¦ÖÝu˜z¯x@”9~@˾¾'vAgc—À_xª±O4Þ7¦/u
G"ffG©‡B›ŸW”µ>ºó^ŽîúZ!À7”ôÝUÍЗƞ*@aàUUóJsº(ªÞ*Íü]dÅD¶!³²ÇâW*©µ¯u2tSÌ•”ößįH¿à“œ”†èÒ#6˜^wÌšd”©Û(=³ú¢=ðimGëòN›­}P
+0B
+‡cG.º‘'`d›'ÏO0ú:hàN_Òqõh
KµeH–°˜3åíZ+æÌékܧþÄ
+'9™¬â,ò#&ÉMv¯+j<N²·qýzºá2{»<¹öëGzÈܵC„ …$Ð:“	{Ÿz0rå…ùýœè0ˆý8€¼;N!Ñ“åDs\µž.»$õò´‰¯ãW!8À™«£€^ı§óÞJܶ
éÃø¹7æ\�~wÿð�¦2ú˜aÑuÏÛHÚز*Œ
k°É16!ýršC‹¸Ñ@ÐdŒîŽØ•¬Ç4î oabQ‘7bÚƒN ¶š%BH9Þ4©/Le P--1¸¤Éë¡àŽÃil;*aûb<ŒóP/q
+cKüž|*,rÀ�û°Á†‹ótÞB¢qà€/²Q�¦ÖAÛ\*ôÚw3SFXûÔ¼£Ô)8Ü;ÑŒçœ\a•Í11køè�;Ç��[xFÇß-U�×îË@¸!(ÓƒáÍ`C;�„©	”À8‚ä
ƒ$çÈ‚„ˆ[XÅìƒ`˜QløL68µ·*pé.EšÄέWŸ){Zoºv·.àè
+äd5Çwí×óŽ™-G€
ú¥zjÒy¤fŒ6ïhÆ”%5Hpmiò®ÚŸÎ±ŽW,T€õAš9ÉtXÌ1ýÚjÊ¥ˆ¤ô¥ÌœˆòšóË¿¼E*"·˜÷q	åòxøa(�¶šðCŽÅ˜œèKgç±Q̱ÑȤ?Tÿ2Üy*{Ö%@	L×ð{²+8Ìkqø­*(ˆÕV¸vÌT/Ü9f9‚ù"¸èb¶¸‹
³·µÁEü‚•”Ø
+‡TT”ŸûëÐg”«‰´5EFv+C˜¸ a´žB
ƒ1‡»Â#ü�©,øí�È&œJ 9�`{$ÇXX¼ÌØ8öS¥£´ûaÏAýóÉýÙ»N
ëà5TÒŠ™VmÚÆ0y
M�½ê¦úâlF]ítÓÏ_FÈTVŒ¹¦3L>²)ôS€§³J€KÍÿg™çgñJ`Ùyg	RSúiŽœ
L§e8j	R6êÀ.ÕýqÑ|׎™
+%8LVì ” *Œ
+&
âN‰°Mó|®8Ø‹iK…mØš79K(H~ꊊéØiA-j’~+¬üâ–Œv�(9•8ÎV¼Ó´;)Ê
+##¸bV¶XÝom|‚—ñ×–¬p5qfz*xŽ°ØžØ_
+AîO†–H6ÉDžÅS0P—ú“¡¦cZDß�-“bËЯ¿Uš:%„$|ÃÒ
0UÄ„Ìň¸â³Æ_*ø'" “ÇÃmI
[F¿½¿&p^:ÿ'³€d†UCÜHµ*{œtUhÌ_H3GZßØÚŽQÄ6[æ?ÌïJˆ`PªByß·´V §Êƒ-9ßQCÀJÀ.]ŒVæ<¤gXÇ‘Š	öao’õÅ®$ÃN©7ê¢í¸j)l€°˜’BálÑþ°B§ã\YNcʾpAÛ@8ÎF}ûßBÑ#,&Æ,¨’qÔP¡‹V	!¨ër)S�ÔÈ·-…ÅŠÓ\øn@ÓÇ!/4Ù¦Ok÷üª½º=¾Æ€@J4Õž†Ð{1Mú"–õf~àÅÏ,¯¡7„7ŒmW‹¨xÓ°ê` :"£HæÈs„Œ"™ £�„Œ.¢NƇ6V»@Ý⎺.j¶äCßþ:DCÕ‚`V
-cÝ«FgÃ/å¶jŠ¯þÞדß� RÅ8hSwD§0SÆ:vô*²øàä
+^0d~œ,Ĉ5ˆF(,Ú|ÀÈ­]¼ÇýÆ|BÎI„@„qHð°ž7�o¬*žQ¶A4ûÍä…õa0îWWÍvb�6C«—~ÙiÔàÙüw—ñ×:WŽŸˆSNœ“ѽÆFxBùi˜
+ú!G‡·½\@_x¥
[¾5&~(Š7,ûol
+©mø¯(
¡Ÿ¡AAÉM@rgJ'Ï¢«P
+ó§ñº«¾¸Ë8‹W‰=öÃO¿PÚ¾
 endobj
-1008 0 obj <<
+1063 0 obj <<
 /Type /Page
-/Contents 1009 0 R
-/Resources 1007 0 R
+/Contents 1064 0 R
+/Resources 1062 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1001 0 R
-/Annots [ 1012 0 R 1013 0 R ]
+/Parent 1056 0 R
+/Annots [ 1067 0 R 1068 0 R ]
 >> endobj
-1012 0 obj <<
+1067 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [464.1993 519.4233 511.2325 531.4829]
+/Rect [464.1993 488.466 511.2325 500.5257]
 /Subtype /Link
 /A << /S /GoTo /D (proposed_standards) >>
 >> endobj
-1013 0 obj <<
+1068 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [55.6967 508.4843 105.4 519.5278]
+/Rect [55.6967 477.5271 105.4 488.5705]
 /Subtype /Link
 /A << /S /GoTo /D (proposed_standards) >>
 >> endobj
-1010 0 obj <<
-/D [1008 0 R /XYZ 56.6929 794.5015 null]
+1065 0 obj <<
+/D [1063 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 146 0 obj <<
-/D [1008 0 R /XYZ 56.6929 584.989 null]
+/D [1063 0 R /XYZ 56.6929 556.0057 null]
 >> endobj
-1011 0 obj <<
-/D [1008 0 R /XYZ 56.6929 551.635 null]
+1066 0 obj <<
+/D [1063 0 R /XYZ 56.6929 521.4772 null]
 >> endobj
 150 0 obj <<
-/D [1008 0 R /XYZ 56.6929 396.4263 null]
+/D [1063 0 R /XYZ 56.6929 361.9951 null]
 >> endobj
-1014 0 obj <<
-/D [1008 0 R /XYZ 56.6929 360.8629 null]
+1069 0 obj <<
+/D [1063 0 R /XYZ 56.6929 325.2573 null]
 >> endobj
 154 0 obj <<
-/D [1008 0 R /XYZ 56.6929 173.1662 null]
+/D [1063 0 R /XYZ 56.6929 133.2872 null]
 >> endobj
-1015 0 obj <<
-/D [1008 0 R /XYZ 56.6929 145.9427 null]
+1070 0 obj <<
+/D [1063 0 R /XYZ 56.6929 104.8892 null]
 >> endobj
-1007 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F55 970 0 R /F39 863 0 R /F48 885 0 R /F47 879 0 R >>
+1062 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F55 1025 0 R /F41 925 0 R /F48 940 0 R /F39 885 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1019 0 obj <<
-/Length 2880      
+1074 0 obj <<
+/Length 3001      
 /Filter /FlateDecode
 >>
 stream
-xÚå]sÛÆñ]¿‚o¡2æù¾qˆŸÜDi”‰ÇVÛLãÌ"!‘5E($Yéô¿w÷ö8€ )5Ó§NÆÁÝa±·ß_”˜pøOLœa\åz’åš.Ìd~sÂ'×ðîÏ'"ÀÌ"Ð,…úÓÅÉËoU6ÉYn¥�\\%¸ãΉÉÅâ—é×ß½~wqöþt&
Ÿjv:3–O_ó×S!ÄôõۯϾ¡Wß¼ý@‹oÏ^Ÿfzzñ—÷gp"œ6¾‹_~x÷ÃùE÷ůߟœ]´”¦Ü®�ÌßN~ù•OÀÔ÷'œ©Ü™Él8y.'7'Ú(f´Rñd}òáä§aòÖ:&£3Nf#â‘jL<&gVÁ+Ïùæt¦ŸVÛSᦋr[žO›ŠŽ‹ù¼º¹]¯êe8_®ê°”–%�!D±y¤Vë5×eCGw·áÛ‡€ÞÔtT]Ñɦ¸)ãWÛûr[ƒ´µË§?nÊ
²€V—áU8@z@ “™,7FzW›zµ
-BÌò�aΘȄìQZ~.ÀIKž8‚RpÁ¬È[”3�‘ýîâ–Ž�­¥b�OBîØQ]ZZ²
Á¢U:ž¢%omgAX$S™qQj"ZR
 "ç‰-á®E‹²%\-‹û
-¸ K{ñƒ©CºäÜé 0u›)ñE›)qãx6I{)n"•e	 #Ù1UÉýä>/ß]®WsŸ”ý‰ŽdhŸ\�Øc¼…kCµ7ÞS’Ù¼õä½6k3.žÉÁs€…ðÉïÕ¦ôe‡Zª>$[‚|îÖâ€T\Fv@×
¦¾£FL‹ºcÖ¿BáÓÉwÊÎðe¾¬º�.3°s3Rë(¸ÁRn,@ª”<zâÃÃÃ	äx—Í�ÉU˜Ü˜«æöNz°*Âcýè=D‡ˆ7[Ó
-Š–e±¹ö®"<So~§â#ÛϹ0†eÐ7DVØÍçgµ„èkŒî'ØÃ<X¨
-´ÇäåU¼ð/<"lìn�ÙdQ÷
-®“®|Ÿ"Á¤‹:3z°jÝ�GÛ!ŒCõŸRÐ2Jy�GÉ·Ïu)'”L]ŠØ¨—äHH:U+þô¶œ¯(Øñ雟épGïxè«{J	V0è
-_©ƒ©A˜[ÌÛªÃ3šÍ?¾ü"—3.=½­ MQ‡o(GèËuËámˆå�­L˜¦MY.|^ÂÏÊyqç³
--Âm¹]ŸŠé£ñùÊ[wÓª0á©Ö±Î$žï› í8L=t?/§þ`%ðHiž@ù
-ªºìIú³ÏÎ$ÿ¥þ08Kpó<ŸÞà3hóešf8™Nf8°iìbÂ/­xN¥|Šýï°|Gÿô?�ájQÖóíê’þ,®º¬îK,ú�˜¾­š2¢*š¸ŠDŧïQúÍFÇoE×Ø%?¿4 ½_ŽÓp·Œµrl->Vw
Ñï­�ø^£Œ¿º,‡ö¬…cN+7‘ P…ÿCz¹½žÐâ}bÚ-ü,ý`׶wñ¢ >`¹RLìPc!âä}bv¼+£`ˆ+ùiXA¸4Æ
Íy/_
ºö¾à÷Œµ`Î9*‹ùšÆ|1
Ö´ýWfàœ–ÁÿùK©_…Ãéá¿_E›¢1 î£�é´�>f«Ûzv]Í–å¶ÜƒŽrFu‹à-Žt’Ùk¢cc¾sLÐ40YVô–W |GX
-Ã?�1>øÿÇ×%&
�·srÜŒ·ÌÉ<‹D!/rÇqÚ?ØÛ%ý?mwendstream
+xÚå]sÛÆñ]¿‚o¡2æå>�CòäÆJãLâ&±Úfšd¦ 	›¨)€! Ñj§ÿ½»·wÀ
I©™>u<2îc±··ß» ˜qø'fÖ0®2=K3Íf¶º»â³÷°÷Ç+áa
hCýáö곯T:ËX–Èdvû.Âe·VÌn×?Ï¿üúå÷·7?^/¤ásÍ®&áó—¯þr-„˜¿|óåÍ+Úzõæ-
¾ºyy�êù퟼�aµ±ð^xóí÷ß¾¾íßøõö›«›ÛŽÒø6‚+$ó·«Ÿå³5\ê›+ÎTfÍì
+¶û7Á’T8_9äUÛ
+GźØÔ{áÁ2Üxº-›�_ß”
*£4^°Ös^8”H!.7EKK÷;ÿîÁ#…�†–�p\Aý	oíQ Ym³ùŸªb„Ìã‡ÑÒoÕþHϤ<Ÿlǘ¤Ùün8HÎmã`à
‰XØëïi§Ùå«Þ4ujŽûÝ«5Œö©ÅM¢—–
ª¢�eÞ´eí�GB¶Jʺ)WF§0ùEJ½sõÇGœ/KÞÔ!+Ø*¯üR¾ýàG5=—5šŽ�IÍP›Ê€Ê³íEЭ‘²½úîo“ªEfi¶3/aœØ NX^zàU]ý¹|O—_ÓªÓGx¾«÷bËšäáýßî‹}Y8å´�N±k;ò ZDL™©$	.´)ÛB°Žìc�kKl"=ø‹	ŒmãÝ~¬�ˆYþ>Ì)©PJŠ,q¥àài…Í:œ�’#— ?Ëc>È'a!Gqi™�Žhp�Ðq5(ÚMz
Ç"™‚8ähR "‹=Î:´8!]Âùl9ïU´E
+î·ÚÞ¯Ëê½ÇïbЇ½ð™Ð1J5màŽË†»Hé’Ö)qâx¶
Iw(N•Eñ ÑGÚ.•uç��»¸|¿Ü–+”݉N¤#.¸ZqByÁý
+Û9S§¼¦$K2¡/él’rñ,G–Wð¯¸\Ó0Åd}H¶þÜo×tq®²ö0Í=%0bž7ýeÝ2Ÿ–ˆ¿+Ÿvú7½óE]
+Ž“v¢N‘ Rëu‰ÆŒ¬:3äA7&ãP¢?Á¦ãVʳw”œñä¹&!WÆ&E×h6dHHº¯0quW¬Jrv|þÝO´x$w\tÙ=…¨£�²ê($¸ºÔ©¸¹õªËšÑ=£ÚüýÓO‚ré)åÒó]
aŠ|8¼C1B_®#_»Þ—C´2Á]`𘪢X»¸„¯«üÞE
+õ’Šc"DŒdñbTnbBÂëê8¿¨i@Têuï÷b3TyúBá9¨7…

+/ª}µX
϶N‡ø¯=™Ÿ4!µ¤§·¨a)šwŽÙ�‘àsȳÏ'ŒŽGûåškŸ:šÀfØ,ÕÊ�£ys½H8aƧàôš:Èû§ºq‹€tpÝ7¨`J_—Ó¨x¤v–v~•Ä‹#—±8ƒÙäÛw~Í?AÓ]È¥YYuÃB—6Á¬¯ß•Iz >-‚‰ïàÐgEîÅbRC]>ijù‡ÊÝŠgd?]ãˆÛÞ~pÑß©ÛÎùo—.´MÈÑc[gØ�ÂÔ ë@
qQKG¾DØûíµ˜?º²Ë¼uß­·úB‰gÇ$r8GÓŒÍÏñiØXñ
+<‘šGPÎÁž0ÓQÏU®QÓ%>d•£öxw½{¤yÒò~è2«<;pcVÅM]Ü},åûXèj›Cähpç‘ž]²7ÄØçî2í3XîËŸÿ¹Õ(,xbSz(œô…‘Ç
+|_æ«]ûôß;N]W—¼hs²½*!DÚŒSº¨0¾‰Wk7ªéé;•0Ú]», …JXÌQ¹;Í–RÅlØ®·ïPS„	¡wlÂŽ5´ƒ2N<�ää+ á`ÊvE±kqOä?³‰
+I!ñNDÅ/e¤ó=m�Eû$…÷
+Ĩ	ìSgyT©¸¦y32ËÛ>xßUP�‡2Çm‹U[>xHäÍÈõÄ&œí®ûøUÀ
‚Ãv
+“7� `©gŒN¡wbAÎÇü&ePÁ†¬¶ÿL„N|&‚š
+ä•Pn»ÎK0‚:#Á
 endobj
-1018 0 obj <<
+1073 0 obj <<
 /Type /Page
-/Contents 1019 0 R
-/Resources 1017 0 R
+/Contents 1074 0 R
+/Resources 1072 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1001 0 R
-/Annots [ 1021 0 R ]
+/Parent 1056 0 R
+/Annots [ 1076 0 R ]
 >> endobj
-1021 0 obj <<
+1076 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [417.8476 228.9788 466.5943 241.0384]
+/Rect [417.8476 181.7231 466.5943 193.7827]
 /Subtype /Link
 /A << /S /GoTo /D (sample_configuration) >>
 >> endobj
-1020 0 obj <<
-/D [1018 0 R /XYZ 85.0394 794.5015 null]
+1075 0 obj <<
+/D [1073 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1017 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F47 879 0 R /F14 685 0 R >>
+1072 0 obj <<
+/Font << /F37 791 0 R /F39 885 0 R /F23 726 0 R /F41 925 0 R /F14 729 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1024 0 obj <<
-/Length 837       
+1079 0 obj <<
+/Length 853       
 /Filter /FlateDecode
 >>
 stream
-xÚÅWKSÛ0¾ûWx8%+zÙ–Ë)…Жé0”¸½
-g­Vé…³ Œ´QXK`ZyÊÈ
+xÚÕWMsÚ0½ûWxr‚ƒ…¾üÕœhBÚf:™4¸½$9¸F$Ì›X&	íô¿W²°‘ƒ€PÒÎt˜
Y^½]½}+VȆâƒl×^ˆCÛ)p!rídjAûN¼û`¡¥�S9ºÕûÈê�ßAèaÏŽÆV
+ùLšó�'ÀŽäÏ[Bì½eK¸]—q¶Ð]»PïØ8ž§Ûš?Óe„¸@Þ WØðxðEeuG£> A€›;HKôØ
 endobj
-1023 0 obj <<
+1078 0 obj <<
 /Type /Page
-/Contents 1024 0 R
-/Resources 1022 0 R
+/Contents 1079 0 R
+/Resources 1077 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1001 0 R
+/Parent 1056 0 R
 >> endobj
-1025 0 obj <<
-/D [1023 0 R /XYZ 56.6929 794.5015 null]
+1080 0 obj <<
+/D [1078 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1022 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R >>
+1077 0 obj <<
+/Font << /F37 791 0 R /F41 925 0 R /F23 726 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1028 0 obj <<
-/Length 2146      
+1083 0 obj <<
+/Length 1946      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥ÛrÛ¶òÝ_¡É“4	a¼"�>¸‰“¸—4'Ö9/M'‘�ÄT$^ì¨gοŸ],@‰2ݤSkÆ
-ƒÀAv·ÿžìš£S:‰‚”E©H¦”"§”I"0Jùßw(òDÀ$÷Cý³®ô‹}þ¤-:Í™þ¢ÊýN³¬.ŸÐÆL./	Ð;ß©;;5¤ð
-ΙŒ"1óhB6é{‹Wª¶ÓÍÀ�ÃF¤uáè>)/‰Ÿu]^&ñÕnWß{]£ªv­›�]Š
-.©Ô®ýŽÖúËxmÕáM2ûMº“ºú�}Mþö’îøKùI•íHpUÕÝV7W°WÔÕÇmÝvKuXé±äþ˜½¢ÊIMŠM^¾'<ú'\@ðXœ›Š¢Ø&ä‘3‹¨…!n£Ûzw©Ö„㔉0ä÷ƒùuC´õ羸S;]u
-´	²gíW€Ùtn¯8§Ðê¬oŠî`Ù´ÐnÞ¾d4½é¦Ô˜ë6kŠÞðhžmUµqÃŒè6f·®>ø¾Øô�¢‹ˆ��EPöä½ÞíÎ [ÕM\¡HbZÐü—&9A×èÙ8É‹5Â1hq»²ôÖú¨¸gS"U¶ës²ÃiìÍ¡:ÓmkÃdMcFÔTw<3Ò6
-‚!æò&tÏ
-™XDËU7ÚгvW(šL7ÈJ™
-KÖûcâf±$îfˉ&Ägqdd<h< ;‡'ȨÜc>’ᮨl–­÷��L\Ø&¥¨ŽhÊŸzœ†»IEC#Â÷#Ë!$â)IcûIlqر!pRPGÊQŠ
-ð�eÏ¢™˜…¢�“Yéî^ëŠØOŸ–�XøÎèØò	nEȤ/ϽgL	_|qzBHL÷IR9XÞž�ð*bS5«Šæ<\¢}Íû½±üÐ×ÕsêÉô¨>‡îy”>q<ÃÃ5&XHUKטpB7à¬ìÛÎ:§>kÚ
ÉÕöUíê8ÞѲ	ŸÅg@ÀÒ4G¼ìªïêŠpFD¬ÓaëðU‡!b¬ø¨±­¦<	EXÜØ‹álsôgX)¸H=Ð8-°åä1ÍW‡N»ÖSÎßürõÂûåeD+Òiitm¤½S­ê;SÉâdþs
íÞdAµM×âµ;i0"ª*¸cºmê_ÒÇNkÕ…:ŸÔ6*GŽd8[w¹3]©p•'¥úR”}9ÜAxOmŒ™mÁ�ˆ#.,ÃE‡/D!15ñÚ‘¬/©á=¦:×#�x\^@/Ô¹„slÉx¸µ±yŸÙ“Š†£a­“cƒf½3LÇNEÝ9U^µ�q<8
þBo+OѸ-Uæ•yd¡+ûò©Xô7¿Þ.í�“Ø›vçÓ›É�¥I˜UKNÏéÂ&öÑñ°~É
+xÚ¥ÙrÛÈñ�_ÁòYeŒ0ƒ{ý¤µd[›¬ãXL^Ö[®!0$Q‹ƒÆ!™IåßÓ=Ý 
Ú�7¥*ÍLOOß(—.üÉe×Küe”ø"pe°LË…»ÜÃÝÛ…dg@rÆX?nWo¼h™ˆ$Tár³ÑŠ…Çr¹É~Y½~wýasûqí¨À]ùbí¡»º¾ùçZJ¹º~ÿúö†®nÞßÓæÍíõ:òW›|¼EˆT	¾øåæþîíú×ÍO‹ÛÍY¾±ÒõP¸/‹_~u—¨òÓÂ^ËG8¸B&‰Z–?ðDà{Þ
+6WWhLÛ5yÚÑiDP§©i[´íH)’ P#	“öM›×ÕwóWþ³ü/Dgø
+!¦`9
Ÿ�“GÀ�ß(O$èb„þ«®XÍmÞ)ÌW]#Òº|qVHzcKµƒ÷…~à­%…,®öÝéÈx¥nÁ¯æÛåÝåɳ«k+Ë«9�É
]£«vgšïµÿÈVêOØJÍÚê0€µÙéß^�ßÕŸLÙN×UÝLóyw?ŸuÛ}.õik¦šÏÆòŸ3åZòê
äì%��µ'…ù¡Å¹«¨h�Ø„<É}
5?�GˆYR`‘j7C8Œ…ò}ɸŸÜÀ­¢m¾ôùƒ.LÕ
T¬ñµ6ÐnH¡Å?Ìæ@U‚º7èYž­ÑMz »|“¦d’J—¦5ÍÃ`e)!C
ÿÕœ�ŸG÷¾�ºÏ“KéÏ»"
+-VÒ¼;±˜ýñîý� í]7gÇÌ´i“o‘§'ƒUzÐÕ~8 vÅÀ±·uõÉuÕ¾o41F B
+FÐüòÑÅÈAw3,4iLÚCÓ&#èc7Y¾C8¦-^WLog.†{9Yy•}F~§ÁÑ>ªm×£DÙÑš5Ý]ÞL¬
€ß̉é*£Mß>�Þæû©{
ö˜wÚ‘“É!eXÉñP¢
+eS	´™¶&ÐÖÐÚ·f×tKn`v‚:–§ŒqÌtgЮ·º&ùýD‡³SÇ$ô7”’Á]øäP÷EÆÂÕUG!Ïb<?ñÙÌ�bÎü(¹�G(	J(Sž_‚—úŽÀwö>`Föf"^æ-¯UÛÛÇ‚’æ�ß`Š0�ð&!@�ætìê}£�e^òÖ>É�îP¥3‚lO´’ÿpge�ðØé†Õë�¦ÉkîVœÈŠ3t˜Qû–žðbü öÔ²‘¾m-~ b•DŒÈR�Rå™#§öT´‡\Óf~|�@6IbÅd�ßf8Ë@Dž8cZÎŒ!®}ÿLæ4CÆ�Ñ>gâ'ƒ7Ö“s1,òŠ«l}ì83ñÀcJ^]ÐT?Í´w³††QD(é,!â9MCºQÈ8â2ò‚
+ÌKÔÂKàÔUÃd $ÏoMeé(ÎýA7†Õû˹üï•nuÊåüƒÎ›©&ï`Æjç§’Æ<TAÎ{ž9«/
φæ–P�|Ïâ1šÍYX±à ÚS2[Ó=S‘^2ö¹J„繃Óq"”3Ò*_$nò4z¦”ð9ŒG„Ô!Ÿ(NÎÞ�Ñ
+^Ebêf›C“Áš‡Gô¯ÝàÀ7Õ?ú¦ú�¦rSª+a~žÄä'¥|«ŽcexÆ¥j3Œ
–nˆîʾí88Í“¡¡=#
½}[}y´b&fqšŒ Æ¢ècç(»î»º„&œ:þ$þý€!BìøYãf2JE8<æ8‹án‰g8iZ¤Š°8pä”!í·§Î£g²z÷óõkç盀Nd3$ÒÒ:Œ‘ÌSoëÛÉÂhõ×ƽنÊC6ˆaÄj70ê*xc§mš_âç^Ýæ
+M>1:C‰õ¾î¹³S©:nJý5/ûò̃6ðEµ·n憥 R±Ày‡ßˆ*Q$ÔLC-ÈKúüE¦»a´NE\–Ã,Ô
ç2,’ðq=c³>å—š–‹c9Èq@ãèôãiP�§™¬j¡â8ðâ…>®Më¡Ô©Sf
C·üé¥b0ú»¿ÝoøÁ(÷žû%Îþ|6ó»™{®×ÿ÷¯t—Ÿ%ýút¬Î?ÀMòËsCjÎ,ÚCyO%?ÿœ÷­èÿ¢ „êendstream
 endobj
-1027 0 obj <<
+1082 0 obj <<
 /Type /Page
-/Contents 1028 0 R
-/Resources 1026 0 R
+/Contents 1083 0 R
+/Resources 1081 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1001 0 R
+/Parent 1056 0 R
 >> endobj
-1029 0 obj <<
-/D [1027 0 R /XYZ 85.0394 794.5015 null]
+1084 0 obj <<
+/D [1082 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 158 0 obj <<
-/D [1027 0 R /XYZ 85.0394 479.27 null]
+/D [1082 0 R /XYZ 85.0394 427.2881 null]
 >> endobj
-1030 0 obj <<
-/D [1027 0 R /XYZ 85.0394 444.0186 null]
+1085 0 obj <<
+/D [1082 0 R /XYZ 85.0394 390.6298 null]
 >> endobj
 162 0 obj <<
-/D [1027 0 R /XYZ 85.0394 287.5734 null]
+/D [1082 0 R /XYZ 85.0394 229.0656 null]
 >> endobj
-1031 0 obj <<
-/D [1027 0 R /XYZ 85.0394 259.9325 null]
+1086 0 obj <<
+/D [1082 0 R /XYZ 85.0394 200.0179 null]
 >> endobj
 166 0 obj <<
-/D [1027 0 R /XYZ 85.0394 214.4637 null]
+/D [1082 0 R /XYZ 85.0394 151.3455 null]
 >> endobj
-1032 0 obj <<
-/D [1027 0 R /XYZ 85.0394 191.8161 null]
+1087 0 obj <<
+/D [1082 0 R /XYZ 85.0394 127.291 null]
 >> endobj
-1026 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F21 658 0 R /F47 879 0 R /F48 885 0 R >>
+1081 0 obj <<
+/Font << /F37 791 0 R /F41 925 0 R /F23 726 0 R /F21 702 0 R /F39 885 0 R /F48 940 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1035 0 obj <<
-/Length 2336      
+1090 0 obj <<
+/Length 2296      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥]sÛ6òÝ¿BÓ—HsŠ‚—éƒâ8©{M.W«÷Òö�!‰)E*"G×éï» H›¶“ëxÆ‹Åb¿b¢C&2™DIÀ4z²Þ_ðÉÖÞ\™{¤yëåòâÛ×*š$,	e8Ynz´bÆãXL–Ù/SØÀf@�O—7×ofs)d§—ß/Þ/¯~‚©æ€‚‹Wÿ�	!¦‹w—W¯péÕ»¼¾ZÌ¢`ºüù§«›ÙoË.®–ý;®,s/~ù�O2¸Êœ©$Ö“[˜p&’DNö�VLJyHqqsñŸŽ`oÕm•‰àLªPŽEŠ1¡è„…JªN(‚ÉÙ\pΧoÓ²M¼çSšcÚäUio	´T�Ÿ
-‹UæÉKÄ[¥µ™‡V‡ŠëéÛª¦C7—××D¸9æ嶦ƒ‘5œ|J‹<³7µw‚%Zã݈ªÅŠ‡û嚧uÝî
„Ë�—CaÊm³C`^÷îO÷mÑä‡bp·xJôA/Q<11æ€k�nºṉ&ìþÚÚdÀ‘ 	ÕÕ€¥¸¯šÁ-Ñ9Ší¯Ó+ƒß½3
Ç̶h&c±˜)ŽØ¢¨+ËF$Ü¥Ãhú{YÝ–8DâO��;¾ÇY<m	ÖìGU»Ý‘ö­YÄ’©0‰ál{ä~�&1b«Z² ².ä«#R'ÆÀó"%Ø
ÜÓ=±Pá×_—˜í,&Þ­@Î
‹%†²ÍÒ&eÝ:Ûr^¤B¸?û¢÷ÄËêpB1�´Q‡0¸
:«·cИזã¾/+gtÚzòz——¦~Ìwù®3Ð8DC�5(ãT9;
Àz]ÂœÍÂB"ÃÅÀˆÚÎ$íæ™°n]ªcƒ�½
.ózOvU[dþT„Y;²�ˆ:Öôtíñ¯w؈׾^¾ŸA|Ÿ>GqÔõŽF�)ÌaW•†æ¦Y?®ÙéF‘n®ËMuÜ�hÇ?¡oÂÄ	©¿ú/sz6Ó Hœ^}ÎëÆŸ'£ëõ>Ý‚.1èç9C$¼ì â‰r2`<L4aÙsŸ’H˜Ò‘êQB6å½�i+¢×iÜF‹Î
-êÓ(êܵ>WP	s!ã;•†c$$ÕK
9¼ÊËÆÅv_ûÀ²s[;ðX^áÛ2ÿŸK7
-r¥mÓd-Äô—…½!ª>.Ù14 sÚ˜zRu�nýŽ|[¢”"ç'CÖ-—¶ëx>œÉò
-%Øõæ1$¡#ÂR»^Û¶(Nçc¬òMæBBt&ƒû!¹—õ]*tM;^ÝcT?æÈþö_š�ƒ.CEÙ‚µ?��‡öþsmîçå§S°�2<¶|Ö8JÏL��]\™æÖ˜'Ím…›0h·‹¤¨n°>åwfeÇû¶n�þŠV›ª nwžü,5•g¿¾²‚zÊFä|yvnvfÄÉ…�P�„êÿÍľF8ŽÕ:‚©H$OÕ:‚é(öXTãåwk±ë÷ÝÅÈŠÏUÛý“cˆGJö«,ùd•åE½9´×L�Ö*,Ô:æf¯[
øí�”Â{Oí‘(P^üùw«†·çÖ5JèH�•¦'­hé@R5Šmuß6¸D�-ŒP°ÝêþXÓº|ÉXUú¸˜wsàe•¡eÕ \“ºG
€¦%w.Ü#‚í ª1Èßðž†Ù3/)Ó¥ËùC™òN_Œ
Þõ˜u%,P±zº„W�ô%7È5s—Æ,c5Ðe™¨KY=·ÀrŠSdöckj’”óæÁŽžG8)g5
θ͋G+Zîr›[um@äS0€êƒYS"¡„®XsýhJrq2üªf‡Ø´íÄg`€T‹6ÑÕ9˜Âêa€;§jîo~ÃÛE“.Þ�5.ß¹ÑàrÐa€N÷VÐ3‘uÛݳ„�4PCeÚàs¹eÖ}wC@^Žµx«aðdDÐg]^Zåm[ztÀ.h»±æîö#8X]äöçöìÑ>n!p<A„ÚSñt˜DwŒÓ¥“÷¶$­HÅ´ÖáÐ.‡ž3f#ŽÍp¬¾êÚ£ÅpyÚ ûE�¦"ˆ^´©œÁ· ´öV¹pEŽ/!8«âé’ÇöoV8zD(
-œ>$fN;ëÅ	Á‚ðÍÈ=ù d
+xÚ¥YK“Û6¾Ï¯PåbªlÁx|Ä•Ãx<v”]{½e/q”DItø�Ej&J*ÿ}h
+l$#¥<ÅiH$er´¨®èh
cﮘá™X¦IŸëõìêå[�R’F<ÍV½µB“„�fË_˜@Æ°
fwÓwã	g<¥ÁÍ�×g·?CWR`A†ë7ÿ3Æ‚ë7·opè͇;l¼½½Ça0ûåçÛ»ño³Ÿ®ngN¾¾Œ
+%Ü—«_££%¨òÓ%"Mäè
:”°4å£ê*”‚ÈPK)¯î®þíì�ê©^›0J¸ˆ¸Ç(\øŒ"S	RF™mrPìð{~ÀFѪ/Šû�åøD)/s¥òË·!ë-œ
+ÂY¨äQ+þcÓ´›¨ÿ9yÎdüœªd»+î³ÎÌÆI•v
ðA(Xð¡é6E½Æ½—ÅnÌ’ _t¥sßæ­ЊŒ¾O¥Á|߀MG'D2°ñ„1’JÉõvó¬Í'QˆÎÍëE³Ì—Øi»
+
+{èéü¢ÛYmxÁ<¦•µæk”ÚdhJ«d¾À~÷½G¡	‹cÂ
ÇR§Ø$+ÿ3{y+o>¿Kÿõ¼iÙç/4㟗×?üàQ›טYùûf>cWÉ	O„µØ7ìÉBABH�‹¦~l/gßó#fÇ¡ÅRIbÈÛÑD„�p4v‡#|<a�Áû¬Þg%.÷.¯ó]ÖMí·—*[{&ñP$õDÂq�Š^T[�0@Ëð³ƒÑ!¤§}ÙCÄ›E›RçE×Bñ°Ÿ@×ð™„!*Ídðòé×w7Ó©YX»´5£hعÏÊb©Ó‘žKC‘碒fm»¯0J`¸³v(ózÝm�X´==“ Ú—]±-º%�YÓDÑk4ObÓÄXW¥Ý®5Ü}T €DÌX¨m"%}×x´8ʇ•Ž-ôÖù’¸Åzt]¶�#fZé(~¯›‡›.« �»@CïßÝ8	ö†ÖmðXÙ¯7žpf	'"J“AU…!á	UÈÑ0v9Úìpu#bQf†¶Å
×»¬2"4øµêa]D@ÇF"ä�Y	`ÄжˬˎéFt	À¾Äd‘JE›ˆ7Íöà—ñwàC›íwà1ë--'|_7:è¤Jä€ ÑåÔÕñ™D§‰_†@Ã��Ø.šmŽ4²ð…ƒàà5 †ö."Õä1SYÝn›]‡”*‡®‹¶26;\Ú]‘¦ÂX
-‹�h2XX¾Èñõ6ó„óÛÙÇ1TQÁs2¶Óêò2ßnš:7ý¼[|Ý5¹F×LëU³«<ÎÉw÷˜šÐÑFê�2=K0$voÿ(ÚNq—4­²5xù
+`éJÉ9Äo©ñJÛg­‚¹d„RiÍPgТ©WÙ#€ë(²¶ÀúÄ[]„œ‘$@	˜&ÑüºUµE¿�DÊ_:müB1+×Í®è6•™[e‹Iµ”¯Î�Â*§ãw窉ïpêäd7¼KüýÊP¨;¢µ ü(šªLYèd3]åÅÖY~%A´©ÝoUz+÷)úü€ä×Óo’Ün}ˆQžåsqèbÄœ7÷9ñÙë®ÐE‚ˆBSl«–ýfê#{Û*µR]ŸO¦€o„è8Äå2Öƒ� þ<�' r‚ôI�Õ…”CÖ¹‘¹nêÉC³+Íž(H¶ÌæxWH…F+ÇLQ1ˆP7HÉù‰û�בâ>¸'ÉLåÝCuûb<.äÑ0ýì”{·öüà3•º‰ÁEø	–‚;`»lF¯O\_(ãÉI™¡‰ì=K€7EÝé“Ý>0ŒHi
+C9¹‡h?ƒÆÃxÿ¥Í£òE
+mÀ·lr3£n:ä‚€ë2ý 
 endobj
-1034 0 obj <<
+1089 0 obj <<
 /Type /Page
-/Contents 1035 0 R
-/Resources 1033 0 R
+/Contents 1090 0 R
+/Resources 1088 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1001 0 R
+/Parent 1056 0 R
 >> endobj
-1036 0 obj <<
-/D [1034 0 R /XYZ 56.6929 794.5015 null]
+1091 0 obj <<
+/D [1089 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 170 0 obj <<
-/D [1034 0 R /XYZ 56.6929 769.5949 null]
+/D [1089 0 R /XYZ 56.6929 691.7741 null]
 >> endobj
-1037 0 obj <<
-/D [1034 0 R /XYZ 56.6929 752.2692 null]
+1092 0 obj <<
+/D [1089 0 R /XYZ 56.6929 668.7722 null]
 >> endobj
 174 0 obj <<
-/D [1034 0 R /XYZ 56.6929 663.7495 null]
+/D [1089 0 R /XYZ 56.6929 579.8329 null]
 >> endobj
-1038 0 obj <<
-/D [1034 0 R /XYZ 56.6929 633.2462 null]
+1093 0 obj <<
+/D [1089 0 R /XYZ 56.6929 549.1878 null]
 >> endobj
 178 0 obj <<
-/D [1034 0 R /XYZ 56.6929 587.2939 null]
+/D [1089 0 R /XYZ 56.6929 502.9124 null]
 >> endobj
-1039 0 obj <<
-/D [1034 0 R /XYZ 56.6929 559.4406 null]
+1094 0 obj <<
+/D [1089 0 R /XYZ 56.6929 474.9173 null]
 >> endobj
 182 0 obj <<
-/D [1034 0 R /XYZ 56.6929 362.928 null]
->> endobj
-1040 0 obj <<
-/D [1034 0 R /XYZ 56.6929 335.0747 null]
->> endobj
-186 0 obj <<
-/D [1034 0 R /XYZ 56.6929 132.2109 null]
+/D [1089 0 R /XYZ 56.6929 277.7919 null]
 >> endobj
-1041 0 obj <<
-/D [1034 0 R /XYZ 56.6929 104.3577 null]
+1095 0 obj <<
+/D [1089 0 R /XYZ 56.6929 249.7968 null]
 >> endobj
-1033 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R /F14 685 0 R >>
+1088 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F41 925 0 R /F21 702 0 R /F39 885 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1044 0 obj <<
-/Length 2916      
-/Filter /FlateDecode
->>
-stream
-xÚ¥YYsÛÈ~ׯà[¨*žÁ`pÄO²%¯½©õndnR[ë}€HHB–h(YI忧¯ÁEÈvUŠUœ»§»§�oz¡à§©
”É¢E’E�UÚ.6û3µ¸ƒ±δÌYùI«á¬×ë³—oM²È‚,ãÅúv@+
TšêÅzûûòÍ»‹_ÖW×ç«Ðªeœ¯l¬–—ÿ8×Z//>¼¹ºä¡Ë¹òöêâ<‰–ë_¯¯°Ge0/
-bY¹þÛÕoç¬<»Zwü
eÐÊ sŸÏ~ÿC-¶ Ê�g*0Yj�ÐP�βp±?‹¬	ldŒïÙ�}<û{Gp0JKçtbMØ4Lf”š9¥Ø,ˆ
¡R.*–µø’ﻂõ-—¹æ»]ý¸:¶y+3¶es®Óe±iËéz¬�»-WoŠ¿¢fàP²Áþj±2a�†)ï<&+µüO\¹¯]«WøÜó꿯˜ðH°	áõ}é|K}ûTåûrÃ
ÞUFÚšKwÜlŠBD¨«Ý×JQF{/‚²äŸ�…kEò\(¹ò®òndyÎ	…àÂOù†‘ˆ£â˜LÊÂA)g¤…Sá-¹
e2’¤Y‹UÙÀÆQ¼
-u6béÄk»Yßbä„2tzFåZ8˜ºŠ”
-²4´xøAñT°� >_iþsÕ4uãæ](Ì‚0V‰¸«N–:ãzS8WVwÜGÑAÇËõÇ÷?pOg÷PßÃÔüŽ|Z
-!0™mÅw-”•,-Š&ßq£hx»Æ�¿‡Yº|Ëù³û5Ç»8¶è!;îWVuµ"·
-aë˜*h^Åå±ú³ª+^…‰

-hÜD)«ûå¬uå„$[	,<!ÙfÆ2Ëöf-$¡"âD-hžøƒþά¹¹©·OsE+$j.__\"*B~î!
B™ó
-¿…iš�¡>Ñ Q¼Z4�^€|N>”<o�Ý*AÑQ�J–Ûš(C9v=ä»3ê9”4‡ý=ÃÑ3ŒÝHO§gêÆhC!"bC×@³*iE³*!ÍΘ9é9²¨g pƒTŤ¤Èú½ 6TqÔ;&Ö'*îW÷*††HY�ʽ
påÖ7n¹dyq:/5yuGj�³¯‡©NÉZy%kÅJÖ=¸âQbLûsÒ�e©l¨b誚¢bí�WsˆÀ”º~ÿÓÕnQdí ÂC
låHzóŒÎˆD
/½nÿA�b´†£ØŠ)bÇÍ8žè
-Ÿ@”ÂYA±ÝBÆ”%yõÄŠá´cÑÓu…Þ¨~{9ø¿¸
7¤¬3ļ7aײj%ñ!T󘸘 Ë?¯1Þ^üº~'0¨q^Ã8}Žª¶Ü€+n‘Ú
-$,‚ªD\†ß¬3	(‰EŠÇæ6¸ëYŸ”±¶&pr*_‘%Š£oŠëÔŸÿ¦ƒrµ]’Gç¿O-ÛbWøª‘"(yEøgÖ¦*)ïýs‡òCY�ê•<¯èÐq¦3º0ÌÛ4Ì­�¿Qe£9“6–&•UÙ–0±Iw‡˜247»’¼ëK¡ìpŸŸN}Õ–òÓ`mï!Söp¥¾‹ÿÌóùX4²úÜwGÙº�°'Ú4°qœ�í*?ˆø‡¦¤×A
-òÃ#÷{Ã÷{,ˆ§,\®†˜—žúûÝÊjÍ9¡z‡e ,œÁL`"zøÃѲ•T¶ágC"À`L&{¼šà�¶Í1ò1{³`dvžw
uQçI”V)#Ô.Œõ°gª7…lÅÏ)ñòⶥ(¦ðI�j>‰½à'”Nb°ð�7
+1098 0 obj <<
+/Length 3185      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥Ùrã6òÝ_¡·•«" ;O�'™“¬GÙ­T&´[ÌH¤"Röx·öß·/ð2=NÕ–«L 
4�¾!½Pð§©
”É¢E’E�UÚ.6û3µ¸ƒ±oδÌYùI«á¬×볯ߚd‘YÆ‹õí
+n^l6®i¸}YWí±Þáùa3`½Z¬Â(È"ú×ïÞ#[S½Ìw»ú
—§áòÝÏ+Šã¹N—€×5ª
+nóêÎÉü¶fØ�ãosp›ò£R!ÑÊŠ..àFáp¸*Û²®	bfzõ€^é@Ù$‘^¢rÅóàý¼0
’Dg2ívS$i$ãžÜñqK˜$ô›ý1ƒn#‘áXÐܺã¸òPgÑð¬"«€b›-V�ÀÔÓ¡È[7‡$6‰áÝÌÅ&A¬;ÒŠ’ïmÓ–÷®
�0Ö,×ÛYÛå6§Fæ*n¹Ï­«
+º/˜@
+Pb7ƒDø
+?åcFs�¡FwÊñÂ}Z4™ <QÒ,�’T1Žâñ}ÿzž…ËúÄìóG‚ª3ƒ™¥ ³§v†}Ís¸w¨Üñö´›9Oˆb¡�Y¿:Ô»ró8sž
ˆñzÚ´0yï<u`&'+Ò`‘¢0Z€rÚ€ßÁƒÇ»7®Φ›¿.`g3$ã)^$ç
+|-ZaÆAô„¤4X·IO¼^7ë%Bž`CB‚ŽÏÿ¸Š”
+²4´‹XÃ4ŠÒÎCÆâ!¯ŽÇúؼìöØZédy K®Ñs–ÕÃÈ<èØ[<€t‚í=LÍÙóAoC6&‹Ÿ<íZ �‡Kݽ;æ;î¸#owD“féòÝ-äÏî#ØÞ¥aQ
	r¿²ª+òŠdÿþD΂]~È;�†nãŽ@ÆO_! #D
+!Ûè+h^ÅßSõ©ª*^…ž#|ฉRf3Âå®
+J–Bè<"Ùf†ce»…YFJhÈñŒD;ïÄš»›ºp<­q­ ¨ùûúâ
¦HoÀâ |s^á·Ð#B·ã ´'4ŠWë
¡Ó N"òöÔí¡b8(*ªQɲ¨	3ÀH¡tŸïJtMÈçPüÂ'|†%Âg»HÇg‚
+a´¡ ‘chÀY•Œ8ƒÂY•ggÔ™øYä3`¸C,ŽbbRäQl
YõŠ‰í	‹ûÕ=‹¡#'‰,�Â�ʽA@Д…ïÜò—Ï‹Ó1ò¢CÂ"Ê„�­qöÔL…3Õ1Y+Ïd­˜Éº�®x”Óþžt'Y*²àCCWX¬½ðj6ø¦®ßýxõ÷ȲŽv�ÃCdåD|ó„ΉyàkñANÀAÕ’@�("„ífOx€vžÐð¸(Dmˆ³È|¸PI$)Ï
+©}èM¶Z¾�ÄØKʵúÖív{ÒFœâ>£LÜ9Ob�F‰Þx²úK¸OËNˆ;µ¬Êïeïœ
ó$๔/G{¢¥¤]ù®ÝÖ§;¤Î 
.�±
wæ–ÐåÀ—•ÒÌÑ�ÃD·áh¿1	ƒÃ2Šñ
Å?øù7\k49»õÖÍe¿~EY—
+È„uÒÄÝIv'¬‰6
lO<U~�ãŽ%UÁ( Ék8º0’ÞNïñC4eár5y©ºÐ§w+«5+ä`„Ú](f¢ô&¢ÂŽ–­|�e.ŽÅd²WLhÛ-“7ŒŒ*Ϫ�†¶°ó‰•V©¼4@®À¡B¦|ÃQ¬FS5%^^ܶdŦ‘d8 å�ØW\A¹a'ùšò�“‹Å©ì pÌUâN
+cýaÒ±ãIׯª‰ÏñNý)yQhTŒ—ÈKmjäÁ-Fà[Ÿ‰ÿ8aÛG&öRPÎ~©GáôáQàYpb)hÈHî�¬&{@’*âCbÚp̆¡¨}1Þ—$ð}î3eÍAà/A¤¶D‚´Óƹ´9õ±•bâ›÷>\]òÈh¥×­Ü׃qñ°à (èe
+Î&ßÏ&ü �Ù"tíM6t¯%Í+ï‹Ëûrçº(£|p÷ÐvÏ6G	Te÷Ó?
ûÒ}÷ˆ1z–™­
 endobj
-1043 0 obj <<
+1097 0 obj <<
 /Type /Page
-/Contents 1044 0 R
-/Resources 1042 0 R
+/Contents 1098 0 R
+/Resources 1096 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1050 0 R
-/Annots [ 1046 0 R ]
+/Parent 1105 0 R
+/Annots [ 1101 0 R ]
 >> endobj
-1046 0 obj <<
+1101 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [418.3461 669.297 487.0181 681.3566]
+/Rect [418.3461 611.3335 487.0181 623.3932]
 /Subtype /Link
 /A << /S /GoTo /D (dynamic_update_policies) >>
 >> endobj
-1045 0 obj <<
-/D [1043 0 R /XYZ 85.0394 794.5015 null]
+1099 0 obj <<
+/D [1097 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+186 0 obj <<
+/D [1097 0 R /XYZ 85.0394 769.5949 null]
+>> endobj
+1100 0 obj <<
+/D [1097 0 R /XYZ 85.0394 749.4437 null]
 >> endobj
 190 0 obj <<
-/D [1043 0 R /XYZ 85.0394 648.2128 null]
+/D [1097 0 R /XYZ 85.0394 597.4103 null]
 >> endobj
-1047 0 obj <<
-/D [1043 0 R /XYZ 85.0394 619.5539 null]
+1102 0 obj <<
+/D [1097 0 R /XYZ 85.0394 573.0707 null]
 >> endobj
 194 0 obj <<
-/D [1043 0 R /XYZ 85.0394 444.3683 null]
+/D [1097 0 R /XYZ 85.0394 410.9267 null]
 >> endobj
-1048 0 obj <<
-/D [1043 0 R /XYZ 85.0394 407.9434 null]
+1103 0 obj <<
+/D [1097 0 R /XYZ 85.0394 378.8211 null]
 >> endobj
 198 0 obj <<
-/D [1043 0 R /XYZ 85.0394 220.8457 null]
+/D [1097 0 R /XYZ 85.0394 204.765 null]
 >> endobj
-1049 0 obj <<
-/D [1043 0 R /XYZ 85.0394 183.187 null]
+1104 0 obj <<
+/D [1097 0 R /XYZ 85.0394 171.4256 null]
 >> endobj
-1042 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R >>
+1096 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F14 729 0 R /F41 925 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1054 0 obj <<
-/Length 3094      
-/Filter /FlateDecode
->>
-stream
-xÚ­Ërã6òî¯Ða«F®Œ<Ìžœ±'™d×Ùµ�=äq DØbE"‘šÏ×o7º
‘�Ij·|P£Ñ
-J$š-RÂUÆÎR‚ŒòóîcïšnÒ½t6¯Ü/B¨ÆU8TpWú½{û
=O…ÖLÊ8…¸”qeS�øIƨXÚÚK
-véÜŠÅ•ëVûzé:’Œ€hå…çÊ#eÜýÐ1
(o'Æ·
-Ž�VÞÕOt€?µ�ë’¸¢HR«ÈÞ5È"(ÛŸY¹=ͼo	ݹž‡!J†ƒˆ4é9¦9<¤¢•À+
gÊã îÔ¹}�ðL<2®w;F}
-Äœæùüëw·×DPŒ…Cñ£[×q׺_æß»}¹ÁA·n7LѯK>lÄ4È¿"Úº	„5/ّͯ\×ñõ#óùx÷q·)놶ÊâVÛvHT¹¾¬™±¥ƒ{^jîojYk°ëf3e«²sÞ®³Â[•w]œ%M•B¬"gY¬'ü	ÂŽ)RÍ$펭13pѺé;‚Kúy<
-¡°ì<Ãw¬¿)`ê¦Âkú0�ègBs¶Õcöùšyô·
-g³y¦ñªm0T=q¯hÎ’ÈÏè¼WÝ”
|ŠÊü
ùj*ŠlŠ&(®a¡ŒéÊeû>ÚH°›8[7'Ä¿§›¸„u
etàÕ—Ã)…Ejcc!¹„þÆ5Pô>úã>߃¯NÔ*Çh,CpŠçlªHd–lSUÓ�k/àâO®™Ø2CI‹P¿r1
Eúvì3T�ø+¶ôûD,Ë
tam’É|l‚p 2Öl8f�ÄAFaøn ihç½N‘®�^ÏÁ
’‹—ÊÄ,Aj_1(*T	**˜€cWô‹å<pÕOx=e•%®�Pñ9¿7@
Ck
`î¤	ÜINHÜ<0˜Ì‚ó{]ðxmUóŸ&öc©´.ß»:(�j"4Éå멲¸Õa)@ýóŽ!jN¬2³I!bKõÓ·7ƨŠD«"„Ã×´å~@K>éÐqÆ°!µ ý¨©ÄŒ' tå•Þž­ŽúÝn]S9>€ëB€X9
-‚Œ—f/Á-�ÉA�jl…ÇÓ¡ñ{�¶3Á�0 )™__ćAïvãw@aÞ¬µOù4vâ‘þ

-a+ÓtlÈ+ð˜~CYˆ|q`õ2¿œ‹ñäL
-üãqÚÑÑ\5áy-ý!Œ(p†÷O'Š›jºg¸Îa¹�lB%¾3“�õv'ã_Œ™)7þ<[eI*äÔå&KÂ¥G÷!tþ="dc‰Ü$ÆdgA2,ÊíPJy1¨Ñs¶Äro�󓢸¢
G¾�Û÷þ™gQ4ËäËþtƒ’Uýˆ«Ý {žÈ±À—%áihçJÞŽ¹°±w
-ScvøÛ»Û7ÿøñzª2„"rU.NÞÓ±£ô•Q÷g;.Å×=˜j¬Zb#÷—Dÿ·¾=âÓô¦yÕÈ_ﻸo9–Q¸=û~·0À¸÷jž§ò²JZ�ˆoC®Ÿ`RÛÄš¢8Ó©€àÛr�ÙíÚ¦ªÁ±¼	ÉÏøòä‰X?,}dzÁ˜³�ƒg—÷L²GÀ›±àO{ÂrÑ#bdõ¯
ç×]`©“ª“s;ýÝJa]“™?¬k@ÂY¡C¸»»÷Í”øT’ËTN¾ïøº?=ö-\ §áqEA<,™ˆûH€ÊnŠ
܈øŒûÒSS)–IøÔð˜
LJwEf€®'ŽÃ�”Ç­^-ªW/
-1ôr5ï7xŸFK97uBf ·õúð–BòR�½FšŽ¯Ã^Gçg‡ºæWœ»;p†n¢¡†=¹ÇY‡ÏÑîÔq—¡û©ª0yààŸÃð›ñË}–.²aŸ…ÃØgá
+1109 0 obj <<
+/Length 3252      
+/Filter /FlateDecode
+>>
+stream
+xÚ­M—ã¶í>¿Â‡¾·ž×µBŠ¢H¥§ÉÎl²I»ig&=äã [ôX/¶äXòîN~}
¤%[“M_û|‚$€ø -g~r¦ó$/ÒbfŠ,ÑBêÙjw%fOÐ÷õ•dšE Z©¾z¼úâ­2³")ò4Ÿ=®sÙDX+g�ÕOó,±É5Ì æ·ïîÞ\/d¡µš¿ùææŸ�w÷׋T "’›Û_K)ç7ïßÜÝRŒ"àíÝ͵Éæ�?Üß=\ÿòøíÕÝcäp¸)²÷ÛÕO¿ˆY›ùöJ$ª°zö"‘E‘ÎvW™V‰Î”
+˜íÕÃտ℃^?tR*R$©ÊÓ	±¤r&³DeÐ9”‹.`R­ƒ\@BD¹À–` ÈSÌi‘H©?âÍáyß·O‡r¿©W “"Ÿ—Ç~ãš¾^•}Ý6„k×øÕ,8@Ôͺ=ìuGß}Ûuõrë¨Õ_Ëùæp-í¼=>m·áÎ8Ùƒ[uÿL­Ÿ…ĸ*Œ«"O”²v€ŒÓKX÷r“ hk�dR˜P"Ñl‘i�nªíl!e“ú~÷©wM;é^*ŸWîg!ÒÆUØLa¯ô½û
5Ï„RLʸqãʦ
ð�¬Q	0µ�—ÌÒ¹‹(*×­õÒuÔ$
ÑÊÏ•'Ê8û±cPîN„]É�€ÈÌ»ú‰vðïmãº$Ž°`nžþ]ƒ‚ªýŠ•;`SÏû–Ð�ë	qÜ¢¤fX†h@�ž_êÃ¥@&*¸¡aOyjÄ™:w¨qÿž‰5ãz·gÔG0Ð
awÇ®'ä’ç[·ÛmûÑU ä̘ùWïÞßA1
)¼ÛÔqÖºßæ?¸C¹Å†�]·[¦è7%/6b¤_mÝš‡ìÉâW®ëxû‘y3žÅ}Úo˺¡©ò8Õ®U®/kflé`Ÿ×E:÷;µ¬5˜u»�2‚UÙ9oÕyámÊ•LŽJ–%i®ŠŽÊb3qšÀëè"SLÒîÙs
­›¾#¸¤Ïúœxh[£–Ò<#ï�äå¡Ü¹Þ:<ZÏß·½£.’2AŒŠŒHÒ‚$™ßŽu®ýêž½¥"Œ‡xë::úÚ&6SzlÞ¸SKf”²*¡í§CÄÇöðkÝ<¶â%W}{x¦þöp6à‚Æλ½[ÕÈ‹×2Ð,ŸOƒ.’Z
½ÐA#Õ”Ft’J›Ž4‚––r¸
+Ûí�¹`ÕÈ�½«H6JˆÄäÆŒ…CG]'„Š$M>H~
+K‡8„ãª]Ý€±JPZG�Þd‡DûrÈžwò_´^fSo+"C—Ç#™˜¶évu?åˆÐZñ g�¥`ðËüøW>”*r§3p…eäÞ3`ýN
S7nÓ;yD?šc­³ÏëPÏÚïP%µã±Ԫܗ˼®Ý~p<¶8ásúõ�³Rļöþ
€ªìK<öR„ˆ½¡“ņ1L†²g\³bLŒn9D®9u¶L‘d¹µ!‡x˜övY¦	ŸfŠ<sÆYå¶î)ÚpÚ‚[$ÛEÉ%…Ìòa¨}ëÝF–Î[
”ý@®á½_Âo%’ 	ïý`8ä
+Éùó×®�l ÷¾çùNêÙ´N”±Á3Åeévn
+6¨ªéà\/`ßO®™˜1ÍŠ�ºr&
ùùn|`(ýð;léûDŸäÊÞsam’K3ö¡èm -&lØfyÄ&EßÝ@úÑP#ö{•"];=ž=D/•‰^‚>Ö>]H)G%¨¨`	
+
+ЦüàÎè 7"¨‰Ð$—¯§¼.zo«ÂP€úç=CTœYen“BÄjêÇïßßM#TŠ*-‚/|MÓQà·1
+
´ä•Ž‡â
+Ò�êIwòVéíÙª¨ßÝÎ5•ã8)ˆ•Ó/ƨ’ì¼@ÿjÏ2¼ÕY}k¡€Ú>µV7;jBå–Ç:´’DøŸÓ4ÛÁ^KÊäå�|ëÝ~ë€Ñiµ$Xð:‚ßÝ=¾ý�ƒìf(YÛnrÂxÙ¿¸yøæF¾”UBÑo¡Dc¦Æ‡íÂY”ô1¹…zº-væ¥×CW~_•ðVSŸ%îS‰òš0/ë¯IBa�:þ’'µª…²àA…ÑÃ:v£‹üÌ¢¤oäÜ#—ô…½1‚©½Å{hÄe2íäG¢¾.@”¡U
yJ¿?ú +b½á;HÖùâ¾ìË«ãÊU_NOæ") cq|7æë¯Bè¿ÊTe:AmLä-&OŒAö¨ô‰H@µ—¿´WÚ€Ó±
žV‡šïZÎBƒžd~ºve?X�Ÿ
…Ux£V>ÞS;X‰Gúò�%5½ù!ЗOx™“ â,Ùü©èIèyö¼°·Òû­FŽG{%ª2;¸Š›¹Ld:måSöcU’Û<ÜFa¦fFžK7\MÑ”fÈPo^F‚:,ù?n5Ï£/úð
+<ß�"/X=ƒ¸/çÁb<9¹Àât4‡|Á›Hk“‰Œ÷–§E"R}’0Z�¿õ#N;Zšs&\¯¥ïÀ
B‹â
+Jb±ß„щÖù…“ƒxƒŒJÉƒÝ°í –Ëj÷
ˆâ|PìùöîÐû>ìEÑ,�-ûó	JBTõG­Ý p®È¾À'%áVhïJžŽ¹°±p
+RËâV²³´¡†AˆdÀßÀÕöXÑ…¡}É­©T%Jhõ™Co’¼°ùèÔw´Ê±Ã.%™!ƒû_Þ½ó÷n§ÒzÈÀ!Õ0âìo|ZÛýÙj9åjù
<ML9cþ#ç³ÿ¯šýÙïÓs™ä_3sÍyJ�qz¶)|nÒÀ¸nnž§²ª4�¤7Ø$_A_2©lbuQ\¨T@èl¹>èömSÕà½
	Éï/òìmX?.}µÉ½Á–Û²�ƒû²‹®\ò�€.¶bÁ/CÂrÊ*b\ôE—Û]`¢š¥ÙØzÞO¿7¦xý%T,!/§[°*¸FœEMÉ.MŒ•˜Û‚Í‹Õûû‡w_¿4‘È'¯÷üíj …·§"Þ®	.±
+UˆÄuV¼¼Ô)e	ç/>–|}Ä[¾¸»¿‡CÔMT�4ÃðF‹Ó
üIT¸ ;?ðËPñVUè‚èô7 ø�piKìOD“"VØØŒ66ð8uRÈ(L0”lÙuÇ]‰¥¶â§s$ôuJAï¡þœ.ºj2˜dàJU>¨¡“Ï•ÝPK'ºÈO1ta øŠ#~Õ
Ä9ÖsåÖåqÛ³ºÊp�0ºÈe©ó['‚|ËÅežÿ~(!ˆA§Ò`xË0zDúÜMç8kO&.βºóhB×íÄe
++â~Ú;Ä(>õw¥üÎÄŸoDÌvþç¿úœþÝ’QÖ¦§ñŒ“<Â�I˜)Üvš_pþtÉú
 endobj
-1053 0 obj <<
+1108 0 obj <<
 /Type /Page
-/Contents 1054 0 R
-/Resources 1052 0 R
+/Contents 1109 0 R
+/Resources 1107 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1050 0 R
+/Parent 1105 0 R
 >> endobj
-1055 0 obj <<
-/D [1053 0 R /XYZ 56.6929 794.5015 null]
+1110 0 obj <<
+/D [1108 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 202 0 obj <<
-/D [1053 0 R /XYZ 56.6929 769.5949 null]
+/D [1108 0 R /XYZ 56.6929 769.5949 null]
 >> endobj
-1056 0 obj <<
-/D [1053 0 R /XYZ 56.6929 747.8139 null]
+1111 0 obj <<
+/D [1108 0 R /XYZ 56.6929 748.4014 null]
 >> endobj
 206 0 obj <<
-/D [1053 0 R /XYZ 56.6929 540.916 null]
+/D [1108 0 R /XYZ 56.6929 549.4516 null]
 >> endobj
-1057 0 obj <<
-/D [1053 0 R /XYZ 56.6929 511.3349 null]
+1112 0 obj <<
+/D [1108 0 R /XYZ 56.6929 521.7105 null]
 >> endobj
 210 0 obj <<
-/D [1053 0 R /XYZ 56.6929 239.6059 null]
+/D [1108 0 R /XYZ 56.6929 231.5025 null]
 >> endobj
-1058 0 obj <<
-/D [1053 0 R /XYZ 56.6929 207.3747 null]
+1113 0 obj <<
+/D [1108 0 R /XYZ 56.6929 201.1114 null]
 >> endobj
-1052 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R /F48 885 0 R >>
+1107 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F39 885 0 R /F41 925 0 R /F48 940 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1061 0 obj <<
-/Length 2903      
+1116 0 obj <<
+/Length 2902      
 /Filter /FlateDecode
 >>
 stream
 xÚµYI“«F¾÷¯èx«§Ýˆ¢XÃ1mOûÚl @b‘
-�WýÀ«,0,TøWIá�«῰¯6¢µ_@Æó‘3}<rÕÕ—êw(½*Œ"r⫺{�%3¬,ƒWÕüµÒèÔ&jkööÁ	l…gÞ>‘­Ôš‹7
-lr݈nf„Õ->†�évɆ€™òýæ%[

çGÎB%"ÑøiÆhk�o¬'I¨HdåÊOØQÚøð
-ºˆâ,\ÈüJtâX
 Â?‰œˆl–Ø<¹py+ɈBW™ÄLTKý!A•
-”¢4’°È8³^øÔ<óúTàì_�l”©â×ÈÆ›˜VlDîö3;éÓŸ™ÝÍì÷�…Ñ3sâ¸Lfhœ}Ôl˜"ɾOºj�ç°`	VêÝ>i£“µü3~*Å¬(”`†äPˆ&‚0¡S¨8»»”N⳪žd%&cÊç…º™‰%§SD¢Ç6LÌ|‹æHÎâ�~Nœ0rTn/W–Ƙj†t
-«‘w²‡Ì
-¬¯ñPߣe¸8‘¿‚\DÈg¥¤•žLæçÚ’®YÛQpâCß+¶EÏ"B"A�È�‹
-|ŽÍoÌ7*™$:€O�oõÑš¿FË!»Þ{ce²Ñb•®ýp›Hq«µëCÛmÛºz�÷nQûpë-ÃÍYìJ“{ïL·F×m‰%-à
ê–bßx­
îíZÇ[õÍ_w�3G¯÷ƒ‹Ñà4Åß8S;š`‡ÕNÍÜ�,yà½à¾†eλ§Ü*åÞr\kª“ûü¢Xº¿—@žtÚûú@_$ëË¡ê¦vܯmg÷.îZ^ä¦~/KÜá”7‚Zc&©ù�¯×uI›U·V³“w©®–sW\ùao°m+sãdHžÄö›'ﲚÁa™ŽUOÓ³íÁ²AwÒ›»¦ß‡›´áy¿š÷·{«ÊóþÙèØÁUöÖn˜œDÑî‡ætÿ^*Ñ­q ¶Ó–tV”å] tNÞ­éÜÖÓ)Ç~Ÿ*Òü}Ð×ÔãÔ8qÒLª©°ºœÙô67ºeV�NWãÎïקM“ÛMMû¶5šjÃÓØƬnº®•†£ûª
¿ýR|M¡îý{AŽC›„©pxžóAôY¯~Š.tÅ5éKþ¥ê•ƒ
-þÎÿJbp"dX
-Fd¯ªýa«mVKMtÏ—ïü©×Hͳku·óvøÕ°fÌÞo®ÎQƒ®6¹øÕ0]Îäú²ê,Íûø”™8o¨Ž×ÙÁ›»ö¬æ6©†`¬NY¥Æþ3�÷O§ýß>½wß<¸é
-¹›á�þRÙ—Ð]‹“„g39]æ˜îè£ÖlÎ&5fÔRÿ(Χã`Îß‚j×kÇú¤·¡}¿·±9Òo¬@žž6Át:­QuÀpä;ô£Ã‹èÝ8m5µ�°.§­{ïG½ÅÞm;…ËëH›P4Ø2‡'ñ}}Ú&ÃñíiCnÜûá~X]Ñ‡íª¥g˜¶5»úØœ³enNÇ]±nOâëûzcÞ½õPïöÚ;~È›iØï:ws“N¹ízíÓi™ü Îz
Iñ0]÷;�µ5»Ð�'·}wºòÍ“=îµOïtŽk³biÃZ¾ƒ›½î9JÔèî´q¤Û·Á¤Í]Vj³:«÷&T¡6(3BêôÖ�žSÛ4…� ,.ûù$Þô:V³¡¥Ëut™l¬xÓìÎ.N³Y¶¿ÀÍû—­cYjOóÅ–s¸§ÉhÄÍGŠ8�ä}ÕíÊî¶ûRoþû—\2Mú'ýd_~z\Í0ÌûÇ¢P‡°ìÿ
¶H¦¿ýoÊçHH=(ËÜç%OŸñ—stÎÏ•"$}Õ¼øÛåGÕÿôtúendstream
+�WýÀ«,0,TøWIá�«῰¯6¢µ_@Æó‘3}<rÕÕ—êw(½*Œ"r⫺{�%3¬,ƒWÕüµÒèÔ&jkööÁ	l…gÞ>‘­Ôš‹7
+8?r*‰ÆO3F[ƒ|c=¡HBEb  +ÏP~ÂŽÒ†À‡(¬Î�„c”Òá1t1¨„=ü²£Ìdº‚×b›Rò
+d%šÏ8!ÊK–e+�0À!aŸ#3·¢‹•á‹äpÈnaŒå¨o
+WÁJp©¨o=«ØüÁ'�AÅd@ºOCë‹d
+r!ŸÇa–ÿO–?Úô
e…�"Ÿ]îŸãÌ�ÛÂÝ_<šZ1ñ#HŒ¢ ºô8”Áÿ
+QÐE”gáBæ·ˆP¢Çr
+#¡¾•±2%f| ŽÆÈ
+¾3 7^¬½"º�ü‹ˆç%FæXtÑDG°<a®’€/u¸,2)á„�ëó@˜…¸ìa±}‹v0�Ü?¸’å™Ü‡yºß@—�Sàsl~c¾QÉœ Ñ
|z|«�Öü5ZAÐØõÞ+“�«tí‡ÛDŠ[­]ÞlÛÖÕë¼w‹Ú‡[onÎbWšÜ{gº5ºnK,i
P·ûÆk
po×:Þªo¶øûº{œ9z½\Œ§)þÆ9˜ÚÑ‹8¬vjæ~dÉè÷5,sÞ=åV)ð–ãZS�ÜçÅÒý½¼
+uïßrÚ$äH…Ãðœ¢ÏzõS\p¡+®I_ò/U¯Tðw6øWƒ!Ã(=£`Ýtÿˆz¯�_¥"dR»¶j5ý63îÆv¶Ó¿´6u1l5Wï;ŠBë¨ûh	6zmæOœÖfCÕ0+~¹»ÁµâîìÖù$]6Õ{{£™­öh™¾÷6÷sÌzÚ1¹ÚûöÕÑæ@äΖïõµí¶,8ƪ1”�ו·g[î
+†Íïßó<oõ15@ëk»ªß�:—ÝuÝ©Ö-Žk�²Èð"7è÷Ž`lóéõ>V–¶7<Hûín	¡­õ/n¤v"Nh¤¹:Õîõ­ Å·Ò“’ìÙAªj�$°wm¬§¿§ï7¿¶ØL8ÖµU÷æU00"{Uí[m³Zj¢{¾|çO½Fjž]«s>œ×°Ã¯†5cö~suŽštµÉů†ér&×—UgiÞÇ— ÌÄyCu¼ÎÞܵg5·I5cuÊ*5öŸy¼:íÿðîý¸ûæÁMÏPÈÝ$ð—ʾ„îZœ$<›É1øë2ÇtGµfs6©1£–úGq>sþT»öX;Ö'=¸
íûÕ¸�Í‘~c%0
+µA™R§·îôœÚ¦)eqÙÏ'ñ¦×±š
-]®£ËdcÅ›fwvqšÍ²ýnÞ¿lËR{š/¶œÃ=MF#n>RÄéì ï«nWv·EØ—zóß¿ä’i2Ð?è'ûò£Ðãj†aþÛ?&…:„eÿo°E2ýíS>ÿ@BêAYæ>ÿ(yú¬ˆ¿œ£s~®É é«æÅß.?ªþÛúÞendstream
 endobj
-1060 0 obj <<
+1115 0 obj <<
 /Type /Page
-/Contents 1061 0 R
-/Resources 1059 0 R
+/Contents 1116 0 R
+/Resources 1114 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1050 0 R
+/Parent 1105 0 R
 >> endobj
-1062 0 obj <<
-/D [1060 0 R /XYZ 85.0394 794.5015 null]
+1117 0 obj <<
+/D [1115 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 214 0 obj <<
-/D [1060 0 R /XYZ 85.0394 717.5894 null]
+/D [1115 0 R /XYZ 85.0394 717.5894 null]
 >> endobj
-1063 0 obj <<
-/D [1060 0 R /XYZ 85.0394 690.1986 null]
+1118 0 obj <<
+/D [1115 0 R /XYZ 85.0394 690.1986 null]
 >> endobj
-1059 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
+1114 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1066 0 obj <<
-/Length 2379      
+1121 0 obj <<
+/Length 2380      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥YKsã6¾ûWð°ªÊBð"H:'gÆ“8•õxmMö�É�¡1w(RCRÖz«ö¿o7¤(šv¶jì*£
4�~|hÐ"àð+‚È0“Ê4ˆSÍ".¢`½=ãÁ˜ûùLxžeÏ´sý´:û჊ƒ”¥Fš`µÉJO¬ò?BÍR¶
-F‡ê/Ç’Ý¡ nŽ!‰\°?xRˆ8¥3Õ†ŒÓ°Þ`›„Ý£øº�<´øç¹¥©²h;›ÓlQõìEK#v¡xøïl»+-Me�—ô´�Qˆ�¨t^W4¾ËšÅRó°+ÖûhHÀó‰M]w44RÇk൪€c& G›N¡
85I“`ßWÁQj °Ž¹ü}QªZߪ"š)mä8£8àŒuœ€�œ#p>õÀ¹ßíꦣŽsß4�Ñ݇˜T&’€àÄ3ó›Í¾,ÑÜ„-Ioi"+K"Öû¦Yˆ$´UGœq˜ÛÏœËÊʨ›mK2\Â�ר*ÛZ¢ºÚKÎsØúEY•ÏΗ…”uýu¿kÙ\¼\{Ë
-§;PYÙÖDí[ëïšÁš£ÝlKC�çÞf_=û·½mŠ~úðh½Ñ›E¨¾P¿öãY5Ýe�íº±Ó>Cúm�ÊÇ,U2qʨ!“¤ThÍCæËiÀóJ&½a<¥Æ»m!–êÊù	¨Kø!Šº®In‹YÌEx÷áM+eQ¹Ý�$ÏžVÀ0e3dGÜeã÷0³;œŸ:ˆŠ
r´IÃuY@8-Û"·4Б
��3N6´Ù4xÈ<‘­ûp‡;ú°d[?Y¿åÆ�Ô[Dœ!i`Ëeâð—ú`ŸlƒµƒC0fûî±nŠîÒ';o½+rEÒ‡)P­m@Xë;$�e�åDý‡`(Ì¥ÒzÞu]uYáúdÞd0
9'&+HÈÎÚg糋"Ô^)°u{°
->1tȺ3¢ç='GžÃ
-ç3{œÖ/µZ0)¢t¤mQu3ÊJ,ž†Š‰´Å,Šãð£ÛÔí�n
›¶¤Õ&²÷	P)MxŸPQ2R-ÿPTYóL|eö`Kçgslj:˜Ï`)�ù&
-¿Võ¡"’°Âx©]Û5ƒØ�‚XÈÁç„
-ûŽFGÀÑ! ô‰%d$ªæ7x¤�€ÇZ¿÷ºÆ‚ª³MÑš¢pçL‹�g’ÑÙÕ]&ü{V9)2Ìv»²X»:¿¥ŠÅÁÄFöaŸ×Ô­\!ľ/µ�‡ãÞè@&ÉàDcöíÛÒOm)}í¹7y/Ý]Ç3Ç"înßTx¶ÔÝ�ØZB4Lwìj¿
-c˜,/<+”Ÿ}åI�®0zy'øí†È4H¥Ôb#EˆM4nM†
·K
�R„ßs÷ÝîóíÌÛ¾Q
-Œª	•æ©°ßÛxÐ}´Þ’{ÜÔâX£¬Á¾ÎΧk_©‚ÎýZk§·Š8<	˜x$”{<ÓdóÅ?oîF¯Þ�9^пÓÆÀ7•‹¸‡ë¬èkªK&™xñà1¬ƒÂ,þÅÛ{àú-^JC-˜Ç>1~Wº“Å©;"<Âx<|æ¾^¿‹RÊÿF7u>µÇ›�J3 îðÞƒë|¾vÁZЋ`E5XÔ;(�!Bªñ¢É%Jcî……¯(jð¹&0u]fÀ+x±ÉÆOêpVª+.\”yj_•ÅW{"DO¯RÕ¼!¯ÝÙu�ydÛ¹<"ŠÆbγa|ú<ò5Z¾¯ÂOU@dü˜t–Àçä�“O4è�”%	¥éß>Þ]ÿŒŸ®ð+‹_Å
-tÒ“'--$¤ƒ�Þ:Û­…k"wŸÜTx½ñ¨¡ãà:wá¹™ŠZŠ œí†ÐEôz82CT¼~1ŒCÜB—×Ñ¡h±óþ½×=ÎxKoö¡N¹¸ØÀÏ…H
ML´•‰}q7:ñ‹²v‚µ£3ÍÃT’é(–=>˜
ä>ô/Îz:¼�7® õ9	ñÿ2þ鬊Ó#Ò‰ÂÎ~Gmæ'O’
-?Qù=‘ê#Ïg�Ù¥XíÀÕXu¾ŸõùŠ�¶€$y&zT¼çNª	ÿµwQŵ³»Wdî¡!æÁûî¥ë5”ÓÂ}…×ÝlÆ`DB"zÆ^gÈŒ}Ò]„£Ã™ý�÷eç-ª]
™¢c$È6
-£”òåjÎ$PšÀƒ
+xÚ¥YKsã6¾ûWð°ªÊBð"H:'gÆ“8•õxmMö�É�¡1w(RCRÖz«ö¿o7¤(šv¶jì*£
4�~|hÐ"àð+‚È0“Ê4ˆSÍ".¢`½=ãÁ˜ûùLxžeÏ´sý´:û჊ƒ”¥Fš`µÉJO¬ò?BÍR¶
+âæ"�XÀûƒ'…ˆS:S]A`È8
ë
¶IØ=ú�¯ÉC‹ž[š*‹¶³9ÍUÏ^´4bŠ‡ÿζ»ÒÒTÖxIO…X��JGáuE㻬Y,5»b½/�†<Ÿ(ÑÔuGC#u¼^«
+8fz´éÄÚ€S“4	ÆAð}q…¥ë˜Ëßõ§¡ª5ð
¡*¡™ÒFŽ�3Šc
+-˜Q:Ò¶¨ºe%OCÅDÚbÅqøÑmêöG·€M[R�jÙû¨”&¼O¨(©�–(ª¬y&¾2{°¥s‡3‹ˆ9‹ãD�Ìg°”Ç|…_«úPIXa¼Ô®íˆAìÀ
+A,äàsB…‡}G£#`ŠèÐz�Ä2Uó<ÒNÀc­ß{]cAÕY‚¦h
+MQ¸s&ƒÅˆÇ3ɇèìê.þ=«œf»]Y¬]�ßÒÅâ`b#û°ÏkêV®b_�—ÚÎÃqot Ž“dp"�±ûömé'�¶”¾öÜ›¼—î®ã™cw·o*<[êîNl-!¦;v‹
µ_
+7�&C‚€Û‰¥†@
)Âï¹ûn
+wƒy�væmß(FÕ„JóT؃ïm<è>Ú
oÉ=n‰jq¬QÖ`_gçÓµ¯TAç~­µÓŠ[Eƒ‰L<Ê=ži²ùâŸ7w£WïÀ¿/èßicà›ÊEÜÃuVô5Õ%“L¼x
ðÖ
~�Å¿x{\¡ÅKi¨óØ'ÆïJw²8uG„G�‡ÏÂ×ë—`Qª`AùßèF¢Î§öxóQiÔÞ{p�Ï×î Xz¬¨‹zç
2DH5^4¹Di̽°ðE
>צ®Ëlp/¶#ÙxáIÎJuÅ…‹2Oí«²øjO„èéUCªš7äµ;».0�l;—GC¤CÑXŒÃy6ŒOŸG¾AË÷Uø©
+ˆ¬‚“ÎÒøœrò‰’²$¡4ýÛÇ»ëŸñÓ~eñ«€=›;ÂcÝB†ÆXðÃVšÓ‡/ìöá€cÀ".ò‡äâB¼¨‚üÂÊG)í[)òß²¨–dœÙÂM�N@zòäÁ¡¢¥…„t0Ð[g»µpMäî“›
+¯7^5t\ç.<7SQK„S£Ýš£ˆ^GfˆŠ×/†qˆ€[èò::-vÞ¿÷ºÇo	aàÍ>Ô)ø¹) ‰I˜ö 2±/.âF'~QÖN°vt¦yx�J2ŲÇ3àƒœÃ‡þÅyCO‡7ãƤþ#'!þ_BÆ?݃UqzD:QØÙï¨ÍüäIòà@á'*¿'ÒC}¤àùáì1»«¸«Î÷³>_±Ó�$ÏD�Š÷ÜI5á¿ö.ª¸vv÷ŠÌ=ô!ļ"xß½t½†rZ¸¯p㺛Í,‚HHDÏØëƒ±Oº ‹pt8³?ð¾ì¼Eµ«# Stì�Ù 9µØ¦.Ëú0øâPïK¿�fý„¯b*r¹f1“"÷ôÕƒ©1Ľæ_a”²C¾¼@Í™JxèØ[çm`2‹#Õ'›‡o2耵_EQÎNöÀrh…ëIvâÉ)Ä
+Æßú…ìK`¡5¯£ïíê=ÀÉHlŠåsÇ!¹õ|ÑÁ8øî/¿ ê˜)¬’f«xÝaõ¢z¥œ³’š÷ÿ‡x©úÿ
 endobj
-1065 0 obj <<
+1120 0 obj <<
 /Type /Page
-/Contents 1066 0 R
-/Resources 1064 0 R
+/Contents 1121 0 R
+/Resources 1119 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1050 0 R
-/Annots [ 1069 0 R ]
+/Parent 1105 0 R
+/Annots [ 1124 0 R ]
 >> endobj
-1069 0 obj <<
+1124 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [349.4919 384.4828 408.4801 395.2672]
 /Subtype /Link
 /A << /S /GoTo /D (ipv6addresses) >>
 >> endobj
-1067 0 obj <<
-/D [1065 0 R /XYZ 56.6929 794.5015 null]
+1122 0 obj <<
+/D [1120 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 218 0 obj <<
-/D [1065 0 R /XYZ 56.6929 594.1106 null]
+/D [1120 0 R /XYZ 56.6929 594.1106 null]
 >> endobj
-1068 0 obj <<
-/D [1065 0 R /XYZ 56.6929 562.6395 null]
+1123 0 obj <<
+/D [1120 0 R /XYZ 56.6929 562.6395 null]
 >> endobj
 222 0 obj <<
-/D [1065 0 R /XYZ 56.6929 370.2937 null]
+/D [1120 0 R /XYZ 56.6929 370.2937 null]
 >> endobj
-1070 0 obj <<
-/D [1065 0 R /XYZ 56.6929 341.714 null]
+1125 0 obj <<
+/D [1120 0 R /XYZ 56.6929 341.714 null]
 >> endobj
 226 0 obj <<
-/D [1065 0 R /XYZ 56.6929 214.6004 null]
+/D [1120 0 R /XYZ 56.6929 214.6004 null]
 >> endobj
-1071 0 obj <<
-/D [1065 0 R /XYZ 56.6929 186.0207 null]
+1126 0 obj <<
+/D [1120 0 R /XYZ 56.6929 186.0207 null]
 >> endobj
-1064 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F62 995 0 R /F21 658 0 R /F47 879 0 R >>
-/XObject << /Im2 984 0 R >>
+1119 0 obj <<
+/Font << /F37 791 0 R /F41 925 0 R /F23 726 0 R /F62 1050 0 R /F21 702 0 R /F39 885 0 R >>
+/XObject << /Im2 1039 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1075 0 obj <<
+1130 0 obj <<
 /Length 1913      
 /Filter /FlateDecode
 >>
@@ -3645,249 +3836,246 @@ stream
 xÚ�X_�Û8ï§È£h\KòßÇöfoÑÅ]±èÎ>]ïA±•‰P[ÊFöäæÛ)JNœqºE€˜¦(Š"©)³M?¶©‹4M¾©š<-2VlÚá]¶y†±_ß± “"-r!àeet[ˆ:-j^m¶×J>=½ûðOÎ6<KË’›§ý¼VYÕi#òfóÔý'ùÇAGuzØò"KŠ‡ÿ>ýFÓò´ª+†Ó2X¢H«&«ý„§ƒ"áOŸ¿<ÕÐã_úù0žþã«r¶
åQ+ËS‘—<h-EZ•™Q¤ìa˲,»è¿¯.ïNòôt‹M“6%/ƒj^§eÕ2ø¡É’“ìô¨­‘}ÿ
 5e"�Ç^·™Ž8ù¢�ª’�R†x½6ßUGôY�—Äpã´#êôÀêd6�&’y^~<È1LQ¦s×sÚéä4­[&�_þ 	MꤕÃÍávK›¢à~;£¥ýKzô¶•=‘­lÚ<Ó‹‘Cð£S'´ªÊ“tÖWA@Æ ¾Ï¿¿”[
«[Ó*¤ªD›Ñ[g»©ÅÝã¨QglípìÕÿôøJ lid<(bÍî˜Ð½Ä;’ÆV9÷þa霸©=ÐDéHfoûÞžý�ý1Ö¤6.ˆšnÍ+�_>þûØ/¯£_­v¸Üσá*qz˜úQe'Gzk¿OGµ{â�Wr¢æ‰ä(Ï꺰C§\
 veÒÖNϬ—ê¼g�¸rÞÊ.ÎèŒÈ¢h¡Á¾¨îý<æBh%�ÒË�Þ:z³á˜èáh�Ó»>HÅôÑhÇ L8[Ú,²j¼œ—�D>Õ/…T¿—T„
¬ñØ€0š&îm´Ù­4DÈÞY¢Bž¼è.ÈÜ&ò0§5¤RP¦†³à÷öÆ'çSʯ†í°ÓF^b ®Æû+ìY‰Óò¸ó†_Ž;oDHàJz+ÞI©!úê`Dñ:™Œ¡£Q�’â™Þ
R-ÅãT!pº 
-M&PÄqíèÙi7jÓŽ4¾§Y�yŸ"A¦͠ì‚d,"û©ì±‰kkÒ;¥)ÏR^Š:”&JÓ×9*—“²,J�ן©IW؃È!6Š‚O
+M&PÄqíèÙi7jÓŽ4¾§Y�yŸ"A¦͠ì‚d,"û©ì±‰kkÒ;¥)ÏR^Š:”&JÓ×9*—“²,J�ן©IW؃È!6Š‚O
+q¿–D"mX•
‘¹ÈjmËúÿ@CH®2#¶¦È²&RØš8"u�£
+:åô³¡&Ä«»Û†ý5é˜âB€û}Ye¡ødÉ �°]B楖x¬†Í@”üizT(þ¶Úxe訳vTn3o-òÁa^¨ª1ü8Háã=ô6³¶µ{Ó‘¡š»hW”P·Šj‰v¢æwЮ„Z[Š´»ƒhM	5ƒ©º¡s?‡+ì
+ïp,'èñ+)jä‘jåQúk ©ï¯‘ÙYºÝÕ¡�Eâ¦Á§âÛð´â·I-§Ñ;ÀÍÍ$b®»Ö¬Ý‰ÜQµ㩺›{JýÐà4;,ÿ‰f`¨º


��‡W$‚7€Úù«1[Ë/¥nÆÏX	 «EšQS£»»·ž;šWïP{“øÄDN�)�ój=u”ö¬ÊùßC;»òÕ]Û Ñ_;Œ`ÝÄF
+q…7ÉGb†N0bèKNôJ…$ȳÈBÏ"g¥OØêåýµ	G’^—=Ys{}ñJE½Ó6l`‘“TÈ‹«Ã}%­JüŠÆ‹ŸêIÙmS:_Óß	Р*çóýÃì(š´ªŠúºWy÷ËÓü-1~!EŠß×¾6F‘íE†>5.NF�¸áb¼¹]mþpùv¹ÿÐÆ�}endstream
 endobj
-1074 0 obj <<
+1129 0 obj <<
 /Type /Page
-/Contents 1075 0 R
-/Resources 1073 0 R
+/Contents 1130 0 R
+/Resources 1128 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1050 0 R
+/Parent 1105 0 R
 >> endobj
-1076 0 obj <<
-/D [1074 0 R /XYZ 85.0394 794.5015 null]
+1131 0 obj <<
+/D [1129 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 230 0 obj <<
-/D [1074 0 R /XYZ 85.0394 769.5949 null]
+/D [1129 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1077 0 obj <<
-/D [1074 0 R /XYZ 85.0394 576.7004 null]
+1132 0 obj <<
+/D [1129 0 R /XYZ 85.0394 576.7004 null]
 >> endobj
 234 0 obj <<
-/D [1074 0 R /XYZ 85.0394 576.7004 null]
+/D [1129 0 R /XYZ 85.0394 576.7004 null]
 >> endobj
-1078 0 obj <<
-/D [1074 0 R /XYZ 85.0394 544.8207 null]
+1133 0 obj <<
+/D [1129 0 R /XYZ 85.0394 544.8207 null]
 >> endobj
 238 0 obj <<
-/D [1074 0 R /XYZ 85.0394 403.9445 null]
+/D [1129 0 R /XYZ 85.0394 403.9445 null]
 >> endobj
-1079 0 obj <<
-/D [1074 0 R /XYZ 85.0394 368.2811 null]
+1134 0 obj <<
+/D [1129 0 R /XYZ 85.0394 368.2811 null]
 >> endobj
-1073 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
+1128 0 obj <<
+/Font << /F21 702 0 R /F23 726 0 R /F41 925 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1082 0 obj <<
+1137 0 obj <<
 /Length 69        
 /Filter /FlateDecode
 >>
 stream
 xÚ3T0
 endobj
-1081 0 obj <<
+1136 0 obj <<
 /Type /Page
-/Contents 1082 0 R
-/Resources 1080 0 R
+/Contents 1137 0 R
+/Resources 1135 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1050 0 R
+/Parent 1105 0 R
 >> endobj
-1083 0 obj <<
-/D [1081 0 R /XYZ 56.6929 794.5015 null]
+1138 0 obj <<
+/D [1136 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1080 0 obj <<
+1135 0 obj <<
 /ProcSet [ /PDF ]
 >> endobj
-1086 0 obj <<
+1141 0 obj <<
 /Length 3113      
 /Filter /FlateDecode
 >>
 stream
-xÚÍË’ã¶ñ>_¡K*šªŒ7�ÍiýØd}p{o¶«Â‘8#ÖJ¤,R;ž|}ºÑ
+xÚÍË’ã¶ñ>_¡K*šªŒ7�ÍiýØd}p{o¶«Â‘8#ÖJ¤,R;ž|}ºÑ
 Waƒš)m%ÂÌ ™æLZEBµL€ap~ƽ¯Wq/¿£ÍïòI:pH^”ïÛÕª}Žòâäv -©YÕ]O½`ùÐV	sø·ëª¨ý’XP»ëÓXu¬,óݤÔ_´ó.>¿Eúï¾û8øoAè…žh!™å^¢óÿíîç_ùd
±âû;Δwfò8
-h\±›f¢š%žfÊÁ¾x燈v œ0“)¥ÌDsͤæEؾr¾:–‘�‚9sÀ/’dÞ9—gv6`œ�QfH„@ê8€Ñ&rf€â
-ñŸ‹S5Ë~ÐhÙx“áÔ1·ÏfNùÔP”yÃííø0^áS#íXð¹ÙV�õïN•� 7Ä£³œªð	ôcV¸}ÅéíXM¯±êa¾Gž£^äânô«‰Í™…z¯ÝfØÅ\mM:ãLÊ!!Þ©ÍÜ:èùjÆŒ³1ÊSÆe
¨-šy»�r@¬ÐƒE¦Dö
å�]U�X¨)˜Ä 7&�>nŸ&Ôùqt61ÀŸÒ|¤hÇx‘žŸªù>#†DRýcõ‚]0¢ôœœ�PW¨8Å6T#ù
-]·
-°Éä¾ešq6ÀBmã%Ħ+
Ö€*È·º¾Ú^¯zÃà: ¼Z÷ž‰YP2îC† œÍÇlLé¿p0$ÒØbü
-�-�\Š_J@…eÏûuåãd~#

ø.
-Hy‰¨Uc
�‹\`e*Y;�
Þ7hfå*óUÌ8ëÏ;xÃ
”èÚÞŠç
ßEž
w¨µzÌsÖµƒëðL;s”=—Í⫬ƒWŽi
}n‹¥÷ñ<¸u­™†šâõn=aœ�Qf¶™CyÇ�´
,„îvÛ_MQØ=Ø#ïrs`X¥<ïŒå+ Ñè$nÅõ€ñ
-׸6VêC®ÏØ?ðÂ
—/P{Ya§u3_íþ)¦m8óÍDváøôFcE9#é1•õ ôq_Ü@
"ÆÙe&º{¨L·_8É#w°QŹÂ��Õò�l"^uŽ+E}ËJ\²¸È 6F›Àó¢]—usÉ”g…·ÅöÕ±,aœ�Q梙„”ÁQyî<ˆ[ÆñÌdˆgRÛéo»{
jNáo×oé¨R›éó²0ü\‡³]çÆ0&u¼|ÐtÅ
Í·?üDãHÆ{Äxˆ�ê÷r=ËùoÒñä/RêŒAIH×`Ç’1¾°¾êz¶ß�#^Áú¬³)6!Îê:R„?îÁ†t 
.õu•0Áj-¢ºö¸±çÔu€½�ºŽQ^P×C*«y½.W×5öï!»¯‹—J Zí¶4R7}õ„ž5Œ.W»�¤Á§ìOÏ	FC_ºjSnËžàm<b+Pv]î6çˆ	ÿb†F¤Â†®áðL¿ËœÊð°Î$¯)¤Ê1ª™×ÊVÆX
-…—×*Y€’ªxToôÙÓÿ
ðv§ÿc”NÿH<“œ�þ¿ƒº†ÄôÃ?>ëØ
3Ã%dG(‰‡.GO=—�áYZèîï§Âß:wwpäÜó~¬‚)!ìDZ•Û¥Â÷K³ž„q6F™Ézäû²‰
첂dT#eµMKwgìa¤i·²‡á¾òËqSÎY„àKæk÷ajf'•‰aÏ[D¼¡EŒP^²ˆ1‰_nJt0‹=3¶píÚ%×¾å\;’é�†ˆQr.Þ.ÜÛ·°”Î�‚CÑQ8±¯£€ÇÑúݼÝ`BªÊtå#H2ŸC‹J„â½¾6ßðn{Ëòs…=7-×õÓ®î_è}hUo©V$àãÙ…˜vôo½ë"º‡*uGØ)pjÁCàÔBàe"µ›
…ÜͶ.ñ¥IEãa¡Ðûð-Í$¯£ã½Vø´¡—4sp4Ù"KÙóðÐÊMŠÉ
-1™0%ÅvQ­êuÝÓ+”7çÓ=}«#d¼�ÌæiõB#$Ûy»?· öÂÈ!�Cº ý�7+p�Ä!Žb
-ÜÑ ¤X*†aج†F›ÝºÚÖs®Àn�~�É€*íÃk¤s¤Yv/Â{+ß*ARth‰¯‡°•ø¿|‚d™þ€²½@)º>~”Þà ùTÑk"7ý[ûœÍÛGO 
-³ÆGZP[ññk(ü[wÔ6-µ]_6zü´ ‘5hÉ�sª\0Á03
-“ã…õ"GÌX€2Á K!§óÝ–(Š¯x¼‡]Ç^ 2Èíc™¨/Öìªn>EXX'»ÃîÅOÃ;"¢Ùmðx¥Z 5=J·[S­  2³¾�ÍAèAøñ¡êŸ«ªÉ²œÈK’dB©
›Êó>”_>u|¶ô&2¶‡œ­Úy¹Š(FiÁ©Ï“�Ã[ã’Ï{¬—=+K�£z©Â�©«Â&±ÂPÙ÷å|qh�
+h\±›f¢š%žfÊÁ¾x燈v œ0“)¥ÌDsͤæEؾr¾:–‘�‚9«üð„$™wÎå™�
gc”!�:à€D´‰œ 8À‚¢|D]QÜxè¡Ê)
ºØdlµ�Ì9íâìr±ØV]w,
+e5¨.·’DBxEÊLØcA€š/OHô³ÚÝ’Æ„ñ
+‘šC^¢@Èº[”ÔsŸÄÝÑ-*4Ý}
+{Häí¶–Y
@ªùîj
+&1è�I �Û§	u~�Mð§4)Ú1^¤ç§j¾Ïˆ!чTÿX½`Œ(Ä
=''$Ô*N±
ÕH>ÀŽB×­l2¹/G™fœ
°PÛx	±éJ€5 
+2Æ­®¯¶Â+�Þ0¸/…Ö=�gb”�Œ»Á�!h
gAó1S:Æ/‰4¶¿BgK —â—PaÙó~]yÅ8™ßH@¾‹RÞ@"jÕX@ç"X™JÖNgC�÷
šY¹Êðl3ÎúóÞp%º¶·âyÀw‘gÃj­óœuíà:<ÓÎeÏe³ø*ëà•cZ€EŸÛbé=D<n]k¦¡¦x½[Ogc”™mæPÞq m
+h4:‰[q=`¼Âµ®�•ú�ë3ö¼pÃåÀÔ^VØiÝÌW»E…ŠiÎ|3‘]8~½ÑXQÎDzLe=HF
}Ü7Pƒˆq6F™‰î*ÓÂíNòÈlATq®ðãcµ| …ˆ×E�ãJQß²R×À…,®2È…�Ñ&ð¼h×eÝœD2åYám±‡}u,Kgc”¹h&!e0GTž;â–q<3â™ÔvúÛî^€‡SFøÛõ[:ªÔfú¼¬Ã?×álù1ŒÄƒI/4]q@óí?Ñ8’ñ†Æ1b§ú½\ÏrGþ›t<ù‹”:cPÒ5رdŒ/¬¯ºží÷ãˆW°>ëlŠMˆó‚ºŽá�{°!H€K}E]%L°Z‹¨®=nì9u`o§®c”Ôõ�Êj^¯ËÕu�ý{È®Àëâ%…¨V»-�ÔM_=¡g
ãŸËÕ.$ið…Ç)ûÓs‚‘ÆЗ®Ú”Û²'x�Ø
+”]—»Íùb¿؟¡©°¡k8<Óï2§r<¬3Ék
+©rŒjæµò‡•ñ

+'öuð8Z¿›·CHU™îá|éAæshQ‰P¼××ãÞÍcoY~®°ç¦åú¡~ÚÕý}À£/­ê-uÊüo<»ÓŽþ­w]D÷På¢à¢î;N-xœZ¼L¤v³¡�»ÙÖ%¾4©h<,z¾¥™äut¼×
+Ÿ6ô’fŽ&û@d	!{A¹I1ùO!&Ó
+²>Ÿ2˜ÄáÎG9ü)¿²ÁrÔ™½ã7àã~€ª;'è¼UðB4²nÃÑ2–'ÁN;ú3Þ*ü?ÚªŠª•YZêð€rõ\¾ÄE^í…
+�¶ÍÍ^f"|-Ô—0zp™=Ÿ?¬†3©­ÒŠI®åÍØ^fSiÓ¿ŒËX9\+ÒGêý:ƒÑZ0)-Ø �ºÈÙ"{Kšž‡ã$¾6Ï_Ôri;��ur-;<IߣJËý~ÌÑóendstream
 endobj
-1085 0 obj <<
+1140 0 obj <<
 /Type /Page
-/Contents 1086 0 R
-/Resources 1084 0 R
+/Contents 1141 0 R
+/Resources 1139 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1093 0 R
-/Annots [ 1092 0 R ]
+/Parent 1148 0 R
+/Annots [ 1147 0 R ]
 >> endobj
-1092 0 obj <<
+1147 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [356.2946 363.7923 412.5133 376.6291]
 /Subtype /Link
 /A << /S /GoTo /D (address_match_lists) >>
 >> endobj
-1087 0 obj <<
-/D [1085 0 R /XYZ 85.0394 794.5015 null]
+1142 0 obj <<
+/D [1140 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 242 0 obj <<
-/D [1085 0 R /XYZ 85.0394 769.5949 null]
+/D [1140 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1088 0 obj <<
-/D [1085 0 R /XYZ 85.0394 576.7004 null]
+1143 0 obj <<
+/D [1140 0 R /XYZ 85.0394 576.7004 null]
 >> endobj
 246 0 obj <<
-/D [1085 0 R /XYZ 85.0394 479.565 null]
+/D [1140 0 R /XYZ 85.0394 479.565 null]
 >> endobj
-1089 0 obj <<
-/D [1085 0 R /XYZ 85.0394 441.8891 null]
+1144 0 obj <<
+/D [1140 0 R /XYZ 85.0394 441.8891 null]
 >> endobj
-1090 0 obj <<
-/D [1085 0 R /XYZ 85.0394 424.9629 null]
+1145 0 obj <<
+/D [1140 0 R /XYZ 85.0394 424.9629 null]
 >> endobj
-1091 0 obj <<
-/D [1085 0 R /XYZ 85.0394 413.0077 null]
+1146 0 obj <<
+/D [1140 0 R /XYZ 85.0394 413.0077 null]
 >> endobj
-1084 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
+1139 0 obj <<
+/Font << /F21 702 0 R /F23 726 0 R /F41 925 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1097 0 obj <<
-/Length 3978      
-/Filter /FlateDecode
->>
-stream
-xÚÍ;ks#Çqßù+èO
UÂܼvåÃYæ)çH'G¢ËdÕe	.É­°vq<:ÉO÷¼°
-áªën³3===ýîYvIá�]*M´ãîÒ8Ieêr¶¸ —ðîÛÇLÓ épÔo.Þ¼æÒ§¹¾¼¹À²„ZË.oî~žhÂÈ@ “o~øðîý·ýñí•‘“›÷?|¸šrE'ïÞwZ×ß]ýáæ'øE…›|óooÿrsýcx§#�?¾ÿð§ÐãÂcÔ¯ß]ÿxýá›ë«_nþ|q}“73Ü0£wòëÅÏ¿ÐË;Ø÷Ÿ/(ΪËgøA	sŽ_..¤DI!RÏü⧋ÿÈ
-¨Íꮃe#:Feu—Ëfùp5TOªŸ*,Ô¶=PT8¬exݵ‹:˜U
-À‡ŸOójV?¶ó;H೫çõ¬�]UË»vÚ�ÍÃã4ž;Rñ®DäF²-eÒ
S0쾑Ø×é
-ö¾�Ï[PÏž@Ôž�2ݼê£ú2ÀðN뱈zÉ~%["-—
-°5ÅÈÒ	s¥ÃN ‘yäq DUF”p"}ÃK$’ÒŒ\†€ç4ÑH™q3¢=âà/0!Çë–ÎÅ
M䡇ɣ€»äÉÿdimà…±ÙµÚg‡öæ\V1è-ù@&M·×*‚û§„µ‡­¢~±Tûª_¶÷ì ``FmƽVE$€Ó!Ä‚Y!D¡á×ÜM"ÐÁe‡ømɶQ"
Oœ
îQÕ,w”!¾Æœo§â‘­rèq­Æ{]V‹º¬œ úHÂܺ§è#×ËÞ{µô¡·.Øðp %½)ž*<:ðM£Wèãá3ÆÐdrã‚�
Ý·Qí8eØXë�•{»
-�Ð|Þ¦]†Ž®ž­WM€�©
·¾N
-ýQoe6‰â¯…½ú‡Æ¬…ý~éÃ�&ªäçÇf™«I¯ºðD�¾ŸÁG÷:føgêhfÔ*0÷LiXAÆp»êw”4xÃHœ¾ZIG€Ó!Ä]üåDZèa¸Ç`ÌÊì€ÿµ�üºnƒ‚6æÍ|¢K›têØýÜÌç¡åsOðŒ¹'hù,
>Ãiƒ«#O;3éÖ	FÕTüv°
-æ¡{³ðY²7‹Ò×]O6þ×ön4Û£þ÷ð„Ï¥çœ"Z²ßâ‡ûù‚)Â;¢è·d£tr‘ÓÀóñá
-ÐCŠq>Þ+–AŽ0Ø7©D2’’ñÝภ¹AdqDp“°r`
NíØ;»ÙÚE‰�àq£3V	–Â~fÏ�“H§C�¥œ„
-ÅÈ4E„ÖnÛ2£²g(-Ç4EsˆúC
¾”Ñpœ\ïK¢«o•'ulf}å…°5*ùc‡_¶f˜ÆZ¹Ç2¬¦Æ°nBË�ó%ôÐ
-t:( c切î'l
-èøÓG©Îó`’W`ÅÎð€ˆº¹;£<Np}(8—R‚Ì:ózÿ$CœAÔ®Ð`€A?æaGq4ZÆ!¯m6Ѧ¯Õ¿%[›§ì‹—ÄPy8·
-Ä!Vò`Ø»æõ¾x)<[¼4„x ^cÎú)ñ’¯c…´“‘>?Lâ<‡œê]Ac8F´ËÑÓz™²A»k‚Ö6Î,BÎYû–MÉÑuˆU”ú¾ZÏK|	ªÊÊ|E�lª¦Êȱjx[4@•Ë¯›�{Æ‹'.Àñ5Æ‹ã=
s�!AœAŒ¼,Vvà̹%’±qåæ×uÝy·¶¶µÓ5hJá�	;sš	Ì�³eƒ«/Íbíc?ІŸ«fò‹þç¢]/ñr“Q®\$“|
-ªº¯ç/Iƒõ£:d d¼ ‹š2EwÛ^Ì~�tèé½Ò{üg^ ábC·/CRA!fÃ
-3Òö%X—R±?�;[±q±„_ÐCô`£àna¡î\øeˆGôihPa#—mÉ[¦à:)‘ŒÌu(wU  hg’†‹g±í€¿¬ò%·}š”:“ïá·Gï
-Ÿ"Îä³Û¯�†¢ýÿ÷¦fÚß—´‹
-ˆ[F$Ö ¼×Þ€)ÜIh€
)Ú<öÕBž N‡ KB.‰„ž’Á!-
-º&TóÄ®?àÝ"­D¹Œ…©d­ÜAigx:Ã+9‡ÐrùNé	²~Œ¾¹9úÝΉp¦OU‡îBI\@´­>¯U}¿ª»Ç¢ƒ,¬œá§8è2ÜïŽ)Ú½Èmç
-I"øæ<=¡y
õÿGÁ0Lendstream
+1152 0 obj <<
+/Length 4061      
+/Filter /FlateDecode
+>>
+stream
+xÚÍ[[sãƱ~ׯ`žB¹ÌÙ¹_’ÊÃÆÑúlŽ½Nl¥òà¸| 
+’PK2
®V©üøtÏ�
+­«o®¾½úpýü¢ÂM¿úŸ·¹¾ú>ÜÓ‘ÈßøSèqár€ê÷W﮾¿úðÕÕåO×¾¸ºÎ‹.˜Q�+ùåâÇŸèäÖýçJ„³jò?(aÎñÉòB*A”"õ,.~¸øk&8¸ë-1PJF4Wb2³šp£Õá׆WPxml*GŒQvç­3m‰f÷„ZÂùvK$l‰‘ÄY31@D.üŽ4�»<±†(áÜvؘÂ�°µe–ÌÁÙ�âþì%ŠïNï±]÷8Á7ï c;–qh�¯ÀQoW(%vúþ/x5ƒ§Fo�†au|hµYÞÔëq¡ˆÕJÅa jÜééõC] ÈAl¬<IÐ'„‹Ãš.LvÑ,›¾¾
3îÛÐIãχõ%³Óvsÿúa>B}‰´'3&1œCƒ§÷TŸš‡23ýT-6uÚ7õ¢}¦�2Êeè쟛yµX<‡ŸþMuׯ›y˜‹Ó�îÍ%›vuhßÄñ�ajóºëà58#:žÊú\­šÕýåLP=­:¼ªð¢¶í�£ÒÀf­Âí®]ÖaÀ¼Š_B›ÓiµJ÷õºé>†ÿ Šþß¿…·çÕº‚y¯ãOxl4£`vnðÊL7.[~N
+ȇŸ�‹j^?´‹[OH൫õ¼�]W«ÛvÚÍýÃ,î;rñ¶Ä”F²«eÒ�P0â¾ÕØ×Ù
+JÜ,Ð@ÔõŸA—[ÜKÃ<5¼Ve‡â„“w”[JœƒG´QÄIÍ^½£™âlHrG¹…]²€lò°c;jˆ¦:íè²z+nÁ?�G
+·–ÍýCzï6k0äëÐS— Ì6ÿ¥B¸è�°·þИ·°ÞÏ}øÑD‹üôÐÌ£p5éVÄChÐ�Ø`ï^'ÿUM½ñãÆ}>Ã…4FÕ?ìYiˆ2ð8|µ•ŽgCŠûóc”i!Íð
+´1Œ?&‡`2`¸Õ£4}IóÀ³Éá�â9Íð\Ø•C°N-(’KØSLèaðK³C-d€ÏJŸoý‘Þ‰åsg‰’@¤¸Aû?L"eb
+ùÕ†‹Ƴ
�ñ=D•3Æ™L¢ù.wC³é"J S;¡ô0]*©‰:¸†D4
+ŒhÄ�:ÂHÌXa€‘šàùr‰âlH²”“09Í·o>*4RÑdÀ‡g®…T?Å
}Lxà…þålkÎO¬YhX³Ñn¼æ£Â38¾QÞGÄO
+KeøQ½‘†Ê©>ßÒ3ÅK—€FÀ–È—l7¦yÁc›£·Ü ·—´¢�
Ä–RŠé"$š|Ø%Cj·x²ÇÀ˜Ë�	Úzá�ÀMg^�Ê3ÅÙ�dI8ð…#
{±eÁ3ˆ.ýÉ.|ò3rÍF¡µÛõÌhì
NË1ÏC1‚¦46”N
+€®¥ê[åY›Û„8þ
+/ÀÖ¨”;üai†iÌÙûY†·©�\{BXî\Jå;è 0
{G…	þ�maþôaªsAÄ<™„J­Ø.R7·§c”âèC
üMÀƇÙÖW›ÝDq6$Y0»Bƒû˜‡�(âd´4ŒCÎuZ�ù+Eõ¯¡™9/qcGÃ%ŠèÃD$Üü³>.¥�ç—�…K£VI¸ä�CÚÉHŸ�&qžBNõ¶`0#Úåài³JÙ ýw‚Ñ6ÎRÎIû¼
+%GäQê»j³(‰%X*+såÙF+#Ç–ámÑ
+Ô±41æ(¬œ~líÍs_w%L „ËüÌ·ˆfÐõ‚‰-_<±e}_ʼn�çwƒˆzLjs•ë_¿>Ãï_<Ãû&—ÂÂ4ÛÙ¦íô…ÈÁ±
+Ô1‡ž=ÌÏ\rEm¨H…'´ŒÇDеYuÍý*
+“@ÄŠçB”‡bW°ÖÌJ©�”ÔCq]šù#!¦öŽ„`Üôo]¬ Û˳ÄKú%¾]˨ޖ9…Õ“]|Ìßlšnê.ÛµtlÔFUÝÕ‹T
+S÷£sÈÀÈX÷Œ–2w»(æ0 
+žèͶKê-‰?˜^À¡E×°NžÄô;,)ÒJ”¯0�¬•;ªåëÉ3½&„–˺/ÐñÐè›»ç“_A½�Îì±ê%”ÔTÚêÏk]ß­ëËAt•Û…e›(Cµ|LÌœÜnè?cX/J�•–±È
+jLŒ˜æxqºñ�¿IýÅã=þ\%öú�oõ꾈CþuèÃcUJ‡w7žæU¿ú£äí'ÛÒagÐ;ð-JZœòEð½™3
 endobj
-1096 0 obj <<
+1151 0 obj <<
 /Type /Page
-/Contents 1097 0 R
-/Resources 1095 0 R
+/Contents 1152 0 R
+/Resources 1150 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1093 0 R
+/Parent 1148 0 R
 >> endobj
-1098 0 obj <<
-/D [1096 0 R /XYZ 56.6929 794.5015 null]
+1153 0 obj <<
+/D [1151 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 250 0 obj <<
-/D [1096 0 R /XYZ 56.6929 194.962 null]
+/D [1151 0 R /XYZ 56.6929 165.9801 null]
 >> endobj
-1094 0 obj <<
-/D [1096 0 R /XYZ 56.6929 163.332 null]
+1149 0 obj <<
+/D [1151 0 R /XYZ 56.6929 136.242 null]
 >> endobj
 254 0 obj <<
-/D [1096 0 R /XYZ 56.6929 163.332 null]
+/D [1151 0 R /XYZ 56.6929 136.242 null]
 >> endobj
-1099 0 obj <<
-/D [1096 0 R /XYZ 56.6929 131.4748 null]
+1154 0 obj <<
+/D [1151 0 R /XYZ 56.6929 106.2766 null]
 >> endobj
-1095 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F21 658 0 R /F48 885 0 R >>
+1150 0 obj <<
+/Font << /F37 791 0 R /F41 925 0 R /F23 726 0 R /F21 702 0 R /F48 940 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1102 0 obj <<
-/Length 2913      
+1157 0 obj <<
+/Length 3064      
 /Filter /FlateDecode
 >>
 stream
-xÚ­]sÛ6òÝ¿B™{ˆœX4Aðóú”8vëNëægîfšÎ”¢`‹cŠTIÊŽÿýíb DÓòõÚÑÁÅb±Øï%f>üÄ,�<_fá,ÉB/òE4+6Gþìæ¾?Œ³0HëýõÑé…Lf™—ÅA<»¾qh¥žŸ¦bv½úu~öû�×矎AäÏcïxÅþüýåÕ‚dô8ûåêâòû/ŸÞ'áüúò—+:¿8ÿt~uv¯@Ö¦ðÌ‚‹ËŸÎitþÓùÏçWן�»þñèüÚÆ=°ð%žä�£_óg+8÷�G¾'³4š=À‹ï‰,f›£0’^Ji ÕÑç£Y‚ά^:%ÀH¦^”É„1%Á(óbH-A<´ð‚ã…ð}þA}õý .û²©é¤y½¢Á—.¿Ux^ *ªþlÄžïÇ™¦÷nµj�E:W]ë9ßä}±¦aUv½†óœ�¾mËMÞ–Õ#½î:µ¢QßÐs¥zÕnÊZñ⢰䋦î5­¦"ÀMÓÒàH6;Þ¯Sí½â‰f«ÚOØ�ºe’ͯ×êO†gÂË¢(Ðgq˜„M«®¡ÑîXÌ™Å`^Öôì×F8{"OA©1hOÓÃó«z
¢}*ÆPz~%Œ‰RJMd^”„‚qº¦í‘â1z�L
±®Ï{µQuOç�ð¼Ä´ªNoë’4%Pª]_ö»ÞžO™ïk7`í¢ììKøajd(ì™É€ŠœMj©Œi=Ò ¹¡g¿æ™›¦ªš‡²¾ýçsgÂóA\Šƒ¤½A„ŽŒ2¦r „Ì~õE2ÞŽkÂäà–éÉž{z>ŒÃxoO#•Ë�,•=à«ù—ïC–UkÐïc˜Ï
-(	0bd/HÈÁ: "ƒõ²Œíêi¼í´”ÜmÇbÚ’�0\}äT2Ö璘iP7½võƒ¢‚›„~ú‚¨¬¢2X/‹êЮŽ¨ÆÛN‹ÊÝ6§£ß)v¯Ë'lZlQ+ŠòŠ#ûòqp¿‰ Q'…‰:w*Ç|d½R98ÏJ\Â
-/)Í¡`„Úµ¯`=�‚ñ¡i$R7µ"ÐDA„USäÕºéz^¼¹ÌÄ€P«¾ÃÛB
-_8r[S‡¢$
Î~n$7Ôqæì¸Ê<{Øš	ñYp¨ÅŒƒ%ÏÝ4;ÃSiWªý3‘¾Vª+Úr;T¼Oªt+=°¾ãYBŽâ©ªŠb4/[@ÇL.2äb—ã9hw×1p“¯ÔÏÄC"†©²£Q÷X÷yÑ—­á:Žçš�LmEÎâœP7eWB‹��Né¼+ëBM©»SÅ®-{.Ë�o]ô…lÔ	µS±‡¶b¿Ï«r•SùîìhóÍ®§Rù-ÙLjDN45š0…=ØÖC£=
I_Æ¢\¸©˜_�ƒ+ØôdJçVµØVpõ€ÞðB\ ƒÖÑ 3QVl;*ú55$»[>¨kL«¦Ø¡®´iOÚÑ¿×
--Vú(
dóÛòÞ@°úAЧ8�²Á‰ý²g�Uœ)šÍ–ýpE3(hMÌl·G&øø8‡Çs‘aFG10B,™‹¾Í¡ËÒ‚ÐàÚ2‡ê£›0²]
2Ùd1åÊÌ5ç,&&j6cv2
-c
l¸ÒdC²Iœà€�hªV‹±8ÉS«á‘О”7SuL˜˜þd‚^ìEIîQûc§ÚIb‘'Ãàÿ µ :*>/M娳/òb=u!„5iG¶‹€H"÷¶ƒÈQw7!FôâÐi¿DoŸýÝVgŸ	j¾'…ü“ܵ8ûCÞêm¢ÌxýaÙÐÁ2}æ"/Ì@ŽŒº¬òânÝTSì†)`J1pƒ‘5�ëºái"€çBF‚E±®O�ЗpM¡æú\nÊ*o«Çc!„fÙ&
-Š½°%Ycj$˜z ´§+/ªa2g¡½lC`CO°t"ƒµí	ˆFVêz”+<|ÒµnFt7`qe­^O{ú 	Õ™hXšô½jì}À“Ônã$x5é÷ÊœRdÄU`V

-²ªSÍ”4I‚u€—„PûàÄ=aÄïL\ëK†Ø§ÎŸ9=H/8²ö¤g
vMÏ3"ŒñÒ�ÄĞ̌?e�õ3/Píµ"§§D÷/óõöíT§ó�¿‡:N6<þruùi]zØËà@«þ€º¥£î¿ï»ìÙàÕºúáÐg½’¾Ç¹n­CXÞÛRjpë猚Ôá;üSGÖßkÈ‘'”r¶Ð^�·��$”¬]Ÿ·=MÐí©4wžê‚ë¼Í‹^û<Nœ¾!8^œvUÞa'#"§¿
i,ê7ñê•îoN	¢)À*¾@ÓD� RÁ¿D©­§ož°ðçNÔOökx_©
-JsjuᕹðõEgÖØ#žpù
- s/
²Ä0…ç•r̹ýÆSÖÿœÐådendstream
+xÚ­]sÛ6òÝ¿B�{ˆÜX4A€y}J]§u§ur‰3w3M'¥%Øâ˜"U’²ãéÝ¿]ì"%Z¾´7z
+ÕÓRÝTöh¡¼C¡w™Âª`’Ò‡¹z¬}¶ƒÍ!ôU2dëtsñ–u3Ptluxñö^±Æ‡~Ÿ¸ã>ª¦HZÆé3jêaP“Ãz^M‡¸öÔ´Ëv\M}¶»jZ“’Ði}Þê©`¬ßN_P§ª;{àª
+ø©LfϨª‡u@UëyUâÚSÕ.ÛqUõÙæ´tc¬Ê¾;aÓb‹Z�¯7ì߯·‡pÄõ€ïQJ8ßsGsWŽ|X*wÝÎS�3<1°9¨ñ>ÖÓ÷XÏjü ×­Æ÷ØŽj|ÀÖ»/ŠÛ}ÏæìvïX»èÝ­§ÜÙ™‡¢[Ú›(RAªUìbǼÛ›8ˆD”þÏ{£!qu`ozXöÆa=¿7‡¸ööf—íøÞôÙòi¨DàÅ—ì…©æeݺ9γ\79¤ ÷@ûY˜$
+Ƙ׫5ÅA¬®SÎòLj:
¤äDÐbø(ÙyD±hkžßåw†g®Kp”Ì¿Û„|M’ÖŸ¡ìÖ€2Ó7èÛ„Í×ìwW¬ÞDÑô‡úÁÜ{Ó•2£³$£°'HKÓh¿o
+ïU�Ö2ï\�A䱇I‘�#äÚMkr`k÷?7ì:uó±ccuÆ篗†9›±®éd§ÆyHÐïÉ
+ûµéãi�$m©Ú�	™†M£s~†ìª±¾ÃF¸ýFȬMµh	îЖƊj��£ÏJPÑäÚX ˆm�Ž çØ+ã1š„‘K‚�Àˆv·¥4Õ
P·'ÃÚÈÅêÜéŒÊå]�ûµhÏ—ŠK™9l�ª™,8WçbNµcNÿz`Ë
+è¶�'’X!;òž¬rëŠ=�'æ/LU?6¦c$Š®T@ñ€áCe[¥OgÌUMß–þ	õ½P=<ËC½3)CŽ€íXf«D&PÐpf‹kžA1WÜŒ•q%Šv·'#ô SÓq< Ö`tk‹Ñ;-ˆ#ÉŸ$H:ëNƒT©h¨ÛQ~€
+5p–}UðíU{¶½O/Q�HÓäËèÑÖ+(
´ñ0âmÖ6%¹µA¬ÄaN¡H£
'¢6§ú�7ö–{v…7sZyÊ3ÉžbäÈ%A:‹¾†è}·¬Ë1iUô}^ŒÅ6	¤Î ‰�Rù Â•HËþï‹UQæ
~!„“�b
+cú+S¨µ"
*P;gÉ¥íP¼<P&½9§ÕÐåb(ÙÞ#°¦–®GF#ÏŽ,]U"àf‡ä*Ç(o^ð„Þª
w­
+ÝóF_�é§
+TÀh¼yCÙ2EaÍ\CÔƒEºÀžr$Ö�ÝßVTÈÚ�Þ,�ü킧¬¶5Ì€ì¨b’•¡Ž†Ä€Z‡õêì§!+WtiÒ±åàò	M††lÖ¦²8RÙ±»÷�ù@>Pc:g»ýÜ
F(ºáð„¥ŒE%{�!§q
+¨4TGá7Øë@`:[ªyy[C}¿\Ñ'{Pyç„8ÖÿÁ¬²®ï6kÒKÛž\Ö±Šhß¡‰�ZÉ»–
+£ÛMãîX“ÔšH‰2Ó«ãÃ�°Jši¥†–
ç¶ÉaMMK@ëopBÉØw”Ñ'ô¼Ú-íu
 endobj
-1101 0 obj <<
+1156 0 obj <<
 /Type /Page
-/Contents 1102 0 R
-/Resources 1100 0 R
+/Contents 1157 0 R
+/Resources 1155 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1093 0 R
+/Parent 1148 0 R
 >> endobj
-1103 0 obj <<
-/D [1101 0 R /XYZ 85.0394 794.5015 null]
+1158 0 obj <<
+/D [1156 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 258 0 obj <<
-/D [1101 0 R /XYZ 85.0394 769.5949 null]
+/D [1156 0 R /XYZ 85.0394 731.767 null]
 >> endobj
-1104 0 obj <<
-/D [1101 0 R /XYZ 85.0394 749.6335 null]
+1159 0 obj <<
+/D [1156 0 R /XYZ 85.0394 703.7216 null]
 >> endobj
 262 0 obj <<
-/D [1101 0 R /XYZ 85.0394 336.0663 null]
+/D [1156 0 R /XYZ 85.0394 229.6467 null]
 >> endobj
-1105 0 obj <<
-/D [1101 0 R /XYZ 85.0394 307.6963 null]
+1160 0 obj <<
+/D [1156 0 R /XYZ 85.0394 201.8883 null]
 >> endobj
 266 0 obj <<
-/D [1101 0 R /XYZ 85.0394 248.6123 null]
+/D [1156 0 R /XYZ 85.0394 144.1965 null]
 >> endobj
-1106 0 obj <<
-/D [1101 0 R /XYZ 85.0394 222.7648 null]
->> endobj
-270 0 obj <<
-/D [1101 0 R /XYZ 85.0394 150.9902 null]
->> endobj
-1107 0 obj <<
-/D [1101 0 R /XYZ 85.0394 123.8975 null]
+1161 0 obj <<
+/D [1156 0 R /XYZ 85.0394 118.9605 null]
 >> endobj
-1100 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F14 685 0 R /F39 863 0 R >>
+1155 0 obj <<
+/Font << /F37 791 0 R /F41 925 0 R /F21 702 0 R /F23 726 0 R /F14 729 0 R /F39 885 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1111 0 obj <<
-/Length 2398      
+1165 0 obj <<
+/Length 2262      
 /Filter /FlateDecode
 >>
 stream
-xÚÍYYoãF~÷¯ �‡P™Ý7ÙÉ“ãx;“ÄãÅb‘XšjKD(R!);š_¿ÕÙ’écÖÞ 0`öQ]Ý]U_-!øÉ�DF©d	G˜GÅúEK˜;?ÂŽfî‰æ!Õ·WGÇïhÉD
-"¢«›€W– ,ÃÑÕâ—X$$™
ŸþøáÝÅù?/Of)‹¯.~ü0›Žâwÿ8³­óË“÷ïO.gsœqŸ~òÓÕÙ¥�ŽÇ·¾³#Ò~`zyöîìòìÃéÙì·«ŽÎ®†»„÷ňê‹üqôËo(ZÀµ8B	•�î ƒ,%‰ÖGŒÓ„3JýHuôñèç�a0k–NÊ£„PA&Hè”
-vIS°6ŒõY¢?@ë-5MØ6—…bŽ/Ö4ú®�+FÁ-=ßyÀØ\2öÑÊ¡¨
"Ø]rpWÂÚú¿g˜�êÁû04FRÝ6QG7Œ=èF§ÖeÑ@’c»Ú=üç›/­G`)2¾g†Át�ÿ±k·
-#¡0ÿØ«Ï=ÿàW€Ù]iN ,F,
¡DšÐŒâˆ`€�áÙæE5
NŒ2(GSJC°6ŽTHã.!>ÔùÚÔc0rñ“Ê«‚Α®ó¾X}éé
-06C¥M¶ŽYQXjqÀmaWMÙh>$™
-ß|vup1$5þEÌM6“Y@[~
-² m7Dª«�ç�¨+�Äkù©×W…¢
-?eâ,M2žÚÐõêRKàó4FSH(Lò-÷°ŸA‚ÐÞŸƒÀפÌ¿Z˜%j|÷ÖZË`
Q&_BÙwvÀ'jì&³úA[£ ^WYì•fˆ?¥-Í…¥6¨Tw­z:¢„5’‰*÷c
“‰¿:Ù,á>[Ê žQGdÞeu2`2F“IèŸÌÐ~ÒQ•ËU?¿Súc'ÜAšÊ؇Yä.GŸgPÆPyðà¿öøÔïÄù	ÔÓ
-4ŠeòPÜg4x\Ã�˜L Ž¿-ÀAXLò§Ü1B	¢ßë¼3?+|Nú˜r«I6¤�0♎N-…ÍaÈÄÀΖã¦kç»~{íXÖŽSWé—ý‰ç¸OÍðï73ÙO•?žABùÛ*N HçùãzKE‚‰°zk6:F=ë>WÔâ’Y¼¬škó”üà‘aü~‘~CaµÔŽÜTk0¿P7ù¶š.Goü3o�ê�ÕÞÃêEñ2Ñê‡ÃŒ¢´Å̱œúEÞÂ^ü«ýø
”f™þAž¤àG2`¢g)µ¦MÙ½7\ÿû¾'ÿ_À�¶endstream
+xÚ½koÜ6ò»…€~¸ÝÔ+“"õ`ûÉqlŸ‹KÚs¶8Ú'k¯P­´•´qÝ_3R¢lÙIϹ€ÅÇp8ï—þx'a¢"¤J†1ãqPìŽXp{—GܬÐʇz½>:¹i B•DI°þàáÊB–e<Xo~Z$a.
[œ}ÿîâêòÇëÓe*ë«ïß-WQÌWÿ8§ÑåõéÛ·§×ËÏb¾8ûûéëókÚJ,Ž×WïÞЊ¢ÏH¯Ï/ίÏß��/Ywt¾xñùåL #¿ýô6ÀöwG,*‹ƒ;˜°�+»#‹0–B¸•êèýÑ?„Þ®9:+?ÎÂH$ÑŒ
+ãab¢Fd‘�L\„EEplB#®Y"64ÍãäM×Ñ|Œ]8˧wtßÂ8‘Wam›´°MmUs;žã.LLˆœq·™€yLc�ÛqÕ…WN(jùÑƨ$F-MҚ͸.tÛØùlL¢P�xÑV_iV<28´sÍßí
ÃÜŒ~ݵƒã»ƒwÌÇ4Óuíˆj·[{¶Ÿâ°ê�øÌ…Ïĸ}«?–Í¡{ì¼3E™ç�ï·ºª|D·qšØëÖîY*­Ü7AÉèƒnGÏú”–á;¡ eA…J¿ša&
+È#%€h‘!-Áo Å¥ÈæG¡˜…“«�Þ4Àbàqé¯|̆KhUG;‡n Ò@
+ºÝ•unÞK¦=·½ÊôLÚ_»rÂ!ˆÙTáoï{|"Ñ›oúg–†R—жIÆ?Ç—„_â «‰/ýo§¼Ì	Øî¹óQ|p'8³e	Tª ã©lþ!ò‰Èx·€ö9å”2ò¢šñNÎ2èHS›7ô¼i"i¢L¼„Qç;Ó’ÁÊÕ´”o6¤ƒÎ‚îò¾Ø…ávN‹�aJ�*[‹¬(:5ï�=õvÕœ‘oªM¿ÕíÐOu�#p
+IZòÀ—ÇË$ŒºŒy’Ž}>Jwâ)¥1(SR™|Biʉ„�îÚ6U÷š+*ëÝðÖ;Ș¶P&誛>
ÞèA¾Vè7÷cqO×údrÅ°qÅT[oŠâ iQ‰pÄú²*ûû%ç|ñŒ=ñ¼LàÿGª8„*ŸW¡R
 endobj
-1110 0 obj <<
+1164 0 obj <<
 /Type /Page
-/Contents 1111 0 R
-/Resources 1109 0 R
+/Contents 1165 0 R
+/Resources 1163 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1093 0 R
+/Parent 1148 0 R
 >> endobj
-1108 0 obj <<
+1162 0 obj <<
 /Type /XObject
 /Subtype /Form
 /FormType 1
@@ -3907,2690 +4095,3034 @@ xÚm”In1EOPw¨u€$ÅIg0²Êľÿ6¤¤êV5oʯÅésÀó�ή¯�ƒÖ×O²Î Ž¢‘ÿ¨#h8Çùø:„5?ù
 6\>RgÈbÏWÖ¹j[†�›
 WŒÏ¢®{6;»²þFÃÇñ÷ø]š¨)Õ/Ô¬Mu;pk;Ì©Ëdh<åE–ñ¬AÏw³ð¬±±Nê¦ó¡Ä½�t•‹ùD„™Â²]°Ä(�‡;�„ ·åŽ°Š­r²ÂÙÄLûˆ
T¥Í¡誋ŠŽt’¹w_=Î]ˆ‹=¦uSä÷—ä"ï±yl±‡µÃ-ËkHsŠöreOÚ³êvg›<7ºt,‡Ýe—;ãÒèЭ/I…B÷&ê(ýê³ö󻉨YÙ¹Ç,çkRÔšÚ'^
m"	^�˜h±�ÎW9AVªy­Â©/f�ýÆ"•œãûFy-Sng	\Çdª¼˜©Æ¥†Í}B©•µŒÎ$âw1.¶&�Øíþ²C¶O–ÃVç X×9g¹E{îÇ<•ãóP)!ÍZÜÅŸLÞª~ÑÔ'¯UâXLµüc“ÅXsЖõÚ¯½˜Ó’~òBL–§èªÆ¹O¦ºNZ�_[Èü.øšŠû*]3QôçÇñ!Ö-žendstream
 endobj
-1112 0 obj <<
-/D [1110 0 R /XYZ 56.6929 794.5015 null]
+1166 0 obj <<
+/D [1164 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+270 0 obj <<
+/D [1164 0 R /XYZ 56.6929 769.5949 null]
+>> endobj
+1167 0 obj <<
+/D [1164 0 R /XYZ 56.6929 749.9737 null]
 >> endobj
 274 0 obj <<
-/D [1110 0 R /XYZ 56.6929 330.9243 null]
+/D [1164 0 R /XYZ 56.6929 246.2071 null]
 >> endobj
-1113 0 obj <<
-/D [1110 0 R /XYZ 56.6929 299.0803 null]
+1168 0 obj <<
+/D [1164 0 R /XYZ 56.6929 214.3631 null]
 >> endobj
-1114 0 obj <<
-/D [1110 0 R /XYZ 56.6929 240.311 null]
+1169 0 obj <<
+/D [1164 0 R /XYZ 56.6929 155.5938 null]
 >> endobj
-1115 0 obj <<
-/D [1110 0 R /XYZ 56.6929 228.3558 null]
+1170 0 obj <<
+/D [1164 0 R /XYZ 56.6929 143.6386 null]
 >> endobj
-1109 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F62 995 0 R /F21 658 0 R >>
-/XObject << /Im3 1108 0 R >>
+1163 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R /F62 1050 0 R >>
+/XObject << /Im3 1162 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1118 0 obj <<
-/Length 2415      
+1173 0 obj <<
+/Length 2334      
 /Filter /FlateDecode
 >>
 stream
-xÚÍZÝS#7ç¯ðÛ™«X§oi²O„e÷Hí’= O›­­Á`níÎ3@È]þ÷ëVKã±óHUŠ‡‘ZR«õëVȈ‡?1ò†q•é‘Ë43\˜Ñt±ÃG0ö~GÄ9“4iÒŸõÃéÎ?Þ)7ÊXf¥�ž÷xyƽ£ÓÙçñþ?÷>�ïN¤ácËv'Æòñ‡Go‰’Ñgÿ§£w‡ï>ÞÛuz|zøÓ‘�ÞíìN„7ÖËÈaË‚w‡¨õþxïãǽãÝ/§?îœvgéŸWp…ùÏÎç/|4ƒcÿ¸Ã™Ê¼ÝB‡3‘er´ØÑF1£•J”ùÎÉο:†½Ñ°t?-“2S£‰òLã·oK[pØ66…`™1›»N„0L…:1–qm\§)z:R0'33r&cVI”ÒË›b‰ØÀtÕŸÎ=Úá64¯mÎi±ló²Š�ºú…syq½ÌÛ²ŽÄú
-Ûqz"æô¹‚Í„Oâ¾�v–7eÃ6õc¸cÞq1êëeP©L2#¬CÐhÂk¢¯5ã7�¡¯³ÎÑ•h—×M[Ì&ߊ»æqÌ
-ĺ*"²ír×�Ãzê¿=:99ا62|
-‹ü.ùûyjM§×ËDœ+ÿ?9X'YÒ=l	&-™Í,˜4Üq!¸
{cì�p8�¿“$PúË|±Èc`SYï´¦Y¦
Xâ4©òEA½ÿâÊ\�sƒî’†³Ù²hš¯‹¼�^~�—MæN6&“‡ÿýÍÐÁ@ÜßH>r ·tóÊU˜Eu†ÆÏM~1tw7NºÝ”„O¦„»8

-BÑ€;�Íã}¹¬á¾¤P$ipÿ}a^šB(f!ÿ9˜�3Í Ay3ˆFy²ïj8ïz
-¡D²‘´ò¸iaˆ0‰¬UÑÞÖËoÔ)«¶Xžç�àˆqZPu~§çÉÚäwš;(ÚÛ5ׇäe0¯4醗ü95tZ±]sÚ3)ùcÖ®<¼Ñ÷ÕUÆŸ¬:‘éàX ¡‚Í	³ ¢RjYÒ—tŠc�¾�|žÆo/K¥8!¨i¤š!í]æ¨\¡(wr¥wHRdæÇ'uÈD`1ihÚ¬&bU·Ô¸¢DáÌ¥œÅ9}nC
�ãºY
Û,Jr+¡DϤ¤ŽLC ÿ•(ó¢&íeCý`ÄHG
P3=´ÖŒ>$]b|XÑXs²IRaš7ÅwC¾l@.ÙU%ÛU=é殧`]í°è;¼îâ$Ù¡e_Ï׊æ;¢ý;$A”±}Êz%§Ò«¾¬[<Šæ�BÛ”=pk{×áeWlukŸSæ¾~b! \åFP—a<ÒË\%¡œk™C¯öIï®ü‚6Jt�ŠÐ“ézÞ¼¬®[qY•s)\3ºÏ4nXK-LØ#íêk°®Ðù±»�FGÈœŽyÏßã1í
`ÎO«ã.Wõ²íx¯:_b	Šùhx"$çCÅ&
üNIs2¡5·žü
+xÚÍZÝsÛ6÷_¡·“;%Š/â£}r'çNâö÷)Ídh‰–x¡HŸHEuïú¿ßP”MYv­Îdü@`
,»‹ÝýAf#
+ldRB…•#m%I)KG“ÅÍ`ìÍs’8)éÏúñêè»×B�,±Š«ÑÕM�—!Ô6ºš~Ÿþóä—«³Ëㄧt¬Èq’*:þñüâR,~N¾x}þæ×Ë“c-ÇWç?_ ùòìõÙåÙÅéÙqÂLÊ`=v,x}þö[o.OÞ½;¹<þxõÓÑÙUw–þyî ÿ9ú𑎦p쟎(Ö¤£5t(aÖòÑâH¦‚¤RˆH)�Þý«cØõK‡ô'¹ œ[1JRJ$c»wÅ(ìš°Ò:9·7MK‰H…3‰”„Zº1	g=“0Έæ6éÔ%¸ð6)ëÙ¬¨fN70_ôçSC˜Ôn7±¹Í'Åo”ò¼
­
+=^ϳ[í<w
3nòå—|‰D`Ü|MIÇY5�K`”™q¾µÎÏE‹ü˜�›&›á&fœ…ù È
g%6M9
+”W-¹oÓ”jb4e£¾.^¦_a9I™Ò£$N8¤É8Ì4”ï3™H¡Á,šl½õì5ؤ®œ¹f+Ta\Ñç/Á”’aA•-òé
+µ™5m¾|‚çLsç8•»ƒB§hOÜÃS"'ß)‹¦Å7õIE5)WMᬇ]oÚÕu`YNM™}¼ÝÔUŽ¶ï6s�I™­š¼Ùm¿¾b¾â{¯4‡–ݪ•ÑÄR†¡º¾mA¥O»ù­¿kuéÔfÍxVÖ×YéÚv¤�¾‰YëÍå&Ä}üŒÝÖÅö¶Áñi~“­Ê¶2›w
g¨º�ç¡Ù´Y›/ Z?f¶ž>¾f³IC¤´ûµRÀÈR×îøpEŠI“LæYUåå“® xzÜPå(0Õb±ªŠI0”'Ev¾ç"³ûÎòÙd’7~P»Á�ð)¡œ‹=ñ?éæmçßî\�˜µ§¯C™5Êðt–qÅn³
+E¤•û¬*)Ô²T…êÃߢýe^ºòe›!¡=¼xîÎtÏu1ÃÏ-VNIw{�v�5ÅcÊßœêeŠú{uÏ
G³/“)jå©Ä"d¹‚œ0M>çwÏKgNkÍدÇþ«‹÷ïÏN±í>¢Ðž¨‡Õ(;¨F07
+M
+ŠÉ–ì6uÒÍÝ®Á:ð°è¼îÞDÙ¡dß.ØrÿKÐþí« ,Ù>•½Ü¡SnD_Ö
ERHp*F�\ÚÞmxÙ
Û\ÚçàÜÃÌÅÜ”§ ‘ jµ'â\f”å[ï=ô¯†à
 endobj
-1117 0 obj <<
+1172 0 obj <<
 /Type /Page
-/Contents 1118 0 R
-/Resources 1116 0 R
+/Contents 1173 0 R
+/Resources 1171 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1093 0 R
+/Parent 1148 0 R
 >> endobj
-1119 0 obj <<
-/D [1117 0 R /XYZ 85.0394 794.5015 null]
+1174 0 obj <<
+/D [1172 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 278 0 obj <<
-/D [1117 0 R /XYZ 85.0394 656.7756 null]
+/D [1172 0 R /XYZ 85.0394 537.224 null]
 >> endobj
-1120 0 obj <<
-/D [1117 0 R /XYZ 85.0394 632.436 null]
+1175 0 obj <<
+/D [1172 0 R /XYZ 85.0394 512.8844 null]
 >> endobj
 282 0 obj <<
-/D [1117 0 R /XYZ 85.0394 563.6675 null]
+/D [1172 0 R /XYZ 85.0394 444.1158 null]
 >> endobj
-1121 0 obj <<
-/D [1117 0 R /XYZ 85.0394 533.5536 null]
+1176 0 obj <<
+/D [1172 0 R /XYZ 85.0394 414.002 null]
 >> endobj
-1122 0 obj <<
-/D [1117 0 R /XYZ 85.0394 456.2156 null]
+1177 0 obj <<
+/D [1172 0 R /XYZ 85.0394 336.6639 null]
 >> endobj
-1123 0 obj <<
-/D [1117 0 R /XYZ 85.0394 444.2604 null]
+1178 0 obj <<
+/D [1172 0 R /XYZ 85.0394 324.7088 null]
 >> endobj
 286 0 obj <<
-/D [1117 0 R /XYZ 85.0394 307.3784 null]
->> endobj
-1124 0 obj <<
-/D [1117 0 R /XYZ 85.0394 280.2293 null]
+/D [1172 0 R /XYZ 85.0394 175.0326 null]
 >> endobj
-290 0 obj <<
-/D [1117 0 R /XYZ 85.0394 163.9859 null]
->> endobj
-976 0 obj <<
-/D [1117 0 R /XYZ 85.0394 133.872 null]
+1179 0 obj <<
+/D [1172 0 R /XYZ 85.0394 144.8676 null]
 >> endobj
-1116 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
+1171 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1127 0 obj <<
-/Length 4048      
-/Filter /FlateDecode
->>
-stream
-xÚ­;ÛrÛ8–ïþ
-¿­¼eqp%€ä)“NzÝ5“îMÜU»ÕݵEK´ÄŠDjD*Žgjþ}ÎÁ
x‘ Û³IùA$
-¾«Ð+>«�़Çq¹(<°%²
-	5õæ‘ž�ħ¤u&“ÒDxûz¹H¡.3¥m�zM
-Ü„úŸšM
!lÉyä(<xÇݶ!
-€�!—8’c8�föß¡õ°Ý Nø²Ûm*ÏaD¤™ dAúhmÝÑIJ
-iC×ì€ö¹Cxò�WôÒÏU×–›{"E†€è(4zZûY"¹›íöÕ¶ð8ÂKqèÖ;ú{�

mKTäªÅ'·dÿa¸‹ß‡p5¼ô:/^?ÂÒD¨‰¨»>öKøJ¡Á¡	f*ìee�§Mp„8ƒL˜`q½ÓÖ/{ql‚Éëëj±&Š¡aˆQÐ�‡åŸbÁ`‚À\ª<Ó¹OG
-‘ 8물ÔNdBéo/‘D€ó1ÄSp<˜Àõ«ÎF>ÿ�†ÊÛegï
-r¹Ç„G£ÆÜy™ÀŽÃ
-Îw;oñ™£Ùv,w/81‡(C«è½;rç¼�°™âO(
 Œ¢è¾ã�#Äg, @·<âäÀç”À@ৣ�õšGŽæÄ›M$AC¿å×rqðN^†|ß(ß�ô‚sYàde‚(}*Ëså`mY&|þA3ûÕ%=|L•Á‡Õçk¸a
ò·�å–<Ÿ³…÷xFÎ~(`¸¦Ñ·ÌaÒ;‘…·®œ¤Zg` äë“’s¿æId�ÇÜ{„mUŸìÁºæ‚¿ŒJýê§w>‚é½8¥ëD™ÉŸӔ€gJª'ÏÞ¯yƒcH#�nb‚Œ¨jŒJŠ
±â®9t4ò†ÑÜê?˜�å‹K4î'r55ÌUªºÍ}�Ë=S‚e™2ò¨€Ä1£s‰’!×X2LX
ªÞd¼Â4›TÁŒ¤1°o»¢óÉ�öj¿»�ÃÄuºvgtq®AòSFB.ûT˜
-×¼-Ãngúß‚~–å}qØ„¹©ÊóQ‰_ƹ
×!lÒ1lÒC5š‚%púFkõDÞ/­UšáUúÐÔ�W]XÚ äPwåb¾Ž¦^½â`Œç³›š–t¾6�s‹¢-¯)Pîa›¶¡ukßy±ê\”¤]ÆsýÎ*†e—ü”³þ1Éq¨Ÿìˆ#~c’¤fw‡ð°lJŸ¸¡Ø…¡uñ¥¤§"%ó‚S1ç鲟„¨�	(›HIäd̾@Ð ±“SACô: À.`í=�@Ñ(–adŽ1°ø2$­Ê»cÿÕ=Éâvø’l
¤É
-«¥“0<d›‰fD¶Ûò‘=È‚Ã?v6™¤‡ø!ÙØÀÊ
-pâ—Æß΀�C�]QgR:""NÀvÞúÂÒÈÑ“î.ÁÔ3AdÂD�höŸÃQ£å…
-×¼
-HÈYgGÆǜ˩L¡…žhUÂlD1á«°àìó÷·TáÇBÚ5Ýê(܆MÂõ13«KªÄÙ~ÿIh�ø$óˆ?Í—'ÔÐ÷­z©EÀuØ9¨¼ÃŽ�Á_€×€Ñ²¸‹ßzŸ‘ƒHb…„œÈÞŠïOáJÒ¨þ®ã•5º¡´cëp
k0M,Úglõ{ùE*ÊôY
-,[Vm@y¼Í�]â¢×=ñ.
ýbºšŠ[V’tþ‚ê/\ŠãÀ«”|a!(wI˜\�…ºÿ«dê\‘‘÷¯Sâš)ÇòqäAô\ľ‡™qRâSÆÃ]Y¼l¬¯æœ1ŒS›Ã2îÓ¨~…7�÷;•ÕÛ 
-ÜôvöÕ-?ºdz–�Z¾ƒŠgèX3»/è`¬�Ü€4q¹­jH¾úX{ã÷4wšvÙHì–VÐõ
o§‘{ƒ�²Ÿ¡+–ÔÊ°NN)𰯺pc7±¯z¡¨…F}ÝCê«É¥ù¦�1³÷âhùµÀûUèh‹
¸ž&˜Þ˜âL¯,8¾ÛW_¼ÃÁŒ~èÂ"‹¡	>Å^v"@=òšõq#Ò�Íobñnî+^F¥-Ï©¢› è!^üÿX;DÔ9Aú?,.àó?üÑÀ�;ü…iiz³j€gë-­Äû›õêuê¾=Ûà/›Á%Âýóõ¹>¶]¥Lu]XO£oþ—Š¡Ñ¦BÅ™’±™²
+1182 0 obj <<
+/Length 4254      
+/Filter /FlateDecode
+>>
+stream
+xÚ­[Ýsã¶÷_¡·ê:C|ÀÝÓõ¾êLsIv’<ÐmqN"]‘ŠãÎôï.
+?Çß®>¾¥K�“~z÷þݧwß¼{ñÛõ÷ï®ã^Æûe¹À�üçâ—ßòÙ
+¶ýýEž	kÔì
>òŒYËgÛ©D¦¤¡esñùâŸqÂQ¯ûi’,ϸ(x‚�’¥¨lV.ÿ÷
+÷ðÝ{ÎfŒeV)ŽCs˜ÕdZæ&rYãò<Ÿ/ۦߵ›Ž8ñ¹/ûj[5=}¾­~ÍsÞÔ}Ý6ÔR6+zù¹+ï*¿–QK‰<ËØ.u½®"Aà ÛWZÃ`I8žM+€ï4®ˆ…�¯ªå¦Ü½`f^
õBû½`C»¡!ËuÙ4ÕÆw÷-µÞTôÜwÕŠzn©¥{ì`j+WÛº©»~Wöí®£þ0Ãt!œš¶9[y’§g‹È} ¼½¯`âa¡çí->�û‘khÊmEM]µû½Ú¡tf¸Gþu¾o²(þlØv{VPm
ßpka±ãƒ9ÈB.=ƒwÍj™8.2&´ñƒö}½©ûGšBt7~½e»Ý‚�x¢ ß±Ep›	ÉÌ”/Q˜ˆô~WW¿WÔÒ´ÍâíÇÏãîn¿é½˜Þ¶^&ýOˆ‹ð6æ".2ÉY&½Š¼nŒ`*3@°ßcÝT}‚^
ãc±�çÁ£´á‡™×5–ôyýæ'úîÚå—ª§÷
ˆWÕÔÍ�)}3É4t÷Õ²F
„ÃL(‘,À:¨@òý¡ñÒfynĬà*“ÆÏ1_vhLÚx-⌋ñ”Î2M¥JÁ![͆•‘Âûv—b*œLnƒ)p*ò|hø­aâ$¤»­At¿âŒgX •ÎXQè)ÊÕjw‚‚ù]\ÂÆ…˜?¬ëåš”GB¿Êå�ò,Kä•1Îœq’濯~ú]RK»‹-½9œ2u``$W'´
ÌãZžd,çè‡í1phBʯflœq1žò˜± ™aàã°§+2›ËÀY°»nÈÄ‹K‘ƒ³eàÍö×ÄT&3
+ìúhÔ¯¹ÊKPà]Ý}�wFvz¼¯è¹÷†ÍcdGOoÎÊÌêÍjI6|åÏs8«W$œiQA`Á5ÕÝ‹ós
+§rnI’§ƒ–r¹¬î{òvÊ)ö–Í£o¸¥§#_Èþ¥£qD¤›g ©B
*À¨–Ï[ê'ƒF¿¢UF“’z‡½z=ñÃ2 
‚qôgð’#þH›
i”>)­L˜Œ
ÂT�‡ãÿZa
.Æ3Ë*“Œ€5ÃÂOɪÌrV¨3²ªAgý�—/S.ʳ‘† Ž+�²[bÞc»Ѳ6H4µÍæ‘Þ�ÅǬµ:Bó³
+%#ãSÓ€nZÁ‚ð
ÀHÝ�AÂ#ÀJ•>·ÎDÃ˶ü£Þî·
¿,÷;ÄXŒ1a A2—ÅÉà¹X¢§ó°“EGîóòpŒUb:A#ÂN–;ØNØÊ8úú•s™`ø+@ü`Ɉª“FTeVëb6åftsƒ?kZOÚM5P40*!� _F³ÓÈ™å@˜ÂCUøzf\Œ§L@ ïŒóaå' çÂì ´™¨
+Z™£›f'
‹7`e´\h}7hD]˜§Èå¾
+Ù”Çú–
+šB„¾A¨‹"~³­Œúzôf\Œ§L¡ožÒ²aegxWi$bÀÅø]T—¹ñìi½ãJ+F
gÏ-;£F!pÿf<ˆ3žá�� sì�iÅÐy¦€‚oGd˜ñ‘¢#�vcLä)ŀЫˆÐsdÜ
+LDÈÜ>é¦Ázh&˜»]»¿O;|«clý4øh=ÿØöž;Îi:.m}Ëý¦ìÁ(o;bâýÏûæÇÏÔë)Âè
+Ü$:þÜnJ
+c�˜I€Û«˜¯æQ˜p1žñ˜Eü†oqÔI0á‚ß`¨œÍ�fþ®$�{”}	Ííi™Àì�ÅôÍ7Ûoœñ̆ÑlÛ¼°ÏØ1�¡d˜ 9å
¸É${B	€dEû
7f<³aøÜhðˆ“
ŸR
¸OÅLG[æÄ™MdAKÏê�j¹wN>FU'ø¢p7ð^ô
²À_�•ñ¢ô¹ªNÕ~en2‡†¤¾ÝÝŒ^>¥ªÞãñÄ‘(ÚÆQ¸Õ_>U[òšÏ?RK‹ùÛšj}3¡:�+Y:ûÛQ| TfJLh?ª3ÇQgH†#ÉášëæhUÀíŠqö\ŽÅñçÖ?š×ùuŠß‰;"
+G%fi±ëåK6J36¿jhHï2Ø·,»ê’ðsœ³Üt-�{X»RŒ‘§À“²+”yÖ-!£/_ÃÀM„ØÇ¢šærŠ6Fç�±“œßìý˪­\<‡bç›Ö¥+ÿÃ[™yŽaÏ$F*P�‘’4
+ð^:ˆó}×í¤K⥛Êé&6iÝjÁëv¿YQ#Z<zKyt�]0~Ñ:©B…Hß""«‡ÚhUO|ûÐÐKÜ`};¡/<uk¢1^ˆÍ°ü@e"ÝÆÛ.¾‚¶cÖK
+—ØèÒÒη=¬ýͬÁ4åÁ>cùß�QÊ-ÆF­êÎS<^e-ñƒ`èe$ \/ 'ƪ)ÔÂ1‹¤Šg¤v
+Lò�$UÄ„Qþa
 endobj
-1126 0 obj <<
+1181 0 obj <<
 /Type /Page
-/Contents 1127 0 R
-/Resources 1125 0 R
+/Contents 1182 0 R
+/Resources 1180 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1093 0 R
-/Annots [ 1129 0 R 1130 0 R ]
+/Parent 1148 0 R
+/Annots [ 1184 0 R 1185 0 R ]
 >> endobj
-1129 0 obj <<
+1184 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [55.6967 576.4843 256.3816 588.5439]
+/Rect [55.6967 404.4849 256.3816 416.5446]
 /Subtype /Link
 /A << /S /GoTo /D (rndc) >>
 >> endobj
-1130 0 obj <<
+1185 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [268.5158 576.4843 332.4306 588.5439]
+/Rect [268.5158 404.4849 332.4306 416.5446]
 /Subtype /Link
 /A << /S /GoTo /D (admin_tools) >>
 >> endobj
-1128 0 obj <<
-/D [1126 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-294 0 obj <<
-/D [1126 0 R /XYZ 56.6929 311.2132 null]
->> endobj
-1131 0 obj <<
-/D [1126 0 R /XYZ 56.6929 286.8682 null]
+1183 0 obj <<
+/D [1181 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-298 0 obj <<
-/D [1126 0 R /XYZ 56.6929 252.8569 null]
+290 0 obj <<
+/D [1181 0 R /XYZ 56.6929 724.3071 null]
 >> endobj
-1132 0 obj <<
-/D [1126 0 R /XYZ 56.6929 223.8335 null]
+1031 0 obj <<
+/D [1181 0 R /XYZ 56.6929 689.0661 null]
 >> endobj
-302 0 obj <<
-/D [1126 0 R /XYZ 56.6929 155.208 null]
+294 0 obj <<
+/D [1181 0 R /XYZ 56.6929 117.0915 null]
 >> endobj
-1133 0 obj <<
-/D [1126 0 R /XYZ 56.6929 127.8981 null]
+1186 0 obj <<
+/D [1181 0 R /XYZ 56.6929 87.6248 null]
 >> endobj
-1125 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R /F48 885 0 R /F14 685 0 R >>
+1180 0 obj <<
+/Font << /F37 791 0 R /F41 925 0 R /F21 702 0 R /F23 726 0 R /F48 940 0 R /F14 729 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1137 0 obj <<
-/Length 2663      
-/Filter /FlateDecode
->>
-stream
-xÚ¥]sÜ6îÝ¿b噈å‡(Š—§4urî]“«ãÎ=¤™Œ¼K{5ÕJÛ•6;¾öþ{A‚ÔJ+ú£ãñ  
-É`=÷Xðîòß½¿zóÓOo®Î¿\ÿxvq=è2Ö—QaùýìóºX�Ú?žQ"t!P´æ‹ÍY&‘™
SŸ}:ûy`8šuKcö“¢ ²à*b@ÎŒ-%ŸXPj’.œ­Ò€RšüfîQ½O}Ù›�izþ`~¥”7U_µ
bÊf…À/]yg¬`31:-ºHyFtÆ2·Ëõ:±§$ϸbKcwŸ3©¬
Mw쑬P0Óá°ÄŸn]îÎY‘˜•›%Žý*§¦nÛûÎ p¨ú5Bן.ß#ô+•´3æô¬3ªHÎAH%2’kª­Õqrw·@àjtL}:^€Ç4VxÎ×*þÉ,ÑúV"8å™4Rða=‘fæ*ÕS2̸YÀvë×ÞnËv³±>
R-R¡()—‹tp>X½\—Mcjt›lÊ2§�«…âœ(!Õ6èÓñ‚¹>s¾›bòà$›É£Á<tÌ~fÕ�ê))fÜ‚U	Ž1JT.¬áÑ‚«Gb‡D1Z<;@“g,;œfɲlh—ËýÁÒϹsåT&}»ELm¾¹³³ô·"àÔ66ïö»ÒÛ�S{‚Ö³¯š®Zy\ÑIPI$WA©o•9Ä2äVEå©V�º¹–É¿Ì}‡;¬Lêý1Wü-›ú#f›Æ„•AßU�K§œÉ×�Y¼Cîhr
-NÕ�¬æ,%Qr¨'x¡°+xìÁëV<Ū8aÅya–[Z‘ý]¹¸Ìd&ÿ.3QD%ƒ[3ÊR''ì€*“'ü$ãò™Ð?Ü8É>
%Ü BÓH{ŒÍæœ&×çšBÞ€ax¼¥3HÝÚ:—"ñ/Kœðn„t"¹¹Gt¹ÝB‘†ÙÐþr	¤¦j³ß Q³ßܸ®¢–Ç]
ÏWǶrùæ·ˆO§yÅ?¯–… €“C»¨²ÃˆÿÊÞV,1äŽDŒ­¡>f‚ŸzhZЈµƒ·K¨
ÁnÜÍd­î±|¸¡ ñ™þ4e	–“
-fxã®sö┦cŽó”%ÀÁ¤fÅqc¼E]ŠVÄJr”¶¬eñd5›tÜDëOÂÏû:t6~)_ÎW9È#\ΟîÐoq[ÛB÷NJ±²¿¾à,;“æÜ‹«@ˆ:’¡î5ˆÀ¥à½¯T¦†Ö�ö­¡º½»ó=k½ß•ðúßEë¤40É�ãNßPÒN"ó3RƒÑà+Vl#^üÙk‰n«Ú“oK{¹[ȱ°k¹ Ú¶é&kýæPat�:†¸µðŸø³oêjS¹“ð´¡/±Àóïªÿ™7ÝxeUÎïÚÝw`Ï1üõ¶\V5\‡±üVõ+³ÛÅäú3èW×G=^�å`QCuÆc°é`¨%!¯Ö#Á®íÔl‡r×Þvoa¥	(»·O7'Åóm;Y¶27{ÏÈKåûhË	é=µ«8¶øt»É‰m!núÔÞ±^Ý{ã$èÖ´¯£gÏ眦†{	§¾
-1ñ—S�BÿÿŒ�¦z‡ÑóÂq»¯'‡õà<!ä…Ò[¸tšhxXOƒYN÷OT›}F|I›\<Þ&§B…Ë'H½¤¸Ð,Ò*jԤ÷—ÅbÇ\؇�mËYè[¹«ŒõI;°u‰¥”vÈm�yÑ°ƒ.üÜÒâZ”BªÌV	RÙ·rkúIM 6	¥cHúsõ ŒSDªâ$_o×»߸öìÚezwØ3h÷ývßãÜÆôëvÕ½Â7'¾)ýÌ ‘k3¸#ã¼fG.Ÿx’ƒ}�ೋ,AC#AÐá
ÍB»ÏÕ	Â'4;vNÜÕ¿@}K(b,M¨•ó’‘G	<‹`ÒÁBÒW&¶
-0µYz¿]·ìá·{_H,k°¦ñ¬P­;ëÉ¡Ö8ÃfZVš¨lÚ°úظæJ–%mS-ƒb#d~ÄËÔGYé{
-СBxñGýã<d |Qðø×AsRp­‚PVq¡N%¾þÏEÿ(^Øendstream
+1190 0 obj <<
+/Length 2372      
+/Filter /FlateDecode
+>>
+stream
+xÚµËrã6òî¯ÐQ®
+<,Ÿ&ÛëìÆÙxœÓdjŠ&a‹>‘²W»É¿§�)R¤,ﺶt`h4ºýB‹-(üØBKBE.TI™\¤å]<ÁÚõó8A‡±¾»?ûöJ¨ELâˆG‹ûÇ
-M¨ÖlqŸ}^~üÛ‡Þ_Þ�\ÒeDÎÑåw7·ßãLŒŸ�?Ý^Ý\ÿr÷á\…Ëû›ŸnqúîòêòîòöãåyÀ´d°Ÿ{
+G6\Ýüã¡ë»?þøáîüËýg—÷½,CyV�ßÏ>¡‹ÄþáŒk¹x�
%,Žù¢<¥ 2¢›)Î>�ýܬº­sú“B©¹šQ gÆH,%iPÆ$\8
Z¡#P
+Îq³æ_I¹.Ì70âùrD÷ú±Dà’ŠWzg±óëMþˆ8øÍìÎÙ²éxIüÞÄÛ”‹Žo´“>y(¼÷ÕU±CèÁQU
+gRLöõ„ÝáÉC)’g~.™‘	R
‹ë„zÎÍË\D€úQQy($-ËåßÍ®Á2x{Œ
{Çöˆ‘ÃU?–3ü‚¼
Š:åN)"B®Ni<éDã
RG•ð`ðqgÄ
+·Önꢙ+ƒ4x¿d»qÚÁH!>Èq;æÐ4$“j*A4„”SÝáÃ
3®4¡ûF‡– Z�mH~êÐÖ).&ÔöaÒ²PnŸA|UÒ%,Ÿ=“ö ~AÀ¡–8åÇ¢‚<´?ØèH
œÃ3(Š\ˆ�t¾åÆI¬µž…=Å`HÒ)kÌÔaUG�æjñl΋¼›¢ßX“fàM
WËߪú¥B0ið‹
+´k®„á‘«ÝNŽï‹Œ+Y]&¹ßïëE€¶UþûÖ¸ÂF¦ª6ÜaÉÍ£ñ
Œ±¥sM¾¼iq]€‡Žžum¬ÒÁããèóš£Â%
+I»²È²3^J	e|îédãFˆ4éC–@ cÓ=›	:ävÆŸŠ³õ0jÁ¾ü©œX0áÞÜ©NENýX,ŒB\–!/�Ç/“6]ùà¢G6“cK‘#Ëðr¬h½Þàvü2
<;êÒ¿’ô¡À°¾Jž
®=Sá\/À^í*I;�Ö€c±§ìEÕª·²Xí«ønìË¡™‹QÒ/Ÿtk[(+ѹõþ½pèܸ(NH™-!ùû}Û†g\;„Æjpðq׆ÊG²þ%j„=VÝöƒO„ñVCp1ת€G£ëV48×m0PºäíîÛd
+›ú
+ÄíÔ®
+UÕòî*óû¶ëum›"Ó·\‡àV”�omU&iPfrF"xLiNU¬¦$%Q²¯%x¡°RRkqŠ”> Åy8C,²¸ýÃéÍ|q%&ÿ[bBÏrY3êËRï'ä€*”ô$ãGéu‘Ð?ÜÉ6èJÈ B´Š†C°µqSˆð ¬`³ta£Y¹f�}£Â-x3B<á»Ó×k(Ò0ZÀ´Oîbi›Då¶D¤j[>¸
+ÉÔ`Yû®Hì¼Ê3`߶nÀî
y"3ÊŽ¡>f‚Zh éŒ¶#Jtµ¡íAn>µ"ÈcQŸ¡°wq²‹H³p•Ë{CVG0Rœ†,a[‚1Óûƒ1‹º
+êUÛž
+û1ú†Á`ð¶

¿ïài')"=æ…G_'í
+wíÃùs¡¶h $48ÚÓê<ÖÂàg[y™»;ð¸¡/s©ßÓoò›	9n¸3˜•ËŸÚìPåþê{Ó»¹ÈÐíj3³ÙÌñõG'_Qìå¸òÁæ1¶kw{E¥¶÷œ&ÅHIpj=VÛK²©zCèN¯a§é¦ìÙ>ÐŒdÉ«Çz´-3[OÈså;¨Ëê®?O‡"5>>n$è<¦
lF
 endobj
-1136 0 obj <<
+1189 0 obj <<
 /Type /Page
-/Contents 1137 0 R
-/Resources 1135 0 R
+/Contents 1190 0 R
+/Resources 1188 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1145 0 R
-/Annots [ 1140 0 R 1141 0 R 1142 0 R ]
+/Parent 1199 0 R
+/Annots [ 1195 0 R 1196 0 R 1197 0 R ]
 >> endobj
-1140 0 obj <<
+1195 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [406.6264 730.8852 456.8481 742.9449]
+/Rect [406.6264 524.1437 456.8481 536.2033]
 /Subtype /Link
 /A << /S /GoTo /D (tsig) >>
 >> endobj
-1141 0 obj <<
+1196 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [140.5805 719.5976 196.7992 730.9897]
+/Rect [140.5805 512.856 196.7992 524.2481]
 /Subtype /Link
 /A << /S /GoTo /D (controls_statement_definition_and_usage) >>
 >> endobj
-1142 0 obj <<
+1197 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [103.6195 677.087 159.8382 689.1466]
+/Rect [103.6195 470.0794 159.8382 482.1391]
 /Subtype /Link
 /A << /S /GoTo /D (controls_statement_definition_and_usage) >>
 >> endobj
-1138 0 obj <<
-/D [1136 0 R /XYZ 85.0394 794.5015 null]
+1191 0 obj <<
+/D [1189 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-306 0 obj <<
-/D [1136 0 R /XYZ 85.0394 769.5949 null]
+298 0 obj <<
+/D [1189 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1139 0 obj <<
-/D [1136 0 R /XYZ 85.0394 749.4437 null]
+1192 0 obj <<
+/D [1189 0 R /XYZ 85.0394 749.3189 null]
 >> endobj
-310 0 obj <<
-/D [1136 0 R /XYZ 85.0394 543.6821 null]
+302 0 obj <<
+/D [1189 0 R /XYZ 85.0394 679.8163 null]
 >> endobj
-1143 0 obj <<
-/D [1136 0 R /XYZ 85.0394 516.3776 null]
+1193 0 obj <<
+/D [1189 0 R /XYZ 85.0394 652.1211 null]
 >> endobj
-314 0 obj <<
-/D [1136 0 R /XYZ 85.0394 259.6272 null]
+306 0 obj <<
+/D [1189 0 R /XYZ 85.0394 573.4726 null]
 >> endobj
-1144 0 obj <<
-/D [1136 0 R /XYZ 85.0394 229.5133 null]
+1194 0 obj <<
+/D [1189 0 R /XYZ 85.0394 542.9681 null]
 >> endobj
-1135 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F53 962 0 R /F39 863 0 R >>
+310 0 obj <<
+/D [1189 0 R /XYZ 85.0394 335.1831 null]
+>> endobj
+1198 0 obj <<
+/D [1189 0 R /XYZ 85.0394 307.4879 null]
+>> endobj
+1188 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R /F53 1017 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1148 0 obj <<
-/Length 4006      
-/Filter /FlateDecode
->>
-stream
-xÚ­Û’ã:ñ}¾bŠ2U£«/ìÓr˜=ì�³À2<PŠò$žÄlb‡ØÞì@ñït«[²�Qvfa+–[r«Õê»y-à'¯mš¤…*®³Â$VH{½Ú_‰ë
ô}%yÌÒZNGýêîêouv]$EªÒ뻇	®<y.¯ïÖ]¤‰Jn
-Ö.ÊÝ!z±k7›Ð½¯º®ÜTüéñFæ‹jSºç:꛾üLíêè:Û#R7ôì·¡_µÍOB¨Íp,ûºå^„ì*joZþ¢�}iëê¡v=î°c)eRX«ÜÚVÛ²iª]÷Šv­=ÒQà–ܬ™j‚2éµ~àp.lü¤”Á‰@2‹	ceª€³9l’›v¹¡13æ{ºhˆCDDh½Ø>•Sv¨V5®¾Z'ŒKNp-ef’Ôj{½Ô&)t®ƒ.€(H�p!ÄâÎSÍl —?l�eWEÞ)›dFäÙ›
-ßQ²$¹—uÝ­jÇÒH»x×B”ˆÙÒÉI�Ž�)ÃMÔ°»‰ÓùbWï란D'À˜Ïí*Ø{\
‡·�§zÇ°{þ¨\­ªC_­©ÿþñl‚q'
-&§Yÿ¢ezÇ­Â7Þ*lz“†›4ÉužÎ902Í>ˆ¦íç6nÔi4#Í#26	71wÛ*Æ't»Âo]3€Ø<e“’I–zO27E:ŒyÍŽàÎM#pb$
-š!FpÅÙ‚ÄåAJ¡^ȹùŠ€MÚº§h!'J‘lñ¼x@˜[ù�©ÏQ�!0ø”¿Ü öÍIŽ�JÄòG
f§
-¯>¶ x	>ª.|ô��ÃþÞe2ÐvŽž~B\hÒ;GcÌ\ºÈý”]ý¯˜C¿ŸÚ =!µœµ”º®]Õw"}§}ë$2J9á-Ælˆìa!+ÎÂÒ}!Î¢²–£HôÙ.í€ÖšsdË&a¥£—ƒîûŠ±¤ÞR8põyUUëîìúY×+^BÎ$(ÐÙâ}K#¼ÀöÔ£�»ÑYàõ2jÝs&Í1òëþrÍäsÝõLï¤Z0®g¨»ì>V`eë^ûbüœ'xYòÔžK
-÷Ür/i4†¦¯ùË®Ýso;ôËöayO\À¾Â«îöôJ”í�»pdüÇ›P¢)ì.Íèi!a¦1ç%£`Ù}%ñs½öÞ€‘q•“êê¬tp_mËOu¨_*$x9Í��A;/YNmiÔRÞR,Mã®[�áˆdi’AŽõ¬)•…ñƒBttn’µÍô‹´Ù\êº_F¡¥ÌRØ“ÏײìT ïù;çŸÁÿí8¤tRàÙËl?jdúŠÑÕÏ4š|Óô ýÀ–û×19ë¦_RÆŠã«îu̯Ҹ±„5»Œ’ûŸ×ñ
-½†(H+ùe'ióPúà"mÄe€c)ä…:“šÔ™Ô¼ô�
-œôÂܽ«¹C#ÙôG‹w)†=רÇhÎNò÷Ši.0ƒ¹t•X
-ŒufÖ
Â�˜Á³�âK$ÙDJãåvV‡•¤¹ÉŸÃâÆÕ1ºY 9…²/%÷
-Lާخ{˜—bzè—ø,äK‘ìÚU¹‹eÑ
-D0ê«ðÈÿ��âQ߈ý�ð˜o´.û�èIcxðh6”¬.Æ#&
å[‡*{
IK•j¬o»Œ�R'�µ>sæ–¹Â!ýy‹œYz×ò
xé†Ã¡=r­A.ȹ†�±@ŒG`”�ápç0]5DëÅo¨Æ~²
îÊcèö%ÿž‡rñæ
-›Î®`\`qŠ·ƒ‚ßÇ‚�ƒg¢x|ÕÑ×…#ÈH©8Eä9ßòéMg¥žè×QoN)¹Þƒ98l¦-^X÷QR{;Žy#Í+í’@•]œÚãGÏ]ý1"!+~a ðóŽÐãmðxíÑ|{5V쨌fÃþº
-Ë#Áø‹ñ7\í�žT�Â>º…d½P›i�n¬áÐávj’"ËõyÁçXÖ›-ή
-’x¢ ëI�@`Œè¶	Û:Ú 5tŒÿIèš'2Ͼ2¸r•½øq´=0…×DUL6>qF(?wUÙqÓe¸ÚgÉ
-MÄ
-Ëé×xÃ2žI•E‹¶˜DNÅYñ/
ÔÓ;[TØbìíª£;ý‚ø9y~ݺ˜_·.&÷?1HÐ9,’ÂÉbžMïN
9I†uf ÈGçŠnú(0í|ÚšûÚd®yØv¸s<YÀó2õwÇ[9•#ááotðàà®EÁgz_Á^¿¢´.PP…âüŒ
-g›7ã<ô˜Ü€_FO$`’Kÿ7Ð6Á?	Dþ ÂÍóÿû¿ã5L–€áQñ¿(Œ¥Á&z¢�x�?¡Üÿiá)éÿ—±hendstream
+1202 0 obj <<
+/Length 3489      
+/Filter /FlateDecode
+>>
+stream
+xÚ­Z_“ã¶
ßO±“'ïÌYÿJê=]’½tÓæ’^6Óé$™ŒlË»êYÒÖ’ooÛéw/@€”ä¥ïÜöÆ"A
+@ø�²¸Lá'.�Ml!‹Ë¬Ð‰I…¹\7éåŒ}{!xÎÒOZNg}u{ñåk•]Ia¥½¼ÝNxåIšçâòvóËÂ&2¹éâëÞ¼¾ùöç·¯®2½¸½ùáÍÕRštñúæÏ×Ôúöí«ï¿õöj)r#_ÿñÕ�·×oiÈ2�¯nÞ|C”‚'˜¾½~}ýöúÍ××W¿Ý~wq}t™ê+R…Šüãâ—ßÒË
¨ýÝEš¨"7—�ÐIQò²¹ÐF%F+å)»‹Ÿ.þNFÝ«Qû‰4‘Êʈ
¥¸")Œ‘3š"±Jª`A‘‚UÒ4]캻»º½#-Ê¡jªv î7Õ¯i*Ûz¨»–(e»¡ÆÏ}yW¡-`E5Ù²ô†“ãò°Ôí½Ÿ$&“dš¤*30çx	ž3S9hYž×�Â)•-Ö]‹ÒÝöW"_T=RóEIƒ�õ¦¢Öûr_WÃuº-Í
+J;âê×SgÛí©1ÜW4·-fÕWû÷Õý�'“‹›¡�h§ÀÖ*‹½¾/Û¶ÚEÔ[j‘%&ËÕå2l¼ðp¿/{XR*°wßwëôî±/Ýax84ÖTÃ}·é_`O£àMÉ#A#|…¶¨}Ò×h
+ìí ·ã)�õ•
+09¤ …@Ã&tž™‰è¯øìÜáÀV¸ÚÕ½	�.v`+ð…Ý­½o�d�”O¸/y�UÌfÆãZî{çÁ&ÍH3a¼fÂ.rÔLÉE=ÐÈ£ãsi�@fÑwNŽ	%Ï$z/¦í3r[*U$µÁ�~�™%ÃÁø
+›0©j‡òµ«½ìöüJÝÒ“ó¨Šl*Œ†M…ö]Çot³7u8\‘}öQŽƒ&ïYR ð±ÔD	bR·ÞE•_¥Ô‘P!¬ •ûýZÆvÔËES#êa’JÎ4ýCµ®Q{Î0Gn´™N¬Á¸ª
+¨}ùÔ
‚¡Ë«Ä{Ä"8É
š
+Žú†šbƒ#ω³
+‡H¿nê�ˆ$'ÐØÎD�¢âœP±ŸN°7÷8h+~©\¯«‡ÁA2_=-0îPMMFNÀ‘º�ÂÆ<)„)øDÔí¶‹Åš<ÉEbMjÄro­³$SFÌ]ÃÁ?%²Ñß°ã-<ƒ'c§Œ!7a’\ûœ†•Á&v’Ó¤(”
!²j+õ¯<Ô
¯
+Ð]’Fâ$F˜ü]¡PÐ^"…<­˜Æ1¤vDtþýÙƒ «dê6q(/@�¡‹€Îy
y˜
+’˜ÈT&ya—�~&[a‹Ë7há¶Àtú,[¼vQÈÕïc€©ÀF*í4Ö÷]G§Nòq’‹wUõàסµyB·ÛPc¢’·A*l¨Y˜áöôøè4À(Áý|¾
¦H²,@QÜX�ñM—’ùâïùakUm»P®B¿fº+´àIþ«"`§m–†+� 
 úçò@P™÷AÏ<ì�K¬@ºÈJŠ†,²ŽŒ­I‰ ösf(Ôœ™Ïð.Ø~~^q¡4æçš
 8…ÒâH¡ô´BPNÈ3-7×̤\œ{Îê!‹b§Ÿv¨
+0sÈèi.AëÆò9¤}kÂé	e5ð¬=Lò×å’�oŸG\d¹Ø-ÆRˆoÍÒĤG †o¹�=
+ˆÒ†�–/º°µáúØpˆD ;&9^UÌÅúHáÈÕ‡uUmú£ëvS¯Y!˜„–Á{Y™-Þt4Ãg
+
+̉ˆµ·üƹ|Aƒ*ŒEN( #Ëì§Ñ�0Ai‡(ö*›•�Ã~èÐx!”J´qŠ¯
|½…„°�ІX
+íISÓkè K¿q:Ö©J”ÍåÜF‘#%�ón·#w‘|×+±vXïëU ¯º÷üWÖÒ•ðh«Gj€¢‚ØJ8ñw‡Ã`aØ©äôs
+vk^)úåDa%“…Kå�ãVYH13øŠmG+4ÝtÝM9”\k
+ü“Ål7·5Ú'}Á¯"´ú‚HcÀÀž¢í¶dÚ¼Œ~?Ú×í°¤jç=U}ô#Í›ªs—QqÏùw2Eš<\{ðõl$a@Z)ĉ+&9¹b’ók$0L’Óë#Ép2
+kî²Úc¯0¹¿C8_Pø;v! ¹(Éï3S|µŒ@x"BÉ_–
IJ,Ç÷xc$†âÖ•Æ'Ëýн.ô'
&
 endobj
-1147 0 obj <<
+1201 0 obj <<
 /Type /Page
-/Contents 1148 0 R
-/Resources 1146 0 R
+/Contents 1202 0 R
+/Resources 1200 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1145 0 R
+/Parent 1199 0 R
 >> endobj
-1149 0 obj <<
-/D [1147 0 R /XYZ 56.6929 794.5015 null]
+1203 0 obj <<
+/D [1201 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+314 0 obj <<
+/D [1201 0 R /XYZ 56.6929 769.5949 null]
+>> endobj
+1204 0 obj <<
+/D [1201 0 R /XYZ 56.6929 749.2381 null]
 >> endobj
 318 0 obj <<
-/D [1147 0 R /XYZ 56.6929 728.4063 null]
+/D [1201 0 R /XYZ 56.6929 540.3599 null]
 >> endobj
-1150 0 obj <<
-/D [1147 0 R /XYZ 56.6929 705.2957 null]
+1205 0 obj <<
+/D [1201 0 R /XYZ 56.6929 517.4049 null]
 >> endobj
-1146 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F47 879 0 R >>
+1200 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R /F39 885 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1153 0 obj <<
-/Length 2604      
-/Filter /FlateDecode
->>
-stream
-xÚÅ]sÛ6òÝ¿B“—Ð3B
-òûÅ/¿…‹Äþþ"d2Sñb!ãY&Û‹(–,Ž¤t�úâç‹Œ'³f©O±T,V"õ(PHŸãŒ%¦P�÷
e<èu÷Uw8ƒ"o,p÷øX¨ÿtÓW_-~©vëuÕ¬é³jVm·Í‡ªm}¿Ñ–H5ØÿžfªÆC!¶m©Aý‘ÁÍŠ0†SæÀ¯{T:H¾äœeq,Œëº}Èk@V	ÑÅaÔú«¶P³;ü¯»K®�FXÀ6FZ˜ú·6síÜ4ÆÝB™r
-xÈ)Mì«ú’5}<hšÎ‹
´„¢ðÌêf½&GSäÐ#Y¯A}Y®€¡Ç°Õ�`ý�wƒá¿P]@
ÌÎ'fç\0!e„‘^“ouiѦÞ!ÁcãŒ[,§p$»‡�iÛq™MV¦!S2v+—>â<f\„±Eù5eny^µuÝî�£™\9ý=¶}5�ïªôÔ
|�€‘¤ŒƒÖ2éVv—*Ø5
êä\K!“‘’NÅDº¦,ðXgÁÐå…öðE,
—°ü3Ü:±¦…U£iaìL«Ñ´
-S@õ�º¨VúÈ'0ðxQÐ÷è 0¬uÕp¸äœ£?#l…�ýG¾}¬õ;Ï�Ã
90JRÃhAÜ\.“бP_Ì>_¬âÌŒ¬B²ŒŸZwrÒ«UÛ¾z?�CÜFˬÁ³RàPúÒKùÏ÷—
Ê2daÈ•Á� 
-,B	Ö&ÖÅ³Ô GåÓøºù·’áPÚ™Ž°kp2‚äÍ�CµÕv´±ƒ1ÂÁŠÊâ£CžmÏÍ¡Ãp“&
yÍ:7ÿåq'àÊ»i3%Ç!U4#SFð«|àèW8câîùÉ!ê.uÁ¨<@D¯
-_Ð’Œs9tg>$½ë513r8Ï°fîÈ´töF°S<@!x‘éq+Œï§HwÛªÑäÐûñ˜L¢
-�¡ mƒ1’.ûã´	O0WBÑ@#
-:8gAäÅD˜þëv½Ö%ó™0Féâø¯s¿ÍÓM&áÅ	€
„‚Z1•ÄÑÜ(¹‡�JÌÄ1Óz`Üè9¤Î$³h6è¼±im7Pº2UVœ‚ƒíòÚTŽ1¦q��Î
-ÎõUSx•R’EýFFòºo‰®QcO[’Í
-TâéÌ:ÐY·ÝÁÃO’°4‘.“Ú*nE	HŠ“RÃÄ�ßwºt‰ÊSÜyDâ:�ƒq7ó…!ÿÇi{€h‘u<
-ûßÈr$¸œP¤Œ8oÚ8Kp¹Ã"ñPxÊÁb9Þ}Ž¶Äs= ÓÔ6
+1208 0 obj <<
+/Length 3336      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥ZYoãF~÷¯0ò22`1}‘lÎ<Mf=ÉÉd×ñ>%A@K”DD"’²â]ä¿oUW5/·íÃ`_ì®ó«ª¦ä¥€?yiãHèÌ\¦™‰b!ãËÕáB\naîëÉk–~Ñr¼ê«»‹/?êô2‹²D%—w›Ñ^6ÖÊË»õO‹ß¼ÿçÝÍíÕRÅb‘DWË8‹¯>}þ�dôøðÃç�Ÿ¾þ÷íû«Ô,î>ýð™†oo>ÞÜÞ|þpsµ”6–ð¾âžyáã§ïn¨õõíûï¿{õËÝ·7w=/c~¥ÐÈÈï?ý".×Àö·"Ò™�/ÏБÌ2uy¸0±Žb£µÙ_üxñ¯~ÃѬ{5$¿XÛ(¶*
Pé�
+Êi€dLíó®\íhöÔ:1À ¯{(šGšª÷ë~¨-k>´Þ¸YÊÄF6K§bzIG*U†ùévyGîRWûGjy²Ä¢;×Ô Ûž .?ÇSψ8‘Ò©7°¹
+ÈùYÄþe€,ž-¯’Í©ZuÀöuFå[%Ÿ¿Úç@(µýX[î�@ÏG¹­jrŒuD�2ãD
+lô‚ÃÎé
+
+ˆY
1Y^(14Qo¨Ï[(I©Ä+É91ìÊ�–í¸Ê¹žùZjzrÉÆBl!þDIjfð¹>í94
+CDžU=yØv{òæÊ.NA=Žç-?é±ávË‘a_;Rº¾¦²®§€CÉœ
+‡ÍÛáz
+h Ì’kP—†Ã`ñH¯-xý˜è"À5o°œ)Æ)®�¨`¦¬;€½×ëÂU¯Š*1WCΈ#ƒ˜ðÇ�e_ßçhN6áèÍ´Ïã`”•,¶l&i0õ¹*Lý‡Ð­všˆ}µK&2O¥4q.!Ur—yÁt%σc ƒä³A
+“�ÂtQ9k‹Ž µ()¿ÖŽz¤1ðŠ†1zÏUÉ
+J8�¼Ž½€Ò}™Dòî!Ý�Úïo&)¡€û,dÚët%<úƒ¡êœIÞÔû}}F(³•ÓãXCøq‡=ô^�öv@fdäsä†�
+[A£ÍPá�o4ÕzÅ
+ˆü‘1ƒ½
¡¢Ö‘HŬ„´ãÑÀrЬDcT¼xO.‘MÇŽCšµ„Öþµ#\ÍüÝ‹µ„pvð®Îœ“Z–Ì÷uR`-¸%ð²(GÎc(b&,C½�—{dëSw<u¨y)(xù”þê¥=«rÃÕY>Ch^Q¿7�Q5'¥\\ÏjDFÿ·
‡›!xJáI(W¿ºs~eÄ™ÿ:^•†<l®ÝM‰a}±©ë/Þ…ÈP�à:æ›ú�¿“	ìü绀ÉÀÎ�Cdi&ÇùvŒ®ÝQcd6º>M¹ÌžÌ65Ï4´zFF#yõH�®<ÜÚq£G8¾vÂ14È'ÇKçt7©Ïx·œ‡'Ñ…Þ“ ë³ºGmÍds˜r|€]¥`ƒ]áÌ3©´""õ`´~@/W!ÐÒ‘”z~ï嶦²Æš�ÂYÆ…sÑÚ뇽àa´«Yõx”š×z£‚ÛÝPôn2Mlýý£K�Ÿ»¬x*†PJË¡þ¯º¥Ór@6²i_	î\bf$@±‹îFPjð–Ñhü�ÏYan
9µtpÎñŒÛ˜žPl¹Üš«0îL_
ý
êùãø�¼x@ÔÙ$žÕ¡R9� TŠÿÂ7
mŸ 0è\sX;u®(ÓNÁÀøB�5ðG¾‚smY­ÂWÍ’æ%û«„ø»Ï”ÄØÒ‘\I¤^g±0„‚v!\‡-KeY_à�vV°Ï¶nB÷ÆI¥I_ú�Æ$À�˜Â�ßOP4¹’S{¶4@¢:Å›]>ÍõÜM`Óì@ô^Ê—¿ð$㶳ö÷=¢Œ†Œó#”k¨u°ˆ	ÉAYÙ_)�^¸?{K¥É�ˆ¯®ûê©bÑ°8¼D€¥Tc¨‚ž‡h:è—rXÙË
;F uÏ#Þ
—&Kž)y
b"­ú»1âñ™šWô	`}Ä2§e"òÇé±t÷Ž-O¤�C«´Ã=Ë×�hôÚ}É{©³UHoY¹�mæûsþØÒ¨S4Œ9r^ê²)í­f)µ¦Ü‹2ewÚ¼¥«!tT
Tʽ¹y“ÐvšœDtßóM1\¯Ç¤axºÜÎêU$|7Z›¸K�@méEP5
+¾_í9}�OAÜvuó›óiGoÙ€¡s
+4rÿêçºCt²¦ûc:•õN¾Lt@”¯CUS¯¶Í†_:ºŲ̈÷%͘
+)×ÙœòþYOIÿwB)Îendstream
 endobj
-1152 0 obj <<
+1207 0 obj <<
 /Type /Page
-/Contents 1153 0 R
-/Resources 1151 0 R
+/Contents 1208 0 R
+/Resources 1206 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1145 0 R
-/Annots [ 1155 0 R ]
+/Parent 1199 0 R
+/Annots [ 1210 0 R ]
 >> endobj
-1155 0 obj <<
+1210 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [173.6261 465.0053 242.2981 474.4149]
+/Rect [173.6261 273.4719 242.2981 282.8815]
 /Subtype /Link
 /A << /S /GoTo /D (the_category_phrase) >>
 >> endobj
-1154 0 obj <<
-/D [1152 0 R /XYZ 85.0394 794.5015 null]
+1209 0 obj <<
+/D [1207 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1151 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R >>
+1206 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F41 925 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1159 0 obj <<
-/Length 2725      
+1214 0 obj <<
+/Length 2391      
 /Filter /FlateDecode
 >>
 stream
-xÚÍZKsÛF¾ëW°r1Tebç�Ác}Rl9«ÔZö:Ê!›M¹ r(¢
Há¦òß·{º
HÚk¹Ê¥ƒ€ž™žž¯ßʉ€?91¡&*™DIà!Íd¶:“;ûáLòœi;iÚŸõýÍÙß^ëh’øI¨ÂÉÍ¢Ç+öEËÉÍüW/ô•„÷òíõë«~~qÞÍÕÛëó©2Â{}õÏKzúáýÅ›7ïϧ26Ò{ù�‹w7—ïi(dß_]¿"JBÿ0}ùúòýåõËËóßn~<»¼éÎÒ?¯òûÙ¯¿‰ÉŽýã™ðu›É¼_&‰š¬Î£}hÝRò³ŸÎþÕ1ì�º¥£øIá+ª
-ï?J§Nú6#}'	Ã9½A¼eGSDZ\×YYÐ3ƒ Àì<£ÿ³š¨ žbΈÅnÚ
½’Á
V•[Ÿµ¨}Tbä'ZENŒ·Å–·$	�ý6'šƒþÏ-r*ì�Õ"ò²šè3˜[òó­%,y»Ô¡w³l˜ie°8ôÒ¼¶çÒÛÐ��<›,¯§YÁH´Š&í°É·çRJïù˜Þn†Ž¶…Ø–Vå<[l·V½s»H›œ×äåÝ;ƒðnyêºÌŠº£ÎÀ!ïÊMf+ž—ödío¾Lï»�:€û°pÚ’²é1ÐAüB
-f?2ŒZÇH	/�é¸+‚Ø챸P´µ
�a³,8ädv$@ü±°›)f§~„Àm1`_!CP
¹cãp ŠD‰ã÷ºE°KíøBn„Ôû4ËÓÛê-¦ŠœáªPx¸Ú‚続m2Wªò¬r1`eøvm÷Æ(ËÁúÃf•r¥K«¶¼{YÔiVøc
-.Y‰®È4m�h‚Ž9/ÂJœ@›vS€B¶4½ö±;¼ÓâR ½ºéÝ}Tõ iü·,ìž
ÌÒY×ïƒHGÔ¼Ã充ܚ觳l!8¬eû"�§ãj¤F‘áb•KËSj¾X¯é‚é>Í÷PœÛ"k‰.ßw9õ÷ÆVuuÖžÀ_Â>®êIqU¡/µ9‘$`‘â+å6›œÄõå~ÚÙ]×ñ5Sº©ºŽ©Ãœ•1çƒÁ#÷D*„¿FòÊWÊœJ>PvGaDa}c«2¿ïîí#üêú§ó©�²”lV5ˆôsüÜyU3[â0]Qã4]�À׊
àoi,/Ë�ͺ¢ñ5e‡Ñ¤ƒEn[�¶ZÅv7_ýd–gÔŒ÷oÓ]tê4ÿ(Ô¹žù Ú{x>mÀzRÇ’‰ðU$ÔqµËDû±	)/aåP§²£šÿwñëMZT°²Ú»Iè§�ö^ˆÕn³û£žÕ—ýŽ]2æý¯a£ÇÀFÈpˆ0ß±~ˆñ¢ø8¸$µüÖÁ
C_›äD•!Ђ�.÷öŸT2#T×oo®^ÿ2úu9+ó#Øõ„ú–±3�ˆàDR•pª$‘œT]°<‰Ý»An‹·ŸS£ôå|*8
T
-‘‰?ƒe»â œ
-*ñebøv\ôIÙRnÞš"½Í-ÏäÎln¡ª_eEK^òƒëæƲ'jKljûš©A_T�ð°Ì0]#­î}½Â‘´":ö÷Hp‡Cý�|óˆ±ùt÷™}»TP8…í‡\hX#{´=º�š$þn£ßŸäî¨JC kV«Ô}—Óý´à[t¥¥»æpU‚æ®EºÇ”Ä�Æ»½¥<ä	
-*$
µýÞw¼4Åv(anð9}O‰Ü�¡>t©5}¡×:€Ú¿y!…?,iú�””^Û¢IN_[ù9~˜†Zå95x·[Ø}õÁM˜a6jUç°mc7x—€Rásoz{~Ï¥¾ÌK¿j�ز>FãÐW¡ (ZØú¡Ü|<éõ×<�›`©A9){’|Ãy'~$ãQ€
-y!B�xôS±öW[<«'úÿ
+xÚµ]sÛ6òÝ¿BÓ—H3B€	^žÒÔιsIZŸûpÓv2´IœR¤Ž¤âª7ýïÝÅ.ø!ÓŽï27z °X,ö{�œð“3‹8Ué,I#¡©g«ýE0ÛÂÚ»É8K�´b}{{ñê*Lf©HcÏn7ZFÆÈÙíúçy,”X
+E*ƒh¶”R¤Z+·—Ð^ƒF“0_½¢÷uÞÚ†ÆmE_¦ˆ¤O„hìgN„——›
+	†j@°*^nl¹¦Ñ¡Î«ñ6âSjPc8æÓÓÉüæ]¾ÝYâf©ÂMu&ÚŸ¯=¯$yøPYå±(†*’‰HCeÆt	åI‡ò´UÓxŽNí./·�tm§6'�’B&A<ÖXGf—3Ï×zu¥Â�G x©0&IÎíÎ2ÒÐmT "…=äÜï%¸`G³X¢«ä9Ž¯DjŒ™vû¥'¸Rt.=âMÊP„”Þ¡“wÇ털¡:¥3f˜Äó]Öà 
¥Z‚4»Ê3^>ÔiæÕÁÖèqiwYK;ò– ä¥ìõqe^;¶‡#ãßïléiø³l
A°XB’yÑ�
1í-¯‚¹T@Ø4D/ÀoY•X:òY(ƒùuëWê}V {8óñ‰cŒOüfôù%Tai¼‚vMjåXœ†õXf{»õ±œÐ8¤eLʘyɇîøˆ±ÜÄ\Uÿæ'ë܉cWmUŸRʹ í„A,¢$Aõ¸¨#»_U@K¥Ð])9àŒhdMU6/¸•M€kÄ
+~Q*š�UF¡0©”,Áò8!¤·¡8BŽäªÚï]ÊÁI‘—î$
^ÔæïLßcc׎7í8šàC§"cý<�'*õ
ÛYtpÚŠ5ÒÚ5³„®KŠM”PR�%�lÓRº<O
JiÔ�©©°ƒ¦�W¡‹4¥[Ç�6쇉w
3/í=A~ºþî%�H—°Y“ ]<˜.¼µ¥­Y:�
—S‰
´-"“&ÿû9sß´Yݲ£šùñÀêK�¤Šä™úãàäM›cÍÀa½€]eI`î´’°³VJ’„t@×y³ÊÜÒìŽbÔüzCk§êHƒÒZ>Çi¾«ìÐÉØD�J.‘¾P³&èIì�M;ä�É9£ ÿ¯8¾ÏÛÝT=ï‚û‘ˆ‚’¦LêSÂrûÜ€Š]äèÀ;CÀÑÝg
+Î,- °Æ‚íª¶~"ñùì
+ié“‹ql|,WÀ¸%�ûú�0
+-
æAJ%G3„¯
+r-›¯<oð:<|—}îêô0†g-)×
송ã
+ /ºÝÙÑáÌØ»:kì#ýP$ÒHF¾òÁ¦�ú‰™ï]Bp/Ø<
+õ¼©hÁÉ‚¸N‘¡öATú
škÄè�¯2lqÔV´ÔXƾ÷¹0|°‹ÀЄøžî¶-Yü‚ŽVžSç*Uù¢%Òs.™R¦�UFKz4n“œs †˜pÞ0‘j3ŠvÈ
Õ鿳9'ŽSPIHÀ&¡ímÓd[Ë<çå”s[¦ÌÀä¡JA%˜xŽÑ‡j¶â´�v²ý•‘†@‡àó:¡EêsÖðp¬6­Í0À58j¡d98—µ‰°N›ÏÖ¨*2žoP„‘P�õÙígSEußÅ!¦ÓQìò¤O³¾ŸÄ¦äo<w]½¬ƒ+¤¿�¯•§Œùzt5œaϹ¤¼ÁpQ�…1¦T<·¿gûCa�. Í²í‹†šìD˜¬èØ€Èäš|Ë!w#‚!¼Ê–ÉxÔŒ¦T(ø4—3GGdEÃøþ°xþ›µ>ÖE=€^tîÁãTj!ÂEŸ¸§ÿ×"UP½_pYëão˜œ;›?i?óðR»?}òªø4Z˜| œ²ÁöÊ!}3ÜŽào^O‰8uåç«ëÄ+߯§ÙØëzó}áÉbB¾IÏ]v‚ƒ3þ’
+O§‘«AV¢¾¶ã„¡Ÿ³¼Èî
+h¸2êbõ¡0¸؆†kÛ¬êÜõªŒUmF„¡?ìÙ•9`<Àu�[]ÚuâÓ«²ÍòRL)è}Õ‰0Ñmí³“Ï(ì4ëµ]�ýhs\ôð5” Ü¡m#¼ý)4`A
+•R	hôs n‰$HÎ^=ÿ·]žì¡VÇú	h_
+™Ìd‰ÀÈ/ti$ùHsÍi&}ÉŒÂA/ÄKÔû64miKÜ	„VÞÕp‚½Õd_T5¸7–#×Àù}ßåF1†�]êÀÓW¼­*q¶=ÖìšÄËüÔ]ÂÚrªyºM¤I¸}üu6Cï€ÖÑôo¶Ï'éw<êF‰8	“§Ý 5Ò©v: Gˆâyn S—ZV»%äz�
®œ¿w7é©ÀÖ
�ù	
‡œ³\óèYÓ8“ad#î_UG|9e©þæ2ºTsÊÖë׎¾¡±Û<nÙ�ξÎÿWËjÈ)qø…
 endobj
-1158 0 obj <<
+1213 0 obj <<
 /Type /Page
-/Contents 1159 0 R
-/Resources 1157 0 R
+/Contents 1214 0 R
+/Resources 1212 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1145 0 R
+/Parent 1199 0 R
 >> endobj
-1160 0 obj <<
-/D [1158 0 R /XYZ 56.6929 794.5015 null]
+1215 0 obj <<
+/D [1213 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 322 0 obj <<
-/D [1158 0 R /XYZ 56.6929 687.8392 null]
+/D [1213 0 R /XYZ 56.6929 496.5566 null]
 >> endobj
-1156 0 obj <<
-/D [1158 0 R /XYZ 56.6929 663.0573 null]
+1211 0 obj <<
+/D [1213 0 R /XYZ 56.6929 471.7746 null]
 >> endobj
-1161 0 obj <<
-/D [1158 0 R /XYZ 56.6929 346.0859 null]
+1216 0 obj <<
+/D [1213 0 R /XYZ 56.6929 154.8032 null]
 >> endobj
-1162 0 obj <<
-/D [1158 0 R /XYZ 56.6929 334.1307 null]
+1217 0 obj <<
+/D [1213 0 R /XYZ 56.6929 142.848 null]
 >> endobj
-1157 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R >>
+1212 0 obj <<
+/Font << /F37 791 0 R /F41 925 0 R /F23 726 0 R /F21 702 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1165 0 obj <<
-/Length 2655      
+1220 0 obj <<
+/Length 3046      
+/Filter /FlateDecode
+>>
+stream
+xÚÍZÝsÛ6÷_¡™{¨<­pø 
+T
ä^S°QÄxÂõ�`#ËŒµ¤í³ªü�sy7(ØÓÀ¸Y§M^•$>¬)Ñ«t]çåÝ¡‡Ó˜¹ˆ¸³ö×±T,9xe¾²íñ¼ˆ%pÆ\‰XÁ¶¤H¼äÖ®®Š{·ñÙå
Ø
+®‚VB¯
Šú'4 v\oflŽÆiMlÍÂQñÃ
©ó{GmEU}Ú¬jj_9Ï1ÁÀ\A÷H
æÕzéÂaµÇúÑ-Òb¾SfEîʦ�á˜C[:[l�¾L—A#j·Æmƒ½;pî�~Ý!}Û«Åc&åàÍ‚qb!Œìçy�z^žü«2ȬY§e
=ƒ ýwdéé¼î¯™Ëï_­ÝÚ¿cãeð•&‰Dl’„ÅÚDû"®6Í7’qíÊì t»ë~]ñŠWo1%¢!§kbË.Èé–U“χ]îm+¿Ë«Û‹óÿìÙý¦šUÅ
áuVõ=릕Lédèú«Y™àX½½Þ‡=ÿØgr_Tº}-y³öE°íñ¼<…d:VƒÊhÀÒ'œ¼è¦\¦Íl
®jH¤ïA–é�ƒ,
·;m�Š¼cʨò!­©nS¦ÀxΊê2׸õ2/ÛêE fEZ×û.Tú	ñ¼TœŒ+°*áèR©âa‘£ÏÆ:…Ž0´à°¾¬¨Âo5€v·'�X
+PÛT¡\¸¾%kXNF‘¾Ò2«¬nÙÒÆÝU0¿· 
+[/7EÑ'ÁZŽÙ"-KwÈ–v.Õ×]ÔokK9gFƃ¶”GLŠ ¡¥kªõ§Á›øÈŠêõ¡Ê!{ÙYÌwìtƒPj@f:‘Lê$ØËUWc8æx³˜ÏHdÔ瀼ºùŽÁŽ¶†YEi:†Ixwä5ùV‰†p/ðåÝM¼š¬�eÊÊè%c¶]ž•vĦ"=„ܵ�UD	G°ùuîêA)߬Ü1¨—Û÷âg;áôEµ)²6|¥r민1f}Öúlu„n¢I×Íff?Ša0šÕ2lõ
+¿2ð=ä`øýØÞÏ7
(NAĶç¦]€*Ò&8ú±{O
_¸O�ð±)W×}g+#wø={V'f#øªUH÷ÀØD-ÒÆ aW¶^™³$Vñ'ˆDë²^±SÈ
+jÐúm9 Ÿ\m3­šÛó3íôØ%¿+ýúŒösÞl0ã)æ¸z„ðp++©ÜÔ(ý(ò#LÞaNåٕ؃ÞLOéûê2Sßí¨(‘wg4�ühÔ‰�žµiNÍOnöi¢�å5ÞÆŒæòÆ)ÝfšN/d`tÇ¢îm|2Sê
 ãEåð/þf¤Væ
D’“¹{|Ó+¼‡æ>§ËUáجZÒ(—TžÀQ?ÞLû6Ù�úÍšÔšT~1iéšç&�Ф½®ë8¾Ò}Ó¤¯‚GJAÖÀdb-‰'Ëë†tÃ
+èe•m
+W÷*ʾ…îmw¯ºÚw£�~0罧ٕÒwœÉUV1ðñCXZY¸„Æ–ÎJØúì¯äï½Úƒ·7o¿L‰½ìq¤»æׂ‚J³Ø¼è´ÚÏ‹(#¢! ¨Œfá[J>€G��ú£ÁwþiAé$(|�ÎVY„uhØj2~,óz¶ÿlå=6'/ļ¬(Pú2”÷“ (”oô¬ºw[÷«Aù
(éy©„
+¸i%Q€eü%ötE%yÍžÚ,ªz/|J1Iëzö‡(Mç4¾î„¿­Òp
h3¼�2
ôj‚qu…»óç9©Êb8V;Ûò#*Tcß©M2
l|WÝÕÔ²‹)¬
+©C¤é½#Ê#_Oa–Nbæ¡rW}:tùﳫ÷'þµßŽ	#˜öÉÁ¶‡ésKøMᢥ‡5óÅF}ÛŸá!Ã"zéQ¢´üƒ´mrKÏF,ŠxÊäåÞcxª
+‡òuÛΤÓ{FÕ3t,Yâ‹�ýèB
+j{$jçÅàÃo97erlª*£¨bbÀì\„δ’>ÐGŠ’¡“A£?MWÛ²¡éî\Ca˜Ÿ†ÊÝÑ™¸ÕG¨ž§yºVT;¶ª¼`LüŒ5$i>ÍÝ„�÷iV•?„Ê°m�yo.áí
æm‚YU*ä�XÒ[}ÌÒ’
+Ñúš¼6+Z|¢$’ w;`]³>éþìÂEDeOT'®'L¢Žò¾¶óKªµAÕ¡ºUõYÿE%ùØN¾¢rÔm‹&�«é mÀò–wß´°GH£à�5ප˷!]i·oOçÇEïVˆfœhk& ÌpŠØËÈÐu÷nßuˆ°älót»-
+Þ$diö2ªs8E7YUuÞø_½ì°‘ϪÒ•ØZÌ&-Ыj©Û×A$)'§
ó‘áÅ:$–pýVÔÖÐdi^í¾@�þ÷:˜ôhÍ*}µi2 &Xn(I€Ú€ù&�XŒéª
ÒŸ×òiÌðàØ]žG�9¨vCdûú|„'[mODÐö‰U||ŽR.Ìõ9¯|þØkQéà£Ý½AG"*
%m¿m(iÛ@„mãqã%¨coçÀ•/{g‡I½€cI=c±Ç î>-ò¬E€ð^f‘­ÍƇÄZ$~ æý(k«›Ý¨/ü"§µ¸ýñôÎK
+§; ãëpÌí~ð9ôRìc¹}òÒÿ¯×v!Z²Hà
+8³’~óñô‡§|4ñÿÕŸ¹î~YÀeq¾íeã¹a±L,K‹Î6O�E«˜éXîØ:‹ÿ®æ¹÷endstream
+endobj
+1219 0 obj <<
+/Type /Page
+/Contents 1220 0 R
+/Resources 1218 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1199 0 R
+>> endobj
+1221 0 obj <<
+/D [1219 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1218 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1224 0 obj <<
+/Length 1962      
 /Filter /FlateDecode
 >>
 stream
-xÚ­ZmoÛ8þž_aà>œŒ=©")RR÷S¶I{Y´é^’èEfládÉkÉÉå÷ßo†CêÅ–ë¦Ý()r8CÎçá¸lÂ_6KdŠ4šÅiÈ�ÉY¾>gK˜{wÆ,�ïˆü!ÕOwg¯ÞŠx–©âjv÷0à•a’°ÙÝâ“÷æïç¿Ü]ÞÌ}.COs_ªÐûéêú‚FRjÞ|¼~{õî×›óyywW¯iøæòíåÍåõ›Ë¹ÏÉ`=·Ž,x{õþ’zïnÎ?|8¿™¾ûùìò®;Ëð¼,x�?Î>}g8öÏga ÒDΞà#XšòÙú,’"�‘n¤<»=ûGÇp0k–Né/
-YÀ¸3_$A$er\,‰A¬í2¤RîKõ™ˆ�SŒ6‘*¡ÛÙ„³�MX$‚D9‹e(Á…1Ên³ÈZí7:ßm‹ö•ëÄ`¨'–QÂ�þ|³ÙÎYâÕ�YIêͪuº*Ü`ý@-±§¾Y§ÿØé¦m‚}kD`ŽX)>âû#¢$à} ")ƒˆÅü%<Ý’£ÚVa(žÈSÚŽâ@Å1…
-)á8œsϧ
š�^U·¬c–êòâúv$VØ­íM(æ×Ðx½s¶GSV­Æ!ÖÓŲrñ‹\o‘k@+Ò�Ãî”|cŽ“‡^Â_öÙF½†¬ÉCº;ž_Oiééé)ÐÿÎÖ›Ry½&.W×ÔžÃêýp{9µ÷¡èׯIhü2¡•n�	õIèdºÞÂßyµ÷ù‚‹ ý"$8àéVÍ2VAÌ~"[È”\¦©QÏ¢h6Y›¯N¦‹KH·¡à”~¡-*°¥eÞ&Ëÿ¥MàÁT[ÛÖ8&t½}4�ýu½Ø•t�Ølœ�`¹MSÙh¸ç$r¸¡ìÝ8iÍ¡–¾Oóƒäo7ÿ'-	I/Vâ”-l!JÙ²‚“ç§-y}{{ùfXÝÝ^½©±­óº<P,Øùší·üg¡*!ƒDÉ—Dž[q\±<	’4>…©$`D€î‘QY	ÉÉ'ç=
¬Þ1$-™Zwo0o‰3sc':?Æ�uÑäu…)}¹Ûf	LòÍý�D¼®
äN‹‚øŠ+Œç¼~Ô]&)ó¥wöRj Î*ê
,0!lú5µG³H»ªsN'Î
Þ›{ âM]îð@_ð™�5¾Ï½Ó
-ËÁµ„B ³´<FUœ�xÙ1,¡DÒºíëP6‰‹ãf¼cƒâ‡Fø:à3Ž=¾�
-P›RŽÓE©_Opô9ø!KÀh,
TÂØ`çêþ×xºÃ4#?ÿDeÑ´£Ì-0M±ùÝ<ÍÇ'zçÙqüøL_?ÚùoX
uìðÿ~tŸw‰ðX觾÷;jpzÕè€�ζ€y‡§[Ô묨ƒ©ƒ›þÊ=�¤W‹ºµ¶ 7òh�¿g:.ðuÞ9ˆ¤áPG}ñ“!t¡ÑyªÂ†(ð×&[ꯉ­ÉXIƒ¤/n
•$SÁcEpæõ8ˆò�R¹
-ËŸéÞûÅE ÝEÏœŠú®ìŒý,Ïõ²q‰Ÿf”ù˜îê�ªšZ[‹„^aIÕS,6r5 I9#	Žxgê#ÎVÈi`
0x×EÛQû?Nز»)Q‹tRWšstWj³œhÓæ-Î^àk@�Åò!“:',Âý«	0“ﾨ
uIØë¿ ‚6£bμÞ'pl�8âo×#”áIŽ“lEQÉ:˜wCF€ØØ€ßd9V—¹H<S&6�®Í…«›
-W9n6ð×D‚Ý—ôqoÉà’iÚí<ñv9YÊ…ãj‰“«°·ÎªŠŠ^ô â-ØTõv�Yîtt…{³´¯¸Ùœ€FC)7+dÖW£ÎW£±¯
-Ï
÷Þ)„…Ç8½Ð™yà!
i{nF…‰�ÔVçq®Ù]ÿCA�Ñ�³èvmÅgÑè-]¤ÛNêTb[,—®Èñ2ÿgQÚ
uB�¿#±€GÑÄ]Ë£„ž‘	äâ1+»qã¶Qzì!
<•êqÏ·‰®&ð¾T}Zx¥ÛüÕÖDÖ±gD*1—?ÁeD˜âO*fïîw×b¡í)3j(‘`¯~ 0
-Å|ï2'˜ìn·U� û p›m6ºZô?oÇÙ�–ÎDõøe+Á±Ú
á¯ã'œ�,Ò~í�ðýÿPˆðÝ7,¸�LéÞÃvS¨Ÿˆ
+xÚÍ]sÛ6òÝ¿B�ôL…üÀõ)Mœœ;W·g»OnÆC‹°Å)?T’²›»Þ¿],@‘•(i:ž1‹Å.°_Ø…ø"„?¾ˆbk¡‰V,
+y´XUgáâ	æÞŸqG³ôDË1Õw·g¯ÞÉd¡™ŽE¼¸}ñJY˜¦|q›ß1ì8„Á›¯Þ]¾ÿùúõy¢‚Û˯Η"
+ƒw—ÿº èýõë~x}}¾äiă7ÿ|ýÓíÅ5MÅŽÇw—Wo	£és„éõÅ»‹ë‹«7çn¿?»¸Î2>/%ä·³»á"‡c2©Óhñƒ�q­Å¢:S‘d‘’Òcʳ›³G³véœþ„ä,‰äb)KAü˜è�8I™J¥
+Y	›i®}Zp=JŽž|9¦§Ü8VÎ
WÔÑ�Y-É5”ŒX†|êdG®U1±¿ÏX¦‹H¢Þ“Ù4ïi–#¢Ã½ísBÑ´I[hŽ>AÚ¤­TÙG,BÕ¶ì‹M9ë8aÊ%Ôç<'f©ˆÕ¾çt$gç:EýD"'æFš©¹Cæîˆþ¥èׄ΋G$}tG÷´úç1$z'Ó¤²±DÍÆ´}a:6D¾M¿é'F€‘!tÝ©‡¤{xr%Y"g"FFA·1«nƒEÆÖÕ
�ì�7bl"¶çïˆ6²¾mcé0!wdOœë×™cÐÛ«qE
Òë•Ùcì%ŽƒæIšsÝŽ ôÔq‡¸ã<È3S¡#Ü­›m™œ­Vfƒyèþ¶5g›¢&¸|$DÝЗ®„
+GºSTþ
†z<¢Ñ‚“O¼íà"žrvZ@N#�€™›¦©Š¾·¢0¯NwŽ˜—¢,	zpe	�Ô¸LìS3‡ÚÜ„qlj6mIÁ¿À× 9+;²·æL€)Üÿ\“ÊࡨóŽ@RB;‡À‘­¥à›Ñ§,Îy0ò	ÄM#1Þð–q3a@—;Éñ’�¨·W7à•Ðùô¨ XãûÑ™­êN¦
^Â:4º¶°NnpûÚ4ugˆÛ/iðàÈ Ét}{žÛYÊ…çêˆ:{K!TeumωqÙ.£OÝ´Uæ¸Óa
+ çJ©™(P)5ÊÆrñœ•Þz®ÒÇÚàÇ’ÿ9ÑõLµ½Ôp3¼2ýêUkƒëX¡#+î€×ÈP—=íÝÝcÏEnÜ)3úÐ]‚PóH‘&c`”ˆ½|NE²OpëKl›Ù¼gØÁfcêܧ9«·!A–Y_<;:ØÓ
+Ããð†ýŒÉ÷µ&ÕݳݛN5Ÿkߔ룩Á
O�>ap�¨ø$Éâˆä#öN£�ïWYjZkñSW^¬@hçÎD2$�Í—U%vó¶<Ûº¨¶0S±ëaN¨$
+Ç]‡&]‡VePñµ'¼sL<
 endobj
-1164 0 obj <<
+1223 0 obj <<
 /Type /Page
-/Contents 1165 0 R
-/Resources 1163 0 R
+/Contents 1224 0 R
+/Resources 1222 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1145 0 R
-/Annots [ 1169 0 R 1170 0 R ]
+/Parent 1199 0 R
+/Annots [ 1228 0 R 1229 0 R ]
 >> endobj
-1169 0 obj <<
+1228 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [519.8432 216.1999 539.579 228.2596]
+/Rect [491.4967 546.2465 511.2325 558.3062]
 /Subtype /Link
 /A << /S /GoTo /D (lwresd) >>
 >> endobj
-1170 0 obj <<
+1229 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [84.0431 204.2448 117.8035 216.3044]
+/Rect [55.6967 534.2914 89.457 546.351]
 /Subtype /Link
 /A << /S /GoTo /D (lwresd) >>
 >> endobj
-1166 0 obj <<
-/D [1164 0 R /XYZ 85.0394 794.5015 null]
+1225 0 obj <<
+/D [1223 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 326 0 obj <<
-/D [1164 0 R /XYZ 85.0394 429.0696 null]
+/D [1223 0 R /XYZ 56.6929 744.5408 null]
 >> endobj
-1167 0 obj <<
-/D [1164 0 R /XYZ 85.0394 399.3522 null]
+1226 0 obj <<
+/D [1223 0 R /XYZ 56.6929 717.3918 null]
 >> endobj
 330 0 obj <<
-/D [1164 0 R /XYZ 85.0394 269.1889 null]
+/D [1223 0 R /XYZ 56.6929 594.9189 null]
 >> endobj
-1168 0 obj <<
-/D [1164 0 R /XYZ 85.0394 236.5067 null]
+1227 0 obj <<
+/D [1223 0 R /XYZ 56.6929 564.805 null]
 >> endobj
-1163 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
+334 0 obj <<
+/D [1223 0 R /XYZ 56.6929 340.8686 null]
+>> endobj
+1230 0 obj <<
+/D [1223 0 R /XYZ 56.6929 316.529 null]
+>> endobj
+338 0 obj <<
+/D [1223 0 R /XYZ 56.6929 259.8095 null]
+>> endobj
+1231 0 obj <<
+/D [1223 0 R /XYZ 56.6929 229.6957 null]
+>> endobj
+342 0 obj <<
+/D [1223 0 R /XYZ 56.6929 197.042 null]
+>> endobj
+1232 0 obj <<
+/D [1223 0 R /XYZ 56.6929 169.8331 null]
+>> endobj
+1222 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1173 0 obj <<
-/Length 1372      
+1235 0 obj <<
+/Length 1102      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥XKsÛ6¾ëWèH€
-#lvqA-h)”‹\‹qõô,ú½e÷$ßÏ‹JÏ‹i¹†QàúGI¶_�\j'Ûz{ÜWTįÊ«üÆU™Nˆˆ<è»Ø12>¤Ã¬K¡•geÂb)”›¤-Ý|!ec(¸%p”›}.
–FyžÝ!±¢-$˜ë[e[li£èÀªR=×ÙÛÍH¤n†èas†C‹æD°{Úo-ˆÞX%)̬ȈÐϪ6O†Ü¼ÍÍZÏGŒº#±ÐSq¦góªúÖÖzzKÓJ£tÆ¡±Qœ’nQqªü¨‰0Í»“ázD„Ô5-šÀ}ì!S%Àñ¡k;î>ͱ#S!$Uä‚6òóððe’7¤(¤˜ç èŽ.{_"jÿ)ꦮ¡IVoÔàV�þÖ�¯ÈCš2
-õ¢ë’
iŒp–?jºåÔ±53…yVçf/íö‰µ<'÷fõGUR>Œ 7ÉĤwp¶gœ]ÕÊ•GÄäÈUO|ºÎ˜A蟦² ëÎ`ŒóB
Å!t=×3Ðk6qP²&"LUQÔ•ˆ‘ŒQ2D�õeZ¦OòR!õmhû~¯�
-»œþ6
	ìA/
-¤—¥
ŽmJËÞ±:	Uñ±©ËuT‚nôŽ{(]L.VÞ™œº�*`†;«¸8Ô‚~ôS~<äç´‘2
K†Ã
KŽ× a
�EÕ˜Ú 
-éFép«¬#à4ö‘îÝ!‚]J›ÓE‹N¶¹�:3:ú$îlX7‡SP#AŽñ~L⌂”åôt’¶¨g²´P¹#ë‹ùñ#Õk–Ì”.Ï»•Q^ÞÍäÿeÕUÙ=ùHù¦j6eu„¤(wÃð9…=¡ê^QݨJ@wL…�ÇYGrÕéè�®;GÈOÉ7
-Ø÷–öIwŠò©lD3p—·ôt¥Ó¼åèn-e9ÏZ‘T3<˜	�' ΙnÕN�…òÔÀ?

+xÚ½XKs£8¾ûWpŒbyjN™¬“ÍÔNf×ë9eS.„QYHŒ${ÿ}…<x
+g+•€Zô§îOÝ­ŽlÃR?¶á{¦åcLLϲ=#LG–±Vs7#»üT�æW߮ݙ˜ÁÔ™˸�å›–ïÛÆ2º¿¸úãò¯å|1Žg]LÍ1ð¦ÖÅûۻߵ$Ð�«Ow×·7Ÿ—ãÙäbyûéN‹óëùb~w5Û÷l¥ï”G®oÿœë·›ÅåÇ�—‹ñÃòÃh¾¬}iúk[náÈ—ÑýƒeDÊí#Ëtß3žÕÀ2í pŒt4ñ\Ó›¸n%!£F×€�Ù½jžë›žïÌ:œØ
mË7ƒI03f^`N]ÇÝ3x?S˺�´k!`†AÈQ„¨Ä�蹌câ’wzüP¸­Ö¶mžçü„±bªú�ÂõÖNÔ_=V/«Bõe$áºÇnâ„0Lˆ1)53(“UO¢<ͪ¦(J,$…í�X1¾¢¬‡Õ-õ�&d8¨ÉQ˜s�麿~ËúW›þ•QNä¯
+�
+
¢ð‘ÈÑRý	A9h×JÂØ
+¡æù\¿<Wéi˜0Þœío_Z
+\†aˆ2©êq†U_2 22þyô²½ú­È’ÖfƘYÕgKKdÄËØù¦U�e+E%�÷ã²–ƒ=*—1M³ZoÿøÑ«QQeJÕºp£èæOµG×ú¶s\3(zÓW/¼èÝjt]Gá¾ïá*ÃZöó½ ¹b¡€�X55mN@§Uÿ— ÅJ£ú¾øw,�[’ªø7ìì Î9 Nm‡Ĥ%ÀkÊ8:d ¾åQº=tç•kZ¿ ï“(¬3ç”ÌÕúªN£5Çr7 ÝêôôYð§·]³ÃM�‰j»ô»ª]}Íf¡¬@Eî!!V)TMáŠàª®ýèÁƒmt¡Ã0�#˜ :¹Î»ÿ�ï-HÐÈç7[rHE\U¢³Átugã¢Æ=?y¦:ô&  <¢ëô:%²ÎÝ�Øœž·RE•3Åi¬¬H~
Ðu·äzfq!ÔqdÕ‡ñ«ï�^.å&3Óõ}§¾RrÜÆ•’kMMß	f•Q…“÷Ðòú‚êgÓÿ]Ágendstream
 endobj
-1172 0 obj <<
+1234 0 obj <<
 /Type /Page
-/Contents 1173 0 R
-/Resources 1171 0 R
+/Contents 1235 0 R
+/Resources 1233 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1145 0 R
->> endobj
-1174 0 obj <<
-/D [1172 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-334 0 obj <<
-/D [1172 0 R /XYZ 56.6929 716.8068 null]
->> endobj
-1175 0 obj <<
-/D [1172 0 R /XYZ 56.6929 691.8907 null]
->> endobj
-338 0 obj <<
-/D [1172 0 R /XYZ 56.6929 633.7645 null]
->> endobj
-1176 0 obj <<
-/D [1172 0 R /XYZ 56.6929 603.0741 null]
->> endobj
-342 0 obj <<
-/D [1172 0 R /XYZ 56.6929 569.0137 null]
+/Parent 1237 0 R
 >> endobj
-1177 0 obj <<
-/D [1172 0 R /XYZ 56.6929 541.2283 null]
+1236 0 obj <<
+/D [1234 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1171 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R >>
+1233 0 obj <<
+/Font << /F37 791 0 R /F41 925 0 R /F23 726 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1180 0 obj <<
-/Length 1187      
+1240 0 obj <<
+/Length 1162      
 /Filter /FlateDecode
 >>
 stream
-xÚ½Y[s£6~÷¯à1îŒT]
Í>eSg›�n¶uݧ4ã! $L¸xvÖ³Ûÿ^a.Ç“L°è;ßùt$)Ø@ú6‡ˆ
-fX‚AŽ07Üp„ŒýîÓ߀ò#Pÿêãlôë%µ
…ILcv_ò!²ml̼›³‹ßÏÿœM¦c@8:3áp�}¼ºþ-·ˆüqñõúòêÓ?Óó±ÅÎfW_¯sótr9™N®/&c€mŽuR èpyõÇ$ÿõizþåËùt|;û<šÌªXêñbD³@¾�nn‘áé°?�¤ÂæƳn ˆ… F8bœBÎ(--ÁèïÑ_`íí¦k›~œÚ�ÛÄjPÔÄȆ‚	Ë°¸€&%t£à͘�ÝÇɳ“x2QyûGþ(Þú‹¹ãyIa[ÄIZÙ³ÆmÞú�? „ù�Âü߇²©ÕÒ”
ÆPpNêî½¥
-œ•lX©q¤d�g‹txG:�QæÞñƒ†Áˆâ¤†Ú7¢ðûn8'úD/8{öÏÕù�ÛÖRÍãdÅíýñ~?JåCâ§ëN
+xÚ½X]sâ6}çWø:#U–mMž²)I³ÓͶ,ûDƱEâÆX¬-ÈÒîþ÷
+l°
Ø&Éð€-ù�{t¯t%l ýó Å	7lnB†03¼Yºï¦ƒ³oÀö#Püêðóë5µ
¹E,c8-`996†þ¨kA{
u¯>ß]ßÞ|\öl³;¼ý|ׄ¡îõíýôéfpùéÓå °Ãp÷ê÷Ë?‡ýAÚeenï~K[xú÷è Ýôï®ú½ñðc§?ÜùRô#ºvä[g4F†¯ÝþØA�r‡ÏúAÌ91f“QÈLJ·-açKç¯`¡wcZ©F�P‹Thâ‚€‚ÒP6ãТ„nõ€…P×
Cù–HV‘zI�¤íÿeݾ‹$™Ì\å=N QiûÏ‹ô¼B³
CÎ)B߇®÷ô(Cñjˆ‹D€¥	þÌe¬ÊT×-§ñpÉù¥üsZ¯‡—1´^Ïçõ×"2J_G9PúÌ'ùËøÕ¦n7¬væ}Gþ¶ñ
+$r{Y$þ�Ú
+ææd=Júöcƒ‡m)±™†…¶IÍ
ê/iW6N¡CcáMÀ–
©MÌJýs‹ƒ<ÏÆÆ:ÿm�ÆéØ쥱Y>vQ· #œVÇV*j-%¨
MÇ4›³Ii˜š”[•4Ú	Rg2Š‚ä
G©á—Bg·ÕÑcjÆmH,Dh–2r¤úíÅz×è±NEOƒ©;=Eï#HÝè9Ø6´&£o¦í+‘Ld<‰dÝÅkg_Ü
¢Åì^Ä5ü=ˆ R"^ºái”‘™û¨Ø�’©ˆ�
+fB�
!ª¡3%ŒÀÏ¥±�¨E£„¡¼9ðÂ@D�gC猖_øzUñžDsR6÷q,EýáKözðÀ
Ó°±«DCúû@$-TËê
+ÆÎK›Bjr~ÌϺI“gà[ä7Ç�8Ä>FTIÍÕÝ›ÏÚs↉)Ré<¨Y实b;ja!,€?kÁ÷iBù
+¼¤-‚’s©ÃoUïöd|ql>tRäß6…*W­q"�±¿­Í2´MËá$�Žöî§fž¡GnŸ\}ÚP*lqÚˆ<×{¬i|�Î'm«î�)ƒë‹ßŠ_´;¬ž}¿œ_¾›z/s²»:&´puLlGÝ5HFjíŸi0ß^DRÿv2°endstream
 endobj
-1179 0 obj <<
+1239 0 obj <<
 /Type /Page
-/Contents 1180 0 R
-/Resources 1178 0 R
+/Contents 1240 0 R
+/Resources 1238 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1182 0 R
+/Parent 1237 0 R
 >> endobj
-1181 0 obj <<
-/D [1179 0 R /XYZ 85.0394 794.5015 null]
+1241 0 obj <<
+/D [1239 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1178 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R >>
+1238 0 obj <<
+/Font << /F37 791 0 R /F41 925 0 R /F23 726 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1185 0 obj <<
-/Length 1261      
+1244 0 obj <<
+/Length 1750      
 /Filter /FlateDecode
 >>
 stream
-xÚ­X[wÚ8~çWøÎY¹¾`cŸ<¥)ɦgKº”>¥9aÐÖ¶\I$!Ûýï;²ÌÅ@RÛ<i>�梑dümÃóM?tBcöMϲ=#J;–±€¾›Ž]ŽA›AhÔûIçݵ;0B3ôߘÌ÷°Ó
-Û˜Ä÷]ßtÌ XÝ«»ÑõíÍ×ñeoÐïNnïF=äxV÷úö¯¡¦nÆ—Ÿ>]Ž{È<»{õçåçÉp¬»üãýíèƒæ„úó
-èxx=GWÃÞÃäcg8Ù®e½¶åª…üèÜ?XFËþرL7<ã	–i‡¡c¤�¾çš^ßu7œ¤ó¥ó÷p¯·=i?Û2×wN0Ü3``™¾P/4}×qÞ÷�oY]œ†2&é|­ÿêͧ8Ž¹nÜçŒË-_5të¢ìo!cš¦&Jö›&˜Ö‡lÛ=ÏÙW6Åψ>Ï9JØ	úB4;[¥3ÂkÊÿÃV<ÃÉž¸¢¦"'Ñi{!bœœ�¬¬ì-
b,ñ9òsšÑ@¸¢¼�8ú~ÎìQBpF³¢™$ü'
í¿$˜ËÁ²
@e…ØG¤­`I…¤‘h‹ YÎ üªÙ¢Âž1M±Œ–Óf(ƒúáâ-@RìÆ6…ªhŹ 1^A+8ÇN¾³÷05wúº	N	’²©CUFfŽ–5…�Ò¹­¬ Χ1•ë“¡P;«Rš!Θ
5X	Rlfºµ&bÊø4cµ“1çì‘Æ'1jhÍÉ�²¾t5	¸Jâˆ#,�È!Û.¢0™CÄ/‘¤)iç
ˆƒ6 '4‘|}D¡GSˆÊRŽŠf�iaÇ ’2UÔ朥¯ä²­?±Šôj
-i“´É!Îç
-»R-†‡ì·Ï¥ƒa $S*´N=
rîKù·J˜êA7¡$“å„£Â7­wÄß…$ÔÑŽ¿hÎ8¤ó.÷$y–?9~RIU{}$Í¡ð°ðF‰F»’�XGjÙZþ…eD4ûTàï5_QÍvÚÂÕU	†wªæq|
-¥‰¯/H9—»ww†©Ï´]OO5Y’­B»Av`†a8€ÁjÌFƒc0ׇû·ë•ãÄžr®Û…¼ÐÔ*×ßEÂf*ÿ½[4$Sß~wFJ
AbMÍÖú«4LMN–´;˜0Åå`U1/ç)özMED{Æó”ÚNÕÛjSu}¿‹Õg
+xÚ­XÝs›F×_¡·Ê3�Þ
ÇÇôÉMíÔ�Æiuú�fÜœ$&(v”6ÿ{wÙƒŒSYi<–»½ýüíÞ">gðÇç¡°™yó òlÁ¸˜Ç»›o`ïÕŒ«c²†\ß/gß^ºÁ<²#ßñçËõ@Vh³0äóeònñòÇó_–7g–#Ø·Ï,á³Å÷W×?ÐJD�—o®/¯^ývs~x‹åÕ›kZ¾¹¸¼¸¹¸~yqfñPp8ï	O¸¼úù‚¨W7ç¯_Ÿßœ½_þ4»Xö¾ýåÌEGþš½{Ïæ	¸ýÓŒÙnŠù=¼0›G‘3ßÍ<áÚÂsÝn%›½�ýÚì¶G§â'ÜСLÐãƒ
+$€ªM8µZŒ�8S²½�¦®Ú#ó.O*˜‘5q–ª\×V©*«ÍÍÉ�ùdInÕŽu
+)^”óCíiõQÿSÉ{,ª£-S»Æ™"Üñ¬®DÇã"×2ÖÇ�ç�Ï*rU%l:à?H¤u¤ž×i?©ª€¹Ìªii��Z‰bŽ½B,ǵ#œŒG¦AõÁæ·—Ÿ÷ËkTÓ¯ãù¢eÂéœû0ª3�V”سjÆßj©ÕàG¯?¨?sòö†£¸¡ˆø­–et¹ƒÑT9�í´ª–[Õ4˜Ÿa|Ž"˜‘§³à±0ׇéÚ†¯纋Zá‰TSÒs“+¬¤Ü‚]àÓ[¬”9P«„¨Õžžø¡c¹Ü¦æØ�Â�4Ìx+ÊÊèi{=Q±¢Ì�fóqf°©º¾¿�øP
+ÛMSIŠ.îáJ¦À_D‹«5-ê-TŠ¢q¸ ˜¬ÚañÿŽl
+‹„S“Q±cþì”C×£’s=(AùAå´$kz’/ȽS´Òºeȶ
+‘zp=朷^EÜÄ9:ø "@ig)lÁÝGÄ®¨5Q݆ÌE£ËƬ“Su÷"˜²76•Îèãÿ ‹cð»jò‰*ƒ¦D¡kªŒî[ÒÒ6˜ s©I'ÝÐi»
+2г¦…¶sïŸ�p}׆û¨k"öT
 endobj
-1184 0 obj <<
+1243 0 obj <<
 /Type /Page
-/Contents 1185 0 R
-/Resources 1183 0 R
+/Contents 1244 0 R
+/Resources 1242 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1182 0 R
+/Parent 1237 0 R
 >> endobj
-1186 0 obj <<
-/D [1184 0 R /XYZ 56.6929 794.5015 null]
+1245 0 obj <<
+/D [1243 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 346 0 obj <<
-/D [1184 0 R /XYZ 56.6929 122.4687 null]
+/D [1243 0 R /XYZ 85.0394 285.8176 null]
 >> endobj
-1187 0 obj <<
-/D [1184 0 R /XYZ 56.6929 92.1609 null]
+1246 0 obj <<
+/D [1243 0 R /XYZ 85.0394 252.9894 null]
 >> endobj
-1183 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F21 658 0 R /F23 682 0 R >>
+1242 0 obj <<
+/Font << /F37 791 0 R /F41 925 0 R /F21 702 0 R /F23 726 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1190 0 obj <<
-/Length 3581      
-/Filter /FlateDecode
->>
-stream
-xÚµ]sÛ6òÝ¿Âo•§‚‚¦Oiâ´î]Ó\âÎÍMÛ™£%ÊâD"‘Šãûõ·‹H�"åÜÝÜx<„ìb±Ÿ
-®p!Ÿ.~ÿ“_®aÙ?_p¦¬Ñ—�ðƒ3a­¼Ü_$Z1�( »‹ë&ŒzÝÐ)ùie˜62› TSÔ–¥
-ºP€ëb“w-­ê±Üí¨uWÐ÷Økv²Jθ†
ȤeR$Éô®z¤eŒEL‰)¦–cª<«¶><�)©™µZ�'ÝaMÐŽ"g6KÓ!ñÛ-¬]I½x¬Ëêž~
-°‡	s
-PhØ\~i‘Øš\¤2rq³!„|
-o0YU·ÔhŠU‰«)Öß
ÄpÚMìê´ir.P°vÀ	³!@[î?'¡RÅRÎ3¿<6%
-_ʱÏ
-)Ƕà<ìý!ßcà�œáÆ)‰éòX³°MR
�†~7ÅC~ÈÛ)ŽD’1¥´øŽ4¤‹ü3BT\xƒoUëbý=² eë¡›cµÂ�Ëweû
-P?bRþDm/KEÁ¿sk ËÔ†Úã
-	Îå5e¿.é\þTìv{—aZC>
-�ünç[N&г«óµ‡„)B­ãTke
B½¨ ÕÕÐäø•f©•fèø»ÚU9¨t§úýá�æ3PsÝøaó¦êÀX”mý‡·íæ>ooÜ‚“�Ež7¸ëŒÅ,™òÕ¶Xö§`ÃÓÁŒ¥ƒÓ§ƒk‚üðtP²TòlHŸÊ·Iþë"¾ä-Ý&ÕÕn°7¯k/µºíNVg¥§29|òÌiEŒ5/½˹âãþaVx–™ôÚ
i‚öPt	3‰§üV¥ƒËg3ðmC·ç/ö®
-�¸Šf4h�·ùh»×ô}¤$ZeÕ´‡+³8®(ç��ÖþÛÔDj&^Bœ4ýul·‡j½òf	\­ïfBœNe”£­nFú0::ŒÍppF_6áßùa³¸èo0±Lñ,½T)Tˆ˜AÅí„dÖ3}7±ìf\ÆSÒÍÍà´2L¢ä:´ ‹lR`€n%âÃÍI+Q)ÏYI„uÆJ–KuŠ}Óæm	æ¼jæÌ¢qj­=ÏE‡5ÁÆÀ`RËR#ä�2cbƒ1–Æ„
-ÃØÞ`b`g0
-Fƒ[Tz”&žœ�õÁ$¢0}Ù„l¶Eˆ}õh|X%yWúWá(ΰÄÉO…\Ô]ÂB,ÓòÑÚ.vªó·

-)Že}Èê㘙ŠcYo–xVÙúãK
-·*¸yN3±LËè^
-;è�Be£Ð¡RÞ“ëïçèpõT‰1»
CÞöE(©Ak´Ò}Î/Çêi:ìÀó,†;É}ê­U¼mî7eQI¨R
-s5“tŠ/ÀS1tQ$ɺçZ¹w²;+ͺ'ý#
¼l-«ÝS÷JÀ_qc�?Q�î'ð¾›NW¿§‡ù)B¸yÐYè%yb_í:¤‡AÄçÔ#žþX¢¥Ýã�.ë‹âýþX•«<¼äñ·"±ñßïê»ÜO	¢gso†!äâCß	Uƒ/óÿù=qÿØŸ‰3g™<eFÚ,0…‚Iô˜óîáñ)ëÿÍ6RÀendstream
+1249 0 obj <<
+/Length 3961      
+/Filter /FlateDecode
+>>
+stream
+xÚ½[_“Û8ŽïOÑo箋٤(ŠdíÓlÒ“ÍþÉÌ%ÞººÚÝÙVw«bKŽ%%éûô$Mɲ{î¦ê*•˜¢ �
+.q"_oþñ/~»…iÿù†3i�ºýœ	k³ÛýM®$S¹”¡gwóùæ?â€É[÷éœþre˜Êòâv)sf€ÿ¼–ÓB
+<Ó*ëIAˆ.þ6Uµ­¶@²EÝûÞÇ¡Ùà•»ºI?°‹õPïzßÕô^f¯ÀÛeÆaör¢R8ºaW¿�´àšì̽µkZçZ¿â	Õ—T(Eÿ¥zY>u]y¨—›#̺éërwæ
+Tlsu]ŽH5#Hº¢È˜ÔÊŒ%Y¡5
+‹êØG§a|Ú¸5Š‚¹¾ïuÿì[ÏõÆ7ûÓ÷N�Ô~n‡Ý–Úå
+±C„‰Žšdqô¹£Žî¹ô®NÏ„gØzªš
+Ãå–¾p€y¾¸2 ¶¼ð+¶úËÃÍ,k¦™ÈÌÉWpüÿtò3–…†¨Æž¸ÙÕ€Aˆ°EŠ°s}9‘H–+n_È2®퉪›ç²yr8ÁÁ==¿}ùB�öHìbGÓz’˜ák>
+À¥®ŽZuô.P#Í#�Uœˆ«„öbñᑺ)TÌþ
éGpÉ­ž(ȃaà�-\dü�¯ÒEÆg‚Gh|¯wžqyw`Eþa]Í€ŠÐS…	«¦àÜk¡ÆáñÒ¬~Fç¬Àš€ÿ>ðÍØ߆
+ p
+ä0lÍëðKò,xÃk»'¥<W?¨±­Ÿ0œÑÏ¡mÕYNòÔ�*¬K’Qø}Ûõ4³MÙUÝrñùlJ)Îr
C�ìŽ;Î0Ï
+šq«K›��£“Ì•°Ë0Þ2ðü-|\@‰ˆÂb{˜˜‰÷°@&vque šÔ˜7�‚½ÜáÆÕ—vð!7æ`ð0tuóä7b¨÷ÉXÈ¿•ÇÚç”ðtŠÝ!bo+ÌÆšj{1n+Y0e P\�Û)Õ帩N®òŒ:œ¯Ú_á©f˜Ëóª}ÂÝ…íÌêÅ»úuŠj¨–ªv»½³ek<"ÛPˆc×Ú÷ôáë˜-[ŠñØ‚4õŽpÞj̱EåÒnw�-«M*M™�ÑY9vŽ’
P²u˜!ŠÎTÖ 9Uäæ—àÀ¤57ι‘UA/
‰Xx‹ƒ–Ó	¼ÙµåÖ÷„!ÃzWoü®ØÁÎcý�T½^UÐz¤jcThOfC¨¬ðv_7iY�ïíñKt—­Ï6}{Œ�Þ9œÿŒ°˜J ÂâÑ` XRæ$MÜ*RN‘ºžãØ8ÆE¿ð`ByÝïRªË~©\’Pnž«%ikÊw¤FÌ1D3̧¡3òhÄ}¡)üºìË)
rȸD®˜NVæ]êÅ> ßÝA£È
Ž¯ë.¡º¢»@å`|Ø.¨NpÁ”È_a©f¸�•W°w´FìW!JwöŠóTÉKè’‰RÈ°!¬ip*Ýä»m	uuÙù'Ú0„üŠŠhÕM×ïÌbØP	’m[Ï"|4_š@*ËŒ-&y˱Ùn¼g‚TÛõ|ö’©"K’Ë$>F£pI¯ÄíÔgGûu7—("¬«Ó
Çé*CJôBÜæÒ2H¼íïN?âˆËtHg#餀arkOœƒA²Y…å‚™\Š¨°K®ì…Î_Ù�L©®¸J rûÕ¾ëËr¿zÓ]òˆÈâ«RDª1F>S–ÞŽäð!‹'>ƒO®3Á>�>“tŠ$ÌA9Ö½/ІÉaäpí¡+Ÿüw§	ûqZϬ¡_H…{0ÝœSI‰]hº.¨a(U6vŒßgÏ\‚¯ÙÔœ™_•¹RÇ@šd»`0²(pGà•¸”R]6˜Håvíëí31–�ÿÈë¬ÑëQïΠŠ1ëÕü‰	áª>¨œp59e9�ªŽ6âmzŽãw�7Uç;>¼Ç:Xê̾p8æÆ­»,ø‰]\wÊt¾îhþÒØàú÷d_y†–�œV@}pš{gô/ƒ…˜«„¥†‚&OËûB{ï‚*6Y=÷ì¢;üúÜZ.w.lz:ãiú粧Ö÷²ñ-ç:–¢�ÿ¾«Ÿšr×%¯5?eÈQ¼QNè‚UÓ¸¬Bj¶t6:œYÚ,>Ó®’ÎdÌJ2X…xÀ”LÖ
Û6³7|$òXÖæÅ}Bë	‚�ÄYt”ôø«³hœeXêÀÒ÷$bø�h­Ã	•
+H
+
+u;RªËØ©\žÖÒ¡WÊTÆâÕ¥«LÑÓ6r–[ÀëS�fñ÷w¿Þ¯ÞþJNhA’?ìסˆà&ÁƒaG¤nk»¼ÝVõ7Je¹¿BŸ6ÛØûîãgú4½²ây˸_¼Á|ÍäÑðøa1)
’X¢ã
*ȃ±òÈâ>žŽ·ÞN÷¦ô;v/ñâ”?Ç7~·/Ù9ÇSqÚùûÝ
+Ï	âQ‡oIŸøÎ9Q'¤M�s|?†`ܧ°i0
;¶§C’è7í~?4þZQŒôcïÚµëÒ	ª¿láÂê•›�	ÑûöD§£Ìå¶úVoÎÃb–3]hq•w$:g>Nø,Ó`/#]íàŒmãŸÛGúÜ%#<ø;_¨Yü]{Bª
]ÏËüe/*Ï2èx˜Vû+^‡c½/�õÎwÓ?jûs}·4ŸÞú|Ï@^f&ßðÄÌØ»
+(¼%9FG¿î”ĵÀ‘š®t˜ÚÑ)¨÷E@~<ÀC
|[g;ئL�»"¶òÄÿ
ÅO‡Ž¨l¸DŠ”?°‡ø˹«^.æ"•AP`Èu–
 endobj
-1189 0 obj <<
+1248 0 obj <<
 /Type /Page
-/Contents 1190 0 R
-/Resources 1188 0 R
+/Contents 1249 0 R
+/Resources 1247 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1182 0 R
-/Annots [ 1192 0 R ]
+/Parent 1237 0 R
+/Annots [ 1251 0 R ]
 >> endobj
-1192 0 obj <<
+1251 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [250.9056 118.4935 324.559 127.9031]
+/Rect [222.5592 220.8351 286.2499 230.2447]
 /Subtype /Link
 /A << /S /GoTo /D (statsfile) >>
 >> endobj
-1191 0 obj <<
-/D [1189 0 R /XYZ 85.0394 794.5015 null]
+1250 0 obj <<
+/D [1248 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1188 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R /F47 879 0 R >>
+1247 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F39 885 0 R /F23 726 0 R /F41 925 0 R /F48 940 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1196 0 obj <<
-/Length 3429      
-/Filter /FlateDecode
->>
-stream
-xÚ¥]sÛ6òÝ¿BÓ'y&B	 Áé“›8½ôçÎvîcÚ>Ð$dqB‘ªHÙñÝÜ¿]ì‚"%JÎÍ%3æX‹Å~¯ä,€ÿr¦c§a:KR%t õ,__³G˜ûéB2ÎÂ#-†X?Þ_|ÿ>Jf©Hã0žÝ/k#g÷ůóX„âVæo?ݼÿðÓçÛ«ËDÍï?|º¹\„:˜¿ÿðË5A?Ý^}üxu{¹�FËùÛ?]ýåþú–¦b^ãÇ7ïh$¥Ç‰Eo¯ß_ß^ß¼½¾üýþç‹ëûþ,ÃóÊ ÂƒüqñëïÁ¬€cÿ|ˆ(5zö/��iÎÖJGB«(ò#ÕÅÝÅ_û³îÓ)þ)m„UœŒD¤âpšËR$RR¢¤�ZG=—C9Åe�…\ÞfuѬ…}*s{xf*‘ĉœ
>ھǚØ?ì/ÃT$ʨ1
÷+÷–ó¶Ùm/¥™çüÞ,éiëÎ�7›èz>0⮵�xŒ~M»}²[¼aƒ®+[zn¶å:Û–×Ö~Õe³%àÝÍÝÝõ[dÜŒR�l)Eª5‰l³±Û¬+›º}s¹ˆd8owù
-  ˜g-=ïÿ|ýO‚:`}›å‰Kçp4U¼ÔÙºÌée·)²ÎŒ<Ág[>Ö–‘ÿÕÔ¶…ã)�3KÞ§ÙðÂ}córá<Å¡£ø· -bIE\C€…
àt€çÇqD®,ŒHz_+×ôö¼*Ýaá#¼!ró6+èmx‘RJ¼0	óK¿}É„øgæIÀm‘£Q0`ñp‹?v嶬�÷™8òsYUÀï.6+z^Ù!ILÀ!Ú•àÞÎ>\ʹõ¨öë*Ûµ�-à QBAìºéplw.Þàˆö«K`ñ2ÛUŒ÷”U;Þ	Ž$ƒyLŠ©D(4�;À÷p?ß“ÞòHËb#Œ€¯×ÝI¬Ô"UJ�EYûÏè^C•zn
-i¢yU¢®Z÷²±¡„_š)º‚,Ì0Êêã¼�]—]¿Òƒ]òñ"(Ì4õHZ	ƒeÍÛzZ²¢`{
-fW¤:¿¡x¡yéjm¾—*4àNPè
°}
-@»
ËæIäqno-¢EfF“?Ä'+ëÒËhVóÒÌ-8nÝ|º¹Föœ³
-nÓÉS‰XFòä|<]ásÙ­üý²Lm†âf¿æÕ®àûF�½Ï�Ä©[ð¦é¥m¼ñ¢3¸•{�ÊÙž
Þ”U/{±²â‘Åö·0Tï®ñïžð—Ë4œÿí`ðóþ=0�8ôñóÝõç�õ’zàá<Q TÊ�‡
-îñ]a¿û�Áê©wm®!øÜ­ýë~`›0ÞšH¤É)…SFb
-ðŠ]b�V¸·,Ê6{¨ì"«›-Èͺ=R7
-ú<
=Ö#uÃ@EI3¦âQ
·s�ÆÑÐÒÓG×nr@°›s.ŸNH
-•]v4Äk¨ùËçØaæiæ.)äû<D*%‚Ðèƒ@‘ñY�¯ˆ§	+7q—Y»ÙX*$”\ï¯6¦íqíã{äŒPÞ‘û¥±±ÀœÚykyv·nƒ’1RÉÂT²Tä õ£{&ÉefÚ	¹
-
0ÜËì+TÇýºí	±M\dÒ–ë²Ê¶.dÃå›ÕxÎxÆwšOEc)„›�æÞl{\=ñ,Ò8p!_ûtÐÇîÞŠïåç¤!�$ÒAôJx>Ä:mÈ{¬�R­QìàÝöØšëThXæ<=Ö#k+¡“D�	¹C«±D�
-“ùª´[òš9€-
r­	A$— ÇÃ�L“›Éx	Š`îhÞ‡^J¨¤†ïd&
-ÆõWç0#¨§¶/´qîò
-¹ûèXÍSûV³!”ë†@[s)Û+›!ÑÐÜet·j×
…!o´Ù—vÜ8@¸Š�¤�¨¤€‡�áXÙÒÃD{P^ž§/¿y3á*Êvd­¿s„ŸnSHAP%¯ˆÂ
+1255 0 obj <<
+/Length 3390      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥]s£Fòݿ•—ÈUa`€¡ò䬽9'YûÎÖ^.•ä
K#‹ZŠ@v|W÷߯¿�„äMÝn•fšéžþî©ó
+HS¯dÄg �;[èkØŽ
‚—¸àÊúO¢°¿…¡¾ºÆ¿ïd†?]dáäŸ{“Ÿð¯;Í|·ðñÓÃõ§�8êtô›º¯\pžHùÊ:³
+s%òÖÊêvÝG�€y	P!ÊTˆVÌ@ÝrfÍfÚ•RÒ?Eé>Nw:ûÕI·osDmSJEšbU”ù†r4ܾÞ3�—\VÜ÷Çù4¯-çl#ÚܹjG
+¸
—v>ŠÕ|ŽÊb²ç9Ù>qÄ9*ŽòÙÌ®[WÍ‹Ý4ü‚V‰O؉@“]ª�Ó»ãû\M�’ÆX…²ª#^pŒxq¬8vŽÇ=ÇJüAt�DC�ÁÚu¦97*ª'|‹&r“0
åSO�踀pdç0ùè‰]”b¥Zq�pƒT
»
+l�aîâ ªù®®KëjÍ;)´Ž¸ªHC© Þ¨dz@Ç•"ÝضK¯úSÄtЗÒ~šÀùOá»R™Ÿj¨)ûØG�à¢ø¯™z*±–(0.MØÏW!
Ô©K?//Çö5~œ(òèq—®•ÝdL�‘Õ’�ÝþëêîãåÍm?Üq¯©í³K	]¤—¨‰)öæÙn:l’ã(?LM:´eö¿&CÕÛ‚-¿ÊˆK§I%©¤Cú[°¾ëo#ö¸®À§&N¾ÜK}ë¸M±�¸gÎ�Ù2¯ž,£\p¶¿âi/ÃÈ¡‰t'³Ék½•=v-Ãb89,ÜèÛyÌŸôN{Ñ£.ç]Þàš0‹öE¶“þcÁ:0—Ê°²ûIÄ.ÓØ5
G¸†
wÓU¥§ÔÕÌÑ\òY?Uú�J²uÜÄ;(rt�þb¯WWžý³h«I(ÝÃ8;MC5BÄð¼ÔÔ‡TL—.g㎒ÔÛT
+Ä
+dì$PÈÒîÂ0jwÍC[IçVgK;ûÌ
+oÑH¶vUsëWA�‘vÈ+×Ë+Zj(FÄ <QáP¥ä
+réc7{Ý„þyºV›sÔ7¶ kµÿÞ×ú1°ï
}èA�ÐEqÌ®°}R4m1;l[A]Ÿe‰>�¾ƒÁ?ôúÀÈ4M‡üŒ—Bà­��Ŭ°=,”jG½;±sÆL1Hþ�9ÛS°øø:âþÃÀø)yàÉv#	
+ºâ yA—EÐ$ëFNýÑ€Z¢¼à®;p®á)LGðÝ•8ýèàí
+9W÷±Àn >XH•„ÙøÆmÍÓÈkŒ9sKŠF>6JüX§{ Bñ¢8FMüŒ)“	�
+â,vCh@µCœLãöiÙò‚ûaø"Ý]üR¤§¢³§ú`vy	}A!
+GÂJpS`ä ‰^¸DÍ+Ül^ÐöxˆÌªÚ±n�˜
+"RT9‰½20EÅ<™»4C÷‰NÍ'篫àØH‡FIÛmø&ñ-ÄF
+‡Ò§ö°‘„
+âC`D~ÎÄÔÀ…Ç*oZ*Mø¡Uæªíþ]k\‹�gù.>WÝv¾½›Þ|ø…Çl‚lm#0äÖí³CSæÏb©{þ	[�bFÜcôtž;CÿµÅò0JЋ§'¢69à@¸�P,-Фq\mW�”rvÞŽ|eÿk¢Œ‡HÊ=}ÂÙA‚×
_:z
+f‹ü¼Æ]fvåM§2‚¬_²÷¹Õ«³ÜÎ�꺒©—VUÿ×3.yt�­¡�êjbç
YäM¿@Þ€½,Ò	|�¥ÒoA8Ǭ†Í5 �³˜º,];šÚ«LùQÚ¥�UÝ"F¬$ðU’¼é+¢8uU:1ïè~*ÖÇ3Y×n‹}üýÙH>t•ÿûgn»ß
 endobj
-1195 0 obj <<
+1254 0 obj <<
 /Type /Page
-/Contents 1196 0 R
-/Resources 1194 0 R
+/Contents 1255 0 R
+/Resources 1253 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1182 0 R
+/Parent 1237 0 R
 >> endobj
-1197 0 obj <<
-/D [1195 0 R /XYZ 56.6929 794.5015 null]
+1256 0 obj <<
+/D [1254 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 350 0 obj <<
-/D [1195 0 R /XYZ 56.6929 293.8263 null]
+/D [1254 0 R /XYZ 85.0394 396.2024 null]
 >> endobj
-1005 0 obj <<
-/D [1195 0 R /XYZ 56.6929 268.1652 null]
+1060 0 obj <<
+/D [1254 0 R /XYZ 85.0394 369.4308 null]
 >> endobj
-1194 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F48 885 0 R >>
+1253 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R /F48 940 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1200 0 obj <<
-/Length 3311      
+1259 0 obj <<
+/Length 3376      
 /Filter /FlateDecode
 >>
 stream
-xÚÍ]sã¶ñÝ¿Âo•gŽñE�—‹}u¦çkg:i’Z¢,6©ˆ”}î¯ï.vA‘%]Ó›é�Çøvû
ˆËþÄ¥5q¢œ¾ÌœŽM"Ìåtu‘\>Á»÷‚q¢€õ±¾}¸øæFe—.v©L/æ½¹lœX+.f¿LÞýõíß®ï¯"i’I_E&M&ßÞÞ}G#Žï>ÞÝܾÿéþíU¦'·ïhøþúæúþúîÝõU$¬ð½äŽ|psû·k‚Þß¿ýðáíýÕoß_\?t¼ôù‰BFþ¸øå·ärl‘ÄÊYsù?’X8'/WÚ¨Øh¥ÂÈòâÇ‹º	{oý§cò3ÊÆÆÊlD€Rõ(€uz™§
-^¡
-þ]W•
=sz¬ò¦-6;¤7W‘?¬ö¦hŠÍsÀ|)—Ë0Zͪ·í`æ»�·7?¼¹vRü±-ÆikÆ
óì–YæÏEƒ[
-ㆩߟû*ÒºG) ï˜‹Á°颎©(M¸ÉLI,¥�eó¤	äŸN‘7›AÚäHoUÏ|Ò¦ÍiI«D(R¤5é–ÈTv€µsiý}
�+	¾ÏÁÿ&”¿�tü
¦'¦'g1&gã$dð6eo:b
-_ìÞûo¦ù¶ñkpë-ëõê,7–ì$oÛbµnûÝ&K+r¯)Íb«ÜP'ˆé,LM½õÀt0:­ý»
-æúX^ÕЗY9TŒ¼zå°ÉØýŽMÙÍþ¡—À�F�ôü±K*”îêæ{²ï„�S§Å.Ë)Ê™…3
W%6Ö:;ã”ûX't,`ù]\,gÑtYU{�ôAˆŒ&'	è°F(0EdWbHŸÁeiç™~Éy°¼“
-\kRë{Î8¾Z/‹íûÝ8À_’A#„Ñ['|œàQÂœOUÝù	x„E^÷?wxHhíäáÊ�j’îi¨â¦åÝ£¾û®1ê
lyV³‚Û¬E—¨Ñop|#Ê&Q.]š6²9{*e¸UB÷*ìóÇ	aNLh9iÖÅÔŸHn_êÐ^盼åaÚ—QëÐØ}Aóm»ˆªO³z•—c
ÁU@‚½w 2N¶Lb-;»;u béf>• Y¦SbLXP!u²:Ö"ÓÚ„^r	ñ­ÈgG�RBÁ�juÆñ÷±Že‡å÷½nÚ¨i!OkÚrzh”ÌȦú4
ÖC£„­H³lH‚Ï€ŒèEGŸ
-Ra€(ýå
->“iîO-ñÓgJ~
Df‡%‘ØAcˆá©BN°?Lȧ|Di'Rd{g&e»`oŠ¥�ËðÕAp|·EgXÐ�ÞíÖ‰ÝXH)ÚJÿQù‰ÚÑcÞæÈ`ê.Õ§ÉH‡dèlàdÈf�Ž�Zé]†0�©]3’ÑÚØd‰ëbX¤¤˜Ü¶ô½÷ãpž‹SòÔAêPfÑtWACT†ý]•º5¦œ ú‘Ó£ÝäU*
-H¨0™æl~­k¨ôÁ¢xöÛùØ•‰×zÒÔ ÅáŠ_ñ-ŒmûTïúü
’£–y'mÛfô,=u18”ÐXoðúJAj;r.ySÿ|÷hò#Î%?Xf9—œñ³}¬ã–×ayË+«r•/£
W‡ž6
-!(Ÿ&¡Ã¡aˆÓØb>8 âv>"<9§M?#¬Û^X7Y¸øaL¨Ó
-̦i¬2e‡$ðŽ¹^?`Š.
±
-†J~Å® K(^×�¡xÒƒ³_�Åù‹3~褘N„ùîîí‡k2¨’´Äjª¯c‡'Q'å乬©«GÃ^£d¸ËÔt”x[ì,ç9¼
t)¼¯ÃT/ù`¡|ù’¿6aŽMIe¾)ªyÍ=¥foÕKÉ>/v²í2ÇǺ]Ó±p­a(¸e‡Ú5mf¯ ÙrÊÑj�—ÏšøØÍ[eb¼.;¢EÉåٮϽ•»»²%¢²öȽ•@�.D¡8tvpÖ®ï’þ§ÿÛendstream
+xÚÍ]sÛ6òÝ¿Bo•gB” ><¦©“sçâ\wnz½>Ðeñ*‘ªHÙñýúÛÅ)Rt.—™Ëx<Z`w±ß$ŸÅðÇgJ3m;K­d*æj¶Ø^ij˜{wÁ=N�¢.Öwß¿éÌ2«=»[uö2,6†Ïî–¿Í5KØ%ìÏß|¸y{ýî—Û×—©œß]¸¹ŒÏß^ÿõŠ w·¯ß¿}{q£øüÍ_^ÿíîê–¦´ßã‡ë›iÄÒÏ™Mo¯Þ^Ý^ݼ¹ºüý«»–—.¿<ÈÈŸ¿ýÏ–ÀöO1Ö¨Ù<ÄŒ[›Ì¶R	¦¤adsññâçvÃά[:*?³DèdD€‰èÐp¦¬U³TY¦L¡
+CñAF—*™¶‘ÊËç(2¿lTT"¾aQqÒ
+ÒËét¡/­½š’V‡ŽoØ,cͬ� 4--(	TÊÅ!ÿEåš0Ãß®n)«X™ð´´T”šë—2½3ÒúŸÕ%ã–,N¥|AX�%jÍ»‰ó—‹l»Ô|-™‹èÿG.Äm
+UVfÌhaºµü ¦Olâv·¢ Þñ„O×ôJà=¦8|S59%"Íú˜’S�nxšžãXÑ&¡~q¶B¤U¾h°¾Ã‘ûç±zj!¨wÃuû¤k¨(€4
EÝ wUœ¥œëyÆ…<×ô ¤¨‹5ÔÚÐ�i±\ û#�
+¬-9��¶DˆéÃ[¬‘Ó{¹ÇLOêþñ×X¶CÚã»MFÎ
VÂu9ÑÃ\µóå=Ìæ%Kš¨‹ía“5tWFù–	`U÷uµÉÝÅÃð�7	 .Fó¼ó³×?ÿru{	‰ë¯—œs¸�=jn}),XŸTFeN�¬XªP­tösÏ�Ȫ<{¹Rƒ
i1}·¤óW�ÜÍæÍb=lùðb¦H§n‘†'÷®5N™Ž;LàÑwtwÚï6aÌ߈�
+À°9@f´O
õ¥4mÝØáò€øLÆþY(ìº5‹ìP;Ý�3|{-íôãŒo™yÖ4ùv×t;J†Nôý$�2#l¿9@´$Öø¨®XôF•ûÅJ‹†~—ŲüÎÃkê-ä›j
+ܳðB¸®OK3­f]¬ójÖb¹F\\l–ÑbSäe3Høx"@¸œ& Å¡ Çl‚¹<ä©=ȪEª[çŒðSæЪ¼”פƵ–q|»Ûä[ ÚµµqÀ¯$›FC·Œý[‡ö|(«ÖUˆTQK¼·Ö‚ªhcæw—ô’O¦,æ‚Ÿ(õÖ�ÍO`[³\澕š·9=ƒãÑ4�Ž”m†6r3'ú¥
8}�z<Ñ¢¯S™8™×»|�5zŸäæ©
+�ß]¶Ï?L—2j;¬<(ovhÖQùiYm³bÌ@98‹í‰ÝŽ“�ÄL&"°ÖöwûÇ[ˆ¥i0Ìýj‘ˆØD˜Hñ1aa¦.'MQ‚øUèßòlyÞ"cY£á/XdkÂ"–»÷ªn¢º�­nŠÅÐ"Ñ©`'d’€k„‚¾E‚å‚{ë“à2 Å;ÑÑ%ÁŠ‡$ J|}€ü#ÏwÞçrŠêðÛáÁ!­Ü›I\úHi/€Èl¿òoV\,†ã·
+9Àî…A¶ ‹
+Úþ…Ú¾z„Œšwäí¤MÝ·¸_žû$<&_6m{¬	ÛXÎöŠ²Øf›hïkŽ¡¯•‚)
Ió$	-Ö
ýø†"Ó´OÄõjDxRN£?#°›N`Wiø¼C©P©
ô
+Ù
äˆ=ü}ÙN'`ŠV‡HC…ŸòŽ C(NÓá1Ûl\AúñÙ¯ÃòùŒüÐIQ­óÍÍë÷Wd* 2	Õm_Ææ–¢.Iæ�EEý<vú”„ïµ`€Ú�	~V–ù=œ´)Ì‚Ïñ”OYï ló”=×a�}A5Îäåªò=¥úäÔ#Kñ)/f~h3ÇûªY÷Ó±m‰·oÁ@µ�´¨mÓfù’->Víð³ú¼Çœ�/}¡QÝÅšPã€ÕÏÙ=ÖHȨŒ™>6 �ÛK¬°À‰yÿØÑx�ªÔNŒ„3Å•é¼ì§^Žný
+:8ìʘ”tF¨ÎW[º÷u̴ΧjÈ+"¿ìh€Ò„è<eÛ0ƒƒEØî@ñ€¼/µ¸-S‰<Iã\Î&b1_¬³Ò}B>#×0i›O´”(G®áEsû‡
·]—УþˆK9݉úºšH˜dü”(ºéKÑÎÖÃ×J
iš€Á^>ë–ÚP¤@:Wwâ"Nù«Š)ßÆéfÝNá½Ôô°�Ú͵G
+É—fèsýÇÎCÒÿù§3†endstream
 endobj
-1199 0 obj <<
+1258 0 obj <<
 /Type /Page
-/Contents 1200 0 R
-/Resources 1198 0 R
+/Contents 1259 0 R
+/Resources 1257 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1182 0 R
+/Parent 1237 0 R
+/Annots [ 1263 0 R ]
 >> endobj
-1201 0 obj <<
-/D [1199 0 R /XYZ 85.0394 794.5015 null]
+1263 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [154.2681 85.4256 203.5396 97.4853]
+/Subtype /Link
+/A << /S /GoTo /D (notify) >>
 >> endobj
-1202 0 obj <<
-/D [1199 0 R /XYZ 85.0394 625.316 null]
+1260 0 obj <<
+/D [1258 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1203 0 obj <<
-/D [1199 0 R /XYZ 85.0394 613.3608 null]
+1261 0 obj <<
+/D [1258 0 R /XYZ 56.6929 679.1143 null]
 >> endobj
-1198 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F48 885 0 R /F47 879 0 R >>
+1262 0 obj <<
+/D [1258 0 R /XYZ 56.6929 667.1591 null]
+>> endobj
+1257 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F48 940 0 R /F39 885 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1206 0 obj <<
-/Length 3763      
-/Filter /FlateDecode
->>
-stream
-xÚ­]sÛ6òÝ¿Bo•g"Ÿ$0÷”&NÏ7çÎqçzÓö�¦(‹ŠTE*®ï×ß. H‘’Üi'3&,v‹Å~
á3ÿøLÇQl…�%VEšq=Ë6Wlöc?\q³@‹>Ô÷Wo?Êdf#‹xö°êá23†Ï–?ÏãHD×€�Íß¾ûxûÃ�÷ï®5¸ý|w½šÍ?Þþó†Z?Ü¿ûôéÝýõ‚Íçïÿþî_7÷4{ßßÞ} KŸHïo>ÞÜßܽ¿¹þõáW7ÝZúëåLâB~»úùW6[²ÿqÅ"i�ž=ÃqkÅls¥´Œ´’2ô”W_®þÝ!ì�º©SòSÚDZ¨x¶�*2@ZÊ<J8 DÛ(–BvR|JÊ

-¥\Õm±z9^¬Q‘Œ�™õŽÈ 	²²GÖØHÂÖÉÞ®�äÛ�Êô 9‹„N,`G�—¼!˜
6Á#͵ñ0¿0ÍÚu~½�°ÅË|•îËúøè1ÉüÃÝhh;¿ûüpûñ¿¶É›&}än$Ý]s3÷š¼j©õ¼Î+@ÿ«+Dô`¤Éwßòu
ݾ]×»¢MÛâ[ŽìÃÎYÜB9[pY­…c|UãD&çÙ:­€d˜k@™o×:±R³D%Qœ$¥Lƒ»§5î{»ÒÁ/úÆÛ2Æ‹|}ɳ¶¨+â
ý˜Á)mùH3:¨<Œ±!pbUlæNÎÀFoØèmù
ƒV[Óp»î†pwúQM›/	¢ð«ë qk¿óØ�Â@Éj÷]6´“\°È*i†[‰:˜ÿžå[äD*�›ˆî¨Ýé
-´‹%p]ü˜p,aOu4õËçwÔøt÷îÓ
5Ý„rÔ[ëyZùùnñðM«—>¹†~t‹?¢D‡«o!XXmDZ6õâ` Ž6­ŽÒÚŸÄz‹z‘ ÂØãì¥8}ämd’$ñ8H`‹º*§èÅ:J´TE ­3_N0¸VÑ×Áç‘ëöz}tð «ÛèD
hÐQuÂ2¡Ñ7`õ‰xþû¶,²¢�àÙ–ü
.o¢ã—㆒íà	ÚÌá¶t›‹þ*°‚3ñwØllzšØf.ˆ2	¢<¿ÍÊ‚QVÁàFh§Ø	!)ØuðUÌ;–	dáÜtÒA6
ÒRÂß�”ðJÉk—`1ø;1Ô®‡I…†®:–N¬Qr
-jàjùR
@Z5ÏŽæý26hiœs4„Â:oáË"Niaè ËLy¡…è{º•B{Y;­…a8{~BI¨Óå�|­êç#®<«�Ç EårNžéØ�{9
-ã¹õÇ
~§ýî˜�t
-CIÏßz¢�Î…b£iI
K{D½iã¿

	ÁÀ±ˆ$z\á*§¬ð«Þæ»´%³" êjöà$'ÎAêã‹�ºXc¹ôºî˺þºß6>Þù’û0Ä…
SÎ=Ž¬AWy›­Oå~ÊÅ+)liúîú¤ÒÂFLšø¼êC�vA”;#«LHfíË6åxŽ$ã±<O¾ƒš ?8ß�±[›ÄC¾„Ó!Yâ¼kÕf$†¸2¾à¡0336ÈŸ,"tQA ’“vv¹t_/—Ô¢0e€njZÖ�éç¢]'>k°áÜ�<ÆW‰�¨¸à7¢š
©™³èAûÈäjÖ3¹š�0¹Ú‚VXþú |¤|`MµµôT�e¶¯ªtIã
-wfºÒç/�›Åú4.šÇ
- �3ùÆL‰$Ò‰[Ëì·øe­$˜^Û­ô 
×ñöv#fjXϬ¿$�wÑCìV‹Á9’�
-*9SREÕ‘þÜ9‡•˜ù˵€dÐÿ(6ÛÒådã�Kð뫠в£}W1dzÆšY_²n³$ìBl!m^jœN• 芌ÁS$À*$üBtŽÈ8
-ð¬iì P¢`/År±­ërd„
6¨�vlÔ˜ºJÇ6: ÿ@Éœï.Ù¡³N}�M]æí”[
$JÇGyú¨ê�–ÏéKȯ˲Π{ó?CØÍÛ¾¯@àú hNº,ˆ÷À½Iya_zPgö%@…„y�Ùf
qDÖŒö<€‰AÎ2ÐAMp0tZ:2p֜Ȟb8™4{ŠC’¢{™Žî25Ï겤Aª]¤>³Ò×'?šJY„“ûª¤�Ñ„‚àqa$ôaàŒâò‰ŠsWh6
8�
-…á”>oጅ¯�CÏcÚ¾äúøâë°Huõr¢¡d,zE‘þ;“>Ü€‘<¸¹~Iw¢d"ýø…ÂÕ®l×5°ØêÊÑ�pJËGb„K•)0åJh5Œ7]ÕC'ó4êçâ“Å9F C2S-3š�D§´KÉHY¡ú%5
-D8ÏëP\î7[ê9m|«¦1RGè@ý(sê<Ôò úT9I0p·ŒÛžüH@�o"¯ë¾½’]œwqöT`"ñH%æÂEH)ôá'®§Ž±®Aè
-Q€}Ž¸_ÍÈHÄàÞúÆ6'@]`dŒm2<6TX%§î
;CÛ‡:mh;¨Î
þ–ÿ¸:Åñ™ó„ИðÀ÷ÙËœ|H˜\ŸLu>lw}§]Ÿ‘ä}×ÛÄUf¤aó—zOªÜjª7âwY4é#*;þ¸ýéãýp8¥Ï6Ý�&ïËtGÁ
-ð¹Ï ৻OHÂm ^ä)ÎÝE![ûk@ŽGD³£dQA°IʾÓçÌhˆ�ü:·»ú[±<ìÕñùJ°þ§�jÚ.˜¤¯
-̆èöä…“À}ø‰Û½c¬Ó'kt¬ÀüEqÌõ€�‘¦uP¸cëÅG£¼~ÀGŽC±W‹¥ƒ¿ÄÑïH0*’£ðœë¼ú©tPxc;olå�¢œ·5 3¦ÆMið°
‘��C}Žt4¦=LxAcHûÄ»­oÙu“íŠÞA©WGÐ&êÂø¦<ð>àu•ç^
-)¶»<måDi³h¶i6~Î#,„>–Ÿg£ƒšàc tREZ0=dÄ×?¸}h?§¾Óß“*FA=ôø2
´}\Z
-’w/*à×S^á}	邯$@wê¿wôuKƒï‡Ï_¨±q—;thæ·<¨P<·oèûXc�[žKh�ÚžPéñ•û_M=J€È8½ýËY†õ¼õKЧØHt$“.‰}­WÒ׿hNm–µ>Jªü¹,ªÉ3ƒJ_†ÏÓòå›p»°<rJSµÆ⩪ýÍøi[Ê�qÃ.\Põ¡ÎØÒ
+1266 0 obj <<
+/Length 3662      
+/Filter /FlateDecode
+>>
+stream
+xÚ­ksÛ6ò»…¾=2x’àܧ4qrî\œ;Ç�éMÛ4EÙœP¢"RQ}¿þv±
+exý^™d™$‰
;B¬³¦-va½©^t€4ÖQ¢¥r°¯®C)Ó`S·å¯Œ‰¢�g!‚lwÍMPà,"»Ü›–ÖVõŽ–ˆ-þ·Þ
nˆPólrÔ²ažxñû¶*ó²�áR%‘,ù\zÞDÇ/ÚQ/BÉT ¨žó(ÕZX¬M±ûVì²Ï~ŠÏU	r-i¾oÊÍ“c’÷Å‘t™hÇeV5uˆ<®æô®ÒHhå%-IÎNhIE‰ê 7õ2ƒÕƒl¤�jÂçNMø€jŠH+‚ÅQÂ(%�d¬,ª‡çbFPÁ¢XpÕqtBDÉ
Œy®êm[Ö�3�ÁJ^h‚:¢ÙcAc³-rbw‰:(Ý7í,+ìW$ÜëMn†¡#-¥ç¤i³¶Xƒà (%EGáð\æÏ4ͳÆñS¶4Ö`»rimí$7¡P2b*Y‰Žê7éiuÅ	ìó˜E0%âඥ�õ¾ZÒ”ÌZcUg1yÑ4Ùî…Ûš^·ûÝÆ}²Â�_¹×Ï¥ãÈï—îméæÙ¾±vïš*ûV4rk4Äô@Ú|—5ÏÑij²ˆipúq2òD$q@aŠ!Ÿ‰$ÔÑö›:Sç°/\3sž|5CpÜ”‰8ú�
³‡×€zRox/ ½ã¡;׶ÄMc¥¡Iþ\ä_pšZ›£—Ùº8z+X@Ʊƒ¸ûLãý}S´ôuö”•›¦
~þô†&ïÞ|¼‰Ü×õn�U.@1D!†›œ
$øÖ»O·ïÿCó5ßSAÖ¶`$9ºX!„$»„â
&ÄL,4ý•iÖ­º¿ýp{Kœž3‡¼l‡Äšýv[“¹"þšèå5PæAf•„ôéè‚ÂCï7­ý€R
@ÆxLìHÊ$ØWm¹†IË.ÄAb�^›éàs½.
+µ+òý®AG;öM²tgIwP3´¾I
+Èm؈ø‰,QŸõM�(¥R˜^ÞÅ„³�TX³NyðÎjž¿î|`J9,4mCP´âtà0ÁÞlžv).£Od5H©…p¸miÙ,.ÝH†�/<’C½ûBÎKcVž˜¡}yæJš 4LZ&A¼æ`9À5ò“ʉÆ9ÇC/R›ÐÚ±�=Ûðêná�”Æäe')Ì—µµvxí?|PêlùBo¾lêÈ+Ǫs4\”<�]›Ó£0Ž[—ÀsÖ_^A†“

+B=¨3AÈCÙ3²Ê…d&l_¶Ÿ&É
+?‘œ'ßAÍÐœop½R�èö‡C²ÄU vVÏ8‘êÞ˜éK¹sjR¯~òsˆÐ–-žJAÆéíÈ´#e#8Æ£óçµ—
}šUµgúP¶ÏÄ	åh6ü–üqÄU’O™í—ئxÓýæ­Ìúso|>s9:\Ìkf®N¡vï
+�3MÑ9Üñî»î’ÉÐéwô¾¤±­<3ßû‚ã—ð(f±>�‹¾c€ËMýCT¡ç.”&Žt"Ò¾ÑušE!u•,”RðAJ'ÿ®§+NÝ´HËîä~ºc<ÀÜLTH¥Ðf¡‹wÄ_~TšJ‚êÍ­´G-Ø…×·k±xWƒL‹¾XsØGmåŠÅ`ADÃ�ƒ$2�Ú‘XµKÅ_®
+÷P®·•í£ßµUa–Nv_¥Ø‹å¢¯ß?·eÒ
+õ	>#,—ᶮ«‰	ÈÐÊtÑG;õ�jJû

äÁbä¨#g¼ëÈÐy§µÇ¦®Šv.²€Ò”ŽÍ°—8i¢gÕ!{iºZªÎ¡ds�>q‡éí;·ÖË!ðP5'£–„íÑüRk§uf_<”ïê…؃ò®Ì›iÜJ#ÁŒ8Ï@5ÃÁ0naS:ÕCNP1ò;²Ü~ãšùê>Õ½bGwÅŽ‚Š½ª(
B/¶Ív`Áey)&…4ºúGSÃ�p`ÿd¿©(­A4¾­šÛÆŽ]Ã2ÀúÄåj³à@'Žæ {²½[,�h€œ¿mÇÕ®<f
Ås˜¾Ðh©®^N´ËÁ§A}*z­Ûþ&[³�Ò~#¹�u¥ãk¾#+Lðía…,÷^±á„ý×8ÅPÜ81Ç,bšKýsðœJh9Œô¶9«“ ˱9K͉øäœÞ\v›eN_#Ñ9óR2R©PýÆ¿ñ}lüÎP\î×[ZE­Ý¬¦w®E’h UA‹Ç^Jâz)§ºÞb’`¼¯?RPèðÍÔa�6Ǻï±d—lÇ]²=—žˆTF±²~•^íž\�½ÿ0“.ôÀO_¨y ÊPó£ï…
� MxÁˆ§”è33õ7èc\³É™÷ž"` Æœw±}¨Ó.¶ƒêBßïàó'©„Üjì³”;¨)éa܃“f’4Ò¦¸'“ãMλµÓq/$<îÝ¡Åib3Ò0j^"‚Ma¯’ºÁqY6Ù#Ú9>Üþüþ~ø:£a›íÀˆ÷U¶#„à
+
?ÝÝþìØ}�Rm=wåánÑRt?û‚§§bƒw&d®“
+ƒq“‰³ìu@Sþ†EŒ€ú
kŸAß
+JÕñw}Òví6äk¼ƒJÝE?¾y,ž³o¥­Sû«
 endobj
-1205 0 obj <<
+1265 0 obj <<
 /Type /Page
-/Contents 1206 0 R
-/Resources 1204 0 R
+/Contents 1266 0 R
+/Resources 1264 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1182 0 R
-/Annots [ 1208 0 R 1209 0 R 1210 0 R 1211 0 R 1212 0 R 1213 0 R ]
->> endobj
-1208 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [154.2681 743.8714 203.5396 755.9311]
-/Subtype /Link
-/A << /S /GoTo /D (notify) >>
+/Parent 1273 0 R
+/Annots [ 1268 0 R 1269 0 R 1270 0 R 1271 0 R 1272 0 R ]
 >> endobj
-1209 0 obj <<
+1268 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [80.6033 320.3921 154.2566 329.6075]
+/Rect [108.9497 292.4924 172.6404 301.7078]
 /Subtype /Link
 /A << /S /GoTo /D (statsfile) >>
 >> endobj
-1210 0 obj <<
+1269 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [265.4578 275.0376 326.6578 287.0973]
+/Rect [293.8042 246.568 355.0043 258.6276]
 /Subtype /Link
 /A << /S /GoTo /D (server_statement_definition_and_usage) >>
 >> endobj
-1211 0 obj <<
+1270 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [367.5441 275.0376 416.2908 287.0973]
+/Rect [395.8905 246.568 444.6373 258.6276]
 /Subtype /Link
 /A << /S /GoTo /D (incremental_zone_transfers) >>
 >> endobj
-1212 0 obj <<
+1271 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [280.9692 244.2883 342.1692 256.348]
+/Rect [309.3157 215.2488 370.5157 227.3084]
 /Subtype /Link
 /A << /S /GoTo /D (server_statement_definition_and_usage) >>
 >> endobj
-1213 0 obj <<
+1272 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [277.6219 213.539 338.8219 225.5987]
+/Rect [305.9683 183.9296 367.1684 195.9892]
 /Subtype /Link
 /A << /S /GoTo /D (server_statement_definition_and_usage) >>
 >> endobj
-1207 0 obj <<
-/D [1205 0 R /XYZ 56.6929 794.5015 null]
+1267 0 obj <<
+/D [1265 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1204 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F48 885 0 R /F62 995 0 R /F47 879 0 R /F14 685 0 R >>
-/XObject << /Im2 984 0 R >>
+1264 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F48 940 0 R /F21 702 0 R /F62 1050 0 R /F39 885 0 R /F14 729 0 R >>
+/XObject << /Im2 1039 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1217 0 obj <<
-/Length 3807      
-/Filter /FlateDecode
->>
-stream
-xÚ¥]sÛ6òÝ¿ÂoGÏT<àøè¦N/�6Í%ÎôfÚ>ÐeñB‘ªHÚq}÷ )ÑÎåj?X,€Åb¿!uÁ¿º´I™<¾Ìò8L"•\®÷Ñå=Œ}¡gå�VS¬oo/þùÚd—y˜§:½¼ÝNÖ²ad­º¼Ýü¼ú×õ»Û›÷W+�DA^­’4
-¾}óö;†äüyõóÛ×o¾ÿøþú*‹ƒÛ7?¿eðû›×7ïoÞ¾º¹Z)›(˜¯e…g&¼~óã
·¾ýÓO×ï¯~¿ýáâæÖŸez^<È¿þ]nàØ?\D¡Émrù�(Ty®/÷qbÂ$6ÆAê‹ÿöNFiêÿcÃÄêl��ÚL¨"hÇée–äaj`ø[éº.7p¬<ª¿6ºª¹gЦèn�WÊížám¿+�<Pý®=V}ÑW%�þÙ6e'£�,>�o˜Îàu±Þ•À÷8I‚7
úv/£]Õ°nÛtnZÕ	­rX°R*Ì“DÓy†fSvÕ±¸«Ëo®V&2A7¬w8CÍ4Áã®lBg
-ï·”þÝ#M¼ÂKîÝp•(�ű¯Ê.Ťip]w-Cƒ*mµaÑHÝÂô®,h:1ú[8îì(¬¬rwV#µ^jQc_9!ƒ‘ǪXw(‰<
-m×U .?ʦ“!ºª32tðÇPáÜK×з¬ø|Q][Ó¥
-lœ­ØHÞuz±E(ˆ
♞¸YtŸ:nmÛ+Èì¢áïOÿá¯Hvë×Úº­vm×#)`›ó‰iÑÆ„™Í3 )Û¶m(D…kPxš0³ELPj¾PN‚‹»7pßsZ�öÁá‰	X�1ÁRÆó+ûMëx�Ö8Ì­2²3:�¢@EüÝUíIoÊ~�teÙ4—p¢_M{ÜuMÜŽÜ!èJEj:ÌO%Àߢ$º–	|¾(¸†?€+î‰V�²^G¡Î”P3£_˜“¤!˜|=gÎòÙ`­(5V]T10|O dSáûXÖ5²A+@}jÚÇF`å™\€‚«îÑN(2¨O²Œ7ÃÐiÚž•Ÿ##S¡"
-ÚLÅ^…PÞeõ©lx(×ÕöIÄuah:ãx,×ñó"‹›&6ÌàÞçzÈ나�[ò­ÌÙ„
Õ}Óz
d>ˆYd^–͹8jO"Ö
-u{/ñ‡Å±áX
:{°~Å}¹$K^bFlC«¼±%~µ=¶û…X°A¬Ÿ¹•…*UÎ:k&É@㌉ÂÆN	¡ÁƒE	Ó‘Ùn½ 5n9VËXÔä˜5“بÒ$̳=du5)r®ý4P…ˆÒP\Êâ‚-Xq1‰§Æ°�D Í õÅœlbjrPS´B8TÉêC'@ ŸH13ÝÿFˆðF‹&7ný%�ZÒB]DÐ(Jíi¸sIcô´=ÅBÆ‹”‰‘KøH,€®ß
‹öËÎ9Ÿ‚ýNSìÅ¡x•Dÿä~š•…Š÷PÒ�
-ž
-&AêV„Üg ˜KLð!é,6¦JÂëVâ’�îвS±’wå.‹ˆKÒdf¿c„÷7¯?~¸ù.d8>š¸si™=Lrñ‹"Ȫ7¦jp{136g¼³BÏ{²JS{';Ä?†ÑÚR¤ÕO,žO3‡ž=ÿHÒìdxVx‚x7±X/RaÇËu6ÁYM�¸J¤Êl‰³Š~½[í‹Ã¡Ü¬0�
8MžÒ £(Lmœ¿H„G:§bžˆ$� BD3%ãÍ–¥1¶³h)ÔƉòSudanô$Ù4–r
-ò©–m@’oÞ=ÄrH
-­xŠÎH
-@®jm>»ºêÐD
-ÍK·‰´x»] É¶$šT¡H]8*€q<#LÈÀúZ7
X�É9
-bB@Ç
w̆º¯öŽЙíP/Ù:ÑŒöNW%nB¢
�«føÌÍî	tßQ))eÅèc{üÄ-ÖÎî©ÏŸOå±)kn£â¶xYh‘2wž€˜[·¯ÞÉpÛ4\DY,ì8â8•…¯K‹`�#¸Ñ­$DZl‘’rLX¯Ë×РÇjª$Q"=8¯kן(Ã
-–ú–]h&É4Ø
gNˆr`[5Û‹uG�sÏ‚Ãp<´n�å2.Äæëv8BÆ°yÖÖ™T…&ù‚­› =oëî\}fïξpSm±2P‚õ?3y
-ö‰u”½H‹G:'ff¥€š8Ò3b~ñ|fótŽþ×¼hô´
-ãÜøÄ©Ù°%bë
6ÊG"
-"±)þ厽¹g¡7p’ëyL¿ÛXÊŸ=SSºÉ=Àaý¶=ÇÊ•™PÅÖd¹ÎÈ6�²kÝ»œèžø^¥¨tÆkWÂêÃ…z®ë_ŒN<snCÈ­]…XŠÂy&ád·°_’„‰NRÿÆCjq¾°1¡ÉÓtâòŠË:è̽ð°‹\ÒPGþˆ,rž¹—íŒêë³ÇýlR†N]>”µ´w¿¿g.P?'j…ï‡zóËÿjÆf¡Í´í.‚ìúD
-–µ"R&*Ê¿Èdæ:u»¸'¹9�UhÓ$þ�“é[‚{Ûsÿ&-T|TJÏFÁʦ¡³ðr<Åz>öXÄ�¡î«ÕȇYÜÈâ­}yw�µ°ýü͆i©ùþRÂ
ÓáK8©–ß;(1—Ð�s@ë©g'¿˜P|†Cízt–nöŠÆifê³>o©Æw¹“ìŒA¾â#¨­<¶âCL¬N“™¹u¡_*à[ózÖ–~f‘çËÕ
°:Ræ(oØÉ[ºÍ¨ºá}ÜO*\ʺ§š,wܳ®ôd©d[n°¿ã\D’ãç#¢ÿ±Í?쀅¹ˆOëÉk
°nÕŒLaÇ<þn‘ŠVy8:9¥ÝÄ q´JÖºÜp±þ`¡(dñ÷Ö¾øP'7Ä(Ïë—QaAöö²~M°^Ð/‡ERÑ€4­¥Zr®`y¨•�_ÞÞc-ì?;jã�˲9
7�„Öß½ýðá涱Ôz
-œt᳆“.lOH¢~%_'`‰5ÁÛ¶/ü*ÕŽÓܱôL�NÈJ³0ÉƧc~MÅ� ¦ì¸Ù·Ówñ*2p~í+¸NˆúæõLõK>&>‰EÜïÀJñäàÿë¦ó0²ñß1n®ð•„øãÒ…»�üû7¬ã|ã,4Ö>˜(…ÐŒ”…„Çù)åþÇ®ç¤ÿ"‹™‘endstream
+1277 0 obj <<
+/Length 3827      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥]sÛ6òÝ¿Âo'ÏT,
ðóÑI�ž;mšsœéÍ´} %Èâ…"U‘´âþúÛ/€¤D;—9ûAÀb
,û
ªËþÕeœI®óË4�‚8Tñåjw^>ÂØ�Jp–i9Æzsñý;“^æAžèäò~3Z+Â,S—÷ëßI ƒ+X!\¼ýõý»Û?Ý]_¥Ñâþö×÷WK‡‹w·?ßpëÇ»ë_~¹¾»Zª,V‹·ÿ¼þpsÇC‰¬ñæöýÉùç…EïnÞÝÜݼ{sõçýO7÷þ,ãóªÐàAþºøýÏðr
Çþé"LžÅ—Gè„�Ês}¹»ˆbÄ‘1R]|¼ø—_p4JSgù§Â@›DÏ0P›3Äy_¦q$†��¿mm}µ4J/šnË­fÿÝÖ¶›jÑ컲©[†‡+•-,wZÛ	vƒÜøþ]”�öT)Ò"­¸Û³miB˜VAhò\pþãvæE×vSôU0%{×ki0aõöðÌ�RÈ{°eýè°Û£ejeÚ†zÍNÆû%Òs¹T¹
+t
+¿*ÈãX!ݶ9”]Ñ•O@ŒŽòźè
+
+d…}qèJÛÂ¥˜$Y\WmƒÒ	v¯xjÊ5‹Fâ®0A‰d;@Œ†þŽ;s¹»LO…;SNÈ`Dä`íÞy
+Uó(ñ†Å¡æH
:;0Å£�ób_cF”™J\:0ˆürshvK
+°0ÌÕ/\†J•(g‹„’Æz¬±‘ÓBh0Ç"-�õhd²['Hµ[Žõ2½9fÕäŒ"‰ƒ<ͦ\d}5	r®ùÜïQ…bˆÑP\Êâ‚-Wq19¡
0Eä)qú‹é)ÅÄä ¦”ÁP)«÷­p
+J[°E܇ßQìÅ€)ÅÑ”b
‘á87ªFé Ë¡ýªU5/YÕ¥Ÿ?¹½-ƒq‡ u3B~ŽPL%
æ÷�skŒ%�Gæk.ýh÷
{•LÒ®Ü%ñ
+ãf“ůÓá±f™¸ï4
$‚SJn7sµE*{¾ZY„X 7z”tšŒrr­œ›8]Ü~xŠäœ<
+ÐiY‚õGQÀËN&1‚I�EZÏ<HX8ãO\ÍÌB0ÞòHÁLôò
+œÆ¢Ûó(²æPÙÉÙkΨlÕ<>ò[—Tï"W½‹bbã?Zþ›WÐqw‚m±ÃQì,û°B´Xm‹úÑÊ«B6x�õérve×9
+ÈPÃïR‰¶cú‹�ìƒ"ÑòÄ¢��]�þD$¦µ³±HÌ&Ÿo0 DY¬ õcC½óU½ é‘ µÒmø÷A†Á¯¹Å‘#*HïúòŸrÅ#ôV„>Äø73T(1ÐØn…0û
Di9Ç…c¹¦Ô14BŒ‹<Ìð¢bBÎ]èV�zûᓬPdgw
¥lÐÇÜö;ç7Î÷‰œuá²F”äôHˆôJ…‚ïR¥X~IëЃ’ÖaÃkv¸ä ¹t¥ýõj)2Pò·¯lÇ¥€ØzÓ�žâÈè‘3ÖþS5¦=)ƒŸ q!ÒÓcæÕÈÜÌh %¹,�ó�ðõoË)['Î/qÄåWBCŽeÍÉ0qXQሕàH0w¼ÞÁ½m“|Ïcú݆"Q>s&-�.Oò¯çv·oÅ¡tµ&T®Ù?.6²x�§l÷4'Ê@Õ'¾T©,�ñÚÕ±º`&‰>Qó¯'N9ÏH°½WæÒpžJ4ÙÎlÇA¬ãÄ?õ�Rœ/lL`ò$¹û™3D
:u©»Ç™¸!	t蟃Èç©{ÝN©Ê>yàOG…aèTöÉVÒ>nK~ƒO]œ~NÔŸužœ„ßÌØ4ÈR¹Ûwï¯CR2κ–»z²ÂGC/ó[¹N܆î‘nÊndI}�ÝñøqÁ=õµ€=¦/TŒTJ¡)4*\ÜvÓbhÃì‘S‹ȇ3/FÑ*ÑR*}=Šc½E{,bìZ.ÖM‚f³¼º»ÇšÙ~4ƒ.mÒéþRËã«@‰–/&”X[hÈç ÐznzÆÙÊ7ŠÏ°¯\�ÎÒNžâ8GM|Êè
Ýð¸w’Ú1È�µ‘[|̉Ôi245Nô­>X¯¶`¬éC�<Ÿ/�€¥Ñ¡2ßVÑYJÅÔ5ïã>Êp•¬Ì=÷¤¹ã^æªWU}ËÂMèwüÉF(‚|@t‰¶ùÓX˜h=yq
 endobj
-1216 0 obj <<
+1276 0 obj <<
 /Type /Page
-/Contents 1217 0 R
-/Resources 1215 0 R
+/Contents 1277 0 R
+/Resources 1275 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1219 0 R
+/Parent 1273 0 R
 >> endobj
-1218 0 obj <<
-/D [1216 0 R /XYZ 85.0394 794.5015 null]
+1278 0 obj <<
+/D [1276 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1215 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F48 885 0 R >>
+1275 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F48 940 0 R /F41 925 0 R /F21 702 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1222 0 obj <<
-/Length 3299      
-/Filter /FlateDecode
->>
-stream
-xÚÍZ[sã¶~ϯð£3³æò"Q⣛Mö¤ífSÇ=—iû µåÄGr-9Ùô×€
-Ìf¥ŸiÎg†E+âJd×±¶Uv�ðN š’6:}¢‡W0Á!¶	Ix§l ÙJ»„Ùþ(å“àLIë`Bj8˜:¢ÒTè(V<Ç"[®úŽ¤XDN%­#	æîW]cMkµ‚£§gBg Øþ}š¿d›¢O�
&Ý£¹’ÕK¾©|r$ ë ¯ŒI;ðt⃇Ï`Ë••Ö"ÆS‰ÔÙ0Nû¢¹OæBЂéÔž¸�}â#ö�øïâ#ä/å¦w+œ0Æ%íð8€I®��Ž4ØB3Œ½Gh«Á(épëýP[3\xsy•ßg+¢=”UÍŽ=>B ý	
æI
-x
-ö
-î�HNÖ†‡–µ�oruAdØ'Y0#w™aªåÉŸÊùrÔuKÍfÅã®{TÑ4ЀC׈³Ê`“¾à¾g[+Eb’
-8‘Æ2=-80õî–PÐ¥#ù%£L«€Ćü~»h"øZžm*Q¶ÍDLÎèçú–çsNe|} G_èj…~é·áÄc?GŽ¥pÒéo=#AÚg¿T:¡–2é~Z¶.«jÙ�ÏÙjjÌÌ{ŽlÈ#¢4z#Ù€ä5Õ�	ÃDÏA
-‡Vœ˜ÿálëƒm„‘Nº7Rÿ6×qØ6\;ؾ,WóY¶9¼
ÑVDR�˜zÄwŒfì�:ò)÷×&Ú]@;Ð(÷׆1”ƒšt¨¬ ‹Uuþl
-¯§	ÓFFNš”%.N�ç:4r"IõÞÓÌ
ìš¿Ùê	‚ ¶#h¿d¯pTüX臇|ž½*¡;ò¸Û6a]óòáw[@ê
5¹?Zuðqh´WL”§¬ž=P™êUƒ"uY?<‘
-¾þˆØ*R
ñ~FËž½ÃN^?t‡åñK¾*_ˆZ—kf\�­�Q¤jzvFÁ�-£xغT8e\oqãcOˆG"	µ:
-¯�z eDbµù¶:⨴5ØÞxÙæ:ª†k·aÕæù$ªNËL=ò{0eº
-Á”‰Òo�ì¢jCʦ)뤀 •˜
-Š]Lø^á¤BI­O‹o¸zäw_á!S8/:
-ü‹ßÚášB~í˜t²¾ˆ“‚êõñ•´Bª5ñˆa=žÌ‡�}^IÒŽu·£ÀÜ{襜J¿¥¶8º“*5Ô8¹“m®ã;Ùpù|-ß”£¢Ue6ªëÕaB¯EÅæ´
W�ݽ„-Ô6éªÀ{©B
-Zo¡¸�ÒÏïP³mý€µdV/ŸùN¶À”ŸÔþ.$yÅ�>�‰^†z*d—¼Óé�Dñé”
-÷š@À(«�…Ó‰:‘Õ‡‹óÝ2e¹ÿÚ8¬‰Ó¦
-ªÚƒ¯þ ‹ÖòÛÓ�8!�ü[ŒëibÕÈkq�@^àêAÞh–�S~#EC¦rR�†«G�îK»X$¤3E
-2TÁ
-k=‡ú‘²þÑcõx˜—@.aÝiñ
Ó¡ü.Ì!}‰eW
9:¼Û¿Ïñ»þœÈ?…îÉäîúcEÄE¹‚ò‹o¸œ¿Š
êÏ·ü^å²=!쾿š0ìÎ;~põÖM›óuÛ»ö]cxÑ9ÏÞý2iåâáw?Pêü«”&»'¢.Þq}¸¹ûáò?Ä8™pgI¿Íg)Ô½\„±>7�ÖcþJ]Íg<@üÂ3ó5)€8ÍS²
ó=-¼EßUA¸Š�wË0vh»„mÎê¨[/ àqWíâç
-þÛÓZ;'žòKY?PëeI-ËE-“ $f*ÑÀ΂Z|™ÛúòÁëØç{à¡BcbóWŽýP!Æ?cì�¿l>ŠûË_Kî>%�ð­Fz$Á×I
-E4LÂJ¡ât¥Ú
R€�t�êÿ£„‹�endstream
+1281 0 obj <<
+/Length 3465      
+/Filter /FlateDecode
+>>
+stream
+xÚÅZÝsÛ6÷_áGy&B	€ ÁG×qrnÇ'»÷1m‰²5–I�HÙqÿúÛÅ.(P‚äæÚ™‹g"p±Ä.€ß~��§	üÉSkD¢‹ô4/RaiN§O'Éé=ô}<‘Ì3öLã�ëû»“ï>èü´E¦²Ó»y0–‰µòônöËèâoç7w—“³±2É(gc“%£ï¯®ß¥ Ÿ‹Ï×®>þ<9?ËÓÑÝÕçk"O.?\N.¯/.ÏÆÒ	ï+áÀ®~º¤ÖÇÉù§O瓳ßî~8¹¼ëçÎW&'òŸ“_~KNg0íN¡kN_à!²(ÔéÓIj´0©Öž²<¹=ù{?`Ðë^�­_j¬0*ÍNÇ:6ƒ1¢«œˆÄÀª�sSˆL+ݯ²’±Uö\¸Ê³ºm«éø¹\.fe·hêÝyËÌ•åÅi8øž
+=WDè óD¨´ÐC%.ëò˲:ƒIÊÑûëÛÛËjZ¹çÿÖåS5Ãý´ztÝtê¼3Y•$"Ë
+êÓ¬H±‡ze¹0yV0w¹l–TU³–š“¾°¢mÕõnÀÔŽµ‚­3°2RÆ(7îkÕFd«D¤J§,Å QþVó3iGójÚ-ž+˜³–Éèî�;gÕ¼Ü,;zX´=¤*À¤üàqd.
+P—yÄò^¹Ì„Íù®#ô\Áæ”ÓiµêÆÕ×Õb]ÍöphS‘)£�«ÑsEôLÙü’,*rî4€5ÖräÔÀ¥U€�ŒÚÅ}]v¢µÄôòPÕÔû\­ó×E}O=Š¡=|aÉm!öö[ˆÑ-ç	PN2�%Òµnb;É`ó;éÐr[u�SAÒ=€×jVdXŽÊ ûU©0‚?DXVåsÅ/8«£æófYWk2Úð}šãjY¾ÒsÙuåô±=©,Ggj�#*`:(Ï„óþϦZ¿.›û=©L$‰I�Ší™öåVZ'¢°Y>|»ª¦€˜{š"6º‡j�šT":(vOÛ
íC³YΨí,xÛ®\wÕ¬¥¦–_~|9I:±£«yÄýi	ë"¥GB¸";I5„ˆ0ÄèÀ�šŽE­ª39šŽñMpj
+¡u‘‡òÍÁ½&¸V@啳3Aᙂ5±£�3C•éÑÜ­&�—Õ}¹$ÚCÓvlßØãÒŸ_ŽDž€‡`£àðå´Øð,6ðM>\¹0Šß¬™‘»ôÈ*ÉByð§f¶Ǭ’Þ0XÑ0Ѐ°«EdY¿&Qÿ¾[�(
xë’ÕjI¾ŠVçqsÍÎÍKí¼мgDêœ~ÏßQ×9ü#
+9] }ú©ì‘0±È¬]uÄÅÕ¾¸UC³©SÃm½Wy°RÞm«¢wÛØ$’eTaòž
+rüïœH.ÄÃïõí;b¾ýÌ=´uÐÀ	àïþR“¹	8v7
×òp²™øGt¸¹›q C÷r�W*LÙzPÂ#

Þ&lâJPkQϘ­à„$îiÙq‡ÿåQKú¡‘¡Úhy€eÓ<nV,a>àõ¦DOèXXít�(¼¦'Ç�yUÏ8C[pJwu=>ÿ~"Î'7g…rØrä›l—äL›»®®ïÐÌ¡RH+%„‰ã9TÈu8‡ê¹¶6öôu¿°B¹:.¹çŠˆÖMs›
e_ l\”F{GLÖ‡¿C
€Z•ë–ßhBÆy?“Kú¹ºáÇÙŒ3W!ÈÂèÐõkN¾u|1Ì’
”7I¡¾5D‚´Ïnª‹\h›î”«¦m}éø\.7¾ÂôÎ<±!�H­y#×È¡$S>n¡“ˆÄQZ&×ÿCl‹Wg0Áü
Ün™ŽÀ–™¶¨}Y,gÓr½bR‘§¹9*¼gÚ—>ÌÎ
+H›­ˆ§Ì_ét{D
+ÏEƒÈ§5¤T
+ÌѸCÙ«ÕEäÁÀ™óÆN†\‡w²çr)[µnÆu3n›rÜuËýÄÌ¿vU çŠh0ÜKp¹–Cx/¥ÏB»
9�»�
+VW™¿&å‘f[èô
à\G€ç¹"ÀOËéÃ~ŒÂãGq\�ž+¢ÇðŠL
+	O.‡Šü$ä"¨‚³Y¸¤m‘†O!Òˆ
w{˜Ýá
é|A
+³åz}ûã忉q2áΆ~ûë)Ô½˜ûw]j­Çꕺúë<@üÂ#ÓU	ÅøE
+/`µ£‚[>+³ý‰¬ÙÎAg#OÛ&k3î˜SG|ˆ‚Çm±‹ÜLˆ“	ù¥é¨õ² VÆ5-“ "f*Ñ`‘µø@7¸ûàtŒ˜§€Z[ý)ÏëÏߌÀ»´ì'ý­¸?}ew{Ÿ9ÅVÅ­H'P8áí
+V
+7rWs£­0VåÕÿƒ^'endstream
 endobj
-1221 0 obj <<
+1280 0 obj <<
 /Type /Page
-/Contents 1222 0 R
-/Resources 1220 0 R
+/Contents 1281 0 R
+/Resources 1279 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1219 0 R
+/Parent 1273 0 R
 >> endobj
-1223 0 obj <<
-/D [1221 0 R /XYZ 56.6929 794.5015 null]
+1282 0 obj <<
+/D [1280 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1220 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F48 885 0 R >>
+1279 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F48 940 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1226 0 obj <<
-/Length 3218      
+1285 0 obj <<
+/Length 3124      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥ZKsã6¾ûWèºj„/¬œ&3ž¬S›IÖã=l%9Ðe±†"‘²ãýõÛ�nB$EÉ»›r•	6@£Ñ�¯AÉErᬈufif„�¥]¬vWñâú~¸’̳왖C®ïﯾý¤ÓE&²D%‹ûÍ`.'bçäâ~ýkôáoﹿ¹»^*G‰¸^Ú$Ž¾¿ýü‘(=>üüùÓíÿ¼{�šèþöçÏD¾»ùtswóùÃÍõR:+a¼âÎøtû÷jýp÷þ§ŸÞß]ÿ~ÿãÕÍ}ØËp¿2Ö¸‘?®~ý=^¬aÛ?^ÅBgÎ.^à%2ËÔbwe¬ÖhÝSª«/WÿzýÐ9ýYí„u*�Q ’s
-´™H´Ò^�¸g	ÿ@q;lö/ù~]Ö�¸5˜@&ˆ°wa•IýÐûmq½Ôqmü ké"?h6Ú䫲*»WâXå5‘xÈ¡-ÖDéfñyÇ9uW4ñ#SÛ²+–/庠ÞU¾ê…hx…œe*^xD±.öí;x“YD‹¬+4‰º}¾Aâoq¬V¸iܦ”"³–L¬�áÀjâ¨*ë¯-5½Ô:‹Š?»b_çQë|WP‹WEsJ³è¶#*©
yÕ6Ôzà
 �k­³{¶ªy¡æ‡b_¼úÃ+­Î«ð mÎˬyxÝ0a›?ã­)¿µuIúX!ŸJ£|µ*Ú–Ú^å`Ú‚·5nµèP“&‰1¼”ív8$�ª¦ùJ­Ãñx5•Íž¨¨&^%¯__ò×k)e„º2Š-p`LÀÕ¬V‡=�hêê•&…ŸÙS·m@•ÞIƒÎðeƒ«cãe[®¶Ôô{Ã)’Ú%ðÚÃF~€9÷e—wå3óçõš릘²{e�§Ïëö%L_ó³ã�Þ†ÅI$‰El!È%I
-{KÕ|äd¦å�ë¼ã.Ô9ízº®TRØTf—\3+#†T‰°Â×héû-êXg*jžºÒ;n&£@£Ê®Èk°�Í¡¢žrCt2I ¹
Ъ²íÆ’
-ÇörÆr�Ϙ�˳pŒËöxô£Ì	ˆÖ¤™½,Càšb”;SÀ
IìÆRŒr§6–5ƒåW_C
Ñ—UðœäQäò]¬GðCý¡à3\ˆca×P¯åCóS{s‚Nj>Ó%JXiܤøÚxCSÀàžd	B¶¥N�¯Ê¡Fù¹H¢è@E7@¼,{h}=þÂþÝÁ慨ZJÆL/ušϨžûŽ-óöëá:`ø2z¤7®3 ubçr¼ÄxP}ðs›ãæLœúÍ!…A£êÕÌü-=Ñ”°¥#oO5ã
-�Í;i./¸fVG!ùâþhùq:Ú0`Š…ÐÍBú1
-9‚šžØ~%BÓß™ät˜E?¡®þ–t6¨`Z�ÝD/“ÍX'”LÔ0¨>�×9ˆ-±”3—3pÌ£�êà9#œ‚¹LöFˆ0 B4†åâ°@¯ÞÔPˆ Õ;z6àýÇxp^	—*c¦Ñ
-1PJdêuHÔB©A„»–P`{«ÄÂ!z]®òÕ54zóW¸[F—gƒÏPºÖ4	½ðÕ7—ºø<bM,¬û
-cÀ@Fš:þ<s�—É
-Í^éâÝù[u
-Ød(ÁøzG\ŒMÎHØ\ÊcFÒºÿ‚Œ‹Ž{ý§3wŒ6øFxü½yi­_ÔFÊÒ1”Ã&±§éiÙãb`NÓÉ·Ì Ãi¶H$<7´q#9ÆÉý†ïCN¥I R'6	³/ð÷
+xÚ¥ZKsã6¾ûWèªj„‚äq2ãÉ:µ™ÌzœÃV’MQ6k(Ò);Ú_¿ÝèÅ—ì­ÍL•	6@£Ñ�¯AÉUÿå*²Â¦*]Å©Q(£U¾¿
+WÐ÷ã•dž�gÚ¹~¸»úþ“ŽW©H­²«»Ý`®D„I"WwÛß+”XÃaðá—ÏŸn~üõöý:6ÁÝÍ/Ÿ×…Á§›^SëÇÛ÷?ÿüþv½‘I$ƒÿxÿåîú–º,ÏñÃÍç�DIéqaÒÛëO׷ן?\¯ÿ¸ûéêú®ßËp¿2Ô¸‘?¯~û#\maÛ?]…B§I´z�—PÈ4U«ý•‰´ˆŒÖžR]}½úW?á ×
]ÒŸ‰)cA“J$¡ZV²±”À	2¦g%+¹¤dÏ…Jî§M—?mÅîP´�ÓMK%EšÄj5œz&@ϵ �H •…vbÇ"Ü­Ó08œÖ
g×5ø„÷µL�É=@.ê|,¨ñŸ¦.ˆïØ–õï>|¡F¹£¾_?2áÏcq(‹–^vYY�MX©‚OÍ�hd8&!BÞ쟲®¼/«²;­¥”Á;舭
t„'#´Ö°õ(Rn'Ûb—«Ž©l‘qrF#­µ!ÿ©ð<#-‘�0�X˜e“h¡lš×J(cÎþ"áxA†¸¹—ì°EõÌ×W…ËHCGàÚ`ç¡Ò·¤×0…å¤Ç‘g5‘ïyȱ-¶Dqg‡,tjYÇuW4ñSÛ²+6/嶠Þ<˽
¯�±LÅ�(ÏÅ¡Å“�)[Èö˜³ p6‡l‡ÄßÃPåî”Âñù40XMTeý­¥¦“Z§AñWWê¬"j�íjñªFâ4¸éˆJj€FVµ
µîy
+*Ê(6¿�%
W“çÇ�hêêD“Âq/œU÷Ø´yR¯3|ÙáêØxy,óGjº½aƒÙûŸ{:ía#;Âœ‡²¿~fþ¬ÞRcÛSv§ìñôYݾôÓ×üìx 3`1Ë›mh!~Gæõ
+BEÑëëz¦…u‡Á’²
+m2^÷î¬S4O]é\6•AO£ÓʾÈj0€Ý±¢œSË�09ä@«Ê¶OH>
+�h&Pš
+B”Î?‹<=×[bÌf»XÿhÏFõb
¤¹
+©õë"x¦ÆU»þŒeeNm"Ö^¾z¢+¨à9É¢ÈåìºX‹<àŽ…úûRÏpý�%]C½™›Útº3syÎ*I“LÊ® 74í6µÖ6:N\1õ/Êϵ1:*:
‚eéq=ôyä…ýû£Û5P]‘”L™(Nê8íý¢zö�Ìë×ÃuJðWNÂКY¹oÑ”ü|Ìps&ŒÝæ�ÂpQy53KO4$léÀYƒÌ°GÂʯ?±J°~
+„¾¸€6¡è½çN¶çîPæ�Û#Ð
+¥­ɳþ™ë
)|üWx1
+.à!qÑeeÕŽmøoä†>áŠÈÝÉg6v”Ña8#o»Ë• ¡õ©lÀt9“y&çÁXl
+-µ/"öÙ‰fçKâ„ó<WDpxŽe›Ë !®…Æø‰�Ü·#‘0‘‰™	R
„(vÜ5–êWàÄfñˆõ�2Ne<VX鲶ò塃ðÚA^3XnS/e_â˜7J–ÖÎDGGtë+Æýõ"´F׋1ß-¸õèá‰š¨4?ߎHX�¹íËSµUcü0¹Wf¾é§žQ(y"´~N7½ñ#jöP´çÒ’17
Ú�24Êü]ë�4š(úÊÅø#¡rŠâ8z=
+i(åØì‚€cÅ$¸PÏå‘(˜Ë¤o„
*Yˆ*	ûù½vcC‚Gc�õ0\–E&¡ˆ•ÑÓH€#^×æyø7¬0-Â(™ÜãÝì&÷+ÿ¯ãò‡ºùG§±oºkd.rç` ‘"ÂoÛ³ub¢ÿå—ha’$Ë¿
 endobj
-1225 0 obj <<
+1284 0 obj <<
 /Type /Page
-/Contents 1226 0 R
-/Resources 1224 0 R
+/Contents 1285 0 R
+/Resources 1283 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1219 0 R
-/Annots [ 1229 0 R 1232 0 R ]
+/Parent 1273 0 R
+/Annots [ 1288 0 R 1291 0 R ]
 >> endobj
-1229 0 obj <<
+1288 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [367.5469 543.9652 428.747 555.8654]
+/Rect [339.2005 483.6075 400.4005 495.5077]
 /Subtype /Link
 /A << /S /GoTo /D (zone_statement_grammar) >>
 >> endobj
-1232 0 obj <<
+1291 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [483.4431 345.7585 539.579 357.8182]
+/Rect [455.0966 291.3684 511.2325 303.428]
 /Subtype /Link
 /A << /S /GoTo /D (address_match_lists) >>
 >> endobj
-1227 0 obj <<
-/D [1225 0 R /XYZ 85.0394 794.5015 null]
+1286 0 obj <<
+/D [1284 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 354 0 obj <<
-/D [1225 0 R /XYZ 85.0394 769.5949 null]
+/D [1284 0 R /XYZ 56.6929 712.783 null]
 >> endobj
-1228 0 obj <<
-/D [1225 0 R /XYZ 85.0394 749.7875 null]
+1287 0 obj <<
+/D [1284 0 R /XYZ 56.6929 687.8416 null]
 >> endobj
 358 0 obj <<
-/D [1225 0 R /XYZ 85.0394 528.8451 null]
+/D [1284 0 R /XYZ 56.6929 470.2923 null]
 >> endobj
-1230 0 obj <<
-/D [1225 0 R /XYZ 85.0394 505.7912 null]
+1289 0 obj <<
+/D [1284 0 R /XYZ 56.6929 447.8217 null]
 >> endobj
 362 0 obj <<
-/D [1225 0 R /XYZ 85.0394 390.6092 null]
+/D [1284 0 R /XYZ 56.6929 335.2388 null]
 >> endobj
-1231 0 obj <<
-/D [1225 0 R /XYZ 85.0394 367.7147 null]
+1290 0 obj <<
+/D [1284 0 R /XYZ 56.6929 312.9276 null]
 >> endobj
-1224 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F63 998 0 R /F62 995 0 R >>
-/XObject << /Im2 984 0 R >>
+1283 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R /F63 1053 0 R /F62 1050 0 R >>
+/XObject << /Im2 1039 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1236 0 obj <<
-/Length 3335      
-/Filter /FlateDecode
->>
-stream
-xÚ­]sÛ6òÝ¿B÷tòŒ…ÀéSš:­o®iêøæÚ>Pi"‘ªHÙÕÝÜ¿],
-¶>¼lêbd{žhÆe"ÎÙT7QéÕ­aÑd&­e6Ix%Y¿g,²eÈ=Â
–Å*?nzø%I“1†¹ãÊ3±­ù¶,šúkZåžQž²¥ÃYaN‹ÜIàOÂμ„7Em
K$ºj¯]¬Ëö±Z™÷˼)ÎŒ•b¢ÕõÝ#ÖÈö=cpÖ˜þþ=cI4V‘˜`¬�Æꂱ"+ëã|·ihüí©Ìw›!|ûþ#Aé�5AWÕ� »¼n
-?þOU5˜©Èôô‰ô|&øSkE_�ZeÑ™×Å„X�çeQžÒn	àùˆMÁ!ìNÉÐYdÓ÷US´YçMD¬^6å'‚·ajž“ö¼ñ°öH``LuƒGÿów¿êáƒ;X2ð5Ë%-©ë¾^nÊ�›óz^çºbSfЗh-ÂEš<|šÐ౫5
Ö]0¢5gt�Ö‹fãŽÜ&‡Ü)˜²€Ü%~¦¹ë„T,3h9]HƒœãhòͶ¾l»°�sH×m·ƒuÅvÖÐvgÀÎK~X¢¢¯Æp\#¯3±F8é]ˆÑÌØî±ÎÍXËhÆ0fÃÖŒñ!š1<�íÈÖŒaÜš1>83†AǦ:˶ù³·×,eÜ
-Þ×ngÙx]~I*¦ó‚žIpÈ×Ò1S„"Cl�ÁIP—Ü8ïàf:QC¢É8¿¯lW{„f	WÒ;þÿB�$¢K´&þo,ØIÉkXsGäƒL‘¡"/kÏ,y
-
-‚�´ª“%!ßÇúò<Ñâ:– Í{
-GËãÂ+‡ä ‰ÅAW9ÈxïðÒÁÈ6åï6–
:àcƾ*ëÍ|³Ý4'B ïQ#
-dª©Ö=FÎKä€t}%(=uÖc ¦»ª+éׄì\‚Oºž t±.'«õ¡ÏzVŸJÐÚšâS/7€Â9K„¹ÎCÄa¢—(ͬU}&žÖ”§Ójï¯Æ/¹jPÌ&:"*åR/G�±Ã ÞU•ó
-T»!H‚:l–®r¸Ì�±L¤6HŒl¬G툋GÃõ_–5<@°ËU°Go !Þ]kmCŽáyô V�4ð­ŠKÖ›€Ä!¼b½¬+Ö°ðèó-äëj{ÞtH8KëêÖkdo9èFª,lÞï&á’7øÙn07ÅQµòm"p}
-éF
b¦'„¯³pänÑ�ŒkïÇm‹Zkv{z
-G—
-ªjà9¨¶ÏE`—*&Ål¦QŽZ­œó©WªŸÂŽxÛ�¸JÊZ¦ƒƒ’ï:õqî±Û
-a"ESùýž.ièy-$Á”IB1T^6z|›Š»‘N»Ä¶5 R±Ô$6¾Âæî-¨”VX!­rÈ~G6�ø
->>5™ò	Ž«HЧÄE®B¡ ûêà: Õz&B!ãFàØËÑ-®_4*>t®ÅUA'Ï}YÔ÷¥vÈ)
-”
„¤!‡©ÀzCþu‚¯pù€{íÒåÐù¾×�oúAÖ�ןjŽ#R	Å%].Æ
-™B0¡‡íªž™…
-Öâ÷|\Ü�XÐÌJ–¢
{¶ù€׊ò½)È™a¶×~–#ƒ•$<AZ§zÔþÆÁ)K¦<9xúŠëk­=ØI‚!áûšt�éÆ¥	
$
-lz–‡>…ko¨Á@1–Uø€œ €æ·˜ÇÅ	KöùÁ1Á—ëL‰¶Ž÷ß—T‹ÏÎÙJë�\wN­ëŒ�FѤé±ïå¥×Ui|"²(­SžØÊo¸öäª}
Œ’
Âc}qíh¼Î=�¢¤Ï”püæÃÇ<î�	,>ìeá–¾Ž‰V¶ 7KˆA_ÿdļu¯ð­aMP'€>¾{K
+1295 0 obj <<
+/Length 3121      
+/Filter /FlateDecode
+>>
+stream
+xÚµZKsã6¾ûWè¹jÈà
²ršd<‰SOÖñž’h‰¶X#‘Ž(�ãÝÚÿ¾Ýh
+>»[þ:ÿ?ß]Ý^fB³¹É/3mØüÛë›wD)éç»7ﯿÿ×íÛK«æw×nˆ|{õþêöê滫ˌšC{á{8Ñàýõ?®¨ôýíÛŸ~z{{ùûÝ�Wwq.Ãùr&q"\üú;›-aÚ?^°\–…ž=ÃËyYŠÙæBi™k%e ¬/~¹øgìpPëšNéOé"×B™Y¦A¶,§µÌr¦Ak™• SÁMÔ²àSZ\¨åj½îž³?öõö%ëÚñ¤¹Ö¹Z̆=�¹&�
¸�©2cR	~yªÍoŒ‰º‡�ÅüyÕ,VT\w‹j�E;¯–Ëí%/æußÆEÕR¡Z,꧕;ǵlÚjûB”w7¿P0Ë~×tm¦
+Ú¶ý®j�¾ë�\’Ž©ˆŠnp(ü
+NÀÖ­�k´{êé3Y°%Ù#ÊUæ–³S–82+rÅ-4CîM…’qÍúŽJ÷5ýöÑ –DhÐL¸tr‹ÁÏ�´ÜwüoÐÉÄàBæVxXä]½©ÛªNpß¿Š†ÅEÕ{iœ=Áo÷©Þn›¥33ø<!‹5¹Öà4P÷äÌ•Ì\½Ì¦«ù9Z³Öè±è9ujýJXÇtýà´óæ0Ð蛑	,ë‡j¿ö|�_z4|gd¤XŒ†OfëOÙJ…L‚ ‘‚ âŸ{eáRI1{Áô,¬º2êt_ÔŽA_¾Z¤]eAºLkŒjÖƒ_\*X[®s#”�^äRIÒõÍ`É´�¹!'˵Ê/Ù‡ËÌðùü/æWGªá.ô3ÐK.XéŸý1ã9Se)‰kPv³=hÁ¾¾ÞˆÙ»æ4N+ôœ
»vó2IP×0Å‚�ÏÁ²y4ËK®çdš�„Ùü%[T‹K(Ë7b˜œJL†ÁÃœ!Ùb¾ï�CÉ™ü:S|x¡Œû}Ÿ2�eZÌ(‚Gö¤J³®Ø—�, Ë`AvÈæ_f¢™(s¬ÿÈMQÈ3™–HʼP¬<Ÿø#×8p�ªÆ¦e
+…¾vTÛ	iŒÌ™Ñ6f[/öÛ¾™Žø�ª
+Pp:œw%(54Œ‹Ñ\Éy#oŸ›~2%1Dž†ëbbhmsˆÏòï
Š&Wº,‚b)šLg›ß˜f¬V¢Ów�Iÿ
5rßhZßLˆY0ćþyš×p"GÑ$ oe‹\eÏCô!×iO�\“ž:Ôp/	Aþ¬‘kBŒÄYÜv
+2™|Í\\gÌ5p�Pé–<\¼2~`š?ÝPò\1 %¤IÅÄ
%CR�â!©àGL*† þâ®�JÄêfôÉ“;9l±"Þ?®¡ñU}½ä�‡
`ÉÆè錓
ŠRBϸ?ë@eØR‹>µX~2µ
+tf's"·pû3ÅÕßO.âï%iK
+V§;\0lÐgà³cÆæô¹Ùd$É—î„£9H�+¿{=c®3æ¸æ°ZV»ã
�‚¡åùÑ#×Äðé¾öDR‰tüÆ8BÆ÷±©1v»�»‘É­
ûýýƽ@ùÝK[mš1Ði Pi’
�àR7U¿«}�‚z�?î‚9@z…#R€z0SúÐäÍ
¾—µƒ@9	ä
è±Á
+ûÀ–¾,vxCÝ�¢@5짼°)€Øz±}4wµt=â�1Üšq¡S×Ó§ £ 7.8©‚””§z=m°d’•ó»ËRÌ;â©Ûê~íùâÐÊ=¿!æpœ7¡§öOZÈN7•yÞd^µ°ašýæ¤jeÜ.e`#d¿/t#ÙüSµÞÓ•Ç�þôiUµ¢s	ÐÆ
+û×–Øâa`�–i¢_‘£Fݦ7Õ+(/X åÞ÷{Ðç},º=^ã<Q:Zîጋƒfäa?í�b
+Ù‡k)@ïr0Þî‘gÉ`âþšÎúsEUĹa9µvO««Ý>î:�@÷u€`¨#ŠZŽâgàÊîªË
ûçS××�HÓ=0÷S£ÑÖ/ƒ¿ã4NÀ
cJ„
+7øtµîuØ—=0FÛß6lz›ÇÖ›ùòð¶ÀGƒnS‡Q¶mŒJ|mðxfÃË$²Â¼rþ1ä:ã	�ëà	Îpêíñ–·Ì…(Θ&†O7¼îU¦ã'HY	P=RVÂ�2Ò#RÆ´7üõëS»s$¸‡Äâgçû:x…«\y®áAåÄ•˜Ö¹Á\C8&
+þÌâÄ‹9<ß‘“÷×,¾�øâ×t‡§†ÊÒ
Í4D`öø¥
B¡õ$вÈu!ì„èÿ¤â/
+endstream
 endobj
-1235 0 obj <<
+1294 0 obj <<
 /Type /Page
-/Contents 1236 0 R
-/Resources 1234 0 R
+/Contents 1295 0 R
+/Resources 1293 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1219 0 R
-/Annots [ 1238 0 R 1239 0 R ]
+/Parent 1273 0 R
+/Annots [ 1297 0 R 1298 0 R ]
 >> endobj
-1238 0 obj <<
+1297 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [184.7318 660.5919 233.4785 671.3763]
+/Rect [213.0783 309.0057 261.825 319.7901]
 /Subtype /Link
 /A << /S /GoTo /D (dynamic_update_security) >>
 >> endobj
-1239 0 obj <<
+1298 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [369.8158 538.8963 418.5625 550.9559]
+/Rect [398.1622 184.6228 446.9089 196.6825]
 /Subtype /Link
 /A << /S /GoTo /D (dynamic_update_security) >>
 >> endobj
-1237 0 obj <<
-/D [1235 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-366 0 obj <<
-/D [1235 0 R /XYZ 56.6929 372.9462 null]
->> endobj
-1240 0 obj <<
-/D [1235 0 R /XYZ 56.6929 349.997 null]
+1296 0 obj <<
+/D [1294 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1234 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F48 885 0 R /F39 863 0 R >>
+1293 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F63 1053 0 R /F62 1050 0 R /F48 940 0 R >>
+/XObject << /Im2 1039 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1244 0 obj <<
-/Length 3002      
+1302 0 obj <<
+/Length 2626      
 /Filter /FlateDecode
 >>
 stream
-xÚ­ZKsÛF¾ëWpO¡¶óÂÃ>)¶ìUj­8Z¥j·’@Q
†
-íœxö‡JC'¤òïUWî*{`¸a1¸a…ÐÊ`$©MÀÍÑà¡:˜8LD?¸ÙueS3wö:-_ÌΡ-V!Êl —ã§|l¼ ¥U6X:È’Pi•:ƳÄQ4ÿ}òúáµþûÊw‹�'¢è¨%¤Ò£Åþ"£H¼\-Ò—/¿Wò•‡‰$`?ö%%íw,«
-ΙyQç‹
-õ1Ò¬˜@¬ó-“zªÕJ kH1Š(Vñ�
-`ª)Úú»Ž:>ÖÍq26¯Û#�bCsrúùÇ¡hQŒh§	
/‡ ³8¥¡À‚Tv9=^a@h%0î¾ìJAÛöËÂsà >Ž˜ý�¢;Šc>U<rÔCNìò`†	¢‘ÓƒF{°1:‘¡²
-~1Îtr’*ÅŒ@›(”Ò¤c+99´1@ò 5¯¶€×ÒiÌ›Yóñp$Â$SŸÓ…QÖûg¿ª¨,N‰Q)²””"ËJaA=uîÁª›-
Ø�ƒBÓÆõa»(x…µÕ7Œgr¼–M�þãîpÀ0Ö½+ÆûïJˆï+¢v¼VÍ–0�ßDfÊÄcC&‡cy¢ã%Þ‰|©€Ã�åB"5¿Ý0;>VB|¡z·l==ƒ	£¤ŒR»!>o#Á{¨4vv
L÷:8¬v
nìóij
-d@¦à×9j6Rln
-²–ü>/+,Œø®)Ã,*6_¾¦D¦z|M°&Êvº ,›½s¢MMñûûK‚!½@°ÃÆ›Wx{	ePDz-Ч‘M·pŒg¿’TÎæ¨"=I‹šc=öË/¿œÏ?2¯aNÏxÈ–° ÜR+6F™'JaÂo^ß°æSÕ‚Ç×Mþ`CÌe% (}Ú¥®–žb;´LkkŠv¼,!›«ˆ^Q,¸ã¹(ã‹åa_v'œ–j[“†.¬¢¢Å¸.ÿ]¸¾]Q¯xoª½¥óû|_6&îòÀ'A°É´Úh-æ‹êà—#*‚Bkð²�d:÷²ÙnMaDÉ3
-DÄq“O3˜ç/Z|1/Kò6pŒ–�CºG­G	‰pø”§@>™$“‚˜ÇŸÙæÉŸQír5‚¼CøŸ·
¾#ðIJ&ße+]öaê”M¨ŽOW]?5§W'«bËÜÂno	‚]z�y&ÿ„y€±Š§‹Ï©Î‹Äc_oóèA‡ÂÄ—ÔV"ˆuð�Œ¬¥Õ­écƒñÒ¦\”QH
-UΉá5}Ûfˇh  j"‡�R
-ÃY»{Â$¯×6ÈQÑ
+xÚ­]sÛ6òÝ¿B÷tòMˆà“É“›Ø=w7q}ssÓö�–èHc‰tDÙ®çæþûíbIQŽ3éøAàb±X,öV	jâR‘º˜d…N*7™­�ää3Ìýx¤'	HI뇫£×g&›¢Hu:¹ºéÐÊ…Ìs5¹šÿ6M…Ç@ANßýrqvþã¿.OŽ3;½:ÿåâ8ÑNNÏÎ>¥Ñ�—'>œ\'*wjúîŸ'¯N/i*e?œ_¼'HA?ˆ^žž�^ž^¼;=þãꧣӫx–îy•4x�/G¿ý!'s8öOGR˜"w“Gø�B…ž¬�¬3ÂYcduôëѧH°3ë—ŽÉϺ\8mÓIb¬Èaÿq)+‘)H™+Dj´‰RÖjLÊ
¥|½*g·‹fU
Ï«¤NÁÖ]¢{[G¬‘½Mgo%Sa7Øü×»j¶ü]J]µÇ‰ÑzZÒÏjÙniÔÜðÄ|¾9Vù´jÛ€»]”Û0ªhÐV›‡jCãÇåjE£ºa¼r6«îxüå¾Ú,©O»YóžLá¾õdÍtÛ€9hVU`„6I4ÜM‘Z�†…sÚŸ
7x:VJMA�’ÓOaGT³ÝŽøÀ½p88(‚è$8ò'ÁÁ5c3ê]SÏ«9Ójx¿«#Í«›ò~Å+—-òüúÌæ�Û1&6“Ü)²^7uEX½;ÔF¨ù„$£«a‰ÉÁjóõµ
+|³–ÉÁ×k•öhïûgéFjHOù …ªêòz…È«
+Š}‘�ˆ¢`Sû”„Š'F÷ÉÔ–ÑI°0ë¡=QòY�š¡BB”gHÜóºZ”èÍý²œH.wGl)�
PÙŽlùoBÖ‡Ú3îO0=Œ­¥¨Õ
Pþírv¿*7ôMrEŒa&g¾„ƒA¹jÂÂ|!ý˜otæSœ�˜…–Bë}“C)n¢¨N…¹ó7î[¼Ž™ÊæÙÛg?Ù+!^u;ŸY‹V±¶h8Kz\TÀñf�ÌÌ«vI+™0)F'c9XÌ�â�†Òo¯#ºÍLEdr›Ì�¿Îý¢æå…D‘	(!ó¾ªõøéfÿ�xÿ|>WJh)Õ›ùuþæÍk£ßŽïð’jÂH«	#¹@ UŠ:
+P¯–
+�»ìùN<ê¶	vj:vŠ}bL›ë¿oiâ¶n¸¡áî�
÷–éjÛ–“9ŸkšØŠ`d—4òʱ òÑŽvÈ+ŒŽ6ç)%ms¿™�½o$½ŸËô©R®mLêú‚3äýaÀ—8Ô|@E#´÷>û‚I®ëAwS—Q€G„ÝÛbûr±7À8Ÿ5äõCïq–�“°x—£íkÈÞsËfÜ%…>…ì=Kø+µ:k…ÌÍ~�? ‹OO¹êx†}JP‘[çãc¬a=p†‘­;Ü,Û[‚ „4”Óïw=)DÝõr»%×IâÂÉ~€G4ß~L‡­B
+�ãìçؘ1©aýÿˆdM3endstream
 endobj
-1243 0 obj <<
+1301 0 obj <<
 /Type /Page
-/Contents 1244 0 R
-/Resources 1242 0 R
+/Contents 1302 0 R
+/Resources 1300 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1219 0 R
+/Parent 1273 0 R
 >> endobj
-1245 0 obj <<
-/D [1243 0 R /XYZ 85.0394 794.5015 null]
+1303 0 obj <<
+/D [1301 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+366 0 obj <<
+/D [1301 0 R /XYZ 56.6929 725.2846 null]
+>> endobj
+1304 0 obj <<
+/D [1301 0 R /XYZ 56.6929 700.2184 null]
 >> endobj
 370 0 obj <<
-/D [1243 0 R /XYZ 85.0394 558.6856 null]
+/D [1301 0 R /XYZ 56.6929 148.5316 null]
 >> endobj
-1246 0 obj <<
-/D [1243 0 R /XYZ 85.0394 533.2657 null]
+1305 0 obj <<
+/D [1301 0 R /XYZ 56.6929 118.3446 null]
 >> endobj
-1242 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R >>
+1300 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F48 940 0 R /F41 925 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1249 0 obj <<
-/Length 2437      
+1308 0 obj <<
+/Length 2999      
 /Filter /FlateDecode
 >>
 stream
-xÚÝYYsÛÈ~ׯÀ[Àª%vn`’'¯-;ÚÊÊŽÌ­T²»	Š(ã 	PŠüëÓ==
-\÷
-£ašOt/2QQbyÜ·ÜD1Ö1Œ…«+_û.fœóÐÝVʧ•;:e‚E#]=u~Ò˜p“6D”Ùr“VySú1WøÜ©i@º~ÇÄá:]æ3!³MÛŒ¦>9US¯…R "&E^æ­[{!A‘½¬÷•gÄÎÀ-¨ÓIi7i;:2]ë@*»î¢:ê;šç¦ÍJ,~
-�îDú«+ñÊ¥J‘¸®WÄáCQߧMyÓå.ÞÞ¼óÌ�]›Ö4´>ö,IX¥eFT“í	EÂ_<­¥•~€�Ë14Yånß.n^ÿ•è$@»Þø"â�°G5øÓÚþG—û
5ïÅ×^½
Í.ëí3QIÞá•õ¸gTdÀ+Dk¶úS}â�È958"?ìr8+ÐnîptëGò~ç%ݾû}""Õ—µ{®
-
-Ç€ÄG+Çí¢Q]E˜rT½ƒR‡SJÃ%C@ÙH3v”ûþo¢Ub#!¹¼Œ¨
Óy@uLçCÕ$ž FVö²=Ó©"ãH•DR²±&0IÖ�I26ŠTŒ"Ð.RÁs"R1F‘Šu¨¢µ.R1BÕÑãßøHÅXn•·‡‡–‰bˆ_ãX›ü�G«îs€Žð·ò‰eýͯþI~ðÁ*†n+ÓØPÁª6ñJ¡¡µ:u
-ÿÛý©êÿ
+xÚ­ZÝsÛ¸÷_¡·Ò�ˆ‡Olžr‰“úæ.ISg¦3w÷@I”͉D2"e'íôï.vA‘2e;I'3!´X,‹ýø
°œ	ø'gÎÆBgf–f&¶BÚÙr{&f×Ð÷æL2Ï<0͇\?_�ýôZ§³,Ε̮ÖY.ÎÉÙÕê÷èåß_¼¿ºøp>WVDI|>·‰ˆ~¾|ûŠ(}^¾{ûúòÍÇ/ÎS]]¾{Kä¯/>\¼}yq>—ÎJ¯X‰
¯/½ Ö›/~ûíŇó?¯~9»¸ê×2\¯òùì÷?ÅlËþåLÄ:svv?D,³LͶgÆêØ­esöϳô½~è”ý¬v±u*�0 ÒS´YœhèB^®q
À)œÐo\Ò‘£©wó¥)§™fž²��"E,²$c–¿NÈHaQ©d†z¦ÍÊ‚oÕÛ²ëŠÕ³ó¹–2Ê©s—W«zK͹ŒP7ÿ£ÚoKXïÎ¥‹�l<±˜/ëê!Ôõž~¯ˆ	ä^ãù›rù‰º]´oXVÅ„»r³!Ò¢À…ÍæÆÅ™¶Él.eœY«üšöm�°¦å¥Q‘/oˆôy_쾞KXxlttuÃ*4¼¬”ôúCXÑÂr¨`u7yG”¶)–%®*ÌVV�¥˜Ø•ÚX»Ä°áAÉù­™ïWÍ'n'6ʉØhvõY‡íº|k‚n©7Ðý	ð¼Ôêá|ɜͦDì²c³= 
+ØY(c�UÑJ¢*	©¢•Šê¦+ëªEÿÑYT|Ynö«²º¦N4Œã
ÜqdFìD3î	3ZKg‚ƒç·u¹zÌ�™€Ð2ÁòÓÖ‹ˆ$KÇb{{ATeJÛ`0ù¸Á ʤR!Êz«`£Àuwåm±	ÞH3ñ¸¹Ìbi!ãprQ¹*Öù~Óµô«^ÓwÚPÎÄ©•!νÛÏÛz¿[ê&�W„{Ð@ �¶©™�všJ3rh26
+€šßª˜oór“/6ÅÔ6e¡ibߦT93Þ&˜܇æ Í
ʲޅ,ZWT`°¿ß$`é
‚¾à<ÇÝK£¤ìîʶÀtìDT2ÏÄ|%¹*¬ÂQ“�-QßUã¼<•ÒÄ8•Ý/Ÿ/þCDØ”Po©•X«ísjÿ÷ùxGätx}‡Ì£­ã´ñ¶î _nH¢mþ	ýJ¤à(´ø˱k
+w(îÐ^0­Ý¯‘ãxYUEÏÓ7T®Y"y*òËý®ì@Í™èuAXaHìÐÕ˜¹üwúš¢ZñÜuEßÛ|WÖ{&6ù|ʧ!&ðj_¡�Œ{ô	
+%�
+"=âóFÄG8‚Úʱ³³@­ìÁ�µäWáéžr…åc»	!e�öÆ9º5@¸ÚÁñ·X…›€�EG]¸§H ›Oòà�‚ÑùðhXÞÁ>6ŒáŽ
+í«€[ŸÑ•˃’Hâ ·dÁ]õfO�FrJl‰ð˪Øäð¢(Ó¢8fìBaÅ<€¨r‹KÍ+æöù¾Çùw¸R¶ξf�²ãñ¢¹èBzXæ]œXÚ|]„dtH,eu” ¥ú}ã|3̾»º-É[+€FÝdâù?Üf<éÖÇAS«o¸Óè/}ž,õé×NCÂ;¾Ö˜X!÷c˜¯Né7d?…àÝ(ÝgýM½È"8øÇ1î4cÌÕ~IÈäÔVà}†„Ä *û˜C�@­z3}'\ŸïÉl<GMª´û†/`�˜Íóïð¥³)öõwÒ@
éA�þÝ)ËcžµÚG€I
+„kÙÐ!²ø­CVLôk—Ó§Éw€|÷ˆ‡ü`Þ[è¡#‚‘'¼KãmŠUO¾¶Ld’<t57Æ€»ºd\Ó¾ïþò9gEN¢�­{|éZÙâ©´=Ê™ä:ƒG¾§VN£lhу
+
¶ÑÄ�ur¦’,†cÑô‹óÌLô%'Þ£ÓéÎ�ŸBƒR gº¯Áа2u±
 endobj
-1248 0 obj <<
+1307 0 obj <<
 /Type /Page
-/Contents 1249 0 R
-/Resources 1247 0 R
+/Contents 1308 0 R
+/Resources 1306 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1219 0 R
+/Parent 1310 0 R
 >> endobj
-1250 0 obj <<
-/D [1248 0 R /XYZ 56.6929 794.5015 null]
+1309 0 obj <<
+/D [1307 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1306 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F41 925 0 R /F62 1050 0 R /F63 1053 0 R >>
+/XObject << /Im2 1039 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1313 0 obj <<
+/Length 2984      
+/Filter /FlateDecode
+>>
+stream
+xÚÝZÝ�Û6ß¿Âo•�šå‡(‘�i²ÉmqÝäwm´¶¼"KKÎvû×ß‡”%[ò¦—
+®p!Ÿ®~ù�Ïְ쟮8SÖèÙ#¼p&¬•³ÝU¬Ó±R¡¥¼úpõ�nÂ^¯:¶èÆ×â‹Ä
+ɬÕñ¸XÆ€¥¤°ó“sÑ8sy2ŒNu4/ügZ*Ó™Wª™Ìj-Ѿ‰d*É,Õlž�}oq‡§e:‰2
+δ’ ¹ãx;_$"ZÂ�Ùæä©Lg)È1J¢äÙ§™`<¶VO�vK=n�køáf'g¯jXЬ·¦0ï¢7±[R"{ˆ H—Š¥65Nßu™í
„:*šùBÁ®0AdV­‰È=OYä{jY×¹ç¯ê–ˆæððPCẉВ·mQÝÃKj£v›ûÖú°_y:[¯÷yãgÚÌ�j/`ùònÚ¾³
+èÛÔ«¹äÑGü—·Í”b§Û'–Icͬoâ¯C
âSÛ`sDþWcüC[n¿� �ÿÌJýˆ)ÿÐ4Lªžq�¼]ñø›ºGÂ-)ßÞ?ú3O;H"&dœ’ƒä
+ã4NŽ0#IXkX”ìR0Ø/…xÅ9�þSW9eÉå\9ûäû¦‡Ô0y¤JMDÙW%I´Í"vùj›UE³óïEEχ2s

ȶÆgm²U10۬ͩ駊cê´p¯f�€xIDYìŠÖ÷Ö^ÅOdßÕ‡Ê3Ö? ÎÖ$¥ÝfíXàìÉÄÝð*#‰ðé Ñ<5m¾ƒ"D
Ž—¡uS—eýè¹õÐuågËÊ'?KMÏ?º�ï$ŸaQ+™Åiíx=æ™}®i(t\Î¥Àgä4§²‡¼ƒ·_Þq�Hx)„¹3é¯ò_9—•K”>Ò辬ﲒšÊ¢i‰r†„Þ›wžã\˜’#�O=‹‰ªl—ÕäûÏ„"é
Oci¤Á°åš¼ò·o—7¯ÿMô$d÷¹sp
+½¸r™ßp{ª
#§PæÕF½â_[·V�n‚J™ÐÊö7ÁñNo>TÝ<‰OU QLE	‰¶‘i$3R«®V‘
+¶t€ù»�³h¯€
+Á
é.¸ù¶™.k�Yê4Ñ­óMv(=CÑœ$Ç|÷ÐúTçÕêW®yå_ˆïHãº1¬2Šlað‹élÈ¢1~&ö¸.dÃÀ…{µË~_„dŒæ]´Å._ÕYjÔP³›Ëzxž5pTëD¨¡7ÕT0îh‡ì
+‚´‰UEçGè.ëêžNŸˆÂ¬
+�[cX]õD#wEuhsßLHBê.ÈÉ÷»bA Jè*Ò!¦*ð½õ¡BHî�D4H"·P©7díát`‹bwØÑËç¬<äÙ¥ñb³§Þ¬1W'/"IAYœè©{®€¤>×4’:®Q$ërIqÊÔP—5é¸FT¢I²Ô
+3Ôåˆ&Ñ¡IÑ$	I@£§âóÁé^߇XG­®ž²D‡,¡qÓ¡¨÷à‚w.áÁ%NÀ% ÇIù¿‚+™Â–8bëÿ-‘2-éBî´z\ ¸¦ƒT}hÏ£œÒ…—Ué¸Ft`+
cqDj_™·‡Öƒ«ŸÅ±*í¦àµªð½�øhå¸]´"*ÔR„)Guæí<‚éÊ2͹Ö!™h%ñ:ÄÒmÝ4¤ú\Ó�긦£Õ(¤ XŽí3ªt\#ºÕaJñeŽ�R<@Jq>ˆW\ãÐ.^Ás$^Á@¯xÀ�uñŠ¶æˆ!ßãã'x¹Q~K<À–BF,˜ä¯³$œd?sÍÐçº
+,…ûyY
Ï3"
+š{ã%�~áéî1ÖÄ€~ã‹
5ø°H²‹Ì¬»;Ï›  qpµ%���ðVíÞ!,–It�­¶ÔÞ”ò@g 2z�é}“¿“†®T°�Jwœ®ì$Ò*ç‹4Ž¾ó³UyûXï?ÒË]V­‹u»eÃ6…Üå܉8!ừ:$µm�@;-°@3/¬/@¤á3ðØÞ”ÍÉœV4»÷¸ÅÆ•Ÿwˆî!�¥»ª€—Æ�dá0e¼¿
7¹ØÈ‚S—O�°e´áŒ:†ú¸¦)€Tä¸j!"—9Þ$´9fJ°„ïq>ÏýÕ²ƒ¸"Ž ìqí\„“ w˜M«ºZ3:Á.iex·§˜Ñúä@9Ö$Ÿ*xÄ‘)¦ÆîsM•Žëd{ºžDaXòŒtÏ3"|Q¤bIe ýÍ#m
+}FvPœØ­—V�ýõf,$
4"¯÷p\ ǃÎ}UûRâkFîs˜Öv×J_bZÁe20­?7ÞiRÜ“tÉ7wáz	t9
w1†;ˆutK[8Y¥'žÛ]Ñ—‹Ÿ&ºP8¸%ÊšPÅÐýš^M÷�cb7RÃ4lÉŸ‹�iœš“
™'Æ2‰éýb4é1M“ÀÔÿøãJ½M½ße絯Ô0N©‹tLç*‹Îüh××�¾Ä	«û¥.¾®0 qçûÉJHys¸A�5k¨;`~5+­ªù~,k©”‡¼z,@�G˜`äB2ójqúIöÄ#˜áîË(�.ª'?ߨ;hH2�;øe(sðŽtˆßå8à`ãN¡	Cž"N0�˜³èª�Oh©+?¨%ôxï1ÇbP§]™äjz®sw$­<;¹¥ãöú� ÿ[®éÃßé¹@£˜žMüÖpƒ(×Ãð6i/(‡%þ´‰¦¡ÚP¹eaè¥^Ý~ L­®4ÀV
+endobj
+1312 0 obj <<
+/Type /Page
+/Contents 1313 0 R
+/Resources 1311 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1310 0 R
+>> endobj
+1314 0 obj <<
+/D [1312 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 374 0 obj <<
-/D [1248 0 R /XYZ 56.6929 401.1388 null]
+/D [1312 0 R /XYZ 56.6929 573.6377 null]
 >> endobj
-1006 0 obj <<
-/D [1248 0 R /XYZ 56.6929 376.7118 null]
+1061 0 obj <<
+/D [1312 0 R /XYZ 56.6929 551.8981 null]
 >> endobj
-1247 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F62 995 0 R /F63 998 0 R >>
-/XObject << /Im2 984 0 R >>
+1311 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F62 1050 0 R /F63 1053 0 R /F21 702 0 R >>
+/XObject << /Im2 1039 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1253 0 obj <<
-/Length 3630      
-/Filter /FlateDecode
->>
-stream
-xÚ­]sÛ6òÝ¿Bo'ÏD(>�xL§çÎ5Í%îÜ̵} %ÊæD"]‘²ëþúÛÅ.(’¢dgz£`±Øo@Í$üÔ,³BŸÌRŸ+•�-·rv}?\(†YD Eêû›‹ï>˜tæ…wÚÍnÖ½¹2!³LÍnV¿Îßýóí§›«Ï—må܉˅urþýõÇ÷Ôâéóîç�®øåóÛË4™ß\ÿü‘š?_}¸ú|õñÝÕåBeVÁxÍ3œðáú_WTúáóÛŸ~zûùò÷›/®nº½ô÷«¤Á�üqñëïr¶‚mÿx!…ñ™�=AE
-彞m/k„MŒ‰-›‹/ÿî&ìõ†¡SôKl&¬NÜla‘9˜c’ÊRHT[¤Ög´é¨¬Õ•#R¹)ve¾Yü±/vÏ‹]Þã}+'…öÎÎú“¡ÐAMà`z8(g…NÓlˆÄ—MþX
-,Ñn~•/墳ÙÇRDŠû¦h¨”Óg[Vû–gÊ·õ¾Bü²l^¯©­½çÎfÓ­H»¼\
-¹Ó[ó
G«$ûGËÚçº3““Ú±oÇÚ.‰ÚÎi»µ¨ºpŒ:ñà¤~xŽ4dõ°]¨4!TX1`3w¯Š`Ú𠱺oˆ€P<A�ü	 É·iÀ4I³AN)¥…² aÏk“Ôu¡uvyÕ¬‹@�źÞm�®c¥b˜�G¢ƒšÀb¨V¼� Ì‡hü7ø
-ÊÛ¡†ªK´X¸å~:+,ñ¡„AO5Và|ÀNxC(m¬y3eºL*2ß©œªXÀúO0þøÄ`‡Vu6fJ,D&}”Š->Ï7)ÌŒŽLC.º:B%#ãs3ÍuÔ%@ÈsG9f;%¬ËÌXÅÚŒmZ\j‰=,BÙÁ!°è*€š¾«ºÁïbp’Í
-‚��Ž;y^‚Œ(hòMØêO@êýÇ/Ô²-š&¿ãÖà`+kÁz
-ˢߺ$¹¢!‘ôÔ·šÚ“¶N
-+ÉdØä-XcœÀHt󟨓£�P¤˜V7:á¨ÛÃ!Èèa‹0�%‡¾LüÉÀhX±pèK„–ëê)çÓÀ0BŒiQ7Þƒ®H|ŸÄ|þ±gB(¦Èo@ÿfkur‰wCß|ÓàÑKÓ£jè@úá—Ù¨s§*—¡©nê57ýçÒZà¡UýÔÐTUDôì¹Û
öàY»‡ãL�O^Þ½~i÷àû¦2í«ÜÑZVØÔ«oÕ©I7d›?“§pËÞE
{Þ•«UQq�¿9}xöƒ>…¡y#ŒÛçWº Ô�é¬Ï6A
-Ôš¶‰AßâÏ%x<|þëñùsvŠœKí)|šs�~´ +Ç
’H,ÁœO:–`c
„ØJ‹ŸâBP}™Sî.ìA�áÂ5äÂhǪ㬸¾iæÝy,:¨	4†™n%ÒâÆ
œÁ”½´T)AN)yPçXáµ’}^Õ{òŠ˜±é–!�xo0~ÇJŒ(`=öLÖä(!~ž\
-@-d†l1vœ0rY:ðœp«Á:°0K°ÝéÈ»
6Cq"Ø(=a3%�±³óèÕÁfè”m¦•[‚#ë€-d§”Y‡Þ’Š­¡u`Ó?Dì C¨ôñ˜†£ë„×L¬íùƈz¦ÉûÈÌÀýÄöš¿9u�ÝÏ0”ÜÏP|&0v?±é„û™@Lcœ3ÀÂ`u\ÒåHîwD\ÄmM«M/
¡.Äÿ‰RéÿæéíÁš,uê´Žì Ž‚É—Ç—�`X½N^@¢ƒz
eSá¥}cnª¥Y̽t	�pñ'»ŒŽ9¸@FÍóÕŠó
ŒïYiâ—u.@Óå!¨”O�	•nÞ}¢ˆqU,1%Å„J�1Îù!CO뢥LSF"νôgŸ:ýo=GW½×@Ëî0'«¢ë˜
i2Û϶@�7Ëôôfêâ�’ïÖq>Ž/c¡Îs§ó_Þ¢ŒÇßu!»6€wÑáU况—
w‡5apÌAÄùVÏ ²Ê%õïV :µ
›Z^LL\84%k8˧»è¾¡Z80´~Èy¦2~KÖq³	ˆ@[´fPŒ¬‡Eb/(í›=K“ÆkÜsaÈ—ZóÕè—K5' ®wë|Éc~Ó:Ynêf1uNà%"`‚á°ÌËaã@íCGn­ÆûÕ O
f€m÷qÎüá¡ÈwÔZV¼Î=Ï5œÛàÜÿ˜Ì”('¬rчëªE'ùɸT$R�ÓÁ¸ò›`#<ÄRS×*Æ€¼
1+®Ü”¥À7CáׄŽ˜y÷6 ä9 
lþ²Ä„9Í2a¢…¾¨»ãs‚¶9wéh$ÄÎ]ZýÕjOËÎÕ&y‚òøN‚"HªÁ³;DÄùìNð•œY`hX`¬sNÕh�KJAÀŽ
-u±­wSgð­��ÈúLÎ#SÙ[0X_‡!^Î�êAÖ»Ûïòx"CöyS¹JÂ
-‰›i¼¿rIöšK&ﯲéK dR'\ªÝé¹hœ„¹¸G§ZDìÊX‘x­ûATwVH@DNÒ™ò™ðœ*¤ÑÇ­G!Á
7:’úçË…Sóø×ó«#ÒÀ¤,_¸2̤o¯fÌ€“>9(‡Ý¨¾»ÞêÙûö4ëo+μèOör8~´ 
ѤsÄ—_ê
*V2eàEú¹V(*R~
-ÃlÊàC_ÃC‰®á�çŒ8ÄDÀ=ÜR´-IŸã7E¡•ÄŠV
-×é%ÁD�ì„ÒÓ—'õ0Xè,ëò¸oÉ©N#ýu”Úšzã
-‘È—ëž|¼Ú;‡¬órÓ0Ò“Ïð||÷€
-„’:^•�æôft{þj÷Ȥ�½�wS úĩ缨•Ìä½�ììÐß~ê{x
Ž¨"=}úF:pØ|‘Â=X;ÆÜšLØL§¨ÿß»xÊendstream
+1317 0 obj <<
+/Length 3275      
+/Filter /FlateDecode
+>>
+stream
+xÚÅ]sÛ6òÝ¿Bo'ÏD,¾?ÓÄé¹sMs©;7sm(‰²9•HU¤ìº¿¾»X€"%JN&¹¹ñŒ¹
+g&¼»ý×
Aß}|ýï?^ÿv÷ýÕÍ]w–þy9“x�?®~ù�M–pìï¯X&½Ó“'h°Œ{/&›+¥e¦•”©g}õÓÕ¿»{£aêÿ´t™vÂŽ0PÈ9X™‰Õ>3†��»kî¦ESï°(àxÜÆÞE¾Ë†:óøÝÖMSÎ×µ¬Ú:ŽÓgS4M~_dÈ €÷)ð"ƒ›ƒÓ„½7yõ<Ë«æ©Ø5»O¯�{æÒGä2î¾!¢âîÅ
+¿2&eQµ¯ WÈé|ßFâ⤺Z?Ôì·Ûz×KÜp2†eÎk1™qžy

+¥“*I:g#²�ÖNÊ0Sào+Ræ"7¢ :sLš#
I×x´ kt=Ý@Š›m�FÁý¿*Huè
+ä2.„4HqÐ l$
R‚…KÃ> 0ª¶H…ê©¢“
+á@P!泯BˆzF…Hs€XkŽ\ÿæá“I-Zâ�}Ñ´Mú. â‰÷¿:¾ÿrS¶>•ëõÐàÓš«}S,3òòwiÞÁÕA#jpØtLƒ%‰Ìsñ9*|F
+µ7™R\–Â>Öy)ì°†R˜üXÕœ£6™uÞ\¦¢Ã!cpbÃ3k™ÒAæì ŒØHÂ( è
+wÈÙÁœcƒd¡ž,†æEEQ±k1Odo0�&°8ŽLV(!}žB
+hR><*‚îÞ| 
+1còN
µÂ…‰`}ðCÁ3Ápù-yÇõ:}É›
˜DA/€öÍ>2K�Å{<D`(—‚ì’Úk>%$‰…®b·ÊqίB¨Åºnfc÷Q"r
¨á¸vÌ>Æxq÷ì)àHB¤Í>­™o·E¾£Þ²Šû<ĵ†kK\û£•n2ÍMòÃÀœúiÖiþH1ÎfŠ‰d‹Iüh”©è‚eæ!—:rN�R‚¾
3«Ø˜T¥€LöHùP*¤™–+B¤¸KÆ¢t€Ï_”X𣠙©È´0–l7M
‹ã~B2È�…+á\2{‚u¡6él�“)p †X
‘Ý!à É�á„Žù?7ä�¡cà�±Çsj&üXR	v„�FbÑ
F’gFð™� DYï—ä�¡;
+•iñ¹áF»Ï$t(w–=•íCY]*R)›Y͛ÉOw
+›¨­wcgˆ­�NÄþŒ®Ã¬O�ìÖïïKçÀô èÝïw9)
+†že]D|ôu
 z8dD ;±§h[Ò=h�µÆ^R*Ú
,>Y{h¬®!ʉ†õÈ·Pd1ŒX\6ýÿ¡¥¢N„Py™DÛ½kþ2Á�4br2;<I}™XC*—áàôP*w©Û3dã—Ãê댛=š¡4ò]X­¿Ãid�°FÀ*Z%�(éÊ;
eë:<�äÈ&ãbümá¬í\WÆ}u¨Mmc鯓ÊV,Zå݃½2àóE±<yM€(՜͉œ×`Æq1'êc�¿¼‹“vö)yäã"	i„ŽáÝ�ÛFS7 ä5:ck‘ bWå!¾²¦W%ÄÁ~d�mŒbðK
+èä ¡g]6á¹,`Ucy2=3Ö}®/62MYå庉DWË1'á�WÉdC–0Cn§÷2•9/õx¥áÅIÚÎé¦*°€g}¤`†•_ÅG:,¨Ï°ta‚ôg]$W`˜˜/ùH
á“…¤ø«úHn±°%ÝÿÀGö—¾à#¹ƒ Þ Ñ·á}…MŸÑëÔ{j,±ÆxôózL%Š¯5Œô%a•A�ðá»	î.(¬Ò9EĨé;�mLe±,ÇÌ�‚æ¡Þ¯—.âÛ«‘çkfIÚI¢‘ØR�@’ì!O¸È„ÖÉÊB&¶«·1f€Sa‚©©
+ÎA¼µ•—�R‡uÁ)�E,2ÄþýMNýRD!eà—FdViA¿$,ëû%lö^¯ 5¨8YNÙµM‰�e1Ͷ¬óK�û%æ2λø<Ž¨w*S\‰¡o
+„�û&0M‡ß_ ¶’Z(0ÊNXuü^{6J8&ŒëjÊ—|SŠZ¬Í„5/D6=¤ó2”�NíÏåØïÝÀu_¢¤C:%e CDM93 åçð¢í’}p~ LÎõ…Éùž054\Ç
°háÉISñF0qoâ’]”	ý½"�¶TÃq®_Äþz¬¾úb™0úJU�={*Ö$E5œo®)½¥¶ƒ·Ö(
+£;rÈá­ð©Ôð\Œ=W@ÀÂù•iË­ý_$ºTHØl󶜗ë²}Tž�û)¡ÔþþoäÎY„|ñÏ¿ÁT6ÛzæIÜ.(d‘‘(<§¶Ç”w¿G<%ýo
+~_õendstream
 endobj
-1252 0 obj <<
+1316 0 obj <<
 /Type /Page
-/Contents 1253 0 R
-/Resources 1251 0 R
+/Contents 1317 0 R
+/Resources 1315 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1255 0 R
+/Parent 1310 0 R
 >> endobj
-1254 0 obj <<
-/D [1252 0 R /XYZ 85.0394 794.5015 null]
+1318 0 obj <<
+/D [1316 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1251 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F62 995 0 R >>
-/XObject << /Im2 984 0 R >>
+1315 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F41 925 0 R /F62 1050 0 R /F63 1053 0 R >>
+/XObject << /Im2 1039 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1258 0 obj <<
-/Length 2802      
+1321 0 obj <<
+/Length 3347      
 /Filter /FlateDecode
 >>
 stream
-xÚµZÝsÛ6÷_¡·£f"ß/OibçÜI�œã<Ü´} DÊæD&‘²êÞÜÿ~»X€"%Êv'm2c‚Àr±Ø�ßîÂæÿùD›Ø¤"�$©Š5ãz²¸?c“[X{Æ=Í,ÍúT?Þœýp!“I§F˜ÉͲÇËÆÌZ>¹É‰L,â)p`ÑÛ�W—ï¿\¿™&*º¹üx5�	Í¢‹Ëç4zýæçŸß\OgÜj½ý×›O7ç×´d<�/¯ÞÑLJ�L¯Ï/ίϯޞO»ùéìü¦;Kÿ¼œI<È·³_~c“ŽýÓ‹ejõd/,æi*&÷gJËX+)ÃÌêìóÙ¿;†½U÷é˜þ”°±‘&�‘�/ØVZ§E;¾-›Ì¬Œ�’éi^ô^~¾²šYë4Õ“™1ä´ª3¯�ÎãTk�öµI,+&‰”1Ã)0ï*ئ±6Š#g±–B
s¤ø8�ÝÀO™Ãš8SL6å7ž|›ð˜©4•DÓ»“î5à&~¸¼“w5œgÒ?’ç;ë1v'2¢ç°\€B¤’“„%@•¦NàËåt&‹§‚Eõ–^òŸ<ªê–&vesG£ö® A¶j‹
ú_Te­Ÿk7S+U³œJá2riêíf(jzÎýû¶)òW84C	š»z»Êý¸hIïFöŽ>AÖ¢ÈF3iÖnÜöÜmg¸;@b2Ð	±Ð:ñÖËÖëM½±¹ŽJ8Õêq
-îœÀ‰r Œ<�ê)�¶´ÄıSòb]T~r»®+Ü…õ[Í:'ƒo‹¶-«[Ðcb£Ì?ªÕ·ó‡psól�‡øJo¨E÷DcààWÆĦiéeS,7Ú_¾mÉ(:è2>ôIeÒXØÔNúáð}&!tL
-p3Û£Ä÷ÅÿL¤±µIêLs>Ü<N87²™u‘ÍG€»£r–ï\ÔÅ-¹Í¢˜=˜C…q€@©
-
ÅÀ¼"‘È>a’11t,YÄ(ÊŠ
-¦Ÿv£Ñi/
-DÇt$õЋÀî ö'%鈎Eø�
_cBdùÒ ñmÀ›œ	ç÷΋{gjh¹ö€j1B™v™WÊb×x–îÏ°Y‹�ȹ¬¶w¥g–Ël»jýW€^Ǿ�y9a0ÀcU�˜›C1ÃMêÍ]Ã
7�Ÿ
-²zÙÒ³·¥fã[BE'"5žÑ#}d³$VRiOó+ÓléT£û噥Ǣ¾_gm9/Weû¤ü´ÿI@]ÁÅ3Ø£zÂ)¬-—�§œÞÛ==³;`¦böéí´‰žª
÷ÚÌðÈû²BŸ“LE»»ráÊ­êE¶¢Ù>ÎáR–çävMƒ•·”ž‘´^·e]e+ÌÛøþåÝ'úf]oZO¼+Wžñ¼ð™ý
-+Üf•=„a±yÀ…jÿ͈KHÞ\tÅç}8¿óbic-d@È?03xä…T­´"ïb•m1ž¤TðéÄ”t="ˆ¡�ú¯w3r…Yt'‰E{¹†‡åÁvM@u_T­-Z¿€j	e•sjÓ¸¡QXlPÞ
-gÌœgÀ
-”0ÐFp±ƒÍ„ŠYÒ!.œ|Ä”<¶F—vÊåcDÌ=´øêá¿ò€WL®0'Ýn7bMâ̪8BçÐ*­ ¡Jø_Ò¸&
-\ÇÏ„Î_<8§û^w
-ÚâÀ§ VPt–‚»¨Ã)
-&œÙÃ.ÎìâüÒÙ¢¾«W!ëB¸Te÷E>Ö�AQn�ôT¾	þ"vpý•ð—v}á¨ô@övÄy§–æŸP²ht�d®[…u™Â¿W&ÜW%‡wϨd>L+Š>"ÿsX£IÕtÎÀcÉ´¥ÃþîåÀÝ£²A5ãøË!='2ù“øÛc‹ÝÛL0N8ÈD
-~ê:ò¶Âpf,ÌáxŠwWÐîÚ±!¾]ÚƯöm•gÎ�aÊ
=5΀n›âµ7ï]ñ8äC
+xÚ¥ZÝsÛF÷_¡·Ò3»ß\^žÒÄɹÓ:9Ç}¸éõ�–(›ITEʪ{sÿû
,EJ´�L’s?@
+0��ÖOò¢÷ðâf|cÈjµ›ZoRŸ»ì
+ŒPz‹­�À3`!’¦
+fÔOÁ‘¢'c_ïè%ÄZèäsyR‡£1„l¦õ
=hn{Ç
ãº_5Eòi�þôŸp
!¢œqØÍØÙOÀÄB$³«¾>#hÆDÏkÑÌdpT´"-ŠÛ:žùûz”¡Eµ,n—Ü�¶Å:ÒÔ銥9VB½,3å_Åj³,]0e;’°¨1#§¤q$%
+>kún' ÓiÆÏDk‘ü—Ûb}WRS«Ìyj:kµ}Míÿ½‹Š#‡§ÏÖ
+ú¡0è+GÉêpØGfiþ
I‹•ÑöHêU˜×9ü{E8¢À{Á%³á ‘å0¤z‰ü/ÀŒ%SÑ…
4¸Í Ú©oÀt¨��¦‡^`ê3�}#ôöØbý6UB
+qN�ÅpdCî
wýTƒ23Ûʼn'·ê)!biÒ¹M�3»¯ë†Î!Hè
+£U8ï0
+r•mØ
+z®ˆ€€ôÄ™nÍ¡óØ{Ë-øU?ÓG¢u³´÷õn9§—¨b€±»²ísu‡7�
IÜæª4DoÂûÙÝùh«:¹0|O—B–�7<Éb�®¸+ª5^@I“\Õm	˜`¥b�`~^6iÄÜQ±Ž6ŠeSù-OÑ+|(
+ãëõzÉ’ÃVŒƒÀð.íEPÑw‡ë‰ì�„˾#³·<a+äSF¥^)7À™±cË32²¦‹Ç†øva;löÝz^?†¡
+ìÆZA%b£‡“ÉËp
+´ÔÛ’‹ "“–«Ë)l·ñýîø^<KŸ«�V9‡MƒÎè¦á7ã,Ïì7oŠ?*80ÔÌUšy§†G3¬ÅB­Øåýù!øC3 ><ë2½…[Ê�Q&T¬—ccô_‚¤¥„Ùœƒ©¦ªyb‰¿Ühù•>ïŠe—ÍÂG³ O'£jÆ�3¨Že›È¢.Š ð•»x·
­$V�ÚÇŸ’à(oœc
 ßm¹µ,CU#ûÃ2@çiHPÓ�"ÆŠ:ï®>Þªf”yž|ÿ»§/û%§R˜&ê\Ъ1�sT£vÛrÝ*mRïÅQÛéps„c=öÓ„Há8@ðÇË7�œO@Ÿ4n‹˜“€[ØÚGj>ØLP^ñúª…édK1¨\‚2+©É—DšÍ	ÔÛ¢jx2Ò¢¹íEsÏ+´bûÉ­ë’[G�Óݺfú]j¡>�4LJ0s‡þþÄOÄ´Mñw]#(%ºïîßýó±Ãoë ìÐÞ«q¼S$I˜°R¸Ö?ùAãTõÿ5µùÍendstream
 endobj
-1257 0 obj <<
+1320 0 obj <<
 /Type /Page
-/Contents 1258 0 R
-/Resources 1256 0 R
+/Contents 1321 0 R
+/Resources 1319 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1255 0 R
-/Annots [ 1261 0 R ]
+/Parent 1310 0 R
+/Annots [ 1324 0 R 1326 0 R ]
 >> endobj
-1261 0 obj <<
+1324 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [442.7768 250.2874 511.2325 262.347]
+/Rect [442.7768 483.7823 511.2325 495.8419]
 /Subtype /Link
 /A << /S /GoTo /D (query_address) >>
 >> endobj
-1259 0 obj <<
-/D [1257 0 R /XYZ 56.6929 794.5015 null]
+1326 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [361.118 212.4953 409.8647 224.5549]
+/Subtype /Link
+/A << /S /GoTo /D (configuration_file_elements) >>
+>> endobj
+1322 0 obj <<
+/D [1320 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 378 0 obj <<
-/D [1257 0 R /XYZ 56.6929 318.8054 null]
+/D [1320 0 R /XYZ 56.6929 540.8756 null]
 >> endobj
-1260 0 obj <<
-/D [1257 0 R /XYZ 56.6929 288.9425 null]
+1323 0 obj <<
+/D [1320 0 R /XYZ 56.6929 517.8101 null]
 >> endobj
-1256 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F62 995 0 R /F63 998 0 R /F21 658 0 R /F39 863 0 R >>
-/XObject << /Im2 984 0 R >>
+382 0 obj <<
+/D [1320 0 R /XYZ 56.6929 293.4989 null]
+>> endobj
+1325 0 obj <<
+/D [1320 0 R /XYZ 56.6929 267.9627 null]
+>> endobj
+1319 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F62 1050 0 R /F41 925 0 R >>
+/XObject << /Im2 1039 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1264 0 obj <<
-/Length 3378      
+1329 0 obj <<
+/Length 3260      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥ZK“Û6¾Ï¯Ðm9U$kOŽc{�JììÌlí!›EQ3\K¤"R¶'¿~»Ñ
”(M\©©)âÑD7€î¯”\ø“‹ÌÄBçÉ"Í“ØiåîF,aîÝ�dš¥'Z†Tß?Üüý­Nyœ[e›`­,Y&ë_£×ÿ|õËÛ»Û¥2"²ñíÒX}ÿþÃ4’ÓãõÇoß¿û÷Ý«Û4‰Þü@ÃwoÞ¾¹{óáõ›Û¥ÌŒ„÷¯pá…·ïzC­ww¯~þùÕÝío?Þ¼yöîW
-�ùýæ×ßÄb
ÛþñFÄ:ÏÌâtD,ó\-v7‰Ñ±I´ö#Û›û›
³îÕ¹ó3:‹M¦Ò™Trî
-&«§tK�€E[ÀÁ‰òmÚAëÐAmjÑêÐðÖæ¦Ý¢8Ø6	¶]U'/­«®<Ôû¾ny¹Y‚‰ØèÔðÖºú�ê5 V–fja
«e&íŸ
B…–ÍÃàrXq.yŽqÚX¸ŸtdìD��¹"¥âD¯àtâ“]ä"N¬H'» ÉÃã‚w
ô32NTãl]ä_•ãÁÛXžJ“è4V2É'Òœù‚�êÎWCbV:0}™J—
\È
-�»=ãäÃ�öþ\¢è|‚(CSû¢wHÀ‹$Z2ÝÅ{1¹‰U’æ×ï%¤º|/•“¬è‹ù{
ˇ á:ç�j†õô^ÒXäŽNxÓyæ2¸è�Ë¥¶»™\8)™´Úµ‡gj÷þý

-ÜZ<zŽá—V#ŸñÞ 3{o¢0ˆŠ¾ýÞ€‘FÎȆÅѨ8ͬšš©Û‹‰ž(þ\SÏ›*4øÃsÜWlÜP¸Œ<½ßÐFø„/= Í"Y¨HÕò wYôüJ¸vͼ«¯ˆ¦,ÏÀƒ÷u;NôïxS/‡õ,È“AŸ€
[±u
K�Ј£|q–%°Q<pk[ŸyÕaùq›`�#6$hé	¨ÞcG�>Ü�oÕ%Å ã.˜ Ãç 
-Fðд륶Š=µýØ�“ˆí3õAí6GDp«£‚i
-z|)˜Æy
Ë΂�ßz‚äl
!©¿"f±&+¸Úgj^ð|L�k¹ð7�VGTlÃIó“Ò'6]úÄ
[î8aæPÔO±�zvxvëíZŒ²a˜k‡0×’SÂÀ·m™~W85�æê™æØ�c·¨ï3Û|n�@, q«;Ô'P-'9Œx¾8ä”ÆŒœpÂØ`"óû‡ÑÕóÉ«Ó•)ÒŽ$3A2dâ©Î=R
-©.»¥�
-¥ø¯j[ug^IÀÖ’,½Îx šá<ñJ"‹3=eÌÁmf…iÔw+Š5SÒxz]§÷¯�Qiʈ)çÁ¾¼w	´Ê¶�k#ìhz@)eätÜŒBŒV©Ápg}Vª!‹Ð>}¹–4ôn�;½m$Vank^¸Ö€êʵz*‡F}Q~š7Lœ§Æ^g=PÍðž\¬ ø6Ÿ2Ÿ(A'&ÓzT¸”SÓ%S\ýíq¢I³1õü¦8ñ´†’
-)±Eš
-#ÎLBòAbìpš	­OǾÝ
,”Î\ü‚³k?ñoðàR¤€&ÿÓÑ—~)úRÂ×Ü^·ì€è²a{"d÷Ôvý›¾îà(º%˜Ô¹iç±TZ]•` :abØ)~÷LìD†÷xs6ó
-`’™z1‘ÎëXÿ|<ñVîEk—ÆĉÒ×�= ºlëžÈ]S¹¿häZÁª*½Êy :g=MšSà=eýà«­A…ÞŽm*
ÛS‡‘A‹¡ýðúl›¦œy>”ÇÊn:©ìŽEcÊø»$~NÈN´ù|¶U˜F<÷[‹4εJ_rÖRêX&òoR]¹tOE6âÎa½ìÚòS5sõ�wÁ¹˜ëT3"LñÝÄ+eSÜ‘Bp3Ü8L¸Ç1\cÛÿ^ =t4ÀY¼Û
½æbuœB]��…GÝ®_×-¶MU}	`™	ˉ¤c]Ukn¢•ãsUÑ’«ú‘qßÄZ�èF&]5íñÑY2ׂáY¶ìJrï_²À]qL
OW1Øôû" ƯÎkšÚB„QQ}ñ�ÖŠ‰�º™‚ßüR‘Çò#£,6®×‘R¿ÝÍ…¨ü!NÿØ?¶\s÷v�ß�‡:®@ÏÅûº�Œx þÃýÇÕß1¦ÞT‡Žkê\o´a½Ñ^(X	Ê*}µØHuÑv²ÑÿEMÀ’ºñ•Uë];gùAÖ
ÎÔ&')»TÙœß�L?¡¢cH<²$!Š%#çÄ\põ2ÇhbøA֟ล/fŽ¥«OoÁ®�yèòžS0dÎ
;89zí™+–=HRh nÆݱ“1ÀüI~¶9öTG«âK¿QÔ
+xÚ¥]sÛ6òÝ¿BoGÏT<|$8÷”䜞;iÚsÜëC¯Ù¼P¤*RqÜ_ß]ì‚"eJnç&ãp±Xì÷Rr!àŸ\X�'‹,Ob#¤Y”Û+±x€¹o¯$Ó,ÑrLõöþêïïu¶Èã<Uéâ~3ZËÆÂZ¹¸_ÿ½û×›ïoʈ(�¯—&ÑÛÛ�ÿ$LN�w?||ûíOwo®³$º¿ýá#¡ïnÞßÜÝ||ws½”ÖHx_ñ
+g^xûᆠoïÞ|ÿý›»ë_ï¿»º¹Î2>¯òÛÕ/¿ŠÅŽýÝ•ˆunÍâ	"–y®Û«ÄèØ$ZL}õéêߣYÿêÜýmccU6s�J�.P
+€“t‘™<N5Lá>·8‘È£§ª{DÈF}K˜ºÚV=£áŠm{hÙn·uÛvÿL¸CçÖ„]=Ÿ¼Ú¹ý·Çý2CÚ#	\$°+Gì*8L¦s<&2º-¾.Ë¢|tË®ú=Ð��—Áj™3yѬgÖ”n ÑL³wåaßU_ÜIKmul¥Ñ‹¥”qnŒòTe]¹¦ïfvÔ*ÖÆ&¼Z»ë«¶éH?ª¦ë]±Ž_(ˆˆ…
Ýͤ‰³DËyƒ`¢å˜Šä)ç"P!ÿBÕ®;Ý”1¶‰Í.o<PÍì<Õ$[=ÝøÞËYg(¨j{ØÒ 9lW t{}�g`Ñúð«/�Ê£môX|áévç‚ʶ
±í¯¥�@.õóµ”2»Õ™X»Mq¨{Z¥º–Ë/_ Îtœ¤Ú²
+H{,Ù=F™‚‡è „ˆ>�x¿s]{Ø—ÌíT›9!K•�ÇɎרUmÚºnŸªæ
‡öè8p®s=
5-J
áú°B¸Gp¦ãÉ ºtýàá’iÁ^ºÃÖïV)x�‚^¢M\³iùÅ5MWMïöMQƒ�ù1¸tô“bêg…»/
+þÍgð–Û³Ve2ð9—­jLuÞªªSª¯êeÝ>,g-,•q¶p™��j†�‰…¥iœ¡ŠM¹¬PŒ¹fe@XEnÕµµëÝ?®—IšD”ÇÓEYº]ï…†£fÍÓ
É3Ì x=@ùÒXB”ívâXUuÕþ4ÏyO‘•BdLÕTòÌëK‹Ò2ÖB�#÷ÿÀ\@“ÎÆnˆ'²=z
”xÝr(-XGÀê‚UjshJº'
+¶ôå}çuIÙX*™¾¢K#ªº¨Î�òT�¡’ËT3,œª¤+vÊÃ'ç=Fâ/
ƒÃÆ�çÊC¤	
+9Ô ñD’Ärx„!+,÷Õ®o÷!¸YàO@¯ù’
+ï�˜sQ€|ê¾qûÎw5ÓÐÕLÇ]ÍôL[L¤ ¬2ô¤�TgmÇŽòécë|IÕ„þm	¶Tg÷ƒâBjšœt¤²sÑW@†¢ô¨C¿TIð,ÉØ‹%Ç�s&àËsŠ°ÚŸÙ±v]¶ô-)Ú3X°c¹»üÄ•nÎuL…PG¯=°bÞGµ!ªæx:õà¹UvRn=µë\<(ðŸÙqcˆZfdžÇcÑ…@Ø÷5ûU·Áe6ྦྷ%ÏÏ×®°Y·Oçë¨páÎ^	�#¢óN2Ͳ™æÁ:¹Î.n>½Ü}¢ÑÆÆ"3r²=õ[;î‚¿`á„Ï��€{Õ8ï3–ÄÒ×)¸Yº¯€9í¾Ê³°L{É#Îgf E)XWèäG}H°³�Ë“®@hª§Šë(­‹¾ Èë<¹S´-�œVq3!•@äU¦|ºä=¡9¾:„q€9Œû),9奨XS‘ûº«BóÇ;Öÿ"hó|Ç`EiŸ�$õL"ê
›èÃÝO4	Ÿ}Ñ»‡gš â>	9‰	‡
 |ª„Y²L-¹¯%Ä(jQ¨$zCdÁ½ 'zŠé¾ò-j¼7ïŠ]õlÜ÷ÓùòÊyl²'pOC{þÁç¿€¢ös»%jV2D‹`Ûø<@O¬Fž®ÚÓ÷÷x«£T|›JGoà|gù@ôÒg÷üÄ|²sµÓã^lÎd˜�„`‚×ÔQo™N’Ë‘ù
6T&9UGˆÒj¹
+=íCÓU
u¬¥�ónÏ¢k_ÉË]þÝ7æ,*ƒ«|‹ÓóñL5¡­xŸè(/6´ö
+°bH${^ª%4¬æ¶!LAÃàuEõb±6©vuà²rOTÑŠÁ[žk°w�}ÔšR+ßïÛè2êðá±=ùðæ¨Â?@¸ñ5èÇkÍLÿgƒ©2Ö‰yåsÕ˜ê|8¨B±Iùíʃ›ë,ÉLä—9¨fX8í,I¨	TsN´	&n–ÚßÕ®ôAÏi‡ô
Ø `H45_+"5¿{»™ÝÖ¾q5ÁlC½:DT“ÄJ¤zjÎT˜¢Áð/z¯8R*ÁØÊ‘sýŒš¢Ø‰õ”‚Ú¸'W]óÜcûDÀ¶hž	ò?S+iZ²`.(Ú"äÍÊZº¿5áªfNáÃé•”dö>E…
!H@_
 endobj
-1263 0 obj <<
+1328 0 obj <<
 /Type /Page
-/Contents 1264 0 R
-/Resources 1262 0 R
+/Contents 1329 0 R
+/Resources 1327 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1255 0 R
-/Annots [ 1267 0 R 1269 0 R ]
->> endobj
-1267 0 obj <<
-/Type /Annot
-/Border[0 0 0]/H/I/C[1 0 0]
-/Rect [389.4645 694.3759 438.2112 706.4356]
-/Subtype /Link
-/A << /S /GoTo /D (configuration_file_elements) >>
+/Parent 1310 0 R
+/Annots [ 1332 0 R ]
 >> endobj
-1269 0 obj <<
+1332 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [375.4723 314.3269 432.5882 326.3865]
+/Rect [375.4723 524.316 432.5882 536.3756]
 /Subtype /Link
 /A << /S /GoTo /D (journal) >>
 >> endobj
-1265 0 obj <<
-/D [1263 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-382 0 obj <<
-/D [1263 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-1266 0 obj <<
-/D [1263 0 R /XYZ 85.0394 749.7681 null]
+1330 0 obj <<
+/D [1328 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 386 0 obj <<
-/D [1263 0 R /XYZ 85.0394 443.842 null]
+/D [1328 0 R /XYZ 85.0394 661.0164 null]
 >> endobj
-1268 0 obj <<
-/D [1263 0 R /XYZ 85.0394 420.887 null]
+1331 0 obj <<
+/D [1328 0 R /XYZ 85.0394 635.6995 null]
 >> endobj
-1262 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
+1327 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F41 925 0 R /F48 940 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1272 0 obj <<
-/Length 3275      
-/Filter /FlateDecode
->>
-stream
-xÚ­]sã6î=¿Âoç̬U~ˆúxL·Ù^:mÚÛó]z}Pl:Ö¬,y-9Þô×@€ËÞÞô&3‚ ⋤åLÀŸœ™$Jr•ÏÒ<ŽŒ�f¶Ú݈Ù3ô}#™fá‰!Õ·Ë›o>èt–Gy¢’ÙrðÊ"‘er¶\ÿ6O"Ý1ÿó㇇ïÿõñî6�çˇŸoʈù‡‡ï	úþãÝO?Ý}¼]ÈÌÈùû¿ßý²¼ÿH]	óøöáñ;Âäô¹Àôãý‡û�÷�ïïo_þps¿ì×®W
-�ù|óÛïb¶†eÿp#"�gfv‚†ˆdž«Ùî&6:2±ÖSÝüóæ=à×
�ÔŸ‘Ò‰šP Ò�3™<7³ÔäQ¢¡¸Ü–--ªÙweS¼-Y•]WY‚íæVfó�]u<€‰½5f^ÖëæÔFg
-‘Q*e2KÌgé…Ñ"¤"ùå”
x*”W|Y¬ŠÕÖ.Úòûvz©â(�S}}þžjB€P�zS•%c	–[Ð�Ž3¥ÜwØÈçÅ®9Öu4&°»æðJý]C¸cË£7Í�{<¿Ö^, ÁôþÖÊ­ôÀ©�îéµ³ øE"Ìü×­­. ŒÙ"Î"�W)£ÜådöÒ©D9éð».º‚ äŒ_'	nZhÛh!‰"g@ÐU•»²{‡°†úE |*«Ê3të®÷]3+Ô~í—}IÔÞScWtG‚ªW·Já—GQ¡Åá šn[tBqJBÎÉ
ߺa„ý²²vm× L-òùa_Šêh	tª‚¯¤óvoWeQáÒAó;[ÔeýL]ƒçëdÑ/{ZÓ³]S{ãšÍnXÁh©´“¼5Z¢?Vh\RÎOd€ƒQå��Ëå�-!­ÂJã\Îï@[Ët¼"ýd_O,2Îþ͇8B¥i”ô#åX;åZ¦¹øn–‹Œ)QEm/ Më½Ç­Ö18˜LÇkõ;aØhá«ÕâÉí§Ñ0[>×N{�¸³ÏöÐRë?Âñ…Øõ@)ßÃÓ¶\miü®x%`¶ÅËB¶@[ì,Q�C¥š,†`ék"ÛÁæ•5xÒ„
“åÈâÀq¿oÜØ5Þd°D5AZÑ´Ñ„*r#8ê8Vûb…›®r›ÎÈ}Ó–]ùÂ,�’™EeÛöíDê§o	 ovsòPÐ>K·ž2Uêj-êDjòqøC”HªùCM˜‚>}è
-B«¦î(zWÜ·mNì
-ô;„–ïé©kP}µžeÁR�“!„N¦³Œô·&$ê	[ô«W.˜ƒÃx*ÀË]^‚†«6A³ã~ÎÿàOvÓGìy²ý¸}Ѷ.ÂLî#Yk.ª¤ó£‹pÁN
-!ŽÜ…„4D倛�…)+[wos:G�¢l15Sn	íÒc”‹$Å´Å:8È$’b“bþ‹=”ͺ\‘G.o%JÞ~¢æ$‹D¾ö’Ÿ�5s¦¯ûiHuÙO{*—¿+*%‹pî¨p”Hdv]„žjB†±£æ‘Œµáœ/Ö‰¹·rŽV�MÚ!„¸îj^¡	JˆuHÐ6Tì˜ì¬èAÒ¡®A’ÎÏÍÁ×q‡¸ÿ:±ÓênK_pôºã¢!K"“ÅoŠ†P¯o”�ºÚø¢¤¬�\I§‚ãQtl8O‡o"è{aÌp€W-áp•1ïâÕa¤«Ob¡Õ˜/Ö"/Že­íaCæK9Ã[Ã	ç}knïGÆïõF-vC<ЭV°}pܸ˜®bcà¤Å
BªËnÐSáJ¶¶8tO¶è®ø
ûáÜs]†žjBˆ‘Ä:2KÆR�ˆáè‚Z„À¸#ôMÍÄ»e®‹ÚY=tuWZêsqq…g‚ãZÂíŠÃ'ç?€.Ú){×i¤áÜϺ†²ü¸Ÿ0d°Ž
-qH»£t†Ç
-
-]ç){Ú´ÎïÓ¤Éβ‡ÖTÍRØNE¤Í›”Ô»•Ìg øE·ÂïÀiNíí[B‘ÅöGûÆ/Ù7B�}|Ù¾‘÷Æzœ}#€ö�ì�}C|*¡‰=¨w—9&Œ›w'Ëù"BåÞŽ’î$¢-
-3®›Â^ÑùæŽÏ<q†ä
-ìm©4S3µ/ìmÔc`&‰¥³HŠZÅl?C¥'áä¼HÔüìåÎ^yšÇ38ƃØZáÔ³Ï3°¢8Ï5°[ê ‡øæa§fß5° Y¸&f¼9»E%jô6£á<u¼’Yë4¦E¹ÛZ¨2_o•˜[n”»}ew¶îÜM"júòû@ùÙÎÇIAÉf�nÿÚnAý
-ÁHÀYexÜûk¶@ö©Ìõ((I8`Œ.L_˜ÐI³oÀ^'"®2 Œ¤áw#è)!v«�ZBó%¢íç£{-‰�ªˆý-,Rö‡/@®¶MÓZfQЧv±{Jº�B&êWB
~´âZÐ	º!Œã7QÐw¼]Ö¹œã�²ž 6îiA'šoñ!­¶S0qéiH�å
-’ù+u­*\Xçû™¾kmµÁ#UÜ‘os¼
-MND_ÿýåŸ$
¿×ŠÓê5}Ì�**‚ÂöB¡žMv~²ãß.�‹þ_±ïŸ5endstream
+1335 0 obj <<
+/Length 2714      
+/Filter /FlateDecode
+>>
+stream
+xÚ­]sÛ6òÝ¿B÷tÔLÄà‹_“'7uzî\�œ«{jû
+'Œ'“Åö†MÖ°öÓ
w83�4±~˜ß¼ý ³I©H'óU@+�YžóÉ|ù[”Æ"ž½ÿøðáþ§?ÞN3Íï?>Lg"aчûÞÑè§ÇÛ_~¹}œÎxžðèý?n?Íïi)u4~¸ø‘ }.}¼ûp÷x÷ðþnúÇüç›»y—ð¾œI¼È—›ßþ`“%\ûçË"O&/0a1/
+1ÙÞ¨DƉ’ÒCª›_oþÕVíÖQùq™Š

+>&À¤ˆS)d/@žÆœƒ\cÑ'³/›e¹ ‹Î§œóH·Ÿiz_wfÿ¬«öìÞ<Î8O'™à1—B]à“�f!Ö6=²¹¨Œ®Ëz=+§p	Oy~�…k„ðÀes%ù�‰ù¦l§3™‹¨ç‚fjVSžG+³èÊgS½°yj›ÊtSвŒ¥Ñ§=¢™ç²9´€…~3�)žDÝÆЦ¨›=�_šCµ¤!mÜ6ÏÍ|Ý•[¢<@Äjˆ˜ó¸HaÙ&Œ¶9ØÁ÷&…ƒ.û]¶\ÙY³¥±ƒ…^ø¡
¾^ñ°“WãY¥
+�óÅ÷:rÎc¦RîvlËúЙd”ÊÌY"XЧn^h°Õµ^›6dÌ^]€Þˆ‚û«“{Ø‚°ö¯„[ÂÔ4ÔŽ]ÞÞ,�ÚfïÛ•Ý™eVmŸ
–uí€Ë†NÏ�§.”¥}q
+Š_4+ü	‰B�,Øë7/2¯ßávÔoü’~ã(ÐÓo¤�ú�+V¿q€ú�ä­~ƒ²
µ$® ÜmhQn÷:y
á#¥(¼[ :#Ñ“Á`ÑÔ¿3&Ö‡½v1¶ ¤rÖxá[5zi–À¶yt»êÌþ„òLKƘ×<¼çíɬKwj…©gcn‡¢·LÈbqðå
+9w4Ž'UÕ¼xJO£#;�yŽ¶”8�tnÇB†Ç\üäIP[Þ�K²éÑÐKµ]³£�Ôg/>ßïMnOw>eyvþoMÎOxÑ”,_vz,�Óo;½
+<n‹,’c¹$/þhA’*nUb#–Ȥ!áãÑþÑY$Oã"+ÔD1(¨ÖàèÉ—	‚E!	)Û»e`
oï·bòc7š„—r„g!e{©T„Z.dœJ%'ŠËN¡ÈCc3¸<z�
+¨ŽÜ¤Üî*³5µ­- ¦¯ëÁ¨8{z•P/@J
+÷ûÞòXpIj–cèû´i¨`£ßèÄH(‚ Dô‹„ëQ‡¨Ù5`¯#.4W¤�;)ra·¶ÎÁ¶X…¡ÀÊ£^·~26J Ø|9è
+#	wÙ
!Âìk0
+qXA€tÍ
+’ˆŠö’�à‚©¼æ iw”nÛr]ÇŒ;RàK`êtͲ4–¶%ZÕCSÏj³v­8Á=y¤>z�NÁšæž$
Ÿtë·ÙT\Ø´¿Üh×´%Õ¸`…
+õnLåÿ$€ó–§ïh"‘’ý÷�ëÜ��H‹çɱ/-„[š» L}8[nðØ‚	gôuý
+�Õ-ýt[D’ÄøX‹Œ�Õ
¥²JF™R	\¶ÛÐ2±óua|û0щ Ø3ª¨�K
Ee•4²	ˆžM˪/ïñt§û°§t´�2‚:Ñ€Êh¯ð�«» ¹9þƼf_óõý/*μŠ:»;Wê£þÔNUÛ~ªR+Ï»`÷o9öƒ®Lbüv¤¦g}ÍôÝ?ö	WY)¼o@åC…-=S6-gçM÷«ð9ëÿ‹aè�endstream
 endobj
-1271 0 obj <<
+1334 0 obj <<
 /Type /Page
-/Contents 1272 0 R
-/Resources 1270 0 R
+/Contents 1335 0 R
+/Resources 1333 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1255 0 R
+/Parent 1310 0 R
 >> endobj
-1273 0 obj <<
-/D [1271 0 R /XYZ 56.6929 794.5015 null]
+1336 0 obj <<
+/D [1334 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 390 0 obj <<
-/D [1271 0 R /XYZ 56.6929 564.5444 null]
+/D [1334 0 R /XYZ 56.6929 769.5949 null]
 >> endobj
-1274 0 obj <<
-/D [1271 0 R /XYZ 56.6929 539.4426 null]
+1337 0 obj <<
+/D [1334 0 R /XYZ 56.6929 751.9325 null]
 >> endobj
 394 0 obj <<
-/D [1271 0 R /XYZ 56.6929 176.3615 null]
+/D [1334 0 R /XYZ 56.6929 369.5823 null]
 >> endobj
-1275 0 obj <<
-/D [1271 0 R /XYZ 56.6929 152.4304 null]
+1338 0 obj <<
+/D [1334 0 R /XYZ 56.6929 344.1885 null]
 >> endobj
-1270 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F48 885 0 R /F62 995 0 R >>
-/XObject << /Im2 984 0 R >>
+1333 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F62 1050 0 R /F41 925 0 R >>
+/XObject << /Im2 1039 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1278 0 obj <<
-/Length 3129      
+1341 0 obj <<
+/Length 3169      
 /Filter /FlateDecode
 >>
 stream
-xÚ­]sÛ6òÝ¿B÷tôLDã“&Oiâ$î´NëøæÚ>Ðes"‘ŽHÅñtúßoP EÙ¹I&ã`
,‹Åb¿(>cð�ÏŒN™´j–[•jÆõl±9a³[˜{wÂ=Î< Íc¬Ÿ®OÎÞÊ|fS›‰lv½Šh™”Ãg×Ë?’×ï_ýv}~u:š%Yz:×K~º¸|C#–š×.ß^¼ûÏÕ«Ó\%×.iøêüíùÕùåëóÓ97šÃzá)Yðöâ—s‚Þ]½úõ×WW§]ÿ|r~ÝŸ%>/gòùä�¿Øl	Çþù„¥Ò={€K¹µb¶9QZ¦ZIFÖ'O~ï	F³né”ü´4©6"Ÿ � ¶i&…tìšûfÝÜ>žÎ3Æ’¿ñ@3!S‹ÜÏ9O­ÖÂ!rvf^ºi6œø±É3¡F³tAaÀ9ãÙKêH¤ä hÍ|rGš<{œî�äóÔJaÎCµ^Ã�žÜoO¹IÊU¹¥~[n¿”Û;"ij¬Ëî¡Ù~¢gÔvw%amš¶{� MVÍzÝ<”K¸y¤öž¤’`©'û'Óf7Eû‰–­Sü˜ãSÒ*jÜQ©ˆ¬’‰D¦”†Ãvw4M,P~]”÷]å¸
ÌfEÃ�Q
-àÜa|
-ÔëŸð'ʨ47Â:™¡åYÊÁºpï©Òm³íÖU°»¢sÒ›6ñB¥VÁóØ©²1í}S·nDÂMÒLAÝ7—©ÿyWn	Ü�4¹€e´=Œ:Cƒ02Üã`ƒfç€Å`tѸvÙÒB´šWW­³ãkÕl7U}K³ÅÿCoÂd¶%òiUئìp#ˆMØg’LÖÅÆCäëöç�%°´�Ô£m»Ý¶¦>¹« VvwÕpV%nwÃ\QÓÂêÜß²ìJ<9\'�ús
;þ
Ïs³Cz,®Kºðfê6ZKÿ·[àcÞl=á‘Êh–
-ÎnÛ+—#|�ž!¼¼”ñl¦¤»À�~ÓÜöÖÛ¦«(À
-èó?ØØÈ	�©"/Ë…7"ÀIxjÌ�ä
-Ì�rtèõXÏ0rHÍËUHØÌ«0´XW½˜‚¶®I•p¶Yz¼ö®Ù­—1^±Ýõmt�@]¢€N€}chÂc½.œåIqO‘Cs¿­àª0ÀÈ3 Rt4_µn(Ov-½)\S?z`¹ô¬¶¥§GF:Dr
-±­~�3&H¨l'¶ÙIÈÞCXˆðÅ”Š“ƒPƒbÁ¶4´po€%nª,p^ù©fë—Ó2�ßøkѹ÷ì†ê?·;z!{Ì&ÿ½+=é‚(÷W¬¼ƒ6ˆ5`™^`
-õyáü<Y^,(i†:¶UÆ�8[ÔN'#ä
÷èãžh/÷Î W@•<ðºÒB6 @‰´I…
-ì(Óû��»µäj”ü�LŠÏ1™ëTäàªLSI@ÉAÍYoöü�­¨-�õCÈY?¼õs &“N
¡ƒÁ¶‹»rñÉÁß©4c¨¦·EU‡¢B·¯5D)7†j{-"û¡b
-�tSº 
+xÚ½]sÛFîÝ¿BoGÏDÌ~’ËéSš:­;­Ó:¾¹‡¶´DÛœJ¤#Rq2�þ÷XjIÑqñŒ	îb±X
+P†L3Eº˜§EëÐb0¬“:¨7+òÔæ¦Ô«ôBÊ´°V¡~‘æÔš[:ÏH¿(a�Y¤63¥H­VÀ¹Çx{ºÌdrÿUr6ÕÐ4Ò³&S§î¼x¿�©0E¡	'‚ýQ"ð/Ï·jñ]ZDg
+t—a¤LE+UžŠÜàö.u…Ôžá«»Š•é@mùL}{ßnÚÛOŒÓ4ö“
±½ïë¶
“Ì]RwôlÚž¶÷›j[5}µæ
Æäû
P‘N%f@I™Öbm=Ï
+3V<ÜÕ+&íK(®y%Ù…JÎ!+’VAúm&¹Þ!JCäÔûý2[à2ÿdg‡||œ ¼zý
Tã äÏÏP‡WVÞÇ©60¬}" 	Å«™(Ÿ¥Î¿B¬`ŠË˜ä\¬0àA…=ìüx@ËA®Ò÷¯Çd ø“¹MUAjÄäc&i æ�™‹Áí±ÆnèYyï‡�÷~°÷ó –‘ÞáÓ8|®îªÕŸ¤^`Z˜4�¢Œí붬›ÐNè]†¨ØÆ$í`…4à+ÿxEè
+—„Ž.w>]",2]*_*CSÌ:j™±]byÓSÕ…†'àV57…;4SIÅ$¹7Íèa†7£oý3§h0têù(ŽwwíCCà5У¬C+ä¨cª*´Œåm­N~ð'†	Ø‘aÂ[I¶0Mý[OÝPIs®ÉŽ«ml è`þ�[¹NMÞ’qŠ“›�ÉúDÆxh§úðD}dµS…P}ä3£ˆƒ´l1•–]ãCÁÃÒ¼º¡f¬v7¼{(–fPì”Aš"t!#<”g,Ì‚…9sšé]F‡Ø±Þ¸®Gll—F7«±Ä^¾1rüI0δß3!’¿<SJ§þ(`ÄÚ_„á
+ð¼ŒøYòåKš9ƒ¿Nìº\½ÈghË#ÚÀ{÷
RÊ"ÚW?œ]tSï³75(¢Œ7>ì1‰¢ñ=@ú6Ð÷<G1Ç‘‰9ý0£±ù~3Ò‡¡¿�ŸÔ)òÎ|VS.5'ápàÕ¦ÄHŽàëÉú'9Ý)s³òÞw¬ÌT¾`iïx@MÞõãÂÿ¿ÉM=Snê‹å¦¾Tnj*7ù_ËMþÏ䦟)7ýÅrÓ_*7ý”ÜÔs䦞'·Éæx;Þ ��‹Ý39’å3ßï(X�W+ûÁ+Í9¥Àï¬ôiòøg!Ój�ªg±ÄWÎœé…
ЭoP Äõn×6åuÀ»®îʵO¯<Eú°Gø<
+ Åa„¸T¡¡Ž@úæ�M£Œ¢Ý\fvȦ´rɹokeÜsÊ“®ÞÖ›rGƒ¾asvÄ<¼Q-MOZ`™�žD×WR0~Ò—%&-Ò�ÌÅe”Æã2*ç"†ji
IËcuÔ‰AŽ†ìoH>4$>培À /š»ˆº8ЋG¢D_ãÔ4Ïâcà,ÃSléy(ªà%ÎT‰‹G~„…:þ*p曑~w÷ì(~Š…Ÿ}œS�|~Üú"LùbÉ)çøqÒ:•Ï°þorc\endstream
 endobj
-1277 0 obj <<
+1340 0 obj <<
 /Type /Page
-/Contents 1278 0 R
-/Resources 1276 0 R
+/Contents 1341 0 R
+/Resources 1339 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1255 0 R
-/Annots [ 1281 0 R 1282 0 R ]
+/Parent 1346 0 R
+/Annots [ 1344 0 R 1345 0 R ]
 >> endobj
-1281 0 obj <<
+1344 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [242.0197 432.1255 315.2448 444.1851]
+/Rect [242.0197 602.0286 315.2448 614.0883]
 /Subtype /Link
 /A << /S /GoTo /D (rrset_ordering) >>
 >> endobj
-1282 0 obj <<
+1345 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [238.0484 354.4169 311.8142 366.4765]
+/Rect [238.0484 522.6184 311.8142 534.678]
 /Subtype /Link
 /A << /S /GoTo /D (topology) >>
 >> endobj
-1279 0 obj <<
-/D [1277 0 R /XYZ 85.0394 794.5015 null]
+1342 0 obj <<
+/D [1340 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 398 0 obj <<
-/D [1277 0 R /XYZ 85.0394 498.9148 null]
+/D [1340 0 R /XYZ 85.0394 673.0194 null]
 >> endobj
-1280 0 obj <<
-/D [1277 0 R /XYZ 85.0394 477.595 null]
+1343 0 obj <<
+/D [1340 0 R /XYZ 85.0394 649.1998 null]
 >> endobj
-1276 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F62 995 0 R /F63 998 0 R /F21 658 0 R >>
-/XObject << /Im2 984 0 R >>
+1339 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F62 1050 0 R /F63 1053 0 R /F21 702 0 R /F41 925 0 R >>
+/XObject << /Im2 1039 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1285 0 obj <<
-/Length 2262      
+1349 0 obj <<
+/Length 2450      
 /Filter /FlateDecode
 >>
 stream
-xÚÅY[sÛ6~÷¯Ðä‰Þ©`Ü	¤OnÖNÝi�]Å;;;i‰²9¥HU¤ãhwúß{p£À‹lï:™Ï pp.€ƒsŽÈÙ	‰¤¦z–jŽ&b¶ÜœàÙ-̽=!žfˆæ1Õ7'g—,�i¤%•³›uÄK!¬™Ý¬>$Qt
-pòæÝõåÕÛ,ÎOSžÜ\½»>�S�“Ë«Ÿ/\ïíâü—_Χs¢IÞüxþ·›‹…›’žÇW×u#Ú5G˜.../×o.N?ÞütrqÓÙÛK03†ü~òá#ž­ÀìŸN0bZ‰Ù|`D´¦³Í		ÎX)OÞŸü½cÍÚ¥“øŒ(“t
-@
H¨BœÂP*4’Œ2‹àNçã„hŠˆTˆžQþ}ˆ†þ·€ÀlÎS¤(NgsB�‚>Â>aðìÌM^]šý€N]¹�e™5�뾬·¢(Cš`þ,IRE’n~¼¸v½û&wD¿s�zçÈà›E2Y�I¦d’o†{!nìÙ¸±çâÆžÂ�¾7ú2ÜøX€èHcs‹µ7�LÞæí._ç~°½ËZ׫òÖj†û*}'‘p“g—p—Ô0H‘fTYš›;ÀœJ™¬ë²¬ŠêÖ}æ_²Í¶ôsEYºÞmñÙ�íN‰Jò¬©«ìS û”ßeŸc‘ãè;m�QÖËÌ3º«›Öõ²juj\×:Ó®
-'fÙ–{7²¬«
->óÕ
-T[·l$Dûg±†!'‰ú[fFšl“÷¸‚ñ÷÷&ÁäGÌ�÷;ÚRt‚^U·®ó)w­9Cù
-¹kÚ{K»kšZÞ†°,š6x #^
-”
-6íqí	1 ~}ƒMMßÏáI×y„x>)°s2¤¯=§ŒuA‘ˆ€Ë#.Mî‘x·[
Tàu&=…‹Ä	·Lþy—[¯ ’Í}Ù�sòÇ£¶íªq$™�)Úû]eÏLUð=ž¼jìÞ™9ï—6ÙÞ
|òlàyZß—nÌÞ]há,þŠ1½½�åy'¯Sîý õ)fñÝÕ'¶d[fK«5g µ˹ç
-ŠàCyá¨n^¾Výf0
-î%dZ‹#,Ìr¸ßœ;„.ð3çç‹ËüˆBfbÃC‡è¢—
peœ³
˜¶
%GHâ¸Ý�ïGŒú/8,pÁÉ¿ë*Ÿ
-éͪ2GÃýæ"Eœ@¼#ó2´Í¾Â+¥ñóóY†Ç73¤8gOl «ÐÛ¬#«V®´ñ_쟈aï¢ùnÿÞ'hðŒ¤<yõÈœ—AôMQ§R"‡ÞS¨S
m*\¼¸Ü/ËbùÍPÏ"‚ú¾ZÍ]ïS˜&þ±a_ÿÃoÿ¿I¤F,¥&_‚œ‡pgU£ìŠ¦
-¶ŽÑ™

ÑTN'Wá J!SaÞ1^Ö¾î䫶¯§JæEç\�
-
-…îN–»ž“%¨ˆÊ�[_{šTìX�Rqo
-×ËÌþºàŠ>û¸ür¨ìÉ4ªY[Mïüh™Ivu$��é„'_T4uí,ÔÌQMok¨¦pPHˆ†øMØ×[šºX/Ê1¦y%2×4÷k£­}7MØ•’Pº„0M!Lè ´’•Ù¾é×(�ßüG¼¬-²œ‡ºgTÃø|OãÙ¯2<áWëA}h±qðª‡êÉš˜dZë;Á‚í6Ϭ.‡ðv?a\W
†},„La1œ(Ojˆ ¤,òûQRBóKîDíÏž|Šžûƒñá×tn}E§ý”wg,(eËÀx¤yøey¬úŸåF˜endstream
+xÚÅÛrÛÆõ]_�ñØ	×{Çnò¤8’«L"·4;�Žãˆ„,N@‚&À(Š§ÿÞ³7`q¡$Wét<–‹³gÏý’`øG!‘ÔT'™æH`"’Õö'ŸàÝÛ3âaæ
hC}¿<{}ɲD#-©L–·.…°R$Y®?¤Q48}óîúòêí?糌§Ë«w׳98½¼úé­Þ.Îþù|1›%Húæ¯ç[^,Ü+éq|uýƒÛÑîqéââòbqqýæböqùãÙŲå%æ—`fù|öá#NÖÀö�g1­Dr?0"ZÓd{ÆC‚3vʳ÷goFoíÑIùŒ(“tB€”M	Ph$¼2¬š»â
+¦LÀt/Ÿ·XD¶…ŸÇÆvŒ×Ðñ¥Ó‹M5Î
Ùˆ&
¡FiÖ£ië[¨§(a3” §RÆÁµä!¼eöåùnJôaÀå%ÚÚjL8Ü$•Ê¡(Ÿ�ç$=
+Ä)5�òæ
á<ÆèX쑆1’Y&º‹­Ò÷ÅjÂ0(E‹àMŸÖ…q‘ŒúíÛª,«ûú[qA§‹~.ø°*óºv‰ÞEA%AüE-T,0Bʘ‘˜ä¦’a/–X‹q£´"ëG@�5"`†È�I¸"cHÌ='�h>4ûb‚mˆlDÒ`'
¨Çµ9b%ÿD®Ƨ¸€
+ePw÷½÷¿;1u¸�L�Dw.¿'†q305çY�œ�H°D þÍ5…ì"�2Á|~‡|9(4&ÖÒœ@½f€ã¨àdØÀk[Oò`‘
+**œ[ò¤©¯ÔŸˆÅÞó­þnû�ºÚwÑ ‹d<}Dê;/Q'už
ï8û
+”áÄi©C¯âOH]H¤2¨mø°*7«ÿ™Ô}æo逫ãn=w«›
+Œ™3ƒ7……YŠ²ÈMp2?Lž6OW˜•“â\wãaÙ›ïpcòR·F<ƒ#Î�gwËa‚£Œ´�u4^7÷­«Âf­Õ,êã~o£é.ÜŽ­qLX™AýP¬C`3s)À
“��˜¦ ‘:½1ä=¸5tà�éÂMè€færã1;€‰ó+÷éDû¯#:5å–ÁY†C.þꨎ‚Íf[Œ	°ÅÌíƒï–G
STйæï½Â.Sî£<�+üêŠÇ¢ƒ¶BÝ�Â�ÑݸJ‚R‚*­’؃^æ”Æû…£ùŠ*éñˆÑ÷s–i5Ý 0ÍŽ¢÷qNø�sË�Rô¸óÚ˜
+uÚƦ>àäÉV󹟟;ž¸™():]”ùâ�¢,KtDyøN=&ý?o>¤Uendstream
 endobj
-1284 0 obj <<
+1348 0 obj <<
 /Type /Page
-/Contents 1285 0 R
-/Resources 1283 0 R
+/Contents 1349 0 R
+/Resources 1347 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1255 0 R
-/Annots [ 1287 0 R ]
+/Parent 1346 0 R
+/Annots [ 1351 0 R ]
 >> endobj
-1287 0 obj <<
+1351 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [325.3322 434.7534 398.9856 446.813]
+/Rect [325.3322 596.1482 398.9856 608.2078]
 /Subtype /Link
 /A << /S /GoTo /D (the_sortlist_statement) >>
 >> endobj
-1286 0 obj <<
-/D [1284 0 R /XYZ 56.6929 794.5015 null]
+1350 0 obj <<
+/D [1348 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 402 0 obj <<
-/D [1284 0 R /XYZ 56.6929 505.3435 null]
+/D [1348 0 R /XYZ 56.6929 666.7383 null]
 >> endobj
-955 0 obj <<
-/D [1284 0 R /XYZ 56.6929 477.7522 null]
+1010 0 obj <<
+/D [1348 0 R /XYZ 56.6929 639.147 null]
 >> endobj
-1288 0 obj <<
-/D [1284 0 R /XYZ 56.6929 352.0635 null]
+1352 0 obj <<
+/D [1348 0 R /XYZ 56.6929 513.4583 null]
 >> endobj
-1289 0 obj <<
-/D [1284 0 R /XYZ 56.6929 340.1083 null]
+1353 0 obj <<
+/D [1348 0 R /XYZ 56.6929 501.5031 null]
 >> endobj
-1283 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F21 658 0 R /F53 962 0 R >>
+406 0 obj <<
+/D [1348 0 R /XYZ 56.6929 101.3093 null]
+>> endobj
+1354 0 obj <<
+/D [1348 0 R /XYZ 56.6929 74.6262 null]
+>> endobj
+1347 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F41 925 0 R /F21 702 0 R /F53 1017 0 R /F62 1050 0 R /F63 1053 0 R >>
+/XObject << /Im2 1039 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1292 0 obj <<
-/Length 3119      
+1357 0 obj <<
+/Length 3401      
 /Filter /FlateDecode
 >>
 stream
-xÚ­Û’Û¶î}¿ÂoGž‰^tãã6Ùô¤Ónzvݾ4}�-ÚÖ‰-9ºìfûõR–lÙM&Mf"	@
-.y|t
->ó∡â‰Q*†)<0ÆÀö¹P^W‚6ÎâX>ƒ4<aÉtüµDþ�êŠ,Ž
-eÙe{í·íî”1Gkñ®qî©&XË‘EA(’xÌûQ·hP¡ðZp(
-õKcQ“®€¾+”ºÎ¿§š`ä
-¨€s9–`1W`ð 
-YëÈ»ª[„^©ÛçªþD“m�­qëŠæéâFÓ­ÍM˜ƒ®×U½ÏÊ•~…e/WDG'�š¶¢…
Í•z.ód)³²yÖuLø€ÂaâHŽÍû\�':À“óÞ*�—	éu�Î	2Nß;2’óh�€#‰[x À¹íºÂ„
-¤Ÿ;]Ú²oí
-¹ºº¤ñ#Ô¿ ªßßa±zûþçW´v©iG<$;J"eêíªÆ”Š4Ú–f„1°â½Î°fšyxh̵"Œ'o:¼0¤Í,öþ‘¾æQÁ‰�9>¢náÏë[‚]C—g³âIÆ
-›IЬuÓ”"Ý‘J7í	�u^5âšžp­ˆdi�Êc¦'q;[­ô
brð5É-TÎ}±ÊíÄUÆb⩉•@EAg†ÃP†1déð"¥\|Mɇ´,MÓË-(HõM©YqV=:é@-	$ÄâRK…ó(ˆ¼ó2‰‚$bêßè©à¦îp&%‡tÊâ«©Òïì·žèª@�U)C	 ¡‚èX®«0êgDI_ÛH]nUú}·$SØR1ù-mƒë6äC¸ÀIlôEñÕri¡¢€’âz4³T¤Â¦Øøð`yѾø&üÃèìþÑ–ÒT—NF6GåÉ&"ˆ›`@	òxЫkó&1›g#à¢Âæ¡‚/¥g’a¹Ž�e´`ÝÁKib�Ÿ·º$èíýããÝ‚áäeæ-Ϭk«}ÖºþR!£q„*VµÑ <mt©kJ!%çô"r“âÐîl¢�ì€Ï_Êl_¬ÙrØ ¡|`Ou/TÉuŸ¨ Lc
4Yo¬{=n¡§÷‡Îoá|_ÊáVT¡lð
-åŠJp
ÀšÎULëÊñuwV]MøÒUB6£ÔD»]õL Mú:iW싾ÚÊöUçv©l�µÚU«O¶Öú¤Ÿ±¿q1»ƒZƒÙõän@t%Z¢>µÓëZ7[ÏöªïjM¢
u[¿œÓ:ä™û`0‚ˆwMþžèü
-­ÝfKSKÂjÇèDt´g"ýªl2a[³£u�múbƇlõÉš¢qé×.ó¬±æwBì:AlhL-m +	²vÆœ‘^øß02
-Âé&3ë»ßý?eŽ?©‡I 1a™N”°3$Ày­Pæ·O~*y$SxÔD2!úßL*úhendstream
+xÚ½]sã6î=¿Âoç̬´â—$>¦»Ù^zmö.Ioæ¦íƒb3‰fm)+Éɦ¿¾
+kÌJ9‰R‹2cãTIÕKYŠ9),”ò¦Øº¨ë6ûÛ2‰µNÕb¼æ
åk†´‘ÒÄZfé”öµëZ�¹–ËîÁaC-«ÝöÖ5¬ïèÛºU]­[Bèj®ŠÍ‘Ë‚Fp'aBó)«u¹*º²®àüU’/‚¯Ë¶¸Ý8^W+«S±¼g¬_“Ü<”Ì|A<{âT9´…Ô 	ÜÌåçFo<Ò‰‰½[c¤ÇmNE¾„]m·®Z»uÔÐÉòÆo
+´píîŠÝ¦£N ¯Çô¨„Í{úi’ÌÐÇó‘*àà®DBknËj×¹–H# ¨ÖÔèÛâ[¹Ým©óTlvî5v²,–VI&%òy~ÒX'bÄŽ:d'>0=ÖïL¤±•&{ÃFX¯AÀBF`£Qå5jÖ€%-­}�~�5ÃÀÄˆ@5åàæԂƒ(¤aíXïV(n©—•ëžëæ
vMq‡ã¿&‰\Ñ8Œ•ÕŠæ­#È£kîêf[T+÷!–†z#�Ú®¦‰-�UîLæ‰1‹ª}vMÏØ@¤a3©QSõ>çžÒ<NE¯•ÞʤZîZ·¦–7rø¶®£FA|
+	0â¸s7Ï+½€ìšA®eïƒ:eÕ�ZAaP“ç
¯°¦Í/¢À8o—.*¶Ù¬·ÙC9�«ƒ«ø3ò±FÊA>‡æn4×Y0¶dÞÚ”ïl
c
~xõ¶G͇z×†·o/2¶‰–�ó`à«¢ªêŽ¨¸o+çÏÚË«xanP…½€E‚‚�(Ôs¹Ù�›¸eÔ–8øÍ{¬æ4_ÎVÓ7coÊ”ÀwÝñ®›bô¹gê¼.¿wÔ%¥noY^wIc¬ã.©Ç
+’>î‘4\*Z毓ï±fèO=ŒJ-¦ðålÒp¤ãûÀ[0Ù4žÊÕÃdÎÈÍà8cÚßÞÐ$ϳ.«¢y!ªæcÝ–]	¦÷äÂ
•Ž(R2÷fçuF×Y¾§2Ãý™kò0ð­+$š›å³s_„Ä2j¢’�DZ¨åAý‡ÓïhöïÎó\t[¼PcUìZÆ,üF
õëÎ5¥còÏ`ϵk*ê_C”¢úï'IÏ.~|Gso­ˆ›L¦.9Q*_nê¶Ã–%‰¶¥Qn´xëÖ%h3�\]µþX±�;owx`ˆ[0ôòš¾þRÁ�{¿}�Áßû3j‡†�£¢I^
ÀK½Ùy?=ÙÕ#IsåÚö¨�™\Å©öu;c·³ËÛYYEM]wía
+*£T.ÏD‹*8Ã…†Ë]ÊÔ'•‹¯'ÚZEX£¶ßí x±•‹�5ìi1ÞVX9/í÷Íñ�[ÌäÀÆ�‘S»ôŠ–�o7R#ºÍPÑ—³hÙƒ×6ƒÌRѱHÿÞ)©–´�ëGCŠþ÷t(w�ƒh.Y¦^@†Zƹ"u;îÍz,â•÷\Xåºì^"ïþ¡wpþ™‰³<—‹1�CÏ°fø˜x6`7K!Èœ0rýèV%æ(þîËB@�eƒw ÷nYx®	Æ ¼ØÁMé}õŸ\E(/¯¯Ï?v^
±¥ñb×Õ[Hd"rQYçR™©‹ZÁU�÷·N—÷®r
‡�Ð-ZþÒ‡W&·¥™wø®_ªb[®¨³{\Ã</Ø}Ù+

+Ÿ€JiÜ€¸P¨4Øܳy]�N¡Ç�ÆOáp]ŠáVœ
;p
p“‚àxÇ‹hB�õ«q’/ˆ
ÿ å¾=òÝäË-o†þˆa¼œŠ¾~Ä]<™Ò¾u�LÑ ÆgêõnƒñK"BPŠÍv¬”x¨Ÿ©±©«{jݺ»:°‚}Ïêµé¦¥ï«�§è÷I‹Ñ—†{ýÂ
+
+±øMðFC踜Ù؈g›Ïçï:‹¥Èr¾¯Õ\ö.tl¥!ïÖ»/ŸJTWl£…ØŒO8Bm쇦Lxwߌ&ˆ÷’ú¸,ê£Q¼G€
yt|þÔ‹ÞH¡ã‰°Ô‹+š–Ë#2ÊfSåõ•†4M†L¼¯5x¹åqfS5Š‡¥œš�Ê
+cI.õȾÔ#¹|$1ÿ­,ÉUxŸ>T�$—”$§€ÐÀÓ¥ÖØä=jàbµk^uûDÃr@	}H(9Íè×6å¶ì«ŶÞUþÖ\�XmêÕ®M|qÏXÜ“‘ìetX¦A÷oT¨»
ö4Ì*LüCÝ‚H6ëÖcš’›@ÀÆmÇ°ÖAà¶`
å#UÒû„%Ô
pýùŒ ƒÓ§>ñ,¬R
+’©W(!$DfY6)'*É2T;áÄo7¡8�ËáÞó%£Òýj¯¶ýT4e½ã¢žk³WŽŸ”.õ£¹)Ä£�«¨7j@c¬ãÑ\�Ž‘M:ªêµ;ÌQSÈ
+r•¾ÎB�5ÃÃÄß@¬Rm§LøHî!BP&Æ.BŒB:hûóâ—&Õº…³æéîÄL•7@ðן¤/
ä뮨º°<|€€Âà`.±¹Ý»'½ïŠy¿“µCë¹ì&C•{¦‘ÿ:ÿß©ìÍCþÂŒ„4ÕŠ¾Þ)f«°"‹­’Ù±LµW#•ÆBgê
5a½¢F
k_�‚c�Ñ¥<�Á­g¯óÑcÍ02Ù³±Ì§|š„�
+üœñÀ±ËC½áWŒ^› íµ	ñûѽŸê}´8°D˜k@¯|¹Ë?•%R��0j«Rj¯ö^èºðìÅÊçKÎárý*X¦ �^Õfõ‹ù~C¿x{­“7^ÏÆXÇõ«ÇÚׯîåѾŸYÈ…“ôuz¬&»Mu,29eaP-«)&Òpøåit®>Ò{¿¯°ȳJ-tPÖÐãôù!
+Z|úÐâ虣+½üâ˜Ú(æÒûeQ¬´*ÕFcQäX¡ú˜hØ(øððÎkŒ2s/«XYèfü^Ú£m¦Ä\o:ÈÉë`V¾0‹¦Ø:ŠµE¨xCÃL„moë'Z„ChAG
ŸI
+ÃXF¤ûY`Q~åA7Æ"êý"mw3E LOð¸º+²ÊÞ¨�±^Q÷€ÕWŒÝ¸Ð‡‡wýcù,ØcwÍË!n
+ÇÙuK¡;ršøá!èîË�€%¢±Bߺ‡â©ô!šRKÊ*¼ÖÞoO£èe>ìH=È|Ýa¨Ð¼0–æˆð(š„Æ
+ò½ûþçH¨êúɘåÆ+&´»¦¨Ú;~DJÌòçI
b¹�†O”×ĹXž¨[;JŠ,ófCÙ ¼h�&ëÝÊ;¬„CŽ½ëž§÷Öœ$Z”Ã
 endobj
-1291 0 obj <<
+1356 0 obj <<
 /Type /Page
-/Contents 1292 0 R
-/Resources 1290 0 R
+/Contents 1357 0 R
+/Resources 1355 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1296 0 R
-/Annots [ 1295 0 R ]
+/Parent 1346 0 R
+/Annots [ 1359 0 R ]
 >> endobj
-1295 0 obj <<
+1359 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [326.242 275.682 375.5914 287.7416]
+/Rect [318.204 427.0782 366.911 439.1379]
 /Subtype /Link
 /A << /S /GoTo /D (dynamic_update) >>
 >> endobj
-1293 0 obj <<
-/D [1291 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-406 0 obj <<
-/D [1291 0 R /XYZ 85.0394 667.0947 null]
->> endobj
-1294 0 obj <<
-/D [1291 0 R /XYZ 85.0394 641.059 null]
+1358 0 obj <<
+/D [1356 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1290 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F62 995 0 R /F63 998 0 R /F21 658 0 R /F39 863 0 R /F48 885 0 R >>
-/XObject << /Im2 984 0 R >>
+1355 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R /F48 940 0 R /F62 1050 0 R >>
+/XObject << /Im2 1039 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1299 0 obj <<
-/Length 3888      
-/Filter /FlateDecode
->>
-stream
-xÚ¥]oã6ò=¿"�«üE	=°ÝfÛ=\·½Ýôp@¯ŠEÛº•%×’’uýÍpHZ’å¸E±ÁŠŽ†Ãá|Ëü–Á?~«’(ÉDv«³8RŒ«ÛÕî†Ýn`í»îp–i9Äúæñæ«wRßfQ–ˆäöq= •F,MùícñË"‰DtØâí�Þ½ÿîç�oît¼x|ÿㇻ¥Plñîý?hôÝÇ7?üðæãÝ’§Š/Þ~ÿæ§Ç‡�´”8ß¼ÿð-A2z\ úñáÝÃLJoî~}üÇÍÃc8Ëð¼œI<Èo7¿üÊn8ö?nX$³TݾÀ„E<ËÄíî&V2R±”RÝ|ºùW 8Xµ¯ÎÉ/Vi¤DœÜ.e¥°ÿ¼”y¤9$­²(‘B)>'e�…RÞå_–}±_¶åïfzdÎÓˆs@Ò=Û=`Íl/ÛJÄ2™Œ÷ÿdºön)ÓxÑm

€¥r×ïhòðí‡O4úù۟ܺiÛ|ã�-ßvTç;SÐð¥¬*·lj+kz>;Ó‚Rh.ÿ¾ËÄ"¯J‡òœW½iQ
- yÅYŒ§‹2¥„å5?ÜñtaPQäBq�à»!@̲„ ÿeŠ9Zv¥é»¶,ŒCß–|Èë�Ã|r�¶¬LÝUG‚æÅÿú¶3PæÀ»lñ¸u˜…Yç}բݖà~ä˾Ãí;x:6>Wßö9nÏÄ‚N˜·MMóus Akº®¬74)�…X!À3§GÝÔË_
-còiåùD>èN6N¼�9¼zîFœr± ­’ã�Ó•²ExÖ…Ùƒ†ÏhÖôìH9(γ9te‹GÂ91°2å³Cxê×Z#G8GÝEŽ&¾Cèl|³ü™¢nGncbë	øH�9dRÚ©;u>+ÑY”*xëUÇ6ĺìØ960˜^~e– Æ;¸‘©“*Zǯ3°f¸ù·˜EB¥zÌƧ½Y•È:	’&7b�ÆŽ?;Æ;ÄçïM=ÂlýD±ÖœùjЦd Gg¡ÅÃæ–§
-øWNuN—¼öª+ÑG GI$#}ÆOÊ¢TBt{U¶
ëgÔNŠZ“7Df‚×Á‰ó:8,[RS™
¯ŒAHbÂéig¾t3ºa+ÀOH÷.<ˆ$â—‡žçe[®¶°]Ì­…â“n;ÿÙ�!gP¸%ØÎú]œ�]îé
A«ËQ¾x8ˆKïJº}¤[Ó³
Â’î´´�w(“ƒJ‘ER‹äÊIu$¹C9ù-dõ¸/Wà<�45_–$‰–—Šdì¼@ã­ÚG­(¬Á|cjsÈÝ2€�mkfœ—2Š%X±dürÕìö kçGÈTÄ•VþœMS¡óLåâCÓÚ“|3îú²Å�°œ
-zÊ’�ºÐ¹-I`€ÐÞãvï8YåŽñ'ãô	–N"bÙç¡,
-ëg¥^ØÓÊÔê<öäC—NÇá0^y.Í­<å­
-,Ú¨
 ²^U}AU‰%:s?JCÑ™ˆ?''`þº†W
-�².»’jhuªu›¬ï`q×ï0Y¥õ[¸8©ûÝ“	aQÀ�ë‰o¦âNù®?´å3„ZCÐHU�d–MßRÀ‰Ž–ɬî~¤å
Ô€5ÁH¨¡wAÚÅGv$u”Å!UøÛŒêHÇ©÷"¿¡+¼ÿ
GøUaí~N4›„$åï—h¦ƒ:’øõN<öJ
Ç7‡gªa]7…œ\yʲi~±Z™=H0 d\[æuö{r+
-zHó’¦<Šuâ?Šx†.¢í8ŒÍ7™7CH®ÁžðsõÈ þ�=»êr2Âá§Üô€$u:�1o{-Á1FÛ'Õ+ëA0ÕaYA8YmËz€KñnˆâßNµ�riÌí2…d+�Çö³¦€ˆ5}‹½�mγ„é·Ë<
cÝ×+÷£É|Ý/ìå.·ê€“þ€ÍzÃê
-X€ú¤”èÌMö§‚™ûM\Óïij÷„'ä„«Ü~f™“‹ýù_ê~?+üùŒÍÄ,>þfÐýB1Äë@£S¿Rd×è–H…šè8ÑA÷õ\È‘‘V©wïÁ³Q›I¨¡Ù$‡ýkþ.4E"üíðŒÏa·~³¿üåSéëH¦©¸ðÁL£ŽÇ”íˆsOÍ°A&fXÿ?A
+1362 0 obj <<
+/Length 3826      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥ZQ�Û8~Ÿ_‘Ç0ñZ’mÙ¸Ã
Ýît·‡Ûv¯�=°»žXI|uì4¶gšýõGŠ”b;Î‡jJ¢%Š"?‘ŒÅ"„b'A’Él¡³(ˆC/Öû›p±…±oó¬ÓjÈõýÃÍwï”^dA–Èdñ°Ì•ašŠÅCñÛ2	dp3„Ë·?¼{ÿ㯟ÞÜêhùðþã‡Û•ŒÃå»÷ÿ¸'êÇOo~þùͧەHc±|ûÓ›_î?ÑPÂs|ÿþÃÔ“ÑãʤŸîßݺÿðöþö�‡¿ßÜ?ø½÷+B…ùzóÛᢀmÿý&T–Æ‹gh„�È2¹ØßD±
+âH)×SÝ|¾ù§Ÿp0j_�ÕŸ©9£@©
+LEgY¼Ðq$
+†P�ÝÎО>|CÄñV¤K³¡G»£Î¼.†£ÝñDͮܛ–ɆŸnÆö`Öåïa(
¿û”W½iƒ¥‰@‘,´LÇÙ•MÓjÈE{sFâ¸p�¦¨ÛU_Vmù§™®.d¤Zd//ï¹fÖêXÈ8Hc%Ç|6�U’vÊI–yñdŽ]Ù’nôòþ‡Ÿiä×~¡®Ç~ƒÊÞ˜#µ­ô–¥¬™ãÔ¡>WJ…ËÝfr™WeA,¤kbËéШIt^z…YBÔïaò{ ¤Å*Š`àƒ+!‚,ŽÉãš¾kË'“¸�×�Éò˜×[î|.«Š¨GîiËÊÔ]u"Ö¼øOßv¦€å
+ªåƒUŒf“÷UG¯YYˆtË °Ówú¶ÏyAÚhÞ65µ7Í‘%0]WÖ[»¯ÐmHÎXÇJ&¬šGͺ©WgÁ’Ä–°`þ•d¹5ÌCLj“Ôí³9NØyÛÒp·³B7ývGC�Ôþbjj£ѾžóªòoåÝÜf«fý…¼msÌ·{P»ó¾C¾þÂvhýù;« ï°íM˜íbôÚÙ’Â喵ݙ£ç«‰b#�…^ñø$A("ñ²Ç¹®{¼çB5ìóo×^¤�àµ/®î¹f–;¼
+ÂL%ãõÉáU‘Ã#
"•û~O
òv¤¬Æí¸iÛ|ËÌdŠHÕùIò+;ljîC$À§C-ä	phäÑ"ˆ²hl2ƒ3Uîà"FåÑ!¢ƒ9
²@·‚Ø	Œ��Ü3
+ØIŽŠû4’CÀ¶wml8˜¼CV9e>Oïm#`¾znSTX)�'^2Ìøg]˜X8ÈLÍfYŒ/O”¬MùÄã«3´¶‹M°Cê"!À˜p>N˜øzA�Θ™Œö
+°Åk¥B¿lC®ëÀæ¹ØÀaŽxø•Y�ïéᛊ©uô²žkFŠ¾E\Æ©‹ñÙ‡vh i‚9 H4¢Y>KãâóϦq¶®‡­¹Àj°¦
+²,Ô¯
(Z©”™,þÃŒU“¦¸›Q]
+²«¡æffýjt¦�óDÓ6û’5Ô6{Ã}·	ÖÊzgÖ_X6|«Ó¦¯nÅ’�ÿ‘ß>˜#jÂYFVi"	0ËlìG¨h03`×öØŸfTè
+D!dÆYòºŸE"ö–ÐÔ¸ì¶?æt‰âô¤\{J©‹ô ®�Îì)¾Ã&ešWÅ©ûô8q%º¬v…a20Z!·)	h
íÒ
+x›ø åo¯ÍÉ!Ä-å4`ŽO†ÁÃVS” '‹ .žÔqÖks°ÅG¼aP3\Ö�vAÕƒÃ�`zò¢(ÑOìñ&ÂY,Bu”¸ª2r_é
+¸wP
+•îI}R„“ß.D~Yð)$;�•Wœ»@¶;ˆù
+¢iV
+¤òA>ê(’))	´³†È�ž#-YÏ–ç¬glº9jûž^ö«,ìzlzÔ’\
+¢÷óšXËý¡±E_Ë|š‹R…ˆ¡e<VêÑnãs·2„šiæbê«1#ÆÞq¢äË1ã�ëzÌè¹ÕºrsZ¦ÊO—¿YÉ ÎÀC^\ÝsÍ,?:T
£rÛÑút»j@J+�b‰.“rZ¬1B„ »°IþädºgcüPÍ)‹Ö.ŸŠê+	ï�úø‡®–FèVÔô[+<Ãmq+
+ä®{­—>Ó�ƒLG“"�³Á`Î4 —ÈBð‚&2¤†î‘Àßí
+ƒpù}_VÝÊe>þ²¥V>¹°äŒ!�GB-¤ÎÎzUéy2•Š%ÕD›§²°p‹£6`@jgªÃ¦¯ˆ±(ómÝ
+WØ¡5}Ѭºæ°²õ‡UÑà
0W&Q2HbíÐü±¬‹ùª¬ÔÂEÉV$¥¯•#àzð…Ÿ·?½ùøyfBˆ‰³ÔGÕ68ÇB3 ç88¿Û2æÕ¾Œ»Ë�QVU”Ëcs 1hQÞŽÃW~¯pŽ-€ˆ´zíç
+ÿåÓ�ÿÒ_/fýX!Ef­XªKÔˆ
T:g5˜ë).g¤/ ƒõuxò¢Ñ)*,Ö§É+Ç\©ð…@W‚…i)DÇ”ËF<RâGÖø÷4ÆQs6@hpµÅ‰o]Q†)äȱ3¢÷ænDÀ¹kâ/~aþlŠÓ®;þÔ…rHK«æ1wé[œ >=†.5^ïx´-5ÚÞª ÓXí›»ÛE�ÊÔ¹[^A”wõ:‡•UèymÁ6K¹`„+ØfîC¥ÌÞÞ-“Ö{À©"flˆ}§¦'bclQ2KÝ«zYSº€]¼RQ¶ùc5šÙWÌ…Ò“:›+Ñ©$]öÖ…#÷A^I
++x¶�ß=Xvª¸aÿÎ~¡0zÏ»ôÌùÃ
'“¾5X×zX¹¢™O´h�©¢¬í}ˆýyMOóíP•kOC˽æ@Ï5³„´9tšM‚š�PˆÌAëùã¸5Ö;Ÿ)»ÀÒ'þWâ�ÁW¨—Ã�
ÓõhÇ1Y¥Çšzºh†Õó—×d–Ë%'?˜EJ«Ñ’N¤~mÛè\¯÷?¤]î4ÿ†Ù;~»Ì‰à‡ðuÊÑÎ`N›×_Þ�RCœ¦”ƒB–'¸rSjü¦Óÿ¢À©1®r:˜+¿‘)Æ>üûaÀTñ‹¿ýÊó5:ç(^ñò5,×A"ý•ŒQ]&9âü›vFŸÏà³s£üMIE-dØð‘
ÐÖu2WrBŠÏQG¸ †tÜ~«°9ñ×ÓK)„02Õ“£àuæKÛG»¨xVmì^ß­!ÖåªÆÌg,¾èp%ŠPhų^.Ü)ýß_Ÿƒ�H*M¯äø©L”Â$,”��£KÐàO‘/Eÿ/²Wendstream
 endobj
-1298 0 obj <<
+1361 0 obj <<
 /Type /Page
-/Contents 1299 0 R
-/Resources 1297 0 R
+/Contents 1362 0 R
+/Resources 1360 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1296 0 R
-/Annots [ 1301 0 R 1306 0 R ]
+/Parent 1346 0 R
+/Annots [ 1364 0 R 1369 0 R ]
 >> endobj
-1301 0 obj <<
+1364 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [324.9335 676.047 381.8296 688.1066]
+/Rect [324.9335 578.0115 381.8296 590.0711]
 /Subtype /Link
 /A << /S /GoTo /D (zonefile_format) >>
 >> endobj
-1306 0 obj <<
+1369 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [55.6967 244.9849 116.59 257.0445]
+/Rect [55.6967 152.6674 116.59 164.7271]
 /Subtype /Link
 /A << /S /GoTo /D (view_statement_grammar) >>
 >> endobj
-1300 0 obj <<
-/D [1298 0 R /XYZ 56.6929 794.5015 null]
+1363 0 obj <<
+/D [1361 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 410 0 obj <<
-/D [1298 0 R /XYZ 56.6929 320.529 null]
+/D [1361 0 R /XYZ 56.6929 226.773 null]
 >> endobj
-1305 0 obj <<
-/D [1298 0 R /XYZ 56.6929 292.5255 null]
+1368 0 obj <<
+/D [1361 0 R /XYZ 56.6929 199.6254 null]
 >> endobj
-1297 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F11 1304 0 R >>
+1360 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F41 925 0 R /F11 1367 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1311 0 obj <<
-/Length 2800      
+1374 0 obj <<
+/Length 2801      
 /Filter /FlateDecode
 >>
 stream
-xÚ½ZÝoÛ8Ï_aìËÉ@Í凨�½§´qz^\“^â;,n»Š-ÇBÉ•äd½ýÍp(™rd9E�CˆÎ×oHšňßEšqû£0ö™æB�O|ô}/„å™4L—ëýüâçkŽb2ÍWŽ®ˆñ(£ùòwïÃ?.?ϧwã‰ÔÜØx¢Ý\%¦Ç‡Û›ëÙÇß]ŽCß›Ïnoˆ|7½žÞMo>LÇi
òÒj8!p=ûç”Zï.?}º¼ÿ1ÿõb:o±¸xWäÛÅïðÑ`ÿzÁ™Š#=z�ÎDËÑÓ…¯Ó¾R
esqñ¯V¡ÓkDûâçëˆi飉òY€ŽÞ(sÆ5Dmê˜Jª6ÊRôE¹áÂ(Wiùœ–cy“lyŒYHͤŽäÈUüÊ|ËÕc_9ö…âLªXw˜¯Sˆ{z3Ø ðŠ½×Ô4.bµ.v›%Ñ�×é¶(kê{ÎêHèýÛ.-÷'tæÉSŠha"ÆŽ‹2à,öãÛìŠÝOïþ3½#Ö0Aßr¾dõš4×û­ÕÜ	¾¯™<°ìóßæ=*4•¶,ïÈãÅ&©ª}ŸKª(‚øk-›Es{ߣZ…,�QhuÃR�±´¡�…·-³§ÄÄ
-¨Û]¹-ª”^LààYíkâŨfiEäÌ>ë¾/Ó¼/[Ye/댪Òóh†¯Øm�zóý"©jkÕŒ¼�+ÀBèà5@˜’E½K6›½}Ë«ð2¤×}±+Sœü*�Þý6]€§È÷:À’‡Db²î:1Êò"OÿÞë�³Hˆff,³*yؤÖÏ-¡^¤UÕºw49/
nBRcÕ
-Pê]™SÿÍoW·Ÿ.g7ôF½Õ¶È+P�Nþä>À$†mRÖÙbÒ7.»
/|hánÉVU¨[§Ã&nÐ '£%´ð5 Ù�ôd¹´“·@ZQ�Ÿèíîú‰ˆXDVÆŒö¡O{
-’B‰…½eÛT‰fùb³[¦}°Èc%�<†dæzýä1ÐgŸŸ"™)HDõáÂ:LQ“6«ì1O—¸t0†*h5	o“å_‡t¦•Á-¹ñØu¤ØNúæÞC²øJ¥ë LµMóØ°ú µË¿æÅKþJÒndh$b2rs�”±Ýa°•Ô5æôŽÓìâ2…µô”å)½f+ËK“­HÀ$D aæ°<r!Yî‰�þ™UuEmN_È›È³Äa ùÙ¤4µ?X6YùB©k9ÁäÖH‡‡v{³-Á']™àŽuØÃÚ°Ú`@‹ò�ÛXX4µ�|B�ô°
XèÚÃSÒH'UÚ3ív¹Ø•¤?·›¬²-ó�òÚ’�YõË©³’†mB1x2<ð˜ìQζ
-ÍHµzÐß/öÁãc
-÷Aćìµ<Ç»_à<Æï× g³›ÉåÕÕ»¼û<†�ÒË“hñ‹Qñsx®
Ä
×yÌCVÔÇfûq»f…ߌÝ�ð“ŠËaì.×iì-×YìƒVØ_™íÅÞ1+5œòƒøíøá£?Ïâw¸ð7\çñYuð›íÇïš•kòíøµd*æê~‡k
-*X	ævË­3Þ	™
8÷~b?õ•Ü'}:f+*ÔØÎX{;{€åǦìØ­Ö`Ý1É›Zf·ž
„f®¼Ã±fÜ¢g·‚f×ÉsêÔ4ÛÊW|˜?�­Ž=Å‘£Öw�ØØa­bHejŒHÙ–X Y¤ôV¯3+ë4MJûb.#àiJ&Øx0üvÞ"
« Ô¢;l=%¹-q·Å_’5ˆc™ºôkLö:*_•IU—ãÈÛ-ê];`¡pŠ·ðb™¶\HMS²	Å¡F
-2۱𰂋ë+TÞ}AtòØZAtñĶªdQfNù؉—Ôõ/OÓ¥™¡¹Ôé
÷Ð^¬l7žY•&;âB\'yžnŽ–Us‹ëªH¬Hò’Xš“Ó\©Sa„®¶x~b‹oNô›®ç…„Ïí÷_ÏøH1úò´.’ã Ë6‰®*çgœ…¼»E¶†­zE;¯Gߧï£'_èÀ´™2
©½Jº…•" ÷Âzñ¦Çq
�>äGqÀbAf£o#ÔÇŠxœ¶Azˆ€!ü<{’£«ðŒH�Þ‰£Ø@
-dç¦-d"ð€äwjŽaä•)M̯¨ðÔ
-ï¤ä±„
Šfkä­Æ@¢eÖHäý56ûvjÙÚì\&�%¦têLLqͶL�<uìò%ÝJD§–xëi¹²Ýß‚±=õuQ £]Ä×-�(²S>jC
jJÚ®¢ž@€ܘbn 2Ñ3´Ø€`Û²8öçôl ë!dÆ«žÜ<'õ[�ƘåÝ`‚ëO¶U4ÃY›‹vøØhfÔR¬,s¼Yéò/ÓtÛD;ËQ§F™¦­îŒöáܨ@�œÅôcË�Žƒx49ü燓ÇÀvø¨‰õÿˆÈ­-2E'j|Š,’1|ËkøúV4È�:­VÓ‘<°9Îÿê°
Üendstream
+xÚ½ZÝoã6Ï_aôå Vù!ê£÷”Ý$=]ï^’;×íƒbËkaɵ䤾¿þf8¤D)²œE�C`h4ÎÌoHÉQøŒÁŸÅÊg2	fQøŠq5[=]°Ùhûé‚™¹š»Rï.~¸•Ñ,ñ“P„³‡�£+öYóÙÃú7ïý?®>=ÜÜ]Î…b^è_ÎUȼw‹å5qz¼ÿ¸¼]üô¯»«Ë(ð—ľ»¹½¹»Y¾¿¹œóXqè/Œ†n¿ÜõÓÝÕ‡Ww—¿?ü|qóÐbqñr&È¿ýÎfk€ýóóe«Ù¼0Ÿ'‰˜=]Jú*�ÒrŠ‹û‹¶
+�VÝu,~�Š}%‚p6W`5Œ‚ñ(3Ÿ)ˆÚ<
+@—xeÁÇ¢l¥0ÊÛªnÊô)Âå"ñ%—3Wå+ÃVhÄ°tsø"	–¶<;ô[cÙu¶Îö†ÞV‡b�täí/yìe»jßPÛsža²ý‘Èj3Ði‘þp¸‘1÷ƒ(L
+`õ³WI÷æäi”‰YgHt^FJL{)8L¦vïqÒ&Ñ1G˜·"i§mQP—Uz¨3“@c	‰!äýX >\ú‚ÑÞ#¸wÐ{–°	'{C{Z×îœ@ê�šÚã;'vrwNfô4'ƒ±�Dq?âq2—×�„ðÀçck‘±]b8ð#Z„€4Äí
+9hàS"‚ÈÂrÄŠâÉŸÃ	,‚õÅ
+…¤ÚLIž^6˜­ÖšmÚ/iW9­”ÕþÉœ6àñ˜Ñ“ºV¿&NQ­¬˜"Ï‘kCIè¡çÐtY5}å5ä,¢ô,OÌ‘‹²ÉöeÖüÍè¡Um˜…YN_8]{€(Eª‡>¸Õ­òVž�Ò9gÉ õø«ŠvH‰±ÒqEJ½KW™é@qhû’Ú—¿^üpµXÒµÖ»ª¬©ƒ$XÐÑÑ٥ɀI»tßä«ùظ
+^¸¦â^‹VU¤Z§#7 È	Äh-|
iv ?]¯�Ãä-°6ä'z»»}O]`oŠM=Ú]›ò¤„íaŽF¬¨+êš—«â°ÎÆ`‘ÇR<–¼ç1´“ÇÀ_|z‰¥§ 1Ô†«›¢(
Á—2[ãÒÁÊ°ÕĽ"/¿NéÌjÓŸÛ÷¢ÚÍÇ&ÞcºúJé¤ï2tÝc°ÑÔ¡üZV/å«ž~kïIÜË@B$f_A*mÌ6èžÝ8Èá°’žô

_ó�‘¥‡ÎUÔA§C`aÞ02ù�®�ÄÈþÌë¦&š†…ÑmEèÛJþl:â Ðì´‰M;Ë7ªý%®õSÛØ$qdÚ‹Ä:ƒcÚ>ÅíÊl`n\M0€¢lÄÊ€hLÄSzd]Ö7ˆ•‰�žÔöNël0î)%{²Pš.E^7ýKÏÀ–™yýã©S
+¹·ãXÊiä®Ôiä­ÔYä“V;ä¯ÌŽ"ï™åpyx3v¸©Xñ3Ø©	ìVê<ö)«ö¡Ùqì®Y¡–ÉÛñã-9“3ø©	üVê<þ)«þ¡Ùqü®YácÑW¼
+
+Þ2[£—OÇW{ÿüžècu°—ܲ';¨Q8Å·ÞmÙÞ‘[AÝ@@ÆUpðügú´+²G¾EÜ�$¬	Çge®NÆ™¹ïœÌ†Œyßùß�Ûçc:ªÔÄÎDyó}2	»Êc¿fƒ¥Ç´übË™ý¢0ì\Áïô,ê̸uÏ~ÌnÓçÌ)k¶Å¯¤›?ÖVÏ¿±oÌý2–xµH°r1…ÔeFäìöX¥YeôÖÐ
 endobj
-1310 0 obj <<
+1373 0 obj <<
 /Type /Page
-/Contents 1311 0 R
-/Resources 1309 0 R
+/Contents 1374 0 R
+/Resources 1372 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1296 0 R
+/Parent 1346 0 R
 >> endobj
-1312 0 obj <<
-/D [1310 0 R /XYZ 85.0394 794.5015 null]
+1375 0 obj <<
+/D [1373 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 414 0 obj <<
-/D [1310 0 R /XYZ 85.0394 693.6703 null]
+/D [1373 0 R /XYZ 85.0394 592.2428 null]
 >> endobj
-1313 0 obj <<
-/D [1310 0 R /XYZ 85.0394 667.7108 null]
+1376 0 obj <<
+/D [1373 0 R /XYZ 85.0394 565.4551 null]
 >> endobj
-1309 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F14 685 0 R /F62 995 0 R >>
-/XObject << /Im2 984 0 R >>
+1372 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R /F14 729 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1316 0 obj <<
-/Length 2594      
-/Filter /FlateDecode
->>
-stream
-xÚÍZÝsÛ8Ï_á·S¦µNü’¨½§l›ôÒÙ&{ivæf¶û Xr¢9YòZr>î¯?€ )Ù–O?ævvº‚A$�@�›Dð›¨8ŒSžN’T†*bj2[œD“{hûp¬ÌÔ	M‡R?ßžüýB$“4LcOnç]:Œ´f“Ûü÷ yx
-¢àÝõÕÅå‡ßnÎNÜ^^_�N¹Š‚‹Ë_ΉúpsöéÓÙÍé”iÅ‚wÿ<ûõöü†šb«ãçË«÷ÄIé³GéÍùÅùÍùÕ»óÓ?n?žœßúµ×Ë"�ùóä÷?¢IËþx…"Õjò?¢�¥)Ÿ,N¤¡’B8Nuòùä_^á Õt³ŸT:T\Æ`Iêˆ�™…	c “HsL{#s6fd'…F.ËîeÚ«Çbµ½bÐÊXóÉPïÎè^jdx1žqJ	­ã^³rþr:"
ž²Ž(;!C×Ù¢°íeU•-—EfÛËš¾Ýƒ[�2ÝzU9q>_Ÿ
›f�ùÚÆyc[ùߦ.ZDN¢ƒË9f2i¨ešâŠÃT)næ_ƒ 
§léÛ⊾D/ò·Ä�‰Õž"õÿÍv õ!EëCêÎrÖm‘‡;H´þ#†ZÅò0(†RûAá¥zPÌšºËfÝ*xBˆ&‡‡÷R#ão¢B…:›ã{Pp--(¸V�›�a[«
ÛZ
xH#*°•LŒMT`“AEßÔ£çÍ)VD[` ¨†dÒCÊ�ÇB~0¾p.Cüß×

²DÄ„x©@pR=Ìš§E�ÝUÅ$$(•¤‡çà¥F&±�L‰2åÆ,ÎidcŒUüæeÛ33g-ç(aè(Á ÷[^^̳uÕyã[vFþ·*Ì`lÍu }-èRlí¤p•vEÓÞ滶ŽC�Jvx^jd›¶f¡N ucï{»
-ˆ¡¼|,óuVÑoo^90ojÍ+‡æÿbh^áV™cW·"h–]ÙÔDϲš4ÞaIòDm¥ÞA<‘ë0x¹t èÊÎúoY
-¡–F1xIˆ�±Aµ
;ÓPDDÎÌêùÜe]Ùvå̆ñEIQ°eΈôB^0ê|÷v«;NØMñ¾¨‹UÖ¹ùßY<î”*>ƒ”‹²sBÁb3ÈÝÚ¢¹n,QæE
£e•Ë1�ƒ{Ö9ª6Vñ$LO¯(_/–.YÝ—uëRX÷`Ë>UYoùŸâ§ÏøµñÍ›7ã.xïGô"_"¥‰€2•)ü`ã.ÚY�ÐIP¯w¦Ø
-dăj«4kº™÷=Z’2ûnY[µ±ë5kÖugì†C½,;ªÃ@à1«Öv §Õ·¹ÎÊ#‹£t
- �ü&ƒûª¹ƒt¹±"J0aË6e'T¡
-–‚‚xdäè€e£
-p”ND¢B•¨£ÕjÉ$J¶Õ_×ËMV-“Pó(Ù?ê�.Kº›ª¦~Qˆ’
-¬x¼dL…R''!�b²w»žÍŠ¶qL*QWcô‘€aíÀ´I²¦VÉ|]ÿϵËïðc‘嶫
²K¦Ÿ¿ØÉÆæ DÇb<ü
-åìa,:ú3vfçÅÏÕõùÍÍ5ÞðˆØ
-µË¦nj¶™å;úV°ñZ’²¶ÕíÓøronvÊ©’PÂN;:õÛ€‚�‘ÖP8Š0=x¥´£ÒõØ�½H„ZJñ
-öX
-“­‹y±ZÑÞõ:ö$ã{H#ö$=Ö�I~5¤uäyÄ
r°Òê[ìØFq¦£›¨ñr{À=ƒu›-¨{xÖò°wx
-ßDQf¨ŸW«¶èŽÌz°-
m2ƒ�9ÊZ;ï ¹éäPœúHÛœÖ#ÛEm�yÖeû½50Ã÷u–ü®Î‚óz™æo%,T±=F×ÏyƒßqîâJyw!�î¯wþ°îBrÓ]0=ºí‚–«¿¿þtvy5–Õ6üuÀ'ƒÕþ•#HÀy}ïm–w
-äÞØ
vž•ÕzUBxÆ
-º¦Ó1^ÎÂ�6×/æyá�Ræh¥U_AÇn;í_1 F·Ïqpùëئœå¹MC-^Ç$i°lV�!µS�™§Ìm³9®³ÀþÂk›²êœˆY•µ­åU¤;ËG/¤î
->\Á�#wéšC§¯búG`“qØÚÙ+
-p'4>£ÊG,çUÚ—óŠ
-Fä4ñR㞃$Fýô äWô˜:Kšh*~Sé.ðD¤,ê�I—N@XÔ
xP
ù;£i}×0vÝU£h¤80^8
-8ƒ¦$S¼¢IX�ýÇ6
Ç|-:ZÑÞ…TpˆJÔ±š°
-�îûë¡Ð c‹ðÏF×7ÿåKÿgALpÚä㨳ànRæ™Nî>ÌF!WøÈÔÿ^»îùendstream
+1379 0 obj <<
+/Length 3229      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥ZÝsÛ6÷_¡·£f"Ÿ$ñ˜6NëNëÜ9îô¡í-Qç$R);Î_ì‚%ZI®“™\,‹Ýß~
+shšnJ„¼�)ËỪE&|f´7 ø«-	©j|†-ë`2¯Õh“‚<T‘=Ÿ«Þfõؘ úŽFMpgwtû2IÞkåá04lÇü«²ÜkWõ`uʲ×/´N-“¹Ígq,ý³ðt‰ÀØâsH1ÿ,y,4³¹€t$5@*§“¾`™€h_¤*c&WzÈ
+b"é÷\ÎCÞ�@ÈXðÄB “é4—³XîÙê=×Äò*Z^HÁ´¶f¼þÇ}¹¬Ö
+™G:<[·£?9—åê
R@±ºáÀÉÿ}€ûs#
+=åØ–«3䨌Vjs1×ë è¹P,›º+–Ý*$gÐ2d——ï¹&֣°<Uãõ{PÈ\(dn’ �'“Õ€LVZ@…c¾2!3êT¸)�Šaj@…›\7s‘pÜç<ÝCÝCk&SÀó(¿0þ”àî¿ÿF‚&ý"®@\üž.ooË34@ŸdLf/ëÐsM(1Bƒk¿dÁ‘׸²·ƒ/xðô59‹`­à(Š0ç(ã{¢­Êuqô
�OäýO"übl
i̤ا\°uÄuÁÖ�Ëí’v´l~në”å:·‹:ô\JŒm-XžAáiñn°«‚ZUOÕêè[
+xïÍ«#óZ2¯ŽÍ«zü«Ø¼*ìrå>…&€˜hö]ÕÔ8^5J|ÀÖi‘q&3cÇźn‹Wû
+Ôù¡EUÚ$E$Ni
ŽÄ¹É%ˆ+!'¨Ôõ–mƒ,K€5lí|"‡$#jÛÿù„.
+V–åÄFò�½½B5®RÕ]y µHœè$U»½w`óD[éúµÝ7uKSІ­1‹.ÐqRhÆ9ô-#ÏíŠzYbÛܬ]^í�‹@±6O~ÇäsÎv�Œ{o
+ícƒ�sy< ³7’õ‘°õ6+('
+�HŠDUôD_ý}¬(-!uwôµÒ�š¾µT®DÁûÎ`¼{¡¤pTÛàÍk¶¢Íõ¶XˆT1‘
Î	÷ŒÇÖuOÐDT.C§d\eÎj
L�£3íËŠ	eHàµÎÇ}J¥ÑÍý
+J{ÜQKì‰ÀÍ{ýæý�û*èßL央÷ÂÈ[)3VȯpVjq
m€¿\[†vé�nÛB{�ot7úz:ÐÙçÚŽ•ˆŽš'º¤)Ó\«‹YD0�rs1‹£ …a€ÞЭ1^XZêÃeß´mõÐ_W6´§þŽ"ºã…h™ÉO£û¸ß‡Ve[íª“ ïqkNüîc:x‹(z^Â¥À´U%íŒRipZñiA–m«ÏSvÍãÊd½Ep/pN2©U¯·SQ‚Õ~èÐ`†,¨BeUX}á}WÕŸ:ªÿ8…’úŽÄ`Ç„´qÃä»Z·ï_Æ-’	ÚQsòûÜ@Êï6‹© iŽÝ$@Y–©ü[�Zç‚ ?i¨Ë—å¶ZNÉÉ™�}[Ü!p‹9
+ÏÿúSƒyt;ùÇå²,ý8|—�–FÚ#^·¬¶eÛÒ¢ë‘>ºOÇaö‹]Þá
+#8Á¬ÎáLÙ7eîÒ �"¸žqDJ¿<9Jø©ÍQè+Ì¥T²ÁÇQB{'ðøê>"Oº¡o Eà<F›{ÂÁq½ì	Ça/£í»ººõ�õë0ò·ÑUÝâ[��vW`DeI}Ü=`
 endobj
-1315 0 obj <<
+1378 0 obj <<
 /Type /Page
-/Contents 1316 0 R
-/Resources 1314 0 R
+/Contents 1379 0 R
+/Resources 1377 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1296 0 R
+/Parent 1346 0 R
 >> endobj
-1317 0 obj <<
-/D [1315 0 R /XYZ 56.6929 794.5015 null]
+1380 0 obj <<
+/D [1378 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 418 0 obj <<
-/D [1315 0 R /XYZ 56.6929 598.1755 null]
+/D [1378 0 R /XYZ 56.6929 489.6987 null]
 >> endobj
-1193 0 obj <<
-/D [1315 0 R /XYZ 56.6929 575.8643 null]
->> endobj
-1318 0 obj <<
-/D [1315 0 R /XYZ 56.6929 387.929 null]
->> endobj
-1319 0 obj <<
-/D [1315 0 R /XYZ 56.6929 375.9738 null]
+985 0 obj <<
+/D [1378 0 R /XYZ 56.6929 463.7183 null]
 >> endobj
-1314 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R >>
+1377 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F62 1050 0 R /F21 702 0 R >>
+/XObject << /Im2 1039 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1322 0 obj <<
-/Length 3098      
-/Filter /FlateDecode
->>
-stream
-xÚ¥ZYsÜ6~ׯ˜·U™‚Gí“ãÈŽR‰¼++•Çåâp03¬ðó�<ÙÝÿ¾Ýh€Ç˜’ìré�@£
4}|�_1øã«XùL&Á*J_1®VYyÁV{{sÁ-�瘼)×�w?¼–Ñ*ñ“P„«»Ýd­ØgqÌWwÛ÷ëW?¿ü×ÝÕí¥'[‡þ¥§B¶þñúæ'¢$ôyõöæõõ›ßo_^FÁúîúí
‘o¯^_Ý^ݼººôx¬8Ìv…G&¼¾þõŠZon_þöÛËÛËw¿\\Ý
g™ž—3‰ùtñþ[máØ¿\0_&±Z=@‡ù<IĪ¼”ôU ¥£ï.þ=,85S—ô§dì«XD
-|I�*ñC)¤Q`ßh<°Ê	+ü$�1¬�</,Çt1å"pÛþXäYÚ--?ÖñD¢Öu³°�ü0Pn½¦>õvi5GMË×Õ°b®7¿j�WYsÉãµ.uÕé­Ý/­¶4\¦'âO·Û¼Ëë*-Š
eißjìzA>!@@ÆÝÎ�Îú¦…%–dÝ(%,gV÷ Kc×®i»�ÙbåÉDù"dáÊãÜOpN9;†¿ ƒ¹`a˜h¹<KfŒ­_$s}§3ìZoH³C^í$‡U…ò¹ŒÈ6î@žÔD_ØÖ­[3XNƒªe¯Ó¢­‰%Ý78»è\CÄ�UOj¦/È"?Ž¢ÑÍúykªh—UkŲ’Ð@W)/�F•õ½=Jç8HÃí±®Z;tÔÍ®6d�nG€0Šùí”i•¡©DɺÞáu
(	pÔõ]Ñêî’¯‡Û
-£³ÔÆà/\°
¼0‰ž
°Ò�¶ZF6ˆb"g
-·\#
-5ž”®h„äáYͶùßKz�$Ôµ*4BgP
-‡‰|NM@eû¡ÁˆÕ t™URö…~™WäŸÁ$ÿÓ­4 Eˆ‰hsÀdP†ÝwÀ/sˆ¤œtœüq© äwoÉIê¾[.ª£h(㿺ÔZªö#ºü—�2¨ö—Ö‰}ç°lS„ÀŠ
ð=ÃLH2f‚

-LИ%|6…½8hWzÐE1§Ð|Ά:Äš…
‹²Nڶ΋¹'PÚÏÌÞà&T½�ëŸë�h ˆ)	³Ü65$55$A¤ùÙDåC©skPp4w<ÎlÚn\SÛêPYä<ÎÀ€d�m²	
-¹h-ƒäɇ£‘Q©ãP‡HäºMKM¤3™“À¡I@!¾™ª
[ƺqý>Ë´65°›6M;­Ý˜hû”ö(tÛÚMw3y‚!»ÑgQ^ÓÀ¯nÐkb¨)P†Ï`ôðÁÙƒKQ�Ã11s
-`Ÿ¾ØucgQ„ c‘R®3óAŠƒwœÊWœdo›@óÈ™óÜÚ°?ºr�ŽÖŽÝYfvŒyµ0&âW®……<
-
-lÏÑŽû¡E™�/A×Â…G5‰Ðq™G&³ˆÂ|—VúÊÈ»øc+˜J”Är’/%üÌVÿⱕ:épƒÐ9ö¦·§@ª¦}ÂÙε²pÑP»‘Í>r>X4WÌ$XaÖ.kå¥BfíÀ»

+1383 0 obj <<
+/Length 2832      
+/Filter /FlateDecode
+>>
+stream
+xÚµ]sÛ6òÝ¿Bo'ß„(>I }JS'uçšæRwî!õdh
+²9•H•¤œøîúßo�ø!ѱ]÷Fø^ì.ö›b
+?¶ÐŠPaä"3’(ÊԢ؞ÐÅ5¬½9aaO7%ã]ß^œ|õZdCLÊÓÅÅzKª5[\¬>,_}ÿòÝÅÙûÓ„+ºLÉi¢Rºüöüíw8c°yõÓÛ×ço~yÿò4“Ë‹óŸÞâôû³×gïÏÞ¾:;M˜VÎó
+g6'?Ÿü³8ZõGçø'•&ŠËt‘(N4MÙ<—)¡
+¸–d’‘Ô(Ùs™³9.Ç]ŽËÛüs’yqc“¶ü·=¤š
4Sl1}„@¿k1€¥0MP¸¸±§‰ ÂáRn÷[äÛz_uد×aƒÝÖÍöË
+Û«»Î¶Øíjl÷m
+…3bÇ•ôعv•w9ön®õ׺Þ�ýæ”é¥uã6î*CoSnËî…ë«álDÙõ?•›
öŠ�ÍÃ-À2\u}�ö-oíæ.
+Î8Àv Yú#nšJvFŒà:ì!aèODfí´,GJA™…"ŒKDÑY&–�™¢”.Û.ïʶ+‹6)nòª²›1ûìÖV
Ñ7M¾ÝæÍ¶À
+žz›òêóvÃAk¹ÖÑ�H¿dú`{ŽÄE«_ŸˆÖTC
+†›«×)²@g0�n¦‡v�Gì­‹.üÖuh;\Á£)<M¹	SŽÒz@ãcÂ,PÝä�WZºç4*<'¬åÕî/îoÛ0bµÎËM`@ gBôÞÎak”³û•àe5g|@qy½¢7¶3®ººw¯E]ux—Õ›øn ‘M0™ãðâÕ;·uñ›×~è;�`«²ºÆ=y˜FÂD»³EéŒ-¼Ê1ÊlC¢¦ÜÄ"ˈPRCøÞ<cú1‰
+µžO’b2y¾ó…SÞosz[qÌTÎ5©	dxkñxdpX3y/¤æ.+zˆð@B£˜`Sø�dž"ªªÓ!–ŸnJˆQôa]Qyü^äÁ xó£Í2ŽÏßÝJœqIE˜I±çÀ˜Ûå\Ý£)PÏ!2»�±÷C„h€<É	ØðìÙŒí!&c�ÇŒå�Á1•™áæ/1VCeÔXŒ¼�‚f’
+Ê�ƒÂÃP<;Í"Dšƒ7eûF‹ŽÃh�w©
:=Ì*°¿|€ßßJ;›·*0\Y…÷Þêð„  XSA¨ÁìÎÓº(Æ{g>@Ç÷‡Æ]x‰«Þ
+û‰5¶˜|:×裟wÂ>DÒÃP²N€R-—.Y©q-žÂ[F@Q
+‚­3ÉÐèšhÖ}¢ìü±¸¦†è,»ß²¢O‘µdššŠgKk1ƒ<–V�O�@͆›¿,­
+žø
iå2‹[¾þzÎKFŽ<—[¢ŒSWx"É*„ž!œÃüÊÁü¾8Ü£ét/ˮ竮Ü;ôb¤r˜ÕFÂѯœËªdn2¥&(©¼WI1Y–.F»<DÄ
+�©R0�„»þÎ./Ã…@b[vå­?Ä1 rêí}Uc&¥çQ´
+øj×Øuùyc«Ëq�ÙeîƒÙ\ýõª¾Þ‡‚ô�m?ÖÍG4¹á¤{PšŠ¥ã¦¾-W6)?¯›'À˜ Р>†]Ušw6Ù¯vøñÍOUûíUdí#nwðž kòª]Û¦}ìi6w:Árêჺ²	lødûo
éê.Ì·ý6½ôK8ÿfïúï¾qæÈ…P#
 endobj
-1321 0 obj <<
+1382 0 obj <<
 /Type /Page
-/Contents 1322 0 R
-/Resources 1320 0 R
+/Contents 1383 0 R
+/Resources 1381 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1296 0 R
+/Parent 1388 0 R
 >> endobj
-1323 0 obj <<
-/D [1321 0 R /XYZ 85.0394 794.5015 null]
+1384 0 obj <<
+/D [1382 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 422 0 obj <<
-/D [1321 0 R /XYZ 85.0394 732.0195 null]
+/D [1382 0 R /XYZ 85.0394 690.4757 null]
 >> endobj
-930 0 obj <<
-/D [1321 0 R /XYZ 85.0394 704.3916 null]
+1385 0 obj <<
+/D [1382 0 R /XYZ 85.0394 663.4801 null]
 >> endobj
 426 0 obj <<
-/D [1321 0 R /XYZ 85.0394 215.3041 null]
+/D [1382 0 R /XYZ 85.0394 582.7428 null]
 >> endobj
-1324 0 obj <<
-/D [1321 0 R /XYZ 85.0394 190.7685 null]
+1386 0 obj <<
+/D [1382 0 R /XYZ 85.0394 552.623 null]
 >> endobj
-1320 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R >>
+430 0 obj <<
+/D [1382 0 R /XYZ 85.0394 310.6261 null]
+>> endobj
+1387 0 obj <<
+/D [1382 0 R /XYZ 85.0394 286.2805 null]
+>> endobj
+1381 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1327 0 obj <<
-/Length 3841      
-/Filter /FlateDecode
->>
-stream
-xÚµÙrÛÈñ]_ÁG*e"˜3SûäìÚ§obksÔÆ•‚HPBL\”¬TòïéžîÁ%Ð’²•âgz®îž¾b‘ÂO,L–d^ú…õ:1©0‹õþ"]ÜÀØ÷‚ç¬â¤ÕpÖo®.~ýVÙ…O|&³ÅÕv°—KRçÄâjóÓ2Kdr	;¤ËoxÿöÝ÷?~x}iõòêÝï/WҤ˷ï~ÿ†Zßxý‡?¼þp¹Έ巿}ýÇ«7h(ã=~óîýwñôwfÓoÞ¾ùðæý·o.?]ýîâÍUGË�^‘*$äç‹Ÿ>¥‹
�ý»‹4QÞ™Å=tÒDx/ûmTb´R²»øxñ§nÃÁhX:Ë?‘&RerŽ�~À@—&Y
-[Yã“LIøÓå*KÓe{Ì«f[WM}:®þ=5iyÐÿÈ7›#Aþ�/„õ‰’Ö,V"±Z™°Ñ¯Â�I¼µÙb
-̬øý¶˜6f‹–:Ñ©Óc™þÏ78úë·Rt<»—Ât—èLg�ËÜ@
-Û5Åñ®8’UÿØæm±/ª–ºßOSY•mYWÉ«
5~lò›‚�R'I“cl8éê¶èðé'	—d.50ç0�÷’`¤-øž6À-Ë
áV4Ô]ßæÇ|ÝDziË5Ûšþ¯úÏ›¦^—°Í†ú÷e{Ë#ôw¼nYìë6,�Ë*ßóRF| 8JéÕòÝv´ò@K§/´vW\Šeu'Ðu¹D?QìU°û¡X—¸¶Ø¼BˆY¶·²\Ép
-2SÓü(leEw>òÐàì½Í<ß9ò“¬ëj;#àÃÁ/Ä©	P¡k¤C'
-_“B�
…~J
-ÆVÌH¡UËu^Q£^¯OGjæ<FtƒÄ´õ� »â®ØñüíhìTWx
7§cÎê@„ìxBÍÛ—USnxç|†,%L"ŒrŒð]YÜÏé–Nœq�¨B‘±ž„ûÌþ`�}âR;1<çϱ)@sÏX¤¹Í�ì¹e]”`O3{w:Mœ5Ϲ<©Å£ãÔ2ãáÈ pV{[7|<Šz„ÖbvD%Í"Kè ñÀ“êÊn˜]¹Iœ˜Fu0X*)aÚ‚Š–7UÝ+­¶i¸�0�&Ü•`LðhìôlÃU=ÇkÁv:óþdÞÉ9þ(a‰6<dDÛô,¡!fÑò=k†`v6n8
-v[13ÄžAB*†ßò�Þ	;ôGT)áÉð
-¢ÕYLˆ©
D#žžEAÑŠ@³æéí|te!
]xö”Š‚»2*ês}àv/«þ€\°ã8
þovõ5jC€…¥
u®Am?ó6
-ž…8£X2?I+s6ªùÈ‚Îú—³Q¥v*z¹#©ËY²Mâ{™èâm'É2±Y’Nôf	™"š%„�XúÞ,á¼@•£\ç²RKç£ð89ToZ5«up­:õfÌ5²AÒfc96Ë-iÛžIšM4D¶™ÐÁ8üޢ¢fºŒ53ci
+ÛWCþÀX”V­·=3–	PËÎi=}m.3�¤v/Ù|CÌ	1‘Wg2¡F¦립#¬“aèDFÏ ŠŽ‚”>_Zßýõ-–z•ž˜qP²602H(5ÇG8¼áaâ4Î;¨¨�£ýÆ,J
-"ïÍW媛5âEs[Ÿvˆ%¡ùî>h¨}_?£ædLJ
-’ùsæÜÉD+ežmε•1HD®ÍJ£;%zZã¬÷#;Ét•ün:ÞŸA.DÝ�JöèÝ<Š M�±c
…!§©.Þ4:«L.¯“yhdÈœâxg]ס¬06Z¡M²�`}i&PRîù°šG;ɃNIþW,·5ïR|É÷:FKƈ°SŠ|�SUé¥|`P®O77“ßú˜7·1ňVj]�—ny:´<€µ˜|h1s&ëe.Ôimq±©š3…ÝÉcÔ‡Sï:1‰í#zá8hŒè
Ö%zÐæ8sßòÓCËËjúçCìòÍwï?ò
-Š³–3öûSF/8^òr*£ÆwÀeGLÝ¢CyA“ŽË�çsºÙôŸRR)ôÂì˜�9À2è>+˺²^Òê´9¬šò_sea@ÉgÎO<&äèµñžW'ļ…Ö�ßý‘ƶ
Äi»#é±|¬jK*
-Ï°÷`B;¡9#GB¢»rFDi¦îÜ¡3Œ°€7ÒñWÛFÃÌê®x5µe}Ø12hló°<KÃ÷ÝàPû”j—±ÅÖÐc°GQ;ôv$E7£�BþeÆÔ‚¦³æíó/_US0WªËG:¡*ª©PÑ‚¢sûRîO{ìÈÎ*ÖY/šðHDëI�¡ÕR¨ÎØböR…ʧŸh•ŠZEZª¥Ò‰švª&¥$U“’Ÿ~
-V®°}L$?ÓÀT.gqè#I&?WõýTd^.™ÿ»¸±²ô¹ôèi朂uíkªk‚ɆÜâ¾&0¯œ¯0p—]o@ÎW6:?²Šfü‘M!vY”ݪXÁ†÷³•h#c¥éK1Z„Ê
-†°þcŽ®ø?£À2|pÐ)põÀ„͹õüX£CžÕÐÑ!O„ãöôXÑ!óu'‹‡q4(â¦PÜ›4GÂJx|•3cûü4)²{	U÷$=	I"vÂëe	ʈÖ[C~‰uyœL‹d|å
*REÀ€½æ’ôOÕðhëzÃð‚óQ
-ÆÖWß}ÿjz%�bg&‹´ïÀ?:Þ,¨ñaðEoœ½L'v©œî‰|,"Ò΂75S<„Ê›efˆÈ£Š»I_?ÿÑ^ý{xz,;dË6ßñç
+1391 0 obj <<
+/Length 3884      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥Ërã6òî¯ðQ®1x$P9M2ž¬S›IvÆÙG%9P%s‡"‘²G©Úßntƒ/ÓcOR:h
+0ˆÅ·?¾{{óÝÏï__¥ñâöæÇwWKeÄâíÍ߯©õÝû×?üðúýÕRZ#ßþíõO·×ïi(aßܼ{CGO }ýöúýõ»o¯¯~»ýþâú¶;Ëð¼Rh<Èï¿ü&.7pìï/D¤�5—БtN]î/b£#k åŇ‹t£~é,ÿ¤ˆ”NÔc9` Q"
+ÙŒ2&“ÏI¡C…ŽŸ“B�zŸÊ)Lõb�UÔ¨×ëÓ‘š�ѹAbÚú@�2¿ÏKž¿MLu…×°;3V7
+€=ÉËìÕÅ"²©yÉÝ©X>Ú¾A%3¶ôš
{µwuÃÛ£¤hM –`K§¤Yd-4Î<©>,é‚I�‰¬tcU¨½½Ò„„Ïæ5´ØUu¯³q*ü
øi4á¾
+vx;«R62 ×|?Dãì-Ê$	³Šfxm©ƒiéÄS�D&‚–ž˜n@©_bº•ˆâ¸ïñ¾“¸,>mçÏÀÁvN
íÜ&oÑW.öé%€îrÏußñz¯S»(ë5Fbë
¸êØ
QÝ4ú†ùû¬i“d¸g˜B×Ü`ÛmˆßÔÇ!AEÌH]$�‰£k/ª5)‰§G$‹?¼ÝÄV!B³õ´ƒ©~Ç@zl$ìÐ�JKG†àevŸ#H	^²×�Ò&$rqš²¹B4-ï9g•4„¿iÓ9Ÿ“/0&.îœï<=8™0°©Rnì‡z& ¯$¶«TQR3//žŒÊïÊCÝ4ŪÌ#ºÈvÓþ`ˆgö`J§ô‹øå2�Ðg%‡�솻õ(:PãÀÔÓs¼ŸRó!!l­«%çöKúú9AÂKT’ÎjSXÝR�t:!+Íš§·óÁUj"#�{¡Š‚»2:ès}à°U¿Q@.Ørœ
+ŽuE/Ãëd:A†ÑÁ3ˆ¢#/¥/—Ö›¿ÅJ‹Ž'fÔ€¬
Œòɘã#Þð0qç�X§ Ñ1‹À²S[ï!�
é¤Ô3^lÉÔAk•ù
ö}
("jÞÞqòºå€Ø§Ã^ýûd`QêëÐî¿]T¹g@hǪS ¼yAÙ/zûb}GÍÁáíð„®;¡ã Æë(¤ÇÖ&l_·_C+憺ëÕv•áê¹P,Ö±8g>ë(—ݬ/š»úT"•„fåCvn¨ýP?¢æ$	LJ
+’¸§Ì¹UQ¬µy±9�S‚DäÚ¬¡4q§DÏk\êÜÈNò¹
+þ÷7íï�þ@ÖGÝþ”ìÑ»y=@–:“Ž£H2šjÃíA£³Êäò:™‡VN†ÌjŽ·pÖªöU%€±Ñòm’hxëK3á$Åž7«y´“<èäåb[3–üS¶ÇÐ1ÐX0Ed€­îHäkœªJ/僲:ívçI}o}Ìš»�b+µ®�Ç+»8ZÀŒ‡Z||h1s&kb”ž©ËØX[œoªæ‰ÂBÜÉcÔûúRï:1‰í#zi9hˆè
Ö%zÐæ8sßòÓCËËjúçMÒÅõ›wxÅÙËûý©£ç/ù�r*£ÇBÆUGLÝ‚CyA#ÆÕƧsºÙôK&i$”Œ¿ ̘*Oî‹2°¤«Šá%-O›Ã²)þ˜«
+I.±nâ1!@¯�÷d¹8‰ æ-´~~ó�y´Äi»%é±l¬j*
+ÿeÆ4MgÍÛgŸ>«¦`®t—�tB!uPS©ƒEçö©ØŸöØQ�=Ô¬³8ž7þ�ˆÖ“C+¨¥Ô�±Åì¥ò•O7Ñ*´Š´4Ž´5íTM)Eª¦¿ü
+\�ù`sn=
?ÖÅè�g5´µÏa»==VtÄ|žÄÉâa�Å
Š¸é
qƒæŽ°”_åÌXªŸ?
+Äë}�Ù'TÝ“ô$‰Øñ�—(#ZïòK¬ËãdZ¤Â+@P‘*zêc.™AÿTm€Ž¶®7?œ¿G
+½¿…
ÿÒˆ
ÿb»=S‡Q_sö:CmïNÓ¯BÃ{:ldŒ$è&âàê³}ª8v×Ä*ÜE§©Àû%à…D.=íV�À¼-DSo}qu&ùÅš˜ø²ÍR	Û½2úB8ªW`ð<~]×*~â Öa´þvlD$øXTŠ'öK5hv�Üíì›Ki×ñðˆŠ[x×Äqé$�|b°Ê'IØ„ˆ‰õîx�éˆÁnje‡:™v娔�.@Êbï“ï4„Aiø€…æQ-ÓÉj}:öa!ŠjUŸ¼6A'Ô帮8òEÃMFüÇeã<ŠÞU)1㣌„sþ)L—ê¾x†=žØi5wàp'ŸyÃÄÀ³áìœ
Ù:˜äÎY‡G¿yÁR��õõ’Žæå�ÅyVÊÒ8R±çhQx}•‘pþõõÙ8l-�
+üú˜ŸŸÈÞ�HÔ4{�!ûØ€(�‚Ì}„`u÷´Â&Ó¯À”€{u RËT½ä;09kíüW`ËãrˆÒâ59?˜p›$ýÎ^Y6sI¸ŠlMღ
Û›Žø©z¸«Í„
S&´M�Ìš@~bòû0ãùÍZä+pk|GðY@Œ9è+~ŠÐžùÅÀNMQ0¾¾ýpóÝ«é­@š��_¦¹È&HCÇÝ%5Þ>ª³—ƒéÄïá)§8‘€y Ú¦àQÍ”©“(M3$äÑ7}ݤÏïÿs@Òî¡ô�,Ú¬äOð9«æ
+mÓqµÁ&cË•B6ÿ/F”zÞ­à÷Ío\´´j?¿¾=·>¸P–WšN‹!¸§q“=
VvUÖžºr‡éJh†Eþwy•é«;ìžbƒ	é<,B	&„#
+€>ÏÁž´|ãp€œ1LjñD#”®H—‰N¯ç«ñ“—/t»¢ÊÚÎÎŽ“žçêu#óMÏ%¦7/8Ê[ðUWØUaluûdÈ,\Ìf\¯KˆüN;âbÁDbcwÌö{Hê|}n�sr„Ø$ÏXm	ùè¹±B’Y?4ÔöæûSÙ‡’§ NLµ4~éUÂ}�îÓF™L¥ú+eþb»àj€Lâ(}ô…Õ  (™‹œ{rø3÷­°6ø¸1gD÷í_þŽ¸ÿÈ:†xÎZ5oOTjñY¢ü÷ºöåáƒãǤÿC_ý¢endstream
 endobj
-1326 0 obj <<
+1390 0 obj <<
 /Type /Page
-/Contents 1327 0 R
-/Resources 1325 0 R
+/Contents 1391 0 R
+/Resources 1389 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1296 0 R
-/Annots [ 1329 0 R ]
+/Parent 1388 0 R
+/Annots [ 1393 0 R ]
 >> endobj
-1329 0 obj <<
+1393 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [87.6538 61.5153 137.7628 73.5749]
+/Rect [87.6538 116.0624 137.7628 128.122]
 /Subtype /Link
 /A << /S /GoTo /D (tsig) >>
 >> endobj
-1328 0 obj <<
-/D [1326 0 R /XYZ 56.6929 794.5015 null]
+1392 0 obj <<
+/D [1390 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-430 0 obj <<
-/D [1326 0 R /XYZ 56.6929 659.7801 null]
+434 0 obj <<
+/D [1390 0 R /XYZ 56.6929 718.7806 null]
 >> endobj
-1214 0 obj <<
-/D [1326 0 R /XYZ 56.6929 629.052 null]
+1274 0 obj <<
+/D [1390 0 R /XYZ 56.6929 687.5668 null]
 >> endobj
-1325 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F21 658 0 R /F23 682 0 R >>
+1389 0 obj <<
+/Font << /F37 791 0 R /F41 925 0 R /F21 702 0 R /F23 726 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1332 0 obj <<
-/Length 2654      
+1396 0 obj <<
+/Length 2509      
 /Filter /FlateDecode
 >>
 stream
-xÚÅZÝsÛ¸÷_¡·R3HLžœÄN}í9w¶ï¡“Ëx(‰–8¡HE¤¬º�ûßoðKTl7ÓéøA ¸X,»¿ý ƒ	ƒ¿`KŸ	N"ú’r²Øœ±É
-Þ}<,ÍÌͺTïîÎþz)¢‰öµâjr÷Ðáû,ŽƒÉÝò³÷þoç¿Ü]ÜLg\2OùÓ™TÌ{wuý�f4ý¼ÿt}yõñ·›óizwWŸ®iúæâòâæâúýÅtÄ2€õÜr8±àòê4úxsþóÏç7Ó/w?�]Ü5géž7`òíìó6Y±:c¾Ð±œà�ù�Ö|²9¥ðe(„›ÉÏnÏ~mvÞš¥cú“"öeÌ£r1¦@©}%à*0™Î„ÔÞnÄ^úmŸV5MTÙªHê=ÍãTì²<§—ó”~Wi‘î’:]Òã¾ÊŠ
ëµ]ô5}²·é"û�1î¨×iË\{Ia§“í6-–Ž¨ž^Ùc©½MZUÉ*…«R"òÎñ@³ ðµ”Üœªw¼¯r—­28�'I¹¡'ôpSÖö¹Jw� §gýeÝ%þ¶Ïh°´¼Jú�; I÷nþäösÌP?Ax~sŒÈׂÇæçy½.÷«õt2+$V»d³IvôP>´o�Üyйó@h?RR
gd»U–ªk,#PÂ-òd_Ù­’</�J»åfŸ×Ù6·$Èó
¨³€ëÊŸp>@ËÂ×hRlSËÊéÇ™
4 B?Ší®”<}±ß‘š‹:·Z¬öÛm¹óUÞݸB´pÎíQë]RTdˆ³ªÜïéˆz"p>®c»-u”¯ušïìQ�°Ž
'T÷4�–Jr˜<j¨¬�ÂìÕ/�!M�±SÊ.)Éa©%Y.Ig•åil^Ì-7Ømi•®9¨.ûJ7W.Xèý»,Ðû˜l�fæY½¶óÆ=aªëBøÂ^1
-ùø3
wþ}ÇŸ8€žb™ ßÝ}ß�4cê»îe¨õÓ§‹D[ok½I(—¼GÌÅóˆÙŒÞÑ­˜%o2$]o2lJz1·�ü%6’†ò¡ÌI2#”ä@8mø‰~ÆçÖ�°†9å@RYÂ%&aʶgêy:a�‹
-Â%Ÿ¿U©ú
7›Û8rH¦Y¬ûzù?:Gü�äË-L½ªà¥þc¶kŽŠ‰mJ
‰œ€*GÙ²×ÄM
u?ÃÒi·¯ Š˜™êÈp½­¡ªÝÎbµo.Ã_èŽtPs€‚u‰3¥]N
-xÿÇ\‡°‰	Mÿê�)G‘¬Øoæ˜SoÜ¥Û¯z)d|>¦{=_óóÙ÷ý/_È‚Feÿã혲Až0‚R®×)™³—*ùCŠ×XdmrCñ¿aô±��öOæa[bõÄ8æ(µÏ1«eö†Z	cÌ^�„&Ãã‡ëÛÛ‹÷4®R¨O³ú‰ž¨·PÖ•O¥p—2«3L…ç&Àéã¬a@‡ñ$¸FJ=—U:úYwÁX27äÛÏ*A˜Ð�‡ÒHš	uO˜ãN”%zF‚#^”Mš&À¹Óç¬Å/Îô°sʆúÈ)›žŒzá×ݪW0ï°NzAy¶ûyž-hlm¡&L÷Š²˜%ûz]Â~	¢?MS9ŒŒÝ~_‹òP˜ŠMzó½Ъp‚ÍíRc)<	‡N\Ρ„2rC"
-zÌ3º1ê
¶ô£¶GñbÇ@¬]~�¸ž2r_¦
-«P5Ú�ñ¸v¢Øg<~±râ8vé¼IÉlq[VépëVwðàêTÕT°Îþ{å±
•¿_üÓ¥
-
-r5H6onª´Z«Ò¿8{·lÈiH_z=w—÷¡|£Fz2	`Rê—k-Pj$	Úf "FˆB¤¦Ù¶%ŽO6œh<–B@’d±nÖVpÑÖE´59í‚“á`ô´ä¼4]$›ô
é›Ô;€™"Y¹þ›E¦º\”ù+eëÍ›AŠÕ´èÞ%{UØŨ­õj8MÒkÝõWÒ©-ù'òÃaΛ>féáÇ’oâ ,¯{Ô•Ql+9ÐÔg¨U«êK7IâMR/Ö³Ež�$M2o~°,´¸7÷¹
œÿãíX >�îÕæTYü8³bvÙÈŒ\éŸÒê¾ÜÝåó‚QOiº°6ßÇtl;»
-0t¤²ŸÅRÈ�ÊCº{ØÌŠ¼H5 h¾¡â9�j>Q+úD�xšXžyZ÷¹C6«Û¯‘Øo¨͘~l@ÝŽ'.!¹�í]›Ûu×
+xÚÅY_sã¸
ϧð[�™µJ‘")Í>ew“m®wÙk’{èäv2²ÍØšµ%Ÿ$ÇM;÷ݤþØò:¹›NÇ")@à@G~á(–
I4ÒIHÊÑl}ÆFx÷ù,t4O4éR}¸?ûë•Ð£$HW£û§¯8`qŽîçã�»øùþòö|Â%«à|"¸¾ùD+	=>~¹¹ºþüË폎Æ÷×_nhùöòêòöòæãåù$Œeû¹ãpdÃÕõ�—4ú|{ñÓO·ç_ï8»¼otéê2�Šüvöð•�æ ög,I,G;˜° L>ZŸER2¯¬ÎîÎþÑ0ì¼µ[‡ì'EȘë
r1d@™JÀ+4àýÒ @vHÃ$9çÀiê2Í«'Sž‡ñxRÛræ÷tÙk‘'±Û“æóa¾"Õq¾“g5À:k*íYÏVé¶2\D$ÇÕÆ̲§œ¨q
ÊØÕ럟#ZB9ü’r[à$<rfÉ|nç¦r<ë‚^L78Í*3š„	‚¯†a�HÉ­@OEy>,ÿ»È
Žd«š]ßeõÒ­/
-щë¢v*S>9¸Û;X€wN$P¯ÎžÍêå<Ã1¸g¤ÅøŠ” q#}q¥Ï7:ä[äÀëðfx‡’±zÓ•Oš]={ÌP,Î�
ái/éWƸ™(ßeël•–N-�‹�ìˆô´_û;ƒ•®Z–cW-Ü{D-.#�‹Ë7{œí�ñ
+}®Ht=^$*ù‹€ÐL8Ä­³�ÖÜÔi¶ªÞ”TÆЀ¼sSÍÊlSgENÅÓP,	@™·©–ÑÉ •Zü� å¡ð¬³|#Ƥk.­TŒ(E/Ëň·Xkè'Ý
‡°vÈϿøñöC`U DR
+ØÞé
+xGÑ
¬,ÀV§íQ¦˜`ï1¼Õ2à Æk/Y¨{‹GÖ&À‹ˆØ¼LŒì¡TÈPÈua�ºhq÷£žrªºÊ!0A]
þ¦ù6“¡î
.ðT…â	♉�¿&ž8€žb™~Ûšòûá”0¦¾NÀPFI2Àð¨vZ4¹µ‰&¡YMB%®:ÐÌçsÍ(šðÝŠÝÒ‰&KÒ�&˦ SGЩ_b+¹ª_„²šdV2¡]
+¡½‰”+)ºœðþ�½H›	4=ç¬ê2ËD–o×S¬©¿7îÒ¿·lYŸáÃ!ÝÛùÚÇC_¿’íÉNôûû!cƒ<¬�8̲Fæ¯5ò'ƒ×˜gmqCù¿`öð�Æú'jŽ¨m±zbr„’cUËÜ
µÆX½Z	m†é§›»»Ë�4®Ìl[fõÍlpE]aWÃÂeVyfX
+Om5€Ë‡U%Â@ÅÐ)GPã$úTUéé'Ý
CÅÜ>ß~U	ÂDA¼/�d`™(é	sد;¢ð¢jëâñ…·ç¤Å/Î’ý>Ìú#olšYóÂÓßšW°ñnirzAu6Ûé*›Ñ¼¡Û¨Á ¥G^ä“t[/8/Eô§ej‡‘±?ï[^ìrÛ±Éñtë„
´Ê½`S·ÕzŠOÂÇ6ˆ)²Š)´PVn(@ZRo»XÒ¸Ò;h½m"ÚÏ0óÒ$ÃäJ+ñ0Í^´&ÙëíaT³s|6)É�ìó'mó*[ä¾’ÙC§/¹Më×øpFÇù2­hejð–piVäxgª¹ÛèèRšÖåy<¶áLsdè²—ÐÎ’®wÕÄ+­ûì€à‰ü†e:÷òœ‡c)?§«lÞÙœ;¢
YóÙäCZ·×íí½ï…]UQ¬0oÞÕ€6›ÚÁc0vg·m³GÈÕª!vvZ§4ÊMµ�΋5øTÕ´Ü´×'î&˜d‹\í
Ú”²Û…=
*‡á0ú•IF0
“YQúR©Èç6§à2úI„!MWÝŽ	õ
+±c N|}í\”¸Ï
€·;ɶJð4ÿ‚ãiH¤Ú2_QËëÖ@ðÜ-SGÙñ|J‰
+£Æ:0¶ŽŽÆãW'Žc_ÎÛ’Ì5·Eeö�nmߧª¦ƒõþßk�-¨üýòŸ¾TPP+¨¤o—ÛÛÊÔûÞßšô/Þß�[rî2ïߣ�ºåtÒ£E
+TÄQˆÔ´ºÞ®êl³24sé$Aõ°íÀ¼
’¤³e³·‚‹v!’8—K|r²¬]€–‚—–ótmÞ‘­ñ£�æ{ý`¦H¶o‰¤G¦º˜+·”®˜Ê–k;�ŠqŸ$`ð!…Ü«"šÐm\Tƒ6ƒðÊÜÛIxΥŠl�@ø»M:3^ž:�úanv«Ì†‹àÊ÷¢û©p––e†•_/ëmé�¬õWD»E^4¹¢Í·Gº‘þe±GÔæ�Ú®Ó—ý¦c•9ÜnüqµãÕq˜Y-ƒ#ÅòAG"\±üœ™ÝŸëDˆƒr¼Ñq¬‰…b%÷Üæ
÷ªúÚíXöÒØ:­gËÉl•�$MgcØ£t>ZŠÇ•EW\ÿýýЕ¨}Á÷­…ÿ³®P%&°
+J³	áÒ¿˜ê±(óât·dÍSØOÒ®ùÁÞgHv·
aþ±
…ý=“A¿¾]ŠNyÀÿ°Mâ<ñ}¶=þ�ã
+Ê
+$_p E›ã<ÔÀ�4Â5@Á�cŒÀÛzÈÁ—é3±A€+<ˆÂÉùP¹O^Á±?~Á¯ñßÚ�¶�5>ý§ÿnÿ1�t â˜7�‚© æPô9¡lô$-«ÿ÷øPôÿLÎ8Èendstream
 endobj
-1331 0 obj <<
+1395 0 obj <<
 /Type /Page
-/Contents 1332 0 R
-/Resources 1330 0 R
+/Contents 1396 0 R
+/Resources 1394 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1339 0 R
-/Annots [ 1334 0 R 1337 0 R ]
+/Parent 1388 0 R
+/Annots [ 1398 0 R 1401 0 R ]
 >> endobj
-1334 0 obj <<
+1398 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [399.2874 660.1853 467.9594 672.2449]
+/Rect [399.2874 719.9611 467.9594 732.0207]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1337 0 obj <<
+1401 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [461.1985 408.6709 510.2452 420.7306]
+/Rect [461.1985 450.514 510.2452 462.5737]
 /Subtype /Link
 /A << /S /GoTo /D (DNSSEC) >>
 >> endobj
-1333 0 obj <<
-/D [1331 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-434 0 obj <<
-/D [1331 0 R /XYZ 85.0394 562.3583 null]
->> endobj
-1335 0 obj <<
-/D [1331 0 R /XYZ 85.0394 535.0538 null]
+1397 0 obj <<
+/D [1395 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 438 0 obj <<
-/D [1331 0 R /XYZ 85.0394 457.3433 null]
+/D [1395 0 R /XYZ 85.0394 615.421 null]
 >> endobj
-1336 0 obj <<
-/D [1331 0 R /XYZ 85.0394 427.2294 null]
+1399 0 obj <<
+/D [1395 0 R /XYZ 85.0394 585.8633 null]
 >> endobj
 442 0 obj <<
-/D [1331 0 R /XYZ 85.0394 274.9785 null]
+/D [1395 0 R /XYZ 85.0394 502.9736 null]
 >> endobj
-1308 0 obj <<
-/D [1331 0 R /XYZ 85.0394 250.6389 null]
+1400 0 obj <<
+/D [1395 0 R /XYZ 85.0394 470.6064 null]
 >> endobj
 446 0 obj <<
-/D [1331 0 R /XYZ 85.0394 122.1428 null]
+/D [1395 0 R /XYZ 85.0394 298.1533 null]
 >> endobj
-1338 0 obj <<
-/D [1331 0 R /XYZ 85.0394 92.0289 null]
+1371 0 obj <<
+/D [1395 0 R /XYZ 85.0394 271.5604 null]
 >> endobj
-1330 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R >>
+450 0 obj <<
+/D [1395 0 R /XYZ 85.0394 137.8852 null]
+>> endobj
+1402 0 obj <<
+/D [1395 0 R /XYZ 85.0394 105.518 null]
+>> endobj
+1394 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F41 925 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1342 0 obj <<
-/Length 2718      
+1405 0 obj <<
+/Length 2683      
 /Filter /FlateDecode
 >>
 stream
-xÚ­ZÝsÛ¸÷_¡ÉK陈!
-“X)?²>ûåìïÃÁ¬ûtÒ~"
-¥Jå„
¥š2`bÂTÁp•Êê©ÕÖôÜ�ë`_½Ù¯Ûr»¶ôÖØÝÁîšõ†Íç2
-SkÇé2/V8»ŠÁ®2ÉJû‰
E“I(c¡yQÓæ­Ýت=Ÿ+!ƒ…ý-Šde|AN£Ž“£ê%M´+K?\ÿB#U¾±Í6/x¼]åÌòS¹^Ó’;žk¬­ˆº»íÓìïÛŽw*Ö%Hf˜Ç&	.œ5€«¦
-©b¶1²ÀÏ�
-‰75™Gà|"%ÁÁèdÌñ	Õ~"²°Ëò"i‚YŸŽæRg@ð»0–JŽ}5Ç´#Á¯²˜G”Jƒ«ª›+Éñ�’²	ÀçŠ�œª
e‚c>SªBúÍ4T"'ZO…±Šä­'LÇIò5ÖÓø‰ìQî]7¬\›´[Í•
d£{�¬øÑÞOíª¦Iìá÷iU‚7Ã9ÄÁÖ™¨>”tˆT(
-Õå-åù-Ig¤îX˜�'𒩃œ{íFIÖßÙb¿kʃ�×Õú~
-½�‚µÏ(àn2K½}d&ÀyÕI%’Ì¢À±rc0Þb8ôÇŽ�?\’�7ÌÑû‚cåñ榨ôê
¶u~âŽÎ{`\%Á­K¡*	j·çÂîøuIÏ.'�]ƒ†Ù'êÐ8Œ³ì¸mˆoÉϦüP¹ƒCmiè7)3¤bW×Á@W÷
=0
°	€º³Ã%M½> ÜfU¯Œc\ÔUk?·�ªÎZPÐ…*ŠŽüƒ¾�r…Üuch
fV]äܩ̼ÉÀ¶ä'WÔ
Ì!™èTˆqSðïÚÕíP3ue<*)0B»rJFh´‰0I8%žQ¤iü°q@¶lgØŒÁ‘×¹-‹bfyç:›ˆ¢8Ž÷X�b¯r¤:¬Fñ#ð…¡l‹³'Ä•¡À�
ž%ô¯îi6PŸB ø%1Zt”B0Hˆà?`X¤"J÷©o€h ë¡©Š)áà„#};‡£(eƒéZˆt
-«®,p\kÏÕ‚iM”Ä^.–'9f$”	œ•XiÄã0òÏó’:„[ŒõI�“Èô�RÃã½Êœ°qÂ	‡èñÚ’Ÿ¼RÄÃé«ëñ2˜Øoì‚ù^×-ïî“\Ê݉۬šûϽЛ½«`P
-(Fòc§èòšâÇX„$‡ò¦ìχB
-ãĈ¯i ú}¦€Hcó6ŒX?Ú¡Jo{\³ ËQ]ÛÞoÑÛŸ(r™/rAY,—Ñû†ûŽã¾úf¨­þ?=ÿ:q7Z«0Òñ‘ÚìR@Þ3_ì?£÷ÿ:c©ºËä¨Ñ}ñ‚–Ü:çCªYÕûõ‚hîÙ�Ä¿£8Âó¦·Ê¶ŸêÝÇ>u<¼[é	Å=Dº/ôKøóe—{ ‚p8’îýŽ¯žðe×_¤8yíîPü‚>úPÈ‘˜6'¥e¾òpݽmN—)ç�jE˃ý� Ìœx+žb†^÷à€w¸c¡ün�ö×û…«ëÝ~ô÷
+xÚ­ZYsÛÈ~ׯ`ù%P•	Ï…+~’½²W[±ÖÑ*IUv÷
‡Ê$À%@ÉJjÿ{º§{pP EÇ*—=zúøúˆr&àŸœEqg*›%™	#!£Y±>³O°öþDòž¹ß4îzs}òê�NfY˜Å*ž]/¼ÒP¤©œ]/~
âP…§ÀAo¾|wñþWg§‰	®/~¾<�«Hï.þvNÔû«³ήNç2�dðödz�×çW´3�7—?ÐLF�L¯Îß�_�_¾=?ýýú§“óëN—¡¾RhTä�“_³¨ýÓ‰u–F³{ˆPf™š­OL¤ÃÈhígV'¿œü½c8Xu¯NÚOŠPéXMPé)FYkXBžçÅ-j
{å`¯2p^„G঻ÒÞó¦!C…ÊÈ”75mÞÚµ­ÚÓ¹–*XØß„P•mp(ƒœf'GÕKZho-MüpùÍTùÚ6›¼àùö6g–÷åjE[nx­±¶"êæatN³»il;>©X• ]¾6Yœ¡B3 Á1€OÊ0‹"åT¡�àë4	Öy[Ü¢8Èñ‘‚§2@EpP.i­lySSﶧ2
P
_|ä—7o›†Þ±F;8›‘¢$”J¶1²À×÷`§Áµ°SΓ„qÄÀSa–¦é4ìæÇù�¥ÃÔH>
XR&îF)�^�dL³0Ñ2~F=ǧdÌT˜(aÆB®Ê¦�ÂtÂŽˆí]/{ç8ñû—f"`ÀI,|,8ÌaJ…Q”¥Sk&$Ð::ö«|×8´§A^-ˆpPCba›¶¬ò¶¬+š@¬¹­C¬áD‡5ÀšFÝɱ…BÅÉ,јUfÏ€5æ8²œÂ$~ÅýÉ_
[Š‰P=£�žãSBf24ÙXÄCPKB‘dr
+jwæÂny¸¤gW“F„^?…Õ'úPš$ÙoCâ[ò³)?UÎaàÔ–¦~S*Aʸ¾&º¾è�±h‚M
+%ÞhàYÁýáÍ�ÁêK$¿È EG%“„þ†EJP¹�ýõˆn=´T1%œpf
e«Ü¬x¥l°üÂb
·
+ž«ï\[à¸Öž«OÓšh…w9£Ž
+L!µ	\u*±Ó0>�Ð×±žFPÔ!Ýb®�‚œD¦
Ü”žïUæâ€'\pˆï-ùéÁ«¤._\Ž·ÁÂnmÌ÷²nùt_äb¾�¸Ãª¹ý®z½sJ
ÍH>œd!ïpŽEHr*oÊÞ?”ØŽ¸¸ô¹›t@.9E½Þ”+»˜{öðåÚÉìíÌá§?ÛYúóÞü°¦�¸kð±8"3“Mõ‹À—Dõ	&ÀjèÚO4B’‹œ"«©¡Vþ'qÈy®ÿЇ/Qe’}·‰§úÅ][Ãî²
+*±ðÜäÛ–(ú®‡(v†O‡ÈLú
+õ’¾ÓR±Le ™(È@ÙQµCdÙÄ÷räÍm/P¾äâ�uð@ÌS
+dQ1ûÚ¦¢l'ï¦.øY–|O
à@Df—Øßm—¢&ì5®ú	
 endobj
-1341 0 obj <<
+1404 0 obj <<
 /Type /Page
-/Contents 1342 0 R
-/Resources 1340 0 R
+/Contents 1405 0 R
+/Resources 1403 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1339 0 R
+/Parent 1388 0 R
 >> endobj
-1343 0 obj <<
-/D [1341 0 R /XYZ 56.6929 794.5015 null]
+1406 0 obj <<
+/D [1404 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1340 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R >>
+1403 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F41 925 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1346 0 obj <<
-/Length 1045      
+1409 0 obj <<
+/Length 1124      
 /Filter /FlateDecode
 >>
 stream
-xÚÍXÛrÛ6}×WðÑêP€o“'Ç•]g§UÔ'U£�IHFÍ[
-Âñ>¬E
-’T²iže“œw‰™¥\nìùC9C9Áè
+xÚÍXÛnã6}÷Wè1)@®¨»�§lê¤Yt³­×}rƒ‘(‡�nKÒqœzÿ½”(Ù’/Éq�…aHâåðÌpf8C¤éò‡4φºé[šë[ÐÖ‘­É@×f²ïf€ª1 š£>Ž®MWó¡ïŽ6ŽXÔ=iãprvõÛåãáè¶~æÀs`;úÙÇÛ»_U‹¯W_î®ooþ]ž»ÖÙøöË�j
¯‡£áÝÕð ÏFr¾Q!˜p}ûûP½ÝŒ.?¾�ß�?
†ãµ,My‘n‚|Lîu-”bèÐô=[[È"ß7´d`Ù&´-Ó¬[âÁ×ÁŸkÀFo9uŸþlÓƒ¶g¸{h 
!èÛ¶ÑÒ íCÇ4ÌRƒ…І-5 ëúÙk–%àW�IH**yNÌ
+y?\[¨±-ºLº®«6D!8Ö4ÅIõ9	bÌù½úø·
+äYLƒ¶bUÏTõLÙ<®7BxßG<i&hÔ†§ù´à]aæëöâ£Z¡Z`rÄI³f×YÅÁ#	ž@aÈ\5ü­Ûú³ta¯è,Í‘m¨µÒ�ÄWˆÉËIá4ÌBÕ¶$|š±išu�¦‚ÌË-€Î4BŠãyÞ|Ÿf¹ µu@ˆhmO\0šÎ~4±%�ŠÅteLšüF³‚¼ˆË^ý'›³Ç]¹m./ š8}­’oSž“ ƒ4R„Åz#²4^®"ʸè%E…Co9Ùÿè7­åéKÄÀæÇmi9;bYBɈIÒ ö¿7l{—„HrÐǶ¶öSz†üƒ-y:9Ú¶Œ$Îf
ÓHçÉC}"t´¯ú
4”&ŸÍÅû‘Mz!µ$k†ò-½¬Ôƒ¼äòÈ ¢Õ¨ÜæÝ™´Z
+„$ÆÕ$N‚,
y_‘
žáþÑ2Ÿ?<‘定½÷4·Š—$ ›@s«á®«
+YÕOü©ÊVzO�×þÜàç¬.÷]™6,îvö\êèë{›w_!mî×,™/xž±¹2÷8¦î@ÏðÝšT¡Pm3_ß5íRÿŽ@íendstream
 endobj
-1345 0 obj <<
+1408 0 obj <<
 /Type /Page
-/Contents 1346 0 R
-/Resources 1344 0 R
+/Contents 1409 0 R
+/Resources 1407 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1339 0 R
+/Parent 1388 0 R
 >> endobj
-1347 0 obj <<
-/D [1345 0 R /XYZ 85.0394 794.5015 null]
+1410 0 obj <<
+/D [1408 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-450 0 obj <<
-/D [1345 0 R /XYZ 85.0394 769.5949 null]
+454 0 obj <<
+/D [1408 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1233 0 obj <<
-/D [1345 0 R /XYZ 85.0394 748.6299 null]
+1292 0 obj <<
+/D [1408 0 R /XYZ 85.0394 748.6299 null]
 >> endobj
-1344 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F39 863 0 R /F23 682 0 R >>
+1407 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F41 925 0 R /F23 726 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1350 0 obj <<
-/Length 1052      
+1413 0 obj <<
+/Length 1090      
 /Filter /FlateDecode
 >>
 stream
-xÚíXË’â6Ýó^Bª¤ÖÃ/Õ¬z:t‡©“²"åA«ÆØŒ$ÒM‡ù÷ÈØæ
‹<Š¢,YÖѹGWÒ½Â2?l9.ta–Çlè ìXýqY#ÓöTÁÙ7`ù(~õ±]¹{¤žÅ s‰kµ‡,"ßÇV{Щº�ÀšA@Õ‡/ÍÇÆÓï­ûšgWÛ�/Í ª>6~®§¥§ÖýçÏ÷­À¾ƒ«?ÝÿÒ®·Ò&7ÃøØhþ˜¾aéch«þXoÕ›õZ·ý©Roç¶íň&†|«tºÈ³?U¤Ìw¬WSA3F¬qÅv(tlJ—oÂÊo•_sÀBë¢k©~AB]R& +è#è"å9º”Ð…€�pªŽióâm(Ás xú~ÆU/–½(N«ÒG7±Û0†ÌqÈ:’Ò\ª´Ò™ÄR§E1é%•nZû+}ü�´Ö­
-•u˜çý‚Á@Àë|å³´d
-ݯÑî@³¶ïGYò–ÊÆ# Ä{&I4?s¹O¼‰¢e©!—@BDt,ÙOõåHZŒO¡„÷�K)ŠµÎJ}.óþ6	E_¬;Gê5 ŽÂÙÑCM¦Ï¹³Yî*+-E4:Z“\OeŸ¯ü\Lì‚'ÏØc�Ï1Hг©³
-©ÍXé쬱<ìò«õs‹ÕÉ0$>ñJå|�#”´9E_�{¬ów²±	$J®^›ûÙgÍå &ZÎN‚ÀÛ<N…Xg1
µ
-%±j>RéC8¸'O¨²éeØäg9Þ	)п)™;7
Ã×Jžnœ‡�kå!W˜7óüÍC®Îu=!WÎC®�6mä!ø&yÈÿ�ó?<p.»N¥Lî@K.?Í?ïâ«ÖÕ=´mòSß'ù-*¡…[TâùÐö
HF*±ÓC[Ì—w²ÛÔÿgCúwendstream
+xÚÝX[sâ6~çWø:#Å’ï³OÙ”¤Ùé²-¥O”a[NÔõm%±	Yúß+_
+ãýíèç²Ç+{@ÇÃëáx8ºf“½ád£K]_¤¹"_zÓ™®Jí=žki�êE‡Èó°÷LË€–i램÷Gï÷
`m´m´Ò!6lÜ`@ÕèêÐÖ”cyÐ6°Qp:
+ÊÁV‡4‰–«�q!;iQáP^yø[ù¨FY6'AÀ«¾,årÓŸ¿Ìv¦�®ç+ÿ´˜ž=…ÜqšKé�§1XRN©K*æ)Ÿ'i[2Î@—ØúΟ,‘ê¾Ógâc”Š#ÿ¶õûŽØ<b¢Xuñàô3]–-Õ˜mÀwÃhªÜÁµyŒæˆÒûZ�'‹øŽòN™"9I„r/`�J^–´B‡�Ò…<Ÿ’dqJG€:PÚQ.I%—�1WÅ
}Ê"æ³Ýà(£äKGkÒåT  ©„õÓ$]d
+DJZe뎮Ùân­u3íkwLå�C„ZŸ}ºM4–™µTZÈñ �K!AÇ4¬è§bÈ‚žãØZ­›PÇVÒ’_^’@C	µá	¾ÚuªöKªž±Úé+ªæªæiT±n¨jÃñ=F"	:™µ†öfź1²¬F³6p=jZŒDŽn¿]ì@dº¸‘îBP°×¼]²ªJÊVAo;Ðp°¹O]ë¼ wh˜žwhéhòÛüy‹ìôÄ.v‰>§	B©öcæ‹S«�€HÒ¥:ÚÝ^T=ÂiÈ©x(v—“÷¨S@ÐK&’/ÏåqÄ"’”{Þ©y¦<I±s
)£ã0
+1WÇPÿ¡Vµ·)¬k˜`}p~ØW9ì£×=ì¿Rìý0wÿÝSûÿø�ÚíxÙt±gX0¿�k¸†SÿjÒ³/ý¶7¢¦ª¿\oîó°Q»ÏÃŽMW�T¤reü‚ùúvð%õ
õ~�Lendstream
 endobj
-1349 0 obj <<
+1412 0 obj <<
 /Type /Page
-/Contents 1350 0 R
-/Resources 1348 0 R
+/Contents 1413 0 R
+/Resources 1411 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1339 0 R
+/Parent 1388 0 R
 >> endobj
-1351 0 obj <<
-/D [1349 0 R /XYZ 56.6929 794.5015 null]
+1414 0 obj <<
+/D [1412 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1348 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R >>
+1411 0 obj <<
+/Font << /F37 791 0 R /F41 925 0 R /F23 726 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1354 0 obj <<
-/Length 1867      
+1417 0 obj <<
+/Length 2117      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥XK“Û6¾ûWè(ÏÄ_zMN›t7ÝN³i7Î¥ÉN†¶¨µZYr-z÷ñߤÖv´}e|‚
-»‘_'îhT¶¿›P"Š<‰ö0 „�Ö™’H!§™¼›ü8(<šuKÇâ—ˆœ$9ÏÆXŒ0)H*¸p
üó…Ý(šqA
-F¥ãþÖµz:K)uÔ§V­ýðòQ}‡ƒßÝR\'¢c¤HÌ‹9lüŠªÛîն̠wRNDpð‘&´k›ÃU½í
Œò_àçîŸõèmüCŸñSo>©²ÜzÞ¦Ûš�ow'f!Ážûü9nž›/u£ï•©»vf7€Ìƒî?uÛOm7²‹ÙYèøhFÄ×f„ŸeäÌÏÿèËó+΢�]Y×
-ªŠçE¬pìu9zÙmHu
-™ ¢TÆ/€êDb˜ó`±:€µ¯›©…«tµh|ÖM‡ßÍvÊò¸{¨K?¡vfÕmk€_ýXm¿w]ÁÐ jCÎc£ô±M¾>_¬Hápã,
J°ÿ¢—<�
žBeö$ d²,�d^�òë"Ø7êA�A€‘L0�€›–ÌË:2ä*�ë9
-?.üzÓÔK…ó�a~À‰W}Urî0öeÉsZ�ÌnˆáµñVd$ãÁÛ¦î�wx£—õÌ74™™æò@¶i‡„,ö\Þ"cÝánptýκSòû~XYùas †ÅâÌJ™@y#!˜À[BëC·QK8x§ñnä—Õ8™†zIƒ•!ÄBÐø��žð1	èþ¶-UªE¶júnìpƒ:œ	­=qz$­Q÷«[KæC¦ßÚêÁ	ÈPüò€¼RWjטg˜}³…’¬†*„]8À”£¥_a¡¯ÁÝŒÅx~óŒÇ‰@Ž;Wà‹¡
-ñ^rB3žÞ?ÿû
ä�.“zñýJûóåKÍ‚�b)�hãŒÀ;1„ÃÈ�ÀË+;MÝÏ;$èN˜ ì·wß!ÑL¡p�¿�ÀØÕßñ2  ,tˆ}䮌ÞtAYp‡³Çá†ý
ªyý¾Wˆ)b
+xÚµYÝsÛ6÷_¡Gú&DðÉ�ñ““Ú9w.nÏQ_êf<”Y¼£HAYQ¯ýß»ÀmÓ‰OÇX.‹Åîo™M(ü±I¦¹œ¤¹$Š25™¯�èäæ>1/¡x(õnzôö\¤“œä	O&Óå@WFh–±Étq½ÿçéÏÓ³«ã˜+%ä8V	�Þ]\þ€œ‡÷?]ž_|øåêô8•Ñôâ§Kd_��Ÿ]�]¾?;ŽY¦¬ç^ÃÎ/þu†Ô‡«Ó�O¯Ž?O<:›ögž—Qaò¿£ëÏt²€cÿxD‰È35ÙÁ%,Ïùd}$• J
+8Õѧ£÷
+³né˜ÿ”ȈÊx:â@Éd4#¹ÌÓIªr’.œ¯�ã„Òh]|‰»¶¨ÍR·qW®u\Ö8So×3Ý"}‚Ãg{nØ<fŒäJñ¡¢Ívö_½¼ô)ÚtmYß>[}o£i¶í\#ó7ªh¹‘7ÅbáµþáT°4'‚§
+4‘T
+éýÃM)’§i2ðA	ÃÅ×›¦í�,77öãóˆ}3DÀ¢`'ûŠ�ñ]245yljžž
+frëÉýqUž+î«Šû#ÅBP’%Ð…Ž·ZnÈ,Ë&B&DÒ<s.ô¥]-â)ø‡�ubÓ•õ,8ÕèöΖK¯
+È*žåQ�ß¡ìXzÞlöH5Kê‚
+[ð‘‚ìD¢Ÿó`±:€µ+«
+©™«ŬòQï7í1Ë¢æ®\ø‰bÛ­š¶´WÕ]`Õf窂ý@;€(;ò1Š�ÛØdèÛ×Å˃å	¼- £
+©‡¦[ÞôÓŤà…oÍR4�.–^-ê²^ymöœvtñq©¿x3šxp.�ç°Ä½º&”ð7“�šy‘\2]¿°	
+ܦ@õ†ØÅ°�Æc7Áªj©ÒŒº‘i#Î^’‚ro[Õ@¦xÎ!9ì—·
¨Þ P`,pèýÚ+„×]ÛÙúœ$Г…UË°jľ žS†÷B¯kÞ¬¡Ê,œíœA2–õ<v86Kç<»â£Ù=T-m-ÚnP{àêª\—£´†Zéoy{ýÈ<ªAqFæ΂IW9A`jwå¢[Y�3]6A"ÔðÐ1€p…•êÖK`V›qÏ(j¿¡"‰4êÚ Ë%/pVÛÚgÙ"Ì,½ìªÙ°Íàè0ÅjJm\ûbg,´%Ö¾j:œÖLãu |sûC
2
+üîvM\
d+äBùwÕÍN™ùJ¯½´o¦xßø
+w_LÉs‘þ2¶b½©ô›Cw	åºo=€
+¯ªü^‹Ò—¿®�M>âòwü™1ìß_÷&�<ó¿0f”€Qc?ÓÓIðЫÿ)pø�	4ÙÐÿñþr¿K§	ÉxžÂû›X]62©xäŒðß/50ý/—$Šendstream
 endobj
-1353 0 obj <<
+1416 0 obj <<
 /Type /Page
-/Contents 1354 0 R
-/Resources 1352 0 R
+/Contents 1417 0 R
+/Resources 1415 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1339 0 R
+/Parent 1423 0 R
 >> endobj
-1355 0 obj <<
-/D [1353 0 R /XYZ 85.0394 794.5015 null]
+1418 0 obj <<
+/D [1416 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-454 0 obj <<
-/D [1353 0 R /XYZ 85.0394 589.0297 null]
+458 0 obj <<
+/D [1416 0 R /XYZ 85.0394 421.6574 null]
 >> endobj
-1356 0 obj <<
-/D [1353 0 R /XYZ 85.0394 558.9158 null]
+1419 0 obj <<
+/D [1416 0 R /XYZ 85.0394 391.5435 null]
 >> endobj
-458 0 obj <<
-/D [1353 0 R /XYZ 85.0394 558.9158 null]
+462 0 obj <<
+/D [1416 0 R /XYZ 85.0394 391.5435 null]
 >> endobj
-1357 0 obj <<
-/D [1353 0 R /XYZ 85.0394 534.5045 null]
+1420 0 obj <<
+/D [1416 0 R /XYZ 85.0394 367.1321 null]
 >> endobj
-1358 0 obj <<
-/D [1353 0 R /XYZ 85.0394 534.5045 null]
+1421 0 obj <<
+/D [1416 0 R /XYZ 85.0394 367.1321 null]
 >> endobj
-1359 0 obj <<
-/D [1353 0 R /XYZ 85.0394 522.5493 null]
+1422 0 obj <<
+/D [1416 0 R /XYZ 85.0394 355.1769 null]
 >> endobj
-1352 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F21 658 0 R /F23 682 0 R >>
+1415 0 obj <<
+/Font << /F37 791 0 R /F41 925 0 R /F21 702 0 R /F23 726 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1362 0 obj <<
-/Length 3416      
-/Filter /FlateDecode
->>
-stream
-xÚ¥ÙnãFòÝ_¡·Ð€ÕÓ/ì“3ñLìx²/v�$´DYL$R){”¯ßºš¢$:“ìÀ0ºX}UWU×Õ2
f'*Ém>Is¯bmâÉl}¡'OÐ÷þÂȘi4ŽúöáâÍ;—Nr•'6™<,keJg™™<ÌŠeÕ%¬ £·ïÞݾÿ÷ýõe꣇Û�w—SëèÝí?ozýáÃõýåÔd±‰Þ~ýãÃÍ=w%²Æ··wß1&çæ•EïoÞÝÜßܽ½¹üåᇋ›‡þ,Ãóíð ¿_üô‹žÌáØ?\håò,ž¼À‡V&Ïíd}ác§bï\À¬.>]ü«_pÐKSÇøçm¦â$Èf¹Š�÷¯ïË{hØW@›8¥
0úxßifT’¤(íUž
Ô%ÅX­rXh’ƹJœu$•¶Û="kÞ¼Äap’©Ô[Ü]/]Êc
J¢?šºd\ÕJ_µ®VÅ–»»†‘…ô­Šçò0ñ
-Á<*?ÏÊMÇ#ºe!PÕñÀí¥É¢r³ªfEWÊM½Ú#­@ÕԕDZ%òº%¬îlÝ}Â6“ɳ†ÚyË�Í‚;þ\mWnÅÇAlU¶˜Ïè×/ë®âµóP}}>žÒ†C�|m¢"LµZGuÓ	–¿Û®¨ç<bΛbÛqÒ�¢ßÝ}úG�Ú3n°z¿è¢,ºÝßnÊYõ³ÖvvL+ßPÜÞ'^²j½Y•k8ÑUM­ÆNJ
-øPÕUý$3Ï×aÑ÷ÙîÇx
ÒFÎ’:Ú&—“°¡­‹uº¶Ï¨©4z>gúÛ–Ô
-Pp@º¿Ç—=ITf³T.0.6W³¦^ŒÜu0)Ø
-ú윋–•¬¿k‹'¡Px”©µ`<µOŽ9M*íàž¡¬Aaæ$D@²
¨Ë€Tŧݖ”ª»àâœ9ƒý¬}åÜ´»Í¦Ùví¨˜qï,aA	>cédq„ZÖ1€{)ö—Æ<l
-´ÞÊPÙ ÿ&r¼Éƒ,
×m‹º]”ÛVvZÖïk:&lÒ6›Cc44³ÕŽ˜ƒx¾q
-Á˜ŽÚ2–勆�Ì;@‹N3Â�
<i22>2Ø1Â+8MŠ2Ðl—´,bÖÕg¼‚v
œxIûÁ2âçE,q/:ÂWü]êÉ@tï+4ŽV^V£ê>P`§ñ¶ÊRÖö±6ªPØça#ö œ›že–Í3ÿ0áˆQ½£DhY´°˜FHýÔþp®xpçiÝ9Òi\T¬VÜ/.Î÷1ƒ²lÏÂŽ<¢:„Fè)Vm3&Uö,äéÄã-y³¡ïkÅþê^ÉgŠu¦XŸ�éϼ£Îzï {G
-$lœÎÝ÷	QF«ªž"ªØnŠž;^Ûˆ§Ð*ÉX`ü@Áß$ 'þ
[dÊm]¬x”°”–&¢€äLJvÿa³ã€æXÖt[ú‹|qc|@¬cê43ó™WYâ’É0ŸùÊÉk’hv2×$û‹öS^K¼\ê”Ï8‰I¼ˆM.žøÂ&“%Ä/àÇK±��È2MUªaTŸ{yŸG?[ëyŠ¤ˆD=ÂþB?Ž-ÞN/†¿éúB{¢ŸŒ¬Iš�8¼CýBy´)Ç"ÖÌ`&¬‰£Ç¢­àbO-ø­k9—žÔƇc‘•>?»u*=‚¤¨£¬ƒ7 ¨Âën¿)ÇÖO1äu2÷uþºL%ir[²Á¸:°§“³ ù8_âd{�‹˜Ý©DÄ©Ui§§^z”
-Ë
!2[&‘(Ç$¡r“HìNPÈ QoRVxZ!·�&Æ�z  Õ§Á6lF½ •Õû3q’,Cô3Ðÿ×Cža$ñ•ÑÉ!äI
8Õ¿EÉ„WÃ
ý>w_¨3ÃTû¤Ä"ðÝëÌÄ:ƒE‡ª«ˆwðÁ¥1
-e40Ä›¸„´}É“r>@ì8„Ç…
-Æ J}ô‚ªÑ4î?¬à&1Зî
-¬O¼Û šÛ˜KÚˆà’Ýpîð$9ñ(Œh¸E©Rhr¦öt�~ä¾ôTaöB+
-¯ùg¯ú6Í hsn‚¿W€Ø'=ü,⸀ ?90>Uij’þglXPP
·™œÉˆBhÜF´ð}¤drV¹oZ†Ù%#DµI8o—¿eÀ¢Y­š¾pš2ulnÈÝÒ5ÑäÎO»¬Â®|õГ³2úü:@f	)¯	õ
-p�#fݩ̧!ßAÓ9^*5©Êµ
�·TÐ,ÇBM�å!�4œhL=XZŸÛ“ò@Höà;|<Å$@÷ÞE÷ý³f+·¬;+tŠÕx.Zé[¿Š•&€ô v7så]œõb92€:Ü[–mÕ¼–	æ.Ô�Drøh^IK¯ÂöOìá½¾B¹&ô<4“·ù��¯·ßÈ’?rǯl–
-ϘÚ3Ê�VÖ�!>'ýlßEendstream
+1426 0 obj <<
+/Length 3415      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥ÙrÛFò]_Á·@Uâx.\µOŠ#;J­å¬¬­Ýª$	ŠHH€!@ÉÌ×o_‚$'ërÉÓè¹zº{úš‰†f'*Ém>Is¯bmâÉl}¡'OÐ÷þÂȘi4ŽúöáâÍ;—Nr•'6™<,keJg™™<ÌŠeÕ%¬ £·ïÞݾÿ÷ýõe꣇Û�w—SëèÝí?ozýáÃõýåÔd±‰Þ~ýãÃÍ=w%²Æ··wß1&çæ•EïoÞÝÜßܽ½¹üåᇋ›‡þ,Ãóíð ¿_üô‹žÌáØ?\håò,ž¼À‡V&Ïíd}ác§bï\À¬.>]ü«_pÐKSÇøçm¦â$Èf¹Š�÷¯ïË{hØW@›8¥
0úxßifT’¤(íUž
„âÍ@(Æj•ÃB“4ÎUâ¬#©´ÝîYóæ ƒ“L¥Þâö8èxéRPýÑÔ%ãªVúªuµ*¶ÜÝ5Œ,¤oU<—‡‰WæQùyVn:Ñ-�ªŽn/M•›U5+ºRöhêÕiª¦Æ¨<Ž-‘×-augóèLž5ÔÎ[îlÜYðçºh»rË(>b«°ÅüxF¿~Yw¯}˜‡úè“è“ðñ”6‚äkaªÕ:ª›N°üÝvE=çsîØÛŽû�ĈøîîÓ?zÔžqƒÕûEeÑí†øvSΪŸµ¶³cZù†’ØàÎð>ñð’Uëͪ\Ãù‹®jj5vRâ
+3'!’…@]¾0
+:%ŒaÿˆP¯øAç´l•aÊf[=Kh
SÊî¥ÙþÆ»v:.àúIÝ¿{kr“ñÇÀíÊ
+þ&
9ñØB SnëbÅ£„¥40°4$gR²û›4Dz¦ÛÒ_\øà‹ëà“
+Ï$`Àžü­Êmò¯@1òª/@Ì%8’ñ`J\~|¤ÓËì|:�8ù)�®�2/‘1¢ØÅzqû˜ô^q
+NÊØ>Zñ–¬úpóljüi•©WFögj}.Ézù‡ålYÔOG1%,!Ь‚#“û�óiœoÁ�Ü Éǧ
+5Æ�\i«óžo½�òʧùé™(.´ÞBökñÌ’>Ìï¬÷çn{Ñ‹lÛŽ=NîîDQi½±‰˜¼a‡,NŒ
+nr3
+VåÕ‡§áùçÄ„89dUyoCØMÛ(´\JAˆ�³�Ê:MÈTe‚žÓí‰QÅNc§
‹×‹mÑvÛKˆfý#ËŸ?
+²8ªüL¼7¼Ú˜Xrï?Ò
ð(.w©N‹‡«²„�|G_«ç˜¿¨ÔpLì‚_¤b«#‚°ñ‚ˆûœQÄí8(‰Œ?èE3ñ°�“Ž“Ø°éiûå°ex±¿ÎVÌÏáý‹ïò0'ÎããgùÿkR (P™
ê ò³Ê%¨ðšöªoÓ‚6ç&ø{ˆ}ÒÃÏ"Žò“ãS•¦&éaá?PP
·™œÉˆBhÜF´ð}¤drV¹oZ†Ù%#DµI8o—¿eÀ¢Y­š¾pš2ulnÈÝÒ5ÑäÎO»¬Â®|õГ³2úü:@f	)¯	õ
+p�#fݩ̧!ßAÓ9^*5©Êµ
�·TÐ,ÇBM�å!�4œhL=XZŸÛ“ò@Höà;|<Å$@÷ÞE÷ý³f+·¬;+tŠÕx.Zé[¿Š•&€ô v7så]œõb92€:Ü[–mÕ¼–	æ.Ô�Drøh^IK¯ÂöOìá½¾B¹&ô<4“·ù��¯·ßÈ’?rǯl–
+Ϙú3Ê�VÖ�!>'ýÿÞüendstream
 endobj
-1361 0 obj <<
+1425 0 obj <<
 /Type /Page
-/Contents 1362 0 R
-/Resources 1360 0 R
+/Contents 1426 0 R
+/Resources 1424 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1339 0 R
+/Parent 1423 0 R
 >> endobj
-1363 0 obj <<
-/D [1361 0 R /XYZ 56.6929 794.5015 null]
+1427 0 obj <<
+/D [1425 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-462 0 obj <<
-/D [1361 0 R /XYZ 56.6929 167.2075 null]
+466 0 obj <<
+/D [1425 0 R /XYZ 56.6929 167.2075 null]
 >> endobj
-1364 0 obj <<
-/D [1361 0 R /XYZ 56.6929 139.8789 null]
+1428 0 obj <<
+/D [1425 0 R /XYZ 56.6929 139.8789 null]
 >> endobj
-1360 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F21 658 0 R >>
+1424 0 obj <<
+/Font << /F37 791 0 R /F41 925 0 R /F23 726 0 R /F21 702 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1367 0 obj <<
-/Length 3031      
-/Filter /FlateDecode
->>
-stream
-xÚµ[Ksã6¾ûW¨ö²rU„àE8:OÖ©ÄÎzœÃn’%Ñc–%R!©qœ_¿
6$:oM¹Ñ|h
-R±bŸoWL'´ßK&—ÿ-Û²M›Á�¥Õ0·úlÒÂø°bŒè(â­5ë‡§>d›üWJy+*^òæ	KF.¼	äÒ=ßhp3UÐ�%ÕÝ'yœˆDŵ٥5èŒ0Öƒ­�ˆRq¼X‰„…Ž6äâ’ॴ³º;4yYÔ#*QB#`yœ0qyfêXЪ�‘g#ïPF¡t·+_V0üùãëP8“ŒH•ÌHw¨	ñ}¿1«�üOYv‘¶°ÍêM•·îÀŠòq½:!”KmGahÅ@t¤ˆ Áy14T0Ab¦cÏPl¬>/°pß3ÙágL÷‹&oNÆB0pÌH%T®õŒïjN‘QoFr–mMÌâ¶õP
¶u¨Ó8ý~̪	²
N1îPÒ}²EÐ
-ÑÐÿždsF¹–%@ðy®Át¡'¹fñ3�û};׳–&qØõ5§È¨·0ר†%O%3\ë¡\ëP§ajª´¨aiÑMÎUX|šï‘-’„S-|ù�lÊ#[ߊ�ð8&q²Ïò�ƒN”	ÏÒß:üŒÑã~ßÎ7‘DÑç;Ôœ"£Þ‚|‹=E4÷>ê<ßê4RÇìW²1Û E\‡¥;Ô„xŸo0±„ä¾ü÷äÛÉŠ!Û8Q$Ÿg˜ïæ Û,~Æäq¿a%5oÐ8ì{‡šSdÔ[˜m°éQ	„�0Ûz¨
-ЪC
§ÿ
-Î[/iµÍ‹ÏC=8¿Áf>¬ˆCMhÒ7žÓˆØ7ëÿÏ
iÎiÅÎÆ6)¨9FhÏè
-ƒü%Ã2¦7 Ð<uÍ–Ef¢"ˇ'«³À~Ô2Ý<åEVw/§¶ý%ßY½1þn2'*�H~ð8"2QÝÚþím›ü
-d�~Šåöîáæ㦲#pÔ–¬ËŽì³ºN?gÆkŸ) }‚ªÖ>¬ÃcÌÖÖøkÌ4ØÔXƒ¯[Ä.¯Û„’)éÞÖÖYõ%«¬€_iDmj_M‹A'‡*ߧx’3»
-b*è‰Á’[; €}HÑ™
U‡Ý±ÆRZ¼báæ'[±Ýâ8ÔuVã{^‚Ê`ÚÕ˜b¶]<ŠO1Í›£YXÙ@M*S%Ë+«^Y5XÚ§V½u6Ðå’-At¸
6]‘?ö˜E3ÞÍ€yêÂ&½IÛˆÁãNÛž�PBSvƒZlm
œêf²y潤̎¤a4šš”¤e‚3AÁòò˜wô[aï3•ÜÓŠÄ&Oë9fÆRFÉ~
-ÄòÕæGŸ²ÍóÊÌÎz¼K$VzF¸CMH÷3>0$&Nyâ0ÔH#vß ¬›Lݱn'žqX‰5–}M•oÛ‚“\ƒ%iáº%�–&ŠÅ¤-9
S¿MúV¶2ïeU“æVò¶ÜcYbȪ­B…‹?	—ƒX‹ñ€"^š	ºkß‚ûuiL¸nÖ‚CYÔ®þ·Xóˆú=>¡‰P(²æ¥¬žÛë…3Õ§‰
_Ò*w
-l6eÛS»¥Â¾Ê©ŒüŸ.Ïݼ2Ká�e51µâ˜PØŠuÚ>™…×-¬�£Ý¢?1&Vî„Hq¶�Ç4ßMmaUÔ¬NÏ«ÎA'%ºµ¯Þ¥_¦ŽÐöVBˆwÔö´Å” 
~ÒüÌÔþ�…á‰ÂœŸösšôû?F3žÃ‰S'<$ÓaFBý�œIÍ-LOêûúºWÖˆÄÒíôÆîP=óLJ:ìóÜÑ€�ŽÌ°r%L‹�¯&¨Â°§0›˜†=a3|ê¡ŒêP§q�=ívG¸³"	«k…å;Ô„þœ×‡•ò5xO~õíO¸Ébªó)6iNÕ”{¦†r!~Æèq¿o暤&{¡“°÷jF‘qoAÆÁ8�Rr†q}ÔyÆ9Ôi¤ò¢É>Wy3>ŠÂ´ˆá¤VÀ¡&4ð)§Ìu¼òUxOÊy†9Ç£<À9‘ÀÁH	ÏÖç:üŒÕã~ÿç$‰y’„ÝïP3ŠŒ{s.SÆg8×C8סNCUçëÝDÖ­½A—°èÅ;Ô„|ŸqŒH®µ¯Àû\‘ŽÌ^#¢´Ö�kóÁ÷-
^#XüŒÍã~ß¾žjJ8çaßw 95†}…Éf>$jŽl=T€lªÝ{f•9¯®ê2]5Ínà(ŒSajBŸnКæ«ð>t›0dH8E„\’ÂqBr¥=SƒñÍâgŒ÷ûøfîW•{ß¡æõ¤Ó“h&ÐG�§œCõ®­0><×Ï#ÎÅ ‹g4p¨	<Î%”$:èð>‹ê”%ÃOíà
-§/Å:쇚QdÜ[˜u°,DŒÏ±®‡
-°®C‰æÂuZ�¯å¹„˜‡« d‡ší±�k¢bˆæžìöž´ÍSÊ.™$t›Á*LÑ“ŽØ^bíÚ¢l¦JÚ¼ �ÔMYaÚÅu,i—Š†vÓa›ý¥]&Ǽszå±4Wc^S_1B™EÜψ÷ý9ºÌ‚8㾡|Î^_l†¤ð3oæ6£~'šaŸ«ejSü1	K,µ>ÀËSÞdõ!Ýd«m¶Ë÷¹}5YvRLzxk14˜„YÕõ3Ðe›M¾²·Vo/må®·ubƒNÕVÃ@~…©â6hêÚÔ¿)ÔÇu�ý~ÄïguOK‹s÷âðpHëvŒÛðùh¾ÀíÔ(ÃêØæu6•†y�cî±ÿ’¾¾žÝØhY£æI²KìuB5á4Il
-Ö $륵à¡KkA<õ¾.Œv«TëæÓ7iJ¹›4ó
²Ý×Þгþç%[ÖX.R{½f$«}¶/«W|D/lWë]
-
¼ÁÇNSkY{õ–Ø$2÷&i+³NNÙ �t{x�}·7é³u’7 oámë�½¢rù%Ý1Ó*NT1
‡²6[ë›òG¬M·ÛÜøt‡õý€"—Û*··bÐôd2“mõ:Ë
-¬ƒ�ú3¦‡¥áI‰µ6`I{«f>„o³Ãlù©Ü8†±¡NOß~8¡'Û³Žt›Ýq;ý]6¾š›Xµ>ž–,(wW&E6Ñeg@ŸÓëW/£JÎ}©/""§ïàÏŽäßþŠÿô_¤ù üìVͤ?¸I RÆ©‰jî>÷«þ?.1Š\endstream
+1431 0 obj <<
+/Length 2969      
+/Filter /FlateDecode
+>>
+stream
+xÚµ[[sÛ6~÷¯Ð£<S¡¸À£›ÚYwZ§ë¸»mh‰Ž9‘D…¤ãº¿~"
+t¦ÞÉd‚Ï
�Š,0ü#%fš/¤æH`"ëÝ^|‚{ïψìzÐjˆúáîìû+&éŒf‹»‡�,…°Rdq·ù}ùî_¿Þ]Þž¯¨ÀË�¯D†—?\ßüh{´ýóîÃÍÕõûßn/Î%_Þ]¸±Ý·—W—·—7ï.ÏWD	ÏS'áÄW×?_ÚÖûÛ‹_~¹¸=ÿóË;ïËÐ_‚™qäËÙïâÅÜþé#¦•X<ÃFDkºØ�qÁ�àŒõ=Û³�gÿöw»G§â'˜BBQ9@ʦ(4ÊÜ2
¼ØWícQƒWJ,¹¾3
¾Ü_‹muØûÖÞ)û÷Ýc^5û¢ý.5[æ¶÷ç‹ûÜ¡>'jYµÕºÚÚ[뮧ÈÛbã$í-´ÚŽ]¹Y-q±ç„/ÿ[íÝ�MÞæüP9KgÏ:ß›ØC
+/Œ¤~�š0  [®bÈõ�ÿŒn*¦›óc¤\R$e&N34ÕB®¦×ãgœŽå¾šqK¤¥`éè{ÔŒ!±´$ã„!(3Œ¢N3ΣŽ#ÕÖù¾y€ÅT”à4¢T¥Õ÷ 	õ
ßGkêK¾
½)Ï2”IÐ}’oF
xšâ[�Ÿq:–ûú§’
+Ïߣæ‰¤¥ù%aPÓ| |ëQÇ‘z:À
+¹ˆÙ™KP�ÖîQêC¾A~cœ†úß’oG/Æl£HaÐ|šm\ a˜“lsø—c¹ß°v3´ÀY:ö5gH$-Í6äÄzŽmT‚m=Êh´#´:TÛr=±zSˆPÊÓê=jBH7f6Î24à£ßÎ56þ¹ýóHüXî[GB£'»ß´×¿u†”½vB Š°¾Â‘ÇcotÂ`Í7´4E«?ãZ,w’Vtê¥	�°ôeé{ÔŒ!±´$­¸â¨Ó´¢NÓÊ£ÆÓ;üç¼Þ”ûOc;(†¸Áö1mˆGMX2tžb
DºõÿÉg#‡Æ4'	­ÈÉÜÆ6W8� ¡ÇϸË}ýÊ
œÍˆâéqð¨9C"iiB^`ŠÍ‘p€J�°GÙ1kªSEK-Íg”{Ô„ö`Ȭ朗ÿ°ß¾@Ø©^îŠ|dyxÚÚërŠoàŒ^¿à?Yõ€å’²ßµvµ;�˜Ã -lÛÔ Ñ>ö·ÿ®ö…ÉŠ˜-ï¬)ZÛ
+_UõÄÔÊ2„a)Ö¿@¬ï“ç>Ò¢ƒu3#Z-†câÍ-‡çd<äåvjYoEMéô´élR¬÷5ÛüëԚŸ1ö†–ÚvªI¢œ-?5õ‰†,ÉÌÔ S¿G§þî¯hÞSØwjIÓš=jBu¸†ƒÝ©9
t¿ÍæaèÁø-+PÆÕé2/…!‚�¨ÀÉÄfÁãgÜ�åžÚ,�h
ï2I4KÇÝ£f‰¥%YFgÆgX6D�f™GÇÖº›5líâƒo])Òú=j€0hÈÏJ…¼%׆~ÄD+•8X0»mLW“?ãt,÷ÕŒãØT5´LGߣf‰¥¥' ¾˜ÐÆ
P	Æõ¨ãH•û¶øT—m¼E…‰‘	X4'
ð¨	BÊ)óaˆ
+MxKÊŽŒ9GÁ4Á9&aäXàkŠs=~ÆëXî7pŽ£ŒJ™¿GÍKKsÎ|eÂÔç¨çzÔq¨šò~;Q�ë¾åàð
+Lª÷¨	ý!ãâTëЀ·9¬�Ü/0¤´Ö‰ãóé
=M/8üŒÏ±Ü׿U5F”Òtì{ÐœcYI²
Ü4­I²
Q§ÉæQÝš´¨Í>vÕTùªm·q‚Ã0JD¥
ð¨	Bº�¯’‘Є·¡Û„#cÂ)Äxâð¶œ*¸šÌo?ãt,÷øfÎ]OGߣæ‰¤¥)T:G¹
*A¹58βùásó9â\,!ÙŒ5aBÀ9‰‘ÔrdÃÛ¼T§<ô	³L&>€3å>94oî´ËágÜŽå¾þ­
+»1-2�Ž¿GÍKK³Î|äÉ�2iÖ
P	Öõ(£±­_Víú°ª‹‡ºh§ìÔeÚ
+µ�4mUÛ Ìq(÷�Àî÷5EóÌñ‘‡ÊÒ¦¾à†64,,ã«Â›Í?þ¹xyvµJÐB¥­
›¿°ý©í7ò…=M¢j™»›¹ýcJç¶ÕÅ
+£Þ()Æ–ûŸ’Ħÿýì{endstream
 endobj
-1366 0 obj <<
+1430 0 obj <<
 /Type /Page
-/Contents 1367 0 R
-/Resources 1365 0 R
+/Contents 1431 0 R
+/Resources 1429 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1382 0 R
-/Annots [ 1370 0 R 1371 0 R 1372 0 R 1373 0 R 1374 0 R 1375 0 R 1376 0 R 1377 0 R 1378 0 R 1379 0 R 1380 0 R 1381 0 R ]
+/Parent 1423 0 R
+/Annots [ 1434 0 R 1435 0 R 1436 0 R 1437 0 R 1438 0 R 1439 0 R 1440 0 R 1441 0 R 1442 0 R 1443 0 R 1444 0 R 1445 0 R 1446 0 R 1447 0 R ]
 >> endobj
-1370 0 obj <<
+1434 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [312.6233 667.7189 381.2953 679.7785]
 /Subtype /Link
 /A << /S /GoTo /D (access_control) >>
 >> endobj
-1371 0 obj <<
+1435 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
 /Rect [310.4119 636.5559 379.0839 648.6156]
 /Subtype /Link
 /A << /S /GoTo /D (access_control) >>
 >> endobj
-1372 0 obj <<
+1436 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [328.1051 605.393 396.7771 617.4526]
+/Rect [340.2996 605.393 408.9716 617.4526]
 /Subtype /Link
 /A << /S /GoTo /D (access_control) >>
 >> endobj
-1373 0 obj <<
+1437 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [320.3548 574.23 389.0268 586.2897]
+/Rect [328.1051 574.23 396.7771 586.2897]
 /Subtype /Link
 /A << /S /GoTo /D (access_control) >>
 >> endobj
-1374 0 obj <<
+1438 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [320.3548 543.0671 389.0268 555.1267]
+/Subtype /Link
+/A << /S /GoTo /D (access_control) >>
+>> endobj
+1439 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [359.1386 543.0671 427.8106 555.1267]
+/Rect [359.1386 511.9042 427.8106 523.9638]
 /Subtype /Link
 /A << /S /GoTo /D (dynamic_update_policies) >>
 >> endobj
-1375 0 obj <<
+1440 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [429.9426 511.9042 498.6146 523.9638]
+/Rect [429.9426 480.7412 498.6146 492.8008]
 /Subtype /Link
 /A << /S /GoTo /D (access_control) >>
 >> endobj
-1376 0 obj <<
+1441 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [286.0435 346.6843 354.7155 358.744]
+/Rect [286.0435 315.5214 354.7155 327.581]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1377 0 obj <<
+1442 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [339.144 315.5214 407.816 327.581]
+/Rect [339.144 284.3584 407.816 296.4181]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1378 0 obj <<
+1443 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [336.952 284.3584 405.624 296.4181]
+/Rect [336.952 253.1955 405.624 265.2551]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1379 0 obj <<
+1444 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [322.5463 253.1955 391.2183 265.2551]
+/Rect [322.5463 222.0326 391.2183 234.0922]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1380 0 obj <<
+1445 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [331.4327 222.0326 400.1047 234.0922]
+/Rect [331.4327 190.8696 400.1047 202.9292]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1381 0 obj <<
+1446 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [361.2812 190.8696 429.9532 202.9292]
+/Rect [361.2812 159.7067 429.9532 171.7663]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1368 0 obj <<
-/D [1366 0 R /XYZ 85.0394 794.5015 null]
+1447 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [330.3165 128.5437 398.9885 140.6034]
+/Subtype /Link
+/A << /S /GoTo /D (boolean_options) >>
 >> endobj
-466 0 obj <<
-/D [1366 0 R /XYZ 85.0394 726.6924 null]
+1432 0 obj <<
+/D [1430 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1369 0 obj <<
-/D [1366 0 R /XYZ 85.0394 700.1172 null]
+470 0 obj <<
+/D [1430 0 R /XYZ 85.0394 726.6924 null]
 >> endobj
-1365 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F48 885 0 R >>
+1433 0 obj <<
+/D [1430 0 R /XYZ 85.0394 700.1172 null]
+>> endobj
+1429 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F41 925 0 R /F21 702 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1385 0 obj <<
-/Length 2958      
+1450 0 obj <<
+/Length 3050      
 /Filter /FlateDecode
 >>
 stream
-xÚµ[ÛrÜ6}×WÌÛŽª2X\	àÑqd¯R;++µ[ç�šáHŒ)rv.R”¯ßÆuxí�].×€À!º8Ý
- UõýíÅßß0¹ÐHg4[Ün[})„•"‹ÛͯËQt	=àåë÷ïÞ\¿ýåæÕ¥äËÛë÷ï.WTàå›ë^¹ÒÛ›W?ýôêærE” Ë×ÿxõóíÕ�kÊ|ß_¿ûÁÕh÷3ÑéÍÕ›«›«w¯¯.»ýñâê6ÚÒ¶—`fùïů¿áÅÌþñ#¦•X<ÃFDkºx¼à‚!Á5ÕŇ‹Å[­öÕ±ñãB!Ay#É�ÔL��2A’
-è*ß“É(bŒ©ƒ•uß>
-
-(BÒàz¶×ãþ’¨e‘‹�ãa~p¿åÖÿý¯¯÷›RpÐîl:÷}Ùyÿ5ÊMò+Ë2¤5#i‚µQÓ‹(cÖ¶Ù?çûM_®fˆR!ÒrhDn'~)Dq¦ºrßÛ`L,‹¼.ëûí©2ÏÜŽ§©·³f
-nÖLÓƒsS•»§¼™—M±?8LUŽvÉâ–¾Ãc
�IÏ–àXƒ@î/‰=A˜ôÚ¬óӡ𲢊UÓ|‚8êôn\ã6/+G(
-œ0Bº„Ê·ÇbS/�û
S&ž¬PÙ7Î4:—‚ÆûâxŒ¯Ô�«ÌëÃ3t	Ëñw¦"[>?”Õø”)żuàÝt8Ž�‚]ZÃ(<7§ÊËÏ«ªyö:¹šºÙ?æ•«
-Ãamk\]ð.*)lQ2ƒxï*‹Í4û	
-±òŸA	î{P‹úfpû�ÃÊŒ
ý‚#h(¹›ÀL®ý[¢9Ø(B¤˜ãæ©ØïËMák|Á°Ù•š­ÞWÍ�g¨ëR™0¦]\…ÆÒ¿hã@êÆWvź4st(k‡ÈÝ£�’Q¦tAjH#&4’4£ž­PÒßMÀH1šÅøl‰
-9¥(:ø
-~åk;«Íïu5»q²bœÏ4=ßñƸSÅ”Ë9K¦}†ÀVÎúL•ð™€êøÌñq·òÃÙ�è0Š‹%"jD‹nLÏ`�œõÔˆ¾ãÂ��"õ¦YŸ‹:î›Ö­ô¿çõf2‚—בˆ›)¨ži®`3¯O�t5=ÒeYä‰Û?í‘Ál’rhDng·È‘’šwå¾òÛ
œHQXò¶ù©:ºZ¯ØßîÑ‘À“°–ÏÊnBì¯_m7Em#Xø“´tzµ+Žy=´®OÉx.�>üÀ¾XjÝuÀ)F0&<xð¸—Â^T›ŒIßK]”0«”¥ÌíCX!ãÄÐÖù]UD·®â„K”e<èð˜̾t4% Ï‹½	�#}ÁR"dÐôPåOŘ=Â3ý™pŠÊpüV3Tn¡T(gç+»m<ÊÇb5Ìt8.•ÖÃcFÔèD
!�Èëêñu9)kúû)ådj‡eAº&'R;?cþ°ß©ÔŽì«d¶ŠŠšž…ˆšQdØ[2µÃ1¼ª˜œa`•``@�ÎY¹©FªiM"jD•.)’ÚLC[—oÄ–E}BtÇŠN³Pp'&Ù1:Å€Ÿ1Øï°� ª)MÏCDÍ(2ì-ÉB&5"xfEo�¦9@Óa£9‡QkD“¤4T¤ÃÀŒ@#0µ­É·ƒÞž‘�&°‰›¤ „b¸csŠ�
ž¶~Ðëçó�Ánë4"(­Å ¯4ù¸B°ë˜IÀ´Q	úÔtÀåCŒëU"jD—nTpöÅ=eþu2ŽSP›ÜvÜ.�-Å�tŒN®Ä>cý ×/` …½ƒñÜÔ,DÔŒÃÞÒ$„Ã*ã|f'ØF%HP.çt4©‹þ™†›¬ˆJ‹
 ±mK•Ù—o‹ý:t;+ߟeØmeYâ�J$)´Úª§nð~ÆÖa¿_pƒÇÇJ§Ç<¢æô–¤U⟹Âk£¦éQçZmŠ*ÞàŠ„¦*-=¢FÄwÓ	ÉIWþ×YYûVôD›€ªq6Í6ð"%ïšb[ÀϘ<ìw’mb¸Åp€=hrð#jF“aoiº™Ã 3É°6*A·€2w§»OÅ€hæ8»'¥z̈ÐÞñQp8¼w„^›±–<$§ ¤¾é›Œ€š˜÷‚òsî+ËúhSæIø|>Tût²¿áâÛ*“ï5eŸv„·Œ¹¶*¾þTìíÇ:?‹´yK@Êû:_ùD
Gš³þEïéœ
-Ræ–wýàj×y¿e°¿›Óã®Ø8¶ÃÁCaLz¯­LÿÈE±4w—aqž˜V–½¿hÄE|cS`ÝÏaG’Å¡9_ÉM2ŽåÏDÌ6jšseÍ*ïWOyUnÊãËʤýÓ0ÅmÒ+œ«’jDÔˆý$‡šŽ_gC8iÍ0
C™æ‰CJBLl[’LÀxüŒéÃ~?ÅæೂÍP!€fôô•\®	xVsù—6*A¾€r>´ŽŠ‡æ´_ﮨ¹d’3JDÔˆݸ§‘=-¾Îq–žéO$ˆ‡•9“Ž¹)âüŒáÃ~?ûÜË$7÷}"=5§È ·$õ`ÃkÔLú¹š&^
-3СK8Ž¸96·”ø:kl”>ã@4Ö‰kðL¸jY›$œG'íî÷ùtã0k°'N}Ä$Uè÷4ε�ŒÈ|Å?"
þûƒÙ_þc�ó_RÀ�)E'ò	b™‚N¼RFqɇ^‚aógå¡êÿXÔ€9endstream
+xÚµZ[sÛ¶~÷¯Ðô¥òL…
+6§éd2†€�Ø]àÛÅâ‚WüÃ+ÆWD­„Š‹0[m÷Ñê
ÚÞ\`‡ÙxЦ‹úîîâÛk*V
+)Nøên×éK¢HJ¼ºK[sDÐ%ô­_¿{{}óæçÛW—"^ßݼ{{¹!,Z_ßüûÊ–ÞܾúñÇW·—,^¿þ׫Ÿî®nmw}|wóö{[£ìŸ™No¯®¯n¯Þ¾¾ºüý«»Ö–®½8¢Ú�ÿ^üö{´JÁì."D•d«gø!¬Yí/bF‹)õ5ÅÅû‹ÿ´vZͧ“ã‡#D('Hhg
+gn+ôl»kÉËmqJµ<ýë9omÉÈ3ŸæusÌïOÚ"[e[(«2›èÒ`»wß¼¸Þ,õÐÈ›0ó—aíÓì· MeÉ�'¢G‹Ò£‘æ0‰‡¡XÉÀó XšÛõ>Ç@‘žØ÷Y6ϬÞóÃy8«�s­®
J ˆ€KFå2)ø)Ès0ì�}
+[
A`ë
CÉ0§€‘¢„·ñÙ
V%ˆì¼Ÿa–.dv,³4ïÖ´Í
5H…>�óÇ2´µ#§3$“-Me¯v˜ 
+pÒ£LÂõçÎh³1éý0*sDUaé4!½ÇË#W¤/þ—KEÌʆa‘<–b†è»Ó%i4}õOé݋ýaF\·–É>³UšI�&(!Z%.¹ÓØ¢z°-"ýQ�Ž°Ù�"ö•)\¯fÖueúò­Sö
+¹¨Òç�C/µQB¯R†2î(«»Ñ´mrïÏlü«7Ñ8ˆóØë°Oj�—N¨ób¯CàD_
+Öá5­}5aƒðL½@·'œ¡2•1)‚F5OåeíüsãX³©óOãˆ
;âˆ-(àA
+ôw×EÆ¥§Á—9È™²c ^H$³G:&ø%z¶ŽtZü‚Ùã~g�t¢‘N�Ƴðø·¨%MF½Ït((dĤ려ó(?Y&óÙenÅÊ÷Ùf<#ö¨L†õp˜	5zÔƒ]ã˜öõørÔ›³fÕ!)Õëä,y„0Ã}“CôøóÇýÎQPUÒûI1	ÏB‹ZPdÜ[˜�°óŽ÷]T€�59gyZL2VX~YX“5¡JŸ…	¥§¡«Ë?ÄÂŽECRÄ#IæYÈbÄ1=£C,ôøóÇý~1"Š�ð<´¨EƽYH¤DB.„Áhžƒ46ªS3Ž‚°2`…ƒz´ ±"=r«0µ«É?�=»n…¹š§ €¢QÏæ=<lý¨×¿Î?
+[ÄH…¹Ð‚ÂZŒú
+“öVúò+L¾3(@>š�“䣈Æ*¬G+ÒQõ5ù{äSÁè7M>¥¯RÚì|jf0`¸kqp	¶è°éÃ>?ƒxRí°�ñoAa%F}…‰K5añó:¨
+iúq'a©3!tp8Ábhì	½Ñƒ,bÞ%ù�?�6ç«PÓåCù9q•yÙ˜SYý‹¹+J¨v7dîÒ>¶×汶­ÐWXºìnRà+m®©j?ÿ˜Í�í69‹4W1€®ó‡2Ù¸³gˆ	1¾]9�ï´ˆ½ÍÓ¿ûþýÕk[Ö}�‰ÕÃAŸí#bÞ:¼ØÒùº”èk»$õßÙ[˜jo¥yýdY¶×lP©\[åØëVb
ܽœ•IÎJO¼Dô. Åî{ûWxÝð`§k–¿B "øBÚ×
ͳ׃üñö¦n`Úê&ߎŸÀF\r,‚Ò[ÐX|/Lê+ˆ¦]ñ7»‰GUJ¿õ’ÿד*ÿf˼5åóSª§,;ø_ÎÞÄ5ååN¿qÜ…
+Kló8+¯Ï¯³Œ ©®lmí6)ÛçYæozÚ²Ô²¶µ2ŠpŸÝËˉ·/B?Çðéêyb:‡Ã”CATh¿H3
,‡×r-ÉÚ¡9¿2@s½)C3¯á¿óß¿ýüüB>ˆJ9—à	C©WJÛ*øØWÜkñ±êÿ×è"Rendstream
 endobj
-1384 0 obj <<
+1449 0 obj <<
 /Type /Page
-/Contents 1385 0 R
-/Resources 1383 0 R
+/Contents 1450 0 R
+/Resources 1448 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1382 0 R
-/Annots [ 1387 0 R 1388 0 R 1389 0 R 1390 0 R 1391 0 R 1392 0 R 1393 0 R 1394 0 R 1395 0 R 1396 0 R 1397 0 R ]
+/Parent 1423 0 R
+/Annots [ 1452 0 R 1453 0 R 1454 0 R 1455 0 R 1456 0 R 1457 0 R 1458 0 R 1459 0 R 1460 0 R ]
 >> endobj
-1387 0 obj <<
+1452 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [231.137 736.902 299.809 748.9617]
+/Rect [231.137 681.3376 299.809 693.3972]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1388 0 obj <<
+1453 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [324.1075 378.783 397.7608 390.8427]
+/Subtype /Link
+/A << /S /GoTo /D (server_resource_limits) >>
+>> endobj
+1454 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [359.1555 437.0578 427.8275 449.1174]
+/Rect [359.1555 347.5161 427.8275 359.5757]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1389 0 obj <<
+1455 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [353.6164 406.178 422.2884 418.2377]
+/Rect [353.6164 316.2492 422.2884 328.3088]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1390 0 obj <<
+1456 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [370.2338 375.2983 438.9058 387.358]
+/Rect [370.2338 284.9823 438.9058 297.0419]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1391 0 obj <<
+1457 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [364.6948 344.4186 433.3668 356.4782]
+/Rect [364.6948 253.7154 433.3668 265.775]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1392 0 obj <<
+1458 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [226.7331 313.5389 295.4051 325.5985]
+/Rect [226.7331 222.4485 295.4051 234.5081]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1393 0 obj <<
+1459 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [283.1811 282.6591 356.8344 294.7188]
+/Rect [283.1811 191.1815 356.8344 203.2412]
 /Subtype /Link
 /A << /S /GoTo /D (tuning) >>
 >> endobj
-1394 0 obj <<
+1460 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [287.6042 159.9146 356.2762 171.9743]
+/Subtype /Link
+/A << /S /GoTo /D (boolean_options) >>
+>> endobj
+1451 0 obj <<
+/D [1449 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1448 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F48 940 0 R /F21 702 0 R /F41 925 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1463 0 obj <<
+/Length 2955      
+/Filter /FlateDecode
+>>
+stream
+xÚµ[Msã6½ûWè(WEX|¬=MϬS›IÖqjI‰²Y‘H‡¤<Ñþúm D$¨©8•J‰Ÿ¯»€njLVþ#+-f	_©„#�‰Xm�7xõÏ>܇Ùt MõõãÍ?Þ3µJP"©\=î{¶4ÂZ“Õãî—õ7ÿz÷ããÝÃí†
+¼–èv#$^}ÿñ[;’Ø�o~øøþþÃÏïn_?ÞÿðÑ?ܽ¿{¸ûøÍÝí†hAàûÔY˜ùÂûûßÙ«ï¾ÿþÝÃío�ßÝÜ=z_úþÌŒ#Üüò^íÀíïn0b‰«ÏpƒIº:ÞpÁ�àŒu#‡›Ÿnþã
öž¶_�Š	Êåj`"ŸŽ2FX@Ô6ŠÄ\uQ¦d*ÊÊD¹ÎŸ6¯é!ßåÍy“MVÁÝØw¢RZÓU‚€†GMð`=ø*™ˆ!‘Ÿ²ÌÆ¿yv»¬ÞVùK“—…(÷†ØÈ«D!L¹
+QwF†(
+ö[y1ö˜iŠ(%jà±}X=­ìÅCÏw�_ð=´k}ß^¼4R%1ædáñ,xÔ“Кa‚Ù;m)BÌÒLØCEØ¡ºŒÁÿE^<mŠrˆOJÄ4“q
+5Áa >ÞJžIü5ñ%=ñ®Œæ×uæ¿1!<É'tèmLx~ÁïÐî�AâãñxÔ“ÐZTx.4Kd\x}Ô¼ð<jœ-ó™6§jB}Â’hçáQDêK¢zÈãí6¾ioÆ0Cj~ããð˜r:ô7¢?�_ð<´ûúS%˜‰x<j‰I`-®?�‘Hì�Ñ_Ñ_‡g¬9¿d�òDe–q5Aa�v	e‹¢C
+o/½Î‘ÑìJ"ÉId×ã	X”C_c»^‡_ð:´ûª£I­x<þµÀ$´WÀ'¢»€"šs 3]S¥E½Ïª[¢×›º<UÛ	ÕQ”PgàA!…�æ„‚•&†ÞFs3žŒeÓ*˜VvL"ž˜­àâFLu<îv`uNsjjó%ŠEcßaâÆ–¢b9"œ@QU[5/7�šÉÒæUNxJÒ5Ad\à)ÎFLþ6Õ9ÆUG”°ˆðÌnlZ ¾/Ñ*Ïáœí^¯=§!¦Ñ$t �­¸üàÓœŠùõPùu(3czh6×lyR!-tœGšà1T55yõEÜËO †�ļü Y’„
\ŽÊÏá¼í~�ü«x<j�Hh-®@šÀ™Ìè‚{¨ˆ;T$eS› &HB-¥Ò�&¨_°@¹¥`÷pù[E8½
&P›rÑaÂ!h}¢:ìð
í^¯C‰‘‚ÅO„G-	­EuÈ!`Œ³…—,}Ô¼=ÊÌxª³Íµ»¡�„ØEÉxÔ›qÃ+¹–C:oóºeÁ© ï…£hG;ßD%ÉÀñ…ηÅ/„ ´{½¡€•¢ŸÌéÆס–ˆÖâb”Ð;%|áÅKc‡23e“ïÏsòãpvIØ°£Ó{ÔÄüÃÄ”¿L	¼ÍN¸1š[B%@˜žßü(�îÁ¾±Í¯Ã/øÚ½ZoLk86¾G-	¬ÅõÆ4ÕbáEKÑ[‡
+5uôB�@1q5A!xÑ¢‰rø$7}äš7-‚èø›.ÙÀÙ¥7-¿àvh÷ú]Ž¤¨Ðñø{Ô‘ÐZ\uXÃÁ¼´É]@Í9�™î˜›*ÛWYý¼iòcö•�À1ýsr¸E7Õ9ÄvƒáJ‚ê(
+WK	ãtàA+X’8Áš‹�`ÍÀÄ
+
+¬iŸUìíàq~�Õ�²“Ùwxê/¡ !‰…Ƀâ4[Q]1¥áä‘:.¬>j^YÕ.é?÷¶ÒÙWåq³Ë÷檟¬ØNýz�§ÐEéxÔŸa_!Çtȧ
+“Â
+…I>Šy2¹³L Šœt;Õ’[ak�	�µ†#l×}—¢­…Ã/Ä ´;P£q·ScØZÀ kÑdxÔ‘КÕãF
+¾þü±l|fÒƦÆä(Lņ	àLÌ&Oì‚^›8™g•VÔeä˜Ö
”äaâ`W†é:XZì&,¨O…ïëCú:U`1
+uŽ/è·Ïenxµ›gÚw'-œšnô5Í駃O›Ñ‘ü¿²pW‡ì5; ˆ"™]ßÂÏéBµÒGEÖw‡2~üž�!Öª¬ÎSÕqB1�OïQó�«ãC±0 ð6¥JàƸ:f�<¢"Õ1EÐ7Ò�§ÑêØá|íÎÔ)á‰kÞ½0½G-ѬÅO,�N–Äv
E´æ@í=š|sY©C¥1$µÖÑ©=(œ{ 3®‘T˜&›w
+	>O½U“ç~¸·eû¹ó{àT´›«¼˜¨•‘WèrV4Jß\!è3“Q^(c뼶ŸEöÙ
bŒv‹Fûaäj/ŒÜ׎¥oàÎ,Ÿ"Û@äó"shXUM‹)Öp	´�>·m”¹º¬Wcß™´âÀ“a†ZÙÎ$œ²õ;@±®³¶ýà.ê2¢×§ƒí`„uFÍ‚È
Ñl×.	4`óÉ.
ŽXgéöy`Ã
ç�­Ê>èÔÕNXÙ绬È37vÑŽØw(×]¾æc8Øžlò�`Œ
-¬ú4_Êì½�ÙÎ
ží 5n.*û — Í�b“7ÀbÇ	_ßï-ÌÊ—mÔOaÖ̧¬nìC V§OîiîHš¶f9‰¶gn;å‰m7¯Ý.•7ÝzØN»®Ý¼D�ýxüéþƒ[Uî
˜)pÛUN¬A3þÕh•¹
+»>‰Òp¦µ'Éh�pÍüŠŽÅõž%Ltèº
ð’g´%�ÞTw>ÔðÀøš+¨"µ·—Ã=u%f•Ý™*{kÝÖs™¡
+wrõAH¤œæn²2ºjCÈ´ù3:\ø=ÇLÌ•š9(û÷µ$*™à¥h§ÅÖÙŸ©ÑymÇíê€a¿:xoÇR{ë6ƒöwó�ÒSÛÌÂÒÝÎùU[@îæ0¯”¬ž(ƒƒ-¡C=Ù/²×Ô„cæ‰rl²Éƒÿ�±¿üGF—¿Àâ
+1óÇ9ÓíÔ…š&ª#eœPÁ5PÖ#¡©š þ4A‘�endstream
+endobj
+1462 0 obj <<
+/Type /Page
+/Contents 1463 0 R
+/Resources 1461 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1423 0 R
+/Annots [ 1465 0 R 1466 0 R 1467 0 R 1468 0 R 1469 0 R 1470 0 R 1471 0 R 1472 0 R 1473 0 R 1474 0 R 1475 0 R 1476 0 R 1477 0 R 1478 0 R 1479 0 R 1480 0 R ]
+>> endobj
+1465 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [352.879 154.1545 426.5323 166.2141]
+/Rect [381.2254 737.5325 454.8788 749.5921]
 /Subtype /Link
 /A << /S /GoTo /D (tuning) >>
 >> endobj
-1395 0 obj <<
+1466 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [307.1508 123.2747 375.8228 135.3344]
+/Rect [362.4163 707.2832 436.0696 719.3428]
 /Subtype /Link
-/A << /S /GoTo /D (zone_transfers) >>
+/A << /S /GoTo /D (tuning) >>
 >> endobj
-1396 0 obj <<
+1467 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [334.8268 92.395 403.4988 104.4547]
+/Rect [402.2465 677.0339 475.8998 689.0936]
 /Subtype /Link
-/A << /S /GoTo /D (zone_transfers) >>
+/A << /S /GoTo /D (tuning) >>
 >> endobj
-1397 0 obj <<
+1468 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [337.0185 61.5153 405.6905 73.5749]
+/Rect [348.0303 646.7846 421.6837 658.8443]
 /Subtype /Link
-/A << /S /GoTo /D (zone_transfers) >>
+/A << /S /GoTo /D (tuning) >>
 >> endobj
-1386 0 obj <<
-/D [1384 0 R /XYZ 56.6929 794.5015 null]
+1469 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [335.4973 616.5353 404.1693 628.595]
+/Subtype /Link
+/A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1383 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F48 885 0 R /F39 863 0 R >>
-/ProcSet [ /PDF /Text ]
+1470 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [363.1733 586.2861 431.8453 598.3457]
+/Subtype /Link
+/A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1400 0 obj <<
-/Length 3140      
-/Filter /FlateDecode
->>
-stream
-xÚµZÝ“Û¶¿¿B�º€Ú''9»N;=_¦ÓIò@KÔk‰¼ˆÔ�•éß],ñKäuâNÆ!¸X,v¿ý
-ÈÅ�gŒ0]þ�/¹	äe-&P§,J,;ÆN¡®áŸ1{(÷åYNh–DÚLû?pÍ(2”6�º(Âeu-®	Ô5\¸ã>/V‡l{Ȫ‡U�ï³Wä„}úe”ì¸ëÃiÈÛ‡Á
-èÈL›¸Flè·LVª¨k„ƒ­°¶8èÀ	#…¶ÔÜDŦ
-iÃ?£âPnb¨Œ‡˜Ð}�àjÂt"ä´³׌&Ci“Ó6b‘†`cm®Ë\.¼¿l©ëÙÊýj“oñ:¡¬XgÕ°±ãLE<™V'p�èÓ½ch¦àÆÔÑçëôu³Võo	3I4qÉ:PÓ±{ò’áùg<0”{)ã‰A„À½SÄq4}�kF‘¡´i4Bc"“™»n‹i‹ž	·ûœ�à¨`}y8�5u6âjrïÀ4ܼßÒY®½û×)¯ú�„
E2ÑÑEˆˆ¨mædCçÙ§
H½
-TˆÍ6.PbP’Oì
-p±;yŸ¥E^Üo�;z'¬âÝ;ÊFØÈX,ÿù�Ÿ"1PÓ\%é¥ÐÓðï¿\¿Ü2+uÃ]ÕÀ¼‡ÃClÅoIS*˜@[­&@µ8Rz=÷Ô·p@Ì”™ôJf›K')hÜÅ‹¡ˆãqÝ)�Ä•s¡„N?ÁïŒí×2}ž$ê€6,â¡â¾-6±#z%Qƒ‡D.³/)â¼":E�Ct ó–h)½údð—v6Á%5SëŒØÒÍÆÛUCî÷(ÊÚã)’PØlÔÅ-ÚeO)ºc´Hæ>u4χò¹“?Z™CÙ•ªüÜÍïÊòsõgr™´½Þ×2cú~…çzC#í*
-•“&J-Ù²¡1%6%=·Çƒ¯°¢Õ
-,‘‘킺rWè&.tÒ.Ë.wDN]@Ö’HîûôcÃê<s�jÓeFÂÅñnÔ£ S±Šæ]Š¿Ê1±¸¶ÛݵÔÀûlJ	Œ’Ð\M\ývLw­4ž)÷©û°å?º@Sh4þT£Ã½OŒ[#,4–¡ƒ	|Ü!FŒá¾¤ã'Lz<¥;ÈcÍ�LÊà:—Þ†;adž¿�%¦W#b³F4˜`9ÇcJKèOM4'ªÙË£p3	3ø÷âJª²Ýö¢iê‘æ�©#˜QRAþ³ÐfDb¤Àçá�(Íœ5qð·!¦ðKbh‹¥}Éo—¥2,áÉ…ß.ãÏ‘•0pc‰™–|ôÇ
-ðχûþ©ôùwä`©4æÒ—zƒl²�š�,Ê3Éð§Ò0m¢3[KùÿÿÞY[endstream
-endobj
-1399 0 obj <<
-/Type /Page
-/Contents 1400 0 R
-/Resources 1398 0 R
-/MediaBox [0 0 595.2756 841.8898]
-/Parent 1382 0 R
-/Annots [ 1402 0 R 1403 0 R 1404 0 R 1405 0 R 1406 0 R 1407 0 R 1408 0 R 1409 0 R 1410 0 R ]
+1471 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [365.365 556.0368 434.037 568.0964]
+/Subtype /Link
+/A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1402 0 obj <<
+1472 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [393.041 737.8938 461.713 749.9535]
+/Rect [393.041 525.7875 461.713 537.8471]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1403 0 obj <<
+1473 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [402.9837 708.0059 471.6557 720.0656]
+/Rect [402.9837 495.5382 471.6557 507.5979]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1404 0 obj <<
+1474 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [320.374 678.118 389.046 690.1776]
+/Rect [320.374 465.2889 389.046 477.3486]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1405 0 obj <<
+1475 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [348.05 648.2301 416.722 660.2897]
+/Rect [348.05 435.0397 416.722 447.0993]
 /Subtype /Link
 /A << /S /GoTo /D (zone_transfers) >>
 >> endobj
-1406 0 obj <<
+1476 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [488.512 618.3422 561.5676 630.4018]
+/Rect [488.512 404.7904 561.5676 416.85]
 /Subtype /Link
 /A << /S /GoTo /D (tuning) >>
 >> endobj
-1407 0 obj <<
+1477 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [390.4905 588.4542 459.1625 600.5139]
+/Rect [397.3443 374.5411 467.1586 386.6007]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1408 0 obj <<
+1478 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [321.49 558.5663 382.69 570.626]
+/Rect [321.49 332.3366 382.69 344.3963]
 /Subtype /Link
 /A << /S /GoTo /D (options) >>
 >> endobj
-1409 0 obj <<
+1479 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [317.0267 528.6784 385.6987 540.738]
+/Rect [317.0267 302.0873 385.6987 314.147]
 /Subtype /Link
 /A << /S /GoTo /D (boolean_options) >>
 >> endobj
-1410 0 obj <<
+1480 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [356.8967 498.7905 430.5501 510.8501]
+/Rect [356.8967 271.8381 430.5501 283.8977]
 /Subtype /Link
 /A << /S /GoTo /D (tuning) >>
 >> endobj
-1401 0 obj <<
-/D [1399 0 R /XYZ 85.0394 794.5015 null]
+1464 0 obj <<
+/D [1462 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-470 0 obj <<
-/D [1399 0 R /XYZ 85.0394 484.6014 null]
+474 0 obj <<
+/D [1462 0 R /XYZ 85.0394 256.8016 null]
 >> endobj
-1051 0 obj <<
-/D [1399 0 R /XYZ 85.0394 459.8194 null]
+1106 0 obj <<
+/D [1462 0 R /XYZ 85.0394 231.4888 null]
 >> endobj
-1411 0 obj <<
-/D [1399 0 R /XYZ 85.0394 84.3175 null]
+1461 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F48 940 0 R >>
+/ProcSet [ /PDF /Text ]
 >> endobj
-1412 0 obj <<
-/D [1399 0 R /XYZ 85.0394 72.3624 null]
+1483 0 obj <<
+/Length 3014      
+/Filter /FlateDecode
+>>
+stream
+xÚÍZ[sÛº~÷¯Ðœ'¹c!¸ìS}'õ¹8©ãN§““Z¢-6©ˆTœÌôÇwR LYJ�Ît<c€Àb±X|Xì.$FþÄÈXfS™Ž’T3Ã…M—'|t}oND ™´D“˜ê盓¯U2JYj¥ÝÜE¼ãΉÑÍìÃØ2ÉN�¿|{õúòÍ߯ÏO=¾¹|{u:‘†�__þvAµ7×ç¿ÿ~~}:ΈñË¿ž¿»¹¸¦.xü|yõŠZR*ö0½¾x}q}qõòâôãÍ/'7ÝZâõ
+®p!ŸO>|ä£,û—ÎTêÌè
>8i*GËm3Z©¶eqòþäoè×ÔŸàL*+(Õ�Mʬ‚.Tàͼ¨iQm9¯¨’Q±>uãÍ"§�Yþç²,š¢*©eQUŸê?£"^¼Ö"šŽ�&2eÎ9?ÏÜðÓ‰å||¿Îʆªÿ¦b–—ߨT‚j46EÚËl™7ßVùö‹j¨À®šªI’ÞÂ[I’Ô‹r‘Mç »µÑÒàÃËUS½Zc™ dEÚVëâK±ÈïóТŒ¿-§ahFÅ2¯ëì>§¡ó,Œ«7Ó)tÜm‹o�.k¦ó|ÖD9ƒ¯4œ«U¾Î‚²�)ì,$K�‘~AÅr™ÏŠ¬Éý.¥¥ø	œ£µ@£_ËŒêY*eEåÝf
s®iD�¥´ëSáÆ9}ä_³eQæ3P�–v|N­[=‡ÇpÙ®æyI5ZTê⾄{ë¡CM#‘�N½v"°a˜/fgÔ×4� bÒõ']¿kPsQRc6�V~¹³Œ6úŠf>À…àq
+¢ jöˆÆÂ*Õ¶Þïmõ*Ÿžû,Ñr€˜jAÖÍ�°TÉÄÏ}U!`E«q¨K¿KØF›ûySPeF½w՚Α‰Ï‘†9e€½_Ñt5©óÅÝÀ�3‚))’@8ÌK2—˜–Ä6•ÞË,a2MU ë”¡EÒÊ[7 vê,^PÖ�d™­VEyO½/¨Xêî«WÜDª„)¢÷6oZ•È©³yËMÝD{¸³)P÷nŒÆw
+¬6@c§´ðx”×èÀ[ýzDÙ xLŠ4jœ-êŠZ‘�ã2¿¯š¢½Èð4æͼšQ�¤ÂÚí7*ß¼?A|�Ñçü C&Ç€€ìvQÔÁnJ0·aòèÐ)Ò[ÖÐÇî¥)¶[%R3þ5_ßæ^ûUM-pÓ—Ób•-èõ‰e7bº(`2Žûë}NÍY¼ Û9—€×Å]0_?Áb×™W
+ö·D°äxážr‰½ahq‚„^`e”IÔ1>qoØnBp°Wðfåêá>"¡´c	OvÿݨVŒ¼Ã�Ø+
�ãÀ+T[ëÐg5é³,‘JviŽ¾!JÑ.
{&™„Kô	;”p–"RãÅ×lÚL‚G¯gj™¡o„
¿u<äJ°§»|ð£‹ãðƒ]•èàHAS;ùîUs›ûxM;9»³~"†®™)º!>¾¨vâ¼FrJYòúÚîÇ·€„‰¥Õî€]¶LwWE¸ÄàÒ�i‘‚‚£mxÞÖ"ˆw®E‹ú¡h1j
+™@‹ŒN^8}Ì´é3§ÉDÚ‹6÷ÑÆ«X	qÔ:ˆbܲͨðM†P´õª»³PYï
ÐÙ3$œc\KóCmÍ�B�2ÌYc¾ƒe;b?‚„e©Nô
ið•µV‡üŒ]
+JÁÒ5sȹáÛ�?œzÏ«
�^ƒ©*([;é<XC©»/ 4gÆ8s”b4j~W1Öè­búŽ. �w!ð<M$¸óBŠï›/«6n�ƲªjÙÔ9Ä¿}ƒ
WßbQ=�4�­¨ÊÀ)$¶äxµû�°�œ&ÛçT€%X7-<–Û·
O3bÔ”<Œ»ÂN8ñŽ‰¬T¸ë•õY©Šª·¡i³‚6R0�Æí¾ ^HÆ]—Ez:
�v:D»„)?!f?©ÚVPQâ*ÞïÔ2Ç-n$K´"7úOƒ[nRÆ�Öh¡èX¶ï}Y›â¨›|]ÔŸèu¯ÿ�Ñ:»Ó¬Î÷æØâ=ÏŠþO]MÅ1‚ã\M°Ì¥Øöd`ÐÑ´½÷ØðØf1�¾,Ùš
ìûiXªœ<�½
+‡êÿ^sA'fÚ
'd’9�—m ôR¢-ø?J¤,hn Â÷Ô…—ú'2<CPQ<vËxp¥ ì ‚ÃP
Oß}*)¬u*ž§‡
+Öªrñ-L�Æ÷�f"àd¤‰Q}+þV»P£ƒÌÑ@‰wàG
œ&¹ùžaÈчЖaFõI¤È$a<‘‡²P} œã‹NYûÚæ=46›çÙ—œj·9ù}SäeèýRdT¹yùŽ*þwH„Ⱦ%¼Ý`u�ã×»•JmŸjñ㎞f–ôE=xoþ%k:²ËwTf³ÝéuM
Eé'Û±@{5IŸ¿zuÍίß�¦Òÿ°

Pâ‹Ëw6î
+O£õ*›¶�õC/Ám˜ÏÃ9Ûu
�U8À¸à€<ð8�±æ˜<ž”þÍFìÍÈ%–Y<9ǃ”F<ŽHZñ&üI0ã:þáQ§ZLl¢ûâÒ‘š
IßW@��ýÓß¼5=oÁ!ãø/Ç�~k%RðLÒ‘
+endobj
+1482 0 obj <<
+/Type /Page
+/Contents 1483 0 R
+/Resources 1481 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1423 0 R
 >> endobj
-1398 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F53 962 0 R >>
+1484 0 obj <<
+/D [1482 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+1485 0 obj <<
+/D [1482 0 R /XYZ 56.6929 512.9872 null]
+>> endobj
+1486 0 obj <<
+/D [1482 0 R /XYZ 56.6929 501.0321 null]
+>> endobj
+1481 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F41 925 0 R /F53 1017 0 R /F48 940 0 R /F62 1050 0 R >>
+/XObject << /Im2 1039 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1415 0 obj <<
-/Length 3076      
+1489 0 obj <<
+/Length 2789      
 /Filter /FlateDecode
 >>
 stream
-xÚÍZÝsãÆ
÷_¡Gºcm¸$—}»Üù’Ëd|­¬L§ùx ¤µÅ†"‘:Ÿû×X`)J–,_}™v<c.±Ø/à,
-©=k#,¬ÿ’eµ±"‹³ËÆ£±Ò"—±9=�‹a.nÒ}0ÕXƹ�ðÔ¨‘)™ïÔ˜Ô(e"ŒÍFY"…JAèƺX9ò7ï•ðf±È•ÆÕ‘éús1ïÆ«¢›//Ç:ÓQëVEÝ•óôšÚ8š.Ë–z6—6ÚVŽ^üÇ=KWcËDÝ’ûÃâ()Ež$ʯ7se}OHØ®Eçô‚‹øçÂáêEE¯]ÃOœó¦î€ƒ¹›»]·?i2<©’(
cù¨'ä¡R
(`ž_ãX¹j!Ái’L™ƒ„zx�nEl.ÀEU¸ÀÑ­”鸨LèDôv;[4«¢¬Ïb† ¡¹ƒ¾ô�À‚¶Xu’äï[=ä2
-Óôð;C‘ß&#àŠ›
-˜VÎ…!F1/DŠŽ‡QYÌ‘<{¤àËq¤@œŸ$æ,Rr8ê
Rüœ)Øjêê‘`Æ÷ÃÌX*#ò,ÑûNü¨ö‰F�˜—ãd €¯…“]må¿«š¼®Ö"!*ÒÈh¬`CJçÃ"Ï“b�Ê,@@3N
-B´¡É„c?�.H@¯Ã·§ìS$©H+¹R)L%À]G·`ÀŽ¨´[°ÞÎÀ}�¯”`�ß1<éÈÐGV	vˆÅC¤×î�¦˜Lx©eñ‰§Ÿ¹°!ÊLرqD½¾ËÕºr+`î‹ÞõAÉæÝÍ­è
°°óÅ{á!¹*¾ï=`÷p¢
¢rðAGöˆ=ͳ`{ƒ^Çö¶9Œ³¡Zê+˜¥Y8Ô
d�פ8&R‹²Í{ë:šÐë(.hR@-kp
«"à]©àS±Ó;~l̘ýß㥔2Ç€6]rjM‹CÃ/nä±ÅM<\œ“ö�GÄwòˆ¾‡ëbÓ•ó-… Föµ¾PÀ¢ôjÝ´a‚°~ë`dÑ1/€Ë8 Ééñr[™ÛÐý@"̼Рµ‘¥Ê8È:ç09µ0¡-ïk¯L¸ž˜äA왜[°“œóhÍòr›OžGÒëy)è© wÓ^QÍ(H¸К°ÿnyXâ 8£8Ñ—Æä|T.šØÒ÷àéðNÍL„·‘Ì¢¶ÙðÕ1¹ÚV]¹®x¸—•b™ aí6«²#‹…Wº‘psë’Š3
-<çvƒ*ly±žÓ}.Ði,øý½
-›@êê]øC¬™k¨¢š^‡ÙèÙÕt÷¢‰ÉdÿÛú]³­Ÿ)·û:–‘¾ê/!¤�œ?ÉÎ55Âæ–€LeøÔ¤Iô…—§‘«çƒ <ó$’éxVvÔñ©¨¶Žšì‡�a—9¶¡+ðø©‘ÇÅ°‹TBŸ¯­&9íy¬f?™yFO;
|­*ŽÉ„Uñ—LFœVS,E¢S}FO�‘�š8�™þˆ_cò˜
Ÿ�4Ë•Ã-)£qU~b¢uD�%
-rÀ´6†]O>t=vàzò�ë±½ëÉ+ì+¨ƒ‚í¦kæME”»b…`;‰àþ2uÛuð:—ùpÚg~ÃÒËáu’5q,2•¢‚(ˆ*Ó‡!NÜß2¯þEàîW‘
+xÚÍZYsÛ8~÷¯à#U!8ûæq쌧f•¬¬©­�ã�!‹5©ˆ”ϯßn4@Q‡íÉ$S»•*l4€FãëŠ8üAªWY$YÄ4:X¬/xpcï/„ã{¦ñ�ë»ÙÅÛ•Ëb³å`­”ñ4Á¬ø%¼úþòãìz:KÍØ�Æ:æáw·“wDɨ¹ú0¹¹}ÿÓôr”DáìöÄÈÓë›ëéõäêz4*ÒPn‰Ÿ?L®‰éæöÇëÑo³.®g½ÈÃc	®PÞO¿üƃN÷Ãg*Kuðœ‰,“Áú"ÒŠéH)O©.î.þÕ/8µSÏ©)â‚	©U0±f	�åóûÒöu]¡2&¹ÖGû¹é”Ë”%™V½ò#1P¾ˆK•ÒA¢3+©¬ö㮉ƭ©–¨ ·7@ÝÏH8ˤB!�󲪚Çœ!»•¡ΦÞf;ih~å\~vL
¶i8w¼»M‘w®?¢6¯]gvõ‘:‹¦6‹®lj”vÁ2­¥ai7iÖ£±ŠR’BE^
+$Õ¦{l¶¿¹Ùñ™Y‹fK2·›¦.ÊúžÆo?>DÄ�ãsBnV8SZ„³UÙÎâ(¤V…eÝ™º0QQØæ¤?d˜Ü	%ÄöÝäòŸ×44�¶¦kg‚ä »ÉÚ
+
+ÊLRaæÀº6²TÁ½®)*`[7ŽÐ–÷µ½LHŽdAl™Œ)ŽØIÏ}}Üšíƒåv-¯C
+zª-ÖlöÚ¢^ÃÕ€ÖxùÁ,¶çΉê´ù9é«u$8Ò÷àé0Š&Qh“˜$l›­ƒ™ë]Õ•›ÊM·º’N'HؘíºìÈbá“"
+·éÊuù‡C�åÜmñ
+[·YÏi>çh÷gc¿÷ûùŸ‹æûLp›ö™|;w̤NêÏûB¸ô/qÛvŒnãΘãúFE�Ç"	—à¢3fÜÞ»
+o:Ì°=ÿx8á4Å>]Ï{çÞ=Ü;²@‰xRs	Y<”¯Ã-Nš<×+’@ÁÏÀM‹CI\Ð9,õ4ŒsýgUÑó¿&ÀɺϪ":–	ªa¦°ÄxQ=×+’œ®†’¸
+Š\&3ÈpJˆ™MÖCÕàå��|˜ïx7Ù–A^æÂØ?Ž�Ø¿íI(õt’Æÿ«Rsàe¾ ~v3ž}°”:a±TÏÜHÿ`)cÁ$9…æ±öMn
+‰dÇ õÑWîÓ„>£˜ºGç²õ)õ®.N_9 "NbH“‡Ò~�öR±ìÅçç“%ýŒç•Š�1hÓ¯(5ʘÔQF¾’ôÑ8Žb^¢ú²84õ¢¡ÆL‡"ÏËŽòjg¨ë¼10ìkÊÖy»4òX«Ñ¥Ð#kªÈó³c³9,i^¸©�
+¾N­û›Šð¨üKž¸üŒgoJ€¼i&_…¿ÔP§Eô¢9›ý¥3î@Ÿ€>˵C´á¸*Ñ*;ñÊN4€�ŽWiÿàdOÌéSIwã@Â÷ì{kvÈW?_»º´.PQŽŠm×U6ðG¾¼réØ6Ûr�oKû¸Ÿ»Ö8†¹£$AD²åι„aepRÅdÓ†º”BÄuúÂÇ^T!v%~®èyž‡Uc¡Ø樴ˆ_·¦ÎülŽi·-|¾±l†N§ô¯Y«fW‡9IQ¶‹Üå§/ z—¯ƒàßê ³aY*_ó?"I˜–î½aQA�
+pè*Må3u¥¿/(ª`-òfIvR7
¬u*÷láÿêê]endstream
 endobj
-1414 0 obj <<
+1488 0 obj <<
 /Type /Page
-/Contents 1415 0 R
-/Resources 1413 0 R
+/Contents 1489 0 R
+/Resources 1487 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1382 0 R
-/Annots [ 1419 0 R 1420 0 R ]
+/Parent 1499 0 R
+/Annots [ 1493 0 R 1494 0 R ]
 >> endobj
-1419 0 obj <<
+1493 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [312.8189 214.5127 386.4723 226.5723]
+/Rect [341.1654 298.8688 414.8187 310.9284]
 /Subtype /Link
 /A << /S /GoTo /D (the_sortlist_statement) >>
 >> endobj
-1420 0 obj <<
+1494 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[1 0 0]
-/Rect [406.3277 214.5127 479.981 226.5723]
+/Rect [434.6742 298.8688 508.3275 310.9284]
 /Subtype /Link
 /A << /S /GoTo /D (rrset_ordering) >>
 >> endobj
-1416 0 obj <<
-/D [1414 0 R /XYZ 56.6929 794.5015 null]
->> endobj
-474 0 obj <<
-/D [1414 0 R /XYZ 56.6929 424.823 null]
->> endobj
-1417 0 obj <<
-/D [1414 0 R /XYZ 56.6929 392.7174 null]
+1490 0 obj <<
+/D [1488 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
 478 0 obj <<
-/D [1414 0 R /XYZ 56.6929 392.7174 null]
+/D [1488 0 R /XYZ 85.0394 509.1791 null]
 >> endobj
-899 0 obj <<
-/D [1414 0 R /XYZ 56.6929 362.8617 null]
+1491 0 obj <<
+/D [1488 0 R /XYZ 85.0394 477.0735 null]
 >> endobj
 482 0 obj <<
-/D [1414 0 R /XYZ 56.6929 306.2038 null]
+/D [1488 0 R /XYZ 85.0394 477.0735 null]
 >> endobj
-1418 0 obj <<
-/D [1414 0 R /XYZ 56.6929 283.8925 null]
+954 0 obj <<
+/D [1488 0 R /XYZ 85.0394 447.2177 null]
 >> endobj
-1421 0 obj <<
-/D [1414 0 R /XYZ 56.6929 197.5762 null]
+486 0 obj <<
+/D [1488 0 R /XYZ 85.0394 390.5598 null]
 >> endobj
-1422 0 obj <<
-/D [1414 0 R /XYZ 56.6929 185.621 null]
+1492 0 obj <<
+/D [1488 0 R /XYZ 85.0394 368.2486 null]
 >> endobj
-1413 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F53 962 0 R /F21 658 0 R >>
+1495 0 obj <<
+/D [1488 0 R /XYZ 85.0394 281.9323 null]
+>> endobj
+1496 0 obj <<
+/D [1488 0 R /XYZ 85.0394 269.9771 null]
+>> endobj
+1497 0 obj <<
+/D [1488 0 R /XYZ 85.0394 89.8526 null]
+>> endobj
+1498 0 obj <<
+/D [1488 0 R /XYZ 85.0394 77.8974 null]
+>> endobj
+1487 0 obj <<
+/Font << /F37 791 0 R /F41 925 0 R /F23 726 0 R /F62 1050 0 R /F53 1017 0 R /F21 702 0 R /F39 885 0 R >>
+/XObject << /Im2 1039 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1425 0 obj <<
-/Length 2926      
+1502 0 obj <<
+/Length 2893      
 /Filter /FlateDecode
 >>
 stream
-xÚí[[S9~çWø±©Š5º_vŸ—„™a�TÍîÌ<4v]1nÖÝ@2¿~ÏÑQÛm»“ÅÔò°IUt¤–dé;wIÅÀÆUÐ43\˜Áèv‡®áÛ»‘úÛNÃn¯·;?)7,XiW�¹<ãÞ‹ÁÅø÷lÿýÞéÅáÙîPžY¶;4–go�O¨%P±ÿñäèøݧ³½]§³‹ã�'Ô|vxtxvx²¸;J	¨4Å¿>žR§£ã‡»^ü¼sx1_rw[‚+\ï¿w~ÿ“Æ°»Ÿw8SÁ›Á#T8!ÈÁíŽ6Š­TÛ2Ù9ßùÇ|ÂÎ×8ô)˜4LH£CÙbý¯Ò/pøÕDJÅ®sùGaÓŽiãy­|�¼Tä…VÌ+eÎf|CèÏNügow¨ƒ…ÊM±;T^f³]á³¢®î#1J­ã¼É
`ÇÍ¢çU5»Í¢«+,EÖÜtUÖT6_ïÒ·?¸áùtŒ¼xØ 1¸%�„Œ¬«Û¢)o‹š9šäu
ƒUë»bTþÁ¹±Uöj௳Vº°<j¥=S µƒá‚Ã}"ƒcw+"óß�j"l`Ê
‡Ò1î–Eí‘SÜ2/ƒ
–Y¡ÖH«TÓzî#ü‘ÈôU5™T�åôšª9É‚þÓ‘^Òp\²‡•ÇñÈéšz-ý l$	ê…"ƒ³>ä“rœÔú¬þÛ*Kç¢nATŒpîÅ
-Lze	?€ÌJþõè	0`eë:ò„Üe4i%«wù¬)óÉ7P§è ’³¹¿ÂOèn¾,\z/šnº^Ê鸤yGMY¡"B ÒT©Œ
-	Ä4¿MÔãM‘,TÅ¢GZ[Cµèi»,­põøÆ‚�Kº£žÝÝ
-i¬²b¸1HdÄ.&D�´EÛ/�AË]MËQÚÉ—à‡ho %Zv¨CŒ�GóâõìÐ¥L]P ×—ÍñZw‡Û²%ÂxÉdÊvÄZFè !ëK•Án@*äÈ¢$>Àí¬¸›ä£Èƒà²¤4²
èqu›G�N<
-jœåik5O]óÔÖ3i;RlTÅrLßóš¾Ñ/´’
#ô•OD4mÙ´9kÒJ'}Ñ´´N®—îŽØ<O_ÔÊh“KÝge4ÄÞZ�¤ûü—ûUàÙyS%_‰Q\ˆƒâîþrRŽˆþ\|M¾®«Q	–|L’d/FÕåõ´…~…ÿª¦Ó?\/ê›™¥¹Ú]vaØ–)z�èRk
a£î‹.5$ÂÁØd‹Î1õ‘f‰S"$%Ád7y}Cª–9õh™ˆM‘‰ñ[‡‰Ø‰˜8eæLD™¸–aKŒ}÷:°l7(Ýj´¤•*ˆ>î)Ë8Œˆ½;ýüÓò£ó¹c¨WŒ×õ¤ºl#¦»ª.1�HÀžßßa:«‹qîeÒÆ÷7@ÚYë+’4÷Ìh˜¼RÏu)}|rô0^®IÂ%P�Ø?ýDeí 8È	l¸¯#”@E(áKNU<RCß–“]ø:>#Zênu»&j«�P‘YåûÂ%ÍaBÏiãǧç‡ûÑ¥H§tvÍTõPŽÉTÍíÑmÑÜTɲ\�1#sf-†+X9>­‹…Áš7ß‚¹šÅƒ¬!3’qzò,R|×Y¤ær·º0¼b‡¢,gNú>“¤œeÒ†@Ü:?8�D™‡±mr)˜ýÒ¹…‘tÚdðô—ºÊ¥ã¦3
-! þ\ÉœcÛ3\üæ“‹îV·Å‘8Ý„(zȾœZÉ”	&ÂU0ZŽÆ [<‘‡¢uäHGG¿u9ÖÉ‘wFÅ	Øã=©É>Õm÷rº^w@#¯ËitI4è÷ß©BË‹)јZ¢¥ndhòÎÐËï¤òÙå}óTvQ7å$ù¿dœ�JÑ%PçÇïðt“ãÙeoÀQÏ�ÌÒ©-4ÈñÖËW‡qÛ= Ü®}Ã@7ûäKX¦Åû¿ü¤PbÕ[‚
ˆg6¾�ð�±_F�»]ÇDªÑH#Ѥ£uŸÂzãZ¡Rjùh
ºl’¬Eò%ßÀŒÎ._qD(½g!¸>ó+!•4^QDa¨"D/ÙQDlæÜJ b<§ÖrzUÅ£wµ0t‰Ò.}„w6u]¶Éëðí.ü_�3Ü>c*=gVz
-i‡À÷iG'†…‚h¢œÕŠ;ÕHÚÛkS0?õ€ÆdŽ¤j§–®I‘NnôjƒïK·<Óx`â^€ß'�Û¤zŒZçy¼ŽÅæË¢�°']Ø@�îå£àׯTÒba]cS: 

-ùævžx$$€j‘øÎ|.8ýæ‡îv»œÜ–u}	…Ö‚	guŸÀAŠ—(æÉÞéŤ#\ñì„€G§s¡î¬l¾¶Y]9^âÓ›8b¢´TóʯÀ<1)EŸ¿’�¯zî(B=9ß;D���ŠiÑ<V³Ïér¶˜=”£èÑhq̓(¯àx®�7ßp›Þ]ø+Π%7L‰^$9óFº/ÆÖ§?ÊÍ¥5ǃdjJ6(º¥$šL¤òÉ„¨ö<:³$Ôj]  —�»±ØÞ+¾b¨Àû„\Ë‚–:qáp?žù6(×±XÎãfªÆçPBrLôè´?—x·–úÝÄ—y@��¥¡)+
-®û|¯LiC‘M�U!¾âÔzÆ
-™y½¸'Ž=òYCT¼¢Õéâ‰6=A:=(ÓéR�{‚zÖiÜF¿ÜÙúóÐăd'-æ�À)ÊHWß5óAï£ï}¸¿øÏ`d•÷k^ÍR8ÂåÜ*øJÅx9ïÕYú
+xÚí[]oÛ:}ϯð£4\~‹Â>¥iÒúÞÖÉÚ)°»÷ÞÙV¡Žåµä¤Ù_¿3Ê–]ÛJÈö@9Q4uf8s8TE‡Ã_Ñ1–ÙD&�8ÑÌpa:£û#Þ¹…{Ÿ�DèsRw:iöúx}ô·w–Xi;×7�±ãΉÎõø�È2ÅŽaýû²w~|"
�.º_AJ�}9½º>ïÓ
º~ìö>‘&¡æì²wÑýü½zëèº{Ù#uÿüâ¼Þ;;?þëú·£óëå”›¯%¸Âùþçè�¿xgo÷Ûg*q¦óœ‰$‘�û#m3Z©Z39ýc9`ã®tLš&¤Q�¥™ƒßÎÏ*íXÌã?Ë;'R±Dp½{,zŽÃXA¤'ÔÆP'‚'LÀ?`FeX,E²4£T
3
+a˜vq'6‚IF3žŸØX[l•TÑ]QV$¥ãñüX¸(+K4žL¢î”îTw	ݵ£IZ–@Önæ%i©ÕQJ—Jžó0v÷jËo€¥;±f‰1ÞI�€Sü”•£y>ÌÆäù4øÈÅ	
+W_!ó%¢ÓõuÍ×ÜŸ4“¼¬BÄÝ„}„�E´3+!÷¡Ü˜þ¡âpÝá�(k‘Û”µbÖÆäng@U]ƒ»'@¿“q
+#d9kÓ!XˆñЋ
+d1ï½}FB›wKHG{¼»á6¯sÅ7MFrf¤k‰LFYÆc"Soðûù¿ÀÜ*áÑ *ÍAú�x‹A3['ùˆäÙSHÎ�ˆƒ7‚g¯ž*óÛi
7ü
+)ÿ[LWñæd·«·„"®ölš(6�ÔXÀv˜®…*!™°<„¢
nY¥Y3”H‰‰îÒòŽ$\ئԣ¶!ª¼
ý½µ¬¡ƒ
—O™¥
QFn±…„5»¾ÆxMT»›8(ÏÕNƒUz¿ñ´s�=@Ÿ¯.Áxð˜�ˤPn®ÛI1¬‰î¬(sÜöT‹Yéf¤¡FvVâ×˳=x6&úŽ©­¶œÅ°ÓjÁ3¶L&ÚyD¿t{—
+ÂÙÕw¨Ò‹
�
+"`(y$áNJ—XÅ´‘¬(àŽwfèø
+’Û|ÓwLr5$	§eÜbØ•Â^€\¼{58?óÉDÆJGW>B@j˵PtŸUwE*�úB¤�ˆh¯�‘Êl«–ê{ˆTs_kÃ+´EˆK¯(k.÷«�Â{N%�$%Û¢‘tLÇšpé>õŽO71’Ú�L°bA¥&#©>h°ZO]åZ�0Ãm @<7ª^÷ŠÜ¾¿ØÔ|ÓCä
ÊÑ*Ž·¶…ˆi®™±ŠÂ™_8
+�Iã#(u£@ƒ7æxD$•‹†‹jÛ®¢¬òIÈ}!2ƒX%Hƒîg,Gs,6·2�rYõ1kevP%jÏ.¶i·ÃV”ºÞ•QLÛB•uÌ&Ž¨ãïÿê(”ØL•°þ}™ÍÕÌûs{¶[¿�3¡:�B]5p�ΛxY>Pëå è²Ï³V›.©øc4ÞòSA¥“\´_;ÈØÑRˆKtá±…€¹LR&À¤Í§7…?)QkðBïëÒ(A!\lC×õ€¼ÝÆ´ßñÁžâ†A¤j‰¤JIæ”$x¿�«›Düâê˜À°Q@$ò	Iµ¯Ó¹z}Ä�,K ±HªzaéHå�Boöä½p&7õU'¢‡t²"F¶Iñ藜㾪‡êaV
ã	Çkp}SL°×8Ü}¢–&�Ñá=ªBU$Hâ[bírÇ�
 endobj
-1424 0 obj <<
+1501 0 obj <<
 /Type /Page
-/Contents 1425 0 R
-/Resources 1423 0 R
+/Contents 1502 0 R
+/Resources 1500 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1382 0 R
+/Parent 1499 0 R
 >> endobj
-1426 0 obj <<
-/D [1424 0 R /XYZ 85.0394 794.5015 null]
->> endobj
-1427 0 obj <<
-/D [1424 0 R /XYZ 85.0394 695.8713 null]
->> endobj
-1428 0 obj <<
-/D [1424 0 R /XYZ 85.0394 683.9162 null]
+1503 0 obj <<
+/D [1501 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1423 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F47 879 0 R >>
+1500 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1431 0 obj <<
-/Length 3069      
+1506 0 obj <<
+/Length 3252      
 /Filter /FlateDecode
 >>
 stream
-xÚÍZYsÛF~ׯà[À*	Á¸6OŽ,ÅÊ&²–b6®Mò
-øZˆÃ»Ò
ìʤT~ŠçÜÞôB©/àH^k?Hƒ�ä¥êI^ˆÐ×I<ˆÃÔ�t¡äïÞ
/"8Žw×EâÕ�ÅÌ´ ·$öÙrYTsnML÷dLE�Ñõ%‰”DdÕŒˆw¾æÍfvQÓ¶¦õQúƒXûiJ8´ ÏðÚ´Ó¦˜˜髨Xov ¤ˆ”¿«<Æ ¾^§÷ÒŸ'H¥_�M.Ü€—Ô�„‘I OèF…~,Ejå2º³º‘ÞMõP7‹¬+jM,=÷\š¦­«–,ë%0ŠIiˆ	‘P^—3gV/²¢Rqì]}€%pÞÅ>õ�sSuY‰3DpRYB$ǔՓÂË*K¿¤²¢4òe”&'”RJ„ˆHY£û›†:Œ”wYƒÀ
-Ô‹N„÷úöþþêrRئôÚb^eÝŠ´E¬YÖe ^a_¾Ø…òÅ'Ê÷ é@éÃ2ï¿ÌKÉÌ4‰ÂÿÇçÜŒÃ2�
-¥¨0¶R±Î&iÚsF
-Þ4<¢‘Þ«~Å!PG~,’!P˜J_†)…@÷w×èƪïÆ:H¼n(<TÒ÷¦šAc黺,¦ÏD_7ÙÂ0ÊB³èQÈ°^ƒDvÏçÅ£a�16•DnB¨Oˆ
-‡�KÁPŽß�ÑÓ@Ìãa*=ó¡#yp8ZÛç¬ýÔ$îèuÓ?Þç½òõ�*ˆOÝ6
-ìIæ+F2
%E|\�:Ñ~)mEùN†.„±72KΩ0…âk'Q62Ãç;‡"µ¹h ±›ŠÅAº“Šýí*ÖñL¬ÿ²/¥“MòTYçÄA¼SÖü{³ÜA¼‘ŠAgÝúpon•C?*‹ÂÝꛄkHø‘ÖÔîj¶
-‚X«…é>V÷`H,üX	{Ä&{ÊþŠËoJj!Ox¨‚üH…œü½�@*`@oÈi†²M´—ÙRÇN*ŽŽ’¨13�¦¬—TIlÍŸ`“ß´Dr’ò_,³´ÂW`³ó Fön0Õ”ÒÃ"¼’Î$‘cÓà´ù·íÀ­|ú]¾
-}�YSÔ+^©}nwʲä•�Yð}€5ÅIÖ®-ìãxNÓ¸Þ9ׯ—Ža³èߩѵ5=ÁÛWOq/e__KP
�€sûÄ  Ëd¢ŽRÉ‚4Ù
-@{D$«lÁL2$è|èLŬŲ,¦Eg¸‰×d`€<x„Ve?G`Ã1QÁó![K[_¤ÅÝtÞu4ò‰¸®yeó!ƒm
ï¹Èªç}XHçF$´ßtC»oSe¥jèÄÃÕ‘/gÁ¸y†)>rZ�x«©«ž·ëx~ÎS{;/³©ÅõT¹¯ÅÚ›æ”Ç$XçEà­aÉjTõÌâZh«‘=/G'À„ˆ¾óh
káSZQ¶ÄÚDeÚs5U†Âû`ÁÚ¹Él-a™©{^Ú3kE#ÓãñOXW¢qœâô‚7›â7Ø,££6Éd˜/Ò	ÝZ$mË&8Ñ%Ãï·{@…LÝ7zM¿tÀ¯ø<[Ù"¾]×•1.RuÁíºo”;1$XÄ2—äøîxÜÇ"‰z.§Y˜Œ”�õnkÅ1Û2@zıõõrF
ëQЛñèbÁÃËbQtÄ´`ϼ~⾚v¡»9¨zlO3;áeÞ›%¯RT[;M³inÀÄ"¡Æ¹;íºÇÜfµ­ŒÅ‚¾ªüx¹´…°˜«cÈâÊ?Ü �†ºð ŠÀqÇwøx÷ñâYÙòR(‰1á
-:Çšµû<½·1I×éð�U™³„·ÄÒxáÎŽ¹ïÖ²«¤Ú
ó_°Ë±ã‘ÞRVºq‹ŸÐìáRþ¸•êÍÙ Ü
+xÚÍÙrÛFò]_Á·€U"‚9€lžYŠ•8²–b6®Mò
+o­B+$}¤CÎ×”ç¢Cy&E¨…ˆ{
+ÖIô!é¯?Œ€V’‰à·Æäý�ÔiPVøÔÁ›ëÛÛ‹sµ5=3Y.úLfúäGçå$k�Wd-AÃaCÀcÙeò §d˜Æ1žœ!ÀíAêÇÊ,`gA•Íp5Îé$€Éè11‹6#_�b0ª5‹‡lJø¼v«Ô-
æSÙ´Ûëá9¢Í|®+XPÄ	œ3'`ýnØz´ï†ÐpHÏöinU�U?§Fc*7á®^ø¥éi5Ø<)CY̦݃Ҿ ²”Üñ‘ø<A½(ïË
+߱ĩ¨A{ϧÙÄO?ÑóÚ²Ó-³ƒ´Ì¸l`[Á¢à�i&‹rl—
%²{£Æ]ž
+&Õ¥IÒ4Ôq"-�nFC40"
΀PRóÚÊ 5PUð™�9Ï-Aõ�Vòzf…aj„š9ðí0û�ìR’—Ã,‚w?À¢îËA·y$_”GIÊHŠc<Rq˜Ê„Èró¡?H@@ƒ«õC™£ªr­‚Y6Ÿƒ–¹ÖØ´�ÆTÔ º
 9'ÀÚ>À"‡Ës§à�iÂý6í¨þ°D`Nç­_–9/«@"	e*�ñ&æàmA·‘.ÃË\U`gY[ÖHÅÿœ›ESW
5­ç€(ÇSCHkQ¹¤Gˆ!=BÓ¥Tpñ	–Àyƒýì)g`Ÿ³é3�cú³ÖTxͼb<Œµ8jì¸Æ …ŒÝpx{õ¸!°wÁy]¡¶Ž�­Ý6yД÷UÖ.½DTžµ�—EQÜ¥/vQ�Á-}÷rHFB yçm^Šè`-uÿ§ågì%z¬’P1Í�=’!gΨûB#Ô
"X/[3h2dË{ˆ¦¸ˆƒ1F'6X.À@ ¨›¶!�b1„0&§�‰ì¨ìÁøA¦tS!ÛÏŠ¼$ÆN0”Õå† ù`Œ&£ sZ/>º®MC9Ð^3ת§•^ù·èoy¶ƒúØ%ú×1òÛʆŒ ¬àÇ2Nà2M,Y¬:Æ:M;ê¨x´
+×ÞÒEDy]D˜âI„�¬
+"âU<¹ß™ùS°x+Æ„ÂƘØãÌ¢lP¨•�8…¶`ÁxÙÒ€¦-§S³Äí�
’k`7¬úgGü±£»Yǧ‘GT*Ø
©é°ã¥¤æÄC1K ÐáÇâ¡XðPjI„¼}†‰Ø�«t¯ü3Š¸
ˆ[»Ð¦µaªõÄwôÌh%G˶
+“DPLt;ìÇqð/L¹ÅŠòƒqmM\¢ƒGc-@+ô¯\ùHl4fñPNl
Zhã:Ƶٯ6¿ÿrël!râhª¡4?À©
^q(e!;f÷$$N*Îîݾ½¼ÁÐbÍíT0¶ÖM'ÁcöDmÌݱYæžùr<-›‚º3­G¹Y…å6v}4Oß5„EK[HCîÍb¾(«ö¹:Çãæ²K¢—â¤?ìó—ô3ösRˆ�Ç�ªá$dUZr²—#[ªL €õS˜O-ÄÅ¥µ}æÏ­]ö:Ýó}Ý;[Û¥BV}„Œ\†Z«ÄÛ
 #fÎv+æ±·[>å¤@0q&‘΄!¸2a8›°ÓýBÞ,q9Š¹àìö×ÑMŸñ48¥¶ËVpD×Ü,çózÑzæ¾-›b�	f{YØ¡Í+v?ÎQÙ±¢½Œ¢0UŠˆù�Ç9Ä*šN©Ù{ -¨ÈÏ!Ehís ±�—©(ÝÊËöF
_W&é¾íK1e}Ûrìúç¨Hm]ßü³üA¸N¡€i膑ڼöùâúGD`Ðxª0™T@T½‡ïþnJ@BñØ@¦�ïêé´~ÄÜèüý¥H;3	§Ô¶Ã)“i†,¦q;ð4äBãlP¿²¥MMnmbvZX§¥+Ï
ðƒÔ¬Zë0
õ�MË-!iý@Fø�mY©„@k•J¾-G£oâñãa©cz.˜­#’®]]÷	Þ­8…× Ê4¬³ÏKy®oPøà
+´EË—D$ÃXèÔÝãmX¯ó"« Âé:C… ûÝ^CM±nëI=%ÌÄU¨Zkµ0@o©ã׫!¬„‚$€Y™Xª¢CåýaÖ	™ @¾8
¨ÒÖâ
+Î õÅBñÁ¨‚¥e9YGŒ�ûAw
�õáÆuÞµ¦r¨Ù|ZNÊÖVsu°ÈÜ-7·1¼„Re/'°á‘Èàûš@l¹+q»¸ŸîvC.k·²ù”Á¶Æí9˪§]0йQɺ,ß
+V•M)——öpµ¤†ÆYcØ"£D2| ƒåÄ—Ò›Õn~á¦vvÆ‹ûSúJÃ]Ë`RP*£cú.qðÖ°ä5ª:·‘¸dÒrdÇËÑ	0'¢[Éìw(\rKʆPë°LúÂ.
+Š<½Ã�sù N/ÝN¼�mZû�¶‰(0 ³E{<¿BÚ/ypš–ïrwX’Ôy<Üð
}ï…gî<Ù"¾ZÛl˜•1>Nõ¡íªowŒ;6DU4d>Å	WÇÓ�ƒ¸H_à43“'°ðmEXù¯:
+u¸ÁË4{8÷)>Wkd9Ø9P0ƒÖV¥Î:àÔ��z,ÌÊý®—žn€r7q-%æ +¿åt§Ah€ø¨šá©‚¬H 06ôtÁ¤f®¸É<ð¬ülü„	Òφ.©·X¤¨ðøLÇ­WÛàbì¢S„ûÅ:Î02Ç)ÈÛÒ¸‘V#áé“™]ï67˜T¨4Ëû{ӸȄ´Ÿ Ó¸(B�\ÔË©|Æ®›î�\:K¾‹;'„ß,<¹Uˆ�Ý)`))„ÇÞ´‡T
 endobj
-1430 0 obj <<
+1505 0 obj <<
 /Type /Page
-/Contents 1431 0 R
-/Resources 1429 0 R
+/Contents 1506 0 R
+/Resources 1504 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1382 0 R
+/Parent 1499 0 R
 >> endobj
-1432 0 obj <<
-/D [1430 0 R /XYZ 56.6929 794.5015 null]
+1507 0 obj <<
+/D [1505 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1433 0 obj <<
-/D [1430 0 R /XYZ 56.6929 420.9025 null]
+1508 0 obj <<
+/D [1505 0 R /XYZ 85.0394 337.2163 null]
 >> endobj
-1434 0 obj <<
-/D [1430 0 R /XYZ 56.6929 408.9473 null]
+1509 0 obj <<
+/D [1505 0 R /XYZ 85.0394 325.2611 null]
 >> endobj
-1429 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R >>
+1504 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F39 885 0 R /F41 925 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1437 0 obj <<
-/Length 3129      
+1512 0 obj <<
+/Length 2929      
 /Filter /FlateDecode
 >>
 stream
-xÚÍ]sÛ8î=¿Â�ÊL£?ôÁ{KÛdÏ;Ý´çzo:·ÝÙ–m^eÉgÉIýï @Yv䶷ۙk3SA$ 
-ôûŠ¢hnV?:çH|4NòL³tâ€UÑ„ß^‘9à/ëN`‚xC·*ÊÊ¡…F@ì‡^ÓpþX[ÏÕffW{<bƒ‚³¡ç1»n›�Bb(í•‹àQ%îõh/ð²°Íj�ɪ…Âbч•7!© ©{›á[L:DjåS~`kQ)‘æà
-õ&·Ì–W¡Äjê3Ÿ|±à<¬9K…ÜGO/ý�/ëjA© çGãwhP��s,þ\ÅB@~–Q)Iòu©pU´ÏH~!ù�ùãê$ñ;&yÌMc?w¢ù¬�¾Ð‘½§úLnÏx‘Ï×çÏÄ“OEYÑ£¢‡+ï©~ä
-fòÑ¢xžKÊ$4 5
-•(d�.ÀÂ7¯Þ‡¿Œ§œQ‚#ÓfMàeI,Ü=€Z?���`ìïýWc ùÞ÷ÀQC:…Œ.\�Â(4Cd�RÉm€¾.DpTŽÂ½]VJo»ï¤”ÿåbøþv+RÈ)ébˆC�$Ù7^JÊPƱúòÅ 0Å’8æB‘m¾€ºÓ‹jÅ1TRoáÔÀë…‚Žl ‘�£d‰`ô—‡Ý…]"ËÂ×U»ŠG[×L鮋%*13aÐ.ÃÔÇ`l§øfÊkÛÌ÷­¼,]t-æõnñ
m”[W…“Á¢hæ;;swÖ͸†¦Ì1îâ8u
xM×k 9[Ñ=D×.Ì猗wkmÁCTTµœ¥Ñ9ÕLJ`ýöWÓ½>pÝòåçJSƒr¥¶ÖÎ÷®¹àÞmáŠ7
-—5[<£¹u%nÞÁ¦âJøsöÉsI�íÎÖ®–JƒÕÂϨ©3�röìnOâÆz´tÒ—³¡ùÖ#öÛyðJ4“.õ‡!'=�=õ nC¸yǽm‹Út*¼™öwÁÏ
-ÃíxxÚUUMGƒÍ�+¸¶sÄ#ßsÊŒD& rb�4DQÇøýô~0ƒð¶wM:.*^åÒ‚�
-Ì€áÀØ»³½­tv8kš¹ƒ
-/ý,LÁw—RC?âŠF_ý`þÖŸŒ6§ÓPe™þnë¾ï˜)'5çœw¿-{Îúð{¼£endstream
+xÚÍ]sã6î=¿Â�ÎL¢?ôÁ{Ûf“6�^Ú˦7;×íƒlѱneɵädýï @™väì^»w×ÉL’  
+Ÿ%àâS±Z×ΡÅBxªÊãEïo®h&¸}q¸72‘…&�ë]m¬VU
²s
´J÷]=B‚íûpü®Š®·Œÿ!Ž¥ãϘmwÇóHN¥=XJL»eûìe–æ-¨¨é™Z~Á
+4WlzÉ÷)o&Ê­Œ�œ>VOd-Á(l“ìodæý}DÀ-�DÇSTÓ™}¬&ù\õË
+2…Ç-ªæ ?�Æ'�ÙuËŒxÚ†Ò^¸îEâš{{�FYuÿÂ�dUŽ›Ãâ­w+Û/B»F€v,†­„dˆÔêçbÇ00Ö£PbÍÎ
ðnïB®OîÌ—ÔÀSQo?wÚUÕ÷Ã	 è³ò)Å™Æò—õP�ë»Ã“
+<nNœ,tyzˆ’[̹קžš£©~™qê0ãÔìõ¼¸qÂ=}÷û†ºNžà}4€›ö¹¶å£=A
+4WÍ]ž50äÆ#Õ‘Äp[£â¸ñ¨,òj=ó¼$-ì)¢P¥Ð—„Éu .Î:!ÉíŠÇÁÅþõøžIE$\+’8ƒ;“”_rSQi¥©Lo*¿o–g$âIh^´ô3I]›ºÔ&‰Û_ƒt˜i‹ØÀ%É艆ûb&Têtrûî6º~û3ÃTåñôoïÏ/3•IH¿ Rð\ß]ß¿‰´#�êT
¿™šKÿ±Ý ÜÀÿ;òÉ
ÊD>. )ã(7)ì%O£,ÉéÒðR"oÞò8-Ž`¥¯*ñUå‘Á]K¤Ÿ5˜LGy¬èâ|h˜«ƒÙ€¯ÊÊH摉€%yZ2ÁšbKIÐ*
+',%•Q®ùî:

$¯È  þ'–�Î"§êsÖ‘ 0¤!ë$y¡m
+€ïßG?\½‹þvûÀ)¥4Ýè0o‚C–‚_Ã8€Z¿t�pàM
Öþ£.Ð|åð¸„XgêTБ°2Ä3œ@Ññê»Pbº—öJ-ãÓ2	–ûJ2ùOÂÂ×·Z‘H�0,(eF˜/¨æIj^pf£X˜”QÕ½î~ø4»w”ô´px2	ù
+¥¦.BçÁK´9ÅÀ‘Ö) ð
+7¯à”©¸þ’=Fò\Òg½©ZWJ¥Î¦ô£c¥{o0:ãÜÙEOâúZ:
÷ÙÑxïÃ×<hÍtHü¡ËížÀ@<ˆÛnуº×½-Ѧ3áÍ4\/
pÈFŒÖß°ÜŽÜp5<¥',e8,Á0ïÉ9Cl5ùÜ×Þ
½.‘¯ÐìÃòý£- T<}>�\R>Ý€´ÛUí«ØÁú9x&ì}¸[»ç/}ïfö’sFÇùàÃ×mSòCÆðTžë)	ñz`°Ük!4‹GŠ„9žÜšqApÇ*æy^Ë_O²±Ÿ˜FMŒ<:LJCÓ¼-âéOƒ	áÒSGèe;f“äŽÁ©Ñ=SJF¼£®bÖµõ¶·ÔZÙ¢¡’<à|�2£nàÔ£‚’æدI|à­Ñ/­~Q·qÄâŸd
 endobj
-1436 0 obj <<
+1511 0 obj <<
 /Type /Page
-/Contents 1437 0 R
-/Resources 1435 0 R
+/Contents 1512 0 R
+/Resources 1510 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1445 0 R
+/Parent 1499 0 R
 >> endobj
-1438 0 obj <<
-/D [1436 0 R /XYZ 85.0394 794.5015 null]
+1513 0 obj <<
+/D [1511 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-486 0 obj <<
-/D [1436 0 R /XYZ 85.0394 769.5949 null]
+490 0 obj <<
+/D [1511 0 R /XYZ 56.6929 729.6823 null]
 >> endobj
-1439 0 obj <<
-/D [1436 0 R /XYZ 85.0394 750.0533 null]
+1514 0 obj <<
+/D [1511 0 R /XYZ 56.6929 704.98 null]
 >> endobj
-1440 0 obj <<
-/D [1436 0 R /XYZ 85.0394 564.5091 null]
+1515 0 obj <<
+/D [1511 0 R /XYZ 56.6929 519.4358 null]
 >> endobj
-1441 0 obj <<
-/D [1436 0 R /XYZ 85.0394 552.554 null]
+1516 0 obj <<
+/D [1511 0 R /XYZ 56.6929 507.4807 null]
 >> endobj
-1442 0 obj <<
-/D [1436 0 R /XYZ 85.0394 384.3846 null]
+1517 0 obj <<
+/D [1511 0 R /XYZ 56.6929 339.3113 null]
 >> endobj
-1443 0 obj <<
-/D [1436 0 R /XYZ 85.0394 372.4294 null]
+1518 0 obj <<
+/D [1511 0 R /XYZ 56.6929 327.3562 null]
 >> endobj
-490 0 obj <<
-/D [1436 0 R /XYZ 85.0394 286.7057 null]
+494 0 obj <<
+/D [1511 0 R /XYZ 56.6929 227.5589 null]
 >> endobj
-1444 0 obj <<
-/D [1436 0 R /XYZ 85.0394 262.3661 null]
+1519 0 obj <<
+/D [1511 0 R /XYZ 56.6929 200.4217 null]
 >> endobj
-1435 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F47 879 0 R >>
+1510 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F41 925 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1448 0 obj <<
-/Length 2766      
+1522 0 obj <<
+/Length 2732      
 /Filter /FlateDecode
 >>
 stream
-xÚÍZÝoÛ8Ï_¡‡}P€ŠË/QÔ¾uÛ´—Å6é¹>`qÝ>(¶'K^KnÚûëo†Cʲc;éµÅ
"j8’Ãß|Q‡?¥†™\æQ–k–r‘F³å�î ïõ™ð<I`JÆ\¿NÏ~~¥²(g¹‘&šÞŽdYÆ­Ñtþ>6L±s�Àã__]œ'2åñ«Ëß¡%”NeüâÏßN/&Ôa<믗W/‰’ÓãÅõÕ«Ë×ÿš<?Ït<½¼¾"òäâÕÅäâêÅÅù‡éogÓaÉãm	®p½�½ÿÀ£9ìî·3ÎTnÓè^8y.£å™NKµR�RŸ½;ûç pÔë†T“àL*#èIªCzJsft¡ž^µkÚSù©X®êò—ý-ËLf³(Óšiÿ¤=Éœ¥™Èv÷ôÿ�
-ëàQ"ËÓôÄ
-hY¾FìŠJž’LI–
-½ÅU>ÒW–2žjeÊÀarãôåÕÄfí@c”Öñ% BIžÇoþp
~žd06^UÍv†ìiW糩€CÙ®äëö†Z í»¨Kr–¦ÖÖ¨€�deЯ¡�
-Û×N´£œväÕC3ç?¸~8´88§Gô#$Èãêˆ~äX?즘ýg³bíúî„vFóþ¸Ú198 mÓG¬�£7KÉ‹?´ŸD�LÎÆÏái¦þ‰£*Oþ«ÈjðÑJ�V‘±–É,ÏíQ"³:’ÇuD³S'´�[GÐ@“³\§¨„ñl7€>¤2³L[\µI3&…ѧ©Q9“VQ`xç
-º¶†síˆt¿(jÁ&=Û¬˜¹
Cs2é0hëÕ$Ð*5æe7[W7¥—´hï©Q·î
-[J´…ÁVªÃ®ì?‡ÀÑ�YH,Üñ½»†ˆ	…—‡¦ãºèœ
©±¡)¯gÌQÑP¤�=¨Ð£ÁÕݽ·c™‡€Ã/#¦é"Œ#ëÝù¶uG}ˆfÄšIÉŒvìÉ#<Mã68ÔLuíÍ
-3¸¶t0&h6m.v‘Ì[ð”
ÑÐÇ_ýñòúÍóË+ôèDõ†ºj›®ìaþ–V»$œ}n7ì�ÝV°,>UË�çF?Œc"ÃV]|¬.îUËcE°ÆuÐ�rµÀE?L•38s‘gÑ_‡0IJâP%R�lþ%"È£ …Cgò$f¡Ÿq
I?*ö'ç%4d#¤cA˜hJfà�èüf¤Rì,zzöÄ
!¥]ýŽ#9ä>°EQÙc¹#쀰ƒÔ;˜´ó³‚°wšåm±©û=Ÿ7
-—9ÛÔ•ý	PlÕýu¸�	ý-1�7F˜Ó Ð/žÈ‘E¹´²ÛLÅ`I˜¢¥Ô)S¡±(œ¹A« éß;z’3“©O¨½uˆðR5{œ“‰ËÁÿ,ª0sȈӱ—;îÛ(ŒÃ6‚“ã['ÇÇNŽû½x‡"jhT§
-
tλ|Ñóì@±°ÄBñC…T�Öf¡Î8Rxžµ�öµÁeƒÐõð|S¬VÛçq|ùö£~¼`˜”^ŽÊ!rL•Í·Éõ¦¯Ú†zÑk÷çü�£"ƒ½®‹¦«Ï=ÛpŽ£.ßµ˜Ï½ÐŽ:Ü!BNê~NÚ±CÔ†¥Í‰Š9?R—%ÌE$:p²Q·K�?ŠªIÜü™ŽY±^ô’*0…4T«!«
°R¡¢¬‰ßN'ÔðÑW¯XTd’Çà�*­`
6>¬9ÂÞ\÷Î<C8„Že1/w%Õ%$’XÒ-[H(]…Ö¼»ê®¡0V4à¬Ü–Ù8;:U€<MV̉£.o¯rÇ‚”uu·
-ûDvÞÞÃSîÃSz|a‡
-]‰;u!QU¼ç_­j?€6�=K$¢»"Êì á&ƒæ[žs¹­Ò?¡Ö8q?-eü×®qpó<„È�9¼]’}ðwQÎæ9VHK,¤ñ6î﫤¿Ùåô�€Ja˜ÌÓ#_Ë|*±’¶¤ÀŸ®'—¯ñ:ŠÇ»¶0¸ðƒùØxª¯[ý6û
-áš)Íåi…ðŒåÒXòç‰Í@¨þÍÙ
+xÚÍZKsÛ8¾ûWè0ºj„Å“çæÉ8YOMœ¬¢­Jm&Z¢-ÖJ¤V¤âdýv£%Kv²Ijb
+åMÓ-°–Åqâ ú`‹8[ÝW¨|ùö3OÎû4×p)YRñˆå&´cÈ„i£Â)‘u“òè\åÁ²º«›�êX�'WuÛ•®ÈHÉ+ò9k vy8Èž	•»Q ´åY¨¾.gWä[Á^ç*‰‚ò#Š´uSÕÝ`ª½­’BÞ|"å D
:P�l ÀR~,VëeùË¡{Ê3!5Œ›fZdÆëÏòO:.SÙ¾úÿzÅu¶xrÔOÂX\�=ö‡Ç=�ÓTŠÌ›Þ÷Y5pàŒ…•ÊŒÒÔ
+“‚[@�±œÄ¬Y¡¿1Ö&WŒ– ¹àû“·ü¡äù8“ì¿Ä^·;�Âr½
–óuDQªÌèï"3ëD\h‹1*¥N«¬
Bc	åA±C…¥c‚tôgŠ‡fÎpù˜TøÌë	ùX)¬ËÍ	ùè¡|ÄM1û÷v-šÍÝ#ÒÌûKBl®2÷”ÉiÀ'Ò’ç~h@c³gwG�J%ð_�–Ñ`öXFJ£DžtK*œçó^FfÁð!éÓBLÿ­„´ƒ¢Eì
+¶
+Ì0Œ’ñPerÛ,—Í}¯Ý‚æàÖîÓºl÷í�¶‡ºØ¯>f[Ê€àÔ–lAØ”-Ö܃Šÿ6u“O©ÁØC€R ~.³#ëRa³ÏÂú&7"“™ù2}¼×
+`5pîZ©G
«¹f9Àïqª…vizìw/r½ÕWÿÊf÷K#›	ã½>Ž�{
�ÇÂÃöæÁ)ÆŸã0×`éÿ3RºNendstream
 endobj
-1447 0 obj <<
+1521 0 obj <<
 /Type /Page
-/Contents 1448 0 R
-/Resources 1446 0 R
+/Contents 1522 0 R
+/Resources 1520 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1445 0 R
+/Parent 1499 0 R
 >> endobj
-1449 0 obj <<
-/D [1447 0 R /XYZ 56.6929 794.5015 null]
+1523 0 obj <<
+/D [1521 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1450 0 obj <<
-/D [1447 0 R /XYZ 56.6929 756.8229 null]
+1524 0 obj <<
+/D [1521 0 R /XYZ 85.0394 685.0919 null]
 >> endobj
-1451 0 obj <<
-/D [1447 0 R /XYZ 56.6929 744.8677 null]
+1525 0 obj <<
+/D [1521 0 R /XYZ 85.0394 673.1367 null]
 >> endobj
-494 0 obj <<
-/D [1447 0 R /XYZ 56.6929 609.3337 null]
+498 0 obj <<
+/D [1521 0 R /XYZ 85.0394 537.6026 null]
 >> endobj
-1452 0 obj <<
-/D [1447 0 R /XYZ 56.6929 582.0292 null]
+1526 0 obj <<
+/D [1521 0 R /XYZ 85.0394 510.2982 null]
 >> endobj
-1453 0 obj <<
-/D [1447 0 R /XYZ 56.6929 540.5567 null]
+1527 0 obj <<
+/D [1521 0 R /XYZ 85.0394 468.8256 null]
 >> endobj
-1454 0 obj <<
-/D [1447 0 R /XYZ 56.6929 528.6015 null]
+1528 0 obj <<
+/D [1521 0 R /XYZ 85.0394 456.8705 null]
 >> endobj
-498 0 obj <<
-/D [1447 0 R /XYZ 56.6929 359.8869 null]
+502 0 obj <<
+/D [1521 0 R /XYZ 85.0394 288.1559 null]
 >> endobj
-1455 0 obj <<
-/D [1447 0 R /XYZ 56.6929 329.8975 null]
+1529 0 obj <<
+/D [1521 0 R /XYZ 85.0394 258.1665 null]
 >> endobj
-1456 0 obj <<
-/D [1447 0 R /XYZ 56.6929 240.6043 null]
+1530 0 obj <<
+/D [1521 0 R /XYZ 85.0394 168.8733 null]
 >> endobj
-1457 0 obj <<
-/D [1447 0 R /XYZ 56.6929 228.6491 null]
+1531 0 obj <<
+/D [1521 0 R /XYZ 85.0394 156.9181 null]
 >> endobj
-1446 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F47 879 0 R /F62 995 0 R /F63 998 0 R >>
-/XObject << /Im2 984 0 R >>
+1520 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F39 885 0 R /F41 925 0 R /F21 702 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1460 0 obj <<
-/Length 2195      
+1534 0 obj <<
+/Length 2208      
 /Filter /FlateDecode
 >>
 stream
-xÚ½YooÛ6ŸOá{¡
-�µ@…víõîTèY£S
è²mÌæÖÓ
>—›¢ñd	ÛÝÙ=+¿”DbwJA eíž«n¹_õ©í·ûÆ3»ñ#µ “»)¶&’…tJ*"¤Âãf'�‚ái{©–›ýÊø£§ÑÑSΉÊ3ë�–å7×óéËélÀG„ Š�{âºoX	¢å�Ñtv~ùë‹É
-”J‰`Ó�TÐe>à\†@�“¡ôöúõkð~rç³³+[ê( ¯Î¦³ñ«Éü7¨�Á-Þ/È™¶üPl:ÝàŽe~ô-lO&¿Ÿ]ýr9!ç×W…ö¢d}Iú�ÏXƒo(NEáìÂC:ùjÞËW=Ø•PzAÉåÞB¢}Á%z´Ë€Ï"x½+ß¡{?â’©LÊÀ�ÎCìÀ�™Ìÿ—„
-˜#òP—ñ<¹sî_/�«ˆ`ãx3à.|U
-¡>ËdTuðQø\|ÁÖ.¾àýþ€Ãv‹/^Y9Ü�ËMm˜,=ó»>±É#Í’éíPÑA9ô"Œ?{L)�ëÓ€}I˜pR¨P¤ÎŸ(P;a#‰L€í¾l׃‰N‘wPõ¹�¼‹v�—¡,Ø_”Õ6Þ—�yTœ~:%ÐN?ÿT¦ ü¾±å=‚~žC™’ª~Ù‹  T8G£»ŠàB÷„t3]�´¯Q€Â5Ìίr9ðQh�yÂàŽ®¿ßÝ®¬wÇŸàMFIÞÿ§êcÀ!‚_ÕÕÒôØ‚GAQÐpö=*v$ì¥\aª¸[)дC}/ç²#ûs_ʈÖR7¾
-˜¯èˆS»,E4‹�NfP[[ï„Æ

-@oÝkÈW4YÀ–Ýh›ò@4–[¨„ʶ½¹ÍqQD;]6pßM·lô¢�F‘R�ñ8æì”ÊXH,'©
$¦¡4c
¢m-rí{h¡ÒsœÂpFÊà.ì¨õX*;Ьëýf…+m…nÇv¦ië�ñ£Å­ë5íDáÑ0ë¡!¸O&Q@¨ÜüDÏ[#çïéíäPzh…�ÉÍ)\°²‹Ì%;hñÂ>›‹K×®¹_¼±ƒh &€—€v9¢�cì
-/dr¼�ùÉÂ/²¼LÑîwæöô“ëàiõ8‚¡s’qp‹8X¿,þ-ÒH
ããÃ-Ú—¡SR¤€uÑ•ÛñÕ$K�¾)‹ÊS~Tž.—_¯4µÌ�‹?I@èînÁÜûM;nÛÍ¿|·
+xÚ½ÛnÛ8ö=_¡‡}��šÃ»¨Áb�Lêt=Èe6õLÓéƒb3µ
+7t@ýi~ñWrüœ\^œÎßüzu<Édº˜_^àòÕìtv5»8™M>,~>š-:–ûb1*¿ŸŽÞ É
+¤ûùˆ‘•ÜÔ°<çÉöH*A”"®lŽÞý«#ØÛõGÇÔÔá
+õéPgâvSnLz^€ªwR&OOëÝÖ[Vï‹�²*Û²Ø8_q®ì”òÊÛÉïâÑ«Ó\€„¯*ª€³FRyÚì¯ûio«6R»¶¶BÈ~nmµ²+ç³à#ïÖŽ«ŸDo
¹;ÚèD
+Žu0=àê™fcÙtà#.›rh+ïÕ)ð_ÃD$4¿89ûõõl„’‚ Êø�ê«Z��ä’a²Hs±8CEL¹†Â–S !IfT/±ˆºŒB
áå8xû¥j‹Ï?Žð%QL«1¥©�Ò2"ç
oUo‹²šVδ�/׆p)£!Þ�P@,‹—.ëíÖù䈥 Ì‚�¼#ìOY®	®
B’/äà2Ú¡±­÷+Ý•ÑÌÓ*¸.‹™ û£†�ç¾N¹H˜5~‹êûêTªÒeÄáã�¸ª$ Øpo�'ÿÙ�…hf©#²kZôœ(Ê ú"éÂ]Ä$Æ0|}FuaÙ‘ƒ‹°]Bù*—e;UJNfò1aƒ˜ÑÀDô�¿#‚ì#d$“Æ'ZÏ}” ±…¦>’úÇSRd,0‰TyôŒs¹ß¡ª1I!˜MvˆÐ§=¨/(jRö}À©»îÔŽŠNåÍ&p!7HóÍ­]ö|ä�~ÛõX²ƒŽ€e¹~™ÙAØ^ü�ûmWÊX.ÚaÙð­™Ïf×M½Ù·–ŒXÐDæP§Ðë
+2õ¹™jH]{#ANÆÊÛ»wïÀû]’;¹8>wƒš
øüx~1};»ú
fµÑäÖ¿/ò•¶¼+6�l`…Ç<?8דٿ�Ï9›‘“Ës‚LVô�“!âc›
+à‹	¼Þ¹¶u„pŠV]þö2�‘oæ*û_ê
(I¸iÎ�eýŽâ
+s ˆm™È`æqÞ_»Qw0<
pq·±#ÞÂÀU•”æ«TÆL—=Špƒ/¸Ú‡ü}HÃn{™À^Yù´1—ß.Ú¸Yâ·5qµƒêt~3Ös0A¨áâE3QP Èû)
È÷3ÖêÆÐ<{¢?í˜í¥‘žÊc^»/Ûõh�
+Š.S}mFƒÞ{H—±†T°·¡'«]
¼/û 7}¾"°¬ŸÉÿ–§(¼›2C“'²ºj†>ŠIAšh£»Êè20éwºàТ
+¤Ÿ e–‡	ZÚK9
na4#dÇEƒ�·Ú{5Á…f]ï7+Ätý¹[ÛÙ¦­w6¬7~ÒtE5ò&''Z‚ÊìÛÂÆÀY{¾?†9(¡ü0J©Òk÷,µw¼Kík‚[téÂ}›[×âܯ->†¸ET

+ÄdÿyA<jN‹³¿îmÁÜú
ïFv³ÚÊÞûM;mÛÍÿùaa¬’€
 endobj
-1459 0 obj <<
+1533 0 obj <<
 /Type /Page
-/Contents 1460 0 R
-/Resources 1458 0 R
+/Contents 1534 0 R
+/Resources 1532 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1445 0 R
->> endobj
-1461 0 obj <<
-/D [1459 0 R /XYZ 85.0394 794.5015 null]
+/Parent 1499 0 R
 >> endobj
-502 0 obj <<
-/D [1459 0 R /XYZ 85.0394 769.5949 null]
->> endobj
-1462 0 obj <<
-/D [1459 0 R /XYZ 85.0394 752.162 null]
+1535 0 obj <<
+/D [1533 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
 506 0 obj <<
-/D [1459 0 R /XYZ 85.0394 685.5532 null]
+/D [1533 0 R /XYZ 56.6929 663.594 null]
 >> endobj
-1463 0 obj <<
-/D [1459 0 R /XYZ 85.0394 660.2382 null]
+1536 0 obj <<
+/D [1533 0 R /XYZ 56.6929 640.0743 null]
 >> endobj
 510 0 obj <<
-/D [1459 0 R /XYZ 85.0394 468.978 null]
+/D [1533 0 R /XYZ 56.6929 573.5829 null]
 >> endobj
-1464 0 obj <<
-/D [1459 0 R /XYZ 85.0394 442.1289 null]
+1537 0 obj <<
+/D [1533 0 R /XYZ 56.6929 548.3076 null]
 >> endobj
 514 0 obj <<
-/D [1459 0 R /XYZ 85.0394 217.1462 null]
+/D [1533 0 R /XYZ 56.6929 357.2459 null]
 >> endobj
-1465 0 obj <<
-/D [1459 0 R /XYZ 85.0394 194.0979 null]
+1538 0 obj <<
+/D [1533 0 R /XYZ 56.6929 330.4365 null]
 >> endobj
 518 0 obj <<
-/D [1459 0 R /XYZ 85.0394 110.3497 null]
+/D [1533 0 R /XYZ 56.6929 105.6253 null]
 >> endobj
-1466 0 obj <<
-/D [1459 0 R /XYZ 85.0394 82.4166 null]
+1539 0 obj <<
+/D [1533 0 R /XYZ 56.6929 82.6167 null]
 >> endobj
-1458 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F53 962 0 R /F11 1304 0 R /F39 863 0 R /F62 995 0 R /F63 998 0 R >>
-/XObject << /Im2 984 0 R >>
+1532 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F62 1050 0 R /F63 1053 0 R /F21 702 0 R /F53 1017 0 R /F11 1367 0 R /F41 925 0 R >>
+/XObject << /Im2 1039 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1469 0 obj <<
-/Length 3190      
+1542 0 obj <<
+/Length 3049      
+/Filter /FlateDecode
+>>
+stream
+xÚÝÉrÛ8öî¯Ð!¹ÊBc!¸ôÍí(O¥�Œ­éêšt”HÛ¬¡HµHÅI¾~ÞøH�ìžt×T�}
+¦‹ë÷74|;3¿�ß\ÍÏgBZ
+ïûûÙÇO|’
v?ãL%±ž<ÁÎD’ÈÉú,Њé@)7RžÝ�ý£8˜5[}dÒ*f:–‘‡NRùè¤*˜B:Ýå- “ðiû˜S'ËïÓ]iGçZO‹uî~%rZSÿ]ñÙŽþÆ5_,ÞA#hà¾ÞR§Ù-›ü÷]^YhÛsOóUmÚ¬¡Á§¢}¤Þ®Êòß8—UžÙóï { øô<:-‹ÁöÄ4% 4\ß÷È
+-­lê�é¬rph&úcÚÚÍUù•zYq�Kî�èÃï{³£^˜<]=Ú ùvÉÒnM+jЛ´…£À
øTæ°’gIæ?Ž+<L…át™cYšáÒÛ<m
+Ä
+ûy…w²k�Òâp“·
õ�z8u@'œ¤ÁßwuFçD`‘7›zÛZˆ»%u~�Ápóç|Û�ýœ9DFØgy™?¤-–ÎÆ5«m±<aãDdmÐêR™7vçõÍìòõë[vyû
‰yéà¹,K¯5¶bûþöúí5xîL"gèF%À½d>W`9ˆæ÷‰™´
+Hž$�8h@Z÷BöÉ•/J(3æG@F/EÁ®<rÞ0R<ªŽ0û!ãàj^*ªD±ˆG{¡â·Ë݃›ð"µ>~ÚÇ
–íºcP³'ŒØ`%¢C‘R0¥Àó:baƒ
+­À W‡Ó˲¤
Škº¤…hQ
+£
Œ/ª‡2÷„/Hlj‹È}H3j·
+ÓÞÊ—"°$.’G„€"9{``�…F¢K™*2XpBÄF§a%ˆ@»|t
ÿ™p~
+Öˆ,ëô+Q£Þ`°˜–¥ýmÚ{�åúÉðGöBƒ6%	‚½¨v]gZw~‰ O�&*
+0W¥=è?³4�
+#	½?&ãnAÏø�†{/�EŸ>y 'pv¨�
|x�v(Mߘ¨ˆ’I×›2¿ð\)ÔL(­ŸÃ*x)V3É/ÔEæ3
	Sê#@RiY.ã‹Fјå-ˆ&²’Ë©äتaÞÎ¥�µ`xµÛ’h›fŒ
’BN7[õfo‡õµT¾„‰Ô.Hi:ËWÅ:-iÌ8¯~î[N—˜yÃ¥4Ë\vÛ)/þ0�™æN‰¥S¬£7Õ�ÏiQ¦KW�#B}“R·÷u°½¿£¦Òª×LrÊ®¾�ù*ŒÇ‘è•V\Ø+¬Ú´´ü‰À´óXŽùsäÈQí©ö•ç˜V‰ˆ&-¢Øíá#ˆr‡Î9(NX :…ùâµGAÐi3(ŠGá!"ìaüê; ¼ä]¨g
+Öx§ÝfCb°}F$LŽ§Œ·2ºâ8þè=¡XøŒÏL€ú„(ªÏå‡âܯ­�H«N6ŽZœ``q´´‰NpÄ
++�E0ýl$§“QyàUuK�tÙÔå®5êÛ'TÁHÉ}œFÉ®¨îj=œ"8]F{§§ÀÏ
+5—øE½²Ábm«+®:Ž±¼7Ü6VYI�µ×MÚË¢,Zqö'ót[F$`KiX'ópE,N’ηùœ›P�
±Âš¶ÀÄá»4â¡*¾Q˜£�Ñö¨²Ây_pC<Ù¯b®
+ã;¹ýDbK¹ãc¯ä ³1Ðtï#½dõ:u
+AQœÉÄ®÷4ž^¯ò¦qjÔkHÔ¶æa™^ÚÜ—'¸0@ïûHÖs¡ÿÌçñ„!Ž€Þ³ `B‘ipß|w¤8~±�˜üòÑ8<ýÙQÓçT[Ïýö$;9þùˆ<ü|ÄEÏ™}ï¦oXFì¶ÂÑ-“»ïböTŽB)�tÛŽóû.j ÚÉHçí®oôîd+.ÕÇô>¥y2Ó$"HÜ â:I¢AŸØIoÞì]¤{®Ç߶ÚI¿ðc¤1Wï.ïîFÅŠC)v\
‹ŽŸ—y¾+ã“gMÂK¿bë¿äL­Hú%¥({)¤R¬ôÏ}îvxõÿ
+endobj
+1541 0 obj <<
+/Type /Page
+/Contents 1542 0 R
+/Resources 1540 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1547 0 R
+>> endobj
+1543 0 obj <<
+/D [1541 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+522 0 obj <<
+/D [1541 0 R /XYZ 85.0394 713.4234 null]
+>> endobj
+1544 0 obj <<
+/D [1541 0 R /XYZ 85.0394 686.2623 null]
+>> endobj
+1545 0 obj <<
+/D [1541 0 R /XYZ 85.0394 478.4096 null]
+>> endobj
+1546 0 obj <<
+/D [1541 0 R /XYZ 85.0394 466.4545 null]
+>> endobj
+1540 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F53 1017 0 R /F41 925 0 R /F14 729 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1550 0 obj <<
+/Length 3201      
 /Filter /FlateDecode
 >>
 stream
-xÚåËrÛ8òî¯ðÁU+WY<H‚Ø›&±³žÊ8YÛ»5µ™(¶XC‰‘²ã|ýt£
’’!ÙÙ¤jk
-çÛÕeÉhÓ˜‚zm�m:š­Oy62ykh<§¦1ëÒ¸Mõµ´²©7¶33€Fgµm·¥�ç­Û¼¬ž¨W”w¸äάé÷�ÝQ/ŒÉgs·£�û%S·5_R[¶f�·pp5rH)5öX�9�t’ˆ×‘
-xžrîH5ÃÃdšŽ¦[åh†#H3lMÞ”ˆöïÍïäÖÂÕi¸1mC=¤N=£NÒàŸ›’:[ç¨Q³Y­êuë n¦ÔùIÄÃÍfÝÄ
-°wˆla_˜ÊÜçmY/R‚Â4³u9µ‚
-E¼øp}ùîÔ1elÄ"Ô
àN,»ë9�{v€š«joίÿ}~}�ÿ6ùõãûó×�âBQ÷„š7W“_ÝäIÄⲃQ鈃\|È+³lé70ñ
-
-£Ä¼ªÜo«?ÐÞ�(×�–?¢—´':ŽwÂÙE]”hÙ!ê%‚<ÎKÌdJ;·ŽÉ“8ÄÖ cÖa-7þîÓÜÒ-¦Hj%­1UáŽ)‹vN]4â
-Ÿæ
Š­‚ØïW¸ä)õ÷ԪשSÚ–®Ql¬®àLvp.°—ƒéd)÷Âr$¹–<ˆÊܵqº�$û€•‹…)J°V•;è?v4W
-í�L�.lDD1_òŪ2g�+AÜÄe’¼„UüZ¬Æ‚�ɳ"dt$å
¶8
-ó%h�â¸ÓfP”€Â‹(ëaüŠ: ´„;zÝ°Üi³Z‘Ì@Ÿ	›ÜIë­ì‚ÂÜåVºðGï1Å2d|ÆãNŠº]-øn+ÄÎXX[!ƒ–�lìµ8ñÀâ$Â%9ñ+,9V¿’¹DoÕ
Þ²n©“O›ºÚ´V}ûd*ÞRò'�QB{l|‘'€“‚Ó…Ú9=~.QsIà�ŸJ=kWV™;-ÅP>X°VYŠd4««¼-§eU¶6âˆm4L“&_W¥	ÆÈBœ+eZw¾-äܸŒ0ë±Âš¶Ä¤áû,â~Y~¥0'±FÛrY”Þû‚bz·|9¬÷EDMe£g}N¶ëx�ÈŒíO‡éØw¦x}ÞøãËRÆQ&y0k”©ˆ¤NTÚêŬñfFÎZ”ÁØå�¶S.̸­ÇäÜ4b½GÌú%¾æ[ÐÏ�ÑVUa–T:Mwdá�$S´ëÆ­Ü §ÆóvnÖeë}›Ë3¶Õ
•—$Àp_¾œ¹UëÓl´©L½œíÌ°ö £ˆ#–hod\,¼«3Š$Ê«L˜`ýãXŠaÕ}ˆ2ÓŇòmJ÷>€"N$7ýƒ@XÒ"ô£
-$?^Ð…†Ø;чË#R ýNÕAõÄÇa‰tûíEHƒ¹¡ŒÃx@ƹò%>XîªX°r‘·ö%[È�<¼¯Xó{wà°‹ÒJ{ùÊú@qþ¿äv(?Jn…Øì[TÁïØ+·*‰X¬“ƒr+4‹Í��~Z½\>ž´$c+—-ØôBrŸ²Ã=-â�{(³®&~C3}Ö
ão¯ÏhØ>œÑèÛ®Ÿ�&gÁúü9ÿ»t\½º9À¶
A¾�ƃz¬»Î7øj·c/ÛR	ÁF|دŠ–g°Ü–ý! „8;c¶÷œ½d@Ðapׇ,E½È½*PèfÓ¯Ë]'n×3Ó4^�šr
ÙÙÚ>#Ó»Å@óæ
-òëü1Ep”–¾ ±Àï\lçÒ¹A¢LenÈôúòÒ0ñËÝ5ó
;û»º«^î€Ï©™–Ë|ý4\ï2H¸ŸàJlĽËôŽ´KNýÍGaÀt²Uämî•Ë&³vÓ×ÁØ@µ
[Îùè¬Óš˜>ùÌ-òõ@	7V.œ¹xžÏTu^ô£å0×è)U`5•µ-7.,a„æø
Óƒé
-ú¬[äŒô:£ ]¡Q
-ÜÛ¡$„}�sÛ# Nw¤Ão¨5_ òá£ÅÕxZMíÔÝbvÃÏAÉr÷ït0ˆŒ«$Ä‘ÈøN%ÁN®aý8î*Õ裋1–PÀºøà}×áÇQš
-oåaíÌED´&Έ¸ÿ lV£-yê¾/{ð_yÕþƒ°�-Å\¢œÑ¼Ê–tù�Ó	»|ÓBpÑ–3û²´çË>Œñs¼ÀwxìøÅàêµ_ýõ_>ƶÚ.Ân·sÏîRH½L<»¹ÿ<ðùÕÿäoendstream
+xÚÝZKsÛ8¾ûWè¶rÕˆ‹	‚Ç<œYOÕ&3Ž÷²³s %ØbE"5"eGóë·
€ DÉÉćTÊ%³ñn4¾n4Ðà|’©D¢˜äEšdŒg“ùú‚M ìçîêÌ|¥Y\ëõíÅ?ßÉ|R$…jr{õ¥¦5ŸÜ.~Ÿª$M.¡6}}ýþmq9›~¼½ÌÓé+üw{ýñöúÍÇËYQh1}ó¯W¿Þ^ÝP-5¤×ü͇÷ï®þÏ�ëàÃ{ʾ¹zwusõþÍÕå·¿\\݆	Ä“äL"÷^üþ›,`®¿\°D:›<A‚%¼(Äd}‘f2ÉR)}ÎêâãÅo¡Ã¨Ô6g‰�JŒHMð	çI‘eb ¶¬H”Ò‰M&ùåŒ3Ʀ¯‹ª«šº\Ñ<ßU+ã¨f».»ç½Êh-Ød&Ò¤Hyj»»®/gR²i麢T׸ïÒÑve½(·—\O®È|îv80&îíp?A"ó«‚Ù…k¼Ûlš-p3ì³¼«VU·Žh‡0¥¤ÙÒw±[o†õþjj×Íÿ+c§Š“òƒÉU8‘MsK$qÚ"€d6½^¬ˆR‰d›°ˆÙ^¶åÓˆOxι«CÝÒUKßùnK³©»Õž²ÊDzZ•w¸J6éj–ŽÏ2ZÏžYÇëõA÷%}ÜîãúV3
+žK/R:bhCŸ8«êBL¤Kÿh‰¨êÎl¸eWÕvÛK=ÝÍ»õãÊ+JÍq¶œóéO”oe�w{Ê ÔºÜ~I¸¼jM<5��!‹$VM¹ès«µIÂZçI!…¶3{‡X…@¹àg³­ÖV0¢àÓÖl�0
+ˆQ*Š�"�°Áo7ŽŽ\&iÊõyt°DËB ÃvÞÒ×|Þ\r”–Y¸ÑúÞ9.Lm¶e(¾'ù¬iBŽÿ „£“!€�´} v-
+ò_!˜�)Q^IYÎ¥…oÐ0×ú°Øp0`[’Œóg£Xz„èÔú×0Ⱥüd¼ôòÆÌ»rþi·qó¹ïù±AÏáÀc—
+(WÌiûÞm~UÓ‚‘VNY±$xÌãzk
HÎÎÚ6„�ù¾œûBò©”EúÖåYI*ô5;×ù·
ʄ»ø^EĨõó”=LA‰ŽO9Ê”®êùj·ðuí4RkÞìjØ?;âUÞ\
+vê³×3ÔŽAWŽô-†]ÍüŒf)¬zŠNQ¸y‰•XAk�ÃÄÁz1!¹»)
ƒ„vcþÜ™–nXb™I–'™ƒ�ðmL‡.ŸáZrthx6d› ”Óz·¾³HÍɈc^ÕÏ	Roߤb‚§› -Bã1¢/¦$¯ŽM?üúæÃÛ«c1
s*øŠÁ"É&³þŽíA¥Ô°[æ"{•L$9OÅ*Û™meNƒ2à¥@yžé”1×”2—
”H[Ͼ=(1õ§›’MØ=	¼
 	í7ÛoÌi0¾œ¾0‚‰Ö*ûšù'Á˜±¤`ú0Ê\')Ëè2ùî{h¾ŒÑ
+wù—Äìä!+œ[ñ¥1/G›Q¨tž…£¾¬%´ŽÈ	
€]ÅÄ#c²ð:ø›*÷Ds¨µç>츎)d^«#Îý‹æcÖÿQ(T�endstream
 endobj
-1468 0 obj <<
+1549 0 obj <<
 /Type /Page
-/Contents 1469 0 R
-/Resources 1467 0 R
+/Contents 1550 0 R
+/Resources 1548 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1445 0 R
+/Parent 1547 0 R
+/Annots [ 1555 0 R ]
 >> endobj
-1470 0 obj <<
-/D [1468 0 R /XYZ 56.6929 794.5015 null]
+1555 0 obj <<
+/Type /Annot
+/Border[0 0 0]/H/I/C[1 0 0]
+/Rect [55.6967 62.1828 116.8967 73.5749]
+/Subtype /Link
+/A << /S /GoTo /D (statschannels) >>
 >> endobj
-1471 0 obj <<
-/D [1468 0 R /XYZ 56.6929 586.2823 null]
+1551 0 obj <<
+/D [1549 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1472 0 obj <<
-/D [1468 0 R /XYZ 56.6929 574.3272 null]
+526 0 obj <<
+/D [1549 0 R /XYZ 56.6929 769.5949 null]
 >> endobj
-522 0 obj <<
-/D [1468 0 R /XYZ 56.6929 166.8772 null]
+1370 0 obj <<
+/D [1549 0 R /XYZ 56.6929 752.4085 null]
 >> endobj
-1307 0 obj <<
-/D [1468 0 R /XYZ 56.6929 140.1236 null]
+530 0 obj <<
+/D [1549 0 R /XYZ 56.6929 542.1781 null]
 >> endobj
-1467 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F14 685 0 R >>
+1552 0 obj <<
+/D [1549 0 R /XYZ 56.6929 510.0725 null]
+>> endobj
+1553 0 obj <<
+/D [1549 0 R /XYZ 56.6929 447.7453 null]
+>> endobj
+1554 0 obj <<
+/D [1549 0 R /XYZ 56.6929 435.7902 null]
+>> endobj
+1548 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R /F48 940 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1475 0 obj <<
-/Length 1085      
+1558 0 obj <<
+/Length 2647      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥VK�Û6¾ûWè(Ç(QÇÍÖ›:(vÛ�{i’mѶ°zU’³q}‡J~¬ƒ¢(ÎŒ†óüfLPøc�’„Š,Ò,&’2lª
vðíÃŒy�hTŠÎµÞ¯fïDd$Kx¬¶g¶¡J±`•ï¹ûmµxžG\Ò0!óH&4|¿|ü%÷O�Ë<ßÍÓ8\-ŸQü¼xX</ïóˆ‰Xr0 ¼‰?Ÿ¨ô°üu1ÿºú8[¬¦�ÏÓbTØxÿš}þJƒ²û8£DdJ¯ÀP²ŒÕ,–‚ÈXˆQRÎ>Í~Ÿž}uWo•I
-E¤âé�:qq«N2#‰€O¶N;S›N&ŸG"‰Ã/TÒb‹ô0gá¾è‘Ù6]¥¤GYßšMñ…R>Þ^í)ÂaoleÀ?;óéÙèRˆÚz®t?˜Î^/MäÍ㥋 9áT�wšv(š‚dèðuoêž’˜P'þR­+ð­i“„¥Êk凪õyÙðñwS»D‚H(h€â*ˆ#™”ÜÝÙ4õ`ê¡G@è-䃤»è¨¡Óu¿å�?]Üx©mËcQï�k»bT9´9´¥'Î?¿)É`ý.¡CœÆ¡ÆÃ{£¶}¶šHõ…Òº¨uwDzl¦¥kcòÉJ×]zºÉ]k7ÚVü'2ÃÉM×{¦:ŒÔÚy–¶,ß
-~¸ˆ/›Z¹K<æaßà9ìµ—ãiG2¡î‘¯4@µM7èµràÆïmÓ÷ÅAÇWf¸Ý+•îŠòˆ¬ù›1d½û(ÖÞ&Ï)ê¾ÈÍ£Á�z€‡öVi.Sì�°Û+˜¬$IÂem·©º(u’9·VÁ@J(Ó(Â…fãB³Ò¢öov‘0Eÿ†˜„ÆoF›�TúÅ\Ärª·®õæåÐú|¶§xœ`šsø©v-°_¡8
-<%ŒÉør³!˜ìüX0]
µŸõ«	Ÿvü­ñï@0âu46-Z`Ð]‹G8tK�üè#$±o��ø÷íþßOœÓ3/Ná7VñÛ¯A¢x–ŽAÙê)qùôzú?ro«³endstream
+xÚÍZÍwÛ8¿ç¯ðQ~­¹ü�DqöÔ¦I'=¤­ãîÎÛéd[‰5+KKvšýë (YvìÊù˜÷ü|‚ ð�¢E�ÃOô¢€qeüž6>¸z“ùïÝAßÇ3áx5Ó Íõ~tö�K¥{†™P†½ÑmKVÄx‰Þhú»wþë»/£‹a î…¬?Bºþ@C�óÏ×—W¿
ßõµï�®>_yxqy1¼¸>¿èŒ‰$Œ÷[ÜØ›r#oFWç7ý?FŸÎ.F�
m#W¨ý_g¿ÿÁ{S°õÓgÊDAï^8ÆÈÞüÌ|¥jJvvsöµØêµC÷�¨ˆ‘Ô{P“bj�a¡’Ê¢††ÂÌý�àœ{£YâL­â*-«tRÒûeš%h,ˆT-‘¼7�>3¾ð­°fx•ü¨¨u[,ç±k—;B§«ù‚Zãä.Íõ>­fÔŠé‘¥yò¶nþ7ùÅé!¶õš%#«Ç›7oö›ñ¡™±aùÎn´‚P2¾�±ßL¯7f*®½|5'Kj§9>#o/û"ò’¼š%eRºN÷Œé
@äSâ›Ò¨oyúcPV™“\¥ó¸æ0\IáÍ“¸\‘`7"v"ËdRäÓú%Í'N§8_ÅËboÑ*k‡`&¤µCÍ2„Þe‘eÅ}šß
(>øof}¦ŒŸZh>cb)ÇQÜÒsË»À�æ·E_xèþ´ÈÑ�¾ôîgéd¶-oWÉ]±Lÿ‡–áÀØuL“r²LÇ–ŒóŽ‹uÂȸ‹¤lYD9
+ÝÒ[„ø³Q%uYxá‰
+—¨±T^ÒÞ*Nsr¼Wv
+½í
+t•WVYè\ÇÙÊñÝZÇ[Œ�kü@Ô´žò*Îè…²ì‹%T�",(;i	ˆÆ&N³$Z¼ŽÓ,gŽÅ©Uº¡—5Û˜b}�V}!„‡†kÑ°“P¥À>‹×	Ñb"Ô†@ qÇ@’‰–QËYqŸ-ÍkéÉ>Cw“ØwÎeqY³>Ê2Ú�.ñaOBKh¡H«h˜vkI÷³¤V{‹£I@@L� t
+¹'� Ó,oAäªVfk,Ð|KfDËÆFÔëQ¥6™�ÉÈSÙÏ—
ò]JÝ•˜7<‡2³è5ÙTÀ„àº)gu1Û�㼞ãê˜RW TgF¤T»ˆ´^¹šÏcL\ÔµåeÕV;Ð+ÒiO‚4C„…õm±ÏáB‚€²ÐRG.bº'25«ZSÒëí¾¤H<]r[Í‹Õ¨^¶šçÔccGðšU@²mV ¤gÀ`Jôòa>.2bÎm"Ä–ÕFˆÚF Ôé¶J`‘obZ:vRº™šÀÆZ†V¥¼–yÄ24¶Ú¸RƒËòüd’”¥MlÐ
fP#vÝ¿ŽF_ˆ²%	z&³8Ï“3’Šê-�ñ–éÝÌ¡g¹ldX
+Ç\nÇ\}!vߥ+¡´e’À"œB*0‘ð®!ÃüÒ@ ºd�|”bP†]„%µsrÀî:ƒ	ðÔ…~kÏÈ;«ÄË�Ýu–z=gA·èð”ŠXè‹hËSáÓ<ž¸§j^ËMµ6¯–s [ø~Ôá)á3­ÜV<u1ÍKÞíŸaã‘íõŇëÜLp»EoÁY»ë œ-m_+K½v—Æ0ÀAw Ê%Ó:T5Nïã)¢ò/{t…zøllWy¹Z,ŠeEûX›ZPgËæSÇq€·�y]À_/„e¤™T~ðsÀ%pGR4eatsõñù(ÛÑOÁ±¥ãÉâ¨&µé(¯RG,
+SÃ@¼ Àèg%‚¶®'›BÅpÿÕ�gbÊ�Z‰àE‘™æë8K§›ï!›P­¿¾´Aß
 endobj
-1474 0 obj <<
+1557 0 obj <<
 /Type /Page
-/Contents 1475 0 R
-/Resources 1473 0 R
+/Contents 1558 0 R
+/Resources 1556 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1445 0 R
+/Parent 1547 0 R
 >> endobj
-1476 0 obj <<
-/D [1474 0 R /XYZ 85.0394 794.5015 null]
+1559 0 obj <<
+/D [1557 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1473 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R >>
+534 0 obj <<
+/D [1557 0 R /XYZ 85.0394 769.5949 null]
+>> endobj
+1252 0 obj <<
+/D [1557 0 R /XYZ 85.0394 752.4444 null]
+>> endobj
+538 0 obj <<
+/D [1557 0 R /XYZ 85.0394 549.5629 null]
+>> endobj
+1560 0 obj <<
+/D [1557 0 R /XYZ 85.0394 524.9842 null]
+>> endobj
+542 0 obj <<
+/D [1557 0 R /XYZ 85.0394 417.5407 null]
+>> endobj
+1561 0 obj <<
+/D [1557 0 R /XYZ 85.0394 395.2295 null]
+>> endobj
+1562 0 obj <<
+/D [1557 0 R /XYZ 85.0394 395.2295 null]
+>> endobj
+1563 0 obj <<
+/D [1557 0 R /XYZ 85.0394 383.2743 null]
+>> endobj
+1556 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F39 885 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1479 0 obj <<
+1566 0 obj <<
+/Length 2456      
+/Filter /FlateDecode
+>>
+stream
+xÚÍ[[sâ8~ϯàÑ©´º_Ó¹Ì25�tf«kfç�`gâ©Û$�ýõ{dÉF€Á�ÐSTWµ…Ðåè;ß¹è8�†¤'$’†šž2	LDoòt‚{Áw?Ÿ?¦_ꇣ>�NþuÅTÏ #©ì�4ÂZ“Þ(þ#’ˆ£SX
GŸ×æ´OŽnG§ŠGgö¿Ñàv48¿=í£itþï³/£Ë¡%ƒ‰®ÇO?¿¹¾üüÛÐ/psíº‡—W—ÃËëóËÓ?G¿œ\Žš„‡$˜YéŸOþø÷b8ë/'1£Eï>`DŒ¡½§.œ±ºçñäöäk³`ðm5µ
4Î5`ÈôFœ�Í»º0ìê›”!cå\Þ´/	RŒÁ‚Šs„
^¨�’@
RÃ!�ê)a�d”Ujøš¿
“û$ÏÇ�˜Â‚)D�Õpا<Oò4)NûŒó(?%:JŠùc™Ä®'�†ßøE«žñ´xMr««:âÑCê—™d¹_i–MãÂ
+
»õ	AFZm[fN�åCâe�EâZ
+/b¾ù0L"*
+59$Ôš#F¸ê€Z+d0iBÁÕÍð3X¢…D*@ø,èPûµ·
+7±ãb>{L'ãÒ*›2
¡cÞBL­yk›kl£æªm�Ë2yš¹ÐbÇdî¹`«Ÿs7/]#N‹~o&™OÆìR²‰ñÔ=“ïiQ¦Ó¿Ü§ç¹½¹O.µ­J8Û(ÆO¾5øâŠcOÞ⧶�gY^þÂ1^­þfÓY
.ª>MaAÿuù6KÜ·ckJöÛÉã¸(|ߣÛf¿¹ïî’JlÛt”Íúm†;
Á’lNUÛœj³9åð­žíV^_J©¼"ãFÿ-f©äÚÕË®
æãÒa#¶Wçe´i|
­?f(?Ôö@Z£Ýn|B
+à
$w«&^¼Az‘Nvó
+ Ò³
H8¹îÀP@ta\.cøîˆáB¸cæ!§HÚ…!‡0«0&wC8…üÝ•v7ÂèÒª-03ŽrO¦dŽ�¹8‘«7gû˜âÏáßZt8Ä@²c¶e¢‘Ñ´+SŠ„4$pS~€�dÇÌ@¬¦ª+Œ$a.Ÿ}»“ç½(h笕ä¶p ×ÃW½wT´# £‘Z-Á·
÷†/”ë˜áÓZÒtÀ§á^ˆ!µ­@yû{ÃÈuÄÞ�(WZÒ†‰X¸æKðíþýáä:fö	ƒ(–Ñ—HŠ”aÍ«�ÛùÄþD'~¿¯½ÊÙôN¢°+&ñVDQ�Q®„w *0ÒL×€n(V¾Í
µË”NƃæÝ«f?¢äŽ
+1àÙº™ TíR7«^ê+¸ec¶½n¦9¢2øÙ
A̗͆I‘=¾ÔšØµRÖÔã€Ì]WeĽNnîú›šÅ¯Œ@íL‡…¶ô3_L¬¥²§ÕzMvȃ(“´Møÿmlºendstream
+endobj
+1565 0 obj <<
+/Type /Page
+/Contents 1566 0 R
+/Resources 1564 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1547 0 R
+>> endobj
+1567 0 obj <<
+/D [1565 0 R /XYZ 56.6929 794.5015 null]
+>> endobj
+546 0 obj <<
+/D [1565 0 R /XYZ 56.6929 352.0981 null]
+>> endobj
+1568 0 obj <<
+/D [1565 0 R /XYZ 56.6929 326.9775 null]
+>> endobj
+1569 0 obj <<
+/D [1565 0 R /XYZ 56.6929 326.9775 null]
+>> endobj
+1570 0 obj <<
+/D [1565 0 R /XYZ 56.6929 315.0223 null]
+>> endobj
+550 0 obj <<
+/D [1565 0 R /XYZ 56.6929 102.2008 null]
+>> endobj
+1571 0 obj <<
+/D [1565 0 R /XYZ 56.6929 77.0802 null]
+>> endobj
+1572 0 obj <<
+/D [1565 0 R /XYZ 56.6929 77.0802 null]
+>> endobj
+1564 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F39 885 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1575 0 obj <<
+/Length 2081      
+/Filter /FlateDecode
+>>
+stream
+xÚÍšÝoâHÀßóWðÒÒ×ß�ÙfYí$àV+íîƒ�‰µ€lå¿¿j·mÚl¸äNh¤	6U]å_WWUÓ&ÿHG„™áe8˜ˆÎly…;ßá»/W¤�é—BýPêçéÕ¿†Lu2’ÊÎô)K#¬5éLçvo~¹þ6Œ{}*pW¢^_HÜýytwëïÿçæþn8úòïñuOñîttço�ÃÁxpw3èõ�Ñôy0B¡;™:¥Bs2ÝLzO½L«’`æ¼ÿqõç߸3‡gýõ
+#f´è¼ÂFÄÚY^qÁ�àŒ•wW“«‡jÀàÛ\õ4Î5°¢ªÓgi	cœb–3Ä%­[ý¯”J?p§O2B4Ø÷z†*>–õ¡úüBp…¤Rd&ˆ“$$é(A• .
+&oËÇdÑëKnh>wº˜»â>£œvom:ÛÄë,NVû3(C„3Ñ	mìa5,aÈÏçÃR”˜Š%‡ø0ƒŽÏÃÖnÞ^8Ķ�²;¾ÎPe�*ÑB
+çJ£oNÃaü
ê±MýEjW:0pîs
’ÏHRRê€T!&
+ã¢;†ëvœ;¥3ø¾]l4*�—¤…ŸŒå0h�~ö„è^�~ƒ šwÇÃ(^´ƒtÚ Ú®ÏrÚg
+»¼™nåê5¸¹]Øï‘ÛbŸG2ðòRI
+C¦¥Œ#�æRmzæR_Žrþ„=ãÃ.[ztÙn㸶›§d³l:y± 5¨bÞRÐ…fHâú—ÅÖ-äA·dŠñîdò–žõÆÝÄÿ�æóbÁTŸÜ¸%âxõ’üÓØ;ÑÛsH�ˆqÓRâ…‚A˜¤{€åÙ€å眿XÀB‚*o©þBÀ½âgê €Ok¤N
Ü]cÕ5pøb¡rŽ83-õ_p�0z?jO¦*?‘jàñ¥¶û°GG\ó–ú/˜DXa_ÿÏ»ªhq�ev¹ÎÚ©BÏ?Üxf/Ñ"žç
@Á×Òˆ1pñbƒ“b$¨n+þ”#B„¨a¼ÿçcÓílfí¼‘`àÝg¤rVo[j&)I¢ÛŠ¡ˆHÌjïì÷s *nj@ÌÿÂýUÞ�¾X7^¹~*Ö}ghw¬åÓwÛ„÷1Zÿ»†%[zÖR´¸ÖÐ@ÖðŸ–Z›B¸-‘†®}VüîŽNÿÿ‡¢6†m
+VìV±Vá	\†%ÒÔIsÁ”ê#%°<fæ”@Ù)wd
—½>Áwo’å¸?Æ‹8+v¯qöìg6%ÁìQ…\tûÉËÌý‡©F° e!Tœ©Þ$ÛUf7é��èè3
+hs“uဋ¯òË<C»ÏÉ“»öªá¸ðrMA­ôűŠ6õ"ùmæñêû!'%ˆ3UŒ¥‡ž– i$i~XȦÒeÓZ>šÇó#G:Ú	M°h9—€©†˜+¥ò˜»þcø>Úˆ�„y³ÙJê€ÝZ´A
+eœ¨ºáésœÖm±Ëõ
½bšÆy®Ü[¤þÃh5K–n–ò«‡ú{	3GaRM‘¡T6Ã¥ŽÃ¬¤r˜£‡w(1ä>,e³ÑJê€ÕJÈÝaoÍìç¢Û[›f§²Ч0®ZXR
,K©œåý:Kß&„’pMg“ÙJê€ÝMÀ€½n¸…fUB‚üç.òŸ„þRuNJ0eݲûfgµŠ”ÁÑ·¢®ƒ_­ßÍõ_ÓMZ¨¬ÑÌŸZêºZÿOÃÔR
S[Jùsrˆ¹¿NŒä¼Ùj%uÀìþ:1\¨ºÝ#3‹jlËõÂ.-ÈÌ*¾)1¿‹ƒ7»èØ{•L ÷2ä�'Ã�Ö]Ò©ï\îÞBåÐIjM#ªšõ©¼™÷;èœ5U\ÿðçœendstream
+endobj
+1574 0 obj <<
+/Type /Page
+/Contents 1575 0 R
+/Resources 1573 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1547 0 R
+>> endobj
+1576 0 obj <<
+/D [1574 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1577 0 obj <<
+/D [1574 0 R /XYZ 85.0394 769.5949 null]
+>> endobj
+554 0 obj <<
+/D [1574 0 R /XYZ 85.0394 439.3709 null]
+>> endobj
+1581 0 obj <<
+/D [1574 0 R /XYZ 85.0394 411.7795 null]
+>> endobj
+1573 0 obj <<
+/Font << /F37 791 0 R /F39 885 0 R /F21 702 0 R /F23 726 0 R /F65 1580 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1584 0 obj <<
 /Length 69        
 /Filter /FlateDecode
 >>
 stream
 xÚ3T0
 endobj
-1478 0 obj <<
+1583 0 obj <<
 /Type /Page
-/Contents 1479 0 R
-/Resources 1477 0 R
+/Contents 1584 0 R
+/Resources 1582 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1445 0 R
+/Parent 1547 0 R
 >> endobj
-1480 0 obj <<
-/D [1478 0 R /XYZ 56.6929 794.5015 null]
+1585 0 obj <<
+/D [1583 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1477 0 obj <<
+1582 0 obj <<
 /ProcSet [ /PDF ]
 >> endobj
-1483 0 obj <<
-/Length 1368      
+1588 0 obj <<
+/Length 1324      
 /Filter /FlateDecode
 >>
 stream
-xÚ•]oÛ6ð=¿ÂÈ“Ä)ês}jÓvëPCã>­{ eÚ*‰šD%͆þ÷ñx¤,Ǫ·À0t<ïŽ÷M¶ æÇYL(Ï£EšG$¦,^õ]ìÍÞÏWÌÑD1'qĹYÌì®bž‘8ÓÅjÊäÍúêö}È!%IÆ‹õn”•¤)ÉÒ8_¬·wÑjÙ-WaLƒtùçúW<‘4K£FDB²(Ïì�7~{‹Ô9~îe1t¥~ÂÕ�júr+;¡K�üXDx”„Ž_‘Œå¨@JØrÅ(¥Áë¢�}?²Ñ�ªpñ±ìµgÅ9É“0qœ8%!��Óñ|Œç—,�Gäxؽ/4¦¯ï>öæËn
-Ñ ÐK·5´Žg³E )‹¯�¨�¨�ê�n7èaªÃÐ; lFž\œ1’Çqh/.ªJ=®¥ËÝÓŒ™Œ÷¢(MÍ) ¾™á‘<cÜ ·¿ÙÍ2‹�#Cö2f„Hob†aÊÏXòn*Q|=¨JΰŠLX…ì…Õ�hú�É€s~&LY–U³Á(uA€ÖÄ	£Inœ‘‘<7‚�ìs_6{Cš˜€6A†�å`Œh…߃x�}¡4ll2&,(Ô’Ó(68õ€»4x<¸Ós Ç?Êpt.ÖÔËN§‘½IƒÇRÔ ›jЦ€îp¹g†a<ò5P¡Ðv�+
-ôU”N|æ$LŒ/ÐW{¥¶îÌVŠ¹Pa$ËSÆà	 ¶Y
-ýM#
+xÚ•WKoã6¾çW99@D‹¤DIÍi7ÛmS,Š¢ëžº=Ð2m‘EU�dÝbÿ{9R¶lÁÛÀ08¿΋�…æGgiLBžE³$‹HÒx–ïoÂÙÖ¬ýtC�LsGœ›ÉÄjó”Ä)KfÁ)ÈûåÍâ#£3!X<[n]"Iå,�-×Îw²îTs°8œ'w-ÁmI҄¶ШHHœ±Ìnxÿôë”Îpø¬ò¾)ºÎuÕkÕÈ®0Ô€G#Â#ÁžˆI,¸…3¦Ü4Ãù»<Wm; t�.qò©h;�ÄgɈS™ÉïçÌí¿£é0€�–üÆá»ÇO­é½añt.­¬Âu¹^ãÔƒíe—ï�,�0ÝNvHt�D.+$Zå–úÚaVk$ª"®äÞ©Úè:ßô]jCß*80‘R’Å1³G,ªÁ¡G7��SfdAD–¥~
*ݛÄÏbA¢(Iœðý\DÒXŒÀþîU3‰›˜²·Cºš@KBÂÒ8ûÜ €x
ä^[LšÜH©x“}Þ´�©0éGÿrUÊüy§K5�AFß›A¥™˜"w™A­D×Ȫݘ:¾TÅcQqTekJu9A<¿ÐŒ$<Â"ÿ£-ª­‘¦,M© e­p´Íy :�ãN¾(¤¾„!«lGtž?Òù±�§_p5œ¿îÜn[9V‡o¨ÃÉaÅ
+ŽÛýâþá-ñ�Õa|ìkç›üÌYˆ2K›éœòá=4v{Ix
¬°7L ÉsaM
 endobj
-1482 0 obj <<
+1587 0 obj <<
 /Type /Page
-/Contents 1483 0 R
-/Resources 1481 0 R
+/Contents 1588 0 R
+/Resources 1586 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1487 0 R
+/Parent 1592 0 R
 >> endobj
-1484 0 obj <<
-/D [1482 0 R /XYZ 85.0394 794.5015 null]
+1589 0 obj <<
+/D [1587 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-526 0 obj <<
-/D [1482 0 R /XYZ 85.0394 769.5949 null]
+558 0 obj <<
+/D [1587 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1485 0 obj <<
-/D [1482 0 R /XYZ 85.0394 574.5824 null]
+1590 0 obj <<
+/D [1587 0 R /XYZ 85.0394 573.0962 null]
 >> endobj
-530 0 obj <<
-/D [1482 0 R /XYZ 85.0394 574.5824 null]
+562 0 obj <<
+/D [1587 0 R /XYZ 85.0394 573.0962 null]
 >> endobj
-1486 0 obj <<
-/D [1482 0 R /XYZ 85.0394 544.7049 null]
+1591 0 obj <<
+/D [1587 0 R /XYZ 85.0394 542.127 null]
 >> endobj
-1481 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R /F47 879 0 R /F39 863 0 R >>
+1586 0 obj <<
+/Font << /F21 702 0 R /F23 726 0 R /F39 885 0 R /F41 925 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1490 0 obj <<
-/Length 3343      
+1595 0 obj <<
+/Length 3437      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥Z[oÛV~÷¯ÐÛÒ€Eñ\x+¸�Óº»Hº‰ŒÝ¢íEKÜP¤BRVÕ_¿3gæP”D7
Š æáp8ç2·o†³
-¬$ ƒU‚3åGax‘~_3b™úI§£ˆ…†Kï؀•N8)á¨6h8²Æ
W0Jì1¡ê˜|î¯̾µÉxTÖyµ/LÇÌ�7Žý†²*ܳëƒ8œ±;Ÿ’üÉGÛÓÞ[Nk´s·—³ôŠÂþ†A5M
®•v-`|65
é¥4ŒÍSG8&NRñ5± ‚ÌÆ.n–<aœ
-ð9«
-ìË
]³âû®¿˜ï%«ö¦f³§#"+�îÏì‚°RçPÇ'3];OÛ”‘;°^¶ÜëApŽ“'FÅ	
-€M)_ÄQr
\	ÿtŽf¹®±ðÇŽßréùg
-ñÍ7-?†bBÊS@ÛC	8‘œAQQà‚è¾J%aa‚ÛR¾ÉêµqtA-â£é:®˜l+ˆÛ¦(‘)Ïú¡NCmv®ê‡”`jJ_fŠöOŒ”ªTÕ¦´£¤ŸÊH]í‡ë2ן´B³Î`?·¢5çÁeÁ=	7µo3,‹m\ý4TÞ8�–¹„rê£ümÙS!4Õ.U
-QØ´£³À›ÐÉ^Å‚³É
-€è­=B	Áb+Ë|nD�u•£àÔ±±þ5ûGO:8ÀéãÃ_óαK	‚lƒK�µªŸÀJ­9Ï)ÎroŽ`JeN¡åiWd½qÍjî;~±]}Ï
^	Åý×WÒ+œ|¤îY>ŽŸ³œ/Þu›f_4^ñ« qPvŶ‰Úšƒ«Úš©`ÆN€!`Æ+æѪàY]§pØÁ¶Tq]£½¢áû
US`ï¶7¤UÖQ¤(¾§Ú•RÊ{ü‰YQFíø%*º”ãÔÞ¦¡²I&5Ÿ¡bbX9f£“»cÿâEVåÀª©U÷ÊÔ;¥¬…^ÖSç@†P™Þ
-\Tü·”Ã'ºm¶†É«üØ×qêðÀöæ0gUOÖ¨I2ı?¸ƒœœÚåJ…Ü.GòÖô›¦àe0
Š4N×

-@µÜœÖh¹»†X܃s]àŒ®$�Áý"pó³Š�å$ƒÑâøé
žnˆ-”üáƒdX–ɺÒ20~¦fÐÚ,väï«®áoúa©™ñ|¶ø˜´x¾hÃÓØó¥6lB¦ðªfTª|)høÍÌö‰Ú¦±�$Û1¡Z,ÎOÖÊñ
]º*{aÖáÃ
-ìÍ´phÛŽ0<PyÇEØHêRð†vc¿Œ)qZÒ6ƒz¬�2üœzÚfdN‹�m.A�œõ=궠‡+¦vC5:7ÕÈ44Ã3ç²@°»¾£ñ€ñÔðuE�÷H�è[Ë„(Þ
¿o›!~¼ðl2\½`Ï `›
-.
júl?Qëœ&=aÏl7úReQnï¾�›îù†b:óÄ'ž·�ÍÉÖ|:‹�b}Y±C¦}CL˜õmÿnmóÀÀ‹
|c›ÜVA¨ÁèfÅÒóö¸ë›u›í6®×€�³=¬ ÆöCoXЊçØš¬ž>[4A
+xÚ¥Zm�£Fþ>¿ÂßÎ#�1ý4Ñé¤É¾\&íæv=º‹’|ÀÀØÜbp
+Êú`ZFs‚ÄîXËpþT7DŸ²˜@§âUƒ
;P}n¼J²È�—;ÖÍ¢p”ÝçMy¢gEå$¡	IÓé¡LXÒŒ¸ð¶À§`€ê7À®s7±X‰é!ƒU‚3å…Ap‘~_2b@?ÆDñ b¡!Gk
+÷ìúÀWlÇK’?yh{zþžÓíÜíeä7ÈìoTãàZae
㳩	HÏE~ÄØ<uÄ€c –_BÈìAäâfÁëÆñ1Êž#²[›R~ñ}Yæ„=`g`ËO(ª
+€©À¾\Ó5Éþwh»‹õž“ò�·ýjötDˆa%ÆÇCX©u¨ãK>];OÛ”¡;°^¶Ü‰ÚNA¶]ÀŨ8
@cO�m_d:ˆ)w¼Ð„1.IÓúPqàxr2RËÙJD¢ÅE²z¬x›€ŽE·%$‘'MYþ±8¦åSÑl*@EKº£¡u‹XNû‚eyrü@Qð^ƒø±pòW“GÀœ¨O'¬h@ŠÅåZ	d`.3ÉuDSqßÛ.醒Wuãà<¢]`¹

ÛáE*Ú&¶PÂÓøºIšÂœAÈb#1>!7h·G¢8O@\›ùwõ14LQ|ŸWÁ˜oŸé[H�ð
+²Smã3b¿£B‡ôÔ]r¢Ù|ŽÆ‚Ë2.­rÂÜ÷æSmÚK/—&�B„K¸Ë,^þ‘7õBP^÷m±©£•é!«|…Úeˆ	 Ä(ý35dVÖ›ú.Ò�ÎÀÅÕʸXÜcžy—:èŠÝ”›…nê6ìM
°)å‰(4=0p%üãÍr]cá�¿çÒóÏ
+õë ç<pK
+aµÉd(Iå:B¶k䪯?óü•ówW]Xéù‘Œ (ã�aéÙo3áù:ŽMŒí^Ïg`	ˇ�œ½­aG³Á¦ãÅ�³ÝÄž�@+¬o`#
í©î,HÒŽÂ{(DaÓG�×ÐÉ^Å‚Ñb̤ËQ,`î-]ÁZEÐǤ$ö‰"Ô÷XìÛIçŠß’ÑúÁþP°Ôj(ì`�3ðñ!ó(¥Æœ¬o%$5ô©ˆ
+€è­æ„ÁbËË|nD�ºÊapêÐXÿšý£§
àüeæ¯yçØ¥ N×g—µªÝ<飑Ɗóœâ,÷ö¦T¤Z÷YÒå®YÍ}ÇWÛÕ÷à•PÜop}U!ç™ã�ÔóÇñS’ràÅ»v[ÊŒÆk~4Ê.y†íE¢¶શæFj˜ñ…3`ÆG˜ñÊ€y <«ÊÓT‡îh
[¬¸®Ñó¬æû-US`ï¶7¤uÒR¤(¾ÇÚ•Rjþð#’,#ŒÚòKTt)7SÏ·5•MŠ0iþTL+‡ÓèäîØ¿XȲè§jjÕ½°ô⤬…^ÖQç@P™Þ
+*þ[Êá¿Ý6[ób0ŠÞØ^¬êÉÕ˜>ŽýÁdsn—+p»É»¼ÛÖ‹Á4(Ð8û�àèPÊçgí춦)îÁX¸¢+I#p¿*—‘)0Ó-ŽßâéØBI¿>0½XyÒ¶��ñ5ƒ6Ö`±#_¶5ŸxÝõ¢&ŽÅÓHøˆ´8:çeìùRÖ�)¼¨+Oʾ¢™E?}¢6‡el#ÉvL膄…Áød�`­Ð¥-“gžÚÀŽìH�½å
~Dn‰
+ä¤ëP·=\3µí«ÁÀ¹y ¦¡ž9—‚Ýõ�{Œ§ú¯+z¸GzDßZ&Xñnø}Û,ð3`;Ãô€9€Ï6å_:ÔôÉa¢Ö9/zÆžÉ~ð¥Ê¢ÜÎ}37=ð
Å0tæ‰O<ö'Ê·æÓZqèKZˆÝâ0íç4	³¾íßmlèçb?·Mnˉ To
t³fîisÚwõ¦Iö[×kÀÇÉ
$¨°ýÐåÌhÍkìò¤š>[4A
 endobj
-1489 0 obj <<
+1594 0 obj <<
 /Type /Page
-/Contents 1490 0 R
-/Resources 1488 0 R
+/Contents 1595 0 R
+/Resources 1593 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1487 0 R
-/Annots [ 1495 0 R ]
+/Parent 1592 0 R
+/Annots [ 1600 0 R ]
 >> endobj
-1495 0 obj <<
+1600 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[0 1 1]
-/Rect [63.4454 757.0719 452.088 767.2337]
+/Rect [63.4454 738.9144 452.088 749.0762]
 /Subtype/Link/A<</Type/Action/S/URI/URI(ftp://ftp.auscert.org.au/pub/auscert/advisory/AL-1999.004.dns_dos)>>
 >> endobj
-1491 0 obj <<
-/D [1489 0 R /XYZ 56.6929 794.5015 null]
+1596 0 obj <<
+/D [1594 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-534 0 obj <<
-/D [1489 0 R /XYZ 56.6929 739.5018 null]
+566 0 obj <<
+/D [1594 0 R /XYZ 56.6929 723.0302 null]
 >> endobj
-1496 0 obj <<
-/D [1489 0 R /XYZ 56.6929 704.7645 null]
+1601 0 obj <<
+/D [1594 0 R /XYZ 56.6929 689.3491 null]
 >> endobj
-538 0 obj <<
-/D [1489 0 R /XYZ 56.6929 563.5308 null]
+570 0 obj <<
+/D [1594 0 R /XYZ 56.6929 552.677 null]
 >> endobj
-1497 0 obj <<
-/D [1489 0 R /XYZ 56.6929 535.7626 null]
+1602 0 obj <<
+/D [1594 0 R /XYZ 56.6929 525.9649 null]
 >> endobj
-542 0 obj <<
-/D [1489 0 R /XYZ 56.6929 418.2412 null]
+574 0 obj <<
+/D [1594 0 R /XYZ 56.6929 411.5673 null]
 >> endobj
-1498 0 obj <<
-/D [1489 0 R /XYZ 56.6929 389.5504 null]
+1603 0 obj <<
+/D [1594 0 R /XYZ 56.6929 383.9327 null]
 >> endobj
-546 0 obj <<
-/D [1489 0 R /XYZ 56.6929 228.1296 null]
+578 0 obj <<
+/D [1594 0 R /XYZ 56.6929 225.6356 null]
 >> endobj
-1241 0 obj <<
-/D [1489 0 R /XYZ 56.6929 194.8993 null]
+1299 0 obj <<
+/D [1594 0 R /XYZ 56.6929 193.4614 null]
 >> endobj
-1488 0 obj <<
-/Font << /F37 747 0 R /F67 1494 0 R /F11 1304 0 R /F39 863 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R /F53 962 0 R /F48 885 0 R /F62 995 0 R /F63 998 0 R >>
-/XObject << /Im2 984 0 R >>
+1593 0 obj <<
+/Font << /F37 791 0 R /F69 1599 0 R /F23 726 0 R /F39 885 0 R /F11 1367 0 R /F41 925 0 R /F21 702 0 R /F53 1017 0 R /F48 940 0 R /F62 1050 0 R /F63 1053 0 R >>
+/XObject << /Im2 1039 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1501 0 obj <<
+1606 0 obj <<
 /Length 533       
 /Filter /FlateDecode
 >>
 stream
-xÚ¥TM�›0½ó+|©¸6Æ`³IÚ²RÓ4a«ÕxT‚Ó@6Úýõµ3·¶ôTEóÆoÞ|x€"b~	Ž	“1JeŒ9¡•[� µ9ûêQÇ	Ϥð–u—{Ÿ¿°I,“(AùË�–ÀDŠòêÉÍóé"#Nü!Oˆ—Í&à‘ðXNÇ‹,4þ1[f“éb¤±Ÿga,ˆ0ñÌ)Lg£ïÙøó	P§Ôžó{oš_¹m–f»øí==T™žï=‚™
 ˜J¡­s†yÌØÙÓxKïçEðæô:4<Îæ"J¦±¡éq‰fŽìô–z«lO‰ßÕ½êÀ,7ZwÎÝkûäþ/¥và)šŒê­-¶uið[xØUE¯*8˜ØyžE_€U· ã`wXUz[€×H¶.²R�Z!—{Sô7üÐŽÛôRŠ%çÑ©
'ÂTÊä)…��Ú{�2è]·ÊÜ,#‰Ÿoê˜Çâ- ”úŸŒ‰I§Àßë]بWÕ\cÁ*uÛ›|u»vx_÷v
+xÚ¥TM�›0½ó+|©¸6Æ`³IÚ²RÓ4a«ÕxT‚Ó@6Úýõµ3·¶ôTEóÆoÞ|x€"b~	Ž	“1JeŒ9¡•[� µ9ûêQÇ	Ϥð–u—{Ÿ¿°I,“(AùË�–ÀDŠòêÉÍóé"#Nü!Oˆ—Í&à‘ðXNÇ‹,4þ1[f“éb¤±Ÿga,ˆ0ñÌ)Lg£ïÙøó	P§Ôžó{oš_¹m–f»øí==T™žï=‚™
 ˜J¡­s†yÌØÙÓxKïçEðæô:4<Îæ"J¦±¡éq‰fŽìô–z«lO‰ßÕ½êÀ,7ZwÎÝkûäþ/¥và)šŒê­-¶uið[xØUE¯*8˜ØyžE_€U· ã`wXUz[€×H¶.²R�Z!—{Sô7üÐŽÛôRŠ%çÑ©
'ÂTÊä)…��Ú{�2è]·ÊÜ,#‰Ÿoê˜Çâ- ”úŸŒ‰I§Àßë]بWÕ\cÁ*uÛ›|u»vx_÷v
 endobj
-1500 0 obj <<
+1605 0 obj <<
 /Type /Page
-/Contents 1501 0 R
-/Resources 1499 0 R
+/Contents 1606 0 R
+/Resources 1604 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1487 0 R
+/Parent 1592 0 R
 >> endobj
-1502 0 obj <<
-/D [1500 0 R /XYZ 85.0394 794.5015 null]
+1607 0 obj <<
+/D [1605 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1499 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R >>
+1604 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1505 0 obj <<
+1610 0 obj <<
 /Length 69        
 /Filter /FlateDecode
 >>
 stream
 xÚ3T0
 endobj
-1504 0 obj <<
+1609 0 obj <<
 /Type /Page
-/Contents 1505 0 R
-/Resources 1503 0 R
+/Contents 1610 0 R
+/Resources 1608 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1487 0 R
+/Parent 1592 0 R
 >> endobj
-1506 0 obj <<
-/D [1504 0 R /XYZ 56.6929 794.5015 null]
+1611 0 obj <<
+/D [1609 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1503 0 obj <<
+1608 0 obj <<
 /ProcSet [ /PDF ]
 >> endobj
-1509 0 obj <<
+1614 0 obj <<
 /Length 1964      
 /Filter /FlateDecode
 >>
@@ -6602,86 +7134,87 @@ i	·¥Ý3éÀ–yíˆùðŠ&�Â8K<æc�ø¡›‚hïCû™<»úÐŒ­êhüýÔï Æס\@�•‰ó÷w= vV
 ýf3GÕ51b‘æi‘diNŒ�‘Œâ�±ˆ±0·"ð0àâÄßZÕ7’\sÂw
"ó‡&0ÍåþF
—?$cRÍZº”í(õåŠ:é�H^�04g¢°û(½ÀÙWáÓ
7�˜¿S,[>°úŒ¹…;î3`ô¦'b�ÕÀ¤Ö^ïöEy˜]¹œ­Þv‹íçÞa¯Úák@n@þzh|ÇütÓOÓ0J¿mºã—¿ÞeÚâš(°ÁiÇEðá
êÍ�âÀz҃ѣm§žæˆ§çOŒ$ 
 ­è×ØÚ:‰óÎÐÃBYn?z·XdÌqâd¾©Üä¤ÚNí:ørðï»QÕaáƒL·CÕMucVìâªV.Wª�4 Û8Hü»Uoy)”@»Zìo+B)ˆ×­©ôD9ƒ©;B.ÊõTyåvÂ)Î6™îZds§¡ÁÓÏMí­µ°r=¶ö�ä&vÓž®é^/yr€�¡¶¯ÓP;«y Â1{9B€FãŸà{ËוÂM>p\×-ž‘7>å	èWˆÌ¨W
 ¥Ìrcø-Š¼ûãËü
-“¤%œ¡i±Iæ² —â~ÚøÑŸ/¯6³Âv¡ám’rá÷Î.zïá°ú‹EØûÛxà8KQ”×ñܼÍBw1\­ýÎÆð»•s^ÀÍQŠ’säjMkç/Ú,ÜÚmR¡ÈEz�ís³ã¾‡ê
+“¤%œ¡i±Iæ² —â~ÚøÑŸ/¯6³Âv¡ámÒ¥ß;»è½‡CÀê/aïoã�ã<,EQ^Çsór4ÝÅpµö;[ÃïVÎy
7G)JΑOü©5­�¿|hW°hpk·IQ„"é5¶ÏÍŽûª‡]Ù)C™‹_Ú‘Âõ%KÄQXDñ¯oʬ±]ªÜïʽe×SX{üâññ|>‡¼+�¾,}�w¸ÉÀUßÄx³Q³Ô}\Wù¸·ö߶
+ߣ«�ª]qöü´Þíâ³äZÄ^d{‘¡Éep
…E\æÞ†RÊ[oóûæ½»ÿ
 endobj
-1508 0 obj <<
+1613 0 obj <<
 /Type /Page
-/Contents 1509 0 R
-/Resources 1507 0 R
+/Contents 1614 0 R
+/Resources 1612 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1487 0 R
-/Annots [ 1516 0 R 1517 0 R ]
+/Parent 1592 0 R
+/Annots [ 1621 0 R 1622 0 R ]
 >> endobj
-1516 0 obj <<
+1621 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[0 1 1]
 /Rect [348.3486 128.9523 463.9152 141.0119]
 /Subtype/Link/A<</Type/Action/S/URI/URI(mailto:info@isc.org)>>
 >> endobj
-1517 0 obj <<
+1622 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[0 1 1]
 /Rect [147.3629 116.9971 364.5484 129.0567]
 /Subtype/Link/A<</Type/Action/S/URI/URI(http://www.isc.org/services/support/)>>
 >> endobj
-1510 0 obj <<
-/D [1508 0 R /XYZ 85.0394 794.5015 null]
+1615 0 obj <<
+/D [1613 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-550 0 obj <<
-/D [1508 0 R /XYZ 85.0394 769.5949 null]
+582 0 obj <<
+/D [1613 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1511 0 obj <<
-/D [1508 0 R /XYZ 85.0394 576.7004 null]
+1616 0 obj <<
+/D [1613 0 R /XYZ 85.0394 576.7004 null]
 >> endobj
-554 0 obj <<
-/D [1508 0 R /XYZ 85.0394 576.7004 null]
+586 0 obj <<
+/D [1613 0 R /XYZ 85.0394 576.7004 null]
 >> endobj
-1512 0 obj <<
-/D [1508 0 R /XYZ 85.0394 548.3785 null]
+1617 0 obj <<
+/D [1613 0 R /XYZ 85.0394 548.3785 null]
 >> endobj
-558 0 obj <<
-/D [1508 0 R /XYZ 85.0394 548.3785 null]
+590 0 obj <<
+/D [1613 0 R /XYZ 85.0394 548.3785 null]
 >> endobj
-1513 0 obj <<
-/D [1508 0 R /XYZ 85.0394 518.5228 null]
+1618 0 obj <<
+/D [1613 0 R /XYZ 85.0394 518.5228 null]
 >> endobj
-562 0 obj <<
-/D [1508 0 R /XYZ 85.0394 460.6968 null]
+594 0 obj <<
+/D [1613 0 R /XYZ 85.0394 460.6968 null]
 >> endobj
-1514 0 obj <<
-/D [1508 0 R /XYZ 85.0394 425.0333 null]
+1619 0 obj <<
+/D [1613 0 R /XYZ 85.0394 425.0333 null]
 >> endobj
-566 0 obj <<
-/D [1508 0 R /XYZ 85.0394 260.2468 null]
+598 0 obj <<
+/D [1613 0 R /XYZ 85.0394 260.2468 null]
 >> endobj
-1515 0 obj <<
-/D [1508 0 R /XYZ 85.0394 224.698 null]
+1620 0 obj <<
+/D [1613 0 R /XYZ 85.0394 224.698 null]
 >> endobj
-1507 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R /F11 1304 0 R /F39 863 0 R >>
+1612 0 obj <<
+/Font << /F21 702 0 R /F23 726 0 R /F11 1367 0 R /F41 925 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1520 0 obj <<
+1625 0 obj <<
 /Length 69        
 /Filter /FlateDecode
 >>
 stream
 xÚ3T0
 endobj
-1519 0 obj <<
+1624 0 obj <<
 /Type /Page
-/Contents 1520 0 R
-/Resources 1518 0 R
+/Contents 1625 0 R
+/Resources 1623 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1487 0 R
+/Parent 1592 0 R
 >> endobj
-1521 0 obj <<
-/D [1519 0 R /XYZ 56.6929 794.5015 null]
+1626 0 obj <<
+/D [1624 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1518 0 obj <<
+1623 0 obj <<
 /ProcSet [ /PDF ]
 >> endobj
-1524 0 obj <<
+1629 0 obj <<
 /Length 2543      
 /Filter /FlateDecode
 >>
@@ -6694,41 +7227,41 @@ RÜŠ1ÏuL~”6�`l�¿‚~ZѨ¢<ÓCƒÚ̓
 ’
r�”OœBç=Á	1j"«¢ºÑpQɧUäzý"GöÄÙ	G,ØÝfS6äÐBdz˜€z²Ó„Q™DÏ
B0q
 �ã”U#7Cã@Q²€.ÿ¾ô
 ÝD‘øñðñ^=:\è±æí
-®o¬ƒñ+ñ'E\2}8Ç’;i%Ò‡ï&ª°Wõ\~jÀaÛÍ{³˜¢GË!zeoA
_�^†NmÞxš^Xð”Ð;’ù‚Ïr{z8Ø'"Hóȃ…×UØNÑô�
+®o¬ƒñ+ñ'E\2}8Ç’;i%Ò‡ï&ª°Wõ\~jÀaÛÍ{³˜¢GË!zeoA
_�^†NmÞxš^Xð”Ð;’ù‚Ïr{z8Ø'"Hóȃ…×UØNÑô�
 endobj
-1523 0 obj <<
+1628 0 obj <<
 /Type /Page
-/Contents 1524 0 R
-/Resources 1522 0 R
+/Contents 1629 0 R
+/Resources 1627 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1529 0 R
+/Parent 1634 0 R
 >> endobj
-1525 0 obj <<
-/D [1523 0 R /XYZ 85.0394 794.5015 null]
+1630 0 obj <<
+/D [1628 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-570 0 obj <<
-/D [1523 0 R /XYZ 85.0394 769.5949 null]
+602 0 obj <<
+/D [1628 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1526 0 obj <<
-/D [1523 0 R /XYZ 85.0394 573.5449 null]
+1631 0 obj <<
+/D [1628 0 R /XYZ 85.0394 573.5449 null]
 >> endobj
-574 0 obj <<
-/D [1523 0 R /XYZ 85.0394 573.5449 null]
+606 0 obj <<
+/D [1628 0 R /XYZ 85.0394 573.5449 null]
 >> endobj
-1527 0 obj <<
-/D [1523 0 R /XYZ 85.0394 539.0037 null]
+1632 0 obj <<
+/D [1628 0 R /XYZ 85.0394 539.0037 null]
 >> endobj
-578 0 obj <<
-/D [1523 0 R /XYZ 85.0394 539.0037 null]
+610 0 obj <<
+/D [1628 0 R /XYZ 85.0394 539.0037 null]
 >> endobj
-1528 0 obj <<
-/D [1523 0 R /XYZ 85.0394 510.2426 null]
+1633 0 obj <<
+/D [1628 0 R /XYZ 85.0394 510.2426 null]
 >> endobj
-1522 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R >>
+1627 0 obj <<
+/Font << /F21 702 0 R /F23 726 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1532 0 obj <<
+1637 0 obj <<
 /Length 2893      
 /Filter /FlateDecode
 >>
@@ -6737,880 +7270,877 @@ xÚ­ksã¸í{~…¿Õ™‰IÔ3ÛéL.›ls×Ë¥‰;íÌíÍ”–h[]Yò‰r²¹__€
 'é<%Ø«Ô4hνd®J%µÊ‰¢¨ó¬ö­Ú­TCSßu]"�UN ‚yH‚ïäêfÈõµ)ZE¸zMˆJɦ|ãeeÉõ^e-3³”í–—ª\~4
 hfáyN†¾9fùVT²"ŸFÒÐg[Ø>k$ŒÓ­%ya4P’~¯$œø#Ìùp
 "
‡Ï®ëgýFÐ\í‰s&[ÔÂŒjp`‹1ãÄ.}Qe½ß©ª%€Ý)«+]ðq‰§
-~H¿°OQ­4Áæ:“¥$o…Ù=ŠR©–fì-DM¸û"�çËm/Èá¤ÝÒÌNßöæ@1t$ê÷Š,s¸b,Â)PøTE&u;aBá9±èèðV$ÑÜ\{؆,CfáCƒUP9'°ÐßHI"ð掉z�Û›äÄ”‰ïˆDø¼ùuõöž�è‚��"FHÜm,$BŒëàæV4P}#¡ô
-±AiÏK:·úCÛÅÂñCa×R¾_~à‰�-³¤üœö
-É‘
9R �P)�0¦†Œi‚4`(M§6ó'óÃ^S(Wr7dg51™hïŸÏ=¨m/̹?5YŽ¥ÚlË7“ìÌ(Ø… ¾È5o]÷"L¸6xc0¡q²m
-©—´¦5õÃD 	œ$ŒlH„r«å&Âçݳ5º?¾·hdµÁk+ §/-UçI0>
+~H¿°OQ­4Áæ:“¥$o…Ù=ŠR©–fì-DM¸û"�çËm/Èá¤ÝÒÌNßöæ@1t$ê÷Š,ví-#‚Ø
ˆp
+þU‘IÝN˜PxN,::¼I47׶!Ë�YøÐ`TÎBÄ	,ôÆ·R’¼¹†c¢Dàö&ù0!eâ;">o~]½½'¤
+æíœH¸>ø8þzduÖ+ž™ ‰èMY¯0† Ð:„™¼‰(5Dò�â=@¶«‡›}´ÁãBnÑŠw|º»!&ñÅÔeúìûÁ'ãL'Ž©‡â àÎläࢩìÒG¯Ã�Íq�Iôo£´œ²<Ô‰PÓlÏÍ@ÔÁUæÄG» y¿Nxø¸ë=ãÝ=}ÊSK¨+Š˜5†þsºC:¡'¼£ªÜ¦ÂCìDPÚó’έþÐv±püPص”ï�8AâÇcË,)?§½Er¤@@Žh T
+$Œ©!cš 
JÓ©ÍüÉü°×Ê•Ü
Ù™E
AL&
ÚûçÇsjÛsîOM–c©6ÛòÍ$;³
+v!¨/rÍ[×½®
ÞLh܇l›„´¦5õÃD 	œ$ŒlH„r«å&Âçݳ5º?¾·hdµÁk+ §/-UçI0>
 è¾ÏÝG$”uf,Õ­DC¡Æüx¾;˜t
-(–
"—ÜYi4¹B™º¦qfèY'ÉíŽÑ–�\z
¬nÌ\³&ÊKŸ	‰•v(Äð1“‘㣓Æ|ÒØŠž«�ˈ�p}µ6eè£[SWöj›ŸMñ¢Âú`K@®Ö j]¼©VP%Û
-·KÊÿóWÞþCw;"Iüé¸~œ8
Ô¥V(<AêŸHn?ŸŠþ_a52…endstream
+(–
"—ÜYi4¹B™º¦qfèY'ÉíŽÑ–�\z
¬nÌ\³&ÊKŸ	‰•v(Äð1“‘㣓Æ|ÒØŠž«�ˈ�p}µ6eè£[SWöj›ŸMñ¢Âú`K@®Ö j]¼©VP%Û
 endobj
-1531 0 obj <<
+1636 0 obj <<
 /Type /Page
-/Contents 1532 0 R
-/Resources 1530 0 R
+/Contents 1637 0 R
+/Resources 1635 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1529 0 R
-/Annots [ 1536 0 R 1537 0 R ]
+/Parent 1634 0 R
+/Annots [ 1641 0 R 1642 0 R ]
 >> endobj
-1536 0 obj <<
+1641 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[0 1 1]
 /Rect [253.7995 146.8976 417.685 158.9572]
 /Subtype/Link/A<</Type/Action/S/URI/URI(ftp://www.isi.edu/in-notes/)>>
 >> endobj
-1537 0 obj <<
+1642 0 obj <<
 /Type /Annot
 /Border[0 0 0]/H/I/C[0 1 1]
 /Rect [63.4454 108.9117 208.8999 119.0735]
 /Subtype/Link/A<</Type/Action/S/URI/URI(http://www.ietf.org/rfc/)>>
 >> endobj
-1533 0 obj <<
-/D [1531 0 R /XYZ 56.6929 794.5015 null]
+1638 0 obj <<
+/D [1636 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-582 0 obj <<
-/D [1531 0 R /XYZ 56.6929 652.1213 null]
+614 0 obj <<
+/D [1636 0 R /XYZ 56.6929 652.1213 null]
 >> endobj
-1534 0 obj <<
-/D [1531 0 R /XYZ 56.6929 614.8935 null]
+1639 0 obj <<
+/D [1636 0 R /XYZ 56.6929 614.8935 null]
 >> endobj
-586 0 obj <<
-/D [1531 0 R /XYZ 56.6929 614.8935 null]
+618 0 obj <<
+/D [1636 0 R /XYZ 56.6929 614.8935 null]
 >> endobj
-1072 0 obj <<
-/D [1531 0 R /XYZ 56.6929 584.5024 null]
+1127 0 obj <<
+/D [1636 0 R /XYZ 56.6929 584.5024 null]
 >> endobj
-590 0 obj <<
-/D [1531 0 R /XYZ 56.6929 289.5256 null]
+622 0 obj <<
+/D [1636 0 R /XYZ 56.6929 289.5256 null]
 >> endobj
-1535 0 obj <<
-/D [1531 0 R /XYZ 56.6929 251.3901 null]
+1640 0 obj <<
+/D [1636 0 R /XYZ 56.6929 251.3901 null]
 >> endobj
-594 0 obj <<
-/D [1531 0 R /XYZ 56.6929 251.3901 null]
+626 0 obj <<
+/D [1636 0 R /XYZ 56.6929 251.3901 null]
 >> endobj
-900 0 obj <<
-/D [1531 0 R /XYZ 56.6929 222.7156 null]
+955 0 obj <<
+/D [1636 0 R /XYZ 56.6929 222.7156 null]
 >> endobj
-1538 0 obj <<
-/D [1531 0 R /XYZ 56.6929 53.7852 null]
+1643 0 obj <<
+/D [1636 0 R /XYZ 56.6929 53.7852 null]
 >> endobj
-1539 0 obj <<
-/D [1531 0 R /XYZ 56.6929 53.7852 null]
+1644 0 obj <<
+/D [1636 0 R /XYZ 56.6929 53.7852 null]
 >> endobj
-1530 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F21 658 0 R /F47 879 0 R /F53 962 0 R /F11 1304 0 R /F39 863 0 R >>
+1635 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F39 885 0 R /F53 1017 0 R /F11 1367 0 R /F41 925 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1542 0 obj <<
+1647 0 obj <<
 /Length 2824      
 /Filter /FlateDecode
 >>
 stream
-xÚµZ]{£6¾Ï¯ð¥ý<-’ KÇö¤É4™4v·Û�α›g0¸g&ýõ{„>äζûä" ôâóžO	<òà�"†<ÊýQÈ}Ä<ÌFëý•7ÚÂÜíV2×ZèÚ–ºY]ýó
Gñ€£Õgk­yQ„G«ÍÇñôéiñ8¿û÷äš0o<E“kæyzt¶XN®Ã€‹	*¦o|swóã݇Ûçéӿʇ~ó˜7}œË›åÏ··‹åj¡nŸÓùÝã-ˆàɧÕýÕbe^ÛþiØ£â�¿úøÉmàÞ_yˆòˆ�¾Â�‡0çd´¿òȨT�dWË«ŸÌ‚ÖlýhŸª�‹HØ£+‚G#Îi)‹qPBke-«8ßÄÇM9ø[¨�(c—h²¤$4í£IK	ä�Ïïf $ÿS3EÞÝ	m¤Î±}ÛD0c(
-)kƒÏ‹}œæ’ÐÇxŸ”ŠwBBy5+òur¨Ô8èH^¼‹×i–ViRë«ó3qè!„¼ Àø‡|äi‚	£Érì¡X‰IuLK%õX¼&û—ä(ï0�B4ÈÀVüKŒXRF´”Ås0₶éb0bƒ_dänÈ’}’Wq•y‡—å!Y§¿yYËÙsr&@¿ö’#oþ>Š�(½@‘-5L‘‘ÒñÐá3N䆡3è~†ZØqš©Xœª4ßv8¨v‰¼°©\¾•U²ïs1Òç¼ÍÇLiÿ)>‚æ7ÛD�ßÇù)>¾ÕH-ÙŠpׄøˆG Z*~€O꥟ŽÅ¡(m)—^@Eäw–”ƒ;-eÜ‹s‡{9¡-òºØäÙàwùú8ÁÑXz�âñ?E®([M0Æãcœ—Ÿµ�kç�Ë>ú|Œp
-�ªèf1ˆ{²¶À,@^C-·{FæBþ¿9•;yµÈþЉ픽ý&A$¢ä–”ƒ	-e˜ ^ä`Âm1ÑÅ`ÂL¶ ÒWÕâõÎT:è~:%Ç�²›r„I@úSÑ4ßÈÄ÷U×qq=°Þ½GÃz‡¦
CP½ wKÊ¡w-eô„.pA[zïbèÝ_|«’¼4	Æ$§²“�ŒòE?¼€;Ow½g�F¡€ùŸóŽÃô1|‰KÊA�–²( 
-\Ð]ì

-lðÇ"¿–EWrܧ¹®ÈŒÆe‚©£G²I¥¯ÃC$d´ß
fÇø«`VØôëžêÞ^"ˆ|nÝÛRú7RF÷‘洞�Ð�îÏ°ûuß_&ª* lü>y“M¯UýEÐ䄼JMM’ÒEàBÂEVË»Û
!„"/bØâj<nÀCüq:Ácå$”�?¨©ÛÓfé»”E
¡Ñx®fqY]˼o Zy?‹¿h—£-#0}Û�2”_&œŒ“,ƒ\Iœ:XªôD<(›í$QQ~ÁN,)‡�h)c'œz;qA[vÒÅ°¼e' i'"}—Uü’¥åN4S®˜¹z¿P;ŠÏÏC¡3âÈçAgÓh®8ô2¸L•µ#áfÈçˆr‰!KÊÁ�–²r$2'´ÅP{€!Ü(û9ùý”è�f,»ÇŸ…ÚÒmW'ImÙ�%�׫s\9äÆÔ”ðÿ7[#àKlYR¶´”f‹z^è`Ëm±ÕÅ`ËRZ?ß'jò�j¨-ÀqM†|D·kâF¶k½Á#ƃ6IÎ0×ÞÛssƒ)�è7–”ƒ-e¸	œ9ÑmqÓÅàÆ¿Mr¨¯…bÃP•V"Ú…
Ü_Óu"§¦Ù¶€©Ý^ÎÉ°'ib%ÜËX	=>(–éæT{-éÕp!è¿].e~ót^“§<®\Ë�ÏüN9´Tô¿ÿç}õé­ì
-¶º/ÓÃi&·hÞêß¡fÔ_¦/Å«=sß²²~e|–pu?øCœejîú*ló£ýû›<€æ©»¿Ù4ª
mõÖÒwm{RßCKqšµ-5lÖFʘ5!³vB7f}†ÝoÖ-ð»|SÛ˜n+Ÿ“²È^µ¢—§Ã¡8Vgçr1ëËÔ
ƒØ±þØ?+ò£¡zž¬Ûá†
-±ŠSzIï–”CïZÊè=¢Ô¡w´¥÷.ö€ÞmðÕNFƒ”/
]xœ½•i)Źµfk
®ÕÖ\éL ®íLÐð©p’f¯M¬Šxõ%Í´Ü-ƒ‹g=	�P’Š�àã@wFªžV‹¶êi Ó$“pŒ"^Ø#µ¥†É4RšLßs‘é„nÈ<Ãî'³^Ìí¼€y¾U
É|\lN*²‹ÑZÁBX”disæлsùбØÅ”ÕĈç§òYèzº†11ú FŒ�ª;òdw$^æ!.ËDGn¹9ª [œ6LjHp•IÿnÐφé0
-=|a¿Ô–rЯ¥,ú1Ô	mÑßÅ ßWgU±.Ä.øÌC±él FD¥oíÕbD&&áÈMb‚;¹û}nýlŸ3C¯îs;s,“&,Ú63a;²}PâÚ,”G«•[ìëÞ2–Îñò_´¨‚™èÌÝvaI9ìBK5vá;΃�Ж]t±ì¹TÖó¢8„È#ëB”õMm”F*ÊSU׉‹ÆÄ�Ù�ì5,>}ñ­}ʸÞ´#š‰È21ú ÄMŒƒsu\bZFñ÷ÃY
‚©À²¸ ¡£ùÈ

-’Xï*
+xÚµZ]{£6¾Ï¯È¥ý<-’ KÇö¤É4™4v·Û�α›glH
ÎLúë÷} 0’;Ûî“‹€tЋÏ{>%ðe
+’_.×G“ÇÇùÃìößã+‚Ñ�¯XèÑé|1¾Š#.&¨˜Š‚Ñõíõ�·nž&�?ü*ú-`Áäa&o?ßÜÌ˹º}šOf·7 ‚ÇŸ–wó¥ymû§á€Šwþýâã§àr
¿ðî"@”'ìò+ÜsN.÷!£ˆ…”ê‘ÝÅââ'³ 5Û<:¤*FÄèŠàKŒgŒt”Å8Š(¡�²uZ¬Óúrþ"ÊØ9š,)	M‡hÒRùãÓ»)()üÔGÆ,@	‡w÷B©SlÊ-lÌJbʺà³rŸæ…$ô!Ýg•â��X^MËb•½Ôjt$/Þ¥«|—×yÖè«÷3q Å	¼ Àø‡|äqŒ	¡Érì¾\}I_²ú�WJê¡|ÍöÏÙAÞažÄÈÉŽÀVÂsŒXRF´”Åó0⃶éc;±ÁÏ2r»Ùeû¬¨Ó:/‹/‹—l•ÿd%gOÉ!˜
+¨¯…bãX•×"ÚÅÜ^óU&§&»M	SÛ½œ“aO>ÒÆJ¸—±$|P,ÓÏ©öZÒ«áBгXÈüè¼&Oy|¹–¡�…½rh¡èÿ5-†êÓÙlt_¦‡ó�Ü¢yk~‡šýQ;|•?—¯öÌ]ÇÊ*ø•éIÂÕýàén§æ>¬êÒ6?:¼¿É#hžúû›m£ÚÒÖl-}׶'
ð0ö›µ-å6k#eÌš�Y{¡[³>Á6ëøm±nlL·•OYUî^µ¢Ç——òPŸtœ‹ùt(SGb†cÿ´,†êY¶ê†ì'b§ôœÞ-)�Þµ”Ñ{B©Gï>hKï}l‡ÞmðåVFƒ”/
]xº{«òJÞ	U‹ÿrk
.ÌÖ\«­5¸Ò™@\Û™`8àSá$í^›X)ðúK^(h¹[Oz:¡,!!Ä‘îŒT=­íÔÓ@fè$“pŒŸÙ#µ¥Üd)MføÈôB·dž`“Ù
oæv^À<
ߪ�d>*×GÙÅh£`!,J²¼=sܹIBèXìb*HbÄóù,t=ý	ؽW£?¦Õ²;/sŸVU¦#·ÜU�NÛcD¤¸ªlx·ègnú#Œâ
+-©ôfªò·¸híEÜ™]§Áƒ,>q­þ˜2.�”öl¡�H,[£÷JÜØ‚œ©mqƒÐ¡¾c!½3å¿hPú2ÑŽû�Á’òƒ–²ŒÁ“P½Ð–1ô±Æ`ƒ««º\•bË
+è}¹îí¦'DÕr:Ä‹Y¥ˆ¨ÞV)p'�bŒG.» 1JBnsË
+
+íÆ3aGu1z¯Äµ]¨ð®Vî؃Nç�]œp1èž
+´¸ ¤ƒùÈ

+’Tï*
+µ�9Te>#ôá¶6Ø6Ay2¾b$´ÌHÜ)³|Þ‰zA4lY3ª#Óò`ï§6c¿ŒI0‚¶Æ¾[g;µú,{Ù•oúùFÿÍ+”Ÿë¯’ù
Ø.…‚1¦‘•ß‹WñÈÌvìï&}•/\u˜sê8˜$Ðk“3�©-å¡ZKY\{h½ÐÙ}lÛ6ø´Üïå®+Ö›­ßÁä\²Z*)#ý&ÇÍ:±¦‚ñwù·á£s£˜cû‰†Íçƒb‘÷Ç}ªO]žkÓçÁj�%¬¼SƒS5ø��´‰3zÝÏ�Þs–äWœ¹Ïw;sâû}&ÁDÂ(ò[„%ä6-Ô~P‘xN|¸­9ô�‡­ÁF^d‡\•<ÛkÒlIdu¾ª2!³ðôtÖÅ:Úsq\û½I$�Ø‚?Sÿ[Bn…k¡6ãû>ûòá¶
+ï+ÜF6Þuþ}^=gÛô5Õ Œ@õµ�®­ÑLKç„}RÛˆÈB
 endobj
-1541 0 obj <<
+1646 0 obj <<
 /Type /Page
-/Contents 1542 0 R
-/Resources 1540 0 R
+/Contents 1647 0 R
+/Resources 1645 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1529 0 R
+/Parent 1634 0 R
 >> endobj
-1543 0 obj <<
-/D [1541 0 R /XYZ 85.0394 794.5015 null]
+1648 0 obj <<
+/D [1646 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1544 0 obj <<
-/D [1541 0 R /XYZ 85.0394 752.3015 null]
+1649 0 obj <<
+/D [1646 0 R /XYZ 85.0394 752.3015 null]
 >> endobj
-1545 0 obj <<
-/D [1541 0 R /XYZ 85.0394 752.3015 null]
+1650 0 obj <<
+/D [1646 0 R /XYZ 85.0394 752.3015 null]
 >> endobj
-1546 0 obj <<
-/D [1541 0 R /XYZ 85.0394 752.3015 null]
+1651 0 obj <<
+/D [1646 0 R /XYZ 85.0394 752.3015 null]
 >> endobj
-1547 0 obj <<
-/D [1541 0 R /XYZ 85.0394 746.3107 null]
+1652 0 obj <<
+/D [1646 0 R /XYZ 85.0394 746.3107 null]
 >> endobj
-1548 0 obj <<
-/D [1541 0 R /XYZ 85.0394 731.5461 null]
+1653 0 obj <<
+/D [1646 0 R /XYZ 85.0394 731.5461 null]
 >> endobj
-1549 0 obj <<
-/D [1541 0 R /XYZ 85.0394 728.1497 null]
+1654 0 obj <<
+/D [1646 0 R /XYZ 85.0394 728.1497 null]
 >> endobj
-1550 0 obj <<
-/D [1541 0 R /XYZ 85.0394 713.3851 null]
+1655 0 obj <<
+/D [1646 0 R /XYZ 85.0394 713.3851 null]
 >> endobj
-1551 0 obj <<
-/D [1541 0 R /XYZ 85.0394 709.9887 null]
+1656 0 obj <<
+/D [1646 0 R /XYZ 85.0394 709.9887 null]
 >> endobj
-1552 0 obj <<
-/D [1541 0 R /XYZ 85.0394 651.9592 null]
+1657 0 obj <<
+/D [1646 0 R /XYZ 85.0394 651.9592 null]
 >> endobj
-1016 0 obj <<
-/D [1541 0 R /XYZ 85.0394 651.9592 null]
+1071 0 obj <<
+/D [1646 0 R /XYZ 85.0394 651.9592 null]
 >> endobj
-1553 0 obj <<
-/D [1541 0 R /XYZ 85.0394 651.9592 null]
+1658 0 obj <<
+/D [1646 0 R /XYZ 85.0394 651.9592 null]
 >> endobj
-1554 0 obj <<
-/D [1541 0 R /XYZ 85.0394 648.8377 null]
+1659 0 obj <<
+/D [1646 0 R /XYZ 85.0394 648.8377 null]
 >> endobj
-1555 0 obj <<
-/D [1541 0 R /XYZ 85.0394 634.0731 null]
+1660 0 obj <<
+/D [1646 0 R /XYZ 85.0394 634.0731 null]
 >> endobj
-1556 0 obj <<
-/D [1541 0 R /XYZ 85.0394 630.6767 null]
+1661 0 obj <<
+/D [1646 0 R /XYZ 85.0394 630.6767 null]
 >> endobj
-1557 0 obj <<
-/D [1541 0 R /XYZ 85.0394 615.9121 null]
+1662 0 obj <<
+/D [1646 0 R /XYZ 85.0394 615.9121 null]
 >> endobj
-1558 0 obj <<
-/D [1541 0 R /XYZ 85.0394 612.5156 null]
+1663 0 obj <<
+/D [1646 0 R /XYZ 85.0394 612.5156 null]
 >> endobj
-1559 0 obj <<
-/D [1541 0 R /XYZ 85.0394 585.7959 null]
+1664 0 obj <<
+/D [1646 0 R /XYZ 85.0394 585.7959 null]
 >> endobj
-1560 0 obj <<
-/D [1541 0 R /XYZ 85.0394 582.3994 null]
+1665 0 obj <<
+/D [1646 0 R /XYZ 85.0394 582.3994 null]
 >> endobj
-1561 0 obj <<
-/D [1541 0 R /XYZ 85.0394 567.6349 null]
+1666 0 obj <<
+/D [1646 0 R /XYZ 85.0394 567.6349 null]
 >> endobj
-1562 0 obj <<
-/D [1541 0 R /XYZ 85.0394 564.2384 null]
+1667 0 obj <<
+/D [1646 0 R /XYZ 85.0394 564.2384 null]
 >> endobj
-1563 0 obj <<
-/D [1541 0 R /XYZ 85.0394 549.5337 null]
+1668 0 obj <<
+/D [1646 0 R /XYZ 85.0394 549.5337 null]
 >> endobj
-1564 0 obj <<
-/D [1541 0 R /XYZ 85.0394 546.0774 null]
+1669 0 obj <<
+/D [1646 0 R /XYZ 85.0394 546.0774 null]
 >> endobj
-1565 0 obj <<
-/D [1541 0 R /XYZ 85.0394 531.3128 null]
+1670 0 obj <<
+/D [1646 0 R /XYZ 85.0394 531.3128 null]
 >> endobj
-1566 0 obj <<
-/D [1541 0 R /XYZ 85.0394 527.9163 null]
+1671 0 obj <<
+/D [1646 0 R /XYZ 85.0394 527.9163 null]
 >> endobj
-1567 0 obj <<
-/D [1541 0 R /XYZ 85.0394 513.1518 null]
+1672 0 obj <<
+/D [1646 0 R /XYZ 85.0394 513.1518 null]
 >> endobj
-1568 0 obj <<
-/D [1541 0 R /XYZ 85.0394 509.7553 null]
+1673 0 obj <<
+/D [1646 0 R /XYZ 85.0394 509.7553 null]
 >> endobj
-1569 0 obj <<
-/D [1541 0 R /XYZ 85.0394 483.0356 null]
+1674 0 obj <<
+/D [1646 0 R /XYZ 85.0394 483.0356 null]
 >> endobj
-1570 0 obj <<
-/D [1541 0 R /XYZ 85.0394 479.6391 null]
+1675 0 obj <<
+/D [1646 0 R /XYZ 85.0394 479.6391 null]
 >> endobj
-1571 0 obj <<
-/D [1541 0 R /XYZ 85.0394 464.8745 null]
+1676 0 obj <<
+/D [1646 0 R /XYZ 85.0394 464.8745 null]
 >> endobj
-1572 0 obj <<
-/D [1541 0 R /XYZ 85.0394 461.4781 null]
+1677 0 obj <<
+/D [1646 0 R /XYZ 85.0394 461.4781 null]
 >> endobj
-1573 0 obj <<
-/D [1541 0 R /XYZ 85.0394 446.7135 null]
+1678 0 obj <<
+/D [1646 0 R /XYZ 85.0394 446.7135 null]
 >> endobj
-1574 0 obj <<
-/D [1541 0 R /XYZ 85.0394 443.3171 null]
+1679 0 obj <<
+/D [1646 0 R /XYZ 85.0394 443.3171 null]
 >> endobj
-1575 0 obj <<
-/D [1541 0 R /XYZ 85.0394 428.5525 null]
+1680 0 obj <<
+/D [1646 0 R /XYZ 85.0394 428.5525 null]
 >> endobj
-1576 0 obj <<
-/D [1541 0 R /XYZ 85.0394 425.156 null]
+1681 0 obj <<
+/D [1646 0 R /XYZ 85.0394 425.156 null]
 >> endobj
-1577 0 obj <<
-/D [1541 0 R /XYZ 85.0394 355.0758 null]
+1682 0 obj <<
+/D [1646 0 R /XYZ 85.0394 355.0758 null]
 >> endobj
-1578 0 obj <<
-/D [1541 0 R /XYZ 85.0394 355.0758 null]
+1683 0 obj <<
+/D [1646 0 R /XYZ 85.0394 355.0758 null]
 >> endobj
-1579 0 obj <<
-/D [1541 0 R /XYZ 85.0394 355.0758 null]
+1684 0 obj <<
+/D [1646 0 R /XYZ 85.0394 355.0758 null]
 >> endobj
-1580 0 obj <<
-/D [1541 0 R /XYZ 85.0394 352.0499 null]
+1685 0 obj <<
+/D [1646 0 R /XYZ 85.0394 352.0499 null]
 >> endobj
-1581 0 obj <<
-/D [1541 0 R /XYZ 85.0394 337.3452 null]
+1686 0 obj <<
+/D [1646 0 R /XYZ 85.0394 337.3452 null]
 >> endobj
-1582 0 obj <<
-/D [1541 0 R /XYZ 85.0394 333.8889 null]
+1687 0 obj <<
+/D [1646 0 R /XYZ 85.0394 333.8889 null]
 >> endobj
-1583 0 obj <<
-/D [1541 0 R /XYZ 85.0394 309.8192 null]
+1688 0 obj <<
+/D [1646 0 R /XYZ 85.0394 309.8192 null]
 >> endobj
-1584 0 obj <<
-/D [1541 0 R /XYZ 85.0394 303.7727 null]
+1689 0 obj <<
+/D [1646 0 R /XYZ 85.0394 303.7727 null]
 >> endobj
-1585 0 obj <<
-/D [1541 0 R /XYZ 85.0394 278.3282 null]
+1690 0 obj <<
+/D [1646 0 R /XYZ 85.0394 278.3282 null]
 >> endobj
-1586 0 obj <<
-/D [1541 0 R /XYZ 85.0394 273.6565 null]
+1691 0 obj <<
+/D [1646 0 R /XYZ 85.0394 273.6565 null]
 >> endobj
-1587 0 obj <<
-/D [1541 0 R /XYZ 85.0394 246.9367 null]
+1692 0 obj <<
+/D [1646 0 R /XYZ 85.0394 246.9367 null]
 >> endobj
-1588 0 obj <<
-/D [1541 0 R /XYZ 85.0394 243.5403 null]
+1693 0 obj <<
+/D [1646 0 R /XYZ 85.0394 243.5403 null]
 >> endobj
-1589 0 obj <<
-/D [1541 0 R /XYZ 85.0394 173.5556 null]
+1694 0 obj <<
+/D [1646 0 R /XYZ 85.0394 173.5556 null]
 >> endobj
-1590 0 obj <<
-/D [1541 0 R /XYZ 85.0394 173.5556 null]
+1695 0 obj <<
+/D [1646 0 R /XYZ 85.0394 173.5556 null]
 >> endobj
-1591 0 obj <<
-/D [1541 0 R /XYZ 85.0394 173.5556 null]
+1696 0 obj <<
+/D [1646 0 R /XYZ 85.0394 173.5556 null]
 >> endobj
-1592 0 obj <<
-/D [1541 0 R /XYZ 85.0394 170.4341 null]
+1697 0 obj <<
+/D [1646 0 R /XYZ 85.0394 170.4341 null]
 >> endobj
-1593 0 obj <<
-/D [1541 0 R /XYZ 85.0394 144.9896 null]
+1698 0 obj <<
+/D [1646 0 R /XYZ 85.0394 144.9896 null]
 >> endobj
-1594 0 obj <<
-/D [1541 0 R /XYZ 85.0394 140.3179 null]
+1699 0 obj <<
+/D [1646 0 R /XYZ 85.0394 140.3179 null]
 >> endobj
-1595 0 obj <<
-/D [1541 0 R /XYZ 85.0394 113.5982 null]
+1700 0 obj <<
+/D [1646 0 R /XYZ 85.0394 113.5982 null]
 >> endobj
-1596 0 obj <<
-/D [1541 0 R /XYZ 85.0394 110.2017 null]
+1701 0 obj <<
+/D [1646 0 R /XYZ 85.0394 110.2017 null]
 >> endobj
-1597 0 obj <<
-/D [1541 0 R /XYZ 85.0394 95.4372 null]
+1702 0 obj <<
+/D [1646 0 R /XYZ 85.0394 95.4372 null]
 >> endobj
-1598 0 obj <<
-/D [1541 0 R /XYZ 85.0394 92.0407 null]
+1703 0 obj <<
+/D [1646 0 R /XYZ 85.0394 92.0407 null]
 >> endobj
-1540 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R >>
+1645 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F39 885 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1601 0 obj <<
+1706 0 obj <<
 /Length 2889      
 /Filter /FlateDecode
 >>
 stream
-xÚµš[w›º€ßó+üh¯Õh£·G»‰ÛÄͱ“ž½WwˆMV0¤·Í¿?#tA`Ý笳ò�
֧͌ÀþðÄõ�’pâ‡¹v'Ûý™3ù}WgXÊœ+¡sSêâþì�÷ÔŸ„(ôˆ7¹2Æ
-�xr¿û2�E3Á™^,/n–Ÿ®ÖÑÝõ_³sâ:Ó¿׉Vsq³y¸ºZlîòv½ˆæËÕˆàÙ¹ï…Î4º»[¬æË?EÄGutëåb3ûzÿálq¯_ÛüiØ¡ü�¿Ÿ}ùêLvð?œ9ˆ†�;ù	7ÂaH&û3æRä2JUKv¶9û—Ðè­í�*ì B=Ò3WO0F¡ë’Öd¹!ò(¡õd­“²8¶‰œ‚d[vâú~3ðöš”ƒ¿’bä»
-vL+õà%ø@ïà)âL/ÑûYH¦HŒ±ø‘f8˜>LJªÀÓÙÕÿÉô6ÞÇ/E){ײ÷!ËöqžËAã|'šïf˜„jðÛbû¿&Õ!…§áý`&Ô+�‹e ìãÓ¶*á=jÊ°è4DØCxl„°)5LXKi¾ã
¶ªnŸèî%ÜÒ-ÀÂO_m¢;µì¹p0mCèÅºýÐ
Ì �Äÿ[€”æßÄ�ÀÄG“½—E–dY,Ÿér`Ã|ÐO±?ÂÁ�²pPRšCàÛ8ØTººû9˜º#¾–ýémƒ9Á¥7}*¢mñ뵦‘”¥˜Lè¼)¶17=!±ÌAx¯¼i*;ªçD\Ì‹}œÊÎU¼—­›·²Jö=X©ƒ‘˽hƒ•b°^9Xü#-e[csÐñyæºÓôWšH‹ÓÃœkÇ£ÝÏ|6Eï:«b)WÅ<ݾ¤yYäRàCœãÛ^Þðº`°í1:fŸ†”e]()µ.ˆã˺°©6ÖEWwÿº0uú ØfJ1«ý/o¨W¿Ø¼&Ûôé­^ü¾FÎ%›%›‹')ž~¤Û¤D=Ô‰"L‰A�aîŠù“WÇìñ
-jt¼G¯
~c¬�úqe×õ‚ÐZÂN{»îH`dJY¨*)M{–}ÕªÚ ÚÕÝOÕÔý ,fBò‚‹e^%‡<©Ä�
-
-
-þC§)vŽ¶á‘�·‘±02Š ÅØâ^-J
~m­ýô­<ÐÝ\GçX`Èl„ÈP—Â%D‹L^àJj±ªÞ£z‹uõ7®G¶Ë
-<¢8´3„†�)!
Ì
-¥
›ÞXWq/0S±¨¡þª’¼¬O*avDMþ—Ç××âP	¡å�hü‘JQ6‡F¯¯2ãcäx¡±2âN7H<qÿ\ìE¾À[/eëõ1[�eëg]0‡®�ešÇy%»D
-ͪ§µµ�iqLË2í«ÿ
-w,!0¥,””Në(¶ìZVÕ†®î~¦îË,.ËL‡‚ËÕy4Ÿ¯Q´Þ%ú�é†åw&ûZUUÒ]ž('t%w’æU=÷EQu¿Âèx¶æ(¿Ùð¹.†ìÎÁÁȱ½)eA¦¤4²€X¢I«jYWw?2S÷2ºP[/Q$ÛçÜS¦>gÚs'÷¡îaÓCž~?&Ý`ôn:®ç·Á¶�e$Q@XÙ±Ô‹"îTÐ~§rÀÏƾ²0„†i)¡¦lB,•j›Þ†UWq/*S±öq,P>Ž…ÜÇÍ ­®Ý;UL�\F«H\]B®�î’C<ô}#/iz¤uú#Ö)5<n¦ÔÐl¤Ô¼S
-]Ô…­<Ažÿ»¶¶,Kã½úbQ+iÅþÚX;ŸÙ
š–:‹‹ø÷´=“ïè˜ôþlרŠûˆÁ@ðBü
+xÚµšKsÛ8Çïþ:JU1>�´¥ØJlÅ+ÙÙ™Êä@KtÌ2E:"•Äß~ă E‚™ÝÚòÁÐÄ_ÂÝ@7I&þÈÄõ�Òpâ‡r1q'Ûýž|ƒ¾«3"mΕѹiuqöÇ{æOBzÔ›Ü?c
™Üï¾L#ÄÐFÀÓ‹åÅÍòÓÕ:º»þkvN]<ý»8ZÍŇÍÃÕÕbs¿�׋h¾\]�	™�û^ˆ§ÑÝÝb5_þ)ú#>*Ö­—‹Íìëý‡³Å½þÚæO#˜ñïüýìËW<ÙÁ/üp†wò>`DÂ�NögŽË�ë0¦Z²³ÍÙ¿ô€Fo}kïTŒ(óhÏ\Q2!…®K[“å†Èc”Õ“µNÊâxØ&r
+’mq؉ëûÌÀÛkRþJF�ï;@ÃJ|)ÖPYñïôeýþ’�€}í*Ja:\ß.­­NµYhhê#—úmíUò~>aÓùj#.ÖkÙ�ü�1ÍÓ*-òzN:?…`¦•yð%ø@ïà.Š§—èý,¤S$ÆXüH3LŸãCU�é�ìŠêÿtzïã—¢”½kÙû�eû8Ïå q¾Íw3BC5øm±}‰_“ê�ÂÝðý`&ÔW:Ë@øǧmU<Â÷¨)âÃhˆ°†(ðœ¦Õ0am¥	ûØ&l•nŸh÷ni°ðÓW›èN-{îLÛz1ƒ¶ú¡�ì/�ø�Òü›ø 0ñÑdïe‘%YË{ºœa>è3â�p0¬,”•æø66iƒCW»Ÿƒ©ñµìOo“Ü	.½éSqm‹_¯5�¤,ÅdBçM±�¹ë	‹eÆ{ÝàMSÙQ='âb^ìãTv®â½lݼ•U²ïÁÊ0A.�¢
VFÀ{å`ñ�´”m�ÏAÇç™ëNÓ_i"=Ns®/Œv?ó�)z×YK¹*æéö%ÍË"—âüÞôºð†×…ÛžÃÆüÓ°²¬e¥ÖÅ.µ¬›´±.ºÚýëÂÔ†uÁˆ+Ü”§Ž¿¼¡^übóšlÓ§·zeðÏ5rnÙ,Þ\<Ióäð#Ý&%ê¡Nqˆ£u„y(æw^³Çà*“\Ôèx�^üƒ±êÛ•_×B+´„�*ñqÝ‘ƒ‘ie¡ª¬4UâYöU«´Aµ«ÝOÕÔ~ž3!yÁÅ2¯’CžTâ“
+†•…‚²Ò`¯·P°IºÚýLíù&?ýã⯲s¬Ø,¯dSšwç]ù?ý
+?â7?Òù1Щsàží’9(ô½6¡¹$´ˆË*‹_ÙÌjGß½Sçbá÷ÏšX8LŒÀÌ6 
+1eeó-ÄlÒ±®v?1S{½‰þ¸�»°³øŠó‰<QøŠ¿â€ø±M‚�¢ÆµúI�_�PóBä;80v9_`ã£ØlbãŸlâ0£Fjå“V˜N€‘“n‡iZ
ÃÔVLËng•n`žh÷ÂlioªâPïR$dÓËä ¶08|&%osj†¼¯fÈCÞ(ò+Å�[Œ0¤H;†ü~Î�ßkºvCaS¯0~ñI_wû#jåáF�ÜbÚDÚ⹜ã}æÓ؆•¶²2`‡Ø6ivW»¶©ÍaÇbŸĹÆ
álúTŸZί“º2#zas,E*[dè
ŒÐêС7[
+°I+ «Ý¿Lí{Ôqî‹5eÇaÓèX=ö[½‰®»"ååÑÇ¡®¢»ûµðOÞ_3æ}í¬“wÉä¤?Èz®Óð†hÁSÃú.•®‘Wä‘ÊïlEÕMò
+ñC§)vŽ¶á‘#occa(lAFˆ%¼ZD
~mÕ~z�*?èn®£s"`Èl„Ê£.¥”[ˆ™¼À•(ÔU½¥Fõ–èê-i2\�l—
ðÀŒ˜cˆˆ¿´uæåE\#þò‚tü&™ª1ZP�"¦}ÔÇ�‘…£4j@RKÝΦk�ì÷£4„£&]ÉøZ?¤üÑ`'¿¿IËJ¦ž"öâv1Ž7܉�üðô+)�‡²w7JcðìLÚ[ªz!¯*¶Ï'5+0ˆ8ˆ‘ÐÌ0¦Œ407´”lº
°®p/0SXÔP8þª’¼¬ŸTÂŒEMþ—Ç××âP	£å�hü‘JQ6‡F¯¯2ㄽÐØêN7HÜqÿ\ìE¾À[/eëõ1_�eëg]0‡®�ešÇy%»D
+ͪ§ÕÚÁ´8¦e™öÕ€0&Ì‹·�!6¬,Œ••
ÙRM°J”»Úý˜Mík˜´L?gTÎö�¿äÅϼë´7ß“.×rí²·üC�㇌¤ó]Ë*~*›ÌñtûcêL뽈KV0£ü �LHû9­®lé:–~p0ÀòYÈqðH6­†™k«æÍL†™[¥æ'Ú½Ì[Úz>ù¶Ø�À_%ÕÏâðÒä0ݺà'˜¾Ão@Æ
¢Ø,aö³ù¡õÖ�X¯‡4SÉK0œ¼7D
«˜VJʪ¡dÛ/­Ò¥®v?%S{�|?¦b�Û'¹ÚõÙ<ò⟮½až«¹{ÍÒ­QHoʺ2r÷¹¥É“Ó)œ_â]2P.·Aaðcg¤^gZY (+
Å
m®c“6 tµû¡˜Úãéý¦:·•“Igæ�g=[cè"ÏgN{ò?Hç¸À<GHì‡ßø $ܱ„À´²`PV:­cIJkY¥
]í~¦öe—e¦�‚ËÕy4Ÿ¯Q´Ñ%ú�é†åw&ûZUUÒ]ž¨ t%w’æU=÷EQußÂèD¶æQ~?²á纲;L‚‘Çö¦•™²ÒÈj9MZ¥
d]í~d¦ö2ºP[/Q$ÛçÂS¦^gÚó'÷¡îæ‡<ý~Lº‡ лéP¸žßÛ–‘D
ÇÊŽ§^q§‚ö;•“
 endobj
-1600 0 obj <<
+1705 0 obj <<
 /Type /Page
-/Contents 1601 0 R
-/Resources 1599 0 R
+/Contents 1706 0 R
+/Resources 1704 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1529 0 R
+/Parent 1634 0 R
 >> endobj
-1602 0 obj <<
-/D [1600 0 R /XYZ 56.6929 794.5015 null]
+1707 0 obj <<
+/D [1705 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1603 0 obj <<
-/D [1600 0 R /XYZ 56.6929 748.5056 null]
+1708 0 obj <<
+/D [1705 0 R /XYZ 56.6929 748.5056 null]
 >> endobj
-1604 0 obj <<
-/D [1600 0 R /XYZ 56.6929 748.5056 null]
+1709 0 obj <<
+/D [1705 0 R /XYZ 56.6929 748.5056 null]
 >> endobj
-1605 0 obj <<
-/D [1600 0 R /XYZ 56.6929 748.5056 null]
+1710 0 obj <<
+/D [1705 0 R /XYZ 56.6929 748.5056 null]
 >> endobj
-1606 0 obj <<
-/D [1600 0 R /XYZ 56.6929 743.7078 null]
+1711 0 obj <<
+/D [1705 0 R /XYZ 56.6929 743.7078 null]
 >> endobj
-1607 0 obj <<
-/D [1600 0 R /XYZ 56.6929 719.6381 null]
+1712 0 obj <<
+/D [1705 0 R /XYZ 56.6929 719.6381 null]
 >> endobj
-1608 0 obj <<
-/D [1600 0 R /XYZ 56.6929 711.8197 null]
+1713 0 obj <<
+/D [1705 0 R /XYZ 56.6929 711.8197 null]
 >> endobj
-1609 0 obj <<
-/D [1600 0 R /XYZ 56.6929 697.0552 null]
+1714 0 obj <<
+/D [1705 0 R /XYZ 56.6929 697.0552 null]
 >> endobj
-1610 0 obj <<
-/D [1600 0 R /XYZ 56.6929 691.8868 null]
+1715 0 obj <<
+/D [1705 0 R /XYZ 56.6929 691.8868 null]
 >> endobj
-1611 0 obj <<
-/D [1600 0 R /XYZ 56.6929 665.1671 null]
+1716 0 obj <<
+/D [1705 0 R /XYZ 56.6929 665.1671 null]
 >> endobj
-1612 0 obj <<
-/D [1600 0 R /XYZ 56.6929 659.9987 null]
+1717 0 obj <<
+/D [1705 0 R /XYZ 56.6929 659.9987 null]
 >> endobj
-1613 0 obj <<
-/D [1600 0 R /XYZ 56.6929 635.929 null]
+1718 0 obj <<
+/D [1705 0 R /XYZ 56.6929 635.929 null]
 >> endobj
-1614 0 obj <<
-/D [1600 0 R /XYZ 56.6929 628.1106 null]
+1719 0 obj <<
+/D [1705 0 R /XYZ 56.6929 628.1106 null]
 >> endobj
-1615 0 obj <<
-/D [1600 0 R /XYZ 56.6929 601.3909 null]
+1720 0 obj <<
+/D [1705 0 R /XYZ 56.6929 601.3909 null]
 >> endobj
-1616 0 obj <<
-/D [1600 0 R /XYZ 56.6929 596.2225 null]
+1721 0 obj <<
+/D [1705 0 R /XYZ 56.6929 596.2225 null]
 >> endobj
-1617 0 obj <<
-/D [1600 0 R /XYZ 56.6929 569.5028 null]
+1722 0 obj <<
+/D [1705 0 R /XYZ 56.6929 569.5028 null]
 >> endobj
-1618 0 obj <<
-/D [1600 0 R /XYZ 56.6929 564.3344 null]
+1723 0 obj <<
+/D [1705 0 R /XYZ 56.6929 564.3344 null]
 >> endobj
-1619 0 obj <<
-/D [1600 0 R /XYZ 56.6929 549.6297 null]
+1724 0 obj <<
+/D [1705 0 R /XYZ 56.6929 549.6297 null]
 >> endobj
-1620 0 obj <<
-/D [1600 0 R /XYZ 56.6929 544.4015 null]
+1725 0 obj <<
+/D [1705 0 R /XYZ 56.6929 544.4015 null]
 >> endobj
-1621 0 obj <<
-/D [1600 0 R /XYZ 56.6929 529.6968 null]
+1726 0 obj <<
+/D [1705 0 R /XYZ 56.6929 529.6968 null]
 >> endobj
-1622 0 obj <<
-/D [1600 0 R /XYZ 56.6929 524.4686 null]
+1727 0 obj <<
+/D [1705 0 R /XYZ 56.6929 524.4686 null]
 >> endobj
-1623 0 obj <<
-/D [1600 0 R /XYZ 56.6929 500.3989 null]
+1728 0 obj <<
+/D [1705 0 R /XYZ 56.6929 500.3989 null]
 >> endobj
-1624 0 obj <<
-/D [1600 0 R /XYZ 56.6929 492.5805 null]
+1729 0 obj <<
+/D [1705 0 R /XYZ 56.6929 492.5805 null]
 >> endobj
-1625 0 obj <<
-/D [1600 0 R /XYZ 56.6929 467.136 null]
+1730 0 obj <<
+/D [1705 0 R /XYZ 56.6929 467.136 null]
 >> endobj
-1626 0 obj <<
-/D [1600 0 R /XYZ 56.6929 460.6924 null]
+1731 0 obj <<
+/D [1705 0 R /XYZ 56.6929 460.6924 null]
 >> endobj
-1627 0 obj <<
-/D [1600 0 R /XYZ 56.6929 436.6227 null]
+1732 0 obj <<
+/D [1705 0 R /XYZ 56.6929 436.6227 null]
 >> endobj
-1628 0 obj <<
-/D [1600 0 R /XYZ 56.6929 428.8043 null]
+1733 0 obj <<
+/D [1705 0 R /XYZ 56.6929 428.8043 null]
 >> endobj
-1629 0 obj <<
-/D [1600 0 R /XYZ 56.6929 414.0996 null]
+1734 0 obj <<
+/D [1705 0 R /XYZ 56.6929 414.0996 null]
 >> endobj
-1630 0 obj <<
-/D [1600 0 R /XYZ 56.6929 408.8714 null]
+1735 0 obj <<
+/D [1705 0 R /XYZ 56.6929 408.8714 null]
 >> endobj
-1631 0 obj <<
-/D [1600 0 R /XYZ 56.6929 382.1516 null]
+1736 0 obj <<
+/D [1705 0 R /XYZ 56.6929 382.1516 null]
 >> endobj
-1632 0 obj <<
-/D [1600 0 R /XYZ 56.6929 376.9833 null]
+1737 0 obj <<
+/D [1705 0 R /XYZ 56.6929 376.9833 null]
 >> endobj
-1633 0 obj <<
-/D [1600 0 R /XYZ 56.6929 350.2636 null]
+1738 0 obj <<
+/D [1705 0 R /XYZ 56.6929 350.2636 null]
 >> endobj
-1634 0 obj <<
-/D [1600 0 R /XYZ 56.6929 345.0952 null]
+1739 0 obj <<
+/D [1705 0 R /XYZ 56.6929 345.0952 null]
 >> endobj
-1635 0 obj <<
-/D [1600 0 R /XYZ 56.6929 321.0255 null]
+1740 0 obj <<
+/D [1705 0 R /XYZ 56.6929 321.0255 null]
 >> endobj
-1636 0 obj <<
-/D [1600 0 R /XYZ 56.6929 313.2071 null]
+1741 0 obj <<
+/D [1705 0 R /XYZ 56.6929 313.2071 null]
 >> endobj
-1637 0 obj <<
-/D [1600 0 R /XYZ 56.6929 298.5024 null]
+1742 0 obj <<
+/D [1705 0 R /XYZ 56.6929 298.5024 null]
 >> endobj
-1638 0 obj <<
-/D [1600 0 R /XYZ 56.6929 293.2742 null]
+1743 0 obj <<
+/D [1705 0 R /XYZ 56.6929 293.2742 null]
 >> endobj
-1639 0 obj <<
-/D [1600 0 R /XYZ 56.6929 267.8297 null]
+1744 0 obj <<
+/D [1705 0 R /XYZ 56.6929 267.8297 null]
 >> endobj
-1640 0 obj <<
-/D [1600 0 R /XYZ 56.6929 261.3861 null]
+1745 0 obj <<
+/D [1705 0 R /XYZ 56.6929 261.3861 null]
 >> endobj
-1641 0 obj <<
-/D [1600 0 R /XYZ 56.6929 199.468 null]
+1746 0 obj <<
+/D [1705 0 R /XYZ 56.6929 199.468 null]
 >> endobj
-1642 0 obj <<
-/D [1600 0 R /XYZ 56.6929 199.468 null]
+1747 0 obj <<
+/D [1705 0 R /XYZ 56.6929 199.468 null]
 >> endobj
-1643 0 obj <<
-/D [1600 0 R /XYZ 56.6929 199.468 null]
+1748 0 obj <<
+/D [1705 0 R /XYZ 56.6929 199.468 null]
 >> endobj
-1644 0 obj <<
-/D [1600 0 R /XYZ 56.6929 191.7053 null]
+1749 0 obj <<
+/D [1705 0 R /XYZ 56.6929 191.7053 null]
 >> endobj
-1645 0 obj <<
-/D [1600 0 R /XYZ 56.6929 176.9408 null]
+1750 0 obj <<
+/D [1705 0 R /XYZ 56.6929 176.9408 null]
 >> endobj
-1646 0 obj <<
-/D [1600 0 R /XYZ 56.6929 171.7724 null]
+1751 0 obj <<
+/D [1705 0 R /XYZ 56.6929 171.7724 null]
 >> endobj
-1647 0 obj <<
-/D [1600 0 R /XYZ 56.6929 157.0677 null]
+1752 0 obj <<
+/D [1705 0 R /XYZ 56.6929 157.0677 null]
 >> endobj
-1648 0 obj <<
-/D [1600 0 R /XYZ 56.6929 151.8395 null]
+1753 0 obj <<
+/D [1705 0 R /XYZ 56.6929 151.8395 null]
 >> endobj
-1649 0 obj <<
-/D [1600 0 R /XYZ 56.6929 137.1348 null]
+1754 0 obj <<
+/D [1705 0 R /XYZ 56.6929 137.1348 null]
 >> endobj
-1650 0 obj <<
-/D [1600 0 R /XYZ 56.6929 131.9066 null]
+1755 0 obj <<
+/D [1705 0 R /XYZ 56.6929 131.9066 null]
 >> endobj
-1651 0 obj <<
-/D [1600 0 R /XYZ 56.6929 117.2018 null]
+1756 0 obj <<
+/D [1705 0 R /XYZ 56.6929 117.2018 null]
 >> endobj
-1652 0 obj <<
-/D [1600 0 R /XYZ 56.6929 111.9736 null]
+1757 0 obj <<
+/D [1705 0 R /XYZ 56.6929 111.9736 null]
 >> endobj
-1653 0 obj <<
-/D [1600 0 R /XYZ 56.6929 97.2091 null]
+1758 0 obj <<
+/D [1705 0 R /XYZ 56.6929 97.2091 null]
 >> endobj
-1654 0 obj <<
-/D [1600 0 R /XYZ 56.6929 92.0407 null]
+1759 0 obj <<
+/D [1705 0 R /XYZ 56.6929 92.0407 null]
 >> endobj
-1599 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R >>
+1704 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F39 885 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1657 0 obj <<
-/Length 2544      
+1762 0 obj <<
+/Length 2542      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥ZKs㸾ûWè(U�€ øÈM¶l�&3¶#y²IÍî�–`™ŠTHʳ³¿>
âA�" É¦|0	4ñýu7º›ÂxS‘$˜DIàQ„éd{¸B“=ÌÝ_a)3WBsSêúùê/w$š$^úáäùÕX+öPãÉóîÛtñôtû°\ýs6÷)š.¼Ùœ"¤Fon7³y&|‚ð©M¯WןW�÷ëÅÓlj‡~E-–âfóõþþvó|+o×·‹åêáDðì·çOW·ÏúµÍ­aDø;ÿçêÛoh²ƒ~ºBIb:ù7ÈÃIâOW
%
Q#ùÕæêïzAc¶}tLU”Ä�ýhDW>ž`ì%”ú=eÑĉOZe-6b[�GV¥MVµuWÃ[\ Kˈ cd	Žþm}wŠ"¿
11E^œÀû;@µÌ50MSêÅ¡&ì²<¤Y!ö�îY‘Õ
l¾¬j1Vvºhï÷§lÇ<þŽƒ-á�zAÆðB|ÝBü‹'þ.Xsjâ¡|g‡V‰;œÄ‘gU6çKr¨Û�r(\Ii•S9Tî‚6”>Ķ¨Ý¿)‡R*^[Þ2mRqu—åL\ݔůùû“àAÞVÕÇSNÓ Ì HŸŠ§ö“©äãš±ªa‡TÎ=n›Ò #!V2ÂúªL);ZJ“‘`ßN†º#ã{œŒø(:¤¹ô�b÷g)ñ1õÂ8öû”,ieúÆ{©fñô”V?4#¡�‘vNQ|�CÊÁˆ’RŒø##.hƒ‘!¶…üLù7UÖ°*“îñZJc]—e##Jz�³aÕ;«êÑ(Åà‚qØçáZòð%-Š¬ØØî9Î?f”N³ß3fñO �0Âhê„,I!M’�I\ƒ£
°…"ùk-Õ]¾g‘giÍê
S¬ù^Vÿî(ʶlœ£0ö"?ÆO’�é!Ëåtš¤µœþ…ûQ•íßA‘‚ì%sŸ$¥�WÌ߃V¸*Àæ
-i‡ÙL‚™‡&7;kž@£Ä‹¾�)˜RvÖµ”¦=ö©�v'tÇûö8ñ=ðì<§Ï3Œ10°Ï[½„(ßGSöò×ÙœþtUקÖ
-`¦µxf…ã‡âR+¦[%òñHQ
-ͳ�pUÉç[BX#îŽ"â6å¶ÌÇ¢.ñ¡Ä<
`µ¸ëj¤uk“¹–ŸÓ†¾L3Ø¢2ÃTÆd!dõuD^FhK!E:	G@vᜀ-”È?1’ÐŽCHGh‡Å�.ŽÇ<ÛêôFx5±Z>,TÉ0<&	`&„ÁC]
-/¦”�O-ÕñIÉ£ºãó{œÏøB÷FßYѵEï”Kɬ`à|*û㽜ÚÑ]9+áU}ŒÖÛtÙî&6Fãà/��ƒ)¤Sz9j8®AÊ
-§ý©n4‰•%ˆtÓ`ÙYPBÝ'©ÈQG»p;†Àã˜ÈÂÉb
§áY…Hvà¾)ù³¸†A•áÊ8åÀ~/öê»~¬¼VY³âÄ-}¼'`(ŠÌ¦Gœºâ>]ݲòÜ”öÜêF}î<eÆï4>�òŸùüÄÓ
-2jëHøÿûYF2òHlë¹B¦žDê¥øæ:|sýË­óWÿ/ÿ÷Ãendstream
+xÚ¥Z[w£º~ϯð£½Ö˜Jqé›'Og’ÔÎô´kÎy ¶â°ŠÁœ9s~}·Ð�‘<=]yH>Øß¾c<Að‡'1õI‚I”E˜N¶‡+4ÙÃÞý–2s%47¥®Ÿ¯þrG¢Iâ%¡Nž_�{ÅŠc<yÞ}›.žžn–«Îæ>EÓ…7›S„ÔêÍíf6�„o¾¢éõêúóêñ~½xúø/qѯˆ¢ÅÃRœl¾Þßßnžoåéúv±\=܃žýöüéêöY?¶ùjþÌÿ¹úöšìà
?]!�$1�|‡äá$ñ'‡«€�„¨•üjsõw}Cc·½tLU”Ä�ýhDW>ž`ì%”ú=eÑĉOZe-6âµ�¬J›¬,jë[Oq�.-#€Œ‘%d8ú·õÝ
(Šü6ÄÄyqÏï
+ÔÆCùÎ/¬g8‰#Ϫl Η6äP·!åP¸’Ò*§$r¨Üm(}ˆmQ»	~S¥T¼¶¼eÚ¤âè.Ë™8º)‹_ò÷'ÁƒX¼­ªŽ§œ¦*@™A�>O3ì'SÉÇ5cUéÜ{Ü6¥AFB¬d„	†t!T™Rv2´”&#Á¾�'tGÆö8=ðQ2tHséÅîÏRâcê…qì÷)Y*6ÒÊô�;öRÍâé)­~hFB;#¼9EñF)#JJ1â#ŒŒ¸ 
F†ØFLð3åßTYêLºÇk)�u]–�Œ(éAz̆UשׁG£TƒÆaŸ‡kÉ×´(²b?`»ç8ÿ˜Q:Í~ϘÅs<�>Â_ ©r°$…4I>N$9p
ŽÀŠ䯵Twù:pœEž¥5«L=°æ{Yý»£(Û²qŽÂØ‹ü Ï$ÓC–7Êé4Ik¹ý÷£*Û¿5‚"Ù+æ>I<J¡®˜¾"¬pU€ÍÒ³?˜3“&7;k�@£Ä‹¾P)˜RvÖµ”¦=ö©�v'tÇûö8ñ=ð¼yNŸgc``Ÿ·z	#P¾�¦ì寳9	ü骮O­ÀNk#pÍ
+ÇÄ¡V"l·Jäë‘¢š7&vᨒ׷„°FœEÄmÊm™�E]â'B‰™
`µ¸÷ÕHëÖ&&s-?¦!}™fðŠÊS“}„�Õ×iya] ½r°.…é$H
Ù…kp>
+�‘gDDvXýZdüR±(’>¬Ž%PØ×q#êâ,«%7æ-y¨��^ôB0�WD¡õˈ…§JøŸrö³:
û ¸ÊY'ˆŒ¨2”¨‚æËÓF@¨µ> ‡ÐÈ¿P˜R3RRº›‚ÐaF.hÃŒ†Ø32Á¿Ö­uˆ]Vçê(�•:_Ýü
+”vйQ`Å­cCÊ¡d%Õi9q¸ŠÚPóÛ¢g\ëss:˪¨ûs™îÔˆ€'+‹¾Ià…1Ì{žy'¤UVo•ÒÇ*˵Ʃ]ã~ì¡(¾0ê1¥WR]Ï8êX'´¡ñ!¶Eã&øBj–íÕdá:­³3;txª±ÍKQÎŽŽÓ>	�zl�øÓô´Eé˜éÛ EðÂñ…v”r¡¤4$pt‘Nhƒˆ!¶…\g„P×
+9±ôI�Œ»©Òï¯bF²SÁà´?Õ�æ!±ò
 endobj
-1656 0 obj <<
+1761 0 obj <<
 /Type /Page
-/Contents 1657 0 R
-/Resources 1655 0 R
+/Contents 1762 0 R
+/Resources 1760 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1529 0 R
+/Parent 1634 0 R
 >> endobj
-1658 0 obj <<
-/D [1656 0 R /XYZ 85.0394 794.5015 null]
+1763 0 obj <<
+/D [1761 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1659 0 obj <<
-/D [1656 0 R /XYZ 85.0394 748.4854 null]
+1764 0 obj <<
+/D [1761 0 R /XYZ 85.0394 748.4854 null]
 >> endobj
-1660 0 obj <<
-/D [1656 0 R /XYZ 85.0394 748.4854 null]
+1765 0 obj <<
+/D [1761 0 R /XYZ 85.0394 748.4854 null]
 >> endobj
-1661 0 obj <<
-/D [1656 0 R /XYZ 85.0394 748.4854 null]
+1766 0 obj <<
+/D [1761 0 R /XYZ 85.0394 748.4854 null]
 >> endobj
-1662 0 obj <<
-/D [1656 0 R /XYZ 85.0394 743.3452 null]
+1767 0 obj <<
+/D [1761 0 R /XYZ 85.0394 743.3452 null]
 >> endobj
-1663 0 obj <<
-/D [1656 0 R /XYZ 85.0394 728.6405 null]
+1768 0 obj <<
+/D [1761 0 R /XYZ 85.0394 728.6405 null]
 >> endobj
-1664 0 obj <<
-/D [1656 0 R /XYZ 85.0394 723.1655 null]
+1769 0 obj <<
+/D [1761 0 R /XYZ 85.0394 723.1655 null]
 >> endobj
-1665 0 obj <<
-/D [1656 0 R /XYZ 85.0394 708.4607 null]
+1770 0 obj <<
+/D [1761 0 R /XYZ 85.0394 708.4607 null]
 >> endobj
-1666 0 obj <<
-/D [1656 0 R /XYZ 85.0394 702.9857 null]
+1771 0 obj <<
+/D [1761 0 R /XYZ 85.0394 702.9857 null]
 >> endobj
-1667 0 obj <<
-/D [1656 0 R /XYZ 85.0394 688.2211 null]
+1772 0 obj <<
+/D [1761 0 R /XYZ 85.0394 688.2211 null]
 >> endobj
-1668 0 obj <<
-/D [1656 0 R /XYZ 85.0394 682.8059 null]
+1773 0 obj <<
+/D [1761 0 R /XYZ 85.0394 682.8059 null]
 >> endobj
-1669 0 obj <<
-/D [1656 0 R /XYZ 85.0394 668.0414 null]
+1774 0 obj <<
+/D [1761 0 R /XYZ 85.0394 668.0414 null]
 >> endobj
-1670 0 obj <<
-/D [1656 0 R /XYZ 85.0394 662.6262 null]
+1775 0 obj <<
+/D [1761 0 R /XYZ 85.0394 662.6262 null]
 >> endobj
-1671 0 obj <<
-/D [1656 0 R /XYZ 85.0394 599.7666 null]
+1776 0 obj <<
+/D [1761 0 R /XYZ 85.0394 599.7666 null]
 >> endobj
-1672 0 obj <<
-/D [1656 0 R /XYZ 85.0394 599.7666 null]
+1777 0 obj <<
+/D [1761 0 R /XYZ 85.0394 599.7666 null]
 >> endobj
-1673 0 obj <<
-/D [1656 0 R /XYZ 85.0394 599.7666 null]
+1778 0 obj <<
+/D [1761 0 R /XYZ 85.0394 599.7666 null]
 >> endobj
-1674 0 obj <<
-/D [1656 0 R /XYZ 85.0394 591.7571 null]
+1779 0 obj <<
+/D [1761 0 R /XYZ 85.0394 591.7571 null]
 >> endobj
-1675 0 obj <<
-/D [1656 0 R /XYZ 85.0394 565.0374 null]
+1780 0 obj <<
+/D [1761 0 R /XYZ 85.0394 565.0374 null]
 >> endobj
-1676 0 obj <<
-/D [1656 0 R /XYZ 85.0394 559.6222 null]
+1781 0 obj <<
+/D [1761 0 R /XYZ 85.0394 559.6222 null]
 >> endobj
-1677 0 obj <<
-/D [1656 0 R /XYZ 85.0394 534.1777 null]
+1782 0 obj <<
+/D [1761 0 R /XYZ 85.0394 534.1777 null]
 >> endobj
-1678 0 obj <<
-/D [1656 0 R /XYZ 85.0394 527.4872 null]
+1783 0 obj <<
+/D [1761 0 R /XYZ 85.0394 527.4872 null]
 >> endobj
-1679 0 obj <<
-/D [1656 0 R /XYZ 85.0394 502.0427 null]
+1784 0 obj <<
+/D [1761 0 R /XYZ 85.0394 502.0427 null]
 >> endobj
-1680 0 obj <<
-/D [1656 0 R /XYZ 85.0394 495.3523 null]
+1785 0 obj <<
+/D [1761 0 R /XYZ 85.0394 495.3523 null]
 >> endobj
-1681 0 obj <<
-/D [1656 0 R /XYZ 85.0394 420.5376 null]
+1786 0 obj <<
+/D [1761 0 R /XYZ 85.0394 420.5376 null]
 >> endobj
-1682 0 obj <<
-/D [1656 0 R /XYZ 85.0394 420.5376 null]
+1787 0 obj <<
+/D [1761 0 R /XYZ 85.0394 420.5376 null]
 >> endobj
-1683 0 obj <<
-/D [1656 0 R /XYZ 85.0394 420.5376 null]
+1788 0 obj <<
+/D [1761 0 R /XYZ 85.0394 420.5376 null]
 >> endobj
-1684 0 obj <<
-/D [1656 0 R /XYZ 85.0394 412.5281 null]
+1789 0 obj <<
+/D [1761 0 R /XYZ 85.0394 412.5281 null]
 >> endobj
-1685 0 obj <<
-/D [1656 0 R /XYZ 85.0394 388.4584 null]
+1790 0 obj <<
+/D [1761 0 R /XYZ 85.0394 388.4584 null]
 >> endobj
-1686 0 obj <<
-/D [1656 0 R /XYZ 85.0394 380.3932 null]
+1791 0 obj <<
+/D [1761 0 R /XYZ 85.0394 380.3932 null]
 >> endobj
-1687 0 obj <<
-/D [1656 0 R /XYZ 85.0394 365.6884 null]
+1792 0 obj <<
+/D [1761 0 R /XYZ 85.0394 365.6884 null]
 >> endobj
-1688 0 obj <<
-/D [1656 0 R /XYZ 85.0394 360.2134 null]
+1793 0 obj <<
+/D [1761 0 R /XYZ 85.0394 360.2134 null]
 >> endobj
-1689 0 obj <<
-/D [1656 0 R /XYZ 85.0394 345.4488 null]
+1794 0 obj <<
+/D [1761 0 R /XYZ 85.0394 345.4488 null]
 >> endobj
-1690 0 obj <<
-/D [1656 0 R /XYZ 85.0394 340.0336 null]
+1795 0 obj <<
+/D [1761 0 R /XYZ 85.0394 340.0336 null]
 >> endobj
-1691 0 obj <<
-/D [1656 0 R /XYZ 85.0394 325.269 null]
+1796 0 obj <<
+/D [1761 0 R /XYZ 85.0394 325.269 null]
 >> endobj
-1692 0 obj <<
-/D [1656 0 R /XYZ 85.0394 319.8539 null]
+1797 0 obj <<
+/D [1761 0 R /XYZ 85.0394 319.8539 null]
 >> endobj
-1693 0 obj <<
-/D [1656 0 R /XYZ 85.0394 295.7842 null]
+1798 0 obj <<
+/D [1761 0 R /XYZ 85.0394 295.7842 null]
 >> endobj
-1694 0 obj <<
-/D [1656 0 R /XYZ 85.0394 287.7189 null]
+1799 0 obj <<
+/D [1761 0 R /XYZ 85.0394 287.7189 null]
 >> endobj
-1695 0 obj <<
-/D [1656 0 R /XYZ 85.0394 272.9543 null]
+1800 0 obj <<
+/D [1761 0 R /XYZ 85.0394 272.9543 null]
 >> endobj
-1696 0 obj <<
-/D [1656 0 R /XYZ 85.0394 267.5392 null]
+1801 0 obj <<
+/D [1761 0 R /XYZ 85.0394 267.5392 null]
 >> endobj
-1697 0 obj <<
-/D [1656 0 R /XYZ 85.0394 252.7746 null]
+1802 0 obj <<
+/D [1761 0 R /XYZ 85.0394 252.7746 null]
 >> endobj
-1698 0 obj <<
-/D [1656 0 R /XYZ 85.0394 247.3594 null]
+1803 0 obj <<
+/D [1761 0 R /XYZ 85.0394 247.3594 null]
 >> endobj
-1699 0 obj <<
-/D [1656 0 R /XYZ 85.0394 223.2897 null]
+1804 0 obj <<
+/D [1761 0 R /XYZ 85.0394 223.2897 null]
 >> endobj
-1700 0 obj <<
-/D [1656 0 R /XYZ 85.0394 215.2245 null]
+1805 0 obj <<
+/D [1761 0 R /XYZ 85.0394 215.2245 null]
 >> endobj
-1701 0 obj <<
-/D [1656 0 R /XYZ 85.0394 149.4956 null]
+1806 0 obj <<
+/D [1761 0 R /XYZ 85.0394 149.4956 null]
 >> endobj
-1702 0 obj <<
-/D [1656 0 R /XYZ 85.0394 149.4956 null]
+1807 0 obj <<
+/D [1761 0 R /XYZ 85.0394 149.4956 null]
 >> endobj
-1703 0 obj <<
-/D [1656 0 R /XYZ 85.0394 149.4956 null]
+1808 0 obj <<
+/D [1761 0 R /XYZ 85.0394 149.4956 null]
 >> endobj
-1704 0 obj <<
-/D [1656 0 R /XYZ 85.0394 144.3554 null]
+1809 0 obj <<
+/D [1761 0 R /XYZ 85.0394 144.3554 null]
 >> endobj
-1705 0 obj <<
-/D [1656 0 R /XYZ 85.0394 120.2857 null]
+1810 0 obj <<
+/D [1761 0 R /XYZ 85.0394 120.2857 null]
 >> endobj
-1706 0 obj <<
-/D [1656 0 R /XYZ 85.0394 112.2205 null]
+1811 0 obj <<
+/D [1761 0 R /XYZ 85.0394 112.2205 null]
 >> endobj
-1707 0 obj <<
-/D [1656 0 R /XYZ 85.0394 97.4559 null]
+1812 0 obj <<
+/D [1761 0 R /XYZ 85.0394 97.4559 null]
 >> endobj
-1708 0 obj <<
-/D [1656 0 R /XYZ 85.0394 92.0407 null]
+1813 0 obj <<
+/D [1761 0 R /XYZ 85.0394 92.0407 null]
 >> endobj
-1655 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R >>
+1760 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F39 885 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1711 0 obj <<
-/Length 2122      
+1816 0 obj <<
+/Length 2121      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥YKs㸾ûWèª*Bðà37ÙÒ8žñÚŽå­d33š‚%–)R+RžÑþú4Ð J$µ•”�n ?ôQø±‘ç?âÑ(ˆ\âQæ�’Í­`ìöŠžIÍ4±¹®_®þöI£ˆD>÷G/o–¬�Ð0d£—åWgJƒê\ß]ßß=Þ>OŸþñÛxÂ=ê|£�>Ì°³øõöv¾x™›îó|:»{¸6ž~D�éÓÓüav÷oŸ*©´¡ÞÌãï/Ÿ¯æ/Ͳí­1*Ôš¿úú�Ž–°ÃÏW”ˆ(ôF? C	‹">Ú\¹ž ž+DMÉ®WÿlZ£zj§©%\ø¼ÃVœ�#‘çñ–±¼ˆø‚m¬ÇײÈd%—¸ÇÙÃÂØF&û]ZŒi>Ý”½›.4ht
G‹×&ºp¬¹ÔÒ¾‚VN}ïû©fÆ9XņU7\çº]û1�mݳb§ùxârê<Ä©ZÌYÊJn�z4�™ÿ¬d^¦E®Ít²;R„�ëR²ÿ
-S|á̈™—U¿Ë1Ã×»1�%ê‰sÓ¸1ü_âýÛ&Î�”Ïq¾�w¥¶\+š4°ƒ>8W
éE�º$Ä£:
-‰"ïÀà—Xw“uƒCÔ�ƒ’Hò’Í5€CÍUã (
pRmápª»[w�ƒCƒƒjÕ8èvƒƒ�'!,æ7˜5GºÊÓ|…�é¾Zšÿ'î3HW‘î8w®	Nü×8âŽÌ2�T:Šqá<ró*wÆêù­(Æ)¥ý˜‰ˆP7º„™Å5€YÍuÄ,¢˜
©¶0;ÕÝ�™­»'7.‚Ý›,Þ¥ß(åI\5ÄúûŸ"¯]®Š«}—Sqð°íUsãU÷òGZv;
-p¹™Ll«ežúï…ÔƒÈyx¡Î³¹ú!m¸H}o
-ÌWP%ºQ�…A=-Í@Rà:Mb;4ظýØp�¸`ÂØX\ØÔ\6—¥AÕ6§º»±±u7õ¹[×…ªÕÔçÐÖL5LI}ãE@;ñ"M1^df/B±öåúó¼Ú°ùT¤yuœµ˜?§}ÊâUÎ.»|±
ZÇĆڊ‰µs~)²w¼;«ÞgC]$ëìPµŽ„Ž¾}…�u£<1PÈ/¼t“°¹úOLÃÕœ˜p¨T}<1gº;OLKwOUzzaÐ>ù³BëB®øZ\ϳéØóœå™S$}*v›¸3�ú°ò�»mçÀqº_íËê«Ó‡±‰€�á2ª!áA¹Gýæ‘�'.Î]rsi$Ívñ[ÕULSHÊ.Dæj	֬ЫgA¾»Yi¬
-ë˜èÊÿ€\åºØg†ªµªÆ«ÄïïûßU�Qg5 %©!¹Ú>Zcn„½©SŸ!Ñƺû<3þ$)6“.|¶qžjéŒ:¯ü≀Æ2-“,N7:‡ê�¸jXóñBçç®:s%võrá‹(+d-K¢øp��uüa„ÄøÉÒ7YÂò°§O+|Ëô'66E^­Í\8ïõ¬S¸lvlԬسW�¥´^²“©¶~Ö3¯f*IM=ëÇŒ²38Ðó  LPxuµbá¥ÂÎk±7±âúîav”ëB±ê7r)‰X}y“;åF½Ïì<„RïÂõËæ:O&°lâ(LgÖŸGµóÈ™ÚÎ<ÒÒŠy„zÆ­¨o[Ê^´
5Vć9Oñ>ÃIÓ.\œHº�Sá¤É»ŽпO÷j"s¡âÜvéj­“ˈ!lÀ
Õß+Ô¼ '¸ˆàÇ%L8	üöiñ}£ÌëºpØbXWŸ,ŠB\ÛB¾ÆeUlM ÈÞLÿŽ#�y†‚43OøÜSºN®tM52…kE’ÂY.{‹8¬ê£¼hs¬ÿïÿ¥¬ê% "컊p°¯‚³(µ—È?[yýÖùÒÿš¸�¥endstream
+xÚ¥YIs㸾ûWèª*B°pÍM¶ÔŽ»=¶cy*™t÷�¦`‰eŠÔˆ”»5¿>x J$5•”Äòà}x 6¢ðc#Ï'~Ä£Q¹Ä£Ì%›+:ZÁÜí34“šhbS]¿\ýí“F‰|î�^Þ,Y!¡aÈF/˯Δ2	Ô¹¾»¾¿{¼}ž>ýã·ñ„{ÔùF=:}˜agñëíí|ñ27Ýçùtv÷p$l<	üˆ:Ó§§ùÃìîß8?URi3z3_Œ¿¿|¾š¿4˶·Æ¨Pkþýêëw:ZÂ?_Q"¢Ðý€%,Šøhsåz‚x®õHvµ¸úg#Кլ�¦b”páó[q6bŒDžÇ[Æò"â.´±_Ë"“•\âgc™ìwiu0¦ùtSönV¸Ð Ñ-*\›è±¦RKû
+Z9õ½ï§šç`/VÝP�ë‘¥›ñ€x<hëž›8ÍÇ—Sç!ÞHÕbÎâPVrƒ£G©™ùÏJæeZäÚL'»c!%Aø°.%û¯ÀâgFk\VYü.Çg\GìÆ,t–¨'ÎMãÆЉ÷o›87R>Çù>Þ”VØr­hÒÀúà\¤=ê’�ê
+›ª‹†ª
Ã~4¨úˆÆ™îN8Zº/Û¿h†ý($Š¼ÿ
ƒ_bÝMÖ
Q?~H"\ÈK6Õ
+¸÷‹Š{Jð/qYÊŽéZA/‰E©¢
+\§Il‡·îLx
‹j
+aÜo汆ÆÙ3¨¢sõd¥Ë*^ÉÛXxùÎR~ȬتýÁŠüˆ9w›m&U¿Øé�½cïU¢Àâ,pò¢2ª‹ö6°L@ÎU\¿²q8.€6býN}×I?âL�¥°Ž	�®üHU®‹}fFµVÕx•øý}_à»*ê¬cIj†\m­17ÂÞÔ©ÏpÐƺû<3ú$)6“.|¶qžjéŒ:¯ü≀Æ2-“,N7:‡ê‰¸jHññBçç®:s%võrá‹(+$-K¢èp
+��uüa„ÄøÉÒ7YÂò°§O+|Ëô'66E^­
/œ÷z‰?Ö)\6;6jVìÙ+†ÎRZ/Ù�ÉT[?뙉WÃ
+BRSOÄú1£ìô<(AD]­Xx©°óZìM¬¸¾{˜åºP¬ú�\J"VßCÞäN¹Qï3;�¡Ô»pý²©Î“	ì‚
+ÓÙ„õç‘A­Ç<r¦¶3�´´b¡žq+êÛ–²íC@
…ñ�ç)ÞgÈ4ÍàÂõlj¤8Nš¼ëøýût¯™çö°KWk�\F,an¨þ^¡æ9Á%@?.aÂIàG°O‹îe^×å€ÃúúdQâÚò5.«b[èhAöfúwœyüË3¤™yÂçžÒur¥kª‘)\+’ÎrÙ[tÀaUuàE›cýÿ/eU/
aßU„
f¿^”6	ågK¯ÿÁ:_û
øp�Úendstream
 endobj
-1710 0 obj <<
+1815 0 obj <<
 /Type /Page
-/Contents 1711 0 R
-/Resources 1709 0 R
+/Contents 1816 0 R
+/Resources 1814 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1529 0 R
+/Parent 1634 0 R
 >> endobj
-1712 0 obj <<
-/D [1710 0 R /XYZ 56.6929 794.5015 null]
+1817 0 obj <<
+/D [1815 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1713 0 obj <<
-/D [1710 0 R /XYZ 56.6929 749.4437 null]
+1818 0 obj <<
+/D [1815 0 R /XYZ 56.6929 749.4437 null]
 >> endobj
-1714 0 obj <<
-/D [1710 0 R /XYZ 56.6929 749.4437 null]
+1819 0 obj <<
+/D [1815 0 R /XYZ 56.6929 749.4437 null]
 >> endobj
-1715 0 obj <<
-/D [1710 0 R /XYZ 56.6929 749.4437 null]
+1820 0 obj <<
+/D [1815 0 R /XYZ 56.6929 749.4437 null]
 >> endobj
-1716 0 obj <<
-/D [1710 0 R /XYZ 56.6929 746.6461 null]
+1821 0 obj <<
+/D [1815 0 R /XYZ 56.6929 746.6461 null]
 >> endobj
-1717 0 obj <<
-/D [1710 0 R /XYZ 56.6929 722.5763 null]
+1822 0 obj <<
+/D [1815 0 R /XYZ 56.6929 722.5763 null]
 >> endobj
-1718 0 obj <<
-/D [1710 0 R /XYZ 56.6929 716.7581 null]
+1823 0 obj <<
+/D [1815 0 R /XYZ 56.6929 716.7581 null]
 >> endobj
-1719 0 obj <<
-/D [1710 0 R /XYZ 56.6929 701.9936 null]
+1824 0 obj <<
+/D [1815 0 R /XYZ 56.6929 701.9936 null]
 >> endobj
-1720 0 obj <<
-/D [1710 0 R /XYZ 56.6929 698.8254 null]
+1825 0 obj <<
+/D [1815 0 R /XYZ 56.6929 698.8254 null]
 >> endobj
-1721 0 obj <<
-/D [1710 0 R /XYZ 56.6929 684.1207 null]
+1826 0 obj <<
+/D [1815 0 R /XYZ 56.6929 684.1207 null]
 >> endobj
-1722 0 obj <<
-/D [1710 0 R /XYZ 56.6929 680.8926 null]
+1827 0 obj <<
+/D [1815 0 R /XYZ 56.6929 680.8926 null]
 >> endobj
-1723 0 obj <<
-/D [1710 0 R /XYZ 56.6929 656.8229 null]
+1828 0 obj <<
+/D [1815 0 R /XYZ 56.6929 656.8229 null]
 >> endobj
-1724 0 obj <<
-/D [1710 0 R /XYZ 56.6929 651.0047 null]
+1829 0 obj <<
+/D [1815 0 R /XYZ 56.6929 651.0047 null]
 >> endobj
-1725 0 obj <<
-/D [1710 0 R /XYZ 56.6929 636.3 null]
+1830 0 obj <<
+/D [1815 0 R /XYZ 56.6929 636.3 null]
 >> endobj
-1726 0 obj <<
-/D [1710 0 R /XYZ 56.6929 633.072 null]
+1831 0 obj <<
+/D [1815 0 R /XYZ 56.6929 633.072 null]
 >> endobj
-1727 0 obj <<
-/D [1710 0 R /XYZ 56.6929 609.0023 null]
+1832 0 obj <<
+/D [1815 0 R /XYZ 56.6929 609.0023 null]
 >> endobj
-1728 0 obj <<
-/D [1710 0 R /XYZ 56.6929 603.184 null]
+1833 0 obj <<
+/D [1815 0 R /XYZ 56.6929 603.184 null]
 >> endobj
-1729 0 obj <<
-/D [1710 0 R /XYZ 56.6929 579.1143 null]
+1834 0 obj <<
+/D [1815 0 R /XYZ 56.6929 579.1143 null]
 >> endobj
-1730 0 obj <<
-/D [1710 0 R /XYZ 56.6929 573.2961 null]
+1835 0 obj <<
+/D [1815 0 R /XYZ 56.6929 573.2961 null]
 >> endobj
-1731 0 obj <<
-/D [1710 0 R /XYZ 56.6929 558.5914 null]
+1836 0 obj <<
+/D [1815 0 R /XYZ 56.6929 558.5914 null]
 >> endobj
-1732 0 obj <<
-/D [1710 0 R /XYZ 56.6929 555.3634 null]
+1837 0 obj <<
+/D [1815 0 R /XYZ 56.6929 555.3634 null]
 >> endobj
-1733 0 obj <<
-/D [1710 0 R /XYZ 56.6929 540.5988 null]
+1838 0 obj <<
+/D [1815 0 R /XYZ 56.6929 540.5988 null]
 >> endobj
-1734 0 obj <<
-/D [1710 0 R /XYZ 56.6929 537.4306 null]
+1839 0 obj <<
+/D [1815 0 R /XYZ 56.6929 537.4306 null]
 >> endobj
-1735 0 obj <<
-/D [1710 0 R /XYZ 56.6929 510.7109 null]
+1840 0 obj <<
+/D [1815 0 R /XYZ 56.6929 510.7109 null]
 >> endobj
-1736 0 obj <<
-/D [1710 0 R /XYZ 56.6929 507.5427 null]
+1841 0 obj <<
+/D [1815 0 R /XYZ 56.6929 507.5427 null]
 >> endobj
-598 0 obj <<
-/D [1710 0 R /XYZ 56.6929 477.5928 null]
+630 0 obj <<
+/D [1815 0 R /XYZ 56.6929 477.5928 null]
 >> endobj
-1737 0 obj <<
-/D [1710 0 R /XYZ 56.6929 453.2532 null]
+1842 0 obj <<
+/D [1815 0 R /XYZ 56.6929 453.2532 null]
 >> endobj
-602 0 obj <<
-/D [1710 0 R /XYZ 56.6929 369.7201 null]
+634 0 obj <<
+/D [1815 0 R /XYZ 56.6929 369.7201 null]
 >> endobj
-1738 0 obj <<
-/D [1710 0 R /XYZ 56.6929 345.3805 null]
+1843 0 obj <<
+/D [1815 0 R /XYZ 56.6929 345.3805 null]
 >> endobj
-1739 0 obj <<
-/D [1710 0 R /XYZ 56.6929 310.6805 null]
+1844 0 obj <<
+/D [1815 0 R /XYZ 56.6929 310.6805 null]
 >> endobj
-1740 0 obj <<
-/D [1710 0 R /XYZ 56.6929 310.6805 null]
+1845 0 obj <<
+/D [1815 0 R /XYZ 56.6929 310.6805 null]
 >> endobj
-1741 0 obj <<
-/D [1710 0 R /XYZ 56.6929 310.6805 null]
+1846 0 obj <<
+/D [1815 0 R /XYZ 56.6929 310.6805 null]
 >> endobj
-1742 0 obj <<
-/D [1710 0 R /XYZ 56.6929 310.6805 null]
+1847 0 obj <<
+/D [1815 0 R /XYZ 56.6929 310.6805 null]
 >> endobj
-1709 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R /F14 685 0 R >>
+1814 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F39 885 0 R /F14 729 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1745 0 obj <<
-/Length 1944      
+1850 0 obj <<
+/Length 1945      
 /Filter /FlateDecode
 >>
 stream
-xÚµX[�Ûº~ϯ0Ð>h�#†wQ穹µÙdS4[ô!Ù­MÛBdI‘äÝEÿ{‡R¶¼ò1Šƒb�9~œÎ�f
-la¡"—‹,—DQ¦ËÝ+ºØÀÚß^±À#• J
-
“™ÕT	C”áÙ"=y{ÿêõ_9[pJ´æjq¿ÏÒYFh¾¸_}MÞ´­­WåÏ›”+š¼½y¸ÿ
wI’™Œ¹]NȈJûŸŠz_TÈßÛ�{˜$BjöhE4UÆïyKØMÊ(¥ÉªÜ8~Ç 2"´F1îŠ�
8b‘“\s`#€̎Ëmöç~ã<ÃÑû»/8¨šæû¾Åñ~(«r8c$W*
-&ᆡ2_uÓö¥×áÕ‡ûѦš&À¢’iÂT.æìÎ@N®ä…K1”€öÌw„ðw"ò
ã•Œ\£ž¬õõ/½ížl÷¦é#ê¤N�ÄhFT®œë6«Ugûp+“³@q#|#ærS(b´Š�˪˜ä91&ËÏ
×W
×eeëñʧBfÄpš�c~ÿ?`îÆQ;ƒž
-çõʘE:úìn›nøÓ%[˜ó#~\û‚È\�œQqŽ7\Åíÿ€÷ó*žs§9<I¸~qó‡«p_·»bùëƒÓú×ïö0ƒœS"sªÏ¡å8Ò>ƒ¤�sAùô~¾:èÈëŒÇÞ‰ãäÇÞv‡¦!—b_dœÈŒý‘Ø?…¸û#×4öÓíeÑ':ÙíâwD‹\SÑ6UóXTéÄŠ)ã£e£Y¯dß÷¾¼ûÇíßïo?ß�Ü“äÏ]²còY!A£#~£Š®š]QÖP$MÊzÝt»b(Gy²én˜IšÖvÀÊS�kN¿Q*ìÏò±²Hš¦ÂÀŠ°ƒíiàõ9±Áº�iOÂôÝ“›TÐ,¹�
-Ç;¹zävÛ¼CG]&þŒu
Xë¸+£}[‡@¶ÉEÝ?Ãq‘Za›—5ðàxØwµ]áòUÙ��¡Ž„Z8ãöh6·|„‡##>Ìœ”v*+˜}jú!üSµ¼­„f�_ve]Þ°¤ºbh¼ð@Þ÷vÆ%@è|¬8\º!¡c¶PÉ=Ük¿m'º¦G1Z\†Õ]�K�vY8)ür³Æo9„Õè%Øh€\É/°`À
-Åùž
-ÔÞ¶û‘*A‡K+». Àz\wÂÍô™†2Æä5»hšG»<•Åœ?�
-Yô¦?ÿûãçOþóš
-ž{äÅ\Äî6]^ªŠ\Lªb(‡Óòúp,¿8p¿øõà0Íê¢Wõr½f9$
5Jöã¢d1|ÆsO¤GêøHƒ±³~�¢	E;H#|ú¸½‹	VÆú@¨ÂÙYíß}ŒüàŽ¡	5»-÷a;zs»icŸì½Ä
ƒ—�ówøñyLÜϲ³íÀ’yðÙÉo#TÃó,9òìü´ñ÷Ý—ÇýóUžéendstream
+xÚµX[�Ûº~ϯ0Ð>x�#†wI穹µÙdS4[ô!Ù­MÛBdI±äÝEÿ{g8¤lyåcÅ+r8ü83œ-fþÄ,3Œ«\ÏÒ\3Ã…™-¶¯øl
k{%�6Š­L&V£2f2™Î’S�·÷¯^ÿUŠ™äÌZif÷«á,›¦Œç³ûå×ù›¶uõ²üy“HÃçooî£]š¥Y*p‡Rf•±~ǧ¢Þñ·ÅÚuá™ÒV†=Ö0ËMæ÷¼eâ&œóù²\#?2¨”)kIŒ»b뎚å,·Ò%˜Ê@fäÂÍþÜoR¦4z÷…UÓ|ß·4Þ÷eUö‡£`‚åÆDÁ´`2¤Ì—CÝ´]éuxõá~°©åL(°¨–	“«)»�S}áR2Î@{�Ç!ü�hq¢a¼’�kÐÓ‚µ¾þ¥s»'·{Óä‘t2§F<e&·ÎÅÍÅr¹s]¸•ÑY x¦•|æbS–Y!U1	(s–ei~¸º
+¸*+WW>2e™äé9æ÷ÿævµè‰B¯7Y6Kÿ�Ým³ëÿtÉÙù?®Š}Ad©X.¸:Çë¯âõ‡öÀûyÝi
+O3i_Üüá*Ü×ͶXüú€ZÿúÝ&�sÎtÎí9´FöÁg�D
r®¸ßÏW„Ž¼hŒ8öN'?önwhÚž1öp)öU*™NʼnýSˆË±?p�c?Ù\ÍHfs•þÑN ~G´È5m]5�E•Œ¬˜9X6šõJö}ÿáË»ÜþýþöóÝÀ=Jþ#P“ÿË
+! ˆ(ñ7|Ùl‹²†B ù¼¬WÍn[ôeƒ•Ï×»‘Í›Öí€U¦ŽÖ
+š~ã\¹ŸåcåˆÜ7ME+€a{·#¤5€×kâ¤Zë>¦=‰ÒwÇnÅÓùmOT8åꈷy‡ŽºŒü™ê°*
"ÖKH,£][‡@î7ŽÈEÝ=Ãq‘Zôa›—5ðиßïj·¤å©²=#-�DZ q;2.ááȈ3t€Ò-Ae³OM×Ç‚ª–·•²ò˶¬Ë1ïú]Ñ7^x ï;7á l>Tœ.
Ý�²1Û÷

ö¤äîµÛ4
ŠnùQŒ––auÛÑÒ£[(…_nVô-û°½„
�kþ,d`…â|O
+³‰1éï\³\«XûXÌΚeyn@Çœ¥iJÿ¦ê7Í~½™8Jè8•ºvµ2eàÁÀUJÎkŒñª:àÌ›{Iôç²ßmÑl·`ý¤*kGkëýÖÕ}‡Wg$\.qU×צè‰æ�E¿�Ûf ü=ãšR�7€Õ�B¹»ý�B(bŠ%%}r¡�h©ëCŽ8†(ÎŽ™JVÎç;C´Gˆ½
»=(½;Ф	DïÀxÆØ$õÔ$�ä½	··¨X7$̉ˆnw˜‘ßêùóÆÕ4Âtò²È§9Âêp‘ÉfÚ«Lfc@¤OØð]—O®Fõ�šÿ³®ÊïŽè®ØU¥˜`úEÑÁiJÙMZ3{{÷ž8ò€ºm!øA÷âxR³šŒ	x�‰¡�¾X—Lj¢7ƒw6ÏdµDãÓ*züÛ}Õ—måN£»GòcX,»nïB”Ÿø…âÀ.7€Á
³áÆN‚lF)A‘ïK¥B1”phµ$Š?(¾°© J׺E‰N¸ y,{*Œ›TCV|i@ÉsïyÍ€^5�繬ª XŠ2 —Ô«�‚QÕ%jUvä–¨e=á‹Â&¤ˆêk×/^ê©žb*Ëàá$@º‘¿/šz5!÷¸Ñ‘82ÿ¿(Fd	¿éɵ
1&ŒÎH>�ÀŽc\|a“ŽIëë³É®Z_Èll}@
�^ñ}Ûßè!0\E
᥮þ#:ötM0!ßmzì)¢¡,<ƒyfÇ–ò}“ÍBà§ðëºÐ 
Õ;(P;ØZêG¨;ZZºU

ÖÑ:
+7Ñ[¤ʘÐ×ìbyíòTSþ*¤Ñ›þüï�Ÿ?}øÏkx»Åb¦˜Í¬ü:5¿ßDU)ÇŸªŸ
µƒ8Èa€\Ô¢�7…r$sÍ´�gõȇ½á'®ƒ“¶…ü¹ŒYÍu\¼œcN‘‚³N¦�{ß`Bɺ½£/uµ0x÷‘¾ô{ƒo™1§tDm ¦«¢¥I¨í0ê¯ÂõMK`•{rÑè•�ý!`z�fó%5YH§Î-œ1ñ³¼eL–ÅBç£ëMÓÙ+5´‚çžy1W±»M—ª¢T£ªÊ!Å�¢´¼:Ë/
ðw
¿F“™C]ôª^®×"‡¤aÉ~\”,†Ïpî‰4êHi0Fë)šP´ƒ4ʧ�Û»˜@`eè¡¡„*œžõÐÈøîcäw�H¨©Ômá/„íàÍ]tì¦�}²÷/açïðãó˜áϲ“íÀ’yèÙÑo#\Ó/U€:q~ÜðïËóþÐažƒendstream
 endobj
-1744 0 obj <<
+1849 0 obj <<
 /Type /Page
-/Contents 1745 0 R
-/Resources 1743 0 R
+/Contents 1850 0 R
+/Resources 1848 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1752 0 R
+/Parent 1857 0 R
 >> endobj
-1746 0 obj <<
-/D [1744 0 R /XYZ 85.0394 794.5015 null]
+1851 0 obj <<
+/D [1849 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-606 0 obj <<
-/D [1744 0 R /XYZ 85.0394 769.5949 null]
+638 0 obj <<
+/D [1849 0 R /XYZ 85.0394 769.5949 null]
 >> endobj
-1747 0 obj <<
-/D [1744 0 R /XYZ 85.0394 573.0107 null]
+1852 0 obj <<
+/D [1849 0 R /XYZ 85.0394 573.0107 null]
 >> endobj
-610 0 obj <<
-/D [1744 0 R /XYZ 85.0394 573.0107 null]
+642 0 obj <<
+/D [1849 0 R /XYZ 85.0394 573.0107 null]
 >> endobj
-1748 0 obj <<
-/D [1744 0 R /XYZ 85.0394 538.4209 null]
+1853 0 obj <<
+/D [1849 0 R /XYZ 85.0394 538.4209 null]
 >> endobj
-1749 0 obj <<
-/D [1744 0 R /XYZ 85.0394 504.6118 null]
+1854 0 obj <<
+/D [1849 0 R /XYZ 85.0394 504.6118 null]
 >> endobj
-1750 0 obj <<
-/D [1744 0 R /XYZ 85.0394 432.7569 null]
+1855 0 obj <<
+/D [1849 0 R /XYZ 85.0394 432.7569 null]
 >> endobj
-1751 0 obj <<
-/D [1744 0 R /XYZ 85.0394 303.3232 null]
+1856 0 obj <<
+/D [1849 0 R /XYZ 85.0394 303.3232 null]
 >> endobj
-1743 0 obj <<
-/Font << /F21 658 0 R /F23 682 0 R /F39 863 0 R /F53 962 0 R >>
+1848 0 obj <<
+/Font << /F21 702 0 R /F23 726 0 R /F41 925 0 R /F53 1017 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1755 0 obj <<
-/Length 3825      
+1860 0 obj <<
+/Length 3824      
 /Filter /FlateDecode
 >>
 stream
 xÚÍZÝoã6Ï_ õk•)‘ê}à²ÝMÑM÷6)®EÛÙVbamÉkÉ›¦ýÍp†´$KÉ÷rÑCŠçã7CÉs
ò<I£4‹³s“é(29_nÏÄùô½9“<fîÍ»£^Üœ}ó�2çY”¥qz~sÛ™ËFÂZy~³úuö"’Ñ3˜AÌ^]¾y6�ÓDij‹÷ï__½ºü~'†À
-…œ|:ûõwq¾¾¿?‘Êlr~?D$³,>ßžéDE‰VÊS6g×gÿvzÝ«£�"ŠU�H –çRFY’Ä=$Y”ªX9\_¾{ÿÃkÚ×O×°)ܼ©:²çÐcS÷Ê�nvå2ßÐ�²ú\/ó¶¬+ú]ßò<²3ˆ$¦nžUy7²˜4‘V:á1›ºþØД›òcñ-½ ²Îs)u¤�Ý\ZØlÂìóNî_M±ÿ\ìéG•oj
ûÅÈòó$ÊŒIý\´ãû5¼/íŒÖï�¸ŒŒ”éyš¦pBbê„hм;Ê�¶#*FáÒÌü`Ù,Ž’ÄêÇ—õƒN—íí83Q¢2Ó_¶D¡[�ÒÄ›Œ‡¤zOÏË÷Ô“¯V$œ†ß�³Ÿz×RÛšhŸÅþá™”r¦¦²lv³ö«/óŠÆ.ø}÷Û­ýYO¬^ò�UݶÅjŽ’ƒÃ„SÕ5Ä›jH±,·N�­šUuëÕ~ѯ§p½”)ýõ¯§fËzSWóU±)·%,ÜŸv¦E6ûϺàÑ$h4‡ÝnSÂx§ŠI÷`”1‘ÍŒdS8jÂà
-÷íãö¨¤[ô(êá¢ã²î.ZV+À:­3�LpR‚–ãƵœÐáIáÌ5KN‚þt(©±"êoql°PòêÿžSÇ?ßýÌ�ëË7ÜûŽÆÜ[F'…wÐ&N#+…öNÅÅ6˜sÁÈ+fûs¾)WÝÍ8ÃVð: ƒ´oظԗ8`
¨[fêIµ�=ç;«|Èu®6²ÚÊ¿€0ïË
cØ]±‡(´íDÔöÃŽ�UÍŽ(g�{1fGQઽç1 �Td =e@Q|sùãÕõcˆ;	îóÔ÷Ëp?LEû˜/ƶŠ	AæãH½ó
-vr€Ä~T½=QÑgâÓÙô¹˜)>@Š€P픿W2J”õ[›ïÆwŸe
šoVÖ°Ùb5
 ˜(Ñ
£_�€,Žm'
-Öop}èzîÇì­“»ZH5ˆ“GYa4­zÅ©Z»Üƒä‚ý$WØêÔôq6Y8ǹ¨ÂÄÉP…¥ò¥·åxT0dB,™Œª"•Þ:œ
´u…UlÁaQƒÊ¶Øb\§$ø´}^5¸,’ºòïèMŒ±*ø¨ôÿw‹)û8H*³}=©’ènü¯ 'e¤çuÞNaÓӜϟó郪8âëPÊ0b<‡D
ÔyªÆ
-+µÌ;ÁPÞó�ýó˜	KÈU³là*�^Þº0ƒHM
¶q15Ž»hÖe¢Øõ@].E½¥Â=Òs"“(‘àÐ1P.~þîCD$ºA¢_¨¬–´–~\b�Ži×ÝgÏ¥‚0e}îõf,Öàž�©
-\ƒj3DÖÒ߇(ŸðÍ\w Nó5GÉë/¦«Ò÷y3q©‰º?Š1‰òe®()}
-bÎDü…îR
-ïóæŸÆíWéd
!ËôîVû룻UÇ»•)w˜‘GŽ	Ü©»ƃ(˜ùð5óö°¡Ÿ«šŸ€YÀFe³>ò7Æ‚…Œ:
-”®DXð9I;܉
-ô½¿ù@„0È•œåñú¹X¶åçbã?^¡€™	À°õW¶ÖƒMw›gÂW%fèÂphðRØ.]¡Ã‰h¾,¤ª\,6<ÏËe³8´Z9ÿký�¾ÅEÓèâ}ÂÆLÁ©—îÀS7ØQóëEÚP8d½¡é“löá»—)Rú±-Ú5˜³Àe’ù¸Ÿ9.¯nè­NmÆ�ÇácÕyW­	µãrâÖK…zº÷¿
-"BV˜ñ�I§ë†¾xÀfHÏqàÛw/çï^%cÁ8`–Y(bOud)ú	O¨&y¢álD
 ×Tˆc÷Âà)†Ì‰HÉ´õ0QÉÓÁù âþ“I‘r5Æ|Äï4K‹0AN�EÞóTS_Q-ëÁ'ïÑþ´ôŸõnx’»¢ÂK2œvE”'0«
-‚ÕrœÀ4d‹VM}­°¢Æ¾ÌáK‰ÿù{éã×àÚDÊÚ‰o|bc#mafʆìé§Lüaõ)ëÿÜÈûendstream
+…œ|:ûõwq¾¾¿?‘Êlr~?D$³,>ßžéDE‰VÊS6g×gÿvzÝ«£�"ŠU�H –çRFY’Ä=$Y”ªX9\_¾{ÿÃkÚ×O×°)ܼ©:²çÐcS÷Ê�nvå2ßÐ�²ú\/ó¶¬+ú]ßò<²3ˆ$¦nžUy7²˜4‘V:á1›ºþØД›òcñ-½ »³Î¥Ô‘N@vsiaÿ±	³ÏS8¹5Åþs±§U¾-¨ì#ËÏ“(3&õsÑŽï×ð¾´3Z¿wâ22R¦çišÂ	‰©¢Aóî(w@ÚŽ¨h…K3óƒe³8J«_Ö:]¶·ãÌD‰ÊLÙ…nAJkWl2’ê==/ßSO¾Z‘p~Î~ê]Hmk¢}:û‡gRʘšÊ²ÙÍÚ¯¾Ì+»à÷Ýo·ög=±zÉCVuÛ«9JNUÔo¨!ŲÜ:¶jVÕ­W_øE{T¼žÂõR¦ô×S¼žš-ëM]ÍWŦܖ°pVØ™Ùì?ë‚G“l Ñv»M	ã�*&݃QÆD63’Má¨	ƒT6J­ÎxXîØã}k™F‰
û&¯wwØUËvËÆ•Óc]7-žÖóQë562{Úz•g™%Uo>¼N»ÎyeV
+hÁáÊÙmMƒ‰ät¢¬î¦_bií´F‚JÜò�zD”1¸<ÇñˆR%`”O‹2î‹R[%<wî­ús¹*VcrÌdd?)F™¦<fYWÍaÓ6#Î6èûià7E»üfïÁK·#3Cøé(¯VÄ4
+¼,x¤œ:.�HbÜ¿)ÒpK‘˜b�F2–²/§›5�Ýmèç-ÉjëϹ˜8æ�°^íêjÕôõxU6»MþP¬¢)O�X”@ü¸£îšöÓ~nÐq<XÑŠ(»[Ñ�9Y±wh6
ÕÓioŲ™Z};èòvxp�e�º$Ã[
e毃•R†ˆ\ðèÃnZ̉‰RTóÇåÜõˆ ý(Ü·�Û£’~lÑ£¨‡‹ŽËº»hY­
+mý
+´
+¶üV°
ñ‹öÇP/À"j{d0„O7¯Zó¼+{MÞT?~Yeaí£æ¢(X¿Áõ¡ë¹;³·NZìj!Õ Ne…Ñ´êe§jír’ö“\\a«PÓÇ
Ødáçz< 
+'C–Ê—Þ–ãQÀ�	±d2ªŠTzëp6ÓÖVy°‡E
*Ûb‹q�’àÓöyÕàþ±HêÊ¿£;41ƪà£Òÿß-¦ìã0 ©Ìöõ0¤J¢»ñ¿‚œ”‘ž×y;…MOs>#|Îg¤ªâˆ¯C)ÈñqP穼ù:"
+˜ù²¥¸œÏµ$ãK@Wvÿ‘£ûuIAxŒU
+÷HωL¢D‚CÇ@¹øù»‘èN‰~¡²ZÒXúq‰1t:¦]wŸ=—
+Âl”õ¹×›±<xXƒ{>V¤T‹ä	
­:–TJÆíMÑd?R¥7ÀH¸9)ÿ¸Ýÿãj$X%I:ÆÞ¬C‚2Y,*îŠèʱEÈ�“›ÖO¶\çÕ]ÑøŒÊç9”—ujô&&é­ê¢(pUªÍYK/¢|Â7sÝ�8Í×%¯¼˜®JßçÍÄ¥$êþ(Æ$Ê—¹^ ¤ô)ˆ9ñº[H)¼Ï›·_¥“!4„,Ó»[íw¬�îVïV¦Ü-`B@D9N$p§îV¢`æÃ3ÔÌÛÆ~®j~f
=”ÍúÈß2ê
+.ÜXÛmP”>–�Å7Äò¼d¸Msá”`bÈÏ‚r
+£L¨¸Â›2Ž¤Šà˜ÊjŽŠåû]>ê|“(ÑÆô®³av½Ò»^q¬$C“¡�Ç|qYðw)Ð÷þæ Wr–ÇëçbÙ–Ÿ‹�ÿx…f&@
+Žx»k¹|t’†ó
+�Giß\_¾AQ?çM@#`£JU¤7ÏøJg]­T;Tˆ�8I§r3
À-KBnöq\‘¬ºIËlö‹;—­@‰-Úñ¦©‰ÔÙ†¿(êÓeÛ›["’¨Ò£±r™—¨\ë
›ã+‚òŸ^ŒÕPð«ÔP%z˜¸vé^�àŽÿ6u±•øȱÞæËqè"™’ð)ˆYaÆw&�®úâ
›!=Ç�oß]¼œ¿{•ŒãX€Yf¡ˆ=Ô‘¥pè'<Q šä‰ZxtüI„³5€\S!ŒÝƒ§2'"%Ó.ÔÃD!$`LçS€ˆøO&EÊÕó¿Ó,-Â9=ySÌSM}Eµ¬WŸ¼/DûÓÒÖ»áIîŠ
+/ÉpÚQœÀ¬*VË9pcÐ�-Zq4õM´ÂRˆû2G„/%þçï¥�_ƒk)k'¾ñ‰
$†´™)‡:„>ý–‰¿¬>åý¿�
 endobj
-1754 0 obj <<
+1859 0 obj <<
 /Type /Page
-/Contents 1755 0 R
-/Resources 1753 0 R
+/Contents 1860 0 R
+/Resources 1858 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1752 0 R
+/Parent 1857 0 R
 >> endobj
-1756 0 obj <<
-/D [1754 0 R /XYZ 56.6929 794.5015 null]
+1861 0 obj <<
+/D [1859 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1757 0 obj <<
-/D [1754 0 R /XYZ 56.6929 752.1413 null]
+1862 0 obj <<
+/D [1859 0 R /XYZ 56.6929 752.1413 null]
 >> endobj
-1758 0 obj <<
-/D [1754 0 R /XYZ 56.6929 501.191 null]
+1863 0 obj <<
+/D [1859 0 R /XYZ 56.6929 501.191 null]
 >> endobj
-1753 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F48 885 0 R /F53 962 0 R /F11 1304 0 R >>
+1858 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R /F48 940 0 R /F53 1017 0 R /F11 1367 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1761 0 obj <<
-/Length 2980      
+1866 0 obj <<
+/Length 2981      
 /Filter /FlateDecode
 >>
 stream
-xÚ­Zmoã6þž_áoç µJŠ¤$ÐÙͶHÑnÓ&‹ëa›Š%ÇBl)µääüïo†CR/–”ÃÝa�5EŽ8Çç…
-_0ølj
-˜Ðrk(ÆÕb½¿`‹'ûñ‚[™•Zu¥>Ü_|÷ƒˆ:ÐQ-î7�¹’€%	_Üg_—W··Ÿ>_ßüq¹
-[~.WŠ±å/WŸ¿\ýL}·—:\^ýøé#ÅBâ(±åõÍ�—÷?]|º÷Æt
æL %]|}`‹ìþé‚B'jñ,àZ‡‹ý…T"PR׳»¸»øÍOØ5¯Ž
 D¨$ŒGÅJ‘€!DàczlŠª¼\	/ëmuÜeÔ~Ìé·IŸs;ü¶u­c]”Ov|›#
-€¶îèâ‰’„)°µ¬N$Ó³‡ƒ=\p+R½´v¸ßýq׫c�¬}§ºÉ÷5=¤uk€i<ç'lDËuZö×ðZÔÅãÎ>%Ú²X
ÚA¢E-h¥Bc†™-ŒÅ²:6/ÇÛr¹9\òdYíiä¥þ“
Ê𷢃™Í³Ÿ£Þæ»ÝßjzØuSN$ú'cá."‰„-ÿapE‹+6ïï€^Fvšb�B8úV4[)ï@*tH‘„Ó¬xÃ]„¬Ì·8¡nm.Ó}N
-¶L_lçË¡H›|uÎX ­-¢¸¢ÔuÀt"¬.vd";õùT\EEN¬
«ö@�šì%~Îcj&í+¸ÇY°®ÊÍÈìàbpV4ðfzl«Pƒ?ŠpºB2–±‘ýí˧ß/•Zþ“ùõöþæ×Ïw#ëÐÃ(HT¬çh<ä±µ£Ý˜×É�&ø“,ËãþѺª
õ!
O¶Ë¸ûÊÛ¶¸äËõÖN°Á)7ùº¡g¢$t½¥öes ±c[¸—vUõ||q&£ì[û4Ëm·a2OÜŒzIr5¸³Ú:»¸ÞÙÊŠúe—žˆÑàÇîª=¾/Z˜0¾®¶]uÞر�Y®<ŒHŸ¨ýXrˆ˜V$œe¢…
-ƶ9¬àp	��dËÚëÏò&?ì‹Ò>:<à¥à³
-€[ELÛ�
-6D¼{&ÜaB'"—*@£Î	ôÇ"Â4¤v"ý‚nRÜìþ{°y;Û¦u�xˆ�C2ª¥+"»XQ3	YÜ^FÍèjæ/6d[ý’¯}æm¬UéHq¹P“*HyúII×Ö~5�2Ò‘¿2±©jS˜ì*âãµ’à…+Õ¿Ë›õw‡¼®v¯Seµ†]Á<¡]hb+E\ÀCT ¯¿3¼³3ÖE®!D“{‡Ñ>V¼½�SýÛ‡$€ZÀÙû
êXoG̳ W<»óñ¼{®ž
-Sz¸þ|w÷é#µ_Ó]‘¥m!Rmzùqy’
-:¢K§Y&t„¦‰à„Zì&¯ç´¶·ƒCµã—ƒ]½×ô­p*-´Ÿ¡ôãÏWwwî*6/;à|zèemVä?†LÀ
-ÁD„ïÜ™´2Ó Z™öB±�Í>ƒUÊ á@˜­^f¨vðGŽ_¤ºzÿ;Lïïþ?!ê*à_üŒ¬�ù�ðÿóµ6%ñ¯<’‰j>;†:vF!LZ-÷�tnú¿
1W@endstream
+xÚ­Zmsã¶þî_¡o•' 
+ázvw¿ú	;£æÕ1
+ÈXÆFöׯŸ»TjùO2ä—Ûû›_¾Ü�¬@£ Q±ž£ið�ÇÖŽvcr\'šàO²,�ûGCHèª6Ô‡4<Ù.ãVì+oÛâ’/×[;Á§Üä놞‰’Ðõ–Ú—Í�ÆŽmá^ÚUÕóñÅ™`Œ²oíÓ,·Ý†É<q3ê%ÉÕàÎjë|ìâzg++ê—]z"Fƒ»«öø¾HhaÂøºÚvÕycÇ4fu¸nð0"}¢öcaÈ!bZ‘p–‰*Ûæ°‚Ã%x<>’-k¯?Ë›ü°/Jûèð€—j€ÏìíL\Pž®´¬ßÈy°å“1p¬Ê&Ͼ·§�¼
+c §‘]×/HDëágp	YÆqÞÇ%­i?
µåkº;¢Ë\ðÏ;%ìÜÏ9uS&ƒ
ÇkÇÓq€YÀ©c„ùDÛôuøâ¦:ìÇÈã N´K¾£ud?ÛFàLD%QèC€SLzéœØ��ûW²Ì[Ÿ‹Ç’¶þ¯g©2˜‚4\É8C%£¹½Zu¥Lf+“‘ÌÖK™U~+«‡fý2TÌP9bïhöRçªÌ‹á`ð�î¯x¬þ[†[.!ªê�Œå�Z÷ŸniÌæÕÐe ¥ÔßÁTÌôS*
+ªŽû-q6`¦4®Òˆ�Ê&ýµëmU/ÿ”	>
í´aHâAÈ´+ñ
+ë4eÈÅ…êS¯“áÙ@¾q|{L×Ïoi¸Iö/P=»¢9]rÎÑM	Îèp Äa(_×ø¿Ë C¨3¡âÐÓ��·0jÖÇ¢Á±I¾ĮE¨çùÖ•šæ›—òhBô¨ùçb&óʽԹöAù­ Ñ—¼¯þ5»¬–

—Pe•®ö„¢™3#Ob:lÎð>ß$ç<œþ4£qŠ²�ÄÌÆ_Fe¬‘AóPã.âÀÇu[‡n„;Ñ™	’:K)$a2Ã~!˜f挎3.DBR'Ãæ·´#5³¥NÊliVíÓ¢ü
óiW^÷ö&�Ï[à¥ÎMèï+ØAðî™p‡	�ˆ\ª
+Sz¸þrw÷ùµ_Ó]‘¥m!Rmzùqy’
+:¢K§Y&t„¦‰à„Zì&¯ç´¶·ƒCµã—ƒ]½×ô­p*-´Ÿ¡ôÓÏWwwî*6/;à|zèemVä?†LÀ
+ÁD„ïÜ™´2Ó Z™öB±�Í>ƒUÊ á@˜­^f¨vðGŽ_¤ºzÿ;Lïïþ?!ê*à_üŒ¬�ù�ðÿóµ6%ñ¯<’‰*˜„ÐÜ…0q¦†¦û?A:·ýßh @endstream
 endobj
-1760 0 obj <<
+1865 0 obj <<
 /Type /Page
-/Contents 1761 0 R
-/Resources 1759 0 R
+/Contents 1866 0 R
+/Resources 1864 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1752 0 R
+/Parent 1857 0 R
 >> endobj
-1762 0 obj <<
-/D [1760 0 R /XYZ 85.0394 794.5015 null]
+1867 0 obj <<
+/D [1865 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1763 0 obj <<
-/D [1760 0 R /XYZ 85.0394 674.4719 null]
+1868 0 obj <<
+/D [1865 0 R /XYZ 85.0394 674.4719 null]
 >> endobj
-1759 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F48 885 0 R /F53 962 0 R >>
+1864 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F41 925 0 R /F21 702 0 R /F48 940 0 R /F53 1017 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1766 0 obj <<
+1871 0 obj <<
 /Length 2837      
 /Filter /FlateDecode
 >>
@@ -7625,904 +8155,1196 @@ lhïëÁ4êvÂîûYž^®1Æ	€"C,¹}ªûéG¶D3Ý¿(•iäˆg œ–¨VVɇòÜ¯�“äù©Þ?
ÄŠ"9ȲíÕ‡  (
 @ãâ]0ƒ±î½±½&Óè�‰wç<ÐE0…lõKžLQ–	¹ìÉ>ÊoÒ:`=È“wÓÜå»t¡Fà8^»ö|B­{ô]£¿%ÌêF¬¡e=Q�z•A·QEÉÇÁ>×P44�yy蚦{™<ÈÓ©lz;<Ú<ÓÀæ@d-­Ò8ƒÔÿÔ={A\¤ñŽi*OÈîÏÎwG�§C+ôï1<—ý˜‰ì`†«£Èë•:”Vüž‘f$Û~R­û½§ò~¿?T3¯GP«cz�³§š³ŽáÙ…lÂ{ôz¥0aCMŽ§ºLІn
 ”]H¹!Õ†aÕh{Ö;ßM0”Ò¬ÀÛü=Õ\€Ø6PfS�X,ÁhælÃœmXdæOŠQ2Š¬_GóИ‡ó°%ó Ìš‡…æaÖ<Ìš‡E§ËÛæ�`E1»°ë©6Ìã¨FóTU­VW6sûu×’mà©æÄö
I)Íc	ógáÌ#"ódÎ<"	DÖï£}˜°öÆ>bÉ>…³�í#¬}„µOæí£ƒ©(Ҍ擊hÃh¸ )b]@´n2G4Z¬iVç¶ØŽgsS¾ËGs!ãOÒÆW¶íYÚ¦’go¾"DËÇõ*
u
 ®’ñÌÜß.äPŸøÛPðƒ®­ú8‘äF&+¶ˆ'	7�øû·­Ö\ëy9-é° 0(Žd0‰ÝdYpØK¹SQ—°2
-Óš8³tüÌÕÿoœ'xL:´U�œnþëvßœ«éᢾŠsPÿ~µòÇ;à«þ-·€´sÎõÿ)oüË!Ë cædO$ã)|,œPJ¡¹ã ”PH»sÙÿm˜þŸendstream
+Óš8³tüÌÕÿoœ'xL:´U�œnþëvßœ«éᢾŠsPÿ~µòÇ;à«þ-·€´sÎõÿ)oüË!Ë cædO$ã)|,œPJ‰¹ã ”PH»sÙÿn þ¥endstream
 endobj
-1765 0 obj <<
+1870 0 obj <<
 /Type /Page
-/Contents 1766 0 R
-/Resources 1764 0 R
+/Contents 1871 0 R
+/Resources 1869 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1752 0 R
+/Parent 1857 0 R
 >> endobj
-1767 0 obj <<
-/D [1765 0 R /XYZ 56.6929 794.5015 null]
+1872 0 obj <<
+/D [1870 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1764 0 obj <<
-/Font << /F37 747 0 R /F48 885 0 R /F23 682 0 R /F21 658 0 R /F53 962 0 R >>
+1869 0 obj <<
+/Font << /F37 791 0 R /F48 940 0 R /F23 726 0 R /F21 702 0 R /F53 1017 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1770 0 obj <<
-/Length 3317      
+1875 0 obj <<
+/Length 3266      
 /Filter /FlateDecode
 >>
 stream
-xÚ­]sÛFîÝ¿B3}¡§Õ†ûÅ�›ÉƒS;9·iâÖNïnÚ>P"ms*‘ªH9qý
,EŠ”|Ó^2	w—Øß
-hGôU¶.j@«Š…Š"É@pþø ©Dh4C\Nœ‘
-­•a€ûÚÕöiŽ‚ßaYWM™Ã½e9ßgÑÔ«][<}6WI$”’Èr)Rk•;ùÎñÍ�Šûl·jiò”­v¼^6ôdÎ9È_ÃPU
LwM	\«<齃é0lÚ¬-ÖEÅû=cuÚgYb„Ýâ¿*Úå«m
xp·û)YéYø
œ�˜Àñ	pHF…
-`£ ª‰:NA‰àê0©*µŽT¸
S‹+%¿ÙÀ2°7PGx
vnŒ	>€
-0Èç²}Ä‘	î‹Ï¨ƒ¸èÏ6¨X(>¶j‹í†VZd¥ƒàƒhy•µåSAoª=–¬bèÏåjEK§„À	¾¹¯¦ ŒËGw>¸+§F8
-
-¸Þ¥¸8AÇj bCÄù†¯KE¶|¤Åá�h
Í¡2šb`#Ä*À»@"jtÚ{Ÿ-Aš˜
-q•”áÚm‚,_<
¨#‹R¸W¬‡ŠâIu1÷±Deu™ï´«CwV•ªBKcWÝ´»E³bø¢€*¹í‡ÛUCÔÖžV�>ÔqÕé :ÕYP‹ÜƒkhG
-ð`ú:¨1Öâ
-{;$ᢅÂuƒÉpDžBEàFÊf³ÊžyÑ1PH´ètÆqV9]nhæ…É^LF¨l…ίÈ�þ°ÇÂ�þà¤lØBÊ®;Ô	J�R¹4¯£&ŽÉUõis\¤ uQÇ/ˆ´uB¤ª)„î¦XŽÄiC¨DTry5Æ>'¤5qläýO$
ÊHBÕ
ÿöê[�‚—¤²Ú=×p+Ï~…s%œ88<ðã÷¼£ä­¿†6¼üÿKšcd”i´ßýñænŠ’¹±"Q‰F¾QŸåyÙBêÒÙ6u5Ž(½DŒRþ#Š ÓP@M~R
ö0Ç•€a:hʇåcÖLä8JÄpÂ	¼äïPüPCÆ*Õ}Äß:„s9…”RX³>TY»ëÌQaÃ{!h‹°Qg¸ËÐÐk·nàÒV…Í·õ¦\9ãêRÍ/'šÀ&Q¤ÚôîøRXAHK’éð¼;ï$CH UŸ!·×ï¾ýçÅíÕqéCÚ
aé%ù÷ Nh€‡r:ÐnwØbšÿ^<¿þ
-þŒô ‰Dd}š„jLÃPR)"�FC"\í…�Ì™»«Tð�K«‚ÆèÔAØÔÁv¶çI°£îÎ�~ÞŒþŸÞ¹k<ŒÓ‡‰†§6¦]ëìë¾IÐo!í…¤¦kFÍ{å’TD
-F“~JÅèBM:ªñrúo{ªîÄyÿȱ¹*p-±Ôñóÿä­T!?J_HZúPǽUÕE¬¶Þ¸ÆÙ(k‰ ÏÍiìÔýAØ’"¶2âÿ*æ\¹N~Æ¢L÷A^1éƒ�7ÅÓ?šd´.4çV tí¢2ÏZ×ö
-°¸¦ÌfÅ„aŠX:@*Z$_Øg¡V·Iêãà3Ý’‰ÆŒ”}¦äi"õÐ×Ñýt¨©,�§ÏQäÖ§¿<…,:ôás>õG‘Æ©çÍ"k1b"
-Pç2À[â´Þ ˜šã7½XrlEäî2€´�®m…KOp}™1õ‹bOýªtßFa•ô×]Pu'~®Ò}º&Ä ‰P¥…Ъ³‡æÉŽÔÆ—qù¨¥Ê
-hÈ�ð×Φ[Θž²Ê˧2ß¹²E«î:î•'¹`ŠIç¸mˆ+Í3˜ÉçE³Ü–þ2—!Di>yg‹ú©À_i€ScI«�¾ »ÚgNî¿ä<÷WO8hZ #óÂv²Á×N68ØËoÿ3Xv¿ kÚ¾à9æ:oÞmxŸS3åÅ›­¦>ôôëÏ›â@G–«¬9Ôw»iê¾ôpÒ<Ö»U>Ì'2¯êý^þ~ËA}y¨�¤w«zA‚�É$ÿpŸ�&Dž.§­i×IÁMž2þ9>÷”ño%Ü¢Ë&ùT°`>jIjˆï›švøc¼1»Rеe\	LõD—IÖØ)î¿.ßÖ®ÓÌÝļ W¤ðýÒ–À`u·Yñ:y!å”B'�QÚnh{\Â=݃©d¨Ž’×�O6¦™—Æp°>˜~°\'ÀYIpáT
-…²‘Ü»w&9ãK,øà¶Û2Ï‹Ê÷\AM£$š×âyðAËÝeÞÕ;Kßqi‡Ý–)×쾯¾õßc‹/Fûûµ˜†Ê]멼2ìÒ“¿ýK²ýïäL,4~}ŸL› n	àŽôD!_ ’n1+IT<Aû
œÓ4endstream
+xÚ­ZÝsÛ6÷_¡™¾ÐÓŠÁ'?òàÔnÎmš¤µÓ»›¶”HÙœR¤*’NÝ¿þv±
+Ì™DI~¿øùW¶ÈAîo/X(ÓD/>C‡…<MÅb{¡´µ’Ò�Tw?øoÍÔ9(�„Z¨h±âX¦|^M,d¶½ŒãH(¯&•Ì©ÉQ¡š¾¬ó¦k__o—K&ã‹ášΞjÊZÈ
k.ã0Qüˆ÷]Ñ].¥Œƒî± FÝoWÅÛQÐlhåsd™�ð˜=Ù]CÏl·+.y�í©[Ö¸¡Wßè¡‚¥a”(
²#û:ÛD5’UÄ¡ˆ"n‰`ýéB\„LIKq=³FJ	›$‚Mã„ê†2GÁÊîaÝÔm™Ã¾y¹ÝϪmª¾+B\}±I
+ÁQå<Lµfå{£7
:*6Y_uÔyʪގ—-=­æå/Œ‰Ú°�nß– µúÁ‘ÙyµU:4Û.ëŠmQÛùN±ŠU–¨P
+
 £ nH2N
D°u«²s+ªHµvc¥Å‘Ò¾ÙÁ0¨7#-¼;WJï
–äsÙ=bK›â3bÝÚ
+�…§c—­»b¿£‘Ui(ìB4\e]ùTЛúÀ%«-õ粪hhe@šm[Çõ£YÜ•�6àÌÓœ6òf›•uK�ªl;7eH9=5'aÂcSä¸~œ9+™„pÎj@Š™¥8¸
íV"yN®äL+/IUk«)xº¸!�dôwÁN<¹u—Q¬Bóô¼OR�ö©žÊøÔU¿iË?‹×o&^U)P9ñYÞžjÊ|ìUUÆi¤ÇÜ�WΚ±ñéú#5
+_пÉdÌú QnŒ6gl‰×U€µeSÛ÷
=½sãè+w^engú£Kh�/&´¶€ÑwÖHÏÊBÁ
+Ww[¬'Ç©d""9ÏÜSM¹��š8V|ÌþÇ‚�ψCÖþÝÍ×Ôž\^œÒjólM1ÀŒ<»+aÇ@àxÁßÙ¥�úÓìúüÏ©�7#O£Ãìïçd¡3WÜZrT»™dñYž—„.Þ¶1áhêé�2Ä(ä?
™ÂE“0qCªÓ@ðTmù°~ÌÚ™HG„1¬q–»#šr
²ÉX¤rÌþkÃv) ¾p‡&æ¯uÖõÞ4O°.‚v	—7âÇVZz�W¯i˜V`!n»++ch>ŒÁÖòz¦ ¬ªTªÑN_*	‹0M’d¾ ¼ô+¾ §´b¬–»Û·_ÿëêîæ4@éÂï<Tgðà¨º}�E§åoÅóë/àÏIÔ‰</‚§šÊ0FEÊÃH¦ÑX“�am³0Àä.øÀ¡ª 6ºy@„5~°¦ýeôT/Ã>Èo'£GÆçÊÎì[GcP1S•*Ô©/¦}94�#ù±”Ÿ&‡òÔRÀ²7&lE€éïnþëJžp,I*ç‚æC`k.	ØÆ8s®£ì\À•0Ò
}1Z”&fá[ô2©
nø·Ö+5ŸdS¬IË—Y—ù¹’gTMó1ØÌ–ui¹ÏMÅo
+¬Ò ¥�r»«Ìw¿ÌÆÌÊ|˜ÞY¨Z	þbõ…§îEÛïv�¶ĩ¥ª/i¸˜BØ®²‚¡BJcb(@Mƒt[À
+�Y€½M0
J~tùÓþ$“TŠ`ÊÉg$2ãó_ûÐûjæ”å܇3®Â4N�nVY‡1	²Àà’¸Kì6;”Ó!üŽs½ sóÕHºGS*Ä!¯_gVúUq�¾*Í÷h%ƒã&l1+~®-¥ù¹
 endobj
-1769 0 obj <<
+1874 0 obj <<
 /Type /Page
-/Contents 1770 0 R
-/Resources 1768 0 R
+/Contents 1875 0 R
+/Resources 1873 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1752 0 R
+/Parent 1857 0 R
 >> endobj
-1771 0 obj <<
-/D [1769 0 R /XYZ 85.0394 794.5015 null]
+1876 0 obj <<
+/D [1874 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1772 0 obj <<
-/D [1769 0 R /XYZ 85.0394 204.5196 null]
+1877 0 obj <<
+/D [1874 0 R /XYZ 85.0394 179.5067 null]
 >> endobj
-1768 0 obj <<
-/Font << /F37 747 0 R /F48 885 0 R /F23 682 0 R /F53 962 0 R /F39 863 0 R /F21 658 0 R >>
+1873 0 obj <<
+/Font << /F37 791 0 R /F48 940 0 R /F23 726 0 R /F53 1017 0 R /F41 925 0 R /F21 702 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1775 0 obj <<
-/Length 2180      
+1880 0 obj <<
+/Length 1912      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥ÛrÛÊíÝ_¡‡Î”š­÷Æ[ßœØÉÑ™Û�”9í$y IÊâ„E¤ì£vúï»4%Ñ£t:| ‹Åb
,.+&>1ñÄ2ž„±f>þ$­.øäæ>\K3sD³!ÕÛåÅå{Nb2˜,W^ãQ$&Ëì‹÷–I6Üûõn±œÎ¤Hî]ÝßßÜ^Ïÿ�c4@Á¹÷ûÕíç«�„»ŸÆÒ»úp³˜~[þvq³ì¥J,¸BQ~\|ùÆ'þÛg*ŽüÉ38q,'Õ…öóµRS^,.þÞ3Ìš¥£œIÈ1Äc*Ð!Â�T��ÓY
-C¦#Xs ºfÓ
˜Gñ¨É?Ø	$âÎ…~u])ÀE/31K6›²È3T¹”^Û¶['݈3G’ùQœWœâ“�ŽÆÞâ™PÔEW˜“ÃÀYñý«$³”d+
-	WÎèTBøõC:(ñ†Ü‚·	ÿ'·	‘ãQÜJk.ÿçÛä4Ö˱™¤f2ÂÈ£|‹XÚùõ-	°ø|÷iêûÞr<¸KŸÉ8hÕjÄ(1ÿóñ\E±39y›¼‡©€À[ÛÁ®(QÇÚ£ukB’˜€úÊ}fË·u‚N˜”Å¿L
-ÔeBž�_Zig±í4òvuûJ¸
r…Û÷ó�Ô[éû(¾^æ]z¹ÍÛ¦|bpÅW½FL„°?Òüåß¿Þý~óŸK¢nÓ1¸Û›,nnH
Wwçcüºi;Œ¶ãèZ‰ñ"Cd4@fuÛæéì{¾ÌëÁ¤ÙA[5@-¦{ý}zÿZ)¬4ˆXè÷tã
-–Duê÷íç‹óGßs±�6Ì>€í	Ó5

•é—r•
€T
�@3¥g
-Tú˜¨Æ{X
-�7tÀâõ¶§z9(6�_fÉ»¬¬·íòùé›C¥c¥§Â&A»Ôš–IÛŽö)ÌICÔ3¼aZŠß¹b�5Ý«üÂø˜á§ówÕC>Ú@LJ-Ž9vg9vûÍX¶‘
-¬Íõ1¿?Îò{NŠîU~ªçG-ZzŽË£/³jd—C�Veò8¶‹f:ŒN´ {(°U2G¥Á·Ñ *Lâ0h\ß,Þ}šß/çw·#ya$,Ž·�JGÃÒ/–4øk‹jƒéHÄQ'Í„©%Øä[€+S¬áØ\gì;$MC®ìëø×°&)KË�CÂzÿ¶<¤�M9z8?¿·rfÅ@ˆä­-tí�,IÕ1”OOEj1|~HL
¦¼?¨Klmk@
-­�;,Z[ymíŸç�ΰ½Çâ)¯ßŒ˜BB”àÚw>óš)$„Jß]nÓå¹]lí¸6e†
wU•˜Pû6¶„,½{<"…„ø¾xÜ1Û'¥>‹¼QF]'IÂ?Ší”Õɽêñ
+xÚ¥X[sÛº~ׯÐCgJ͉`Üx;oJlçøLŽãFÊ´Ç4	YœP„BRVÔNÿ{X�¦$jt:=
+?6öÄ<‡±$>eþ8]�èøæ>Ž˜[3mMû«Þ/FW·"Ç$x0^,{º"B£ˆ�Ù£÷žp2

Ôûíó|1™r?àÔ›=<ÜÜ_ßýÃŒ)¬�”zÌî¿Î>¡ìasoöñf>yZü>ºYtÖô-fTS~ŒŸè8ÃQ"âÈï`@	‹c>^�¤/ˆ/…h%Åh>ú[§°7kÿ:ˆ
+ãÑöõJïLÀBéAÏ­ï›yH)�ìÆÚS�,$A(Ú¦z[d¨ÒÚm­œdYMXäé5Ž0ãÂ~ÆÁÀdœ›×Ø®“ï­de(7,´þ¾ÝÔ¿ü~äÙ
+h´éK›RFÖ©Z,̼Óá1]ãˆ�²àÉý¼¿Qªm›Õݧ.$ŒƒØÙûgý2ŒOâv-	˜]Ð><haHdÿ9€Ï	ÒHk’°XD;L]Î Yg3*K6–Éäœ{µFi³Jš�dŽ8ñ£Î�3ÉBj׸ó�:vò2orë9ÚÈyƒí:ÉÜJŒtT’®°‡Á$e$½ª=Ã6å¡J&|"ÀœL<´«ÄYa³Ã4…N-‹·Œ²ƒÜö‡ gÖÕ–QÏ°go'd•OŒÎµJJgÇ9¸!£�.qÏ UŸΑR7ØÙTyÙ´Û(ìt8ry·RÖaac�ÐèïÎH8rS.Câ‡"8LPÔ
ÔmN“iON“³¤•””ÿϧ©E¬³c	6qIxd˜GJ‚WõÝõ=î>ÿúððùËÄ÷½Å0³s`³0Ä?-Æ/s¹ˆâ6ܘi2ðž'H·tƒm^4xÝîòf…B´Ò]ü2U•‰IÀ¤Èÿ…•Fàez�äî¢.“µjïïÀ«·›�®šw8²Ñƒ¶»Õ“´-$¯«L²¼ÞÉ¥¥.§.¾
�ÊÈ?<2³ù‡»;s¼Dg„ ÜQ“
¤ª€¬¹„UÐ6¿�‰ðrƒŒMUìq»T—ÀýM�¦«¤JR
+ aW�š½�
+Ná¸Æ~<ö¹$
+ÙF¬šDÞ¶¬ÏP- HeˆTËã8¶¹½û„ï»Óº½G¯WªI¯*Uëâ•À	_¶iÇ0ˆìŠ¿üû·ÏÜü犀�U:d
+nþ�ó{×mEÑÖý¦¿mò"oöçÓ1›ïK½©á|ÑŽ`$Œà1FPQ@å1ðy€�‘Ü7—Óð·0šÁ©ìi8å˜îË�[ôæ¢yb>N“YQVõb÷úÔŠÒ¡BS˜'�l/Ó´HêzðUB,-ÚE�Âû
…Â'Qà·	Xfº9«/Œ�~¹¬p»~VƒÏÅ€p.Ù±Ææ¢Æf¿üú!H̨<Ö÷÷‹úvIÞœÕ':}ø ‹
‡à­ Â0>N×»´,’—¡]$‘at‚‚ìz�ëaíbeX<�ûnÞ™�]™J»£ñS{ûd(M‘ñáÏe<ô	ü9h�2N2�˜Þ~};µý¿p"5endstream
 endobj
-1774 0 obj <<
+1879 0 obj <<
 /Type /Page
-/Contents 1775 0 R
-/Resources 1773 0 R
+/Contents 1880 0 R
+/Resources 1878 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1752 0 R
->> endobj
-1776 0 obj <<
-/D [1774 0 R /XYZ 56.6929 794.5015 null]
+/Parent 1857 0 R
 >> endobj
-1777 0 obj <<
-/D [1774 0 R /XYZ 56.6929 626.4701 null]
+1881 0 obj <<
+/D [1879 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1778 0 obj <<
-/D [1774 0 R /XYZ 56.6929 517.4334 null]
+1882 0 obj <<
+/D [1879 0 R /XYZ 56.6929 581.7741 null]
 >> endobj
-1779 0 obj <<
-/D [1774 0 R /XYZ 56.6929 438.0429 null]
+1883 0 obj <<
+/D [1879 0 R /XYZ 56.6929 460.6765 null]
 >> endobj
-1780 0 obj <<
-/D [1774 0 R /XYZ 56.6929 376.8269 null]
+1884 0 obj <<
+/D [1879 0 R /XYZ 56.6929 366.7195 null]
 >> endobj
-614 0 obj <<
-/D [1774 0 R /XYZ 56.6929 339.1376 null]
+1885 0 obj <<
+/D [1879 0 R /XYZ 56.6929 293.4426 null]
 >> endobj
-1781 0 obj <<
-/D [1774 0 R /XYZ 56.6929 306.6767 null]
+646 0 obj <<
+/D [1879 0 R /XYZ 56.6929 247.3727 null]
 >> endobj
-1782 0 obj <<
-/D [1774 0 R /XYZ 56.6929 271.6646 null]
+1886 0 obj <<
+/D [1879 0 R /XYZ 56.6929 211.2315 null]
 >> endobj
-1783 0 obj <<
-/D [1774 0 R /XYZ 56.6929 207.5268 null]
+1887 0 obj <<
+/D [1879 0 R /XYZ 56.6929 172.539 null]
 >> endobj
-1784 0 obj <<
-/D [1774 0 R /XYZ 56.6929 137.3205 null]
+1888 0 obj <<
+/D [1879 0 R /XYZ 56.6929 96.3402 null]
 >> endobj
-1773 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F21 658 0 R /F53 962 0 R /F47 879 0 R >>
+1878 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F41 925 0 R /F21 702 0 R /F53 1017 0 R /F39 885 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1787 0 obj <<
-/Length 4062      
-/Filter /FlateDecode
->>
-stream
-xÚÍ[Ísã6²¿û¯ðíÉU#>ܪ=8“™¬wgÞØÙÍÖf”DY¬H¤F$í8ýëF7@R¢¢™ÝË›9j‚@£Ñ¿nÀòZÀymM$t_§Y!Íõrw%®ŸàÝwW’ûÌ}§ù°×7�Wo?èô:‹²D%×�ëÁX6ÖÊëÇÕ¿f·?¾¿ÿöî盹2böMt37BÌ~¸½ÿéö{¢}¼ÉÔìö»÷ø3QØIa·DÌþòãÃãÍ¿ÿzõþ1p3äX
-�¬|¾ú׿Åõ
-ÿ땈tfÍõü‘Ì2u½»Š�ŽL¬µ§l¯®þ78xë>�’€Ñ62V¥"0zJ&‹­´ASž‹®ãí5ì­³HÊTÁØ­lnæZ%³¼Âg:«÷mYWù–©‡igOÝ®¨Z¢¼lÊ冺úO‹²ÝÀLŽ-"VùŽ[5¿ºûÈc®VnÔ¢áïëõÙoyü:oy9r´X½±¯gS7íĢ籆�K�ª”QfŒ"!mên»"�ø܇Wj–UÓ9Ó‘=|:ö°á™r/CZC?¶%|¾òC7:p£t¥:ó{ð¶h—oESoŸ£e]­'ø‡E&±ÔüA„=®çZ«H[a®ç
-iJºÿ|žN)aדÔKižOÌ!ã(Ž�å.¿#òí’—ê4ƒWÅ+->wås¾uÚádT{q´mY=õ‚›`(
eaIóç‹
È+–oÞüŠ�ê…U‘ÔRý±Z(Y“ú	<÷»üWÞêüD5‚6¼î¹Ïíý?o¤”aS`Ì$ÎìxSþ±)ÐÀ¤>#�8��Tž‘ù»)a€ž§2>éž]S¬ÞLˆ$-”–D¡¢ØƾÓK¹ÝÒ yÛ»}ËÌ×øT³UÙì·ùk¿"×xøñ–dßËÚ=WÌÝÚ9hü^W,3f@F â)sàœÀ›)¬%x¯µ›¡Þ1«žg–1X½€1aíÞêi3¼}jÏò®ÝÔ‡²ÍÛò¹ ’w?¦·j$ÿÐpŽÈµp%4´vVçh88}M~­/�GîÓÌVÅ/B¨Ê3´xõ³ðG÷ÔïX¨¸@1vgÄ™S\êM?ÖuçÍeíVðf´ì‹üH–z-™/§õTÅÙ±šjé¼êáÆκe‹K×ä.ð
Rr"|ë

´¼9{¥_N¢ð\nó¦™R!)¢·›&tëPY|!n Q°Ü’¹ZæÌð¢ 'ÚÕ˜ám]ÿÚí‰ö—¢)ë3x ½S©‰¬j¼=ï6yÝToqçšëÎ5–Å�6<BݤhøzU¬ón{:˜÷Íw÷ôDG~WµÅ
fFo~´ÙŽ³¿;VuãFеû®¥6�˜ÎžŠª8äÚRÔÔS_#
^“Ê‹~7S68çqÈ3ÎQG	„¯t«éHadâ•î0¥¸0¥6É…pƒÈ“pÓK
-ü½H0Hõ†Ä(§³MŽÎHÅtÐÉh{òuÏåÊm
-á p³½�f[Éd…ÜŽzÏåØ
-h«ºïæ°-Ð(9Æj.xŸÕ
xÅZ]Äï:ô!H�ãµ<UM¿<5dÃ
Ä;Úò½Ë�(w­Þ™ôRQ‚Ê+Ðûãâ÷ä1¸ÃÝ€ÏÜ6
‰!3´8;t
ùק FE‚ÂfCAe7ÜdšoÒ(N•ùOÓü7ä�w…)%=Ê5MYÕÓLÍY‘�Ž$ ±±&3ÇÊr ²4œÀ|zv;Ç/�ßr­uñBîÞ²¶`«98 bL�Y¾$ò–³,¤Tý,äwÝtν)Kž
-žMAs0b@Fꃟ�¦ðÉÞQ.D¶>]‘9®çø9Æ5ï-\»d‡Ë8[Ù
°B¤ÿmesáX�ú°
-´dÅ]ŸK6š3Ø=K¢4µ¡rw8£ý§ÐÝX;{ðuRš dvúƹ÷ÄôÖ{€Oßá@ÝD,ÒçT
-’''
±)C<UBòJˆÙÃ0’œ×~Ÿ„êM:
-âæ,öILjò0Ù®È+93ÇL	®«!)TäE
-À€†Š'öž�/ad‘4}ÌQC ©>DL|F
-ŠРórm&Ö§
—E°_¹ž4�æb¹Mõ‰7�p&tÊš`!ÂÖ|ڶ˙]ò«®ÓèžpéÙ^Ö[
-LÇ_“F&ÉÌ—³,÷ÜQ_"!>ƒÿºÛp´CZÓ]�‰êœYšpj�½§=Ž
-¹j¶W9»3&›.;
h,œ�}ѨäÇôl˾ÉÕ*j
\vþÓÛ&�úu¹õ3ù:†i
-~M×;Üþ
²ÏÜó.­ÏBM¤cmÿHIæq,#ƒ×TG> 9	£€ôüm.É$¹ì+•:r–8x±F«YS›�@ê-Ó&ÜTMa‚ë“ÓïÞTùJA,36zèÄFýí9½áh°+áo<—)£¹ÄmŒó›™ˆ
-�?œr0òP�Ñœœ
-.é€xkêR�6‘Mb}31RŠN’ˆ•‰aPjA�C¼£ã,Ò&õ#¹‹Cç.ÚáÑÛÔ��ÇÚzꆾ¸öŠö_ÿ=@ÿçq
-¾ÎªpÕ¼v
ɌΤg
-—B³þrà”÷ÿúž¹øendstream
+1891 0 obj <<
+/Length 4197      
+/Filter /FlateDecode
+>>
+stream
+xÚÍ[[s㸱~÷¯ðÛ‘«F\\x
OU¼3³'Yïdìœl*›Z¢,ÖJ¤F¤ìx}ú�¢¨ÕlååÌ<j‚@£Ñýõ°¾Vð__»$R6�¯³<Ž¥“ëÅöJ]?ûﯴô™ûNóa¯o¯¾ùÎf×y”§&½~\
Ær‘rN_?.ÿ9»ýôéãý‡»Ÿnæ&Q³o£›y¢Ôì‡Ûû¿Ýþ…iŸnr3»ýþãþL
v2Ø-U³?þøðxó¯Ç?]}|Ü9ÖÊ"+_®þù/u½Æÿt¥"›»äú~¨Hç¹¹Þ^ʼn�’ØZOÙ\=\ý58xKŸNI ±.JœÉ&D`ôµÖQž$æHI¥ÖX’Á‡�ï?ß}z¼ûñWCßôbS×s“EF©Œ:¯›¶“^vÐËèÈÆ:cŸª½™ÃJf?Új»Û”Øv³CWmªî�_¬š=7våÚÛª~æßiš_»ämr;»ëx?~
ß›�ŒvhË%·º†Ÿ‹¦~)÷òQ]lËöøýÝ'ás¹Üßh7+ÛºÀâ`ɼžy�,«¨a|“ºÙKµ(¥UîÛ¸³©�ý}]ÖL­~4êóa[Ö]Ë$\1=w]ÕÔí°
™Íž«—²~7± }‘Š“X„|n#ìpâwb·¯ÂÔ?Úuƒ"¡æa»-öo<o³bbåû/xKfydh4Úx‰°õlªºd+/I$.hÈZ#æ6±ÇÊ¥ó(ÎD¹p�¦ÖWÉ@¹ŒV³n]rcÙl‹
+%¯5 ¯‹Ž[჆û<IÔ-Ôlv¤b©EÍ�bÓŽ¾+ü´]W.çËrQ�2íîÓKÌ�*ůhãû¯ͦ©ç"[^Þ‘®-ËMµ­:äÏêN±•~kg¸v|óº®kî¾(ÚrBƒtf¢Øä(ÑÆKûµÚlx̧7žfY®ŠÃ¦c¢.ÿ(¸³‡–Q2��˜ÛdòØàý­hJE@Aâ(�õH@m¹‡)&ø·y¤u¦Úb
ð†B2™è"îQZË/Dèê?-+Pµ=ÓHé�ÈŠ†­F^!˜Ð˜Ã�§«³ßÊ"äuÑMì™Í
²“{6�-x›,ÕÇæ	¦~؈~9”déЬê¶+oœ+~²9AÃóD/÷CšØõ¦jI/y(æ&>*›F™GÆ<Sv‹oöeÛl^"@äÕÿ°Æ4ÖV>ˆØ,¬5‘udŽ^>®Ë‰)¡‡N3/¥y11‡Ž£8Àø³J¸xè!Hɪd¥å—CõRlH9HF�Gב¯ò‚›`(«Â’æ/92 ³hÁ‰NÕ™H[m.˜²Ž\’ù	<÷ÛâÚ'ª´ám'}nïÿq£
Ðü¦À˜iœ»cÜf×gµ=#�8…�„ðD„ñ~J æ™ŽGÂÀ!Éá‰þ}Ê/‚¤•±æ"ªÅ.Ö#T³³@|»ë„ùŸf¶¬ÚݦxëWD�‡o¹Áæ½hè¹îØììצ.'`Ì€à@ŽÎyºÖ’ùµ¬h†f+¬zžEÆ`õ
+Æ„µ#£·OkâYqèÀÝW]ÑATÁ$�>IoÕHfþ¡!À-\	Fºàc×ò5Î_3¬õãÅÇã1z¢»øY)S{†È‹Ð,òFzØo,T\ :†3qé!Ú
]5o.+X
Íx
~°¯Á‘<øŽùbZOMœ�ÕÔjBÕý
D¸€¬e¸À7lpH)˜@á-6Ðònôì�‘Dá¹Øm;¥BZEn7O>èv¬Cyä\ÀBÜÀÄÀr+áŠ"œæ©ä'ÇÍC†ƒÃÚ˶j–ÂàÞƒIä´ƒï×EÓÖ¥lsGMq‡Í�‹rH
ŽA4ÄE�~ãB˜1ÌcóÝ=?Èïê®ÜÃ̈æ£Íf|ú?‚°rÿÔ´4<Ä
‡nwè¸ÍCBä]Öå¾ß–¡ªN„P^$IP‘óÀ›Іƒ$;‡Ž6JÁ_x­[N»ŠD§^ëöSšSÚ$½ào`}âoz	 *D¼×²Àók#")üX`6ð“â%
+G•vœœá$¢A""ëí7·ð�q•ˆw+~‚ý=UäÕñèüzÊ’2TF“^ËMòŠqÎrDaÛ“sQŠÕ°#ô$ºM¢A$›pgü>—ô†UM1
+ûgÕ8ZÇÊR»+F9¡¾D�
+¾:Ê…‘ -þ�ŸëP˜Ý#å¸Å£K'%.&Ò.cãîSÝÝ?ò_	¡š–|ÞÇ_¿G‰³Ù±vU’v|þî½v`L¿åŠ½ÿõÙÄÁ
+rrû™«¥¿CòFE*f9¿Ÿ¹l–œÄ\±ÅD£šØÇ“@ªÛ'J©�H
ЖMß�‚[ ±"ún>É >­EðI‡<ã|
+*o@ïÇ.Äï
È|ð
w>£m’ÄÌÐâØáÐ2vPŸ’5
+›-¤%—Eh¸É<?É`wC©èwçùï	]aJÍ�jÅSRu‚))šÙÄF¢±cqÇƉ£r>h)8�ùììžÁø’p‹Z«ò•áÞ‰¶`«rp@2e4q|leø’ÉI³�R÷³0îÒtoÆ1RÁ³-y‰�‘fïçã)|¶7J†ØÖ§K2ã‚ŽŸã¸¨ê¦Ø®pe
gK;`�þËÒ&ñ9Å°
+îï½ð�T�ÛËß:æ™Õ)I!Mããm «çµøcq,„‰Fêp¢—Ål…¹Ÿ*ç ŠPŠCaa
Ý«àÏ}©;È9‡(O8mÇ÷¬_UP"<‚ïÞÉÁ��¨EÎøô5•“b_‚‘*ïíOß}îÏëü<eÛµ¿'ÑÏ!—	Ú<ž®H¤‰>©íegR{mT¤mª/ßÎHÃôd-V$QÖ&óÙ4�ä&AÖŸÎ
‘d²kö”ÉdæÜé@,”Ãæéÿã5¦>¶1xY*�PìPõ+ÿ=[�Ä.:vÓbp&=9�u’>:'‡#Æ1~"…Í�Ûìy�¬"ímWNÅþ:K#•…*(�°N^uÉœö(÷Pœä‹SÉ7æÆ×ÇžëêWæð„‰ÿE4ÏfïïoøøŽÉXd$�Lâ¢Q,üðã-u4³‡»ï¥õç�|þK?õ�PÞ@î‡x¢óÉNÚáX1þ(ÙIM(}½lò<Trwêuû˜a[4íSËSÂ_±“c†Ý¾‚”J„‘Û(NM>­}¸õ´¥ó²òo…4ÈQA:±¸×r“ÓxxÇÍgXG•&× ñÃOÜgTìÄny>{:È°Tqù¹ã
+GV÷æþþŒžŸO8ä+0€¹uF{d—[y¤“Þç’6•SÄÔgÖ_ñ�˜Ûdb}6‘²ö«V“æ¢ð #¹Xn3}âÍGœ|	ãZHc\¥NG÷t€KÏ6_Í^À²é
+Ķ+öq*º9PÂ_Ÿ@_ÏS™þXØ0,Q¡:?0y! ÆYÖËpæ¿'_lüùþfÓ¼Ž¿ë+]�I	7+ÿá0ÇX¢Œž¥Ê=—tåðmlœ¤™;{�Ì5
+SqEZ
?_‚
+W)°QðCj&Lð“b¹ÚL„¦î•6|Vg1fÊáy-ÓLgN‰‰²4ä8ó¿Ÿ9aqý	ËäÁ"ޟʳpPózn˜ôCèÐT`Úÿ&Y”¤yòõ¬`‚åž;êK5øÇ`ð_{Ž5‘w¯L®üz2ªødyÄÞÓˆcB®Ú‚íÕdwI’O—�ÑX8ûªQÇìl#ØDEµš[.~zÛR¿.ªQ¿0ÖÙ0L[Êk¾ßAcø7Ⱦp/—¸¬=[M"[÷[J2�c%x¹þÈ]ô.'•( ;�ËE:M/c¥1#°ÄÁËZÍŠëØ	dÞ2]êƒÛ’«)B >ÿîMU®Ä:£‡NbôÐ�ƒÁñÐÔ(ø�xƒX‰|ã¹Ì$šKic7sA¨6NŸKÿf5Q��?ƒ�k¹?!÷(ÊÿiýmÀWÛÃVnÈ
Òð*•‡aÔ­g?=@rÝõ7/Îü
„Å3;õ*üQÂý÷ýŸÄHÑ™þOŽŒ[A˜dsí™B	k•�YIqÊû
 endobj
-1786 0 obj <<
+1890 0 obj <<
 /Type /Page
-/Contents 1787 0 R
-/Resources 1785 0 R
+/Contents 1891 0 R
+/Resources 1889 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1789 0 R
+/Parent 1894 0 R
 >> endobj
-1788 0 obj <<
-/D [1786 0 R /XYZ 85.0394 794.5015 null]
+1892 0 obj <<
+/D [1890 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1785 0 obj <<
-/Font << /F37 747 0 R /F53 962 0 R /F23 682 0 R /F21 658 0 R /F39 863 0 R /F47 879 0 R >>
+1893 0 obj <<
+/D [1890 0 R /XYZ 85.0394 751.6872 null]
+>> endobj
+1889 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F53 1017 0 R /F41 925 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1792 0 obj <<
-/Length 2137      
+1897 0 obj <<
+/Length 1971      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥X_sÛ8ϧðÛ)3Ë?¢$î›Û¸­÷Ú4Wygî&ÛE¦MeÉkÉîæ>ý�¥H“tæÆ) àÀlFáÇf2&±âj–¨ˆHÊä¬Ø]ÐÙÞ}¼`Ž'ì™Â1×»ÕÅÛ"™)¢bÏV›‘¬”Ð4e³Õú6xG¹	4¸ºÎ²ÅûðŸ‹ÿ|\\_†L¥Ró››ÅõÕòß—!—˜�•ÒàËüú�ùgÜ»¹T<˜\d—ßW¿_,VƒZcÕF§¿.n¿ÓÙ,øý‚
7Ì~‚¦Ÿí.")ˆŒ„èwª‹ìâ_ƒÀÑ[{Ôë
-F	1÷ø‚³cDIÉ'Î�ŠÄ‚ëŒåÕ5•ýqsóõÛ¥”Áʘ‡ÅÈ‘tò˜¤Œ)<µq<lÄ“’4¢)°Žû¦í<r8#RÖ3å-\Î’àNëÚPipw,«7–Ý=n¢’°õ'•´¬;}¨ó®lê¼*ÿ«×øjÝìòÒ	©ó�V†oÚã~ߺ7°âQP:éEî˜ó¢Ð{·™×½´²ÝWùƒ×Ô¡±e
-ø‰€°Ü
-V̳÷Ë%p&ìQ	 �-ñø‰QJT$^ó'4NÇ”ï÷‡KP¥ÙʼÓÕÞQ4õIºÖ­îóC^€wp©ë¢Y—õWÍƯ"RwzÓØܺյ=j­f\Ê ®œÙ˜F9pÆ*ÀSuÛáFטgj’7Z}8Y�€nÜÓùaÁ·&òöÖBXnÐì�“}¯Q¸“™D
䧈‘öÅCsüÇ™«ò‡«Ïã¡F6ðˆÝL¤*gFek>�~mã§PppQcœ'8w*çmSCŒ	
ÖAôQ^ë9�|û�!rFaÀ¡	—î›»Ïà„Óˆp%Õ,V1(©_
NTš¦~8	‰áX$âæX7NÂÓ(y¼Ù¨xµÌæï>/<ÁIB£ˆ;St}*ñ³Õ;]wè„S‘{Wiƒ§�†«{ç<ësëOçs»([|qb­Ýîw�CáÃ(	PO¿Pâš‘dž­î�øyXãA/
-€ž	ÄÄ�®ÙûoË›Õò뵧0�÷9ÔžAj¬
-¸âÁ±uïÜð
-3ñº±¹—¨€ýfæ.3;åî`�ˆbÔJio¾±½x‚£<À€µ©ˆÈj§4õÛWËÜ(+±ŸÑÍ=Ù|$ ME³§ƒê×zm‡ÑàC\²÷ž›Î
�JBG¼äƒ¿¡ø©(�¿©Ù8v0…we‘WÕÃÙx‚áDø£G-*ò-y3 dP¨^ÁŒ×˜ÑsMšÅ	fÀ
-'8
åÑ£àÉKCàSÿ
åÉݱêJ
+xÚ½XKsÛ8¾ëWè6RÕÁƒ �£ËYÍdl¯¥líV&Z„$ÖP¤†¤œñüúm
+ðäæn¹œn–·�÷¿ý:ÿÏ4 ±Àr2{x˜ßÝ,þ=
(Ç ÚO~›Ý}ž}2²‡©¤“ÙÇùrúuõËh¾ê<ë{O0Óný9úò�SØÄ/#Œ˜|ü
^0"RÒñ~r†xȘ“ä£åèŸ�ÁÞlû©7#Ê"ê	e¾pp‰"S:«�Ò›xw’ž*‹a(Á¾Ö	j£2°F8â”
+«Rš¬,¦
ãbÒ¨<w_ô�ÂV¤‘ýbWÖ�Qb²¿2E’…ÎlQ6¾¥#$Â8¶:Mi–­U‘Z`OíàÏ£ª^¬¬ÌÉI¡þjŒ¨HöªVÕ³ªÌ{¶1Ϥxq–O“Õ”ˆ‰ªe‘ÖFò-kvöíë8 T"΄€A’sÚº¹œ?N9Ÿüëv‡“ÙÂVÒÉ\­~6¢o»l½3ì6ÏÖé“:8S[A¹1Ï¢¬öInÆus|X/óÖ}-yR»ä9++íjÝÅà¦@Yz¥ˆD$Š»zØû’¢0ä.që¤pšç±V©ÝLiÝTÍÙîöj_ê|ýdkÅ©z:n·Y±5¯¿cÌ’­-0Þw�²j2r…Q©uY¥WG"âܪýì±B¥fŒ+3±¸«ç¤H=† pŒÇÎRS%kŸ%(!\èP×:]ùlÆ
“E„@»Ã&C†M÷.nîLP–ŸîÛ[yìCŽ)‡7l p±ñt§€žÂâ¢9‡~(lFœR¢Ë“Ä�c¥³
µötÌòÆM[h¡qD¿cŽ³¢QU‘h´Hòìï¶(`*-÷If�è~UbfêãáPV�nN2kÝÔ('ëµ:X¡N�±–Õ‡<y±æÊ"0�É
+!*uð¥Öå¤.¨1Æ`wP}˜ª6š�¡gqLˆèµÏ¸
+‰‘ˆH4,L·Òðì‹o;Àz
¥!ômø¼;Ū©˜‹Ú·€´(Œq<„ÛÛÅ'ÃùÎ~†¯ïT³~Wµç.‚ßøVÀCËËùÜìoöiyÿ6‚§ÙVƒ)Ñ0iiƒFƒT…öv"FnÍ�".wL(/n›u­ÖAZoªrÿ‡zq�eó¨Õ¾Óhãwb/…ñëdÈ4¾6fNmJc32´ÛŽ—æùøhž[U¨*1TÒp…2ÿžè½å¡ÎêódÁ
Íà	}@ü—	˜’”ëÚÏ­õ‡P¢}—ç¨u§uˆbý%xöñªé´tD!Ž—ûx¹&
+]uI7¢Ý(ñ¬¢û-ìxM’o}À&à
+�£áàý&ËÕ«ñÅ.X�šˆoÏÄ•ø:­×ã—•kqÒÝðaÿ÷(	ÖsC¶ºÎ“ºþþÊHß4˜Ø{ý£’„�9ßE!´à°!
Å	†0J�HvëÍ|ùáqñ°ZÜßy�üé<ÐtA‚#(0ÇJËcs8¶œŠrË
h4¹Q¹Ú:`�‰e¶-ZVc
š7KË8A×ÝšŽí`­Œ–‘®
ÏJO_>>:†O»®£V¯el0ýxûÁXÄ…ÙkÃ8p»Ðó

+n1{wïäø¤§6É1oήéew×µ—ß²Ù]®Y¤'åQ—*o€Ê
gáo$ §u%
N«M
+{AÈf†¬ë‰ç$?Úa¹ñ‚>dICß/ÿK<Aîþè–~²î”Åi�öéꆺ�à•XÀÕÚ•�@*˜>Ýåð|T‹ý¸kàeXoЕV»E[QIw%†—uâT²®ÇuÖ
 endobj
-1791 0 obj <<
+1896 0 obj <<
 /Type /Page
-/Contents 1792 0 R
-/Resources 1790 0 R
+/Contents 1897 0 R
+/Resources 1895 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1789 0 R
+/Parent 1894 0 R
 >> endobj
-1793 0 obj <<
-/D [1791 0 R /XYZ 56.6929 794.5015 null]
+1898 0 obj <<
+/D [1896 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1794 0 obj <<
-/D [1791 0 R /XYZ 56.6929 751.8114 null]
+1899 0 obj <<
+/D [1896 0 R /XYZ 56.6929 684.0716 null]
 >> endobj
-1795 0 obj <<
-/D [1791 0 R /XYZ 56.6929 637.809 null]
+1900 0 obj <<
+/D [1896 0 R /XYZ 56.6929 572.8605 null]
 >> endobj
-1796 0 obj <<
-/D [1791 0 R /XYZ 56.6929 571.6272 null]
+1901 0 obj <<
+/D [1896 0 R /XYZ 56.6929 509.4701 null]
 >> endobj
-618 0 obj <<
-/D [1791 0 R /XYZ 56.6929 530.4875 null]
+650 0 obj <<
+/D [1896 0 R /XYZ 56.6929 470.2699 null]
 >> endobj
-1797 0 obj <<
-/D [1791 0 R /XYZ 56.6929 492.9536 null]
+1902 0 obj <<
+/D [1896 0 R /XYZ 56.6929 433.5878 null]
 >> endobj
-1798 0 obj <<
-/D [1791 0 R /XYZ 56.6929 459.984 null]
+1903 0 obj <<
+/D [1896 0 R /XYZ 56.6929 401.47 null]
 >> endobj
-1799 0 obj <<
-/D [1791 0 R /XYZ 56.6929 390.8804 null]
+1904 0 obj <<
+/D [1896 0 R /XYZ 56.6929 335.1577 null]
 >> endobj
-1800 0 obj <<
-/D [1791 0 R /XYZ 56.6929 303.7532 null]
+1905 0 obj <<
+/D [1896 0 R /XYZ 56.6929 244.1508 null]
 >> endobj
-1801 0 obj <<
-/D [1791 0 R /XYZ 56.6929 225.6163 null]
+1906 0 obj <<
+/D [1896 0 R /XYZ 56.6929 168.8052 null]
 >> endobj
-1790 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F53 962 0 R /F55 970 0 R >>
+1895 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F41 925 0 R /F21 702 0 R /F39 885 0 R /F53 1017 0 R /F55 1025 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1804 0 obj <<
-/Length 2916      
+1909 0 obj <<
+/Length 1658      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥Z[sÛ6~÷¯Ð£<�\y™}rçÒ´v6Rf·Ûö�–(›ŠTEÊÞô×ï98
-Y\!O^ýöŸ¬`?]q¦`µÉ<p&ÒTN6WÚ(f´R~¤¼š_ý³[0˜µ¯‰B›„©£ÉÀšGé°À8ã0‹µ`<¸˜Có(جÂ�¾~gL€‚%©
Î,¤Ê6yû}›KDhÍbc‚‡˜ëPÜ©�¦NY¬¢¸ÏÞ|›/‹ß9—yÇ%Óö)§NýRå;ì¦SË
®�Pßòï×Bˆ)œ°ŠÌtAãéô9+÷‡w¬Tp#EÌDlÄ€Žø6œéTiÜì›––Í`bGýGõ?÷w·4ò;7|]»é—�Ì�™6 '3�jŒ´+’RÔö¯ºÂ•Ra÷e‡p!PØ×
-Rúb‚>Ý;IWffB¥ðR2•èähSGœÈˆ	nú
-5⛿R-Ú£HÓ”lì[·P’%ÉX
-Š±—šê_*û{#oÜ÷{ ñ4yȨ°ƒÑºr¯ÛTæ,ç~–ÛPb&#Åb.Gü4CQ
•¿J±ÔV!¡7vÅ鱸·û‡Ò«òÑGL—ÜŸ$‹ c¡ƒÁÆž15:eKhÌt7Õcì¸÷{üŒ‹2Y4 ¸¼Kþï0ÌNÇ�&'r8s�Z�)’qLá&!_>fÝ@¥dÃ)ïÿ6™&Èendstream
+xÚ¥X[wÚ8~çWð'±ª»å¾™„´i“4èžîiûà`A}jì,†¤Ù_¿#KœÐ=›<X¶G3ŸæòÍÒÇðOúJ Ì"Þ#Ž&¢?[öp
ïÞõˆ“	¼PДM{o.XØ�P$©ìOç
]
+a¥Hš~Ä··ã›óË/À
+<¡a 0\Ç7Ÿã+ûìvÑAün<D(%Aˆ1‰ç7“Éø,ø8þëâîÓõU<_
¿O?ôÆÓ-¸æ
fÙß½¯ßq?…s|èaÄ"%úOpƒ‰"Ú_ö¸`HpÆü“¼7éý±UØx[oír
+	Êe?`•cÕí6Œ°
+)˜¥¯çDCèå”ðBuF̺ª#Ê€ÃlÍò¤ª«H ÃE¯ÂÚ
+âj×6AZÀ&z–÷ëýRª£iX½ü†Nõ<Ùäkç\÷âò^‘S{³©ô|“¿gÀ'Àñ�0ŽB*Ø‘˜4¤^	Š—ª£’vs›Š„ç¶4[éÙº\=DF`9¿
+Îu€kEFÎÚè®Êò'”–ƒy¹²@yóH(1‚B±@�7k±–r¦PD€%¬˜­´Êê…�ªeÀBDŠ®óïi).C'™8¥–`
[
e¸í„�AÍ)�	‹¢´¯R+ùôCvU”ë-´¶¶Ýùú
%	艞#l*os¨ýöÍä9Š°„&Ã"$”%Ìñ—øúöjÜq,$lpsÃÔL¥IS2¸ßdyj–Ô§1LÞÇp•öéùÄ>¼»³÷óúœåÒ>5{¬ÃU3úR!…¡bÇä¿’å°á¬\¢ŒÙ	¶Ç@!ª(RQ´Ë
+Áà"ö<š©­Ï§r“»å½ö¥_mtú¶ã@à@A[j«S¨¨*=Òj¾*—
+¦×ã)]»Ž‘VÊÀí,1ͨ�1<HuÅjÊÔÜÝ?Û뺱Ý.²¦‚º�ÌÓ™;hÄ�ÜóÊÇþÐI’$'™ùë
+‘
+Uزo“Ÿ“É0Tí‘c‡
™sâS‘Pªý™ÜZèB¯’µöÕ⺟+Ц�*Ó0
+O“çj­—ŽÎà{©\­³ÍrgêŽKŸP…!§¶ãŒäÁ¸É[¦{çɽýÒ¯ÓIBù0KV7ÝUh¤ È¸ÜË"ÏNVŸ¯„pûá1ŸmëªE«¦·Øô/Ëü¥_`€"ÌÏ&9Þºúÿ:³û-Š‡ˆ)õÂGÆÜ"âA?À(¼]À”.
;°ÿ\y™bendstream
 endobj
-1803 0 obj <<
+1908 0 obj <<
 /Type /Page
-/Contents 1804 0 R
-/Resources 1802 0 R
+/Contents 1909 0 R
+/Resources 1907 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1789 0 R
+/Parent 1894 0 R
 >> endobj
-1805 0 obj <<
-/D [1803 0 R /XYZ 85.0394 794.5015 null]
+1910 0 obj <<
+/D [1908 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1806 0 obj <<
-/D [1803 0 R /XYZ 85.0394 181.7045 null]
+1911 0 obj <<
+/D [1908 0 R /XYZ 85.0394 575.4191 null]
 >> endobj
-1802 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F55 970 0 R /F23 682 0 R /F39 863 0 R /F14 685 0 R >>
+1912 0 obj <<
+/D [1908 0 R /XYZ 85.0394 427.1073 null]
+>> endobj
+1913 0 obj <<
+/D [1908 0 R /XYZ 85.0394 329.3834 null]
+>> endobj
+1914 0 obj <<
+/D [1908 0 R /XYZ 85.0394 262.8864 null]
+>> endobj
+1915 0 obj <<
+/D [1908 0 R /XYZ 85.0394 196.3893 null]
+>> endobj
+654 0 obj <<
+/D [1908 0 R /XYZ 85.0394 155.0304 null]
+>> endobj
+1916 0 obj <<
+/D [1908 0 R /XYZ 85.0394 117.4002 null]
+>> endobj
+1917 0 obj <<
+/D [1908 0 R /XYZ 85.0394 84.3344 null]
+>> endobj
+1907 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F55 1025 0 R /F23 726 0 R /F41 925 0 R /F48 940 0 R /F39 885 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1809 0 obj <<
-/Length 1934      
+1920 0 obj <<
+/Length 2406      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥X[wâ8~çWð°äL[#Y[ûF't3’
ô93Û�ðŒ/6ée~ý–,ÉÁD„žÝÃR©\*}Uª‹ÈÃ�¹@B†rI†8&|¸,x¸†µ�byÇs½_~ü@£¡DR„b¸XÉŠŽc2\¤_FïCW 
�nfóùä:˜O?Îþ}7›\$ŽH4ßßOf7Ó_¯‚�c`fŒG·ãÙçñ'C»¿’áhüq2¿z\ü<˜,:ÅŽ•'˜j­þ|yÄÃÎðó
-©=h„Ô‡—HPXÒh,6J€“G¬D¢(Œb�¯yÐê`˜zòB
C,-ÓWŒÃ\]‹Ñ²*›$+k3Kô_¤Ñ6ó_&¿™ÁîŠÄ#µ¬ÚÿÔКMÒX!IiOÊ
-i¥ì÷eÕÀ"Ð7¤Ø&yV¯µ*Õ.ÉÍÄn“šÙV튬®³ªôâø¾#y€dˆðõ·}4B‚I‡vR¦~‹ÌÅwY„s)zÑ(D|”˜鉰G5ž
-k«wÔ‡¢PÍ.[š©*—»Ã¶�c›Ï:CZ™õ~¹±Ò-å§ÛñµuOÇ' VíÛþÎ@ªžUiFͦگ7nl�±Ý?åZ
=Ö ¢=x;Ñpšew²VìŸ{àÉÁë‘Ň;VÚp#I9kÕ™ü:¾½ÿ4ñ 	Œ`&¥a\èx
-·9¤Ä�wEÚ=��˜¿HÄÁSÖè	DîùØP�š@iAÖsF ¤U
—Äl×èØÞD_Afí¨þ“Û\¡eUx4Eœ:^�.en»æyõ-+×fKQ8aí[µÏSC²ìàä{•þÓ£S
-�âh=×OËîg
-ÈCAbþ[Z“ù€,Áršœ¦GoѶZc¿œ&î4ÆOÊÆ:‡‹…;ƒ
Œ«Õ‰¯�e
-ß‘O¶ýåHIôÆô‡P�/ë;mÓw�
-3wÜw�‹¾|1Ä0
­9ûðzŒCº¿´Q«i/}»£2ºPð:¶@PÄDº uæŒgb lË7ƒ !q—„»
L� ò8ã'1ùdóóñŽPxXte€ïÊSïêÏ'6MŽ?Íï.
-Ue4Yá«ÆYYG§2W™

cÄetÒTûf»o‚U–ûä÷ˇNþºmºÑž=áê	ÖÝæ.Mô3@[téÄå—±>*�zûl�Äì¢ÄL_ögW¿è©h�Ê#Ò·Ä
-oq†j"iü™6¢¯œã÷‹:ÿž5 ´�Â�…§g%ÖU@§š%ùym	Ô ‚įnHuQ:´ë¿cµ;/Âœ"LO›5çÊg!ŽP„ãWž¶íF;Ï^ý°ƒ*¦*Rõ|æ~cþ
-ðú2àM²kÎÝp%PÔ•�Ô¦=ŸUÚÉÏ¡›Ê¿?Êýõh«¯XB6“²²Žµm°0Üp§B�ÞÌ-žÄPŠô’ÉÍd~ý0½_LïfžúöíºÊ“Á¦4dî^jF��kK{hÿõgª\NFÓÆ�\{kg&K‚i€ôð0Ÿ~4´þ�“m)´š\¥û¥êo«QVÚ³ÚÕm“¬ª•}m°z÷°5=‡Œ�ÖŒÛÎHé: ±<XB“4úDÐv-@KU®Ö‰îÉíÂÊhX˜ånƒN? Úâ
-ے
ŽšqWÞ–Uûe&™-®RÕèW£$ÌŸ§O
+xÚ¥YÝoÛ8Ï_aà^ fù!RÒ½¥MÚdÛ:¹Úv¯ÛÅ–!²ä³äÙ¿~‡RmÚ^ààRä�3CÎ'i6 ðc©ˆJy:ˆÓˆHÊä`¶º ƒ%Ì}¾`3r Qõazñþ“ˆ)IWƒé¢G+!4IØ`:ÿ9ü@"r	èðz<™Ü|}¹ùãÓ÷ûo_¯>Ü|½1™$jxõðp3¾¾ûýrÄ%…%°€Òá·«ñ�«¯8öp™òáÕç›Éå¯éo7ÓN¸þZ²ÿ]üüEsØÇo”ˆ4‘ƒWø „¥)¬.")ˆŒ„p#åÅäâ?ÁÞ¬Y<F	ŠN„³
c$•’{G"S¢æH&oU½nŠf+‚‘8QbJ¤d,ÄšÁqs	‘‹ÄŒ)«Gˆ±�¢JK5¯š&Ÿ�žó·Å¦^•Ùc^^Ž¨a”iAß®;LÄ$J¢øêÅY¹¬7Eû´B¨Ï͈Ì-rT†¨Å$<±ä}HHH’()-êçh ÄIµ fVfM ÄS’$qjQ¿pŸ?G‹
+ß&µJÛˆÎé,Ø´08¹½ÒÆ(D<¼ž\½Ãñ1˜°èO&8ŸÀõ-¶šÃu±Ðv®
9ÇÑÛ¼,WY¥ùê:FàÌ;	§¶ÍMFцŠâbúÌúþ2ËšÜ9E“WMÑ‚ç·ŒƒIššeãºÕÈ8²•‚6³G´Ïšº§ö¾¤Û>Î
¶6 ÷<këÍBuô0¨ÕºÌWyeévŠ4cë�š�>©Ž,À=ÍêÕÈß2j(Îóù©mé  ·ÅðÐM(ضõ*k‹YV–o8Ô˜è©{hÉÐ=»`DE¶$ÇÜ?‚*DÄ2:íþ}Ôq÷ïP^•Òwÿ”0.ãý"¥/W*IL•<-—äòüžRˆÔñž`“u>+Œµî™­Øt×8´˜Œú±¹C»ä¢û‡ÉÅå�‡/'ÿbÌ…û—b–£_Ó�ˆR©8£�ê„>Êè£
+…cF »R£_7yј)Ñ$=-\‡
+HçGc×Ê}ñ|­¨Äž3tê×*×^¬[‡ƒ•Ÿ!CÚfŒ
uœVÒÆi˜2§[
+Ò1aqW^ûÕ££¡ÚL…ðc4�Í! Œ	Ækàúßûñ
Žh3À@™
ØR‘Lù‘"njaÀOm9¢‡4!¸û½4ÚŒ\I
¨ÛûÉa†´7ãéÝôœÝÉ
+æÇPØ@*b_²»jé§5'	—pM/Ç(Cwx—
+�:ÍS½--ú){É=6]´põ9Øín�cUm…2hÔ¬N±,�˜o±HÉÖæx¤¦{7¶±ß~ƒEÎ�š
ø‰ ðœ6ƒ>ê¸t(c‹`&U‰P{wjÏÀN•œË�byW5	õsÂ|±&¹)†ìåLw|­ÄÌÖºÏ1öÑ»I¼hå¥]eb{¹‹yHÊ7)­õXØp¯—W¦*‚žÃ-«â¯ HX†Ž˜€<”(ßé¿L¾ì²ø—ÜZ“biÍ>`Ô%¼ài
1
3‘H‘8–g’{uÂDʘÈÓ>Ke¼õK
+°ì«?f„­Ígù°)*Wtf¶
+}ª7­ínW«lóæS]éT¯Û¢®š½›-ÆååV—Ù®4«¯
<J	çÜ•‘»×†e^’6l2•‰˜ÇuÃ"BádÏ覇:¡‡2ºy>ª›S,wº9`ÔMŸåçJ¦ÌÝÐo$Ýó{Ä€ÃÚÅ((«<k-;z‚,�ÂN‰3'ØG?ÁeNp}¶tí?ÏKדÂíJ×Cé‚¥«'ÞŸ®XjŸ©à’»Æ×(ÉLÙ"TOšŠÈƒ/­¾æ8þ¼+d%³aª:1é™?«íê1·WôǼ}ÍÍ[LPWÃò3…¤®Nú�Ki2(µ±”3¸°,²mÙâ‡É‚Ð
+ÝPWrAÁêJ.˜»·ÆÝuÝ4Åci)u˜;
 endobj
-1808 0 obj <<
+1919 0 obj <<
 /Type /Page
-/Contents 1809 0 R
-/Resources 1807 0 R
+/Contents 1920 0 R
+/Resources 1918 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1789 0 R
+/Parent 1894 0 R
 >> endobj
-1810 0 obj <<
-/D [1808 0 R /XYZ 56.6929 794.5015 null]
+1921 0 obj <<
+/D [1919 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1811 0 obj <<
-/D [1808 0 R /XYZ 56.6929 635.5323 null]
+1922 0 obj <<
+/D [1919 0 R /XYZ 56.6929 748.122 null]
 >> endobj
-1812 0 obj <<
-/D [1808 0 R /XYZ 56.6929 476.3563 null]
+1923 0 obj <<
+/D [1919 0 R /XYZ 56.6929 665.5133 null]
 >> endobj
-1813 0 obj <<
-/D [1808 0 R /XYZ 56.6929 407.9215 null]
+1924 0 obj <<
+/D [1919 0 R /XYZ 56.6929 579.9397 null]
 >> endobj
-622 0 obj <<
-/D [1808 0 R /XYZ 56.6929 365.2162 null]
+1918 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F41 925 0 R /F53 1017 0 R /F23 726 0 R /F55 1025 0 R >>
+/ProcSet [ /PDF /Text ]
 >> endobj
-1814 0 obj <<
-/D [1808 0 R /XYZ 56.6929 326.9947 null]
+1927 0 obj <<
+/Length 2100      
+/Filter /FlateDecode
+>>
+stream
+xÚ­Y_“Ú8ŸOÁÃ=˜Ú³V²$[~$ÉÌnBr©Û«Ù<x@€k�Ía3©ÙO¿­Æ
Ùº›y°,·ZÝ­î_w2ÀðO‚#LS6HR†8&|°ØÞáÁ¾}¸#–&tDa—êÝüîç÷4¤(�£x0_ux	„… ƒùò9}ù2™Ž†ÇÁ;49ÆÁ§Ñôë裙û2L£`ôa2†$<"®ÈbŒ§³Ùä>üuòŸ“éðÛü—»É¼«+:ÁTÉôß»çox°
~¹Ãˆ·ÁwxÁˆ¤i4ØÞ1Ng”º™ânv÷¯–aç«^ê3§q%[Dd@J9�zÆà)ŠiDµ1@‹ÉÓHé;ŸŒ�ö ›¼ü&
+¤Ú�¼dµƒ‰I`Ü#vÚ&ÖåÒÌÐC>Øæ�rE’\€m½D!5 tÄXª•Ao9ú¢ïÍËÓ³Ø^
+çíŠ�ËK¾—9IC.I	ʾ‚=Ò—GÉ
qìúž<V÷(%pÜ1é÷|#}R¦(‰Zc¢Šal°�!uÒ�ËpÜ‘N½eꑨÊɼëúB
Œ×,*—Õ\³ÉËDå?5x‘†
0”{í
+j¼¢êð�ƒ?«ÒnßEEÄ2·;5P9hV*FÔWã�&ÿxœ†Æ\,F±€ ìyÊýǯãI›Î¹•�ðRuÑmÓ‚[á8vÁ}åÄ�kDÚœÔêÄp×¼¬ƒ›ê•õN.L±`>kx(–µª_ÔtZu «^^!êòêPÛurq
+xè±Tm<NO•Ø´£?ÚÑγQ
+QƈSg·¯šjá‚Às‚ñé>{Oˆ\sw	±‡2®Ú.å«_ø·Ö2­o2…ü Ë5”·\­åÙxx†T©o*ºîŃßïúgÒ2~½)l!_eñƒîW‘î°
Hy‚YŠÆ“ÙýÓã—ùã穧=¹’À=`§ˆGiÔw9ÓbÙfdoJDQ…®gªüÑYºýî*xËìò¥TÅOiÚ
5¨yš¼	ÈIÜ®(—'ß Ý1u×Cyðؘ)UâêàrÒ÷2+êªMÓ&€úäÞçPÛo®ÃÂÁ|öøáØ·)V¾\g‹c˜AÁ“5VíºUîz¨§.¶êb§Öe”jŸõÏÎÚz›/DŠ"JèõœÒ!rW›ç)Åi”véƒ÷ÒJDÊ}Ù£×û³ÅQr]´–è\¶^bÐ(!xO¸™, QVfÌvo0XìßvMµÞg»�î)aªs)ý‰Ð=|àÁ+Ô�$8Ø·jåP@ì”ÆÄŸ+û½F²µ¨³=Ô�ÙþÅJ¦[+=X™
Ÿf£Ocn›j(D”Ò¾÷*¯*åUæžVûªÐKg#íj)Ƴ‘¾ÇeÁâ‘ö?ê)GÁƒñƒy*Öã|¥ÜVw7föAÅ6+�Ãr·ãçÑ}â»4-'q]š°éÁ]•fG0€†+s$ª-ë¼É_/ß|ª+{�Ïà6Fþç_Ž÷]�1¨è\ìõ¯’0°4%N(¥1!ôTôö7„sÙÿ(l7wendstream
+endobj
+1926 0 obj <<
+/Type /Page
+/Contents 1927 0 R
+/Resources 1925 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1894 0 R
 >> endobj
-1815 0 obj <<
-/D [1808 0 R /XYZ 56.6929 293.3376 null]
+1928 0 obj <<
+/D [1926 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1816 0 obj <<
-/D [1808 0 R /XYZ 56.6929 221.9809 null]
+1929 0 obj <<
+/D [1926 0 R /XYZ 85.0394 752.0811 null]
 >> endobj
-1817 0 obj <<
-/D [1808 0 R /XYZ 56.6929 108.6903 null]
+1930 0 obj <<
+/D [1926 0 R /XYZ 85.0394 529.0618 null]
 >> endobj
-1807 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F48 885 0 R /F47 879 0 R /F53 962 0 R >>
+1931 0 obj <<
+/D [1926 0 R /XYZ 85.0394 453.6936 null]
+>> endobj
+658 0 obj <<
+/D [1926 0 R /XYZ 85.0394 414.4777 null]
+>> endobj
+1932 0 obj <<
+/D [1926 0 R /XYZ 85.0394 377.7886 null]
+>> endobj
+1933 0 obj <<
+/D [1926 0 R /XYZ 85.0394 345.6639 null]
+>> endobj
+1934 0 obj <<
+/D [1926 0 R /XYZ 85.0394 279.329 null]
+>> endobj
+1935 0 obj <<
+/D [1926 0 R /XYZ 85.0394 194.9705 null]
+>> endobj
+1936 0 obj <<
+/D [1926 0 R /XYZ 85.0394 119.6023 null]
+>> endobj
+1925 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R /F14 729 0 R /F39 885 0 R /F53 1017 0 R /F55 1025 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1820 0 obj <<
-/Length 3191      
+1939 0 obj <<
+/Length 2835      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥Z[wÛ6~÷¯ð#}Z±¸’D÷)mÜ4mâdk·»Ý¦´DÛl$Ò©8Þ_¿3˜
o¢¤œ³öƒÀÁ
-iÏ—›3q~}¯Î$ó,ÓbÈõÝÍÙ7?èôÜÅ.QÉùÍÝ`®,Y&ÏoVD/Þ¿¿¼zùúßeEô]|±°BDo_\ýúâ
ÑÞ_8½xuy}±�Y*S`2È–ˆèåÕõõå÷‹ëׯ®þóîêòâÏ›ŸÎ.o:Á†ÂK¡Qª¿ÏþøSœ¯`?�‰X»Ìž?Áƒˆ¥sê|sf¬Ž­Ñ:PÖg×gÿì&ôú¡sÊ°:‹m¦Òm(y.eì¬U#uX'Zi¯Žwïo^¿»ºÞÛ‰ˆ…�¥JÄN¥jÞÌ´r……g̸pÝE>]ÒéXëL_20Í,©K‚Áµtv¼äoRʨؖwÏdè|½¦Æ}QÛ¼-VôØ”÷UÞî¶2‹Š&>¤›$sq& qT7C®Ãºé¸¼n–¸ä7?X;à”"Vl+<Ër�7ÍT0©l,m–—¬ãšm¨C©Á%��cÙ®‹eùAU4¤¬ö¡ Ä5H6߬ï&Lÿ­«â°BmÃb§:à:¢ÐÀåúqN¡2ΜլÐ�Åóž:¥‰³$µÇåê¸f©S‚
g(ÙÍ…9ZÞ^,´’QÓixEÍ7ò†Gtåýµ¬î'Ü@¬·9¯ž'ý°„ÎïD6¥£›‡’g¯Û²®¨½Éy‰Ûb_8Pdì„ÊP
Œ3°©ÍnÝ–�k6y[nŽ‘´q"�;aó
×›.oóõŒÍ]ÞŸ²ÉWõ&/«=«ƒÛ-’ã’u\3¢�ƒdÓ�e{Åx
-JšS%6zùÏ�߈Ö-QA@bZ­J²RÛš¨WÐðVÅžÂ
-ˆÄŸ/‡–ä±ÕŠ—¸îfG»k‹v/¨�µáûÑ�–?>Õ*˜pC$Ö�mí%Fx•oŠÁO~¾¬ýïê°OØTÁ©'Òã>1ä:ì—÷‰ÕIX•ÛbÙÖÛ}4°"Ná$>*\`šnäÖÆ©4z,Ý›ºþHŠºyAµŒ2€Ç©ëñ
-}Äs�æ†l@ÛD2†ê:@59ûdV-ã<tnû“™m«,äSü‡¡dß9íu¦526J&'L;à:bÚÀåM{?“Od.9±d`šYr’Odi:YrÅxü]Ï:yoP:Êõª?
-C·g®7ôĦõm¶«Ñåç²i=¤Ÿ\ñ©ÉÍí(ú6õ§bu8ò ËÐBÙæp1OàòæiN¦4M›oÛžû¡Sš$=.^Ç5#ß(ø؇n¶Ëk|b(¬BcEæš1ûÊ
w>=Õˆ_�I ÿòT
-ÔÜ7o�°á¡Ÿòu	†Y(gù0FŽe^Va
-îÝKÈèEEÌá†ìÒóRË˧ðxZ•Ĥ=åö™×§Ÿj·¹
¢•<ÿïð÷öíË…ß‘Ÿ'/üñíÛëkô÷4ªê6ÇCïxVÉH	ø³ ©1P³!¨²
-<²‰èw<
bÍ9©†-&&ù'µ.NS›1+{¤Ñ
-S|=R�‰
-’Uc3�®è±G 
PÅ…sÈA×�Æ¿)ס¾œ€¬´/ì®'“�Ã>L0ƒ�¾â4j¸;m$ï;ªúé««˜ÚnØ;n*n&Φ^#c8Šì
-Yw9ÔαK[é§>qA2ä:Œ]—Ç®»Ùb9ÉtÐT½kwíâ®\ï£$T&Môqñ:®ùÆé™��MÓ±€¾LÕ2‰ªÿ!£
4˜†…&þ’M IX"úºç…Xh¡Î¥{`mÃÄx‰â�Dº¥‚\+ífÛƒ·/®XÓ3Ês€–¤±4P9�cF)¥b¨¤åØú,Á¡’Nñ{wYùÍöå–à‡}H¸X›ìÄ…Ë�ëˆ.ïC{ø¸1'–L3KŽ*0Î`'K¾ß–Uˇ~ÎÁC½ee4»Í&ß>¸Œ k®0¸â¢,÷A~¿ÛÝÄ-ÎHÊ8ÀÕ]%U
Àì-ˆ¾3cÃÔĉs#?˜³ŽJ3˜×�ÈN†\‡­Óqy딧®Ã@•Åª�ýä|4¶£²u\3Â�““Ú©K÷¯.ÓÈéç‘N�Oe½kÖÏ‹œØåì[%'�yÓ„Þœi>(ðlj>5ñW›Ø¸-†	­ÄÙ
-ÿLLƒí�2fFo“Í.t»5 óQ ‡ÖqRÝL3ýçå:”a	ÿ”3gÎS€kƒäwtg0©\„g5Méæ‹jaÒ]V£:k_Y¨®²ÈižP×e¬Û¹¦Ï
Qîàû®õar!h„Íf²Û,/ƒ½·LæÑ4b¸7“�ºçV¿OeS»iÊUA#W¼rM¿·¼ª—’®Và©©ëÊOæ<4Ìå.íñ{–Çu¾ä*Ä…PK´ëÏ2	‰Rw¤H§‚�Þ›Û?5ÄÀn¯£¿w�q ñ
q
{ÛnÒ’Ü�·[-™~[´OEÙ€{ôª‹H*T]vˆÍþ2ª�k%
âÞÑrÅ—ûñc- …Ô_�«	<B†?{'Š¸/.jCÈæa¿(ð´¬� ©O[Œür Oc­º´)ÔK
¯5z³îðó–Ëi	…›R“rºV§tK„Í„ëa aªŠLUÑi�sâ	ñ”
˜@‡?�
-…<põ	:*¯-ýjØäJæ_+á°¢¿šr
+xÚ¥Z_sã6ϧð£3³VHJ”ÄÞSº›Ý¤’½Ú�¹^ÛÅ–ÍÊ’kÉIÓO 
J¤-Ë7;;¤È
@€Ÿ0øÇ'2b%Ô$QQ —“åöŠM60÷åŠffA3õýâêæs˜LT bOk‡V°4å“Åê÷é÷�®�›~zœÏï>Î~¼ûíËÝãõŒ«Tªéíׯw�Ÿþs=’
 ŒM¾}üõö'ûz­ÄôöËÝüúÏÅWw‹N,WtÎB-Ó_W¿ÿÉ&+ØÁW,�Ãä
>XÀ•“íU$Ã@FahGÊ«ùÕ¿;‚άY:¨
+ÎÆb@"tt‘ò@*%'‰TA”ÖÅcÝæ°©DMùw׳0VÓö%kqd]ﱃjú
+#;P\å+8Ÿ�³ég#,Îbþðåvï¾ý8ûù“Ä/CÚ^HÎù4°”…X+W+
+¿ß`;Épà¥Æ(Ó‰ÐóöÙ¯ó»_ôf…»sä
+
r��¸Æט[$Äý?œ°Ÿ÷.§^-
‚49v�
4ÄSüXfRTM^
&
Mѯ¹
Wù:ƒèA1À¤+ÐÒiCom“
+û›lîúº:ëø =})Œû½:ïöd¼~9äõ:ùƒ”ÍxYÂIK¥b !¢Q©,æT*Ïݯ ÃvÅz¨V�÷´æD¢Ðæ�¦—c´§;¢ËçL»ÂÉe]µYQÕæhtš—úPú%{Í=œ˜6]´±µô	³tú°Æ±ª&¡-c&tÎqß@�e�¨OÓ}xôÓH¼âÏ
+.á0d[ó‰Ò(×´ÈR4à[¹%vwûb›cwmä©·¸ø—ÏqXÈPaï­(Kì=Ó×^¬‰^Ý4Ås™ÿK{„:?|+ÂkWHœV˜Zøw†8k¾aœŠEŠ~uÞ|;”1ß—“#˜J.°´ 
–®IBÐbIzÄò뾨lNE
®ð=é¢9l·Ùž|ÞÖgÝI½Ó‰UsTnÑuqÐoH}²†9½—ýG
+LJ$ä—«ªiòål¬i €M*™ÚÜéüÙè?Ž¦�œ�ÌÁ|;{0#üús9æ7x,¿/èP¤ç.›õ>)pX™£±½›-;«;¡T�^(€{ÌyÍÆ(nw±øÝíë¶^ÖåÙâwD¬¾ô=–k°ðuƒ[Û¼)z+:™øƒÂ˜)*`õ¤©.<8=€¸rŸ±$�Yœ§Šáƒ!|v/fÂyÇÐŒ`àXXº*ÈçYâ‡`!¥ÉžéáLîD3ø0ÑÚP7Ì–kPìÚr
æžÈ€ kÃ'~uÅ›U€ÄÛF÷\OwGhuy­Ùc™©%©°5�]w °KZF[<*ÿ
+?šÃr™CÕº±ÝŠä’õ:¨ûµ(cÁûKYçį·«üõ4£€š%‰’qá:Ô€t¾Ë€ËؗΈeöå“A¥UÌa˜'T†Ù¤nQÚ*7UWKÌIú•€Üõ¹‰&ôg¸Å©Umù˜MO“}¿+Zž
¼ô„`¥\	ëò7 ¬kÔi�DiêŸ<
+9p€°0±wú$Ü_‡lÕ˜¡ö _,s�s„Ò¾«Þ/ôO=<¥få¨Ç‹¦sïç:³µ°™©v¬‚Ž7BÆÇX:dGÛ�%¢tÒ{÷ðO5²gš72ÂóÄÔšåK¶Ï–­	$€C
r�­&XÒ˜[Èk<)ÜÌ­²–ˆêGÝ>wJ·`¤¨À(²•/ÊxvEÏ8›=˜Mf%~`¤=Õ¥þùAòî‰�Na5üDrn-¬pÞ9ð^l»b×9G“ïésì2|¼pž–GŸx"�Çœs>âÆÄ›æâÃQÓîójÓ¾œÞ˜øh}D¬s"—ÿ«Ü5"Ž\ÁŽB�ýÍ: �	ûF&3b/NF?ݸh÷÷žØþÞ3H¥ F6ÝEÉÜ‹>ÁLí.µëóй:Ó
+2å{Ùò°'Ž­ýð%#ƒ©èyq•ëW9Åî°‡2·†Ó¥ZpŸž·¨Y,.</¹¨;±(c)íàÍ÷„��C¿)¤údS5.–
ˆå½‡€-éŸÎ=±Ü'Fa«¸äñ]IPÑϸ1
 endobj
-1819 0 obj <<
+1938 0 obj <<
 /Type /Page
-/Contents 1820 0 R
-/Resources 1818 0 R
+/Contents 1939 0 R
+/Resources 1937 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1789 0 R
+/Parent 1894 0 R
 >> endobj
-1821 0 obj <<
-/D [1819 0 R /XYZ 85.0394 794.5015 null]
+1940 0 obj <<
+/D [1938 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1822 0 obj <<
-/D [1819 0 R /XYZ 85.0394 751.8312 null]
+1937 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F55 1025 0 R /F41 925 0 R >>
+/ProcSet [ /PDF /Text ]
 >> endobj
-1818 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F55 970 0 R /F39 863 0 R >>
+1943 0 obj <<
+/Length 2184      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥YM{Û¸¾ûWèЃüd‰
½ÉŽ’x+i¤<Ý6ñ�a‹»©){½¿¾ (	½­} gï|Sd„៌C˜ÊhË1LØh¹¾À£Gxöþ‚XšÀ]ª«ÅÅßßÑx$‘ä!-:¼ÂB�Ñ"ý>ž|ù2�½½ùå2_¡Ë€a<¾�̾M>™½/—2OÞOç—
1‰�ˆk2ŽÇogóùô:˜ß¼Ÿýçólzy·øùbºhë*O0ÕZý~ñý�R8ÃÏQ)Øèn0"R†£õEÄ(b¥n'¿˜_ü³eØyÚ¼êƒQ�˜c!‚$cá
L"NCÚÀñ~:›~�è/¦oÍù?Nÿ=×'ƒ÷iM<‚§($Òàø¯•*,éP…Â8Pk¢´¨*µ~S/�-u—'—(Ž¨%^–ëM®jU�±W»åRUÕÃ.Ï_.	!ãŸ`_Äã¬ÖW<Þl³¢¶´‰ÙªjØ{4[åƒÙ«WÊl<”ÛµQ!:P˜bXKb•øXÀz“$É›Lÿy”oŠB&íuiØk9@;
+¢P �Q>
+Zì�¬ª“"M¶—DŒSs¹«7»‹<^¬²Êl»kRØûTuöãp™ÔYiwÛ“Âf樰
+`‘¬U/T\pˆ‡(:U—ªª–jª³R÷P�ˆõBu œÞ‡w
{ *vkµÍ–æ¦ñoµ1—
+·ã²M@vßLòÇr›Õ«u?À·5ÎÜ¡:°£øœÔÀÇbý
+—ÊÝãêLÞÒ¨ø³‡yìŽÖ°ý}49¸ý¾htÆ°eM›®µ™þ2¹ýòi:<,ôL¡{cJx—D$×°Pf?1—˜‹à¾iU)ŒXó‰Ù5ÊR×ßÂŽ9)ì¤åbÅš]˜�èHtÍŠú#Ñ#‚ÉÂ7|À©XÛØhŒ]=ÒÂÊ</ŸM“
"�ÅÚ€
+ÏžË]žšý{K¾¾Sé?<:!çH„°w¦ì†Ð 1ׂfãÞ\
 »a)›á³Y�?¢'{5&ߟnÜi˜�©¬‹œ'œ©|G>û±£$zƒ1}rÂñ°¾7Mµ`._áÈ÷'OwGÐÑSòúÉÆíØÛÕ4•è2ÂiŠ�܈‰t¹ªçŒ=)ŒpPºª³9
+¶Äm-n˜\A¥�9îh„Ÿi=(ä=Ì]%ò~ÐÙ`{>µÕròiþy8XCTÙc¡«¹®ÝB—WkB*»l’9¥®nfö‹„´ÓuVdà‘IízÞ¯êAÛKë”·I±ƒšäsÎyð§
+@'Ú:þõݵáÓ¼ôð‹ 8jüev"bÿ;»è˜8=dç70•‰ˆÄ~òmñáó×aÃÞ@»¾-”Mó—
+Z'Û»^C«Qnël·Þ‹…ÊqWP"h[¥Я‡²€!—¹Šë(œÞmˆg0Lô¨&à\±×ç쨆±Y™¯xf½®©ÛTW—e>\ç/E¹©²êx”„Ð#’�SǘžIRGwÈ´5½Ã-t”L4ѽgq:eº¸¥òž^׉ïArçVKs2v8‹HÑý˜—'•/é…	»œÔrL=
'Á™Ë�ЯC¯^n_<LY„xغjËT
2UEÔÙÚ×’G1Ô\ó|ðð(ø“q|˜KÍ÷¹à!Ë}ü›‡–ÿc»Zµ«ß<2!ðxÔÆr[$ó¿
+…asœ
r¬Ê$€q5Kò~m	t œˆ“)¹ÃœðøW¬öÙ‹0£�Ž'6çʽÇ�=ĉ§mÚÕÖ#ë0¶ÐÔëT=õÄ7f'€WÀ×ɶî‹p
PÜ6-׺]=õ*íøç0Qå¯ÏrÞÙÞKH(fòhNûP�À�"I°C©JòÚû„&¢Çò>Çe­‡R˜6«×4±+]šäfö!!„îú>Å‚\ý;”§Vá¶>þß?wí¿éBV¡Bì¿ó~.m¾ïCb•ÒÇ#„«Þþ0vªû
<¥ø¾endstream
+endobj
+1942 0 obj <<
+/Type /Page
+/Contents 1943 0 R
+/Resources 1941 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1952 0 R
+>> endobj
+1944 0 obj <<
+/D [1942 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+1945 0 obj <<
+/D [1942 0 R /XYZ 85.0394 752.3199 null]
+>> endobj
+1946 0 obj <<
+/D [1942 0 R /XYZ 85.0394 504.8188 null]
+>> endobj
+1947 0 obj <<
+/D [1942 0 R /XYZ 85.0394 359.3246 null]
+>> endobj
+1948 0 obj <<
+/D [1942 0 R /XYZ 85.0394 298.3625 null]
+>> endobj
+662 0 obj <<
+/D [1942 0 R /XYZ 85.0394 260.8495 null]
+>> endobj
+1949 0 obj <<
+/D [1942 0 R /XYZ 85.0394 224.9084 null]
+>> endobj
+1950 0 obj <<
+/D [1942 0 R /XYZ 85.0394 193.5316 null]
+>> endobj
+1951 0 obj <<
+/D [1942 0 R /XYZ 85.0394 129.6476 null]
+>> endobj
+1941 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R /F14 729 0 R /F48 940 0 R /F39 885 0 R /F53 1017 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1825 0 obj <<
-/Length 2975      
-/Filter /FlateDecode
->>
-stream
-xÚ¥ZÝsÛ6÷_¡·ÊÓÁI
-3wÅ·<Lö�º¸/Óæx¸f鎵X™˜›„`6†RšÝäD‹üxå›ÇšZõž iV”÷ÔU”kêÛåe“n=®·©ë¢ö}^懔x‚½Õ#ž<ìÇ}3L&I컬Ùå¶Ø䈧_�22Ët[WÔÛøo]\þµ
©}t (šš~?¦Û"K›êPûuÊÌOÏ@¢GÝ=ûÎ
 «:ú•×éšÔÇ�cÈ`wtÇVµ,*œ‚…Š
õlS·î½c™\–ÇÝí
cÕ†:?†kêû²ªü®¡î¾øÔ2mèëô
-ε=Ð(´d‘0vžÈ5BeOÌZ³äÙ'Ø*âzyóñ
-É’H¢Î jl#ïÅÉt?QòømÂhÈQN¸Æ7+ˆ]ðûU]wÛ¼]V¨éGzò4Ž®,øΓ¾ÿ�2ú+Ï÷øs§àÈ-œ�¸û�¹W5hŠW#»DÜ4¼]=”óN[Ć)Ó
--ÿùªÂ2kÕYõX_ѼL-Ê™…HËO8ÓT
Ú%Œ\ÀÙ€ÜÈŽ*A
-駎fØ–p¦¹’/°­ƒša[@MêK�w
-.œ±É<	-j„†ï@[#ÍmŸˆwÝ�êp̵�uš}þñjk¤÷›‡¢yØA𴮧™«8/’˜ÛAÍ07 ¦®MŸ·¢vÍSТFHèñ–d û4Üäÿ˜£!igt«M˜
OÂdP!�Í÷ÕúaÒQA>Å$0jÞQuQÓŽªE9GU�‡ *Òmjr(î‹òL7X›yÒZÔmý(Ä0¹dŸ¸ÛÀÈo.Ppltĸp˜/ßm¶ã”9e¯†²hc½ ‰æ|uœºõíÂË(­ëãng†0¶]#Ð5!?¸»Œ+#çå×EM˯E9ù}|)Ѐ„cl¦‚ŒÈà‰ç	lQ#ö¤¹7Ü$Ó'ÑIQiîÝ?¶…ŽÚ3D&µƒ·¥I‹²€èÍvµsBÐ�mt$0~
-:N»Ö4u&èÐwsut4�N8oiDã1‡×žÑ(!¶LÛÓDXü�>Mí¡™@C: ´8“ˆè
ë f4, œ†í‡[&	ãV¿°e
-U×ëì$Mé±°!Љ=¾úUSÿ_ùó]Eúžù‘|;¬r©¤S�Áq@ä3
-½\÷øýb,ö…+Q`É3ruZø¬ÒCº¦R-àˆy oëáî=	YµæǼµã¾¤ß;¿»/ìBOQ‚R¤YŸ”fX[¤«ëùîã§6¾r‡LOU¶ãX][ˆ˜Å"žÈK!Ïid…X”Y±N›¼në{>ZëË‘jÄ.p$=TÇmÖ�¶ðÌÓV‡k–Dò…«‹š±:
å¬ÎYÔ”(¦¤¶ó[ÐÈ–]^%†)nUËO‡"$tu÷¿Æ<¬_Ð\W»ý6G¿1ɉ5ÉãyŽtQÓiQŽ#�/&
Ûü1ßžÕ-5–\ä<a
4BX?c��Y@æØ£²¶z™gùÝñþ¾ÍuaÓ,‹ ڲ慂`5ò€r,ûv¦D³V˜ù-hdËžAS+ÑßòÝ}YuVÞß¼o³•zv„ª;ÜEjø0Á1LØÎ&
-ÊÒ A¦y) J¿p!»¨^ƒo@‡
-&Y’h;¿u
-
e nYÝ_Ö“ëT=]èO�bžÁƒ]
-×Ä‘«8½RHiñ±üýõ¿©“HXÓ}tÕ
-¿öˆÖšÑX
9ø*øå�fCbDk7•ùGÅuSž/…ËS
æ4¹öÓ=[®�ZÄ?G€NÖæÏ-Ï7hÁú'¨'LJM_ÿvõë§_®G"8„ì�Ã%�kœà“Òv[=7 þ§º#&Âî_S³	ý‘”;$oŸP
À%³õh´Œ~Þ$
4²Ø¢y Í›@ÔÛ›+j�Q††
§ãóòÈËú
-c­ß!+kÈ_W°L
wáŽÆ&¼–aã}ç$ì{pß
ž‹˜OCN%C7å;Œ�j!K}ö?vǺ!È�‡¢áHæî(wí6
+1955 0 obj <<
+/Length 3093      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥MwãÆíî_¡#ý±óIrÒ““u7N²Þmì¤M“h‰²ùV"‘ZÇùõŠ¤(i_k8Ä`|c(9ð/g6‰§Ü,u&¶BÚÙbs!f�0÷öB2Î< ÍûX_ß_üí:�¹Ø%*™Ý¯z{e±È29»_þ}'ñ%ì ¢7·ww×ßÌïnÞÞþçýíõå\f©L£«®oßÜüûr®¬
+X¸%œ6ð³x*×Kævhš“ÜüYE8$ùƒ?
+|J§±RÖú�ß{ç8ôu§R&³D›8ÂñMBš÷±‚kªéÎó1IŒs2;M2 M�ìK/�aªå�äÏ—«Ø–+Ök¾^Ó 8)Ë
Ìœ••�
+¨…­€6«�~.Jî’F{~>4õzçÙW–:ØXCŸö© žÍKÈèª"äþRCzÙãÒÈó§0?-Kè|f€øvIQZƒGµÛ<ÖJÞÿø{÷îÍ|تQn|óí·ïÞÝÝ¡½§ØŸùŽòïÔM+
à‡Ò+¢€(@B?B|i¾2ö«0õÓ=pö
�}Eï|E
+|`ÑO¼@Àš²Q­¡\6Éç©uqº¿Aa‹4Za‰¯‡>êC"Ä�^\³ª³FɆ#ž%/ãpÕE&„…Èä³Å¸�Ðý–£8‹äjÆyb”W+÷Vž1gŒ9MÒóTÄAÅqhÐ-½îƒ
+Àúwr!m
8°âºt`Œð‡r]Ðw]ò¸ô-(œt<ĪG{½?ì3A}ãiTÿ�ÚH>$NTõË·1�1Äáìdˆ“FÇ*Ù„»��º1el/Âáæƒ7×Ð	iA3Ëü•qöD6üiýR’ ‡yyùñH4—3$'s•ÎÄ&ƒöp �e±Ê¡…>ÂT*¡HÏôG}¬ã!¬Ãò!l5Ù3'™YïÚç];_•ëà æ]ϹÓìuXü
‹´4–Rª!ƒ¾[Õ2á.=»L„�&àY$`¸0E8xA.݈À{ö
+Ò8þ«»
+ZDh£åPçÌın.´gívYùÃî[”ÌqËQYœ@|<c9=¬–°¼å<t_I,\z†d@š 9è¾À �I~Ø–UÛ„+v*žê-£Ùm6ùöõÈMÝq…Å7dô
áq·)º�Ûz⃑‚¼ª”êî‘Î02 2gúv0¥‰ŸðœÒ§µÓÇ:®�Ëk§<w¢,¶Ð�V&��µÓ§yë°&˜8µý)‘¹ûWWfäôàï+ŸÊz׬_çÁ?qŠ>á¨äJâ9oš0›3Ì;&F¡¦ë¯‰ƒ‡¢_½%.UÐù'|tï”1rv®³$vd>pôp½:¬¨›q•ÿºX‡¶"�ðo9c漘6p¾¢û‚Q×€Ý œ4žlh„wY
z¬ª}W¡º®"§}BO�¡l§
+˜}
ˆ|g�
+å×É”ÜC:ž‘’OÈ7ç
+mŸÂæ ù
YÈ°ÒÎb) ®<Å\‡tÈ�µL"˲
{÷¡–fú06\hÛ}¡Í¥'ÎQZF ¡¾~6чºiÊ*À
oÖpѼ·‚ƒê*Áï£Ý÷èÓÚâÏŸ.§@jÝý
+æ1¬t+ä)…Ú|èÚØUhÓ#²Í_ŽÑÀV$Sã2>�â~ä¯|oëì>Í;Ø󶄚´\¿2œÑ]óoÔ?'d�ðN=#ŽÈÙa°|…â¾\ÐËþg4vÿ#
 endobj
-1824 0 obj <<
+1954 0 obj <<
 /Type /Page
-/Contents 1825 0 R
-/Resources 1823 0 R
+/Contents 1955 0 R
+/Resources 1953 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1789 0 R
+/Parent 1952 0 R
 >> endobj
-1826 0 obj <<
-/D [1824 0 R /XYZ 56.6929 794.5015 null]
+1956 0 obj <<
+/D [1954 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1827 0 obj <<
-/D [1824 0 R /XYZ 56.6929 119.3275 null]
+1957 0 obj <<
+/D [1954 0 R /XYZ 56.6929 752.112 null]
 >> endobj
-1823 0 obj <<
-/Font << /F37 747 0 R /F23 682 0 R /F39 863 0 R /F21 658 0 R /F55 970 0 R /F48 885 0 R >>
+1958 0 obj <<
+/D [1954 0 R /XYZ 56.6929 665.106 null]
+>> endobj
+1953 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R /F55 1025 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1830 0 obj <<
-/Length 1542      
+1961 0 obj <<
+/Length 2978      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥Xm“šHþî¯ðËUi%Læøh\7Ù$ëýÀ**	 ‰ùõ×038š½ºÚª†¦»çé§_ÒÇðGúž@˜ù¼ïú	LD±íáþž½ë-ã!§)õvÞ{sÍܾ�|Ie¾jèòö<ÒŸ/¿F÷÷“éÕÍßC‡
-<x‹†ŽÀxp;š~}Rk÷CŸFï&³¡C\É8‰RLâÁtt;¹rÆï'ã�ã»éõðqþ¡7™×Ž5�'˜•^ýÓûòˆûKØÇFÌ÷DÿÜ`D|Ÿö·=.œ1³÷f½?k…�§Õ«60ó�ð¨kC÷¡!|$e	Û_&y.œ<Z'¿Ò$T‹ÎZÿ¦ê7ülŸã-Ò­~ë	�¬}%Œ—°€o!È‚V†>6$Ñ+ŒÙ+âRîÚDÛjQéT¸lí<,¾¹†­wYŠxHz®¨DnÓb–d<¥û!è;mçµVDŠ|âqPXùÔ
èÔ°ëB
-J~‘
‰7ƒ"Ì[
-�gAè˜%T A}¦_ž2BóM”·ÌU×ù&ÝÅKµó§Ê…¾Ã¤‹0a¤åý*T¿É"\*
‘†3P?Š+•ê¶º
“¢+wºO"€ˆ¾ô´ÇI°
—°ÇdeÙ�¤ˆJ)´¨ÚRŽSâ"&!5Zñ6¯C[ÞP½Ÿ*|úq <«'û(ÝåñA=ÒXW×f‡tð#*6jm®‚]\hA(Â,¯ çà�æÖsí
%ö=<ÃÊ¢Zò|·í’[… H„OaÒšH‹]¦Ã£A_Fê~Q¤ÙaH€È'At
X<ÛRÚÐΖí—/“Kš¿ ÐV= ýzµÚ/s¡à	Uðf“‰Bkôivg¯T"e´™÷¾u˜|…eþ]/x«Ùı)oo¦WÊŒ¯­-·QåE@pÔÒC3¿ÔÒm�ì‚Ø–åÒ+Ajõ6ûù1eàáz¬4r̘E'ˆrAê¢aÁÍ¡¾@žï¶á}ž¿¿{ø=n7	¤DjfÎ9T]‘Æi’§Yí¶G³1.M¸8E®•·	èÂxRÕ	g±	ßM±¨b+�+…[	OAäŒk~©òXozT•¤ÔUWÕc�`iRVœõ‚¥‰¥ž’"ø©…K…Q²ÖIš¦ñKÈxHÒç*VgŽ�00hCkg
-DœcÙvÿCÅѱ]ÃŒ©”è„?£âl
+xÚ¥ZK“Û6¾Ï¯Ðm9U�AGÇv¼N6c¯gRÙÚ8J¤FL$R©�ýv£
Š HªR[:l|
+)˜J¹?íÚ¬*êSÓ³T�6„ õ`¬Ý?�Œ¡¥¬Ö4Ù¾€s²ƒñ†Lç
+°Híð�ªhzÊv%”úØØyªÜ/ŽÀ¢E­^,q  CÃÆ:[oG
ÌØl݈Uºó•¢ì23ªÓ~EkCŸ	N@4ŽÊÒòºúGKd_}’|<Ég
+Ò‚C'­_¨Ö8SÃÀ*â0
+;Q©œÞ|úeZ³
+2Û4ÕW4ÛCÍhÖ¡ŒfïÆ4‹‰·K™š:[‚Ï(³ÝÒ¦¯caƒ!Ì2Ù¡F¸ì+Y0&QûlšÔ6bIpÿñ56â€X"¢Ó4¶]Š�Ô:ÒZ7Ú%؉	
¨<�ÜàSÝ4åjWôghè%;‡™�8—‚Ãt°ï6¾ýY|ŽÅR¨-4sgæSÌš4ùw#«Dbtê‚/ΊáÉ„¦‰%TÊ´ÓºýËY!I•ÈÞ¬§ªüŠ¾ejRjº 
fÊYÐ(
\B
5^cu¨evi¨®ÆêPc‚õ–)±HÅW–w¨‘å=7%!±ö×[»Z§sÔy¹:jcžT&‘yš!dž�*N.J¨<Á¼àú°iÁu¨I›ñxˆÁ�e|…áÀ“]”'‘χ~Fõ7$fÚ§¦ËÌ>ÿð†\§Â†Í#ÔK{È�ÖÍŒp#j®ô5áö`3Âu¨©£ãËä¡¢ô
+5‚']R‚ðy¸/þ¶L]Ò�èwÖ72žÜåÉ`B[êõv2RE\„Qþ{6RõQÓ‘ªC™HU�ç 2êY},Ë겺!$�bžµ5›Ÿ„$PÔKå3÷àiY£aÆäÃŒ
+Þ¾÷8—NùwC]tÉžÓD{9{wå¤lÉŒg
*úý0Ñtyl7‡ãkB2å üDÎë¯�šÖ_‡2úûx-Ó€Šêí‰,ƒ'�$ÂØYþh„?O‡ÐçHúÊ„u)„L8%Ž‰«¶¡ALRÛ)
�ö:ï–Æ]!©ãÒlÛ´#†þsÚq^µ¡¡3iG‚i7¤^¯'·Р7>žuXÛÍ”†
+ˆ4†¤&M‚–xóÁ¢s-Ã-¿™åve·Dq)hHqþÝ&B…ªùÁGÓÎr*g9ȇWgKkZÉ7I÷YÐYdwÈ­ˆ�gDOÿK"
çó+’8ƒfþ#aAÆ"ÿy­
+‡”™>ê]~ÍQi¨…³¬u KÞü«,Ð#“±Çܯ“âËÆ…×Éß	Ù©hŸU/.Rwû&]n×W.g,œúGähÑxFÎΈþï+�ÿ—%¡LÓ‰ ¹8\ÍS(?Γ!ëÝÿš.yÿgH,endstream
 endobj
-1829 0 obj <<
+1960 0 obj <<
 /Type /Page
-/Contents 1830 0 R
-/Resources 1828 0 R
+/Contents 1961 0 R
+/Resources 1959 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1839 0 R
+/Parent 1952 0 R
 >> endobj
-1831 0 obj <<
-/D [1829 0 R /XYZ 85.0394 794.5015 null]
+1962 0 obj <<
+/D [1960 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1832 0 obj <<
-/D [1829 0 R /XYZ 85.0394 562.7154 null]
+1959 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F21 702 0 R /F55 1025 0 R /F41 925 0 R /F53 1017 0 R >>
+/ProcSet [ /PDF /Text ]
 >> endobj
-1833 0 obj <<
-/D [1829 0 R /XYZ 85.0394 499.03 null]
+1965 0 obj <<
+/Length 1813      
+/Filter /FlateDecode
+>>
+stream
+xÚ¥XKsÛ6¾ëWðÒ©4	Q¼ˆÇQ±•ÄMb»‘2M'É�–(‹�Dº&åDùõ]
+‰¤ ,ê
+¨ôL
•¬£RR$9�=•n²b3ªÇ·Y‘ݧu^ÜÚ÷Ô>.ç³3fÉå&Ís•Õ–¨7™%®®¢ÆWïöý#Æ,u¢J·+ÝnBïÍ®lY6ÏUå‹•%V¥}eݳ23@E
+©DF1!H'	müq’Mô$›Å5¼6D^TÙroyìÊ*Ûf·
+¦»Å— Ž}©xvqynÕh§mÃl^ÕÐü$ö¶›[véMZìÓm(ÃaÒ�$N|H¿Tˆ/
oŸŸY‰3�Ç	¢<!mÁƒ:AJŸƒÓw‹—Wo8^�EæÂr~€¡dçŠÑÜnËû:ßïŽZ9‚®Ùž3ÿ3$'1Á&M‰ˆ—›lùÙ×	Ã̸­„½yKØ2F ¾‘c©éȱ’Ri©æs{
5Åævï—A)=À
õ«c6�wÕ²ÜþL,Šò®²“S÷òæJ%X$Rá¿‚ 5MÌi?~—m4·J¼ÉZž 6&??Ä›Ožzh©¿[Ê�eIrŠ5¢Pã}Ëï]I£„#AÛHtR×ù63Æxß>}ïÿ7– ó§Y
+endobj
+1964 0 obj <<
+/Type /Page
+/Contents 1965 0 R
+/Resources 1963 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1952 0 R
 >> endobj
-626 0 obj <<
-/D [1829 0 R /XYZ 85.0394 459.6249 null]
+1966 0 obj <<
+/D [1964 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1834 0 obj <<
-/D [1829 0 R /XYZ 85.0394 426.4105 null]
+1967 0 obj <<
+/D [1964 0 R /XYZ 56.6929 612.518 null]
 >> endobj
-1835 0 obj <<
-/D [1829 0 R /XYZ 85.0394 390.6449 null]
+1968 0 obj <<
+/D [1964 0 R /XYZ 56.6929 335.1485 null]
 >> endobj
-1836 0 obj <<
-/D [1829 0 R /XYZ 85.0394 324.0377 null]
+1969 0 obj <<
+/D [1964 0 R /XYZ 56.6929 267.4555 null]
 >> endobj
-1837 0 obj <<
-/D [1829 0 R /XYZ 85.0394 263.3171 null]
+666 0 obj <<
+/D [1964 0 R /XYZ 56.6929 225.2657 null]
 >> endobj
-1838 0 obj <<
-/D [1829 0 R /XYZ 85.0394 199.6317 null]
+1970 0 obj <<
+/D [1964 0 R /XYZ 56.6929 190.8284 null]
 >> endobj
-1828 0 obj <<
-/Font << /F37 747 0 R /F39 863 0 R /F23 682 0 R /F21 658 0 R /F47 879 0 R /F53 962 0 R /F55 970 0 R >>
+1971 0 obj <<
+/D [1964 0 R /XYZ 56.6929 153.8399 null]
+>> endobj
+1972 0 obj <<
+/D [1964 0 R /XYZ 56.6929 83.2251 null]
+>> endobj
+1963 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F48 940 0 R /F41 925 0 R /F39 885 0 R /F53 1017 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1842 0 obj <<
-/Length 1880      
+1975 0 obj <<
+/Length 1710      
 /Filter /FlateDecode
 >>
 stream
-xÚíY[sÛ¶~ׯÐ#5S!¸’à£b«­{;µ•¶Ó$´Ù<¡HE¤âª¿¾‹ER”�LÜNÏÌϘ °Ü;>`WdŒá�ŒEˆÂ˜Æã(æH`"ÆËõ�ï`í‡q4SO4mS½\Œ^|Ï¢qŒâ�†ãŪÅK",%/ÒwÁK¢	pÀÁåìõü|zöãüì?¿_]Î'S…”³7oæ—ç¿M¦T` bŒƒ×³Ë·³WvîÍ$¦Áì‡ùÍäÃâ§Ñ|Ñ(ÖVž`¦µú4z÷
�S°á§F,–bü
-ŒxÉ \Ù™úÞM,ËB«x·Û&uVvÕ*m	êÒÎÝúîÕò£J!²‹àbeg‹²¶dÕF-3ý½J¿ƒŽƒ¬¶$©Z%»¼®œ¥öä\Ü2ƒqˆ	µõZÿª^¾Ðºƒ4 OY¨ƒ�‚b!¨!V–YÇ'”¡˜`îx!GAÆͧ+¿D’DÀX Œ
åõ|ñöúÒ&ë/Bã`öê­M×^Àñˆ™ýÐh:5þ9¡’¤(¢�§V¥í„È@Õ»mQYiIaŸêã3UuRïܪ	<‰}dîUm
ŸrëÈ”åkßRU«e­R/À
°c	i°}È*5ì¯nÇ=7ó¹ýxöêæjÀÆ!§¼ÇKøG¾³Ÿ¶<õgY¨Ö²áÇÛ8D '#>Ž//.Ï-“Ø©‘®³"«jÈßrk§®ÕÊ9¡X:?¼NŠ]’¨KB‰h†�¦	ƒË®#fo?^]?í�‹¢VÛB¹ˆÞì«Z­]¬ÎÊ¢*·u¶[ÄrÄxHŽ
ÁˆðØ(‹ñ‘ûÌÞ
-Nò,Íê½}3L³âÎ%š‹ì‹Ï
-öóuYæCÇÞÕv‡ßì‹rSeUB
-8‡ö6{ÆÐÞP
xo2
!6ï¦é?úo3úÔŒ>7£¥5\t1+ÖgŸOöežTÕ
-=×gP[¨Ë&oÀ�´ƒ
-ÔZµ'(Ý÷Ný�Zz·Ã-'欇—®ñe[c¾6f8×۹ľ¶šdvÞ«:£(˜¥PFge‘äù~BÑf1k“Í&ÏtzVõ6[Ö;³d\erõYå•�¾ÝÛ§kÁi~TGôGô‚ñ„þJ{Ç÷Ú–•»z£½Êìª,ÏíH÷õ²;µ£¤rÏÂ=—µî»˜±õ²5®!vgú¯o÷)A

)Ä`À0ŠcvèãL¦Á¯
-cØ¡Qø”—â’7ÂQó·ééœh„aª2ˆ»�°+s^7ôÝ5^cAß<zÕo�î¬{"-tšöåA¤p=.ÏÓËk{)‚ë~$»òæEr›7]ÕÛÝÝ@,:e3\!àH|ÜäÍi‹�1øÓ)ƒÖØÛ6dnKØÏ»Ìw,ÍýÇŒ¦ýöô²Y*‡UèÔÏ:L_wØ�’¸I±oþÉçðãÜ}Í¥jÐ`
-‡9|z¥´Å„àã`bDYHtÿÏå®oendstream
+xÚíYßsÛ6~÷_áGû®bùC”ÈG7qÛt�“Åκ[ÚÕ–µ–”JrÒô¯(’²$Ëö’f»ín—»„¢!
+Þ¿‡Œˆ”´÷\Îw³;«Þ´÷k¥°öiùjœ	Äõ;Р¤O’œÓ\"�QVÂq<ž]œœÏNÎ&ê4å;qß¡.’¾ï•ÂI‡g~οÎÓdi^`uÈ)ò)—ò¥d®Q-nB½È’"øþB?|^z‘¤E[.Œƒ¤ˆæ¹M—úo`^P¾è%øòcz½Î‚"J½©vV!ªU±^:ŒêL'ÆY	Ât+¦a¹ãyq*dwB!§.eC°��•”²ëÜ´MB]×=`Ò
+u˜¬DJäRÞ2yžEIîu\[ä×qdîÄ ~�
+´F‘G<v
+u˜lTž€Xú-“]•wfyE[–åÔ§Û|Mª{&AËÇ&¶×Y?¦¸¡ó!Áá¿Ú¿*ÑÿÑ�>c‚îµge¶íµ°gDò†½ó0[¦YÜÈÌ"ÌM4Vi°hõ™ÕJ/â /ÂL¯¤Ih™®-zQÒQõªsà‰Z¬ÐŽ0AGö¡-ÑÝ�`IÊø�HÔ¤ö„ÂJ•±ø²‚<ßu÷›´B&Ñð�Ç�Õ&?Ü„Éú(¹nFál)J³‹b(¢ªt¾¤ë,	VM&ŠŠ*§ó"ß
&†ø| ¡×¥ö€i¥ÔÉ´ß*Þ[	†)‰¹ßv%Õa¼Ñ‘¨„,g´i}VbÃü2áÔJ茆
llLði7@+÷>ÛÅ(Š†Á'K½«g6ËoÃy¤ÞjXsM@d.ƒõªÈ�]Ý‘¹0ã�˜ä󗛆
+‰2$	vë…´5ý¹@ÌÄ·Ã_)x1ž]^LtÚü6`£÷—ãéóOÄ:�ÈÚÜ2ð†€M·,‚b�7¹ˆ43<Ì4‘gFì>´\=-ÂfÛ[+ŠÇF%dAvå��§ã±~yô~zÖqÆ.P>bŽü"/j=^#¥‹»ú¸ÔÇd=³]ÅòĆñÕÉäX+‘Æ�E%PÜ�¾©!æ‹pi@Hæ‡Ó Y7l»K<�¨çy{³„Á—¢‘&£ËÙÛ³‹Ã
+KúE©¿áãú½ÊL.Á*ZDE5×�ÒŠÈm` ,`À)ªý"MW]€ãVÊ=$émåm
+…†”çhpt":gz§Ww¼ŸÚë*Jvu»¨½’ê@oèx›+gñÉ®nªÕ—jõ­ZÝU«¹¹Õ4¸ÒRJb†ù*Èó®¹BúvV¨4.;4 :¯UÓOPt1pC¬Òøúù4–Dî¹�ÛM"¿r¢.,J·PÄé"ìB¢Aö•ß_ú½Wkë‹Nß–§Ïì_òÌúÒÃq�6óMû®ë#A±ßÖ™wèt˜�¡´0m&D^<¬Â¿ž÷ÓgŽNqP_ëßPÊ�,('m¥÷‡Òãjõ¡C½Ç‘Ï™û³Ùèªñ‰le@=«;¯
+~:;×4ì&g+Tãæzk³ó8™«KœàOãä£gÎ͆ã&|Ä]ÏoÖåcUGÏ|ø;­ÿwi˜u?'� añ?kîdÍòi?Zâ‚c¨¯u:WCñO{´ùžÒ�	A»ÿ�À°úƒ$Ö)u(BdÛõê{¦mßÿÅl”–endstream
 endobj
-1841 0 obj <<
+1974 0 obj <<
 /Type /Page
-/Contents 1842 0 R
-/Resources 1840 0 R
+/Contents 1975 0 R
+/Resources 1973 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1839 0 R
+/Parent 1952 0 R
 >> endobj
-1843 0 obj <<
-/D [1841 0 R /XYZ 56.6929 794.5015 null]
+1976 0 obj <<
+/D [1974 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1844 0 obj <<
-/D [1841 0 R /XYZ 56.6929 687.0104 null]
+1977 0 obj <<
+/D [1974 0 R /XYZ 85.0394 752.397 null]
 >> endobj
-1845 0 obj <<
-/D [1841 0 R /XYZ 56.6929 626.5588 null]
+1978 0 obj <<
+/D [1974 0 R /XYZ 85.0394 692.2263 null]
 >> endobj
-1846 0 obj <<
-/D [1841 0 R /XYZ 56.6929 566.1072 null]
+1979 0 obj <<
+/D [1974 0 R /XYZ 85.0394 446.6274 null]
 >> endobj
-630 0 obj <<
-/D [1841 0 R /XYZ 56.6929 528.949 null]
+1980 0 obj <<
+/D [1974 0 R /XYZ 85.0394 386.4567 null]
 >> endobj
-1847 0 obj <<
-/D [1841 0 R /XYZ 56.6929 496.7215 null]
+1981 0 obj <<
+/D [1974 0 R /XYZ 85.0394 326.2861 null]
 >> endobj
-1848 0 obj <<
-/D [1841 0 R /XYZ 56.6929 461.9427 null]
+670 0 obj <<
+/D [1974 0 R /XYZ 85.0394 289.3231 null]
 >> endobj
-1849 0 obj <<
-/D [1841 0 R /XYZ 56.6929 398.5692 null]
+1982 0 obj <<
+/D [1974 0 R /XYZ 85.0394 257.1813 null]
 >> endobj
-1850 0 obj <<
-/D [1841 0 R /XYZ 56.6929 263.2909 null]
+1983 0 obj <<
+/D [1974 0 R /XYZ 85.0394 222.4882 null]
 >> endobj
-1851 0 obj <<
-/D [1841 0 R /XYZ 56.6929 125.0477 null]
+1984 0 obj <<
+/D [1974 0 R /XYZ 85.0394 159.3957 null]
 >> endobj
-1840 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F47 879 0 R /F53 962 0 R >>
+1973 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F55 1025 0 R /F41 925 0 R /F39 885 0 R /F53 1017 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1854 0 obj <<
-/Length 2946      
+1987 0 obj <<
+/Length 2836      
 /Filter /FlateDecode
 >>
 stream
-xÚÝZY“·~ß_ÁGn•ˆà>ײìȉÖr´‰U±ý0KÎ.Ç&9kÎP²òëÓ8çr#U*m•ˆÁô
-ûÔŒŒ±²p¨pPˆ),"|
8 lpÖ¯kÿ.ÛU¥o%;€v°h=îNa”l³ñÌV�hhÐYâî3ºlØØgµÅ€[ViXH=ê¢ÊÝ&ŠèÀú~¦m‹Ýæ¾R\‘gá›ÌâÛküC;Äš‘6À
ÊrŸGÔ¤¤­‘øI~?¾¢N¯§&äѶHìÆÜ#ÉÔ±“?D¾#i³–èÛ
qÔ×EÎs¬žqD5çç¢¢9y~øBeŠ~7E•¹’2¶Ú…ÊXƒè½?Õ¾3Ƙ®ì5?~,ªð�®„ë)²j,®#ÚC†n†qݼÛ¡Ÿ€]î惡CjSr0	–|±¦6ûç—ê�’Kc@Èé¸&]¥Tó÷ÁÿDÅaŒÏ¤P-¢é*¹êa4�’šÅÀÚf1`hý
-ÒOÈRù,[‰hÈW7•HH£:Œ�g²�™éT¶]Z®´É£šbÞ:�IA®ÃqǬëü�z³f<“j*AÃi æ…¬Ú³�S“(DHÑ4N0ƒ=‚œ©æµ©f�©T¾«{ĸbg°B`€³¬%ªÞºhQœ�è2—àÂ4´f	.¶ÓÂÅö…—.
y:Õ¾3Ö¢l«ê
RàZ™x´òÄÓ‚
-µ¹Ì\
Z\p~®ÄË>Ït.ÒÈó
-ѨôÌÑi›jš‘ÊAóðYÁÑ,_):ò5uk²MÆœç½&Kç|í³+‘16R"c49_Kpª!ÉùºjIóP5qçØŒç;(¶ô�/â�²è|;_Ž_`�ÚÕ2úµ—t+d¸øÁÅ—
-ŠÌ3<»0ÿÿQÑ
-I†ÏÜiSM[f¢r–YžOîA£VJëäQpñóÌ%ªî:öÉmÙS«.{?^+¾<õ Ë‹I|¨I»50ӳǯbd
½‰¹¿�nþ„œø.%®ñwêÎêòøiZö1ÿ¹MLë_HÄ$;ã™ÛT3ú�TNÿÕÙK-Uýi—O^j™å¬¹Ô2dmôRK‡·Æ9k2}ƒ;®ÏUÛïleÀù_èXѦ©
-rnW€—÷^5ŽWyʹt“øKO—Áñ,#N;Ó¨ó°™»2í�ä˜ï2[¯ž˜È—b²{É \«èî
+xÚÍZ[wÛ¸~÷¯Ð£|N„Å•½‰³Í¶q¼·ÝÓÍ>ÐmsC‘ŽHÅq}gpáE¼HÞí9m|NDC`ðÍ7ÀÌ�lAá�-TD"ÃÍ"6’(ÊÔb½=£‹{èûáŒy™UZu¥¾¿9ûî­ˆ†˜ˆG‹›»ÎXšP­Ùâfóëò{¢É9Œ@—Wï/߬^ÿåòõ_ÿõáêò|Å∳åÅõõåÕ›w¿œ¯¸¢ ”.ß_\ýýâo®íúÜðåÅ—Ï»ùñìò¦Q¬«<£µúröëot±�5üxF‰0Z-žà†f_lϤDI!BK~öñì§fÀN¯}tF	Aƒ³cÄ(Å{p(C"Á……ãÍåÇ×?¿»¾y÷á
+WcŸi¤X0‰©PV¸H¶éfµ~Hןÿ]©@tÐ’HKxå­d… ‰eý�â…\VÏE�|s�I±q�YQ§÷»¬~víå�ïw½v2Ûð‰Rž§`
–zW»ÆÇtwW‰@[×Ôê!—I5²N!4aVBÛuŽ¬n%9{˜x±r¸:JmÊ×rùô�î*/“MVÜã�[†vË
+íU¿†Ûå™^úÎuY`ÿý
+ç>D”Hɸ›nç†ï
+ŒZº«ÄýÞ"tY¥»¯éî<–K2N;¦‰T¬G»rû˜åéÄê�"œE̯Þ�ÓdÛ,OìêÙ”N¥$Ñ\šÓQ†ES®¼ü+Y/o÷µ›/«ÝTIþ”<{6ûí£¿tÔ„þ
+œ”Á&=~Z:™UG(œ•ÃÈ!ᤫÍá|`)jâùù‚Ìp¾.J1#4Öýù.‹ä6÷¶Ù¤·ûû{ØbÉäš%±q1ÇÌ¢;R3«RvÙ“Ëž›²]÷`ÊÑ…w§¼†Ã¤n¹g/öUrˆºßn“ݳ'ráÙš~Ëêit8PZDGÐéHÍ ¤,:_&Ñ™›²Eg0å(:Ý)Úg©Gg[n<&«wµnºÊÂïê“èH
SÆGü¥#4�M²Ð|@£0xšŸ/Èçë
C‰´?ßk ƨš}Æ•SûÄë×Ðè%ñ–0"D�6d*ïwÉö%Ä„�¨ø˜Ûv¥fÀRýßè"xlæ§B#Sv×ið‹þ”î쳇Püv�¢xÚÇxíBÍds ü{¹ßx�Û“È[.� ­êjTn‹Žy{WjÔ eA];(Õ#¤_,Dë<©ªCÅœ]ŒËyłЈb¢7,
+
™ÝÔ‚Ý"æÚÌ«„FÔê%�naŽßSëÚe¢
+lV1?ݨæ°ê"$æY˜ •ÞÿâZ�Ö.ÅßTÝÆ;›Õ�,¦¡Ø|ánË�¿…cƒ8)¤Ò-¤5N"+V�ðÊ�…v¤}½*ïVáD…=
+ÒI›2Ú¶N¿Õs¼eã¹T[yë¡Q]7ß%OSsÄÂÞM%F©‚)—1úU:R3T	R–*oÇŠŒÙ8ãW1TéyÕ©Ýúl�0QÃ1ØS®a‹ÐÒŸÑZ4lÁFd¶ùNÙ¾YÒ¢}/¤{¯h€@
+ÃÏŽùI+4ã&^ÈzÉçq/ÑF‰™Šî|FÏ+d†JõêQ1‘±é+ÊQ#U kÌ…t±Æ]¹°zœ=1èÁØa–©Ùò)³ŸæÁÉØÁûNh¸K²|âl@4ÐϨìùkj^0Ü\ÍKëîp†	ÍW6 ¾8JZwkΈ±Íb‰¾+ÌŒ
 endobj
-1853 0 obj <<
+1986 0 obj <<
 /Type /Page
-/Contents 1854 0 R
-/Resources 1852 0 R
+/Contents 1987 0 R
+/Resources 1985 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1839 0 R
+/Parent 1952 0 R
 >> endobj
-1855 0 obj <<
-/D [1853 0 R /XYZ 85.0394 794.5015 null]
+1988 0 obj <<
+/D [1986 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1852 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F55 970 0 R /F39 863 0 R >>
+1989 0 obj <<
+/D [1986 0 R /XYZ 56.6929 752.1653 null]
+>> endobj
+1990 0 obj <<
+/D [1986 0 R /XYZ 56.6929 611.3886 null]
+>> endobj
+1985 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F55 1025 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1858 0 obj <<
-/Length 2056      
+1993 0 obj <<
+/Length 2490      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥Y[oÛ¸~ϯ0°çÁb–w‰�iìîÉ¢usbg»@ÛE–m¡ºduIšýõ;)Y²i»ÀA4¢G3Ùo.dÈÃ	‰¤¢jä)Ž&b¦Wx´…ß~¿"–gÚ2Mû\ïWWï>0o¤�’TŽV›ž,aß'£Õúëø=òÐ$àñâæÓ|6™RΙßÜßϳ»¿à]``ŒÇŸn�7ÍÚýDÑñÍïóåäûê�«ùª3§o2ÁLÛò÷Õ×ïx´Ëÿ¸Âˆ)_Œ^á#¢¥W\0$8cíJrµ¼ú_'°÷kó©Ë\øHP.Áa!O8Š �`ò8AœïýD‰ËO–I»iZém¾û D�Q!B…¢5Ç:.¢°Ê‹·C¢�$r/ÏeYÇtlëi$¬|:°ívWLˆ?Îój2eX�«ÜØÊTïK.�ð¥t{ ¶ï{·œen…î+>Τ^GæiÝ ,~‰JË0!ã¬ýÊò…yö
cº­‹ Šsû«^I,C`䘗g³¡0*Ëh­MÁ¸l<…”¼Ai°o̳˜øã:3ôÓ›yæQÆiœEbWÃÎg  YÉ‚4Z£#0[ÄH¥ãÞXõ¹Nãªãj€õê
-âëÚqݼ�§ôÔû¹‘ǽÁ`í†øÊ:ÍÔGíÌ„C=pSÞU —@Ð#mÍy·˜yÊîj
m&.+8´äv|ˆ6Ö§YhÝú)ÈjèEÇê	DTv‡.·_¡{B-&jèØ›ÇÕ??œó¨©öwôÂ,²Y¾ÁdœÚØßæY™U\§{½C.©•Þ!D´·
-_C™òjhݦf‹¥™�õ‚-`‡>3e?Ee~ÒÍZ?Ím¦ÑhJ™ÇZ7™ø©¶wc°²1�Üj»[Þ"C}hNK@¤ù~º÷ØÝ²&Î̹ڴøì`2‚\·õ×.AO-»¦Ê®;’_Œ
ºç¢îS­ïµ_vQ£G_¾ä?L?ðáüSíòº2¿˜£É¶N£¬*¯Q$ÂCÌ÷dÿ8îŠ"CÂÃ-XሕùÆ7�Um÷«Æöäb^Žî$5«½w8F+ñ0⬫
ï¢*|wöòÆWHJæ÷‡}OM YRo˜&}kµ‡ßÚ{�¸ŠÛÛŽuP‡!H
+xÚµZ[wÛ6~÷¯ÐÃ>PçT(®$ðèØJënìdm§íéå�‘¨ˆ§éåe]ï¯ßÁ…)�”ÛdOŽ†À`ðÍÌ7ˆÉÃ?2“a¦ø,Q	LÄlµ¿À³ÏðÛwÄé,:¥E_ëÍãÅ·oY2SHÅ4ž=nzsI„¥$³Çõ¯Ñå‡˻뛟ç*pôÍãèöòîãå;+û0W4ºünù0_�$¦”¤V‹qtwy»¼^\}¿¼úç/ïï–ó߸X>zÃúÆÌ´Uÿ¾øõw<[Ã~¸Àˆ))fÏð‚QŠÎö\0$8c�dwñpñ/?aïWóiÈ\H$(�gÁ‘"J†]†à‚E‚Aâ]FIÈe�–vÙâVoôÛ·Bô4‰@I‚%Ì®Uöå:;ö¡%‹YÉüVÀ2Ö_�*”`¢†¦]m³Õóã,Ê7ö™ê�n¶¯ÕœÈ([•æ¹îË6YUÛ÷¦ì}Ê¢+}ÌÈNó¡¬ëüÓ.³¿èmºoR;‰õÌÀ‡TRÄ™Œ�k~£”oÒ|§ŸN»¿/*‡#vÊßæ‹a‰èÍöœVÅÈl,F€ØN¼Î6i»k`HœÝÅ:°Æ‚%qœ08‚”Ô¯–.Ê*!†ig=:	‡ºX	°Ÿ�f_kš^Ë@³A“ ©›„&F’‹i»:¥€]C`
+$i|dØÃS¶Ê7/�Q‹ž·Y3'Ñ6«ìû݃}±Yk!�êmÙîÖVáSfe+
óÌ	5Z�b–Y�F¾4ÛÌ-Ø�ÓˆÓõÚ¾ÖuVkXcуµÖp°î€D¼”˜Ÿ"d
+Ý	R\œâÑfÚ
ìüt!A
SŒº�ŠtŸ­«rÿ”ï²ÿ–EXEAÀQ*Ë�PID•T¯Œ#8J%ÔW0\ŸÜˆÙüˆiÏ;ÄÎQ€‰E?|•ÈÅB©3‘ÙÓšˆÌNËDfŽLƓΨ
œ¨öÒItrŽ(Nø´q^+`Ý >¹BDÊdhÞOó„GUÞèÄÎHdNF8*Ûæ©m¬´q{àýݪÉ„ÒÀŽæ	äœøX@ÌD7›À”¢D€ÏN	; Dtù=¯CsA'¾\,BÑ‚hB:hCÎ(ìfŸ;o`[AT7
+ž}­qxz-Ï&
+Å¡.
Ì»ÚÚ‚¢c˜af©\ !㠽ǜRóY¿3�šÌ¤ÛÔMŸ«]»ÎìLd±¯«Gí ÑÝWNRŸæŸ[(ayé~µ¬ÂŽ}‡ª_z2[Û„¨A<&Cä¤õ0ßUs	iÙŽ?¹Ä˜ÚG�ïó]Zíœtå}fÈŽN�º€Œc0¨Ä¹‹¾Ö¶:-ƒ­çPêÓ×…ç±åÑ0eœ×
+X7Ä`�ÆCëV[}À@‡øª€ãJúPI„)§=P™9
¨ôhHB´Ä‚CŸJ­pgاu“U}%;þÇÍÝÕ»�×KûvL‡!Hs2>ªªÏeõ‡NÄ»¦_l\q,�ÊêaßϬvŽ;èIŠ€Ë(†Ã¥¾ß²°ƒðØ„¼¦P’ˆ³M
S)y®«ék�ƒÓkp^/	Í®áð“KvJ�%ˆÃаd¸ä50(ë=Ç›`Ô�²ó©õsZ”…¦Ë}R3zŒéî9}qcÀÔÚõTû	T1ÆØß¾r?ª·@LUOkâ¨:-sT?}Ù�ü¤a‡;ùSË‚wòÓ|ªI¯¾ú4÷žúÅp"x®ÍR‰ë
+@Ç»€8ßç…>cói¾[¯ÜíƒæÐ	—ÑÝ´–j,�îLƒf˜+ ¾†E¥Ã
+§.ÒyÇðj{áï¦oæ†Íé‡æ^­¿cå–íég[¬�
6¦/LØ7ÓJ
 endobj
-1857 0 obj <<
+1992 0 obj <<
 /Type /Page
-/Contents 1858 0 R
-/Resources 1856 0 R
+/Contents 1993 0 R
+/Resources 1991 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1839 0 R
+/Parent 1998 0 R
 >> endobj
-1859 0 obj <<
-/D [1857 0 R /XYZ 56.6929 794.5015 null]
+1994 0 obj <<
+/D [1992 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1860 0 obj <<
-/D [1857 0 R /XYZ 56.6929 499.6076 null]
+1995 0 obj <<
+/D [1992 0 R /XYZ 85.0394 225.6507 null]
 >> endobj
-1861 0 obj <<
-/D [1857 0 R /XYZ 56.6929 438.3307 null]
+1996 0 obj <<
+/D [1992 0 R /XYZ 85.0394 155.4035 null]
 >> endobj
-1862 0 obj <<
-/D [1857 0 R /XYZ 56.6929 377.0537 null]
+1997 0 obj <<
+/D [1992 0 R /XYZ 85.0394 85.1564 null]
 >> endobj
-634 0 obj <<
-/D [1857 0 R /XYZ 56.6929 339.322 null]
+1991 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F55 1025 0 R /F23 726 0 R /F41 925 0 R /F39 885 0 R >>
+/ProcSet [ /PDF /Text ]
 >> endobj
-1863 0 obj <<
-/D [1857 0 R /XYZ 56.6929 306.8426 null]
+2001 0 obj <<
+/Length 2597      
+/Filter /FlateDecode
+>>
+stream
+xÚÝËnÛHòî¯0‡‘
«Ã~²X,�ØN ÁÄã‰��
’h‰’ˆH¤F$g¿~«_M)ÀÎ^69°Ô,VUW×»�'üÇ.�PDMbÅ�0Ÿ,vÑd
ïÞ]`‡3óH³6֛NjWoi<QH	"&�«-‰")ñäqùiú)t	¢éÝë÷·7—3ÂÓ×÷÷·w7ó?á7�
+¯„ËŽ`‡y²K—zG@vF9Šá;ƒr/ô:У-�Q(æ±Õ¦ýÜèç3!±…æy•ò´²¿–Å.Érkt•éá9=8 0FŠsâ8ÐqÁ¤áðð=/öeVöµN1Š¥ AA‹�–0ÈM8èqD…(ÖÎÚ$ŒXQƒÕÚ·
+Çuu¸ÄrZ8nó‡kd¡·ÅÁ»Â`¤î´Ün:Þ”å«â°K,Q|ýÓ¢
ØÁ•�ËnéÃÛëÒB�ÓèU2&ù²YãÈg,‘‚¶lRÃG�
+TB}¸²çÄ ùDœôª-­ÖðwdyVeÉÖ¥Ó¤JúG°³IÝ™®´ahà¯:=di‰~ Çþf|hXظÉ BˆÑZÌgÑ6–¯C†Y´ÁÒ|g¬ÏR0¤–§Yz¤
+¸œ#%cÁ­zÂcíÈMæÐ'0E…(�©'#FÉx¿H\¨°û¨«:Ù6[Ylë2{NјPÉ2Vê´´±Æ­ Á:
+²‚“,+²YA‡eÛ
+ÄÿÞ
+Øÿ‘
+ì$=c-¬Vౌà¾bæmÁu“ƒy¸`n‹‡)A"ŽÕiù¬€€}Apú²Ž„Úh†•‰€¤”c5}ß…ä¾*Jt­¡¸+&"ýÖ%"g9Äy�4¶©&ÚŸ»¤v²5,€&-_ä(¬)馣‘„f‹fopP�HÁ¦�º;..gŒòiš—µ·1ý»Ú$•†˜KpÛ"YfùÚ¿tXƒÝëE¿{ý1 TY^§¥ûÐqûV¾Z„d}g�ª+Ç¼IJ»]¿ƒNI»Ø$ùZ)”BÅR•ÐÔ�¬úTåf¶2·Kuj
-Nû™ØǾ(Ëì)XIh(U‰pÉßQ9A8nêøbïÌCêžÖ
+h šÑ‹V�W¡ŒH‰¢XàáÑŸ°c‰c>r•PÎm]%ò”úÒÄ=ŸÊb[WnuŸTmv£Ñ…(� $’ÓÑ¥�5],]–¡è‚‘Tœ†ûæntÑóhÜOÊ×`ìFˆØ°ÒðÁŒK”;H
,“tWä?—΂VÄ…æŒ-0f`Q…ÇÆ
d¼—_f<žÞèOÖÆê�D‡d¡�N3lÚ‘@¥Ž¡“W‚ž¯Ô!ûxù”Î\AŒ9Š`¹g…~\Ôt9æxôSáSxRö’´W•.Œ­ªl½påuéŠâ 
BsM;S궱N Ç2¸9B.äö“,=R€eÏ!¥€R¢ÃòCÝoó|0´úè½\9¯í×¾¹Ðn†RÝwb=Ís“¼Â�÷Œ™fÿNu<®W¹"&gŠÇ6Ö	½z,£×õ@¯q¦Î°ôH
–m½B¯ÇiÔcù7éµéÞÂÂÛóÖYì¶ðNÈ�žÞ+!¡‹<ÎwÊj™!ŸëŒ�F	C‰‡x¦¶kc�RƒeiŠ¾Ð•	¦z£Ä¶\Š#"$>-—G
+ÈÕ	Š”’L±®`PµDÓú`f-tjg.lº‹6ùÖê2Y§\âƂœJ“u©o
+€È½ÏóÕ½³?’〦_;BA¢ˆf>§y
+®ÎÔ3”Ŭ!câõù£T )˳Æt–N	¡a´ˆd½©ÑŸŠnhºžn’ët=»Eõò#•ªŽ`�›Ô§Ø¡=›r_xo¬Šžÿήû†©Ã¬€VKð?µÓ\ùhö´öC>3OpÖ¦84bu �±<2Öûzû~  ¤ˆüwJè)žQ
+DpwE¼¹}óñÝŸðϧç6]—‹Cö䯑²<Ôã2ª…ó6õ�¬\¼/E›ŽÖ4ç£�‹Ï¥ú6Ö‰hç±L´ËÏÖšÍýF'ÜI !ÈiÁ<R@°n¸£Ððż+Ùµ«€ªP0Òj˜Å}	‡å[„#ßÂêîH'>Š)8Œ_긇™í„ô‹äkjW’ås’W6 ÂÓÁÂs]k¶ß:¤ëû�¥»~�;Slèwå>]dº™I—¡a1Å:6Ò�• Ð-ƒ1ÚëyÜÔ"v¥£¿

+s?6
+�åÎÎ{ôòÆ
y½{2‰ŸÙÝh\-¿]Ù»à’æ•]°)€Åñ Ì7Å‘rk¬Ixê@YÜùÊ®dŽhæ¸Õ¹›=1æª3�ou¸í]´#\³‹ÖÔJïÂ�™]‘™Ï϶ü¹[2ݱµ¾›Áãn—£Þi\Aø?íŒ-¤q_ôHÆ÷g]Ñßv<‘ ¦äi¡<ÎP¨Î}iÞ§ºBýzbZß½Ÿ9ÞZöî‘™Ž±dp·y"úä7_õÊ÷ŽGõû¨æ’ä8â4ÌÄéèaB¦Ÿ¹topÆ�Òᘓ,CbF¡c<ÁÌ£˜õ†rÐ|â6³?ôõÝ!óc_jØÕƒFuURÁQf‹òD‰®›qÁȱB×W_�°*¡œÍŸú’UhìÏM Ó#ØwÔ\õü׊rüS¦ïáäÈHƒÄ`ß
+`'”Þ&dhî�V†²ÿ�Šfendstream
+endobj
+2000 0 obj <<
+/Type /Page
+/Contents 2001 0 R
+/Resources 1999 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1998 0 R
 >> endobj
-1864 0 obj <<
-/D [1857 0 R /XYZ 56.6929 271.8119 null]
+2002 0 obj <<
+/D [2000 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1865 0 obj <<
-/D [1857 0 R /XYZ 56.6929 207.6131 null]
+674 0 obj <<
+/D [2000 0 R /XYZ 56.6929 769.5949 null]
 >> endobj
-1866 0 obj <<
-/D [1857 0 R /XYZ 56.6929 125.3906 null]
+2003 0 obj <<
+/D [2000 0 R /XYZ 56.6929 747.9385 null]
 >> endobj
-1856 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F55 970 0 R /F23 682 0 R /F39 863 0 R /F47 879 0 R /F53 962 0 R >>
+2004 0 obj <<
+/D [2000 0 R /XYZ 56.6929 712.2038 null]
+>> endobj
+2005 0 obj <<
+/D [2000 0 R /XYZ 56.6929 645.6981 null]
+>> endobj
+2006 0 obj <<
+/D [2000 0 R /XYZ 56.6929 561.1687 null]
+>> endobj
+2007 0 obj <<
+/D [2000 0 R /XYZ 56.6929 455.008 null]
+>> endobj
+1999 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F41 925 0 R /F53 1017 0 R /F55 1025 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1869 0 obj <<
-/Length 3024      
+2010 0 obj <<
+/Length 2569      
 /Filter /FlateDecode
 >>
 stream
-xÚÝZÝ�ÛÆ¿¿B@J
Öz¿—Šgûj\_®ñ
�ä�'Q'Ö)‹¤Ïî_ß™ý HŠ’\ÄyiXËåpvv>~3³{lFá6‹¡"‘3“H¢(S³åöŠÎžàÝÛ+æi�hѧzõpõòÂÌ’h®g믘Ð8f³‡Õ¯ÑõýýÍÝ›Û_æ®hôŠÌŠÒèÝõ݇ëÝÜý<áÑõÛ›÷ð(¥Ð@d�LÓèîúÝÍ›ùï?\Ý<tâôEfT ,Ÿ®~ý�ÎV ùW”ˆ$V³gx „%	Ÿm¯¤DI!ÂLqõþêŸÃÞ[ûé”
-”ˆ‰Š¹™Ð
g3ÆH¢(A%D.¬~º¸ýéîýÑN(¡
-ôd8'LédZùžhѧ
-O(?Páº9^2Dˆ˜Ÿ_2M,)zK‚™KÔpÉuæÌz{ÿYºQU_Ý(ûœ•n”¯Ýo³ñ䛪nÜh›.7yé§óÚý.Ó]úXøÉjÝ-¡	î1é	Æ•"Ilp?-Œ„g’H©bO’–«	>,!BØèËlösG^ÊmÛ´iÑmý˲hëüsFNy�N‰�:ï=¢Ó>ˆRO¹À¹õ:8ZoÊ
úëõí¯ÿ|ûËÿ#ûkFT".Øÿ@tÆþžÈJ½tR+Õ—š.
-:EâÙI#Ið6
�tÞH}ªÓFꨬ‘¶Sø+
e@‚u‘Y’A¦ÖLêó‚uT’
p‘Ccœ¨d(T.4j÷˜)¥ˆlÆ”2Ú‚OÛsm�>en¸: #RA^éS�G
-.¸Õßòzù•lþþ
•Í)ÈS”Hj.äû>ÕÈTòÊ‹%ç_–»¶>Æ<Mbäg%ë¨&D„ˆ€éH´×¾j¦
-/l'¿[è^ó]á‰^ߨýì­'°%¾«wÙ2Ǧ&[½˜¨DÑK©¦—*Qèš¡—bÔû<ç6ÿj7˜
ì ²¾à¤Ðan݉Noü l·�6ýK·¤EùÝÌÎãKV6nÂ%~,†°ßTÎA‰žEà\‰£½]»™Ü3ÍýjméOŸ¤ô5¨a
-wñ—%¾Ô�ìN·‚Ý›žÈø.eLh
-»]�G‘h(dAгáا:Ž•
ÇÝÅpÜUûæ8)‰¡R8+W š�kX@Úäz$Ø�yÝ„£F,íàS›í󬇒¾}öò�³ `-?Äâ�êr¼]�jùA`�›*{¼4<ë´‹Ùô'm
-PœÁ/Ø´GuƦ�ÊÚ´žh©Lª8»d šXrÔRÍôpÉÍ�Œöy8Ñe"Ž}™hÕؤ
˜5_ÖgjwlÓµä‡Ò½j§'b(rtèæƒ/d_òæHáŒÂgP
¡\Ks)Ý‹ØÞ€�Hø€O+ô™»+÷^~¾ÕA:�_CNjï]K1zá��ÇÃZíÂ䮧¥%ógÃJð�âš/4ƒr~¡yts¤`*¸ŠgÜ@âL¸
ÑÙ§¬ “D8ªÞØîö ;ñòvËgo*ØÓ¬¿­ÀyÑgm÷¥yßÜЪ%1	b˜d¾•|ظP2Ý©ŽÝœŽ¶iî/$ŒGdxWzgîÂøJÕD¯nïÞ¸o7±Êæ‚FŸç\á�+ä¿Œo:
ðF‚¯î#Ñ*þm5gÊ·f
¢L|8/ÅÛóÂoê~ÖmÓî37Þgž¸ ×#‡•˜€¸Šw	öǽLÄ0ŸàáîáŠô�ÅÀÂ7M�Q‰ òÜ­-3lÔ.ÜztTÅÞ_.·é—E]-?W‹ 8èžõ>NP�jB¾áÑ$å±d(àuQTÏeèÅzÒ3ç}2–a'¡³jCûÕî†9Hm
-4.º>s¨…q¹Ï	׺;
ª¬©O"$§s¦þ.ÉDB¤áòpÞî“S©)1x«y
"´‚1Õ±ÏM	ýšá¡cº¶àø³ý÷ÎÂåm7æÑÛ“ ‰°´ò I
¿¤t@ÙŸ
-OÛôßH
¨•7ö3�ÀÈ´F4µx¶�TâaB÷b1±}XÔçöV‰÷np pRã°Ù¥#|ÌÜ›MjÃh»n7ó˜-SDHæoD¿~snSEëßw �_Ùå¾,¦D^fÈ@2ÏZBóUäÛ¼	Wsðw%™t½ÊœÆŠ¯îzÞÖ_¡ºÝ:‚ëû[âfoç,jÜUâ×ÙgÞ0~Å:küR˜'™ç
êIRí…€ÁÊñp•*NîÃæPðùñª¯vc§‰
ÌÞÛýÑÞ¤å^/½Sìšjï¿ö‡Sc:£@ŒaöíOÑ~l 9cçûªÜÚÆ)­ÀË�¥ÍÂÏ¥›¶4L×ín‡N)iä?èÖhK\Ñ7tVˆõ”Œ€“(ÆGüðÒ;5”½Ñ]ÕX3@ÅPÔxÕÊâp‘sÞèðr‰9àÆ
-+­¦%WãZïÈúNµ—Ê,—UØwHTF™%IBµ>&*ÚeÁ?ü§t‡?”†€h'º@¨ø Ižy#/4
cb¬âî�î<YOöÿ�O•ªendstream
+xÚÅZ_oÜ6÷§p•�®Êÿ"qOÎ%¸hÝ\ãÞÐöAÞ¥m%Zi»’âäÛß‡Òjwåu{N°Èáp8ÎüfÈ
Oüã‰Õ“N%¹S™f\'ËõKî`ìõ�<‹�i1åzq}öÝ?ež¸Ìa’ëÛ‰,›1kyr½ú5½xóæÕÕËËÿž/„fé‹ì|¡K¼¸úå⢽9w"½xýê-t•’˜²–^]üøêåùï×ߟ½ºÕ™ªÌ™D]þ8ûõw–¬@óïÏX&�ÕÉtXÆ�ÉúLi™i%å@©ÎÞžýk8
SçL „ÍŒ49´l&8ÈøËJaç—e`Ï<3ÆœØÍc +6‡û¢œÁ1(“,Œ
=¹HÈ„óÌi-ð„8×™*Or)3†48¡+4pàt™6ŠF–i)GŽŸÎ†§×ðW¤¯�eJ¡mb`·Ž[\:ù#áSÎIbš´ÃVw&„ï.×"yÙÀ†’éžÁ‹‰ä°)#&^Ç5ìÏ2›ä
+”F•¯ïËÝ+O›MW65µ‰fÒuQÖÕ§8~ÇêÎo}ÛQ¯kèûâòê%ÍqDXùsÉÒçB§¾j6~—)ê5Ö2|¢I7žˆ[¿nιŽóVhC<ÿñh@ãf¬¹M—÷E}çWÔ)kúô¹í»~멽õ•/Z�R³Ã3Q.Go•ÉÄžç`ÒÝA´-vAò<÷_—á ØÜC‰yäaà¦è
Jfœvç×|xF.´çâ-ùµÖSgá™uZF¿þÛºø¸h›åûöÈ©µÉrÎL2]øH»‘kF?9]Õp0wû
+^TUócoº°Knsu¬‹5ùË�L`eÕ°rW–ö­��
}a€¬0�«U&%ØeÎ
+Ë‘	cVäò]{äoüÀ�\J~päÒe*‡xþóÎ;NyUÎ3�f{5�ÔtNÿ™ÃGžé,Df¹Èøsø{°òrl‹ôõ£ˆ©…ÉÀD„L §Áä´ýdÊS�9}3u®ÀNN1ÓÙfB»½oújEí
+ÔñãÀ,`Â<)%¬„jK)Fµ‘º$­±9Aìšq8r�
+½…`yf•ÍÜ'øW(¦F¸ÂB«k‡Š«ódÆàSH꟪²¦Yå™™ê+×YJi°Ùôþ0Wg�\¡Îêfê,—q({ãA®Ê­_‚Ý?%B•Ã(‡¦ËWY׌v{>¦$yÈò{êýã@2Zƒ	H˜ù‚Ê2'场k@ÁÇZ:p·ä+ vC«`R –
+¡#,×kº@§*ë@†Ø	sîzªö[ IžÞôQÏÛ„ñ(ƒÚÅ
+¥÷æJ`W3舅ß ‹áþÃbÄ<Z¾)¸A)ãÜg)ß\(PÝ_ˆ‰aÆcÅ›„€Ž!qªvš#¾pñ&¨-Å—(Þ¦¢OoÒ@<Z!öŠ·É…×™Iñ–Çâ-G8‹”2r�¯¼ëëå0-OÊîžZèOÁ‚jïŠ" lt£	ý–sVàÃ)õ-Â9‡j�„/ï·—£GÀDqèÐ�Á$-›mˆ-êÐCB
)Å0â\Bq³j|[ÓÙ×�Ï–ž:­_ö“I¡h„ïºiã*°Ú¿cIÇ+¦ùL±ô›1`*ËE4
+q˜òX:ä‚g¹ÕOæCk§Øç}ìå�{ Tø¯½SÑ'²Ÿ€bÅrž“Òàʤ?”t9úøíÌ%D�ëJcŸºƒèLë|-‰¦;!4èVï¾úæ\)ò
+j½Ëåto�ÒøÙ×mE*ì]¨-½Žc#<>Ь&ÞÓ¸EÜÑæð©Óþ÷À¦ßböV2§÷’áF
H”þR�9\¯¯‹ÎÃõ—3–Ð(Hoô@„“×¾¨£Ôxé–æ±Ç@T0{ºÄ�e‚ï•8$s|ZÁ<nÊn¡á²ÂÞãq
+GÏ.Ç^e�âN=íµÒ
+;)PäP(aÏR•Ô¦A‘‰Œ[b@Å�Vˆî:œe¤Ïp 
+âÏL_¹Tr •öt¥40…�úph¨
­3<™ˆ:Znà9^o4Îf6Ï÷×ûÙcÂ�?‹×ä~ÛŽ×ã:>ªa;þž~÷±ìŽÎ�6̓I‹Ÿ°4v<'~¹"ž`–™Åd
 endobj
-1868 0 obj <<
+2009 0 obj <<
 /Type /Page
-/Contents 1869 0 R
-/Resources 1867 0 R
+/Contents 2010 0 R
+/Resources 2008 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1839 0 R
+/Parent 1998 0 R
 >> endobj
-1870 0 obj <<
-/D [1868 0 R /XYZ 85.0394 794.5015 null]
+2011 0 obj <<
+/D [2009 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1871 0 obj <<
-/D [1868 0 R /XYZ 85.0394 752.2237 null]
->> endobj
-1867 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F55 970 0 R /F53 962 0 R /F62 995 0 R /F63 998 0 R >>
-/XObject << /Im2 984 0 R /Im3 1108 0 R >>
+2008 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F62 1050 0 R /F21 702 0 R /F55 1025 0 R /F53 1017 0 R /F63 1053 0 R /F41 925 0 R >>
+/XObject << /Im2 1039 0 R /Im3 1162 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1874 0 obj <<
-/Length 2332      
+2014 0 obj <<
+/Length 1639      
 /Filter /FlateDecode
 >>
 stream
-xÚÅYÝ�Û6ß¿Bo•�˜á‡ø…>m.›ÜÉ6—lÐm´6½VcK[KÊfÿûr(Y²e§‡¤8ˆIj8gæ73Ë
-ÿX"Q–ÛDÛŒHÊd²Ø^Ðä¾½¾`‘fÞ͇T/n/ž¿:±Ä*®’ÛÕ€—!Ô–Ü.K_MfÀ�¦7—o¯^Îæ<Ë„J/ß½»ºyyý+Ì%" ¡4}{yóñò
®½›Yž^¾¾ú0ûãö§‹«Û^œ¡ÈŒ
-/Ë_¿ýA“%HþÓ%™<„f-O¶™DfBt+›‹ÿ龆­S*Ȥ!’g*(.pBQŒhÆ€HP�Ú뉳)=E"¯¦yã¯ùü•”BK—X{Še±s‹¦Ú=êƒ1KS{~S’õDÇ¢‰Á‰ŒÃ[ÃG²ýk½›1“VU/ÃUÚTQÖáÎL+àRÂœ
ק™é(óUãvÈ÷
�Y¸º.ÊûxÖÚá`Qm·y¹Äɦ(òLó°ç¾Ýº²©ŸÁš`é]½s«*|�<pœ/=w�´’qb
ͼ~ˆ•’‘ðL0ÁEUþN)¿owyST%.ú•�#‡¯`(ÎÊDY67ýf)Lp3m–4™[A2“ÙÓ¼p^qØí³šwÒÍ¥ÕDS­‡Ïßß}•M¸†çWÈ<’×Ç/ƒG”*cÁP€¡æ�m^Î抧ïÃÿ7ð?K¯û1O_éJÞ›(n‰‘2¸pòhÁ2�h8·ßk%,<¿ÞŠäewL†×ŒŒçCÎᚊ�¬\%€»’�çÇkÞ®‹žØê´zˆÏmUZ¯«v³Äõ;‡¿míâJ©ÀRþlËE·M§�E³Æ‘·¦ ?a"pp4îÍ8o‘f,fJ`Y$A¡ÀÄei%]¬wà–½=sa	?4ç¶0
Þ<'àqL¦mYGó+y÷%¸¹`<]V®.hpÙ•ë¼\8œÔnÑ"‡¢yÂ%oÿ»­ê¸£~ª·­„™ �¼Q£lˆ�3`’Ï€àiJI”PªyT
--Ž
+Þ
ÇæÅæ(Œd
-^ÐX“õÛ|_€S+@9ßãÛ·E¦¹÷.£
L¸†»b€:
†î¤U&ΣaO5ô‡‚>�•">/8áîP{–“Ì•O<’«#š�kS ÿLÛ¹>¸¦-‚ïó0ȉî2°æŠfõ
K
-ðÒ2r/Ñ€�$ð¦vlÀ#Q
-)‘‚w1úç€}·
õ®N¡^&½�ŒEÔc�
Y‹H7Ÿ@=~õ†œÏ ^¤@ƒþÙÇíL¥o
-I¤Ôzoú5²é”|šqšS—ié6?ÌÀŒ"
DÏü®Ø œÀ|ë€7E½õS¬_^îªAÇAˆ§h¶ì!“‡f{µá�à|Y¸‡ç(¡²é^¿ZM@`"ë0é®(—ç)�ì!<\8çø3–m‰"€_ÍÀ:Ó(ZHyý vM·«šÇìÕø`#ÕRÅ|�µsuÕî<hgBƒ§oð8Š-?éÇråõÐ�×–yã6O`4…è’
ª5!#ò›·./#WŒ8šÌl¸5ç3ðNÊÙ(³AžU¹yŠ¹ŒöQ’êñ{>z+­PqŸüsr›>®]9aµ¾Pc6ûºÕ
-ÃÍ gð,»üÈÏ&7°z`Àø‘N˜A/˜_Ûä>¤Ë H0–~}‚�P:ÙùÃÎ	¼9T†r>¾x`
™ßˆ5Õ)”J!-£-‚a.ª¶FâƒóâêÒ#˜ßP†Tϧ“]N„Óc§�Å`¼°éÎá|çš¼YUà@ìØò½:àçÙNmMò§ó£a
-lü¨£¯Æ%áYñzª	ùF=
!BX5ðM•G-ó&ÇÑ
- Û‰¼^DéLMŠ~pž‚ã”ênY”¡F¾YØ�ÃjuðméVy»‰¯ü¹p�¾w2Í QH+ôwIó´†,ãéuÄ
§R<îõn²¯µ: |'šÿ³�.9‘Féïßèr>“òqp|Å4:„Ü7:üxò¿P½Ã¡AbÏÃÿúž‡ïÒ¸rüÔsñ˜�£UüR8ä…E²_}q}óG–ˆW3@'·ñµM=îÄÒ9D(˜·±Q&¡¿;·
Ð…\"¥K,·óò¾[½mºR|Õ6í®g²qyí09:…8C{ú&ýðf`ô�<0‚A¨}+™É‡\‹Úë×7—o>L„x	AáÒÁ×å �ZµMìª}];°uq_æ>Ýðû�f…­Yü�­4[)¡Ñ[6xÀ÷ô-`ŸÂAA
�óc”u±†÷‰žº+—‹©ÒRfˆŽ‘h/Ú±DÞŠ¡6Η'Á‹q
-&ÕçÁkHu¼zªø ÿþø¡	õÅÝÙc;¢‰cG˜D9¡êÖѹ¯°[¾ˆXQ	
-›¯Ž0ßd¦³ô¤ª ^�ñŠóš�VTGõt}sëêJ·Wïßá9
-ÇÄŒkïtþôjZŠ0."Q[ö½Qrê¯lPù?�MhŒö�å›ÿ·ÿc¦!E7|Z÷ 5¨”`…òzƒêúØè f	ˆ�Dzÿbƒ¼žendstream
+xÚÅXKoÛ8¾ûWè(÷HìÉmu‘ºÙØÁ.Ðö Zt"¬-e-9iö×ïP¤Ù’Ý]`aÀ¢ÈáÌð›'E?‰¤¦:ˆ5G,7#ÜÃÚÕˆxš¨!ŠºTo£³KiIe°Xux)„•"Á"ý¾E£1°Àál~ws>Ç<\\Œ#J9“áäææbv>ýÞb Ä8ü8™ÝM®ÝÜÍXÓpru1]|],Zµºª̬N�>ÅA
+'ø0ˆi%‚gxÁˆhMƒÍˆ†g¬™Y�æ£ß[†�Õzë\($(—
+CŒ*6A1!@s‚HÌh%C€5T°è»=èÙ¥JÀ0VZ
+î©×R
èǺRE”i¹¯àu‘¤Î4iR%n´ÚŽ‰
+‹�W½Ë$ÆHÆ
+ͬ?°àùôj6¹ž$°�†¹¨	§A*C—¨vU–7am—XWzevŸ'ëÒ-–Ånmm@½[ÙÉo~§u+7ª<—E^9
k·Çe'XÉ“�)ÍöÉlóºv
ƒ„SÅ}¤nót9p"J�H6™ôUµ¾FÖ‹ËÊ$iÏ#šÊ$˜•|O–¯.ÕñòÕRyƒ¼¿»9«c„5!§Å6Db÷ª¦Ç”ï˽,jà—¾øºTÏA|6«W5œMlOr*#†�ô¯Pu¨N@ÕPy¨¦³…-Soœ20±¸¸ýØ+êò¼ŠùiMZª
Uöà�¶%Dã¾.;_:Óâ9?
XŠCÐ…¸ÐħfÓ½l‹qziò4Ëï½�ò¿
+b¶ž 
=+½Ö¢gžh—§æÆ47ÎÕs$
&‘Š�†ï>Í.§Ww·‹ùbúiöã´aÕ�W¢Áœ�V]$ÚØNX1Ž0‘´é|ŠÜjz¿sÙªf¡�YÛ*…¹+I0W…,‹ÍãÚ|w«•ŸLM¹Üfßš=y3[%ÙÚ�-œÖ
 endobj
-1873 0 obj <<
+2013 0 obj <<
 /Type /Page
-/Contents 1874 0 R
-/Resources 1872 0 R
+/Contents 2014 0 R
+/Resources 2012 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1839 0 R
+/Parent 1998 0 R
 >> endobj
-1875 0 obj <<
-/D [1873 0 R /XYZ 56.6929 794.5015 null]
+2015 0 obj <<
+/D [2013 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1876 0 obj <<
-/D [1873 0 R /XYZ 56.6929 175.2854 null]
+2016 0 obj <<
+/D [2013 0 R /XYZ 56.6929 586.3808 null]
 >> endobj
-1872 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F55 970 0 R /F23 682 0 R /F53 962 0 R /F62 995 0 R /F39 863 0 R /F63 998 0 R >>
-/XObject << /Im3 1108 0 R /Im2 984 0 R >>
+2017 0 obj <<
+/D [2013 0 R /XYZ 56.6929 444.5078 null]
+>> endobj
+2018 0 obj <<
+/D [2013 0 R /XYZ 56.6929 369.9671 null]
+>> endobj
+2019 0 obj <<
+/D [2013 0 R /XYZ 56.6929 265.0122 null]
+>> endobj
+2020 0 obj <<
+/D [2013 0 R /XYZ 56.6929 190.4715 null]
+>> endobj
+678 0 obj <<
+/D [2013 0 R /XYZ 56.6929 151.8306 null]
+>> endobj
+2021 0 obj <<
+/D [2013 0 R /XYZ 56.6929 115.5088 null]
+>> endobj
+2022 0 obj <<
+/D [2013 0 R /XYZ 56.6929 83.5219 null]
+>> endobj
+2012 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F55 1025 0 R /F23 726 0 R /F53 1017 0 R /F62 1050 0 R /F39 885 0 R /F48 940 0 R >>
+/XObject << /Im3 1162 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1879 0 obj <<
-/Length 1937      
+2025 0 obj <<
+/Length 3855      
 /Filter /FlateDecode
 >>
 stream
-xÚÅX[oÛ8~ϯðÛ:Àˆå]⣛¤Ú4›¸‹:}P$9*K]’ñþú=¼É’¬&Ìyxxxxø�I~d	„™â‹Pq$0‹d�O0öñ‚8žÀ3C®÷›‹wX¸PHI*›í@V„p‘Å&ý¶\ÝÝÝÜ^¯ÿ}P�—ïÑe 0^~^Ý~]}²´»KE—«�7ºó�)Òl/ïo¯¯.¿o~»¸ÙôÚ5&˜iUþ¸øö/RPü·Œ˜ŠÄâ:¥èbÁC‚3æ)ÅÅÃÅ?{�ƒQ3u΂EHD4œ1
%B�‚Žl ’Œ2cƒ«/·Ö¿Þ¯ôN7ë/·zO0“
Œ‡

QD±4S6»Ì1‘

¡JEÀ¬yÊxŸ¥3¢G˜H긒ªücúÔÕq›WåeÀ0[jJ‘é6_æ�¥µUeIµ?ÙŸv´uÄ4k’:ôsJOmã¼°í]V_’h™ÁÙñ/W–Ó
-k³¡”ÃI»8_ÌÜ*ÐÛÑæF!‘‹ 7,ìã9Oa·1zuým½‘ø†B .	sÛ¿¾½¶ÜÊ~Vé>/ó¦sTµ%Ýg[§{™d–ô9.»¸˜1.‘¢RJ'õ§4
-Ûéú$ä(Äì
z®s
ÆÖ	
¡c4˜�UÓlwEk;gÀÔDLôS+a‰„l¿n¥
×+Vò\ÆJÏqý®îJg©CžžJQðh¡^סç:Wbl("IB:ÖbÞPÎ7’¬i‚<=³Óú¡H„a4FßÃÍ�s€O_fÜf€î?\]Ânðb,›ñŽ‘äÒ‡¢_fê8ɈcŠãÿ[qâ/ˆ(¦6^É.K~hOøÁ9þOUfÓáºL“)­x±a£Ig…!¿Œ°#ç›
-ÃHq9‰uÿ— Õ3�`³úºùõËýÛ	k]¶Y]f²ǦÍö�í\UeSÕmÞíOërĸ¤N—("�ÖÌÖQ'‹¡FÐ7é
-/
IΠú°œÖÚÀ•tµ+ŽZ;Ú70Â�ðÔÿ  ÐHò71̱ôF­Ñ=ýÍK:Ô}ª�ƒ«Ò«ÏÁŽÅѶ†(S#ãéxäW"ÉÞ|¶LŠ‹§ªîA´tmøþúyu|¾zEE–/»<ÙÙ‘®ÉOl?ÍÎbP¯múYbû­í›;<|³Ø‹ÈJÃÊMˆÔ‹)ÉzŒT%œ˜ä
-®:^£A�j|½7ÄÁæaý1hÚ£y¯�ÑÔ†¶Õ€ÉÐ/�†îXµÿ貦u2üHÏï@/ÃôÆÿÑç7À�~Þ�°ÃUQŒšU½±ðÓîÞ—›}@Hv1ØÄÕœû®qœ�>¼
-¡¤€
-î•PÈ«¿Ÿú½À` ñü«“†Â\õëºÄoõ,«ÿTSMv?Ì•ç¤S“-Ñ\Œ‹ÞHä*R¾N³‡ÛHlc½ s¯
§g0Í`54OZY½·yÈ»êÅÒí¸ÔÆIëˆ;Çæ¯lpµ >®k¡	ÀÛ¶_lžÖý‹Z?vÛ»±O
úÐíë—
-d¯®pƒ]3ófânPìêòiæš�ûBëo?¢žÞˆ¡‡ÿ“g†áâqÇ+¥wHˆ˜ªÞ?·žëþ_'x—êendstream
+xÚ¥]sÛ6òÝ¿Âo•§ƒ$ûæÆI›ë%õÅÎô®i(‘¶9‘HW¤ìº½þ÷ÛÅ.@‚¦gn4#‚øX,ö{”Ç~ò8K"¡óø8Íã(29^o�Äñ5Œýp$yÎÒMZŽg}yôü•N�ó(7Ê_^�`e‘È2y|Y~XœžŸ¿|{öúß'K•ˆÅ÷ÑÉ2bñæôíûÓRßùI®§?¼¼€Wk“¤ÀyF,Þ^¼??;=IãÅåË“�—ÿ8zyéÑ£.…Fœ~?úðQ—p‚‰HçYr|/"’y®Ž·Gq¢£$ÖÚõlŽ.Žþå
ŽFíÒ9R$:‹’L¥3´PòXÊ(O#É#£•¶Ä¸xhÚÛ®î¦G1€� ©ÖQj
+�;�†ÌáÕ�ˆ
án³Þ=°~ã{±¹nwàÁ·ø/®�ËØ鶴­GÃç�oN_,ßœ%�dqS¯o£äÂvóÀTj@ÛsÉÅÏͺ¢[8ÉnNŽ=fh-Ó±ÓNƒ­pÌ¢�ýˆö3ž¦vmmGGƒ÷õfCcME+5ù|è©€}ã

+[|L�ž§"�
•ÊÐE¤Aª6^Få¹Ë¼#Q*ž»Ñ
+÷6˜Áh«íx6@€’+¾‚w�r9ñQè_´RN¨mŒ´�«ŽC²žå΂üô‚ÿ;úV&iôí_TVÿ;_y7OL™æ‘½EY&Êp ›BžöKJôÎÔî@ºP8c1à7¦\¨ì±Š2™Æs(2
Ò$Êtœ†Ðgw>µ…x�JG`ÉÓètwƒQ•»ÌYŠ
++E˜™‰xñEh™< ×2‘‘^Ù¹4ÑÓ¤aÚâì�	%�)–Ö�âH�‡Ž'Ko€JZëå“Êš±µåI¨±æîU"-=;í�Øêö^k¸¦ù”ðF�c‹6€«OçÝ¥Jrt!ac()‡j[(™Û8mF%ämJ9
ßóxè›ê«¢«LL��UµËÀ{�t‚uO±
+ìPÖݺÝïŠk+,1Ö˜¹­]�{7‡&pSL^–Mkb*ÑÃàºÝn)Ñ€¾MÝpÚšg`6ÀÊ…Ï‚¿Þo)V)Elð\oª#|•-úê�Þ–]•+»Âø¶x ÑÕ‰´¾
+šwuWÛ¤gˆØ�vßßÚ!˜9²å0rÛaÄ*9bÅ©»1ŒÌ†šðJ¶í�^Øz12µ½ß±
ï+ÆÍåì�£nØ
+1B’ö¬×àTÍÄÔ‘Þ°ôøå“R•û‰\[ÂÉÈOê¼|ÁË8VNjé¾ÜŠ‰> "
+\J*¹›×==­�Ã6kà22¹ÖOâ¬ÖF¬
èá9[S­)_çk-åY–N
+¡^ØI‘Gw„¨\A °rWÒTL²ÂÍ“‹~Íw“Ö�¾¶îB-ÁË�¯3KÊ×}–ý
³$ÌÔS
³@@íæÚ¸Â��Ýÿ¨·û-÷Ö[î.xÅ`>ÌD° cífõÀJj­ª«áöÞkžj«¼(ª)[ŸK‡Å�Kù¹f¡…Œ“ž~Gn³mJkÇ Tøµ"g3ù$Àq�íçèþœõÀLoÓøËœ¯`G†A�H÷óìBÄSvˆÄ±C8v@i148$°ŽP`�¥ãRl"*µáĘp8©£§và…T–þŠzÿdJÙ`.vv;\Wã
+<!â
+~�ÓÐw4’¿91#[âwsŠh|õÒØò±S™LéIòúÕ–Ff¾†0÷±˜„P¿OœýX, 4ä”�ä�nBÕ(x訣àþàëÅB¡x—|«Õü”H˜¸{}œi/¼ù²
+þn<|V�n–©áKb=ùHë\:¤�þR%SÔý‡É�qÿ&ãQendstream
 endobj
-1878 0 obj <<
+2024 0 obj <<
 /Type /Page
-/Contents 1879 0 R
-/Resources 1877 0 R
+/Contents 2025 0 R
+/Resources 2023 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1889 0 R
+/Parent 1998 0 R
 >> endobj
-1880 0 obj <<
-/D [1878 0 R /XYZ 85.0394 794.5015 null]
+2026 0 obj <<
+/D [2024 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1881 0 obj <<
-/D [1878 0 R /XYZ 85.0394 751.4893 null]
+2027 0 obj <<
+/D [2024 0 R /XYZ 85.0394 749.1471 null]
 >> endobj
-1882 0 obj <<
-/D [1878 0 R /XYZ 85.0394 670.0469 null]
+2028 0 obj <<
+/D [2024 0 R /XYZ 85.0394 677.0612 null]
 >> endobj
-1883 0 obj <<
-/D [1878 0 R /XYZ 85.0394 556.7566 null]
+2023 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F41 925 0 R /F53 1017 0 R /F23 726 0 R >>
+/ProcSet [ /PDF /Text ]
 >> endobj
-1884 0 obj <<
-/D [1878 0 R /XYZ 85.0394 475.3142 null]
+2031 0 obj <<
+/Length 3132      
+/Filter /FlateDecode
+>>
+stream
+xÚÅ]sã¶ñÝ¿Bo•gÎ>I oÎÄÉ\§ç\Ͼig’{ $êÌž$*"uç×w€ EÉ—¤ÓŽgLp±X,ö{Añƒ?>Óy–[ag…U™f\Ï–Û+6ûs?\q�s�nR¬o¯¾ù^3›Ù\ä³ÇuBËdÌ>{\ý4ÿ6ã,»l~ÿðþíw·×…š?Þ]ß¡d>¿}ûöîþ»×ÿ‚wÍ
+w×BÏ8ˆƒúÝ[z#vÝŸ¯ñ$ºÚÖ»ºíeWöëöÇþiQ¹Ž 3„7ÝSuh‰@BMÌ«ghì•æÙÂ×f~\¢ñµî lhSŽÎç{¢Gÿ9Ömíˆp6_>UËO-a¡°ðÙ=…Éf×U».L¯GÓ¿� á
+-î©j+šN)¶U)­jbÓÓ(;�Bg#´Ó¡_>u*`DäÒ›fÛÝ`‰JÍ•‡.²Ÿ–Pfš½{ô`À	ÄêÆ¿‚’ZZßxXí—–‹d@sÑäÝŒ¼ $ø BÓ3ãûöØz2�±­:¿×š&�âàÀdˆ°,BX­
+›µì\‚ÃÂ'wP`T¶ô¤”ƒïž!ÖKÿrÿ@ƒèð0:<–
+ž:±¨C ¥�à?X\N:×cXÑgRx
¯Þ–�g,B�z} á¶*w¤TDˆ�)9κqÿדê”gç9<Uf„gªIBºI±¨˜äÅdÄ"E»'‡ï…ñÓ¾9tÆ,ñ¼È¤É‹Ë<E¬	¦R‹âØ]n†L=TT&@MXbÀÅÁ*è_¢wÃ8Q¯[£È½a†ò.|¢Ä•Ž{Z€	(â´â*ÚÅ©@1^ÚxTôÄBÏÿ	ˆ,ZZ�eã¨ZÝ!SÂD�»q§ØRDT‘áÓ‡¥ÏõªZ½šðU®L¦°g`/V¦:“‚N){.JÃèÒ¾tžG¶eÛEfƩг="D>;_Z™˜!D.•{W²ùüÍýí›;ê\œuýÀ]Ñbuh=
+iÞ@×”+32ÿx@æåÀÒÜúj‘WÕº„önÕƒ¼Ø€œ3xj9$O�癀ª¤Îr­ŠË
5Å:P#tÓ,]KŽÁ}µ:Tm{1˜*™é<W—ù‰XÉQ`€ÉbÈ‘�¦¢`MEÁíI²,øXû8ëë‘Â72£CNDQ�Œám/`"0ñÌ(Éû*�¼¡n#gUqr±òÆGX	&®¡–NH¹¢@Êå‹�ÔˆLqûUa”Å0ŠÂ6>Šr™DQ®‚ÀpXîhAå_&V4 “Fœå4¹;‚.ž	æ;GØêÖv*¹Ë=. Î‡#bÈÒ1Çs®Ï
+¹î-_úÒ‘›´7×`«ÁLÈ5€â;-$‡òD„ž#ÄØ
(Y‘„íSPîRÐm›Á›�žv­BuÔccŒÆI;44—[ U})²€Î¹ˆÝÔå»C+cÙé
6(;`fßÑ˪‚jeë»9Z+;¨ºÀ[â4ôŒ±Æ‹²¥ÌÒ5_Jʇ'OÇ¥T?MI�ñŒéQN÷×|ç\‡ËŒ©^p�ë‚ë,¸6eHªnxÖyDa/s±&Ø8qfÅ�ç>®´<[¹8þ2º­{íË”IsåRfÖê`¯tÄSkÁ¼W˜|PO~}•®n'™€V\ë`Œ¯ï'8úžxFùÂ@‚—:¿¬üë¼ò#–»è6¡YŲöDñr5ã—HÏÊ ‘Ѐƒ^í¡ÅÄA/h„Ö[vnÏ�»ÍÆ�Ôbľ5½vMð~=äæäëIuò©góŒêÓûîLÈÓ ?17@r¹©ÊÙ#ù’ËBŸ>®êAçM@B1*ÅvŠuÁ–ÿ†uzm³<ÐÕ÷0ØŒ[ö+k‚—¡w(¨ùˆ™a5,äPŠmÃ’jÒëão¢Œ¿ç‚çãÃën°2¡8Ý߆õ÷vC�k�	ÈÆKVÀK/˜ñi  ÁB¾/ëäÖëF1–ÏFUÖãäÍ!ñå…é˜Ú
ÈY#‡÷†¾ú‚Fö
+í¿}œ×¾
+8xÁú¾øï¹ÿߺ‚É ä„"Öÿ^DûÄÉ30YýÿwŒp¿¡3üÅà„µ±XFþé&ö?ÀTømölr/ EÄÞž)<;ù©OûŸ0žòþ
+¦ˆæendstream
+endobj
+2030 0 obj <<
+/Type /Page
+/Contents 2031 0 R
+/Resources 2029 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 1998 0 R
 >> endobj
-638 0 obj <<
-/D [1878 0 R /XYZ 85.0394 431.8777 null]
+2032 0 obj <<
+/D [2030 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1885 0 obj <<
-/D [1878 0 R /XYZ 85.0394 396.8929 null]
+2033 0 obj <<
+/D [2030 0 R /XYZ 56.6929 699.775 null]
 >> endobj
-1886 0 obj <<
-/D [1878 0 R /XYZ 85.0394 359.3568 null]
+2029 0 obj <<
+/Font << /F37 791 0 R /F23 726 0 R /F41 925 0 R /F21 702 0 R /F53 1017 0 R >>
+/ProcSet [ /PDF /Text ]
 >> endobj
-1887 0 obj <<
-/D [1878 0 R /XYZ 85.0394 286.9477 null]
+2036 0 obj <<
+/Length 2472      
+/Filter /FlateDecode
+>>
+stream
+xÚ­YQoã8~ï¯p—
+À7W
úËà€²ŒÑë\éìš²ÞJ>Xëa²”Bʾáà8@ª�ûƬu(Ñ™Õ"Ѷ^†ÛÈØÂ,Q7òŸŸ†Ð²^]Øê1‰÷[}xs²”°øb鳂¼­¦XEœ¹ÊV½äK½|gH
+³™ÅÏA'Îö#‹0Àmæ¨íôBB^.ôA*"ƒ8½2¹á‘M—ËÓ±c¦è^@ŠÓ™Ø9&ìÆ1麱ƒ½Ë”8«20ëìÆöu
+³m¥÷ ÔA)úÛ`f'p@p�(ðÙ=MP^²"𛣊¥›Ú…
6è‡�Ç"+¿ã°€ÓÍI'‹22J.ì�6×i7.ÜÛõ’©ïi
+{›ñój×€ÞnÚ)¢( uGñ|]æn[ú*î»n0ç2Æ5‹œ“$†ön
+ý�2Pn>ýYã|ø¨�¹†•¦•kµ^狪ðâ§"ìÖ� u¯±èð´â Þ¸Ç
Æ8M.t7Ʋëßf_o¿\ßTjê0áî/i,
+Âñz½)ìzTë�',’[¢ƒô^8™ˆLÿç`Y»FãX5X:½jW,Q…í>AÁ®ÖŽb7.Pò²ÖÛiè„#0�õø@·¬‡k$«ÁÃ/S	œ
+&HᨮúÊ3ä~Æ%î6vi´[Sl9sù–°í¤Y�3m­oüÞ IÌøÒî%}5Ôut®¬¡˜i×:M싧†.¹åv—ç‚u“Ú£$N•]Ñß&ÐIÒNÊõýdñ›±O3®ŠåªªÒ	·™˜u…±SÂl'm�ÐûaI*”z¡öÁ’‚„vÆb_„�·oÛ³Ò^ˆq#Ú<ŽŸÓ½kfWk&·}Ôo/s”±
KÇS¶4EÇ
6LEƒÎ0ýù6LÜŽvù×òU§Òc紇ɥ÷ÅÛÔNµsó`¤¡­|j;hfþ`ãŽoó¹û)âw*©æ+l×e
TöMMÅoÙ_ñ@æÞòÅw³_:nü³i9$£Ÿ—ïof_¯]ÚUk}º¿š¥ós
t€Âeîîô�é¦ßÅ;ä0ðç‘ÃLW®Ç_éÅwÿE’º™½ýRº
+H8T¶Hë<`ﱬ&wÔwŽƒ35è}“´\˜‹&`I;6ÂÎFs4‰„ªàª>àªñŒÚŠ•N¬r¿sXâÂ:*íi•ûÔÞŒ;e„É0�f¸*{Ð]ÊZ
ê°e¾'W¦ç®wιHpq�Ñ~¥»—¿!�ÄÚ3š
+*Y‰¶›qUÂÑŠç/›.E7ÁÐp=Oí½²)¨‘ÚNÀ·…½€T¶Z³4ß}|Ï(HD«
9CúÓð·	K«�õ'Ò²Ú}†·žP–m¨-­�KV‘½c1³ù“³§-´îIÅWë6‚cƒWv§¡†ÖÂä
,þQÛ0pæÒË
+endobj
+2035 0 obj <<
+/Type /Page
+/Contents 2036 0 R
+/Resources 2034 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 2039 0 R
 >> endobj
-1888 0 obj <<
-/D [1878 0 R /XYZ 85.0394 208.4702 null]
+2037 0 obj <<
+/D [2035 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1877 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F47 879 0 R /F48 885 0 R /F39 863 0 R /F53 962 0 R >>
+2038 0 obj <<
+/D [2035 0 R /XYZ 85.0394 372.4169 null]
+>> endobj
+2034 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F23 726 0 R /F53 1017 0 R /F41 925 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1892 0 obj <<
-/Length 2634      
+2042 0 obj <<
+/Length 2188      
 /Filter /FlateDecode
 >>
 stream
-xÚ­Z[oÛ:~ϯðÛ:@ÌòNñ1mÓ³9h“lã.8=Š-ÇBm)kÉÉæßï/ºYvzpŠ5EŽ†Ã¹~C…M(üc¥‰¶ÜNŒ•DQ¦&‹í�<ÂÚog,ÐÌ"ѬKõ~~öî“0K¬æz2_ux%„&	›Ì—LßKÎÿœÿþî“ZΈæ‰þHôõæãòáö擧ìqå	¶ŠÒË»»«›�×ÿ9ŸqE�ûùLQ:ýryóíò³Ÿ»;·|zùÛÕ=2;»š7çèž•Q�‡øïÙÒÉŽüû%Â&jò”0kùd{&• J
-g6g÷gÿjvVÝ«£ºc”p¡ùˆò8›0F¬‚³uµ§,Ñ‚wÚÛ»ùõíÍáI1Œé‰áœFÍ‘�=ѬK7±Z¤Â}gÁfªC	Â&¬è
Q•ûÝ"›¥Ëå.«ª¡„LqÂ�”§El¨FdìzS†p¥L_ÈoU6æY”H©ÕQ)¬CDœ=yZ�Ï„aÓz�ျ÷ÏY2]d~
á32s«rç)Ã+lº(‹"[ÔyY^倠ÊvÏÙîÜÈ©‹PC"ˆLPCã Ë—ý¦ÎŸ6™÷꼨ê´Xd•L½þá)ÛmóºÎ–þ7t4›Mùâ‡UV×yñèÊ•ÿ}(ëuxc8]ß=Ëðr±l¦t`ÒÑ…#iu‘Uä˜�êbÇ$ü´�v©ŽûhCå|t1æ£m,ZL±Êg«|“8¨€´bŒ=-_C5"`ÏA…!ZA‚èI8î ,!ZS;. ¶ÚÈŽw2<	ðòwJùã~—zÃIœÙôš,]ú´;³¢}}™­Rp²‹�um/Š(¡†E)ßeõâÝ®X.Ê;F‚èDÇ$}Ü°¥ì
_h‰N¸B ržðãÍlõ#{w¦‰¤‰=)YCt(ZÏ°PÔ„¥¼'ÛQ°Fòá<‘“4¶ã
-�`5ëïúÍ™N‡|�ƒ€õbMIÐ%UÇuÉ£þ…ºŒGtÙÙœÐæ˜2‡�´aöʇôvpüì“>«“Ñ„wÖWŒ€®1¡â×)&2|C1`.
-ðÇÂC²:<×»p¡¡B±—߀béñ€òW38di5Ý°KÃŽÏé&_6uZ…;ì‹‹òLp�‡pðС©ÀP¦9?nj	Ü‚j¥†‡TöwMÝ0œu8š*0á	c;G-
ÐÒg¾g‡õ(@¦§l‘£³gË‹�IÀ2®ß
-Y¦ªÂM0‡0¢XÙ„-çÞ×>¹·d¼†�î¾âi“9/%j?íL�ÃÂ,vi
-þc¡kÇ….@Jǵ¤³æ`îèä(+àÔ!v"ÉágnJiŽÎÅC8É ‰ÂÔ0‰ÂT›D‡vÖ`­u÷ÍA®’Š"‘í+óòÛüŸ·_OiÑç§ë¢ÎvEL6÷¯€Ÿ`Õ€? óäûm»/v�:O2¼>6ñ/‚~’.8¾6²‹0»ß¢zg‘vu„†�q7XëCa	£RŒòýëž4³ð�sÓzIstôÞïÈ#`¥b¬}§�mþö*´Á!ñs÷±¯˜Ü(/ë(“1}xeþ¤áPöÿ-pUbendstream
+xÚíY[oÛ:~ϯðÛ:85Ë»¨Ç´I»>Û¦Ù&],ÐöA±e[¨,ùXR‚üûrHY’e§Ày]o£ápøÍ�f
+l¢4Ñ1�'Q,‰¢LMÛ:YÃÚÇæif�hÖ¥z÷pñöƒˆ&1‰5ד‡U‡—!Ô6yX~Ÿ¾#Œ‘K`A§_o¯ß_θ4±œ^ÝÝÝÜ^ÏÿcE�((�~¾ºývõ	çî.c>½úxsùóáÏ‹›‡Vœ®ÈŒ
++Ë_ßÒÉ$ÿó‚5y†
%,Žùd{!• J
+fò‹û‹·;«îÓQ0J¸Ð|DœMàˆ±R¼§-¸pJø0ÿ4rF"Æô$âŒhÅ͉}‘hÖ¥rÛJ3¦ú@ew}›Ö‹·û´*ó'²(‹ÕP
+tªƒBðõ
QaÃH³³æŠ
/g5˜-yò”dyò˜§!ÄùÔ™�L½³�q�[4è8>«r8kj+dSdH#`k)¯pÛs’ŠH{@Û©)m¿l{	6ïï�,§HuÙMY€Ö%�àËó\KyP�û¼�� ^_¸Ä¡ç…ì!/@AN—Ù:« c�)[IÈ3$¥˜Î¤DmÕ¢Ù#EQã
+H_À(ÃCû‡À�–¯bXRÚõZ]HL§¢ZŽ°”ÄqëVu_‚1Õ”=”Å=åYä
Wi3Žžú’|]îA…[`­…³6Û†ZÃîiä3ä|\iªÔÓ$ØT›¤ÍrÝ8õI�cëm›&�EZ8Ré\¤�@LA'`¤,àÆ´Œ}þk—:Nªêç±hp69ŸUõKîX™¡
+ÜœËj…ŽÂ†æà6ì
+$qñŽ…¸ÊÝ÷˜‹,#t,ž½XÄÃ'¬ã6=¯r@0°!o¬ÆȾýÜäu¶ËÛz½ª“b‘VÝLïí,òëzøÄžä9Z�5Ûº>z2},]°îš÷üîIÒ˜ÒžIGŽä ÿV0öûÔm¶¹|ÚBþoÿvsømJÚû4ü„ß‹Dp[ó PVÍŒ›cÃò¿òËþ?ƒü¨Jendstream
 endobj
-1891 0 obj <<
+2041 0 obj <<
 /Type /Page
-/Contents 1892 0 R
-/Resources 1890 0 R
+/Contents 2042 0 R
+/Resources 2040 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1889 0 R
+/Parent 2039 0 R
 >> endobj
-1893 0 obj <<
-/D [1891 0 R /XYZ 56.6929 794.5015 null]
+2043 0 obj <<
+/D [2041 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1894 0 obj <<
-/D [1891 0 R /XYZ 56.6929 752.2728 null]
+2044 0 obj <<
+/D [2041 0 R /XYZ 56.6929 752.0628 null]
 >> endobj
-1895 0 obj <<
-/D [1891 0 R /XYZ 56.6929 348.0801 null]
+2045 0 obj <<
+/D [2041 0 R /XYZ 56.6929 615.2568 null]
 >> endobj
-1896 0 obj <<
-/D [1891 0 R /XYZ 56.6929 250.1909 null]
+2046 0 obj <<
+/D [2041 0 R /XYZ 56.6929 551.6561 null]
 >> endobj
-1897 0 obj <<
-/D [1891 0 R /XYZ 56.6929 188.746 null]
+682 0 obj <<
+/D [2041 0 R /XYZ 56.6929 500.3546 null]
 >> endobj
-642 0 obj <<
-/D [1891 0 R /XYZ 56.6929 150.8976 null]
+2047 0 obj <<
+/D [2041 0 R /XYZ 56.6929 467.1661 null]
 >> endobj
-1898 0 obj <<
-/D [1891 0 R /XYZ 56.6929 118.3669 null]
+2048 0 obj <<
+/D [2041 0 R /XYZ 56.6929 431.4263 null]
 >> endobj
-1899 0 obj <<
-/D [1891 0 R /XYZ 56.6929 83.2849 null]
+2049 0 obj <<
+/D [2041 0 R /XYZ 56.6929 364.9038 null]
 >> endobj
-1890 0 obj <<
-/Font << /F37 747 0 R /F53 962 0 R /F21 658 0 R /F55 970 0 R /F23 682 0 R /F39 863 0 R /F47 879 0 R /F48 885 0 R >>
+2050 0 obj <<
+/D [2041 0 R /XYZ 56.6929 292.3128 null]
+>> endobj
+2051 0 obj <<
+/D [2041 0 R /XYZ 56.6929 107.6861 null]
+>> endobj
+2040 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F48 940 0 R /F23 726 0 R /F14 729 0 R /F41 925 0 R /F53 1017 0 R /F55 1025 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1902 0 obj <<
-/Length 2930      
+2054 0 obj <<
+/Length 2477      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥]oÜ6òÝ¿b�{¨Üz~ˆ™<9ŽÓsѸ¹Æ
-ôú ìʶP­ä®´v�Ãý÷›á�ZI«uRü°Ô�šÎ÷Œ,þÄÂjÆ•K™K™æB/V›¾¸ƒ½ïOD8³Œ‡–ÃSooN^½WÙÂ1g¤YÜÜpYÆ­‹›õoÉùÇ�—×ï®~=]JÍ“·ìt©9O>œ_ÿrþ#Á>ž:™œù	¥Ërìô÷›^½×j€^9DzT#Wˆøçëwìâ§ë÷xôäò¦gwx%ÁòúçÉo¿óÅnöÃ	gÊY½x‚΄sr±9Iµb:U*Bª“O'ÿêvý«s"ÒÊ2me6##)B0§µ	I;f”Tþ.Ÿžëæ¡-ÛéUð£
-›4m*»çS!DÖo„Lnîé^|À¹Hîó
- Ý=©4lì­ê5½ž×t®yÀÕNN�Ñftr°‡T11ŒPHúáEzÌ£Äsúù£xžœcs¶�Wšñ¸½êÝ?ò{(¥4eŽË˜yAHõ//ñžø„"{,Ây#z�ÇX0)d(£îuq›ïªn$pÈŠ5XÈpœ(µ2ppÛTUóä#	<}~¦_Šã°ðaÛË^	ÍÒ”OdßøØ
-ñ`½&5·-
ÐÄýý„ð/1
-�ŠÄ³›¥>0JC<ìÞ7mG«§²ªhõ9¼¹Ñöî‹:àmð—�ð‡ôëˆõ®|Œ/ä
”ÇgÏöÝ.h 1ö�R"畯I‰x·TQ¤Ì˜Í¤�èÍó«qŒKm¦J”6ÜÏ
•P¯Dé‚
…ã‚V,iÅ’; üé¾Ä�1ÄY®A"%èo>w'˜ÈLdrþ"R@U“º¡c,ɸ Šb™–nl\äŸKcLr…Œ‹ú>$AêPµ§]®g¨C±¦µÓÃZɸä�Ê�Ǭrío
-@_*™(A ëõíA˜¹(ã7V>Άäf9”"c×Ù—Äcxª¦zœÄ¬=ï"_ Ò$<nònu„	:bÖ;fYßÍh>d¯‘caDAõ�uñ$¢ÁÕS¡@Jž?+¢Ó—åÑ“mðdÛ{²¥Ôˆ�|²{[
j‚�ìáHthß:A	á‰D'))@ill&&õà„lŠ±YvÄ5�ÀV#�¸&–3’ÉR̈¾ÉM°z`M°:X“x¼~Õ�6´„$Q«oèo”<ÖØ
-n« 2`½0„2,å‹ð>Å�ø´
-¸èÃîW±ºW”dÂ]¤SsÚñÎ5ï?˜1
-
$„ø² mÑ€¯Taqõñ1¥=*	dÂñ†úÃU8<(mŠ6¸Säm¤ôpê
<ê�*6±3õåùm·/Ê甓
-–aðúR\¶Ð§ÛtŸUžÏÄú,ÖÞ±êŽ%ò°¶¦ÇúÎݺ…wú†n‹öîAQØ©íŒ/–kv|	(ŒŠA„1ƒ°©õA{Š^«5
-_Pj1üΠ˜†Wh
--!£IÍM„R<ÃU½Û|öv‰¸Àq¨Þl'XâùàÒ
-DÐo!KaÀ›YKq��ØðÑÝSÛD–™tbÐqlr(,¶¬Šf™WwÍn³™Ÿ£¡ú9Ú¾õÅü¢B(RJâ”vûë\ØØ#õ�Gæé”L¶ïŸŽ
 ¤ïùjNùræ
Öui²ÚmÉ2ê®z¦Í¦¦•Lþùáübùá�s2§¡úRr){›ý µàÑNÖŸØ÷,Åž¡9=¶ÅŠøè܇DX÷µÂpÐ…¡b
+xÚ­Y[oÛ:~ϯðÛ:@Äò.ò1mÓ³9hÓnã.8=Š-ÇBm)kÉÉæßïŒHên»§SÃ9œë7›Qøc3£VÎb+‰¢LÍ–»:{„¹ß.˜ç‰SÔåz»¸xóAÄ3K¬æz¶XwÖ2„Ãf‹Õóë/_nîÞßþç2âŠÎß’ËHQ:ÿt}÷íú££}¹´|~ýÛÍ=<rk`bœ\þ¹øýÍ%:ëkI,Š…+½{ÿŽ¼û|÷
Y/n�¼Ý31*PØÿ^üñ'�­àh¿_P"¬Q³x „YËg»©QRˆ@Ù^Ü_ü«Y°3[¿:¥#©Q\êYÌÔ0=­IJ¨ÍD±dDÂV�&9›ÒdàÂóFK¯Õád”p
q*Yù:{ŒÖÙ6*…iF(—bÖÝy$_Ã5!`×LkB©Šû~+Ó	³1C´¦vZÄÁº:ÞXzÞ¤¼Œ8GµIÝ
+ä
+sÌ{r�k @àËdû5+Ž1
 
ÕýCd«qZb4ã§×pMh®_Q%+Wý]¿ÕÆÓ>eã Áa½hS´IÕqmr
+x‘	õë´Ù¬8¡Í^ˆ:‰)œuB�#O”Õ
o¯]Xï
+§v ºÔN&ó'‚Ùø¸j4‘Ð>È_§šfÅ3ªÚÚ2]5»Öm<øCp‹¼xñºÀú͵%I/YµiÕXu„ȱ
Ù{ø¦tHL©y²},öðÚÎ?ºj 
+%Ñ(iYhºùÈuÛðb€­ïý­j¹[
+Qø¥4DÆN3¿š:Ì�M‚Iß
+¿ËÃÞ{Pµ}u¤:ÃïKâ	•'¸Œ[<g«z‘�Ì`¦—�¸í£xv©™ã•ÎÄ¥¹²€0•>ñ�Ò«fБHaü@<¿bÔ]²®ú=Ù
+Bo-Ú�OA<ÞôËmDÀ¡¥ƒXܶ§ v`ðËÔxjƒ¥ïëŸÛ¤˜:Û…�ö!TOlrn¸#YnSo§ýe,瓱FûAvsãÞ½þxÿyâÔáUìøNUð�ùö'"œ€¬Žs¦3W#ÝIâäR°R‡¹IØ®?I˜†éÜ@ø“)�†‰Hm"}´sh­»mF	K*ŠL¶¯Ìëo‹~þz^‹·y•îó�qî_KÀ?Þªï
+’¬…VÆg¾
+À¸õdÂe@ŸcÙÿ9Īendstream
 endobj
-1901 0 obj <<
+2053 0 obj <<
 /Type /Page
-/Contents 1902 0 R
-/Resources 1900 0 R
+/Contents 2054 0 R
+/Resources 2052 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1889 0 R
+/Parent 2039 0 R
 >> endobj
-1903 0 obj <<
-/D [1901 0 R /XYZ 85.0394 794.5015 null]
+2055 0 obj <<
+/D [2053 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-1904 0 obj <<
-/D [1901 0 R /XYZ 85.0394 749.0409 null]
+2056 0 obj <<
+/D [2053 0 R /XYZ 85.0394 409.4177 null]
 >> endobj
-1905 0 obj <<
-/D [1901 0 R /XYZ 85.0394 687.8191 null]
+2057 0 obj <<
+/D [2053 0 R /XYZ 85.0394 311.5951 null]
 >> endobj
-1906 0 obj <<
-/D [1901 0 R /XYZ 85.0394 186.4649 null]
+2058 0 obj <<
+/D [2053 0 R /XYZ 85.0394 250.1972 null]
 >> endobj
-1900 0 obj <<
-/Font << /F37 747 0 R /F53 962 0 R /F21 658 0 R /F39 863 0 R /F23 682 0 R >>
+686 0 obj <<
+/D [2053 0 R /XYZ 85.0394 212.3815 null]
+>> endobj
+2059 0 obj <<
+/D [2053 0 R /XYZ 85.0394 179.9082 null]
+>> endobj
+2060 0 obj <<
+/D [2053 0 R /XYZ 85.0394 144.7976 null]
+>> endobj
+2061 0 obj <<
+/D [2053 0 R /XYZ 85.0394 80.4778 null]
+>> endobj
+2052 0 obj <<
+/Font << /F37 791 0 R /F53 1017 0 R /F21 702 0 R /F55 1025 0 R /F23 726 0 R /F41 925 0 R /F39 885 0 R /F48 940 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1909 0 obj <<
-/Length 1762      
+2064 0 obj <<
+/Length 2904      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥XÝsÓ8Ï_‘éË9sXX’eKÇðJÚB†�×VZŽ]b‡ÐÞÝÿ~+­ì:©Ka?XZ­Vû¡ýíÚtÀCÇ""‘bj«�ˆ€ŠqºãsX{6¢ŽÇo™ü>דÙèá>�ÇŠ¨ˆEãÙ¼'K’@J:že½'D‘ÉçÙ‹‡û‚÷x%“
-䦓£§»d÷øh97¤2É@¬`ŽuúúõÞÑÓƒ÷Ÿ‰
-NDÈyK)F§£7�ÀÞªÝ:è;Æ#6ä<Õ3S1"„DZP$âŒ[cÿ{dl
-%Ó:/
-”{v…Gezž¬
-4Õ[ÕN
Ô(í·Z9®Þ¥4äO
d‹I
-£Ú
½3
-*Q?Y!¨ç‹8ë”ÛIK"Cîöæ5î\¡zÜÞ¯ràD’8ä÷ãCÇ[ø
-ê8I
-û´�/eµ.]ÿ[$Æäï®	6n¶ƒÄu³¶kÛÁÉ¿øÚRŽv½!æ]È	Œ&pæÑôpí>Ý;™@U~/;7ŸHÏÞžL�7gÇGw$±$‚Kìél�å4rE™SÑ¡§¡baFgnõ¦ôÛd¸jÓÞIšêË9±xªièjÇVfÈÓîCaiu^æ×N!ÌDà±l(õ¥Nssx{j^ÕH×Æl§LD”id‹€“Æ·°ˆ3ÕVNy«Çì3ê›´”^§b¦y9¨Ü"!&Éà‹*_«9 M¨”wªõ–uÏÃÜ–½vy‡(‰yß ~3˜lö!½f¬×x`Ù4ÞGOq¤ð5Íy™×
$¶ÉC:Ñs�q/S·í0)WIqNØÍh訊šü05„UëtÏeÆôÕéñ.¿ê.�ù*�ækà�+ν¸½Öæ¨ý’@:Eÿ�M)c-&þž#n[@#i 7ênÀS|ÂçtÑ›¸1};{~|r?$
+xÚ¥]oÜFîÝ¿b�{¨Üf'ó¡�’''qz.š4׸@�^ä]Ùª•Ü•Ö®q¸ÿ~ä�£•vå8ÅÁqF$‡ßäZ-$ü©…uÂå:_dy*¬Tv±ÚœÈÅ
ì}¢øÌ2ZŽO½¹<yùÞd‹\äN»Ååõ—Ò{µ¸\ÿ–¼J‹Óß/xùÞšÑa
‡•Ô@
+±êN—ƪ¤¿-q!øêßRê›Ý¶è«¶¡]„Ô|àºÝ2Ö1J§Âé-20C[K‘f†Ï¼
+~S-WmÝ6ÀOjÒäm]ì:Ä®Áµ�"ž
+*D@7â7nÃKݵ|lÀÊßÌ1•Ëˆp×튚­Ú
bf¾úÇ:r‰àmä�.wwwíð¾v½p)ÊvßR”¸^�X”L^~K°o_N?Èèƒï¾›ùä%Áú–ž%Ší5=ëª)ç°ýÒT£ûÇWb;
+ï‰o(²û’wÈÑk¼zŠ—
+i�eÜëòºØÕý’%pÌŠw"KmÌÇD�¨UÌÁu[×íCˆ$ðvõHOŠã°a;ÈÞ(+ÒTªihiCl…x°^“š»Ž
+ñ=°}³c

$Æ~}è’#“ûš”ˆwKíŠÔ™ð™özDó<Æêr!µu‡JÔžï—�•РD�³
…“³V<iÅ“; üá¶Â�1ÆY­A"è!Þbî>¹*s‘Éù‹h%´Ló±c,ɸR
¾e±K™üséœK.�qçQßÇÄ!Bgö´«õuU�Íí¸VryrGåÇ}V¹7`(•\” �
ú Ì\”ˆ
Œñ+ŸÜsr†³jÕ®´Ùsâq25‡zœÄ¬=ï"™P 8Ò$¼nŠ~uËÂ	zjÕÜÌ(êõ ‘§Âˆ�ÚÕú£ˆWO•
)þ¼ŠvL/d\^FOöìÉ~ðdO©!Åd
ö¶Ô!ÙÑèÐ.¾a:¬~#ÑÃIŠ@,(��ÏSÅ„lŠ±Yö„k:……zzàšXzÌH&K1#ù¦t`í$À:°6X—¼aÕƒ¶´„$Ñ”«oé“`”2ÖØ
+¤)4CÊ.ãñgüdœ]ðÈ��Xù7òÈ™]B/•ê/÷ZH™ûãE*Ñ4o„×a¶e¾f‚j¯C‚@
+ãAnpÅ
+ñç°µrÎ÷µÐ^Æ"z$¦Ã?u MûÐ0{ÝMéEjÒˆjS}�¨ÊD_°ˆ­
+¹©™“èWCˇ*‡ò±è2šuãñÁìݨ ‡ýkºâ†vâ¥ÂLén׋™‹ig…ö—e™Â:ö”-•r8ë‰vw[݈®ÈDq7gÎw}œ9{!s=Ç0uÞU]>ÃÀ¦hâ�ÿ
+ªMÇñàsY$êó_Ï>|úñœcº�8‚‡h�? ÐzOÄŸnºƒÃ%Ôb{ñ�~†�
•Eê-ý¢éÎd,è$öG{Ž<�üÒ°tR&ÿ	’‰¸ç»k®•†óu»*jlÓ^Ï…ÐñࢃŒ†÷×ÜêÎQúï€2²å[E²nLõY¦åÌ?OY}eÓýøý9Ò:å�"á¹-
 endobj
-1908 0 obj <<
+2063 0 obj <<
 /Type /Page
-/Contents 1909 0 R
-/Resources 1907 0 R
+/Contents 2064 0 R
+/Resources 2062 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1889 0 R
+/Parent 2039 0 R
 >> endobj
-1910 0 obj <<
-/D [1908 0 R /XYZ 56.6929 794.5015 null]
+2065 0 obj <<
+/D [2063 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1911 0 obj <<
-/D [1908 0 R /XYZ 56.6929 253.0811 null]
+2066 0 obj <<
+/D [2063 0 R /XYZ 56.6929 752.0756 null]
 >> endobj
-1912 0 obj <<
-/D [1908 0 R /XYZ 56.6929 157.3292 null]
+2067 0 obj <<
+/D [2063 0 R /XYZ 56.6929 252.6303 null]
 >> endobj
-1913 0 obj <<
-/D [1908 0 R /XYZ 56.6929 85.4876 null]
->> endobj
-1907 0 obj <<
-/Font << /F37 747 0 R /F53 962 0 R /F39 863 0 R /F23 682 0 R /F21 658 0 R /F48 885 0 R /F47 879 0 R >>
+2062 0 obj <<
+/Font << /F37 791 0 R /F53 1017 0 R /F21 702 0 R /F41 925 0 R /F23 726 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1916 0 obj <<
-/Length 2868      
+2070 0 obj <<
+/Length 1788      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥ZKoãF¾ûWè(QO¿ÙÄž&™I0ÁÆ3›q€’d‘¶ˆH¢"Qvœ_¿_?ER-ÉÁ¶šÅêꪯ^ÝfŠ?61ŠPQÊIQJ¢(S“Åú†Nžðî‡hf‘hÖ§úöþæÝ÷¢˜”¤Ô\Oî{¼¡Æ°É}õëôý—/ï>|úïíŒ+:ý–ÜÎ¥ÓŸÞßýòþß~îËmɧïøøõvÆJYH1jé4�þ|÷á»ÙwŸï¾ÿáãÝíï÷?Þ|¼ObõEgTX™þ¼ùõw:©°ƒo(¥Q“ü „•%Ÿ¬o¤DI!âÌêæëÍÃÞ[÷iNJ¢/2ºàlÂ$Ró�2TI¸)¸S†ÝvI¡�ݦZÌíæñ©ÞØ��ýL(bX©éÝ|]Ûyð=ƒŠ—ÄHÏoÀÄ)ó7Î?²ïüè�úÕ@Uïæ]Óâ®mWa
ÈÎH©‹ˆ‚*˜ðëë¦Ýî›ýØ
-€kÌ~UÜyUíêýþí讲\,wmÛUÍ.''âŠÒå˜éá*ÓþÎñã’ð»ŒãÍãAfè>~ýîçO_î?}¾K
#‚F\‘ìÔ-N㇄S!B½G<0åŸýF):¤ �I;³Š�í.#“‚ñ”&2KsJdA…ø.y1ýÔ…•çaµ‡Ú?¡ÂÊ�æaéy’ñ¹Þ4õ&|9_uõnyŸÃ—]ëŸ/»¦›¹È:CL$ÂH=Äh³ye©§Ý2‡R
'pÉ í‰Xµf6¦4)$�xöúòœáv ÜnfÑîv·ÌLëý¶ÝTV„Œ:¡)®Êˆ¬ÚíÚÕ>³²(‰ÔE„½]-Ã
é‚1~"> �V"Ÿ}H¬¡á½—¹ÙdÔ£áq¥‰lm`ªÎéGsRðN^=×%Ä%Þ>ÒæÍR–Ñ>¡r8ZvõzË›~ƒ/%䱦—2€F*LìnÍôæ^šnég“y‡jQ†0#‹ ÕlžS%…PQðvœÜÈÀ{_w~â°õóŒª
-CJÊXIy3(k÷‚��öH–ÿsÛTA†eØö¦®Ã”uϳb0®ˆ*Š�Aÿøˆ^règ¬‰`#)ˈjÂËhu#BP¨ûM�¦¨*ÆPœW]ûTcã»[Ô‰$B5D
-01Ôo泟_OjÈP€HÉ›‘@.V)}ªXò�V)‰êˆ«þ’È—B@ª‹KF¢Ì’}e¡Ð¬TÃ%?¸
-	Aó7ù….hÌ®Ùp(™°ý®îy躇]E�¿@È—%ä~ÎfmT+F¨¨…ýëÞúE*ø°Òu
-E¥æìŠé9‘,E¾3‰{¥¦ìg€œ?sRÕ׆m¯wÝaKl*à
-+øBŸíº¾sÐtºn½výd½š?´¶÷ñ?O[L"ÔG�ç[¦Ê¿xxÍù—D‡[z‡>DËó5E�K« õ2ÿyhü ²6Ñ<Bûøk¾Þ®b
-Û®ÛC’Ë°éQ]€M¤r°Ù^…M¼`†Sb÷wQ®H”‘KŒ$Ñá�fíp<ï©e¯·oœ¤nôb{MWågüš¢„ãZ\ë{%)Eê“VèeêMÅUÝ^,¾AÆŠóè;¹u®ïÔ^ÏÈv;RHÏE&3‰²†r&ßPÀ|çÁÄa’]©úTÀ©˜v0•D‘<ap!8@”B’(�¹,]¢Êˆ7ÀŠi(Ê7Ä”²çãx¨é¾=8»-j?íªA<½´ž¦šws?ë­�A¼G·-®%ñµl¥Ú]ów<!Õ\¸.Ô¾D
-É)~ìm[%$fí_�ºµoõªÖÅNÍÐ~w~jëÑöÜTµŸÈž÷£éé]U?¿ûÊ$1�êtÂêzKpµm'B¦?~Çú`Ñ,j×�Æë+_‚!Húµ/]HÇÓ¯¼	··¶O×6[ŒÎ«b
-Ù!g7G£å:o´(wþy¼q1¢CŠ	!zzT¾Mª%"íÈ�Ь]•©©Ï^øŽ0Ól€‹y姽ncÙãìã,A|«á³–Ū;«
ìy¨³—Óýe¿�·¨ò§ñð«tN±©Ü1d€èñ ddC¼s6ç5¨taÄõá@ÁƱ‡�ríÞɹýŠØ+ÚLÀ éNèÿþ· ã¿?I{�lÎd3AÑXÛƒz¡ì†+Ç¢§ :•ýÚ
5½endstream
+xÚ¥XKsÓH¾ûW¸rY¹
š‡4ÒRLp‚�8�ŠâqP¤q¢E–‚%c»ÿ}{¦G²ìˆM(ÊÍô´zúùuËtèÁ�CŸx<C	â{Ô&Ë�7¼„³ã
µ<nÃäv¹žÌ�¸F$
+X0œ/:²Bâ…!ÎÓÎøÕ«ÉìéôÝÈe¾ç<!#×÷<çd<{3~‰´W£ˆ9ããÉùÈ¥‘�˜(×|�çœÍžº‡§³£ãÉlôiþ|0™·juU§×:}|øä
S°àùÀ#<
+ýá6¡QĆË�ð9ñç
%œ^·;§æÕ>Wø<$~Èd�/íø‚rFÂÀ£CéG$àŒgÄiºRU¥ª‘€~à#/“8¿*«·×åÊ®|îóG¸ü÷‘6èRJ"ßgÛ…k½¡+hÇCý¬nðÝ*^^çªÝþ0̽‚âü²\eõÕr’€õj'î2õ[ù]æJ%+…šzÎApt²ø[ðÓê»Èo.˜8�*–O¾Gù‚æùóÓ?óïý6ÐûØP«ªþE‚ûÀ„6àŒ?›†¯‚'/6Ñûͻ͌¿}ÿbýúñã{hýðâ»�½Ë}ˆ½ïÃÂ#
ƒLÒ¬ÓÂÜäÔW
+<râ‹ò«BšúfBôÀ
+ë&Ô’¤T€îZȪH“ž$›ù–i“å9ʽ¸Á«Rµˆ×9šê¬+«
+…1æÔ¥}š[ÝÑè­
pd­*Ú}­S	šÞÜù@o¥³¹Ê’+<Y®Q4…„ªìåVHª>z+Œm@Ίí%;IFm’¡j€khk¤t’²Ð.׫¸ÎJýºMÉ2l �q…šÃ1hn‹v…Îׇ�È#:ªÖÞ4�_Y4U³Ôq­–ª¨‘ži–
+fm�‹‰°	wè<;º'O}ÜÅùˆ:m
ŠÑYm_Ý*‹û$�1Pz]uœ†Sn/¹ˆ+å7ªHÊ4+.qW.~¦ÐO
+¾½:ˆÊËÊv&�ðLËõ…‰¬¿¬Kpi……$�…M=Õ’úB·X¡¨ãj‹83(fâvË�„‚Ûw³
+ß\£zÜäWÑs£/ˆün|�RîáH*©í%·h@“�|·Þ€[”>Ð-ªÑƒÂ›zšÚÂ7V8"Aà®»­õ*vȹJtþ¥*”ˆ
EŒ�dT¹Äõ~<MÝÜv¡îŬã#,_\¶íú*€îFXæ¿�C„]|g^DhNßQý¹Þ.÷*UJ–ºÞje¯Ù‰¬O±ƒüDKïíKÀTŸZNDÀ4
ÎÎ Å×X.ú:Z7B±.ó$4ÎN‘±�Z¦Œ>Ð(¨Ÿ(òE±eW<,
+•e+RäiÞCaIyYdß­BX‰Àc XSªk•dúòæÖ¬èë‘vŒÙ/™€D<ˆîƒEÀIå-,â,j:§¼Q�cõiõuJgRÑÛ¬èU*ÓïSdðù�¯Ñ�FD‘s®ÔžUÇÃÜ´½æ¸‡(‘\È»
ÄžO$ƒÍîÒÆ:ƒ¶Mý•<�=ÅU„�qºÌŠ¬ª¡°u5hÒ™Z(Œ{‘Ø×Nâbç[pÂiFÁD•ãsGiœOleŒ_žŸÞ�ü:ôgA¨?ØîÜé�ûgM‘šO	¤›;xÔõ­Ô½Œ5 ø{ž¸m
B�¹A›=^q¹€ï7£w½3~3vzv·[¦€]«¢
×ó›
+Bm;Æ!$LNÙz¹½WÀ4Ñ€O_)àãȘ@?r©þ¸ÞŸ,Là ±„°˜¦Ñ§_1Èþ@²Ûó‰Ñç#|õlã†+Ù¶�?Ptv–eþ³¿`@=Éõüaⵞýí¿g¶C	Ix²öŸ—«¹.åm”Ò¦SN÷Uoÿȹ­û`&ã±endstream
 endobj
-1915 0 obj <<
+2069 0 obj <<
 /Type /Page
-/Contents 1916 0 R
-/Resources 1914 0 R
+/Contents 2070 0 R
+/Resources 2068 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1889 0 R
+/Parent 2039 0 R
 >> endobj
-1917 0 obj <<
-/D [1915 0 R /XYZ 85.0394 794.5015 null]
+2071 0 obj <<
+/D [2069 0 R /XYZ 85.0394 794.5015 null]
 >> endobj
-646 0 obj <<
-/D [1915 0 R /XYZ 85.0394 769.5949 null]
+2072 0 obj <<
+/D [2069 0 R /XYZ 85.0394 343.1761 null]
 >> endobj
-1918 0 obj <<
-/D [1915 0 R /XYZ 85.0394 744.3535 null]
+2073 0 obj <<
+/D [2069 0 R /XYZ 85.0394 255.6488 null]
 >> endobj
-1919 0 obj <<
-/D [1915 0 R /XYZ 85.0394 712.0918 null]
+2074 0 obj <<
+/D [2069 0 R /XYZ 85.0394 192.0319 null]
 >> endobj
-1920 0 obj <<
-/D [1915 0 R /XYZ 85.0394 645.3077 null]
+690 0 obj <<
+/D [2069 0 R /XYZ 85.0394 152.6743 null]
 >> endobj
-1921 0 obj <<
-/D [1915 0 R /XYZ 85.0394 572.4552 null]
+2075 0 obj <<
+/D [2069 0 R /XYZ 85.0394 115.923 null]
 >> endobj
-1922 0 obj <<
-/D [1915 0 R /XYZ 85.0394 472.7274 null]
+2076 0 obj <<
+/D [2069 0 R /XYZ 85.0394 83.7361 null]
 >> endobj
-1914 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F23 682 0 R /F39 863 0 R /F53 962 0 R /F55 970 0 R >>
+2068 0 obj <<
+/Font << /F37 791 0 R /F41 925 0 R /F23 726 0 R /F21 702 0 R /F48 940 0 R /F39 885 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1925 0 obj <<
-/Length 1422      
+2079 0 obj <<
+/Length 3192      
 /Filter /FlateDecode
 >>
 stream
-xÚ¥WMoÛ8½ûWè(k–ß"�nëvS´I¶q�mŠ%'BeÉ+Ékäßw(’Šd3ñaaÀ¢ÈçÍÌ›’D~$IMu”hŽ&"Úìf8z€µ�3âd^h1–z»ž½ùÀ’H#-©ŒÖÛÑ^
-a¥H´Î~ÄoÁh[àøëõûw‹w7×>®®ç¢yÂãåííêúýÕ÷ù‚
- ‰qüeyýmùÙÎÝÎ5�—Wwó_ëO³Õz€5†N03˜þ�ýø…£,ø4Èi%¢#¼`D´¦ÑnÆC‚3ægÊÙÝìŸaÃÑjÿiÈ\($(—àŠ¦a”2	'€Q?û‹’�¿¼”ñ×¢5v¾ù ÄH\H¸÷"i–5yÛžúƒ`…™ˆh¬õÛ 
-ï[››ˆk‹îÑŽŒWÏ+RLùZ¤�¨Bàh"}èë½aŒÛ²¶ÏÖ°ûd_RóP±±ÜkÓÕ�[y•ñB#L8¹Ìx�ꤎEYÚ­›¹Šx¾çqÝåÔM.d¼tKi¶°¬d�ÅX+5¥eVÛR³§d�{\Ò¸ÞÚ™Á…L�0)…¤Jè(5Ðïü)
-à»@'P.õ	.—º}´úÔ•ü¥Ôå(Iy5uÁÉ”èÓÔ˜Äã6ïž¹Ýêc•7n¸=Ñ?á=a=ë¿À{Î<!L—,�®‡t¥6O0ëj°3p¶Âþs_y§žDÀV�Ħ‹Ó²õFÝ9séÕF0|’þuU>�t 
¬iOÕÉâs¸eS1µo�©kSEçÞ³Â6âc¶7wÀ±�PÒ5–‰�‰Á²·ú¾ürûÙžöN¬ÇöNlñ_›ƒaí •e}ø”C×dš\hç†CÜ:·å½³þ`‰
-#GTUNN‡¾ŒŠþ˜a¼øp€@ýþ²³®`÷J¹)]H8Ô`jB“ Í`à.`§íƒ)ŽŽÂA¾cÿU2ñÃ2Þ7EÕÙajmºÛ—Á‚NczÌk£9Dl‰€Ÿòº×`*ªlêÆ�Yöu•ÕC¨õa†ÎV «kê²
ÕL`mB}y2J»Á�HßÐÃ	iÎ"ñ
-Û2p—W†¦sç<vÁ4©aÞŠÊ·PJÌÁîäd%³ó¼
+xÚ¥ZYoãF~÷¯Ð£D=}اIf8Øxf3°@6´HÛÄH¢"Rvœ_¿Õ'5%?°Ý,U«¾:I²ÀðGB"i¨Y(ÑÀD,ÖÛ+¼x„{?]‘@³ŠD«!Õ÷wWï~dja�‘T.î¼4ÂZ“Å]ùûò{Dºxùëí‡V?|ºýñ§�·×+b¸âË÷Ÿ?¼ýpóßëˆ�ãå/ïo{ÿo¿÷ùÚÐåûŸ>~¹þãîç«�wI¬¡è3+ÓŸW¿ÿ�%<ÁÏW1£ÅâþÁˆCÛ+.œ±¸³¹úrõŸÄpp×ý4«
+‚e’ftAÉ‚d„ #eƒ$£Ì)ãËë®Ù·u;}F�Ò’-c+ªsGP4 ÜŒ\H"A¬
''9E*+ÕaW®Wëf÷ðXí®Wôÿûªø#®î­°ï~„“{6X8Û2øZ½¶õß•'�Ç	Òœ‘@—x®3<™@Z
+ѳ|¨7ßÀò)­¾f˜K�”`¼g¾+¶ßÀ|QÞ}sè2ü(CÆbsÂï�á·bàG9@+ÁȧؕÍvF€-¥„ž²o/Š[”å¡jÛ·k »Èrýthš®¬99ÁCE‚Kbz¼ÈôØV9~”#:`çÆî·b„‚3kXh¤ŒðÁèÃÇ/?üzóùîæÓmúQÏ/VT"!Œ8uO=‚CÓ) ©EWµ´´YÂÏþ‡1}<Â^Ýìü¦ÝÙDŠ‡æ��p††È„“™£)F\EPAÈäT-oºprN»¯üTXúUŽ.’ŒÏÕ®®vá—Ŧ«;�÷9ü²küõåPw++è‡*Ä4—cŒÖ»G 4rÙ=åP
+±Æ¸°šž	Yµf“â4âÙëËs/°áŽp;ëæp¸&zYµûfWZ2êMQa"RàÔîÐlÚÌÉÌ .U„½=-ÃÍ MíƒH†ЀV"Ÿ¶HlAí—¹ÞeÔ#Á㌎lm`*çô#)R4…“ûWÏõ	ÄEÞ>œpÈ]ÜŒíó¾·ìæõš²ü~ÉAkzÎh¸ð ��õ^ÃÞKÝ=ùÝdÞ±Z„FDs¤Z9µ`¤˜ˆ‚7ûàÀÝ�x·Uç7Ž{¿QdT¥42˜�!’òfÖîŠN�ì=�,ÿç¦.ƒOá±wU¶¬{ΊA¨@B©‘Aÿð!zñ¨q—³&ŽÉTF(y¼Œv‘Q7Dê~¤1at
+ÅÀyÓ5�<øáª0”
¡kÄ01ԃ铟§ÕX(@‡¸«•<_¥©bñtZ¥$ªWÃ#%GÆ}þÈH”9räY°T�öFG~p
‚ϱk¶à>ëŒ9À%µ‚€x>`3ÄhŠk“ä`8ı»§ºõÇ­}\‹ÙDú€-#D2xä‚doò©pÌ®ÙpÉ™ßUÝ:�\%qï^;w
_ž@ìçlÒ†bE3cqûÚZ·Hõ×BRC€õØ�^l#�Ú}µ®­:¬»Ú�xãåÉ–°võýÍ퇰oÞëMÂÿo¢º6dY‚ ÷ÀÓ†Wwm þ�ž
+¨)%%,O')ðÍäxV¬Í0
äÜ™"Ó«¯	�	n}èŽ{d3
åàauI¥<�VÐå@¾Õzœ-f›‘IÈ­0_–•ýoçÀŠ…«Û}(Ž›Îÿ³n¶[Ô€`
ùjWmü�´>vM–`>p³X3Á¶Æn6ÍK>Ë35#7â¢%6Ñ\.íÉŽ;{dtÙŒQ%Æ:q90ƒ
ÈÇœóK–cˆCM=°œ�À>éÀbÓ¬‹�_>5mˆÏ!éÂj×øëÃñàµûç$„8Ù!nB”Q :„~ƽè¿w»¼Þ ÔÇ‚š�Úú.²g>“+(P™Š`rVi=¹÷8*äÒø�<Ú5Ùøó
3¬‡Æ†®:
þ¡¤µG„³KçºÍ~UÙ½+ï7Å:Õ_ðCŸÕ²ª¥Ž…-GXˉ+ÌÖ�L¤ú;ÿ
+5©à-?ÂÝcTá[»;œÂ“Û¤W-}KWHuJ=É'ù©OòoGœ¯¸X"Ñ\qå:à"ìÙâvH5_Ü&*§ò8ec•k“>²
E#
+ÇWÙ(|V¶>
+Ÿ
+—�Â#éFQØV³ÁF24I°p¢¹•·ã€Æ×,v5
Ì‘ƒ­L�OÜa
7¶Gß‘ÈT|þò\lÜø–e³-ê]/
:„ï"®¦Ñ8Ó¶ÚILj®tþ‘GSÁ ƒÆ<zHu6‘ÊÁf6ñõÐP.C7ú‚\‘(#×PF!®ÌD®qÚãy·Hý83ƒ~ÜÞq‚ºÕ‹m6]™Ÿqk5M§ÙÆ—ƒ0©QÚ@3Sí‚(®ìö¢Àáëc¬8¾•Ûæ/†Á#H¼áíd¸8±åE˜þ†Ò
+e‡øvÂ眧²ÿ¯îŒ—endstream
 endobj
-1924 0 obj <<
+2078 0 obj <<
 /Type /Page
-/Contents 1925 0 R
-/Resources 1923 0 R
+/Contents 2079 0 R
+/Resources 2077 0 R
 /MediaBox [0 0 595.2756 841.8898]
-/Parent 1889 0 R
+/Parent 2039 0 R
 >> endobj
-1926 0 obj <<
-/D [1924 0 R /XYZ 56.6929 794.5015 null]
+2080 0 obj <<
+/D [2078 0 R /XYZ 56.6929 794.5015 null]
 >> endobj
-1927 0 obj <<
-/D [1924 0 R /XYZ 56.6929 591.7686 null]
+2081 0 obj <<
+/D [2078 0 R /XYZ 56.6929 748.9271 null]
 >> endobj
-1928 0 obj <<
-/D [1924 0 R /XYZ 56.6929 465.9632 null]
+2082 0 obj <<
+/D [2078 0 R /XYZ 56.6929 674.5821 null]
 >> endobj
-1929 0 obj <<
-/D [1924 0 R /XYZ 56.6929 405.9112 null]
+2083 0 obj <<
+/D [2078 0 R /XYZ 56.6929 573.362 null]
 >> endobj
-1923 0 obj <<
-/Font << /F37 747 0 R /F21 658 0 R /F55 970 0 R /F23 682 0 R /F39 863 0 R /F48 885 0 R /F47 879 0 R >>
+2077 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F41 925 0 R /F53 1017 0 R /F23 726 0 R /F55 1025 0 R >>
 /ProcSet [ /PDF /Text ]
 >> endobj
-1134 0 obj
-[650 0 R /Fit]
+2086 0 obj <<
+/Length 965       
+/Filter /FlateDecode
+>>
+stream
+xÚ¥VMoÛ8½ûWè(+–ß"�NâdS$N6v€mª-;ÂÊ”×’äßïP$]Ùa›CÀJ�3o†oF$	†?’(�0Ó<É5G‘,·#œlàÝ͈xL@Ùu±}ºfy¢‘–T&‹õÀ—BX)’,V_ÓÉããtvuûeœQ�Ó4ÎÆéýdö<¹sÏÇš¦“›é|œÍs Â,Nâôivu™]>Ì®o¦³ñ÷ÅçÑtq¤5¤N0³œþ}ýŽ“dðy„ÓJ$¯°ÀˆhM“툆g,<©GóÑ?G‡ƒ·ýÖX)¸PHP.“LP¤0�×#, ÿ,çI­Ö‹’X½ÊÖ+;Ø<?]1@‚”@¬‡Úr^B1R\$ÈïxP„F£)*ψ=·å
+L²ôµê^¬ÅÓî¥tlOò’å¹ žmVxÈIŒ4%ÚCš]W5Æ9ïçº-;ÿ
+E=¢j�ó¢nC–»rYÙ¸P[Øœ@,�‚º™úÍ5‹«G²`Wæìåòe?&*mšÎ­‹~YnõR´~_ç�PÚ~ka66í�î‘Ç:É(GKii"B sKnúerÿxíû>{ì¶pÂ{äÂvzã)Õuó©)‡ÖdšÎ.â—R0aö8Pç]þðÙœRÁòJËx̶0‡¢ö©6ÆVqs€ƒýýåžîÇ*=/+5šIs†*8šiFó#Ã<­A1ãLÂl‹
+‡]ê¤Ët·¯LçÌÂýk‹í®Ž)[Ä؉®m䘰%4ú¹®ûfåŒe³w¢hw�YUf9˜ªHæÄêöMÝFâ1PmN¹Ú o`)<&Þ�€‘"~Ú:p[+S˹óûá“q‡i[î*“ù¢ne:ì!š]쉔—kÄqnŠ-´Á¯ê«íˆ'ñ¡rÖˆäZÿF:‘vç}6ŸN]œÉÝüáãf³Þ¿a�ü�À0Hƾƒ}²tï”68NQ"hêâvvå¶jOjµ­LÕvÐK�%Oåºt3Kßš÷®ý"/¢R†Y?>¾¾§u™</þ~xú¸ ·¦+÷¦ô#qþÖ‚¶üü»lLÛì»ê°ýÕ%Ú›Aä«Š�ÿøòó¢ÅsÄ”¢ñï3ÃÜŽ
HÙä KÏ©WZ{Ïýyb´endstream
 endobj
-1930 0 obj <<
+2085 0 obj <<
+/Type /Page
+/Contents 2086 0 R
+/Resources 2084 0 R
+/MediaBox [0 0 595.2756 841.8898]
+/Parent 2091 0 R
+>> endobj
+2087 0 obj <<
+/D [2085 0 R /XYZ 85.0394 794.5015 null]
+>> endobj
+2088 0 obj <<
+/D [2085 0 R /XYZ 85.0394 687.41 null]
+>> endobj
+2089 0 obj <<
+/D [2085 0 R /XYZ 85.0394 561.6045 null]
+>> endobj
+2090 0 obj <<
+/D [2085 0 R /XYZ 85.0394 501.5525 null]
+>> endobj
+2084 0 obj <<
+/Font << /F37 791 0 R /F21 702 0 R /F55 1025 0 R /F23 726 0 R /F41 925 0 R /F48 940 0 R /F39 885 0 R >>
+/ProcSet [ /PDF /Text ]
+>> endobj
+1187 0 obj
+[694 0 R /Fit]
+endobj
+2092 0 obj <<
 /Type /Encoding
 /Differences [ 0 /.notdef 1/dotaccent/fi/fl/fraction/hungarumlaut/Lslash/lslash/ogonek/ring 10/.notdef 11/breve/minus 13/.notdef 14/Zcaron/zcaron/caron/dotlessi/dotlessj/ff/ffi/ffl/notequal/infinity/lessequal/greaterequal/partialdiff/summation/product/pi/grave/quotesingle/space/exclam/quotedbl/numbersign/dollar/percent/ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/asciicircum/underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright/asciitilde 127/.notdef 128/Euro/integral/quotesinglbase/florin/quotedblbase/ellipsis/dagger/daggerdbl/circumflex/perthousand/Scaron/guilsinglleft/OE/Omega/radical/approxequal 144/.notdef 147/quotedblleft/quotedblright/bullet/endash/emdash/tilde/trademark/scaron/guilsinglright/oe/Delta/lozenge/Ydieresis 160/.notdef 161/exclamdown/cent/sterling/currency/yen/brokenbar/section/dieresis/copyright/ordfeminine/guillemotleft/logicalnot/hyphen/registered/macron/degree/plusminus/twosuperior/threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior/ordmasculine/guillemotright/onequarter/onehalf/threequarters/questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE/Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis/multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn/germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla/egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis/eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash/ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]
 >> endobj
-1493 0 obj <<
+1598 0 obj <<
 /Length1 1628
 /Length2 8040
 /Length3 532
@@ -8532,7 +9354,7 @@ endobj
 stream
 xÚíte\Ôí¶6Ò ˆtÃÐÝÝÝÝ¡Ä000Ì ÝÝÝÝ’‚R"‚´t	ÒÈ‹>ïÞûüž³?�³?½¿w¾Ìÿ^×Z׺î7�¶‡Œ5Ü
 ¬‡¹rðpr‹t�´�P(ÐWç�…C­
�f
L9g0ЇÉ]Á¢
-Äü{fXE
+Äü{fXE
 0Üú÷äè¹aÖ�ÃöOÃoäæìüØã?ûÿxýœÿŒ=ì	a.ÌÁAb¡ö™9Y®
Ä£ò/z{x�Âœ*Þè—ÖÁ»2#×Dj,ïêÃ8›ÇEµyÍî;Ýoª²n
öA™ºÓÁß‹(üèX>ã.3v±ms™W`gÅúϨ¯"›
 rn­�êèš—ß¡RŽwð9£_²Ò¹Ð_8=óe4%v>oFÀk(Ù?`LÙ½¼`êú4ð±ûåÃ&9[~ƒ˜;26cLà«|r)Sƒj…×Íl(ßÛ
 b¬Å7ÎßÊçÏVð™h9�Žù,¢I‚°RÊ• e®äß·RÆ%=²ìÙ
êt›œ(†Ì%³LÇ�î)®Ž>1Ù¥‘„µ…^Ñ2¼éˆO£Ý	%õ‰>•pjÕr{2–Âw�Í<–g¬™-j—!3cäáakIè,AŒ$ÁLˆÇÆ‹J¯³nöùU»Ïm›Þ‰D3
@@ -8555,85 +9377,146 @@ $O�íœàÅ€DÈ
 t�‡Í=žÝbóÆÃwî6ß"£“˵?�”JËOP2RÐoQo+†â1)©w†¦ÜèådîI½ÈZ¿VÍ�­(e÷åû È
"QÔüFØs(úF�$'‘qL ®/¶!õÔ
¤HvkÖ‰Œh¼È‰¬ê؉á¶o?Ùa:Šÿ±qêcŒ°gã!_QÇ~ÏWê¡1üaœ¯UÝGmã§Yñmn%ìRãr9÷¬ß0qˆ5†/‚E…(êÚ“�†,W‚˜$Ù½ï¶åçLxËÎÔ|ú奕£w†Z|ÂV€ãž÷,éOd
 ÞyŠGÝ
 ŽÎ¨Ý3lÍ4©¿Î\×T2Zª½Ag—.7Ù#ÏPæï™v¼eŦQLÞ»±Oþ¼Ô\’	¬ÿĵJÅñ¾(š3Ç].Å*,MÎ>ÛBx�(ÃSÃó|D³uû‚Þ¡ï†{:Ò‘Á¨2G9¡Cê{É•<|?�ÒK áéá@F)Ø,êw÷ó?�È ¸¢Ëa„Çh%Ù±o^Œñ{‹6™Ý@¥-«ä%
Å~jÉwXjz1�îi´·î¬%uÕ3^¿±g�¸`d+ÎK[ŽDe—„]âò†Yè�ÖýÇ?Ï>£³HjË,èkѸÍhÔ8Š”™v_Å
[ªJÖ®²9m=·�âú?\‹k>¼à¬‡¤*³Ñ³ž,Y
ê<‹ý¹uÓZ/ZV$S·é#ƒmNOš¨5M@¿§rãÝ0Hõ7¬&7[àçŽAØñêOõƧÈêÚ5±pE6~d»Ž^.x¨T1¬µ¤$£Í7¿ÿ4òÆêüj§‹G1¬èípoóÌ3³QýÐZ:œNÍÆéç,0½‹Š‡Zg‹ðâ£à)‹Q©¯³‹X""œÛÆ0�ÏÁ¾äBvFA‚)Y9(ÎYÖý…ì¬S…|¸Ôü¾“qbæÇN.LÔX§…_�ï‚¿œ%�%½¥åŒìé|°
D>W²7}C–Í#—ZR¸
­$º`bÛGο…a¿9gÝS%\”Á/œîñ�hC|�?s§Ø…šg¯ÎÙÈ)ª¬m}ÐvÖËk†Ÿ.bÉ&O
 üõí+uqfº`Îa‡„°£â,I§ã¯½/‘�˜÷�ÇÝ›Á¤'P6ߢH‚
Ú?÷›½šÙ¹˜Žà9¦ŠmHr7:pMRYŸ#£ 'æW¥¿ðKCß|-¡mWÝ躖nᲶË0–«ÞÐ3äÛÙ=j’
¸Ë-,n–³e±€¢üb½iÙ;‘˜Hâ°l<)žL.ßÐYÖÿ°Ú·)�wL=(‚Œ£± L|�)=å'ÀÆ-Å@²öò¾µ<ÃNrä³6îµEôʃ3±d¶kÓ»¬ÿ‹%ôµøü·(kD~ô(¬_yñ‡Í;¯åä²fùOî{&*‰äyÒ¯9Û�B±T¨d>è.<Sâ¢éX3p7«Á~ª"럽Ÿ“lË´ÍÔDQÿfŒ°Ì
-*s"}Y
;Ò‰¢ú{YÌÝÇí]p¶Òݯ€Ž¶Xo³êÙ}
+*s"}Y
;Ò‰¢ú{YÌÝÇí]p¶Òݯ€Ž¶Xo³êÙ}
 endobj
-1494 0 obj <<
+1599 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 1930 0 R
+/Encoding 2092 0 R
 /FirstChar 67
 /LastChar 85
-/Widths 1931 0 R
-/BaseFont /AUEZLU+URWPalladioL-Bold-Slant_167
-/FontDescriptor 1492 0 R
+/Widths 2093 0 R
+/BaseFont /ZIFUNW+URWPalladioL-Bold-Slant_167
+/FontDescriptor 1597 0 R
 >> endobj
-1492 0 obj <<
+1597 0 obj <<
 /Ascent 708
 /CapHeight 672
 /Descent -266
-/FontName /AUEZLU+URWPalladioL-Bold-Slant_167
+/FontName /ZIFUNW+URWPalladioL-Bold-Slant_167
 /ItalicAngle -9
 /StemV 123
 /XHeight 471
 /FontBBox [-152 -301 1000 935]
 /Flags 4
 /CharSet (/C/D/E/H/I/O/R/S/T/U)
-/FontFile 1493 0 R
+/FontFile 1598 0 R
 >> endobj
-1931 0 obj
+2093 0 obj
 [722 833 611 0 0 833 389 0 0 0 0 0 833 0 0 722 611 667 778 ]
 endobj
-1303 0 obj <<
+1579 0 obj <<
+/Length1 1630
+/Length2 6133
+/Length3 532
+/Length 6981      
+/Filter /FlateDecode
+>>
+stream
+xÚíVuTÔí¶VA�!¤†”ºQº¤»{€!f€J¤SJº	�!¤‘RBpé–NI%‰‹~÷;ßYß=ÝsþºëÎZ3ë÷îgïg?;~ïFZu-Ik¸%DCrpsr‰€t4õÔ--¬¡pe)¸£µ"ÒÂtñ¥]!H(&c�„ˆ€ô Ö ˆˆ‡Ä-,,`IÃ�½\¡¶vHó
û_–_. K¯?‘›HÔbºyp‡8Â�� 0ä
Åÿ:P
!í  ¨#$­¦n ¨*b–WÕ
ÉC`×›"ÔÝ,¡V e¨†€°€là® Ç? +8Ìú«4ç
—$d
B8C¬ 7aO+ˆó/ˆäqu‚"7Ï (dëj
CÞô
+ý-Ã

…Ùþ¥€ä
+±µpµv„ 747Ü¿ºóW� ªÞÂÙÙÑëw4ü·×?4@‘ˆ£
'€›ç&§ò&·-
+âàæâú¦mµr€ýj?ÿfýwí7ƒú­¬£©¡¨,Éö¯o×ß¾ê7[€Ôör†€þ;‘ž
+Üú‡_LRRpO�7· ˆƒ÷F7— /H˜—ßç_dýMÄý×YÅé
+õqqrqqƒn~ÿüþu2ù�,Ì
+nýko´�0ë›Uû‡álåæêz3áßoÿMáž/=â	±LOÀ­DƒíS3Ò�Uä9=ý2F:¸1zBœ‹k´_çûWÀÛýRÃ…ËÌ/*C8kE®š¼Æ·�/W•X×z;È·'Cöò¨|èYÞçÍ3½d[›ã§}Õ‹òÞS^À4àÒ][ê×Ð4-º¸|Ç늽ÊâOïžïOÊpâLàk•òöÕƒÂÚ[ÄUÛ_™6OOwõ}ìén?¼û~•’-û£¨;&>S¤¿K6åSC�RÙò·ª·ãòŽ�X�Xðð+yÏ—×ro1
XçFèÅR61žêDž�eâ§Á	×^‰mùkT³ïT¥ØÜKCvá)µKö±éû�¬l´¾úï.ú¹üA¢IὬ}‹xp—ÆÌ:…x÷dlt×VEæ�¹®ëºB4ߢé:°h`M$z¯=Ä*óù?7l &?QäÔ…ÚvÆ<=yÊÙûÃ㎣²=÷'ºçä�ÄAŸßÊ}gw‡U¸'b%6—=\5�Æ„�¶O€X)Ô| 
6*�˜Ö}ØŒôDVs§Up
ˆíbëÞ­×…+Ïo_MX`êÁWÉC.Âß6¼|í½ÏÊ)¥2ÉP0–b®G+kGõýZŠÿåÆ~+`çÑáËé
+Žòêˆ
+âÜy­@/èqú‘�³	v&¹
+Õ8àñ´ZÕHƒ»k|鵑dèC<g¨7¢µ?Ó¥›-;ë
+'´æ«:C\›ë¨úÙñ}ž¥•ý)4
?BºÈQ1­®ÑZUy!/”´�C.pûÁ¹1>(ŒžJAÿÝëáæ…\™�F{3dk*ƒ
+ù£ÜÛõŒÚGa¾Tµ
˵µ;¥¬W~òn+–lO­4o¥ø!=ËMS¸âØ(kb¡,D
ZÆ8T'p—.ø;2S•cf‘¦>dÇvË%·*­7}Åçj£&ã—6Y”<P£-µdšûpÊͱá4xÜÃÍÀªNIÙžG�Ôi®ZyˆJNœ¦‹Âƒü´ÉP»£U?ÐçKÕ¡Â$±åîU¾¨•¯î�´¤Ä�6Œù°Ï÷b0Ol&‚3ûh.R²ÔEµ6�¿PDÌsXykdìnq¡9¬[–º4$4´vŒwäú¾e'1	PEêA„÷ƒ?´ó2k¡†ãÌ2ž"šüœ÷‘
R´«Årg�?Òûü°ºÍ(çóˆÇxemL Ïç&¯�Ë0ú¼B»=0Ò\3$Kr¶êó„ÒÛ+©/fÃl»,{„ÉŠSÕÇúߥÛÌûzTÉߥ\ç›
+j2
ri ÐÔaSïC§[Ev„�¦6”¸£N�Ú±ݸü}Šuò{´’Ú0G/P4t‡!ïLÖöÙ�9ºj>«Dd��¥�×VÑà›lh`2ç
ˆ™0#·êZ=4�í%牵7h%Å	Y$Zü¬ˆv±?‘©‡É=áមð;Ïcc„—÷:IêÖá°5ž’”ö×yÇUµD2>ÃÙ}ÐŽvk2š>2òQ×
›yôASLPkQ¡âZõ>×_À
+ZŒvR¸pdÎ&QºÒàî�¯E¦âx|E&ù'Ar0Ëèh"
’çÏvÙý½Ï»ÓçêßV¤0²iRÂyO„jßÌé&šH¹£(Âμ4™
+V1-S8`_3D	ÝËúÅ7BëbØr¨Ãt©aÊÓêغ0‰¼•�5ï´ñïâ¨Î)9É@[gbL¦')Ä?Ê„ãÐ÷*éT“꟱Eê+ãIõ_â‚R§—«·>noߢiŒ!L½<©35¢$2MIÝs™ôäu¢¨bâ8ûVÇÌšDT£ä¶"Q TFÉ…Cóuø9�dcÝI¥Z’f@A
+»<¶ÚL�9’00#†ô}à…ê¬ëè¾>€à)†fbˆù†7sÑ¿×ÀÅ}ä׊³ÒgÍ¿?FІæNP�˜ké÷2è´à2|Ö§™¥£[¶WDMåtè3?èù:28¢È;Xf1S§³E�Š$´×å0Ä0d—5ŤÐ4|ybæ)OÄ|˜léË@Èu±}µ\"üSÀd5ŒÃkùpü3ʇ×Î
++˜^p€&9I‘òÝÂcJ-Ù.Eâ.ÂÄSL”�
+”kx±saóÝÒ÷ÁÜ÷Kk ]ö¾ô�3	·/*ÉmÌKgƒwõÇ–ˆýIô‰ù¤ŽòŒ¿Ù=a
£ïe€üvû#	}Llb9_ÚEƒˆÓFHRòæ›=ë�­GýTùH:ñ9ˆe¬ù6PÃ%BÒ§4�ž£Ò.n+¿ƒª°ÿ9ÌèÙïc‚4Ã_gÇÓ¶ú‰s+>�傹»˜‡¬9,Épª½è!׉·ïhuFÒiU2Æâ-A6L;iY­"Û±+hô3…RÝOïi¦¹Í —Š‹ä©ˆÏHžn�5÷ò”JD
ýÉ›³¯pôÝÞó4ÇÃøJ~t‰•|§›19äÚ¸N±)¸}> ˜5.¶�5Œ¥¿þ“<ö¨õëGš±×1{!•Å²ê3‚A-üMÉcÂ[ ×%Üû/¾¶�°½9oØPO;fiv±}½•@ÃœJ#(G9j>2š?¤Æñ?~ªÑWåïBç¡ÛµO±B¥™Ÿ†ñúÃ&e“v”3†­ÉÞ&™<)��ïÈxbý'.¼Ï\Ì_³Ÿ±‡Ý'0þààõªckêUPe¤cne„žÁVó“�pÜ Ê½ö>ÄÐ
+½c–î3Ó5¬´0ÏÚEdÊŒƒH(‘©,ðÉôä‚<Iµ±¾»ê»	:�—Ò´
Ä!ܼ^ÞXÒ›/¾5obÿd¬ë¥KºÃ{�ƒø‰Õ˜ÞMG0C&ÂØjãž;áÔ+5ó¸Ç›“°äFÀ.³†ÎDú²À}]lÃúÙ²f�“_¼²v-úHÞœ_qØ*ñ	yžNÂŒ°dŠß³Ó¤¨Jµ¼½·8òý·äæ/›Ü&Õ
+yn£­ŽZ°Ü_N@%3&“µÀeÑ¢ÓnEoÍ“Óm’~XvK”¸8­é3-�äëýð
³ú
+¼0ʪœw�(îø7¼ûVdÖ‰o›áÞÇâ-ã±®3Å(·ˆ˜·gy„Mª/‰Ã¼–Ô÷€(sq%£Êª$¦Ì±lvá3_‡ìäÁU�GÑ8[ÃDUOÓ7¿éç=åÕU�cQQZ¨cÞ­(§ó†64†0\LT\�Æn^·¸’ÃÎéŒââ�›Ñˆh\}Cëõv…ì=^ÞQ¡7°ç¹‹].Fè‡!–‹5·�›\ƒj+Ø3Š7B‚äÔή˜ °w>Nnád¥
+ecŽ¡ñ³b2•ßÃÄœ¯ît¸�âËA".0mÕjÛ;÷$èÓ#Ó“]Q;
Ò­vü‘‡¦ýO¢Â{'ˆÈ‚1N;$�F_<tïy �ã.“yw`¸`�[ÀÉ¥½¢‘öâÈwxúÎÂ-çsy¬û³B£¼!ç?7p>Õ~@
+ÈÃñô�ß[Æ�¤7œàÀfIŸŠ¿iÍPŽêbFDt¨%Sc<ØCÞ±‰¤_¥}#툎~áß\°ÕÃjC¾35𮾌ŠãÖEf˜ä÷q}ÔUp¬$Ú¿�•×çyD*û*ݷ÷î@òQŒÞ7¬â¢¾yçã,£êìª%É0®š¹î³È6�¸½}ˆŸ^½÷s®Ã´ÔøÛܪ{‚€79»#¼¸ùߣf²sË©W½ørÄ(€Db�^Ð*A|üÙÀø乪“ÐzÜÙ™N>uêתͲ, ¤Õè/‡üî¥IM€©*õO	ÀgÆC”kìþ‡•
+5Y_£cóclNŒf•@Uï '¯jwåB
^…gzrÖ¤º|`ÿ!	Î~û¦ã­t¤w¹>îη¯Œ_‰_Tó¾
+Ÿ�ó/°Kê¼-œ	[—¿çÃq-øz~Ii‡³®>ë
GGÈF¶Üšqˆ‹¢À¤^Ý
µºÜzœòŽLy*Ø!$ëȯ²È¿Äø
+Òí¸Fúï�šyË«mn£°MWÑl‡ög2w™SçäSCþ¹A¡‰
+endobj
+1580 0 obj <<
+/Type /Font
+/Subtype /Type1
+/Encoding 2092 0 R
+/FirstChar 66
+/LastChar 78
+/Widths 2094 0 R
+/BaseFont /URQILA+URWPalladioL-BoldItal
+/FontDescriptor 1578 0 R
+>> endobj
+1578 0 obj <<
+/Ascent 728
+/CapHeight 669
+/Descent -256
+/FontName /URQILA+URWPalladioL-BoldItal
+/ItalicAngle -9.9
+/StemV 114
+/XHeight 469
+/FontBBox [-170 -300 1073 935]
+/Flags 4
+/CharSet (/B/D/I/N)
+/FontFile 1579 0 R
+>> endobj
+2094 0 obj
+[667 0 778 0 0 0 0 389 0 0 0 0 778 ]
+endobj
+1366 0 obj <<
 /Length1 771
 /Length2 1151
 /Length3 532
-/Length 1712      
+/Length 1711      
 /Filter /FlateDecode
 >>
 stream
-xÚíRiTSבª¡¬2©¤j=,Œyn4„„H
-¯€iá
Ëg‘ªUpêëê*ýÙþzë�óçìogïï|g3\Âå,1Œo@¤8F² 6$þ2Y0Äԙ˥1þ¢ QP�ˆ@B¡X­Ó
-Àˆø+D|
�
üñT�&«IàæÏœ$	€X‹¨R�
™‚T#Zª†R¡
r\‰"¤�
Ä
X;y#
¬EÒ"�Ù40ª$Á$ÅhœIMÁ˜
-‚70¬K}›JGˆ4Jp›’É”HÇ4
-G0xºÊ¿)œPÿ@™4Ìý÷¯�J†+PŒŒ0¤"€û{*†þˆ)“Tâ¸l.¢ˆÔ~{J˜ÖL‚)qÅ’
�ï
¡0Ш!¢">È„
-‘ý2{ ‹)p)y·;8/»8(:8rtÁÑ
-eÍ�w`5Ý©o]×¢õÁ.äÖ¯ÉsH©ïäyA©�{k“Æ_2~]²cæ“„çÏ{Ÿ½6Ò[(3],œ�ψv÷Üï›îæ>ÌlçÒ­¯~fr‰U¨¿¸KŠ}ƒzmVÛ´ÿöíÏj“�áõ\§G>s5óh÷DãÚ½åÿ’­sÿºÉ´;^¢·Æ^Ä>ì¯|øóÅã~^¢Ô?®7éLÄM÷Kµ
ç«kóg&˜š¤Òª%M³ñž
¿ù.>Ž½æÚ‰ã#€z§ùB·¾ð¾úl–b|Ñ1‘Ç�î^C?GšG{,ʱÚ¼ e'û~ÄòLÏ_¬Î…Ô&:=kO˜¾Ÿ·l/‘ÅZ³7åXMHÍ6­á‘pΞ£Âú‡�UyÖÙ'â¦ïTeD!¨sÙøt9³�±þrí#Ò®0üye›ˆõ=ÓÒŠØàññÌtÞ™�Öó½â“_uû^{°:s×Æ�n®\´}=MdÓß3 ¤§J>-Îy½e´'Pgc/ij�3cw�–Üþ¾l>{Ð^çêóÕRŸzÝùÿŒ­ZÃâÙ«"2¹šX÷Ëþ	Ü\©­ubÀNƒ—üÉnfg“ÌñÛà'Θ©9Õ¸MJ2½<QUÅÉìYuÒÃ…«aò¥Á§4Ë-fÜž9ö¸Øyð)±éÀÕ ACùNØ÷VEøºÑŠ	ï;]º\ÇË#?�^!SÉ^ÇÉ÷$ÍWeô�ó2šºJØ•ëýYn[N”ù9ï‹SÆÆMóˆ°àpøKuû¶kŽW‚¢lµÐæh¡ž÷ìHLGžÕ»Ù«éôO0ãÒº1ý¾º ÒÁ¾#;.fD¾Ÿoºãå\*)~eU7ÔnYˆ'rhT6Öw_¨,²ý0JãO”Fä)Ûn%n^=,«k8¾Ëf;tP�UÔ57¿yÖ›~tz´,]^ñå:Ÿs‚¼ô¨³R~Ÿïœo]ªI81ûÄP¡¤ú@ò]IOPÖ3ßïރ߱]ò8úLIAþóAuïiÏò¢àáË�â›­»µ]š¦êÒüݲ¹5ëß	´;Ô~YtÕÎ{W{Q;ÿ“¶qú2òÅ«¸“Ë�¾6$B
ÝƇ�-¡0v¸°
ëmthóeçæŠKýº®ïQ'6t\+Ëý	‹”7Ð'ÚªöÍ�"s9>m³ˆÅB«Y÷>¸ûé7IÕ‚�±ó’–„«=Ÿ�®Ù!xaNà0
-Y
-rU7žyÓŒðCyUôÚ~îß\´ÿøŸ( Ô 
-‵
-"…ö#FŒ‡endstream
+xÚíRiTSבª¡¬2©¤j=,ŒiF
!¡€
D¢a”Abî
¹%¹—^n )ƒˆ•TeYÄF—Œ¢¢TXUê€RK¬B8‘VJXÖ"U«"àÔÖÕUúó½_o½sþœýíïìý�ïlš[„Œ!‚°
p0†“#�R©„Ãä™Í¦Ðh�8,'
’°p/°R«Üe€Íò–	y|
+
bizIQÀ#�>Aâ‘Æ…R9¡‚5d
…\
d˜�	=ˆÔj°vâF:X§Ãx1)€
6À)JaMh’ JðßÀ�6ím*ÆÓIQÀcR&�"!Uë
+)¬pŒì“Zþ²¦ÖªÕárÍDùI§þ•—kµþ/¦IÓ0¤ãèTjüFœ†­fjVBÈÕˆB„¦¨aÀà,g²—¿Á‘ô`DC¡P
¥\�Oâ0
+MUBú7©ƒµZíù××N&#äJDêÓ`Àþ›=sþŽI“pDâÙL6›CÉýö”8¥™U`‚¦
+Á:
+-ŽÃ(19>¤Aoc%Bz
+Ã:XA1ßÀ>[>Þ{j[M®¸ªó¨-=}¾ñð–ös[O}˜C½>N×ðÆ#áþpÜêø1rÌ¡d8ì+¤äõQO‰²MY2ÖÖG“½½bŸlÆÅPBÒ´Kem­ïil¿k^hIkô|ð“ûÓ;çlëVÝãð+©Ã…ÓknÞxù87ucGŸÙîKÈ}°„’XvzÕ8ú×;EWÆï‡`U˜¹úÒÜ„}O�_™©­·»SoÙ†2©Íu£ï‹YlºNÙßAáìO]hŽ-¬”	gÎ÷º]nVïûºcýš›Â¤¿Ïè¢ÜŒïvKòsJBc$Q#óŽV8)jæ©}Cª©Öp}ëº�z¡ÀR¿&ß)µ¾“ë[ÌIkÜC[›<ö’öÇ¢ÓŸ$>Þûìµ�Úò@‘åfåz|ZŒ§÷~ÿÏ!z;›j{õ3“[œ\õÅ]BäÚk·ÂЦùÁ¿?»yT
+b×ó\nùÌÝ̥܎iö–(]çùu“iw‚Xg%ˆ»ˆ~Ô_ùð·‹-†ýܤàÀøÞä3‘7=/Õ6œ¯
+r®-˜žhj
+®ZÔ4ë˜ëæç<ßg¶ƒ(Á	T;ͺuE÷Ug³�xãcŽ	½t¿ðü±$ÊÔ8|ØkA®íàæy©;™÷#—fyÿns.¬6Yßé]{Âôýœ%{¡ÈlÆš½©ÇjÂj¶iô�³öÔ?äØ”gŸ}"júNY†�:�°�O—ÒÛhë/×>"Š"žW&3ñ8ÿ3-­(ŽZŽ�eepϬ^ÏóIHyÕíwxíÁê¬]<º¹|Áöõ¡]Ï€€š&þ´$÷õ–‘ž­�£¸©=ÞŒÞ=j¼ý}"Ø|ö £ÖÝ7ö«Å~-Ժ󿌮XÃà:*#³Øê8ÏBëþqÔ\©©u¡A.–K
ò³«Iêü­ä‰+jjN3l&h‡^ž¨*‰fåZzVœôr#V�V
+QÙbÉ)õR«i·§�>.qµ<Å7¸Êo(ß	ùߪˆX7R1î{§k\›ç|y¸°ãçÓˤJéëxÙžä¹ÊL½®sNfSWé<‡r] ÃcËéÕYŸs¿8ehÜd5—D@ßX«Ú·]s¾m¯álŽè¸ÏŽÄväÛ¼›S¸’Jý5,®Õí«-µôÙq13êýÓ�h×RqÉ+ë¸èºÁv버C\¡S£¢±Þ°ûBe±ýGÑê@¼42_Ñv+ióÊ!i]Ãñ]vÛ9UÙÅ]³šgÌß±é'—GK2d_®ó;ÇÏψ>ÌëóŸõ­ûÂ"
%åœ,WH¹+î	Í~æÿÝ{Ð;¶A#‹Çœ1<·¨zO{—K†.wŠn¶î¦Õv©›ªKvKg×8­'ÄáPûeáUß]íÅí¼OÚƨKˆ¯âO.uùZŸ\Ä	ê6<iY•	¡‡[° ûðÞF§6f^ž¨4 ëúÎaURCǵ²¼ŸÑ(Yu¼­jß,NT˯m¾P`3ãÞWâ>ý&¹š?0z^Ü’xµçó‘5;ø/̉,zbCN¬èæÍ1ox’q(¿ŠZÛÏþåÿþ'
+(Ô°'0�O¥ü	ÛGŒŸendstream
 endobj
-1304 0 obj <<
+1367 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 1932 0 R
+/Encoding 2095 0 R
 /FirstChar 60
 /LastChar 62
-/Widths 1933 0 R
-/BaseFont /LCGMFN+CMMI10
-/FontDescriptor 1302 0 R
+/Widths 2096 0 R
+/BaseFont /OICPNV+CMMI10
+/FontDescriptor 1365 0 R
 >> endobj
-1302 0 obj <<
+1365 0 obj <<
 /Ascent 694
 /CapHeight 683
 /Descent -194
-/FontName /LCGMFN+CMMI10
+/FontName /OICPNV+CMMI10
 /ItalicAngle -14.04
 /StemV 72
 /XHeight 431
 /FontBBox [-32 -250 1048 750]
 /Flags 4
 /CharSet (/less/greater)
-/FontFile 1303 0 R
+/FontFile 1366 0 R
 >> endobj
-1933 0 obj
+2096 0 obj
 [778 0 778 ]
 endobj
-1932 0 obj <<
+2095 0 obj <<
 /Type /Encoding
 /Differences [ 0 /.notdef 60/less 61/.notdef 62/greater 63/.notdef]
 >> endobj
-997 0 obj <<
+1052 0 obj <<
 /Length1 1608
 /Length2 7939
 /Length3 532
@@ -8644,7 +9527,7 @@ stream
 xÚívgPTݶ-HPPÉ™&çÐÉ™–œƒº�–††î&K�(HÎQÉH�’sÎ 9#$ˆ€øÐïžsn}ïüº÷üzõvÕ®ÚkιÆsŽ¹VmVF-]^Yª„p@óùž4`ö–Î(]°ƒ¯
ÜEXYå‘P0†pP
 G8ÚCзÿã�ºP(
 �²BÂÑ€Û¬Z
-JñDÛ‚Ñ¿s£`·n
+JñDÛ‚Ñ¿s£`·n
 uƒZ|™BX‰¼LLIB—Qdt
(<ok
bu:æ}Ò{ŸíûÑ쓼,Vôâº4�¯rèéM�ûäŽãÏõg\=-äpöæxèA­3gkö£¶Qî
~ó<¤]ÃpÏÃ	µ%l“Ç+Ú:æ¹×w醄�x‡ß9}™]²}IYΉ¼­*"ÉVb—åìì²Å|ý~ÎÞÑÛÝÕÙ|ŒÓºNÃ�‰Ï*î‚MÈæë”N#m¢_äa™ŒéøÛÔªÏ!´0sL^µ$0ÙÂÿTh5ë¹[­Fúù{ª\™ÏíßÉúÐâ¦Ùé%üföC ~–fí*!Î:‰E�výÔzð­´÷Û6гßÕ•Ü 곺£�Âgü«e‰;}ƒv©b]ùßÖÒï6”�‡ùÚ}sø.Gj¢T«$Kñ£•I
âQ–®‹Â~ÒìEÛ1w.ì*Çbr|¬½}$oÖ‡·Gs]> Ã?V1ñŸx£+w¿³^õ9’e‡Ð†ŠÚ¥ÍäÊu””7œœ¸äN­Ñ÷ˆ¨/ùŠõ.‹ú…'Ð)á0äPùÝÚ…ke
 ¸éÛR§ö
 ]8sô&sß±­|*åŸî#>cÕ¯‡‹úœ‚œEëÑymeê÷AÆ€>8m„1œ4¬jõõr¦XÜâd8„²³¤¿V>M¼çÀ7ÁÜ&N\€*ÄJÒÜOµøï8•^Ýçôáö¼J%qõ‡  ‘®.µ&у;ìXBÒ0ÊÚcVKŸ0-SÛ·ߌG?óí·Eƒòñ(€(§¸Ëš’=´øô•ú
+y\J6.æꔋ‚œÞ»ó^eúÞ‚·V„(õb*$Ã=AÁžéÌmEé�ïa9žoñ€Rý3™ÙÑS×!÷8ÎãÒ9‹ÅÕçÜrƒÅ£‘C™Äù\‹-ÕÕ²k±ò¡øáÃÍ�8
@@ -8676,452 +9559,353 @@ QH;ǘ¢&šùŸe“ô¿žUÙ|µ°S�c0R2YE]¨
 �‡á{__bçâ.°ßþ
 LóÃI8GU–¿Bã¡\‚–Ÿˆ{éõ´Sû›7M‹Š–…;ûÛ䃵h¹0GQœ&÷

<‹"œ_ý¼ÈAze‰ÀN2ÿPÜJ"u]©¶ÕLòs.}æQùü‰iõHö5¨ñ‹‚‘öqLðëƒýUj[’
	=Á®…1Ñè²YÆHOŠåoq ’„!¿‡RÒ¯¸ð%ê«~u¯³¿0Š×·6î;>nE=m½a�Ô\{\ÄcïQq”&T/bµ^þü‹}m“¹ò
A’ü陈×O/ÍI>c×b%ÒÌ&ìýºªú· ¶mJ;û7žb{ª6eC‰Æô_è<@ÀbW’+Q'‘šäçÚU›‚ݧ/ˆ+ƒË°a
 <¤þdÑ
_IÒõ.˜ê¢Ï\9¾§é-xÚÖ-9?›
ìÐv_wóý}¾éH`…Ñ'>Êß4¬�>äŽT‹¬ÌÛúGäµGÔà…$Í	ï‚7LI›u`žUJ2ì„΃79ç¯~f´lá­ÊΚìïW5�?|¸':U—.ûrJoÇÓlÔË5áAÜçxE ³º×ا‰3Ç•ÚTñ#åKþtâ•.iKW@ö/É›ÔÑ÷ û�j&Q �¦Œ²È˜¥t°Èð§Äh-ؤ1íý b?e¾™F	Š– ÉXrÙ/&Šjz©�¨rAÁM°re.�2Òe%ÉÍ£™6"�5[¹(H4:\mdb“™[i:ýP½2“�¿Ýä÷ö0JÑ»pÕh¯QšQ¨ý±�Q�ó_»Ã7;mþã«÷Aú^ÁÐ;Óèvñ¡Õñ¥ã«*’Hóß�¹,QëtT½�}…ÁbWý€�g”ùxÔ$Ó¬GÞ×™®'}¡uÞói õ´’D§ùõ; ¼xðÞÔ¡Æ°~.
°öâ%ÅÅ4O”˜»ª¡Þ»Bï­\ÿÆÈæ 
-†ìvm…$t§³ÎLd?莑ˆ+í–«I&VñZ"-¿35MGöÊìä§7À Ñ4‰>ÅauA×W¯½r‚…`Hã×W{Ûw1Û®­¹E¥^["W¬%BŽ… >«íÜMÑ#nNCuy‹¼Hû%Tž,TÜþ0]4.�ïdîžk0œPañœ„5ðYÓë�F–?ª
U'?Õ‹«žäfü¸Š·Ö¤qCr®až1j,†º¿÷2Ó“=²õáÿ¶D4ÏØeÊÀ¿I
Üóv¼vþ´
b„dîÿ¼ø)xý)\+"oÜ´¦ÜD1å�[|�)h$úØûeGUeŸ?õ¾†Ó<å�ízznKB†Éd–¬ö…Àÿò!øÿ
+†ìvm…$t§³ÎLd?莑ˆ+í–«I&VñZ"-¿35MGöÊìä§7À Ñ4‰>ÅauA×W¯½r‚…`Hã×W{Ûw1Û®­¹E¥^["W¬%BŽ… >«íÜMÑ#nNCuy‹¼Hû%Tž,TÜþ0]4.�ïdîžk0œPañœ„5ðYÓë�F–?ª
U'?Õ‹«žäfü¸Š·Ö¤qCr®až1j,†º¿÷2Ó“=²õáÿ¶D4ÏØeÊÀ¿I
Üóv¼vþ´
b„dîÿ¼ø)xý)\+"oÜ´¦ÜD1å�[|�)h$úØûeGUeŸ?õ¾†Ó<å�ízznKB†Éd–¬ö…Àÿò!øÿ
 endobj
-998 0 obj <<
+1053 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 1930 0 R
+/Encoding 2092 0 R
 /FirstChar 36
 /LastChar 121
-/Widths 1934 0 R
-/BaseFont /NHCECU+NimbusSanL-Bold
-/FontDescriptor 996 0 R
+/Widths 2097 0 R
+/BaseFont /ZKLPWP+NimbusSanL-Bold
+/FontDescriptor 1051 0 R
 >> endobj
-996 0 obj <<
+1051 0 obj <<
 /Ascent 722
 /CapHeight 722
 /Descent -217
-/FontName /NHCECU+NimbusSanL-Bold
+/FontName /ZKLPWP+NimbusSanL-Bold
 /ItalicAngle 0
 /StemV 141
 /XHeight 532
 /FontBBox [-173 -307 1003 949]
 /Flags 4
 /CharSet (/dollar/hyphen/semicolon/C/D/E/F/G/I/L/N/O/R/T/U/Y/a/c/d/e/f/g/h/i/l/m/n/o/p/q/r/s/t/u/w/y)
-/FontFile 997 0 R
+/FontFile 1052 0 R
 >> endobj
-1934 0 obj
+2097 0 obj
 [556 0 0 0 0 0 0 0 0 333 0 0 0 0 0 0 0 0 0 0 0 0 0 333 0 0 0 0 0 0 0 722 722 667 611 778 0 278 0 0 611 0 722 778 0 0 722 0 611 722 0 0 0 667 0 0 0 0 0 0 0 556 0 556 611 556 333 611 611 278 0 0 278 889 611 611 611 611 389 556 333 611 0 778 0 556 ]
 endobj
-994 0 obj <<
+1049 0 obj <<
 /Length1 1166
-/Length2 8264
+/Length2 8309
 /Length3 544
-/Length 9079      
-/Filter /FlateDecode
->>
-stream
-xÚízUX\[Ö-4�Á½p'hpw×*(¤€*Ü!‚»înÁ]ƒ»kÜÝ/çôºoŸîûtßîw«öZcÌ=æœcÍýíz(*r%U&3[ÐG[¨+3� 
-në3Áù
-|ØGè´£ÇÀNâ¨Ð×	éÛb®=R‡äEÚTBbCøª
¶DÞ¤W:›[öŠ¨$dEY%Š[Ót¼/oü¥¬½”ùP'û[Ä�–~�	X2­µc×42:Xµ{—%ÍøFSÓ]¢8œÞ“
’˜•G&$ÚÜ|-C­l7…�à›ò~»,Nv}»Æî,@HíŒÅfMè\ƒ•jLw~˜,r
ÿMüF]_©
-ýÍ8¶öOáÏoëÓ‚úïLîÓ¼¿œ+è¶kÎ6ÙA
Ý$=43Žºoô°Jü¨rOwVsr¶Ê¬ðšz¾Ž~ÿ²ºþëÁ‹êËõ-!蔄Wd=R9‹ò”l:VŽhÔïÀ³¼Lô
Ãaìtþ8QIVæy
U&Á¡û�«ü\žj_E‘{<ó�éYàôDËæúløa½ê£D–Îîç„xô�?¹é$Ì|’"Xûü"rø—Xu[ÊÚ6·èNâ÷�AŒ»®qmƒ½É�ý¢¹Hx7žMxÃ
_Õ[±½z
-¼*K«™Zú¹úÕ°×Wý¢Øø¹.ÔR¯�æESúLkéDÐ?«áäv%.
-šI-b´zŸŒU íÑ—þDÅyMß\…‹ÙCó«ïÓÖSätRR˜…$ùÛˆFy/Áê}äYeOÈZñ¸ÕÏ«¥¬øïc}͹ü<	ÂåŠ^úRX¿T[ÅgÝñF/yo\ky“Wb“Ë·Ú{že”Ã_¥b1‰¯ç(17•®LsT/“ks¸àýÄR–Ê8à׆h0ƒÄcsâð]€¡í"Z°p¬Ì¥`ÓTÚÕ¼��V£ˆ™×Þš¥”¾Îé;»WžÄi%(¶ØÄ5œ™,—»ì>N*�Yƒ?åïyÚóíʈfüλ�»²ɽø7ãáFWqÊZS>M…ùdT„Ǫ;£Qס3˱_‹§ÙL_¥Ÿ€(U}Üh-²CöF;5œ}ó�.T²¶/0žyÖ]±!3f\CÕ1�WR|#¯o‚Ǧ?}Fq?¯Óf�Ï ‰²¾
RŒ2Á	œðäÞ"#
-hŠÚ?åðP‘­�||èuæsSQ2¨•PbHRóŠêÐ8ꎜ¹MS^MýÜÝ´Ó›û¶ÈnØU´]IÜl(óš–ªÉô˜ÔpXò,Î%0Œ1µky„Òæ®qú§°Ä	ßÉ`hˆ	Y›½	goû[rð`jϾªN¸tÇ\®»–ü»bIBj¬÷¯Âµ^‘•H�Ý{”é·ÄÞê
-Ô
+¸'º]÷ñ@f̼ÀÜGgìdô—éËùêÛðFÔ!k£«Ã*.$|™/mßFàŽùyAO&—2Ö…Õªõ¾1Ù«<Žø+vˆý–­Dce�”­µEx`Iµ5úÐçK:™¢¦ïÝO�Ütó‡ž.erƧbÛ,H/«äíuåí™RrŠò–WW“OF3³gÃ)‡¬Då"\ßžâj��èßÓ”võVسïuÔt2C
«Æh]W*é„g̯%ä"‡È@Šr¤Bqf„�•4†Fóó<ÐP+]°¹Ng…8à„q/•ãȼ¹b–Òdù&Ê´ºdVNšùÞÕç6bÎN�é?ï…çPÒZWïn›�vÊ
-bší‘v\aۺΤ:×}¸½ø�Ú"¤#"tl~–ŠÂó5‚ws¬@ö|KéêyÏ’4%Óù|ô}É=ƒ-RK¨Ö{Öˆ“¤‹xwwa@­â©Ûæí‰ûÂŽKˆ0�oýwËŠµºÕ6©M8�³q¡ºïˆoâ³·àßYF¤i{#ØHjî˜/„†HP,9;]D»¢ôc¢bÓ*ÃzøüÆísüe¹ÔÊâ°?»ÔÎTùw}ãΗÊâÜšTÆýjy¡<w¹ï…ʼOŽ  âéMÉwï¿ÆUQ8øx¬È¬¿àñÆ3…}ð^ëaÑÄà|Ý’¯¼~¢Zw�(í
-kA,Èž¼ÃR*(^?�X5ðÙä,|í0&æ)q��¡3�5QýQ�”>1(`ãóŸ©3;çó~•�…jffl¯©È{>ë²SÕ†¬[ZÆ€ñí^m5
-îlúôü4 
}
-¸iÛ¬[
-AEÂiæ·Ü¾^Ápš¡¶²S�‹q”)ä—®}ÀÈ™’X¦‘Ñê	½ž¹I|&åYöd§œçI»Á~hÜ%i}ºZùñf�ǤXÂx,¯ðçÝÀŠÆTÀ;=ÝJi×î^‡É¦Öèz,€h?R9Ìó;@Öÿj—þY) Ƀp9:•Iß­¸ù�G«
-gwoÔЇ¼V}ŽCsg@ˆÑÕ†šÒm
^©‰iÙ;4
-ú‹�®fºÐ61^Ô˜±õƒøåiBž•1•ƒ—ÛÉŽ¸ïõ+üèªicöe	3+âòÖÛ'˜–ÍN¥ê“�7ðÉi˜ì§ï´½~2¤bêó²ãò½õþ•`×Êê¯áÞØC?¹ÕÔÌ=u¤ÛˆU¸…Í"â#øŽ\f�£N2ú
-wŸè’¡µ¸§¶”¬Õ¾Ï®HÁ=ˆÒT“³šÌ6X’>�3¡6º­1•üVŽ mjƒ3/7¯=Íôþ
&!nIy<<QDð"'É[nt”;D[sZæZÿÄŽ¥¾v™•8`±ÝÆfF—ÚsÔ|¯ï7G 9Î+
�?Iæ†]KkÛdìÓ½çÓô+(–¶ÿ5ß(äþCT°‚\ÚŸ§l±npOhÃíÜ@tþ¹�3´6PäUi·�QñGŸð*íwõÌx¿©1)mvj"§f6¦F0±ÎýèªêµÌY™i	õÞK÷òUQNÉ
g_;;C4‹±o­%bTèŠÍ†d^âFG
ÐÛk—W·>`e%aŠ{ƒ#0SÌ=²\:×Ñòz¤ØGàU%˜YM�çËá.žÜ�Ã_bÔõ~¬›Öw�ŸXöçÏ×�{7¨‡¬MÅ6ê£BÊæz‘×´‡ïÝpä÷¹QØì‡G2n2ªDö.×hE#£“	Z½¼Y‘ñ&ÐëE
\(ÃES¥cùlgK„ŽT@â91D±èc™×Àj…¤�Ði�ÞÚDÅëÁ»ÂЯ0Tµµ£bÅ$㪌íéyÑdö¸Ì
„ý�n&¢›\ ‹Hè^¶ÙôX\JÆÇH?!Ê
-F‘PÖçhé!ÍFµù„複ì‚4�ãE¢Q¢ªÈŒêË¿$Æ£}IÅD0I>àÅlPól&ÕFXÞáÅâ‹×Ž^ì÷êÑ!W‹ é·qV`ç¥Óz"!׌_j¯Ñò«E’µeä—QúŸŠGÌå«P•['ïkÈôZðÛ5%K…š�†Â¸ª¾àÛ㼿°è/©äGZ­�Ö¸µ²¤Ë›w� f§þĺ#7^•Ÿ?<Žàa¶Úñ9"	ç*‹æz]à•Öˆ·Ñôv–ý £-ÉTqÿ.åó%‚8Þkeÿ3¿[M£6ò¢@Gò‰ƒXúÞ¥çˆS&2ØŸjF[fzØ.½„ø'eCL`KI
-g.£Êù5õ\Ïc¯ªO]ffå,§m¾¼@+¬—q[¹ ,<¸¡ÎIPŸ©if8§”MIe({—Jœ~À$:­`š‘-éé;±‘¬y~�`²ŸâÑjr+Ö-±˜…>IEƒf�çl±¢ZV­®ô
ÛûUM½5
ßOÇRòˆœ�N@Èd£èF_ó³òÌu³Gö–l0êYiQ¶ˆrœÔÑeY$î9Ù
q+SÊbÁ9+²ÀYƒŒá—)mdA(Å”µˆm;ÞUÓ
ŠÊˆm-Œ/=ŠÉ?ˆ)CHÙrS¶Ô-“×ìª0Kƒk}öW­jõ‰9‡ý@F#iÍKû½D;¦$*µ±¯ˆ:vÍuš
- ¢6G4ÚWó�÷mq£Mo’¾íü0zt™žà[ΛÙóïÄ3ÕÝZsÆÈP:dVÔ/fyŨV�³Œ§²·ÞŽ%ŸðG5¤ÆA«ÀÞ«§hÏ}Kœ¤=ª4¢a3¨˜– xMPn”ªÇ#qp´ų́çxk lƒ<¶ä¥ùÁãÊ¿�aLÆòË+&ç0q�wl$^dnÜðy(ÙBÓ¶ûo‘#@¹×M±®@S#8±CjQðç}
ékŠ»*lí,¡�µ=êï�Θexí¬„¢h‹®•ëö¥°gЇ™N¬/U
tùM-w*Û¼¿<ý\ɽ~,($ۥDzÁÏ5dèrР®Êº=¸’+•"‹~tó%Ê�"â…,iãä,
-û
-àÑè.šoÏx­g6åëÚ†ÇËVDU±N…;ZÆÒ5oùOhú­—Ð>IîÌ:h^�$¼Ôlz×ÚÁÓT	@ÿ}&YƒHõEŒ(=‹qåö6õÙ¨ôW=wš’xsDs‰¼:ŒëöÊ-¶¿{´1öFi”"}±FêÃLf_ÜÅÅ;FO5æøþ|y~U¦Î ‡ëÄCš�¢Õ„’+ê´Èø–u{Ó&d¹¿*¯’E牊ô‡Mâ‰t/&%Ï©H6ÛÒ¥Š‡¬GJ×:Ìøö•¿ÒÒ•ß:–”eˆº	—ýq«É(LdOÅ"^$·u1§&j¶ÀZ¬
-Ú=;ˆðá:ØÓÏäÁÏ/én¼¡,*¢`\ÜäK}["ÊHTÆÞˆo`ÝÙýz„N¢&j¸'µ2ó‹|K×c6Qén)'	üÖœëv?.ßüê´–®PÌ£§åZ]GOŸIªvIbŒµ³ÉЄH\Ô‡óÉ}vÆé¾°å1ù{'¾ógâ݇ûmœ‡½*œ‰VákÑJÃÙ9ÿ¾�<§µÈ
i¥ßg
CL⦇X
±rX¯=Gó‹Ûìö.BÒÓ	oû~o‡´~8:_ª˜WzåHTº{‚,×d?u-ôR,ýá²ÍþcQk®‰î•üâŒ'ÄݹQì�ª¡³¾§�Æç‰g\&ÚQ„#J©Yð#Õ²á[ƒ�ËEßE(@˵¸x†üœ³/ö®:g]!$…US	](%v¨	åÑÜ팼`‰jî&^Ûœ?-ó@öùàjÙ÷<³ï�lY?XRr$Š™£-ÑTù†~ŠÇ/0‰ÌB¯7Ù×ìYSB{@&A^UEs	$DH@
-٦ϭÓ%"Òð9Ó
--ý¸Bç
hµ0ÊnnL¿ñE~„éMÇv¡“LYd< gñÕ¾ìQ±í�Å EþoÉ|Ľ„\cvê´
-Y	

É4j"¼ÒÜçÞ»6ð¯ø»(~7qBËb“½L*&=¤ö4P'©ð·@Xáѧ†÷§€R§ ÙiîÌ#k]3§&M<~èêÆŽ¬y×–=¶÷.Ö}ìh�"rr
²Ë«À±æ<³$wt•°CnEÕ@�¸*ùwN.߆Z r™LŽ:øõŒªOâTãPêŽ".!ÉMù?dð<Ÿ½h·Õð¯=B­›B]	oº×dûJèoÛ°Æ°­TFØQêP¢úC@qSÁÅùÖ÷¥7_±�¸Ôˆ²»ÞÌ3å�³_Ž¾«š’ñ #¼Ì‚�
¸~sOsÔ|ùƱ-J?§>8�_@1.æXIg5ßRic¹Rc
+/Length 9124      
+/Filter /FlateDecode
+>>
+stream
+xÚízeTÛÖ-–
+Ìj +às�Û@C£
†Ù�þ~Ä�A¦0°DÂöŒkX»
+r¶Cž!	s{¦îâèhY¨� .Îæ (ÐòyeÿY(îàèá¶²†
é4Õ´é™þaçååšyü…
+²spü£Ò3…4r~^´Å¹*–¦’`Øíé¬a0G>VVGKSÐsŒjÉ
ÁXéŸ*	±w°ÿƒ
+øC3	°3Èü¹)Ö¿ëfqpƒxýGØ±ø³%GVMØÉ$+ñ?ÉÏ!À¿bV �›�ƒ�—�r‚ÜÍ­Yÿ(©ááúdÿ#l
+±ðörtpZšÚAAÞ`KÐó
à5u
aÎ. o¯ÿø÷€�h
6‡
Í@VÏÛð/öç0ÈòsES˜3بÏÆÂÆÆdûãÿÏ‘áó†Z8@ì<þ•®dj²Š*ȨÈ)2þ½÷f‰‰9<S2³¿ã2s¼ç~vÊ3#/7çßÿ©Å_:üU1ÿÏ:ÙþE)±t
+ÝØ)[7q\ä딬Ÿâ}2Ç”¥Wº4BâÃ8êÁø¾d7z»{NÊ/IÈKsËQ•÷fèy	eì|Tù^N
~“`³	IA“k¯¿¥•ÓC«?¸Æ-oÃ1™žéÃàö�
+–ÀªOÌHt‹ßñ}n縳.i±¼«tÌå–ã4t\dêÍFÔÏZïÖEη2Úú`¿Lè-Š²FsŽ]Ä!JÞlø*@�çìwÓ>ׇ&ª©æˆy²¥@¥]kU>=­rEÞ-çŠÇ™°V£¨ÙaQmL1!h²R%^×àj¸Öl;Ó�Ûì^R‹
+8ÆßÆûOv�j(øÏñTÔ¤\¥+Ö#2\…¿n5;ÿH¯i}¤ß®£Ñå~º9$m`Ƶ'4É)ù6b›•½.†�e
C[•+ÚËG}*”µ>A¼­dÏGæjøf¬%€Ê4ìªÉ�$›�ŠÛwÃPoÄd‰÷ú´ÊÈÓƒ8~Gžõ‘÷<Yqðæ3z©ÞÆ 2[¢ÉIJIH>Èe¦_h‘Q¤Ç�‹×g\<©‡3Ñ
¾¯òJ­’ûÁ«‘e‚gìºN¦bŽO+ÞÀ“îS­™c­Hœ�4ÞCØKH÷²m:§dÔ’�ÆC»t½€!…Âæ©.—IóÉ^!Øæ¾Ô�D’ZÐZ¢˜ÝËMïQ•¦ùÜ�ȇ®CÄTÄZÅ‚zŽz­‹Ä#EÄ7ÏLm}.éF
?:�ÃÓ¬v­Ä3*ŸH“¾˜sLfZž�Ó$Vf‹B4�®»%DÚ”6òÛì!Ó7ôRI¿S{ŽØ¸Õü	ØKÒG;ë¢Od€V@Sp¾¿–_
+eÀ_±2äÀéŠê×Ü÷qóºÄÃfhÙzÇð#e6Pw=3vd[¼¶#mýç;±ýO�߇P÷LèLI
Š `ßy·b�gh¶£ûô•À|ª¿2Õ1äÔ@ßXˆãàç¹ÒH_Li¹=YK/0¯§E	ÒÀ(èù\²ÈÖ«:˜ðCÃkX[ÐBf	µÝ÷l¼
+¥ô€áëÖKŒ×m5X€>Úí�À½æØ™Ô
„(QjiVJÒ˜˜¢�`ßÛCÄ9UoðzÙ„íÖ�ðWvªD+ž
+VËkþy…Šä]WzÃ�È”}ÑDE\Mó�½}ºŸ	záuÙ Ë
+�Ec'b£cƒâºb+�"±¡ežê±3<}MëMÖM6À–è¿ùùn¬¹˜¶´30ÿ=
ùƨÔc¿¯¸§šŠQ½¤
+cª†O\—aðIoìì}¦êZzPoë
+Û¸Áü—%N㞺°Åøjâ6c¹×tÔ¶­æ§dÆ#Ò�ÎIî!QLé=+£oì·Ìl‰Hžñ�
EF˜‘gr8™!söw’RZ¥÷ªëEËpÍxé(R”Iã½E£"ŒÖ!$ÿŠ+3þà\aø-ñ^Ønàêdb{QÉ°n«D75¡¤Ý`:4ä¾é-TËu—6"Ä;ü¶·M9—sïôñ«£#ÚO1èÒ{
!Ìá8„‚_Ü2ähh.‚LjÚq�ÍŒè• hê1€RàZlƒ‰N?Lä&ÍÀ÷Ý
Û@Tý¾‘VÒb\0í¡ë0ÿª…É0N‚%»î•+1¶•Ì1ÁÙ7Lûêš_Ô>X–ÙG]td�1KâƒÑŠQ¶SF$‰·U¥8:ï¾Ó5Ÿ½OÜÇ'vp¦3gGp|wã›À„J÷Wó¯c¶LLËFÊY7pŠäh·nK.q ¥'Œ/®Â9bŽ‡±Ïw9_2ÇÐfÊê¶VWdÞ·�¸áË™
w7‰œ"Óù}R4T˾jVø?âó~:Ãí1~uÊæ|*€Ó”ʱŒ«HÂ@pÎúNšú	7¹á8[³?p~¨y4Ñ5r€»ö£õ5C6Œæѵ,âM˜“�Õ�QÓ8®‚ùÐùU7
¬Ûþ§>S+zâŸ[VÑUŠ<¥<
s²Ê&:Nð )ÎI�JÀÃTãÃX×ò
+ÓsñŸ¬5ŠN!úŠNÌJiJ¥…+kkŸÏÆròæ¢ßÛŠ)Äx�žcé\Œ>Ð~í.í¯râ<èªëf�׌Óy¬VÑ‹ÌYÝn§ FÈ�KRd"1f…U´†ÇŠŠ”> ¿¬öH‰Bç9Ÿâ‚â%¨„$‘ûò$,gÊóMV0êôÈ­ž·ñQÔ‡‡´
+åƒb�3èu¯ÃízSHø”Ç!=ÐSV«ènÞèõÐ`åÍ’ª;qg?Ìj†o+ÌÊ€/F;=!`ž· ÀË!¢Ëþiú)�*z‘�ñÄïø.ëœØ½ 8Òà4AgÉ—õ:fÞv\JÞ�
+L^e°ls›Näº�Ô§ßýšR6úù¤Û°éµÁkkùéÓü½I°±U-«a¾r�BïñØ;e9Ïx¡‹K€q("�Ãßj¯mµW.~ØÛüÔÚuf«ù)ýûU=¼?R‹ï7éÙ5ĺºWéŽò¹ÊaÉ[Ð4Œ@Çr�ß�g|óy¢X–%}ƒ	_l3÷ó*CÈz:â0ÂÈ(PóÇŽZÝô†vÌ£1Í5KUFêçöóÉ„¨Bß¹DóV¿ý\öâ•GþÐò$uI“!š›*«±5í1
ÀÌD(©u›P¹©üò®¤Ãóãõ�€2^DõÚTnÀo—£AÜžÈ77lŽ×�¿2+ó33£‚…VØsùÜÁ&ùK
+
+	×�yLˆßº§(Pœ(4Ä3dBmÝkÇ–?v7‹]çì£PܹïÏ›ËèÓ}
+ð(8ôðY&Ò”}„yäÖ5ð±KêÑ&Ek)Oá†x°ñîs=BˆFÆðïDœxѯÁÛìÍ㓶‹]Õ¼ô½ÓlIÃÏ6<<*°OÖehÞÁ»GÝ�„1S¯¿–Z
+4;�
ÃkÊZTwïG¶¾htû»Ï4êªÖR¡Þ'­ DIn>˜Qâܤ¹*'_I¦äÆ6¦æ>»\<º¿UQ,‘baà&�#ç
^ËmÛÝ[oâù$Ç©e�$ò�Ô�qµ=¿=jYÄPs˜³ûD<‰™*Jß–¡£fo,_mSBºØɾzªS Q_øi¼ÔR@¯KFÀ®+µ™øìiåÁMwš”¶µ<ñiÒ^ìjg–Öëã~f쇬òÑK§kY¤Ó
+
+j¤¹‹4;X£O<eïc¯¿ð�K’s…]�䆎sÇï#ó Th�äP•©îyÙú¼Ø¤×	‰"i§¿wç}¨Þ‡�øÛ¾yI¨A¤ÚáTŸÑ8{Z/|&jêãõ®Ý>]ãPò÷2×EQà{‚°rëáÞ8,~;;ÁWâŒ�įFõ9ŠCá•
+j[ÕeÀUoóOõe¹#´M7îL°”XËzÛƒñ…Œ‚´Wvû¼‰¼†Æ«<¶eªhYÃ<ÀæþÆêè²o¦ B‹Ï¯¢:YAW󹄛é_³óöÛЛë7.ï.¹m{(Az>oɧÊé^˜ë@Zc—‰7*wÈê
+›»WVö]°dÙ®ã\öý™fÛµ‰t9¶¤V}îñ�ìÝØì¾Vᱸ¨Ô3Z(-ógWÎÃ	iÔ“g±Âî1µúnG¿Õi/Ö®aª\z6wH5VkÃÂXŒYgtýSH}vˆqé-ÂY/Dbø¼ýdyP8s
+$RÇÌvé…h'w$K´|†·í…§™;Y¸ñç?óg�›+HGÓðF~pQD=YwW´äL;v£ˆ§&Ì3p}OG_½¼¯2y¼¢@Õï·URåo<õ4"¶ÐþÁ€àþ2½öÝCI;¥ €)ª¤ÿéì¼Íµ¾ZnùˆÛ„œß�~‹øŒþ—¢@™ðÔ6!†%ÿKu9Èš¸ØA`ŸÊŒa¦	±¾!¿¯yÙ´FmîLRÂöqu8�.ó
‹j5Žó®Ö?ÍžÉÎÅ¿ïÅ4‡ôc…g96·¼oìŽ~¬ðBGÆY6-¹ª…M6õÐêY
Z`–ÄR:´t‰¡¼JÆB	ÂP™\µ�ÔäœöF-<u¯Âû]ÍÞ¨6ÆÚÚ”u0ÜôæN;q3ŒN³Pq]Øw�'�çjªóMõÜA0”‰R‡Àâ=ù
é.Ùèí'wÜÒÛD†äúŸu®ûÍ£\y6EGíŽC¾ô/èÆbIÝ72Š#ÜrnTözêñ k7Ó�b’Q|{wy™ÉsŠBd‰êqzðõåñ·D‹�,j1^U‰pðá—‚[v�žgVD#vR…ôz¤uí3íë œ¬ûvªÈ¤©³q.ÑA	øƒ„£Â«|Ìon<oÌa�J‚P4„¶@“
�bIðò)R!%|rÏOì6&Ö¡‡Í
+s–¬7ôäP"sÌœ9|p]\ÉlfÏ'ªv7K¶iÍÕ$¸Áî}S[ÜVK cب0D×”ê0Ø5ò«¤gitËZhg7ñí­¢•dÞÚÇ_ê¶~XD¦pô§Æ%
=Ñ*F꟱–⯹ߟþžª+ ýê»\~d+GÏ�¼%OÙU2ª©³g(÷|˜KÞ8åº~ý=M¿¨U�;µ
+ëAv4>ÂâÉb[&èëÛXåõ‡ R'䄉¥ü"Üñý"É)¥F{WqÜj³‡h!YNéðˆ~~ò"ÙÐ5Œ©»Xçà ‡‹-Ýxä%ñqÉ>ÿó1¹rP*#7
+¶²çìÞê’ñ¬Õ(àmÆÊÞš±	~µ�nH�
¤a0³•JT�½6‹’¾eËŒL£õ•ÃSóM <zÉÞ7B“Ü¿‡Ì�/ñd=£TªÂ÷!
Ö«7#�.lG‘e‚ª'6;?3n*Ì�ö{<^iÿyŸÇ5½ÆL
ž›4Ûã6P_††
+Ëȯúô$šü=Z¤ïs£öjïM ­�È"±óBc!¤d³£©Ëb”ű‰„g²@›€³y‹u
+¢ï
,Ý™Š£°ƒûüµ±ÒI‡c&”ü¼ün®'ñ°~ÅH¿ßýø ‡é+RúŸRû��#Ì»’ŒŒ[È1Z‚«„äî<úüEþ„þ'¢DEPˆ¨½|”‘s¼j#U(�»1é�·–½,ÝÓ4Ešç×ÜWŸuÓ‚S{:D¦àæ	}ª¯ÏB%Ö^‰$—Y–Œ8Ǹ	%³šc&h˜!ç¹ÙG£ÀŽ–+([;3ˆý¡ŸA`´ž°ç£G°øªlV˜SÞRÿS”W~V'¦—,É*ZÊÿ�ëH™­>FþrRZ§³¹™ª$@!È¿�Æf'%N¯Íqg'á4¤ÄÛeù+¡D
‚A¿x0J1»ôÖ©Cøp:©¡Ý69‡Ñr;�âš>ã|º‹Úˆ²;h“Ùé gÖÐŒíõÒ½Ó’iH)è¿iŸö&Iû RKÈÜ-‹Åx°VÅEc°ÖH·1ÁïX™hF¸íµnQtCç¬``*<L5f¾ž‹•3®h¥ÞÞÃI‡€Ú;¿ ñXú¡}JlZaÒÝO—˜‹�s1ä¥gH—Mî\åœàdH
+_„á}<É!‹à¨'…K^y‚ë:­C†j½Åê%½2šI‚£DÏ�µé¼H
+Å2ÑÈùðîì”í
êzTóM¥ŸýØc¶ªáq_Ø™
 endobj
-995 0 obj <<
+1050 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 1930 0 R
+/Encoding 2092 0 R
 /FirstChar 2
 /LastChar 151
-/Widths 1935 0 R
-/BaseFont /GNUWIN+NimbusSanL-Regu
-/FontDescriptor 993 0 R
+/Widths 2098 0 R
+/BaseFont /ALHPJM+NimbusSanL-Regu
+/FontDescriptor 1048 0 R
 >> endobj
-993 0 obj <<
+1048 0 obj <<
 /Ascent 712
 /CapHeight 712
 /Descent -213
-/FontName /GNUWIN+NimbusSanL-Regu
+/FontName /ALHPJM+NimbusSanL-Regu
 /ItalicAngle 0
 /StemV 85
 /XHeight 523
 /FontBBox [-174 -285 1001 953]
 /Flags 4
-/CharSet (/fi/quoteright/parenleft/parenright/comma/hyphen/period/zero/one/two/three/five/eight/nine/semicolon/A/B/C/D/F/I/L/N/O/P/R/S/T/U/Y/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/quotedblright/emdash)
-/FontFile 994 0 R
+/CharSet (/fi/quoteright/parenleft/parenright/comma/hyphen/period/zero/one/two/three/five/eight/nine/semicolon/A/B/C/D/F/I/L/N/O/P/R/S/T/U/Y/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/quotedblright/endash/emdash)
+/FontFile 1049 0 R
 >> endobj
-1935 0 obj
-[500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 222 333 333 0 0 278 333 278 0 556 556 556 556 0 556 0 0 556 556 0 278 0 0 0 0 0 667 667 722 722 0 611 0 0 278 0 0 556 0 722 778 667 0 722 667 611 722 0 0 0 667 0 0 0 0 0 0 222 556 556 500 556 556 278 556 556 222 222 500 222 833 556 556 556 556 333 500 278 556 500 722 500 500 500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 333 0 0 1000 ]
+2098 0 obj
+[500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 222 333 333 0 0 278 333 278 0 556 556 556 556 0 556 0 0 556 556 0 278 0 0 0 0 0 667 667 722 722 0 611 0 0 278 0 0 556 0 722 778 667 0 722 667 611 722 0 0 0 667 0 0 0 0 0 0 222 556 556 500 556 556 278 556 556 222 222 500 222 833 556 556 556 556 333 500 278 556 500 722 500 500 500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 333 0 556 1000 ]
 endobj
-969 0 obj <<
+1024 0 obj <<
 /Length1 1624
 /Length2 8579
 /Length3 532
-/Length 9443      
-/Filter /FlateDecode
->>
-stream
-xÚíwePœë–.îîNCpwM‚»Üh ±†¦qw'H°à’àAîî48A“
-‹ß5á\�ãb�­Þsß]v”Ùv»I™»Ò@§Tþ/X¿â¯1µ³ï†p›•`géÇùžÍªn 	ñèín�ji›}ü�B=ÞÎE;»e
záQDÄpã‚`•^ÿ–¸¯Ž ¶èûSÊÁí
sßÐ×�þ®ä/;”ì¹oÑÅ=�°™bƒ\s)%Œt+|£^Ë
�àcš¤H�Ó¯øbD{ˆÂÓ®hå_ãO•Ñ8V§%Ål¢¾Æ3Ö`éT¤¼‚cØÄÍùÉDF͸
wvÎ%™îåH%ãc×ÊÎrYÓÀfhجØ
³_Ë7åCüUœB>þ¾o¤
²:ØÏ Ô÷¾î}'CL!Ôk‡»Pôë*/Ìò[!
­â‚Y?ËSR]¸
½ní΄Ê~ŜŽ#DiþqõÒ�i!�Oï
-ùÊaº5B
Osö;5¤²nÛ®”‡1?ß×!¶Õ¼Fä›`¾EïÎf%¥üÍNJ]Ë`|
ü^VÒ#5“Ù>U¶,lT*$A�6	/WÍo¿D)9A[ßÞE�»¯oOäÁçeˆbAÔ²²O,m£a’ «>+^¾1AU«Ôsi¦l›sÚ(,ÜØV¹ZùF§­#â=Õþ§‚[Fª½Ph7Æ�M&âCo#ù»¤ø²ù2y=�õ)êilºGôÙO=?-íw¡ë#Ž'a²—¥¦
4#¶š™5-+3>S¯áŒÌͱæEÆÛÚ?W«EAì/6sRI~ߟ¯òÒË
-g©ùX½—ÿˆN|)ãÆs"•AàÂøžÉ&?®}߳ݚÀG¦ãkx%cqµˆ*Ê„þs#Ñ öàH_líÛòþЭDò.SÍò2µ¸‚¶cô~r×Ý&¼¶aËnàbAˆëàö‘·hàm|¢MæHvsºhkõ«Õ‚%ÍÍsu¢©¤¡Ÿ“=l¤´É¡¾4Ë_œœÅ¨””Ò8n“9�1Vh½#àÛµ-ÞTöw?Y¢Ô§¾LÑÜõÐop+–¹?µ­ªEzƒïê'&é�µ'	´™öZ�2VõzIÁ¿Ò$¼yíîRÿ}�LÎáP<D°çœqAì%ÿ'…Ÿl¿Þ�wF'N,µ…¿Ï™—}å’cý)á)nc´qNhªlâ%eR=ZøvF"ãÆ|‡é�Ìsr
-ª:ÚÉú/Iâr·?UP›…Â…ÆŸv]NVûsm72ðVó›ÂÞIš*c1+³žrwS1&‰÷©�j¸·ÇšB—ëïÔÒ®K…ØŸ±ci7úRëY‹Õ¶GKÇ�TàÙ¼Á,L
ïTü© –B�7ÓFCÕýºPñòÐgûjœ­È6¢Ð3Ǥç+$سÁãäÖ½oИUFµfÌW·jæÇ5UrâŽ_•1ЙÈÓMm²OÁâË‚ÑN†~öò¯_¯³ö ió%O·­ŒKÐL°@D¼žºÕãöNº}lÚCèp�h¥ÑXÍw1çéJ2²¸ífþò'ÝÌ�p’ØA:ªöÉÀX�ræô{ïA{êg*PZ‡Yt¿ŽÝZ?ÙõúPÚ«p¸ýEªÇ¹þ©ðå˜ ]	dîôŒxf ^GQÞWFNsµÞý¶	
¬8uIÔ¢0Ÿ®µômºwʼn«¿jD‰ó>Š3”×/”})WCÄç^<"Ô¾±®ïÚáÆHýôbºY‘)ù O1€öúÊø½:†æ‡t�У+ÕÖ7v
-\F	P2ç´¢•ácƒÑ‹Ù‘…rò‹'ŽÔZOê�Þ£ÐËT5ù„–ämýÂÆ¡\ƒO¬nÎhY¯ÊT£˜(3‚'Iáq&ÝàL‹x¸8'`‹r›—¸]k�ãï²—8x¯ô6»ŠÝw‹®A3‘3hÉÂä'O,˜G9¹5j v@Í�¥×b*’ÅI
œOb?¬ÐÔP
M%gxWªIVÈ!ñhÅÒø['¯¼¿.:°ÅλÒ6ù€@š<.œ»M=b¢³G<Éžb©ÎV逖4–Hº·ïK¤ŒS»7àâĺq›™ª�””Óx`�Ð@[{ù®Hš€@8ÅïÏSAø²�ýäʲ½e#óòœ‡)P'dÖŒno¸”]`ú›Ð/ý»„ª6.˜²;NVßn81—hL°g/#³†õ½T5N•È&œ#kX�Ò·Z‰[¦ZO¦íVñ¨ÖŒ[ŸÓƒá~‰ò¼/×èa¶î^"’]d³¨ˆU?c«<œ)´ NGWŸÓJª"Z!ÉÜžo½¥I´¼½g:>:ªk{ˆëçÈ	Žœ}ÊÌbÒ¡}Åó~@ó±F|íƒ-˜(��2.°p{¶šIĨËq�
þ"AßEðI ý¼Ë¢oÒE±ã‡¢÷§Ðú0r¿¡þ�â°åÅKŒh—W‡ÃégäË�C²},7Øzíå¶[D“ð§Ý÷3ð­beÖz«ë{çòCŒⲯÍ-kÛÓ~µ‘ñQÔ;¹F׌~Z¯r[Ÿ¾ÖcOSô•Üše
 O4CwT(„¨]§kfž—zëd̹:E.g3G5Õ_üIA…nµ>Ĉe! ªÐ½×~sýücê{�?ê…s’.âÈÑ¢8é+û3FX©wvÝ*—n~	,!PÁzc³ÐMÕÁ—=®“@
®±&Ó/C¦ì>š�#ö¥X÷Þ•ß|/"rÈÏÞJð‚WXhÕö13/¾¼v"sõ]8«{¢5¬•n/ÁîÄÌÖZñÛÕêÇDßõÓ'R
-­)ýHF	º6Y~Ûé»n{0òiSÖ^q _±ð¦ÀO¦îEþ‘”8¢±7_'š-CØ¢bùu]<ÉeA$o4�¬ÒÌ)¦hÔ?úõt’†:öª^m™]IçoÅÙY�?¿î(g‡$
ÀOÆs[ìKÍ÷\!�xóI‘s/}©¥¸{•Äb’Ó½ä>‘b;’|†_};ËÈá—´nT
-ƒPÒ€m\ûVO~LDiåÍå¿Làæñº[{Ú2ÛÊ«ÃÔM–�7P)‘�uJl¹!{øXq£‚ʵ3f+ò¢,˲�“§eg·î+lê
šÂãEfqrqv±ç|ý{�EMË
5ƒ,IËrévÅä›ß‘¿öoX�H°íxBâ‚Æð’ESyŠˆ»O‰Ú0r¨Ð¾/�é¹Kš9+¶“Ò/J½[Snø¸›°F]Sç?…)Vž�›r3WKn'Â�S¢Bp?o‰ËÅ„¶DkŸxͦ;é›!dœ\Ø)ª+þ�AáÓý¼�+I§…Ÿ Â1/ÒØO±}¦L�hoañf¢yÉYnÙó7XîÙu®DBÈ_ÞI‰^nù¤úóÓÝ2«�Áé
-hãÓ‡¦øªB“ÞÉ�,
-M…ߎ9_³œü§Ó©7\y9Làbf
Lý”Bãôžå˦fð(iÚB5ö±¬r/Ö@¦•
-/ôÙ°úQw�.#EœêhüYУ„%UÛ96‘iYÆ·ŒÌï\]”¬®)”ÏâõŽê£p¯ª, ¹ESIªfs èLü„Ü#€˜ð�5õ
|ºóX�ŠÜ´Ñ;1*ýó$]˜o4^|œÖarAG–´@îõ´\ph®«`�­
-ãDáð£ìÆU¦1*]	ÓýQ„dl¯}ߨ¨7(cKqÞ9–ã¨[k�wOŽÌ|ö$·¨íŸí«æ|sŠR¿
-�ÞgÔ h¥%Ñî›!«RèPêé]å’qh”ö$Õk<©6–ìùŒ“=Ý°ãs8Ëqçsïï>®ê
še{Þ1#ìgŠ²8egç~¤’+J˜gÑ“¯©�²j>�-Z’µ×v�i™4/CTÊ´Š]±‡|ë‰
-)¯…=ղŻ†â	&И2Ù‘)„j‘^êK¡„4
-uHöó¾¤Ç|X(ÂÎiá—0åÁ¯ýîׇ%ɸìÚƒ]~2¦ˆ8­¢3¤PBþã^äK,l<0�‰”¡ÄºwRÃÃRù‰Ú—ÉÂ	I³OFAãÃI•�B„íŒ	Lõ¾
b­*ÒW{pͦa¦öùŸÙÞâdW-Ë'ŸÜH£û´Í`7$^¤©W‘8�z.êЋü;*Ö&>0A̼I™µØú‘‚ø3àU$NõŽoíeá—·©E¥¥Ë°‹c¸3¦)fõwÖ.=£5f–MmB]7{¾ùP5/‚–Žè';n¬·ÍýòøŽ—D¤ë"‚ÙV+Œ)r‹U˜5ZV
%En‰y\kºsóL£¸;s2¹c:ÅeCÜ�ñ—D³Ùyò뵊²:ä¹iKg(Ç3æxb6^<§a’
êÂ¥\9$Ä>Ša(Íâä£mˆ#ô}ˆµ˜±®uS%aéA²çÉF<ôÄt0côz¸
ô(é²Oè=wÈF£>yN¬F0‚®w9¹ê	Ñ!ŒüâUȲ­Áô7ø÷ó\â‡[äÝ,—PÞ\]Qé÷·¨ÈŽëªxŠ¢é‘t¾£ã‰£ò;:�2öø²x‹�{e@
-ø6Uu^˜ç|�:¥ÔËíäð%X8ä—@Ö�ONÙ™¿°
-S
Ò±H�]^åí?ÒS”:j>ù^±$•MËÔ°Ö~�¨ù®Ó›¨òëŠÖhé¸Zêî @­!5“Ößꦶüþyö{¶=êÇ{§	9¶$â[Ùo„5òѨÛç³-ïoGóù/.	ÈR+¿”Ûû²W}˜x÷�aî¶bK‚+52gõK䯰’Oß󅤧d0ð¨3”âK9ìºXÃø¹Ê'=ñÜdÇY–µBø
Üc‰­’Þ�RNªzcÐØ2•¼eཙüœ/ŒB+‚YK°>]3çÚàÔô‰é(±œÌ×
üq]ÔÒ•h»¦éyù>¬oG{åM\4Ù™§©	ÌÔîå«îTäfo¢d¥SʆuÓµ‘´F”T�/¤*ÜÄ"Úé‚&‘v”gHæ�ÅBY+*z âÛ“kȺªñŒ¯W¾q ¶Nr1=æÁ{F³N·>©)‡kêøW}À{×.¬´;UBòœ•$‡3/ï�twG¤òt$qËoGćâ·éçë][
-‘mv¿`€÷˜¶”¬d檥—ˆT®•¨U~Ì:¼dLTФo*`›ð=Csì„	:Ó‚$G£C‹*zÒÛüªˆ�ÇzY]R?Ž§iÊ­6&ldr¹á}Ö¢�ç2D’©cŽ–RŽ½4õ1@@Üzå©jF
¿Ê%™RQݤóvš•7Vi4(Á¦�¿ o-ÎË C�
-È<S
-ò`]Ÿš¶ü]c”¡S½‰Be­])Àžm''Îk¨%æ:™F•øô3Ñ‹*UÃzçF¬›�0Þ‡ÉůÐæÎ"³‡l„nû³OÚëV”<ûÇtJr!˜ò&b,Ê\Ø°–=“QXåâã�ÓÄQ(ãÌ0½ŸÀ‚5®&ÉáÁcLçÏWá]¾N”jŠ¢Ñ¯+#„‘J¡š¸FÐüÙÌàþ	jîòCYLƒ�5”h"‹ThîÖå
-Ɉ¦/�Ž5C]K‚š¾&ÆëZ~c‰ŒÑÎ Œ/«ÙyE <Yô$ÔÿMðúÿPhÉñ"¢–O߀KvÅ
	†
MQ…¢f`�÷væú±BÝ#NA»é`7aÌý钲Ɣ K•{=‚0ê]=	v…;ŽT³wz{b×ôqÑ	™‚NûbîE?Z½ ‚˸¯ƒÉ˜2\qÄ‘ž2_ŸhÀ(7„÷7Æçm
-÷ÅžA>Œ./–ûš¡�`¥ßV¬åÅù=uë�sôŠæò‚~ÃñQß‹?{Ù*.z{ö­`!ŒOÍžE¡â‹ù'™Ï<LõêoŠz–»lfvùt®ï¶6•�@!	éÚñ´}›¾z8õpƧ¤˜<|Ø¡
-c.8=ƒ¹-ýؽ`硈‚Œ/>mQ5%ä,fÝOýjïøÖî—_e^Š¬
-ÒÆ°9QðÙsý‚v�9êÎu12g‰j=I^Û¸å<¦¶±q;~?”,
-:Ö¯}‰÷v,}çx>¯‡j+’¼ ¨XRÔi q8;­‘½–„¿¬Ÿ6mF\©%šÆžéƒàÉÒ�i?6‡/9ÒiHö^Å’ÕÃ&y{&Ìe$66Úr‘oMí’ÉÉ*Ëû†±	õR¡ð•Á¯k7Î[ì…$"+•zSàCz¥ØöUP‹µ;«3ËP:1Ž�.ÿ
Û{‘q.ŸI´¬o^Ã{ßH¼÷ê£LMëV¢Z@eð»¾Ô•w^6'þƒ¼¾
-ˆÒ�—³AÕ÷Üì4*‡
ËGFO„’P°Áñd‡�œ¾×vu¼v£¬}  J6J(c�8'Nj×mÕ‰kݸBgdî?PPÐuȈŒG/ýTø›!ž|¹$dKX]ò6ÃÑb~þÝäÄðå²W/]\î¢ã¸;cùb•zÿÔ�9¿ßÊÍ^Ð`ö¶¨«QíÛ$
ÂÐ2Òn«Ã­+³Çø/Bîr/–YÖmí‘×…¯ñ™I"Wâ}-è¨>¢×6n#°Öӧ˿ÏT‹YeFÚ@ìT‰¨Ç¶&TGŒN·p/SòÖŽgzaN»zµú8#Xáü=ö6Œ¬ªˆ§)xû#YÄ)´9pÍd™"üF‚š¯€ÉŽ÷Ó±ü—j" F!m:™­•0./1S¿À
þ4×<¼ý@(°tÈ£^ž<bâfvßf£ZÏùÌ6�G%2À1-øu"
gŸü55KS½©¥ÛX'ó”±ÜIlÛbßÖ.’Vð*£Ð´Ëk,nñIl�ìØî­ƒ|4xn¸·"‹p,€˜,©VÞFôkÍ÷™Ÿ0¦ûÛ~ĵ·_"muFÛF�,V¬+×)ö³1|¡n”"Ü3÷QÑjªßõ…°^rÚŠ
.áÓ®ÓÅY¹YD§HÚ
-ćPí�ˆb}Õö#çù_~0þ?ÁÿVŽ  qB0þa
*endstream
+/Length 9445      
+/Filter /FlateDecode
+>>
+stream
+xÚíwePœë–.Npwkîî	îNpo �Fº¡iÜ‚	\Ü!Áîî4¸CÈ�½ï™3uîüš9¿nÝ®ê®ï]ÏZÏÒw}ÕLôÚ¯¸dl¡Ö E(ÎÅÇÍ+лX{¸k@!ê\²Pg[-kg0à	Âdb’ƒ�€p0"„ƒÄ
† [€<ÈÀÏàÃdÈA]}``{8€U_×��ƒƒóŸ’?*
+ÿ†‡;bÿÏ8
0�=fërw¢yâþS�æ	ø/Ù]]�}þ²†þ¥õŸ1€áî g;nL>þ'Ÿ6ð'ßö`&ÏŸaQ�ØA
|¼Ëm=\ÿ�y‚`ˆõÏÌ°=
´…Bœ}
+«_5Ü�câ�->³ß]¶UÙwºH�Y:Ó@'Ô
ÏÙ¾¬2·‰pì„òX”àdÆù�Ψ¯£˜óìlŽèèZ|ø…F3Ö&
+�qh<ë/=íq|ÜÞ>“f¾WV “Ž�]m(;ÍeJ[<ÃaÃlœùb\¾¡ æúžè×}#-�#ÈÉq©¾çeÏ[9Já¼ù¢_¸ØWaøáÖß
+ié”ç-ÚX'ÕE1xãÕ^r%LSõ)çœ+眛 Ë
+<Hh–~H{
úýÖ¨�¿®_#ø{Öq»†ŒRÞ}Ë�êàáõ�wuÈ­5/�‘ùfXo0º²ÙȨ~q�ÑÔ2š^¿—•tËLg¶M–-‰—
+K1<›@T¨p\¤’‹¤«oë¤Á‰Ý3´Ž'öä÷6Ƶ"n^Þ#‘µÓ‰4K�ל‘�(_§.‹Ué¾°PµÏ9iil­\	«|¥Wñ¬=ò7>õÞÇÂ[&Zêy#ƒ0Xæ�]&òCO#ÅÛ¤ø²¹2E�í	úIlºgÌéÝ·akÃÎÇáòû¥Næ
´ÃöÚ™5ÍËÓV¾“/M,-±çDÇZÛ>Wk˜DCÏ7rRIÝŸ’¬ð1È‹diøÚ¿Sü€Ar%çÎ{*“AèÊôŽÙ.… ®mÏ«Í–ÐW®ýkD-ca¥ˆ:ÚŒás#ñ€îÀpolí›ò¾°ÍDŠNsíò2�¸‚Ö#Œe

+·�&üÖ!Bë}àBA¨ÛÀΡ�XÐm|¢]æpvKºXKõ‹•‚Eí�3MâɤáÝìdtÉa~´K_\ â4HÎý**iœ·É\Ìe:ŸHÄ6]«W•}]¿­ÑêS%S´w<
Ü‹åîOìkkQ^¸ù‹Kû`ïJí¦¼W&MÕ½%)–›D6Bc<\ë¿ï’+8H„
+uŸ1Í‹K
+|TúÁ.øó-x{dœñØZWäû¬eÙ—n¶R^v&ëgD& Ê&>2P&õ£±•_aG*Þëýï°`�eNNAU{yßÅi\îÓÇê#‹0x�ðØï†×c¥•¾\ûõL$ü•ü¦ð·ÒæªØ,ªl'<]ÔLI½à†ž­Ñ¦°¥ú_Ûµtk2aÁŽ§ØÚC�~4¶âµm1²¯I+ðí^a¤Ft(†VPÉ Ç[è>C×ÿ:_!yà»uµÎVfVúôz–ÙÀOX¨{�ëµW°{מQcVõª)ÝŠ…?÷dɱ8~EÎHo<O?µÉ1Q›?N7öÙ; ~­Î6Ä“´Õ�"ݾ2.A;Á
+ùzòÖ€Ç'éö±i©Ým¼…Vk%ßÕ’·3ÉÄ궋åË+Üt¢	'ÙèÚßF¦TÓ'ß{öÛR?SƒÒÚ-búpVûȯ×Ó^D .P?ÎöMF,½Ö—BåIψWc
â·å}eâ²ÔèÙ7lÄŽÓ$•F/
+Wòí\Mߢ[œ¸ò³FŒ$¯áƒc9Iý|Ù—r
d	ž…C"ÝÛúÎmÌÔ�ϧ>)3'ï÷*Ò]_™¾ÓÄÔ~Ÿ®vx¥ÞòÊ¡
+wøvÄ�ü¸61vø'6çlò=n¡íˆc–¾Å[확;ýQ3Z¦Á„äô™Ò+~Yq"§÷p1_—Ï<!Õí;âæ§né©	6×ÞË!ôÝ*?Ö‚/Ø\ò`r*ËšúÑtØ´Yó&×NŸ·d0êë„«�’k{%Ø!£ÖŒ¯ª=�~
s‹úŒÍc|Ÿóç}¶wý>.pÔáò[ ¥`«Ë„‰ä9“2Cƒ‘i‡“žÆáWö.—6Æ™ÖE(}Ruã̱«˜10Ë
_S0-ÏkH“¢JéG³ÂÌV³ßz/gѺÇ;Öö#ejö¨0Øt5¤^yE½mqÝ(X q(Ú2”*n#œ³tWtV¡èžã`Yõ±Á±º l/W¢Ù©kü:e·´\úö†K+=à7éë¥ý7§B´ÌY�UÄØŒbTáœü"¡		o�–ãú£ùwhrU
‡¾á%y›?qp©V«?e4¯UeiPŽ—YFüF$Má…�­s¥E>œŸ²G»ˆÏIÝ®6‰"t:Jí¿Sy“]Åá·Iß �ȼhåiÖ�'«šÜ�Ý_Û¯
Abí±šŒbuQç“:)õ
+ýL?ë´ê�pUn¿TöùVnEÁê?Ø×_¾´p�ãúâ`(ý”b	z@¾‡ínüºSw©õÙ,"ÃeçÝ4b‹x™-R†ÁÊÚî™â “”„üKKëšÄ¶´Ÿ­äü”Fõ.Ÿ1´c~¯U¹¯M]p¤)ûIoΰ2$Z`8+B5®Óµ³ÎJ}ô²?ä\� –³[¢›.ü ¤Æ°Yd¶SêZDh»¹áYºœü€~IÒG>\� {áxÊ/õÉ®[ávÅË/¡‡')Ù®oº«;ùqÄuj 4Ö„bùàgÈ•ÝçOñsÆJŠwí^ùÏõ £†þè©ÿj/(x�ý¬Úñõôó//]ÈÝÅüæOë~Ó×ʶ•àt`e/ûïè
ãûcOû)…WU/“Ñ‚¯Í–Þ´Gù­ÙïÜ�wTîÏW.¼)ð—«{žÿE4%ŽxôÕ×ñO‰Ö¡ìѱüBú®^?² Ò7Ú‡6i–”“´šü»;ÈÂœ{Ô¯6-®dó7
+DŽãlÀŸ_¶—s@“Mú§„ây¬ödæº/ŠP‡}øe(x¿ÔR^�¾ŠÎæ
+5ËéZôO±N>%¨ˆ¹�aâôOZ3)€å}íÖN¤§fQrÍ›d²~©d›Ã«°]µmä_—–õo‡öé´6š·§¯t`0ˆ'¬bXšz˜g­âA;Ìƺ‡:ÄŽ/0´³’YÍ“Ó^O¬œ.~èÿé“1 m«ð(¦Ìÿ#~+ÿÄ@è…†–1‡¬üþÖZš‡ÑÏMŽc…#ë,�…põ«—½ãQ›q„~ݶDwRÉ�­±­ðç}ˆãê�ЀlqâÂmƒéN¡òºât�»ÉÒy•qÝGŽó©6ƒïXd,7DýiF}/JáP*Z°ýƒ[ïÊñåx´NÞl¾d¯÷ÝêèïM‹Í¼:,ýdÅx#µÅøÇ—ÄæÂч7jèÜÛÓáöâ¡Ï˲¬¸x›·wê¾Â'_=Sz<Ï,NîË!É.öš«çY¢¬-j=-¨¦a”%m].'Û¦œ|ó+êçÞ
Û!)Žoh\ð(~r£hc*o±q×	q+fõ³ïóäÒå62†™·«ª
vVij^×Lb‰—'ä¦ÜÌÖR8ˆ
+à–¨ÞÏÙCãr±`Í1º'�Þ3©$.GæEHÇçʚʗrhüúŸ·Òb¥éuž!&¨qΉ6öQn�ªÒ$:ZC}˜i%¹Ê­»ßàÅË]¡;�J¤ü¥íÄáÈ¡¥æ�ê?^0ß-±9�,ƒÖ?¾oŠ¯*4ë™XÏ¢ÔVúåœó5Ë%`*�fÝ��Óáõ€¹�Jx¬ŸÁ«|ÉÜ-MW¸Æ1–Máù*ȼRé¹!;vúŽËE”¨Km
+ÓD‘ˆy“ìÆæQj})ó½¤dï=¿èèWh£‹q>9Öžc蛫�w¿�YøIoÇÑÛ>;V;Íúå¥~$»Ï¨AÒIK(¢Û³@Õ0¦Ô£20¸Ê
)$çÔ*í>Lª×5z(Ro,ÙõÝ#ÿ}Ã�Â	QàÉçÙÛy\1°Èöºc.FÚËcuÉÎÎý D­P”0Çj XS;ióé,¶hqPÞQ×I®y²Y%Ó&tÅú­;ôþþ ¹„ÙsQdÐ+-\yª×¹L&¯Ÿc݇)ùÈ69ëzTê|øÚÞo–ÖÕwÙ�Y\9C
+¹oú•ÿ™„WÀ ßóÇÓ�NV]UÅw¥Uf]F�}å'Æ~’Ò›X�œ#Ëçž¾cvB¯W/¤™�iÐÂò:Èû°?¥Zï³ÚÜt!r¨±w(P¶¨^á	ô	Û}3e/¹N \J¡ñ¢ufý\˜‘ãLT(�1„™YÍdãºIé;o¤äú9oÒ>ÒçMªá8rCŒuÁÀ߉DL6¦ëÕŸ¦D¹í�[v¿8½£ÉICxY'ž%¸�)4ãl¤Ã!þ"2J)/E¼4²%º㉜Ɵ1gr P
+×¢<Ð;’Am
+b&c,±í™Ðò´6@ýMãÇlå‚¢Ý+§¤õþŠ´JX)Ò~Ú®~_òŒ`|µ*ÊOw`à™]ÃtíÓ?³Ý…‰ÎZÖ�z¾xï¥<QFöè>�ÝQøP&_DFáî?¸jÂÎóï¨Ùšø•À„¯çäHËlÅוäÀŸ
/¢p«·ýj/
+¿¼I-*-]‚×X![0O²h¾µuí©±°njî¼Ùõˇix6·ÇüvàÁ~ó©O‘�Àù‚˜lMT(Ûf™)Ea¡
+«f\‡Ð¦¡$ƒ±È=Ñ3�{UvŽyo{VîÏë	ù P`üñŒT¶Ve¤âZ­²<§EnÚâ)ÚQû´%¾ ¦¸�7ïI¸tƒæ¹H)w)I¿¯r8Ú'‰uŠ‘VäaÊ^äZ¬Øy·ºÉ’ðô`ù³d^z¸)Æ6Â:F´lÙGNŒî;T“Aß<68açÛœ\Í„˜P&
-‰*Tù–†‚û9n‰ƒMŠ.Ö_®¾˜ì»[tTç5u|e±ô(z¿‘1­ÄE¤m½9FGyü…Çݲýu %b«º&Ü“k®[“Jf—õvbè,úS0ëò£KvæOìÂT€l,Jc§wyÛezŠJ{ÍG¿+Ö¤²)¹¶Ú¯ã5ßõzÕ~^Ñ™,UËÜíj4¤fÒØÜÔ–Ÿ"^£Î|ÏvDÿpï2®ÀžDrng/ÿ�¨F1}ël†±ùÝ/àíÀÈ/þ€%À!yjå—rG?v’ŠÁ÷ão¿1ÎÞVlJq§FÅã®|‰ú^òñ{¾°ì¤&>M†J|)§C'[¸@wÑ„¾»üë’N¨€‘ÇA,‰MÒ[PÊqu RÏëgìN™*>rˆÞÌþ�s“°Š¶ì�×,¹v¸5½âz*¬Çsu€yÂ
+wñÈ6úà	”mÕé²ÂþYTñ0¶ŠŠn˜ÄVûÄ*ª¾“z<ÓËåoœÈ-ÜÌ�€9ð®Éü̸˭ojÊÁª&ÁU/ðޭ목;íN�ˆ"ç}%éÁ´ä}£‹>òΰLžž4^ùÂí°Ä`üÃ\½[s!ªÝÎLð.ó¦Š�Ülµò"±Úu�
+�Ú匓$S¢’ 6CS
ûT ßé3çDIЩ49VTÑ�Þê_Eb:ÚÃæšúa,M[a¥1a=“Ûÿ³6]<·1Š\KŒŒjì…¹¯ònð/uÄn锊ê&½7Slx±*#Á	ÆxpC‚yC[	>F=ÂT@Dæ©F ¨j`ŒT-Fbj×t0ÿJ"Ã.c0@mY{PJ 5¤Ì'¶WŠô(æ
+w:©ÿrŠ®­|¢©Â¸¦z�$:�S÷5ýe!�Óné³úÇÈ‚®¥kîciqç`“&"Œ»ñ¯[’¿Â
+Þ^aæ’�W~Þ¸‡ï¼¾L¥�	[þ¼RB ¶¸¦ÓP?¸O/Kch™iÆìɶ69eý«Æñ0C¯z�ÚV»\€3ÓF6F’×PK(Â}<….õñG¢7uª–íö�x?Q:¢/³«¡Ý�Uf7ù0ýÖgß´—-hyŽ�éT¤ÂpÕ
äX´Ùð!Gf“$~°Úù‡A—ñÃ0¦é!Áy[<mÒƒýÇ×?^Dtú¹Pi(‹Å¼¬ŒfB)…iã™Àòfr°.Á}ã4<åòXFj¨ž‰.<P?ó°-—RJF6Žr¤•ææ\’è¬ìÔô51^ßúkÔkÝ¢ø²ÊáuÑ„ªE¿…û¾	]+9Z@ÖñííwÍ®¸!Å4¢mee&®PÖªñÙÊ\;ÒAª{Ä-h'æ!z}²¨ª5)äZ呆π$‚~WÏOLŠSá�+óÉ'½-±sꨙø˜\I¯m!÷�²ïY½�’똟“Ù¨*Bqä¡�*¯¨ß$7”ïæç]J�…î
%~ÌNoÖûšÁþ•_6låÅùÝukA³Ê–‚ŠBûþCñÑß‹?{šØ+/øxõš/c#�MÎE
¢ˆ$YN?Œönˆy•»ndvúv¬í´4•
à	éºñt½~¸õ¦'dFX¼ü8a
+É]g¤ÌÒìÃ<¥)7‚�Ñì¦aìnd0² ã‹ï»¡.{tm)«�ÿÚ;�ðÅû¥™¢ËÀOû&*‘8$�nÎ
¢7ï A
+/TÍ®vi�6Ð9¸Í>4â�|ßï½@G_C
)$œôÀÁ¡S霿<+sK…¦–s5KÃóøêÄ寶Pþ}JýHgëeC÷ÁUf2‹�ïU¦�(^9g­5Þ’‡®?�¯¸ËÎïPrtAFžÕŸþzo…‡“Œ:¾æ$žýf¾ÙéÝ›S”¦]¾‘õÉŒ·‡¶3­×žÂBR­Ì]þ
+诮ñqÂmdàÔ`7nƒ¨RWºÓE[œ–™Ù6‘9¶?`ƒ=p®ç3Lã,oئDLß÷˜¯ÙTýŽ§Ý¯eW‘öîònQÆ—a)ähF%ö¤5ÙÍqXÒÜâD�ÍPá±S)ô|ÒÞôÔŽUYïÃÛ›ær¬f~0?rén#º«�mH¼Ÿú„Âl#¦u¬…85ˆ#FìEeU§¼¹Ô_k<ÿ
k¦°ÙbA%R7@"ÿÔ÷»Â2aë}ñó±
Í„½![/©¬‡D�pÙn/Éo	´=ý!"o×Ï¢ðœoâ}Nó’Ïúýk'´$ó ’�;ŠTÅã�8æWÌuTš+Èó
+^õ,mÝ>µsªÇÍó�Q™“™:…&ÚÞ0Å(ÛHj…`ÌðSòèí$¬=Ý3UÊõú”ûµ̒yæMŸ"¦*lÊKÓã)¯ý¼ð^lØb$vÖˆ�H0癥l{<
+�ø_Ê'Œ.ÌGöª‹é–Q}é•.t(f2‰ûj�éŲ¼[Õ
+§m#dì^Àz#ÎHc3ŒÕA›Þ@�4ýÆaù ÃM¸gGs´+l®ºhXÉ¿N5ÙbHË5toï<Ÿ¶¤UxÑ£(½¶§b^j
+Ûó–ÊŠEVÛ*l‘(¯;Ä¢føqOóÊE½WÇçT(ÝkEfAó¼žýÂ
+rW²tˆjêÏé
+¼õ¥¦Ø[?°qI„Kõ⬟5~•)ž¢7Stû�Œ•_ÑባûŒÒO�Lû-ˆè•ÕóåÉú¹@¡dÉE’]_VJDù»ýõW……¿].²dt~ˆ˜ˆ ëM„í[z:ð1¼meãðÎW
&If°
ânË5èŒqJ ùHçq$?HÒàºN÷œ³ÄtÉÕ¶øhÎ=ø�i2Ó1\‡>ÆQ�ºO€Iep3ó¡5_€lª§~—å�6í×ðnþ4Ã�
;h·M±VH½r4­ÊvV & ¯Ž¼ ml߇K�€#×?xÇ”³îL3sÆ™¸Ö‹ô¥�{Îcj+;�ó÷ˆ™�¢à#ÃZIü7£aÛG+ˆñøÝÔ›QEíÀ’¢#­ƒ™)­ìÕ¼`¤øÍíø´)’J±4ŽL_$/Ö.,ÇÑYéácòwjÖlžvÉ[ÓáþhÉðþð‘æó|[×L.6y¾WLMèJÕ€¯ŒþØ;©>âÏ
 ‘Y‰è4‚ïÓ+Å·®‚›m=Ø”°YXÓIp}å°ñ	YÙ߉ŽqûN<Ëúæ=´û�Ôg·>ÚܼŽq9ºT†¸ÃèGSyçm÷p0ðÞû[  ‡s‰³3Éî%ø¥/ÝðúµnAi•wÖ,[é5SõˆcÜÕ°Öº×èÏÕÇFÍ,Œ;nòAï-´´€Ä߬ug�¬À!ˆ <*’Ïã´ñ—Ü›£D•îÔO/
ý-?*¹Ww×%sUc‚ö6�a	u¤´ƒ·¶ªVq«ù|4F;2¤
¬«šßh1Î2éj˜ô÷8æºÚÀ¤¨Ä•½š:q‘—
8roBÎJìÞÉK<<æÓ?6tð4)=Oö¹nÝúy33ç4ç«"s_ʯrXZœ´¿�":¿y€Ø`eóúþèÇi™f*õÀdP[SÚ^D$24³ªSpÙçr«u	+¯X£ð\½àá)™—�Úùìû.¹ò‰¬vY·S‹È¸w´þÓÄœŸ£ãì/âìœb†Î#aÂ]ôG1ë-ñÒ8;iµ�¡ø	LÃ,c¥&]#¨£V¥¨wʈտ™f_ŒWi—²]Šã—â¬3—ÄGBßèòQB]Pö½!FUßs³Ó¨�ú­™¼‘JÂÀFGíÂ
+†Þ[Õñº�òŽABjÙhaLMô\¸©�·UÇ2lucJQ¹ô@!5@ç
;*>ƒìïâ _\Hñà‹Ea{¢ê’7ÎV[ˆso'Ƈ.–¼{èãrœÇ<˜Ê¢©5û&/gý©~ò†…p´F7Û,‹™éÞ&	ƒ–PvZœÆé<ÙX<Ç~ÚñDRx›±Î°mé¿,œÏxIÀBµüïgE/Hý
£öÓçVB[�1úüû¼
�×+,(ëÈj‘õ8¶DšÈ1éV%á*>ºÑÌÏ-ÉbW®V§…* ßcoÃÉ«Šx›B¶>�GžÀ>­š-QFÜHÑÃâ•°8ð8—ÿTO¼VJ›Jfo!ŠËKÌ4,pB@<ɵŒhÛ*ô¬W¤ˆ¿™Ù³[¯6€œÚ§óªE:§…¼L¤åê•B¼¦aíe®7·víÀe™4U8Žm]èÝÜA±ÁYažr}‰Í#1�ã™Ûµ*j”ÿÑŒá�è+àu–L_#Ƶö»Ìñ�˜S}­�—qmm(›1öÑÃkªuÊ}$ìL„_h�H÷,½ÔtÚšw½á�lœADöâ‹Ctkôq¶ÁîV1)Òö" Ô»gFbØ_
p(xÿ—ÌÿOðÿ��3ƒC]€0'Ìÿ
 endobj
-970 0 obj <<
+1025 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 1930 0 R
+/Encoding 2092 0 R
 /FirstChar 35
 /LastChar 122
-/Widths 1936 0 R
-/BaseFont /FEIHRQ+NimbusMonL-BoldObli
-/FontDescriptor 968 0 R
+/Widths 2099 0 R
+/BaseFont /EETKYY+NimbusMonL-BoldObli
+/FontDescriptor 1023 0 R
 >> endobj
-968 0 obj <<
+1023 0 obj <<
 /Ascent 624
 /CapHeight 552
 /Descent -126
-/FontName /FEIHRQ+NimbusMonL-BoldObli
+/FontName /EETKYY+NimbusMonL-BoldObli
 /ItalicAngle -12
 /StemV 103
 /XHeight 439
 /FontBBox [-61 -278 840 871]
 /Flags 4
 /CharSet (/numbersign/hyphen/period/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/r/s/t/u/v/w/x/y/z)
-/FontFile 969 0 R
+/FontFile 1024 0 R
 >> endobj
-1936 0 obj
+2099 0 obj
 [600 0 0 0 0 0 0 0 0 0 600 600 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 0 600 600 600 600 600 600 600 600 600 ]
 endobj
-961 0 obj <<
+1016 0 obj <<
 /Length1 1630
-/Length2 10420
+/Length2 10814
 /Length3 532
-/Length 11287     
-/Filter /FlateDecode
->>
-stream
-xÚíteTœí’-îîNÜ%¸{‚»k
4ÒXãîîÜ� Áƒ÷
-t
-rvuzñp|Á^ÈÔ�Ü n–®`g(à%«º¬üßuBm�Ð?¹ÝÀ/0ÀÉúÅÓÊÉÒýOKa/4/(†¸
  /èŸ\ €ØÍÙ
èý’û…ÌÙüWîn`ˆÍ?+`¸‚l€®V 7·šî?·óÏ>
ÿ¥{ ³³ƒ÷_ÑNyýg
`¨ÈÁš�›ç%§%ô%·
‚ÆùgX ÖN
-:‚¼ÿ›ÀuÔý]ìðý+¬
-äê
-°|טHØ…Óƒ×PrxÄ�ºsÍ8862<ÔsŽØ÷�œ5?•^Ä
“!6È%Ÿ\ÂP§Æ7šuîÃ.uB_J
?ÏúTþ.=Œh28s¾ºPÃQGû‚? +ß/WI
-;‚Ÿ­û¬’»SU*rUO(|ðþï~«m¯ÿÊk�ûõ”ódS
ê܉5I&Ù‘­J
z &WÒpŸø
ºÇÿÈ+�cr¾Mo»À8„<¶o˜:b;ö!ÖöãUÿá UìœÓÞ7=ïQ”|ôh‡Š�xÓaŸœS…~v¢Ñ>ɼ{,O뢹Ž‡D¯ÈõM·*_Ö}¢õ$&ˆ\¤h…*Úe�[gÈ}üæ#K'ÙY•§Ì¾©l•+‚â‹ãº�<WŸ^ð}ÕÍsÖŒ^0L�ùª©f'T
-Ý2<Y±A‡nÉã§fHç·Pòè=Þ¯%˜)2w¥³3›ôh®™¿[÷%u9Ž&â>I›"¨8®¢iñH]® .â³IgË$ ÌÞìè¨Á±•Ìˆ×3F$èóþ±:ˆžGÚ¹,nÖû¹4‹Šx9€Š?Í‚ÉH}½áwskŒ$Ê=�ü1ïfòw…�¸…3
-#®Ð‚K½!ß…—-ÿ—Z³.•ˆzdÉ~ÖÓ�0&·fžïMQ_ò‘½{JM¹]ÁÚ7bþ~”Á.«sB4g
-Ë“›V2báJÄíŽÃá4k£„kܽx:exÆ墖¤ß>$æ¥×¾ÿž³gѲC‘6)õ
|{ýn÷ô~ú®��áë”$%žEw­¿‚áLxÒÊ�<¿¨7åAð�£?Œy¶\«Ì´³qwß}¼}¼Ziév�63;íªÔWc~ûô Dqz˜´ˆ
ÏrÔ´N²¥Šêsßa)QØ
-Æ=�Ûw…gúѺà6"€«ØXiø-ðgE:
-A["Ïb—�#='%}BY4óK`5·GßmD.•ÿarI/iT,Þ,[Z©}k“^M"‡'*øÆðú�åŠQòП_ÕWf/O¨úO^;zåô5¡qž.,Ù)úm—#É;=ØÜKIé·…s¯Æ‚w7ÍÙ€IÍ�­ÂÊ÷;ØÅ~žÒ³×Ÿ}b¿P`žÚUÅÑ	Ú,?œP<%F}v«ik>6Í’D¬Ÿ‰ÿåÄݨé<pOÇ•¢j7†>ì§CœˆÁy֓Ŭî’kŽÇbÌ=s´½w-+çùÚâ:
7{\h#¦Ú`¬ç¿4©��‰Ñµ�ê^�ÿ±×ï½Xøw¾l~ÉwÃüË|[DxÚóªZ7�¥ÇÍO©ì©zí¨ŸjVVcÈ-XÐõ‘Ê•ÓõL…X5=€švÔ9qZA]·àÇùR„!�¯ç'ø›“dYªõöÑà‰¶[$uÅz³-.*óÃ2”XmÍÙSÎ~" lœÂƃXfÎ%C킲!¤æ³åQv_EŒar¬é'µòSÙ®.ÜÁ±üZqž2óã¹»qÍÝò±aT‡Ëï[3íížBÙ1Õì*{<£Í´q.‹êŒÉ`jÛ�P’õ
R°¦Çk‰UK+ú�Ó@pWjaÝVçoC×õ:„÷-dr¬M³
-…š)ZP~§‘²GÆw¶:è6‹%ïHkxš*òšç$z¥‚²'Ku†Y<Z(Ý0c\1ÎWmNæ'Ÿ_Ñ9±þZÄf¬ïÖ7ã>ê7꣇®ÁÂY€kìÁ˜¬®·V'£9Àt#úGB-6�ûÉ7š‡FÈbfd½ß´‘Ϩ[¹ØUóàçÃ{k8
§¼9ùò>dDî"^W/艞hq«¼ŽD$j³Ȱ#²§Ýâ_‡£u¼á$=Wx„i\/O/b“íªíPœõ.§K©¯Š³Ö
-vèfÆŒ²§²V	äLÕu £=«µÆ0åQ
h0ÞÆjâKw¿Œi
-ÕÈo‰‹™ãÚ“Vt+%Æê
Ò0jtƒŠ!H”œæi†BôwíqßÌŠÛt5ÇYeC¤ùÉ¡ëYVPu9¹u6rOSåº÷”¥ÆÞŒð™ºøe‹b»oð¢1j¾SÑØ”×i!#a�®MÒ:4Fô–la4¬ªûïÑÚ"RwV~_ÈxΣGì?~(ú²oU
-ùÌÉg¼¿Ž>º§
V‘ŒéÙèðýö…5”ÌËíîFöÀƒLáÎdº6g‡­ï.üÎ2Á5¥7¹T§¯hj„þÎù¹Ó>"ÆÈeûÛ’õ
"Î3‰Ý}1¸áb“šÅ-‡â�EŽÑAOÑ>Οdo	e¥¿´vÖ”œú­µ‰,ƒ/Dr£á…©ôRx_=ÜàµíŒ
Cöo-P¡“dà˜‡S:’%ÎŒ¾6Ÿ‡'ð¿µq
-³ßk9ø‡jÕÖ—'è Á̹5�Ü�ue§wº—ÚWÚü#FÁ²°h»U�Ú¯ÈDçC²¯LX£	#VKÔââ•å:Ã$ßÞx!jCZJ`6¥æå6íÔì|h1e§,p¶Ý«GRñ™¯­7î`­T„c�XŠ„³ŒK�«o
|sg>â>uªp¹™Z¬¿ïÏÃ+Çío@<´En�…sÓf…ë~›¤â*ÿ
;ÐSsÇô}=3ûpãzö,¨”VYqI0ÙûÝs¦â[m† ìi6ÕhC9m7Ÿš�I»‹ñÓéïgEOöDVûêwYj%ÖQu4´ñ=ˆ\|ãUWìÕ›F1a)^�BûKÁJxȤå8ï#çç–½RZQÏ~ÁDøLAZA<Mg‹O÷EiÇ
×ǹ0�Äx…&®I³”÷å
ÀxfN/<	²
-
-CÍŠHV†*t2GÂØþG³ìŠ
mÜ
ZxGe·bîBáÙãÃù»‹çRבb�’Œh¤9W¸–øTgR¸Ì(”ø¡5kºà›É¤¹µùÛ�bþï¶-Ê~˜;”7ÑmÆ
^T˜‹vÐí­&•3özÑ/JÁŽˆ¹ËM6¼�ÑH*­›Š=Hœ¶CPHÅÔª’.UJòûõÆP©ãËŒ
-+ìöù[Õ2š
-ÒñW:N<YÖ]k!+1vÄDÞQ÷):âïn#þn-‘zªÞ´Yª½åS<¸úp"Tíª˜òÁY(×!WÊ‘Üç�´åXÑåbÏ�QŸïPb
v¦]ŽÖÁ\¨+=cÄâ~ê¤}·‘í"²O†ÕoS—™×Š£6îHNdΣJõøœßébž»…í§¶E€>F1R„§ŽÎ)}ß0
-í>Ö‰†­õçl?ë&ú]Æ�Ù-Á'†â¤ª?…²Ò0$¸	iú]÷
·ñ‘™ì-Ëö’]
ç¼w¹8Óœ¦aé•«S¼Û¦;èò#.	ãm^kZ_
�†Žg#(¢X¥ò“º�·ŸA¬Ö›"ÓŠ‚Kæ³buëK¿ªwöVåÞ#§-÷Ü�@VM<˜ÖÊi7´Â£„-v'�È,ÜbtL%!5--IŽ»W¾l‹ºbÂÝ{dÞ™áð0Œ¤\ÏR׳?½z�}:CZÏÒþG÷ä­¬þ±Ï›pÈ:§lÈ8ÕQµ1íåðaòj/‰±m¡HMlê—ç,Ú#cl•ãZÀ„´]äI~›]O踑ơ|Gàjz“šÊ,ûckÇ$±	ZäÐù+†´Í?‘Ja#ñü/ÛùÁ|ìJ§Ü.̤pPë&ƒã—)¼Ái¤UøJÛÁöSùOq†eT¨
-=èŽ
íóÀ„>zß�¹‚¶ìüœNžé¸i+h:“¶’IðWþjQæMýò©†4�#{µ8�<Ô2Ì^þ¯™ZçóF—o£ã¤[¯Ÿ&l´-æ„ÆÉ„l^»ì#K,yaÂÓŠ	ô-®�k‰<�+ꩯïƒ,ƒÅSÂÊ°&£�²¹í�jXºEéÆŠ™8?%ùŠ4<7K[_"Ú•vŽ³Fk“¨ÝÏaMY§!‘ÉšS·“7¤4,­,ï2Í¿¾pæ×rGð?òåi%h¬ÒÉ´UÐ5ñýq5Ò8¦ »=¬óÙWÑù0YL \-síaœ3;Ù„%ñÐwæœ~ðbE†dUÁ&ö	½D"ë}‹ëI§«‡AªS‰<ç'Âo'rX.®!oö>QÇp~R¡/~™©�Ü\?ý-3³Àö„¾¥ãÙaÙ0�Ú“5ÅpÎ1¥¬¦¢1Ú®¾S$Ë5&fy¦´vZC_p|ÐÒä
-P€{�åN¢4­DŸÌ5ßv‹ ë
+ãR×uÓëM>«YVB°éHŠdŽÈÙf?+ð6±§}1º,B-¤Ylùö®sJÏwŠ:—(Ëë·‚ÁÑ!
-™P9ʃ�ëu²‡2†F
ƒbtnh–!jTV>Ì×A}ŸÁt=Lo–Ä¢Ë9þòVôª_eá½ÌP~Îà_V©Ë°?SâßõWx¥J}Ûw�ÿæ‚[Ì)"óó
-ðÈÅžŒ
/)÷±^&·Ò�L#0¢8yX¼ÀI¤¦žX½;ys1iUü3/ç
-ʊО=ô
-k…H8M)¯‰fXý|:i¹²»&Œœû#Ñ“‚6~´”ªF5eûÎ+qbYß­	.-椨š÷9
>ú+ÙÒ‘c¬õ`ÎÐâšStz£q)

Ó7šW7ØŸâÓ4è’¨�ëHUÓ×}PÏÚÒ�%§S¨7Û.êOò¼ÑöŽ:Ñáݨ؅jé¼übs±åma¡}î'yŸ?ÿ†‹häEúÝǵÊ™}Qƒ~¸'ªÜñ–¼cuG N=óæ]õ2ú
׫Bó¼0®Ó©M]oA'ÓÙÔÇÌÝ]Ì“Ðk�U
y‹tÚ½³7–pБ ²5‘#•¦§e÷µ..ØBeïç
eÒÛ -Cµ<ª§yC½ñúã
¸òZ·ùu�½1Ê$ÿ†HLõRæf‘Y½2ëëÐôYמ6j›Ï¤~6îEĤ88=wšêWVgéó;Ýó!k¯c`f8�ýQqñJà½Æ;Ë—øn,Ò;n$}÷­·Le¸Íq½iYˆvè-™Íe †§2Ç4`¿DìÅBÓ@¢”Õ‡o´ˆKÄP1ùƒƒ†×‘àLÒ$5œæj—ð$‹Uë%&¼;¸û?åH£€h Š*{df”÷xuFYãîVÌ’‰Å0L´§Ë1]�*EBìYT=ò¶ˆRZ†Â
-|)Ž¯âðœl\H˜ÝIC>–ù‡»…R©-/	ã–‡%Ü©Ù̺žÖ{ªûN�{o6]”½óÚ#X1P™f`EŽ²=Ã(H¬ûO=CšÛw“ÑKÖß”s÷Ó“Ú�7ª‰]ì„k+óJçmô/Ö
³ôCû™)¸¦ñç‡ÝL*ØúÃ/:;<±á4Ó$Bo:€+?ÅÂìd/\:¢N/ØDR�“à~«�ù²¹á5LÑí©ÆÏÞw9‡ù¡þ Pz«×jQ
-s½vI½6Få½=QZ&Iª r¬­¿˜¬Î=6yþ•.Ä÷’¦Ô¾Œt›x}Zp–F¤]ùuãôÚ�77ª/°¶‰ž –áiX6EöúY2«.̸§Aá{ÏƧ`-cß×zV¶À•¤f¿ëª±”
ÿ°IØ%?´˜7SsJY¶Äs}ÑŸ<'<±¬rù„ƒ³3í¶ÚÌ¡!›öˆÁP7KûC:A�iz¤öö˜ýSñð~ºrúsÏQY¾ƒ‚Š/ýthÊÕÔ±8‚Q-_:¥¶L+€6*£Ý0r’¡œ±ëDäª:✇'à
g‚Ç×T[‘–m\ù„|-9ÝÙ%¯e?µ�•Ñ¸;ªø·•âìO¤»Ÿõèó<êÈ|ô¡¹ÛÛ6b•œšÄjijÇP`÷f›¯zcÙŸMÛ¼Ê	À‘[Œ}_|.ýÐä‡O•_‡Ìc–¼ûUݹ
‚oŸ–?‡@2u_{¶¢j¤ÉÊÂäk
!"¿{&ŒÍ•©ê6Æ›¢sgŸeœ™øjº=‹Èp³ªCigæõ”õˆ®Æ³?Ú¸z
ãûQïÓ\µêžëc{Ï( [ZHº¬‹éÎgð-ÆÅ
ïâ+ë¶æªõÜäï|õœJý�Èm£ÐJ
Uiª1„
-ßvÏ:¯†„6
-ÍDãw§¸°:Mý
²qù.ûþGõ&‹F:ê1΃Ю,%†·¯(µL{vf‚¦ç¹(�@´šdqˆ2onnôþ�7ëc©�„¿cì•î®úŽ¢Z^ÿ)Óax3'�µ¹Ÿ‚e>u¿mðs§¤ü牥+
-ª³èì:œD^U3Œ»º÷ÅðRîfE$¥¤…~;,º-YvÎ$àu™‘·¬Áú[“l �°Â°a7ÛÙ%w¬Û‚ÕWnî<Øíl¥»õ"YA~FÚå	âDëþôa’–H��¸‚óU
-@üY¬öÌ_{½õN‡Ù$åÇ7ѯVxàK9>:t|3QëØñ¦É?ð?ÍÌà\6ú³_+¿¥§ÀÆ4…çf¼lŠl”0Ât|Lòâ÷0ÌA«œ�ê–¹¢D fhtV",µÊK3óÅ
.IÄÕ x0>›µ@²åliØd‘žqÔö5£3=@ß2œï’XÏ·‹|B
•ÃT«õÄ8×AþwbCƒÙlÕÏ¿‘*>Œ¸¼—Ôb_i'TOHÙûÝéÊɆ}3®Ñôn×…wÍ…Dˆa@FÐz<ýkd?]‰ ¤Ë‚h8à[b�úÖIî£åƒ0
!Öú¶UŒßëÓö:vtÏê<­'ºb²/gH¯Æp3.Þ¯.µÐõPµ�ê>µ¼ˆÅ½®zò-Ù2#Êle°<Z¿–0†CšbƒxoàFÄÁ£�Ý^–Gž¼!÷›¾ñRhb»pÛC«¶6ò�¼)P‹)Nö¤Øß^�a¦rüH€þ3ü˜|j›Æ­¹<rÅ{zRSŨ ¼¥ð­_NO�Á
¿�Õ°Ã×sÚ稭…[?K4a9J)&´ÈðÔ>§æK‘�­t‰tîîÉõ½3cc‚	-s²µäéEô¤³Ÿñ nhR¡×¨a/ŸÎü{
-À/6ñü>pF‡)Ö“‡Q÷Ïõ·om1ùÞ^Nˆ–­Žz±�5Ÿ~ÜÉzŸŸ¨»~^ªì®�—Ö7\JTÂS!õÎ<e2TéýY3#ÍnW›_}	AGC›?Ù.Ã.UÂBÓQ:Г4¡©UZÎB²QÁ}c…G Å?ÿˆ:s\ŒY‚5IìH<Œ�vt%mîë&*ÔÁ�{ø�·r¤k&Ë$PïíÕZâY{dA«°Z<•@÷Ï>ßh^êG—×;(��”;7Y¾¢™$ë±Ý+ÉÊ_`åuPèýQYð·õâE¼sÎ	[‡71Jš³VjÆ-ýô
ÕæÓ°QñdNk{VßH–œyåv	ŽÁØ›MÖ)3Û†þžÔ+wݘY­’Á¦>K;m¼kxó¡øxdGò�{çDþ•Ox§WJ½(ÎçöÏŸ°Îáu3ÊäkŽ›¤ÞÓ¨öUŒ1‡å
�ÜçcŒà¸ò UÀ/ˆ�¶Têëµ±¹ˆÈ5W×±#àìJªÕ–Þ
-Tßl_µ›ëb+eÊ¡ýºž�MDÁ¸ß7 ”¶cœå¸X®7�ݽ›™7t¤Ý«‹Ù“ãS+I4f=Öçâ\™Fƒœ^­‹ñòðIö˜B¡é÷VýµXõÔ’8~ Vš±¨á‚±ûSDZ~’»�Ág3÷Îó°—Us†C[Ù¢œW Ä“šHThôb£«ÎoŠrJ!KŒéðK££8ò²7t
ÍÍé{ÛÚZQW¥o^å«®x+"ácˆ#dÿkå¦Øåõ}ŸÎ©! ‹_
-�”°+ÊØöÿ�`ûS�KhÖϤfÊúw ¼0ݲR�ŽXU§­b»£=á{_{X®/L$šÍv…0.=o3_5ý
-ÕçaΗŒ3SxÃïéšßOs:û~�NBÜÜ.%Qò¡Æ[즉}’åÉôÐéŒ,IÚ„f�@úÚ˜ð­�þ»X¤ì]ñÆ·‚:þhŸ´se»§gB„¾�û.¹Öøâ•#’A_­+§X•ÑoI[Rh½ãô4E³¸­JLðïDuõÝ™ìEs«Ì—už7:èTÛ˜òÞ+êñ/¾4»üå{†–åt™Sy€ŠÚ{¯Úµ1ÇëóÈ ×ðÑVI#p
k51»i¬¯Ž>ìÊ4k,½}2årPky+HÝòöSÕwn»ª}¶¸°5­U¯¢é’L ðöÜžw
K®aACsQ�Òœ,…ýê\–„å:
f®©
0—Lœe³m\gSÅrm1aç÷6âóJ’Ýqj§ÅzÃó|8ýÆÐðo©h<�TL¸—¢››}죡­Úê{iî¼¥Ìèì…Ûš”\ÿËÚÿ'ø‚ÀÒ
t…:9]íÑþ†w–}endstream
+/Length 11687     
+/Filter /FlateDecode
+>>
+stream
+xÚíteT\ë–-w‚-Ü	®ÁÝ]A(\
+ww‡à…;AÁÝ!¸÷à—Ç9·»o�ûúWwÿzãÕ»ÆþÖ\k.™kÔä*êÌ¢fö&@){;03+?@	dkââ¬ho§À¬´pQ6±

Þ
+tøb8
+¯Æíwu»d±Ý‰¹ÜÆXæ§R÷)Áxã
i³åyª¶š—ܾí9ÞYò<0�”jûˆ�/²­pÛ2	D¯"k<û¶¨ó¼ˆ­pΛlxEv'Ê%Ëž…¹`|R_•·–ñÿd{÷ç9óÙ¢Ü߶e�@°-Q–äÿˆO$¯ê2Á³|ÀnåäÉ4¸Ø¢¶œ£íG>ÐK´®‹²üE{ÝsÔGµ÷Î~ï—¶Gí'Ä”›’V¬Éà‡$¾}¿6?dÊ—|ñÔ'Hr;ùMŒ]IJd÷d“ÂUu�?¥¾q¬Àe¢z�œUú…	~Æ¡dë/O	*‘¶²læ
³,
D/L§­„Ÿ5)¹;+În3†Ô¼Á¼ô×
ÃXؘA¢(¦!	rµšT®çj�m¿‚ˆ"ê:=8„é‰ÓvÅÒýÒ´ÉoèwÌ»ã¿ÛŽû«h»‚¬Î.zµŒ4�Í$‚Ÿ!‹8s»wè«©}ÌT8-TCšP×í±¿Ò‡š…ß¾*hÔ>_˜A‚»êEžä>A£%»Y÷¾�¼Ó‡—
+bEh;m&¶2q@¤}Ï7ëX£ÇuénÉ=µLiØ®Z#‹ ÒÃxLçÜȾÓ>•ƒàÑYô…Í	¤qk#è3‡ãMà¸ò“�üLvq|ìD\0D¿Åv „|uw•­K³KòÉôﺸ씪Ê�Ì=½Ðz ¢˜A‘'¨÷GêîéÃä}-.ÍÒ!˜ 1†Akµ§„öŒÜ̆(;¿+ñ‘7ÕÖÊ(C²I|ÒAÿG÷CŒuŒrQÑV…=3åŠè’>·uŠ?œ5Trh¯©ŽòÒ^¢HNåç4	’/Sîˆë‘~_Ë.ÿôa÷rû»õPãôdìo0gùš²þ›</½‚Wõƒ�'…‡Ý|é䨳 eçK[¯-8(VÅï>D"îbHèœé–š”¢‘:æ]jx6Ϥ0õ!5½‹%CDAçK*Ë3W'Á¤='€.I5p4¬›#CF¢NóÕ`Âv'F.ÛB|Ê]ÞOŠá€íú
#&ãøÆ6“¦P~…‡mŒo7±™›1Ϩ)b´S«ü²h*^‹ÅÇâçü¸ð1~çŠæÆß_ÒEàj¦cþسի9ôžÆP±&*Y
£xkâÇ¡r_�u¦Ó«8¦Ca1è³M/FìÝHHºq˜ÜÂb¿Ïá[�l
×êkû¬ú�ËƦ¡¶¯F$¹äÆÇ´vyW
+†üdË‘È)ÜÑ˹ʱ„ƒ¡¼(«BuV�•ÚèHbNÒnAÂé¨X^‰$2a€ÕóEÑ�‡(¤hÉãcTsë5V»´"ËŒV÷o¿=ÍÊ~€íçÙ7¡èûÉ;ÊÝ/ÁP®}€ƒ·õMDK°+Ãä²4'ø«<£¥sâáÙ9,ìú)t�aúBD.ÈÊ?ÃîƒÑ$ÜjIàsT¦9õ¸zNÓõ%�(ªÎ»é}ìsZ^NÛ�÷FÎ9PJ�‡¦4k[«ç f4e«’ùN·C
Ì«üj}B¨ª–^xÄ€(4ì—ß«qeË:m“®Æ ö¤¼êͶW=§µjØÊo„’Œ
3²8yj‰ê`nûÁâ'YÚTKM”‹ùÂÔì
%�Ù�³¹Â]¢þãEš®ßHœÑ"�P/V,N~Î�¿P�óÙ3ãþ™Ç ­ù¡cÈeü¤S¯ƒ´
+ýÏTa%ª£3»Ùª]�`Á
Q
êó}³x:HX¿U;úŒ hHØõKጬ‰•Y)f.¤«â£Þ„ÇG8îàôº¯a»p7åsÚBc£µ�Î¥7apx
X&_­ð¬)wMÔY„«9y™ÁŸ�e�!Ë×÷*$“ §E¿jéŒ)f?ÂwJ×ÓŽRIßU±($
{û‹xÜ©ÎMYÈÅäJõÅc?—Þ^�Ì:yðý¡_nA7üÕ©Ô–?Ài¤kðÉPHRòÎzçiÞY­Ýû+Öäˆ2…tzW3¦Ž­�à:]q¨¢–½¾:µ;›ôšÿL±î\ì{¯�1üÛüë]¥ôî•ÀJªÏªœûÄøø¾z$A)ŽöNÏÊþû>ϾЇ�Ñu—ßR±Â ö’ºÛua{Ø°¨ï•›)�wËÜ%ÒUùœ×“ǘy‰–wè–š7ô¹ÇÑöˆøoµÃî:5Nö˜~ø§•ûß¾ËPéä—b@3¢€iÓ,m¥däg	àø¤'�®/}"Lø¡-”ÉP&kB;…}ü§D7×±0œ^þ +ú)[¾ž¤.ª×VYzd,Ò#áx]RÁÜõ�]òe&`”2Ÿé3WÀâ•ZŽ°X…Eµ®ÙßWÌ
¿vAJ|,„$={Kýë§Ò/Ð0�Ñ4ͨÙEiÜ.äîOîþŸmÏ)¶9ÜÂOq?¸ ííë[ï]ÄtŽþF™]ðL7
+—ÑÅW%HkÂE©(ˆö6i°¶&b°Þ¨ïnwÓ÷߀MÙð#îVbjXèÿÞ«[k‹ÄA³±8Õ
7j/I$Êý¥í¼ž;‘zJ�FžÀÊÓÔµFÑÌ®mÆ"F̶�ƒ�°‰¢2­`Ÿ¨3pCQŽf�©:ÇvlÔÁþZ[zCºåçš8ÓîŠu¤ì5í¶rÅŸßÛ¾25ùŠ†ÒVÔgó°Õ_Γæ@ÒïÅ™…Á)DWÐ6+Þ­ë
‡ñß¼©MüâÆaªƒi>_ªóCËLD
�CP]ÐúÂL½\=ö›ŠLE Ñ:Ç¡õ>_ç¾”ÕÓDÀ`h{#oÜ1§ÌT«®X²é¦nh¿,ÿá2ž’‰ˆFÙ`TMN>ÜïO?èdÚg>|Y×ð²,"ë•ÊWBJ°‰ëÊw ª7¹·�DþAG—/Øi¬�\¤C§õ�œ.óbƒAÆ.Iµ +
ËÁúŸõ#¤½ü?PÝuØ¡™BŽTÜksmuçÛÇ¢,3ÔZ
+rÍå…Œ†ê#	Rßò,"l�êþ¨¨T�"Â�‚è:‰¹'\â­CrÞ×z,Õ¸
§A:æ‹Ïg<¬>Ú'dPîÐÿ¡1ŸibT,­L”¡ïéd¢º6[*1½[)R«¢x
úJ6Ž°ÉÊlÅß
ùЇº¾“¾%ß6%€ÌZ€ÿ@ ×/Û:œŒ�œPœLö'½<Òpk\yOO6ÒÐÆÈÔ©B"ÑitÚ>€Bµ8o)vç�ùêµFÕ¬�$¾üESúÀŸüY=ÁÂýŠŽëWÝÏ¿6nhϽ±ý;]¢f%�(ÞŸèA¸Ž‡yÛ$o/Aûv	sÙzOÖÆ�’±È^d¡›_Û"Õ3ôܱS+­¸Œâz»ö­‡?5Šž:¡ô´Ä)lI_%�Š¨ªÂý»6}ê™;Ç]CË‹/—øMÊ›md>&ö3¾OÝÑzÙ¢²ÛbÒ¿'•?OäºÈ"`ùÌθrÌJâ˜ô튓yðYtè»;íA�ýºû);†1åO¯º2¶€ér´¥Ró˜”LÓÁ©^šv¤öŸ‡G/„ß_ú±Ø«'.‰ªÔM“k—K26é÷ÿôW�SºÛ§¯÷ŸšN×V¦KÃã|³DZ£…C3¿åB”‰…³[ÏY *J“›Ûä—a�ñüïM–͇»‡[R»³Ÿ"ýŽ‚fç¹8¬™<G×JÃÍ™Úx˜¢#Ïúdç/û#]o¥LÒ( ª–Êô}.X¯²þ“²{ïC\Ò§;ûè~&^,rÂEÀÚÒGØÅž`bhUh×5çAÇú{ÊEkõ¼3ùÁ¼íXÙ¨®ê6~•jË?è[d­{4qó*Šçv¡ŒÌïßì›ê‰ð~�é™Je
ll[Ñ·!²qšï²¼à>^}
µö:›QòbSpìØcø±gÊX?KÀð~íó‡6ÞOX¸:âZôÍ 
++Ë,¶öyL,Z&1ÝÍz*ÐßeÑIå²�ONçÓ‡õ™Í#ùÝ1Éq…•-eÀh‡ÛQ$ß
n:pEä®Àì]05‰°=5˜®‡¶­2P‰5eÃí+–
+aÉÁ_¹5wCs�̲ÕûÖþŸjÆà��ùØ÷–¯ž™‘ÌJþ¯swQ⢃³F‘1b˜üÒ|ëFžøßIµç+x-Jï)#ÌÙªëÃn¾(ýpð»*tYÜÇÎ}Å›Ço¸Æ³jÞÒ±ko{!dhÖ-\˜`[Kþ)pLžXlø ÈÖQø~‚¸×Çl7¬S¹þ›¥*¼”>§Â.öÝìþñÃd
i‘;`‰‚j#–•µß¯XB`ZdHnh“¿èI¤Ž$Ì‚Õvz!Œ^ !�+NypÛÈŸVͧÁ`f–fU®äi l'Nªw!]Åú�ŸÑ|È'Žb&‘$US —ŸÞF`
'CŠ‡r(¾Kª‰;Æf+e�Z´X‹�+�öÿ说oÃ�
+®0QU?Åtv¤T1_¼Yp¯ÏÑn1×’äê'ŒWÔZB¾y¶¦}Âw’ë°È‹G¤Î�
+f‡dúë‘|3ÝÖ¬9»pï°h1ûó¸í•½ÈW©”qn‘9¤pÙ²Q@ýDîã6Ó>ëo\�,«m÷º·óSP¼ÕÆé‹cŠ˜/»f€�¾-Ïxˆ®;SëP´JáŒU'â#VúÝ](ëeQb}�–¡˜hïá\¢°»­ŸÓ¢aKY3Ê´R°ÝĦŽTWòã?É�ç4ÙÚ¼~p�ÕôÉs;.“=@K?ò°ÞŸmG¢«Óg‘n1»€˜ótÆ[;ËæW{¼«ó¼¶¤êqáãï876}
ÎÆEòY‚i›XëzPD}ÕÓq>ÌÖ=�¨[ÓeÚÚÛ-DuoãáTç+ÄGQ½Ma.Ù¹êÜ×,r„U16W Ý¡UPÎQâ	sªÞûÛT—ž´Þ>UtB%®Q?™†o\?‡c
©ãàò
DíDÞÌÁ<¨‘‘å±cW'}¿ü%)yõ(¶Lz,£›Ú÷=Á‹º“Ûˆƒ„ªk_mÖø'\ÿ�g:óÈm§j³.”ŽÑ}½�³‘šÞJAàÈ<X¶ûUõP=ÊþŒ¬ÄPC_*rËTs×çñ™¿l® ˆôòݽݵJ^‡Yn½Þë”iõ�ùÖ(@.ùÆéWšG>¶¨â>ÓÇBt^¿æt8Lyäån¨ðª�~ÛÓœ�„×RD"Ÿ"nN4�U¨·áì�Dz
+�#ª5¶ãƒýŠŒ[ônjŸÛ\vù$/ãRÖyÕ\-¨üKŽà|B8x“AíÁ.O_JŸqD×=®_ž~:? ³7—2⊦Ý|�jèÚ~e“hŒ¬Ò`2Æ`PzwL˜,Á”‚Ó­à¸=] {¸â>uD-‡UÙð�›Ãí÷Qri|&
+Ô>ÏíFŒòóGL2Õ×i#yûyNÕÓSá�Ä.ì(¢ ê—´®u߃]bùž<hŽˆpÎ<Ûê/Qmé‰ñ3¡
+úÎŽq¼E{¾	fáñ$¯}’škªÇqŒi†ik›�ÈV+Rê°ƒØÆDK'æ—{áß
Ó~±ªßÂ�5í±”»±ÐNû†c¼�«PèR)r°s½e¾ÉQ­‡‹ö®â߈T~7`ù½¤w~( Ú/פöHóe®B'?/ÇÃ0SÏ)X&Þ‹“f•mhUöN áîË…;<§�­ŒLÏYì‘û�Aߪ»=øþ�Î~eY�á€37¬àq�Ê„ÄJóWmÚ;
+ò<e{œBÄ4è6X~S…ÕÓ´¤mF¼§k­¿üJ‡­"fÒ탽tâ#ð<ŽNÕ½¨)­“o¹ßÖ^ÿˆŠ�A«-|o¬÷é&ÍS&Tí––
+ñ]X}UÐDÇgS_x&W_d;½´Ö‘tˆ-…%eC˜Ww:�.{ñOÎþ˜­¢¡t¨_Døiņ@×}Ýò‰ÃÐ1ÊÇ$¶g¤	¥&·á)^D ´¢¥Îô…ë‡ÔïŒC¬‡“Ba¥†øêLÜþ®‰nfÂhš*ë(¥=àëڤ̋>¹Tè²ÕV YŸ(uAyFìT½ª7?‰ã[×4¯#ã:ªÞš|1¥·cÿÂÄ=SŸ¶Q,hÛñðh�]©¤ßûàzÑ÷ùÝQywÚë\ç£V}—À&}nJÎ_#2ž½+¢û%Ì°Ë=NIW™H9ถÃM”†òó?¹>HÛÀh[�ÃdýÀ#þñøV¸°ÏjT̆Š½Úß'9Q£•ðD
+ƒ¥=Ûe!sdê)‚.l4lóþE¿‹'@ÑN“Œ
+�žKXø4¼]íywbZâü™rœ¤ÂQ-<µÏ¬�À¯
´)"‡£]·ˆçÚ\¹çyy/Àbý‚	.G¢×.èßY÷®!	É>a'c6CU¢y{nÞ#‹MÝ¢UüišB|!#	V­}'­5®Ð±äNÆ ]túPÑ:/­ò¦X˜f9Žó¦ž�Wv·Ô•©:N"õ³g²N î‡íæV¾–HYÈ.J°M¼FWÁq
�AéoÑxJ!�&Wðˆâ­Tþ“$(®mXïe{Ì××Ð8]/^¾g«Äo�‰M·9}SO‹ý‹³n£zbÏ<3³�ºÍö½9dÏD�y6ÔDPM:�Žð˜S“ wh…µ„cK´Äã‹{:Qö¦Ò-‘þh[N½œ;M7 !ìX¶lç
+ûÆnÅOøÙ/šåvýÑ;Á¿Š(æÀêzÑÊ–>ì9¬Ç”°n÷ùv®Û·Y^+ùå+ÔÅKl—‰æÀ+gbïç6Å”E”v�Õ8÷¸Ü¯¸.ÔF,ÜcjÇqx"3¦Ò™L•*×5FžÅVÝMçï©Év%¿ã´Þ'£N·ò6�iM¯È-ËÅ8ò̉Xµ3<³ƒE´p“®Rºçèg
+®	v'ö½Î�ln;mÿ�FN•
+/Ÿ3Áô�1êˆõí‰~4HFz>5#Ε{}mBl+ï� Èà+S>îϵ³3™ýžYZÍ?º°ü|(ø«8EÛN¼-<g~£PØp*Ÿ<Á3—æé6ah/Ä°l;�¢,,r_T¯Ý�XƲÉ%Ï™Óßæc†�¿¾g–µÚÃw°QY>Zr^’3©ÒÓ83ÅX£n Õ¤îc„Ô#gAGŒT3$�kÿu‰mßêÃ0¦ô%BV¾®”ÍXK
ƒ²ÿ )¦|¶
+«÷îõç‡k¥¨9îx]RÉé
!lŸàk�<“�™H�ÏÕ2Ú3'Ð_}Á±n
wYíÖP¤z�™$z¸ˆå¬uBZö˜ò,ïД‰ˆ6”E׋8'<
óٔ᭦ó'îôÇÇ)§Óˆ%£‰[LgPÌùÃ[VëÁçµü÷=iˆçv¸#¨�<¼‚¿ÏûN¶Ë9·©\qwqVb§E9¤»çóÆØ';<G\ò�p›Ýk¸ì1Â\©øÓˆK
+ÈÂcR *7Jô1B-[Å\‰Ë^áÖ:	QÌ�DIB–-Èsì.¯õqþeÖÄ*Úzá[L&y@5�þC5
+wóÔ
+Áéãå)«#sLW�M>†0€z!1q*L»_E³%)dª8„qb�"Béãkë}™`_ölz?d(dð	º¢¼ùŠú·nöM|Îëv�
N–È1@´é}Þ…gðvÉ–ßoµµRj¸Mk5"YŸ~bÐW¯ÔÛǦ¤}wQ1øA³x/ÆP/3Þ‘,¼#[¹3'Ì™^4ªýJw“çM›vŠ%Y37ÚZ-í!�ÚZ„¯Nêý÷ÆA@U/#ÀJG4½øˆ®Lš„(Ûq¤—ZDÉŒf%)1[1$EβU?ç]ùÅÏ÷àº|/»çº86
+ÏÆ^é(t{äg^Ì)¾^Äyo�ߊ“8E˜‰YjÚ é]ÁØ¥ÙDf’øiÌÌR¥®Û·‘•¿#ëÊቛ¯½ð“_“9>~"iú�
+M)Ã9Âp:Ä'°ÂyFJv5„yfù¾ZF|šÿ˜Œû�;àcêØBüß›©î¬ÃŽNÌtèÔd/O7ðŠëË–“Õ7ÑyD¿‹3<B¢
ažpøwâÎÁû~8J­_¾\÷ë\·^M­ùífƒ‚Xv\Vr€åÂÝñx4O?ï:±ªY¤xg$!ZÏ6ÄÂaé’±½òÚKvª|�R¼Æ”œ k½Ò°@·&¥1ú-lß0ox„Èæ»W`š¯{òø»�î•ÒÏâ~­E	§…[2–ÙÚ¹‡	h|^ÉV®ÈÍ/4^PJeë	?³cD\r´šdûhhç_é®êû¦U²SýªÛžhšúÔï:é#ù^¦¸%Wk`}Œ¶Ïá­ê�ÅEM3Ê+	`‡*
+G‘áRì
›¸5™UP®ÇÇ°H„×5Åã>½,TGè±8ñª4ô~È®š††,h»®ß z¿š
l–,hËÐ%ˆÁC}ìÜbÒŽy’Ÿ&þÕ
öZïtï|çil¸#é¹–8!}BÌ’ñé{‘ˤFX.K·¿ì�ܦ|ºgÀM¤ûÆ¢•Ü=ÿ=²X_S`ìÿ<ì)ú¸Ô#�»oøý–‹¿ˆ‰´ƒAF;ûû
�
+Ûwôd¡Üw÷xgXøÉ\›ôi3“ŒIDί¹N%àŒ±éï\á>Ø°tmÖ$¼ãÅ,ñ�á�…uÛæþCU˜Å6é*x
sÈé4矾½–çëO�f%,RKÁÖñ¦¤EÎL_2¾›Š‰iŸ¯œ±zÇÍÃÁs}~±
à)Ë~ת0üÈ»€ñ¹R.Ä•!/`9ºz\h­õx–jÖ‘þ:9OñÉÉjð‰¬”ÔÌ°–˜Þè.h1ýdftX*ÿ7=™q
FB1w)ÝúiC$ü9œsðàÒŽžQÔÄÚÂdÝ@BN~CªÝ©.ÉÊ¢^r’¹�º¨JªÂ˜
†C4|¡"‰j&m¤cYõ"¡
+#‡O/$v$�R®cià¤Çâ÷Û¹6AçU‘©�®¼n„¥Ä£Ïš��‘mÛ«ðáäwãëuÃ&µ!¿®êÐ0š{©Ld"Ö½þ¤´4¡æmTu{5v÷­õýT_ekp¤¹¾r§Ð~Q�4ËÍRK2'¿ÊÀRŽõ‹l9Ù‚
<£G�{{©ÅVØeÞ=þ½ãøkæÈr by&?Ý!`�@Ê‘Ъu
+5«€ßbÑdûClC‚eÑ3›i“É_É�>`"cGKó‚+îœÂ”SË%ëŽX½
úð±Å­¾ç2]p×9¢øõÛu“°WÙ8å{‘+cc"]•Á½[ˆ‹uÔ§Š®åëÜe\¾"Õ?M!©Ø‘5Yñ>>ƒg�™.faSçõ"VY%¨öôÒPâÀ}ç_~[Š3šXh¬Xâ&4ã‡4ó
ZòU‚õ(c˜äœMÈ>õ”D{Ê=ëÚ
+B4½0üÂå�Z8CÆzh¹Äõ ë­ÍÙ”™\ÛÑíÎ¥+ò—áE¢ì¹:BZ
+ï!ÖdÙÌ>‡·‰—´ß•D¿l,¸Y‡þl½P ºñé:®DÁUÃñî+k#/™P¼|±ÔTa=Õ*¥­T^훳ø®Q¶t°HKZ®Åœ~`LgÊ`ømq%['=§!Y§ù“%–±y
»�¾nrI
 endobj
-962 0 obj <<
+1017 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 1930 0 R
+/Encoding 2092 0 R
 /FirstChar 34
 /LastChar 122
-/Widths 1937 0 R
-/BaseFont /VYFYRB+NimbusMonL-ReguObli
-/FontDescriptor 960 0 R
+/Widths 2100 0 R
+/BaseFont /TMDQVH+NimbusMonL-ReguObli
+/FontDescriptor 1015 0 R
 >> endobj
-960 0 obj <<
+1015 0 obj <<
 /Ascent 625
 /CapHeight 557
 /Descent -147
-/FontName /VYFYRB+NimbusMonL-ReguObli
+/FontName /TMDQVH+NimbusMonL-ReguObli
 /ItalicAngle -12
 /StemV 43
 /XHeight 426
 /FontBBox [-61 -237 774 811]
 /Flags 4
-/CharSet (/quotedbl/numbersign/parenleft/parenright/plus/hyphen/period/colon/B/C/D/F/N/O/R/T/bracketleft/bracketright/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z)
-/FontFile 961 0 R
+/CharSet (/quotedbl/numbersign/parenleft/parenright/plus/hyphen/period/four/six/colon/B/C/D/F/I/N/O/R/T/bracketleft/bracketright/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z)
+/FontFile 1016 0 R
 >> endobj
-1937 0 obj
-[600 600 0 0 0 0 600 600 0 600 0 600 600 0 0 0 0 0 0 0 0 0 0 0 600 0 0 0 0 0 0 0 600 600 600 0 600 0 0 0 0 0 0 0 600 600 0 0 600 0 600 0 0 0 0 0 0 600 0 600 0 0 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 ]
+2100 0 obj
+[600 600 0 0 0 0 600 600 0 600 0 600 600 0 0 0 0 0 600 0 600 0 0 0 600 0 0 0 0 0 0 0 600 600 600 0 600 0 0 600 0 0 0 0 600 600 0 0 600 0 600 0 0 0 0 0 0 600 0 600 0 0 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 ]
 endobj
-884 0 obj <<
+939 0 obj <<
 /Length1 1606
-/Length2 16371
+/Length2 17112
 /Length3 532
-/Length 17252     
-/Filter /FlateDecode
->>
-stream
-xÚ¬¸c”å_“%œ¶í¼iÛª´mÛ¶³Ò6+mÛÎJÛ¶ÍJ[oýŸgº{V¿ói¦?ܵ~'"ÎŽ±ãœuÖ%#RP¦4±72³·s¡c¢gäÈYÚ¹:ËÚÛÉÐ	ÙÛ˜
-–WД”PŠË©ÄMíL�m
-®F6–Æ
-…$ØVW˃÷æ¹)Àõá}@Jš2»œœ$~P–D™ˆ‡…:Nq©ó#5ßì"	󧈼ˆÎQ僶J–©Èµôc“Êç؉/Wñýê›X²˜HO÷|¬®-“[ÿƒn2ç¡‚÷`Œà�
õÉùKH}&¢~t–ßêÆ“-µZ•÷�ÎäÒàMV]ÓYÚñ‰‘06Îó'ˬy?‚²9¼oºÝ²Ï—YzÉA€&s5õC`ýnXÙ°ðõɃ
í’D,÷gÚUÑ{MX8“Ž_ZœìÊø)“bz�lS âz/ˆPr m¤–ÕýŒø86
]¬
-+½ÄGL~Ö§æ0GW˜RS4Œ–¢V˜,ŠÈZzU¨âè(ŠcÆÀXÙˆ-jà±*ç+êJ"ÈhZåðIƒ ïŒ
œƒŠñ]Ñîç/µÜhà÷ šEh3ŸiqÌVHXn´Nx
-ÿQ9ƒ]ne£(‰ßU;<kµ˜\û·h8V)‡5ª#ñá»+[?C6õy‘®G‹gõ›ˆí¥¯vÂó†Ù�ÌHÝ—Q`£n(9åÉ‹Ôª†¢"ñéÛ>aXSû¦Ÿæ¿rçG.�môú¥»ÁÊ|a™
â¡^>#þ»ˆ^驵]M»qÁO>Z6Úl ¯=µ)¢_¬¾rÔ—!U;:±å$z2»?Ô?÷,|gP¨Ö:`Ì�G*p²Sí»Ï³œ.ÞJ;"8çÉK­�ñs·Ìúe”%±¶ Ü-.EÊ’JÿLئh·ý,hïY«M÷s<ùi“©Ò£úþÕ›j2�žE)m
œÀî;Ÿ¡å×)× ÄãÜùšë�_`ÂýÜ�ƒ4¨G³0 œ{¢zÀñ®yÑ C‰ÁŸèP!“2Ž¨Ÿ*§_‹Z夻'ªá¯›ò
=2ç#µõ-»Œ(…’jáô˜iÜS$J
-éèóQ.ž¾,Èv‹®Ç'Ÿ¤Îûz5+Éí.þÇÌHF.'_6®DWeN‡´¦j×I*92RÖ¾Ø.}ùÚu¯c†ß±©ŸoL¼`Åa\¯²ZÕãLƒÒË+-(þÍHUëO˵Íè|ºZÖe±šÜ.¢{sN"p6¨Wvg‘¨Ú�TzVóeÿºŠÉ�ßDbþ}fìkG�a<ÊaÆ#sSs&ÓçQ�‹Ö:“m€¦ý)®ý]ѺΈ¼ÂP€œ_—ÁJîY*ùEÇd@–NËoÀ*EëgšþÐ*Eì/5
-fe}®ÒTÌòl"kã&|]	‰Í0ìIâ8z}ÞàÒÛq­IIØ!R9/�žðb¦¢T$ý5—yYÀ;cÉÝb–Õ©¡á<GÄŠµä™UOäÅšT‹Ð	º¸jnm0±ˆ¾ô�#>xyÑu¢Ì{§›�û}ï<L	zcf
-—[W´³1fóÔ=;:[?ïAÚ¶€œ"§u°œ~ð:ÕÅÕ§A:‚¥¹Òãb	ìRœéÞÄJú�àÀÂT•º’8ȯ}j�@hjž¤v!äåõÊg>-L«YO×]1‰’œâÕ1•°ZÅ	ÿ*ý²o�ªìž²t
É�Èux^I'ön2*°5ÏY\]Øé½o
ËÃSÖ/CÂß 
-K1Pm™`)9öã*ïÀÀ˜9ójQc£º»5¨æñxkØk!>Ìa±dQÝÌ¢N–�ð§óΫÌÜ‹FÙó˜TKi•óLsè¯KÅÖ_T3’šy!—ägÀÑ&`pÆÆVRË
‹b¶ERÐ'Túv¦†\�
-^‹2÷p‰7ÿAäœQˆ‹¸&jÓC+Šînöhù=Ò,‚z]QX+dyÚ4lÞŽö
-�ÚNÝÑä0‹ø¯ñ$´lÓápàá˜7-ÎN*¡_~�}ÜviŠôŒSõ±ø<ÊqníêãâT2ª/ñ—Xà£Á•áºÜ§¥(’Ëæëya÷Ä6Ãé˜9ãVr¯°Z5l:¢�1Zuâ�Øó¶pÑß-ÖÚ¬æ¿ÂÇkëé|3! ëé}£?µ\RÈ(áÿÈù€>ƒ°šp~O»„¦jx¬ƒ qøf
-0Q1w+övæ”Nuê{„'®wäÕÒcɚΡë
lnm
-[1ȯ
@€ÂZ6Wj™Àtù'î,ž¹t$P} 'g"])²¡ÏãèæiØb¢Aù:5¹vòQüæøTzÿŸ^=�‚­².iXƒ×GéJµL«Šï’®ý#
¶†Ý:Ô»‚�u¼û.×'“Cãl¡Kè�m²¢4¸Ž“iašµ×B
É>íJò�j˜Û7¤&Å?ázKÂxYrY§EÛ^÷ò,,ne2üäέ†¬<Z¶×™øã‹?à¢
[c™«U¹NÀ¤ÊÉÙýHmaCsT|79O|f¬®‚’³i	ÉpÃ(ë*³’²!í:•ðt;Çün»L»÷Šæ?��öõ9ý2ÙbkÙ±!Y‡—çJb²Z?³Ÿ
-	Õƒcf„W
-*€Œ#Ç3&ìߣöbY�Ê_w‘&[þÜÈ_lˆèyIõÞqù&;è;ˆ¿/ÎÎ"Ëüè‚ð7Ñç–u’DŽzwÞŸ/é¼Õ†x³ëŠìb*]ü2)u§·O¨Wñ5òx‰1ò4˜•�3MäŠ`AÁøý4g<üÔâ‡?yi�ûÇ©¹$sç£ñs}7š
‹•†‰µê~
‡¥’ž·÷•ªm/�:N–lÀD t˜p
ÆÑùö5Æ„
¯ú9ø[ìœÍý�ßÖty37ѹ­øCËiqgõ Þdx‘Ó²¨„$¬Üá”1ëR• .Yú›ÊL�ûo›03´Â£X‹,‘ÖpŸ—;ôq¸ 5iÉɪf1`CÏ_®9^¥��u¢­­Ï¼%¹þêlóùŠèTžÅbàV0v¶?ž÷)mÌ?£B—ÎÞé
-àò0߬éwŸ³=ÛåËLX·AõfQÑ9]Ч
-sxX
‰Z–¸¤œ�!D°‚¶åßà½y¶õè’Ê«ÔùY-”¬Q>tkøH†•¶½@Sÿ6M¯çÆo퀱1“Z(}‡lš‹HñxŽ¤pOz’.t¸q(ò錣íB�.¸Ò™Å™ôÅ.ýX\Àª�ºö’¥«.ïÿ…ãÚ£È?¹¨®XH.
-Å׆ˆbïÜ÷ƒˆwêß
-n
-‹÷ƒ}öÜü\XGÔOCèÒ9®ÍŠ]Âdç šuFðê£ì§1œB'ÿ[©pT‘©#êìÊLT™µ+àaGØIF“FÆVåÑi²+®ñ^
-ÒÇý2¬‚�£Ó°ï�‘–£ïÐé… «’·éí«2ÒuÆû˜™‡ŠK¹‚™e
…þ’sêƒQµb•5<&—´‹è‚CK°%ɉ$ß…ÅJÄèè¯
-êRµù”C°†F¦)¸Ÿ5/7Õ²ai6Œ`U›�Úq‚¼]´nz€?öÉ
¿QŒ'éË‡c�MxiM
-Õ©Á<@J´¨ƒ¢	“ˆ{¥“o=‚K]—-x÷¹–’ð꧆)fè¾ZøÁ×.Ré*nßs¿š –apB üÒó´¸Ü
-4ù™ÅBj.B{J+–$hR¯*U)›–»À°ð!>PýuH€Oi·¬­x¥Æ·Ù€F0½Š“¬/!€k¶†.œº¼×tæ%ÝP"�˜®_cc_ÜV¸ë׌GÙõ¢àÄŽ_åk+ß6¢½J†ÿŽBhWˆ~ƒÍ«#b8Ý=¸åª
þ�œQÖ*È-"4íÙGZwò�¾P_q¯Bw±îÏ‚$ª$²u(ÈÙÆh?ZVÚÇ�´ƒ. «¶ïDæáæx£án¡Çò½Ã{Úmw.v~¯Q?óó°�%/%àÃÅðo‚/ƒ¬¸tëÛ¾ob¾»ëñ�XœòLšÅ©cx"Šsøy™á'n�²è3¶
Ÿ’YNuRŽ½}øªNµ©¡±`s‡¸ŠÕù¸¼È1FŽ:ÛW.Ÿ`1�´¬x€ùe€Ì$ïµ_ß |™þu*Ö~èîÕ¤©%•Ø©ü�Zf/ksWü0ÿÙG.öËÖPî±w¬¡¹s9™†£?<à2qŸ <˜¸Qþ·»
-,óa{¢ìÙÙù3†Õ}œI
	Ïà…u¾§	ΞОœ#“/!ZKóÑ�îe¸mX]†KjÆ—=P.G8­t
-C‡‘7MBñ®Þ’¨ÌÞB`Ô4Ü]òP~OăóOò^Æ_n+�¯ò݉ؖмprÅÝ<œJæ­³y¬l´ößÇ׎d6Vþ¸£ÈÙæÅ­X®üÍM#§f}ed‰J7Ò™ôT¬Ö©lÙ‰3·|¯¿Ì!U>„{ñWaa§¡VÔìùo'm
#K®™ Ú"åÄw4âïâÓ‚Äšóã
;üú­ŽÙGF!…Iå÷RòªÑ
-uŸÆŒ©“6Ô¯ùÙênñH0ûg›±së,)SÚŒxÝÃ/kzëð§ î#&ý!zçȳױ8“2jY‚G¤u¾˜â%ŸéÃóÉ7!Ißú&^úu*æöCP®»í½§	]Ö†¸Rða\ÓD!)�å1»ù”b$l1xZñ‰ LñûŽ/-
-4‹z�H8‘–	š‡‹ÔéA ‰‡A"Ðj�q&âGîè¿„‡­û•™ËË‚˜ÝKÖ�ÓÓdz——s;ä—¯ÜQ¿
-Ò×%¨•½xòª=å$«·å
-6¿Îá;8td.úÉÆj’1ƒmŠíyB>^bÐqÊåLà‰bƒ4h/mHÖ%B¯-¦/Â9€L:»¤Üó¡ÿ÷]mÎ|ùY.¨#+Ÿ8úT¹Ù9}FmOj
orn4ý
-Û…Ú²)•>PQÑSWüÂŽà8COÚ9Ì.½zQ”OÔ
B—F,ÇD“¸”Ãп€[Der-ãɉU`�øîìWr! ”‚ªsB‘–«f—¹¼Ñ€Õª.=K×$"Læ"òY-Ñ;N4·*r&þ†Ÿ+z
-α6
``…¾ÞïG0­o¸N'‘Ñ{-¢ŸîŠJf—Et~£vÍšAOÝÑ´m
­Ön7S¨D˜sªŽ’9F÷¤ûFš™%¤�[Âv¼˜d„žÌq£]‹ù„Á"•©!w67Ë?—ˆ«¦‡�š~Çt³‰=Èϵè|=WU�Œ	,Yª¢j»ª¶N!GÖ©ºCbtÍíÃþŒ=šhƒiu5Eé‘pºÐ”:ÍFAr4`›$ñ�?¯6¥·Õs•ÎлÉ,³¥f›LóÍ«ÕO“=Wþ…ëSrªAñ:½5­¤s“Ê"oxDöõ¨‡$8Ì�bµ*Ü9¡âë¤cvˆÚ(’ ÓƒìFÙ

÷N÷GÐ�sÎkÉhÕ»ù.C3
-;©4’¼ÄÿKýI·W|%½cøÅ]h…GœMùDîa&Ru�ãu>€�’-ÛSÝpÞ¶
-ŽW–%ÆÔ^葸Ú"¼E* 8
á	u8�üÙ•§Çì'Í
o�›u
-yDœ–NrešB#êè‰<2«DSµ¿pt†÷�-ªS9><o*vY\Wû^n"5ÁÞX2.dKÕ¸ûé:ƒ ‚˜Lö#„ÕT–E0Èôcó#¶ÏWº"÷ATÖ¥rlmÄ$£‘éYeg2B¾¥�[{á=ØܹDòF.Oû3íQpÇ�¢fÖBE(öo^;’S³§ßÎbf|…rˆ÷}Ž4F]žvB…„þ´ñ~M
U�PÙ^íâDaôXUùóžþ£Ð®`­{·Rª”@Â?
Y—º˜þ›Ï¶£Þ|aéeì€ÜùZmlô*ŒË×B‹àŠè]‰¸_ {%DOù¹‘nºµÇë÷ü3ó7O¾ŽÆ‡8ë›~žžWF¢p•&00oD³!ÙÕ~ÏÙéa­À3¿�wÍüüýw¿Œå/y�#(Ån:.PÜ™¼@Â+)ê˜Ü(Ä‹Å"‚Â]”t¶
"•C«î¬‰�>Ö
D’|ËP¼+Êë0yÊ»ô4ß{¥mÊ÷¸s ôIÊŽ$¶â$dÃ÷‡CîE½*ã
-g+�´sñ¤5ºT£ÃHÏ)æjAº1K
-ˆ`
-e_ÍQPš}IAÏžc°ß‹zá#P}ò †^eî~µhÎ,ò°Š˜€CøØùf
-}B$oÒ1>ÊóHM{PmÏårœQDç|Ù¼ð
:QS�v€šâ’ùP‡Ú6>t>Ë
-ã0Ï�Q®œã_%+­oHÞƒSm3ªþ¼øÚe'¾¥LmHdR§ù‚óÃ*�¦Ÿ? “M¡.ɼÄq4I¾8¥Ëø>ÀèzþÅ÷õ3ò
„_·eÝGnGky}žña“D9ä÷ô½ëjT‰à•ÿv«ý
Ù9ÅÝ77�½ÂIq)ÜÉì–Nâ�)	Þ‚ú!ÑçÌáeƒÉüý
-BÎ÷
IK ºÏ8V?Ò±ÞH;3¥YFjàQÚ;13+ܼ—/nIû†<Rt;˜v³s$*ØNþE�äNÎ>ñ{,Úü#0lËßJëšä(šYùXu“Ø£�gŸV<î‚<½°ÊyVˆMa[íSšYMJäÒwnÕ‚Q~dÈw€c¬h°œ§× ˆ]KŸé3é
-±„4GjïnŠŸ�Þ¹
­^v³ùÌZgØ}¶�*b«ªDýŠÍp�qP`Cκ,¸„då=œCΓʨrÂ\¬qc„ƒ>e-–$Éÿ…­¶FôÔÄŽ�QÐÑÔŽÛ„6}9E¡€­:¬v�°6ÈöŒxvý=\Ò›7ÞÙJÄ6ˆÚŒåHJŸÎ)½Jßj½˜_%½@l»,ÖÙký� ¡Û™Uf
-êáE'ÒõÕJUŠ•�la"í]©}Ë¡—ÅÅ`;¶f‰È<‰âÈÖ½ûAy�ãA6ÐîÚ±lì„S’ÜZdõ"àBk
-U}½òõÛ02y jp³K´=Í5eñnª“ÄJã^°É©ƒRÓ3Í’cÛT̯ÌÑ+�ik›=tcg�E†tÁ¶£Ë g§›0ý#å�“ÍÝ,½âI<©
Çñ9OAÁ÷XÉ�Uy¤”�ÝaN!
´ê§gÐI‚Û–
-nÈ” m+åÉcßd_µFt펆¯9�AFˆKÊùÓP/�` :òÔ0éîyÖ2É'†íÉ@¡C®�½SàT>…Ý4�™à�’†µÒšæ=*¹à’
-بïÇ‘ö"W,GÀÚgçà8Ó#þåiÁÜ,ÿ7äŽ\ñÆ‚âA}ñ</æö¾ÞA[q<XŠôâ/ÑH½!»èéü£RÙbÛÉétFÄ´ûuýˆüº‰©ÑÂy ±'©%âûÞ¹Hù*Ï$vRïÅ&©z
-`ÿ‡âÞ[
B´†Îìz%}”fM°–Û–BÆŒÒ�½Ô™)ì9R{ª+YËÛ.”ð†$Ž$ì–o�¹Æ>eûeç1T±NÀ°óZjbêTSØ�‘DSÂo¿Ÿê¶@v Ú•ôˆfP„2<ö4MÁ T`¿SvØÑÔ‡Ã\&ðHmøÆ
-E R^íÒ~áWžš';>�àð‰ä™ L€Ëÿf=ºMi)ÔH³w‰!ŠŠÉúæ´øjÑ <ˆ¸
ÒÂN³@Ñ6#;Q¨
-rcÅQH	ícûOÔ†ŽÕÌ|­�‘@WËO„]–ü½[@™}?ùãTuÆC“ˆ¡ªðÏ¡0å¯jAÇç%´�D0¥€iB�3‘à>!u㉽®Èßó’y1ÕwŠr;üoö)w‰¯öáJ¡„SЮ|ߍêZ‹%ªv8³¹¬Y2WQD[k`b‘¤àPx±¯lÓm¼µ{Çq&F|¥U~zZãÅ2m‘§§àwL€M:�«Þ‘¢:‚¡ˆh¢[Hò8¯ØÑ‘~ÜØ.®åŒ2»†ÍFW%°P¦]­lfÚH,´Rr„Äå<Hµ�ÏÄž&sÂd™±oGÜ}Éü±~ 
qŒ¢9‹´†H·:i÷.yñS>Qo«¼]µL÷c½ó89Ľ¼½~–RA²ª¡0ÒÛr’Ft¾‚_±<4ó�ìWîÝòiïÆEJÎŒCgy,7Ûĺi–O¾ÃÀÊ/Z‹ñu9X>±fOº:*Û› &ÔÁY.O?8K\{Râ¨jÈ7„K®îëlÛ²³ÉœËR;>Ôг2:œ…Žè¦ÿ`¶´ÑÈÆ2#ûûj²Á?<9€õÚ‚:Bî¡EQ@8á<kûÕ³ÝÍWóäcÃXeŽÌé.¤C�砄ʨ=±E%%²Älµ–	2õD¿&R»½qd¾9q—·}{´W*@—…Í©-O_nK,ûlT&~²²3gÂ{B€K$±6Nr_)¢LœP­�Ÿ£³zËN1¹,ÐA˜•¯W¡V*eØE1ƒºHÏ.z ˆ¯ÆGŸ5ÆA‘Ã{ÆY+�ì,l)ü�dÏåiKŠÝÕ&Ú2¼ž©Ïxaì2ç].åëVPÈý½.è\ssã%‡,“7{÷gåÃ
DȘuÃ'ð²—ä\=ßKϵ¨^f>ºŸIh™h7¹÷¢HNõ™
-Q?ôVïóTöIK¿òöÞM•|ieÚ‡Ÿ¹Dœ­2^B È…“	äOøD„ñ��Hñrø»ÌÞ¶á🺞[S§¨”OuáLïxÕt‘Àì×ÙÆ·Ùâ‡5�5ùweʾ?)•f<p·¯Ý­
-VCV^uNA	a÷¦BRj÷—Üs•“}”}Ú"zÁú»™9î`ÎT	ýld—>_¢’F|�·ßƒcè÷z):§Ù펰‰ÇÙîo¼{å[­Üûš”½yÂ.àB´�4
-Ø©U¢•¯‡º{YzEWY2e³ �º%½8ŸùßJ~±`„
-;Œ€ô3Ã%m1
Ýè?ÒmR�ºêc\žÅ
-Ì ¸¥õ£—»`4Œ­F™Ô¿ãR<sstB˜
Æ7/?+òŠ¯F:Ó]LîgÿéÃCÛS–Ú•Ó‹,}|` Þây÷8õ7�h›pG–JuÕ@,Ë�Š3TÙz uëqñ"�:<5}D?Í6Œ#Ú¼i1�²‚Ñ£›r>¾<Ì|£Š [ÝeRäßn@Ë\¿T�OØ€¦qZBQãc¥âäwÞ^%<tq\v^�Ôà…¾MtZ¡Wï¶ò �ó )ÍÁ8a{øV’Û˜Û‡8ì«îFâ´#•‡Wx½
-k1H�¤üô]–®$ÂþNeáŠ�t_?-{3h’úžû´ßñn¾ÚJíЭQ€”l(SêQŒ‘5­…Š²>¥­(ñƒZˆ¸Z…+Œ,îHÿͦ.—·Quç¥Gž™­½¯À+÷Ç×÷e¶ƒ(Å0®åÎJ掴9>ò‹qD~ßqÊlC¤þ.Á¼¦A€Xe
-D·nuWŽÎx(ȱ䒸W¬JÇ~‚¿‘º£eúT™aŸƒ^ï½–
Þ7ž§ç~hw™™_‡QÌ¢cñsÌÂå)H&^Æ1¼žC©g³¯®{‹DË
-Δ(47ö´@¿|¹­rƒË̓æ�U€ü;"H‘p�w›7l®è¢ÖÙ±_3 Ë²á	“x°÷�mŸa[­<�B5
-m©è—ðò–õáÇYêšstùá&%OŒ¶oëˆð•—ìO»Î[‹¡
¹:Ñœa#�âiîÓ`5ð½éÕ;)fñûqL˜\ Zž®°	@D~äõû«~ Ú¬u£¥,ºa+ט^¤.ïj±%šE–J�Ÿ5¨«ã_\A�á�Ž&©b´Hµ‘cïE&Ù‡¿²±~0·Ç2:y$¡0ËUÜ:Öã­”ðô
-Dղέñw¹Q‘Ƽ#Q›4Ž‡!¥VŠzÎEhϤŒ/RVÆLüˆ³MˆUÁj÷brkLP°…žz1ï/Qº™±€°šÑ@vbÍy¦,ÙQ«·/nÍáD'
-y“�(c¥‰´Á÷w„{n„Æ<iïDʲæ£aîþÊ`àðä=:ªH?Äçðâ€:n’TÚö:j>¥ZrÉO<xþ	¸� Û7:ôžPZ(´Pä%îB¡Ô$l®×Î�£UõCu6ÂwÆñxì§ç†ÑÐS­…Ã1@°UIÌ+KÏXŽë_`“BP'�oJÊðÅŠ¨Òq§¤3µv‘”_aè‡WUQŒˆ9H0݉P¯ù½gM9µ3ŸS£ã(-“ŽògPº@eãÛž°.µB…8ZQ•AÊÈ
-ö™…„-ì‰ÛïzD�Xy²®
-¿©²Ô
-r
_å~ŒÙsK=pÿëxoײ^�I'níça„SpÃ÷ëáòþ½ñ3|K0À¦
²=z,çÝ•âïcíñÌIér‹‘�¦
-Ѐ­)-E›Dë|8¤FH’=ÊÛÈã·pórHÚKG
-0öÞÛù®_3g(\¸ÜÁ¯úàòž–Ç
°¡³!}0}þ8ÁÀEþL†2Ì{
-WBˆuÀB="÷Mª†ß|j¤E˜&µ»“=W¸õNtéÁ¶5dPGŽj¿wj‡Sy®¾"‘Ê UW#¡4‚0‡©¸¿ô3‚´RÅÒ]ʽM§ù
�Z–T‹0ž0Å•$í£[É‹Ícãu1ÞeEpv¡„(�©šóˆí濸A·Â’ò·äûtô±(s¦“Fi2Åx\èE(×(9Å?UËÇ|O½¤2o{¸¯}a£ˆ²zŸ��–�δ€R"ô¥²¶‡ÀØßš)ë*m ô�Ds§úä}á·D
-À€èö}»!Xö&#’Qƒ÷ÄQo”Cþ¸G
FòñͳH³3ànGZ(ÎF_¯AYÔ%õˆøcŸ=ß0�ßpMv¨ú�¶Lbã1†ŽêÁ³†L	*öVt°Á�ëh-½m—œ(<ÊxSæN£X»œ$ÚÛع4›ŒbŸ…±´þÂÞ±Üã‹eõ”~ð�^•ËÄ·¹©ëPXƼŒð;ö2nµ *’ç#i¥¥ÈÇNÚÝü…+3÷3ÌÌ^ë�t]XW¨²¸DLèi[Ó8OÛþ>M6¬˜NJ3ÆzU1nç€6QÐ19‹—Û¥ŒPÖáZvõ'P¶—YãšUrAIîžÅÅ€1›MejùzV+ÕÖù7¤¯¼/E^;æ{/ZÀHgâ×j\œÿ+jÚ¹U7ÿ1œ6Þõ‡cuªæ®öèT8ÀõÅXý]¿0Ô¦‹Y‡½ZybÅvë$n§ýõ£±#ù2 [*ÃwÅYårÄ9V@»”d5ÙKˆÙ"ûº°yóv	ƒ®'XiH!ó á3wIykÿ#J÷lÒ<¦s(sUø®û¤Tð|á:/pœs§Ô ëP’–<ˆrÞbL|}ä’0ω´üûÿÛÏgÌ_ögk�=úÚú¥�¯®®‚_{íÜíÿíü®Ò§à1ñƽœ�[.I$Þhè
-¶�Ù½äÝîØðmŽR/´Ï8e°ûœ“|ñîëszC<’^'¬üš~xõ¹l­SÒ|úcä',ü~Ç+L`áƒm¡à¸Ô›;ΘÍfyüØb�Ïþ9%¼Wû^š¦ù¬ãFáuž©ªcMŸîVÿšW:áõd�ÝÂ}L“â��ÝK?ϼ|BóÂú–UvÞ•‹w|›&óyvÓê—šß²CÙvOË*|ð(-´zé>û‚Û\y–'$*·ñóÓÌ¿åÌoßoßîËÇ6Éý¯ÝI)–ö÷]³=ž+·ô»@siÿ–R¿‹Âs2š5ª¹rwö¤˜q	-¨
-�¸wëB€tIÉ>NÖÃïÚ&ÇÚ4ä†11>Ú"³OzÓúv«_§ö°÷ßâW�3ïý¿”é–7Òv(/z¼`ÖrËm_姷´—+vÙW²ÅÔfî�K0庡û×2,¾ÝÜùÞºsÞÙÕ÷ïíK;b÷Ž9]„m/—èϵÏê7~ùp&,kÚÖŽ óKâ>„(vú^K¿{uYMd«WT~Ë5�Û/Í}(ïÜnXªÃYÖðíÆ™þÙ�®%|´<þ¯ÁuJx´nÎ�Ö×Þqr%M=6åŠÚ3ÆY�·=4k<±;ä�ã­ÿ]ßµâÜÙ“ŽI¢Éÿ­C—̈0Ø¢•–óñ‹õáü.Óë�œùv%ÍÙÐ8³÷ eYU›ï&™·µg#žÝò¾ËuÉ5€Ã¤QÝ€BÀ5jÀ°0 9'5±¨$?7±(›
+/Length 18022     
+/Filter /FlateDecode
+>>
+stream
+xÚ¬µct¦ÝÖ%ÛvîضY1+¶mÛ¶Y±mÛIŶm[õÕsNw¿=Î׿ºß×מsíµÉˆ”è„ŒíMÄìl�é˜è¹
r6†.N²v¶2tÂvÖÆ€¿J622Gg;[Qgn€š‰1@ÔÄÀÌ`âââ‚!ˆØÙ{8Z˜™;(U~ªQÑÐÐþ—怡Çÿ´ü=édaf ÿûãjbmgocbëüâÿú ’‰	ÀÙÜ`jam‘WÐ�”PŠË©
+.†ÖF
+¢bÿÎÓÙÜÀùŸØNÍ
+à gçü7$€òÿŽeúÿ>’ÿ(þo!ø¿…Þÿ7rÿ“£ÿíÿ¿Þçÿ„s±¶–3°ù;
+FzÆ+-œÄ,ÜMŒ,œ�Ì
¦Ö{ô/½Š­±‰£µ…­É_.ÿÕF
+Ð÷ª-
KCºæì¢]•ß@e›‡á±Í	R©e7ãÝ8æ¥X¼Ýú^¯bª¿fiWã¦Ç6hé("ôæ?�ü…$ØVS̓÷â¹-Àõæ}DJš2½œœ$~T’D™ˆ‡…:Nq®ó#5ßì"	󧈼ˆÎQჶL–­Èµðc“Êç؉/WöýîŸX2ŸÈÈðxª©-“[¿F7žsWÆ{4B
+pÇ€úâLV›‰¨ÛE�°¼õ`K«Vá½Öž\ºÍªk:K?>1ÁÆy9ãd™5@P2ƒ÷Í°]öþ6Í(9Ð`®¦ ~Ì¢ß
+¹9y´Æ¢]’ˆåþJ¿*ú¨	gÒöK�“]?e’CÌ(�m
+D\ïN¤�Ô´|˜Ǧ¡‹Uf¥—øŒÉïÀúÒáè
+ûÙ
£)�¨Ž&
‹"º–Qª86Æ…‡â�9x
V6jƒxlˆÊù†º’2–^ù
+|Ò Ä;c
g¯lt_´û•jP°–
¼ãT³mê=-ŽÙ
+	Ë�Ö	/¨é?&§ Ã­¤oø
+%Ñ]µÃ³V‹Éµ‡†#hižrX£2¾K±²Å?²©Ç‹t3V<«×üHl'}µ“œ7ÂnhJ권buKÉ)O^Œ Z5‰OßöÚÖ?ý<ÿ�s88z™l­; %ÔVæËŒõ”ð�ðßEôÌH«íjÚ�~öÖ´Öb}ë­MùñÍê+GÝq’Yµ£[N¢+C1¸Ë¯ö
+RÚ8�Ýw>SÓ¯S®A˜Ç©ó-×;%¾À˜úe
+ß$TAÂrü—ÇDUËx,¬mCFË„vh”V¬èæÝod%·Ýͼc‹ò¡R´©kð97Aa¸ö<ër Ñ¿�5{ßîRÖÀª—Öì
+(
ÙóŸAuÂ)¡¦HŸÞOØV";M¸�’…ܶRýd°2auÒ/3ߘ–�¿AjqBGÎÓÙ1\æ›+>€y¥&0•²jmÚqý[„ìÑL6Qb~´+¹PÄ-sÙø¿�µ$ÈÑ*ªï
¥ðÈOÓ…¦JûèY[éýSækŒ¹©[üm}ÿ
˜Ð6L÷èO³[²ò½¼ƒëÆÐNOp:„ùHïä7CĬ“ü]½yî´¶ïï�Ã>Õ“·aý'×M½®qêäîbà_w–
ž]4ðÚÀˆ²öÒøÞó¬n+: §	�Ìô 8û›cÑJ�R[2£mXÅw‹}y7ˆ×ÅLeD$ç,?Yh{³ÛÆBÅΙki¿ŽøК¿ Ø1ò°ºŸ;eó‚T›n|˜)94µ9uæÐ¥x´	ƒã½R
+>ç³]æoM%„£¬ÎG)³‘4°ký‡ïbZ~ø ¼`_[h�ã»8ë<¾4²}$.îÁ³Ö
+Œ(iýŽà-º 7~õSLcüýkÅ!.0Yü:7—
`hPêoˆÜä¦ójÂlƒG¥v‚j»8Ç«Á¨›ÕäÅÆ6nÂN'éú3ÑX®ÐH¨Ïü%›zl½ýƒ©´
+)‡¿ÕÖÏéÛNÄD]*¾ÔŸæ›õ·
�­‡.k
Ùõ£a ü�:ræ\e·ûá&ÈÉDŽ¿Œ™%_$$3}9šü• Š8�$½¬€È¢þàÎg×™„�¿ZuÎ�Ú8רË=~³a#›L]gŽyiðÎ+.ÐÇå‹6{™jšSksÀ›ø¥qéD¾~Èͯõ{Ó·Æm'¤v;?«A%qÐ7�ú"�úpM°!(ïx[„Ô]Ä,…u‹0~‘—Ý›°ùot…ÿ‘vm¸oŸÓÔ/˜àyÝSÝñ}Ó"‡ÍÿImñ@ü
+åÚ`qÈoa’:�Üà}ÒË’àóI¡	Å¡H±`í ¾‹¢R¯u²Í3}›’«˜Œ(-�ž� ŒßD<Akº
z³,¼u˜Kí mÇkûL”4iH!±¡wÅE•Ô›ß¶ÑËf½Ä¯Z8_‚vŸªÙÿMÞW'n%Õ‡óyï+ kpKx®˜XnÝÅçel\¶êaºÆ§#§ˆA³K
ES÷éüT¶�È
+Œ¾ˆeD;õ›‘æB,º„5µ³äé
+IEVx[i©ó•û� M�Cá–‚C÷=…ÐÈÏ ½~À
Õõó)Þ7ƒNòw8>Çîwëôêé‚t­»Ìt«Ã<EÀ ‚†Å5#²üd¡,º%¯BBç;¦é.lãWœ›ÜûÜÝ<’ÂÚ9a¨Äƒ.vKž
+q›ÅßZV¶�¸Œ&®äò®Å©ði¬Ÿa
•ÌF/wø†¤°•|ÒÎmyÒd`Í\º¯*ÚßDw§Ìw °)eG8ïÂ5´B¼Hc†µÙt¢ùš^¨3€6ŸoÈ:W¦ z´˜˜éÁéä’*ëÔ£Ÿ@îàâp¯_© ¥ì%Šcga>¯W�¹4#UâRwXPƯY“�4ìg·FRß vßû<ÔxP>†uÂËe&+
+Dì2Çüߢ¿¢‚IÔnèEYÒÒÇe)ü²:V ùUš>иɚúq:…mɲ¶þUñNžY±B§Ýêƒ&³Ã¼]Rý*ÃŽûý=*n…ѽKv„hf0ó;!ØÅ.&f«RÚ„ Ï‹ë&e¤ãe}|“x$Ó½ââ;£kg�ž=çyÅg©Þ+a…¶’û.Î)†Ú`NËiߜʼnW«Uäç*i¼/W6æø>±��§“ <?;dPy\Ÿêd汉ä»tóñ#+|þ­1qÕqVø‚¥Éh¢‹P³Á4>t6ó –p�2/ÉõÚzî„øÑ=h>±`
+n5TÁšëÑ”’ÐX"GEÉ.4–ú&µ¼ ØØ…'Àú|€PÜLêar	¾0N1fo÷í¼Á¶Uå"‹*0âù$]s¨>ÓΆ”'â�¾ÞÑØèÝf6qì�©)¡}mZ€šÍ�
ûIÄN§
+Îþ@PD #V{¿Ö%þVõ|3ùÈ”JE3)&Níð{_’ Êm3™Î1 oåñ S“•/bì~O«¸8/*™Œ²éëí�Zφä(.Pÿ§žÏdÔö¤¾X<é§îrî9YJÛ)E抰z6Ø/v0
¡ªD°¾T㹋˜€7ýP“Ú¡ûµ¿^¶û°iDØF…ṳ̈9Ô\ðØDˆ“Ï%Ë;¥Ø�—qëŒà2ß œNý.¶8bWÉI0Uy®ƒÎÈfPw³‘ Õ8ŒÌ"
Çsäs
+ZmØFÐÃʶÞïPhzI÷™ð€*qaBrÒ·Ø^ðƒMâÝàí-Õ¨ô¡À˜å�®™ÂÞžÑÉö>u¼‰Š�ÏãonŒ{óæâ<ŠéU¿˜f);›Íp±OË,¾†ª™ŸÔL~‡(ÂJšW
+`þ*
ÎŒÔÀh0±ì$�(]J+?!uR[LGÓOÁ
+>DGÓyØ}—(l
ø &‰åSß}fÄ	†ù©»7«ôÖÞ•ŸÑ;!)îüP_©cEìì_Ï“Á’TYj¥àê§ïS({	çÑd
+±
�éÇ¥µ¨ÿ‹0Ò±«ö¡`¢/³I	Ph¦€Z�h
tDįcÅxBkô¹õ¾z힢�Uˆ1áû-C^­î@\’ž¶Ê#f„†µ]òOÍÕ5Ñôh‚˜CGÚc(hƼ<@žðŒe/ºˆ¾]úyèŸãgT—–B„W�‹:ƒÅ‹"p+EŒŒûE|ë7p<*6~¾R—”{N f.]Æ&‡•è…M�ÀNsr'=d/UMzW¿¨8ûÎ=ªŽ´n¸ÚvDôÓM=×�ArY8sœ‹ªf(ú²"’å®êvj×;¥ôŠË7/“æÖö¹]Ë\Ù”7Ùë•azgòá¶gÌ)RàÞ%H}!³¡i°�Re<�Ñ 7¡%ý¿¹a¢d:£�gteµIˆ­¨*’
+‡–oü‘éO' °xd�"뙂T¯·3z^‡ø~LËÿ¡IÖBcP/giй.^ÿâ×úÔ¡/jƒX©ÛQÕ­€ÒÆ-Ô¦4Ê{Ù·hïgZ¼'ªF§ó.²$2ÈÙBÆúž07êÅÌJFØ“|Àmv®å·Ìù´"Ëæn0jª8xB¯QÎïïˆþ”âÞþÐßÙ«À|˜­jiu›¡lQæ5ý%ßzÅŒãÎv¥ú…>GïÀ•Nv.óY‹=Šð ðô"¦k
¿E)û›™,$i{;vÓSëœ†œSW¿BPPúËj…+ýá{ÛÏáûg¬ššLœ/

+�¹,6:üâƒ^ÔX'€å9U¿œ‹fkM6¼¿tî˜è^‚(Ò2g¡I›yÕ²˜RôÓ(.ãcÃÿBM¶SaÓv¨‚/uø¹!&jìdR¥*ÿ!´BSJ‡ã� !DË¢FT=B–žýÏm+›ä’…0Ñ
+
’¦ž~o8LÃć4»DÜ϶ÒlÊô‰'´:Y'ϵ:X–¹ȃKKÖr97…üdé2
+{¡„Fuœ·3žÍÇoÕ‹Ü2C7§jy¸-Í@Šæ,dL//¢„KàôÌ°FYîÊ„³Ýþ9Å™
+*–÷oz ×PýÚúŽÇä–G”30¢ò
¡€?Žê)^¿)’£Êw8:B-sìFDò±û¹Õ.¯ýaËmwñ¶ÀBUô�z8sš3&¥JÎ|ñ$¡9ê
+¿’ƒ½[žBš´¾™Kåd H*ž±yÈ"�ýƒßýzêXê>ªµÌWÕŽ“Ѥi$&N“yu°BIsŒŒÓoLª¸IòD·»ñŸ’ÆãÇ•ÑlèE)÷—¡OŠÌ�:˜¶O-h/_cÂ:u*	ý ‚(ÖÛõî9ç}y}F)ß×]>9]¾¬šæù%†­Ž8[pµŠ Úˆììˆ4eAäÙoÀ�ÄÜ#	Ò¹äY¼I©[ˆˆu÷Ìp•)ÁæDÚøõl¡ù})¼ºjoÌa %h1•l­õíP”Eöd¡‹#ò!Œí±Y‡q4NaB¢#@÷3ÁÜ´*ìåFÖ‡ù–[>¼üózëþ2‰ØMÌDn…ÞÜwKØ¢Y(i£X‹ßüƒd¤ú9ò ¯L,ÿì“^^ñëàö­ÂóY%)µ4ÙZ\ÔötôÕW¯ù­i
¢7,qK“ñâ”-Ç?ÑúE�@•àë#¼‰&+ƒÄ0¸Ø¡¸04ºœ5Ö–›ÿë“WåÔ/¶fLƉèß‹›¥0³<IíºÛ‹ÉÄ[t>Å¡u±yØ°Ðu:�¯Û{®[’ĸ2Ï}’ cu¶Þ÷²' )¦Z`‡`\… c¬—ÖÙ±{OÑØD°Çré ám;€¸LÐl}
JÜ„Ž6‘nþ‹‚>°§nºxŽPc=‰6pÊè)L[‡+»†%ª}'¿P°aŽ‘45¨lG½>(ÅûE&-#Èkií·jEüÅ×Ö	"ŸûmUó˜SvL„„§=ªA2Ÿ¶_5J¶Ôø¿ÒU‹‡_O·V°mîl=
+æ7ÒÁÒq3‚`¦	t.Ó„c‰Nä•×wíÝZKGº¦Ô›.(ðÔà^æÕ—w[.,ÕZåŒ
+cGM}!;4šÍCnœ®2'ÖÊï�ìù®? Œå¯@9ÖË'Ñ®æp]CÖ-C¼Dû]QPÓ-}yhÎ�ëzqã©Ýcô‚®ËÚ+›ß™A;t
ocšn’Éæ¤-O‹ÛÃWÓ•ºžÛóÛž:]‚é#Â_fbÈ°g‘øÌÇ
õPŠ€Ú†ÑPÅŽO£ªõdU “ï6dÍpŒ‹bçÆ©\¦�©Þ÷Œ­;£&�{"ÿÚé,–ŒO_»ÔÇÐ9V¼4�7M=ÍaÍ]:mÎïGA�ã›P.4”ªþ3€ãd�—&•É–è*HfÅ„÷‚¼M:ÞÌk(g
+4–·öÈZýjH
sóG··»�èV
üY).üjcPÌ�¥’»nÞÝtïw¼RÓTÔBÇ
+ŠéÑ:kÅÖ ›r}’õéŽVbbérªï�HÎ7Õã³ßêí¥‹_©¼“×2[ëAõ°çô­JCRz!»‘<ùq3mÔ¢W[M0hÒ VÊíaL¦3zb¥ÿÐCNãú?O“l��VŠšßÍÒ4Øë>Rj•·•ÛéD[÷87ž
+vÚÑKâåÅíÍÓ¿½Í~¬?קS§ÎªôÉžµè6.¤K±“H?R‡y�þn�v8Âax9™:¯¼&ýµêo<çßb%ðórÿDí;Ú%§1M–UΗUÈÁX�Ò6G«NJ"€Ùíì£â%Àì”w¶ðtý—_7×¾`!—
+;ÜÆŠF¸�*Cb&Znf]C¡ÈN‹×6Á.þÂÑ,	èW91£ðà«i�K;m+úbTèSpïGsÊuÊkÏ&ALH^Ö™FV{ð$	ÝkúÝMbx�áñå6ÿa˜ƒØÅYå�›a¹5°þ¦J0Ëšëö“©¾é™ý¡
+Ó†©"S—Ïz_¥¬Sþ@ÎlÀ£ì†�D�/®¨÷þ¹B­c0ˆb(	º
+ƒËsˆŸ.ÍÏxP£þþ\næèJµ�õN*·ƒ7A—^…¯f£èïnò˜Øc#ï|<ÐŒ¹a=íÂèœL¹Çt}N9@œí2ò“º¬ð;ŒÔ’`Ÿš瘓gÛ–»
“(kw“Hˆ«fz#
ü«T�U5aQW.;ì§øtÁTK!bñ6Û¨Ú±A2®Èü„è-£�þ|âáŒMÍU5j2~áúˆ^]i‘åe-·¨^žÿWeoÙ~äèžÞÊ„×Cô®ïw=	ý²{ì}Åï÷šNå)àÒ„½\Š*‹Jò|±WŽMí¡±Òøòo-	kÈ“èZ±Õ6"Ù™þ\W7ϧGÂ}VÁc§Úª4�ØXoM�7ùwÂá›P«cþÕ’Ûl{lY
B‰©Ù/šÌÝÖíü¾ì–­˜T¡ÁÜ?ï°êšš+‰¾Å’Ñs­êŠGô†äv5¶ÈÍÌ?ÈÖ§éBÄ<wsÕÆصŸ×ŒD�¦¤9	ߥKòã_Ý»›’�«á`Ž]}‰µñnÃáhDÜÀÂ\É&*NNk…¤û0œ†»™¥
›
ýÔº˜Å9}­Q}lêœD�ª0ŸœÛj2wü“¯µJ÷‹¡œéÃvµvz¬�,Æ}úè"öìijƒŠyñý›·î ’±¼cæOˆq¸Ìpãd:3ö¬Õ¹$c¿_W#ò4ºÑ1¬ç¥†Á	z,8ÚÈÕD-æ h•’ö5Cºͧáƒ_%wÒªu¿ â#¤Ç”g!]7¾ô/BŒ]eh©IKôŠ2¦WTŸu�ÊÊŒk84æÍ¥0Ç‚AÞÈ;b•1b°mÍH;í>nôÏ¢ÖRÂ	/#NìqHºà0gÚ…>tí°§Vûa¶ ˜/�æöŸñü|¥sçYà¨q³Ý,ÙŽÆ™(®”	¿œ^õÏ‚~¢­Ö>ʧÐÃw��Hv«;ø´þâÎMÌÿ$ìe™´´_ÚژтX–KµÆ
+Ú…W¨•fI•M@ï±–KÉ­7‹û)Cc¢ïS`…,8'Îl[stÂ<¡\nc<BU¿Q×ÓãäKüŸþ<¬ÍŽÙ»¯ÅƒúÉM€^ÆÃT»Ì«ÓË4	§¤Š1´\�Ï"µÒˆÊ®ˆéâ]xµŒ'ƃÙIÏKXPõ}BÎè‚YÓÝ2�Ä6å¶a«í™TÙÀ
ô&†’–Àiû‰Ÿº¾îpÆ4
+~[ØÝñ°Lå ¸¡©Ûa
�¨Ë=‘yÿn¬%YçYt½¿Ëú7R¬lN%mÄQ$:�	QŒ²›DµØ†È¨Ð¬)¦ÃºÊìH%Ûß	^>«¡T&8Ñew‹¹ƒã'}'ÅrW÷ ŸMì7#X1nfœ÷
~�¸ŒÓ2Û*¡U§%›ˆÁÇ:èDMÂ|Ò.Ž«ªˆàc:š®�)IË�ü*�ŠÎ¿žê³Â:
+ºâreA5n!Ñ…êì]Œ¨ÁºØ»‚õOWìõHƒ:Ô…—‡uÀÏk2Q:ú†É�df¬š¢µ‡$EÏÐï8f±æ™€âNØÔ@Gœ¹}\=ñõ°¨öˆ¨‹¼_W/nÀÄbÛíÿ¸¯ß0^8U¤>¾û=O?°g›¾U̧[aý;óþÓSX¦ä”gÚLÁ´·¹‹.võ@/Ò&ÿ”i:dÏk0G£u¨ð“rÏBž7gO‚w üúàü•–”À�‰KY&jøœ7¼r2–á°WNÎxëh“õÒ¿Í7§LŽ„×VC@]ÒÖóºÁ*óë-Å ÃA;}üvñïiCU…—.úZl¬ õå?²ŠcHÕ¸´Ôu½ö!» »†ó±œW‚
Ñ/ðó\Hvq•bf€úOÕy3¹;¾Ð¤ ² Ü
Œ°š'ÿˆê�IܯE|Ÿ¹
š­p:ÔC9èc
+gŽ}“ú£qÍòÛ¨ù›ÂN•¥•îÉ/­„¼Ÿ¿¨ÎwýéN­ъ”⃞êöÉ(ú˜i.ŽJÓY{Ê…ë߃ˆêo&ãX
+Ë|åT¬N!{¶ L•„«a` K=ETBÔSEÐATMb§œ
+Q‡Æ~ËJlQ‹Rü¶×ZB§©{g¯^x™‡¾m€ï¨LŽ1p%õïø×ké\¤~}ôO½Ü8Ûu·×çqÏÜV»ì*æGj¸ÙÛ9ýèO�â÷Ž<M×mÆô|UíZ0¥—¶µ™r'·>û’VuûtñCv.¯ÉÞ¯²�”ì U=Ú·rèöI3	Í¢¹ØO7(S~ãÈ”‡	«ÒÛšt”š®`½öÈl/ÅY¦37›„Û¦š ;ŠôÑ
à<‹ÆN–T‘Z.
�!`ßêã…”´I¼M%0,(`Y³¡mm¡ §<!È’WÏX®l‘«oÎ�Fž5Ô¥�Õ
ÂYe%13ð}‡yBjú$·¢³-71\4oà'!¿¾¡Þ­«’[É2@2´�F´‚ø„ö�€ñг…ǬÜÄ#ºÅ[i©R(|˜.Èm‚F
x¼HÃ>&ymr¦-åɽ.§æo�·œ¢ŒEŸ¼B91Œâƒ!ÈD4B\\ò.½Ÿ†‡b.ô¾=ƒq™“s,|Ö?¼�´~8£»»³­
+Ñÿž¶l ÷ö"•äjÓ`Zo…hbµÌ}åÏ0—ŸùoÎ*˯�µŸÞµöñæ/~úÕ'Kü@Tƒ¯k5{<‹i»ö—ROBz@-+µ�yÚª«1èûŒÂ·–µZë¿Ên�òEp7�âPi�«ú€pV¢;g
�.Oã­pÈTA3V.ÀÙòV…I’]UAÍÊ&¯æwú{¥,¿f
+ý’OP\h{†!Ë/:9*ÁþNª‘À„y†Ý¢›¼~¸®<rÍ¥Ø.k�¹á�R\ÄKÀõ=™Ê³ô¤µéšàš)É 
+�Ìó¬¤^©êzX-Ta’•éÔUÚjLØ–‡ÁPϲ‘ Ú€,j%‚‹Bè_|³yŒß]¶to7ɹ¿"Á¡ÒW¾7ÉÔ9NÙbdÌ÷Î2s—O‹D"—MêÓ†l›Ñc,Å=Æ/¿ÎWDk¿þ-ţø¬‰tF%ÿÐjwÕïS;ù^É£ñšo?ñ
+ÆQ'?ßœ†*×3;ùQhþà“R¿«A±FÌb<\gÜÝ@ƒ×oìfg,ÙS¿´íw*0=a{ æŽ!Ù5"OBŃð4ûbü[ïR«r‰2Ó'VìÖĵv\PjÐÝh«»Œd
­ªÌ'3çÜŸ
¬ô£uª�ü”.ø¡×cšÎO
+DSmÝ÷dU�«TòȨr7)z¡mYÅÀX˜Ä5ê¦[�Ø÷ËÅŸ"f ‰@êéqD„ç™Õ'~ñHA[€‹Vû¤“õ^C
+ݓ׀-xú€°š
Nce<Pdc–0`RôA˜‹¬ß”™…r8HXÞú§Ó•~«÷�®tOý08em_¦;nÒB0Õ
üYÂð-'y©_‰ôÛº@Á=¬È*ÃE\Ž�Kδ¿ÅÿØÙ½/™‰HíMâÑÁ�8g7m‘ÿ{<Q-u·´å´_;M;S1Dá[ñ7;žŒØ‚†ò”ÎD!m÷í¯`èh�pÚh16jä¬Ö’ØŸ¸*¿v/¯`%–ëekáÍ?LhÎ=”v‹…}éƒíý8�ÔµÑ89riL&òëcOý‰„iŽý†àÁ¸¬Go›‹Í²fÂɘz(¸—¡3
+ßÜ}º^hîëgŒÛ·S~¢Y 
+ÄSä–5“˜{'Ë¡esøücl\î½gˆî*š1ŽšÈõ¼3ª¶è:ÃegMvc¦‚Ê癚ËÖ¢&§�,€íIš®
Ø1¤¯à
+©*É&;jDú`ç�sÞ#)„Ê4s‡oEcà	&ßÙIÉ;qÝ#K¸n�›å¯ý´Y|”àŒmãø•6ŒÊÑ�é>Ÿ[å˥ߺŽ1
½é˜Ê®aYÝ«ÀF5PYåaÉ|3ãä¡ïbøM@©Nyav.åh­nî×ņ®ô²¡RŠÅ—ȬŒWyŸ¦Þtƒ7×ÔÀOkB¬œC@ƒž©êo´dÏ� “I¿ü“Z©þä}\žÅ’gÎBT…bM+5êõHzJžìfy<p!uš/ÃúZÇÉ vc&Bãž³'˜3{âC"Ã^z�|8�m§¥ØÛ#¦ÔjÞ¿øËú½:¡(Èn‡óÐ)˜âq—4Ù¶³dÑåÚ³;AúGòùVQ°!‡®´$ú>®âq
+C¸ÎÞ•¡‡›û/ìë aLãdU±Å,[g¯úWСÖX·V7~æQÈ¢%+ð?éצµ!ùUè³Êk5ãø&Z£Q‚É�
[äxŽ-b÷uP…#Ïñ¾†E@qI�À$ä;®ŽVçæ$#ÜíkôëtJ€\¶p5žr„�º‘¢€$|H{U¡øæòƒK]N}¬ò†Ÿ€E×D°
+FÏ-¶6© †Â	߸ŒçânVä^… ]šMg\Ô<C‰é>KÇ·ä 9·/£‡õü7o¼¾¾Ð¼­ÎÉSö'ž”Q®¬þ´òB†‡Òe|°ià”¸[‹_Ý‘†6ùŒë.'¸cä�½M½åÕr\S>‚K䃔t§C稶h5uREæ‹LU§­Ò�ƒ˜Oôz VÇ‹;¬¤'áS�™ÇOXñË€¿®›¦™;µWEƒeÔ #:0츜�BøUª,ØÞèb
+Òó…2pÈ^Ù†:0|&e¦Õ,?‚HFkJæU'ý!qÆYµwß³HžÿÔ«œ;…ª»ž–3ª[œé@—h�žÏuãrnL‘;®ˆ=b�ªy7¥�E>°áíîä=HøŠõzŒ³šâs|Ó�߶�ª`KA
+Œõ�_P-ç'„HS
+Л¨'ÁÚæãy¿�ˆ
Re†êi[‘¯²2Ê2ýQ%™ÒZâû®žm-c¢‰LPe³o“=ÒÜi:èÑ'Ðr^ùÑ­ßÔ{?z$É&aM%*Æð®iÞ	ïÚ‹š%4Üôí#6¼�±
+´!;h¾þGáÁj2Á|O¸D‡?ûµ“îw¹´`ªÓ¢¿¸‚’cçÅò¢†‰‡Î·¤ÌaŸŒÄÆ툗62A»wÆÕ(†“Øs/A'viÙ.Ü]Á‰µ‚7*‹4¥'O¢°vŒ�÷øF34§¡Æág¢O¿u¬�.t¼“®rõ–s}/
¸šä”ôÛºö˜#=ÕdrõÔ�VL­WVŒªÙÄKã‰éS.“ (Õ;ãh"’€}R>•lÏs¯ì³²Ô!¶‹lAËE:ßy&ôœh»Æ2©×Äë2+Ù®HѳÁŸ¨0�An´ë‡Lš@°ƒy‡ß[q8^:ZËÄc hjð-¦B_¦–¨ñº€ÛJT§ûš5j9È«>Ú)¢Û»�nSÑj=³ÕXër÷
Hl_—rß:¯0)]F:
”Ùtë,�,pQ£î÷s²•�õÒœúåx.Þ!ª±…» šMdÙŽ%󌥢À>­×בtÍýh;ÑN}ÅO™~�ìx[ôÒ[ ô)Ò`Ç™[z€Ð¥Ç;ÿµbä¸
ý·Z�Û�±ýW=mVùD×®9,«Ÿ³e,ëKj}Ü üïJ¼,®bðýÂò3�Þ2�¼ ­h=Á‰U,jï%
+ìé×¾
Ä92¯kƒG`µÕÂKþ{|*Œ”)ÎêÒˆÁÄRéAîCêD´Ó®ïÒ‰svѬµ>�cj
+6müÍpHr£\Ik[xi×$¼šÉH$S<ÂÐ]­H;"þÏ]…h!ÎKÙçwœÙƒaƒ!Wo§têQ‘21¸¦e}œDó—ýªM¢Ê&ëÅ"þçÍÜ1IpÅQè—{ØAÛ»kJ‡�³÷4°6ŒíîO«Ö*“YŒÝ*³A"Õ±«Ì
Õ	r¤eKãùŒ©$a^Hœ›Œ×ý‰ÞFïNûé)•7µ»‹i?¦:
¤®ý§"×ñ—á
+¦y¼5âéx
Î?8€†,ÄÙ%š¼ø*%q$GÐ]È%\íðÀ¸¯±ÆLÆø¤z*­Ë"7›U0ž$¥¨×”€ïøq*櫸×\~ghL[ü	¢rñY{âkây9‘ä¹_­-¡„­“ߣ|ÒœZ¿€�ë˜û.†zžÜbé�><ZwúµžËtÄw/*‘ê}5Tö4[Ï*ùaÅ6y¡W;åRÊØŸ7¦½jJAºjæ”ÅhÜU–Fî¦|ð¥Ûê:]Ù+ärå’ß±¯µíj�u:Ûdí>1a�NÓßø–à—ÒK!5hI¾?K3²<áŸ,ÞÅÁ¸²��Ü$j:=úzåmÈ_N4ƒ˜�F�äûq
+°’胱«T«þÃ5jíaƒ"¯‹¬Î×Эô'7kˆ]ú†A§òuSà‰epÀƒZ˜%ÆÅ…¹­Â¬¾=úð¤´~¸Pù*€üÕÝ+àŒVd˜¥ódqɈÎEX—dÓJHÁ+°:ƒÊ}Ð)#ôø@ײ!R»ÿ©€£ì–ù
+;\ùˆ¹¥e7ÍHÖx³¡l�½ [sÉHù[êƒáëXôËUNÑõ¢iX–Ø«c4ë7û�\Aº0«<�{ Evg]8xp[lZщ5õè¹r÷ûGâÈm�*Nêê:Q+|‡gµ
}ÁÞ\d„äO¾>hžDä¡GXnöº
+b¸¬óÇ;½<nõÄߺƶrEiO8võÞH•kö}aq²2ß5|LÇŽ´Fa
+ÐQk|/Û9¾ÑxÜÜúÙP7˜ªl©¼å©	敱<ý6œÍ¶Â=Ÿù	…3ñTI‡@TƒÌ07ƒI`5¼áô‡lcoƒ|áþü]¤ãÏ(^¡¥�µºÈÕ6ÿCÞŒ
Ú롾—lšÒÚ´ë÷aµ1Óþÿ×Îœÿ3¡
+šþˆ/KnèE�KØ(xÆÈìƒww¦\3¥kÔ!›ùÑÆlð›Qe8‚nÛh’8¯tãær|BUw•Q“)€gÏ£ŽWºè¥@Pñ„¥¾‡LZð7×(fÐlç9¬Œ bfr·Ñá·šPæ}p
+øš*›íßyýá“ãûB/�1;Aì2ÕÙ3ÕSs�±‘woÃñÕ“VÝÝíßv�¼¯å¹ÜÆ{¯’XcÇú9'*:ÞÒˆVÂ)BSzŠ�)Xý_ƒÓŠÖpm{§z¼¸—±u±)ôc¹ÿÕ)€+H2Qi·'Âڱ׉×b@akÊE¿¢vÉÃBakR‡å:›ñ†‡Fˆ~¨êÈ’Ì�m®g4šv~\œI©¸
+^ýì¶<��[7Û-ú%çq´Å5mââËÊž¶t“Bdc;|WÝÚú7–xSyåÈ4ØÇÖv´¦×ÅõQ«´�˜
„2ã¹Rwr�\Œ¨ÇÂCÀVD
+­`Ú5øy÷»é@k"¢™5)Ï1·ØRù-DÒHÖ»¼ÍDdM†o3w»5Gv`LÐ2î�ä¯uÈoêb—r›[ˆv^Ð^P€ó]üQ¨‹ÔS^?¨Ïóè
_û³£ 'C2T5ÍyÅ
[<;ËÛÜ}‹hL�é4mMmÖéҎ/À}"ÑçB0%’éVE�~µb(e’ ”峕Uò�ïiN“ýië€ëÜ„{X#Œ=dÓ[娽�	ÿÆOƒHð”£Vê
��ªë�vGJMGÚêåÄLX^9ymiZPpù˜B5«¬Âø#…sW+* ¨)¨OñD¾Ë_*Ïøy81¢ÎsY×/NI„8wÖ¦.¶v.rþ÷¥äïûˆÍžá¹ˆ“¤;éë7¤{®ÈE�ÕîÄìø‘VYƒÉïÌ|ÝWN`ÄþÅW‡Ù¾—›º‚ÔÂâsh™ËúÊIÆ(ˆxó^m¸ƒž²Ê+»O':Q�GrçÉ×æ[XFRž;j¸±·ùI•šà5A
 endobj
-885 0 obj <<
+940 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 1930 0 R
+/Encoding 2092 0 R
 /FirstChar 34
 /LastChar 125
-/Widths 1938 0 R
-/BaseFont /TBYCOO+NimbusMonL-Bold
-/FontDescriptor 883 0 R
+/Widths 2101 0 R
+/BaseFont /VWNNCO+NimbusMonL-Bold
+/FontDescriptor 938 0 R
 >> endobj
-883 0 obj <<
+938 0 obj <<
 /Ascent 624
 /CapHeight 552
 /Descent -126
-/FontName /TBYCOO+NimbusMonL-Bold
+/FontName /VWNNCO+NimbusMonL-Bold
 /ItalicAngle 0
 /StemV 101
 /XHeight 439
 /FontBBox [-43 -278 681 871]
 /Flags 4
-/CharSet (/quotedbl/numbersign/plus/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/semicolon/equal/A/B/D/E/F/G/H/K/M/N/O/R/S/T/W/Z/bracketleft/bracketright/a/b/c/d/e/f/g/h/i/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright)
-/FontFile 884 0 R
->> endobj
-1938 0 obj
-[600 600 0 0 0 0 0 0 0 600 0 600 600 600 600 600 600 600 600 600 600 600 600 0 0 600 0 600 0 0 0 600 600 0 600 600 600 600 600 0 0 600 0 600 600 600 0 0 600 600 600 0 0 600 0 0 600 600 0 600 0 0 0 600 600 600 600 600 600 600 600 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 ]
-endobj
-878 0 obj <<
-/Length1 1620
-/Length2 20127
-/Length3 532
-/Length 21036     
-/Filter /FlateDecode
->>
-stream
-xÚ¬ºct¤]·.Ûv*I§cul'ÛFÅNÅFǶm۶͎í¤cwý¼ï·÷>cŸóëœý£jÜk^s^×Zë5FQ’)ª0›Ú%ìí@,ŒÌ<
-ükì{ýÒÂv¹+
?j06Íðün÷X>wø<”¦=ëñ¡êM
^çùPÐô o}íä¤;
-dÒ/EN¿ÐˆòºY’Ý�Òæ`V?Ú›RRÖ/ù€!žédu‚»y¦ñ§p-ðÇúòä€âk’Ú‹Ý…Ö†QWx~ñ5ñôù‰jh|td¸÷ºÿ��.'ž’×
-ùk¤¿c¡ ¶Z…xUó«óö”ê&BÏØ>Ÿ¿ù‡PvE‘妷�‚ïÕàO͘ƒá†Àl
¬„ÔÈW"æþx² 
ãŽïIx%Q¼Kâf†Îo¿møWcwúŸò‚‘ßÄÎ׊�ü;L§Ö‘;æT°£6®ãGvíÌÓ.õ=n¾Õ.7èX¬JÌ[ÃZUýùbªÜÁ+_®›xF»-b¨À(¥ã©ƒw¸ÜÄ$ÌÓ…
(_,Ó	¡Ã4ŒS4r-Ù“©¾ˆ3‚2Ž‰Œ�Ž$¿ d­ô“„}¼Dä9%G¹<á¬;Ö6®£ÛA‘œ´Øpÿ(w�ßöìWŸ.S?62=ú0z‘ßãš@΀ƒë��ì˜ç3¹>9È%æÒðOÞ`zŒ—6"Aïܪ“³ÖSªÒ¼qRÉŒ!ÝMë–›Å/˜6 pöpò>ÙOB�ˆÁrêO<õlb­‚‡ˆà\jÑhŽ!··qè™•íº”…u=5±—ª——‡³ŸG
¿:×KÎ{òɵÅéKœJC·ÒBµ¾/)qpgŸ”­µí‚ ¨•ŠgœuºœÚ]_ÕÞ´c¸Cûô¿Y‹ü	n¿3ÇaÉ»ðSr
-o(:¨Ñ_‚å¤ñOFõØI)Q’l¤®‰Í;TÜ*kÀ2ñ´Ò(ÏË2+­Õ»ÐÝé¾›äAM�¾×Q­?A"tto¯�$ÏÊAœÇ;tÎB�¾ã¢ü1jþUx�q¨eÓÒäþtþcÉTI€�3!š@X芆eÎ^í'a‚†:U+�“òÀÅ$˜ ‹EÕùÆ
-a®;�?o®åü+L7O7¹uv¤ÓuÞ̸¶çŽNóæî™Éñ¢ÊÏC°¶ŠæЂÚ\�„P¼®ˆ™ß¢�’1âÊ¢Þ zO&�É·c튩È—©7•Á¼G}Žúäñʬ�!FŠd1‚_mÅ€th¬×Ÿ2°?X¶'9­1îî»�(RŒæËÜ�F1”P (Ê·úí¼eô<syôA$”¨…³Z‡j?¡»½¤`y×Ê ›¤»€–ä…@3éŒ2äaMÊà
T¬6¶†ÙÁÜßñÁ.ïs—f}ŠrõEKæË–4ÅJmþHž6î€ï^çÔt�V-O4ë"²$ì2ƒë†`zê%ž¦,"�þ¢ý_…Ù÷4Ô›øãö•÷ï¼f=hR àˆ¼®<|Ó$ddð£Ì…ÌËÖá‰ñq¸WœQÈ
GðdȾ×-&üäJ6fëÏurþq^KÐk\#º“4”ÿ8rÝäRlºQ
-Æ9vrQÚûaÞßïèóQÝiç·Äjí(^&+
MÌäkRÐ<7÷u¾!+o­¹
-}�iC¼HBb×*
1'O. Íþ~6'jïó˜ñ+gt5û¢PV4घ¿Ô ÚóÔR¨�s(S¡šq¹"yV‡ôîHvhp„3ëÜHG¹çòšu¼ÉÅQ›8Ô%âÛU†w>ðÛg�ã‘Ûˆ}�­H}öE÷2OöÑgí
-‚7I•{œP¾©3½¥Œ�/Ä[Ö[ªp«Cƒ’½f±cB8|*×vÞ’(2M´:G‹çeƒÀü‘H7þ5'is=½ó{LXwÜëiì>Aº„ï=Ëo?F—Aµb©�ÜħcL·¼ž…×›ÂY_‰g Ï¿¦©èe‘O5ÙÀܧâí/96]d±�ÊPàH]~+B†<�Ô•R–…€
õ\ͯ©sðÑþrOŒ…[’�½�¸m+þ¶ø¶ý©>þ½ØRkn„´VÁÁE.ÉYSssF‘kÿ©Tââ.ŸŸ3hÈŽxÒµ¦ö–Ñ9õd¨HÎ6
-á]ô
-ØI:ý}Ÿð…îŒr\Òv-`÷’¶­»j³œ³·í}
-]rSÓ|¬U]Iƒsuoé$½9¢c÷U¹“äx°Ð¶¾Ø¤Û‹«bÜIÅQ¶?³…á6.S¼à‡n|ÑG{×BõwK�¢»™(‡§òq°4N�qéåé»iÁ;í¶¹öU‘PÈœ¯æxÊ&ô•¤1S¶2�ó¥w\·+zê›DJ´�v¸$ÌLßòÈîk>^µ².L±¿²!ð4^¸“PÔ¿¦.¬äïŸ(¿'Ú¶£Pb¥i‘÷êzÝûDUoÀõQ
-0E†IÃZ^ŠÿŽ¦Ö‚0›2%“ýJ§^ˆVÄÉk"y
-4ÑÃ¥Ë2š=
¥«UkW3G­{—ð̪K¦¾(ÞØ–WŽÓÓ�üý®9’ã‘<džâö—ŠäÓ^Rƒÿ°PŠÊ·Zl—›Tj­5¾9.¢"¥³f>89ù�IÆvp3Ý�é9çáCDq
	€¯¹/�W4=¹¶dopso´�‘
‡À1¶¬´’møÚÉ6]ó|"쮘V»ÃJhO5‚°2ÓË�±‡7Nß¼hC;
-®@ê#^>«\×Ȳp‹Ç*,	A_Ó�ðtÅ
âqÙb1?&}=Ä2ãÒ]óð€ÆžoÑG¡PL.]Bª�¢E3ý7z®Æn¸c<®žepNwd¶\ñú"¯kÑ�;ïX¨‹ЀBgN}®²ûàóÃÌ�òhkrŸÀ¶Gâ{°l:&j‘ñ™û
^òÕPkNÉ«±L�Öñü«DÙj‹+Y9‚dÌœòÖ„Ê—6<€ôVcŠ§‹Íš‘Ýþ³¥SÕsiÚÚ¤Ûò>vü[Âë
-Ð"$©p@�zŸÖÐGƒ›‚·^_fñžtDPiÂñøËɘ.yÖÆÐó†·ÅDã^!¡¥ 1âóÜ,óšªiÖc.â4£÷LÛ}cN6\ÈÛ�Ð�C•Å?ÐÖÔØ5÷Ü tbgipO
‹¹shÛtƒt{J'uYÌ„ÕÑ’Z6è�¬wßù/NÐÈy0¬Ö‚;g‹ÖZ0….R;
-*Èí­´âT¸žfWÓ�3Õ'7)ÔYß=á!`ƒSé‰7ˆv¤U¿È!~{£Ø1�Çœj÷àºßŨ�žG]¬ßg•,½[
W,{ukRÿÔj•Å‚�èÒ<’…æp_íÖ©ÛRV·((þ22ߊvóÇÝl.ˆÏÜs/¬U¡¥&‚ko¾÷ñ@ÆÇÊ5V…jj¬a
`N}ÕÆêŽáOú
-–ÙýÉvuöù‹ª¥'NP
-SèÇ´FÞ¦…ÛÏÎ
š13±©É'æztƒÞm~ ¹Hº&¶Ñ~ñÍhŸŠ�pu¢�h^Âc0xÆ(ë7\×�[:‹¶q¢Íš-µj“’"z¾r§YJ÷-Ù6ÔïnnÔãõÍÌI·n ïS7ýö4¦¦ì¾•ôÈ@؈F9x&«sî|×`pu¡e
F`{i~¶ÙƒË!$jmJt†œ/üaâ\èÎÅNià"û*±z˜Ãt3¬Gs€µ/Yn ~³1&¾âÆ0tYœVáqð(ê™w†—V†Ÿ÷ :·ÉóÇ�otxøí…*˜®ñ§õ‘á#Ms9½C¨9ðtIL�³òXˆ×íŠçÝ€îWÞ«�Ê.­’Âå݇Ӝ,7§©Ù7‚ÆQƒÄéèd`³Ú³“t÷¾k
œM÷ûx}Pïïo\5�Ö÷ôC§Ÿ®Z*ïÏkm Rã̽oÙ°?1DêñeÄ'ŸÆ à6…©jb6LÒë¦Xšá|—?÷tKÒ:6™Ëühï;¬p€Gˆ*z µ-Ox—�
oÂܽš°¶çÈÝÔÆ	Ñb„,I­£±½é¸NiÉõÇ{^èd–PL[‘îc±Ø™Q¯dZÃÙ&ËŽA¯î/Ú;�!òùpÁBßÙs�ÝO‘΃3ײ³2¨%ÖuzøÄ[cé‘Ù§‰ÂïŠRfUÔgçúW·­ºì;§Øø8ÍLŠ¨ék˜"­¢¬tµ2¹ešòK¬ Á¾9c$rMe©€€Ô˜6T¡Ð‘1­QçTè{O–ÅË]Ñ’f³ÕÓ9�-©þR[0£Nk¾·ýµ�„ŽÏߨNïçÂ"?Gw~\“¬…XH”ã\�lã¼Å_¡’”*G�wQQBÁ9+§ªÁ¤�Â¥à(-n›_Òx3“mì‚gU‘wµé�íâߪv6ºÈ¯pÓ[óæ¢I´2Ö6ß ‡
×ÇëŸíI�Gûƒ—e<ªð1}xçªÀéž~ôá*@O€ô…¹É¶s—ê>‡Ú{#ØËz߈¹ç!žå<×Ó‹¦g=‘Ñ�GHö'²Ôe	ȱóŽõµ“:…Ÿ‚ëR,q@�õû´ùüqhŽN\VeÆdh�„ɘB™Ám*QZ!cJeåMj…Ïòá#éå8;¡H‚
-¾zT…¢gôOÿ’‹Óo0-šÎ०²Š˜hÈ�›9ÉÈ%m-ÜC7‚µ$©OãzAp9%mëƒf7ìÄîâºÞNÍíOKB¯Wˆà/°´e¡ìÔáo~f›]{ˆðEŠ˜*ƒ�ûN·G®²ÎÏ«Eô[‡ðQðu1ªÑÃ(X²ÁZû¨Âx5¤ 6™œ¹¯$ß's.1߬)Ç^r‘�au5nUG‘áŸÕÔ÷TÁzÀ½¦¬ÜÌ
lé�Ldi\”aÐZj(ô ¬õ\œñ,ôS–W2�ƒo³‡CÜ�`e­æí㦃F$êuÆ�z�{†ÂÎK!K#$
-bÉbðúuÙ9ðeÞWsS†ÚINñ­E$Œc�D3>ä:ÝÔ%žÐçIr<Û½;åµV}$1â°ðô£õmõ“¶)L£BòùP-PîÀ™ÑD|=ÜF—dã;õ…R^jºßsÒcþRÖ'šîϳH¥¹¼+jìF+ò˜ªB~ÈCgÙ5ûë	€UÓ(6û˜Ý#̼vÀ£Äòq¥þ…äž“ZrtjŠo�e|‚+ gÈb
�ÇXxÞÈÍGŸÆÜ/bøc§èüv+ø²òkbˆ BFÛ;l'a¡|E]éü×6téC¿×0q‚M™±I0êÇ`ÇsZ+£.ÌgŠÊ)ùcs³½-ãVé¨Ý³·††²¼&D̘ô”@¶Ý”ï³Oœöø]¥ÿ]ƒÒ˜,±Î
-qœ
-Çp\=Nü¬4··
-d;uÌ’‘ÜsÛ„÷_]e pxßÁÀ:Ïhâ�î|k±·¾ö'nTdÇ2å2fu·0¼e}XÇc*IÃoô}xFe6;acÑÈîXúúË¥áær,–êœh¤/º9;`©®GÅ–°
�,ÓH>%Oà"û|?éJ3iὓQ!Efb«èDCõñd±Mðhˆ–Xµæϸ­6ô#ñ†l»È…±ûsLóæßgél;µñÌ#%
-‘¼GøCAÌÑð}¾€¶6Ç¢³V»þ\ƒ	diKB´«Ù�Qïè.§~Þ‚´ÈÌ=ìäm’yS$ý-Ñ¥ªŽ¹P‚�´)keÅÓnM¡Gã¶Ëu·5%¬_ØEçMŠKÒcƒ†Œ8î5€Ã|5wìóµ Ô"öů£„²3ÇŸ�³’œVÉ÷
-žóø.Ѩ\éd¥(š˜>¯–LãPÚ Ôš3,¿Ô16še¬»Û²˜BG»O�åÜÏænP�ƵW‚®eoÁP×½'”�@çßÒKLýº-/ÞJ[ýŒxw]öG8förˆVƒÉsvÄþh;Ìšé£HÛF�Ïæ�8w&_a†¶j¡ã÷q´r©
Ý}~9ÃQ‡³¹Ã
ñQËöš‚¸¸ÅÒRŸv7Ý/샃ð+B­gN2ãâjÒz	ÂE‡`õfQ•8{Æ
Á9û»¨½qN5mc¯
gÀ<Åj½`ž@.vS;눂DÊknDÔš™˜�±ºO�ZÖµÜÑ–HJ”ää&¶[óX=
-<ÊîòÈYŸ­ØìZ
Ê£÷íé™ùÈ�TxÇSêhD¯Óe{Ð’ÖMÂÒé*�’­D#ôTtهͼÔ<~WêšÏ¯,Äѵ—úHLÆücœcyµ¼‡ÅÒîÇ<Ï	EÇvž¹t�ú“H;:±[æ¥�@B³CoјI3åÕŽ+´s«©Æ?™À“0�”VðÍíÉ ¾¹Ùì�ʃ¼ãA�œ'7¶ÆÁ&¢GL6öÝ¥
-Õ.¹YO¬êªœ©Û×™¥
o;å
-ˆçŒ¼™¬ï›»E|ÜÌÐðXuãý–üÂ˨µÎ¯ˆr ‰¯ûV™�ÆZù
-ÙòsøeìÕÙÂ1Y¤t�Yv~
-³L7,òH
-É_AWš…*QÙk4‹†ÊSgïë}“æý
ÝH>•b5?þ‘ÄœbÇ‘þ[½²%?QÃÔu­2NѼ5¯|F„=ktåÂnïìÈòæ‹ô'†<³Ç‡_Æn|Vœ	“mpéU÷YX ­|NHô¥kÊ rO6ágÌf
-SS˜K"
-Ï~~C®x®'ñ0yÉ#ñÚºƒ.UŠq/öÑŸ˜*Îö¥ýµ4Çï`àIm­Š´¦Ç”Ní.zßF6ù‰‘¡Dž³�¢,t°Í(¸™8é±%iXK{Ëlò\‘Vñ}g
x7wÏbðb¬½‰jÁ½`û'ü�Nf ÌB Ì´Ð¯1fBÈŒ+%¹7¾CäKvÇÑŽŠ¨'¶,³jvZÛÚ•¢lD¤È½Å‚…U?/rªìuGш¤59+òúøF´'Éûu£÷ÁO^C.¶ºó×?D¡ú
-Ë!«O$!*_—‘}	qufÖä­2¿ÐAQ”¤ÂâWH,‘Z8�gm­ÈÞ¨gA‘¸¶vaõÈ”YÖ¹›‘k (
-á�„%F<5Ÿ�¼K»ç´Åö Û3Ó΄ÕÁŠÂ~çD7/âšÅ	Œˆ¼êÇ™©E½ŽîûFí<gðSL2R\”˜um’|Ø¿I"-‘Ê�Q:‡‘w˜°ƒ„~U—ÒÛãäÚ"(ùy—k1WÀqr±·}§MNÉðÉ�†a0’~åBnJèÔ$¶\
áyq!~Y!Ê`Eõâïá$ìµòs¹íÒfØT\à\þL
-Pb”<pÂ*1oAjV±üVªñÖÃÚt”9oÕ H½”8OÝ#q‡æ€ÿ÷	ŒÚ‚€@·äV�̶xxOždhìQ[Îÿ_¨£òDà1Ös?õ~-e^¹Š‡ºêëé¢>3vŽ,€
-Ôù´6Š8ä­ÔÔs‡ÎCý—
ó<n!äö™…ãÖ…T«Ðùê“—J8R…’Ðæ(Qå|?Ç:¹6ê<™úÈüÙ:ò‹G8çü;k»Z[·É}ñ b¦ND‰)�Ÿ_ÚT jÄØ*à+5µÐ.‹j´aµ”n^@ì]•yE}±Ï» Ÿù¬w©…ò;ô'ÓÛéû#N䪦(…Yòg�v�ì™%c·ëµIˆÛÖ$J×E+¬ÂVbx*5uÃl}¦öKZ#Èóq%ñ­Ü72ŸÃ‹øiXu€á•©~Öá
œÑð\?"«§Ó-ªˆ„ƵKÑQˆÔÀMH@}ÎîkVÉP" ñZß4l§\Ê7w'œˆ£‹cÝj“Ô½?P…qƽ¯�ÝÑtךY{;¡8FÒ£N	ªÛÝè&~GýI¤ò’Á-M¦Qìb
pÚÀÒ”{»äüóMgyôجؒ/9…Áj(—¥x1ž}*Ú•ò£"jðr„-!…ÎÂÀ=ûð$eþš‰¢©c@“ Ÿi.��÷Ñ6*äl
BK±cn
-‡fð¦ZUiÎã0$¿Ü|MïШC¼ìí29†ÀeðOµY(FŒÔ�³ù-^¬–ŽŸ>Ó:2±èë5/•l†%†ÖhCÓ˜]¨w'hX6Í—¹Sº†U¬Òú|“L�AÒÁcçpÏ:i³ˆc¤ÖûúÆIX—m¥ù|(Ÿ:²�zS¶ÃÁ˜¦ß–ãòßÆîÖjb-�­
-ৗÛ"ÛX›?ÕSDâJªÌGú¬Ú‘o�°Ùð¤®÷ÐȳžñÏKv×F$-ã`÷5
-a�-‹Pšê�Êi^(5aò÷Þ8œÆ—†rmëÜ0Û™//UªŸÑbVPp©ûÉ`i.‰ –§Á’¤Þ¡áû	ÇÏ�º»ijì‘"f[ºtköÁŠ”È|^g†Í„ZÏš¥2ÝDÜyÓ—À>ü¶6•thâàoì\Á
-z¤ûŠâuÐyçøé›1irÝžã‘é£äX’Eßa›×ˆÕÇ“;˜/¼’>ì[ö±™³FcFÒªgãö‚á‹©G
-oL1MFr-ÍŒ™a=áÖVVF
ÎwÎ¥Xߪâs¿Ü”<¤Ómpö{g~ű
-Ϊ¶yY5Tl�´«œ+Ã2Ê$WÄ0�Ñ3˜K_Óm£âç¡^‚Ü<çëþ,�õ˲
šDÐ)ôà”2Ÿå\[EªâW&Ç'ÒN³…Í(JJÚØ~;Î×ÚÍ+噞¼ULJ;Œ¤3ä%…Óô
X¼©ê+ÎbTØ+E¸¸Ä	ßpzeÅ^÷.Ê“ îìÚA–£Ì‘lH¸“iM«™Àþ(ÊnS1¢e…•,vû©œ+½Ôä0euT¯w}Ý.8
-^ÝúãÝ9ÑF˜.ÛgÛ«q\V�ßr_g|œx[D&w—=€wÑ6ÊÐE�’tœ>-LEøbµ˜öbo…ç
m»7oÕ–7æWÀG»JáoÔbÐ5z^oDB°w\<à /r¸Š\רrRjþBõ�âÿÂ�èù!&†Žh„Ž6‹$˜WóˆB-3ã½ä�—K`­¼ò‡‰”zó°™ò‹N`zd åÇB™�£+sÕýN<‹-8�‡òŽ0;ë)Eµ&Ì.P¹$ݾM€ñ’@ݸ¦/Ã2HœQ…„IJEzïe‚q™ŸÑzÆ-tàQÍÔ¤rÆ‚}ô˜8kí±ÊäXë‚ël²iÀDâñJ”FR‡AÏŽ-H›2²ãXÒç+Ý"Ã�ð�ûÍÓšÿ+;Wó¸_G±.OÒxè"ƒ%u°¯“¿>Wû^ï.7 åòƒ  ž0ôuS¼2 ©'w²áÁ™ãi¨šFNù6ýUv“-«>]
xñÕ—*æ®çÅÔv‘?‡Ýâ–Ü©.M +0·dæ´ëžÿÇTcz¡JÍÜæŒ.5aö$¿¥Ê­°�D
ÜE…q3„f›ÊœÎ.lªdX±îÚûp}�˜•7M“ÈœÀÓªkQ4N5Åç­-…@²!G©¢6š
VœiˆR7\ÐMj„dcäî€doû4�~<”Òe6äm?Ð0I×�€ŒÔK›ÛS£ò£Ê%Šv¥Õï^+„¬Æ³ÒÛø!&à1:¥Çã‚'„D=ìà«&€©IãY
¯€äÂWƺ¥„RÒŠHw²ˆsë.üÙ­gäè÷mïyo�µ©ltx�ebmH÷fïêïo&Hì*âj]
¦Î¾kÒrX›0 —
ó=ø^‡,›�.Âõ˜/�Z—[’áXýõ~™?4ÒdÈÅ7�
€äñq´¤ª^JÙ[K™†OøDÊW÷ãº�ò"îf/’’u.3éªZšœ˜­9µÀµ”…”Û±†mùlË—‡Ï³'´4/Éu×µF�±‹gGŽ‚Ç;`Žøç:í·úGj¹ÃÊH‡Íi¤Î@É÷²ÇÖiFèÅžoºÃ‹…õXWAú�ŒF˜g	=çÇ$¥�¶¸i\üh¸Ôè¢ë9ÃËñüw<d;BvŠÄŸ„Œï6È™*cf[š—ÇImAÌžëIdM8R«DVUê‚ú�x×aÊÁ]Ÿ±þ%ܵ>¹UÇüv"¢îjÕiÐS+�4ã%⎩ñaoä{Zg=!$Î3å�õ1'Éê\ªWä¼sÖ†Ílâ4,N9Ã4¼�½þÄ‚;w ½'U‡z~”Š¡+É6ÉÎù¸©õ—õ€ðËÂT‡4çjôA¢ÞŒ Ó[‰ôïq�Wűd‰¶ÛŸ€¢Kªî1šÒÉ|Ö´øÐÉøKœ-`@XƲœ»Þj”§§¡øð©Öµ„ËÍñšüÀ¨ɯ¡žßÒ
#ZVöÏeÁr²lã[�cѽ·aײ‡xþѿnÊí"p¯½6Ö8wK
-†‚™!Y5ª¬h›Âø
-Ü`¹}ÊWÆÖý&_cWs£åÔlÓ¿›
-.«þvÐŽ–%u‰ ¯¤’¨]5�H4�Øe"›ƒhQ‰‰ôM“ªRM-D>í¡)rüˆ(Ëê­©è¥ÔYÇ9ÓQHŽÝ\(]
-Öð5,(x	J)ÜÀÞÁg0ý{wýçêŒx”
-Ô&‘#àfîÉ×kBq‚ÂõÅ{à1æˆè#žw­KH×\’Ëœ!w[‰‹Ë)ƒ?q[ø,YçÔYÿª²‡¶Ë•:Žè“tG½­3èÔ*þmèÊžÜ`m
-(¯-üü2ÉòFM:ãM¨sv¶Ä÷Эv"¥}
kædJî
-×cºŸËã+DoÇ–ãÉ­)ýe¯¶ôŒã¢—WÖ™eBdeìºf|íö˜-Œ‹Zw�4Vçvž&Ê=®ýÂ¥H‡,d|Làâ�3N‹'¹²,šK°#L„Ô]øm³)n-@Ü´¬N&…¬$ÿÈçÃíKðt|]Øl‡¢ËJ>h–
-’9„©²Í¦i=ÿ¨nuþò©­'x¾N»˜4Õ0
7<±–¹ûIíÓÏÕ=Î)iÇN{à$dQñãTË0¿§h¹kÝçµùÚÒ9äó
ÌèÍï ¢ËG¢�$éðf+vHÀÑ:ÓÝ&îûAoР`ž®³DGO?Ìd¨Î3ìŒ+Â̪Y¢ì'Y"-¨öíG3qŸZê…[|i<B‡{5mäš
i’ù%ù—	DqërŒh¤c碫Z´�BÁGE y"Ïž·Ü‰ü¼ tu¦…³´Ü¸ŒHþ›Zó-%bˆ9S‚®;…þŠG‹ŽÄÇ0¢æÑP±TôÕ••¿|P(×ïVŽ38áôQ�ülõâóüý÷}ΦPÔÃsM’È6¢±dRŒ<ÅBq´—áHW¡°XŽ0ÌQðê5e8ç tKÌÂÔ«UÑ\XîH£WƘŽ+úe@Ã\

-~º8Çùˆê¬ä{„W<:î9ëÏaùÉ
-–YæikQ9èúÞÍ…¬Ar¢$sCK¡¬+ÏHbw­ó¯n‘aÉ çÀ$.Š_ºœ0‡âÐ~jîI²Øˆ!<Ù3<í˜mÐ×µø}ãuÂgü>øb£HÇß·¿lè t#æh'¯¶ßk‘¿�
-ÎòÑÁÌûøjTL,
-gRH`\Âê‡%Aþ‚¸ÿ•LTa†ø¤6T:ùQè^·.¸Ê´DYAž£µ$À<ô{ÃiçŠKl¿XæŠÔÄ%ã»<ºr£²‰ÉÇI§ßðÒ÷®ó¥©XX;|¨‰êbuÊ	X‡jÂÕX£Ô†ØÒïI7Ù¡™
G;³*‡Òe÷ŽnInî‚(¿æ2ÞÅ¡æbE§4!0{šÕ?ÞñŠ”’nô0g™²ä}»O4,ä]Èhö3g"l˜\¡Ì±Óp•Í»6²Z“šÿêŠ/¦¶ƒûeÝ$³®"tÕ¤È:ôƒòõ
‰›îxÿœŒ¥?Àh[MND.ÇðL7|SɶtÑð„ö&øyDZÌû*Gmpr8\UÛ¬gTÀ­X
-h�†“Ì]�õ5ˆ%?»â'º˜M¾×ž/•[C2°‹ð}j…Ž.ˆ&•µ7ˆˆÁ�õÖ
ÿ‰r¸‰*½Æ¡rsC¥‡Áà¼qãl§ž_€Ôv¿vwŒSX�~K™�Ê”	Ç›¸´5"_¢»åz�W‰8L�B‡ôÚÄš+H*Ƃ߯@K„/ë·Á)¹²%Í%]Üå–=È«V,è
­{«RW‚:ik>•HŸSTÇÿÉ%6vô¾ö\áñ-R•@BêÔ“fÊø²øÕUrÇ–÷ëSv¾]õáåG:ƉÐì%*
-ÖäJ¶$÷A­B:{~PŒ­|ˆÊ
©¸/N˜¼wéàý‰ØaÊ9ÕÒ”®òM_u*u~0Ã׊éào‰èX0Êr‡ÖÁÙqh[ýl½®ØÑîáÃe7æMà€;æ,—"íFóTIû ¹²ÐŽ÷_â05#¸.cœY‰]j�˜ª:Ç¿ùö:Qqæ!å½¾iÀÁÈéo‹¡¾{£6jÆÑõ({öû^ÁèéWÝ{ƒHÈ%ŒéK!zþox
  µ˜˜¦°Ö�ûˆÄll¡Y:Ðÿ3ìvz6G0†Ç&QÚ	�äŠ�«‚n‚}uãaI#߃y>g—/¨`.n+/­Ð^q›‰t*+ˆ��âõa+uF¼ý} ˜Ž¥ï>à£jŽÄ˜;â¤ÏLUá�À˜ÍPÒ¬ü“žÖkm"
,Á(\~éGP»Oªt[‚ÜŽŽ6nxf³lTÆíØH�'ºSÍõw<²qs)‘‘Ç~*Ún¥
ÑBëRËÏ++¥È›!®)™øÄ•™þîêñþœCåaIyÃγ<–äxßsG²)¬•¢×®8zÅJäó`ãn©ÌsÌ™æEHœX-zoè=O!�å™B?Êóíwö»
-†�»·=z/¢ÇCï¥ä‡`RðÏ!¤Ù·)žíú!Œ·zÍáí;LZ|FÕGì%«¯ˆÅ�Ö¤H6}+8ã¹ðú¸°ÐÀÑ�/Žë)díˆz°W‚úXƒX¶¾m«Ø½•„»ù5gR›žF¹{‚$³*ú)u\=(Ñ-‚"Ð…÷±,â¢|]ǹý?9¿YÐOØ[L‹&ãÀŸrS*AØ�f­ši
-t)ÌXN9¥D±z¤‰-D0Œ8­àª;ÁEÎ+p“ùhJ½:–Éîföâ}©PýSücd?àó	<ÌÈ“|Šˆîç}®rw‚RÕ:Í�$å·=„~mÉ]]˜RòöÖ„½®íX((—€¶Ä?Éž¸‹e»¿èœ¬ÛXÄ
-Ü�¯*˜Œù¢V}ÒD¦ÿôð£ÎÈ
-}ˆ2àq=G/¦8õ1ÝüÍ/]Z?ó{P>yêU•œµú}éÇ2&@žÊå6Þä¡þ;TÆ
-Ý‚Æo
-©õŠÊ§üyž+¾û™’i†2£]Þá­•\÷¤Mçó:µš•wbÕ‘…Ùˆ×hg¢I��µ#ŒºÛà@ïuJ*³É<¸S!ÙÖdNPÂD )­×cÅkø2æòò›b«ë
-JÎtŒ.a½�AöB¿×n
8b¦”w»VŽn$øÍé�)4Üú¤÷VçËÌ�ŒµµèN‰R£ëÐŪ—Ãÿ×>Y¶5
(QD‰!%ÝH�îfà¨Ñ9º‘n	i’"]Ò-Ý1ºK�Ýݵ÷þ‡÷Û}îù
çÃyžã•�”4|œ"ïñ`Ûý]_€ßÿ¼�ݲí\£$«:ê¯{¶F†Æ»lìÏ3¢?ÑL$G@Öóå×vmôãŠ#Žª×°tή4ËFIñê\é±¹†òã–ÊcLÏBÙðn¶²e™i¤ÿs;<¶ ¼ÿñÏ7JŸ�¨ie/þ5÷“FàEZUuç!í¯îðœJMþ•³ŽôÓ�	}Ëß–~¸
-Âòé€z{JE‰FªM Û„�u–æG0iž³ÍÀ†�^µYkúzþ'ôÍòH¬n“È([ÒKFR}ÿ^÷ôdk
-±5b�$ßì}Cd%#vﱓ*š°ßÉ
‘ú°»­¥8hñÀÜ_Œ»Ð7¥U½2f
-b›oÒm÷ãÅY…½jãnQŒ˜�fýÊm½­�ªm&*þ8”Èç1|ñ˜a¬~– F‘«•¢ûÎòXQ;(_ÆSI0ü+p˜ý&�á¸$BF
-ý1ì_v#ZâÍ,µgªìVØ
-*‹š@i‰úû¿ž8ëäCî3luRŽn£ÒsbX‰É ýÚ�Nã0Lb£?yrK—Søƒ=Õˆ�áÜá@Æ	žÀlþ
 ¦Ã<˜
'•AÅ87gñU˜
-Üxäø›Š•XGŠyº'üá9vµ,Õ½OÓ
à¬KÏýØIC`­”¿¸9Âò§é¸ˆßcZ”Âh.RÕŒI�8¬_$òfIKmÌXró–€àÇêŸ%Ŭg”ÆÂüˆßY'ºVR, ¨B~
ÐÔAQäϲ¯u£s¢€Ý_˜Œ\@øt-ò©Ÿ’>ö‡Q÷FÉÎUŽ«l$Ô.ËW(¦8*³Ÿ{>B7@-7쑘ôy™Ù7º!„³¶QèÌL}*Ÿ$‚WVÉÉ®š±Èñ×´//2ZA$¼�§¥ªb;>~T6EÕ<Õ¿¿Vj3ps[‡Ú[ë�#.JìñåY¯ª0ûì©'™„±ŸµQÖ8}Q¥ÞÒš½.H�Òý¤ñ‘õ$=¨â¯oñöaZ]‹#6ž/¿¦Ðô¹e¸ÞZ‹ÇM{ªh=Hp¿œ¦-Õôš£åežÂúz‚€ÛÆ«ì(Onû�÷söQY²æ‰Ï&¡I(Ja]�U›-fø´Û[ˆÿÞóݦ6vº%š.[Íá§KpyJÖˆàêh2nösjJ,©VŽ&EͯU¨•x�9øW+0éOžÜX‰3„\
-‚¾¡ÉzŒ:s[­+ž:[´‚r7À«_ó熈ÑFÂ2Õ:¨Ù�˜-Aè
-œÆâO­Œ,Eß�÷�;XM«âU†æüìeçÎ&¾¸cë2“.D£T�«h8&Ëe7nV"ÎCøpÁ¨Ö#}&_ot-ç2ÃæX�L¦ºŠ�ðï"’‚Áf&ѭ탔w¤éʼŽE9Ãê¶Y|t\dà=_©Ÿiµª¯9ÅÝU5½<}âoCʬe±É·mQJ_”�–õx-�ºDïä»3¦Ÿëï"‚_
-{8þF�ÑÇæ–éì	é–sE�cø ôc/
¥Xne­£ß	Ip’XÌ,X§x©o�ÞC§C7}yñ8㟑KÓ•F<Ø—¶cÚùc§>É÷"ÊåæÔYxVì#³í³9y«bTjýé‰NÜáù„…ª�jŽ\«WÍX!Ì[Ê뺧b'ÞŒÆ)<$1ôÊÚ[,à§	ƒ@ŽWÃc3/—°WnY"¬Æ4áé[_Šüå–#xÎöf3I�¹[V¦;ñ²è2f’a_ÏãX;q)ö�&Öö4FØ…È÷Ÿ
-=X¤9�ƒ:Ø•ñÒ
-†*Nñ(ßc“À“
-ÎQÓp/6è~�
-ê™ã2ú»‚îY$óµÉ•­ßª2^IÑPYm3ïÜÚ×Juý¼=ÕùÌ~9Äÿ	2©”pmPkDÉ�	Ç¥)DcX¨Ù콘ûk*+ÇMCÆ{Ù´~­Íµ)²è5�¿¯ÅL|yÿ1ª5u‡Êë�ñ÷Òc9„ÍrU¶óBDøò3TyÈ嘙	SzH1ß+`Îð¶+§`½°W5Ó㎎²ÁÑÃiÁ™,÷ò}cýö3!§ïÒƒŒ‘PuaÛ›”Ë tòÍ|T\ÅL,p�ÈBHðì9çÑô)8H-ú�äjj*ê=êOŽ
-Œ†<\a/r¼ˆvÈxµfíÉCvP€ÕóuóföÈy§Åm4ÍÛÆajùlW¤JÕ4pñû
Z¢Aÿ6Ñ®–B�][¢µš×´B©®¦Ö
-å�UÔwUMõ»gÕ"&
-C•Á&ûA×"4ÂÌ]iÅÎ|,›ž(mÍ…pêÖ.‰ý³oRŽÕ]¸kŽ¬¢PÖ¡ZÛZŒŽT2Ê©‚pC¯–dô.Rn®f™7£žØær
ðk®–-!OõŽž1t¿9~‚ó–�‰æ·q¼mxYæó”9gK’}ÃÜÕè×å HéÏAf™\pCÊˬM‚._óBâÚjq
À¶]qL÷‡Âa¯¡n—ˆ›´¢('â¥&Cv­pñf–¿�‡OFÙ2ö
-# ð:øF(‰¥YäsäLèÆùxÂJßÓ%ÌgæÂîˆñe:‡¯#0®ÿëÊ»3¯‡óíLM¤\“wŒgßRkHäŽÅ_KØwÓªÂìni–ŠØ±
¨wŠlNþjsßÑ8v<o¸ÞâÖ²ãU8^ë|Wš�
-ÆúÁÿ%ž†ëÿ	öÿÿsK¨«»³#ÔÕûÿ
-endobj
-879 0 obj <<
-/Type /Font
-/Subtype /Type1
-/Encoding 1930 0 R
-/FirstChar 2
-/LastChar 151
-/Widths 1939 0 R
-/BaseFont /HZZZJN+URWPalladioL-Ital
-/FontDescriptor 877 0 R
->> endobj
-877 0 obj <<
-/Ascent 722
-/CapHeight 693
-/Descent -261
-/FontName /HZZZJN+URWPalladioL-Ital
-/ItalicAngle -9.5
-/StemV 78
-/XHeight 482
-/FontBBox [-170 -305 1010 941]
-/Flags 4
-/CharSet (/fi/fl/parenleft/parenright/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/A/B/C/D/E/F/G/H/I/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/a/b/c/d/e/f/g/h/i/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/emdash)
-/FontFile 878 0 R
+/CharSet (/quotedbl/numbersign/plus/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/semicolon/equal/at/A/B/C/D/E/F/G/H/I/K/M/N/O/R/S/T/W/Z/bracketleft/bracketright/a/b/c/d/e/f/g/h/i/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright)
+/FontFile 939 0 R
 >> endobj
-1939 0 obj
-[528 545 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 333 333 0 0 250 333 250 296 500 500 500 500 500 500 500 500 500 500 250 0 0 0 0 0 0 722 611 667 778 611 556 722 778 333 0 667 556 944 778 778 611 778 667 556 611 778 722 944 722 667 667 0 0 0 0 0 0 444 463 407 500 389 278 500 500 278 0 444 278 778 556 444 500 463 389 389 333 556 500 722 500 500 444 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1000 ]
+2101 0 obj
+[600 600 0 0 0 0 0 0 0 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 0 600 0 600 0 0 600 600 600 600 600 600 600 600 600 600 0 600 0 600 600 600 0 0 600 600 600 0 0 600 0 0 600 600 0 600 0 0 0 600 600 600 600 600 600 600 600 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 ]
 endobj
-862 0 obj <<
+924 0 obj <<
 /Length1 1612
 /Length2 18760
 /Length3 532
@@ -9130,7 +9914,7 @@ endobj
 >>
 stream
 xÚ¬·ctåßÖ&›£’Û¶mWœT²cÛ¶m§bÛ¶]±*¶­[ÿsºûíqnß/}ß{Œßšxæ3ç3×c“)ªÐ	ÛþŠÛÚ8Ñ1Ñ3räÍ­:;ÊÙÚÈÒ)M�
�lpdd"@C's[QC' 7@h
˜™
L\\\pd
-ŠšRò
+ŠšRò
 P7É;8hôJÓÏ4¢<¯e·!´ØÕv'•”õŠß¡¾Ow°8À\=Qù‘¸ø¡“>Ú!ù¥ÖÇbt¢4‚|«-<=#O<~z¤ê¹�ìÛǣɉ…%ãq�@$�ô³ÏÁÐR«ð§‚JoBÀ»i¿ú$ÔèöÔË##Å%�°–}U4Í_³i—}O‚LoàM”s�lݯü�y=?É+”8Í5—ûµîL&æˆÅÛ„?Ø;kI8“	]O0ü
 ôX‹ýv5�FMç|.òöZSª‡æâû÷eµo®ºG¦�|ß^£dìfÈ婯?ÿxñ¤}GðrçXQ†�•¥ïí«°nãÄ"‘ìv¢t³íg•×ÛudkàXþæš1­´¹û±¢þúgÔ\Ô®:è'&
 yY·ŽeFÞÜÉe$WemDGóÒaž@²§—ñqfS–ô6BÙßõȽÒU?ùÏ ž�RÀ=²ÜçqEË4|Y²Õ7˜Yàýe•çŠuóL*”ÅK	ãŸ	$HÙU&�Ä–ÒòÈõ×€®8ƒw}_þ×ïÝ�k0žGFÔÃó'€r¥wŽ—m�­ølËsöxRxÏ¢ªVæ±Y�D
@@ -9216,36 +10000,153 @@ eËè2R¼ÄûÛûyŸ?à	·Cžtж‰ä€¢rªØt°W¨ÂÃ^Ã>
 ŠwêˆVM¤¬Èôv£äG�Ótøu #£yå\x¦CžšƒÇŸÇ˜ZçU.æ�@ÈÄôÄe²˜=æ÷ÉáyÜuù^é"HÄÇ׬íôœ™Í ®h;@‰¦$ˆ;ï¼ã>ÛL‰†¸æVìP¤ýÄJÍÏD{¤>pV$QJ¬©ô=˜Ð9Úp€Õâ«ùD¤å0ù_‡b>éRêVtÃÖ ÄM
 Úð­,6äX€qÐ-}nJ®k^¨£ô@l€¼ÜI>Œ˜×TqÅOшتxín°úâ…õµ4JÌäÅV�kw¨Š‘þI’€¥¤\°^0Vò˘íep«%"h*
êm�QôB±Ýë“ÙÏXšEÿ¶Éµú0üöA•ÚªÏPbÑËöê6EL7‹:Æ6
 ϥ
-mŽ[A±Ræ¦ØíŸeµ1£¿YÝÒ~kð¢�|Xžë,|@î~èÒ<¦maöè“žÉGJPòíRWù˜ž‰P	ŠïMÏÜ£Ëÿx½qì’‡î“ü\Ÿ,³›}ÛÃë½E#û¼ÐÄ!áosA8G'Ñ´2›_ð‹¿Ào8�V  qqML2ÔËÜIVœ�má\©ü:’P -wÇrµ?
²T§‹ÏlKðKáJì}Z%=�|Ó˜~¹´ê¡¿QL-jÅ¿Vq†/¥ökåàM×±Û÷a”÷1•£Ôq/dWµ8Ã
UnˆÇrÉ•Ü	“6ŸùÙ¥»R̓AczCËSåã§
-endstream
+mŽ[A±Ræ¦ØíŸeµ1£¿YÝÒ~kð¢�|Xžë,|@î~èÒ<¦maöè“žÉGJPòíRWù˜ž‰P	ŠïMÏÜ£Ëÿx½qì’‡î“ü\Ÿ,³›}ÛÃë½E#û¼ÐÄ!áosA8G'Ñ´2›_ð‹¿Ào8�V  qqML2ÔËÜIVœ�má\©ü:’P -wÇrµ?
²T§‹ÏlKðKáJì}Z%=�|Ó˜~¹´ê¡¿QL-jÅ¿Vq†/¥ökåàM×±Û÷a”÷1•£Ôq/dWµ8Ã
UnˆÇrÉ•Ü	“6ŸùÙ¥»R̓AczCËSåã§
 endobj
-863 0 obj <<
+925 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 1930 0 R
+/Encoding 2092 0 R
 /FirstChar 33
 /LastChar 125
-/Widths 1940 0 R
-/BaseFont /HXBZDR+NimbusMonL-Regu
-/FontDescriptor 861 0 R
+/Widths 2102 0 R
+/BaseFont /XFYNBR+NimbusMonL-Regu
+/FontDescriptor 923 0 R
 >> endobj
-861 0 obj <<
+923 0 obj <<
 /Ascent 625
 /CapHeight 557
 /Descent -147
-/FontName /HXBZDR+NimbusMonL-Regu
+/FontName /XFYNBR+NimbusMonL-Regu
 /ItalicAngle 0
 /StemV 41
 /XHeight 426
 /FontBBox [-12 -237 650 811]
 /Flags 4
 /CharSet (/exclam/quotedbl/numbersign/dollar/percent/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/less/equal/greater/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/underscore/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/braceleft/bar/braceright)
-/FontFile 862 0 R
+/FontFile 924 0 R
 >> endobj
-1940 0 obj
+2102 0 obj
 [600 600 600 600 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 0 600 0 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 ]
 endobj
-746 0 obj <<
+884 0 obj <<
+/Length1 1620
+/Length2 20127
+/Length3 532
+/Length 21036     
+/Filter /FlateDecode
+>>
+stream
+xÚ¬ºct¤]·.Ûv*I§cul'[£b§bÛ¶mÛ¶­Ží¤cwý¼ï·÷>cŸóëœý£jÜk^s^×Zë5FQ’)ª0›Ø
%ìlA,ŒÌ<
+o(:¨Ñ_‚ä¤ñOFuØI)Q’¬¥®‰Í:T\+kÀ2ñ´Ò(ÏË2+­Ô»Ð]é¾çAM�¾×Q­?A"tto¯�$ÏÊAœÇÛwÎB�¼ã¢ü1lþUx�q¨eÝÒäöt¼d"�$ÀÇŒ‡™M ,tEÃ2g§ö“0AC�ª•ƒÇ“IyàbL�żê|c
+)/
úh½0HéZ=`|K›@?ôî3Ob¨cËL<Bß1d÷h•ß$™§”±ù¡î]C¶Y™�GOýú!‰�ëŠ.=÷«Ý¹½.oÇ°,½ƒšt­¯”3sƒÆÖ®·qbé§0ŠÅ°ÈDY~–iÃøu(Ò˾‰ªæ³?ž�
cŠÔbdS7sYð§>ádÍíìÉQûcz‹þú7¾cèü¹$	Æ>2Í%—¹ß°%F
+>@í£dJî'�¾T¨WÝ–
’ÆÑë«úþ®@Zl—,P* ï™7o6x©bäÀ×ZëíùOרc ‰^à°HY¹ê¶]¼„qGÝx-
$v·úyüJŠÑ‹lüwÝ„ze|5lÇ¢‰Û&^^Y†¯d¤å¸=眫Ø'ZðþžQ.,°#p¯ü°Éøù¨~j‡|i¯ÖÍ_)¢é<-ëqHb_Ò»S3‚4~«Ò/²Jú
+ó»kœAUyÑ®
D‰<aº/Q߆W}á{N·râ‹0¢ž¦¸2üuŠþK!Ìe§óç-õœ_…Éæé&·öŽtºö›)×öÜÑiÞÜ=39^TùyÖVÑúA`›Ë¯“Š×1³[´³Cr!F\YÔT¯É$0¹âv¬]1¹â2õ¦2˜÷¨ÏQï<^™2ÄH‘,Fð«­Ѐö

�ÕúSöËö$§f@ÂÝ}7EŠqÂl™ûÑ0†R
+CùV¿�·¬�žg&�>ˆ„’"µpVk_í+t·—$ïÒBh�tçß’¼`ª-�‘C†<l®I4@‚ŠÕÆ6Ã0;˜‚û;>Èù}îÒôƒ¡OQN¢¾hÉlÙ‚¦X©ÍÉÃÚ-ðÝ󜚮Ӳå‰f]D–„]fp`Ý
+‘ו‡ošDƒŒ¾”¹�yÙÚ<1Þö÷Š3
+9àÙ÷:Å„Ÿ\ÉFlý¹ŽNÁçµ±½F¥1¢{1I#�ù�#gÐM!Å&Ð!ùf¸¸<:â‘�[Ç‚êÞ
—dx²U�Ãü9‰Åm³{¦¨F�®Aº/b›ƒÞŸ&ŽiÊù0ÆÊ<É{–3Á—)t;¾
+I…ÆÄ8á J’«2ðÚÁF–û†t÷+àK‘D:rtËSα£³ÒFX°Y¿ƒw0¢ºãÎo‰Õ"Ú-P¼L>Vš˜ñפ2 Ynîë|CVÞZsZú Ó†x9�„ĶU&bNž\@š'üýlNÔÞû1ãWÎèjöE¡¬¨ÿI1©~´Ç)¨¥P#çP&¦B5ãrEò¬é&Ü�ìPÿgÖ©‘ŽrÏ3ä5ë(h“‹£66q¨	JÄ·­ï|à·Ë Ç#·û:[‘úìƒîi0žì­ÎÚoœ*3ö8¡|SgrJ_ˆ·¬»TáZ‡%{ÍbË„pøTþÃiK¢`È$Ñò-ž—
r
+g}%ž�¿<ÿš¦¢§y>ÕdsŸZˆ—ŸäØt‘ùB<*C�uù­
Xò4RWJY¾?Ôse4¿¦öÁGGøË=1nI6ö>â¶�dxøÛzÀÛö§úø÷^`K­™u ÒZ¹$gMÍÍE®Ý§R‰³› |~Π
;âIךÚCXFçÔ[ �"9Û
+%Všy¯Žç½wd`õ\¥
+?>Lîw\_¼__º‚+�úˆ—Ï*×5²,Üâ~‡
+ËGBÐ×4
$<]q…x\6_Ì�I_ϱȸtÓ<< ±ã[ôV(“K—�ê£hAÑLÿ�ž�ƒ«±î�«k”“Á™-H¼~„ÈëRtàÆ;ê¬ԧОSŸ«,Ä>x›ºQmMΠà¸ÀöH|’MÇD-2:s»ÁK¾jÍ)yu$–©Ó:ž•([mq!+G�Œ™SÞz‚PùÒ†�ÞjLñpö«Ys%²Ý¶p¬z.M[›t]Þ§ÀŽKxÀKPų½×ÕêL•ªçLý=à'd{ì-¥?Ö­�#†‚­¢E^+#6#–
ñ/–“õ­ñ¼ÍTñÖ<ínÀZ‰/”Ú8Y2ÓØ/gÓAÓ›øæ±,dx
+v]šÑØ}a(ôÉ:eÝX!±«AÏ�[–Ž×ÊÜ’ÀæƹƣÞ3a‘^£ãxR°šË\ì2ª<2€ÿŒÍmxÕîQžæ‘QáE‚ž�È¿¼=±HF,ÃØðªÊжÌ>Èü]¼¾Ø¨ÍqZ\Q0³“×-|/SS´æ;ª?
 [B�«˜jÜë&BØ’ÆIRòu“$€„ƒƒj°�i&ÝY³$——½å£
+ç
¨÷i
¼%0¸)xëõdïIG•&Ž¿œÃtɳ6†ž7|¸.&õ
+	-ΈŸçf™ÕÈPMC°3p§î¸eÚìq²áBÞæh‡~ò¨,þ�¶¢Æ®¹ÿã
+¥;Kƒ{jPÌ�CÛf¯¨“Ø£_:©Ãb*¬Ž–Ôº°AïhµûÞÈq‚F΃a¹¦Ô9›X´Öò€)t‘ÚQPAng©§âÏíÿ4»š†ü˜©>¹I¡Îúîá
+-5ù\;³½�2>V®±*T#
+
+@0‡cz´ëðcL"¸¶©ˆ1tQ mhž7OyÙK/=mŽ1Ü´iüŒÇŠ··ôŒÄŒ%¥”v=
\lB­×9Ɔ½‰ü‘“WŽÄõÝ©s;Ú¾†øðýa_ 7,Z±jg[À6¾bV¤ÊY—qá=›TLÀTæù4¸©ŒZä¹xæÇ©D
 S7Aof„ûoŽ¦¹¶†d¬Å(?#	Í”¡4÷Ú7©¯;˜Ác%$P„P|¹Ú“k½T˜d
�pR(áæÓþ;	@UÂŽåo.P
+·?å?«ì:º;rº¶;(œåÒHBÐUQ%Wy¯ÇûcEàÝÚóÌãÁÏbמgo@¦
ð­q´ÔDÖèÈ'
)øóÁ�«ÄhåHø*²ï›#™·ZÏYHá(%Òïg!›µß¿ûW{|êõhñGÆq¡ÄL»»o–DTèd·ºãú±‚e6D²]�}~Ç¢jé‰
+S(xÚ#oÓÜõçç‚
+¦cô)E}dðHÓœGNoj<]Sç¬<âu½âyקûU�7Áê­²‹E«¤py÷á8'ËÍibHö� qT?q::جöì(ݽïRgÝý>^ØûûWM€Õ}ýÐ駋–Ê{ÅóZˆÔ(sï[6ìÂO‘zü
+I³ÙêéÇ–T©-˜R§5߇›‡þÚ@ÂÇŒçoT§÷uf‘‚‚Ÿ£;?®IÖB,$ÊqªG¶vÚâ¯PIJ	•£Æ»¨(¡àœ•SÕ`RHáRp�·É/i¼™É6rƳ¬È»ÚôÊvökU;]äW¸é­�ysV†$Zk›o��ÀëãõK„ö Î£
æe�*|LÞ¹*p¼§}¸ò× }an²éÜ¥ºÏ¡öÚò´Ú7dîyˆg9ÏÅõð¤éFOdtã’ý‰,5FYrè¼c}í¤Ná§à:†KÐe
fŸvE#Ÿ?Íю˪̘í‘0S(Ó¿£ME J+dL©¬¼I­ð^>|$½g'IàŠ´?"týy0ïù4=:9W8ùÉÝ1Õ
+6AdQ›¹Í,>N)¥Ò©ðOã’ÛÍ·o}ŠÓ3U¢ªõ3“ÏŠC…}àp)Æó
¿a™FK›ó+	•W1{‘¨íœiNŒZ?¿~Ô<îZÛ
×Áˆô~ô}“IU?û
+^ºö*ÕÊ;â˜<\éæj�B† :æ‹ãk‡o™ùžËýta�A=« ÓÔ'ŸÔÐH•ÄN!z^“«ÿw¢ëKËÌ´«vߪý'ZÎØS³_-Ÿ!¡ÑÐ9†˜­yƒ±<`–ìÜkÚìƒ8˹‚®UF¡èýÒ¿äâôëO‹¦3xª©‡ì†°b$pãÀfN2rI[	÷Ð�`-IêѸ\\AIëÇz£AÅ
;²;»¬·Ó@sûÑ’Ðë"ø	,méG(;vø™�Ùd×"|‘"¦ŠÄ`྅Óé‘«¬óõlýÖ!|t]Œjø0Š–¬¿Ö¾ª0Z
)ˆM&çEî+
É÷ÉœGÌ7kʱ—Ed`X]ŒÚE•ÀQd¸À'D5õüDU°p¯)+7sZz Ce´–
+Ý)k=g<
+ýÀ”å•LâàÛìàwD#XY«yû¸é ‰z�p£^àž¡�°óRÈÒˆþ‰B
˜D²¼¾Ý_v|˜÷ÕìÆ”¡v’S|*B‰ã˜D#ÑŒ¹N7uˆ'ôx’ÎvïNEy-‡UI9̽Ç|iýB[}¥­Ó¨�ÜE>T”;pf4_·Ñ%ÙøN} T…—Äï÷uĘ¿”õ‰¦ûñ,Ri.ï
+„y„ÑŠ<¦ª�òÐYtÍþz`Õ4ŠMÇ>f·ÅH
3¯�ð(±…¼]¨!9‡çߤ–�šà›c�à
+è°ƒXC#Ä1ž7róѧƒ†1÷‹þØ*:½Ý
+¾¬üš"¨�ùᶓ°P
¾¢®tþkºô¡�ßs˜8ÁºÌÈ8õc°ã9­•Qæ3EåŠü±¹ÙΆq«¿tÔöÙËCCY
^"fDzJ 
+ÛnÂ÷Ù'Î{ü®ÒÿŒŒ®AiD–Xg‰¸N
+Ã2k}„‡�Œ°±hd7,
=½åÒp3{9uN4Ò�œ°T—£b؆F–i$ïó‹'p‘}¾Ÿt¥™´ð^ɨ�"3±Ut¢¡zx²ØÆx4D	K¬ZógÜ–z‘xC6‹]äÂØý9&yóï³t6�?ðÌ"%
+‘¼FøCAÌÑð}>€¶6‡¢ÓVÛþ\ý	diB´«Ù�Q¯è.Ç~Þ‚´ÈÌ=ìäm’6yS$ý-Ñ¥ª¶™)P‚�´)keÅÃvM¡Gã¶Ëe·5%¬_ØYûMŠKÒ}ƒ†Œ8îÕŸÃl5wìóµ Ô<öÅ·£„²3Ç��³’œVÉ÷
+žóø.Ñ°\éd¥(š˜>¯–LãPÊ Ôš3,¿Ô16še¤³Û²˜BG»O�åÔÏæ¦_�ƵW‚®e	oÎP×½'”�@ç×ÒKLýº-/ÞJ[ýŒxw]öG8förˆVƒÉcvÄþh;Ìšé£è‡µŸõ!qîL¾ÂmÕBÇïã@håR}ºûür†¢'rû⣖í5qq!Š¥¥¾Üt¿°wô¯µžQ8É@Œ‹«}Hë%‚Õ›E1TâìGäìï¢vF9Õ´�½Öœþó«õ‚y¦
+°YN0Û�æxôÞù¾•
·Z1#‘pÐG�)œïò±ž{+¿ÝªjwÒ±E©áš=P´Þ7±ÙÑ[7û¦“¸NYYÇU¸yd
+¢ˆÉd)$±¶Š¸[a# :‘�ÁÜ.‹ÍÉü�7LÓ„�(èòGÚyö é안øžwb�MŽÓüÇÞN�Ëe?ZÎÂfRc¯PÌeš²ªéQÚ"äI8�
+4Æg÷ÎüôL¬¾¾Ò?Âlœ�á6_±Â؈u‡ëî$àÝÌ;ÇDpBÝu¢Cbî›#13º;Ï
+*‡Kò·¶‡;¼-’"+ܦ˳-ý<ÎÈt_üöYëÎ’áBÁ‚¡$üé©Ò.&�>Ùe¸R¸¡3›Áÿ]u7üaÌõñ.R8‹zAµÓãvnXLûçpYTÓôª['ÒøUÒà=|¹üº*ÚÜO�AŒ/–*CØ
¿?CÞêh67÷
Wáïx,V½ªŽ_RÆò^/H–}èÈ;‡¨=+mä káÕÊuS®ÉẇNbnN’²‹Y)êctž-yá¬JHw‡d`‹£Mó®úí}KÕ4¬�«–!øWù…�sYÚá•MS
|•Ð§DNß"æµdYDé
+Á4õ5’KÄó}†#‘.§­¤‹R�‹«
+õS—¸­oïV‚•¦x{ì—?]Ž{øjA}øé{¶$õ†BÇÃh>/o†"U¹»ý´P‡SkwUçn0þ€8âàB¶ü¾F;u¶pL)#–�à
+}c6!„L¹âP’{ƒá;D¾dçqí¨ˆz`Ë2«f§µ­])ÊFDŠÜ›/˜[öÃð"§Ê^w�HZÁ‘³"¯�oD{�¼_7züä5àb«;ýS@$ú¡W °²ZðDò¢òuÙ
Ù‡W{fMÞ2ó¥I*,~…Ä©¹#xÖÖŠì�z‰KkVß�L™E�›)¹‚¢ÞIXbÄSóùÈ»´[N[lº3íLX¬˜
üçw^@dqór
+G%vA)ÁÃ
G¬³¤f‹o¥¿ñ`Ý­LF™óVõ‹ÔK‰óÔÝwø`ø?qŸàÁ¨Í	tj@®È<a‹÷
÷äIFÞµåüïñõñ
Ú1*Oîc=÷Sï×Rf•«xh¡«>Îê3cçÈ
+ž(—NÑÄåi¾%¦�Še¿€Ù?ó‡Ÿ›o†`ƒbîª0Ø– õÚ MR�¾
+Xá�…<§õ0ØC"ôñŸjè(–ŸÚŠeÂÑ_{Ú#‹p7ƒLìÙ5`:ì¥~Áì4«¼„?ãL®Ý8Qó\‡,OÇ™ÒÀ;ŒmhT Î§µVÄ! ¿h¥¦ž;t*ê¿ôŸçq
!·Ë,·*¤Z…ΟÐWŸ¼T‘*”„6C‰:(ç›ø9ÖɵQçQÈÔGæǦߑ_<Â9ç×YÛ­ÐÚºMîƒ3u"JL	üüÒ¦Q#ÆV
_©©…vYTóVKYðçæÄÞU™gÔ»ð¼òù‘Ïz‘Z(ßC?¢1Ý=�žâD®jŠR8€‘%öøg×Èži2v»n›„¸MM¢t
Qd�Â*l%–¿‡RS7ÌÖgj¿¤‚<ÿWßÊ}#ó9¼ˆ¯†eç
^™êgÞÀ
Ïõ#²z:Ý¢
+�Ha\»¤ÿE�H
Ü„Ôçì¾f•%bA
¯üIÃvÊ¥lPsw‰8º8Ö­æŽÚz1IÝûQgÜûØÍMw­©•—#ŠC$=ꤡ ºí=ŒjâwÔŸD*/ÜÒdêÅÎV
+�ž‘�õ÷¦ÝÔÆ.3±õƒ¤9ù]v\_17OnS{‡71¼ôtÝêÅËCgû!Ìõ’+
Ì\\j·Äž¸,1Èßß62–e€Æ§¥ì¶£þ&kL¿ÜêWÎc½aàJÚQà&AY¸Úãt�¼Å+«8•�õà�ZõÐ
³…V|Òœ½ÅÆú¡/½99t<�g¸`^B?h¸Ç0Àûµ©¢ûOÛâD¥¿¸ÆŽAôÅöŸÐˆ"&üÒÙGZ‘úáMŠ÷1Ó.Ø›ÉÕ
+}É6¡©†þÇÈE…<ÊP&öÌ>sDõbÛ_ÇÜÛWp	vµe�>‡ÿö²fßé(!‡°~i0bkzì¾ÕIä­ÖÙ²¥©@ œæ‰R&ï…Ãi$|i ׶Î
³�ùòR¥ñ-f	—ºŸæžæœby,I꾟pXðØ©»›¦Æ)bF°¡K·b¬H‰ÌçubØ<A¨õ¨Y*ÓIÄ�w7y	èÃokSI‡&úÆΤ Kʱ¯¨/ÞQ�wŽŸž±“&×í1™>JŽ%Yô¶y�X}<¹ƒùÂ3éîe›i0Û~4f$­z6n/¾˜z¤ðvÀÓx$×ÂìÀˆæÑnmeõaàtçTŠEð­*>÷ËMÉCJÁ0Ýg¿WæWk¡
0[(ÃL�(”ÂÁÒ/;í�:1JÛÙÞ¯£ùþŽŠ's
+†‚˜!Y5ª¬h›Âø
+’9„©²Íºi=ÿ¨nuþò©­'h¾N«˜4Õ 
7<±–¹ûIíÓö†�÷Õ=Î)iÇN{À$dQñãTË0¿‡h¹KÝçµÙÚÒ9äó
ÌèÍï@¢ËG¢�$éðfKvHÀÑ:ÓÝ&îûAoà `žŽ“DGO?Ìd¨ö3ìŒÂ̪i¢ì'Y"-°ö-¸™¸O-õÂ5¾4¡Ã­š6rMŸ4Éì’‰üË¢¸U9F4Ò±SÑU-ÚÆ
+¡à£"Ð,‘gÏKîD~^ººÓÜÉ/Zn\Æ$ÿM­Œù–1ÄŒ)Á×�BoÅ�£E[âcQóh¨X*úêÊÒO>0”�ëw+ÇœðaÚ¨F~¶zñyþþ{‡gS(êá9‡&IdÑX2)Fžb¡8ÚËp¤‹PX,Gæ(xõš2œS`º	faj�e‰ªh.,w¤á«7
+cLÇý2 Ža®
+L­ysŽ<q›é;u	%ý¡xCߤi67k]|Õ•ðÓ�*‰I
+Ñœ±îÙª
Zˆ¼¿›7Ã_ÆvN¹—Ks6Ù\£÷ˆ[�wåÝ4
+ÒÝzI6…®uê+¤S9ü$±ì
+³î^x½«nŸN)ýŠ‚Ÿƒ.Îq:¢:+ùá�Ž{ÎúsX~²‚e–yÚÊYTº¾ws!k�œ(IÛÌÀB(ëÊ#’ØMëü««}d˜D2è9 ‰‹â—'Ì¡ø´ïƒšÛE’,6bOöO;fôu-~_Çx�ð¿7¾ØÄ(Òñ÷í/Ú݈9?’WÛïµÈßFgùè`æ}ô}4*¦
+…3©	¤ô1.aõÂ’ AÜÿJ&ªƒ0E|R*�ü(ô¯[\eZ¢¬ ÏÑZõçú½á¸sÅ%¶_,sEjìœÌ.�®Ü¨llüqÒé;¼ô½ë|i*VÖŸ
+¸Kþ­Óp’¹«³>ú±ägWüD³É÷?æKåÖ�ôm#|žZ¡£¢Ieí"b0G`½t¢n¢J¯q¨ÜÜPé¢G08mÜ8Ùªç µÝ¯Ýã¤ßRf§2e±;$D/Æ&.m�È—(Ân¹\çU"S#�Ð!=7±æ
+’Š±à÷+ÐáËú­qJ®lHsIw¹eòªzDëÞªÔ• NÚšO%ÒçÕñr‰�½¯=W¸Ë„TF%��:uÀ䀙2º,~u‘\ıáýú”�oC}xù‘Žq"4{‰
+@ûÅ#\t£¼ó�¿º™/K®Ÿ±UgR¯H€d~È
+a«Ç|…Á|e¿g½¯
}ð”uT©ûa3s+³Ì¥•¿½ã1KÇ×1¼tþ~¸O`Ë’tyQ[ýÈ—M!›ªo®J¿¦½Á'‚K›ð⊿Sî|
ÿ˜û\W�Aƒ#‰Å9Žê2]2Z³lp‰Fûû–†ÜûO¯†O
&¤ ÜDpªV¦8ï…ñ™÷óìº
è™zgØùÝg¢‚5¹’-É}P«�†öž/£y+
¢rC*î‹#&ï]:x"v˜rNµ4¥‹|ÓWíJû`føZ1mü-msFYîÐ:8[Ž–?[¯+v~ôðá²›	ó&pÀs–K‘v£y¨¤}�Üšÿˆ÷[â01%¸.cœY‰]j�˜ª:Ç¿ùö:Qqæ!åµ¾©ÏÁÈégƒ¡¾{£6jÊÑõ({ö;¯`ôô«î½A$äÆä¥=ÿ7<‰†ÐZLLSXëFŠ}Db62×,èÿv;=›#˜‡Ãc�(íˆFrEƒÎUA7Á¾ºñ°¤‘ïμ	Ÿ³ËØ
0
+·‘—Vh/†¸MƒD:•ÄÇNñü°†•:#Þþ>PLÇÒwïÿQ5GbÄñ
Òû¦ªð@`	Ìz(iVþÉOëµ6‘
+³ãÆY§uïèœÙ+�èï°9¤- ˆíRUöMxöOþúíú¡ÅsC¨3‚Džú›„àyEà·£¸q›—Rôd}ŽO±æé[ÞÄ™G`c·§;[�‰^L–çÎ(Ön^v轈î½—’‚IA?‡�Zdߦx¶ë‡0Þê5/„·ï0iñUE°—,¿"7ZE�"Y÷­à ŒçÂëáÂBG¾8˜¯§�µ#êÂ^	êa¹bÙø´­b÷VîæלuHmzæî	
+P�̪è¥Ôqõ D·Š@ÞDzˆ‹òuçöÿäüfN?ag>-šŒÊM©a7šµjª)Ð¥0c1å˜Åêž&¶Á0®ï¸‚«n9¯ÀMæW )õêP&°C˜Ù‹÷¥J@eôOqðȾÿçx˜¡ù3ÜÏú\åušà$å·=„þ’»:0¥äí
¬	{]Û7°PPÎþm1ˆ’=pËvÑ18Zµ±ˆ
ÀºrG»%±6.«ßÌ¢8Î8П«woZKÉ9'çêí#úG—ïj²X+§ÃšP8†»Œݸ¼0J…®D“-ýf¸=_U0óA­ú¤‰Lÿé-àK�‘ú¥Ïã&zŽ^Lqêm²ù›_º´~æ9ö$ |òÔ«*9k+ôûÒ—eL€<•Ëu¼É]ý	v¨Œº�_rœ!¬ß§Ìèèn"X[,#ѬR;Ry\³¥»VXÀƒ±AA+w
+©õŠÊ»üyž+¾û™%’I†2£mÞá­¥\÷¤uçó:µš¥WbÕ‘¹éˆ×h'¢I��µCŒºÛ 
+JÎtŒa½µ~öB¿çn
8b¦”W»VŽn$èÍñ�)4Üê¤÷VûËÌ�Œ;µ•èN ‰R£ËÐŪ§ýÿ×>Y¶5
(QD‰!%ÝH�îfà¨Ñ9º‘n	i’"]Ò-Ý1ºK�Ýݵ÷þ‡÷Û}îù
çÃyžã•�”4|œ"ïñ`Ûý]_€ßÿ¼�ݲí\£$«:ê¯{¶F†Æ»lìÏ3¢?ÑL$G@Öóå×vmôãŠ#Žª×°tή4ËFIñê\é±¹†òã–ÊcLÏBÙðn¶²e™i¤ÿs;<¶ ¼ÿñÏ7JŸ�¨ie/þ5÷“FàEZUuç!í¯îðœJMþ•³ŽôÓ�	}Ëß–~¸
+Âòé€z{JE‰FªM Û„�u–æG0iž³ÍÀ†�^µYkúzþ'ôÍòH¬n“È([ÒKFR}ÿ^÷ôdk
+±5b�$ßì}Cd%#vﱓ*š°ßÉ
‘ú°»­¥8hñÀÜ_Œ»Ð7¥U½2f
+b›oÒm÷ãÅY…½jãnQŒ˜�fýÊm½­�ªm&*þ8”Èç1|ñ˜a¬~– F‘«•¢ûÎòXQ;(_ÆSI0ü+p˜ý&�á¸$BF
+ý1ì_v#ZâÍ,µgªìVØ
+*‹š@i‰úû¿ž8ëäCî3luRŽn£ÒsbX‰É ýÚ�Nã0Lb£?yrK—Søƒ=Õˆ�áÜá@Æ	žÀlþ
 ¦Ã<˜
'•AÅ87gñU˜
+Üxäø›Š•XGŠyº'üá9vµ,Õ½OÓ
à¬KÏýØIC`­”¿¸9Âò§é¸ˆßcZ”Âh.RÕŒI�8¬_$òfIKmÌXró–€àÇêŸ%Ŭg”ÆÂüˆßY'ºVR, ¨B~
ÐÔAQäϲ¯u£s¢€Ý_˜Œ\@øt-ò©Ÿ’>ö‡Q÷FÉÎUŽ«l$Ô.ËW(¦8*³Ÿ{>B7@-7쑘ôy™Ù7º!„³¶QèÌL}*Ÿ$‚WVÉÉ®š±Èñ×´//2ZA$¼�§¥ªb;>~T6EÕ<Õ¿¿Vj3ps[‡Ú[ë�#.JìñåY¯ª0ûì©'™„±ŸµQÖ8}Q¥ÞÒš½.H�Òý¤ñ‘õ$=¨â¯oñöaZ]‹#6ž/¿¦Ðô¹e¸ÞZ‹ÇM{ªh=Hp¿œ¦-Õôš£åežÂúz‚€ÛÆ«ì(Onû�÷söQY²æ‰Ï&¡I(Ja]�U›-fø´Û[ˆÿÞóݦ6vº%š.[Íá§KpyJÖˆàêh2nösjJ,©VŽ&EͯU¨•x�9øW+0éOžÜX‰3„\
+‚¾¡ÉzŒ:s[­+ž:[´‚r7À«_ó熈ÑFÂ2Õ:¨Ù�˜-Aè
+œÆâO­Œ,Eß�÷�;XM«âU†æüìeçÎ&¾¸cë2“.D£T�«h8&Ëe7nV"ÎCøpÁ¨Ö#}&_ot-ç2ÃæX�L¦ºŠ�ðï"’‚Áf&ѭ탔w¤éʼŽE9Ãê¶Y|t\dà=_©Ÿiµª¯9ÅÝU5½<}âoCʬe±É·mQJ_”�–õx-�ºDïä»3¦Ÿëï"‚_
+{8þF�ÑÇæ–éì	é–sE�cø ôc/
¥Xne­£ß	Ip’XÌ,X§x©o�ÞC§C7}yñ8㟑KÓ•F<Ø—¶cÚùc§>É÷"ÊåæÔYxVì#³í³9y«bTjýé‰NÜáù„…ª�jŽ\«WÍX!Ì[Ê뺧b'ÞŒÆ)<$1ôÊÚ[,à§	ƒ@ŽWÃc3/—°WnY"¬Æ4áé[_Šüå–#xÎöf3I�¹[V¦;ñ²è2f’a_ÏãX;q)ö�&Öö4FØ…È÷Ÿ
+=X¤9�ƒ:Ø•ñÒ
+†*Nñ(ßc“À“
+ÎQÓp/6è~�
+ê™ã2ú»‚îY$óµÉ•­ßª2^IÑPYm3ïÜÚ×Juý¼=ÕùÌ~9Äÿ	2©”pmPkDÉ�	Ç¥)DcX¨Ù콘ûk*+ÇMCÆ{Ù´~­Íµ)²è5�¿¯ÅL|yÿ1ª5u‡Êë�ñ÷Òc9„ÍrU¶óBDøò3TyÈ嘙	SzH1ß+`Îð¶+§`½°W5Ó㎎²ÁÑÃiÁ™,÷ò}cýö3!§ïÒƒŒ‘PuaÛ›”Ë tòÍ|T\ÅL,p�ÈBHðì9çÑô)8H-ú�äjj*ê=êOŽ
+Œ†<\a/r¼ˆvÈxµfíÉCvP€ÕóuóföÈy§Åm4ÍÛÆajùlW¤JÕ4pñû
Z¢Aÿ6Ñ®–B�][¢µš×´B©®¦Ö
+å�UÔwUMõ»gÕ"&
+C•Á&ûA×"4ÂÌ]iÅÎ|,›ž(mÍ…pêÖ.‰ý³oRŽÕ]¸kŽ¬¢PÖ¡ZÛZŒŽT2Ê©‚pC¯–dô.Rn®f™7£žØær
ðk®–-!OõŽž1t¿9~‚ó–�‰æ·q¼mxYæó”9gK’}ÃÜÕè×å HéÏAf™\pCÊˬM‚._óBâÚjq
À¶]qL÷‡Âa¯¡n—ˆ›´¢('â¥&Cv­pñf–¿�‡OFÙ2ö
+# ð:øF(‰¥YäsäLèÆùxÂJßÓ%ÌgæÂîˆñe:‡¯#0®ÿëÊ»3¯‡óíLM¤\“wŒgßRkHäŽÅ_KØwÓªÂìni–ŠØ±
¨wŠlNþjsßÑ8v<o¸ÞâÖ²ãU8^ë|Wš�
+ÆúÁÿ%ž†ëÿ	öÿÿsK¨«»³#ÔÕûÿ
+endobj
+885 0 obj <<
+/Type /Font
+/Subtype /Type1
+/Encoding 2092 0 R
+/FirstChar 2
+/LastChar 151
+/Widths 2103 0 R
+/BaseFont /NHNDXP+URWPalladioL-Ital
+/FontDescriptor 883 0 R
+>> endobj
+883 0 obj <<
+/Ascent 722
+/CapHeight 693
+/Descent -261
+/FontName /NHNDXP+URWPalladioL-Ital
+/ItalicAngle -9.5
+/StemV 78
+/XHeight 482
+/FontBBox [-170 -305 1010 941]
+/Flags 4
+/CharSet (/fi/fl/parenleft/parenright/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/A/B/C/D/E/F/G/H/I/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/a/b/c/d/e/f/g/h/i/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/emdash)
+/FontFile 884 0 R
+>> endobj
+2103 0 obj
+[528 545 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 333 333 0 0 250 333 250 296 500 500 500 500 500 500 500 500 500 500 250 0 0 0 0 0 0 722 611 667 778 611 556 722 778 333 0 667 556 944 778 778 611 778 667 556 611 778 722 944 722 667 667 0 0 0 0 0 0 444 463 407 500 389 278 500 500 278 0 444 278 778 556 444 500 463 389 389 333 556 500 722 500 500 444 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1000 ]
+endobj
+790 0 obj <<
 /Length1 1630
 /Length2 15892
 /Length3 532
@@ -9256,7 +10157,7 @@ stream
 xÚ¬¹cx¥]³-Ûv¯ØfǶm¯$+6:ìض“Žm;éØè°culãëç}ÏÞû\ûœ_çÛ¿Ö=kT�ªY£æ¼îûZ”¤ÊjŒ"æ¦@I{WFV&^€†ª–²‰­­‰9ÈAžQÕÁÎð×̉@I)æ4q9Ø‹›¸y
Z@s€8ÐÀÆ`ýúõ+%@ÌÁÑËdiå
  ùËAKOÏð_–\
 ø›UY\òßuºZ™¸þ“Ûô8Xüõ4w0sûgKÿÂþÒüE]M@ö.
-`abû·Wÿ²kØ›�mAöÀ¿šþ«�
+`abû·Wÿ²kØ›�mAöÀ¿šþ«�
 ™**À)—PHW£B¢ªU³m·W�ÛÔOrí]VÉ• $«ùqyĤ"õÂzŒf<0ëûë£Îðf}/Ÿí¤>bêFè,VØUd‹ÕƒæÔJlNÍo’©+¬O�XÏ1Ï-¼§c-NÂ1ipÝ›í\AÖ
 úêì`uvdé,RHžê$žkK‚>&Y	¤ºÛ”OØ&â„o™kâÆœm§Ù WëÙÉ
 ¨œ/û«Ð[BÒó´`Ûtä¯äÍN¿GfáĈHªýmVéDÇÏ“Ÿ�”Ä÷¦Y_kÉóÍ+èü1pÇÒ¨å�Á³ñÂjD•jÊ
@@ -9318,207 +10219,215 @@ MIª\ÂuTØjGI-gý�ÂÓ–GâydføæÅxÃÃ,�oÛ.رÌ*�_ùSÕúƒóØCkëÚ™­¨·>]ÙrÿÅ:K¥ÓS%œx
 ¿n$rÝ	Xð�D˜t
ÎõÓ…”2§—n„sÞmOÆ„
 ˆ;²ÃßshuåU9ñÖ�&;y-sõP~K*ªÅz4rnp´�}ª÷œõ)RB—+«å—>¢cI£Ž¹w×	éhz€Ì\mm £MúHþ×<×|Ìï­&‰� Ÿw³s£Üë+\?VË´<=yò‹ØH»M'²ñÑ67Cøoí+A5x5
½·x¯'_Ë
 c!vÜ~óÓ4¶bIpµP]ãH^ŒúÀnkLßYßÙ„æÀ,•‰)tCœrÀ‘Çi†Ï±m$�hýÈn.ÿ¶»öO¿ªWÂ[–{OFChÓ'ž
WùÆ*6L‡1±’g^H]u Ââa3ð¸g@—TÕL_1@d7¾ùÁ“†µ�‹Œ:…‘XF.ÿ§�Òfb1\ÄñSÙ£�Ö®TÁIS ÒŽã{9.´ v´ôPš_$ƒºÃ™.T€Áj”¤RÚ.z�àÂiXÎ^;-”ûkwå0HMKyÃûSc-‘tkâôk'a.*bí	Û¶4ŠdÇ&ž*qÉŸX‡ÒÝÓä"c°4	*+9‚3£
 cáE¢Lg%ãŸïÁó§KíÚï©=ëg‡~Q)œu‘Še7@ô`­¥¡c˜„s2¬ìe/ï´Ã÷
5ØI*·[ÔrH�îD4;"«hntRÉ´c¬¥ŸýÝ„u å{ÿÁØ}hë 
…
-¯41¶{ºQµÚâl·Pãg;‹($@
QQ~:ú4¥ /麞e„¼æª't“Ê>~œÍÆTÂ={š÷ÈcW
ä­ë6Å͆ÇIjË‚¶{Al ¸¸
²œísè¹”Lª £ÈàýÞùqœöÇ=*Y€þK
+¯41¶{ºQµÚâl·Pãg;‹($@
QQ~:ú4¥ /麞e„¼æª't“Ê>~œÍÆTÂ={š÷ÈcW
ä­ë6Å͆ÇIjË‚¶{Al ¸¸
²œísè¹”Lª £ÈàýÞùqœöÇ=*Y€þK
 endobj
-747 0 obj <<
+791 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 1930 0 R
+/Encoding 2092 0 R
 /FirstChar 40
 /LastChar 90
-/Widths 1941 0 R
-/BaseFont /VXUVES+URWPalladioL-Roma-Slant_167
-/FontDescriptor 745 0 R
+/Widths 2104 0 R
+/BaseFont /VZSVYR+URWPalladioL-Roma-Slant_167
+/FontDescriptor 789 0 R
 >> endobj
-745 0 obj <<
+789 0 obj <<
 /Ascent 715
 /CapHeight 680
 /Descent -282
-/FontName /VXUVES+URWPalladioL-Roma-Slant_167
+/FontName /VZSVYR+URWPalladioL-Roma-Slant_167
 /ItalicAngle -9
 /StemV 84
 /XHeight 469
 /FontBBox [-166 -283 1021 943]
 /Flags 4
 /CharSet (/parenleft/parenright/hyphen/period/zero/one/two/three/four/five/six/seven/eight/nine/A/B/C/D/E/F/G/H/I/K/L/M/N/O/P/Q/R/S/T/U/V/X/Y/Z)
-/FontFile 746 0 R
+/FontFile 790 0 R
 >> endobj
-1941 0 obj
+2104 0 obj
 [333 333 0 0 0 333 250 0 500 500 500 500 500 500 500 500 500 500 0 0 0 0 0 0 0 778 611 709 774 611 556 763 832 337 0 726 611 946 831 786 604 786 668 525 613 778 722 0 667 667 667 ]
 endobj
-684 0 obj <<
+728 0 obj <<
 /Length1 862
 /Length2 1251
 /Length3 532
-/Length 1861      
+/Length 1860      
 /Filter /FlateDecode
 >>
 stream
 xÚíUkTgnõJÀ+Å€€¸
-æ2�@	Š&X4-."(R’		$˜$ \(PÁ Bå"Pi¥´^€ÊÅ`EÁS#BAn¬\uÝ
ôØ¥?wíÙ™?ó>Ïó½ß3Ïû�óY˜yúè$vEDHi€‹»Ï~�€D2ÎÂÂ…!	í‚$0

-àÀ\ÉÁö‚1'ÿ
SË›»JH¸Ð~1¥¿ð��/ˆz£@„áR	ŒîFEË¥~ð’9w˜Ã—
-—³L	$à³é¢
@;"Ù–ºDðÅ®|ÌñäKØ<€	Äð"‹8Ë­`ñ-!íbyøîñ±y3×EÒâ‹${£Âa€üN½Xƒïj,%”/ÈD2Ä„Øûö+pÙfŸ‰Ø‡/
-
(T{
-‡� ¬¢1 Àq`
-T©)s‘›ò¯5”ïØ—Ëlòi~àpdÝLãË$+õ7™•žæ+M‹zç‹+
-endobj
-685 0 obj <<
+æ2��%X4-wDP¤2$H20I0@¹,P ‚A…ÊE ÒJi½
+& X¹ê
+ºè±KîþÚ³3æ}žç{¿gž÷;ç33ñð&8²‘ ØŠ	 ¤N®ÞA2
+WJ}áes®0›'¬d™bˆÏc9
+ƒù0@
+Dƒ
+Z$eñaÖâÔÄ‹ì2AHAXæðŸ 2ÃPˆóaΟaë7ðòÐßᶡï
+ÿ®~çœ>#†øEõ©ƒOKëåÚÝõz î®»½N™/
+µÜ:4Ò(®’+³²Zîñ1~xܦ£ûöÞÒ‡ñ‚÷t¾ýÊ3 —á9¿ÒÈh<v-Œ¢e*뢙yà%suùZQ‰Å&QÉÅø±DzÿQ°êFgx_5žq8'–9ÉLÓË
¾š
+!üm94¡�ÜÜ—=7âjp¢ŒûLé^g_]flB쵧%õ„DàPYR»rÍü
ëÀÎCûîSŒÃ㲎„�™xh躗Ë.Ûk'$Ô\—-”…ÌîЉМV*¦…­FÔ�=2À5½[wì™üPûR�×ÈÉ?ª)–’Öokö³ïOWûlz�yàYC?÷£ÐèÎú©_†çÍVS¹Ëúä—pïç7J¿üñ·¡ÒÉðõùWoʯʉ΄։Öþ›E¶TÅÑ“Êk•×Ç$
7ìÍe$å-ŠOÂé,¶ižï…ÔË*‹GUM�=uó)�ƒ¢…0订êcú<Êyê<^a?YYêOÿÔ{߯qT1ç„ãó_N’^'v?רk••ù2ªR¦¦K´Z_oõÈjrÔ“ÍYY2(Õk$ûš	@šÝî~Ã{8sç—Úµ¬÷U$FÛéx7:á,?ÔyòÓ�æݯ¸ùO�iD§È‡‹øÄuþ÷T«TêSFaô{ò€Š1b]aÚù_Ýv*S’ç#¶ä]k¬Øu �ÙìÝò€vlÃlÓËDÕ7™U¦«�‹ûJ*
ƶábuÁÀ$ñö²
×p}Â(�5ñiQBCG¸ÇÀ\—$§!7!ÇM~9Šœù¸)ökµÑ)Ç÷D_uo€£ŒÚjnÿ=Õáh׺™;wáÔúBÙ˜‹jU´fŸ�î�Nç²QÝÖ…Zöî–[£!CŽWµ$Aü6ÍŸd‡š@Â!ß¼tÍ›
‰ˆINzÀxwÁv}ÃuÙF{I¾?>¬iÿ˜ú`v«ç íøT6Ý1¿é0S x}Î䇯£Ž¨Fü׆�þÜ×¢¯ª«;rª³+Ù7ÖÅt®]šrZ9µqg{7áø®l÷GÌ}Ÿ3\NkôÏɵV'•Ç²;Bêmиƒ’ž˜l/�^·`m`onç=òøàþßà¢
vuC¨@h(î_<þuendstream
+endobj
+729 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 1942 0 R
+/Encoding 2105 0 R
 /FirstChar 13
 /LastChar 110
-/Widths 1943 0 R
-/BaseFont /DONUHS+CMSY10
-/FontDescriptor 683 0 R
+/Widths 2106 0 R
+/BaseFont /CWTQLU+CMSY10
+/FontDescriptor 727 0 R
 >> endobj
-683 0 obj <<
+727 0 obj <<
 /Ascent 750
 /CapHeight 683
 /Descent -194
-/FontName /DONUHS+CMSY10
+/FontName /CWTQLU+CMSY10
 /ItalicAngle -14.035
 /StemV 85
 /XHeight 431
 /FontBBox [-29 -960 1116 775]
 /Flags 4
 /CharSet (/circlecopyrt/bullet/braceleft/braceright/bar/backslash)
-/FontFile 684 0 R
+/FontFile 728 0 R
 >> endobj
-1943 0 obj
+2106 0 obj
 [1000 0 500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 500 500 0 0 278 0 0 0 500 ]
 endobj
-1942 0 obj <<
+2105 0 obj <<
 /Type /Encoding
 /Differences [ 0 /.notdef 13/circlecopyrt 14/.notdef 15/bullet 16/.notdef 102/braceleft/braceright 104/.notdef 106/bar 107/.notdef 110/backslash 111/.notdef]
 >> endobj
-681 0 obj <<
+725 0 obj <<
 /Length1 1616
-/Length2 25291
+/Length2 25334
 /Length3 532
-/Length 26183     
-/Filter /FlateDecode
->>
-stream
-xÚ¬ºc”¤]°%\]èª.uÙȲmÛ¶]YV—mÛ¶mtÙ¶ºlÛÖ×ï{çÎ�ug~Í7?r­çDÄÙ±#ö9±Ö“™$òJ4ƶ†@Q[GZzN€Š¢š¼�••�±¹­4�¢­µ
௙š„DÈhàhnk#làä¨
�
Â@#
-
Ó¿rÐÓÒÿ‡ÑÜAÔÜh,oîhd01°úÛ§í*6Æ@{+sà_=ÿm%€†�žþ¿ù”ÍÌ�,mþi<˸€6Æÿ�û_‰þeN'«"%$«Fõ¿ÏÔãäÿjï¨ìf÷—Úÿ(EÆÖø.þA´uxÐ0°²hÙ™þ^9F
-4‚^ùckÄh‘š‘æX‹ž34!¬Õ×Ã
-¥$T³ØÄ^×âs:‰¿�„³Ó�t»©È i+3«0�€Ö~Z¦Ò‹Áº*ã¹®.òzbdÄhn“<£c¿§¯
-ë³ü>Ëä1os´˜™(ÏÂß_�Ø⟣
-Üiv^ëå‚áßcHdð8�âzî‡ù&v'ö@¹v
-Ý}�ÈâJK3�î„ÕžÖõlµüÁçÓDÓRfd‚ICÖFJ$GKó¾¯D˜ü‘·vŽ+À$kPSöc«¶U|R·Æ
‹‡hX'œQýSÁàØœ¸5£
-•LŒ{Œ›h1X+ðaÃ1©GÌ$“ñ¥l&HÝoÿÃ5Ÿ©qΧ©uAÑÇÁÛ9+�.ÅÌAK¯lrD‡2||ÀÞ�W™òqoÅU{´@ÎÜ^ËÜq�øHΧ6U½SN0}� ì Šz,sE¬˜¶a;<Z�t$N}Dzë³õPô:–šÕú.� Nž³¤Ftȥ͜hR=l>eŽE/Í:P–ÒÝH“OïQ\ÉŒm–Õ›ÝèIY湪
F'}P¡Éô”ÆiR¤ÞÑî	•¼Æ-D1dšMZa·ø»ooÄPe0™ù{à3X|ªÕ(Æ5rcˆí“ªCch³Áó€n']íõ%®$Á÷pÙC$äg´ž/qº–Q„¬{kÐÝy¡	»ä(örïZÔ”*"ILÎÑŒè¹ÐbG. /“!C¡U†�RmÊfB,@�²¼NïÊ;�ÉE–•@’O}64jÂ(æcŠ
-M
J9‚®»˜=¾EMì¥Ç§SëøüªæÊgg� æ·g˜èô\ %#B9%´®©b]cA=Ô
-‹“Û,o2ˆC½³Ò=ÙÖk•/ØØK‘ÕœƒjŸQªÊ„·¨Ãy
-@†Ä¿ØÜôH¢ì’×Z²øPAçGÆKX•©Èë7ÿŒQŒ±f´ý1ÜF-Ùw|¤$»\ÃD¿�‰x¼�	�È€Ñ"õ†t?oånŒFÖÙ»s¤‡V@•RÈ2Sx	�p]½ùö]¼¦ÊCRë
".zî¼å§ð©PGŠŠÔƒ H>öé%WÀD|rÀ©ñËE`…zôGfìí¢t•„9—šÏ¶3Í7„ ir6s¼ŸÏ‹¼Á†(»µ›œM•_Ï^–8%ÃÒÌh<TÏø<G‰& žÕsŠŒ�ï}x4ž"Ø`ñ ã?�70„029t3™aŒh ~Áع‹&ì*ÇcGí\¤Šn
<_‰HB÷nV ^?z^
6~pÈ“!Tþ(Q4Î×"‹>§Üs:�	žlwÇjèQ›–óž…-á’æØŽ¬£öI:(i>
·QÄJé|]ˆgZC—º’¢0'¡Üœó7Á¿�†pyfãÎCûâtˆí&ž?¨Ó[åÏè˜�šç>÷bE‰ÌiòK)¿Oµ…µËÃmžÒÃúÔˆÒÒ³ü}'ð–�ixiªûÂcá‰|^"íÆÅ�>p&Äñ�âüGÚ:[>´ŠX>µlºZ‹ÿZ9Ð[:ž}€Àe�‡Fk;èpO©¿=–�õySɱ¤T‰‚í)Üs<ZvkHJÉ=žEFék
Ê[} ´ÇHeˆ"y0OÍÁJzÍ
4M¬˜×Ír|L_hàüKå[ÃÔéê…ë˜Ùc™ØSF¶Ñ�ò]ö™c(Î=©à=�ñÁîEù©y†øÏ$¸«]K¶ç…­ðšµ¯Ô>m%¾äËï¨OZ¥8!'Ú7�6
ÅuþöÍqCS)	(Ág-˜¾"Ÿmå:�ºWV¶õÇ/ã|ÅÂY¿,F}ØÛu/Ÿˤ°�¨570]ç4�eCØ¢Yøí–²	ó—Z
-JëØ
-{Œ¥�«KqHM+~ÏBO¨Ÿ?oiµxÍ+«7g7[*‰F]4HxD½I·È-÷€ðÚѦîº-v€á*hûT°ž½ g$+ªíá?t�"+<äµ +zÒ´ÊßÇKÙ’«fÍ¡Ù”ø…È^fx—wÝ¡×Ú‘Q!·úwxm$,
ãûùyïìC8@„S+®dtóWÚ³æѶ9ÊN-*h³ÞºE¨‹@­åðòuAIÒØždé°&#t›ÿ	xªÅæQ§„
ó
-9µÝ.Ý
0{Z[Cdiî×É!âOø^)kUIÑh�ä�ëºCiµá{¾ç&KÚéçýoû›ÆîZ—‰ÜËlÓîÔù—6lÂKR:¶;y>ñuju¶�	M¯²á3Ú©*cð!¼cpäï ½¿§$+7æ,ÌŸ; o&ÁÈb�ÓZlÑ~ËwÔ»¤¶”Y¶ˆ~ÂÞÉ)X‡[u­çÌSX‰&©ìÈ-D rÄ-‘7Œ¿îV5Û—nþÙÓž­ÍÔÞš£÷âËì›tŽƒ‚õGQbE�ˆD�>¤*꯴Â[@ÁÖ5Ƥö*>›�9%§úýDHÔy	µff3@h?L;¬îFÂ�ð¡Íϸ/;*s ˆ¯cOåU®BÚ½/âAñ�.k�þÚ	sHFC®Ü¨¬J½¯1þFn^×áöƒ¿¢
WW�)ËNV¹ŸQO‘Âömœi}Ü8åÑñ¶;áî=Ÿ8;2{¶†^ÜóJE9£n(tòx~�˜Jþká)5þ–ÞBʨnŽ8Ʋ>>•m‹jS#®YR«—Í´…Á­‰�Ù\ñGkï¬1_d:mN;ªž‚˜"a’žq€‹©°Ê?ÌÐÄ#ìÕãÙ{½=#Ç™‰¢Òò�¢äè{¶Êl¯=¨çPÒDZÒ‹Ýlļ÷Ù-:ñeD8å=ü*$YTÔO½xÑÜúÜ]µ©ÑÚˆ”I5�ãþ±×©_)ºNÈ3¨6«äµõ«‰Nó"äD1¬ù „®ê0ö°7®<4ö(Ìuæ´SˆQÁ“pR/Á®E©`SŒ^ôÈÅÙ@D‚±ñ–§æxÌä}ú”:»º¶¥uÒpp—§QÿКÓ
-ÒÎ&rs¿:Ÿ°ôåÌ�ÄÜÏV
èy.<Ó!f•ÛËiQØg:0ÖáéãÍs_E©3dΑ¹Ÿ:A=Ë�×8‹´dÍAƒʽïêÛRØ-À×SÄÂ'ãBØ\eá~›"›ÙRrD|©}Ýÿd¯qyIÇð1ó6§µ(‹‚hQCÀÛ#÷œ—é[6ED€ó‹%±˜úÍ<ZL9ÉAÒê“sõ“7\wêm’’¹Ù·—¬˜9ðwב0Êpø¢Ày&NߧBm4D”SD"«4*Èwît�£&ˆÞWÄŠWÈžèHÌËKv3†;a�4¥QoÚ®ÓA.óÎ`L›&<v×2•M\ü;C‰ï!Uê›^e_Å Ú*Ù³ä�_ª¤Ø¶�•ð
-¢á`7
z´|„yð•Ý™íýî�kn:ð˜|—
ý
-ã;[Ȳœ]P¿“ؤ¸›äNßñÕ§Ü
ÿH¬Ù|.´=hÄÎdr †E#†UP�QE^}ÿv€ê¡þ˜(#û¢2ôVÌìôü“£
βÄÏcH®çy³>•q‘óýÁµÚi¦týL6OcG!,çj§eD
­=G83˜ø®eÁ鯑´^4ÒršXýŽ2Nä@È“mï†óD¼ <ÔýÙíŠÎ±6øpv\èÚž”%¦3+è¢W,K…�êÙœçEÛhÃï`vÐyù'5‰$ع$rñ‹’ŸÅ[
-Ý(~®$"·jJZ«ö0V;XÁÖ9àL[ö÷ŽÃ=ú\µ$ÔeKE²¦ë•*VÃ%TÚÓì—£ácÒ㢎¯ô­
�1 6`hÒÀ7>œm¸>/ÿge–‰—�sªè²àÔ2Vú¤yîpwí¡úÜkÆƱg¬¯Ð·ˆ½P…ÊÔÆöÐGWð%!ŽlsŒÒe��£•;‹8Ù1Ëk²àÚ>Ø?Fõ$é;wͺn­æœÌ�^Ü”/˜÷RºñTš„ŽzÇWÒU~WW›G0a–
@8§OQvˆk?UJ_xJ”³&ûˆ#p�;'+ÍUv˜á#9¾}¶Qý•þÇ%ë<"w9>O“d°FT´pü;í�&w°nð-gùo…�ÁŸÒ3íâDã»­;ÖC+Ò¸ïÅf@Ô
-Æ°
-á[xœŒ†÷\KQ}Þ£{ânUÃ{¨ƒÁÅð(¸ixJ
-/ÀÅÜÍôx¢Pt|‚£»ŽPûβJÿ´ÌΧ•Í[…†%®§íßW´¦ú‡Ñá´L±ŒZLys)5œb[vb§�¦ÖKÃB¬ÐüŽÛ|Å2Þ>‚µ¡XÉK©o[rHÔ\ñíq˜²?

�ßyæùíoædÏfN/ÊÎMB-£ÁPˆ,÷#”|¬7a•´“YE8n¤
Hõ¥ ¨ùIHÿD}ž†‘#×Àä:>ƒŒlØ)_Æ1}NšLŠýö]ùNp’›±=’“j	†/Gîr¶Ò£1,Â;c|�6Ž4Õ‘a	'ýq*v¥Ú³§ '|iú‚â®ìL5³ÇI"wè{À,•|XÐì¯/û(3Âö-4Ø—•0dT@N&‚†E|ð4þç.ùiÛÑœÈ1àü[Ò	pJÓT
†šžs;ícñU\�ÂKÁ/m¨@‘§M=ò]“’Jí‚%ë_JXñÒ¹Žìhuó{¨øy¬–z­¼ÍAWô{iaz¢˜š–mŽÜ󺳘;¨2¨/ˆþ/»ÄcÆѶˆäó?™Nû¸°Ü F`® ^å±Z§ô�v»ÜÃR�4êI¯d¸'|ß|ºÐzëÔ%†=-ÉjÅÐÕï¡ó-‡Õ´;ÌXåpMž8Ìæ-�<
-QPÓ-áê“&eÃÜÓªŠ^"q\SVÁkøD÷>©Ìp8ð=·[5<‚K‹	“óç/=¨^ï{"~jhõ^Z	×
-TSõ÷Ò‘òÍ?¡n¢‡	Ì�>bO³3ÙØÈ#wÈVßÊ[½6´Éû‰V˜5xy`ï’ÙFC±èëŠY &�³»ïÙXºÜR>Ñí.Žù’Bpe­Œ ¹Ž•®¶ºÁ¼�ž¾ÖM‡çÃ{‰(Lv¹%Û<ÃDì¼Ù ÑÄ@^m„ï�}
(}屩 A?N'´89�}�¡ãÕ°àahg›ò…NyF=Ø,¨E$ª=ˆ
-‡?wÔ]™{†]°á³Í4jÕâŠ”P)ssW;RëË„‘#•m“>®~F�í&û[¾
-�Êçx™>]ù‘³±”íìÕÄõ3OSF}óÞ�n+QýíPR»Š¦½Ý5­¨VÅÅ ç„þªeh—‡�ÇŠû�Fe]mÿ‚e¤e¤RÕƒÓI¤MQÈ›.·�—~#v‰XÇJ€Ë¦ïu»wgß´»Ù²
-^>íª$¡‚ªN³°jQtˆâ¡'§"»BKº-¯”¬ØfOUÎ51½D:e;…"YE­"^gŽLÖIÜ)Éæ#S|^o´¨/‘feý•á€•‰¶	4ê|¶%ýý
.–î´0¶&Û$LèÐÛýÏk¨MLèOöc«¨ðæ[›L3xÒZsýZ�”Óîd42)wàÐ!É5³ ­%aû+|ã=Ê�.ÜÓ¹3ÜÙ8Þ-	pˆh’•™ž^¿W¯ïEvÃhdBdwü¨øPy�>h†L r%@÷CøÆ#œ(|HD‰ñÝ ¾W6ÀG~ùç+¢m+ç®_#É€'[.ÕF­ öÔ9”f÷iõD
-ÇEE‹S9WM3×!ídòÔmAfoç�õÄmî¦Ð[Òd‘F$ØíRUJt·�äýÀ ÷
-0ê
-‚‚DqÓÚ»uJ‡$m¨Ëâ\5%�wËxƒ�ëá¤ÝŠc×Ãäçò‘ ¾¶Ï
·
-:âP ÉÜgú–ÁÏÛç-R^üÀ#¥w…÷n²Q1šû£ö2ü8
-ßU‰òãTç[Fèš�x],Z·Éðšsðð½Š+šž	ÈS&×9hÁôœp
4mYKØ…Ðl]ë³.)µ~g�RšŽ_•Ÿ(ºë÷˜te“c»¼x„Ÿ×ŽÆ¡â]ôî2xÂÂ4–ÙO®°¤ë梨áq.svÞ}µØüDváð -7—s‹fYn‘iÌŽR0Ö˜Áp§¡G~)!×R%e¼k/“‡£%A0Ê|&á8¬
ºàµo�Œ/t!„ÈÏ$»g¤—«â½Ú'x�Æý+ß=Fœ‘è¦y@õST~£Ì½´,Ò~”B”Ê¥¦µ�|ø2H‹%È_Øò'5Y�h
ÂE8i´ÞÅ ï…Ø)uô_ƒ¯	òÉ`XÇ˶b”ëÈó“Ëã$]TÖHõŒn0F’¯h-òðíìaÝ�ÛR�]ÐÉËæ½PÉ$¯	Ðêm<²ètL?Y=àGWr&`Ðñ°êà8Cº+Úš!xr(<:Ž¶Üº�±‚=6ûP.'…ºŸf
zh?9>^.~-죦ª îêê>.	ó¾_þAC鈮ëø:%cý6{L
™n&¾[™˜â¨†énC–rMÌÒ(	¿Zv›ptúˆ c2{d„q¡D|ýü¢ó䊇•©|„¦3Ì‹ÀŒ¶¹S(·’ÖÿÎV‰Ò‡CýîδÐCM*y]?œeàq1œ®=à¨Ì>xÞd?O-G¼®·²µñ¤ç¿�òºáåÞ¿ï¯ý _ŠS߃Ø#”ÍÝÈÞc³7—½û9˜X'!yf¿ÑìfÝ;ˆg3³Œ0¬`ÛemrG¨^²üzë ÓãÓÉ×e��I’ÚuÓV¨™Wk))5ü÷pÝ3`ÜŠŽâf~€)`â¸ÒÉê¦GñF¬&Ðœ�íçM�ÃD@«UJ¾k¶¦»Öê^ŠdÔ«©ÒmÞ~9OºðQ
†4Â>…£”ÈX>®è8#c
-ÿ^÷É
- ŽM·«*T$à&N_Òò,j5%
-œì_ØË\ŸŽdµíY|ï—ô(®iÙ˜ï÷_<{‚ßnSéÓ7T³®lpá/Å=[ü][Ë6S[ÑM�¹–3$`êMIuÀØR{,ÅWþ¤”µΖg-ÿqjòIý˜=ßôY÷idᜒÑtR˜)¸zéôªóe;ú�Ot+%«Àã†Ù²ÇÙWË7pž>\¦
ÅxÑÍŸ*L³bæüQÄ'QÛ\˜èõžx˜:S,Q@²úIyîÛIÿ�AË)i^í·’�ê#\>¡²ˆ×k¸ôpÀ/ðânoMe�™3²�ÌB¤ÿÆ]Ò§F¿"Ûà5~·±µÐÇVS´Öþ,&Tqx`•GYú®F/Í	â�å=TЉ�¦ê&Ô%³S¬À#¯]âëI–7•„
-öšû�DG¹_×
óæÕõôðªØtx˜†&ÍRueŠÖï:FŸ‚sy.!À\Ùs‡‡k¯EÁ€Ó•sö«x×CíÕ<©t¹KrgÆ/Y4Žö<KSUGYþúÌôJŠ>•V«‹§K¯€Kb1¸Ž†¤”,M1}}A­ÖW2Œ…á¤ÊùÛ8x¼3tã×Ã3Ï<º›©¼U³GüÖ†¤|D‘�‚ZÚD…ûú÷÷>Ìâ’¾ÃÁÊ:º�Ÿ
ømõA‘ÚõØ'º\ÝöH+Ì»tô¤H�¿€áÖN
ÛstàmœŽ'1LÞd˜Í8¿�Ê!©£l�Äö'`•,áO�›>ÖSÃâ<Ú…Ì¢î±D»Lôyº*mpÐœŸUžâ™Jš:‘¢`6Í؈÷+ÒÜ\ñ2¬aÃUÃ?wéöÛ<ÚÊë4'�ž’!lž¾T§brÖœ-1_/&âXcb®�ÓiÇD8ûæþŽu†åfmk7ÔõvüZ­ÏÅ¢ã|$bŒAnÕ·Íê…¸bQ&¢½ÁRîX[ÂÅѸ¶ ¿øE·Ë¬[oÙ¶žÚ[£Ê«ïÌw>w¦{3ÿD)¯Iÿ#Ó)°Ó'×J‡£ÀŒÏF™¡ã×ö£M÷ß4ÙËáZuT»Ø²n“€9DDt”¾ôb5Û1g8õ!2õ¬j<­è+Íy"
$¬ï¡1!‰ùœ«l_.‰‰´—k3q,7’•ˆ³F÷F¹¡ï_z=F¨ïœ:Gß¿q€*F 
yDÓ³–R�3¡ÞPaZ¥~CRœúsF]ñµ«†,
-áŠD(A~«ÌiðÔ–Eó—1+¥^¨„iyÖ¡dõgVs¥Ý_Çë t\û¥[Vƒ‹¢ ãŸž4Ž«EUwS¦€˜”Í�Æ�µßT÷Ün¯
°"@æs�÷‚Ù¡h B^#ÓÞ€Ý~aG&gta­LÉ	uò§p€ºf¦Î
-ë`H“@$ÕflÕ=nUúÕ5îÙù-�2?—+{žj•ð¡Òj�›W	b�>H°ÿØ…9ŠÌïh‹æv =f÷{fÕüVì:Ç1["rù”SêƒoÑõ¾Ç’€šlOÕ‘äÌ]ªãuƒ0êôXPðkµ»9Ð…Ø:ÿÖ‹\þ±Öãà–{áÍÜÒ#ú}B*Q½‘W¢¢´ž�…tZ…xœêÆ/*ÖV’^oá�?Z‘F
‰Ô�7”:ã
øcj¿?‰z�z1ÿÍ^yãývÍð¿\û0Æò±ŒÄ†]dqá=¤¿@‚Öº›3IoÝûÂ"Ãp™çMLò"–Îw»h=y|+Õ(¹2#g‰DÛkœþUhÉ«ýƒ�h+V2™¹,ÈÎ*MYcœ�´ð¬äOæ~‚ gï.ícfÛè�MM““!TêÕ6ƒ8 
.�ƒ)¡
éU¾ïmS‹"Œ§Ô°5”
L4ûöã¾:‘Oìc
³5hFWG8sË›æs-¡ëûç";÷\¬ã2•„ys8‹×ªlºP²XÎL|¹©‰ü4ÍÞ̯v9êNvsr‰…Â+xCü
>c¯Xç§Ë'��­}ֲ߱ß1TÝçu#ß2çÓ
-+¦É¿ìÚÖŠ^Ú®/\—sjÇOŒ¤+G4Õ–¬¨9
-,�Ù°U×g­·ù;ŸÐôl"•R’�uEc°VÁ2^ºBRA4MæÀQ‰ç‰¶·#ÂÊ€ó#Šh­5¾;•b‡§XæD””gX]åF¥"yM�…Y@ÅZ�éxaxÕ49ìÍ|ÑÞŒ>‹Šçââ�D’ü2¼C%4öÿ/ô»�ènÙt§ÄŠeýú2nš±t
=_
~ ¼}RÉ~>Ë »a0¬n.¿Î¥µ#M

HöíTiCÕNjŽØÃsûÖ‘ýaç_ÒÈ£�ÑxF‰“Ô
EG^Èn	Ý=†¨Œr&ª‡C0ŒwCÀ�“`>ÒUÜFæœØXîØ}6ø[·ìfÇ·fíŒz¼–ç‡ñVÉSçä‘¿Ôìi€ÐgoLúº¨6Ut�Y–S
ýS´,�ãþXppjIíWÀž8›‘ÊsÇÞwZ„EyB¦È˜Ê}°w9zÌ^Ù®(ÿ÷ô�ÈЩÛ<KäVÕø>Q/ÚÜ#ï×Ø·¢yû!«oø~Aòô­%“#¹ö÷ƒ¼BzÁ˜»ªŒï?_"’	ë‘Úë?w0
ºŠüvˆ_…¡"=%_U[Œˆ|ð<"á6ìZƒ UcèzA²¿¯5`¢\î~ê×Sù©å¡ïÕšPÄëŠó+™ë�
-1·ð€š2åªvÙz¥›Ž³AfW­æ›îs÷óK—i&ê¯Ózy¿ðƒþ#t°ZÚ)þƒÝ6Ö
-kÈä+>x‡ÅôŸåÞ„PÁ
EEo-B1ЦL¥ŠñãÝÖ›²Ö›ï{ƒÎûZq"Cöá±âši¨èbyÇû[&Èïd_†/
-ÁÑ™i-j´ã/¾fXØü€ßÙ(‡.V’+®¿
²
-½JTàÇÊcŒ†úJ$1³Ù«B«“HûS•°
î{ƒ)E˜ï@Ä|èÈö,›G|8fäUÜêg¾dÊÊSðõÀPÒ”¬^Ÿ¢õ±ûJ#„ÉòvÖœ¶2W¡ýâ­Vø~-…3RüzÌýÝ÷
-3Üdc
×›+°É'�©z8údÆÕù�ÛüÌ[Tòw@ÿŽ¦žÍ�…gM/Ù›ƒéFŽ]á,ˆø½Åžlx+d±‹
9²ðä~OêÌKC†«hMŒú%ÎvkøæþÒ(„¼MW{B%8T Ødaè
Ò…`[Ô¥�Ýy¬CCtt?èhîÑâðïä÷`ãß1>ëÕÙu•î$= ›gSg¸W‚Åw‚¾H�.Þ¬¬_ÕLz£x­÷þç…«ˆ9ú¼Q³:�²sðÖ9v®A%ý˲ùïß¡ãë’!CÒ¶è‰)YXP›Äî­é•1*A‹EöRSîŸùÆš¦ÿ8L?#ºOYI(¬c,F‡n¿ô¤@É«ïE6ÊPdw9^Öäv]
ô%cND·y§;£ÙP™äµQFaØ®›qF?Æh¿µÚëè-Å×›ÞË�#ôý<ë)%™<åàiÙFÏ
-{@[s0Ÿ"¥�²ŽÌdbÔǘ–´EVðMh^±i5q×B2¯^JO
^Ìê£oÜ'‹âØL¥ÆdýT<“ø­ê²fjí7Dµ•	1­X}2†7›€¤c½Bbá/?ãÒIxPp�%‡Œ©SíCÖ…“La2ì‹i½I[«E8Ššå
½¸çÌ Þ@Âî\ǸŸ29SQTw*ÑB1ï¼Ð�å+Uïh®¼Ä¡Ê/þ­‘Cå y[üAôŒŸ#2‰oLú*ÇÇUqQ½
-ó|,šZŠK§ -J˜UÀ·~SsÜ1Á¥Ã3ûtâ’”§ ¿�ømƒQDf"x~ˆîd÷ôM”pr�B!�4¥”N½Ëïb«@äÒë³q
§àάAÃêÕµh�Û„Œ°Ç³8vˆti¤E¥ÌU$ÕƒF#ãlˆè‹2Ž�55JÁÆû
-W—‰ÊGo#�Jܤ±ÐLê yNב]IïðÔfñ+ZMv‡ï7{ä¶Ãê‚øíXºžXäó�½Ý‹`*‹Ò‚
jpj÷´?+›
-|B@†-›&±í
ä5‰tkfÏ?B~½b:%Yñóà6uέ£þ˜”£LA®ªˆðÁëX‹ÀÌWÿªïÏ,Ñoðö»¶ƒ1´†Ö®ûM")ûŠ’8H_Q@)­ÃûÌßj”Yã*Fô&ù2ÙüB‘çÇ.Œ%nåÁ\Û†_ØO˜Aê;)çÓjÙ7 ÊíåÛsoÒ쪰1¯3Yjè@á³fæåE#ÚQÔYï”zpÒáš×,£»e‹\nÆnCþÙPÛöXC­ƒ
-Û .]¿1èf‹Þ$‰V™ÇŒ[óN<š?ÜY ætLçN¢“v} «˜&…yncú(Å:ÉZ£Ÿœî,Õ„wJo ØŸq”é»»2ÛÔŒR⩽(Òue†·¦³‰Â€D…%ô¿Á„Ä	a÷uZG“9ì4éÓ¤uy	Ù¡]&PžàfÌeAÔ>X	õ®pøN·¶±R`ÿläC‰ÚHlÐ$ðô²NæPh7»˜ è›LfŒ¨“ah¿Ïy8
¨ã	q˜ác )ÿ_~1iSÕˆC¢aH
”Ó‰k0zÉæ.@ÉÕ—Rû�“µl‚‘¿R
§´ù½Lý¥tû(Iðd˜î |ëm´ØÿSáB÷ÈVG�:ý†®§DÚƒ?s¼Úö˜ ÎTëýô?ÿ?ˆ¹×”-.��ûdÜ7”ˆì¾.îÐ
-q·
-<Š´yçö{e¯(×6鈔I»îbyö„•ZA„I³ªÙÆç`¼ÏÎS¼^™AáRup:ÓäGW@-!�Äø«ƒèÕßèËs=aË‹Ü'vÉRýl+}¦Á_�¾u0
-Öÿ“^)~ƒpàÕ²ô*²ÿ‰sY:ûyé×6Å€$ŒÝº½Å{‡êÑi×rL#¯(T‹PÆvœ·Qr†¤óVJôk�H0¥rÔIV€«´*$ã®/
-ëÙO³!õx
ÉRdíhÜ!]	úãUK+<7Öœjã�«/ªM;�Ë>ú‘ÕÃ}„ý甂ÜZV
-bù‰æ1�²y†#Ö6yéRØÙ`sßUJ öà‚Hø.ß°›GßôýMŒek�½„¾Ûº¦¥CŽšËž…l^§¿\<…‡6ÂK̹çø$‡’vçÏ
%hf¥Ëm°¥sô	|G'Æ[fûý/Ša¥¬3µrž®gS¬Ê~9^éÈŠSìꦘÏéNÐó	á¢M>À]àpÀ
-䀚Œ5åèÓíöRŠÙRÒ
-�Ì‚StRóùa¼âæøïŸm+ŽÞ¾µ¬¼/†m@”«†fDä)”y â­XDl_`p ˜3‰Õé"p£ ùÓ½r§à‡¬i3N€‚_ø+iÝ‚WQô¥ˆlò÷ÅK¯Ë.XÐ:îîÐ0ûvפ¹,aÑ;‰<e8“z Uö¯ùšÒø\j^íÂÖ"œ‰7	s.G쯸‘U,™Ç‘–ÚUõ
ê…¶,?àE	jÏ2
-K¼BPÒÇ�MÆÍ�Ö�ßx)<¨„Ó«à?j¨¨[âs£
-#!ÕŸ­ÝS‰¾¡Ú±á$j',göbõÓËÍÅ!:Ñi¼|ÓÜîÊûJpÙ‘ýéÞÇœ*ðáˆR7¢O�&½¶$nÄP$sn¢ä+ouu*„Û“A–�’
ã†ò/%£¸¾älÛñËÔk|*“š
HîÀ²äk|ß�m: ÕU¥�Õ6ØŸo£;§h™:Á„tè÷!©N|çÊ?÷`~Y`¶V­G?Ãça}4¨äIßž=6Î,ºJ¥ÀV9uÖ”!þÈjY
A‹¯ÏdJõ�æÕ…2–ÎÊ/«âÖV0ÙF­ì­Œù.}3}ä–Ü&q—ó?xúœ¾˜þsóp¿]×U‡|y
#çjr¶24°E_ôaà´�¢u¨‰C¡^¡Óå’&BŒ‹‚•M}ŽÀÙz) Ü…tMJXŧòŽ©:õCbX(—Ârj´¶45õèÚ{,3¶jòWó0_±Žª
-þ®£¥?]ÄýŽ<ꯞ'°á1ÛÃCÃæKtð(Õ‚Ã'%ÔŸ8“ÓM¼æcûÕz&CA3þ×E®rÒÝ,”BªyK¤åNÉ×%‘/);ÐÖS˧‡v!ï]Àÿ_›ÓdðŒ¶6ýCŠŸTÝçÌôûî*®¥e轜Ódv*LáOhfò�ÕúÓ€oMºÜ¸‡_õxB5(Ceõº%-n„ôVDÆ„ç�™6j®Ž\åoÕ”ƒºB¬çýû[ÝÌ›_œÿr¸HÔ�;6é×ÑðÀ¼�!Çrª¬
±£
-éNÀÐq
„Ê•GÄ`“Ïx]SJãõ_�ê»G1ÁmÃðé²]„5½R)%hÃ+Ñ]
-we:‰¢}‡”ëâ.ðUöÉ›±-ÏÒõwKP–ŒxÊÙl×Ê´	Õ®Hi¸®Àð”á6Ãìؼyn¼
-#"±91cÓ…†5BZÌ¡UQ}‚Û’á“ÓiþçáœBpØ÷�=:¸Œ=ĪÈÃýïVƒ®Ì¾‡¡¤ã<Å‘J*=
ó2",^†B;TË}Ç\å€S ´rV„-ã•£‘c?5ä圣9zL�’ž1dpAP³¡Ÿ63—ó[%Ò
MD´j&z\%djÕ2žS)Ü‚í:c�ExòCU}SÄ\ºáz&¶ð,GÂ{k�˳
Ô:•³D"¸
²„?.¤V5’0_‚Üö»Hñ´é¦Èݼ+ÙŽÚñ#ü™ëÊ°øm;•HP^vø+ˆoo|ú²®Ë7¨õ$0‚b…çþç<nhœBmWf¡Áy°+‘›¸Uë«Ð-‘�±ôwhÒýi‰
›õž+æ/Ã={W¬ÎZ�ð|,'‘¿ó#hQlÍüyïírT¶Ô‰ƒ"~1]¹²?::·ç3ÝÛ¨wÎC
-Òð�š¦}dÔF\•È]Œ9@òµñ…¿[¡Ô´]z›»•K½Ÿ³™µŸ Pù
-‚Ï€oD‚¯õ!ä]OZg*µ@D©(ú¢é¯NVÓX.ò_šï�¾Ü@Üú$4Ü"_=‚1«qÓTnÌhž¹ÈuÑRý
-Ç�‰
»•ª nÀC›žFåÔã€ë(RX¦ðròÚ…ïØÈzš¹]3èm8Y)HRï˜*w;6ü-$9Ô7ÈbVu|sÀùñ¯ªã°}¨$\ˆ%¼®ËDq–îÑAÃ÷Ð&8Ýß«ñ¨Âµ”(Æo™­;Z{ŠrA	y¤÷>[€Äß‘yO(³ÿ®™3hwr粂ˆ¢†;D¾J#Hù]øÝ/˜[>@çÆŒt.<‘I×S=RÌZ`Ï3Uó%ÖÑõ,Á>!ßÀÄt$9·žÒ›Q6óâ‚:ÕEðµ$î£?u&ÌIßIUŒûÍÛÜ¡½Àý—#û&y-
-tkR¦� ÍûÀVùŒ 
-+Eª0»¹§�“Í3M‡rN?ZeÜÔhSžK½c#B¯š`”Ž+ÞÁ?í@žâM¹ÓØ%qndzF¯ðIÏE8ú£ÖÚ¥dó½ëH’›Tz]¾7]37Ô—ãß?2œœÕ˜`‹Óý5ŒVY7Žâv‡ébŸ
-2ã$5nµD錥öI …5;£·‘³â¥œš½œ¹ÎœI—¼ŠP¶–z¬{çÙÏšÐQÅhÆ-	[/µ/þ%Á4¾Ù^—a‚ªßvè¨1�¡x™6LÚëI –œ©n¾4âzEÍçõ3ù¬�ßÇÖ%r—±(×Ù[!yŒk»¬Fy›˜µ›e5k
WâìŒ(¯(j¶Y9›oæÔjCBçO›ƒ±æä9?}0‹ÀÃÒéstQ Óútƒy QÆä*¥[	~R¨[E†¼Íx#è{¬=�6OKâ#s‚{oq“7�ë­[›¹<nÃœ!é“q’§€
%ã¼ ×$21Ó‚åûˆY£®ƒ;YÕjįb§E»iœs'hœüÓò
-xá¢,FÅ×V¢u=;”ZØn†•îµ"ÊÖÔêvÐ
¡Õ›¶õÝäa®r¿=Ia‰›qììY˜f ‚¤H¸¸ÃซqõÛ#ø¢tÞDײØ)b»„
-•±ÒAëågѪ‡Öö-Ñ©3	…
-iâwˆ]SwC''/ˆŽ‰~ðs
-
-ñ 8þ~|²oßÅ3ôv<*gÅײî_ÈŠZœ�ëÁ
-jf
«ÕIˆ7ÛÑt":¤Ê˜f÷ºá|¥Ýn«8ËiòÙºi=7"*ÆZ÷T…½ƒ Jœ[É©L~
¯ä÷úxô|×ôjƒsm #ƒ�Ymèu#Œì .¨lÝPXUòÑ,‹÷âÐysËÓJàläy¨›Èß¾gVmè|Yɺ™IÎo
ÆÙ¥Ã}xªhx R§ªœØD"áíñmóC/·Û]Ë#ìß’œ|rÝB>ý†›Ýe‚gظ%ÛâÂ�¥FK#¼Ü
-VKëÏ°@öMêhµÕ{í�Ó«k
-ýñWÖÍ�¸uòóɃ�É�‹,In“„È ÷úÏh¬Záßrž×wç3÷¡nã)8FÕ°=ÀËÈS¬�‡5÷*ÎoÕ`!Ú\:âÀÉGà�b¸ØÖ:*™°Wɬ)÷Ðõ�áñµ.Åzxï¶Q+u
-ßo�ÕüŠèg|)¢Ý”+媀B}lzr}/LŸè×Z
-	¸Ä¦~Vyg²åŒ¡°uÆJ°Ê×´fM-€8¥K¬Ÿ«äCËš,J½|šj_6R#/&]ää�æ|e@¸(óã#š'ò{�Ì¿’˜qå »|ð¹L¹¹j
-
-0ís¬¦¬×&0/¾Ét‹ÕŸóëå;”Û9t;ÎÑÛ¶niaóÀvñ~¶"‘_ŒNëÁÚGM]	Ñ#·8-z;aaZJpÙ ½k�š
-²°׳^Kè„…žåÖ#Ö »*0N” u ^8~=“²BÑóCŒüÛr/CÎà-À;0|ûÇ£‡gÊÒMNÄéa`œËßwª@É#—0ñŸ}Åà¦Åÿ“[Ž5^3H¸>x«0Ò"†„TÛp»
-ÓhÙ$ål$zQœ€ì=´ö‚1d–®�ÓÃû"sx(Ú*1¨ø¶z,ˆÒ'݇v!²§ðI1Õ�΃ñ�¦©»g [ÞC¡ç1Q1SÑÄl»Iz_TŸÊé–Éü¢Í«¹>Ð¥Gâ­�È…¬oa¦Ý—ÞëZ¼êɬÿDW•¸¼‹Uô‰ù;VtWí½ªŒä´p€4oUû¤I67Â]¯KÃ%µôN”ph»ÈØO{Viï‡
•ÂÔF�ìË¿ú°È‹!”éH8-“¨š
-:B‡ŒlŽgú‚2ºaÒ"¦¹?|  ÿ¢
t+�ë+ˆùR–~h
,“Ø‚_s
-h<…È™¸gßW ¯@Wç™áÜ;_y"ÙCü	:mM`¢= ã;òtçÊXÈê
~Ô“'–6Ç3mœÄAÛ�÷1­Á¦±ÙMæŽW‰¡Þ®jjÚÔ2ä,Êb¡¦³ÿÊ<)yh+oÕQÑv‘j—3¦‘„å&‰
-ÃGÖÏ:¾åîø§¡û­2M.ˆºD7–c ùWkx6Š„N+§Ls£ÙȶVaŽkŸÓÜ	ø�œy#‡-ôØ¢xofiRTÚ´µlQNí¸ÙÕULÓ‚Mæ&ò“2ç‚‹D‡u£®�#}J¡4×pÚ4e�mØ
-ÖVxæ]"ÊÕ=�¤¿Ëós÷ç~ÿ—41‚ó
�¸%ÊO:F§£43†Y\ô¹³*lT¶Š‚Tò3®�³¡Ž¨Å°¸n«¼AoœsíêrO¼±¶5åd­�1
¢~ìËQ¢¸¾»Æ)56(ù×ÖÂ<ìÖåZ‰G¬LQ„pyC¯gŠ÷�).è1 οy™ëßá�ÖO–‚\7ŒTQ|§uÎC†wv#†ææ¤MÊØrÌ\÷˜›d†À��¡f¤Æ1`ˆ×J8>ùÔ~ÐõÔ&­Ø`Y£Í˜¡cç?›2¡e‰ð D/Ô(–+ÉP×½L-Í�až
-Z¦Ûæûa„Ék6kUqèL£%hp—´rÛ° ÍèE–r:-ÃdÆÊHP:ì‡2;P®…ÓêF{Ư<Q,JšãÁ~	+¡h[ÅRN]~�¾…L„ÁßïüÉíä-—Ù¥ìŸ
-»áY€»}€cù‡Câˤêðq£þ¤ÂeSê]èûgÚò6\LÀž/*X«–Ü>ДÏ@ÏœüO©ªtºG©÷Ž’4Å%ü’Y×ÞöPðüid‘˃8LÖU/p�„h[×ÿ1õ˜åô×îE¥JP(òCˆ¤‚§t¢8ꜧÝÎQ‹‚j%U×¼±†ÙŸJXµ¿LF-.=5†Oí~Ñ
-\jË9gWØÅ."FˆmßÝÔÇ‘ÓßAÌõ|ˆWj
p7MÐ"Kc20ȧåOh]9J°F®×Ò‡õíTNì)mC\Rà‰æ8
èÄ�З|-	µÂ¸ÅæßËlÏB@\�ë®4Ʋó˜•k™_̦CÍö˜T!Ô½\!ƒÂD×$×&miÀ槻ÁLÝ¢»?a�|ÿ¤þë™ú*$÷¼66ÛëðÞºR¨p`N‹8¹Îs©2õóŸÉ×®aLç%¢)K–9CJN
-iÿót:ùÃûxxñÍš6ïÛ÷ÄKZ·ÏlŽ¸ŠŒbd|Oá±–kË¥þÎÏB�™E‹¤»
-èlLäšOnRZ~‡î&I°=w¦}æ‰l§b””Î÷g Å�TÍ‘ûûÁ{Ë1LxméÌ­�?b†‘Ü€±%Öé]¶çÛ'$5ˆç
}~Ü‹{Á47
ŒCS
+/Length 26225     
+/Filter /FlateDecode
+>>
+stream
+xÚ¬ºc”¤]°%\]î²�,Û¶mÛvuÙ¶mÛ¶m£ËU]¶í¯ß÷Î�;ëÎüšo~äZωˆ³cGìsb­'3Iä•hŒíMDíl�hhé9
*ŠjòÖÖÆvÒ4Šv6€¿f(!';[a'N€š‰1@ØÄÀÈ`ààà€"
ÙÙ»;X˜™;
ÈÿbPPQQÿ—埀¡ûzþît´0³�þ}p1±¶³·1±uúñ½QÉÄàdn0µ°6
ÉÉkHÈŠ
ÈÅdU
+üPˆŸìá|ŒRbQ»š€�ê
+ÏÎIOžŸÈ†ÆGG†{oÁú°©rb’p¹€Â’FúýÊÁæÓT©©jUmÛëÕb3ô]ÿ””sÂ
+Îl~^õ­H¹²çŸÈôÿbاÑÙ®ï岞ÒæNHÙ™C	½‰h1R�^�iC«ÙÂ{»AùÖˆqwÛÁxyÒWcÁ·ÿ¡y÷'‡—ÁOéTñ´šŸ­wôêuòÓsPMTUËçýNÀ(5±†Å
Ä ö¶‘�ÛMüc,‚�¨×]EI[™Y…	¸îˆ0�^ÆMÏm}™×Ë 3ž@óɪ�0öGƺ°>KÛy�E‡“åÜTh6þÁØŸøÐJ¢w¢§æ_[c
³ö�B8xÕ¾Vk”Ô‚—I¯¿ä„÷gÞk‰òŒ+(}‘²Å�+åýdä„P9Œ,U•ä�D¡&w("Z·´U¾D£|yÛ)Õ‚þ0ŽÖ)¹` Á6l¬NÒµ½žŒÍ&²˜ W	
+€gÍý¬ÌV” C†�û3æèºnMp»-˜…Z‘˜æj¤¯gÜ\}–ʈ}—}ÍšP«¤{}ò#U/ÉXÑ
…€¼ðk¬¾ëÜV­�Ð<´eÁºµýt�.<Á0œ7Íw©~‹A“1²Ù°¢%îßD?âÝjÑä¤[,È4ý©
+ÔI™Èüíç‘,ª!Û^ó&I|ú,~C¼ð O¯JëŽs/)'UgL—æªöÛ�'ŒŸKnõætÉËÁ!;ÙÜ\õýâÚõþ#ˆ%æÈMµB”j!ˆªÎŒ	o¢†PU�&ø’¿ß¹PÃ$Þ;Ž‘»w©*t!Šꌄ|Õj”1íw-¡LÕÙ—›ö‚ߎ…>ßË>#ÈQ�ƒ›a"¦´Ú×5ù“97Û
+Ïþu¿^ù5cÔÃ[î˜4mô–
CÌb^Ûe 
m¦Ýìž88ç}gõi.Ó	6Û�²¡{ÇÙº[·:±’‚~s¼r^®µ{×y"j¾À`UŠ2f5?+ún ¸	¼â@œî×�¿…@“�%5£shàî‚Œš¶{++¬#ÂЙH¼GH–�T
l™!Ñ+PH­ÞPË9­«·Ä[ZYIç�i\e�yr*–¨Ö{Gnðx*yçK ’„èD2JG
«L¸Vä±èG6<… †Žçð9‡X�¹;‹X‡ã$]Hñ8ÇR™¿}t%بêŸZ¥
+´êÄÐÓ
+Þkvßèå�à?`Hdò8Ÿáz„û%u•$õAºu™\<bxÂ0×í°–h¹ÚU\£ÑÈÖ{¥ß\«E²È²æx,3wר•Ù.$UÚr¸kÀrJ“»Ü$œ)»
+�'Þõ¹TÒktÊ1 ÊYµœóý–,‚Åw†Åáù.Ûå•OسÐ-Ž^ö�}ÃÊÔ§4¼°…ï¿•U;hŒIv@™È8Too?â.i¾NFNû²O	
*¿‹Ÿ9áäu7é8ã›
+|V뛚¢”ø±W’\úyëªb™=)ÎþWàöûI¢¥Í|ûBŸx§/i¾Úæ3“�"¬ì!óYº&4«?©eL:ˆ˜¨^lHëž|´XÁSº)7x}:Z=n¸Ö‚žäQÊü˜‚>›+Gr*|wݨWÔÐæ>zuÚÐÜHq…ȃŠ0?‰Ù“]¢¨=+ûfUˆb9T
V¶54ç,Te5®Åj
+–€íÖ—ݯU
Ûˆ¢¿ß$»�Zµg-SÃ]‚.(#º™‡`¿Ât
´Üæ	�6¿mà¯ò�™9M}§’ˆù'�WÃÙð´£ÜNæÜ‚é§$# ÁIÀq¯¹
+ýl…;œë‚$#¥Rј'ûBYâSö JLjN·—“\ð“ë�¨zå0y¥~Сª{úë#Òsa¢¸²ÆfÙà´ñéöªðc~ßâ} ]˜V42lï
+T ›+=Ý"N¸F{VwÜ«Ýê'O¼o3Mk¹‘)&
Y)‘-ÍÇ�aÊgþÆ®
+˜r]w9jr‡šØ[�O§ÎéåMÍ�ÏÞ@Í?éÀ0ÕíµDJF„rFhS[ͺ.ÆŠz¤9dR’XL
+fÎ$Ë\n�Þq�94e#q0r±MnJïù»1ç5Gö>
+ª *Aº\Õ@^¿>V1Ö†ÑîçhµäÀɱ~°ìj-ýflâÉL8D¼ÈV©§p¤‡Ekc4²îþÝc=´BªÔ"–¹² + „›šíwp	‹ÚjOI­{4°ؘ…‹VxáOR¡®TÈGA ì³+ ®À©„”À3ã×ËbÀõøϬ¸»eéj	.5ß?.4?‚w1¤ÉÙ,ðà_–yCQöê¶9›«¾_¼­pJ-G¥™Ñx¨^ð5xŽ“L�¼<k-Ÿ>ðh¼D°A€'áO¶0„0²8t³˜¡�hÀ~AÛ{ˆ&î)'`Gï^¦‰m�½\‹HBõoW"Þ<y]7}rÈ“!Vý,U4.Ð"‹¹ Üw9…	ÆžîôÀjìS›•ó™…)å’æøUOí›|XÚr
+j«ˆ•Úý¶”À´�.u-EaAB´=?`Š)/æúÂÆ=š�öÌé×K¼xX¯·ÎŸÙ5½È}áÍŠ•ÛìŸZñ�f6nŸ�Û2£‚õ¥­¥gÕv/ð^€axe¦÷Êcé…|Q*íÎÅ�>t.Äñ˜êò[Ê&G>¬šX>­|¶F‹ÿF9ÈG:�
+}ˆÀu‰‡FëOðѾÒ`g!ë˶’Si™Ûs„×dŒìΈ”’G‹ŒÒ÷¤�úPXŸ‘ÊX*òp¾š£µô†;pšX	¯»Õ䄾ÐÐÅ·.Ê�Æ™³õK·	ó§r±çÌg<¢åûœs§0œRÁãýËdò3‹Lqø%$ØDë=+¶X—¥�ˆÚ�Hï´
m%¾”+pÔg­2œÐSíÛ&ÛÆ’ú
+ˆ!Ýkk»†“×ÉÇ.¾á®ì6Ëq_6…áNÝ«—6™T¶Sµ–F¦›�–‰0;4Kÿ½26aþ2+Ai}
;
bŸÀ‰ŒIu)I£YÅï“y¨)õ‹—­VïEeõ–œ+e"ÑèËF	ÏèwéV¹Õ> ^;"ZÀÌ}¯å®I„
+Ú
ŒW?ð9ÉšjgÄO¤¨Ê£%Oy-¨Ê¾ÆÃt­Š�É2¶”êy(6eÅF~!²×9ÞÕ=¨�NdÔ_Èí
]Þ[‰+£øþþ>»`.‡`ÔŠk™½¼CæêU¬ùôÃÅN²3Ë
+Ú¬wî‘ê"�¹¼|=�’4v§Ù:¬)ÈÝ%¿Ÿë°yÔÅ)aÆÃ=Ax•qÊ�8úçUûƒ�òM[�iñÊŽBËE7ø·džŒ¿_SMé)7ç	\=aY„2Ǹ,DôÝØÌ¿ðÿtöÒãž¿â	K‚7Ö–ªëÏ«wV÷ž®a@¡ §¶¦Û£;4É™ÕÖYYøuzD�×/e£*)£‘ò9fS$ 6úÀ÷ÒlE;ûrðã`Û¸ËCë*‰{•mÖƒºàÊ–Mx¥PJÇn7ß7Á±^m©Þ®;±ùM6ÂqN;Me.”·k–ü¸¿mF²jkÁÒâ¥êv„,Î8½Õ­Mþk´«Á5­� ÜªUôæ^NÁ&ºg3w‘²X4YeWn)•#~…¼qòõh¯jH¨Åö¤Tpû÷ؾö|]–öÎ…¸�GxÖÀ´K<$L
+ÔUñ`•5Þ
+¶¾¨1&µwÉù|ì9UÛ39TQ÷䆹í| ¡Ã(=̨º;	GLâ§6ÿã�ì¸Ì¡"¾Ž•w…B|(iï�ˆ'Å'º¬ú[7ô
¹r+£²*iÌ�Æä;¹E}—ûOþÊF\]¦l{YåAF=AD
+»÷I¦aôIãÔ'§»ÞÄû�✨œùZzñ
+´a�fÓ´s!(ˆ)§é‡¸˜Š Â
Mí0Âß<_°7;3s]˜(ª¬Þ)J�ÁsTæû°€½F’§Ò“_íç#¹ÏïЉ¯"#(àÖ!È¢‹ù£áõDóòöÔfÆë"S§ÔtN'Þf~¥ê:#Ï¡Ú®“×5¬'9/Š�Ų
+1«¬Ù]͊¼Ð�°ŽÎžl_ø)J%r˜#sŽ-Àë÷­Ýà,Ó’µÿV¨ðyºoèLLe·rÝLû—‚f{��ûc†lî�	%Gä·Ú÷<{­ëk†¯¹�­ey4X«Þ>¹×¢ìØÀª"¬‰åLóp	å4I»{lî5<o„îÌû4%s‹_?Y	sP[ϱ0Êh5è²ÀEÎÀ—B]X´sd«3*8w†çñOSDŸkâHÅkd/t$æÕû9ÃÝpš®²èwm·Ù`×E¦mSû™ªf.þÝ‘¤�ÐjõmïòïË`m•œyò§oURl»î*8
+©~ó lP}E�H¦à%ÄM¼·¾t›t‡¥âÐ{cöÞBÑP,Ì6@�–�0®ª7ëSB¢sÐãiÃ]î“
+á¹×»­còh�¹ÂY!Ä÷­Kο™x�¤õb�VÑÄŠéw�‘q¢†BŸíú·\¦å!ÎïÖt–N´AGsƒaÃ6ö¥¬0%˜Y�—½ãX*íUϼ.;ÆëÚBØ�åŸÕ$’a’ÉÅ/KáKv2zQü	ÜIDîÔ”´Ö# ­w±Bl*sA™vœFûô¹êH¨ËWŠeÍ6«T¬GK¨´gÙ¯Æ#&¤'E�¶ÞèÛƒb�mAФMÞùpþÀx¼(³L½†^PÅ”‡¤•ã°Ò'_ÊsGÈxh�4ÒçÝ06�‰½`}‡­¹Gî‡)U¦5u†=¹‰€®qäXZ`”…*ƒ
}^­Ý›ZÆËYÝ�…Ô
ÀüF0j ÉؽoÑuo·àd¶lŠôæ¦|•À|�ÒM ÒÐ$<tÒ;¹–®ö¿¾Þ~<€·j4�uuþe»ñW¥”ñƒ£D9ovˆ<Õ¹çp¶Ö\g‡=–ã;`×_LtZ±É'ò�ãó2M
iBE‹À¿×jö
+rÂWf¯(¾ Ê.Tsûœ$rG~‡ÌR)G…-
ú²O2cl?ÂBüX	CÇäd"iXćÏà÷ÈÏ:ŽDN
+ä¶Ôñ{mƸM¯ýœîdßË
+‹¬)Ì Ÿž6Ö=
jÖdÃ�;í¡Ô¶„µ¼n:_>;y""¸ü,߸藵’ðȲd
Ëd¨Q T
ÇëìÙÚÏÜ­•ïØ`.ø|Mõíº�$õ´#É�*šö7 ´¢Z•—Ã^SúëVa=žBžk#UõuƒKVQVQJÕ�ÞL§Q¶Å¡ïºÜöÞÖøMØ¥b]k�®Û
ý7�>ݳd«,B?.ÿ@uÏD®3uçæM‰0).WòòÉÈhW'Vws˜‡×ˆ¢ƒ•\
+=;3؇ZÑíx§fÇu1{©‚qnˆé%Ñ)(Û+Ë*jóºpd±NãÎH¶›áóú E‹´Ø*ë_ªŒ®MuL¡Q°­èlq±ô¦‡³ý4ýCÂ4Š
+õgðeµ™	ýÙabÎbg›iÏRZkaPC+ˆrÖƒŒF&õ*4¥vè°½4ü`�o²O¹Û•{6oŽ;ǧ5M²*ËË»mýæAd/œvH&TvןŠ•×èë§fè"W"Ô ˜_©§D´ß-ê{IU#\Ôw€18_1mGwÃI&Ùj™6j%µ�Α4»o»R.*Z¼Ê…jº…i7“—n+2{'oœnó„É^*½mp`6id¢ýU•DoPþOz¯@@�W7Q!˜ã¯º|—qu
ËNƒò,ÖÆ8þÉòê’xÅ“œ-LÂæ“š¤Ö
�,Q‘ݾŠY]ò:ú©s¸÷8UsÞð„Œ)ü<²oD¹B2Â
+Q9ÁïÕ@[E£©ë|å»Þ¡–åq¡¢ pȫУá'¨h æl¥ËˆxKw,Š–Z�=S÷z ë‹TgÔèŸ)¸ yXɶÚj"�С~Ù·©y¾Wjǵ­
+)˜Y?þÄô‰H;§#ËaY‹zv,„krÇ)Æ-�¼›è™«Ÿg\�VÆAÜ®ô×f�-²”xéH9ØM±·‘úÕ¿)ÇDEðHÅ#Àë-WΈbe8Ôç˜y•ÛaÈÓ¶#„ŠB€s¨Ô[¿Ñ¬å=%*žÞ$�ŠÞµmu|6$)!¨z°ŸøÇ�¸ô†áîÊMÌ]Ê„hf⃕ðH!
+Z_!ÎØÏ™P°‚ž§TÙ
s§ÌÛ ˆ�o{V®!(H”4o|ؤvIÒ†¹./ÔPÒùä³L6ŠH±ÞNÛ¯9s=N­âkûrë¡¡ #Ž™.|eìÀ‡Ú½ì�ðâ+}(|ô’�‹Ñ<w–ãÇûpÌ'ä çEFeÆZ
+O>´
?�ˆw]°÷¨Ãæ'²�€n]*¼½ZX6Ïv�Jgv’‚¶Á�=£;–ðO
½‘*-ŸâÝx�>G(
†Væ3�ÀamÔ­{b|¥%D~!Ù;'½Xï×>Å{2\ôsA¢›å
ÖOUiCYxm]¦ý,+“+ÎLïûôc�K”¿´ãOn¶Ó†�2pÖh¿�EßµWê¼
݆a#’Á°I�mǨÐ5<,”ç'—ÇI$º¬ª�êßbŒ>"1^ÓZ-âáÛÝ-ƺ%·£¹¤“—Í¥’IÙ ÕÛzbÑéš}¶~Ä�©âLÄ6 ãaÕÁq�ðP2´6GðâPx,ro½sayjñ¥\Mó8Ë49öÑ~q|¾^þZ:@MSAÜÓÕ}$\æý¸ú�†
+ÔSßõ}FÆúcþ„"Ã\|¯*)ÕI
ÓÔ–,õ†˜¥I"
+n½ü.ñø*ì	AÆtþØãR‰øæåUçÙ
+KùMg”�m{·Hn-dðƒ­
+'´	‡úÃi©�šTâ¦a4ÛÀór4C{$ÐI™}ø¢Ù>a‘Z(žxSomgìY/àOêÛ–·Go<Ü�;œö£~NCbŸPT{ŸíþBÎÞ×pR½P¤ä¹ÃV‹»MÿpžíÜ*¨‚]�”Yè=¡zéêÛCœ£LŸ3t7_�>&IZoômG‘f~�•¤Ôóþ{àMß�q;:Š»Åu ¦€©ÓZOk˜ˆ<´Xm�ümŸãT`»u6J�+kŽ¦‡+Ö3ê~ªdô›™Ò]þAO†ðq
†Â
…“”ÈH
®è$#c*ÿ1^ïÉ’^‹ÍR¹aéc‚ç'JžÂF°úÝŽH18LVÙë`¨çòö«�;nQRGí\vß]"zÊ°�¼~Ë*¬‰@ÔàÀ°··¹K
+
ª`Ί‹šXN”ÀU?Ž¢®ºëÈ5ËXrB0n9½âà!§æ®»u*PSçoiyµÚÒLNöol�U®/'
²ºN�l¾�+
+z·ôÌ�‡oŠ%ž}Áwiô[ªÙ׶K�¸pWâ^­
níåÛiíèf.\«™CÐ
f¤: l©N}Vâk¿3Ê[‹æ+>C²W�97û&
Î_lûnú6±pÎÈè?9+Ì^?…ö	z×û±·ÝIÉ*ð¸ãEu…nÄsA´Ç×ñ�^dŒ–kC2^FvBñ§	Ó¬Yƒ¸†|óIÔµ%y$¥Í•Èƒ’¬¿BPÞƒúuÓ?fÒrJZÔø¯e¢ú
+WL©,ãõ®<ò¼z8Ø�AÚBeåŽýAf!Òç.P£MX“mtŠž¼ßZ‰^`«-Þè|‘ª<:´N†„¥,ûP£—ærÌö)ìÆFSuê‘Ù-Qà‘×®
+õó"KŒŸIF€¥%(³–_@k°„
+j-éù•_"R§‡7D.àúœµÁK`RŠcàÅR
Ó¶µËê‘V¡€Â‚�
¾±Ð
‡‰ŸV�':–ðê$íôÃDgènº¾Í·ìM‡k/‡&ŽNYúÞVÆ3‚tӾݭæ;["Û‰`Ëk•¬‡~bŒók-<ÓLÄHsH‡X®¡Ê%¨};É„ÞÌ“Äo·ç™HV²[]û:ûýã÷ön±Út‹©¯¼€ x-0å­¤ò3(×|–¤á#¸Úª$xœ£
“µ[=~©øwBˆ¢ÞЦîx´-«’Â@iaéLß
+–qÇÙ¶â(ŽÇwû',»_eßùÈvôÕÝU]wùd}ðy0=˜$IyO›ÍÈ€œ=»U9e~5ÉŒœ¼uo{´Ñä¬nEhÕkPía˺Oo
ÑQ2úˆ9Ôì&\`}ÕGÈÔ³ktð´bÖ¬5‰\5�°ÀÃbC“
+8×Ù¾]“’h·À¯6æâYn%«ç�Œò2Ã>¾õúŒP?$8uŽÁp
+ ™ðˆfd;®"¤¹dA¾£B·KµAP�ùsF_óuª†.áŠD*Aü¨ÊiðÔ•Çð—3+¥]ª„kyÕ£dfÕp¥ß†ÜŒ&è tÝøgXÕ€Š¢ ãŸ�6MªE×ôR¦™–/œÅOtÞÖôÝýÙbE€(àºè±GÑ@…¸A¦½¹ûÆŽJÉìÁÚ ˜‘êæ§p„¼a¦ÎïbH—@$ÕflÕ?îTù×7íÛ|¯œ1¿T({�i•ò¡Òj�[Tb�>J°ÿ܃>Ž.è
h‹æ
+v¡=åze׶)ö\à˜¯y€Š|É)
Àµêú<`I@Nw¦éŠHræ­Ôóºƒuy.)ø·Û‰Ýê‚í\üèG®øÜè8tÏ»ôanퟒJRo╨,ëE…cc!�U!ž¤ºõ�N�±“¤×[zç�Q¤QC"5ä
ã‚Ê|7ù9s0˜L½I½\ðî	§¼õq·aø‹_®sÅ$Ö꩜Ė]dyé=t°P‚Ö¦—3YoÝçÒ2Ëp•ç]Lò2†ÎïOñfÊäNªQJUfî‰8¶÷$ý›°‰¯öOv¢�8ÉæòLvViÊZã¬à¥Wf¥
+<”â×­Ò�ª�ܹ�çò3¼+çÓ2> $´‰G£éœ'¹’Ž¼ˆÔ
+ªwQå\T1‡`ï–*�!7Ñb¬§¤ƒÌ%©©Â+¨÷|¸M·äv×·vã„z²Žç§ñN4És÷ôq€ÔüY ÐW<o9tƦ7°6UL¡y¶s-ýsŒ,�ÓÁDHHZiÝwà¾8›5‘ÊK×>8­-²¼
+!STlÕ
ȇ=f¿lOtÀGF­FTØÌ]¾Žr»j€¨7mÞ±Ï[Üû)ѢÈõ|ÿ`yzŠöÒé±<‡‡a^!½Ì=UÆø×ÈÂúa¤Î†¯=Æ%L€®"¿ý%âwQ˜H_éwõ#"Ü�H„-»Ö0PõºÞ¥@°lÛ�t´+Ã=¼~•¬Z>ñ~�)E‚®8¿’…@ Å²!tiv6diü•â¨n�©
J@u˜$íoá}ÝÉ–i3Áñ§EÊ®�äK�„o«9
‘9�Px¶:lrÔpÊÕ²²`¸uÓ/µo­î’h±†™º¤Õá¤Üôƒa30 ?GÝf×�k!{h¢Ræ×;ì]
OËÄ(«‹ž<üÓÎÃijW$Ä,=
B‘Å)HS†b@‚ÕIw´«–¨;¬Ùlͨn³]]C�þÃzÃÅH4¯9¦d˜«çï¡~�¬ˆÊ \ES ·Â>VjPÈ7³�ßtë™LËYýUå€(ÉxpЋØÁß`›¿ÃTdߢ}éøO Éñ¬1°y°‰¼wx;l¦"–SH{ïÚË“°ØéÆÛ'µ‚� ‰œõO
+‘xÑ6@·î“ü <SË~m!¾áº™Àƒøu’°ag¥Þ¼ÃæÚ ñŠw­“ë•Î2z­B•CÜ.7`˜Uy̨²Bzx’qê/›ä?º—d¾¨¢
ѧcŠA×<38æª"<ž ‚õ�Æ—½
+;i÷¤ð =¨?³F‰%dr,¯Ô=wxŽ$Ì„½‹eÐQ˜	}èax>�,�¢RÔ÷ÕüMoÖ+&Dù
={ùfs�9µ¨<|ó\¡Ð’0së·§!Æì¡K^j1®!çóã7ƒÂF!2ùš/ÞQ	ýW…!dHc±g±Ä{«£Pa,†S™"GÂd¯Íçe䶬ÍöáÇþ°Ë�V¼Èˆ�€CaDÜ�øç�f:*ºXþÉÁŽ)2Å·áV׫ÂPHLVz륚íä«Ÿ96? Í2åÈÕZrÍ­Í »È»Tn¢"Öhd T3‡½:¬&™t0M	
;Éà¡?„R„ùHÌ÷�ŽlߪeÌ—cN^Žaî[¦|©"ÏP%]Éúí9F{ ,R˜,wÃy'kÊ?Áz�ï×J#ů§¼¶�7èÑf[ØÖ¸Ü8�m>é,Õ£ñgsöèîǼ–Ÿ >¢’m�ƒ»šz¶‡–œµýdïŽf[¹öEódd@â?õ–ûn±áH¬‘YÄ.·äÈ"R½¨³®®c41V8;MmàZË¢ò·ÝHu0”`QMĦ‹Â‘.;¢¯|í/âcb�ÇóŽ—GÛR>BŒÛb}7krê«<Hú€·Ïg†Îq¯Kîý� \—|XY¿k˜ôÆñÚ.ŠÖ§	rõy£çu‚dàlríÝ‚KWe>À¡꓃ BÓwè‰)YXP›Ålè•1«€KDà©)ÎýâÌ2~eœM=¤®%Õ3– Cu^yQ ä7ô£¿˜e*²»ž¬js»
¯ù‘1'¡Û~POœÓü	T™æ·UFaØ­ŸsA?Áè¼³Þïê/Ã×›Ý/ˆ'xû:ï+#™>ãàiýƒžþˆ¶	âh1CJi•ÅĨ�
0+íˆ	ªä›Ò¼fÓjæ®3„":b^¿’ž¾>œÒGßzHű�I
ŠÍ2‚W<—ø­î±aj4Dµ“	5«\6†3Ÿ‚ c½Fbá¯8çÒIzTp…!‡ˆ­W@Ö…•Le2ˆm¿MߨC8Žžç
¾|à̤ÞBÂîÞÄx˜1=WUTw.ÒB²è¾Ô�ç+Sïj©zx¡Ê-iSŒÌ¥ŠvÔ¼+ù$zÁÏ™FK0&}
–ã㪼¬Y‡~9M+Ã¥SÐ%Ì.äÛ¼­=éšâÒá™>uMÎWÐ_Jú±Å("3²8Bwú÷7Ôm´pJ°B�4¥”Nƒk[‰urÙÍù¤†sH÷Ö°aÍúFŒÆ]bføÓy<;X†4Ò²RÖ:’êa“‘qXL¢e9G膥`ÓC®%…›ëTÕ“�PnòDXup­<§Û­Èž¤ODZ‹ø5­¦/»#øí>¹Ý¨€º ~'–®y×âSï2ˆÊ²„´` l—Ú-|Us¡o(ШUó4¶ƒ�¼&‘níüÅçcè¯7Lçdk~Üæî…MTx€iÊL1ĺŠœŽõ‰4Ábͯ†Á¬R=ÐFÿ‡	hC(íú6IÙÇ0”¬ aúÊBJiÞþv£¬zh7ùp¢wÉ×é–WŠ|WXva,qkOæê¸ü¢AÂLR¿i9ßv«�!Uno¿¾Ó7…­EýØé2CGÊHß
soo¹°®âîç´ÃÓ.·ü‰XÝ[ä
+sŽ[ò¯ÆºŽÏ ZªT˜Fu醭aw;ôfI´ª|fÜÚâñ‚ÑîB5ç:�ô›C]Åt)´¨[³')Öá(Ö²Xý”©A8çŒFŠƒ9'™�ûkóm
Áh%žºË!]Çqf°pPŠpÛhT€[LœPv?çM4™£nÓ
MZw ×Ð]ÚUå)nÆ<DíÃ�Ð0ŸJç!pº�­µB‡#_JÔ&bƒf�ç×M2ÇjH@§ùåAßÄt
+Ópd½Ô[`çCDîãY`=O¨ã<IÅÿò‹I‡ªF<
óPZ�ä„N|£Ñkÿh!Jž¾”Ú§x¼¬ÃÇ�`3´üµj¥mÛ*õ·ÒÝ“$Á³a†£ò��Ñ*ààw¥+}ü[=5êÔ;ºžiþÜÉzÇS^ dSuœÏóÿüÿ,.Ä2lsŽ¸@
î³ñÀH²Ç¦¸c;däýHŽˆEpcæ2®ªÉ'ýœ²( HñíÀfº6¢~ãÍè’6yÏØlêÖ¿Œ·ð‘®ª_0
°—j†BƒLgxN†N¼¸4tãr&ð$Òá“×â�³¦\׬#RdBÚsdz/¬Ôü(Lš]ÓÄ>º
+Á¸ç‡ÂúIo>¢ž  Y†¬ƒ;¢+A²ne�çΚ[czýMµm/p5@?¶~t€pð’ºF°‹[Ç
+ }W—ÔÖ¤í®d�Ïê3Æ­­Ò‡¿�$ºÕVP› øÅVc%3¥@¡íä&žH˜.ÀýÁ6vÀáõ£…z…BqÛNÉš›2•TûD:½õ®àxü
\Æ/(tùDѦ$C‹%Ð}B–ÌCÀèçQÅÞ§�ŠµHËÅL9Ú~[[f︙¼mZŒ=6%	Ù]NÐu¤s0E‚ÿYð»\I'T‹p>̵†ƒ"H=‘ª-ùQLO*I!P9RÖ°´
+tE$ú�oÜK‚†¥ocÙÙ E/¥ïµ
+žž3¬ªA9^éH_ˆÊ3ìšæدÙnà‹)áâm>À}ÐhàÄ�šŒ
åø3ÓÝŸ•Tw²•ä!l}òrû´žMßÁž}µe¤Ä¨(ÔvÇ �µþ«Š	ÉpÝ8})Z¯ìf�ä8»8Iƒ~±žH.<³�»k—�Ã¥ÌdÕ¹<™Xð’hɤbÕs!÷Müÿ´/$¥nŒñIpƒR{Ä„'âcêRIÙ=\XÌDçl„ñÙ7<²´-œà	SæÞ’ÇV�ûñâ¸bå#É^e‚ÏÙþ*Y¥µ
+÷5bóWŸüÕôt³C9D$š)I®«K$j tR(PPÀ"“‰ìXjÄrÍq=L7D�ã`f*n^˜ÑééÍz˜`ÕîÊ�_Òºn°u|ù5Öe3Œ?�Ä‚!×J„·LR8“*'²¸¢hŽ•ˆã€AŒe~ô"ž^'Ô®qiÙ&­´fˆÄãow^xvÁoóÏRvÎ?îè†÷ÖlùÑ2ú«4Nc|mOdòpÝ.#8£²#îK²nd¹!6Hßçw¿Mï;ž†‚ìÞ	BUuו€‚CTl®´ÔZ¡ØlAi!Lëö.¨N«�¬œÏÂðNÕ ÷?õaØÞ&.8Gq2x4Sâ@ò~ê–œ%´Æ­j¤«¦³úN‚Ó˜N S�ˆWVµêYkÇ°¬5²¥áŽ¥ôbûz\séeñ½kQZy¤h*Z–E(ÚRˆ3Fè~�˜;ã�|$ªÓÃ[®ÍÖ-˜N]ˆÉáÙP�<|Å:³èôFÎõSº6¾Ï,)£Tÿ¨²š
+Ñ�åêB:­ÃÖŠ
Êx$To9@H¸%±.¨Ì~jô&+A
 7—ê³Óê®ãOºQœßÝÓ¼UëªðKŒGf´Â8�Jý?âá~«¦°,i´KRQFÈ:çZÔ²öhÚO>Oɽfx‡2ȪA™`dµjgÞqÚþæ
b[{e=?_)ºüDÁêÊl[TÌ�37Æ8)Ñn+àAíMõ­¨Š"z´CE'h˜¹BÅQqzïªö0|#aÄ—loàÊ—v’³XfŒ´x�è@—zÁÄJ/Ÿa‰¹­2ŸÝ¥1%~¬uÂ…ÚÐ63íè4(ÖOHv´Éã‡6ø‚æ*ñ;yŸÄp+íKÈG?üþúI‹À7	
\sNw%Ø’‰î;J¸To•Ö!�N�ÉSenéN†£�²p¬î“‹
+4­úWM‹~©¡CÏßÊÿU-Ÿ}ìŽY¾†¢á_±@Yh€íu›�øbÔnW,ø”=ízt<îKfp¥]“ŸqæÅÞ-3Æn’aZ|ìŠï|=AW?~†ŠŠ¬‘-šë\ïb;üšsî¶j÷�Žmùé4§xßîh&ô¥ü"{kƒ³é|‡l#g nl+Ï�7#R±´Ö>õŒ™Y©âeë:@³Í¿xçc…/}RÖ¸g´µõIßârÎëýM•4yþ^Ú'ȇ·ø§–ýͬ&‘^×Á7È:6'ó'r2!LÇ1¤Abw>ñg²*¯Ž¾O‚Gk(9ïu
+�%¶íV,ÜQòQÛÆtäf‡ÅuZý~J´A{�3’ÀJ™‰&Ð0M\ý\¶XÀö1S¤³ô;5¯EaÏôJ0·/›Í4j³}
+eOLÌq3©¶Ô}ÅÂù„×
+�³ÝMB®Oá÷£…ˆ¾b4Ûm5Ðo{\ˆciÿ™ÇWáÿ3Î%üg©çŽŒ¸Û¹�J…QÒ‚Q
]¢À›ÿБ:™¾††4§VõÏ_$2}Y뤩ØÝððÙ� ÿ¶cÚ¨"yo�g2ÃŽ‘}	º8SJ)ì"Ko™†øžJ/	Æ´“+b<7H @,U¸)‹}ȼŒë§ü`J†g¹÷ûŠ¡tm
+…™¡é*®ïÏZžx;À-Ïåìƒ"ïÚ†ùòù·)*¤¥3�ËÚ^ý=äÜúP~Ø.†ÜTË‹ùæ�(Õ¯
^þkΛ±¢é¤TrÌ°íåZãÒm5Xî3·#xæÓÄ·¼+»b{ÿÃ�0œ}-å1˜Ë¾•áQÎÁz‰Â¬ÊÞ¹tEpyIêY`à7¢K	KÀ½1«Òâ
++aëØ “)¯[L’ïµ' ò+Ÿ°Ÿl
‘\ñ™ÛtôÍ<ÌÖëwÊ¢bð59Ð*ßCdŠã•Q¦T¹/®¬“¯}%%§º/»ï³t.fÌ
fMÚ˜Õ]Õ4}/	
ÃÆѾ9ÿ5$ÉýÓ\úP/eë1WÞ³…Óv`ÓHT»Š@NùÛèjÔø«Â2¬ËXì^â{ËÆmô«—Ä 3¥è)Ç�	UGø:ÿ‚|…o?W6Á~ÇÈ!]ØâgÆ®±ê3_áoxFP²¾Nµ¢CŸs|’u(ÙR«ãòâü)ÞNcZöÒ¼°nPF›‘úâP‰6�úÓ(1êv¾o*ï›”|QÐ�ù#$!4SzâS#Ž·uþI6Då%3פx{ˆé´¯KKÁçÌ®CÌ
|HuæË‚Þ
+mèLj¿I¼Äyê4¢“xC‹´¾}í_dšÈb‡a¼Ð˜
,ÇÁ”jÿ»¡|
+ôÏ™�¶ôú�û¿
+h?IOø¿{EÁk–X4~Ôåqp�„DuNLi’ã¨L’¸œKŒ}ƒ—Öxåp·UÚ¡e=.L,¾uêÀ±Ó>Ø6¶�Ëh
¾­I
©¥2ÈæýkæYל2oíˆ6K�îØà|ž	°
+4£|í4öî
#a`ã�åƱÂcJN¿$DÁäÊ:ß÷”¶Sù¿�š0'x\n)|”"<
jÈàlZñL|ì�ó“ ¨EëhÈ`TdÈægòㄲ'{°›ö…`*ÌñN¦ÈKìí111—Q'ÁX¢‡^¡8fŽ$°}d+xÑW_Ìñ÷õ•Â
 Rö>ü?ëáˆò$ƒ‚EÍ›z`…Ó.´ï�îÞ9C˜Lö*¸`b@å
Ml
å½/O‹EW9
+¦?Ä›Q‰ìó
+€u“¶o-ռζÈFE£ð.åƒÊŠë>{‰*¨òwµš°s÷ãÁ±A
+Ä¡gK°–jྤvÖ?�”lMöV([®™4úÊáD3p½$V¶Å,t‰#”ò·k¼�Í_y´©¡4A{;D9"š;ó;ée�$X|9T7N®åüok½µÏÝ�3äñ= àŠŸœó,çPzìýªk,AUóÚd¢`VX�¬@a!G»�¸¬³^„žÍdSïÄâzy’_W}TkÓˆ}¯µj,BMðî´¥{¦XS~§aN·¶®žc“£Ô‘«8³s&ëÊ‹·Å	&èñÜ”?äý«>�ÀÞ×]Q´®óP™Øk`ßäÕÝfû®‹Y×Z«ruì=È3€1\&ÀHCNXùlu[80ëFÝŨïØìNÄ]©
+˜%0œÒAJ^ý´¼%¤w}/ö‡î²òAæìQæãžûnúéùÎÕŽÙPÒòçÌÃzÈ/Z;ž)\x‘ÚìëÖÞ9”U.‰Ó_>ò_øá5Uûc-­@6
QEæ*D}X2a/GúGc1§OMc-Œ¾2å\¶ý„ÆP¶ó2¥‡`1”{݆àYšU!²TQŒywµÄB´¶BS�Òhឤ2šA1±3_o�yPüTIŠ¼û«õ[»TW�”—¡6ŠÅ~u‘#·ë�õpmðI„#³ZÕY$Ø�óyø2XõþÇ0†¸-{ñÍ·¾ªå¼2ñåÐèœ/ûY-T !ÓXÈ`lgÀðß‹Ù§¦ß
+_ÃýS‡µ	)1ŒÊ�OesLQ²
+Ôqµw
ˆlød�{ŽÞ‹t¢Þâ+ïí[^.\1}
)ÃÌÚtú¢à›%×ùRO|cÇŠˆ?ô€L�]£µúem˜m…pRn7+o“Þ«¶�›4s·Í–çë:yÊtôÒ²
ê+ã\æ—�‹HöÉ�ˆD#|q™eѺTÀ?È6@å¦}Òú”¶¢§†ñ®ÐJÛ?ûÝ(
+!N™<‘cÞšó¬1¬
+Jµ¸�Q
+¸*	ÞNK
+Ä'ΕoäNï
çÊòHª,—üw*»ú.|¶0ÚIÐ	ž4[Vƒç›
-Gy2½
û{(b'óXèŽïÝÕˆYzåeø’ºkSoðÕzN
+…Ï\{¥?!݈¿Q圲,é“Ó{Ü™Óó½%·‡ƒR™ØKY,áëÎú¤ÌLŠšàßÎÐc+t_5ñ‡^€¨aà¹3n<‰¨t6.ôÌö›Šûƒì-w\£ÐZÆ.�ž(¯íôúDÀëôèT!þYÑPêÒ•m‘�Q•ôƒMƒhØ�›‹Öš– Z¿,ÃCó
+ËÝ@Á¢g�ßqìöD€¶þ¸µÿO™ë&Ñsu€r“·NŽ¸¬¸Ü/½à=Nº&F¼«F_L-C§ˆ�}yï=]Ií˵¦² †¤Ä,Õmza­®4@Aĺ@q‘s “†D(�7–Øuç´qçGªw=cPÏú#ÆÅ·¹ªËPl²Uø¾d¤GË^ôë/mŠ¯,¾R�Á
+¶Èãé©t²�„4å¼н”n_0gþZXßåì…×bKÀ!È*Š¢Só±[¸ùq]²Q¨ù
+R㻯Ù�QôÏŽ}ÔZ—7“Á ¬¤jžé
ñ"�FOi�Š>?ÎyÛ!änQT)Æd§
Õ©Jü[—p1}àn‹ß�¯¶ñˆ#ªU{¹SV}¿W†yT¼"~,�*0W‰™ý.ÜXxäݾw‚”ÕÏ#hïyª ?N8,�¬Ÿ¢Ò‚÷†—ó]ÅŒPpF�ÅKÕ~G‹kýj
Ý¿þKIÕ$õºÁÞ�º©‰uVé¡OýC±ÉåMìi	ž2C´gyƒ?’ËvH4åËÌŠJ
ÂCéØK!ÄÕãþIêf|ÐÝþs/ô³@Ä:÷8=]׆ËlÙím1qGoi{tÒ-3î.¡¡�¡)òË“–š1®”9c¿X;È:Œ5ð4‘�t�# `bK)qA¢
©˜æš ›c´­5ÁzZ1ŠÞÖª)\“²1ì×±u2�7Õ@}}·
f RÙáÝoW9Ç\P¦0»EÆ}UB%×/y×—¶¤^â¡26ýù,bÍŽóPI2ƒM<¦éË:ª‚ »û­h�¡1¢Yâl8.ì4„ãGóqj#ÊÑY
+bJÁœ>ZÔ¶X-wJÂp²u©âÆ0S§±sª3KÅæóì“#‹yžÇ�­¶÷âÙØn¼ú}åÔ\C"…}ñõkRO‘"ÆÉصCŸ°Ç&î—»ýl#˜LV¢n÷‘¡ÈÀ)5~ÁrioΟeÓH²ƒ'¨ŠÒc~1GÙÏVÛÔ&¶b®Æz†­(óÞçy]µu9Û³·ºSß<ñ‘¨¥ÔÆúµ•†Š·ý]n>+�`½÷£�¯´¢w¬lŤŸÊPh;w#7Ž®vUsË0 ÒÕ1©HÖ�W¦Bü0%Ï�	x4î/ƤúEGû ¤y+Ë(§ÛH·ïv²x�¹1=›uBCpƒÉ�Œ5¾ÂÇ™Ò{A•0žÑ5'†:]+³lYô9²Ÿo
Û;O%í§æe½;ió]…J.Å*¸½ÚWf�éë]šÆ¨’IFD>’!(š
9$˜Õ{è{W»‰êå|�rg,fi©†Yœž›V™êkS3ððŠ³Œê£s(h"ñÞJÚ¹‚ërG×ȃ®Ÿ¦Ô\ãûö!]aX
+=ÄWDe1ˆ�¦H”L9Ê
�³‹Šâ(ÉLU~f
3Š^ùž©DÃUBAB´m0Ap ÿØÁ÷4@-ð³ÅÌO­‰D^¯-;<�BÖ6÷¨qs LâãÔ#½×ÄoQ,Lñ¹½
+A™âõ2ѶŠŸÓ¶Äøí÷w6Ê+–IºÓœnµq×oúWïkN)ï�‡mÖ8/1aÀÈ[­ø
'! ´ŒÄPxÉ¢rB<�–ðœØEÔ?Pr|7°™2�­²�3Dá ÄWUOš9¬hÓÄ5@)NI´°
›s0ÇÖnŸ[fö½U¹fHɸ>›»|¾¸¬{ü*ÄØ*X‰À¤ø‹Ã’mdñ„]�8Î̱r¯�éúë$Ÿ5îyôÅ1™ú&àv(WØáñªLŽe½pò‰õTàb{´ŠÄB!ð¸YRE!ɾdä\ÁÔ|
+Äôò}	0á·Ï<ðx­×³5(©²ÓÇXõ̼‰h8�L©�m¢Í°]ºÓŒx$“
+­�u|Ðí8t^ˆš/€‹MÝp­_’<{*ñ>Jn
ÐÅ—6¹s²R¯aÆ‹úr×�€]9ä¯:²(`\‰áÉlA7¾ĦK”ž·†9z8nb64Ë¢jE¢$µ1V|·ZBËÐöX#Y»ͪföWßqYûlf/ö»­8Fj…›ë_X1¡ÁèínÕ
(N1©þ¢CÑð´ýÆ9(AÄEêÞ–«ôáÃÉ€ÖÜÑf}_�¢£J¾:¤ íéJ$<ÂBÿˆSUÅö�
ìMø›Yr¤˜¾�ÃÈ×`Qí�å?›�Ù±Vƒ�ÝŽˆ½¸ÂˆÚÖñhÃÙƒXÔ‡7Ó¶,Í!Á•FÿÁEè^F¸¯xÀÁ¦ÿàB*·ÛvªR&¤N�<•ê`¢µ+çN¼é
¬
+g¤£Ê¾2f~mû„�m}…i
+'óP4I×¥ŸÐ?`b¬FH.�÷R}ÿÀ#]«i�ÀAñ7FÌÐ5øùq6O‰Ç/êúWbõÑF�åq-¢´ð
§]xžök%˜Ã–td˜¯‘ŒÎ¼r¿
+ä&oH[œ¯A•9f
 endobj
-682 0 obj <<
+726 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 1930 0 R
+/Encoding 2092 0 R
 /FirstChar 2
 /LastChar 216
-/Widths 1944 0 R
-/BaseFont /NUKCNW+URWPalladioL-Roma
-/FontDescriptor 680 0 R
+/Widths 2107 0 R
+/BaseFont /WWIPFK+URWPalladioL-Roma
+/FontDescriptor 724 0 R
 >> endobj
-680 0 obj <<
+724 0 obj <<
 /Ascent 715
 /CapHeight 680
 /Descent -282
-/FontName /NUKCNW+URWPalladioL-Roma
+/FontName /WWIPFK+URWPalladioL-Roma
 /ItalicAngle 0
 /StemV 84
 /XHeight 469
 /FontBBox [-166 -283 1021 943]
 /Flags 4
-/CharSet (/fi/fl/exclam/numbersign/dollar/percent/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/equal/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/bracketright/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/circumflex/quotedblright/emdash/Oslash)
-/FontFile 681 0 R
+/CharSet (/fi/fl/exclam/numbersign/dollar/percent/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/equal/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/bracketright/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/circumflex/quotedblright/endash/emdash/Oslash)
+/FontFile 725 0 R
 >> endobj
-1944 0 obj
-[605 608 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 278 0 500 500 840 0 278 333 333 389 606 250 333 250 606 500 500 500 500 500 500 500 500 500 500 250 250 0 606 0 444 747 778 611 709 774 611 556 763 832 337 333 726 611 946 831 786 604 786 668 525 613 778 722 1000 667 667 667 333 0 333 0 0 278 500 553 444 611 479 333 556 582 291 234 556 291 883 582 546 601 560 395 424 326 603 565 834 516 556 500 0 0 0 0 0 0 0 0 0 0 0 0 0 333 0 0 0 0 0 0 0 0 0 0 0 500 0 0 1000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 833 ]
+2107 0 obj
+[605 608 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 278 0 500 500 840 0 278 333 333 389 606 250 333 250 606 500 500 500 500 500 500 500 500 500 500 250 250 0 606 0 444 747 778 611 709 774 611 556 763 832 337 333 726 611 946 831 786 604 786 668 525 613 778 722 1000 667 667 667 333 0 333 0 0 278 500 553 444 611 479 333 556 582 291 234 556 291 883 582 546 601 560 395 424 326 603 565 834 516 556 500 0 0 0 0 0 0 0 0 0 0 0 0 0 333 0 0 0 0 0 0 0 0 0 0 0 500 0 500 1000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 833 ]
 endobj
-657 0 obj <<
+701 0 obj <<
 /Length1 1614
 /Length2 24766
 /Length3 532
@@ -9526,7 +10435,7 @@ endobj
 /Filter /FlateDecode
 >>
 stream
-xÚ¬zS�m]³eÙ¶]uʶmÛ¶mÛö)Û¶mÛæ)ó”«ëû¯:n÷S÷}Xkfæ92GÎ{G,RBy%
c;CQ;[gZzNE5ykkc;iA;kc‚3)©�£‰�³…�­°�³	'�š‰1�°‰
##
)���½‡£…™¹3
ùõYþ	!0ôøÏÏN'3[²ŸWk;{[çˆÿç�J&&Îæ&¦Ö&Brò²bäb²*b&¶&ŽÖò.†ÖFÒF&¶N&¦vŽÖÿ¶ 0²³5¶ø§4'Ú,
''{#‹Ÿm&îF&öÿ¸¨	ìMm,œœ~Þ	,œÌ
l�zàlG`akdíbü�»©Ý¿Ù;ÚýDØüø~Àä휜�Œ-ì�	~²Ê‹þOgsçr;Yü¸	ìL"�íŒ\þ)é_¾˜¯³�…­�³‰»ó?¹MŒ-œì­
<~rÿ€Ù;Zü‹†‹“…­Ù1 &p413p4¶6qrú�ùÁþ§;ÿU'ÁÿV½�½½µÇ¿vÛý+ê?9X8;™X›ÒB10þä4rþÉmfaE÷ϨHØšÚ0Ðÿ›ÝØÅþ?|®&Žÿjù?3CñCÂÀØÎÖÚƒÀØÄŠNÖÎù'%
ùÿ›Ê´ÿs"ÿHü?"ðÿˆ¼ÿâþw�þ·Cüÿ{žÿ;´¨‹µµ¬��É¿6üÇC MðÏ%óØXX{üßÂÿ{¤šÉ¿qü¿¡H8ü4BÀÖìGzZú3Z8‰Z¸›Ë[8™˜Xÿté_v[cGk[“5ÿÕHzúÿæS6·0²²ý§í,ÿæ2±5þïÔúq:)EMYqªÿóFýWœü�òÎÊö?Ôþ½;ãÿ\üƒ"(hçNàEÃÀÂH@ÃDÏðsà~øp0±øü_2þˆá¿Ö2ÎŽîZ?eÿìü§øþk¥óß`Dl�ìŒÿ™%g[ãŸñúOÃ?n#GÇUÿuâŠþ�õ¿ÝÄÄÝÄj}ÅΈ+Ø2ýw†szîÈ”°Ö@ðHˆ}i£rQ��]¯_zøG¥þGmmÓçW»ÇòûÏ#IÊã±>4ë_½©&×ù8>ÄýˆÛd�lTÇ�tº¥°jÑ^7KÒ» š¬ôªÇûS
+xÚ¬zS�m]³eÙ¶]uʶmÛ¶mÛö)Û¶mÛæ)ó”«ëû¯:n÷S÷}Xkfæ92GÎ{G,RBy%
c;CQ;[gZzNE5ykkc;iA;kc‚3)©�£‰�³…�­°�³	'�š‰1�°‰
##
)���½‡£…™¹3
ùõYþ	!0ôøÏÏN'3[²ŸWk;{[çˆÿç�J&&Îæ&¦Ö&Brò²bäb²*b&¶&ŽÖò.†ÖFÒF&¶N&¦vŽÖÿ¶ 0²³5¶ø§4'Ú,
''{#‹Ÿm&îF&öÿ¸¨	ìMm,œœ~Þ	,œÌ
l�zàlG`akdíbü�»©Ý¿Ù;ÚýDØüø~Àä휜�Œ-ì�	~²Ê‹þOgsçr;Yü¸	ìL"�íŒ\þ)é_¾˜¯³�…­�³‰»ó?¹MŒ-œì­
<~rÿ€Ù;Zü‹†‹“…­Ù1 &p413p4¶6qrú�ùÁþ§;ÿU'ÁÿV½�½½µÇ¿vÛý+ê?9X8;™X›ÒB10þä4rþÉmfaE÷ϨHØšÚ0Ðÿ›ÝØÅþ?|®&Žÿjù?3CñCÂÀØÎÖÚƒÀØÄŠNÖÎù'%
ùÿ›Ê´ÿs"ÿHü?"ðÿˆ¼ÿâþw�þ·Cüÿ{žÿ;´¨‹µµ¬��É¿6üÇC MðÏ%óØXX{üßÂÿ{¤šÉ¿qü¿¡H8ü4BÀÖìGzZú3Z8‰Z¸›Ë[8™˜Xÿté_v[cGk[“5ÿÕHzúÿæS6·0²²ý§í,ÿæ2±5þïÔúq:MAaQiªÿóFýWœü�òÎÊö?Ôþ½;ãÿ\üƒ"(hçNàEÃÀÂH@ÃDÏðsà~øp0±øü_2þˆá¿Ö2ÎŽîZ?eÿìü§øþk¥óß`Dl�ìŒÿ™%g[ãŸñúOÃ?n#GÇUÿuâŠþ�õ¿ÝÄÄÝÄj}ÅΈ+Ø2ýw†szîÈ”°Ö@ðHˆ}i£rQ��]¯_zøG¥þGmmÓçW»ÇòûÏ#IÊã±>4ë_½©&×ù8>ÄýˆÛd�lTÇ�tº¥°jÑ^7KÒ» š¬ôªÇûS
 Šº%`¸3�LŽ7)ü‰]üQHžíá|�ÒâP»š
 ÿ\�%�ý}þ54>:2Ü{Ú„M•IÊå
 Kåï�ƒÍ§©R!RÕDzÝžeÌ}øØ"œ³\ʤ!g?5íµ	Îk“T$f}QìŒ}}œ7Ãë–aI­zQ£Ø`�{1®ËÊ›¡9sõ‰ór5úË<#¤=ø…ˆ´±36…è4Ó+òŽÇ¾a‘Ïp:‰é"“|:[5P6“Ó<M`IÍÍÍLÕ‘˜‡‰ŠŒDa_gÁ¡Ãœá½]é–§	9ç8sêÓšÆô e¬bô:miØ*N±«z|+hytHOÛV77Ùa‰
@@ -9625,541 +10534,638 @@ Iö×~pºóE¦f}^!˜tQ°Ù’‹ƒEäì>‰ n|'ÆV²5D9_äå‹7â̬FJvõ˜2È­ÛŒ’ý;Û£K¿>Z&ú‰Àš¤þØɉ,
 y‘üP'càÜ^M#R°·ñÃ4
{LJB«œ»×ën¾HïŸMc–9|þ*S5ïV®ñKãÁ“ü�vÚJ¦‰‡’à°áR‹ÁPKw©ä;ÉͳðåH-ºOÖ²ÉâØÉ*Wü—¼éýšö•p…+èó®a7AÔºº;˜âR·~4ÿÕ|S®‘mƒ®W•~	©Ãâ‡}DL×WF5J‰åéØ|¨i÷>#\2®˜
 šÒ30D”€`Ÿ†§¾ç�4}&1xÒ¤Ö¥	ÎdP•Ý‹$ȾCO‡Ù’jÛvëö?`C&W'aÔCJ•I'sŠFðìM˼k©¡¨»°+X	ŠcAÐÀ«á¥£ùr!<s%!ÈbˆÀNÑ*d3³Ê6�†Ø0´+3ïÍNYÀ8�îj•ÛP³7Þ¨VäÎc=$0€Ž9€òõ
«£…WCÒ¸1å
Ô²9L±ž±~óŸ–äWÚyüInÐäöÀ'¼I3
ú]`+ò7vÃÝ!�’ÔËö—k«Zœ–(&4¨j�„¸`é+àpôxÿÅë«SüWâ$åM7ƒ[IZÒýš®ê~‚VƒÍ:Ø\é«…Œ
€Øy_à£öý
 .ÈëÃ6‹û¯™ÅSßcŽ¾Q&É5	fd
-ön’“,6"”@K;\ÿŸÁüø¯
+ön’“,6"”@K;\ÿŸÁüø¯
 endobj
-658 0 obj <<
+702 0 obj <<
 /Type /Font
 /Subtype /Type1
-/Encoding 1930 0 R
+/Encoding 2092 0 R
 /FirstChar 2
 /LastChar 151
-/Widths 1945 0 R
-/BaseFont /KRZENH+URWPalladioL-Bold
-/FontDescriptor 656 0 R
+/Widths 2108 0 R
+/BaseFont /ZBDFML+URWPalladioL-Bold
+/FontDescriptor 700 0 R
 >> endobj
-656 0 obj <<
+700 0 obj <<
 /Ascent 708
 /CapHeight 672
 /Descent -266
-/FontName /KRZENH+URWPalladioL-Bold
+/FontName /ZBDFML+URWPalladioL-Bold
 /ItalicAngle 0
 /StemV 123
 /XHeight 471
 /FontBBox [-152 -301 1000 935]
 /Flags 4
 /CharSet (/fi/fl/exclam/dollar/percent/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon/semicolon/question/at/A/B/C/D/E/F/G/H/I/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/bracketright/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/quotedblright/emdash)
-/FontFile 657 0 R
+/FontFile 701 0 R
 >> endobj
-1945 0 obj
+2108 0 obj
 [611 611 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 278 0 0 500 889 0 278 333 333 444 606 250 333 250 296 500 500 500 500 500 500 500 500 500 500 250 250 0 0 0 444 747 778 667 722 833 611 556 833 833 389 0 778 611 1000 833 833 611 833 722 611 667 778 778 1000 667 667 667 333 0 333 0 0 0 500 611 444 611 500 389 556 611 333 333 611 333 889 611 556 611 611 389 444 333 611 556 833 500 556 500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 500 0 0 1000 ]
 endobj
-659 0 obj <<
+703 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1946 0 R
-/Kids [650 0 R 677 0 R 687 0 R 742 0 R 806 0 R 867 0 R]
+/Parent 2109 0 R
+/Kids [694 0 R 721 0 R 731 0 R 786 0 R 850 0 R 912 0 R]
 >> endobj
-886 0 obj <<
+941 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1946 0 R
-/Kids [871 0 R 888 0 R 902 0 R 913 0 R 920 0 R 932 0 R]
+/Parent 2109 0 R
+/Kids [929 0 R 943 0 R 957 0 R 968 0 R 975 0 R 987 0 R]
 >> endobj
-944 0 obj <<
+999 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1946 0 R
-/Kids [937 0 R 946 0 R 957 0 R 965 0 R 972 0 R 978 0 R]
+/Parent 2109 0 R
+/Kids [992 0 R 1001 0 R 1012 0 R 1020 0 R 1027 0 R 1033 0 R]
 >> endobj
-1001 0 obj <<
+1056 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1946 0 R
-/Kids [986 0 R 1008 0 R 1018 0 R 1023 0 R 1027 0 R 1034 0 R]
+/Parent 2109 0 R
+/Kids [1041 0 R 1063 0 R 1073 0 R 1078 0 R 1082 0 R 1089 0 R]
 >> endobj
-1050 0 obj <<
+1105 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1946 0 R
-/Kids [1043 0 R 1053 0 R 1060 0 R 1065 0 R 1074 0 R 1081 0 R]
+/Parent 2109 0 R
+/Kids [1097 0 R 1108 0 R 1115 0 R 1120 0 R 1129 0 R 1136 0 R]
 >> endobj
-1093 0 obj <<
+1148 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1946 0 R
-/Kids [1085 0 R 1096 0 R 1101 0 R 1110 0 R 1117 0 R 1126 0 R]
+/Parent 2109 0 R
+/Kids [1140 0 R 1151 0 R 1156 0 R 1164 0 R 1172 0 R 1181 0 R]
 >> endobj
-1145 0 obj <<
+1199 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1947 0 R
-/Kids [1136 0 R 1147 0 R 1152 0 R 1158 0 R 1164 0 R 1172 0 R]
+/Parent 2110 0 R
+/Kids [1189 0 R 1201 0 R 1207 0 R 1213 0 R 1219 0 R 1223 0 R]
 >> endobj
-1182 0 obj <<
+1237 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1947 0 R
-/Kids [1179 0 R 1184 0 R 1189 0 R 1195 0 R 1199 0 R 1205 0 R]
+/Parent 2110 0 R
+/Kids [1234 0 R 1239 0 R 1243 0 R 1248 0 R 1254 0 R 1258 0 R]
 >> endobj
-1219 0 obj <<
+1273 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1947 0 R
-/Kids [1216 0 R 1221 0 R 1225 0 R 1235 0 R 1243 0 R 1248 0 R]
+/Parent 2110 0 R
+/Kids [1265 0 R 1276 0 R 1280 0 R 1284 0 R 1294 0 R 1301 0 R]
 >> endobj
-1255 0 obj <<
+1310 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1947 0 R
-/Kids [1252 0 R 1257 0 R 1263 0 R 1271 0 R 1277 0 R 1284 0 R]
+/Parent 2110 0 R
+/Kids [1307 0 R 1312 0 R 1316 0 R 1320 0 R 1328 0 R 1334 0 R]
 >> endobj
-1296 0 obj <<
+1346 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1947 0 R
-/Kids [1291 0 R 1298 0 R 1310 0 R 1315 0 R 1321 0 R 1326 0 R]
+/Parent 2110 0 R
+/Kids [1340 0 R 1348 0 R 1356 0 R 1361 0 R 1373 0 R 1378 0 R]
 >> endobj
-1339 0 obj <<
+1388 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1947 0 R
-/Kids [1331 0 R 1341 0 R 1345 0 R 1349 0 R 1353 0 R 1361 0 R]
+/Parent 2110 0 R
+/Kids [1382 0 R 1390 0 R 1395 0 R 1404 0 R 1408 0 R 1412 0 R]
 >> endobj
-1382 0 obj <<
+1423 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1948 0 R
-/Kids [1366 0 R 1384 0 R 1399 0 R 1414 0 R 1424 0 R 1430 0 R]
+/Parent 2111 0 R
+/Kids [1416 0 R 1425 0 R 1430 0 R 1449 0 R 1462 0 R 1482 0 R]
 >> endobj
-1445 0 obj <<
+1499 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1948 0 R
-/Kids [1436 0 R 1447 0 R 1459 0 R 1468 0 R 1474 0 R 1478 0 R]
+/Parent 2111 0 R
+/Kids [1488 0 R 1501 0 R 1505 0 R 1511 0 R 1521 0 R 1533 0 R]
 >> endobj
-1487 0 obj <<
+1547 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1948 0 R
-/Kids [1482 0 R 1489 0 R 1500 0 R 1504 0 R 1508 0 R 1519 0 R]
+/Parent 2111 0 R
+/Kids [1541 0 R 1549 0 R 1557 0 R 1565 0 R 1574 0 R 1583 0 R]
 >> endobj
-1529 0 obj <<
+1592 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1948 0 R
-/Kids [1523 0 R 1531 0 R 1541 0 R 1600 0 R 1656 0 R 1710 0 R]
+/Parent 2111 0 R
+/Kids [1587 0 R 1594 0 R 1605 0 R 1609 0 R 1613 0 R 1624 0 R]
 >> endobj
-1752 0 obj <<
+1634 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1948 0 R
-/Kids [1744 0 R 1754 0 R 1760 0 R 1765 0 R 1769 0 R 1774 0 R]
+/Parent 2111 0 R
+/Kids [1628 0 R 1636 0 R 1646 0 R 1705 0 R 1761 0 R 1815 0 R]
 >> endobj
-1789 0 obj <<
+1857 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1948 0 R
-/Kids [1786 0 R 1791 0 R 1803 0 R 1808 0 R 1819 0 R 1824 0 R]
+/Parent 2111 0 R
+/Kids [1849 0 R 1859 0 R 1865 0 R 1870 0 R 1874 0 R 1879 0 R]
 >> endobj
-1839 0 obj <<
+1894 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1949 0 R
-/Kids [1829 0 R 1841 0 R 1853 0 R 1857 0 R 1868 0 R 1873 0 R]
+/Parent 2112 0 R
+/Kids [1890 0 R 1896 0 R 1908 0 R 1919 0 R 1926 0 R 1938 0 R]
 >> endobj
-1889 0 obj <<
+1952 0 obj <<
 /Type /Pages
 /Count 6
-/Parent 1949 0 R
-/Kids [1878 0 R 1891 0 R 1901 0 R 1908 0 R 1915 0 R 1924 0 R]
+/Parent 2112 0 R
+/Kids [1942 0 R 1954 0 R 1960 0 R 1964 0 R 1974 0 R 1986 0 R]
 >> endobj
-1946 0 obj <<
+1998 0 obj <<
+/Type /Pages
+/Count 6
+/Parent 2112 0 R
+/Kids [1992 0 R 2000 0 R 2009 0 R 2013 0 R 2024 0 R 2030 0 R]
+>> endobj
+2039 0 obj <<
+/Type /Pages
+/Count 6
+/Parent 2112 0 R
+/Kids [2035 0 R 2041 0 R 2053 0 R 2063 0 R 2069 0 R 2078 0 R]
+>> endobj
+2091 0 obj <<
+/Type /Pages
+/Count 1
+/Parent 2112 0 R
+/Kids [2085 0 R]
+>> endobj
+2109 0 obj <<
 /Type /Pages
 /Count 36
-/Parent 1950 0 R
-/Kids [659 0 R 886 0 R 944 0 R 1001 0 R 1050 0 R 1093 0 R]
+/Parent 2113 0 R
+/Kids [703 0 R 941 0 R 999 0 R 1056 0 R 1105 0 R 1148 0 R]
 >> endobj
-1947 0 obj <<
+2110 0 obj <<
 /Type /Pages
 /Count 36
-/Parent 1950 0 R
-/Kids [1145 0 R 1182 0 R 1219 0 R 1255 0 R 1296 0 R 1339 0 R]
+/Parent 2113 0 R
+/Kids [1199 0 R 1237 0 R 1273 0 R 1310 0 R 1346 0 R 1388 0 R]
 >> endobj
-1948 0 obj <<
+2111 0 obj <<
 /Type /Pages
 /Count 36
-/Parent 1950 0 R
-/Kids [1382 0 R 1445 0 R 1487 0 R 1529 0 R 1752 0 R 1789 0 R]
+/Parent 2113 0 R
+/Kids [1423 0 R 1499 0 R 1547 0 R 1592 0 R 1634 0 R 1857 0 R]
 >> endobj
-1949 0 obj <<
+2112 0 obj <<
 /Type /Pages
-/Count 12
-/Parent 1950 0 R
-/Kids [1839 0 R 1889 0 R]
+/Count 25
+/Parent 2113 0 R
+/Kids [1894 0 R 1952 0 R 1998 0 R 2039 0 R 2091 0 R]
 >> endobj
-1950 0 obj <<
+2113 0 obj <<
 /Type /Pages
-/Count 120
-/Kids [1946 0 R 1947 0 R 1948 0 R 1949 0 R]
+/Count 133
+/Kids [2109 0 R 2110 0 R 2111 0 R 2112 0 R]
 >> endobj
-1951 0 obj <<
+2114 0 obj <<
 /Type /Outlines
 /First 7 0 R
-/Last 607 0 R
+/Last 639 0 R
 /Count 10
 >> endobj
+691 0 obj <<
+/Title 692 0 R
+/A 689 0 R
+/Parent 639 0 R
+/Prev 687 0 R
+>> endobj
+687 0 obj <<
+/Title 688 0 R
+/A 685 0 R
+/Parent 639 0 R
+/Prev 683 0 R
+/Next 691 0 R
+>> endobj
+683 0 obj <<
+/Title 684 0 R
+/A 681 0 R
+/Parent 639 0 R
+/Prev 679 0 R
+/Next 687 0 R
+>> endobj
+679 0 obj <<
+/Title 680 0 R
+/A 677 0 R
+/Parent 639 0 R
+/Prev 675 0 R
+/Next 683 0 R
+>> endobj
+675 0 obj <<
+/Title 676 0 R
+/A 673 0 R
+/Parent 639 0 R
+/Prev 671 0 R
+/Next 679 0 R
+>> endobj
+671 0 obj <<
+/Title 672 0 R
+/A 669 0 R
+/Parent 639 0 R
+/Prev 667 0 R
+/Next 675 0 R
+>> endobj
+667 0 obj <<
+/Title 668 0 R
+/A 665 0 R
+/Parent 639 0 R
+/Prev 663 0 R
+/Next 671 0 R
+>> endobj
+663 0 obj <<
+/Title 664 0 R
+/A 661 0 R
+/Parent 639 0 R
+/Prev 659 0 R
+/Next 667 0 R
+>> endobj
+659 0 obj <<
+/Title 660 0 R
+/A 657 0 R
+/Parent 639 0 R
+/Prev 655 0 R
+/Next 663 0 R
+>> endobj
+655 0 obj <<
+/Title 656 0 R
+/A 653 0 R
+/Parent 639 0 R
+/Prev 651 0 R
+/Next 659 0 R
+>> endobj
+651 0 obj <<
+/Title 652 0 R
+/A 649 0 R
+/Parent 639 0 R
+/Prev 647 0 R
+/Next 655 0 R
+>> endobj
 647 0 obj <<
 /Title 648 0 R
 /A 645 0 R
-/Parent 607 0 R
+/Parent 639 0 R
 /Prev 643 0 R
+/Next 651 0 R
 >> endobj
 643 0 obj <<
 /Title 644 0 R
 /A 641 0 R
-/Parent 607 0 R
-/Prev 639 0 R
+/Parent 639 0 R
 /Next 647 0 R
 >> endobj
 639 0 obj <<
 /Title 640 0 R
 /A 637 0 R
-/Parent 607 0 R
-/Prev 635 0 R
-/Next 643 0 R
+/Parent 2114 0 R
+/Prev 603 0 R
+/First 643 0 R
+/Last 691 0 R
+/Count -13
 >> endobj
 635 0 obj <<
 /Title 636 0 R
 /A 633 0 R
-/Parent 607 0 R
+/Parent 623 0 R
 /Prev 631 0 R
-/Next 639 0 R
 >> endobj
 631 0 obj <<
 /Title 632 0 R
 /A 629 0 R
-/Parent 607 0 R
+/Parent 623 0 R
 /Prev 627 0 R
 /Next 635 0 R
 >> endobj
 627 0 obj <<
 /Title 628 0 R
 /A 625 0 R
-/Parent 607 0 R
-/Prev 623 0 R
+/Parent 623 0 R
 /Next 631 0 R
 >> endobj
 623 0 obj <<
 /Title 624 0 R
 /A 621 0 R
-/Parent 607 0 R
-/Prev 619 0 R
-/Next 627 0 R
+/Parent 603 0 R
+/Prev 615 0 R
+/First 627 0 R
+/Last 635 0 R
+/Count -3
 >> endobj
 619 0 obj <<
 /Title 620 0 R
 /A 617 0 R
-/Parent 607 0 R
-/Prev 615 0 R
-/Next 623 0 R
+/Parent 615 0 R
 >> endobj
 615 0 obj <<
 /Title 616 0 R
 /A 613 0 R
-/Parent 607 0 R
-/Prev 611 0 R
-/Next 619 0 R
+/Parent 603 0 R
+/Prev 607 0 R
+/Next 623 0 R
+/First 619 0 R
+/Last 619 0 R
+/Count -1
 >> endobj
 611 0 obj <<
 /Title 612 0 R
 /A 609 0 R
 /Parent 607 0 R
-/Next 615 0 R
 >> endobj
 607 0 obj <<
 /Title 608 0 R
 /A 605 0 R
-/Parent 1951 0 R
-/Prev 571 0 R
+/Parent 603 0 R
+/Next 615 0 R
 /First 611 0 R
-/Last 647 0 R
-/Count -10
+/Last 611 0 R
+/Count -1
 >> endobj
 603 0 obj <<
 /Title 604 0 R
 /A 601 0 R
-/Parent 591 0 R
-/Prev 599 0 R
+/Parent 2114 0 R
+/Prev 583 0 R
+/Next 639 0 R
+/First 607 0 R
+/Last 623 0 R
+/Count -3
 >> endobj
 599 0 obj <<
 /Title 600 0 R
 /A 597 0 R
-/Parent 591 0 R
+/Parent 583 0 R
 /Prev 595 0 R
-/Next 603 0 R
 >> endobj
 595 0 obj <<
 /Title 596 0 R
 /A 593 0 R
-/Parent 591 0 R
+/Parent 583 0 R
+/Prev 587 0 R
 /Next 599 0 R
 >> endobj
 591 0 obj <<
 /Title 592 0 R
 /A 589 0 R
-/Parent 571 0 R
-/Prev 583 0 R
-/First 595 0 R
-/Last 603 0 R
-/Count -3
+/Parent 587 0 R
 >> endobj
 587 0 obj <<
 /Title 588 0 R
 /A 585 0 R
 /Parent 583 0 R
+/Next 595 0 R
+/First 591 0 R
+/Last 591 0 R
+/Count -1
 >> endobj
 583 0 obj <<
 /Title 584 0 R
 /A 581 0 R
-/Parent 571 0 R
-/Prev 575 0 R
-/Next 591 0 R
+/Parent 2114 0 R
+/Prev 559 0 R
+/Next 603 0 R
 /First 587 0 R
-/Last 587 0 R
-/Count -1
+/Last 599 0 R
+/Count -3
 >> endobj
 579 0 obj <<
 /Title 580 0 R
 /A 577 0 R
-/Parent 575 0 R
+/Parent 559 0 R
+/Prev 567 0 R
 >> endobj
 575 0 obj <<
 /Title 576 0 R
 /A 573 0 R
-/Parent 571 0 R
-/Next 583 0 R
-/First 579 0 R
-/Last 579 0 R
-/Count -1
+/Parent 567 0 R
+/Prev 571 0 R
 >> endobj
 571 0 obj <<
 /Title 572 0 R
 /A 569 0 R
-/Parent 1951 0 R
-/Prev 551 0 R
-/Next 607 0 R
-/First 575 0 R
-/Last 591 0 R
-/Count -3
+/Parent 567 0 R
+/Next 575 0 R
 >> endobj
 567 0 obj <<
 /Title 568 0 R
 /A 565 0 R
-/Parent 551 0 R
+/Parent 559 0 R
 /Prev 563 0 R
+/Next 579 0 R
+/First 571 0 R
+/Last 575 0 R
+/Count -2
 >> endobj
 563 0 obj <<
 /Title 564 0 R
 /A 561 0 R
-/Parent 551 0 R
-/Prev 555 0 R
+/Parent 559 0 R
 /Next 567 0 R
 >> endobj
 559 0 obj <<
 /Title 560 0 R
 /A 557 0 R
-/Parent 555 0 R
+/Parent 2114 0 R
+/Prev 243 0 R
+/Next 583 0 R
+/First 563 0 R
+/Last 579 0 R
+/Count -3
 >> endobj
 555 0 obj <<
 /Title 556 0 R
 /A 553 0 R
-/Parent 551 0 R
-/Next 563 0 R
-/First 559 0 R
-/Last 559 0 R
-/Count -1
+/Parent 539 0 R
+/Prev 551 0 R
 >> endobj
 551 0 obj <<
 /Title 552 0 R
 /A 549 0 R
-/Parent 1951 0 R
-/Prev 527 0 R
-/Next 571 0 R
-/First 555 0 R
-/Last 567 0 R
-/Count -3
+/Parent 539 0 R
+/Prev 547 0 R
+/Next 555 0 R
 >> endobj
 547 0 obj <<
 /Title 548 0 R
 /A 545 0 R
-/Parent 527 0 R
-/Prev 535 0 R
+/Parent 539 0 R
+/Prev 543 0 R
+/Next 551 0 R
 >> endobj
 543 0 obj <<
 /Title 544 0 R
 /A 541 0 R
-/Parent 535 0 R
-/Prev 539 0 R
+/Parent 539 0 R
+/Next 547 0 R
 >> endobj
 539 0 obj <<
 /Title 540 0 R
 /A 537 0 R
-/Parent 535 0 R
-/Next 543 0 R
+/Parent 531 0 R
+/Prev 535 0 R
+/First 543 0 R
+/Last 555 0 R
+/Count -4
 >> endobj
 535 0 obj <<
 /Title 536 0 R
 /A 533 0 R
-/Parent 527 0 R
-/Prev 531 0 R
-/Next 547 0 R
-/First 539 0 R
-/Last 543 0 R
-/Count -2
+/Parent 531 0 R
+/Next 539 0 R
 >> endobj
 531 0 obj <<
 /Title 532 0 R
 /A 529 0 R
-/Parent 527 0 R
-/Next 535 0 R
+/Parent 243 0 R
+/Prev 479 0 R
+/First 535 0 R
+/Last 539 0 R
+/Count -2
 >> endobj
 527 0 obj <<
 /Title 528 0 R
 /A 525 0 R
-/Parent 1951 0 R
-/Prev 243 0 R
-/Next 551 0 R
-/First 531 0 R
-/Last 547 0 R
-/Count -3
+/Parent 479 0 R
+/Prev 523 0 R
 >> endobj
 523 0 obj <<
 /Title 524 0 R
 /A 521 0 R
-/Parent 475 0 R
-/Prev 519 0 R
+/Parent 479 0 R
+/Prev 507 0 R
+/Next 527 0 R
 >> endobj
 519 0 obj <<
 /Title 520 0 R
 /A 517 0 R
-/Parent 475 0 R
-/Prev 503 0 R
-/Next 523 0 R
+/Parent 507 0 R
+/Prev 515 0 R
 >> endobj
 515 0 obj <<
 /Title 516 0 R
 /A 513 0 R
-/Parent 503 0 R
+/Parent 507 0 R
 /Prev 511 0 R
+/Next 519 0 R
 >> endobj
 511 0 obj <<
 /Title 512 0 R
 /A 509 0 R
-/Parent 503 0 R
-/Prev 507 0 R
+/Parent 507 0 R
 /Next 515 0 R
 >> endobj
 507 0 obj <<
 /Title 508 0 R
 /A 505 0 R
-/Parent 503 0 R
-/Next 511 0 R
+/Parent 479 0 R
+/Prev 503 0 R
+/Next 523 0 R
+/First 511 0 R
+/Last 519 0 R
+/Count -3
 >> endobj
 503 0 obj <<
 /Title 504 0 R
 /A 501 0 R
-/Parent 475 0 R
+/Parent 479 0 R
 /Prev 499 0 R
-/Next 519 0 R
-/First 507 0 R
-/Last 515 0 R
-/Count -3
+/Next 507 0 R
 >> endobj
 499 0 obj <<
 /Title 500 0 R
 /A 497 0 R
-/Parent 475 0 R
+/Parent 479 0 R
 /Prev 495 0 R
 /Next 503 0 R
 >> endobj
 495 0 obj <<
 /Title 496 0 R
 /A 493 0 R
-/Parent 475 0 R
-/Prev 491 0 R
+/Parent 479 0 R
+/Prev 483 0 R
 /Next 499 0 R
 >> endobj
 491 0 obj <<
 /Title 492 0 R
 /A 489 0 R
-/Parent 475 0 R
-/Prev 479 0 R
-/Next 495 0 R
+/Parent 483 0 R
+/Prev 487 0 R
 >> endobj
 487 0 obj <<
 /Title 488 0 R
 /A 485 0 R
-/Parent 479 0 R
-/Prev 483 0 R
+/Parent 483 0 R
+/Next 491 0 R
 >> endobj
 483 0 obj <<
 /Title 484 0 R
 /A 481 0 R
 /Parent 479 0 R
-/Next 487 0 R
+/Next 495 0 R
+/First 487 0 R
+/Last 491 0 R
+/Count -2
 >> endobj
 479 0 obj <<
 /Title 480 0 R
 /A 477 0 R
-/Parent 475 0 R
-/Next 491 0 R
+/Parent 243 0 R
+/Prev 275 0 R
+/Next 531 0 R
 /First 483 0 R
-/Last 487 0 R
-/Count -2
+/Last 527 0 R
+/Count -7
 >> endobj
 475 0 obj <<
 /Title 476 0 R
 /A 473 0 R
-/Parent 243 0 R
-/Prev 275 0 R
-/First 479 0 R
-/Last 523 0 R
-/Count -7
+/Parent 459 0 R
+/Prev 471 0 R
 >> endobj
 471 0 obj <<
 /Title 472 0 R
 /A 469 0 R
-/Parent 455 0 R
+/Parent 459 0 R
 /Prev 467 0 R
+/Next 475 0 R
 >> endobj
 467 0 obj <<
 /Title 468 0 R
 /A 465 0 R
-/Parent 455 0 R
+/Parent 459 0 R
 /Prev 463 0 R
 /Next 471 0 R
 >> endobj
 463 0 obj <<
 /Title 464 0 R
 /A 461 0 R
-/Parent 455 0 R
-/Prev 459 0 R
+/Parent 459 0 R
 /Next 467 0 R
 >> endobj
 459 0 obj <<
 /Title 460 0 R
 /A 457 0 R
-/Parent 455 0 R
-/Next 463 0 R
+/Parent 275 0 R
+/Prev 455 0 R
+/First 463 0 R
+/Last 475 0 R
+/Count -4
 >> endobj
 455 0 obj <<
 /Title 456 0 R
 /A 453 0 R
 /Parent 275 0 R
 /Prev 451 0 R
-/First 459 0 R
-/Last 471 0 R
-/Count -4
+/Next 459 0 R
 >> endobj
 451 0 obj <<
 /Title 452 0 R
@@ -10207,21 +11213,21 @@ endobj
 /Title 428 0 R
 /A 425 0 R
 /Parent 275 0 R
-/Prev 347 0 R
+/Prev 423 0 R
 /Next 431 0 R
 >> endobj
 423 0 obj <<
 /Title 424 0 R
 /A 421 0 R
-/Parent 347 0 R
-/Prev 419 0 R
+/Parent 275 0 R
+/Prev 347 0 R
+/Next 427 0 R
 >> endobj
 419 0 obj <<
 /Title 420 0 R
 /A 417 0 R
 /Parent 347 0 R
 /Prev 415 0 R
-/Next 423 0 R
 >> endobj
 415 0 obj <<
 /Title 416 0 R
@@ -10346,10 +11352,10 @@ endobj
 /A 345 0 R
 /Parent 275 0 R
 /Prev 343 0 R
-/Next 427 0 R
+/Next 423 0 R
 /First 351 0 R
-/Last 423 0 R
-/Count -19
+/Last 419 0 R
+/Count -18
 >> endobj
 343 0 obj <<
 /Title 344 0 R
@@ -10475,10 +11481,10 @@ endobj
 /A 273 0 R
 /Parent 243 0 R
 /Prev 247 0 R
-/Next 475 0 R
+/Next 479 0 R
 /First 279 0 R
-/Last 455 0 R
-/Count -24
+/Last 459 0 R
+/Count -26
 >> endobj
 271 0 obj <<
 /Title 272 0 R
@@ -10534,12 +11540,12 @@ endobj
 243 0 obj <<
 /Title 244 0 R
 /A 241 0 R
-/Parent 1951 0 R
+/Parent 2114 0 R
 /Prev 231 0 R
-/Next 527 0 R
+/Next 559 0 R
 /First 247 0 R
-/Last 475 0 R
-/Count -3
+/Last 531 0 R
+/Count -4
 >> endobj
 239 0 obj <<
 /Title 240 0 R
@@ -10556,7 +11562,7 @@ endobj
 231 0 obj <<
 /Title 232 0 R
 /A 229 0 R
-/Parent 1951 0 R
+/Parent 2114 0 R
 /Prev 131 0 R
 /Next 243 0 R
 /First 235 0 R
@@ -10738,7 +11744,7 @@ endobj
 131 0 obj <<
 /Title 132 0 R
 /A 129 0 R
-/Parent 1951 0 R
+/Parent 2114 0 R
 /Prev 91 0 R
 /Next 231 0 R
 /First 135 0 R
@@ -10812,7 +11818,7 @@ endobj
 91 0 obj <<
 /Title 92 0 R
 /A 89 0 R
-/Parent 1951 0 R
+/Parent 2114 0 R
 /Prev 67 0 R
 /Next 131 0 R
 /First 95 0 R
@@ -10855,7 +11861,7 @@ endobj
 67 0 obj <<
 /Title 68 0 R
 /A 65 0 R
-/Parent 1951 0 R
+/Parent 2114 0 R
 /Prev 7 0 R
 /Next 91 0 R
 /First 71 0 R
@@ -10964,2001 +11970,2164 @@ endobj
 7 0 obj <<
 /Title 8 0 R
 /A 5 0 R
-/Parent 1951 0 R
+/Parent 2114 0 R
 /Next 67 0 R
 /First 11 0 R
 /Last 23 0 R
 /Count -4
 >> endobj
-1952 0 obj <<
-/Names [(Access_Control_Lists) 1486 0 R (Bv9ARM.ch01) 874 0 R (Bv9ARM.ch02) 923 0 R (Bv9ARM.ch03) 940 0 R (Bv9ARM.ch04) 989 0 R (Bv9ARM.ch05) 1077 0 R (Bv9ARM.ch06) 1088 0 R (Bv9ARM.ch07) 1485 0 R (Bv9ARM.ch08) 1511 0 R (Bv9ARM.ch09) 1526 0 R (Bv9ARM.ch10) 1747 0 R (Configuration_File_Grammar) 1113 0 R (DNSSEC) 1056 0 R (Doc-Start) 655 0 R (Setting_TTLs) 1452 0 R (acache) 930 0 R (access_control) 1231 0 R (acl) 1121 0 R (address_match_lists) 1094 0 R (admin_tools) 963 0 R (appendix.A) 570 0 R (appendix.B) 606 0 R (bibliography) 1535 0 R (boolean_options) 1005 0 R (builtin) 1305 0 R (chapter*.1) 690 0 R (chapter.1) 6 0 R (chapter.2) 66 0 R (chapter.3) 90 0 R (chapter.4) 130 0 R (chapter.5) 230 0 R (chapter.6) 242 0 R (chapter.7) 526 0 R (chapter.8) 550 0 R (cite.RFC1033) 1662 0 R (cite.RFC1034) 1547 0 R (cite.RFC1035) 1549 0 R (cite.RFC1101) 1644 0 R (cite.RFC1123) 1646 0 R (cite.RFC1183) 1606 0 R (cite.RFC1464) 1684 0 R (cite.RFC1535) 1592 0 R (cite.RFC1536) 1594 0 R (cite.RFC1537) 1664 0 R (cite.RFC1591) 1648 0 R (cite.RFC1706) 1608 0 R (cite.RFC1712) 1704 0 R (cite.RFC1713) 1686 0 R (cite.RFC1794) 1688 0 R (cite.RFC1876) 1610 0 R (cite.RFC1912) 1666 0 R (cite.RFC1982) 1596 0 R (cite.RFC1995) 1554 0 R (cite.RFC1996) 1556 0 R (cite.RFC2010) 1668 0 R (cite.RFC2052) 1612 0 R (cite.RFC2065) 1716 0 R (cite.RFC2136) 1558 0 R (cite.RFC2137) 1718 0 R (cite.RFC2163) 1614 0 R (cite.RFC2168) 1616 0 R (cite.RFC2181) 1560 0 R (cite.RFC2219) 1670 0 R (cite.RFC2230) 1618 0 R (cite.RFC2240) 1690 0 R (cite.RFC2308) 1562 0 R (cite.RFC2317) 1650 0 R (cite.RFC2345) 1692 0 R (cite.RFC2352) 1694 0 R (cite.RFC2535) 1720 0 R (cite.RFC2536) 1620 0 R (cite.RFC2537) 1622 0 R (cite.RFC2538) 1624 0 R (cite.RFC2539) 1626 0 R (cite.RFC2540) 1628 0 R (cite.RFC2671) 1564 0 R (cite.RFC2672) 1566 0 R (cite.RFC2673) 1706 0 R (cite.RFC2782) 1630 0 R (cite.RFC2825) 1674 0 R (cite.RFC2826) 1652 0 R (cite.RFC2845) 1568 0 R (cite.RFC2874) 1708 0 R (cite.RFC2915) 1632 0 R (cite.RFC2929) 1654 0 R (cite.RFC2930) 1570 0 R (cite.RFC2931) 1572 0 R (cite.RFC3007) 1574 0 R (cite.RFC3008) 1722 0 R (cite.RFC3071) 1696 0 R (cite.RFC3090) 1724 0 R (cite.RFC3110) 1634 0 R (cite.RFC3123) 1636 0 R (cite.RFC3225) 1580 0 R (cite.RFC3258) 1698 0 R (cite.RFC3445) 1726 0 R (cite.RFC3490) 1676 0 R (cite.RFC3491) 1678 0 R (cite.RFC3492) 1680 0 R (cite.RFC3596) 1638 0 R (cite.RFC3597) 1640 0 R (cite.RFC3645) 1576 0 R (cite.RFC3655) 1728 0 R (cite.RFC3658) 1730 0 R (cite.RFC3755) 1732 0 R (cite.RFC3757) 1734 0 R (cite.RFC3833) 1582 0 R (cite.RFC3845) 1736 0 R (cite.RFC3901) 1700 0 R (cite.RFC4033) 1584 0 R (cite.RFC4035) 1586 0 R (cite.RFC4044) 1588 0 R (cite.RFC4074) 1598 0 R (cite.RFC974) 1551 0 R (cite.id2499963) 1741 0 R (configuration_file_elements) 1089 0 R (controls_statement_definition_and_usage) 976 0 R (diagnostic_tools) 911 0 R (dynamic_update) 999 0 R (dynamic_update_policies) 1051 0 R (dynamic_update_security) 1241 0 R (empty) 1313 0 R (historical_dns_information) 1528 0 R (id2464966) 875 0 R (id2466572) 876 0 R (id2467531) 880 0 R (id2467541) 881 0 R (id2467713) 893 0 R (id2467734) 894 0 R (id2467768) 895 0 R (id2467852) 898 0 R (id2467945) 891 0 R (id2470250) 905 0 R (id2470274) 908 0 R (id2470372) 909 0 R (id2470393) 910 0 R (id2470423) 916 0 R (id2470526) 917 0 R (id2470553) 918 0 R (id2470587) 924 0 R (id2470614) 925 0 R (id2470627) 926 0 R (id2470721) 929 0 R (id2470731) 935 0 R (id2470763) 942 0 R (id2470779) 943 0 R (id2470802) 949 0 R (id2470819) 950 0 R (id2471156) 953 0 R (id2471161) 954 0 R (id2473080) 981 0 R (id2473092) 982 0 R (id2473469) 1014 0 R (id2473488) 1015 0 R (id2473923) 1031 0 R (id2473940) 1032 0 R (id2473978) 1037 0 R (id2473996) 1038 0 R (id2474007) 1039 0 R (id2474046) 1040 0 R (id2474172) 1041 0 R (id2474285) 1047 0 R (id2474299) 1048 0 R (id2474417) 1049 0 R (id2474621) 1057 0 R (id2474691) 1058 0 R (id2474770) 1063 0 R (id2474844) 1068 0 R (id2474974) 1070 0 R (id2474996) 1071 0 R (id2475165) 1078 0 R (id2475313) 1090 0 R (id2476171) 1099 0 R (id2476199) 1104 0 R (id2476374) 1105 0 R (id2476389) 1106 0 R (id2476419) 1107 0 R (id2476502) 1114 0 R (id2476918) 1120 0 R (id2476961) 1122 0 R (id2477176) 1124 0 R (id2477605) 1131 0 R (id2477622) 1132 0 R (id2477645) 1133 0 R (id2477669) 1139 0 R (id2477760) 1143 0 R (id2477885) 1144 0 R (id2477938) 1150 0 R (id2478768) 1161 0 R (id2479441) 1167 0 R (id2479514) 1168 0 R (id2479578) 1175 0 R (id2479622) 1176 0 R (id2479637) 1177 0 R (id2481622) 1202 0 R (id2483531) 1228 0 R (id2483590) 1230 0 R (id2484011) 1240 0 R (id2485010) 1260 0 R (id2485069) 1266 0 R (id2485253) 1268 0 R (id2485483) 1274 0 R (id2486119) 1288 0 R (id2487441) 1318 0 R (id2488552) 1335 0 R (id2488603) 1336 0 R (id2488685) 1338 0 R (id2490133) 1356 0 R (id2490140) 1357 0 R (id2490146) 1358 0 R (id2490560) 1364 0 R (id2490593) 1369 0 R (id2492021) 1411 0 R (id2492346) 1417 0 R (id2492364) 1418 0 R (id2492385) 1421 0 R (id2492621) 1427 0 R (id2493653) 1433 0 R (id2493781) 1439 0 R (id2493802) 1440 0 R (id2494233) 1442 0 R (id2494370) 1444 0 R (id2494392) 1450 0 R (id2494865) 1453 0 R (id2494989) 1455 0 R (id2495004) 1456 0 R (id2495253) 1462 0 R (id2495275) 1463 0 R (id2495336) 1464 0 R (id2495405) 1465 0 R (id2495442) 1466 0 R (id2495504) 1471 0 R (id2496119) 1496 0 R (id2496196) 1497 0 R (id2496256) 1498 0 R (id2496336) 1512 0 R (id2496341) 1513 0 R (id2496353) 1514 0 R (id2496370) 1515 0 R (id2496432) 1527 0 R (id2496672) 1534 0 R (id2496928) 1539 0 R (id2496930) 1545 0 R (id2496938) 1550 0 R (id2496962) 1546 0 R (id2496985) 1548 0 R (id2497021) 1559 0 R (id2497048) 1561 0 R (id2497074) 1553 0 R (id2497098) 1555 0 R (id2497122) 1557 0 R (id2497177) 1563 0 R (id2497204) 1565 0 R (id2497230) 1567 0 R (id2497361) 1569 0 R (id2497390) 1571 0 R (id2497420) 1573 0 R (id2497447) 1575 0 R (id2497522) 1578 0 R (id2497529) 1579 0 R (id2497556) 1581 0 R (id2497592) 1583 0 R (id2497657) 1587 0 R (id2497722) 1585 0 R (id2497787) 1590 0 R (id2497796) 1591 0 R (id2497821) 1593 0 R (id2497890) 1595 0 R (id2497925) 1597 0 R (id2497965) 1604 0 R (id2497971) 1605 0 R (id2498028) 1607 0 R (id2498066) 1615 0 R (id2498101) 1609 0 R (id2498155) 1611 0 R (id2498194) 1613 0 R (id2498219) 1617 0 R (id2498245) 1619 0 R (id2498272) 1621 0 R (id2498298) 1623 0 R (id2498338) 1625 0 R (id2498368) 1627 0 R (id2498397) 1629 0 R (id2498440) 1631 0 R (id2498473) 1633 0 R (id2498500) 1635 0 R (id2498523) 1637 0 R (id2498581) 1639 0 R (id2498605) 1642 0 R (id2498613) 1643 0 R (id2498638) 1645 0 R (id2498661) 1647 0 R (id2498684) 1649 0 R (id2498730) 1651 0 R (id2498754) 1653 0 R (id2498804) 1660 0 R (id2498811) 1661 0 R (id2498835) 1663 0 R (id2498861) 1665 0 R (id2498888) 1667 0 R (id2498924) 1669 0 R (id2498965) 1672 0 R (id2498970) 1673 0 R (id2499002) 1675 0 R (id2499048) 1677 0 R (id2499083) 1679 0 R (id2499110) 1682 0 R (id2499128) 1683 0 R (id2499150) 1685 0 R (id2499176) 1687 0 R (id2499202) 1689 0 R (id2499225) 1691 0 R (id2499271) 1693 0 R (id2499294) 1695 0 R (id2499321) 1697 0 R (id2499347) 1699 0 R (id2499384) 1702 0 R (id2499390) 1703 0 R (id2499448) 1705 0 R (id2499475) 1707 0 R (id2499511) 1714 0 R (id2499523) 1715 0 R (id2499562) 1717 0 R (id2499657) 1719 0 R (id2499687) 1721 0 R (id2499713) 1723 0 R (id2499739) 1725 0 R (id2499776) 1727 0 R (id2499812) 1729 0 R (id2499838) 1731 0 R (id2499865) 1733 0 R (id2499910) 1735 0 R (id2499952) 1738 0 R (id2499961) 1740 0 R (id2499963) 1742 0 R (incremental_zone_transfers) 1011 0 R (internet_drafts) 1737 0 R (ipv6addresses) 1072 0 R (journal) 1000 0 R (lwresd) 1079 0 R (man.dig) 1748 0 R (man.dnssec-keygen) 1797 0 R (man.dnssec-signzone) 1814 0 R (man.host) 1781 0 R (man.named) 1863 0 R (man.named-checkconf) 1834 0 R (man.named-checkzone) 1847 0 R (man.rndc) 1885 0 R (man.rndc-confgen) 1918 0 R (man.rndc.conf) 1898 0 R (notify) 990 0 R (options) 1187 0 R (page.1) 654 0 R (page.10) 915 0 R (page.100) 1767 0 R (page.101) 1771 0 R (page.102) 1776 0 R (page.103) 1788 0 R (page.104) 1793 0 R (page.105) 1805 0 R (page.106) 1810 0 R (page.107) 1821 0 R (page.108) 1826 0 R (page.109) 1831 0 R (page.11) 922 0 R (page.110) 1843 0 R (page.111) 1855 0 R (page.112) 1859 0 R (page.113) 1870 0 R (page.114) 1875 0 R (page.115) 1880 0 R (page.116) 1893 0 R (page.117) 1903 0 R (page.118) 1910 0 R (page.119) 1917 0 R (page.12) 934 0 R (page.120) 1926 0 R (page.13) 939 0 R (page.14) 948 0 R (page.15) 959 0 R (page.16) 967 0 R (page.17) 974 0 R (page.18) 980 0 R (page.19) 988 0 R (page.2) 679 0 R (page.20) 1010 0 R (page.21) 1020 0 R (page.22) 1025 0 R (page.23) 1029 0 R (page.24) 1036 0 R (page.25) 1045 0 R (page.26) 1055 0 R (page.27) 1062 0 R (page.28) 1067 0 R (page.29) 1076 0 R (page.3) 689 0 R (page.30) 1083 0 R (page.31) 1087 0 R (page.32) 1098 0 R (page.33) 1103 0 R (page.34) 1112 0 R (page.35) 1119 0 R (page.36) 1128 0 R (page.37) 1138 0 R (page.38) 1149 0 R (page.39) 1154 0 R (page.4) 744 0 R (page.40) 1160 0 R (page.41) 1166 0 R (page.42) 1174 0 R (page.43) 1181 0 R (page.44) 1186 0 R (page.45) 1191 0 R (page.46) 1197 0 R (page.47) 1201 0 R (page.48) 1207 0 R (page.49) 1218 0 R (page.5) 808 0 R (page.50) 1223 0 R (page.51) 1227 0 R (page.52) 1237 0 R (page.53) 1245 0 R (page.54) 1250 0 R (page.55) 1254 0 R (page.56) 1259 0 R (page.57) 1265 0 R (page.58) 1273 0 R (page.59) 1279 0 R (page.6) 869 0 R (page.60) 1286 0 R (page.61) 1293 0 R (page.62) 1300 0 R (page.63) 1312 0 R (page.64) 1317 0 R (page.65) 1323 0 R (page.66) 1328 0 R (page.67) 1333 0 R (page.68) 1343 0 R (page.69) 1347 0 R (page.7) 873 0 R (page.70) 1351 0 R (page.71) 1355 0 R (page.72) 1363 0 R (page.73) 1368 0 R (page.74) 1386 0 R (page.75) 1401 0 R (page.76) 1416 0 R (page.77) 1426 0 R (page.78) 1432 0 R (page.79) 1438 0 R (page.8) 890 0 R (page.80) 1449 0 R (page.81) 1461 0 R (page.82) 1470 0 R (page.83) 1476 0 R (page.84) 1480 0 R (page.85) 1484 0 R (page.86) 1491 0 R (page.87) 1502 0 R (page.88) 1506 0 R (page.89) 1510 0 R (page.9) 904 0 R (page.90) 1521 0 R (page.91) 1525 0 R (page.92) 1533 0 R (page.93) 1543 0 R (page.94) 1602 0 R (page.95) 1658 0 R (page.96) 1712 0 R (page.97) 1746 0 R (page.98) 1756 0 R (page.99) 1762 0 R (proposed_standards) 1016 0 R (query_address) 1246 0 R (rfcs) 900 0 R (rndc) 1134 0 R (rrset_ordering) 955 0 R (sample_configuration) 941 0 R (section*.10) 1671 0 R (section*.11) 1681 0 R (section*.12) 1701 0 R (section*.13) 1713 0 R (section*.14) 1739 0 R (section*.15) 1749 0 R (section*.16) 1750 0 R (section*.17) 1751 0 R (section*.18) 1757 0 R (section*.19) 1758 0 R (section*.2) 1538 0 R (section*.20) 1763 0 R (section*.21) 1772 0 R (section*.22) 1777 0 R (section*.23) 1778 0 R (section*.24) 1779 0 R (section*.25) 1780 0 R (section*.26) 1782 0 R (section*.27) 1783 0 R (section*.28) 1784 0 R (section*.29) 1794 0 R (section*.3) 1544 0 R (section*.30) 1795 0 R (section*.31) 1796 0 R (section*.32) 1798 0 R (section*.33) 1799 0 R (section*.34) 1800 0 R (section*.35) 1801 0 R (section*.36) 1806 0 R (section*.37) 1811 0 R (section*.38) 1812 0 R (section*.39) 1813 0 R (section*.4) 1552 0 R (section*.40) 1815 0 R (section*.41) 1816 0 R (section*.42) 1817 0 R (section*.43) 1822 0 R (section*.44) 1827 0 R (section*.45) 1832 0 R (section*.46) 1833 0 R (section*.47) 1835 0 R (section*.48) 1836 0 R (section*.49) 1837 0 R (section*.5) 1577 0 R (section*.50) 1838 0 R (section*.51) 1844 0 R (section*.52) 1845 0 R (section*.53) 1846 0 R (section*.54) 1848 0 R (section*.55) 1849 0 R (section*.56) 1850 0 R (section*.57) 1851 0 R (section*.58) 1860 0 R (section*.59) 1861 0 R (section*.6) 1589 0 R (section*.60) 1862 0 R (section*.61) 1864 0 R (section*.62) 1865 0 R (section*.63) 1866 0 R (section*.64) 1871 0 R (section*.65) 1876 0 R (section*.66) 1881 0 R (section*.67) 1882 0 R (section*.68) 1883 0 R (section*.69) 1884 0 R (section*.7) 1603 0 R (section*.70) 1886 0 R (section*.71) 1887 0 R (section*.72) 1888 0 R (section*.73) 1894 0 R (section*.74) 1895 0 R (section*.75) 1896 0 R (section*.76) 1897 0 R (section*.77) 1899 0 R (section*.78) 1904 0 R (section*.79) 1905 0 R (section*.8) 1641 0 R (section*.80) 1906 0 R (section*.81) 1911 0 R (section*.82) 1912 0 R (section*.83) 1913 0 R (section*.84) 1919 0 R (section*.85) 1920 0 R (section*.86) 1921 0 R (section*.87) 1922 0 R (section*.88) 1927 0 R (section*.89) 1928 0 R (section*.9) 1659 0 R (section*.90) 1929 0 R (section.1.1) 10 0 R (section.1.2) 14 0 R (section.1.3) 18 0 R (section.1.4) 22 0 R (section.2.1) 70 0 R (section.2.2) 74 0 R (section.2.3) 78 0 R (section.2.4) 82 0 R (section.2.5) 86 0 R (section.3.1) 94 0 R (section.3.2) 106 0 R (section.3.3) 110 0 R (section.4.1) 134 0 R (section.4.2) 138 0 R (section.4.3) 146 0 R (section.4.4) 150 0 R (section.4.5) 158 0 R (section.4.6) 194 0 R (section.4.7) 198 0 R (section.4.8) 202 0 R (section.4.9) 218 0 R (section.5.1) 234 0 R (section.5.2) 238 0 R (section.6.1) 246 0 R (section.6.2) 274 0 R (section.6.3) 474 0 R (section.7.1) 530 0 R (section.7.2) 534 0 R (section.7.3) 546 0 R (section.8.1) 554 0 R (section.8.2) 562 0 R (section.8.3) 566 0 R (section.A.1) 574 0 R (section.A.2) 582 0 R (section.A.3) 590 0 R (section.B.1) 610 0 R (section.B.10) 646 0 R (section.B.2) 614 0 R (section.B.3) 618 0 R (section.B.4) 622 0 R (section.B.5) 626 0 R (section.B.6) 630 0 R (section.B.7) 634 0 R (section.B.8) 638 0 R (section.B.9) 642 0 R (server_statement_definition_and_usage) 1214 0 R (server_statement_grammar) 1324 0 R (statsfile) 1193 0 R (subsection.1.4.1) 26 0 R (subsection.1.4.2) 30 0 R (subsection.1.4.3) 34 0 R (subsection.1.4.4) 38 0 R (subsection.1.4.5) 54 0 R (subsection.1.4.6) 62 0 R (subsection.3.1.1) 98 0 R (subsection.3.1.2) 102 0 R (subsection.3.3.1) 114 0 R (subsection.3.3.2) 126 0 R (subsection.4.2.1) 142 0 R (subsection.4.4.1) 154 0 R (subsection.4.5.1) 162 0 R (subsection.4.5.2) 174 0 R (subsection.4.5.3) 178 0 R (subsection.4.5.4) 182 0 R (subsection.4.5.5) 186 0 R (subsection.4.5.6) 190 0 R (subsection.4.8.1) 206 0 R (subsection.4.8.2) 210 0 R (subsection.4.8.3) 214 0 R (subsection.4.9.1) 222 0 R (subsection.4.9.2) 226 0 R (subsection.6.1.1) 250 0 R (subsection.6.1.2) 262 0 R (subsection.6.2.1) 278 0 R (subsection.6.2.10) 314 0 R (subsection.6.2.11) 326 0 R (subsection.6.2.12) 330 0 R (subsection.6.2.13) 334 0 R (subsection.6.2.14) 338 0 R (subsection.6.2.15) 342 0 R (subsection.6.2.16) 346 0 R (subsection.6.2.17) 426 0 R (subsection.6.2.18) 430 0 R (subsection.6.2.19) 434 0 R (subsection.6.2.2) 282 0 R (subsection.6.2.20) 438 0 R (subsection.6.2.21) 442 0 R (subsection.6.2.22) 446 0 R (subsection.6.2.23) 450 0 R (subsection.6.2.24) 454 0 R (subsection.6.2.3) 286 0 R (subsection.6.2.4) 290 0 R (subsection.6.2.5) 294 0 R (subsection.6.2.6) 298 0 R (subsection.6.2.7) 302 0 R (subsection.6.2.8) 306 0 R (subsection.6.2.9) 310 0 R (subsection.6.3.1) 478 0 R (subsection.6.3.2) 490 0 R (subsection.6.3.3) 494 0 R (subsection.6.3.4) 498 0 R (subsection.6.3.5) 502 0 R (subsection.6.3.6) 518 0 R (subsection.6.3.7) 522 0 R (subsection.7.2.1) 538 0 R (subsection.7.2.2) 542 0 R (subsection.8.1.1) 558 0 R (subsection.A.1.1) 578 0 R (subsection.A.2.1) 586 0 R (subsection.A.3.1) 594 0 R (subsection.A.3.2) 598 0 R (subsection.A.3.3) 602 0 R (subsubsection.1.4.4.1) 42 0 R (subsubsection.1.4.4.2) 46 0 R (subsubsection.1.4.4.3) 50 0 R (subsubsection.1.4.5.1) 58 0 R (subsubsection.3.3.1.1) 118 0 R (subsubsection.3.3.1.2) 122 0 R (subsubsection.4.5.1.1) 166 0 R (subsubsection.4.5.1.2) 170 0 R (subsubsection.6.1.1.1) 254 0 R (subsubsection.6.1.1.2) 258 0 R (subsubsection.6.1.2.1) 266 0 R (subsubsection.6.1.2.2) 270 0 R (subsubsection.6.2.10.1) 318 0 R (subsubsection.6.2.10.2) 322 0 R (subsubsection.6.2.16.1) 350 0 R (subsubsection.6.2.16.10) 386 0 R (subsubsection.6.2.16.11) 390 0 R (subsubsection.6.2.16.12) 394 0 R (subsubsection.6.2.16.13) 398 0 R (subsubsection.6.2.16.14) 402 0 R (subsubsection.6.2.16.15) 406 0 R (subsubsection.6.2.16.16) 410 0 R (subsubsection.6.2.16.17) 414 0 R (subsubsection.6.2.16.18) 418 0 R (subsubsection.6.2.16.19) 422 0 R (subsubsection.6.2.16.2) 354 0 R (subsubsection.6.2.16.3) 358 0 R (subsubsection.6.2.16.4) 362 0 R (subsubsection.6.2.16.5) 366 0 R (subsubsection.6.2.16.6) 370 0 R (subsubsection.6.2.16.7) 374 0 R (subsubsection.6.2.16.8) 378 0 R (subsubsection.6.2.16.9) 382 0 R (subsubsection.6.2.24.1) 458 0 R (subsubsection.6.2.24.2) 462 0 R (subsubsection.6.2.24.3) 466 0 R (subsubsection.6.2.24.4) 470 0 R (subsubsection.6.3.1.1) 482 0 R (subsubsection.6.3.1.2) 486 0 R (subsubsection.6.3.5.1) 506 0 R (subsubsection.6.3.5.2) 510 0 R (subsubsection.6.3.5.3) 514 0 R (table.1.1) 882 0 R (table.1.2) 892 0 R (table.3.1) 951 0 R (table.3.2) 983 0 R (table.6.1) 1091 0 R (table.6.10) 1422 0 R (table.6.11) 1428 0 R (table.6.12) 1434 0 R (table.6.13) 1441 0 R (table.6.14) 1443 0 R (table.6.15) 1451 0 R (table.6.16) 1454 0 R (table.6.17) 1457 0 R (table.6.18) 1472 0 R (table.6.2) 1115 0 R (table.6.3) 1123 0 R (table.6.4) 1162 0 R (table.6.5) 1203 0 R (table.6.6) 1289 0 R (table.6.7) 1319 0 R (table.6.8) 1359 0 R (table.6.9) 1412 0 R (the_category_phrase) 1156 0 R (the_sortlist_statement) 1280 0 R (topology) 1275 0 R (tsig) 1030 0 R (tuning) 1294 0 R (types_of_resource_records_and_when_to_use_them) 899 0 R (view_statement_grammar) 1308 0 R (zone_statement_grammar) 1233 0 R (zone_transfers) 1006 0 R (zonefile_format) 1307 0 R]
+2115 0 obj <<
+/Names [(Access_Control_Lists) 1591 0 R (Bv9ARM.ch01) 932 0 R (Bv9ARM.ch02) 978 0 R (Bv9ARM.ch03) 995 0 R (Bv9ARM.ch04) 1044 0 R (Bv9ARM.ch05) 1132 0 R (Bv9ARM.ch06) 1143 0 R (Bv9ARM.ch07) 1590 0 R (Bv9ARM.ch08) 1616 0 R (Bv9ARM.ch09) 1631 0 R (Bv9ARM.ch10) 1852 0 R (Configuration_File_Grammar) 1168 0 R (DNSSEC) 1111 0 R (Doc-Start) 699 0 R (Setting_TTLs) 1526 0 R (acache) 985 0 R (access_control) 1290 0 R (acl) 1176 0 R (address_match_lists) 1149 0 R (admin_tools) 1018 0 R (appendix.A) 602 0 R (appendix.B) 638 0 R (bibliography) 1640 0 R (boolean_options) 1060 0 R (builtin) 1368 0 R (chapter*.1) 734 0 R (chapter.1) 6 0 R (chapter.2) 66 0 R (chapter.3) 90 0 R (chapter.4) 130 0 R (chapter.5) 230 0 R (chapter.6) 242 0 R (chapter.7) 558 0 R (chapter.8) 582 0 R (cite.RFC1033) 1767 0 R (cite.RFC1034) 1652 0 R (cite.RFC1035) 1654 0 R (cite.RFC1101) 1749 0 R (cite.RFC1123) 1751 0 R (cite.RFC1183) 1711 0 R (cite.RFC1464) 1789 0 R (cite.RFC1535) 1697 0 R (cite.RFC1536) 1699 0 R (cite.RFC1537) 1769 0 R (cite.RFC1591) 1753 0 R (cite.RFC1706) 1713 0 R (cite.RFC1712) 1809 0 R (cite.RFC1713) 1791 0 R (cite.RFC1794) 1793 0 R (cite.RFC1876) 1715 0 R (cite.RFC1912) 1771 0 R (cite.RFC1982) 1701 0 R (cite.RFC1995) 1659 0 R (cite.RFC1996) 1661 0 R (cite.RFC2010) 1773 0 R (cite.RFC2052) 1717 0 R (cite.RFC2065) 1821 0 R (cite.RFC2136) 1663 0 R (cite.RFC2137) 1823 0 R (cite.RFC2163) 1719 0 R (cite.RFC2168) 1721 0 R (cite.RFC2181) 1665 0 R (cite.RFC2219) 1775 0 R (cite.RFC2230) 1723 0 R (cite.RFC2240) 1795 0 R (cite.RFC2308) 1667 0 R (cite.RFC2317) 1755 0 R (cite.RFC2345) 1797 0 R (cite.RFC2352) 1799 0 R (cite.RFC2535) 1825 0 R (cite.RFC2536) 1725 0 R (cite.RFC2537) 1727 0 R (cite.RFC2538) 1729 0 R (cite.RFC2539) 1731 0 R (cite.RFC2540) 1733 0 R (cite.RFC2671) 1669 0 R (cite.RFC2672) 1671 0 R (cite.RFC2673) 1811 0 R (cite.RFC2782) 1735 0 R (cite.RFC2825) 1779 0 R (cite.RFC2826) 1757 0 R (cite.RFC2845) 1673 0 R (cite.RFC2874) 1813 0 R (cite.RFC2915) 1737 0 R (cite.RFC2929) 1759 0 R (cite.RFC2930) 1675 0 R (cite.RFC2931) 1677 0 R (cite.RFC3007) 1679 0 R (cite.RFC3008) 1827 0 R (cite.RFC3071) 1801 0 R (cite.RFC3090) 1829 0 R (cite.RFC3110) 1739 0 R (cite.RFC3123) 1741 0 R (cite.RFC3225) 1685 0 R (cite.RFC3258) 1803 0 R (cite.RFC3445) 1831 0 R (cite.RFC3490) 1781 0 R (cite.RFC3491) 1783 0 R (cite.RFC3492) 1785 0 R (cite.RFC3596) 1743 0 R (cite.RFC3597) 1745 0 R (cite.RFC3645) 1681 0 R (cite.RFC3655) 1833 0 R (cite.RFC3658) 1835 0 R (cite.RFC3755) 1837 0 R (cite.RFC3757) 1839 0 R (cite.RFC3833) 1687 0 R (cite.RFC3845) 1841 0 R (cite.RFC3901) 1805 0 R (cite.RFC4033) 1689 0 R (cite.RFC4034) 1691 0 R (cite.RFC4035) 1693 0 R (cite.RFC4074) 1703 0 R (cite.RFC974) 1656 0 R (cite.id2504427) 1846 0 R (configuration_file_elements) 1144 0 R (controls_statement_definition_and_usage) 1031 0 R (diagnostic_tools) 966 0 R (dynamic_update) 1054 0 R (dynamic_update_policies) 1106 0 R (dynamic_update_security) 1299 0 R (empty) 1376 0 R (historical_dns_information) 1633 0 R (id2464966) 933 0 R (id2466572) 934 0 R (id2467531) 935 0 R (id2467541) 936 0 R (id2467713) 948 0 R (id2467734) 949 0 R (id2467768) 950 0 R (id2467852) 953 0 R (id2467945) 946 0 R (id2470250) 960 0 R (id2470274) 963 0 R (id2470372) 964 0 R (id2470393) 965 0 R (id2470423) 971 0 R (id2470526) 972 0 R (id2470553) 973 0 R (id2470587) 979 0 R (id2470614) 980 0 R (id2470627) 981 0 R (id2470721) 984 0 R (id2470731) 990 0 R (id2470763) 997 0 R (id2470779) 998 0 R (id2470802) 1004 0 R (id2470819) 1005 0 R (id2471224) 1008 0 R (id2471229) 1009 0 R (id2473110) 1036 0 R (id2473122) 1037 0 R (id2473515) 1069 0 R (id2473533) 1070 0 R (id2473969) 1086 0 R (id2473986) 1087 0 R (id2474024) 1092 0 R (id2474042) 1093 0 R (id2474121) 1094 0 R (id2474161) 1095 0 R (id2474286) 1100 0 R (id2474331) 1102 0 R (id2474345) 1103 0 R (id2474462) 1104 0 R (id2474599) 1112 0 R (id2474678) 1113 0 R (id2474759) 1118 0 R (id2474902) 1123 0 R (id2475169) 1125 0 R (id2475190) 1126 0 R (id2475291) 1133 0 R (id2475438) 1145 0 R (id2476300) 1154 0 R (id2476328) 1159 0 R (id2476522) 1160 0 R (id2476537) 1161 0 R (id2476567) 1167 0 R (id2476718) 1169 0 R (id2477161) 1175 0 R (id2477272) 1177 0 R (id2477419) 1179 0 R (id2477780) 1186 0 R (id2477797) 1192 0 R (id2477889) 1193 0 R (id2477912) 1194 0 R (id2478003) 1198 0 R (id2478197) 1204 0 R (id2478249) 1205 0 R (id2478942) 1216 0 R (id2479645) 1226 0 R (id2479719) 1227 0 R (id2479783) 1230 0 R (id2479827) 1231 0 R (id2479842) 1232 0 R (id2482169) 1261 0 R (id2484043) 1287 0 R (id2484102) 1289 0 R (id2484598) 1304 0 R (id2485793) 1323 0 R (id2485852) 1325 0 R (id2486200) 1337 0 R (id2486839) 1352 0 R (id2488339) 1386 0 R (id2489091) 1399 0 R (id2489142) 1400 0 R (id2489292) 1402 0 R (id2490761) 1419 0 R (id2490769) 1420 0 R (id2490774) 1421 0 R (id2491188) 1428 0 R (id2491221) 1433 0 R (id2492840) 1485 0 R (id2493223) 1491 0 R (id2493309) 1492 0 R (id2493330) 1495 0 R (id2493498) 1497 0 R (id2494737) 1508 0 R (id2494865) 1514 0 R (id2495022) 1515 0 R (id2495385) 1517 0 R (id2495522) 1519 0 R (id2495544) 1524 0 R (id2496017) 1527 0 R (id2496141) 1529 0 R (id2496156) 1530 0 R (id2496268) 1536 0 R (id2496291) 1537 0 R (id2496420) 1538 0 R (id2496489) 1539 0 R (id2496525) 1544 0 R (id2496587) 1545 0 R (id2497018) 1553 0 R (id2497363) 1561 0 R (id2497368) 1562 0 R (id2499022) 1568 0 R (id2499029) 1569 0 R (id2499405) 1571 0 R (id2499411) 1572 0 R (id2500259) 1581 0 R (id2500446) 1601 0 R (id2500592) 1602 0 R (id2500651) 1603 0 R (id2500731) 1617 0 R (id2500737) 1618 0 R (id2500748) 1619 0 R (id2500765) 1620 0 R (id2500964) 1632 0 R (id2501136) 1639 0 R (id2501255) 1644 0 R (id2501257) 1650 0 R (id2501266) 1655 0 R (id2501289) 1651 0 R (id2501381) 1653 0 R (id2501417) 1664 0 R (id2501444) 1666 0 R (id2501469) 1658 0 R (id2501494) 1660 0 R (id2501517) 1662 0 R (id2501573) 1668 0 R (id2501600) 1670 0 R (id2501626) 1672 0 R (id2501688) 1674 0 R (id2501718) 1676 0 R (id2501748) 1678 0 R (id2501843) 1680 0 R (id2501917) 1683 0 R (id2501925) 1684 0 R (id2501952) 1686 0 R (id2501988) 1688 0 R (id2502053) 1690 0 R (id2502118) 1692 0 R (id2502183) 1695 0 R (id2502192) 1696 0 R (id2502217) 1698 0 R (id2502285) 1700 0 R (id2502321) 1702 0 R (id2502361) 1709 0 R (id2502366) 1710 0 R (id2502424) 1712 0 R (id2502461) 1720 0 R (id2502497) 1714 0 R (id2502551) 1716 0 R (id2502589) 1718 0 R (id2502615) 1722 0 R (id2502641) 1724 0 R (id2502667) 1726 0 R (id2502694) 1728 0 R (id2502733) 1730 0 R (id2502763) 1732 0 R (id2502793) 1734 0 R (id2502836) 1736 0 R (id2502869) 1738 0 R (id2502896) 1740 0 R (id2502919) 1742 0 R (id2502977) 1744 0 R (id2503001) 1747 0 R (id2503009) 1748 0 R (id2503034) 1750 0 R (id2503057) 1752 0 R (id2503080) 1754 0 R (id2503126) 1756 0 R (id2503149) 1758 0 R (id2503200) 1765 0 R (id2503207) 1766 0 R (id2503230) 1768 0 R (id2503257) 1770 0 R (id2503352) 1772 0 R (id2503388) 1774 0 R (id2503429) 1777 0 R (id2503434) 1778 0 R (id2503466) 1780 0 R (id2503512) 1782 0 R (id2503547) 1784 0 R (id2503574) 1787 0 R (id2503592) 1788 0 R (id2503614) 1790 0 R (id2503640) 1792 0 R (id2503666) 1794 0 R (id2503689) 1796 0 R (id2503735) 1798 0 R (id2503758) 1800 0 R (id2503785) 1802 0 R (id2503811) 1804 0 R (id2503848) 1807 0 R (id2503854) 1808 0 R (id2503912) 1810 0 R (id2503939) 1812 0 R (id2503975) 1819 0 R (id2503987) 1820 0 R (id2504026) 1822 0 R (id2504053) 1824 0 R (id2504083) 1826 0 R (id2504108) 1828 0 R (id2504135) 1830 0 R (id2504240) 1832 0 R (id2504276) 1834 0 R (id2504302) 1836 0 R (id2504329) 1838 0 R (id2504374) 1840 0 R (id2504416) 1843 0 R (id2504425) 1845 0 R (id2504427) 1847 0 R (incremental_zone_transfers) 1066 0 R (internet_drafts) 1842 0 R (ipv6addresses) 1127 0 R (journal) 1055 0 R (lwresd) 1134 0 R (man.dig) 1853 0 R (man.dnssec-dsfromkey) 1902 0 R (man.dnssec-keyfromlabel) 1916 0 R (man.dnssec-keygen) 1932 0 R (man.dnssec-signzone) 1949 0 R (man.host) 1886 0 R (man.named) 2003 0 R (man.named-checkconf) 1970 0 R (man.named-checkzone) 1982 0 R (man.nsupdate) 2021 0 R (man.rndc) 2047 0 R (man.rndc-confgen) 2075 0 R (man.rndc.conf) 2059 0 R (notify) 1045 0 R (options) 1246 0 R (page.1) 698 0 R (page.10) 970 0 R (page.100) 1707 0 R (page.101) 1763 0 R (page.102) 1817 0 R (page.103) 1851 0 R (page.104) 1861 0 R (page.105) 1867 0 R (page.106) 1872 0 R (page.107) 1876 0 R (page.108) 1881 0 R (page.109) 1892 0 R (page.11) 977 0 R (page.110) 1898 0 R (page.111) 1910 0 R (page.112) 1921 0 R (page.113) 1928 0 R (page.114) 1940 0 R (page.115) 1944 0 R (page.116) 1956 0 R (page.117) 1962 0 R (page.118) 1966 0 R (page.119) 1976 0 R (page.12) 989 0 R (page.120) 1988 0 R (page.121) 1994 0 R (page.122) 2002 0 R (page.123) 2011 0 R (page.124) 2015 0 R (page.125) 2026 0 R (page.126) 2032 0 R (page.127) 2037 0 R (page.128) 2043 0 R (page.129) 2055 0 R (page.13) 994 0 R (page.130) 2065 0 R (page.131) 2071 0 R (page.132) 2080 0 R (page.133) 2087 0 R (page.14) 1003 0 R (page.15) 1014 0 R (page.16) 1022 0 R (page.17) 1029 0 R (page.18) 1035 0 R (page.19) 1043 0 R (page.2) 723 0 R (page.20) 1065 0 R (page.21) 1075 0 R (page.22) 1080 0 R (page.23) 1084 0 R (page.24) 1091 0 R (page.25) 1099 0 R (page.26) 1110 0 R (page.27) 1117 0 R (page.28) 1122 0 R (page.29) 1131 0 R (page.3) 733 0 R (page.30) 1138 0 R (page.31) 1142 0 R (page.32) 1153 0 R (page.33) 1158 0 R (page.34) 1166 0 R (page.35) 1174 0 R (page.36) 1183 0 R (page.37) 1191 0 R (page.38) 1203 0 R (page.39) 1209 0 R (page.4) 788 0 R (page.40) 1215 0 R (page.41) 1221 0 R (page.42) 1225 0 R (page.43) 1236 0 R (page.44) 1241 0 R (page.45) 1245 0 R (page.46) 1250 0 R (page.47) 1256 0 R (page.48) 1260 0 R (page.49) 1267 0 R (page.5) 852 0 R (page.50) 1278 0 R (page.51) 1282 0 R (page.52) 1286 0 R (page.53) 1296 0 R (page.54) 1303 0 R (page.55) 1309 0 R (page.56) 1314 0 R (page.57) 1318 0 R (page.58) 1322 0 R (page.59) 1330 0 R (page.6) 914 0 R (page.60) 1336 0 R (page.61) 1342 0 R (page.62) 1350 0 R (page.63) 1358 0 R (page.64) 1363 0 R (page.65) 1375 0 R (page.66) 1380 0 R (page.67) 1384 0 R (page.68) 1392 0 R (page.69) 1397 0 R (page.7) 931 0 R (page.70) 1406 0 R (page.71) 1410 0 R (page.72) 1414 0 R (page.73) 1418 0 R (page.74) 1427 0 R (page.75) 1432 0 R (page.76) 1451 0 R (page.77) 1464 0 R (page.78) 1484 0 R (page.79) 1490 0 R (page.8) 945 0 R (page.80) 1503 0 R (page.81) 1507 0 R (page.82) 1513 0 R (page.83) 1523 0 R (page.84) 1535 0 R (page.85) 1543 0 R (page.86) 1551 0 R (page.87) 1559 0 R (page.88) 1567 0 R (page.89) 1576 0 R (page.9) 959 0 R (page.90) 1585 0 R (page.91) 1589 0 R (page.92) 1596 0 R (page.93) 1607 0 R (page.94) 1611 0 R (page.95) 1615 0 R (page.96) 1626 0 R (page.97) 1630 0 R (page.98) 1638 0 R (page.99) 1648 0 R (proposed_standards) 1071 0 R (query_address) 1305 0 R (rfcs) 955 0 R (rndc) 1187 0 R (rrset_ordering) 1010 0 R (sample_configuration) 996 0 R (section*.10) 1776 0 R (section*.100) 2058 0 R (section*.101) 2060 0 R (section*.102) 2061 0 R (section*.103) 2066 0 R (section*.104) 2067 0 R (section*.105) 2072 0 R (section*.106) 2073 0 R (section*.107) 2074 0 R (section*.108) 2076 0 R (section*.109) 2081 0 R (section*.11) 1786 0 R (section*.110) 2082 0 R (section*.111) 2083 0 R (section*.112) 2088 0 R (section*.113) 2089 0 R (section*.114) 2090 0 R (section*.12) 1806 0 R (section*.13) 1818 0 R (section*.14) 1844 0 R (section*.15) 1854 0 R (section*.16) 1855 0 R (section*.17) 1856 0 R (section*.18) 1862 0 R (section*.19) 1863 0 R (section*.2) 1643 0 R (section*.20) 1868 0 R (section*.21) 1877 0 R (section*.22) 1882 0 R (section*.23) 1883 0 R (section*.24) 1884 0 R (section*.25) 1885 0 R (section*.26) 1887 0 R (section*.27) 1888 0 R (section*.28) 1893 0 R (section*.29) 1899 0 R (section*.3) 1649 0 R (section*.30) 1900 0 R (section*.31) 1901 0 R (section*.32) 1903 0 R (section*.33) 1904 0 R (section*.34) 1905 0 R (section*.35) 1906 0 R (section*.36) 1911 0 R (section*.37) 1912 0 R (section*.38) 1913 0 R (section*.39) 1914 0 R (section*.4) 1657 0 R (section*.40) 1915 0 R (section*.41) 1917 0 R (section*.42) 1922 0 R (section*.43) 1923 0 R (section*.44) 1924 0 R (section*.45) 1929 0 R (section*.46) 1930 0 R (section*.47) 1931 0 R (section*.48) 1933 0 R (section*.49) 1934 0 R (section*.5) 1682 0 R (section*.50) 1935 0 R (section*.51) 1936 0 R (section*.52) 1945 0 R (section*.53) 1946 0 R (section*.54) 1947 0 R (section*.55) 1948 0 R (section*.56) 1950 0 R (section*.57) 1951 0 R (section*.58) 1957 0 R (section*.59) 1958 0 R (section*.6) 1694 0 R (section*.60) 1967 0 R (section*.61) 1968 0 R (section*.62) 1969 0 R (section*.63) 1971 0 R (section*.64) 1972 0 R (section*.65) 1977 0 R (section*.66) 1978 0 R (section*.67) 1979 0 R (section*.68) 1980 0 R (section*.69) 1981 0 R (section*.7) 1708 0 R (section*.70) 1983 0 R (section*.71) 1984 0 R (section*.72) 1989 0 R (section*.73) 1990 0 R (section*.74) 1995 0 R (section*.75) 1996 0 R (section*.76) 1997 0 R (section*.77) 2004 0 R (section*.78) 2005 0 R (section*.79) 2006 0 R (section*.8) 1746 0 R (section*.80) 2007 0 R (section*.81) 2016 0 R (section*.82) 2017 0 R (section*.83) 2018 0 R (section*.84) 2019 0 R (section*.85) 2020 0 R (section*.86) 2022 0 R (section*.87) 2027 0 R (section*.88) 2028 0 R (section*.89) 2033 0 R (section*.9) 1764 0 R (section*.90) 2038 0 R (section*.91) 2044 0 R (section*.92) 2045 0 R (section*.93) 2046 0 R (section*.94) 2048 0 R (section*.95) 2049 0 R (section*.96) 2050 0 R (section*.97) 2051 0 R (section*.98) 2056 0 R (section*.99) 2057 0 R (section.1.1) 10 0 R (section.1.2) 14 0 R (section.1.3) 18 0 R (section.1.4) 22 0 R (section.2.1) 70 0 R (section.2.2) 74 0 R (section.2.3) 78 0 R (section.2.4) 82 0 R (section.2.5) 86 0 R (section.3.1) 94 0 R (section.3.2) 106 0 R (section.3.3) 110 0 R (section.4.1) 134 0 R (section.4.2) 138 0 R (section.4.3) 146 0 R (section.4.4) 150 0 R (section.4.5) 158 0 R (section.4.6) 194 0 R (section.4.7) 198 0 R (section.4.8) 202 0 R (section.4.9) 218 0 R (section.5.1) 234 0 R (section.5.2) 238 0 R (section.6.1) 246 0 R (section.6.2) 274 0 R (section.6.3) 478 0 R (section.6.4) 530 0 R (section.7.1) 562 0 R (section.7.2) 566 0 R (section.7.3) 578 0 R (section.8.1) 586 0 R (section.8.2) 594 0 R (section.8.3) 598 0 R (section.A.1) 606 0 R (section.A.2) 614 0 R (section.A.3) 622 0 R (section.B.1) 642 0 R (section.B.10) 678 0 R (section.B.11) 682 0 R (section.B.12) 686 0 R (section.B.13) 690 0 R (section.B.2) 646 0 R (section.B.3) 650 0 R (section.B.4) 654 0 R (section.B.5) 658 0 R (section.B.6) 662 0 R (section.B.7) 666 0 R (section.B.8) 670 0 R (section.B.9) 674 0 R (server_resource_limits) 1331 0 R (server_statement_definition_and_usage) 1274 0 R (server_statement_grammar) 1387 0 R (statistics) 1552 0 R (statistics_counters) 1560 0 R (statschannels) 1385 0 R (statsfile) 1252 0 R (subsection.1.4.1) 26 0 R (subsection.1.4.2) 30 0 R (subsection.1.4.3) 34 0 R (subsection.1.4.4) 38 0 R (subsection.1.4.5) 54 0 R (subsection.1.4.6) 62 0 R (subsection.3.1.1) 98 0 R (subsection.3.1.2) 102 0 R (subsection.3.3.1) 114 0 R (subsection.3.3.2) 126 0 R (subsection.4.2.1) 142 0 R (subsection.4.4.1) 154 0 R (subsection.4.5.1) 162 0 R (subsection.4.5.2) 174 0 R (subsection.4.5.3) 178 0 R (subsection.4.5.4) 182 0 R (subsection.4.5.5) 186 0 R (subsection.4.5.6) 190 0 R (subsection.4.8.1) 206 0 R (subsection.4.8.2) 210 0 R (subsection.4.8.3) 214 0 R (subsection.4.9.1) 222 0 R (subsection.4.9.2) 226 0 R (subsection.6.1.1) 250 0 R (subsection.6.1.2) 262 0 R (subsection.6.2.1) 278 0 R (subsection.6.2.10) 314 0 R (subsection.6.2.11) 326 0 R (subsection.6.2.12) 330 0 R (subsection.6.2.13) 334 0 R (subsection.6.2.14) 338 0 R (subsection.6.2.15) 342 0 R (subsection.6.2.16) 346 0 R (subsection.6.2.17) 422 0 R (subsection.6.2.18) 426 0 R (subsection.6.2.19) 430 0 R (subsection.6.2.2) 282 0 R (subsection.6.2.20) 434 0 R (subsection.6.2.21) 438 0 R (subsection.6.2.22) 442 0 R (subsection.6.2.23) 446 0 R (subsection.6.2.24) 450 0 R (subsection.6.2.25) 454 0 R (subsection.6.2.26) 458 0 R (subsection.6.2.3) 286 0 R (subsection.6.2.4) 290 0 R (subsection.6.2.5) 294 0 R (subsection.6.2.6) 298 0 R (subsection.6.2.7) 302 0 R (subsection.6.2.8) 306 0 R (subsection.6.2.9) 310 0 R (subsection.6.3.1) 482 0 R (subsection.6.3.2) 494 0 R (subsection.6.3.3) 498 0 R (subsection.6.3.4) 502 0 R (subsection.6.3.5) 506 0 R (subsection.6.3.6) 522 0 R (subsection.6.3.7) 526 0 R (subsection.6.4.1) 538 0 R (subsection.7.2.1) 570 0 R (subsection.7.2.2) 574 0 R (subsection.8.1.1) 590 0 R (subsection.A.1.1) 610 0 R (subsection.A.2.1) 618 0 R (subsection.A.3.1) 626 0 R (subsection.A.3.2) 630 0 R (subsection.A.3.3) 634 0 R (subsubsection.1.4.4.1) 42 0 R (subsubsection.1.4.4.2) 46 0 R (subsubsection.1.4.4.3) 50 0 R (subsubsection.1.4.5.1) 58 0 R (subsubsection.3.3.1.1) 118 0 R (subsubsection.3.3.1.2) 122 0 R (subsubsection.4.5.1.1) 166 0 R (subsubsection.4.5.1.2) 170 0 R (subsubsection.6.1.1.1) 254 0 R (subsubsection.6.1.1.2) 258 0 R (subsubsection.6.1.2.1) 266 0 R (subsubsection.6.1.2.2) 270 0 R (subsubsection.6.2.10.1) 318 0 R (subsubsection.6.2.10.2) 322 0 R (subsubsection.6.2.16.1) 350 0 R (subsubsection.6.2.16.10) 386 0 R (subsubsection.6.2.16.11) 390 0 R (subsubsection.6.2.16.12) 394 0 R (subsubsection.6.2.16.13) 398 0 R (subsubsection.6.2.16.14) 402 0 R (subsubsection.6.2.16.15) 406 0 R (subsubsection.6.2.16.16) 410 0 R (subsubsection.6.2.16.17) 414 0 R (subsubsection.6.2.16.18) 418 0 R (subsubsection.6.2.16.2) 354 0 R (subsubsection.6.2.16.3) 358 0 R (subsubsection.6.2.16.4) 362 0 R (subsubsection.6.2.16.5) 366 0 R (subsubsection.6.2.16.6) 370 0 R (subsubsection.6.2.16.7) 374 0 R (subsubsection.6.2.16.8) 378 0 R (subsubsection.6.2.16.9) 382 0 R (subsubsection.6.2.26.1) 462 0 R (subsubsection.6.2.26.2) 466 0 R (subsubsection.6.2.26.3) 470 0 R (subsubsection.6.2.26.4) 474 0 R (subsubsection.6.3.1.1) 486 0 R (subsubsection.6.3.1.2) 490 0 R (subsubsection.6.3.5.1) 510 0 R (subsubsection.6.3.5.2) 514 0 R (subsubsection.6.3.5.3) 518 0 R (subsubsection.6.4.0.1) 534 0 R (subsubsection.6.4.1.1) 542 0 R (subsubsection.6.4.1.2) 546 0 R (subsubsection.6.4.1.3) 550 0 R (subsubsection.6.4.1.4) 554 0 R (table.1.1) 937 0 R (table.1.2) 947 0 R (table.3.1) 1006 0 R (table.3.2) 1038 0 R (table.6.1) 1146 0 R (table.6.10) 1498 0 R (table.6.11) 1509 0 R (table.6.12) 1516 0 R (table.6.13) 1518 0 R (table.6.14) 1525 0 R (table.6.15) 1528 0 R (table.6.16) 1531 0 R (table.6.17) 1546 0 R (table.6.18) 1554 0 R (table.6.19) 1563 0 R (table.6.2) 1170 0 R (table.6.20) 1570 0 R (table.6.21) 1577 0 R (table.6.3) 1178 0 R (table.6.4) 1217 0 R (table.6.5) 1262 0 R (table.6.6) 1353 0 R (table.6.7) 1422 0 R (table.6.8) 1486 0 R (table.6.9) 1496 0 R (the_category_phrase) 1211 0 R (the_sortlist_statement) 1343 0 R (topology) 1338 0 R (tsig) 1085 0 R (tuning) 1354 0 R (types_of_resource_records_and_when_to_use_them) 954 0 R (view_statement_grammar) 1371 0 R (zone_statement_grammar) 1292 0 R (zone_transfers) 1061 0 R (zonefile_format) 1370 0 R]
 /Limits [(Access_Control_Lists) (zonefile_format)]
 >> endobj
-1953 0 obj <<
-/Kids [1952 0 R]
+2116 0 obj <<
+/Kids [2115 0 R]
 >> endobj
-1954 0 obj <<
-/Dests 1953 0 R
+2117 0 obj <<
+/Dests 2116 0 R
 >> endobj
-1955 0 obj <<
+2118 0 obj <<
 /Type /Catalog
-/Pages 1950 0 R
-/Outlines 1951 0 R
-/Names 1954 0 R
+/Pages 2113 0 R
+/Outlines 2114 0 R
+/Names 2117 0 R
 /PageMode /UseOutlines 
-/OpenAction 649 0 R
+/OpenAction 693 0 R
 >> endobj
-1956 0 obj <<
+2119 0 obj <<
 /Author()/Title()/Subject()/Creator(LaTeX with hyperref package)/Producer(pdfeTeX-1.21a)/Keywords()
-/CreationDate (D:20081024041421Z)
+/CreationDate (D:20081116011130Z)
 /PTEX.Fullbanner (This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4) kpathsea version 3.5.4)
 >> endobj
 xref
-0 1957
+0 2120
 0000000001 65535 f 
 0000000002 00000 f 
 0000000003 00000 f 
 0000000004 00000 f 
 0000000000 00000 f 
 0000000009 00000 n 
-0000066894 00000 n 
-0000671475 00000 n 
+0000070820 00000 n 
+0000731720 00000 n 
 0000000054 00000 n 
 0000000086 00000 n 
-0000067018 00000 n 
-0000671403 00000 n 
+0000070944 00000 n 
+0000731648 00000 n 
 0000000133 00000 n 
 0000000173 00000 n 
-0000067143 00000 n 
-0000671317 00000 n 
+0000071069 00000 n 
+0000731562 00000 n 
 0000000221 00000 n 
 0000000273 00000 n 
-0000067268 00000 n 
-0000671231 00000 n 
+0000071194 00000 n 
+0000731476 00000 n 
 0000000321 00000 n 
 0000000377 00000 n 
-0000071531 00000 n 
-0000671121 00000 n 
+0000075519 00000 n 
+0000731366 00000 n 
 0000000425 00000 n 
 0000000478 00000 n 
-0000071656 00000 n 
-0000671047 00000 n 
+0000075643 00000 n 
+0000731292 00000 n 
 0000000531 00000 n 
 0000000572 00000 n 
-0000071781 00000 n 
-0000670960 00000 n 
+0000075768 00000 n 
+0000731205 00000 n 
 0000000625 00000 n 
 0000000674 00000 n 
-0000071906 00000 n 
-0000670873 00000 n 
+0000075892 00000 n 
+0000731118 00000 n 
 0000000727 00000 n 
 0000000757 00000 n 
-0000076184 00000 n 
-0000670749 00000 n 
+0000080171 00000 n 
+0000730994 00000 n 
 0000000810 00000 n 
 0000000861 00000 n 
-0000076309 00000 n 
-0000670675 00000 n 
+0000080296 00000 n 
+0000730920 00000 n 
 0000000919 00000 n 
 0000000964 00000 n 
-0000076434 00000 n 
-0000670588 00000 n 
+0000080421 00000 n 
+0000730833 00000 n 
 0000001022 00000 n 
 0000001062 00000 n 
-0000076559 00000 n 
-0000670514 00000 n 
+0000080546 00000 n 
+0000730759 00000 n 
 0000001120 00000 n 
 0000001162 00000 n 
-0000079531 00000 n 
-0000670390 00000 n 
+0000083518 00000 n 
+0000730635 00000 n 
 0000001215 00000 n 
 0000001260 00000 n 
-0000079656 00000 n 
-0000670329 00000 n 
+0000083643 00000 n 
+0000730574 00000 n 
 0000001318 00000 n 
 0000001355 00000 n 
-0000079781 00000 n 
-0000670255 00000 n 
+0000083768 00000 n 
+0000730500 00000 n 
 0000001408 00000 n 
 0000001463 00000 n 
-0000082709 00000 n 
-0000670130 00000 n 
+0000086696 00000 n 
+0000730375 00000 n 
 0000001509 00000 n 
 0000001556 00000 n 
-0000082834 00000 n 
-0000670056 00000 n 
+0000086821 00000 n 
+0000730301 00000 n 
 0000001604 00000 n 
 0000001648 00000 n 
-0000082959 00000 n 
-0000669969 00000 n 
+0000086946 00000 n 
+0000730214 00000 n 
 0000001696 00000 n 
 0000001735 00000 n 
-0000083084 00000 n 
-0000669882 00000 n 
+0000087071 00000 n 
+0000730127 00000 n 
 0000001783 00000 n 
 0000001825 00000 n 
-0000083208 00000 n 
-0000669795 00000 n 
+0000087195 00000 n 
+0000730040 00000 n 
 0000001873 00000 n 
 0000001936 00000 n 
-0000084291 00000 n 
-0000669721 00000 n 
+0000088275 00000 n 
+0000729966 00000 n 
 0000001984 00000 n 
 0000002034 00000 n 
-0000086001 00000 n 
-0000669593 00000 n 
+0000089985 00000 n 
+0000729838 00000 n 
 0000002080 00000 n 
 0000002126 00000 n 
-0000086125 00000 n 
-0000669480 00000 n 
+0000090109 00000 n 
+0000729725 00000 n 
 0000002174 00000 n 
 0000002218 00000 n 
-0000086250 00000 n 
-0000669404 00000 n 
+0000090234 00000 n 
+0000729649 00000 n 
 0000002271 00000 n 
 0000002323 00000 n 
-0000086375 00000 n 
-0000669327 00000 n 
+0000090359 00000 n 
+0000729572 00000 n 
 0000002377 00000 n 
 0000002436 00000 n 
-0000088903 00000 n 
-0000669236 00000 n 
+0000092896 00000 n 
+0000729481 00000 n 
 0000002485 00000 n 
 0000002523 00000 n 
-0000089155 00000 n 
-0000669119 00000 n 
+0000093155 00000 n 
+0000729364 00000 n 
 0000002572 00000 n 
 0000002618 00000 n 
-0000089281 00000 n 
-0000669001 00000 n 
+0000093284 00000 n 
+0000729246 00000 n 
 0000002672 00000 n 
 0000002739 00000 n 
-0000092488 00000 n 
-0000668922 00000 n 
+0000096500 00000 n 
+0000729167 00000 n 
 0000002798 00000 n 
 0000002842 00000 n 
-0000092614 00000 n 
-0000668843 00000 n 
+0000096628 00000 n 
+0000729088 00000 n 
 0000002901 00000 n 
 0000002949 00000 n 
-0000102943 00000 n 
-0000668764 00000 n 
+0000107160 00000 n 
+0000729009 00000 n 
 0000003003 00000 n 
 0000003036 00000 n 
-0000107874 00000 n 
-0000668632 00000 n 
+0000112147 00000 n 
+0000728877 00000 n 
 0000003083 00000 n 
 0000003126 00000 n 
-0000108000 00000 n 
-0000668553 00000 n 
+0000112276 00000 n 
+0000728798 00000 n 
 0000003175 00000 n 
 0000003205 00000 n 
-0000108126 00000 n 
-0000668421 00000 n 
+0000112405 00000 n 
+0000728666 00000 n 
 0000003254 00000 n 
 0000003292 00000 n 
-0000108252 00000 n 
-0000668356 00000 n 
+0000112534 00000 n 
+0000728601 00000 n 
 0000003346 00000 n 
 0000003388 00000 n 
-0000112543 00000 n 
-0000668263 00000 n 
+0000116796 00000 n 
+0000728508 00000 n 
 0000003437 00000 n 
 0000003496 00000 n 
-0000112670 00000 n 
-0000668131 00000 n 
+0000116925 00000 n 
+0000728376 00000 n 
 0000003545 00000 n 
 0000003578 00000 n 
-0000112799 00000 n 
-0000668066 00000 n 
+0000117054 00000 n 
+0000728311 00000 n 
 0000003632 00000 n 
 0000003681 00000 n 
-0000120171 00000 n 
-0000667934 00000 n 
+0000124364 00000 n 
+0000728179 00000 n 
 0000003730 00000 n 
 0000003758 00000 n 
-0000120298 00000 n 
-0000667816 00000 n 
+0000124493 00000 n 
+0000728061 00000 n 
 0000003812 00000 n 
 0000003881 00000 n 
-0000120427 00000 n 
-0000667737 00000 n 
+0000124622 00000 n 
+0000727982 00000 n 
 0000003940 00000 n 
 0000003988 00000 n 
-0000123302 00000 n 
-0000667658 00000 n 
+0000127456 00000 n 
+0000727903 00000 n 
 0000004047 00000 n 
 0000004092 00000 n 
-0000123431 00000 n 
-0000667565 00000 n 
+0000127585 00000 n 
+0000727810 00000 n 
 0000004146 00000 n 
 0000004214 00000 n 
-0000123560 00000 n 
-0000667472 00000 n 
+0000127714 00000 n 
+0000727717 00000 n 
 0000004268 00000 n 
 0000004338 00000 n 
-0000123689 00000 n 
-0000667379 00000 n 
+0000127843 00000 n 
+0000727624 00000 n 
 0000004392 00000 n 
 0000004455 00000 n 
-0000123817 00000 n 
-0000667286 00000 n 
+0000131746 00000 n 
+0000727531 00000 n 
 0000004509 00000 n 
 0000004564 00000 n 
-0000127463 00000 n 
-0000667207 00000 n 
+0000131875 00000 n 
+0000727452 00000 n 
 0000004618 00000 n 
 0000004650 00000 n 
-0000127592 00000 n 
-0000667114 00000 n 
+0000132004 00000 n 
+0000727359 00000 n 
 0000004699 00000 n 
 0000004727 00000 n 
-0000127721 00000 n 
-0000667021 00000 n 
+0000132133 00000 n 
+0000727266 00000 n 
 0000004776 00000 n 
 0000004808 00000 n 
-0000131327 00000 n 
-0000666889 00000 n 
+0000135910 00000 n 
+0000727134 00000 n 
 0000004857 00000 n 
 0000004887 00000 n 
-0000131456 00000 n 
-0000666810 00000 n 
+0000136039 00000 n 
+0000727055 00000 n 
 0000004941 00000 n 
 0000004982 00000 n 
-0000131584 00000 n 
-0000666717 00000 n 
+0000136168 00000 n 
+0000726962 00000 n 
 0000005036 00000 n 
 0000005078 00000 n 
-0000135026 00000 n 
-0000666638 00000 n 
+0000139609 00000 n 
+0000726883 00000 n 
 0000005132 00000 n 
 0000005177 00000 n 
-0000138100 00000 n 
-0000666520 00000 n 
+0000142684 00000 n 
+0000726765 00000 n 
 0000005226 00000 n 
 0000005272 00000 n 
-0000138229 00000 n 
-0000666441 00000 n 
+0000142813 00000 n 
+0000726686 00000 n 
 0000005326 00000 n 
 0000005386 00000 n 
-0000138357 00000 n 
-0000666362 00000 n 
+0000142941 00000 n 
+0000726607 00000 n 
 0000005440 00000 n 
 0000005509 00000 n 
-0000140837 00000 n 
-0000666229 00000 n 
+0000145423 00000 n 
+0000726474 00000 n 
 0000005556 00000 n 
 0000005609 00000 n 
-0000140966 00000 n 
-0000666150 00000 n 
+0000145552 00000 n 
+0000726395 00000 n 
 0000005658 00000 n 
 0000005714 00000 n 
-0000141095 00000 n 
-0000666071 00000 n 
+0000145681 00000 n 
+0000726316 00000 n 
 0000005763 00000 n 
 0000005812 00000 n 
-0000145279 00000 n 
-0000665938 00000 n 
+0000149865 00000 n 
+0000726183 00000 n 
 0000005859 00000 n 
 0000005911 00000 n 
-0000145408 00000 n 
-0000665820 00000 n 
+0000149994 00000 n 
+0000726065 00000 n 
 0000005960 00000 n 
 0000006011 00000 n 
-0000150015 00000 n 
-0000665702 00000 n 
+0000154684 00000 n 
+0000725947 00000 n 
 0000006065 00000 n 
 0000006110 00000 n 
-0000150142 00000 n 
-0000665623 00000 n 
+0000154812 00000 n 
+0000725868 00000 n 
 0000006169 00000 n 
 0000006203 00000 n 
-0000153580 00000 n 
-0000665544 00000 n 
+0000158401 00000 n 
+0000725789 00000 n 
 0000006262 00000 n 
 0000006310 00000 n 
-0000153709 00000 n 
-0000665426 00000 n 
+0000158529 00000 n 
+0000725671 00000 n 
 0000006364 00000 n 
 0000006404 00000 n 
-0000153838 00000 n 
-0000665347 00000 n 
+0000158658 00000 n 
+0000725592 00000 n 
 0000006463 00000 n 
 0000006497 00000 n 
-0000153967 00000 n 
-0000665268 00000 n 
+0000162385 00000 n 
+0000725513 00000 n 
 0000006556 00000 n 
 0000006604 00000 n 
-0000157817 00000 n 
-0000665135 00000 n 
+0000162514 00000 n 
+0000725380 00000 n 
 0000006653 00000 n 
 0000006703 00000 n 
-0000160916 00000 n 
-0000665056 00000 n 
+0000165534 00000 n 
+0000725301 00000 n 
 0000006757 00000 n 
 0000006804 00000 n 
-0000161044 00000 n 
-0000664963 00000 n 
+0000165662 00000 n 
+0000725208 00000 n 
 0000006858 00000 n 
 0000006918 00000 n 
-0000161303 00000 n 
-0000664870 00000 n 
+0000165920 00000 n 
+0000725115 00000 n 
 0000006972 00000 n 
 0000007024 00000 n 
-0000161432 00000 n 
-0000664777 00000 n 
+0000171027 00000 n 
+0000725022 00000 n 
 0000007078 00000 n 
 0000007143 00000 n 
-0000166331 00000 n 
-0000664684 00000 n 
+0000171156 00000 n 
+0000724929 00000 n 
 0000007197 00000 n 
 0000007248 00000 n 
-0000166460 00000 n 
-0000664591 00000 n 
+0000174630 00000 n 
+0000724836 00000 n 
 0000007302 00000 n 
 0000007366 00000 n 
-0000166589 00000 n 
-0000664498 00000 n 
+0000174759 00000 n 
+0000724743 00000 n 
 0000007420 00000 n 
 0000007467 00000 n 
-0000170354 00000 n 
-0000664405 00000 n 
+0000174888 00000 n 
+0000724650 00000 n 
 0000007521 00000 n 
 0000007581 00000 n 
-0000170483 00000 n 
-0000664312 00000 n 
+0000175017 00000 n 
+0000724557 00000 n 
 0000007635 00000 n 
 0000007686 00000 n 
-0000170612 00000 n 
-0000664180 00000 n 
+0000179033 00000 n 
+0000724425 00000 n 
 0000007741 00000 n 
 0000007806 00000 n 
-0000175144 00000 n 
-0000664101 00000 n 
+0000179162 00000 n 
+0000724346 00000 n 
 0000007866 00000 n 
 0000007913 00000 n 
-0000181571 00000 n 
-0000664022 00000 n 
+0000185987 00000 n 
+0000724267 00000 n 
 0000007973 00000 n 
 0000008021 00000 n 
-0000185205 00000 n 
-0000663929 00000 n 
+0000192355 00000 n 
+0000724174 00000 n 
 0000008076 00000 n 
 0000008126 00000 n 
-0000185334 00000 n 
-0000663836 00000 n 
+0000192484 00000 n 
+0000724081 00000 n 
 0000008181 00000 n 
 0000008244 00000 n 
-0000187219 00000 n 
-0000663743 00000 n 
+0000192612 00000 n 
+0000723988 00000 n 
 0000008299 00000 n 
 0000008351 00000 n 
-0000187348 00000 n 
-0000663650 00000 n 
+0000192740 00000 n 
+0000723895 00000 n 
 0000008406 00000 n 
 0000008471 00000 n 
-0000187477 00000 n 
-0000663557 00000 n 
+0000192869 00000 n 
+0000723802 00000 n 
 0000008526 00000 n 
 0000008578 00000 n 
-0000190809 00000 n 
-0000663424 00000 n 
+0000198137 00000 n 
+0000723669 00000 n 
 0000008633 00000 n 
 0000008698 00000 n 
-0000198905 00000 n 
-0000663345 00000 n 
+0000206589 00000 n 
+0000723590 00000 n 
 0000008758 00000 n 
 0000008802 00000 n 
-0000220055 00000 n 
-0000663252 00000 n 
+0000227810 00000 n 
+0000723497 00000 n 
 0000008862 00000 n 
 0000008901 00000 n 
-0000220184 00000 n 
-0000663159 00000 n 
+0000227938 00000 n 
+0000723404 00000 n 
 0000008961 00000 n 
 0000009008 00000 n 
-0000220313 00000 n 
-0000663066 00000 n 
+0000228067 00000 n 
+0000723311 00000 n 
 0000009068 00000 n 
 0000009111 00000 n 
-0000224587 00000 n 
-0000662973 00000 n 
+0000235196 00000 n 
+0000723218 00000 n 
 0000009171 00000 n 
 0000009210 00000 n 
-0000228114 00000 n 
-0000662880 00000 n 
+0000235325 00000 n 
+0000723125 00000 n 
 0000009270 00000 n 
 0000009312 00000 n 
-0000231064 00000 n 
-0000662787 00000 n 
+0000242275 00000 n 
+0000723032 00000 n 
 0000009372 00000 n 
 0000009415 00000 n 
-0000238656 00000 n 
-0000662694 00000 n 
+0000250260 00000 n 
+0000722939 00000 n 
 0000009475 00000 n 
 0000009518 00000 n 
-0000242961 00000 n 
-0000662601 00000 n 
+0000250389 00000 n 
+0000722846 00000 n 
 0000009578 00000 n 
 0000009639 00000 n 
-0000243090 00000 n 
-0000662508 00000 n 
+0000254380 00000 n 
+0000722753 00000 n 
 0000009700 00000 n 
 0000009752 00000 n 
-0000246876 00000 n 
-0000662415 00000 n 
+0000257620 00000 n 
+0000722660 00000 n 
 0000009813 00000 n 
 0000009866 00000 n 
-0000247005 00000 n 
-0000662322 00000 n 
+0000257749 00000 n 
+0000722567 00000 n 
 0000009927 00000 n 
 0000009965 00000 n 
-0000251036 00000 n 
-0000662229 00000 n 
+0000261821 00000 n 
+0000722474 00000 n 
 0000010026 00000 n 
 0000010078 00000 n 
-0000254054 00000 n 
-0000662136 00000 n 
+0000265032 00000 n 
+0000722381 00000 n 
 0000010139 00000 n 
 0000010183 00000 n 
-0000258009 00000 n 
-0000662043 00000 n 
+0000265290 00000 n 
+0000722288 00000 n 
 0000010244 00000 n 
 0000010280 00000 n 
-0000262835 00000 n 
-0000661950 00000 n 
+0000274081 00000 n 
+0000722195 00000 n 
 0000010341 00000 n 
 0000010404 00000 n 
-0000266161 00000 n 
-0000661857 00000 n 
+0000277408 00000 n 
+0000722102 00000 n 
 0000010465 00000 n 
 0000010515 00000 n 
-0000269322 00000 n 
-0000661764 00000 n 
+0000281163 00000 n 
+0000722023 00000 n 
 0000010576 00000 n 
-0000010625 00000 n 
-0000273049 00000 n 
-0000661685 00000 n 
-0000010686 00000 n 
-0000010742 00000 n 
-0000273177 00000 n 
-0000661592 00000 n 
-0000010797 00000 n 
-0000010848 00000 n 
-0000277701 00000 n 
-0000661499 00000 n 
-0000010903 00000 n 
-0000010967 00000 n 
-0000281213 00000 n 
-0000661406 00000 n 
-0000011022 00000 n 
-0000011079 00000 n 
-0000281342 00000 n 
-0000661313 00000 n 
-0000011134 00000 n 
-0000011204 00000 n 
-0000281471 00000 n 
-0000661220 00000 n 
-0000011259 00000 n 
-0000011308 00000 n 
-0000281600 00000 n 
-0000661127 00000 n 
-0000011363 00000 n 
-0000011425 00000 n 
-0000286259 00000 n 
-0000661034 00000 n 
-0000011480 00000 n 
-0000011529 00000 n 
-0000290062 00000 n 
-0000660916 00000 n 
-0000011584 00000 n 
-0000011646 00000 n 
-0000290191 00000 n 
-0000660837 00000 n 
-0000011706 00000 n 
-0000011745 00000 n 
-0000294250 00000 n 
-0000660744 00000 n 
-0000011805 00000 n 
-0000011839 00000 n 
-0000299864 00000 n 
-0000660651 00000 n 
-0000011899 00000 n 
-0000011940 00000 n 
-0000310269 00000 n 
-0000660572 00000 n 
-0000012000 00000 n 
-0000012052 00000 n 
-0000314360 00000 n 
-0000660454 00000 n 
-0000012101 00000 n 
-0000012134 00000 n 
-0000314488 00000 n 
-0000660336 00000 n 
-0000012188 00000 n 
-0000012260 00000 n 
-0000314616 00000 n 
-0000660257 00000 n 
-0000012319 00000 n 
-0000012363 00000 n 
-0000325410 00000 n 
-0000660178 00000 n 
-0000012422 00000 n 
-0000012475 00000 n 
-0000325798 00000 n 
-0000660085 00000 n 
-0000012529 00000 n 
-0000012579 00000 n 
-0000329220 00000 n 
-0000659992 00000 n 
-0000012633 00000 n 
-0000012671 00000 n 
-0000329479 00000 n 
-0000659899 00000 n 
-0000012725 00000 n 
+0000010632 00000 n 
+0000284537 00000 n 
+0000721930 00000 n 
+0000010687 00000 n 
+0000010751 00000 n 
+0000284666 00000 n 
+0000721837 00000 n 
+0000010806 00000 n 
+0000010883 00000 n 
+0000284794 00000 n 
+0000721744 00000 n 
+0000010938 00000 n 
+0000010989 00000 n 
+0000289362 00000 n 
+0000721651 00000 n 
+0000011044 00000 n 
+0000011108 00000 n 
+0000292729 00000 n 
+0000721558 00000 n 
+0000011163 00000 n 
+0000011220 00000 n 
+0000292857 00000 n 
+0000721465 00000 n 
+0000011275 00000 n 
+0000011345 00000 n 
+0000292986 00000 n 
+0000721372 00000 n 
+0000011400 00000 n 
+0000011449 00000 n 
+0000293115 00000 n 
+0000721279 00000 n 
+0000011504 00000 n 
+0000011566 00000 n 
+0000297818 00000 n 
+0000721186 00000 n 
+0000011621 00000 n 
+0000011670 00000 n 
+0000301909 00000 n 
+0000721068 00000 n 
+0000011725 00000 n 
+0000011787 00000 n 
+0000302038 00000 n 
+0000720989 00000 n 
+0000011847 00000 n 
+0000011886 00000 n 
+0000306096 00000 n 
+0000720896 00000 n 
+0000011946 00000 n 
+0000011980 00000 n 
+0000311992 00000 n 
+0000720803 00000 n 
+0000012040 00000 n 
+0000012081 00000 n 
+0000323134 00000 n 
+0000720724 00000 n 
+0000012141 00000 n 
+0000012193 00000 n 
+0000330383 00000 n 
+0000720592 00000 n 
+0000012242 00000 n 
+0000012275 00000 n 
+0000330512 00000 n 
+0000720474 00000 n 
+0000012329 00000 n 
+0000012401 00000 n 
+0000330640 00000 n 
+0000720395 00000 n 
+0000012460 00000 n 
+0000012504 00000 n 
+0000341427 00000 n 
+0000720316 00000 n 
+0000012563 00000 n 
+0000012616 00000 n 
+0000341814 00000 n 
+0000720223 00000 n 
+0000012670 00000 n 
+0000012720 00000 n 
+0000345189 00000 n 
+0000720130 00000 n 
 0000012774 00000 n 
-0000332384 00000 n 
-0000659767 00000 n 
-0000012828 00000 n 
-0000012880 00000 n 
-0000332512 00000 n 
-0000659688 00000 n 
-0000012939 00000 n 
-0000012991 00000 n 
-0000332641 00000 n 
-0000659595 00000 n 
-0000013050 00000 n 
-0000013103 00000 n 
-0000332769 00000 n 
-0000659516 00000 n 
-0000013162 00000 n 
-0000013211 00000 n 
-0000332898 00000 n 
-0000659423 00000 n 
-0000013265 00000 n 
-0000013345 00000 n 
-0000336811 00000 n 
-0000659344 00000 n 
-0000013399 00000 n 
-0000013448 00000 n 
-0000340557 00000 n 
-0000659211 00000 n 
-0000013495 00000 n 
-0000013547 00000 n 
-0000340686 00000 n 
-0000659132 00000 n 
-0000013596 00000 n 
-0000013640 00000 n 
-0000344779 00000 n 
-0000659000 00000 n 
-0000013689 00000 n 
-0000013730 00000 n 
-0000344908 00000 n 
-0000658921 00000 n 
+0000012812 00000 n 
+0000345448 00000 n 
+0000720037 00000 n 
+0000012866 00000 n 
+0000012915 00000 n 
+0000348312 00000 n 
+0000719905 00000 n 
+0000012969 00000 n 
+0000013021 00000 n 
+0000348440 00000 n 
+0000719826 00000 n 
+0000013080 00000 n 
+0000013132 00000 n 
+0000348569 00000 n 
+0000719733 00000 n 
+0000013191 00000 n 
+0000013244 00000 n 
+0000348698 00000 n 
+0000719654 00000 n 
+0000013303 00000 n 
+0000013352 00000 n 
+0000352344 00000 n 
+0000719561 00000 n 
+0000013406 00000 n 
+0000013486 00000 n 
+0000356394 00000 n 
+0000719482 00000 n 
+0000013540 00000 n 
+0000013589 00000 n 
+0000356523 00000 n 
+0000719364 00000 n 
+0000013638 00000 n 
+0000013678 00000 n 
+0000359826 00000 n 
+0000719285 00000 n 
+0000013737 00000 n 
 0000013784 00000 n 
-0000013832 00000 n 
-0000345037 00000 n 
-0000658842 00000 n 
-0000013886 00000 n 
-0000013937 00000 n 
-0000345166 00000 n 
-0000658763 00000 n 
-0000013986 00000 n 
-0000014033 00000 n 
-0000349429 00000 n 
-0000658630 00000 n 
-0000014080 00000 n 
-0000014117 00000 n 
-0000349558 00000 n 
-0000658512 00000 n 
-0000014166 00000 n 
-0000014205 00000 n 
-0000349687 00000 n 
-0000658447 00000 n 
-0000014259 00000 n 
-0000014337 00000 n 
-0000349816 00000 n 
-0000658354 00000 n 
-0000014386 00000 n 
-0000014453 00000 n 
-0000349945 00000 n 
-0000658275 00000 n 
-0000014502 00000 n 
-0000014547 00000 n 
-0000353384 00000 n 
-0000658142 00000 n 
-0000014595 00000 n 
-0000014627 00000 n 
-0000353513 00000 n 
-0000658024 00000 n 
-0000014676 00000 n 
-0000014715 00000 n 
-0000353642 00000 n 
-0000657959 00000 n 
-0000014769 00000 n 
-0000014830 00000 n 
-0000357407 00000 n 
-0000657827 00000 n 
-0000014879 00000 n 
-0000014936 00000 n 
-0000357536 00000 n 
-0000657762 00000 n 
-0000014990 00000 n 
-0000015039 00000 n 
-0000357665 00000 n 
-0000657644 00000 n 
-0000015088 00000 n 
-0000015150 00000 n 
-0000357794 00000 n 
-0000657565 00000 n 
-0000015204 00000 n 
-0000015259 00000 n 
-0000381817 00000 n 
-0000657472 00000 n 
-0000015313 00000 n 
-0000015354 00000 n 
-0000381946 00000 n 
-0000657393 00000 n 
-0000015408 00000 n 
-0000015460 00000 n 
-0000384676 00000 n 
-0000657273 00000 n 
-0000015508 00000 n 
-0000015542 00000 n 
-0000384805 00000 n 
-0000657194 00000 n 
-0000015591 00000 n 
-0000015618 00000 n 
-0000402812 00000 n 
-0000657101 00000 n 
-0000015667 00000 n 
-0000015695 00000 n 
-0000410349 00000 n 
-0000657008 00000 n 
-0000015744 00000 n 
-0000015781 00000 n 
-0000416667 00000 n 
-0000656915 00000 n 
-0000015830 00000 n 
-0000015869 00000 n 
-0000426187 00000 n 
-0000656822 00000 n 
-0000015918 00000 n 
-0000015957 00000 n 
-0000429074 00000 n 
-0000656729 00000 n 
-0000016006 00000 n 
-0000016045 00000 n 
-0000435466 00000 n 
-0000656636 00000 n 
-0000016094 00000 n 
-0000016123 00000 n 
-0000444851 00000 n 
-0000656543 00000 n 
-0000016172 00000 n 
-0000016200 00000 n 
-0000448491 00000 n 
-0000656450 00000 n 
-0000016249 00000 n 
-0000016282 00000 n 
-0000457889 00000 n 
-0000656371 00000 n 
-0000016332 00000 n 
-0000016369 00000 n 
-0000016738 00000 n 
-0000016860 00000 n 
-0000024689 00000 n 
-0000016422 00000 n 
-0000024563 00000 n 
-0000024626 00000 n 
-0000652234 00000 n 
-0000626291 00000 n 
-0000652060 00000 n 
-0000653259 00000 n 
-0000019723 00000 n 
-0000019940 00000 n 
-0000020009 00000 n 
-0000020078 00000 n 
-0000020146 00000 n 
-0000020214 00000 n 
-0000020263 00000 n 
-0000020310 00000 n 
-0000020643 00000 n 
-0000020665 00000 n 
-0000020833 00000 n 
-0000020998 00000 n 
-0000021167 00000 n 
-0000021346 00000 n 
-0000021655 00000 n 
-0000021815 00000 n 
-0000026053 00000 n 
-0000025868 00000 n 
-0000024789 00000 n 
-0000025990 00000 n 
-0000625079 00000 n 
-0000598600 00000 n 
-0000624905 00000 n 
-0000597915 00000 n 
-0000595770 00000 n 
-0000597751 00000 n 
-0000037759 00000 n 
-0000029109 00000 n 
-0000026138 00000 n 
-0000037633 00000 n 
-0000037696 00000 n 
-0000029643 00000 n 
-0000029797 00000 n 
-0000029954 00000 n 
-0000030111 00000 n 
-0000030267 00000 n 
-0000030424 00000 n 
-0000030586 00000 n 
-0000030747 00000 n 
-0000030908 00000 n 
-0000031070 00000 n 
-0000031237 00000 n 
-0000031404 00000 n 
-0000031569 00000 n 
-0000031731 00000 n 
-0000031897 00000 n 
-0000032058 00000 n 
-0000032213 00000 n 
-0000032370 00000 n 
-0000032526 00000 n 
-0000032683 00000 n 
-0000032840 00000 n 
-0000032997 00000 n 
-0000033151 00000 n 
-0000033307 00000 n 
-0000033469 00000 n 
-0000033631 00000 n 
-0000033787 00000 n 
-0000033944 00000 n 
-0000034106 00000 n 
-0000034273 00000 n 
-0000034439 00000 n 
-0000034600 00000 n 
-0000034755 00000 n 
-0000034912 00000 n 
-0000035069 00000 n 
-0000035231 00000 n 
-0000035388 00000 n 
-0000035545 00000 n 
-0000035707 00000 n 
-0000035864 00000 n 
-0000036026 00000 n 
-0000036193 00000 n 
-0000036359 00000 n 
-0000036521 00000 n 
-0000036683 00000 n 
-0000036845 00000 n 
-0000037006 00000 n 
-0000037168 00000 n 
-0000037323 00000 n 
-0000037478 00000 n 
-0000051124 00000 n 
-0000041076 00000 n 
-0000037844 00000 n 
-0000051061 00000 n 
-0000595219 00000 n 
-0000578138 00000 n 
-0000595035 00000 n 
-0000041666 00000 n 
-0000041829 00000 n 
-0000041991 00000 n 
-0000042154 00000 n 
-0000042312 00000 n 
-0000042475 00000 n 
-0000042638 00000 n 
-0000042793 00000 n 
-0000042951 00000 n 
-0000043109 00000 n 
-0000043265 00000 n 
-0000043423 00000 n 
-0000043586 00000 n 
-0000043754 00000 n 
-0000043922 00000 n 
-0000044085 00000 n 
-0000044253 00000 n 
-0000044421 00000 n 
-0000044579 00000 n 
-0000044742 00000 n 
-0000044905 00000 n 
-0000045067 00000 n 
-0000045229 00000 n 
-0000045392 00000 n 
-0000045554 00000 n 
-0000045716 00000 n 
-0000045879 00000 n 
-0000046042 00000 n 
-0000046205 00000 n 
-0000046374 00000 n 
-0000046543 00000 n 
-0000046707 00000 n 
-0000046870 00000 n 
-0000047034 00000 n 
-0000047198 00000 n 
-0000047361 00000 n 
-0000047525 00000 n 
-0000047694 00000 n 
-0000047862 00000 n 
-0000048031 00000 n 
-0000048200 00000 n 
-0000048369 00000 n 
-0000048538 00000 n 
-0000048707 00000 n 
-0000048876 00000 n 
-0000049045 00000 n 
-0000049215 00000 n 
-0000049385 00000 n 
-0000049555 00000 n 
-0000049724 00000 n 
-0000049894 00000 n 
-0000050064 00000 n 
-0000050232 00000 n 
-0000050401 00000 n 
-0000050571 00000 n 
-0000050738 00000 n 
-0000050899 00000 n 
-0000063946 00000 n 
-0000054652 00000 n 
-0000051222 00000 n 
-0000063883 00000 n 
-0000055218 00000 n 
-0000055381 00000 n 
-0000055544 00000 n 
-0000055707 00000 n 
-0000055870 00000 n 
-0000056032 00000 n 
-0000056195 00000 n 
-0000056363 00000 n 
-0000056531 00000 n 
-0000056699 00000 n 
-0000056867 00000 n 
-0000057023 00000 n 
-0000057185 00000 n 
-0000057352 00000 n 
-0000057519 00000 n 
-0000057681 00000 n 
-0000057843 00000 n 
-0000058005 00000 n 
-0000058167 00000 n 
-0000058334 00000 n 
-0000058501 00000 n 
-0000058667 00000 n 
-0000058829 00000 n 
-0000058991 00000 n 
-0000059146 00000 n 
+0000359955 00000 n 
+0000719167 00000 n 
+0000013838 00000 n 
+0000013883 00000 n 
+0000360084 00000 n 
+0000719088 00000 n 
+0000013942 00000 n 
+0000014001 00000 n 
+0000363183 00000 n 
+0000718995 00000 n 
+0000014060 00000 n 
+0000014124 00000 n 
+0000363442 00000 n 
+0000718902 00000 n 
+0000014183 00000 n 
+0000014239 00000 n 
+0000366164 00000 n 
+0000718823 00000 n 
+0000014298 00000 n 
+0000014360 00000 n 
+0000368398 00000 n 
+0000718690 00000 n 
+0000014407 00000 n 
+0000014459 00000 n 
+0000368527 00000 n 
+0000718611 00000 n 
+0000014508 00000 n 
+0000014552 00000 n 
+0000372713 00000 n 
+0000718479 00000 n 
+0000014601 00000 n 
+0000014642 00000 n 
+0000372842 00000 n 
+0000718400 00000 n 
+0000014696 00000 n 
+0000014744 00000 n 
+0000372970 00000 n 
+0000718321 00000 n 
+0000014798 00000 n 
+0000014849 00000 n 
+0000373099 00000 n 
+0000718242 00000 n 
+0000014898 00000 n 
+0000014945 00000 n 
+0000377366 00000 n 
+0000718109 00000 n 
+0000014992 00000 n 
+0000015029 00000 n 
+0000377495 00000 n 
+0000717991 00000 n 
+0000015078 00000 n 
+0000015117 00000 n 
+0000377624 00000 n 
+0000717926 00000 n 
+0000015171 00000 n 
+0000015249 00000 n 
+0000377753 00000 n 
+0000717833 00000 n 
+0000015298 00000 n 
+0000015365 00000 n 
+0000377882 00000 n 
+0000717754 00000 n 
+0000015414 00000 n 
+0000015459 00000 n 
+0000381321 00000 n 
+0000717621 00000 n 
+0000015507 00000 n 
+0000015539 00000 n 
+0000381450 00000 n 
+0000717503 00000 n 
+0000015588 00000 n 
+0000015627 00000 n 
+0000381579 00000 n 
+0000717438 00000 n 
+0000015681 00000 n 
+0000015742 00000 n 
+0000385344 00000 n 
+0000717306 00000 n 
+0000015791 00000 n 
+0000015848 00000 n 
+0000385473 00000 n 
+0000717241 00000 n 
+0000015902 00000 n 
+0000015951 00000 n 
+0000385602 00000 n 
+0000717123 00000 n 
+0000016000 00000 n 
+0000016062 00000 n 
+0000385731 00000 n 
+0000717044 00000 n 
+0000016116 00000 n 
+0000016171 00000 n 
+0000409752 00000 n 
+0000716951 00000 n 
+0000016225 00000 n 
+0000016266 00000 n 
+0000409881 00000 n 
+0000716872 00000 n 
+0000016320 00000 n 
+0000016372 00000 n 
+0000412612 00000 n 
+0000716752 00000 n 
+0000016420 00000 n 
+0000016454 00000 n 
+0000412741 00000 n 
+0000716673 00000 n 
+0000016503 00000 n 
+0000016530 00000 n 
+0000430434 00000 n 
+0000716580 00000 n 
+0000016579 00000 n 
+0000016607 00000 n 
+0000437928 00000 n 
+0000716487 00000 n 
+0000016656 00000 n 
+0000016696 00000 n 
+0000440723 00000 n 
+0000716394 00000 n 
+0000016745 00000 n 
+0000016788 00000 n 
+0000446647 00000 n 
+0000716301 00000 n 
+0000016837 00000 n 
+0000016874 00000 n 
+0000453150 00000 n 
+0000716208 00000 n 
+0000016923 00000 n 
+0000016962 00000 n 
+0000462862 00000 n 
+0000716115 00000 n 
+0000017011 00000 n 
+0000017050 00000 n 
+0000465578 00000 n 
+0000716022 00000 n 
+0000017099 00000 n 
+0000017138 00000 n 
+0000475305 00000 n 
+0000715929 00000 n 
+0000017187 00000 n 
+0000017216 00000 n 
+0000481121 00000 n 
+0000715836 00000 n 
+0000017266 00000 n 
+0000017299 00000 n 
+0000495077 00000 n 
+0000715743 00000 n 
+0000017349 00000 n 
+0000017378 00000 n 
+0000498576 00000 n 
+0000715650 00000 n 
+0000017428 00000 n 
+0000017462 00000 n 
+0000504687 00000 n 
+0000715571 00000 n 
+0000017512 00000 n 
+0000017549 00000 n 
+0000017918 00000 n 
+0000018040 00000 n 
+0000025869 00000 n 
+0000017602 00000 n 
+0000025743 00000 n 
+0000025806 00000 n 
+0000711071 00000 n 
+0000685128 00000 n 
+0000710897 00000 n 
+0000712096 00000 n 
+0000020903 00000 n 
+0000021120 00000 n 
+0000021189 00000 n 
+0000021258 00000 n 
+0000021326 00000 n 
+0000021394 00000 n 
+0000021443 00000 n 
+0000021490 00000 n 
+0000021823 00000 n 
+0000021845 00000 n 
+0000022013 00000 n 
+0000022178 00000 n 
+0000022347 00000 n 
+0000022526 00000 n 
+0000022835 00000 n 
+0000022995 00000 n 
+0000027233 00000 n 
+0000027048 00000 n 
+0000025969 00000 n 
+0000027170 00000 n 
+0000683907 00000 n 
+0000657386 00000 n 
+0000683733 00000 n 
+0000656701 00000 n 
+0000654557 00000 n 
+0000656537 00000 n 
+0000038940 00000 n 
+0000030289 00000 n 
+0000027318 00000 n 
+0000038814 00000 n 
+0000038877 00000 n 
+0000030823 00000 n 
+0000030977 00000 n 
+0000031134 00000 n 
+0000031291 00000 n 
+0000031447 00000 n 
+0000031604 00000 n 
+0000031766 00000 n 
+0000031927 00000 n 
+0000032088 00000 n 
+0000032250 00000 n 
+0000032417 00000 n 
+0000032584 00000 n 
+0000032749 00000 n 
+0000032911 00000 n 
+0000033077 00000 n 
+0000033238 00000 n 
+0000033393 00000 n 
+0000033550 00000 n 
+0000033706 00000 n 
+0000033863 00000 n 
+0000034020 00000 n 
+0000034177 00000 n 
+0000034331 00000 n 
+0000034487 00000 n 
+0000034649 00000 n 
+0000034811 00000 n 
+0000034967 00000 n 
+0000035124 00000 n 
+0000035286 00000 n 
+0000035453 00000 n 
+0000035619 00000 n 
+0000035780 00000 n 
+0000035935 00000 n 
+0000036092 00000 n 
+0000036249 00000 n 
+0000036411 00000 n 
+0000036568 00000 n 
+0000036725 00000 n 
+0000036887 00000 n 
+0000037044 00000 n 
+0000037206 00000 n 
+0000037373 00000 n 
+0000037539 00000 n 
+0000037701 00000 n 
+0000037863 00000 n 
+0000038025 00000 n 
+0000038187 00000 n 
+0000038349 00000 n 
+0000038504 00000 n 
+0000038659 00000 n 
+0000052318 00000 n 
+0000042272 00000 n 
+0000039025 00000 n 
+0000052255 00000 n 
+0000654006 00000 n 
+0000636925 00000 n 
+0000653822 00000 n 
+0000042862 00000 n 
+0000043025 00000 n 
+0000043187 00000 n 
+0000043350 00000 n 
+0000043508 00000 n 
+0000043671 00000 n 
+0000043834 00000 n 
+0000043989 00000 n 
+0000044147 00000 n 
+0000044305 00000 n 
+0000044461 00000 n 
+0000044619 00000 n 
+0000044782 00000 n 
+0000044950 00000 n 
+0000045118 00000 n 
+0000045281 00000 n 
+0000045449 00000 n 
+0000045617 00000 n 
+0000045775 00000 n 
+0000045938 00000 n 
+0000046101 00000 n 
+0000046263 00000 n 
+0000046425 00000 n 
+0000046588 00000 n 
+0000046750 00000 n 
+0000046912 00000 n 
+0000047075 00000 n 
+0000047238 00000 n 
+0000047401 00000 n 
+0000047570 00000 n 
+0000047739 00000 n 
+0000047903 00000 n 
+0000048066 00000 n 
+0000048230 00000 n 
+0000048394 00000 n 
+0000048557 00000 n 
+0000048721 00000 n 
+0000048890 00000 n 
+0000049059 00000 n 
+0000049228 00000 n 
+0000049397 00000 n 
+0000049566 00000 n 
+0000049735 00000 n 
+0000049904 00000 n 
+0000050073 00000 n 
+0000050242 00000 n 
+0000050412 00000 n 
+0000050582 00000 n 
+0000050752 00000 n 
+0000050922 00000 n 
+0000051092 00000 n 
+0000051262 00000 n 
+0000051432 00000 n 
+0000051601 00000 n 
+0000051771 00000 n 
+0000051932 00000 n 
+0000052093 00000 n 
+0000065459 00000 n 
+0000055941 00000 n 
+0000052416 00000 n 
+0000065396 00000 n 
+0000056515 00000 n 
+0000056678 00000 n 
+0000056841 00000 n 
+0000057004 00000 n 
+0000057167 00000 n 
+0000057330 00000 n 
+0000057493 00000 n 
+0000057656 00000 n 
+0000057824 00000 n 
+0000057991 00000 n 
+0000058159 00000 n 
+0000058327 00000 n 
+0000058484 00000 n 
+0000058646 00000 n 
+0000058811 00000 n 
+0000058977 00000 n 
+0000059139 00000 n 
 0000059301 00000 n 
-0000059458 00000 n 
-0000059620 00000 n 
-0000059782 00000 n 
-0000059939 00000 n 
-0000060094 00000 n 
-0000060251 00000 n 
-0000060413 00000 n 
-0000060569 00000 n 
-0000060726 00000 n 
-0000060882 00000 n 
-0000061039 00000 n 
-0000061201 00000 n 
-0000061358 00000 n 
-0000061520 00000 n 
-0000061677 00000 n 
-0000061838 00000 n 
-0000062000 00000 n 
-0000062162 00000 n 
-0000062317 00000 n 
-0000062473 00000 n 
-0000062630 00000 n 
-0000062787 00000 n 
-0000062944 00000 n 
-0000063100 00000 n 
-0000063257 00000 n 
-0000063414 00000 n 
-0000577172 00000 n 
-0000557205 00000 n 
-0000576999 00000 n 
-0000063571 00000 n 
-0000063727 00000 n 
-0000064391 00000 n 
-0000064206 00000 n 
-0000064057 00000 n 
-0000064328 00000 n 
-0000067519 00000 n 
-0000066709 00000 n 
-0000064432 00000 n 
-0000066831 00000 n 
-0000066955 00000 n 
-0000067080 00000 n 
-0000067205 00000 n 
-0000556316 00000 n 
-0000534984 00000 n 
-0000556142 00000 n 
-0000067330 00000 n 
-0000067393 00000 n 
-0000067456 00000 n 
-0000534210 00000 n 
-0000516663 00000 n 
-0000534037 00000 n 
-0000653377 00000 n 
-0000072030 00000 n 
-0000070848 00000 n 
-0000067643 00000 n 
-0000071342 00000 n 
-0000071405 00000 n 
-0000071468 00000 n 
-0000071593 00000 n 
-0000071718 00000 n 
-0000071843 00000 n 
-0000070998 00000 n 
-0000071191 00000 n 
-0000071968 00000 n 
-0000314552 00000 n 
-0000357858 00000 n 
-0000076684 00000 n 
-0000075648 00000 n 
-0000072154 00000 n 
-0000076121 00000 n 
-0000076246 00000 n 
-0000075798 00000 n 
-0000075960 00000 n 
-0000076371 00000 n 
-0000076496 00000 n 
-0000076621 00000 n 
-0000092551 00000 n 
-0000079906 00000 n 
-0000079346 00000 n 
-0000076808 00000 n 
-0000079468 00000 n 
-0000079593 00000 n 
-0000079718 00000 n 
-0000079843 00000 n 
+0000059463 00000 n 
+0000059625 00000 n 
+0000059792 00000 n 
+0000059959 00000 n 
+0000060126 00000 n 
+0000060288 00000 n 
+0000060450 00000 n 
+0000060607 00000 n 
+0000060774 00000 n 
+0000060936 00000 n 
+0000061103 00000 n 
+0000061270 00000 n 
+0000636036 00000 n 
+0000614704 00000 n 
+0000635862 00000 n 
+0000061437 00000 n 
+0000061604 00000 n 
+0000061759 00000 n 
+0000061916 00000 n 
+0000062073 00000 n 
+0000062235 00000 n 
+0000062396 00000 n 
+0000062552 00000 n 
+0000062707 00000 n 
+0000062864 00000 n 
+0000063026 00000 n 
+0000063183 00000 n 
+0000063340 00000 n 
+0000063496 00000 n 
+0000063652 00000 n 
+0000063813 00000 n 
+0000063970 00000 n 
+0000064132 00000 n 
+0000064289 00000 n 
+0000064451 00000 n 
+0000064613 00000 n 
+0000064775 00000 n 
+0000064931 00000 n 
+0000065086 00000 n 
+0000065241 00000 n 
+0000068260 00000 n 
+0000066412 00000 n 
+0000065570 00000 n 
+0000068197 00000 n 
+0000066626 00000 n 
+0000066783 00000 n 
+0000066940 00000 n 
+0000067096 00000 n 
+0000067253 00000 n 
+0000067409 00000 n 
+0000067566 00000 n 
+0000067724 00000 n 
+0000613738 00000 n 
+0000593771 00000 n 
+0000613565 00000 n 
+0000067882 00000 n 
+0000068039 00000 n 
+0000071445 00000 n 
+0000070635 00000 n 
+0000068358 00000 n 
+0000070757 00000 n 
+0000070881 00000 n 
+0000071006 00000 n 
+0000071131 00000 n 
+0000071256 00000 n 
+0000071319 00000 n 
+0000071382 00000 n 
+0000592977 00000 n 
+0000574660 00000 n 
+0000592804 00000 n 
+0000712214 00000 n 
+0000076016 00000 n 
+0000074836 00000 n 
+0000071569 00000 n 
+0000075330 00000 n 
+0000075393 00000 n 
+0000075456 00000 n 
+0000075580 00000 n 
+0000075705 00000 n 
+0000075830 00000 n 
+0000074986 00000 n 
+0000075179 00000 n 
+0000075953 00000 n 
+0000330576 00000 n 
+0000385795 00000 n 
+0000080671 00000 n 
+0000079635 00000 n 
+0000076140 00000 n 
+0000080108 00000 n 
+0000080233 00000 n 
+0000079785 00000 n 
+0000079947 00000 n 
+0000080358 00000 n 
+0000080483 00000 n 
+0000080608 00000 n 
+0000096564 00000 n 
+0000083893 00000 n 
 0000083333 00000 n 
-0000082192 00000 n 
-0000080017 00000 n 
-0000082646 00000 n 
-0000082771 00000 n 
-0000082896 00000 n 
-0000083021 00000 n 
-0000083146 00000 n 
-0000082342 00000 n 
-0000082494 00000 n 
-0000083270 00000 n 
-0000273113 00000 n 
-0000084416 00000 n 
-0000084106 00000 n 
-0000083418 00000 n 
-0000084228 00000 n 
-0000084353 00000 n 
-0000086501 00000 n 
-0000085816 00000 n 
-0000084514 00000 n 
-0000085938 00000 n 
-0000086063 00000 n 
-0000086187 00000 n 
-0000086312 00000 n 
-0000086438 00000 n 
-0000653495 00000 n 
-0000089406 00000 n 
-0000088538 00000 n 
-0000086599 00000 n 
-0000088840 00000 n 
-0000088966 00000 n 
-0000089029 00000 n 
-0000089092 00000 n 
-0000088680 00000 n 
-0000089218 00000 n 
-0000089344 00000 n 
-0000254118 00000 n 
-0000092740 00000 n 
-0000092303 00000 n 
-0000089517 00000 n 
-0000092425 00000 n 
-0000516007 00000 n 
-0000504421 00000 n 
-0000515830 00000 n 
-0000092677 00000 n 
-0000096525 00000 n 
-0000096340 00000 n 
-0000092864 00000 n 
-0000096462 00000 n 
-0000503882 00000 n 
-0000494141 00000 n 
-0000503705 00000 n 
-0000100909 00000 n 
-0000100518 00000 n 
-0000096688 00000 n 
-0000100846 00000 n 
-0000100660 00000 n 
-0000161496 00000 n 
-0000103195 00000 n 
-0000102758 00000 n 
-0000101046 00000 n 
-0000102880 00000 n 
-0000103006 00000 n 
-0000103069 00000 n 
-0000103132 00000 n 
-0000105847 00000 n 
-0000108379 00000 n 
-0000105696 00000 n 
-0000103319 00000 n 
-0000107811 00000 n 
-0000107937 00000 n 
-0000108063 00000 n 
-0000107489 00000 n 
-0000107650 00000 n 
-0000493282 00000 n 
-0000483910 00000 n 
-0000493110 00000 n 
-0000483348 00000 n 
-0000474265 00000 n 
-0000483175 00000 n 
-0000108189 00000 n 
-0000108315 00000 n 
-0000653613 00000 n 
-0000107318 00000 n 
-0000107376 00000 n 
-0000107466 00000 n 
-0000198969 00000 n 
-0000231128 00000 n 
-0000112928 00000 n 
-0000111994 00000 n 
-0000108531 00000 n 
-0000112478 00000 n 
-0000112606 00000 n 
-0000112150 00000 n 
-0000112316 00000 n 
-0000112734 00000 n 
-0000112863 00000 n 
-0000361883 00000 n 
-0000116420 00000 n 
-0000116040 00000 n 
-0000113079 00000 n 
-0000116355 00000 n 
-0000116187 00000 n 
-0000117654 00000 n 
-0000117463 00000 n 
-0000116545 00000 n 
-0000117589 00000 n 
-0000120556 00000 n 
-0000119980 00000 n 
-0000117753 00000 n 
-0000120106 00000 n 
-0000120233 00000 n 
-0000120362 00000 n 
-0000120491 00000 n 
-0000123946 00000 n 
-0000123111 00000 n 
-0000120694 00000 n 
-0000123237 00000 n 
-0000123366 00000 n 
-0000123495 00000 n 
-0000123624 00000 n 
-0000123752 00000 n 
-0000123881 00000 n 
-0000127849 00000 n 
-0000127081 00000 n 
-0000124084 00000 n 
-0000127398 00000 n 
-0000127228 00000 n 
-0000127527 00000 n 
-0000127656 00000 n 
-0000127785 00000 n 
-0000653737 00000 n 
-0000310333 00000 n 
-0000131713 00000 n 
-0000131136 00000 n 
-0000127961 00000 n 
-0000131262 00000 n 
-0000131391 00000 n 
-0000131519 00000 n 
-0000131648 00000 n 
-0000135155 00000 n 
-0000134835 00000 n 
-0000131851 00000 n 
-0000134961 00000 n 
-0000135090 00000 n 
-0000138486 00000 n 
-0000137727 00000 n 
-0000135267 00000 n 
-0000138035 00000 n 
-0000138164 00000 n 
-0000137874 00000 n 
-0000138293 00000 n 
-0000138421 00000 n 
-0000357600 00000 n 
-0000141224 00000 n 
-0000140646 00000 n 
-0000138652 00000 n 
-0000140772 00000 n 
-0000140901 00000 n 
-0000141030 00000 n 
-0000141159 00000 n 
-0000141664 00000 n 
-0000141473 00000 n 
-0000141323 00000 n 
-0000141599 00000 n 
-0000145666 00000 n 
-0000144900 00000 n 
-0000141706 00000 n 
-0000145214 00000 n 
-0000145343 00000 n 
-0000145471 00000 n 
-0000145536 00000 n 
-0000145601 00000 n 
-0000145047 00000 n 
-0000653862 00000 n 
-0000150078 00000 n 
-0000150270 00000 n 
-0000149824 00000 n 
-0000145765 00000 n 
-0000149950 00000 n 
-0000150205 00000 n 
-0000154096 00000 n 
-0000153389 00000 n 
-0000150395 00000 n 
-0000153515 00000 n 
-0000153644 00000 n 
-0000153773 00000 n 
-0000153902 00000 n 
-0000154031 00000 n 
-0000156826 00000 n 
-0000158075 00000 n 
-0000156700 00000 n 
-0000154221 00000 n 
-0000157752 00000 n 
-0000157881 00000 n 
-0000157946 00000 n 
-0000158010 00000 n 
-0000161559 00000 n 
-0000160725 00000 n 
-0000158229 00000 n 
-0000160851 00000 n 
-0000160980 00000 n 
-0000161108 00000 n 
-0000161173 00000 n 
-0000161238 00000 n 
-0000161367 00000 n 
-0000166717 00000 n 
-0000165800 00000 n 
-0000161671 00000 n 
-0000166266 00000 n 
-0000165956 00000 n 
-0000166107 00000 n 
-0000166395 00000 n 
-0000166524 00000 n 
-0000166652 00000 n 
-0000460456 00000 n 
-0000170741 00000 n 
-0000169599 00000 n 
-0000166855 00000 n 
-0000170289 00000 n 
-0000170418 00000 n 
-0000169764 00000 n 
-0000169916 00000 n 
-0000170103 00000 n 
-0000170547 00000 n 
-0000170676 00000 n 
-0000653987 00000 n 
-0000175273 00000 n 
-0000174953 00000 n 
-0000170866 00000 n 
-0000175079 00000 n 
-0000175208 00000 n 
-0000178462 00000 n 
-0000178083 00000 n 
-0000175398 00000 n 
-0000178397 00000 n 
-0000178230 00000 n 
-0000181635 00000 n 
-0000181830 00000 n 
-0000181380 00000 n 
-0000178574 00000 n 
-0000181506 00000 n 
-0000181700 00000 n 
-0000181765 00000 n 
-0000185463 00000 n 
-0000184678 00000 n 
-0000181942 00000 n 
-0000185140 00000 n 
-0000185269 00000 n 
-0000185398 00000 n 
-0000184834 00000 n 
-0000184987 00000 n 
-0000187606 00000 n 
-0000187028 00000 n 
-0000185575 00000 n 
-0000187154 00000 n 
-0000187283 00000 n 
-0000187412 00000 n 
-0000187541 00000 n 
-0000189177 00000 n 
-0000188986 00000 n 
-0000187718 00000 n 
-0000189112 00000 n 
-0000654112 00000 n 
-0000190937 00000 n 
-0000190618 00000 n 
-0000189276 00000 n 
-0000190744 00000 n 
-0000190873 00000 n 
-0000195079 00000 n 
-0000194711 00000 n 
-0000191049 00000 n 
-0000195014 00000 n 
-0000194858 00000 n 
-0000269386 00000 n 
-0000199034 00000 n 
-0000198714 00000 n 
-0000195204 00000 n 
-0000198840 00000 n 
-0000202871 00000 n 
-0000202551 00000 n 
-0000199159 00000 n 
-0000202677 00000 n 
-0000202742 00000 n 
-0000202806 00000 n 
-0000208134 00000 n 
-0000206840 00000 n 
-0000202996 00000 n 
-0000208069 00000 n 
-0000207032 00000 n 
-0000207186 00000 n 
-0000207342 00000 n 
-0000207527 00000 n 
-0000207701 00000 n 
-0000207885 00000 n 
-0000277765 00000 n 
-0000212392 00000 n 
-0000212201 00000 n 
-0000208313 00000 n 
-0000212327 00000 n 
-0000654237 00000 n 
-0000216088 00000 n 
-0000215897 00000 n 
-0000212517 00000 n 
-0000216023 00000 n 
-0000220442 00000 n 
-0000219499 00000 n 
-0000216200 00000 n 
-0000219990 00000 n 
-0000220119 00000 n 
-0000219655 00000 n 
-0000220248 00000 n 
-0000220377 00000 n 
-0000219824 00000 n 
-0000286323 00000 n 
-0000224715 00000 n 
-0000224024 00000 n 
-0000220608 00000 n 
-0000224522 00000 n 
-0000224180 00000 n 
-0000224351 00000 n 
-0000224651 00000 n 
-0000345230 00000 n 
-0000228243 00000 n 
-0000227923 00000 n 
-0000224840 00000 n 
-0000228049 00000 n 
-0000228178 00000 n 
-0000231193 00000 n 
-0000230873 00000 n 
-0000228355 00000 n 
-0000230999 00000 n 
-0000235248 00000 n 
-0000235057 00000 n 
-0000231346 00000 n 
-0000235183 00000 n 
-0000654362 00000 n 
+0000080795 00000 n 
+0000083455 00000 n 
+0000083580 00000 n 
+0000083705 00000 n 
+0000083830 00000 n 
+0000087320 00000 n 
+0000086179 00000 n 
+0000084004 00000 n 
+0000086633 00000 n 
+0000086758 00000 n 
+0000086883 00000 n 
+0000087008 00000 n 
+0000087133 00000 n 
+0000086329 00000 n 
+0000086481 00000 n 
+0000087257 00000 n 
+0000281227 00000 n 
+0000088400 00000 n 
+0000088090 00000 n 
+0000087405 00000 n 
+0000088212 00000 n 
+0000088337 00000 n 
+0000090485 00000 n 
+0000089800 00000 n 
+0000088498 00000 n 
+0000089922 00000 n 
+0000090047 00000 n 
+0000090171 00000 n 
+0000090296 00000 n 
+0000090422 00000 n 
+0000712332 00000 n 
+0000093412 00000 n 
+0000092524 00000 n 
+0000090583 00000 n 
+0000092831 00000 n 
+0000092960 00000 n 
+0000093025 00000 n 
+0000093090 00000 n 
+0000092670 00000 n 
+0000093219 00000 n 
+0000093348 00000 n 
+0000265096 00000 n 
+0000096757 00000 n 
+0000096310 00000 n 
+0000093524 00000 n 
+0000096435 00000 n 
+0000573985 00000 n 
+0000561996 00000 n 
+0000573806 00000 n 
+0000096692 00000 n 
+0000100548 00000 n 
+0000100358 00000 n 
+0000096883 00000 n 
+0000100483 00000 n 
+0000561455 00000 n 
+0000551709 00000 n 
+0000561276 00000 n 
+0000105074 00000 n 
+0000104676 00000 n 
+0000100714 00000 n 
+0000105009 00000 n 
+0000104822 00000 n 
+0000171091 00000 n 
+0000107419 00000 n 
+0000106970 00000 n 
+0000105213 00000 n 
+0000107095 00000 n 
+0000107224 00000 n 
+0000107289 00000 n 
+0000107354 00000 n 
+0000110116 00000 n 
+0000112663 00000 n 
+0000109960 00000 n 
+0000107544 00000 n 
+0000112082 00000 n 
+0000112211 00000 n 
+0000112340 00000 n 
+0000111759 00000 n 
+0000111921 00000 n 
+0000550839 00000 n 
+0000541419 00000 n 
+0000550665 00000 n 
+0000540855 00000 n 
+0000531769 00000 n 
+0000540680 00000 n 
+0000112469 00000 n 
+0000112598 00000 n 
+0000712455 00000 n 
+0000111588 00000 n 
+0000111646 00000 n 
+0000111736 00000 n 
+0000206653 00000 n 
+0000242339 00000 n 
+0000117183 00000 n 
+0000116248 00000 n 
+0000112819 00000 n 
+0000116731 00000 n 
+0000116860 00000 n 
+0000116404 00000 n 
+0000116569 00000 n 
+0000116989 00000 n 
+0000117118 00000 n 
+0000389821 00000 n 
+0000120797 00000 n 
+0000120417 00000 n 
+0000117335 00000 n 
+0000120732 00000 n 
+0000120564 00000 n 
+0000122047 00000 n 
+0000121856 00000 n 
+0000120922 00000 n 
+0000121982 00000 n 
+0000124750 00000 n 
+0000124173 00000 n 
+0000122146 00000 n 
+0000124299 00000 n 
+0000124428 00000 n 
+0000124557 00000 n 
+0000124686 00000 n 
+0000127972 00000 n 
+0000127265 00000 n 
+0000124888 00000 n 
+0000127391 00000 n 
+0000127520 00000 n 
+0000127649 00000 n 
+0000127778 00000 n 
+0000127907 00000 n 
+0000132261 00000 n 
+0000131363 00000 n 
+0000128097 00000 n 
+0000131681 00000 n 
+0000131810 00000 n 
+0000131510 00000 n 
+0000131939 00000 n 
+0000132068 00000 n 
+0000132196 00000 n 
+0000712580 00000 n 
+0000323198 00000 n 
+0000136297 00000 n 
+0000135719 00000 n 
+0000132386 00000 n 
+0000135845 00000 n 
+0000135974 00000 n 
+0000136103 00000 n 
+0000136232 00000 n 
+0000139738 00000 n 
+0000139418 00000 n 
+0000136435 00000 n 
+0000139544 00000 n 
+0000139673 00000 n 
+0000143070 00000 n 
+0000142311 00000 n 
+0000139850 00000 n 
+0000142619 00000 n 
+0000142748 00000 n 
+0000142458 00000 n 
+0000142877 00000 n 
+0000143005 00000 n 
+0000385537 00000 n 
+0000145810 00000 n 
+0000145232 00000 n 
+0000143238 00000 n 
+0000145358 00000 n 
+0000145487 00000 n 
+0000145616 00000 n 
+0000145745 00000 n 
+0000146250 00000 n 
+0000146059 00000 n 
+0000145909 00000 n 
+0000146185 00000 n 
+0000150252 00000 n 
+0000149486 00000 n 
+0000146292 00000 n 
+0000149800 00000 n 
+0000149929 00000 n 
+0000150057 00000 n 
+0000150122 00000 n 
+0000150187 00000 n 
+0000149633 00000 n 
+0000712705 00000 n 
+0000154748 00000 n 
+0000154940 00000 n 
+0000154493 00000 n 
+0000150351 00000 n 
+0000154619 00000 n 
+0000154875 00000 n 
+0000158787 00000 n 
+0000158210 00000 n 
+0000155065 00000 n 
+0000158336 00000 n 
+0000158464 00000 n 
+0000158593 00000 n 
+0000158722 00000 n 
+0000161394 00000 n 
+0000162773 00000 n 
+0000161268 00000 n 
+0000158925 00000 n 
+0000162320 00000 n 
+0000162449 00000 n 
+0000162578 00000 n 
+0000162643 00000 n 
+0000162708 00000 n 
+0000166049 00000 n 
+0000165343 00000 n 
+0000162928 00000 n 
+0000165469 00000 n 
+0000165597 00000 n 
+0000165726 00000 n 
+0000165790 00000 n 
+0000165855 00000 n 
+0000165984 00000 n 
+0000171284 00000 n 
+0000170496 00000 n 
+0000166161 00000 n 
+0000170962 00000 n 
+0000170652 00000 n 
+0000170803 00000 n 
+0000171220 00000 n 
+0000510397 00000 n 
+0000175146 00000 n 
+0000173875 00000 n 
+0000171422 00000 n 
+0000174565 00000 n 
+0000174694 00000 n 
+0000174823 00000 n 
+0000174952 00000 n 
+0000174040 00000 n 
+0000174192 00000 n 
+0000174378 00000 n 
+0000175081 00000 n 
+0000712830 00000 n 
+0000179291 00000 n 
+0000178842 00000 n 
+0000175272 00000 n 
+0000178968 00000 n 
+0000179097 00000 n 
+0000179226 00000 n 
+0000183212 00000 n 
+0000182833 00000 n 
+0000179416 00000 n 
+0000183147 00000 n 
+0000182980 00000 n 
+0000186051 00000 n 
+0000186245 00000 n 
+0000185796 00000 n 
+0000183324 00000 n 
+0000185922 00000 n 
+0000186116 00000 n 
+0000186181 00000 n 
+0000189675 00000 n 
+0000189484 00000 n 
+0000186357 00000 n 
+0000189610 00000 n 
+0000192997 00000 n 
+0000191830 00000 n 
+0000189787 00000 n 
+0000192290 00000 n 
+0000192419 00000 n 
+0000192548 00000 n 
+0000191986 00000 n 
+0000192140 00000 n 
+0000192676 00000 n 
+0000192804 00000 n 
+0000192932 00000 n 
+0000194483 00000 n 
+0000194292 00000 n 
+0000193109 00000 n 
+0000194418 00000 n 
+0000712955 00000 n 
+0000196016 00000 n 
+0000195825 00000 n 
+0000194582 00000 n 
+0000195951 00000 n 
+0000198266 00000 n 
+0000197946 00000 n 
+0000196115 00000 n 
+0000198072 00000 n 
+0000198201 00000 n 
+0000202789 00000 n 
+0000202420 00000 n 
+0000198378 00000 n 
+0000202724 00000 n 
+0000202567 00000 n 
+0000359890 00000 n 
+0000206718 00000 n 
+0000206398 00000 n 
+0000202927 00000 n 
+0000206524 00000 n 
+0000210794 00000 n 
+0000210300 00000 n 
+0000206843 00000 n 
+0000210599 00000 n 
+0000210664 00000 n 
+0000210729 00000 n 
+0000210447 00000 n 
+0000215794 00000 n 
+0000214662 00000 n 
+0000210919 00000 n 
+0000215729 00000 n 
+0000214845 00000 n 
+0000215002 00000 n 
+0000215186 00000 n 
+0000215359 00000 n 
+0000215544 00000 n 
+0000713080 00000 n 
+0000289426 00000 n 
+0000220074 00000 n 
+0000219883 00000 n 
+0000215975 00000 n 
+0000220009 00000 n 
+0000223936 00000 n 
+0000223745 00000 n 
+0000220199 00000 n 
+0000223871 00000 n 
+0000228196 00000 n 
+0000227253 00000 n 
+0000224048 00000 n 
+0000227745 00000 n 
+0000227873 00000 n 
+0000227409 00000 n 
+0000228002 00000 n 
+0000228131 00000 n 
+0000227579 00000 n 
+0000297882 00000 n 
+0000232129 00000 n 
+0000231567 00000 n 
+0000228365 00000 n 
+0000232064 00000 n 
+0000231723 00000 n 
+0000231893 00000 n 
+0000373163 00000 n 
+0000235454 00000 n 
+0000235005 00000 n 
+0000232298 00000 n 
+0000235131 00000 n 
+0000235260 00000 n 
+0000235389 00000 n 
+0000238850 00000 n 
+0000238659 00000 n 
+0000235579 00000 n 
 0000238785 00000 n 
-0000238284 00000 n 
-0000235401 00000 n 
-0000238591 00000 n 
-0000238720 00000 n 
-0000238431 00000 n 
-0000243217 00000 n 
-0000242410 00000 n 
-0000238951 00000 n 
-0000242896 00000 n 
-0000243025 00000 n 
-0000242566 00000 n 
-0000243153 00000 n 
-0000242741 00000 n 
-0000247134 00000 n 
-0000246685 00000 n 
-0000243329 00000 n 
-0000246811 00000 n 
-0000246940 00000 n 
-0000247069 00000 n 
-0000251164 00000 n 
-0000250497 00000 n 
-0000247287 00000 n 
-0000250971 00000 n 
-0000251100 00000 n 
-0000250653 00000 n 
-0000250815 00000 n 
-0000254312 00000 n 
-0000253673 00000 n 
-0000251330 00000 n 
-0000253989 00000 n 
-0000253820 00000 n 
-0000254182 00000 n 
-0000254247 00000 n 
-0000258137 00000 n 
-0000257637 00000 n 
-0000254437 00000 n 
-0000257944 00000 n 
-0000258073 00000 n 
-0000257784 00000 n 
-0000654487 00000 n 
-0000262963 00000 n 
-0000262285 00000 n 
-0000258316 00000 n 
-0000262770 00000 n 
-0000262441 00000 n 
-0000473910 00000 n 
-0000471912 00000 n 
-0000473745 00000 n 
-0000262898 00000 n 
-0000262603 00000 n 
-0000336875 00000 n 
-0000281535 00000 n 
-0000266290 00000 n 
-0000265970 00000 n 
-0000263089 00000 n 
-0000266096 00000 n 
-0000266225 00000 n 
-0000269580 00000 n 
-0000269131 00000 n 
-0000266456 00000 n 
-0000269257 00000 n 
-0000269451 00000 n 
-0000269515 00000 n 
-0000273306 00000 n 
-0000272858 00000 n 
-0000269679 00000 n 
-0000272984 00000 n 
-0000273241 00000 n 
-0000277829 00000 n 
-0000277340 00000 n 
-0000273418 00000 n 
-0000277636 00000 n 
-0000277487 00000 n 
-0000281728 00000 n 
-0000280676 00000 n 
-0000277941 00000 n 
-0000281148 00000 n 
-0000280832 00000 n 
-0000281277 00000 n 
-0000281406 00000 n 
-0000280994 00000 n 
-0000281664 00000 n 
-0000654612 00000 n 
-0000284830 00000 n 
-0000284639 00000 n 
-0000281840 00000 n 
-0000284765 00000 n 
-0000286388 00000 n 
-0000286068 00000 n 
-0000284942 00000 n 
-0000286194 00000 n 
-0000287824 00000 n 
-0000287633 00000 n 
-0000286500 00000 n 
-0000287759 00000 n 
-0000290450 00000 n 
-0000289871 00000 n 
-0000287923 00000 n 
-0000289997 00000 n 
-0000290126 00000 n 
-0000290255 00000 n 
-0000290320 00000 n 
-0000290385 00000 n 
-0000294379 00000 n 
-0000294059 00000 n 
-0000290562 00000 n 
-0000294185 00000 n 
-0000294314 00000 n 
-0000299993 00000 n 
-0000297603 00000 n 
-0000294491 00000 n 
-0000299799 00000 n 
-0000299928 00000 n 
-0000297849 00000 n 
-0000298011 00000 n 
-0000298173 00000 n 
-0000298334 00000 n 
-0000298494 00000 n 
-0000298665 00000 n 
-0000298827 00000 n 
-0000298989 00000 n 
-0000299149 00000 n 
-0000299310 00000 n 
-0000299473 00000 n 
-0000299636 00000 n 
-0000654737 00000 n 
-0000305217 00000 n 
-0000303157 00000 n 
-0000300118 00000 n 
-0000305152 00000 n 
-0000303394 00000 n 
-0000303554 00000 n 
-0000303716 00000 n 
-0000303877 00000 n 
-0000304038 00000 n 
-0000304200 00000 n 
-0000304363 00000 n 
-0000304517 00000 n 
-0000304670 00000 n 
-0000304832 00000 n 
-0000304992 00000 n 
-0000310526 00000 n 
-0000308563 00000 n 
-0000305342 00000 n 
-0000310204 00000 n 
-0000308782 00000 n 
-0000308942 00000 n 
-0000309104 00000 n 
-0000309263 00000 n 
-0000309422 00000 n 
-0000309575 00000 n 
-0000309738 00000 n 
-0000309888 00000 n 
-0000310050 00000 n 
-0000310398 00000 n 
-0000310462 00000 n 
-0000314874 00000 n 
-0000313808 00000 n 
-0000310651 00000 n 
-0000314295 00000 n 
-0000314423 00000 n 
-0000314680 00000 n 
-0000313964 00000 n 
-0000314134 00000 n 
-0000314745 00000 n 
-0000314810 00000 n 
-0000318327 00000 n 
-0000318006 00000 n 
-0000314999 00000 n 
-0000318132 00000 n 
-0000318197 00000 n 
-0000318262 00000 n 
-0000321897 00000 n 
-0000321576 00000 n 
-0000318426 00000 n 
-0000321702 00000 n 
-0000321767 00000 n 
-0000321832 00000 n 
-0000325927 00000 n 
-0000325219 00000 n 
-0000322009 00000 n 
-0000325345 00000 n 
-0000325474 00000 n 
-0000325539 00000 n 
-0000325604 00000 n 
-0000325668 00000 n 
-0000325733 00000 n 
-0000325862 00000 n 
-0000654862 00000 n 
-0000329738 00000 n 
-0000328899 00000 n 
-0000326052 00000 n 
-0000329025 00000 n 
-0000329090 00000 n 
-0000329155 00000 n 
-0000329284 00000 n 
-0000329349 00000 n 
-0000329414 00000 n 
-0000329543 00000 n 
-0000329608 00000 n 
-0000329673 00000 n 
-0000333026 00000 n 
-0000332193 00000 n 
-0000329917 00000 n 
-0000332319 00000 n 
-0000332448 00000 n 
-0000332576 00000 n 
-0000332704 00000 n 
-0000332833 00000 n 
-0000332962 00000 n 
-0000336940 00000 n 
-0000336490 00000 n 
-0000333219 00000 n 
-0000336616 00000 n 
-0000336681 00000 n 
-0000336746 00000 n 
-0000338422 00000 n 
-0000338231 00000 n 
-0000337065 00000 n 
-0000338357 00000 n 
-0000338875 00000 n 
-0000338684 00000 n 
-0000338534 00000 n 
-0000338810 00000 n 
-0000340815 00000 n 
-0000340366 00000 n 
-0000338917 00000 n 
-0000340492 00000 n 
-0000340621 00000 n 
-0000340750 00000 n 
-0000654987 00000 n 
-0000345295 00000 n 
-0000344351 00000 n 
-0000340927 00000 n 
-0000344714 00000 n 
-0000471591 00000 n 
-0000462378 00000 n 
-0000471405 00000 n 
-0000344498 00000 n 
-0000344843 00000 n 
-0000344972 00000 n 
-0000345101 00000 n 
-0000346333 00000 n 
-0000346142 00000 n 
-0000345528 00000 n 
-0000346268 00000 n 
-0000346760 00000 n 
-0000346569 00000 n 
-0000346419 00000 n 
-0000346695 00000 n 
-0000350073 00000 n 
-0000348847 00000 n 
-0000346802 00000 n 
-0000349364 00000 n 
-0000349493 00000 n 
-0000349622 00000 n 
-0000349751 00000 n 
-0000349880 00000 n 
-0000350009 00000 n 
-0000349003 00000 n 
-0000349175 00000 n 
-0000350527 00000 n 
-0000350336 00000 n 
-0000350186 00000 n 
-0000350462 00000 n 
-0000353771 00000 n 
-0000353193 00000 n 
-0000350569 00000 n 
-0000353319 00000 n 
-0000353448 00000 n 
-0000353577 00000 n 
-0000353706 00000 n 
-0000655112 00000 n 
-0000358050 00000 n 
-0000356831 00000 n 
-0000353857 00000 n 
-0000357342 00000 n 
-0000357471 00000 n 
-0000357729 00000 n 
-0000356987 00000 n 
-0000357166 00000 n 
-0000357922 00000 n 
-0000357986 00000 n 
-0000364935 00000 n 
-0000361107 00000 n 
-0000358202 00000 n 
-0000361233 00000 n 
-0000361298 00000 n 
-0000361363 00000 n 
-0000361428 00000 n 
-0000361493 00000 n 
-0000361558 00000 n 
-0000361623 00000 n 
-0000361688 00000 n 
-0000361753 00000 n 
-0000361818 00000 n 
-0000361948 00000 n 
-0000362013 00000 n 
-0000362078 00000 n 
-0000362143 00000 n 
-0000362208 00000 n 
-0000362273 00000 n 
-0000362338 00000 n 
-0000362403 00000 n 
-0000362468 00000 n 
-0000362533 00000 n 
-0000362598 00000 n 
-0000362663 00000 n 
-0000362728 00000 n 
-0000362793 00000 n 
-0000362858 00000 n 
-0000362923 00000 n 
-0000362988 00000 n 
-0000363053 00000 n 
+0000713205 00000 n 
+0000242404 00000 n 
+0000242084 00000 n 
+0000239019 00000 n 
+0000242210 00000 n 
+0000246107 00000 n 
+0000245916 00000 n 
+0000242560 00000 n 
+0000246042 00000 n 
+0000250518 00000 n 
+0000249704 00000 n 
+0000246276 00000 n 
+0000250195 00000 n 
+0000250324 00000 n 
+0000249860 00000 n 
+0000250453 00000 n 
+0000250021 00000 n 
+0000254509 00000 n 
+0000254014 00000 n 
+0000250673 00000 n 
+0000254315 00000 n 
+0000254444 00000 n 
+0000254161 00000 n 
+0000257878 00000 n 
+0000257429 00000 n 
+0000254634 00000 n 
+0000257555 00000 n 
+0000257684 00000 n 
+0000257813 00000 n 
+0000261950 00000 n 
+0000261283 00000 n 
+0000258033 00000 n 
+0000261756 00000 n 
+0000261885 00000 n 
+0000261439 00000 n 
+0000261601 00000 n 
+0000713330 00000 n 
+0000265418 00000 n 
+0000264650 00000 n 
+0000262119 00000 n 
+0000264967 00000 n 
+0000264797 00000 n 
+0000265160 00000 n 
+0000265225 00000 n 
+0000265354 00000 n 
+0000269455 00000 n 
+0000269083 00000 n 
+0000265601 00000 n 
+0000269390 00000 n 
+0000269230 00000 n 
+0000274209 00000 n 
+0000273530 00000 n 
+0000269623 00000 n 
+0000274016 00000 n 
+0000273686 00000 n 
+0000531414 00000 n 
+0000529417 00000 n 
+0000531249 00000 n 
+0000274144 00000 n 
+0000273849 00000 n 
+0000356458 00000 n 
+0000293050 00000 n 
+0000277537 00000 n 
+0000277217 00000 n 
+0000274335 00000 n 
+0000277343 00000 n 
+0000277472 00000 n 
+0000281291 00000 n 
+0000280972 00000 n 
+0000277662 00000 n 
+0000281098 00000 n 
+0000284923 00000 n 
+0000284346 00000 n 
+0000281433 00000 n 
+0000284472 00000 n 
+0000284601 00000 n 
+0000284730 00000 n 
+0000284858 00000 n 
+0000713455 00000 n 
+0000289491 00000 n 
+0000289000 00000 n 
+0000285035 00000 n 
+0000289297 00000 n 
+0000289147 00000 n 
+0000293243 00000 n 
+0000292193 00000 n 
+0000289603 00000 n 
+0000292664 00000 n 
+0000292349 00000 n 
+0000292792 00000 n 
+0000292921 00000 n 
+0000292511 00000 n 
+0000293179 00000 n 
+0000296310 00000 n 
+0000296119 00000 n 
+0000293355 00000 n 
+0000296245 00000 n 
+0000297947 00000 n 
+0000297627 00000 n 
+0000296422 00000 n 
+0000297753 00000 n 
+0000299421 00000 n 
+0000299230 00000 n 
+0000298059 00000 n 
+0000299356 00000 n 
+0000302297 00000 n 
+0000301718 00000 n 
+0000299520 00000 n 
+0000301844 00000 n 
+0000301973 00000 n 
+0000302102 00000 n 
+0000302167 00000 n 
+0000302232 00000 n 
+0000713580 00000 n 
+0000306225 00000 n 
+0000305905 00000 n 
+0000302409 00000 n 
+0000306031 00000 n 
+0000306160 00000 n 
+0000312121 00000 n 
+0000309387 00000 n 
+0000306337 00000 n 
+0000311927 00000 n 
+0000312056 00000 n 
+0000309651 00000 n 
+0000309813 00000 n 
+0000309975 00000 n 
+0000310136 00000 n 
+0000310296 00000 n 
+0000310458 00000 n 
+0000310629 00000 n 
+0000310791 00000 n 
+0000310953 00000 n 
+0000311114 00000 n 
+0000311275 00000 n 
+0000311438 00000 n 
+0000311601 00000 n 
+0000311764 00000 n 
+0000317105 00000 n 
+0000315364 00000 n 
+0000312233 00000 n 
+0000317040 00000 n 
+0000315583 00000 n 
+0000315744 00000 n 
+0000315913 00000 n 
+0000316075 00000 n 
+0000316237 00000 n 
+0000316399 00000 n 
+0000316560 00000 n 
+0000316723 00000 n 
+0000316877 00000 n 
+0000323263 00000 n 
+0000320266 00000 n 
+0000317230 00000 n 
+0000323069 00000 n 
+0000320548 00000 n 
+0000320702 00000 n 
+0000320856 00000 n 
+0000321010 00000 n 
+0000321164 00000 n 
+0000321325 00000 n 
+0000321487 00000 n 
+0000321647 00000 n 
+0000321807 00000 n 
+0000321969 00000 n 
+0000322129 00000 n 
+0000322288 00000 n 
+0000322439 00000 n 
+0000322602 00000 n 
+0000322753 00000 n 
+0000322915 00000 n 
+0000326791 00000 n 
+0000326470 00000 n 
+0000323375 00000 n 
+0000326596 00000 n 
+0000326661 00000 n 
+0000326726 00000 n 
+0000331027 00000 n 
+0000329830 00000 n 
+0000326960 00000 n 
+0000330318 00000 n 
+0000330447 00000 n 
+0000330704 00000 n 
+0000329986 00000 n 
+0000330156 00000 n 
+0000330769 00000 n 
+0000330834 00000 n 
+0000330899 00000 n 
+0000330963 00000 n 
+0000713705 00000 n 
+0000334374 00000 n 
+0000334183 00000 n 
+0000331209 00000 n 
+0000334309 00000 n 
+0000338114 00000 n 
+0000337793 00000 n 
+0000334460 00000 n 
+0000337919 00000 n 
+0000337984 00000 n 
+0000338049 00000 n 
+0000341943 00000 n 
+0000341236 00000 n 
+0000338226 00000 n 
+0000341362 00000 n 
+0000341491 00000 n 
+0000341554 00000 n 
+0000341619 00000 n 
+0000341684 00000 n 
+0000341749 00000 n 
+0000341878 00000 n 
+0000345707 00000 n 
+0000344868 00000 n 
+0000342055 00000 n 
+0000344994 00000 n 
+0000345059 00000 n 
+0000345124 00000 n 
+0000345253 00000 n 
+0000345318 00000 n 
+0000345383 00000 n 
+0000345512 00000 n 
+0000345577 00000 n 
+0000345642 00000 n 
+0000348826 00000 n 
+0000348121 00000 n 
+0000345832 00000 n 
+0000348247 00000 n 
+0000348375 00000 n 
+0000348504 00000 n 
+0000348633 00000 n 
+0000348762 00000 n 
+0000352603 00000 n 
+0000352153 00000 n 
+0000349023 00000 n 
+0000352279 00000 n 
+0000352408 00000 n 
+0000352473 00000 n 
+0000352538 00000 n 
+0000713830 00000 n 
+0000356782 00000 n 
+0000356024 00000 n 
+0000352742 00000 n 
+0000356329 00000 n 
+0000356587 00000 n 
+0000356652 00000 n 
+0000356717 00000 n 
+0000356171 00000 n 
+0000360343 00000 n 
+0000359635 00000 n 
+0000356907 00000 n 
+0000359761 00000 n 
+0000360019 00000 n 
+0000360148 00000 n 
+0000360213 00000 n 
+0000360278 00000 n 
+0000363634 00000 n 
+0000362992 00000 n 
+0000360455 00000 n 
 0000363118 00000 n 
-0000363183 00000 n 
-0000363248 00000 n 
-0000363313 00000 n 
-0000363378 00000 n 
-0000363443 00000 n 
-0000363507 00000 n 
-0000363572 00000 n 
-0000363637 00000 n 
-0000363702 00000 n 
-0000363767 00000 n 
-0000363832 00000 n 
-0000363897 00000 n 
-0000363962 00000 n 
-0000364027 00000 n 
-0000364092 00000 n 
-0000364157 00000 n 
-0000364222 00000 n 
-0000364287 00000 n 
-0000364352 00000 n 
-0000364417 00000 n 
-0000364482 00000 n 
-0000364547 00000 n 
-0000364612 00000 n 
-0000364677 00000 n 
-0000364742 00000 n 
-0000364807 00000 n 
-0000364871 00000 n 
-0000371581 00000 n 
-0000368017 00000 n 
-0000365047 00000 n 
-0000368143 00000 n 
-0000368208 00000 n 
-0000368273 00000 n 
-0000368338 00000 n 
-0000368403 00000 n 
-0000368468 00000 n 
-0000368533 00000 n 
-0000368598 00000 n 
-0000368663 00000 n 
-0000368728 00000 n 
-0000368793 00000 n 
-0000368858 00000 n 
-0000368922 00000 n 
-0000368987 00000 n 
-0000369052 00000 n 
-0000369117 00000 n 
-0000369182 00000 n 
-0000369247 00000 n 
-0000369312 00000 n 
-0000369377 00000 n 
-0000369442 00000 n 
-0000369507 00000 n 
-0000369572 00000 n 
-0000369637 00000 n 
-0000369701 00000 n 
-0000369766 00000 n 
-0000369831 00000 n 
-0000369896 00000 n 
-0000369961 00000 n 
-0000370026 00000 n 
-0000370091 00000 n 
-0000370156 00000 n 
-0000370221 00000 n 
-0000370286 00000 n 
-0000370351 00000 n 
-0000370416 00000 n 
-0000370481 00000 n 
-0000370546 00000 n 
-0000370611 00000 n 
-0000370676 00000 n 
-0000370740 00000 n 
-0000370804 00000 n 
-0000370868 00000 n 
-0000370933 00000 n 
-0000370998 00000 n 
-0000371063 00000 n 
-0000371128 00000 n 
-0000371193 00000 n 
-0000371258 00000 n 
-0000371323 00000 n 
-0000371388 00000 n 
-0000371453 00000 n 
-0000371517 00000 n 
-0000377756 00000 n 
-0000374318 00000 n 
-0000371693 00000 n 
-0000374444 00000 n 
-0000374509 00000 n 
-0000374574 00000 n 
-0000374639 00000 n 
-0000374704 00000 n 
-0000374769 00000 n 
-0000374834 00000 n 
-0000374899 00000 n 
-0000374964 00000 n 
-0000375029 00000 n 
-0000375094 00000 n 
-0000375159 00000 n 
-0000375224 00000 n 
-0000375289 00000 n 
-0000375354 00000 n 
-0000375419 00000 n 
-0000375484 00000 n 
-0000375549 00000 n 
-0000375614 00000 n 
-0000375679 00000 n 
-0000375744 00000 n 
-0000375809 00000 n 
-0000375874 00000 n 
-0000375939 00000 n 
-0000376004 00000 n 
-0000376069 00000 n 
-0000376134 00000 n 
-0000376199 00000 n 
-0000376264 00000 n 
-0000376329 00000 n 
-0000376394 00000 n 
-0000376459 00000 n 
-0000376524 00000 n 
-0000376589 00000 n 
-0000376653 00000 n 
-0000376718 00000 n 
-0000376783 00000 n 
-0000376848 00000 n 
-0000376913 00000 n 
-0000376978 00000 n 
-0000377043 00000 n 
-0000377108 00000 n 
-0000377173 00000 n 
-0000377238 00000 n 
-0000377303 00000 n 
-0000377368 00000 n 
-0000377433 00000 n 
-0000377498 00000 n 
-0000377563 00000 n 
-0000377628 00000 n 
-0000377692 00000 n 
-0000382335 00000 n 
-0000380071 00000 n 
-0000377868 00000 n 
-0000380197 00000 n 
-0000380262 00000 n 
-0000380327 00000 n 
-0000380392 00000 n 
-0000380457 00000 n 
-0000380522 00000 n 
-0000380587 00000 n 
-0000380652 00000 n 
-0000380717 00000 n 
-0000380782 00000 n 
-0000380847 00000 n 
-0000380912 00000 n 
-0000380977 00000 n 
-0000381042 00000 n 
-0000381104 00000 n 
-0000381168 00000 n 
-0000381233 00000 n 
-0000381297 00000 n 
-0000381362 00000 n 
-0000381427 00000 n 
-0000381492 00000 n 
-0000381557 00000 n 
-0000381622 00000 n 
-0000381687 00000 n 
-0000381752 00000 n 
-0000381881 00000 n 
-0000382010 00000 n 
-0000382075 00000 n 
-0000382140 00000 n 
-0000382205 00000 n 
-0000382270 00000 n 
-0000385129 00000 n 
-0000384485 00000 n 
-0000382460 00000 n 
-0000384611 00000 n 
-0000384740 00000 n 
-0000384869 00000 n 
-0000384934 00000 n 
-0000384999 00000 n 
-0000385064 00000 n 
-0000655237 00000 n 
-0000389467 00000 n 
-0000389147 00000 n 
-0000385241 00000 n 
-0000389273 00000 n 
-0000389338 00000 n 
-0000389403 00000 n 
-0000392936 00000 n 
+0000363247 00000 n 
+0000363312 00000 n 
+0000363377 00000 n 
+0000363506 00000 n 
+0000363570 00000 n 
+0000366293 00000 n 
+0000365908 00000 n 
+0000363746 00000 n 
+0000366034 00000 n 
+0000366099 00000 n 
+0000529136 00000 n 
+0000521853 00000 n 
+0000528956 00000 n 
+0000366228 00000 n 
+0000366760 00000 n 
+0000366569 00000 n 
+0000366419 00000 n 
+0000366695 00000 n 
+0000368655 00000 n 
+0000368207 00000 n 
+0000366802 00000 n 
+0000368333 00000 n 
+0000368462 00000 n 
+0000368591 00000 n 
+0000713955 00000 n 
+0000373228 00000 n 
+0000372285 00000 n 
+0000368767 00000 n 
+0000372648 00000 n 
+0000521532 00000 n 
+0000512319 00000 n 
+0000521346 00000 n 
+0000372432 00000 n 
+0000372777 00000 n 
+0000372905 00000 n 
+0000373034 00000 n 
+0000374270 00000 n 
+0000374079 00000 n 
+0000373465 00000 n 
+0000374205 00000 n 
+0000374697 00000 n 
+0000374506 00000 n 
+0000374356 00000 n 
+0000374632 00000 n 
+0000378010 00000 n 
+0000376784 00000 n 
+0000374739 00000 n 
+0000377301 00000 n 
+0000377430 00000 n 
+0000377559 00000 n 
+0000377688 00000 n 
+0000377817 00000 n 
+0000377946 00000 n 
+0000376940 00000 n 
+0000377112 00000 n 
+0000378464 00000 n 
+0000378273 00000 n 
+0000378123 00000 n 
+0000378399 00000 n 
+0000381708 00000 n 
+0000381130 00000 n 
+0000378506 00000 n 
+0000381256 00000 n 
+0000381385 00000 n 
+0000381514 00000 n 
+0000381643 00000 n 
+0000714080 00000 n 
+0000385987 00000 n 
+0000384768 00000 n 
+0000381794 00000 n 
+0000385279 00000 n 
+0000385408 00000 n 
+0000385666 00000 n 
+0000384924 00000 n 
+0000385103 00000 n 
+0000385859 00000 n 
+0000385923 00000 n 
+0000392873 00000 n 
+0000389045 00000 n 
+0000386140 00000 n 
+0000389171 00000 n 
+0000389236 00000 n 
+0000389301 00000 n 
+0000389366 00000 n 
+0000389431 00000 n 
+0000389496 00000 n 
+0000389561 00000 n 
+0000389626 00000 n 
+0000389691 00000 n 
+0000389756 00000 n 
+0000389886 00000 n 
+0000389951 00000 n 
+0000390016 00000 n 
+0000390081 00000 n 
+0000390146 00000 n 
+0000390211 00000 n 
+0000390276 00000 n 
+0000390341 00000 n 
+0000390406 00000 n 
+0000390471 00000 n 
+0000390536 00000 n 
+0000390601 00000 n 
+0000390666 00000 n 
+0000390731 00000 n 
+0000390796 00000 n 
+0000390861 00000 n 
+0000390926 00000 n 
+0000390991 00000 n 
+0000391056 00000 n 
+0000391121 00000 n 
+0000391186 00000 n 
+0000391251 00000 n 
+0000391316 00000 n 
+0000391381 00000 n 
+0000391445 00000 n 
+0000391510 00000 n 
+0000391575 00000 n 
+0000391640 00000 n 
+0000391705 00000 n 
+0000391770 00000 n 
+0000391835 00000 n 
+0000391900 00000 n 
+0000391965 00000 n 
+0000392030 00000 n 
+0000392095 00000 n 
+0000392160 00000 n 
+0000392225 00000 n 
+0000392290 00000 n 
+0000392355 00000 n 
+0000392420 00000 n 
+0000392485 00000 n 
+0000392550 00000 n 
+0000392615 00000 n 
 0000392680 00000 n 
-0000389619 00000 n 
-0000392806 00000 n 
-0000392871 00000 n 
-0000396183 00000 n 
-0000395992 00000 n 
-0000393074 00000 n 
-0000396118 00000 n 
-0000399962 00000 n 
-0000399706 00000 n 
-0000396308 00000 n 
-0000399832 00000 n 
-0000399897 00000 n 
-0000403136 00000 n 
-0000402361 00000 n 
-0000400100 00000 n 
-0000402487 00000 n 
-0000402552 00000 n 
-0000402617 00000 n 
-0000402682 00000 n 
-0000402747 00000 n 
-0000402876 00000 n 
-0000402941 00000 n 
-0000403006 00000 n 
-0000403071 00000 n 
-0000407608 00000 n 
-0000407417 00000 n 
-0000403274 00000 n 
-0000407543 00000 n 
-0000655362 00000 n 
-0000410737 00000 n 
-0000409964 00000 n 
-0000407746 00000 n 
-0000410090 00000 n 
-0000410155 00000 n 
-0000410220 00000 n 
-0000410284 00000 n 
-0000410413 00000 n 
-0000410478 00000 n 
-0000410542 00000 n 
-0000410607 00000 n 
-0000410672 00000 n 
-0000414128 00000 n 
-0000413872 00000 n 
-0000410875 00000 n 
-0000413998 00000 n 
-0000414063 00000 n 
-0000416991 00000 n 
-0000416281 00000 n 
-0000414266 00000 n 
-0000416407 00000 n 
-0000416472 00000 n 
-0000416537 00000 n 
-0000416602 00000 n 
-0000416731 00000 n 
-0000416796 00000 n 
-0000416861 00000 n 
-0000416926 00000 n 
-0000420670 00000 n 
-0000420414 00000 n 
-0000417142 00000 n 
-0000420540 00000 n 
-0000420605 00000 n 
-0000424107 00000 n 
-0000423851 00000 n 
-0000420795 00000 n 
-0000423977 00000 n 
-0000424042 00000 n 
-0000426576 00000 n 
-0000425868 00000 n 
-0000424245 00000 n 
-0000425994 00000 n 
-0000426059 00000 n 
-0000426124 00000 n 
-0000426251 00000 n 
-0000426316 00000 n 
-0000426381 00000 n 
-0000426446 00000 n 
-0000426511 00000 n 
-0000655487 00000 n 
-0000429462 00000 n 
-0000428688 00000 n 
-0000426727 00000 n 
-0000428814 00000 n 
-0000428879 00000 n 
-0000428944 00000 n 
-0000429009 00000 n 
-0000429137 00000 n 
-0000429202 00000 n 
-0000429267 00000 n 
-0000429332 00000 n 
-0000429397 00000 n 
-0000432818 00000 n 
-0000432627 00000 n 
-0000429600 00000 n 
-0000432753 00000 n 
-0000435789 00000 n 
-0000435080 00000 n 
-0000432943 00000 n 
-0000435206 00000 n 
-0000435271 00000 n 
-0000435336 00000 n 
-0000435401 00000 n 
-0000435529 00000 n 
-0000435594 00000 n 
-0000435659 00000 n 
-0000435724 00000 n 
-0000439301 00000 n 
-0000439045 00000 n 
-0000435940 00000 n 
-0000439171 00000 n 
-0000439236 00000 n 
-0000442176 00000 n 
-0000441920 00000 n 
-0000439507 00000 n 
-0000442046 00000 n 
-0000442111 00000 n 
-0000445175 00000 n 
-0000444400 00000 n 
-0000442382 00000 n 
-0000444526 00000 n 
-0000444591 00000 n 
-0000444656 00000 n 
-0000444721 00000 n 
-0000444786 00000 n 
-0000444915 00000 n 
-0000444980 00000 n 
-0000445045 00000 n 
-0000445110 00000 n 
-0000655612 00000 n 
-0000448684 00000 n 
-0000448041 00000 n 
-0000445326 00000 n 
-0000448167 00000 n 
-0000448232 00000 n 
-0000448297 00000 n 
-0000448362 00000 n 
-0000448427 00000 n 
-0000448555 00000 n 
-0000448620 00000 n 
-0000452245 00000 n 
-0000451859 00000 n 
-0000448848 00000 n 
-0000451985 00000 n 
-0000452050 00000 n 
-0000452115 00000 n 
-0000452180 00000 n 
-0000454598 00000 n 
-0000454213 00000 n 
-0000452370 00000 n 
-0000454339 00000 n 
-0000454404 00000 n 
-0000454469 00000 n 
-0000454534 00000 n 
-0000458278 00000 n 
-0000457698 00000 n 
-0000454749 00000 n 
-0000457824 00000 n 
-0000457953 00000 n 
-0000458018 00000 n 
-0000458083 00000 n 
-0000458148 00000 n 
-0000458213 00000 n 
-0000460305 00000 n 
-0000459919 00000 n 
-0000458416 00000 n 
-0000460045 00000 n 
-0000460110 00000 n 
-0000460175 00000 n 
-0000460240 00000 n 
-0000460489 00000 n 
-0000471833 00000 n 
-0000474157 00000 n 
-0000474126 00000 n 
-0000483645 00000 n 
-0000493701 00000 n 
-0000504168 00000 n 
-0000516376 00000 n 
-0000534653 00000 n 
-0000556743 00000 n 
-0000577753 00000 n 
-0000595571 00000 n 
-0000598402 00000 n 
-0000598172 00000 n 
-0000625660 00000 n 
-0000652769 00000 n 
-0000655737 00000 n 
-0000655860 00000 n 
-0000655986 00000 n 
-0000656112 00000 n 
-0000656202 00000 n 
-0000656294 00000 n 
-0000671585 00000 n 
-0000688895 00000 n 
-0000688936 00000 n 
-0000688976 00000 n 
-0000689110 00000 n 
+0000392745 00000 n 
+0000392809 00000 n 
+0000399519 00000 n 
+0000395955 00000 n 
+0000392985 00000 n 
+0000396081 00000 n 
+0000396146 00000 n 
+0000396211 00000 n 
+0000396276 00000 n 
+0000396341 00000 n 
+0000396406 00000 n 
+0000396471 00000 n 
+0000396536 00000 n 
+0000396601 00000 n 
+0000396666 00000 n 
+0000396731 00000 n 
+0000396796 00000 n 
+0000396860 00000 n 
+0000396925 00000 n 
+0000396990 00000 n 
+0000397055 00000 n 
+0000397120 00000 n 
+0000397185 00000 n 
+0000397250 00000 n 
+0000397315 00000 n 
+0000397380 00000 n 
+0000397445 00000 n 
+0000397510 00000 n 
+0000397575 00000 n 
+0000397639 00000 n 
+0000397704 00000 n 
+0000397769 00000 n 
+0000397834 00000 n 
+0000397899 00000 n 
+0000397964 00000 n 
+0000398029 00000 n 
+0000398094 00000 n 
+0000398159 00000 n 
+0000398224 00000 n 
+0000398289 00000 n 
+0000398354 00000 n 
+0000398419 00000 n 
+0000398484 00000 n 
+0000398549 00000 n 
+0000398614 00000 n 
+0000398678 00000 n 
+0000398742 00000 n 
+0000398806 00000 n 
+0000398871 00000 n 
+0000398936 00000 n 
+0000399001 00000 n 
+0000399066 00000 n 
+0000399131 00000 n 
+0000399196 00000 n 
+0000399261 00000 n 
+0000399326 00000 n 
+0000399391 00000 n 
+0000399455 00000 n 
+0000405692 00000 n 
+0000402254 00000 n 
+0000399631 00000 n 
+0000402380 00000 n 
+0000402445 00000 n 
+0000402510 00000 n 
+0000402575 00000 n 
+0000402640 00000 n 
+0000402705 00000 n 
+0000402770 00000 n 
+0000402835 00000 n 
+0000402900 00000 n 
+0000402965 00000 n 
+0000403030 00000 n 
+0000403095 00000 n 
+0000403160 00000 n 
+0000403225 00000 n 
+0000403290 00000 n 
+0000403355 00000 n 
+0000403420 00000 n 
+0000403485 00000 n 
+0000403550 00000 n 
+0000403615 00000 n 
+0000403680 00000 n 
+0000403745 00000 n 
+0000403810 00000 n 
+0000403875 00000 n 
+0000403940 00000 n 
+0000404005 00000 n 
+0000404070 00000 n 
+0000404135 00000 n 
+0000404200 00000 n 
+0000404265 00000 n 
+0000404330 00000 n 
+0000404395 00000 n 
+0000404460 00000 n 
+0000404525 00000 n 
+0000404589 00000 n 
+0000404654 00000 n 
+0000404719 00000 n 
+0000404784 00000 n 
+0000404849 00000 n 
+0000404914 00000 n 
+0000404979 00000 n 
+0000405044 00000 n 
+0000405109 00000 n 
+0000405174 00000 n 
+0000405239 00000 n 
+0000405304 00000 n 
+0000405369 00000 n 
+0000405434 00000 n 
+0000405499 00000 n 
+0000405564 00000 n 
+0000405628 00000 n 
+0000410270 00000 n 
+0000408006 00000 n 
+0000405804 00000 n 
+0000408132 00000 n 
+0000408197 00000 n 
+0000408262 00000 n 
+0000408327 00000 n 
+0000408392 00000 n 
+0000408457 00000 n 
+0000408522 00000 n 
+0000408587 00000 n 
+0000408652 00000 n 
+0000408717 00000 n 
+0000408782 00000 n 
+0000408847 00000 n 
+0000408912 00000 n 
+0000408977 00000 n 
+0000409039 00000 n 
+0000409103 00000 n 
+0000409168 00000 n 
+0000409232 00000 n 
+0000409297 00000 n 
+0000409362 00000 n 
+0000409427 00000 n 
+0000409492 00000 n 
+0000409557 00000 n 
+0000409622 00000 n 
+0000409687 00000 n 
+0000409816 00000 n 
+0000409945 00000 n 
+0000410010 00000 n 
+0000410075 00000 n 
+0000410140 00000 n 
+0000410205 00000 n 
+0000413065 00000 n 
+0000412421 00000 n 
+0000410395 00000 n 
+0000412547 00000 n 
+0000412676 00000 n 
+0000412805 00000 n 
+0000412870 00000 n 
+0000412935 00000 n 
+0000413000 00000 n 
+0000714205 00000 n 
+0000417403 00000 n 
+0000417083 00000 n 
+0000413178 00000 n 
+0000417209 00000 n 
+0000417274 00000 n 
+0000417339 00000 n 
+0000420874 00000 n 
+0000420618 00000 n 
+0000417556 00000 n 
+0000420744 00000 n 
+0000420809 00000 n 
+0000424122 00000 n 
+0000423931 00000 n 
+0000421013 00000 n 
+0000424057 00000 n 
+0000427851 00000 n 
+0000427595 00000 n 
+0000424248 00000 n 
+0000427721 00000 n 
+0000427786 00000 n 
+0000430691 00000 n 
+0000429983 00000 n 
+0000427990 00000 n 
+0000430109 00000 n 
+0000430174 00000 n 
+0000430239 00000 n 
+0000430304 00000 n 
+0000430369 00000 n 
+0000430498 00000 n 
+0000430563 00000 n 
+0000430627 00000 n 
+0000435364 00000 n 
+0000435108 00000 n 
+0000430830 00000 n 
+0000435234 00000 n 
+0000435299 00000 n 
+0000714330 00000 n 
+0000438315 00000 n 
+0000437542 00000 n 
+0000435490 00000 n 
+0000437668 00000 n 
+0000437733 00000 n 
+0000437798 00000 n 
+0000437863 00000 n 
+0000437992 00000 n 
+0000438057 00000 n 
+0000438120 00000 n 
+0000438185 00000 n 
+0000438250 00000 n 
+0000440916 00000 n 
+0000440207 00000 n 
+0000438468 00000 n 
+0000440333 00000 n 
+0000440398 00000 n 
+0000440463 00000 n 
+0000440528 00000 n 
+0000440593 00000 n 
+0000440658 00000 n 
+0000440787 00000 n 
+0000440852 00000 n 
+0000443940 00000 n 
+0000443555 00000 n 
+0000441068 00000 n 
+0000443681 00000 n 
+0000443746 00000 n 
+0000443810 00000 n 
+0000443875 00000 n 
+0000447035 00000 n 
+0000446261 00000 n 
+0000444080 00000 n 
+0000446387 00000 n 
+0000446452 00000 n 
+0000446517 00000 n 
+0000446582 00000 n 
+0000446711 00000 n 
+0000446776 00000 n 
+0000446841 00000 n 
+0000446905 00000 n 
+0000446970 00000 n 
+0000450308 00000 n 
+0000450117 00000 n 
+0000447201 00000 n 
+0000450243 00000 n 
+0000453409 00000 n 
+0000452699 00000 n 
+0000450434 00000 n 
+0000452825 00000 n 
+0000452890 00000 n 
+0000452955 00000 n 
+0000453020 00000 n 
+0000453085 00000 n 
+0000453214 00000 n 
+0000453279 00000 n 
+0000453344 00000 n 
+0000714455 00000 n 
+0000457067 00000 n 
+0000456748 00000 n 
+0000453574 00000 n 
+0000456874 00000 n 
+0000456939 00000 n 
+0000457003 00000 n 
+0000460443 00000 n 
+0000460252 00000 n 
+0000457193 00000 n 
+0000460378 00000 n 
+0000463120 00000 n 
+0000462477 00000 n 
+0000460583 00000 n 
+0000462603 00000 n 
+0000462668 00000 n 
+0000462732 00000 n 
+0000462797 00000 n 
+0000462926 00000 n 
+0000462991 00000 n 
+0000463056 00000 n 
+0000465837 00000 n 
+0000465063 00000 n 
+0000463272 00000 n 
+0000465189 00000 n 
+0000465254 00000 n 
+0000465318 00000 n 
+0000465383 00000 n 
+0000465448 00000 n 
+0000465513 00000 n 
+0000465642 00000 n 
+0000465707 00000 n 
+0000465772 00000 n 
+0000469228 00000 n 
+0000468907 00000 n 
+0000465990 00000 n 
+0000469033 00000 n 
+0000469098 00000 n 
+0000469163 00000 n 
+0000472297 00000 n 
+0000471912 00000 n 
+0000469341 00000 n 
+0000472038 00000 n 
+0000472103 00000 n 
+0000472168 00000 n 
+0000472233 00000 n 
+0000714580 00000 n 
+0000475693 00000 n 
+0000475114 00000 n 
+0000472436 00000 n 
+0000475240 00000 n 
+0000475369 00000 n 
+0000475434 00000 n 
+0000475499 00000 n 
+0000475564 00000 n 
+0000475629 00000 n 
+0000478674 00000 n 
+0000478483 00000 n 
+0000475833 00000 n 
+0000478609 00000 n 
+0000481314 00000 n 
+0000480605 00000 n 
+0000478885 00000 n 
+0000480731 00000 n 
+0000480796 00000 n 
+0000480861 00000 n 
+0000480926 00000 n 
+0000480991 00000 n 
+0000481056 00000 n 
+0000481185 00000 n 
+0000481250 00000 n 
+0000485767 00000 n 
+0000485446 00000 n 
+0000481510 00000 n 
+0000485572 00000 n 
+0000485637 00000 n 
+0000485702 00000 n 
+0000489361 00000 n 
+0000489106 00000 n 
+0000485893 00000 n 
+0000489232 00000 n 
+0000489297 00000 n 
+0000492296 00000 n 
+0000492040 00000 n 
+0000489487 00000 n 
+0000492166 00000 n 
+0000492231 00000 n 
+0000714705 00000 n 
+0000495466 00000 n 
+0000494691 00000 n 
+0000492422 00000 n 
+0000494817 00000 n 
+0000494882 00000 n 
+0000494947 00000 n 
+0000495012 00000 n 
+0000495141 00000 n 
+0000495206 00000 n 
+0000495271 00000 n 
+0000495336 00000 n 
+0000495401 00000 n 
+0000498834 00000 n 
+0000498190 00000 n 
+0000495632 00000 n 
+0000498316 00000 n 
+0000498381 00000 n 
+0000498446 00000 n 
+0000498511 00000 n 
+0000498640 00000 n 
+0000498705 00000 n 
+0000498770 00000 n 
+0000502306 00000 n 
+0000501985 00000 n 
+0000499000 00000 n 
+0000502111 00000 n 
+0000502176 00000 n 
+0000502241 00000 n 
+0000504879 00000 n 
+0000504301 00000 n 
+0000502432 00000 n 
+0000504427 00000 n 
+0000504492 00000 n 
+0000504557 00000 n 
+0000504622 00000 n 
+0000504751 00000 n 
+0000504815 00000 n 
+0000508675 00000 n 
+0000508290 00000 n 
+0000505017 00000 n 
+0000508416 00000 n 
+0000508481 00000 n 
+0000508546 00000 n 
+0000508611 00000 n 
+0000510245 00000 n 
+0000509861 00000 n 
+0000508815 00000 n 
+0000509987 00000 n 
+0000510052 00000 n 
+0000510115 00000 n 
+0000510180 00000 n 
+0000714830 00000 n 
+0000510430 00000 n 
+0000521774 00000 n 
+0000529362 00000 n 
+0000531661 00000 n 
+0000531630 00000 n 
+0000541154 00000 n 
+0000551267 00000 n 
+0000561743 00000 n 
+0000574367 00000 n 
+0000593432 00000 n 
+0000614319 00000 n 
+0000636463 00000 n 
+0000654358 00000 n 
+0000657188 00000 n 
+0000656958 00000 n 
+0000684495 00000 n 
+0000711606 00000 n 
+0000714910 00000 n 
+0000715033 00000 n 
+0000715159 00000 n 
+0000715285 00000 n 
+0000715402 00000 n 
+0000715494 00000 n 
+0000731830 00000 n 
+0000750703 00000 n 
+0000750744 00000 n 
+0000750784 00000 n 
+0000750918 00000 n 
 trailer
 <<
-/Size 1957
-/Root 1955 0 R
-/Info 1956 0 R
-/ID [<B3E059B0906A0C00E3685A1538A2E1E1> <B3E059B0906A0C00E3685A1538A2E1E1>]
+/Size 2120
+/Root 2118 0 R
+/Info 2119 0 R
+/ID [<E7B0BB00F44154DCC90012FC495A8314> <E7B0BB00F44154DCC90012FC495A8314>]
 >>
 startxref
-689368
+751176
 %%EOF
diff --git a/contrib/bind9/doc/arm/Makefile.in b/contrib/bind9/doc/arm/Makefile.in
index 85f318d..5fa267e 100644
--- a/contrib/bind9/doc/arm/Makefile.in
+++ b/contrib/bind9/doc/arm/Makefile.in
@@ -1,4 +1,4 @@
-# Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2001, 2002  Internet Software Consortium.
 #
 # Permission to use, copy, modify, and/or 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.18.8 2007/08/28 07:20:03 tbox Exp $
+# $Id: Makefile.in,v 1.20.332.2 2009/02/12 23:47:22 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -44,6 +44,10 @@ Bv9ARM.html: Bv9ARM-book.xml releaseinfo.xml
 	${XSLTPROC} --stringparam root.filename Bv9ARM \
 		${top_srcdir}/doc/xsl/isc-docbook-chunk.xsl -
 
+Bv9ARM-all.html: Bv9ARM-book.xml releaseinfo.xml
+	expand Bv9ARM-book.xml | \
+	${XSLTPROC} -o Bv9ARM-all.html ../xsl/isc-docbook-html.xsl -
+
 Bv9ARM.tex: Bv9ARM-book.xml releaseinfo.xml
 	expand Bv9ARM-book.xml | \
 	${XSLTPROC} ${top_srcdir}/doc/xsl/pre-latex.xsl - | \
diff --git a/contrib/bind9/doc/arm/man.dig.html b/contrib/bind9/doc/arm/man.dig.html
index e6aa96d..4a5697a 100644
--- a/contrib/bind9/doc/arm/man.dig.html
+++ b/contrib/bind9/doc/arm/man.dig.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.dig.html,v 1.2.2.65 2008/10/18 01:29:59 tbox Exp $ -->
+<!-- $Id: man.dig.html,v 1.93.14.7 2009/04/03 01:52:23 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -52,7 +52,7 @@
 <div class="cmdsynopsis"><p><code class="command">dig</code>  [global-queryopt...] [query...]</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2563849"></a><h2>DESCRIPTION</h2>
+<a name="id2570492"></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
@@ -98,7 +98,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2563944"></a><h2>SIMPLE USAGE</h2>
+<a name="id2603014"></a><h2>SIMPLE USAGE</h2>
 <p>
       A typical invocation of <span><strong class="command">dig</strong></span> looks like:
       </p>
@@ -144,7 +144,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2569789"></a><h2>OPTIONS</h2>
+<a name="id2603125"></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
@@ -248,7 +248,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2624336"></a><h2>QUERY OPTIONS</h2>
+<a name="id2630091"></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
@@ -326,13 +326,15 @@
             </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>
+	      Set [do not set] the AD (authentic data) bit in the
+	      query.  This requests the server to return whether
+	      all of the answer and authority sections have all
+	      been validated as secure according to the security
+	      policy of the server.  AD=1 indicates that all records
+	      have been validated as secure and the answer is not
+	      from a OPT-OUT range.  AD=0 indicate that some part
+	      of the answer was insecure or not validated.
+	    </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.
@@ -547,7 +549,7 @@
 	      on its own line.
             </p>
 <p>
-	      If not specified <span><strong class="command">dig</strong></span> will look for
+	      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>
@@ -561,13 +563,17 @@
               validation.
               Requires dig be compiled with -DDIG_SIGCHASE.
             </p></dd>
+<dt><span class="term"><code class="option">+[no]nsid</code></span></dt>
+<dd><p>
+              Include an EDNS name server ID request when sending a query.
+            </p></dd>
 </dl></div>
 <p>
 
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2625254"></a><h2>MULTIPLE QUERIES</h2>
+<a name="id2631092"></a><h2>MULTIPLE QUERIES</h2>
 <p>
       The BIND 9 implementation of <span><strong class="command">dig </strong></span>
       supports
@@ -613,7 +619,7 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2625408"></a><h2>IDN SUPPORT</h2>
+<a name="id2631177"></a><h2>IDN SUPPORT</h2>
 <p>
       If <span><strong class="command">dig</strong></span> has been built with IDN (internationalized
       domain name) support, it can accept and display non-ASCII domain names.
@@ -627,14 +633,14 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2625436"></a><h2>FILES</h2>
+<a name="id2631206"></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="id2625458"></a><h2>SEE ALSO</h2>
+<a name="id2631227"></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>,
@@ -642,7 +648,7 @@ dig +qr www.isc.org any -x 127.0.0.1 isc.org ns +noqr
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2625495"></a><h2>BUGS</h2>
+<a name="id2631265"></a><h2>BUGS</h2>
 <p>
       There are probably too many query options.
     </p>
diff --git a/contrib/bind9/doc/arm/man.dnssec-dsfromkey.html b/contrib/bind9/doc/arm/man.dnssec-dsfromkey.html
new file mode 100644
index 0000000..ebf41d2
--- /dev/null
+++ b/contrib/bind9/doc/arm/man.dnssec-dsfromkey.html
@@ -0,0 +1,170 @@
+<!--
+ - Copyright (C) 2004-2009 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: man.dnssec-dsfromkey.html,v 1.6.14.6 2009/04/03 01:52:23 tbox Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>dnssec-dsfromkey</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.ch10.html" title="Manual pages">
+<link rel="prev" href="man.host.html" title="host">
+<link rel="next" href="man.dnssec-keyfromlabel.html" title="dnssec-keyfromlabel">
+</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"><span class="application">dnssec-dsfromkey</span></th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="man.host.html">Prev</a> </td>
+<th width="60%" align="center">Manual pages</th>
+<td width="20%" align="right"> <a accesskey="n" href="man.dnssec-keyfromlabel.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="refentry" lang="en">
+<a name="man.dnssec-dsfromkey"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p><span class="application">dnssec-dsfromkey</span> &#8212; DNSSEC DS RR generation tool</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="cmdsynopsis"><p><code class="command">dnssec-dsfromkey</code>  [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] [<code class="option">-1</code>] [<code class="option">-2</code>] [<code class="option">-a <em class="replaceable"><code>alg</code></em></code>] {keyfile}</p></div>
+<div class="cmdsynopsis"><p><code class="command">dnssec-dsfromkey</code>  {-s} [<code class="option">-v <em class="replaceable"><code>level</code></em></code>] [<code class="option">-1</code>] [<code class="option">-2</code>] [<code class="option">-a <em class="replaceable"><code>alg</code></em></code>] [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-d <em class="replaceable"><code>dir</code></em></code>] {dnsname}</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2603968"></a><h2>DESCRIPTION</h2>
+<p><span><strong class="command">dnssec-dsfromkey</strong></span>
+      outputs the Delegation Signer (DS) resource record (RR), as defined in
+      RFC 3658 and RFC 4509, for the given key(s).
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2603981"></a><h2>OPTIONS</h2>
+<div class="variablelist"><dl>
+<dt><span class="term">-1</span></dt>
+<dd><p>
+            Use SHA-1 as the digest algorithm (the default is to use
+            both SHA-1 and SHA-256).
+          </p></dd>
+<dt><span class="term">-2</span></dt>
+<dd><p>
+            Use SHA-256 as the digest algorithm.
+          </p></dd>
+<dt><span class="term">-a <em class="replaceable"><code>algorithm</code></em></span></dt>
+<dd><p>
+            Select the digest algorithm. The value of
+            <code class="option">algorithm</code> must be one of SHA-1 (SHA1) or
+            SHA-256 (SHA256). These values are case insensitive.
+          </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><span class="term">-s</span></dt>
+<dd><p>
+            Keyset mode: in place of the keyfile name, the argument is
+            the DNS domain name of a keyset file. Following options make sense
+            only in this mode.
+          </p></dd>
+<dt><span class="term">-c <em class="replaceable"><code>class</code></em></span></dt>
+<dd><p>
+            Specifies the DNS class (default is IN), useful only
+            in the keyset mode.
+          </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, ignored when
+            not in the keyset mode.
+          </p></dd>
+</dl></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2604180"></a><h2>EXAMPLE</h2>
+<p>
+      To build the SHA-256 DS RR from the
+      <strong class="userinput"><code>Kexample.com.+003+26160</code></strong>
+      keyfile name, the following command would be issued:
+    </p>
+<p><strong class="userinput"><code>dnssec-dsfromkey -2 Kexample.com.+003+26160</code></strong>
+    </p>
+<p>
+      The command would print something like:
+    </p>
+<p><strong class="userinput"><code>example.com. IN DS 26160 5 2 3A1EADA7A74B8D0BA86726B0C227AA85AB8BBD2B2004F41A868A54F0 C5EA0B94</code></strong>
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2604216"></a><h2>FILES</h2>
+<p>
+      The keyfile can be designed by the key identification
+      <code class="filename">Knnnn.+aaa+iiiii</code> or the full file name
+      <code class="filename">Knnnn.+aaa+iiiii.key</code> as generated by
+      <span class="refentrytitle">dnssec-keygen</span>(8).
+    </p>
+<p>
+      The keyset file name is built from the <code class="option">directory</code>,
+      the string <code class="filename">keyset-</code> and the
+      <code class="option">dnsname</code>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2604258"></a><h2>CAVEAT</h2>
+<p>
+      A keyfile error can give a "file not found" even if the file exists.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2604267"></a><h2>SEE ALSO</h2>
+<p><span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>,
+      <span class="citerefentry"><span class="refentrytitle">dnssec-signzone</span>(8)</span>,
+      <em class="citetitle">BIND 9 Administrator Reference Manual</em>,
+      <em class="citetitle">RFC 3658</em>,
+      <em class="citetitle">RFC 4509</em>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2604304"></a><h2>AUTHOR</h2>
+<p><span class="corpauthor">Internet Systems Consortium</span>
+    </p>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="man.host.html">Prev</a> </td>
+<td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td>
+<td width="40%" align="right"> <a accesskey="n" href="man.dnssec-keyfromlabel.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">host </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> <span class="application">dnssec-keyfromlabel</span>
+</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/contrib/bind9/doc/arm/man.dnssec-keyfromlabel.html b/contrib/bind9/doc/arm/man.dnssec-keyfromlabel.html
new file mode 100644
index 0000000..dffae42
--- /dev/null
+++ b/contrib/bind9/doc/arm/man.dnssec-keyfromlabel.html
@@ -0,0 +1,210 @@
+<!--
+ - Copyright (C) 2004-2009 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: man.dnssec-keyfromlabel.html,v 1.31.14.6 2009/04/03 01:52:21 tbox Exp $ -->
+<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
+<title>dnssec-keyfromlabel</title>
+<meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.ch10.html" title="Manual pages">
+<link rel="prev" href="man.dnssec-dsfromkey.html" title="dnssec-dsfromkey">
+<link rel="next" href="man.dnssec-keygen.html" title="dnssec-keygen">
+</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"><span class="application">dnssec-keyfromlabel</span></th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="man.dnssec-dsfromkey.html">Prev</a> </td>
+<th width="60%" align="center">Manual pages</th>
+<td width="20%" align="right"> <a accesskey="n" href="man.dnssec-keygen.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="refentry" lang="en">
+<a name="man.dnssec-keyfromlabel"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p><span class="application">dnssec-keyfromlabel</span> &#8212; DNSSEC key generation tool</p>
+</div>
+<div class="refsynopsisdiv">
+<h2>Synopsis</h2>
+<div class="cmdsynopsis"><p><code class="command">dnssec-keyfromlabel</code>  {-a <em class="replaceable"><code>algorithm</code></em>} {-l <em class="replaceable"><code>label</code></em>} [<code class="option">-c <em class="replaceable"><code>class</code></em></code>] [<code class="option">-f <em class="replaceable"><code>flag</code></em></code>] [<code class="option">-k</code>] [<code class="option">-n <em class="replaceable"><code>nametype</code></em></code>] [<code class="option">-p <em class="replaceable"><code>protocol</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="id2604759"></a><h2>DESCRIPTION</h2>
+<p><span><strong class="command">dnssec-keyfromlabel</strong></span>
+      gets keys with the given label from a crypto hardware and builds
+      key files for DNSSEC (Secure DNS), as defined in RFC 2535
+      and RFC 4034.  
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2604773"></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, NSEC3RSASHA1, NSEC3DSA or DH (Diffie Hellman).
+	    These values are case insensitive.
+	  </p>
+<p>
+            Note 1: that for DNSSEC, RSASHA1 is a mandatory to implement
+            algorithm, and DSA is recommended.
+          </p>
+<p>
+            Note 2: DH automatically sets the -k flag.
+          </p>
+</dd>
+<dt><span class="term">-l <em class="replaceable"><code>label</code></em></span></dt>
+<dd><p>
+            Specifies the label of keys in the crypto hardware
+            (PKCS#11 device).
+          </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><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><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><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><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><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="id2604969"></a><h2>GENERATED KEY FILES</h2>
+<p>
+      When <span><strong class="command">dnssec-keyfromlabel</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 files 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><code class="filename">iiiii</code> is the key identifier (or
+          footprint).
+        </p></li>
+</ul></div>
+<p><span><strong class="command">dnssec-keyfromlabel</strong></span> 
+      creates two files, with names based
+      on the printed string.  <code class="filename">Knnnn.+aaa+iiiii.key</code>
+      contains the public key, and
+      <code class="filename">Knnnn.+aaa+iiiii.private</code> contains the
+      private
+      key.
+    </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 <code class="filename">.private</code> file contains algorithm
+      specific
+      fields.  For obvious security reasons, this file does not have
+      general read permission.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2605063"></a><h2>SEE ALSO</h2>
+<p><span class="citerefentry"><span class="refentrytitle">dnssec-keygen</span>(8)</span>,
+      <span class="citerefentry"><span class="refentrytitle">dnssec-signzone</span>(8)</span>,
+      <em class="citetitle">BIND 9 Administrator Reference Manual</em>,
+      <em class="citetitle">RFC 2539</em>,
+      <em class="citetitle">RFC 2845</em>,
+      <em class="citetitle">RFC 4033</em>.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2605102"></a><h2>AUTHOR</h2>
+<p><span class="corpauthor">Internet Systems Consortium</span>
+    </p>
+</div>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="man.dnssec-dsfromkey.html">Prev</a> </td>
+<td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td>
+<td width="40%" align="right"> <a accesskey="n" href="man.dnssec-keygen.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">
+<span class="application">dnssec-dsfromkey</span> </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> <span class="application">dnssec-keygen</span>
+</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/contrib/bind9/doc/arm/man.dnssec-keygen.html b/contrib/bind9/doc/arm/man.dnssec-keygen.html
index ac3fbe8..fd12259 100644
--- a/contrib/bind9/doc/arm/man.dnssec-keygen.html
+++ b/contrib/bind9/doc/arm/man.dnssec-keygen.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.dnssec-keygen.html,v 1.2.2.66 2008/10/18 01:29:59 tbox Exp $ -->
+<!-- $Id: man.dnssec-keygen.html,v 1.97.14.6 2009/04/03 01:52:21 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -22,7 +22,7 @@
 <meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
 <link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
 <link rel="up" href="Bv9ARM.ch10.html" title="Manual pages">
-<link rel="prev" href="man.host.html" title="host">
+<link rel="prev" href="man.dnssec-keyfromlabel.html" title="dnssec-keyfromlabel">
 <link rel="next" href="man.dnssec-signzone.html" title="dnssec-signzone">
 </head>
 <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
@@ -31,7 +31,7 @@
 <tr><th colspan="3" align="center"><span class="application">dnssec-keygen</span></th></tr>
 <tr>
 <td width="20%" align="left">
-<a accesskey="p" href="man.host.html">Prev</a> </td>
+<a accesskey="p" href="man.dnssec-keyfromlabel.html">Prev</a> </td>
 <th width="60%" align="center">Manual pages</th>
 <td width="20%" align="right"> <a accesskey="n" href="man.dnssec-signzone.html">Next</a>
 </td>
@@ -50,7 +50,7 @@
 <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="id2598403"></a><h2>DESCRIPTION</h2>
+<a name="id2605817"></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 4034.  It can also generate keys for use with
@@ -58,20 +58,20 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2598417"></a><h2>OPTIONS</h2>
+<a name="id2605831"></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.
+	    DSA, NSEC3RSASHA1, NSEC3DSA, 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,
-            and DSA is recommended.  For TSIG, HMAC-MD5 is mandatory.
+            algorithm, and DSA is recommended.  For TSIG, HMAC-MD5 is
+	    mandatory.
           </p>
 <p>
             Note 2: HMAC-MD5 and DH automatically set the -k flag.
@@ -94,8 +94,8 @@
             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.
+            These values are case insensitive.  Defaults to ZONE for DNSKEY
+	    generation.
           </p></dd>
 <dt><span class="term">-c <em class="replaceable"><code>class</code></em></span></dt>
 <dd><p>
@@ -166,7 +166,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2598692"></a><h2>GENERATED KEYS</h2>
+<a name="id2606584"></a><h2>GENERATED KEYS</h2>
 <p>
       When <span><strong class="command">dnssec-keygen</strong></span> completes
       successfully,
@@ -212,7 +212,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2600711"></a><h2>EXAMPLE</h2>
+<a name="id2608808"></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
@@ -233,7 +233,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2601518"></a><h2>SEE ALSO</h2>
+<a name="id2608865"></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 2539</em>,
@@ -242,7 +242,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2601549"></a><h2>AUTHOR</h2>
+<a name="id2608896"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
@@ -252,13 +252,14 @@
 <table width="100%" summary="Navigation footer">
 <tr>
 <td width="40%" align="left">
-<a accesskey="p" href="man.host.html">Prev</a> </td>
+<a accesskey="p" href="man.dnssec-keyfromlabel.html">Prev</a> </td>
 <td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td>
 <td width="40%" align="right"> <a accesskey="n" href="man.dnssec-signzone.html">Next</a>
 </td>
 </tr>
 <tr>
-<td width="40%" align="left" valign="top">host </td>
+<td width="40%" align="left" valign="top">
+<span class="application">dnssec-keyfromlabel</span> </td>
 <td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
 <td width="40%" align="right" valign="top"> <span class="application">dnssec-signzone</span>
 </td>
diff --git a/contrib/bind9/doc/arm/man.dnssec-signzone.html b/contrib/bind9/doc/arm/man.dnssec-signzone.html
index a12d355..89cab24 100644
--- a/contrib/bind9/doc/arm/man.dnssec-signzone.html
+++ b/contrib/bind9/doc/arm/man.dnssec-signzone.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.dnssec-signzone.html,v 1.2.2.65 2008/10/18 01:29:59 tbox Exp $ -->
+<!-- $Id: man.dnssec-signzone.html,v 1.94.14.6 2009/04/03 01:52:21 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -47,10 +47,10 @@
 </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">-I <em class="replaceable"><code>input-format</code></em></code>] [<code class="option">-j <em class="replaceable"><code>jitter</code></em></code>] [<code class="option">-N <em class="replaceable"><code>soa-serial-format</code></em></code>] [<code class="option">-o <em class="replaceable"><code>origin</code></em></code>] [<code class="option">-O <em class="replaceable"><code>output-format</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 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">-I <em class="replaceable"><code>input-format</code></em></code>] [<code class="option">-j <em class="replaceable"><code>jitter</code></em></code>] [<code class="option">-N <em class="replaceable"><code>soa-serial-format</code></em></code>] [<code class="option">-o <em class="replaceable"><code>origin</code></em></code>] [<code class="option">-O <em class="replaceable"><code>output-format</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>] [<code class="option">-3 <em class="replaceable"><code>salt</code></em></code>] [<code class="option">-H <em class="replaceable"><code>iterations</code></em></code>] [<code class="option">-A</code>] {zonefile} [key...]</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2599262"></a><h2>DESCRIPTION</h2>
+<a name="id2608094"></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
@@ -61,7 +61,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2599282"></a><h2>OPTIONS</h2>
+<a name="id2608114"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-a</span></dt>
 <dd><p>
@@ -244,6 +244,23 @@
 <dd><p>
             Ignore KSK flag on key when determining what to sign.
           </p></dd>
+<dt><span class="term">-3 <em class="replaceable"><code>salt</code></em></span></dt>
+<dd><p>
+            Generate a NSEC3 chain with the given hex encoded salt.
+	    A dash (<em class="replaceable"><code>salt</code></em>) can
+	    be used to indicate that no salt is to be used when generating		    the NSEC3 chain.
+          </p></dd>
+<dt><span class="term">-H <em class="replaceable"><code>iterations</code></em></span></dt>
+<dd><p>
+	    When generating a NSEC3 chain use this many interations.  The
+	    default is 100.
+          </p></dd>
+<dt><span class="term">-A</span></dt>
+<dd><p>
+	    When generating a NSEC3 chain set the OPTOUT flag on all
+	    NSEC3 records and do not generate NSEC3 records for insecure
+	    delegations.
+          </p></dd>
 <dt><span class="term">zonefile</span></dt>
 <dd><p>
             The file containing the zone to be signed.
@@ -259,7 +276,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2653693"></a><h2>EXAMPLE</h2>
+<a name="id2659164"></a><h2>EXAMPLE</h2>
 <p>
       The following command signs the <strong class="userinput"><code>example.com</code></strong>
       zone with the DSA key generated by <span><strong class="command">dnssec-keygen</strong></span>
@@ -288,14 +305,14 @@ db.example.com.signed
 %</pre>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2653766"></a><h2>SEE ALSO</h2>
+<a name="id2659237"></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 4033</em>.
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2653790"></a><h2>AUTHOR</h2>
+<a name="id2659330"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
diff --git a/contrib/bind9/doc/arm/man.host.html b/contrib/bind9/doc/arm/man.host.html
index f180544..fe37654 100644
--- a/contrib/bind9/doc/arm/man.host.html
+++ b/contrib/bind9/doc/arm/man.host.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.host.html,v 1.2.2.64 2008/10/18 01:29:59 tbox Exp $ -->
+<!-- $Id: man.host.html,v 1.93.14.6 2009/04/03 01:52:23 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -23,7 +23,7 @@
 <link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
 <link rel="up" href="Bv9ARM.ch10.html" title="Manual pages">
 <link rel="prev" href="man.dig.html" title="dig">
-<link rel="next" href="man.dnssec-keygen.html" title="dnssec-keygen">
+<link rel="next" href="man.dnssec-dsfromkey.html" title="dnssec-dsfromkey">
 </head>
 <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
 <div class="navheader">
@@ -33,7 +33,7 @@
 <td width="20%" align="left">
 <a accesskey="p" href="man.dig.html">Prev</a> </td>
 <th width="60%" align="center">Manual pages</th>
-<td width="20%" align="right"> <a accesskey="n" href="man.dnssec-keygen.html">Next</a>
+<td width="20%" align="right"> <a accesskey="n" href="man.dnssec-dsfromkey.html">Next</a>
 </td>
 </tr>
 </table>
@@ -50,7 +50,7 @@
 <div class="cmdsynopsis"><p><code class="command">host</code>  [<code class="option">-aCdlnrsTwv</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">-m <em class="replaceable"><code>flag</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="id2597501"></a><h2>DESCRIPTION</h2>
+<a name="id2603329"></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.
@@ -148,7 +148,7 @@
       referrals to other name servers.
     </p>
 <p>
-      By default <span><strong class="command">host</strong></span> uses UDP when making
+      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
@@ -166,7 +166,7 @@
       NS, SOA, SIG, KEY, AXFR, etc.  When no query type is specified,
       <span><strong class="command">host</strong></span> automatically selects an appropriate
       query
-      type.  By default it looks for A, AAAA, and MX records, but if the
+      type.  By default, it looks for A, AAAA, and MX records, but if the
       <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
@@ -202,7 +202,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2597947"></a><h2>IDN SUPPORT</h2>
+<a name="id2603843"></a><h2>IDN SUPPORT</h2>
 <p>
       If <span><strong class="command">host</strong></span> has been built with IDN (internationalized
       domain name) support, it can accept and display non-ASCII domain names. 
@@ -216,12 +216,12 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2598044"></a><h2>FILES</h2>
+<a name="id2603872"></a><h2>FILES</h2>
 <p><code class="filename">/etc/resolv.conf</code>
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2598058"></a><h2>SEE ALSO</h2>
+<a name="id2603885"></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>
@@ -234,13 +234,13 @@
 <td width="40%" align="left">
 <a accesskey="p" href="man.dig.html">Prev</a> </td>
 <td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td>
-<td width="40%" align="right"> <a accesskey="n" href="man.dnssec-keygen.html">Next</a>
+<td width="40%" align="right"> <a accesskey="n" href="man.dnssec-dsfromkey.html">Next</a>
 </td>
 </tr>
 <tr>
 <td width="40%" align="left" valign="top">dig </td>
 <td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> <span class="application">dnssec-keygen</span>
+<td width="40%" align="right" valign="top"> <span class="application">dnssec-dsfromkey</span>
 </td>
 </tr>
 </table>
diff --git a/contrib/bind9/doc/arm/man.named-checkconf.html b/contrib/bind9/doc/arm/man.named-checkconf.html
index 3d5cdd2..10287aa 100644
--- a/contrib/bind9/doc/arm/man.named-checkconf.html
+++ b/contrib/bind9/doc/arm/man.named-checkconf.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.named-checkconf.html,v 1.2.2.67 2008/10/18 01:29:59 tbox Exp $ -->
+<!-- $Id: man.named-checkconf.html,v 1.92.14.6 2009/04/03 01:52:21 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -47,18 +47,22 @@
 </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 class="cmdsynopsis"><p><code class="command">named-checkconf</code>  [<code class="option">-h</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="id2599904"></a><h2>DESCRIPTION</h2>
+<a name="id2609005"></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" lang="en">
-<a name="id2599917"></a><h2>OPTIONS</h2>
+<a name="id2609019"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
+<dt><span class="term">-h</span></dt>
+<dd><p>
+            Print the usage summary and exit.
+          </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
@@ -88,21 +92,21 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2600020"></a><h2>RETURN VALUES</h2>
+<a name="id2609136"></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" lang="en">
-<a name="id2600034"></a><h2>SEE ALSO</h2>
+<a name="id2609149"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
       <span class="citerefentry"><span class="refentrytitle">named-checkzone</span>(8)</span>,
       <em class="citetitle">BIND 9 Administrator Reference Manual</em>.
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2600064"></a><h2>AUTHOR</h2>
+<a name="id2609179"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
diff --git a/contrib/bind9/doc/arm/man.named-checkzone.html b/contrib/bind9/doc/arm/man.named-checkzone.html
index 264e960..723c484 100644
--- a/contrib/bind9/doc/arm/man.named-checkzone.html
+++ b/contrib/bind9/doc/arm/man.named-checkzone.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.named-checkzone.html,v 1.2.2.70 2008/10/18 01:29:59 tbox Exp $ -->
+<!-- $Id: man.named-checkzone.html,v 1.98.14.6 2009/04/03 01:52:21 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -47,11 +47,11 @@
 </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">-f <em class="replaceable"><code>format</code></em></code>] [<code class="option">-F <em class="replaceable"><code>format</code></em></code>] [<code class="option">-i <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-k <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-m <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-M <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">-s <em class="replaceable"><code>style</code></em></code>] [<code class="option">-S <em class="replaceable"><code>mode</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>] [<code class="option">-W <em class="replaceable"><code>mode</code></em></code>] {zonename} {filename}</p></div>
+<div class="cmdsynopsis"><p><code class="command">named-checkzone</code>  [<code class="option">-d</code>] [<code class="option">-h</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">-f <em class="replaceable"><code>format</code></em></code>] [<code class="option">-F <em class="replaceable"><code>format</code></em></code>] [<code class="option">-i <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-k <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-m <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-M <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">-s <em class="replaceable"><code>style</code></em></code>] [<code class="option">-S <em class="replaceable"><code>mode</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>] [<code class="option">-W <em class="replaceable"><code>mode</code></em></code>] {zonename} {filename}</p></div>
 <div class="cmdsynopsis"><p><code class="command">named-compilezone</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">-C <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-f <em class="replaceable"><code>format</code></em></code>] [<code class="option">-F <em class="replaceable"><code>format</code></em></code>] [<code class="option">-i <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-k <em class="replaceable"><code>mode</code></em></code>] [<code class="option">-m <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">-s <em class="replaceable"><code>style</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>] [<code class="option">-W <em class="replaceable"><code>mode</code></em></code>] {zonename} {filename}</p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2601603"></a><h2>DESCRIPTION</h2>
+<a name="id2610131"></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
@@ -71,12 +71,16 @@
      </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2601653"></a><h2>OPTIONS</h2>
+<a name="id2659401"></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">-h</span></dt>
+<dd><p>
+            Print the usage summary and exit.
+          </p></dd>
 <dt><span class="term">-q</span></dt>
 <dd><p>
             Quiet mode - exit code only.
@@ -92,7 +96,7 @@
           </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.
+            Specify the class of the zone.  If not specified, "IN" is assumed.
           </p></dd>
 <dt><span class="term">-i <em class="replaceable"><code>mode</code></em></span></dt>
 <dd>
@@ -187,6 +191,8 @@
 <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>.
+	    If <code class="filename">filename</code> is <code class="filename">-</code> then
+	    write to standard out.
 	    This is mandatory for <span><strong class="command">named-compilezone</strong></span>.
           </p></dd>
 <dt><span class="term">-s <em class="replaceable"><code>style</code></em></span></dt>
@@ -251,14 +257,14 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2656364"></a><h2>RETURN VALUES</h2>
+<a name="id2660208"></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" lang="en">
-<a name="id2656378"></a><h2>SEE ALSO</h2>
+<a name="id2660221"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
       <span class="citerefentry"><span class="refentrytitle">named-checkconf</span>(8)</span>,
       <em class="citetitle">RFC 1035</em>,
@@ -266,7 +272,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2656480"></a><h2>AUTHOR</h2>
+<a name="id2660254"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
diff --git a/contrib/bind9/doc/arm/man.named.html b/contrib/bind9/doc/arm/man.named.html
index b08e738..08489e0 100644
--- a/contrib/bind9/doc/arm/man.named.html
+++ b/contrib/bind9/doc/arm/man.named.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.named.html,v 1.2.2.72 2008/10/18 01:29:59 tbox Exp $ -->
+<!-- $Id: man.named.html,v 1.99.14.6 2009/04/03 01:52:22 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -23,7 +23,7 @@
 <link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
 <link rel="up" href="Bv9ARM.ch10.html" title="Manual pages">
 <link rel="prev" href="man.named-checkzone.html" title="named-checkzone">
-<link rel="next" href="man.rndc.html" title="rndc">
+<link rel="next" href="man.nsupdate.html" title="nsupdate">
 </head>
 <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
 <div class="navheader">
@@ -33,7 +33,7 @@
 <td width="20%" align="left">
 <a accesskey="p" href="man.named-checkzone.html">Prev</a> </td>
 <th width="60%" align="center">Manual pages</th>
-<td width="20%" align="right"> <a accesskey="n" href="man.rndc.html">Next</a>
+<td width="20%" align="right"> <a accesskey="n" href="man.nsupdate.html">Next</a>
 </td>
 </tr>
 </table>
@@ -47,10 +47,10 @@
 </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">-m <em class="replaceable"><code>flag</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">-s</code>] [<code class="option">-S <em class="replaceable"><code>#max-socks</code></em></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 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">-m <em class="replaceable"><code>flag</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">-s</code>] [<code class="option">-S <em class="replaceable"><code>#max-socks</code></em></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">-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="id2602169"></a><h2>DESCRIPTION</h2>
+<a name="id2610579"></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
@@ -65,7 +65,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2602200"></a><h2>OPTIONS</h2>
+<a name="id2610610"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-4</span></dt>
 <dd><p>
@@ -216,6 +216,10 @@
 <dd><p>
             Report the version number and exit.
           </p></dd>
+<dt><span class="term">-V</span></dt>
+<dd><p>
+            Report the version number and build options, and exit.
+          </p></dd>
 <dt><span class="term">-x <em class="replaceable"><code>cache-file</code></em></span></dt>
 <dd>
 <p>
@@ -234,7 +238,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2603333"></a><h2>SIGNALS</h2>
+<a name="id2612848"></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
@@ -255,7 +259,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2605226"></a><h2>CONFIGURATION</h2>
+<a name="id2612898"></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
@@ -264,20 +268,20 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2605245"></a><h2>FILES</h2>
+<a name="id2612917"></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>
+<dt><span class="term"><code class="filename">/var/run/named/named.pid</code></span></dt>
 <dd><p>
             The default process-id file.
           </p></dd>
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2645430"></a><h2>SEE ALSO</h2>
+<a name="id2612961"></a><h2>SEE ALSO</h2>
 <p><em class="citetitle">RFC 1033</em>,
       <em class="citetitle">RFC 1034</em>,
       <em class="citetitle">RFC 1035</em>,
@@ -290,7 +294,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2645500"></a><h2>AUTHOR</h2>
+<a name="id2613099"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
@@ -302,14 +306,14 @@
 <td width="40%" align="left">
 <a accesskey="p" href="man.named-checkzone.html">Prev</a> </td>
 <td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td>
-<td width="40%" align="right"> <a accesskey="n" href="man.rndc.html">Next</a>
+<td width="40%" align="right"> <a accesskey="n" href="man.nsupdate.html">Next</a>
 </td>
 </tr>
 <tr>
 <td width="40%" align="left" valign="top">
 <span class="application">named-checkzone</span> </td>
 <td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
-<td width="40%" align="right" valign="top"> <span class="application">rndc</span>
+<td width="40%" align="right" valign="top"> <span class="application">nsupdate</span>
 </td>
 </tr>
 </table>
diff --git a/contrib/bind9/doc/arm/man.nsupdate.html b/contrib/bind9/doc/arm/man.nsupdate.html
new file mode 100644
index 0000000..5848fb2
--- /dev/null
+++ b/contrib/bind9/doc/arm/man.nsupdate.html
@@ -0,0 +1,569 @@
+<!--
+ - Copyright (C) 2004-2009 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: man.nsupdate.html,v 1.22.14.7 2009/04/03 01:52:22 tbox 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.71.1">
+<link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
+<link rel="up" href="Bv9ARM.ch10.html" title="Manual pages">
+<link rel="prev" href="man.named.html" title="named">
+<link rel="next" href="man.rndc.html" title="rndc">
+</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"><span class="application">nsupdate</span></th></tr>
+<tr>
+<td width="20%" align="left">
+<a accesskey="p" href="man.named.html">Prev</a> </td>
+<th width="60%" align="center">Manual pages</th>
+<td width="20%" align="right"> <a accesskey="n" href="man.rndc.html">Next</a>
+</td>
+</tr>
+</table>
+<hr>
+</div>
+<div class="refentry" lang="en">
+<a name="man.nsupdate"></a><div class="titlepage"></div>
+<div class="refnamediv">
+<h2>Name</h2>
+<p><span class="application">nsupdate</span> &#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">-D</code>] [[<code class="option">-g</code>] |  [<code class="option">-o</code>] |  [<code class="option">-y <em class="replaceable"><code>[<span class="optional">hmac:</span>]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">-R <em class="replaceable"><code>randomdev</code></em></code>] [<code class="option">-v</code>] [filename]</p></div>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2611329"></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
+      <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
+      <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
+      <code class="option">-d</code>
+      option makes
+      <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>
+      The <code class="option">-D</code> option makes <span><strong class="command">nsupdate</strong></span>
+      report additional debugging information to <code class="option">-d</code>.
+    </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 or GSS-TSIG as described in RFC3645.  TSIG relies on
+      a shared secret that should only be known to
+      <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> and
+      <span class="type">server</span> statements would be added to
+      <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.
+      <span><strong class="command">nsupdate</strong></span> does not read
+      <code class="filename">/etc/named.conf</code>.
+      GSS-TSIG uses Kerberos credentials.
+    </p>
+<p><span><strong class="command">nsupdate</strong></span>
+      uses the <code class="option">-y</code> or <code class="option">-k</code> option
+      to provide the shared secret needed to generate a TSIG record
+      for authenticating Dynamic DNS update requests, default type
+      HMAC-MD5.  These options are mutually exclusive.  With the
+      <code class="option">-k</code> option, <span><strong class="command">nsupdate</strong></span> reads
+      the shared secret from the file <em class="parameter"><code>keyfile</code></em>,
+      whose name is of the form
+      <code class="filename">K{name}.+157.+{random}.private</code>.  For
+      historical reasons, the file
+      <code class="filename">K{name}.+157.+{random}.key</code> must also be
+      present.  When the <code class="option">-y</code> option is used, a
+      signature is generated from
+      [<span class="optional"><em class="parameter"><code>hmac:</code></em></span>]<em class="parameter"><code>keyname:secret.</code></em>
+      <em class="parameter"><code>keyname</code></em> is the name of the key, and
+      <em class="parameter"><code>secret</code></em> is the base64 encoded shared
+      secret.  Use of the <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 <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>
+      The <code class="option">-g</code> and <code class="option">-o</code> specify that
+      GSS-TSIG is to be used.  The <code class="option">-o</code> should only
+      be used with old Microsoft Windows 2000 servers.
+    </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
+      <code class="option">-v</code>
+      option makes
+      <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 <code class="option">-t</code> option sets the maximum time an update request
+      can
+      take before it is aborted.  The default is 300 seconds.  Zero can be
+      used
+      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 <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>
+<p>
+      The <code class="option">-R <em class="replaceable"><code>randomdev</code></em></code> option
+      specifies a 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.  <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
+      <code class="filename">keyboard</code> indicates that keyboard input
+      should be used.  This option may be specified multiple times.
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2612201"></a><h2>INPUT FORMAT</h2>
+<p><span><strong class="command">nsupdate</strong></span>
+      reads input from
+      <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.
+      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.
+    </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 <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>
+<div class="variablelist"><dl>
+<dt><span class="term">
+              <span><strong class="command">server</strong></span>
+               {servername}
+               [port]
+            </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,
+              <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.
+              <em class="parameter"><code>port</code></em>
+              is the port number on
+              <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><span class="term">
+              <span><strong class="command">local</strong></span>
+               {address}
+               [port]
+            </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,
+              <span><strong class="command">nsupdate</strong></span>
+              will send updates using an address and port chosen by the
+              system.
+              <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.
+            </p></dd>
+<dt><span class="term">
+              <span><strong class="command">zone</strong></span>
+               {zonename}
+            </span></dt>
+<dd><p>
+              Specifies that all updates are to be made to the zone
+              <em class="parameter"><code>zonename</code></em>.
+              If no
+              <em class="parameter"><code>zone</code></em>
+              statement is provided,
+              <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">
+              <span><strong class="command">class</strong></span>
+               {classname}
+            </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">
+              <span><strong class="command">ttl</strong></span>
+               {seconds}
+            </span></dt>
+<dd><p>
+              Specify the default time to live for records to be added.
+	      The value <em class="parameter"><code>none</code></em> will clear the default
+	      ttl.
+            </p></dd>
+<dt><span class="term">
+              <span><strong class="command">key</strong></span>
+               {name}
+               {secret}
+            </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
+              <code class="option">-y</code> or <code class="option">-k</code>.
+            </p></dd>
+<dt><span class="term">
+              <span><strong class="command">prereq nxdomain</strong></span>
+               {domain-name}
+            </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">
+              <span><strong class="command">prereq yxdomain</strong></span>
+               {domain-name}
+            </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">
+              <span><strong class="command">prereq nxrrset</strong></span>
+               {domain-name}
+               [class]
+               {type}
+            </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
+              <em class="parameter"><code>domain-name</code></em>.
+              If
+              <em class="parameter"><code>class</code></em>
+              is omitted, IN (internet) is assumed.
+            </p></dd>
+<dt><span class="term">
+              <span><strong class="command">prereq yxrrset</strong></span>
+               {domain-name}
+               [class]
+               {type}
+            </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
+              <em class="parameter"><code>domain-name</code></em>
+              must exist.
+              If
+              <em class="parameter"><code>class</code></em>
+              is omitted, IN (internet) is assumed.
+            </p></dd>
+<dt><span class="term">
+              <span><strong class="command">prereq yxrrset</strong></span>
+               {domain-name}
+               [class]
+               {type}
+               {data...}
+            </span></dt>
+<dd><p>
+              The
+              <em class="parameter"><code>data</code></em>
+              from each set of prerequisites of this form
+              sharing a common
+              <em class="parameter"><code>type</code></em>,
+              <em class="parameter"><code>class</code></em>,
+              and
+              <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
+              <em class="parameter"><code>type</code></em>,
+              <em class="parameter"><code>class</code></em>,
+              and
+              <em class="parameter"><code>domain-name</code></em>.
+              The
+              <em class="parameter"><code>data</code></em>
+              are written in the standard text representation of the resource
+              record's
+              RDATA.
+            </p></dd>
+<dt><span class="term">
+              <span><strong class="command">update delete</strong></span>
+               {domain-name}
+               [ttl]
+               [class]
+               [type [data...]]
+            </span></dt>
+<dd><p>
+              Deletes any resource records named
+              <em class="parameter"><code>domain-name</code></em>.
+              If
+              <em class="parameter"><code>type</code></em>
+              and
+              <em class="parameter"><code>data</code></em>
+              is provided, only matching resource records will be removed.
+              The internet class is assumed if
+              <em class="parameter"><code>class</code></em>
+              is not supplied.  The
+              <em class="parameter"><code>ttl</code></em>
+              is ignored, and is only allowed for compatibility.
+            </p></dd>
+<dt><span class="term">
+              <span><strong class="command">update add</strong></span>
+               {domain-name}
+               {ttl}
+               [class]
+               {type}
+               {data...}
+            </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
+              <em class="parameter"><code>data</code></em>.
+            </p></dd>
+<dt><span class="term">
+              <span><strong class="command">show</strong></span>
+            </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">
+              <span><strong class="command">send</strong></span>
+            </span></dt>
+<dd><p>
+              Sends the current message.  This is equivalent to entering a
+              blank line.
+            </p></dd>
+<dt><span class="term">
+              <span><strong class="command">answer</strong></span>
+            </span></dt>
+<dd><p>
+              Displays the answer.
+            </p></dd>
+<dt><span class="term">
+              <span><strong class="command">debug</strong></span>
+            </span></dt>
+<dd><p>
+              Turn on debugging.
+            </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="id2667233"></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>
+      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>.
+
+      </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>
+      with IP address 172.16.1.1 is added.
+      The newly-added record has a 1 day TTL (86400 seconds).
+      </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>.
+
+      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.)
+    </p>
+</div>
+<div class="refsect1" lang="en">
+<a name="id2667283"></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="id2667352"></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="id2667422"></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>
+</div>
+<div class="navfooter">
+<hr>
+<table width="100%" summary="Navigation footer">
+<tr>
+<td width="40%" align="left">
+<a accesskey="p" href="man.named.html">Prev</a> </td>
+<td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td>
+<td width="40%" align="right"> <a accesskey="n" href="man.rndc.html">Next</a>
+</td>
+</tr>
+<tr>
+<td width="40%" align="left" valign="top">
+<span class="application">named</span> </td>
+<td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
+<td width="40%" align="right" valign="top"> <span class="application">rndc</span>
+</td>
+</tr>
+</table>
+</div>
+</body>
+</html>
diff --git a/contrib/bind9/doc/arm/man.rndc-confgen.html b/contrib/bind9/doc/arm/man.rndc-confgen.html
index fa5924d..4839e89 100644
--- a/contrib/bind9/doc/arm/man.rndc-confgen.html
+++ b/contrib/bind9/doc/arm/man.rndc-confgen.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.rndc-confgen.html,v 1.2.2.76 2008/10/18 01:29:59 tbox Exp $ -->
+<!-- $Id: man.rndc-confgen.html,v 1.102.14.7 2009/04/03 01:52:22 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -48,7 +48,7 @@
 <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="id2605546"></a><h2>DESCRIPTION</h2>
+<a name="id2616981"></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
@@ -64,7 +64,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2605612"></a><h2>OPTIONS</h2>
+<a name="id2625034"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-a</span></dt>
 <dd>
@@ -171,7 +171,7 @@
 </dl></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2606203"></a><h2>EXAMPLES</h2>
+<a name="id2634158"></a><h2>EXAMPLES</h2>
 <p>
       To allow <span><strong class="command">rndc</strong></span> to be used with
       no manual configuration, run
@@ -188,7 +188,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2607830"></a><h2>SEE ALSO</h2>
+<a name="id2634215"></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>,
@@ -196,7 +196,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2607868"></a><h2>AUTHOR</h2>
+<a name="id2634253"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
diff --git a/contrib/bind9/doc/arm/man.rndc.conf.html b/contrib/bind9/doc/arm/man.rndc.conf.html
index 47a5d9d..cb72238 100644
--- a/contrib/bind9/doc/arm/man.rndc.conf.html
+++ b/contrib/bind9/doc/arm/man.rndc.conf.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.rndc.conf.html,v 1.2.2.75 2008/10/18 01:29:59 tbox Exp $ -->
+<!-- $Id: man.rndc.conf.html,v 1.103.14.7 2009/04/03 01:52:22 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -50,7 +50,7 @@
 <div class="cmdsynopsis"><p><code class="command">rndc.conf</code> </p></div>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2604313"></a><h2>DESCRIPTION</h2>
+<a name="id2606668"></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
@@ -135,7 +135,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2604485"></a><h2>EXAMPLE</h2>
+<a name="id2614213"></a><h2>EXAMPLE</h2>
 <pre class="programlisting">
       options {
         default-server  localhost;
@@ -209,7 +209,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2604743"></a><h2>NAME SERVER CONFIGURATION</h2>
+<a name="id2614334"></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>
@@ -219,7 +219,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2604769"></a><h2>SEE ALSO</h2>
+<a name="id2614360"></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>,
@@ -227,7 +227,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2604807"></a><h2>AUTHOR</h2>
+<a name="id2614398"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
diff --git a/contrib/bind9/doc/arm/man.rndc.html b/contrib/bind9/doc/arm/man.rndc.html
index 351267b..f88a70e 100644
--- a/contrib/bind9/doc/arm/man.rndc.html
+++ b/contrib/bind9/doc/arm/man.rndc.html
@@ -1,5 +1,5 @@
 <!--
- - Copyright (C) 2004-2008 Internet Systems Consortium, Inc. ("ISC")
+ - Copyright (C) 2004-2009 Internet Systems Consortium, Inc. ("ISC")
  - Copyright (C) 2000-2003 Internet Software Consortium.
  - 
  - Permission to use, copy, modify, and distribute this software for any
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: man.rndc.html,v 1.2.2.74 2008/10/18 01:29:59 tbox Exp $ -->
+<!-- $Id: man.rndc.html,v 1.101.14.7 2009/04/03 01:52:22 tbox Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
@@ -22,7 +22,7 @@
 <meta name="generator" content="DocBook XSL Stylesheets V1.71.1">
 <link rel="start" href="Bv9ARM.html" title="BIND 9 Administrator Reference Manual">
 <link rel="up" href="Bv9ARM.ch10.html" title="Manual pages">
-<link rel="prev" href="man.named.html" title="named">
+<link rel="prev" href="man.nsupdate.html" title="nsupdate">
 <link rel="next" href="man.rndc.conf.html" title="rndc.conf">
 </head>
 <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
@@ -31,7 +31,7 @@
 <tr><th colspan="3" align="center"><span class="application">rndc</span></th></tr>
 <tr>
 <td width="20%" align="left">
-<a accesskey="p" href="man.named.html">Prev</a> </td>
+<a accesskey="p" href="man.nsupdate.html">Prev</a> </td>
 <th width="60%" align="center">Manual pages</th>
 <td width="20%" align="right"> <a accesskey="n" href="man.rndc.conf.html">Next</a>
 </td>
@@ -50,7 +50,7 @@
 <div class="cmdsynopsis"><p><code class="command">rndc</code>  [<code class="option">-b <em class="replaceable"><code>source-address</code></em></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="id2603601"></a><h2>DESCRIPTION</h2>
+<a name="id2612305"></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
@@ -79,7 +79,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2603651"></a><h2>OPTIONS</h2>
+<a name="id2612355"></a><h2>OPTIONS</h2>
 <div class="variablelist"><dl>
 <dt><span class="term">-b <em class="replaceable"><code>source-address</code></em></span></dt>
 <dd><p>
@@ -151,7 +151,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2603876"></a><h2>LIMITATIONS</h2>
+<a name="id2613262"></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.
@@ -165,7 +165,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2604043"></a><h2>SEE ALSO</h2>
+<a name="id2613293"></a><h2>SEE ALSO</h2>
 <p><span class="citerefentry"><span class="refentrytitle">rndc.conf</span>(5)</span>,
       <span class="citerefentry"><span class="refentrytitle">rndc-confgen</span>(8)</span>,
       <span class="citerefentry"><span class="refentrytitle">named</span>(8)</span>,
@@ -175,7 +175,7 @@
     </p>
 </div>
 <div class="refsect1" lang="en">
-<a name="id2604099"></a><h2>AUTHOR</h2>
+<a name="id2613349"></a><h2>AUTHOR</h2>
 <p><span class="corpauthor">Internet Systems Consortium</span>
     </p>
 </div>
@@ -185,14 +185,14 @@
 <table width="100%" summary="Navigation footer">
 <tr>
 <td width="40%" align="left">
-<a accesskey="p" href="man.named.html">Prev</a> </td>
+<a accesskey="p" href="man.nsupdate.html">Prev</a> </td>
 <td width="20%" align="center"><a accesskey="u" href="Bv9ARM.ch10.html">Up</a></td>
 <td width="40%" align="right"> <a accesskey="n" href="man.rndc.conf.html">Next</a>
 </td>
 </tr>
 <tr>
 <td width="40%" align="left" valign="top">
-<span class="application">named</span> </td>
+<span class="application">nsupdate</span> </td>
 <td width="20%" align="center"><a accesskey="h" href="Bv9ARM.html">Home</a></td>
 <td width="40%" align="right" valign="top"> <code class="filename">rndc.conf</code>
 </td>
diff --git a/contrib/bind9/doc/draft/draft-baba-dnsext-acl-reqts-01.txt b/contrib/bind9/doc/draft/draft-baba-dnsext-acl-reqts-01.txt
deleted file mode 100644
index 1030e57..0000000
--- a/contrib/bind9/doc/draft/draft-baba-dnsext-acl-reqts-01.txt
+++ /dev/null
@@ -1,336 +0,0 @@
-
-
-
-
-Internet-Draft                                                   T. Baba
-Expires: March 11, 2004                                         NTT Data
-                                                      September 11, 2003
-
-
-         Requirements for Access Control in Domain Name Systems
-                   draft-baba-dnsext-acl-reqts-01.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/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-   Distribution of this memo is unlimited.
-
-   This Internet-Draft will expire on March 11, 2004.
-
-Abstract
-
-   This document describes the requirements for access control
-   mechanisms in the Domain Name System (DNS), which authenticate
-   clients and then allow or deny access to resource records in the
-   zone according to the access control list (ACL).
-
-1. Introduction
-
-   The Domain Name System (DNS) is a hierarchical, distributed, highly
-   available database used for bi-directional mapping between domain
-   names and IP addresses, for email routing, and for other information
-   [RFC1034, 1035].  DNS security extensions (DNSSEC) have been defined
-   to authenticate the data in DNS and provide key distribution services
-   using SIG, KEY, and NXT resource records (RRs) [RFC2535].
-
-
-
-Baba                     Expires March 11, 2004                 [Page 1]
-
-Internet-Draft       DNS Access Control Requirements      September 2003
-
-
-   At the 28th IETF Meeting in Houston in 1993, DNS security design team
-   started a discussion about DNSSEC and agreed to accept the assumption
-   that "DNS data is public".  Accordingly, confidentiality for queries
-   or responses is not provided by DNSSEC, nor are any sort of access
-   control lists or other means to differentiate inquirers.  However,
-   about ten years has passed, access control in DNS has been more
-   important than before.  Currently, new RRs are proposed to add new
-   functionality to DNS such as ENUM [RFC2916].  Such new RRs may
-   contain private information.  Thus, DNS access control will be
-   needed.
-
-   Furthermore, with DNS access control mechanism, access from
-   unauthorized clients can be blocked when they perform DNS name
-   resolution.  Thus, for example, Denial of Service (DoS) attacks
-   against a server used by a closed user group can be prevented using
-   this mechanism if IP address of the server is not revealed by other
-   sources.
-
-   This document describes the requirements for access control
-   mechanisms in DNS.
-
-2. Terminology
-
-   AC-aware client
-      This is the client that understands the DNS access control
-      extensions. This client may be an end host which has a stub
-      resolver, or a cashing/recursive name server which has a
-      full-service resolver.
-
-   AC-aware server
-      This is the authoritative name server that understands the DNS
-      access control extensions.
-
-   ACE
-      An Access Control Entry.  This is the smallest unit of access
-      control policy.  It grants or denies a given set of access
-      rights to a set of principals.  An ACE is a component of an ACL,
-      which is associated with a resource.
-
-   ACL
-      An Access Control List.  This contains all of the access control
-      policies which are directly associated with a particular
-      resource.  These policies are expressed as ACEs.
-
-   Client
-      A program or host which issues DNS requests and accepts its
-      responses. A client may be an end host or a cashing/recursive name
-      server.
-
-
-
-Baba                     Expires March 11, 2004                 [Page 2]
-
-Internet-Draft       DNS Access Control Requirements      September 2003
-
-
-   RRset
-      All resource records (RRs) having the same NAME, CLASS and TYPE
-      are called a Resource Record Set (RRset).
-
-3. Requirements
-
-   This section describes the requirements for access control in DNS.
-
-3.1 Authentication
-
-3.1.1 Client Authentication Mechanism
-
-   The AC-aware server must identify AC-aware clients based on IP
-   address and/or domain name (user ID or host name), and must
-   authenticate them using strong authentication mechanism such as
-   digital signature or message authentication code (MAC).
-
-   SIG(0) RR [RFC2931] contains a domain name associated with sender's
-   public key in its signer's name field, and TSIG RR [RFC2845] also
-   contains a domain name associated with shared secret key in its key
-   name field.  Each of these domain names can be a host name or a user
-   name, and can be used as a sender's identifier for access control.
-   Furthermore, SIG(0) uses digital signatures, and TSIG uses MACs for
-   message authentication.  These mechanisms can be used to authenticate
-   AC-aware clients.
-
-   Server authentication may be also provided.
-
-3.1.2 End-to-End Authentication
-
-   In current DNS model, caching/recursive name servers are deployed
-   between end hosts and authoritative name servers.  Although
-   authoritative servers can authenticate caching/recursive name servers
-   using SIG(0) or TSIG, they cannot authenticate end hosts behind them.
-   For end-to-end authentication, the mechanism for an end host to
-   discover the target authoritative name server and directly access to
-   it bypassing caching/recursive name servers is needed.  For example,
-   an end host can get the IP addresses of the authoritative name
-   servers by retrieving NS RRs for the zone via local caching/recursive
-   name server.
-
-   In many enterprise networks, however, there are firewalls that block
-   all DNS packets other than those going to/from the particular
-   caching/recursive servers.  To deal with this problem, one can
-   implement packet forwarding function on the caching/recursive servers
-   and enable end-to-end authentication via the caching/recursive
-   servers.
-
-
-
-
-Baba                     Expires March 11, 2004                 [Page 3]
-
-Internet-Draft       DNS Access Control Requirements      September 2003
-
-
-3.1.3 Authentication Key Retrieval
-
-   Keys which are used to authenticate clients should be able to be
-   automatically retrieved.  The KEY RR is used to store a public key
-   for a zone or a host that is associated with a domain name.  SIG(0)
-   RR uses a public key in KEY RR for verifying the signature.  If
-   DNSSEC is available, the KEY RR would be protected by the SIG RR.
-   KEY RR or newly defined RR can be used to automatic key retrieval.
-
-3.2 Confidentiality
-
-3.2.1 Data Encryption
-
-   To avoid disclosure to eavesdroppers, the response containing the
-   RRsets which are restricted to access from particular users should be
-   encrypted.  Currently, no encryption mechanism is specified in DNS.
-   Therefore, new RRs should be defined for DNS message encryption.
-   Instead, IPsec [RFC2401] can be used to provide confidentiality if
-   name server and resolver can set up security associations dynamically
-   using IPsec API [IPSECAPI] when encryption is required.
-
-   In case encryption is applied, entire DNS message including DNS
-   header should be encrypted to hide information including error code.
-
-   Query encryption may be also provided for hiding query information.
-
-3.2.2 Key Exchange
-
-   If DNS message encryption is provided, automatic key exchange
-   mechanism should be also provided.  [RFC2930] specifies a TKEY RR
-   that can be used to establish and delete shared secret keys used by
-   TSIG between a client and a server.  With minor extensions, TKEY can
-   be used to establish shared secret keys used for message encryption.
-
-3.2.3 Caching
-
-   The RRset that is restricted to access from particular users must not
-   be cached.  To avoid caching, the TTL of the RR that is restricted to
-   access should be set to zero during transit.
-
-3.3 Access Control
-
-3.3.1 Granularity of Access Control
-
-   Control of access on a per-user/per-host granularity must be
-   supported.  Control of access to individual RRset (not just the
-   entire zone) must be also supported.  However, SOA, NS, SIG, NXT,
-   KEY, and DS RRs must be publicly accessible to avoid unexpected
-   results.
-   
-
-Baba                     Expires March 11, 2004                 [Page 4]
-
-Internet-Draft       DNS Access Control Requirements      September 2003
-
-
-3.3.2 ACL Representation
-
-   Access Control List (ACL) format must be standardized so that both
-   the primary and secondary AC-aware servers can recognize the same
-   ACL.  Although ACL may appear in or out of zone data, it must be
-   transferred to the secondary AC-aware server with associated zone
-   data.  It is a good idea to contain ACL in zone data, because ACL can
-   be transferred with zone data using existing zone transfer mechanisms
-   automatically.  However, ACL must not be published except for
-   authorized secondary master servers.
-   
-   In zone data master files, ACL should be specified using TXT RRs or
-   newly defined RRs.  In each access control entry (ACE), authorized
-   entities (host or user) must be described using domain name (host
-   name, user name, or IP address in in-addr.arpa/ip6.arpa format).
-   There may be other access control attributes such as access time.
-
-   It must be possible to create publicly readable entries, which may be
-   read even by unauthenticated clients.
-
-3.3.3 Zone/ACL Transfer
-
-   As mentioned above, ACL should be transferred from a primary AC-aware
-   server to a secondary AC-aware server with associated zone data.
-   When an AC-aware server receives a zone/ACL transfer request, the
-   server must authenticate the client, and should encrypt the zone
-   data and associated ACL during transfer.
-
-3.4 Backward/co-existence Compatibility
-
-   Any new protocols to be defined for access control in DNS must be
-   backward compatible with existing DNS protocol.  AC-aware servers
-   must be able to process normal DNS query without authentication, and
-   must respond if retrieving RRset is publicly accessible.
-   
-   Modifications to root/gTLD/ccTLD name servers are not allowed.
-
-4. Security Considerations
-
-   This document discusses the requirements for access control
-   mechanisms in DNS.
-
-5. Acknowledgements
-
-   This work is funded by the Telecommunications Advancement
-   Organization of Japan (TAO).
-
-   The author would like to thank the members of the NTT DATA network
-   security team for their important contribution to this work.
-
-
-Baba                     Expires March 11, 2004                 [Page 5]
-
-Internet-Draft       DNS Access Control Requirements      September 2003
-
-
-6. References
-
-   [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.
-
-   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
-              Internet Protocol", RFC 2401, November 1998.
-
-   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
-              "Secret Key Transaction Authentication for DNS (TSIG)", 
-              RFC 2845, May 2000.
-
-   [RFC2916]  Faltstrom, P., "E.164 number and DNS", RFC 2916,
-              September 2000.
-
-   [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.
-
-   [IPSECAPI] Sommerfeld, W., "Requirements for an IPsec API",
-              draft-ietf-ipsp-ipsec-apireq-00.txt, June 2003, Work in
-              Progress.
-
-
-Author's Address
-
-   Tatsuya Baba
-   NTT Data Corporation
-   Research and Development Headquarters
-   Kayabacho Tower, 1-21-2, Shinkawa, Chuo-ku,
-   Tokyo 104-0033, Japan
-   
-   Tel: +81 3 3523 8081
-   Fax: +81 3 3523 8090
-   Email: babatt@nttdata.co.jp
-
-
-
-
-
-
-
-
-Baba                     Expires March 11, 2004                 [Page 6]
diff --git a/contrib/bind9/doc/draft/draft-daigle-napstr-04.txt b/contrib/bind9/doc/draft/draft-daigle-napstr-04.txt
deleted file mode 100644
index fffa8a5..0000000
--- a/contrib/bind9/doc/draft/draft-daigle-napstr-04.txt
+++ /dev/null
@@ -1,1232 +0,0 @@
-
-
-Network Working Group                                          L. Daigle
-Internet-Draft                                                 A. Newton
-Expires: August 15, 2004                                  VeriSign, Inc.
-                                                       February 15, 2004
-
-
-    Domain-based Application Service Location Using SRV RRs and the
-              Dynamic Delegation Discovery Service (DDDS)
-                       draft-daigle-napstr-04.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 15, 2004.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-Abstract
-
-   This memo defines a generalized mechanism for application service
-   naming that allows service location without relying on rigid domain
-   naming conventions (so-called name hacks).  The proposal defines a
-   Dynamic Delegation Discovery System (DDDS) Application to map domain
-   name, application service name, and application protocol to target
-   server and port, dynamically.
-
-
-
-
-
-
-
-Daigle & Newton          Expires August 15, 2004                [Page 1]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-Table of Contents
-
-   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
-   2.    Straightforward-NAPTR (S-NAPTR) Specification  . . . . . . .  4
-   2.1   Key Terms  . . . . . . . . . . . . . . . . . . . . . . . . .  4
-   2.2   S-NAPTR DDDS Application Usage . . . . . . . . . . . . . . .  5
-   2.2.1 Ordering and Preference  . . . . . . . . . . . . . . . . . .  5
-   2.2.2 Matching and non-Matching NAPTR Records  . . . . . . . . . .  5
-   2.2.3 Terminal and Non-Terminal NAPTR Records  . . . . . . . . . .  5
-   2.2.4 S-NAPTR and Successive Resolution  . . . . . . . . . . . . .  6
-   2.2.5 Clients Supporting Multiple Protocols  . . . . . . . . . . .  6
-   3.    Guidelines . . . . . . . . . . . . . . . . . . . . . . . . .  7
-   3.1   Guidelines for Application Protocol Developers . . . . . . .  7
-   3.1.1 Registration of application service and protocol tags  . . .  7
-   3.1.2 Definition of conditions for retry/failure . . . . . . . . .  8
-   3.1.3 Server identification and handshake  . . . . . . . . . . . .  8
-   3.2   Guidelines for Domain Administrators . . . . . . . . . . . .  8
-   3.3   Guidelines for Client Software Writers . . . . . . . . . . .  9
-   4.    Illustrations  . . . . . . . . . . . . . . . . . . . . . . .  9
-   4.1   Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . .  9
-   4.2   Service Discovery within a Domain  . . . . . . . . . . . . . 10
-   4.3   Multiple Protocols . . . . . . . . . . . . . . . . . . . . . 10
-   4.4   Remote Hosting . . . . . . . . . . . . . . . . . . . . . . . 11
-   4.5   Sets of NAPTR RRs  . . . . . . . . . . . . . . . . . . . . . 12
-   4.6   Sample sequence diagram  . . . . . . . . . . . . . . . . . . 12
-   5.    Motivation and Discussion  . . . . . . . . . . . . . . . . . 14
-   5.1   So, why not just SRV records?  . . . . . . . . . . . . . . . 15
-   5.2   So, why not just NAPTR records?  . . . . . . . . . . . . . . 15
-   6.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 16
-   7.    Security Considerations  . . . . . . . . . . . . . . . . . . 16
-   8.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
-         References . . . . . . . . . . . . . . . . . . . . . . . . . 17
-         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18
-   A.    Application Service Location Application of DDDS . . . . . . 18
-   A.1   Application Unique String  . . . . . . . . . . . . . . . . . 18
-   A.2   First Well Known Rule  . . . . . . . . . . . . . . . . . . . 18
-   A.3   Expected Output  . . . . . . . . . . . . . . . . . . . . . . 18
-   A.4   Flags  . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
-   A.5   Service Parameters . . . . . . . . . . . . . . . . . . . . . 19
-   A.5.1 Application Services . . . . . . . . . . . . . . . . . . . . 19
-   A.5.2 Application Protocols  . . . . . . . . . . . . . . . . . . . 20
-   A.6   Valid Rules  . . . . . . . . . . . . . . . . . . . . . . . . 20
-   A.7   Valid Databases  . . . . . . . . . . . . . . . . . . . . . . 20
-   B.    Pseudo pseudocode for S-NAPTR  . . . . . . . . . . . . . . . 20
-   B.1   Finding the first (best) target  . . . . . . . . . . . . . . 20
-   B.2   Finding subsequent targets . . . . . . . . . . . . . . . . . 21
-         Full Copyright Statement . . . . . . . . . . . . . . . . . . 23
-
-
-
-
-Daigle & Newton          Expires August 15, 2004                [Page 2]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-1. Introduction
-
-   This memo defines a generalized mechanism for application service
-   naming that allows service location without relying on rigid domain
-   naming conventions (so-called name hacks).  The proposal defines a
-   Dynamic Delegation Discovery System (DDDS -- see [6]) Application to
-   map domain name, application service name, and application protocol
-   to target server and port, dynamically.
-
-   As discussed in Section 5, existing approaches to using DNS records
-   to dynamically determining the current host for a given application
-   service are limited in terms of the use cases supported.  To address
-   some of the limitations, this document defines a DDDS Application to
-   map service+protocol+domain to specific server addresses using both
-   NAPTR [7] and SRV ([5]) DNS resource records.  This can be viewed as
-   a more general version of the use of SRV and/or a very restricted
-   application of the use of NAPTR resource records.
-
-   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 ([2]).
-
-2. Straightforward-NAPTR (S-NAPTR) Specification
-
-   The precise details of the specification of this DDDS application are
-   given in Appendix A.  This section defines the usage of the DDDS
-   application.
-
-2.1 Key Terms
-
-   An "application service" is a generic term for some type of
-   application, indpendent of the protocol that may be used to offer it.
-   Each application service will be associated with an IANA-registered
-   tag.  For example, instant messaging is a type of application
-   service, which can be implemented by many different application-layer
-   protocols, and the tag "IM" (used as an illustration here) could be
-   registered for it.
-
-   An "application protocol" is used to implement the application
-   service.  These are also associated with IANA-registered tags.  In
-   the case where multiple transports are available for the application,
-   separate tags should be defined for each transport.
-
-   The intention is that the combination of application service and
-   protocol tags should be specific enough that finding a known pair
-   (e.g., "IM:ProtC") is sufficient for a client to identify a server
-   with which it can communicate.
-
-
-
-
-Daigle & Newton          Expires August 15, 2004                [Page 3]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   Some protocols support multiple application services.  For example,
-   LDAP is an application protocol, and can be found supporting various
-   services (e.g., "whitepages", "directory enabled networking", etc).
-
-2.2 S-NAPTR DDDS Application Usage
-
-   As outlined in Appendix A, NAPTR records are used to store
-   application service+protocol information for a given domain.
-   Following the DDDS standard, these records are looked up,  and the
-   rewrite rules (contained in the NAPTR records) are used to determine
-   the successive DNS lookups, until a desirable target is found.
-
-   For the rest of this section, refer to the set of NAPTR resource
-   records for example.com shown in the figure below.
-
-   example.com.
-   ;;       order pref flags service     regexp replacement
-   IN NAPTR 100   10   ""    "WP:whois++" ""    bunyip.example.
-   IN NAPTR 100   20   "s"   "WP:ldap"    ""    _ldap._tcp.myldap.example.com.
-   IN NAPTR 200   10   ""    "IM:protA"   ""    someisp.example.
-   IN NAPTR 200   30   "a"   "IM:protB"   ""    myprotB.example.com.
-
-
-2.2.1 Ordering and Preference
-
-   A client retrieves all of the NAPTR records associated with the
-   target domain name (example.com, above).  These are to be sorted in
-   terms of increasing ORDER, and increasing PREF within each ORDER.
-
-2.2.2 Matching and non-Matching NAPTR Records
-
-   Starting with the first sorted NAPTR record, the client examines the
-   SERVICE field to find a match.  In the case of the S-NAPTR DDDS
-   application, that means a SERVICE field that includes the tags for
-   the desired application service and a supported application protocol.
-
-   If more than one NAPTR record matches, they are processed in
-   increasing sort order.
-
-2.2.3 Terminal and Non-Terminal NAPTR Records
-
-   A NAPTR record with an empty FLAG field is "non-terminal".  That is,
-   more NAPTR RR lookups are to be performed.  Thus, to process a NAPTR
-   record with an empty FLAG field in S-NAPTR, the REPLACEMENT field is
-   used as the target of the next DNS lookup -- for NAPTR RRs.
-
-   In S-NAPTR, the only terminal flags are "S" and "A".  These are
-   called "terminal" NAPTR lookups because they denote the end of the
-
-
-
-Daigle & Newton          Expires August 15, 2004                [Page 4]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   DDDS/NAPTR processing rules.  In the case of an "S" flag, the
-   REPLACEMENT field is used as the target of a DNS query for SRV RRs,
-   and normal SRV processing is applied.  In the case of an "A" flag, an
-   address record is sought for the REPLACEMENT field target (and the
-   default protocol port is assumed).
-
-2.2.4 S-NAPTR and Successive Resolution
-
-   As shown in the example NAPTR RR set above, it is possible to have
-   multiple possible targets for a single application service+protocol
-   pair.  These are to be pursued in order until a server is
-   successfully contacted or all possible matching NAPTR records have
-   been successively pursued to terminal lookups and servers contacted.
-   That is, a client must backtrack and attempt other resolution paths
-   in the case of failure.
-
-   "Failure" is declared, and backtracking must be used when
-
-   o  the designated remote server (host and port) fail to provide
-      appropriate security credentials for the *originating* domain
-
-   o  connection to the designated remote server otherwise fails -- the
-      specifics terms of which are defined when an application protocol
-      is registered
-
-   o  the S-NAPTR-designated DNS lookup fails to yield expected results
-      -- e.g., no A RR for an "A" target, no SRV record for an "S"
-      target, or no NAPTR record with appropriate application service
-      and protocol for a NAPTR lookup.  Except in the case of the very
-      first NAPTR lookup, this last is a configuration error:  the fact
-      that example.com has a NAPTR record pointing to "bunyip.example"
-      for the "WP:Whois++" service and protocol means the administrator
-      of example.com believes that service exists.  If bunyip.example
-      has no "WP:Whois++" NAPTR record, the application client MUST
-      backtrack and try the next available "WP:Whois++" option from
-      example.com.  As there is none, the whole resolution fails.
-
-   An application client first queries for the NAPTR RRs for the domain
-   of a named application service.  The application client MUST select
-   one protocol to choose The PREF field of the NAPTR RRs may be used by
-   the domain administrator to The first DNS query is for the NAPTR RRs
-   in the original target domain (example.com, above).
-
-2.2.5 Clients Supporting Multiple Protocols
-
-   In the case of an application client that supports more than one
-   protocol for a given application service, it MUST pursue S-NAPTR
-   resolution completely for one protocol before trying another.j It MAY
-
-
-
-Daigle & Newton          Expires August 15, 2004                [Page 5]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   choose which protocol to try first based on its own preference, or
-   from the PREF ranking in the first set of NAPTR records (i.e., those
-   for the target named domain).    However, the chosen protocol MUST be
-   listed in that first NAPTR RR set.
-
-   That is, what the client MUST NOT do is start looking for one
-   protocol, observe that a successive NAPTR RR set supports another of
-   its preferred protocols, and continue the S-NAPTR resolution based on
-   that protocol.  For example, even if someisp.example offers the "IM"
-   service with protocol "ProtB", there is no reason to believe it does
-   so on behalf of example.com (since there is no such pointer in
-   example.com's NAPTR RR set).
-
-3. Guidelines
-
-3.1 Guidelines for Application Protocol Developers
-
-   The purpose of S-NAPTR is to provide application standards developers
-   with a more powerful framework (than SRV RRs alone) for naming
-   service targets, without requiring each application protocol (or
-   service) standard to define a separate DDDS application.
-
-   Note that this approach is intended specifically for use when it
-   makes sense to associate services with particular domain names (e.g.,
-   e-mail addresses, SIP addresses, etc).  A non-goal is having all
-   manner of label mapped into domain names in order to use this.
-
-   Specifically not addressed in this document is how to select the
-   domain for which the service+protocol is being sought.  It is up to
-   other conventions to define how that might be used (e.g., instant
-   messaging standards can define what domain to use from IM URIs, how
-   to step down from foobar.example.com to example.com, and so on, if
-   that is applicable).
-
-   Although this document proposes a DDDS application that does not use
-   all the features of NAPTR resource records, it does not mean to imply
-   that DNS resolvers should fail to implement all aspects of the NAPTR
-   RR standard.  A DDDS application is a client use convention.
-
-   The rest of this section outlines the specific elements that protocol
-   developers must determine and document in order to make use of S-
-   NAPTR.
-
-3.1.1 Registration of application service and protocol tags
-
-   Application protocol developers that wish to make use of S-NAPTR must
-   make provision to register any relevant application service and
-   application protocol tags, as described in Section 6.
-
-
-
-Daigle & Newton          Expires August 15, 2004                [Page 6]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-3.1.2 Definition of conditions for retry/failure
-
-   One other important aspect that must be defined is the expected
-   behaviour for interacting with the servers that are reached via S-
-   NAPTR.  Specifically,  under what circumstances should the client
-   retry a target that was found via S-NAPTR?  What should it consider a
-   failure that causes it to return to the S-NAPTR process to determine
-   the next serviceable target (a less preferred target)?
-
-   For example, if the client gets a "connection refused" from a server,
-   should it retry for some (protocol-dependent) period of time?  Or,
-   should it try the next-preferred target in the S-NAPTR chain of
-   resolution?  Should it only try the next-preferred target if it
-   receives a protocol-specific permanent error message?
-
-   The most important thing is to select one expected behaviour and
-   document it as part of the use of S-NAPTR.
-
-   As noted earlier, failure to provide appropriate credentials to
-   identify the server as being authoritative for the original taret
-   domain is always considered a failure condition.
-
-3.1.3 Server identification and handshake
-
-   As noted in Section 7, use of the DNS for server location increases
-   the importance of using protocol-specific handshakes to determine and
-   confirm the identity of the server that is eventually reached.
-
-   Therefore, application protocol developers using S-NAPTR should
-   identify the mechanics of the expected identification handshake when
-   the client connects to a server found through S-NAPTR.
-
-3.2 Guidelines for Domain Administrators
-
-   Although S-NAPTR aims to provide a "straightforward" application of
-   DDDS and use of NAPTR records, it is still possible to create very
-   complex chains and dependencies with the NAPTR and SRV records.
-
-   Therefore, domain administrators are called upon to use S-NAPTR with
-   as much restraint as possible, while still achieving their service
-   design goals.
-
-   The complete set of NAPTR, SRV and A RRs that are "reachable" through
-   the S-NAPTR process for a particular application service can be
-   thought of as a "tree".  Each NAPTR RR retrieved points to more NAPTR
-   or SRV records; each SRV record points to several A record lookups.
-   Even though a particular client can "prune" the tree to use only
-   those records referring to application protocols supported by the
-
-
-
-Daigle & Newton          Expires August 15, 2004                [Page 7]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   client, the tree could be quite deep, and retracing the tree to retry
-   other targets can become expensive if the tree has many branches.
-
-   Therefore,
-
-   o  Fewer branches is better:  for both NAPTR and SRV records, provide
-      different targets with varying preferences where appropriate
-      (e.g., to provide backup services, etc), but don't look for
-      reasons to provide more.
-
-   o  Shallower is better:  avoid using NAPTR records to "rename"
-      services within a zone.  Use NAPTR records to identify services
-      hosted elsewhere (i.e., where you cannot reasonably provide the
-      SRV records in your own zone).
-
-
-3.3 Guidelines for Client Software Writers
-
-   To properly understand DDDS/NAPTR, an implementor must read [6].
-   However, the most important aspect to keep in mind is that, if one
-   target fails to work for the application, it is expected that the
-   application will continue through the S-NAPTR tree to try the (less
-   preferred) alternatives.
-
-4. Illustrations
-
-4.1 Use Cases
-
-   The basic intended use cases for which S-NAPTR has been developed
-   are:
-
-   o  Service discovery within a domain.  For example, this can be used
-      to find the "authoritative" server for some type of service within
-      a domain (see the specific example in Section 4.2).
-
-   o  Multiple protocols.  This is increasingly common as new
-      application services are defined.  This includes the case of
-      instant messaging (a service) which can be offered with multiple
-      protocols (see Section 4.3).
-
-   o  Remote hosting.  Each of the above use cases applies within the
-      administration of a single domain.  However, one domain operator
-      may elect to engage another organization to provide an application
-      service.  See Section 4.4 for an example that cannot be served by
-      SRV records alone.
-
-
-
-
-
-
-Daigle & Newton          Expires August 15, 2004                [Page 8]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-4.2 Service Discovery within a Domain
-
-   There are occasions when it is useful to be able to determine the
-   "authoritative" server for a given application service within a
-   domain.  This is "discovery", because there is no a priori knowledge
-   as to whether or where the service is offered; it is therefore
-   important to determine the location and characteristics of the
-   offered service.
-
-   For example, there is growing discussion of having a generic
-   mechanism for locating the keys or certificates associated with
-   particular application (servers) operated in (or for) a particular
-   domain.  Here's a hypothetical case for storing application key or
-   certificate data for a given domain.  The premise is that some
-   credentials registry (CredReg) service has been defined to be a leaf
-   node service holding the keys/certs for the servers operated by (or
-   for) the domain.  Furthermore, it is assumed that more than one
-   protocol is available to provide the service for a particular domain.
-   This DDDS-based approach is used to find the CredReg server that
-   holds the information.
-
-   Thus, the set of NAPTR records for thinkingcat.example might look
-   like this:
-
-   thinkingcat.example.
-   ;;       order pref flags service                 regexp  replacement
-   IN NAPTR 100   10   ""    "CREDREG:ldap:iris-beep" ""     theserver.thinkingcat.example.
-
-   Note that another domain, offering the same application service,
-   might offer it using a different set of application protocols:
-
-   anotherdomain.example.
-   ;;       order pref flags service                    regexp replacement
-   IN NAPTR 100   10   ""    "CREDREG:iris-lw:iris-beep" ""    foo.anotherdomain.example.
-
-
-4.3 Multiple Protocols
-
-   As it stands, there are several different protocols proposed for
-   offering "instant message" services.  Assuming that "IM" was
-   registered as an application service, this DDDS application could be
-   used to determine the available services for delivering to a target.
-
-   Two particular features of instant messaging should be noted:
-
-   1.  gatewaying is expected to bridge communications across protocols
-
-   2.  instant messaging servers are likely to be operated out of a
-
-
-
-Daigle & Newton          Expires August 15, 2004                [Page 9]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-       different domain than the instant messaging address, and servers
-       of different protocols may be offered by independent
-       organizations
-
-   For example, "thinkingcat.example" may support its own servers for
-   the "ProtA" instant messaging protocol, but rely on outsourcing from
-   "example.com" for "ProtC" and "ProtB" servers.
-
-   Using this DDDS-based approach, thinkingcat.example can indicate a
-   preference ranking for the different types of servers for the instant
-   messaging service, and yet the out-sourcer can independently rank the
-   preference and ordering of servers.  This independence is not
-   achievable through the use of SRV records alone.
-
-   Thus, to find the IM services for thinkingcat.example, the NAPTR
-   records for thinkingcat.example are retrieved:
-
-   thinkingcat.example.
-   ;;	order pref flags service   regexp replacement
-   IN NAPTR 100  10   "s"   "IM:ProtA" ""    _ProtA._tcp.thinkingcat.example.
-   IN NAPTR 100  20   "s"   "IM:ProtB" ""    _ProtB._tcp.example.com.
-   IN NAPTR 100  30   "s"   "IM:ProtC" ""    _ProtC._tcp.example.com.
-
-   and then the administrators at example.com can manage the preference
-   rankings of the servers they use to support the ProtB service:
-
-   _ProtB._tcp.example.com.
-    ;;    Pref Weight Port  Target
-   IN SRV 10    0     10001 bigiron.example.com
-   IN SRV 20    0     10001 backup.im.example.com
-   IN SRV 30    0     10001 nuclearfallout.australia-isp.example
-
-
-4.4 Remote Hosting
-
-   In the Instant Message hosting example in Section 4.3, the service
-   owner (thinkingcat.example) had to host pointers to the hosting
-   service's SRV records in the thinkingcat.example domain.
-
-   A better way to approach this is to have one NAPTR RR in the
-   thinkingcat.example domain pointing to all the hosted services, and
-   the hosting domain has NAPTR records for each service to map them to
-   whatever local hosts it chooses (and may change from time to time).
-
-
-
-
-
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 10]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   thinkingcat.example.
-   ;;      order pref flags service         regexp replacement
-   IN NAPTR 100  10   "s"   "IM:ProtA"       ""    _ProtA._tcp.thinkingcat.example.
-   IN NAPTR 100  20   ""    "IM:ProtB:ProtC" ""    thinkingcat.example.com.
-
-
-   and then the administrators at example.com can break out the
-   individual application protocols and manage the preference rankings
-   of the servers they use to support the ProtB service (as before):
-
-   thinkingcat.example.com.
-   ;;      order pref flags service   regexp  replacement
-   IN NAPTR 100  10   "s"   "IM:ProtC" ""     _ProtC._tcp.example.com.
-   IN NAPTR 100  20   "s"   "IM:ProtB" ""     _ProtB._tcp.example.com.
-
-
-
-   _ProtC._tcp.example.com.
-    ;;    Pref Weight Port  Target
-   IN SRV 10    0     10001 bigiron.example.com
-   IN SRV 20    0     10001 backup.im.example.com
-   IN SRV 30    0     10001 nuclearfallout.australia-isp.example
-
-
-4.5 Sets of NAPTR RRs
-
-   Note that the above sections assumed that there was one service
-   available (via S-NAPTR) per domain.  Often, that will not be the
-   case.  Assuming thinkingcat.example had the CredReg service set up as
-   described in Section 4.2 and the instant messaging service set up as
-   described in Section 4.4, then a client querying for the NAPTR RR set
-   from thinkingcat.com would get the following answer:
-
-   thinkingcat.example.
-   ;;       order pref flags service          regexp  replacement
-   IN NAPTR 100   10   "s"   "IM:ProtA"        ""     _ProtA._tcp.thinkingcat.example.
-   IN NAPTR 100   20   ""    "IM:ProtB:ProtC:" ""     thinkingcat.example.com.
-   IN NAPTR 200   10   ""    "CREDREG:ldap:iris-beep" "" bouncer.thinkingcat.example.
-
-   Sorting them by increasing "ORDER", the client would look through the
-   SERVICE strings to determine if there was a NAPTR RR that matched the
-   application service it was looking for, with an application protocol
-   it could use.  The first (lowest PREF) record that so matched is the
-   one the client would use to continue.
-
-4.6 Sample sequence diagram
-
-   Consider the example in Section 4.3.  Visually, the sequence of steps
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 11]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   required for the client to reach the final server for a "ProtB"
-   service for IM for the thinkingcat.example domain is as follows:
-
-
-   Client   NS for                NS for
-            thinkingcat.example   example.com    backup.im.example.com
-                |                     |                  |
-     1 -------->|                     |                  |
-     2 <--------|                     |                  |
-     3 ------------------------------>|                  |
-     4 <------------------------------|                  |
-     5 ------------------------------>|                  |
-     6 <------------------------------|                  |
-     7 ------------------------------>|                  |
-     8 <------------------------------|                  |
-     9 ------------------------------------------------->|
-    10 <-------------------------------------------------|
-    11 ------------------------------------------------->|
-    12 <-------------------------------------------------|
-   (...)
-
-
-
-   1.  the name server (NS) for thinkingcat.example is reached with a
-        request for all NAPTR records
-
-   2.  the server responds with the NAPTR records shown in Section 4.3.
-
-   3.  the second NAPTR record matches the desired criteria; that has an
-        "s" flag and a replacement fields of "_ProtB._tcp.example.com".
-        So, the client looks up SRV records for that target, ultimately
-        making the request of the NS for example.com.
-
-   4.  the response includes the SRV records listed in Section 4.3.
-
-   5.  the client attempts to reach the server with the lowest PREF in
-        the SRV list -- looking up the A record for the SRV record's
-        target (bigiron.example.com).
-
-   6.  the example.com NS responds with an error message -- no such
-        machine!
-
-   7.  the client attempts to reach the second server in the SRV list,
-        and looks up the A record for backup.im.example.com
-
-   8.  the client gets the A record with the IP address for
-        backup.im.example.com from example.com's NS.
-
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 12]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   9.  the client connects to that IP address, on port 10001 (from the
-        SRV record), using ProtB over tcp.
-
-   10.  the server responds with an "OK" message.
-
-   11.  the client uses ProtB to challenge that this server has
-        credentials to operate the service for the original domain
-        (thinkingcat.example)
-
-   12.  the server responds, and the rest is IM.
-
-
-5. Motivation and Discussion
-
-   Increasingly, application protocol standards are using domain names
-   to identify server targets, and stipulating that clients should look
-   up SRV resource records to determine the host and port providing the
-   server.  This enables a distinction between naming an application
-   service target and actually hosting the server.  It also increases
-   flexibility in hosting the target service:
-
-   o  the server may be operated by a completely different organization
-      without having to list the details of that organization's DNS
-      setup (SRVs)
-
-   o  multiple instances can be set up (e.g., for load balancing or
-      secondaries)
-
-   o  it can be moved from time to time without disrupting clients'
-      access, etc.
-
-   This is quite useful, but Section 5.1 outlines some of the
-   limitations inherent in the approach.
-
-   That is, while SRV records can be used to map from a specific service
-   name and protocol for a specific domain to a specific server, SRV
-   records are limited to one layer of indirection, and are focused on
-   server administration rather than on application naming.  And, while
-   the DDDS specification and use of NAPTR allows multiple levels of
-   redirection before locating the target server machine with an SRV
-   record, this proposal requires only a subset of NAPTR strictly bound
-   to domain names, without making use of the REGEXP field of NAPTR.
-   These restrictions make the client's resolution process much more
-   predictable and efficient than with some potential uses of NAPTR
-   records.  This is dubbed "S-NAPTR" -- a "S"traightforward use of
-   NAPTR records.
-
-
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 13]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-5.1 So, why not just SRV records?
-
-   An expected question at this point is: this is so similar in
-   structure to SRV records, why are we doing this with DDDS/NAPTR?
-
-   Limitations of SRV include:
-
-   o  SRV provides a single layer of indirection -- the outcome of an
-      SRV lookup is a new domain name for which the A RR is to be found.
-
-   o  the purpose of SRV is focused on individual server administration,
-      not application naming: as stated in [5] "The SRV RR allows
-      administrators to use several servers for a single domain, to move
-      services from host to host with little fuss, and to designate some
-      hosts as primary servers for a service and others as backups."
-
-   o  target servers by "service" (e.g., "ldap") and "protocol" (e.g.,
-      "tcp") in a given domain.  The definition of these terms implies
-      specific things (e.g., that protocol should be one of UDP or TCP)
-      without being precise.  Restriction to UDP and TCP is insufficient
-      for the uses described here.
-
-   The basic answer is that SRV records provide mappings from protocol
-   names to host and port.  The use cases described herein require an
-   additional layer -- from some service label to servers that may in
-   fact be hosted within different administrative domains.  We could
-   tweak SRV to say that the next lookup could be something other than
-   an address record, but that is more complex than is necessary for
-   most applications of SRV.
-
-5.2 So, why not just NAPTR records?
-
-   That's a trick question.  NAPTR records cannot appear in the wild --
-   see [6].  They must be part of a DDDS application.
-
-   The purpose here is to define a single, common mechanism (the DDDS
-   application) to use NAPTR when all that is desired is simple DNS-
-   based location of services.  This should be easy for applications to
-   use -- some simple IANA registrations and it's done.
-
-   Also, NAPTR has very powerful tools for expressing "rewrite" rules.
-   That power (==complexity) makes some protocol designers and service
-   administrators nervous.  The concern is that it can translate into
-   unintelligible, noodle-like rule sets that are difficult to test and
-   administer.
-
-   This proposed DDDS application specifically uses a subset of NAPTR's
-   abilities.  Only "replacement" expressions are allowed, not "regular
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 14]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   expressions".
-
-6. IANA Considerations
-
-   This document calls for 2 IANA registries:  one for application
-   service tags, and one for application protocol tags.
-
-   Application service and protocol tags should be defined in an RFC
-   (unless the "x-" experimental form is used, in which case they are
-   unregistered).  There are no restrictions placed on the tags other
-   than that they must conform with the syntax defined below (Appendix
-   A.5).  The IANA registries should list the tags and the RFC that
-   defines their use.
-
-7. Security Considerations
-
-   The security of this approach to application service location is only
-   as good as the security of the DNS servers along the way.  If any of
-   them is compromised, bogus NAPTR and SRV records could be inserted to
-   redirect clients to unintended destinations.  This problem is hardly
-   unique to S-NAPTR (or NAPTR in general).
-
-   To protect against DNS-vectored attacks, applications should define
-   some form of end-to-end authentication to ensure that the correct
-   destination has been reached.  Many application protocols such as
-   HTTPS, BEEP, IMAP, etc...  define the necessary handshake mechansims
-   to accomplish this task.
-
-   The basic mechanism works in the following way:
-
-   1.  During some portion of the protocol handshake, the client sends
-       to the server the original name of the desired destination (i.e.
-       no transformations that may have resulted from NAPTR
-       replacements, SRV targets, or CNAME changes).  In certain cases
-       where the application protocol does not have such a feature but
-       TLS may be used, it is possible to use the "server_name" TLS
-       extension.
-
-   2.  The server sends back to the client a credential with the
-       appropriate name.  For X.509 certificates, the name would either
-       be in the subjectDN or subjectAltName fields.  For Kerberos, the
-       name would be a service principle name.
-
-   3.  Using the matching semantics defined by the application protocol,
-       the client compares the name in the credential with the name sent
-       to the server.
-
-   4.  If the names match, there is reasonable assurance that the
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 15]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-       correct end point has been reached.
-
-   It is important to note that this document does not define either the
-   handshake mechanism, the specific credenential naming fields, nor the
-   name matching semantics.  Definitions of S-NAPTR for particular
-   application protocols MUST define these.
-
-8. Acknowledgements
-
-   Many thanks to Dave Blacka, Patrik Faltstrom, Sally Floyd for
-   discussion and input that has (hopefully!) provoked clarifying
-   revisions of this document.
-
-References
-
-   [1]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
-        Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
-
-   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [3]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
-        Specifications: ABNF", RFC 2234, November 1997.
-
-   [4]  Eastlake, D., "Domain Name System Security Extensions", RFC
-        2535, March 1999.
-
-   [5]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
-        specifying the location of services (DNS SRV)", RFC 2782,
-        February 2000.
-
-   [6]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
-        One: The Comprehensive DDDS", RFC 3401, October 2002.
-
-   [7]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
-        Three: The Domain Name System (DNS) Database", RFC 3403, October
-        2002.
-
-   [8]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
-        Four: The Uniform Resource Identifiers (URI)", RFC 3404, October
-        2002.
-
-
-
-
-
-
-
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 16]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-Authors' Addresses
-
-   Leslie Daigle
-   VeriSign, Inc.
-   21355 Ridgetop Circle
-   Dulles, VA  20166
-   US
-
-   EMail: leslie@verisignlabs.com; leslie@thinkingcat.com
-
-
-   Andrew Newton
-   VeriSign, Inc.
-   21355 Ridgetop Circle
-   Dulles, VA  20166
-   US
-
-   EMail: anewton@verisignlabs.com
-
-Appendix A. Application Service Location Application of DDDS
-
-   This section defines the DDDS application, as described in [6].
-
-A.1 Application Unique String
-
-   The Application Unique String is domain label for which an
-   authoritative server for a particular service is sought.
-
-A.2 First Well Known Rule
-
-   The "First Well Known Rule" is identity -- that is, the output of the
-   rule is the Application Unique String, the domain label for which the
-   authoritative server for a particular service is sought.
-
-A.3 Expected Output
-
-   The expected output of this Application is the information necessary
-   to connect to authoritative server(s) (host, port, protocol) for an
-   application service within a given a given domain.
-
-A.4 Flags
-
-   This DDDS Application uses only 2 of the Flags defined for the
-   URI/URN Resolution Application ([8]): "S" and "A".  No other Flags
-   are valid.
-
-   Both are for terminal lookups.  This means that the Rule is the last
-   one and that the flag determines what the next stage should be.  The
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 17]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   "S" flag means that the output of this Rule is a domain label for
-   which one or more SRV [5] records exist.  "A" means that the output
-   of the Rule is a domain name and should be used to lookup address
-   records for that domain.
-
-   Consistent with the DDDS algorithm, if the Flag string is empty the
-   next lookup is for another NAPTR record (for the replacement target).
-
-A.5 Service Parameters
-
-   Service Parameters for this Application take the form of a string of
-   characters that follow this ABNF ([3]):
-
-      service-parms = [ [app-service] *(":" app-protocol)]
-      app-service   = experimental-service  / iana-registered-service
-      app-protocol  = experimental-protocol / iana-registered-protocol
-      experimental-service      = "x-" 1*30ALPHANUMSYM
-      experimental-protocol     = "x-" 1*30ALPHANUMSYM
-      iana-registered-service   = ALPHA *31ALPHANUMSYM
-      iana-registered-protocol  = ALPHA *31ALPHANUM
-      ALPHA         =  %x41-5A / %x61-7A   ; A-Z / a-z
-      DIGIT         =  %x30-39 ; 0-9
-      SYM           =  %x2B / %x2D / %x2E  ; "+" / "-" / "."
-      ALPHANUMSYM   =  ALPHA / DIGIT / SYM
-      ; The app-service and app-protocol tags are limited to 32
-      ; characters and must start with an alphabetic character.
-      ; The service-parms are considered case-insensitive.
-
-   Thus, the Service Parameters may consist of an empty string, just an
-   app-service, or an app-service with one or more app-protocol
-   specifications separated by the ":" symbol.
-
-   Note that this is similar to, but not the same as the syntax used in
-   the URI DDDS application ([8]).  The DDDS DNS database requires each
-   DDDS application to define the syntax of allowable service strings.
-   The syntax here is expanded to allow the characters that are valid in
-   any URI scheme name (see [1]).  Since "+" (the separator used in the
-   RFC3404 service parameter string) is an allowed character for URI
-   scheme names, ":" is chosen as the separator here.
-
-A.5.1 Application Services
-
-   The "app-service" must be a registered service [this will be an IANA
-   registry; this is not the IANA port registry, because we want to
-   define services for which there is no single protocol, and we don't
-   want to use up port space for nothing].
-
-
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 18]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-A.5.2 Application Protocols
-
-   The protocol identifiers that are valid for the "app-protocol"
-   production are any standard, registered protocols [IANA registry
-   again -- is this the list of well known/registered ports?].
-
-A.6 Valid Rules
-
-   Only substitution Rules are permitted for this application.  That is,
-   no regular expressions are allowed.
-
-A.7 Valid Databases
-
-   At present only one DDDS Database is specified for this Application.
-   [7] specifies a DDDS Database that uses the NAPTR DNS resource record
-   to contain the rewrite rules.  The Keys for this database are encoded
-   as domain-names.
-
-   The First Well Known Rule produces a domain name, and this is the Key
-   that is used for the first lookup -- the NAPTR records for that
-   domain are requested.
-
-   DNS servers MAY interpret Flag values and use that information to
-   include appropriate NAPTR, SRV or A records in the Additional
-   Information portion of the DNS packet.  Clients are encouraged to
-   check for additional information but are not required to do so.  See
-   the Additional Information Processing section of [7] for more
-   information on NAPTR records and the Additional Information section
-   of a DNS response packet.
-
-Appendix B. Pseudo pseudocode for S-NAPTR
-
-B.1 Finding the first (best) target
-
-   Assuming the client supports 1 protocol for a particular application
-   service, the following pseudocode outlines the expected process to
-   find the first (best) target for the client, using S-NAPTR.
-
-
-    target = [initial domain]
-    naptr-done = false
-
-    while (not naptr-done)
-     {
-      NAPTR-RRset = [DNSlookup of NAPTR RRs for target]
-      [sort NAPTR-RRset by ORDER, and PREF within each ORDER]
-      rr-done = false
-      cur-rr = [first NAPTR RR]
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 19]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-      while (not rr-done)
-         if ([SERVICE field of cur-rr contains desired application
-              service and application protocol])
-            rr-done = true
-            target= [REPLACEMENT target of NAPTR RR]
-         else
-            cur-rr = [next rr in list]
-
-         if (not empty [FLAG in cur-rr])
-            naptr-done = true
-     }
-
-    port = -1
-
-    if ([FLAG in cur-rr is "S"])
-     {
-      SRV-RRset = [DNSlookup of SRV RRs for target]
-      [sort SRV-RRset based on PREF]
-      target = [target of first RR of SRV-RRset]
-      port = [port in first RR of SRV-RRset]
-     }
-
-    ; now, whether it was an "S" or an "A" in the NAPTR, we
-    ; have the target for an A record lookup
-
-    host = [DNSlookup of target]
-
-    return (host, port)
-
-
-
-B.2 Finding subsequent targets
-
-   The pseudocode in Appendix B is crafted to find the first, most
-   preferred, host-port pair for a particular application service an
-   protocol.  If, for any reason, that host-port pair did not work
-   (connection refused, application-level error), the client is expected
-   to try the next host-port in the S-NAPTR tree.
-
-   The pseudocode above does not permit retries -- once complete, it
-   sheds all context of where in the S-NAPTR tree it finished.
-   Therefore, client software writers could
-
-   o  entwine the application-specific protocol with the DNS lookup and
-      RRset processing described in the pseudocode and continue the S-
-      NAPTR processing if the application code fails to connect to a
-      located host-port pair;
-
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 20]
-
-Internet-Draft           draft-daigle-napstr-04            February 2004
-
-
-   o  use callbacks for the S-NAPTR processing;
-
-   o  use an S-NAPTR resolution routine that finds *all* valid servers
-      for the required application service and protocol from the
-      originating domain, and provides them in sorted order for the
-      application to try in order.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 21]
-
-Internet-Draft           draft-daigle-napstr-04            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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daigle & Newton          Expires August 15, 2004               [Page 22]
-
diff --git a/contrib/bind9/doc/draft/draft-danisch-dns-rr-smtp-03.txt b/contrib/bind9/doc/draft/draft-danisch-dns-rr-smtp-03.txt
deleted file mode 100644
index 4a01d91..0000000
--- a/contrib/bind9/doc/draft/draft-danisch-dns-rr-smtp-03.txt
+++ /dev/null
@@ -1,1960 +0,0 @@
-
-
-
-INTERNET-DRAFT                                           Hadmut Danisch
-Category: Experimental                                         Oct 2003
-Expires: Apr 1, 2004
-
- The RMX DNS RR and method for lightweight SMTP sender authorization
-                   draft-danisch-dns-rr-smtp-03.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/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-Abstract
-
-   This memo introduces a new authorization scheme for SMTP e-mail
-   transport. It is designed to be a simple and robust protection
-   against e-mail fraud, spam and worms. It is based solely on
-   organisational security mechanisms and does not require but still
-   allow use of cryptography. This memo also focuses on security and
-   privacy problems and requirements in context of spam defense. In
-   contrast to prior versions of the draft a new RR type is not
-   required anymore.
-
-
-
-
-
-
-
-
-
-
-
-
-Hadmut Danisch                Experimental                      [Page 1]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-                           Table of Contents
-
-
-1.  General Issues . . . . . . . . . . . . . . . . . . . . . . . . .   4
-2.  Problem and threat description . . . . . . . . . . . . . . . . .   4
-    2.1.  Mail sender forgery  . . . . . . . . . . . . . . . . . . .   4
-          2.1.1  Definition of sender forgery  . . . . . . . . . . .   4
-          2.1.2  Spam  . . . . . . . . . . . . . . . . . . . . . . .   5
-          2.1.3  E-Mail Worms  . . . . . . . . . . . . . . . . . . .   5
-          2.1.4  E-Mail spoofing and fraud . . . . . . . . . . . . .   5
-    2.2.  Indirect damage caused by forgery  . . . . . . . . . . . .   6
-    2.3.  Technical problem analysis . . . . . . . . . . . . . . . .   6
-    2.4.  Shortcomings of cryptographical approaches . . . . . . . .   7
-3.  A DNS based sender address verification  . . . . . . . . . . . .   7
-    3.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .   7
-    3.2.  Envelope vs. header sender address . . . . . . . . . . . .   9
-    3.3.  Domain part vs. full sender address  . . . . . . . . . . .   9
-4.  Mapping of E-Mail addresses to DNS names . . . . . . . . . . . .  10
-    4.1.  Domain part only . . . . . . . . . . . . . . . . . . . . .  10
-    4.2.  Full address . . . . . . . . . . . . . . . . . . . . . . .  11
-    4.3.  Empty address  . . . . . . . . . . . . . . . . . . . . . .  11
-5.  Mandatory entry types and their syntax . . . . . . . . . . . . .  11
-    5.1.  Overall structure  . . . . . . . . . . . . . . . . . . . .  11
-    5.2.  Unused . . . . . . . . . . . . . . . . . . . . . . . . . .  12
-    5.3.  IPv4 and IPv6 address ranges . . . . . . . . . . . . . . .  12
-    5.4.  DNS Hostname . . . . . . . . . . . . . . . . . . . . . . .  13
-          5.4.1  Road warriors and DynDNS entries  . . . . . . . . .  13
-    5.5.  APL Reference  . . . . . . . . . . . . . . . . . . . . . .  14
-    5.6.  Domain Member  . . . . . . . . . . . . . . . . . . . . . .  14
-    5.7.  Full Address Query . . . . . . . . . . . . . . . . . . . .  15
-    5.8.  DNS mapped authorization . . . . . . . . . . . . . . . . .  15
-    5.9.  RMX reference  . . . . . . . . . . . . . . . . . . . . . .  16
-6.  Optional and experimental entry types  . . . . . . . . . . . . .  16
-    6.1.  TLS fingerprint  . . . . . . . . . . . . . . . . . . . . .  16
-    6.2.  TLS and LDAP . . . . . . . . . . . . . . . . . . . . . . .  16
-    6.3.  PGP or S/MIME signature  . . . . . . . . . . . . . . . . .  16
-    6.4.  Transparent Challenge/Response . . . . . . . . . . . . . .  17
-    6.5.  SASL Challenge/Response  . . . . . . . . . . . . . . . . .  17
-7.  Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . .  17
-    7.1.  Alternative encoding as TXT records  . . . . . . . . . . .  17
-    7.2.  RMX Records  . . . . . . . . . . . . . . . . . . . . . . .  17
-          7.2.1  Overall structure . . . . . . . . . . . . . . . . .  18
-          7.2.2  Record encoding . . . . . . . . . . . . . . . . . .  18
-          7.2.3  Encoding of IPv4 and IPv6 address ranges  . . . . .  18
-          7.2.4  Encoding of DNS . . . . . . . . . . . . . . . . . .  18
-          7.2.5  Encoding of unused and full query . . . . . . . . .  19
-          7.2.6  Additional Records  . . . . . . . . . . . . . . . .  19
-8.  Message Headers  . . . . . . . . . . . . . . . . . . . . . . . .  19
-
-
-
-Hadmut Danisch                Experimental                      [Page 2]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-9.  SMTP error messages  . . . . . . . . . . . . . . . . . . . . . .  20
-10.  Message relaying and forwarding . . . . . . . . . . . . . . . .  20
-    10.1.  Problem description . . . . . . . . . . . . . . . . . . .  20
-    10.2.  Trusted relaying/forwarding . . . . . . . . . . . . . . .  21
-    10.3.  Untrusted relaying/forwarding . . . . . . . . . . . . . .  21
-11.  Security Considerations . . . . . . . . . . . . . . . . . . . .  22
-    11.1.  Draft specific considerations . . . . . . . . . . . . . .  22
-          11.1.1  Authentication strength  . . . . . . . . . . . . .  22
-          11.1.2  Where Authentication and Authorization end . . . .  22
-          11.1.3  Vulnerability of DNS . . . . . . . . . . . . . . .  23
-          11.1.4  Sneaking RMX attack?   . . . . . . . . . . . . . .  25
-          11.1.5  Open SMTP relays . . . . . . . . . . . . . . . . .  25
-          11.1.6  Unforged Spam  . . . . . . . . . . . . . . . . . .  25
-          11.1.7  Reliability of Whois Entries . . . . . . . . . . .  26
-          11.1.8  Hazards for Freedom of Speech  . . . . . . . . . .  26
-    11.2.  General Considerations about spam defense . . . . . . . .  27
-          11.2.1  Action vs. reaction  . . . . . . . . . . . . . . .  27
-          11.2.2  Content based Denial of Service attacks  . . . . .  27
-12.  Privacy Considerations  . . . . . . . . . . . . . . . . . . . .  28
-    12.1.  Draft specific considerations . . . . . . . . . . . . . .  28
-          12.1.1  No content leaking . . . . . . . . . . . . . . . .  28
-          12.1.2  Message reception and sender domain  . . . . . . .  28
-          12.1.3  Network structure  . . . . . . . . . . . . . . . .  29
-          12.1.4  Owner information distribution . . . . . . . . . .  29
-    12.2.  General Considerations about spam defense . . . . . . . .  29
-          12.2.1  Content leaking of content filters . . . . . . . .  29
-          12.2.2  Black- and Whitelists  . . . . . . . . . . . . . .  30
-13.  Deployment Considerations . . . . . . . . . . . . . . . . . . .  30
-    13.1.  Compatibility . . . . . . . . . . . . . . . . . . . . . .  30
-          13.1.1  Compatibility with old mail receivers  . . . . . .  30
-          13.1.2  Compatibility with old mail senders  . . . . . . .  30
-          13.1.3  Compatibility with old DNS clients . . . . . . . .  30
-          13.1.4  Compatibility with old DNS servers . . . . . . . .  30
-    13.2.  Enforcement policy  . . . . . . . . . . . . . . . . . . .  31
-14.  General considerations about fighting spam  . . . . . . . . . .  31
-    14.1.  The economical problem  . . . . . . . . . . . . . . . . .  31
-    14.2.  The POP problem . . . . . . . . . . . . . . . . . . . . .  32
-    14.3.  The network structure problem . . . . . . . . . . . . . .  33
-    14.4.  The mentality problem . . . . . . . . . . . . . . . . . .  33
-    14.5.  The identity problem  . . . . . . . . . . . . . . . . . .  33
-    14.6.  The multi-legislation problem . . . . . . . . . . . . . .  34
-Implementation and further Information . . . . . . . . . . . . . . .  34
-References . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  34
-Draft History  . . . . . . . . . . . . . . . . . . . . . . . . . . .  35
-Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . .  35
-
-
-
-
-
-
-Hadmut Danisch                Experimental                      [Page 3]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-1.  General Issues
-
-   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 [1].
-
-2.  Problem and threat description
-
-2.1.  Mail sender forgery
-
-   The amount of e-mails with forged sender addresses has dramatically
-   increased. As a consequence, damages and annoyances caused by such
-   e-mails increased as well. In the majority of examined e-mails the
-   domain name of the envelope sender address was forged, and the e-
-   mail was sent from an IP address which does not belong to a network
-   used by the actual owner of the domain.
-
-2.1.1.  Definition of sender forgery
-
-   As discussions, comments to prior versions of this draft, and
-   different approaches to stop forgery showed, different perceptions
-   of "mail forgery" exist. For example, there are mechanisms to
-   verify e-mail addresses for mailing lists, web servers, or to stop
-   spam, which do send a message with a random number to the given
-   address and expect the user to send a reply. Here, someone is
-   considered to be allowed to use a particular e-mail address, if and
-   only if he is able to receive informations sent to this address,
-   and is able to reply to such a message. While this definition
-   appears to be quite plausible and natural, it can't be used for a
-   simple technical solution. Sending back a challenge and expecting a
-   reply is simply too much overhead and time delay, and not every
-   authorized sender is able or willing to reply (e.g. because he went
-   offline or is not a human).
-
-   Within the scope of this memo, sender forgery means that the
-   initiator of an e-mail transfer (which is the original sender in
-   contrast to relays) uses a sender address which he was not
-   authorized to use. Being authorized to use an address means that
-   the owner (administrator) of the internet domain has given
-   permission, i.e. agrees with the use of the address by that
-   particular sender. This memo will cover both the permission of the
-   full e-mail address and the domain part only for simplicity.
-
-   Within context of Internet and SMTP, the sender address usually
-   occurs twice, once as the envelope sender address in SMTP, and once
-   as the address given in the RFC822 mail header. While the following
-   considerations apply to both addresses in principle, it is
-   important to stress that both addresses have distinct semantics and
-
-
-
-Hadmut Danisch                Experimental                      [Page 4]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   are not neccessarily the same. The envelope address identifies the
-   initiator of the transport, while the header identifies the author
-   of the message content. Since this memo deals with the message
-   transport only and completely ignores the message content, the
-   method should naturally be applied to the envelope sender address.
-
-2.1.2.  Spam
-
-   A common and well known problem is the dramatic increase of
-   unsolicited e-mail, commonly called "spam". Again, the majority of
-   examined e-mails had forged sender addresses.  The abused domains
-   were mainly those of common webmailers as hotmail or yahoo, or
-   well-known companies.
-
-   Unfortunately, there is no accurate definition of spam availabe
-   yet, and neither are the concise technical criterions to filter or
-   block spam with technical mechanisms. There are efforts to design
-   content based filters, but these filters are expensive in
-   calculation time (and sometimes money), and they do not reliably
-   provide predictable results. Usually they give false positives
-   and/or require user interaction. Content filters in general suffer
-   from a design problem described later in this memo.  Therefore,
-   this proposal does not use the content based approach to block
-   spam.
-
-   As analysis of spam messages showed, most of spam messages were
-   sent with forged envelope sender addresses. This has mainly three
-   reasons.  The first reason is, that spam senders usually do not
-   want to be contacted by e-mail. The second reason is, that they do
-   not want to be blacklisted easily. The third reason is, that spam
-   is or is going to be unlawful in many countries, and the sender
-   does not want to reveal his identity. Therefore, spam is considered
-   to be a special case of sender forgery.
-
-2.1.3.  E-Mail Worms
-
-   Another example of sender forgery is the reproduction of e-mail
-   worms. Most worms do choose random sender addresses, e.g.  using
-   the addresses found in mailboxes on the infected system. In most
-   cases analyzed by the author, the e-mails sent by the reproduction
-   process can also be categorized as forged, since the infected
-   system would under normal circumstances not be authorized to send
-   e-mails with such e-mail addresses. So forgery does not require a
-   malicious human to be directly involved. This memo covers any kind
-   of e-mail sender address forgery, included those generated by
-   malicious software.
-
-2.1.4.  E-Mail spoofing and fraud
-
-
-
-Hadmut Danisch                Experimental                      [Page 5]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   Forging e-mail sender addresses for fraud or other kinds of
-   deception ("human engineering") has also dramatically increased.
-   There are many known cases where single or mass e-mails were sent
-   with wrong sender addresses, pretending to come from service
-   provider, software manufacturers etc., and asking the receiver to
-   install any software or patches, or to reply with any confidential
-   information. The Internet is becoming more and more a scene of
-   crime, and so are it's services, including e-mail. It is obvious
-   that crime based on e-mail is eased by the fact that SMTP allows
-   arbitrary sender address spoofing.
-
-2.2.  Indirect damage caused by forgery
-
-   As observed by the author, mass mails and worms with forged sender
-   addresses can cause a severe damage for the real owner of the
-   abused sender addresses. If a sender A is sending an e-mail to the
-   receiver B, pretending to be C by using a sender address of C's
-   domain, then C has currently no chance to prevent this, since C's
-   machines and software are not involved in any way in the delivery
-   process between A and B.  B will nevertheless send any error
-   messages (virus/spam alert, "no such user", etc.) to C, erroneously
-   assuming that the message was sent by C. The author found several
-   cases where this flood of error messages caused a severe denial of
-   service or a dramatic increase of costs, e.g. when C was
-   downloading the e-mail through expensive or low bandwidth
-   connections (e.g. modem or mobile phones), or where disk space was
-   limited. The author examined mass mailings, where several tens or
-   hundreds of thousands of messages were sent to several addresses
-   around the world, where these messages caused only annoyance. But
-   since several thousands of these addresses were invalid or didn't
-   accept the message, the owner of the DNS domain which was abused by
-   the spammer to forge sender addresses was flooded for several
-   months with thousands of error messages, jamming the e-mail system
-   and causing severe costs and damages.
-
-   As a consequence, when A sends a message to B, pretending to be C,
-   there must be any mechanism to allow C to inform B about the fact,
-   that A is not authorized to use C as a sender address. This is what
-   this memo is about.
-
-2.3.  Technical problem analysis
-
-   Why does e-mail forgery actually exist? Because of the lack of the
-   Simple Mail Transfer Protocol SMTP[2] to provide any kind of sender
-   authentication, authorisation, or verification. This protocol was
-   designed at a time where security was not an issue. Efforts have
-   been made to block forged e-mails by requiring the sender address
-   domain part to be resolvable.  This method provides protection from
-
-
-
-Hadmut Danisch                Experimental                      [Page 6]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   e-mails with non-existing sender domains, and indeed, for some time
-   it blocked most spam e-mails. However, since attackers and spam
-   senders began to abuse existing domain names, this method was
-   rendered ineffective.
-
-2.4.  Shortcomings of cryptographical approaches
-
-   At a first glance, the problem of sender address forgery might
-   appear to be solvable with cryptographic methods such as challenge
-   response authentications or digital signatures. A deeper analysis
-   shows that only a small, closed user group could be covered with
-   cryptographical methods. Any method used to stop spam forgery must
-   be suitable to detect forgery not only for a small number of
-   particular addresses, but for all addresses on the world. An
-   attacker does not need to know the secrets belonging to a
-   particular address. It is sufficient to be able to forge any
-   address and thus to know any secret key. Since there are several
-   hundreds of millions of users, there will always be a large amount
-   of compromised keys, thus spoiling any common cryptographic method.
-   Furthermore, cryptography has proven to be far too complicated and
-   error prone to be commonly administered and reliably implemented.
-   Many e-mail and DNS administrators do not have the knowledge
-   required to deal with cryptographic mechanisms. Many legislations
-   do not allow the general deployment of cryptography and a directory
-   service with public keys. For these reasons, cryptography is
-   applicable only to a small and closed group of users, but not to
-   all participants of the e-mail service.
-
-3.  A DNS based sender address verification
-
-3.1.  Overview
-
-   To gain improvement in e-mail authenticity while keeping as much
-   SMTP compatibility as possible, a method is suggested which doesn't
-   change SMTP at all.
-
-   The idea is to store informations about how to verify who is
-   authorized to transmit e-mails through SMTP with a particular
-   sender address (either full address or - for simplicity - only the
-   domain part of the address) in a directory service, which is
-   currently the DNS. To be precise, the verification consists of two
-   steps, the classical pair of authentication and authorization:
-
-   The first step is the authentication. While several methods are
-   possible to perform authentication (see below), the most important
-   and robust method is the verification of the sender's IP address.
-   This is done implicitely by TCP/IP and the TCP sequence number. The
-   authenticated identity is the IP address. It has to be stressed
-
-
-
-Hadmut Danisch                Experimental                      [Page 7]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   that this TCP/IP "authentication" is a weak authentication and
-   vulnerable to several attacks. It is nevertheless sufficient for
-   this purpose, especially for blocking spam. It doesn't take any
-   implementation and it doesn't cost: It is already there, it is a
-   functionality of TCP/IP. An incoming SMTP connection based on
-   TCP/IP already carries the sender's IP address without any
-   modification of SMTP. See below (section Entry types) for more
-   details about authentication methods.
-
-   The second step is the authorization. It is based on the identity
-   given by the previous authentication step, e.g. the IP address of
-   the originator of the incoming SMTP connection,  and on the
-   envelope sender address. The mechanism proposed in this memo
-   answers the question "Is that particular sender (IP address,...)
-   allowed to send with that sender address" by querying and
-   processing informations stored in a directory service, which is
-   DNS.
-
-   When the sender has issued the "MAIL FROM:" SMTP command, the
-   receiving mail transfer agent (MTA) can - and modern MTAs do -
-   perform some authorization checks, e.g. run a local rule database
-   or check whether the sender domain is resolvable.
-
-   The suggested method is to let the DNS server for the sender domain
-   provide informations about who - this means for example which IP
-   address - is authorized to use an address or a domain as a part of
-   it.  After receiving the "MAIL FROM:" SMTP command, the receiving
-   MTA can verify, whether e. g. the IP address of the sending MTA is
-   authorized to send mails with this domain name. Therefore, a list
-   of entries with authorized IP addresses or other informations is
-   provided by the authoritative DNS server of that domain. The entry
-   types are described in the subsequent chapters. Some of these
-   methods are
-
-     - An IPv4 or IPv6 network address and mask
-     - A fully qualified domain name referring to an A record
-     - A fully qualified domain name referring to an APL record
-
-   RMX records of these types would look like this:
-
-      somedomain.de.      IN RMX ipv4:10.0.0.0/8
-      rmxtest.de.         IN RMX host:relay.provider.com
-      danisch.de.         IN RMX apl:relays.rackland.de
-      relays.rackland.de. IN APL 1:213.133.101.23/32 1:1.2.3.0/24
-
-   where the machine with the example address 213.133.101.23 and the
-   machines in the example subnet 1.2.3.0/24 are the only machines
-   allowed to send e-mails with an envelope sender address of domain
-
-
-
-Hadmut Danisch                Experimental                      [Page 8]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   danisch.de. Since the APL records do not necessarily belong to the
-   same domain or zone table as the RMX records, this easily allows to
-   refer to APL records defined by someone else, e.g. the internet
-   access or server hosting provider, thus reducing administrative
-   overhead to a minimum. In the example given above, the domain
-   danisch.de and several other domains are hosted by the service
-   provider Rackland. So if the relay structure of Rackland is
-   modified, only the zone of rackland.de needs to be modified. The
-   domain owners don't need to care about such details.
-
-3.2.  Envelope vs. header sender address
-
-   Questions were raised why the proposed mechanism is based on the
-   envelope sender address, and not on the sender address given in the
-   message header. Technically, both can be used. Actually, it makes
-   sense to use the envelope address.
-
-   In common, the header sender address identifies the author of the
-   content, while the envelope sender tells who caused the
-   transmission.  The approach proposed in this memo is transmission
-   based, not content based. We can not authorize the author of a
-   message if we don't have contact with him, if the message does not
-   already contain a signature. In contrast, the sending MTA is linked
-   to an IP address which can be used for authentication. This
-   mechanism might not be very strong, but it is available and
-   sufficient to solve today's e-mail security problems.
-
-   Some people argued that it is the header address and not the sender
-   address, which is displayed in common mail readers (MUAs), and
-   where the receiver believes the mail comes from. That's true, but
-   it doesn't help. There are many cases where the header sender
-   differs from the envelope sender for good reasons (see below in the
-   consequences chapter for the discussion about relaying).  Relaying,
-   mailing lists etc. require to replace the sender address used for
-   RMX. If this were the header address, the message header would have
-   to be modified. This is undesirable.
-
-3.3.  Domain part vs. full sender address
-
-   Former versions of this draft were limited to the domain part of
-   the sender address. The first reason is that it is common and MX-
-   like, to lookup only the domain part of an e-mail address in DNS.
-   The second reason is, that it was left to the private business of
-   the domain administration to handle details of user verification.
-   The idea was that the domain administration takes care to verify
-   the left part of an e-mail address with an arbitrary method of
-   their individual taste. RMX was originally designed to ignore the
-   left part of the address and to expect the domain administration to
-
-
-
-Hadmut Danisch                Experimental                      [Page 9]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   take over responsibility for enforcing their policy. If, e.g., a
-   spam message arrived and passed the RMX mechanism, it is known to
-   be authorized by the domain administration and they can be blamed,
-   no matter what is on the left side of the sender address - it's
-   their private problem what happens on the left side of the @. By
-   far the most of the comments to prior versions of this draft agreed
-   with that. A few comments asked for a finer granularity.
-
-   And indeed, there is no technical reason against a finer
-   granularity.  All it takes is a mapping from a given envelope
-   sender address to a DNS name, and the RMX lookup for that
-   particular e-mail address could be done instead of a lookup for the
-   domain part only.  However, to my knowledge, most domain
-   administrators would not like to provide an RMX entry for every
-   single e-mail address. In many cases, this would also overload DNS
-   servers.
-
-   It is to be discussed how to cover both views. One method could be
-   to query the full address, and if no RMX records were found to
-   query the domain part only. A different approach would be to query
-   the domain part only, and if it's RMX record contain a special
-   entry, then a new query for the full address is triggered. A third
-   way would be to always query the full address and to leave the
-   problem to the wildcard mechanism of DNS. This still has to be
-   discussed and will be described in future versions of this draft.
-
-
-
-
-
-
-
-
-
-
-
-4.  Mapping of E-Mail addresses to DNS names
-
-   To perform the RMX query, a mapping is needed from E-Mail addresses
-   to DNS fully qualified domain names.
-
-   This chapter is under development and just a first approach.
-
-4.1.  Domain part only
-
-   Mapping of the domain part is trivial, since the domain part of an
-   e-mail address itself is a valid DNS name and does not need
-   translation. It might be nevertheless desirable to distinguish the
-
-
-
-Hadmut Danisch                Experimental                     [Page 10]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   RMX entries from other entries, depending of the encoding of the
-   records. If the RMX entries are encoded in TXT record types, they
-   might collide with other uses of TXT records.  It might be
-   necessary to prepend the domain part with a special prefix, e.g.
-   _rmx. So the e-mail address some.user@example.com could be mapped
-   to example.com or _rmx.example.com.
-
-4.2.  Full address
-
-   Mapping a full address is slightly more difficult. The @ sign must
-   be unambiguously translated, and therefore can not be simply
-   translated into a dot. The e-mail addresses some.user@example.com
-   and some@user.example.com must have different mappings. Therefore,
-   the @ sign could be translated into _rmx, implicitely assuming that
-   this is not an allowed domain name component of normal domain
-   names. Then the rightmost _rmx in the mapped DNS name always
-   corresponds to the @ sign. some.user@example.com would e translated
-   into some.user._rmx.example.com and can be covered by a wildcard
-   entry like *._rmx.example.com.
-
-   Character encoding and character sets are still to be discussed.
-
-4.3.  Empty address
-
-   Unfortunately, SMTP allows empty envelope sender addresses to be
-   used for error messages. Empty sender addresses can therefore not
-   be prohibited. As observed, a significant amount of spam was sent
-   with such an empty sender address. To solve this problem, the host
-   name given in the HELO or EHLO command is taken to lookup the RMX
-   records instead. This makes sense, since such messages were
-   generated by the machine, not a human.
-
-
-
-
-5.  Mandatory entry types and their syntax
-
-   The entry types described in this section MUST be supported by any
-   implementation of this draft.
-
-5.1.  Overall structure
-
-   Similar to APL, an RMX record is just a concatenation of zero or
-   more RMX entries. The entries within one record form an ordered
-   rule base as commonly usual in packet filtes and firewall rulesets,
-   i. e. they are processed one ofter another until the first entry
-   matches. This entry determines the result of the query. Once a
-   matching entry is found, the RMX processing is finished.
-
-
-
-Hadmut Danisch                Experimental                     [Page 11]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   For any domain name there should not exist more than a single RMX
-   record. Due to the structure of DNS, it is nevertheless possible to
-   have more than a single RMX record. Multiple RMX records are
-   treated as a single record consisting of the concatenation of all
-   records. While the entries in a record are ordered, the records are
-   not ordered and may be processed in arbitrary order. If the order
-   of the entries matters, it is the zone maintainer's responsibility
-   to keep those entries in a single record. For example, there are
-   negative entries, which exclude IP addresses from authorization.
-   It is important that these entries are processed before positive
-   entries giving permission to a wider address range. Since order is
-   guaranteed only within a record, corresponding negative and
-   positive entries must be put in the same record.
-
-   An RMX record may consist of one or more entries, where the entries
-   are separated by whitespace. An entry must not contain white space.
-   Each entry consists of an optional exclamation sign, a tag, a
-   colon, and the entry data:
-
-      [!] TAG : ENTRY-SPECIFIC-DATA
-
-   If the entry starts with an exclamation sign, the entry is negated.
-   See the entry type description below for details.
-
-   The TAG is the mnemonic type identifier or the decimal number of
-   the entry. The TAG is case-insensitive. It is immediately followed
-   by a colon.
-
-   The syntax and semantics of ENTRY-SPECIFIC-DATA depends of the the
-   entry type. See description below.
-
-   Example:
-
-      danisch.de.  IN RMX apl:relays.rackland.de !ipv4:1.2.3.5
-   ipv4:1.2.3.0/24
-
-5.2.  Unused
-
-   This is a primitive entry which just says that this sender address
-   will never be used as a sender address under any circumstances.
-   Example:
-
-   testdomain.danisch.de    IN RMX unused:
-
-5.3.  IPv4 and IPv6 address ranges
-
-   These entry types contain a bit sequence representing a CIDR
-   address part. If that bit sequence matches the given IP address,
-
-
-
-Hadmut Danisch                Experimental                     [Page 12]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   authorization is granted or denied, depending on the negation flag.
-
-   The entry is prepended with the tag "IPv4" or "IPv6". The colon is
-   followed with an IPv4 or IPv6 address in standard notation,
-   optionally followed by a slash and a mask length. If the negation
-   flag is set, then the given address range is excluded.  Examples:
-
-   danisch.de   IN RMX ipv4:213.133.101.23 ipv6:fe00::0
-                IN RMX ipv4:10.0.0.0/8     ipv6:fec0::0/16
-                IN RMX !ipv4:1.2.3.4
-
-   (Please note that it does not make much sense to use
-   RFC1918-Addresses in RMX records, this is just to give a syntax
-   example.)
-
-
-5.4.  DNS Hostname
-
-   This entry type simply contains a regular DNS name, which is to be
-   resolved as a host name (fetch the A record or IPv6 equivalent). If
-   the given IP address matches the result, authorization is granted
-   or denied, depending on the negation flag.  It is still to be
-   defined how to treat unresolvable entries.
-
-   The entry is prepended with the tag "host", followed by a colon and
-   the hostname. Examples:
-
-   danisch.de  IN RMX host:relay.provider.de
-               IN RMX !host:badmachine.domain.de apl:relays.domain.de
-
-5.4.1.  Road warriors and DynDNS entries
-
-   Several people argued against RMX that it would break their
-   existing installation which delivers e-mail from dynamically
-   assigned IP addresses, because their IP providers didn't assign a
-   static address, or because they are a road warrior, plugging their
-   notebook in any hotel room on the world.
-
-   RMX provides a simple solution. If such a machine has a dynamically
-   updated DNS entry (e.g. DynDNS), all it takes is an RMX entry of
-   the hostname type pointing to this dynamic DNS entry.
-
-   The cleaner solution would be to deliver mail the same way as it is
-   received: If downloaded by POP from a central relay with a static
-   address, where the MX points to, then it would be a good idea to
-   deliver e-mail the same way in reverse direction. Unfortunately,
-   plain POP does not support uploading yet.
-
-
-
-
-Hadmut Danisch                Experimental                     [Page 13]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-5.5.  APL Reference
-
-   This entry type simply contains a regular DNS name, which is to be
-   resolved as an APL record index  (fetch the APL record).  If the
-   given IP address positively  matches the APL, authorization is
-   granted. Details of the semantic (espially when the negation bit is
-   set) are still to be defined.  It is still to be defined how to
-   treat unresolvable entries.
-
-   The entry is prepended with the tag "host", followed by a colon and
-   the hostname. Example:
-
-   danisch.de     IN RMX apl:relays.rackland.de
-
-5.6.  Domain Member
-
-   In many cases it is desirable to cover all hosts of a given domain
-   with an RMX record without the need to duplicate the list of these
-   hosts. This entry type does it (thanks to Eric A. Hall for pointing
-   out this entry type).  It contains a regular DNS name.
-
-   If this entry type is given, a reverse DNS query for the IP address
-   of the sending MTA is performed to find its official fully
-   qualified domain name. To prevent spoofing, this domain name is
-   accepted only if a subsequent address query to the given domain
-   name points to exactly the IP address of the sending MTA (the usual
-   procedure to verify PTR records).
-
-   The entry matches if the fully qualified domain name of the sending
-   MTA ends in the given domain. The negation flag works as usual.
-
-   The tag for this entry type is "domain". After the colon the domain
-   name is given, but might be empty, thus pointing to itself.
-   Example:
-
-      somedomain.org  IN RMX domain:somedomain.org domain:provider.com
-
-   would authorize all machines which's hostname can be verified
-   through an PTR and A query, and which ends in "somedomain.org" or
-   "provider.com".
-
-   With such an entry, large companies with different networks can
-   easily be covered with just a single and simple RMX entry.
-   Obviously, it requires proper PTR records.
-
-   As a special shortcut, the DNS name may be empty. In this case the
-   domain name of the zone itself is taken. Thus, with a very simple
-   entry of the type
-
-
-
-Hadmut Danisch                Experimental                     [Page 14]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-     somecompany.com  IN RMX domain:
-
-   a company could authorize all machines which's IP addresses map to
-   DNS names end in somecompany.com, which applies in the majority of
-   companies.
-
-
-
-
-5.7.  Full Address Query
-
-   As described above, RMX records will in most cases apply to the
-   domain part of the sender address. In special cases it might be
-   desirable to query the RMX record for a particular address.  An RMX
-   entry of the Full Address Query type may occur in a domain RMX
-   record only. It signals that the RMX record for the full address is
-   to be fetched and processed.
-
-   This entry type does not take arguments. The negation flag is not
-   supported. The tag is "full".
-
-   If such a full address query is to be performed, the mail address
-   must be mapped to a valid and non-ambiguos DNS name. This mapping
-   is still to be defined. It is not sufficient to simply replace the
-   @ with a dot, because of case sensitivity, character sets, etc. The
-   e-mail addresses
-
-      john.doe@example.org
-      John.Doe@example.org
-      john@doe.example.org
-
-   must all be mapped to different DNS entries. This entry type might
-   vanish in future versions of the draft, depending on the discussion
-   about whether to query the domain name part only or the full
-   address.
-
-5.8.  DNS mapped authorization
-
-   As I learned from comments to prior versions of the draft and from
-   alternative proposals, many users wish to have a DNS mapped
-   authorization table, i. e. the client queries a DNS entry of the
-   form a.b.c.d.domain, where a.b.c.d is the sender's IP address.
-   Since people wish to have this, RMX will now include such a mapping
-   entry. The entry has a parameter giving the DNS domain name where
-   to look at. If the parameter is empty, then the same domain is
-   taken as for the RMX lookup.
-
-   As this is currently under construction and discussion in an IETF
-
-
-
-Hadmut Danisch                Experimental                     [Page 15]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   group, details will be published in future versions of this draft.
-
-5.9.  RMX reference
-
-   This entry type has no parameters. It means that all those machines
-   are authorized, which are pointed to by an MX record.
-
-6.  Optional and experimental entry types
-
-   The following subsections roughly describe further entry types
-   which might not be supported by all implementations and might not
-   be allowed in all legislations. These methods might vanish in
-   future versions of the draft and are just considerations about what
-   to include in RMX and what to not include. The main purpose of this
-   section is to start discussion about such entry types.
-
-   The disadvantage of the following methods is that they violate the
-   basic idea of RMX, i. e. to be simple, robust, easy to implement
-   and easy to administer. I personally do not believe that it is a
-   good idea or even feasible to implement cryptography for a world
-   wide e-mail transfer network. Keep in mind that cryptographic keys
-   can be copied.  If only <0.1% of cryptographic keys were revealed,
-   this completely compromises and spoils RMX. Cryptography is simply
-   the wrong tool for the problem RMX is intended to solve. I
-   nevertheless like to discuss these methods.
-
-6.1.  TLS fingerprint
-
-   The sender is considered to be authorized if the message was
-   transmitted through SMTP and TLS, and the sender used a certificate
-   matching the fingerprint given in the RMX record.
-
-6.2.  TLS and LDAP
-
-   This means that the receiver should perform an LDAP query for the
-   sender address (through the LDAP SRV record or given in the RMX
-   record), fetch the X.509 certificate for the sender. The sender is
-   considered to be authorized when the message was transmitted
-   through SMTP and TLS using this certificate.
-
-6.3.  PGP or S/MIME signature
-
-   It would be possible to accept a message only if it was signed with
-   PGP or S/MIME with a key which's fingerprint is given in the RMX
-   record or to be fetched from LDAP or any PGP database.  This is
-   just for discussion, since it violates the idea of RMX to focus on
-   the transport, not on the content. It would also allow replay
-   attacks and not cover the envelope sender address or message
-
-
-
-Hadmut Danisch                Experimental                     [Page 16]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   header.
-
-6.4.  Transparent Challenge/Response
-
-   It would also be possible to implement a challenge-response
-   mechanism without modifying the syntax of SMTP. For example, the
-   receiving MTA could issue a challenge with it's very first greeting
-   message, the sending MTA could hide the response in the HELO
-   parameter and when the receiving MTA later learns the sender
-   envelope address, it could verify the response based on
-   informations in the RMX record.
-
-6.5.  SASL Challenge/Response
-
-   Modern SMTP implementations already include a SASL mechanisms,
-   which easily allows to plugin new authentication mechanisms. While
-   common SASL mechanisms require to use a previously shared password,
-   a new mechanism could perform a challenge response authentication
-   as a SASL method.
-
-
-
-
-
-
-7.  Encoding
-
-7.1.  Alternative encoding as TXT records
-
-   The main objection against the prior versions of this draft was
-   that it requires a new RR entry type and upgrading all DNS servers.
-
-   Therefore and alternative encoding is proposed. Instead of using a
-   new RR type, the TXT record type is used to contain the RMX record.
-   The records would simply look as described in the entry type
-   chapters above, e.g.
-
-      _rmx.danisch.de.   IN TXT "apl:relays.rackland.de"
-
-   To allow smooth introduction of RMX without the need to immediately
-   upgrade all DNS servers, all clients (which have to be newly
-   installed anyway) MUST support both the TXT and the RMX records. A
-   client has to perform an ANY or a TXT and a RMX query. Servers/zone
-   tables may currently use TXT entries but SHOULD use RMX entries in
-   future.
-
-7.2.  RMX Records
-
-
-
-
-Hadmut Danisch                Experimental                     [Page 17]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-7.2.1.  Overall structure
-
-   Each entry starts with an octet containting the entry type and the
-   negation flag:
-
-      +---+---+---+---+---+---+---+---+------
-      | N |    Entry Type Code        | Parameters...
-      +---+---+---+---+---+---+---+---+------
-
-      N           If this bit (MSB) is set, an IP address
-                  matching this entry is not authorized,
-                  but explicitely rejected. See entry
-                  type descriptions for details.
-
-      Entry Type  A 7bit number simply determining the entry
-                  type.
-
-
-   Currently, entries do not have an explicit length field, the entry
-   length is determined implicitely by the entry type. Applications
-   are required to abort if an unknown entry type is found, instead of
-   skipping unknown entries.
-
-7.2.2.  Record encoding
-
-   A RMX record is simply a concatenation of RMX entries.
-
-7.2.3.  Encoding of IPv4 and IPv6 address ranges
-
-   After the entry type tag as described above, one octet follows
-   giving the length L of the bit sequence. Then a sequence of exactly
-   as many octets follows as needed to carry L bits of information (=
-   trunc((L+7)/8) ).
-
-      +---+---+---+---+---+---+---+---+
-      | N | Entry Type Code  (1 or 2) |
-      +---+---+---+---+---+---+---+---+
-      |         Length Field L        |
-      +---+---+---+---+---+---+---+---+
-      |           Bit Field           |
-      /        ((L+7)/8) Octets       /
-      +---+---+---+---+---+---+---+---+
-
-
-7.2.4.  Encoding of DNS
-
-   After the entry type tag immediately follows a DNS encoded and
-   compressed [3] domain name.
-
-
-
-Hadmut Danisch                Experimental                     [Page 18]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-      +---+---+---+---+---+---+---+---+
-      | N |  Entry Type Code  (3..5)  |
-      +---+---+---+---+---+---+---+---+
-      |         Length Field L        |
-      +---+---+---+---+---+---+---+---+
-      |  Encoded DNS                  |
-      /  Name as described in RFC1035 /
-      +---+---+---+---+---+---+---+---+
-
-   In contrast to earlier versions of this draft, the DNS name cannot
-   be compressed, since this would cause decompression errors when a
-   DNS server is part of the query chain which does not know this
-   particular RR type.
-
-7.2.5.  Encoding of unused and full query
-
-   These entries do not contain parameters and does not allow the
-   negation flag.  So the encoding is quite simple:
-
-      +---+---+---+---+---+---+---+---+
-      | 0 |  Entry Type Code  (6 or 7)|
-      +---+---+---+---+---+---+---+---+
-
-
-
-7.2.6.  Additional Records
-
-   In order to avoid the need of a second query to resolve the given
-   host name, a DNS server should enclose the A record for that domain
-   name in the additional section of the additional section of the DNS
-   reply, if the server happens to be authoritative.
-
-   In order to avoid the need of a second query to resolve the given
-   host name, a DNS server should enclose the APL record for that
-   domain name in the additional section of the additional section of
-   the DNS reply, if the server happens to be authoritative.
-
-
-
-8.  Message Headers
-
-   An RMX query must be followed by any kind of action depending on
-   the RMX result. One action might be to reject the message.  Another
-   action might be to add a header line to the message body, thus
-   allowing MUAs and delivery programs to filter or sort messages.
-
-   In future, the RMX result might be melted into the Received: header
-   line.
-
-
-
-Hadmut Danisch                Experimental                     [Page 19]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   The details of such entries are to be discussed. As a proposal the
-   following form is suggested:
-
-     X-RMX: RESULT addr ADDRESS by HOST on DATE mechanism MECHANISM
-
-   where
-
-   RESULT is one of "Granted", "Denied", "NotInRMX", "NoRMX",
-   "TempFail", "BadData", "Trusted".
-
-   ADDRESS is the IP address of the sending machine
-
-   HOST is the name of the machine performing the RMX query.
-
-   DATE is the date of the query.
-
-   MECHANISM is the RMX method used to authorize the sender.
-
-
-
-9.  SMTP error messages
-
-   If a message is rejected because of RMX records, an error message
-   should be issued which explains the details.  It is to be discussed
-   whether new SMTP error codes are to be defined.
-
-
-10.  Message relaying and forwarding
-
-10.1.  Problem description
-
-   Message forwarding and relaying means that an MTA which received an
-   e-mail by SMTP does not deliver it locally, but resends the message
-   - usually unchanged except for an additional Received header line
-   and maybe the recipient's address rewritten - to the next SMTP MTA.
-   Message forwarding is an essential functionality of e-mail
-   transport services, for example:
-
-     - Message transport from outer MX relay to the intranet
-     - Message forwarding and Cc-ing by .forward or .procmail-alike
-       mechanisms
-     - Mailing list processing
-     - Message reception by mail relays with low MX priority,
-       usually provided by third parties as a stand-by service
-       in case of relay failure or maintenance
-     - "Forwarding" and "Bouncing" as a MUA functionality
-
-   In all these cases a message is sent by SMTP from a host which is
-
-
-
-Hadmut Danisch                Experimental                     [Page 20]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   not covered by the original sender domain's RMX records.  While the
-   RMX records would forbid accepting this message, it still must be
-   accepted. The following subsections explain how to cope with
-   relaying.
-
-10.2.  Trusted relaying/forwarding
-
-   In some cases the receiving MTA trusts the sending MTA to not fake
-   messages and to already have checked the RMX records at message
-   reception. As a typical example, a company might have an outer mail
-   relay which receives messages from the Internet and checks the RMX
-   records. This relay then forwards the messages to the different
-   department's mail servers. It does not make sense for these
-   department mail servers to check the RMX record, since the RMX
-   records have already been checked and - since the message was
-   relayed by the outer relay - always would deny the message. In this
-   case there is a trust relationship between the department relays
-   and the outer relay.  So RMX checking is turned off for trusted
-   relays. In this example, the department relays would not check
-   messages from the outer relay (but for intranet security, they
-   could still check RMX records of the other departments sub-domains
-   to avoid internal forgery between departments).
-
-   Another common example are the low-priority MX relays, which
-   receive and cache e-mails when the high-priority relays are down.
-   In this case, the high-priority relay would trust the low-priority
-   relay to have verified the sender authorization and would not
-   perform another RMX verification (which would obviously fail).
-
-   When a relay forwards a message to a trusting machine, the envelope
-   sender address should remain unchanged.
-
-10.3.  Untrusted relaying/forwarding
-
-   If the receiving MTA does not trust the forwarding MTA, then there
-   is no chance to leave the sender envelope address unchanged. At a
-   first glance this might appear impracticable, but this is
-   absolutely necessary. If an untrusted MTA could claim to have
-   forwarded a message from a foreign sender address, it could have
-   forged the message as well. Spammers and forgers would just have to
-   act as such a relay.
-
-   Therefore, it is required that, when performing untrusted
-   forwarding, the envelope sender address has to be replaced by the
-   sender address of someone responsible for the relaying mechanism,
-   e.g. the owner of the mailing list or the mail address of the user
-   who's .forward caused the transmission. It is important to stress
-   that untrusted relaying/forwarding means taking over responsibility
-
-
-
-Hadmut Danisch                Experimental                     [Page 21]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   for the message.  It is the idea of RMX records to tie
-   responsibility to message transmission. Untrusted relaying without
-   replacing the sender address would mean to transmit without taking
-   responsibility.
-
-   The disadvantage is that the original sender address is lost.
-   Therefore, whenever a sender address replacement happens, the
-   Received-Line must contain the old address. Many of today's MTAs
-   already insert the envelope recipient address, but not the sender
-   address into the Received header line. It seems reasonable to
-   require every Received line to include both the sender and
-   recipient address of the incoming SMTP connection.
-
-
-11.  Security Considerations
-
-11.1.  Draft specific considerations
-
-11.1.1.  Authentication strength
-
-   It is important to stress, that the suggested method does not
-   provide high level security and does not completely prevent forged
-   e-mails or spam under any circumstances. It is a robust, but not
-   highly reliable and completely secure security mechanism. Keep in
-   mind that it is based on DNS, and DNS is not secure today.
-   Authorization is based on the IP address. The very same machine
-   with the very same IP address could be authorized to send e-mail
-   with a given sender address and sending spam at the same time.
-   Maybe because several users are logged in. Or because several
-   customers use the same relay of the same ISP, where one customer
-   could use the sender address of a different customer. It is up to
-   the ISP to prevent this or not. Machines can still be hijacked.
-   Spammers are also domain owners. They can simply use their own
-   domain and authorize themselves. You will always find people on the
-   world who do not care about security and open their relays and RMX
-   records for others to abuse them.  RMX is to be considered as a
-   very cheap and simple light weight mechanism, which can
-   nevertheless provide a significant improvement in mail security
-   against a certain class of attacks, until a successor of SMTP has
-   been defined and commonly accepted.
-
-11.1.2.  Where Authentication and Authorization end
-
-   Previous versions of RMX records did not cover the local part of
-   the e-mail address, i.e. what's on the left side of the @ sign.
-   This is still to be discussed. Authentication and authorization are
-   limited to the sending MTA's IP address. The authentication is
-   limited to the TCP functionality, which is sufficient for light
-
-
-
-Hadmut Danisch                Experimental                     [Page 22]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   weight authentication. The RMX records authorize the IP address of
-   the sending host only, not the particular sender of the message. So
-   if a machine is authorized to use sender addresses of more than a
-   single domain, the authentication scheme does not prevent that any
-   user on this machine can send with any of these domains. RMX is not
-   a substitute for the host security of the involved machines.
-
-   The proposed authentication scheme can be seen as a "half way
-   authentication": It does not track back an e-mail to the effective
-   sender. It tracks only half of the way, i. e. it tracks back to the
-   domain and it's DNS administrators who authorized that particular
-   sender IP address to use it for sending e-mail. How the party
-   responsible for that domain performs user authentication, whom it
-   grants access to, how it helds people responsible for abuse, is
-   completely left as the private business of those who are in charge
-   of that domain. So this draft does not interfere with the domain's
-   individual security policy or any legislation about such policies.
-   On the other hand, the proposed authentication scheme does not give
-   any statement about the nature and quality of the domain's security
-   policy. This is an essential feature of the proposal: E-mail
-   authentication must be deployed world wide, otherwise it won't do
-   the job. Any security scheme interfering with the local
-   legislations or the domain's security policy will not be accepted
-   and can't effectively deployed. Therefore, the security policy must
-   remain the domain's private business, no matter how lousy the
-   policy might be.
-
-   In order to achieve this and to make use of the only existing world
-   wide Internet directory scheme (DNS), the approach of this proposal
-   is to just ignore the local part of the sender address (i.e. what's
-   left of the @ part) and limit view to the domain part. After all,
-   that's what we do anyway when delivering to a given address with
-   SMTP.
-
-11.1.3.  Vulnerability of DNS
-
-   DNS is an essential part of the proposed authentication scheme,
-   since it requires any directory service, and DNS is currently the
-   only one available. Unfortunately, DNS is vulnerable and can be
-   spoofed and poisoned. This flaw is commonly known and weakens many
-   network services, but for reasons beyond that draft DNS has not
-   been significantly improved yet. After the first version of this
-   draft, I received several comments who asked me not to use DNS
-   because of its lack of security. I took this into consideration,
-   but came to the conclusion that this is unfeasible: Any
-   authentication scheme linked to some kind of symbolic identity (in
-   this case the domain name) needs some kind of infrastructure and
-   trusted assignment. There are basically two ways to do it: Do it
-
-
-
-Hadmut Danisch                Experimental                     [Page 23]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   yourself and trust nobody else, or let someone else do it. There
-   are methods to do it the former way, e.g. to give someone some kind
-   of authentication information after a first successful e-mail
-   exchange, e.g. some kind of cookie or special e-mail address. This
-   is certainly interesting and powerful, but it does not solve the
-   problem on a world wide scale and is far to complicated and error
-   prone for the average user, i. e. 99% of the users.
-
-   The latter method to let someone else do the symbolic name
-   assignment and create the authentication framework is well known.
-   It context of public key cryptography, this is called a Public Key
-   Infrastructure (PKI). On of the best known facts about PKIs is
-   that, until now, we don't have any covering a significant part of
-   the Internet. And we won't have any in near future. The complexity
-   is far too high, it is too expensive, and it involves cooperation
-   of every single user, which is simply unrealistic and extremely
-   error prone. So what do we have we can use? All we have is the DNS
-   and the Whois database. And we have countries who don't allow
-   cryptography. So the proposal was designed to use DNS without
-   cryptography. It does not avoid DNS because of its vulnerability,
-   it asks for a better DNS, but accepts the DNS as it is for the
-   moment. Currently there are two main threats caused by the DNS
-   weakness:
-
-      - A spammer/forger could spoof DNS in order to gain false
-        authorization to send fake e-mails.
-
-      - An attacker could spoof DNS in order to block delivery from
-        authorized machines, i. e. perform a Denial of Service attack.
-
-   The first one is rather unrealistic, because it would require an
-   average spammer to poison a significant part of the DNS servers of
-   its victims. A spammer sending messages to one million receipients
-   would need to poison at least 1-10% which is 10,000 to 100,000
-   receipient's DNS servers. This should be unfeasible in most cases.
-
-   In contrast, the second threat is a severe one. If an attacker
-   wanted to block messages from one company to another, he just needs
-   to poison the recipients DNS server with a wrong RMX record in
-   order to make the recipient's SMTP machine reject all messages. And
-   this is feasible since the attacker needs to poison only a single
-   DNS server. But does this make SMTP more vulnerable? No. Because
-   the attacker can already do even more without RMX. By poisoning the
-   sender's DNS server with wrong MX records, the attacker can also
-   block message delivery or even redirect the messages to the
-   attacker's machine, thus preventing any delivery error messages and
-   furthermore getting access to the messages.
-
-
-
-
-Hadmut Danisch                Experimental                     [Page 24]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   As a consequence, e-mail delivery by SMTP requires a better DNS
-   anyway. The requirements are not significantly expanded by RMX.
-
-11.1.4.  Sneaking RMX attack?
-
-   While writing a test implementation, a certain kind of attack came
-   into my mind. I'm still not sure, whether this attack is possible
-   on any DNS server, but I believe it should be mentioned:
-
-   Imagine an unauthorized sender is sending a forged mail (e.g.
-   spam).  At connection time, before querying the RMX record, the
-   receiving MTA usually performs a PTR query for the IP address of
-   the sending MTA. If the sender has control over the authoritative
-   name server for that particular IP address, the sender could give a
-   normal PTR answer, but could append a wrong RMX, APL, or A record
-   in the additional section of the query. A subsequent RMX query
-   could receive wrong DNS data if the DNS server used by the
-   receiving MTA accepted those forged records.
-
-11.1.5.  Open SMTP relays
-
-   Open SMTP relays (i.e. machines who accept any e-mail message from
-   anyone and deliver to the world) abused by spammers are a one of
-   the main problems of spam defense and sender backtracking. In most
-   cases this problem just vanishes because foreign open relay
-   machines will not be covered by the RMX records of the forged
-   sender address. But there are two special cases:
-
-   If the spammer knows about a domain which authorizes this
-   particular machine, that domain can be used for forgery. But in
-   this case, the IP address of the relay machine and the RMX records
-   of the domain track back to the persons responsible. Both can be
-   demanded to fix the relay or remove the RMX record for this
-   machine. An open relay is a security flaw like leaving the machine
-   open for everybody to login and send random mails from inside. Once
-   the administrative persons refuse to solve the problem, they can be
-   identified as spammers and held responsible.
-
-   The second special case is when a domain authorizes all IP
-   addresses by having the network 0.0.0.0/0 in the RMX/APL record. In
-   this case, open relays don't make things worse. It's up to the
-   recipient's MTA to reject mails from domains with loose security
-   policies.
-
-11.1.6.  Unforged Spam
-
-   This proposal does not prevent spam (which is, by the way, not yet
-   exactly defined), it prevents forgery. Since spam is against law
-
-
-
-Hadmut Danisch                Experimental                     [Page 25]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   and violates the recipients rights, spam depends on untracability
-   of the sender. In practice the sender forges the sender address
-   (other cases see below). This proposal is designed to detect such
-   forgeries.
-
-   However, the RMX approach is rendered ineffective, if the sender
-   doesn't forge. If the sender uses just a normal address of it's own
-   domain, this is just a plain, normal e-mail, which needs to be let
-   through. Since it is up to the human's taste whether this is spam
-   or not, there's no technical way to reliably identify this as spam.
-   But since the sender domain is known, this domain can be
-   blacklisted or legal steps can be gone into.
-
-11.1.7.  Reliability of Whois Entries
-
-   Once the RMX infrastructure gets deployed, what's the security
-   gain?  It allows to determine the domain which's DNS zone
-   authorized the sending machine. What's that good for? There are
-   some immediate uses of the domain name, e.g. in black- and
-   whitelisting. But in most cases this is just the starting point of
-   further investigations, either performed automatically before
-   message acceptance, or manually after spam has been received and
-   complainted about.
-
-   The next step after determining the domain is determining the
-   people responsible for this domain. This can sometimes be achieved
-   by querying the Whois databases. Unfortunately, many whois entries
-   are useless because they are incomplete, wrong, obsolete, or in
-   uncommon languages. Furthermore, there are several formats of
-   address informations which make it difficult to automatically
-   extract the address. Sometimes the whois entry identifies the
-   provider and not the owner of the domain. Whois servers are not
-   built for high availability and sometimes unreachable.
-
-   Therefore, a mandatory standard is required about the contents and
-   the format of whois entries, and the availability of the servers.
-   After receiving the MAIL FROM SMTP command with the sender envelope
-   address, the receiving MTA could check the RMX record and Whois
-   entry. If it doesn't point to a real human, the message could be
-   rejected and an error message like "Ask your provider to fix your
-   Whois entry" could be issued. Obviously, domain providers must be
-   held responsible for wrong entries. It might still be acceptable to
-   allow anonymous domains, i. e. domains which don't point to a
-   responsible human. But it is the receivers choice to accept e-mails
-   from such domains or not.
-
-11.1.8.  Hazards for Freedom of Speech
-
-
-
-
-Hadmut Danisch                Experimental                     [Page 26]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   Currently, some governments try to enforce limitations of internet
-   traffic in order to cut unwanted content providers from the
-   network. Some of these governments try to hide a whole country
-   behind firewalls, others try to force Internet providers to poison
-   DNS servers with wrong A records for web servers, e.g. one county
-   administration in Germany tries to do so. If message reception
-   depends on DNS entries, the same governments will try to block not
-   only HTTP, but SMTP also.
-
-   However, since most MTAs already reject messages from unresolvable
-   domain names this is not a new threat.
-
-11.2.  General Considerations about spam defense
-
-   After discussing security requirements of the proposal, now the
-   security advantages of the RMX approach over content based filters
-   will be explained. Basically, there are three kinds of content
-   filters:
-
-      - Those who upload the message or some digest to an external
-        third party and ask "Is this spam"?
-
-      - Those who download a set of patterns and rules from a third
-        party and apply this set to incoming messages in order to
-        determine whether it is spam.
-
-      - Those who are independent and don't contact any third party,
-        but try to learn themselves what is spam and what isn't.
-
-
-   The message filters provided by some e-mail service providers are
-   usually not a kind of their own, but a combination of the first two
-   kinds.
-
-11.2.1.  Action vs. reaction
-
-   Content filters suffer from a fundamental design problem: They are
-   late. They need to see some content of the same kind before in
-   order to learn and to block further distribution.
-
-   This works for viruses and worms, which redistribute. This doesn't
-   work for spam, since spam is usually not redistributed after the
-   first delivery. When the filters have learned or downloaded new
-   pattern sets, it's too late.
-
-   This proposal does not have this problem.
-
-11.2.2.  Content based Denial of Service attacks
-
-
-
-Hadmut Danisch                Experimental                     [Page 27]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   All three kinds of content filters, but especially the second and
-   the third kind are vulnerable to content based Denial of Service
-   attacks.
-
-   If some kind of third party (e.g. non-democratic government,
-   intellectual property warriors, religious groups, military, secret
-   services, patriots, public relation agents, etc.) wants certain
-   contents not to be distributed, they could either poison the
-   pattern/rule databases or feed wrong sets to particular receivers.
-
-   Such pattern/rule sets are the perfect tool for censoring e-mail
-   traffic and denial of service attacks by governments and other
-   parties, and a similar threat are virus filters. E. g. the content
-   industry could demand to teach all virus and spam filters to delete
-   all e-mails containing the URL of an MP3 web server outside the
-   legislations. Software manufacturers could try to block all e-mails
-   containing software license keys, thus trying to make unallowed
-   distribution more difficult. Governments could try to block
-   distribution of unwanted informations.
-
-   This proposal does not have this problem.
-
-
-12.  Privacy Considerations
-
-   (It was proposed on the 56th IETF meeting to have a privacy section
-   in drafts and RFCs.)
-
-12.1.  Draft specific considerations
-
-12.1.1.  No content leaking
-
-   Since the RMX approach doesn't touch the contents of a message in
-   any way, there is obviously no way of leaking out any information
-   about the content of the message. RMX is based solely on the
-   envelope recipient address. However, methods to fix problems not
-   covered by RMX might allow content leaking, e.g. if the acceptance
-   of a message with an empty sender address requires the reference to
-   the message id of an e-mail recently sent, this allows an attacker
-   to verify whether a certain message was delivered from there.
-
-12.1.2.  Message reception and sender domain
-
-   Message delivery triggers RMX and APL requests by the recipient.
-   Thus, the admin of the DNS server or an eavesdropper could learn
-   that the given machine has just received a message with a sender
-   from this address, even if the SMTP traffic itself had been
-   encrypted.
-
-
-
-Hadmut Danisch                Experimental                     [Page 28]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   However, most of today's MTAs do query the MX and A records of the
-   domain after the MAIL FROM command, so this is not a real new
-   threat.
-
-12.1.3.  Network structure
-
-   Since RMX and its associated APL records provide a complete list of
-   all IP addresses of hosts authorized to send messages from this
-   address, they do reveal informations about the network structure
-   and maybe the lifestyle of the domain owner, since a growing number
-   of domains are owned by single persons or families. E.g. the RMX
-   records could reveal where someone has his job or spends his time
-   at weekends.
-
-   If such informations are to be kept secret, it is the user's job to
-   not sent e-mails from there and to relay them from non-compromising
-   IP addresses.
-
-12.1.4.  Owner information distribution
-
-   As described above, RMX depends partly on the reliability of the
-   whois database entries. It does not make anonymous domains
-   impossible, but it requires to keep the database entries "true", i.
-   e. if a whois entry does not contain informations about the
-   responsible person, this must be unambigously labeled as anonymous.
-   It must not contain fake names and addresses to pretend a non-
-   existing person. However, since most Internet users on the world
-   feel extremely annoyed by spam, they will urge their MTA admin to
-   reject messages from anonymous domains. The domain owner will have
-   the choice to either remain anonymous but be not able to send e-
-   mail to everyone in the world, or to be able but to reveal his
-   identity to everyone on the world.
-
-   It would be possible to provide whois-like services only to
-   recipients of recent messages, but this would make things too
-   complicated to be commonly adopted.
-
-12.2.  General Considerations about spam defense
-
-12.2.1.  Content leaking of content filters
-
-   As described above in the Security chapter, there are spam filters
-   which inherently allow leakage of the message body. Those filters
-   upload either the message body, or in most cases just some kind of
-   checksum to a third party, which replies whether this is to be seen
-   as spam or not. The idea is to keep a databases of all digests of
-   all messages.  If a message is sent more often than some threshold,
-   it is to be considered as a mass mail and therefore tagged as spam.
-
-
-
-Hadmut Danisch                Experimental                     [Page 29]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   While the digest itself does not reveal the content of the message,
-   it perfectly reveals where a particular message has been delivered
-   to. If a government finds just a single unwanted message, if a
-   software manufacturer finds a single message with a stolen product
-   license key, if someone finds a message with unpatriotic content,
-   it takes just a single database lookup to get a list of all people
-   who received this particular message. Content filters with digest
-   upload are the perfect "Big Brother".
-
-12.2.2.  Black- and Whitelists
-
-   Some proposals against spam are based on a central database of
-   white- or blacklisted IP addresses, Sender names, Message IDs or
-   whatever. Again, there is a central database which learns who has
-   received which e-mail or from which sender with every query. This
-   allows tracking relations between persons, which is also a breach
-   of privacy.
-
-
-
-13.  Deployment Considerations
-
-13.1.  Compatibility
-
-13.1.1.  Compatibility with old mail receivers
-
-   Since the suggested extension doesn't change the SMTP protocol at
-   all, it is fully compatible with old mail receivers. They simply
-   don't ask for the RMX records and don't perform the check.
-
-13.1.2.  Compatibility with old mail senders
-
-   Since the SMTP protocol is unchanged and the SMTP sender is not
-   involved in the check, the method is fully compatible with old mail
-   senders.
-
-13.1.3.  Compatibility with old DNS clients
-
-   Since the RMX is a new RR, the existing DNS protocol and zone
-   informations remain completely untouched.
-
-   If RMX is provided as a TXT record instead, it must be ensured that
-   no other software is misinterpreting this entry.
-
-13.1.4.  Compatibility with old DNS servers
-
-   Full compatibility: If the server does not support RMX records, RMX
-   in TXT records can be used.
-
-
-
-Hadmut Danisch                Experimental                     [Page 30]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-13.2.  Enforcement policy
-
-   Obviously, for reasons of backward compatibility and smooth
-   introduction of this scheme, RMX records can't be required
-   immediately. Domains without RMX records must temporarily be
-   treated the same way as they are treated right now, i.e. e-mail
-   must be accepted from anywhere. But once the scheme becomes
-   sufficiently widespread, mail relays can start to refuse e-mails
-   with sender addresses from domains without RMX records, thus
-   forcing the owner of the domain to include a statement of
-   authorization into the domain's zone table.  Domain owners will
-   still be free to have an RMX record with a network and mask
-   0.0.0.0/0, i.e. to allow e-mails with that domain from everywhere.
-   On the other hand, mail receivers will be free to refuse mails from
-   domains without RMX records or RMX records which are too loose.
-   Advanced MTAs might have a configuration option to set the maximum
-   number of IP addresses authorized to use a domain. E-mails from a
-   domain, which's RMX records exceed this limit, would be rejected.
-   For example, a relay could reject e-mails from domains which
-   authorize more than 8 IP addresses. That allows to accept e-mails
-   only from domains with a reasonable security policy.
-
-
-
-14.  General considerations about fighting spam
-
-   Is there a concise technical solution against spam? Yes.
-
-   Will it be deployed? Certainly not.
-
-   Why not? Because of the strong non-technical interests of several
-   parties against a solution to the problem, as described below.
-   Since these are non-technical reasons, they might be beyond the
-   scope of such a draft. But since they are the main problems that
-   prevent fighting spam, it is unavoidable to address them. This
-   chapter exists temporarily only and should support the discussion
-   of solutions. It is not supposed to be included in a later RFC.
-
-14.1.  The economical problem
-
-   As has been recently illustrated in the initial session of the
-   IRTF's Anti Spam Research Group (ASRG) on the 56th IETF meeting,
-   sending spam is a business with significant revenues.
-
-   But a much bigger business is selling Anti-Spam software. This is a
-   billion dollar market, and it is rapidly growing. Any simple and
-   effective solution against spam would defeat revenues and drive
-   several companies into bankrupt, would make consultants jobless.
-
-
-
-Hadmut Danisch                Experimental                     [Page 31]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   Therefore, spam is essential for the Anti-Spam business. If there
-   is no spam, then no Anti-Spam software can be sold, similar to the
-   Anti-Virus business. There are extremely strong efforts to keep
-   this market growing. Viruses, Worms, and now spam are just perfect
-   to keep this market alive: It is not sufficient to just buy a
-   software. Databases need to be updated continuously, thus making
-   the cash flow continuously. Have a single, simple, and permanent
-   solution to the problem and - boom - this billion dollar market is
-   dead.
-
-   That's one of the reasons why people are expected to live with
-   spam. They have to live with it to make them buy Anti-Spam
-   software.  Content filters are perfect products to keep this market
-   alive.
-
-14.2.  The POP problem
-
-   Another problem is the history of mail delivery. Once upon a time,
-   there used to be very few SMTP relays which handled the e-mail
-   traffic of all the world, and everybody was happy with that. Then
-   odd things like Personal Computers, which are sometimes switched
-   off, portable computers, dynamicly assigned IP addresses, IP access
-   from hotel rooms, etc. was invented, and people became unhappy,
-   because SMTP does not support delivery to such machines. To make
-   them happy again, the Post Office Protocol[4] was invented, which
-   turned the last part of message delivery from SMTP's push style
-   into a pull style, thus making virtually every computer on the
-   world with any random IP address a potential receiver of mails for
-   random domains. Unfortunately, only receiving e-mail was covered,
-   but sending e-mail was left to SMTP.
-
-   The result is that today we have only very few SMTP relays pointed
-   to by MX records, but an extreme number of hosts sending e-mail
-   with SMTP from any IP address with sender addresses from any
-   domain. Mail delivery has become very asymmetric. Insecurity,
-   especially forgeability, has become an essential part of mail
-   transport.
-
-   That problem could easily be fixed: Use protocols which allow
-   uploading of messages to be delivered. If a host doesn't receive
-   messages by SMTP, it shouldn't deliver by SMTP.  Mail delivery
-   should go the same way back that incoming mail went in.  This is
-   not a limitation to those people on the road who plug their
-   portable computer in any hotel room's phone plug and use any
-   provider. If there is a POP server granting download access from
-   anywhere, then the same server should be ready to accept uploading
-   of outgoing messages.
-
-
-
-
-Hadmut Danisch                Experimental                     [Page 32]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   But as I saw from the comments on the first version of this draft,
-   people religiously insist on sending e-mail with their domain from
-   any computer with any IP address in the world, e.g. when visiting a
-   friend using her computer. It appears to be impossible to convince
-   people that stopping mail forgery requires every one of them to
-   give up forging.
-
-14.3.  The network structure problem
-
-   A subsequent problem is that many organisations failed to implement
-   a proper mail delivery structure and heavily based their network on
-   this asymmetry. I received harsh comments from Universities who
-   were unable to give their network a good structure. While they do
-   have a central mail relay for incoming mail to the universities
-   domain, they developed a structure where every member of the
-   University randomly sends e-mails with that University's domain as
-   a sender address from home or everywhere in the world with any
-   dynamically assigned IP address from any provider. So this domain
-   is to be used from every possible IP address on earth, and they are
-   unable to operate any authentication scheme. Furthermore, they were
-   unable to understand that such a policy heavily supports spam and
-   that they have to expect that people don't accept such e-mails
-   anymore once they become blacklisted.
-
-   As long as organisations insist on having such policies, spammers
-   will have a perfect playground.
-
-14.4.  The mentality problem
-
-   Another problem is the mentality of many internet users of certain
-   countries. I received harsh comments from people who strongly
-   insisted on the freedom to send any e-mail with any sender address
-   from anywhere, and who heavily refused any kind of authentication
-   step or any limitation, because they claimed that this would
-   infringe their constitutional "Freedom of speech". They are
-   undeviatingly convinced that "Freedom of speech" guarantees their
-   right to talk to everybody with any sender address, and that is has
-   to be kept the recipient's own problem to sort out what he doesn't
-   want to read - on the recipient's expense.
-
-   It requires a clear statement that the constitutional "Freedom of
-   Speech" does not cover molesting people with unsolicited e-mail
-   with forged sender address.
-
-14.5.  The identity problem
-
-   How does one fight against mail forgery? With authentication.  What
-   is authentication? In simple words: Making sure that the sender's
-
-
-
-Hadmut Danisch                Experimental                     [Page 33]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-   real identity meets the recipients idea of who is the sender, based
-   on the sender address which came with the message.
-
-   What is identity? It is the main problem. Several countries have
-   different ideas of "identity", which turn out to be somehow
-   incompatible. In some countries people have identity cards and
-   never change their name and birthday. Identities are created by
-   human birth, not by identity changes. Other countries do not have
-   such a tight idea about identity. People's temporary identity is
-   based on nothing more than a driving license and a social security
-   number.  With this background, it is virtually impossible to create
-   a trustworthy PKI covering all Internet users. I learned that it is
-   extremely difficult to convince some people to give up random e-
-   mail sending.
-
-14.6.  The multi-legislation problem
-
-   Many proposals about fighting spam are feasible under certain
-   legislations only, and are inacceptable under some of the
-   legislations. But a world wide applicable method is required.
-   That's why the approach to ask everone on the world to sign
-   messages with cryptographic keys is not feasible.
-
-
-Implementation and further Information
-
-   Further informations and a test implementation are available at
-
-      http://www.danisch.de/work/security/antispam.html
-      http://www.danisch.de/software/rmx/
-
-
-   Additional informations and a technology overview are also
-   available at
-
-      http://www.mikerubel.org/computers/rmx_records/
-
-
-References
-
-
-
-1.   S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev-
-     els," RFC 2119 (March 1997).
-
-2.   J. Klensin, "Simple Mail Transfer Protocol," RFC 2821 (April 2001).
-
-
-
-
-
-Hadmut Danisch                Experimental                     [Page 34]
-
-INTERNET-DRAFT                 DNS RMX RR                       Oct 2003
-
-
-3.   P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION,"
-     RFC 1035 (November 1987).
-
-4.   J. Myers, M. Rose, "Post Office Protocol - Version 3," RFC 1939
-     (May 1996).
-
-
-Draft History
-
-   00  Dec 2002
-   01  Apr 2003
-   02  Jun 2003
-   03  Oct 2003
-
-Author's Address
-
-   Hadmut Danisch
-
-   Tennesseeallee 58
-   76149 Karlsruhe
-   Germany
-
-   Phone:  ++49-721-843004 or ++49-351-4850477
-   E-Mail: rfc@danisch.de
-
-Comments
-
-   Please send comments to rfc@danisch.de.
-
-Expiry
-
-   This drafts expires on Apr 1, 2004.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hadmut Danisch                Experimental                     [Page 35]
-
diff --git a/contrib/bind9/doc/draft/draft-dnsext-opcode-discover-02.txt b/contrib/bind9/doc/draft/draft-dnsext-opcode-discover-02.txt
deleted file mode 100644
index 7b5e8cc..0000000
--- a/contrib/bind9/doc/draft/draft-dnsext-opcode-discover-02.txt
+++ /dev/null
@@ -1,241 +0,0 @@
-
-IETF DNSEXT WG                                             Bill Manning
-draft-dnsext-opcode-discover-02.txt                              ep.net
-                                                             Paul Vixie
-                                                                    ISC
-                                                            13 Oct 2003
-
-
-                         The DISCOVER opcode
-
-This document is an Internet-Draft and is subject to all provisions of
-Section 10 of RFC2026.
-
-Comments may be submitted to the group mailing list at "mdns@zocalo.net"
-or the authors.
-
-Distribution of this memo is unlimited.
-
-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.
-
-The capitalized keywords "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
-
-0. Abstract:
-
-   The QUERY opcode in the DNS is designed for unicast. With the
-   development of multicast capabilities in the DNS, it is desireable
-   to have a more robust opcode for server interactions since a single
-   request may generate replies from multiple responders. So DISCOVER
-   is defined to deal with replies from multiple responders.
-
-   As such, this document extends the core DNS specifications to allow
-   clients to have a method for coping with replies from multiple
-   responders. Use of this new opcode may facilitate DNS operations in
-   modern networking topologies. A prototype of the DISCOVER opcode
-   was developed during the TBDS project (1999-2000), funded under DARPA
-   grant F30602-99-1-0523.
-
-1. Introduction:
-
-   This document describes an experimental extension to the DNS to receive
-   multiple responses which is the likely result when using DNS that has
-   enabled multicast queries.  This approach was developed as part of the
-   TBDS research project, funded under DARPA grant F30602-99-1-0523.  The
-   full processing rules used by TBDS are documented here for possible
-   incorporation in a future revision of the DNS specification."
-
-2. Method:
-
-        DISCOVER works like QUERY except:
-
-        1. it can be sent to a broadcast or multicast destination. QUERY
-           isn't defined for non-unicast, and arguably shouldn't be.
-
-        2. the Question section, if present, has <QNAME=zonename,QTYPE=SOA>
-           tuples. TBDS tried to augment this structure as follows:
-           <QNAME=service,QTYPE=SRV>. While this worked for our purposes in
-           TBDS, it is cleaner to place the SRV question in a separate pass.
-
-        3. if QDCOUNT equals 0 then only servers willing to do recursion should
-           answer. Other servers must silently discard the DISCOVER request.
-
-        4. if QDCOUNT is not equal to 0 then only servers who are authoritative
-           for the zones named by some QNAME should answer.
-
-        5. responses may echo the request's Question section or leave it blank,
-           just like QUERY.
-
-        6. responses have standard Answer, Authority, and Additional sections.
-           e.g. the response is the same as that to a QUERY. It is desireable
-           that zero content answers not be sent to avoid badly formed or
-           unfulfilled requests. Responses should be sent to the unicast
-           address of the requester and the source address should reflect
-           the unicast address of the responder.
-
-   Example usage for gethostby{name,addr}-style requestors:
-
-        Compute the zone name of the enclosing in-addr.arpa, ip6.int, or
-        ip6.arpa domain.
-
-        DISCOVER whether anyone in-scope is authoritative for this zone.
-
-                If so, query these authoritative servers for local
-                in-addr/ip6 names.
-
-        If not, DISCOVER whether there are recursive servers available.
-
-                If so, query these recursive servers for local
-                in-addr/ip6 names.
-
-        So, a node will issue a multicast request with the DISCOVER opcode at
-        some particular multicast scope.  Then determine, from the replies,
-        whether there are any DNS servers which are authoritative (or support
-        recursion) for the zone. Replies to DISCOVER requests MUST set the
-        Recursion Available (RA) flag in the DNS message header.
-
-        It is important to recognize that a requester must be prepared to
-        receive multiple replies from multiple responders. We expect that
-        there will be a single response per responder.
-
-        Once one learns a host's FQDN by the above means, repeat the process
-        for discovering the closest enclosing authoritative server of such
-        local name.
-
-        Cache all NS and A data learned in this process, respecting TTL's.
-
-   TBDS usage for SRV requestors:
-
-        Do the gethostbyaddr() and gethostbyname() on one's own link-local
-        address, using the above process.
-
-        Assume that the closest enclosing zone for which an authority server
-        answers an in-scope DISCOVER packet is "this host's parent domain".
-
-        Compute the SRV name as _service._transport.*.parentdomain.
-
-        This is a change to the definition as defined in RFC 1034.
-        A wildcard label ("*") in the QNAME used in a DNS message with
-        opcode DISCOVER SHOULD be evaluated with special rules.  The
-        wildcard matches any label for which the DNS server data is
-        authoritative.  For example 'x.*.example.com.' would match
-        'x.y.example.com.' and 'x.yy.example.com.' provided that the
-        server was authoritative for 'example.com.'  In this particular
-        case, we suggest the follwing considerations be made:
-
-   getservbyname() can be satisfied by issuing a request with
-   this computed SRV name.  This structure can be
-   populated by values returned from a request as follows:
-
-        s_name    The name of the service, "_service" without the
-                  preceding underscore.
-        s_aliases The names returned in the SRV RRs in replies
-                  to the query.
-        s_port    The port number in the SRV RRs replies to the
-                  query.  If these port numbers disagree - one
-                  of the port numbers is chosen, and only those
-                  names which correspond are returned.
-        s_proto   The transport protocol from named by the
-                  "_transport" label, without the preceding
-                  underscore.
-
-        Send SRV query for this name to discovered local authoritative servers.
-
-     Usage for disconnected networks with no authoritative servers:
-
-        Hosts should run a "stub server" which acts as though its FQDN is a
-        zone name.  Computed SOA gives the host's FQDN as MNAME, "." as the
-        ANAME, seconds-since-1Jan2000 as the SERIAL, low constants for EXPIRE
-        and the other timers.  Compute NS as the host's FQDN.  Compute the
-        glue as the host's link-local address. Or Hosts may run a
-        "DNS stub server" which acts as though its FQDN is a zone name.  The
-        rules governing the behavior of this stub server are given elsewhere
-        [1] [2].
-
-        Such stub servers should answer DISCOVER packets for its zone, and
-        will be found by the iterative "discover closest enclosing authority
-        server" by DISCOVER clients, either in the gethostbyname() or SRV
-        cases described above.  Note that stub servers only answer with
-        zone names which exactly match QNAME's, not with zone names which
-        are owned by QNAME's.
-
-   The main deviation from the DNS[3][4] model is that a host (like, say, a
-   printer offering LPD services) has a DNS server which answers authoritatively
-   for something which hasn't been delegated to it.  However, the only way that
-   such DNS servers can be discovered is with a new opcode, DISCOVER, which
-   is explicitly defined to discover undelegated zones for tightly scoped
-   purposes.  Therefore this isn't officially a violation of DNS's coherency
-   principles. In some cases a responder to DISCOVER may not be traditional
-   DNS software, it could be special purpose software.
-
-3. IANA Considerations
-
-        As a new opcode, the IANA will need to assign a numeric value
-        for the memnonic. The last OPCODE assigned was "5", for UPDATE.
-        Test implementations have used OPCODE "6".
-
-4. Security Considerations
-
-        No new security considerations are known to be introduced with any new
-        opcode, however using multicast for service discovery has the potential
-        for denial of service, primarly from flooding attacks. It may also be
-        possible to enable deliberate misconfiguration of clients simply by
-        running a malicious DNS resolver that claims to be authoritative for
-        things that it is not. One possible way to mitigate this effect is by
-        use of credentials, such as CERT resource records within an RR set.
-        The TBDS project took this approach.
-
-5. Attribution:
-
-        This material was generated in discussions on the mdns mailing list
-hosted by Zocalo in March 2000. Updated by discussion in September/October
-2003.  David Lawrence, Scott Rose, Stuart Cheshire, Bill Woodcock,
-Erik Guttman, Bill Manning and Paul Vixie were active contributors.
-
-6. Author's Address
-
-   Bill Manning
-   PO 12317
-   Marina del Rey, CA. 90295
-   +1.310.322.8102
-   bmanning@karoshi.com
-
-   Paul Vixie
-   Internet Software Consortium
-   950 Charter Street
-   Redwood City, CA 94063
-   +1 650 779 7001
-   <vixie@isc.org>
-
-7. References
-
-Informational References:
-
-[1]  Esibov, L., Aboba, B., Thaler, D., "Multicast DNS",
-        draft-ietf-dnsext-mdns-00.txt, November 2000. Expired
-
-[2] Woodcock, B., Manning, B., "Multicast Domain Name Service",
-        draft-manning-dnsext-mdns-00.txt,  August 2000.  Expired.
-
-Normative References:
-[3]  Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
-        RFC 1034, November 1987.
-[4]  Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
-        RFC 1035, November 1987
-
-        ----------------------------EOL-----------------------
-
diff --git a/contrib/bind9/doc/draft/draft-durand-dnsop-dynreverse-00.txt b/contrib/bind9/doc/draft/draft-durand-dnsop-dynreverse-00.txt
deleted file mode 100644
index 224e7ad1..0000000
--- a/contrib/bind9/doc/draft/draft-durand-dnsop-dynreverse-00.txt
+++ /dev/null
@@ -1,240 +0,0 @@
-Internet Engineering Task Force                             Alain Durand
-INTERNET-DRAFT                                          SUN Microsystems
-Feb 21, 2003
-Expires Aug 2, 2003
-
-
-
-                Dynamic reverse DNS for IPv6
-              <draft-durand-dnsop-dynreverse-00.txt>
-
-
-
-Status of this memo
-
-
-   This memo provides information to the Internet community.  It does
-   not specify an Internet standard of any kind.  This memo is in full
-   conformance with all provisions of Section 10 of RFC2026 [RFC2026].
-
-   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 describes a method to dynamically generate PTR records
-   and corresponding A or AAAA records when the reverse path DNS tree is
-   not populated.
-
-   A special domain dynrev.arpa. is reserved for that purpose.
-
-
-1. Introduction
-
-   In IPv4, the reverse path tree of the DNS under in-addr.arpa.
-   although not perfectly maintained, is still mostly usable and its
-   existence is important for a number of applications that relies on
-   its existence and decent status.  Some applications performs some
-   (very) weak security checks based on it. Mail relays relies on it for
-   some anti-spams checks an some FTP server will not let you in unless
-   your IP address resolve properly with a PTR record.
-
-   IPv6 addresses being much longer (and cumbersome) than IPv4
-   addresses, it is to fear that the reverse path tree under ip6.arpa.
-   would not be as well maintained.  Also, tools like 6to4, Isatap and
-   others have made creative use of the 128 bits of an IPv6 address to
-   automatically embed an IPv4 address to enable seamless connection to
-   the IPv6 Internet. However, no provision has been made to make sure
-   the reverse path tree gets automatically updated as well for those
-   new IPv6 addresses.  One step furter, RFC3041 describes a mechanism
-   to basically use random bits in the bottom part of an IPv6 address to
-   preserver anonymity. If those addresses are to resolve in the reverse
-   path tree, it obviously has to be with anonymous data as well.
-   Another point to note is that home customer ISPs in IPv4 have a
-   current practice to pre-populate the reverse path tree with names
-   automatically derived from the IP addresses. This practice is no
-   longer possible in IPv6, where IP address allocation is not dense as
-   it is the case in IPv4. The mere size of typical customer allocation
-   (2^48 according to the recommendation of RFC3177) makes it
-   impossible.
-
-   Applications that check the existence of PTR records usually follow
-   this by checking if the name pointed by the PTR resolve in a A (or
-   AAAA for IPv6) that match the original IP address. Thus the forward
-   path tree must also include the corresponding data.
-
-   One simple approach of this problem is to simply declare the usage of
-   the reverse path DNS as described above obsolete.  The author believe
-   this is too strong an approach for now.
-
-   Similarly, a completely different approach would be to deprecate the
-   usage of DNS for the reverse tree altogether and replace it by
-   something inspired from ICMP name-info messages. The author believes
-   that this approached is an important departure from the current
-   practise and thus not very realistic.  Also, there are some concerns
-   about the the security implications of this method as any node could
-   easily impersonate any name. This approach would fundamentally change
-   the underlying assumption of "I trust what has been put in the DNS by
-   the local administrators" to "I trust what has been configured on
-   each machine I query directly".
-
-
-
-2. Dynamic record generation
-
-   If static pre-population of the tree is not possible anymore and data
-   still need to be returned to applications using getnameinfo(), the
-   alternative is dynamic record generation.  This can be done is two
-   places: in the DNS servers responsible for the allocated space (/64
-   or /48) in the ip6.arpa. domain.  or in the DNS resolvers (either the
-   sub resolver library or the recursive DNS server).
-
-   2.1. On the resolver side.
-
-   The resolver, either in the recursive DNS server or in the stub
-   library could theoretically generate this data.
-
-   In case DNSsec is in place, the recursive DNS server would have to
-   pretend these records are authentic.
-
-   If the synthesis is done in the stub-resolver library, no record
-   needs to be actually generated, only the right information needs to
-   be passed to getnameinfo() and getaddrinfo().  If the synthesis is
-   done in the recursive DNS server, no modification is required to
-   existing stub resolvers.
-
-
-2.2. On the server side.
-
-   PTR records could be generated automatically by the server
-   responsible for the reverse path tree of an IPv6 prefix (a /64 or /48
-   prefixes or basically anything in between) when static data is not
-   available.
-
-   There could be impact on DNSsec as the zone or some parts of the zone
-   may need to be resigned each time a DNS query is made for an
-   unpopulated address. This can be seen as a DOS attack on a DNSsec
-   zone, so server side synthesis is not recommended if DNSsec is
-   deployed.
-
-
-
-3. Synthesis
-
-   The algorithm is simple: Do the normal queries. If the query returns
-   No such domain, replace this answer by the synthetized one if
-   possible.
-
-3.1. PTR synthesis
-
-   The synthetized PTR for a DNS string [X] is simply [X].dynrev.arpa.
-   where [X] is any valid DNS name.
-
-   The fact that the synthetized PTR points to the dynrev.arpa. domain
-   is an indication to the applications that this record has been
-   dynamically generated.
-
-
-3.2. A synthesis
-
-   If [X] is in the form a.b.c.d.in-addr.arpa, one can synthetized an A
-   record for the string [X].dynrev.arpa. which value is d.c.b.a. with
-   a,b,c & d being integer [0..255]
-
-
-3.3. AAAA synthesis
-
-   If [X] is in the form
-   a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.s.t.u.v.w.x.y.z.A.B.C.D.E.F.in-
-   addr.arpa, one can synthetized a AAAA record for the string
-   [X].dynrev.arpa. which value is
-   FEDC:BAzy:xwvu:tsrq:ponm:lkji:hgfe:dcba with
-   a,b,c....x,y,z,A,B,C,D,E,F being hexadecimal digits.
-
-
-3.4. Server side synthesis
-
-   If synthesis is done on the server side, PTR could be set not to use
-   the dynrev.arpa domain but the local domain name instead.  It culd be
-   for instance dynrev.mydomain.com.
-
-   Note also that server side synthesis is not incompatible with
-   resolver side synthesis.
-
-
-
-4. IANA considerations
-
-   The dynrev.arpa. domain is reserved for the purpose of this document.
-
-
-
-5. Security considerations
-
-   Section 2. discusses the the interactions with DNSsec.
-
-
-
-6. Authors addresses
-
-   Alain Durand
-   SUN Microsystems, Inc
-   17, Network Circle
-   UMPK17-202
-   Menlo Park, CA 94025
-   USA
-   Mail: Alain.Durand@sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-2929bis-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-2929bis-01.txt
deleted file mode 100644
index fa41e76..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-2929bis-01.txt
+++ /dev/null
@@ -1,928 +0,0 @@
-
-INTERNET-DRAFT                                    Donald E. Eastlake 3rd
-Obsoletes RFC 2929, Updates RFC 1183               Motorola Laboratories
-Expires: February 2006                                       August 2005
-
-
-
-              Domain Name System (DNS) IANA Considerations
-              ------ ---- ------ ----- ---- --------------
-                   <draft-ietf-dnsext-2929bis-01.txt>
-
-
-
-Status of This Document
-
-   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 becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Distribution of this draft is unlimited.  It is intended to become
-   the new BCP 42 obsoleting RFC 2929.  Comments should be sent to the
-   DNS 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
-
-   Internet Assigned Number Authority (IANA) parameter assignment
-   considerations are given for the allocation of Domain Name System
-   (DNS) classes, RR types, operation codes, error codes, RR header
-   bits, and AFSDB subtypes.
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 1]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-Table of Contents
-
-      Status of This Document....................................1
-      Abstract...................................................1
-
-      Table of Contents..........................................2
-
-      1. Introduction............................................3
-      2. DNS Query/Response Headers..............................3
-      2.1 One Spare Bit?.........................................4
-      2.2 Opcode Assignment......................................4
-      2.3 RCODE Assignment.......................................5
-      3. DNS Resource Records....................................6
-      3.1 RR TYPE IANA Considerations............................7
-      3.1.1 DNS TYPE Allocation Policy...........................8
-      3.1.2 Special Note on the OPT RR...........................9
-      3.1.3 The AFSDB RR Subtype Field...........................9
-      3.2 RR CLASS IANA Considerations...........................9
-      3.3 RR NAME Considerations................................11
-      4. Security Considerations................................11
-
-      Appendix: Changes from RFC 2929...........................12
-
-      Copyright and Disclaimer..................................13
-      Normative References......................................13
-      Informative References....................................14
-
-      Authors Addresses.........................................16
-      Expiration and File Name..................................16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 2]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-1. Introduction
-
-   The Domain Name System (DNS) provides replicated distributed secure
-   hierarchical databases which hierarchically store "resource records"
-   (RRs) under domain names.  DNS data is structured into CLASSes and
-   zones which can be independently maintained.  See [RFC 1034, 1035,
-   2136, 2181, 4033] familiarity with which is assumed.
-
-   This document provides, either directly or by reference, general IANA
-   parameter assignment considerations applying across DNS query and
-   response headers and all RRs.  There may be additional IANA
-   considerations that apply to only a particular RR type or
-   query/response opcode.  See the specific RFC defining that RR type or
-   query/response opcode for such considerations if they have been
-   defined, except for AFSDB RR considerations [RFC 1183] which are
-   included herein. This RFC obsoletes [RFC 2929].
-
-   IANA currently maintains a web page of DNS parameters.  See
-   <http://www.iana.org/numbers.htm>.
-
-   "IETF Standards Action", "IETF Consensus", "Specification Required",
-   and "Private Use" are as defined in [RFC 2434].
-
-
-
-2. DNS Query/Response Headers
-
-   The header for DNS queries and responses contains field/bits in the
-   following diagram taken from [RFC 2136, 2929]:
-
-                                              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  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-               |                QDCOUNT/ZOCOUNT                |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-               |                ANCOUNT/PRCOUNT                |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-               |                NSCOUNT/UPCOUNT                |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-               |                    ARCOUNT                    |
-               +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   The ID field identifies the query and is echoed in the response so
-   they can be matched.
-
-   The QR bit indicates whether the header is for a query or a response.
-
-
-D. Eastlake 3rd                                                 [Page 3]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-   The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
-   only in queries or only in responses, depending on the bit.  However,
-   many DNS implementations copy the query header as the initial value
-   of the response header without clearing bits.  Thus any attempt to
-   use a "query" bit with a different meaning in a response or to define
-   a query meaning for a "response" bit is dangerous given existing
-   implementation.  Such meanings may only be assigned by an IETF
-   Standards Action.
-
-   The unsigned fields query count (QDCOUNT), answer count (ANCOUNT),
-   authority count (NSCOUNT), and additional information count (ARCOUNT)
-   express the number of records in each section for all opcodes except
-   Update.  These fields have the same structure and data type for
-   Update but are instead the counts for the zone (ZOCOUNT),
-   prerequisite (PRCOUNT), update (UPCOUNT), and additional information
-   (ARCOUNT) sections.
-
-
-
-2.1 One Spare Bit?
-
-   There have been ancient DNS implementations for which the Z bit being
-   on in a query meant that only a response from the primary server for
-   a zone is acceptable.  It is believed that current DNS
-   implementations ignore this bit.
-
-   Assigning a meaning to the Z bit requires an IETF Standards Action.
-
-
-
-2.2 Opcode Assignment
-
-   Currently DNS OpCodes are assigned as follows:
-
-          OpCode Name                      Reference
-
-           0     Query                     [RFC 1035]
-           1     IQuery  (Inverse Query, Obsolete) [RFC 3425]
-           2     Status                    [RFC 1035]
-           3     available for assignment
-           4     Notify                    [RFC 1996]
-           5     Update                    [RFC 2136]
-          6-15   available for assignment
-
-   New OpCode assignments require an IETF Standards Action as modified
-   by [RFC 4020].
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 4]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-2.3 RCODE Assignment
-
-   It would appear from the DNS header above that only four bits of
-   RCODE, or response/error code are available.  However, RCODEs can
-   appear not only at the top level of a DNS response but also inside
-   OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930].
-   The OPT RR provides an eight bit extension resulting in a 12 bit
-   RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field.
-
-   Error codes appearing in the DNS header and in these three RR types
-   all refer to the same error code space with the single exception of
-   error code 16 which has a different meaning in the OPT RR from its
-   meaning in other contexts.  See table below.
-
-        RCODE   Name    Description                        Reference
-        Decimal
-          Hexadecimal
-         0    NoError   No Error                           [RFC 1035]
-         1    FormErr   Format Error                       [RFC 1035]
-         2    ServFail  Server Failure                     [RFC 1035]
-         3    NXDomain  Non-Existent Domain                [RFC 1035]
-         4    NotImp    Not Implemented                    [RFC 1035]
-         5    Refused   Query Refused                      [RFC 1035]
-         6    YXDomain  Name Exists when it should not     [RFC 2136]
-         7    YXRRSet   RR Set Exists when it should not   [RFC 2136]
-         8    NXRRSet   RR Set that should exist does not  [RFC 2136]
-         9    NotAuth   Server Not Authoritative for zone  [RFC 2136]
-        10    NotZone   Name not contained in zone         [RFC 2136]
-        11 - 15         Available for assignment
-        16    BADVERS   Bad OPT Version                    [RFC 2671]
-        16    BADSIG    TSIG Signature Failure             [RFC 2845]
-        17    BADKEY    Key not recognized                 [RFC 2845]
-        18    BADTIME   Signature out of time window       [RFC 2845]
-        19    BADMODE   Bad TKEY Mode                      [RPC 2930]
-        20    BADNAME   Duplicate key name                 [RPF 2930]
-        21    BADALG    Algorithm not supported            [RPF 2930]
-
-        22 - 3,840
-          0x0016 - 0x0F00   Available for assignment
-
-        3,841 - 4,095
-          0x0F01 - 0x0FFF   Private Use
-
-        4,096 - 65,534
-          0x1000 - 0xFFFE   Available for assignment
-
-        65,535
-          0xFFFF            Reserved, can only be allocated by an IETF
-                            Standards Action.
-
-
-
-D. Eastlake 3rd                                                 [Page 5]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-   Since it is important that RCODEs be understood for interoperability,
-   assignment of new RCODE listed above as "available for assignment"
-   requires an IETF Consensus.
-
-
-
-3. DNS Resource Records
-
-   All RRs have the same top level format shown in the figure below
-   taken from [RFC 1035]:
-
-                                       1  1  1  1  1  1
-         0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       |                                               |
-       /                                               /
-       /                      NAME                     /
-       |                                               |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       |                      TYPE                     |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       |                     CLASS                     |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       |                      TTL                      |
-       |                                               |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-       |                   RDLENGTH                    |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
-       /                     RDATA                     /
-       /                                               /
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   NAME is an owner name, i.e., the name of the node to which this
-   resource record pertains.  NAMEs are specific to a CLASS as described
-   in section 3.2.  NAMEs consist of an ordered sequence of one or more
-   labels each of which has a label type [RFC 1035, 2671].
-
-   TYPE is a two octet unsigned integer containing one of the RR TYPE
-   codes.  See section 3.1.
-
-   CLASS is a two octet unsigned integer containing one of the RR CLASS
-   codes.  See section 3.2.
-
-   TTL is a four octet (32 bit) bit unsigned integer that specifies the
-   number of seconds that the resource record may be cached before the
-   source of the information should again be consulted.  Zero is
-   interpreted to mean that the RR can only be used for the transaction
-   in progress.
-
-   RDLENGTH is an unsigned 16 bit integer that specifies the length in
-
-
-D. Eastlake 3rd                                                 [Page 6]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-   octets of the RDATA field.
-
-   RDATA is a variable length string of octets that constitutes the
-   resource. The format of this information varies according to the TYPE
-   and in some cases the CLASS of the resource record.
-
-
-
-3.1 RR TYPE IANA Considerations
-
-   There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
-   and MetaTYPEs.
-
-   Data TYPEs are the primary means of storing data.  QTYPES can only be
-   used in queries.  Meta-TYPEs designate transient data associated with
-   an particular DNS message and in some cases can also be used in
-   queries.  Thus far, data TYPEs have been assigned from 1 upwards plus
-   the block from 100 through 103 while Q and Meta Types have been
-   assigned from 255 downwards except for the OPT Meta-RR which is
-   assigned TYPE 41.  There have been DNS implementations which made
-   caching decisions based on the top bit of the bottom byte of the RR
-   TYPE.
-
-   There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG
-   [RFC 2845], and TKEY [RFC 2930].
-
-   There are currently five QTYPEs assigned: * (all), MAILA, MAILB,
-   AXFR, and IXFR.
-
-   Considerations for the allocation of new RR TYPEs are as follows:
-
-     Decimal
-   Hexadecimal
-
-     0
-   0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC
-          2535] and in other circumstances and must never be allocated
-          for ordinary use.
-
-     1 - 127
-   0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
-          TYPEs by the DNS TYPE Allocation Policy as specified in
-          section 3.1.1.
-
-     128 - 255
-   0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
-          Meta TYPEs by the DNS TYPE Allocation Policy as specified in
-          section 3.1.1.
-
-
-
-
-D. Eastlake 3rd                                                 [Page 7]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-     256 - 32,767
-   0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by the DNS
-          TYPE Allocation Policy as specified in section 3.1.1.
-
-     32,768 - 65,279
-   0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
-
-     65,280 - 65534
-   0xFF00 - 0xFFFE - Private Use.
-
-     65,535
-   0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
-
-
-
-3.1.1 DNS TYPE Allocation Policy
-
-   Parameter values specified above as assigned based on DNS TYPE
-   Allocation Policy. That is, Expert Review with the additional
-   requirement that the review be based on a complete template as
-   specified below which has been posted for three weeks to the
-   namedroppers@ops.ietf.org mailing list.
-
-   Partial or draft templates may be posted with the intend of
-   soliciting feedback.
-
-
-                 DNS RR TYPE PARAMETER ALLOCATION TEMPLATE
-
-        Date:
-
-        Name and email of originator:
-
-        Pointer to internet-draft or other document giving a detailed
-        description of the protocol use of the new RR Type:
-
-        What need is the new RR TYPE intended to fix?
-
-        What existing RR TYPE(s) come closest to filling that need and why are
-        they unsatisfactory?
-
-        Does the proposed RR TYPR require special handling within the DNS
-        different from an Unknown RR TYPE?
-
-        Comments:
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 8]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-3.1.2 Special Note on the OPT RR
-
-   The OPT (OPTion) RR, number 41, is specified in [RFC 2671].  Its
-   primary purpose is to extend the effective field size of various DNS
-   fields including RCODE, label type, OpCode, flag bits, and RDATA
-   size.  In particular, for resolvers and servers that recognize it, it
-   extends the RCODE field from 4 to 12 bits.
-
-
-
-3.1.3 The AFSDB RR Subtype Field
-
-   The AFSDB RR [RFC 1183] is a CLASS insensitive RR that has the same
-   RDATA field structure as the MX RR but the 16 bit unsigned integer
-   field at the beginning of the RDATA is interpreted as a subtype as
-   follows:
-
-     Decimal
-   Hexadecimal
-
-     0
-   0x0000 -  Allocation requires IETF Standards Action.
-
-     1
-   0x0001 - Andrews File Service v3.0 Location Service [RFC 1183].
-
-     2
-   0x0002 - DCE/NCA root cell directory node [RFC 1183].
-
-     3 - 65,279
-   0x0003 - 0xFEFF - Allocation by IETF Consensus.
-
-     65,280 - 65,534
-   0xFF00 - 0xFFFE - Private Use.
-
-     65,535
-   0xFFFF - Reserved, allocation requires IETF Standards Action.
-
-
-
-3.2 RR CLASS IANA Considerations
-
-   DNS CLASSes have been little used but constitute another dimension of
-   the DNS distributed database.  In particular, there is no necessary
-   relationship between the name space or root servers for one CLASS and
-   those for another CLASS.  The same name can have completely different
-   meanings in different CLASSes; however, the label types are the same
-   and the null label is usable only as root in every CLASS.  However,
-   as global networking and DNS have evolved, the IN, or Internet, CLASS
-   has dominated DNS use.
-
-
-D. Eastlake 3rd                                                 [Page 9]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-   There are two subcategories of DNS CLASSes: normal data containing
-   classes and QCLASSes that are only meaningful in queries or updates.
-
-   The current CLASS assignments and considerations for future
-   assignments are as follows:
-
-     Decimal
-   Hexadecimal
-
-     0
-   0x0000 - Reserved, assignment requires an IETF Standards Action.
-
-     1
-   0x0001 - Internet (IN).
-
-     2
-   0x0002 - Available for assignment by IETF Consensus as a data CLASS.
-
-     3
-   0x0003 - Chaos (CH) [Moon 1981].
-
-     4
-   0x0004 - Hesiod (HS) [Dyer 1987].
-
-     5 - 127
-   0x0005 - 0x007F - available for assignment by IETF Consensus for data
-          CLASSes only.
-
-     128 - 253
-   0x0080 - 0x00FD - available for assignment by IETF Consensus for
-          QCLASSes only.
-
-     254
-   0x00FE - QCLASS None [RFC 2136].
-
-     255
-   0x00FF - QCLASS Any [RFC 1035].
-
-     256 - 32,767
-   0x0100 - 0x7FFF - Assigned by IETF Consensus.
-
-     32,768 - 65,279
-   0x8000 - 0xFEFF - Assigned based on Specification Required as defined
-          in [RFC 2434].
-
-     65,280 - 65,534
-   0xFF00 - 0xFFFE - Private Use.
-
-     65,535
-   0xFFFF - Reserved, can only be assigned by an IETF Standards Action.
-
-
-D. Eastlake 3rd                                                [Page 10]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-3.3 RR NAME Considerations
-
-   DNS NAMEs are sequences of labels [RFC 1035].  The last label in each
-   NAME is "ROOT" which is the zero length label.  By definition, the
-   null or ROOT label can not be used for any other NAME purpose.
-
-   At the present time, there are two categories of label types, data
-   labels and compression labels.  Compression labels are pointers to
-   data labels elsewhere within an RR or DNS message and are intended to
-   shorten the wire encoding of NAMEs.  The two existing data label
-   types are sometimes referred to as Text and Binary.  Text labels can,
-   in fact, include any octet value including zero value octets but most
-   current uses involve only [US-ASCII].  For retrieval, Text labels are
-   defined to treat ASCII upper and lower case letter codes as matching
-   [insensitive].  Binary labels are bit sequences [RFC 2673]. The
-   Binary label type is Experimental [RFC 3363].
-
-   IANA considerations for label types are given in [RFC 2671].
-
-   NAMEs are local to a CLASS.  The Hesiod [Dyer 1987] and Chaos [Moon
-   1981] CLASSes are essentially for local use.  The IN or Internet
-   CLASS is thus the only DNS CLASS in global use on the Internet at
-   this time.
-
-   A somewhat out-of-date description of name allocation in the IN Class
-   is given in [RFC 1591].  Some information on reserved top level
-   domain names is in BCP 32 [RFC 2606].
-
-
-
-4. Security Considerations
-
-   This document addresses IANA considerations in the allocation of
-   general DNS parameters, not security.  See [RFC 4033, 4034, 4035] for
-   secure DNS considerations.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                [Page 11]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-Appendix: Changes from RFC 2929
-
-   RFC Editor: This Appendix should be deleted for publication.
-
-   Changes from RFC 2929 to this draft:
-
-   1. Changed many "IETF Consensus" for RR TYPEs to be "DNS TYPE
-   Allocation Policy" and add the specification of that policy. Change
-   some remaining "IETF Standards Action" allocation requirements to say
-   "as modified by [RFC 4020]".
-
-   2. Updated various RFC references.
-
-   3. Mentioned that the Binary label type is now Experimental and
-   IQuery is Obsolete.
-
-   4. Changed allocation status of RR Type 0xFFFF and RCODE 0xFFFF to be
-   IETF Standards Action required.
-
-   5. Add an IANA allocation policy for the AFSDB RR Subtype field.
-
-   6. Addition of reference to case insensitive draft.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                [Page 12]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-Copyright and Disclaimer
-
-   Copyright (C) The Internet Society (2005).  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
-
-   [RFC 1034] - Mockapetris, P., "Domain Names - Concepts and
-   Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC 1035] - Mockapetris, P., "Domain Names - Implementation and
-   Specifications", STD 13, RFC 1035, November 1987.
-
-   [RFC 1183] - Everhart, C., Mamakos, L., Ullmann, R., and P.
-   Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990.
-
-   [RFC 1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone
-   Changes (DNS NOTIFY)", RFC 1996, August 1996.
-
-   [RFC 2136] - Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
-   "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
-   April 1997.
-
-   [RFC 2181] - Elz, R. and R. Bush, "Clarifications to the DNS
-   Specification", RFC 2181, July 1997.
-
-   [RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an
-   IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-   [RFC 2671] - Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC
-   2671, August 1999.
-
-   [RFC 2673] - Crawford, M., "Binary Labels in the Domain Name System",
-   RFC 2673, August 1999.
-
-   [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B.
-   Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
-   RFC 2845, May 2000.
-
-
-D. Eastlake 3rd                                                [Page 13]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-   [RFC 2930] - Eastlake, D., "Secret Key Establishment for DNS (TKEY
-   RR)", September 2000.
-
-   [RFC 3363] - 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.
-
-   [RFC 3425] - Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
-   2002.
-
-   [RFC 4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of
-   Standards Track Code Points", BCP 100, RFC 4020, February 2005.
-
-   [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "DNS Security Introduction and Requirements", RFC 4033, March
-   2005.
-
-   [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
-   March 2005.
-
-   [RFC 4044] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "Protocol Modifications for the DNS Security Extensions", RFC
-   4035, March 2005.
-
-   [US-ASCII] - ANSI, "USA Standard Code for Information Interchange",
-   X3.4, American National Standards Institute: New York, 1968.
-
-
-
-Informative References
-
-   [Dyer 1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena
-   Technical Plan - Name Service, April 1987,
-
-   [Moon 1981] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
-   Institute of Technology Artificial Intelligence Laboratory, June
-   1981.
-
-   [RFC 1591] - Postel, J., "Domain Name System Structure and
-   Delegation", RFC 1591, March 1994.
-
-   [RFC 2929] - Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
-   "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
-   September 2000.
-
-   [RFC 2606] - Eastlake, D. and A. Panitz, "Reserved Top Level DNS
-   Names", RFC 2606, June 1999.
-
-   [insensitive] - Eastlake, D., "Domain Name System (DNS) Case
-
-
-D. Eastlake 3rd                                                [Page 14]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-   Insensitivity Clarification", draft-ietf-dnsext-insensitive-*.txt,
-   work in progress.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                [Page 15]
-
-
-INTERNET-DRAFT           DNS IANA Considerations             August 2005
-
-
-Authors Addresses
-
-   Donald E. Eastlake 3rd
-   Motorola Laboratories
-   155 Beaver Street
-   Milford, MA 01757 USA
-
-   Telephone:   +1-508-786-7554 (w)
-   email:       Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
-   This draft expires February 2006.
-
-   Its file name is draft-ietf-dnsext-2929bis-01.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                [Page 16]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt
deleted file mode 100644
index f0ce70a..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt
+++ /dev/null
@@ -1,393 +0,0 @@
-
-
-
-INTERNET-DRAFT                                      Andreas Gustafsson
-draft-ietf-dnsext-axfr-clarify-05.txt                     Nominum Inc.
-                                                         November 2002
-
-
-               DNS Zone Transfer Protocol Clarifications
-
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups.  Note that
-   other groups may also distribute working documents as Internet-
-   Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at
-   http://www.ietf.org/ietf/1id-abstracts.txt
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-Abstract
-
-   In the Domain Name System, zone data is replicated among
-   authoritative DNS servers by means of the "zone transfer" protocol,
-   also known as the "AXFR" protocol.  This memo clarifies, updates, and
-   adds missing detail to the original AXFR protocol specification in
-   RFC1034.
-
-1. Introduction
-
-   The original definition of the DNS zone transfer protocol consists of
-   a single paragraph in [RFC1034] section 4.3.5 and some additional
-   notes in [RFC1035] section 6.3.  It is not sufficiently detailed to
-   serve as the sole basis for constructing interoperable
-   implementations.  This document is an attempt to provide a more
-   complete definition of the protocol.  Where the text in RFC1034
-   conflicts with existing practice, the existing practice has been
-   codified in the interest of interoperability.
-
-
-
-
-Expires May 2003                                                [Page 1]
-
-draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-   document are to be interpreted as described in [RFC 2119].
-
-2. The zone transfer request
-
-   To initiate a zone transfer, the slave server sends a zone transfer
-   request to the master server over a reliable transport such as TCP.
-   The form of this request is specified in sufficient detail in RFC1034
-   and needs no further clarification.
-
-   Implementers are advised that one server implementation in widespread
-   use sends AXFR requests where the TCP message envelope size exceeds
-   the DNS request message size by two octets.
-
-3. The zone transfer response
-
-   If the master server is unable or unwilling to provide a zone
-   transfer, it MUST respond with a single DNS message containing an
-   appropriate RCODE other than NOERROR.  If the master is not
-   authoritative for the requested zone, the RCODE SHOULD be 9
-   (NOTAUTH).
-
-   Slave servers should note that some master server implementations
-   will simply close the connection when denying the slave access to the
-   zone.  Therefore, slaves MAY interpret an immediate graceful close of
-   the TCP connection as equivalent to a "Refused" response (RCODE 5).
-
-   If a zone transfer can be provided, the master server sends one or
-   more DNS messages containing the zone data as described below.
-
-3.1. Multiple answers per message
-
-   The zone data in a zone transfer response is a sequence of answer
-   RRs.  These RRs are transmitted in the answer section(s) of one or
-   more DNS response messages.
-
-   The AXFR protocol definition in RFC1034 does not make a clear
-   distinction between response messages and answer RRs.  Historically,
-   DNS servers always transmitted a single answer RR per message.  This
-   encoding is wasteful due to the overhead of repeatedly sending DNS
-   message headers and the loss of domain name compression
-   opportunities.  To improve efficiency, some newer servers support a
-   mode where multiple RRs are transmitted in a single DNS response
-   message.
-
-   A master MAY transmit multiple answer RRs per response message up to
-   the largest number that will fit within the 65535 byte limit on TCP
-
-
-
-Expires May 2003                                                [Page 2]
-
-draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
-
-
-   DNS message size.  In the case of a small zone, this can cause the
-   entire transfer to be transmitted in a single response message.
-
-   Slaves MUST accept messages containing any number of answer RRs.  For
-   compatibility with old slaves, masters that support sending multiple
-   answers per message SHOULD be configurable to revert to the
-   historical mode of one answer per message, and the configuration
-   SHOULD be settable on a per-slave basis.
-
-3.2. DNS message header contents
-
-   RFC1034 does not specify the contents of the DNS message header of
-   the zone transfer response messages.  The header of each message MUST
-   be as follows:
-
-       ID      Copy from request
-       QR      1
-       OPCODE  QUERY
-       AA      1, but MAY be 0 when RCODE is not NOERROR
-       TC      0
-       RD      Copy from request, or 0
-       RA      Set according to availability of recursion, or 0
-       Z       0
-       AD      0
-       CD      0
-       RCODE   NOERROR on success, error code otherwise
-
-   The slave MUST check the RCODE in each message and abort the transfer
-   if it is not NOERROR.  It SHOULD check the ID of the first message
-   received and abort the transfer if it does not match the ID of the
-   request.  The ID SHOULD be ignored in subsequent messages, and fields
-   other than RCODE and ID SHOULD be ignored in all messages, to ensure
-   interoperability with certain older implementations which transmit
-   incorrect or arbitrary values in these fields.
-
-3.3. Additional section and SIG processing
-
-   Zone transfer responses are not subject to any kind of additional
-   section processing or automatic inclusion of SIG records.  SIG RRs in
-   the zone data are treated exactly the same as any other RR type.
-
-3.4. The question section
-
-   RFC1034 does not specify whether zone transfer response messages have
-   a question section or not.  The initial message of a zone transfer
-   response SHOULD have a question section identical to that in the
-   request.  Subsequent messages SHOULD NOT have a question section,
-   though the final message MAY.  The receiving slave server MUST accept
-
-
-
-Expires May 2003                                                [Page 3]
-
-draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
-
-
-   any combination of messages with and without a question section.
-
-3.5. The authority section
-
-   The master server MUST transmit messages with an empty authority
-   section.  Slaves MUST ignore any authority section contents they may
-   receive from masters that do not comply with this requirement.
-
-3.6. The additional section
-
-   The additional section MAY contain additional RRs such as transaction
-   signatures.  The slave MUST ignore any unexpected RRs in the
-   additional section.  It MUST NOT treat additional section RRs as zone
-   data.
-
-4. Zone data
-
-   The purpose of the zone transfer mechanism is to exactly replicate at
-   each slave the set of RRs associated with a particular zone at its
-   primary master.  An RR is associated with a zone by being loaded from
-   the master file of that zone at the primary master server, or by some
-   other, equivalent method for configuring zone data.
-
-   This replication shall be complete and unaltered, regardless of how
-   many and which intermediate masters/slaves are involved, and
-   regardless of what other zones those intermediate masters/slaves do
-   or do not serve, and regardless of what data may be cached in
-   resolvers associated with the intermediate masters/slaves.
-
-   Therefore, in a zone transfer the master MUST send exactly those
-   records that are associated with the zone, whether or not their owner
-   names would be considered to be "in" the zone for purposes of
-   resolution, and whether or not they would be eligible for use as glue
-   in responses.  The transfer MUST NOT include any RRs that are not
-   associated with the zone, such as RRs associated with zones other
-   than the one being transferred or present in the cache of the local
-   resolver, even if their owner names are in the zone being transferred
-   or are pointed to by NS records in the zone being transferred.
-
-   The slave MUST associate the RRs received in a zone transfer with the
-   specific zone being transferred, and maintain that association for
-   purposes of acting as a master in outgoing transfers.
-
-5. Transmission order
-
-   RFC1034 states that "The first and last messages must contain the
-   data for the top authoritative node of the zone".  This is not
-   consistent with existing practice.  All known master implementations
-
-
-
-Expires May 2003                                                [Page 4]
-
-draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
-
-
-   send, and slave implementations expect to receive, the zone's SOA RR
-   as the first and last record of the transfer.
-
-   Therefore, the quoted sentence is hereby superseded by the sentence
-   "The first and last RR transmitted must be the SOA record of the
-   zone".
-
-   The initial and final SOA record MUST be identical, with the possible
-   exception of case and compression.  In particular, they MUST have the
-   same serial number.  The slave MUST consider the transfer to be
-   complete when, and only when, it has received the message containing
-   the second SOA record.
-
-   The transmission order of all other RRs in the zone is undefined.
-   Each of them SHOULD be transmitted only once, and slaves MUST ignore
-   any duplicate RRs received.
-
-6. Security Considerations
-
-   The zone transfer protocol as defined in [RFC1034] and clarified by
-   this memo does not have any built-in mechanisms for the slave to
-   securely verify the identity of the master server and the integrity
-   of the transferred zone data.  The use of a cryptographic mechanism
-   for ensuring authenticity and integrity, such as TSIG [RFC2845],
-   IPSEC, or TLS, is RECOMMENDED.
-
-   The zone transfer protocol allows read-only public access to the
-   complete zone data.  Since data in the DNS is public by definition,
-   this is generally acceptable.  Sites that wish to avoid disclosing
-   their full zone data MAY restrict zone transfer access to authorized
-   slaves.
-
-   These clarifications are not believed to themselves introduce any new
-   security problems, nor to solve any existing ones.
-
-Acknowledgements
-
-   Many people have contributed input and commentary to earlier versions
-   of this document, including but not limited to Bob Halley, Dan
-   Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert Elz,
-   Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam
-   Trenholme, and Brian Wellington.
-
-References
-
-   [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
-   November 1987.
-
-
-
-
-Expires May 2003                                                [Page 5]
-
-draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
-
-
-   [RFC1035] - Domain Names - Implementation and Specifications, P.
-   Mockapetris, November 1987.
-
-   [RFC2119] - Key words for use in RFCs to Indicate Requirement Levels,
-   S. Bradner, BCP 14, March 1997.
-
-   [RFC2845] - Secret Key Transaction Authentication for DNS (TSIG).  P.
-   Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000.
-
-Author's Address
-
-   Andreas Gustafsson
-   Nominum Inc.
-   2385 Bay Rd
-   Redwood City, CA 94063
-   USA
-
-   Phone: +1 650 381 6004
-
-   Email: gson@nominum.com
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000 - 2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implmentation may be prepared, copied, published and
-   distributed, in whole or in part, without restriction of any kind,
-   provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
-   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
-   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-
-
-
-Expires May 2003                                                [Page 6]
-
-draft-ietf-dnsext-axfr-clarify-05.txt                      November 2002
-
-
-   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires May 2003                                                [Page 7]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt
deleted file mode 100644
index 07749d9..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt
+++ /dev/null
@@ -1,674 +0,0 @@
-
-
-
-
-DNSEXT                                                          M. Stapp
-Internet-Draft                                       Cisco Systems, Inc.
-Expires: September 1, 2006                                      T. Lemon
-                                                           Nominum, Inc.
-                                                           A. Gustafsson
-                                          Araneus Information Systems Oy
-                                                       February 28, 2006
-
-
-           A DNS RR for Encoding DHCP Information (DHCID RR)
-                  <draft-ietf-dnsext-dhcid-rr-12.txt>
-
-Status of this Memo
-
-   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 becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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 September 1, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   It is possible for DHCP clients to attempt to update the same DNS
-   FQDN or attempt to update a DNS FQDN that has been added to the DNS
-   for another purpose 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
-
-
-
-Stapp, et al.           Expires September 1, 2006               [Page 1]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-   Conflicts" [1] proposes storing client identifiers in the DNS to
-   unambiguously 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 . . . . . . . . . . . . . . . . . . . .  3
-     3.2.  DHCID Presentation Format  . . . . . . . . . . . . . . . .  4
-     3.3.  The DHCID RR Identifier Type Codes . . . . . . . . . . . .  4
-     3.4.  The DHCID RR Digest Type Code  . . . . . . . . . . . . . .  4
-     3.5.  Computation of the RDATA . . . . . . . . . . . . . . . . .  5
-       3.5.1.  Using the Client's DUID  . . . . . . . . . . . . . . .  5
-       3.5.2.  Using the Client Identifier Option . . . . . . . . . .  5
-       3.5.3.  Using the Client's htype and chaddr  . . . . . . . . .  6
-     3.6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . .  6
-       3.6.1.  Example 1  . . . . . . . . . . . . . . . . . . . . . .  6
-       3.6.2.  Example 2  . . . . . . . . . . . . . . . . . . . . . .  6
-       3.6.3.  Example 3  . . . . . . . . . . . . . . . . . . . . . .  7
-   4.  Use of the DHCID RR  . . . . . . . . . . . . . . . . . . . . .  7
-   5.  Updater Behavior . . . . . . . . . . . . . . . . . . . . . . .  8
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
-   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
-     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
-     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
-   Intellectual Property and Copyright Statements . . . . . . . . . . 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al.           Expires September 1, 2006               [Page 2]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-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 [6] [10] 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 or a DHCP client attempts to use a name added for another
-   purpose.  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 obscure potentially sensitive client identifying
-   information, the data stored is the result of a one-way SHA-256 hash
-   computation.  The hash includes information from the DHCP client's
-   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.
-
-
-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.
-
-3.1.  DHCID RDATA format
-
-   The RDATA section of a DHCID RR in transmission contains RDLENGTH
-   octets 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
-
-
-
-Stapp, et al.           Expires September 1, 2006               [Page 3]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-   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 2-octet identifier type, in network byte order,
-   followed by a 1-octet digest type, followed by one or more octets
-   representing the actual identifier:
-
-           < 2 octets >    Identifier type code
-           < 1 octet >     Digest type code
-           < n octets >    Digest (length depends on digest type)
-
-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 3548 [7].  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 Identifier Type Codes
-
-   The DHCID RR Identifier Type Code specifies what data from the DHCP
-   client's request was used as input into the hash function.  The
-   identifier type codes are defined in a registry maintained by IANA,
-   as specified in Section 7.  The initial list of assigned values for
-   the identifier type code is:
-
-   0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [6].
-   0x0001 = The data octets (i.e., the Type and Client-Identifier
-      fields) from a DHCPv4 client's Client Identifier option [9].
-   0x0002 = The client's DUID (i.e., the data octets 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.  The DHCID RR Digest Type Code
-
-   The DHCID RR Digest Type Code is an identifier for the digest
-   algorithm used.  The digest is calculated over an identifier and the
-   canonical FQDN as described in the next section.
-
-   The digest type codes are defined in a registry maintained by IANA,
-   as specified in Section 7.  The initial list of assigned values for
-   the digest type codes is: value 0 is reserved and value 1 is SHA-256.
-
-
-
-Stapp, et al.           Expires September 1, 2006               [Page 4]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-   Reserving other types requires IETF standards action.  Defining new
-   values will also require IETF standards action to document how DNS
-   updaters are to deal with multiple digest types.
-
-3.5.  Computation of the RDATA
-
-   The DHCID RDATA is formed by concatenating the 2-octet identifier
-   type code with variable-length data.
-
-   The RDATA for all type codes other than 0xffff, which is reserved for
-   future expansion, is formed by concatenating the 2-octet identifier
-   type code, the 1-octet digest type code, and the digest value (32
-   octets for SHA-256).
-
-       < identifier-type > < digest-type > < digest >
-
-   The input to the digest hash function is defined to be:
-
-       digest = SHA-256(< identifier > < FQDN >)
-
-   The FQDN is represented in the buffer in unambiguous canonical form
-   as described in RFC 4034 [8], section 6.1.  The identifier type code
-   and the identifier are related as specified in Section 3.3: the
-   identifier type code describes the source of the identifier.
-
-   A DHCPv4 updater uses the 0x0002 type code if a Client Identifier
-   option is present in the DHCPv4 messages and it is encoded as
-   specified in [12].  Otherwise, the updater uses 0x0001 if a Client
-   Identifier option is present and 0x0000 if not.
-
-   A DHCPv6 updater always uses the 0x0002 type code.
-
-3.5.1.  Using the Client's DUID
-
-   When the updater is using the Client's DUID (either from a DHCPv6
-   Client Identifier option or from a portion of the DHCPv4 Client
-   Identifier option encoded as specified in [12]), the first two octets
-   of the DHCID RR MUST be 0x0002, in network byte order.  The third
-   octet is the digest type code (1 for SHA-256).  The rest of the DHCID
-   RR MUST contain the results of computing the SHA-256 hash across the
-   octets of the DUID followed by the FQDN.
-
-3.5.2.  Using the Client Identifier Option
-
-   When the updater is using the DHCPv4 Client Identifier option sent by
-   the client in its DHCPREQUEST message, the first two octets of the
-   DHCID RR MUST be 0x0001, in network byte order.  The third octet is
-   the digest type code (1 for SHA-256).  The rest of the DHCID RR MUST
-
-
-
-Stapp, et al.           Expires September 1, 2006               [Page 5]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-   contain the results of computing the SHA-256 hash across the data
-   octets (i.e., the Type and Client-Identifier fields) of the option,
-   followed by the FQDN.
-
-3.5.3.  Using the Client's htype and chaddr
-
-   When the updater is using the client's link-layer address as the
-   identifier, the first two octets of the DHCID RDATA MUST be zero.
-   The third octet is the digest type code (1 for SHA-256).  To generate
-   the rest of the resource record, the updater computes a one-way hash
-   using the SHA-256 algorithm across a buffer containing the client's
-   network hardware type, link-layer address, and the FQDN data.
-   Specifically, the first octet 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 octets of the
-   'chaddr' field in the client's DHCPREQUEST message follow, in the
-   same order in which the octets appear in the DHCPREQUEST message.
-   The number of significant octets in the 'chaddr' field is specified
-   in the 'hlen' field of the DHCPREQUEST message.  The FQDN data, as
-   specified above, follows.
-
-3.6.  Examples
-
-3.6.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
-   octets to zero, the 1-octet digest type to 1 for SHA-256, and
-   performing an SHA-256 hash computation across a buffer containing the
-   Ethernet MAC type octet, 0x01, the six octets of MAC address, and the
-   domain name (represented as specified in Section 3.5).
-
-     client.example.com.   A       10.0.0.1
-     client.example.com.   DHCID   ( AAABxLmlskllE0MVjd57zHcWmEH3pCQ6V
-                                     ytcKD//7es/deY= )
-
-   If the DHCID RR type is not supported, the RDATA would be encoded
-   [13] as:
-
-     \# 35 ( 000001c4b9a5b249651343158dde7bcc77169841f7a4243a572b5c283
-             fffedeb3f75e6 )
-
-3.6.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
-
-
-
-Stapp, et al.           Expires September 1, 2006               [Page 6]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-   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 octets to the value 0x0001, the 1-octet digest
-   type to 1 for SHA-256, and performing a SHA-256 hash computation
-   across a buffer containing the seven octets from the client-id option
-   and the FQDN (represented as specified in Section 3.5).
-
-     chi.example.com.      A       10.0.12.99
-     chi.example.com.      DHCID   ( AAEBOSD+XR3Os/0LozeXVqcNc7FwCfQdW
-                                     L3b/NaiUDlW2No= )
-
-   If the DHCID RR type is not supported, the RDATA would be encoded
-   [13] as:
-
-     \# 35 ( 0001013920fe5d1dceb3fd0ba3379756a70d73b17009f41d58bddbfcd
-             6a2503956d8da )
-
-3.6.3.  Example 3
-
-   A DHCP server allocates the IPv6 address 2000::1234:5678 to a client
-   which included the DHCPv6 client-identifier option data 00:01:00:06:
-   41:2d:f1:66:01:02:03:04:05:06 in its DHCPv6 request.  The server
-   updates the name "chi6.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 octets to the
-   value 0x0002, the 1-octet digest type to 1 for SHA-256, and
-   performing a SHA-256 hash computation across a buffer containing the
-   14 octets from the client-id option and the FQDN (represented as
-   specified in Section 3.5).
-
-     chi6.example.com.     AAAA    2000::1234:5678
-     chi6.example.com.     DHCID   ( AAIBY2/AuCccgoJbsaxcQc9TUapptP69l
-                                     OjxfNuVAA2kjEA= )
-
-   If the DHCID RR type is not supported, the RDATA would be encoded
-   [13] as:
-
-     \# 35 ( 000201636fc0b8271c82825bb1ac5c41cf5351aa69b4febd94e8f17cd
-             b95000da48c40 )
-
-
-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.
-
-
-
-Stapp, et al.           Expires September 1, 2006               [Page 7]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-   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
-   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 obscure the client's identity information,
-   a one-way hash is used.  And, 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.
-
-   However, it should be noted that an attacker that has some knowledge,
-   such as of MAC addresses commonly used in DHCP client identification
-   data, may be able to discover the client's DHCP identify by using a
-   brute-force attack.  Even without any additional knowledge, the
-   number of unknown bits used in computing the hash is typically only
-   48 to 80.
-
-   Administrators should be wary of permitting unsecured DNS updates to
-   zones, whether or not they 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
-
-
-
-
-Stapp, et al.           Expires September 1, 2006               [Page 8]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-   IANA is requested to allocate a DNS RR type number for the DHCID
-   record type.
-
-   This specification defines a new number-space for the 2-octet
-   identifier 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 identifier
-   type codes are assigned through Standards Action, as defined in RFC
-   2434 [5].
-
-   This specification defines a new number-space for the 1-octet digest
-   type codes associated with the DHCID RR.  IANA is requested to
-   establish a registry of the values for this number-space.  Two
-   initial values are assigned in Section 3.4.  New DHCID RR digest type
-   codes are assigned through Standards Action, as defined in RFC 2434
-   [5].
-
-
-8.  Acknowledgements
-
-   Many thanks to Harald Alvestrand, Ralph Droms, Olafur Gudmundsson,
-   Sam Hartman, Josh Littlefield, Pekka Savola, and especially Bernie
-   Volz for their review and suggestions.
-
-
-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-*)", February 2006.
-
-   [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]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-
-
-
-
-
-
-Stapp, et al.           Expires September 1, 2006               [Page 9]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-9.2.  Informative References
-
-   [6]   Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
-         March 1997.
-
-   [7]   Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
-         RFC 3548, July 2003.
-
-   [8]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Resource Records for the DNS Security Extensions", RFC 4034,
-         March 2005.
-
-   [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 Dynamic Host Configuration Protocol Version Four (DHCPv4)",
-         RFC 4361, February 2006.
-
-   [13]  Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
-         Types", RFC 3597, September 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al.           Expires September 1, 2006              [Page 10]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-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
-   Araneus Information Systems Oy
-   Ulappakatu 1
-   02320 Espoo
-   Finland
-
-   Email: gson@araneus.fi
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al.           Expires September 1, 2006              [Page 11]
-
-Internet-Draft                The DHCID RR                 February 2006
-
-
-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 (2006).  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 September 1, 2006              [Page 12]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt
deleted file mode 100644
index 438e800..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt
+++ /dev/null
@@ -1,1397 +0,0 @@
-DNS Extensions Working Group                                   G. Sisson
-Internet-Draft                                                 B. Laurie
-Expires: January 11, 2006                                        Nominet
-                                                           July 10, 2005
-
-
-            Derivation of DNS Name Predecessor and Successor
-                   draft-ietf-dnsext-dns-name-p-s-00
-
-Status of this Memo
-
-   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 becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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 11, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document describes two methods for deriving the canonically-
-   ordered predecessor and successor of a DNS name.  These methods may
-   be used for dynamic NSEC resource record synthesis, enabling
-   security-aware name servers to provide authenticated denial of
-   existence without disclosing other owner names in a DNSSEC-secured
-   zone.
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006                [Page 1]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Notational Conventions . . . . . . . . . . . . . . . . . . . .  3
-   3.  Absolute Method  . . . . . . . . . . . . . . . . . . . . . . .  4
-     3.1.  Derivation of DNS Name Predecessor . . . . . . . . . . . .  4
-     3.2.  Derivation of DNS Name Successor . . . . . . . . . . . . .  4
-   4.  Modified Method  . . . . . . . . . . . . . . . . . . . . . . .  5
-     4.1.  Derivation of DNS Name Predecessor . . . . . . . . . . . .  6
-     4.2.  Derivation of DNS Name Successor . . . . . . . . . . . . .  6
-   5.  Notes  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
-     5.1.  Case Considerations  . . . . . . . . . . . . . . . . . . .  7
-     5.2.  Choice of Range  . . . . . . . . . . . . . . . . . . . . .  7
-     5.3.  Wild Card Considerations . . . . . . . . . . . . . . . . .  8
-     5.4.  Possible Modifications . . . . . . . . . . . . . . . . . .  8
-       5.4.1.  Restriction of Effective Maximum DNS Name Length . . .  8
-       5.4.2.  Use of Modified Method With Zones Containing
-               SRV RRs  . . . . . . . . . . . . . . . . . . . . . . .  9
-   6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
-     6.1.  Examples of Immediate Predecessors Using Absolute
-           Method . . . . . . . . . . . . . . . . . . . . . . . . . . 10
-     6.2.  Examples of Immediate Successors Using Absolute Method . . 13
-     6.3.  Examples of Predecessors Using Modified Method . . . . . . 19
-     6.4.  Examples of Successors Using Modified Method . . . . . . . 20
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
-   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
-     10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
-     10.2. Informative References . . . . . . . . . . . . . . . . . . 22
-   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 21
-   Appendix A.  Change History  . . . . . . . . . . . . . . . . . . . 22
-     A.1.  Changes from sisson-02 to ietf-00  . . . . . . . . . . . . 22
-     A.2.  Changes from sisson-01 to sisson-02  . . . . . . . . . . . 23
-     A.3.  Changes from sisson-00 to sisson-01  . . . . . . . . . . . 23
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
-   Intellectual Property and Copyright Statements . . . . . . . . . . 25
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006                [Page 2]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-1.  Introduction
-
-   One of the proposals for avoiding the exposure of zone information
-   during the deployment DNSSEC is dynamic NSEC resource record (RR)
-   synthesis.  This technique is described in [I-D.ietf-dnsext-dnssec-
-   trans] and [I-D.ietf-dnsext-dnssec-online-signing], and involves the
-   generation of NSEC RRs that just span the query name for non-existent
-   owner names.  In order to do this, the DNS names which would occur
-   just prior to and just following a given query name must be
-   calculated in real time, as maintaining a list of all possible owner
-   names that might occur in a zone would be impracticable.
-
-   Section 6.1 of [RFC4034] defines canonical DNS name order.  This
-   document does not amend or modify this definition.  However, the
-   derivation of immediate predecessor and successor, while trivial, is
-   non-obvious.  Accordingly, several methods are described here as an
-   aid to implementors and a reference to other interested parties.
-
-   This document describes two methods:
-
-   1.  An ``absolute method'', which returns the immediate predecessor
-       or successor of a domain name such that no valid DNS name could
-       exist between that DNS name and the predecessor or successor.
-
-   2.  A ``modified method'', which returns a predecessor and successor
-       which are more economical in size and computation.  This method
-       is restricted to use with zones consisting only of single-label
-       owner names where a maximum-length owner name would not result in
-       a DNS name exceeding the maximum DNS name length.  This is,
-       however, the type of zone for which the technique of online-
-       signing is most likely to be used.
-
-
-2.  Notational Conventions
-
-   The following notational conventions are used in this document for
-   economy of expression:
-
-   N: An unspecified DNS name.
-
-   P(N): Immediate predecessor to N (absolute method).
-
-   S(N): Immediate successor to N (absolute method).
-
-   P'(N): Predecessor to N (modified method).
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006                [Page 3]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   S'(N): Successor to N (modified method).
-
-
-3.  Absolute Method
-
-   These derivations assume that all uppercase US-ASCII letters in N
-   have already been replaced by their corresponding lowercase
-   equivalents.  Unless otherwise specified, processing stops after the
-   first step in which a condition is met.
-
-3.1.  Derivation of DNS Name Predecessor
-
-   To derive P(N):
-
-   1.  If N is the same as the owner name of the zone apex, prepend N
-       repeatedly with labels of the maximum length possible consisting
-       of octets of the maximum sort value (e.g. 0xff) until N is the
-       maximum length possible; otherwise continue to the next step.
-
-   2.  If the least significant (left-most) label of N consists of a
-       single octet of the minimum sort value (e.g. 0x00), remove that
-       label; otherwise continue to the next step.
-
-   3.  If the least significant (right-most) octet in the least
-       significant (left-most) label of N is the minimum sort value,
-       remove the least significant octet and continue with step 5.
-
-   4.  Decrement the value of the least significant (right-most) octet,
-       skipping any values that correspond to uppercase US-ASCII
-       letters, and then append the label with as many octets as
-       possible of the maximum sort value.  Continue to the next step.
-
-   5.  Prepend N repeatedly with labels of as long a length as possible
-       consisting of octets of the maximum sort value until N is the
-       maximum length possible.
-
-3.2.  Derivation of DNS Name Successor
-
-   To derive S(N):
-
-   1.  If N is two or more octets shorter than the maximum DNS name
-       length, prepend N with a label containing a single octet of the
-       minimum sort value (e.g. 0x00); otherwise continue to the next
-       step.
-
-   2.  If N is one or more octets shorter than the maximum DNS name
-       length and the least significant (left-most) label is one or more
-       octets shorter than the maximum label length, append an octet of
-
-
-
-Sisson & Laurie         Expires January 11, 2006                [Page 4]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-       the minimum sort value to the least significant label; otherwise
-       continue to the next step.
-
-   3.  Increment the value of the least significant (right-most) octet
-       in the least significant (left-most) label that is less than the
-       maximum sort value (e.g. 0xff), skipping any values that
-       correspond to uppercase US-ASCII letters, and then remove any
-       octets to the right of that one.  If all octets in the label are
-       the maximum sort value, then continue to the next step.
-
-   4.  Remove the least significant (left-most) label.  If N is now the
-       same as the owner name of the zone apex, do nothing.  (This will
-       occur only if N is the maximum possible name in canonical DNS
-       name order, and thus has wrapped to the owner name of zone apex.)
-       Otherwise repeat starting at step 2.
-
-
-4.  Modified Method
-
-   This method is for use with zones consisting only of single-label
-   owner names where an owner name consisting of label of maximum length
-   would not result in a DNS name which exceeded the maximum DNS name
-   length.  This method is computationally simpler and returns values
-   which are more economical in size than the absolute method.  It
-   differs from the absolute method detailed above in the following
-   ways:
-
-   1.  Step 1 of the derivation P(N) has been omitted as the existence
-       of the owner name of the zone apex never requires denial.
-
-   2.  A new step 1 has been introduced which removes unnecessary
-       labels.
-
-   3.  Step 4 of the derivation P(N) has been omitted as it is only
-       necessary for zones containing owner names consisting of more
-       than one label.  This omission generally results in a significant
-       reduction of the length of derived predecessors.
-
-   4.  Step 1 of the derivation S(N) had been omitted as it is only
-       necessary for zones containing owner names consisting of more
-       than one label.  This omission results in a tiny reduction of the
-       length of derived successors, and maintains consistency with the
-       modification of step 4 of the derivation P(N) described above.
-
-   5.  Steps 2 and 4 of the derivation S(N) have been modified to
-       eliminate checks for maximum DNS name length, as it is an
-       assumption of this method that no DNS name in the zone can exceed
-       the maximum DNS name length.
-
-
-
-Sisson & Laurie         Expires January 11, 2006                [Page 5]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   These derivations assume that all uppercase US-ASCII letters in N
-   have already been replaced by their corresponding lowercase
-   equivalents.  Unless otherwise specified, processing stops after the
-   first step in which a condition is met.
-
-4.1.  Derivation of DNS Name Predecessor
-
-   To derive P'(N):
-
-   1.  If N has more labels than the number of labels in the owner name
-       of the apex + 1, repeatedly remove the least significant (left-
-       most) label until N has no more labels than the number of labels
-       in the owner name of the apex + 1; otherwise continue to next
-       step.
-
-   2.  If the least significant (left-most) label of N consists of a
-       single octet of the minimum sort value (e.g. 0x00), remove that
-       label; otherwise continue to the next step.
-
-   3.  If the least significant (right-most) octet in the least
-       significant (left-most) label of N is the minimum sort value,
-       remove the least significant octet.
-
-   4.  Decrement the value of the least significant (right-most) octet,
-       skipping any values which correspond to uppercase US-ASCII
-       letters, and then append the label with as many octets as
-       possible of the maximum sort value.
-
-4.2.  Derivation of DNS Name Successor
-
-   To derive S'(N):
-
-   1.  If N has more labels than the number of labels in the owner name
-       of the apex + 1, repeatedly remove the least significant (left-
-       most) label until N has no more labels than the number of labels
-       in the owner name of the apex + 1.  Continue to next step.
-
-   2.  If the least significant (left-most) label of N is one or more
-       octets shorter than the maximum label length, append an octet of
-       the minimum sort value to the least significant label; otherwise
-       continue to the next step.
-
-   3.  Increment the value of the least significant (right-most) octet
-       in the least significant (left-most) label that is less than the
-       maximum sort value (e.g. 0xff), skipping any values which
-       correspond to uppercase US-ASCII letters, and then remove any
-       octets to the right of that one.  If all octets in the label are
-       the maximum sort value, then continue to the next step.
-
-
-
-Sisson & Laurie         Expires January 11, 2006                [Page 6]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   4.  Remove the least significant (left-most) label.  (This will occur
-       only if the least significant label is the maximum label length
-       and consists entirely of octets of the maximum sort value, and
-       thus has wrapped to the owner name of the zone apex.)
-
-
-5.  Notes
-
-5.1.  Case Considerations
-
-   Section 3.5 of [RFC1034] specifies that "while upper and lower case
-   letters are allowed in [DNS] names, no significance is attached to
-   the case".  Additionally, Section 6.1 of [RFC4034] states that when
-   determining canonical DNS name order, "uppercase US-ASCII letters are
-   treated as if they were lowercase US-ASCII letters".  Consequently,
-   values corresponding to US-ASCII uppercase letters must be skipped
-   when decrementing and incrementing octets in the derivations
-   described in Section 3.1 and Section 3.2.
-
-   The following pseudo-code is illustrative:
-
-   Decrement the value of an octet:
-
-      if (octet == '[')       // '[' is just after uppercase 'Z'
-              octet = '@';    // '@' is just prior to uppercase 'A'
-      else
-              octet--;
-
-   Increment the value of an octet:
-
-      if (octet == '@')       // '@' is just prior to uppercase 'A'
-              octet = '[';    // '[' is just after uppercase 'Z'
-      else
-              octet++;
-
-5.2.  Choice of Range
-
-   [RFC2181] makes the clarification that "any binary string whatever
-   can be used as the label of any resource record".  Consequently the
-   minimum sort value may be set as 0x00 and the maximum sort value as
-   0xff, and the range of possible values will be any DNS name which
-   contains octets of any value other than those corresponding to
-   uppercase US-ASCII letters.
-
-   However, if all owner names in a zone are in the letter-digit-hyphen,
-   or LDH, format specified in [RFC1034], it may be desirable to
-   restrict the range of possible values to DNS names containing only
-   LDH values.  This has the effect of:
-
-
-
-Sisson & Laurie         Expires January 11, 2006                [Page 7]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   1.  making the output of tools such as `dig' and `nslookup' less
-       subject to confusion;
-
-   2.  minimising the impact that NSEC RRs containing DNS names with
-       non-LDH values (or non-printable values) might have on faulty DNS
-       resolver implementations; and
-
-   3.  preventing the possibility of results which are wildcard DNS
-       names (see Section 5.3).
-
-   This may be accomplished by using a minimum sort value of 0x1f (US-
-   ASCII character `-') and a maximum sort value of 0x7a (US-ASCII
-   character lowercase `z'), and then skipping non-LDH, non-lowercase
-   values when incrementing or decrementing octets.
-
-5.3.  Wild Card Considerations
-
-   Neither derivation avoids the possibility that the result may be a
-   DNS name containing a wildcard label, i.e. a label containing a
-   single octet with the value 0x2a (US-ASCII character `*').  With
-   additional tests, wildcard DNS names may be explicitly avoided;
-   alternatively, if the range of octet values can be restricted to
-   those corresponding to letter-digit-hyphen, or LDH, characters (see
-   Section 5.2), such DNS names will not occur.
-
-   Note that it is improbable that a result which is a wildcard DNS name
-   will occur unintentionally; even if one does occur either as the
-   owner name of, or in the RDATA of an NSEC RR, it is treated as a
-   literal DNS name with no special meaning.
-
-5.4.  Possible Modifications
-
-5.4.1.  Restriction of Effective Maximum DNS Name Length
-
-   [RFC1034] specifies that "the total number of octets that represent a
-   [DNS] name (i.e., the sum of all label octets and label lengths) is
-   limited to 255", including the null (zero-length) label which
-   represents the root.  For the purpose of deriving predecessors and
-   successors during NSEC RR synthesis, the maximum DNS name length may
-   be effectively restricted to the length of the longest DNS name in
-   the zone.  This will minimise the size of responses containing
-   synthesised NSEC RRs but, especially in the case of the modified
-   method, may result in some additional computational complexity.
-
-   Note that this modification will have the effect of revealing
-   information about the longest name in the zone.  Moreover, when the
-   contents of the zone changes, e.g. during dynamic updates and zone
-   transfers, care must be taken to ensure that the effective maximum
-
-
-
-Sisson & Laurie         Expires January 11, 2006                [Page 8]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   DNS name length agrees with the new contents.
-
-5.4.2.  Use of Modified Method With Zones Containing SRV RRs
-
-   Normally the modified method cannot be used in zones that contain
-   SRV RRs [RFC2782], as SRV RRs have owner names which contain multiple
-   labels.  However the use of SRV RRs can be accommodated by various
-   techniques.  There are at least four possible ways to do this:
-
-   1.  Use conventional NSEC RRs for the region of the zone that
-       contains first-level labels beginning with the underscore (`_')
-       character.  For the purposes of generating these NSEC RRs, the
-       existence of (possibly fictional) ownernames `9{63}' and `a'
-       could be assumed, providing a lower and upper bound for this
-       region.  Then all queries where the QNAME doesn't exist but
-       contains a first-level label beginning with an underscore could
-       be handled using the normal DNSSEC protocol.
-
-       This approach would make it possible to enumerate all DNS names
-       in the zone containing a first-level label beginning with
-       underscore, including all SRV RRs, but this may be of less a
-       concern to the zone administrator than incurring the overhead of
-       the absolute method or of the following variants of the modified
-       method.
-
-   2.  The absolute method could be used for synthesising NSEC RRs for
-       all queries where the QNAME contains a leading underscore.
-       However this re-introduces the susceptibility of the absolute
-       method to denial of service activity, as an attacker could send
-       queries for an effectively inexhaustible supply of domain names
-       beginning with a leading underscore.
-
-   3.  A variant of the modified method could be used for synthesising
-       NSEC RRs for all queries where the QNAME contains a leading
-       underscore.  This variant would assume that all predecessors and
-       successors to queries where the QNAME contains a leading
-       underscore may consist of two lablels rather than only one.  This
-       introduces a little additional complexity without incurring the
-       full increase in response size and computational complexity as
-       the absolute method.
-
-   4.  Finally, a variant the modified method which assumes that all
-       owner names in the zone consist of one or two labels could be
-       used.  However this negates much of the reduction in response
-       size of the modified method and may be nearly as computationally
-       complex as the absolute method.
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006                [Page 9]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-6.  Examples
-
-   In the following examples:
-
-      the owner name of the zone apex is "example.com.";
-
-      the range of octet values is 0x00 - 0xff excluding values
-      corresponding to uppercase US-ASCII letters; and
-
-      non-printable octet values are expressed as three-digit decimal
-      numbers preceded by a backslash (as specified in Section 5.1 of
-      [RFC1035]).
-
-6.1.  Examples of Immediate Predecessors Using Absolute Method
-
-   Example of typical case:
-
-      P(foo.example.com.) =
-
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255.\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255.fon\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255.example.com.
-
-      or, in alternate notation:
-
-           \255{49}.\255{63}.\255{63}.fon\255{60}.example.com.
-
-      where {n} represents the number of repetitions of an octet.
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 10]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where least significant (left-most) label of DNS name
-   consists of a single octet of the minimum sort value:
-
-      P(\000.foo.example.com.) = foo.example.com.
-
-   Example where least significant (right-most) octet of least
-   significant (left-most) label has the minimum sort value:
-
-      P(foo\000.example.com.) =
-
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255.\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255.\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255.foo.example.com.
-
-      or, in alternate notation:
-
-           \255{45}.\255{63}.\255{63}.\255{63}.foo.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 11]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where DNS name contains an octet which must be decremented by
-   skipping values corresponding to US-ASCII uppercase letters:
-
-      P(fo\[.example.com.) =
-
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255.\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255.fo\@\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255.example.com.
-
-      or, in alternate notation:
-
-           \255{49}.\255{63}.\255{63}.fo\@\255{60}.example.com.
-
-      where {n} represents the number of repetitions of an octet.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 12]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where DNS name is the owner name of the zone apex, and
-   consequently wraps to the DNS name with the maximum possible sort
-   order in the zone:
-
-      P(example.com.) =
-
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255.\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255.\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.example.com.
-
-      or, in alternate notation:
-
-           \255{49}.\255{63}.\255{63}.\255{63}.example.com.
-
-6.2.  Examples of Immediate Successors Using Absolute Method
-
-   Example of typical case:
-
-      S(foo.example.com.) = \000.foo.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 13]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where DNS name is one octet short of the maximum DNS name
-   length:
-
-      N =  fooooooooooooooooooooooooooooooooooooooooooooooo
-           .ooooooooooooooooooooooooooooooooooooooooooooooo
-           oooooooooooooooo.ooooooooooooooooooooooooooooooo
-           oooooooooooooooooooooooooooooooo.ooooooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo.example.com.
-
-      or, in alternate notation:
-
-           fo{47}.o{63}.o{63}.o{63}.example.com.
-
-      S(N) =
-
-           fooooooooooooooooooooooooooooooooooooooooooooooo
-           \000.ooooooooooooooooooooooooooooooooooooooooooo
-           oooooooooooooooooooo.ooooooooooooooooooooooooooo
-           oooooooooooooooooooooooooooooooooooo.ooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           oooo.example.com.
-
-      or, in alternate notation:
-
-           fo{47}\000.o{63}.o{63}.o{63}.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 14]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where DNS name is the maximum DNS name length:
-
-      N  = fooooooooooooooooooooooooooooooooooooooooooooooo
-           o.oooooooooooooooooooooooooooooooooooooooooooooo
-           ooooooooooooooooo.oooooooooooooooooooooooooooooo
-           ooooooooooooooooooooooooooooooooo.oooooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           o.example.com.
-
-      or, in alternate notation:
-
-           fo{48}.o{63}.o{63}.o{63}.example.com.
-
-      S(N) =
-
-           fooooooooooooooooooooooooooooooooooooooooooooooo
-           p.oooooooooooooooooooooooooooooooooooooooooooooo
-           ooooooooooooooooo.oooooooooooooooooooooooooooooo
-           ooooooooooooooooooooooooooooooooo.oooooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           o.example.com.
-
-      or, in alternate notation:
-
-           fo{47}p.o{63}.o{63}.o{63}.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 15]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where DNS name is the maximum DNS name length and the least
-   significant (left-most) label has the maximum sort value:
-
-      N =  \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.ooooooooooooooooooooooooooooooooooooooooooo
-           oooooooooooooooooooo.ooooooooooooooooooooooooooo
-           oooooooooooooooooooooooooooooooooooo.ooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           oooo.example.com.
-
-      or, in alternate notation:
-
-           \255{49}.o{63}.o{63}.o{63}.example.com.
-
-      S(N) =
-
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           oooooooooooooop.oooooooooooooooooooooooooooooooo
-           ooooooooooooooooooooooooooooooo.oooooooooooooooo
-           ooooooooooooooooooooooooooooooooooooooooooooooo.
-           example.com.
-
-      or, in alternate notation:
-
-           o{62}p.o{63}.o{63}.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 16]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where DNS name is the maximum DNS name length and the eight
-   least significant (right-most) octets of the least significant (left-
-   most) label have the maximum sort value:
-
-      N  = foooooooooooooooooooooooooooooooooooooooo\255
-           \255\255\255\255\255\255\255.ooooooooooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooo.ooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           oooooooooooo.ooooooooooooooooooooooooooooooooooo
-           oooooooooooooooooooooooooooo.example.com.
-
-      or, in alternate notation:
-
-           fo{40}\255{8}.o{63}.o{63}.o{63}.example.com.
-
-      S(N) =
-
-           fooooooooooooooooooooooooooooooooooooooop.oooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           ooooooooo.oooooooooooooooooooooooooooooooooooooo
-           ooooooooooooooooooooooooo.oooooooooooooooooooooo
-           ooooooooooooooooooooooooooooooooooooooooo.example.com.
-
-      or, in alternate notation:
-
-           fo{39}p.o{63}.o{63}.o{63}.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 17]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where DNS name is the maximum DNS name length and contains an
-   octet which must be incremented by skipping values corresponding to
-   US-ASCII uppercase letters:
-
-      N  = fooooooooooooooooooooooooooooooooooooooooooooooo
-           \@.ooooooooooooooooooooooooooooooooooooooooooooo
-           oooooooooooooooooo.ooooooooooooooooooooooooooooo
-           oooooooooooooooooooooooooooooooooo.ooooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           oo.example.com.
-
-      or, in alternate notation:
-
-           fo{47}\@.o{63}.o{63}.o{63}.example.com.
-
-      S(N) =
-
-           fooooooooooooooooooooooooooooooooooooooooooooooo
-           \[.ooooooooooooooooooooooooooooooooooooooooooooo
-           oooooooooooooooooo.ooooooooooooooooooooooooooooo
-           oooooooooooooooooooooooooooooooooo.ooooooooooooo
-           oooooooooooooooooooooooooooooooooooooooooooooooo
-           oo.example.com.
-
-      or, in alternate notation:
-
-           fo{47}\[.o{63}.o{63}.o{63}.example.com.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 18]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where DNS name has the maximum possible sort order in the
-   zone, and consequently wraps to the owner name of the zone apex:
-
-      N  = \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255.\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255.\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.example.com.
-
-      or, in alternate notation:
-
-           \255{49}.\255{63}.\255{63}.\255{63}.example.com.
-
-      S(N) = example.com.
-
-6.3.  Examples of Predecessors Using Modified Method
-
-   Example of typical case:
-
-      P'(foo.example.com.) =
-
-           fon\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255.example.com.
-
-      or, in alternate notation:
-
-           fon\255{60}.example.com.
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 19]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where DNS name contains more labels than DNS names in the
-   zone:
-
-      P'(bar.foo.example.com.) = foo.example.com.
-
-   Example where least significant (right-most) octet of least
-   significant (left-most) label has the minimum sort value:
-
-      P'(foo\000.example.com.) = foo.example.com.
-
-   Example where least significant (left-most) label has the minimum
-   sort value:
-
-      P'(\000.example.com.) = example.com.
-
-   Example where DNS name is the owner name of the zone apex, and
-   consequently wraps to the DNS name with the maximum possible sort
-   order in the zone:
-
-      P'(example.com.) =
-
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255.example.com.
-
-      or, in alternate notation:
-
-           \255{63}.example.com.
-
-6.4.  Examples of Successors Using Modified Method
-
-   Example of typical case:
-
-      S'(foo.example.com.) = foo\000.example.com.
-
-   Example where DNS name contains more labels than DNS names in the
-   zone:
-
-      S'(bar.foo.example.com.) = foo\000.example.com.
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 20]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-   Example where least significant (left-most) label has the maximum
-   sort value, and consequently wraps to the owner name of the zone
-   apex:
-
-      N  = \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255\255\255\255\255\255\255\255\255\255
-           \255\255\255.example.com.
-
-      or, in alternate notation:
-
-           \255{63}.example.com.
-
-      S'(N) = example.com.
-
-
-7.  Security Considerations
-
-   The derivation of some predecessors/successors requires the testing
-   of more conditions than others.  Consequently the effectiveness of a
-   denial-of-service attack may be enhanced by sending queries that
-   require more conditions to be tested.  The modified method involves
-   the testing of fewer conditions than the absolute method and
-   consequently is somewhat less susceptible to this exposure.
-
-
-8.  IANA Considerations
-
-   This document has no IANA actions.
-
-   Note to RFC Editor: This section is included to make it clear during
-   pre-publication review that this document has no IANA actions.  It
-   may therefore be removed should it be published as an RFC.
-
-
-9.  Acknowledgments
-
-   The authors would like to thank Olaf Kolkman, Olafur Gudmundsson and
-   Niall O'Reilly for their review and input.
-
-
-10.  References
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 21]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-10.1  Normative References
-
-   [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.
-
-   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
-              Specification", RFC 2181, July 1997.
-
-   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
-              specifying the location of services (DNS SRV)", RFC 2782,
-              February 2000.
-
-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Resource Records for the DNS Security Extensions",
-              RFC 4034, March 2005.
-
-10.2  Informative References
-
-   [I-D.ietf-dnsext-dnssec-online-signing]
-              Ihren, J. and S. Weiler, "Minimally Covering NSEC Records
-              and DNSSEC On-line Signing",
-              draft-ietf-dnsext-dnssec-online-signing-00 (work in
-              progress), May 2005.
-
-   [I-D.ietf-dnsext-dnssec-trans]
-              Arends, R., Koch, P., and J. Schlyter, "Evaluating DNSSEC
-              Transition Mechanisms",
-              draft-ietf-dnsext-dnssec-trans-02 (work in progress),
-              February 2005.
-
-
-Appendix A.  Change History
-
-A.1.  Changes from sisson-02 to ietf-00
-
-   o  Added notes on use of SRV RRs with modified method.
-
-   o  Changed reference from weiler-dnssec-online-signing to ietf-
-      dnsext-dnssec-online-signing.
-
-   o  Changed reference from ietf-dnsext-dnssec-records to RFC 4034.
-
-   o  Miscellaneous minor changes to text.
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 22]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-A.2.  Changes from sisson-01 to sisson-02
-
-   o  Added modified version of derivation (with supporting examples).
-
-   o  Introduced notational conventions N, P(N), S(N), P'(N) and S'(N).
-
-   o  Added clarification to derivations about when processing stops.
-
-   o  Miscellaneous minor changes to text.
-
-A.3.  Changes from sisson-00 to sisson-01
-
-   o  Split step 3 of derivation of DNS name predecessor into two
-      distinct steps for clarity.
-
-   o  Added clarifying text and examples related to the requirement to
-      avoid uppercase characters when decrementing or incrementing
-      octets.
-
-   o  Added optimisation using restriction of effective maximum DNS name
-      length.
-
-   o  Changed examples to use decimal rather than octal notation as per
-      [RFC1035].
-
-   o  Corrected DNS name length of some examples.
-
-   o  Added reference to weiler-dnssec-online-signing.
-
-   o  Miscellaneous minor changes to text.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 23]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-Authors' Addresses
-
-   Geoffrey Sisson
-   Nominet
-   Sandford Gate
-   Sandy Lane West
-   Oxford
-   OX4 6LB
-   GB
-
-   Phone: +44 1865 332339
-   Email: geoff@nominet.org.uk
-
-
-   Ben Laurie
-   Nominet
-   17 Perryn Road
-   London
-   W3 7LR
-   GB
-
-   Phone: +44 20 8735 0686
-   Email: ben@algroup.co.uk
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 24]
-
-Internet-Draft     DNS Name Predecessor and Successor          July 2005
-
-
-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 (2005).  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.
-
-
-
-
-Sisson & Laurie         Expires January 11, 2006               [Page 25]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
deleted file mode 100644
index bcc2b4e..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
+++ /dev/null
@@ -1,442 +0,0 @@
-
-
-INTERNET-DRAFT                                             Samuel Weiler
-Expires: June 2004                                     December 15, 2003
-Updates: RFC 2535, [DS]
-
-	 Legacy Resolver Compatibility for Delegation Signer
-	 draft-ietf-dnsext-dnssec-2535typecode-change-06.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/1id-abstracts.html
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html
-
-   Comments should be sent to the author or to the DNSEXT WG mailing
-   list: namedroppers@ops.ietf.org
-
-Abstract
-
-   As the DNS Security (DNSSEC) specifications have evolved, the
-   syntax and semantics of the DNSSEC resource records (RRs) have
-   changed.  Many deployed nameservers understand variants of these
-   semantics.  Dangerous interactions can occur when a resolver that
-   understands an earlier version of these semantics queries an
-   authoritative server that understands the new delegation signer
-   semantics, including at least one failure scenario that will cause
-   an unsecured zone to be unresolvable.  This document changes the
-   type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to
-   avoid those interactions.
-
-Changes between 05 and 06:
-
-   Signifigantly reworked the IANA section -- went back to one
-   algorithm registry.
-
-   Removed Diffie-Hellman from the list of zone-signing algorithms
-   (leaving only DSA, RSA/SHA-1, and private algorithms).
-
-   Added a DNSKEY flags field registry.
-
-Changes between 04 and 05:
-
-   IESG approved publication.
-
-   Cleaned up an internal reference in the acknowledgements section.
-
-   Retained KEY and SIG for TKEY, too.  Added TKEY (2930) reference.
-
-   Changed the names of both new registries.  Added algorithm
-   mnemonics to the new zone signing algorithm registry.  Minor
-   rewording in the IANA section for clarity.
-
-   Cleaned up formatting of references.  Replaced unknown-rr draft
-   references with RFC3597.  Bumped DS version number.
-
-Changes between 03 and 04:
-
-   Clarified that RRSIG(0) may be defined by standards action.
-
-   Created a new algorithm registry and renamed the old algorithm
-   registry for SIG(0) only.  Added references to the appropriate
-   crypto algorithm and format specifications.
-
-   Several minor rephrasings.
-
-Changes between 02 and 03:
-
-   KEY (as well as SIG) retained for SIG(0) use only.
-
-Changes between 01 and 02:
-
-   SIG(0) still uses SIG, not RRSIG.  Added 2931 reference.
-
-   Domain names embedded in NSECs and RRSIGs are not compressible and
-   are not downcased.  Added unknown-rrs reference (as informative).
-
-   Simplified the last paragraph of section 3 (NSEC doesn't always
-   signal a negative answer).
-
-   Changed the suggested type code assignments.
-
-   Added 2119 reference.
-
-   Added definitions of "unsecure delegation" and "unsecure referral",
-   since they're not clearly defined elsewhere.
-
-   Moved 2065 to informative references, not normative.
-
-1. Introduction
-
-   The DNSSEC protocol has been through many iterations whose syntax
-   and semantics are not completely compatible.  This has occurred as
-   part of the ordinary process of proposing a protocol, implementing
-   it, testing it in the increasingly complex and diverse environment
-   of the Internet, and refining the definitions of the initial
-   Proposed Standard.  In the case of DNSSEC, the process has been
-   complicated by DNS's criticality and wide deployment and the need
-   to add security while minimizing daily operational complexity.
-
-   A weak area for previous DNS specifications has been lack of detail
-   in specifying resolver behavior, leaving implementors largely on
-   their own to determine many details of resolver function.  This,
-   combined with the number of iterations the DNSSEC spec has been
-   through, has resulted in fielded code with a wide variety of
-   behaviors.  This variety makes it difficult to predict how a
-   protocol change will be handled by all deployed resolvers.  The
-   risk that a change will cause unacceptable or even catastrophic
-   failures makes it difficult to design and deploy a protocol change.
-   One strategy for managing that risk is to structure protocol
-   changes so that existing resolvers can completely ignore input that
-   might confuse them or trigger undesirable failure modes.
-
-   This document addresses a specific problem caused by Delegation
-   Signer's [DS] introduction of new semantics for the NXT RR that are
-   incompatible with the semantics in RFC 2535 [RFC2535].  Answers
-   provided by DS-aware servers can trigger an unacceptable failure
-   mode in some resolvers that implement RFC 2535, which provides a
-   great disincentive to sign zones with DS.  The changes defined in
-   this document allow for the incremental deployment of DS.
-
-1.1 Terminology
-
-   In this document, the term "unsecure delegation" means any
-   delegation for which no DS record appears at the parent.  An
-   "unsecure referral" is an answer from the parent containing an NS
-   RRset and a proof that no DS record exists for that name.
-
-   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 The Problem
-
-   Delegation Signer introduces new semantics for the NXT RR that are
-   incompatible with the semantics in RFC 2535.  In RFC 2535, NXT
-   records were only required to be returned as part of a
-   non-existence proof.  With DS, an unsecure referral returns, in
-   addition to the NS, a proof of non-existence of a DS RR in the form
-   of an NXT and SIG(NXT).  RFC 2535 didn't specify how a resolver was
-   to interpret a response with both an NS and an NXT in the authority
-   section, RCODE=0, and AA=0.  Some widely deployed 2535-aware
-   resolvers interpret any answer with an NXT as a proof of
-   non-existence of the requested record.  This results in unsecure
-   delegations being invisible to 2535-aware resolvers and violates
-   the basic architectural principle that DNSSEC must do no harm --
-   the signing of zones must not prevent the resolution of unsecured
-   delegations.
-
-2. Possible Solutions
-
-   This section presents several solutions that were considered.
-   Section 3 describes the one selected.
-
-2.1. Change SIG, KEY, and NXT type codes
-
-   To avoid the problem described above, legacy (RFC2535-aware)
-   resolvers need to be kept from seeing unsecure referrals that
-   include NXT records in the authority section.  The simplest way to
-   do that is to change the type codes for SIG, KEY, and NXT.
-
-   The obvious drawback to this is that new resolvers will not be able
-   to validate zones signed with the old RRs.  This problem already
-   exists, however, because of the changes made by DS, and resolvers
-   that understand the old RRs (and have compatibility issues with DS)
-   are far more prevalent than 2535-signed zones.
-
-2.2. Change a subset of type codes
-
-   The observed problem with unsecure referrals could be addressed by
-   changing only the NXT type code or another subset of the type codes
-   that includes NXT.  This has the virtue of apparent simplicity, but
-   it risks introducing new problems or not going far enough.  It's
-   quite possible that more incompatibilities exist between DS and
-   earlier semantics.  Legacy resolvers may also be confused by seeing
-   records they recognize (SIG and KEY) while being unable to find
-   NXTs.  Although it may seem unnecessary to fix that which is not
-   obviously broken, it's far cleaner to change all of the type codes
-   at once.  This will leave legacy resolvers and tools completely
-   blinded to DNSSEC -- they will see only unknown RRs.
-
-2.3. Replace the DO bit
-
-   Another way to keep legacy resolvers from ever seeing DNSSEC
-   records with DS semantics is to have authoritative servers only
-   send that data to DS-aware resolvers.  It's been proposed that
-   assigning a new EDNS0 flag bit to signal DS-awareness (tentatively
-   called "DA"), and having authoritative servers send DNSSEC data
-   only in response to queries with the DA bit set, would accomplish
-   this.  This bit would presumably supplant the DO bit described in
-   RFC 3225.
-
-   This solution is sufficient only if all 2535-aware resolvers zero
-   out EDNS0 flags that they don't understand.  If one passed through
-   the DA bit unchanged, it would still see the new semantics, and it
-   would probably fail to see unsecure delegations.  Since it's
-   impractical to know how every DNS implementation handles unknown
-   EDNS0 flags, this is not a universal solution.  It could, though,
-   be considered in addition to changing the RR type codes.
-
-2.4. Increment the EDNS version
-
-   Another possible solution is to increment the EDNS version number
-   as defined in RFC 2671 [RFC2671], on the assumption that all
-   existing implementations will reject higher versions than they
-   support, and retain the DO bit as the signal for DNSSEC awareness.
-   This approach has not been tested.
-
-2.5. Do nothing
-
-   There is a large deployed base of DNS resolvers that understand
-   DNSSEC as defined by the standards track RFC 2535 and RFC 2065
-   and, due to under specification in those documents, interpret any
-   answer with an NXT as a non-existence proof.  So long as that is
-   the case, zone owners will have a strong incentive to not sign any
-   zones that contain unsecure delegations, lest those delegations be
-   invisible to such a large installed base.  This will dramatically
-   slow DNSSEC adoption.
-
-   Unfortunately, without signed zones there's no clear incentive for
-   operators of resolvers to upgrade their software to support the new
-   version of DNSSEC, as defined in [DS].  Historical data suggests
-   that resolvers are rarely upgraded, and that old nameserver code
-   never dies.
-
-   Rather than wait years for resolvers to be upgraded through natural
-   processes before signing zones with unsecure delegations,
-   addressing this problem with a protocol change will immediately
-   remove the disincentive for signing zones and allow widespread
-   deployment of DNSSEC.
-
-3. Protocol changes
-
-   This document changes the type codes of SIG, KEY, and NXT.  This
-   approach is the cleanest and safest of those discussed above,
-   largely because the behavior of resolvers that receive unknown type
-   codes is well understood.  This approach has also received the most
-   testing.
-
-   To avoid operational confusion, it's also necessary to change the
-   mnemonics for these RRs.  DNSKEY will be the replacement for KEY,
-   with the mnemonic indicating that these keys are not for
-   application use, per [RFC3445].  RRSIG (Resource Record SIGnature)
-   will replace SIG, and NSEC (Next SECure) will replace NXT.  These
-   new types completely replace the old types, except that SIG(0)
-   [RFC2931] and TKEY [RFC2930] will continue to use SIG and KEY.
-
-   The new types will have exactly the same syntax and semantics as
-   specified for SIG, KEY, and NXT in RFC 2535 and [DS] except for
-   the following:
-
-      1) Consistent with [RFC3597], domain names embedded in
-      RRSIG and NSEC RRs MUST NOT be compressed,
-
-      2) Embedded domain names in RRSIG and NSEC RRs are not downcased
-      for purposes of DNSSEC canonical form and ordering nor for
-      equality comparison, and
-
-      3) An RRSIG with a type-covered field of zero has undefined
-      semantics.  The meaning of such a resource record may only be
-      defined by IETF Standards Action.
-
-   If a resolver receives the old types, it SHOULD treat them as
-   unknown RRs and SHOULD NOT assign any special meaning to them or
-   give them any special treatment.  It MUST NOT use them for DNSSEC
-   validations or other DNS operational decision making.  For example,
-   a resolver MUST NOT use DNSKEYs to validate SIGs or use KEYs to
-   validate RRSIGs.  If SIG, KEY, or NXT RRs are included in a zone,
-   they MUST NOT receive special treatment.  As an example, if a SIG
-   is included in a signed zone, there MUST be an RRSIG for it.
-   Authoritative servers may wish to give error messages when loading
-   zones containing SIG or NXT records (KEY records may be included
-   for SIG(0) or TKEY).
-
-   As a clarification to previous documents, some positive responses,
-   particularly wildcard proofs and unsecure referrals, will contain
-   NSEC RRs.  Resolvers MUST NOT treat answers with NSEC RRs as
-   negative answers merely because they contain an NSEC.
-
-4. IANA Considerations
-
-4.1 DNS Resource Record Types
-
-   This document updates the IANA registry for DNS Resource Record
-   Types by assigning types 46, 47, and 48 to the RRSIG, NSEC, and
-   DNSKEY RRs, respectively.
-
-   Types 24 and 25 (SIG and KEY) are retained for SIG(0) [RFC2931] and
-   TKEY [RFC2930] use only.
-
-   Type 30 (NXT) should be marked as Obsolete.
-
-4.2 DNS Security Algorithm Numbers
-
-   To allow zone signing (DNSSEC) and transaction security mechanisms
-   (SIG(0) and TKEY) to use different sets of algorithms, the existing
-   "DNS Security Algorithm Numbers" registry is modified to include
-   the applicability of each algorithm.  Specifically, two new columns
-   are added to the registry, showing whether each algorithm may be
-   used for zone signing, transaction security mechanisms, or both.
-   Only algorithms usable for zone signing may be used in DNSKEY,
-   RRSIG, and DS RRs.  Only algorithms usable for SIG(0) and/or TSIG
-   may be used in SIG and KEY RRs.
-
-   All currently defined algorithms remain usable for transaction
-   security mechanisms.  Only RSA/SHA-1, DSA/SHA-1, and private
-   algorithms (types 253 and 254) may be used for zone signing.  Note
-   that the registry does not contain the requirement level of each
-   algorithm, only whether or not an algorithm may be used for the
-   given purposes.  For example, RSA/MD5, while allowed for
-   transaction security mechanisms, is NOT RECOMMENDED, per RFC3110.
-
-   Additionally, the presentation format algorithm mnemonics from
-   RFC2535 Section 7 are added to the registry.  This document assigns
-   RSA/SHA-1 the mnemonic RSASHA1.
-
-   As before, assignment of new algorithms in this registry requires
-   IETF Standards Action.  Additionally, modification of algorithm
-   mnemonics or applicability requires IETF Standards Action.
-   Documents defining a new algorithm must address the applicability
-   of the algorithm and should assign a presentation mnemonic to the
-   algorithm.
-
-4.3 DNSKEY Flags
-
-   Like the KEY resource record, DNSKEY contains a 16-bit flags field.
-   This document creates a new registry for the DNSKEY flags field.
-
-   Initially, this registry only contains an assignment for bit 7 (the
-   ZONE bit).  Bits 0-6 and 8-15 are available for assignment by IETF
-   Standards Action.
-
-4.4 DNSKEY Protocol Octet
-
-   Like the KEY resource record, DNSKEY contains an eight bit protocol
-   field.  The only defined value for this field is 3 (DNSSEC).  No
-   other values are allowed, hence no IANA registry is needed for this
-   field.
-
-5. Security Considerations
-
-   The changes introduced here do not materially affect security.
-   The implications of trying to use both new and legacy types
-   together are not well understood, and attempts to do so would
-   probably lead to unintended and dangerous results.
-
-   Changing type codes will leave code paths in legacy resolvers that
-   are never exercised.  Unexercised code paths are a frequent source
-   of security holes, largely because those code paths do not get
-   frequent scrutiny.
-
-   Doing nothing, as described in section 2.5, will slow DNSSEC
-   deployment.  While this does not decrease security, it also fails
-   to increase it.
-
-6. Normative references
-
-   [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
-             RFC 2535, March 1999.
-
-   [DS]      Gudmundsson, O., "Delegation Signer Resource Record",
-             draft-ietf-dnsext-delegation-signer-15.txt, work in
-             progress, June 2003.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
-             (SIG(0)s)", RFC 2931, September 2000.
-
-   [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY
-             RR)", RFC 2930, September 2000.
-
-   [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name
-             System (DNS)", RFC 2436, March 1999.
-
-   [RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
-             Domain Name System (DNS)", RFC 2539, March 1999.
-
-   [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the
-             Domain Name System (DNS)", RFC 3110, May 2001.
-
-7. Informative References
-
-   [RFC2065] Eastlake, D. and C. Kaufman, "Domain Name System Security
-             Extensions", RFC 2065, January 1997.
-
-   [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-	     2671, August 1999.
-
-   [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
-             3225, December 2001.
-
-   [RFC2929] Eastlake, D., E. Brunner-Williams, and B. Manning,
-	     "Domain Name System (DNS) IANA Considerations", BCP 42,
-	     RFC 2929, September 2000.
-
-   [RFC3445] Massey, D., and S. Rose, "Limiting the Scope of the KEY
-	     Resource Record (RR)", RFC 3445, December 2002.
-
-   [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource
-             Record (RR) Types", RFC 3597, September 2003.
-
-8. Acknowledgments
-
-   The changes introduced here and the analysis of alternatives had
-   many contributors.  With apologies to anyone overlooked, those
-   include: Micheal Graff, John Ihren, Olaf Kolkman, Mark Kosters, Ed
-   Lewis, Bill Manning, and Suzanne Woolf.
-
-   Thanks to Jakob Schlyter and Mark Andrews for identifying the
-   incompatibility described in section 1.2.
-
-   In addition to the above, the author would like to thank Scott
-   Rose, Olafur Gudmundsson, and Sandra Murphy for their substantive
-   comments.
-
-9. Author's Address
-
-   Samuel Weiler
-   SPARTA, Inc.
-   7075 Samuel Morse Drive
-   Columbia, MD 21046
-   USA
-   weiler@tislabs.com
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt
deleted file mode 100644
index 3a800f9..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt
+++ /dev/null
@@ -1,616 +0,0 @@
-
-
-
-Network Working Group                                          S. Weiler
-Internet-Draft                                               SPARTA, Inc
-Updates: 4034, 4035 (if approved)                           May 23, 2005
-Expires: November 24, 2005
-
-
-         Clarifications and Implementation Notes for DNSSECbis
-                draft-ietf-dnsext-dnssec-bis-updates-01
-
-Status of this Memo
-
-   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 becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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 November 24, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document is a collection of minor technical clarifications to
-   the DNSSECbis document set.  It is meant to serve as a resource to
-   implementors as well as an interim repository of possible DNSSECbis
-   errata.
-
-
-
-
-
-
-
-Weiler                  Expires November 24, 2005               [Page 1]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-Proposed additions in future versions
-
-   An index sorted by the section of DNSSECbis being clarified.
-
-   A list of proposed protocol changes being made in other documents,
-   such as NSEC3 and Epsilon.  This document would not make those
-   changes, merely provide an index into the documents that are making
-   changes.
-
-Changes between -00 and -01
-
-   Document significantly restructured.
-
-   Added section on QTYPE=ANY.
-
-Changes between personal submission and first WG draft
-
-   Added Section 2.1 based on namedroppers discussions from March 9-10,
-   2005.
-
-   Added Section 3.4, Section 3.3, Section 4.3, and Section 2.2.
-
-   Added the DNSSECbis RFC numbers.
-
-   Figured out the confusion in Section 4.1.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler                  Expires November 24, 2005               [Page 2]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-Table of Contents
-
-   1.  Introduction and Terminology . . . . . . . . . . . . . . . . .  4
-     1.1   Structure of this Document . . . . . . . . . . . . . . . .  4
-     1.2   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
-   2.  Significant Concerns . . . . . . . . . . . . . . . . . . . . .  4
-     2.1   Clarifications on Non-Existence Proofs . . . . . . . . . .  4
-     2.2   Empty Non-Terminal Proofs  . . . . . . . . . . . . . . . .  5
-     2.3   Validating Responses to an ANY Query . . . . . . . . . . .  5
-   3.  Interoperability Concerns  . . . . . . . . . . . . . . . . . .  5
-     3.1   Unknown DS Message Digest Algorithms . . . . . . . . . . .  5
-     3.2   Private Algorithms . . . . . . . . . . . . . . . . . . . .  6
-     3.3   Caution About Local Policy and Multiple RRSIGs . . . . . .  6
-     3.4   Key Tag Calculation  . . . . . . . . . . . . . . . . . . .  7
-   4.  Minor Corrections and Clarifications . . . . . . . . . . . . .  7
-     4.1   Finding Zone Cuts  . . . . . . . . . . . . . . . . . . . .  7
-     4.2   Clarifications on DNSKEY Usage . . . . . . . . . . . . . .  7
-     4.3   Errors in Examples . . . . . . . . . . . . . . . . . . . .  8
-   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-     7.1   Normative References . . . . . . . . . . . . . . . . . . .  8
-     7.2   Informative References . . . . . . . . . . . . . . . . . .  9
-       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  9
-   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
-       Intellectual Property and Copyright Statements . . . . . . . . 11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler                  Expires November 24, 2005               [Page 3]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-1.  Introduction and Terminology
-
-   This document lists some minor clarifications and corrections to
-   DNSSECbis, as described in [1], [2], and [3].
-
-   It is intended to serve as a resource for implementors and as a
-   repository of items that need to be addressed when advancing the
-   DNSSECbis documents from Proposed Standard to Draft Standard.
-
-   In this version (-01 of the WG document), feedback is particularly
-   solicited on the structure of the document and whether the text in
-   the recently added sections is correct and sufficient.
-
-   Proposed substantive additions to this document should be sent to the
-   namedroppers mailing list as well as to the editor of this document.
-   The editor would greatly prefer text suitable for direct inclusion in
-   this document.
-
-1.1  Structure of this Document
-
-   The clarifications to DNSSECbis are sorted according to the editor's
-   impression of their importance, starting with ones which could, if
-   ignored, lead to security and stability problems and progressing down
-   to clarifications that are likely to have little operational impact.
-   Mere typos and awkward phrasings are not addressed unless they could
-   lead to misinterpretation of the DNSSECbis documents.
-
-1.2  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 [4].
-
-2.  Significant Concerns
-
-   This section provides clarifications that, if overlooked, could lead
-   to security issues or major interoperability problems.
-
-2.1  Clarifications on Non-Existence Proofs
-
-   RFC4035 Section 5.4 slightly underspecifies the algorithm for
-   checking non-existence proofs.  In particular, the algorithm there
-   might incorrectly allow the NSEC from the parent side of a zone cut
-   to prove the non-existence of either other RRs at that name in the
-   child zone or other names in the child zone.  It might also allow a
-   NSEC at the same name as a DNAME to prove the non-existence of names
-   beneath that DNAME.
-
-
-
-
-Weiler                  Expires November 24, 2005               [Page 4]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-   A parent-side delegation NSEC (one with the NS bit set, but no SOA
-   bit set, and with a singer field that's shorter than the owner name)
-   must not be used to assume non-existence of any RRs below that zone
-   cut (both RRs at that ownername and at ownernames with more leading
-   labels, no matter their content).  Similarly, an NSEC with the DNAME
-   bit set must not be used to assume the non-existence of any
-   descendant of that NSEC's owner name.
-
-2.2  Empty Non-Terminal Proofs
-
-   To be written, based on Roy Arends' May 11th message to namedroppers.
-
-2.3  Validating Responses to an ANY Query
-
-   RFC4035 does not address now to validate responses when QTYPE=*.  As
-   described in Section 6.2.2 of RFC1034, a proper response to QTYPE=*
-   may include a subset of the RRsets at a given name -- it is not
-   necessary to include all RRsets at the QNAME in the response.
-
-   When validating a response to QTYPE=*, validate all received RRsets
-   that match QNAME and QCLASS.  If any of those RRsets fail validation,
-   treat the answer as Bogus.  If there are no RRsets matching QNAME and
-   QCLASS, validate that fact using the rules in RFC4035 Section 5.4 (as
-   clarified in this document).  To be clear, a validator must not
-   insist on receiving all records at the QNAME in response to QTYPE=*.
-
-3.  Interoperability Concerns
-
-3.1  Unknown DS Message Digest Algorithms
-
-   Section 5.2 of RFC4035 includes rules for how to handle delegations
-   to zones that are signed with entirely unsupported algorithms, as
-   indicated by the algorithms shown in those zone's DS RRsets.  It does
-   not explicitly address how to handle DS records that use unsupported
-   message digest algorithms.  In brief, DS records using unknown or
-   unsupported message digest algorithms MUST be treated the same way as
-   DS records referring to DNSKEY RRs of unknown or unsupported
-   algorithms.
-
-   The existing text says:
-
-      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.
-
-
-
-
-Weiler                  Expires November 24, 2005               [Page 5]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-   To paraphrase the above, when determining the security status of a
-   zone, a validator discards (for this purpose only) any DS records
-   listing unknown or unsupported algorithms.  If none are left, the
-   zone is treated as if it were unsigned.
-
-   Modified to consider DS message digest algorithms, a validator also
-   discards any DS records using unknown or unsupported message digest
-   algorithms.
-
-3.2  Private Algorithms
-
-   As discussed above, section 5.2 of RFC4035 requires that validators
-   make decisions about the security status of zones based on the public
-   key algorithms shown in the DS records for those zones.  In the case
-   of private algorithms, as described in RFC4034 Appendix A.1.1, the
-   eight-bit algorithm field in the DS RR is not conclusive about what
-   algorithm(s) is actually in use.
-
-   If no private algorithms appear in the DS set or if any supported
-   algorithm appears in the DS set, no special processing will be
-   needed.  In the remaining cases, the security status of the zone
-   depends on whether or not the resolver supports any of the private
-   algorithms in use (provided that these DS records use supported hash
-   functions, as discussed in Section 3.1).  In these cases, the
-   resolver MUST retrieve the corresponding DNSKEY for each private
-   algorithm DS record and examine the public key field to determine the
-   algorithm in use.  The security-aware resolver MUST ensure that the
-   hash of the DNSKEY RR's owner name and RDATA matches the digest in
-   the DS RR.  If they do not match, and no other DS establishes that
-   the zone is secure, the referral should be considered BAD data, as
-   discussed in RFC4035.
-
-   This clarification facilitates the broader use of private algorithms,
-   as suggested by [5].
-
-3.3  Caution About Local Policy and Multiple RRSIGs
-
-   When multiple RRSIGs cover a given RRset, RFC4035 Section 5.3.3
-   suggests that "the local resolver security policy determines whether
-   the resolver also has to test these RRSIG RRs and how to resolve
-   conflicts if these RRSIG RRs lead to differing results."  In most
-   cases, a resolver would be well advised to accept any valid RRSIG as
-   sufficient.  If the first RRSIG tested fails validation, a resolver
-   would be well advised to try others, giving a successful validation
-   result if any can be validated and giving a failure only if all
-   RRSIGs fail validation.
-
-   If a resolver adopts a more restrictive policy, there's a danger that
-
-
-
-Weiler                  Expires November 24, 2005               [Page 6]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-   properly-signed data might unnecessarily fail validation, perhaps
-   because of cache timing issues.  Furthermore, certain zone management
-   techniques, like the Double Signature Zone-signing Key Rollover
-   method described in section 4.2.1.2 of [6] might not work reliably.
-
-3.4  Key Tag Calculation
-
-   RFC4034 Appendix B.1 incorrectly defines the Key Tag field
-   calculation for algorithm 1.  It correctly says that the Key Tag is
-   the most significant 16 of the least significant 24 bits of the
-   public key modulus.  However, RFC4034 then goes on to incorrectly say
-   that this is 4th to last and 3rd to last octets of the public key
-   modulus.  It is, in fact, the 3rd to last and 2nd to last octets.
-
-4.  Minor Corrections and Clarifications
-
-4.1  Finding Zone Cuts
-
-   Appendix C.8 of RFC4035 discusses sending DS queries to the servers
-   for a parent zone.  To do that, a resolver may first need to apply
-   special rules to discover what those servers are.
-
-   As explained in Section 3.1.4.1 of RFC4035, 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.  Section 4.2 of RFC4035
-   specifies a mechanism for doing that.
-
-4.2  Clarifications on DNSKEY Usage
-
-   Questions of the form "can I use a different DNSKEY for signing the
-   X" have occasionally arisen.
-
-   The short answer is "yes, absolutely".  You can even use a different
-   DNSKEY for each RRset in a zone, subject only to practical limits on
-   the size of the DNSKEY RRset.  However, be aware that there is no way
-   to tell resolvers what a particularly DNSKEY is supposed to be used
-   for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to
-   authenticate any RRset in the zone.  For example, if a weaker or less
-   trusted DNSKEY is being used to authenticate NSEC RRsets or all
-   dynamically updated records, that same DNSKEY can also be used to
-   sign any other RRsets from the zone.
-
-   Furthermore, note that the SEP bit setting has no effect on how a
-   DNSKEY may be used -- the validation process is specifically
-   prohibited from using that bit by RFC4034 section 2.1.2.  It possible
-   to use a DNSKEY without the SEP bit set as the sole secure entry
-
-
-
-Weiler                  Expires November 24, 2005               [Page 7]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-   point to the zone, yet use a DNSKEY with the SEP bit set to sign all
-   RRsets in the zone (other than the DNSKEY RRset).  It's also possible
-   to use a single DNSKEY, with or without the SEP bit set, to sign the
-   entire zone, including the DNSKEY RRset itself.
-
-4.3  Errors in Examples
-
-   The text in RFC4035 Section C.1 refers to the examples in B.1 as
-   "x.w.example.com" while B.1 uses "x.w.example".  This is painfully
-   obvious in the second paragraph where it states that the RRSIG labels
-   field value of 3 indicates that the answer was not the result of
-   wildcard expansion.  This is true for "x.w.example" but not for
-   "x.w.example.com", which of course has a label count of 4
-   (antithetically, a label count of 3 would imply the answer was the
-   result of a wildcard expansion).
-
-   The first paragraph of RFC4035 Section C.6 also has a minor error:
-   the reference to "a.z.w.w.example" should instead be "a.z.w.example",
-   as in the previous line.
-
-5.  IANA Considerations
-
-   This document specifies no IANA Actions.
-
-6.  Security Considerations
-
-   This document does not make fundamental changes to the DNSSEC
-   protocol, as it was generally understood when DNSSECbis was
-   published.  It does, however, address some ambiguities and omissions
-   in those documents that, if not recognized and addressed in
-   implementations, could lead to security failures.  In particular, the
-   validation algorithm clarifications in Section 2 are critical for
-   preserving the security properties DNSSEC offers.  Furthermore,
-   failure to address some of the interoperability concerns in Section 3
-   could limit the ability to later change or expand DNSSEC, including
-   by adding new algorithms.
-
-7.  References
-
-7.1  Normative References
-
-   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033,
-        March 2005.
-
-   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Resource Records for the DNS Security Extensions", RFC 4034,
-        March 2005.
-
-
-
-Weiler                  Expires November 24, 2005               [Page 8]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions",
-        RFC 4035, March 2005.
-
-   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-7.2  Informative References
-
-   [5]  Blacka, D., "DNSSEC Experiments",
-        draft-blacka-dnssec-experiments-00 (work in progress),
-        December 2004.
-
-   [6]  Gieben, R. and O. Kolkman, "DNSSEC Operational Practices",
-        draft-ietf-dnsop-dnssec-operational-practices-04 (work in
-        progress), May 2005.
-
-
-Author's Address
-
-   Samuel Weiler
-   SPARTA, Inc
-   7075 Samuel Morse Drive
-   Columbia, Maryland  21046
-   US
-
-   Email: weiler@tislabs.com
-
-Appendix A.  Acknowledgments
-
-   The editor is extremely grateful to those who, in addition to finding
-   errors and omissions in the DNSSECbis document set, have provided
-   text suitable for inclusion in this document.
-
-   The lack of specificity about handling private algorithms, as
-   described in Section 3.2, and the lack of specificity in handling ANY
-   queries, as described in Section 2.3, were discovered by David
-   Blacka.
-
-   The error in algorithm 1 key tag calculation, as described in
-   Section 3.4, was found by Abhijit Hayatnagarkar.  Donald Eastlake
-   contributed text for Section 3.4.
-
-   The bug relating to delegation NSEC RR's in Section 2.1 was found by
-   Roy Badami.  Roy Arends found the related problem with DNAME.
-
-   The errors in the RFC4035 examples were found by Roy Arends, who also
-   contributed text for Section 4.3 of this document.
-
-
-
-Weiler                  Expires November 24, 2005               [Page 9]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-   The editor would like to thank Olafur Gudmundsson and Scott Rose for
-   their substantive comments on the text of this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler                  Expires November 24, 2005              [Page 10]
-
-Internet-Draft       DNSSECbis Implementation Notes             May 2005
-
-
-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 (2005).  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.
-
-
-
-
-Weiler                  Expires November 24, 2005              [Page 11]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt
deleted file mode 100644
index ee03583..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt
+++ /dev/null
@@ -1,784 +0,0 @@
-
-
-
-DNSEXT                                                         D. Blacka
-Internet-Draft                                            Verisign, Inc.
-Expires: January 19, 2006                                  July 18, 2005
-
-
-                           DNSSEC Experiments
-                draft-ietf-dnsext-dnssec-experiments-01
-
-Status of this Memo
-
-   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 becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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 19, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   In the long history of the development of the DNS security extensions
-   [1] (DNSSEC), a number of alternate methodologies and modifications
-   have been proposed and rejected for practical, rather than strictly
-   technical, reasons.  There is a desire to be able to experiment with
-   these alternate methods in the public DNS.  This document describes a
-   methodology for deploying alternate, non-backwards-compatible, DNSSEC
-   methodologies in an experimental fashion without disrupting the
-   deployment of standard DNSSEC.
-
-
-
-
-Blacka                  Expires January 19, 2006                [Page 1]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-Table of Contents
-
-   1.   Definitions and Terminology  . . . . . . . . . . . . . . . .   3
-   2.   Overview . . . . . . . . . . . . . . . . . . . . . . . . . .   4
-   3.   Experiments  . . . . . . . . . . . . . . . . . . . . . . . .   5
-   4.   Method . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
-   5.   Defining an Experiment . . . . . . . . . . . . . . . . . . .   8
-   6.   Considerations . . . . . . . . . . . . . . . . . . . . . . .   9
-   7.   Transitions  . . . . . . . . . . . . . . . . . . . . . . . .  10
-   8.   Security Considerations  . . . . . . . . . . . . . . . . . .  11
-   9.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  12
-   10.  References . . . . . . . . . . . . . . . . . . . . . . . . .  13
-     10.1   Normative References . . . . . . . . . . . . . . . . . .  13
-     10.2   Informative References . . . . . . . . . . . . . . . . .  13
-        Author's Address . . . . . . . . . . . . . . . . . . . . . .  13
-        Intellectual Property and Copyright Statements . . . . . . .  14
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006                [Page 2]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-1.  Definitions and Terminology
-
-   Throughout this document, familiarity with the DNS system (RFC 1035
-   [4]) and the DNS security extensions ([1], [2], and [3].
-
-   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 [5].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006                [Page 3]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-2.  Overview
-
-   Historically, experimentation with DNSSEC alternatives has been a
-   problematic endeavor.  There has typically been a desire to both
-   introduce non-backwards-compatible changes to DNSSEC, and to try
-   these changes on real zones in the public DNS.  This creates a
-   problem when the change to DNSSEC would make all or part of the zone
-   using those changes appear bogus (bad) or otherwise broken to
-   existing DNSSEC-aware resolvers.
-
-   This document describes a standard methodology for setting up public
-   DNSSEC experiments.  This methodology addresses the issue of co-
-   existence with standard DNSSEC and DNS by using unknown algorithm
-   identifiers to hide the experimental DNSSEC protocol modifications
-   from standard DNSSEC-aware resolvers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006                [Page 4]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-3.  Experiments
-
-   When discussing DNSSEC experiments, it is necessary to classify these
-   experiments into two broad categories:
-
-   Backwards-Compatible: describes experimental changes that, while not
-      strictly adhering to the DNSSEC standard, are nonetheless
-      interoperable with clients and server that do implement the DNSSEC
-      standard.
-
-   Non-Backwards-Compatible: describes experiments that would cause a
-      standard DNSSEC-aware resolver to (incorrectly) determine that all
-      or part of a zone is bogus, or to otherwise not interoperable with
-      standard DNSSEC clients and servers.
-
-   Not included in these terms are experiments with the core DNS
-   protocol itself.
-
-   The methodology described in this document is not necessary for
-   backwards-compatible experiments, although it certainly could be used
-   if desired.
-
-   Note that, in essence, this metholodolgy would also be used to
-   introduce a new DNSSEC algorithm, independently from any DNSSEC
-   experimental protocol change.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006                [Page 5]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-4.  Method
-
-   The core of the methodology is the use of strictly "unknown"
-   algorithms to sign the experimental zone, and more importantly,
-   having only unknown algorithm DS records for the delegation to the
-   zone at the parent.
-
-   This technique works because of the way DNSSEC-compliant validators
-   are expected to work in the presence of a DS set with only unknown
-   algorithms.  From [3], Section 5.2:
-
-      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.
-
-   And further:
-
-      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.
-
-   While this behavior isn't strictly mandatory (as marked by MUST), it
-   is unlikely that a validator would not implement the behavior, or,
-   more to the point, it will not violate this behavior in an unsafe way
-   (see below (Section 6).)
-
-   Because we are talking about experiments, it is RECOMMENDED that
-   private algorithm numbers be used (see [2], appendix A.1.1.  Note
-   that secure handling of private algorithms requires special handing
-   by the validator logic.  See [6] for futher details.)  Normally,
-   instead of actually inventing new signing algorithms, the recommended
-   path is to create alternate algorithm identifiers that are aliases
-   for the existing, known algorithms.  While, strictly speaking, it is
-   only necessary to create an alternate identifier for the mandatory
-   algorithms, it is RECOMMENDED that all OPTIONAL defined algorithms be
-   aliased as well.
-
-   It is RECOMMENDED that for a particular DNSSEC experiment, a
-   particular domain name base is chosen for all new algorithms, then
-   the algorithm number (or name) is prepended to it.  For example, for
-   experiment A, the base name of "dnssec-experiment-a.example.com" is
-   chosen.  Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are
-   defined to be "3.dnssec-experiment-a.example.com" and "5.dnssec-
-   experiment-a.example.com".  However, any unique identifier will
-
-
-
-Blacka                  Expires January 19, 2006                [Page 6]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-   suffice.
-
-   Using this method, resolvers (or, more specificially, DNSSEC
-   validators) essentially indicate their ability to understand the
-   DNSSEC experiment's semantics by understanding what the new algorithm
-   identifiers signify.
-
-   This method creates two classes of DNSSEC-aware servers and
-   resolvers: servers and resolvers that are aware of the experiment
-   (and thus recognize the experiments algorithm identifiers and
-   experimental semantics), and servers and resolvers that are unware of
-   the experiment.
-
-   This method also precludes any zone from being both in an experiment
-   and in a classic DNSSEC island of security.  That is, a zone is
-   either in an experiment and only experimentally validatable, or it
-   isn't.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006                [Page 7]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-5.  Defining an Experiment
-
-   The DNSSEC experiment must define the particular set of (previously
-   unknown) algorithms that identify the experiment, and define what
-   each unknown algorithm identifier means.  Typically, unless the
-   experiment is actually experimenting with a new DNSSEC algorithm,
-   this will be a mapping of private algorithm identifiers to existing,
-   known algorithms.
-
-   Normally the experiment will choose a DNS name as the algorithm
-   identifier base.  This DNS name SHOULD be under the control of the
-   authors of the experiment.  Then the experiment will define a mapping
-   between known mandatory and optional algorithms into this private
-   algorithm identifier space.  Alternately, the experiment MAY use the
-   OID private algorithm space instead (using algorithm number 254), or
-   may choose non-private algorithm numbers, although this would require
-   an IANA allocation (see below (Section 9).)
-
-   For example, an experiment might specify in its description the DNS
-   name "dnssec-experiment-a.example.com" as the base name, and provide
-   the mapping of "3.dnssec-experiment-a.example.com" is an alias of
-   DNSSEC algorithm 3 (DSA), and "5.dnssec-experiment-a.example.com" is
-   an alias of DNSSEC algorithm 5 (RSASHA1).
-
-   Resolvers MUST then only recognize the experiment's semantics when
-   present in a zone signed by one or more of these private algorithms.
-
-   In general, however, resolvers involved in the experiment are
-   expected to understand both standard DNSSEC and the defined
-   experimental DNSSEC protocol, although this isn't required.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006                [Page 8]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-6.  Considerations
-
-   There are a number of considerations with using this methodology.
-
-   1.  Under some circumstances, it may be that the experiment will not
-       be sufficiently masked by this technique and may cause resolution
-       problem for resolvers not aware of the experiment.  For instance,
-       the resolver may look at the not validatable response and
-       conclude that the response is bogus, either due to local policy
-       or implementation details.  This is not expected to be the common
-       case, however.
-
-   2.  In general, it will not be possible for DNSSEC-aware resolvers
-       not aware of the experiment to build a chain of trust through an
-       experimental zone.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006                [Page 9]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-7.  Transitions
-
-   If an experiment is successful, there may be a desire to move the
-   experiment to a standards-track extension.  One way to do so would be
-   to move from private algorithm numbers to IANA allocated algorithm
-   numbers, with otherwise the same meaning.  This would still leave a
-   divide between resolvers that understood the extension versus
-   resolvers that did not.  It would, in essence, create an additional
-   version of DNSSEC.
-
-   An alternate technique might be to do a typecode rollover, thus
-   actually creating a definitive new version of DNSSEC.  There may be
-   other transition techniques available, as well.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006               [Page 10]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-8.  Security Considerations
-
-   Zones using this methodology will be considered insecure by all
-   resolvers except those aware of the experiment.  It is not generally
-   possible to create a secure delegation from an experimental zone that
-   will be followed by resolvers unaware of the experiment.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006               [Page 11]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-9.  IANA Considerations
-
-   IANA may need to allocate new DNSSEC algorithm numbers if that
-   transition approach is taken, or the experiment decides to use
-   allocated numbers to begin with.  No IANA action is required to
-   deploy an experiment using private algorithm identifiers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006               [Page 12]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-10.  References
-
-10.1  Normative References
-
-   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033,
-        March 2005.
-
-   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Resource Records for the DNS Security Extensions", RFC 4034,
-        March 2005.
-
-   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions",
-        RFC 4035, March 2005.
-
-10.2  Informative References
-
-   [4]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [5]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [6]  Weiler, S., "Clarifications and Implementation Notes for
-        DNSSECbis", draft-weiler-dnsext-dnssec-bis-updates-00 (work in
-        progress), March 2005.
-
-
-Author's Address
-
-   David Blacka
-   Verisign, Inc.
-   21355 Ridgetop Circle
-   Dulles, VA  20166
-   US
-
-   Phone: +1 703 948 3200
-   Email: davidb@verisign.com
-   URI:   http://www.verisignlabs.com
-
-
-
-
-
-
-
-
-
-
-
-Blacka                  Expires January 19, 2006               [Page 13]
-
-Internet-Draft             DNSSEC Experiments                  July 2005
-
-
-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 (2005).  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.
-
-
-
-
-Blacka                  Expires January 19, 2006               [Page 14]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt
deleted file mode 100644
index 7503c66..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt
+++ /dev/null
@@ -1,616 +0,0 @@
-
-
-
-Network Working Group                                          S. Weiler
-Internet-Draft                                               SPARTA, Inc
-Updates: 4034, 4035 (if approved)                               J. Ihren
-Expires: July 24, 2006                                     Autonomica AB
-                                                        January 20, 2006
-
-
-       Minimally Covering NSEC Records and DNSSEC On-line Signing
-               draft-ietf-dnsext-dnssec-online-signing-02
-
-Status of this Memo
-
-   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 becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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 24, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes how to construct DNSSEC NSEC resource records
-   that cover a smaller range of names than called for by RFC4034.  By
-   generating and signing these records on demand, authoritative name
-   servers can effectively stop the disclosure of zone contents
-   otherwise made possible by walking the chain of NSEC records in a
-   signed zone.
-
-
-
-
-Weiler & Ihren            Expires July 24, 2006                 [Page 1]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-Changes from ietf-01 to ietf-02
-
-   Clarified that a generated NSEC RR's type bitmap MUST have the RRSIG
-   and NSEC bits set, to be consistent with DNSSECbis -- previous text
-   said SHOULD.
-
-   Made the applicability statement a little less oppressive.
-
-Changes from ietf-00 to ietf-01
-
-   Added an applicability statement, making reference to ongoing work on
-   NSEC3.
-
-   Added the phrase "epsilon functions", which has been commonly used to
-   describe the technique and already appeared in the header of each
-   page, in place of "increment and decrement functions".  Also added an
-   explanatory sentence.
-
-   Corrected references from 4034 section 6.2 to section 6.1.
-
-   Fixed an out-of-date reference to [-bis] and other typos.
-
-   Replaced IANA Considerations text.
-
-   Escaped close parentheses in examples.
-
-   Added some more acknowledgements.
-
-Changes from weiler-01 to ietf-00
-
-   Inserted RFC numbers for 4033, 4034, and 4035.
-
-   Specified contents of bitmap field in synthesized NSEC RR's, pointing
-   out that this relaxes a constraint in 4035.  Added 4035 to the
-   Updates header.
-
-Changes from weiler-00 to weiler-01
-
-   Clarified that this updates RFC4034 by relaxing requirements on the
-   next name field.
-
-   Added examples covering wildcard names.
-
-   In the 'better functions' section, reiterated that perfect functions
-   aren't needed.
-
-   Added a reference to RFC 2119.
-
-
-
-
-Weiler & Ihren            Expires July 24, 2006                 [Page 2]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-Table of Contents
-
-   1.  Introduction and Terminology . . . . . . . . . . . . . . . . .  4
-   2.  Applicability of This Technique  . . . . . . . . . . . . . . .  4
-   3.  Minimally Covering NSEC Records  . . . . . . . . . . . . . . .  5
-   4.  Better Epsilon Functions . . . . . . . . . . . . . . . . . . .  6
-   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
-   7.  Normative References . . . . . . . . . . . . . . . . . . . . .  8
-   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . .  8
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
-   Intellectual Property and Copyright Statements . . . . . . . . . . 11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Ihren            Expires July 24, 2006                 [Page 3]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-1.  Introduction and Terminology
-
-   With DNSSEC [1], an NSEC record lists the next instantiated name in
-   its zone, proving that no names exist in the "span" between the
-   NSEC's owner name and the name in the "next name" field.  In this
-   document, an NSEC record is said to "cover" the names between its
-   owner name and next name.
-
-   Through repeated queries that return NSEC records, it is possible to
-   retrieve all of the names in the zone, a process commonly called
-   "walking" the zone.  Some zone owners have policies forbidding zone
-   transfers by arbitrary clients; this side-effect of the NSEC
-   architecture subverts those policies.
-
-   This document presents a way to prevent zone walking by constructing
-   NSEC records that cover fewer names.  These records can make zone
-   walking take approximately as many queries as simply asking for all
-   possible names in a zone, making zone walking impractical.  Some of
-   these records must be created and signed on demand, which requires
-   on-line private keys.  Anyone contemplating use of this technique is
-   strongly encouraged to review the discussion of the risks of on-line
-   signing in Section 6.
-
-   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 [4].
-
-
-2.  Applicability of This Technique
-
-   The technique presented here may be useful to a zone owner that wants
-   to use DNSSEC, is concerned about exposure of its zone contents via
-   zone walking, and is willing to bear the costs of on-line signing.
-
-   As discussed in Section 6, on-line signing has several security
-   risks, including an increased likelihood of private keys being
-   disclosed and an increased risk of denial of service attack.  Anyone
-   contemplating use of this technique is strongly encouraged to review
-   the discussion of the risks of on-line signing in Section 6.
-
-   Furthermore, at the time this document was published, the DNSEXT
-   working group was actively working on a mechanism to prevent zone
-   walking that does not require on-line signing (tentatively called
-   NSEC3).  The new mechanism is likely to expose slightly more
-   information about the zone than this technique (e.g. the number of
-   instantiated names), but it may be preferable to this technique.
-
-
-
-
-
-Weiler & Ihren            Expires July 24, 2006                 [Page 4]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-3.  Minimally Covering NSEC Records
-
-   This mechanism involves changes to NSEC records for instantiated
-   names, which can still be generated and signed in advance, as well as
-   the on-demand generation and signing of new NSEC records whenever a
-   name must be proven not to exist.
-
-   In the 'next name' field of instantiated names' NSEC records, rather
-   than list the next instantiated name in the zone, list any name that
-   falls lexically after the NSEC's owner name and before the next
-   instantiated name in the zone, according to the ordering function in
-   RFC4034 [2] section 6.1.  This relaxes the requirement in section
-   4.1.1 of RFC4034 that the 'next name' field contains the next owner
-   name in the zone.  This change is expected to be fully compatible
-   with all existing DNSSEC validators.  These NSEC records are returned
-   whenever proving something specifically about the owner name (e.g.
-   that no resource records of a given type appear at that name).
-
-   Whenever an NSEC record is needed to prove the non-existence of a
-   name, a new NSEC record is dynamically produced and signed.  The new
-   NSEC record has an owner name lexically before the QNAME but
-   lexically following any existing name and a 'next name' lexically
-   following the QNAME but before any existing name.
-
-   The generated NSEC record's type bitmap MUST have the RRSIG and NSEC
-   bits set and SHOULD NOT have any other bits set.  This relaxes the
-   requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at
-   names that did not exist before the zone was signed.
-
-   The functions to generate the lexically following and proceeding
-   names need not be perfect nor consistent, but the generated NSEC
-   records must not cover any existing names.  Furthermore, this
-   technique works best when the generated NSEC records cover as few
-   names as possible.  In this document, the functions that generate the
-   nearby names are called 'epsilon' functions, a reference to the
-   mathematical convention of using the greek letter epsilon to
-   represent small deviations.
-
-   An NSEC record denying the existence of a wildcard may be generated
-   in the same way.  Since the NSEC record covering a non-existent
-   wildcard is likely to be used in response to many queries,
-   authoritative name servers using the techniques described here may
-   want to pregenerate or cache that record and its corresponding RRSIG.
-
-   For example, a query for an A record at the non-instantiated name
-   example.com might produce the following two NSEC records, the first
-   denying the existence of the name example.com and the second denying
-   the existence of a wildcard:
-
-
-
-Weiler & Ihren            Expires July 24, 2006                 [Page 5]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-             exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC )
-
-             \).com 3600 IN NSEC +.com ( RRSIG NSEC )
-
-   Before answering a query with these records, an authoritative server
-   must test for the existence of names between these endpoints.  If the
-   generated NSEC would cover existing names (e.g. exampldd.com or
-   *bizarre.example.com), a better epsilon function may be used or the
-   covered name closest to the QNAME could be used as the NSEC owner
-   name or next name, as appropriate.  If an existing name is used as
-   the NSEC owner name, that name's real NSEC record MUST be returned.
-   Using the same example, assuming an exampldd.com delegation exists,
-   this record might be returned from the parent:
-
-             exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC )
-
-   Like every authoritative record in the zone, each generated NSEC
-   record MUST have corresponding RRSIGs generated using each algorithm
-   (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as
-   described in RFC4035 [3] section 2.2.  To minimize the number of
-   signatures that must be generated, a zone may wish to limit the
-   number of algorithms in its DNSKEY RRset.
-
-
-4.  Better Epsilon Functions
-
-   Section 6.1 of RFC4034 defines a strict ordering of DNS names.
-   Working backwards from that definition, it should be possible to
-   define epsilon functions that generate the immediately following and
-   preceding names, respectively.  This document does not define such
-   functions.  Instead, this section presents functions that come
-   reasonably close to the perfect ones.  As described above, an
-   authoritative server should still ensure than no generated NSEC
-   covers any existing name.
-
-   To increment a name, add a leading label with a single null (zero-
-   value) octet.
-
-   To decrement a name, decrement the last character of the leftmost
-   label, then fill that label to a length of 63 octets with octets of
-   value 255.  To decrement a null (zero-value) octet, remove the octet
-   -- if an empty label is left, remove the label.  Defining this
-   function numerically: fill the left-most label to its maximum length
-   with zeros (numeric, not ASCII zeros) and subtract one.
-
-   In response to a query for the non-existent name foo.example.com,
-   these functions produce NSEC records of:
-
-
-
-
-Weiler & Ihren            Expires July 24, 2006                 [Page 6]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-     fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG )
-
-     \)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )
-
-   The first of these NSEC RRs proves that no exact match for
-   foo.example.com exists, and the second proves that there is no
-   wildcard in example.com.
-
-   Both of these functions are imperfect: they don't take into account
-   constraints on number of labels in a name nor total length of a name.
-   As noted in the previous section, though, this technique does not
-   depend on the use of perfect epsilon functions: it is sufficient to
-   test whether any instantiated names fall into the span covered by the
-   generated NSEC and, if so, substitute those instantiated owner names
-   for the NSEC owner name or next name, as appropriate.
-
-
-5.  IANA Considerations
-
-   This document specifies no IANA Actions.
-
-
-6.  Security Considerations
-
-   This approach requires on-demand generation of RRSIG records.  This
-   creates several new vulnerabilities.
-
-   First, on-demand signing requires that a zone's authoritative servers
-   have access to its private keys.  Storing private keys on well-known
-   internet-accessible servers may make them more vulnerable to
-   unintended disclosure.
-
-   Second, since generation of digital signatures tends to be
-   computationally demanding, the requirement for on-demand signing
-   makes authoritative servers vulnerable to a denial of service attack.
-
-   Lastly, if the epsilon functions are predictable, on-demand signing
-   may enable a chosen-plaintext attack on a zone's private keys.  Zones
-   using this approach should attempt to use cryptographic algorithms
-   that are resistant to chosen-plaintext attacks.  It's worth noting
-
-
-
-Weiler & Ihren            Expires July 24, 2006                 [Page 7]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-   that while DNSSEC has a "mandatory to implement" algorithm, that is a
-   requirement on resolvers and validators -- there is no requirement
-   that a zone be signed with any given algorithm.
-
-   The success of using minimally covering NSEC record to prevent zone
-   walking depends greatly on the quality of the epsilon functions
-   chosen.  An increment function that chooses a name obviously derived
-   from the next instantiated name may be easily reverse engineered,
-   destroying the value of this technique.  An increment function that
-   always returns a name close to the next instantiated name is likewise
-   a poor choice.  Good choices of epsilon functions are the ones that
-   produce the immediately following and preceding names, respectively,
-   though zone administrators may wish to use less perfect functions
-   that return more human-friendly names than the functions described in
-   Section 4 above.
-
-   Another obvious but misguided concern is the danger from synthesized
-   NSEC records being replayed.  It's possible for an attacker to replay
-   an old but still validly signed NSEC record after a new name has been
-   added in the span covered by that NSEC, incorrectly proving that
-   there is no record at that name.  This danger exists with DNSSEC as
-   defined in [3].  The techniques described here actually decrease the
-   danger, since the span covered by any NSEC record is smaller than
-   before.  Choosing better epsilon functions will further reduce this
-   danger.
-
-7.  Normative References
-
-   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033,
-        March 2005.
-
-   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Resource Records for the DNS Security Extensions", RFC 4034,
-        March 2005.
-
-   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions",
-        RFC 4035, March 2005.
-
-   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-
-Appendix A.  Acknowledgments
-
-   Many individuals contributed to this design.  They include, in
-   addition to the authors of this document, Olaf Kolkman, Ed Lewis,
-
-
-
-Weiler & Ihren            Expires July 24, 2006                 [Page 8]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-   Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
-   Jakob Schlyter, Bill Manning, and Joao Damas.
-
-   In addition, the editors would like to thank Ed Lewis, Scott Rose,
-   and David Blacka for their careful review of the document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Ihren            Expires July 24, 2006                 [Page 9]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-Authors' Addresses
-
-   Samuel Weiler
-   SPARTA, Inc
-   7075 Samuel Morse Drive
-   Columbia, Maryland  21046
-   US
-
-   Email: weiler@tislabs.com
-
-
-   Johan Ihren
-   Autonomica AB
-   Bellmansgatan 30
-   Stockholm  SE-118 47
-   Sweden
-
-   Email: johani@autonomica.se
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Ihren            Expires July 24, 2006                [Page 10]
-
-Internet-Draft                NSEC Epsilon                  January 2006
-
-
-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 (2006).  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.
-
-
-
-
-Weiler & Ihren            Expires July 24, 2006                [Page 11]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt
deleted file mode 100644
index 17e28e8..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt
+++ /dev/null
@@ -1,896 +0,0 @@
-
-
-
-DNSEXT                                                         R. Arends
-Internet-Draft                                      Telematica Instituut
-Expires: January 19, 2006                                     M. Kosters
-                                                               D. Blacka
-                                                          Verisign, Inc.
-                                                           July 18, 2005
-
-
-                             DNSSEC Opt-In
-                   draft-ietf-dnsext-dnssec-opt-in-07
-
-Status of this Memo
-
-   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 becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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 19, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   In the DNS security extensions (DNSSEC, defined in RFC 4033 [3], RFC
-   4034 [4], and RFC 4035 [5]), delegations to unsigned subzones are
-   cryptographically secured.  Maintaining this cryptography is not
-   practical or necessary.  This document describes an experimental
-   "Opt-In" model that allows administrators to omit this cryptography
-   and manage the cost of adopting DNSSEC with large zones.
-
-
-
-Arends, et al.          Expires January 19, 2006                [Page 1]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-Table of Contents
-
-   1.  Definitions and Terminology  . . . . . . . . . . . . . . . . .  3
-   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   3.  Experimental Status  . . . . . . . . . . . . . . . . . . . . .  4
-   4.  Protocol Additions . . . . . . . . . . . . . . . . . . . . . .  4
-     4.1   Server Considerations  . . . . . . . . . . . . . . . . . .  5
-       4.1.1   Delegations Only . . . . . . . . . . . . . . . . . . .  5
-       4.1.2   Insecure Delegation Responses  . . . . . . . . . . . .  6
-       4.1.3   Wildcards and Opt-In . . . . . . . . . . . . . . . . .  6
-       4.1.4   Dynamic Update . . . . . . . . . . . . . . . . . . . .  7
-     4.2   Client Considerations  . . . . . . . . . . . . . . . . . .  7
-       4.2.1   Delegations Only . . . . . . . . . . . . . . . . . . .  7
-       4.2.2   Validation Process Changes . . . . . . . . . . . . . .  7
-       4.2.3   NSEC Record Caching  . . . . . . . . . . . . . . . . .  8
-       4.2.4   Use of the AD bit  . . . . . . . . . . . . . . . . . .  8
-   5.  Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-   6.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
-   7.  Transition Issues  . . . . . . . . . . . . . . . . . . . . . . 10
-   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
-   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
-   10.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 12
-   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 13
-     11.1  Normative References . . . . . . . . . . . . . . . . . . . 13
-     11.2  Informative References . . . . . . . . . . . . . . . . . . 13
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
-   A.  Implementing Opt-In using "Views"  . . . . . . . . . . . . . . 14
-       Intellectual Property and Copyright Statements . . . . . . . . 16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 19, 2006                [Page 2]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-1.  Definitions and Terminology
-
-   Throughout this document, familiarity with the DNS system (RFC 1035
-   [1]), DNS security extensions ([3], [4], and [5], referred to in this
-   document as "standard DNSSEC"), and DNSSEC terminology (RFC 3090
-   [10]) is assumed.
-
-   The following abbreviations and terms are used in this document:
-
-   RR: is used to refer to a DNS resource record.
-   RRset: refers to a Resource Record Set, as defined by [8].  In this
-      document, the RRset is also defined to include the covering RRSIG
-      records, if any exist.
-   signed name: refers to a DNS name that has, at minimum, a (signed)
-      NSEC record.
-   unsigned name: refers to a DNS name that does not (at least) have a
-      NSEC record.
-   covering NSEC record/RRset: is the NSEC record used to prove
-      (non)existence of a particular name or RRset.  This means that for
-      a RRset or name 'N', the covering NSEC record has the name 'N', or
-      has an owner name less than 'N' and "next" name greater than 'N'.
-   delegation: refers to a NS RRset with a name different from the
-      current zone apex (non-zone-apex), signifying a delegation to a
-      subzone.
-   secure delegation: refers to a signed name containing a delegation
-      (NS RRset), and a signed DS RRset, signifying a delegation to a
-      signed subzone.
-   insecure delegation: refers to a signed name containing a delegation
-      (NS RRset), but lacking a DS RRset, signifying a delegation to an
-      unsigned subzone.
-   Opt-In insecure delegation: refers to an unsigned name containing
-      only a delegation NS RRset.  The covering NSEC record uses the
-      Opt-In methodology described in this document.
-
-   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 [7].
-
-2.  Overview
-
-   The cost to cryptographically secure delegations to unsigned zones is
-   high for large delegation-centric zones and zones where insecure
-   delegations will be updated rapidly.  For these zones, the costs of
-   maintaining the NSEC record chain may be extremely high relative to
-   the gain of cryptographically authenticating existence of unsecured
-   zones.
-
-   This document describes an experimental method of eliminating the
-
-
-
-Arends, et al.          Expires January 19, 2006                [Page 3]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   superfluous cryptography present in secure delegations to unsigned
-   zones.  Using "Opt-In", a zone administrator can choose to remove
-   insecure delegations from the NSEC chain.  This is accomplished by
-   extending the semantics of the NSEC record by using a redundant bit
-   in the type map.
-
-3.  Experimental Status
-
-   This document describes an EXPERIMENTAL extension to DNSSEC.  It
-   interoperates with non-experimental DNSSEC using the technique
-   described in [6].  This experiment is identified with the following
-   private algorithms (using algorithm 253):
-
-   "3.optin.verisignlabs.com": is an alias for DNSSEC algorithm 3, DSA,
-      and
-   "5.optin.verisignlabs.com": is an alias for DNSSEC algorithm 5,
-      RSASHA1.
-
-   Servers wishing to sign and serve zones that utilize Opt-In MUST sign
-   the zone with only one or more of these private algorithms.  This
-   requires the signing tools and servers to support private algorithms,
-   as well as Opt-In.
-
-   Resolvers wishing to validate Opt-In zones MUST only do so when the
-   zone is only signed using one or more of these private algorithms.
-
-   The remainder of this document assumes that the servers and resolvers
-   involved are aware of and are involved in this experiment.
-
-4.  Protocol Additions
-
-   In DNSSEC, delegation NS RRsets are not signed, but are instead
-   accompanied by a NSEC RRset of the same name and (possibly) a DS
-   record.  The security status of the subzone is determined by the
-   presence or absence of the DS RRset, cryptographically proven by the
-   NSEC record.  Opt-In expands this definition by allowing insecure
-   delegations to exist within an otherwise signed zone without the
-   corresponding NSEC record at the delegation's owner name.  These
-   insecure delegations are proven insecure by using a covering NSEC
-   record.
-
-   Since this represents a change of the interpretation of NSEC records,
-   resolvers must be able to distinguish between RFC standard DNSSEC
-   NSEC records and Opt-In NSEC records.  This is accomplished by
-   "tagging" the NSEC records that cover (or potentially cover) insecure
-   delegation nodes.  This tag is indicated by the absence of the NSEC
-   bit in the type map.  Since the NSEC bit in the type map merely
-   indicates the existence of the record itself, this bit is redundant
-
-
-
-Arends, et al.          Expires January 19, 2006                [Page 4]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   and safe for use as a tag.
-
-   An Opt-In tagged NSEC record does not assert the (non)existence of
-   the delegations that it covers (except for a delegation with the same
-   name).  This allows for the addition or removal of these delegations
-   without recalculating or resigning records in the NSEC chain.
-   However, Opt-In tagged NSEC records do assert the (non)existence of
-   other RRsets.
-
-   An Opt-In NSEC record MAY have the same name as an insecure
-   delegation.  In this case, the delegation is proven insecure by the
-   lack of a DS bit in type map and the signed NSEC record does assert
-   the existence of the delegation.
-
-   Zones using Opt-In MAY contain a mixture of Opt-In tagged NSEC
-   records and standard DNSSEC NSEC records.  If a NSEC record is not
-   Opt-In, there MUST NOT be any insecure delegations (or any other
-   records) between it and the RRsets indicated by the 'next domain
-   name' in the NSEC RDATA.  If it is Opt-In, there MUST only be
-   insecure delegations between it and the next node indicated by the
-   'next domain name' in the NSEC RDATA.
-
-   In summary,
-
-   o  An Opt-In NSEC type is identified by a zero-valued (or not-
-      specified) NSEC bit in the type bit map of the NSEC record.
-   o  A RFC2535bis NSEC type is identified by a one-valued NSEC bit in
-      the type bit map of the NSEC record.
-
-   and,
-
-   o  An Opt-In NSEC record does not assert the non-existence of a name
-      between its owner name and "next" name, although it does assert
-      that any name in this span MUST be an insecure delegation.
-   o  An Opt-In NSEC record does assert the (non)existence of RRsets
-      with the same owner name.
-
-4.1  Server Considerations
-
-   Opt-In imposes some new requirements on authoritative DNS servers.
-
-4.1.1  Delegations Only
-
-   This specification dictates that only insecure delegations may exist
-   between the owner and "next" names of an Opt-In tagged NSEC record.
-   Signing tools SHOULD NOT generate signed zones that violate this
-   restriction.  Servers SHOULD refuse to load and/or serve zones that
-   violate this restriction.  Servers also SHOULD reject AXFR or IXFR
-
-
-
-Arends, et al.          Expires January 19, 2006                [Page 5]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   responses that violate this restriction.
-
-4.1.2  Insecure Delegation Responses
-
-   When returning an Opt-In insecure delegation, the server MUST return
-   the covering NSEC RRset in the Authority section.
-
-   In standard DNSSEC, NSEC records already must be returned along with
-   the insecure delegation.  The primary difference that this proposal
-   introduces is that the Opt-In tagged NSEC record will have a
-   different owner name from the delegation RRset.  This may require
-   implementations to search for the covering NSEC RRset.
-
-4.1.3  Wildcards and Opt-In
-
-   Standard DNSSEC describes the practice of returning NSEC records to
-   prove the non-existence of an applicable wildcard in non-existent
-   name responses.  This NSEC record can be described as a "negative
-   wildcard proof".  The use of Opt-In NSEC records changes the
-   necessity for this practice.  For non-existent name responses when
-   the query name (qname) is covered by an Opt-In tagged NSEC record,
-   servers MAY choose to omit the wildcard proof record, and clients
-   MUST NOT treat the absence of this NSEC record as a validation error.
-
-   The intent of the standard DNSSEC negative wildcard proof requirement
-   is to prevent malicious users from undetectably removing valid
-   wildcard responses.  In order for this cryptographic proof to work,
-   the resolver must be able to prove:
-
-   1.  The exact qname does not exist.  This is done by the "normal"
-       NSEC record.
-   2.  No applicable wildcard exists.  This is done by returning a NSEC
-       record proving that the wildcard does not exist (this is the
-       negative wildcard proof).
-
-   However, if the NSEC record covering the exact qname is an Opt-In
-   NSEC record, the resolver will not be able to prove the first part of
-   this equation, as the qname might exist as an insecure delegation.
-   Thus, since the total proof cannot be completed, the negative
-   wildcard proof NSEC record is not useful.
-
-   The negative wildcard proof is also not useful when returned as part
-   of an Opt-In insecure delegation response for a similar reason: the
-   resolver cannot prove that the qname does or does not exist, and
-   therefore cannot prove that a wildcard expansion is valid.
-
-   The presence of an Opt-In tagged NSEC record does not change the
-   practice of returning a NSEC along with a wildcard expansion.  Even
-
-
-
-Arends, et al.          Expires January 19, 2006                [Page 6]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   though the Opt-In NSEC will not be able to prove that the wildcard
-   expansion is valid, it will prove that the wildcard expansion is not
-   masking any signed records.
-
-4.1.4  Dynamic Update
-
-   Opt-In changes the semantics of Secure DNS Dynamic Update [9].  In
-   particular, it introduces the need for rules that describe when to
-   add or remove a delegation name from the NSEC chain.  This document
-   does not attempt to define these rules.  Until these rules are
-   defined, servers MUST NOT process DNS Dynamic Update requests against
-   zones that use Opt-In NSEC records.  Servers SHOULD return responses
-   to update requests with RCODE=REFUSED.
-
-4.2  Client Considerations
-
-   Opt-In imposes some new requirements on security-aware resolvers
-   (caching or otherwise).
-
-4.2.1  Delegations Only
-
-   As stated in the "Server Considerations" section above, this
-   specification restricts the namespace covered by Opt-In tagged NSEC
-   records to insecure delegations only.  Thus, resolvers MUST reject as
-   invalid any records that fall within an Opt-In NSEC record's span
-   that are not NS records or corresponding glue records.
-
-4.2.2  Validation Process Changes
-
-   This specification does not change the resolver's resolution
-   algorithm.  However, it does change the DNSSEC validation process.
-   Resolvers MUST be able to use Opt-In tagged NSEC records to
-   cryptographically prove the validity and security status (as
-   insecure) of a referral.  Resolvers determine the security status of
-   the referred-to zone as follows:
-
-   o  In standard DNSSEC, the security status is proven by the existence
-      or absence of a DS RRset at the same name as the delegation.  The
-      existence of the DS RRset indicates that the referred-to zone is
-      signed.  The absence of the DS RRset is proven using a verified
-      NSEC record of the same name that does not have the DS bit set in
-      the type map.  This NSEC record MAY also be tagged as Opt-In.
-   o  Using Opt-In, the security status is proven by the existence of a
-      DS record (for signed) or the presence of a verified Opt-In tagged
-      NSEC record that covers the delegation name.  That is, the NSEC
-      record does not have the NSEC bit set in the type map, and the
-      delegation name falls between the NSEC's owner and "next" name.
-
-
-
-
-Arends, et al.          Expires January 19, 2006                [Page 7]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   Using Opt-In does not substantially change the nature of following
-   referrals within DNSSEC.  At every delegation point, the resolver
-   will have cryptographic proof that the referred-to subzone is signed
-   or unsigned.
-
-   When receiving either an Opt-In insecure delegation response or a
-   non-existent name response where that name is covered by an Opt-In
-   tagged NSEC record, the resolver MUST NOT require proof (in the form
-   of a NSEC record) that a wildcard did not exist.
-
-4.2.3  NSEC Record Caching
-
-   Caching resolvers MUST be able to retrieve the appropriate covering
-   Opt-In NSEC record when returning referrals that need them.  This
-   requirement differs from standard DNSSEC in that the covering NSEC
-   will not have the same owner name as the delegation.  Some
-   implementations may have to use new methods for finding these NSEC
-   records.
-
-4.2.4  Use of the AD bit
-
-   The AD bit, as defined by [2] and [5], MUST NOT be set when:
-
-   o  sending a Name Error (RCODE=3) response where the covering NSEC is
-      tagged as Opt-In.
-   o  sending an Opt-In insecure delegation response, unless the
-      covering (Opt-In) NSEC record's owner name equals the delegation
-      name.
-
-   This rule is based on what the Opt-In NSEC record actually proves:
-   for names that exist between the Opt-In NSEC record's owner and
-   "next" names, the Opt-In NSEC record cannot prove the non-existence
-   or existence of the name.  As such, not all data in the response has
-   been cryptographically verified, so the AD bit cannot be set.
-
-5.  Benefits
-
-   Using Opt-In allows administrators of large and/or changing
-   delegation-centric zones to minimize the overhead involved in
-   maintaining the security of the zone.
-
-   Opt-In accomplishes this by eliminating the need for NSEC records for
-   insecure delegations.  This, in a zone with a large number of
-   delegations to unsigned subzones, can lead to substantial space
-   savings (both in memory and on disk).  Additionally, Opt-In allows
-   for the addition or removal of insecure delegations without modifying
-   the NSEC record chain.  Zones that are frequently updating insecure
-   delegations (e.g., TLDs) can avoid the substantial overhead of
-
-
-
-Arends, et al.          Expires January 19, 2006                [Page 8]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   modifying and resigning the affected NSEC records.
-
-6.  Example
-
-   Consider the zone EXAMPLE, shown below.  This is a zone where all of
-   the NSEC records are tagged as Opt-In.
-
-   Example A: Fully Opt-In Zone.
-
-         EXAMPLE.               SOA    ...
-         EXAMPLE.               RRSIG  SOA ...
-         EXAMPLE.               NS     FIRST-SECURE.EXAMPLE.
-         EXAMPLE.               RRSIG  NS ...
-         EXAMPLE.               DNSKEY ...
-         EXAMPLE.               RRSIG  DNSKEY ...
-         EXAMPLE.               NSEC   FIRST-SECURE.EXAMPLE. (
-                                       SOA NS RRSIG DNSKEY )
-         EXAMPLE.               RRSIG  NSEC ...
-
-         FIRST-SECURE.EXAMPLE.  A      ...
-         FIRST-SECURE.EXAMPLE.  RRSIG  A ...
-         FIRST-SECURE.EXAMPLE.  NSEC   NOT-SECURE-2.EXAMPLE. A RRSIG
-         FIRST-SECURE.EXAMPLE.  RRSIG  NSEC ...
-
-         NOT-SECURE.EXAMPLE.    NS     NS.NOT-SECURE.EXAMPLE.
-         NS.NOT-SECURE.EXAMPLE. A      ...
-
-         NOT-SECURE-2.EXAMPLE.  NS     NS.NOT-SECURE.EXAMPLE.
-         NOT-SECURE-2.EXAMPLE   NSEC   SECOND-SECURE.EXAMPLE NS RRSIG
-         NOT-SECURE-2.EXAMPLE   RRSIG  NSEC ...
-
-         SECOND-SECURE.EXAMPLE. NS     NS.ELSEWHERE.
-         SECOND-SECURE.EXAMPLE. DS     ...
-         SECOND-SECURE.EXAMPLE. RRSIG  DS ...
-         SECOND-SECURE.EXAMPLE. NSEC   EXAMPLE. NS RRSIG DNSKEY
-         SECOND-SECURE.EXAMPLE. RRSIG  NSEC ...
-
-         UNSIGNED.EXAMPLE.      NS     NS.UNSIGNED.EXAMPLE.
-         NS.UNSIGNED.EXAMPLE.   A      ...
-
-
-   In this example, a query for a signed RRset (e.g., "FIRST-
-   SECURE.EXAMPLE A"), or a secure delegation ("WWW.SECOND-
-   SECURE.EXAMPLE A") will result in a standard DNSSEC response.
-
-   A query for a nonexistent RRset will result in a response that
-   differs from standard DNSSEC by: the NSEC record will be tagged as
-   Opt-In, there may be no NSEC record proving the non-existence of a
-
-
-
-Arends, et al.          Expires January 19, 2006                [Page 9]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   matching wildcard record, and the AD bit will not be set.
-
-   A query for an insecure delegation RRset (or a referral) will return
-   both the answer (in the Authority section) and the corresponding
-   Opt-In NSEC record to prove that it is not secure.
-
-   Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE.  A
-
-
-         RCODE=NOERROR, AD=0
-
-         Answer Section:
-
-         Authority Section:
-         UNSIGNED.EXAMPLE.      NS     NS.UNSIGNED.EXAMPLE
-         SECOND-SECURE.EXAMPLE. NSEC   EXAMPLE. NS RRSIG DS
-         SECOND-SECURE.EXAMPLE. RRSIG  NSEC ...
-
-         Additional Section:
-         NS.UNSIGNED.EXAMPLE.   A      ...
-
-   In the Example A.1 zone, the EXAMPLE. node MAY use either style of
-   NSEC record, because there are no insecure delegations that occur
-   between it and the next node, FIRST-SECURE.EXAMPLE.  In other words,
-   Example A would still be a valid zone if the NSEC record for EXAMPLE.
-   was changed to the following RR:
-
-         EXAMPLE.               NSEC   FIRST-SECURE.EXAMPLE. (SOA NS
-                                       RRSIG DNSKEY NSEC )
-
-   However, the other NSEC records (FIRST-SECURE.EXAMPLE. and SECOND-
-   SECURE.EXAMPLE.)  MUST be tagged as Opt-In because there are insecure
-   delegations in the range they define.  (NOT-SECURE.EXAMPLE. and
-   UNSIGNED.EXAMPLE., respectively).
-
-   NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that is
-   part of the NSEC chain and also covered by an Opt-In tagged NSEC
-   record.  Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot be
-   removed from the zone without modifying and resigning the prior NSEC
-   record.  Delegations with names that fall between NOT-SECURE-
-   2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or removed without
-   resigning any NSEC records.
-
-7.  Transition Issues
-
-   Opt-In is not backwards compatible with standard DNSSEC and is
-   considered experimental.  Standard DNSSEC compliant implementations
-   would not recognize Opt-In tagged NSEC records as different from
-
-
-
-Arends, et al.          Expires January 19, 2006               [Page 10]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   standard NSEC records.  Because of this, standard DNSSEC
-   implementations, if they were to validate Opt-In style responses,
-   would reject all Opt-In insecure delegations within a zone as
-   invalid.  However, by only signing with private algorithms, standard
-   DNSSEC implementations will treat Opt-In responses as unsigned.
-
-   It should be noted that all elements in the resolution path between
-   (and including) the validator and the authoritative name server must
-   be aware of the Opt-In experiment and implement the Opt-In semantics
-   for successful validation to be possible.  In particular, this
-   includes any caching middleboxes between the validator and
-   authoritative name server.
-
-8.  Security Considerations
-
-   Opt-In allows for unsigned names, in the form of delegations to
-   unsigned subzones, to exist within an otherwise signed zone.  All
-   unsigned names are, by definition, insecure, and their validity or
-   existence cannot by cryptographically proven.
-
-   In general:
-
-   o  Records with unsigned names (whether existing or not) suffer from
-      the same vulnerabilities as records in an unsigned zone.  These
-      vulnerabilities are described in more detail in [12] (note in
-      particular sections 2.3, "Name Games" and 2.6, "Authenticated
-      Denial").
-   o  Records with signed names have the same security whether or not
-      Opt-In is used.
-
-   Note that with or without Opt-In, an insecure delegation may have its
-   contents undetectably altered by an attacker.  Because of this, the
-   primary difference in security that Opt-In introduces is the loss of
-   the ability to prove the existence or nonexistence of an insecure
-   delegation within the span of an Opt-In NSEC record.
-
-   In particular, this means that a malicious entity may be able to
-   insert or delete records with unsigned names.  These records are
-   normally NS records, but this also includes signed wildcard
-   expansions (while the wildcard record itself is signed, its expanded
-   name is an unsigned name).
-
-   For example, if a resolver received the following response from the
-   example zone above:
-
-
-
-
-
-
-
-Arends, et al.          Expires January 19, 2006               [Page 11]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE.  A
-
-         RCODE=NOERROR
-
-         Answer Section:
-
-         Authority Section:
-         DOES-NOT-EXIST.EXAMPLE. NS     NS.FORGED.
-         EXAMPLE.                NSEC   FIRST-SECURE.EXAMPLE. SOA NS \
-                                        RRSIG DNSKEY
-         EXAMPLE.                RRSIG  NSEC ...
-
-         Additional Section:
-
-
-   The resolver would have no choice but to believe that the referral to
-   NS.FORGED. is valid.  If a wildcard existed that would have been
-   expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
-   have undetectably removed it and replaced it with the forged
-   delegation.
-
-   Note that being able to add a delegation is functionally equivalent
-   to being able to add any record type: an attacker merely has to forge
-   a delegation to nameserver under his/her control and place whatever
-   records needed at the subzone apex.
-
-   While in particular cases, this issue may not present a significant
-   security problem, in general it should not be lightly dismissed.
-   Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
-   In particular, zone signing tools SHOULD NOT default to Opt-In, and
-   MAY choose to not support Opt-In at all.
-
-9.  IANA Considerations
-
-   None.
-
-10.  Acknowledgments
-
-   The contributions, suggestions and remarks of the following persons
-   (in alphabetic order) to this draft are acknowledged:
-
-      Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf
-      Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill Manning,
-      Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, Brian
-      Wellington.
-
-11.  References
-
-
-
-
-Arends, et al.          Expires January 19, 2006               [Page 12]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-11.1  Normative References
-
-   [1]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [2]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS
-        Authenticated Data (AD) bit", RFC 3655, November 2003.
-
-   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033,
-        March 2005.
-
-   [4]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Resource Records for the DNS Security Extensions", RFC 4034,
-        March 2005.
-
-   [5]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions",
-        RFC 4035, March 2005.
-
-   [6]  Blacka, D., "DNSSEC Experiments",
-        draft-ietf-dnsext-dnssec-experiments-01 (work in progress),
-        July 2005.
-
-11.2  Informative References
-
-   [7]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-   [8]   Elz, R. and R. Bush, "Clarifications to the DNS Specification",
-         RFC 2181, July 1997.
-
-   [9]   Eastlake, D., "Secure Domain Name System Dynamic Update",
-         RFC 2137, April 1997.
-
-   [10]  Lewis, E., "DNS Security Extension Clarification on Zone
-         Status", RFC 3090, March 2001.
-
-   [11]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
-         December 2001.
-
-   [12]  Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
-         System (DNS)", RFC 3833, August 2004.
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 19, 2006               [Page 13]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-Authors' Addresses
-
-   Roy Arends
-   Telematica Instituut
-   Drienerlolaan 5
-   7522 NB  Enschede
-   NL
-
-   Email: roy.arends@telin.nl
-
-
-   Mark Kosters
-   Verisign, Inc.
-   21355 Ridgetop Circle
-   Dulles, VA  20166
-   US
-
-   Phone: +1 703 948 3200
-   Email: markk@verisign.com
-   URI:   http://www.verisignlabs.com
-
-
-   David Blacka
-   Verisign, Inc.
-   21355 Ridgetop Circle
-   Dulles, VA  20166
-   US
-
-   Phone: +1 703 948 3200
-   Email: davidb@verisign.com
-   URI:   http://www.verisignlabs.com
-
-Appendix A.  Implementing Opt-In using "Views"
-
-   In many cases, it may be convenient to implement an Opt-In zone by
-   combining two separately maintained "views" of a zone at request
-   time.  In this context, "view" refers to a particular version of a
-   zone, not to any specific DNS implementation feature.
-
-   In this scenario, one view is the secure view, the other is the
-   insecure (or legacy) view.  The secure view consists of an entirely
-   signed zone using Opt-In tagged NSEC records.  The insecure view
-   contains no DNSSEC information.  It is helpful, although not
-   necessary, for the secure view to be a subset (minus DNSSEC records)
-   of the insecure view.
-
-   In addition, the only RRsets that may solely exist in the insecure
-   view are non-zone-apex NS RRsets.  That is, all non-NS RRsets (and
-
-
-
-Arends, et al.          Expires January 19, 2006               [Page 14]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-   the zone apex NS RRset) MUST be signed and in the secure view.
-
-   These two views may be combined at request time to provide a virtual,
-   single Opt-In zone.  The following algorithm is used when responding
-   to each query:
-      V_A is the secure view as described above.
-      V_B is the insecure view as described above.
-      R_A is a response generated from V_A, following RFC 2535bis.
-      R_B is a response generated from V_B, following DNS resolution as
-      per RFC 1035 [1].
-      R_C is the response generated by combining R_A with R_B, as
-      described below.
-      A query is DNSSEC-aware if it either has the DO bit [11] turned
-      on, or is for a DNSSEC-specific record type.
-
-
-
-   1.  If V_A is a subset of V_B and the query is not DNSSEC-aware,
-       generate and return R_B, otherwise
-   2.  Generate R_A.
-   3.  If R_A's RCODE != NXDOMAIN, return R_A, otherwise
-   4.  Generate R_B and combine it with R_A to form R_C:
-          For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the
-          records from R_A into R_B, EXCEPT the AUTHORITY section SOA
-          record, if R_B's RCODE = NOERROR.
-   5.  Return R_C.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.          Expires January 19, 2006               [Page 15]
-
-Internet-Draft                DNSSEC Opt-In                    July 2005
-
-
-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 (2005).  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 19, 2006               [Page 16]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt
deleted file mode 100644
index 390420a..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt
+++ /dev/null
@@ -1,392 +0,0 @@
-
-
-
-DNS Extensions working group                                   J. Jansen
-Internet-Draft                                                NLnet Labs
-Expires: July 5, 2006                                       January 2006
-
-
-     Use of RSA/SHA-256 DNSKEY and RRSIG Resource Records in DNSSEC
-                 draft-ietf-dnsext-dnssec-rsasha256-00
-
-Status of this Memo
-
-   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 becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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 5, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes how to produce RSA/SHA-256 DNSKEY and RRSIG
-   resource records for use in the Domain Name System Security
-   Extensions (DNSSEC, RFC4033, RFC4034, and RFC4035).
-
-
-
-
-
-
-
-
-
-Jansen                    Expires July 5, 2006                  [Page 1]
-
-Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.  RSA/SHA-256 DNSKEY Resource Records . . . . . . . . . . . . . . 3
-   3.  RSA/SHA-256 RRSIG Resource Records  . . . . . . . . . . . . . . 3
-   4.  Implementation Considerations . . . . . . . . . . . . . . . . . 4
-   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
-   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
-   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
-   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
-     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
-     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jansen                    Expires July 5, 2006                  [Page 2]
-
-Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
-
-
-1.  Introduction
-
-   The Domain Name System (DNS) is the global hierarchical distributed
-   database for Internet Addressing.  The DNS has been extended to use
-   digital signatures and cryptographic keys for the verification of
-   data.  RFC4033 [1], RFC4034 [2], and RFC4035 [3] describe these DNS
-   Security Extensions.
-
-   RFC4034 describes how to store DNSKEY and RRSIG resource records, and
-   specifies a list of cryptographic algorithms to use.  This document
-   extends that list with the algorithm RSA/SHA-256, and specifies how
-   to store RSA/SHA-256 DNSKEY data and how to produce RSA/SHA-256 RRSIG
-   resource records.
-
-   Familiarity with the RSA [7] and SHA-256 [5] algorithms is assumed in
-   this document.
-
-
-2.  RSA/SHA-256 DNSKEY Resource Records
-
-   RSA public keys for use with RSA/SHA-256 are stored in DNSKEY
-   resource records (RRs) with the algorithm number [TBA].
-
-   The format of the DNSKEY RR can be found in RFC4034 [2] and RFC3110
-   [6].
-
-
-3.  RSA/SHA-256 RRSIG Resource Records
-
-   RSA/SHA-256 signatures are stored in the DNS using RRSIG resource
-   records (RRs) with algorithm number [TBA].
-
-   The value of the signature field in the RRSIG RR is calculated as
-   follows.  The values for the fields that precede the signature data
-   are specified in RFC4034 [2].
-
-   hash = SHA-256(data)
-
-   signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)
-
-   Where SHA-256 is the message digest algorithm as specified in FIPS
-   180 [5], | is concatenation, 00, 01, FF and 00 are fixed octets of
-   corresponding hexadecimal value, "e" is the private exponent of the
-   signing RSA key, and "n" is the public modulus of the signing key.
-   The FF octet MUST be repeated the maximum number of times so that the
-   total length of the signature equals the length of the modulus of the
-   signer's public key ("n"). "data" is the data of the resource record
-   set that is signed, as specified in RFC4034 [2].
-
-
-
-Jansen                    Expires July 5, 2006                  [Page 3]
-
-Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
-
-
-   The prefix is the ASN.1 BER SHA-256 algorithm designator prefix as
-   specified in PKCS 2.1 [4]:
-
-   hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20
-
-   This prefix should make the use of standard cryptographic libraries
-   easier.  These specifications are taken directly from PKCS #1 v2.1
-   section 9.2 [4].
-
-
-4.  Implementation Considerations
-
-   DNSSEC aware implementations MUST be able to support RRSIG resource
-   records with the RSA/SHA-256 algorithm.
-
-   If both RSA/SHA-256 and RSA/SHA-1 RRSIG resource records are
-   available for a certain rrset, with a secure path to their keys, the
-   validator SHOULD ignore the SHA-1 signature.  If the RSA/SHA-256
-   signature does not verify the data, and the RSA/SHA-1 does, the
-   validator SHOULD mark the data with the security status from the RSA/
-   SHA-256 signature.
-
-
-5.  IANA Considerations
-
-   IANA has not yet assigned an algorithm number for RSA/SHA-256.
-
-   The algorithm list from RFC4034 Appendix A.1 [2] is extended with the
-   following entry:
-
-                                   Zone
-   Value Algorithm    [Mnemonic] Signing  References   Status
-   ----- ----------- ----------- -------- ----------  ---------
-   [tba] RSA/SHA-256 [RSASHA256]      y        [TBA]  MANDATORY
-
-
-6.  Security Considerations
-
-   Recently, weaknesses have been discovered in the SHA-1 hashing
-   algorithm.  It is therefore strongly encouraged to deploy SHA-256
-   where SHA-1 is used now, as soon as the DNS software supports it.
-
-   SHA-256 is considered sufficiently strong for the immediate future,
-   but predictions about future development in cryptography and
-   cryptanalysis are beyond the scope of this document.
-
-
-
-
-
-
-Jansen                    Expires July 5, 2006                  [Page 4]
-
-Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
-
-
-7.  Acknowledgments
-
-   This document is a minor extension to RFC4034 [2].  Also, we try to
-   follow the documents RFC3110 [6] and draft-ietf-dnsext-ds-sha256.txt
-   [8] for consistency.  The authors of and contributors to these
-   documents are gratefully acknowledged for their hard work.
-
-   The following people provided additional feedback and text: Jaap
-   Akkerhuis, Miek Gieben and Wouter Wijngaards.
-
-
-8.  References
-
-8.1.  Normative References
-
-   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033,
-        March 2005.
-
-   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Resource Records for the DNS Security Extensions", RFC 4034,
-        March 2005.
-
-   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions",
-        RFC 4035, March 2005.
-
-   [4]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards
-        (PKCS) #1: RSA Cryptography Specifications Version 2.1",
-        RFC 3447, February 2003.
-
-   [5]  National Institute of Standards and Technology, "Secure Hash
-        Standard", FIPS PUB 180-2, August 2002.
-
-   [6]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
-        System (DNS)", RFC 3110, May 2001.
-
-8.2.  Informative References
-
-   [7]  Schneier, B., "Applied Cryptography Second Edition: protocols,
-        algorithms, and source code in C", Wiley and Sons , ISBN 0-471-
-        11709-9, 1996.
-
-   [8]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
-        Resource Records (RRs)", Work in Progress Feb 2006.
-
-
-
-
-
-
-Jansen                    Expires July 5, 2006                  [Page 5]
-
-Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
-
-
-Author's Address
-
-   Jelte Jansen
-   NLnet Labs
-   Kruislaan 419
-   Amsterdam  1098VA
-   NL
-
-   Email: jelte@NLnetLabs.nl
-   URI:   http://www.nlnetlabs.nl/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jansen                    Expires July 5, 2006                  [Page 6]
-
-Internet-Draft       RSA/SHA-256 DNSKEYs and RRSIGS         January 2006
-
-
-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 (2006).  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.
-
-
-
-
-Jansen                    Expires July 5, 2006                  [Page 7]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt
deleted file mode 100644
index dd8cbf0..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt
+++ /dev/null
@@ -1,839 +0,0 @@
-
-DNS Extensions Working Group                                   R. Arends
-Internet-Draft                                      Telematica Instituut
-Expires: August 25, 2005                                         P. Koch
-                                                                DENIC eG
-                                                             J. Schlyter
-                                                                  NIC-SE
-                                                       February 21, 2005
-
-
-                Evaluating DNSSEC Transition Mechanisms
-                 draft-ietf-dnsext-dnssec-trans-02.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 August 25, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document collects and summarizes different proposals for
-   alternative and additional strategies for authenticated denial in DNS
-   responses, evaluates these proposals and gives a recommendation for a
-
-
-
-Arends, et al.           Expires August 25, 2005                [Page 1]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-   way forward.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Transition Mechanisms  . . . . . . . . . . . . . . . . . . . .  3
-     2.1   Mechanisms With Need of Updating DNSSEC-bis  . . . . . . .  4
-       2.1.1   Dynamic NSEC Synthesis . . . . . . . . . . . . . . . .  4
-       2.1.2   Add Versioning/Subtyping to Current NSEC . . . . . . .  5
-       2.1.3   Type Bit Map NSEC Indicator  . . . . . . . . . . . . .  6
-       2.1.4   New Apex Type  . . . . . . . . . . . . . . . . . . . .  6
-       2.1.5   NSEC White Lies  . . . . . . . . . . . . . . . . . . .  7
-       2.1.6   NSEC Optional via DNSSKEY Flag . . . . . . . . . . . .  8
-       2.1.7   New Answer Pseudo RR Type  . . . . . . . . . . . . . .  9
-       2.1.8   SIG(0) Based Authenticated Denial  . . . . . . . . . .  9
-     2.2   Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 10
-       2.2.1   Partial Type-code and Signal Rollover  . . . . . . . . 10
-       2.2.2   A Complete Type-code and Signal Rollover . . . . . . . 11
-       2.2.3   Unknown Algorithm in RRSIG . . . . . . . . . . . . . . 11
-   3.  Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12
-   4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
-   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
-     5.1   Normative References . . . . . . . . . . . . . . . . . . . 13
-     5.2   Informative References . . . . . . . . . . . . . . . . . . 13
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
-       Intellectual Property and Copyright Statements . . . . . . . . 15
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.           Expires August 25, 2005                [Page 2]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-1.  Introduction
-
-   This report shall document the process of dealing with the NSEC
-   walking problem late in the Last Call for
-   [I-D.ietf-dnsext-dnssec-intro, I-D.ietf-dnsext-dnssec-protocol,
-   I-D.ietf-dnsext-dnssec-records].  It preserves some of the discussion
-   that took place in the DNSEXT WG during the first half of June 2004
-   as well as some additional ideas that came up subsequently.
-
-   This is an edited excerpt of the chairs' mail to the WG:
-      The working group consents on not including NSEC-alt in the
-      DNSSEC-bis documents.  The working group considers to take up
-      "prevention of zone enumeration" as a work item.
-      There may be multiple mechanisms to allow for co-existence with
-      DNSSEC-bis.  The chairs allow the working group a little over a
-      week (up to June 12, 2004) to come to consensus on a possible
-      modification to the document to enable gentle rollover.  If that
-      consensus cannot be reached the DNSSEC-bis documents will go out
-      as-is.
-
-   To ease the process of getting consensus, a summary of the proposed
-   solutions and analysis of the pros and cons were written during the
-   weekend.
-
-   This summary includes:
-
-      An inventory of the proposed mechanisms to make a transition to
-      future work on authenticated denial of existence.
-      List the known Pros and Cons, possibly provide new arguments, and
-      possible security considerations of these mechanisms.
-      Provide a recommendation on a way forward that is least disruptive
-      to the DNSSEC-bis specifications as they stand and keep an open
-      path to other methods for authenticated denial of existence.
-
-   The descriptions of the proposals in this document are coarse and do
-   not cover every detail necessary for implementation.  In any case,
-   documentation and further study is needed before implementaion and/or
-   deployment, including those which seem to be solely operational in
-   nature.
-
-2.  Transition Mechanisms
-
-   In the light of recent discussions and past proposals, we have found
-   several ways to allow for transition to future expansion of
-   authenticated denial.  We tried to illuminate the paths and pitfalls
-   in these ways forward.  Some proposals lead to a versioning of
-   DNSSEC, where DNSSEC-bis may co-exist with DNSSEC-ter, other
-   proposals are 'clean' but may cause delay, while again others may be
-
-
-
-Arends, et al.           Expires August 25, 2005                [Page 3]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-   plain hacks.
-
-   Some paths do not introduce versioning, and might require the current
-   DNSSEC-bis documents to be fully updated to allow for extensions to
-   authenticated denial mechanisms.  Other paths introduce versioning
-   and do not (or minimally) require DNSSEC-bis documents to be updated,
-   allowing DNSSEC-bis to be deployed, while future versions can be
-   drafted independent from or partially depending on DNSSEC-bis.
-
-2.1  Mechanisms With Need of Updating DNSSEC-bis
-
-   Mechanisms in this category demand updates to the DNSSEC-bis document
-   set.
-
-2.1.1  Dynamic NSEC Synthesis
-
-   This proposal assumes that NSEC RRs and the authenticating RRSIG will
-   be generated dynamically to just cover the (non existent) query name.
-   The owner name is (the) one preceding the name queried for, the Next
-   Owner Name Field has the value of the Query Name Field + 1 (first
-   successor in canonical ordering).  A separate key (the normal ZSK or
-   a separate ZSK per authoritative server) would be used for RRSIGs on
-   NSEC RRs.  This is a defense against enumeration, though it has the
-   presumption of online signing.
-
-2.1.1.1  Coexistence and Migration
-
-   There is no change in interpretation other then that the next owner
-   name might or might not exist.
-
-2.1.1.2  Limitations
-
-   This introduces an unbalanced cost between query and response
-   generation due to dynamic generation of signatures.
-
-2.1.1.3  Amendments to DNSSEC-bis
-
-   The current DNSSEC-bis documents might need to be updated to indicate
-   that the next owner name might not be an existing name in the zone.
-   This is not a real change to the spec since implementers have been
-   warned not to synthesize with previously cached NSEC records.  A
-   specific bit to identify the dynamic signature generating key might
-   be useful as well, to prevent it from being used to fake positive
-   data.
-
-2.1.1.4  Cons
-
-   Unbalanced cost is a ground for DDoS.  Though this protects against
-
-
-
-Arends, et al.           Expires August 25, 2005                [Page 4]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-   enumeration, it is not really a path for versioning.
-
-2.1.1.5  Pros
-
-   Hardly any amendments to DNSSEC-bis.
-
-2.1.2  Add Versioning/Subtyping to Current NSEC
-
-   This proposal introduces versioning for the NSEC RR type (a.k.a.
-   subtyping) by adding a (one octet) version field to the NSEC RDATA.
-   Version number 0 is assigned to the current (DNSSEC-bis) meaning,
-   making this an 'Must Be Zero' (MBZ) for the to be published docset.
-
-2.1.2.1  Coexistence and Migration
-
-   Since the versioning is done inside the NSEC RR, different versions
-   may coexist.  However, depending on future methods, that may or may
-   not be useful inside a single zone.  Resolvers cannot ask for
-   specific NSEC versions but may be able to indicate version support by
-   means of a to be defined EDNS option bit.
-
-2.1.2.2  Limitations
-
-   There are no technical limitations, though it will cause delay to
-   allow testing of the (currently unknown) new NSEC interpretation.
-
-   Since the versioning and signaling is done inside the NSEC RR, future
-   methods will likely be restricted to a single RR type authenticated
-   denial (as opposed to e.g.  NSEC-alt, which currently proposes three
-   RR types).
-
-2.1.2.3  Amendments to DNSSEC-bis
-
-   Full Update of the current DNSSEC-bis documents to provide for new
-   fields in NSEC, while specifying behavior in case of unknown field
-   values.
-
-2.1.2.4  Cons
-
-   Though this is a clean and clear path without versioning DNSSEC, it
-   takes some time to design, gain consensus, update the current
-   dnssec-bis document, test and implement a new authenticated denial
-   record.
-
-2.1.2.5  Pros
-
-   Does not introduce an iteration to DNSSEC while providing a clear and
-   clean migration strategy.
-
-
-
-Arends, et al.           Expires August 25, 2005                [Page 5]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-2.1.3  Type Bit Map NSEC Indicator
-
-   Bits in the type-bit-map are reused or allocated to signify the
-   interpretation of NSEC.
-
-   This proposal assumes that future extensions make use of the existing
-   NSEC RDATA syntax, while it may need to change the interpretation of
-   the RDATA or introduce an alternative denial mechanism, invoked by
-   the specific type-bit-map-bits.
-
-2.1.3.1  Coexistence and migration
-
-   Old and new NSEC meaning could coexist, depending how the signaling
-   would be defined.  The bits for NXT, NSEC, RRSIG or other outdated RR
-   types are available  as well as those covering meta/query types or
-   types to be specifically allocated.
-
-2.1.3.2  Limitations
-
-   This mechanism uses an NSEC field that was not designed for that
-   purpose.  Similar methods were discussed during the Opt-In discussion
-   and the Silly-State discussion.
-
-2.1.3.3  Amendments to DNSSEC-bis
-
-   The specific type-bit-map-bits must be allocated and they need to be
-   specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis)
-   interpretation.  Also, behaviour of the resolver and validator must
-   be documented in case unknown values are encountered for the MBZ
-   field.  Currently the protocol document specifies that the validator
-   MUST ignore the setting of the NSEC and the RRSIG bits, while other
-   bits are only used for the specific purpose of the type-bit-map field
-
-2.1.3.4  Cons
-
-   The type-bit-map was not designed for this purpose.  It is a
-   straightforward hack.  Text in protocol section 5.4 was put in
-   specially to defend against this usage.
-
-2.1.3.5  Pros
-
-   No change needed to the on-the-wire protocol as specified in the
-   current docset.
-
-2.1.4  New Apex Type
-
-   This introduces a new Apex type (parallel to the zone's SOA)
-   indicating the DNSSEC version (or authenticated denial) used in or
-
-
-
-Arends, et al.           Expires August 25, 2005                [Page 6]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-   for this zone.
-
-2.1.4.1  Coexistence and Migration
-
-   Depending on the design of this new RR type multiple denial
-   mechanisms may coexist in a zone.  Old validators will not understand
-   and thus ignore the new type, so interpretation of the new NSEC
-   scheme may fail, negative responses may appear 'bogus'.
-
-2.1.4.2  Limitations
-
-   A record of this kind is likely to carry additional
-   feature/versioning indications unrelated to the current question of
-   authenticated denial.
-
-2.1.4.3  Amendments to DNSSEC-bis
-
-   The current DNSSEC-bis documents need to be updated to indicate that
-   the absence of this type indicates dnssec-bis, and that the (mere)
-   presence of this type indicated unknown versions.
-
-2.1.4.4  Cons
-
-   The only other 'zone' or 'apex' record is the SOA record.  Though
-   this proposal is not new, it is yet unknown how it might fulfill
-   authenticated denial extensions.  This new RR type would only provide
-   for a generalized signaling mechanism, not the new authenticated
-   denial scheme.  Since it is likely to be general in nature, due to
-   this generality consensus is not to be reached soon.
-
-2.1.4.5  Pros
-
-   This approach would allow for a lot of other per zone information to
-   be transported or signaled to both (slave) servers and resolvers.
-
-2.1.5  NSEC White Lies
-
-   This proposal disables one part of NSEC (the pointer part) by means
-   of a special target (root, apex, owner, ...), leaving intact only the
-   ability to authenticate denial of existence of RR sets, not denial of
-   existence of domain names (NXDOMAIN).  It may be necessary to have
-   one working NSEC to prove the absence of a wildcard.
-
-2.1.5.1  Coexistence and Migration
-
-   The NSEC target can be specified per RR, so standard NSEC and 'white
-   lie' NSEC can coexist in a zone.  There is no need for migration
-   because no versioning is introduced or intended.
-
-
-
-Arends, et al.           Expires August 25, 2005                [Page 7]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-2.1.5.2  Limitations
-
-   This proposal breaks the protocol and is applicable to certain types
-   of zones only (no wildcard, no deep names, delegation only).  Most of
-   the burden is put on the resolver side and operational consequences
-   are yet to be studied.
-
-2.1.5.3  Amendments to DNSSEC-bis
-
-   The current DNSSEC-bis documents need to be updated to indicate that
-   the NXDOMAIN responses may be insecure.
-
-2.1.5.4  Cons
-
-   Strictly speaking this breaks the protocol and doesn't fully fulfill
-   the requirements for authenticated denial of existence.  Security
-   implications need to be carefully documented: search path problems
-   (forged denial of existence may lead to wrong expansion of non-FQDNs
-   [RFC1535]) and replay attacks to deny existence of records.
-
-2.1.5.5  Pros
-
-   Hardly any amendments to DNSSEC-bis.  Operational "trick" that is
-   available anyway.
-
-2.1.6  NSEC Optional via DNSSKEY Flag
-
-   A new DNSKEY may be defined to declare NSEC optional per zone.
-
-2.1.6.1  Coexistence and Migration
-
-   Current resolvers/validators will not understand the Flag bit and
-   will have to treat negative responses as bogus.  Otherwise, no
-   migration path is needed since NSEC is simply turned off.
-
-2.1.6.2  Limitations
-
-   NSEC can only be made completely optional at the cost of being unable
-   to prove unsecure delegations (absence of a DS RR [RFC3658]).  A next
-   to this approach would just disable authenticated denial for
-   non-existence of nodes.
-
-2.1.6.3  Amendments to DNSSEC-bis
-
-   New DNSKEY Flag to be defined.  Resolver/Validator behaviour needs to
-   be specified in the light of absence of authenticated denial.
-
-
-
-
-
-Arends, et al.           Expires August 25, 2005                [Page 8]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-2.1.6.4  Cons
-
-   Doesn't fully meet requirements.  Operational consequences to be
-   studied.
-
-2.1.6.5  Pros
-
-   Official version of the "trick" presented in (8).  Operational
-   problems can be addressed during future work on validators.
-
-2.1.7  New Answer Pseudo RR Type
-
-   A new pseudo RR type may be defined that will be dynamically created
-   (and signed) by the responding authoritative server.  The RR in the
-   response will cover the QNAME, QCLASS and QTYPE and will authenticate
-   both denial of existence of name (NXDOMAIN) or RRset.
-
-2.1.7.1  Coexistence and Migration
-
-   Current resolvers/validators will not understand the pseudo RR and
-   will thus not be able to process negative responses so testified.  A
-   signaling or solicitation method would have to be specified.
-
-2.1.7.2  Limitations
-
-   This method can only be used with online keys and online signing
-   capacity.
-
-2.1.7.3  Amendments to DNSSEC-bis
-
-   Signaling method needs to be defined.
-
-2.1.7.4  Cons
-
-   Keys have to be held and processed online with all security
-   implications.  An additional flag for those keys identifying them as
-   online or negative answer only keys should be considered.
-
-2.1.7.5  Pros
-
-   Expands DNSSEC authentication to the RCODE.
-
-2.1.8  SIG(0) Based Authenticated Denial
-
-
-2.1.8.1  Coexistence and Migration
-
-
-
-
-
-Arends, et al.           Expires August 25, 2005                [Page 9]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-2.1.8.2  Limitations
-
-
-2.1.8.3  Amendments to DNSSEC-bis
-
-
-2.1.8.4  Cons
-
-
-2.1.8.5  Pros
-
-
-2.2  Mechanisms Without Need of Updating DNSSEC-bis
-
-2.2.1  Partial Type-code and Signal Rollover
-
-   Carefully crafted type code/signal rollover to define a new
-   authenticated denial space that extends/replaces DNSSEC-bis
-   authenticated denial space.  This particular path is illuminated by
-   Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com>
-   posted to <namedroppers@ops.ietf.org> 2004-06-02.
-
-2.2.1.1  Coexistence and Migration
-
-   To protect the current resolver for future versions, a new DNSSEC-OK
-   bit must be allocated to make clear it does or does not understand
-   the future version.  Also, a new DS type needs to be allocated to
-   allow differentiation between a current signed delegation and a
-   'future' signed delegation.  Also, current NSEC needs to be rolled
-   into a new authenticated denial type.
-
-2.2.1.2  Limitations
-
-   None.
-
-2.2.1.3  Amendments to DNSSEC-bis
-
-   None.
-
-2.2.1.4  Cons
-
-   It is cumbersome to carefully craft an TCR that 'just fits'.  The
-   DNSSEC-bis protocol has many 'borderline' cases that needs special
-   consideration.  It might be easier to do a full TCR, since a few of
-   the types and signals need upgrading anyway.
-
-
-
-
-
-
-Arends, et al.           Expires August 25, 2005               [Page 10]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-2.2.1.5  Pros
-
-   Graceful adoption of future versions of NSEC, while there are no
-   amendments to DNSSEC-bis.
-
-2.2.2  A Complete Type-code and Signal Rollover
-
-   A new DNSSEC space is defined which can exist independent of current
-   DNSSEC-bis space.
-
-   This proposal assumes that all current DNSSEC type-codes
-   (RRSIG/DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any
-   future versions of DNSSEC.  Any future version of DNSSEC has its own
-   types to allow for keys, signatures, authenticated denial, etcetera.
-
-2.2.2.1  Coexistence and Migration
-
-   Both spaces can co-exist.  They can be made completely orthogonal.
-
-2.2.2.2  Limitations
-
-   None.
-
-2.2.2.3  Amendments to DNSSEC-bis
-
-   None.
-
-2.2.2.4  Cons
-
-   With this path we abandon the current DNSSEC-bis.  Though it is easy
-   to role specific well-known and well-tested parts into the re-write,
-   once deployment has started this path is very expensive for
-   implementers, registries, registrars and registrants as well as
-   resolvers/users.  A TCR is not to be expected to occur frequently, so
-   while a next generation authenticated denial may be enabled by a TCR,
-   it is likely that that TCR will only be agreed upon if it serves a
-   whole basket of changes or additions.  A quick introduction of
-   NSEC-ng should not be expected from this path.
-
-2.2.2.5  Pros
-
-   No amendments/changes to current DNSSEC-bis docset needed.  It is
-   always there as last resort.
-
-2.2.3  Unknown Algorithm in RRSIG
-
-   This proposal assumes that future extensions make use of the existing
-   NSEC RDATA syntax, while it may need to change the interpretation of
-
-
-
-Arends, et al.           Expires August 25, 2005               [Page 11]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-   the RDATA or introduce an alternative denial mechanism, invoked by
-   the specific unknown signing algorithm.  The different interpretation
-   would be signaled by use of different signature algorithms in the
-   RRSIG records covering the NSEC RRs.
-
-   When an entire zone is signed with a single unknown algorithm, it
-   will cause implementations that follow current dnssec-bis documents
-   to treat individual RRsets as unsigned.
-
-2.2.3.1  Coexistence and migration
-
-   Old and new NSEC RDATA interpretation or known and unknown Signatures
-   can NOT coexist in a zone since signatures cover complete (NSEC)
-   RRSets.
-
-2.2.3.2  Limitations
-
-   Validating resolvers agnostic of new interpretation will treat the
-   NSEC RRset as "not signed".  This affects wildcard and non-existence
-   proof, as well as proof for (un)secured delegations.  Also, all
-   positive signatures (RRSIGs on RRSets other than DS, NSEC) appear
-   insecure/bogus to an old validator.
-
-   The algorithm version space is split for each future version of
-   DNSSEC.  Violation of the 'modular components' concept.  We use the
-   'validator' to protect the 'resolver' from unknown interpretations.
-
-2.2.3.3  Amendments to DNSSEC-bis
-
-   None.
-
-2.2.3.4  Cons
-
-   The algorithm field was not designed for this purpose.  This is a
-   straightforward hack.
-
-2.2.3.5  Pros
-
-   No amendments/changes to current DNSSEC-bis docset needed.
-
-3.  Recommendation
-
-   The authors recommend that the working group commits to and starts
-   work on a partial TCR, allowing graceful transition towards a future
-   version of NSEC.  Meanwhile, to accomodate the need for an
-   immediately, temporary, solution against zone-traversal, we recommend
-   On-Demand NSEC synthesis.
-
-
-
-
-Arends, et al.           Expires August 25, 2005               [Page 12]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-   This approach does not require any mandatory changes to DNSSEC-bis,
-   does not violate the protocol and fulfills the requirements.  As a
-   side effect, it moves the cost of implementation and deployment to
-   the users (zone owners) of this mechanism.
-
-4.  Acknowledgements
-
-   The authors would like to thank Sam Weiler and Mark Andrews for their
-   input and constructive comments.
-
-5.  References
-
-5.1  Normative References
-
-   [I-D.ietf-dnsext-dnssec-intro]
-              Arends, R., Austein, R., Massey, D., Larson, M. and S.
-              Rose, "DNS Security Introduction and Requirements",
-              Internet-Draft draft-ietf-dnsext-dnssec-intro-13, October
-              2004.
-
-   [I-D.ietf-dnsext-dnssec-protocol]
-              Arends, R., "Protocol Modifications for the DNS Security
-              Extensions",
-              Internet-Draft draft-ietf-dnsext-dnssec-protocol-09,
-              October 2004.
-
-   [I-D.ietf-dnsext-dnssec-records]
-              Arends, R., "Resource Records for the DNS Security
-              Extensions",
-              Internet-Draft draft-ietf-dnsext-dnssec-records-11,
-              October 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.
-
-   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures (
-              SIG(0)s)", RFC 2931, September 2000.
-
-5.2  Informative References
-
-   [RFC1535]  Gavron, E., "A Security Problem and Proposed Correction
-              With Widely Deployed DNS Software", RFC 1535, October
-              1993.
-
-   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
-
-
-
-Arends, et al.           Expires August 25, 2005               [Page 13]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-              RFC 2535, March 1999.
-
-   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
-              June 1999.
-
-   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record
-              (RR)", RFC 3658, December 2003.
-
-
-Authors' Addresses
-
-   Roy Arends
-   Telematica Instituut
-   Brouwerijstraat 1
-   Enschede  7523 XC
-   The Netherlands
-
-   Phone: +31 53 4850485
-   Email: roy.arends@telin.nl
-
-
-   Peter Koch
-   DENIC eG
-   Wiesenh"uttenplatz 26
-   Frankfurt  60329
-   Germany
-
-   Phone: +49 69 27235 0
-   Email: pk@DENIC.DE
-
-
-   Jakob Schlyter
-   NIC-SE
-   Box 5774
-   Stockholm  SE-114 87
-   Sweden
-
-   Email: jakob@nic.se
-   URI:   http://www.nic.se/
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.           Expires August 25, 2005               [Page 14]
-
-Internet-Draft    Evaluating DNSSEC Transition Mechanisms  February 2005
-
-
-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 (2005).  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 August 25, 2005               [Page 15]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt
deleted file mode 100644
index 2460cb6..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt
+++ /dev/null
@@ -1,504 +0,0 @@
-
-
-
-Network Working Group                                        W. Hardaker
-Internet-Draft                                                    Sparta
-Expires: August 25, 2006                               February 21, 2006
-
-
- Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
-                   draft-ietf-dnsext-ds-sha256-05.txt
-
-Status of this Memo
-
-   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 becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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 25, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document specifies how to use the SHA-256 digest type in DNS
-   Delegation Signer (DS) Resource Records (RRs).  DS records, when
-   stored in a parent zone, point to key signing DNSKEY key(s) in a
-   child zone.
-
-
-
-
-
-
-
-
-Hardaker                 Expires August 25, 2006                [Page 1]
-
-Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.  Implementing the SHA-256 algorithm for DS record support  . . . 3
-     2.1.  DS record field values  . . . . . . . . . . . . . . . . . . 3
-     2.2.  DS Record with SHA-256 Wire Format  . . . . . . . . . . . . 3
-     2.3.  Example DS Record Using SHA-256 . . . . . . . . . . . . . . 4
-   3.  Implementation Requirements . . . . . . . . . . . . . . . . . . 4
-   4.  Deployment Considerations . . . . . . . . . . . . . . . . . . . 4
-   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
-   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
-     6.1.  Potential Digest Type Downgrade Attacks . . . . . . . . . . 5
-     6.2.  SHA-1 vs SHA-256 Considerations for DS Records  . . . . . . 6
-   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
-   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
-     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
-     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
-   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
-   Intellectual Property and Copyright Statements  . . . . . . . . . . 9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker                 Expires August 25, 2006                [Page 2]
-
-Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
-
-
-1.  Introduction
-
-   The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent
-   zones to distribute a cryptographic digest of a child's Key Signing
-   Key (KSK) DNSKEY RR.  The DS RRset is signed by at least one of the
-   parent zone's private zone data signing keys for each algorithm in
-   use by the parent.  Each signature is published in an RRSIG resource
-   record, owned by the same domain as the DS RRset and with a type
-   covered of DS.
-
-   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].
-
-
-2.  Implementing the SHA-256 algorithm for DS record support
-
-   This document specifies that the digest type code [XXX: To be
-   assigned by IANA; likely 2] is to be assigned to SHA-256 [SHA256]
-   [SHA256CODE] for use within DS records.  The results of the digest
-   algorithm MUST NOT be truncated and the entire 32 byte digest result
-   is to be published in the DS record.
-
-2.1.  DS record field values
-
-   Using the SHA-256 digest algorithm within a DS record will make use
-   of the following DS-record fields:
-
-   Digest type: [XXX: To be assigned by IANA; likely 2]
-
-   Digest: A SHA-256 bit digest value calculated by using the following
-      formula ("|" denotes concatenation).  The resulting value is not
-      truncated and the entire 32 byte result is to used in the
-      resulting DS record and related calculations.
-
-        digest = SHA_256(DNSKEY owner name | DNSKEY RDATA)
-
-      where DNSKEY RDATA is defined by [RFC4034] as:
-
-        DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key
-
-   The Key Tag field and Algorithm fields remain unchanged by this
-   document and are specified in the [RFC4034] specification.
-
-2.2.  DS Record with SHA-256 Wire Format
-
-   The resulting on-the-wire format for the resulting DS record will be
-   [XXX: IANA assignment should replace the 2 below]:
-
-
-
-Hardaker                 Expires August 25, 2006                [Page 3]
-
-Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
-
-
-                           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    | DigestType=2  |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      /                                                               /
-      /            Digest  (length for SHA-256 is 32 bytes)           /
-      /                                                               /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
-2.3.  Example DS Record Using SHA-256
-
-   The following is an example DNSKEY and matching DS record.  This
-   DNSKEY record comes from the example DNSKEY/DS records found in
-   section 5.4 of [RFC4034].
-
-   The DNSKEY record:
-
-   dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
-                                                fwJr1AYtsmx3TGkJaNXVbfi/
-                                                2pHm822aJ5iI9BMzNXxeYCmZ
-                                                DRD99WYwYqUSdjMmmAphXdvx
-                                                egXd/M5+X7OrzKBaMbCVdFLU
-                                                Uh6DhweJBjEVv5f2wwjM9Xzc
-                                                nOf+EPbtG9DMBmADjFDc2w/r
-                                                ljwvFw==
-                                                ) ;  key id = 60485
-
-   The resulting DS record covering the above DNSKEY record using a SHA-
-   256 digest: [RFC Editor: please replace XXX with the assigned digest
-   type (likely 2):]
-
-   dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C
-                                                CEB1E3E0614B93C4F9E99B83
-                                                83F6A1E4469DA50A )
-
-
-3.  Implementation Requirements
-
-   Implementations MUST support the use of the SHA-256 algorithm in DS
-   RRs.  Validator implementations SHOULD ignore DS RRs containing SHA-1
-   digests if DS RRs with SHA-256 digests are present in the DS RRset.
-
-
-4.  Deployment Considerations
-
-   If a validator does not support the SHA-256 digest type and no other
-   DS RR exists in a zone's DS RRset with a supported digest type, then
-
-
-
-Hardaker                 Expires August 25, 2006                [Page 4]
-
-Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
-
-
-   the validator 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 in [RFC4035], section 5.2.
-
-   Because zone administrators can not control the deployment speed of
-   support for SHA-256 in validators that may be referencing any of
-   their zones, zone operators should consider deploying both SHA-1 and
-   SHA-256 based DS records.  This should be done for every DNSKEY for
-   which DS records are being generated.  Whether to make use of both
-   digest types and for how long is a policy decision that extends
-   beyond the scope of this document.
-
-
-5.  IANA Considerations
-
-   Only one IANA action is required by this document:
-
-   The Digest Type to be used for supporting SHA-256 within DS records
-   needs to be assigned by IANA.  This document requests that the Digest
-   Type value of 2 be assigned to the SHA-256 digest algorithm.
-
-   At the time of this writing, the current digest types assigned for
-   use in DS records are as follows:
-
-      VALUE     Digest Type          Status
-        0       Reserved                -
-        1       SHA-1                MANDATORY
-        2       SHA-256              MANDATORY
-      3-255    Unassigned               -
-
-
-6.  Security Considerations
-
-6.1.  Potential Digest Type Downgrade Attacks
-
-   A downgrade attack from a stronger digest type to a weaker one is
-   possible if all of the following are true:
-
-   o  A zone includes multiple DS records for a given child's DNSKEY,
-      each of which use a different digest type.
-
-   o  A validator accepts a weaker digest even if a stronger one is
-      present but invalid.
-
-   For example, if the following conditions are all true:
-
-
-
-
-
-Hardaker                 Expires August 25, 2006                [Page 5]
-
-Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
-
-
-   o  Both SHA-1 and SHA-256 based digests are published in DS records
-      within a parent zone for a given child zone's DNSKEY.
-
-   o  The DS record with the SHA-1 digest matches the digest computed
-      using the child zone's DNSKEY.
-
-   o  The DS record with the SHA-256 digest fails to match the digest
-      computed using the child zone's DNSKEY.
-
-   Then if the validator accepts the above situation as secure then this
-   can be used as a downgrade attack since the stronger SHA-256 digest
-   is ignored.
-
-6.2.  SHA-1 vs SHA-256 Considerations for DS Records
-
-   Users of DNSSEC are encouraged to deploy SHA-256 as soon as software
-   implementations allow for it.  SHA-256 is widely believed to be more
-   resilient to attack than SHA-1, and confidence in SHA-1's strength is
-   being eroded by recently-announced attacks.  Regardless of whether or
-   not the attacks on SHA-1 will affect DNSSEC, it is believed (at the
-   time of this writing) that SHA-256 is the better choice for use in DS
-   records.
-
-   At the time of this publication, the SHA-256 digest algorithm is
-   considered sufficiently strong for the immediate future.  It is also
-   considered sufficient for use in DNSSEC DS RRs for the immediate
-   future.  However, future published attacks may weaken the usability
-   of this algorithm within the DS RRs.  It is beyond the scope of this
-   document to speculate extensively on the cryptographic strength of
-   the SHA-256 digest algorithm.
-
-   Likewise, it is also beyond the scope of this document to specify
-   whether or for how long SHA-1 based DS records should be
-   simultaneously published alongside SHA-256 based DS records.
-
-
-7.  Acknowledgments
-
-   This document is a minor extension to the existing DNSSEC documents
-   and those authors are gratefully appreciated for the hard work that
-   went into the base documents.
-
-   The following people contributed to portions of this document in some
-   fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Paul Hoffman,
-   Olaf M. Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam
-   Weiler.
-
-
-
-
-
-Hardaker                 Expires August 25, 2006                [Page 6]
-
-Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
-
-
-8.  References
-
-8.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements",
-              RFC 4033, March 2005.
-
-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Resource Records for the DNS Security Extensions",
-              RFC 4034, March 2005.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-   [SHA256]   National Institute of Standards and Technology, "Secure
-              Hash Algorithm. NIST FIPS 180-2", August 2002.
-
-8.2.  Informative References
-
-   [SHA256CODE]
-              Eastlake, D., "US Secure Hash Algorithms (SHA)",
-              June 2005.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker                 Expires August 25, 2006                [Page 7]
-
-Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
-
-
-Author's Address
-
-   Wes Hardaker
-   Sparta
-   P.O. Box 382
-   Davis, CA  95617
-   US
-
-   Email: hardaker@tislabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardaker                 Expires August 25, 2006                [Page 8]
-
-Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
-
-
-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 (2006).  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.
-
-
-
-
-Hardaker                 Expires August 25, 2006                [Page 9]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-ecc-key-07.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-ecc-key-07.txt
deleted file mode 100644
index 2cdcdb1..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-ecc-key-07.txt
+++ /dev/null
@@ -1,928 +0,0 @@
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-Expires: January 2006                                          July 2005
-
-
-
-                     Elliptic Curve KEYs in the DNS
-                     -------- ----- ---- -- --- ---
-                   <draft-ietf-dnsext-ecc-key-07.txt>
-
-                         Richard C. Schroeppel
-                          Donald Eastlake 3rd
-
-
-Status of This Document
-
-   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 becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   This draft is intended to be become a Proposed Standard RFC.
-   Distribution of this document is unlimited. Comments should be sent
-   to the DNS 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
-
-   The standard method for storing elliptic curve cryptographic keys and
-   signatures in the Domain Name System is specified.
-
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005). All Rights Reserved.
-
-
-
-
-
-R. Schroeppel, et al                                            [Page 1]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-Acknowledgement
-
-   The assistance of Hilarie K. Orman in the production of this document
-   is greatfully acknowledged.
-
-
-
-Table of Contents
-
-      Status of This Document....................................1
-      Abstract...................................................1
-      Copyright Notice...........................................1
-
-      Acknowledgement............................................2
-      Table of Contents..........................................2
-
-      1. Introduction............................................3
-      2. Elliptic Curve Data in Resource Records.................3
-      3. The Elliptic Curve Equation.............................9
-      4. How do I Compute Q, G, and Y?..........................10
-      5. Elliptic Curve SIG Resource Records....................11
-      6. Performance Considerations.............................13
-      7. Security Considerations................................13
-      8. IANA Considerations....................................13
-      Copyright and Disclaimer..................................14
-
-      Informational References..................................15
-      Normative Refrences.......................................15
-
-      Author's Addresses........................................16
-      Expiration and File Name..................................16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al                                            [Page 2]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-1. Introduction
-
-   The Domain Name System (DNS) is the global hierarchical replicated
-   distributed database system for Internet addressing, mail proxy, and
-   other information. The DNS has been extended to include digital
-   signatures and cryptographic keys as described in [RFC 4033, 4034,
-   4035].
-
-   This document describes how to store elliptic curve cryptographic
-   (ECC) keys and signatures in the DNS so they can be used for a
-   variety of security purposes.  Familiarity with ECC cryptography is
-   assumed [Menezes].
-
-   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. Elliptic Curve Data in Resource Records
-
-   Elliptic curve public keys are stored in the DNS within the RDATA
-   portions of key RRs, such as RRKEY and KEY [RFC 4034] RRs, with the
-   structure shown below.
-
-   The research world continues to work on the issue of which is the
-   best elliptic curve system, which finite field to use, and how to
-   best represent elements in the field.  So, representations are
-   defined for every type of finite field, and every type of elliptic
-   curve.  The reader should be aware that there is a unique finite
-   field with a particular number of elements, but many possible
-   representations of that field and its elements.  If two different
-   representations of a field are given, they are interconvertible with
-   a tedious but practical precomputation, followed by a fast
-   computation for each field element to be converted.  It is perfectly
-   reasonable for an algorithm to work internally with one field
-   representation, and convert to and from a different external
-   representation.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al                                            [Page 3]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-                            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
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |S M -FMT- A B Z|
-       +-+-+-+-+-+-+-+-+
-       |       LP      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        P (length determined from LP)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |       LF      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        F (length determined from LF)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |             DEG               |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |             DEGH              |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |             DEGI              |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |             DEGJ              |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |             TRDV              |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |S|     LH      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        H (length determined from LH)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |S|     LK      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        K (length determined from LK)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |       LQ      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        Q (length determined from LQ)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |       LA      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        A (length determined from LA)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |             ALTA              |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |       LB      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        B (length determined from LB)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |       LC      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        C (length determined from LC)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |       LG      |
-
-
-R. Schroeppel, et al                                            [Page 4]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        G (length determined from LG)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |       LY      |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |                        Y (length determined from LY)       .../
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   SMFMTABZ is a flags octet as follows:
-
-        S = 1 indicates that the remaining 7 bits of the octet selects
-           one of 128 predefined choices of finite field, element
-           representation, elliptic curve, and signature parameters.
-           MFMTABZ are omitted, as are all parameters from LP through G.
-           LY and Y are retained.
-
-        If S = 0, the remaining parameters are as in the picture and
-           described below.
-
-        M determines the type of field underlying the elliptic curve.
-
-        M = 0 if the field is a GF[2^N] field;
-
-        M = 1 if the field is a (mod P) or GF[P^D] field with P>2.
-
-        FMT is a three bit field describing the format of the field
-           representation.
-
-        FMT = 0  for a (mod P) field.
-            > 0  for an extension field, either GF[2^D] or GF[P^D].
-                The degree D of the extension, and the field polynomial
-                must be specified.  The field polynomial is always monic
-                (leading coefficient 1.)
-
-        FMT = 1  The field polynomial is given explicitly; D is implied.
-
-        If FMT >=2, the degree D is given explicitly.
-
-           = 2  The field polynomial is implicit.
-           = 3  The field polynomial is a binomial.  P>2.
-           = 4  The field polynomial is a trinomial.
-           = 5  The field polynomial is the quotient of a trinomial by a
-                short polynomial.  P=2.
-           = 6  The field polynomial is a pentanomial.  P=2.
-
-        Flags A and B apply to the elliptic curve parameters.
-
-
-
-
-
-
-R. Schroeppel, et al                                            [Page 5]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-        A = 1 When P>=5, the curve parameter A is negated.  If P=2, then
-              A=1 indicates that the A parameter is special.  See the
-              ALTA parameter below, following A.  The combination A=1,
-              P=3 is forbidden.
-
-        B = 1 When P>=5, the curve parameter B is negated.  If P=2 or 3,
-              then B=1 indicates an alternate elliptic curve equation is
-              used.  When P=2 and B=1, an additional curve parameter C
-              is present.
-
-        The Z bit SHOULD be set to zero on creation of an RR and MUST be
-           ignored when processing an RR (when S=0).
-
-   Most of the remaining parameters are present in some formats and
-   absent in others.  The presence or absence of a parameter is
-   determined entirely by the flags.  When a parameter occurs, it is in
-   the order defined by the picture.
-
-   Of the remaining parameters, PFHKQABCGY are variable length.  When
-   present, each is preceded by a one-octet length field as shown in the
-   diagram above.  The length field does not include itself.  The length
-   field may have values from 0 through 110.  The parameter length in
-   octets is determined by a conditional formula: If LL<=64, the
-   parameter length is LL.  If LL>64, the parameter length is 16 times
-   (LL-60).  In some cases, a parameter value of 0 is sensible, and MAY
-   be represented by an LL value of 0, with the data field omitted.  A
-   length value of 0 represents a parameter value of 0, not an absent
-   parameter.  (The data portion occupies 0 space.)  There is no
-   requirement that a parameter be represented in the minimum number of
-   octets; high-order 0 octets are allowed at the front end.  Parameters
-   are always right adjusted, in a field of length defined by LL.  The
-   octet-order is always most-significant first, least-significant last.
-   The parameters H and K may have an optional sign bit stored in the
-   unused high-order bit of their length fields.
-
-   LP defines the length of the prime P.  P must be an odd prime.  The
-   parameters LP,P are present if and only if the flag M=1.  If M=0, the
-   prime is 2.
-
-   LF,F define an explicit field polynomial.  This parameter pair is
-   present only when FMT = 1.  The length of a polynomial coefficient is
-   ceiling(log2 P) bits.  Coefficients are in the numerical range
-   [0,P-1].  The coefficients are packed into fixed-width fields, from
-   higher order to lower order.  All coefficients must be present,
-   including any 0s and also the leading coefficient (which is required
-   to be 1).  The coefficients are right justified into the octet string
-   of length specified by LF, with the low-order "constant" coefficient
-   at the right end.  As a concession to storage efficiency, the higher
-   order bits of the leading coefficient may be elided, discarding high-
-   order 0 octets and reducing LF.  The degree is calculated by
-
-
-R. Schroeppel, et al                                            [Page 6]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-   determining the bit position of the left most 1-bit in the F data
-   (counting the right most bit as position 0), and dividing by
-   ceiling(log2 P).  The division must be exact, with no remainder.  In
-   this format, all of the other degree and field parameters are
-   omitted.  The next parameters will be LQ,Q.
-
-   If FMT>=2, the degree of the field extension is specified explicitly,
-   usually along with other parameters to define the field polynomial.
-
-   DEG is a two octet field that defines the degree of the field
-   extension.  The finite field will have P^DEG elements.  DEG is
-   present when FMT>=2.
-
-   When FMT=2, the field polynomial is specified implicitly.  No other
-   parameters are required to define the field; the next parameters
-   present will be the LQ,Q pair.  The implicit field poynomial is the
-   lexicographically smallest irreducible (mod P) polynomial of the
-   correct degree.  The ordering of polynomials is by highest-degree
-   coefficients first -- the leading coefficient 1 is most important,
-   and the constant term is least important.  Coefficients are ordered
-   by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ...  The first polynomial of
-   degree D is X^D (which is not irreducible).  The next is X^D+1, which
-   is sometimes irreducible, followed by X^D-1, which isn't.  Assuming
-   odd P, this series continues to X^D - (P-1)/2, and then goes to X^D +
-   X, X^D + X + 1, X^D + X - 1, etc.
-
-   When FMT=3, the field polynomial is a binomial, X^DEG + K.  P must be
-   odd.  The polynomial is determined by the degree and the low order
-   term K.  Of all the field parameters, only the LK,K parameters are
-   present.  The high-order bit of the LK octet stores on optional sign
-   for K; if the sign bit is present, the field polynomial is X^DEG - K.
-
-   When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH +
-   K.  When P=2, the H and K parameters are implicitly 1, and are
-   omitted from the representation.  Only DEG and DEGH are present; the
-   next parameters are LQ,Q.  When P>2, then LH,H and LK,K are
-   specified.  Either or both of LH, LK may contain a sign bit for its
-   parameter.
-
-   When FMT=5, then P=2 (only).  The field polynomial is the exact
-   quotient of a trinomial divided by a small polynomial, the trinomial
-   divisor.  The small polynomial is right-adjusted in the two octet
-   field TRDV.  DEG specifies the degree of the field.  The degree of
-   TRDV is calculated from the position of the high-order 1 bit.  The
-   trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1.  If
-   DEGH is 0, the middle term is omitted from the trinomial.  The
-   quotient must be exact, with no remainder.
-
-   When FMT=6, then P=2 (only).  The field polynomial is a pentanomial,
-   with the degrees of the middle terms given by the three 2-octet
-
-
-R. Schroeppel, et al                                            [Page 7]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-   values DEGH, DEGI, DEGJ.  The polynomial is X^DEG + X^DEGH + X^DEGI +
-   X^DEGJ + 1.  The values must satisfy the inequality DEG > DEGH > DEGI
-   > DEGJ > 0.
-
-        DEGH, DEGI, DEGJ  are two-octet fields that define the degree of
-           a term in a field polynomial.   DEGH is present when FMT = 4,
-           5, or 6.  DEGI and DEGJ are present only when FMT = 6.
-
-        TRDV is a two-octet right-adjusted binary polynomial of degree <
-           16.  It is present only for FMT=5.
-
-        LH and H define the H parameter, present only when FMT=4 and P
-           is odd.  The high bit of LH is an optional sign bit for H.
-
-        LK and K define the K parameter, present when FMT = 3 or 4, and
-           P is odd.  The high bit of LK is an optional sign bit for K.
-
-   The remaining parameters are concerned with the elliptic curve and
-   the signature algorithm.
-
-        LQ defines the length of the prime Q.  Q is a prime > 2^159.
-
-   In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data
-   member of the pair is an element from the finite field defined
-   earlier.  The length field defines a long octet string.  Field
-   elements are represented as (mod P) polynomials of degree < DEG, with
-   DEG or fewer coefficients.  The coefficients are stored from left to
-   right, higher degree to lower, with the constant term last.  The
-   coefficients are represented as integers in the range [0,P-1].  Each
-   coefficient is allocated an area of ceiling(log2 P) bits.  The field
-   representation is right-justified; the "constant term" of the field
-   element ends at the right most bit.  The coefficients are fitted
-   adjacently without regard for octet boundaries.  (Example: if P=5,
-   three bits are used for each coefficient.  If the field is GF[5^75],
-   then 225 bits are required for the coefficients, and as many as 29
-   octets may be needed in the data area.  Fewer octets may be used if
-   some high-order coefficients are 0.)  If a flag requires a field
-   element to be negated, each non-zero coefficient K is replaced with
-   P-K.  To save space, 0 bits may be removed from the left end of the
-   element representation, and the length field reduced appropriately.
-   This would normally only happen with A,B,C, because the designer
-   chose curve parameters with some high-order 0 coefficients or bits.
-
-   If the finite field is simply (mod P), then the field elements are
-   simply numbers (mod P), in the usual right-justified notation.  If
-   the finite field is GF[2^D], the field elements are the usual right-
-   justified polynomial basis representation.
-
-
-
-
-
-R. Schroeppel, et al                                            [Page 8]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-        LA,A is the first parameter of the elliptic curve equation.
-           When P>=5, the flag A = 1 indicates A should be negated (mod
-           P).  When P=2 (indicated by the flag M=0), the flag A = 1
-           indicates that the parameter pair LA,A is replaced by the two
-           octet parameter ALTA.  In this case, the parameter A in the
-           curve equation is x^ALTA, where x is the field generator.
-           Parameter A often has the value 0, which may be indicated by
-           LA=0 (with no A data field), and sometimes A is 1, which may
-           be represented with LA=1 and a data field of 1, or by setting
-           the A flag and using an ALTA value of 0.
-
-        LB,B is the second parameter of the elliptic curve equation.
-           When P>=5, the flag B = 1 indicates B should be negated (mod
-           P).  When P=2 or 3, the flag B selects an alternate curve
-           equation.
-
-        LC,C is the third parameter of the elliptic curve equation,
-           present only when P=2 (indicated by flag M=0) and flag B=1.
-
-        LG,G defines a point on the curve, of order Q.  The W-coordinate
-           of the curve point is given explicitly; the Z-coordinate is
-           implicit.
-
-        LY,Y is the user's public signing key, another curve point of
-           order Q.  The W-coordinate is given explicitly; the Z-
-           coordinate is implicit.  The LY,Y parameter pair is always
-           present.
-
-
-
-3. The Elliptic Curve Equation
-
-   (The coordinates of an elliptic curve point are named W,Z instead of
-   the more usual X,Y to avoid confusion with the Y parameter of the
-   signing key.)
-
-   The elliptic curve equation is determined by the flag octet, together
-   with information about the prime P.  The primes 2 and 3 are special;
-   all other primes are treated identically.
-
-   If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3
-   + A*W + B.  Z,W,A,B are all numbers (mod P) or elements of GF[P^D].
-   If A and/or B is negative (i.e., in the range from P/2 to P), and
-   P>=5, space may be saved by putting the sign bit(s) in the A and B
-   bits of the flags octet, and the magnitude(s) in the parameter
-   fields.
-
-   If M=1 and P=3, the B flag has a different meaning: it specifies an
-   alternate curve equation, Z^2 = W^3 + A*W^2 + B.  The middle term of
-   the right-hand-side is different.  When P=3, this equation is more
-
-
-R. Schroeppel, et al                                            [Page 9]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-   commonly used.
-
-   If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 +
-   A*W^2 + B.  Z,W,A,B are all elements of the field GF[2^N].  The A
-   parameter can often be 0 or 1, or be chosen as a single-1-bit value.
-   The flag B is used to select an alternate curve equation, Z^2 + C*Z =
-   W^3 + A*W + B.  This is the only time that the C parameter is used.
-
-
-
-4. How do I Compute Q, G, and Y?
-
-   The number of points on the curve is the number of solutions to the
-   curve equation, + 1 (for the "point at infinity").  The prime Q must
-   divide the number of points.  Usually the curve is chosen first, then
-   the number of points is determined with Schoof's algorithm.  This
-   number is factored, and if it has a large prime divisor, that number
-   is taken as Q.
-
-   G must be a point of order Q on the curve, satisfying the equation
-
-        Q * G  =  the point at infinity (on the elliptic curve)
-
-   G may be chosen by selecting a random [RFC 1750] curve point, and
-   multiplying it by (number-of-points-on-curve/Q).  G must not itself
-   be the "point at infinity"; in this astronomically unlikely event, a
-   new random curve point is recalculated.
-
-   G is specified by giving its W-coordinate.  The Z-coordinate is
-   calculated from the curve equation.  In general, there will be two
-   possible Z values.  The rule is to choose the "positive" value.
-
-   In the (mod P) case, the two possible Z values sum to P.  The smaller
-   value is less than P/2; it is used in subsequent calculations.  In
-   GF[P^D] fields, the highest-degree non-zero coefficient of the field
-   element Z is used; it is chosen to be less than P/2.
-
-   In the GF[2^N] case, the two possible Z values xor to W (or to the
-   parameter C with the alternate curve equation).  The numerically
-   smaller Z value (the one which does not contain the highest-order 1
-   bit of W (or C)) is used in subsequent calculations.
-
-   Y is specified by giving the W-coordinate of the user's public
-   signature key.  The Z-coordinate value is determined from the curve
-   equation.  As with G, there are two possible Z values; the same rule
-   is followed for choosing which Z to use.
-
-
-
-
-
-
-R. Schroeppel, et al                                           [Page 10]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-   During the key generation process, a random [RFC 1750] number X must
-   be generated such that 1 <= X <= Q-1.  X is the private key and is
-   used in the final step of public key generation where Y is computed
-   as
-
-        Y = X * G (as points on the elliptic curve)
-
-   If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2
-   in the (mod P) case, or the high-order non-zero coefficient of Z >
-   P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the
-   GF[2^N] case), then X must be replaced with Q-X.  This will
-   correspond to the correct Z-coordinate.
-
-
-
-5. Elliptic Curve SIG Resource Records
-
-   The signature portion of an RR RDATA area when using the EC
-   algorithm, for example in the RRSIG and SIG [RFC records] RRs is
-   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
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                   R, (length determined from LQ)           .../
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                   S, (length determined from LQ)           .../
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   R and S are integers (mod Q).  Their length is specified by the LQ
-   field of the corresponding KEY RR and can also be calculated from the
-   SIG RR's RDLENGTH. They are right justified, high-order-octet first.
-   The same conditional formula for calculating the length from LQ is
-   used as for all the other length fields above.
-
-   The data signed is determined as specified in [RFC 2535].  Then the
-   following steps are taken where Q, P, G, and Y are as specified in
-   the public key [Schneier]:
-
-     hash = SHA-1 ( data )
-
-     Generate random [RFC 4086] K such that 0 < K < Q.  (Never sign two
-          different messages with the same K.  K should be chosen from a
-          very large space: If an opponent learns a K value for a single
-          signature, the user's signing key is compromised, and a forger
-          can sign arbitrary messages. There is no harm in signing the
-          same message multiple times with the same key or different
-          keys.)
-
-     R = (the W-coordinate of ( K*G on the elliptic curve )) interpreted
-
-
-R. Schroeppel, et al                                           [Page 11]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-          as an integer, and reduced (mod Q).  (R must not be 0.  In
-          this astronomically unlikely event, generate a new random K
-          and recalculate R.)
-
-     S = ( K^(-1) * (hash + X*R) ) mod Q.
-
-     S must not be 0.  In this astronomically unlikely event, generate a
-          new random K and recalculate R and S.
-
-     If S > Q/2, set S = Q - S.
-
-     The pair (R,S) is the signature.
-
-     Another party verifies the signature as follows:
-
-          Check that 0 < R < Q and 0 < S < Q/2.  If not, it can not be a
-               valid EC sigature.
-
-          hash = SHA-1 ( data )
-
-          Sinv = S^(-1) mod Q.
-
-          U1 = (hash * Sinv) mod Q.
-
-          U2 = (R * Sinv) mod Q.
-
-          (U1 * G + U2 * Y) is computed on the elliptic curve.
-
-          V = (the W-coordinate of this point) interpreted as an integer
-               and reduced (mod Q).
-
-          The signature is valid if V = R.
-
-     The reason for requiring S < Q/2 is that, otherwise, both (R,S) and
-     (R,Q-S) would be valid signatures for the same data.  Note that a
-     signature that is valid for hash(data) is also valid for
-     hash(data)+Q or hash(data)-Q, if these happen to fall in the range
-     [0,2^160-1].  It's believed to be computationally infeasible to
-     find data that hashes to an assigned value, so this is only a
-     cosmetic blemish.  The blemish can be eliminated by using Q >
-     2^160, at the cost of having slightly longer signatures, 42 octets
-     instead of 40.
-
-     We must specify how a field-element E ("the W-coordinate") is to be
-     interpreted as an integer.  The field-element E is regarded as a
-     radix-P integer, with the digits being the coefficients in the
-     polynomial basis representation of E.  The digits are in the ragne
-     [0,P-1].  In the two most common cases, this reduces to "the
-     obvious thing".  In the (mod P) case, E is simply a residue mod P,
-     and is taken as an integer in the range [0,P-1].  In the GF[2^D]
-
-
-R. Schroeppel, et al                                           [Page 12]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-     case, E is in the D-bit polynomial basis representation, and is
-     simply taken as an integer in the range [0,(2^D)-1].  For other
-     fields GF[P^D], it's necessary to do some radix conversion
-     arithmetic.
-
-
-
-  6. Performance Considerations
-
-     Elliptic curve signatures use smaller moduli or field sizes than
-     RSA and DSA.  Creation of a curve is slow, but not done very often.
-     Key generation is faster than RSA or DSA.
-
-     DNS implementations have been optimized for small transfers,
-     typically less than 512 octets including DNS overhead. Larger
-     transfers will perform correctly and and extensions have been
-     standardized to make larger transfers more efficient [RFC 2671].
-     However, it is still advisable at this time to make reasonable
-     efforts to minimize the size of RR sets stored within the DNS
-     consistent with adequate security.
-
-
-
-  7. Security Considerations
-
-     Keys retrieved from the DNS should not be trusted unless (1) they
-     have been securely obtained from a secure resolver or independently
-     verified by the user and (2) this secure resolver and secure
-     obtainment or independent verification conform to security policies
-     acceptable to the user.  As with all cryptographic algorithms,
-     evaluating the necessary strength of the key is essential and
-     dependent on local policy.
-
-     Some specific key generation considerations are given in the body
-     of this document.
-
-
-
-  8. IANA Considerations
-
-     The key and signature data structures defined herein correspond to
-     the value 4 in the Algorithm number field of the IANA registry
-
-     Assignment of meaning to the remaining ECC data flag bits or to
-     values of ECC fields outside the ranges for which meaning in
-     defined in this document requires an IETF consensus as defined in
-     [RFC 2434].
-
-
-
-
-
-R. Schroeppel, et al                                           [Page 13]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-  Copyright and Disclaimer
-
-     Copyright (C) The Internet Society 2005.  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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al                                           [Page 14]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-  Informational References
-
-     [RFC 1034] - P. Mockapetris, "Domain names - concepts and
-     facilities", 11/01/1987.
-
-     [RFC 1035] - P. Mockapetris, "Domain names - implementation and
-     specification", 11/01/1987.
-
-     [RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)",
-     August 1999.
-
-     [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and
-     S. Rose, "DNS Security Introduction and Requirements", RFC 4033,
-     March 2005.
-
-     [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and
-     S. Rose, "Protocol Modifications for the DNS Security Extensions",
-     RFC 4035, March 2005.
-
-     [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
-     "Randomness Requirements for Security", BCP 106, RFC 4086, June
-     2005.
-
-     [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
-     Algorithms, and Source Code in C", 1996, John Wiley and Sons
-
-     [Menezes] - Alfred Menezes, "Elliptic Curve Public Key
-     Cryptosystems", 1993 Kluwer.
-
-     [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic
-     Curves", 1986, Springer Graduate Texts in mathematics #106.
-
-
-
-  Normative Refrences
-
-     [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
-     Requirement Levels", March 1997.
-
-     [RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an
-     IANA Considerations Section in RFCs", October 1998.
-
-     [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and
-     S. Rose, "Resource Records for the DNS Security Extensions", RFC
-     4034, March 2005.
-
-
-
-
-
-
-
-R. Schroeppel, et al                                           [Page 15]
-
-
-INTERNET-DRAFT                                       ECC Keys in the DNS
-
-
-  Author's Addresses
-
-     Rich Schroeppel
-     500 S. Maple Drive
-     Woodland Hills, UT 84653 USA
-
-     Telephone:   +1-505-844-9079(w)
-     Email:       rschroe@sandia.gov
-
-
-     Donald E. Eastlake 3rd
-     Motorola Laboratories
-     155 Beaver Street
-     Milford, MA 01757 USA
-
-     Telephone:   +1 508-786-7554 (w)
-     EMail:       Donald.Eastlake@motorola.com
-
-
-
-  Expiration and File Name
-
-     This draft expires in January 2006.
-
-     Its file name is draft-ietf-dnsext-ecc-key-07.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al                                           [Page 16]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-02.txt
deleted file mode 100644
index 160afc3..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-interop3597-02.txt
+++ /dev/null
@@ -1,334 +0,0 @@
-DNS Extensions Working Group                                 J. Schlyter
-Internet-Draft                                              May 19, 2005
-Expires: November 20, 2005
-
-
-                     RFC 3597 Interoperability Report
-                   draft-ietf-dnsext-interop3597-02.txt
-
-Status of this Memo
-
-    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 becomes
-    aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-    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 November 20, 2005.
-
-Copyright Notice
-
-    Copyright (C) The Internet Society (2005).
-
-Abstract
-
-    This memo documents the result from the RFC 3597 (Handling of Unknown
-    DNS Resource Record Types) interoperability testing.
-
-
-
-
-
-
-
-
-
-
-Schlyter                Expires November 20, 2005               [Page 1]
-
-Internet-Draft      RFC 3597 Interoperability Report            May 2005
-
-
-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  . . . . . . . . . . . . . . . . .  4
-      3.4   Stub Resolver  . . . . . . . . . . . . . . . . . . . . . .  4
-      3.5   DNSSEC Signer  . . . . . . . . . . . . . . . . . . . . . .  4
-    4.  Problems found . . . . . . . . . . . . . . . . . . . . . . . .  4
-    5.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
-    6.  Normative References . . . . . . . . . . . . . . . . . . . . .  4
-        Author's Address . . . . . . . . . . . . . . . . . . . . . . .  4
-    A.  Test zone data . . . . . . . . . . . . . . . . . . . . . . . .  5
-        Intellectual Property and Copyright Statements . . . . . . . .  6
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter                Expires November 20, 2005               [Page 2]
-
-Internet-Draft      RFC 3597 Interoperability Report            May 2005
-
-
-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
-    tested for compliance with RFC 3597:
-
-       DNSJava 1.6.4
-       ISC BIND 8.4.5
-       ISC BIND 9.3.0
-       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)
-
-    All listed implementations are genetically different.
-
-3.  Tests
-
-    The following tests was been performed to validate compliance with
-    RFC 3597 section 3 ("Transparency"), 4 ("Domain Name Compression")
-    and 5 ("Text Representation").
-
-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.
-
-
-
-
-
-
-Schlyter                Expires November 20, 2005               [Page 3]
-
-Internet-Draft      RFC 3597 Interoperability Report            May 2005
-
-
-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
-    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.
-
-6.  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 November 20, 2005               [Page 4]
-
-Internet-Draft      RFC 3597 Interoperability Report            May 2005
-
-
-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 November 20, 2005               [Page 5]
-
-Internet-Draft      RFC 3597 Interoperability Report            May 2005
-
-
-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 (2005).  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 November 20, 2005               [Page 6]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt
deleted file mode 100644
index 6bffb70..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt
+++ /dev/null
@@ -1,560 +0,0 @@
-
-DNS Extensions                                                O. Kolkman
-Internet-Draft                                                  RIPE NCC
-Expires: June 17, 2004                                       J. Schlyter
-
-                                                                E. Lewis
-                                                                    ARIN
-                                                       December 18, 2003
-
-
-                   DNSKEY RR Secure Entry Point Flag
-              draft-ietf-dnsext-keyrr-key-signing-flag-12
-
-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 June 17, 2004.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
-   With the Delegation Signer (DS) resource record the concept of a
-   public key acting as a secure entry point has been introduced. During
-   exchanges of public keys with the parent there is a need to
-   differentiate secure entry point keys from other public keys in the
-   DNSKEY resource record (RR) set.  A flag bit in the DNSKEY RR is
-   defined to indicate that DNSKEY is to be used as a secure entry
-   point. The flag bit is intended to assist in operational procedures
-   to correctly generate DS resource records, or to indicate what
-   DNSKEYs are intended for static configuration. The flag bit is not to
-
-
-
-Kolkman, et al.          Expires June 17, 2004                  [Page 1]
-
-Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
-
-
-   be used in the DNS verification protocol. This document updates RFC
-   2535 and RFC 3445.
-
-Table of Contents
-
-   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2. The Secure Entry Point (SEP) Flag  . . . . . . . . . . . . . . . 4
-   3. DNSSEC Protocol Changes  . . . . . . . . . . . . . . . . . . . . 5
-   4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . . 5
-   5. Security Considerations  . . . . . . . . . . . . . . . . . . . . 6
-   6. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . 6
-   7. Internationalization Considerations  . . . . . . . . . . . . . . 6
-   8. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . . 6
-      Normative References . . . . . . . . . . . . . . . . . . . . . . 7
-      Informative References . . . . . . . . . . . . . . . . . . . . . 7
-      Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
-      Intellectual Property and Copyright Statements . . . . . . . . . 9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al.          Expires June 17, 2004                  [Page 2]
-
-Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
-
-
-1. Introduction
-
-   "All keys are equal but some keys are more equal than others" [6]
-
-   With the definition of the Delegation Signer Resource Record (DS RR)
-   [5] it has become important to differentiate between the keys in the
-   DNSKEY RR set that are (to be) pointed to by parental DS RRs and the
-   other keys in the DNSKEY RR set.  We refer to these public keys as
-   Secure Entry Point (SEP) keys.  A SEP key either used to generate a
-   DS RR or is distributed to resolvers that use the key as the root of
-   a trusted subtree[3].
-
-   In early deployment tests, the use of two (kinds of) key pairs for
-   each zone has been prevalent.  For one kind of key pair the private
-   key is used to sign just the zone's DNSKEY resource record (RR) set.
-   Its public key is intended to be referenced by a DS RR at the parent
-   or configured statically in a resolver.  The private key of the other
-   kind of key pair is used to sign the rest of the zone's data sets.
-   The former key pair is called a key-signing key (KSK) and the latter
-   is called a zone-signing key (ZSK).  In practice there have been
-   usually one of each kind of key pair, but there will be multiples of
-   each at times.
-
-   It should be noted that division of keys pairs into KSK's and ZSK's
-   is not mandatory in any definition of DNSSEC, not even with the
-   introduction of the DS RR.  But, in testing, this distinction has
-   been helpful when designing key roll over (key super-cession)
-   schemes.  Given that the distinction has proven helpful, the labels
-   KSK and ZSK have begun to stick.
-
-   There is a need to differentiate the public keys for the key pairs
-   that are used for key signing from keys that are not used key signing
-   (KSKs vs ZSKs). This need is driven by knowing which DNSKEYs are to
-   be sent for generating DS RRs, which DNSKEYs are to be distributed to
-   resolvers, and which keys are fed to the signer application at the
-   appropriate time.
-
-   In other words, the SEP bit provides an in-band method to communicate
-   a DNSKEY RR's intended use to third parties. As an example we present
-   3 use cases in which the bit is useful:
-
-      The parent is a registry, the parent and the child use secured DNS
-      queries and responses, with a preexisting trust-relation, or plain
-      DNS over a secured channel to exchange the child's  DNSKEY RR
-      sets. Since a DNSKEY RR set will contain a complete DNSKEY RRset
-      the SEP bit can be used to isolate the DNSKEYs for which a DS RR
-      needs to be created.
-
-
-
-
-Kolkman, et al.          Expires June 17, 2004                  [Page 3]
-
-Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
-
-
-      An administrator has configured a DNSKEY as root for a trusted
-      subtree into security aware resolver. Using a special purpose tool
-      that queries for the KEY RRs from that domain's apex, the
-      administrator will be able to notice the roll over of the trusted
-      anchor by a change of the subset of KEY RRs with the DS flag set.
-
-      A signer might use the SEP bit on the public key to determine
-      which private key to use to exclusively sign the DNSKEY RRset and
-      which private key to use to sign the other RRsets in the zone.
-
-   As demonstrated in the above examples it is important to be able to
-   differentiate the SEP keys from the other keys in a DNSKEY RR set in
-   the flow between signer and (parental) key-collector and in the flow
-   between the signer and the resolver configuration. The SEP flag is to
-   be of no interest to the flow between the verifier and the
-   authoritative data store.
-
-   The reason for the term "SEP" is a result of the observation that the
-   distinction between KSK and ZSK key pairs is made by the signer, a
-   key pair could be used as both a KSK and a ZSK at the same time. To
-   be clear, the term SEP was coined to lessen the confusion caused by
-   the overlap. ( Once this label was applied, it had the side effect of
-   removing the temptation to have both a KSK flag bit and a ZSK flag
-   bit.)
-
-   The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
-   "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
-   interpreted as described in RFC2119 [1].
-
-2. The Secure Entry Point (SEP) Flag
-
-
-                           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          |S|   protocol    |   algorithm   |
-      |                             |E|               |               |
-      |                             |P|               |               |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                                                               /
-      /                        public key                             /
-      /                                                               /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-                                DNSKEY RR Format
-
-
-
-
-
-
-Kolkman, et al.          Expires June 17, 2004                  [Page 4]
-
-Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
-
-
-   This document assigns the 15'th bit in the flags field as the secure
-   entry point (SEP) bit.  If the the bit is set to 1 the key is
-   intended to be used as secure entry point key.  One SHOULD NOT assign
-   special meaning to the key if the bit is set to 0.  Operators can
-   recognize the secure entry point key by the even or odd-ness of the
-   decimal representation of the flag field.
-
-3. DNSSEC Protocol Changes
-
-   The bit MUST NOT be used during the resolving and verification
-   process. The SEP flag is only used to provide a hint about the
-   different administrative properties of the key and therefore the use
-   of the SEP flag does not change the DNS resolution protocol or the
-   resolution process.
-
-4. Operational Guidelines
-
-   The SEP bit is set by the key-pair-generator and MAY be used by the
-   zone signer to decide whether the public part of the key pair is to
-   be prepared for input to a DS RR generation function.  The SEP bit is
-   recommended to be set (to 1) whenever the public key of the key pair
-   will be distributed to the parent zone to build the authentication
-   chain or if the public key is to be distributed for static
-   configuration in verifiers.
-
-   When a key pair is created, the operator needs to indicate whether
-   the SEP bit is to be set in the DNSKEY RR.  As the SEP bit is within
-   the data that is used to compute the 'key tag field' in the SIG RR,
-   changing the SEP bit will change the identity of the key within DNS.
-   In other words, once a key is used to generate signatures, the
-   setting of the SEP bit is to remain constant. If not, a verifier will
-   not be able to find the relevant KEY RR.
-
-   When signing a zone, it is intended that the key(s) with the SEP bit
-   set (if such keys exist) are used to sign the KEY RR set of the zone.
-   The same key can be used to sign the rest of the zone data too.  It
-   is conceivable that not all keys with a SEP bit set will sign the
-   DNSKEY RR set, such keys might be pending retirement or not yet in
-   use.
-
-   When verifying a RR set, the SEP bit is not intended to play a role.
-   How the key is used by the verifier is not intended to be a
-   consideration at key creation time.
-
-   Although the SEP flag provides a hint on which public key is to be
-   used as trusted root, administrators can choose to ignore the fact
-   that a DNSKEY has its SEP bit set or not when configuring a trusted
-   root for their resolvers.
-
-
-
-Kolkman, et al.          Expires June 17, 2004                  [Page 5]
-
-Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
-
-
-   Using the SEP flag a key roll over can be automated. The parent can
-   use an existing trust relation to verify DNSKEY RR sets in which a
-   new DNSKEY RR with the SEP flag appears.
-
-5. Security Considerations
-
-   As stated in Section 3 the flag is not to be used in the resolution
-   protocol or to determine the security status of a key. The flag is to
-   be used for administrative purposes only.
-
-   No trust in a key should be inferred from this flag - trust MUST be
-   inferred from an existing chain of trust or an out-of-band exchange.
-
-   Since this flag might be used for automating public key exchanges, we
-   think the following consideration is in place.
-
-   Automated mechanisms for roll over of the DS RR might be vulnerable
-   to a class of replay attacks.  This might happen after a public key
-   exchange where a DNSKEY RR set, containing two DNSKEY RRs with the
-   SEP flag set, is sent to the parent.  The parent verifies the DNSKEY
-   RR set with the existing trust relation and creates the new DS RR
-   from the DNSKEY RR that the current DS RR is not pointing to.  This
-   key exchange might be replayed. Parents are encouraged to implement a
-   replay defense. A simple defense can be based on a registry of keys
-   that have been used to generate DS RRs during the most recent roll
-   over. These same considerations apply to entities that configure keys
-   in resolvers.
-
-6. IANA Considerations
-
-   The flag bits  in the DNSKEY RR are assigned by IETF consensus and
-   registered in the DNSKEY Flags registry (created by [4]). This
-   document assigns the 15th bit in the DNSKEY RR as the Secure Entry
-   Point (SEP) bit.
-
-7. Internationalization Considerations
-
-   Although SEP is a popular acronym in many different languages, there
-   are no internationalization considerations.
-
-8. Acknowledgments
-
-   The ideas documented in this document are inspired by communications
-   we had with numerous people and ideas published by other folk. Among
-   others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson,
-   Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler
-   have contributed ideas and provided feedback.
-
-
-
-
-Kolkman, et al.          Expires June 17, 2004                  [Page 6]
-
-Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
-
-
-   This document saw the light during a workshop on DNSSEC operations
-   hosted by USC/ISI in August 2002.
-
-Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Eastlake, D., "Domain Name System Security Extensions", RFC
-        2535, March 1999.
-
-   [3]  Lewis, E., "DNS Security Extension Clarification on Zone
-        Status", RFC 3090, March 2001.
-
-   [4]  Weiler, S., "Legacy Resolver Compatibility for Delegation
-        Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work
-        in progress), October 2003.
-
-Informative References
-
-   [5]  Gudmundsson, O., "Delegation Signer Resource Record",
-        draft-ietf-dnsext-delegation-signer-15 (work in progress), June
-        2003.
-
-   [6]  Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy
-        Story", ISBN 0151002177 (50th anniversary edition), April 1996.
-
-
-Authors' Addresses
-
-   Olaf M. Kolkman
-   RIPE NCC
-   Singel 256
-   Amsterdam  1016 AB
-   NL
-
-   Phone: +31 20 535 4444
-   EMail: olaf@ripe.net
-   URI:   http://www.ripe.net/
-
-
-   Jakob Schlyter
-   Karl Gustavsgatan 15
-   Goteborg  SE-411 25
-   Sweden
-
-   EMail: jakob@schlyter.se
-
-
-
-
-Kolkman, et al.          Expires June 17, 2004                  [Page 7]
-
-Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
-
-
-   Edward P. Lewis
-   ARIN
-   3635 Concorde Parkway Suite 200
-   Chantilly, VA  20151
-   US
-
-   Phone: +1 703 227 9854
-   EMail: edlewis@arin.net
-   URI:   http://www.arin.net/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al.          Expires June 17, 2004                  [Page 8]
-
-Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
-
-
-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 (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 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, et al.          Expires June 17, 2004                  [Page 9]
-
-Internet-Draft     DNSKEY RR Secure Entry Point Flag       December 2003
-
-
-   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, et al.          Expires June 17, 2004                 [Page 10]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-43.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-43.txt
deleted file mode 100644
index 5de6e85..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-mdns-43.txt
+++ /dev/null
@@ -1,1740 +0,0 @@
-
-
-
-
-
-
-DNSEXT Working Group                                       Bernard Aboba
-INTERNET-DRAFT                                               Dave Thaler
-Category: Standards Track                                   Levon Esibov
-<draft-ietf-dnsext-mdns-43.txt>                    Microsoft Corporation
-29 August 2005
-
-              Linklocal Multicast Name Resolution (LLMNR)
-
-Status of this Memo
-
-   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 becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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 March 15, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society 2005.
-
-Abstract
-
-   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.
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 1]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-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 .................................    9
-   2.3       Responder Behavior ..............................   10
-   2.4       Unicast Queries and Responses ...................   12
-   2.5       Off-link Detection ..............................   13
-   2.6       Responder Responsibilities ......................   13
-   2.7       Retransmission and Jitter .......................   14
-   2.8       DNS TTL .........................................   15
-   2.9       Use of the Authority and Additional Sections ....   15
-3.     Usage model ...........................................   16
-   3.1       LLMNR Configuration .............................   17
-4.     Conflict Resolution ...................................   18
-   4.1       Uniqueness Verification .........................   19
-   4.2       Conflict Detection and Defense ..................   20
-   4.3       Considerations for Multiple Interfaces ..........   21
-   4.4       API issues ......................................   22
-5.     Security Considerations ...............................   22
-   5.1       Denial of Service ...............................   23
-   5.2       Spoofing ...............,........................   23
-   5.3       Authentication ..................................   24
-   5.4       Cache and Port Separation .......................   25
-6.     IANA considerations ...................................   25
-7.     Constants .............................................   25
-8.     References ............................................   25
-   8.1       Normative References ............................   25
-   8.2       Informative References ..........................   26
-Acknowledgments ..............................................   27
-Authors' Addresses ...........................................   28
-Intellectual Property Statement ..............................   28
-Disclaimer of Validity .......................................   29
-Copyright Statement ..........................................   29
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 2]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-1.  Introduction
-
-   This document discusses Link Local Multicast Name Resolution (LLMNR),
-   which is based on 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.  Usage scenarios
-   (discussed in more detail in Section 3.1) include situations in which
-   hosts are not configured with the address of a DNS server; where the
-   DNS server is unavailable or unreachable; where there is no DNS
-   server authoritative for the name of a host, or where the
-   authoritative DNS server does not have the desired RRs, 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.  In such
-   networks, if a network has a gateway, then typically 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 networks.
-
-   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.  IPv4 administratively scoped
-   multicast usage is specified in "Administratively Scoped IP
-   Multicast" [RFC2365].
-
-   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.
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 3]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-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 LLMNR responder considers one of its addresses reachable over a
-     link if it will respond to an ARP or Neighbor Discovery query for
-     that address received on that 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.
-
-UNIQUE
-     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.  Names for which only a single responder is
-     anticipated are referred to as UNIQUE.  Name uniqueness is
-     configured on the responder, and therefore uniqueness verification
-     is the responder's responsibility.
-
-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.  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
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 4]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   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, if only to verify the uniqueness of names as described in
-   Section 4.  This document does not specify how names are chosen or
-   configured.  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.
-
-   By default, LLMNR queries MAY be sent only when one of the following
-   conditions are met:
-
-   [1] No manual or automatic DNS configuration has been performed.
-       If DNS server address(es) have been configured, then LLMNR
-       SHOULD NOT be used as the primary name resolution mechanism,
-       although it MAY be used as a secondary name resolution
-       mechanism.  A dual stack host SHOULD attempt to reach DNS
-       servers overall protocols on which DNS server address(es) are
-       configured, prior to sending LLMNR queries.  For dual stack
-       hosts configured with DNS server address(es) for one protocol
-       but not another, this inplies that DNS queries SHOULD be sent
-       over the protocol configured with a DNS server, prior to
-       sending LLMNR queries.
-
-   [2] All attempts to resolve the name via DNS on all interfaces
-       have failed after exhausting the searchlist.  This can occur
-       because DNS servers did not respond, or because they
-       responded to DNS queries with RCODE=3 (Authoritative Name
-       Error) or RCODE=0, and an empty answer section.  Where a
-       single resolver call generates DNS queries for A and AAAA RRs,
-       an implementation MAY choose not to send LLMNR queries if any
-       of the DNS queries is successful.  An LLMNR query SHOULD only
-       be sent for the originally requested name;  a searchlist
-       is not used to form additional LLMNR queries.
-
-   While these conditions are necessary for sending an LLMNR query, they
-   are not sufficient.  While an LLMNR sender MAY send a query for any
-   name, it also MAY impose additional conditions on sending LLMNR
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 5]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   queries.  For example, a sender configured with a DNS server MAY send
-   LLMNR queries only for unqualified names and for fully qualified
-   domain names within configured zones.
-
-   A typical sequence of events for LLMNR usage is as follows:
-
-   [a]  DNS servers are not configured or attempts to resolve the
-        name via DNS have failed, after exhausting the searchlist.
-        Also, the name to be queried satisfies the restrictions
-        imposed by the implementation.
-
-   [b]  An LLMNR sender sends an LLMNR query to the link-scope
-        multicast address(es), unless a unicast query is indicated,
-        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.
-
-   The sections that follow provide further details on sender and
-   responder behavior.
-
-2.1.  LLMNR Packet Format
-
-   LLMNR is based on 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 the smaller of the link
-   MTU or 9194 octets (Ethernet jumbo frame size of 9KB (9216) minus 22
-   octets for the header, VLAN tag and CRC).
-
-2.1.1.  LLMNR Header Format
-
-   LLMNR queries and responses utilize the DNS header format defined in
-   [RFC1035] with exceptions noted below:
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 6]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-                                   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  | C|TC| T| 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.  For advice on generation of pseudo-random values, please
-     consult [RFC1750].
-
-QR   Query/Response.  A one bit field, which if set indicates that the
-     message is an LLMNR response; if clear then the message is an LLMNR
-     query.
-
-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.
-     LLMNR senders and responders MUST support standard queries (opcode
-     value of zero).  LLMNR queries with unsupported OPCODE values MUST
-     be silently discarded by responders.
-
-C    Conflict.  When set within a request, the 'C'onflict bit indicates
-     that a sender has received multiple LLMNR responses to this query.
-     In an LLMNR response, if the name is considered UNIQUE, then the
-     'C' bit is clear, otherwise it is set.  LLMNR senders do not
-     retransmit queries with the 'C' bit set.  Responders MUST NOT
-     respond to LLMNR queries with the 'C' bit set, but may start the
-     uniqueness verification process, as described in Section 4.2.
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 7]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-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 in an LLMNR response,
-     then the sender SHOULD 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.
-
-T    Tentative.  The 'T'entative bit is set in a response if the
-     responder is authoritative for the name, but has not yet verified
-     the uniqueness of the name.  A responder MUST ignore the 'T' bit in
-     a query, if set.  A response with the 'T' bit set is silently
-     discarded by the sender, except if it is a uniqueness query, in
-     which case a conflict has been detected and a responder MUST
-     resolve the conflict as described in Section 4.1.
-
-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 sender MUST set RCODE to zero;
-     the responder ignores the RCODE and assumes it to be zero.  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 preferable to not
-     sending a response, since it enables errors to be diagnosed.
-     Errors include those defined in [RFC2845], such as BADSIG(16),
-     BADKEY(17) and BADTIME(18).
-
-     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
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 8]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-     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
-     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.  LLMNR
-     responders MUST silently discard LLMNR queries with NSCOUNT not
-     equal to zero.
-
-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, PTR, SRV, etc.) to the link-scope multicast address.
-   As described in Section 2.4, a sender MAY also send a unicast query.
-
-   The sender MUST anticipate receiving no replies to some LLMNR
-   queries, in the event that no responders are available within the
-   link-scope.  If no response is received, a resolver treats it as a
-   response that the name does not exist (RCODE=3 is returned).  A
-   sender can handle duplicate responses by discarding responses with a
-   source IP address and ID field that duplicate a response already
-   received.
-
-   When multiple valid LLMNR responses are received with the 'C' bit
-   set, they SHOULD be concatenated and treated in the same manner that
-   multiple RRs received from the same DNS server would be.  However,
-   responses with the 'C' bit set SHOULD NOT be concatenated with
-   responses with the 'C' bit clear; instead, only the responses with
-   the 'C' bit set SHOULD be returned.  If valid LLMNR response(s) are
-   received along with error response(s), then the error responses are
-
-
-
-Aboba, Thaler & Esibov       Standards Track                    [Page 9]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   silently discarded.
-
-   If error responses are received from both DNS and LLMNR, then the
-   lowest RCODE value should be returned. For example, if either DNS or
-   LLMNR receives a response with RCODE=0, then this should returned to
-   the caller.
-
-   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
-   responder has another RR in addition to the SOA RR;  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
-   192.0.2.1 and IPv6 address 2001:0DB8::1:2:3:FF:FE:4:5:6 might be
-   authoritative for the following records:
-
-   host1. IN A 192.0.2.1
-          IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
-   host1.example.com. IN A 192.0.2.1
-          IN AAAA 2001:0DB8::1:2:3:FF:FE:4:5:6
-
-   1.2.0.192.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.  (line split for formatting reasons)
-            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:
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 10]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-[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 MUST 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, with the exception of queries with the 'C' bit
-     set, which do not elicit a response.
-
-[d]  Responders MUST NOT respond to LLMNR queries for names they are not
-     authoritative for.
-
-[e]  Responders MUST NOT respond using data from the LLMNR or DNS
-     resolver cache.
-
-[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 MUST 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.
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 11]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   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.".
-
-   Without the restriction on authority 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;  for example a host
-   "child.foo.example.com." could send a dynamic update for the NS and
-   glue A record to "foo.example.com.".  However, this approach
-   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).
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 12]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-2.5.  "Off link" Detection
-
-   A sender MUST select a source address for LLMNR queries that is
-   assigned on the interface on which the query is sent.  The
-   destination address of an LLMNR query MUST be a link-scope multicast
-   address or a unicast address.
-
-   A responder MUST select a source address for responses that is
-   assigned on the interface on which the query was received.  The
-   destination address of an LLMNR response MUST be a 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.
-
-   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 Bonjour [Bonjour].
-
-   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.
-   IPv4 Link-Local addresses are defined in [RFC3927].  IPv6 Link-Local
-   addresses are defined in [RFC2373].  In particular:
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 13]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   [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.
-
-   Where multiple addresses represent valid responses to a query, the
-   order in which the addresses are returned is as follows:
-
-   [d] If the source address of the query is a link-scope address,
-       then the responder SHOULD include a link-scope address first
-       in the response, if available.
-
-   [e] If the source address of the query is a routable address,
-       then the responder MUST include a routable address first
-       in the response, if available.
-
-2.7.  Retransmission and Jitter
-
-   An LLMNR sender uses the timeout interval LLMNR_TIMEOUT to determine
-   when to retransmit an LLMNR query.  An LLMNR sender SHOULD either
-   estimate the LLMNR_TIMEOUT for each interface, or set a reasonably
-   high initial timeout.  Suggested constants are described in Section
-   7.
-
-   If an LLMNR query sent over UDP is not resolved within LLMNR_TIMEOUT,
-   then a sender SHOULD repeat the transmission of the query in order to
-   assure that it was received by a host capable of responding to it,
-   while increasing the value of LLMNR_TIMEOUT exponentially.  An LLMNR
-   query SHOULD NOT be sent more than three times.
-
-   Where LLMNR queries are sent using TCP, retransmission is handled by
-   the transport layer.  Queries with the 'C' bit set MUST be sent using
-   multicast UDP and MUST NOT be retransmitted.
-
-   An LLMNR sender cannot know in advance if a query sent using
-   multicast will receive no response, one response, or more than one
-   response.  An LLMNR sender MUST wait for LLMNR_TIMEOUT if no response
-   has been received, or if it is necessary to collect all potential
-   responses, such as if a uniqueness verification query is being made.
-   Otherwise an LLMNR sender SHOULD consider a multicast query answered
-   after the first response is received, if that response has the 'C'
-   bit clear.
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 14]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   However, if the first response has the 'C' bit set, then the sender
-   SHOULD wait for LLMNR_TIMEOUT in order to collect all possible
-   responses.  When multiple valid answers are received, they may first
-   be concatenated, and then treated in the same manner that multiple
-   RRs received from the same DNS server would.  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.
-
-   Since it is possible for a response with the 'C' bit clear to be
-   followed by a response with the 'C' bit set, an LLMNR sender SHOULD
-   be prepared to process additional responses for the purposes of
-   conflict detection and LLMNR_TIMEOUT estimation, even after it has
-   considered a query answered.
-
-   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 JITTER_INTERVAL. This delay MAY be avoided by
-   responders responding with names which they have previously
-   determined to be UNIQUE (see Section 4 for details).
-
-2.8.  DNS TTL
-
-   The responder should insert a pre-configured TTL value in the records
-   returned in 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.
-
-   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 TTL of this record is set from the minimum of the
-   MINIMUM field of the SOA record and the TTL of the SOA itself, and
-   indicates how long a resolver may cache the negative answer.  The
-   owner name of the SOA record (MNAME) MUST be set to the query name.
-   The RNAME, SERIAL, REFRESH, RETRY and EXPIRE values MUST be ignored
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 15]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   by senders.  Negative responses without SOA records SHOULD NOT be
-   cached.
-
-   In LLMNR, the additional section is primarily intended for use by
-   EDNS0, TSIG and SIG(0).  As a result, unless the 'C' bit is set,
-   senders MAY only include pseudo RR-types in the additional section of
-   a query; unless the 'C' bit is set, responders MUST ignore the
-   additional section of queries containing other RR types.
-
-   In queries where the 'C' bit is set, the sender SHOULD include the
-   conflicting RRs in the additional section.  Since conflict
-   notifications are advisory, responders SHOULD log information from
-   the additional section, but otherwise MUST ignore the additional
-   section.
-
-   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
-   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
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 16]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   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 link-local 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 a AAAA RR query
-   sent over IPv4 or IPv6 with an authoritative name error (RCODE=3) or
-   RCODE=0 and an empty answer section, then a AAAA RR query sent using
-   LLMNR over IPv6 may be successful in resolving the name of an
-   IPv6-only host on the local link.
-
-   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
-   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
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 17]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   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.
-
-   An outage in the DNS configuration mechanism may result in hosts
-   continuing to use LLMNR even once the outage is repaired.  Since
-   LLMNR only enables linklocal name resolution, this represents a
-   degradation in capabilities.  As a result, hosts without a configured
-   DNS server may wish to periodically attempt to obtain DNS
-   configuration if permitted by the configuration mechanism in use.  In
-   the absence of other guidance, a default retry interval of one (1)
-   minute is RECOMMENDED.
-
-4.  Conflict Resolution
-
-   By default, a responder SHOULD be configured to behave as though its
-   name is UNIQUE on each interface on which LLMNR is enabled.  However,
-   it is also possible to configure multiple responders to be
-   authoritative for the same name.  For example, multiple responders
-   MAY respond to a query for an A or AAAA type record for a cluster
-   name (assigned to multiple hosts in the cluster).
-
-   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.
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 18]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-4.1.  Uniqueness Verification
-
-   Prior to sending an LLMNR response with the 'T' bit clear, a
-   responder configured with a UNIQUE name MUST verify that there is no
-   other host within the scope of LLMNR query propagation that is
-   authoritative for the same name on that interface.
-
-   Once a responder has verified that its name is UNIQUE, if it receives
-   an LLMNR query for that name, with the 'C' bit clear, it MUST
-   respond, with the 'T' bit clear. Prior to verifying that its name is
-   UNIQUE, a responder MUST set the 'T' bit in responses.
-
-   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 LLMNR queries on an interface
-       enabled for transmission and reception of IP traffic
-     - is configured to respond to LLMNR queries using additional
-       UNIQUE resource records
-     - verifies the acquisition of a new IP address and configuration
-       on an interface
-
-   To verify uniqueness, a responder MUST send an LLMNR query with the
-   'C' bit clear, over all protocols on which it responds to LLMNR
-   queries (IPv4 and/or IPv6).  It is RECOMMENDED that responders verify
-   uniqueness of a name by sending a query for the name with type='ANY'.
-
-   If no response is received, the sender retransmits the query, as
-   specified in Section 2.7.  If a response is received, the sender MUST
-   check if the source address matches the address of any of its
-   interfaces; if so, then the response is not considered a conflict,
-   since it originates from the sender.  To avoid triggering conflict
-   detection, a responder that detects that it is connected to the same
-   link on multiple interfaces SHOULD set the 'C' bit in responses.
-
-   If a response is received with the 'T' bit clear, the responder MUST
-   NOT use the name in response to LLMNR queries received over any
-   protocol (IPv4 or IPv6).  If a response is received with the 'T' bit
-   set, the responder MUST check if the source IP address in the
-   response, interpreted as an unsigned integer, is less than the source
-   IP address in the query.  If so, the responder MUST NOT use the name
-   in response to LLMNR queries received over any protocol (IPv4 or
-   IPv6).  For the purpose of uniqueness verification, the contents of
-   the answer section in a response is irrelevant.
-
-   Periodically carrying out uniqueness verification in an attempt to
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 19]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   detect name conflicts is not necessary, wastes network bandwidth, and
-   may actually be detrimental.  For example, if network links are
-   joined only briefly, and are separated again before any new
-   communication is initiated, temporary conflicts are benign and no
-   forced reconfiguration is required.  LLMNR responders SHOULD NOT
-   periodically attempt uniqueness verification.
-
-4.2.  Conflict Detection and Defense
-
-   Hosts on disjoint network links may configure the same name for use
-   with LLMNR.  If these separate network links are later joined or
-   bridged together, then there may be multiple hosts which are now on
-   the same link, trying to use the same name.
-
-   In order to enable ongoing detection of name conflicts, when an LLMNR
-   sender receives multiple LLMNR responses to a query, it MUST check if
-   the 'C' bit is clear in any of the responses.  If so, the sender
-   SHOULD send another query for the same name, type and class, this
-   time with the 'C' bit set, with the potentially conflicting resource
-   records included in the additional section.
-
-   Queries with the 'C' bit set are considered advisory and responders
-   MUST verify the existence of a conflict before acting on it.  A
-   responder receiving a query with the 'C' bit set MUST NOT respond.
-
-   If the query is for a UNIQUE name, then the responder MUST send its
-   own query for the same name, type and class, with the 'C' bit clear.
-   If a response is received, the sender MUST check if the source
-   address matches the address of any of its interfaces; if so, then the
-   response is not considered a conflict, since it originates from the
-   sender.  To avoid triggering conflict detection, a responder that
-   detects that it is connected to the same link on multiple interfaces
-   SHOULD set the 'C' bit in responses.
-
-   An LLMNR responder MUST NOT ignore conflicts once detected and SHOULD
-   log them.  Upon detecting a conflict, an LLMNR responder MUST
-   immediately stop using the conflicting name in response to LLMNR
-   queries received over any supported protocol, if the source IP
-   address in the response, interpreted as an unsigned integer, is less
-   than the source IP address in the uniqueness verification query.
-
-   After stopping the use of a name, the responder MAY elect to
-   configure a new name.  However, since name reconfiguration may be
-   disruptive, this is not required, and a responder may have been
-   configured to respond to multiple names so that alternative names may
-   already be available.  A host that has stopped the use of a name may
-   attempt uniqueness verification again after the expiration of the TTL
-   of the conflicting response.
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 20]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-4.3.  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.
-
-   Where a host is configured to issue LLMNR queries on more than one
-   interface, each interface maintains its own independent LLMNR
-   resolver cache, containing the responses to LLMNR queries.
-
-   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
-   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
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 21]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   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 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.4.  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
-   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 a peer-to-peer name resolution protocol designed for use on
-   the local link.  While LLMNR limits the vulnerability of responders
-   to off-link senders, it is possible for an off-link responder to
-   reach a sender.
-
-   In scenarios such as public "hotspots" 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 network, while wireless attackers may mount
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 22]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   attacks from a distance.  Link-layer security such as [IEEE-802.11i]
-   can be of assistance against these threats if it is available.
-
-   This section details security measures available to mitigate threats
-   from on and off-link attackers.
-
-5.1.  Denial of Service
-
-   Attackers may take advantage of LLMNR conflict detection by
-   allocating the same name, denying service to other LLMNR responders
-   and possibly allowing an attacker to receive packets destined for
-   other hosts.  By logging conflicts, LLMNR responders can provide
-   forensic evidence of these attacks.
-
-   An attacker may spoof LLMNR queries from a victim's address in order
-   to mount a denial of service attack.  Responders setting the IPv6 Hop
-   Limit or IPv4 TTL field to a value larger than one in an LLMNR UDP
-   response may be able to reach the victim across the Internet.
-
-   While LLMNR responders only respond to queries for which they are
-   authoritative and LLMNR does not provide wildcard query support, an
-   LLMNR response may be larger than the query, and an attacker can
-   generate multiple responses to a query for a name used by multiple
-   responders.  A sender may protect itself against unsolicited
-   responses by silently discarding them as rapidly as possible.
-
-5.2.  Spoofing
-
-   LLMNR is designed to prevent reception of queries sent by an off-link
-   attacker.  LLMNR requires that responders receiving UDP queries check
-   that they are sent to a link-scope multicast address.  However, 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.  To prevent successful setup of TCP
-   connections by an off-link sender, responders receiving a TCP SYN
-   reply with a TCP SYN-ACK with TTL set to one (1).
-
-   While it is difficult for an off-link attacker to send an LLMNR query
-   to a responder,  it is possible for an off-link attacker to spoof a
-   response to a 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.  Since the
-   forged response will only be accepted if it contains a matching ID
-   field, choosing a pseudo-random ID field within queries provides some
-   protection against off-link responders.
-
-   Since LLMNR queries can be sent when DNS server(s) do not respond, an
-   attacker can execute a denial of service attack on the DNS server(s)
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 23]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   and then poison the LLMNR cache by responding to an LLMNR query with
-   incorrect information.  As noted in "Threat Analysis of the Domain
-   Name System (DNS)" [RFC3833] these threats also exist with DNS, since
-   DNS response spoofing tools are available that can allow an attacker
-   to respond to a query more quickly than a distant DNS server.
-   However, while switched networks or link layer security may make it
-   difficult for an on-link attacker to snoop unicast DNS queries,
-   multicast LLMNR queries are propagated to all hosts on the link,
-   making it possible for an on-link attacker to spoof LLMNR responses
-   without having to guess the value of the ID field in the query.
-
-   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.
-
-   Limiting the situations in which LLMNR queries are sent, as described
-   in Section 2, is the best protection against these attacks.  If LLMNR
-   is given higher priority than DNS among the enabled name resolution
-   mechanisms, 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, eliminating the benefits of cache separation.  As a result,
-   LLMNR is only used as a name resolution mechanism of last resort.
-
-5.3.  Authentication
-
-   LLMNR is a peer-to-peer name resolution protocol, and as a result,
-   it is often deployed in situations where no trust model can be
-   assumed.  This makes it difficult to apply existing DNS security
-   mechanisms to LLMNR.
-
-   LLMNR does not support "delegated trust" (CD or AD bits).  As a
-   result, unless LLMNR senders are DNSSEC aware, it is not feasible to
-   use DNSSEC [RFC4033] with LLMNR.
-
-   If authentication is desired, and a pre-arranged security
-   configuration is possible, then the following security mechanisms may
-   be used:
-
-[a]  LLMNR implementations MAY support TSIG [RFC2845] and/or SIG(0)
-     [RFC2931] security mechanisms. "DNS Name Service based on Secure
-     Multicast DNS for IPv6 Mobile Ad Hoc Networks" [LLMNRSec] describes
-     the use of TSIG to secure LLMNR responses, based on group keys.
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 24]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-[b]  IPsec ESP with a null-transform MAY be used to authenticate unicast
-     LLMNR queries and responses or LLMNR responses to multicast
-     queries.  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.
-
-   Where these mechanisms cannot be supported, responses to LLMNR
-   queries may be unauthenticated.
-
-5.4.  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.
-
-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.  Constants
-
-   The following timing constants are used in this protocol; they are
-   not intended to be user configurable.
-
-      JITTER_INTERVAL      100 ms
-      LLMNR_TIMEOUT        1 second (if set statically on all interfaces)
-                           100 ms (IEEE 802 media, including IEEE 802.11)
-
-8.  References
-
-8.1.  Normative References
-
-[RFC1035] Mockapetris, P., "Domain Names - Implementation and
-          Specification", RFC 1035, November 1987.
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 25]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-[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.
-
-[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.
-
-[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
-          August 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.
-
-8.2.  Informative References
-
-[Bonjour] Cheshire, S. and M. Krochmal, "Multicast DNS", Internet draft
-          (work in progress), draft-cheshire-dnsext-multicastdns-05.txt,
-          June 2005.
-
-[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.
-
-[IEEE-802.11i]
-          Institute of Electrical and Electronics Engineers, "Supplement
-          to Standard for Telecommunications and Information Exchange
-          Between Systems - LAN/MAN Specific Requirements - Part 11:
-          Wireless LAN Medium Access Control (MAC) and Physical Layer
-          (PHY) Specifications: Specification for Enhanced Security",
-          IEEE 802.11i, July 2004.
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 26]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-[LLMNREnable]
-          Guttman, E., "DHCP LLMNR Enable Option", Internet draft (work
-          in progress), draft-guttman-mdns-enable-02.txt, April 2002.
-
-[LLMNRSec]
-          Jeong, J., Park, J. and H. Kim, "DNS Name Service based on
-          Secure Multicast DNS for IPv6 Mobile Ad Hoc Networks", ICACT
-          2004, Phoenix Park, Korea, February 9-11, 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
-
-[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and Suggested
-          Fixes", RFC 1536, October 1993.
-
-[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
-          Recommendations for Security", RFC 1750, December 1994.
-
-[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
-          March 1997.
-
-[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6",
-          RFC 2292, February 1998.
-
-[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
-          2365, July 1998.
-
-[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
-          Socket Interface Extensions for IPv6", RFC 2553, March 1999.
-
-[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.
-
-[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
-          System (DNS)", RFC 3833, August 2004.
-
-[RFC3927] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
-          of Link-Local IPv4 Addresses", RFC 3927, October 2004.
-
-[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
-          "DNS Security Introduction and Requirement", RFC 4033, March
-          2005.
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 27]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-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, Rob Austein, Randy Bush,
-   Stuart Cheshire, Ralph Droms, Robert Elz, James Gilroy, Olafur
-   Gudmundsson, Andreas Gustafsson, Erik Guttman, Myron Hattig,
-   Christian Huitema, Olaf Kolkman, Mika Liljeberg, Keith Moore,
-   Tomohide Nagashima, Thomas Narten, Erik Nordmark, Markku Savela, Mike
-   St. Johns, Sander Van-Valkenburg, and Brian Zill.
-
-Authors' Addresses
-
-   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
-
-   Levon Esibov
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA 98052
-
-   EMail: levone@microsoft.com
-
-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.
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 28]
-
-
-
-
-
-INTERNET-DRAFT                    LLMNR                   29 August 2005
-
-
-   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 (2005).  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.
-
-Open Issues
-
-   Open issues with this specification are tracked on the following web
-   site:
-
-   http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
-
-
-
-
-
-
-
-
-
-
-
-Aboba, Thaler & Esibov       Standards Track                   [Page 29]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-04.txt
deleted file mode 100644
index 8c6c5b1..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-nsec3-04.txt
+++ /dev/null
@@ -1,2352 +0,0 @@
-
-
-
-Network Working Group                                          B. Laurie
-Internet-Draft                                                 G. Sisson
-Expires: August 5, 2006                                        R. Arends
-                                                                 Nominet
-                                                           February 2006
-
-
-             DNSSEC Hash Authenticated Denial of Existence
-                       draft-ietf-dnsext-nsec3-04
-
-Status of this Memo
-
-   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 becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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 5, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   The DNS Security Extensions introduces the NSEC resource record for
-   authenticated denial of existence.  This document introduces a new
-   resource record as an alternative to NSEC that provides measures
-   against zone enumeration and allows for gradual expansion of
-   delegation-centric zones.
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                 [Page 1]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.1.  Rationale  . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.2.  Reserved Words . . . . . . . . . . . . . . . . . . . . . .  4
-     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
-   2.  NSEC versus NSEC3  . . . . . . . . . . . . . . . . . . . . . .  5
-   3.  The NSEC3 Resource Record  . . . . . . . . . . . . . . . . . .  5
-     3.1.  NSEC3 RDATA Wire Format  . . . . . . . . . . . . . . . . .  6
-       3.1.1.  The Hash Function Field  . . . . . . . . . . . . . . .  6
-       3.1.2.  The Opt-In Flag Field  . . . . . . . . . . . . . . . .  7
-       3.1.3.  The Iterations Field . . . . . . . . . . . . . . . . .  8
-       3.1.4.  The Salt Length Field  . . . . . . . . . . . . . . . .  8
-       3.1.5.  The Salt Field . . . . . . . . . . . . . . . . . . . .  8
-       3.1.6.  The Next Hashed Ownername Field  . . . . . . . . . . .  9
-       3.1.7.  The Type Bit Maps Field  . . . . . . . . . . . . . . .  9
-     3.2.  The NSEC3 RR Presentation Format . . . . . . . . . . . . . 10
-   4.  Creating Additional NSEC3 RRs for Empty Non-Terminals  . . . . 11
-   5.  Calculation of the Hash  . . . . . . . . . . . . . . . . . . . 11
-   6.  Including NSEC3 RRs in a Zone  . . . . . . . . . . . . . . . . 11
-   7.  Responding to NSEC3 Queries  . . . . . . . . . . . . . . . . . 12
-   8.  Special Considerations . . . . . . . . . . . . . . . . . . . . 13
-     8.1.  Proving Nonexistence . . . . . . . . . . . . . . . . . . . 13
-     8.2.  Salting  . . . . . . . . . . . . . . . . . . . . . . . . . 14
-     8.3.  Iterations . . . . . . . . . . . . . . . . . . . . . . . . 15
-     8.4.  Hash Collision . . . . . . . . . . . . . . . . . . . . . . 16
-       8.4.1.  Avoiding Hash Collisions during generation . . . . . . 16
-       8.4.2.  Second Preimage Requirement Analysis . . . . . . . . . 16
-       8.4.3.  Possible Hash Value Truncation Method  . . . . . . . . 17
-       8.4.4.  Server Response to a Run-time Collision  . . . . . . . 17
-       8.4.5.  Parameters that Cover the Zone . . . . . . . . . . . . 18
-   9.  Performance Considerations . . . . . . . . . . . . . . . . . . 18
-   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
-   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 18
-   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
-     12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
-     12.2. Informative References . . . . . . . . . . . . . . . . . . 22
-   Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
-   Appendix A.  Example Zone  . . . . . . . . . . . . . . . . . . . . 22
-   Appendix B.  Example Responses . . . . . . . . . . . . . . . . . . 27
-     B.1.  answer . . . . . . . . . . . . . . . . . . . . . . . . . . 27
-       B.1.1.  Authenticating the Example DNSKEY RRset  . . . . . . . 29
-     B.2.  Name Error . . . . . . . . . . . . . . . . . . . . . . . . 30
-     B.3.  No Data Error  . . . . . . . . . . . . . . . . . . . . . . 32
-       B.3.1.  No Data Error, Empty Non-Terminal  . . . . . . . . . . 33
-     B.4.  Referral to Signed Zone  . . . . . . . . . . . . . . . . . 34
-     B.5.  Referral to Unsigned Zone using the Opt-In Flag  . . . . . 35
-     B.6.  Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 36
-
-
-
-Laurie, et al.           Expires August 5, 2006                 [Page 2]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-     B.7.  Wildcard No Data Error . . . . . . . . . . . . . . . . . . 38
-     B.8.  DS Child Zone No Data Error  . . . . . . . . . . . . . . . 39
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
-   Intellectual Property and Copyright Statements . . . . . . . . . . 42
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                 [Page 3]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-1.  Introduction
-
-1.1.  Rationale
-
-   The DNS Security Extensions included the NSEC RR to provide
-   authenticated denial of existence.  Though the NSEC RR meets the
-   requirements for authenticated denial of existence, it introduced a
-   side-effect in that the contents of a zone can be enumerated.  This
-   property introduces undesired policy issues.
-
-   An enumerated zone can be used either directly as a source of
-   probable e-mail addresses for spam, or indirectly as a key for
-   multiple WHOIS queries to reveal registrant data which many
-   registries may be under strict legal obligations to protect.  Many
-   registries therefore prohibit copying of their zone file; however the
-   use of NSEC RRs renders these policies unenforceable.
-
-   A second problem was the requirement that the existence of all record
-   types in a zone - including unsigned delegation points - must be
-   accounted for, despite the fact that unsigned delegation point
-   records are not signed.  This requirement has a side-effect that the
-   overhead of signed zones is not related to the increase in security
-   of subzones.  This requirement does not allow the zones' size to grow
-   in relation to the growth of signed subzones.
-
-   In the past, solutions (draft-ietf-dnsext-dnssec-opt-in) have been
-   proposed as a measure against these side effects but at the time were
-   regarded as secondary over the need to have a stable DNSSEC
-   specification.  With (draft-vixie-dnssec-ter) [14] a graceful
-   transition path to future enhancements is introduced, while current
-   DNSSEC deployment can continue.  This document presents the NSEC3
-   Resource Record which mitigates these issues with the NSEC RR.
-
-   The reader is assumed to be familiar with the basic DNS and DNSSEC
-   concepts described in RFC 1034 [1], RFC 1035 [2], RFC 4033 [3], RFC
-   4034 [4], RFC 4035 [5] and subsequent RFCs that update them: RFC 2136
-   [6], RFC2181 [7] and RFC2308 [8].
-
-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 [9].
-
-1.3.  Terminology
-
-   The practice of discovering the contents of a zone, i.e. enumerating
-   the domains within a zone, is known as "zone enumeration".  Zone
-
-
-
-Laurie, et al.           Expires August 5, 2006                 [Page 4]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   enumeration was not practical prior to the introduction of DNSSEC.
-
-   In this document the term "original ownername" refers to a standard
-   ownername.  Because this proposal uses the result of a hash function
-   over the original (unmodified) ownername, this result is referred to
-   as "hashed ownername".
-
-   "Hash order" means the order in which hashed ownernames are arranged
-   according to their numerical value, treating the leftmost (lowest
-   numbered) octet as the most significant octet.  Note that this is the
-   same as the canonical ordering specified in RFC 4034 [4].
-
-   An "empty non-terminal" is a domain name that owns no resource
-   records but has subdomains that do.
-
-   The "closest encloser" of a (nonexistent) domain name is the longest
-   domain name, including empty non-terminals, that matches the
-   rightmost part of the nonexistent domain name.
-
-   "Base32 encoding" is "Base 32 Encoding with Extended Hex Alphabet" as
-   specified in RFC 3548bis [15].
-
-
-2.  NSEC versus NSEC3
-
-   This document does NOT obsolete the NSEC record, but gives an
-   alternative for authenticated denial of existence.  NSEC and NSEC3
-   RRs can not co-exist in a zone.  See draft-vixie-dnssec-ter [14] for
-   a signaling mechanism to allow for graceful transition towards NSEC3.
-
-
-3.  The NSEC3 Resource Record
-
-   The NSEC3 RR provides Authenticated Denial of Existence for DNS
-   Resource Record Sets.
-
-   The NSEC3 Resource Record (RR) lists RR types present at the NSEC3
-   RR's original ownername.  It includes the next hashed ownername in
-   the hash order of the zone.  The complete set of NSEC3 RRs in a zone
-   indicates which RRsets exist for the original ownername of the RRset
-   and form a chain of hashed ownernames in the zone.  This information
-   is used to provide authenticated denial of existence for DNS data, as
-   described in RFC 4035 [5].  To provide protection against zone
-   enumeration, the ownernames used in the NSEC3 RR are cryptographic
-   hashes of the original ownername prepended to the name of the zone.
-   The NSEC3 RR indicates which hash function is used to construct the
-   hash, which salt is used, and how many iterations of the hash
-   function are performed over the original ownername.  The hashing
-
-
-
-Laurie, et al.           Expires August 5, 2006                 [Page 5]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   technique is described fully in Section 5.
-
-   Hashed ownernames of unsigned delegations may be excluded from the
-   chain.  An NSEC3 record which span covers the hash of an unsigned
-   delegation's ownername is referred to as an Opt-In NSEC3 record and
-   is indicated by the presence of a flag.
-
-   The ownername for the NSEC3 RR is the base32 encoding of the hashed
-   ownername prepended to the name of the zone..
-
-   The type value for the NSEC3 RR is XX.
-
-   The NSEC3 RR RDATA format is class independent and is described
-   below.
-
-   The class MUST be the same as the original ownername's class.
-
-   The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL
-   field.  This is in the spirit of negative caching [8].
-
-3.1.  NSEC3 RDATA Wire Format
-
-   The RDATA of the NSEC3 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
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   | Hash Function |O|                Iterations                   |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |  Salt Length  |                     Salt                      /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   /                     Next Hashed Ownername                     /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   /                         Type Bit Maps                         /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   "O" is the Opt-In Flag field.
-
-3.1.1.  The Hash Function Field
-
-   The Hash Function field identifies the cryptographic hash function
-   used to construct the hash-value.
-
-   The values are as defined for the DS record (see RFC 3658 [10]).
-
-   On reception, a resolver MUST ignore an NSEC3 RR with an unknown hash
-   function value.
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                 [Page 6]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-3.1.2.  The Opt-In Flag Field
-
-   The Opt-In Flag field indicates whether this NSEC3 RR covers unsigned
-   delegations.
-
-   In DNSSEC, NS RRsets at delegation points are not signed, and may be
-   accompanied by a DS record.  The security status of the subzone is
-   determined by the presence or absence of the DS RRset,
-   cryptographically proven by the NSEC record or the signed DS RRset.
-   The presence of the Opt-In flag expands this definition by allowing
-   insecure delegations to exist within an otherwise signed zone without
-   the corresponding NSEC3 record at the delegation's (hashed) owner
-   name.  These delegations are proven insecure by using a covering
-   NSEC3 record.
-
-   Resolvers must be able to distinguish between NSEC3 records and
-   Opt-In NSEC3 records.  This is accomplished by setting the Opt-In
-   flag of the NSEC3 records that cover (or potentially cover) insecure
-   delegation nodes.
-
-   An Opt-In NSEC3 record does not assert the existence or non-existence
-   of the insecure delegations that it covers.  This allows for the
-   addition or removal of these delegations without recalculating or
-   resigning records in the NSEC3 chain.  However, Opt-In NSEC3 records
-   do assert the (non)existence of other, authoritative RRsets.
-
-   An Opt-In NSEC3 record MAY have the same original owner name as an
-   insecure delegation.  In this case, the delegation is proven insecure
-   by the lack of a DS bit in type map and the signed NSEC3 record does
-   assert the existence of the delegation.
-
-   Zones using Opt-In MAY contain a mixture of Opt-In NSEC3 records and
-   non-Opt-In NSEC3 records.  If an NSEC3 record is not Opt-In, there
-   MUST NOT be any hashed ownernames of insecure delegations (nor any
-   other records) between it and the RRsets indicated by the 'Next
-   Hashed Ownername' in the NSEC3 RDATA.  If it is Opt-In, there MUST
-   only be hashed ownernames of insecure delegations between it and the
-   next node indicated by the 'Next Hashed Ownername' in the NSEC3
-   RDATA.
-
-   In summary,
-   o  An Opt-In NSEC3 type is identified by an Opt-In Flag field value
-      of 1.
-   o  A non Opt-In NSEC3 type is identified by an Opt-In Flag field
-      value of 0.
-   and,
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                 [Page 7]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   o  An Opt-In NSEC3 record does not assert the non-existence of a hash
-      ownername between its ownername and next hashed ownername,
-      although it does assert that any hashed name in this span MUST be
-      of an insecure delegation.
-   o  An Opt-In NSEC3 record does assert the (non)existence of RRsets
-      with the same hashed owner name.
-
-3.1.3.  The Iterations Field
-
-   The Iterations field defines the number of times the hash has been
-   iterated.  More iterations results in greater resiliency of the hash
-   value against dictionary attacks, but at a higher cost for both the
-   server and resolver.  See Section 5 for details of this field's use.
-
-   Iterations make an attack more costly by making the hash computation
-   more computationally intensive, e.g. by iterating the hash function a
-   number of times.
-
-   When generating a few hashes this performance loss will not be a
-   problem, as a validator can handle a delay of a few milliseconds.
-   But when doing a dictionary attack it will also multiply the attack
-   workload by a factor, which is a problem for the attacker.
-
-3.1.4.  The Salt Length Field
-
-   The salt length field defines the length of the salt in octets.
-
-3.1.5.  The Salt Field
-
-   The Salt field is not present when the Salt Length Field has a value
-   of 0.
-
-   The Salt field is appended to the original ownername before hashing
-   in order to defend against precalculated dictionary attacks.  See
-   Section 5 for details on how the salt is used.
-
-   Salt is used to make dictionary attacks using precomputation more
-   costly.  A dictionary can only be computed after the attacker has the
-   salt, hence a new salt means that the dictionary has to be
-   regenerated with the new salt.
-
-   There MUST be a complete set of NSEC3 records covering the entire
-   zone that use the same salt value.  The requirement exists so that,
-   given any qname within a zone, at least one covering NSEC3 RRset may
-   be found.  While it may be theoretically possible to produce a set of
-   NSEC3s that use different salts that cover the entire zone, it is
-   computationally infeasible to generate such a set.  See Section 8.2
-   for further discussion.
-
-
-
-Laurie, et al.           Expires August 5, 2006                 [Page 8]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   The salt value SHOULD be changed from time to time - this is to
-   prevent the use of a precomputed dictionary to reduce the cost of
-   enumeration.
-
-3.1.6.  The Next Hashed Ownername Field
-
-   The Next Hashed Ownername field contains the next hashed ownername in
-   hash order.  That is, given the set of all hashed owernames, the Next
-   Hashed Ownername contains the hash value that immediately follows the
-   owner hash value for the given NSEC3 record.  The value of the Next
-   Hashed Ownername Field in the last NSEC3 record in the zone is the
-   same as the ownername of the first NSEC3 RR in the zone in hash
-   order.
-
-   Hashed ownernames of glue RRsets MUST NOT be listed in the Next
-   Hashed Ownername unless at least one authoritative RRset exists at
-   the same ownername.  Hashed ownernames of delegation NS RRsets MUST
-   be listed if the Opt-In bit is clear.
-
-   Note that the Next Hashed Ownername field is not encoded, unlike the
-   NSEC3 RR's ownername.  It is the unmodified binary hash value.  It
-   does not include the name of the containing zone.
-
-   The length of this field is the length of the hash value produced by
-   the hash function selected by the Hash Function field.
-
-3.1.7.  The Type Bit Maps Field
-
-   The Type Bit Maps field identifies the RRset types which exist at the
-   NSEC3 RR's original ownername.
-
-   The Type bits for the NSEC3 RR and RRSIG RR MUST be set during
-   generation, and MUST be ignored during processing.
-
-   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 NSEC3 RR RDATA in increasing numerical
-   order.
-
-   "|" denotes concatenation
-
-   Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                 [Page 9]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   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 to
-   1, it indicates that an RRset of that type is present for the NSEC3
-   RR's ownername.  If a bit is set to 0, it indicates that no RRset of
-   that type is present for the NSEC3 RR's ownername.
-
-   Since bit 0 in window block 0 refers to the non-existing RR type 0,
-   it MUST be set to 0.  After verification, the validator MUST ignore
-   the value of bit 0 in window block 0.
-
-   Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [11]
-   (section 3.1) or within the range reserved for assignment only to
-   QTYPEs and Meta-TYPEs MUST be set to 0, 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
-   NSEC3 RR's actual ownername.  Trailing zero octets not specified MUST
-   be interpreted as zero octets.
-
-3.2.  The NSEC3 RR Presentation Format
-
-   The presentation format of the RDATA portion is as follows:
-
-   The Opt-In Flag Field is represented as an unsigned decimal integer.
-   The value is either 0 or 1.
-
-   The Hash field is presented as a mnemonic of the hash or as an
-   unsigned decimal integer.  The value has a maximum of 127.
-
-   The Iterations field is presented as an unsigned decimal integer.
-
-   The Salt Length field is not presented.
-
-   The Salt field is represented as a sequence of case-insensitive
-   hexadecimal digits.  Whitespace is not allowed within the sequence.
-   The Salt Field is represented as "-" (without the quotes) when the
-   Salt Length field has value 0.
-
-   The Next Hashed Ownername field is represented as a sequence of case-
-   insensitive base32 digits, without whitespace.
-
-   The Type Bit Maps Field is represented as a sequence of RR type
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 10]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   mnemonics.  When the mnemonic is not known, the TYPE representation
-   as described in RFC 3597 [12] (section 5) MUST be used.
-
-
-4.  Creating Additional NSEC3 RRs for Empty Non-Terminals
-
-   In order to prove the non-existence of a record that might be covered
-   by a wildcard, it is necessary to prove the existence of its closest
-   encloser.  A closest encloser might be an empty non-terminal.
-
-   Additional NSEC3 RRs are generated for empty non-terminals.  These
-   additional NSEC3 RRs are identical in format to NSEC3 RRs that cover
-   existing RRs in the zone except that their type-maps only indicated
-   the existence of an NSEC3 RRset and an RRSIG RRset.
-
-   This relaxes the requirement in Section 2.3 of RFC4035 that NSEC RRs
-   not appear at names that did not exist before the zone was signed.
-   [Comment.1]
-
-
-5.  Calculation of the Hash
-
-   Define H(x) to be the hash of x using the hash function selected by
-   the NSEC3 record and || to indicate concatenation.  Then define:
-
-   IH(salt,x,0)=H(x || salt)
-
-   IH(salt,x,k)=H(IH(salt,x,k-1) || salt) if k > 0
-
-   Then the calculated hash of an ownername is
-   IH(salt,ownername,iterations-1), where the ownername is the canonical
-   form.
-
-   The canonical form of the ownername is the wire format of the
-   ownername where:
-   1.  The ownername is fully expanded (no DNS name compression) and
-       fully qualified;
-   2.  All uppercase US-ASCII letters are replaced by the corresponding
-       lowercase US-ASCII letters;
-   3.  If the ownername is a wildcard name, the ownername is in its
-       original unexpanded form, including the "*" label (no wildcard
-       substitution);
-   This form is as defined in section 6.2 of RFC 4034 ([4]).
-
-
-6.  Including NSEC3 RRs in a Zone
-
-   Each ownername within the zone that owns authoritative RRsets MUST
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 11]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   have a corresponding NSEC3 RR.  Ownernames that correspond to
-   unsigned delegations MAY have a corresponding NSEC3 RR, however, if
-   there is not, there MUST be a covering NSEC3 RR with the Opt-In flag
-   set to 1.  Other non-authoritative RRs are not included in the set of
-   NSEC3 RRs.
-
-   Each empty non-terminal MUST have an NSEC3 record.
-
-   The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL
-   value field in the zone SOA RR.
-
-   The type bitmap of every NSEC3 resource record in a signed zone MUST
-   indicate the presence of both the NSEC3 RR type itself and its
-   corresponding RRSIG RR type.
-
-   The following steps describe the proper construction of NSEC3
-   records.  [Comment.2]
-   1.  For each unique original ownername in the zone, add an NSEC3
-       RRset.  If Opt-In is being used, ownernames of unsigned
-       delegations may be excluded, but must be considered for empty-
-       non-terminals.  The ownername of the NSEC3 RR is the hashed
-       equivalent of the original owner name, prepended to the zone
-       name.  The Next Hashed Ownername field is left blank for the
-       moment.  If Opt-In is being used, set the Opt-In bit to one.
-   2.  For each RRset at the original owner name, set the corresponding
-       bit in the type bit map.
-   3.  If the difference in number of labels between the apex and the
-       original ownername is greater then 1, additional NSEC3s need to
-       be added for every empty non-terminal between the apex and the
-       original ownername.  This process may generate NSEC3 RRs with
-       duplicate hashed ownernames.
-   4.  Sort the set of NSEC3 RRs into hash order.  Hash order is the
-       ascending numerical order of the non-encoded hash values.
-   5.  Combine NSEC3 RRs with identical hashed ownernames by replacing
-       with a single NSEC3 RR with the type map consisting of the union
-       of the types represented by the set of NSEC3 RRs.
-   6.  In each NSEC3 RR, insert the Next Hashed Ownername by using the
-       value of the next NSEC3 RR in hash order.  The Next Hashed
-       Ownername of the last NSEC3 in the zone contains the value of the
-       hashed ownername of the first NSEC3 in the hash order.
-
-
-7.  Responding to NSEC3 Queries
-
-   Since NSEC3 ownernames are not represented in the NSEC3 chain like
-   other zone ownernames, direct queries for NSEC3 ownernames present a
-   special case.
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 12]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   The special case arises when the following are all true:
-   o  The QNAME equals an existing NSEC3 ownername, and
-   o  There are no other record types that exist at QNAME, and
-   o  The QTYPE does not equal NSEC3.
-   These conditions describe a particular case: the answer should be a
-   NOERROR/NODATA response, but there is no NSEC3 RRset for H(QNAME) to
-   include in the authority section.
-
-   However, the NSEC3 RRset with ownername equal to QNAME is able to
-   prove its own existence.  Thus, when answering this query, the
-   authoritative server MUST include the NSEC3 RRset whose ownername
-   equals QNAME.  This RRset proves that QNAME is an existing name with
-   types NSEC3 and RRSIG.  The authoritative server MUST also include
-   the NSEC3 RRset that covers the hash of QNAME.  This RRset proves
-   that no other types exist.
-
-   When validating a NOERROR/NODATA response, validators MUST check for
-   a NSEC3 RRset with ownername equals to QNAME, and MUST accept that
-   (validated) NSEC3 RRset as proof that QNAME exists.  The validator
-   MUST also check for an NSEC3 RRset that covers the hash of QNAME as
-   proof that QTYPE doesn't exist.
-
-   Other cases where the QNAME equals an existing NSEC3 ownername may be
-   answered normally.
-
-
-8.  Special Considerations
-
-   The following paragraphs clarify specific behaviour explain special
-   considerations for implementations.
-
-8.1.  Proving Nonexistence
-
-   If a wildcard resource record appears in a zone, its asterisk label
-   is treated as a literal symbol and is treated in the same way as any
-   other ownername for purposes of generating NSEC3 RRs.  RFC 4035 [5]
-   describes the impact of wildcards on authenticated denial of
-   existence.
-
-   In order to prove there exist no RRs for a domain, as well as no
-   source of synthesis, an RR must be shown for the closest encloser,
-   and non-existence must be shown for all closer labels and for the
-   wildcard at the closest encloser.
-
-   This can be done as follows.  If the QNAME in the query is
-   omega.alfa.beta.example, and the closest encloser is beta.example
-   (the nearest ancestor to omega.alfa.beta.example), then the server
-   should return an NSEC3 that demonstrates the nonexistence of
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 13]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   alfa.beta.example, an NSEC3 that demonstrates the nonexistence of
-   *.beta.example, and an NSEC3 that demonstrates the existence of
-   beta.example.  This takes between one and three NSEC3 records, since
-   a single record can, by chance, prove more than one of these facts.
-
-   When a verifier checks this response, then the existence of
-   beta.example together with the non-existence of alfa.beta.example
-   proves that the closest encloser is indeed beta.example.  The non-
-   existence of *.beta.example shows that there is no wildcard at the
-   closest encloser, and so no source of synthesis for
-   omega.alfa.beta.example.  These two facts are sufficient to satisfy
-   the resolver that the QNAME cannot be resolved.
-
-   In practice, since the NSEC3 owner and next names are hashed, if the
-   server responds with an NSEC3 for beta.example, the resolver will
-   have to try successively longer names, starting with example, moving
-   to beta.example, alfa.beta.example, and so on, until one of them
-   hashes to a value that matches the interval (but not the ownername
-   nor next owner name) of one of the returned NSEC3s (this name will be
-   alfa.beta.example).  Once it has done this, it knows the closest
-   encloser (i.e. beta.example), and can then easily check the other two
-   required proofs.
-
-   Note that it is not possible for one of the shorter names tried by
-   the resolver to be denied by one of the returned NSEC3s, since, by
-   definition, all these names exist and so cannot appear within the
-   range covered by an NSEC3.  Note, however, that the first name that
-   the resolver tries MUST be the apex of the zone, since names above
-   the apex could be denied by one of the returned NSEC3s.
-
-8.2.  Salting
-
-   Augmenting original ownernames with salt before hashing increases the
-   cost of a dictionary of pre-generated hash-values.  For every bit of
-   salt, the cost of a precomputed dictionary doubles (because there
-   must be an entry for each word combined with each possible salt
-   value).  The NSEC3 RR can use a maximum of 2040 bits (255 octets) of
-   salt, multiplying the cost by 2^2040.  This means that an attacker
-   must, in practice, recompute the dictionary each time the salt is
-   changed.
-
-   There MUST be at least one complete set of NSEC3s for the zone using
-   the same salt value.
-
-   The salt SHOULD be changed periodically to prevent precomputation
-   using a single salt.  It is RECOMMENDED that the salt be changed for
-   every resigning.
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 14]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   Note that this could cause a resolver to see records with different
-   salt values for the same zone.  This is harmless, since each record
-   stands alone (that is, it denies the set of ownernames whose hashes,
-   using the salt in the NSEC3 record, fall between the two hashes in
-   the NSEC3 record) - it is only the server that needs a complete set
-   of NSEC3 records with the same salt in order to be able to answer
-   every possible query.
-
-   There is no prohibition with having NSEC3 with different salts within
-   the same zone.  However, in order for authoritative servers to be
-   able to consistently find covering NSEC3 RRs, the authoritative
-   server MUST choose a single set of parameters (algorithm, salt, and
-   iterations) to use when selecting NSEC3s.  In the absence of any
-   other metadata, the server does this by using the parameters from the
-   zone apex NSEC3, recognizable by the presence of the SOA bit in the
-   type map.  If there is more than one NSEC3 record that meets this
-   description, then the server may arbitrarily choose one.  Because of
-   this, if there is a zone apex NSEC3 RR within a zone, it MUST be part
-   of a complete NSEC3 set.  Conversely, if there exists an incomplete
-   set of NSEC3 RRs using the same parameters within a zone, there MUST
-   NOT be an NSEC3 RR using those parameters with the SOA bit set.
-
-8.3.  Iterations
-
-   Setting the number of iterations used allows the zone owner to choose
-   the cost of computing a hash, and so the cost of generating a
-   dictionary.  Note that this is distinct from the effect of salt,
-   which prevents the use of a single precomputed dictionary for all
-   time.
-
-   Obviously the number of iterations also affects the zone owner's cost
-   of signing the zone as well as the verifiers cost of verifying the
-   zone.  We therefore impose an upper limit on the number of
-   iterations.  We base this on the number of iterations that
-   approximately doubles the cost of signing the zone.
-
-   A zone owner MUST NOT use a value higher than shown in the table
-   below for iterations.  A resolver MAY treat a response with a higher
-   value as bogus.
-
-                       +--------------+------------+
-                       | RSA Key Size | Iterations |
-                       +--------------+------------+
-                       | 1024         | 3,000      |
-                       | 2048         | 20,000     |
-                       | 4096         | 150,000    |
-                       +--------------+------------+
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 15]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-                       +--------------+------------+
-                       | DSA Key Size | Iterations |
-                       +--------------+------------+
-                       | 1024         | 1,500      |
-                       | 2048         | 5,000      |
-                       +--------------+------------+
-
-   This table is based on 150,000 SHA-1's per second, 50 RSA signs per
-   second for 1024 bit keys, 7 signs per second for 2048 bit keys, 1
-   sign per second for 4096 bit keys, 100 DSA signs per second for 1024
-   bit keys and 30 signs per second for 2048 bit keys.
-
-   Note that since RSA verifications are 10-100 times faster than
-   signatures (depending on key size), in the case of RSA the legal
-   values of iterations can substantially increase the cost of
-   verification.
-
-8.4.  Hash Collision
-
-   Hash collisions occur when different messages have the same hash
-   value.  The expected number of domain names needed to give a 1 in 2
-   chance of a single collision is about 2^(n/2) for a hash of length n
-   bits (i.e. 2^80 for SHA-1).  Though this probability is extremely
-   low, the following paragraphs deal with avoiding collisions and
-   assessing possible damage in the event of an attack using hash
-   collisions.
-
-8.4.1.  Avoiding Hash Collisions during generation
-
-   During generation of NSEC3 RRs, hash values are supposedly unique.
-   In the (academic) case of a collision occurring, an alternative salt
-   MUST be chosen and all hash values MUST be regenerated.
-
-8.4.2.  Second Preimage Requirement Analysis
-
-   A cryptographic hash function has a second-preimage resistance
-   property.  The second-preimage resistance property means that it is
-   computationally infeasible to find another message with the same hash
-   value as a given message, i.e. given preimage X, to find a second
-   preimage X' != X such that hash(X) = hash(X').  The work factor for
-   finding a second preimage is of the order of 2^160 for SHA-1.  To
-   mount an attack using an existing NSEC3 RR, an adversary needs to
-   find a second preimage.
-
-   Assuming an adversary is capable of mounting such an extreme attack,
-   the actual damage is that a response message can be generated which
-   claims that a certain QNAME (i.e. the second pre-image) does exist,
-   while in reality QNAME does not exist (a false positive), which will
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 16]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   either cause a security aware resolver to re-query for the non-
-   existent name, or to fail the initial query.  Note that the adversary
-   can't mount this attack on an existing name but only on a name that
-   the adversary can't choose and does not yet exist.
-
-8.4.3.  Possible Hash Value Truncation Method
-
-   The previous sections outlined the low probability and low impact of
-   a second-preimage attack.  When impact and probability are low, while
-   space in a DNS message is costly, truncation is tempting.  Truncation
-   might be considered to allow for shorter ownernames and rdata for
-   hashed labels.  In general, if a cryptographic hash is truncated to n
-   bits, then the expected number of domains required to give a 1 in 2
-   probability of a single collision is approximately 2^(n/2) and the
-   work factor to produce a second preimage is 2^n.
-
-   An extreme hash value truncation would be truncating to the shortest
-   possible unique label value.  This would be unwise, since the work
-   factor to produce second preimages would then approximate the size of
-   the zone (sketch of proof: if the zone has k entries, then the length
-   of the names when truncated down to uniqueness should be proportional
-   to log_2(k).  Since the work factor to produce a second pre-image is
-   2^n for an n-bit hash, then in this case it is 2^(C log_2(k)) (where
-   C is some constant), i.e.  C'k - a work factor of k).
-
-   Though the mentioned truncation can be maximized to a certain
-   extreme, the probability of collision increases exponentially for
-   every truncated bit.  Given the low impact of hash value collisions
-   and limited space in DNS messages, the balance between truncation
-   profit and collision damage may be determined by local policy.  Of
-   course, the size of the corresponding RRSIG RR is not reduced, so
-   truncation is of limited benefit.
-
-   Truncation could be signaled simply by reducing the length of the
-   first label in the ownername.  Note that there would have to be a
-   corresponding reduction in the length of the Next Hashed Ownername
-   field.
-
-8.4.4.  Server Response to a Run-time Collision
-
-   In the astronomically unlikely event that a server is unable to prove
-   nonexistence because the hash of the name that does not exist
-   collides with a name that does exist, the server is obviously broken,
-   and should, therefore, return a response with an RCODE of 2 (server
-   failure).
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 17]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-8.4.5.  Parameters that Cover the Zone
-
-   Secondary servers (and perhaps other entities) need to reliably
-   determine which NSEC3 parameters (that is, hash, salt and iterations)
-   are present at every hashed ownername, in order to be able to choose
-   an appropriate set of NSEC3 records for negative responses.  This is
-   indicated by the parameters at the apex: any set of parameters that
-   is used in an NSEC3 record whose original ownername is the apex of
-   the zone MUST be present throughout the zone.
-
-   A method to determine which NSEC3 in a complete chain corresponds to
-   the apex is to look for a NSEC3 RRset which has the SOA bit set in
-   the RDATA bit type maps field.
-
-
-9.  Performance Considerations
-
-   Iterated hashes impose a performance penalty on both authoritative
-   servers and resolvers.  Therefore, the number of iterations should be
-   carefully chosen.  In particular it should be noted that a high value
-   for iterations gives an attacker a very good denial of service
-   attack, since the attacker need not bother to verify the results of
-   their queries, and hence has no performance penalty of his own.
-
-   On the other hand, nameservers with low query rates and limited
-   bandwidth are already subject to a bandwidth based denial of service
-   attack, since responses are typically an order of magnitude larger
-   than queries, and hence these servers may choose a high value of
-   iterations in order to increase the difficulty of offline attempts to
-   enumerate their namespace without significantly increasing their
-   vulnerability to denial of service attacks.
-
-
-10.  IANA Considerations
-
-   IANA needs to allocate a RR type code for NSEC3 from the standard RR
-   type space (type XXX requested).  IANA needs to open a new registry
-   for the NSEC3 Hash Functions.  The range for this registry is 0-127.
-   Defined types are:
-
-      0 is reserved.
-      1 is SHA-1 ([13]).
-      127 is experimental.
-
-
-11.  Security Considerations
-
-   The NSEC3 records are still susceptible to dictionary attacks (i.e.
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 18]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   the attacker retrieves all the NSEC3 records, then calculates the
-   hashes of all likely domain names, comparing against the hashes found
-   in the NSEC3 records, and thus enumerating the zone).  These are
-   substantially more expensive than enumerating the original NSEC
-   records would have been, and in any case, such an attack could also
-   be used directly against the name server itself by performing queries
-   for all likely names, though this would obviously be more detectable.
-   The expense of this off-line attack can be chosen by setting the
-   number of iterations in the NSEC3 RR.
-
-   Domains are also susceptible to a precalculated dictionary attack -
-   that is, a list of hashes for all likely names is computed once, then
-   NSEC3 is scanned periodically and compared against the precomputed
-   hashes.  This attack is prevented by changing the salt on a regular
-   basis.
-
-   Walking the NSEC3 RRs will reveal the total number of records in the
-   zone, and also what types they are.  This could be mitigated by
-   adding dummy entries, but certainly an upper limit can always be
-   found.
-
-   Hash collisions may occur.  If they do, it will be impossible to
-   prove the non-existence of the colliding domain - however, this is
-   fantastically unlikely, and, in any case, DNSSEC already relies on
-   SHA-1 to not collide.
-
-   Responses to queries where QNAME equals an NSEC3 ownername that has
-   no other types may be undetectably changed from a NOERROR/NODATA
-   response to a NAME ERROR response.
-
-   The Opt-In Flag (O) allows for unsigned names, in the form of
-   delegations to unsigned subzones, to exist within an otherwise signed
-   zone.  All unsigned names are, by definition, insecure, and their
-   validity or existence cannot by cryptographically proven.
-
-   In general:
-      Records with unsigned names (whether existing or not) suffer from
-      the same vulnerabilities as records in an unsigned zone.  These
-      vulnerabilities are described in more detail in [16] (note in
-      particular sections 2.3, "Name Games" and 2.6, "Authenticated
-      Denial").
-      Records with signed names have the same security whether or not
-      Opt-In is used.
-
-   Note that with or without Opt-In, an insecure delegation may be
-   undetectably altered by an attacker.  Because of this, the primary
-   difference in security when using Opt-In is the loss of the ability
-   to prove the existence or nonexistence of an insecure delegation
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 19]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   within the span of an Opt-In NSEC3 record.
-
-   In particular, this means that a malicious entity may be able to
-   insert or delete records with unsigned names.  These records are
-   normally NS records, but this also includes signed wildcard
-   expansions (while the wildcard record itself is signed, its expanded
-   name is an unsigned name).
-
-   For example, if a resolver received the following response from the
-   example zone above:
-
-   Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE.  A
-
-           RCODE=NOERROR
-
-           Answer Section:
-
-           Authority Section:
-           DOES-NOT-EXIST.EXAMPLE. NS     NS.FORGED.
-           EXAMPLE.                NSEC   FIRST-SECURE.EXAMPLE. SOA NS \
-                                          RRSIG DNSKEY
-           abcd...                 RRSIG  NSEC3 ...
-
-           Additional Section:
-
-   The resolver would have no choice but to accept that the referral to
-   NS.FORGED. is valid.  If a wildcard existed that would have been
-   expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
-   have undetectably removed it and replaced it with the forged
-   delegation.
-
-   Note that being able to add a delegation is functionally equivalent
-   to being able to add any record type: an attacker merely has to forge
-   a delegation to nameserver under his/her control and place whatever
-   records needed at the subzone apex.
-
-   While in particular cases, this issue may not present a significant
-   security problem, in general it should not be lightly dismissed.
-   Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
-   In particular, zone signing tools SHOULD NOT default to using Opt-In,
-   and MAY choose to not support Opt-In at all.
-
-
-12.  References
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 20]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-12.1.  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]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "DNS Security Introduction and Requirements", RFC 4033,
-         March 2005.
-
-   [4]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Resource Records for the DNS Security Extensions", RFC 4034,
-         March 2005.
-
-   [5]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Protocol Modifications for the DNS Security Extensions",
-         RFC 4035, March 2005.
-
-   [6]   Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
-         Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
-         April 1997.
-
-   [7]   Elz, R. and R. Bush, "Clarifications to the DNS Specification",
-         RFC 2181, July 1997.
-
-   [8]   Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
-         RFC 2308, March 1998.
-
-   [9]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-   [10]  Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
-         RFC 3658, December 2003.
-
-   [11]  Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain
-         Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
-         September 2000.
-
-   [12]  Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
-         Types", RFC 3597, September 2003.
-
-   [13]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
-         RFC 3174, September 2001.
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 21]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-12.2.  Informative References
-
-   [14]  Vixie, P., "Extending DNSSEC-BIS (DNSSEC-TER)",
-         draft-vixie-dnssec-ter-01 (work in progress), June 2004.
-
-   [15]  Josefsson, Ed., S,., "The Base16, Base32, and Base64 Data
-         Encodings.", draft-josefsson-rfc3548bis-00 (work in progress),
-         October 2005.
-
-   [16]  Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
-         System (DNS)", RFC 3833, August 2004.
-
-Editorial Comments
-
-   [Comment.1]  Although, strictly speaking, the names *did* exist.
-
-   [Comment.2]  Note that this method makes it impossible to detect
-                (extremely unlikely) hash collisions.
-
-
-Appendix A.  Example Zone
-
-   This is a zone showing its NSEC3 records.  They can also be used as
-   test vectors for the hash algorithm.
-
-   The data in the example zone is currently broken, as it uses a
-   different base32 alphabet.  This shall be fixed in the next release.
-
-
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1
-                              3600
-                              300
-                              3600000
-                              3600 )
-                  3600 RRSIG  SOA 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
-                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
-                              qYIt90txzE/4+g== )
-                  3600 NS     ns1.example.
-                  3600 NS     ns2.example.
-                  3600 RRSIG  NS 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
-                              m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
-                              1SH5r/wfjuCg+g== )
-                  3600 MX     1 xx.example.
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 22]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-                  3600 RRSIG  MX 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              L/ZDLMSZJKITmSxmM9Kni37/wKQsdSg6FT0l
-                              NMm14jy2Stp91Pwp1HQ1hAMkGWAqCMEKPMtU
-                              S/o/g5C8VM6ftQ== )
-                  3600 DNSKEY 257 3 5 (
-                              AQOnsGyJvywVjYmiLbh0EwIRuWYcDiB/8blX
-                              cpkoxtpe19Oicv6Zko+8brVsTMeMOpcUeGB1
-                              zsYKWJ7BvR2894hX
-                              ) ; Key ID = 21960
-                  3600 DNSKEY 256 3 5 (
-                              AQO0gEmbZUL6xbD/xQczHbnwYnf+jQjwz/sU
-                              5k44rHTt0Ty+3aOdYoome9TjGMhwkkGby1TL
-                              ExXT48OGGdbfIme5
-                              ) ; Key ID = 62699
-                  3600 RRSIG  DNSKEY 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              e6EB+K21HbyZzoLUeRDb6+g0+n8XASYe6h+Z
-                              xtnB31sQXZgq8MBHeNFDQW9eZw2hjT9zMClx
-                              mTkunTYzqWJrmQ== )
-                  3600 RRSIG  DNSKEY 5 1 3600 20050712112304 (
-                              20050612112304 21960 example.
-                              SnWLiNWLbOuiKU/F/wVMokvcg6JVzGpQ2VUk
-                              ZbKjB9ON0t3cdc+FZbOCMnEHRJiwgqlnncik
-                              3w7ZY2UWyYIvpw== )
-   5pe7ctl7pfs2cilroy5dcofx4rcnlypd.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-                              7nomf47k3vlidh4vxahhpp47l3tgv7a2
-                              NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              PTWYq4WZmmtgh9UQif342HWf9DD9RuuM4ii5
-                              Z1oZQgRi5zrsoKHAgl2YXprF2Rfk1TLgsiFQ
-                              sb7KfbaUo/vzAg== )
-   7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-                              dw4o7j64wnel3j4jh7fb3c5n7w3js2yb
-                              MX NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA
-                              ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo
-                              MEFQmc/gEuxojA== )
-   a.example.     3600 IN NS  ns1.a.example.
-                  3600 IN NS  ns2.a.example.
-                  3600 DS     58470 5 1 3079F1593EBAD6DC121E202A8B
-                              766A6A4837206C )
-                  3600 RRSIG  DS 5 2 3600 20050712112304 (
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 23]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-                              20050612112304 62699 example.
-                              QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn
-                              cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2
-                              0kx7rGKTc3RQDA== )
-   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 20050712112304 (
-                              20050612112304 62699 example.
-                              plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU
-                              6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq
-                              ZXW5S+1VjMZYzQ== )
-                  3600 HINFO  "KLH-10" "ITS"
-                  3600 RRSIG  HINFO 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              AR0hG/Z/e+vlRhxRQSVIFORzrJTBpdNHhwUk
-                              tiuqg+zGqKK84eIqtrqXelcE2szKnF3YPneg
-                              VGNmbgPnqDVPiA== )
-                  3600 AAAA   2001:db8:0:0:0:0:f00:baa9
-                  3600 RRSIG  AAAA 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV
-                              ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns
-                              l5/UqLCJJ9BDMg== )
-   b.example.     3600 IN NS  ns1.b.example.
-                  3600 IN NS  ns2.b.example.
-   ns1.b.example. 3600 IN A   192.0.2.7
-   ns2.b.example. 3600 IN A   192.0.2.8
-   dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-                              gmnfcccja7wkax3iv26bs75myptje3qk
-                              MX DNSKEY NS SOA NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D
-                              C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R
-                              MOiKMSHozVebqw== )
-   gmnfcccja7wkax3iv26bs75myptje3qk.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-                              jt4bbfokgbmr57qx4nqucvvn7fmo6ab6
-                              DS NS NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              ZqkdmF6eICpHyn1Cj7Yvw+nLcbji46Qpe76/
-                              ZetqdZV7K5sO3ol5dOc0dZyXDqsJp1is5StW
-                              OwQBGbOegrW/Zw== )
-   jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 24]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-                              kcll7fqfnisuhfekckeeqnmbbd4maanu
-                              NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V
-                              IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK
-                              94Zbq3k8lgdpZA== )
-   kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 NSEC3  1 1 1 (
-                              deadbeaf
-                              n42hbhnjj333xdxeybycax5ufvntux5d
-                              MX NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA
-                              IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx
-                              TOLtc5jPrkL4zQ== )
-   n42hbhnjj333xdxeybycax5ufvntux5d.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-                              nimwfwcnbeoodmsc6npv3vuaagaevxxu
-                              A NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              MZGzllh+YFqZbY8SkHxARhXFiMDPS0tvQYyy
-                              91tj+lbl45L/BElD3xxB/LZMO8vQejYtMLHj
-                              xFPFGRIW3wKnrA== )
-   nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-                              vhgwr2qgykdkf4m6iv6vkagbxozphazr
-                              HINFO A AAAA NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx
-                              z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG
-                              jL33Wm1p07TBdw== )
-   ns1.example.   3600 A      192.0.2.1
-                  3600 RRSIG  A 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb
-                              BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr
-                              nWWLepz1PjjShQ== )
-   ns2.example.   3600 A      192.0.2.2
-                  3600 RRSIG  A 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3
-                              P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz
-                              AkeTJu3J3auUiA== )
-   vhgwr2qgykdkf4m6iv6vkagbxozphazr.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 25]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-                              wbyijvpnyj33pcpi3i44ecnibnaj7eiw
-                              HINFO A AAAA NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              leFhoF5FXZAiNOxK4OBOOA0WKdbaD5lLDT/W
-                              kLoyWnQ6WGBwsUOdsEcVmqz+1n7q9bDf8G8M
-                              5SNSHIyfpfsi6A== )
-   *.w.example.   3600 MX     1 ai.example.
-                  3600 RRSIG  MX 5 3 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF
-                              xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ
-                              gQlgxEwhvQDEaQ== )
-   x.w.example.   3600 MX     1 xx.example.
-                  3600 RRSIG  MX 5 3 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w
-                              lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP
-                              U9VazOa1KEIq1w== )
-   x.y.w.example. 3600 MX     1 xx.example.
-                  3600 RRSIG  MX 5 4 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              aKVCGO/Fx9rm04UUsHRTTYaDA8o8dGfyq6t7
-                              uqAcYxU9xiXP+xNtLHBv7er6Q6f2JbOs6SGF
-                              9VrQvJjwbllAfA== )
-   wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-                              zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui
-                              A NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN
-                              ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd
-                              oorBv4xkb0flXw== )
-   xx.example.    3600 A      192.0.2.10
-                  3600 RRSIG  A 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9
-                              tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj
-                              cxwCXWj82GVGdw== )
-                  3600 HINFO  "KLH-10" "TOPS-20"
-                  3600 RRSIG  HINFO 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              ghS2DimOqPSacG9j6KMgXSfTMSjLxvoxvx3q
-                              OKzzPst4tEbAmocF2QX8IrSHr67m4ZLmd2Fk
-                              KMf4DgNBDj+dIQ== )
-                  3600 AAAA   2001:db8:0:0:0:0:f00:baaa
-                  3600 RRSIG  AAAA 5 2 3600 20050712112304 (
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 26]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-                              20050612112304 62699 example.
-                              rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo
-                              w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy
-                              rzKKwb8J04/ILw== )
-   zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 NSEC3  0 1 1 (
-                              deadbeaf
-                              5pe7ctl7pfs2cilroy5dcofx4rcnlypd
-                              MX NSEC3 RRSIG )
-                  3600 RRSIG  NSEC3 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
-                              7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
-                              OcFlrPGPMm48/A== )
-
-
-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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 27]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   ;; 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 IN RRSIG  MX 5 3 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              s1XQ/8SlViiEDik9edYs1Ooe3XiXo453Dg7w
-                              lqQoewuDzmtd6RaLNu52W44zTM1EHJES8ujP
-                              U9VazOa1KEIq1w== )
-
-   ;; Authority
-   example.       3600 IN NS  ns1.example.
-   example.       3600 IN NS  ns2.example.
-   example.       3600 IN RRSIG  NS 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
-                              m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
-                              1SH5r/wfjuCg+g== )
-
-   ;; Additional
-   xx.example.    3600 IN A   192.0.2.10
-   xx.example.    3600 IN RRSIG  A 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              XSuMVjNxovbZUsnKU6oQDygaK+WB+O5HYQG9
-                              tJgphHIX7TM4uZggfR3pNM+4jeC8nt2OxZZj
-                              cxwCXWj82GVGdw== )
-   xx.example.    3600 IN AAAA   2001:db8::f00:baaa
-   xx.example.    3600 IN RRSIG  AAAA 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              rto7afZkXYB17IfmQCT5QoEMMrlkeOoAGXzo
-                              w8Wmcg86Fc+MQP0hyXFScI1gYNSgSSoDMXIy
-                              rzKKwb8J04/ILw== )
-   ns1.example.   3600 IN A   192.0.2.1
-   ns1.example.   3600 IN RRSIG  A 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              QLGkaqWXxRuE+MHKkMvVlswg65HcyjvD1fyb
-                              BDZpcfiMHH9w4x1eRqRamtSDTcqLfUrcYkrr
-                              nWWLepz1PjjShQ== )
-   ns2.example.   3600 IN A   192.0.2.2
-   ns2.example.   3600 IN RRSIG  A 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              UoIZaC1O6XHRWGHBOl8XFQKPdYTkRCz6SYh3
-                              P2mZ3xfY22fLBCBDrEnOc8pGDGijJaLl26Cz
-                              AkeTJu3J3auUiA== )
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 28]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   The query returned an MX RRset for "x.w.example".  The corresponding
-   RRSIG RR indicates that the MX RRset was signed by an "example"
-   DNSKEY with algorithm 5 and key tag 62699.  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 RR 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 RR's labels field value of 3 indicates that the
-   answer was not the result of wildcard expansion.  The "x.w.example"
-   MX RRset is placed in canonical form, and, assuming the current time
-   falls between the signature inception and expiration dates, the
-   signature is authenticated.
-
-B.1.1.  Authenticating the Example DNSKEY RRset
-
-   This example shows the logical authentication process that starts
-   from a configured root DNSKEY RRset (or DS RRset) and moves down the
-   tree to authenticate the desired "example" DNSKEY RRset.  Note that
-   the logical order is presented for clarity.  An implementation may
-   choose to construct the authentication as referrals are received or
-   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 a configured DNSKEY RRset for the
-   root zone (or a configured DS RRset for the root zone).  The resolver
-   checks whether this configured DNSKEY RRset is present in the root
-   DNSKEY RRset (or whether a DS RR in the DS RRset matches some DNSKEY
-   RR in the root DNSKEY RRset), whether this DNSKEY RR has signed the
-   root DNSKEY RRset, and whether 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
-   that the resolver may have 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
-   matching "example" DNSKEY is found, the resolver checks whether this
-   DNSKEY RR has signed the "example" DNSKEY RRset and the signature
-   lifetime is valid.  If 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"
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 29]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   DNSKEY RRset uses algorithm 5 and has a key tag of 62699.  This
-   DNSKEY is used to authenticate 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 validate the signature as described above.
-
-B.2.  Name Error
-
-   An authoritative name error.  The NSEC3 RRs prove that the name does
-   not exist and that no covering wildcard exists.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 30]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   ;; Header: QR AA DO RCODE=3
-   ;;
-   ;; Question
-   a.c.x.w.example.         IN A
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-   example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
-                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
-                              qYIt90txzE/4+g== )
-   7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN NSEC3  0 1 1 (
-                              deadbeaf
-                              dw4o7j64wnel3j4jh7fb3c5n7w3js2yb
-                              MX NSEC3 RRSIG )
-   7nomf47k3vlidh4vxahhpp47l3tgv7a2.example. 3600 IN RRSIG  NSEC3 (
-                              5 2 3600 20050712112304
-                              20050612112304 62699 example.
-                              YTcqole3h8EOsTT3HKnwhR1QS8borR0XtZaA
-                              ZrLsx6n0RDC1AAdZONYOvdqvcal9PmwtWjlo
-                              MEFQmc/gEuxojA== )
-   nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN NSEC3  0 1 1 (
-                              deadbeaf
-                              vhgwr2qgykdkf4m6iv6vkagbxozphazr
-                              HINFO A AAAA NSEC3 RRSIG )
-   nimwfwcnbeoodmsc6npv3vuaagaevxxu.example. 3600 IN RRSIG  NSEC3 (
-                              5 2 3600 20050712112304
-                              20050612112304 62699 example.
-                              c3zQdK68cYTHTjh1cD6pi0vblXwzyoU/m7Qx
-                              z8kaPYikbJ9vgSl9YegjZukgQSwybHUC0SYG
-                              jL33Wm1p07TBdw== )
-   ;; Additional
-   ;; (empty)
-
-   The query returned two NSEC3 RRs that prove that the requested data
-   does not exist and no wildcard applies.  The negative reply is
-   authenticated by verifying both NSEC3 RRs.  The NSEC3 RRs are
-   authenticated in a manner identical to that of the MX RRset discussed
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 31]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   above.  At least one of the owner names of the NSEC3 RRs will match
-   the closest encloser.  At least one of the NSEC3 RRs prove that there
-   exists no longer name.  At least one of the NSEC3 RRs prove that
-   there exists no wildcard RRsets that should have been expanded.  The
-   closest encloser can be found by hashing the apex ownername (The SOA
-   RR's ownername, or the ownername of the DNSKEY RRset referred by an
-   RRSIG RR), matching it to the ownername of one of the NSEC3 RRs, and
-   if that fails, continue by adding labels.  In other words, the
-   resolver first hashes example, checks for a matching NSEC3 ownername,
-   then hashes w.example, checks, and finally hashes w.x.example and
-   checks.
-
-   In the above example, the name 'x.w.example' hashes to
-   '7nomf47k3vlidh4vxahhpp47l3tgv7a2'.  This indicates that this might
-   be the closest encloser.  To prove that 'c.x.w.example' and
-   '*.x.w.example' do not exists, these names are hashed to respectively
-   'qsgoxsf2lanysajhtmaylde4tqwnqppl' and
-   'cvljzyf6nsckjowghch4tt3nohocpdka'.  The two NSEC3 records prove that
-   these hashed ownernames do not exists, since the names are within the
-   given intervals.
-
-B.3.  No Data Error
-
-   A "no data" response.  The NSEC3 RR proves that the name exists and
-   that the requested RR type does not.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 32]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   ns1.example.        IN MX
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-   example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
-                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
-                              qYIt90txzE/4+g== )
-   wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN NSEC3  0 1 1 (
-                              deadbeaf
-                              zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui
-                              A NSEC3 RRSIG )
-   wbyijvpnyj33pcpi3i44ecnibnaj7eiw.example. 3600 IN RRSIG  NSEC3 (
-                              5 2 3600 20050712112304
-                              20050612112304 62699 example.
-                              ledFAaDCqDxapQ1FvBAjjK2DP06iQj8AN6gN
-                              ZycTeSmobKLTpzbgQp8uKYYe/DPHjXYmuEhd
-                              oorBv4xkb0flXw== )
-   ;; Additional
-   ;; (empty)
-
-   The query returned an NSEC3 RR that proves that the requested name
-   exists ("ns1.example." hashes to "wbyijvpnyj33pcpi3i44ecnibnaj7eiw"),
-   but the requested RR type does not exist (type MX is absent in the
-   type code list of the NSEC RR).  The negative reply is authenticated
-   by verifying the NSEC3 RR.  The NSEC3 RR is authenticated in a manner
-   identical to that of the MX RRset discussed above.
-
-B.3.1.  No Data Error, Empty Non-Terminal
-
-   A "no data" response because of an empty non-terminal.  The NSEC3 RR
-   proves that the name exists and that the requested RR type does not.
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 33]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   y.w.example.        IN A
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-   example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
-                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
-                              qYIt90txzE/4+g== )
-   jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN NSEC3  0 1 1 (
-                              deadbeaf
-                              kcll7fqfnisuhfekckeeqnmbbd4maanu
-                              NSEC3 RRSIG )
-   jt4bbfokgbmr57qx4nqucvvn7fmo6ab6.example. 3600 IN RRSIG  NSEC3 (
-                              5 2 3600 20050712112304
-                              20050612112304 62699 example.
-                              FXyCVQUdFF1EW1NcgD2V724/It0rn3lr+30V
-                              IyjmqwOMvQ4G599InTpiH46xhX3U/FmUzHOK
-                              94Zbq3k8lgdpZA== )
-
-   The query returned an NSEC3 RR that proves that the requested name
-   exists ("y.w.example." hashes to "jt4bbfokgbmr57qx4nqucvvn7fmo6ab6"),
-   but the requested RR type does not exist (Type A is absent in the
-   type-bit-maps of the NSEC3 RR).  The negative reply is authenticated
-   by verifying the NSEC3 RR.  The NSEC3 RR is authenticated in a manner
-   identical to that of the MX RRset discussed above.  Note that, unlike
-   generic empty non terminal proof using NSECs, this is identical to
-   proving a No Data Error.  This example is solely mentioned to be
-   complete.
-
-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.
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 34]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   ;; 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 IN DS  58470 5 1 (
-                              3079F1593EBAD6DC121E202A8B766A6A4837
-                              206C )
-   a.example.     3600 IN RRSIG  DS 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              QavhbsSmEvJLSUzGoTpsV3SKXCpaL1UO3Ehn
-                              cB0ObBIlex/Zs9kJyG/9uW1cYYt/1wvgzmX2
-                              0kx7rGKTc3RQDA== )
-
-   ;; Additional
-   ns1.a.example. 3600 IN A   192.0.2.5
-   ns2.a.example. 3600 IN A   192.0.2.6
-
-   The query 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 whether
-   this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether
-   the signature lifetime is valid.  If all these conditions are met,
-   all keys in the "a.example" DNSKEY RRset are considered
-   authenticated.
-
-B.5.  Referral to Unsigned Zone using the Opt-In Flag
-
-   The NSEC3 RR proves that nothing for this delegation was signed in
-   the parent zone.  There is no proof that the delegation exists
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 35]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   ;; 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.
-   kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN NSEC3  1 1 1 (
-                              deadbeaf
-                              n42hbhnjj333xdxeybycax5ufvntux5d
-                              MX NSEC3 RRSIG )
-   kcll7fqfnisuhfekckeeqnmbbd4maanu.example. 3600 IN RRSIG  NSEC3 (
-                              5 2 3600 20050712112304
-                              20050612112304 62699 example.
-                              d0g8MTOvVwByOAIwvYV9JrTHwJof1VhnMKuA
-                              IBj6Xaeney86RBZYgg7Qyt9WnQSK3uCEeNpx
-                              TOLtc5jPrkL4zQ== )
-
-   ;; Additional
-   ns1.b.example. 3600 IN A   192.0.2.7
-   ns2.b.example. 3600 IN A   192.0.2.8
-
-   The query returned a referral to the unsigned "b.example." zone.  The
-   NSEC3 proves that no authentication leads from "example" to
-   "b.example", since the hash of "b.example"
-   ("ldjpfcucebeks5azmzpty4qlel4cftzo") is within the NSEC3 interval and
-   the NSEC3 opt-in bit is set.  The NSEC3 RR is authenticated in a
-   manner identical to that of the MX RRset discussed above.
-
-B.6.  Wildcard Expansion
-
-   A successful query that 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 NSEC3 RR proves that
-   no closer match exists in the zone.
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 36]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   ;; 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 IN RRSIG  MX 5 3 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              sYNUPHn1/gJ87wTHNksGdRm3vfnSFa2BbofF
-                              xGfJLF5A4deRu5f0hvxhAFDCcXfIASj7z0wQ
-                              gQlgxEwhvQDEaQ== )
-   ;; Authority
-   example.       3600 NS     ns1.example.
-   example.       3600 NS     ns2.example.
-   example.       3600 IN RRSIG  NS 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              hNyyin2JpECIFxW4vsj8RhHcWCQKUXgO+z4l
-                              m7g2zM8q3Qpsm/gYIXSF2Rhj6lAG7esR/X9d
-                              1SH5r/wfjuCg+g== )
-   zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3  0 1 1 (
-                              deadbeaf
-                              5pe7ctl7pfs2cilroy5dcofx4rcnlypd
-                              MX NSEC3 RRSIG )
-   zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG  NSEC3 (
-                              5 2 3600 20050712112304
-                              20050612112304 62699 example.
-                              eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
-                              7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
-                              OcFlrPGPMm48/A== )
-   ;; Additional
-   ai.example.    3600 IN A   192.0.2.9
-   ai.example.    3600 IN RRSIG  A 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              plY5M26ED3Owe3YX0pBIhgg44j89NxUaoBrU
-                              6bLRr99HpKfFl1sIy18JiRS7evlxCETZgubq
-                              ZXW5S+1VjMZYzQ== )
-   ai.example.    3600 AAAA   2001:db8::f00:baa9
-   ai.example.    3600 IN RRSIG  AAAA 5 2 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              PNF/t7+DeosEjhfuL0kmsNJvn16qhYyLI9FV
-                              ypSCorFx/PKIlEL3syomkYM2zcXVSRwUXMns
-                              l5/UqLCJJ9BDMg== )
-
-   The query returned an answer that was produced as a result of
-   wildcard expansion.  The answer section contains a wildcard RRset
-   expanded as it would be in a traditional DNS response, and the
-   corresponding RRSIG indicates that the expanded wildcard MX RRset was
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 37]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   signed by an "example" DNSKEY with algorithm 5 and key tag 62699.
-   The RRSIG indicates that 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 that the answer
-   is the result of wildcard expansion, as the "a.z.w.example" name
-   contains 4 labels.  The name "a.z.w.example" is replaced by
-   "*.w.example", the MX RRset is placed in canonical form, and,
-   assuming that the current time falls between the signature inception
-   and expiration dates, the signature is authenticated.
-
-   The NSEC3 proves that no closer match (exact or closer wildcard)
-   could have been used to answer this query, and the NSEC3 RR must also
-   be authenticated before the answer is considered valid.
-
-B.7.  Wildcard No Data Error
-
-   A "no data" response for a name covered by a wildcard.  The NSEC3 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 38]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   a.z.w.example.      IN AAAA
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-   example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
-                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
-                              qYIt90txzE/4+g== )
-   zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN NSEC3  0 1 1 (
-                              deadbeaf
-                              5pe7ctl7pfs2cilroy5dcofx4rcnlypd
-                              MX NSEC3 RRSIG )
-   zjxfz5o7t4ty4u3f6fa7mhhqzjln4mui.example. 3600 IN RRSIG  NSEC3 (
-                              5 2 3600 20050712112304
-                              20050612112304 62699 example.
-                              eULkdWjcjmM+wXQcr7zXNfnGLgHjZSJINGkt
-                              7Zmvp7WKVAqoHMm1RXV8IfBH1aRgv5+/Lgny
-                              OcFlrPGPMm48/A== )
-   ;; Additional
-   ;; (empty)
-
-   The query returned NSEC3 RRs that prove that the requested data does
-   not exist and no wildcard applies.  The negative reply is
-   authenticated by verifying both NSEC3 RRs.
-
-B.8.  DS Child Zone No Data Error
-
-   A "no data" response for a QTYPE=DS query that was mistakenly sent to
-   a name server for the child zone.
-
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 39]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   example.            IN DS
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
-                              1
-                              3600
-                              300
-                              3600000
-                              3600
-                              )
-   example.       3600 IN RRSIG  SOA 5 1 3600 20050712112304 (
-                              20050612112304 62699 example.
-                              RtctD6aLUU5Md5wOOItilS7JXX1tf58Ql3sK
-                              mTXkL13jqLiUFOGg0uzqRh1U9GbydS0P7M0g
-                              qYIt90txzE/4+g== )
-   dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN NSEC3  0 1 1 (
-                              deadbeaf
-                              gmnfcccja7wkax3iv26bs75myptje3qk
-                              MX DNSKEY NS SOA NSEC3 RRSIG )
-   dw4o7j64wnel3j4jh7fb3c5n7w3js2yb.example. 3600 IN RRSIG  NSEC3 (
-                              5 2 3600 20050712112304
-                              20050612112304 62699 example.
-                              VqEbXiZLJVYmo25fmO3IuHkAX155y8NuA50D
-                              C0NmJV/D4R3rLm6tsL6HB3a3f6IBw6kKEa2R
-                              MOiKMSHozVebqw== )
-
-   ;; Additional
-   ;; (empty)
-
-   The query 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 that the answer is from the child .
-   Queries for the "example" DS RRset should be sent to the parent
-   servers ("root" servers).
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 40]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-Authors' Addresses
-
-   Ben Laurie
-   Nominet
-   17 Perryn Road
-   London  W3 7LR
-   England
-
-   Phone: +44 (20) 8735 0686
-   Email: ben@algroup.co.uk
-
-
-   Geoffrey Sisson
-   Nominet
-
-
-   Roy Arends
-   Nominet
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 41]
-
-Internet-Draft                    nsec3                    February 2006
-
-
-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 (2006).  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.
-
-
-
-
-Laurie, et al.           Expires August 5, 2006                [Page 42]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-nsid-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-nsid-01.txt
deleted file mode 100644
index 90d1a06..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-nsid-01.txt
+++ /dev/null
@@ -1,840 +0,0 @@
-
-
-
-Network Working Group                                         R. Austein
-Internet-Draft                                                       ISC
-Expires: July 15, 2006                                  January 11, 2006
-
-
-                DNS Name Server Identifier Option (NSID)
-                       draft-ietf-dnsext-nsid-01
-
-Status of this Memo
-
-   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 becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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 15, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-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.  While existing ad-hoc
-   mechanism allow an operator to send follow-up queries when it is
-   necessary to debug such a configuration, the only completely reliable
-   way to obtain the identity of the name server which responded is to
-   have the name server include this information in the response itself.
-   This note defines a protocol extension to support this functionality.
-
-
-
-Austein                   Expires July 15, 2006                 [Page 1]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     1.1.  Reserved Words . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     2.1.  Resolver Behavior  . . . . . . . . . . . . . . . . . . . .  4
-     2.2.  Name Server Behavior . . . . . . . . . . . . . . . . . . .  4
-     2.3.  The NSID Option  . . . . . . . . . . . . . . . . . . . . .  4
-     2.4.  Presentation Format  . . . . . . . . . . . . . . . . . . .  5
-   3.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  6
-     3.1.  The NSID Payload . . . . . . . . . . . . . . . . . . . . .  6
-     3.2.  NSID Is Not Transitive . . . . . . . . . . . . . . . . . .  8
-     3.3.  User Interface Issues  . . . . . . . . . . . . . . . . . .  8
-     3.4.  Truncation . . . . . . . . . . . . . . . . . . . . . . . .  9
-   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
-   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
-   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
-     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
-     7.2.  Informative References . . . . . . . . . . . . . . . . . . 13
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
-   Intellectual Property and Copyright Statements . . . . . . . . . . 15
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                   Expires July 15, 2006                 [Page 2]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-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.
-
-   Existing ad-hoc mechanisms allow an operator to send follow-up
-   queries when it is necessary to debug such a configuration, but there
-   are situations in which this is not a totally satisfactory solution,
-   since anycast routing may have changed, or the server pool in
-   question may be behind some kind of extremely dynamic load balancing
-   hardware.  Thus, while these ad-hoc mechanisms are certainly better
-   than nothing (and have the advantage of already being deployed), a
-   better solution seems desirable.
-
-   Given that a DNS query is an idempotent operation with no retained
-   state, it would appear that the only completely reliable way to
-   obtain the identity of the name server which responded to a
-   particular query is to have that name server include identifying
-   information in the response itself.  This note defines a protocol
-   enhancement to achieve this.
-
-1.1.  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 [RFC2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                   Expires July 15, 2006                 [Page 3]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-2.  Protocol
-
-   This note uses an EDNS [RFC2671] option to signal the resolver's
-   desire for information identifying the name server and to hold the
-   name server's response, if any.
-
-2.1.  Resolver Behavior
-
-   A resolver signals its desire for information identifying a name
-   server by sending an empty NSID option (Section 2.3) in an EDNS OPT
-   pseudo-RR in the query message.
-
-   The resolver MUST NOT include any NSID payload data in the query
-   message.
-
-   The semantics of an NSID request are not transitive.  That is: the
-   presence of an NSID option in a query is a request that the name
-   server which receives the query identify itself.  If the name server
-   side of a recursive name server receives an NSID request, the client
-   is asking the recursive name server to identify itself; if the
-   resolver side of the recursive name server wishes to receive
-   identifying information, it is free to add NSID requests in its own
-   queries, but that is a separate matter.
-
-2.2.  Name Server Behavior
-
-   A name server which understands the NSID option and chooses to honor
-   a particular NSID request responds by including identifying
-   information in a NSID option (Section 2.3) in an EDNS OPT pseudo-RR
-   in the response message.
-
-   The name server MUST ignore any NSID payload data that might be
-   present in the query message.
-
-   The NSID option is not transitive.  A name server MUST NOT send an
-   NSID option back to a resolver which did not request it.  In
-   particular, while a recursive name server may choose to add an NSID
-   option when sending a query, this has no effect on the presence or
-   absence of the NSID option in the recursive name server's response to
-   the original client.
-
-   As stated in Section 2.1, this mechanism is not restricted to
-   authoritative name servers; the semantics are intended to be equally
-   applicable to recursive name servers.
-
-2.3.  The NSID Option
-
-   The OPTION-CODE for the NSID option is [TBD].
-
-
-
-Austein                   Expires July 15, 2006                 [Page 4]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-   The OPTION-DATA for the NSID option is an opaque byte string the
-   semantics of which are deliberately left outside the protocol.  See
-   Section 3.1 for discussion.
-
-2.4.  Presentation Format
-
-   User interfaces MUST read and write the content of the NSID option as
-   a sequence of hexadecimal digits, two digits per payload octet.
-
-   The NSID payload is binary data.  Any comparison between NSID
-   payloads MUST be a comparison of the raw binary data.  Copy
-   operations MUST NOT assume that the raw NSID payload is null-
-   terminated.  Any resemblance between raw NSID payload data and any
-   form of text is purely a convenience, and does not change the
-   underlying nature of the payload data.
-
-   See Section 3.3 for discussion.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                   Expires July 15, 2006                 [Page 5]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-3.  Discussion
-
-   This section discusses certain aspects of the protocol and explains
-   considerations that led to the chosen design.
-
-3.1.  The NSID Payload
-
-   The syntax and semantics of the content of the NSID option is
-   deliberately left outside the scope of this specification.  This
-   section describe some of the kinds of data that server administrators
-   might choose to provide as the content of the NSID option, and
-   explains the reasoning behind choosing a simple opaque byte string.
-
-   There are several possibilities for the payload of the NSID option:
-
-   o  It could be the "real" name of the specific name server within the
-      name server pool.
-
-   o  It could be the "real" IP address (IPv4 or IPv6) of the name
-      server within the name server pool.
-
-   o  It could be some sort of pseudo-random number generated in a
-      predictable fashion somehow using the server's IP address or name
-      as a seed value.
-
-   o  It could be some sort of probabilisticly unique identifier
-      initially derived from some sort of random number generator then
-      preserved across reboots of the name server.
-
-   o  It could be some sort of dynamicly generated identifier so that
-      only the name server operator could tell whether or not any two
-      queries had been answered by the same server.
-
-   o  It could be a blob of signed data, with a corresponding key which
-      might (or might not) be available via DNS lookups.
-
-   o  It could be a blob of encrypted data, the key for which could be
-      restricted to parties with a need to know (in the opinion of the
-      server operator).
-
-   o  It could be an arbitrary string of octets chosen at the discretion
-      of the name server operator.
-
-   Each of these options has advantages and disadvantages:
-
-   o  Using the "real" name is simple, but the name server may not have
-      a "real" name.
-
-
-
-
-Austein                   Expires July 15, 2006                 [Page 6]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-   o  Using the "real" address is also simple, and the name server
-      almost certainly does have at least one non-anycast IP address for
-      maintenance operations, but the operator of the name server may
-      not be willing to divulge its non-anycast address.
-
-   o  Given that one common reason for using anycast DNS techniques is
-      an attempt to harden a critical name server against denial of
-      service attacks, some name server operators are likely to want an
-      identifier other than the "real" name or "real" address of the
-      name server instance.
-
-   o  Using a hash or pseudo-random number can provide a fixed length
-      value that the resolver can use to tell two name servers apart
-      without necessarily being able to tell where either one of them
-      "really" is, but makes debugging more difficult if one happens to
-      be in a friendly open environment.  Furthermore, hashing might not
-      add much value, since a hash based on an IPv4 address still only
-      involves a 32-bit search space, and DNS names used for servers
-      that operators might have to debug at 4am tend not to be very
-      random.
-
-   o  Probabilisticly unique identifiers have similar properties to
-      hashed identifiers, but (given a sufficiently good random number
-      generator) are immune to the search space issues.  However, the
-      strength of this approach is also its weakness: there is no
-      algorithmic transformation by which even the server operator can
-      associate name server instances with identifiers while debugging,
-      which might be annoying.  This approach also requires the name
-      server instance to preserve the probabilisticly unique identifier
-      across reboots, but this does not appear to be a serious
-      restriction, since authoritative nameservers almost always have
-      some form of nonvolatile storage in any case, and in the rare case
-      of a name server that does not have any way to store such an
-      identifier, nothing terrible will happen if the name server just
-      generates a new identifier every time it reboots.
-
-   o  Using an arbitrary octet string gives name server operators yet
-      another thing to configure, or mis-configure, or forget to
-      configure.  Having all the nodes in an anycast name server
-      constellation identify themselves as "My Name Server" would not be
-      particularly useful.
-
-   Given all of the issues listed above, there does not appear to be a
-   single solution that will meet all needs.  Section 2.3 therefore
-   defines the NSID payload to be an opaque byte string and leaves the
-   choice up to the implementor and name server operator.  The following
-   guidelines may be useful to implementors and server operators:
-
-
-
-
-Austein                   Expires July 15, 2006                 [Page 7]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-   o  Operators for whom divulging the unicast address is an issue could
-      use the raw binary representation of a probabilisticly unique
-      random number.  This should probably be the default implementation
-      behavior.
-
-   o  Operators for whom divulging the unicast address is not an issue
-      could just use the raw binary representation of a unicast address
-      for simplicity.  This should only be done via an explicit
-      configuration choice by the operator.
-
-   o  Operators who really need or want the ability to set the NSID
-      payload to an arbitrary value could do so, but this should only be
-      done via an explicit configuration choice by the operator.
-
-   This approach appears to provide enough information for useful
-   debugging without unintentionally leaking the maintenance addresses
-   of anycast name servers to nogoodniks, while also allowing name
-   server operators who do not find such leakage threatening to provide
-   more information at their own discretion.
-
-3.2.  NSID Is Not Transitive
-
-   As specified in Section 2.1 and Section 2.2, the NSID option is not
-   transitive.  This is strictly a hop-by-hop mechanism.
-
-   Most of the discussion of name server identification to date has
-   focused on identifying authoritative name servers, since the best
-   known cases of anycast name servers are a subset of the name servers
-   for the root zone.  However, given that anycast DNS techniques are
-   also applicable to recursive name servers, the mechanism may also be
-   useful with recursive name servers.  The hop-by-hop semantics support
-   this.
-
-   While there might be some utility in having a transitive variant of
-   this mechanism (so that, for example, a stub resolver could ask a
-   recursive server to tell it which authoritative name server provided
-   a particular answer to the recursive name server), the semantics of
-   such a variant would be more complicated, and are left for future
-   work.
-
-3.3.  User Interface Issues
-
-   Given the range of possible payload contents described in
-   Section 3.1, it is not possible to define a single presentation
-   format for the NSID payload that is efficient, convenient,
-   unambiguous, and aesthetically pleasing.  In particular, while it is
-   tempting to use a presentation format that uses some form of textual
-   strings, attempting to support this would significantly complicate
-
-
-
-Austein                   Expires July 15, 2006                 [Page 8]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-   what's intended to be a very simple debugging mechanism.
-
-   In some cases the content of the NSID payload may be binary data
-   meaningful only to the name server operator, and may not be
-   meaningful to the user or application, but the user or application
-   must be able to capture the entire content anyway in order for it to
-   be useful.  Thus, the presentation format must support arbitrary
-   binary data.
-
-   In cases where the name server operator derives the NSID payload from
-   textual data, a textual form such as US-ASCII or UTF-8 strings might
-   at first glance seem easier for a user to deal with.  There are,
-   however, a number of complex issues involving internationalized text
-   which, if fully addressed here, would require a set of rules
-   significantly longer than the rest of this specification.  See
-   [RFC2277] for an overview of some of these issues.
-
-   It is much more important for the NSID payload data to be passed
-   unambiguously from server administrator to user and back again than
-   it is for the payload data data to be pretty while in transit.  In
-   particular, it's critical that it be straightforward for a user to
-   cut and paste an exact copy of the NSID payload output by a debugging
-   tool into other formats such as email messages or web forms without
-   distortion.  Hexadecimal strings, while ugly, are also robust.
-
-3.4.  Truncation
-
-   In some cases, adding the NSID option to a response message may
-   trigger message truncation.  This specification does not change the
-   rules for DNS message truncation in any way, but implementors will
-   need to pay attention to this issue.
-
-   Including the NSID option in a response is always optional, so this
-   specification never requires name servers to truncate response
-   messages.
-
-   By definition, a resolver that requests NSID responses also supports
-   EDNS, so a resolver that requests NSID responses can also use the
-   "sender's UDP payload size" field of the OPT pseudo-RR to signal a
-   receive buffer size large enough to make truncation unlikely.
-
-
-
-
-
-
-
-
-
-
-
-Austein                   Expires July 15, 2006                 [Page 9]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-4.  IANA Considerations
-
-   This mechanism requires allocation of one ENDS option code for the
-   NSID option (Section 2.3).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                   Expires July 15, 2006                [Page 10]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-5.  Security Considerations
-
-   This document describes a channel signaling mechanism, intended
-   primarily for debugging.  Channel signaling mechanisms are outside
-   the scope of DNSSEC per se.  Applications that require integrity
-   protection for the data being signaled will need to use a channel
-   security mechanism such as TSIG [RFC2845].
-
-   Section 3.1 discusses a number of different kinds of information that
-   a name server operator might choose to provide as the value of the
-   NSID option.  Some of these kinds of information are security
-   sensitive in some environments.  This specification deliberately
-   leaves the syntax and semantics of the NSID option content up to the
-   implementation and the name server operator.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                   Expires July 15, 2006                [Page 11]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-6.  Acknowledgements
-
-   Joe Abley, Harald Alvestrand, Mark Andrews, Roy Arends, Steve
-   Bellovin, Randy Bush, David Conrad, Johan Ihren, Daniel Karrenberg,
-   Peter Koch, Mike Patton, Mike StJohns, Paul Vixie, Sam Weiler, and
-   Suzanne Woolf.  Apologies to anyone inadvertently omitted from the
-   above list.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                   Expires July 15, 2006                [Page 12]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-7.  References
-
-7.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", RFC 2119, BCP 14, March 1997.
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
-              RFC 2671, August 1999.
-
-   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
-              Wellington, "Secret Key Transaction Authentication for DNS
-              (TSIG)", RFC 2845, May 2000.
-
-7.2.  Informative References
-
-   [RFC2277]  Alvestrand, H., "IETF Policy on Character Sets and
-              Languages", RFC 2277, BCP 18, January 1998.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                   Expires July 15, 2006                [Page 13]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-Author's Address
-
-   Rob Austein
-   ISC
-   950 Charter Street
-   Redwood City, CA  94063
-   USA
-
-   Email: sra@isc.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                   Expires July 15, 2006                [Page 14]
-
-Internet-Draft                  DNS NSID                    January 2006
-
-
-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 (2006).  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.
-
-
-
-
-Austein                   Expires July 15, 2006                [Page 15]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt
deleted file mode 100644
index 5b6d655..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt
+++ /dev/null
@@ -1,464 +0,0 @@
-
-INTERNET-DRAFT                                DSA Information in the DNS
-OBSOLETES: RFC 2536                               Donald E. Eastlake 3rd
-                                                   Motorola Laboratories
-Expires: January 2006                                          July 2005
-
-
-            DSA Keying and Signature Information in the DNS
-            --- ------ --- --------- ----------- -- --- ---
-               <draft-ietf-dnsext-rfc2536bis-dsa-06.txt>
-                         Donald E. Eastlake 3rd
-
-
-Status of This Document
-
-   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 becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Distribution of this document is unlimited. Comments should be sent
-   to the DNS extensions 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
-
-   The standard method of encoding US Government Digital Signature
-   Algorithm keying and signature information for use in the Domain Name
-   System is specified.
-
-
-Copyright Notice
-
-   Copyright (C) The Internet Society 2005. All Rights Reserved.
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 1]
-
-
-INTERNET-DRAFT                                DSA Information in the DNS
-
-
-Table of Contents
-
-      Status of This Document....................................1
-      Abstract...................................................1
-      Copyright Notice...........................................1
-
-      Table of Contents..........................................2
-
-      1. Introduction............................................3
-      2. DSA Keying Information..................................3
-      3. DSA Signature Information...............................4
-      4. Performance Considerations..............................4
-      5. Security Considerations.................................5
-      6. IANA Considerations.....................................5
-      Copyright and Disclaimer...................................5
-
-      Normative References.......................................7
-      Informative References.....................................7
-
-      Authors Address............................................8
-      Expiration and File Name...................................8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 2]
-
-
-INTERNET-DRAFT                                DSA Information in the DNS
-
-
-1. Introduction
-
-   The Domain Name System (DNS) is the global hierarchical replicated
-   distributed database system for Internet addressing, mail proxy, and
-   other information [RFC 1034, 1035]. The DNS has been extended to
-   include digital signatures and cryptographic keys as described in
-   [RFC 4033, 4034, 4035] and additional work is underway which would
-   require the storage of keying and signature information in the DNS.
-
-   This document describes how to encode US Government Digital Signature
-   Algorithm (DSA) keys and signatures in the DNS.  Familiarity with the
-   US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier].
-
-
-
-2. DSA Keying Information
-
-   When DSA public keys are stored in the DNS, the structure of the
-   relevant part of the RDATA part of the RR being used is the fields
-   listed below in the order given.
-
-   The period of key validity is not included in this data but is
-   indicated separately, for example by an RR such as RRSIG which signs
-   and authenticates the RR containing the keying information.
-
-        Field     Size
-        -----     ----
-         T         1  octet
-         Q        20  octets
-         P        64 + T*8  octets
-         G        64 + T*8  octets
-         Y        64 + T*8  octets
-
-   As described in [FIPS 186-2] and [Schneier], T is a key size
-   parameter chosen such that 0 <= T <= 8.  (The meaning if the T octet
-   is greater than 8 is reserved and the remainder of the data may have
-   a different format in that case.)  Q is a prime number selected at
-   key generation time such that 2**159 < Q < 2**160. Thus Q is always
-   20 octets long and, as with all other fields, is stored in "big-
-   endian" network order.  P, G, and Y are calculated as directed by the
-   [FIPS 186-2] key generation algorithm [Schneier].  P is in the range
-   2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long.  G
-   and Y are quantities modulo P and so can be up to the same length as
-   P and are allocated fixed size fields with the same number of octets
-   as P.
-
-   During the key generation process, a random number X must be
-   generated such that 1 <= X <= Q-1.  X is the private key and is used
-   in the final step of public key generation where Y is computed as
-
-
-
-D. Eastlake 3rd                                                 [Page 3]
-
-
-INTERNET-DRAFT                                DSA Information in the DNS
-
-
-        Y = G**X mod P
-
-
-
-3. DSA Signature Information
-
-   The portion of the RDATA area used for US Digital Signature Algorithm
-   signature information is shown below with fields in the order they
-   are listed and the contents of each multi-octet field in "big-endian"
-   network order.
-
-        Field     Size
-        -----     ----
-         T         1 octet
-         R        20 octets
-         S        20 octets
-
-   First, the data signed must be determined.  Then the following steps
-   are taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as
-   specified in the public key [Schneier]:
-
-        hash = SHA-1 ( data )
-
-        Generate a random K such that 0 < K < Q.
-
-        R = ( G**K mod P ) mod Q
-
-        S = ( K**(-1) * (hash + X*R) ) mod Q
-
-   For information on the SHA-1 hash function see [FIPS 180-2] and [RFC
-   3174].
-
-   Since Q is 160 bits long, R and S can not be larger than 20 octets,
-   which is the space allocated.
-
-   T is copied from the public key.  It is not logically necessary in
-   the SIG but is present so that values of T > 8 can more conveniently
-   be used as an escape for extended versions of DSA or other algorithms
-   as later standardized.
-
-
-
-4. Performance Considerations
-
-   General signature generation speeds are roughly the same for RSA [RFC
-   3110] and DSA.  With sufficient pre-computation, signature generation
-   with DSA is faster than RSA.  Key generation is also faster for DSA.
-   However, signature verification is an order of magnitude slower than
-   RSA when the RSA public exponent is chosen to be small, as is
-   recommended for some applications.
-
-
-D. Eastlake 3rd                                                 [Page 4]
-
-
-INTERNET-DRAFT                                DSA Information in the DNS
-
-
-   Current DNS implementations are optimized for small transfers,
-   typically less than 512 bytes including DNS overhead.  Larger
-   transfers will perform correctly and extensions have been
-   standardized [RFC 2671] to make larger transfers more efficient, it
-   is still advisable at this time to make reasonable efforts to
-   minimize the size of RR sets containing keying and/or signature
-   inforamtion consistent with adequate security.
-
-
-
-5. Security Considerations
-
-   Keys retrieved from the DNS should not be trusted unless (1) they
-   have been securely obtained from a secure resolver or independently
-   verified by the user and (2) this secure resolver and secure
-   obtainment or independent verification conform to security policies
-   acceptable to the user.  As with all cryptographic algorithms,
-   evaluating the necessary strength of the key is essential and
-   dependent on local policy.
-
-   The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
-   current DSA standard may limit the security of DSA.  For particular
-   applications, implementors are encouraged to consider the range of
-   available algorithms and key sizes.
-
-   DSA assumes the ability to frequently generate high quality random
-   numbers.  See [random] for guidance.  DSA is designed so that if
-   biased rather than random numbers are used, high bandwidth covert
-   channels are possible.  See [Schneier] and more recent research.  The
-   leakage of an entire DSA private key in only two DSA signatures has
-   been demonstrated.  DSA provides security only if trusted
-   implementations, including trusted random number generation, are
-   used.
-
-
-
-6. IANA Considerations
-
-   Allocation of meaning to values of the T parameter that are not
-   defined herein (i.e., > 8 ) requires an IETF standards actions.  It
-   is intended that values unallocated herein be used to cover future
-   extensions of the DSS standard.
-
-
-
-Copyright and Disclaimer
-
-   Copyright (C) The Internet Society (2005).  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.
-
-
-D. Eastlake 3rd                                                 [Page 5]
-
-
-INTERNET-DRAFT                                DSA Information in the DNS
-
-
-   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                                DSA Information in the DNS
-
-
-Normative References
-
-   [FIPS 186-2] - U.S. Federal Information Processing Standard: Digital
-   Signature Standard, 27 January 2000.
-
-   [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
-   March 2005.
-
-
-
-Informative References
-
-   [RFC 1034] - "Domain names - concepts and facilities", P.
-   Mockapetris, 11/01/1987.
-
-   [RFC 1035] - "Domain names - implementation and specification", P.
-   Mockapetris, 11/01/1987.
-
-   [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
-   1999.
-
-   [RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
-   (DNS)", D.  Eastlake 3rd. May 2001.
-
-   [RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P.
-   Jones, September 2001.
-
-   [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "DNS Security Introduction and Requirements", RFC 4033, March
-   2005.
-
-   [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "Protocol Modifications for the DNS Security Extensions", RFC
-   4035, March 2005.
-
-   [RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
-   "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
-
-   [Schneier] - "Applied Cryptography Second Edition: protocols,
-   algorithms, and source code in C" (second edition), Bruce Schneier,
-   1996, John Wiley and Sons, ISBN 0-471-11709-9.
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 7]
-
-
-INTERNET-DRAFT                                DSA Information in the DNS
-
-
-Authors Address
-
-   Donald E. Eastlake 3rd
-   Motorola Labortories
-   155 Beaver Street
-   Milford, MA 01757 USA
-
-   Telephone:   +1-508-786-7554(w)
-   EMail:       Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
-   This draft expires in January 2006.
-
-   Its file name is draft-ietf-dnsext-rfc2536bis-dsa-06.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 8]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt
deleted file mode 100644
index 2ec9dbe..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt
+++ /dev/null
@@ -1,840 +0,0 @@
-
-
-
-Network Working Group                                       S. Josefsson
-Internet-Draft                                           August 30, 2005
-Expires: March 3, 2006
-
-
-          Storing Certificates in the Domain Name System (DNS)
-                    draft-ietf-dnsext-rfc2538bis-04
-
-Status of this Memo
-
-   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 becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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 March 3, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   Cryptographic public keys are frequently published and their
-   authenticity demonstrated by certificates.  A CERT resource record
-   (RR) is defined so that such certificates and related certificate
-   revocation lists can be stored in the Domain Name System (DNS).
-
-   This document obsoletes RFC 2538.
-
-
-
-
-
-
-Josefsson                 Expires March 3, 2006                 [Page 1]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  The CERT Resource Record . . . . . . . . . . . . . . . . . . .  3
-     2.1.  Certificate Type Values  . . . . . . . . . . . . . . . . .  4
-     2.2.  Text Representation of CERT RRs  . . . . . . . . . . . . .  5
-     2.3.  X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . .  6
-   3.  Appropriate Owner Names for CERT RRs . . . . . . . . . . . . .  6
-     3.1.  Content-based X.509 CERT RR Names  . . . . . . . . . . . .  7
-     3.2.  Purpose-based X.509 CERT RR Names  . . . . . . . . . . . .  8
-     3.3.  Content-based OpenPGP CERT RR Names  . . . . . . . . . . .  9
-     3.4.  Purpose-based OpenPGP CERT RR Names  . . . . . . . . . . .  9
-     3.5.  Owner names for IPKIX, ISPKI, and IPGP . . . . . . . . . .  9
-   4.  Performance Considerations . . . . . . . . . . . . . . . . . . 10
-   5.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
-   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
-   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
-   9.  Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 11
-   Appendix A.  Copying conditions  . . . . . . . . . . . . . . . . . 12
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
-     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
-     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
-   Intellectual Property and Copyright Statements . . . . . . . . . . 15
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                 Expires March 3, 2006                 [Page 2]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-1.  Introduction
-
-   Public keys are frequently published in the form of a certificate and
-   their authenticity is commonly demonstrated by certificates and
-   related certificate revocation lists (CRLs).  A certificate is a
-   binding, through a cryptographic digital signature, of a public key,
-   a validity interval and/or conditions, and identity, authorization,
-   or other information.  A certificate revocation list is a list of
-   certificates that are revoked, and incidental information, all signed
-   by the signer (issuer) of the revoked certificates.  Examples are
-   X.509 certificates/CRLs in the X.500 directory system or OpenPGP
-   certificates/revocations used by OpenPGP software.
-
-   Section 2 below specifies a CERT resource record (RR) for the storage
-   of certificates in the Domain Name System [1] [2].
-
-   Section 3 discusses appropriate owner names for CERT RRs.
-
-   Sections 4, 5, and 6 below cover performance, IANA, and security
-   considerations, respectively.
-
-   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 [3].
-
-
-2.  The CERT Resource Record
-
-   The CERT resource record (RR) has the structure given below.  Its RR
-   type code is 37.
-
-                       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              |             key tag           |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |   algorithm   |                                               /
-   +---------------+            certificate or CRL                 /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
-   The type field is the certificate type as defined in section 2.1
-   below.
-
-   The key tag field is the 16 bit value computed for the key embedded
-   in the certificate, using the RRSIG Key Tag algorithm described in
-   Appendix B of [10].  This field is used as an efficiency measure to
-   pick which CERT RRs may be applicable to a particular key.  The key
-
-
-
-Josefsson                 Expires March 3, 2006                 [Page 3]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-   tag can be calculated for the key in question and then only CERT RRs
-   with the same key tag need be examined.  However, the key must always
-   be transformed to the format it would have as the public key portion
-   of a DNSKEY RR before the key tag is computed.  This is only possible
-   if the key is applicable to an algorithm (and limits such as key size
-   limits) defined for DNS security.  If it is not, the algorithm field
-   MUST BE zero and the tag field is meaningless and SHOULD BE zero.
-
-   The algorithm field has the same meaning as the algorithm field in
-   DNSKEY and RRSIG RRs [10], except that a zero algorithm field
-   indicates the algorithm is unknown to a secure DNS, which may simply
-   be the result of the algorithm not having been standardized for
-   DNSSEC.
-
-2.1.  Certificate Type Values
-
-   The following values are defined or reserved:
-
-       Value  Mnemonic  Certificate Type
-       -----  --------  ----------------
-           0            reserved
-           1  PKIX      X.509 as per PKIX
-           2  SPKI      SPKI certificate
-           3  PGP       OpenPGP packet
-           4  IPKIX     The URL of an X.509 data object
-           5  ISPKI     The URL of an SPKI certificate
-           6  IPGP      The URL of an OpenPGP packet
-       7-252            available for IANA assignment
-         253  URI       URI private
-         254  OID       OID private
-   255-65534            available for IANA assignment
-       65535            reserved
-
-   The PKIX type is reserved to indicate an X.509 certificate conforming
-   to the profile being defined by the IETF PKIX working group.  The
-   certificate section will start with a one-byte unsigned OID length
-   and then an X.500 OID indicating the nature of the remainder of the
-   certificate section (see 2.3 below).  (NOTE: X.509 certificates do
-   not include their X.500 directory type designating OID as a prefix.)
-
-   The SPKI type is reserved to indicate the SPKI certificate format
-   [13], for use when the SPKI documents are moved from experimental
-   status.
-
-   The PGP type indicates an OpenPGP packet as described in [6] and its
-   extensions and successors.  Two uses are to transfer public key
-   material and revocation signatures.  The data is binary, and MUST NOT
-   be encoded into an ASCII armor.  An implementation SHOULD process
-
-
-
-Josefsson                 Expires March 3, 2006                 [Page 4]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-   transferable public keys as described in section 10.1 of [6], but it
-   MAY handle additional OpenPGP packets.
-
-   The IPKIX, ISPKI and IPGP types indicate a URL which will serve the
-   content that would have been in the "certificate, CRL or URL" field
-   of the corresponding (PKIX, SPKI or PGP) packet types.  These types
-   are known as "indirect".  These packet types MUST be used when the
-   content is too large to fit in the CERT RR, and MAY be used at the
-   implementer's discretion.  They SHOULD NOT be used where the entire
-   UDP packet would have fit in 512 bytes.
-
-   The URI private type indicates a certificate format defined by an
-   absolute URI.  The certificate portion of the CERT RR MUST begin with
-   a null terminated URI [5] and the data after the null is the private
-   format certificate itself.  The URI SHOULD be such that a retrieval
-   from it will lead to documentation on the format of the certificate.
-   Recognition of private certificate types need not be based on URI
-   equality but can use various forms of pattern matching so that, for
-   example, subtype or version information can also be encoded into the
-   URI.
-
-   The OID private type indicates a private format certificate specified
-   by an ISO OID prefix.  The certificate section will start with a one-
-   byte unsigned OID length and then a BER encoded OID indicating the
-   nature of the remainder of the certificate section.  This can be an
-   X.509 certificate format or some other format.  X.509 certificates
-   that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
-   type, not the OID private type.  Recognition of private certificate
-   types need not be based on OID equality but can use various forms of
-   pattern matching such as OID prefix.
-
-2.2.  Text Representation of CERT RRs
-
-   The RDATA portion of a CERT RR has the type field as an unsigned
-   decimal integer or as a mnemonic symbol as listed in section 2.1
-   above.
-
-   The key tag field is represented as an unsigned decimal integer.
-
-   The algorithm field is represented as an unsigned decimal integer or
-   a mnemonic symbol as listed in [10].
-
-   The certificate / CRL portion is represented in base 64 [14] and may
-   be divided up into any number of white space separated substrings,
-   down to single base 64 digits, which are concatenated to obtain the
-   full signature.  These substrings can span lines using the standard
-   parenthesis.
-
-
-
-
-Josefsson                 Expires March 3, 2006                 [Page 5]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-   Note that the certificate / CRL portion may have internal sub-fields,
-   but these do not appear in the master file representation.  For
-   example, with type 254, there will be an OID size, an OID, and then
-   the certificate / CRL proper.  But only a single logical base 64
-   string will appear in the text representation.
-
-2.3.  X.509 OIDs
-
-   OIDs have been defined in connection with the X.500 directory for
-   user certificates, certification authority certificates, revocations
-   of certification authority, and revocations of user certificates.
-   The following table lists the OIDs, their BER encoding, and their
-   length-prefixed hex format for use in CERT RRs:
-
-       id-at-userCertificate
-           = { joint-iso-ccitt(2) ds(5) at(4) 36 }
-              == 0x 03 55 04 24
-       id-at-cACertificate
-           = { joint-iso-ccitt(2) ds(5) at(4) 37 }
-              == 0x 03 55 04 25
-       id-at-authorityRevocationList
-           = { joint-iso-ccitt(2) ds(5) at(4) 38 }
-              == 0x 03 55 04 26
-       id-at-certificateRevocationList
-           = { joint-iso-ccitt(2) ds(5) at(4) 39 }
-              == 0x 03 55 04 27
-
-
-3.  Appropriate Owner Names for CERT RRs
-
-   It is recommended that certificate CERT RRs be stored under a domain
-   name related to their subject, i.e., the name of the entity intended
-   to control the private key corresponding to the public key being
-   certified.  It is recommended that certificate revocation list CERT
-   RRs be stored under a domain name related to their issuer.
-
-   Following some of the guidelines below may result in the use in DNS
-   names of characters that require DNS quoting which is to use a
-   backslash followed by the octal representation of the ASCII code for
-   the character (e.g., \000 for NULL).
-
-   The choice of name under which CERT RRs are stored is important to
-   clients that perform CERT queries.  In some situations, the clients
-   may not know all information about the CERT RR object it wishes to
-   retrieve.  For example, a client may not know the subject name of an
-   X.509 certificate, or the e-mail address of the owner of an OpenPGP
-   key.  Further, the client might only know the hostname of a service
-   that uses X.509 certificates or the Key ID of an OpenPGP key.
-
-
-
-Josefsson                 Expires March 3, 2006                 [Page 6]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-   Therefore, two owner name guidelines are defined: content-based owner
-   names and purpose-based owner names.  A content-based owner name is
-   derived from the content of the CERT RR data; for example, the
-   Subject field in an X.509 certificate or the User ID field in OpenPGP
-   keys.  A purpose-based owner name is a name that a client retrieving
-   CERT RRs MUST already know; for example, the host name of an X.509
-   protected service or the Key ID of an OpenPGP key.  The content-based
-   and purpose-based owner name MAY be the same; for example, when a
-   client looks up a key based on the From: address of an incoming
-   e-mail.
-
-   Implementations SHOULD use the purpose-based owner name guidelines
-   described in this document, and MAY use CNAMEs of content-based owner
-   names (or other names), pointing to the purpose-based owner name.
-
-3.1.  Content-based X.509 CERT RR Names
-
-   Some X.509 versions permit multiple names to be associated with
-   subjects and issuers under "Subject Alternate Name" and "Issuer
-   Alternate Name".  For example, X.509v3 has such Alternate Names with
-   an ASN.1 specification as follows:
-
-        GeneralName ::= CHOICE {
-           otherName                  [0] INSTANCE OF OTHER-NAME,
-           rfc822Name                 [1] IA5String,
-           dNSName                    [2] IA5String,
-           x400Address                [3] EXPLICIT OR-ADDRESS.&Type,
-           directoryName              [4] EXPLICIT Name,
-           ediPartyName               [5] EDIPartyName,
-           uniformResourceIdentifier  [6] IA5String,
-           iPAddress                  [7] OCTET STRING,
-           registeredID               [8] OBJECT IDENTIFIER
-        }
-
-   The recommended locations of CERT storage are as follows, in priority
-   order:
-   1.  If a domain name is included in the identification in the
-       certificate or CRL, that should be used.
-   2.  If a domain name is not included but an IP address is included,
-       then the translation of that IP address into the appropriate
-       inverse domain name should be used.
-   3.  If neither of the above is used, but a URI containing a domain
-       name is present, that domain name should be used.
-   4.  If none of the above is included but a character string name is
-       included, then it should be treated as described for OpenPGP
-       names below.
-
-
-
-
-
-Josefsson                 Expires March 3, 2006                 [Page 7]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-   5.  If none of the above apply, then the distinguished name (DN)
-       should be mapped into a domain name as specified in [4].
-
-   Example 1: An X.509v3 certificate is issued to /CN=John Doe /DC=Doe/
-   DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Names of (a)
-   string "John (the Man) Doe", (b) domain name john-doe.com, and (c)
-   uri <https://www.secure.john-doe.com:8080/>.  The storage locations
-   recommended, in priority order, would be
-   1.  john-doe.com,
-   2.  www.secure.john-doe.com, and
-   3.  Doe.com.xy.
-
-   Example 2: An X.509v3 certificate is issued to /CN=James Hacker/
-   L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a)
-   domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and
-   (c) string "James Hacker <hacker@mail.widget.foo.example>".  The
-   storage locations recommended, in priority order, would be
-   1.  widget.foo.example,
-   2.  201.13.251.10.in-addr.arpa, and
-   3.  hacker.mail.widget.foo.example.
-
-3.2.  Purpose-based X.509 CERT RR Names
-
-   Due to the difficulty for clients that do not already possess a
-   certificate to reconstruct the content-based owner name, purpose-
-   based owner names are recommended in this section.  Recommendations
-   for purpose-based owner names vary per scenario.  The following table
-   summarizes the purpose-based X.509 CERT RR owner name guidelines for
-   use with S/MIME [16], SSL/TLS [11], and IPSEC [12]:
-
-    Scenario             Owner name
-    ------------------   ----------------------------------------------
-    S/MIME Certificate   Standard translation of an RFC 2822 email
-                         address.  Example: An S/MIME certificate for
-                         "postmaster@example.org" will use a standard
-                         hostname translation of the owner name,
-                         "postmaster.example.org".
-
-    TLS Certificate      Hostname of the TLS server.
-
-    IPSEC Certificate    Hostname of the IPSEC machine and/or, for IPv4
-                         or IPv6 addresses, the fully qualified domain
-                         name in the appropriate reverse domain.
-
-   An alternate approach for IPSEC is to store raw public keys [15].
-
-
-
-
-
-
-Josefsson                 Expires March 3, 2006                 [Page 8]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-3.3.  Content-based OpenPGP CERT RR Names
-
-   OpenPGP signed keys (certificates) use a general character string
-   User ID [6].  However, it is recommended by OpenPGP that such names
-   include the RFC 2822 [8] email address of the party, as in "Leslie
-   Example <Leslie@host.example>".  If such a format is used, the CERT
-   should be under the standard translation of the email address into a
-   domain name, which would be leslie.host.example in this case.  If no
-   RFC 2822 name can be extracted from the string name, no specific
-   domain name is recommended.
-
-   If a user has more than one email address, the CNAME type can be used
-   to reduce the amount of data stored in the DNS.  Example:
-
-      $ORIGIN example.org.
-      smith        IN CERT PGP 0 0 <OpenPGP binary>
-      john.smith   IN CNAME smith
-      js           IN CNAME smith
-
-3.4.  Purpose-based OpenPGP CERT RR Names
-
-   Applications that receive an OpenPGP packet containing encrypted or
-   signed data but do not know the email address of the sender will have
-   difficulties constructing the correct owner name and cannot use the
-   content-based owner name guidelines.  However, these clients commonly
-   know the key fingerprint or the Key ID.  The key ID is found in
-   OpenPGP packets, and the key fingerprint is commonly found in
-   auxilliary data that may be available.  In this case, use of an owner
-   name identical to the key fingerprint and the key ID expressed in
-   hexadecimal [14] is recommended.  Example:
-
-      $ORIGIN example.org.
-      0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ...
-      F835EDA21E94B565716F                     IN CERT PGP ...
-      B565716F                                 IN CERT PGP ...
-
-   If the same key material is stored for several owner names, the use
-   of CNAME may be used to avoid data duplication.  Note that CNAME is
-   not always applicable, because it maps one owner name to the other
-   for all purposes, which may be sub-optimal when two keys with the
-   same Key ID are stored.
-
-3.5.  Owner names for IPKIX, ISPKI, and IPGP
-
-   These types are stored under the same owner names, both purpose- and
-   content-based, as the PKIX, SPKI and PGP types.
-
-
-
-
-
-Josefsson                 Expires March 3, 2006                 [Page 9]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-4.  Performance Considerations
-
-   Current Domain Name System (DNS) implementations are optimized for
-   small transfers, typically not more than 512 bytes including
-   overhead.  While larger transfers will perform correctly and work is
-   underway to make larger transfers more efficient, it is still
-   advisable at this time to make every reasonable effort to minimize
-   the size of certificates stored within the DNS.  Steps that can be
-   taken may include using the fewest possible optional or extension
-   fields and using short field values for necessary variable length
-   fields.
-
-   The RDATA field in the DNS protocol may only hold data of size 65535
-   octets (64kb) or less.  This means that each CERT RR MUST NOT contain
-   more than 64kb of payload, even if the corresponding certificate or
-   certificate revocation list is larger.  This document addresses this
-   by defining "indirect" data types for each normal type.
-
-
-5.  Contributors
-
-   The majority of this document is copied verbatim from RFC 2538, by
-   Donald Eastlake 3rd and Olafur Gudmundsson.
-
-
-6.  Acknowledgements
-
-   Thanks to David Shaw and Michael Graff for their contributions to
-   earlier works that motivated, and served as inspiration for, this
-   document.
-
-   This document was improved by suggestions and comments from Olivier
-   Dubuisson, Olaf M. Kolkman, Ben Laurie, Edward Lewis, Jason
-   Sloderbeck, Samuel Weiler, and Florian Weimer.  No doubt the list is
-   incomplete.  We apologize to anyone we left out.
-
-
-7.  Security Considerations
-
-   By definition, certificates contain their own authenticating
-   signature.  Thus, it is reasonable to store certificates in non-
-   secure DNS zones or to retrieve certificates from DNS with DNS
-   security checking not implemented or deferred for efficiency.  The
-   results MAY be trusted if the certificate chain is verified back to a
-   known trusted key and this conforms with the user's security policy.
-
-   Alternatively, if certificates are retrieved from a secure DNS zone
-   with DNS security checking enabled and are verified by DNS security,
-
-
-
-Josefsson                 Expires March 3, 2006                [Page 10]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-   the key within the retrieved certificate MAY be trusted without
-   verifying the certificate chain if this conforms with the user's
-   security policy.
-
-   If an organization chooses to issue certificates for it's employees,
-   placing CERT RR's in the DNS by owner name, and if DNSSEC (with NSEC)
-   is in use, it is possible for someone to enumerate all employees of
-   the organization.  This is usually not considered desirable, for the
-   same reason enterprise phone listings are not often publicly
-   published and are even mark confidential.
-
-   When the URI type is used, it should be understood that it introduces
-   an additional indirection that may allow for a new attack vector.
-   One method to secure that indirection is to include a hash of the
-   certificate in the URI itself.
-
-   CERT RRs are not used by DNSSEC [9], so there are no security
-   considerations related to CERT RRs and securing the DNS itself.
-
-   If DNSSEC is used, then the non-existence of a CERT RR and,
-   consequently, certificates or revocation lists can be securely
-   asserted.  Without DNSSEC, this is not possible.
-
-
-8.  IANA Considerations
-
-   Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
-   only be assigned by an IETF standards action [7].  This document
-   assigns 0x0001 through 0x0006 and 0x00FD and 0x00FE.  Certificate
-   types 0x0100 through 0xFEFF are assigned through IETF Consensus [7]
-   based on RFC documentation of the certificate type.  The availability
-   of private types under 0x00FD and 0x00FE should satisfy most
-   requirements for proprietary or private types.
-
-   The CERT RR reuses the DNS Security Algorithm Numbers registry.  In
-   particular, the CERT RR requires that algorithm number 0 remain
-   reserved, as described in Section 2.  The IANA is directed to
-   reference the CERT RR as a user of this registry and value 0, in
-   particular.
-
-
-9.  Changes since RFC 2538
-
-   1.   Editorial changes to conform with new document requirements,
-        including splitting reference section into two parts and
-        updating the references to point at latest versions, and to add
-        some additional references.
-
-
-
-
-Josefsson                 Expires March 3, 2006                [Page 11]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-   2.   Improve terminology.  For example replace "PGP" with "OpenPGP",
-        to align with RFC 2440.
-   3.   In section 2.1, clarify that OpenPGP public key data are binary,
-        not the ASCII armored format, and reference 10.1 in RFC 2440 on
-        how to deal with OpenPGP keys, and acknowledge that
-        implementations may handle additional packet types.
-   4.   Clarify that integers in the representation format are decimal.
-   5.   Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis
-        terminology.  Improve reference for Key Tag Algorithm
-        calculations.
-   6.   Add examples that suggest use of CNAME to reduce bandwidth.
-   7.   In section 3, appended the last paragraphs that discuss
-        "content-based" vs "purpose-based" owner names.  Add section 3.2
-        for purpose-based X.509 CERT owner names, and section 3.4 for
-        purpose-based OpenPGP CERT owner names.
-   8.   Added size considerations.
-   9.   The SPKI types has been reserved, until RFC 2692/2693 is moved
-        from the experimental status.
-   10.  Added indirect types IPKIX, ISPKI, and IPGP.
-
-
-Appendix A.  Copying conditions
-
-   Regarding the portion of this document that was written by Simon
-   Josefsson ("the author", for the remainder of this section), the
-   author makes no guarantees and is not responsible for any damage
-   resulting from its use.  The author grants irrevocable permission to
-   anyone to use, modify, and distribute it in any way that does not
-   diminish the rights of anyone else to use, modify, and distribute it,
-   provided that redistributed derivative works do not contain
-   misleading author or version information.  Derivative works need not
-   be licensed under similar terms.
-
-
-10.  References
-
-10.1.  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., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-   [4]   Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri,
-
-
-
-Josefsson                 Expires March 3, 2006                [Page 12]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-         "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
-         January 1998.
-
-   [5]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
-         Resource Identifiers (URI): Generic Syntax", RFC 2396,
-         August 1998.
-
-   [6]   Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
-         "OpenPGP Message Format", RFC 2440, November 1998.
-
-   [7]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-         Considerations Section in RFCs", BCP 26, RFC 2434,
-         October 1998.
-
-   [8]   Resnick, P., "Internet Message Format", RFC 2822, April 2001.
-
-   [9]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "DNS Security Introduction and Requirements", RFC 4033,
-         March 2005.
-
-   [10]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Resource Records for the DNS Security Extensions", RFC 4034,
-         March 2005.
-
-10.2.  Informative References
-
-   [11]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-         RFC 2246, January 1999.
-
-   [12]  Kent, S. and R. Atkinson, "Security Architecture for the
-         Internet Protocol", RFC 2401, November 1998.
-
-   [13]  Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,
-         and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
-         September 1999.
-
-   [14]  Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
-         RFC 3548, July 2003.
-
-   [15]  Richardson, M., "A Method for Storing IPsec Keying Material in
-         DNS", RFC 4025, March 2005.
-
-   [16]  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
-         (S/MIME) Version 3.1 Message Specification", RFC 3851,
-         July 2004.
-
-
-
-
-
-
-Josefsson                 Expires March 3, 2006                [Page 13]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-Author's Address
-
-   Simon Josefsson
-
-   Email: simon@josefsson.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                 Expires March 3, 2006                [Page 14]
-
-Internet-Draft       Storing Certificates in the DNS         August 2005
-
-
-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 (2005).  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.
-
-
-
-
-Josefsson                 Expires March 3, 2006                [Page 15]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt
deleted file mode 100644
index 5e6cb1d..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt
+++ /dev/null
@@ -1,580 +0,0 @@
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-OBSOLETES: RFC 2539                               Donald E. Eastlake 3rd
-                                                   Motorola Laboratories
-Expires: January 2006                                          July 2005
-
-
-
-
-        Storage of Diffie-Hellman Keying Information in the DNS
-        ------- -- -------------- ------ ----------- -- --- ---
-               <draft-ietf-dnsext-rfc2539bis-dhk-06.txt>
-
-
-
-Status of This Document
-
-   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 becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   Distribution of this document is unlimited. Comments should be sent
-   to the DNS extensions 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
-
-   The standard method for encoding Diffie-Hellman keys in the Domain
-   Name System is specified.
-
-
-
-Copyright
-
-   Copyright (C) The Internet Society 2005.
-
-
-
-D. Eastlake 3rd                                                 [Page 1]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-Acknowledgements
-
-   Part of the format for Diffie-Hellman keys and the description
-   thereof was taken from a work in progress by Ashar Aziz, Tom Markson,
-   and Hemma Prafullchandra.  In addition, the following persons
-   provided useful comments that were incorporated into the predecessor
-   of this document: Ran Atkinson, Thomas Narten.
-
-
-
-Table of Contents
-
-      Status of This Document....................................1
-      Abstract...................................................1
-      Copyright..................................................1
-
-      Acknowledgements...........................................2
-      Table of Contents..........................................2
-
-      1. Introduction............................................3
-      1.1 About This Document....................................3
-      1.2 About Diffie-Hellman...................................3
-      2. Encoding Diffie-Hellman Keying Information..............4
-      3. Performance Considerations..............................5
-      4. IANA Considerations.....................................5
-      5. Security Considerations.................................5
-      Copyright and Disclaimer...................................5
-
-      Normative References.......................................7
-      Informative Refences.......................................7
-
-      Author Address.............................................8
-      Expiration and File Name...................................8
-
-      Appendix A: Well known prime/generator pairs...............9
-      A.1. Well-Known Group 1:  A 768 bit prime..................9
-      A.2. Well-Known Group 2:  A 1024 bit prime.................9
-      A.3. Well-Known Group 3:  A 1536 bit prime................10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 2]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-1. Introduction
-
-   The Domain Name System (DNS) is the global hierarchical replicated
-   distributed database system for Internet addressing, mail proxy, and
-   similar information [RFC 1034, 1035]. The DNS has been extended to
-   include digital signatures and cryptographic keys as described in
-   [RFC 4033, 4034, 4035] and additonal work is underway which would use
-   the storage of keying information in the DNS.
-
-
-
-1.1 About This Document
-
-   This document describes how to store Diffie-Hellman keys in the DNS.
-   Familiarity with the Diffie-Hellman key exchange algorithm is assumed
-   [Schneier, RFC 2631].
-
-
-
-1.2 About Diffie-Hellman
-
-   Diffie-Hellman requires two parties to interact to derive keying
-   information which can then be used for authentication.  Thus Diffie-
-   Hellman is inherently a key agreement algorithm. As a result, no
-   format is defined for Diffie-Hellman "signature information".  For
-   example, assume that two parties have local secrets "i" and "j".
-   Assume they each respectively calculate X and Y as follows:
-
-        X = g**i ( mod p )
-
-        Y = g**j ( mod p )
-
-   They exchange these quantities and then each calculates a Z as
-   follows:
-
-        Zi = Y**i ( mod p )
-
-        Zj = X**j ( mod p )
-
-   Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared
-   secret between the two parties that an adversary who does not know i
-   or j will not be able to learn from the exchanged messages (unless
-   the adversary can derive i or j by performing a discrete logarithm
-   mod p which is hard for strong p and g).
-
-   The private key for each party is their secret i (or j).  The public
-   key is the pair p and g, which must be the same for the parties, and
-   their individual X (or Y).
-
-   For further information about Diffie-Hellman and precautions to take
-
-
-D. Eastlake 3rd                                                 [Page 3]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-   in deciding on a p and g, see [RFC 2631].
-
-
-
-2. Encoding Diffie-Hellman Keying Information
-
-   When Diffie-Hellman keys appear within the RDATA portion of a RR,
-   they are encoded as shown below.
-
-   The period of key validity is not included in this data but is
-   indicated separately, for example by an RR such as RRSIG which signs
-   and authenticates the RR containing the keying information.
-
-                            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 flags           |    protocol   |  algorithm=2  |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |     prime length (or flag)    |  prime (p) (or special)       /
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       /  prime (p)  (variable length) |       generator length        |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       | generator (g) (variable length)                               |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |     public value length       | public value (variable length)/
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       /  public value (g^i mod p)    (variable length)                |
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   Prime length is the length of the Diffie-Hellman prime (p) in bytes
-   if it is 16 or greater.  Prime contains the binary representation of
-   the Diffie-Hellman prime with most significant byte first (i.e., in
-   network order). If "prime length" field is 1 or 2, then the "prime"
-   field is actually an unsigned index into a table of 65,536
-   prime/generator pairs and the generator length SHOULD be zero.  See
-   Appedix A for defined table entries and Section 4 for information on
-   allocating additional table entries.  The meaning of a zero or 3
-   through 15 value for "prime length" is reserved.
-
-   Generator length is the length of the generator (g) in bytes.
-   Generator is the binary representation of generator with most
-   significant byte first.  PublicValueLen is the Length of the Public
-   Value (g**i (mod p)) in bytes.  PublicValue is the binary
-   representation of the DH public value with most significant byte
-   first.
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 4]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-3. Performance Considerations
-
-   Current DNS implementations are optimized for small transfers,
-   typically less than 512 bytes including DNS overhead.  Larger
-   transfers will perform correctly and extensions have been
-   standardized [RFC 2671] to make larger transfers more efficient. But
-   it is still advisable at this time to make reasonable efforts to
-   minimize the size of RR sets containing keying information consistent
-   with adequate security.
-
-
-
-4. IANA Considerations
-
-   Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
-   an IETF consensus as defined in [RFC 2434].
-
-   Well known prime/generator pairs number 0x0000 through 0x07FF can
-   only be assigned by an IETF standards action. [RFC 2539], the
-   Proposed Standard predecessor of this document, assigned 0x0001
-   through 0x0002. This document additionally assigns 0x0003.  Pairs
-   number 0s0800 through 0xBFFF can be assigned based on RFC
-   documentation. Pairs number 0xC000 through 0xFFFF are available for
-   private use and are not centrally coordinated. Use of such private
-   pairs outside of a closed environment may result in conflicts and/or
-   security failures.
-
-
-
-5. Security Considerations
-
-   Keying information retrieved from the DNS should not be trusted
-   unless (1) it has been securely obtained from a secure resolver or
-   independently verified by the user and (2) this secure resolver and
-   secure obtainment or independent verification conform to security
-   policies acceptable to the user.  As with all cryptographic
-   algorithms, evaluating the necessary strength of the key is important
-   and dependent on security policy.
-
-   In addition, the usual Diffie-Hellman key strength considerations
-   apply. (p-1)/2 should also be prime, g should be primitive mod p, p
-   should be "large", etc. See [RFC 2631, Schneier].
-
-
-
-Copyright and Disclaimer
-
-   Copyright (C) The Internet Society (2005).  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.
-
-
-D. Eastlake 3rd                                                 [Page 5]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-   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                     Diffie-Hellman Information in the DNS
-
-
-Normative References
-
-   [RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June
-   1999.
-
-   [RFC 2434] - "Guidelines for Writing an IANA Considerations Section
-   in RFCs", T.  Narten, H. Alvestrand, October 1998.
-
-   [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
-   March 2005.
-
-
-
-Informative Refences
-
-   [RFC 1034] - "Domain names - concepts and facilities", P.
-   Mockapetris, November 1987.
-
-   [RFC 1035] - "Domain names - implementation and specification", P.
-   Mockapetris, November 1987.
-
-   [RFC 2539] - "Storage of Diffie-Hellman Keys in the Domain Name
-   System (DNS)", D. Eastlake, March 1999, obsoleted by this RFC.
-
-   [RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
-   1999.
-
-   [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "DNS Security Introduction and Requirements", RFC 4033, March
-   2005.
-
-   [RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
-   Rose, "Protocol Modifications for the DNS Security Extensions", RFC
-   4035, March 2005.
-
-   [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
-   Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley
-   and Sons.
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 7]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-Author Address
-
-   Donald E. Eastlake 3rd
-   Motorola Laboratories
-   155 Beaver Street
-   Milford, MA 01757 USA
-
-   Telephone:   +1-508-786-7554
-   EMail:       Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
-   This draft expires in January 2006.
-
-   Its file name is draft-ietf-dnsext-rfc2539bis-dhk-06.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 8]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-Appendix A: Well known prime/generator pairs
-
-   These numbers are copied from the IPSEC effort where the derivation of
-   these values is more fully explained and additional information is
-   available.
-   Richard Schroeppel performed all the mathematical and computational
-   work for this appendix.
-
-
-
-A.1. Well-Known Group 1:  A 768 bit prime
-
-   The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }.  Its
-   decimal value is
-          155251809230070893513091813125848175563133404943451431320235
-          119490296623994910210725866945387659164244291000768028886422
-          915080371891804634263272761303128298374438082089019628850917
-          0691316593175367469551763119843371637221007210577919
-
-   Prime modulus: Length (32 bit words): 24, Data (hex):
-            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
-            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
-            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
-            E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
-
-   Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-A.2. Well-Known Group 2:  A 1024 bit prime
-
-   The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
-   Its decimal value is
-         179769313486231590770839156793787453197860296048756011706444
-         423684197180216158519368947833795864925541502180565485980503
-         646440548199239100050792877003355816639229553136239076508735
-         759914822574862575007425302077447712589550957937778424442426
-         617334727629299387668709205606050270810842907692932019128194
-         467627007
-
-   Prime modulus:  Length (32 bit words): 32, Data (hex):
-            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
-            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
-            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
-            E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
-            EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
-            FFFFFFFF FFFFFFFF
-
-   Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-D. Eastlake 3rd                                                 [Page 9]
-
-
-INTERNET-DRAFT                     Diffie-Hellman Information in the DNS
-
-
-A.3. Well-Known Group 3:  A 1536 bit prime
-
-   The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] +  741804 }.
-   Its decimal value is
-            241031242692103258855207602219756607485695054850245994265411
-            694195810883168261222889009385826134161467322714147790401219
-            650364895705058263194273070680500922306273474534107340669624
-            601458936165977404102716924945320037872943417032584377865919
-            814376319377685986952408894019557734611984354530154704374720
-            774996976375008430892633929555996888245787241299381012913029
-            459299994792636526405928464720973038494721168143446471443848
-            8520940127459844288859336526896320919633919
-
-   Prime modulus Length (32 bit words): 48, Data (hex):
-              FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
-              29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
-              EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
-              E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
-              EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
-              C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
-              83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
-              670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
-
-   Generator: Length (32 bit words):  1, Data (hex): 2
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                [Page 10]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt
deleted file mode 100644
index 0af13c6..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt
+++ /dev/null
@@ -1,755 +0,0 @@
-
-
-Network Working Group                                          B. Laurie
-Internet-Draft                                                   Nominet
-Expires: March 2, 2005                                         R. Loomis
-                                                                    SAIC
-                                                          September 2004
-
-
-
-      Requirements related to DNSSEC Signed Proof of Non-Existence
-         draft-ietf-dnsext-signed-nonexistence-requirements-01
-
-
-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 March 2, 2005.
-
-
-Copyright Notice
-
-
-   Copyright (C) The Internet Society (2004).
-
-
-Abstract
-
-
-   DNSSEC-bis uses the NSEC record to provide authenticated denial of
-   existence of RRsets.  NSEC also has the side-effect of permitting
-   zone enumeration, even if zone transfers have been forbidden.
-   Because some see this as a problem, this document has been assembled
-   to detail the possible requirements for denial of existence A/K/A
-   signed proof of non-existence.
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                  [Page 1]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-Table of Contents
-
-
-   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
-   2.   Non-purposes . . . . . . . . . . . . . . . . . . . . . . . .   3
-   3.   Zone Enumeration . . . . . . . . . . . . . . . . . . . . . .   3
-   4.   Zone Enumeration II  . . . . . . . . . . . . . . . . . . . .   4
-   5.   Zone Enumeration III . . . . . . . . . . . . . . . . . . . .   4
-   6.   Exposure of Contents . . . . . . . . . . . . . . . . . . . .   4
-   7.   Zone Size  . . . . . . . . . . . . . . . . . . . . . . . . .   4
-   8.   Single Method  . . . . . . . . . . . . . . . . . . . . . . .   5
-   9.   Empty Non-terminals  . . . . . . . . . . . . . . . . . . . .   5
-   10.  Prevention of Precomputed Dictionary Attacks . . . . . . . .   6
-   11.  DNSSEC-Adoption and Zone-Growth Relationship . . . . . . . .   6
-   12.  Non-overlap of denial records with possible zone records . .   7
-   13.  Exposure of Private Keys . . . . . . . . . . . . . . . . . .   7
-   14.  Minimisation of Zone Signing Cost  . . . . . . . . . . . . .   8
-   15.  Minimisation of Asymmetry  . . . . . . . . . . . . . . . . .   8
-   16.  Minimisation of Client Complexity  . . . . . . . . . . . . .   8
-   17.  Completeness . . . . . . . . . . . . . . . . . . . . . . . .   8
-   18.  Purity of Namespace  . . . . . . . . . . . . . . . . . . . .   8
-   19.  Replay Attacks . . . . . . . . . . . . . . . . . . . . . . .   8
-   20.  Compatibility with NSEC  . . . . . . . . . . . . . . . . . .   8
-   21.  Compatibility with NSEC II . . . . . . . . . . . . . . . . .   9
-   22.  Compatibility with NSEC III  . . . . . . . . . . . . . . . .   9
-   23.  Coexistence with NSEC  . . . . . . . . . . . . . . . . . . .   9
-   24.  Coexistence with NSEC II . . . . . . . . . . . . . . . . . .   9
-   25.  Protocol Design  . . . . . . . . . . . . . . . . . . . . . .   9
-   26.  Process  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
-   27.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .   9
-   28.  Requirements notation  . . . . . . . . . . . . . . . . . . .   9
-   29.  Security Considerations  . . . . . . . . . . . . . . . . . .  10
-   30.  References . . . . . . . . . . . . . . . . . . . . . . . . .  10
-   30.1   Normative References . . . . . . . . . . . . . . . . . . .  10
-   30.2   Informative References . . . . . . . . . . . . . . . . . .  10
-        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  10
-        Intellectual Property and Copyright Statements . . . . . . .  11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                  [Page 2]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-1.  Introduction
-
-
-   NSEC records allow trivial enumeration of zones - a situation that
-   has existed for several years but which has recently been raised as a
-   significant concern for DNSSECbis deployment in several zones.
-   Alternate proposals have been made that make zone enumeration more
-   difficult, and some previous proposals to modify DNSSEC had related
-   requirements/desirements that are relevant to the discussion.  In
-   addition the original designs for NSEC/NXT records were based on
-   working group discussions and the choices made were not always
-   documented with context and requirements-- so some of those choices
-   may need to be restated as requirements.  Overall, the working group
-   needs to better understand the requirements for denial of existence
-   (and certain other requirements related to DNSSECbis deployment) in
-   order to evaluate the proposals that may replace NSEC.
-
-
-   In the remainder of this document, "NSEC++" is used as shorthand for
-   "a denial of existence proof that will replace NSEC".  "NSECbis" has
-   also been used as shorthand for this, but we avoid that usage since
-   NSECbis will not be part of DNSSECbis and therefore there might be
-   some confusion.
-
-
-2.  Non-purposes
-
-
-   This document does not currently document the reasons why zone
-   enumeration might be "bad" from a privacy, security, business, or
-   other perspective--except insofar as those reasons result in
-   requirements.  Once the list of requirements is complete and vaguely
-   coherent, the trade-offs (reducing zone enumeration will have X cost,
-   while providing Y benefit) may be revisited.  The editors of this
-   compendium received inputs on the potential reasons why zone
-   enumeration is bad (and there was significant discussion on the
-   DNSEXT WG mailing list) but that information fell outside the scope
-   of this document.
-
-
-   Note also that this document does not assume that NSEC *must* be
-   replaced with NSEC++, if the requirements can be met through other
-   methods (e.g., "white lies" with the current NSEC).  As is stated
-   above, this document is focused on requirements collection and
-   (ideally) prioritization rather than on the actual implementation.
-
-
-3.  Zone Enumeration
-
-
-   Authenticated denial should not permit trivial zone enumeration.
-
-
-   Additional discussion:  NSEC (and NXT before it) provide a linked
-   list that could be "walked" to trivially enumerate all the signed
-   records in a zone.  This requirement is primarily (though not
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                  [Page 3]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-   exclusively) important for zones that either are delegation-only/
-   -mostly or do not have reverse lookup (PTR) records configured, since
-   enterprises that have PTR records for all A records have already
-   provided a similar capability to enumerate the contents of DNS zones.
-
-
-   Contributor: various
-
-
-4.  Zone Enumeration II
-
-
-   Zone enumeration should be at least as difficult as it would be to
-   effect a dictionary attack using simple DNS queries to do the same in
-   an unsecured zone.
-
-
-   (Editor comment: it is not clear how to measure difficulty in this
-   case.  Some examples could be monetary cost, bandwidth, processing
-   power or some combination of these.  It has also been suggested that
-   the requirement is that the graph of difficulty of enumeration vs.
-   the fraction of the zone enumerated should be approximately the same
-   shape in the two cases)
-
-
-   Contributor: Nominet
-
-
-5.  Zone Enumeration III
-
-
-   Enumeration of a zone with random contents should computationally
-   infeasible.
-
-
-   Editor comment: this is proposed as a way of evaluating the
-   effectiveness of a proposal rather than as a requirement anyone would
-   actually have in practice.
-
-
-   Contributor: Alex Bligh
-
-
-6.  Exposure of Contents
-
-
-   NSEC++ should not expose any of the contents of the zone (apart from
-   the NSEC++ records themselves, of course).
-
-
-   Editor comment: this is a weaker requirement than prevention of
-   enumeration, but certainly any zone that satisfied this requirement
-   would also satisfy the trivial prevention of enumeration requirement.
-
-
-   Contributor: Ed Lewis
-
-
-7.  Zone Size
-
-
-   Requirement:  NSEC++ should make it possible to take precautions
-   against trivial zone size estimates.  Since not all zone owners care
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                  [Page 4]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-   about others estimation of the size of a zone, it is not always
-   necessary to prohibit trivial estimation of the size of the zone but
-   NSEC++ should allow such measures.
-
-
-   Additional Discussion: Even with proposals based on obfuscating names
-   with hashes it is trivial to give very good estimates of the number
-   of domains in a certain zone.  Just send 10 random queries and look
-   at the range between the two hash values returned in each NSEC++.  As
-   hash output can be assumed to follow a rectangular random
-   distribution, using the mean difference between the two values, you
-   can estimate the total number of records.  It is probably sufficient
-   to look at even one NSEC++, since the two hash values should follow a
-   (I believe) Poisson distribution.
-
-
-   The concern is motivated by some wording remembered from NSEC, which
-   stated that NSEC MUST only be present for existing owner names in the
-   zone, and MUST NOT be present for non-existing owner names.  If
-   similar wording were carried over to NSEC++, introducing bogus owner
-   names in the hash chain (an otherwise simple solution to guard
-   against trivial estimates of zone size) wouldn't be allowed.
-
-
-   One simple attempt at solving this is to describe in the
-   specifications how zone signer tools can add a number of random
-   "junk" records.
-
-
-   Editor's comment: it is interesting that obfuscating names might
-   actually make it easier to estimate zone size.
-
-
-   Contributor: Simon Josefsson.
-
-
-8.  Single Method
-
-
-   Requirement:  A single NSEC++ method must be able to carry both
-   old-style denial (i.e.  plain labels) and whatever the new style
-   looks like.  Having two separate denial methods could result in
-   cornercases where one method can deny the other and vice versa.
-
-
-   Additional discussion:  This requirement can help -bis folks to a
-   smooth upgrade to -ter.  First they'd change the method while the
-   content is the same, then they can change content of the method.
-
-
-   Contributor: Roy Arends.
-
-
-9.  Empty Non-terminals
-
-
-   Requirement:  Empty-non-terminals (ENT) should remain empty.  In
-   other words, adding NSEC++ records to an existing DNS structure
-   should not cause the creation of NSEC++ records (or related records)
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                  [Page 5]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-   at points that are otherwise ENT.
-
-
-   Additional discussion:  Currently NSEC complies with ENT requirement:
-   b.example.com NSEC a.c.example.com implies the existence of an ENT
-   with ownername c.example.com.  NSEC2 breaks that requirement, since
-   the ownername is entirely hashed causing the structure to disappear.
-   This is why EXIST was introduced.  But EXIST causes ENT to be
-   non-empty-terminals.  Next to the dissappearance of ENT, it causes
-   (some) overhead since an EXIST record needs a SIG, NSEC2 and
-   SIG(NSEC2).  DNSNR honours this requirement by hashing individual
-   labels instead of ownernames.  However this causes very long labels.
-   Truncation is a measure against very long ownernames, but that is
-   controversial.  There is a fair discussion of the validity of
-   truncation in the DNSNR draft, but that hasn't got proper review yet.
-
-
-   Contributor: Roy Arends.
-
-
-   (Editor comment: it is not clear to us that an EXIST record needs an
-   NSEC2 record, since it is a special purpose record only used for
-   denial of existence)
-
-
-10.  Prevention of Precomputed Dictionary Attacks
-
-
-   Requirement:  NSEC++ needs to provide a method to reduce the
-   effectiveness of precomputed dictionary attacks.
-
-
-   Additional Discussion:  Salt is a measure against dictionary attacks.
-   There are other possible measures (such as iterating hashes in
-   NSEC2).  The salt needs to be communicated in every response, since
-   it is needed in every verification.  Some have suggested to move the
-   salt to a special record instead of the denial record.  I think this
-   is not wise.  Response size has more priority over zone size.  An
-   extra record causes a larger response than a larger existing record.
-
-
-   Contributor: Roy Arends.
-
-
-   (Editor comment: the current version of NSEC2 also has the salt in
-   every NSEC2 record)
-
-
-11.  DNSSEC-Adoption and Zone-Growth Relationship
-
-
-   Background:  Currently with NSEC, when a delegation centric zone
-   deploys DNSSEC, the zone-size multiplies by a non-trivial factor even
-   when the DNSSEC-adoption rate of the subzones remains low--because
-   each delegation point creates at least one NSEC record and
-   corresponding signature in the parent even if the child is not
-   signed.
-
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                  [Page 6]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-   Requirements:  A delegation-only (or delegation-mostly) zone that is
-   signed but which has no signed child zones should initially need only
-   to add SIG(SOA), DNSKEY, and SIG(DNSKEY) at the apex, along with some
-   minimal set of NSEC++ records to cover zone contents.  Further,
-   during the transition of a delegation-only zone from 0% signed
-   children to 100% signed children, the growth in the delegation-only
-   zone should be roughly proportional to the percentage of signed child
-   zones.
-
-
-   Additional Discussion: This is why DNSNR has the Authoritative Only
-   bit.  This is similar to opt-in for delegations only.  This (bit) is
-   currently the only method to help delegation-centric zone cope with
-   zone-growth due to DNSSEC adoption.  As an example, A delegation only
-   zone which deploys DNSSEC with the help of this bit, needs to add
-   SIG(SOA), DNSKEY, SIG(DNSKEY), DNSNR, SIG(DNSNR) at the apex.  No
-   more than that.
-
-
-   Contributor: Roy Arends.
-
-
-12.  Non-overlap of denial records with possible zone records
-
-
-   Requirement:  NSEC++ records should in some way be differentiated
-   from regular zone records, so that there is no possibility that a
-   record in the zone could be duplicated by a non-existence proof
-   (NSEC++) record.
-
-
-   Additional discussion:  This requirement is derived from a discussion
-   on the DNSEXT mailing list related to copyrights and domain names.
-   As was outlined there, one solution is to put NSEC++ records in a
-   separate namespace, e.g.: $ORIGIN co.uk.
-   873bcdba87401b485022b8dcd4190e3e IN NS jim.rfc1035.com ; your
-   delegation 873bcdba87401b485022b8dcd4190e3e._no IN NSEC++ 881345...
-   ; for amazon.co.uk.
-
-
-   Contributor: various
-
-
-   (Editor comment:  One of us still does not see why a conflict
-   matters.  Even if there is an apparent conflict or overlap, the
-   "conflicting" NSEC2 name _only_ appears in NSEC2 records, and the
-   other name _never_ appears in NSEC2 records.)
-
-
-13.  Exposure of Private Keys
-
-
-   Private keys associated with the public keys in the DNS should be
-   exposed as little as possible.  It is highly undesirable for private
-   keys to be distributed to nameservers, or to otherwise be available
-   in the run-time environment of nameservers.
-
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                  [Page 7]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-   Contributors: Nominet, Olaf Kolkman, Ed Lewis
-
-
-14.  Minimisation of Zone Signing Cost
-
-
-   The additional cost of creating an NSEC++ signed zone should not
-   significantly exceed the cost of creating an ordinary signed zone.
-
-
-   Contributor: Nominet
-
-
-15.  Minimisation of Asymmetry
-
-
-   Nameservers should have to do as little additional work as necessary.
-   More precisely, it is desirable for any increase in cost incurred by
-   the nameservers to be offset by a proportionate increase in cost to
-   DNS `clients', e.g.  stub and/or `full-service' resolvers.
-
-
-   Contributor: Nominet
-
-
-16.  Minimisation of Client Complexity
-
-
-   Caching, wildcards, CNAMEs, DNAMEs should continue to work without
-   adding too much complexity at the client side.
-
-
-   Contributor: Olaf Kolkman
-
-
-17.  Completeness
-
-
-   A proof of nonexistence should be possible for all nonexistent data
-   in the zone.
-
-
-   Contributor: Olaf Kolkman
-
-
-18.  Purity of Namespace
-
-
-   The name space should not be muddied with fake names or data sets.
-
-
-   Contributor: Ed Lewis
-
-
-19.  Replay Attacks
-
-
-   NSEC++ should not allow a replay to be used to deny existence of an
-   RR that actually exists.
-
-
-   Contributor: Ed Lewis
-
-
-20.  Compatibility with NSEC
-
-
-   NSEC++ should not introduce changes incompatible with NSEC.
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                  [Page 8]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-   Contributor: Ed Lewis
-
-
-21.  Compatibility with NSEC II
-
-
-   NSEC++ should differ from NSEC in a way that is transparent to the
-   resolver or validator.
-
-
-   Contributor: Ed Lewis
-
-
-22.  Compatibility with NSEC III
-
-
-   NSEC++ should differ from NSEC as little as possible whilst achieving
-   other requirements.
-
-
-   Contributor: Alex Bligh
-
-
-23.  Coexistence with NSEC
-
-
-   NSEC++ should be optional, allowing NSEC to be used instead.
-
-
-   Contributor: Ed Lewis, Alex Bligh
-
-
-24.  Coexistence with NSEC II
-
-
-   NSEC++ should not impose extra work on those content with NSEC.
-
-
-   Contributor: Ed Lewis
-
-
-25.  Protocol Design
-
-
-   A good security protocol would allow signing the nonexistence of some
-   selected names without revealing anything about other names.
-
-
-   Contributor: Dan Bernstein
-
-
-26.  Process
-
-
-   Clearly not all of these requirements can be met.  Therefore the next
-   phase of this document will be to either prioritise them or narrow
-   them down to a non-contradictory set, which should then allow us to
-   judge proposals on the basis of their fit.
-
-
-27.  Acknowledgements
-
-
-28.  Requirements notation
-
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                  [Page 9]
-Internet-Draft      signed-nonexistence-requirements      September 2004
-
-
-
-   document are to be interpreted as            described in [RFC2119].
-
-
-29.  Security Considerations
-
-
-   There are currently no security considerations called out in this
-   draft.  There will be security considerations in the choice of which
-   requirements will be implemented, but there are no specific security
-   requirements during the requirements collection process.
-
-
-30.  References
-
-
-30.1  Normative References
-
-
-   [dnssecbis-protocol]
-              "DNSSECbis Protocol Definitions", BCP XX, RFC XXXX, Some
-              Month 2004.
-
-
-30.2  Informative References
-
-
-   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
-              3", BCP 9, RFC 2026, October 1996.
-
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-   [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
-              Procedures", BCP 25, RFC 2418, September 1998.
-
-
-
-Authors' Addresses
-
-
-   Ben Laurie
-   Nominet
-   17 Perryn Road
-   London  W3 7LR
-   England
-
-
-   Phone: +44 (20) 8735 0686
-   EMail: ben@algroup.co.uk
-
-
-
-   Rip Loomis
-   Science Applications International Corporation
-   7125 Columbia Gateway Drive, Suite 300
-   Columbia, MD  21046
-   US
-
-
-   EMail: gilbert.r.loomis@saic.com
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                 [Page 10]
-Internet-Draft      signed-nonexistence-requirements      September 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.
-
-
-
-
-
-Laurie & Loomis          Expires March 2, 2005                 [Page 11]
\ No newline at end of file
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt
deleted file mode 100644
index 9c73c68..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt
+++ /dev/null
@@ -1,1292 +0,0 @@
-
-
-
-
-
-DNS Extensions                                              Yuji Kamite
-Internet-Draft                                       NTT Communications
-Expires: April 15, 2005                                 Masaya Nakayama
-                                                The University of Tokyo
-                                                       October 14, 2004
-
-
-
-                      TKEY Secret Key Renewal Mode
-                 draft-ietf-dnsext-tkey-renewal-mode-05
-
-
-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 April 15, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).
-
-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
-
-
-
-Kamite, et. al.          Expires April 15, 2005                 [Page 1]
-
-INTERNET-DRAFT                                              October 2004
-
-
-   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.
-
-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.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
-  11.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
-    11.1   Normative References . . . . . . . . . . . . . . . . . . . 21
-    11.2   Informative References . . . . . . . . . . . . . . . . . . 21
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
-       Intellectual Property and Copyright Statements . . . . . . . . 23
-
-
-
-
-
-
-
-Kamite, et. al.          Expires April 15, 2005                 [Page 2]
-
-INTERNET-DRAFT                                              October 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.          Expires April 15, 2005                 [Page 3]
-
-INTERNET-DRAFT                                              October 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.          Expires April 15, 2005                 [Page 4]
-
-INTERNET-DRAFT                                              October 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.          Expires April 15, 2005                 [Page 5]
-
-INTERNET-DRAFT                                              October 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.          Expires April 15, 2005                 [Page 6]
-
-INTERNET-DRAFT                                              October 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.          Expires April 15, 2005                 [Page 7]
-
-INTERNET-DRAFT                                              October 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.          Expires April 15, 2005                 [Page 8]
-
-INTERNET-DRAFT                                              October 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.          Expires April 15, 2005                 [Page 9]
-
-INTERNET-DRAFT                                              October 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.          Expires April 15, 2005                [Page 10]
-
-INTERNET-DRAFT                                              October 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.          Expires April 15, 2005                [Page 11]
-
-INTERNET-DRAFT                                              October 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.          Expires April 15, 2005                [Page 12]
-
-INTERNET-DRAFT                                              October 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.          Expires April 15, 2005                [Page 13]
-
-INTERNET-DRAFT                                              October 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.          Expires April 15, 2005                [Page 14]
-
-INTERNET-DRAFT                                              October 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.          Expires April 15, 2005                [Page 15]
-
-INTERNET-DRAFT                                              October 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.          Expires April 15, 2005                [Page 16]
-
-INTERNET-DRAFT                                              October 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.          Expires April 15, 2005                [Page 17]
-
-INTERNET-DRAFT                                              October 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.          Expires April 15, 2005                [Page 18]
-
-INTERNET-DRAFT                                              October 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.          Expires April 15, 2005                [Page 19]
-
-INTERNET-DRAFT                                              October 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.          Expires April 15, 2005                [Page 20]
-
-INTERNET-DRAFT                                              October 2004
-
-
-10.  Acknowledgements
-
-   The authors would like to thank Olafur Gudmundsson, whose helpful
-   input and comments contributed greatly to this document.
-
-
-11.  References
-
-11.1.  Normative References
-
-[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.
-
-11.2.  Informative References
-
-[RFC2104]
-     H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message
-     Authentication", RFC2104, February 1997.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 21]
-
-INTERNET-DRAFT                                              October 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.          Expires April 15, 2005                [Page 22]
-
-INTERNET-DRAFT                                              October 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.
-
-
-
-
-Kamite, et. al.          Expires April 15, 2005                [Page 23]
-
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt
deleted file mode 100644
index a598826..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt
+++ /dev/null
@@ -1,1501 +0,0 @@
-Network Working Group                                           J. Ihren
-Internet-Draft                                             Autonomica AB
-Expires: April 18, 2005                                       O. Kolkman
-                                                                RIPE NCC
-                                                              B. Manning
-                                                                  EP.net
-                                                        October 18, 2004
-
-
-
-  An In-Band Rollover Mechanism and an Out-Of-Band Priming Method for
-                         DNSSEC Trust Anchors.
-               draft-ietf-dnsext-trustupdate-threshold-00
-
-
-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 April 18, 2005.
-
-
-Copyright Notice
-
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-
-Abstract
-
-
-   The DNS Security Extensions (DNSSEC) works by validating so called
-   chains of authority.  The start of these chains of authority are
-   usually public keys that are anchored in the DNS clients.  These keys
-   are known as the so called trust anchors.
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                 [Page 1]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   This memo describes a method how these client trust anchors can be
-   replaced using the DNS validation and querying mechanisms (in-band)
-   when the key pairs used for signing by zone owner are rolled.
-
-
-   This memo also describes a method to establish the validity of trust
-   anchors for initial configuration, or priming, using out of band
-   mechanisms.
-
-
-Table of Contents
-
-
-   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     1.1   Key Signing Keys, Zone Signing Keys and Secure Entry
-           Points . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Introduction and Background  . . . . . . . . . . . . . . . . .  5
-     2.1   Dangers of Stale Trust Anchors . . . . . . . . . . . . . .  5
-   3.  Threshold-based Trust Anchor Rollover  . . . . . . . . . . . .  7
-     3.1   The Rollover . . . . . . . . . . . . . . . . . . . . . . .  7
-     3.2   Threshold-based Trust Update . . . . . . . . . . . . . . .  8
-     3.3   Possible Trust Update States . . . . . . . . . . . . . . .  9
-     3.4   Implementation notes . . . . . . . . . . . . . . . . . . . 10
-     3.5   Possible transactions  . . . . . . . . . . . . . . . . . . 11
-       3.5.1   Single DNSKEY replaced . . . . . . . . . . . . . . . . 12
-       3.5.2   Addition of a new DNSKEY (no removal)  . . . . . . . . 12
-       3.5.3   Removal of old DNSKEY (no addition)  . . . . . . . . . 12
-       3.5.4   Multiple DNSKEYs replaced  . . . . . . . . . . . . . . 12
-     3.6   Removal of trust anchors for a trust point . . . . . . . . 12
-     3.7   No need for resolver-side overlap of old and new keys  . . 13
-   4.  Bootstrapping automatic rollovers  . . . . . . . . . . . . . . 14
-     4.1   Priming Keys . . . . . . . . . . . . . . . . . . . . . . . 14
-       4.1.1   Bootstrapping trust anchors using a priming key  . . . 14
-       4.1.2   Distribution of priming keys . . . . . . . . . . . . . 15
-   5.  The Threshold Rollover Mechanism vs Priming  . . . . . . . . . 16
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
-     6.1   Threshold-based Trust Update Security Considerations . . . 17
-     6.2   Priming Key Security Considerations  . . . . . . . . . . . 17
-   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
-   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 20
-   8.2   Informative References . . . . . . . . . . . . . . . . . . . 20
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
-   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
-   B.  Document History . . . . . . . . . . . . . . . . . . . . . . . 23
-     B.1   prior to version 00  . . . . . . . . . . . . . . . . . . . 23
-     B.2   version 00 . . . . . . . . . . . . . . . . . . . . . . . . 23
-       Intellectual Property and Copyright Statements . . . . . . . . 24
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                 [Page 2]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-1.  Terminology
-
-
-   The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
-   and "MAY" in this document are to be interpreted as described in
-   RFC2119 [1].
-
-
-   The term "zone" refers to the unit of administrative control in the
-   Domain Name System.  In this document "name server" denotes a DNS
-   name server that is authoritative (i.e.  knows all there is to know)
-   for a DNS zone.  A "zone owner" is the entity responsible for signing
-   and publishing a zone on a name server.  The terms "authentication
-   chain", "bogus", "trust anchors" and "Island of Security" are defined
-   in [4].  Throughout this document we use the term "resolver" to mean
-   "Validating Stub Resolvers" as defined in [4].
-
-
-   We use the term "security apex" as the zone for which a trust anchor
-   has been configured (by validating clients) and which is therefore,
-   by definition, at the root of an island of security.  The
-   configuration of trust anchors is a client side issue.  Therefore a
-   zone owner may not always know if their zone has become a security
-   apex.
-
-
-   A "stale anchor" is a trust anchor (a public key) that relates to a
-   key that is not used for signing.  Since trust anchors indicate that
-   a zone is supposed to be secure a validator will mark the all data in
-   an island of security as bogus when all trust anchors become stale.
-
-
-   It is assumed that the reader is familiar with public key
-   cryptography concepts [REF: Schneier Applied Cryptography] and is
-   able to distinguish between the private and public parts of a key
-   based on the context in which we use the term "key".  If there is a
-   possible ambiguity we will explicitly mention if a private or a
-   public part of a key is used.
-
-
-   The term "administrator" is used loosely throughout the text.  In
-   some cases an administrator is meant to be a person, in other cases
-   the administrator may be a process that has been delegated certain
-   responsibilities.
-
-
-1.1  Key Signing Keys, Zone Signing Keys and Secure Entry Points
-
-
-   Although the DNSSEC protocol does not make a distinction between
-   different keys the operational practice is that a distinction is made
-   between zone signing keys and key signing keys.  A key signing key is
-   used to exclusively sign the DNSKEY Resource Record (RR) set at the
-   apex of a zone and the zone signing keys sign all the data in the
-   zone (including the DNSKEY RRset at the apex).
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                 [Page 3]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   Keys that are intended to be used as the start of the authentication
-   chain for a particular zone, either because they are pointed to by a
-   parental DS RR or because they are configured as a trust anchor, are
-   called Secure Entry Point (SEP) keys.  In practice these SEP keys
-   will be key signing keys.
-
-
-   In order for the mechanism described herein to work the keys that are
-   intended to be used as secure entry points MUST have the SEP [2] flag
-   set.  In the examples it is assumed that keys with the SEP flag set
-   are used as key signing keys and thus exclusively sign the DNSKEY
-   RRset published at the apex of the zone.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                 [Page 4]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-2.  Introduction and Background
-
-
-   When DNSSEC signatures are validated the resolver constructs a chain
-   of authority from a pre-configured trust anchor to the DNSKEY
-   Resource Record (RR), which contains the public key that validates
-   the signature stored in an RRSIG RR.  DNSSEC is designed so that the
-   administrator of a resolver can validate data in multiple islands of
-   security by configuring multiple trust anchors.
-
-
-   It is expected that resolvers will have more than one trust anchor
-   configured.  Although there is no deployment experience it is not
-   unreasonable to expect resolvers to be configured with a number of
-   trust anchors that varies between order 1 and order 1000.  Because
-   zone owners are expected to roll their keys, trust anchors will have
-   to be maintained (in the resolver end) in order not to become stale.
-
-
-   Since there is no global key maintenance policy for zone owners and
-   there are no mechanisms in the DNS to signal the key maintenance
-   policy it may be very hard for resolvers administrators to keep their
-   set of trust anchors up to date.  For instance, if there is only one
-   trust anchor configured and the key maintenance policy is clearly
-   published, through some out of band trusted channel, then a resolver
-   administrator can probably keep track of key rollovers and update the
-   trust anchor manually.  However, with an increasing number of trust
-   anchors all rolled according to individual policies that are all
-   published through different channels this soon becomes an
-   unmanageable problem.
-
-
-2.1  Dangers of Stale Trust Anchors
-
-
-   Whenever a SEP key at a security apex is rolled there exists a danger
-   that "stale anchors" are created.  A stale anchor is a trust anchor
-   (i.e.  a public key configured in a validating resolver) that relates
-   to a private key that is no longer used for signing.
-
-
-   The problem with a stale anchors is that they will (from the
-   validating resolvers point of view) prove data to be false even
-   though it is actually correct.  This is because the data is either
-   signed by a new key or is no longer signed and the resolver expects
-   data to be signed by the old (now stale) key.
-
-
-   This situation is arguably worse than not having a trusted key
-   configured for the secure entry point, since with a stale key no
-   lookup is typically possible (presuming that the default
-   configuration of a validating recursive nameserver is to not give out
-   data that is signed but failed to verify.
-
-
-   The danger of making configured trust anchors become stale anchors
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                 [Page 5]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   may be a reason for zone owners not to roll their keys.  If a
-   resolver is configured with many trust anchors that need manual
-   maintenance it may be easy to not notice a key rollover at a security
-   apex, resulting in a stale anchor.
-
-
-   In Section 3 this memo sets out a lightweight, in-DNS, mechanism to
-   track key rollovers and modify the configured trust anchors
-   accordingly.  The mechanism is stateless and does not need protocol
-   extensions.  The proposed design is that this mechanism is
-   implemented as a "trust updating machine" that is run entirely
-   separate from the validating resolver except that the trust updater
-   will have influence over the trust anchors used by the latter.
-
-
-   In Section 4 we describe a method [Editors note: for now only the
-   frame work and a set of requirements] to install trust anchors.  This
-   method can be used at first configuration or when the trust anchors
-   became stale (typically due to a failure to track several rollover
-   events).
-
-
-   The choice for which domains trust anchors are to be configured is a
-   local policy issue.  So is the choice which trust anchors has
-   prevalence if there are multiple chains of trust to a given piece of
-   DNS data (e.g.  when a parent zone and its child both have trust
-   anchors configured).  Both issues are out of the scope of this
-   document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                 [Page 6]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-3.  Threshold-based Trust Anchor Rollover
-
-
-3.1  The Rollover
-
-
-   When a key pair is replaced all signatures (in DNSSEC these are the
-   RRSIG records) created with the old key will be replaced by new
-   signatures created by the new key.  Access to the new public key is
-   needed to verify these signatures.
-
-
-   Since zone signing keys are in "the middle" of a chain of authority
-   they can be verified using the signature made by a key signing key.
-   Rollover of zone signing keys is therefore transparent to validators
-   and requires no action in the validator end.
-
-
-   But if a key signing key is rolled a resolver can determine its
-   authenticity by either following the authorization chain from the
-   parents DS record, an out-of-DNS authentication mechanism or by
-   relying on other trust anchors known for the zone in which the key is
-   rolled.
-
-
-   The threshold trust anchor rollover mechanism (or trust update),
-   described below, is based on using existing trust anchors to verify a
-   subset of the available signatures.  This is then used as the basis
-   for a decision to accept the new keys as valid trust anchors.
-
-
-   Our example pseudo zone below contains a number of key signing keys
-   numbered 1 through Y and two zone signing keys A and B.  During a key
-   rollover key 2 is replaced by key Y+1.  The zone content changes
-   from:
-
-
-          example.com.  DNSKEY key1
-          example.com.  DNSKEY key2
-          example.com.  DNSKEY key3
-          ...
-          example.com.  DNSKEY keyY
-
-
-          example.com.  DNSKEY keyA
-          example.com.  DNSKEY keyB
-
-
-          example.com.  RRSIG DNSKEY ... (key1)
-          example.com.  RRSIG DNSKEY ... (key2)
-          example.com.  RRSIG DNSKEY ... (key3)
-          ...
-          example.com.  RRSIG DNSKEY ... (keyY)
-          example.com.  RRSIG DNSKEY ... (keyA)
-          example.com.  RRSIG DNSKEY ... (keyB)
-
-
-    to:
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                 [Page 7]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-          example.com.  DNSKEY key1
-          example.com.  DNSKEY key3
-          ...
-          example.com.  DNSKEY keyY
-          example.com.  DNSKEY keyY+1
-
-
-          example.com.  RRSIG DNSKEY ... (key1)
-          example.com.  RRSIG DNSKEY ... (key3)
-          ...
-          example.com.  RRSIG DNSKEY ... (keyY)
-          example.com.  RRSIG DNSKEY ... (keyY+1)
-          example.com.  RRSIG DNSKEY ... (keyA)
-          example.com.  RRSIG DNSKEY ... (keyB)
-
-
-   When the rollover becomes visible to the verifying stub resolver it
-   will be able to verify the RRSIGs associated with key1, key3 ...
-   keyY.  There will be no RRSIG by key2 and the RRSIG by keyY+1 will
-   not be used for validation, since that key is previously unknown and
-   therefore not trusted.
-
-
-   Note that this example is simplified.  Because of operational
-   considerations described in [5] having a period during which the two
-   key signing keys are both available is necessary.
-
-
-3.2  Threshold-based Trust Update
-
-
-   The threshold-based trust update algorithm applies as follows.  If
-   for a particular secure entry point
-   o  if the DNSKEY RRset in the zone has been replaced by a more recent
-      one (as determined by comparing the RRSIG inception dates)
-   and
-   o  if at least M configured trust anchors directly verify the related
-      RRSIGs over the new DNSKEY RRset
-   and
-   o  the number of configured trust anchors that verify the related
-      RRSIGs over the new DNSKEY RRset exceed a locally defined minimum
-      number that should be greater than one
-   then all the trust anchors for the particular secure entry point are
-   replaced by the set of keys from the zones DNSKEY RRset that have the
-   SEP flag set.
-
-
-   The choices for the rollover acceptance policy parameter M is left to
-   the administrator of the resolver.  To be certain that a rollover is
-   accepted up by resolvers using this mechanism zone owners should roll
-   as few SEP keys at a time as possible (preferably just one).  That
-   way they comply to the most strict rollover acceptance policy of
-   M=N-1.
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                 [Page 8]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   The value of M has an upper bound, limited by the number of of SEP
-   keys a zone owner publishes (i.e.  N).  But there is also a lower
-   bound, since it will not be safe to base the trust in too few
-   signatures.  The corner case is M=1 when any validating RRSIG will be
-   sufficient for a complete replacement of the trust anchors for that
-   secure entry point.  This is not a recommended configuration, since
-   that will allow an attacker to initiate rollover of the trust anchors
-   himself given access to just one compromised key.  Hence M should in
-   be strictly larger than 1 as shown by the third requirement above.
-
-
-   If the rollover acceptance policy is M=1 then the result for the
-   rollover in our example above should be that the local database of
-   trust anchors is updated by removing key "key2" from and adding key
-   "keyY+1" to the key store.
-
-
-3.3  Possible Trust Update States
-
-
-   We define five states for trust anchor configuration at the client
-   side.
-   PRIMING: There are no trust anchors configured.  There may be priming
-      keys available for initial priming of trust anchors.
-   IN-SYNC: The set of trust anchors configured exactly matches the set
-      of SEP keys used by the zone owner to sign the zone.
-   OUT-OF-SYNC: The set of trust anchors is not exactly the same as the
-      set of SEP keys used by the zone owner to sign the zone but there
-      are enough SEP key in use by the zone owner that is also in the
-      trust anchor configuration.
-   UNSYNCABLE: There is not enough overlap between the configured trust
-      anchors and the set of SEP keys used to sign the zone for the new
-      set to be accepted by the validator (i.e.  the number of
-      signatures that verify is not sufficient).
-   STALE: There is no overlap between the configured trust anchors and
-      the set of SEP keys used to sign the zone.  Here validation of
-      data is no longer possible and hence we are in a situation where
-      the trust anchors are stale.
-
-
-   Of these five states only two (IN-SYNC and OUT-OF-SYNC) are part of
-   the automatic trust update mechanism.  The PRIMING state is where a
-   validator is located before acquiring an up-to-date set of trust
-   anchors.  The transition from PRIMING to IN-SYNC is manual (see
-   Section 4 below).
-
-
-   Example: assume a secure entry point with four SEP keys and a
-   validator with the policy that it will accept any update to the set
-   of trust anchors as long as no more than two signatures fail to
-   validate (i.e.  M >= N-2) and at least two signature does validate
-   (i.e.  M >= 2).  In this case the rollover of a single key will move
-   the validator from IN-SYNC to OUT-OF-SYNC.  When the trust update
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                 [Page 9]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   state machine updates the trust anchors it returns to state IN-SYNC.
-
-
-   If if for some reason it fails to update the trust anchors then the
-   next rollover (of a different key) will move the validator from
-   OUT-OF-SYNC to OUT-OF-SYNC (again), since there are still two keys
-   that are configured as trust anchors and that is sufficient to accpt
-   an automatic update of the trust anchors.
-
-
-   The UNSYNCABLE state is where a validator is located if it for some
-   reason fails to incorporate enough updates to the trust anchors to be
-   able to accept new updates according to its local policy.  In this
-   example (i.e.  with the policy specified above) this will either be
-   because M < N-2 or M < 2, which does not suffice to authenticate a
-   successful update of trust anchors.
-
-
-   Continuing with the previous example where two of the four SEP keys
-   have already rolled, but the validator has failed to update the set
-   of trust anchors.  When the third key rolls over there will only be
-   one trust anchor left that can do successful validation.  This is not
-   sufficient to enable automatic update of the trust anchors, hence the
-   new state is UNSYNCABLE.  Note, however, that the remaining
-   up-to-date trust anchor is still enough to do successful validation
-   so the validator is still "working" from a DNSSEC point of view.
-
-
-   The STALE state, finally, is where a validator ends up when it has
-   zero remaining current trust anchors.  This is a dangerous state,
-   since the stale trust anchors will cause all validation to fail.  The
-   escape is to remove the stale trust anchors and thereby revert to the
-   PRIMING state.
-
-
-3.4  Implementation notes
-
-
-   The DNSSEC protocol specification ordains that a DNSKEY to which a DS
-   record points should be self-signed.  Since the keys that serve as
-   trust anchors and the keys that are pointed to by DS records serve
-   the same purpose, they are both secure entry points, we RECOMMEND
-   that zone owners who want to facilitate the automated rollover scheme
-   documented herein self-sign DNSKEYs with the SEP bit set and that
-   implementation check that DNSKEYs with the SEP bit set are
-   self-signed.
-
-
-   In order to maintain a uniform way of determining that a keyset in
-   the zone has been replaced by a more recent set the automatic trust
-   update machine SHOULD only accept new DNSKEY RRsets if the
-   accompanying RRSIGs show a more recent inception date than the
-   present set of trust anchors.  This is also needed as a safe guard
-   against possible replay attacks where old updates are replayed
-   "backwards" (i.e.  one change at a time, but going in the wrong
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 10]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   direction, thereby luring the validator into the UNSYNCABLE and
-   finally STALE states).
-
-
-   In order to be resilient against failures the implementation should
-   collect the DNSKEY RRsets from (other) authoritative servers if
-   verification of the self signatures fails.
-
-
-   The threshold-based trust update mechanism SHOULD only be applied to
-   algorithms, as represented in the algorithm field in the DNSKEY/RRSIG
-   [3], that the resolver is aware of.  In other words the SEP keys of
-   unknown algorithms should not be used when counting the number of
-   available signatures (the N constant) and the SEP keys of unknown
-   algorithm should not be entered as trust anchors.
-
-
-   When in state UNSYNCABLE or STALE manual intervention will be needed
-   to return to the IN-SYNC state.  These states should be flagged.  The
-   most appropriate action is human audit possibly followed by
-   re-priming (Section 4) the keyset (i.e.  manual transfer to the
-   PRIMING state through removal of the configured trust anchors).
-
-
-   An implementation should regularly probe the the authoritative
-   nameservers for new keys.  Since there is no mechanism to publish
-   rollover frequencies this document RECOMMENDS zone owners not to roll
-   their key signing keys more often than once per month and resolver
-   administrators to probe for key rollsovers (and apply the threshold
-   criterion for acceptance of trust update) not less often than once
-   per month.  If the rollover frequency is higher than the probing
-   frequency then trust anchors may become stale.  The exact relation
-   between the frequencies depends on the number of SEP keys rolled by
-   the zone owner and the value M configured by the resolver
-   administrator.
-
-
-   In all the cases below a transaction where the threshold criterion is
-   not satisfied should be considered bad (i.e.  possibly spoofed or
-   otherwise corrupted data).  The most appropriate action is human
-   audit.
-
-
-   There is one case where a "bad" state may be escaped from in an
-   automated fashion.  This is when entering the STALE state where all
-   DNSSEC validation starts to fail.  If this happens it is concievable
-   that it is better to completely discard the stale trust anchors
-   (thereby reverting to the PRIMING state where validation is not
-   possible).  A local policy that automates removal of stale trust
-   anchors is therefore suggested.
-
-
-3.5  Possible transactions
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 11]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-3.5.1  Single DNSKEY replaced
-
-
-   This is probably the most typical transaction on the zone owners
-   part.  The result should be that if the threshold criterion is
-   satisfied then the key store is updated by removal of the old trust
-   anchor and addition of the new key as a new trust anchor.  Note that
-   if the DNSKEY RRset contains exactly M keys replacement of keys is
-   not possible, i.e.  for automatic rollover to work M must be stricly
-   less than N.
-
-
-3.5.2  Addition of a new DNSKEY (no removal)
-
-
-   If the threshold criterion is satisfied then the new key is added as
-   a configured trust anchor.  Not more than N-M keys can be added at
-   once, since otherwise the algorithm will fail.
-
-
-3.5.3  Removal of old DNSKEY (no addition)
-
-
-   If the threshold criterion is satisfied then the old key is removed
-   from being a configured trust anchor.  Note that it is not possible
-   to reduce the size of the DNSKEY RRset to a size smaller than the
-   minimum required value for M.
-
-
-3.5.4  Multiple DNSKEYs replaced
-
-
-   Arguably it is not a good idea for the zone administrator to replace
-   several keys at the same time, but from the resolver point of view
-   this is exactly what will happen if the validating resolver for some
-   reason failed to notice a previous rollover event.
-
-
-   Not more than N-M keys can be replaced at one time or the threshold
-   criterion will not be satisfied.  Or, expressed another way: as long
-   as the number of changed keys is less than or equal to N-M the
-   validator is in state OUT-OF-SYNC.  When the number of changed keys
-   becomes greater than N-M the state changes to UNSYNCABLE and manual
-   action is needed.
-
-
-3.6  Removal of trust anchors for a trust point
-
-
-   If the parent of a secure entry point gets signed and it's trusted
-   keys get configured in the key store of the validating resolver then
-   the configured trust anchors for the child should be removed entirely
-   unless explicitly configured (in the utility configuration) to be an
-   exception.
-
-
-   The reason for such a configuration would be that the resolver has a
-   local policy that requires maintenance of trusted keys further down
-   the tree hierarchy than strictly needed from the point of view.
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 12]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   The default action when the parent zone changes from unsigned to
-   signed should be to remove the configured trust anchors for the
-   child.  This form of "garbage collect" will ensure that the automatic
-   rollover machinery scales as DNSSEC deployment progresses.
-
-
-3.7  No need for resolver-side overlap of old and new keys
-
-
-   It is worth pointing out that there is no need for the resolver to
-   keep state about old keys versus new keys, beyond the requirement of
-   tracking signature inception time for the covering RRSIGs as
-   described in Section 3.4.
-
-
-   From the resolver point of view there are only trusted and not
-   trusted keys.  The reason is that the zone owner needs to do proper
-   maintenance of RRSIGs regardless of the resolver rollover mechanism
-   and hence must ensure that no key rolled out out the DNSKEY set until
-   there cannot be any RRSIGs created by this key still legally cached.
-
-
-   Hence the rollover mechanism is entirely stateless with regard to the
-   keys involved: as soon as the resolver (or in this case the rollover
-   tracking utility) detects a change in the DNSKEY RRset (i.e.  it is
-   now in the state OUT-OF-SYNC) with a sufficient number of matching
-   RRSIGs the configured trust anchors are immediately updated (and
-   thereby the machine return to state IN-SYNC).  I.e.  the rollover
-   machine changes states (mostly oscillating between IN-SYNC and
-   OUT-OF-SYNC), but the status of the DNSSEC keys is stateless.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 13]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-4.  Bootstrapping automatic rollovers
-
-
-   It is expected that with the ability to automatically roll trust
-   anchors at trust points will follow a diminished unwillingness to
-   roll these keys, since the risks associated with stale keys are
-   minimized.
-
-
-   The problem of "priming" the trust anchors, or bringing them into
-   sync (which could happen if a resolver is off line for a long period
-   in which a set of SEP keys in a zone 'evolve' away from its trust
-   anchor configuration) remains.
-
-
-   For (re)priming we can rely on out of band technology and we propose
-   the following framework.
-
-
-4.1  Priming Keys
-
-
-   If all the trust anchors roll somewhat frequently (on the order of
-   months or at most about a year) then it will not be possible to
-   design a device, or a software distribution that includes trust
-   anchors, that after being manufactured is put on a shelf for several
-   key rollover periods before being brought into use (since no trust
-   anchors that were known at the time of manufacture remain active).
-
-
-   To alleviate this we propose the concept of "priming keys".  Priming
-   keys are ordinary DNSSEC Key Signing Keys with the characteristic
-   that
-   o  The private part of a priming key signs the DNSKEY RRset at the
-      security apex, i.e.  at least one RRSIG DNSKEY is created by a
-      priming key rather than by an "ordinary" trust anchor
-   o  the public parts of priming keys are not included in the DNSKEY
-      RRset.  Instead the public parts of priming keys are only
-      available out-of-band.
-   o  The public parts of the priming keys have a validity period.
-      Within this period they can be used to obtain trust anchors.
-   o  The priming key pairs are long lived (relative to the key rollover
-      period.)
-
-
-4.1.1  Bootstrapping trust anchors using a priming key
-
-
-   To install the trust anchors for a particular security apex an
-   administrator of a validating resolver will need to:
-   o  query for the DNSKEY RRset of the zone at the security apex;
-   o  verify the self signatures of all DNSKEYs in the RRset;
-   o  verify the signature of the RRSIG made with a priming key --
-      verification using one of the public priming keys that is valid at
-      that moment is sufficient;
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 14]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   o  create the trust anchors by extracting the DNSKEY RRs with the SEP
-      flag set.
-   The SEP keys with algorithms unknown to the validating resolver
-   SHOULD be ignored during the creation of the trust anchors.
-
-
-4.1.2  Distribution of priming keys
-
-
-   The public parts of the priming keys SHOULD be distributed
-   exclusively through out-of-DNS mechanisms.  The requirements for a
-   distribution mechanism are:
-   o  it can carry the "validity" period for the priming keys;
-   o  it can carry the self-signature of the priming keys;
-   o  and it allows for verification using trust relations outside the
-      DNS.
-   A distribution mechanism would benefit from:
-   o  the availability of revocation lists;
-   o  the ability of carrying zone owners policy information such as
-      recommended values for "M" and "N" and a rollover frequency;
-   o  and the technology on which is based is readily available.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 15]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-5.  The Threshold Rollover Mechanism vs Priming
-
-
-   There is overlap between the threshold-based trust updater and the
-   Priming method.  One could exclusively use the Priming method for
-   maintaining the trust anchors.  However the priming method probably
-   relies on "non-DNS' technology and may therefore not be available for
-   all devices that have a resolver.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 16]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-6.  Security Considerations
-
-
-6.1  Threshold-based Trust Update Security Considerations
-
-
-   A clear issue for resolvers will be how to ensure that they track all
-   rollover events for the zones they have configure trust anchors for.
-   Because of temporary outages validating resolvers may have missed a
-   rollover of a KSK.  The parameters that determine the robustness
-   against failures are: the length of the period between rollovers
-   during which the KSK set is stable and validating resolvers can
-   actually notice the change; the number of available KSKs (i.e.  N)
-   and the number of signatures that may fail to validate (i.e.  N-M).
-
-
-   With a large N (i.e.  many KSKs) and a small value of M this
-   operation becomes more robust since losing one key, for whatever
-   reason, will not be crucial.  Unfortunately the choice for the number
-   of KSKs is a local policy issue for the zone owner while the choice
-   for the parameter M is a local policy issue for the resolver
-   administrator.
-
-
-   Higher values of M increase the resilience against attacks somewhat;
-   more signatures need to verify for a rollover to be approved.  On the
-   other hand the number of rollover events that may pass unnoticed
-   before the resolver reaches the UNSYNCABLE state goes down.
-
-
-   The threshold-based trust update intentionally does not provide a
-   revocation mechanism.  In the case that a sufficient number of
-   private keys of a zone owner are simultaneously compromised the the
-   attacker may use these private keys to roll the trust anchors of (a
-   subset of) the resolvers.  This is obviously a bad situation but it
-   is not different from most other public keys systems.
-
-
-   However, it is important to point out that since any reasonable trust
-   anchor rollover policy (in validating resolvers) will require more
-   than one RRSIG to validate this proposal does provide security
-   concious zone administrators with the option of not storing the
-   individual private keys in the same location and thereby decreasing
-   the likelihood of simultaneous compromise.
-
-
-6.2  Priming Key Security Considerations
-
-
-   Since priming keys are not included in the DNSKEY RR set they are
-   less sensitive to packet size constraints and can be chosen
-   relatively large.  The private parts are only needed to sign the
-   DNSKEY RR set during the validity period of the particular priming
-   key pair.  Note that the private part of the priming key is used each
-   time when a DNSKEY RRset has to be resigned.  In practice there is
-   therefore little difference between the usage pattern of the private
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 17]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   part of key signing keys and priming keys.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 18]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-7.  IANA Considerations
-
-
-   NONE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 19]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-8.  References
-
-
-8.1  Normative References
-
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-
-   [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.
-
-
-   [3]  Arends, R., "Resource Records for the DNS Security Extensions",
-        draft-ietf-dnsext-dnssec-records-10 (work in progress),
-        September 2004.
-
-
-8.2  Informative References
-
-
-   [4]  Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose,
-        "DNS Security Introduction and Requirements",
-        draft-ietf-dnsext-dnssec-intro-12 (work in progress), September
-        2004.
-
-
-   [5]  Kolkman, O., "DNSSEC Operational Practices",
-        draft-ietf-dnsop-dnssec-operational-practices-01 (work in
-        progress), May 2004.
-
-
-   [6]  Housley, R., Ford, W., Polk, T. and D. Solo, "Internet X.509
-        Public Key Infrastructure Certificate and CRL Profile", RFC
-        2459, January 1999.
-
-
-
-Authors' Addresses
-
-
-   Johan Ihren
-   Autonomica AB
-   Bellmansgatan 30
-   Stockholm  SE-118 47
-   Sweden
-
-
-   EMail: johani@autonomica.se
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 20]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-   Olaf M. Kolkman
-   RIPE NCC
-   Singel 256
-   Amsterdam  1016 AB
-   NL
-
-
-   Phone: +31 20 535 4444
-   EMail: olaf@ripe.net
-   URI:   http://www.ripe.net/
-
-
-
-   Bill Manning
-   EP.net
-   Marina del Rey, CA  90295
-   USA
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 21]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-Appendix A.  Acknowledgments
-
-
-   The present design for in-band automatic rollovers of DNSSEC trust
-   anchors is the result of many conversations and it is no longer
-   possible to remember exactly who contributed what.
-
-
-   In addition we've also had appreciated help from (in no particular
-   order) Paul Vixie, Sam Weiler, Suzanne Woolf, Steve Crocker, Matt
-   Larson and Mark Kosters.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 22]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 2004
-
-
-
-Appendix B.  Document History
-
-
-   This appendix will be removed if and when the document is submitted
-   to the RFC editor.
-
-
-   The version you are reading is tagged as $Revision: 1.1.230.1 $.
-
-
-   Text between square brackets, other than references, are editorial
-   comments and will be removed.
-
-
-B.1  prior to version 00
-
-
-   This draft was initially published as a personal submission under the
-   name draft-kolkman-dnsext-dnssec-in-band-rollover-00.txt.
-
-
-   Kolkman documented the ideas provided by Ihren and Manning.  In the
-   process of documenting (and prototyping) Kolkman changed some of the
-   details of the M-N algorithms working.  Ihren did not have a chance
-   to review the draft before Kolkman posted;
-
-
-   Kolkman takes responsibilities for omissions, fuzzy definitions and
-   mistakes.
-
-
-B.2  version 00
-   o  The name of the draft was changed as a result of the draft being
-      adopted as a working group document.
-   o  A small section on the concept of stale trust anchors was added.
-   o  The different possible states are more clearly defined, including
-      examples of transitions between states.
-   o  The terminology is changed throughout the document.  The old term
-      "M-N" is replaced by "threshold" (more or less).  Also the
-      interpretation of the constants M and N is significantly
-      simplified to bring the usage more in line with "standard"
-      threshold terminlogy.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 23]
-Internet-Draft    DNSSEC Threshold-based Trust Update       October 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.
-
-
-
-
-Ihren, et al.            Expires April 18, 2005                [Page 24] 
\ No newline at end of file
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt
deleted file mode 100644
index 7cb9063..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt
+++ /dev/null
@@ -1,730 +0,0 @@
-
-
-
-
-Network Working Group                                         M. StJohns
-Internet-Draft                                             Nominum, Inc.
-Expires: July 14, 2006                                  January 10, 2006
-
-
-               Automated Updates of DNSSEC Trust Anchors
-                draft-ietf-dnsext-trustupdate-timers-02
-
-Status of this Memo
-
-   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 becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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 14, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes a means for automated, authenticated and
-   authorized updating of DNSSEC "trust anchors".  The method provides
-   protection against single key compromise of a key in the trust point
-   key set.  Based on the trust established by the presence of a current
-   anchor, other anchors may be added at the same place in the
-   hierarchy, and, ultimately, supplant the existing anchor.
-
-   This mechanism, if adopted, will require changes to resolver
-   management behavior (but not resolver resolution behavior), and the
-
-
-
-StJohns                   Expires July 14, 2006                 [Page 1]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-   addition of a single flag bit to the DNSKEY record.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     1.1.  Compliance Nomenclature  . . . . . . . . . . . . . . . . .  3
-     1.2.  Changes since -00  . . . . . . . . . . . . . . . . . . . .  3
-   2.  Theory of Operation  . . . . . . . . . . . . . . . . . . . . .  4
-     2.1.  Revocation . . . . . . . . . . . . . . . . . . . . . . . .  4
-     2.2.  Add Hold-Down  . . . . . . . . . . . . . . . . . . . . . .  5
-     2.3.  Remove Hold-down . . . . . . . . . . . . . . . . . . . . .  5
-     2.4.  Active Refresh . . . . . . . . . . . . . . . . . . . . . .  6
-     2.5.  Resolver Parameters  . . . . . . . . . . . . . . . . . . .  6
-       2.5.1.  Add Hold-Down Time . . . . . . . . . . . . . . . . . .  6
-       2.5.2.  Remove Hold-Down Time  . . . . . . . . . . . . . . . .  6
-       2.5.3.  Minimum Trust Anchors per Trust Point  . . . . . . . .  6
-   3.  Changes to DNSKEY RDATA Wire Format  . . . . . . . . . . . . .  6
-   4.  State Table  . . . . . . . . . . . . . . . . . . . . . . . . .  7
-     4.1.  Events . . . . . . . . . . . . . . . . . . . . . . . . . .  7
-     4.2.  States . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-     4.3.  Trust Point Deletion . . . . . . . . . . . . . . . . . . .  8
-   5.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-     5.1.  Adding A Trust Anchor  . . . . . . . . . . . . . . . . . .  9
-     5.2.  Deleting a Trust Anchor  . . . . . . . . . . . . . . . . .  9
-     5.3.  Key Roll-Over  . . . . . . . . . . . . . . . . . . . . . .  9
-     5.4.  Active Key Compromised . . . . . . . . . . . . . . . . . .  9
-     5.5.  Stand-by Key Compromised . . . . . . . . . . . . . . . . . 10
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
-     7.1.  Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10
-     7.2.  Multiple Key Compromise  . . . . . . . . . . . . . . . . . 10
-     7.3.  Dynamic Updates  . . . . . . . . . . . . . . . . . . . . . 11
-   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 11
-   Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
-   Intellectual Property and Copyright Statements . . . . . . . . . . 13
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns                   Expires July 14, 2006                 [Page 2]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-1.  Introduction
-
-   As part of the reality of fielding DNSSEC (Domain Name System
-   Security Extensions) [RFC2535] [RFC4033][RFC4034][RFC4035], the
-   community has come to the realization that there will not be one
-   signed name space, but rather islands of signed name space each
-   originating from specific points (i.e. 'trust points') in the DNS
-   tree.  Each of those islands will be identified by the trust point
-   name, and validated by at least one associated public key.  For the
-   purpose of this document we'll call the association of that name and
-   a particular key a 'trust anchor'.  A particular trust point can have
-   more than one key designated as a trust anchor.
-
-   For a DNSSEC-aware resolver to validate information in a DNSSEC
-   protected branch of the hierarchy, it must have knowledge of a trust
-   anchor applicable to that branch.  It may also have more than one
-   trust anchor for any given trust point.  Under current rules, a chain
-   of trust for DNSSEC-protected data that chains its way back to ANY
-   known trust anchor is considered 'secure'.
-
-   Because of the probable balkanization of the DNSSEC tree due to
-   signing voids at key locations, a resolver may need to know literally
-   thousands of trust anchors to perform its duties. (e.g.  Consider an
-   unsigned ".COM".)  Requiring the owner of the resolver to manually
-   manage this many relationships is problematic.  It's even more
-   problematic when considering the eventual requirement for key
-   replacement/update for a given trust anchor.  The mechanism described
-   herein won't help with the initial configuration of the trust anchors
-   in the resolvers, but should make trust point key replacement/
-   rollover more viable.
-
-   As mentioned above, this document describes a mechanism whereby a
-   resolver can update the trust anchors for a given trust point, mainly
-   without human intervention at the resolver.  There are some corner
-   cases discussed (e.g. multiple key compromise) that may require
-   manual intervention, but they should be few and far between.  This
-   document DOES NOT discuss the general problem of the initial
-   configuration of trust anchors for the resolver.
-
-1.1.  Compliance Nomenclature
-
-   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 BCP 14, [RFC2119].
-
-1.2.  Changes since -00
-
-   Added the concept of timer triggered resolver queries to refresh the
-
-
-
-StJohns                   Expires July 14, 2006                 [Page 3]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-   resolvers view of the trust anchor key RRSet.
-
-   Re-submitted expired draft as -01.  Updated DNSSEC RFC References.
-
-   Draft -02.  Added the IANA Considerations section.  Added text to
-   describe what happens if all trust anchors at a trust point are
-   deleted.
-
-
-2.  Theory of Operation
-
-   The general concept of this mechanism is that existing trust anchors
-   can be used to authenticate new trust anchors at the same point in
-   the DNS hierarchy.  When a new SEP key is added to a trust point
-   DNSKEY RRSet, and when that RRSet is validated by an existing trust
-   anchor, then the new key can be added to the set of trust anchors.
-
-   There are some issues with this approach which need to be mitigated.
-   For example, a compromise of one of the existing keys could allow an
-   attacker to add their own 'valid' data.  This implies a need for a
-   method to revoke an existing key regardless of whether or not that
-   key is compromised.  As another example assuming a single key
-   compromise, an attacker could add a new key and revoke all the other
-   old keys.
-
-2.1.  Revocation
-
-   Assume two trust anchor keys A and B. Assume that B has been
-   compromised.  Without a specific revocation bit, B could invalidate A
-   simply by sending out a signed trust point key set which didn't
-   contain A. To fix this, we add a mechanism which requires knowledge
-   of the private key of a DNSKEY to revoke that DNSKEY.
-
-   A key is considered revoked when the resolver sees the key in a self-
-   signed RRSet and the key has the REVOKE bit (see Section 6 below) set
-   to '1'.  Once the resolver sees the REVOKE bit, it MUST NOT use this
-   key as a trust anchor or for any other purposes except validating the
-   RRSIG over the DNSKEY RRSet specifically for the purpose of
-   validating the revocation.  Unlike the 'Add' operation below,
-   revocation is immediate and permanent upon receipt of a valid
-   revocation at the resolver.
-
-   N.B. A DNSKEY with the REVOKE bit set has a different fingerprint
-   than one without the bit set.  This affects the matching of a DNSKEY
-   to DS records in the parent, or the fingerprint stored at a resolver
-   used to configure a trust point. [msj3]
-
-   In the given example, the attacker could revoke B because it has
-
-
-
-StJohns                   Expires July 14, 2006                 [Page 4]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-   knowledge of B's private key, but could not revoke A.
-
-2.2.  Add Hold-Down
-
-   Assume two trust point keys A and B. Assume that B has been
-   compromised.  An attacker could generate and add a new trust anchor
-   key - C (by adding C to the DNSKEY RRSet and signing it with B), and
-   then invalidate the compromised key.  This would result in the both
-   the attacker and owner being able to sign data in the zone and have
-   it accepted as valid by resolvers.
-
-   To mitigate, but not completely solve, this problem, we add a hold-
-   down time to the addition of the trust anchor.  When the resolver
-   sees a new SEP key in a validated trust point DNSKEY RRSet, the
-   resolver starts an acceptance timer, and remembers all the keys that
-   validated the RRSet.  If the resolver ever sees the DNSKEY RRSet
-   without the new key but validly signed, it stops the acceptance
-   process and resets the acceptance timer.  If all of the keys which
-   were originally used to validate this key are revoked prior to the
-   timer expiring, the resolver stops the acceptance process and resets
-   the timer.
-
-   Once the timer expires, the new key will be added as a trust anchor
-   the next time the validated RRSet with the new key is seen at the
-   resolver.  The resolver MUST NOT treat the new key as a trust anchor
-   until the hold down time expires AND it has retrieved and validated a
-   DNSKEY RRSet after the hold down time which contains the new key.
-
-   N.B.: Once the resolver has accepted a key as a trust anchor, the key
-   MUST be considered a valid trust anchor by that resolver until
-   explictly revoked as described above.
-
-   In the given example, the zone owner can recover from a compromise by
-   revoking B and adding a new key D and signing the DNSKEY RRSet with
-   both A and B.
-
-   The reason this does not completely solve the problem has to do with
-   the distributed nature of DNS.  The resolver only knows what it sees.
-   A determined attacker who holds one compromised key could keep a
-   single resolver from realizing that key had been compromised by
-   intercepting 'real' data from the originating zone and substituting
-   their own (e.g. using the example, signed only by B).  This is no
-   worse than the current situation assuming a compromised key.
-
-2.3.  Remove Hold-down
-
-   A new key which has been seen by the resolver, but hasn't reached
-   it's add hold-down time, MAY be removed from the DNSKEY RRSet by the
-
-
-
-StJohns                   Expires July 14, 2006                 [Page 5]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-   zone owner.  If the resolver sees a validated DNSKEY RRSet without
-   this key, it waits for the remove hold-down time and then, if the key
-   hasn't reappeared, SHOULD discard any information about the key.
-
-2.4.  Active Refresh
-
-   A resolver which has been configured for automatic update of keys
-   from a particular trust point MUST query that trust point (e.g. do a
-   lookup for the DNSKEY RRSet and related RRSIG records) no less often
-   than the lesser of 15 days or half the original TTL for the DNSKEY
-   RRSet or half the RRSIG expiration interval.  The expiration interval
-   is the amount of time from when the RRSIG was last retrieved until
-   the expiration time in the RRSIG.
-
-   If the query fails, the resolver MUST repeat the query until
-   satisfied no more often than once an hour and no less often than the
-   lesser of 1 day or 10% of the original TTL or 10% of the original
-   expiration interval.
-
-2.5.  Resolver Parameters
-
-2.5.1.  Add Hold-Down Time
-
-   The add hold-down time is 30 days or the expiration time of the TTL
-   of the first trust point DNSKEY RRSet which contained the key,
-   whichever is greater.  This ensures that at least two validated
-   DNSKEY RRSets which contain the new key MUST be seen by the resolver
-   prior to the key's acceptance.
-
-2.5.2.  Remove Hold-Down Time
-
-   The remove hold-down time is 30 days.
-
-2.5.3.  Minimum Trust Anchors per Trust Point
-
-   A compliant resolver MUST be able to manage at least five SEP keys
-   per trust point.
-
-
-3.  Changes to DNSKEY RDATA Wire Format
-
-   Bit n [msj2] of the DNSKEY Flags field is designated as the 'REVOKE'
-   flag.  If this bit is set to '1', AND the resolver sees an
-   RRSIG(DNSKEY) signed by the associated key, then the resolver MUST
-   consider this key permanently invalid for all purposes except for
-   validing the revocation.
-
-
-
-
-
-StJohns                   Expires July 14, 2006                 [Page 6]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-4.  State Table
-
-   The most important thing to understand is the resolver's view of any
-   key at a trust point.  The following state table describes that view
-   at various points in the key's lifetime.  The table is a normative
-   part of this specification.  The initial state of the key is 'Start'.
-   The resolver's view of the state of the key changes as various events
-   occur.
-
-   [msj1] This is the state of a trust point key as seen from the
-   resolver.  The column on the left indicates the current state.  The
-   header at the top shows the next state.  The intersection of the two
-   shows the event that will cause the state to transition from the
-   current state to the next.
-
-                             NEXT STATE
-           --------------------------------------------------
-    FROM   |Start  |AddPend |Valid  |Missing|Revoked|Removed|
-   ----------------------------------------------------------
-   Start   |       |NewKey  |       |       |       |       |
-   ----------------------------------------------------------
-   AddPend |KeyRem |        |AddTime|       |       |
-   ----------------------------------------------------------
-   Valid   |       |        |       |KeyRem |Revbit |       |
-   ----------------------------------------------------------
-   Missing |       |        |KeyPres|       |Revbit |       |
-   ----------------------------------------------------------
-   Revoked |       |        |       |       |       |RemTime|
-   ----------------------------------------------------------
-   Removed |       |        |       |       |       |       |
-   ----------------------------------------------------------
-
-4.1.  Events
-   NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key.
-      That key will become a new trust anchor for the named trust point
-      after its been present in the RRSet for at least 'add time'.
-   KeyPres The key has returned to the valid DNSKEY RRSet.
-   KeyRem The resolver sees a valid DNSKEY RRSet that does not contain
-      this key.
-   AddTime The key has been in every valid DNSKEY RRSet seen for at
-      least the 'add time'.
-   RemTime A revoked key has been missing from the trust point DNSKEY
-      RRSet for sufficient time to be removed from the trust set.
-   RevBit The key has appeared in the trust anchor DNSKEY RRSet with its
-      "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet
-      signed by this key.
-
-
-
-
-
-StJohns                   Expires July 14, 2006                 [Page 7]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-4.2.  States
-   Start The key doesn't yet exist as a trust anchor at the resolver.
-      It may or may not exist at the zone server, but hasn't yet been
-      seen at the resolver.
-   AddPend The key has been seen at the resolver, has its 'SEP' bit set,
-      and has been included in a validated DNSKEY RRSet.  There is a
-      hold-down time for the key before it can be used as a trust
-      anchor.
-   Valid The key has been seen at the resolver and has been included in
-      all validated DNSKEY RRSets from the time it was first seen up
-      through the hold-down time.  It is now valid for verifying RRSets
-      that arrive after the hold down time.  Clarification: The DNSKEY
-      RRSet does not need to be continuously present at the resolver
-      (e.g. its TTL might expire).  If the RRSet is seen, and is
-      validated (i.e. verifies against an existing trust anchor), this
-      key MUST be in the RRSet otherwise a 'KeyRem' event is triggered.
-   Missing This is an abnormal state.  The key remains as a valid trust
-      point key, but was not seen at the resolver in the last validated
-      DNSKEY RRSet.  This is an abnormal state because the zone operator
-      should be using the REVOKE bit prior to removal.  [Discussion
-      item: Should a missing key be considered revoked after some period
-      of time?]
-   Revoked This is the state a key moves to once the resolver sees an
-      RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains
-      this key with its REVOKE bit set to '1'.  Once in this state, this
-      key MUST permanently be considered invalid as a trust anchor.
-   Removed After a fairly long hold-down time, information about this
-      key may be purged from the resolver.  A key in the removed state
-      MUST NOT be considered a valid trust anchor.
-
-4.3.  Trust Point Deletion
-
-   A trust point which has all of its trust anchors revoked is
-   considered deleted and is treated as if the trust point was never
-   configured.  If there are no superior trust points, data at and below
-   the deleted trust point are considered insecure.  If there there ARE
-   superior trust points, data at and below the deleted trust point are
-   evaluated with respect to the superior trust point.
-
-
-5.  Scenarios
-
-   The suggested model for operation is to have one active key and one
-   stand-by key at each trust point.  The active key will be used to
-   sign the DNSKEY RRSet.  The stand-by key will not normally sign this
-   RRSet, but the resolver will accept it as a trust anchor if/when it
-   sees the signature on the trust point DNSKEY RRSet.
-
-
-
-
-StJohns                   Expires July 14, 2006                 [Page 8]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-   Since the stand-by key is not in active signing use, the associated
-   private key may (and SHOULD) be provided with additional protections
-   not normally available to a key that must be used frequently.  E.g.
-   locked in a safe, split among many parties, etc.  Notionally, the
-   stand-by key should be less subject to compromise than an active key,
-   but that will be dependent on operational concerns not addressed
-   here.
-
-5.1.  Adding A Trust Anchor
-
-   Assume an existing trust anchor key 'A'.
-   1.  Generate a new key pair.
-   2.  Create a DNSKEY record from the key pair and set the SEP and Zone
-       Key bits.
-   3.  Add the DNSKEY to the RRSet.
-   4.  Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
-       'A'.
-   5.  Wait a while.
-
-5.2.  Deleting a Trust Anchor
-
-   Assume existing trust anchors 'A' and 'B' and that you want to revoke
-   and delete 'A'.
-   1.  Set the revolcation bit on key 'A'.
-   2.  Sign the DNSKEY RRSet with both 'A' and 'B'.
-   'A' is now revoked.  The operator SHOULD include the revoked 'A' in
-   the RRSet for at least the remove hold-down time, but then may remove
-   it from the DNSKEY RRSet.
-
-5.3.  Key Roll-Over
-
-   Assume existing keys A and B. 'A' is actively in use (i.e. has been
-   signing the DNSKEY RRSet.)  'B' was the stand-by key. (i.e. has been
-   in the DNSKEY RRSet and is a valid trust anchor, but wasn't being
-   used to sign the RRSet.)
-   1.  Generate a new key pair 'C'.
-   2.  Add 'C' to the DNSKEY RRSet.
-   3.  Set the revocation bit on key 'A'.
-   4.  Sign the RRSet with 'A' and 'B'.
-   'A' is now revoked, 'B' is now the active key, and 'C' will be the
-   stand-by key once the hold-down expires.  The operator SHOULD include
-   the revoked 'A' in the RRSet for at least the remove hold-down time,
-   but may then remove it from the DNSKEY RRSet.
-
-5.4.  Active Key Compromised
-
-   This is the same as the mechanism for Key Roll-Over (Section 5.3)
-   above assuming 'A' is the active key.
-
-
-
-StJohns                   Expires July 14, 2006                 [Page 9]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-5.5.  Stand-by Key Compromised
-
-   Using the same assumptions and naming conventions as Key Roll-Over
-   (Section 5.3) above:
-   1.  Generate a new key pair 'C'.
-   2.  Add 'C' to the DNSKEY RRSet.
-   3.  Set the revocation bit on key 'B'.
-   4.  Sign the RRSet with 'A' and 'B'.
-   'B' is now revoked, 'A' remains the active key, and 'C' will be the
-   stand-by key once the hold-down expires.  'B' SHOULD continue to be
-   included in the RRSet for the remove hold-down time.
-
-
-6.  IANA Considerations
-
-   The IANA will need to assign a bit in the DNSKEY flags field (see
-   section 4.3 of [RFC3755]) for the REVOKE bit.  There are no other
-   IANA actions required.
-
-
-7.  Security Considerations
-
-7.1.  Key Ownership vs Acceptance Policy
-
-   The reader should note that, while the zone owner is responsible
-   creating and distributing keys, it's wholly the decision of the
-   resolver owner as to whether to accept such keys for the
-   authentication of the zone information.  This implies the decision
-   update trust anchor keys based on trust for a current trust anchor
-   key is also the resolver owner's decision.
-
-   The resolver owner (and resolver implementers) MAY choose to permit
-   or prevent key status updates based on this mechanism for specific
-   trust points.  If they choose to prevent the automated updates, they
-   will need to establish a mechanism for manual or other out-of-band
-   updates outside the scope of this document.
-
-7.2.  Multiple Key Compromise
-
-   This scheme permits recovery as long as at least one valid trust
-   anchor key remains uncompromised.  E.g. if there are three keys, you
-   can recover if two of them are compromised.  The zone owner should
-   determine their own level of comfort with respect to the number of
-   active valid trust anchors in a zone and should be prepared to
-   implement recovery procedures once they detect a compromise.  A
-   manual or other out-of-band update of all resolvers will be required
-   if all trust anchor keys at a trust point are compromised.
-
-
-
-
-StJohns                   Expires July 14, 2006                [Page 10]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-7.3.  Dynamic Updates
-
-   Allowing a resolver to update its trust anchor set based in-band key
-   information is potentially less secure than a manual process.
-   However, given the nature of the DNS, the number of resolvers that
-   would require update if a trust anchor key were compromised, and the
-   lack of a standard management framework for DNS, this approach is no
-   worse than the existing situation.
-
-8.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
-              Signer (DS)", RFC 3755, May 2004.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements",
-              RFC 4033, March 2005.
-
-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Resource Records for the DNS Security Extensions",
-              RFC 4034, March 2005.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-Editorial Comments
-
-   [msj1]  msj: N.B. This table is preliminary and will be revised to
-           match implementation experience.  For example, should there
-           be a state for "Add hold-down expired, but haven't seen the
-           new RRSet"?
-
-   [msj2]  msj: To be assigned.
-
-   [msj3]  msj: For discussion: What's the implementation guidance for
-           resolvers currently with respect to the non-assigned flag
-           bits?  If they consider the flag bit when doing key matching
-           at the trust anchor, they won't be able to match.
-
-
-
-
-
-
-StJohns                   Expires July 14, 2006                [Page 11]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-Author's Address
-
-   Michael StJohns
-   Nominum, Inc.
-   2385 Bay Road
-   Redwood City, CA  94063
-   USA
-
-   Phone: +1-301-528-4729
-   Email: Mike.StJohns@nominum.com
-   URI:   www.nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-StJohns                   Expires July 14, 2006                [Page 12]
-
-Internet-Draft             trustanchor-update               January 2006
-
-
-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 (2006).  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.
-
-
-
-
-StJohns                   Expires July 14, 2006                [Page 13]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt
deleted file mode 100644
index 00476ae..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt
+++ /dev/null
@@ -1,522 +0,0 @@
-
-INTERNET-DRAFT                                    Donald E. Eastlake 3rd
-UPDATES RFC 2845                                   Motorola Laboratories
-Expires: July 2006                                          January 2006
-
-                  HMAC SHA TSIG Algorithm Identifiers
-                  ---- --- ---- --------- -----------
-                  <draft-ietf-dnsext-tsig-sha-06.txt>
-
-
-Status of This Document
-
-   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 becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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 as "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 Domain Name System TSIG resource record requires
-   specification of a cryptographic message authentication code.
-   Currently identifiers have been specified only for the HMAC MD5
-   (Message Digest) and GSS (Generic Security Service) TSIG algorithms.
-   This document standardizes identifiers and implementation
-   requirements for additional HMAC SHA (Secure Hash Algorithm) TSIG
-   algorithms and standardizes how to specify and handle the truncation
-   of HMAC values in TSIG.
-
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-
-
-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
-      3.1 Truncation Specification...............................5
-
-      4. TSIG Truncation Policy and Error Provisions.............6
-
-      5. IANA Considerations.....................................7
-      6. Security Considerations.................................7
-      7. Copyright and Disclaimer................................7
-
-      8. Normative References....................................8
-      9. Informative References..................................8
-
-      Author's Address...........................................9
-      Additional IPR Provisions..................................9
-      Expiration and File Name...................................9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-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 (Domain Name System [STD 13]) 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 the Generic Security
-   Service (GSS) [RFC 3645].
-
-   It should be noted that use of TSIG presumes prior agreement, between
-   the resolver and server involved, as to the algorithm and key to be
-   used.
-
-   In Section 2, this document specifies additional names for TSIG
-   authentication algorithms based on US NIST SHA (United States,
-   National Institute of Science and Technology, Secure Hash Algorithm)
-   algorithms and HMAC and specifies the implementation requirements for
-   those algorithms.
-
-   In Section 3, this document specifies the effect 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.
-
-   In Section 4, policy restrictions and implications related to
-   truncation and a new error code to indicate truncation shorter than
-   permitted by policy are described and specified.
-
-   The use herein of MUST, SHOULD, MAY, MUST NOT, and SHOULD NOT is as
-   defined in [RFC 2119].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-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-2, 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 3874, SHA2draft] with 224, 256, 384,
-   and 512 bits, may be preferred in some cases particularly since
-   increasingly successful cryptanalytic attacks are being made on the
-   shorter hashes.
-
-   Use of TSIG between a DNS resolver and server is by mutual agreement.
-   That agreement can include the support of additional algorithms and
-   criteria as to which algorithms and truncations are acceptable,
-   subject to the restriction and guidelines in Section 3 and 4 below.
-   Key agreement can be by the TKEY mechanism [RFC 2930] or other
-   mutually agreeable method.
-
-   The current HMAC-MD5.SIG-ALG.REG.INT and gss-tsig identifiers are
-   included in the table below for convenience.  Implementations which
-   support TSIG MUST also implement HMAC SHA1 and HMAC SHA256 and MAY
-   implement gss-tsig and the other algorithms listed below.
-
-         Mandatory      HMAC-MD5.SIG-ALG.REG.INT
-         Optional       gss-tsig
-         Mandatory      hmac-sha1
-         Optional       hmac-sha224
-         Mandatory      hmac-sha256
-         Optional       hamc-sha384
-         Optional       hmac-sha512
-
-   SHA-1 truncated to 96 bits (12 octets) SHOULD be implemented.
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 4]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-3. Specifying Truncation
-
-   When space is at a premium and the strength of the full length of an
-   HMAC is not needed, it is reasonable to truncate the HMAC output and
-   use the truncated value for authentication. HMAC SHA-1 truncated to
-   96 bits is an option 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. Truncation is indicated by a MAC size
-   less than the HMAC size as specified below.
-
-
-
-3.1 Truncation Specification
-
-   The specification for TSIG handling is changed as follows:
-
-   1. If "MAC size" field is greater than HMAC output length:
-         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 "MAC size" field equals HMAC output length:
-         Operation is as described in [RFC 2845] with the entire output
-      HMAC output present.
-
-   3. "MAC size" field is less than HMAC output length but greater than
-      that specified in case 4 below:
-         This is sent when the signer has truncated the HMAC output to
-      an allowable length, 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. The request MAC used when calculating the TSIG MAC
-      for a reply is the truncated request MAC.
-
-   4. "MAC size" field is less than the larger of 10 (octets) and half
-      the length of the hash function in use:
-         With the exception of certain TSIG error messages described in
-      RFC 2845 section 3.2 where it is permitted that the MAC size be
-      zero, this case MUST NOT be generated and if received MUST cause
-      the packet to be dropped and RCODE 1 (FORMERR) to be returned. The
-      size limit for this case can also, for the hash functions
-      mentioned in this document, be stated as less than half the hash
-      function length for hash functions other than MD5 and less than 10
-      octets for MD5.
-
-
-
-D. Eastlake 3rd                                                 [Page 5]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-4. TSIG Truncation Policy and Error Provisions
-
-   Use of TSIG is by mutual agreement between a resolver and server.
-   Implicit in such "agreement" are criterion as to acceptable keys and
-   algorithms and, with the extensions in this document, truncations.
-   Note that it is common for implementations to bind the TSIG secret
-   key or keys that may be in place at a resolver and server to
-   particular algorithms. Thus such implementations only permit the use
-   of an algorithm if there is an associated key in place. Receipt of an
-   unknown, unimplemented, or disabled algorithm typically results in a
-   BADKEY error.
-
-      Local policies MAY require the rejection of TSIGs even though they
-   use an algorithm for which implementation is mandatory.
-
-      When a local policy permits acceptance of a TSIG with a particular
-   algorithm and a particular non-zero amount of truncation it SHOULD
-   also permit the use of that algorithm with lesser truncation (a
-   longer MAC) up to the full HMAC output.
-
-      Regardless of a lower acceptable truncated MAC length specified by
-   local policy, a reply SHOULD be sent with a MAC at least as long as
-   that in the corresponding request unless the request specified a MAC
-   length longer than the HMAC output.
-
-      Implementations permitting multiple acceptable algorithms and/or
-   truncations SHOULD permit this list to be ordered by presumed
-   strength and SHOULD allow different truncations for the same
-   algorithm to be treated as separate entities in this list. When so
-   implemented, policies SHOULD accept a presumed stronger algorithm and
-   truncation than the minimum strength required by the policy.
-
-      If a TSIG is received with truncation which is permitted under
-   Section 3 above but the MAC is too short for the local policy in
-   force, an RCODE of TBA [22 suggested](BADTRUNC) MUST be returned.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 6]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-5. IANA Considerations
-
-   This document, on approval for publication as a standards track RFC,
-   (1) registers the new TSIG algorithm identifiers listed in Section 2
-   with IANA and (2) allocates the BADTRUNC RCODE TBA [22 suggested] in
-   Section 4. [RFC 2845]
-
-
-
-6. Security Considerations
-
-   For all of the message authentication code algorithms listed herein,
-   those producing longer values are believed to be stronger; however,
-   while there have been 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 break the
-   authentication by brute force [RFC 2104].
-
-   Significant progress has been made recently in cryptanalysis of hash
-   function of the type used herein, all of which ultimately derive from
-   the design of MD4. While the results so far should not effect HMAC,
-   the stronger SHA-1 and SHA-256 algorithms are being made mandatory
-   due to caution.
-
-   See the Security Considerations section of [RFC 2845].  See also the
-   Security Considerations section of [RFC 2104] from which the limits
-   on truncation in this RFC were taken.
-
-
-
-7. Copyright and Disclaimer
-
-   Copyright (C) The Internet Society (2006).
-
-   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 7]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-8. Normative References
-
-   [FIPS 180-2] - "Secure Hash Standard", (SHA-1/224/256/384/512) US
-   Federal Information Processing Standard, with Change Notice 1,
-   February 2004.
-
-   [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 2119] - Bradner, S., "Key words for use in RFCs to Indicate
-   Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
-   Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
-   RFC 2845, May 2000.
-
-   [RFC 3174] - Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
-   1 (SHA1)", RFC 3174, September 2001.
-
-   [RFC 3874] - R. Housely, "A 224-bit One-way Hash Function: SHA-224",
-   September 2004,
-
-   [SHA2draft] - Eastlake, D., T. Hansen, "US Secure Hash Algorithms
-   (SHA)", draft-eastlake-sha2-*.txt, work in progress.
-
-   [STD 13]
-         Mockapetris, P., "Domain names - concepts and facilities", STD
-         13, RFC 1034, November 1987.
-
-         Mockapetris, P., "Domain names - implementation and
-         specification", STD 13, RFC 1035, November 1987.
-
-
-
-9. Informative References.
-
-   [RFC 2930] - Eastlake 3rd, D., "Secret Key Establishment for DNS
-   (TKEY RR)", RFC 2930, September 2000.
-
-   [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction
-   Signatures ( SIG(0)s )", RFC 2931, September 2000.
-
-   [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 8]
-
-
-INTERNET-DRAFT                                 HMAC-SHA TSIG Identifiers
-
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   Motorola Laboratories
-   155 Beaver Street
-   Milford, MA 01757 USA
-
-   Telephone:   +1-508-786-7554 (w)
-
-   EMail:       Donald.Eastlake@motorola.com
-
-
-
-Additional IPR Provisions
-
-   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.
-
-
-
-Expiration and File Name
-
-   This draft expires in July 2006.
-
-   Its file name is draft-ietf-dnsext-tsig-sha-06.txt
-
-
-
-
-
-
-
-
-D. Eastlake 3rd                                                 [Page 9]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt
deleted file mode 100644
index 9cf88a5..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt
+++ /dev/null
@@ -1,1063 +0,0 @@
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-DNSEXT Working Group                                          E. Lewis
-INTERNET DRAFT                                                 NeuStar
-Expiration Date: July 9, 2006                          January 9, 2006
-Updates RFC 1034, RFC 2672
-
-                              The Role of Wildcards
-                            in the Domain Name System
-                      draft-ietf-dnsext-wcard-clarify-10.txt
-
-Status of this Memo
-
-      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
-      becomes aware will be disclosed, in accordance with Section 6 of
-      BCP 79.
-
-      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 9, 2006.
-
-Copyright Notice
-
-      Copyright (C) The Internet Society (2006).
-
-Abstract
-
-      This is an update to the wildcard definition of RFC 1034.  The
-      interaction with wildcards and CNAME is changed, an error
-      condition removed, and the words defining some concepts central
-      to wildcards are changed.  The overall goal is not to change
-      wildcards, but to refine the definition of RFC 1034.
-
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page  1]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-Table of Contents
-
-1.    Introduction   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  3
-1 1   Motivation                                                     3
-1 2   The Original Definition                                        3
-1 3   Roadmap to This Document                                       4
-1 3 1 New Terms                                                      4
-1.3.2 Changed Text                                                   5
-1.3.3 Considerations with Special Types                              5
-1.4   Standards Terminology                                          5
-2.    Wildcard Syntax   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  6
-2.1   Identifying a Wildcard                                         6
-2.1.1 Wild Card Domain Name and Asterisk Label                       6
-2.1.2 Asterisks and Other Characters                                 6
-2.1.3 Non-terminal Wild Card Domain Names                            6
-2.2   Existence Rules                                                7
-2.2.1 An Example                                                     7
-2.2.2 Empty Non-terminals                                            9
-2.2.3 Yet Another Definition of Existence                           10
-2.3   When is a Wild Card Domain Name Not Special                   10
-3.    Impact of a Wild Card Domain Name On a Response .  .  .  .  . 10
-3.1   Step 2                                                        10
-3.2   Step 3                                                        11
-3.3   Part 'c'                                                      11
-3.3.1 Closest Encloser and the Source of Synthesis                  12
-3.3.2 Closest Encloser and Source of Synthesis Examples             12
-3.3.3 Type Matching                                                 13
-4.    Considerations with Special Types   .  .  .  .  .  .  .  .  . 13
-4.1   SOA RRSet at a Wild Card Domain Name                          13
-4.2   NS RRSet at a Wild Card Domain Name                           14
-4.2.1 Discarded Notions                                             14
-4.3   CNAME RRSet at a Wild Card Domain Name                        15
-4.4   DNAME RRSet at a Wild Card Domain Name                        15
-4.5   SRV RRSet at a Wild Card Domain Name                          16
-4.6   DS RRSet at a Wild Card Domain Name                           16
-4.7   NSEC RRSet at a Wild Card Domain Name                         17
-4.8   RRSIG at a Wild Card Domain Name                              17
-4.9   Empty Non-terminal Wild Card Domain Name                      17
-5.    Security Considerations .  .  .  .  .  .  .  .  .  .  .  .  . 17
-6.    IANA Considerations     .  .  .  .  .  .  .  .  .  .  .  .  . 17
-7.    References              .  .  .  .  .  .  .  .  .  .  .  .  . 17
-8.    Editor                  .  .  .  .  .  .  .  .  .  .  .  .  . 18
-9.    Others Contributing to the Document    .  .  .  .  .  .  .  . 18
-10.   Trailing Boilerplate    .  .  .  .  .  .  .  .  .  .  .  .  . 19
-
-
-
-
-
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page  2]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-1. Introduction
-
-      In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the
-      synthesis of answers from special resource records called
-      wildcards.  The definition in RFC 1034 is incomplete and has
-      proven to be confusing.  This document describes the wildcard
-      synthesis by adding to the discussion and making limited
-      modifications.  Modifications are made to close inconsistencies
-      that have led to interoperability issues.  This description
-      does not expand the service intended by the original definition.
-
-      Staying within the spirit and style of the original documents,
-      this document avoids specifying rules for DNS implementations
-      regarding wildcards.  The intention is to only describe what is
-      needed for interoperability, not restrict implementation choices.
-      In addition, consideration is given to minimize any backwards
-      compatibility issues with implementations that comply with RFC
-      1034's definition.
-
-      This document is focused on the concept of wildcards as defined
-      in RFC 1034.  Nothing is implied regarding alternative means of
-      synthesizing resource record sets, nor are alternatives discussed.
-
-1.1 Motivation
-
-      Many DNS implementations diverge, in different ways, from the
-      original definition of wildcards.  Although there is clearly a
-      need to clarify the original documents in light of this alone,
-      the impetus for this document lay in the engineering of the DNS
-      security extensions [RFC4033].  With an unclear definition of
-      wildcards the design of authenticated denial became entangled.
-
-      This document is intended to limit its changes, documenting only
-      those based on implementation experience, and to remain as close
-      to the original document as possible.  To reinforce that this
-      document is meant to clarify and adjust and not redefine wildcards,
-      relevant sections of RFC 1034 are repeated verbatim to facilitate
-      comparison of the old and new text.
-
-1.2 The Original Definition
-
-      The definition of the wildcard concept is comprised by the
-      documentation of the algorithm by which a name server prepares
-      a response (in RFC 1034's section 4.3.2) and the way in which
-      a resource record (set) is identified as being a source of
-      synthetic data (section 4.3.3).
-
-      This is the definition of the term "wildcard" as it appears in
-      RFC 1034, section 4.3.3.
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page  3]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-# In the previous algorithm, special treatment was given to RRs with
-# owner names starting with the label "*".  Such RRs are called
-# wildcards. Wildcard RRs can be thought of as instructions for
-# synthesizing RRs.  When the appropriate conditions are met, the name
-# server creates RRs with an owner name equal to the query name and
-# contents taken from the wildcard RRs.
-
-      This passage follows the algorithm in which the term wildcard
-      is first used.   In this definition, wildcard refers to resource
-      records.  In other usage, wildcard has referred to domain names,
-      and it has been used to describe the operational practice of
-      relying on wildcards to generate answers.  It is clear from this
-      that there is a need to define clear and unambiguous terminology
-      in the process of discussing wildcards.
-
-      The mention of the use of wildcards in the preparation of a
-      response is contained in step 3c of RFC 1034's section 4.3.2
-      entitled "Algorithm."  Note that "wildcard" does not appear in
-      the algorithm, instead references are made to the "*" label.
-      The portion of the algorithm relating to wildcards is
-      deconstructed in detail in section 3 of this document, this is
-      the beginning of the relevant portion of the "Algorithm."
-
-#    c. If at some label, a match is impossible (i.e., the
-#       corresponding label does not exist), look to see if [...]
-#       the "*" label exists.
-
-      The scope of this document is the RFC 1034 definition of
-      wildcards and the implications of updates to those documents,
-      such as DNSSEC.  Alternate schemes for synthesizing answers are
-      not considered.  (Note that there is no reference listed.  No
-      document is known to describe any alternate schemes, although
-      there has been some mention of them in mailing lists.)
-
-1.3 Roadmap to This Document
-
-      This document accomplishes these three items.
-      o Defines new terms
-      o Makes minor changes to avoid conflicting concepts
-      o Describes the actions of certain resource records as wildcards
-
-1.3.1 New Terms
-
-      To help in discussing what resource records are wildcards, two
-      terms will be defined - "asterisk label" and "wild card domain
-      name".  These are defined in section 2.1.1.
-
-      To assist in clarifying the role of wildcards in the name server
-      algorithm in RFC 1034, 4.3.2, "source of synthesis" and "closest
-      encloser" are defined.  These definitions are in section 3.3.2.
-      "Label match" is defined in section 3.2.
-
-DNSEXT Working Group        Expires July 9, 2006             [Page  4]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-      The new terms are used to make discussions of wildcards clearer.
-      Terminology doesn't directly have an impact on implementations.
-
-1.3.2 Changed Text
-
-      The definition of "existence" is changed superficially.  This
-      change will not be apparent to implementations; it is needed to
-      make descriptions more precise.  The change appears in section
-      2.2.3.
-
-      RFC 1034, section 4.3.3., seems to prohibit having two asterisk
-      labels in a wildcard owner name.  With this document the
-      restriction is removed entirely.  This change and its implications
-      are in section 2.1.3.
-
-      The actions when a source of synthesis owns a CNAME RR are
-      changed to mirror the actions if an exact match name owns a
-      CNAME RR.  This is an addition to the words in RFC 1034,
-      section 4.3.2, step 3, part c.  The discussion of this is in
-      section 3.3.3.
-
-      Only the latter change represents an impact to implementations.
-      The definition of existence is not a protocol impact.  The change
-      to the restriction on names is unlikely to have an impact, as
-      RFC 1034 contained no specification on when and how to enforce the
-      restriction.
-
-1.3.3 Considerations with Special Types
-
-      This document describes semantics of wildcard RRSets for
-      "interesting" types as well as empty non-terminal wildcards.
-      Understanding these situations in the context of wildcards has
-      been clouded because these types incur special processing if
-      they are the result of an exact match.  This discussion is in
-      section 4.
-
-      These discussions do not have an implementation impact, they cover
-      existing knowledge of the types, but to a greater level of detail.
-
-1.4 Standards Terminology
-
-      This document does not use terms as defined in "Key words for use
-      in RFCs to Indicate Requirement Levels." [RFC2119]
-
-      Quotations of RFC 1034 are denoted by a '#' in the leftmost
-      column.  References to section "4.3.2" are assumed to refer
-      to RFC 1034's section 4.3.2, simply titled "Algorithm."
-
-
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page  5]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-2. Wildcard Syntax
-
-      The syntax of a wildcard is the same as any other DNS resource
-      record, across all classes and types.  The only significant
-      feature is the owner name.
-
-      Because wildcards are encoded as resource records with special
-      names, they are included in zone transfers and incremental zone
-      transfers[RFC1995] just as non-wildcard resource records are.
-      This feature has been under appreciated until discussions on
-      alternative approaches to wildcards appeared on mailing lists.
-
-2.1 Identifying a Wildcard
-
-      To provide a more accurate description of wildcards, the
-      definition has to start with a discussion of the domain names
-      that appear as owners.  Two new terms are needed, "Asterisk
-      Label" and "Wild Card Domain Name."
-
-2.1.1 Wild Card Domain Name and Asterisk Label
-
-      A "wild card domain name" is defined by having its initial
-      (i.e., left-most or least significant) label be, in binary format:
-
-           0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)
-
-      The first octet is the normal label type and length for a 1 octet
-      long label, the second octet is the ASCII representation [RFC20]
-      for the '*' character.
-
-      A descriptive name of a label equaling that value is an "asterisk
-      label."
-
-      RFC 1034's definition of wildcard would be "a resource record
-      owned by a wild card domain name."
-
-2.1.2 Asterisks and Other Characters
-
-      No label values other than that in section 2.1.1 are asterisk
-      labels, hence names beginning with other labels are never wild
-      card domain names.  Labels such as 'the*' and '**' are not
-      asterisk labels so these labels do not start wild card domain
-      names.
-
-2.1.3 Non-terminal Wild Card Domain Names
-
-      In section 4.3.3, the following is stated:
-
-# ..........................  The owner name of the wildcard RRs is of
-# the form "*.<anydomain>", where <anydomain> is any domain name.
-# <anydomain> should not contain other * labels......................
-
-DNSEXT Working Group        Expires July 9, 2006             [Page  6]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-      The restriction is now removed.  The original documentation of it
-      is incomplete and the restriction does not serve any purpose
-      given years of operational experience.
-
-      There are three possible reasons for putting the restriction in
-      place, but none of the three has held up over time.  One is
-      that the restriction meant that there would never be subdomains
-      of wild card domain names, but the restriciton as stated still
-      permits "example.*.example." for instance.  Another is that
-      wild card domain names are not intended to be empty non-terminals,
-      but this situation does not disrupt the algorithm in 4.3.2.
-      Finally, "nested" wild card domain names are not ambiguous once
-      the concept of the closest encloser had been documented.
-
-      A wild card domain name can have subdomains.  There is no need
-      to inspect the subdomains to see if there is another asterisk
-      label in any subdomain.
-
-      A wild card domain name can be an empty non-terminal.  (See the
-      upcoming sections on empty non-terminals.)  In this case, any
-      lookup encountering it will terminate as would any empty
-      non-terminal match.
-
-2.2 Existence Rules
-
-      The notion that a domain name 'exists' is mentioned in the
-      definition of wildcards.  In section 4.3.3 of RFC 1034:
-
-# Wildcard RRs do not apply:
-#
-...
-#   - When the query name or a name between the wildcard domain and
-#     the query name is know[n] to exist.  For example, if a wildcard
-
-      "Existence" is therefore an important concept in the understanding
-      of wildcards.  Unfortunately, the definition of what exists, in RFC
-      1034, is unclear.  So, in sections 2.2.2. and 2.2.3, another look is
-      taken at the definition of existence.
-
-2.2.1 An Example
-
-      To illustrate what is meant by existence consider this complete
-      zone:
-
-
-
-
-
-
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page  7]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-        $ORIGIN example.
-        example.                 3600 IN  SOA   <SOA RDATA>
-        example.                 3600     NS    ns.example.com.
-        example.                 3600     NS    ns.example.net.
-        *.example.               3600     TXT   "this is a wild card"
-        *.example.               3600     MX    10 host1.example.
-        sub.*.example.           3600     TXT   "this is not a wild card"
-        host1.example.           3600     A     192.0.4.1
-        _ssh._tcp.host1.example. 3600     SRV  <SRV RDATA>
-        _ssh._tcp.host2.example. 3600     SRV  <SRV RDATA>
-        subdel.example.          3600     NS   ns.example.com.
-        subdel.example.          3600     NS   ns.example.net.
-
-      A look at the domain names in a tree structure is helpful:
-
-                                    |
-                    -------------example------------
-                   /           /         \          \
-                  /           /           \          \
-                 /           /             \          \
-                *          host1          host2      subdel
-                |            |             |
-                |            |             |
-               sub         _tcp          _tcp
-                             |             |
-                             |             |
-                           _ssh          _ssh
-
-      The following responses would be synthesized from one of the
-      wildcards in the zone:
-
-          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 '*.example.'
-
-          QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN
-               the answer will be "foo.bar.example. IN TXT ..."
-               because bar.example. does not exist, but the wildcard
-               does.
-
-      The following responses would not be synthesized from any of the
-      wildcards in the zone:
-
-          QNAME=host1.example., QTYPE=MX, QCLASS=IN
-               because host1.example. exists
-
-          QNAME=sub.*.example., QTYPE=MX, QCLASS=IN
-               because sub.*.example. exists
-
-DNSEXT Working Group        Expires July 9, 2006             [Page  8]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-          QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
-               because _tcp.host1.example. exists (without data)
-
-          QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
-               because subdel.example. exists (and is a zone cut)
-
-          QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN
-               because *.example. exists
-
-      The final example highlights one common misconception about
-      wildcards.  A wildcard "blocks itself" in the sense that a
-      wildcard does not match its own subdomains.  I.e. "*.example."
-      does not match all names in the "example." zone, it fails to
-      match the names below "*.example." To cover names under
-      "*.example.", another wild card domain name is needed -
-      "*.*.example." - which covers all but it's own subdomains.
-
-2.2.2 Empty Non-terminals
-
-      Empty non-terminals [RFC2136, Section 7.16] are domain names
-      that own no resource records but have subdomains that do.  In
-      section 2.2.1, "_tcp.host1.example." is an example of a empty
-      non-terminal name.  Empty non-terminals are introduced by this
-      text 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.
-
-      The parenthesized "which may be empty" specifies that empty non-
-      terminals are explicitly recognized, and that empty non-terminals
-      "exist."
-
-      Pedantically 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 [RFC1035].
-      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, so this apparently
-      is not the intent of the original definition, justifying the
-      need for an updated definition in the next section.
-
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page  9]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-2.2.3 Yet Another Definition of Existence
-
-      RFC1034's wording is fixed by the following paragraph:
-
-      The domain name space is a tree structure.  Nodes in the tree
-      either own at least one RRSet and/or have descendants that
-      collectively own at least one RRSet.  A node may exist with no
-      RRSets only if it has descendents that do, this node is an empty
-      non-terminal.
-
-      A node with no descendants is a leaf node.  Empty leaf nodes do
-      not exist.
-
-      Note that at a zone boundary, the domain name owns data,
-      including the NS RR set.  In the delegating zone, the NS RR
-      set is not authoritative, but that is of no consequence here.
-      The domain name owns data, therefore, it exists.
-
-2.3 When is a Wild Card Domain Name Not Special
-
-      When a wild card domain name appears in a message's query section,
-      no special processing occurs.  An asterisk label in a query name
-      only matches a single, corresponding asterisk label in the
-      existing zone tree when the 4.3.2 algorithm is being followed.
-
-      When a wild card domain name appears in the resource data of a
-      record, no special processing occurs.  An asterisk label in that
-      context literally means just an asterisk.
-
-3. Impact of a Wild Card Domain Name On a Response
-
-      RFC 1034's description of how wildcards impact response
-      generation is in its 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 wildcard.
-
-      The algorithm in section 4.3.2. is not intended to be pseudo-code,
-      i.e., its steps are not intended to be followed in strict order.
-      The "algorithm" is a suggested means of implementing the
-      requirements.  As such, in step 3, parts a, b, and c, do not have
-      to be implemented in that order, provided that the result of the
-      implemented code is compliant with the protocol's specification.
-
-3.1 Step 2
-
-      Step 2 of section 4.3.2 reads:
-
-#   2. Search the available zones for the zone which is the nearest
-#      ancestor to QNAME.  If such a zone is found, go to step 3,
-#      otherwise step 4.
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 10]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-      In this step, the most appropriate zone for the response is
-      chosen.  The significance of this step is that it means all of
-      step 3 is being performed within one zone.  This has significance
-      when considering whether or not an SOA RR can be ever be used for
-      synthesis.
-
-3.2 Step 3
-
-      Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'.
-      But the beginning of the step is important and needs explanation.
-
-#   3. Start matching down, label by label, in the zone.  The
-#      matching process can terminate several ways:
-
-      The word 'matching' refers to label matching.  The concept
-      is based in the view of the zone as the tree of existing names.
-      The query name is considered to be an ordered sequence of
-      labels - as if the name were a path from the root to the owner
-      of the desired data.  (Which it is - 3rd paragraph of RFC 1034,
-      section 3.1.)
-
-      The process of label matching a query name ends in exactly one of
-      three choices, the parts 'a', 'b', and 'c'.  Either the name is
-      found, the name is below a cut point, or the name is not found.
-
-      Once one of the parts is chosen, the other parts are not
-      considered.  (E.g., do not execute part 'c' and then change
-      the execution path to finish in part 'b'.)  The process of label
-      matching is also done independent of the query type (QTYPE).
-
-      Parts 'a' and 'b' are not an issue for this clarification as they
-      do not relate to record synthesis.  Part 'a' is an exact match
-      that results in an answer, part 'b' is a referral.
-
-3.3 Part 'c'
-
-      The context of part 'c' is that the process of label matching the
-      labels of the query name has resulted in a situation in which
-      there is no corresponding label in the tree.  It is as if the
-      lookup has "fallen off the tree."
-
-#     c. If at some label, a match is impossible (i.e., the
-#        corresponding label does not exist), look to see if [...]
-#        the "*" label exists.
-
-      To help describe the process of looking 'to see if [...] the "*"
-      label exists' a term has been coined to describe the last domain
-      (node) matched.  The term is "closest encloser."
-
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 11]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-3.3.1 Closest Encloser and the Source of Synthesis
-
-      The closest encloser is the node in the zone's tree of existing
-      domain names that has the most labels matching the query name
-      (consecutively, counting from the root label downward). Each match
-      is a "label match" and the order of the labels is the same.
-
-      The closest encloser is, by definition, an existing name in the
-      zone.  The closest encloser might be an empty non-terminal or even
-      be a wild card domain name itself.  In no circumstances is the
-      closest encloser to be used to synthesize records for the current
-      query.
-
-      The source of synthesis is defined in the context of a query
-      process as that wild card domain name immediately descending
-      from the closest encloser, provided that this wild card domain
-      name exists.  "Immediately descending" means that the source
-      of synthesis has a name of the form:
-            <asterisk label>.<closest encloser>.
-      A source of synthesis does not guarantee having a RRSet to use
-      for synthesis.  The source of synthesis could be an empty
-      non-terminal.
-
-      If the source of synthesis does not exist (not on the domain
-      tree), there will be no wildcard synthesis.  There is no search
-      for an alternate.
-
-      The important concept is that for any given lookup process, there
-      is at most one place at which wildcard synthetic records can be
-      obtained.  If the source of synthesis does not exist, the lookup
-      terminates, the lookup does not look for other wildcard records.
-
-3.3.2 Closest Encloser and Source of Synthesis Examples
-
-      To illustrate, using the example zone in section 2.2.1 of this
-      document, the following chart shows QNAMEs and the closest
-      enclosers.
-
-      QNAME                       Closest Encloser    Source of Synthesis
-      host3.example.              example.            *.example.
-      _telnet._tcp.host1.example. _tcp.host1.example. no source
-      _telnet._tcp.host2.example. host2.example.      no source
-      _telnet._tcp.host3.example. example.            *.example.
-      _chat._udp.host3.example.   example.            *.example.
-      foobar.*.example.           *.example.          no source
-
-
-
-
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 12]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-3.3.3 Type Matching
-
-       RFC 1034 concludes part 'c' with this:
-
-#            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.
-#
-#            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.
-
-      The final paragraph covers the role of the QTYPE in the lookup
-      process.
-
-      Based on implementation feedback and similarities between step
-      'a' and step 'c' a change to this passage has been made.
-
-      The change is to add the following text to step 'c' prior to the
-      instructions to "go to step 6":
-
-               If the data at the source of synthesis is a CNAME, and
-               QTYPE doesn't match CNAME, copy the CNAME RR into the
-               answer section of the response changing the owner name
-               to the QNAME, change QNAME to the canonical name in the
-               CNAME RR, and go back to step 1.
-
-      This is essentially the same text in step a covering the
-      processing of CNAME RRSets.
-
-4. Considerations with Special Types
-
-      Sections 2 and 3 of this document discuss wildcard synthesis
-      with respect to names in the domain tree and ignore the impact
-      of types.  In this section, the implication of wildcards of
-      specific types are discussed.  The types covered are those
-      that have proven to be the most difficult to understand.  The
-      types are SOA, NS, CNAME, DNAME, SRV, DS, NSEC, RRSIG and
-      "none," i.e., empty non-terminal wild card domain names.
-
-4.1 SOA RRSet at a Wild Card Domain Name
-
-      A wild card domain name owning an SOA RRSet means that the
-      domain is at the root of the zone (apex).  The domain can not
-      be a source of synthesis because that is, by definition, a
-      descendent node (of the closest encloser) and a zone apex is
-      at the top of the zone.
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 13]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-      Although a wild card domain name owning an SOA RRSet can never
-      be a source of synthesis, there is no reason to forbid the
-      ownership of an SOA RRSet.
-
-      E.g., given this zone:
-             $ORIGIN *.example.
-             @                 3600 IN  SOA   <SOA RDATA>
-                               3600     NS    ns1.example.com.
-                               3600     NS    ns1.example.net.
-             www               3600     TXT   "the www txt record"
-
-      A query for www.*.example.'s TXT record would still find the
-      "the www txt record" answer.  The asterisk label only becomes
-      significant when section 4.3.2, step 3 part 'c' is in effect.
-
-      Of course, there would need to be a delegation in the parent
-      zone, "example." for this to work too.  This is covered in the
-      next section.
-
-4.2 NS RRSet at a Wild Card Domain Name
-
-      With the definition of DNSSEC [RFC4033, RFC4034, RFC4035] now
-      in place, the semantics of a wild card domain name owning an
-      NS RRSet has come to be poorly defined.  The dilemma relates to
-      a conflict between the rules for synthesis in part 'c' and the
-      fact that the resulting synthesis generates a record for which
-      the zone is not authoritative.  In a DNSSEC signed zone, the
-      mechanics of signature management (generation and inclusion
-      in a message) have become unclear.
-
-      Salient points of the working group discussion on this topic is
-      summarized in section 4.2.1.
-
-      As a result of these discussion, there is no definition given for
-      wild card domain names owning an NS RRSet.  The semantics are
-      left undefined until there is a clear need to have a set defined,
-      and until there is a clear direction to proceed.  Operationally,
-      inclusion of wild card NS RRSets in a zone is discouraged, but
-      not barred.
-
-4.2.1 Discarded Notions
-
-      Prior to DNSSEC, a wild card domain name owning a NS RRSet
-      appeared to be workable, and there are some instances in which
-      it is found in deployments using implementations that support
-      this.  Continuing to allow this in the specification is not
-      tenable with DNSSEC.  The reason is that the synthesis of the
-      NS RRSet is being done in a zone that has delegated away the
-      responsibility for the name.  This "unauthorized" synthesis is
-      not a problem for the base DNS protocol, but DNSSEC, in affirming
-      the authorization model for DNS exposes the problem.
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 14]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-      Outright banning of wildcards of type NS is also untenable as
-      the DNS protocol does not define how to handle "illegal" data.
-      Implementations may choose not to load a zone, but there is no
-      protocol definition.  The lack of the definition is complicated
-      by having to cover dynamic update [RFC 2136], zone transfers,
-      as well as loading at the master server.  The case of a client
-      (resolver, caching server) getting a wildcard of type NS in
-      a reply would also have to be considered.
-
-      Given the daunting challenge of a complete definition of how to
-      ban such records, dealing with existing implementations that
-      permit the records today is a further complication.  There are
-      uses of wild card domain name owning NS RRSets.
-
-      One compromise proposed would have redefined wildcards of type
-      NS to not be used in synthesis, this compromise fell apart
-      because it would have required significant edits to the DNSSEC
-      signing and validation work.  (Again, DNSSEC catches
-      unauthorized data.)
-
-      With no clear consensus forming on the solution to this dilemma,
-      and the realization that wildcards of type NS are a rarity in
-      operations, the best course of action is to leave this open-ended
-      until "it matters."
-
-4.3 CNAME RRSet at a Wild Card Domain Name
-
-      The issue of a CNAME RRSet owned by a wild card domain name has
-      prompted a suggested change to the last paragraph of step 3c of
-      the algorithm in 4.3.2.  The changed text appears in section
-      3.3.3 of this document.
-
-4.4 DNAME RRSet at a Wild Card Domain Name
-
-      Ownership of a DNAME [RFC2672] RRSet by a wild card domain name
-      represents a threat to the coherency of the DNS and is to be
-      avoided or outright rejected.  Such a DNAME RRSet represents
-      non-deterministic synthesis of rules fed to different caches.
-      As caches are fed the different rules (in an unpredictable
-      manner) the caches will cease to be coherent.  ("As caches
-      are fed" refers to the storage in a cache of records obtained
-      in responses by recursive or iterative servers.)
-
-      For example, assume one cache, responding to a recursive
-      request, obtains the record:
-         "a.b.example. DNAME foo.bar.example.net."
-      and another cache obtains:
-         "b.example.  DNAME foo.bar.example.net."
-      both generated from the record:
-         "*.example. DNAME foo.bar.example.net."
-      by an authoritative server.
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 15]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-      The DNAME specification is not clear on whether DNAME records
-      in a cache are used to rewrite queries.  In some interpretations,
-      the rewrite occurs, in some, it is not.  Allowing for the
-      occurrence of rewriting, queries for "sub.a.b.example. A" may
-      be rewritten as "sub.foo.bar.tld. A" by the former caching
-      server and may be rewritten as "sub.a.foo.bar.tld. A" by the
-      latter.  Coherency is lost, an operational nightmare ensues.
-
-      Another justification for banning or avoiding wildcard DNAME
-      records is the observation that such a record could synthesize
-      a DNAME owned by "sub.foo.bar.example." and "foo.bar.example."
-      There is a restriction in the DNAME definition that no domain
-      exist below a DNAME-owning domain, hence, the wildcard DNAME
-      is not to be permitted.
-
-4.5 SRV RRSet at a Wild Card Domain Name
-
-      The definition of the SRV RRset is RFC 2782 [RFC2782].  In the
-      definition of the record, there is some confusion over the term
-      "Name."  The definition reads as follows:
-
-# The format of the SRV RR
-...
-#    _Service._Proto.Name TTL Class SRV Priority Weight Port Target
-...
-#  Name
-#   The domain this RR refers to.  The SRV RR is unique in that the
-#   name one searches for is not this name; the example near the end
-#   shows this clearly.
-
-      Do not confuse the definition "Name" with the owner name.  I.e.,
-      once removing the _Service and _Proto labels from the owner name
-      of the SRV RRSet, what remains could be a wild card domain name
-      but this is immaterial to the SRV RRSet.
-
-      E.g.,  If an SRV record is:
-         _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example.
-
-      *.example is a wild card domain name and although it is the Name
-      of the SRV RR, it is not the owner (domain name).  The owner
-      domain name is "_foo._udp.*.example." which is not a wild card
-      domain name.
-
-      The confusion is likely based on the mixture of the specification
-      of the SRV RR and the description of a "use case."
-
-4.6 DS RRSet at a Wild Card Domain Name
-
-      A DS RRSet owned by a wild card domain name is meaningless and
-      harmless.  This statement is made in the context that an NS RRSet
-      at a wild card domain name is undefined.  At a non-delegation
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 16]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-      point, a DS RRSet has no value (no corresponding DNSKEY RRSet
-      will be used in DNSSEC validation).  If there is a synthesized
-      DS RRSet, it alone will not be very useful as it exists in the
-      context of a delegation point.
-
-4.7 NSEC RRSet at a Wild Card Domain Name
-
-      Wild card domain names in DNSSEC signed zones will have an NSEC
-      RRSet.  Synthesis of these records will only occur when the
-      query exactly matches the record.  Synthesized NSEC RR's will not
-      be harmful as they will never be used in negative caching or to
-      generate a negative response.  [RFC2308]
-
-4.8 RRSIG at a Wild Card Domain Name
-
-      RRSIG records will be present at a wild card domain name in a
-      signed zone, and will be synthesized along with data sought in a
-      query.  The fact that the owner name is synthesized is not a
-      problem as the label count in the RRSIG will instruct the
-      verifying code to ignore it.
-
-4.9 Empty Non-terminal Wild Card Domain Name
-
-      If a source of synthesis is an empty non-terminal, then the
-      response will be one of no error in the return code and no RRSet
-      in the answer section.
-
-5. 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.
-
-6. IANA Considerations
-
-       None.
-
-7. References
-
-      Normative References
-
-      [RFC20]   ASCII Format for Network Interchange, V.G. Cerf,
-                Oct-16-1969
-
-      [RFC1034] Domain Names - Concepts and Facilities,
-                P.V. Mockapetris, Nov-01-1987
-
-      [RFC1035] Domain Names - Implementation and Specification, P.V
-                Mockapetris, Nov-01-1987
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 17]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-      [RFC1995] Incremental Zone Transfer in DNS, M. Ohta, August 1996
-
-      [RFC2119] Key Words for Use in RFCs to Indicate Requirement
-                Levels, S Bradner, March 1997
-
-      [RFC2308] Negative Caching of DNS Queries (DNS NCACHE),
-                M. Andrews, March 1998
-
-      [RFC2672] Non-Terminal DNS Name Redirection, M. Crawford,
-                August 1999.
-
-      [RFC2782] A DNS RR for specifying the location of services (DNS
-                SRV), A. Gulbrandsen, et.al., February 2000
-
-      [RFC4033] DNS Security Introduction and Requirements, R. Arends,
-                et.al., March 2005
-
-      [RFC4034] Resource Records for the DNS Security Extensions,
-                R. Arends, et.al., March 2005
-
-      [RFC4035] Protocol Modifications for the DNS Security Extensions,
-                R. Arends, et.al., March 2005
-
-      Informative References
-
-      [RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE),
-                P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
-                April 1997
-
-8. Editor
-
-           Name:         Edward Lewis
-           Affiliation:  NeuStar
-           Address:      46000 Center Oak Plaza, Sterling, VA, 20166, US
-           Phone:        +1-571-434-5468
-           Email:        ed.lewis@neustar.biz
-
-      Comments on this document can be sent to the editor or the mailing
-      list for the DNSEXT WG, namedroppers@ops.ietf.org.
-
-9. Others Contributing to the Document
-
-      This document represents the work of a large working group.  The
-      editor merely recorded the collective wisdom of the working group.
-
-
-
-
-
-
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 17]
-
-Internet-Draft                  dnsext-wcard           January 9, 2006
-
-10. Trailing Boilerplate
-
-      Copyright (C) The Internet Society (2006).
-
-      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.
-
-Intellectual Property
-
-      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.
-
-Acknowledgement
-
-      Funding for the RFC Editor function is currently provided by the
-      Internet Society.
-
-Expiration
-
-      This document expires on or about July 9, 2006.
-
-
-
-DNSEXT Working Group        Expires July 9, 2006             [Page 19]
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt
deleted file mode 100644
index 0855ba3..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt
+++ /dev/null
@@ -1,1232 +0,0 @@
-
-
-
-DNS Operations                                                 M. Larson
-Internet-Draft                                                 P. Barber
-Expires: August 14, 2006                                        VeriSign
-                                                       February 10, 2006
-
-
-                  Observed DNS Resolution Misbehavior
-                    draft-ietf-dnsop-bad-dns-res-05
-
-Status of this Memo
-
-   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 becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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 14, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This memo describes DNS iterative resolver behavior that results in a
-   significant query volume sent to the root and top-level domain (TLD)
-   name servers.  We offer implementation advice to iterative resolver
-   developers 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.
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 1]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   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 [1].
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-     1.1.  A note about terminology in this memo  . . . . . . . . . .  3
-   2.  Observed iterative resolver misbehavior  . . . . . . . . . . .  5
-     2.1.  Aggressive requerying for delegation information . . . . .  5
-       2.1.1.  Recommendation . . . . . . . . . . . . . . . . . . . .  6
-     2.2.  Repeated queries to lame servers . . . . . . . . . . . . .  7
-       2.2.1.  Recommendation . . . . . . . . . . . . . . . . . . . .  7
-     2.3.  Inability to follow multiple levels of indirection . . . .  8
-       2.3.1.  Recommendation . . . . . . . . . . . . . . . . . . . .  9
-     2.4.  Aggressive retransmission when fetching glue . . . . . . .  9
-       2.4.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 10
-     2.5.  Aggressive retransmission behind firewalls . . . . . . . . 10
-       2.5.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 11
-     2.6.  Misconfigured NS records . . . . . . . . . . . . . . . . . 11
-       2.6.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 12
-     2.7.  Name server records with zero TTL  . . . . . . . . . . . . 12
-       2.7.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 13
-     2.8.  Unnecessary dynamic update messages  . . . . . . . . . . . 13
-       2.8.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 14
-     2.9.  Queries for domain names resembling IPv4 addresses . . . . 14
-       2.9.1.  Recommendation . . . . . . . . . . . . . . . . . . . . 14
-     2.10. Misdirected recursive queries  . . . . . . . . . . . . . . 15
-       2.10.1. Recommendation . . . . . . . . . . . . . . . . . . . . 15
-     2.11. Suboptimal name server selection algorithm . . . . . . . . 15
-       2.11.1. Recommendation . . . . . . . . . . . . . . . . . . . . 16
-   3.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
-   4.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 18
-   5.  Security considerations  . . . . . . . . . . . . . . . . . . . 19
-   6.  Internationalization considerations  . . . . . . . . . . . . . 20
-   7.  Informative References . . . . . . . . . . . . . . . . . . . . 20
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
-   Intellectual Property and Copyright Statements . . . . . . . . . . 22
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 2]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-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 (i.e., the
-   same query received simultaneously from multiple IP addresses).
-
-   By analyzing requery events we have found that the cause of the
-   duplicate traffic is almost always a deficient iterative resolver,
-   stub resolver 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 indirection must be followed, and aggressive retry by stub
-   resolvers 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.  None of the changes recommended affects the core DNS protocol
-   specification; instead, this document consists of guidelines to
-   implementors of iterative resolvers.
-
-1.1.  A note about terminology in this memo
-
-   To recast an old saying about standards, the nice thing about DNS
-   terms is that there are so many of them to choose from.  Writing or
-   talking about DNS can be difficult and cause confusion resulting from
-   a lack of agreed-upon terms for its various components.  Further
-   complicating matters are implementations that combine multiple roles
-   into one piece of software, which makes naming the result
-   problematic.  An example is the entity that accepts recursive
-   queries, issues iterative queries as necessary to resolve the initial
-   recursive query, caches responses it receives, and which is also able
-   to answer questions about certain zones authoritatively.  This entity
-   is an iterative resolver combined with an authoritative name server
-   and is often called a "recursive name server" or a "caching name
-   server".
-
-   This memo is concerned principally with the behavior of iterative
-   resolvers, which are typically found as part of a recursive name
-   server.  This memo uses the more precise term "iterative resolver",
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 3]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   because the focus is usually on that component.  In instances where
-   the name server role of this entity requires mentioning, this memo
-   uses the term "recursive name server".  As an example of the
-   difference, the name server component of a recursive name server
-   receives DNS queries and the iterative resolver component sends
-   queries.
-
-   The advent of IPv6 requires mentioning AAAA records as well as A
-   records when discussing glue.  To avoid continuous repetition and
-   qualification, this memo uses the general term "address record" to
-   encompass both A and AAAA records when a particular situation is
-   relevant to both types.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 4]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-2.  Observed iterative resolver 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 an iterative resolver
-   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 whose
-   iterative resolver 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.  (Note
-   that queries with QTYPE=NS are not required by the standard
-   resolution algorithm described in section 4.3.2 of RFC 1034 [2].
-   These NS queries represent this implementation's addition to that
-   algorithm.)
-
-   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 iterative resolver implementation immediately queries a
-   "com" zone name server for the "example.com" NS RRset to verify it
-   has the proper delegation information.  This 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 recursive
-   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 an iterative resolver 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 would be pointless: this query to the parent would come so
-   quickly on the heels of the referral that it would be almost certain
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 5]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   to contain the same list of name servers.  The chance of discovering
-   any new information is slim.
-
-   The other possibility is that the iterative resolver successfully
-   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 [3], 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 iterative resolver 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 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 when at all possible, with servers
-   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.
-
-   This section should not be understood to claim that all queries to a
-   zone's parent are bad.  In some cases, such queries are not only
-   reasonable but required.  Consider the situation when required
-   information, such as the address of a name server (i.e., the address
-   record corresponding to the RDATA of an NS record), has timed out of
-   an iterative resolver's cache before the corresponding NS record.  If
-   the name of the name server is below the apex of the zone, then the
-   name server's address record is only available as glue in the parent
-   zone.  For example, consider this NS record:
-
-     example.com.        IN   NS   ns.example.com.
-
-   If a cache has this NS record but not the address record for
-   "ns.example.com", it is unable to contact the "example.com" zone
-   directly and must query the "com" zone to obtain the address record.
-   Note, however, that such a query would not have QTYPE=NS according to
-   the standard resolution algorithm.
-
-2.1.1.  Recommendation
-
-   An iterative resolver 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
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 6]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   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 [4].
-
-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 when a subset of a zone's name servers
-   are unavailable or misconfigured.  Different failure modes have
-   different expected durations.  Some symptoms indicate problems that
-   are potentially transient; for example, 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 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.
-
-   It should also be noted, however, that some authoritative name server
-   implementations appear to be lame only for queries of certain types
-   as described in RFC 4074 [5].  In this case, it makes sense to retry
-   the "lame" servers for other types of queries, particularly when all
-   known authoritative name servers appear to be "lame".
-
-2.2.1.  Recommendation
-
-   Iterative resolvers SHOULD cache name servers that they discover are
-   not authoritative for zones delegated to them (i.e. lame servers).
-   If this caching is performed, 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.
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 7]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   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.
-
-   An exception to this recommendation occurs if all name servers for a
-   zone are marked lame.  In that case, the iterative resolver SHOULD
-   temporarily ignore the servers' lameness status and query one or more
-   servers.  This behavior is a workaround for the type-specific
-   lameness issue described in the previous section.
-
-   Implementors should take care not to make lame server avoidance logic
-   overly broad: note that a name server could be lame for a parent zone
-   but not a child zone, e.g., lame for "example.com" but properly
-   authoritative for "sub.example.com".  Therefore a name server should
-   not be automatically considered lame for subzones.  In the case
-   above, even if a name server is known to be lame for "example.com",
-   it should be queried for QNAMEs at or below "sub.example.com" if an
-   NS record indicates it should be authoritative for that zone.
-
-2.3.  Inability to follow multiple levels of indirection
-
-   Some iterative resolver implementations are unable to follow
-   sufficient levels of indirection.  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.
-
-   An iterative resolver resolving the name "www.foo.example" must
-   follow two levels of indirection, first obtaining address records for
-   "ns1.test.example.net" or "ns2.test.example.net" in order to obtain
-   address records for "ns1.example.com" 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
-   top-level domains (gTLDs) become active.  We anticipate many zones in
-   new gTLDs will use name servers in existing gTLDs, increasing the
-   number of delegations using out-of-zone name servers.
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 8]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-2.3.1.  Recommendation
-
-   Clearly constructing a delegation that relies on multiple levels of
-   indirection is not a good administrative practice.  However, the
-   practice is widespread enough to require that iterative resolvers be
-   able to cope with it.  Iterative resolvers SHOULD be able to handle
-   arbitrary levels of indirection resulting from out-of-zone name
-   servers.  Iterative resolvers SHOULD implement a level-of-effort
-   counter to avoid loops or otherwise performing too much work in
-   resolving pathological cases.
-
-   A best practice that avoids this entire issue of indirection is to
-   name one or more of a zone's name servers in the zone itself.  For
-   example, if the zone is named "example.com", consider naming some of
-   the name servers "ns{1,2,...}.example.com" (or similar).
-
-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 address records for every NS record in
-   the authority section.  If necessary, the name server issues multiple
-   queries of its own to obtain any missing address 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 an entity will not
-   normally generate any queries of its own.  Instead it answers non-
-   recursive queries from iterative resolvers looking for information in
-   zones it serves.  With glue fetching enabled, however, an
-   authoritative server invokes an iterative resolver to look up an
-   unknown address record to complete the additional section of a
-   response.
-
-   We have observed situations where the iterative resolver of a glue-
-   fetching name server can send queries that reach other name servers,
-   but is apparently prevented from receiving the responses.  For
-   example, perhaps the name server is authoritative-only and therefore
-   its administrators expect it to receive only queries and not
-   responses.  Perhaps unaware of glue fetching and presuming that the
-   name server's iterative resolver will generate no queries, its
-   administrators place the name server behind a network device that
-
-
-
-Larson & Barber          Expires August 14, 2006                [Page 9]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   prevents it from receiving responses.  If this is the case, all glue-
-   fetching queries will go answered.
-
-   We have observed name server implementations whose iterative
-   resolvers retry excessively when glue-fetching queries are
-   unanswered.  A single com/net name server has received hundreds of
-   queries per second from a single such source.  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, an
-   iterative resolver 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 iterative resolvers'
-   traffic is improperly filtered in this manner.  Stub resolvers in the
-   organization could be configured to query multiple recursive name
-   servers.  Consider the case where a stub resolver queries a filtered
-   recursive name server first.  The iterative resolver of this
-   recursive name server sends one or more queries whose replies are
-   filtered, so it can't respond to the stub resolver, which times out.
-   Then the stub resolver retransmits to a recursive 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 implementation has a very aggressive retransmission
-   schedule, including simultaneous queries to multiple recursive name
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 10]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   servers, which could explain how such a situation could persist
-   without being detected.
-
-2.5.1.  Recommendation
-
-   The most obvious recommendation is that administrators SHOULD take
-   care not to place iterative resolvers behind a firewall that allows
-   queries to pass through but not the resulting replies.
-
-   Iterative resolvers 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.  An iterative resolver
-   attempting to resolve address 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 delegation information is correct in the "com"
-   zone.)  The iterative resolver 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" address record in the answer section and,
-   typically, the "example.com" NS records in the authority section and,
-   if space in the message remains, glue address records in the
-   additional section.  According to Section 5.4 of RFC 2181 [3], 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 overrides the
-   "example.com" NS RRset received moments ago from the "com"
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 11]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   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 iterative resolver to attempt to use the incorrect NS
-   records and so it will try to resolve the nonexistent names
-   "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 iterative resolver cannot reach any "example.com" name
-   servers.  Therefore attempts to resolve these names result in address
-   record queries to the "com" authoritative servers.  Queries for such
-   obviously bogus glue address 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 exists somewhere under the apex of the zone the
-   NS record appears in.  Note that further levels of delegation are
-   possible, so a missing trailing dot could inadvertently create a name
-   server name that actually exists in a subzone.
-
-   An authoritative name server SHOULD issue a warning when one of a
-   zone's NS records references a name server below the zone's apex when
-   a corresponding address record does not exist in the zone AND there
-   are no delegated subzones where the address record could exist.
-
-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 an iterative
-   resolver 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
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 12]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   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 iterative resolvers throughout the Internet to cache the NS
-   RRset for a long period of time, a low TTL is reasonable.
-
-2.7.1.  Recommendation
-
-   Because of the additional load placed on a zone's parent's
-   authoritative servers resulting from a zero TTL on a zone's NS RRset,
-   under such circumstances authoritative name servers SHOULD issue a
-   warning when loading a zone.
-
-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
-   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 entails walking up the name
-   space tree by sending repeated UPDATE messages until success.  For
-   example, consider an agent attempting to add an address 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 valid question is why the algorithm proceeds to send
-   updates all the way to TLD and root name servers.  This behavior is
-   not entirely unreasonable: in enterprise DNS architectures with an
-   "internal root" design, there could conceivably be private, non-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 13]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   public TLD or root zones that would be the appropriate targets for a
-   dynamic update.
-
-   A significant deficiency with this algorithm is that knowledge of a
-   given UPDATE message's failure is not helpful in directing future
-   UPDATE messages to the appropriate servers.  A better algorithm would
-   be to find the closest enclosing zone by walking up the name space
-   with queries for SOA or NS rather than "probing" with UPDATE
-   messages.  Once the appropriate zone is found, an UPDATE message can
-   be sent.  In addition, the results of these queries can be cached to
-   aid in determining closest enclosing zones for future updates.  Once
-   the closest enclosing zone is determined with this method, the update
-   will either succeed or fail and there is no need to send further
-   updates to higher-level zones.  The important point is that walking
-   up the tree with queries yields cacheable information, whereas
-   walking up the tree by sending UPDATE messages does not.
-
-2.8.1.  Recommendation
-
-   Dynamic update agents SHOULD send SOA or NS queries to progressively
-   higher-level names to find the closest enclosing zone for a given
-   name to update.  Only after the appropriate zone is found should the
-   client send an UPDATE message to one of the zone's authoritative
-   servers.  Update clients SHOULD NOT "probe" using UPDATE messages by
-   walking up the tree to progressively higher-level zones.
-
-2.9.  Queries for domain names resembling IPv4 addresses
-
-   The root name servers receive a significant number of A record
-   queries where the QNAME looks like an IPv4 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.  An iterative
-   resolver 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
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 14]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   bandwidth.  A possible solution is to delegate these numeric TLDs
-   from the root zone to a separate set of servers to absorb the
-   traffic.  The "black hole servers" used by 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.  Of course, the proper and usual root zone
-   change procedures would have to be followed to make such a change to
-   the root zone.
-
-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 offers 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
-   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 name server that supposedly offers recursion
-   is configured in a stub resolver using an interactive user interface,
-   the resolver could send a test query to verify that the server indeed
-   supports recursion (i.e., verify that 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 under specified, 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.
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 15]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-   Some deficiencies cause significant operational impact and are
-   therefore worth mentioning here.  One of these is name server
-   selection by an iterative resolver.  When an iterative resolver 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.
-
-   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.
-      Apparently 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.  An
-      iterative resolver 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 14, 2006               [Page 16]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-3.  Acknowledgments
-
-   The authors would like to thank the following people for their
-   comments that improved this document: Andras Salamon, Dave Meyer,
-   Doug Barton, Jaap Akkerhuis, Jinmei Tatuya, John Brady, Kevin Darcy,
-   Olafur Gudmundsson, Pekka Savola, Peter Koch and Rob Austein.  We
-   apologize if we have omitted anyone; any oversight was unintentional.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 17]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-4.  IANA considerations
-
-   There are no new IANA considerations introduced by this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 18]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-5.  Security considerations
-
-   The iterative resolver misbehavior discussed in this document exposes
-   the root and TLD name servers to increased risk of both intentional
-   and unintentional denial of service attacks.
-
-   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 14, 2006               [Page 19]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-6.  Internationalization considerations
-
-   There are no new internationalization considerations introduced by
-   this memo.
-
-7.  Informative 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]  Elz, R. and R. Bush, "Clarifications to the DNS Specification",
-        RFC 2181, July 1997.
-
-   [4]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
-        RFC 2308, March 1998.
-
-   [5]  Morishita, Y. and T. Jinmei, "Common Misbehavior Against DNS
-        Queries for IPv6 Addresses", RFC 4074, May 2005.
-
-   [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>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 20]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-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 14, 2006               [Page 21]
-
-Internet-Draft     Observed DNS Resolution Misbehavior     February 2006
-
-
-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 (2006).  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.
-
-
-
-
-Larson & Barber          Expires August 14, 2006               [Page 22]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-08.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-08.txt
deleted file mode 100644
index 8ca68a8..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-08.txt
+++ /dev/null
@@ -1,2016 +0,0 @@
-
-
-
-DNSOP                                                         O. Kolkman
-Internet-Draft                                                 R. Gieben
-Obsoletes: 2541 (if approved)                                 NLnet Labs
-Expires: September 7, 2006                                 March 6, 2006
-
-
-                      DNSSEC Operational Practices
-          draft-ietf-dnsop-dnssec-operational-practices-08.txt
-
-Status of this Memo
-
-   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 becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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 September 7, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes a set of practices for operating the DNS with
-   security extensions (DNSSEC).  The target audience is zone
-   administrators deploying DNSSEC.
-
-   The document discusses operational aspects of using keys and
-   signatures in the DNS.  It discusses issues as key generation, key
-   storage, signature generation, key rollover and related policies.
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006               [Page 1]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   This document obsoletes RFC 2541, as it covers more operational
-   ground and gives more up to date requirements with respect to key
-   sizes and the new DNSSEC specification.
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.1.  The Use of the Term 'key'  . . . . . . . . . . . . . . . .  4
-     1.2.  Time Definitions . . . . . . . . . . . . . . . . . . . . .  5
-   2.  Keeping the Chain of Trust Intact  . . . . . . . . . . . . . .  5
-   3.  Keys Generation and Storage  . . . . . . . . . . . . . . . . .  6
-     3.1.  Zone and Key Signing Keys  . . . . . . . . . . . . . . . .  6
-       3.1.1.  Motivations for the KSK and ZSK Separation . . . . . .  7
-       3.1.2.  KSKs for High Level Zones  . . . . . . . . . . . . . .  8
-     3.2.  Key Generation . . . . . . . . . . . . . . . . . . . . . .  8
-     3.3.  Key Effectivity Period . . . . . . . . . . . . . . . . . .  9
-     3.4.  Key Algorithm  . . . . . . . . . . . . . . . . . . . . . .  9
-     3.5.  Key Sizes  . . . . . . . . . . . . . . . . . . . . . . . . 10
-     3.6.  Private Key Storage  . . . . . . . . . . . . . . . . . . . 12
-   4.  Signature generation, Key Rollover and Related Policies  . . . 12
-     4.1.  Time in DNSSEC . . . . . . . . . . . . . . . . . . . . . . 12
-       4.1.1.  Time Considerations  . . . . . . . . . . . . . . . . . 13
-     4.2.  Key Rollovers  . . . . . . . . . . . . . . . . . . . . . . 14
-       4.2.1.  Zone Signing Key Rollovers . . . . . . . . . . . . . . 15
-       4.2.2.  Key Signing Key Rollovers  . . . . . . . . . . . . . . 19
-       4.2.3.  Difference Between ZSK and KSK Rollovers . . . . . . . 20
-       4.2.4.  Automated Key Rollovers  . . . . . . . . . . . . . . . 21
-     4.3.  Planning for Emergency Key Rollover  . . . . . . . . . . . 22
-       4.3.1.  KSK Compromise . . . . . . . . . . . . . . . . . . . . 22
-       4.3.2.  ZSK Compromise . . . . . . . . . . . . . . . . . . . . 24
-       4.3.3.  Compromises of Keys Anchored in Resolvers  . . . . . . 24
-     4.4.  Parental Policies  . . . . . . . . . . . . . . . . . . . . 24
-       4.4.1.  Initial Key Exchanges and Parental Policies
-               Considerations . . . . . . . . . . . . . . . . . . . . 24
-       4.4.2.  Storing Keys or Hashes?  . . . . . . . . . . . . . . . 25
-       4.4.3.  Security Lameness  . . . . . . . . . . . . . . . . . . 25
-       4.4.4.  DS Signature Validity Period . . . . . . . . . . . . . 26
-   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
-   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 27
-   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
-     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 27
-     8.2.  Informative References . . . . . . . . . . . . . . . . . . 28
-   Appendix A.  Terminology . . . . . . . . . . . . . . . . . . . . . 29
-   Appendix B.  Zone Signing Key Rollover Howto . . . . . . . . . . . 30
-   Appendix C.  Typographic Conventions . . . . . . . . . . . . . . . 31
-   Appendix D.  Document Details and Changes  . . . . . . . . . . . . 33
-
-
-
-Kolkman & Gieben        Expires September 7, 2006               [Page 2]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-     D.1.  draft-ietf-dnsop-dnssec-operational-practices-00 . . . . . 33
-     D.2.  draft-ietf-dnsop-dnssec-operational-practices-01 . . . . . 33
-     D.3.  draft-ietf-dnsop-dnssec-operational-practices-02 . . . . . 33
-     D.4.  draft-ietf-dnsop-dnssec-operational-practices-03 . . . . . 33
-     D.5.  draft-ietf-dnsop-dnssec-operational-practices-04 . . . . . 34
-     D.6.  draft-ietf-dnsop-dnssec-operational-practices-05 . . . . . 34
-     D.7.  draft-ietf-dnsop-dnssec-operational-practices-06 . . . . . 34
-     D.8.  draft-ietf-dnsop-dnssec-operational-practices-07 . . . . . 34
-     D.9.  draft-ietf-dnsop-dnssec-operational-practices-08 . . . . . 34
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
-   Intellectual Property and Copyright Statements . . . . . . . . . . 36
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006               [Page 3]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-1.  Introduction
-
-   This document describes how to run a DNSSEC (DNS SECure) enabled
-   environment.  It is intended for operators who have knowledge of the
-   DNS (see RFC 1034 [1] and RFC 1035 [2]) and want deploy DNSSEC.  See
-   RFC 4033 [4] for an introduction into DNSSEC and RFC 4034 [5] for the
-   newly introduced Resource Records and finally RFC 4035 [6] for the
-   protocol changes.
-
-   During workshops and early operational deployment tests, operators
-   and system administrators have gained experience about operating the
-   DNS with security extensions (DNSSEC).  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 representing '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 re-signing or key
-   rollovers be transparent to any verifying clients on the Internet.
-
-   The structure of this document is as follows.  In Section 2 we
-   discuss the importance of keeping the "chain of trust" intact.
-   Aspects of key generation and storage of private keys are discussed
-   in Section 3; the focus in this section is mainly on the private part
-   of the key(s).  Section 4 describes considerations concerning the
-   public part of the keys.  Since these public keys appear in the DNS
-   one has to take into account all kinds of timing issues, which are
-   discussed in Section 4.1.  Section 4.2 and Section 4.3 deal with the
-   rollover, or supercession, of keys.  Finally Section 4.4 discusses
-   considerations on how parents deal with their children's public keys
-   in order to maintain chains of trust.
-
-   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 RFC 2119 [9] language does not apply.
-
-   This document obsoletes RFC 2541 [12].
-
-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
-   [18]).  Therefore, this document will use the term 'key' rather
-   loosely.  Where it is written that 'a key is used to sign data' it is
-
-
-
-Kolkman & Gieben        Expires September 7, 2006               [Page 4]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   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 the public part that is
-   used in key exchanges.
-
-1.2.  Time Definitions
-
-   In this document we will be using a number of time related terms.
-   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.
-   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.
-         After one stops publishing an RRSIG in a zone it may take a
-         while before the RRSIG has expired from caches and has actually
-         been removed from the DNS.
-   o  "Key effectivity period"
-         The period during which a key pair is expected to be effective.
-         This period is defined as the time between the first inception
-         time stamp and the last expiration date of any signature made
-         with this key, regardless of any discontinuity in the use of
-         the key.
-         The key effectivity period can span multiple signature validity
-         periods.
-   o  "Maximum/Minimum Zone Time to Live (TTL)"
-         The maximum or minimum value of the TTLs from the complete set
-         of RRs in a zone.  Note that the minimum TTL is not the same as
-         the MINIMUM field in the SOA RR.  See [11] for more
-         information.
-
-
-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 (as defined in [4]
-   section 5), which may cause entire (sub)domains to become invisible
-   to verifying clients.  The administrators of secured zones have to
-   realize that their zone is, to verifying clients, part of a chain of
-   trust.
-
-   As mentioned in the introduction, the procedures herein are intended
-
-
-
-Kolkman & Gieben        Expires September 7, 2006               [Page 5]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   to ensure that maintenance of zones, such as re-signing or key
-   rollovers, will 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
-   transferred to other secondary authoritative nameservers and clients
-   may be fetching data from caching non-authoritative servers.  In this
-   light it is good to note that the time for a zone transfer from
-   master to slave is negligible when using NOTIFY [8] and IXFR [7],
-   increasing by reliance on AXFR, and more if you rely on the SOA
-   timing parameters for zone refresh.
-
-   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 replacing the compromised keys
-   as soon as possible must be made.  Then zone administrators will have
-   to make a trade off, between keeping the chain of trust intact -
-   thereby allowing for attacks with the compromised key - or to
-   deliberately break the chain of trust and making secured sub domains
-   invisible to security aware resolvers.  Also see Section 4.3.
-
-
-3.  Keys Generation and Storage
-
-   This section describes a number of considerations with respect to the
-   security of keys.  It deals with the generation, effectivity period,
-   size and storage of private keys.
-
-3.1.  Zone and Key Signing Keys
-
-   The DNSSEC validation protocol does not distinguish between different
-   types of DNSKEYs.  All DNSKEYs can be used during the validation.  In
-   practice operators use Key Signing and Zone Signing Keys and use the
-   so-called (Secure Entry Point) SEP [3] flag to distinguish between
-   them during operations.  The dynamics and considerations are
-   discussed below.
-
-   To make zone re-signing and key rollover procedures easier to
-
-
-
-Kolkman & Gieben        Expires September 7, 2006               [Page 6]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   implement, it is possible to use one or more keys as Key Signing Keys
-   (KSK).  These keys will only sign the apex DNSKEY RRSet 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 parent and potentially for configuration as trusted anchors - the
-   SEP keys.  In this document we assume a one-to-one mapping between
-   KSK and SEP keys and we assume the SEP flag to be set on all KSKs.
-
-3.1.1.  Motivations for the KSK and ZSK Separation
-
-   Differentiating between the KSK and ZSK functions has several
-   advantages:
-
-   o  No parent/child interaction is required when ZSKs are updated.
-   o  The KSK can be made stronger (i.e. using more bits in the key
-      material).  This has little operational impact since it is only
-      used to sign a small fraction of the zone data.  Also the KSK is
-      only used to verify the zone's key set, not for other RRSets in
-      the zone.
-   o  As the KSK is only used to sign a key set, which is most probably
-      updated less frequently than other data in the zone, it can be
-      stored separately from and in a safer location than the ZSK.
-   o  A KSK can have a longer key effectivity period.
-
-   For almost any method of key management and zone signing the KSK is
-   used less frequently than the ZSK.  Once a key set is signed with the
-   KSK all the keys in the key set can be used as ZSK.  If a ZSK is
-   compromised, it can be simply dropped from the key set.  The new key
-   set is then re-signed 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.
-
-   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 "Signature
-   Validity Periods" on the order of days.
-
-   The key signing key is only to be used to sign the DNSKEY RRs in a
-   zone.  If a key signing key is to be rolled over, there will be
-   interactions with parties other than the zone administrator.  These
-   can include the registry of the parent zone or administrators of
-   verifying resolvers that have the particular key configured as secure
-   entry points.  Hence, the key effectivity period of these keys can
-   and should be made much longer.  Although, given a long enough key,
-
-
-
-Kolkman & Gieben        Expires September 7, 2006               [Page 7]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   the Key Effectivity Period can be on the order of years we suggest
-   planning for a key effectivity of the order of a few months so that a
-   key rollover remains an operational routine.
-
-3.1.2.  KSKs for High Level Zones
-
-   Higher level zones are generally more sensitive than lower level
-   zones.  Anyone controlling or breaking the security of a zone thereby
-   obtains authority over all of its sub domains (except in the case of
-   resolvers that have locally configured the public key of a sub
-   domain, in which case this, and only this, sub domain wouldn't be
-   affected by the compromise of the parent zone).  Therefore, extra
-   care should be taken with high level zones and strong keys should
-   used.
-
-   The root zone is the most critical of all zones.  Someone controlling
-   or compromising the security of the root zone would control the
-   entire DNS name space of all resolvers using that root zone (except
-   in the case of resolvers that have locally configured the public key
-   of a sub domain).  Therefore, the utmost care must be taken in the
-   securing of the root zone.  The strongest and most carefully handled
-   keys should be used.  The root zone private key should always be kept
-   off line.
-
-   Many resolvers will start at a root server for their access to and
-   authentication of DNS data.  Securely updating the trust anchors in
-   an enormous population of resolvers around the world will be
-   extremely difficult.
-
-3.2.  Key Generation
-
-   Careful generation of all keys is a sometimes overlooked but
-   absolutely essential element in any cryptographically secure system.
-   The strongest algorithms used with the longest keys are still of no
-   use if an adversary can guess enough to lower the size of the likely
-   key space so that it can be exhaustively searched.  Technical
-   suggestions for the generation of random keys will be found in RFC
-   4086 [15].  One should carefully assess if the random number
-   generator used during key generation adheres to these suggestions.
-
-   Keys with a long effectivity period are particularly sensitive as
-   they will represent a more valuable target and be subject to attack
-   for a longer time than short period keys.  It is strongly recommended
-   that long term key generation occur off-line in a manner isolated
-   from the network via an air gap or, at a minimum, high level secure
-   hardware.
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006               [Page 8]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-3.3.  Key Effectivity Period
-
-   For various reasons keys in DNSSEC need to be changed once in a
-   while.  The longer a key is in use, the greater the probability that
-   it will have been compromised through carelessness, accident,
-   espionage, or cryptanalysis.  Furthermore when key rollovers are too
-   rare an event, they will not become part of the operational habit and
-   there is risk that nobody on-site will remember the procedure for
-   rollover when the need is there.
-
-   From a purely operational perspective a reasonable key effectivity
-   period for Key Signing Keys is 13 months, with the intent to replace
-   them after 12 months.  An intended key effectivity period of a month
-   is reasonable for Zone Signing Keys.
-
-   For key sizes that matches these effectivity periods see Section 3.5.
-
-   As argued in Section 3.1.2 securely updating trust anchors will be
-   extremely difficult.  On the other hand the "operational habit"
-   argument does also apply to trust anchor reconfiguration.  If a short
-   key-effectivity period is used and the trust anchor configuration has
-   to be revisited on a regular basis the odds that the configuration
-   tends to be forgotten is smaller.  The trade-off is against a system
-   that is so dynamic that administrators of the validating clients will
-   not be able to follow the modifications.
-
-   Key effectivity periods can be made very short, as in the order of a
-   few minutes.  But when replacing keys one has to take the
-   considerations from Section 4.1 and Section 4.2 into account.
-
-3.4.  Key Algorithm
-
-   There are currently three different types of algorithms that can be
-   used in DNSSEC: RSA, DSA and elliptic curve cryptography.  The latter
-   is fairly new and has yet to be standardized for usage in DNSSEC.
-
-   RSA has been developed in an open and transparent manner.  As the
-   patent on RSA expired in 2000, its use is now also free.
-
-   DSA has been developed by NIST.  The creation of signatures takes
-   roughly the same time as with RSA, but is 10 to 40 times as slow for
-   verification [18].
-
-   We suggest the use of RSA/SHA-1 as the preferred algorithm for the
-   key.  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 SHA-1.
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006               [Page 9]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   At the time of publication it is known that the SHA-1 hash has
-   cryptanalysis issues.  There is work in progress on addressing these
-   issues.  We recommend the use of public key algorithms based on
-   hashes stronger than SHA-1, e.g.  SHA-256, as soon as these
-   algorithms are available in protocol specifications (See [20] and
-   [21] ) and implementations.
-
-3.5.  Key Sizes
-
-   When choosing key sizes, zone administrators will need to take into
-   account how long a key will be used, how much data will be signed
-   during the key publication period (See Section 8.10 of [18]) and,
-   optionally, how large the key size of the parent is.  As the chain of
-   trust really is "a chain", there is not much sense in making one of
-   the keys in the chain several times larger then the others.  As
-   always, it's the weakest link that defines the strength of the entire
-   chain.  Also see Section 3.1.1 for a discussion of how keys serving
-   different roles (ZSK v.  KSK) may need different key sizes.
-
-   Generating a key of the correct size is a difficult problem, RFC 3766
-   [14] tries to deal with that problem.  The first part of the
-   selection procedure in Section 1 of the RFC states:
-
-      1. Determine the attack resistance necessary to satisfy the
-         security requirements of the application.  Do this by
-         estimating the minimum number of computer operations that
-         the attacker will be forced to do in order to compromise
-         the security of the system and then take the logarithm base
-         two of that number.  Call that logarithm value "n".
-
-         A 1996 report recommended 90 bits as a good all-around choice
-         for system security.  The 90 bit number should be increased
-         by about 2/3 bit/year, or about 96 bits in 2005.
-
-   [14] goes on to explain how this number "n" can be used to calculate
-   the key sizes in public key cryptography.  This culminated in the
-   table given below (slightly modified for our purpose):
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 10]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-      +-------------+-----------+--------------+
-      | System      |           |              |
-      | requirement | Symmetric | RSA or DSA   |
-      | for attack  | key size  | modulus size |
-      | resistance  | (bits)    | (bits)       |
-      | (bits)      |           |              |
-      +-------------+-----------+--------------+
-      |     70      |     70    |      947     |
-      |     80      |     80    |     1228     |
-      |     90      |     90    |     1553     |
-      |    100      |    100    |     1926     |
-      |    150      |    150    |     4575     |
-      |    200      |    200    |     8719     |
-      |    250      |    250    |    14596     |
-      +-------------+-----------+--------------+
-
-   The key sizes given are rather large.  This is because these keys are
-   resilient against a trillionaire attacker.  Assuming this rich
-   attacker will not attack your key and that the key is rolled over
-   once a year, we come to the following recommendations about KSK
-   sizes; 1024 bits low value domains, 1300 for medium value and 2048
-   for the high value domains.
-
-   Whether a domain is of low, medium, high value depends solely on the
-   views of the zone owner.  One could for instance view leaf nodes in
-   the DNS as of low value and TLDs or the root zone of high value.  The
-   suggested key sizes should be safe for the next 5 years.
-
-   As ZSKs can be rolled over more easily (and thus more often) the key
-   sizes can be made smaller.  But as said in the introduction of this
-   paragraph, making the ZSKs' key sizes too small (in relation to the
-   KSKs' sizes) doesn't make much sense.  Try to limit the difference in
-   size to about 100 bits.
-
-   Note that nobody can see into the future, and that these key sizes
-   are only provided here as a guide.  Further information can be found
-   in [17] and Section 7.5 of [18].  It should be noted though that [17]
-   is already considered overly optimistic about what key sizes are
-   considered safe.
-
-   One final note concerning key sizes.  Larger keys will increase the
-   sizes of the RRSIG and DNSKEY records and will therefore increase the
-   chance of DNS UDP packet overflow.  Also the time it takes to
-   validate and create RRSIGs increases with larger keys, so don't
-   needlessly double your key sizes.
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 11]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-3.6.  Private Key Storage
-
-   It is recommended that, where possible, zone private keys and the
-   zone file master copy that is to be signed, be kept and used in off-
-   line, non-network connected, physically secure machines only.
-   Periodically an application can be run to add authentication to a
-   zone by adding RRSIG and NSEC RRs.  Then the augmented file can be
-   transferred.
-
-   When relying on dynamic update to manage a signed zone [10], be aware
-   that at least one private key of the zone will have to reside on the
-   master server.  This key is only as secure as the amount of exposure
-   the server receives to unknown clients and the security of the host.
-   Although not mandatory one could administer the DNS in the following
-   way.  The master that processes the dynamic updates is unavailable
-   from generic hosts on the Internet, it is not listed in the NS RR
-   set, although its name appears in the SOA RRs MNAME field.  The
-   nameservers in the NS RR set are able to receive zone updates through
-   NOTIFY, IXFR, AXFR or an out-of-band distribution mechanism.  This
-   approach is known as the "hidden master" setup.
-
-   The ideal situation is to have a one way information flow to the
-   network to avoid the possibility of tampering from the network.
-   Keeping the zone master file on-line on the network and simply
-   cycling it through an off-line signer does not do this.  The on-line
-   version could still be tampered with if the host it resides on is
-   compromised.  For maximum security, the master copy of the zone file
-   should be off net and should not be updated based on an unsecured
-   network mediated communication.
-
-   In general keeping a zone-file off-line will not be practical and the
-   machines on which zone files are maintained will be connected to a
-   network.  Operators are advised to take security measures to shield
-   unauthorized access to the master copy.
-
-   For dynamically updated secured zones [10] both the master copy and
-   the private key that is used to update signatures on updated RRs will
-   need to be on-line.
-
-
-4.  Signature generation, Key Rollover and Related Policies
-
-4.1.  Time in DNSSEC
-
-   Without DNSSEC all times in DNS are relative.  The SOA fields
-   REFRESH, RETRY and EXPIRATION are timers used to determine the time
-   elapsed after a slave server synchronized with a master server.  The
-   Time to Live (TTL) value and the SOA RR minimum TTL parameter [11]
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 12]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   are used to determine how long a forwarder should cache data after it
-   has been fetched from an authoritative server.  By using a signature
-   validity period, 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.
-
-4.1.1.  Time Considerations
-
-   Because of the expiration of signatures, one should consider the
-   following:
-   o  We suggest the Maximum Zone TTL of your zone data to 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.  Section
-         7.1 of [4] suggests that "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".  As a result
-         query load on authoritative servers would peak at signature
-         expiration time, as this is also the time at which records
-         simultaneously expire from caches.
-         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  We suggest the Signature Publication Period to end at least one
-      Maximum Zone TTL duration before the end of the Signature Validity
-      Period.
-         Re-signing 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  We suggest the minimum zone TTL to be long enough to both fetch
-      and verify all the RRs in the trust chain.  In workshop
-      environments it has been demonstrated [19] that a low TTL (under 5
-      to 10 minutes) caused disruptions because of the following two
-      problems:
-         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 RRSet 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 September 7, 2006              [Page 13]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   o  Slave servers will need to be able to fetch newly signed zones
-      well before the RRSIGs in the zone served by the slave server pass
-      their signature expiration time.
-         When a slave server is out of sync with its master and data in
-         a zone is signed by expired signatures it may be better for the
-         slave server not to give out any answer.
-         Normally a slave server that is not able to contact a master
-         server for an extended period will expire a zone.  When that
-         happens the server will respond differently to queries for that
-         zone.  Some servers issue SERVFAIL while others turn off the
-         'AA' bit in the answers.  The time of expiration is set in the
-         SOA record and is relative to the last successful refresh
-         between the master and the slave server.  There exists no
-         coupling between the signature expiration of RRSIGs in the zone
-         and the expire parameter in the SOA.
-         If the server serves a DNSSEC zone then 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 shorter than the signature validity period.
-         The consequence of an authoritative server not being able to
-         update a zone, whilst that zone includes expired signatures, is
-         that non-secure resolvers will continue to be able to resolve
-         data served by the particular slave servers while security
-         aware resolvers will experience problems because of answers
-         being marked as Bogus.
-         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 times out.
-         We also suggest that operators of nameservers that supply
-         secondary services develop 'watch dogs' to spot upcoming
-         signature expirations in zones they slave, 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 secondaries expire the zone; How quickly can I reach an
-         administrator of secondary servers to load a valid zone?  All
-         these arguments are not DNSSEC specific but may influence the
-         choice of your signature validity intervals.
-
-4.2.  Key Rollovers
-
-   A DNSSEC key cannot be used forever (see Section 3.3).  So key
-   rollovers -- or supercessions, as they are sometimes called -- are a
-   fact of life when using DNSSEC.  Zone administrators who are in the
-   process of rolling their keys have to take into account that data
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 14]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   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 occurs 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.
-
-4.2.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
-   key sets or newly generated signatures can be verified with the keys
-   still in caches.  One schema, described in Section 4.2.1.2, uses
-   double signatures; the other uses key pre-publication
-   (Section 4.2.1.1).  The pros, cons and recommendations are described
-   in Section 4.2.1.3.
-
-4.2.1.1.  Pre-publish Key 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 "pre-publish
-   rollover".This method has advantages in the case of a 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 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.
-
-   Pre-publish Key Rollover involves four stages as follows:
-
-    initial         new DNSKEY       new RRSIGs      DNSKEY removal
-
-    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)
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 15]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   initial: Initial version 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.
-   new DNSKEY: DNSKEY 11 is introduced into the key set.  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
-      key set.
-   new RRSIGs: At the "new RRSIGs" stage (SOA serial 2) 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 key set.  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 key set 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.
-   DNSKEY removal: DNSKEY 10 is removed from the zone.  The key set, now
-      only containing DNSKEY 1 and DNSKEY 11 is re-signed 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 "new DNSKEY"
-   as DNSKEY 12 and again a newer one, numbered 13, in "new DNSKEY
-   (II)":
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 16]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-       initial             new RRSIGs          new DNSKEY
-
-       SOA0                SOA1                SOA2
-       RRSIG10(SOA0)       RRSIG11(SOA1)       RRSIG11(SOA2)
-
-       DNSKEY1             DNSKEY1             DNSKEY1
-       DNSKEY10            DNSKEY10            DNSKEY11
-       DNSKEY11            DNSKEY11            DNSKEY12
-       RRSIG1(DNSKEY)      RRSIG1 (DNSKEY)     RRSIG1(DNSKEY)
-       RRSIG10(DNSKEY)     RRSIG11(DNSKEY)     RRSIG11(DNSKEY)
-
-
-       new RRSIGs (II)     new DNSKEY (II)
-
-       SOA3                SOA4
-       RRSIG12(SOA3)       RRSIG12(SOA4)
-
-       DNSKEY1             DNSKEY1
-       DNSKEY11            DNSKEY12
-       DNSKEY12            DNSKEY13
-       RRSIG1(DNSKEY)      RRSIG1(DNSKEY)
-       RRSIG12(DNSKEY)     RRSIG12(DNSKEY)
-
-
-   Pre-Publish Key Rollover, showing two rollovers.
-
-   Note that the key introduced in the "new DNSKEY" phase 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.
-
-4.2.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 "new DNSKEY" 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, requiring at least
-   the maximum Zone TTL.
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 17]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   Double Signature Zone Signing Key Rollover involves three stages as
-   follows:
-
-       initial             new DNSKEY         DNSKEY removal
-
-       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)
-
-   initial: Initial Version 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.
-   new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is
-      introduced into the key set and all the data in the zone is signed
-      with DNSKEY 10 and DNSKEY 11.  The rollover period will need to
-      continue 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.
-   DNSKEY removal: DNSKEY 10 is removed from the zone.  All the
-      signatures from DNSKEY 10 are removed from the zone.  The key set,
-      now only containing DNSKEY 11, is re-signed with DNSKEY 1.
-
-   At every instance, RRSIGs from the previous version of the zone can
-   be verified with the DNSKEY RRSet from the current version and the
-   other way around.  The data from the current version can be verified
-   with the data from the previous version of the zone.  The duration of
-   the "new DNSKEY" phase and the period between rollovers should be at
-   least the Maximum Zone TTL.
-
-   Making sure that the "new DNSKEY" phase lasts until the signature
-   expiration time of the data in initial version of the zone is
-   recommended.  This way all caches are cleared of the old signatures.
-   However, this duration 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.
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 18]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-4.2.1.3.  Pros and Cons of the Schemes
-
-   Pre-publish Key Rollover: This rollover does not involve signing the
-      zone data twice.  Instead, before the actual rollover, the new key
-      is published in the key set and thus available for cryptanalysis
-      attacks.  A small disadvantage is that this process requires four
-      steps.  Also the pre-publish scheme involves more parental work
-      when used for KSK rollovers as explained in Section 4.2.3.
-   Double Signature Zone-signing Key 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.
-
-4.2.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 key
-   set) in caches can be verified with a new key set and vice versa.
-   Since only the key set is signed with a KSK, zone size considerations
-   do not apply.
-
-
-       initial        new DNSKEY        DS change       DNSKEY removal
-     Parent:
-       SOA0           -------->         SOA1            -------->
-       RRSIGpar(SOA0) -------->         RRSIGpar(SOA1)  -------->
-       DS1            -------->         DS2             -------->
-       RRSIGpar(DS)   -------->         RRSIGpar(DS)    -------->
-
-
-     Child:
-       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)
-
-   Stages of Deployment for Key Signing Key Rollover.
-
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 19]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   initial: Initial version 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.
-   new DNSKEY: During the "new DNSKEY" 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 parent's zone, the
-      zone administrator has to wait at least TTL_DS to make sure that
-      the old DS RR has expired from caches.
-   DS change: The parent replaces DS1 with DS2.
-   DNSKEY removal: 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.  An
-   alternative mechanism has been considered.  Using an established
-   trust relation, the interaction can be performed in-band, and the
-   removal of the keys by the child can possibly be signaled by the
-   parent.  In this mechanism there are periods where there are two DS
-   RRs at the parent.  Since at the moment of writing the protocol for
-   this interaction has not been developed, further discussion is out of
-   scope for this document.
-
-4.2.3.  Difference Between ZSK and KSK Rollovers
-
-   Note that KSK rollovers and ZSK rollovers are different in the sense
-   that a KSK rollover requires interaction with the parent (and
-   possibly replacing of trust anchors) and the ensuing delay while
-   waiting for it.
-
-   A zone key rollover can be handled in two different ways: pre-publish
-   (Section Section 4.2.1.1) and double signature (Section
-   Section 4.2.1.2).
-
-   As the KSK is used to validate the key set and because the KSK is not
-   changed during a ZSK rollover, a cache is able to validate the new
-   key set of the zone.  The pre-publish method would also work for a
-   KSK rollover.  The records that are to be pre-published are the
-   parental DS RRs.  The pre-publish method has some drawbacks for KSKs.
-   We first describe the rollover scheme and then indicate these
-   drawbacks.
-
-
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 20]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-     initial         new DS           new DNSKEY      DS/DNSKEY removal
-   Parent:
-     SOA0            SOA1             -------->       SOA2
-     RRSIGpar(SOA0)  RRSIGpar(SOA1)   -------->       RRSIGpar(SOA2)
-     DS1             DS1              -------->       DS2
-                     DS2              -------->
-     RRSIGpar(DS)    RRSIGpar(DS)     -------->       RRSIGpar(DS)
-
-
-
-   Child:
-     SOA0            -------->        SOA1            SOA1
-     RRSIG10(SOA0)   -------->        RRSIG10(SOA1)   RRSIG10(SOA1)
-                     -------->
-     DNSKEY1         -------->        DNSKEY2         DNSKEY2
-                     -------->
-     DNSKEY10        -------->        DNSKEY10        DNSKEY10
-     RRSIG1 (DNSKEY) -------->        RRSIG2(DNSKEY)  RRSIG2 (DNSKEY)
-     RRSIG10(DNSKEY) -------->        RRSIG10(DNSKEY) RRSIG10(DNSKEY)
-
-   Stages of Deployment for a Pre-publish Key Signing Key rollover.
-
-   When the child zone wants to roll it notifies the parent during the
-   "new DS" phase and submits the new key (or the corresponding DS) to
-   the parent.  The parent publishes DS1 and DS2, pointing to DNSKEY1
-   and DNSKEY2 respectively.  During the rollover ("new DNSKEY" phase),
-   which can take place as soon as the new DS set propagated through the
-   DNS, the child replaces DNSKEY1 with DNSKEY2.  Immediately after that
-   ("DS/DNSKEY removal" phase) it can notify the parent that the old DS
-   record can be deleted.
-
-   The drawbacks of this scheme are that during the "new DS" phase the
-   parent cannot verify the match between the DS2 RR and DNSKEY2 using
-   the DNS -- as DNSKEY2 is not yet published.  Besides, we introduce a
-   "security lame" key (See Section 4.4.3).  Finally the child-parent
-   interaction consists of two steps.  The "double signature" method
-   only needs one interaction.
-
-4.2.4.  Automated Key Rollovers
-
-   As keys must be renewed periodically, there is some motivation to
-   automate the rollover process.  Consider that:
-
-   o  ZSK rollovers are easy to automate as only the child zone is
-      involved.
-   o  A KSK rollover needs interaction between parent and child.  Data
-      exchange is needed to provide the new keys to the parent,
-      consequently, this data must be authenticated and integrity must
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 21]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-      be guaranteed in order to avoid attacks on the rollover.
-
-4.3.  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.
-
-   When the private material of one of your keys is compromised it can
-   be used for as long as a valid trust chain exists.  A trust chain
-   remains intact for:
-   o  as long as a signature over the compromised key in the trust 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 generally the hardest to
-      update).
-
-   While a trust chain to your compromised key exists, your name-space
-   is vulnerable to abuse by anyone who has obtained illegitimate
-   possession of the 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
-   trust 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.
-
-4.3.1.  KSK Compromise
-
-   A zone containing a DNSKEY RRSet with a compromised KSK is vulnerable
-   as long as the compromised KSK is configured as trust anchor or a
-   parental DS points to it.
-
-   A compromised KSK can be used to sign the key set of an attacker's
-   zone.  That zone could be used to poison the DNS.
-
-   Therefore when the KSK has been compromised, the trust anchor or the
-   parental DS, should be replaced as soon as possible.  It is local
-   policy whether to break the trust chain during the emergency
-   rollover.  The trust chain would be broken when the compromised KSK
-   is removed from the child's zone while the parent still has a DS
-   pointing to the compromised KSK (the assumption is that there is only
-   one DS at the parent.  If there are multiple DSs this does not apply
-   -- however the chain of trust of this particular key is broken).
-
-   Note that an attacker's zone still uses the compromised KSK and the
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 22]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   presence of a parental DS would cause the data in this zone to appear
-   as valid.  Removing the compromised key would cause the attacker's
-   zone to appear as valid and the child's zone as Bogus.  Therefore we
-   advise not to remove the KSK before the parent has a DS to a new KSK
-   in place.
-
-4.3.1.1.  Keeping the Chain of Trust Intact
-
-   If we follow this advice the timing of the replacement of the KSK is
-   somewhat critical.  The goal is to remove the compromised KSK as soon
-   as the new DS RR is available at the parent.  And also make sure that
-   the signature made with a new KSK over the key set with the
-   compromised KSK in it expires just after the new DS appears at the
-   parent.  Thus removing the old cruft in one swoop.
-
-   The procedure is as follows:
-   1.  Introduce a new KSK into the key set, keep the compromised KSK in
-       the key set.
-   2.  Sign the key set, with a short validity period.  The validity
-       period should expire shortly after the DS is expected to appear
-       in the parent and the old DSs have expired from caches.
-   3.  Upload the DS for this new key to the parent.
-   4.  Follow the procedure of the regular KSK rollover: Wait for the DS
-       to appear in the authoritative servers and then wait as long as
-       the TTL of the old DS RRs.  If necessary re-sign the DNSKEY RRSet
-       and modify/extend the expiration time.
-   5.  Remove the compromised DNSKEY RR from the zone and re-sign the
-       key set using your "normal" validity interval.
-
-   An additional danger of a key compromise is that the compromised key
-   could be used to facilitate a legitimate DNSKEY/DS rollover and/or
-   nameserver changes at the parent.  When that happens the domain may
-   be in dispute.  An authenticated out-of-band and secure notify
-   mechanism to contact a parent is needed in this case.
-
-   Note that this is only a problem when the DNSKEY and or DS records
-   are used for authentication at the parent.
-
-4.3.1.2.  Breaking the Chain of Trust
-
-   There are two methods to break the chain of trust.  The first method
-   causes the child zone to appear as 'Bogus' to validating resolvers.
-   The other causes the the child zone to appear as 'insecure'.  These
-   are described below.
-
-   In the method that causes the child zone to appear as 'Bogus' to
-   validating resolvers, the child zone replaces the current KSK with a
-   new one and resigns the key set.  Next it sends the DS of the new key
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 23]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   to the parent.  Only after the parent has placed the new DS in the
-   zone, the child's chain of trust is repaired.
-
-   An alternative method of breaking the chain of trust is by removing
-   the DS RRs from the parent zone altogether.  As a result the child
-   zone would become insecure.
-
-4.3.2.  ZSK Compromise
-
-   Primarily because there is no parental interaction required when a
-   ZSK is compromised, the situation is less severe than with a KSK
-   compromise.  The zone must still be re-signed 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 of the old
-   compromised key may lead to verification problems.  Also note that as
-   long as the RRSIG over the compromised ZSK is not expired the zone
-   may be still at risk.
-
-4.3.3.  Compromises of Keys Anchored in Resolvers
-
-   A key can also be pre-configured in resolvers.  For instance, if
-   DNSSEC is successfully deployed the root key may be pre-configured in
-   most security aware resolvers.
-
-   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.
-
-   End-users faced with the task of updating an anchored key should
-   always validate the new key.  New keys should be authenticated out-
-   of-band, for example, looking them up on an SSL secured announcement
-   website.
-
-4.4.  Parental Policies
-
-4.4.1.  Initial Key Exchanges and Parental Policies Considerations
-
-   The initial key exchange is always subject to the policies set by the
-   parent.  When designing a key exchange policy one should take into
-   account that the authentication and authorization mechanisms used
-   during a key exchange should be as strong as the authentication and
-   authorization mechanisms used for the exchange of delegation
-   information between parent and child.  I.e. there is no implicit need
-   in DNSSEC to make the authentication process stronger than it was in
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 24]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   DNS.
-
-   Using the DNS itself as the source for the actual DNSKEY material,
-   with an out-of-band check on the validity of the DNSKEY, has the
-   benefit that it reduces the chances of user error.  A DNSKEY query
-   tool can make use of the SEP bit [3] to select the proper key from a
-   DNSSEC key set; 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 chain of trust remains intact
-   once the parent publishes the DS RR indicating the child is secure.
-
-   Note: the out-of-band verification is still needed when the key-
-   material is fetched via the DNS.  The parent can never be sure
-   whether the DNSKEY RRs have been spoofed or not.
-
-4.4.2.  Storing Keys or Hashes?
-
-   When designing a registry system one should consider which of the
-   DNSKEYs and/or the corresponding DSs to store.  Since a child zone
-   might wish to have a DS published using a message digest algorithm
-   not yet understood by the registry, the registry can't count on being
-   able to generate the DS record from a raw DNSKEY.  Thus, we recommend
-   that registry systems at least support storing DS records.
-
-   It may also be useful to store DNSKEYs, since having them may help
-   during troubleshooting and, as long as the child's chosen message
-   digest is supported, the overhead of generating DS records from them
-   is minimal.  Having an out-of-band mechanism, such as a registry
-   directory (e.g.  Whois), to find out which keys are used to generate
-   DS Resource Records for specific owners and/or zones may also help
-   with troubleshooting.
-
-   The storage considerations also relate to the design of the customer
-   interface and the method by which data is transferred between
-   registrant and registry; Will the child zone administrator be able to
-   upload DS RRs with unknown hash algorithms or does the interface only
-   allow DNSKEYs?  In the registry-registrar model one can use the
-   DNSSEC EPP protocol extension [16] which allows transfer of DS RRs
-   and optionally DNSKEY RRs.
-
-4.4.3.  Security Lameness
-
-   Security Lameness is defined as what happens when a parent has a DS
-   RR pointing to a non-existing DNSKEY RR.  When this happens the
-   child's zone may be marked as "Bogus" by verifying DNS clients.
-
-   As part of a comprehensive delegation check the parent could, at key
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 25]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   exchange time, verify that the child's key is actually configured in
-   the DNS.  However if a parent does not understand the hashing
-   algorithm used by child the parental checks are limited to only
-   comparing the key id.
-
-   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. removing a DS RR) will
-   take time to propagate through the DNS.
-
-4.4.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 minimizes 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
-   validity periods longer than 2 days.  We recommend an absolute
-   minimum for a DS signature validity period of a few days.
-
-   The maximum signature validity period of the DS record depends on how
-   long child zones are willing to be vulnerable after a key compromise.
-   On the other hand shortening the DS signature validity interval
-   increases the operational risk for the parent.  Therefore the parent
-   may have policy to use a signature validity interval that is
-   considerably longer than the child would hope for.
-
-   A compromise between the operational constraints of the parent and
-   minimizing damage for the child may result in a DS signature validity
-   period somewhere between the order of a week to order of months.
-
-   In addition to the signature validity period, which sets a lower
-   bound on the number of times the zone owner will need to sign the
-   zone data and which sets an upper bound to the time a child is
-   vulnerable after key compromise, there is the TTL value on the DS
-   RRs.  Shortening the TTL means that the authoritative servers will
-   see more queries.  But on the other hand, a short TTL lowers the
-   persistence of DS RRSets in caches thereby increases the speed with
-   which updated DS RRSets propagate through the DNS.
-
-
-5.  IANA Considerations
-
-   This overview document introduces no new IANA considerations.
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 26]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-6.  Security Considerations
-
-   DNSSEC adds data integrity to the DNS.  This document tries to assess
-   the operational considerations to maintain 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
-
-   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 were the original
-   contributors of the ideas we would like to acknowledge people who
-   were actively involved in the compilation of this document.  In
-   random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael
-   Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette
-   Olivier Courtay, Sam Weiler, Jelte Jansen, Niall O'Reilly, Holger
-   Zuleger, Ed Lewis, Hilarie Orman, Marcos Sanz and Peter Koch.
-
-   Some material in this document has been copied from RFC 2541 [12].
-
-   Mike StJohns designed the key exchange between parent and child
-   mentioned in the last paragraph of Section 4.2.2
-
-   Section 4.2.4 was supplied by G. Guette and O. Courtay.
-
-   Emma Bretherick, Adrian Bedford and Lindy Foster corrected many of
-   the spelling and style issues.
-
-   Kolkman and Gieben take the blame for introducing all miscakes(SIC).
-
-   Kolkman was employed by the RIPE NCC while working on this document.
-
-
-8.  References
-
-8.1.  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]  Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System KEY
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 27]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-        (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
-        RFC 3757, May 2004.
-
-   [4]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033,
-        March 2005.
-
-   [5]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Resource Records for the DNS Security Extensions", RFC 4034,
-        March 2005.
-
-   [6]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions",
-        RFC 4035, March 2005.
-
-8.2.  Informative References
-
-   [7]   Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
-         August 1996.
-
-   [8]   Vixie, P., "A Mechanism for Prompt Notification of Zone Changes
-         (DNS NOTIFY)", RFC 1996, August 1996.
-
-   [9]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-   [10]  Eastlake, D., "Secure Domain Name System Dynamic Update",
-         RFC 2137, April 1997.
-
-   [11]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
-         RFC 2308, March 1998.
-
-   [12]  Eastlake, D., "DNS Security Operational Considerations",
-         RFC 2541, March 1999.
-
-   [13]  Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
-         RFC 3658, December 2003.
-
-   [14]  Orman, H. and P. Hoffman, "Determining Strengths For Public
-         Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766,
-         April 2004.
-
-   [15]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
-         Requirements for Security", BCP 106, RFC 4086, June 2005.
-
-   [16]  Hollenbeck, S., "Domain Name System (DNS) Security Extensions
-         Mapping for the Extensible Provisioning Protocol (EPP)",
-         RFC 4310, December 2005.
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 28]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   [17]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
-         Sizes", The Journal of Cryptology 14 (255-293), 2001.
-
-   [18]  Schneier, B., "Applied Cryptography: Protocols, Algorithms, and
-         Source Code in C", ISBN (hardcover) 0-471-12845-7, ISBN
-         (paperback) 0-471-59756-2, Published by John Wiley & Sons Inc.,
-         1996.
-
-   [19]  Rose, S., "NIST DNSSEC workshop notes", June 2001.
-
-   [20]  Jansen, J., "Use of RSA/SHA-256 DNSKEY and RRSIG Resource
-         Records in DNSSEC", draft-ietf-dnsext-dnssec-rsasha256-00.txt
-         (work in progress), January 2006.
-
-   [21]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
-         Resource Records (RRs)", draft-ietf-dnsext-ds-sha256-04.txt
-         (work in progress), January 2006.
-
-
-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.
-
-   Anchored Key: A DNSKEY configured in resolvers around the globe.
-      This key is hard to update, hence the term anchored.
-   Bogus: Also see Section 5 of [4].  An RRSet in DNSSEC is marked
-      "Bogus" when a signature of a RRSet does not validate against a
-      DNSKEY.
-   Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is used
-      exclusively for signing the apex key set.  The fact that a key is
-      a KSK is only relevant to the signing tool.
-   Key size: The term 'key size' can be substituted by 'modulus size'
-      throughout the document.  It is mathematically more correct to use
-      modulus size, but as this is a document directed at operators we
-      feel more at ease with the term key size.
-   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 (mathematically related) 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.
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 29]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   Key Rollover: A key rollover (also called key supercession in some
-      environments) is the act of replacing one key pair by another at
-      the end of a key effectivity period.
-   Secure Entry Point key or SEP Key: A KSK that has a parental DS
-      record pointing to it or is configured as a trust anchor.
-      Although not required by the protocol we recommend that the SEP
-      flag [3] is set on these keys.
-   Self-signature: This is only applies to signatures over DNSKEYs; a
-      signature made with DNSKEY x, over DNSKEY x is called a self-
-      signature.  Note: without further information self-signatures
-      convey no trust, they are useful to check the authenticity of the
-      DNSKEY, i.e. they can be used as a hash.
-   Singing the Zone File: The term used for the event where an
-      administrator joyfully signs its zone file while producing melodic
-      sound patterns.
-   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.
-   Zone Signing Key or 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.
-   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 caches, here
-   follows the "HOWTO".
-   Step 0: The preparation: Create two keys and publish both in your key
-      set.  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.
-      The protocol does not provide for attributes to mark a key as
-      active or published.  This is something you have to do on your
-      own, through the use of a notebook or key management tool.
-   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".
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 30]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   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 DNSKEYx, where x is a number or an
-      identifier, 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.0.2.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".
-   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: SOAs are represented as SOAx, where x is the
-      serial number.
-   Using this notation the following signed zone:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 31]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   example.net.      86400  IN SOA  ns.example.net. bert.example.net. (
-                            2006022100   ; serial
-                            86400        ; refresh (  24 hours)
-                            7200         ; retry   (   2 hours)
-                            3600000      ; expire  (1000 hours)
-                            28800 )      ; minimum (   8 hours)
-                     86400  RRSIG   SOA 5 2 86400 20130522213204 (
-                                  20130422213204 14 example.net.
-                                  cmL62SI6iAX46xGNQAdQ... )
-                     86400  NS      a.iana-servers.net.
-                     86400  NS      b.iana-servers.net.
-                     86400  RRSIG   NS 5 2 86400 20130507213204 (
-                                  20130407213204 14 example.net.
-                                  SO5epiJei19AjXoUpFnQ ... )
-                     86400  DNSKEY  256 3 5 (
-                                  EtRB9MP5/AvOuVO0I8XDxy0... ) ; id = 14
-                     86400  DNSKEY  257 3 5 (
-                                  gsPW/Yy19GzYIY+Gnr8HABU... ) ; id = 15
-                     86400  RRSIG   DNSKEY 5 2 86400 20130522213204 (
-                                  20130422213204 14 example.net.
-                                  J4zCe8QX4tXVGjV4e1r9... )
-                     86400  RRSIG   DNSKEY 5 2 86400 20130522213204 (
-                                  20130422213204 15 example.net.
-                                  keVDCOpsSeDReyV6O... )
-                     86400  RRSIG   NSEC 5 2 86400 20130507213204 (
-                                  20130407213204 14 example.net.
-                                  obj3HEp1GjnmhRjX... )
-   a.example.net.    86400  IN TXT  "A label"
-                     86400  RRSIG   TXT 5 3 86400 20130507213204 (
-                                  20130407213204 14 example.net.
-                                  IkDMlRdYLmXH7QJnuF3v... )
-                     86400  NSEC    b.example.com. TXT RRSIG NSEC
-                     86400  RRSIG   NSEC 5 3 86400 20130507213204 (
-                                  20130407213204 14 example.net.
-                                  bZMjoZ3bHjnEz0nIsPMM... )
-                     ...
-
-   is reduced to the following representation:
-
-       SOA2006022100
-       RRSIG14(SOA2006022100)
-       DNSKEY14
-       DNSKEY15
-
-       RRSIG14(KEY)
-       RRSIG15(KEY)
-
-   The rest of the zone data has the same signature as the SOA record,
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 32]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   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.
-
-   $Id: draft-ietf-dnsop-dnssec-operational-practices.xml,v 1.31.2.14
-   2005/03/21 15:51:41 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
-
-D.3.  draft-ietf-dnsop-dnssec-operational-practices-02
-
-   Style and errors corrected.
-
-   Added Automatic rollover requirements from I-D.ietf-dnsop-key-
-   rollover-requirements.
-
-D.4.  draft-ietf-dnsop-dnssec-operational-practices-03
-
-   Added the definition of Key effectivity period and used that term
-   instead of Key validity period.
-
-   Modified the order of the sections, based on a suggestion by Rip
-   Loomis.
-
-   Included parts from RFC 2541 [12].  Most of its ground was already
-   covered.  This document obsoletes RFC 2541 [12].  Section 3.1.2
-   deserves some review as it in contrast to RFC 2541 does _not_ give
-   recomendations about root-zone keys.
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 33]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-   added a paragraph to Section 4.4.4
-
-D.5.  draft-ietf-dnsop-dnssec-operational-practices-04
-
-   Somewhat more details added about the pre-publish KSK rollover.  Also
-   moved that subsection down a bit.
-
-   Editorial and content nits that came in during wg last call were
-   fixed.
-
-D.6.  draft-ietf-dnsop-dnssec-operational-practices-05
-
-   Applied some another set of comments that came in _after_ the the
-   WGLC.
-
-   Applied comments from Hilarie Orman and made a referece to RFC 3766.
-   Deleted of a lot of key length discussion and took over the
-   recommendations from RFC 3766.
-
-   Reworked all the heading of the rollover figures
-
-D.7.  draft-ietf-dnsop-dnssec-operational-practices-06
-
-   One comment from Scott Rose applied.
-
-   Marcos Sanz gave a lots of editorial nits.  Almost all are
-   incorporated.
-
-D.8.  draft-ietf-dnsop-dnssec-operational-practices-07
-
-   Peter Koch's comments applied.
-
-   SHA-1/SHA-256 remarks added
-
-D.9.  draft-ietf-dnsop-dnssec-operational-practices-08
-
-   IESG comments applied.  Added headers and some captions to the tables
-   and applied all the nits.
-
-   IESG DISCUSS comments applied
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 34]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-Authors' Addresses
-
-   Olaf M. Kolkman
-   NLnet Labs
-   Kruislaan 419
-   Amsterdam  1098 VA
-   The Netherlands
-
-   Email: olaf@nlnetlabs.nl
-   URI:   http://www.nlnetlabs.nl
-
-
-   Miek Gieben
-   NLnet Labs
-   Kruislaan 419
-   Amsterdam  1098 VA
-   The Netherlands
-
-   Email: miek@nlnetlabs.nl
-   URI:   http://www.nlnetlabs.nl
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 35]
-
-Internet-Draft        DNSSEC Operational Practices            March 2006
-
-
-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 (2006).  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.
-
-
-
-
-Kolkman & Gieben        Expires September 7, 2006              [Page 36]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt
deleted file mode 100644
index bcd0d14..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt
+++ /dev/null
@@ -1,396 +0,0 @@
-
-
-
-
-
-
-INTERNET-DRAFT                                                  D. Senie
-Category: BCP                                     Amaranth Networks Inc.
-Expires in six months                                          July 2005
-
-               Encouraging the use of DNS IN-ADDR Mapping
-		    draft-ietf-dnsop-inaddr-required-07.txt 
-
-Status of this Memo
-
-   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 becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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
-
-   Mapping of addresses to names has been a feature of DNS.  Many sites,
-   implement it, many others don't.  Some applications attempt to use it
-   as a part of a security strategy. The goal of this document is to
-   encourage proper deployment of address to name mappings, and provide
-   guidance for their use.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society. (2005)
-
-1. Introduction
-
-   The Domain Name Service has provision for providing mapping of IP
-   addresses to host names. It is common practice to ensure both name to
-   address, and address to name mappings are provided for networks. This
-   practice, while documented, has never been required, though it is
-   generally encouraged.  This document both encourages the presence of
-
-
-
-Senie                                                           [Page 1]
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
-
-
-   these mappings and discourages reliance on such mappings for security
-   checks.
-
-   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].
-
-2. Discussion
-
-
-   From the early days of the Domain Name Service [RFC883] a special
-   domain has been set aside for resolving mappings of IP addresses to
-   domain names.  This was refined in [RFC1035], describing the .IN-
-   ADDR.ARPA in use today.  For the in the IPv6 address space, .IP6.ARPA
-   was added [RFC3152]. This document uses IPv4 CIDR block sizes and
-   allocation strategy where there are differences and uses IPv4
-   terminology.  Aside from these differences, this document can and
-   should be applied to both address spaces.
-
-   The assignment of blocks of IP address space was delegated to three
-   regional registries. Guidelines for the registries are specified in
-   [RFC2050], which requires regional registries to maintain IN-ADDR
-   records on the large blocks of space issued to ISPs and others.
-
-   ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger
-   allocations. For smaller allocations, ARIN can provide IN-ADDR for
-   /24 and shorter prefixes. [ARIN].  APNIC provides methods for ISPs to
-   update IN-ADDR, however the present version of its policy document
-   for IPv4 [APNIC] dropped the IN-ADDR requirements that were in draft
-   copies of this document. As of this writing, it appears APNIC has no
-   actual policy on IN-ADDR.  RIPE appears to have the strongest policy
-   in this area [RIPE302] indicating Local Internet Registries should
-   provide IN-ADDR services, and delegate those as appropriate when
-   address blocks are delegated.
-
-   As we can see, the regional registries have their own policies for
-   recommendations and/or requirements for IN-ADDR maintenance. It
-   should be noted, however, that many address blocks were allocated
-   before the creation of the regional registries, and thus it is
-   unclear whether any of the policies of the registries are binding on
-   those who hold blocks from that era.
-
-   Registries allocate address blocks on CIDR [RFC1519] boundaries.
-   Unfortunately the IN-ADDR zones are based on classful allocations.
-   Guidelines [RFC2317] for delegating on non-octet-aligned boundaries
-   exist, but are not always implemented.
-
-3. Examples of impact of missing IN-ADDR
-
-
-
-Senie                                                           [Page 2]
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
-
-
-   These are some examples of problems that may be introduced by
-   reliance on IN-ADDR.
-
-   Some applications use DNS lookups for security checks. To ensure
-   validity of claimed names, some applications will look up IN-ADDR
-   records to get names, and then look up the resultant name to see if
-   it maps back to the address originally known. Failure to resolve
-   matching names is seen as a potential security concern.
-
-   Some FTP sites will flat-out reject users, even for anonymous FTP, if
-   the IN-ADDR lookup fails or if the result of the IN-ADDR lookup when
-   itself resolved, does not match. Some Telnet servers also implement
-   this check.
-
-   Web sites are in some cases using IN-ADDR checks to verify whether
-   the client is located within a certain geopolitical entity. This
-   approach has been employed for downloads of crypto software, for
-   example, where export of that software is prohibited to some locales.
-   Credit card anti-fraud systems also use these methods for geographic
-   placement purposes.
-
-   The popular TCP Wrappers program found on most Unix and Linux systems
-   has options to enforce IN-ADDR checks and to reject any client that
-   does not resolve. This program also has a way to check to see that
-   the name given by a PTR record then resolves back to the same IP
-   address. This method provdes more comfort but no appreciable
-   additional security.
-
-   Some anti-spam (anti junk email) systems use IN-ADDR to verify the
-   presence of a PTR record, or validate the PTR value points back to
-   the same address.
-
-   Many web servers look up the IN-ADDR of visitors to be used in log
-   analysis.  This adds to the server load, but in the case of IN-ADDR
-   unavailability, it can lead to delayed responses for users.
-
-   Traceroutes with descriptive IN-ADDR naming proves useful when
-   debugging problems spanning large areas. When this information is
-   missing, the traceroutes take longer, and it takes additional steps
-   to determine that network is the cause of problems.
-
-   Wider-scale implementation of IN-ADDR on dialup, wireless access and
-   other such client-oriented portions of the Internet would result in
-   lower latency for queries (due to lack of negative caching), and
-   lower name server load and DNS traffic.
-
-4. Recommendations
-
-
-
-
-Senie                                                           [Page 3]
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
-
-
-   4.1 Delegation Recommendations
-
-
-   Regional Registries and any Local Registries to whom they delegate
-   should establish and convey a policy to those to whom they delegate
-   blocks that IN-ADDR mappings are recommended.  Policies should
-   recommend those receiving delegations to provide IN-ADDR service
-   and/or delegate to downstream customers.
-
-   Network operators should define and implement policies and procedures
-   which delegate IN-ADDR to their clients who wish to run their own IN-
-   ADDR DNS services, and provide IN-ADDR services for those who do not
-   have the resources to do it themselves.  Delegation mechanisms should
-   permit the downstream customer to implement and comply with IETF
-   recommendations application of IN-ADDR to CIDR [RFC2317].
-
-   All IP address space assigned and in use should be resolved by IN-
-   ADDR records. All PTR records must use canonical names.
-
-   All IP addresses in use within a block should have an IN-ADDR
-   mapping. Those addresses not in use, and those that are not valid for
-   use (zeros or ones broadcast addresses within a CIDR block) need not
-   have mappings.
-
-   It should be noted that due to CIDR, many addresses that appear to be
-   otherwise valid host addresses may actually be zeroes or ones
-   broadcast addresses. As such, attempting to audit a site's degree of
-   compliance may only be done with knowledge of the internal subnet
-   architecture of the site.  It can be assumed, however, any host that
-   originates an IP packet necessarily will have a valid host address,
-   and must therefore have an IN-ADDR mapping.
-
-4.2 Application Recommendations
-
-
-   Applications SHOULD NOT rely on IN-ADDR for proper operation. The use
-   of IN-ADDR, sometimes in conjunction with a lookup of the name
-   resulting from the PTR record provides no real security, can lead to
-   erroneous results and generally just increases load on DNS servers.
-   Further, in cases where address block holders fail to properly
-   configure IN-ADDR, users of those blocks are penalized.
-
-5. Security Considerations
-
-   This document has no negative impact on security. While it could be
-   argued that lack of PTR record capabilities provides a degree of
-   anonymity, this is really not valid. Trace routes, whois lookups and
-   other sources will still provide methods for discovering identity.
-
-
-
-Senie                                                           [Page 4]
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
-
-
-   By recommending applications avoid using IN-ADDR as a security
-   mechanism this document points out that this practice, despite its
-   use by many applications, is an ineffective form of security.
-   Applications should use better mechanisms of authentication.
-
-6. IANA Considerations
-
-   There are no IANA considerations for this document.
-
-7. References
-
-7.1 Normative References
-
-   [RFC883] P.V. Mockapetris, "Domain names: Implementation
-   specification," RFC883, November 1983.
-
-   [RFC1035] P.V. Mockapetris, "Domain Names: Implementation
-   Specification," RFC 1035, November 1987.
-
-   [RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR):
-   an Address Assignment and Aggregation Strategy," RFC 1519, September
-   1993.
-
-   [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
-   RFC 2026, BCP 9, October 1996.
-
-   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
-   Requirement Levels", RFC 2119, BCP 14, March 1997.
-
-   [RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation
-   Guidelines", RFC2050, BCP 12, Novebmer 1996.
-
-   [RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation,"
-   RFC 2317, March 1998.
-
-   [RFC3152] R. Bush, "Delegation of IP6.ARPA," RFC 3152, BCP 49, August
-   2001.
-
-7.2 Informative References
-
-   [ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date
-   unknown, http://www.arin.net/regserv/initial-isp.html
-
-   [APNIC] "Policies For IPv4 Address Space Management in the Asia
-   Pacific Region," APNIC-086, 13 January 2003.
-
-   [RIPE302] "Policy for Reverse Address Delegation of IPv4 and IPv6
-   Address Space in the RIPE NCC Service Region", RIPE-302, April 26,
-
-
-
-Senie                                                           [Page 5]
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
-
-
-   2004. http://www.ripe.net//ripe/docs/rev-del.html
-
-
-
-8. Acknowledgements
-
-   Thanks to Peter Koch and Gary Miller for their input, and to many
-   people who encouraged me to write this document.
-
-9. Author's Address
-
-   Daniel Senie
-   Amaranth Networks Inc.
-   324 Still River Road
-   Bolton, MA 01740
-
-   Phone: (978) 779-5100
-
-   EMail: dts@senie.com
-
-10.  Full Copyright Statement
-
-      Copyright (C) The Internet Society (2005).
-
-      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.
-
-Intellectual Property
-
-      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.
-
-
-
-
-Senie                                                           [Page 6]
-
-Internet-Draft Encouraging the use of DNS IN-ADDR Mapping      July 2005
-
-
-      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.
-
-      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/1id-abstracts.html
-
-      The list of Internet-Draft Shadow Directories can be
-      accessed at http://www.ietf.org/shadow.html
-
-Acknowledgement
-
-      Funding for the RFC Editor function is currently provided by the
-      Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Senie                                                           [Page 7]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt
deleted file mode 100644
index bf2afcd..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt
+++ /dev/null
@@ -1,1848 +0,0 @@
-
-
-
-DNS Operations WG                                          J. Jeong, Ed.
-Internet-Draft                              ETRI/University of Minnesota
-Expires: November 6, 2005                                    May 5, 2005
-
-
-      IPv6 Host Configuration of DNS Server Information Approaches
-             draft-ietf-dnsop-ipv6-dns-configuration-06.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 November 6, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-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 the
-   deployment scenarios in four kinds of networks, such as ISP,
-   Enterprise, 3GPP, and Unmanaged networks, considering multi-solution
-   resolution.  Therefore, this document will give the audience a
-
-
-
-Jeong                   Expires November 6, 2005                [Page 1]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   guideline for IPv6 host DNS configuration.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005                [Page 2]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
-   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
-   3.  IPv6 DNS Configuration Approaches  . . . . . . . . . . . . . .  7
-     3.1   RA Option  . . . . . . . . . . . . . . . . . . . . . . . .  7
-       3.1.1   Advantages . . . . . . . . . . . . . . . . . . . . . .  8
-       3.1.2   Disadvantages  . . . . . . . . . . . . . . . . . . . .  8
-       3.1.3   Observations . . . . . . . . . . . . . . . . . . . . .  9
-     3.2   DHCPv6 Option  . . . . . . . . . . . . . . . . . . . . . .  9
-       3.2.1   Advantages . . . . . . . . . . . . . . . . . . . . . . 11
-       3.2.2   Disadvantages  . . . . . . . . . . . . . . . . . . . . 12
-       3.2.3   Observations . . . . . . . . . . . . . . . . . . . . . 12
-     3.3   Well-known Anycast Addresses . . . . . . . . . . . . . . . 12
-       3.3.1   Advantages . . . . . . . . . . . . . . . . . . . . . . 13
-       3.3.2   Disadvantages  . . . . . . . . . . . . . . . . . . . . 14
-       3.3.3   Observations . . . . . . . . . . . . . . . . . . . . . 14
-   4.  Interworking among IPv6 DNS Configuration Approaches . . . . . 15
-   5.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 16
-     5.1   ISP Network  . . . . . . . . . . . . . . . . . . . . . . . 16
-       5.1.1   RA Option Approach . . . . . . . . . . . . . . . . . . 16
-       5.1.2   DHCPv6 Option Approach . . . . . . . . . . . . . . . . 17
-       5.1.3   Well-known Anycast Addresses Approach  . . . . . . . . 17
-     5.2   Enterprise Network . . . . . . . . . . . . . . . . . . . . 17
-     5.3   3GPP Network . . . . . . . . . . . . . . . . . . . . . . . 18
-       5.3.1   Currently Available Mechanisms and Recommendations . . 19
-       5.3.2   RA Extension . . . . . . . . . . . . . . . . . . . . . 19
-       5.3.3   Stateless DHCPv6 . . . . . . . . . . . . . . . . . . . 20
-       5.3.4   Well-known Addresses . . . . . . . . . . . . . . . . . 21
-       5.3.5   Recommendations  . . . . . . . . . . . . . . . . . . . 21
-     5.4   Unmanaged Network  . . . . . . . . . . . . . . . . . . . . 22
-       5.4.1   Case A: Gateway does not provide IPv6 at all . . . . . 22
-       5.4.2   Case B: A dual-stack gateway connected to a
-               dual-stack ISP . . . . . . . . . . . . . . . . . . . . 22
-       5.4.3   Case C: A dual-stack gateway connected to an
-               IPv4-only ISP  . . . . . . . . . . . . . . . . . . . . 22
-       5.4.4   Case D: A gateway connected to an IPv6-only ISP  . . . 23
-   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
-     6.1   RA Option  . . . . . . . . . . . . . . . . . . . . . . . . 25
-     6.2   DHCPv6 Option  . . . . . . . . . . . . . . . . . . . . . . 25
-     6.3   Well-known Anycast Addresses . . . . . . . . . . . . . . . 25
-   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26
-   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
-     9.1   Normative References . . . . . . . . . . . . . . . . . . . 29
-     9.2   Informative References . . . . . . . . . . . . . . . . . . 29
-       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 31
-   A.  Link-layer Multicast Acknowledgements for RA Option  . . . . . 32
-
-
-
-Jeong                   Expires November 6, 2005                [Page 3]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-       Intellectual Property and Copyright Statements . . . . . . . . 33
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005                [Page 4]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-1.  Introduction
-
-   Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address
-   Autoconfiguration provide the ways to configure either fixed or
-   mobile nodes with one or more IPv6 addresses, default routes and some
-   other parameters [3][4].  To support the 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 the 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 a 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 the approaches suitable for IPv6 host configuration of
-   recursive DNS servers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005                [Page 5]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-2.  Terminology
-
-   This document uses the terminology described in [3]-[9].  In
-   addition, a new term is defined below:
-
-   o  Recursive DNS Server (RDNSS): A Recursive DNS Server is a name
-      server that offers the recursive service of DNS name resolution.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005                [Page 6]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-3.  IPv6 DNS Configuration Approaches
-
-   In this section, the operational attributes of the three solutions
-   are described in detail.
-
-3.1  RA Option
-
-   The RA approach is to define a new ND option called the 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.
-   An IPv6 host can configure the IPv6 addresses of one or more RDNSSes
-   via RA message periodically sent by a 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 addresses can
-   be performed manually by an operator or other ways, such as automatic
-   configuration through a DHCPv6 client running on the router.  When
-   advertising more than one RDNSS option, an RA message includes as
-   many RDNSS options as RDNSSes.
-
-   Through the ND protocol and RDNSS option along with a 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, it is worth noting that some link layers, such as Wireless
-   LANs (e.g., IEEE 802.11 a/b/g), do not support reliable multicast,
-   which means that they cannot guarantee the timely delivery of RA
-   messages [25]-[28].  This is discussed in Appendix A.
-
-   The RA approach is useful in some mobile environments where the
-   addresses of the RDNSSes are changing because the RA option includes
-   a lifetime field that allows client to use RDNSSes nearer to the
-   client.  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, the lifetime
-   field would seem to make matters a bit more complex.  Instead of just
-   writing to a 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 the RDNSS option, allows
-   IPv6 hosts to select primary RDNSS among several RDNSSes; this can be
-   used for the load balancing of RDNSSes [8].
-
-
-
-Jeong                   Expires November 6, 2005                [Page 7]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-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
-       multipoint-to-multipoint (i.e., Ethernet LANs), etc.  RFC 2461
-       [3] states, however, that there may be some link types on which
-       ND is not feasible; on such links, some other mechanisms will be
-       needed for DNS configuration.
-
-   3.  All of the information a host needs to run the basic Internet
-       applications such as the email, web, ftp, etc., can be obtained
-       with the addition of this option to ND and address
-       autoconfiguration.  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): Refer to Appendix A.  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, by 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 needed 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, such as NTP server address, that are common to all
-       clients on a subnet would be easy to define.
-
-
-3.1.2  Disadvantages
-
-   1.  ND is mostly implemented in the kernel of operating system.
-       Therefore, if ND supports the configuration of some additional
-       services, such as DNS servers, ND should be extended in the
-
-
-
-Jeong                   Expires November 6, 2005                [Page 8]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-       kernel, and complemented by a user-land process.  DHCPv6,
-       however, has more flexibility for the extension of service
-       discovery because it is an application layer protocol.
-
-   2.  The current ND framework should be modified to facilitate the
-       synchronization between another ND cache for RDNSSes in the
-       kernel space and the DNS configuration file in the user space.
-       Because it is unacceptable to write and rewrite to 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 needed 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 via the RA option.
-
-
-3.1.3  Observations
-
-   The proposed RDNSS RA option along with the IPv6 ND and
-   Autoconfiguration allows a host to obtain all of the information it
-   needs to access the basic Internet services like the web, email, ftp,
-   etc.  This is preferable in the environments where hosts use RAs to
-   autoconfigure their addresses and all the 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.  The environments like this include the 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].  The
-   environments like this are most likely to be the 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
-
-
-
-Jeong                   Expires November 6, 2005                [Page 9]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   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 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 a 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.
-
-
-
-Jeong                   Expires November 6, 2005               [Page 10]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   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.
-
-   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 with 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.
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 11]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-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 messages, 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.
-
-
-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
-
-   Anycast uses the same routing system as unicast [11].  However,
-   administrative entities are local ones.  The local entities may
-   accept unicast routes (including default routes) to anycast servers
-   from adjacent entities.  The administrative entities should not
-   advertise their peers routes to their internal anycast servers, if
-   they want to prohibit external access from some peers to the servers.
-   If some advertisement is inevitable (such as the case with default
-   routes), the packets to the servers should be blocked at the boundary
-
-
-
-Jeong                   Expires November 6, 2005               [Page 12]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   of the entities.  Thus, for this anycast, not only unicast routing
-   but also unicast ND protocols can be used as is.
-
-   First of all, the well-known anycast addresses approach is much
-   different from that discussed at IPv6 Working Group in the past [9].
-   It should be noted that "anycast" in this memo is simpler than that
-   of RFC 1546 [11] and RFC 3513 [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, an 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 in having multiple RDNSSes sharing an anycast
-   address on a single link.
-
-   The approach with well-known anycast addresses is to set multiple
-   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).  A 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.
-
-3.3.1  Advantages
-
-   The basic advantage of the well-known addresses approach is that it
-   uses no transport mechanism.  Thus,
-
-   1.  There is no delay to get the response and no further delay by
-       packet losses.
-
-   2.  The approach can be combined with any other configuration
-       mechanisms, such as the RA-based approach and DHCP based
-       approach, as well as the factory default configuration.
-
-   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
-
-
-
-Jeong                   Expires November 6, 2005               [Page 13]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   accesses 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 the configuration effort of users.
-
-   The redundancy by multiple RDNSSes is better provided by multiple
-   servers having different anycast addresses than multiple servers
-   sharing the 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
-   the boundary between RDNSSes may be fixed (redundancy is still
-   provided by multiple addresses) or change dynamically.  DNS packets
-   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 RFC 1546 [11]
-   and RFC 3513 [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 RFC 2461 [3] and RFC 3513 [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 RFC 3513 [12]) address of packets of UDP and
-   TCP responses.  With TCP, if a 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.
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 14]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-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, the O (Other stateful
-   configuration) flag in RA message can be used [8][32].  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 the
-   configuration effort on servers by using the well-known addresses as
-   the default configuration.  Moreover, the clients preconfigured with
-   the well-known anycast addresses can be further configured to use
-   other approaches to override the well-known addresses, if the
-   configuration information from other approaches is available.
-   Otherwise, all the clients need to have the well-known anycast
-   addresses preconfigured.  In order to use the anycast approach along
-   with two other approaches, there are three choices as follows:
-
-   1.  The first choice is that well-known addresses are used as last
-       resort, when an IPv6 host cannot get RDNSS information through RA
-       and DHCP.  The well-known anycast addresses have to be
-       preconfigured in all of IPv6 hosts' resolver configuration files.
-
-   2.  The second is that an IPv6 host can configure well-known
-       addresses as the most preferable in its configuration file even
-       though either an RA option or DHCP option is available.
-
-   3.  The last is that the well-known anycast addresses can be set in
-       RA or DHCP configuration to reduce the configuration effort of
-       users.  According to either the RA or DHCP mechanism, the well-
-       known addresses can be obtained by an 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.
-
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 15]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-5.  Deployment Scenarios
-
-   Regarding the DNS configuration on the IPv6 host, several mechanisms
-   are 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 for 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
-
-   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
-
-
-
-Jeong                   Expires November 6, 2005               [Page 16]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   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 messages.
-
-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].  The DHCPv6 DNS option is
-   already in place for DHCPv6 as RFC 3646 [7] and DHCPv6-lite or
-   stateless DHCP [6] is nowhere as complex as a full DHCPv6
-   implementation.  DHCP is a client-server model protocol, so ISPs 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 Anycast Addresses Approach
-
-   The well-known anycast addresses approach is also a feasible and
-   simple mechanism for ISP [9].  The use of well-known anycast
-   addresses 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
-
-
-
-Jeong                   Expires November 6, 2005               [Page 17]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   enterprise network can get network prefixes from an 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 from IPv6 hosts as RDNSSes.  The RDNSS configuration in the
-   enterprise network can be performed like in Section 4, in which three
-   approaches can be used together as follows:
-
-   1.  An IPv6 host can decide which approach is or may be used in its
-       subnet with the O flag in RA message [8][32].  As the first
-       choice in Section 4, well-known anycast addresses can be used as
-       a last resort when RDNSS information cannot be obtained through
-       either an RA option or DHCP option.  This case needs IPv6 hosts
-       to preconfigure the well-known anycast addresses in their DNS
-       configuration files.
-
-   2.  When the enterprise prefers the well-known anycast approach to
-       others, IPv6 hosts should preconfigure the well-known anycast
-       addresses like in the first choice.
-
-   3.  The last choice, 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 via either the
-       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
-
-   The 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).  The 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].
-
-   In the 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 cannot be assumed that (s)he has simultaneously an
-   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.
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 18]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   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., 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 a 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, 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 the 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
-
-
-
-Jeong                   Expires November 6, 2005               [Page 19]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   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 the 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.
-
-   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 a router
-       already existing, and that means 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.
-
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 20]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   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 a
-       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.
-
-       *  The 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
-
-   The 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
-
-   It is suggested that a lightweight, stateless DNS configuration
-   mechanism is specified as soon as possible.  From a 3GPP UE and
-   network point of view, the 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.
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 21]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-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, cannot 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).
-
-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.
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 22]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-5.4.4  Case D: A gateway connected to an IPv6-only ISP
-
-   This is similar to Case B.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 23]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-6.  Security Considerations
-
-   As security requirements depend solely on applications and are
-   different application by application, there can be no generic
-   requirement defined at IP or application layer for 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 scenarios [19], where cryptographic security is
-   required for applications, the 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 autoconfiguration
-   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 the local environment is secure enough that the
-   information from the local autoconfiguration server has acceptable
-   security even without cryptographic security.  Thus, the
-   communication between the local DNS client and local DNS server has
-   acceptable security.
-
-   In autoconfiguring recursive servers, DNSSEC may be overkill, because
-   DNSSEC [29] needs the configuration and reconfiguration of clients at
-   root key roll-over [30][31].  Even if additional keys for secure key
-   roll-over are added at the initial configuration, they are as
-   vulnerable as the original keys to some forms of attacks, such as
-   social hacking.  Another problem of using DNSSEC and
-   autoconfiguration together is that DNSSEC requires secure time, which
-   means secure communication with autoconfigured time servers, which
-   requires configured secret information.  Therefore, in order that the
-   autoconfiguration may be secure, it requires configured secret
-   information.
-
-   If DNSSEC [29] is used and the signatures are verified on the client
-   host, the misconfiguration of a DNS server may be simply denial of
-   service.  Also, if local routing environment is not reliable, clients
-   may be directed to a false resolver with the same IP address as the
-   true one.
-
-
-
-Jeong                   Expires November 6, 2005               [Page 24]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-6.1  RA Option
-
-   The security of RA option for RDNSS is the same as the ND protocol
-   security [3][8].  The RA option does not add any new vulnerability.
-
-   It should be noted that the vulnerability of ND is not worse and is a
-   subset of the attacks that any node attached to a LAN can do
-   independently of ND.  A malicious node on a LAN can promiscuously
-   receive packets for any router's MAC address and send packets with
-   the router's MAC address as the source MAC address in the L2 header.
-   As a result, the L2 switches send packets addressed to the router to
-   the malicious node.  Also, this attack can send redirects that tell
-   the hosts to send their traffic somewhere else.  The malicious node
-   can send unsolicited RA or NA replies, answer RS or NS requests, etc.
-   All of this can be done independently of implementing ND.  Therefore,
-   the RA option for RDNSS does not add to the vulnerability.
-
-   Security issues regarding the ND protocol were discussed at IETF SEND
-   (Securing Neighbor Discovery) Working Group and RFC 3971 for the ND
-   security has been published [14].
-
-6.2  DHCPv6 Option
-
-   The DNS Recursive Name Server option may be used by an intruder DHCP
-   server to cause DHCP clients to send DNS queries to an intruder DNS
-   recursive name server [7].  The results of these misdirected DNS
-   queries may be used to spoof DNS names.
-
-   To avoid attacks through the DNS Recursive Name Server option, the
-   DHCP client SHOULD require DHCP authentication (see section
-   "Authentication of DHCP messages" in RFC 3315 [5]) before installing
-   a list of DNS recursive name servers obtained through authenticated
-   DHCP.
-
-6.3  Well-known Anycast Addresses
-
-   Well-known anycast addresses does not require configuration security
-   since there is no protocol [9].
-
-   The DNS server with the preconfigured addresses are still reasonably
-   reliable, if local environment is reasonably secure, that is, there
-   is no active attackers receiving queries to the anycast addresses of
-   the servers and reply to them.
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 25]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-7.  Contributors
-
-   Ralph Droms
-   Cisco Systems, Inc.
-   1414 Massachusetts Ave.
-   Boxboro, MA  01719
-   US
-
-   Phone: +1 978 936 1674
-   Email: rdroms@cisco.com
-
-
-   Robert M. Hinden
-   Nokia
-   313 Fairchild Drive
-   Mountain View, CA  94043
-   US
-
-   Phone: +1 650 625 2004
-   Email: bob.hinden@nokia.com
-
-
-   Ted Lemon
-   Nominum, Inc.
-   950 Charter Street
-   Redwood City, CA  94043
-   US
-
-   Email: Ted.Lemon@nominum.com
-
-
-   Masataka Ohta
-   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, Yeongtong-Gu
-   Suwon, Gyeonggi-Do  443-742
-   Korea
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 26]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   Phone: +82 31 200 4508
-   Email: soohong.park@samsung.com
-
-
-   Suresh Satapati
-   Cisco Systems, Inc.
-   San Jose, CA  95134
-   US
-
-   Email: satapati@cisco.com
-
-
-   Juha Wiljakka
-   Nokia
-   Visiokatu 3
-   FIN-33720, TAMPERE
-   Finland
-
-   Phone: +358 7180 48372
-   Email: juha.wiljakka@nokia.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 27]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-8.  Acknowledgements
-
-   This draft has greatly benefited from inputs by David Meyer, Rob
-   Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil,
-   Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley.
-   Also, Tony Bonanno proofread this draft.  The authors appreciate
-   their contribution.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 28]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-9.  References
-
-9.1  Normative References
-
-   [1]  Bradner, S., "IETF Rights in Contributions", RFC 3667,
-        February 2004.
-
-   [2]  Bradner, S., "Intellectual Property Rights in IETF Technology",
-        RFC 3668, February 2004.
-
-   [3]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
-        for IP Version 6 (IPv6)", RFC 2461, December 1998.
-
-   [4]  Thomson, S. and T. Narten, "IPv6 Stateless Address
-        Autoconfiguration", RFC 2462, December 1998.
-
-   [5]  Droms, R., Ed., "Dynamic Host Configuration Protocol for IPv6
-        (DHCPv6)", RFC 3315, July 2003.
-
-   [6]  Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP)
-        Service for IPv6", RFC 3736, April 2004.
-
-   [7]  Droms, R., Ed., "DNS Configuration options for Dynamic Host
-        Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
-        December 2003.
-
-9.2  Informative References
-
-   [8]   Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 DNS
-         Discovery based on Router Advertisement",
-         draft-jeong-dnsop-ipv6-dns-discovery-04.txt (Work in Progress),
-         February 2005.
-
-   [9]   Ohta, M., "Preconfigured DNS Server Addresses",
-         draft-ohta-preconfigured-dns-01.txt (Work in Progress),
-         February 2004.
-
-   [10]  Venaas, S., Chown, T., and B. Volz, "Information Refresh Time
-         Option for DHCPv6", draft-ietf-dhc-lifetime-03.txt (Work in
-         Progress), January 2005.
-
-   [11]  Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting
-         Service", RFC 1546, November 1993.
-
-   [12]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
-         Addressing Architecture", RFC 3513, April 2003.
-
-   [13]  Lind, M., Ed., "Scenarios and Analysis for Introduction IPv6
-
-
-
-Jeong                   Expires November 6, 2005               [Page 29]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-         into ISP Networks", RFC 4029, March 2005.
-
-   [14]  Arkko, J., Ed., "SEcure Neighbor Discovery (SEND)", RFC 3971,
-         March 2005.
-
-   [15]  Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
-         RFC 3118, June 2001.
-
-   [16]  Bound, J., Ed., "IPv6 Enterprise Network Scenarios",
-         draft-ietf-v6ops-ent-scenarios-05.txt (Work in Progress),
-         July 2004.
-
-   [17]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
-         Configuration Protocol (DHCP) version 6", RFC 3633,
-         December 2003.
-
-   [18]  Wasserman, M., Ed., "Recommendations for IPv6 in 3GPP
-         Standards", RFC 3314, September 2002.
-
-   [19]  Soininen, J., Ed., "Transition Scenarios for 3GPP Networks",
-         RFC 3574, August 2003.
-
-   [20]  Wiljakka, J., Ed., "Analysis on IPv6 Transition in 3GPP
-         Networks", draft-ietf-v6ops-3gpp-analysis-11.txt (Work in
-         Progress), October 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]  Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering
-         Requirements for Stateless DHCPv6",
-         draft-ietf-dhc-stateless-dhcpv6-renumbering-02.txt (Work in
-         Progress), October 2004.
-
-   [24]  Huitema, C., Ed., "Unmanaged Networks IPv6 Transition
-         Scenarios", RFC 3750, April 2004.
-
-   [25]  ANSI/IEEE Std 802.11, "Part 11: Wireless LAN Medium Access
-         Control (MAC) and Physical Layer (PHY) Specifications",
-         March 1999.
-
-   [26]  IEEE Std 802.11a, "Part 11: Wireless LAN Medium Access Control
-         (MAC) and Physical Layer (PHY) specifications: High-speed
-         Physical Layer in the 5 GHZ Band", September 1999.
-
-
-
-Jeong                   Expires November 6, 2005               [Page 30]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-   [27]  IEEE Std 802.11b, "Part 11: Wireless LAN Medium Access Control
-         (MAC) and Physical Layer (PHY) specifications: Higher-Speed
-         Physical Layer Extension in the 2.4 GHz Band", September 1999.
-
-   [28]  IEEE P802.11g/D8.2, "Part 11: Wireless LAN Medium Access
-         Control (MAC) and Physical Layer (PHY) specifications: Further
-         Higher Data Rate Extension in the 2.4 GHz Band", April 2003.
-
-   [29]  Eastlake, D., "Domain Name System Security Extensions",
-         RFC 2535, March 1999.
-
-   [30]  Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
-         draft-ietf-dnsop-dnssec-operational-practices-03.txt (Work in
-         Progress), December 2004.
-
-   [31]  Guette, G. and O. Courtay, "Requirements for Automated Key
-         Rollover in DNSSEC",
-         draft-ietf-dnsop-key-rollover-requirements-02.txt (Work in
-         Progress), January 2005.
-
-   [32]  Park, S., Madanapalli, S., and T. Jinmei, "Considerations on M
-         and O Flags of IPv6 Router Advertisement",
-         draft-ietf-ipv6-ra-mo-flags-01.txt (Work in Progress),
-         March 2005.
-
-
-Author's Address
-
-   Jaehoon Paul Jeong (editor)
-   ETRI/Department of Computer Science and Engineering
-   University of Minnesota
-   117 Pleasant Street SE
-   Minneapolis, MN  55455
-   US
-
-   Phone: +1 651 587 7774
-   Fax:   +1 612 625 2002
-   Email: jjeong@cs.umn.edu
-   URI:   http://www.cs.umn.edu/~jjeong/
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 31]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-Appendix A.  Link-layer Multicast Acknowledgements for RA Option
-
-   One benefit of an RA option [8] is to be able to multicast the
-   advertisements, reducing the need for duplicated unicast
-   communications.
-
-   However, some link-layers may not support this as well as others.
-   Consider, for example, WLAN networks where multicast is unreliable.
-   The unreliability problem is caused by lack of ACK for multicast,
-   especially on the path from the Access Point (AP) to the Station
-   (STA), which is specific to CSMA/CA of WLAN, such as IEEE 802.11
-   a/b/g [25]-[28].  That is, a multicast packet is unacknowledged on
-   the path from the AP to the STA, but acknowledged in the reverse
-   direction from the STA to the AP [25].  For example, when a router is
-   placed at wired network connected to an AP, a host may sometimes not
-   receive RA message advertised through the AP.  Therefore, the RA
-   option solution might not work well on a congested medium that uses
-   unreliable multicast for RA.
-
-   The fact that this problem has not been addressed in Neighbor
-   Discovery [3] indicates that the extra link-layer acknowledgements
-   have not been considered a serious problem till now.
-
-   A possible mitigation technique could be to map all-nodes link- local
-   multicast address to the link-layer broadcast address, and to rely on
-   the ND retransmissions for message delivery in order to achieve more
-   reliability.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 32]
-
-Internet-Draft    IPv6 Host Configuration of DNS Server         May 2005
-
-
-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 (2005).  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.
-
-
-
-
-Jeong                   Expires November 6, 2005               [Page 33]
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt
deleted file mode 100644
index 1276f9f..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt
+++ /dev/null
@@ -1,1682 +0,0 @@
-
-
-
-
-DNS Operations WG                                              A. Durand
-Internet-Draft                                    SUN Microsystems, Inc.
-Expires: January 17, 2006                                       J. Ihren
-                                                              Autonomica
-                                                               P. Savola
-                                                               CSC/FUNET
-                                                           July 16, 2005
-
-
-          Operational Considerations and Issues with IPv6 DNS
-                draft-ietf-dnsop-ipv6-dns-issues-11.txt
-
-Status of this Memo
-
-   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 becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-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
-   service provisioning and for DNS resolver IPv6 support,
-
-
-
-Durand, et al.          Expires January 17, 2006                [Page 1]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   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 . . . . . .  7
-     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   The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 10
-       4.4.1   TTL With Courtesy Additional Data  . . . . . . . . . . 10
-       4.4.2   TTL With Critical Additional Data  . . . . . . . . . . 10
-     4.5   IPv6 Transport Guidelines for DNS Servers  . . . . . . . . 11
-   5.  Recommendations for DNS Resolver IPv6 Support  . . . . . . . . 11
-     5.1   DNS Lookups May Query IPv6 Records Prematurely . . . . . . 11
-     5.2   Obtaining a List of DNS Recursive Resolvers  . . . . . . . 13
-     5.3   IPv6 Transport Guidelines for Resolvers  . . . . . . . . . 13
-   6.  Considerations about Forward DNS Updating  . . . . . . . . . . 13
-     6.1   Manual or Custom DNS Updates . . . . . . . . . . . . . . . 14
-     6.2   Dynamic DNS  . . . . . . . . . . . . . . . . . . . . . . . 14
-   7.  Considerations about Reverse DNS Updating  . . . . . . . . . . 15
-     7.1   Applicability of Reverse DNS . . . . . . . . . . . . . . . 15
-     7.2   Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16
-     7.3   DDNS with Stateless Address Autoconfiguration  . . . . . . 16
-     7.4   DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 18
-     7.5   DDNS with Dynamic Prefix Delegation  . . . . . . . . . . . 18
-   8.  Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 19
-     8.1   NAT-PT with DNS-ALG  . . . . . . . . . . . . . . . . . . . 19
-     8.2   Renumbering Procedures and Applications' Use of DNS  . . . 19
-   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
-   10.   Security Considerations  . . . . . . . . . . . . . . . . . . 20
-   11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 20
-     11.1  Normative References . . . . . . . . . . . . . . . . . . . 20
-
-
-
-Durand, et al.          Expires January 17, 2006                [Page 2]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-     11.2  Informative References . . . . . . . . . . . . . . . . . . 22
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24
-   A.  Unique Local Addressing Considerations for DNS . . . . . . . . 25
-   B.  Behaviour of Additional Data in IPv4/IPv6 Environments . . . . 25
-     B.1   Description of Additional Data Scenarios . . . . . . . . . 26
-     B.2   Which Additional Data to Keep, If Any? . . . . . . . . . . 27
-     B.3   Discussion of the Potential Problems . . . . . . . . . . . 28
-       Intellectual Property and Copyright Statements . . . . . . . . 30
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Durand, et al.          Expires January 17, 2006                [Page 3]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-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 unique 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 January 17, 2006                [Page 4]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   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 [RFC3901] 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 January 17, 2006                [Page 5]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-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 [RFC3879]
-   but are discussed with unique local addresses 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.durand-dnsop-dont-publish].
-
-2.2  Temporary Addresses
-
-   Temporary addresses defined in RFC3041 [RFC3041] (sometimes called
-   "privacy addresses") use a random number as the interface identifier.
-   Having DNS AAAA records that are updated to always contain the
-   current value of a node's temporary address 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.
-
-   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 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.
-
-   Note that it does not seem feasible to provide reverse DNS with
-   another automatic tunneling mechanism, Teredo [I-D.huitema-v6ops-
-   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
-
-
-
-Durand, et al.          Expires January 17, 2006                [Page 6]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   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 [RFC4074]: 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.
-
-4.  Recommendations for Service Provisioning using DNS
-
-   When names are added in the DNS to facilitate a service, there are
-
-
-
-Durand, et al.          Expires January 17, 2006                [Page 7]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   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
-
-   It makes sense to keep information about separate services logically
-   separate in the DNS by using a different DNS hostname for each
-   service.  There are several reasons for doing this, for example:
-
-   o  It allows more flexibility and ease for migration of (only a part
-      of) services from one node to another,
-
-   o  It allows configuring different properties (e.g., TTL) for each
-      service, and
-
-   o  It allows deciding separately for each service whether to publish
-      the IPv6 addresses or not (in cases where some services are more
-      IPv6-ready than others).
-
-   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 could 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.)
-
-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 either be added to "service.example.com", or added
-   separately under a different name, e.g., in a sub-domain, like,
-   "service.ipv6.example.com".
-
-
-
-
-Durand, et al.          Expires January 17, 2006                [Page 8]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   These two methods have different characteristics.  Using a different
-   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
-   that the service offered using both protocols is of roughly equal
-   quality, using the appropriate metrics for the service (e.g.,
-
-
-
-Durand, et al.          Expires January 17, 2006                [Page 9]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   latency, throughput, low packet loss, general reliability, etc.) --
-   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.
-
-4.4  The Use of TTL for IPv4 and IPv6 RRs
-
-   The behaviour of DNS caching when different TTL values are used for
-   different RRsets of the same name calls for explicit discussion.  For
-   example, let's consider two unrelated zone fragments:
-
-      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
-
-   ...
-
-      child.example.com.    300  IN    NS     ns.child.example.com.
-      ns.child.example.com. 300  IN    A      192.0.2.1
-      ns.child.example.com. 100  IN    AAAA   2001:db8::1
-
-   In the former case, we have "courtesy" additional data; in the
-   latter, we have "critical" additional data.  See more extensive
-   background discussion of additional data handling in Appendix B.
-
-4.4.1  TTL With Courtesy Additional Data
-
-   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.  The resolver
-   must explicitly query for both A and AAAA records [RFC2821].
-
-   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.  Further argument
-   for discarding is that in the normal operation, the TTL values are so
-   high that very likely the incurred additional queries would not be
-   noticeable, compared to the obtained performance optimization.  The
-   behaviour in this scenario is unspecified.
-
-4.4.2  TTL With Critical Additional Data
-
-   The difference to courtesy additional data is that the A/AAAA records
-   served by the parent zone cannot be queried explicitly.  Therefore
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 10]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   after 100 seconds the AAAA record is removed from the cache(s), but
-   the A record remains.  Queries for the remaining 200 seconds
-   (provided that there are no further queries from the parent which
-   could refresh the caches) only return the A record, leading to a
-   potential opererational situation with unreachable servers.
-
-   Similar cache flushing strategies apply in this scenario; the record.
-
-4.5  IPv6 Transport Guidelines for DNS Servers
-
-   As described in Section 1.3 and [RFC3901], 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.
-
-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
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 11]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   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
-   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 [RFC4038].
-
-   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
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 12]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   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
-   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 [RFC3901], 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 of 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
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 13]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   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.
-
-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
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 14]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   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
-   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
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 15]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   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 in the reverse DNS, as justified and described in
-   [RFC4025].
-
-   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
-   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 trusted and
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 16]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   deployed at the same site (e.g., not across the Internet), 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.  However,
-   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 infeasible.
-
-   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 [RFC3972]
-   (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.
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 17]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-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
-   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
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 18]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   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.
-
-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.ietf-v6ops-natpt-to-exprmntl].  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
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 19]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   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
-   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 what 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-06 (work in
-              progress), May 2005.
-
-   [I-D.ietf-ipv6-unique-local-addr]
-              Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
-              Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in
-              progress), January 2005.
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 20]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   [I-D.ietf-v6ops-renumbering-procedure]
-              Baker, F., "Procedures for Renumbering an IPv6 Network
-              without a Flag Day",
-              draft-ietf-v6ops-renumbering-procedure-05 (work in
-              progress), March 2005.
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [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.
-
-   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
-              April 2001.
-
-   [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)
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 21]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-              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.
-
-   [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.
-
-   [RFC3879]  Huitema, C. and B. Carpenter, "Deprecating Site Local
-              Addresses", RFC 3879, September 2004.
-
-   [RFC3901]  Durand, A. and J. Ihren, "DNS IPv6 Transport Operational
-              Guidelines", BCP 91, RFC 3901, September 2004.
-
-   [RFC4038]  Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
-              Castro, "Application Aspects of IPv6 Transition",
-              RFC 4038, March 2005.
-
-   [RFC4074]  Morishita, Y. and T. Jinmei, "Common Misbehavior Against
-              DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
-
-11.2  Informative References
-
-   [I-D.durand-dnsop-dont-publish]
-              Durand, A. and T. Chown, "To publish, or not to publish,
-              that is the question.", draft-durand-dnsop-dont-publish-00
-              (work in progress), February 2005.
-
-   [I-D.huitema-v6ops-teredo]
-              Huitema, C., "Teredo: Tunneling IPv6 over UDP through
-              NATs", draft-huitema-v6ops-teredo-05 (work in progress),
-              April 2005.
-
-   [I-D.huston-6to4-reverse-dns]
-              Huston, G., "6to4 Reverse DNS Delegation",
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 22]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-              draft-huston-6to4-reverse-dns-03 (work in progress),
-              October 2004.
-
-   [I-D.ietf-dhc-ddns-resolution]
-              Stapp, M. and B. Volz, "Resolution of FQDN Conflicts among
-              DHCP Clients", draft-ietf-dhc-ddns-resolution-09 (work in
-              progress), June 2005.
-
-   [I-D.ietf-dhc-fqdn-option]
-              Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option",
-              draft-ietf-dhc-fqdn-option-10 (work in progress),
-              February 2005.
-
-   [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-09 (work in progress),
-              February 2005.
-
-   [I-D.ietf-dnsop-bad-dns-res]
-              Larson, M. and P. Barber, "Observed DNS Resolution
-              Misbehavior", draft-ietf-dnsop-bad-dns-res-03 (work in
-              progress), October 2004.
-
-   [I-D.ietf-dnsop-inaddr-required]
-              Senie, D., "Encouraging the use of DNS IN-ADDR Mapping",
-              draft-ietf-dnsop-inaddr-required-06 (work in progress),
-              February 2005.
-
-   [I-D.ietf-v6ops-3gpp-analysis]
-              Wiljakka, J., "Analysis on IPv6 Transition in 3GPP
-              Networks", draft-ietf-v6ops-3gpp-analysis-11 (work in
-              progress), October 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-07
-              (work in progress), March 2005.
-
-   [I-D.ietf-v6ops-natpt-to-exprmntl]
-              Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
-              Experimental", draft-ietf-v6ops-natpt-to-exprmntl-01 (work
-              in progress), July 2005.
-
-   [I-D.ietf-v6ops-onlinkassumption]
-              Roy, S., "IPv6 Neighbor Discovery On-Link Assumption
-              Considered Harmful", draft-ietf-v6ops-onlinkassumption-03
-              (work in progress), May 2005.
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 23]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   [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.
-
-   [I-D.jeong-dnsop-ipv6-dns-discovery]
-              Jeong, J., "IPv6 DNS Configuration based on Router
-              Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-04
-              (work in progress), February 2005.
-
-   [I-D.ohta-preconfigured-dns]
-              Ohta, M., "Preconfigured DNS Server Addresses",
-              draft-ohta-preconfigured-dns-01 (work in progress),
-              February 2004.
-
-   [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.
-
-   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
-              RFC 3972, March 2005.
-
-   [RFC4025]  Richardson, M., "A Method for Storing IPsec Keying
-              Material in DNS", RFC 4025, March 2005.
-
-
-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 January 17, 2006               [Page 24]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   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.  Unique Local Addressing Considerations for DNS
-
-   Unique local addresses [I-D.ietf-ipv6-unique-local-addr] have
-   replaced the now-deprecated site-local addresses [RFC3879].  From the
-   perspective of the DNS, the locally generated unique local addresses
-   (LUL) and site-local addresses have similar properties.
-
-   The interactions with DNS come in two flavors: forward and reverse
-   DNS.
-
-   To actually use 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 local addresses must not be published in the public DNS.
-
-   To faciliate reverse DNS (if desired) with 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 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.  This
-   requirement is discussed in [I-D.ietf-ipv6-unique-local-addr].
-
-Appendix B.  Behaviour of Additional Data in IPv4/IPv6 Environments
-
-   DNS responses do not always fit in a single UDP packet.  We'll
-   examine the cases which happen when this is due to too much data in
-   the Additional Section.
-
-
-
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 25]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-B.1  Description of Additional Data Scenarios
-
-   There are two kinds of additional data:
-
-   1.  "critical" additional data; this must be included in all
-       scenarios, with all the RRsets, 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.
-
-   The responding server can algorithmically determine which type the
-   additional data is by checking whether it's at or below a zone cut.
-
-   Only those additional data records (even if sometimes carelessly
-   termed "glue") are considered "critical" or real "glue" if and only
-   if they meet the abovementioned condition, as specified in Section
-   4.2.1 of [RFC1034].
-
-   Remember that 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.
-
-   In particular, [RFC2181] specifies (in Section 9) that:
-
-   a.  if all the "critical" RRsets do not fit, the sender should set
-       the TC bit, and the recipient should discard the whole response
-       and retry using mechanism allowing larger responses such as TCP.
-
-   b.  "courtesy" additional data should not cause the setting of TC
-       bit, but instead all the non-fitting additional data RRsets
-       should be removed.
-
-   An example of the "courtesy" additional data is A/AAAA records in
-   conjunction with MX records as shown in Section 4.4; an example of
-   the "critical" additional data is shown below (where getting both the
-   A and AAAA RRsets is critical w.r.t. to the NS RR):
-
-      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, at least the non-
-   fitting RRsets should be removed [RFC2181]; however, as the
-   additional data is not critical, even all of it could be safely
-   removed.
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 26]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   When there is too much "critical" additional data, TC bit will have
-   to be set, and the recipient should ignore the response and retry
-   using TCP; if some data were to be left in the UDP response, the
-   issue is which data could be retained.
-
-   Failing to discard the response with TC bit or omitting critical
-   information but not setting TC bit lead to an unrecoverable problem.
-   Omitting only some of the RRsets if all would not fit (but not
-   setting TC bit) leads to a performance problem.  These are discussed
-   in the next two subsections.
-
-B.2  Which Additional Data to Keep, If Any?
-
-   If the implementation decides to keep as much data (whether
-   "critical" or "courtesy") as possible in the UDP responses, 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.
-
-   With courtesy additional data, as long as enough RRsets will be
-   removed so that TC will not be set, it is allowed to send as many
-   complete RRsets as the implementations prefers.  However, the
-   implementations are also free to omit all such RRsets, even if
-   complete.  Omitting all the RRsets (when removing only some would
-   suffice) may create a performance penalty, whereby the client may
-   need to issue one or more additional queries to obtain necessary
-   and/or consistent information.
-
-   With critical additional data, the alternatives are either returning
-   nothing (and absolutely requiring a retry with TCP) or returning
-   something (working also in the case if the recipient does not discard
-   the response and retry using TCP) in addition to setting the TC bit.
-   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.
-
-   That is, leaving in some intelligently selected critical additional
-   data is a tradeoff between creating an optimization for those
-   resolvers which ignore the "should discard" recommendation, and
-   causing a protocol problem by propagating inconsistent information
-   about "critical" records in the caches.
-
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 27]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   Similarly, leaving in the complete courtesy additional data RRsets
-   instead of removing all the RRsets is a performance tradeoff as
-   described in the next section.
-
-B.3  Discussion of the Potential Problems
-
-   As noted above, the temptation for omitting only some of the
-   additional data could be problematic.  This is discussed more below.
-
-   For courtesy additional data, this causes a potential performance
-   problem as this requires that the clients issue re-queries for the
-   potentially omitted RRsets.  For critical additional data, this
-   causes a potential unrecoverable problem if the response is not
-   discarded and the query not re-tried with TCP, as the nameservers
-   might be reachable only through the omitted RRsets.
-
-   If an implementation would look at the transport used for the query,
-   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.
-
-   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, depending on
-   implementations) 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.  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,
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 28]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Durand, et al.          Expires January 17, 2006               [Page 29]
-
-Internet-Draft        Considerations with IPv6 DNS             July 2005
-
-
-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 (2005).  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 January 17, 2006               [Page 30]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt
deleted file mode 100644
index b2e2341..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt
+++ /dev/null
@@ -1,300 +0,0 @@
-Internet Engineering Task Force                         A.Durand
-INTERNET-DRAFT                             SUN Microsystems,inc.
-November, 24, 2003                                      J. Ihren
-Expires May 25, 2004                                  Autonomica
-
-
-               DNS IPv6 transport operational guidelines
-          <draft-ietf-dnsop-ipv6-transport-guidelines-01.txt>
-
-
-
-Status of this Memo
-
-   This memo provides information to the Internet community. It does not
-   specify an Internet standard of any kind. This memo is in full
-   conformance with all provisions of Section 10 of RFC2026
-
-   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/1id-abstracts.html
-
-   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).  All Rights Reserved.
-
-
-Abstract
-
-   This memo provides guidelines and Best Current Practice to operate
-   DNS in a world where queries and responses are carried in a mixed
-   environment of IPv4 and IPv6 networks.
-
-
-Acknowledgment
-
-   This document is the result of many conversations that happened in
-   the DNS community at IETF and elsewhere since 2001. During that
-   period of time, a number of Internet drafts have been published to
-   clarify various aspects of the issues at stake. This document focuses
-   on the conclusion of those discussions.
-
-   The authors would like to acknowledge the role of Pekka Savola in his
-   thorough review of the document.
-
-
-1. Terminology
-
-   The phrase "IPv4 name server" indicates a name server available over
-   IPv4 transport. It does not imply anything about what DNS data is
-   served. Likewise, "IPv6 name server" indicates a name server
-   available over IPv6 transport. The phrase "dual-stack DNS server"
-   indicates a DNS server that is actually configured to run both
-   protocols, IPv4 and IPv6, and not merely a server running on a system
-   capable of running both but actually configured to run only one.
-
-   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 [2119].
-
-
-2. Introduction to the Problem of Name Space Fragmentation:
-     following the referral chain
-
-   The caching resolver that tries to look up a name starts out at the
-   root, and follows referrals until it is referred to a nameserver that
-   is authoritative for the name.  If somewhere down the chain of
-   referrals it is referred to a nameserver that is only accessible over
-   an unavailable type of transport, a traditional nameserver is unable
-   to finish the task.
-
-   When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is
-   only a matter of time until this starts to happen. The complete DNS
-   hierarchy then starts to fragment into a graph where authoritative
-   nameservers for certain nodes are only accessible over a certain
-   transport. What is feared is that a node using only a particular
-   version of IP, querying information about another node using the same
-   version of IP can not do it because, somewhere in the chain of
-   servers accessed during the resolution process, one or more of them
-   will only be accessible with the other version of IP.
-
-   With all DNS data only available over IPv4 transport everything is
-   simple. IPv4 resolvers can use the intended mechanism of following
-   referrals from the root and down while IPv6 resolvers have to work
-   through a "translator", i.e. they have to use a second name server on
-   a so-called "dual stack" host as a "forwarder" since they cannot
-   access the DNS data directly.
-
-   With all DNS data only available over IPv6 transport everything would
-   be equally simple, with the exception of old legacy IPv4 name servers
-   having to switch to a forwarding configuration.
-
-   However, the second situation will not arise in a foreseeable time.
-   Instead, it is expected that the transition will be from IPv4 only to
-   a mixture of IPv4 and IPv6, with DNS data of theoretically three
-   categories depending on whether it is available only over IPv4
-   transport, only over IPv6 or both.
-
-   Having DNS data available on both transports is the best situation.
-   The major question is how to ensure that it as quickly as possible
-   becomes the norm. However, while it is obvious that some DNS data
-   will only be available over v4 transport for a long time it is also
-   obvious that it is important to avoid fragmenting the name space
-   available to IPv4 only hosts. I.e. during transition it is not
-   acceptable to break the name space that we presently have available
-   for IPv4-only hosts.
-
-
-3. Policy Based Avoidance of Name Space Fragmentation
-
-   Today there are only a few DNS "zones" on the public Internet that
-   are  available over IPv6 transport, and most of them can be regarded
-   as "experimental". However, as soon as the root and top level domains
-   are available over IPv6 transport, it is reasonable to expect that it
-   will become more common to have zones served by IPv6 servers.
-
-   Having those zones served only by IPv6-only name server would not be
-   a good development, since this will fragment the previously
-   unfragmented IPv4 name space and there are strong reasons to find a
-   mechanism to avoid it.
-
-   The RECOMMENDED approach to maintain name space continuity is to use
-   administrative policies, as described in the next section.
-
-
-4. DNS IPv6 Transport RECOMMENDED Guidelines
-
-   In order to preserve name space continuity, the following administrative
-   policies are RECOMMENDED:
-      - every recursive DNS server SHOULD be either IPv4-only or dual
-      stack,
-      - every single DNS zone SHOULD be served by at least one IPv4
-      reachable DNS server.
-
-   This rules out IPv6-only DNS servers performing full recursion and
-   DNS zones served only by IPv6-only DNS servers.  However, one could
-   very well design a configuration where a chain of IPv6 only DNS
-   servers forward queries to a set of dual stack DNS servers actually
-   performing those recursive queries.  This approach could be revisited
-   if/when translation techniques between IPv4 and IPv6 were to be
-   widely deployed.
-
-   In order to help enforcing the second point, the optional operational
-   zone validation processes SHOULD ensure that there is at least one
-   IPv4 address record available for the name servers of any child
-   delegations within the zone.
-
-
-5. Security Considerations
-
-   Being a critical piece of the Internet infrastructure, the DNS is a
-   potential value target and thus should be protected.  Great care
-   should be taken not to weaken the security of DNS while introducing
-   IPv6 operation.
-
-   Keeping the DNS name space from fragmenting is a critical thing for
-   the availability and the operation of the Internet; this memo
-   addresses this issue by clear and simple operational guidelines.
-
-   The RECOMMENDED guidelines are compatible with the operation of
-   DNSSEC and do not introduce any new security issues.
-
-
-6. Author Addresses
-
-   Alain Durand
-   SUN Microsystems, Inc
-   17 Network circle UMPK17-202
-   Menlo Park, CA, 94025
-   USA
-   Mail: Alain.Durand@sun.com
-
-   Johan Ihren
-   Autonomica
-   Bellmansgatan 30
-   SE-118 47 Stockholm, Sweden
-   Mail: johani@autonomica.se
-
-
-7. Normative References
-
-   [2119]  Bradner, S., "Key Words for Use in RFCs to Indicate
-           Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-8. 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt
deleted file mode 100644
index 6bece56..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt
+++ /dev/null
@@ -1,389 +0,0 @@
-
-DNSOP                                                          G. Guette
-Internet-Draft                                             IRISA / INRIA
-Expires: July 19, 2005                                        O. Courtay
-                                                             Thomson R&D
-                                                        January 18, 2005
-
-           Requirements for Automated Key Rollover in DNSSEC
-           draft-ietf-dnsop-key-rollover-requirements-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 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 July 19, 2005.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).  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 during an automated rollover
-   process.  This document is essentially about in-band key rollover.
-
-
-
-
-Guette & Courtay         Expires July 19, 2005                  [Page 1]
-Internet-Draft      Automated Rollover Requirements         January 2005
-
-Table of Contents
-
-   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
-   2.   The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3
-   3.   Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4
-   4.   Messages authentication and information exchanged  . . . . . . 5
-   5.   Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5
-   6.   Security consideration . . . . . . . . . . . . . . . . . . . . 6
-   7.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 6
-   8.   Normative References . . . . . . . . . . . . . . . . . . . . . 6
-        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
-   A.   Documents details and changes  . . . . . . . . . . . . . . . . 7
-        Intellectual Property and Copyright Statements . . . . . . . . 8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Guette & Courtay         Expires July 19, 2005                  [Page 2]
-Internet-Draft      Automated Rollover Requirements         January 2005
-
-1.  Introduction
-
-   The DNS security extensions (DNSSEC) [4][6][5][7] 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
-   exchanges between parents and children is necessary for large zones
-   because there are too many changes to handle.
-
-   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 is 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 a protocol to perform
-   the automated key rollover process and focusses on interaction
-   between parent and child zone.
-
-2.  The Key Rollover Process
-
-   Key rollover consists of 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.
-
-   During a ZSK rollover, all changes are local to the zone that renews
-   its key: there is no need to contact other zones administrators to
-   propagate the performed changes because a ZSK has no associated DS
-   record in the parent zone.
-
-   During a KSK rollover, new DS RR(s) must be created and stored in the
-   parent zone.  In consequence, data must be exchanged between child
-   and parent zones.
-
-   The key rollover is built from two parts of different nature:
-   o  An algorithm that generates new keys and signs the zone file.  It
-      can be local to the zone,
-   o  the interaction between parent and child zones.
-
-   One example of manual key rollover [3] is:
-   o  The child zone creates a new KSK,
-
-
-Guette & Courtay         Expires July 19, 2005                  [Page 3]
-Internet-Draft      Automated Rollover Requirements         January 2005
-
-   o  the child zone waits for the creation of the DS RR in its parent
-      zone,
-   o  the child zone deletes the old key,
-   o  the parent zone deletes the old DS RR.
-
-   This document concentrates on defining interactions between entities
-   present in key rollover process.
-
-3.  Basic Requirements
-
-   This section provides the requirements for automated key rollover in
-   case of normal use.  Exceptional case like emergency rollover is
-   specifically described later in this document.
-
-   The main condition during a key rollover is that the chain of trust
-   must be preserved to every validating DNS client.  No matter if this
-   client retrieves some of the RRs from recursive caching name server
-   or from the authoritative servers for the zone involved in the
-   rollover.
-
-   Automated key rollover solution may be interrupted by a manual
-   intervention.  This manual intervention should not compromise the
-   security state of the chain of trust.  If the chain is safe before
-   the manual intervention, the chain of trust must remain safe during
-   and after the manual intervention
-
-   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 and/or to verify that the changes had been taken into account
-   in the parent zone.  Hence, the child zone can also avoid some
-   critical cases where all child key are changed prior to the DS RR
-   creation.
-
-   By keeping some resource records during a given time, the recursive
-   cache servers can act on the automated rollover.  The existence of
-   recursive cache servers must be taken into account by automated
-   rollover solution.
-
-   Indeed, during an automated key rollover a name server could have to
-   retrieve some DNSSEC data.  An automated key rollover solution must
-   ensure that these data are not old DNSSEC material retrieved from a
-   recursive name server.
-
-
-
-Guette & Courtay         Expires July 19, 2005                  [Page 4]
-Internet-Draft      Automated Rollover Requirements         January 2005
-
-4.  Messages authentication and information exchanged
-
-   This section addresses in-band rollover, security of out-of-band
-   mechanisms is out of scope of this document.
-
-   The security provided by DNSSEC must not be compromised by the key
-   rollover, thus every exchanged message must be authenticated to avoid
-   fake rollover messages from malicious parties.
-
-   Once the changes related to a KSK are made in a child zone, there are
-   two ways for the parent zone to take this changes into account:
-   o  the child zone notify directly or not directly its parent zone in
-      order to create the new DS RR and store this DS RR in parent zone
-      file,
-   o  or the parent zone poll the child zone.
-
-   In both cases, the parent zone must receive all the child keys that
-   need the creation of associated DS RRs in the parent zone.
-
-   Because errors could occur during the transmission of keys between
-   child and parent, the key exchange protocol must be fault tolerant.
-   Should an error occured during the automated key rollover, an
-   automated key rollover solution must be able to keep the zone files
-   in a consistent state.
-
-5.  Emergency Rollover
-
-   Emergency key rollover is a special case of rollover decided by the
-   zone administrator generally for security reasons.  In consequence,
-   emergency key rollover can break some of the requirement described
-   above.
-
-   A zone key might be compromised and an attacker can use the
-   compromised key to create and sign fake records.  To avoid this, the
-   zone administrator may change the compromised key or all its keys as
-   soon as possible, without waiting for the creation of new DS RRs in
-   its parent zone.
-
-   Fast changes may 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 the administrator wants to prevent
-   the compromised key from being used (to spoof DNS data).
-
-   Parent and child zones sharing an automated rollover mechanism,
-   should have an out-of-band way to re-establish a consistent state at
-   the delegation point (DS and DNSKEY RRs).  This allows to avoid that
-   a malicious party uses the compromised key to roll the zone keys.
-
-
-Guette & Courtay         Expires July 19, 2005                  [Page 5]
-Internet-Draft      Automated Rollover Requirements         January 2005
-
-6.  Security consideration
-
-   The automated key rollover process in DNSSEC allows automated renewal
-   of any kind of DNS key (ZSK or KSK).  It is essential that parent
-   side and child side can do mutual authentication.  Moreover,
-   integrity of the material exchanged between the parent and child zone
-   must be provided to ensure the right DS are created.
-
-   As in any application using public key cryptography, in DNSSEC a key
-   may be compromised.  What to do in such a case can be describe in the
-   zone local policy and can violate some requirements described in this
-   draft.  The emergency rollover can break the chain of trust in order
-   to protect the zone against the use of the compromised key.
-
-7.  Acknowledgments
-
-   The authors want to thank members of IDsA project for their
-   contribution to this document.
-
-8  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.
-
-   [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]  Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
-        "Resource Records for the DNS Security Extensions",
-        draft-ietf-dnsext-dnssec-records-11 (work in progress), October
-        2004.
-
-   [6]  Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
-        "DNS Security Introduction and Requirements",
-        draft-ietf-dnsext-dnssec-intro-13 (work in progress), October
-        2004.
-
-   [7]  Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions",
-        draft-ietf-dnsext-dnssec-protocol-09 (work in progress), October
-
-
-Guette & Courtay         Expires July 19, 2005                  [Page 6]
-Internet-Draft      Automated Rollover Requirements         January 2005
-
-        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
-
-Appendix A.  Documents details and changes
-
-   This section is to be removed by the RFC editor if and when the
-   document is published.
-
-   Section about NS RR rollover has been removed
-
-   Remarks from Samuel Weiler and Rip Loomis added
-
-   Clarification about in-band rollover and in emergency section
-
-   Section 3, details about recursive cache servers added
-
-
-
-
-
-
-
-
-Guette & Courtay         Expires July 19, 2005                  [Page 7]
-Internet-Draft      Automated Rollover Requirements         January 2005
-
-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 
-     IETF Documents can be found in BCP 78 and 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 which may cover technology that may be required 
-     to implement this standard. Please address the information to the 
-     IETF at ietf-ipr.org. 
-      
-    
- Full Copyright Statement 
-    
-   Copyright (C) The Internet Society (2005).  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.
-
- Acknowledgment
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-         
-
-
-Guette & Courtay         Expires July 19, 2005                  [Page 8]
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-02.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-02.txt
deleted file mode 100644
index 63fe2de..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-respsize-02.txt
+++ /dev/null
@@ -1,480 +0,0 @@
-
-
-
-
-
-
-   DNSOP Working Group                                     Paul Vixie, ISC
-   INTERNET-DRAFT                                         Akira Kato, WIDE
-   <draft-ietf-dnsop-respsize-02.txt>                            July 2005
-
-                           DNS Response Size Issues
-
-   Status of this Memo
-      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 becomes
-      aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-      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 (2005).  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 2005                                           [Page 1]
-
-   INTERNET-DRAFT                  July 2005                       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 belonged 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 desired and what information was omitted.  If a retry using TCP is
-   needed, the total cost of the transaction is much higher.  (See [RFC1123
-   6.1.3.2] for details on the protocol requirement that UDP be attempted
-   before falling back to TCP.)
-
-   2.3. RRsets are never sent partially unless truncation occurs, in which
-   case the final apparent RRset in the final nonempty section must be
-   considered "possibly damaged".  With or without truncation, the glue
-   present in the additional data section should be considered "possibly
-   incomplete", and requestors should be prepared to re-query for any
-   damaged or missing RRsets.  For multi-transport name or mail services,
-
-
-
-   Expires December 2005                                           [Page 2]
-
-   INTERNET-DRAFT                  July 2005                       RESPSIZE
-
-
-   this can mean querying for an IPv6 (AAAA) RRset even when an IPv4 (A)
-   RRset is present.
-
-   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, or will automatically re-query for
-   RRsets that are "possibly truncated", without considering whether the
-   omitted data was actually necessary.
-
-   2.10. Each added NS RR for a zone will add a minimum of between 16 and
-   44 octets to every untruncated referral or negative response from the
-   zone's authority servers (16 octets for an NS RR, 16 octets for an A RR,
-   and 28 octets for an AAAA RR), in addition to whatever space is taken by
-   the nameserver name (NS NSDNAME and A/AAAA owner name).
-
-
-
-
-   Expires December 2005                                           [Page 3]
-
-   INTERNET-DRAFT                  July 2005                       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 2005                                           [Page 4]
-
-   INTERNET-DRAFT                  July 2005                       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 a.dns.br b.dns.br c.dns.br d.dns.br
-      a.dns.br requires 10 bytes
-      b.dns.br requires 4 bytes
-      c.dns.br requires 4 bytes
-      d.dns.br requires 4 bytes
-      # of NS: 4
-      For maximum size query (255 byte):
-              if only A is considered:     # of A is 4 (green)
-              if A and AAAA are condered:  # of A+AAAA is 3 (yellow)
-              if prefer_glue A is assumed: # of A is 4, # of AAAA is 3 (yellow)
-      For average size query (64 byte):
-              if only A is considered:     # of A is 4 (green)
-              if A and AAAA are condered:  # of A+AAAA is 4 (green)
-              if prefer_glue A is assumed: # of A is 4, # of AAAA is 4 (green)
-
-      % perl respsize.pl ns-ext.isc.org ns.psg.com ns.ripe.net ns.eu.int
-      ns-ext.isc.org requires 16 bytes
-      ns.psg.com requires 12 bytes
-      ns.ripe.net requires 13 bytes
-      ns.eu.int requires 11 bytes
-      # of NS: 4
-      For maximum size query (255 byte):
-              if only A is considered:     # of A is 4 (green)
-              if A and AAAA are condered:  # of A+AAAA is 3 (yellow)
-              if prefer_glue A is assumed: # of A is 4, # of AAAA is 2 (yellow)
-      For average size query (64 byte):
-              if only A is considered:     # of A is 4 (green)
-              if A and AAAA are condered:  # of A+AAAA is 4 (green)
-              if prefer_glue A is assumed: # of A is 4, # of AAAA is 4 (green)
-
-   (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.  For these examples we use an average/common name size of
-   15 octets, befitting our assumption of GTLD-SERVERS.NET as our common
-   parent name.
-
-
-
-
-   Expires December 2005                                           [Page 5]
-
-   INTERNET-DRAFT                  July 2005                       RESPSIZE
-
-
-   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 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 given that response truncation is
-   undesirable as an average case, and assuming mostly IPv4-only
-   reachability (only A RRs exist, not AAAA RRs).
-
-   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
-   #
-   # SYNOPSIS
-   #    repsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ...
-   #        if all queries are assumed to have zone suffux, such as "jp" in
-   #     JP TLD servers, specify it in -z option
-   #
-   use strict;
-   use Getopt::Std;
-   my ($sz_msg) = (512);
-   my ($sz_header, $sz_ptr, $sz_rr_a, $sz_rr_aaaa) = (12, 2, 16, 28);
-   my ($sz_type, $sz_class, $sz_ttl, $sz_rdlen) = (2, 2, 4, 2);
-   my (%namedb, $name, $nssect, %opts, $optz);
-   my $n_ns = 0;
-
-
-
-
-   Expires December 2005                                           [Page 6]
-
-   INTERNET-DRAFT                  July 2005                       RESPSIZE
-
-
-   getopt('z', opts);
-   if (defined($opts{'z'})) {
-        server_name_len($opts{'z'}); # just register it
-   }
-
-   foreach $name (@ARGV) {
-        my $len;
-        $n_ns++;
-        $len = server_name_len($name);
-           print "$name requires $len bytes\n";
-        $nssect += $sz_ptr + $sz_type + $sz_class + $sz_ttl + $sz_rdlen + $len;
-   }
-   print "# of NS: $n_ns\n";
-   arsect(255, $nssect, $n_ns, "maximum");
-   arsect(64, $nssect, $n_ns, "average");
-
-   sub server_name_len {
-       my ($name) = @_;
-       my (@labels, $len, $n, $suffix);
-
-       $name =~ tr/A-Z/a-z/;
-       @labels = split(/./, $name);
-       $len = length(join('.', @labels)) + 2;
-       for ($n = 0; $#labels >= 0; $n++, shift @labels) {
-           $suffix = join('.', @labels);
-           return length($name) - length($suffix) + $sz_ptr
-               if (defined($namedb{$suffix}));
-           $namedb{$suffix} = 1;
-       }
-       return $len;
-   }
-
-   sub arsect {
-       my ($sz_query, $nssect, $n_ns, $cond) = @_;
-       my ($space, $n_a, $n_a_aaaa, $n_p_aaaa, $ansect);
-       $ansect = $sz_query + 1 + $sz_type + $sz_class;
-       $space = $sz_msg - $sz_header - $ansect - $nssect;
-       $n_a = atmost(int($space / $sz_rr_a), $n_ns);
-       $n_a_aaaa = atmost(int($space / ($sz_rr_a + $sz_rr_aaaa)), $n_ns);
-       $n_p_aaaa = atmost(int(($space - $sz_rr_a * $n_ns) / $sz_rr_aaaa), $n_ns);
-       printf "For %s size query (%d byte):\n", $cond, $sz_query;
-       printf "if only A is considered:     ";
-       printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns);
-       printf "if A and AAAA are condered:  ";
-       printf "# of A+AAAA is %d (%s)\n", $n_a_aaaa, &judge($n_a_aaaa, $n_ns);
-
-
-
-   Expires December 2005                                           [Page 7]
-
-   INTERNET-DRAFT                  July 2005                       RESPSIZE
-
-
-       printf "if prefer_glue A is assumed: ";
-       printf "# of A is %d, # of AAAA is %d (%s)\n",
-           $n_a, $n_p_aaaa, &judge($n_p_aaaa, $n_ns);
-   }
-
-   sub judge {
-       my ($n, $n_ns) = @_;
-       return "green" if ($n >= $n_ns);
-       return "yellow" if ($n >= 2);
-       return "orange" if ($n == 1);
-       return "red";
-   }
-
-   sub atmost {
-       my ($a, $b) = @_;
-       return 0 if ($a < 0);
-       return $b if ($a > $b);
-       return $a;
-   }
-
-   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 (2005).  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.
-
-
-
-
-
-   Expires December 2005                                           [Page 8]
-
-   INTERNET-DRAFT                  July 2005                       RESPSIZE
-
-
-   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 2005                                           [Page 9]
-
\ No newline at end of file
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-06.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-06.txt
deleted file mode 100644
index c6ec7e4..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-dnsop-serverid-06.txt
+++ /dev/null
@@ -1,618 +0,0 @@
-
-
-
-
-Network Working Group                                           S. Woolf
-Internet-Draft                         Internet Systems Consortium, Inc.
-Expires: September 6, 2006                                     D. Conrad
-                                                           Nominum, Inc.
-                                                           March 5, 2006
-
-
-    Requirements for a Mechanism Identifying a Name Server Instance
-                      draft-ietf-dnsop-serverid-06
-
-Status of this Memo
-
-   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 becomes
-   aware will be disclosed, in accordance with Section 6 of BCP 79.
-
-   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 September 6, 2006.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-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 for
-   administrators.  Existing ad hoc mechanisms for addressing this need
-
-
-
-Woolf & Conrad          Expires September 6, 2006               [Page 1]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-   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
-   some widely deployed implementations of the DNS protocol, including
-   advantages and disadvantages, and discusses some attributes of an
-   improved mechanism.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad          Expires September 6, 2006               [Page 2]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-1.  Introduction and Rationale
-
-   Identifying which name server is responding to queries is often
-   useful, particularly in attempting to diagnose name server
-   difficulties.  This is most obviously useful for authoritative
-   nameservers in the attempt to diagnose the source or prevalence of
-   inaccurate data, but can also conceivably be useful for caching
-   resolvers in similar and other situations.  Furthermore, the ability
-   to identify which server is responding to a query has become more
-   useful as DNS has become more critical to more Internet users, and as
-   network and server deployment topologies have become more complex.
-
-   The traditional means for determining which of several possible
-   servers is answering a query has traditionally been based on the use
-   of the server's IP address as a unique identifier.  However, the
-   modern Internet has seen the deployment of various load balancing,
-   fault-tolerance, or attack-resistance schemes such as shared use of
-   unicast IP addresses as documented in [RFC3258].  An unfortunate side
-   effect of these schemes has been to make the use of IP addresses as
-   identifiers somewhat problematic.  Specifically, a dedicated DNS
-   query may not go to the same server as answered a previous query,
-   even though sent to the same IP address.  Non-DNS methods such as
-   ICMP ping, TCP connections, or non-DNS UDP packets (such as those
-   generated by tools like "traceroute"), etc., may well be even less
-   certain to reach the same server as the one which receives the DNS
-   queries.
-
-   There is a well-known and frequently-used technique for determining
-   an identity for a nameserver more specific than the possibly-non-
-   unique "server that answered the query I sent to IP address XXX".
-   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 September 6, 2006               [Page 3]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-2.  Existing Conventions
-
-   For some time, the commonly deployed Berkeley Internet Name Domain
-   implementation of the DNS protocol suite from the Internet Systems
-   Consortium [BIND] has supported a way of identifying a particular
-   server via the use of a standards-compliant, if somewhat unusual, DNS
-   query.  Specifically, a query to a recent 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.  (The value defaults to the result 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.
-
-   A refinement to the BIND-based mechanism, which dropped the
-   implementation-specific string, replaces ".BIND" with ".SERVER".
-   Thus the query string to learn the unique name of a server may be
-   queried as "ID.SERVER".
-
-   (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 CHAOS TXT RR for this name will return an
-   administratively defined string which defaults to the version of the
-   server responding.  This is, however, not generally implemented by
-   other vendors.)
-
-2.1.  Advantages
-
-   There are several valuable attributes to this mechanism, which
-   account for its usefulness.
-
-   1.  The "HOSTNAME.BIND" or "ID.SERVER" query response 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 system as a
-       "normal" DNS query.
-
-   2.  Since the identity information is requested and returned within
-       the DNS protocol, it doesn't require allowing any other query
-       mechanism to the server, such as holes in firewalls for
-       otherwise-unallowed ICMP Echo requests.  Thus it is likely to
-       reach the same server over a path subject to the same routing,
-       resource, and security policy as the query, without any special
-       exceptions to site security policy.
-
-
-
-
-
-Woolf & Conrad          Expires September 6, 2006               [Page 4]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-   3.  It is simple to configure.  An administrator can easily turn on
-       this feature and control the results of the relevant query.
-
-   4.  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.
-
-   5.  Hypothetically, since it's an ordinary DNS record and the
-       relevant DNSSEC RRs are class independent, the id.server response
-       RR could be signed, which has the advantages described in
-       [RFC4033].
-
-2.2.  Disadvantages
-
-   At the same time, there are some serious drawbacks to the CHAOS/TXT
-   query 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
-       purpose is a good use of the namespace or of implementation
-       effort.
-
-   3.  The initial and still common form, using .BIND, is implementation
-       specific.  BIND is one DNS implementation.  At the time of this
-       writing, it is probably the most prevalent for authoritative
-       servers.  This does not justify standardizing on its ad hoc
-       solution to a problem shared across many operators and
-       implementors.  Meanwhile, the proposed refinement changes the
-       string but preserves the ad hoc CHAOS/TXT mechanism.
-
-   4.  There is no convention or shared understanding of what
-       information an answer to such a query for a server identity could
-       or should include, including a possible encoding or
-       authentication mechanism.
-
-   The first of the listed disadvantages may be 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 September 6, 2006               [Page 5]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-2.3.  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.  But it should preserve the ability of
-       the CHAOS/TXT query-based mechanism to work through firewalls and
-       in other situations where only DNS can be relied upon to reach
-       the server of interest.
-
-   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.  In particular, it should not
-       propagate the existing drawback of requiring support for a CLASS
-       and top level domain in the authoritative server (or the querying
-       tool) to be useful.
-
-   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.  It should be possible to authenticate the received data by some
-       mechanism analogous to those provided by DNSSEC.  In this
-       context, the need could be met by including encryption options in
-       the specification of a new mechanism.
-
-   6.  The identification mechanism should not be implementation-
-       specific.
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad          Expires September 6, 2006               [Page 6]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-3.  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.  A proposed extension, specified and adopted by normal IETF
-   process, is described in [NSID], including relevant IANA action.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad          Expires September 6, 2006               [Page 7]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-4.  Security Considerations
-
-   Providing identifying information as to which server is responding to
-   a particular query from a particular location in the Internet 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.
-
-   Both authentication and confidentiality of serverid data are
-   potentially of interest to administrators-- that is, operators may
-   wish to make serverid data available and reliable to themselves and
-   their chosen associates only.  This would imply both an ability to
-   authenticate it to themselves and keep it private from arbitrary
-   other parties.  This led to Characteristics 4 and 5 of an improved
-   solution.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad          Expires September 6, 2006               [Page 8]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-5.  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 version
-   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.
-
-6.  References
-
-   [1]  Mockapetris, P., "Domain Names - Concepts and Facilities",
-        RFC 1034, STD 0013, November 1987.
-
-   [2]  Mockapetris, P., "Domain Names - Implementation and
-        Specification", RFC 1035, STD 0013, November 1987.
-
-   [3]  Hardie, T., "Distributing Authoritative Name Servers via Shared
-        Unicast Addresses", RFC 3258, April 2002.
-
-   [4]  ISC, "BIND 9 Configuration Reference".
-
-   [5]  Austein, S., "DNS Name Server Identifier Option (NSID)",
-        Internet Drafts http://www.ietf.org/internet-drafts/
-        draft-ietf-dnsext-nsid-01.txt, January 2006.
-
-   [6]  Arends, R., Austein, S., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033,
-        March 2005.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad          Expires September 6, 2006               [Page 9]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-Authors' Addresses
-
-   Suzanne Woolf
-   Internet Systems Consortium, Inc.
-   950 Charter Street
-   Redwood City, CA  94063
-   US
-
-   Phone: +1 650 423-1333
-   Email: woolf@isc.org
-   URI:   http://www.isc.org/
-
-
-   David Conrad
-   Nominum, Inc.
-   2385 Bay Road
-   Redwood City, CA  94063
-   US
-
-   Phone: +1 1 650 381 6003
-   Email: david.conrad@nominum.com
-   URI:   http://www.nominum.com/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Woolf & Conrad          Expires September 6, 2006              [Page 10]
-
-Internet-Draft                  Serverid                      March 2006
-
-
-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 (2006).  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 September 6, 2006              [Page 11]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt b/contrib/bind9/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt
deleted file mode 100644
index 3353b3b..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt
+++ /dev/null
@@ -1,1588 +0,0 @@
-
-                                                            Mark Foster 
-Internet Draft                                              Tom McGarry 
-Document: <draft-ietf-enum-e164-gstn-np-05.txt>                James Yu 
-                                                          NeuStar, Inc. 
-Category: Informational                                   June 24, 2002 
- 
- 
-              Number Portability in the GSTN: An Overview 
- 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC2026 [RFC].  
- 
-   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 (2002).  All rights reserved. 
-    
-    
-   Abstract 
-    
-   This document provides an overview of E.164 telephone number 
-   portability (NP) in the Global Switched Telephone Network (GSTN).    
-   NP is a regulatory imperative seeking to liberalize local telephony 
-   service competition, by enabling end-users to retain telephone 
-   numbers while changing service providers.  NP changes the 
-   fundamental nature of a dialed E.164 number from a hierarchical 
-   physical routing address to a virtual address, thereby requiring the 
-   transparent translation of the later to the former.  In addition, 
-   there are various regulatory constraints that establish relevant 
-   parameters for NP implementation, most of which are not network 
-   technology specific.  Consequently, the implementation of NP 
-   behavior consistent with applicable regulatory constraints, as well 
-   as the need for interoperation with the existing GSTN NP 
-   implementations, are relevant topics for numerous areas of IP 
-   telephony work-in-progress at IETF. 
-  
-Foster,McGarry,Yu         Expired on December 23, 2002        [Page 1] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-    
-   Table of Contents 
-    
-    1.  Introduction ...............................................  2 
-    2.  Abbreviations and Acronyms .................................  4 
-    3.  Types of Number Portability ................................  5 
-    4.  Service Provider Number Portability Schemes ................  7 
-       4.1   All Call Query (ACQ) ..................................  7 
-       4.2   Query on Release (QoR) ................................  8 
-       4.3   Call Dropback .........................................  9 
-       4.4   Onward Routing (OR) ...................................  9 
-       4.5   Comparisons of the Four Schemes ....................... 10 
-    5.  Database Queries in the NP Environment ..................... 11 
-       5.1   U.S. and Canada ....................................... 12 
-       5.2   Europe ................................................ 13 
-    6.  Call Routing in the NP Environment ......................... 14 
-       6.1   U.S. and Canada ....................................... 14 
-       6.2   Europe ................................................ 15 
-    7.  NP Implementations for Geographic E.164 Numbers ............ 17 
-    8.  Number Conservation Method Enabled By NP ................... 20 
-       8.1   Block Pooling ......................................... 20 
-       8.2   ITN Pooling ........................................... 21 
-    9.  Potential Implications ..................................... 21 
-   10.  Security Considerations .................................... 24 
-   11.  IANA Considerations ........................................ 24 
-   12.  Normative References ....................................... 24 
-   13.  Informative References ..................................... 25 
-   14.  Acknowledgement ............................................ 25 
-   15.  AuthorsË Addresses ......................................... 25 
-    
- 
-    
-1. Introduction 
-    
-   This document provides an overview of E.164 telephone number 
-   portability in the Global Switched Telephone Network (GSTN).  There 
-   are considered to be three types of number portability (NP): service 
-   provider portability (SPNP), location portability (not to be 
-   confused with terminal mobility), and service portability. 
-    
-   Service provider portability (SPNP), the focus of the present draft, 
-   is a regulatory imperative in many countries seeking to liberalize 
-   telephony service competition, especially local service.  
-   Historically, local telephony service (as compared to long distance 
-   or international service) has been regulated as a utility-like form 
-   of service.  While a number of countries had begun liberalization 
-   (e.g. privatization, de-regulation, or re-regulation) some years 
-   ago, the advent of NP is relatively recent (since ~1995). 
-    
-   E.164 numbers can be non-geographic and geographic numbers.  Non-
-   geographic numbers do not reveal the locations information of those 
-   numbers.  Geographic E.164 numbers were intentionally designed as 
-   hierarchical routing addresses which could systematically be digit-
-   analyzed to ascertain the country, serving network provider, serving 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 2] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   end-office switch, and specific line of the called party.  As such, 
-   without NP a subscriber wishing to change service providers would 
-   incur a number change as a consequence of being served off of a 
-   different end-office switch operated by the new service provider.  
-   The cost and convenience impact to the subscriber of changing 
-   numbers is seen as barrier to competition.  Hence NP has become 
-   associated with GSTN infrastructure enhancements associated with a 
-   competitive environment driven by regulatory directives. 
-    
-   Forms of SPNP have been deployed or are being deployed widely in the 
-   GSTN in various parts of the world, including the U.S., Canada, 
-   Western Europe, Australia, and the Pacific Rim (e.g. Hong Kong). 
-   Other regions, such as South America (e.g. Brazil) are actively 
-   considering it. 
-    
-   Implementation of NP within a national telephony infrastructure 
-   entails potentially significant changes to numbering administration, 
-   network element signaling, call routing and processing, billing, 
-   service management, and other functions. 
-    
-   NP changes the fundamental nature of a dialed E.164 number from a 
-   hierarchical physical routing address to a virtual address.  NP 
-   implementations attempt to encapsulate the impacts to the GSTN and 
-   make NP transparent to subscribers by incorporating a translation 
-   function to map a dialed, potentially ported E.164 address, into a 
-   network routing address (either a number prefix or another E.164 
-   address) which can be hierarchically routed. 
-    
-   This is roughly analogous to the use of network address translation 
-   on IP addresses to enable IP address portability by containing the 
-   impact of the address change to the edge of the network and retain 
-   the use of CIDR blocks in the core which can be route aggregated by 
-   the network service provider to the rest of the internet. 
-    
-   NP bifurcates the historical role of a subscriberËs E.164 address 
-   into two or more data elements (a dialed or virtual address, and a 
-   network routing address) that must be made available to network 
-   elements through an NP translations database, carried by forward 
-   call signaling, and recorded on call detail records.  Not only is 
-   call processing and routing affected, but also so is SS7/C7 
-   messaging.  A number of TCAP-based SS7 messaging sets utilize an 
-   E.164 address as an application-level network element address in the 
-   global title address (GTA) field of the SCCP message header.  
-   Consequently, SS7/C7 signaling transfer points (STPs) and gateways 
-   need to be able to perform n-digit global title translation (GTT) to 
-   translate a dialed E.164 address into its network address 
-   counterpart via the NP database. 
-    
-   In addition, there are various national regulatory constraints that 
-   establish relevant parameters for NP implementation, most of which 
-   are not network technology specific.  Consequently, implementations 
-   of NP behavior in IP telephony consistent with applicable regulatory 
-   constraints, as well as the need for interoperation with the 
-
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 3] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   existing GSTN NP implementations, are relevant topics for numerous 
-   areas of IP telephony work-in-progress at IETF. 
-    
-   This document describes three types of number portability and the 
-   four schemes that have been standardized to support SPNP for 
-   geographic E.164 numbersspecifically.  Following that, specific 
-   information regarding the call routing and database query 
-   implementations are described for several regions (North American 
-   and Europe) and industries (wireless vs. wireline). The Number 
-   Portability Database (NPDB) interfaces and the call routing schemes 
-   that are used in the North America and Europe are described to show 
-   the variety of standards that may be implemented worldwide.  A 
-   glance of the NP implementations worldwide is provided.  Number 
-   pooling is briefly discussed to show how NP is being enhanced in the 
-   U.S. to conserve North American area codes.  The conclusion briefly 
-   touches the potential impacts of NP on IP & Telecommunications 
-   Interoperability.  Appendix A provides some specific technical and 
-   regulatory information on NP in North America.  Appendix B describes 
-   the number portability administration process that manages the 
-   number portability database in North America. 
-    
-    
-2. Abbreviations and Acronyms 
-    
-   ACQ     All Call Query 
-   AIN     Advanced Intelligent Network 
-   AMPS    Advanced Mobile Phone System 
-   ANSI    American National Standards Institute 
-   CDMA    Code Division Multiple Access 
-   CdPA    Called Party Address 
-   CdPN    Called Party Number 
-   CH      Code Holder 
-   CMIP    Common Management Information Protocol 
-   CS1     Capability Set 1 
-   CS2     Capability Set 2 
-   DN      Directory Number 
-   DNS     Domain Name System 
-   ETSI    European Technical Standards Institute 
-   FCI     Forward Call Indicator 
-   GAP     Generic Address Parameter 
-   GMSC    Gateway Mobile Services Switching Center or Gateway Mobile 
-           Switching Center 
-   GSM     Global System for Mobile Communications 
-   GSTN    Global Switched Telephone Network 
-   GW      Gateways 
-   HLR     Home Location Register 
-   IAM     Initial Address Message 
-   IETF    Internet Engineering Task Force 
-   ILNP    Interim LNP 
-   IN      Intelligent Network 
-   INAP    Intelligent Network Application Part 
-   INP     Interim NP     
-   IP      Internet Protocol 
-   IS-41   Interim Standards Number 41 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 4] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   ISDN    Integrated Services Digital Network 
-   ISUP    ISDN User Part 
-   ITN     Individual Telephony Number  
-   ITU     International Telecommunication Union 
-   ITU-TS  ITU-Telecommunication Sector 
-   LDAP    Lightweight Directory Access Protocol  
-   LEC     Local Exchange Carrier 
-   LERG    Local Exchange Routing Guide 
-   LNP     Local Number Portability 
-   LRN     Location Routing Number 
-   MAP     Mobile Application Part 
-   MNP     Mobile Number Portability 
-   MSRN    Mobile Station Roaming Number 
-   MTP     Message Transfer Part 
-   NANP    North American Numbering Plan 
-   NP      Number Portability 
-   NPDB    Number Portability Database 
-   NRN     Network Routing Number 
-   OR      Onward Routing 
-   OSS     Operation Support System 
-   PCS     Personal Communication Services 
-   PNTI    Ported Number Translation Indicator 
-   PODP    Public Office Dialing Plan 
-   PUC     Public Utility Commission 
-   QoR     Query on Release 
-   RN      Routing Number 
-   RTP     Return to Pivot 
-   SCCP    Signaling Connection Control Part 
-   SCP     Service Control Point  
-   SIP     Session Initiation Protocol 
-   SMR     Special Mobile Radio 
-   SMS     Service Management System 
-   SPNP    Service Provider Number Portability 
-   SRF     Signaling Relaying Function 
-   SRI     Send Routing Information 
-   SS7     Signaling System Number 7 
-   STP     Signaling Transfer Point 
-   TCAP    Transaction Capabilities Application Part 
-   TDMA    Time Division Multiple Access 
-   TN      Telephone Number 
-   TRIP    Telephony Routing Information Protocol 
-   URL     Universal Resource Locator 
-   U.S.    United States 
-    
-    
-3. Types of Number Portability 
-    
-   As there are several types of E.164 numbers (telephone numbers, or 
-   just TN) in the GSTN, there are correspondingly several types of 
-   E.164 NP in the GSTN.  First there are so-call non-geographic E.164 
-   numbers, commonly used for service-specific applications such as 
-   freephone (800 or 0800).  Portability of these numbers is called 
-   non-geographic number portability (NGNP).  NGNP, for example, was 
-   deployed in the U.S. in 1986-92. 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 5] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-    
-   Geographic number portability, which includes traditional fixed or 
-   wireline numbers as well as mobile numbers which are allocated out 
-   of geographic number range prefixes, is called NP or GNP or in the 
-   U.S. local number portability (LNP). 
-    
-   Number portability allows the telephony subscribers in the Global 
-   Switched Telephone Network (GSTN) to keep their phone numbers when 
-   they change their service providers or subscribed services, or when 
-   they move to a new location.   
-    
-   The ability to change the service provider while keeping the same 
-   phone number is called service provider portability (SPNP) also 
-   known as "operator portability." 
-    
-   The ability to change the subscriberËs fixed service location while 
-   keeping the same phone number is called location portability. 
-    
-   The ability to change the subscribed services (e.g., from the plain 
-   old telephone service to Integrated Services Digital Network (ISDN) 
-   services) while keeping the same phone number is called service 
-   portability.  Another aspect of service portability is to allow the 
-   subscribers to enjoy the subscribed services in the same way when 
-   they roam outside their home networks as is supported by the 
-   cellular/wireless networks. 
-    
-   In addition, mobile number portability (MNP) refers to specific NP 
-   implementation in mobile networks either as part of a broader NP 
-   implementation in the GSTN or on a stand-alone basis.  Where 
-   interoperation of LNP and MNP is supported, service portability 
-   between fixed and mobile service types is possible. 
-    
-   At present, SPNP has been the primary form of NP deployed due to its 
-   relevance in enabling local service competition. 
-    
-   Also in use in the GSTN are the terms interim NP (INP) or Interim 
-   LNP (ILNP) and true NP.  Interim NP usually refers to the use of 
-   remote call forwarding-like measures to forward calls to ported 
-   numbers through the donor network to the new service network.  These 
-   are considered interim relative to true NP, which seeks to remove 
-   the donor network or old service provider from the call or signaling 
-   path altogether.  Often the distinction between interim and true NP 
-   is a national regulatory matter relative to the 
-   technical/operational requirements imposed on NP in that country. 
-    
-   Implementations of true NP in certain countries (e.g. U.S., Canada, 
-   Spain, Belgium, Denmark) may pose specific requirements for IP 
-   telephony implementations as a result of regulatory and industry 
-   requirements for providing call routing and signaling independent of 
-   the donor network or last previous serving network. 
-    
-    
-    
-    
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 6] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
- 
-4. Service Provider Number Portability Schemes 
-    
-   Four schemes can be used to support service provider portability and 
-   are briefly described below.  But first, some further terms are 
-   introduced. 
-    
-   The donor network is the network that first assigned a telephone 
-   number (e.g., TN +1-202-533-1234) to a subscriber, out of a number 
-   range administratively (e.g., +1 202-533) assigned to it.  The 
-   current service provider (new SP) or new serving network is the 
-   network that currently serves the ported number. The old serving 
-   network (or old SP) is the network that previously served the ported 
-   number before the number was ported to the new serving network. 
-   Since a TN can port a number of times, the old SP is not necessarily 
-   the same as the donor network, except for the first time the TN 
-   ports away, or if the TN ports back into the donor network and away 
-   again.  While the new SP and old SP roles are transitory as a TN 
-   ports around, the donor network is always the same for any 
-   particular TN based on the service provider to whom the subtending 
-   number range was administratively assigned.  See the discussion 
-   below on number pooling, as this enhancement to NP further 
-   bifurcates the role of donor network into two (the number range or 
-   code holder network, and the block holder network). 
-    
-   To simplify the illustration, all the transit networks are ignored, 
-   the originating or donor network is the one that performs the 
-   database queries or call redirection, and the dialed directory 
-   number (TN) has been ported out of the donor network before.  
-    
-   It is assumed that the old serving network, the new serving network 
-   and the donor network are different networks so as to show which 
-   networks are involved in call handling and routing and database 
-   queries in each of four schemes.  Please note that the port of the 
-   number (process of moving it from one network to another) happened 
-   prior to the call setup and is not included in the call steps.  
-   Information carried in the signaling messages to support each of the 
-   four schemes is not discussed to simplify the explanation. 
-    
-    
-4.1 All Call Query (ACQ) 
-    
-   Figure 1 shows the call steps for the ACQ scheme.  Those call steps 
-   are as follows: 
- 
-   (1) The Originating Network receives a call from the caller and 
-       sends a query to a centrally administered Number Portability 
-       Database (NPDB), a copy of which is usually resident on a 
-       network element within its network or through a third party 
-       provider. 
-   (2) The NPDB returns the routing number associated with the dialed 
-       directory number.  The routing number is discussed later in 
-       Section 6. 
-
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 7] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   (3) The Originating Network uses the routing number to route the 
-       call to the new serving network. 
-    
-    
-   +-------------+              +-----------+    Number   +-----------+ 
-   | Centralized |              | New Serv. |    ported   | Old Serv. | 
-   |    NPDB     |    +-------->|  Network  |<------------|  Network  | 
-   +-------------+    |         +-----------+             +-----------+ 
-       ^  |           | 
-       |  |           | 
-      1|  |         3.| 
-       |  | 2.        | 
-       |  |           | 
-       |  v           | 
-    +----------+      |         +----------+           +----------+ 
-    |   Orig.  |------+         |   Donor  |           | Internal | 
-    |  Network |                |  Network |           |   NPDB   | 
-    +----------+                +----------+           +----------+ 
-    
-    
-              Figure 1 - All Call Query (ACQ) Scheme. 
- 
- 
-4.2 Query on Release (QoR) 
- 
-  Figure 2 shows the call steps for the QoR scheme.  Those call steps 
-  are as follows: 
-    
-    
-   +-------------+              +-----------+    Number   +-----------+ 
-   | Centralized |              | New Serv. |    ported   | Old Serv. | 
-   |    NPDB     |              |  Network  |<------------|  Network  | 
-   +-------------+              +-----------+             +-----------+ 
-       ^  |                          ^ 
-       |  | 4.                       | 
-     3.|  |              5.          | 
-       |  |   +----------------------+ 
-       |  |   | 
-       |  v   | 
-    +----------+      2.        +----------+           +----------+ 
-    |   Orig.  |<---------------|   Donor  |           | Internal | 
-    |  Network |--------------->|  Network |           |   NPDB   | 
-    +----------+      1.        +----------+           +----------+ 
-    
-                   
-                Figure 2 - Query on Release (QoR) Scheme. 
-    
-   (1) The Originating Network receives a call from the caller and 
-       routes the call to the donor network. 
-   (2) The donor network releases the call and indicates that the 
-       dialed directory number has been ported out of that switch. 
-   (3) The Originating Network sends a query to its copy of the 
-       centrally administered NPDB. 
-
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 8] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   (4) The NPDB returns the routing number associated with the dialed 
-       directory number.   
-   (5) The Originating Network uses the routing number to route the 
-       call to the new serving network. 
-    
-    
-4.3 Call Dropback 
-    
-  Figure 3 shows the call steps for the Dropback scheme.  This scheme 
-  is also known as "Return to Pivot (RTP)."  Those call steps are as 
-  follows: 
-    
-   (1) The Originating Network receives a call from the caller and 
-       routes the call to the donor network. 
-   (2) The donor network detects that the dialed directory number has 
-       been ported out of the donor switch and checks with an internal 
-       network-specific NPDB.  
-   (3) The internal NPDB returns the routing number associated with the 
-       dialed directory number. 
-   (4) The donor network releases the call by providing the routing 
-       number. 
-   (5) The Originating Network uses the routing number to route the 
-       call to the new serving network. 
-    
-   +-------------+              +-----------+    Number   +-----------+ 
-   | Centralized |              | New Serv. |    porting  | Old Serv. | 
-   |    NPDB     |              |  Network  |<------------|  Network  | 
-   +-------------+              +-----------+             +-----------+ 
-                                    /\ 
-                                     | 
-                           5.        | 
-            +------------------------+ 
-            | 
-            | 
-    +----------+       4.       +----------+     3.    +----------+ 
-    |   Orig.  |<---------------|   Donor  |<----------| Internal | 
-    |  Network |--------------->|  Network |---------->|   NPDB   | 
-    +----------+      1.        +----------+    2.     +----------+ 
-    
-                   
-                      Figure 3 - Dropback Scheme. 
-    
-    
-4.4 Onward Routing (OR) 
-    
-  Figure 4 shows the call steps for the OR scheme.  Those call steps 
-  are as follows: 
-    
-   (1) The Originating Network receives a call from the caller and 
-       routes the call to the donor network. 
-   (2) The donor network detects that the dialed directory number has 
-       been ported out of the donor switch and checks with an internal 
-       network-specific NPDB.  
-
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 9] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   (3) The internal NPDB returns the routing number associated with the 
-       dialed directory number. 
-   (4) The donor network uses the routing number to route the call to 
-       the new serving network. 
- 
-    
-   +-------------+              +-----------+    Number   +-----------+ 
-   | Centralized |              | New Serv. |    porting  | Old Serv. | 
-   |    NPDB     |              |  Network  |<------------|  Network  | 
-   +-------------+              +-----------+             +-----------+ 
-                                    /\ 
-                                     | 
-                                   4.| 
-                                     | 
-    +----------+                +----------+     3.    +----------+ 
-    |   Orig.  |                |   Donor  |<----------| Internal | 
-    |  Network |--------------->|  Network |---------->|   NPDB   | 
-    +----------+      1.        +----------+    2.     +----------+ 
-    
-                   
-                 Figure 4 - Onward Routing (OR) Scheme. 
- 
-4.5 Comparisons of the Four Schemes 
-    
-   Only the ACQ scheme does not involve the donor network when routing 
-   the call to the new serving network of the dialed ported number.  
-   The other three schemes involve call setup to or signaling with the 
-   donor network.   
-    
-   Only the OR scheme requires the setup of two physical call segments, 
-   one from the Originating Network to the donor network and the other 
-   from the donor network to the new serving network.  The OR scheme is 
-   the least efficient in terms of using the network transmission 
-   facilities.  The QoR and Dropback schemes set up calls to the donor 
-   network first but release the call back to the Originating Network 
-   that then initiates a new call to the Current Serving Network.  For 
-   the QoR and Dropback schemes, circuits are still reserved one by one 
-   between the Originating Network and the donor network when the 
-   Originating Network sets up the call towards the donor network.  
-   Those circuits are released one by one when the call is released 
-   from the donor network back to the Originating Network.  The ACQ 
-   scheme is the most efficient in terms of using the switching and 
-   transmission facilities for the call. 
-    
-   Both the ACQ and QoR schemes involve Centralized NPDBs for the 
-   Originating Network to retrieve the routing information.  
-   Centralized NPDB means that the NPDB contains ported number 
-   information from multiple networks.  This is in contrast to the 
-   internal network-specific NPDB that is used for the Dropback and OR 
-   schemes.  The internal NPDB only contains information about the 
-   numbers that were ported out of the donor network.  The internal 
-   NPDB can be a stand-alone database that contains information about 
-   all or some ported-out numbers from the donor network.  It can also 
-   reside on the donor switch and only contains information about those 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 10] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   numbers ported out of the donor switch.  In that case, no query to a 
-   stand-alone internal NPDB is required.  The donor switch for a 
-   particular phone number is the switch to which the number range is 
-   assigned from which that phone number was originally assigned. 
-    
-   For example, number ranges in the North American Numbering Plan 
-   (NANP) are usually assigned in the form of central office codes (CO 
-   codes) comprising a six-digit prefix formatted as a NPA+NXX.  Thus a 
-   switch serving +1-202-533 would typically serve +1-202-533-0000 
-   through +1-202-533-9999. In major cities, switches usually host 
-   several CO codes.  NPA stands for Numbering Plan Area that is also 
-   known as the area code.  It is three-digit long and has the format 
-   of NXX where N is any digit from 2 to 9 and X is any digit from 0 to 
-   9.  NXX in the NPA+NXX format is known as the office code that has 
-   the same format as the NPA.  When a NPA+NXX code is set as 
-   Ÿportable÷ in the Local Exchange Routing Guide (LERG), it becomes a 
-   "portable NPA+NXX" code. 
-    
-   Similarly, in other national E.164 numbering plans, number ranges 
-   cover a contiguous range of numbers within that range.  Once a 
-   number within that range has ported away from the donor network, all 
-   numbers in that range are considered potentially ported and should 
-   be queried in the NPDB. 
-    
-   The ACQ scheme has two versions.  One version is for the Originating 
-   Network to always query the NPDB when a call is received from the 
-   caller regardless whether the dialed directory number belongs to any 
-   number range that is portable or has at least one number ported out. 
-   The other version is to check whether the dialed directory number 
-   belongs to any number range that is portable or has at least one 
-   number ported out.  If yes, an NPDB query is sent. If not, no NPDB 
-   query is sent.  The former performs better when there are many 
-   portable number ranges.  The latter performs better when there are 
-   not too many portable number ranges at the expense of checking every 
-   call to see whether NPDB query is needed.  The latter ACQ scheme is 
-   similar to the QoR scheme except that the QoR scheme uses call setup 
-   and relies on the donor network to indicate "number ported out" 
-   before launching the NPDB query. 
-    
-    
-5. Database Queries in the NP Environment 
-    
-   As indicated earlier, the ACQ and QoR schemes require that a switch 
-   query the NPDB for routing information.  Various standards have been 
-   defined for the switch-to-NPDB interface.  Those interfaces with 
-   their protocol stacks are briefly described below.  The term "NPDB" 
-   is used for a stand-alone database that may support just one or some 
-   or all of the interfaces mentioned below.  The NPDB query contains 
-   the dialed directory number and the NPDB response contains the 
-   routing number.  There are certainly other information that is sent 
-   in the query and response.  The primary interest is to get the 
-   routing number from the NPDB to the switch for call routing. 
-    
-    
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 11] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-5.1 U.S. and Canada 
-    
-   One of the following five NPDB interfaces can be used to query an 
-   NPDB: 
-    
-   (a) Advanced Intelligent Network (AIN) using the American National 
-       Standards Institute (ANSI)  version of the Intelligent Network 
-       Application Part (INAP) [ANSI SS] [ANSI DB].  The INAP is 
-       carried on top of the protocol stack that includes the (ANSI) 
-       Message Transfer Part (MTP) Levels 1 through 3, ANSI Signaling 
-       Connection Control Part (SCCP), and ANSI Transaction 
-       Capabilities Application Part (TCAP).  This interface can be 
-       used by the wireline or wireless switches, is specific to the NP 
-       implementation in North America, and is modeled on the Public 
-       Office Dialing Plan (PODP) trigger defined in the Advanced 
-       Intelligent Network (AIN) 0.1 call model.  
-    
-   (b) Intelligent Network (IN), which is similar to the one used for 
-       querying the 800 databases.  The IN protocol is carried on top 
-       of the protocol stack that includes the ANSI MTP Levels 1 
-       through 3, ANSI SCCP, and ANSI TCAP.  This interface can be used 
-       by the wireline or wireless switches. 
-    
-   (c) ANSI IS-41 [IS41] [ISNP], which is carried on top of the 
-       protocol stack that includes the ANSI MTP Levels 1 through 3, 
-       ANSI SCCP, and ANSI TCAP.  This interface can be used by the IS-
-       41 based cellular/Personal Communication Services (PCS) wireless 
-       switches (e.g., AMPS, TDMA and CDMA).  Cellular systems use 
-       spectrum at 800 MHz range and PCS systems use spectrum at 1900 
-       MHz range. 
-    
-   (d) Global System for Mobile Communication Mobile Application Part 
-       (GSM MAP) [GSM], which is carried on top of the protocol stack 
-       that includes the ANSI MTP Levels 1 through 3, ANSI SCCP, and 
-       International Telecommunication Union - Telecommunication Sector  
-       (ITU-TS) TCAP.  It can be used by the PCS1900 wireless switches 
-       that are based on the GSM technologies.  GSM is a series of 
-       wireless standards defined by the European Telecommunications 
-       Standards Institute (ETSI). 
-    
-   (e) ISUP triggerless translation.  NP translations are performed 
-       transparently to the switching network by the signaling network 
-       (e.g. Signaling Transfer Points (STPs) or signaling gateways).  
-       ISUP IAM messages are examined to determine if the CdPN field 
-       has already been translated, and if not, an NPDB query is 
-       performed, and the appropriate parameters in the IAM message 
-       modified to reflect the results of the translation.   The 
-       modified IAM message is forwarded by the signaling node on to 
-       the designated DPC in a transparent manner to continue call 
-       setup.  The NPDB can be integrated with the signaling node or be 
-       accessed via an API locally or by a query to a remote NPDB using 
-       a proprietary protocol or the schemes described above. 
-    
-    
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 12] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   Wireline switches have the choice of using either (a), (b), or (e).  
-   IS-41 based wireless switches have the choice of using (a), (b), 
-   (c), or (e).  PCS1900 wireless switches have the choice of using 
-   (a), (b), (d), or (e). In the United States, service provider 
-   portability will be supported by both the wireline and wireless 
-   systems, not only within the wireline or wireless domain but also 
-   across the wireline/wireless boundary.  However, this is not true in 
-   Europe where service provider portability is usually supported only 
-   within the wireline or wireless domain, not across the 
-   wireline/wireless boundary due to explicit use of service-specific 
-   number range prefixes.  The reason is to avoid caller confusion 
-   about the call charge. GSM systems in Europe are assigned 
-   distinctive destination network codes, and the caller pays a higher 
-   charge when calling a GSM directory number. 
-    
-      
-5.2 Europe 
-    
-   One of the following two interfaces can be used to query an NPDB: 
-    
-   (a) Capability Set 1 (CS1) of the ITU-TS INAP [CS1], which is 
-       carried on top of the protocol stack that includes the ITU-TS 
-       MTP Levels 1 through 3, ITU-TS SCCP, and ITU-TS TCAP. 
-    
-   (b) Capability Set 2 (CS2) of the ITU-TS INAP [CS2], which is 
-       carried on top of the protocol stack that includes the ITU-TS 
-       MTP Levels 1 through ITU-TS MTP Levels 1 through 3, ITU-TS SCCP, 
-       and ITU-TS TCAP. 
-    
-   Wireline switches have the choice of using either (a) or (b); 
-   however, all the implementations in Europe so far are based on CS1.  
-   As indicated earlier that number portability in Europe does not go 
-   across the wireline/wireless boundary.  The wireless switches can 
-   also use (a) or (b) to query the NPDBs if those NPDBs contains 
-   ported wireless directory numbers.  The term "Mobile Number 
-   Portability (MNP)" is used for the support of service provider 
-   portability by the GSM networks in Europe.  
-    
-   In most, if not all, cases in Europe, the calls to the wireless 
-   directory numbers are routed to the wireless donor network first.  
-   Over there, an internal NPDB is queried to determine whether the 
-   dialed wireless directory number has been ported out or not.  In 
-   this case, the interface to the internal NPDB is not subject to 
-   standardization. 
-
-   MNP in Europe can also be supported via MNP Signaling Relay Function 
-   (MNP-SRF).  Again, an internal NPDB or a database integrated at the 
-   MNP-SRF is used to modify the SCCP Called Party Address parameter in 
-   the GSM MAP messages so that they can be re-directed to the wireless 
-   serving network.   Call routing involving MNP will be explained in 
-   Section 6.2. 
-    
-    
-    
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 13] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-6. Call Routing in the NP Environment 
- 
-   This section discusses the call routing after the routing 
-   information has been retrieved either through an NPDB query or an 
-   internal database lookup at the donor switch, or from the Integrated 
-   Services Digital Network User Part (ISUP) signaling message (e.g., 
-   for the Dropback scheme).  For the ACQ, QoR and Dropback schemes, it 
-   is the Originating Network that has the routing information and is 
-   ready to route the call.  For the OR scheme, it is the donor network 
-   that has the routing information and is ready to route the call.   
-    
-   A number of triggering schemes may be employed that determine where 
-   in the call path the NPDB query is performed.  In the U.S. an ŸN-1÷ 
-   policy is used, which essentially says that for domestic calls, the 
-   originating local carriers performs the query, otherwise, the long 
-   distance carrier is expected to.  To ensure independence of the 
-   actual trigger policy employed in any one carrier, forward call 
-   signaling is used to flag that an NPDB query has already been 
-   performed and to therefore suppress any subsequent NP triggers that 
-   may be encountered in downstream switches, in downstream networks.  
-   This allows the earliest able network in the call path to perform 
-   the query without introducing additional costs and call setup delays 
-   were redundant queries performed downstream. 
-    
-     
-6.1 U.S. and Canada 
-    
-   In the U.S. and Canada, a ten-digit North American Numbering Plan 
-   (NANP) number called Location Routing Number (LRN) is assigned to 
-   every switch involved in NP.  In the NANP, a switch is not reachable 
-   unless it has a unique number range (CO code) assigned to it.  
-   Consequently, the LRN for a switch is always assigned out of a CO 
-   code that is assigned to that switch. 
-    
-   The LRN assigned to a switch currently serving a particular ported 
-   telephone number is returned as the network routing address in the 
-   NPDB response.  The service portability scheme that was adopted in 
-   the North America is very often referred to as the LRN scheme or 
-   method. 
-    
-   LRN serves as a network address for terminating calls served off 
-   that switch using ported numbers.  The LRN is assigned by the switch 
-   operator using any of the unique CO codes (NPA+NXX) assigned to that 
-   switch.  The LRN is considered a non-dialable address, as the same 
-   10-digit number value may be assigned to a line on that switch.  A 
-   switch may have more than one LRN. 
-    
-   During call routing/processing, a switch performs an NPDB query to 
-   obtain the LRN associated with the dialed directory number. NPDB 
-   queries are performed for all the dialed directory numbers whose 
-   NPA+NXX codes are marked as portable NPA+NXX at that switch. When 
-   formulating the ISUP Initial Address Message (IAM) to be sent to the 
-   next switch, the switch puts the ten-digit LRN in the ISUP Called 
-   Party Number (CdPN) parameter and the originally dialed directory 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 14] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   number in the ISUP Generic Address parameter (GAP).  A new code in 
-   the GAP was defined to indicate that the address information in the 
-   GAP is the dialed directory number. A new bit in the ISUP Forward 
-   Call Indicator (FCI) parameter, the Ported Number Translation 
-   Indicator (PNTI) bit, is set to imply that NPDB query has already 
-   been performed.  All the switches in the downstream will not perform 
-   the NPDB query if the PNTI bit is set. 
-    
-   When the terminating switch receives the IAM and sees the PNTI bit 
-   in the FCI parameter set and its own LRN in the CdPN parameter, it 
-   retrieves the originally dialed directory number from the GAP and 
-   uses the dialed directory number to terminate the call. 
-    
-   A dialed directory number with a portable NPA+NXX does not imply 
-   that directory number has been ported.  The NPDBs currently do not 
-   store records for non-ported directory numbers.  In that case, the 
-   NPDB will return the same dialed directory number instead of the 
-   LRN.  The switch will then set the PNTI bit but keep the dialed 
-   directory number in the CdPN parameter. 
-    
-   In the real world environment, the Originating Network is not always 
-   the one that performs the NPDB query.  For example, it is usually 
-   the long distance carriers that query the NPDBs for long distance 
-   calls.  In that case, the Originating Network operated by the local 
-   exchange carrier (LEC) simply routes the call to the long distance 
-   carrier that is to handle that call.   A wireless network acting as 
-   the Originating Network can also route the call to the 
-   interconnected local exchange carrier network if it does not want to 
-   support the NPDB interface at its mobile switches. 
-    
-    
-6.2 Europe 
-    
-   In some European countries, a routing number is prefixed to the 
-   dialed directory number.  The ISUP CdPN parameter in the IAM will 
-   contain the routing prefix and the dialed directory number.  For 
-   example, United Kingdom uses routing prefixes with the format of 
-   5XXXXX and Italy uses C600XXXXX as the routing prefix.  The networks 
-   use the information in the ISUP CdPN parameter to route the call to 
-   the New/Current Serving Network. 
-    
-   The routing prefix can identify the Current Serving Network or the 
-   Current Serving Switch of a ported number.  For the former case, 
-   another query to the "internal" NPDB at the Current Serving Network 
-   is required to identify the Current Serving Switch before routing 
-   the call to that switch.  This shields the Current Serving Switch 
-   information for a ported number from the other networks at the 
-   expense of an additional NPDB query.  Another routing number, may be 
-   meaningful within the Current Serving Network, will replace the 
-   previously prefixed routing number in the ISUP CdPN parameter.  For 
-   the latter case, the call is routed to the Current Serving Switch 
-   without an additional NPDB query. 
-    
-
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 15] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   When the terminating switch receives the IAM and sees its own 
-   routing prefix in the CdPN parameter, it retrieves the originally 
-   dialed directory number after the routing prefix, and uses the 
-   dialed directory number to terminate the call.  
-    
-   The call routing example described above shows one of the three 
-   methods that can be used to transport the Directory Number (DN) and 
-   the Routing Number (RN) in the ISUP IAM message.  In addition, some 
-   other information may be added/modified as is listed in the ETSI 302 
-   097 document [ETSIISUP], which is based on the ITU-T Recommendation 
-   Q.769.1 [ITUISUP].  The three methods and the enhancements in the 
-   ISUP to support number portability are briefly described below 
-    
-   (a) Two separate parameters with the CdPN parameter containing the 
-      RN and a new Called Directory Number (CdDN) parameter containing 
-      the DN.  A new value for the Nature of Address (NOA) indicator in 
-      the CdPN parameter is defined to indicate that the RN is in the 
-      CdPN parameter.  The switches use the CdPN parameter to route the 
-      call as is done today. 
-    
-   (b) Two separate parameters with the CdPN parameter containing the 
-      DN and a new Network Routing Number (NRN) parameter containing 
-      the RN.  This method requires that the switches use the NRN 
-      parameter to route the call. 
-    
-   (c) Concatenated parameter with the CdPN parameter containing the RN 
-      plus the DN.  A new Nature of Address (NOA) indicator in the CdPN 
-      parameter is defined to indicate that the RN is concatenated with 
-      the DN in the CdPN parameter.  Some countries may not use new NOA 
-      value because the routing prefix does not overlap with the dialed 
-      directory numbers.  But if the routing prefix overlaps with the 
-      dialed directory numbers, a new NOA value must be assigned.  For 
-      example, Spain uses "XXXXXX" as the routing prefix to identify 
-      the new serving network and uses a new NOA value of 126. 
-    
-   There is also a network option to add a new ISUP parameter called 
-   Number Portability Forwarding Information parameter.  This parameter 
-   has a four-bit Number Portability Status Indicator field that can 
-   provide an indication whether number portability query is done for 
-   the called directory number and whether the called directory number 
-   is ported or not if the number portability query is done. 
- 
-   Please note that all those NP enhancements for a ported number can 
-   only be used in the country that defined them.  This is because 
-   number portability is supported within a nation.  Within each 
-   nation, the telecommunications industry or the regulatory bodies can 
-   decide which method or methods to use.  Number portability related 
-   parameters and coding are usually not passed across the national 
-   boundaries unless the interconnection agreements allow that.  For 
-   example, a UK routing prefix can only be used in UK, and would cause 
-   routing problem if it appears outside UK. 
-    
-
-
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 16] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   As indicated earlier, an originating wireless network can query the 
-   NPDB and concatenate the RN with DN in the CdPN parameter and route 
-   the call directly to the Current Serving Network.   
-    
-   If NPDBs do not contain information about the wireless directory 
-   numbers, the call, originated from either a wireline or a wireless 
-   network, will be routed to the Wireless donor network.  Over there, 
-   an internal NPDB is queried to retrieve the RN that then is 
-   concatenated with the DN in the CdPN parameter. 
-    
-   There are several ways of realizing MNP.  When MNP-SRF is supported, 
-   the Gateway Mobile Services Switching Center (GMSC) at the wireless 
-   donor network, when receiving a call from the wireline network, can 
-   send the GSM MAP Send Routing Information (SRI) message to the MNP-
-   SRF.  The MNP-SRF interrogates an internal or integrated NPDB for 
-   the RN of the MNP-SRF of the wireless Current Serving Network and 
-   prefixes the RN to the dialed wireless directory number in the 
-   global title address information in the SCCP Called Party Address 
-   (CdPA) parameter.  This SRI message will be routed to the MNP-SRF of 
-   the wireless Current Serving Network, which then responds with an 
-   acknowledgement by providing the RN plus the dialed wireless 
-   directory number as the Mobile Station Roaming Number (MSRN).  The 
-   GMSC of the wireless donor network formulates the ISUP IAM with the 
-   RN plus the dialed wireless directory number in the CdPN parameter 
-   and routes the call to the wireless Current Serving Network.  A GMSC 
-   of the wireless Current Serving Network receives the call and sends 
-   an SRI message to the associated MNP-SRF where the global title 
-   address information of the SCCP CdPA parameter contains only the 
-   dialed wireless directory number.  The MNP-SRF then replaces the 
-   global title address information in the SCCP CdPA parameter with the 
-   address information associated with a Home Location Register (HLR) 
-   that hosts the dialed wireless directory number and forwards the 
-   message to that HLR after verifying that the dialed wireless 
-   directory number is a ported-in number.   The HLR then returns an 
-   acknowledgement by providing an MSRN for the GMSC to route the call 
-   to the MSC that currently serves the mobile station that is 
-   associated with the dialed wireless directory number.  Please see 
-   [MNP] for details and additional scenarios. 
-    
-    
-7. NP Implementations for Geographic E.164 Numbers 
- 
-   This section shows the known SPNP implementations worldwide.  
-    
-   +-------------+----------------------------------------------------+ 
-   +   Country   +             SPNP Implementation                    + 
-   +-------------+----------------------------------------------------+ 
-   +  Argentina  + Analyzing operative viability now. Will determine  + 
-   +             + whether portability should be made obligatory      + 
-   +             + after a technical solution has been determined.    + 
-   +-------------+----------------------------------------------------+ 
-   +  Australia  + NP supported by wireline operators since 11/30/99. + 
-   +             + NP among wireless operators in March/April 2000,   + 
-
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 17] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   +             + but may be delayed to 1Q01. The access provider    + 
-   +             + or long distance provider has the obligation to    + 
-   +             + route the call to the correct destination. The     + 
-   +             + donor network is obligated to maintain and make    + 
-   +             + available a register of numbers ported away from   +  
-   +             + its network.  Telstra uses onward routing via an   + 
-   +             + on-switch solution.                                + 
-   +-------------+----------------------------------------------------+ 
-   +   Austria   + Uses onward routing at the donor network.  Routing + 
-   +             + prefix is "86xx" where "xx" identifies the         + 
-   +             + recipient network.                                 + 
-   +-------------+----------------------------------------------------+ 
-   +  Belgium    + ACQ selected by the industry. Routing prefix is    + 
-   +             + "Cxxxx" where "xxxx" identifies the recipient      + 
-   +             + switch. Another routing prefix is "C00xx" with "xx"+ 
-   +             + identifying the recipient network.  Plan to use NOA+ 
-   +             + to identify concatenated numbers and abandon the   + 
-   +             + hexadecimal routing prefix.                        + 
-   +-------------+----------------------------------------------------+ 
-   +  Brazil     + Considering NP for wireless users.                 + 
-   +-------------+----------------------------------------------------+ 
-   +  Chile      + There has been discussions lately on NP.           + 
-   +-------------+----------------------------------------------------+ 
-   +  Colombia   + There was an Article 3.1 on NP to support NP prior + 
-   +             + to December 31, 1999 when NP became technically    + 
-   +             + possible. Regulator has not yet issued regulations + 
-   +             + concerning this matter.                            + 
-   +-------------+----------------------------------------------------+ 
-   +  Denmark    + Uses ACQ. Routing number not passed between        + 
-   +             + operators; however, NOA is set to "112" to         + 
-   +             + indicate "ported number."  QoR can be used based   + 
-   +             + on bilateral agreements.                           +        
-   +-------------+----------------------------------------------------+ 
-   +  Finland    + Uses ACQ.  Routing prefix is "1Dxxy" where "xxy"   + 
-   +             + identifies the recipient network and service type. + 
-   +-------------+----------------------------------------------------+ 
-   +  France     + Uses onward routing.  Routing prefix is "Z0xxx"    + 
-   +             + where "xxx" identifies the recipient switch.       + 
-   +-------------+----------------------------------------------------+ 
-   +  Germany    + The originating network needs to do necessary      + 
-   +             + rerouting.  Operators decide their own solution(s).+ 
-   +             + Deutsche Telekom uses ACQ.  Routing prefix is      + 
-   +             + "Dxxx" where "xxx" identifies the recipient        + 
-   +             + network.                                           + 
-   +-------------+----------------------------------------------------+ 
-   +  Hong Kong  + Recipient network informs other networks about     + 
-   +             + ported-in numbers.  Routing prefix is "14x" where  + 
-   +             + "14x" identifies the recipient network, or a       + 
-   +             + routing number of "4x" plus 7 or 8 digits is used  +  
-   +             + where "4x" identifies the recipient network and    + 
-   +             + the rest of digits identify the called party.      + 
-   +-------------+----------------------------------------------------+ 
-   +  Ireland    + Operators choose their own solution but use onward + 
-   +             + routing now. Routing prefix is "1750" as the intra-+ 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 18] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   +             + network routing code (network-specific) and        + 
-   +             + "1752xxx" to "1759xxx" for GNP where "xxx"         + 
-   +             + identifies the recipient switch.                   + 
-   +-------------+----------------------------------------------------+ 
-   +  Italy      + Uses onward routing. Routing prefix is "C600xxxxx" + 
-   +             + where "xxxxx" identifies the recipient switch.     + 
-   +             + Telecom Italia uses IN solution and other operators+              
-   +             + use on-switch solution.                            + 
-   +-------------+----------------------------------------------------+ 
-   +  Japan      + Uses onward routing.  Donor switch uses IN to get  + 
-   +             + routing number.                                    + 
-   +-------------+----------------------------------------------------+ 
-   +  Mexico     + NP is considered in the Telecom law; however, the  + 
-   +             + regulator (Cofetel) or the new local entrants have + 
-   +             + started no initiatives on this process.            + 
-   +-------------+----------------------------------------------------+ 
-   + Netherlands + Operators decide NP scheme to use.  Operators have + 
-   +             + chosen ACQ or QoR.  KPN implemented IN solution    + 
-   +             + similar to U.S. solution.  Routing prefix is not   + 
-   +             + passed between operators.                          + 
-   +-------------+----------------------------------------------------+ 
-   +  Norway     + OR for short-term and ACQ for long-term.  QoR is   + 
-   +             + optional. Routing prefix can be "xxx" with NOA=8,  + 
-   +             + or "142xx" with NOA=3 where "xxx" or "xx"          + 
-   +             + identifies the recipient network.                  + 
-   +------------ +----------------------------------------------------+ 
-   +  Peru       + Wireline NP may be supported in 2001.              + 
-   +-------------+----------------------------------------------------+ 
-   +  Portugal   + No NP today.                                       + 
-   +-------------+----------------------------------------------------+ 
-   +  Spain      + Uses ACQ.  Telefonica uses QoR within its network. + 
-   +             + Routing prefix is  "xxyyzz" where "xxyyzz"         + 
-   +             + identifies the recipient network.  NOA is set to   + 
-   +             + 126.                                               + 
-   +-------------+----------------------------------------------------+ 
-   +  Sweden     + Standardized the ACQ but OR for operators without  + 
-   +             + IN. Routing prefix is "xxx" with NOA=8 or "394xxx" + 
-   +             + with NOA=3 where "xxx" identifies the recipient    + 
-   +             + network. But operators decide NP scheme to use.    + 
-   +             + Telia uses onward routing between operators.       + 
-   +-------------+----------------------------------------------------+ 
-   + Switzerland + Uses OR now and QoR in 2001.  Routing prefix is    + 
-   +             + "980xxx" where "xxx" identifies the recipient      +        
-   +             + network.                                           + 
-   +-------------+----------------------------------------------------+ 
-   +  UK         + Uses onward routing. Routing prefix is "5xxxxx"    + 
-   +             + where "xxxxx" identifies the recipient switch. NOA + 
-   +             + is 126. BT uses the dropback scheme in some parts  + 
-   +             + of its network.                                    + 
-   +-------------+----------------------------------------------------+ 
-   +  US         + Uses ACQ.  "Location Routing Number (LRN)" is used + 
-   +             + in the Called Party Number parameter.  Called party+ 
-   +             + number is carried in the Generic Address Parameter + 
-   +             + Use a PNTI indicator in the Forward Call Indicator + 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 19] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   +             + parameter to indicate that NPDB dip has been       + 
-   +             + performed.                                         + 
-   +-------------+----------------------------------------------------+ 
-    
-    
-8. Number Conservation Methods Enabled by NP 
- 
-   In addition to porting numbers NP provides the ability for number 
-   administrators to assign numbering resources to operators in smaller 
-   increments.  Today it is common for numbering resources to be 
-   assigned to telephone operators in a large block of consecutive 
-   telephone numbers (TNs).  For example, in North America each of 
-   these blocks contains 10,000 TNs and is of the format NXX+0000 to 
-   NXX+9999.  Operators are assigned a specific NXX, or block.  That 
-   operator is referred to as the block holder.  In that block there 
-   are 10,000 TNs with line numbers ranging from 0000 to 9999.   
-    
-   Instead of assigning an entire block to the operator NP allows the 
-   administrator to assign a sub-block or even an individual telephone 
-   number.  This is referred to as block pooling and individual 
-   telephone number (ITN) pooling, respectively.  
-     
-    
-8.1 Block Pooling 
-    
-   Block Pooling refers to the process whereby the number administrator 
-   assigns a range of numbers defined by a logical sub-block of the 
-   existing block.  Using North America as an example, block pooling 
-   would allow the administrator to assign sub-blocks of 1,000 TNs to 
-   multiple operators.  That is, NXX+0000 to NXX+0999 can be assigned 
-   to operator A, NXX+1000 to NXX+1999 can be assigned to operator B, 
-   NXX-2000 to 2999 can be assigned to operator C, etc.  In this 
-   example block pooling divides one block of 10,000 TNs into ten 
-   blocks of 1,000 TNs.   
-    
-   Porting the sub-blocks from the block holder enables block pooling.  
-   Using the example above operator A is the block holder, as well as, 
-   the holder of the first sub-block, NXX+0000 to NXX+0999.  The second 
-   sub-block, NXX+1000 to NXX+1999, is ported from operator A to 
-   operator B.  The third sub-block, NXX+2000 to NXX+2999, is ported 
-   from operator A to operator C, and so on.  NP administrative 
-   processes and call processing will enable proper and efficient 
-   routing.   
-    
-   From a number administration and NP administration perspective block 
-   pooling introduces a new concept, that of the sub-block holder.  
-   Block pooling requires coordination between the number 
-   administrator, the NP administrator, the block holder, and the sub-
-   block holder.  Block pooling must be implemented in a manner that 
-   allows for NP within the sub-blocks.  Each TN can have a different 
-   serving operator, sub-block holder, and block holder. 
-      
-    
-    
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 20] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-8.2 ITN Pooling 
-    
-   ITN pooling refers to the process whereby the number administrator 
-   assigns individual telephone numbers to operators.  Using the North 
-   American example, one block of 10,000 TNs can be divided into 10,000 
-   ITNs.  ITN is more commonly deployed in freephone services.   
-    
-   In ITN the block is not assigned to an operator but to a central 
-   administrator.  The administrator then assigns ITNs to operators.  
-   NP administrative processes and call processing will enable proper 
-   and efficient routing. 
-    
- 
-9. Potential Implications 
-    
-   There are three general areas of impact to IP telephony work-in-
-   progress at IETF: 
-    
-   - Interoperation between NP in GSTN and IP telephony 
-   - NP implementation or emulation in IP telephony 
-   - Interconnection to NP administrative environment 
-    
-   A good understanding of how number portability is supported in the 
-   GSTN is important when addressing the interworking issues between 
-   IP-based networks and the GSTN.  This is especially important when 
-   the IP-based network needs to route the calls to the GSTN.  As shown 
-   in Section 5, there are a variety of standards with various protocol 
-   stacks for the switch-to-NPDB interface.  Not only that, the 
-   national variations of the protocol standards make it very 
-   complicated to deal with in a global environment.  If an entity in 
-   the IP-based network needs to query those existing NPDBs for routing 
-   number information to terminate the calls to the destination GSTN, 
-   it would be impractical, if not an impossible, job for that entity 
-   to support all those interface standards to access the NPDBs in many 
-   countries. 
-    
-   Several alternatives may address this particular problem.  One 
-   alternative is to use certain entities in the IP-based networks for 
-   dealing with NP query, similar to the International Switches that 
-   are used in the GSTN to interwork different national ISUP 
-   variations.  This will force signaling information associated with 
-   the calls to certain NP-capable networks in the terminating GSTN to 
-   be routed to those IP entities that support the NP functions.  Those 
-   IP entities then query the NPDBs in the terminating country.   This 
-   will limit the number of NPDB interfaces that certain IP entities 
-   need to support.  Another alternative can be to define a "common" 
-   interface to be supported by all the NPDBs so that all the IP 
-   entities use that standardized protocol to query them.   The 
-   existing NPDBs can support this additional interface, or new NPDBs 
-   can be deployed that contain the same information but support the 
-   common IP interface. The candidates for such a common interface 
-   include Lightweight Directory Access Protocol (LDAP) and SIP 
-   [SIP](e.g., using the SIP redirection capability).  Certainly 
-
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 21] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   another possibility is to use interworking function to convert from 
-   one protocol to another. 
-    
-   IP-based networks can handle the domestic calls between two GSTNs.  
-   If the originating GSTN has performed NPDB query, SIP will need to 
-   transport and make use of some of the ISUP signaling information 
-   even if ISUP signaling may be encapsulated in SIP.  Also, IP-based 
-   networks may perform the NPDB queries, as the N-1 carrier.  In that 
-   case, SIP also needs to transport the NP related information while 
-   the call is being routed to the destination GSTN.  There are three 
-   pieces of NP related information that SIP needs to transport.  They 
-   are 1) the called directory number, 2) a routing number, and 3) a 
-   NPDB dip indicator.  The NPDB dip indicator is needed so that the 
-   terminating GSTN will not perform another NPDB dip.  The routing 
-   number is needed so that it is used to route the call to the 
-   destination network or switch in the destination GSTN.  The called 
-   directory number is needed so that the terminating GSTN switch can 
-   terminate the call.  When the routing number is present, the NPDB 
-   dip indicator may not be present because there are cases where 
-   routing number is added for routing the call even if NP is not 
-   involved.  One issue is how to transport the NP related information 
-   via SIP.  The SIP Universal Resource Locator (URL) is one mechanism.  
-   Another better choice may be to add an extension to the "tel" URL 
-   [TEL] that is also supported by SIP.  Please see [TELNP] for the 
-   proposed extensions to the "tel" URL to support NP and freephone 
-   service.  Those extensions to the "tel" URL will be automatically 
-   supported by SIP because they can be carried as the optional 
-   parameters in the user portion of the "sip" URL. 
-    
-   For a called directory number that belongs to a country that 
-   supports NP, and if the IP-based network is to perform the NPDB 
-   query, the logical step is to perform the NPDB dip first to retrieve 
-   the routing number and use that routing number to select the correct 
-   IP telephony gateways that can reach the serving switch that serves 
-   the called directory number.  Therefore, if the "rn" parameter is 
-   present in the "tel" URL or sip URL in the SIP INVITE message, it 
-   instead of the called directory number should be used for making 
-   routing decisions assuming that no other higher priority routing-
-   related parameters such as the Ÿcic÷ are present.  If "rn" is not 
-   present, then the dialed directory number can be used as the routing 
-   number for making routing decisions.   
-    
-   Telephony Routing Information Protocol (TRIP) [TRIP] is a policy 
-   driven inter-administrative domain protocol for advertising the 
-   reachability of telephony destinations between location servers, and 
-   for advertising attributes of the routes to those destinations.  
-   With the NP in mind, it is very important to know that it is the 
-   routing number, if present, not the called directory number that 
-   should be used to check against the TRIP tables for making the 
-   routing decisions.   
-    
-   Overlap signaling exists in the GSTN today.  For a call routing from 
-   the originating GSTN to the IP-based network that involves overlap 
-   signaling, NP will impact the call processing within the IP-based 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 22] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   networks if they must deal with the overlap signaling.  The entities 
-   in the IP-based networks that are to retrieve the NP information 
-   (e.g., the routing number) must collect a complete called directory 
-   number information before retrieving the NP information for a ported 
-   number.  Otherwise, the information retrieval won't be successful.   
-   This is an issue for the IP-based networks if the originating GSTN 
-   does not handle the overlap signaling by collecting the complete 
-   called directory number. 
-    
-   The IETF enum working group is defining the use of Domain Name 
-   System (DNS) for identifying available services associated with a 
-   particular E.164 number [ENUM].  [ENUMPO] outlines the principles 
-   for the operation of a telephone number service that resolves 
-   telephone numbers into Internet domain name addresses and service-
-   specific directory discovery.  [ENUMPO] implements a three-level 
-   approach where the first level is the mapping of the telephone 
-   number delegation tree to the authority to which the number has been 
-   delegated, the second level is the provision of the requested DNS 
-   resource records from a service registrar, and the third level is 
-   the provision of service specific data from the service provider 
-   itself.  NP certainly must be considered at the first level because 
-   the telephony service providers do not "own" or control the 
-   telephone numbers under the NP environment; therefore, they may not 
-   be the proper entities to have the authority for a given E.164 
-   number.  Not only that, there is a regulatory requirement on NP in 
-   some countries that the donor network should not be relied on to 
-   reach the delegated authority during the DNS process .  The 
-   delegated authority for a given E.164 number is likely to be an 
-   entity designated by the end user that owns/controls a specific 
-   telephone number or one that is designated by the service registrar. 
-    
-   Since the telephony service providers may have the need to use ENUM 
-   for their network-related services (e.g., map an E.164 number to a 
-   HLR Identifier in the wireless networks), their ENUM records must be 
-   collocated with those of the telephony subscribers.  If that is the 
-   case, NP will impact ENUM when a telephony subscriber who has ENUM 
-   service changes the telephony service provider.  This is because 
-   that the ENUM records from the new telephony service provider must 
-   replace those from the old telephony service provider.  To avoid the 
-   NP impact on ENUM, it is recommended that the telephony service 
-   providers use a different domain tree for their network-related 
-   service.  For example, if e164.arpa is chosen for Ÿend user÷ ENUM, a 
-   domain tree different from e164.arpa should be used for Ÿcarrier÷ 
-   ENUM. 
-    
-   The IP-based networks also may need to support some forms of number 
-   portability in the future if E.164 numbers [E164] are assigned to 
-   the IP-based end users.  One method is to assign a GSTN routing 
-   number for each IP-based network domain or entity in a NP-capable 
-   country.  This may increase the number of digits in the routing 
-   number to incorporate the IP entities and impact the existing 
-   routing in the GSTN.  Another method is to associate each IP entity 
-   with a particular GSTN gateway.  At that particular GSTN gateway, 
-   the called directory number then is used to locate the IP-entity 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 23] 
-
-Number Portability in the GSTN: An Overview               June 24, 2002 
-
-   that serves that dialed directory number.  Yet, another method can 
-   be to assign a special routing number so that the call to an end 
-   user currently served by an IP entity is routed to the nearest GSTN 
-   gateway.  The called directory number then is used to locate the IP-
-   entity that serves that dialed directory number.  A mechanism can be 
-   developed or used for the IP-based network to locate the IP entity 
-   that serves a particular dialed directory number.  Many other types 
-   of networks use E.164 numbers to identify the end users or terminals 
-   in those networks.  Number portability among GSTN, IP-based network 
-   and those various types of networks may also need to be supported in 
-   the future. 
-    
- 
-10. Security Considerations 
- 
-   This document does not raise any security issues. 
- 
- 
-11. IANA Considerations 
- 
-   This document introduces no new values for IANA registration. 
-    
- 
-12. Normative References  
- 
-   [ANSI OSS] ANSI Technical Requirements No. 1, "Number Portability -
-        Operator Services Switching Systems," April 1999. 
-    
-   [ANSI SS] ANSI Technical Requirements No. 2, "Number Portability -
-        Switching Systems," April 1999. 
-             
-   [ANSI DB] ANSI Technical Requirements No. 3, "Number Portability 
-        Database and Global Title Translation," April 1999.         
-          
-   [CS1] ITU-T Q-series  Recommendations - Supplement 4, "Number 
-        portability Capability set 1 requirements for service provider 
-        portability (All call query and onward routing)," May 1998. 
-    
-   [CS2] ITU-T Q-series  Recommendations - Supplement 5, "Number 
-        portability -Capability set 2 requirements for service provider 
-        portability (Query on release and Dropback)," March 1999. 
-    
-   [E164] ITU-T Recommendation E.164, "The International Public 
-        Telecommunications Numbering Plan," 1997. 
-    
-   [ENUM] P. Falstrom, "E.164 number and DNS," RFC 2916. 
-    
-   [ETSIISUP] ETSI EN 302 097 V.1.2.2, ŸIntegrated Services Digital 
-        Network (ISDN); Signalling System No.7 (SS7); ISDN User Part 
-        (ISUP); Enhancement for support of Number Portability (NP) 
-        [ITU-T Recommendation Q.769.1 (2000), modified] 
-    
-   [GSM]  GSM 09.02: "Digital cellular telecommunications system (Phase 
-        2+); Mobile Application Part (MAP) specification". 
-  
-Foster,McGarry,Yu           Expired on December 23, 2002      [Page 24] 
-
-Number Portability in the GSTN: An Overview              March 1, 2002 
- 
- 
- 
-   [IS41] TIA/EIA IS-756 Rev. A, "TIA/EIA-41-D Enhancements for 
-        Wireless Number Portability Phase II (December 1998)"Number 
-        Portability Network Support," April 1998. 
-    
-   [ITUISUP] ITU-T Recommendation Q.769.1, "Signaling System No. 7 - 
-        ISDN User Part Enhancements for the Support of Number 
-        Portability," December 1999. 
-    
-   [MNP] ETSI EN 301 716 (2000-10) European Standard 
-        (Telecommunications series) Digital cellular telecommunications 
-        system (Phase 2+); Support of Mobile Number Portability (MNP); 
-        Technical Realisation; Stage 2; (GSM 03.66 Version 7.2.0 
-        Release 1998). 
-    
-   [RFC] Scott Bradner, RFC2026, "The Internet Standards Process -- 
-        Revision 3," October 1996. 
-    
- 
-13. Informative References  
- 
-   [ENUMPO] A. Brown and G. Vaudreuil, "ENUM Service Specific 
-        Provisioning: Principles of Operations," draft-ietf-enum-
-        operation-02.txt, February 23, 2001. 
-    
-   [SIP] J. Rosenberg, et al., draft-ietf-sip-rfc2543bis-09.txt, "SIP: 
-        Session Initiation Protocol," February 27, 2002. 
-    
-   [TEL] H. Schulzrinne and A. Vaha-Sipila, draft-antti-rfc2806bis-
-        04.txt, "URIs for Telephone Calls," May 24, 2002. 
- 
-   [TELNP] J. Yu, draft-yu-tel-url-05.txt, "Extensions to the "tel" URL 
-        to support Number Portability and Freephone Service," June 14, 
-        2002. 
-    
-   [TRIP] J. Rosenberg, H. Salama and M. Squire, RFC 3219, "Telephony 
-        Routing Information Protocol (TRIP)," January 2002. 
-    
-    
-14. Acknowledgment 
-    
-   The authors would like to thank Monika Muench for providing 
-   information on ISUP and MNP. 
-    
-    
-15. Authors' Addresses 
-    
-   Mark D. Foster 
-   NeuStar, Inc. 
-   1120 Vermont Avenue, NW, 
-   Suite 400 
-   Washington, D.C. 20005 
-   United States 
-  
-Foster,McGarry,Yu           Expired on August 31, 2002        [Page 25] 
-
-Number Portability in the GSTN: An Overview              March 1, 2002 
- 
- 
-    
-   Phone: +1-202-533-2800 
-   Fax:   +1-202-533-2987 
-   Email: mark.foster@neustar.biz 
-          
-   Tom McGarry 
-   NeuStar, Inc. 
-   1120 Vermont Avenue, NW, 
-   Suite 400 
-   Washington, D.C. 20005 
-   United States 
-    
-   Phone: +1-202-533-2810 
-   Fax:   +1-202-533-2987 
-   Email: tom.mcgarry@neustar.biz 
-    
-   James Yu 
-   NeuStar, Inc. 
-   1120 Vermont Avenue, NW,  
-   Suite 400 
-   Washington, D.C. 20005 
-   United States 
-    
-   Phone: +1-202-533-2814 
-   Fax:   +1-202-533-2987 
-   Email: james.yu@neustar.biz 
-    
-    
-    
-Full Copyright Statement 
- 
-   "Copyright (C) The Internet Society (2002). 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. 
-    
-
-  
-Foster,McGarry,Yu           Expired on August 31, 2002        [Page 26] 
-
-Number Portability in the GSTN: An Overview              March 1, 2002 
- 
- 
-   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. 
- 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Foster,McGarry,Yu           Expired on August 31, 2002        [Page 27] 
-
\ No newline at end of file
diff --git a/contrib/bind9/doc/draft/draft-ietf-ipv6-node-requirements-08.txt b/contrib/bind9/doc/draft/draft-ietf-ipv6-node-requirements-08.txt
deleted file mode 100644
index 2d5c87e..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-ipv6-node-requirements-08.txt
+++ /dev/null
@@ -1,1200 +0,0 @@
-
-
-
-
-
-
-IPv6 Working Group                                 John Loughney (ed)
-Internet-Draft                                                  Nokia
-                                                     January 14, 2004
-
-Expires: July 14, 2004
-
-
-
-                         IPv6 Node Requirements
-                draft-ietf-ipv6-node-requirements-08.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.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   This document defines requirements for IPv6 nodes.  It is expected
-   that IPv6 will be deployed in a wide range of devices and situations.
-   Specifying the requirements for IPv6 nodes allows IPv6 to function
-   well and interoperate in a large number of situations and
-   deployments.
-
-
-
-
-
-Loughney (editor)          February 16, 2004                    [Page 1]
-
-
-
-
-
-Internet-Draft
-
-
-Table of Contents
-
-   1.   Introduction
-   1.1 Requirement Language
-   1.2  Scope of this Document
-   1.3  Description of IPv6 Nodes
-   2.   Abbreviations Used in This Document
-   3.   Sub-IP Layer
-   3.1  Transmission of IPv6 Packets over Ethernet Networks - RFC2464
-   3.2  IP version 6 over PPP - RFC2472
-   3.3  IPv6 over ATM Networks - RFC2492
-   4.   IP Layer
-   4.1  Internet Protocol Version 6 - RFC2460
-   4.2  Neighbor Discovery for IPv6 - RFC2461
-   4.3  Path MTU Discovery & Packet Size
-   4.4  ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463
-   4.5  Addressing
-   4.6  Multicast Listener Discovery (MLD) for IPv6 - RFC2710
-   5.   Transport and DNS
-   5.1  Transport Layer
-   5.2  DNS
-   5.3  Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
-   6.   IPv4 Support and Transition
-   6.1  Transition Mechanisms
-   7.   Mobility
-   8.   Security
-   8.1  Basic Architecture
-   8.2  Security Protocols
-   8.3  Transforms and Algorithms
-   8.4  Key Management Methods
-   9.   Router Functionality
-   9.1  General
-   10.  Network Management
-   10.1 MIBs
-   11.  Security Considerations
-   12.  References
-   12.1 Normative
-   12.2 Non-Normative
-   13.  Authors and Acknowledgements
-   14.  Editor's Address
-   Notices
-
-
-
-
-
-
-
-
-
-
-Loughney (editor)          February 16, 2004                    [Page 2]
-
-
-
-
-
-Internet-Draft
-
-
-1. Introduction
-
-   The goal of this document is to define the common functionality
-   required from both IPv6 hosts and routers.  Many IPv6 nodes will
-   implement optional or additional features, but all IPv6 nodes can be
-   expected to implement the mandatory requirements listed in this
-   document.
-
-   This document tries to avoid discussion of protocol details, and
-   references RFCs for this purpose.  In case of any conflicting text,
-   this document takes less precedence than the normative RFCs, unless
-   additional clarifying text is included in this document.
-
-   Although the document points to different specifications, it should
-   be noted that in most cases, the granularity of requirements are
-   smaller than a single specification, as many specifications define
-   multiple, independent pieces, some of which may not be mandatory.
-
-   As it is not always possible for an implementer to know the exact
-   usage of IPv6 in a node, an overriding requirement for IPv6 nodes is
-   that they should adhere to Jon Postel's Robustness Principle:
-
-      Be conservative in what you do, be liberal in what you accept from
-      others [RFC-793].
-
-1.1 Requirement Language
-
-   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 [RFC-2119].
-
-1.2 Scope of this Document
-
-   IPv6 covers many specifications.  It is intended that IPv6 will be
-   deployed in many different situations and environments.  Therefore,
-   it is important to develop the requirements for IPv6 nodes, in order
-   to ensure interoperability.
-
-   This document assumes that all IPv6 nodes meet the minimum
-   requirements specified here.
-
-1.3 Description of IPv6 Nodes
-
-   From Internet Protocol, Version 6 (IPv6) Specification [RFC-2460] we
-   have the following definitions:
-
-      Description of an IPv6 Node
-
-
-
-
-Loughney (editor)          February 16, 2004                    [Page 3]
-
-
-
-
-
-Internet-Draft
-
-
-       - a device that implements IPv6
-
-      Description of an IPv6 router
-
-       - a node that forwards IPv6 packets not explicitly addressed to
-         itself.
-
-      Description of an IPv6 Host
-
-       - any node that is not a router.
-
-2. Abbreviations Used in This Document
-
-   ATM   Asynchronous Transfer Mode
-
-   AH    Authentication Header
-
-   DAD   Duplicate Address Detection
-
-   ESP   Encapsulating Security Payload
-
-   ICMP  Internet Control Message Protocol
-
-   IKE   Internet Key Exchange
-
-   MIB   Management Information Base
-
-   MLD   Multicast Listener Discovery
-
-   MTU   Maximum Transfer Unit
-
-   NA    Neighbor Advertisement
-
-   NBMA  Non-Broadcast Multiple Access
-
-   ND    Neighbor Discovery
-
-   NS    Neighbor Solicitation
-
-   NUD   Neighbor Unreachability Detection
-
-   PPP   Point-to-Point Protocol
-
-   PVC   Permanent Virtual Circuit
-
-   SVC   Switched Virtual Circuit
-
-3. Sub-IP Layer
-
-
-
-Loughney (editor)          February 16, 2004                    [Page 4]
-
-
-
-
-
-Internet-Draft
-
-
-   An IPv6 node must include support for one or more IPv6 link-layer
-   specifications.  Which link-layer specifications are included will
-   depend upon what link-layers are supported by the hardware available
-   on the system.  It is possible for a conformant IPv6 node to support
-   IPv6 on some of its interfaces and not on others.
-
-   As IPv6 is run over new layer 2 technologies, it is expected that new
-   specifications will be issued.  This section highlights some major
-   layer 2 technologies and is not intended to be complete.
-
-3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464
-
-   Nodes supporting IPv6 over Ethernet interfaces MUST implement
-   Transmission of IPv6 Packets over Ethernet Networks [RFC-2464].
-
-3.2 IP version 6 over PPP - RFC2472
-
-   Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP [RFC-
-   2472].
-
-3.3 IPv6 over ATM Networks - RFC2492
-
-   Nodes supporting IPv6 over ATM Networks MUST implement IPv6 over ATM
-   Networks [RFC-2492].  Additionally, RFC 2492 states:
-
-      A minimally conforming IPv6/ATM driver SHALL support the PVC mode
-      of operation. An IPv6/ATM driver that supports the full SVC mode
-      SHALL also support PVC mode of operation.
-
-4. IP Layer
-
-4.1 Internet Protocol Version 6 - RFC2460
-
-   The Internet Protocol Version 6 is specified in [RFC-2460]. This
-   specification MUST be supported.
-
-   Unrecognized options in Hop-by-Hop Options or Destination Options
-   extensions MUST be processed as described in RFC 2460.
-
-   The node MUST follow the packet transmission rules in RFC 2460.
-
-   Nodes MUST always be able to send, receive and process fragment
-   headers.  All conformant IPv6 implementations MUST be capable of
-   sending and receving IPv6 packets; forwarding functionality MAY be
-   supported
-
-   RFC 2460 specifies extension headers and the processing for these
-   headers.
-
-
-
-Loughney (editor)          February 16, 2004                    [Page 5]
-
-
-
-
-
-Internet-Draft
-
-
-      A full implementation of IPv6 includes implementation of the
-      following extension headers: Hop-by-Hop Options, Routing (Type 0),
-      Fragment, Destination Options, Authentication and Encapsulating
-      Security Payload. [RFC-2460]
-
-   An IPv6 node MUST be able to process these headers.  It should be
-   noted that there is some discussion about the use of Routing Headers
-   and possible security threats [IPv6-RH] caused by them.
-
-4.2 Neighbor Discovery for IPv6 - RFC2461
-
-   Neighbor Discovery SHOULD be supported.  RFC 2461 states:
-
-      "Unless specified otherwise (in a document that covers operating
-      IP over a particular link type) this document applies to all link
-      types. However, because ND uses link-layer multicast for some of
-      its services, it is possible that on some link types (e.g., NBMA
-      links) alternative protocols or mechanisms to implement those
-      services will be specified (in the appropriate document covering
-      the operation of IP over a particular link type).  The services
-      described in this document that are not directly dependent on
-      multicast, such as Redirects, Next-hop determination, Neighbor
-      Unreachability Detection, etc., are expected to be provided as
-      specified in this document.  The details of how one uses ND on
-      NBMA links is an area for further study."
-
-   Some detailed analysis of Neighbor Discovery follows:
-
-   Router Discovery is how hosts locate routers that reside on an
-   attached link. Router Discovery MUST be supported for
-   implementations.
-
-   Prefix Discovery is how hosts discover the set of address prefixes
-   that define which destinations are on-link for an attached link.
-   Prefix discovery MUST be supported for implementations. Neighbor
-   Unreachability Detection (NUD) MUST be supported for all paths
-   between hosts and neighboring nodes. It is not required for paths
-   between routers.  However, when a node receives a unicast Neighbor
-   Solicitation (NS) message (that may be a NUD's NS), the node MUST
-   respond to it (i.e. send a unicast Neighbor Advertisement).
-
-   Duplicate Address Detection MUST be supported on all links supporting
-   link-layer multicast (RFC2462 section 5.4 specifies DAD MUST take
-   place on all unicast addresses).
-
-   A host implementation MUST support sending Router Solicitations.
-
-   Receiving and processing Router Advertisements MUST be supported for
-
-
-
-Loughney (editor)          February 16, 2004                    [Page 6]
-
-
-
-
-
-Internet-Draft
-
-
-   host implementations. The ability to understand specific Router
-   Advertisement options is dependent on supporting the specification
-   where the RA is specified.
-
-   Sending and Receiving Neighbor Solicitation (NS) and Neighbor
-   Advertisement (NA) MUST be supported. NS and NA messages are required
-   for Duplicate Address Detection (DAD).
-
-   Redirect functionality SHOULD be supported. If the node is a router,
-   Redirect functionality MUST be supported.
-
-4.3 Path MTU Discovery & Packet Size
-
-4.3.1 Path MTU Discovery - RFC1981
-
-   Path MTU Discovery [RFC-1981] SHOULD be supported, though minimal
-   implementations MAY choose to not support it and avoid large packets.
-   The rules in RFC 2460 MUST be followed for packet fragmentation and
-   reassembly.
-
-4.3.2 IPv6 Jumbograms - RFC2675
-
-   IPv6 Jumbograms [RFC-2675] MAY be supported.
-
-4.4  ICMP for the Internet Protocol Version 6 (IPv6) - RFC2463
-
-   ICMPv6 [RFC-2463] MUST be supported.
-
-4.5 Addressing
-
-4.5.1 IP Version 6 Addressing Architecture - RFC3513
-
-   The IPv6 Addressing Architecture [RFC-3513] MUST be supported.
-
-4.5.2 IPv6 Stateless Address Autoconfiguration - RFC2462
-
-   IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462].
-   This specification MUST be supported for nodes that are hosts.
-
-   Nodes that are routers MUST be able to generate link local addresses
-   as described in RFC 2462 [RFC-2462].
-
-   From 2462:
-
-      The autoconfiguration process specified in this document applies
-      only to hosts and not routers. Since host autoconfiguration uses
-      information advertised by routers, routers will need to be
-      configured by some other means. However, it is expected that
-
-
-
-Loughney (editor)          February 16, 2004                    [Page 7]
-
-
-
-
-
-Internet-Draft
-
-
-      routers will generate link-local addresses using the mechanism
-      described in this document. In addition, routers are expected to
-      successfully pass the Duplicate Address Detection procedure
-      described in this document on all addresses prior to assigning
-      them to an interface.
-
-   Duplicate Address Detection (DAD) MUST be supported.
-
-4.5.3 Privacy Extensions for Address Configuration in IPv6 - RFC3041
-
-   Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041]
-   SHOULD be supported.  It is recommended that this behavior be
-   configurable on a connection basis within each application when
-   available.  It is noted that a number of applications do not work
-   with addresses generated with this method, while other applications
-   work quite well with them.
-
-4.5.4 Default Address Selection for IPv6 - RFC3484
-
-   The rules specified in the Default Address Selection for IPv6 [RFC-
-   3484] document MUST be implemented. It is expected that IPv6 nodes
-   will need to deal with multiple addresses.
-
-4.5.5 Stateful Address Autoconfiguration
-
-   Stateful Address Autoconfiguration MAY be supported. DHCPv6 [RFC-
-   3315] is the standard stateful address configuration protocol; see
-   section 5.3 for DHCPv6 support.
-
-   Nodes which do not support Stateful Address Autoconfiguration may be
-   unable to obtain any IPv6 addresses aside from link-local addresses
-   when it receives a router advertisement with the 'M' flag (Managed
-   address configuration) set and which contains no prefixes advertised
-   for Stateless Address Autoconfiguration (see section 4.5.2).
-   Additionally, such nodes will be unable to obtain other configuration
-   information such as the addresses of DNS servers when it is connected
-   to a link over which the node receives a router advertisement in
-   which the 'O' flag ("Other stateful configuration") is set.
-
-4.6 Multicast Listener Discovery (MLD) for IPv6 - RFC2710
-
-   Nodes that need to join multicast groups SHOULD implement MLDv2
-   [MLDv2]. However, if the node has applications, which only need
-   support for Any- Source Multicast [RFC3569], the node MAY implement
-   MLDv1 [MLDv1] instead. If the node has applications, which need
-   support for Source- Specific Multicast [RFC3569, SSMARCH], the node
-   MUST support MLDv2 [MLDv2].
-
-
-
-
-Loughney (editor)          February 16, 2004                    [Page 8]
-
-
-
-
-
-Internet-Draft
-
-
-   When MLD is used, the rules in "Source Address Selection for the
-   Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be
-   followed.
-
-5. Transport Layer and DNS
-
-5.1 Transport Layer
-
-5.1.1 TCP and UDP over IPv6 Jumbograms - RFC2147
-
-   This specification MUST be supported if jumbograms are implemented
-   [RFC- 2675].
-
-5.2 DNS
-
-   DNS, as described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363]
-   and [RFC-3596] MAY be supported.  Not all nodes will need to resolve
-   names. All nodes that need to resolve names SHOULD implement stub-
-   resolver [RFC-1034] functionality, in RFC 1034 section 5.3.1 with
-   support for:
-
-    - AAAA type Resource Records [RFC-3596];
-    - reverse addressing in ip6.arpa using PTR records [RFC-3152];
-    - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512
-      octets.
-
-   Those nodes are RECOMMENDED to support DNS security extentions
-   [DNSSEC- INTRO], [DNSSEC-REC] and [DNSSEC-PROT].
-
-   Those nodes are NOT RECOMMENDED to support the experimental A6 and
-   DNAME Resource Records [RFC-3363].
-
-5.2.2 Format for Literal IPv6 Addresses in URL's - RFC2732
-
-   RFC 2732 MUST be supported if applications on the node use URL's.
-
-5.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) - RFC3315
-
-5.3.1 Managed Address Configuration
-
-   Those IPv6 Nodes that use DHCP for address assignment initiate DHCP
-   to obtain IPv6 addresses and other configuration information upon
-   receipt of a Router Advertisement with the 'M' flag set, as described
-   in section 5.5.3 of RFC 2462.  In addition, in the absence of a
-   router, those IPv6 Nodes that use DHCP for address assignment MUST
-   initiate DHCP to obtain IPv6 addresses and other configuration
-   information, as described in section 5.5.2 of RFC 2462.  Those IPv6
-   nodes that do not use DHCP for address assignment can ignore the 'M'
-
-
-
-Loughney (editor)          February 16, 2004                    [Page 9]
-
-
-
-
-
-Internet-Draft
-
-
-   flag in Router Advertisements.
-
-5.3.2 Other Configuration Information
-
-   Those IPv6 Nodes that use DHCP to obtain other configuration
-   information initiate DHCP for other configuration information upon
-   receipt of a Router Advertisement with the 'O' flag set, as described
-   in section 5.5.3 of RFC 2462.  Those IPv6 nodes that do not use DHCP
-   for other configuration information can ignore the 'O' flag in Router
-   Advertisements.
-
-   An IPv6 Node can use the subset of DHCP described in [DHCPv6-SL] to
-   obtain other configuration information.
-
-6. IPv4 Support and Transition
-
-   IPv6 nodes MAY support IPv4.
-
-6.1 Transition Mechanisms
-
-6.1.1 Transition Mechanisms for IPv6 Hosts and Routers - RFC2893
-
-   If an IPv6 node implements dual stack and tunneling, then RFC2893
-   MUST be supported.
-
-   RFC 2893 is currently being updated.
-
-7. Mobile IP
-
-   The Mobile IPv6 [MIPv6] specification defines requirements for the
-   following types of nodes:
-
-       - mobile nodes
-       - correspondent nodes with support for route optimization
-       - home agents
-       - all IPv6 routers
-
-   Hosts MAY support mobile node functionality described in Section 8.5
-   of [MIPv6], including support of generic packet tunneling [RFC-2473]
-   and secure home agent communications [MIPv6-HASEC].
-
-   Hosts SHOULD support route optimization requirements for
-   correspondent nodes described in Section 8.2 of [MIPv6].
-
-   Routers SHOULD support the generic mobility-related requirements for
-   all IPv6 routers described in Section 8.3 of [MIPv6]. Routers MAY
-   support the home agent functionality described in Section 8.4 of
-   [MIPv6], including support of [RFC-2473] and [MIPv6-HASEC].
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 10]
-
-
-
-
-
-Internet-Draft
-
-
-8. Security
-
-   This section describes the specification of IPsec for the IPv6 node.
-
-8.1 Basic Architecture
-
-   Security Architecture for the Internet Protocol [RFC-2401] MUST be
-   supported. RFC-2401 is being updated by the IPsec Working Group.
-
-8.2 Security Protocols
-
-   ESP [RFC-2406] MUST be supported. AH [RFC-2402] MUST be supported.
-   RFC- 2406 and RFC 2402 are being updated by the IPsec Working Group.
-
-
-8.3 Transforms and Algorithms
-
-   Current IPsec RFCs specify the support of certain transforms and
-   algorithms, NULL encryption, DES-CBC, HMAC-SHA-1-96, and HMAC-MD5-96.
-   The requirements for these are discussed first, and then additional
-   algorithms 3DES-CBC, AES-128-CBC and HMAC-SHA-256-96 are discussed.
-
-   NULL encryption algorithm [RFC-2410] MUST be supported for providing
-   integrity service and also for debugging use.
-
-   The "ESP DES-CBC Cipher Algorithm With Explicit IV" [RFC-2405] SHOULD
-   NOT be supported. Security issues related to the use of DES are
-   discussed in [DESDIFF], [DESINT], [DESCRACK]. It is still listed as
-   required by the existing IPsec RFCs, but as it is currently viewed as
-   an inherently weak algorithm, and no longer fulfills its intended
-   role.
-
-   The NULL authentication algorithm [RFC-2406] MUST be supported within
-   ESP. The use of HMAC-SHA-1-96 within AH and ESP, described in [RFC-
-   2404] MUST be supported. The use of HMAC-MD5-96 within AH and ESP,
-   described in [RFC-2403] MUST be supported. An implementer MUST refer
-   to Keyed- Hashing for Message Authentication [RFC-2104].
-
-   3DES-CBC does not suffer from the issues related to DES-CBC. 3DES-CBC
-   and ESP CBC-Mode Cipher Algorithms [RFC-2451] MAY be supported. AES-
-   CBC Cipher Algorithm [RFC-3602] MUST be supported, as it is expected
-   to be a widely available, secure algorithm that is required for
-   interoperability. It is not required by the current IPsec RFCs, but
-   is expected to become required in the future.
-
-   In addition to the above requirements, "Cryptographic Algorithm
-   Implementation Requirements For ESP And AH" [CRYPTREQ] contains the
-   current set of mandatory to implement algorithms for ESP and AH as
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 11]
-
-
-
-
-
-Internet-Draft
-
-
-   well as specifying algorithms that should be implemented because they
-   may be promoted to mandatory at some future time.  It is RECOMMENDED
-   that IPv6 nodes conform to the requirements in this document.
-
-8.4 Key Management Methods
-
-   Manual keying MUST be supported.
-
-   IKE [RFC-2407] [RFC-2408] [RFC-2409] MAY be supported for unicast
-   traffic. Where key refresh, anti-replay features of AH and ESP, or
-   on- demand creation of Security Associations (SAs) is required,
-   automated keying MUST be supported. Note that the IPsec WG is working
-   on the successor to IKE [IKE2]. Key management methods for multicast
-   traffic are also being worked on by the MSEC WG.
-
-   "Cryptographic Algorithms for use in the Internet Key Exchange
-   Version 2" [IKEv2ALGO] defines the current set of mandatory to
-   implement algorithms for use of IKEv2 as well as specifying
-   algorithms that should be implemented because they made be promoted
-   to mandatory at some future time. It is RECOMMENDED that IPv6 nodes
-   implementing IKEv2 conform to the requirements in this
-   document.
-
-9. Router-Specific Functionality
-
-   This section defines general host considerations for IPv6 nodes that
-   act as routers.  Currently, this section does not discuss routing-
-   specific requirements.
-
-9.1 General
-
-9.1.1 IPv6 Router Alert Option - RFC2711
-
-
-   The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 Hop-by-
-   Hop Header that is used in conjunction with some protocols (e.g.,
-   RSVP [RFC- 2205], or MLD [RFC-2710]). The Router Alert option will
-   need to be implemented whenever protocols that mandate its usage are
-   implemented. See Section 4.6.
-
-9.1.2 Neighbor Discovery for IPv6 - RFC2461
-
-   Sending Router Advertisements and processing Router Solicitation MUST
-   be supported.
-
-10. Network Management
-
-   Network Management MAY be supported by IPv6 nodes.  However, for IPv6
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 12]
-
-
-
-
-
-Internet-Draft
-
-
-   nodes that are embedded devices, network management may be the only
-   possibility to control these nodes.
-
-10.1 Management Information Base Modules (MIBs)
-
-   The following two MIBs SHOULD be supported by nodes that support an
-   SNMP agent.
-
-10.1.1  IP Forwarding Table MIB
-
-   IP Forwarding Table MIB [RFC-2096BIS] SHOULD be supported by nodes
-   that support an SNMP agent.
-
-10.1.2 Management Information Base for the Internet Protocol (IP)
-
-   IP MIB [RFC-2011BIS] SHOULD be supported by nodes that support an
-   SNMP agent.
-
-11. Security Considerations
-
-   This draft does not affect the security of the Internet, but
-   implementations of IPv6 are expected to support a minimum set of
-   security features to ensure security on the Internet.  "IP Security
-   Document Roadmap" [RFC-2411] is important for everyone to read.
-
-   The security considerations in RFC2460 describe the following:
-
-      The security features of IPv6 are described in the Security
-      Architecture for the Internet Protocol [RFC-2401].
-
-12. References
-
-12.1 Normative
-
-   [CRYPTREQ]     D. Eastlake 3rd, "Cryptographic Algorithm Implementa-
-                  tion Requirements For ESP And AH", draft-ietf-ipsec-
-                  esp-ah-algorithms-01.txt, January 2004.
-
-   [IKEv2ALGO]    J. Schiller, "Cryptographic Algorithms for use in the
-                  Internet Key Exchange Version 2", draft-ietf-ipsec-
-                  ikev2-algorithms-04.txt, Work in Progress.
-
-   [DHCPv6-SL]    R. Droms, "A Guide to Implementing Stateless DHCPv6
-                  Service", draft- ietf-dhc-dhcpv6-stateless-00.txt,
-                  Work in Progress.
-
-   [MIPv6]        J. Arkko, D. Johnson and C. Perkins, "Mobility Support
-                  in IPv6", draft- ietf-mobileip-ipv6-24.txt, Work in
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 13]
-
-
-
-
-
-Internet-Draft
-
-
-                  progress.
-
-   [MIPv6-HASEC]  J. Arkko, V. Devarapalli and F. Dupont, "Using IPsec
-                  to Protect Mobile IPv6 Signaling between Mobile Nodes
-                  and Home Agents", draft-ietf- mobileip-mipv6-ha-
-                  ipsec-06.txt, Work in Progress.
-
-   [MLDv2]        Vida, R. et al., "Multicast Listener Discovery Version
-                  2 (MLDv2) for IPv6", draft-vida-mld-v2-07.txt, Work in
-                  Progress.
-
-   [RFC-1035]     Mockapetris, P., "Domain names - implementation and
-                  specification", STD 13, RFC 1035, November 1987.
-
-   [RFC-1981]     McCann, J., Mogul, J. and Deering, S., "Path MTU
-                  Discovery for IP version 6", RFC 1981, August 1996.
-
-   [RFC-2096BIS]  Haberman, B. and Wasserman, M., "IP Forwarding Table
-                  MIB", draft-ietf- ipv6-rfc2096-update-07.txt, Work in
-                  Progress.
-
-   [RFC-2011BIS]  Routhier, S (ed), "Management Information Base for the
-                  Internet Protocol (IP)", draft-ietf-ipv6-rfc2011-
-                  update-07.txt, Work in progress.
-
-   [RFC-2104]     Krawczyk, K., Bellare, M., and Canetti, R., "HMAC:
-                  Keyed-Hashing for Message Authentication", RFC 2104,
-                  February 1997.
-
-   [RFC-2119]     Bradner, S., "Key words for use in RFCs to Indicate
-                  Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC-2401]     Kent, S. and Atkinson, R., "Security Architecture for
-                  the Internet Protocol", RFC 2401, November 1998.
-
-   [RFC-2402]     Kent, S. and Atkinson, R.,  "IP Authentication
-                  Header", RFC 2402, November 1998.
-
-   [RFC-2403]     Madson, C., and Glenn, R., "The Use of HMAC-MD5 within
-                  ESP and AH", RFC 2403, November 1998.
-
-   [RFC-2404]     Madson, C., and Glenn, R., "The Use of HMAC-SHA-1
-                  within ESP and AH", RFC 2404, November 1998.
-
-   [RFC-2405]     Madson, C. and Doraswamy, N., "The ESP DES-CBC Cipher
-                  Algorithm With Explicit IV", RFC 2405, November 1998.
-
-   [RFC-2406]     Kent, S. and Atkinson, R., "IP Encapsulating Security
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 14]
-
-
-
-
-
-Internet-Draft
-
-
-                  Protocol (ESP)", RFC 2406, November 1998.
-
-   [RFC-2407]     Piper, D., "The Internet IP Security Domain of
-                  Interpretation for ISAKMP", RFC 2407, November 1998.
-
-   [RFC-2408]     Maughan, D., Schertler, M., Schneider, M., and Turner,
-                  J., "Internet Security Association and Key Management
-                  Protocol (ISAKMP)", RFC 2408, November 1998.
-
-   [RFC-2409]     Harkins, D., and Carrel, D., "The Internet Key
-                  Exchange (IKE)", RFC 2409, November 1998.
-
-   [RFC-2410]     Glenn, R. and Kent, S., "The NULL Encryption Algorithm
-                  and Its Use With IPsec", RFC 2410, November 1998.
-
-   [RFC-2451]     Pereira, R. and Adams, R., "The ESP CBC-Mode Cipher
-                  Algorithms", RFC 2451, November 1998.
-
-   [RFC-2460]     Deering, S. and Hinden, R., "Internet Protocol, Ver-
-                  sion 6 (IPv6) Specification", RFC 2460, December 1998.
-
-   [RFC-2461]     Narten, T., Nordmark, E. and Simpson, W., "Neighbor
-                  Discovery for IP Version 6 (IPv6)", RFC 2461, December
-                  1998.
-
-   [RFC-2462]     Thomson, S. and Narten, T., "IPv6 Stateless Address
-                  Autoconfiguration", RFC 2462.
-
-   [RFC-2463]     Conta, A. and Deering, S., "ICMP for the Internet Pro-
-                  tocol Version 6 (IPv6)", RFC 2463, December 1998.
-
-   [RFC-2472]     Haskin, D. and Allen, E., "IP version 6 over PPP", RFC
-                  2472, December 1998.
-
-   [RFC-2473]     Conta, A. and Deering, S., "Generic Packet Tunneling
-                  in IPv6 Specification", RFC 2473, December 1998.  Xxx
-                  add
-
-   [RFC-2671]     Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-                  2671, August 1999.
-
-   [RFC-2710]     Deering, S., Fenner, W. and Haberman, B., "Multicast
-                  Listener Discovery (MLD) for IPv6", RFC 2710, October
-                  1999.
-
-   [RFC-2711]     Partridge, C. and Jackson, A., "IPv6 Router Alert
-                  Option", RFC 2711, October 1999.
-
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 15]
-
-
-
-
-
-Internet-Draft
-
-
-   [RFC-3041]     Narten, T. and Draves, R., "Privacy Extensions for
-                  Stateless Address Autoconfiguration in IPv6", RFC
-                  3041, January 2001.
-
-   [RFC-3152]     Bush, R., "Delegation of IP6.ARPA", RFC 3152, August
-                  2001.
-
-   [RFC-3315]     Bound, J. et al., "Dynamic Host Configuration Protocol
-                  for IPv6 (DHCPv6)", RFC 3315, July 2003.
-
-   [RFC-3363]     Bush, R., et al., "Representing Internet Protocol ver-
-                  sion 6 (IPv6) Addresses in the Domain Name System
-                  (DNS)", RFC 3363, August 2002.
-
-   [RFC-3484]     Draves, R., "Default Address Selection for IPv6", RFC
-                  3484, February 2003.
-
-   [RFC-3513]     Hinden, R. and Deering, S. "IP Version 6 Addressing
-                  Architecture", RFC 3513, April 2003.
-
-   [RFC-3590]     Haberman, B., "Source Address Selection for the Multi-
-                  cast Listener Discovery (MLD) Protocol", RFC 3590,
-                  September 2003.
-
-   [RFC-3596]     Thomson, S., et al., "DNS Extensions to support IP
-                  version 6", RFC 3596, October 2003.
-
-   [RFC-3602]     S. Frankel, "The AES-CBC Cipher Algorithm and Its Use
-                  with IPsec", RFC 3602, September 2003.
-
-12.2 Non-Normative
-
-   [ANYCAST]      Hagino, J and Ettikan K., "An Analysis of IPv6 Anycast",
-                  draft-ietf- ipngwg-ipv6-anycast-analysis-02.txt, Work in
-                  Progress.
-
-   [DESDIFF]      Biham, E., Shamir, A., "Differential Cryptanalysis of
-                  DES-like cryptosystems", Journal of Cryptology Vol 4, Jan
-                  1991.
-
-   [DESCRACK]     Cracking DES, O'Reilly & Associates, Sebastapol, CA 2000.
-   
-   [DESINT]       Bellovin, S., "An Issue With DES-CBC When Used Without
-                  Strong Integrity", Proceedings of the 32nd IETF, Danvers,
-                  MA, April 1995.
-
-   [DHCPv6-SL]    Droms, R., "A Guide to Implementing Stateless DHCPv6 Ser-
-                  vice", draft- ietf-dhc-dhcpv6-stateless-02.txt, Work in
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 16]
-
-
-
-
-
-Internet-Draft
-
-
-                  Progress.
-
-   [DNSSEC-INTRO] Arends, R., Austein, R., Larson, M., Massey, D. and Rose,
-                  S., "DNS Security Introduction and Requirements" draft-
-                  ietf-dnsext-dnssec-intro- 06.txt, Work in Progress.
-
-   [DNSSEC-REC]   Arends, R., Austein, R., Larson, M., Massey, D. and Rose,
-                  S., "Resource Records for the DNS Security Extensions",
-                  draft-ietf-dnsext-dnssec- records-04.txt, Work in Pro-
-                  gress.
-
-   [DNSSEC-PROT]  Arends, R., Austein, R., Larson, M., Massey, D. and Rose,
-                  S., "Protocol Modifications for the DNS Security Exten-
-                  sions", draft-ietf-dnsext- dnssec-protocol-02.txt, Work
-                  in Progress.
-
-   [IKE2]         Kaufman, C. (ed), "Internet Key Exchange (IKEv2) Proto-
-                  col", draft-ietf- ipsec-ikev2-10.txt, Work in Progress.
-  
-   [IPv6-RH]      P. Savola, "Security of IPv6 Routing Header and Home
-                  Address Options", draft-savola-ipv6-rh-ha-security-
-                  03.txt, Work in Progress, March 2002.
-
-   [MC-THREAT]    Ballardie A. and Crowcroft, J.; Multicast-Specific Secu-
-                  rity Threats and Counter-Measures; In Proceedings "Sympo-
-                  sium on Network and Distributed System Security", Febru-
-                  ary 1995, pp.2-16.
-
-   [RFC-793]      Postel, J., "Transmission Control Protocol", RFC 793,
-                  August 1980.
-
-   [RFC-1034]     Mockapetris, P., "Domain names - concepts and facili-
-                  ties", RFC 1034, November 1987.
-
-   [RFC-2147]     Borman, D., "TCP and UDP over IPv6 Jumbograms", RFC 2147,
-                  May 1997.
-
-   [RFC-2205]     Braden, B. (ed.), Zhang, L., Berson, S., Herzog, S. and
-                  S. Jamin, "Resource ReSerVation Protocol (RSVP)", RFC
-                  2205, September 1997.
-
-   [RFC-2464]     Crawford, M., "Transmission of IPv6 Packets over Ethernet
-                  Networks", RFC 2462, December 1998.
-
-   [RFC-2492]     G. Armitage, M. Jork, P. Schulter, G. Harter, IPv6 over
-                  ATM Networks", RFC 2492, January 1999.
-
-   [RFC-2675]     Borman, D., Deering, S. and Hinden, B., "IPv6
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 17]
-
-
-
-
-
-Internet-Draft
-
-
-                  Jumbograms", RFC 2675, August 1999.
-
-   [RFC-2732]     R. Hinden, B. Carpenter, L. Masinter, "Format for Literal
-                  IPv6 Addresses in URL's", RFC 2732, December 1999.
-
-   [RFC-2851]     M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder,
-                  "Textual Conventions for Internet Network Addresses", RFC
-                  2851, June 2000.
-
-   [RFC-2893]     Gilligan, R. and Nordmark, E., "Transition Mechanisms for
-                  IPv6 Hosts and Routers", RFC 2893, August 2000.
-
-   [RFC-3569]     S. Bhattacharyya, Ed., "An Overview of Source-Specific
-                  Multicast (SSM)", RFC 3569, July 2003.
-
-   [SSM-ARCH]     H. Holbrook, B. Cain, "Source-Specific Multicast for IP",
-                  draft-ietf- ssm-arch-03.txt, Work in Progress.
-
-13. Authors and Acknowledgements
-
-   This document was written by the IPv6 Node Requirements design team:
-
-      Jari Arkko
-      [jari.arkko@ericsson.com]
-
-      Marc Blanchet
-      [marc.blanchet@viagenie.qc.ca]
-
-      Samita Chakrabarti
-      [samita.chakrabarti@eng.sun.com]
-
-      Alain Durand
-      [alain.durand@sun.com]
-
-      Gerard Gastaud
-      [gerard.gastaud@alcatel.fr]
-
-      Jun-ichiro itojun Hagino
-      [itojun@iijlab.net]
-
-      Atsushi Inoue
-      [inoue@isl.rdc.toshiba.co.jp]
-
-      Masahiro Ishiyama
-      [masahiro@isl.rdc.toshiba.co.jp]
-
-      John Loughney
-      [john.loughney@nokia.com]
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 18]
-
-
-
-
-
-Internet-Draft
-
-
-      Rajiv Raghunarayan
-      [raraghun@cisco.com]
-
-      Shoichi Sakane
-      [shouichi.sakane@jp.yokogawa.com]
-
-      Dave Thaler
-      [dthaler@windows.microsoft.com]
-
-      Juha Wiljakka
-      [juha.wiljakka@Nokia.com]
-
-   The authors would like to thank Ran Atkinson, Jim Bound, Brian Car-
-   penter, Ralph Droms, Christian Huitema, Adam Machalek, Thomas Narten,
-   Juha Ollila and Pekka Savola for their comments.
-
-14. Editor's Contact Information
-
-   Comments or questions regarding this document should be sent to the
-   IPv6 Working Group mailing list (ipv6@ietf.org) or to:
-
-      John Loughney
-      Nokia Research Center
-      Itamerenkatu 11-13
-      00180 Helsinki
-      Finland
-
-      Phone: +358 50 483 6242
-      Email: John.Loughney@Nokia.com
-
-Notices
-
-   The IETF takes no position regarding the validity or scope of any
-   intellectual property or other rights that might be claimed to per-
-   tain 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
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 19]
-
-
-
-
-
-Internet-Draft
-
-
-   rights, which may cover technology that may be required to practice
-   this standard.  Please address the information to the IETF Executive
-   Director.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Loughney (editor)          February 16, 2004                   [Page 20]
-
-
diff --git a/contrib/bind9/doc/draft/draft-ietf-secsh-dns-05.txt b/contrib/bind9/doc/draft/draft-ietf-secsh-dns-05.txt
deleted file mode 100644
index a272d81..0000000
--- a/contrib/bind9/doc/draft/draft-ietf-secsh-dns-05.txt
+++ /dev/null
@@ -1,614 +0,0 @@
-Secure Shell Working Group                                   J. Schlyter
-Internet-Draft                                                   OpenSSH
-Expires: March 5, 2004                                        W. Griffin
-                                                                  SPARTA
-                                                       September 5, 2003
-
-
-           Using DNS to Securely Publish SSH Key Fingerprints
-                      draft-ietf-secsh-dns-05.txt
-
-Status of this Memo
-
-   This document is an Internet-Draft and is in full conformance with
-   all provisions of Section 10 of RFC2026.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF), its areas, and its working groups. Note that other
-   groups may also distribute working documents as Internet-Drafts.
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time. It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   The list of current Internet-Drafts can be accessed at http://
-   www.ietf.org/ietf/1id-abstracts.txt.
-
-   The list of Internet-Draft Shadow Directories can be accessed at
-   http://www.ietf.org/shadow.html.
-
-   This Internet-Draft will expire on March 5, 2004.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
-   This document describes a method to verify SSH host keys using
-   DNSSEC. The document defines a new DNS resource record that contains
-   a standard SSH key fingerprint.
-
-
-
-
-
-
-
-
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                  [Page 1]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-Table of Contents
-
-   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.    SSH Host Key Verification  . . . . . . . . . . . . . . . . .  3
-   2.1   Method . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
-   2.2   Implementation Notes . . . . . . . . . . . . . . . . . . . .  3
-   2.3   Fingerprint Matching . . . . . . . . . . . . . . . . . . . .  4
-   2.4   Authentication . . . . . . . . . . . . . . . . . . . . . . .  4
-   3.    The SSHFP Resource Record  . . . . . . . . . . . . . . . . .  4
-   3.1   The SSHFP RDATA Format . . . . . . . . . . . . . . . . . . .  5
-   3.1.1 Algorithm Number Specification . . . . . . . . . . . . . . .  5
-   3.1.2 Fingerprint Type Specification . . . . . . . . . . . . . . .  5
-   3.1.3 Fingerprint  . . . . . . . . . . . . . . . . . . . . . . . .  5
-   3.2   Presentation Format of the SSHFP RR  . . . . . . . . . . . .  6
-   4.    Security Considerations  . . . . . . . . . . . . . . . . . .  6
-   5.    IANA Considerations  . . . . . . . . . . . . . . . . . . . .  7
-         Normative References . . . . . . . . . . . . . . . . . . . .  8
-         Informational References . . . . . . . . . . . . . . . . . .  8
-         Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  9
-   A.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  9
-         Intellectual Property and Copyright Statements . . . . . . . 10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                  [Page 2]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-1. Introduction
-
-   The SSH [6] protocol provides secure remote login and other secure
-   network services over an insecure network.  The security of the
-   connection relies on the server authenticating itself to the client
-   as well as the user authenticating itself to the server.
-
-   If a connection is established to a server whose public key is not
-   already known to the client, a fingerprint of the key is presented to
-   the user for verification.  If the user decides that the fingerprint
-   is correct and accepts the key, the key is saved locally and used for
-   verification for all following connections. While some
-   security-conscious users verify the fingerprint out-of-band before
-   accepting the key, many users blindly accept the presented key.
-
-   The method described here can provide out-of-band verification by
-   looking up a fingerprint of the server public key in the DNS [1][2]
-   and using DNSSEC [5] to verify the lookup.
-
-   In order to distribute the fingerprint using DNS, this document
-   defines a new DNS resource record, "SSHFP", to carry the fingerprint.
-
-   Basic understanding of the DNS system [1][2] and the DNS security
-   extensions [5] is assumed by this document.
-
-   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 [3].
-
-2. SSH Host Key Verification
-
-2.1 Method
-
-   Upon connection to a SSH server, the SSH client MAY look up the SSHFP
-   resource record(s) for the host it is connecting to.  If the
-   algorithm and fingerprint of the key received from the SSH server
-   match the algorithm and fingerprint of one of the SSHFP resource
-   record(s) returned from DNS, the client MAY accept the identity of
-   the server.
-
-2.2 Implementation Notes
-
-   Client implementors SHOULD provide a configurable policy used to
-   select the order of methods used to verify a host key. This document
-   defines one method: Fingerprint storage in DNS. Another method
-   defined in the SSH Architecture [6] uses local files to store keys
-   for comparison. Other methods that could be defined in the future
-   might include storing fingerprints in LDAP or other databases. A
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                  [Page 3]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-   configurable policy will allow administrators to determine which
-   methods they want to use and in what order the methods should be
-   prioritized. This will allow administrators to determine how much
-   trust they want to place in the different methods.
-
-   One specific scenario for having a configurable policy is where
-   clients do not use fully qualified host names to connect to servers.
-   In this scenario, the implementation SHOULD verify the host key
-   against a local database before verifying the key via the fingerprint
-   returned from DNS. This would help prevent an attacker from injecting
-   a DNS search path into the local resolver and forcing the client to
-   connect to a different host.
-
-2.3 Fingerprint Matching
-
-   The public key and the SSHFP resource record are matched together by
-   comparing algorithm number and fingerprint.
-
-      The public key algorithm and the SSHFP algorithm number MUST
-      match.
-
-      A message digest of the public key, using the message digest
-      algorithm specified in the SSHFP fingerprint type, MUST match the
-      SSHFP fingerprint.
-
-
-2.4 Authentication
-
-   A public key verified using this method MUST NOT be trusted if the
-   SSHFP resource record (RR) used for verification was not
-   authenticated by a trusted SIG RR.
-
-   Clients that do validate the DNSSEC signatures themselves SHOULD use
-   standard DNSSEC validation procedures.
-
-   Clients that do not validate the DNSSEC signatures themselves MUST
-   use a secure transport, e.g. TSIG [9], SIG(0) [10] or IPsec [8],
-   between themselves and the entity performing the signature
-   validation.
-
-3. The SSHFP Resource Record
-
-   The SSHFP resource record (RR) is used to store a fingerprint of a
-   SSH public host key that is associated with a Domain Name System
-   (DNS) name.
-
-   The RR type code for the SSHFP RR is TBA.
-
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                  [Page 4]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-3.1 The SSHFP RDATA Format
-
-   The RDATA for a SSHFP RR consists of an algorithm number, fingerprint
-   type and the fingerprint of the public host key.
-
-         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
-         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-         |   algorithm   |    fp type    |                               /
-         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
-         /                                                               /
-         /                          fingerprint                          /
-         /                                                               /
-         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-3.1.1 Algorithm Number Specification
-
-   This algorithm number octet describes the algorithm of the public
-   key.  The following values are assigned:
-
-          Value    Algorithm name
-          -----    --------------
-          0        reserved
-          1        RSA
-          2        DSS
-
-   Reserving other types requires IETF consensus [4].
-
-3.1.2 Fingerprint Type Specification
-
-   The fingerprint type octet describes the message-digest algorithm
-   used to calculate the fingerprint of the public key.  The following
-   values are assigned:
-
-          Value    Fingerprint type
-          -----    ----------------
-          0        reserved
-          1        SHA-1
-
-   Reserving other types requires IETF consensus [4].
-
-   For interoperability reasons, as few fingerprint types as possible
-   should be reserved.  The only reason to reserve additional types is
-   to increase security.
-
-3.1.3 Fingerprint
-
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                  [Page 5]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-   The fingerprint is calculated over the public key blob as described
-   in [7].
-
-   The message-digest algorithm is presumed to produce an opaque octet
-   string output which is placed as-is in the RDATA fingerprint field.
-
-3.2 Presentation Format of the SSHFP RR
-
-   The RDATA of the presentation format of the SSHFP resource record
-   consists of two numbers (algorithm and fingerprint type) followed by
-   the fingerprint itself presented in hex, e.g:
-
-         host.example.  SSHFP 2 1 123456789abcdef67890123456789abcdef67890
-
-   The use of mnemonics instead of numbers is not allowed.
-
-4. Security Considerations
-
-   Currently, the amount of trust a user can realistically place in a
-   server key is proportional to the amount of attention paid to
-   verifying that the public key presented actually corresponds to the
-   private key of the server. If a user accepts a key without verifying
-   the fingerprint with something learned through a secured channel, the
-   connection is vulnerable to a man-in-the-middle attack.
-
-   The overall security of using SSHFP for SSH host key verification is
-   dependent on the security policies of the SSH host administrator and
-   DNS zone administrator (in transferring the fingerprint), detailed
-   aspects of how verification is done in the SSH implementation, and in
-   the client's diligence in accessing the DNS in a secure manner.
-
-   One such aspect is in which order fingerprints are looked up (e.g.
-   first checking local file and then SSHFP).  We note that in addition
-   to protecting the first-time transfer of host keys, SSHFP can
-   optionally be used for stronger host key protection.
-
-      If SSHFP is checked first, new SSH host keys may be distributed by
-      replacing the corresponding SSHFP in DNS.
-
-      If SSH host key verification can be configured to require SSHFP,
-      SSH host key revocation can be implemented by removing the
-      corresponding SSHFP from DNS.
-
-   As stated in Section 2.2, we recommend that SSH implementors provide
-   a policy mechanism to control the order of methods used for host key
-   verification. One specific scenario for having a configurable policy
-   is where clients use unqualified host names to connect to servers. In
-   this case, we recommend that SSH implementations check the host key
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                  [Page 6]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-   against a local database before verifying the key via the fingerprint
-   returned from DNS. This would help prevent an attacker from injecting
-   a DNS search path into the local resolver and forcing the client to
-   connect to a different host.
-
-   A different approach to solve the DNS search path issue would be for
-   clients to use a trusted DNS search path, i.e., one not acquired
-   through DHCP or other autoconfiguration mechanisms. Since there is no
-   way with current DNS lookup APIs to tell whether a search path is
-   from a trusted source, the entire client system would need to be
-   configured with this trusted DNS search path.
-
-   Another dependency is on the implementation of DNSSEC itself.  As
-   stated in Section 2.4, we mandate the use of secure methods for
-   lookup and that SSHFP RRs are authenticated by trusted SIG RRs.  This
-   is especially important if SSHFP is to be used as a basis for host
-   key rollover and/or revocation, as described above.
-
-   Since DNSSEC only protects the integrity of the host key fingerprint
-   after it is signed by the DNS zone administrator, the fingerprint
-   must be transferred securely from the SSH host administrator to the
-   DNS zone administrator.  This could be done manually between the
-   administrators or automatically using secure DNS dynamic update [11]
-   between the SSH server and the nameserver.  We note that this is no
-   different from other key enrollment situations, e.g. a client sending
-   a certificate request to a certificate authority for signing.
-
-5. IANA Considerations
-
-   IANA needs to allocate a RR type code for SSHFP from the standard RR
-   type space (type 44 requested).
-
-   IANA needs to open a new registry for the SSHFP RR type for public
-   key algorithms.  Defined types are:
-
-         0 is reserved
-         1 is RSA
-         2 is DSA
-
-    Adding new reservations requires IETF consensus [4].
-
-   IANA needs to open a new registry for the SSHFP RR type for
-   fingerprint types.  Defined types are:
-
-         0 is reserved
-         1 is SHA-1
-
-    Adding new reservations requires IETF consensus [4].
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                  [Page 7]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-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., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [4]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-   [5]  Eastlake, D., "Domain Name System Security Extensions", RFC
-        2535, March 1999.
-
-   [6]  Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
-        Lehtinen, "SSH Protocol Architecture",
-        draft-ietf-secsh-architecture-14 (work in progress), July 2003.
-
-   [7]  Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
-        Lehtinen, "SSH Transport Layer Protocol",
-        draft-ietf-secsh-transport-16 (work in progress), July 2003.
-
-Informational References
-
-   [8]   Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document
-         Roadmap", RFC 2411, November 1998.
-
-   [9]   Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
-         "Secret Key Transaction Authentication for DNS (TSIG)", RFC
-         2845, May 2000.
-
-   [10]  Eastlake, D., "DNS Request and Transaction Signatures (
-         SIG(0)s)", RFC 2931, September 2000.
-
-   [11]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
-         Update", RFC 3007, November 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                  [Page 8]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-Authors' Addresses
-
-   Jakob Schlyter
-   OpenSSH
-   812 23rd Avenue SE
-   Calgary, Alberta  T2G 1N8
-   Canada
-
-   EMail: jakob@openssh.com
-   URI:   http://www.openssh.com/
-
-
-   Wesley Griffin
-   SPARTA
-   7075 Samuel Morse Drive
-   Columbia, MD  21046
-   USA
-
-   EMail: wgriffin@sparta.com
-   URI:   http://www.sparta.com/
-
-Appendix A. Acknowledgements
-
-   The authors gratefully acknowledge, in no particular order, the
-   contributions of the following persons:
-
-      Martin Fredriksson
-
-      Olafur Gudmundsson
-
-      Edward Lewis
-
-      Bill Sommerfeld
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                  [Page 9]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-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 (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 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
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                 [Page 10]
-
-Internet-Draft          DNS and SSH Fingerprints          September 2003
-
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter & Griffin       Expires March 5, 2004                 [Page 11]
-
diff --git a/contrib/bind9/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt b/contrib/bind9/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt
deleted file mode 100644
index 3578d2a..0000000
--- a/contrib/bind9/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt
+++ /dev/null
@@ -1,519 +0,0 @@
-
-Internet Draft                                          Johan Ihren
-draft-ihren-dnsext-threshold-validation-00.txt          Autonomica
-February 2003
-Expires in six months
-
-
-                        Threshold Validation: 
-
-	 A Mechanism for Improved Trust and Redundancy for DNSSEC Keys
-
-
-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 memo documents a proposal for a different method of validation
-   for DNSSEC aware resolvers. The key change is that by changing from
-   a model of one Key Signing Key, KSK, at a time to multiple KSKs it
-   will be possible to increase the aggregated trust in the signed
-   keys by leveraging from the trust associated with the different
-   signees. 
-
-   By having multiple keys to chose from validating resolvers get the
-   opportunity to use local policy to reflect actual trust in
-   different keys. For instance, it is possible to trust a single,
-   particular key ultimately, while requiring multiple valid
-   signatures by less trusted keys for validation to succeed.
-   Furthermore, with multiple KSKs there are additional redundancy
-   benefits available since it is possible to roll over different KSKs
-   at different times which may make rollover scenarios easier to
-   manage.
-
-Contents
-
-	1. Terminology
-	2. Introduction and Background
-
-	3. Trust in DNSSEC Keys
-	3.1. Key Management, Split Keys and Trust Models
-	3.2. Trust Expansion: Authentication versus Authorization
-
-	4. Proposed Semantics for Signing the KEY Resource Record 
-           Set
-	4.1. Packet Size Considerations
-
-	5. Proposed Use of Multiple "Trusted Keys" in a Validating 
-           Resolver
-	5.1. Not All Possible KSKs Need to Be Trusted
-	5.2. Possible to do Threshold Validation
-	5.3. Not All Trusted Keys Will Be Available
-
-	6. Additional Benefits from Having Multiple KSKs
-	6.1. More Robust Key Rollovers
-	6.2. Evaluation of Multiple Key Distribution Mechanisms
-
-	7. Security Considerations
-	8. IANA Considerations.
-	9. References
-	9.1. Normative.
-	9.2. Informative.
-	10. Acknowledgments.
-	11. Authors' Address
-
-
-1. Terminology
-
-   The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
-   and "MAY" in this document are to be interpreted as described in
-   RFC 2119. 
-
-   The term "zone" refers to the unit of administrative control in the
-   Domain Name System. "Name server" denotes a DNS name server that is
-   authoritative (i.e. knows all there is to know) for a DNS zone,
-   typically the root zone. A "resolver", is a DNS "client", i.e. an
-   entity that sends DNS queries to authoritative nameservers and
-   interpret the results. A "validating resolver" is a resolver that
-   attempts to perform DNSSEC validation on data it retrieves by doing
-   DNS lookups.
-
-
-2. Introduction and Background
-
-   From a protocol perspective there is no real difference between
-   different keys in DNSSEC. They are all just keys. However, in
-   actual use there is lots of difference. First and foremost, most
-   DNSSEC keys have in-band verification. I.e. the keys are signed by
-   some other key, and this other key is in its turn also signed by
-   yet another key. This way a "chain of trust" is created. Such
-   chains have to end in what is referred to as a "trusted key" for
-   validation of DNS lookups to be possible. 
-
-   A "trusted key" is a the public part of a key that the resolver
-   acquired by some other means than by looking it up in DNS. The
-   trusted key has to be explicitly configured.
-
-   A node in the DNS hierarchy that issues such out-of-band "trusted
-   keys" is called a "security apex" and the trusted key for that apex
-   is the ultimate source of trust for all DNS lookups within that
-   entire subtree.
-
-   DNSSEC is designed to be able to work with more than on security
-   apex. These apexes will all share the problem of how to distribute
-   their "trusted keys" in a way that provides validating resolvers
-   confidence in the distributed keys. 
-
-   Maximizing that confidence is crucial to the usefulness of DNSSEC
-   and this document tries to address this issue.
-
-
-3. Trust in DNSSEC Keys
-
-   In the end the trust that a validating resolver will be able to put
-   in a key that it cannot validate within DNSSEC will have to be a
-   function of
-
-   	    * trust in the key issuer, aka the KSK holder
-
-	    * trust in the distribution method
-
-	    * trust in extra, out-of-band verification
-
-   The KSK holder needs to be trusted not to accidentally lose private
-   keys in public places. Furthermore it needs to be trusted to
-   perform correct identification of the ZSK holders in case they are
-   separate from the KSK holder itself.
-
-   The distribution mechanism can be more or less tamper-proof. If the
-   key holder publishes the public key, or perhaps just a secure
-   fingerprint of the key in a major newspaper it may be rather
-   difficult to tamper with. A key acquired that way may be easier to
-   trust than if it had just been downloaded from a web page.
-
-   Out-of-band verification can for instance be the key being signed
-   by a certificate issued by a known Certificate Authority that the
-   resolver has reason to trust.
-
-3.1. Simplicity vs Trust 
-
-   The fewer keys that are in use the simpler the key management
-   becomes. Therefore increasing the number of keys should only be
-   considered when the complexity is not the major concern. A perfect
-   example of this is the distinction between so called Key Signing
-   Keys, KSK, and Zone Signing Keys, ZSK. This distinction adds
-   overall complexity but simplifies real life operations and was an
-   overall gain since operational simplification was considered to be
-   a more crucial issue than the added complexity.
-
-   In the case of a security apex there are additional issues to
-   consider, among them
-
-      * maximizing trust in the KSK received out-of-band
-
-      * authenticating the legitimacy of the ZSKs used
-
-   In some cases this will be easy, since the same entity will manage
-   both ZSKs and KSKs (i.e. it will authenticate itself, somewhat
-   similar to a self-signed certificate). In some environments it will
-   be possible to get the trusted key installed in the resolver end by
-   decree (this would seem to be a likely method within corporate and
-   government environments).
-
-   In other cases, however, this will possibly not be sufficient. In
-   the case of the root zone this is obvious, but there may well be
-   other cases.
-
-3.2. Expanding the "Trust Base"
-
-   For a security apex where the ZSKs and KSK are not held by the same
-   entity the KSK will effectively authenticate the identity of
-   whoever does real operational zone signing. The amount of trust
-   that the data signed by a ZSK will get is directly dependent on
-   whether the end resolver trusts the KSK or not, since the resolver
-   has no OOB access to the public part of the ZSKs (for practical
-   reasons).
-
-   Since the KSK holder is distinct from the ZSK holder the obvious
-   question is whether it would then be possible to further improve
-   the situation by using multiple KSK holders and thereby expanding
-   the trust base to the union of that available to each individual
-   KSK holder. "Trust base" is an invented term intended to signify
-   the aggregate of Internet resolvers that will eventually choose to
-   trust a key issued by a particular KSK holder.
-
-   A crucial issue when considering trust expansion through addition
-   of multiple KSK holders is that the KSK holders are only used to
-   authenticate the ZSKs used for signing the zone. I.e. the function
-   performed by the KSK is basically:
-
-   	     "This is indeed the official ZSK holder for this zone,
-   	     I've verified this fact to the best of my abilitites."
-
-   Which can be thought of as similar to the service of a public
-   notary. I.e. the point with adding more KSK holders is to improve
-   the public trust in data signed by the ZSK holders by improving the
-   strength of available authentication. 
-
-   Therefore adding more KSK holders, each with their own trust base,
-   is by definition a good thing. More authentication is not
-   controversial. On the contrary, when it comes to authentication,
-   the more the merrier.
-
-   
-4. Proposed Semantics for Signing the KEY Resource Record Set
-
-   In DNSSEC according to RFC2535 all KEY Resource Records are used to
-   sign all authoritative data in the zone, including the KEY RRset
-   itself, since RFC2535 makes no distinction between Key Signing
-   Keys, KSK, and Zone Signing Keys, ZSK.  With Delegation Signer [DS]
-   it is possible to change this to the KEY RRset being signed with
-   all KSKs and ZSKs but the rest of the zone only being signed by the
-   ZSKs.
-
-   This proposal changes this one step further, by recommending that
-   the KEY RRset is only signed by the Key Signing Keys, KSK, and
-   explicitly not by the Zone Signing Keys, ZSK. The reason for this
-   is to maximize the amount of space in the DNS response packet that
-   is available for additional KSKs and signatures thereof. The rest
-   of the authoritative zone contents are as previously signed by only
-   the ZSKs.
-
-4.1. Packet Size Considerations
-
-   The reason for the change is to keep down the size of the aggregate
-   of KEY RRset plus SIG(KEY) that resolvers will need to acquire to
-   perform validation of data below a security apex. For DNSSEC data
-   to be returned the DNSSEC OK bit in the EDNS0 OPT Record has to be
-   set, and therefore the allowed packet size can be assumed to be at
-   least the EDNS0 minimum of 4000 bytes.
-
-   When querying for KEY + SIG(KEY) for "." (the case that is assumed
-   to be most crucial) the size of the response packet after the
-   change to only sign the KEY RR with the KSKs break down into a
-   rather large space of possibilities. Here are a few examples for
-   the possible alternatives for different numbers of KSKs and ZSKs
-   for some different key lengths (all RSA keys, with a public
-   exponent that is < 254). This is all based upon the size of the
-   response for the particular example of querying for
-   
-	". KEY IN"
-
-   with a response of entire KEY + SIG(KEY) with the authority and
-   additional sections empty:
-
-   	      ZSK/768 and KSK/1024   (real small)
-	      Max 12 KSK +  3 ZSK  at 3975
-	          10 KSK +  8 ZSK  at 3934
-		   8 KSK + 13 ZSK  at 3893
-
-	      ZSK/768 + KSK/1280
-	      MAX 10 KSK +  2 ZSK  at 3913
-	           8 KSK +  9 ZSK  at 3970
-                   6 KSK + 15 ZSK  at 3914
-
-	      ZSK/768 + KSK/1536
-	      MAX  8 KSK +  4 ZSK  at 3917
-                   7 KSK +  8 ZSK  at 3938
-                   6 KSK + 12 ZSK  at 3959
-
-              ZSK/768 + KSK/2048
-              MAX  6 KSK +  5 ZSK  at 3936
-                   5 KSK + 10 ZSK  at 3942
-
-              ZSK/1024 + KSK/1024
-              MAX 12 KSK +  2 ZSK  at 3943
-                  11 KSK +  4 ZSK  at 3930
-                  10 KSK +  6 ZSK  at 3917
-                   8 KSK + 10 ZSK  at 3891
-
-              ZSK/1024 + KSK/1536
-              MAX  8 KSK +  3 ZSK  at 3900
-                   7 KSK +  6 ZSK  at 3904
-                   6 KSK +  9 ZSK  at 3908
-
-              ZSK/1024 + KSK/2048
-              MAX  6 KSK +  4 ZSK  at 3951
-                   5 KSK +  8 ZSK  at 3972
-                   4 KSK + 12 ZSK  at 3993
-
-   Note that these are just examples and this document is not making
-   any recommendations on suitable choices of either key lengths nor
-   number of different keys employed at a security apex.
-
-   This document does however, based upon the above figures, make the
-   recommendation that at a security apex that expects to distribute
-   "trusted keys" the KEY RRset should only be signed with the KSKs
-   and not with the ZSKs to keep the size of the response packets
-   down.
-
-
-5. Proposed Use of Multiple "Trusted Keys" in a Validating Resolver
-
-   In DNSSEC according to RFC2535[RFC2535] validation is the process
-   of tracing a chain of signatures (and keys) upwards through the DNS
-   hierarchy until a "trusted key" is reached. If there is a known
-   trusted key present at a security apex above the starting point
-   validation becomes an exercise with a binary outcome: either the
-   validation succeeds or it fails. No intermediate states are
-   possible.
-
-   With multiple "trusted keys" (i.e. the KEY RRset for the security
-   apex signed by multiple KSKs) this changes into a more complicated
-   space of alternatives. From the perspective of complexity that may
-   be regarded as a change for the worse. However, from a perspective
-   of maximizing available trust the multiple KSKs add value to the
-   system.
-
-5.1. Possible to do Threshold Validation
-
-   With multiple KSKs a new option that opens for the security
-   concious resolver is to not trust a key individually. Instead the
-   resolver may decide to require the validated signatures to exceed a
-   threshold. For instance, given M trusted keys it is possible for
-   the resolver to require N-of-M signatures to treat the data as
-   validated.
-
-   I.e. with the following pseudo-configuration in a validating
-   resolver
-
-   	security-apex "." IN {
-	   keys { ksk-1 .... ;
-      	          ksk-2 .... ;
-	          ksk-3 .... ; 
-		  ksk-4 .... ;
-		  ksk-5 .... ;
-	        };
-	   validation {
-	      # Note that ksk-4 is not present below
-	      keys { ksk-1; ksk-2; ksk-3; ksk-5; }; 
-              # 3 signatures needed with 4 possible keys, aka 75%
-              needed-signatures 3;
-           };
-	};
-
-   we configure five trusted keys for the root zone, but require two
-   valid signatures for the top-most KEY for validation to
-   succeed. I.e.  threshold validation does not force multiple
-   signatures on the entire signature chain, only on the top-most
-   signature, closest to the security apex for which the resolver has
-   trusted keys.		    
-
-5.2. Not All Trusted Keys Will Be Available
-
-   With multiple KSKs held and managed by separate entities the end
-   resolvers will not always manage to get access to all possible
-   trusted keys. In the case of just a single KSK this would be fatal
-   to validation and necessary to avoid at whatever cost. But with
-   several fully trusted keys available the resolver can decide to
-   trust several of them individually. An example based upon more
-   pseudo-configuration:
-
-   	security-apex "." IN {
-	   keys { ksk-1 .... ;
-      	          ksk-2 .... ;
-	          ksk-3 .... ; 
-		  ksk-4 .... ;
-		  ksk-5 .... ;
-	        };
-	   validation {
-	      # Only these two keys are trusted independently
-	      keys { ksk-1; ksk-4; }; 
-              # With these keys a single signature is sufficient
-	      needed-signatures 1;
-           };
-	};
-
-   Here we have the same five keys and instruct the validating
-   resolver to fully trust data that ends up with just one signature
-   from by a fully trusted key.
-
-   The typical case where this will be useful is for the case where
-   there is a risk of the resolver not catching a rollover event by
-   one of the KSKs. By doing rollovers of different KSKs with
-   different schedules it is possible for a resolver to "survive"
-   missing a rollover without validation breaking. This improves
-   overall robustness from a management point of view.
-
-5.3. Not All Possible KSKs Need to Be Trusted
-
-   With just one key available it simply has to be trusted, since that
-   is the only option available. With multiple KSKs the validating
-   resolver immediately get the option of implementing a local policy
-   of only trusting some of the possible keys.
-
-   This local policy can be implemented either by simply not
-   configuring keys that are not trusted or, possibly, configure them
-   but specify to the resolver that certain keys are not to be
-   ultimately trusted alone.
-
-
-6. Additional Benefits from Having Multiple KSKs
-
-6.1. More Robust Key Rollovers
-
-   With only one KSK the rollover operation will be a delicate
-   operation since the new trusted key needs to reach every validating
-   resolver before the old key is retired. For this reason it is
-   expected that long periods of overlap will be needed.
-
-   With multiple KSKs this changes into a system where different
-   "series" of KSKs can have different rollover schedules, thereby
-   changing from one "big" rollover to several "smaller" rollovers.
-
-   If the resolver trusts several of the available keys individually
-   then even a failure to track a certain rollover operation within
-   the overlap period will not be fatal to validation since the other
-   available trusted keys will be sufficient.
-
-6.2. Evaluation of Multiple Key Distribution Mechanisms
-
-   Distribution of the trusted keys for the DNS root zone is
-   recognized to be a difficult problem that ...
-
-   With only one trusted key, from one single "source" to distribute
-   it will be difficult to evaluate what distribution mechanism works
-   best. With multiple KSKs, held by separate entitites it will be
-   possible to measure how large fraction of the resolver population
-   that is trusting what subsets of KSKs.
-
-
-7. Security Considerations
-
-   From a systems perspective the simplest design is arguably the
-   best, i.e. one single holder of both KSK and ZSKs. However, if that
-   is not possible in all cases a more complex scheme is needed where
-   additional trust is injected by using multiple KSK holders, each
-   contributing trust, then there are only two alternatives
-   available. The first is so called "split keys", where a single key
-   is split up among KSK holders, each contributing trust. The second
-   is the multiple KSK design outlined in this proposal.
-
-   Both these alternatives provide for threshold mechanisms. However
-   split keys makes the threshold integral to the key generating
-   mechanism (i.e. it will be a property of the keys how many
-   signatures are needed). In the case of multiple KSKs the threshold
-   validation is not a property of the keys but rather local policy in
-   the validating resolver. A benefit from this is that it is possible
-   for different resolvers to use different trust policies. Some may
-   configure threshold validation requiring multiple signatures and
-   specific keys (optimizing for security) while others may choose to
-   accept a single signature from a larger set of keys (optimizing for
-   redundancy). Since the security requirements are different it would
-   seem to be a good idea to make this choice local policy rather than
-   global policy.
-
-   Furthermore, a clear issue for validating resolvers will be how to
-   ensure that they track all rollover events for keys they
-   trust. Even with operlap during the rollover (which is clearly
-   needed) there is still a need to be exceedingly careful not to miss
-   any rollovers (or fail to acquire a new key) since without this
-   single key validation will fail. With multiple KSKs this operation
-   becomes more robust, since different KSKs may roll at different
-   times according to different rollover schedules and losing one key,
-   for whatever reason, will not be crucial unless the resolver
-   intentionally chooses to be completely dependent on that exact key.
-
-8. IANA Considerations.
-
-   NONE.
-
-
-9. References
-
-9.1. Normative.
-
-   [RFC2535] Domain Name System Security Extensions. D. Eastlake. 
-	     March 1999.
-
-   [RFC3090] DNS Security Extension Clarification on Zone Status. 
-	     E. Lewis.  March 2001.
-
-
-9.2. Informative.
-
-   [RFC3110] RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
-	     (DNS). D.  Eastlake 3rd. May 2001.
-
-   [RFC3225] Indicating Resolver Support of DNSSEC. D. Conrad. 
-	     December 2001.
-
-   [DS]      Delegation Signer Resource Record. 
-	     O. Gudmundsson. October 2002. Work In Progress.
-
-10. Acknowledgments.
-
-   Bill Manning came up with the original idea of moving complexity
-   from the signing side down to the resolver in the form of threshold
-   validation. I've also had much appreciated help from (in no
-   particular order) Jakob Schlyter, Paul Vixie, Olafur Gudmundson and
-   Olaf Kolkman.
-
-
-11. Authors' Address
-Johan Ihren
-Autonomica AB
-Bellmansgatan 30
-SE-118 47 Stockholm, Sweden
-johani@autonomica.se
diff --git a/contrib/bind9/doc/draft/draft-kato-dnsop-local-zones-00.txt b/contrib/bind9/doc/draft/draft-kato-dnsop-local-zones-00.txt
deleted file mode 100644
index d857cd9..0000000
--- a/contrib/bind9/doc/draft/draft-kato-dnsop-local-zones-00.txt
+++ /dev/null
@@ -1,295 +0,0 @@
-
-
-
-Internet Engineering Task Force                         Akira Kato, WIDE
-INTERNET-DRAFT                                           Paul Vixie, ISC
-Expires: August 24, 2003                               February 24, 2003
-
-
-          Operational Guidelines for "local" zones in the DNS
-                  draft-kato-dnsop-local-zones-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.''
-
-To view the list Internet-Draft Shadow Directories, see
-http://www.ietf.org/shadow.html.
-
-Distribution of this memo is unlimited.
-
-The internet-draft will expire in 6 months.  The date of expiration will
-be August 24, 2003.
-
-
-Abstract
-
-A large number of DNS queries regarding to the "local" zones are sent
-over the Internet in every second.  This memo describes operational
-guidelines to reduce the unnecessary DNS traffic as well as the load of
-the Root DNS Servers.
-
-1.  Introduction
-
-While it has yet been described in a RFC, .local is used to provide a
-local subspace of the DNS tree.  Formal delegation process has not been
-completed for this TLD.  In spite of this informal status, .local has
-been used in many installations regardless of the awareness of the
-users.  Usually, the local DNS servers are not authoritative to the
-.local domain, they end up to send queries to the Root DNS Servers.
-
-There are several other DNS zones which describe the "local"
-information.  .localhost has been used to describe the localhost for
-more than a couple of decades and virtually all of the DNS servers are
-configured authoritative for .localhost and its reverse zone .127.in-
-
-
-KATO                    Expires: August 24, 2003                [Page 1]
-
-
-DRAFT                        DNS local zones               February 2003
-
-addr.arpa.  However, there are other "local" zones currently used in the
-Internet or Intranets connected to the Internet through NATs or similar
-devices.
-
-At a DNS server of an university in Japan, half of the DNS queries sent
-to one of the 13 Root DNS Servers were regarding to the .local.  At
-another DNS Server running in one of the Major ISPs in Japan, the 1/4
-were .local.  If those "local" queries are able to direct other DNS
-servers than Root, or they can be resolved locally, it contributes the
-reduction of the Root DNS Servers.
-
-2.  Rationale
-
-Any DNS queries regarding to "local" names should not be sent to the DNS
-servers on the Internet.
-
-3.  Operational Guidelines
-
-Those queries should be processed at the DNS servers internal to each
-site so that the severs respond with NXDOMAIN rather than sending
-queries to the DNS servers outside.
-
-The "local" names have common DNS suffixes which are listed below:
-
-3.1.  Local host related zones:
-
-Following two zones are described in [Barr, 1996] and .localhost is also
-defined in [Eastlake, 1999] .
-
-     o .localhost
-     o .127.in-addr.arpa
-
-
-Following two zones are for the loopback address in IPv6 [Hinden, 1998]
-.  While the TLD for IPv6 reverse lookup is .arpa as defined in [Bush,
-2001] , the old TLD .int has been used for this purpose for years
-[Thomson, 1995] and many implementations still use .int.  So it is
-suggested that both zones should be provided for each IPv6 reverse
-lookup zone for a while.
-
-     o 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int
-     o 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa
-
-
-3.2.  Locally created name space
-
-While the use of .local has been proposed in several Internet-Drafts, it
-has not been described in any Internet documents with formal status.
-However, the amount of the queries for .local is much larger than
-others, it is suggested to resolve the following zone locally:
-
-
-
-
-KATO                    Expires: August 24, 2003                [Page 2]
-
-
-DRAFT                        DNS local zones               February 2003
-
-     o .local
-
-
-
-3.3.  Private or site-local addresses
-
-The following IPv4 "private" addresses [Rekhter, 1996] and IPv6 site-
-local addresses [Hinden, 1998] should be resolved locally:
-
-     o 10.in-addr.arpa
-     o 16.172.in-addr.arpa
-     o 17.172.in-addr.arpa
-     o 18.172.in-addr.arpa
-     o 19.172.in-addr.arpa
-     o 20.172.in-addr.arpa
-     o 21.172.in-addr.arpa
-     o 22.172.in-addr.arpa
-     o 23.172.in-addr.arpa
-     o 24.172.in-addr.arpa
-     o 25.172.in-addr.arpa
-     o 26.172.in-addr.arpa
-     o 27.172.in-addr.arpa
-     o 28.172.in-addr.arpa
-     o 29.172.in-addr.arpa
-     o 30.172.in-addr.arpa
-     o 31.172.in-addr.arpa
-     o 168.192.in-addr.arpa
-     o c.e.f.ip6.int
-     o d.e.f.ip6.int
-     o e.e.f.ip6.int
-     o f.e.f.ip6.int
-     o c.e.f.ip6.arpa
-     o d.e.f.ip6.arpa
-     o e.e.f.ip6.arpa
-     o f.e.f.ip6.arpa
-
-
-3.4.  Link-local addresses
-
-The link-local address blocks for IPv4 [IANA, 2002] and IPv6 [Hinden,
-1998] should be resolved locally:
-
-     o 254.169.in-addr.arpa
-     o 8.e.f.ip6.int
-     o 9.e.f.ip6.int
-     o a.e.f.ip6.int
-     o b.e.f.ip6.int
-     o 8.e.f.ip6.arpa
-     o 9.e.f.ip6.arpa
-     o a.e.f.ip6.arpa
-     o b.e.f.ip6.arpa
-
-
-
-KATO                    Expires: August 24, 2003                [Page 3]
-
-
-DRAFT                        DNS local zones               February 2003
-
-4.  Suggestions to developers
-
-4.1.  Suggestions to DNS software implementors
-
-In order to avoid unnecessary traffic, it is suggested that DNS software
-implementors provide configuration templates or default configurations
-so that the names described in the previous section are resolved locally
-rather than sent to other DNS servers in the Internet.
-
-4.2.  Suggestions to developers of NATs or similar devices
-
-There are many NAT or similar devices available in the market.
-Regardless of the availability of DNS Servers in those devices, it is
-suggested that those devices are able to filter the DNS traffic or
-respond to the DNS traffic related to "local" zones by configuration
-regardless of its ability of DNS service.  It is suggested that this
-functionality is activated by default.
-
-5.  IANA Consideration
-
-While .local TLD has yet defined officially, there are substantial
-queries to the Root DNS Servers as of writing. About 1/4 to 1/2% of the
-traffic sent to the Root DNS Servers are related to the .local zone.
-Therefore, while it is not formally defined, it is suggested that IANA
-delegates .local TLD to an organization.
-
-The AS112 Project [Vixie, ] serves authoritative DNS service for RFC1918
-address and the link-local address.  It has several DNS server instances
-around the world by using BGP Anycast [Hardie, 2002] .  So the AS112
-Project is one of the candidates to host the .local TLD.
-
-Authors' addresses
-
-     Akira Kato
-     The University of Tokyo, Information Technology Center
-     2-11-16 Yayoi Bunkyo
-     Tokyo 113-8658, JAPAN
-     Tel: +81 3-5841-2750
-     Email: kato@wide.ad.jp
-
-
-     Paul Vixie
-     Internet Software Consortium
-     950 Charter Street
-     Redwood City, CA 94063, USA
-     Tel: +1 650-779-7001
-     Email: vixie@isc.org
-
-
-
-
-
-
-
-KATO                    Expires: August 24, 2003                [Page 4]
-
-
-DRAFT                        DNS local zones               February 2003
-
-References
-
-To be filled
-
-References
-
-Barr, 1996.
-D. Barr, "Common DNS Operational and Configuration Errors" in RFC1912
-(February 1996).
-
-Eastlake, 1999.
-D. Eastlake, "Reserved Top Level DNS Names" in RFC2606 (June 1999).
-
-Hinden, 1998.
-R. Hinden and S. Deering, "IP Version 6 Addressing Architecture" in
-RFC2373 (July 1998).
-
-Bush, 2001.
-R. Bush, "Delegation of IP6.ARPA" in RFC3152 (August 2001).
-
-Thomson, 1995.
-S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in
-RFC1886 (December 1995).
-
-Rekhter, 1996.
-Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear,
-"Address Allocation for Private Internets" in RFC1918 (February 1996).
-
-IANA, 2002.
-IANA, "Special-Use IPv4 Addresses" in RFC3330 (September 2002).
-
-Vixie, .
-P. Vixie, "AS112 Project" in AS112. http://www.as112.net/.
-
-Hardie, 2002.
-T. Hardie, "Distributing Authoritative Name Servers via Shared Unicast
-Addresses" in RFC3258 (April 2002).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-KATO                    Expires: August 24, 2003                [Page 5]
-
diff --git a/contrib/bind9/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt b/contrib/bind9/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt
deleted file mode 100644
index f9eaf26..0000000
--- a/contrib/bind9/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt
+++ /dev/null
@@ -1,1830 +0,0 @@
-  
-  
-  
-  INTERNET-DRAFT                                       S. Daniel Park
-  Expires: October 2003                              Syam Madanapalli
-  File:                                           SAMSUNG Electronics
-  draft-park-ipv6-extensions-dns-pnp-00.txt                April 2003
-  
-  
-  
-  
-                 IPv6 Extensions for DNS Plug and Play
-  
-  
-  
-  Status of This Memo   
-  
-  This document is an Internet-Draft and is in full conformance with
-  all provisions of Section 10 of RFC2026.
-
-  Internet-Drafts are working documents of the Internet Engineering
-  Task Force (IETF), its areas, and its working groups. Note that
-  other groups may also distribute working documents as
-  Internet-Drafts.
-
-  Internet-Drafts are draft documents valid for a maximum of six
-  months and may be updated, replaced, or obsoleted by other
-  documents at any time. It is inappropriate to use Internet-Drafts
-  as reference material or to cite them other than as "work in
-  progress."
-
-  The list of current Internet-Drafts can be accessed at
-  http://www.ietf.org/ietf/1id-abstracts.txt
-
-  The list of Internet-Draft Shadow Directories can be accessed at
-  http://www.ietf.org/shadow.html.
-  
-  
-  
-  Abstract  
-  
-  This document proposes automatic configuration of domain name (FQDN)
-  for IPv6 nodes using Domain Name Auto-Configuration (called 6DNAC) as
-  a part of IPv6 plug and play feature. 6DNAC allows the automatic
-  registration of domain name and corresponding IPv6 Addresses with
-  the DNS server. In order to provide 6DNAC function, Neighbor Discovery
-  Protocol [2461] will be used. Moreover, 6DNAC does not require any
-  changes to the existing DNS system.
-  
-  
-  Table of Contents 
-  
-  1.       Introduction .............................................  3
-  2.       Terminology ..............................................  3
-  3.       6DNAC Design Principles ..................................  4
-  4.       6DNAC Overview ...........................................  4
-  5.       6DNAC Requirements .......................................  5
-  5.1.     6DANR Client Requirements ................................  5
-  5.2.     6DNAC Server Requirements ................................  6
-    
-Park & Madanapalli             Expires October 2003             [Page 1]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003    
-    
-  6.       6DNAC Messages and Option Formats ........................  6
-  6.1.     Router Advertisement (RA) Message Format .................  6
-  6.2.     Neighbor Solicitation (NS) Message Format ................  7
-  6.3.     Neighbor Advertisement (NA) Message Format ...............  8
-  6.4.     Option Formats ...........................................  8
-  6.4.1.   DNS Zone Suffix Information Option Format ................  8
-  6.4.2.   Domain Name (FQDN) Option Format .........................  9
-  6.4.3.   Router Alert Option for 6DNAC ............................ 10
-  7.       6DNAC Operation .......................................... 10
-  7.1.     6DNAC Network Topology ................................... 11
-  7.2.     6DNAC Operational Scenarios .............................. 12
-  7.2.1.   Domain Name Registration-Success Case .................... 12
-  7.2.2.   Domain Name Registration-with DupAddrDetectTransmits=2.... 14
-  7.2.3.   Domain Name Registration-Defend Case ..................... 16
-  7.2.4.   Domain Name Registration in Retry Mode ................... 19
-  7.2.5.   Domain Name Registration when DAD Fails .................. 20
-  7.3.     DNS Zone Suffix Discovery and FQDN Construction .......... 22
-  7.3.1.   Sending Router Advertisement Messages .................... 22
-  7.3.2.   Processing Router Advertisement Messages ................. 22
-  7.3.3.   FQDN Lifetime expiry ..................................... 23
-  7.3.4.   Host Naming Algorithm .................................... 23
-  7.4.     Duplicate Domain Name Detection .......................... 23
-  7.4.1.   DAD with All Nodes Multicast Address ..................... 24
-  7.4.1.1. Sending Neighbor Solicitation Messages ................... 24
-  7.4.1.2. Processing Neighbor Solicitation Messages ................ 24
-  7.4.1.3. Sending Neighbor Advertisement Messages .................. 25
-  7.4.1.4. Processing Neighbor Advertisement Messages ............... 25
-  7.4.1.5. Pros and Cons ............................................ 25
-  7.4.2.   DAD with Router Alert Option for 6DNAC ................... 25
-  7.4.2.1. Sending Neighbor Solicitation Messages ................... 25
-  7.4.2.2. Processing Neighbor Solicitation Messages ................ 26
-  7.4.2.3. Sending Neighbor Advertisement Messages .................. 26
-  7.4.2.4. Processing Neighbor Advertisement Messages ............... 26
-  7.4.2.5. Pros and Cons ............................................ 26
-  7.4.3.   Explicit Detection of Duplicate Domain Name .............. 26
-  7.4.3.1. Sending Neighbor Solicitation Messages ................... 26
-  7.4.3.2. Processing Neighbor Solicitation Messages ................ 26
-  7.4.3.3. Sending Neighbor Advertisement Messages .................. 27
-  7.4.3.4. Processing Neighbor Advertisement Messages ............... 27
-  7.4.3.5. Pros and Cons ............................................ 27
-  7.4.4.   Retry Mode for Re-registering Domain Name ................ 27
-  7.5.     Domain Name Registration ................................. 27
-  8.       Security Consideration ................................... 27
-  9.       IANA Consideration ....................................... 28
-  10.      Acknowledgement .......................................... 28
-  11.      Intellectual Property .................................... 28
-  12.      Copyright ................................................ 28
-  13.      References ............................................... 29
-  14.      Author's Addresses ....................................... 30
-
-
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003             [Page 2]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
-  
-  1. Introduction 
-  
-  Today, most networks use DNS[1034][1035] for convenience. In case of
-  IPv6, DNS is more important element because of IPv6 long addresses
-  which are difficult to remember. In addition, small networks like home
-  networks using IPv6, should be able to make network easily without
-  manual configuration. Also, these small networks may not have DHCP
-  Server, DNS Server etc. that are used to configure the network. This
-  document discusses IPv6 Domain Name Auto-Configuration(6DNAC) procedure
-  for generating and registering the Domain Name and IPv6 addresses with
-  the DNS Server automatically. In order to use 6DNAC, IPv6 nodes are
-  required to implement lightweight functions specified in this document.
-  6DNAC can be applied to all defined IPv6 unicast addresses except Link
-  local IPv6 addresses, viz: Site-local and Global addresses.
-  
-  6DNAC uses Neighbor Discovery Protocol [2461] with new additions
-  (defined in section 6) and DAD procedures for generating and 
-  registering the Domain Name with the DNS server automatically.
-  
-  
-  2. Terminology
-
-  6DNAC         - IPv6 Domain Name Auto Configuration. It can provide
-                  IPv6 hosts with Domain Name Generation and 
-                  Registration automatically.
-  
-  6DNAC Client  - An IPv6 node that can generate its own unique Domain
-                  Name. Section 3 identifies the new requirements that
-                  6DNAC places on an IPv6 node to be a 6DNAC node.
-                  
-  6DNAC Server  - An IPv6 node that can collect and registrate Domain
-                  Name and IPv6 addresses automatically. 6DNAC server
-                  uses the information from the DAD operation messages
-                  with newly defined options for the registration of the 
-                  Domain Name and IPv6 Addresses. Section 3 identifies
-                  the new requirements that 6DNAC places on an IPv6 
-                  node to be a 6DNAC server. Also 6DNAC server can have 
-                  various other functions depending on network 
-                  environment and the network operator. For instance 
-                  6DNAC Server can acts as a Gateway as well Home Server
-                  in Home Networks.
- 
-  DAD           - Duplicate Address Detection (is defined [2461]) 
-  
-  DFQDND        - Duplicate Domain Name Detection
-
-  FQDN          - Fully Qualified Domain Name - FQDN and Domain Name are 
-                  used interchangeably in this document.
-  
-  NA            - Neighbor Advertisement message (is defined [2461]) 
-  
-  NS            - Neighbor Solicitation message (is defined [2461])
-
-  RA            - Router Advertisement message (is defined [2461]) 
-
-  SLAAC         - Stateless Address Autoconfiguration [2462].
-
-Park & Madanapalli             Expires October 2003             [Page 3]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
-  
-  3. 6DNAC Design Principles
-  
-  This section discusses the design principles of 6DNAC mechanism.
-  
-  1. The new procedures for plug and play DNS should not cause changes
-     to existing DNS system. 6DNAC requires lightweight functions to be 
-     implemented only at the client side of the DNS system, and uses the 
-     existing DDNS UPDATE [2136] to communicate with DNS Servers.
-  
-  2. Introducing a new protocol will always introduce new problems. 
-     6DNAC uses the existing protocols NDP [2461] with minor extensions 
-     for generating and registering the domain name automatically 
-     without defining a new protocol
-  
-  3. Reusing proven and well understood design principles/patterns 
-     will always yield a robust system. 6DNAC is based on IPv6 Address 
-     Auotoconfiguration principle, where routers advertise the prefix
-     and host adds the interface ID to the prefix and forms the IPv6 
-     address. Domain Name (FQDN) also contains two parts: host name 
-     and DNS zone suffix. Routers can advertise the DNS zone suffix 
-     on a particular link in Router Advertisements (RA Messages) and 
-     hosts can prefix their preferred host name to the DNS zone suffix
-     and form the fully qualified domain name. Also the detection of
-     duplicate domain name is similar to Duplicate Address Detection
-     (DAD) and can be part of DAD operation itself.
-  
-  
-  4. 6DNAC Overview
-  
-  6DNAC proposes minor extensions to NDP [2461] for automatic generation
-  and registration of domain name with the DNS server. It introduces two
-  new options: DNS Zone Suffix and Fully Qualified Domain Name. DNS Zone
-  Suffix option is carried in Router Advertisement (RA) messages for
-  notifying IPv6 nodes about the valid DNS Zone Suffix on the link and
-  FQDN option in Neighbor Solicitation (NS) and Neighbor Advertisement
-  (NA) messages to detect duplicate domain name. 6DNAC consists of two
-  components: 6DNAC Client and 6DNAC Server. 6DNAC Clients generate the
-  domain name based on DNS Zone Suffix using Host Naming Algorithm (see
-  section 7.3.1) and 6DNAC Server collects and registers the DNS
-  information with the DNS Server on behalf of 6DNAC Clients.
-
-  The automatic configuration of domain name using 6DNAC consists of
-  three parts.
-
-     - DNS Zone Suffix Discovery and FQDN Construction:
-
-       IPv6 Nodes collect DNS Zone Suffix information from Router
-       Advertisements and constructs FQDN by prefixing host name to the
-       DNS Zone Suffix. The IPv6 Nodes are required to implement Host 
-       Naming Algorithm for generating host part of the FQDN in the 
-       absence of administrator.
-
-  Generation of node's FQDN within the node itself has advantages. Nodes
-  can provide forward and reverse name lookups independent of the DNS
-  System by sending queries directly to IPv6 nodes [NIQ]. Moreover Domain
-  Name is some thing that is owned by the node.
-
-Park & Madanapalli             Expires October 2003             [Page 4]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-  
-     - Duplicate Domain Name Detection
-
-       All nodes are expected to go for DAD for all new IPv6 unicast
-       addresses, regardless of whether they are obtained through 
-       stateful, stateless or manual configuration. 6DNAC uses the DAD 
-       messages with new option for carrying the Domain Name along with 
-       the new IPv6 Address. 6DNAC Server captures this information and
-       updates DNS Server provided that the IPv6 Address and its domain
-       name are not duplicate. If the domain name is already in use, 
-       the 6DNAC server replies to the sender with FQDN Option in NA 
-       message indicating that the domain name is duplicate. Then the
-       node is expected to generate another domain name using host 
-       naming algorithm and go for DAD. This time the DAD is only for
-       duplicate domain name detection (DFQDND). In order to avoid
-       confusion with the normal NDP processing, the target address 
-       field of the NS message must carry the unspecified address 
-       in retry mode.  This can be repeated depending on number of
-       retries defined by the administrator in the host naming algorithm.
-
-  
-     - Domain Name Registration
-
-       6DNAC Server detects the DNS information (IPv6 Address and 
-       corresponding FQDN) from DAD/DFQDND messages and updates DNS 
-       Server using existing protocol DDNS UPDATE [2136] provided that
-       the IPv6 Address and its domain name are not duplicate.
-  
-  If an IPv6 Address is duplicate, the IPv6 node cannot perform
-  stateless address autoconfiguration repeatedly. Unlike IPv6 stateless 
-  address autoconfiguration, 6DNAC allows the automatic configuration of
-  domain name repeatedly if the domain name is duplicate depending on 
-  number of retries defined by the administrator in the host naming 
-  algorithm.
-  
-  
-  5. 6DNAC Requirements 
-  
-  Depending on the 6DNAC functionality, the IPv6 nodes implement, they
-  are called either 6DNAC Clients or 6DNAC Servers. The following 
-  sections lists the requirements that the 6DNAC Client and 6DNAC server
-  must support.
-   
-   
-  5.1. 6DANC Client Requirements
-  
-        - 6DNAC Client must recognize and process the following NDP 
-          extensions
-
-              - DNS Zone Suffix option in RA messages for generating its
-                domain name (FQDN).
-
-              - Domain Name option in NS and NA messages for detecting 
-                the duplicate domain name
- 
- 
- 
-
-Park & Madanapalli             Expires October 2003             [Page 5]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003 
-  
-        - It must generate its domain name (FQDN) based on the DNS 
-          suffix that it got from the router advertisement. And it must 
-          have a host naming algorithm for generating the host part of
-          the FQDN.
-
-        - If NA message is received with unspecified target address and
-          FQDN option, then the node must treat that the domain is 
-          duplicate.
-  
-  
-  5.2. 6DNAC Server Requirements
-  
-        - 6DNAC Server must recognize and process the following NDP
-          extensions
-      
-              - If the 6DNAC Server is a router on the link, then it
-                must advertise DNS Zone Suffix option in RA messages
-                for hosts to generate their domain name (FQDN).
-
-              - FQDN option in NS messages for detecting new DNS
-                information for of nodes on the link for which it
-                must update the AAAA RR and PTR RR in DNS Server.
-
-              - FQDN option in NA messages for notifying duplicate
-                domain name with unspecified target address.
-  
-        - 6DNAC server must update the DNS Server (both AAAA RR and
-          PTR RR) dynamically using DDNS UPDATE [2136].
-  
-        - 6DNAC server must cache this (newly detected) FQDN, Link
-          Layer Address, and IPv6 Address information, so that it can
-          decide whether it really needs to update DNS Server or not,
-          to avoid redundant updates. This information will also be
-          used for notifying the duplicate domain name.
-  
-  
-  6. 6DNAC Messages and Option Formats
-  
-  In order to achieve the plug and play DNS, 6DNAC proposes new 
-  extensions to the NDP [2461]. This section specifies the new
-  additions to NDP messages and formats of new options.
-  
-  
-  6.1. Router Advertisement (RA) Message Format
-  
-  Routers send out Router Advertisement (RA) message periodically, or
-  in response to a Router Solicitation. 6DNAC does not modify the format
-  of the RA message, but proposes new option (DNS Zone Suffix Information)
-  to be carried in RA messages.
-
-
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003             [Page 6]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-  
-      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
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |     Type      |     Code      |          Checksum             |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     | Cur Hop Limit |M|O|  Reserved |       Router Lifetime         |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                         Reachable Time                        |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                          Retrans Timer                        |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |   Options ...                                                 |
-     /                                                               /
-     |                  DNS Zone Suffix Information                  |
-     |                                                               |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-  
-  
-                          <Figure: 1 RA message>
-  
-  
-  
-  6.2. Neighbor Solicitation (NS) Message Format 
-  
-  6DNAC does not modify the format of the Neighbor Solicitation (NS)
-  message, but proposes new option (FQDN Option) to be carried in NS
-  messages. When a node is going for DAD, the node must include FQDN
-  option in NS message to participate in plug and play DNS. If the
-  node is going for Explicit Detection of Duplicate Domain Name, the
-  node must use FQDN option in NS message and unspecified address in
-  the target address field.
-  
-  
-      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 
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |     Type      |     Code      |          Checksum             |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                           Reserved                            |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                                                               |
-     +                                                               +
-     |                                                               |
-     +                       Target Address                          +
-     |                                                               |
-     +                                                               +
-     |                                                               |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |   Options ...                                                 |
-     /                                                               /
-     |                         Domain Name                           |
-     |                                                               |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-  
-  
-                         <Figure: 2 NS message>
-  
-Park & Madanapalli             Expires October 2003             [Page 7]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
-  
-  6.3. Neighbor Advertisement (NA) Message Format 
-  
-  6DNAC does not modify the format of the Neighbor Advertisement (NA)
-  message, but proposes new option (FQDN Option) to be carried in NA
-  messages. 6DNAC Server sends NA message with FQDN option to 6DNAC
-  Client that is performing duplicate domain name detection in case
-  the domain name found to be duplicate.
-
-      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
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |     Type      |     Code      |          Checksum             |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |R|S|O|                     Reserved                            |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                                                               |
-     +                                                               +
-     |                                                               |
-     +                       Target Address                          +
-     |                                                               |
-     +                                                               +
-     |                                                               |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |   Options ...                                                 |
-     /                                                               /
-     |                         FQDN Option                           |
-     |                                                               |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-  
-  
-                          <Figure: 3 NA message> 
-  
-  
-  6.4 Option Formats
-  
-  6.4.1. DNS Zone Suffix Information Option Format
-  
-  IPv6 nodes require DNS Zone Suffix for constructing their FQDN.
-  6DNAC introduces new option for routers to advertise the DNS Zone
-  Suffix Information for IPv6 nodes on the link. The suffix information
-  should be configured into routers manually.
-
-      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
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |     Type      |    Length     |          Reserved             |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                          Valid Lifetime                       |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                                                               |
-     /                       DNS Zone Suffix                         /
-     |                                                               |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-  
-  
-                   <Figure: 4 DNS Zone Suffix Information>
-
-Park & Madanapalli             Expires October 2003             [Page 8]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
-  
-  Type              [TBD]
-  
-  Length            8-bit unsigned integer. The length of the option
-                    (including the type and length fields) in units of
-                    8 octets.
-  
-  Reserved          This field is unused. It must be initialized to zero
-                    by the sender and must be ignored by the receiver.
-  
-  Valid Life Time   32-bit signed integer.  The maximum time, in 
-                    seconds, over which this suffix is valid. Nodes 
-                    should treat this as the life time for their domain
-                    name. Nodes should contact the source of this
-                    information before expiry of this time interval.
-                    A value of all one bits (0xFFFFFFFF) represents
-                    infinity.
-  
-  DNS Zone Suffix   The suffix part of the FQDN. The data in the DNS 
-                    Zone Suffix field should be encoded according to 
-                    DNS encoding rules specified in [1035].
-  
-  
-  
-  6.4.2. Domain Name (FQDN) Option Format
-  
-  
-      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
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |     Type      |    Length     |          Reserved             |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                          Valid Lifetime                       |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                                                               |
-     +                                                               +
-     |                                                               |
-     +                       FQDN Target Address                     +
-     |                                                               |
-     +                                                               +
-     |                                                               |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-     |                                                               |
-     /                         Domain Name                           /
-     |                                                               |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-  
-  
-                      <Figure: 5 FQDN Information>
-  
-  Type                 [TBD]
-  
-  Length               8-bit unsigned integer. The length of the option
-                       (including the type and length fields) in units 
-                       of 8 octets.  It must be greater than 3.
-                       
-                       
-
-Park & Madanapalli             Expires October 2003             [Page 9]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003                       
-  
-  Reserved             This field is unused. It must be initialized to
-                       zero by the sender and must be ignored by the
-                       receiver.
-  
-  Valid Life Time      32-bit signed integer.  The maximum time, in 
-                       seconds, over which this domain name is valid
-                       6DNAC should deregister this domain name at
-                       the expiry of this interval. 6DNAC clients
-                       should send updates by the expiry of this 
-                       interval. A value of all one bits (0xFFFFFFFF)
-                       represents infinity.
-
-  FQDN Target Address  The Address for which the FQDN maps to.  It 
-                       should be same as Target Address field of the 
-                       NS message in case of DAD & duplicate FQDN are
-                       running in parallel.
-
-  Domain Name          The domain name (FQDN) of the node. The data in
-                       the domain name should be encoded according to
-                       DNS encoding rules specified in [1035].
-  
-  
-  6.4.3. Router Alert Option for 6DNAC
-
-  Router Alert Option for 6DNAC is new option within the IPv6 Hop-by-Hop
-  Header for using in NDP messages.  The presence of this option in NS
-  message informs the router that this NS message is carrying Domain
-  Name information and must be processed by the 6DNAC Server on the router.
-  6DNAC Clients can use this option for sending DAD packets instead
-  of addressing the DAD packets to the all-nodes multicast address
-  when 6DNAC Server is implemented on router.
- 
-  The Router Alert option has the following format:
-
-  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-  |0 0 0|0 0 1 0 1|0 0 0 0 0 0 1 0|        Value (2 octets)       |
-  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-                     Length = 2
-
-  Values are registered and maintained by the IANA. For 6DNAC, the 
-  value has to be assigned by IANA.
-
-  Further information about this option can be obtained from 
-  IPv6 Router Alert Option [2711].
-
-
-  7. 6DNAC Operation
-  
-  6DNAC provides mechanisms for automatic generation of domain name
-  and registering it with the DNS Server for IPv6 nodes. 6DNAC consists
-  of two components: 6DNAC Client and 6DNAC Server. All nodes that want
-  to participate in plug and play DNS are required to implement 6DNAC
-  Client functionality, and one of the IPv6 nodes is required to 
-  implement 6DNAC Server functionality. The IPv6 node that implements 
-  the 6DNAC Server functionality must know the location of the DNS 
-  Server and must be a trusted node to send DDNS UPDATE [2136] messages.
-
-Park & Madanapalli             Expires October 2003            [Page 10]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
-  
-  7.1. 6DNAC Network Topology
-  
-  This section identifies the possible locations for the 6DNAC Server.
-  Note that, all nodes are required to implement 6DNAC Client 
-  functionality for constructing the domain name from the DNS Zone 
-  Suffix Information advertised by the router.  Figure 6 illustrates 
-  IPv6 host (H4) implementing 6DNAC Server functionality. In this case 
-  H4 can serve only one link (that it belongs to) for automatic 
-  registration of domain name. H4 must observe the DAD packets on the 
-  link to detect the DNS information, this requires all nodes on the 
-  link must belong to same solicited node multicast address. In general,
-  this may not be the case. So the node that is going for DAD must use
-  all nodes multicast address for DAD packets, so that the 6DNAC Server
-  (H4) can observe the DAD packets, detects IPv6 address and 
-  corresponding domain name, checks if this domain name is duplicate 
-  and finally registers the domain name with the DNS Server.
- 
-  
-                          6DNAC Server
-      +---+                   +---+                     +----------+
-      | H1|                   | H4|<--- DDNS UPDATE --->|DNS Server|
-      +-+-+                   +-+-+                     +----+-----+
-        |                       |           +----+       +---/
-        |                       |           |    |      /
-     ---+-----+-----------+-----+-----------+ R1 +-----+
-              |           |                 |    |
-              |           |                 +----+
-            +-+-+       +-+-+
-            | H2|       | H3|
-            +---+       +---+
-  
-  
-  H1, H2, H3 - 6DNAC Clients
-  H4         - 6DNAC Server
-  R1         - Router
-  
-  
-                  <Figure: 6 Example of 6DNAC Topology>
-  
-  
-  Figure 7 shows the 6DNAC Server implemented on a router R1. In this
-  case a single 6DNAC server can serve multiple links for automatic
-  configuration of the domain name. This topology also has flexibility
-  of using DAD packets with Router Alert option instead of sending DAD
-  packets to all nodes multicast address. The routers are required to
-  process all the packets with Router Alert option as per [2711].
-
-  In case of Home Networks, R1 is will acts as a Home Gateway (CPE)
-  connected to ISP. R1 delegates the prefix from the ISP edge router.
-  After delegating the prefix the CPE can advertise the DNS Zone suffix
-  along with the prefix information to the nodes on the links to which
-  the router is connected to. Note that the R1 must be configured with
-  the DNS Zone suffix Information manually. 
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 11]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-  
-                         +---+       +---+ 
-                         | H3+       | H4|
-                         +-+-+       +-+-+
-                           |           |
-                           |   LINK2   |
-      +---+             ---+--------+--+--          +----------+
-      | H1|                         |               |DNS Server|
-      +-+-+                         |               +----+-----+
-        |                        +--+-+           -------/
-        |         LINK 1         |    |          /
-     ---+-----+------------------+ R1 +---------+
-              |                  |    |      DDNS UPDATE
-              |                  +----+
-            +-+-+             6DNAC Server
-            | H2|
-            +---+
-  
-  
-  H1, H2 - 6DNAC Clients on Link1
-  H3, H4 - 6DNAC Clients on Link2
-  R1     - Router with 6DNAC Server, serving both Link1 and Link2
-  
-  
-       <Figure: 7 Example of 6DNAC Server serving multiple links>
-  
-  
-  7.2. 6DNAC Operational Scenarios
-  
-  This section provides message sequence charts for various 6DNAC
-  operational scenarios assuming that the 6DNAC Server is implemented
-  on a router. All the scenarios assume that the normal boot up time
-  stateless address autoconfiguration of Link Local address derived
-  from the Interface Identifier has been completed successfully. And
-  it is also assumed that the router is already configured with the
-  DNS Zone Suffix Information.
-
-  
-  Legend:
-  
-  6DNAC-A, B, C  : 6DNAC Clients
-  6DNAC-S        : 6DNAC Server/Router
-  DAD            : Duplicate Address Detection
-  DFQDND         : Duplicate Domain Name Detection
-  DNS-S          : DNS Server
-  
-  
-  7.2.1. Domain Name Registration-Successful Case 
-
-  This scenario starts when a 6DNAC Client receives RA message with
-  DNS Zone Suffix and other parameters including address prefix as
-  specified in NDP [2461] and wants configure its IPv6 address (Global
-  or Site Local) and domain name. It is Assumed that the 
-  DupAddrDetectTransmits is set to 1.
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 12]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-  
-   +---------+      +---------+      +---------+
-   | 6DNAC-C |      | 6DNAC-S |      |  DNS-S  |
-   +----+----+      +----+----+      +----+----+
-        |                |                |
-        |     RA with    |                |
-        | DNS Suffix Opt |                |
-        |<---------------|                |
-        |       #1       |                |
-        |---+            |                |
-  Construct |#2          |                |
-    FQDN    |            |                |
-        |<--+            |                |
-DAD/DFQDND Starts        |                |
-        |                |                |
-        |                |                |
-        |    NS With     |                |
-        |    FQDN Opt    |                |
-        |--------------->|                |
-        |       #3       |                |
-        |                |                |
-        |                |------+         |
-        |          Create FQDN  | #4      |
-        |            <FQDN,C>   |         |
-        |                |<-----+         |
-        |                |                |
-        |                |  Register FQDN |
-        |                |--------------->|
-        |                |       #5       |
-        |   #6           |                |
-        |--------+       |                |
-   No Response   |       |                |
-  DFQDND-Success |       |                |
-        |<-------+       |                |
-        |                |                |
-        |                |                |
-        v                V                v  
-
-
-          <Figure: 8 Domain Name Generation and Registration>
-           
-  
-  #1. 6DNAC Server (Router) sends out router advertisement with DNS
-      Suffix information along with other parameters as specified in
-      NDP [2461].
-  
-  #2. 6DNAC Client processes the router advertisement and constructs
-      the FQDN by prefixing hostname to the DNS Zone Suffix. It also
-      constructs IPv6 address from the autoconfiguration prefix
-      information option.
-
-  #3. 6DNAC Client starts duplicate address & FQDN detection for the
-      IPv6 address & FQDN constructed and sends out a Neighbor
-      Solicitation message with FQDN option. 
-
-      Note that the DAD packets must be addressed to all nodes multicast
-      address if Router Alert option is not used. 
-      
-Park & Madanapalli             Expires October 2003            [Page 13]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003          
-
-  #4. 6DNAC Server processes the Neighbor Solicitation message sent by
-      6DNAC Client as part of duplicate FQDN detection procedure and
-      creates a FQDN entry in its FQDN Cache (assuming that there is no
-      entry <FQDN,C>), where C is Link Layer Address of the 6DNAC Client.
-
-  #5.  6DNAC Server then registers FQDN and corresponding IPv6 address
-       through the existing protocol DDNS UPDATE.
-
-  #6.  6DNAC Client times out and observes that there is no response to
-       defend its duplicate FQDN detection procedure and the node is
-       successful in configuring its domain name.
-  
-  Note that, Stateless Address Autoconfiguration DAD procedure is not
-  depicted in the following message sequence chart, which simultaneously
-  happens along with duplicate FQDN detection.
-  
-
-  7.2.2. Domain Name Registration-with DupAddrDetectTransmits=2 
-
-  This scenario starts when a 6DNAC Client receives RA message with
-  DNS Zone Suffix and other parameters including address prefix as
-  specified in NDP [2461] and wants configure its IPv6 address (Global
-  or Site Local) and domain name. The node is configured with 
-  DupAddrDetectTransmits = 2 for reliability in delivering DAD messages.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 14]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003 
-
-   +---------+      +---------+      +---------+
-   | 6DNAC-C |      | 6DNAC-S |      |  DNS-S  |
-   +----+----+      +----+----+      +----+----+
-        |                |                |
-        |     RA with    |                |
-        | DNS Suffix Opt |                |
-        |<---------------|                |
-        |       #1       |                |
-        |---+            |                |
-  Construct |#2          |                |
-    FQDN    |            |                |
-        |<--+            |                |
-DAD/DFQDND Starts        |                |
-        |                |                |
-        |                |                |
-        |    NS With     |                |
-        |    FQDN Opt    |                |
-        |--------------->|                |
-        |       #3       |                |
-        |                |                |
-        |                |------+         |
-        |          Create FQDN  | #4      |
-        |            <FQDN,C>   |         |
-        |                |<-----+         |
-        |                |                |
-        |                |  Register FQDN |
-        |                |--------------->|
-        |                |       #5       |
-        |    NS With     |                |
-        |    FQDN Opt    |                |
-        |--------------->|                |
-        |      #6        |                |
-        |                |                |
-        |          Lookup FQDN            |
-        |          Entry exists           |
-        |                |------+         |
-        |             Ignore    | #7      |
-        |                |<-----+         |
-        |   #8           |                |
-        |--------+       |                |
-   No Response   |       |                |
-  DFQDND-Success |       |                |
-        |<-------+       |                |
-        |                |                |
-        |                |                |
-        v                V                v  
-
-  
-  
-            <Figure: 9 Verification of duplicated Domain Name>
-
-
-  Steps from #1 to #5 are same as that of scenario.7.2.1.
-  
-  #6. 6DNAC Client sends out second Neighbor Solicitation message with
-      FQDN option as part of duplicate FQDN detection.
-      
-Park & Madanapalli             Expires October 2003            [Page 15]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003      
-
-  #7. 6DNAC Server receives and observes that the FQDN Cache exactly
-      matches with that of the NS information and ignores the NS message.
-
-  #8. 6DNAC Client times out and observes that there is no response to
-      defend its duplicate FQDN detection procedure and the node is
-      successful in configuring its domain name..
-
-  
-  7.2.3. Domain Name Registration-Defend Case 
-
-  This scenario starts when two 6DNAC Client receive RA message with
-  DNS Zone Suffix and other parameters including address prefix as
-  specified in NDP [2461] and both the nodes want configure their IPv6
-  address (Global or Site Local) and domain name. In this scenario both
-  the nodes want to have same domain name.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 16]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-
-
-
-   +---------+      +---------+      +---------+      +---------+
-   | 6DNAC-A |      | 6DNAC-S |      | 6DNAC-B |      |  DNS-S  |
-   +----+----+      +----+----+      +----+----+      +----+----+
-        |                |                |                |
-        |     RA with    |     RA with    |                |
-        | DNS Suffix Opt | DNS Suffix Opt |                |
-        |<---------------|--------------->|                |
-        |       #1       |       #1       |                |
-        |---+            |                |---+            |
-  Construct | #2         |          Construct | #2         |
-      FQDN  |            |              FQDN  |            |
-        |<--+            |                |<--+            |
- DAD/DFQDND Starts       |         DAD/DFQDND Starts       |
-        |                |            <DELAYED>            |
-        |                |                |                |
-        |    NS with     |                |                |
-        |    FQDN Opt    |                |                |
-        |--------------->|                |                |
-        |      #3        |                |                |
-        |            No Entry             |                |
-        |                |------+         |                |
-        |          Create FQDN  | #4      |                |
-        |            <FQDN,A>   |         |                |
-        |                |<-----+         |                |
-        |                |                |                |
-        |                |         Register FQDN #5        |
-        |                |-------------------------------->|
-        |                |                |                |
-        |                |    NS with     |                |
-        |                |    FQDN Opt    |                |
-        |                |<---------------|                |
-        |                |       #6       |                |
-        |                |------+         |                |
-        |         FQDN is in use|         |                |
-        |          Defend DFQDND| #7      |                |
-        |                |<-----+         |                |
-        |                |                |                |
-        |                |    NA with     |                |
-        |                |    D-flag Set  |                |
-        |                |--------------->|                |
-        |                |       #8       |                |
-        |------+         |                |---+            |
- No Response   | #9      |            Enter   | #10        |
- DFQDND Success|         |          Retry Mode|            |
-        |<-----+         |                |<--+            |
-        |                |                |                |
-        v                v                v                v
-
-         
-       <Figure: 10 Multiple Hosts Requesting Same Domain Name>
-
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 17]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003          
-
-  #1. 6DNAC Server (Router) sends out router advertisement with DNS
-      Suffix information.
-      
-  #2. 6DNAC Clients A&B process the router advertisement and construct
-      their FQDN by prefixing hostname to the DNS Zone Suffix.  They
-      also construct IPv6 address from the autoconfiguration prefix
-      information option.
-      
-      When each host is trying to go for DAD, all hosts must have
-      random delay to avoid the traffic congestion according to [2461].
-      So here it is assumed that 6DNAC Client-A starts DAD first and
-      6DNAC Client-B starts DAD later.
-
-  #3. 6DNAC Client-A starts duplicate address & FQDN detection for the
-      IPv6 address & FQDN constructed and sends out a Neighbor
-      Solicitation message with FQDN option.
-   
-  #4. 6DNAC Server processes the Neighbor Solicitation message sent by
-      6DNAC Client-A as part of duplicate FQDN detection procedure and
-      creates a FQDN entry in its FQDN Cache (assuming that there is no
-      entry <FQDN,A>), where A is Link Layer Address of the 6DNAC Client-A.
-
-  #5. 6DNAC Server then registers FQDN and corresponding IPv6 address
-      through the existing protocol DDNS UPDATE.
-
-  #6. 6DNAC Client-B starts duplicate address & FQDN detection for the
-      IPv6 address & FQDN constructed and sends out a Neighbor Solicitation
-      message with FQDN option. 
-
-  #7. 6DNAC Server processes the Neighbor Solicitation message sent by
-      6DNAC Client-B as part of duplicate FQDN detection procedure and 
-      finds that the domain name is already in use by the 6DNAC Client-A.
-      Hence, concludes to defend the duplicate FQDN detection of 6DNAC
-      Client-B.
-
-  #8. 6DNAC Server sends out Neighbor Advertisement message with FQDN
-      option to 6DNAC Client-B to defend its duplicate FQDN detection.
-
-  #9. 6DNAC Client-A times out and observes that there is no response to
-      defend its duplicate FQDN detection procedure and the node is 
-      successful in configuring its domain name.
-
-  #10. 6DNAC Client-B observes that there is a NA with FQDN option
-       indicating that the domain name is duplicate and enters Retry
-       Mode. In retry mode, 6DNAC Client constructs another FQDN based
-       on Host Naming Algorithm. The number of retries is defined by the
-       administrator and must be a configurable value.
-  
-
-
-
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 18]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003  
-  
-  7.2.4. Domain Name Registration in Retry Mode
-
-  Pre-Conditions:
-
-  1. Duplicate Address Detection has succeeded 
-  2. Duplicate FQDN Detection FAILED
-  3. FQDN is the first FQDN one constructed and FAILED
-  4. FQDN2 is the second FQDN to be constructed
-  5. The Neighbor Solicitation in the 'Retry Mode'
-    carries unspecified address in its target field (NS*).
-
-   +---------+      +---------+      +---------+
-   | 6DNAC-C |      | 6DNAC-S |      |  DNS-S  |
-   +----+----+      +----+----+      +----+----+
-        |                |                |
-        |--------+       |                |
-    Construct    | #1    |                |
-    new FQDN2    |       |                |
-        |<-------+       |                |
-        |                |                |
-  DFQDND Restarts        |                |
-        |                |                |
-        |                |                |
-        |    NS* With    |                |
-        |    FQDN Opt    |                |
-        |--------------->|                |
-        |       #2       |                |
-        |                |                |
-        |            No Entry             |
-        |                |------+         |
-        |          Create FQDN  | #3      |
-        |            <FQDN2,C>  |         |
-        |                |<-----+         |
-        |                |                |
-        |                | Register FQDN2 |
-        |                |--------------->|
-        |                |       #4       |
-        |                |                |
-        |--------+       |                |
-   No Response   | #5    |                |
-  DFQDND-Success |       |                |
-        |<-------+       |                |
-        |                |                |
-        v                V                v
-
-                
-                <Figure: 11 Regeneration of Domain Name>
-                
-
-
-
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 19]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
- 
-  #1. 6DNAC Client constructs the FQDN again as per Host Naming Algorithm,
-      the DNS Zone Suffix, and it is FQDN2.
-  #2. It then starts Duplicate Detection only for Domain Name. 6DNAC
-      Client sends out NS with FQDN option and unspecified target
-      address.
-
-  #3. 6DNAC Server processes the Retry Mode NS message and finds that
-      the FQDN2 is not in use and creates Cache entry as <FQDN2, C>.
-
-  #4. It then starts registration procedures with the DNS Server.
-
-  #5. Meanwhile, 6DNAC Client timesout and observes that there is no
-      defending NA for its DFQDND NS sent out and successfully
-      configures its domain name.
-
-
-  7.2.5. Domain Name Registration when DAD Fails
-
-  Duplicate domain name detection and subsequent registration starts 
-  if and only if the DAD for IPv6 address succeeds. If the DAD for
-  IPv6 address fails then no actions are taken for domain name. When
-  DAD fails for stateless address autoconfiguration, then the domain
-  configuration starts only when the address has been configured using 
-  Stateful Address Configuration methods and the node is going on DAD
-  for this address.
-
-  This scenario starts when a 6DNAC Client receives RA message with
-  DNS Zone Suffix and other parameters including address prefix as
-  specified in NDP [2461] and wants configure its IPv6 address (Global
-  or Site Local) and domain name.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 20]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-
-   +---------+      +---------+      +---------+      +---------+
-   | 6DNAC-A |      | 6DNAC-S |      | 6DNAC-B |      |  DNS-S  |
-   +----+----+      +----+----+      +----+----+      +----+----+
-        |                |                |                |
-        |                |                |                |
-        |     RA with    |                |                |
-        | DNS Suffix Opt |                |                |
-        |<---------------|                |                |
-        |       #1       |                |                |
-        |-----+          |                |                |
-    Construct |          |                |                |
-      FQDN&   | #2       |                |                |
-    IPv6 Addr |          |                |                |
-        |<----+          |                |                |
- DAD/DFQDND Starts       |                |                |
-        |                |                |                |
-        |                |                |                |
-        |    NS with     |                |                |
-        |    FQDN Opt    |                |                |
-        |--------------->+--------------->|                |
-        |       #3       |        #3      |                |
-        |            No Entry             |                |
-        |                |------+         |                |
-        |          Create FQDN  |         |                |
-        |            <FQDN,A>   | #4      |                |
-        |                |<-----+         |                |
-        |                |                |                |
-        |                |                |------+         |
-        |                |           My IPv6 Addr| #5      |
-        |                |                |<-----+         |
-        |                |   Defend DAD   |                |
-        |                |    with NA     |                |
-        |<---------------+<---------------|                |
-        |      #6        |       #6       |                |
-        |              Entry              |                |
-        |                |------+         |                |
-        |          Delete FQDN  | #7      |                |
-        |                |<-----+         |                |
-        |                |                |                |
-        |----+           |                |                |
-  DAD Failed | #8        |                |                |
- Stop DFQDND |           |                |                |
-        |<---+           |                |                |
-        |                |                |                |
-        v                v                v                v
-
-                     <Figure: 12 DAD failure>
-
-  #1. 6DNAC Server sends out Router Advertisement to 6DNAC Client-A.
-
-  #2. 6DNAC Client-A constructs IPv6 Address based on the prefix and
-      FQDN as per Host Naming Algorithm. 
-
-  #3. It then starts Duplicate address & FQDN Detection, for the newly 
-      constructed IPv6 address and FQDN, and sends out DAD/DFQDND NS
-      with FQDN option.  
-
-Park & Madanapalli             Expires October 2003            [Page 21]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003      
-
-  #4. 6DNAC Server processes the DAD/DFQDND NS message and finds 
-      that there is no entry for the FQDN in its cache. And,
-      creates Cache entry as <FQDN, A> and starts a Registration
-      timer with RegistrationWaitTime seconds.
-
-  #5. 6DNAC Client-B finds that the DAD/DFQDND-NS target address is 
-      in its unicast address list.  
-
-  #6. It then starts defending DAD by sending NA to all-nodes multicast.
-
-  #7. 6DNAC Server finds that the DAD has failed for 6DNAC Client-A.  
-      And, deletes its FQDN Cache entry <FQDN,A>.
-      
-  #8. 6DNAC Client gets defending DAD-NA and desists from DAD. 
-      And also, stops Duplicate FQDN Detection as well.
-      At this point the address must be configured using stateful 
-      methods and the domain name registration starts with the DAD
-      for the newly constructed IPv6 address.
-  
-  7.3. DNS Zone Suffix Discovery and FQDN Construction
-  
-  7.3.1. Sending Router Advertisement Messages
-
-  Routers send out Router Advertisement message periodically, 
-  or in response to a Router Solicitation. Router should include 
-  the DNS Zone Suffix Option in their advertisements. If the DNS
-  Zone Suffix changes (similar to Site Renumbering), then it should
-  advertise the Old Zone Suffix with zero Valid Lifetime and New
-  Zone Suffix with proper non-zero Valid Lifetime.  In any other
-  case, a router should not send this option twice in a single
-  router advertisement.
-
-  7.3.2. Processing Router Advertisement Messages  
-
-  For each DNS Zone Suffix Option in Router Advertisement,
-
-  a. 6DNAC node stores the Zone Suffix information in its local
-     database.  Also, constructs FQDN as per Host Naming Algorithm.
-
-  b. If the node has not configured FQDN yet,
-
-     1. If the node is going to perform DAD for either Site local or 
-        Global Address, then it should include FQDN option to perform
-        Duplicate FQDN Detection in parallel with DAD.
-
-     2. If the node has already got either Site local or Global 
-        address, then it should send out NS with FQDN option and 
-        unspecified target address to perform Duplicate FQDN 
-        Detection.
-
-  c. If the node has already configured FQDN, and if the 
-     advertisement carries two DNS Zone Suffix Options,
-     First DNS Zone Suffix should match with the configured FQDN 
-     Suffix and its Valid Lifetime must be zero. Second DNS Zone
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 22]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-
-
-     Suffix should have non-zero Valid Lifetime. In this case, the
-     node constructs new FQDN based on the new DNS Zone Suffix (from
-     second DNS Zone Suffix option), and perform Duplicate FQDN 
-     Detection with unspecified target address.  Also, it should
-     overwrite the old FQDN with the newly constructed FQDN.
-     
-
-  7.3.3. FQDN Lifetime expiry
-
-  6DNAC Server:  
-  It should delete the FQDN cache entry and should de-register from
-  the DNS Server.
-
-  6DNAC Client:
-  It should send update to 6DNAC Server by restarting the Duplicate 
-  FQDN Detection. 
-  
-  7.3.4. Host Naming Algorithm
- 
-  A node constructs FQDN by combining DNS Zone Suffix and the hostname
-  as depicted in the following diagram.
-
-     +------------------+----------------------------------+
-     |     Host Name    |          Advertised Suffix       |
-     +------------------+----------------------------------+
-
-          <Figure 13: Fully Qualified Domain Name format>
-
-  A node can choose Host Name using any of the following methods:
- 
-  a. String form of random number generated from the Interface 
-     Identifier.
-     
-  b. List of configured Host Names provided by the administrator.
-
-  
-  The number of retries must be specified in this algorithm in 
-  case of domain name duplication.
-  
-    
-  7.4. Duplicate Domain Name Detection
-  
-  The procedure for detecting duplicated FQDNs uses Neighbor
-  Solicitation and Advertisement messages as described below.
-
-  If a duplicate FQDN is detected during the procedure, the
-  FQDN cannot be assigned to the node.
-
-  An FQDN on which the DFQDND Procedure is applied is said 
-  to be tentative until the procedure has completed successfully.  
-  A tentative FQDN is not considered "assigned to the node" in the 
-  traditional sense.  That is, the node must accept Neighbor 
-  Advertisement message containing the tentative FQDN in the FQDN 
-  Option.
-
-
-Park & Madanapalli             Expires October 2003            [Page 23]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-
-
-  It should also be noted that DFQDN must be performed prior to 
-  registering with DNS Server to prevent multiple nodes from using 
-  the same FQDN simultaneously. All the Duplicate Address Detection 
-  Neighbor Solicitation messages must carry Source Link Layer Address 
-  Option as specified in NDP [2461]. 
-
-  The detection of duplicate FQDN can be achieved through one of the
-  following three types of procedures.
-  
-  1. DAD with All Nodes Multicast Address
-  2. DAD with Router Alert Option for 6DNAC.
-  3. Explicit Detection of Duplicate Domain Name
-   
-  Even though three solutions are listed, authors prefer only one 
-  procedure to be followed in future based on further analysis and
-  comments received from others. 
-  
-  7.4.1. DAD with All Nodes Multicast Address
-  
-  7.4.1.1. Sending Neighbor Solicitation Messages
-
-  6DNAC Client sends Neighbor Solicitation Messages as part
-  of Duplicate Address Detection SLAAC [2462] with the following 
-  extra information and modifications:
-
-  a. Include FQDN Option in the DAD Neighbor Solicitation Message
-  b. Destination Address is set to All Nodes Multicast Address
-
-  There may be a case where DAD has succeeded but DFQDND is in Retry 
-  Mode. In such case, the Neighbor Solicitation must carry unspecified 
-  address in the ICMP target address field and new domain name in FQDN
-  option to re-try the registration of the domain name.
-
-  7.4.1.2. Processing Neighbor Solicitation Messages
-
-  6DNAC Clients must ignore the FQDN option found in any of the
-  neighbor solicitation messages.
-
-  6DNAC Server processes FQDN Option found in the Duplicate Address 
-  Detection Neighbor Solicitation Messages as described below:
-
-  Lookup FQDN Cache for the domain name in FQDN Option.
-
-  If the entry exists and 
-   i. Link Layer Address matches with SLLA option, this is the case, 
-      where node has changed its IPv6 address or updating the valid 
-      life time. 6DNAC Server updates its cache and also updates DNS
-      Server using DDNS-UPDATE. If there is no change in IPv6 address
-      or life time then no updates are sent to the DNS server. 
-
-  ii. Link Layer Address differs with SLLA option, defend the duplicate 
-      FQDN Detection by sending Neighbor Advertisement Message as 
-      described in $7.4.1.3$.
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 24]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-
-
-  else,
-    Lookup FQDN Cache for the Link Layer Address in SLLA Option.
-
-    If the entry exists, update the FQDN Cache and update DNS Server 
-    using DDNS-UPDATE. This is the case, where node has changed its
-    domain name (similar to Site Re-numbering).
-
-    If then entry does not exists, then it means that this is the new 
-    registration. It must create a cache entry and start Registration    
-    
-    timer with RegistrationWaitTime. At the expiry of the Registration
-    timer, it should update DNS Server with DDNS-UPDATE.
-
-  7.4.1.3. Sending Neighbor Advertisement Messages
-
-  6DNAC Server sends Neighbor Advertisement Messages as part
-  of Duplicate Address Detection SLAAC [2462] with the FQDN Option 
-  in Neighbor Advertisement message to defend duplicate FQDN 
-  detection.
-
-  There may be the case where defending of duplicate address detection 
-  is not required but defending of FQDN is required.  In such instance, 
-  the defending Neighbor Advertisement must carry FQDN and unspecified
-  address in the ICMP target address field.
-
-  7.4.1.4. Processing Neighbor Advertisement Messages
-
-  6DNAC Server must ignore the any FQDN option found any of 
-  the neighbor advertisement messages.  If the Neighbor Advertisement
-  is a DAD defending, then it must delete its FQDN Cache entry created 
-  on the reception of DAD Neighbor Solicitation message.
-
-  When 6DNAC Clients gets the duplicate address detection neighbor
-  advertisement messages with FQDN option set it means that its
-  duplicate FQDN detection failed and enters Retry Mode.
-
-  7.4.1.5. Pros and Cons
-  
-  The advantage of this procedure is that it does not need any 
-  extension header options to be included. The disadvantage of this 
-  procedure is that, it needs change in the existing DAD procedure.
-  The change is only that the DAD neighbor solicitations are to be 
-  addressed to all nodes multicast address instead of solicited 
-  node multicast address. The another disadvantage is that, it needs 
-  the existence of Duplicate Address Detection Procedure to 
-  perform duplicate FQDN detection. 
-  
-  7.4.2. DAD with Router Alert Option for 6DNAC
-
-  7.4.2.1. Sending Neighbor Solicitation Messages
-
-  6DNAC Client sends Neighbor Solicitation Messages as part
-  of Duplicate Address Detection SLAAC [2462] with the following 
-  extra information:
-
-
-Park & Madanapalli             Expires October 2003            [Page 25]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-
-
-  a. Include Hop-by-Hop extension Header with Router Alert Option
-     for 6DNAC as described in IPv6 Router Alert Option[2711].
-
-  b. Include FQDN Option in the DAD Neighbor Solicitation Message
-
-  7.4.2.2. Processing Neighbor Solicitation Messages
-
-  This is same as described in $7.4.1.2$. 
-
-  7.4.2.3. Sending Neighbor Advertisement Messages
-
-  This is same as described in $7.4.1.3$. 
-
-  7.4.2.4. Processing Neighbor Advertisement Messages
-
-  This is same as described in $7.4.1.4$.
-
-  7.4.2.5. Pros and Cons
-
-  The advantage of this procedure is that it does not disturb
-  the existing implementation and their way of processing the 
-  packets.  The disadvantage is that, it needs the existence 
-  of Duplicate Address Detection Procedure to perform duplicate 
-  FQDN detection. Another disadvantage is that this procedure 
-  requires 6DNAC Server functionality to be implemented on Router.
-  However, in this case 6DNAC Server can serve multiple links.
-  
-  7.4.3. Explicit Detection of Duplicate Domain Name
-
-  In this procedure Duplicate FQDN Detection starts after completion
-  of successful Site local or Global Address configuration.
-  
-  7.4.3.1. Sending Neighbor Solicitation Messages
-
-  6DNAC Client sends Neighbor Solicitation Messages as part
-  of Duplicate FQDN Detection with the following information:
-
-  a. Include FQDN Option in the Neighbor Solicitation Message
-
-  b. Destination Address is set to All Nodes Multicast Address
-     or uses Router Alert Option for 6DNAC, when 6DNAC Server is 
-     implemented on router.
-
-  c. Target Address is set to Unspecified Address
-
-  d. Other fields are set as per DAD SLAAC [2462].
-
-  7.4.3.2. Processing Neighbor Solicitation Messages
-
-  This is same as described in $7.4.1.2$.
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 26]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003 
-
-
-  7.4.3.3. Sending Neighbor Advertisement Messages
-
-  This is same as described in $7.4.1.3$.
-
-  7.4.3.4. Processing Neighbor Advertisement Messages
-
-  This is same as described in $7.4.1.4$.
-
-  7.4.3.5. Pros and Cons
-
-  The advantage of this procedure is that it does not need the
-  existing duplicate address detection procedure.  This is introduced
-  as the DAD procedure is found to be redundant in when IPv6 addresses
-  are constructed from the interface ID [DIID].
-
-  Note that, if 6DNAC Clients know the address of 6DNAC Server then
-  they can directly send DFQDND-NS to 6DNAC Server. 
-
-  7.4.4. Retry Mode for Re-registering Domain Name
-
-  In retry mode, nodes construct new FQDN as per Host Naming Algorithm.
-  Then they restart Duplicate FQDN Detection as described in $7.4.3$.
-
-
-  7.5. Domain Name Registration
-  
-  6DNAC Server must be an authenticated to update the DNS Server.
-  6DNAC Server must also be configured with the DNS Server 
-  information.
-
-  6DNAC Server detects the DNS information (IPv6 Address and 
-  corresponding FQDN) from DAD/DFQDND messages and caches the
-  information. It also have an associated Registration Timer with 
-  RegistrationWaitTime to wait for the successful completion of 
-  DFQDND and update DNS Server using existing protocol DDNS UPDATE 
-  [2136].
-  
-                 
-  8. Security Consideration
-   
-  If someone wants to hijack correct Domain Name registration, they 
-  could send a NS message with incorrect or same Domain Name to the
-  6DNAC server repeatedly and server would start the Domain Name 
-  registration through above mechanism, which is a security hole. 
-  As described in [2461], a host can check validity of NDP messages.
-  If the NDP message include an IP Authentication Header, the message
-  authenticates correctly. For DNS UPDATE processing, secure DNS
-  Dynamic Update is described in [3007].
-  
-
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 27]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-
-  
-  9. IANA Consideration
-  
-  Values in the Router Alert Option are registered and maintained by
-  IANA. For 6DNAC, the value has to be assigned by IANA. Also IANA is
-  required to assign the Type values for DNS Zone Suffix Information
-  option and FADN option.
-
-  
-  10. Acknowledgement
-  
-  Special thanks are due to Badrinarayana N.S. and Christian Huitema for
-  many helpful suggestions and revisions. 
-  
-  
-  11. Intellectual Property
-
-  The following notice is copied from RFC 2026 [Bradner, 1996],
-  Section 10.4, and describes the position of the IETF concerning
-  intellectual property claims made against this document.
-
-  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 other 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 implementers 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.
-  
-  
-  12. Copyright
-
-  The following copyright notice is copied from RFC 2026 [Bradner,
-  1996], Section 10.4, and describes the applicable copyright for this
-  document.
-
-  Copyright (C) The Internet Society July 12, 2001. 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
-
-Park & Madanapalli             Expires October 2003            [Page 28]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-
-
-  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
-  HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
-  MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-  
-  
-  13. References
-   
-  [2373]        Hinden, R. and S. Deering, "IP Version 6 Addressing 
-                Architecture", RFC 2373, July 1998. 
-       
-  [2460]        Deering, S. abd R. Hinden, "Internet Protocol, 
-                Version 6 (IPv6) Specification", RFC 2460, 
-                December 1998. 
-               
-  [2461]        Narten, T., Nordmark, E. and W. Simpson, "Neighbor 
-                Discovery for IP version 6(IPv6)", RFC 2461, December 
-                1998. 
-
-  [2462]        S. Thomson and Narten T, "IPv6 Stateless Address Auto- 
-                Configuration", RFC 2462, December 1998. 
-               
-  [2711]        C. Patridge and A.Jackson, "IPv6 Router Alert Option",
-                RFC 2711, October 1999. 
-             
-  [1034]        P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND 
-                FACILITIES", RFC 1034, November 1987. 
-               
-  [1035]        P. Mockapetris, "Domain Names - Implementation and 
-                Specification" RFC 1035, November 1987. 
-
-  [2136]        P. Vixie et al., "Dynamic Updates in the Domain Name
-                System (DNS UPDATE)", RFC2136, April 1997.
-                
-  [3007]        B. Wellington, "Secure Domain Name System (DNS) Dynamic 
-                Update", RFC 3007, November 2000.
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 29]
-
-INTERNET-DRAFT     IPv6 Extensions for DNS Plug and Play      April 2003
-
-                 
-  [DIID]        yokohama-dad-vs-diid.pdf
-                at http://playground.sun.com/ipng/presentations/July2002/
-                
-  [DNSISSUES]   Durand, A., "IPv6 DNS transition issues", draft-ietf-              
-                dnsop-ipv6-dns-issues-00.txt, work in progress.
-                
-  [PREFIX]      S. Miyakawa, R. Droms, "Requirements for IPv6 prefix
-                delegation", draft-ietf-ipv6-prefix-delegation-
-                requirement-01.txt, work in progress.
-   
-  [Autoreg]     H. Kitamura, "Domain Name Auto-Registration for 
-                Plugged-in IPv6 Nodes", draft-ietf-dnsext-ipv6-name-
-                auto-reg-00.txt, work in progress.
-
-  [NIQ]         Matt Crawford, "IPv6 Node Information Queries", <draft-
-                ietf-ipngwg-icmp-name-lookups-09.txt>, work in progress.
-                  
-  
-  14. Author's Addresses 
-  
-  Soohong Daniel Park 
-  Mobile Platform Laboratory, SAMSUNG Electronics, KOREA 
-  Phone: +82-31-200-3728 
-  Email:soohong.park@samsung.com
-  
-  Syam Madanapalli
-  Network Systems Division, SAMSUNG India Software Operations, INDIA
-  Phone: +91-80-5550555
-  Email:syam@samsung.com
-  
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Park & Madanapalli             Expires October 2003            [Page 30]
diff --git a/contrib/bind9/doc/draft/update b/contrib/bind9/doc/draft/update
deleted file mode 100644
index 6ac2090..0000000
--- a/contrib/bind9/doc/draft/update
+++ /dev/null
@@ -1,46 +0,0 @@
-#!/bin/sh
-commit=
-for i
-do
-	z=`expr "$i" : 'http://www.ietf.org/internet-drafts/\(.*\)'`
-	if test -n "$z"
-	then
-		i="$z"
-	fi
-	if test -f "$i"
-	then
-		continue
-	fi
-	pat=`echo "$i" | sed 's/...txt/??.txt/'`
-	old=`echo $pat 2> /dev/null`
-	if test "X$old" != "X$pat"
-	then
-		newer=0
-		for j in $old
-		do
-			if test $j ">" $i
-			then
-				 newer=1
-			fi
-		done
-		if test $newer = 1
-		then
-			continue;
-		fi
-	fi
-	if fetch "http://www.ietf.org/internet-drafts/$i" 
-	then
-		cvs add "$i" 
-		if test "X$old" != "X$pat"
-		then
-			rm $old
-			cvs delete $old
-			commit="$commit $old"
-		fi
-		commit="$commit $i"
-	fi
-done
-if test -n "$commit"
-then
-	cvs commit -m "new draft" $commit
-fi
diff --git a/contrib/bind9/doc/misc/Makefile.in b/contrib/bind9/doc/misc/Makefile.in
index c5df0cb..501e3be 100644
--- a/contrib/bind9/doc/misc/Makefile.in
+++ b/contrib/bind9/doc/misc/Makefile.in
@@ -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.3.18.4 2007/12/02 22:36:01 marka Exp $
+# $Id: Makefile.in,v 1.7 2007/09/24 04:21:59 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/doc/misc/format-options.pl b/contrib/bind9/doc/misc/format-options.pl
index aa433b3..b0b8d52 100644
--- a/contrib/bind9/doc/misc/format-options.pl
+++ b/contrib/bind9/doc/misc/format-options.pl
@@ -15,7 +15,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: format-options.pl,v 1.2.18.2 2007/12/02 23:46:31 tbox Exp $
+# $Id: format-options.pl,v 1.5 2007/09/24 04:21:59 marka Exp $
 
 print <<END;
 
diff --git a/contrib/bind9/doc/misc/ipv6 b/contrib/bind9/doc/misc/ipv6
index aeba275..4060bc3 100644
--- a/contrib/bind9/doc/misc/ipv6
+++ b/contrib/bind9/doc/misc/ipv6
@@ -110,4 +110,4 @@ RELEVANT RFCs
 3542:  Advanced Sockets Application Program Interface (API) for IPv6
 
 
-$Id: ipv6,v 1.6.18.3 2004/08/10 04:28:41 jinmei Exp $
+$Id: ipv6,v 1.9 2004/08/10 04:27:51 jinmei Exp $
diff --git a/contrib/bind9/doc/misc/migration b/contrib/bind9/doc/misc/migration
index 4116b63..21856bf 100644
--- a/contrib/bind9/doc/misc/migration
+++ b/contrib/bind9/doc/misc/migration
@@ -264,4 +264,4 @@ necessary, the umask should be set explicitly in the script used to
 start the named process.
 
 
-$Id: migration,v 1.45.18.3 2008/03/18 15:45:43 jreed Exp $
+$Id: migration,v 1.49 2008/03/18 15:42:53 jreed Exp $
diff --git a/contrib/bind9/doc/misc/options b/contrib/bind9/doc/misc/options
index c9a29a7..3416a3b 100644
--- a/contrib/bind9/doc/misc/options
+++ b/contrib/bind9/doc/misc/options
@@ -55,7 +55,10 @@ options {
         allow-notify { <address_match_element>; ... };
         allow-query { <address_match_element>; ... };
         allow-query-cache { <address_match_element>; ... };
+        allow-query-cache-on { <address_match_element>; ... };
+        allow-query-on { <address_match_element>; ... };
         allow-recursion { <address_match_element>; ... };
+        allow-recursion-on { <address_match_element>; ... };
         allow-transfer { <address_match_element>; ... };
         allow-update { <address_match_element>; ... };
         allow-update-forwarding { <address_match_element>; ... };
@@ -134,6 +137,7 @@ options {
         max-transfer-time-in <integer>;
         max-transfer-time-out <integer>;
         max-udp-size <integer>;
+        memstatistics <boolean>;
         memstatistics-file <quoted_string>;
         min-refresh-time <integer>;
         min-retry-time <integer>;
@@ -146,6 +150,8 @@ options {
         notify-delay <integer>;
         notify-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ];
         notify-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ];
+        notify-to-soa <boolean>;
+        nsec3-test-zone <boolean>; // test only
         pid-file ( <quoted_string> | none );
         port <integer>;
         preferred-glue <string>;
@@ -153,11 +159,14 @@ options {
         query-source <querysource4>;
         query-source-v6 <querysource6>;
         querylog <boolean>;
+        queryport-pool-ports <integer>; // obsolete
+        queryport-pool-updateinterval <integer>; // obsolete
         random-device <quoted_string>;
         recursing-file <quoted_string>;
         recursion <boolean>;
         recursive-clients <integer>;
         request-ixfr <boolean>;
+        request-nsid <boolean>;
         reserved-sockets <integer>;
         rfc2308-type1 <boolean>; // not yet implemented
         root-delegation-only [ exclude { <quoted_string>; ... } ];
@@ -166,7 +175,10 @@ options {
         serial-queries <integer>; // obsolete
         serial-query-rate <integer>;
         server-id ( <quoted_string> | none |;
-        sig-validity-interval <integer>;
+        sig-signing-nodes <integer>;
+        sig-signing-signatures <integer>;
+        sig-signing-type <integer>;
+        sig-validity-interval <integer> [ <integer> ];
         sortlist { <address_match_element>; ... };
         stacksize <size>;
         statistics-file <quoted_string>;
@@ -185,10 +197,12 @@ options {
         transfers-out <integer>;
         transfers-per-ns <integer>;
         treat-cr-as-space <boolean>; // obsolete
+        try-tcp-refresh <boolean>;
         update-check-ksk <boolean>;
         use-alt-transfer-source <boolean>;
         use-id-pool <boolean>; // obsolete
         use-ixfr <boolean>;
+        use-queryport-pool <boolean>; // obsolete
         use-v4-udp-ports { <portrange>; ... };
         use-v6-udp-ports { <portrange>; ... };
         version ( <quoted_string> | none );
@@ -216,6 +230,11 @@ server <netprefix> {
         transfers <integer>;
 };
 
+statistics-channels {
+        inet ( <ipv4_address> | <ipv6_address> | * ) [ port ( <integer> | *
+            ) ] [ allow { <address_match_element>; ... } ];
+};
+
 trusted-keys { <string> <integer> <integer> <integer> <quoted_string>; ... };
 
 view <string> <optional_class> {
@@ -226,7 +245,10 @@ view <string> <optional_class> {
         allow-notify { <address_match_element>; ... };
         allow-query { <address_match_element>; ... };
         allow-query-cache { <address_match_element>; ... };
+        allow-query-cache-on { <address_match_element>; ... };
+        allow-query-on { <address_match_element>; ... };
         allow-recursion { <address_match_element>; ... };
+        allow-recursion-on { <address_match_element>; ... };
         allow-transfer { <address_match_element>; ... };
         allow-update { <address_match_element>; ... };
         allow-update-forwarding { <address_match_element>; ... };
@@ -305,12 +327,17 @@ view <string> <optional_class> {
         notify-delay <integer>;
         notify-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ];
         notify-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ];
+        notify-to-soa <boolean>;
+        nsec3-test-zone <boolean>; // test only
         preferred-glue <string>;
         provide-ixfr <boolean>;
         query-source <querysource4>;
         query-source-v6 <querysource6>;
+        queryport-pool-ports <integer>; // obsolete
+        queryport-pool-updateinterval <integer>; // obsolete
         recursion <boolean>;
         request-ixfr <boolean>;
+        request-nsid <boolean>;
         rfc2308-type1 <boolean>; // not yet implemented
         root-delegation-only [ exclude { <quoted_string>; ... } ];
         rrset-order { [ class <string> ] [ type <string> ] [ name
@@ -337,7 +364,10 @@ view <string> <optional_class> {
                     <integer> | * ) ];
                 transfers <integer>;
         };
-        sig-validity-interval <integer>;
+        sig-signing-nodes <integer>;
+        sig-signing-signatures <integer>;
+        sig-signing-type <integer>;
+        sig-validity-interval <integer> [ <integer> ];
         sortlist { <address_match_element>; ... };
         suppress-initial-notify <boolean>; // not yet implemented
         topology { <address_match_element>; ... }; // not implemented
@@ -346,13 +376,16 @@ view <string> <optional_class> {
         transfer-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ];
         trusted-keys { <string> <integer> <integer> <integer>
             <quoted_string>; ... };
+        try-tcp-refresh <boolean>;
         update-check-ksk <boolean>;
         use-alt-transfer-source <boolean>;
+        use-queryport-pool <boolean>; // obsolete
         zero-no-soa-ttl <boolean>;
         zero-no-soa-ttl-cache <boolean>;
         zone <string> <optional_class> {
                 allow-notify { <address_match_element>; ... };
                 allow-query { <address_match_element>; ... };
+                allow-query-on { <address_match_element>; ... };
                 allow-transfer { <address_match_element>; ... };
                 allow-update { <address_match_element>; ... };
                 allow-update-forwarding { <address_match_element>; ... };
@@ -403,19 +436,26 @@ view <string> <optional_class> {
                     ) ];
                 notify-source-v6 ( <ipv6_address> | * ) [ port ( <integer>
                     | * ) ];
+                notify-to-soa <boolean>;
+                nsec3-test-zone <boolean>; // test only
                 pubkey <integer> <integer> <integer>
                     <quoted_string>; // obsolete
-                sig-validity-interval <integer>;
+                sig-signing-nodes <integer>;
+                sig-signing-signatures <integer>;
+                sig-signing-type <integer>;
+                sig-validity-interval <integer> [ <integer> ];
                 transfer-source ( <ipv4_address> | * ) [ port ( <integer> |
                     * ) ];
                 transfer-source-v6 ( <ipv6_address> | * ) [ port (
                     <integer> | * ) ];
+                try-tcp-refresh <boolean>;
                 type ( master | slave | stub | hint | forward |
                     delegation-only );
                 update-check-ksk <boolean>;
                 update-policy { ( grant | deny ) <string> ( name |
-                    subdomain | wildcard | self | selfsub | selfwild )
-                    <string> <rrtypelist>; ... };
+                    subdomain | wildcard | self | selfsub | selfwild |
+                    krb5-self | ms-self | krb5-subdomain | ms-subdomain |
+                    tcp-self | 6to4-self ) <string> <rrtypelist>; ... };
                 use-alt-transfer-source <boolean>;
                 zero-no-soa-ttl <boolean>;
                 zone-statistics <boolean>;
@@ -426,6 +466,7 @@ view <string> <optional_class> {
 zone <string> <optional_class> {
         allow-notify { <address_match_element>; ... };
         allow-query { <address_match_element>; ... };
+        allow-query-on { <address_match_element>; ... };
         allow-transfer { <address_match_element>; ... };
         allow-update { <address_match_element>; ... };
         allow-update-forwarding { <address_match_element>; ... };
@@ -473,15 +514,22 @@ zone <string> <optional_class> {
         notify-delay <integer>;
         notify-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ];
         notify-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ];
+        notify-to-soa <boolean>;
+        nsec3-test-zone <boolean>; // test only
         pubkey <integer> <integer> <integer> <quoted_string>; // obsolete
-        sig-validity-interval <integer>;
+        sig-signing-nodes <integer>;
+        sig-signing-signatures <integer>;
+        sig-signing-type <integer>;
+        sig-validity-interval <integer> [ <integer> ];
         transfer-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ];
         transfer-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ];
+        try-tcp-refresh <boolean>;
         type ( master | slave | stub | hint | forward | delegation-only );
         update-check-ksk <boolean>;
         update-policy { ( grant | deny ) <string> ( name | subdomain |
-            wildcard | self | selfsub | selfwild ) <string> <rrtypelist>;
-            ... };
+            wildcard | self | selfsub | selfwild | krb5-self | ms-self |
+            krb5-subdomain | ms-subdomain | tcp-self | 6to4-self ) <string>
+            <rrtypelist>; ... };
         use-alt-transfer-source <boolean>;
         zero-no-soa-ttl <boolean>;
         zone-statistics <boolean>;
diff --git a/contrib/bind9/doc/misc/sort-options.pl b/contrib/bind9/doc/misc/sort-options.pl
index f516159..4251521 100755
--- a/contrib/bind9/doc/misc/sort-options.pl
+++ b/contrib/bind9/doc/misc/sort-options.pl
@@ -14,7 +14,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: sort-options.pl,v 1.3.36.2 2007/12/02 23:46:31 tbox Exp $
+# $Id: sort-options.pl,v 1.3 2007/09/24 23:46:48 tbox Exp $
 
 sub sortlevel() {
 	my @options = ();
diff --git a/contrib/bind9/doc/rfc/index b/contrib/bind9/doc/rfc/index
deleted file mode 100644
index fea5f71..0000000
--- a/contrib/bind9/doc/rfc/index
+++ /dev/null
@@ -1,119 +0,0 @@
- 952:	DOD INTERNET HOST TABLE SPECIFICATION
-1032:	DOMAIN ADMINISTRATORS GUIDE
-1033:	DOMAIN ADMINISTRATORS OPERATIONS GUIDE
-1034:	DOMAIN NAMES - CONCEPTS AND FACILITIES
-1035:	DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
-1101:	DNS Encoding of Network Names and Other Types
-1122:	Requirements for Internet Hosts -- Communication Layers
-1123:	Requirements for Internet Hosts -- Application and Support
-1183:	New DNS RR Definitions (AFSDB, RP, X25, ISDN and RT)
-1348:	DNS NSAP RRs
-1535:	A Security Problem and Proposed Correction
-	 With Widely Deployed DNS Software
-1536:	Common DNS Implementation Errors and Suggested Fixes
-1537:	Common DNS Data File Configuration Errors
-1591:	Domain Name System Structure and Delegation
-1611:	DNS Server MIB Extensions
-1612:	DNS Resolver MIB Extensions
-1706:	DNS NSAP Resource Records
-1712:	DNS Encoding of Geographical Location
-1750:	Randomness Recommendations for Security
-1876:	A Means for Expressing Location Information in the Domain Name System
-1886:	DNS Extensions to support IP version 6
-1982:	Serial Number Arithmetic
-1995:	Incremental Zone Transfer in DNS
-1996:	A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
-2052:	A DNS RR for specifying the location of services (DNS SRV)
-2104:	HMAC: Keyed-Hashing for Message Authentication
-2119:	Key words for use in RFCs to Indicate Requirement Levels
-2133:	Basic Socket Interface Extensions for IPv6
-2136:	Dynamic Updates in the Domain Name System (DNS UPDATE)
-2137:	Secure Domain Name System Dynamic Update
-2163:	Using the Internet DNS to Distribute MIXER
-	 Conformant Global Address Mapping (MCGAM)
-2168:	Resolution of Uniform Resource Identifiers using the Domain Name System
-2181:	Clarifications to the DNS Specification
-2230:	Key Exchange Delegation Record for the DNS
-2308:	Negative Caching of DNS Queries (DNS NCACHE)
-2317:	Classless IN-ADDR.ARPA delegation
-2373:	IP Version 6 Addressing Architecture
-2374:	An IPv6 Aggregatable Global Unicast Address Format
-2375:	IPv6 Multicast Address Assignments
-2418:	IETF Working Group Guidelines and Procedures
-2535:	Domain Name System Security Extensions
-2536:	DSA KEYs and SIGs in the Domain Name System (DNS)
-2537:	RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)
-2538:	Storing Certificates in the Domain Name System (DNS)
-2539:	Storage of Diffie-Hellman Keys in the Domain Name System (DNS)
-2540:	Detached Domain Name System (DNS) Information
-2541:	DNS Security Operational Considerations
-2553:	Basic Socket Interface Extensions for IPv6
-2671:	Extension Mechanisms for DNS (EDNS0)
-2672:	Non-Terminal DNS Name Redirection
-2673:	Binary Labels in the Domain Name System
-2782:	A DNS RR for specifying the location of services (DNS SRV)
-2825:	A Tangled Web: Issues of I18N, Domain Names, and the
-	 Other Internet protocols
-2826:	IAB Technical Comment on the Unique DNS Root
-2845:	Secret Key Transaction Authentication for DNS (TSIG)
-2874:	DNS Extensions to Support IPv6 Address Aggregation and Renumbering
-2915:	The Naming Authority Pointer (NAPTR) DNS Resource Record
-2929:	Domain Name System (DNS) IANA Considerations
-2930:	Secret Key Establishment for DNS (TKEY RR)
-2931:	DNS Request and Transaction Signatures ( SIG(0)s )
-3007:	Secure Domain Name System (DNS) Dynamic Update
-3008:	Domain Name System Security (DNSSEC) Signing Authority
-3056:	Connection of IPv6 Domains via IPv4 Clouds
-3071:	Reflections on the DNS, RFC 1591, and Categories of Domains
-3090:	DNS Security Extension Clarification on Zone Status
-3110:	RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)
-3123:	A DNS RR Type for Lists of Address Prefixes (APL RR)
-3152:	Delegation of IP6.ARPA
-3197:	Applicability Statement for DNS MIB Extensions
-3225:	Indicating Resolver Support of DNSSEC
-3226:	DNSSEC and IPv6 A6 aware server/resolver message size requirements
-3258:	Distributing Authoritative Name Servers via Shared Unicast Addresses
-3363:	Representing Internet Protocol version 6 (IPv6)
-	 Addresses in the Domain Name System (DNS)
-3364:	Tradeoffs in Domain Name System (DNS) Support
-	 for Internet Protocol version 6 (IPv6)
-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)
-3493:	Basic Socket Interface Extensions for IPv6
-3513:	Internet Protocol Version 6 (IPv6) Addressing Architecture
-3596:	DNS Extensions to Support IP Version 6
-3597:	Handling of Unknown DNS Resource Record (RR) Types
-3645:	Generic Security Service Algorithm for
-	 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"
-4193:	Unique Local IPv6 Unicast Addresses
-4255:	Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
-4343:	Domain Name System (DNS) Case Insensitivity Clarification
-4367:	What's in a Name: False Assumptions about DNS Names
-4398:	Storing Certificates in the Domain Name System (DNS)
-4431:	The DNSSEC Lookaside Validation (DLV) DNS Resource Record
-4408:	Sender Policy Framework (SPF) for Authorizing Use of Domains
-	 in E-Mail, Version 1
-4470:	Minimally Covering NSEC Records and DNSSEC On-line Signing
-4634:	US Secure Hash Algorithms (SHA and HMAC-SHA)
-4641:	DNSSEC Operational Practices
-4648:	The Base16, Base32, and Base64 Data Encodings
-4701:	A DNS Resource Record (RR) for Encoding
-         Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)
-5155:	DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
diff --git a/contrib/bind9/doc/rfc/rfc1032.txt b/contrib/bind9/doc/rfc/rfc1032.txt
deleted file mode 100644
index 0e82721..0000000
--- a/contrib/bind9/doc/rfc/rfc1032.txt
+++ /dev/null
@@ -1,781 +0,0 @@
-Network Working Group                                       M. Stahl
-Request for Comments: 1032                         SRI International
-                                                       November 1987
-
-
-                      DOMAIN ADMINISTRATORS GUIDE
-
-
-STATUS OF THIS MEMO
-
-   This memo describes procedures for registering a domain with the
-   Network Information Center (NIC) of Defense Data Network (DDN), and
-   offers guidelines on the establishment and administration of a domain
-   in accordance with the requirements specified in RFC-920.  It is
-   intended for use by domain administrators.  This memo should be used
-   in conjunction with RFC-920, which is an official policy statement of
-   the Internet Activities Board (IAB) and the Defense Advanced Research
-   Projects Agency (DARPA).  Distribution of this memo is unlimited.
-
-BACKGROUND
-
-   Domains are administrative entities that provide decentralized
-   management of host naming and addressing.  The domain-naming system
-   is distributed and hierarchical.
-
-   The NIC is designated by the Defense Communications Agency (DCA) to
-   provide registry services for the domain-naming system on the DDN and
-   DARPA portions of the Internet.
-
-   As registrar of top-level and second-level domains, as well as
-   administrator of the root domain name servers on behalf of DARPA and
-   DDN, the NIC is responsible for maintaining the root server zone
-   files and their binary equivalents.  In addition, the NIC is
-   responsible for administering the top-level domains of "ARPA," "COM,"
-   "EDU," "ORG," "GOV," and "MIL" on behalf of DCA and DARPA until it
-   becomes feasible for other appropriate organizations to assume those
-   responsibilities.
-
-   It is recommended that the guidelines described in this document be
-   used by domain administrators in the establishment and control of
-   second-level domains.
-
-THE DOMAIN ADMINISTRATOR
-
-   The role of the domain administrator (DA) is that of coordinator,
-   manager, and technician.  If his domain is established at the second
-   level or lower in the tree, the DA must register by interacting with
-   the management of the domain directly above his, making certain that
-
-
-
-Stahl                                                           [Page 1]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-   his domain satisfies all the requirements of the administration under
-   which his domain would be situated.  To find out who has authority
-   over the name space he wishes to join, the DA can ask the NIC
-   Hostmaster.  Information on contacts for the top-level and second-
-   level domains can also be found on line in the file NETINFO:DOMAIN-
-   CONTACTS.TXT, which is available from the NIC via anonymous FTP.
-
-   The DA should be technically competent; he should understand the
-   concepts and procedures for operating a domain server, as described
-   in RFC-1034, and make sure that the service provided is reliable and
-   uninterrupted.  It is his responsibility or that of his delegate to
-   ensure that the data will be current at all times.  As a manager, the
-   DA must be able to handle complaints about service provided by his
-   domain name server.  He must be aware of the behavior of the hosts in
-   his domain, and take prompt action on reports of problems, such as
-   protocol violations or other serious misbehavior.  The administrator
-   of a domain must be a responsible person who has the authority to
-   either enforce these actions himself or delegate them to someone
-   else.
-
-   Name assignments within a domain are controlled by the DA, who should
-   verify that names are unique within his domain and that they conform
-   to standard naming conventions.  He furnishes access to names and
-   name-related information to users both inside and outside his domain.
-   He should work closely with the personnel he has designated as the
-   "technical and zone" contacts for his domain, for many administrative
-   decisions will be made on the basis of input from these people.
-
-THE DOMAIN TECHNICAL AND ZONE CONTACT
-
-   A zone consists of those contiguous parts of the domain tree for
-   which a domain server has complete information and over which it has
-   authority.  A domain server may be authoritative for more than one
-   zone.  The domain technical/zone contact is the person who tends to
-   the technical aspects of maintaining the domain's name server and
-   resolver software, and database files.  He keeps the name server
-   running, and interacts with technical people in other domains and
-   zones to solve problems that affect his zone.
-
-POLICIES
-
-   Domain or host name choices and the allocation of domain name space
-   are considered to be local matters.  In the event of conflicts, it is
-   the policy of the NIC not to get involved in local disputes or in the
-   local decision-making process.  The NIC will not act as referee in
-   disputes over such matters as who has the "right" to register a
-   particular top-level or second-level domain for an organization.  The
-   NIC considers this a private local matter that must be settled among
-
-
-
-Stahl                                                           [Page 2]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-   the parties involved prior to their commencing the registration
-   process with the NIC.  Therefore, it is assumed that the responsible
-   person for a domain will have resolved any local conflicts among the
-   members of his domain before registering that domain with the NIC.
-   The NIC will give guidance, if requested, by answering specific
-   technical questions, but will not provide arbitration in disputes at
-   the local level.  This policy is also in keeping with the distributed
-   hierarchical nature of the domain-naming system in that it helps to
-   distribute the tasks of solving problems and handling questions.
-
-   Naming conventions for hosts should follow the rules specified in
-   RFC-952.  From a technical standpoint, domain names can be very long.
-   Each segment of a domain name may contain up to 64 characters, but
-   the NIC strongly advises DAs to choose names that are 12 characters
-   or fewer, because behind every domain system there is a human being
-   who must keep track of the names, addresses, contacts, and other data
-   in a database.  The longer the name, the more likely the data
-   maintainer is to make a mistake.  Users also will appreciate shorter
-   names.  Most people agree that short names are easier to remember and
-   type; most domain names registered so far are 12 characters or fewer.
-
-   Domain name assignments are made on a first-come-first-served basis.
-   The NIC has chosen not to register individual hosts directly under
-   the top-level domains it administers.  One advantage of the domain
-   naming system is that administration and data maintenance can be
-   delegated down a hierarchical tree.  Registration of hosts at the
-   same level in the tree as a second-level domain would dilute the
-   usefulness of this feature.  In addition, the administrator of a
-   domain is responsible for the actions of hosts within his domain.  We
-   would not want to find ourselves in the awkward position of policing
-   the actions of individual hosts.  Rather, the subdomains registered
-   under these top-level domains retain the responsibility for this
-   function.
-
-   Countries that wish to be registered as top-level domains are
-   required to name themselves after the two-letter country code listed
-   in the international standard ISO-3166.  In some cases, however, the
-   two-letter ISO country code is identical to a state code used by the
-   U.S. Postal Service.  Requests made by countries to use the three-
-   letter form of country code specified in the ISO-3166 standard will
-   be considered in such cases so as to prevent possible conflicts and
-   confusion.
-
-
-
-
-
-
-
-
-
-Stahl                                                           [Page 3]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-HOW TO REGISTER
-
-   Obtain a domain questionnaire from the NIC hostmaster, or FTP the
-   file NETINFO:DOMAIN-TEMPLATE.TXT from host SRI-NIC.ARPA.
-
-   Fill out the questionnaire completely.  Return it via electronic mail
-   to HOSTMASTER@SRI-NIC.ARPA.
-
-   The APPENDIX to this memo contains the application form for
-   registering a top-level or second-level domain with the NIC.  It
-   supersedes the version of the questionnaire found in RFC-920.  The
-   application should be submitted by the person administratively
-   responsible for the domain, and must be filled out completely before
-   the NIC will authorize establishment of a top-level or second-level
-   domain.  The DA is responsible for keeping his domain's data current
-   with the NIC or with the registration agent with which his domain is
-   registered.  For example, the CSNET and UUCP managements act as
-   domain filters, processing domain applications for their own
-   organizations.  They pass pertinent information along periodically to
-   the NIC for incorporation into the domain database and root server
-   files.  The online file NETINFO:ALTERNATE-DOMAIN-PROCEDURE.TXT
-   outlines this procedure.  It is highly recommended that the DA review
-   this information periodically and provide any corrections or
-   additions.  Corrections should be submitted via electronic mail.
-
-WHICH DOMAIN NAME?
-
-   The designers of the domain-naming system initiated several general
-   categories of names as top-level domain names, so that each could
-   accommodate a variety of organizations.  The current top-level
-   domains registered with the DDN Network Information Center are ARPA,
-   COM, EDU, GOV, MIL, NET, and ORG, plus a number of top-level country
-   domains.  To join one of these, a DA needs to be aware of the purpose
-   for which it was intended.
-
-      "ARPA" is a temporary domain.  It is by default appended to the
-      names of hosts that have not yet joined a domain.  When the system
-      was begun in 1984, the names of all hosts in the Official DoD
-      Internet Host Table maintained by the NIC were changed by adding
-      of the label ".ARPA" in order to accelerate a transition to the
-      domain-naming system.  Another reason for the blanket name changes
-      was to force hosts to become accustomed to using the new style
-      names and to modify their network software, if necessary.  This
-      was done on a network-wide basis and was directed by DCA in DDN
-      Management Bulletin No. 22.  Hosts that fall into this domain will
-      eventually move to other branches of the domain tree.
-
-
-
-
-
-Stahl                                                           [Page 4]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-      "COM" is meant to incorporate subdomains of companies and
-      businesses.
-
-      "EDU" was initiated to accommodate subdomains set up by
-      universities and other educational institutions.
-
-      "GOV" exists to act as parent domain for subdomains set up by
-      government agencies.
-
-      "MIL" was initiated to act as parent to subdomains that are
-      developed by military organizations.
-
-      "NET" was introduced as a parent domain for various network-type
-      organizations.  Organizations that belong within this top-level
-      domain are generic or network-specific, such as network service
-      centers and consortia.  "NET" also encompasses network
-      management-related organizations, such as information centers and
-      operations centers.
-
-      "ORG" exists as a parent to subdomains that do not clearly fall
-      within the other top-level domains.  This may include technical-
-      support groups, professional societies, or similar organizations.
-
-   One of the guidelines in effect in the domain-naming system is that a
-   host should have only one name regardless of what networks it is
-   connected to.  This implies, that, in general, domain names should
-   not include routing information or addresses.  For example, a host
-   that has one network connection to the Internet and another to BITNET
-   should use the same name when talking to either network.  For a
-   description of the syntax of domain names, please refer to Section 3
-   of RFC-1034.
-
-VERIFICATION OF DATA
-
-   The verification process can be accomplished in several ways.  One of
-   these is through the NIC WHOIS server.  If he has access to WHOIS,
-   the DA can type the command "whois domain <domain name><return>".
-   The reply from WHOIS will supply the following: the name and address
-   of the organization "owning" the domain; the name of the domain; its
-   administrative, technical, and zone contacts; the host names and
-   network addresses of sites providing name service for the domain.
-
-
-
-
-
-
-
-
-
-
-Stahl                                                           [Page 5]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-         Example:
-
-         @whois domain rice.edu<Return>
-
-            Rice University (RICE-DOM)
-            Advanced Studies and Research
-            Houston, TX 77001
-
-            Domain Name: RICE.EDU
-
-               Administrative Contact:
-               Kennedy, Ken  (KK28)  Kennedy@LLL-CRG.ARPA (713) 527-4834
-               Technical Contact, Zone Contact:
-               Riffle, Vicky R.  (VRR)  rif@RICE.EDU
-               (713) 527-8101 ext 3844
-
-            Domain servers:
-
-            RICE.EDU                     128.42.5.1
-            PENDRAGON.CS.PURDUE.EDU      128.10.2.5
-
-
-   Alternatively, the DA can send an electronic mail message to
-   SERVICE@SRI-NIC.ARPA.  In the subject line of the message header, the
-   DA should type "whois domain <domain name>".  The requested
-   information will be returned via electronic mail.  This method is
-   convenient for sites that do not have access to the NIC WHOIS
-   service.
-
-   The initial application for domain authorization should be submitted
-   via electronic mail, if possible, to HOSTMASTER@SRI-NIC.ARPA.  The
-   questionnaire described in the appendix may be used or a separate
-   application can be FTPed from host SRI-NIC.ARPA.  The information
-   provided by the administrator will be reviewed by hostmaster
-   personnel for completeness.  There will most likely be a few
-   exchanges of correspondence via electronic mail, the preferred method
-   of communication, prior to authorization of the domain.
-
-HOW TO GET MORE INFORMATION
-
-   An informational table of the top-level domains and their root
-   servers is contained in the file NETINFO:DOMAINS.TXT online at SRI-
-   NIC.ARPA. This table can be obtained by FTPing the file.
-   Alternatively, the information can be acquired by opening a TCP or
-   UDP connection to the NIC Host Name Server, port 101 on SRI-NIC.ARPA,
-   and invoking the command "ALL-DOM".
-
-
-
-
-
-Stahl                                                           [Page 6]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-   The following online files, all available by FTP from SRI-NIC.ARPA,
-   contain pertinent domain information:
-
-      - NETINFO:DOMAINS.TXT, a table of all top-level domains and the
-        network addresses of the machines providing domain name
-        service for them.  It is updated each time a new top-level
-        domain is approved.
-
-      - NETINFO:DOMAIN-INFO.TXT contains a concise list of all
-        top-level and second-level domain names registered with the
-        NIC and is updated monthly.
-
-      - NETINFO:DOMAIN-CONTACTS.TXT also contains a list of all the
-        top level and second-level domains, but includes the
-        administrative, technical and zone contacts for each as well.
-
-      - NETINFO:DOMAIN-TEMPLATE.TXT contains the questionnaire to be
-        completed before registering a top-level or second-level
-        domain.
-
-   For either general or specific information on the domain system, do
-   one or more of the following:
-
-      1. Send electronic mail to HOSTMASTER@SRI-NIC.ARPA
-
-      2. Call the toll-free NIC hotline at (800) 235-3155
-
-      3. Use FTP to get background RFCs and other files maintained
-         online at the NIC.  Some pertinent RFCs are listed below in
-         the REFERENCES section of this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stahl                                                           [Page 7]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-REFERENCES
-
-   The references listed here provide important background information
-   on the domain-naming system.  Path names of the online files
-   available via anonymous FTP from the SRI-NIC.ARPA host are noted in
-   brackets.
-
-      1. Defense Communications Agency DDN Defense Communications
-         System, DDN Management Bulletin No. 22, Domain Names
-         Transition, March 1984.
-         [ DDN-NEWS:DDN-MGT-BULLETIN-22.TXT ]
-
-      2. Defense Communications Agency DDN Defense Communications
-         System, DDN Management Bulletin No. 32, Phase I of the Domain
-         Name Implementation, January 1987.
-         [ DDN-NEWS:DDN-MGT-BULLETIN-32.TXT ]
-
-      3. Harrenstien, K., M. Stahl, and E. Feinler, "Hostname
-         Server", RFC-953, DDN Network Information Center, SRI
-         International, October 1985.  [ RFC:RFC953.TXT ]
-
-      4. Harrenstien, K., M. Stahl, and E. Feinler, "Official DoD
-         Internet Host Table Specification", RFC-952, DDN Network
-         Information Center, SRI International, October 1985.
-         [ RFC:RFC952.TXT ]
-
-      5. ISO, "Codes for the Representation of Names of Countries",
-         ISO-3166, International Standards Organization, May 1981.
-         [ Not online ]
-
-      6. Lazear, W.D., "MILNET Name Domain Transition", RFC-1031,
-         Mitre Corporation, October 1987.  [ RFC:RFC1031.TXT ]
-
-      7. Lottor, M.K., "Domain Administrators Operations Guide",
-         RFC-1033, DDN Network Information Center, SRI International,
-         July 1987.  [ RFC:RFC1033.TXT ]
-
-      8. Mockapetris, P., "Domain Names - Concepts and Facilities",
-         RFC-1034, USC Information Sciences Institute, October 1987.
-         [ RFC:RFC1034.TXT ]
-
-      9. Mockapetris, P., "Domain Names - Implementation and
-         Specification", RFC-1035, USC Information Sciences Institute,
-         October 1987.  [ RFC:RFC1035.TXT ]
-
-     10. Mockapetris, P., "The Domain Name System", Proceedings of the
-         IFIP 6.5 Working Conference on Computer Message Services,
-         Nottingham, England, May 1984.  Also as ISI/RS-84-133, June
-
-
-
-Stahl                                                           [Page 8]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-         1984.  [ Not online ]
-
-     11. Mockapetris, P., J. Postel, and P. Kirton, "Name Server
-         Design for Distributed Systems", Proceedings of the Seventh
-         International Conference on Computer Communication, October
-         30 to November 3 1984, Sidney, Australia.  Also as
-         ISI/RS-84-132, June 1984.  [ Not online ]
-
-     12. Partridge, C., "Mail Routing and the Domain System", RFC-974,
-         CSNET-CIC, BBN Laboratories, January 1986.
-         [ RFC:RFC974.TXT ]
-
-     13. Postel, J., "The Domain Names Plan and Schedule", RFC-881,
-         USC Information Sciences Institute, November 1983.
-         [ RFC:RFC881.TXT ]
-
-     14. Reynolds, J., and Postel, J., "Assigned Numbers", RFC-1010
-         USC Information Sciences Institute, May 1986.
-         [ RFC:RFC1010.TXT ]
-
-     15. Romano, S., and Stahl, M., "Internet Numbers", RFC-1020,
-         SRI, November 1987.
-         [ RFC:RFC1020.TXT ]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stahl                                                           [Page 9]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-APPENDIX
-
-   The following questionnaire may be FTPed from SRI-NIC.ARPA as
-   NETINFO:DOMAIN-TEMPLATE.TXT.
-
-   ---------------------------------------------------------------------
-
-   To establish a domain, the following information must be sent to the
-   NIC Domain Registrar (HOSTMASTER@SRI-NIC.ARPA):
-
-   NOTE: The key people must have electronic mailboxes and NIC
-   "handles," unique NIC database identifiers.  If you have access to
-   "WHOIS", please check to see if you are registered and if so, make
-   sure the information is current.  Include only your handle and any
-   changes (if any) that need to be made in your entry.  If you do not
-   have access to "WHOIS", please provide all the information indicated
-   and a NIC handle will be assigned.
-
-   (1)  The name of the top-level domain to join.
-
-         For example:  COM
-
-   (2) The NIC handle of the administrative head of the organization.
-   Alternately, the person's name, title, mailing address, phone number,
-   organization, and network mailbox.  This is the contact point for
-   administrative and policy questions about the domain.  In the case of
-   a research project, this should be the principal investigator.
-
-         For example:
-
-            Administrator
-
-               Organization  The NetWorthy Corporation
-               Name          Penelope Q. Sassafrass
-               Title         President
-               Mail Address  The NetWorthy Corporation
-                             4676 Andrews Way, Suite 100
-                             Santa Clara, CA 94302-1212
-               Phone Number  (415) 123-4567
-               Net Mailbox   Sassafrass@ECHO.TNC.COM
-               NIC Handle    PQS
-
-   (3)  The NIC handle of the technical contact for the domain.
-   Alternately, the person's name, title, mailing address, phone number,
-   organization, and network mailbox.  This is the contact point for
-   problems concerning the domain or zone, as well as for updating
-   information about the domain or zone.
-
-
-
-
-Stahl                                                          [Page 10]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-         For example:
-
-            Technical and Zone Contact
-
-               Organization  The NetWorthy Corporation
-               Name          Ansel A. Aardvark
-               Title         Executive Director
-               Mail Address  The NetWorthy Corporation
-                             4676 Andrews Way, Suite 100
-                             Santa Clara, CA. 94302-1212
-               Phone Number  (415) 123-6789
-               Net Mailbox   Aardvark@ECHO.TNC.COM
-               NIC Handle    AAA2
-
-   (4)  The name of the domain (up to 12 characters).  This is the name
-   that will be used in tables and lists associating the domain with the
-   domain server addresses.  [While, from a technical standpoint, domain
-   names can be quite long (programmers beware), shorter names are
-   easier for people to cope with.]
-
-         For example:  TNC
-
-   (5)  A description of the servers that provide the domain service for
-   translating names to addresses for hosts in this domain, and the date
-   they will be operational.
-
-         A good way to answer this question is to say "Our server is
-         supplied by person or company X and does whatever their standard
-         issue server does."
-
-            For example:  Our server is a copy of the one operated by
-            the NIC; it will be installed and made operational on
-            1 November 1987.
-
-   (6) Domains must provide at least two independent servers for the
-   domain.  Establishing the servers in physically separate locations
-   and on different PSNs is strongly recommended.  A description of the
-   server machine and its backup, including
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stahl                                                          [Page 11]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-         (a) Hardware and software (using keywords from the Assigned
-         Numbers RFC).
-
-         (b) Host domain name and network addresses (which host on which
-         network for each connected network).
-
-         (c) Any domain-style nicknames (please limit your domain-style
-         nickname request to one)
-
-         For example:
-
-            - Hardware and software
-
-               VAX-11/750  and  UNIX,    or
-               IBM-PC      and  MS-DOS,  or
-               DEC-1090    and  TOPS-20
-
-            - Host domain names and network addresses
-
-               BAR.FOO.COM 10.9.0.193 on ARPANET
-
-            - Domain-style nickname
-
-               BR.FOO.COM (same as BAR.FOO.COM 10.9.0.13 on ARPANET)
-
-   (7)  Planned mapping of names of any other network hosts, other than
-   the server machines, into the new domain's naming space.
-
-         For example:
-
-            BAR-FOO2.ARPA (10.8.0.193) -> FOO2.BAR.COM
-            BAR-FOO3.ARPA (10.7.0.193) -> FOO3.BAR.COM
-            BAR-FOO4.ARPA (10.6.0.193) -> FOO4.BAR.COM
-
-
-   (8)  An estimate of the number of hosts that will be in the domain.
-
-         (a) Initially
-         (b) Within one year
-         (c) Two years
-         (d) Five years.
-
-         For example:
-
-            (a) Initially  =   50
-            (b) One year   =  100
-            (c) Two years  =  200
-            (d) Five years =  500
-
-
-
-Stahl                                                          [Page 12]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-   (9)  The date you expect the fully qualified domain name to become
-   the official host name in HOSTS.TXT.
-
-         Please note: If changing to a fully qualified domain name (e.g.,
-         FOO.BAR.COM) causes a change in the official host name of an
-         ARPANET or MILNET host, DCA approval must be obtained beforehand.
-         Allow 10 working days for your requested changes to be processed.
-
-         ARPANET sites should contact ARPANETMGR@DDN1.ARPA.  MILNET sites
-         should contact HOSTMASTER@SRI-NIC.ARPA, 800-235-3155, for
-         further instructions.
-
-   (10) Please describe your organization briefly.
-
-         For example: The NetWorthy Corporation is a consulting
-         organization of people working with UNIX and the C language in an
-         electronic networking environment.  It sponsors two technical
-         conferences annually and distributes a bimonthly newsletter.
-
-   ---------------------------------------------------------------------
-
-   This example of a completed application corresponds to the examples
-   found in the companion document RFC-1033, "Domain Administrators
-   Operations Guide."
-
-   (1)  The name of the top-level domain to join.
-
-            COM
-
-   (2)  The NIC handle of the administrative contact person.
-
-            NIC Handle    JAKE
-
-   (3)  The NIC handle of the domain's technical and zone
-         contact person.
-
-            NIC Handle    DLE6
-
-   (4)  The name of the domain.
-
-            SRI
-
-   (5)  A description of the servers.
-
-            Our server is the TOPS20 server JEEVES supplied by ISI; it
-            will be installed and made operational on 1 July 1987.
-
-
-
-
-
-Stahl                                                          [Page 13]
-
-RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
-
-
-   (6)  A description of the server machine and its backup:
-
-            (a) Hardware and software
-
-               DEC-1090T   and  TOPS20
-               DEC-2065    and  TOPS20
-
-            (b) Host domain name and network address
-
-               KL.SRI.COM  10.1.0.2 on ARPANET, 128.18.10.6 on SRINET
-               STRIPE.SRI.COM  10.4.0.2 on ARPANET, 128.18.10.4 on SRINET
-
-            (c) Domain-style nickname
-
-               None
-
-   (7)  Planned mapping of names of any other network hosts, other than
-   the server machines, into the new domain's naming space.
-
-            SRI-Blackjack.ARPA (128.18.2.1) -> Blackjack.SRI.COM
-            SRI-CSL.ARPA (192.12.33.2) -> CSL.SRI.COM
-
-   (8)  An estimate of the number of hosts that will be directly within
-   this domain.
-
-            (a) Initially  =   50
-            (b) One year   =  100
-            (c) Two years  =  200
-            (d) Five years =  500
-
-   (9)  A date when you expect the fully qualified domain name to become
-   the official host name in HOSTS.TXT.
-
-            31 September 1987
-
-   (10)  Brief description of organization.
-
-            SRI International is an independent, nonprofit, scientific
-            research organization.  It performs basic and applied research
-            for government and commercial clients, and contributes to
-            worldwide economic, scientific, industrial, and social progress
-            through research and related services.
-
-
-
-
-
-
-
-
-
-Stahl                                                          [Page 14]
-
diff --git a/contrib/bind9/doc/rfc/rfc1033.txt b/contrib/bind9/doc/rfc/rfc1033.txt
deleted file mode 100644
index 37029fd..0000000
--- a/contrib/bind9/doc/rfc/rfc1033.txt
+++ /dev/null
@@ -1,1229 +0,0 @@
-Network Working Group                                         M. Lottor
-Request For Comments:  1033                           SRI International
-                                                          November 1987
-
-
-                 DOMAIN ADMINISTRATORS OPERATIONS GUIDE
-
-
-
-STATUS OF THIS MEMO
-
-   This RFC provides guidelines for domain administrators in operating a
-   domain server and maintaining their portion of the hierarchical
-   database.  Familiarity with the domain system is assumed.
-   Distribution of this memo is unlimited.
-
-ACKNOWLEDGMENTS
-
-   This memo is a formatted collection of notes and excerpts from the
-   references listed at the end of this document.  Of particular mention
-   are Paul Mockapetris and Kevin Dunlap.
-
-INTRODUCTION
-
-   A domain server requires a few files to get started.  It will
-   normally have some number of boot/startup files (also known as the
-   "safety belt" files).  One section will contain a list of possible
-   root servers that the server will use to find the up-to-date list of
-   root servers.  Another section will list the zone files to be loaded
-   into the server for your local domain information.  A zone file
-   typically contains all the data for a particular domain.  This guide
-   describes the data formats that can be used in zone files and
-   suggested parameters to use for certain fields.  If you are
-   attempting to do anything advanced or tricky, consult the appropriate
-   domain RFC's for more details.
-
-   Note:  Each implementation of domain software may require different
-   files.  Zone files are standardized but some servers may require
-   other startup files.  See the appropriate documentation that comes
-   with your software.  See the appendix for some specific examples.
-
-ZONES
-
-   A zone defines the contents of a contiguous section of the domain
-   space, usually bounded by administrative boundaries.  There will
-   typically be a separate data file for each zone.  The data contained
-   in a zone file is composed of entries called Resource Records (RRs).
-
-
-
-
-Lottor                                                          [Page 1]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   You may only put data in your domain server that you are
-   authoritative for.  You must not add entries for domains other than
-   your own (except for the special case of "glue records").
-
-   A domain server will probably read a file on start-up that lists the
-   zones it should load into its database.  The format of this file is
-   not standardized and is different for most domain server
-   implementations.  For each zone it will normally contain the domain
-   name of the zone and the file name that contains the data to load for
-   the zone.
-
-ROOT SERVERS
-
-   A resolver will need to find the root servers when it first starts.
-   When the resolver boots, it will typically read a list of possible
-   root servers from a file.
-
-   The resolver will cycle through the list trying to contact each one.
-   When it finds a root server, it will ask it for the current list of
-   root servers.  It will then discard the list of root servers it read
-   from the data file and replace it with the current list it received.
-
-   Root servers will not change very often.  You can get the names of
-   current root servers from the NIC.
-
-   FTP the file NETINFO:ROOT-SERVERS.TXT or send a mail request to
-   NIC@SRI-NIC.ARPA.
-
-   As of this date (June 1987) they are:
-
-           SRI-NIC.ARPA       10.0.0.51    26.0.0.73
-           C.ISI.EDU          10.0.0.52
-           BRL-AOS.ARPA       192.5.25.82  192.5.22.82   128.20.1.2
-           A.ISI.EDU          26.3.0.103
-
-RESOURCE RECORDS
-
-   Records in the zone data files are called resource records (RRs).
-   They are specified in RFC-883 and RFC-973.  An RR has a standard
-   format as shown:
-
-           <name>   [<ttl>]   [<class>]   <type>   <data>
-
-   The record is divided into fields which are separated by white space.
-
-      <name>
-
-         The name field defines what domain name applies to the given
-
-
-
-Lottor                                                          [Page 2]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-         RR.  In some cases the name field can be left blank and it will
-         default to the name field of the previous RR.
-
-      <ttl>
-
-         TTL stands for Time To Live.  It specifies how long a domain
-         resolver should cache the RR before it throws it out and asks a
-         domain server again.  See the section on TTL's.  If you leave
-         the TTL field blank it will default to the minimum time
-         specified in the SOA record (described later).
-
-      <class>
-
-         The class field specifies the protocol group.  If left blank it
-         will default to the last class specified.
-
-      <type>
-
-         The type field specifies what type of data is in the RR.  See
-         the section on types.
-
-      <data>
-
-         The data field is defined differently for each type and class
-         of data.  Popular RR data formats are described later.
-
-   The domain system does not guarantee to preserve the order of
-   resource records.  Listing RRs (such as multiple address records) in
-   a certain order does not guarantee they will be used in that order.
-
-   Case is preserved in names and data fields when loaded into the name
-   server.  All comparisons and lookups in the name server are case
-   insensitive.
-
-   Parenthesis ("(",")") are used to group data that crosses a line
-   boundary.
-
-   A semicolon (";") starts a comment; the remainder of the line is
-   ignored.
-
-   The asterisk ("*") is used for wildcarding.
-
-   The at-sign ("@") denotes the current default domain name.
-
-
-
-
-
-
-
-
-Lottor                                                          [Page 3]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-NAMES
-
-   A domain name is a sequence of labels separated by dots.
-
-   Domain names in the zone files can be one of two types, either
-   absolute or relative.  An absolute name is the fully qualified domain
-   name and is terminated with a period.  A relative name does not
-   terminate with a period, and the current default domain is appended
-   to it.  The default domain is usually the name of the domain that was
-   specified in the boot file that loads each zone.
-
-   The domain system allows a label to contain any 8-bit character.
-   Although the domain system has no restrictions, other protocols such
-   as SMTP do have name restrictions.  Because of other protocol
-   restrictions, only the following characters are recommended for use
-   in a host name (besides the dot separator):
-
-           "A-Z", "a-z", "0-9", dash and underscore
-
-TTL's  (Time To Live)
-
-   It is important that TTLs are set to appropriate values.  The TTL is
-   the time (in seconds) that a resolver will use the data it got from
-   your server before it asks your server again.  If you set the value
-   too low, your server will get loaded down with lots of repeat
-   requests.  If you set it too high, then information you change will
-   not get distributed in a reasonable amount of time.  If you leave the
-   TTL field blank, it will default to what is specified in the SOA
-   record for the zone.
-
-   Most host information does not change much over long time periods.  A
-   good way to set up your TTLs would be to set them at a high value,
-   and then lower the value if you know a change will be coming soon.
-   You might set most TTLs to anywhere between a day (86400) and a week
-   (604800).  Then, if you know some data will be changing in the near
-   future, set the TTL for that RR down to a lower value (an hour to a
-   day) until the change takes place, and then put it back up to its
-   previous value.
-
-   Also, all RRs with the same name, class, and type should have the
-   same TTL value.
-
-CLASSES
-
-   The domain system was designed to be protocol independent.  The class
-   field is used to identify the protocol group that each RR is in.
-
-   The class of interest to people using TCP/IP software is the class
-
-
-
-Lottor                                                          [Page 4]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   "Internet".  Its standard designation is "IN".
-
-   A zone file should only contain RRs of the same class.
-
-TYPES
-
-   There are many defined RR types.  For a complete list, see the domain
-   specification RFCs.  Here is a list of current commonly used types.
-   The data for each type is described in the data section.
-
-                Designation                Description
-              ==========================================
-               SOA                 Start Of Authority
-               NS                  Name Server
-
-               A                   Internet Address
-               CNAME               Canonical Name (nickname pointer)
-               HINFO               Host Information
-               WKS                 Well Known Services
-
-               MX                  Mail Exchanger
-
-               PTR                 Pointer
-
-SOA  (Start Of Authority)
-
-           <name>  [<ttl>]  [<class>]  SOA  <origin>  <person>  (
-                           <serial>
-                           <refresh>
-                           <retry>
-                           <expire>
-                           <minimum> )
-
-   The Start Of Authority record designates the start of a zone.  The
-   zone ends at the next SOA record.
-
-   <name> is the name of the zone.
-
-   <origin> is the name of the host on which the master zone file
-   resides.
-
-   <person> is a mailbox for the person responsible for the zone.  It is
-   formatted like a mailing address but the at-sign that normally
-   separates the user from the host name is replaced with a dot.
-
-   <serial> is the version number of the zone file.  It should be
-   incremented anytime a change is made to data in the zone.
-
-
-
-
-Lottor                                                          [Page 5]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   <refresh> is how long, in seconds, a secondary name server is to
-   check with the primary name server to see if an update is needed.  A
-   good value here would be one hour (3600).
-
-   <retry> is how long, in seconds, a secondary name server is to retry
-   after a failure to check for a refresh.  A good value here would be
-   10 minutes (600).
-
-   <expire> is the upper limit, in seconds, that a secondary name server
-   is to use the data before it expires for lack of getting a refresh.
-   You want this to be rather large, and a nice value is 3600000, about
-   42 days.
-
-   <minimum> is the minimum number of seconds to be used for TTL values
-   in RRs.  A minimum of at least a day is a good value here (86400).
-
-   There should only be one SOA record per zone.  A sample SOA record
-   would look something like:
-
-           @   IN   SOA   SRI-NIC.ARPA.   HOSTMASTER.SRI-NIC.ARPA. (
-                           45         ;serial
-                           3600       ;refresh
-                           600        ;retry
-                           3600000    ;expire
-                           86400 )    ;minimum
-
-
-NS  (Name Server)
-
-           <domain>   [<ttl>] [<class>]   NS   <server>
-
-   The NS record lists the name of a machine that provides domain
-   service for a particular domain.  The name associated with the RR is
-   the domain name and the data portion is the name of a host that
-   provides the service.  If machines SRI-NIC.ARPA and C.ISI.EDU provide
-   name lookup service for the domain COM then the following entries
-   would be used:
-
-           COM.    NS      SRI-NIC.ARPA.
-                   NS      C.ISI.EDU.
-
-   Note that the machines providing name service do not have to live in
-   the named domain.  There should be one NS record for each server for
-   a domain.  Also note that the name "COM" defaults for the second NS
-   record.
-
-   NS records for a domain exist in both the zone that delegates the
-   domain, and in the domain itself.
-
-
-
-Lottor                                                          [Page 6]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-GLUE RECORDS
-
-   If the name server host for a particular domain is itself inside the
-   domain, then a 'glue' record will be needed.  A glue record is an A
-   (address) RR that specifies the address of the server.  Glue records
-   are only needed in the server delegating the domain, not in the
-   domain itself.  If for example the name server for domain SRI.COM was
-   KL.SRI.COM, then the NS record would look like this, but you will
-   also need to have the following A record.
-
-           SRI.COM.	NS	KL.SRI.COM.
-           KL.SRI.COM.  A	10.1.0.2
-
-
-A  (Address)
-
-           <host>   [<ttl>] [<class>]   A   <address>
-
-   The data for an A record is an internet address in dotted decimal
-   form.  A sample A record might look like:
-
-           SRI-NIC.ARPA.           A       10.0.0.51
-
-   There should be one A record for each address of a host.
-
-CNAME ( Canonical Name)
-
-           <nickname>   [<ttl>] [<class>]   CNAME   <host>
-
-   The CNAME record is used for nicknames.  The name associated with the
-   RR is the nickname.  The data portion is the official name.  For
-   example, a machine named SRI-NIC.ARPA may want to have the nickname
-   NIC.ARPA.  In that case, the following RR would be used:
-
-           NIC.ARPA.       CNAME   SRI-NIC.ARPA.
-
-   There must not be any other RRs associated with a nickname of the
-   same class.
-
-   Nicknames are also useful when a host changes it's name.  In that
-   case, it is usually a good idea to have a CNAME pointer so that
-   people still using the old name will get to the right place.
-
-
-
-
-
-
-
-
-
-Lottor                                                          [Page 7]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-HINFO (Host Info)
-
-           <host>   [<ttl>] [<class>]   HINFO   <hardware>   <software>
-
-   The HINFO record gives information about a particular host.  The data
-   is two strings separated by whitespace.  The first string is a
-   hardware description and the second is software.  The hardware is
-   usually a manufacturer name followed by a dash and model designation.
-   The software string is usually the name of the operating system.
-
-   Official HINFO types can be found in the latest Assigned Numbers RFC,
-   the latest of which is RFC-1010.  The Hardware type is called the
-   Machine name and the Software type is called the System name.
-
-   Some sample HINFO records:
-
-           SRI-NIC.ARPA.           HINFO   DEC-2060 TOPS20
-           UCBARPA.Berkeley.EDU.   HINFO   VAX-11/780 UNIX
-
-
-WKS (Well Known Services)
-
-           <host> [<ttl>] [<class>] WKS <address> <protocol> <services>
-
-   The WKS record is used to list Well Known Services a host provides.
-   WKS's are defined to be services on port numbers below 256.  The WKS
-   record lists what services are available at a certain address using a
-   certain protocol.  The common protocols are TCP or UDP.  A sample WKS
-   record for a host offering the same services on all address would
-   look like:
-
-   Official protocol names can be found in the latest Assigned Numbers
-   RFC, the latest of which is RFC-1010.
-
-           SRI-NIC.ARPA.   WKS  10.0.0.51  TCP  TELNET FTP SMTP
-                           WKS  10.0.0.51  UDP  TIME
-                           WKS  26.0.0.73  TCP  TELNET FTP SMTP
-                           WKS  26.0.0.73  UDP  TIME
-
-MX (Mail Exchanger)  (See RFC-974 for more details.)
-
-           <name>   [<ttl>] [<class>]   MX   <preference>   <host>
-
-   MX records specify where mail for a domain name should be delivered.
-   There may be multiple MX records for a particular name.  The
-   preference value specifies the order a mailer should try multiple MX
-   records when delivering mail.  Zero is the highest preference.
-   Multiple records for the same name may have the same preference.
-
-
-
-Lottor                                                          [Page 8]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   A host BAR.FOO.COM may want its mail to be delivered to the host
-   PO.FOO.COM and would then use the MX record:
-
-           BAR.FOO.COM.    MX      10      PO.FOO.COM.
-
-   A host BAZ.FOO.COM may want its mail to be delivered to one of three
-   different machines, in the following order:
-
-           BAZ.FOO.COM.    MX      10      PO1.FOO.COM.
-                           MX      20      PO2.FOO.COM.
-                           MX      30      PO3.FOO.COM.
-
-   An entire domain of hosts not connected to the Internet may want
-   their mail to go through a mail gateway that knows how to deliver
-   mail to them.  If they would like mail addressed to any host in the
-   domain FOO.COM to go through the mail gateway they might use:
-
-           FOO.COM.        MX       10     RELAY.CS.NET.
-           *.FOO.COM.      MX       20     RELAY.CS.NET.
-
-   Note that you can specify a wildcard in the MX record to match on
-   anything in FOO.COM, but that it won't match a plain FOO.COM.
-
-IN-ADDR.ARPA
-
-   The structure of names in the domain system is set up in a
-   hierarchical way such that the address of a name can be found by
-   tracing down the domain tree contacting a server for each label of
-   the name.  Because of this 'indexing' based on name, there is no easy
-   way to translate a host address back into its host name.
-
-   In order to do the reverse translation easily, a domain was created
-   that uses hosts' addresses as part of a name that then points to the
-   data for that host.  In this way, there is now an 'index' to hosts'
-   RRs based on their address.  This address mapping domain is called
-   IN-ADDR.ARPA.  Within that domain are subdomains for each network,
-   based on network number.  Also, for consistency and natural
-   groupings, the 4 octets of a host number are reversed.
-
-   For example, the ARPANET is net 10.  That means there is a domain
-   called 10.IN-ADDR.ARPA.  Within this domain there is a PTR RR at
-   51.0.0.10.IN-ADDR that points to the RRs for the host SRI-NIC.ARPA
-   (who's address is 10.0.0.51).  Since the NIC is also on the MILNET
-   (Net 26, address 26.0.0.73), there is also a PTR RR at 73.0.0.26.IN-
-   ADDR.ARPA that points to the same RR's for SRI-NIC.ARPA.  The format
-   of these special pointers is defined below along with the examples
-   for the NIC.
-
-
-
-
-Lottor                                                          [Page 9]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-PTR
-
-           <special-name>   [<ttl>] [<class>]   PTR   <name>
-
-   The PTR record is used to let special names point to some other
-   location in the domain tree.  They are mainly used in the IN-
-   ADDR.ARPA records for translation of addresses to names.  PTR's
-   should use official names and not aliases.
-
-   For example, host SRI-NIC.ARPA with addresses 10.0.0.51 and 26.0.0.73
-   would have the following records in the respective zone files for net
-   10 and net 26:
-
-           51.0.0.10.IN-ADDR.ARPA.  PTR   SRI-NIC.ARPA.
-           73.0.0.26.IN-ADDR.ARPA.  PTR   SRI-NIC.ARPA.
-
-GATEWAY PTR's
-
-   The IN-ADDR tree is also used to locate gateways on a particular
-   network.  Gateways have the same kind of PTR RRs as hosts (as above)
-   but in addition they have other PTRs used to locate them by network
-   number alone.  These records have only 1, 2, or 3 octets as part of
-   the name depending on whether they are class A, B, or C networks,
-   respectively.
-
-   Lets take the SRI-CSL gateway for example.  It connects 3 different
-   networks, one class A, one class B and one class C.  It will have the
-   standard RR's for a host in the CSL.SRI.COM zone:
-
-           GW.CSL.SRI.COM.    A    10.2.0.2
-                              A    128.18.1.1
-                              A    192.12.33.2
-
-   Also, in 3 different zones (one for each network), it will have one
-   of the following number to name translation pointers:
-
-           2.0.2.10.IN-ADDR.ARPA.      PTR   GW.CSL.SRI.COM.
-           1.1.18.128.IN-ADDR.ARPA.    PTR   GW.CSL.SRI.COM.
-           1.33.12.192.IN-ADDR.ARPA.   PTR   GW.CSL.SRI.COM.
-
-   In addition, in each of the same 3 zones will be one of the following
-   gateway location pointers:
-
-           10.IN-ADDR.ARPA.            PTR   GW.CSL.SRI.COM.
-           18.128.IN-ADDR.ARPA.        PTR   GW.CSL.SRI.COM.
-           33.12.192.IN-ADDR.ARPA.     PTR   GW.CSL.SRI.COM.
-
-
-
-
-
-Lottor                                                         [Page 10]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-INSTRUCTIONS
-
-   Adding a subdomain.
-
-      To add a new subdomain to your domain:
-
-         Setup the other domain server and/or the new zone file.
-
-         Add an NS record for each server of the new domain to the zone
-         file of the parent domain.
-
-         Add any necessary glue RRs.
-
-   Adding a host.
-
-      To add a new host to your zone files:
-
-         Edit the appropriate zone file for the domain the host is in.
-
-         Add an entry for each address of the host.
-
-         Optionally add CNAME, HINFO, WKS, and MX records.
-
-         Add the reverse IN-ADDR entry for each host address in the
-         appropriate zone files for each network the host in on.
-
-   Deleting a host.
-
-      To delete a host from the zone files:
-
-         Remove all the hosts' resource records from the zone file of
-         the domain the host is in.
-
-         Remove all the hosts' PTR records from the IN-ADDR zone files
-         for each network the host was on.
-
-   Adding gateways.
-
-         Follow instructions for adding a host.
-
-         Add the gateway location PTR records for each network the
-         gateway is on.
-
-   Deleting gateways.
-
-         Follow instructions for deleting a host.
-
-         Also delete the gateway location PTR records for each network
-
-
-
-Lottor                                                         [Page 11]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-         the gateway was on.
-
-COMPLAINTS
-
-   These are the suggested steps you should take if you are having
-   problems that you believe are caused by someone else's name server:
-
-
-   1.  Complain privately to the responsible person for the domain.  You
-   can find their mailing address in the SOA record for the domain.
-
-   2.  Complain publicly to the responsible person for the domain.
-
-   3.  Ask the NIC for the administrative person responsible for the
-   domain.  Complain.  You can also find domain contacts on the NIC in
-   the file NETINFO:DOMAIN-CONTACTS.TXT
-
-   4.  Complain to the parent domain authorities.
-
-   5.  Ask the parent authorities to excommunicate the domain.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 12]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-EXAMPLE DOMAIN SERVER DATABASE FILES
-
-   The following examples show how zone files are set up for a typical
-   organization.  SRI will be used as the example organization.  SRI has
-   decided to divided their domain SRI.COM into a few subdomains, one
-   for each group that wants one.  The subdomains are CSL and ISTC.
-
-   Note the following interesting items:
-
-      There are both hosts and domains under SRI.COM.
-
-      CSL.SRI.COM is both a domain name and a host name.
-
-      All the domains are serviced by the same pair of domain servers.
-
-      All hosts at SRI are on net 128.18 except hosts in the CSL domain
-      which are on net 192.12.33.  Note that a domain does not have to
-      correspond to a physical network.
-
-      The examples do not necessarily correspond to actual data in use
-      by the SRI domain.
-
-                       SRI Domain Organization
-
-                               +-------+
-                               |  COM  |
-                               +-------+
-                                   |
-                               +-------+
-                               |  SRI  |
-                               +-------+
-                                   |
-                        +----------++-----------+
-                        |           |           |
-                    +-------+    +------+   +-------+
-                    |  CSL  |    | ISTC |   | Hosts |
-                    +-------+    +------+   +-------+
-                        |           |
-                    +-------+    +-------+
-                    | Hosts |    | Hosts |
-                    +-------+    +-------+
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 13]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   [File "CONFIG.CMD".  Since bootstrap files are not standardized, this
-   file is presented using a pseudo configuration file syntax.]
-
-   load root server list             from file ROOT.SERVERS
-   load zone SRI.COM.                from file SRI.ZONE
-   load zone CSL.SRI.COM.            from file CSL.ZONE
-   load zone ISTC.SRI.COM.           from file ISTC.ZONE
-   load zone 18.128.IN-ADDR.ARPA.    from file SRINET.ZONE
-   load zone 33.12.192.IN-ADDR.ARPA. from file SRI-CSL-NET.ZONE
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 14]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   [File "ROOT.SERVERS".  Again, the format of this file is not
-   standardized.]
-
-   ;list of possible root servers
-   SRI-NIC.ARPA       10.0.0.51    26.0.0.73
-   C.ISI.EDU          10.0.0.52
-   BRL-AOS.ARPA       192.5.25.82  192.5.22.82   128.20.1.2
-   A.ISI.EDU          26.3.0.103
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 15]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   [File "SRI.ZONE"]
-
-   SRI.COM.        IN      SOA     KL.SRI.COM. DLE.STRIPE.SRI.COM. (
-                                   870407  ;serial
-                                   1800    ;refresh every 30 minutes
-                                   600     ;retry every 10 minutes
-                                   604800  ;expire after a week
-                                   86400   ;default of an hour
-                                   )
-
-   SRI.COM.        NS      KL.SRI.COM.
-                   NS      STRIPE.SRI.COM.
-                   MX      10      KL.SRI.COM.
-
-   ;SRI.COM hosts
-
-   KL              A       10.1.0.2
-                   A       128.18.10.6
-                   MX      10      KL.SRI.COM.
-
-   STRIPE          A       10.4.0.2
-   STRIPE          A       128.18.10.4
-                   MX      10      STRIPE.SRI.COM.
-
-   NIC             CNAME   SRI-NIC.ARPA.
-
-   Blackjack       A       128.18.2.1
-                   HINFO   VAX-11/780      UNIX
-                   WKS     128.18.2.1      TCP TELNET FTP
-
-   CSL             A       192.12.33.2
-                   HINFO   FOONLY-F4       TOPS20
-                   WKS     192.12.33.2     TCP TELNET FTP SMTP FINGER
-                   MX      10      CSL.SRI.COM.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 16]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   [File "CSL.ZONE"]
-
-   CSL.SRI.COM.    IN      SOA     KL.SRI.COM. DLE.STRIPE.SRI.COM. (
-                                   870330  ;serial
-                                   1800    ;refresh every 30 minutes
-                                   600     ;retry every 10 minutes
-                                   604800  ;expire after a week
-                                   86400   ;default of a day
-                                   )
-
-   CSL.SRI.COM.    NS              KL.SRI.COM.
-                   NS              STRIPE.SRI.COM.
-                   A               192.12.33.2
-
-   ;CSL.SRI.COM hosts
-
-   A               CNAME   CSL.SRI.COM.
-   B               A       192.12.33.3
-                   HINFO   FOONLY-F4       TOPS20
-                   WKS     192.12.33.3     TCP TELNET FTP SMTP
-   GW              A       10.2.0.2
-                   A       192.12.33.1
-                   A       128.18.1.1
-                   HINFO   PDP-11/23       MOS
-   SMELLY          A       192.12.33.4
-                   HINFO   IMAGEN          IMAGEN
-   SQUIRREL        A       192.12.33.5
-                   HINFO   XEROX-1100      INTERLISP
-   VENUS           A       192.12.33.7
-                   HINFO   SYMBOLICS-3600  LISPM
-   HELIUM          A       192.12.33.30
-                   HINFO   SUN-3/160       UNIX
-   ARGON           A       192.12.33.31
-                   HINFO   SUN-3/75        UNIX
-   RADON           A       192.12.33.32
-                   HINFO   SUN-3/75        UNIX
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 17]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   [File "ISTC.ZONE"]
-
-   ISTC.SRI.COM.   IN  SOA     KL.SRI.COM. roemers.JOYCE.ISTC.SRI.COM. (
-                               870406      ;serial
-                               1800        ;refresh every 30 minutes
-                               600         ;retry every 10 minutes
-                               604800      ;expire after a week
-                               86400       ;default of a day
-                               )
-
-   ISTC.SRI.COM.   NS              KL.SRI.COM.
-                   NS              STRIPE.SRI.COM.
-                   MX              10      SPAM.ISTC.SRI.COM.
-
-   ; ISTC hosts
-
-   joyce           A       128.18.4.2
-                   HINFO   VAX-11/750 UNIX
-   bozo            A       128.18.0.6
-                   HINFO   SUN UNIX
-   sundae          A       128.18.0.11
-                   HINFO   SUN UNIX
-   tsca            A       128.18.0.201
-                   A       10.3.0.2
-                   HINFO   VAX-11/750 UNIX
-                   MX      10  TSCA.ISTC.SRI.COM.
-   tsc             CNAME   tsca
-   prmh            A       128.18.0.203
-                   A       10.2.0.51
-                   HINFO   PDP-11/44 UNIX
-   spam            A       128.18.4.3
-                   A       10.2.0.107
-                   HINFO   VAX-11/780 UNIX
-                   MX      10  SPAM.ISTC.SRI.COM.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 18]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   [File "SRINET.ZONE"]
-
-   18.128.IN-ADDR.ARPA.    IN  SOA  KL.SRI.COM  DLE.STRIPE.SRI.COM. (
-                               870406  ;serial
-                               1800    ;refresh every 30 minutes
-                               600     ;retry every 10 minutes
-                               604800  ;expire after a week
-                               86400   ;default of a day
-                               )
-
-   18.128.IN-ADDR.ARPA.    NS      KL.SRI.COM.
-                           NS      STRIPE.SRI.COM.
-                           PTR     GW.CSL.SRI.COM.
-
-   ; SRINET [128.18.0.0] Address Translations
-
-   ; SRI.COM Hosts
-   1.2.18.128.IN-ADDR.ARPA.        PTR     Blackjack.SRI.COM.
-
-   ; ISTC.SRI.COM Hosts
-   2.4.18.128.IN-ADDR.ARPA.        PTR     joyce.ISTC.SRI.COM.
-   6.0.18.128.IN-ADDR.ARPA.        PTR     bozo.ISTC.SRI.COM.
-   11.0.18.128.IN-ADDR.ARPA.       PTR     sundae.ISTC.SRI.COM.
-   201.0.18.128.IN-ADDR.ARPA.      PTR     tsca.ISTC.SRI.COM.
-   203.0.18.128.IN-ADDR.ARPA.      PTR     prmh.ISTC.SRI.COM.
-   3.4.18.128.IN-ADDR.ARPA.        PTR     spam.ISTC.SRI.COM.
-
-   ; CSL.SRI.COM Hosts
-   1.1.18.128.IN-ADDR.ARPA.        PTR     GW.CSL.SRI.COM.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 19]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-   [File "SRI-CSL-NET.ZONE"]
-
-   33.12.192.IN-ADDR.ARPA. IN  SOA KL.SRI.COM  DLE.STRIPE.SRI.COM. (
-                               870404  ;serial
-                               1800    ;refresh every 30 minutes
-                               600     ;retry every 10 minutes
-                               604800  ;expire after a week
-                               86400   ;default of a day
-                               )
-
-   33.12.192.IN-ADDR.ARPA. NS      KL.SRI.COM.
-                           NS      STRIPE.SRI.COM.
-                           PTR     GW.CSL.SRI.COM.
-
-   ; SRI-CSL-NET [192.12.33.0] Address Translations
-
-   ; SRI.COM Hosts
-   2.33.12.192.IN-ADDR.ARPA.       PTR     CSL.SRI.COM.
-
-   ; CSL.SRI.COM Hosts
-   1.33.12.192.IN-ADDR.ARPA.       PTR     GW.CSL.SRI.COM.
-   3.33.12.192.IN-ADDR.ARPA.       PTR     B.CSL.SRI.COM.
-   4.33.12.192.IN-ADDR.ARPA.       PTR     SMELLY.CSL.SRI.COM.
-   5.33.12.192.IN-ADDR.ARPA.       PTR     SQUIRREL.CSL.SRI.COM.
-   7.33.12.192.IN-ADDR.ARPA.       PTR     VENUS.CSL.SRI.COM.
-   30.33.12.192.IN-ADDR.ARPA.      PTR     HELIUM.CSL.SRI.COM.
-   31.33.12.192.IN-ADDR.ARPA.      PTR     ARGON.CSL.SRI.COM.
-   32.33.12.192.IN-ADDR.ARPA.      PTR     RADON.CSL.SRI.COM.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 20]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-APPENDIX
-
-   BIND (Berkeley Internet Name Domain server) distributed with 4.3 BSD
-   UNIX
-
-   This section describes two BIND implementation specific files; the
-   boot file and the cache file.  BIND has other options, files, and
-   specifications that are not described here.  See the Name Server
-   Operations Guide for BIND for details.
-
-   The boot file for BIND is usually called "named.boot".  This
-   corresponds to file "CONFIG.CMD" in the example section.
-
-           --------------------------------------------------------
-           cache         .                         named.ca
-           primary       SRI.COM                   SRI.ZONE
-           primary       CSL.SRI.COM               CSL.ZONE
-           primary       ISTC.SRI.COM              ISTC.ZONE
-           primary       18.128.IN-ADDR.ARPA       SRINET.ZONE
-           primary       33.12.192.IN-ADDR.ARPA    SRI-CSL-NET.ZONE
-           --------------------------------------------------------
-
-   The cache file for BIND is usually called "named.ca".  This
-   corresponds to file "ROOT.SERVERS" in the example section.
-
-           -------------------------------------------------
-           ;list of possible root servers
-           .       1          IN   NS   SRI-NIC.ARPA.
-                                   NS   C.ISI.EDU.
-                                   NS   BRL-AOS.ARPA.
-                                   NS   C.ISI.EDU.
-           ;and their addresses
-           SRI-NIC.ARPA.           A    10.0.0.51
-                                   A    26.0.0.73
-           C.ISI.EDU.              A    10.0.0.52
-           BRL-AOS.ARPA.           A    192.5.25.82
-                                   A    192.5.22.82
-                                   A    128.20.1.2
-           A.ISI.EDU.              A    26.3.0.103
-           -------------------------------------------------
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 21]
-
-RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
-
-
-REFERENCES
-
-   [1]  Dunlap, K., "Name Server Operations Guide for BIND", CSRG,
-        Department of Electrical Engineering and Computer Sciences,
-        University of California, Berkeley, California.
-
-   [2]  Partridge, C., "Mail Routing and the Domain System", RFC-974,
-        CSNET CIC BBN Laboratories, January 1986.
-
-   [3]  Mockapetris, P., "Domains Names - Concepts and Facilities",
-        RFC-1034, USC/Information Sciences Institute, November 1987.
-
-   [4]  Mockapetris, P., "Domain Names - Implementations Specification",
-        RFC-1035, USC/Information Sciences Institute, November 1987.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lottor                                                         [Page 22]
-
diff --git a/contrib/bind9/doc/rfc/rfc1034.txt b/contrib/bind9/doc/rfc/rfc1034.txt
deleted file mode 100644
index 55cdb21..0000000
--- a/contrib/bind9/doc/rfc/rfc1034.txt
+++ /dev/null
@@ -1,3077 +0,0 @@
-Network Working Group                                     P. Mockapetris
-Request for Comments: 1034                                           ISI
-Obsoletes: RFCs 882, 883, 973                              November 1987
-
-
-                 DOMAIN NAMES - CONCEPTS AND FACILITIES
-
-
-
-1. STATUS OF THIS MEMO
-
-This RFC is an introduction to the Domain Name System (DNS), and omits
-many details which can be found in a companion RFC, "Domain Names -
-Implementation and Specification" [RFC-1035].  That RFC assumes that the
-reader is familiar with the concepts discussed in this memo.
-
-A subset of DNS functions and data types constitute an official
-protocol.  The official protocol includes standard queries and their
-responses and most of the Internet class data formats (e.g., host
-addresses).
-
-However, the domain system is intentionally extensible.  Researchers are
-continuously proposing, implementing and experimenting with new data
-types, query types, classes, functions, etc.  Thus while the components
-of the official protocol are expected to stay essentially unchanged and
-operate as a production service, experimental behavior should always be
-expected in extensions beyond the official protocol.  Experimental or
-obsolete features are clearly marked in these RFCs, and such information
-should be used with caution.
-
-The reader is especially cautioned not to depend on the values which
-appear in examples to be current or complete, since their purpose is
-primarily pedagogical.  Distribution of this memo is unlimited.
-
-2. INTRODUCTION
-
-This RFC introduces domain style names, their use for Internet mail and
-host address support, and the protocols and servers used to implement
-domain name facilities.
-
-2.1. The history of domain names
-
-The impetus for the development of the domain system was growth in the
-Internet:
-
-   - Host name to address mappings were maintained by the Network
-     Information Center (NIC) in a single file (HOSTS.TXT) which
-     was FTPed by all hosts [RFC-952, RFC-953].  The total network
-
-
-
-Mockapetris                                                     [Page 1]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-     bandwidth consumed in distributing a new version by this
-     scheme is proportional to the square of the number of hosts in
-     the network, and even when multiple levels of FTP are used,
-     the outgoing FTP load on the NIC host is considerable.
-     Explosive growth in the number of hosts didn't bode well for
-     the future.
-
-   - The network population was also changing in character.  The
-     timeshared hosts that made up the original ARPANET were being
-     replaced with local networks of workstations.  Local
-     organizations were administering their own names and
-     addresses, but had to wait for the NIC to change HOSTS.TXT to
-     make changes visible to the Internet at large.  Organizations
-     also wanted some local structure on the name space.
-
-   - The applications on the Internet were getting more
-     sophisticated and creating a need for general purpose name
-     service.
-
-
-The result was several ideas about name spaces and their management
-[IEN-116, RFC-799, RFC-819, RFC-830].  The proposals varied, but a
-common thread was the idea of a hierarchical name space, with the
-hierarchy roughly corresponding to organizational structure, and names
-using "."  as the character to mark the boundary between hierarchy
-levels.  A design using a distributed database and generalized resources
-was described in [RFC-882, RFC-883].  Based on experience with several
-implementations, the system evolved into the scheme described in this
-memo.
-
-The terms "domain" or "domain name" are used in many contexts beyond the
-DNS described here.  Very often, the term domain name is used to refer
-to a name with structure indicated by dots, but no relation to the DNS.
-This is particularly true in mail addressing [Quarterman 86].
-
-2.2. DNS design goals
-
-The design goals of the DNS influence its structure.  They are:
-
-   - The primary goal is a consistent name space which will be used
-     for referring to resources.  In order to avoid the problems
-     caused by ad hoc encodings, names should not be required to
-     contain network identifiers, addresses, routes, or similar
-     information as part of the name.
-
-   - The sheer size of the database and frequency of updates
-     suggest that it must be maintained in a distributed manner,
-     with local caching to improve performance.  Approaches that
-
-
-
-Mockapetris                                                     [Page 2]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-     attempt to collect a consistent copy of the entire database
-     will become more and more expensive and difficult, and hence
-     should be avoided.  The same principle holds for the structure
-     of the name space, and in particular mechanisms for creating
-     and deleting names; these should also be distributed.
-
-   - Where there tradeoffs between the cost of acquiring data, the
-     speed of updates, and the accuracy of caches, the source of
-     the data should control the tradeoff.
-
-   - The costs of implementing such a facility dictate that it be
-     generally useful, and not restricted to a single application.
-     We should be able to use names to retrieve host addresses,
-     mailbox data, and other as yet undetermined information.  All
-     data associated with a name is tagged with a type, and queries
-     can be limited to a single type.
-
-   - Because we want the name space to be useful in dissimilar
-     networks and applications, we provide the ability to use the
-     same name space with different protocol families or
-     management.  For example, host address formats differ between
-     protocols, though all protocols have the notion of address.
-     The DNS tags all data with a class as well as the type, so
-     that we can allow parallel use of different formats for data
-     of type address.
-
-   - We want name server transactions to be independent of the
-     communications system that carries them.  Some systems may
-     wish to use datagrams for queries and responses, and only
-     establish virtual circuits for transactions that need the
-     reliability (e.g., database updates, long transactions); other
-     systems will use virtual circuits exclusively.
-
-   - The system should be useful across a wide spectrum of host
-     capabilities.  Both personal computers and large timeshared
-     hosts should be able to use the system, though perhaps in
-     different ways.
-
-2.3. Assumptions about usage
-
-The organization of the domain system derives from some assumptions
-about the needs and usage patterns of its user community and is designed
-to avoid many of the the complicated problems found in general purpose
-database systems.
-
-The assumptions are:
-
-   - The size of the total database will initially be proportional
-
-
-
-Mockapetris                                                     [Page 3]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-     to the number of hosts using the system, but will eventually
-     grow to be proportional to the number of users on those hosts
-     as mailboxes and other information are added to the domain
-     system.
-
-   - Most of the data in the system will change very slowly (e.g.,
-     mailbox bindings, host addresses), but that the system should
-     be able to deal with subsets that change more rapidly (on the
-     order of seconds or minutes).
-
-   - The administrative boundaries used to distribute
-     responsibility for the database will usually correspond to
-     organizations that have one or more hosts.  Each organization
-     that has responsibility for a particular set of domains will
-     provide redundant name servers, either on the organization's
-     own hosts or other hosts that the organization arranges to
-     use.
-
-   - Clients of the domain system should be able to identify
-     trusted name servers they prefer to use before accepting
-     referrals to name servers outside of this "trusted" set.
-
-   - Access to information is more critical than instantaneous
-     updates or guarantees of consistency.  Hence the update
-     process allows updates to percolate out through the users of
-     the domain system rather than guaranteeing that all copies are
-     simultaneously updated.  When updates are unavailable due to
-     network or host failure, the usual course is to believe old
-     information while continuing efforts to update it.  The
-     general model is that copies are distributed with timeouts for
-     refreshing.  The distributor sets the timeout value and the
-     recipient of the distribution is responsible for performing
-     the refresh.  In special situations, very short intervals can
-     be specified, or the owner can prohibit copies.
-
-   - In any system that has a distributed database, a particular
-     name server may be presented with a query that can only be
-     answered by some other server.  The two general approaches to
-     dealing with this problem are "recursive", in which the first
-     server pursues the query for the client at another server, and
-     "iterative", in which the server refers the client to another
-     server and lets the client pursue the query.  Both approaches
-     have advantages and disadvantages, but the iterative approach
-     is preferred for the datagram style of access.  The domain
-     system requires implementation of the iterative approach, but
-     allows the recursive approach as an option.
-
-
-
-
-
-Mockapetris                                                     [Page 4]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-The domain system assumes that all data originates in master files
-scattered through the hosts that use the domain system.  These master
-files are updated by local system administrators.  Master files are text
-files that are read by a local name server, and hence become available
-through the name servers to users of the domain system.  The user
-programs access name servers through standard programs called resolvers.
-
-The standard format of master files allows them to be exchanged between
-hosts (via FTP, mail, or some other mechanism); this facility is useful
-when an organization wants a domain, but doesn't want to support a name
-server.  The organization can maintain the master files locally using a
-text editor, transfer them to a foreign host which runs a name server,
-and then arrange with the system administrator of the name server to get
-the files loaded.
-
-Each host's name servers and resolvers are configured by a local system
-administrator [RFC-1033].  For a name server, this configuration data
-includes the identity of local master files and instructions on which
-non-local master files are to be loaded from foreign servers.  The name
-server uses the master files or copies to load its zones.  For
-resolvers, the configuration data identifies the name servers which
-should be the primary sources of information.
-
-The domain system defines procedures for accessing the data and for
-referrals to other name servers.  The domain system also defines
-procedures for caching retrieved data and for periodic refreshing of
-data defined by the system administrator.
-
-The system administrators provide:
-
-   - The definition of zone boundaries.
-
-   - Master files of data.
-
-   - Updates to master files.
-
-   - Statements of the refresh policies desired.
-
-The domain system provides:
-
-   - Standard formats for resource data.
-
-   - Standard methods for querying the database.
-
-   - Standard methods for name servers to refresh local data from
-     foreign name servers.
-
-
-
-
-
-Mockapetris                                                     [Page 5]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-2.4. Elements of the DNS
-
-The DNS has three major components:
-
-   - The DOMAIN NAME SPACE and RESOURCE RECORDS, which are
-     specifications for a tree structured name space and data
-     associated with the names.  Conceptually, each node and leaf
-     of the domain name space tree names a set of information, and
-     query operations are attempts to extract specific types of
-     information from a particular set.  A query names the domain
-     name of interest and describes the type of resource
-     information that is desired.  For example, the Internet
-     uses some of its domain names to identify hosts; queries for
-     address resources return Internet host addresses.
-
-   - NAME SERVERS are server programs which hold information about
-     the domain tree's structure and set information.  A name
-     server may cache structure or set information about any part
-     of the domain tree, but in general a particular name server
-     has complete information about a subset of the domain space,
-     and pointers to other name servers that can be used to lead to
-     information from any part of the domain tree.  Name servers
-     know the parts of the domain tree for which they have complete
-     information; a name server is said to be an AUTHORITY for
-     these parts of the name space.  Authoritative information is
-     organized into units called ZONEs, and these zones can be
-     automatically distributed to the name servers which provide
-     redundant service for the data in a zone.
-
-   - RESOLVERS are programs that extract information from name
-     servers in response to client requests.  Resolvers must be
-     able to access at least one name server and use that name
-     server's information to answer a query directly, or pursue the
-     query using referrals to other name servers.  A resolver will
-     typically be a system routine that is directly accessible to
-     user programs; hence no protocol is necessary between the
-     resolver and the user program.
-
-These three components roughly correspond to the three layers or views
-of the domain system:
-
-   - From the user's point of view, the domain system is accessed
-     through a simple procedure or OS call to a local resolver.
-     The domain space consists of a single tree and the user can
-     request information from any section of the tree.
-
-   - From the resolver's point of view, the domain system is
-     composed of an unknown number of name servers.  Each name
-
-
-
-Mockapetris                                                     [Page 6]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-     server has one or more pieces of the whole domain tree's data,
-     but the resolver views each of these databases as essentially
-     static.
-
-   - From a name server's point of view, the domain system consists
-     of separate sets of local information called zones.  The name
-     server has local copies of some of the zones.  The name server
-     must periodically refresh its zones from master copies in
-     local files or foreign name servers.  The name server must
-     concurrently process queries that arrive from resolvers.
-
-In the interests of performance, implementations may couple these
-functions.  For example, a resolver on the same machine as a name server
-might share a database consisting of the the zones managed by the name
-server and the cache managed by the resolver.
-
-3. DOMAIN NAME SPACE and RESOURCE RECORDS
-
-3.1. Name space specifications and terminology
-
-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.
-
-Each node has a label, which is zero to 63 octets in length.  Brother
-nodes may not have the same label, although the same label can be used
-for nodes which are not brothers.  One label is reserved, and that is
-the null (i.e., zero length) label used for the root.
-
-The domain name of a node is the list of the labels on the path from the
-node to the root of the tree.  By convention, the labels that compose a
-domain name are printed or read left to right, from the most specific
-(lowest, farthest from the root) to the least specific (highest, closest
-to the root).
-
-Internally, programs that manipulate domain names should represent them
-as sequences of labels, where each label is a length octet followed by
-an octet string.  Because all domain names end at the root, which has a
-null string for a label, these internal representations can use a length
-byte of zero to terminate a domain name.
-
-By convention, domain names can be stored with arbitrary case, but
-domain name comparisons for all present domain functions are done in a
-case-insensitive manner, assuming an ASCII character set, and a high
-order zero bit.  This means that you are free to create a node with
-label "A" or a node with label "a", but not both as brothers; you could
-refer to either using "a" or "A".  When you receive a domain name or
-
-
-
-Mockapetris                                                     [Page 7]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-label, you should preserve its case.  The rationale for this choice is
-that we may someday need to add full binary domain names for new
-services; existing services would not be changed.
-
-When a user needs to type a domain name, the length of each label is
-omitted and the labels are separated by dots (".").  Since a complete
-domain name ends with the root label, this leads to a printed form which
-ends in a dot.  We use this property to distinguish between:
-
-   - a character string which represents a complete domain name
-     (often called "absolute").  For example, "poneria.ISI.EDU."
-
-   - a character string that represents the starting labels of a
-     domain name which is incomplete, and should be completed by
-     local software using knowledge of the local domain (often
-     called "relative").  For example, "poneria" used in the
-     ISI.EDU domain.
-
-Relative names are either taken relative to a well known origin, or to a
-list of domains used as a search list.  Relative names appear mostly at
-the user interface, where their interpretation varies from
-implementation to implementation, and in master files, where they are
-relative to a single origin domain name.  The most common interpretation
-uses the root "." as either the single origin or as one of the members
-of the search list, so a multi-label relative name is often one where
-the trailing dot has been omitted to save typing.
-
-To simplify implementations, the total number of octets that represent a
-domain name (i.e., the sum of all label octets and label lengths) is
-limited to 255.
-
-A domain is identified by a domain name, and consists of that part of
-the domain name space that is at or below the domain name which
-specifies the domain.  A domain is a subdomain of another domain if it
-is contained within that domain.  This relationship can be tested by
-seeing if the subdomain's name ends with the containing domain's name.
-For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ".
-
-3.2. Administrative guidelines on use
-
-As a matter of policy, the DNS technical specifications do not mandate a
-particular tree structure or rules for selecting labels; its goal is to
-be as general as possible, so that it can be used to build arbitrary
-applications.  In particular, the system was designed so that the name
-space did not have to be organized along the lines of network
-boundaries, name servers, etc.  The rationale for this is not that the
-name space should have no implied semantics, but rather that the choice
-of implied semantics should be left open to be used for the problem at
-
-
-
-Mockapetris                                                     [Page 8]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-hand, and that different parts of the tree can have different implied
-semantics.  For example, the IN-ADDR.ARPA domain is organized and
-distributed by network and host address because its role is to translate
-from network or host numbers to names; NetBIOS domains [RFC-1001, RFC-
-1002] are flat because that is appropriate for that application.
-
-However, there are some guidelines that apply to the "normal" parts of
-the name space used for hosts, mailboxes, etc., that will make the name
-space more uniform, provide for growth, and minimize problems as
-software is converted from the older host table.  The political
-decisions about the top levels of the tree originated in RFC-920.
-Current policy for the top levels is discussed in [RFC-1032].  MILNET
-conversion issues are covered in [RFC-1031].
-
-Lower domains which will eventually be broken into multiple zones should
-provide branching at the top of the domain so that the eventual
-decomposition can be done without renaming.  Node labels which use
-special characters, leading digits, etc., are likely to break older
-software which depends on more restrictive choices.
-
-3.3. Technical guidelines on use
-
-Before the DNS can be used to hold naming information for some kind of
-object, two needs must be met:
-
-   - A convention for mapping between object names and domain
-     names.  This describes how information about an object is
-     accessed.
-
-   - RR types and data formats for describing the object.
-
-These rules can be quite simple or fairly complex.  Very often, the
-designer must take into account existing formats and plan for upward
-compatibility for existing usage.  Multiple mappings or levels of
-mapping may be required.
-
-For hosts, the mapping depends on the existing syntax for host names
-which is a subset of the usual text representation for domain names,
-together with RR formats for describing host addresses, etc.  Because we
-need a reliable inverse mapping from address to host name, a special
-mapping for addresses into the IN-ADDR.ARPA domain is also defined.
-
-For mailboxes, the mapping is slightly more complex.  The usual mail
-address <local-part>@<mail-domain> is mapped into a domain name by
-converting <local-part> into a single label (regardles of dots it
-contains), converting <mail-domain> into a domain name using the usual
-text format for domain names (dots denote label breaks), and
-concatenating the two to form a single domain name.  Thus the mailbox
-
-
-
-Mockapetris                                                     [Page 9]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-HOSTMASTER@SRI-NIC.ARPA is represented as a domain name by
-HOSTMASTER.SRI-NIC.ARPA.  An appreciation for the reasons behind this
-design also must take into account the scheme for mail exchanges [RFC-
-974].
-
-The typical user is not concerned with defining these rules, but should
-understand that they usually are the result of numerous compromises
-between desires for upward compatibility with old usage, interactions
-between different object definitions, and the inevitable urge to add new
-features when defining the rules.  The way the DNS is used to support
-some object is often more crucial than the restrictions inherent in the
-DNS.
-
-3.4. Example name space
-
-The following figure shows a part of the current domain name space, and
-is used in many examples in this RFC.  Note that the tree is a very
-small subset of the actual name space.
-
-                                   |
-                                   |
-             +---------------------+------------------+
-             |                     |                  |
-            MIL                   EDU                ARPA
-             |                     |                  |
-             |                     |                  |
-       +-----+-----+               |     +------+-----+-----+
-       |     |     |               |     |      |           |
-      BRL  NOSC  DARPA             |  IN-ADDR  SRI-NIC     ACC
-                                   |
-       +--------+------------------+---------------+--------+
-       |        |                  |               |        |
-      UCI      MIT                 |              UDEL     YALE
-                |                 ISI
-                |                  |
-            +---+---+              |
-            |       |              |
-           LCS  ACHILLES  +--+-----+-----+--------+
-            |             |  |     |     |        |
-            XX            A  C   VAXA  VENERA Mockapetris
-
-In this example, the root domain has three immediate subdomains: MIL,
-EDU, and ARPA.  The LCS.MIT.EDU domain has one immediate subdomain named
-XX.LCS.MIT.EDU.  All of the leaves are also domains.
-
-3.5. Preferred name syntax
-
-The DNS specifications attempt to be as general as possible in the rules
-
-
-
-Mockapetris                                                    [Page 10]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-for constructing domain names.  The idea is that the name of any
-existing object can be expressed as a domain name with minimal changes.
-However, when assigning a domain name for an object, the prudent user
-will select a name which satisfies both the rules of the domain system
-and any existing rules for the object, whether these rules are published
-or implied by existing programs.
-
-For example, when naming a mail domain, the user should satisfy both the
-rules of this memo and those in RFC-822.  When creating a new host name,
-the old rules for HOSTS.TXT should be followed.  This avoids problems
-when old software is converted to use domain names.
-
-The following syntax will result in fewer problems with many
-applications that use domain names (e.g., mail, TELNET).
-
-<domain> ::= <subdomain> | " "
-
-<subdomain> ::= <label> | <subdomain> "." <label>
-
-<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
-
-<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
-
-<let-dig-hyp> ::= <let-dig> | "-"
-
-<let-dig> ::= <letter> | <digit>
-
-<letter> ::= any one of the 52 alphabetic characters A through Z in
-upper case and a through z in lower case
-
-<digit> ::= any one of the ten digits 0 through 9
-
-Note that while upper and lower case letters are allowed in domain
-names, no significance is attached to the case.  That is, two names with
-the same spelling but different case are to be treated as if identical.
-
-The labels must follow the rules for ARPANET host names.  They must
-start with a letter, end with a letter or digit, and have as interior
-characters only letters, digits, and hyphen.  There are also some
-restrictions on the length.  Labels must be 63 characters or less.
-
-For example, the following strings identify hosts in the Internet:
-
-A.ISI.EDU  XX.LCS.MIT.EDU  SRI-NIC.ARPA
-
-3.6. Resource Records
-
-A domain name identifies a node.  Each node has a set of resource
-
-
-
-Mockapetris                                                    [Page 11]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-information, which may be empty.  The set of resource information
-associated with a particular name is composed of separate resource
-records (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.
-
-When we talk about a specific RR, we assume it has the following:
-
-owner           which is the domain name where the RR is found.
-
-type            which is an encoded 16 bit value that specifies the type
-                of the resource in this resource record.  Types refer to
-                abstract resources.
-
-                This memo uses the following types:
-
-                A               a host address
-
-                CNAME           identifies the canonical name of an
-                                alias
-
-                HINFO           identifies the CPU and OS used by a host
-
-                MX              identifies a mail exchange for the
-                                domain.  See [RFC-974 for details.
-
-                NS
-                the authoritative name server for the domain
-
-                PTR
-                a pointer to another part of the domain name space
-
-                SOA
-                identifies the start of a zone of authority]
-
-class           which is an encoded 16 bit value which identifies a
-                protocol family or instance of a protocol.
-
-                This memo uses the following classes:
-
-                IN              the Internet system
-
-                CH              the Chaos system
-
-TTL             which is the time to live of the RR.  This field is a 32
-                bit integer in units of seconds, an is primarily used by
-                resolvers when they cache RRs.  The TTL describes how
-                long a RR can be cached before it should be discarded.
-
-
-
-
-Mockapetris                                                    [Page 12]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-RDATA           which is the type and sometimes class dependent data
-                which describes the resource:
-
-                A               For the IN class, a 32 bit IP address
-
-                                For the CH class, a domain name followed
-                                by a 16 bit octal Chaos address.
-
-                CNAME           a domain name.
-
-                MX              a 16 bit preference value (lower is
-                                better) followed by a host name willing
-                                to act as a mail exchange for the owner
-                                domain.
-
-                NS              a host name.
-
-                PTR             a domain name.
-
-                SOA             several fields.
-
-The owner name is often implicit, rather than forming an integral part
-of the RR.  For example, many name servers internally form tree or hash
-structures for the name space, and chain RRs off nodes.  The remaining
-RR parts are the fixed header (type, class, TTL) which is consistent for
-all RRs, and a variable part (RDATA) that fits the needs of the resource
-being described.
-
-The meaning of the TTL field is a time limit on how long an RR can be
-kept in a cache.  This limit does not apply to authoritative data in
-zones; it is also timed out, but by the refreshing policies for the
-zone.  The TTL is assigned by the administrator for the zone where the
-data originates.  While short TTLs can be used to minimize caching, and
-a zero TTL prohibits caching, the realities of Internet performance
-suggest that these times should be on the order of days for the typical
-host.  If a change can be anticipated, the TTL can be reduced prior to
-the change to minimize inconsistency during the change, and then
-increased back to its former value following the change.
-
-The data in the RDATA section of RRs is carried as a combination of
-binary strings and domain names.  The domain names are frequently used
-as "pointers" to other data in the DNS.
-
-3.6.1. Textual expression of RRs
-
-RRs are represented in binary form in the packets of the DNS protocol,
-and are usually represented in highly encoded form when stored in a name
-server or resolver.  In this memo, we adopt a style similar to that used
-
-
-
-Mockapetris                                                    [Page 13]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-in master files in order to show the contents of RRs.  In this format,
-most RRs are shown on a single line, although continuation lines are
-possible using parentheses.
-
-The start of the line gives the owner of the RR.  If a line begins with
-a blank, then the owner is assumed to be the same as that of the
-previous RR.  Blank lines are often included for readability.
-
-Following the owner, we list the TTL, type, and class of the RR.  Class
-and type use the mnemonics defined above, and TTL is an integer before
-the type field.  In order to avoid ambiguity in parsing, type and class
-mnemonics are disjoint, TTLs are integers, and the type mnemonic is
-always last. The IN class and TTL values are often omitted from examples
-in the interests of clarity.
-
-The resource data or RDATA section of the RR are given using knowledge
-of the typical representation for the data.
-
-For example, we might show the RRs carried in a message as:
-
-    ISI.EDU.        MX      10 VENERA.ISI.EDU.
-                    MX      10 VAXA.ISI.EDU.
-    VENERA.ISI.EDU. A       128.9.0.32
-                    A       10.1.0.52
-    VAXA.ISI.EDU.   A       10.2.0.27
-                    A       128.9.0.33
-
-The MX RRs have an RDATA section which consists of a 16 bit number
-followed by a domain name.  The address RRs use a standard IP address
-format to contain a 32 bit internet address.
-
-This example shows six RRs, with two RRs at each of three domain names.
-
-Similarly we might see:
-
-    XX.LCS.MIT.EDU. IN      A       10.0.0.44
-                    CH      A       MIT.EDU. 2420
-
-This example shows two addresses for XX.LCS.MIT.EDU, each of a different
-class.
-
-3.6.2. Aliases and canonical names
-
-In existing systems, hosts and other resources often have several names
-that identify the same resource.  For example, the names C.ISI.EDU and
-USC-ISIC.ARPA both identify the same host.  Similarly, in the case of
-mailboxes, many organizations provide many names that actually go to the
-same mailbox; for example Mockapetris@C.ISI.EDU, Mockapetris@B.ISI.EDU,
-
-
-
-Mockapetris                                                    [Page 14]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-and PVM@ISI.EDU all go to the same mailbox (although the mechanism
-behind this is somewhat complicated).
-
-Most of these systems have a notion that one of the equivalent set of
-names is the canonical or primary name and all others are aliases.
-
-The domain system provides such a feature using the canonical name
-(CNAME) RR.  A CNAME RR identifies its owner name as an alias, and
-specifies the corresponding canonical name in the RDATA section of the
-RR.  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.
-
-CNAME RRs cause special action in DNS software.  When a name server
-fails to find a desired RR in the resource set associated with the
-domain name, it checks to see if the resource set consists of a CNAME
-record with a matching class.  If so, the name server includes the CNAME
-record in the response and restarts the query at the domain name
-specified in the data field of the CNAME record.  The one exception to
-this rule is that queries which match the CNAME type are not restarted.
-
-For example, suppose a name server was processing a query with for USC-
-ISIC.ARPA, asking for type A information, and had the following resource
-records:
-
-    USC-ISIC.ARPA   IN      CNAME   C.ISI.EDU
-
-    C.ISI.EDU       IN      A       10.0.0.52
-
-Both of these RRs would be returned in the response to the type A query,
-while a type CNAME or * query should return just the CNAME.
-
-Domain names in RRs which point at another name should always point at
-the primary name and not the alias.  This avoids extra indirections in
-accessing information.  For example, the address to name RR for the
-above host should be:
-
-    52.0.0.10.IN-ADDR.ARPA  IN      PTR     C.ISI.EDU
-
-rather than pointing at USC-ISIC.ARPA.  Of course, by the robustness
-principle, domain software should not fail when presented with CNAME
-chains or loops; CNAME chains should be followed and CNAME loops
-signalled as an error.
-
-3.7. Queries
-
-Queries are messages which may be sent to a name server to provoke a
-
-
-
-Mockapetris                                                    [Page 15]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-response.  In the Internet, queries are carried in UDP datagrams or over
-TCP connections.  The response by the name server either answers the
-question posed in the query, refers the requester to another set of name
-servers, or signals some error condition.
-
-In general, the user does not generate queries directly, but instead
-makes a request to a resolver which in turn sends one or more queries to
-name servers and deals with the error conditions and referrals that may
-result.  Of course, the possible questions which can be asked in a query
-does shape the kind of service a resolver can provide.
-
-DNS queries and responses are carried in a standard message format.  The
-message format has a header containing a number of fixed fields which
-are always present, and four sections which carry query parameters and
-RRs.
-
-The most important field in the header is a four bit field called an
-opcode which separates different queries.  Of the possible 16 values,
-one (standard query) is part of the official protocol, two (inverse
-query and status query) are options, one (completion) is obsolete, and
-the rest are unassigned.
-
-The four sections are:
-
-Question        Carries the query name and other query parameters.
-
-Answer          Carries RRs which directly answer the query.
-
-Authority       Carries RRs which describe other authoritative servers.
-                May optionally carry the SOA RR for the authoritative
-                data in the answer section.
-
-Additional      Carries RRs which may be helpful in using the RRs in the
-                other sections.
-
-Note that the content, but not the format, of these sections varies with
-header opcode.
-
-3.7.1. Standard queries
-
-A standard query specifies a target domain name (QNAME), query type
-(QTYPE), and query class (QCLASS) and asks for RRs which match.  This
-type of query makes up such a vast majority of DNS queries that we use
-the term "query" to mean standard query unless otherwise specified.  The
-QTYPE and QCLASS fields are each 16 bits long, and are a superset of
-defined types and classes.
-
-
-
-
-
-Mockapetris                                                    [Page 16]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-The QTYPE field may contain:
-
-<any type>      matches just that type. (e.g., A, PTR).
-
-AXFR            special zone transfer QTYPE.
-
-MAILB           matches all mail box related RRs (e.g. MB and MG).
-
-*               matches all RR types.
-
-The QCLASS field may contain:
-
-<any class>     matches just that class (e.g., IN, CH).
-
-*               matches aLL RR classes.
-
-Using the query domain name, QTYPE, and QCLASS, the name server looks
-for matching RRs.  In addition to relevant records, the name server may
-return RRs that point toward a name server that has the desired
-information or RRs that are expected to be useful in interpreting the
-relevant RRs.  For example, a name server that doesn't have the
-requested information may know a name server that does; a name server
-that returns a domain name in a relevant RR may also return the RR that
-binds that domain name to an address.
-
-For example, a mailer tying to send mail to Mockapetris@ISI.EDU might
-ask the resolver for mail information about ISI.EDU, resulting in a
-query for QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN.  The response's answer
-section would be:
-
-    ISI.EDU.        MX      10 VENERA.ISI.EDU.
-                    MX      10 VAXA.ISI.EDU.
-
-while the additional section might be:
-
-    VAXA.ISI.EDU.   A       10.2.0.27
-                    A       128.9.0.33
-    VENERA.ISI.EDU. A       10.1.0.52
-                    A       128.9.0.32
-
-Because the server assumes that if the requester wants mail exchange
-information, it will probably want the addresses of the mail exchanges
-soon afterward.
-
-Note that the QCLASS=* construct requires special interpretation
-regarding authority.  Since a particular name server may not know all of
-the classes available in the domain system, it can never know if it is
-authoritative for all classes.  Hence responses to QCLASS=* queries can
-
-
-
-Mockapetris                                                    [Page 17]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-never be authoritative.
-
-3.7.2. Inverse queries (Optional)
-
-Name servers may also support inverse queries that map a particular
-resource to a domain name or domain names that have that resource.  For
-example, while a standard query might map a domain name to a SOA RR, the
-corresponding inverse query might map the SOA RR back to the domain
-name.
-
-Implementation of this service is optional in a name server, but all
-name servers must at least be able to understand an inverse query
-message and return a not-implemented error response.
-
-The domain system cannot guarantee the completeness or uniqueness of
-inverse queries because the domain system is organized by domain name
-rather than by host address or any other resource type.  Inverse queries
-are primarily useful for debugging and database maintenance activities.
-
-Inverse queries may not return the proper TTL, and do not indicate cases
-where the identified RR is one of a set (for example, one address for a
-host having multiple addresses).  Therefore, the RRs returned in inverse
-queries should never be cached.
-
-Inverse queries are NOT an acceptable method for mapping host addresses
-to host names; use the IN-ADDR.ARPA domain instead.
-
-A detailed discussion of inverse queries is contained in [RFC-1035].
-
-3.8. Status queries (Experimental)
-
-To be defined.
-
-3.9. Completion queries (Obsolete)
-
-The optional completion services described in RFCs 882 and 883 have been
-deleted.  Redesigned services may become available in the future, or the
-opcodes may be reclaimed for other use.
-
-4. NAME SERVERS
-
-4.1. Introduction
-
-Name servers are the repositories of information that make up the domain
-database.  The database is divided up into sections called zones, which
-are distributed among the name servers.  While name servers can have
-several optional functions and sources of data, the essential task of a
-name server is to answer queries using data in its zones.  By design,
-
-
-
-Mockapetris                                                    [Page 18]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-name servers can answer queries in a simple manner; the response can
-always be generated using only local data, and either contains the
-answer to the question or a referral to other name servers "closer" to
-the desired information.
-
-A given zone will be available from several name servers to insure its
-availability in spite of host or communication link failure.  By
-administrative fiat, we require every zone to be available on at least
-two servers, and many zones have more redundancy than that.
-
-A given name server will typically support one or more zones, but this
-gives it authoritative information about only a small section of the
-domain tree.  It may also have some cached non-authoritative data about
-other parts of the tree.  The name server marks its responses to queries
-so that the requester can tell whether the response comes from
-authoritative data or not.
-
-4.2. How the database is divided into zones
-
-The domain database is partitioned in two ways: by class, and by "cuts"
-made in the name space between nodes.
-
-The class partition is simple.  The database for any class is organized,
-delegated, and maintained separately from all other classes.  Since, by
-convention, the name spaces are the same for all classes, the separate
-classes can be thought of as an array of parallel namespace trees.  Note
-that the data attached to nodes will be different for these different
-parallel classes.  The most common reasons for creating a new class are
-the necessity for a new data format for existing types or a desire for a
-separately managed version of the existing name space.
-
-Within a class, "cuts" in the name space can be made between any two
-adjacent nodes.  After all cuts are made, each group of connected name
-space is a separate zone.  The zone is said to be authoritative for all
-names in the connected region.  Note that the "cuts" in the name space
-may be in different places for different classes, the name servers may
-be different, etc.
-
-These rules mean that every zone has at least one node, and hence domain
-name, for which it is authoritative, and all of the nodes in a
-particular zone are connected.  Given, the tree structure, every zone
-has a highest node which is closer to the root than any other node in
-the zone.  The name of this node is often used to identify the zone.
-
-It would be possible, though not particularly useful, to partition the
-name space so that each domain name was in a separate zone or so that
-all nodes were in a single zone.  Instead, the database is partitioned
-at points where a particular organization wants to take over control of
-
-
-
-Mockapetris                                                    [Page 19]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-a subtree.  Once an organization controls its own zone it can
-unilaterally change the data in the zone, grow new tree sections
-connected to the zone, delete existing nodes, or delegate new subzones
-under its zone.
-
-If the organization has substructure, it may want to make further
-internal partitions to achieve nested delegations of name space control.
-In some cases, such divisions are made purely to make database
-maintenance more convenient.
-
-4.2.1. Technical considerations
-
-The data that describes a zone has four major parts:
-
-   - Authoritative data for all nodes within the zone.
-
-   - Data that defines the top node of the zone (can be thought of
-     as part of the authoritative data).
-
-   - Data that describes delegated subzones, i.e., cuts around the
-     bottom of the zone.
-
-   - Data that allows access to name servers for subzones
-     (sometimes called "glue" data).
-
-All of this data is expressed in the form of RRs, so a zone can be
-completely described in terms of a set of RRs.  Whole zones can be
-transferred between name servers by transferring the RRs, either carried
-in a series of messages or by FTPing a master file which is a textual
-representation.
-
-The authoritative data for a zone is simply all of the RRs attached to
-all of the nodes from the top node of the zone down to leaf nodes or
-nodes above cuts around the bottom edge of the zone.
-
-Though logically part of the authoritative data, the RRs that describe
-the top node of the zone are especially important to the zone's
-management.  These RRs are of two types: name server RRs that list, one
-per RR, all of the servers for the zone, and a single SOA RR that
-describes zone management parameters.
-
-The RRs that describe cuts around the bottom of the zone are NS RRs that
-name the servers for the subzones.  Since the cuts are between nodes,
-these RRs are NOT part of the authoritative data of the zone, and should
-be exactly the same as the corresponding RRs in the top node of the
-subzone.  Since name servers are always associated with zone boundaries,
-NS RRs are only found at nodes which are the top node of some zone.  In
-the data that makes up a zone, NS RRs are found at the top node of the
-
-
-
-Mockapetris                                                    [Page 20]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-zone (and are authoritative) and at cuts around the bottom of the zone
-(where they are not authoritative), but never in between.
-
-One of the goals of the zone structure is that any zone have all the
-data required to set up communications with the name servers for any
-subzones.  That is, parent zones have all the information needed to
-access servers for their children zones.  The NS RRs that name the
-servers for subzones are often not enough for this task since they name
-the servers, but do not give their addresses.  In particular, if the
-name of the name server is itself in the subzone, we could be faced with
-the situation where the NS RRs tell us that in order to learn a name
-server's address, we should contact the server using the address we wish
-to learn.  To fix this problem, a zone contains "glue" RRs which are not
-part of the authoritative data, and are address RRs for the servers.
-These RRs are only necessary if the name server's name is "below" the
-cut, and are only used as part of a referral response.
-
-4.2.2. Administrative considerations
-
-When some organization wants to control its own domain, the first step
-is to identify the proper parent zone, and get the parent zone's owners
-to agree to the delegation of control.  While there are no particular
-technical constraints dealing with where in the tree this can be done,
-there are some administrative groupings discussed in [RFC-1032] which
-deal with top level organization, and middle level zones are free to
-create their own rules.  For example, one university might choose to use
-a single zone, while another might choose to organize by subzones
-dedicated to individual departments or schools.  [RFC-1033] catalogs
-available DNS software an discusses administration procedures.
-
-Once the proper name for the new subzone is selected, the new owners
-should be required to demonstrate redundant name server support.  Note
-that there is no requirement that the servers for a zone reside in a
-host which has a name in that domain.  In many cases, a zone will be
-more accessible to the internet at large if its servers are widely
-distributed rather than being within the physical facilities controlled
-by the same organization that manages the zone.  For example, in the
-current DNS, one of the name servers for the United Kingdom, or UK
-domain, is found in the US.  This allows US hosts to get UK data without
-using limited transatlantic bandwidth.
-
-As the last installation step, the delegation NS RRs and glue RRs
-necessary to make the delegation effective should be added to the parent
-zone.  The administrators of both zones should insure that the NS and
-glue RRs which mark both sides of the cut are consistent and remain so.
-
-4.3. Name server internals
-
-
-
-
-Mockapetris                                                    [Page 21]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-4.3.1. Queries and responses
-
-The principal activity of name servers is to answer standard queries.
-Both the query and its response are carried in a standard message format
-which is described in [RFC-1035].  The query contains a QTYPE, QCLASS,
-and QNAME, which describe the types and classes of desired information
-and the name of interest.
-
-The way that the name server answers the query depends upon whether it
-is operating in recursive mode or not:
-
-   - The simplest mode for the server is non-recursive, since it
-     can answer queries using only local information: the response
-     contains an error, the answer, or a referral to some other
-     server "closer" to the answer.  All name servers must
-     implement non-recursive queries.
-
-   - The simplest mode for the client is recursive, since in this
-     mode the name server acts in the role of a resolver and
-     returns either an error or the answer, but never referrals.
-     This service is optional in a name server, and the name server
-     may also choose to restrict the clients which can use
-     recursive mode.
-
-Recursive service is helpful in several situations:
-
-   - a relatively simple requester that lacks the ability to use
-     anything other than a direct answer to the question.
-
-   - a request that needs to cross protocol or other boundaries and
-     can be sent to a server which can act as intermediary.
-
-   - a network where we want to concentrate the cache rather than
-     having a separate cache for each client.
-
-Non-recursive service is appropriate if the requester is capable of
-pursuing referrals and interested in information which will aid future
-requests.
-
-The use of recursive mode is limited to cases where both the client and
-the name server agree to its use.  The agreement is negotiated through
-the use of two bits in query and response messages:
-
-   - The recursion available, or RA bit, is set or cleared by a
-     name server in all responses.  The bit is true if the name
-     server is willing to provide recursive service for the client,
-     regardless of whether the client requested recursive service.
-     That is, RA signals availability rather than use.
-
-
-
-Mockapetris                                                    [Page 22]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-   - Queries contain a bit called recursion desired or RD.  This
-     bit specifies specifies whether the requester wants recursive
-     service for this query.  Clients may request recursive service
-     from any name server, though they should depend upon receiving
-     it only from servers which have previously sent an RA, or
-     servers which have agreed to provide service through private
-     agreement or some other means outside of the DNS protocol.
-
-The recursive mode occurs when a query with RD set arrives at a server
-which is willing to provide recursive service; the client can verify
-that recursive mode was used by checking that both RA and RD are set in
-the reply.  Note that the name server should never perform recursive
-service unless asked via RD, since this interferes with trouble shooting
-of name servers and their databases.
-
-If recursive service is requested and available, the recursive response
-to a query will be one of the following:
-
-   - The answer to the query, possibly preface by one or more CNAME
-     RRs that specify aliases encountered on the way to an answer.
-
-   - A name error indicating that the name does not exist.  This
-     may include CNAME RRs that indicate that the original query
-     name was an alias for a name which does not exist.
-
-   - A temporary error indication.
-
-If recursive service is not requested or is not available, the non-
-recursive response will be one of the following:
-
-   - An authoritative name error indicating that the name does not
-     exist.
-
-   - A temporary error indication.
-
-   - Some combination of:
-
-     RRs that answer the question, together with an indication
-     whether the data comes from a zone or is cached.
-
-     A referral to name servers which have zones which are closer
-     ancestors to the name than the server sending the reply.
-
-   - RRs that the name server thinks will prove useful to the
-     requester.
-
-
-
-
-
-
-Mockapetris                                                    [Page 23]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-4.3.2. Algorithm
-
-The actual algorithm used by the name server will depend on the local OS
-and data structures used to store RRs.  The following algorithm assumes
-that the RRs are organized in several tree structures, one for each
-zone, and another for the cache:
-
-   1. Set or clear the value of recursion available in the response
-      depending on whether the name server is willing to provide
-      recursive service.  If recursive service is available and
-      requested via the RD bit in the query, go to step 5,
-      otherwise step 2.
-
-   2. Search the available zones for the zone which is the nearest
-      ancestor to QNAME.  If such a zone is found, go to step 3,
-      otherwise step 4.
-
-   3. Start matching down, label by label, in the zone.  The
-      matching process can terminate several ways:
-
-         a. If the whole of QNAME is matched, we have found the
-            node.
-
-            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, change QNAME to the canonical name in
-            the CNAME RR, and go back to step 1.
-
-            Otherwise, copy all RRs which match QTYPE into the
-            answer section and go to step 6.
-
-         b. If a match would take us out of the authoritative data,
-            we have a referral.  This happens when we encounter a
-            node with NS RRs marking cuts along the bottom of a
-            zone.
-
-            Copy the NS RRs for the subzone into the authority
-            section of the reply.  Put whatever addresses are
-            available into the additional section, using glue RRs
-            if the addresses are not available from authoritative
-            data or the cache.  Go to step 4.
-
-         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.
-
-            If the "*" label does not exist, check whether the name
-            we are looking for is the original QNAME in the query
-
-
-
-Mockapetris                                                    [Page 24]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-            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.
-
-            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.
-
-   4. Start matching down in the cache.  If QNAME is found in the
-      cache, copy all RRs attached to it that match QTYPE into the
-      answer section.  If there was no delegation from
-      authoritative data, look for the best one from the cache, and
-      put it in the authority section.  Go to step 6.
-
-   5. Using the local resolver or a copy of its algorithm (see
-      resolver section of this memo) to answer the query.  Store
-      the results, including any intermediate CNAMEs, in the answer
-      section of the response.
-
-   6. Using local data only, attempt to add other RRs which may be
-      useful to the additional section of the query.  Exit.
-
-4.3.3. Wildcards
-
-In the previous algorithm, special treatment was given to RRs with owner
-names starting with the label "*".  Such RRs are called wildcards.
-Wildcard RRs can be thought of as instructions for synthesizing RRs.
-When the appropriate conditions are met, the name server creates RRs
-with an owner name equal to the query name and contents taken from the
-wildcard RRs.
-
-This facility is most often used to create a zone which will be used to
-forward mail from the Internet to some other mail system.  The general
-idea is that any name in that zone which is presented to server in a
-query will be assumed to exist, with certain properties, unless explicit
-evidence exists to the contrary.  Note that the use of the term zone
-here, instead of domain, is intentional; such defaults do not propagate
-across zone boundaries, although a subzone may choose to achieve that
-appearance by setting up similar defaults.
-
-The contents of the wildcard RRs follows the usual rules and formats for
-RRs.  The wildcards in the zone have an owner name that controls the
-query names they will match.  The owner name of the wildcard RRs is of
-the form "*.<anydomain>", where <anydomain> is any domain name.
-<anydomain> should not contain other * labels, and should be in the
-authoritative data of the zone.  The wildcards potentially apply to
-descendants of <anydomain>, but not to <anydomain> itself.  Another way
-
-
-
-Mockapetris                                                    [Page 25]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-to look at this is that the "*" label always matches at least one whole
-label and sometimes more, but always whole labels.
-
-Wildcard RRs do not apply:
-
-   - When the query is in another zone.  That is, delegation cancels
-     the wildcard defaults.
-
-   - When the query name or a name between the wildcard domain and
-     the query name is know to exist.  For example, if a wildcard
-     RR has an owner name of "*.X", and the zone also contains RRs
-     attached to B.X, the wildcards would apply to queries for name
-     Z.X (presuming there is no explicit information for Z.X), but
-     not to B.X, A.B.X, or X.
-
-A * label appearing in a query name has no special effect, but can be
-used to test for wildcards in an authoritative zone; such a query is the
-only way to get a response containing RRs with an owner name with * in
-it.  The result of such a query should not be cached.
-
-Note that the contents of the wildcard RRs are not modified when used to
-synthesize RRs.
-
-To illustrate the use of wildcard RRs, suppose a large company with a
-large, non-IP/TCP, network wanted to create a mail gateway.  If the
-company was called X.COM, and IP/TCP capable gateway machine was called
-A.X.COM, the following RRs might be entered into the COM zone:
-
-    X.COM           MX      10      A.X.COM
-
-    *.X.COM         MX      10      A.X.COM
-
-    A.X.COM         A       1.2.3.4
-    A.X.COM         MX      10      A.X.COM
-
-    *.A.X.COM       MX      10      A.X.COM
-
-This would cause any MX query for any domain name ending in X.COM to
-return an MX RR pointing at A.X.COM.  Two wildcard RRs are required
-since the effect of the wildcard at *.X.COM is inhibited in the A.X.COM
-subtree by the explicit data for A.X.COM.  Note also that the explicit
-MX data at X.COM and A.X.COM is required, and that none of the RRs above
-would match a query name of XX.COM.
-
-4.3.4. Negative response caching (Optional)
-
-The DNS provides an optional service which allows name servers to
-distribute, and resolvers to cache, negative results with TTLs.  For
-
-
-
-Mockapetris                                                    [Page 26]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-example, a name server can distribute a TTL along with a name error
-indication, and a resolver receiving such information is allowed to
-assume that the name does not exist during the TTL period without
-consulting authoritative data.  Similarly, a resolver can make a query
-with a QTYPE which matches multiple types, and cache the fact that some
-of the types are not present.
-
-This feature can be particularly important in a system which implements
-naming shorthands that use search lists beacuse a popular shorthand,
-which happens to require a suffix toward the end of the search list,
-will generate multiple name errors whenever it is used.
-
-The method is that a name server may add an SOA RR to the additional
-section of a response when that response is authoritative.  The SOA must
-be that of the zone which was the source of the authoritative data in
-the answer section, or name error if applicable.  The MINIMUM field of
-the SOA controls the length of time that the negative result may be
-cached.
-
-Note that in some circumstances, the answer section may contain multiple
-owner names.  In this case, the SOA mechanism should only be used for
-the data which matches QNAME, which is the only authoritative data in
-this section.
-
-Name servers and resolvers should never attempt to add SOAs to the
-additional section of a non-authoritative response, or attempt to infer
-results which are not directly stated in an authoritative response.
-There are several reasons for this, including: cached information isn't
-usually enough to match up RRs and their zone names, SOA RRs may be
-cached due to direct SOA queries, and name servers are not required to
-output the SOAs in the authority section.
-
-This feature is optional, although a refined version is expected to
-become part of the standard protocol in the future.  Name servers are
-not required to add the SOA RRs in all authoritative responses, nor are
-resolvers required to cache negative results.  Both are recommended.
-All resolvers and recursive name servers are required to at least be
-able to ignore the SOA RR when it is present in a response.
-
-Some experiments have also been proposed which will use this feature.
-The idea is that if cached data is known to come from a particular zone,
-and if an authoritative copy of the zone's SOA is obtained, and if the
-zone's SERIAL has not changed since the data was cached, then the TTL of
-the cached data can be reset to the zone MINIMUM value if it is smaller.
-This usage is mentioned for planning purposes only, and is not
-recommended as yet.
-
-
-
-
-
-Mockapetris                                                    [Page 27]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-4.3.5. Zone maintenance and transfers
-
-Part of the job of a zone administrator is to maintain the zones at all
-of the name servers which are authoritative for the zone.  When the
-inevitable changes are made, they must be distributed to all of the name
-servers.  While this distribution can be accomplished using FTP or some
-other ad hoc procedure, the preferred method is the zone transfer part
-of the DNS protocol.
-
-The general model of automatic zone transfer or refreshing is that one
-of the name servers is the master or primary for the zone.  Changes are
-coordinated at the primary, typically by editing a master file for the
-zone.  After editing, the administrator signals the master server to
-load the new zone.  The other non-master or secondary servers for the
-zone periodically check for changes (at a selectable interval) and
-obtain new zone copies when changes have been made.
-
-To detect changes, secondaries just check the SERIAL field of the SOA
-for the zone.  In addition to whatever other changes are made, the
-SERIAL field in the SOA of the zone is always advanced whenever any
-change is made to the zone.  The advancing can be a simple increment, or
-could be based on the write date and time of the master file, etc.  The
-purpose is to make it possible to determine which of two copies of a
-zone is more recent by comparing serial numbers.  Serial number advances
-and comparisons use sequence space arithmetic, so there is a theoretic
-limit on how fast a zone can be updated, basically that old copies must
-die out before the serial number covers half of its 32 bit range.  In
-practice, the only concern is that the compare operation deals properly
-with comparisons around the boundary between the most positive and most
-negative 32 bit numbers.
-
-The periodic polling of the secondary servers is controlled by
-parameters in the SOA RR for the zone, which set the minimum acceptable
-polling intervals.  The parameters are called REFRESH, RETRY, and
-EXPIRE.  Whenever a new zone is loaded in a secondary, the secondary
-waits REFRESH seconds before checking with the primary for a new serial.
-If this check cannot be completed, new checks are started every RETRY
-seconds.  The check is a simple query to the primary for the SOA RR of
-the zone.  If the serial field in the secondary's zone copy is equal to
-the serial returned by the primary, then no changes have occurred, and
-the REFRESH interval wait is restarted.  If the secondary finds it
-impossible to perform a serial check for the EXPIRE interval, it must
-assume that its copy of the zone is obsolete an discard it.
-
-When the poll shows that the zone has changed, then the secondary server
-must request a zone transfer via an AXFR request for the zone.  The AXFR
-may cause an error, such as refused, but normally is answered by a
-sequence of response messages.  The first and last messages must contain
-
-
-
-Mockapetris                                                    [Page 28]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-the data for the top authoritative node of the zone.  Intermediate
-messages carry all of the other RRs from the zone, including both
-authoritative and non-authoritative RRs.  The stream of messages allows
-the secondary to construct a copy of the zone.  Because accuracy is
-essential, TCP or some other reliable protocol must be used for AXFR
-requests.
-
-Each secondary server is required to perform the following operations
-against the master, but may also optionally perform these operations
-against other secondary servers.  This strategy can improve the transfer
-process when the primary is unavailable due to host downtime or network
-problems, or when a secondary server has better network access to an
-"intermediate" secondary than to the primary.
-
-5. RESOLVERS
-
-5.1. Introduction
-
-Resolvers are programs that interface user programs to domain name
-servers.  In the simplest case, a resolver receives a request from a
-user program (e.g., mail programs, TELNET, FTP) in the form of a
-subroutine call, system call etc., and returns the desired information
-in a form compatible with the local host's data formats.
-
-The resolver is located on the same machine as the program that requests
-the resolver's services, but it may need to consult name servers on
-other hosts.  Because a resolver may need to consult several name
-servers, or may have the requested information in a local cache, the
-amount of time that a resolver will take to complete can vary quite a
-bit, from milliseconds to several seconds.
-
-A very important goal of the resolver is to eliminate network delay and
-name server load from most requests by answering them from its cache of
-prior results.  It follows that caches which are shared by multiple
-processes, users, machines, etc., are more efficient than non-shared
-caches.
-
-5.2. Client-resolver interface
-
-5.2.1. Typical functions
-
-The client interface to the resolver is influenced by the local host's
-conventions, but the typical resolver-client interface has three
-functions:
-
-   1. Host name to host address translation.
-
-      This function is often defined to mimic a previous HOSTS.TXT
-
-
-
-Mockapetris                                                    [Page 29]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-      based function.  Given a character string, the caller wants
-      one or more 32 bit IP addresses.  Under the DNS, it
-      translates into a request for type A RRs.  Since the DNS does
-      not preserve the order of RRs, this function may choose to
-      sort the returned addresses or select the "best" address if
-      the service returns only one choice to the client.  Note that
-      a multiple address return is recommended, but a single
-      address may be the only way to emulate prior HOSTS.TXT
-      services.
-
-   2. Host address to host name translation
-
-      This function will often follow the form of previous
-      functions.  Given a 32 bit IP address, the caller wants a
-      character string.  The octets of the IP address are reversed,
-      used as name components, and suffixed with "IN-ADDR.ARPA".  A
-      type PTR query is used to get the RR with the primary name of
-      the host.  For example, a request for the host name
-      corresponding to IP address 1.2.3.4 looks for PTR RRs for
-      domain name "4.3.2.1.IN-ADDR.ARPA".
-
-   3. General lookup function
-
-      This function retrieves arbitrary information from the DNS,
-      and has no counterpart in previous systems.  The caller
-      supplies a QNAME, QTYPE, and QCLASS, and wants all of the
-      matching RRs.  This function will often use the DNS format
-      for all RR data instead of the local host's, and returns all
-      RR content (e.g., TTL) instead of a processed form with local
-      quoting conventions.
-
-When the resolver performs the indicated function, it usually has one of
-the following results to pass back to the client:
-
-   - One or more RRs giving the requested data.
-
-     In this case the resolver returns the answer in the
-     appropriate format.
-
-   - A name error (NE).
-
-     This happens when the referenced name does not exist.  For
-     example, a user may have mistyped a host name.
-
-   - A data not found error.
-
-     This happens when the referenced name exists, but data of the
-     appropriate type does not.  For example, a host address
-
-
-
-Mockapetris                                                    [Page 30]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-     function applied to a mailbox name would return this error
-     since the name exists, but no address RR is present.
-
-It is important to note that the functions for translating between host
-names and addresses may combine the "name error" and "data not found"
-error conditions into a single type of error return, but the general
-function should not.  One reason for this is that applications may ask
-first for one type of information about a name followed by a second
-request to the same name for some other type of information; if the two
-errors are combined, then useless queries may slow the application.
-
-5.2.2. Aliases
-
-While attempting to resolve a particular request, the resolver may find
-that the name in question is an alias.  For example, the resolver might
-find that the name given for host name to address translation is an
-alias when it finds the CNAME RR.  If possible, the alias condition
-should be signalled back from the resolver to the client.
-
-In most cases a resolver simply restarts the query at the new name when
-it encounters a CNAME.  However, when performing the general function,
-the resolver should not pursue aliases when the CNAME RR matches the
-query type.  This allows queries which ask whether an alias is present.
-For example, if the query type is CNAME, the user is interested in the
-CNAME RR itself, and not the RRs at the name it points to.
-
-Several special conditions can occur with aliases.  Multiple levels of
-aliases should be avoided due to their lack of efficiency, but should
-not be signalled as an error.  Alias loops and aliases which point to
-non-existent names should be caught and an error condition passed back
-to the client.
-
-5.2.3. Temporary failures
-
-In a less than perfect world, all resolvers will occasionally be unable
-to resolve a particular request.  This condition can be caused by a
-resolver which becomes separated from the rest of the network due to a
-link failure or gateway problem, or less often by coincident failure or
-unavailability of all servers for a particular domain.
-
-It is essential that this sort of condition should not be signalled as a
-name or data not present error to applications.  This sort of behavior
-is annoying to humans, and can wreak havoc when mail systems use the
-DNS.
-
-While in some cases it is possible to deal with such a temporary problem
-by blocking the request indefinitely, this is usually not a good choice,
-particularly when the client is a server process that could move on to
-
-
-
-Mockapetris                                                    [Page 31]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-other tasks.  The recommended solution is to always have temporary
-failure as one of the possible results of a resolver function, even
-though this may make emulation of existing HOSTS.TXT functions more
-difficult.
-
-5.3. Resolver internals
-
-Every resolver implementation uses slightly different algorithms, and
-typically spends much more logic dealing with errors of various sorts
-than typical occurances.  This section outlines a recommended basic
-strategy for resolver operation, but leaves details to [RFC-1035].
-
-5.3.1. Stub resolvers
-
-One option for implementing a resolver is to move the resolution
-function out of the local machine and into a name server which supports
-recursive queries.  This can provide an easy method of providing domain
-service in a PC which lacks the resources to perform the resolver
-function, or can centralize the cache for a whole local network or
-organization.
-
-All that the remaining stub needs is a list of name server addresses
-that will perform the recursive requests.  This type of resolver
-presumably needs the information in a configuration file, since it
-probably lacks the sophistication to locate it in the domain database.
-The user also needs to verify that the listed servers will perform the
-recursive service; a name server is free to refuse to perform recursive
-services for any or all clients.  The user should consult the local
-system administrator to find name servers willing to perform the
-service.
-
-This type of service suffers from some drawbacks.  Since the recursive
-requests may take an arbitrary amount of time to perform, the stub may
-have difficulty optimizing retransmission intervals to deal with both
-lost UDP packets and dead servers; the name server can be easily
-overloaded by too zealous a stub if it interprets retransmissions as new
-requests.  Use of TCP may be an answer, but TCP may well place burdens
-on the host's capabilities which are similar to those of a real
-resolver.
-
-5.3.2. Resources
-
-In addition to its own resources, the resolver may also have shared
-access to zones maintained by a local name server.  This gives the
-resolver the advantage of more rapid access, but the resolver must be
-careful to never let cached information override zone data.  In this
-discussion the term "local information" is meant to mean the union of
-the cache and such shared zones, with the understanding that
-
-
-
-Mockapetris                                                    [Page 32]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-authoritative data is always used in preference to cached data when both
-are present.
-
-The following resolver algorithm assumes that all functions have been
-converted to a general lookup function, and uses the following data
-structures to represent the state of a request in progress in the
-resolver:
-
-SNAME           the domain name we are searching for.
-
-STYPE           the QTYPE of the search request.
-
-SCLASS          the QCLASS of the search request.
-
-SLIST           a structure which describes the name servers and the
-                zone which the resolver is currently trying to query.
-                This structure keeps track of the resolver's current
-                best guess about which name servers hold the desired
-                information; it is updated when arriving information
-                changes the guess.  This structure includes the
-                equivalent of a zone name, the known name servers for
-                the zone, the known addresses for the name servers, and
-                history information which can be used to suggest which
-                server is likely to be the best one to try next.  The
-                zone name equivalent is a match count of the number of
-                labels from the root down which SNAME has in common with
-                the zone being queried; this is used as a measure of how
-                "close" the resolver is to SNAME.
-
-SBELT           a "safety belt" structure of the same form as SLIST,
-                which is initialized from a configuration file, and
-                lists servers which should be used when the resolver
-                doesn't have any local information to guide name server
-                selection.  The match count will be -1 to indicate that
-                no labels are known to match.
-
-CACHE           A structure which stores the results from previous
-                responses.  Since resolvers are responsible for
-                discarding old RRs whose TTL has expired, most
-                implementations convert the interval specified in
-                arriving RRs to some sort of absolute time when the RR
-                is stored in the cache.  Instead of counting the TTLs
-                down individually, the resolver just ignores or discards
-                old RRs when it runs across them in the course of a
-                search, or discards them during periodic sweeps to
-                reclaim the memory consumed by old RRs.
-
-
-
-
-
-Mockapetris                                                    [Page 33]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-5.3.3. Algorithm
-
-The top level algorithm has four steps:
-
-   1. See if the answer is in local information, and if so return
-      it to the client.
-
-   2. Find the best servers to ask.
-
-   3. Send them queries until one returns a response.
-
-   4. Analyze the response, either:
-
-         a. if the response answers the question or contains a name
-            error, cache the data as well as returning it back to
-            the client.
-
-         b. if the response contains a better delegation to other
-            servers, cache the delegation information, and go to
-            step 2.
-
-         c. if the response shows a CNAME and that is not the
-            answer itself, cache the CNAME, change the SNAME to the
-            canonical name in the CNAME RR and go to step 1.
-
-         d. if the response shows a servers failure or other
-            bizarre contents, delete the server from the SLIST and
-            go back to step 3.
-
-Step 1 searches the cache for the desired data. If the data is in the
-cache, it is assumed to be good enough for normal use.  Some resolvers
-have an option at the user interface which will force the resolver to
-ignore the cached data and consult with an authoritative server.  This
-is not recommended as the default.  If the resolver has direct access to
-a name server's zones, it should check to see if the desired data is
-present in authoritative form, and if so, use the authoritative data in
-preference to cached data.
-
-Step 2 looks for a name server to ask for the required data.  The
-general strategy is to look for locally-available name server RRs,
-starting at SNAME, then the parent domain name of SNAME, the
-grandparent, and so on toward the root.  Thus if SNAME were
-Mockapetris.ISI.EDU, this step would look for NS RRs for
-Mockapetris.ISI.EDU, then ISI.EDU, then EDU, and then . (the root).
-These NS RRs list the names of hosts for a zone at or above SNAME.  Copy
-the names into SLIST.  Set up their addresses using local data.  It may
-be the case that the addresses are not available.  The resolver has many
-choices here; the best is to start parallel resolver processes looking
-
-
-
-Mockapetris                                                    [Page 34]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-for the addresses while continuing onward with the addresses which are
-available.  Obviously, the design choices and options are complicated
-and a function of the local host's capabilities.  The recommended
-priorities for the resolver designer are:
-
-   1. Bound the amount of work (packets sent, parallel processes
-      started) so that a request can't get into an infinite loop or
-      start off a chain reaction of requests or queries with other
-      implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED
-      SOME DATA.
-
-   2. Get back an answer if at all possible.
-
-   3. Avoid unnecessary transmissions.
-
-   4. Get the answer as quickly as possible.
-
-If the search for NS RRs fails, then the resolver initializes SLIST from
-the safety belt SBELT.  The basic idea is that when the resolver has no
-idea what servers to ask, it should use information from a configuration
-file that lists several servers which are expected to be helpful.
-Although there are special situations, the usual choice is two of the
-root servers and two of the servers for the host's domain.  The reason
-for two of each is for redundancy.  The root servers will provide
-eventual access to all of the domain space.  The two local servers will
-allow the resolver to continue to resolve local names if the local
-network becomes isolated from the internet due to gateway or link
-failure.
-
-In addition to the names and addresses of the servers, the SLIST data
-structure can be sorted to use the best servers first, and to insure
-that all addresses of all servers are used in a round-robin manner.  The
-sorting can be a simple function of preferring addresses on the local
-network over others, or may involve statistics from past events, such as
-previous response times and batting averages.
-
-Step 3 sends out queries until a response is received.  The strategy is
-to cycle around all of the addresses for all of the servers with a
-timeout between each transmission.  In practice it is important to use
-all addresses of a multihomed host, and too aggressive a retransmission
-policy actually slows response when used by multiple resolvers
-contending for the same name server and even occasionally for a single
-resolver.  SLIST typically contains data values to control the timeouts
-and keep track of previous transmissions.
-
-Step 4 involves analyzing responses.  The resolver should be highly
-paranoid in its parsing of responses.  It should also check that the
-response matches the query it sent using the ID field in the response.
-
-
-
-Mockapetris                                                    [Page 35]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-The ideal answer is one from a server authoritative for the query which
-either gives the required data or a name error.  The data is passed back
-to the user and entered in the cache for future use if its TTL is
-greater than zero.
-
-If the response shows a delegation, the resolver should check to see
-that the delegation is "closer" to the answer than the servers in SLIST
-are.  This can be done by comparing the match count in SLIST with that
-computed from SNAME and the NS RRs in the delegation.  If not, the reply
-is bogus and should be ignored.  If the delegation is valid the NS
-delegation RRs and any address RRs for the servers should be cached.
-The name servers are entered in the SLIST, and the search is restarted.
-
-If the response contains a CNAME, the search is restarted at the CNAME
-unless the response has the data for the canonical name or if the CNAME
-is the answer itself.
-
-Details and implementation hints can be found in [RFC-1035].
-
-6. A SCENARIO
-
-In our sample domain space, suppose we wanted separate administrative
-control for the root, MIL, EDU, MIT.EDU and ISI.EDU zones.  We might
-allocate name servers as follows:
-
-
-                                   |(C.ISI.EDU,SRI-NIC.ARPA
-                                   | A.ISI.EDU)
-             +---------------------+------------------+
-             |                     |                  |
-            MIL                   EDU                ARPA
-             |(SRI-NIC.ARPA,       |(SRI-NIC.ARPA,    |
-             | A.ISI.EDU           | C.ISI.EDU)       |
-       +-----+-----+               |     +------+-----+-----+
-       |     |     |               |     |      |           |
-      BRL  NOSC  DARPA             |  IN-ADDR  SRI-NIC     ACC
-                                   |
-       +--------+------------------+---------------+--------+
-       |        |                  |               |        |
-      UCI      MIT                 |              UDEL     YALE
-                |(XX.LCS.MIT.EDU, ISI
-                |ACHILLES.MIT.EDU) |(VAXA.ISI.EDU,VENERA.ISI.EDU,
-            +---+---+              | A.ISI.EDU)
-            |       |              |
-           LCS   ACHILLES +--+-----+-----+--------+
-            |             |  |     |     |        |
-            XX            A  C   VAXA  VENERA Mockapetris
-
-
-
-
-Mockapetris                                                    [Page 36]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-In this example, the authoritative name server is shown in parentheses
-at the point in the domain tree at which is assumes control.
-
-Thus the root name servers are on C.ISI.EDU, SRI-NIC.ARPA, and
-A.ISI.EDU.  The MIL domain is served by SRI-NIC.ARPA and A.ISI.EDU.  The
-EDU domain is served by SRI-NIC.ARPA. and C.ISI.EDU.  Note that servers
-may have zones which are contiguous or disjoint.  In this scenario,
-C.ISI.EDU has contiguous zones at the root and EDU domains.  A.ISI.EDU
-has contiguous zones at the root and MIL domains, but also has a non-
-contiguous zone at ISI.EDU.
-
-6.1. C.ISI.EDU name server
-
-C.ISI.EDU is a name server for the root, MIL, and EDU domains of the IN
-class, and would have zones for these domains.  The zone data for the
-root domain might be:
-
-    .       IN      SOA     SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
-                            870611          ;serial
-                            1800            ;refresh every 30 min
-                            300             ;retry every 5 min
-                            604800          ;expire after a week
-                            86400)          ;minimum of a day
-                    NS      A.ISI.EDU.
-                    NS      C.ISI.EDU.
-                    NS      SRI-NIC.ARPA.
-
-    MIL.    86400   NS      SRI-NIC.ARPA.
-            86400   NS      A.ISI.EDU.
-
-    EDU.    86400   NS      SRI-NIC.ARPA.
-            86400   NS      C.ISI.EDU.
-
-    SRI-NIC.ARPA.   A       26.0.0.73
-                    A       10.0.0.51
-                    MX      0 SRI-NIC.ARPA.
-                    HINFO   DEC-2060 TOPS20
-
-    ACC.ARPA.       A       26.6.0.65
-                    HINFO   PDP-11/70 UNIX
-                    MX      10 ACC.ARPA.
-
-    USC-ISIC.ARPA.  CNAME   C.ISI.EDU.
-
-    73.0.0.26.IN-ADDR.ARPA.  PTR    SRI-NIC.ARPA.
-    65.0.6.26.IN-ADDR.ARPA.  PTR    ACC.ARPA.
-    51.0.0.10.IN-ADDR.ARPA.  PTR    SRI-NIC.ARPA.
-    52.0.0.10.IN-ADDR.ARPA.  PTR    C.ISI.EDU.
-
-
-
-Mockapetris                                                    [Page 37]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-    103.0.3.26.IN-ADDR.ARPA. PTR    A.ISI.EDU.
-
-    A.ISI.EDU. 86400 A      26.3.0.103
-    C.ISI.EDU. 86400 A      10.0.0.52
-
-This data is represented as it would be in a master file.  Most RRs are
-single line entries; the sole exception here is the SOA RR, which uses
-"(" to start a multi-line RR and ")" to show the end of a multi-line RR.
-Since the class of all RRs in a zone must be the same, only the first RR
-in a zone need specify the class.  When a name server loads a zone, it
-forces the TTL of all authoritative RRs to be at least the MINIMUM field
-of the SOA, here 86400 seconds, or one day.  The NS RRs marking
-delegation of the MIL and EDU domains, together with the glue RRs for
-the servers host addresses, are not part of the authoritative data in
-the zone, and hence have explicit TTLs.
-
-Four RRs are attached to the root node: the SOA which describes the root
-zone and the 3 NS RRs which list the name servers for the root.  The
-data in the SOA RR describes the management of the zone.  The zone data
-is maintained on host SRI-NIC.ARPA, and the responsible party for the
-zone is HOSTMASTER@SRI-NIC.ARPA.  A key item in the SOA is the 86400
-second minimum TTL, which means that all authoritative data in the zone
-has at least that TTL, although higher values may be explicitly
-specified.
-
-The NS RRs for the MIL and EDU domains mark the boundary between the
-root zone and the MIL and EDU zones.  Note that in this example, the
-lower zones happen to be supported by name servers which also support
-the root zone.
-
-The master file for the EDU zone might be stated relative to the origin
-EDU.  The zone data for the EDU domain might be:
-
-    EDU.  IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
-                            870729 ;serial
-                            1800 ;refresh every 30 minutes
-                            300 ;retry every 5 minutes
-                            604800 ;expire after a week
-                            86400 ;minimum of a day
-                            )
-                    NS SRI-NIC.ARPA.
-                    NS C.ISI.EDU.
-
-    UCI 172800 NS ICS.UCI
-                    172800 NS ROME.UCI
-    ICS.UCI 172800 A 192.5.19.1
-    ROME.UCI 172800 A 192.5.19.31
-
-
-
-
-Mockapetris                                                    [Page 38]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-    ISI 172800 NS VAXA.ISI
-                    172800 NS A.ISI
-                    172800 NS VENERA.ISI.EDU.
-    VAXA.ISI 172800 A 10.2.0.27
-                    172800 A 128.9.0.33
-    VENERA.ISI.EDU. 172800 A 10.1.0.52
-                    172800 A 128.9.0.32
-    A.ISI 172800 A 26.3.0.103
-
-    UDEL.EDU.  172800 NS LOUIE.UDEL.EDU.
-                    172800 NS UMN-REI-UC.ARPA.
-    LOUIE.UDEL.EDU. 172800 A 10.0.0.96
-                    172800 A 192.5.39.3
-
-    YALE.EDU.  172800 NS YALE.ARPA.
-    YALE.EDU.  172800 NS YALE-BULLDOG.ARPA.
-
-    MIT.EDU.  43200 NS XX.LCS.MIT.EDU.
-                      43200 NS ACHILLES.MIT.EDU.
-    XX.LCS.MIT.EDU.  43200 A 10.0.0.44
-    ACHILLES.MIT.EDU. 43200 A 18.72.0.8
-
-Note the use of relative names here.  The owner name for the ISI.EDU. is
-stated using a relative name, as are two of the name server RR contents.
-Relative and absolute domain names may be freely intermixed in a master
-
-6.2. Example standard queries
-
-The following queries and responses illustrate name server behavior.
-Unless otherwise noted, the queries do not have recursion desired (RD)
-in the header.  Note that the answers to non-recursive queries do depend
-on the server being asked, but do not depend on the identity of the
-requester.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 39]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-6.2.1. QNAME=SRI-NIC.ARPA, QTYPE=A
-
-The query would look like:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY                                     |
-               +---------------------------------------------------+
-    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
-               +---------------------------------------------------+
-    Answer     | <empty>                                           |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-The response from C.ISI.EDU would be:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
-               +---------------------------------------------------+
-    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
-               +---------------------------------------------------+
-    Answer     | SRI-NIC.ARPA. 86400 IN A 26.0.0.73                |
-               |               86400 IN A 10.0.0.51                |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-The header of the response looks like the header of the query, except
-that the RESPONSE bit is set, indicating that this message is a
-response, not a query, and the Authoritative Answer (AA) bit is set
-indicating that the address RRs in the answer section are from
-authoritative data.  The question section of the response matches the
-question section of the query.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 40]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-If the same query was sent to some other server which was not
-authoritative for SRI-NIC.ARPA, the response might be:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY,RESPONSE                            |
-               +---------------------------------------------------+
-    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
-               +---------------------------------------------------+
-    Answer     | SRI-NIC.ARPA. 1777 IN A 10.0.0.51                 |
-               |               1777 IN A 26.0.0.73                 |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-This response is different from the previous one in two ways: the header
-does not have AA set, and the TTLs are different.  The inference is that
-the data did not come from a zone, but from a cache.  The difference
-between the authoritative TTL and the TTL here is due to aging of the
-data in a cache.  The difference in ordering of the RRs in the answer
-section is not significant.
-
-6.2.2. QNAME=SRI-NIC.ARPA, QTYPE=*
-
-A query similar to the previous one, but using a QTYPE of *, would
-receive the following response from C.ISI.EDU:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
-               +---------------------------------------------------+
-    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
-               +---------------------------------------------------+
-    Answer     | SRI-NIC.ARPA. 86400 IN  A     26.0.0.73           |
-               |                         A     10.0.0.51           |
-               |                         MX    0 SRI-NIC.ARPA.     |
-               |                         HINFO DEC-2060 TOPS20     |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 41]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-If a similar query was directed to two name servers which are not
-authoritative for SRI-NIC.ARPA, the responses might be:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE                           |
-               +---------------------------------------------------+
-    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
-               +---------------------------------------------------+
-    Answer     | SRI-NIC.ARPA. 12345 IN     A       26.0.0.73      |
-               |                            A       10.0.0.51      |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-and
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE                           |
-               +---------------------------------------------------+
-    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
-               +---------------------------------------------------+
-    Answer     | SRI-NIC.ARPA. 1290 IN HINFO  DEC-2060 TOPS20      |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-Neither of these answers have AA set, so neither response comes from
-authoritative data.  The different contents and different TTLs suggest
-that the two servers cached data at different times, and that the first
-server cached the response to a QTYPE=A query and the second cached the
-response to a HINFO query.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 42]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-6.2.3. QNAME=SRI-NIC.ARPA, QTYPE=MX
-
-This type of query might be result from a mailer trying to look up
-routing information for the mail destination HOSTMASTER@SRI-NIC.ARPA.
-The response from C.ISI.EDU would be:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
-               +---------------------------------------------------+
-    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=MX          |
-               +---------------------------------------------------+
-    Answer     | SRI-NIC.ARPA. 86400 IN     MX      0 SRI-NIC.ARPA.|
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | SRI-NIC.ARPA. 86400 IN     A       26.0.0.73      |
-               |                            A       10.0.0.51      |
-               +---------------------------------------------------+
-
-This response contains the MX RR in the answer section of the response.
-The additional section contains the address RRs because the name server
-at C.ISI.EDU guesses that the requester will need the addresses in order
-to properly use the information carried by the MX.
-
-6.2.4. QNAME=SRI-NIC.ARPA, QTYPE=NS
-
-C.ISI.EDU would reply to this query with:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
-               +---------------------------------------------------+
-    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=NS          |
-               +---------------------------------------------------+
-    Answer     | <empty>                                           |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-The only difference between the response and the query is the AA and
-RESPONSE bits in the header.  The interpretation of this response is
-that the server is authoritative for the name, and the name exists, but
-no RRs of type NS are present there.
-
-6.2.5. QNAME=SIR-NIC.ARPA, QTYPE=A
-
-If a user mistyped a host name, we might see this type of query.
-
-
-
-Mockapetris                                                    [Page 43]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-C.ISI.EDU would answer it with:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA, RCODE=NE             |
-               +---------------------------------------------------+
-    Question   | QNAME=SIR-NIC.ARPA., QCLASS=IN, QTYPE=A           |
-               +---------------------------------------------------+
-    Answer     | <empty>                                           |
-               +---------------------------------------------------+
-    Authority  | . SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA.      |
-               |       870611 1800 300 604800 86400                |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-This response states that the name does not exist.  This condition is
-signalled in the response code (RCODE) section of the header.
-
-The SOA RR in the authority section is the optional negative caching
-information which allows the resolver using this response to assume that
-the name will not exist for the SOA MINIMUM (86400) seconds.
-
-6.2.6. QNAME=BRL.MIL, QTYPE=A
-
-If this query is sent to C.ISI.EDU, the reply would be:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE                           |
-               +---------------------------------------------------+
-    Question   | QNAME=BRL.MIL, QCLASS=IN, QTYPE=A                 |
-               +---------------------------------------------------+
-    Answer     | <empty>                                           |
-               +---------------------------------------------------+
-    Authority  | MIL.             86400 IN NS       SRI-NIC.ARPA.  |
-               |                  86400    NS       A.ISI.EDU.     |
-               +---------------------------------------------------+
-    Additional | A.ISI.EDU.                A        26.3.0.103     |
-               | SRI-NIC.ARPA.             A        26.0.0.73      |
-               |                           A        10.0.0.51      |
-               +---------------------------------------------------+
-
-This response has an empty answer section, but is not authoritative, so
-it is a referral.  The name server on C.ISI.EDU, realizing that it is
-not authoritative for the MIL domain, has referred the requester to
-servers on A.ISI.EDU and SRI-NIC.ARPA, which it knows are authoritative
-for the MIL domain.
-
-
-
-
-
-Mockapetris                                                    [Page 44]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-6.2.7. QNAME=USC-ISIC.ARPA, QTYPE=A
-
-The response to this query from A.ISI.EDU would be:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
-               +---------------------------------------------------+
-    Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
-               +---------------------------------------------------+
-    Answer     | USC-ISIC.ARPA. 86400 IN CNAME      C.ISI.EDU.     |
-               | C.ISI.EDU.     86400 IN A          10.0.0.52      |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-Note that the AA bit in the header guarantees that the data matching
-QNAME is authoritative, but does not say anything about whether the data
-for C.ISI.EDU is authoritative.  This complete reply is possible because
-A.ISI.EDU happens to be authoritative for both the ARPA domain where
-USC-ISIC.ARPA is found and the ISI.EDU domain where C.ISI.EDU data is
-found.
-
-If the same query was sent to C.ISI.EDU, its response might be the same
-as shown above if it had its own address in its cache, but might also
-be:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 45]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
-               +---------------------------------------------------+
-    Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
-               +---------------------------------------------------+
-    Answer     | USC-ISIC.ARPA.   86400 IN CNAME   C.ISI.EDU.      |
-               +---------------------------------------------------+
-    Authority  | ISI.EDU.        172800 IN NS      VAXA.ISI.EDU.   |
-               |                           NS      A.ISI.EDU.      |
-               |                           NS      VENERA.ISI.EDU. |
-               +---------------------------------------------------+
-    Additional | VAXA.ISI.EDU.   172800    A       10.2.0.27       |
-               |                 172800    A       128.9.0.33      |
-               | VENERA.ISI.EDU. 172800    A       10.1.0.52       |
-               |                 172800    A       128.9.0.32      |
-               | A.ISI.EDU.      172800    A       26.3.0.103      |
-               +---------------------------------------------------+
-
-This reply contains an authoritative reply for the alias USC-ISIC.ARPA,
-plus a referral to the name servers for ISI.EDU.  This sort of reply
-isn't very likely given that the query is for the host name of the name
-server being asked, but would be common for other aliases.
-
-6.2.8. QNAME=USC-ISIC.ARPA, QTYPE=CNAME
-
-If this query is sent to either A.ISI.EDU or C.ISI.EDU, the reply would
-be:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
-               +---------------------------------------------------+
-    Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
-               +---------------------------------------------------+
-    Answer     | USC-ISIC.ARPA. 86400 IN CNAME      C.ISI.EDU.     |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-Because QTYPE=CNAME, the CNAME RR itself answers the query, and the name
-server doesn't attempt to look up anything for C.ISI.EDU.  (Except
-possibly for the additional section.)
-
-6.3. Example resolution
-
-The following examples illustrate the operations a resolver must perform
-for its client.  We assume that the resolver is starting without a
-
-
-
-Mockapetris                                                    [Page 46]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-cache, as might be the case after system boot.  We further assume that
-the system is not one of the hosts in the data and that the host is
-located somewhere on net 26, and that its safety belt (SBELT) data
-structure has the following information:
-
-    Match count = -1
-    SRI-NIC.ARPA.   26.0.0.73       10.0.0.51
-    A.ISI.EDU.      26.3.0.103
-
-This information specifies servers to try, their addresses, and a match
-count of -1, which says that the servers aren't very close to the
-target.  Note that the -1 isn't supposed to be an accurate closeness
-measure, just a value so that later stages of the algorithm will work.
-
-The following examples illustrate the use of a cache, so each example
-assumes that previous requests have completed.
-
-6.3.1. Resolve MX for ISI.EDU.
-
-Suppose the first request to the resolver comes from the local mailer,
-which has mail for PVM@ISI.EDU.  The mailer might then ask for type MX
-RRs for the domain name ISI.EDU.
-
-The resolver would look in its cache for MX RRs at ISI.EDU, but the
-empty cache wouldn't be helpful.  The resolver would recognize that it
-needed to query foreign servers and try to determine the best servers to
-query.  This search would look for NS RRs for the domains ISI.EDU, EDU,
-and the root.  These searches of the cache would also fail.  As a last
-resort, the resolver would use the information from the SBELT, copying
-it into its SLIST structure.
-
-At this point the resolver would need to pick one of the three available
-addresses to try.  Given that the resolver is on net 26, it should
-choose either 26.0.0.73 or 26.3.0.103 as its first choice.  It would
-then send off a query of the form:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 47]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY                                     |
-               +---------------------------------------------------+
-    Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
-               +---------------------------------------------------+
-    Answer     | <empty>                                           |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-The resolver would then wait for a response to its query or a timeout.
-If the timeout occurs, it would try different servers, then different
-addresses of the same servers, lastly retrying addresses already tried.
-It might eventually receive a reply from SRI-NIC.ARPA:
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE                           |
-               +---------------------------------------------------+
-    Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
-               +---------------------------------------------------+
-    Answer     | <empty>                                           |
-               +---------------------------------------------------+
-    Authority  | ISI.EDU.        172800 IN NS       VAXA.ISI.EDU.  |
-               |                           NS       A.ISI.EDU.     |
-               |                           NS       VENERA.ISI.EDU.|
-               +---------------------------------------------------+
-    Additional | VAXA.ISI.EDU.   172800    A        10.2.0.27      |
-               |                 172800    A        128.9.0.33     |
-               | VENERA.ISI.EDU. 172800    A        10.1.0.52      |
-               |                 172800    A        128.9.0.32     |
-               | A.ISI.EDU.      172800    A        26.3.0.103     |
-               +---------------------------------------------------+
-
-The resolver would notice that the information in the response gave a
-closer delegation to ISI.EDU than its existing SLIST (since it matches
-three labels).  The resolver would then cache the information in this
-response and use it to set up a new SLIST:
-
-    Match count = 3
-    A.ISI.EDU.      26.3.0.103
-    VAXA.ISI.EDU.   10.2.0.27       128.9.0.33
-    VENERA.ISI.EDU. 10.1.0.52       128.9.0.32
-
-A.ISI.EDU appears on this list as well as the previous one, but that is
-purely coincidental.  The resolver would again start transmitting and
-waiting for responses.  Eventually it would get an answer:
-
-
-
-Mockapetris                                                    [Page 48]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
-               +---------------------------------------------------+
-    Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
-               +---------------------------------------------------+
-    Answer     | ISI.EDU.                MX 10 VENERA.ISI.EDU.     |
-               |                         MX 20 VAXA.ISI.EDU.       |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | VAXA.ISI.EDU.   172800  A  10.2.0.27              |
-               |                 172800  A  128.9.0.33             |
-               | VENERA.ISI.EDU. 172800  A  10.1.0.52              |
-               |                 172800  A  128.9.0.32             |
-               +---------------------------------------------------+
-
-The resolver would add this information to its cache, and return the MX
-RRs to its client.
-
-6.3.2. Get the host name for address 26.6.0.65
-
-The resolver would translate this into a request for PTR RRs for
-65.0.6.26.IN-ADDR.ARPA.  This information is not in the cache, so the
-resolver would look for foreign servers to ask.  No servers would match,
-so it would use SBELT again.  (Note that the servers for the ISI.EDU
-domain are in the cache, but ISI.EDU is not an ancestor of
-65.0.6.26.IN-ADDR.ARPA, so the SBELT is used.)
-
-Since this request is within the authoritative data of both servers in
-SBELT, eventually one would return:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 49]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-               +---------------------------------------------------+
-    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
-               +---------------------------------------------------+
-    Question   | QNAME=65.0.6.26.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=PTR |
-               +---------------------------------------------------+
-    Answer     | 65.0.6.26.IN-ADDR.ARPA.    PTR     ACC.ARPA.      |
-               +---------------------------------------------------+
-    Authority  | <empty>                                           |
-               +---------------------------------------------------+
-    Additional | <empty>                                           |
-               +---------------------------------------------------+
-
-6.3.3. Get the host address of poneria.ISI.EDU
-
-This request would translate into a type A request for poneria.ISI.EDU.
-The resolver would not find any cached data for this name, but would
-find the NS RRs in the cache for ISI.EDU when it looks for foreign
-servers to ask.  Using this data, it would construct a SLIST of the
-form:
-
-    Match count = 3
-
-    A.ISI.EDU.      26.3.0.103
-    VAXA.ISI.EDU.   10.2.0.27       128.9.0.33
-    VENERA.ISI.EDU. 10.1.0.52
-
-A.ISI.EDU is listed first on the assumption that the resolver orders its
-choices by preference, and A.ISI.EDU is on the same network.
-
-One of these servers would answer the query.
-
-7. REFERENCES and BIBLIOGRAPHY
-
-[Dyer 87]       Dyer, S., and F. Hsu, "Hesiod", Project Athena
-                Technical Plan - Name Service, April 1987, version 1.9.
-
-                Describes the fundamentals of the Hesiod name service.
-
-[IEN-116]       J. Postel, "Internet Name Server", IEN-116,
-                USC/Information Sciences Institute, August 1979.
-
-                A name service obsoleted by the Domain Name System, but
-                still in use.
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 50]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-[Quarterman 86] Quarterman, J., and J. Hoskins, "Notable Computer
-                Networks",Communications of the ACM, October 1986,
-                volume 29, number 10.
-
-[RFC-742]       K. Harrenstien, "NAME/FINGER", RFC-742, Network
-                Information Center, SRI International, December 1977.
-
-[RFC-768]       J. Postel, "User Datagram Protocol", RFC-768,
-                USC/Information Sciences Institute, August 1980.
-
-[RFC-793]       J. Postel, "Transmission Control Protocol", RFC-793,
-                USC/Information Sciences Institute, September 1981.
-
-[RFC-799]       D. Mills, "Internet Name Domains", RFC-799, COMSAT,
-                September 1981.
-
-                Suggests introduction of a hierarchy in place of a flat
-                name space for the Internet.
-
-[RFC-805]       J. Postel, "Computer Mail Meeting Notes", RFC-805,
-                USC/Information Sciences Institute, February 1982.
-
-[RFC-810]       E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
-                Internet Host Table Specification", RFC-810, Network
-                Information Center, SRI International, March 1982.
-
-                Obsolete.  See RFC-952.
-
-[RFC-811]       K. Harrenstien, V. White, and E. Feinler, "Hostnames
-                Server", RFC-811, Network Information Center, SRI
-                International, March 1982.
-
-                Obsolete.  See RFC-953.
-
-[RFC-812]       K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
-                Network Information Center, SRI International, March
-                1982.
-
-[RFC-819]       Z. Su, and J. Postel, "The Domain Naming Convention for
-                Internet User Applications", RFC-819, Network
-                Information Center, SRI International, August 1982.
-
-                Early thoughts on the design of the domain system.
-                Current implementation is completely different.
-
-[RFC-821]       J. Postel, "Simple Mail Transfer Protocol", RFC-821,
-                USC/Information Sciences Institute, August 1980.
-
-
-
-
-Mockapetris                                                    [Page 51]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-[RFC-830]       Z. Su, "A Distributed System for Internet Name Service",
-                RFC-830, Network Information Center, SRI International,
-                October 1982.
-
-                Early thoughts on the design of the domain system.
-                Current implementation is completely different.
-
-[RFC-882]       P. Mockapetris, "Domain names - Concepts and
-                Facilities," RFC-882, USC/Information Sciences
-                Institute, November 1983.
-
-                Superceeded by this memo.
-
-[RFC-883]       P. Mockapetris, "Domain names - Implementation and
-                Specification," RFC-883, USC/Information Sciences
-                Institute, November 1983.
-
-                Superceeded by this memo.
-
-[RFC-920]       J. Postel and J. Reynolds, "Domain Requirements",
-                RFC-920, USC/Information Sciences Institute
-                October 1984.
-
-                Explains the naming scheme for top level domains.
-
-[RFC-952]       K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host
-                Table Specification", RFC-952, SRI, October 1985.
-
-                Specifies the format of HOSTS.TXT, the host/address
-                table replaced by the DNS.
-
-[RFC-953]       K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
-                RFC-953, SRI, October 1985.
-
-                This RFC contains the official specification of the
-                hostname server protocol, which is obsoleted by the DNS.
-                This TCP based protocol accesses information stored in
-                the RFC-952 format, and is used to obtain copies of the
-                host table.
-
-[RFC-973]       P. Mockapetris, "Domain System Changes and
-                Observations", RFC-973, USC/Information Sciences
-                Institute, January 1986.
-
-                Describes changes to RFC-882 and RFC-883 and reasons for
-                them.  Now obsolete.
-
-
-
-
-
-Mockapetris                                                    [Page 52]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-[RFC-974]       C. Partridge, "Mail routing and the domain system",
-                RFC-974, CSNET CIC BBN Labs, January 1986.
-
-                Describes the transition from HOSTS.TXT based mail
-                addressing to the more powerful MX system used with the
-                domain system.
-
-[RFC-1001]      NetBIOS Working Group, "Protocol standard for a NetBIOS
-                service on a TCP/UDP transport: Concepts and Methods",
-                RFC-1001, March 1987.
-
-                This RFC and RFC-1002 are a preliminary design for
-                NETBIOS on top of TCP/IP which proposes to base NetBIOS
-                name service on top of the DNS.
-
-[RFC-1002]      NetBIOS Working Group, "Protocol standard for a NetBIOS
-                service on a TCP/UDP transport: Detailed
-                Specifications", RFC-1002, March 1987.
-
-[RFC-1010]      J. Reynolds and J. Postel, "Assigned Numbers", RFC-1010,
-                USC/Information Sciences Institute, May 1987
-
-                Contains socket numbers and mnemonics for host names,
-                operating systems, etc.
-
-[RFC-1031]      W. Lazear, "MILNET Name Domain Transition", RFC-1031,
-                November 1987.
-
-                Describes a plan for converting the MILNET to the DNS.
-
-[RFC-1032]      M. K. Stahl, "Establishing a Domain - Guidelines for
-                Administrators", RFC-1032, November 1987.
-
-                Describes the registration policies used by the NIC to
-                administer the top level domains and delegate subzones.
-
-[RFC-1033]      M. K. Lottor, "Domain Administrators Operations Guide",
-                RFC-1033, November 1987.
-
-                A cookbook for domain administrators.
-
-[Solomon 82]    M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
-                Name Server", Computer Networks, vol 6, nr 3, July 1982.
-
-                Describes a name service for CSNET which is independent
-                from the DNS and DNS use in the CSNET.
-
-
-
-
-
-Mockapetris                                                    [Page 53]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-Index
-
-          A   12
-          Absolute names   8
-          Aliases   14, 31
-          Authority   6
-          AXFR   17
-
-          Case of characters   7
-          CH   12
-          CNAME   12, 13, 31
-          Completion queries   18
-
-          Domain name   6, 7
-
-          Glue RRs   20
-
-          HINFO   12
-
-          IN   12
-          Inverse queries   16
-          Iterative   4
-
-          Label   7
-
-          Mailbox names   9
-          MX   12
-
-          Name error   27, 36
-          Name servers   5, 17
-          NE   30
-          Negative caching   44
-          NS   12
-
-          Opcode   16
-
-          PTR   12
-
-          QCLASS   16
-          QTYPE   16
-
-          RDATA   13
-          Recursive   4
-          Recursive service   22
-          Relative names   7
-          Resolvers   6
-          RR   12
-
-
-
-
-Mockapetris                                                    [Page 54]
-
-RFC 1034             Domain Concepts and Facilities        November 1987
-
-
-          Safety belt   33
-          Sections   16
-          SOA   12
-          Standard queries   22
-
-          Status queries   18
-          Stub resolvers   32
-
-          TTL   12, 13
-
-          Wildcards   25
-
-          Zone transfers   28
-          Zones   19
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 55]
-
diff --git a/contrib/bind9/doc/rfc/rfc1035.txt b/contrib/bind9/doc/rfc/rfc1035.txt
deleted file mode 100644
index b1a9bf5..0000000
--- a/contrib/bind9/doc/rfc/rfc1035.txt
+++ /dev/null
@@ -1,3077 +0,0 @@
-Network Working Group                                     P. Mockapetris
-Request for Comments: 1035                                           ISI
-                                                           November 1987
-Obsoletes: RFCs 882, 883, 973
-
-            DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
-
-
-1. STATUS OF THIS MEMO
-
-This RFC describes the details of the domain system and protocol, and
-assumes that the reader is familiar with the concepts discussed in a
-companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034].
-
-The domain system is a mixture of functions and data types which are an
-official protocol and functions and data types which are still
-experimental.  Since the domain system is intentionally extensible, new
-data types and experimental behavior should always be expected in parts
-of the system beyond the official protocol.  The official protocol parts
-include standard queries, responses and the Internet class RR data
-formats (e.g., host addresses).  Since the previous RFC set, several
-definitions have changed, so some previous definitions are obsolete.
-
-Experimental or obsolete features are clearly marked in these RFCs, and
-such information should be used with caution.
-
-The reader is especially cautioned not to depend on the values which
-appear in examples to be current or complete, since their purpose is
-primarily pedagogical.  Distribution of this memo is unlimited.
-
-                           Table of Contents
-
-  1. STATUS OF THIS MEMO                                              1
-  2. INTRODUCTION                                                     3
-      2.1. Overview                                                   3
-      2.2. Common configurations                                      4
-      2.3. Conventions                                                7
-          2.3.1. Preferred name syntax                                7
-          2.3.2. Data Transmission Order                              8
-          2.3.3. Character Case                                       9
-          2.3.4. Size limits                                         10
-  3. DOMAIN NAME SPACE AND RR DEFINITIONS                            10
-      3.1. Name space definitions                                    10
-      3.2. RR definitions                                            11
-          3.2.1. Format                                              11
-          3.2.2. TYPE values                                         12
-          3.2.3. QTYPE values                                        12
-          3.2.4. CLASS values                                        13
-
-
-
-Mockapetris                                                     [Page 1]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-          3.2.5. QCLASS values                                       13
-      3.3. Standard RRs                                              13
-          3.3.1. CNAME RDATA format                                  14
-          3.3.2. HINFO RDATA format                                  14
-          3.3.3. MB RDATA format (EXPERIMENTAL)                      14
-          3.3.4. MD RDATA format (Obsolete)                          15
-          3.3.5. MF RDATA format (Obsolete)                          15
-          3.3.6. MG RDATA format (EXPERIMENTAL)                      16
-          3.3.7. MINFO RDATA format (EXPERIMENTAL)                   16
-          3.3.8. MR RDATA format (EXPERIMENTAL)                      17
-          3.3.9. MX RDATA format                                     17
-          3.3.10. NULL RDATA format (EXPERIMENTAL)                   17
-          3.3.11. NS RDATA format                                    18
-          3.3.12. PTR RDATA format                                   18
-          3.3.13. SOA RDATA format                                   19
-          3.3.14. TXT RDATA format                                   20
-      3.4. ARPA Internet specific RRs                                20
-          3.4.1. A RDATA format                                      20
-          3.4.2. WKS RDATA format                                    21
-      3.5. IN-ADDR.ARPA domain                                       22
-      3.6. Defining new types, classes, and special namespaces       24
-  4. MESSAGES                                                        25
-      4.1. Format                                                    25
-          4.1.1. Header section format                               26
-          4.1.2. Question section format                             28
-          4.1.3. Resource record format                              29
-          4.1.4. Message compression                                 30
-      4.2. Transport                                                 32
-          4.2.1. UDP usage                                           32
-          4.2.2. TCP usage                                           32
-  5. MASTER FILES                                                    33
-      5.1. Format                                                    33
-      5.2. Use of master files to define zones                       35
-      5.3. Master file example                                       36
-  6. NAME SERVER IMPLEMENTATION                                      37
-      6.1. Architecture                                              37
-          6.1.1. Control                                             37
-          6.1.2. Database                                            37
-          6.1.3. Time                                                39
-      6.2. Standard query processing                                 39
-      6.3. Zone refresh and reload processing                        39
-      6.4. Inverse queries (Optional)                                40
-          6.4.1. The contents of inverse queries and responses       40
-          6.4.2. Inverse query and response example                  41
-          6.4.3. Inverse query processing                            42
-
-
-
-
-
-
-Mockapetris                                                     [Page 2]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-      6.5. Completion queries and responses                          42
-  7. RESOLVER IMPLEMENTATION                                         43
-      7.1. Transforming a user request into a query                  43
-      7.2. Sending the queries                                       44
-      7.3. Processing responses                                      46
-      7.4. Using the cache                                           47
-  8. MAIL SUPPORT                                                    47
-      8.1. Mail exchange binding                                     48
-      8.2. Mailbox binding (Experimental)                            48
-  9. REFERENCES and BIBLIOGRAPHY                                     50
-  Index                                                              54
-
-2. INTRODUCTION
-
-2.1. Overview
-
-The goal of domain names is to provide a mechanism for naming resources
-in such a way that the names are usable in different hosts, networks,
-protocol families, internets, and administrative organizations.
-
-From the user's point of view, domain names are useful as arguments to a
-local agent, called a resolver, which retrieves information associated
-with the domain name.  Thus a user might ask for the host address or
-mail information associated with a particular domain name.  To enable
-the user to request a particular type of information, an appropriate
-query type is passed to the resolver with the domain name.  To the user,
-the domain tree is a single information space; the resolver is
-responsible for hiding the distribution of data among name servers from
-the user.
-
-From the resolver's point of view, the database that makes up the domain
-space is distributed among various name servers.  Different parts of the
-domain space are stored in different name servers, although a particular
-data item will be stored redundantly in two or more name servers.  The
-resolver starts with knowledge of at least one name server.  When the
-resolver processes a user query it asks a known name server for the
-information; in return, the resolver either receives the desired
-information or a referral to another name server.  Using these
-referrals, resolvers learn the identities and contents of other name
-servers.  Resolvers are responsible for dealing with the distribution of
-the domain space and dealing with the effects of name server failure by
-consulting redundant databases in other servers.
-
-Name servers manage two kinds of data.  The first kind of data held in
-sets called zones; each zone is the complete database for a particular
-"pruned" subtree of the domain space.  This data is called
-authoritative.  A name server periodically checks to make sure that its
-zones are up to date, and if not, obtains a new copy of updated zones
-
-
-
-Mockapetris                                                     [Page 3]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-from master files stored locally or in another name server.  The second
-kind of data is cached data which was acquired by a local resolver.
-This data may be incomplete, but improves the performance of the
-retrieval process when non-local data is repeatedly accessed.  Cached
-data is eventually discarded by a timeout mechanism.
-
-This functional structure isolates the problems of user interface,
-failure recovery, and distribution in the resolvers and isolates the
-database update and refresh problems in the name servers.
-
-2.2. Common configurations
-
-A host can participate in the domain name system in a number of ways,
-depending on whether the host runs programs that retrieve information
-from the domain system, name servers that answer queries from other
-hosts, or various combinations of both functions.  The simplest, and
-perhaps most typical, configuration is shown below:
-
-                 Local Host                        |  Foreign
-                                                   |
-    +---------+               +----------+         |  +--------+
-    |         | user queries  |          |queries  |  |        |
-    |  User   |-------------->|          |---------|->|Foreign |
-    | Program |               | Resolver |         |  |  Name  |
-    |         |<--------------|          |<--------|--| Server |
-    |         | user responses|          |responses|  |        |
-    +---------+               +----------+         |  +--------+
-                                |     A            |
-                cache additions |     | references |
-                                V     |            |
-                              +----------+         |
-                              |  cache   |         |
-                              +----------+         |
-
-User programs interact with the domain name space through resolvers; the
-format of user queries and user responses is specific to the host and
-its operating system.  User queries will typically be operating system
-calls, and the resolver and its cache will be part of the host operating
-system.  Less capable hosts may choose to implement the resolver as a
-subroutine to be linked in with every program that needs its services.
-Resolvers answer user queries with information they acquire via queries
-to foreign name servers and the local cache.
-
-Note that the resolver may have to make several queries to several
-different foreign name servers to answer a particular user query, and
-hence the resolution of a user query may involve several network
-accesses and an arbitrary amount of time.  The queries to foreign name
-servers and the corresponding responses have a standard format described
-
-
-
-Mockapetris                                                     [Page 4]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-in this memo, and may be datagrams.
-
-Depending on its capabilities, a name server could be a stand alone
-program on a dedicated machine or a process or processes on a large
-timeshared host.  A simple configuration might be:
-
-                 Local Host                        |  Foreign
-                                                   |
-      +---------+                                  |
-     /         /|                                  |
-    +---------+ |             +----------+         |  +--------+
-    |         | |             |          |responses|  |        |
-    |         | |             |   Name   |---------|->|Foreign |
-    |  Master |-------------->|  Server  |         |  |Resolver|
-    |  files  | |             |          |<--------|--|        |
-    |         |/              |          | queries |  +--------+
-    +---------+               +----------+         |
-
-Here a primary name server acquires information about one or more zones
-by reading master files from its local file system, and answers queries
-about those zones that arrive from foreign resolvers.
-
-The DNS requires that all zones be redundantly supported by more than
-one name server.  Designated secondary servers can acquire zones and
-check for updates from the primary server using the zone transfer
-protocol of the DNS.  This configuration is shown below:
-
-                 Local Host                        |  Foreign
-                                                   |
-      +---------+                                  |
-     /         /|                                  |
-    +---------+ |             +----------+         |  +--------+
-    |         | |             |          |responses|  |        |
-    |         | |             |   Name   |---------|->|Foreign |
-    |  Master |-------------->|  Server  |         |  |Resolver|
-    |  files  | |             |          |<--------|--|        |
-    |         |/              |          | queries |  +--------+
-    +---------+               +----------+         |
-                                A     |maintenance |  +--------+
-                                |     +------------|->|        |
-                                |      queries     |  |Foreign |
-                                |                  |  |  Name  |
-                                +------------------|--| Server |
-                             maintenance responses |  +--------+
-
-In this configuration, the name server periodically establishes a
-virtual circuit to a foreign name server to acquire a copy of a zone or
-to check that an existing copy has not changed.  The messages sent for
-
-
-
-Mockapetris                                                     [Page 5]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-these maintenance activities follow the same form as queries and
-responses, but the message sequences are somewhat different.
-
-The information flow in a host that supports all aspects of the domain
-name system is shown below:
-
-                 Local Host                        |  Foreign
-                                                   |
-    +---------+               +----------+         |  +--------+
-    |         | user queries  |          |queries  |  |        |
-    |  User   |-------------->|          |---------|->|Foreign |
-    | Program |               | Resolver |         |  |  Name  |
-    |         |<--------------|          |<--------|--| Server |
-    |         | user responses|          |responses|  |        |
-    +---------+               +----------+         |  +--------+
-                                |     A            |
-                cache additions |     | references |
-                                V     |            |
-                              +----------+         |
-                              |  Shared  |         |
-                              | database |         |
-                              +----------+         |
-                                A     |            |
-      +---------+     refreshes |     | references |
-     /         /|               |     V            |
-    +---------+ |             +----------+         |  +--------+
-    |         | |             |          |responses|  |        |
-    |         | |             |   Name   |---------|->|Foreign |
-    |  Master |-------------->|  Server  |         |  |Resolver|
-    |  files  | |             |          |<--------|--|        |
-    |         |/              |          | queries |  +--------+
-    +---------+               +----------+         |
-                                A     |maintenance |  +--------+
-                                |     +------------|->|        |
-                                |      queries     |  |Foreign |
-                                |                  |  |  Name  |
-                                +------------------|--| Server |
-                             maintenance responses |  +--------+
-
-The shared database holds domain space data for the local name server
-and resolver.  The contents of the shared database will typically be a
-mixture of authoritative data maintained by the periodic refresh
-operations of the name server and cached data from previous resolver
-requests.  The structure of the domain data and the necessity for
-synchronization between name servers and resolvers imply the general
-characteristics of this database, but the actual format is up to the
-local implementor.
-
-
-
-
-Mockapetris                                                     [Page 6]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-Information flow can also be tailored so that a group of hosts act
-together to optimize activities.  Sometimes this is done to offload less
-capable hosts so that they do not have to implement a full resolver.
-This can be appropriate for PCs or hosts which want to minimize the
-amount of new network code which is required.  This scheme can also
-allow a group of hosts can share a small number of caches rather than
-maintaining a large number of separate caches, on the premise that the
-centralized caches will have a higher hit ratio.  In either case,
-resolvers are replaced with stub resolvers which act as front ends to
-resolvers located in a recursive server in one or more name servers
-known to perform that service:
-
-                   Local Hosts                     |  Foreign
-                                                   |
-    +---------+                                    |
-    |         | responses                          |
-    | Stub    |<--------------------+              |
-    | Resolver|                     |              |
-    |         |----------------+    |              |
-    +---------+ recursive      |    |              |
-                queries        |    |              |
-                               V    |              |
-    +---------+ recursive     +----------+         |  +--------+
-    |         | queries       |          |queries  |  |        |
-    | Stub    |-------------->| Recursive|---------|->|Foreign |
-    | Resolver|               | Server   |         |  |  Name  |
-    |         |<--------------|          |<--------|--| Server |
-    +---------+ responses     |          |responses|  |        |
-                              +----------+         |  +--------+
-                              |  Central |         |
-                              |   cache  |         |
-                              +----------+         |
-
-In any case, note that domain components are always replicated for
-reliability whenever possible.
-
-2.3. Conventions
-
-The domain system has several conventions dealing with low-level, but
-fundamental, issues.  While the implementor is free to violate these
-conventions WITHIN HIS OWN SYSTEM, he must observe these conventions in
-ALL behavior observed from other hosts.
-
-2.3.1. Preferred name syntax
-
-The DNS specifications attempt to be as general as possible in the rules
-for constructing domain names.  The idea is that the name of any
-existing object can be expressed as a domain name with minimal changes.
-
-
-
-Mockapetris                                                     [Page 7]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-However, when assigning a domain name for an object, the prudent user
-will select a name which satisfies both the rules of the domain system
-and any existing rules for the object, whether these rules are published
-or implied by existing programs.
-
-For example, when naming a mail domain, the user should satisfy both the
-rules of this memo and those in RFC-822.  When creating a new host name,
-the old rules for HOSTS.TXT should be followed.  This avoids problems
-when old software is converted to use domain names.
-
-The following syntax will result in fewer problems with many
-
-applications that use domain names (e.g., mail, TELNET).
-
-<domain> ::= <subdomain> | " "
-
-<subdomain> ::= <label> | <subdomain> "." <label>
-
-<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
-
-<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
-
-<let-dig-hyp> ::= <let-dig> | "-"
-
-<let-dig> ::= <letter> | <digit>
-
-<letter> ::= any one of the 52 alphabetic characters A through Z in
-upper case and a through z in lower case
-
-<digit> ::= any one of the ten digits 0 through 9
-
-Note that while upper and lower case letters are allowed in domain
-names, no significance is attached to the case.  That is, two names with
-the same spelling but different case are to be treated as if identical.
-
-The labels must follow the rules for ARPANET host names.  They must
-start with a letter, end with a letter or digit, and have as interior
-characters only letters, digits, and hyphen.  There are also some
-restrictions on the length.  Labels must be 63 characters or less.
-
-For example, the following strings identify hosts in the Internet:
-
-A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
-
-2.3.2. Data Transmission Order
-
-The order of transmission of the header and data described in this
-document is resolved to the octet level.  Whenever a diagram shows a
-
-
-
-Mockapetris                                                     [Page 8]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-group of octets, the order of transmission of those octets is the normal
-order in which they are read in English.  For example, in the following
-diagram, the octets are transmitted in the order they are numbered.
-
-     0                   1
-     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |       1       |       2       |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |       3       |       4       |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |       5       |       6       |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-Whenever an octet represents a numeric quantity, the left most bit in
-the diagram is the high order or most significant bit.  That is, the bit
-labeled 0 is the most significant bit.  For example, the following
-diagram represents the value 170 (decimal).
-
-     0 1 2 3 4 5 6 7
-    +-+-+-+-+-+-+-+-+
-    |1 0 1 0 1 0 1 0|
-    +-+-+-+-+-+-+-+-+
-
-Similarly, whenever a multi-octet field represents a numeric quantity
-the left most bit of the whole field is the most significant bit.  When
-a multi-octet quantity is transmitted the most significant octet is
-transmitted first.
-
-2.3.3. Character Case
-
-For all parts of the DNS that are part of the official protocol, all
-comparisons between character strings (e.g., labels, domain names, etc.)
-are done in a case-insensitive manner.  At present, this rule is in
-force throughout the domain system without exception.  However, future
-additions beyond current usage may need to use the full binary octet
-capabilities in names, so attempts to store domain names in 7-bit ASCII
-or use of special bytes to terminate labels, etc., should be avoided.
-
-When data enters the domain system, its original case should be
-preserved whenever possible.  In certain circumstances this cannot be
-done.  For example, if two RRs are stored in a database, one at x.y and
-one at X.Y, they are actually stored at the same place in the database,
-and hence only one casing would be preserved.  The basic rule is that
-case can be discarded only when data is used to define structure in a
-database, and two names are identical when compared in a case
-insensitive manner.
-
-
-
-
-Mockapetris                                                     [Page 9]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-Loss of case sensitive data must be minimized.  Thus while data for x.y
-and X.Y may both be stored under a single location x.y or X.Y, data for
-a.x and B.X would never be stored under A.x, A.X, b.x, or b.X.  In
-general, this preserves the case of the first label of a domain name,
-but forces standardization of interior node labels.
-
-Systems administrators who enter data into the domain database should
-take care to represent the data they supply to the domain system in a
-case-consistent manner if their system is case-sensitive.  The data
-distribution system in the domain system will ensure that consistent
-representations are preserved.
-
-2.3.4. Size limits
-
-Various objects and parameters in the DNS have size limits.  They are
-listed below.  Some could be easily changed, others are more
-fundamental.
-
-labels          63 octets or less
-
-names           255 octets or less
-
-TTL             positive values of a signed 32 bit number.
-
-UDP messages    512 octets or less
-
-3. DOMAIN NAME SPACE AND RR DEFINITIONS
-
-3.1. Name space definitions
-
-Domain names in messages are expressed in terms of a sequence of labels.
-Each label is represented as a one octet length field followed by that
-number of octets.  Since every domain name ends with the null label of
-the root, a domain name is terminated by a length byte of zero.  The
-high order two bits of every length octet must be zero, and the
-remaining six bits of the length field limit the label to 63 octets or
-less.
-
-To simplify implementations, the total length of a domain name (i.e.,
-label octets and label length octets) is restricted to 255 octets or
-less.
-
-Although labels can contain any 8 bit values in octets that make up a
-label, it is strongly recommended that labels follow the preferred
-syntax described elsewhere in this memo, which is compatible with
-existing host naming conventions.  Name servers and resolvers must
-compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII
-with zero parity.  Non-alphabetic codes must match exactly.
-
-
-
-Mockapetris                                                    [Page 10]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-3.2. RR definitions
-
-3.2.1. Format
-
-All RRs have the same top level format shown below:
-
-                                    1  1  1  1  1  1
-      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                                               |
-    /                                               /
-    /                      NAME                     /
-    |                                               |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                      TYPE                     |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                     CLASS                     |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                      TTL                      |
-    |                                               |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                   RDLENGTH                    |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
-    /                     RDATA                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-
-where:
-
-NAME            an owner name, i.e., the name of the node to which this
-                resource record pertains.
-
-TYPE            two octets containing one of the RR TYPE codes.
-
-CLASS           two octets containing one of the RR CLASS codes.
-
-TTL             a 32 bit signed integer that specifies the time interval
-                that the resource record may be cached before the source
-                of the information should again be consulted.  Zero
-                values are interpreted to mean that the RR can only be
-                used for the transaction in progress, and should not be
-                cached.  For example, SOA records are always distributed
-                with a zero TTL to prohibit caching.  Zero values can
-                also be used for extremely volatile data.
-
-RDLENGTH        an unsigned 16 bit integer that specifies the length in
-                octets of the RDATA field.
-
-
-
-Mockapetris                                                    [Page 11]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-RDATA           a variable length string of octets that describes the
-                resource.  The format of this information varies
-                according to the TYPE and CLASS of the resource record.
-
-3.2.2. TYPE values
-
-TYPE fields are used in resource records.  Note that these types are a
-subset of QTYPEs.
-
-TYPE            value and meaning
-
-A               1 a host address
-
-NS              2 an authoritative name server
-
-MD              3 a mail destination (Obsolete - use MX)
-
-MF              4 a mail forwarder (Obsolete - use MX)
-
-CNAME           5 the canonical name for an alias
-
-SOA             6 marks the start of a zone of authority
-
-MB              7 a mailbox domain name (EXPERIMENTAL)
-
-MG              8 a mail group member (EXPERIMENTAL)
-
-MR              9 a mail rename domain name (EXPERIMENTAL)
-
-NULL            10 a null RR (EXPERIMENTAL)
-
-WKS             11 a well known service description
-
-PTR             12 a domain name pointer
-
-HINFO           13 host information
-
-MINFO           14 mailbox or mail list information
-
-MX              15 mail exchange
-
-TXT             16 text strings
-
-3.2.3. QTYPE values
-
-QTYPE fields appear in the question part of a query.  QTYPES are a
-superset of TYPEs, hence all TYPEs are valid QTYPEs.  In addition, the
-following QTYPEs are defined:
-
-
-
-Mockapetris                                                    [Page 12]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-AXFR            252 A request for a transfer of an entire zone
-
-MAILB           253 A request for mailbox-related records (MB, MG or MR)
-
-MAILA           254 A request for mail agent RRs (Obsolete - see MX)
-
-*               255 A request for all records
-
-3.2.4. CLASS values
-
-CLASS fields appear in resource records.  The following CLASS mnemonics
-and values are defined:
-
-IN              1 the Internet
-
-CS              2 the CSNET class (Obsolete - used only for examples in
-                some obsolete RFCs)
-
-CH              3 the CHAOS class
-
-HS              4 Hesiod [Dyer 87]
-
-3.2.5. QCLASS values
-
-QCLASS fields appear in the question section of a query.  QCLASS values
-are a superset of CLASS values; every CLASS is a valid QCLASS.  In
-addition to CLASS values, the following QCLASSes are defined:
-
-*               255 any class
-
-3.3. Standard RRs
-
-The following RR definitions are expected to occur, at least
-potentially, in all classes.  In particular, NS, SOA, CNAME, and PTR
-will be used in all classes, and have the same format in all classes.
-Because their RDATA format is known, all domain names in the RDATA
-section of these RRs may be compressed.
-
-<domain-name> is a domain name represented as a series of labels, and
-terminated by a label with zero length.  <character-string> is a single
-length octet followed by that number of characters.  <character-string>
-is treated as binary information, and can be up to 256 characters in
-length (including the length octet).
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 13]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-3.3.1. CNAME RDATA format
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                     CNAME                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-CNAME           A <domain-name> which specifies the canonical or primary
-                name for the owner.  The owner name is an alias.
-
-CNAME RRs cause no additional section processing, but name servers may
-choose to restart the query at the canonical name in certain cases.  See
-the description of name server logic in [RFC-1034] for details.
-
-3.3.2. HINFO RDATA format
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                      CPU                      /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                       OS                      /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-CPU             A <character-string> which specifies the CPU type.
-
-OS              A <character-string> which specifies the operating
-                system type.
-
-Standard values for CPU and OS can be found in [RFC-1010].
-
-HINFO records are used to acquire general information about a host.  The
-main use is for protocols such as FTP that can use special procedures
-when talking between machines or operating systems of the same type.
-
-3.3.3. MB RDATA format (EXPERIMENTAL)
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   MADNAME                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MADNAME         A <domain-name> which specifies a host which has the
-                specified mailbox.
-
-
-
-Mockapetris                                                    [Page 14]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-MB records cause additional section processing which looks up an A type
-RRs corresponding to MADNAME.
-
-3.3.4. MD RDATA format (Obsolete)
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   MADNAME                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MADNAME         A <domain-name> which specifies a host which has a mail
-                agent for the domain which should be able to deliver
-                mail for the domain.
-
-MD records cause additional section processing which looks up an A type
-record corresponding to MADNAME.
-
-MD is obsolete.  See the definition of MX and [RFC-974] for details of
-the new scheme.  The recommended policy for dealing with MD RRs found in
-a master file is to reject them, or to convert them to MX RRs with a
-preference of 0.
-
-3.3.5. MF RDATA format (Obsolete)
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   MADNAME                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MADNAME         A <domain-name> which specifies a host which has a mail
-                agent for the domain which will accept mail for
-                forwarding to the domain.
-
-MF records cause additional section processing which looks up an A type
-record corresponding to MADNAME.
-
-MF is obsolete.  See the definition of MX and [RFC-974] for details ofw
-the new scheme.  The recommended policy for dealing with MD RRs found in
-a master file is to reject them, or to convert them to MX RRs with a
-preference of 10.
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 15]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-3.3.6. MG RDATA format (EXPERIMENTAL)
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   MGMNAME                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MGMNAME         A <domain-name> which specifies a mailbox which is a
-                member of the mail group specified by the domain name.
-
-MG records cause no additional section processing.
-
-3.3.7. MINFO RDATA format (EXPERIMENTAL)
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                    RMAILBX                    /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                    EMAILBX                    /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-RMAILBX         A <domain-name> which specifies a mailbox which is
-                responsible for the mailing list or mailbox.  If this
-                domain name names the root, the owner of the MINFO RR is
-                responsible for itself.  Note that many existing mailing
-                lists use a mailbox X-request for the RMAILBX field of
-                mailing list X, e.g., Msgroup-request for Msgroup.  This
-                field provides a more general mechanism.
-
-
-EMAILBX         A <domain-name> which specifies a mailbox which is to
-                receive error messages related to the mailing list or
-                mailbox specified by the owner of the MINFO RR (similar
-                to the ERRORS-TO: field which has been proposed).  If
-                this domain name names the root, errors should be
-                returned to the sender of the message.
-
-MINFO records cause no additional section processing.  Although these
-records can be associated with a simple mailbox, they are usually used
-with a mailing list.
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 16]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-3.3.8. MR RDATA format (EXPERIMENTAL)
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   NEWNAME                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-NEWNAME         A <domain-name> which specifies a mailbox which is the
-                proper rename of the specified mailbox.
-
-MR records cause no additional section processing.  The main use for MR
-is as a forwarding entry for a user who has moved to a different
-mailbox.
-
-3.3.9. MX RDATA format
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                  PREFERENCE                   |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   EXCHANGE                    /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-PREFERENCE      A 16 bit integer which specifies the preference given to
-                this RR among others at the same owner.  Lower values
-                are preferred.
-
-EXCHANGE        A <domain-name> which specifies a host willing to act as
-                a mail exchange for the owner name.
-
-MX records cause type A additional section processing for the host
-specified by EXCHANGE.  The use of MX RRs is explained in detail in
-[RFC-974].
-
-3.3.10. NULL RDATA format (EXPERIMENTAL)
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                  <anything>                   /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-Anything at all may be in the RDATA field so long as it is 65535 octets
-or less.
-
-
-
-
-Mockapetris                                                    [Page 17]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-NULL records cause no additional section processing.  NULL RRs are not
-allowed in master files.  NULLs are used as placeholders in some
-experimental extensions of the DNS.
-
-3.3.11. NS RDATA format
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   NSDNAME                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-NSDNAME         A <domain-name> which specifies a host which should be
-                authoritative for the specified class and domain.
-
-NS records cause both the usual additional section processing to locate
-a type A record, and, when used in a referral, a special search of the
-zone in which they reside for glue information.
-
-The NS RR states that the named host should be expected to have a zone
-starting at owner name of the specified class.  Note that the class may
-not indicate the protocol family which should be used to communicate
-with the host, although it is typically a strong hint.  For example,
-hosts which are name servers for either Internet (IN) or Hesiod (HS)
-class information are normally queried using IN class protocols.
-
-3.3.12. PTR RDATA format
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   PTRDNAME                    /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-PTRDNAME        A <domain-name> which points to some location in the
-                domain name space.
-
-PTR records cause no additional section processing.  These RRs are used
-in special domains to point to some other location in the domain space.
-These records are simple data, and don't imply any special processing
-similar to that performed by CNAME, which identifies aliases.  See the
-description of the IN-ADDR.ARPA domain for an example.
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 18]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-3.3.13. SOA RDATA format
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                     MNAME                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                     RNAME                     /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                    SERIAL                     |
-    |                                               |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                    REFRESH                    |
-    |                                               |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                     RETRY                     |
-    |                                               |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                    EXPIRE                     |
-    |                                               |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                    MINIMUM                    |
-    |                                               |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MNAME           The <domain-name> of the name server that was the
-                original or primary source of data for this zone.
-
-RNAME           A <domain-name> which specifies the mailbox of the
-                person responsible for this zone.
-
-SERIAL          The unsigned 32 bit version number of the original copy
-                of the zone.  Zone transfers preserve this value.  This
-                value wraps and should be compared using sequence space
-                arithmetic.
-
-REFRESH         A 32 bit time interval before the zone should be
-                refreshed.
-
-RETRY           A 32 bit time interval that should elapse before a
-                failed refresh should be retried.
-
-EXPIRE          A 32 bit time value that specifies the upper limit on
-                the time interval that can elapse before the zone is no
-                longer authoritative.
-
-
-
-
-
-Mockapetris                                                    [Page 19]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-MINIMUM         The unsigned 32 bit minimum TTL field that should be
-                exported with any RR from this zone.
-
-SOA records cause no additional section processing.
-
-All times are in units of seconds.
-
-Most of these fields are pertinent only for name server maintenance
-operations.  However, MINIMUM is used in all query operations that
-retrieve RRs from a zone.  Whenever a RR is sent in a response to a
-query, the TTL field is set to the maximum of the TTL field from the RR
-and the MINIMUM field in the appropriate SOA.  Thus MINIMUM is a lower
-bound on the TTL field for all RRs in a zone.  Note that this use of
-MINIMUM should occur when the RRs are copied into the response and not
-when the zone is loaded from a master file or via a zone transfer.  The
-reason for this provison is to allow future dynamic update facilities to
-change the SOA RR with known semantics.
-
-
-3.3.14. TXT RDATA format
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   TXT-DATA                    /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-TXT-DATA        One or more <character-string>s.
-
-TXT RRs are used to hold descriptive text.  The semantics of the text
-depends on the domain where it is found.
-
-3.4. Internet specific RRs
-
-3.4.1. A RDATA format
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                    ADDRESS                    |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-ADDRESS         A 32 bit Internet address.
-
-Hosts that have multiple Internet addresses will have multiple A
-records.
-
-
-
-
-
-Mockapetris                                                    [Page 20]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-A records cause no additional section processing.  The RDATA section of
-an A line in a master file is an Internet address expressed as four
-decimal numbers separated by dots without any imbedded spaces (e.g.,
-"10.2.0.52" or "192.0.5.6").
-
-3.4.2. WKS RDATA format
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                    ADDRESS                    |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |       PROTOCOL        |                       |
-    +--+--+--+--+--+--+--+--+                       |
-    |                                               |
-    /                   <BIT MAP>                   /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-ADDRESS         An 32 bit Internet address
-
-PROTOCOL        An 8 bit IP protocol number
-
-<BIT MAP>       A variable length bit map.  The bit map must be a
-                multiple of 8 bits long.
-
-The WKS record is used to describe the well known services supported by
-a particular protocol on a particular internet address.  The PROTOCOL
-field specifies an IP protocol number, and the bit map has one bit per
-port of the specified protocol.  The first bit corresponds to port 0,
-the second to port 1, etc.  If the bit map does not include a bit for a
-protocol of interest, that bit is assumed zero.  The appropriate values
-and mnemonics for ports and protocols are specified in [RFC-1010].
-
-For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP port
-25 (SMTP).  If this bit is set, a SMTP server should be listening on TCP
-port 25; if zero, SMTP service is not supported on the specified
-address.
-
-The purpose of WKS RRs is to provide availability information for
-servers for TCP and UDP.  If a server supports both TCP and UDP, or has
-multiple Internet addresses, then multiple WKS RRs are used.
-
-WKS RRs cause no additional section processing.
-
-In master files, both ports and protocols are expressed using mnemonics
-or decimal numbers.
-
-
-
-
-Mockapetris                                                    [Page 21]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-3.5. IN-ADDR.ARPA domain
-
-The Internet uses a special domain to support gateway location and
-Internet address to host mapping.  Other classes may employ a similar
-strategy in other domains.  The intent of this domain is to provide a
-guaranteed method to perform host address to host name mapping, and to
-facilitate queries to locate all gateways on a particular network in the
-Internet.
-
-Note that both of these services are similar to functions that could be
-performed by inverse queries; the difference is that this part of the
-domain name space is structured according to address, and hence can
-guarantee that the appropriate data can be located without an exhaustive
-search of the domain space.
-
-The domain begins at IN-ADDR.ARPA and has a substructure which follows
-the Internet addressing structure.
-
-Domain names in the IN-ADDR.ARPA domain are defined to have up to four
-labels in addition to the IN-ADDR.ARPA suffix.  Each label represents
-one octet of an Internet address, and is expressed as a character string
-for a decimal value in the range 0-255 (with leading zeros omitted
-except in the case of a zero octet which is represented by a single
-zero).
-
-Host addresses are represented by domain names that have all four labels
-specified.  Thus data for Internet address 10.2.0.52 is located at
-domain name 52.0.2.10.IN-ADDR.ARPA.  The reversal, though awkward to
-read, allows zones to be delegated which are exactly one network of
-address space.  For example, 10.IN-ADDR.ARPA can be a zone containing
-data for the ARPANET, while 26.IN-ADDR.ARPA can be a separate zone for
-MILNET.  Address nodes are used to hold pointers to primary host names
-in the normal domain space.
-
-Network numbers correspond to some non-terminal nodes at various depths
-in the IN-ADDR.ARPA domain, since Internet network numbers are either 1,
-2, or 3 octets.  Network nodes are used to hold pointers to the primary
-host names of gateways attached to that network.  Since a gateway is, by
-definition, on more than one network, it will typically have two or more
-network nodes which point at it.  Gateways will also have host level
-pointers at their fully qualified addresses.
-
-Both the gateway pointers at network nodes and the normal host pointers
-at full address nodes use the PTR RR to point back to the primary domain
-names of the corresponding hosts.
-
-For example, the IN-ADDR.ARPA domain will contain information about the
-ISI gateway between net 10 and 26, an MIT gateway from net 10 to MIT's
-
-
-
-Mockapetris                                                    [Page 22]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-net 18, and hosts A.ISI.EDU and MULTICS.MIT.EDU.  Assuming that ISI
-gateway has addresses 10.2.0.22 and 26.0.0.103, and a name MILNET-
-GW.ISI.EDU, and the MIT gateway has addresses 10.0.0.77 and 18.10.0.4
-and a name GW.LCS.MIT.EDU, the domain database would contain:
-
-    10.IN-ADDR.ARPA.           PTR MILNET-GW.ISI.EDU.
-    10.IN-ADDR.ARPA.           PTR GW.LCS.MIT.EDU.
-    18.IN-ADDR.ARPA.           PTR GW.LCS.MIT.EDU.
-    26.IN-ADDR.ARPA.           PTR MILNET-GW.ISI.EDU.
-    22.0.2.10.IN-ADDR.ARPA.    PTR MILNET-GW.ISI.EDU.
-    103.0.0.26.IN-ADDR.ARPA.   PTR MILNET-GW.ISI.EDU.
-    77.0.0.10.IN-ADDR.ARPA.    PTR GW.LCS.MIT.EDU.
-    4.0.10.18.IN-ADDR.ARPA.    PTR GW.LCS.MIT.EDU.
-    103.0.3.26.IN-ADDR.ARPA.   PTR A.ISI.EDU.
-    6.0.0.10.IN-ADDR.ARPA.     PTR MULTICS.MIT.EDU.
-
-Thus a program which wanted to locate gateways on net 10 would originate
-a query of the form QTYPE=PTR, QCLASS=IN, QNAME=10.IN-ADDR.ARPA.  It
-would receive two RRs in response:
-
-    10.IN-ADDR.ARPA.           PTR MILNET-GW.ISI.EDU.
-    10.IN-ADDR.ARPA.           PTR GW.LCS.MIT.EDU.
-
-The program could then originate QTYPE=A, QCLASS=IN queries for MILNET-
-GW.ISI.EDU. and GW.LCS.MIT.EDU. to discover the Internet addresses of
-these gateways.
-
-A resolver which wanted to find the host name corresponding to Internet
-host address 10.0.0.6 would pursue a query of the form QTYPE=PTR,
-QCLASS=IN, QNAME=6.0.0.10.IN-ADDR.ARPA, and would receive:
-
-    6.0.0.10.IN-ADDR.ARPA.     PTR MULTICS.MIT.EDU.
-
-Several cautions apply to the use of these services:
-   - Since the IN-ADDR.ARPA special domain and the normal domain
-     for a particular host or gateway will be in different zones,
-     the possibility exists that that the data may be inconsistent.
-
-   - Gateways will often have two names in separate domains, only
-     one of which can be primary.
-
-   - Systems that use the domain database to initialize their
-     routing tables must start with enough gateway information to
-     guarantee that they can access the appropriate name server.
-
-   - The gateway data only reflects the existence of a gateway in a
-     manner equivalent to the current HOSTS.TXT file.  It doesn't
-     replace the dynamic availability information from GGP or EGP.
-
-
-
-Mockapetris                                                    [Page 23]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-3.6. Defining new types, classes, and special namespaces
-
-The previously defined types and classes are the ones in use as of the
-date of this memo.  New definitions should be expected.  This section
-makes some recommendations to designers considering additions to the
-existing facilities.  The mailing list NAMEDROPPERS@SRI-NIC.ARPA is the
-forum where general discussion of design issues takes place.
-
-In general, a new type is appropriate when new information is to be
-added to the database about an existing object, or we need new data
-formats for some totally new object.  Designers should attempt to define
-types and their RDATA formats that are generally applicable to all
-classes, and which avoid duplication of information.  New classes are
-appropriate when the DNS is to be used for a new protocol, etc which
-requires new class-specific data formats, or when a copy of the existing
-name space is desired, but a separate management domain is necessary.
-
-New types and classes need mnemonics for master files; the format of the
-master files requires that the mnemonics for type and class be disjoint.
-
-TYPE and CLASS values must be a proper subset of QTYPEs and QCLASSes
-respectively.
-
-The present system uses multiple RRs to represent multiple values of a
-type rather than storing multiple values in the RDATA section of a
-single RR.  This is less efficient for most applications, but does keep
-RRs shorter.  The multiple RRs assumption is incorporated in some
-experimental work on dynamic update methods.
-
-The present system attempts to minimize the duplication of data in the
-database in order to insure consistency.  Thus, in order to find the
-address of the host for a mail exchange, you map the mail domain name to
-a host name, then the host name to addresses, rather than a direct
-mapping to host address.  This approach is preferred because it avoids
-the opportunity for inconsistency.
-
-In defining a new type of data, multiple RR types should not be used to
-create an ordering between entries or express different formats for
-equivalent bindings, instead this information should be carried in the
-body of the RR and a single type used.  This policy avoids problems with
-caching multiple types and defining QTYPEs to match multiple types.
-
-For example, the original form of mail exchange binding used two RR
-types one to represent a "closer" exchange (MD) and one to represent a
-"less close" exchange (MF).  The difficulty is that the presence of one
-RR type in a cache doesn't convey any information about the other
-because the query which acquired the cached information might have used
-a QTYPE of MF, MD, or MAILA (which matched both).  The redesigned
-
-
-
-Mockapetris                                                    [Page 24]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-service used a single type (MX) with a "preference" value in the RDATA
-section which can order different RRs.  However, if any MX RRs are found
-in the cache, then all should be there.
-
-4. MESSAGES
-
-4.1. Format
-
-All communications inside of the domain protocol are carried in a single
-format called a message.  The top level format of message is divided
-into 5 sections (some of which are empty in certain cases) shown below:
-
-    +---------------------+
-    |        Header       |
-    +---------------------+
-    |       Question      | the question for the name server
-    +---------------------+
-    |        Answer       | RRs answering the question
-    +---------------------+
-    |      Authority      | RRs pointing toward an authority
-    +---------------------+
-    |      Additional     | RRs holding additional information
-    +---------------------+
-
-The header section is always present.  The header includes fields that
-specify which of the remaining sections are present, and also specify
-whether the message is a query or a response, a standard query or some
-other opcode, etc.
-
-The names of the sections after the header are derived from their use in
-standard queries.  The question section contains fields that describe a
-question to a name server.  These fields are a query type (QTYPE), a
-query class (QCLASS), and a query domain name (QNAME).  The last three
-sections have the same format: a possibly empty list of concatenated
-resource records (RRs).  The answer section contains RRs that answer the
-question; the authority section contains RRs that point toward an
-authoritative name server; the additional records section contains RRs
-which relate to the query, but are not strictly answers for the
-question.
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 25]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-4.1.1. Header section format
-
-The header contains the following fields:
-
-                                    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  |AA|TC|RD|RA|   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
-                the corresponding reply and can be used by the requester
-                to match up replies to outstanding queries.
-
-QR              A one bit field that specifies whether this message is a
-                query (0), or a response (1).
-
-OPCODE          A four bit field that specifies kind of query in this
-                message.  This value is set by the originator of a query
-                and copied into the response.  The values are:
-
-                0               a standard query (QUERY)
-
-                1               an inverse query (IQUERY)
-
-                2               a server status request (STATUS)
-
-                3-15            reserved for future use
-
-AA              Authoritative Answer - this bit is valid in responses,
-                and specifies that the responding name server is an
-                authority for the domain name in question section.
-
-                Note that the contents of the answer section may have
-                multiple owner names because of aliases.  The AA bit
-
-
-
-Mockapetris                                                    [Page 26]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-                corresponds to the name which matches the query name, or
-                the first owner name in the answer section.
-
-TC              TrunCation - specifies that this message was truncated
-                due to length greater than that permitted on the
-                transmission channel.
-
-RD              Recursion Desired - this bit may be set in a query and
-                is copied into the response.  If RD is set, it directs
-                the name server to pursue the query recursively.
-                Recursive query support is optional.
-
-RA              Recursion Available - this be is set or cleared in a
-                response, and denotes whether recursive query support is
-                available in the name server.
-
-Z               Reserved for future use.  Must be zero in all queries
-                and responses.
-
-RCODE           Response code - this 4 bit field is set as part of
-                responses.  The values have the following
-                interpretation:
-
-                0               No error condition
-
-                1               Format error - The name server was
-                                unable to interpret the query.
-
-                2               Server failure - The name server was
-                                unable to process this query due to a
-                                problem with the name server.
-
-                3               Name Error - Meaningful only for
-                                responses from an authoritative name
-                                server, this code signifies that the
-                                domain name referenced in the query does
-                                not exist.
-
-                4               Not Implemented - The name server does
-                                not support the requested kind of query.
-
-                5               Refused - The name server refuses to
-                                perform the specified operation for
-                                policy reasons.  For example, a name
-                                server may not wish to provide the
-                                information to the particular requester,
-                                or a name server may not wish to perform
-                                a particular operation (e.g., zone
-
-
-
-Mockapetris                                                    [Page 27]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-                                transfer) for particular data.
-
-                6-15            Reserved for future use.
-
-QDCOUNT         an unsigned 16 bit integer specifying the number of
-                entries in the question section.
-
-ANCOUNT         an unsigned 16 bit integer specifying the number of
-                resource records in the answer section.
-
-NSCOUNT         an unsigned 16 bit integer specifying the number of name
-                server resource records in the authority records
-                section.
-
-ARCOUNT         an unsigned 16 bit integer specifying the number of
-                resource records in the additional records section.
-
-4.1.2. Question section format
-
-The question section is used to carry the "question" in most queries,
-i.e., the parameters that define what is being asked.  The section
-contains QDCOUNT (usually 1) entries, each of the following format:
-
-                                    1  1  1  1  1  1
-      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                                               |
-    /                     QNAME                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                     QTYPE                     |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                     QCLASS                    |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-QNAME           a domain name represented as a sequence of labels, where
-                each label consists of a length octet followed by that
-                number of octets.  The domain name terminates with the
-                zero length octet for the null label of the root.  Note
-                that this field may be an odd number of octets; no
-                padding is used.
-
-QTYPE           a two octet code which specifies the type of the query.
-                The values for this field include all codes valid for a
-                TYPE field, together with some more general codes which
-                can match more than one type of RR.
-
-
-
-Mockapetris                                                    [Page 28]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-QCLASS          a two octet code that specifies the class of the query.
-                For example, the QCLASS field is IN for the Internet.
-
-4.1.3. Resource record format
-
-The answer, authority, and additional sections all share the same
-format: a variable number of resource records, where the number of
-records is specified in the corresponding count field in the header.
-Each resource record has the following format:
-                                    1  1  1  1  1  1
-      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                                               |
-    /                                               /
-    /                      NAME                     /
-    |                                               |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                      TYPE                     |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                     CLASS                     |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                      TTL                      |
-    |                                               |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                   RDLENGTH                    |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
-    /                     RDATA                     /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-NAME            a domain name to which this resource record pertains.
-
-TYPE            two octets containing one of the RR type codes.  This
-                field specifies the meaning of the data in the RDATA
-                field.
-
-CLASS           two octets which specify the class of the data in the
-                RDATA field.
-
-TTL             a 32 bit unsigned integer that specifies the time
-                interval (in seconds) that the resource record may be
-                cached before it should be discarded.  Zero values are
-                interpreted to mean that the RR can only be used for the
-                transaction in progress, and should not be cached.
-
-
-
-
-
-Mockapetris                                                    [Page 29]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-RDLENGTH        an unsigned 16 bit integer that specifies the length in
-                octets of the RDATA field.
-
-RDATA           a variable length string of octets that describes the
-                resource.  The format of this information varies
-                according to the TYPE and CLASS of the resource record.
-                For example, the if the TYPE is A and the CLASS is IN,
-                the RDATA field is a 4 octet ARPA Internet address.
-
-4.1.4. Message compression
-
-In order to reduce the size of messages, the domain system utilizes a
-compression scheme which eliminates the repetition of domain names in a
-message.  In this scheme, an entire domain name or a list of labels at
-the end of a domain name is replaced with a pointer to a prior occurance
-of the same name.
-
-The pointer takes the form of a two octet sequence:
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    | 1  1|                OFFSET                   |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-The first two bits are ones.  This allows a pointer to be distinguished
-from a label, since the label must begin with two zero bits because
-labels are restricted to 63 octets or less.  (The 10 and 01 combinations
-are reserved for future use.)  The OFFSET field specifies an offset from
-the start of the message (i.e., the first octet of the ID field in the
-domain header).  A zero offset specifies the first byte of the ID field,
-etc.
-
-The compression scheme allows a domain name in a message to be
-represented as either:
-
-   - a sequence of labels ending in a zero octet
-
-   - a pointer
-
-   - a sequence of labels ending with a pointer
-
-Pointers can only be used for occurances of a domain name where the
-format is not class specific.  If this were not the case, a name server
-or resolver would be required to know the format of all RRs it handled.
-As yet, there are no such cases, but they may occur in future RDATA
-formats.
-
-If a domain name is contained in a part of the message subject to a
-length field (such as the RDATA section of an RR), and compression is
-
-
-
-Mockapetris                                                    [Page 30]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-used, the length of the compressed name is used in the length
-calculation, rather than the length of the expanded name.
-
-Programs are free to avoid using pointers in messages they generate,
-although this will reduce datagram capacity, and may cause truncation.
-However all programs are required to understand arriving messages that
-contain pointers.
-
-For example, a datagram might need to use the domain names F.ISI.ARPA,
-FOO.F.ISI.ARPA, ARPA, and the root.  Ignoring the other fields of the
-message, these domain names might be represented as:
-
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    20 |           1           |           F           |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    22 |           3           |           I           |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    24 |           S           |           I           |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    26 |           4           |           A           |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    28 |           R           |           P           |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    30 |           A           |           0           |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    40 |           3           |           F           |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    42 |           O           |           O           |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    44 | 1  1|                20                       |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    64 | 1  1|                26                       |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    92 |           0           |                       |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-The domain name for F.ISI.ARPA is shown at offset 20.  The domain name
-FOO.F.ISI.ARPA is shown at offset 40; this definition uses a pointer to
-concatenate a label for FOO to the previously defined F.ISI.ARPA.  The
-domain name ARPA is defined at offset 64 using a pointer to the ARPA
-component of the name F.ISI.ARPA at 20; note that this pointer relies on
-ARPA being the last label in the string at 20.  The root domain name is
-
-
-
-Mockapetris                                                    [Page 31]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-defined by a single octet of zeros at 92; the root domain name has no
-labels.
-
-4.2. Transport
-
-The DNS assumes that messages will be transmitted as datagrams or in a
-byte stream carried by a virtual circuit.  While virtual circuits can be
-used for any DNS activity, datagrams are preferred for queries due to
-their lower overhead and better performance.  Zone refresh activities
-must use virtual circuits because of the need for reliable transfer.
-
-The Internet supports name server access using TCP [RFC-793] on server
-port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP
-port 53 (decimal).
-
-4.2.1. UDP usage
-
-Messages sent using UDP user server port 53 (decimal).
-
-Messages carried by UDP are restricted to 512 bytes (not counting the IP
-or UDP headers).  Longer messages are truncated and the TC bit is set in
-the header.
-
-UDP is not acceptable for zone transfers, but is the recommended method
-for standard queries in the Internet.  Queries sent using UDP may be
-lost, and hence a retransmission strategy is required.  Queries or their
-responses may be reordered by the network, or by processing in name
-servers, so resolvers should not depend on them being returned in order.
-
-The optimal UDP retransmission policy will vary with performance of the
-Internet and the needs of the client, but the following are recommended:
-
-   - The client should try other servers and server addresses
-     before repeating a query to a specific address of a server.
-
-   - The retransmission interval should be based on prior
-     statistics if possible.  Too aggressive retransmission can
-     easily slow responses for the community at large.  Depending
-     on how well connected the client is to its expected servers,
-     the minimum retransmission interval should be 2-5 seconds.
-
-More suggestions on server selection and retransmission policy can be
-found in the resolver section of this memo.
-
-4.2.2. TCP usage
-
-Messages sent over TCP connections use server port 53 (decimal).  The
-message is prefixed with a two byte length field which gives the message
-
-
-
-Mockapetris                                                    [Page 32]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-length, excluding the two byte length field.  This length field allows
-the low-level processing to assemble a complete message before beginning
-to parse it.
-
-Several connection management policies are recommended:
-
-   - The server should not block other activities waiting for TCP
-     data.
-
-   - The server should support multiple connections.
-
-   - The server should assume that the client will initiate
-     connection closing, and should delay closing its end of the
-     connection until all outstanding client requests have been
-     satisfied.
-
-   - If the server needs to close a dormant connection to reclaim
-     resources, it should wait until the connection has been idle
-     for a period on the order of two minutes.  In particular, the
-     server should allow the SOA and AXFR request sequence (which
-     begins a refresh operation) to be made on a single connection.
-     Since the server would be unable to answer queries anyway, a
-     unilateral close or reset may be used instead of a graceful
-     close.
-
-5. MASTER FILES
-
-Master files are text files that contain RRs in text form.  Since the
-contents of a zone can be expressed in the form of a list of RRs a
-master file is most often used to define a zone, though it can be used
-to list a cache's contents.  Hence, this section first discusses the
-format of RRs in a master file, and then the special considerations when
-a master file is used to create a zone in some name server.
-
-5.1. Format
-
-The format of these files is a sequence of entries.  Entries are
-predominantly line-oriented, though parentheses can be used to continue
-a list of items across a line boundary, and text literals can contain
-CRLF within the text.  Any combination of tabs and spaces act as a
-delimiter between the separate items that make up an entry.  The end of
-any line in the master file can end with a comment.  The comment starts
-with a ";" (semicolon).
-
-The following entries are defined:
-
-    <blank>[<comment>]
-
-
-
-
-Mockapetris                                                    [Page 33]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-    $ORIGIN <domain-name> [<comment>]
-
-    $INCLUDE <file-name> [<domain-name>] [<comment>]
-
-    <domain-name><rr> [<comment>]
-
-    <blank><rr> [<comment>]
-
-Blank lines, with or without comments, are allowed anywhere in the file.
-
-Two control entries are defined: $ORIGIN and $INCLUDE.  $ORIGIN is
-followed by a domain name, and resets the current origin for relative
-domain names to the stated name.  $INCLUDE inserts the named file into
-the current file, and may optionally specify a domain name that sets the
-relative domain name origin for the included file.  $INCLUDE may also
-have a comment.  Note that a $INCLUDE entry never changes the relative
-origin of the parent file, regardless of changes to the relative origin
-made within the included file.
-
-The last two forms represent RRs.  If an entry for an RR begins with a
-blank, then the RR is assumed to be owned by the last stated owner.  If
-an RR entry begins with a <domain-name>, then the owner name is reset.
-
-<rr> contents take one of the following forms:
-
-    [<TTL>] [<class>] <type> <RDATA>
-
-    [<class>] [<TTL>] <type> <RDATA>
-
-The RR begins with optional TTL and class fields, followed by a type and
-RDATA field appropriate to the type and class.  Class and type use the
-standard mnemonics, TTL is a decimal integer.  Omitted class and TTL
-values are default to the last explicitly stated values.  Since type and
-class mnemonics are disjoint, the parse is unique.  (Note that this
-order is different from the order used in examples and the order used in
-the actual RRs; the given order allows easier parsing and defaulting.)
-
-<domain-name>s make up a large share of the data in the master file.
-The labels in the domain name are expressed as character strings and
-separated by dots.  Quoting conventions allow arbitrary characters to be
-stored in domain names.  Domain names that end in a dot are called
-absolute, and are taken as complete.  Domain names which do not end in a
-dot are called relative; the actual domain name is the concatenation of
-the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as
-an argument to the master file loading routine.  A relative name is an
-error when no origin is available.
-
-
-
-
-
-Mockapetris                                                    [Page 34]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-<character-string> is expressed in one or two ways: as a contiguous set
-of characters without interior spaces, or as a string beginning with a "
-and ending with a ".  Inside a " delimited string any character can
-occur, except for a " itself, which must be quoted using \ (back slash).
-
-Because these files are text files several special encodings are
-necessary to allow arbitrary data to be loaded.  In particular:
-
-                of the root.
-
-@               A free standing @ is used to denote the current origin.
-
-\X              where X is any character other than a digit (0-9), is
-                used to quote that character so that its special meaning
-                does not apply.  For example, "\." can be used to place
-                a dot character in a label.
-
-\DDD            where each D is a digit is the octet corresponding to
-                the decimal number described by DDD.  The resulting
-                octet is assumed to be text and is not checked for
-                special meaning.
-
-( )             Parentheses are used to group data that crosses a line
-                boundary.  In effect, line terminations are not
-                recognized within parentheses.
-
-;               Semicolon is used to start a comment; the remainder of
-                the line is ignored.
-
-5.2. Use of master files to define zones
-
-When a master file is used to load a zone, the operation should be
-suppressed if any errors are encountered in the master file.  The
-rationale for this is that a single error can have widespread
-consequences.  For example, suppose that the RRs defining a delegation
-have syntax errors; then the server will return authoritative name
-errors for all names in the subzone (except in the case where the
-subzone is also present on the server).
-
-Several other validity checks that should be performed in addition to
-insuring that the file is syntactically correct:
-
-   1. All RRs in the file should have the same class.
-
-   2. Exactly one SOA RR should be present at the top of the zone.
-
-   3. If delegations are present and glue information is required,
-      it should be present.
-
-
-
-Mockapetris                                                    [Page 35]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-   4. Information present outside of the authoritative nodes in the
-      zone should be glue information, rather than the result of an
-      origin or similar error.
-
-5.3. Master file example
-
-The following is an example file which might be used to define the
-ISI.EDU zone.and is loaded with an origin of ISI.EDU:
-
-@   IN  SOA     VENERA      Action\.domains (
-                                 20     ; SERIAL
-                                 7200   ; REFRESH
-                                 600    ; RETRY
-                                 3600000; EXPIRE
-                                 60)    ; MINIMUM
-
-        NS      A.ISI.EDU.
-        NS      VENERA
-        NS      VAXA
-        MX      10      VENERA
-        MX      20      VAXA
-
-A       A       26.3.0.103
-
-VENERA  A       10.1.0.52
-        A       128.9.0.32
-
-VAXA    A       10.2.0.27
-        A       128.9.0.33
-
-
-$INCLUDE <SUBSYS>ISI-MAILBOXES.TXT
-
-Where the file <SUBSYS>ISI-MAILBOXES.TXT is:
-
-    MOE     MB      A.ISI.EDU.
-    LARRY   MB      A.ISI.EDU.
-    CURLEY  MB      A.ISI.EDU.
-    STOOGES MG      MOE
-            MG      LARRY
-            MG      CURLEY
-
-Note the use of the \ character in the SOA RR to specify the responsible
-person mailbox "Action.domains@E.ISI.EDU".
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 36]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-6. NAME SERVER IMPLEMENTATION
-
-6.1. Architecture
-
-The optimal structure for the name server will depend on the host
-operating system and whether the name server is integrated with resolver
-operations, either by supporting recursive service, or by sharing its
-database with a resolver.  This section discusses implementation
-considerations for a name server which shares a database with a
-resolver, but most of these concerns are present in any name server.
-
-6.1.1. Control
-
-A name server must employ multiple concurrent activities, whether they
-are implemented as separate tasks in the host's OS or multiplexing
-inside a single name server program.  It is simply not acceptable for a
-name server to block the service of UDP requests while it waits for TCP
-data for refreshing or query activities.  Similarly, a name server
-should not attempt to provide recursive service without processing such
-requests in parallel, though it may choose to serialize requests from a
-single client, or to regard identical requests from the same client as
-duplicates.  A name server should not substantially delay requests while
-it reloads a zone from master files or while it incorporates a newly
-refreshed zone into its database.
-
-6.1.2. Database
-
-While name server implementations are free to use any internal data
-structures they choose, the suggested structure consists of three major
-parts:
-
-   - A "catalog" data structure which lists the zones available to
-     this server, and a "pointer" to the zone data structure.  The
-     main purpose of this structure is to find the nearest ancestor
-     zone, if any, for arriving standard queries.
-
-   - Separate data structures for each of the zones held by the
-     name server.
-
-   - A data structure for cached data. (or perhaps separate caches
-     for different classes)
-
-All of these data structures can be implemented an identical tree
-structure format, with different data chained off the nodes in different
-parts: in the catalog the data is pointers to zones, while in the zone
-and cache data structures, the data will be RRs.  In designing the tree
-framework the designer should recognize that query processing will need
-to traverse the tree using case-insensitive label comparisons; and that
-
-
-
-Mockapetris                                                    [Page 37]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-in real data, a few nodes have a very high branching factor (100-1000 or
-more), but the vast majority have a very low branching factor (0-1).
-
-One way to solve the case problem is to store the labels for each node
-in two pieces: a standardized-case representation of the label where all
-ASCII characters are in a single case, together with a bit mask that
-denotes which characters are actually of a different case.  The
-branching factor diversity can be handled using a simple linked list for
-a node until the branching factor exceeds some threshold, and
-transitioning to a hash structure after the threshold is exceeded.  In
-any case, hash structures used to store tree sections must insure that
-hash functions and procedures preserve the casing conventions of the
-DNS.
-
-The use of separate structures for the different parts of the database
-is motivated by several factors:
-
-   - The catalog structure can be an almost static structure that
-     need change only when the system administrator changes the
-     zones supported by the server.  This structure can also be
-     used to store parameters used to control refreshing
-     activities.
-
-   - The individual data structures for zones allow a zone to be
-     replaced simply by changing a pointer in the catalog.  Zone
-     refresh operations can build a new structure and, when
-     complete, splice it into the database via a simple pointer
-     replacement.  It is very important that when a zone is
-     refreshed, queries should not use old and new data
-     simultaneously.
-
-   - With the proper search procedures, authoritative data in zones
-     will always "hide", and hence take precedence over, cached
-     data.
-
-   - Errors in zone definitions that cause overlapping zones, etc.,
-     may cause erroneous responses to queries, but problem
-     determination is simplified, and the contents of one "bad"
-     zone can't corrupt another.
-
-   - Since the cache is most frequently updated, it is most
-     vulnerable to corruption during system restarts.  It can also
-     become full of expired RR data.  In either case, it can easily
-     be discarded without disturbing zone data.
-
-A major aspect of database design is selecting a structure which allows
-the name server to deal with crashes of the name server's host.  State
-information which a name server should save across system crashes
-
-
-
-Mockapetris                                                    [Page 38]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-includes the catalog structure (including the state of refreshing for
-each zone) and the zone data itself.
-
-6.1.3. Time
-
-Both the TTL data for RRs and the timing data for refreshing activities
-depends on 32 bit timers in units of seconds.  Inside the database,
-refresh timers and TTLs for cached data conceptually "count down", while
-data in the zone stays with constant TTLs.
-
-A recommended implementation strategy is to store time in two ways:  as
-a relative increment and as an absolute time.  One way to do this is to
-use positive 32 bit numbers for one type and negative numbers for the
-other.  The RRs in zones use relative times; the refresh timers and
-cache data use absolute times.  Absolute numbers are taken with respect
-to some known origin and converted to relative values when placed in the
-response to a query.  When an absolute TTL is negative after conversion
-to relative, then the data is expired and should be ignored.
-
-6.2. Standard query processing
-
-The major algorithm for standard query processing is presented in
-[RFC-1034].
-
-When processing queries with QCLASS=*, or some other QCLASS which
-matches multiple classes, the response should never be authoritative
-unless the server can guarantee that the response covers all classes.
-
-When composing a response, RRs which are to be inserted in the
-additional section, but duplicate RRs in the answer or authority
-sections, may be omitted from the additional section.
-
-When a response is so long that truncation is required, the truncation
-should start at the end of the response and work forward in the
-datagram.  Thus if there is any data for the authority section, the
-answer section is guaranteed to be unique.
-
-The MINIMUM value in the SOA should be used to set a floor on the TTL of
-data distributed from a zone.  This floor function should be done when
-the data is copied into a response.  This will allow future dynamic
-update protocols to change the SOA MINIMUM field without ambiguous
-semantics.
-
-6.3. Zone refresh and reload processing
-
-In spite of a server's best efforts, it may be unable to load zone data
-from a master file due to syntax errors, etc., or be unable to refresh a
-zone within the its expiration parameter.  In this case, the name server
-
-
-
-Mockapetris                                                    [Page 39]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-should answer queries as if it were not supposed to possess the zone.
-
-If a master is sending a zone out via AXFR, and a new version is created
-during the transfer, the master should continue to send the old version
-if possible.  In any case, it should never send part of one version and
-part of another.  If completion is not possible, the master should reset
-the connection on which the zone transfer is taking place.
-
-6.4. Inverse queries (Optional)
-
-Inverse queries are an optional part of the DNS.  Name servers are not
-required to support any form of inverse queries.  If a name server
-receives an inverse query that it does not support, it returns an error
-response with the "Not Implemented" error set in the header.  While
-inverse query support is optional, all name servers must be at least
-able to return the error response.
-
-6.4.1. The contents of inverse queries and responses          Inverse
-queries reverse the mappings performed by standard query operations;
-while a standard query maps a domain name to a resource, an inverse
-query maps a resource to a domain name.  For example, a standard query
-might bind a domain name to a host address; the corresponding inverse
-query binds the host address to a domain name.
-
-Inverse queries take the form of a single RR in the answer section of
-the message, with an empty question section.  The owner name of the
-query RR and its TTL are not significant.  The response carries
-questions in the question section which identify all names possessing
-the query RR WHICH THE NAME SERVER KNOWS.  Since no name server knows
-about all of the domain name space, the response can never be assumed to
-be complete.  Thus inverse queries are primarily useful for database
-management and debugging activities.  Inverse queries are NOT an
-acceptable method of mapping host addresses to host names; use the IN-
-ADDR.ARPA domain instead.
-
-Where possible, name servers should provide case-insensitive comparisons
-for inverse queries.  Thus an inverse query asking for an MX RR of
-"Venera.isi.edu" should get the same response as a query for
-"VENERA.ISI.EDU"; an inverse query for HINFO RR "IBM-PC UNIX" should
-produce the same result as an inverse query for "IBM-pc unix".  However,
-this cannot be guaranteed because name servers may possess RRs that
-contain character strings but the name server does not know that the
-data is character.
-
-When a name server processes an inverse query, it either returns:
-
-   1. zero, one, or multiple domain names for the specified
-      resource as QNAMEs in the question section
-
-
-
-Mockapetris                                                    [Page 40]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-   2. an error code indicating that the name server doesn't support
-      inverse mapping of the specified resource type.
-
-When the response to an inverse query contains one or more QNAMEs, the
-owner name and TTL of the RR in the answer section which defines the
-inverse query is modified to exactly match an RR found at the first
-QNAME.
-
-RRs returned in the inverse queries cannot be cached using the same
-mechanism as is used for the replies to standard queries.  One reason
-for this is that a name might have multiple RRs of the same type, and
-only one would appear.  For example, an inverse query for a single
-address of a multiply homed host might create the impression that only
-one address existed.
-
-6.4.2. Inverse query and response example          The overall structure
-of an inverse query for retrieving the domain name that corresponds to
-Internet address 10.1.0.52 is shown below:
-
-                         +-----------------------------------------+
-           Header        |          OPCODE=IQUERY, ID=997          |
-                         +-----------------------------------------+
-          Question       |                 <empty>                 |
-                         +-----------------------------------------+
-           Answer        |        <anyname> A IN 10.1.0.52         |
-                         +-----------------------------------------+
-          Authority      |                 <empty>                 |
-                         +-----------------------------------------+
-         Additional      |                 <empty>                 |
-                         +-----------------------------------------+
-
-This query asks for a question whose answer is the Internet style
-address 10.1.0.52.  Since the owner name is not known, any domain name
-can be used as a placeholder (and is ignored).  A single octet of zero,
-signifying the root, is usually used because it minimizes the length of
-the message.  The TTL of the RR is not significant.  The response to
-this query might be:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 41]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-                         +-----------------------------------------+
-           Header        |         OPCODE=RESPONSE, ID=997         |
-                         +-----------------------------------------+
-          Question       |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |
-                         +-----------------------------------------+
-           Answer        |  VENERA.ISI.EDU  A IN 10.1.0.52         |
-                         +-----------------------------------------+
-          Authority      |                 <empty>                 |
-                         +-----------------------------------------+
-         Additional      |                 <empty>                 |
-                         +-----------------------------------------+
-
-Note that the QTYPE in a response to an inverse query is the same as the
-TYPE field in the answer section of the inverse query.  Responses to
-inverse queries may contain multiple questions when the inverse is not
-unique.  If the question section in the response is not empty, then the
-RR in the answer section is modified to correspond to be an exact copy
-of an RR at the first QNAME.
-
-6.4.3. Inverse query processing
-
-Name servers that support inverse queries can support these operations
-through exhaustive searches of their databases, but this becomes
-impractical as the size of the database increases.  An alternative
-approach is to invert the database according to the search key.
-
-For name servers that support multiple zones and a large amount of data,
-the recommended approach is separate inversions for each zone.  When a
-particular zone is changed during a refresh, only its inversions need to
-be redone.
-
-Support for transfer of this type of inversion may be included in future
-versions of the domain system, but is not supported in this version.
-
-6.5. Completion queries and responses
-
-The optional completion services described in RFC-882 and RFC-883 have
-been deleted.  Redesigned services may become available in the future.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 42]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-7. RESOLVER IMPLEMENTATION
-
-The top levels of the recommended resolver algorithm are discussed in
-[RFC-1034].  This section discusses implementation details assuming the
-database structure suggested in the name server implementation section
-of this memo.
-
-7.1. Transforming a user request into a query
-
-The first step a resolver takes is to transform the client's request,
-stated in a format suitable to the local OS, into a search specification
-for RRs at a specific name which match a specific QTYPE and QCLASS.
-Where possible, the QTYPE and QCLASS should correspond to a single type
-and a single class, because this makes the use of cached data much
-simpler.  The reason for this is that the presence of data of one type
-in a cache doesn't confirm the existence or non-existence of data of
-other types, hence the only way to be sure is to consult an
-authoritative source.  If QCLASS=* is used, then authoritative answers
-won't be available.
-
-Since a resolver must be able to multiplex multiple requests if it is to
-perform its function efficiently, each pending request is usually
-represented in some block of state information.  This state block will
-typically contain:
-
-   - A timestamp indicating the time the request began.
-     The timestamp is used to decide whether RRs in the database
-     can be used or are out of date.  This timestamp uses the
-     absolute time format previously discussed for RR storage in
-     zones and caches.  Note that when an RRs TTL indicates a
-     relative time, the RR must be timely, since it is part of a
-     zone.  When the RR has an absolute time, it is part of a
-     cache, and the TTL of the RR is compared against the timestamp
-     for the start of the request.
-
-     Note that using the timestamp is superior to using a current
-     time, since it allows RRs with TTLs of zero to be entered in
-     the cache in the usual manner, but still used by the current
-     request, even after intervals of many seconds due to system
-     load, query retransmission timeouts, etc.
-
-   - Some sort of parameters to limit the amount of work which will
-     be performed for this request.
-
-     The amount of work which a resolver will do in response to a
-     client request must be limited to guard against errors in the
-     database, such as circular CNAME references, and operational
-     problems, such as network partition which prevents the
-
-
-
-Mockapetris                                                    [Page 43]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-     resolver from accessing the name servers it needs.  While
-     local limits on the number of times a resolver will retransmit
-     a particular query to a particular name server address are
-     essential, the resolver should have a global per-request
-     counter to limit work on a single request.  The counter should
-     be set to some initial value and decremented whenever the
-     resolver performs any action (retransmission timeout,
-     retransmission, etc.)  If the counter passes zero, the request
-     is terminated with a temporary error.
-
-     Note that if the resolver structure allows one request to
-     start others in parallel, such as when the need to access a
-     name server for one request causes a parallel resolve for the
-     name server's addresses, the spawned request should be started
-     with a lower counter.  This prevents circular references in
-     the database from starting a chain reaction of resolver
-     activity.
-
-   - The SLIST data structure discussed in [RFC-1034].
-
-     This structure keeps track of the state of a request if it
-     must wait for answers from foreign name servers.
-
-7.2. Sending the queries
-
-As described in [RFC-1034], the basic task of the resolver is to
-formulate a query which will answer the client's request and direct that
-query to name servers which can provide the information.  The resolver
-will usually only have very strong hints about which servers to ask, in
-the form of NS RRs, and may have to revise the query, in response to
-CNAMEs, or revise the set of name servers the resolver is asking, in
-response to delegation responses which point the resolver to name
-servers closer to the desired information.  In addition to the
-information requested by the client, the resolver may have to call upon
-its own services to determine the address of name servers it wishes to
-contact.
-
-In any case, the model used in this memo assumes that the resolver is
-multiplexing attention between multiple requests, some from the client,
-and some internally generated.  Each request is represented by some
-state information, and the desired behavior is that the resolver
-transmit queries to name servers in a way that maximizes the probability
-that the request is answered, minimizes the time that the request takes,
-and avoids excessive transmissions.  The key algorithm uses the state
-information of the request to select the next name server address to
-query, and also computes a timeout which will cause the next action
-should a response not arrive.  The next action will usually be a
-transmission to some other server, but may be a temporary error to the
-
-
-
-Mockapetris                                                    [Page 44]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-client.
-
-The resolver always starts with a list of server names to query (SLIST).
-This list will be all NS RRs which correspond to the nearest ancestor
-zone that the resolver knows about.  To avoid startup problems, the
-resolver should have a set of default servers which it will ask should
-it have no current NS RRs which are appropriate.  The resolver then adds
-to SLIST all of the known addresses for the name servers, and may start
-parallel requests to acquire the addresses of the servers when the
-resolver has the name, but no addresses, for the name servers.
-
-To complete initialization of SLIST, the resolver attaches whatever
-history information it has to the each address in SLIST.  This will
-usually consist of some sort of weighted averages for the response time
-of the address, and the batting average of the address (i.e., how often
-the address responded at all to the request).  Note that this
-information should be kept on a per address basis, rather than on a per
-name server basis, because the response time and batting average of a
-particular server may vary considerably from address to address.  Note
-also that this information is actually specific to a resolver address /
-server address pair, so a resolver with multiple addresses may wish to
-keep separate histories for each of its addresses.  Part of this step
-must deal with addresses which have no such history; in this case an
-expected round trip time of 5-10 seconds should be the worst case, with
-lower estimates for the same local network, etc.
-
-Note that whenever a delegation is followed, the resolver algorithm
-reinitializes SLIST.
-
-The information establishes a partial ranking of the available name
-server addresses.  Each time an address is chosen and the state should
-be altered to prevent its selection again until all other addresses have
-been tried.  The timeout for each transmission should be 50-100% greater
-than the average predicted value to allow for variance in response.
-
-Some fine points:
-
-   - The resolver may encounter a situation where no addresses are
-     available for any of the name servers named in SLIST, and
-     where the servers in the list are precisely those which would
-     normally be used to look up their own addresses.  This
-     situation typically occurs when the glue address RRs have a
-     smaller TTL than the NS RRs marking delegation, or when the
-     resolver caches the result of a NS search.  The resolver
-     should detect this condition and restart the search at the
-     next ancestor zone, or alternatively at the root.
-
-
-
-
-
-Mockapetris                                                    [Page 45]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-   - If a resolver gets a server error or other bizarre response
-     from a name server, it should remove it from SLIST, and may
-     wish to schedule an immediate transmission to the next
-     candidate server address.
-
-7.3. Processing responses
-
-The first step in processing arriving response datagrams is to parse the
-response.  This procedure should include:
-
-   - Check the header for reasonableness.  Discard datagrams which
-     are queries when responses are expected.
-
-   - Parse the sections of the message, and insure that all RRs are
-     correctly formatted.
-
-   - As an optional step, check the TTLs of arriving data looking
-     for RRs with excessively long TTLs.  If a RR has an
-     excessively long TTL, say greater than 1 week, either discard
-     the whole response, or limit all TTLs in the response to 1
-     week.
-
-The next step is to match the response to a current resolver request.
-The recommended strategy is to do a preliminary matching using the ID
-field in the domain header, and then to verify that the question section
-corresponds to the information currently desired.  This requires that
-the transmission algorithm devote several bits of the domain ID field to
-a request identifier of some sort.  This step has several fine points:
-
-   - Some name servers send their responses from different
-     addresses than the one used to receive the query.  That is, a
-     resolver cannot rely that a response will come from the same
-     address which it sent the corresponding query to.  This name
-     server bug is typically encountered in UNIX systems.
-
-   - If the resolver retransmits a particular request to a name
-     server it should be able to use a response from any of the
-     transmissions.  However, if it is using the response to sample
-     the round trip time to access the name server, it must be able
-     to determine which transmission matches the response (and keep
-     transmission times for each outgoing message), or only
-     calculate round trip times based on initial transmissions.
-
-   - A name server will occasionally not have a current copy of a
-     zone which it should have according to some NS RRs.  The
-     resolver should simply remove the name server from the current
-     SLIST, and continue.
-
-
-
-
-Mockapetris                                                    [Page 46]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-7.4. Using the cache
-
-In general, we expect a resolver to cache all data which it receives in
-responses since it may be useful in answering future client requests.
-However, there are several types of data which should not be cached:
-
-   - When several RRs of the same type are available for a
-     particular owner name, the resolver should either cache them
-     all or none at all.  When a response is truncated, and a
-     resolver doesn't know whether it has a complete set, it should
-     not cache a possibly partial set of RRs.
-
-   - Cached data should never be used in preference to
-     authoritative data, so if caching would cause this to happen
-     the data should not be cached.
-
-   - The results of an inverse query should not be cached.
-
-   - The results of standard queries where the QNAME contains "*"
-     labels if the data might be used to construct wildcards.  The
-     reason is that the cache does not necessarily contain existing
-     RRs or zone boundary information which is necessary to
-     restrict the application of the wildcard RRs.
-
-   - RR data in responses of dubious reliability.  When a resolver
-     receives unsolicited responses or RR data other than that
-     requested, it should discard it without caching it.  The basic
-     implication is that all sanity checks on a packet should be
-     performed before any of it is cached.
-
-In a similar vein, when a resolver has a set of RRs for some name in a
-response, and wants to cache the RRs, it should check its cache for
-already existing RRs.  Depending on the circumstances, either the data
-in the response or the cache is preferred, but the two should never be
-combined.  If the data in the response is from authoritative data in the
-answer section, it is always preferred.
-
-8. MAIL SUPPORT
-
-The domain system defines a standard for mapping mailboxes into domain
-names, and two methods for using the mailbox information to derive mail
-routing information.  The first method is called mail exchange binding
-and the other method is mailbox binding.  The mailbox encoding standard
-and mail exchange binding are part of the DNS official protocol, and are
-the recommended method for mail routing in the Internet.  Mailbox
-binding is an experimental feature which is still under development and
-subject to change.
-
-
-
-
-Mockapetris                                                    [Page 47]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-The mailbox encoding standard assumes a mailbox name of the form
-"<local-part>@<mail-domain>".  While the syntax allowed in each of these
-sections varies substantially between the various mail internets, the
-preferred syntax for the ARPA Internet is given in [RFC-822].
-
-The DNS encodes the <local-part> as a single label, and encodes the
-<mail-domain> as a domain name.  The single label from the <local-part>
-is prefaced to the domain name from <mail-domain> to form the domain
-name corresponding to the mailbox.  Thus the mailbox HOSTMASTER@SRI-
-NIC.ARPA is mapped into the domain name HOSTMASTER.SRI-NIC.ARPA.  If the
-<local-part> contains dots or other special characters, its
-representation in a master file will require the use of backslash
-quoting to ensure that the domain name is properly encoded.  For
-example, the mailbox Action.domains@ISI.EDU would be represented as
-Action\.domains.ISI.EDU.
-
-8.1. Mail exchange binding
-
-Mail exchange binding uses the <mail-domain> part of a mailbox
-specification to determine where mail should be sent.  The <local-part>
-is not even consulted.  [RFC-974] specifies this method in detail, and
-should be consulted before attempting to use mail exchange support.
-
-One of the advantages of this method is that it decouples mail
-destination naming from the hosts used to support mail service, at the
-cost of another layer of indirection in the lookup function.  However,
-the addition layer should eliminate the need for complicated "%", "!",
-etc encodings in <local-part>.
-
-The essence of the method is that the <mail-domain> is used as a domain
-name to locate type MX RRs which list hosts willing to accept mail for
-<mail-domain>, together with preference values which rank the hosts
-according to an order specified by the administrators for <mail-domain>.
-
-In this memo, the <mail-domain> ISI.EDU is used in examples, together
-with the hosts VENERA.ISI.EDU and VAXA.ISI.EDU as mail exchanges for
-ISI.EDU.  If a mailer had a message for Mockapetris@ISI.EDU, it would
-route it by looking up MX RRs for ISI.EDU.  The MX RRs at ISI.EDU name
-VENERA.ISI.EDU and VAXA.ISI.EDU, and type A queries can find the host
-addresses.
-
-8.2. Mailbox binding (Experimental)
-
-In mailbox binding, the mailer uses the entire mail destination
-specification to construct a domain name.  The encoded domain name for
-the mailbox is used as the QNAME field in a QTYPE=MAILB query.
-
-Several outcomes are possible for this query:
-
-
-
-Mockapetris                                                    [Page 48]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-   1. The query can return a name error indicating that the mailbox
-      does not exist as a domain name.
-
-      In the long term, this would indicate that the specified
-      mailbox doesn't exist.  However, until the use of mailbox
-      binding is universal, this error condition should be
-      interpreted to mean that the organization identified by the
-      global part does not support mailbox binding.  The
-      appropriate procedure is to revert to exchange binding at
-      this point.
-
-   2. The query can return a Mail Rename (MR) RR.
-
-      The MR RR carries new mailbox specification in its RDATA
-      field.  The mailer should replace the old mailbox with the
-      new one and retry the operation.
-
-   3. The query can return a MB RR.
-
-      The MB RR carries a domain name for a host in its RDATA
-      field.  The mailer should deliver the message to that host
-      via whatever protocol is applicable, e.g., b,SMTP.
-
-   4. The query can return one or more Mail Group (MG) RRs.
-
-      This condition means that the mailbox was actually a mailing
-      list or mail group, rather than a single mailbox.  Each MG RR
-      has a RDATA field that identifies a mailbox that is a member
-      of the group.  The mailer should deliver a copy of the
-      message to each member.
-
-   5. The query can return a MB RR as well as one or more MG RRs.
-
-      This condition means the the mailbox was actually a mailing
-      list.  The mailer can either deliver the message to the host
-      specified by the MB RR, which will in turn do the delivery to
-      all members, or the mailer can use the MG RRs to do the
-      expansion itself.
-
-In any of these cases, the response may include a Mail Information
-(MINFO) RR.  This RR is usually associated with a mail group, but is
-legal with a MB.  The MINFO RR identifies two mailboxes.  One of these
-identifies a responsible person for the original mailbox name.  This
-mailbox should be used for requests to be added to a mail group, etc.
-The second mailbox name in the MINFO RR identifies a mailbox that should
-receive error messages for mail failures.  This is particularly
-appropriate for mailing lists when errors in member names should be
-reported to a person other than the one who sends a message to the list.
-
-
-
-Mockapetris                                                    [Page 49]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-New fields may be added to this RR in the future.
-
-
-9. REFERENCES and BIBLIOGRAPHY
-
-[Dyer 87]       S. Dyer, F. Hsu, "Hesiod", Project Athena
-                Technical Plan - Name Service, April 1987, version 1.9.
-
-                Describes the fundamentals of the Hesiod name service.
-
-[IEN-116]       J. Postel, "Internet Name Server", IEN-116,
-                USC/Information Sciences Institute, August 1979.
-
-                A name service obsoleted by the Domain Name System, but
-                still in use.
-
-[Quarterman 86] J. Quarterman, and J. Hoskins, "Notable Computer Networks",
-                Communications of the ACM, October 1986, volume 29, number
-                10.
-
-[RFC-742]       K. Harrenstien, "NAME/FINGER", RFC-742, Network
-                Information Center, SRI International, December 1977.
-
-[RFC-768]       J. Postel, "User Datagram Protocol", RFC-768,
-                USC/Information Sciences Institute, August 1980.
-
-[RFC-793]       J. Postel, "Transmission Control Protocol", RFC-793,
-                USC/Information Sciences Institute, September 1981.
-
-[RFC-799]       D. Mills, "Internet Name Domains", RFC-799, COMSAT,
-                September 1981.
-
-                Suggests introduction of a hierarchy in place of a flat
-                name space for the Internet.
-
-[RFC-805]       J. Postel, "Computer Mail Meeting Notes", RFC-805,
-                USC/Information Sciences Institute, February 1982.
-
-[RFC-810]       E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
-                Internet Host Table Specification", RFC-810, Network
-                Information Center, SRI International, March 1982.
-
-                Obsolete.  See RFC-952.
-
-[RFC-811]       K. Harrenstien, V. White, and E. Feinler, "Hostnames
-                Server", RFC-811, Network Information Center, SRI
-                International, March 1982.
-
-
-
-
-Mockapetris                                                    [Page 50]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-                Obsolete.  See RFC-953.
-
-[RFC-812]       K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
-                Network Information Center, SRI International, March
-                1982.
-
-[RFC-819]       Z. Su, and J. Postel, "The Domain Naming Convention for
-                Internet User Applications", RFC-819, Network
-                Information Center, SRI International, August 1982.
-
-                Early thoughts on the design of the domain system.
-                Current implementation is completely different.
-
-[RFC-821]       J. Postel, "Simple Mail Transfer Protocol", RFC-821,
-                USC/Information Sciences Institute, August 1980.
-
-[RFC-830]       Z. Su, "A Distributed System for Internet Name Service",
-                RFC-830, Network Information Center, SRI International,
-                October 1982.
-
-                Early thoughts on the design of the domain system.
-                Current implementation is completely different.
-
-[RFC-882]       P. Mockapetris, "Domain names - Concepts and
-                Facilities," RFC-882, USC/Information Sciences
-                Institute, November 1983.
-
-                Superceeded by this memo.
-
-[RFC-883]       P. Mockapetris, "Domain names - Implementation and
-                Specification," RFC-883, USC/Information Sciences
-                Institute, November 1983.
-
-                Superceeded by this memo.
-
-[RFC-920]       J. Postel and J. Reynolds, "Domain Requirements",
-                RFC-920, USC/Information Sciences Institute,
-                October 1984.
-
-                Explains the naming scheme for top level domains.
-
-[RFC-952]       K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host
-                Table Specification", RFC-952, SRI, October 1985.
-
-                Specifies the format of HOSTS.TXT, the host/address
-                table replaced by the DNS.
-
-
-
-
-
-Mockapetris                                                    [Page 51]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-[RFC-953]       K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
-                RFC-953, SRI, October 1985.
-
-                This RFC contains the official specification of the
-                hostname server protocol, which is obsoleted by the DNS.
-                This TCP based protocol accesses information stored in
-                the RFC-952 format, and is used to obtain copies of the
-                host table.
-
-[RFC-973]       P. Mockapetris, "Domain System Changes and
-                Observations", RFC-973, USC/Information Sciences
-                Institute, January 1986.
-
-                Describes changes to RFC-882 and RFC-883 and reasons for
-                them.
-
-[RFC-974]       C. Partridge, "Mail routing and the domain system",
-                RFC-974, CSNET CIC BBN Labs, January 1986.
-
-                Describes the transition from HOSTS.TXT based mail
-                addressing to the more powerful MX system used with the
-                domain system.
-
-[RFC-1001]      NetBIOS Working Group, "Protocol standard for a NetBIOS
-                service on a TCP/UDP transport: Concepts and Methods",
-                RFC-1001, March 1987.
-
-                This RFC and RFC-1002 are a preliminary design for
-                NETBIOS on top of TCP/IP which proposes to base NetBIOS
-                name service on top of the DNS.
-
-[RFC-1002]      NetBIOS Working Group, "Protocol standard for a NetBIOS
-                service on a TCP/UDP transport: Detailed
-                Specifications", RFC-1002, March 1987.
-
-[RFC-1010]      J. Reynolds, and J. Postel, "Assigned Numbers", RFC-1010,
-                USC/Information Sciences Institute, May 1987.
-
-                Contains socket numbers and mnemonics for host names,
-                operating systems, etc.
-
-[RFC-1031]      W. Lazear, "MILNET Name Domain Transition", RFC-1031,
-                November 1987.
-
-                Describes a plan for converting the MILNET to the DNS.
-
-[RFC-1032]      M. Stahl, "Establishing a Domain - Guidelines for
-                Administrators", RFC-1032, November 1987.
-
-
-
-Mockapetris                                                    [Page 52]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-                Describes the registration policies used by the NIC to
-                administer the top level domains and delegate subzones.
-
-[RFC-1033]      M. Lottor, "Domain Administrators Operations Guide",
-                RFC-1033, November 1987.
-
-                A cookbook for domain administrators.
-
-[Solomon 82]    M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
-                Name Server", Computer Networks, vol 6, nr 3, July 1982.
-
-                Describes a name service for CSNET which is independent
-                from the DNS and DNS use in the CSNET.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 53]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-Index
-
-          *   13
-
-          ;   33, 35
-
-          <character-string>   35
-          <domain-name>   34
-
-          @   35
-
-          \   35
-
-          A   12
-
-          Byte order   8
-
-          CH   13
-          Character case   9
-          CLASS   11
-          CNAME   12
-          Completion   42
-          CS   13
-
-          Hesiod   13
-          HINFO   12
-          HS   13
-
-          IN   13
-          IN-ADDR.ARPA domain   22
-          Inverse queries   40
-
-          Mailbox names   47
-          MB   12
-          MD   12
-          MF   12
-          MG   12
-          MINFO   12
-          MINIMUM   20
-          MR   12
-          MX   12
-
-          NS   12
-          NULL   12
-
-          Port numbers   32
-          Primary server   5
-          PTR   12, 18
-
-
-
-Mockapetris                                                    [Page 54]
-
-RFC 1035        Domain Implementation and Specification    November 1987
-
-
-          QCLASS   13
-          QTYPE   12
-
-          RDATA   12
-          RDLENGTH  11
-
-          Secondary server   5
-          SOA   12
-          Stub resolvers   7
-
-          TCP   32
-          TXT   12
-          TYPE   11
-
-          UDP   32
-
-          WKS   12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 55]
-
diff --git a/contrib/bind9/doc/rfc/rfc1101.txt b/contrib/bind9/doc/rfc/rfc1101.txt
deleted file mode 100644
index 66c9d8b..0000000
--- a/contrib/bind9/doc/rfc/rfc1101.txt
+++ /dev/null
@@ -1,787 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                     P. Mockapetris
-Request for Comments: 1101                                           ISI
-Updates: RFCs 1034, 1035                                      April 1989
-
-
-             DNS Encoding of Network Names and Other Types
-
-
-1. STATUS OF THIS MEMO
-
-   This RFC proposes two extensions to the Domain Name System:
-
-      - A specific method for entering and retrieving RRs which map
-        between network names and numbers.
-
-      - Ideas for a general method for describing mappings between
-        arbitrary identifiers and numbers.
-
-   The method for mapping between network names and addresses is a
-   proposed standard, the ideas for a general method are experimental.
-
-   This RFC assumes that the reader is familiar with the DNS [RFC 1034,
-   RFC 1035] and its use.  The data shown is for pedagogical use and
-   does not necessarily reflect the real Internet.
-
-   Distribution of this memo is unlimited.
-
-2. INTRODUCTION
-
-   The DNS is extensible and can be used for a virtually unlimited
-   number of data types, name spaces, etc.  New type definitions are
-   occasionally necessary as are revisions or deletions of old types
-   (e.g., MX replacement of MD and MF [RFC 974]), and changes described
-   in [RFC 973].  This RFC describes changes due to the general need to
-   map between identifiers and values, and a specific need for network
-   name support.
-
-   Users wish to be able to use the DNS to map between network names and
-   numbers.  This need is the only capability found in HOSTS.TXT which
-   is not available from the DNS.  In designing a method to do this,
-   there were two major areas of concern:
-
-      - Several tradeoffs involving control of network names, the
-        syntax of network names, backward compatibility, etc.
-
-      - A desire to create a method which would be sufficiently
-        general to set a good precedent for future mappings,
-        for example, between TCP-port names and numbers,
-
-
-
-Mockapetris                                                     [Page 1]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-        autonomous system names and numbers, X.500 Relative
-        Distinguished Names (RDNs) and their servers, or whatever.
-
-   It was impossible to reconcile these two areas of concern for network
-   names because of the desire to unify network number support within
-   existing IP address to host name support.  The existing support is
-   the IN-ADDR.ARPA section of the DNS name space.  As a result this RFC
-   describes one structure for network names which builds on the
-   existing support for host names, and another family of structures for
-   future yellow pages (YP) functions such as conversions between TCP-
-   port numbers and mnemonics.
-
-   Both structures are described in following sections.  Each structure
-   has a discussion of design issues and specific structure
-   recommendations.
-
-   We wish to avoid defining structures and methods which can work but
-   do not because of indifference or errors on the part of system
-   administrators when maintaining the database.  The WKS RR is an
-   example.  Thus, while we favor distribution as a general method, we
-   also recognize that centrally maintained tables (such as HOSTS.TXT)
-   are usually more consistent though less maintainable and timely.
-   Hence we recommend both specific methods for mapping network names,
-   addresses, and subnets, as well as an instance of the general method
-   for mapping between allocated network numbers and network names.
-   (Allocation is centrally performed by the SRI Network Information
-   Center, aka the NIC).
-
-3. NETWORK NAME ISSUES AND DISCUSSION
-
-   The issues involved in the design were the definition of network name
-   syntax, the mappings to be provided, and possible support for similar
-   functions at the subnet level.
-
-3.1. Network name syntax
-
-   The current syntax for network names, as defined by [RFC 952] is an
-   alphanumeric string of up to 24 characters, which begins with an
-   alpha, and may include "." and "-" except as first and last
-   characters.  This is the format which was also used for host names
-   before the DNS.  Upward compatibility with existing names might be a
-   goal of any new scheme.
-
-   However, the present syntax has been used to define a flat name
-   space, and hence would prohibit the same distributed name allocation
-   method used for host names.  There is some sentiment for allowing the
-   NIC to continue to allocate and regulate network names, much as it
-   allocates numbers, but the majority opinion favors local control of
-
-
-
-Mockapetris                                                     [Page 2]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-   network names.  Although it would be possible to provide a flat space
-   or a name space in which, for example, the last label of a domain
-   name captured the old-style network name, any such approach would add
-   complexity to the method and create different rules for network names
-   and host names.
-
-   For these reasons, we assume that the syntax of network names will be
-   the same as the expanded syntax for host names permitted in [HR].
-   The new syntax expands the set of names to allow leading digits, so
-   long as the resulting representations do not conflict with IP
-   addresses in decimal octet form.  For example, 3Com.COM and 3M.COM
-   are now legal, although 26.0.0.73.COM is not.  See [HR] for details.
-
-   The price is that network names will get as complicated as host
-   names.  An administrator will be able to create network names in any
-   domain under his control, and also create network number to name
-   entries in IN-ADDR.ARPA domains under his control.  Thus, the name
-   for the ARPANET might become NET.ARPA, ARPANET.ARPA or Arpa-
-   network.MIL., depending on the preferences of the owner.
-
-3.2. Mappings
-
-   The desired mappings, ranked by priority with most important first,
-   are:
-
-      - Mapping a IP address or network number to a network name.
-
-        This mapping is for use in debugging tools and status displays
-        of various sorts.  The conversion from IP address to network
-        number is well known for class A, B, and C IP addresses, and
-        involves a simple mask operation.  The needs of other classes
-        are not yet defined and are ignored for the rest of this RFC.
-
-      - Mapping a network name to a network address.
-
-        This facility is of less obvious application, but a
-        symmetrical mapping seems desirable.
-
-      - Mapping an organization to its network names and numbers.
-
-        This facility is useful because it may not always be possible
-        to guess the local choice for network names, but the
-        organization name is often well known.
-
-      - Similar mappings for subnets, even when nested.
-
-        The primary application is to be able to identify all of the
-        subnets involved in a particular IP address.  A secondary
-
-
-
-Mockapetris                                                     [Page 3]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-        requirement is to retrieve address mask information.
-
-3.3. Network address section of the name space
-
-   The network name syntax discussed above can provide domain names
-   which will contain mappings from network names to various quantities,
-   but we also need a section of the name space, organized by network
-   and subnet number to hold the inverse mappings.
-
-   The choices include:
-
-      - The same network number slots already assigned and delegated
-        in the IN-ADDR.ARPA section of the name space.
-
-        For example, 10.IN-ADDR.ARPA for class A net 10,
-        2.128.IN-ADDR.ARPA for class B net 128.2, etc.
-
-      - Host-zero addresses in the IN-ADDR.ARPA tree.  (A host field
-        of all zero in an IP address is prohibited because of
-        confusion related to broadcast addresses, et al.)
-
-        For example, 0.0.0.10.IN-ADDR.ARPA for class A net 10,
-        0.0.2.128.IN-ADDR.arpa for class B net 128.2, etc.  Like the
-        first scheme, it uses in-place name space delegations to
-        distribute control.
-
-        The main advantage of this scheme over the first is that it
-        allows convenient names for subnets as well as networks.  A
-        secondary advantage is that it uses names which are not in use
-        already, and hence it is possible to test whether an
-        organization has entered this information in its domain
-        database.
-
-      - Some new section of the name space.
-
-        While this option provides the most opportunities, it creates
-        a need to delegate a whole new name space.  Since the IP
-        address space is so closely related to the network number
-        space, most believe that the overhead of creating such a new
-        space is overwhelming and would lead to the WKS syndrome.  (As
-        of February, 1989, approximately 400 sections of the
-        IN-ADDR.ARPA tree are already delegated, usually at network
-        boundaries.)
-
-
-
-
-
-
-
-
-Mockapetris                                                     [Page 4]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-4. SPECIFICS FOR NETWORK NAME MAPPINGS
-
-   The proposed solution uses information stored at:
-
-      - Names in the IN-ADDR.ARPA tree that correspond to host-zero IP
-        addresses.  The same method is used for subnets in a nested
-        fashion.  For example, 0.0.0.10.IN-ADDR.ARPA. for net 10.
-
-        Two types of information are stored here: PTR RRs which point
-        to the network name in their data sections, and A RRs, which
-        are present if the network (or subnet) is subnetted further.
-        If a type A RR is present, then it has the address mask as its
-        data.  The general form is:
-
-        <reversed-host-zero-number>.IN-ADDR.ARPA. PTR <network-name>
-        <reversed-host-zero-number>.IN-ADDR.ARPA. A   <subnet-mask>
-
-        For example:
-
-        0.0.0.10.IN-ADDR.ARPA.  PTR     ARPANET.ARPA.
-
-        or
-
-        0.0.2.128.IN-ADDR.ARPA. PTR     cmu-net.cmu.edu.
-                                A       255.255.255.0
-
-        In general, this information will be added to an existing
-        master file for some IN-ADDR.ARPA domain for each network
-        involved.  Similar RRs can be used at host-zero subnet
-        entries.
-
-      - Names which are network names.
-
-        The data stored here is PTR RRs pointing at the host-zero
-        entries.  The general form is:
-
-        <network-name> ptr <reversed-host-zero-number>.IN-ADDR.ARPA
-
-        For example:
-
-        ARPANET.ARPA.           PTR     0.0.0.10.IN-ADDR.ARPA.
-
-        or
-
-        isi-net.isi.edu.        PTR     0.0.9.128.IN-ADDR.ARPA.
-
-        In general, this information will be inserted in the master
-        file for the domain name of the organization; this is a
-
-
-
-Mockapetris                                                     [Page 5]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-        different file from that which holds the information below
-        IN-ADDR.ARPA.  Similar PTR RRs can be used at subnet names.
-
-      - Names corresponding to organizations.
-
-        The data here is one or more PTR RRs pointing at the
-        IN-ADDR.ARPA names corresponding to host-zero entries for
-        networks.
-
-        For example:
-
-        ISI.EDU.        PTR     0.0.9.128.IN-ADDR.ARPA.
-
-        MCC.COM.        PTR     0.167.5.192.IN-ADDR.ARPA.
-                        PTR     0.168.5.192.IN-ADDR.ARPA.
-                        PTR     0.169.5.192.IN-ADDR.ARPA.
-                        PTR     0.0.62.128.IN-ADDR.ARPA.
-
-4.1. A simple example
-
-   The ARPANET is a Class A network without subnets.  The RRs which
-   would be added, assuming the ARPANET.ARPA was selected as a network
-   name, would be:
-
-   ARPA.                   PTR     0.0.0.10.IN-ADDR.ARPA.
-
-   ARPANET.ARPA.           PTR     0.0.0.10.IN-ADDR.ARPA.
-
-   0.0.0.10.IN-ADDR.ARPA.  PTR     ARPANET.ARPA.
-
-   The first RR states that the organization named ARPA owns net 10 (It
-   might also own more network numbers, and these would be represented
-   with an additional RR per net.)  The second states that the network
-   name ARPANET.ARPA. maps to net 10.  The last states that net 10 is
-   named ARPANET.ARPA.
-
-   Note that all of the usual host and corresponding IN-ADDR.ARPA
-   entries would still be required.
-
-4.2. A complicated, subnetted example
-
-   The ISI network is 128.9, a class B number.  Suppose the ISI network
-   was organized into two levels of subnet, with the first level using
-   an additional 8 bits of address, and the second level using 4 bits,
-   for address masks of x'FFFFFF00' and X'FFFFFFF0'.
-
-   Then the following RRs would be entered in ISI's master file for the
-   ISI.EDU zone:
-
-
-
-Mockapetris                                                     [Page 6]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-   ; Define network entry
-   isi-net.isi.edu.                PTR  0.0.9.128.IN-ADDR.ARPA.
-
-   ; Define first level subnets
-   div1-subnet.isi.edu.            PTR  0.1.9.128.IN-ADDR.ARPA.
-   div2-subnet.isi.edu.            PTR  0.2.9.128.IN-ADDR.ARPA.
-
-   ; Define second level subnets
-   inc-subsubnet.isi.edu.          PTR  16.2.9.128.IN-ADDR.ARPA.
-
-   in the 9.128.IN-ADDR.ARPA zone:
-
-   ; Define network number and address mask
-   0.0.9.128.IN-ADDR.ARPA.         PTR  isi-net.isi.edu.
-                                   A    255.255.255.0  ;aka X'FFFFFF00'
-
-   ; Define one of the first level subnet numbers and masks
-   0.1.9.128.IN-ADDR.ARPA.         PTR  div1-subnet.isi.edu.
-                                   A    255.255.255.240 ;aka X'FFFFFFF0'
-
-   ; Define another first level subnet number and mask
-   0.2.9.128.IN-ADDR.ARPA.         PTR  div2-subnet.isi.edu.
-                                   A    255.255.255.240 ;aka X'FFFFFFF0'
-
-   ; Define second level subnet number
-   16.2.9.128.IN-ADDR.ARPA.        PTR  inc-subsubnet.isi.edu.
-
-   This assumes that the ISI network is named isi-net.isi.edu., first
-   level subnets are named div1-subnet.isi.edu. and div2-
-   subnet.isi.edu., and a second level subnet is called inc-
-   subsubnet.isi.edu.  (In a real system as complicated as this there
-   would be more first and second level subnets defined, but we have
-   shown enough to illustrate the ideas.)
-
-4.3. Procedure for using an IP address to get network name
-
-   Depending on whether the IP address is class A, B, or C, mask off the
-   high one, two, or three bytes, respectively.  Reverse the octets,
-   suffix IN-ADDR.ARPA, and do a PTR query.
-
-   For example, suppose the IP address is 10.0.0.51.
-
-      1. Since this is a class A address, use a mask x'FF000000' and
-         get 10.0.0.0.
-
-      2. Construct the name 0.0.0.10.IN-ADDR.ARPA.
-
-      3. Do a PTR query.  Get back
-
-
-
-Mockapetris                                                     [Page 7]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-         0.0.0.10.IN-ADDR.ARPA.  PTR     ARPANET.ARPA.
-
-      4. Conclude that the network name is "ARPANET.ARPA."
-
-   Suppose that the IP address is 128.9.2.17.
-
-      1. Since this is a class B address, use a mask of x'FFFF0000'
-         and get 128.9.0.0.
-
-      2. Construct the name 0.0.9.128.IN-ADDR.ARPA.
-
-      3. Do a PTR query.  Get back
-
-         0.0.9.128.IN-ADDR.ARPA.       PTR     isi-net.isi.edu
-
-      4. Conclude that the network name is "isi-net.isi.edu."
-
-4.4. Procedure for finding all subnets involved with an IP address
-
-   This is a simple extension of the IP address to network name method.
-   When the network entry is located, do a lookup for a possible A RR.
-   If the A RR is found, look up the next level of subnet using the
-   original IP address and the mask in the A RR.  Repeat this procedure
-   until no A RR is found.
-
-   For example, repeating the use of 128.9.2.17.
-
-      1. As before construct a query for 0.0.9.128.IN-ADDR.ARPA.
-         Retrieve:
-
-         0.0.9.128.IN-ADDR.ARPA.  PTR    isi-net.isi.edu.
-                                  A      255.255.255.0
-
-      2. Since an A RR was found, repeat using mask from RR
-         (255.255.255.0), constructing a query for
-         0.2.9.128.IN-ADDR.ARPA.  Retrieve:
-
-         0.2.9.128.IN-ADDR.ARPA.  PTR    div2-subnet.isi.edu.
-                                  A      255.255.255.240
-
-      3. Since another A RR was found, repeat using mask
-         255.255.255.240 (x'FFFFFFF0').  constructing a query for
-         16.2.9.128.IN-ADDR.ARPA.  Retrieve:
-
-         16.2.9.128.IN-ADDR.ARPA. PTR    inc-subsubnet.isi.edu.
-
-      4. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there
-         are no more subnet levels.
-
-
-
-Mockapetris                                                     [Page 8]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-5. YP ISSUES AND DISCUSSION
-
-   The term "Yellow Pages" is used in almost as many ways as the term
-   "domain", so it is useful to define what is meant herein by YP.  The
-   general problem to be solved is to create a method for creating
-   mappings from one kind of identifier to another, often with an
-   inverse capability.  The traditional methods are to search or use a
-   precomputed index of some kind.
-
-   Searching is impractical when the search is too large, and
-   precomputed indexes are possible only when it is possible to specify
-   search criteria in advance, and pay for the resources necessary to
-   build the index.  For example, it is impractical to search the entire
-   domain tree to find a particular address RR, so we build the IN-
-   ADDR.ARPA YP.  Similarly, we could never build an Internet-wide index
-   of "hosts with a load average of less than 2" in less time than it
-   would take for the data to change, so indexes are a useless approach
-   for that problem.
-
-   Such a precomputed index is what we mean by YP, and we regard the
-   IN-ADDR.ARPA domain as the first instance of a YP in the DNS.
-   Although a single, centrally-managed YP for well-known values such as
-   TCP-port is desirable, we regard organization-specific YPs for, say,
-   locally defined TCP ports as a natural extension, as are combinations
-   of YPs using search lists to merge the two.
-
-   In examining Internet Numbers [RFC 997] and Assigned Numbers [RFC
-   1010], it is clear that there are several mappings which might be of
-   value.  For example:
-
-   <assigned-network-name> <==> <IP-address>
-   <autonomous-system-id>  <==> <number>
-   <protocol-id>           <==> <number>
-   <port-id>               <==> <number>
-   <ethernet-type>         <==> <number>
-   <public-data-net>       <==> <IP-address>
-
-   Following the IN-ADDR example, the YP takes the form of a domain tree
-   organized to optimize retrieval by search key and distribution via
-   normal DNS rules.  The name used as a key must include:
-
-      1. A well known origin.  For example, IN-ADDR.ARPA is the
-         current IP-address to host name YP.
-
-      2. A "from" data type.  This identifies the input type of the
-         mapping.  This is necessary because we may be mapping
-         something as anonymous as a number to any number of
-         mnemonics, etc.
-
-
-
-Mockapetris                                                     [Page 9]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-      3. A "to" data type.  Since we assume several symmetrical
-         mnemonic <==> number mappings, this is also necessary.
-
-   This ordering reflects the natural scoping of control, and hence the
-   order of the components in a domain name.  Thus domain names would be
-   of the form:
-
-   <from-value>.<to-data-type>.<from-data-type>.<YP-origin>
-
-   To make this work, we need to define well-know strings for each of
-   these metavariables, as well as encoding rules for converting a
-   <from-value> into a domain name.  We might define:
-
-   <YP-origin>     :=YP
-   <from-data-type>:=TCP-port | IN-ADDR | Number |
-                     Assigned-network-number | Name
-   <to-data-type>  :=<from-data-type>
-
-   Note that "YP" is NOT a valid country code under [ISO 3166] (although
-   we may want to worry about the future), and the existence of a
-   syntactically valid <to-data-type>.<from-data-type> pair does not
-   imply that a meaningful mapping exists, or is even possible.
-
-   The encoding rules might be:
-
-   TCP-port        Six character alphanumeric
-
-   IN-ADDR         Reversed 4-octet decimal string
-
-   Number          decimal integer
-
-   Assigned-network-number
-                   Reversed 4-octet decimal string
-
-   Name            Domain name
-
-6. SPECIFICS FOR YP MAPPINGS
-
-6.1. TCP-PORT
-
-   $origin Number.TCP-port.YP.
-
-   23              PTR     TELNET.TCP-port.Number.YP.
-   25              PTR     SMTP.TCP-port.Number.YP.
-
-   $origin TCP-port.Number.YP.
-
-   TELNET          PTR     23.Number.TCP-port.YP.
-
-
-
-Mockapetris                                                    [Page 10]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-   SMTP            PTR     25.Number.TCP-port.YP.
-
-   Thus the mapping between 23 and TELNET is represented by a pair of
-   PTR RRs, one for each direction of the mapping.
-
-6.2. Assigned networks
-
-   Network numbers are assigned by the NIC and reported in "Internet
-   Numbers" RFCs.  To create a YP, the NIC would set up two domains:
-
-   Name.Assigned-network-number.YP and Assigned-network-number.YP
-
-   The first would contain entries of the form:
-
-   $origin Name.Assigned-network-number.YP.
-
-   0.0.0.4         PTR     SATNET.Assigned-network-number.Name.YP.
-   0.0.0.10        PTR     ARPANET.Assigned-network-number.Name.YP.
-
-   The second would contain entries of the form:
-
-   $origin Assigned-network-number.Name.YP.
-
-   SATNET.         PTR     0.0.0.4.Name.Assigned-network-number.YP.
-   ARPANET.        PTR     0.0.0.10.Name.Assigned-network-number.YP.
-
-   These YPs are not in conflict with the network name support described
-   in the first half of this RFC since they map between ASSIGNED network
-   names and numbers, not those allocated by the organizations
-   themselves.  That is, they document the NIC's decisions about
-   allocating network numbers but do not automatically track any
-   renaming performed by the new owners.
-
-   As a practical matter, we might want to create both of these domains
-   to enable users on the Internet to experiment with centrally
-   maintained support as well as the distributed version, or might want
-   to implement only the allocated number to name mapping and request
-   organizations to convert their allocated network names to the network
-   names described in the distributed model.
-
-6.3. Operational improvements
-
-   We could imagine that all conversion routines using these YPs might
-   be instructed to use "YP.<local-domain>" followed by "YP."  as a
-   search list.  Thus, if the organization ISI.EDU wished to define
-   locally meaningful TCP-PORT, it would define the domains:
-
-   <TCP-port.Number.YP.ISI.EDU> and <Number.TCP-port.YP.ISI.EDU>.
-
-
-
-Mockapetris                                                    [Page 11]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-   We could add another level of indirection in the YP lookup, defining
-   the <to-data-type>.<from-data-type>.<YP-origin> nodes to point to the
-   YP tree, rather than being the YP tree directly.  This would enable
-   entries of the form:
-
-   IN-ADDR.Netname.YP.   PTR     IN-ADDR.ARPA.
-
-   to splice in YPs from other origins or existing spaces.
-
-   Another possibility would be to shorten the RDATA section of the RRs
-   which map back and forth by deleting the origin.  This could be done
-   either by allowing the domain name in the RDATA portion to not
-   identify a real domain name, or by defining a new RR which used a
-   simple text string rather than a domain name.
-
-   Thus, we might replace
-
-   $origin Assigned-network-number.Name.YP.
-
-   SATNET.         PTR     0.0.0.4.Name.Assigned-network-number.YP.
-   ARPANET.        PTR     0.0.0.10.Name.Assigned-network-number.YP.
-
-   with
-
-   $origin Assigned-network-number.Name.YP.
-
-   SATNET.         PTR     0.0.0.4.
-   ARPANET.        PTR     0.0.0.10.
-
-   or
-
-   $origin Assigned-network-number.Name.YP.
-
-   SATNET.         PTT     "0.0.0.4"
-   ARPANET.        PTT     "0.0.0.10"
-
-   where PTT is a new type whose RDATA section is a text string.
-
-7. ACKNOWLEDGMENTS
-
-   Drew Perkins, Mark Lottor, and Rob Austein contributed several of the
-   ideas in this RFC.  Numerous contributions, criticisms, and
-   compromises were produced in the IETF Domain working group and the
-   NAMEDROPPERS mailing list.
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 12]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-8. REFERENCES
-
-   [HR]        Braden, B., editor, "Requirements for Internet Hosts",
-               RFC in preparation.
-
-   [ISO 3166]  ISO, "Codes for the Representation of Names of
-               Countries", 1981.
-
-   [RFC 882]   Mockapetris, P., "Domain names - Concepts and
-               Facilities", RFC 882, USC/Information Sciences Institute,
-               November 1983.
-
-               Superseded by RFC 1034.
-
-   [RFC 883]   Mockapetris, P.,"Domain names - Implementation and
-               Specification", RFC 883, USC/Information Sciences
-               Institute, November 1983.
-
-               Superceeded by RFC 1035.
-
-   [RFC 920]   Postel, J. and J. Reynolds, "Domain Requirements", RFC
-               920, October 1984.
-
-               Explains the naming scheme for top level domains.
-
-   [RFC 952]   Harrenstien, K., M. Stahl, and E. Feinler, "DoD Internet
-               Host Table Specification", RFC 952, SRI, October 1985.
-
-               Specifies the format of HOSTS.TXT, the host/address table
-               replaced by the DNS
-
-   [RFC 973]   Mockapetris, P., "Domain System Changes and
-               Observations", RFC 973, USC/Information Sciences
-               Institute, January 1986.
-
-               Describes changes to RFCs 882 and 883 and reasons for
-               them.
-
-   [RFC 974]   Partridge, C., "Mail routing and the domain system", RFC
-               974, CSNET CIC BBN Labs, January 1986.
-
-               Describes the transition from HOSTS.TXT based mail
-               addressing to the more powerful MX system used with the
-               domain system.
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 13]
-
-RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
-
-
-   [RFC 997]   Reynolds, J., and J. Postel, "Internet Numbers", RFC 997,
-               USC/Information Sciences Institute, March 1987
-
-               Contains network numbers, autonomous system numbers, etc.
-
-   [RFC 1010]  Reynolds, J., and J. Postel, "Assigned Numbers", RFC
-               1010, USC/Information Sciences Institute, May 1987
-
-               Contains socket numbers and mnemonics for host names,
-               operating systems, etc.
-
-
-   [RFC 1034]  Mockapetris, P., "Domain names - Concepts and
-               Facilities", RFC 1034, USC/Information Sciences
-               Institute, November 1987.
-
-               Introduction/overview of the DNS.
-
-   [RFC 1035]  Mockapetris, P., "Domain names - Implementation and
-               Specification", RFC 1035, USC/Information Sciences
-               Institute, November 1987.
-
-               DNS implementation instructions.
-
-Author's Address:
-
-   Paul Mockapetris
-   USC/Information Sciences Institute
-   4676 Admiralty Way
-   Marina del Rey, CA 90292
-
-   Phone: (213) 822-1511
-
-   Email: PVM@ISI.EDU
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris                                                    [Page 14]
-
\ No newline at end of file
diff --git a/contrib/bind9/doc/rfc/rfc1122.txt b/contrib/bind9/doc/rfc/rfc1122.txt
deleted file mode 100644
index c14f2e5..0000000
--- a/contrib/bind9/doc/rfc/rfc1122.txt
+++ /dev/null
@@ -1,6844 +0,0 @@
-
-
-
-
-
-
-Network Working Group                    Internet Engineering Task Force
-Request for Comments: 1122                             R. Braden, Editor
-                                                            October 1989
-
-
-        Requirements for Internet Hosts -- Communication Layers
-
-
-Status of This Memo
-
-   This RFC is an official specification for the Internet community.  It
-   incorporates by reference, amends, corrects, and supplements the
-   primary protocol standards documents relating to hosts.  Distribution
-   of this document is unlimited.
-
-Summary
-
-   This is one RFC of a pair that defines and discusses the requirements
-   for Internet host software.  This RFC covers the communications
-   protocol layers: link layer, IP layer, and transport layer; its
-   companion RFC-1123 covers the application and support protocols.
-
-
-
-                           Table of Contents
-
-
-
-
-   1.  INTRODUCTION ...............................................    5
-      1.1  The Internet Architecture ..............................    6
-         1.1.1  Internet Hosts ....................................    6
-         1.1.2  Architectural Assumptions .........................    7
-         1.1.3  Internet Protocol Suite ...........................    8
-         1.1.4  Embedded Gateway Code .............................   10
-      1.2  General Considerations .................................   12
-         1.2.1  Continuing Internet Evolution .....................   12
-         1.2.2  Robustness Principle ..............................   12
-         1.2.3  Error Logging .....................................   13
-         1.2.4  Configuration .....................................   14
-      1.3  Reading this Document ..................................   15
-         1.3.1  Organization ......................................   15
-         1.3.2  Requirements ......................................   16
-         1.3.3  Terminology .......................................   17
-      1.4  Acknowledgments ........................................   20
-
-   2. LINK LAYER ..................................................   21
-      2.1  INTRODUCTION ...........................................   21
-
-
-
-Internet Engineering Task Force                                 [Page 1]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-      2.2  PROTOCOL WALK-THROUGH ..................................   21
-      2.3  SPECIFIC ISSUES ........................................   21
-         2.3.1  Trailer Protocol Negotiation ......................   21
-         2.3.2  Address Resolution Protocol -- ARP ................   22
-            2.3.2.1  ARP Cache Validation .........................   22
-            2.3.2.2  ARP Packet Queue .............................   24
-         2.3.3  Ethernet and IEEE 802 Encapsulation ...............   24
-      2.4  LINK/INTERNET LAYER INTERFACE ..........................   25
-      2.5  LINK LAYER REQUIREMENTS SUMMARY ........................   26
-
-   3. INTERNET LAYER PROTOCOLS ....................................   27
-      3.1 INTRODUCTION ............................................   27
-      3.2  PROTOCOL WALK-THROUGH ..................................   29
-         3.2.1 Internet Protocol -- IP ............................   29
-            3.2.1.1  Version Number ...............................   29
-            3.2.1.2  Checksum .....................................   29
-            3.2.1.3  Addressing ...................................   29
-            3.2.1.4  Fragmentation and Reassembly .................   32
-            3.2.1.5  Identification ...............................   32
-            3.2.1.6  Type-of-Service ..............................   33
-            3.2.1.7  Time-to-Live .................................   34
-            3.2.1.8  Options ......................................   35
-         3.2.2 Internet Control Message Protocol -- ICMP ..........   38
-            3.2.2.1  Destination Unreachable ......................   39
-            3.2.2.2  Redirect .....................................   40
-            3.2.2.3  Source Quench ................................   41
-            3.2.2.4  Time Exceeded ................................   41
-            3.2.2.5  Parameter Problem ............................   42
-            3.2.2.6  Echo Request/Reply ...........................   42
-            3.2.2.7  Information Request/Reply ....................   43
-            3.2.2.8  Timestamp and Timestamp Reply ................   43
-            3.2.2.9  Address Mask Request/Reply ...................   45
-         3.2.3  Internet Group Management Protocol IGMP ...........   47
-      3.3  SPECIFIC ISSUES ........................................   47
-         3.3.1  Routing Outbound Datagrams ........................   47
-            3.3.1.1  Local/Remote Decision ........................   47
-            3.3.1.2  Gateway Selection ............................   48
-            3.3.1.3  Route Cache ..................................   49
-            3.3.1.4  Dead Gateway Detection .......................   51
-            3.3.1.5  New Gateway Selection ........................   55
-            3.3.1.6  Initialization ...............................   56
-         3.3.2  Reassembly ........................................   56
-         3.3.3  Fragmentation .....................................   58
-         3.3.4  Local Multihoming .................................   60
-            3.3.4.1  Introduction .................................   60
-            3.3.4.2  Multihoming Requirements .....................   61
-            3.3.4.3  Choosing a Source Address ....................   64
-         3.3.5  Source Route Forwarding ...........................   65
-
-
-
-Internet Engineering Task Force                                 [Page 2]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         3.3.6  Broadcasts ........................................   66
-         3.3.7  IP Multicasting ...................................   67
-         3.3.8  Error Reporting ...................................   69
-      3.4  INTERNET/TRANSPORT LAYER INTERFACE .....................   69
-      3.5  INTERNET LAYER REQUIREMENTS SUMMARY ....................   72
-
-   4. TRANSPORT PROTOCOLS .........................................   77
-      4.1  USER DATAGRAM PROTOCOL -- UDP ..........................   77
-         4.1.1  INTRODUCTION ......................................   77
-         4.1.2  PROTOCOL WALK-THROUGH .............................   77
-         4.1.3  SPECIFIC ISSUES ...................................   77
-            4.1.3.1  Ports ........................................   77
-            4.1.3.2  IP Options ...................................   77
-            4.1.3.3  ICMP Messages ................................   78
-            4.1.3.4  UDP Checksums ................................   78
-            4.1.3.5  UDP Multihoming ..............................   79
-            4.1.3.6  Invalid Addresses ............................   79
-         4.1.4  UDP/APPLICATION LAYER INTERFACE ...................   79
-         4.1.5  UDP REQUIREMENTS SUMMARY ..........................   80
-      4.2  TRANSMISSION CONTROL PROTOCOL -- TCP ...................   82
-         4.2.1  INTRODUCTION ......................................   82
-         4.2.2  PROTOCOL WALK-THROUGH .............................   82
-            4.2.2.1  Well-Known Ports .............................   82
-            4.2.2.2  Use of Push ..................................   82
-            4.2.2.3  Window Size ..................................   83
-            4.2.2.4  Urgent Pointer ...............................   84
-            4.2.2.5  TCP Options ..................................   85
-            4.2.2.6  Maximum Segment Size Option ..................   85
-            4.2.2.7  TCP Checksum .................................   86
-            4.2.2.8  TCP Connection State Diagram .................   86
-            4.2.2.9  Initial Sequence Number Selection ............   87
-            4.2.2.10  Simultaneous Open Attempts ..................   87
-            4.2.2.11  Recovery from Old Duplicate SYN .............   87
-            4.2.2.12  RST Segment .................................   87
-            4.2.2.13  Closing a Connection ........................   87
-            4.2.2.14  Data Communication ..........................   89
-            4.2.2.15  Retransmission Timeout ......................   90
-            4.2.2.16  Managing the Window .........................   91
-            4.2.2.17  Probing Zero Windows ........................   92
-            4.2.2.18  Passive OPEN Calls ..........................   92
-            4.2.2.19  Time to Live ................................   93
-            4.2.2.20  Event Processing ............................   93
-            4.2.2.21  Acknowledging Queued Segments ...............   94
-         4.2.3  SPECIFIC ISSUES ...................................   95
-            4.2.3.1  Retransmission Timeout Calculation ...........   95
-            4.2.3.2  When to Send an ACK Segment ..................   96
-            4.2.3.3  When to Send a Window Update .................   97
-            4.2.3.4  When to Send Data ............................   98
-
-
-
-Internet Engineering Task Force                                 [Page 3]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-            4.2.3.5  TCP Connection Failures ......................  100
-            4.2.3.6  TCP Keep-Alives ..............................  101
-            4.2.3.7  TCP Multihoming ..............................  103
-            4.2.3.8  IP Options ...................................  103
-            4.2.3.9  ICMP Messages ................................  103
-            4.2.3.10  Remote Address Validation ...................  104
-            4.2.3.11  TCP Traffic Patterns ........................  104
-            4.2.3.12  Efficiency ..................................  105
-         4.2.4  TCP/APPLICATION LAYER INTERFACE ...................  106
-            4.2.4.1  Asynchronous Reports .........................  106
-            4.2.4.2  Type-of-Service ..............................  107
-            4.2.4.3  Flush Call ...................................  107
-            4.2.4.4  Multihoming ..................................  108
-         4.2.5  TCP REQUIREMENT SUMMARY ...........................  108
-
-   5.  REFERENCES .................................................  112
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                 [Page 4]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-1.  INTRODUCTION
-
-   This document is one of a pair that defines and discusses the
-   requirements for host system implementations of the Internet protocol
-   suite.  This RFC covers the communication protocol layers:  link
-   layer, IP layer, and transport layer.  Its companion RFC,
-   "Requirements for Internet Hosts -- Application and Support"
-   [INTRO:1], covers the application layer protocols.  This document
-   should also be read in conjunction with "Requirements for Internet
-   Gateways" [INTRO:2].
-
-   These documents are intended to provide guidance for vendors,
-   implementors, and users of Internet communication software.  They
-   represent the consensus of a large body of technical experience and
-   wisdom, contributed by the members of the Internet research and
-   vendor communities.
-
-   This RFC enumerates standard protocols that a host connected to the
-   Internet must use, and it incorporates by reference the RFCs and
-   other documents describing the current specifications for these
-   protocols.  It corrects errors in the referenced documents and adds
-   additional discussion and guidance for an implementor.
-
-   For each protocol, this document also contains an explicit set of
-   requirements, recommendations, and options.  The reader must
-   understand that the list of requirements in this document is
-   incomplete by itself; the complete set of requirements for an
-   Internet host is primarily defined in the standard protocol
-   specification documents, with the corrections, amendments, and
-   supplements contained in this RFC.
-
-   A good-faith implementation of the protocols that was produced after
-   careful reading of the RFC's and with some interaction with the
-   Internet technical community, and that followed good communications
-   software engineering practices, should differ from the requirements
-   of this document in only minor ways.  Thus, in many cases, the
-   "requirements" in this RFC are already stated or implied in the
-   standard protocol documents, so that their inclusion here is, in a
-   sense, redundant.  However, they were included because some past
-   implementation has made the wrong choice, causing problems of
-   interoperability, performance, and/or robustness.
-
-   This document includes discussion and explanation of many of the
-   requirements and recommendations.  A simple list of requirements
-   would be dangerous, because:
-
-   o    Some required features are more important than others, and some
-        features are optional.
-
-
-
-Internet Engineering Task Force                                 [Page 5]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-   o    There may be valid reasons why particular vendor products that
-        are designed for restricted contexts might choose to use
-        different specifications.
-
-   However, the specifications of this document must be followed to meet
-   the general goal of arbitrary host interoperation across the
-   diversity and complexity of the Internet system.  Although most
-   current implementations fail to meet these requirements in various
-   ways, some minor and some major, this specification is the ideal
-   towards which we need to move.
-
-   These requirements are based on the current level of Internet
-   architecture.  This document will be updated as required to provide
-   additional clarifications or to include additional information in
-   those areas in which specifications are still evolving.
-
-   This introductory section begins with a brief overview of the
-   Internet architecture as it relates to hosts, and then gives some
-   general advice to host software vendors.  Finally, there is some
-   guidance on reading the rest of the document and some terminology.
-
-   1.1  The Internet Architecture
-
-      General background and discussion on the Internet architecture and
-      supporting protocol suite can be found in the DDN Protocol
-      Handbook [INTRO:3]; for background see for example [INTRO:9],
-      [INTRO:10], and [INTRO:11].  Reference [INTRO:5] describes the
-      procedure for obtaining Internet protocol documents, while
-      [INTRO:6] contains a list of the numbers assigned within Internet
-      protocols.
-
-      1.1.1  Internet Hosts
-
-         A host computer, or simply "host," is the ultimate consumer of
-         communication services.  A host generally executes application
-         programs on behalf of user(s), employing network and/or
-         Internet communication services in support of this function.
-         An Internet host corresponds to the concept of an "End-System"
-         used in the OSI protocol suite [INTRO:13].
-
-         An Internet communication system consists of interconnected
-         packet networks supporting communication among host computers
-         using the Internet protocols.  The networks are interconnected
-         using packet-switching computers called "gateways" or "IP
-         routers" by the Internet community, and "Intermediate Systems"
-         by the OSI world [INTRO:13].  The RFC "Requirements for
-         Internet Gateways" [INTRO:2] contains the official
-         specifications for Internet gateways.  That RFC together with
-
-
-
-Internet Engineering Task Force                                 [Page 6]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         the present document and its companion [INTRO:1] define the
-         rules for the current realization of the Internet architecture.
-
-         Internet hosts span a wide range of size, speed, and function.
-         They range in size from small microprocessors through
-         workstations to mainframes and supercomputers.  In function,
-         they range from single-purpose hosts (such as terminal servers)
-         to full-service hosts that support a variety of online network
-         services, typically including remote login, file transfer, and
-         electronic mail.
-
-         A host is generally said to be multihomed if it has more than
-         one interface to the same or to different networks.  See
-         Section 1.1.3 on "Terminology".
-
-      1.1.2  Architectural Assumptions
-
-         The current Internet architecture is based on a set of
-         assumptions about the communication system.  The assumptions
-         most relevant to hosts are as follows:
-
-         (a)  The Internet is a network of networks.
-
-              Each host is directly connected to some particular
-              network(s); its connection to the Internet is only
-              conceptual.  Two hosts on the same network communicate
-              with each other using the same set of protocols that they
-              would use to communicate with hosts on distant networks.
-
-         (b)  Gateways don't keep connection state information.
-
-              To improve robustness of the communication system,
-              gateways are designed to be stateless, forwarding each IP
-              datagram independently of other datagrams.  As a result,
-              redundant paths can be exploited to provide robust service
-              in spite of failures of intervening gateways and networks.
-
-              All state information required for end-to-end flow control
-              and reliability is implemented in the hosts, in the
-              transport layer or in application programs.  All
-              connection control information is thus co-located with the
-              end points of the communication, so it will be lost only
-              if an end point fails.
-
-         (c)  Routing complexity should be in the gateways.
-
-              Routing is a complex and difficult problem, and ought to
-              be performed by the gateways, not the hosts.  An important
-
-
-
-Internet Engineering Task Force                                 [Page 7]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-              objective is to insulate host software from changes caused
-              by the inevitable evolution of the Internet routing
-              architecture.
-
-         (d)  The System must tolerate wide network variation.
-
-              A basic objective of the Internet design is to tolerate a
-              wide range of network characteristics -- e.g., bandwidth,
-              delay, packet loss, packet reordering, and maximum packet
-              size.  Another objective is robustness against failure of
-              individual networks, gateways, and hosts, using whatever
-              bandwidth is still available.  Finally, the goal is full
-              "open system interconnection": an Internet host must be
-              able to interoperate robustly and effectively with any
-              other Internet host, across diverse Internet paths.
-
-              Sometimes host implementors have designed for less
-              ambitious goals.  For example, the LAN environment is
-              typically much more benign than the Internet as a whole;
-              LANs have low packet loss and delay and do not reorder
-              packets.  Some vendors have fielded host implementations
-              that are adequate for a simple LAN environment, but work
-              badly for general interoperation.  The vendor justifies
-              such a product as being economical within the restricted
-              LAN market.  However, isolated LANs seldom stay isolated
-              for long; they are soon gatewayed to each other, to
-              organization-wide internets, and eventually to the global
-              Internet system.  In the end, neither the customer nor the
-              vendor is served by incomplete or substandard Internet
-              host software.
-
-              The requirements spelled out in this document are designed
-              for a full-function Internet host, capable of full
-              interoperation over an arbitrary Internet path.
-
-
-      1.1.3  Internet Protocol Suite
-
-         To communicate using the Internet system, a host must implement
-         the layered set of protocols comprising the Internet protocol
-         suite.  A host typically must implement at least one protocol
-         from each layer.
-
-         The protocol layers used in the Internet architecture are as
-         follows [INTRO:4]:
-
-
-         o  Application Layer
-
-
-
-Internet Engineering Task Force                                 [Page 8]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-              The application layer is the top layer of the Internet
-              protocol suite.  The Internet suite does not further
-              subdivide the application layer, although some of the
-              Internet application layer protocols do contain some
-              internal sub-layering.  The application layer of the
-              Internet suite essentially combines the functions of the
-              top two layers -- Presentation and Application -- of the
-              OSI reference model.
-
-              We distinguish two categories of application layer
-              protocols:  user protocols that provide service directly
-              to users, and support protocols that provide common system
-              functions.  Requirements for user and support protocols
-              will be found in the companion RFC [INTRO:1].
-
-              The most common Internet user protocols are:
-
-                o  Telnet (remote login)
-                o  FTP    (file transfer)
-                o  SMTP   (electronic mail delivery)
-
-              There are a number of other standardized user protocols
-              [INTRO:4] and many private user protocols.
-
-              Support protocols, used for host name mapping, booting,
-              and management, include SNMP, BOOTP, RARP, and the Domain
-              Name System (DNS) protocols.
-
-
-         o  Transport Layer
-
-              The transport layer provides end-to-end communication
-              services for applications.  There are two primary
-              transport layer protocols at present:
-
-                o Transmission Control Protocol (TCP)
-                o User Datagram Protocol (UDP)
-
-              TCP is a reliable connection-oriented transport service
-              that provides end-to-end reliability, resequencing, and
-              flow control.  UDP is a connectionless ("datagram")
-              transport service.
-
-              Other transport protocols have been developed by the
-              research community, and the set of official Internet
-              transport protocols may be expanded in the future.
-
-              Transport layer protocols are discussed in Chapter 4.
-
-
-
-Internet Engineering Task Force                                 [Page 9]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         o  Internet Layer
-
-              All Internet transport protocols use the Internet Protocol
-              (IP) to carry data from source host to destination host.
-              IP is a connectionless or datagram internetwork service,
-              providing no end-to-end delivery guarantees. Thus, IP
-              datagrams may arrive at the destination host damaged,
-              duplicated, out of order, or not at all.  The layers above
-              IP are responsible for reliable delivery service when it
-              is required.  The IP protocol includes provision for
-              addressing, type-of-service specification, fragmentation
-              and reassembly, and security information.
-
-              The datagram or connectionless nature of the IP protocol
-              is a fundamental and characteristic feature of the
-              Internet architecture.  Internet IP was the model for the
-              OSI Connectionless Network Protocol [INTRO:12].
-
-              ICMP is a control protocol that is considered to be an
-              integral part of IP, although it is architecturally
-              layered upon IP, i.e., it uses IP to carry its data end-
-              to-end just as a transport protocol like TCP or UDP does.
-              ICMP provides error reporting, congestion reporting, and
-              first-hop gateway redirection.
-
-              IGMP is an Internet layer protocol used for establishing
-              dynamic host groups for IP multicasting.
-
-              The Internet layer protocols IP, ICMP, and IGMP are
-              discussed in Chapter 3.
-
-
-         o  Link Layer
-
-              To communicate on its directly-connected network, a host
-              must implement the communication protocol used to
-              interface to that network.  We call this a link layer or
-              media-access layer protocol.
-
-              There is a wide variety of link layer protocols,
-              corresponding to the many different types of networks.
-              See Chapter 2.
-
-
-      1.1.4  Embedded Gateway Code
-
-         Some Internet host software includes embedded gateway
-         functionality, so that these hosts can forward packets as a
-
-
-
-Internet Engineering Task Force                                [Page 10]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         gateway would, while still performing the application layer
-         functions of a host.
-
-         Such dual-purpose systems must follow the Gateway Requirements
-         RFC [INTRO:2]  with respect to their gateway functions, and
-         must follow the present document with respect to their host
-         functions.  In all overlapping cases, the two specifications
-         should be in agreement.
-
-         There are varying opinions in the Internet community about
-         embedded gateway functionality.  The main arguments are as
-         follows:
-
-         o    Pro: in a local network environment where networking is
-              informal, or in isolated internets, it may be convenient
-              and economical to use existing host systems as gateways.
-
-              There is also an architectural argument for embedded
-              gateway functionality: multihoming is much more common
-              than originally foreseen, and multihoming forces a host to
-              make routing decisions as if it were a gateway.  If the
-              multihomed  host contains an embedded gateway, it will
-              have full routing knowledge and as a result will be able
-              to make more optimal routing decisions.
-
-         o    Con: Gateway algorithms and protocols are still changing,
-              and they will continue to change as the Internet system
-              grows larger.  Attempting to include a general gateway
-              function within the host IP layer will force host system
-              maintainers to track these (more frequent) changes.  Also,
-              a larger pool of gateway implementations will make
-              coordinating the changes more difficult.  Finally, the
-              complexity of a gateway IP layer is somewhat greater than
-              that of a host, making the implementation and operation
-              tasks more complex.
-
-              In addition, the style of operation of some hosts is not
-              appropriate for providing stable and robust gateway
-              service.
-
-         There is considerable merit in both of these viewpoints.  One
-         conclusion can be drawn: an host administrator must have
-         conscious control over whether or not a given host acts as a
-         gateway.  See Section 3.1 for the detailed requirements.
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 11]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-   1.2  General Considerations
-
-      There are two important lessons that vendors of Internet host
-      software have learned and which a new vendor should consider
-      seriously.
-
-      1.2.1  Continuing Internet Evolution
-
-         The enormous growth of the Internet has revealed problems of
-         management and scaling in a large datagram-based packet
-         communication system.  These problems are being addressed, and
-         as a result there will be continuing evolution of the
-         specifications described in this document.  These changes will
-         be carefully planned and controlled, since there is extensive
-         participation in this planning by the vendors and by the
-         organizations responsible for operations of the networks.
-
-         Development, evolution, and revision are characteristic of
-         computer network protocols today, and this situation will
-         persist for some years.  A vendor who develops computer
-         communication software for the Internet protocol suite (or any
-         other protocol suite!) and then fails to maintain and update
-         that software for changing specifications is going to leave a
-         trail of unhappy customers.  The Internet is a large
-         communication network, and the users are in constant contact
-         through it.  Experience has shown that knowledge of
-         deficiencies in vendor software propagates quickly through the
-         Internet technical community.
-
-      1.2.2  Robustness Principle
-
-         At every layer of the protocols, there is a general rule whose
-         application can lead to enormous benefits in robustness and
-         interoperability [IP:1]:
-
-                "Be liberal in what you accept, and
-                 conservative in what you send"
-
-         Software should be written to deal with every conceivable
-         error, no matter how unlikely; sooner or later a packet will
-         come in with that particular combination of errors and
-         attributes, and unless the software is prepared, chaos can
-         ensue.  In general, it is best to assume that the network is
-         filled with malevolent entities that will send in packets
-         designed to have the worst possible effect.  This assumption
-         will lead to suitable protective design, although the most
-         serious problems in the Internet have been caused by
-         unenvisaged mechanisms triggered by low-probability events;
-
-
-
-Internet Engineering Task Force                                [Page 12]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         mere human malice would never have taken so devious a course!
-
-         Adaptability to change must be designed into all levels of
-         Internet host software.  As a simple example, consider a
-         protocol specification that contains an enumeration of values
-         for a particular header field -- e.g., a type field, a port
-         number, or an error code; this enumeration must be assumed to
-         be incomplete.  Thus, if a protocol specification defines four
-         possible error codes, the software must not break when a fifth
-         code shows up.  An undefined code might be logged (see below),
-         but it must not cause a failure.
-
-         The second part of the principle is almost as important:
-         software on other hosts may contain deficiencies that make it
-         unwise to exploit legal but obscure protocol features.  It is
-         unwise to stray far from the obvious and simple, lest untoward
-         effects result elsewhere.  A corollary of this is "watch out
-         for misbehaving hosts"; host software should be prepared, not
-         just to survive other misbehaving hosts, but also to cooperate
-         to limit the amount of disruption such hosts can cause to the
-         shared communication facility.
-
-      1.2.3  Error Logging
-
-         The Internet includes a great variety of host and gateway
-         systems, each implementing many protocols and protocol layers,
-         and some of these contain bugs and mis-features in their
-         Internet protocol software.  As a result of complexity,
-         diversity, and distribution of function, the diagnosis of
-         Internet problems is often very difficult.
-
-         Problem diagnosis will be aided if host implementations include
-         a carefully designed facility for logging erroneous or
-         "strange" protocol events.  It is important to include as much
-         diagnostic information as possible when an error is logged.  In
-         particular, it is often useful to record the header(s) of a
-         packet that caused an error.  However, care must be taken to
-         ensure that error logging does not consume prohibitive amounts
-         of resources or otherwise interfere with the operation of the
-         host.
-
-         There is a tendency for abnormal but harmless protocol events
-         to overflow error logging files; this can be avoided by using a
-         "circular" log, or by enabling logging only while diagnosing a
-         known failure.  It may be useful to filter and count duplicate
-         successive messages.  One strategy that seems to work well is:
-         (1) always count abnormalities and make such counts accessible
-         through the management protocol (see [INTRO:1]); and (2) allow
-
-
-
-Internet Engineering Task Force                                [Page 13]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         the logging of a great variety of events to be selectively
-         enabled.  For example, it might useful to be able to "log
-         everything" or to "log everything for host X".
-
-         Note that different managements may have differing policies
-         about the amount of error logging that they want normally
-         enabled in a host.  Some will say, "if it doesn't hurt me, I
-         don't want to know about it", while others will want to take a
-         more watchful and aggressive attitude about detecting and
-         removing protocol abnormalities.
-
-      1.2.4  Configuration
-
-         It would be ideal if a host implementation of the Internet
-         protocol suite could be entirely self-configuring.  This would
-         allow the whole suite to be implemented in ROM or cast into
-         silicon, it would simplify diskless workstations, and it would
-         be an immense boon to harried LAN administrators as well as
-         system vendors.  We have not reached this ideal; in fact, we
-         are not even close.
-
-         At many points in this document, you will find a requirement
-         that a parameter be a configurable option.  There are several
-         different reasons behind such requirements.  In a few cases,
-         there is current uncertainty or disagreement about the best
-         value, and it may be necessary to update the recommended value
-         in the future.  In other cases, the value really depends on
-         external factors -- e.g., the size of the host and the
-         distribution of its communication load, or the speeds and
-         topology of nearby networks -- and self-tuning algorithms are
-         unavailable and may be insufficient.  In some cases,
-         configurability is needed because of administrative
-         requirements.
-
-         Finally, some configuration options are required to communicate
-         with obsolete or incorrect implementations of the protocols,
-         distributed without sources, that unfortunately persist in many
-         parts of the Internet.  To make correct systems coexist with
-         these faulty systems, administrators often have to "mis-
-         configure" the correct systems.  This problem will correct
-         itself gradually as the faulty systems are retired, but it
-         cannot be ignored by vendors.
-
-         When we say that a parameter must be configurable, we do not
-         intend to require that its value be explicitly read from a
-         configuration file at every boot time.  We recommend that
-         implementors set up a default for each parameter, so a
-         configuration file is only necessary to override those defaults
-
-
-
-Internet Engineering Task Force                                [Page 14]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         that are inappropriate in a particular installation.  Thus, the
-         configurability requirement is an assurance that it will be
-         POSSIBLE to override the default when necessary, even in a
-         binary-only or ROM-based product.
-
-         This document requires a particular value for such defaults in
-         some cases.  The choice of default is a sensitive issue when
-         the configuration item controls the accommodation to existing
-         faulty systems.  If the Internet is to converge successfully to
-         complete interoperability, the default values built into
-         implementations must implement the official protocol, not
-         "mis-configurations" to accommodate faulty implementations.
-         Although marketing considerations have led some vendors to
-         choose mis-configuration defaults, we urge vendors to choose
-         defaults that will conform to the standard.
-
-         Finally, we note that a vendor needs to provide adequate
-         documentation on all configuration parameters, their limits and
-         effects.
-
-
-   1.3  Reading this Document
-
-      1.3.1  Organization
-
-         Protocol layering, which is generally used as an organizing
-         principle in implementing network software, has also been used
-         to organize this document.  In describing the rules, we assume
-         that an implementation does strictly mirror the layering of the
-         protocols.  Thus, the following three major sections specify
-         the requirements for the link layer, the internet layer, and
-         the transport layer, respectively.  A companion RFC [INTRO:1]
-         covers application level software.  This layerist organization
-         was chosen for simplicity and clarity.
-
-         However, strict layering is an imperfect model, both for the
-         protocol suite and for recommended implementation approaches.
-         Protocols in different layers interact in complex and sometimes
-         subtle ways, and particular functions often involve multiple
-         layers.  There are many design choices in an implementation,
-         many of which involve creative "breaking" of strict layering.
-         Every implementor is urged to read references [INTRO:7] and
-         [INTRO:8].
-
-         This document describes the conceptual service interface
-         between layers using a functional ("procedure call") notation,
-         like that used in the TCP specification [TCP:1].  A host
-         implementation must support the logical information flow
-
-
-
-Internet Engineering Task Force                                [Page 15]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         implied by these calls, but need not literally implement the
-         calls themselves.  For example, many implementations reflect
-         the coupling between the transport layer and the IP layer by
-         giving them shared access to common data structures.  These
-         data structures, rather than explicit procedure calls, are then
-         the agency for passing much of the information that is
-         required.
-
-         In general, each major section of this document is organized
-         into the following subsections:
-
-         (1)  Introduction
-
-         (2)  Protocol Walk-Through -- considers the protocol
-              specification documents section-by-section, correcting
-              errors, stating requirements that may be ambiguous or
-              ill-defined, and providing further clarification or
-              explanation.
-
-         (3)  Specific Issues -- discusses protocol design and
-              implementation issues that were not included in the walk-
-              through.
-
-         (4)  Interfaces -- discusses the service interface to the next
-              higher layer.
-
-         (5)  Summary -- contains a summary of the requirements of the
-              section.
-
-
-         Under many of the individual topics in this document, there is
-         parenthetical material labeled "DISCUSSION" or
-         "IMPLEMENTATION". This material is intended to give
-         clarification and explanation of the preceding requirements
-         text.  It also includes some suggestions on possible future
-         directions or developments.  The implementation material
-         contains suggested approaches that an implementor may want to
-         consider.
-
-         The summary sections are intended to be guides and indexes to
-         the text, but are necessarily cryptic and incomplete.  The
-         summaries should never be used or referenced separately from
-         the complete RFC.
-
-      1.3.2  Requirements
-
-         In this document, the words that are used to define the
-         significance of each particular requirement are capitalized.
-
-
-
-Internet Engineering Task Force                                [Page 16]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         These words are:
-
-         *    "MUST"
-
-              This word or the adjective "REQUIRED" means that the item
-              is an absolute requirement of the specification.
-
-         *    "SHOULD"
-
-              This word or the adjective "RECOMMENDED" means that there
-              may exist valid reasons in particular circumstances to
-              ignore this item, but the full implications should be
-              understood and the case carefully weighed before choosing
-              a different course.
-
-         *    "MAY"
-
-              This word or the adjective "OPTIONAL" means that this item
-              is truly optional.  One vendor may choose to include the
-              item because a particular marketplace requires it or
-              because it enhances the product, for example; another
-              vendor may omit the same item.
-
-
-         An implementation is not compliant if it fails to satisfy one
-         or more of the MUST requirements for the protocols it
-         implements.  An implementation that satisfies all the MUST and
-         all the SHOULD requirements for its protocols is said to be
-         "unconditionally compliant"; one that satisfies all the MUST
-         requirements but not all the SHOULD requirements for its
-         protocols is said to be "conditionally compliant".
-
-      1.3.3  Terminology
-
-         This document uses the following technical terms:
-
-         Segment
-              A segment is the unit of end-to-end transmission in the
-              TCP protocol.  A segment consists of a TCP header followed
-              by application data.  A segment is transmitted by
-              encapsulation inside an IP datagram.
-
-         Message
-              In this description of the lower-layer protocols, a
-              message is the unit of transmission in a transport layer
-              protocol.  In particular, a TCP segment is a message.  A
-              message consists of a transport protocol header followed
-              by application protocol data.  To be transmitted end-to-
-
-
-
-Internet Engineering Task Force                                [Page 17]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-              end through the Internet, a message must be encapsulated
-              inside a datagram.
-
-         IP Datagram
-              An IP datagram is the unit of end-to-end transmission in
-              the IP protocol.  An IP datagram consists of an IP header
-              followed by transport layer data, i.e., of an IP header
-              followed by a message.
-
-              In the description of the internet layer (Section 3), the
-              unqualified term "datagram" should be understood to refer
-              to an IP datagram.
-
-         Packet
-              A packet is the unit of data passed across the interface
-              between the internet layer and the link layer.  It
-              includes an IP header and data.  A packet may be a
-              complete IP datagram or a fragment of an IP datagram.
-
-         Frame
-              A frame is the unit of transmission in a link layer
-              protocol, and consists of a link-layer header followed by
-              a packet.
-
-         Connected Network
-              A network to which a host is interfaced is often known as
-              the "local network" or the "subnetwork" relative to that
-              host.  However, these terms can cause confusion, and
-              therefore we use the term "connected network" in this
-              document.
-
-         Multihomed
-              A host is said to be multihomed if it has multiple IP
-              addresses.  For a discussion of multihoming, see Section
-              3.3.4 below.
-
-         Physical network interface
-              This is a physical interface to a connected network and
-              has a (possibly unique) link-layer address.  Multiple
-              physical network interfaces on a single host may share the
-              same link-layer address, but the address must be unique
-              for different hosts on the same physical network.
-
-         Logical [network] interface
-              We define a logical [network] interface to be a logical
-              path, distinguished by a unique IP address, to a connected
-              network.  See Section 3.3.4.
-
-
-
-
-Internet Engineering Task Force                                [Page 18]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-         Specific-destination address
-              This is the effective destination address of a datagram,
-              even if it is broadcast or multicast; see Section 3.2.1.3.
-
-         Path
-              At a given moment, all the IP datagrams from a particular
-              source host to a particular destination host will
-              typically traverse the same sequence of gateways.  We use
-              the term "path" for this sequence.  Note that a path is
-              uni-directional; it is not unusual to have different paths
-              in the two directions between a given host pair.
-
-         MTU
-              The maximum transmission unit, i.e., the size of the
-              largest packet that can be transmitted.
-
-
-         The terms frame, packet, datagram, message, and segment are
-         illustrated by the following schematic diagrams:
-
-         A. Transmission on connected network:
-           _______________________________________________
-          | LL hdr | IP hdr |         (data)              |
-          |________|________|_____________________________|
-
-           <---------- Frame ----------------------------->
-                    <----------Packet -------------------->
-
-
-         B. Before IP fragmentation or after IP reassembly:
-                    ______________________________________
-                   | IP hdr | transport| Application Data |
-                   |________|____hdr___|__________________|
-
-                    <--------  Datagram ------------------>
-                             <-------- Message ----------->
-           or, for TCP:
-                    ______________________________________
-                   | IP hdr |  TCP hdr | Application Data |
-                   |________|__________|__________________|
-
-                    <--------  Datagram ------------------>
-                             <-------- Segment ----------->
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 19]
-
-
-
-
-RFC1122                       INTRODUCTION                  October 1989
-
-
-   1.4  Acknowledgments
-
-      This document incorporates contributions and comments from a large
-      group of Internet protocol experts, including representatives of
-      university and research labs, vendors, and government agencies.
-      It was assembled primarily by the Host Requirements Working Group
-      of the Internet Engineering Task Force (IETF).
-
-      The Editor would especially like to acknowledge the tireless
-      dedication of the following people, who attended many long
-      meetings and generated 3 million bytes of electronic mail over the
-      past 18 months in pursuit of this document: Philip Almquist, Dave
-      Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve
-      Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore),
-      John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG),
-      Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge
-      (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).
-
-      In addition, the following people made major contributions to the
-      effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia
-      (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),
-      Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL),
-      John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill
-      Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul
-      (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue
-      Technology), and Mike StJohns (DCA).  The following also made
-      significant contributions to particular areas: Eric Allman
-      (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic
-      (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn
-      (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann
-      (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun
-      Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen
-      (Toronto).
-
-      We are grateful to all, including any contributors who may have
-      been inadvertently omitted from this list.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 20]
-
-
-
-
-RFC1122                        LINK LAYER                   October 1989
-
-
-2. LINK LAYER
-
-   2.1  INTRODUCTION
-
-      All Internet systems, both hosts and gateways, have the same
-      requirements for link layer protocols.  These requirements are
-      given in Chapter 3 of "Requirements for Internet Gateways"
-      [INTRO:2], augmented with the material in this section.
-
-   2.2  PROTOCOL WALK-THROUGH
-
-      None.
-
-   2.3  SPECIFIC ISSUES
-
-      2.3.1  Trailer Protocol Negotiation
-
-         The trailer protocol [LINK:1] for link-layer encapsulation MAY
-         be used, but only when it has been verified that both systems
-         (host or gateway) involved in the link-layer communication
-         implement trailers.  If the system does not dynamically
-         negotiate use of the trailer protocol on a per-destination
-         basis, the default configuration MUST disable the protocol.
-
-         DISCUSSION:
-              The trailer protocol is a link-layer encapsulation
-              technique that rearranges the data contents of packets
-              sent on the physical network.  In some cases, trailers
-              improve the throughput of higher layer protocols by
-              reducing the amount of data copying within the operating
-              system.  Higher layer protocols are unaware of trailer
-              use, but both the sending and receiving host MUST
-              understand the protocol if it is used.
-
-              Improper use of trailers can result in very confusing
-              symptoms.  Only packets with specific size attributes are
-              encapsulated using trailers, and typically only a small
-              fraction of the packets being exchanged have these
-              attributes.  Thus, if a system using trailers exchanges
-              packets with a system that does not, some packets
-              disappear into a black hole while others are delivered
-              successfully.
-
-         IMPLEMENTATION:
-              On an Ethernet, packets encapsulated with trailers use a
-              distinct Ethernet type [LINK:1], and trailer negotiation
-              is performed at the time that ARP is used to discover the
-              link-layer address of a destination system.
-
-
-
-Internet Engineering Task Force                                [Page 21]
-
-
-
-
-RFC1122                        LINK LAYER                   October 1989
-
-
-              Specifically, the ARP exchange is completed in the usual
-              manner using the normal IP protocol type, but a host that
-              wants to speak trailers will send an additional "trailer
-              ARP reply" packet, i.e., an ARP reply that specifies the
-              trailer encapsulation protocol type but otherwise has the
-              format of a normal ARP reply.  If a host configured to use
-              trailers receives a trailer ARP reply message from a
-              remote machine, it can add that machine to the list of
-              machines that understand trailers, e.g., by marking the
-              corresponding entry in the ARP cache.
-
-              Hosts wishing to receive trailer encapsulations send
-              trailer ARP replies whenever they complete exchanges of
-              normal ARP messages for IP.  Thus, a host that received an
-              ARP request for its IP protocol address would send a
-              trailer ARP reply in addition to the normal IP ARP reply;
-              a host that sent the IP ARP request would send a trailer
-              ARP reply when it received the corresponding IP ARP reply.
-              In this way, either the requesting or responding host in
-              an IP ARP exchange may request that it receive trailer
-              encapsulations.
-
-              This scheme, using extra trailer ARP reply packets rather
-              than sending an ARP request for the trailer protocol type,
-              was designed to avoid a continuous exchange of ARP packets
-              with a misbehaving host that, contrary to any
-              specification or common sense, responded to an ARP reply
-              for trailers with another ARP reply for IP.  This problem
-              is avoided by sending a trailer ARP reply in response to
-              an IP ARP reply only when the IP ARP reply answers an
-              outstanding request; this is true when the hardware
-              address for the host is still unknown when the IP ARP
-              reply is received.  A trailer ARP reply may always be sent
-              along with an IP ARP reply responding to an IP ARP
-              request.
-
-      2.3.2  Address Resolution Protocol -- ARP
-
-         2.3.2.1  ARP Cache Validation
-
-            An implementation of the Address Resolution Protocol (ARP)
-            [LINK:2] MUST provide a mechanism to flush out-of-date cache
-            entries.  If this mechanism involves a timeout, it SHOULD be
-            possible to configure the timeout value.
-
-            A mechanism to prevent ARP flooding (repeatedly sending an
-            ARP Request for the same IP address, at a high rate) MUST be
-            included.  The recommended maximum rate is 1 per second per
-
-
-
-Internet Engineering Task Force                                [Page 22]
-
-
-
-
-RFC1122                        LINK LAYER                   October 1989
-
-
-            destination.
-
-            DISCUSSION:
-                 The ARP specification [LINK:2] suggests but does not
-                 require a timeout mechanism to invalidate cache entries
-                 when hosts change their Ethernet addresses.  The
-                 prevalence of proxy ARP (see Section 2.4 of [INTRO:2])
-                 has significantly increased the likelihood that cache
-                 entries in hosts will become invalid, and therefore
-                 some ARP-cache invalidation mechanism is now required
-                 for hosts.  Even in the absence of proxy ARP, a long-
-                 period cache timeout is useful in order to
-                 automatically correct any bad ARP data that might have
-                 been cached.
-
-            IMPLEMENTATION:
-                 Four mechanisms have been used, sometimes in
-                 combination, to flush out-of-date cache entries.
-
-                 (1)  Timeout -- Periodically time out cache entries,
-                      even if they are in use.  Note that this timeout
-                      should be restarted when the cache entry is
-                      "refreshed" (by observing the source fields,
-                      regardless of target address, of an ARP broadcast
-                      from the system in question).  For proxy ARP
-                      situations, the timeout needs to be on the order
-                      of a minute.
-
-                 (2)  Unicast Poll -- Actively poll the remote host by
-                      periodically sending a point-to-point ARP Request
-                      to it, and delete the entry if no ARP Reply is
-                      received from N successive polls.  Again, the
-                      timeout should be on the order of a minute, and
-                      typically N is 2.
-
-                 (3)  Link-Layer Advice -- If the link-layer driver
-                      detects a delivery problem, flush the
-                      corresponding ARP cache entry.
-
-                 (4)  Higher-layer Advice -- Provide a call from the
-                      Internet layer to the link layer to indicate a
-                      delivery problem.  The effect of this call would
-                      be to invalidate the corresponding cache entry.
-                      This call would be analogous to the
-                      "ADVISE_DELIVPROB()" call from the transport layer
-                      to the Internet layer (see Section 3.4), and in
-                      fact the ADVISE_DELIVPROB routine might in turn
-                      call the link-layer advice routine to invalidate
-
-
-
-Internet Engineering Task Force                                [Page 23]
-
-
-
-
-RFC1122                        LINK LAYER                   October 1989
-
-
-                      the ARP cache entry.
-
-                 Approaches (1) and (2) involve ARP cache timeouts on
-                 the order of a minute or less.  In the absence of proxy
-                 ARP, a timeout this short could create noticeable
-                 overhead traffic on a very large Ethernet.  Therefore,
-                 it may be necessary to configure a host to lengthen the
-                 ARP cache timeout.
-
-         2.3.2.2  ARP Packet Queue
-
-            The link layer SHOULD save (rather than discard) at least
-            one (the latest) packet of each set of packets destined to
-            the same unresolved IP address, and transmit the saved
-            packet when the address has been resolved.
-
-            DISCUSSION:
-                 Failure to follow this recommendation causes the first
-                 packet of every exchange to be lost.  Although higher-
-                 layer protocols can generally cope with packet loss by
-                 retransmission, packet loss does impact performance.
-                 For example, loss of a TCP open request causes the
-                 initial round-trip time estimate to be inflated.  UDP-
-                 based applications such as the Domain Name System are
-                 more seriously affected.
-
-      2.3.3  Ethernet and IEEE 802 Encapsulation
-
-         The IP encapsulation for Ethernets is described in RFC-894
-         [LINK:3], while RFC-1042 [LINK:4] describes the IP
-         encapsulation for IEEE 802 networks.  RFC-1042 elaborates and
-         replaces the discussion in Section 3.4 of [INTRO:2].
-
-         Every Internet host connected to a 10Mbps Ethernet cable:
-
-         o    MUST be able to send and receive packets using RFC-894
-              encapsulation;
-
-         o    SHOULD be able to receive RFC-1042 packets, intermixed
-              with RFC-894 packets; and
-
-         o    MAY be able to send packets using RFC-1042 encapsulation.
-
-
-         An Internet host that implements sending both the RFC-894 and
-         the RFC-1042 encapsulations MUST provide a configuration switch
-         to select which is sent, and this switch MUST default to RFC-
-         894.
-
-
-
-Internet Engineering Task Force                                [Page 24]
-
-
-
-
-RFC1122                        LINK LAYER                   October 1989
-
-
-         Note that the standard IP encapsulation in RFC-1042 does not
-         use the protocol id value (K1=6) that IEEE reserved for IP;
-         instead, it uses a value (K1=170) that implies an extension
-         (the "SNAP") which can be used to hold the Ether-Type field.
-         An Internet system MUST NOT send 802 packets using K1=6.
-
-         Address translation from Internet addresses to link-layer
-         addresses on Ethernet and IEEE 802 networks MUST be managed by
-         the Address Resolution Protocol (ARP).
-
-         The MTU for an Ethernet is 1500 and for 802.3 is 1492.
-
-         DISCUSSION:
-              The IEEE 802.3 specification provides for operation over a
-              10Mbps Ethernet cable, in which case Ethernet and IEEE
-              802.3 frames can be physically intermixed.  A receiver can
-              distinguish Ethernet and 802.3 frames by the value of the
-              802.3 Length field; this two-octet field coincides in the
-              header with the Ether-Type field of an Ethernet frame.  In
-              particular, the 802.3 Length field must be less than or
-              equal to 1500, while all valid Ether-Type values are
-              greater than 1500.
-
-              Another compatibility problem arises with link-layer
-              broadcasts.  A broadcast sent with one framing will not be
-              seen by hosts that can receive only the other framing.
-
-              The provisions of this section were designed to provide
-              direct interoperation between 894-capable and 1042-capable
-              systems on the same cable, to the maximum extent possible.
-              It is intended to support the present situation where
-              894-only systems predominate, while providing an easy
-              transition to a possible future in which 1042-capable
-              systems become common.
-
-              Note that 894-only systems cannot interoperate directly
-              with 1042-only systems.  If the two system types are set
-              up as two different logical networks on the same cable,
-              they can communicate only through an IP gateway.
-              Furthermore, it is not useful or even possible for a
-              dual-format host to discover automatically which format to
-              send, because of the problem of link-layer broadcasts.
-
-   2.4  LINK/INTERNET LAYER INTERFACE
-
-      The packet receive interface between the IP layer and the link
-      layer MUST include a flag to indicate whether the incoming packet
-      was addressed to a link-layer broadcast address.
-
-
-
-Internet Engineering Task Force                                [Page 25]
-
-
-
-
-RFC1122                        LINK LAYER                   October 1989
-
-
-      DISCUSSION
-           Although the IP layer does not generally know link layer
-           addresses (since every different network medium typically has
-           a different address format), the broadcast address on a
-           broadcast-capable medium is an important special case.  See
-           Section 3.2.2, especially the DISCUSSION concerning broadcast
-           storms.
-
-      The packet send interface between the IP and link layers MUST
-      include the 5-bit TOS field (see Section 3.2.1.6).
-
-      The link layer MUST NOT report a Destination Unreachable error to
-      IP solely because there is no ARP cache entry for a destination.
-
-   2.5  LINK LAYER REQUIREMENTS SUMMARY
-
-                                                  |       | | | |S| |
-                                                  |       | | | |H| |F
-                                                  |       | | | |O|M|o
-                                                  |       | |S| |U|U|o
-                                                  |       | |H| |L|S|t
-                                                  |       |M|O| |D|T|n
-                                                  |       |U|U|M| | |o
-                                                  |       |S|L|A|N|N|t
-                                                  |       |T|D|Y|O|O|t
-FEATURE                                           |SECTION| | | |T|T|e
---------------------------------------------------|-------|-|-|-|-|-|--
-                                                  |       | | | | | |
-Trailer encapsulation                             |2.3.1  | | |x| | |
-Send Trailers by default without negotiation      |2.3.1  | | | | |x|
-ARP                                               |2.3.2  | | | | | |
-  Flush out-of-date ARP cache entries             |2.3.2.1|x| | | | |
-  Prevent ARP floods                              |2.3.2.1|x| | | | |
-  Cache timeout configurable                      |2.3.2.1| |x| | | |
-  Save at least one (latest) unresolved pkt       |2.3.2.2| |x| | | |
-Ethernet and IEEE 802 Encapsulation               |2.3.3  | | | | | |
-  Host able to:                                   |2.3.3  | | | | | |
-    Send & receive RFC-894 encapsulation          |2.3.3  |x| | | | |
-    Receive RFC-1042 encapsulation                |2.3.3  | |x| | | |
-    Send RFC-1042 encapsulation                   |2.3.3  | | |x| | |
-      Then config. sw. to select, RFC-894 dflt    |2.3.3  |x| | | | |
-  Send K1=6 encapsulation                         |2.3.3  | | | | |x|
-  Use ARP on Ethernet and IEEE 802 nets           |2.3.3  |x| | | | |
-Link layer report b'casts to IP layer             |2.4    |x| | | | |
-IP layer pass TOS to link layer                   |2.4    |x| | | | |
-No ARP cache entry treated as Dest. Unreach.      |2.4    | | | | |x|
-
-
-
-
-
-Internet Engineering Task Force                                [Page 26]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-3. INTERNET LAYER PROTOCOLS
-
-   3.1 INTRODUCTION
-
-      The Robustness Principle: "Be liberal in what you accept, and
-      conservative in what you send" is particularly important in the
-      Internet layer, where one misbehaving host can deny Internet
-      service to many other hosts.
-
-      The protocol standards used in the Internet layer are:
-
-      o    RFC-791 [IP:1] defines the IP protocol and gives an
-           introduction to the architecture of the Internet.
-
-      o    RFC-792 [IP:2] defines ICMP, which provides routing,
-           diagnostic and error functionality for IP.  Although ICMP
-           messages are encapsulated within IP datagrams, ICMP
-           processing is considered to be (and is typically implemented
-           as) part of the IP layer.  See Section 3.2.2.
-
-      o    RFC-950 [IP:3] defines the mandatory subnet extension to the
-           addressing architecture.
-
-      o    RFC-1112 [IP:4] defines the Internet Group Management
-           Protocol IGMP, as part of a recommended extension to hosts
-           and to the host-gateway interface to support Internet-wide
-           multicasting at the IP level.  See Section 3.2.3.
-
-           The target of an IP multicast may be an arbitrary group of
-           Internet hosts.  IP multicasting is designed as a natural
-           extension of the link-layer multicasting facilities of some
-           networks, and it provides a standard means for local access
-           to such link-layer multicasting facilities.
-
-      Other important references are listed in Section 5 of this
-      document.
-
-      The Internet layer of host software MUST implement both IP and
-      ICMP.  See Section 3.3.7 for the requirements on support of IGMP.
-
-      The host IP layer has two basic functions:  (1) choose the "next
-      hop" gateway or host for outgoing IP datagrams and (2) reassemble
-      incoming IP datagrams.  The IP layer may also (3) implement
-      intentional fragmentation of outgoing datagrams.  Finally, the IP
-      layer must (4) provide diagnostic and error functionality.  We
-      expect that IP layer functions may increase somewhat in the
-      future, as further Internet control and management facilities are
-      developed.
-
-
-
-Internet Engineering Task Force                                [Page 27]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-      For normal datagrams, the processing is straightforward.  For
-      incoming datagrams, the IP layer:
-
-      (1)  verifies that the datagram is correctly formatted;
-
-      (2)  verifies that it is destined to the local host;
-
-      (3)  processes options;
-
-      (4)  reassembles the datagram if necessary; and
-
-      (5)  passes the encapsulated message to the appropriate
-           transport-layer protocol module.
-
-      For outgoing datagrams, the IP layer:
-
-      (1)  sets any fields not set by the transport layer;
-
-      (2)  selects the correct first hop on the connected network (a
-           process called "routing");
-
-      (3)  fragments the datagram if necessary and if intentional
-           fragmentation is implemented (see Section 3.3.3); and
-
-      (4)  passes the packet(s) to the appropriate link-layer driver.
-
-
-      A host is said to be multihomed if it has multiple IP addresses.
-      Multihoming introduces considerable confusion and complexity into
-      the protocol suite, and it is an area in which the Internet
-      architecture falls seriously short of solving all problems.  There
-      are two distinct problem areas in multihoming:
-
-      (1)  Local multihoming --  the host itself is multihomed; or
-
-      (2)  Remote multihoming -- the local host needs to communicate
-           with a remote multihomed host.
-
-      At present, remote multihoming MUST be handled at the application
-      layer, as discussed in the companion RFC [INTRO:1].  A host MAY
-      support local multihoming, which is discussed in this document,
-      and in particular in Section 3.3.4.
-
-      Any host that forwards datagrams generated by another host is
-      acting as a gateway and MUST also meet the specifications laid out
-      in the gateway requirements RFC [INTRO:2].  An Internet host that
-      includes embedded gateway code MUST have a configuration switch to
-      disable the gateway function, and this switch MUST default to the
-
-
-
-Internet Engineering Task Force                                [Page 28]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-      non-gateway mode.  In this mode, a datagram arriving through one
-      interface will not be forwarded to another host or gateway (unless
-      it is source-routed), regardless of whether the host is single-
-      homed or multihomed.  The host software MUST NOT automatically
-      move into gateway mode if the host has more than one interface, as
-      the operator of the machine may neither want to provide that
-      service nor be competent to do so.
-
-      In the following, the action specified in certain cases is to
-      "silently discard" a received datagram.  This means that the
-      datagram will be discarded without further processing and that the
-      host will not send any ICMP error message (see Section 3.2.2) as a
-      result.  However, for diagnosis of problems a host SHOULD provide
-      the capability of logging the error (see Section 1.2.3), including
-      the contents of the silently-discarded datagram, and SHOULD record
-      the event in a statistics counter.
-
-      DISCUSSION:
-           Silent discard of erroneous datagrams is generally intended
-           to prevent "broadcast storms".
-
-   3.2  PROTOCOL WALK-THROUGH
-
-      3.2.1 Internet Protocol -- IP
-
-         3.2.1.1  Version Number: RFC-791 Section 3.1
-
-            A datagram whose version number is not 4 MUST be silently
-            discarded.
-
-         3.2.1.2  Checksum: RFC-791 Section 3.1
-
-            A host MUST verify the IP header checksum on every received
-            datagram and silently discard every datagram that has a bad
-            checksum.
-
-         3.2.1.3  Addressing: RFC-791 Section 3.2
-
-            There are now five classes of IP addresses: Class A through
-            Class E.  Class D addresses are used for IP multicasting
-            [IP:4], while Class E addresses are reserved for
-            experimental use.
-
-            A multicast (Class D) address is a 28-bit logical address
-            that stands for a group of hosts, and may be either
-            permanent or transient.  Permanent multicast addresses are
-            allocated by the Internet Assigned Number Authority
-            [INTRO:6], while transient addresses may be allocated
-
-
-
-Internet Engineering Task Force                                [Page 29]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            dynamically to transient groups.  Group membership is
-            determined dynamically using IGMP [IP:4].
-
-            We now summarize the important special cases for Class A, B,
-            and C IP addresses, using the following notation for an IP
-            address:
-
-                { <Network-number>, <Host-number> }
-
-            or
-                { <Network-number>, <Subnet-number>, <Host-number> }
-
-            and the notation "-1" for a field that contains all 1 bits.
-            This notation is not intended to imply that the 1-bits in an
-            address mask need be contiguous.
-
-            (a)  { 0, 0 }
-
-                 This host on this network.  MUST NOT be sent, except as
-                 a source address as part of an initialization procedure
-                 by which the host learns its own IP address.
-
-                 See also Section 3.3.6 for a non-standard use of {0,0}.
-
-            (b)  { 0, <Host-number> }
-
-                 Specified host on this network.  It MUST NOT be sent,
-                 except as a source address as part of an initialization
-                 procedure by which the host learns its full IP address.
-
-            (c)  { -1, -1 }
-
-                 Limited broadcast.  It MUST NOT be used as a source
-                 address.
-
-                 A datagram with this destination address will be
-                 received by every host on the connected physical
-                 network but will not be forwarded outside that network.
-
-            (d)  { <Network-number>, -1 }
-
-                 Directed broadcast to the specified network.  It MUST
-                 NOT be used as a source address.
-
-            (e)  { <Network-number>, <Subnet-number>, -1 }
-
-                 Directed broadcast to the specified subnet.  It MUST
-                 NOT be used as a source address.
-
-
-
-Internet Engineering Task Force                                [Page 30]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            (f)  { <Network-number>, -1, -1 }
-
-                 Directed broadcast to all subnets of the specified
-                 subnetted network.  It MUST NOT be used as a source
-                 address.
-
-            (g)  { 127, <any> }
-
-                 Internal host loopback address.  Addresses of this form
-                 MUST NOT appear outside a host.
-
-            The <Network-number> is administratively assigned so that
-            its value will be unique in the entire world.
-
-            IP addresses are not permitted to have the value 0 or -1 for
-            any of the <Host-number>, <Network-number>, or <Subnet-
-            number> fields (except in the special cases listed above).
-            This implies that each of these fields will be at least two
-            bits long.
-
-            For further discussion of broadcast addresses, see Section
-            3.3.6.
-
-            A host MUST support the subnet extensions to IP [IP:3].  As
-            a result, there will be an address mask of the form:
-            {-1, -1, 0} associated with each of the host's local IP
-            addresses; see Sections 3.2.2.9 and 3.3.1.1.
-
-            When a host sends any datagram, the IP source address MUST
-            be one of its own IP addresses (but not a broadcast or
-            multicast address).
-
-            A host MUST silently discard an incoming datagram that is
-            not destined for the host.  An incoming datagram is destined
-            for the host if the datagram's destination address field is:
-
-            (1)  (one of) the host's IP address(es); or
-
-            (2)  an IP broadcast address valid for the connected
-                 network; or
-
-            (3)  the address for a multicast group of which the host is
-                 a member on the incoming physical interface.
-
-            For most purposes, a datagram addressed to a broadcast or
-            multicast destination is processed as if it had been
-            addressed to one of the host's IP addresses; we use the term
-            "specific-destination address" for the equivalent local IP
-
-
-
-Internet Engineering Task Force                                [Page 31]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            address of the host.  The specific-destination address is
-            defined to be the destination address in the IP header
-            unless the header contains a broadcast or multicast address,
-            in which case the specific-destination is an IP address
-            assigned to the physical interface on which the datagram
-            arrived.
-
-            A host MUST silently discard an incoming datagram containing
-            an IP source address that is invalid by the rules of this
-            section.  This validation could be done in either the IP
-            layer or by each protocol in the transport layer.
-
-            DISCUSSION:
-                 A mis-addressed datagram might be caused by a link-
-                 layer broadcast of a unicast datagram or by a gateway
-                 or host that is confused or mis-configured.
-
-                 An architectural goal for Internet hosts was to allow
-                 IP addresses to be featureless 32-bit numbers, avoiding
-                 algorithms that required a knowledge of the IP address
-                 format.  Otherwise, any future change in the format or
-                 interpretation of IP addresses will require host
-                 software changes.  However, validation of broadcast and
-                 multicast addresses violates this goal; a few other
-                 violations are described elsewhere in this document.
-
-                 Implementers should be aware that applications
-                 depending upon the all-subnets directed broadcast
-                 address (f) may be unusable on some networks.  All-
-                 subnets broadcast is not widely implemented in vendor
-                 gateways at present, and even when it is implemented, a
-                 particular network administration may disable it in the
-                 gateway configuration.
-
-         3.2.1.4  Fragmentation and Reassembly: RFC-791 Section 3.2
-
-            The Internet model requires that every host support
-            reassembly.  See Sections 3.3.2 and 3.3.3 for the
-            requirements on fragmentation and reassembly.
-
-         3.2.1.5  Identification: RFC-791 Section 3.2
-
-            When sending an identical copy of an earlier datagram, a
-            host MAY optionally retain the same Identification field in
-            the copy.
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 32]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            DISCUSSION:
-                 Some Internet protocol experts have maintained that
-                 when a host sends an identical copy of an earlier
-                 datagram, the new copy should contain the same
-                 Identification value as the original.  There are two
-                 suggested advantages:  (1) if the datagrams are
-                 fragmented and some of the fragments are lost, the
-                 receiver may be able to reconstruct a complete datagram
-                 from fragments of the original and the copies; (2) a
-                 congested gateway might use the IP Identification field
-                 (and Fragment Offset) to discard duplicate datagrams
-                 from the queue.
-
-                 However, the observed patterns of datagram loss in the
-                 Internet do not favor the probability of retransmitted
-                 fragments filling reassembly gaps, while other
-                 mechanisms (e.g., TCP repacketizing upon
-                 retransmission) tend to prevent retransmission of an
-                 identical datagram [IP:9].  Therefore, we believe that
-                 retransmitting the same Identification field is not
-                 useful.  Also, a connectionless transport protocol like
-                 UDP would require the cooperation of the application
-                 programs to retain the same Identification value in
-                 identical datagrams.
-
-         3.2.1.6  Type-of-Service: RFC-791 Section 3.2
-
-            The "Type-of-Service" byte in the IP header is divided into
-            two sections:  the Precedence field (high-order 3 bits), and
-            a field that is customarily called "Type-of-Service" or
-            "TOS" (low-order 5 bits).  In this document, all references
-            to "TOS" or the "TOS field" refer to the low-order 5 bits
-            only.
-
-            The Precedence field is intended for Department of Defense
-            applications of the Internet protocols.  The use of non-zero
-            values in this field is outside the scope of this document
-            and the IP standard specification.  Vendors should consult
-            the Defense Communication Agency (DCA) for guidance on the
-            IP Precedence field and its implications for other protocol
-            layers.  However, vendors should note that the use of
-            precedence will most likely require that its value be passed
-            between protocol layers in just the same way as the TOS
-            field is passed.
-
-            The IP layer MUST provide a means for the transport layer to
-            set the TOS field of every datagram that is sent; the
-            default is all zero bits.  The IP layer SHOULD pass received
-
-
-
-Internet Engineering Task Force                                [Page 33]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            TOS values up to the transport layer.
-
-            The particular link-layer mappings of TOS contained in RFC-
-            795 SHOULD NOT be implemented.
-
-            DISCUSSION:
-                 While the TOS field has been little used in the past,
-                 it is expected to play an increasing role in the near
-                 future.  The TOS field is expected to be used to
-                 control two aspects of gateway operations: routing and
-                 queueing algorithms.  See Section 2 of [INTRO:1] for
-                 the requirements on application programs to specify TOS
-                 values.
-
-                 The TOS field may also be mapped into link-layer
-                 service selectors.  This has been applied to provide
-                 effective sharing of serial lines by different classes
-                 of TCP traffic, for example.  However, the mappings
-                 suggested in RFC-795 for networks that were included in
-                 the Internet as of 1981 are now obsolete.
-
-         3.2.1.7  Time-to-Live: RFC-791 Section 3.2
-
-            A host MUST NOT send a datagram with a Time-to-Live (TTL)
-            value of zero.
-
-            A host MUST NOT discard a datagram just because it was
-            received with TTL less than 2.
-
-            The IP layer MUST provide a means for the transport layer to
-            set the TTL field of every datagram that is sent.  When a
-            fixed TTL value is used, it MUST be configurable.  The
-            current suggested value will be published in the "Assigned
-            Numbers" RFC.
-
-            DISCUSSION:
-                 The TTL field has two functions: limit the lifetime of
-                 TCP segments (see RFC-793 [TCP:1], p. 28), and
-                 terminate Internet routing loops.  Although TTL is a
-                 time in seconds, it also has some attributes of a hop-
-                 count, since each gateway is required to reduce the TTL
-                 field by at least one.
-
-                 The intent is that TTL expiration will cause a datagram
-                 to be discarded by a gateway but not by the destination
-                 host; however, hosts that act as gateways by forwarding
-                 datagrams must follow the gateway rules for TTL.
-
-
-
-
-Internet Engineering Task Force                                [Page 34]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 A higher-layer protocol may want to set the TTL in
-                 order to implement an "expanding scope" search for some
-                 Internet resource.  This is used by some diagnostic
-                 tools, and is expected to be useful for locating the
-                 "nearest" server of a given class using IP
-                 multicasting, for example.  A particular transport
-                 protocol may also want to specify its own TTL bound on
-                 maximum datagram lifetime.
-
-                 A fixed value must be at least big enough for the
-                 Internet "diameter," i.e., the longest possible path.
-                 A reasonable value is about twice the diameter, to
-                 allow for continued Internet growth.
-
-         3.2.1.8  Options: RFC-791 Section 3.2
-
-            There MUST be a means for the transport layer to specify IP
-            options to be included in transmitted IP datagrams (see
-            Section 3.4).
-
-            All IP options (except NOP or END-OF-LIST) received in
-            datagrams MUST be passed to the transport layer (or to ICMP
-            processing when the datagram is an ICMP message).  The IP
-            and transport layer MUST each interpret those IP options
-            that they understand and silently ignore the others.
-
-            Later sections of this document discuss specific IP option
-            support required by each of ICMP, TCP, and UDP.
-
-            DISCUSSION:
-                 Passing all received IP options to the transport layer
-                 is a deliberate "violation of strict layering" that is
-                 designed to ease the introduction of new transport-
-                 relevant IP options in the future.  Each layer must
-                 pick out any options that are relevant to its own
-                 processing and ignore the rest.  For this purpose,
-                 every IP option except NOP and END-OF-LIST will include
-                 a specification of its own length.
-
-                 This document does not define the order in which a
-                 receiver must process multiple options in the same IP
-                 header.  Hosts sending multiple options must be aware
-                 that this introduces an ambiguity in the meaning of
-                 certain options when combined with a source-route
-                 option.
-
-            IMPLEMENTATION:
-                 The IP layer must not crash as the result of an option
-
-
-
-Internet Engineering Task Force                                [Page 35]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 length that is outside the possible range.  For
-                 example, erroneous option lengths have been observed to
-                 put some IP implementations into infinite loops.
-
-            Here are the requirements for specific IP options:
-
-
-            (a)  Security Option
-
-                 Some environments require the Security option in every
-                 datagram; such a requirement is outside the scope of
-                 this document and the IP standard specification.  Note,
-                 however, that the security options described in RFC-791
-                 and RFC-1038 are obsolete.  For DoD applications,
-                 vendors should consult [IP:8] for guidance.
-
-
-            (b)  Stream Identifier Option
-
-                 This option is obsolete; it SHOULD NOT be sent, and it
-                 MUST be silently ignored if received.
-
-
-            (c)  Source Route Options
-
-                 A host MUST support originating a source route and MUST
-                 be able to act as the final destination of a source
-                 route.
-
-                 If host receives a datagram containing a completed
-                 source route (i.e., the pointer points beyond the last
-                 field), the datagram has reached its final destination;
-                 the option as received (the recorded route) MUST be
-                 passed up to the transport layer (or to ICMP message
-                 processing).  This recorded route will be reversed and
-                 used to form a return source route for reply datagrams
-                 (see discussion of IP Options in Section 4).  When a
-                 return source route is built, it MUST be correctly
-                 formed even if the recorded route included the source
-                 host (see case (B) in the discussion below).
-
-                 An IP header containing more than one Source Route
-                 option MUST NOT be sent; the effect on routing of
-                 multiple Source Route options is implementation-
-                 specific.
-
-                 Section 3.3.5 presents the rules for a host acting as
-                 an intermediate hop in a source route, i.e., forwarding
-
-
-
-Internet Engineering Task Force                                [Page 36]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 a source-routed datagram.
-
-                 DISCUSSION:
-                      If a source-routed datagram is fragmented, each
-                      fragment will contain a copy of the source route.
-                      Since the processing of IP options (including a
-                      source route) must precede reassembly, the
-                      original datagram will not be reassembled until
-                      the final destination is reached.
-
-                      Suppose a source routed datagram is to be routed
-                      from host S to host D via gateways G1, G2, ... Gn.
-                      There was an ambiguity in the specification over
-                      whether the source route option in a datagram sent
-                      out by S should be (A) or (B):
-
-                          (A):  {>>G2, G3, ... Gn, D}     <--- CORRECT
-
-                          (B):  {S, >>G2, G3, ... Gn, D}  <---- WRONG
-
-                      (where >> represents the pointer).  If (A) is
-                      sent, the datagram received at D will contain the
-                      option: {G1, G2, ... Gn >>}, with S and D as the
-                      IP source and destination addresses.  If (B) were
-                      sent, the datagram received at D would again
-                      contain S and D as the same IP source and
-                      destination addresses, but the option would be:
-                      {S, G1, ...Gn >>}; i.e., the originating host
-                      would be the first hop in the route.
-
-
-            (d)  Record Route Option
-
-                 Implementation of originating and processing the Record
-                 Route option is OPTIONAL.
-
-
-            (e)  Timestamp Option
-
-                 Implementation of originating and processing the
-                 Timestamp option is OPTIONAL.  If it is implemented,
-                 the following rules apply:
-
-                 o    The originating host MUST record a timestamp in a
-                      Timestamp option whose Internet address fields are
-                      not pre-specified or whose first pre-specified
-                      address is the host's interface address.
-
-
-
-
-Internet Engineering Task Force                                [Page 37]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 o    The destination host MUST (if possible) add the
-                      current timestamp to a Timestamp option before
-                      passing the option to the transport layer or to
-                      ICMP for processing.
-
-                 o    A timestamp value MUST follow the rules given in
-                      Section 3.2.2.8 for the ICMP Timestamp message.
-
-
-      3.2.2 Internet Control Message Protocol -- ICMP
-
-         ICMP messages are grouped into two classes.
-
-         *
-              ICMP error messages:
-
-               Destination Unreachable   (see Section 3.2.2.1)
-               Redirect                  (see Section 3.2.2.2)
-               Source Quench             (see Section 3.2.2.3)
-               Time Exceeded             (see Section 3.2.2.4)
-               Parameter Problem         (see Section 3.2.2.5)
-
-
-         *
-              ICMP query messages:
-
-                Echo                     (see Section 3.2.2.6)
-                Information              (see Section 3.2.2.7)
-                Timestamp                (see Section 3.2.2.8)
-                Address Mask             (see Section 3.2.2.9)
-
-
-         If an ICMP message of unknown type is received, it MUST be
-         silently discarded.
-
-         Every ICMP error message includes the Internet header and at
-         least the first 8 data octets of the datagram that triggered
-         the error; more than 8 octets MAY be sent; this header and data
-         MUST be unchanged from the received datagram.
-
-         In those cases where the Internet layer is required to pass an
-         ICMP error message to the transport layer, the IP protocol
-         number MUST be extracted from the original header and used to
-         select the appropriate transport protocol entity to handle the
-         error.
-
-         An ICMP error message SHOULD be sent with normal (i.e., zero)
-         TOS bits.
-
-
-
-Internet Engineering Task Force                                [Page 38]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-         An ICMP error message MUST NOT be sent as the result of
-         receiving:
-
-         *    an ICMP error message, or
-
-         *    a datagram destined to an IP broadcast or IP multicast
-              address, or
-
-         *    a datagram sent as a link-layer broadcast, or
-
-         *    a non-initial fragment, or
-
-         *    a datagram whose source address does not define a single
-              host -- e.g., a zero address, a loopback address, a
-              broadcast address, a multicast address, or a Class E
-              address.
-
-         NOTE: THESE RESTRICTIONS TAKE PRECEDENCE OVER ANY REQUIREMENT
-         ELSEWHERE IN THIS DOCUMENT FOR SENDING ICMP ERROR MESSAGES.
-
-         DISCUSSION:
-              These rules will prevent the "broadcast storms" that have
-              resulted from hosts returning ICMP error messages in
-              response to broadcast datagrams.  For example, a broadcast
-              UDP segment to a non-existent port could trigger a flood
-              of ICMP Destination Unreachable datagrams from all
-              machines that do not have a client for that destination
-              port.  On a large Ethernet, the resulting collisions can
-              render the network useless for a second or more.
-
-              Every datagram that is broadcast on the connected network
-              should have a valid IP broadcast address as its IP
-              destination (see Section 3.3.6).  However, some hosts
-              violate this rule.  To be certain to detect broadcast
-              datagrams, therefore, hosts are required to check for a
-              link-layer broadcast as well as an IP-layer broadcast
-              address.
-
-         IMPLEMENTATION:
-              This requires that the link layer inform the IP layer when
-              a link-layer broadcast datagram has been received; see
-              Section 2.4.
-
-         3.2.2.1  Destination Unreachable: RFC-792
-
-            The following additional codes are hereby defined:
-
-                    6 = destination network unknown
-
-
-
-Internet Engineering Task Force                                [Page 39]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                    7 = destination host unknown
-
-                    8 = source host isolated
-
-                    9 = communication with destination network
-                            administratively prohibited
-
-                   10 = communication with destination host
-                            administratively prohibited
-
-                   11 = network unreachable for type of service
-
-                   12 = host unreachable for type of service
-
-            A host SHOULD generate Destination Unreachable messages with
-            code:
-
-            2    (Protocol Unreachable), when the designated transport
-                 protocol is not supported; or
-
-            3    (Port Unreachable), when the designated transport
-                 protocol (e.g., UDP) is unable to demultiplex the
-                 datagram but has no protocol mechanism to inform the
-                 sender.
-
-            A Destination Unreachable message that is received MUST be
-            reported to the transport layer.  The transport layer SHOULD
-            use the information appropriately; for example, see Sections
-            4.1.3.3, 4.2.3.9, and 4.2.4 below.  A transport protocol
-            that has its own mechanism for notifying the sender that a
-            port is unreachable (e.g., TCP, which sends RST segments)
-            MUST nevertheless accept an ICMP Port Unreachable for the
-            same purpose.
-
-            A Destination Unreachable message that is received with code
-            0 (Net), 1 (Host), or 5 (Bad Source Route) may result from a
-            routing transient and MUST therefore be interpreted as only
-            a hint, not proof, that the specified destination is
-            unreachable [IP:11].  For example, it MUST NOT be used as
-            proof of a dead gateway (see Section 3.3.1).
-
-         3.2.2.2  Redirect: RFC-792
-
-            A host SHOULD NOT send an ICMP Redirect message; Redirects
-            are to be sent only by gateways.
-
-            A host receiving a Redirect message MUST update its routing
-            information accordingly.  Every host MUST be prepared to
-
-
-
-Internet Engineering Task Force                                [Page 40]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            accept both Host and Network Redirects and to process them
-            as described in Section 3.3.1.2 below.
-
-            A Redirect message SHOULD be silently discarded if the new
-            gateway address it specifies is not on the same connected
-            (sub-) net through which the Redirect arrived [INTRO:2,
-            Appendix A], or if the source of the Redirect is not the
-            current first-hop gateway for the specified destination (see
-            Section 3.3.1).
-
-         3.2.2.3  Source Quench: RFC-792
-
-            A host MAY send a Source Quench message if it is
-            approaching, or has reached, the point at which it is forced
-            to discard incoming datagrams due to a shortage of
-            reassembly buffers or other resources.  See Section 2.2.3 of
-            [INTRO:2] for suggestions on when to send Source Quench.
-
-            If a Source Quench message is received, the IP layer MUST
-            report it to the transport layer (or ICMP processing). In
-            general, the transport or application layer SHOULD implement
-            a mechanism to respond to Source Quench for any protocol
-            that can send a sequence of datagrams to the same
-            destination and which can reasonably be expected to maintain
-            enough state information to make this feasible.  See Section
-            4 for the handling of Source Quench by TCP and UDP.
-
-            DISCUSSION:
-                 A Source Quench may be generated by the target host or
-                 by some gateway in the path of a datagram.  The host
-                 receiving a Source Quench should throttle itself back
-                 for a period of time, then gradually increase the
-                 transmission rate again.  The mechanism to respond to
-                 Source Quench may be in the transport layer (for
-                 connection-oriented protocols like TCP) or in the
-                 application layer (for protocols that are built on top
-                 of UDP).
-
-                 A mechanism has been proposed [IP:14] to make the IP
-                 layer respond directly to Source Quench by controlling
-                 the rate at which datagrams are sent, however, this
-                 proposal is currently experimental and not currently
-                 recommended.
-
-         3.2.2.4  Time Exceeded: RFC-792
-
-            An incoming Time Exceeded message MUST be passed to the
-            transport layer.
-
-
-
-Internet Engineering Task Force                                [Page 41]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            DISCUSSION:
-                 A gateway will send a Time Exceeded Code 0 (In Transit)
-                 message when it discards a datagram due to an expired
-                 TTL field.  This indicates either a gateway routing
-                 loop or too small an initial TTL value.
-
-                 A host may receive a Time Exceeded Code 1 (Reassembly
-                 Timeout) message from a destination host that has timed
-                 out and discarded an incomplete datagram; see Section
-                 3.3.2 below.  In the future, receipt of this message
-                 might be part of some "MTU discovery" procedure, to
-                 discover the maximum datagram size that can be sent on
-                 the path without fragmentation.
-
-         3.2.2.5  Parameter Problem: RFC-792
-
-            A host SHOULD generate Parameter Problem messages.  An
-            incoming Parameter Problem message MUST be passed to the
-            transport layer, and it MAY be reported to the user.
-
-            DISCUSSION:
-                 The ICMP Parameter Problem message is sent to the
-                 source host for any problem not specifically covered by
-                 another ICMP message.  Receipt of a Parameter Problem
-                 message generally indicates some local or remote
-                 implementation error.
-
-            A new variant on the Parameter Problem message is hereby
-            defined:
-              Code 1 = required option is missing.
-
-            DISCUSSION:
-                 This variant is currently in use in the military
-                 community for a missing security option.
-
-         3.2.2.6  Echo Request/Reply: RFC-792
-
-            Every host MUST implement an ICMP Echo server function that
-            receives Echo Requests and sends corresponding Echo Replies.
-            A host SHOULD also implement an application-layer interface
-            for sending an Echo Request and receiving an Echo Reply, for
-            diagnostic purposes.
-
-            An ICMP Echo Request destined to an IP broadcast or IP
-            multicast address MAY be silently discarded.
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 42]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            DISCUSSION:
-                 This neutral provision results from a passionate debate
-                 between those who feel that ICMP Echo to a broadcast
-                 address provides a valuable diagnostic capability and
-                 those who feel that misuse of this feature can too
-                 easily create packet storms.
-
-            The IP source address in an ICMP Echo Reply MUST be the same
-            as the specific-destination address (defined in Section
-            3.2.1.3) of the corresponding ICMP Echo Request message.
-
-            Data received in an ICMP Echo Request MUST be entirely
-            included in the resulting Echo Reply.  However, if sending
-            the Echo Reply requires intentional fragmentation that is
-            not implemented, the datagram MUST be truncated to maximum
-            transmission size (see Section 3.3.3) and sent.
-
-            Echo Reply messages MUST be passed to the ICMP user
-            interface, unless the corresponding Echo Request originated
-            in the IP layer.
-
-            If a Record Route and/or Time Stamp option is received in an
-            ICMP Echo Request, this option (these options) SHOULD be
-            updated to include the current host and included in the IP
-            header of the Echo Reply message, without "truncation".
-            Thus, the recorded route will be for the entire round trip.
-
-            If a Source Route option is received in an ICMP Echo
-            Request, the return route MUST be reversed and used as a
-            Source Route option for the Echo Reply message.
-
-         3.2.2.7  Information Request/Reply: RFC-792
-
-            A host SHOULD NOT implement these messages.
-
-            DISCUSSION:
-                 The Information Request/Reply pair was intended to
-                 support self-configuring systems such as diskless
-                 workstations, to allow them to discover their IP
-                 network numbers at boot time.  However, the RARP and
-                 BOOTP protocols provide better mechanisms for a host to
-                 discover its own IP address.
-
-         3.2.2.8  Timestamp and Timestamp Reply: RFC-792
-
-            A host MAY implement Timestamp and Timestamp Reply.  If they
-            are implemented, the following rules MUST be followed.
-
-
-
-
-Internet Engineering Task Force                                [Page 43]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            o    The ICMP Timestamp server function returns a Timestamp
-                 Reply to every Timestamp message that is received.  If
-                 this function is implemented, it SHOULD be designed for
-                 minimum variability in delay (e.g., implemented in the
-                 kernel to avoid delay in scheduling a user process).
-
-            The following cases for Timestamp are to be handled
-            according to the corresponding rules for ICMP Echo:
-
-            o    An ICMP Timestamp Request message to an IP broadcast or
-                 IP multicast address MAY be silently discarded.
-
-            o    The IP source address in an ICMP Timestamp Reply MUST
-                 be the same as the specific-destination address of the
-                 corresponding Timestamp Request message.
-
-            o    If a Source-route option is received in an ICMP Echo
-                 Request, the return route MUST be reversed and used as
-                 a Source Route option for the Timestamp Reply message.
-
-            o    If a Record Route and/or Timestamp option is received
-                 in a Timestamp Request, this (these) option(s) SHOULD
-                 be updated to include the current host and included in
-                 the IP header of the Timestamp Reply message.
-
-            o    Incoming Timestamp Reply messages MUST be passed up to
-                 the ICMP user interface.
-
-            The preferred form for a timestamp value (the "standard
-            value") is in units of milliseconds since midnight Universal
-            Time.  However, it may be difficult to provide this value
-            with millisecond resolution.  For example, many systems use
-            clocks that update only at line frequency, 50 or 60 times
-            per second.  Therefore, some latitude is allowed in a
-            "standard value":
-
-            (a)  A "standard value" MUST be updated at least 15 times
-                 per second (i.e., at most the six low-order bits of the
-                 value may be undefined).
-
-            (b)  The accuracy of a "standard value" MUST approximate
-                 that of operator-set CPU clocks, i.e., correct within a
-                 few minutes.
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 44]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-         3.2.2.9  Address Mask Request/Reply: RFC-950
-
-            A host MUST support the first, and MAY implement all three,
-            of the following methods for determining the address mask(s)
-            corresponding to its IP address(es):
-
-            (1)  static configuration information;
-
-            (2)  obtaining the address mask(s) dynamically as a side-
-                 effect of the system initialization process (see
-                 [INTRO:1]); and
-
-            (3)  sending ICMP Address Mask Request(s) and receiving ICMP
-                 Address Mask Reply(s).
-
-            The choice of method to be used in a particular host MUST be
-            configurable.
-
-            When method (3), the use of Address Mask messages, is
-            enabled, then:
-
-            (a)  When it initializes, the host MUST broadcast an Address
-                 Mask Request message on the connected network
-                 corresponding to the IP address.  It MUST retransmit
-                 this message a small number of times if it does not
-                 receive an immediate Address Mask Reply.
-
-            (b)  Until it has received an Address Mask Reply, the host
-                 SHOULD assume a mask appropriate for the address class
-                 of the IP address, i.e., assume that the connected
-                 network is not subnetted.
-
-            (c)  The first Address Mask Reply message received MUST be
-                 used to set the address mask corresponding to the
-                 particular local IP address.  This is true even if the
-                 first Address Mask Reply message is "unsolicited", in
-                 which case it will have been broadcast and may arrive
-                 after the host has ceased to retransmit Address Mask
-                 Requests.  Once the mask has been set by an Address
-                 Mask Reply, later Address Mask Reply messages MUST be
-                 (silently) ignored.
-
-            Conversely, if Address Mask messages are disabled, then no
-            ICMP Address Mask Requests will be sent, and any ICMP
-            Address Mask Replies received for that local IP address MUST
-            be (silently) ignored.
-
-            A host SHOULD make some reasonableness check on any address
-
-
-
-Internet Engineering Task Force                                [Page 45]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            mask it installs; see IMPLEMENTATION section below.
-
-            A system MUST NOT send an Address Mask Reply unless it is an
-            authoritative agent for address masks.  An authoritative
-            agent may be a host or a gateway, but it MUST be explicitly
-            configured as a address mask agent.  Receiving an address
-            mask via an Address Mask Reply does not give the receiver
-            authority and MUST NOT be used as the basis for issuing
-            Address Mask Replies.
-
-            With a statically configured address mask, there SHOULD be
-            an additional configuration flag that determines whether the
-            host is to act as an authoritative agent for this mask,
-            i.e., whether it will answer Address Mask Request messages
-            using this mask.
-
-            If it is configured as an agent, the host MUST broadcast an
-            Address Mask Reply for the mask on the appropriate interface
-            when it initializes.
-
-            See "System Initialization" in [INTRO:1] for more
-            information about the use of Address Mask Request/Reply
-            messages.
-
-            DISCUSSION
-                 Hosts that casually send Address Mask Replies with
-                 invalid address masks have often been a serious
-                 nuisance.  To prevent this, Address Mask Replies ought
-                 to be sent only by authoritative agents that have been
-                 selected by explicit administrative action.
-
-                 When an authoritative agent receives an Address Mask
-                 Request message, it will send a unicast Address Mask
-                 Reply to the source IP address.  If the network part of
-                 this address is zero (see (a) and (b) in 3.2.1.3), the
-                 Reply will be broadcast.
-
-                 Getting no reply to its Address Mask Request messages,
-                 a host will assume there is no agent and use an
-                 unsubnetted mask, but the agent may be only temporarily
-                 unreachable.  An agent will broadcast an unsolicited
-                 Address Mask Reply whenever it initializes, in order to
-                 update the masks of all hosts that have initialized in
-                 the meantime.
-
-            IMPLEMENTATION:
-                 The following reasonableness check on an address mask
-                 is suggested: the mask is not all 1 bits, and it is
-
-
-
-Internet Engineering Task Force                                [Page 46]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 either zero or else the 8 highest-order bits are on.
-
-      3.2.3  Internet Group Management Protocol IGMP
-
-         IGMP [IP:4] is a protocol used between hosts and gateways on a
-         single network to establish hosts' membership in particular
-         multicast groups.  The gateways use this information, in
-         conjunction with a multicast routing protocol, to support IP
-         multicasting across the Internet.
-
-         At this time, implementation of IGMP is OPTIONAL; see Section
-         3.3.7 for more information.  Without IGMP, a host can still
-         participate in multicasting local to its connected networks.
-
-   3.3  SPECIFIC ISSUES
-
-      3.3.1  Routing Outbound Datagrams
-
-         The IP layer chooses the correct next hop for each datagram it
-         sends.  If the destination is on a connected network, the
-         datagram is sent directly to the destination host; otherwise,
-         it has to be routed to a gateway on a connected network.
-
-         3.3.1.1  Local/Remote Decision
-
-            To decide if the destination is on a connected network, the
-            following algorithm MUST be used [see IP:3]:
-
-            (a)  The address mask (particular to a local IP address for
-                 a multihomed host) is a 32-bit mask that selects the
-                 network number and subnet number fields of the
-                 corresponding IP address.
-
-            (b)  If the IP destination address bits extracted by the
-                 address mask match the IP source address bits extracted
-                 by the same mask, then the destination is on the
-                 corresponding connected network, and the datagram is to
-                 be transmitted directly to the destination host.
-
-            (c)  If not, then the destination is accessible only through
-                 a gateway.  Selection of a gateway is described below
-                 (3.3.1.2).
-
-            A special-case destination address is handled as follows:
-
-            *    For a limited broadcast or a multicast address, simply
-                 pass the datagram to the link layer for the appropriate
-                 interface.
-
-
-
-Internet Engineering Task Force                                [Page 47]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            *    For a (network or subnet) directed broadcast, the
-                 datagram can use the standard routing algorithms.
-
-            The host IP layer MUST operate correctly in a minimal
-            network environment, and in particular, when there are no
-            gateways.  For example, if the IP layer of a host insists on
-            finding at least one gateway to initialize, the host will be
-            unable to operate on a single isolated broadcast net.
-
-         3.3.1.2  Gateway Selection
-
-            To efficiently route a series of datagrams to the same
-            destination, the source host MUST keep a "route cache" of
-            mappings to next-hop gateways.  A host uses the following
-            basic algorithm on this cache to route a datagram; this
-            algorithm is designed to put the primary routing burden on
-            the gateways [IP:11].
-
-            (a)  If the route cache contains no information for a
-                 particular destination, the host chooses a "default"
-                 gateway and sends the datagram to it.  It also builds a
-                 corresponding Route Cache entry.
-
-            (b)  If that gateway is not the best next hop to the
-                 destination, the gateway will forward the datagram to
-                 the best next-hop gateway and return an ICMP Redirect
-                 message to the source host.
-
-            (c)  When it receives a Redirect, the host updates the
-                 next-hop gateway in the appropriate route cache entry,
-                 so later datagrams to the same destination will go
-                 directly to the best gateway.
-
-            Since the subnet mask appropriate to the destination address
-            is generally not known, a Network Redirect message SHOULD be
-            treated identically to a Host Redirect message; i.e., the
-            cache entry for the destination host (only) would be updated
-            (or created, if an entry for that host did not exist) for
-            the new gateway.
-
-            DISCUSSION:
-                 This recommendation is to protect against gateways that
-                 erroneously send Network Redirects for a subnetted
-                 network, in violation of the gateway requirements
-                 [INTRO:2].
-
-            When there is no route cache entry for the destination host
-            address (and the destination is not on the connected
-
-
-
-Internet Engineering Task Force                                [Page 48]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            network), the IP layer MUST pick a gateway from its list of
-            "default" gateways.  The IP layer MUST support multiple
-            default gateways.
-
-            As an extra feature, a host IP layer MAY implement a table
-            of "static routes".  Each such static route MAY include a
-            flag specifying whether it may be overridden by ICMP
-            Redirects.
-
-            DISCUSSION:
-                 A host generally needs to know at least one default
-                 gateway to get started.  This information can be
-                 obtained from a configuration file or else from the
-                 host startup sequence, e.g., the BOOTP protocol (see
-                 [INTRO:1]).
-
-                 It has been suggested that a host can augment its list
-                 of default gateways by recording any new gateways it
-                 learns about.  For example, it can record every gateway
-                 to which it is ever redirected.  Such a feature, while
-                 possibly useful in some circumstances, may cause
-                 problems in other cases (e.g., gateways are not all
-                 equal), and it is not recommended.
-
-                 A static route is typically a particular preset mapping
-                 from destination host or network into a particular
-                 next-hop gateway; it might also depend on the Type-of-
-                 Service (see next section).  Static routes would be set
-                 up by system administrators to override the normal
-                 automatic routing mechanism, to handle exceptional
-                 situations.  However, any static routing information is
-                 a potential source of failure as configurations change
-                 or equipment fails.
-
-         3.3.1.3  Route Cache
-
-            Each route cache entry needs to include the following
-            fields:
-
-            (1)  Local IP address (for a multihomed host)
-
-            (2)  Destination IP address
-
-            (3)  Type(s)-of-Service
-
-            (4)  Next-hop gateway IP address
-
-            Field (2) MAY be the full IP address of the destination
-
-
-
-Internet Engineering Task Force                                [Page 49]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            host, or only the destination network number.  Field (3),
-            the TOS, SHOULD be included.
-
-            See Section 3.3.4.2 for a discussion of the implications of
-            multihoming for the lookup procedure in this cache.
-
-            DISCUSSION:
-                 Including the Type-of-Service field in the route cache
-                 and considering it in the host route algorithm will
-                 provide the necessary mechanism for the future when
-                 Type-of-Service routing is commonly used in the
-                 Internet.  See Section 3.2.1.6.
-
-                 Each route cache entry defines the endpoints of an
-                 Internet path.  Although the connecting path may change
-                 dynamically in an arbitrary way, the transmission
-                 characteristics of the path tend to remain
-                 approximately constant over a time period longer than a
-                 single typical host-host transport connection.
-                 Therefore, a route cache entry is a natural place to
-                 cache data on the properties of the path.  Examples of
-                 such properties might be the maximum unfragmented
-                 datagram size (see Section 3.3.3), or the average
-                 round-trip delay measured by a transport protocol.
-                 This data will generally be both gathered and used by a
-                 higher layer protocol, e.g., by TCP, or by an
-                 application using UDP.  Experiments are currently in
-                 progress on caching path properties in this manner.
-
-                 There is no consensus on whether the route cache should
-                 be keyed on destination host addresses alone, or allow
-                 both host and network addresses.  Those who favor the
-                 use of only host addresses argue that:
-
-                 (1)  As required in Section 3.3.1.2, Redirect messages
-                      will generally result in entries keyed on
-                      destination host addresses; the simplest and most
-                      general scheme would be to use host addresses
-                      always.
-
-                 (2)  The IP layer may not always know the address mask
-                      for a network address in a complex subnetted
-                      environment.
-
-                 (3)  The use of only host addresses allows the
-                      destination address to be used as a pure 32-bit
-                      number, which may allow the Internet architecture
-                      to be more easily extended in the future without
-
-
-
-Internet Engineering Task Force                                [Page 50]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                      any change to the hosts.
-
-                 The opposing view is that allowing a mixture of
-                 destination hosts and networks in the route cache:
-
-                 (1)  Saves memory space.
-
-                 (2)  Leads to a simpler data structure, easily
-                      combining the cache with the tables of default and
-                      static routes (see below).
-
-                 (3)  Provides a more useful place to cache path
-                      properties, as discussed earlier.
-
-
-            IMPLEMENTATION:
-                 The cache needs to be large enough to include entries
-                 for the maximum number of destination hosts that may be
-                 in use at one time.
-
-                 A route cache entry may also include control
-                 information used to choose an entry for replacement.
-                 This might take the form of a "recently used" bit, a
-                 use count, or a last-used timestamp, for example.  It
-                 is recommended that it include the time of last
-                 modification of the entry, for diagnostic purposes.
-
-                 An implementation may wish to reduce the overhead of
-                 scanning the route cache for every datagram to be
-                 transmitted.  This may be accomplished with a hash
-                 table to speed the lookup, or by giving a connection-
-                 oriented transport protocol a "hint" or temporary
-                 handle on the appropriate cache entry, to be passed to
-                 the IP layer with each subsequent datagram.
-
-                 Although we have described the route cache, the lists
-                 of default gateways, and a table of static routes as
-                 conceptually distinct, in practice they may be combined
-                 into a single "routing table" data structure.
-
-         3.3.1.4  Dead Gateway Detection
-
-            The IP layer MUST be able to detect the failure of a "next-
-            hop" gateway that is listed in its route cache and to choose
-            an alternate gateway (see Section 3.3.1.5).
-
-            Dead gateway detection is covered in some detail in RFC-816
-            [IP:11]. Experience to date has not produced a complete
-
-
-
-Internet Engineering Task Force                                [Page 51]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            algorithm which is totally satisfactory, though it has
-            identified several forbidden paths and promising techniques.
-
-            *    A particular gateway SHOULD NOT be used indefinitely in
-                 the absence of positive indications that it is
-                 functioning.
-
-            *    Active probes such as "pinging" (i.e., using an ICMP
-                 Echo Request/Reply exchange) are expensive and scale
-                 poorly.  In particular, hosts MUST NOT actively check
-                 the status of a first-hop gateway by simply pinging the
-                 gateway continuously.
-
-            *    Even when it is the only effective way to verify a
-                 gateway's status, pinging MUST be used only when
-                 traffic is being sent to the gateway and when there is
-                 no other positive indication to suggest that the
-                 gateway is functioning.
-
-            *    To avoid pinging, the layers above and/or below the
-                 Internet layer SHOULD be able to give "advice" on the
-                 status of route cache entries when either positive
-                 (gateway OK) or negative (gateway dead) information is
-                 available.
-
-
-            DISCUSSION:
-                 If an implementation does not include an adequate
-                 mechanism for detecting a dead gateway and re-routing,
-                 a gateway failure may cause datagrams to apparently
-                 vanish into a "black hole".  This failure can be
-                 extremely confusing for users and difficult for network
-                 personnel to debug.
-
-                 The dead-gateway detection mechanism must not cause
-                 unacceptable load on the host, on connected networks,
-                 or on first-hop gateway(s).  The exact constraints on
-                 the timeliness of dead gateway detection and on
-                 acceptable load may vary somewhat depending on the
-                 nature of the host's mission, but a host generally
-                 needs to detect a failed first-hop gateway quickly
-                 enough that transport-layer connections will not break
-                 before an alternate gateway can be selected.
-
-                 Passing advice from other layers of the protocol stack
-                 complicates the interfaces between the layers, but it
-                 is the preferred approach to dead gateway detection.
-                 Advice can come from almost any part of the IP/TCP
-
-
-
-Internet Engineering Task Force                                [Page 52]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 architecture, but it is expected to come primarily from
-                 the transport and link layers.  Here are some possible
-                 sources for gateway advice:
-
-                 o    TCP or any connection-oriented transport protocol
-                      should be able to give negative advice, e.g.,
-                      triggered by excessive retransmissions.
-
-                 o    TCP may give positive advice when (new) data is
-                      acknowledged.  Even though the route may be
-                      asymmetric, an ACK for new data proves that the
-                      acknowleged data must have been transmitted
-                      successfully.
-
-                 o    An ICMP Redirect message from a particular gateway
-                      should be used as positive advice about that
-                      gateway.
-
-                 o    Link-layer information that reliably detects and
-                      reports host failures (e.g., ARPANET Destination
-                      Dead messages) should be used as negative advice.
-
-                 o    Failure to ARP or to re-validate ARP mappings may
-                      be used as negative advice for the corresponding
-                      IP address.
-
-                 o    Packets arriving from a particular link-layer
-                      address are evidence that the system at this
-                      address is alive.  However, turning this
-                      information into advice about gateways requires
-                      mapping the link-layer address into an IP address,
-                      and then checking that IP address against the
-                      gateways pointed to by the route cache.  This is
-                      probably prohibitively inefficient.
-
-                 Note that positive advice that is given for every
-                 datagram received may cause unacceptable overhead in
-                 the implementation.
-
-                 While advice might be passed using required arguments
-                 in all interfaces to the IP layer, some transport and
-                 application layer protocols cannot deduce the correct
-                 advice.  These interfaces must therefore allow a
-                 neutral value for advice, since either always-positive
-                 or always-negative advice leads to incorrect behavior.
-
-                 There is another technique for dead gateway detection
-                 that has been commonly used but is not recommended.
-
-
-
-Internet Engineering Task Force                                [Page 53]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 This technique depends upon the host passively
-                 receiving ("wiretapping") the Interior Gateway Protocol
-                 (IGP) datagrams that the gateways are broadcasting to
-                 each other.  This approach has the drawback that a host
-                 needs to recognize all the interior gateway protocols
-                 that gateways may use (see [INTRO:2]).  In addition, it
-                 only works on a broadcast network.
-
-                 At present, pinging (i.e., using ICMP Echo messages) is
-                 the mechanism for gateway probing when absolutely
-                 required.  A successful ping guarantees that the
-                 addressed interface and its associated machine are up,
-                 but it does not guarantee that the machine is a gateway
-                 as opposed to a host.  The normal inference is that if
-                 a Redirect or other evidence indicates that a machine
-                 was a gateway, successful pings will indicate that the
-                 machine is still up and hence still a gateway.
-                 However, since a host silently discards packets that a
-                 gateway would forward or redirect, this assumption
-                 could sometimes fail.  To avoid this problem, a new
-                 ICMP message under development will ask "are you a
-                 gateway?"
-
-            IMPLEMENTATION:
-                 The following specific algorithm has been suggested:
-
-                 o    Associate a "reroute timer" with each gateway
-                      pointed to by the route cache.  Initialize the
-                      timer to a value Tr, which must be small enough to
-                      allow detection of a dead gateway before transport
-                      connections time out.
-
-                 o    Positive advice would reset the reroute timer to
-                      Tr.  Negative advice would reduce or zero the
-                      reroute timer.
-
-                 o    Whenever the IP layer used a particular gateway to
-                      route a datagram, it would check the corresponding
-                      reroute timer.  If the timer had expired (reached
-                      zero), the IP layer would send a ping to the
-                      gateway, followed immediately by the datagram.
-
-                 o    The ping (ICMP Echo) would be sent again if
-                      necessary, up to N times.  If no ping reply was
-                      received in N tries, the gateway would be assumed
-                      to have failed, and a new first-hop gateway would
-                      be chosen for all cache entries pointing to the
-                      failed gateway.
-
-
-
-Internet Engineering Task Force                                [Page 54]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 Note that the size of Tr is inversely related to the
-                 amount of advice available.  Tr should be large enough
-                 to insure that:
-
-                 *    Any pinging will be at a low level (e.g., <10%) of
-                      all packets sent to a gateway from the host, AND
-
-                 *    pinging is infrequent (e.g., every 3 minutes)
-
-                 Since the recommended algorithm is concerned with the
-                 gateways pointed to by route cache entries, rather than
-                 the cache entries themselves, a two level data
-                 structure (perhaps coordinated with ARP or similar
-                 caches) may be desirable for implementing a route
-                 cache.
-
-         3.3.1.5  New Gateway Selection
-
-            If the failed gateway is not the current default, the IP
-            layer can immediately switch to a default gateway.  If it is
-            the current default that failed, the IP layer MUST select a
-            different default gateway (assuming more than one default is
-            known) for the failed route and for establishing new routes.
-
-            DISCUSSION:
-                 When a gateway does fail, the other gateways on the
-                 connected network will learn of the failure through
-                 some inter-gateway routing protocol.  However, this
-                 will not happen instantaneously, since gateway routing
-                 protocols typically have a settling time of 30-60
-                 seconds.  If the host switches to an alternative
-                 gateway before the gateways have agreed on the failure,
-                 the new target gateway will probably forward the
-                 datagram to the failed gateway and send a Redirect back
-                 to the host pointing to the failed gateway (!).  The
-                 result is likely to be a rapid oscillation in the
-                 contents of the host's route cache during the gateway
-                 settling period.  It has been proposed that the dead-
-                 gateway logic should include some hysteresis mechanism
-                 to prevent such oscillations.  However, experience has
-                 not shown any harm from such oscillations, since
-                 service cannot be restored to the host until the
-                 gateways' routing information does settle down.
-
-            IMPLEMENTATION:
-                 One implementation technique for choosing a new default
-                 gateway is to simply round-robin among the default
-                 gateways in the host's list.  Another is to rank the
-
-
-
-Internet Engineering Task Force                                [Page 55]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 gateways in priority order, and when the current
-                 default gateway is not the highest priority one, to
-                 "ping" the higher-priority gateways slowly to detect
-                 when they return to service.  This pinging can be at a
-                 very low rate, e.g., 0.005 per second.
-
-         3.3.1.6  Initialization
-
-            The following information MUST be configurable:
-
-            (1)  IP address(es).
-
-            (2)  Address mask(s).
-
-            (3)  A list of default gateways, with a preference level.
-
-            A manual method of entering this configuration data MUST be
-            provided.  In addition, a variety of methods can be used to
-            determine this information dynamically; see the section on
-            "Host Initialization" in [INTRO:1].
-
-            DISCUSSION:
-                 Some host implementations use "wiretapping" of gateway
-                 protocols on a broadcast network to learn what gateways
-                 exist.  A standard method for default gateway discovery
-                 is under development.
-
-      3.3.2  Reassembly
-
-         The IP layer MUST implement reassembly of IP datagrams.
-
-         We designate the largest datagram size that can be reassembled
-         by EMTU_R ("Effective MTU to receive"); this is sometimes
-         called the "reassembly buffer size".  EMTU_R MUST be greater
-         than or equal to 576, SHOULD be either configurable or
-         indefinite, and SHOULD be greater than or equal to the MTU of
-         the connected network(s).
-
-         DISCUSSION:
-              A fixed EMTU_R limit should not be built into the code
-              because some application layer protocols require EMTU_R
-              values larger than 576.
-
-         IMPLEMENTATION:
-              An implementation may use a contiguous reassembly buffer
-              for each datagram, or it may use a more complex data
-              structure that places no definite limit on the reassembled
-              datagram size; in the latter case, EMTU_R is said to be
-
-
-
-Internet Engineering Task Force                                [Page 56]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-              "indefinite".
-
-              Logically, reassembly is performed by simply copying each
-              fragment into the packet buffer at the proper offset.
-              Note that fragments may overlap if successive
-              retransmissions use different packetizing but the same
-              reassembly Id.
-
-              The tricky part of reassembly is the bookkeeping to
-              determine when all bytes of the datagram have been
-              reassembled.  We recommend Clark's algorithm [IP:10] that
-              requires no additional data space for the bookkeeping.
-              However, note that, contrary to [IP:10], the first
-              fragment header needs to be saved for inclusion in a
-              possible ICMP Time Exceeded (Reassembly Timeout) message.
-
-         There MUST be a mechanism by which the transport layer can
-         learn MMS_R, the maximum message size that can be received and
-         reassembled in an IP datagram (see GET_MAXSIZES calls in
-         Section 3.4).  If EMTU_R is not indefinite, then the value of
-         MMS_R is given by:
-
-            MMS_R = EMTU_R - 20
-
-         since 20 is the minimum size of an IP header.
-
-         There MUST be a reassembly timeout.  The reassembly timeout
-         value SHOULD be a fixed value, not set from the remaining TTL.
-         It is recommended that the value lie between 60 seconds and 120
-         seconds.  If this timeout expires, the partially-reassembled
-         datagram MUST be discarded and an ICMP Time Exceeded message
-         sent to the source host (if fragment zero has been received).
-
-         DISCUSSION:
-              The IP specification says that the reassembly timeout
-              should be the remaining TTL from the IP header, but this
-              does not work well because gateways generally treat TTL as
-              a simple hop count rather than an elapsed time.  If the
-              reassembly timeout is too small, datagrams will be
-              discarded unnecessarily, and communication may fail.  The
-              timeout needs to be at least as large as the typical
-              maximum delay across the Internet.  A realistic minimum
-              reassembly timeout would be 60 seconds.
-
-              It has been suggested that a cache might be kept of
-              round-trip times measured by transport protocols for
-              various destinations, and that these values might be used
-              to dynamically determine a reasonable reassembly timeout
-
-
-
-Internet Engineering Task Force                                [Page 57]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-              value.  Further investigation of this approach is
-              required.
-
-              If the reassembly timeout is set too high, buffer
-              resources in the receiving host will be tied up too long,
-              and the MSL (Maximum Segment Lifetime) [TCP:1] will be
-              larger than necessary.  The MSL controls the maximum rate
-              at which fragmented datagrams can be sent using distinct
-              values of the 16-bit Ident field; a larger MSL lowers the
-              maximum rate.  The TCP specification [TCP:1] arbitrarily
-              assumes a value of 2 minutes for MSL.  This sets an upper
-              limit on a reasonable reassembly timeout value.
-
-      3.3.3  Fragmentation
-
-         Optionally, the IP layer MAY implement a mechanism to fragment
-         outgoing datagrams intentionally.
-
-         We designate by EMTU_S ("Effective MTU for sending") the
-         maximum IP datagram size that may be sent, for a particular
-         combination of IP source and destination addresses and perhaps
-         TOS.
-
-         A host MUST implement a mechanism to allow the transport layer
-         to learn MMS_S, the maximum transport-layer message size that
-         may be sent for a given {source, destination, TOS} triplet (see
-         GET_MAXSIZES call in Section 3.4).  If no local fragmentation
-         is performed, the value of MMS_S will be:
-
-            MMS_S = EMTU_S - <IP header size>
-
-         and EMTU_S must be less than or equal to the MTU of the network
-         interface corresponding to the source address of the datagram.
-         Note that <IP header size> in this equation will be 20, unless
-         the IP reserves space to insert IP options for its own purposes
-         in addition to any options inserted by the transport layer.
-
-         A host that does not implement local fragmentation MUST ensure
-         that the transport layer (for TCP) or the application layer
-         (for UDP) obtains MMS_S from the IP layer and does not send a
-         datagram exceeding MMS_S in size.
-
-         It is generally desirable to avoid local fragmentation and to
-         choose EMTU_S low enough to avoid fragmentation in any gateway
-         along the path.  In the absence of actual knowledge of the
-         minimum MTU along the path, the IP layer SHOULD use
-         EMTU_S <= 576 whenever the destination address is not on a
-         connected network, and otherwise use the connected network's
-
-
-
-Internet Engineering Task Force                                [Page 58]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-         MTU.
-
-         The MTU of each physical interface MUST be configurable.
-
-         A host IP layer implementation MAY have a configuration flag
-         "All-Subnets-MTU", indicating that the MTU of the connected
-         network is to be used for destinations on different subnets
-         within the same network, but not for other networks.  Thus,
-         this flag causes the network class mask, rather than the subnet
-         address mask, to be used to choose an EMTU_S.  For a multihomed
-         host, an "All-Subnets-MTU" flag is needed for each network
-         interface.
-
-         DISCUSSION:
-              Picking the correct datagram size to use when sending data
-              is a complex topic [IP:9].
-
-              (a)  In general, no host is required to accept an IP
-                   datagram larger than 576 bytes (including header and
-                   data), so a host must not send a larger datagram
-                   without explicit knowledge or prior arrangement with
-                   the destination host.  Thus, MMS_S is only an upper
-                   bound on the datagram size that a transport protocol
-                   may send; even when MMS_S exceeds 556, the transport
-                   layer must limit its messages to 556 bytes in the
-                   absence of other knowledge about the destination
-                   host.
-
-              (b)  Some transport protocols (e.g., TCP) provide a way to
-                   explicitly inform the sender about the largest
-                   datagram the other end can receive and reassemble
-                   [IP:7].  There is no corresponding mechanism in the
-                   IP layer.
-
-                   A transport protocol that assumes an EMTU_R larger
-                   than 576 (see Section 3.3.2), can send a datagram of
-                   this larger size to another host that implements the
-                   same protocol.
-
-              (c)  Hosts should ideally limit their EMTU_S for a given
-                   destination to the minimum MTU of all the networks
-                   along the path, to avoid any fragmentation.  IP
-                   fragmentation, while formally correct, can create a
-                   serious transport protocol performance problem,
-                   because loss of a single fragment means all the
-                   fragments in the segment must be retransmitted
-                   [IP:9].
-
-
-
-
-Internet Engineering Task Force                                [Page 59]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-              Since nearly all networks in the Internet currently
-              support an MTU of 576 or greater, we strongly recommend
-              the use of 576 for datagrams sent to non-local networks.
-
-              It has been suggested that a host could determine the MTU
-              over a given path by sending a zero-offset datagram
-              fragment and waiting for the receiver to time out the
-              reassembly (which cannot complete!) and return an ICMP
-              Time Exceeded message.  This message would include the
-              largest remaining fragment header in its body.  More
-              direct mechanisms are being experimented with, but have
-              not yet been adopted (see e.g., RFC-1063).
-
-      3.3.4  Local Multihoming
-
-         3.3.4.1  Introduction
-
-            A multihomed host has multiple IP addresses, which we may
-            think of as "logical interfaces".  These logical interfaces
-            may be associated with one or more physical interfaces, and
-            these physical interfaces may be connected to the same or
-            different networks.
-
-            Here are some important cases of multihoming:
-
-            (a)  Multiple Logical Networks
-
-                 The Internet architects envisioned that each physical
-                 network would have a single unique IP network (or
-                 subnet) number.  However, LAN administrators have
-                 sometimes found it useful to violate this assumption,
-                 operating a LAN with multiple logical networks per
-                 physical connected network.
-
-                 If a host connected to such a physical network is
-                 configured to handle traffic for each of N different
-                 logical networks, then the host will have N logical
-                 interfaces.  These could share a single physical
-                 interface, or might use N physical interfaces to the
-                 same network.
-
-            (b)  Multiple Logical Hosts
-
-                 When a host has multiple IP addresses that all have the
-                 same <Network-number> part (and the same <Subnet-
-                 number> part, if any), the logical interfaces are known
-                 as "logical hosts".  These logical interfaces might
-                 share a single physical interface or might use separate
-
-
-
-Internet Engineering Task Force                                [Page 60]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 physical interfaces to the same physical network.
-
-            (c)  Simple Multihoming
-
-                 In this case, each logical interface is mapped into a
-                 separate physical interface and each physical interface
-                 is connected to a different physical network.  The term
-                 "multihoming" was originally applied only to this case,
-                 but it is now applied more generally.
-
-                 A host with embedded gateway functionality will
-                 typically fall into the simple multihoming case.  Note,
-                 however, that a host may be simply multihomed without
-                 containing an embedded gateway, i.e., without
-                 forwarding datagrams from one connected network to
-                 another.
-
-                 This case presents the most difficult routing problems.
-                 The choice of interface (i.e., the choice of first-hop
-                 network) may significantly affect performance or even
-                 reachability of remote parts of the Internet.
-
-
-            Finally, we note another possibility that is NOT
-            multihoming:  one logical interface may be bound to multiple
-            physical interfaces, in order to increase the reliability or
-            throughput between directly connected machines by providing
-            alternative physical paths between them.  For instance, two
-            systems might be connected by multiple point-to-point links.
-            We call this "link-layer multiplexing".  With link-layer
-            multiplexing, the protocols above the link layer are unaware
-            that multiple physical interfaces are present; the link-
-            layer device driver is responsible for multiplexing and
-            routing packets across the physical interfaces.
-
-            In the Internet protocol architecture, a transport protocol
-            instance ("entity") has no address of its own, but instead
-            uses a single Internet Protocol (IP) address.  This has
-            implications for the IP, transport, and application layers,
-            and for the interfaces between them.  In particular, the
-            application software may have to be aware of the multiple IP
-            addresses of a multihomed host; in other cases, the choice
-            can be made within the network software.
-
-         3.3.4.2  Multihoming Requirements
-
-            The following general rules apply to the selection of an IP
-            source address for sending a datagram from a multihomed
-
-
-
-Internet Engineering Task Force                                [Page 61]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-            host.
-
-            (1)  If the datagram is sent in response to a received
-                 datagram, the source address for the response SHOULD be
-                 the specific-destination address of the request.  See
-                 Sections 4.1.3.5 and 4.2.3.7 and the "General Issues"
-                 section of [INTRO:1] for more specific requirements on
-                 higher layers.
-
-                 Otherwise, a source address must be selected.
-
-            (2)  An application MUST be able to explicitly specify the
-                 source address for initiating a connection or a
-                 request.
-
-            (3)  In the absence of such a specification, the networking
-                 software MUST choose a source address.  Rules for this
-                 choice are described below.
-
-
-            There are two key requirement issues related to multihoming:
-
-            (A)  A host MAY silently discard an incoming datagram whose
-                 destination address does not correspond to the physical
-                 interface through which it is received.
-
-            (B)  A host MAY restrict itself to sending (non-source-
-                 routed) IP datagrams only through the physical
-                 interface that corresponds to the IP source address of
-                 the datagrams.
-
-
-            DISCUSSION:
-                 Internet host implementors have used two different
-                 conceptual models for multihoming, briefly summarized
-                 in the following discussion.  This document takes no
-                 stand on which model is preferred; each seems to have a
-                 place.  This ambivalence is reflected in the issues (A)
-                 and (B) being optional.
-
-                 o    Strong ES Model
-
-                      The Strong ES (End System, i.e., host) model
-                      emphasizes the host/gateway (ES/IS) distinction,
-                      and would therefore substitute MUST for MAY in
-                      issues (A) and (B) above.  It tends to model a
-                      multihomed host as a set of logical hosts within
-                      the same physical host.
-
-
-
-Internet Engineering Task Force                                [Page 62]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                      With respect to (A), proponents of the Strong ES
-                      model note that automatic Internet routing
-                      mechanisms could not route a datagram to a
-                      physical interface that did not correspond to the
-                      destination address.
-
-                      Under the Strong ES model, the route computation
-                      for an outgoing datagram is the mapping:
-
-                         route(src IP addr, dest IP addr, TOS)
-                                                        -> gateway
-
-                      Here the source address is included as a parameter
-                      in order to select a gateway that is directly
-                      reachable on the corresponding physical interface.
-                      Note that this model logically requires that in
-                      general there be at least one default gateway, and
-                      preferably multiple defaults, for each IP source
-                      address.
-
-                 o    Weak ES Model
-
-                      This view de-emphasizes the ES/IS distinction, and
-                      would therefore substitute MUST NOT for MAY in
-                      issues (A) and (B).  This model may be the more
-                      natural one for hosts that wiretap gateway routing
-                      protocols, and is necessary for hosts that have
-                      embedded gateway functionality.
-
-                      The Weak ES Model may cause the Redirect mechanism
-                      to fail.  If a datagram is sent out a physical
-                      interface that does not correspond to the
-                      destination address, the first-hop gateway will
-                      not realize when it needs to send a Redirect.  On
-                      the other hand, if the host has embedded gateway
-                      functionality, then it has routing information
-                      without listening to Redirects.
-
-                      In the Weak ES model, the route computation for an
-                      outgoing datagram is the mapping:
-
-                         route(dest IP addr, TOS) -> gateway, interface
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 63]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-         3.3.4.3  Choosing a Source Address
-
-            DISCUSSION:
-                 When it sends an initial connection request (e.g., a
-                 TCP "SYN" segment) or a datagram service request (e.g.,
-                 a UDP-based query), the transport layer on a multihomed
-                 host needs to know which source address to use.  If the
-                 application does not specify it, the transport layer
-                 must ask the IP layer to perform the conceptual
-                 mapping:
-
-                     GET_SRCADDR(remote IP addr, TOS)
-                                               -> local IP address
-
-                 Here TOS is the Type-of-Service value (see Section
-                 3.2.1.6), and the result is the desired source address.
-                 The following rules are suggested for implementing this
-                 mapping:
-
-                 (a)  If the remote Internet address lies on one of the
-                      (sub-) nets to which the host is directly
-                      connected, a corresponding source address may be
-                      chosen, unless the corresponding interface is
-                      known to be down.
-
-                 (b)  The route cache may be consulted, to see if there
-                      is an active route to the specified destination
-                      network through any network interface; if so, a
-                      local IP address corresponding to that interface
-                      may be chosen.
-
-                 (c)  The table of static routes, if any (see Section
-                      3.3.1.2) may be similarly consulted.
-
-                 (d)  The default gateways may be consulted.  If these
-                      gateways are assigned to different interfaces, the
-                      interface corresponding to the gateway with the
-                      highest preference may be chosen.
-
-                 In the future, there may be a defined way for a
-                 multihomed host to ask the gateways on all connected
-                 networks for advice about the best network to use for a
-                 given destination.
-
-            IMPLEMENTATION:
-                 It will be noted that this process is essentially the
-                 same as datagram routing (see Section 3.3.1), and
-                 therefore hosts may be able to combine the
-
-
-
-Internet Engineering Task Force                                [Page 64]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                 implementation of the two functions.
-
-      3.3.5  Source Route Forwarding
-
-         Subject to restrictions given below, a host MAY be able to act
-         as an intermediate hop in a source route, forwarding a source-
-         routed datagram to the next specified hop.
-
-         However, in performing this gateway-like function, the host
-         MUST obey all the relevant rules for a gateway forwarding
-         source-routed datagrams [INTRO:2].  This includes the following
-         specific provisions, which override the corresponding host
-         provisions given earlier in this document:
-
-         (A)  TTL (ref. Section 3.2.1.7)
-
-              The TTL field MUST be decremented and the datagram perhaps
-              discarded as specified for a gateway in [INTRO:2].
-
-         (B)  ICMP Destination Unreachable (ref. Section 3.2.2.1)
-
-              A host MUST be able to generate Destination Unreachable
-              messages with the following codes:
-
-              4    (Fragmentation Required but DF Set) when a source-
-                   routed datagram cannot be fragmented to fit into the
-                   target network;
-
-              5    (Source Route Failed) when a source-routed datagram
-                   cannot be forwarded, e.g., because of a routing
-                   problem or because the next hop of a strict source
-                   route is not on a connected network.
-
-         (C)  IP Source Address (ref. Section 3.2.1.3)
-
-              A source-routed datagram being forwarded MAY (and normally
-              will) have a source address that is not one of the IP
-              addresses of the forwarding host.
-
-         (D)  Record Route Option (ref. Section 3.2.1.8d)
-
-              A host that is forwarding a source-routed datagram
-              containing a Record Route option MUST update that option,
-              if it has room.
-
-         (E)  Timestamp Option (ref. Section 3.2.1.8e)
-
-              A host that is forwarding a source-routed datagram
-
-
-
-Internet Engineering Task Force                                [Page 65]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-              containing a Timestamp Option MUST add the current
-              timestamp to that option, according to the rules for this
-              option.
-
-         To define the rules restricting host forwarding of source-
-         routed datagrams, we use the term "local source-routing" if the
-         next hop will be through the same physical interface through
-         which the datagram arrived; otherwise, it is "non-local
-         source-routing".
-
-         o    A host is permitted to perform local source-routing
-              without restriction.
-
-         o    A host that supports non-local source-routing MUST have a
-              configurable switch to disable forwarding, and this switch
-              MUST default to disabled.
-
-         o    The host MUST satisfy all gateway requirements for
-              configurable policy filters [INTRO:2] restricting non-
-              local forwarding.
-
-         If a host receives a datagram with an incomplete source route
-         but does not forward it for some reason, the host SHOULD return
-         an ICMP Destination Unreachable (code 5, Source Route Failed)
-         message, unless the datagram was itself an ICMP error message.
-
-      3.3.6  Broadcasts
-
-         Section 3.2.1.3 defined the four standard IP broadcast address
-         forms:
-
-           Limited Broadcast:  {-1, -1}
-
-           Directed Broadcast:  {<Network-number>,-1}
-
-           Subnet Directed Broadcast:
-                              {<Network-number>,<Subnet-number>,-1}
-
-           All-Subnets Directed Broadcast: {<Network-number>,-1,-1}
-
-         A host MUST recognize any of these forms in the destination
-         address of an incoming datagram.
-
-         There is a class of hosts* that use non-standard broadcast
-         address forms, substituting 0 for -1.  All hosts SHOULD
-_________________________
-*4.2BSD Unix and its derivatives, but not 4.3BSD.
-
-
-
-
-Internet Engineering Task Force                                [Page 66]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-         recognize and accept any of these non-standard broadcast
-         addresses as the destination address of an incoming datagram.
-         A host MAY optionally have a configuration option to choose the
-         0 or the -1 form of broadcast address, for each physical
-         interface, but this option SHOULD default to the standard (-1)
-         form.
-
-         When a host sends a datagram to a link-layer broadcast address,
-         the IP destination address MUST be a legal IP broadcast or IP
-         multicast address.
-
-         A host SHOULD silently discard a datagram that is received via
-         a link-layer broadcast (see Section 2.4) but does not specify
-         an IP multicast or broadcast destination address.
-
-         Hosts SHOULD use the Limited Broadcast address to broadcast to
-         a connected network.
-
-
-         DISCUSSION:
-              Using the Limited Broadcast address instead of a Directed
-              Broadcast address may improve system robustness.  Problems
-              are often caused by machines that do not understand the
-              plethora of broadcast addresses (see Section 3.2.1.3), or
-              that may have different ideas about which broadcast
-              addresses are in use.  The prime example of the latter is
-              machines that do not understand subnetting but are
-              attached to a subnetted net.  Sending a Subnet Broadcast
-              for the connected network will confuse those machines,
-              which will see it as a message to some other host.
-
-              There has been discussion on whether a datagram addressed
-              to the Limited Broadcast address ought to be sent from all
-              the interfaces of a multihomed host.  This specification
-              takes no stand on the issue.
-
-      3.3.7  IP Multicasting
-
-         A host SHOULD support local IP multicasting on all connected
-         networks for which a mapping from Class D IP addresses to
-         link-layer addresses has been specified (see below).  Support
-         for local IP multicasting includes sending multicast datagrams,
-         joining multicast groups and receiving multicast datagrams, and
-         leaving multicast groups.  This implies support for all of
-         [IP:4] except the IGMP protocol itself, which is OPTIONAL.
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 67]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-         DISCUSSION:
-              IGMP provides gateways that are capable of multicast
-              routing with the information required to support IP
-              multicasting across multiple networks.  At this time,
-              multicast-routing gateways are in the experimental stage
-              and are not widely available.  For hosts that are not
-              connected to networks with multicast-routing gateways or
-              that do not need to receive multicast datagrams
-              originating on other networks, IGMP serves no purpose and
-              is therefore optional for now.  However, the rest of
-              [IP:4] is currently recommended for the purpose of
-              providing IP-layer access to local network multicast
-              addressing, as a preferable alternative to local broadcast
-              addressing.  It is expected that IGMP will become
-              recommended at some future date, when multicast-routing
-              gateways have become more widely available.
-
-         If IGMP is not implemented, a host SHOULD still join the "all-
-         hosts" group (224.0.0.1) when the IP layer is initialized and
-         remain a member for as long as the IP layer is active.
-
-         DISCUSSION:
-              Joining the "all-hosts" group will support strictly local
-              uses of multicasting, e.g., a gateway discovery protocol,
-              even if IGMP is not implemented.
-
-         The mapping of IP Class D addresses to local addresses is
-         currently specified for the following types of networks:
-
-         o    Ethernet/IEEE 802.3, as defined in [IP:4].
-
-         o    Any network that supports broadcast but not multicast,
-              addressing: all IP Class D addresses map to the local
-              broadcast address.
-
-         o    Any type of point-to-point link (e.g., SLIP or HDLC
-              links): no mapping required.  All IP multicast datagrams
-              are sent as-is, inside the local framing.
-
-         Mappings for other types of networks will be specified in the
-         future.
-
-         A host SHOULD provide a way for higher-layer protocols or
-         applications to determine which of the host's connected
-         network(s) support IP multicast addressing.
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 68]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-      3.3.8  Error Reporting
-
-         Wherever practical, hosts MUST return ICMP error datagrams on
-         detection of an error, except in those cases where returning an
-         ICMP error message is specifically prohibited.
-
-         DISCUSSION:
-              A common phenomenon in datagram networks is the "black
-              hole disease": datagrams are sent out, but nothing comes
-              back.  Without any error datagrams, it is difficult for
-              the user to figure out what the problem is.
-
-   3.4  INTERNET/TRANSPORT LAYER INTERFACE
-
-      The interface between the IP layer and the transport layer MUST
-      provide full access to all the mechanisms of the IP layer,
-      including options, Type-of-Service, and Time-to-Live.  The
-      transport layer MUST either have mechanisms to set these interface
-      parameters, or provide a path to pass them through from an
-      application, or both.
-
-      DISCUSSION:
-           Applications are urged to make use of these mechanisms where
-           applicable, even when the mechanisms are not currently
-           effective in the Internet (e.g., TOS).  This will allow these
-           mechanisms to be immediately useful when they do become
-           effective, without a large amount of retrofitting of host
-           software.
-
-      We now describe a conceptual interface between the transport layer
-      and the IP layer, as a set of procedure calls.  This is an
-      extension of the information in Section 3.3 of RFC-791 [IP:1].
-
-
-      *    Send Datagram
-
-                SEND(src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt
-                     => result )
-
-           where the parameters are defined in RFC-791.  Passing an Id
-           parameter is optional; see Section 3.2.1.5.
-
-
-      *    Receive Datagram
-
-                RECV(BufPTR, prot
-                     => result, src, dst, SpecDest, TOS, len, opt)
-
-
-
-
-Internet Engineering Task Force                                [Page 69]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-           All the parameters are defined in RFC-791, except for:
-
-                SpecDest = specific-destination address of datagram
-                            (defined in Section 3.2.1.3)
-
-           The result parameter dst contains the datagram's destination
-           address.  Since this may be a broadcast or multicast address,
-           the SpecDest parameter (not shown in RFC-791) MUST be passed.
-           The parameter opt contains all the IP options received in the
-           datagram; these MUST also be passed to the transport layer.
-
-
-      *    Select Source Address
-
-                GET_SRCADDR(remote, TOS)  -> local
-
-                remote = remote IP address
-                TOS = Type-of-Service
-                local = local IP address
-
-           See Section 3.3.4.3.
-
-
-      *    Find Maximum Datagram Sizes
-
-                GET_MAXSIZES(local, remote, TOS) -> MMS_R, MMS_S
-
-                MMS_R = maximum receive transport-message size.
-                MMS_S = maximum send transport-message size.
-               (local, remote, TOS defined above)
-
-           See Sections 3.3.2 and 3.3.3.
-
-
-      *    Advice on Delivery Success
-
-                ADVISE_DELIVPROB(sense, local, remote, TOS)
-
-           Here the parameter sense is a 1-bit flag indicating whether
-           positive or negative advice is being given; see the
-           discussion in Section 3.3.1.4. The other parameters were
-           defined earlier.
-
-
-      *    Send ICMP Message
-
-                SEND_ICMP(src, dst, TOS, TTL, BufPTR, len, Id, DF, opt)
-                     -> result
-
-
-
-Internet Engineering Task Force                                [Page 70]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                (Parameters defined in RFC-791).
-
-           Passing an Id parameter is optional; see Section 3.2.1.5.
-           The transport layer MUST be able to send certain ICMP
-           messages:  Port Unreachable or any of the query-type
-           messages.  This function could be considered to be a special
-           case of the SEND() call, of course; we describe it separately
-           for clarity.
-
-
-      *    Receive ICMP Message
-
-                RECV_ICMP(BufPTR ) -> result, src, dst, len, opt
-
-                (Parameters defined in RFC-791).
-
-           The IP layer MUST pass certain ICMP messages up to the
-           appropriate transport-layer routine.  This function could be
-           considered to be a special case of the RECV() call, of
-           course; we describe it separately for clarity.
-
-           For an ICMP error message, the data that is passed up MUST
-           include the original Internet header plus all the octets of
-           the original message that are included in the ICMP message.
-           This data will be used by the transport layer to locate the
-           connection state information, if any.
-
-           In particular, the following ICMP messages are to be passed
-           up:
-
-           o    Destination Unreachable
-
-           o    Source Quench
-
-           o    Echo Reply (to ICMP user interface, unless the Echo
-                Request originated in the IP layer)
-
-           o    Timestamp Reply (to ICMP user interface)
-
-           o    Time Exceeded
-
-
-      DISCUSSION:
-           In the future, there may be additions to this interface to
-           pass path data (see Section 3.3.1.3) between the IP and
-           transport layers.
-
-
-
-
-
-Internet Engineering Task Force                                [Page 71]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-   3.5  INTERNET LAYER REQUIREMENTS SUMMARY
-
-
-                                                 |        | | | |S| |
-                                                 |        | | | |H| |F
-                                                 |        | | | |O|M|o
-                                                 |        | |S| |U|U|o
-                                                 |        | |H| |L|S|t
-                                                 |        |M|O| |D|T|n
-                                                 |        |U|U|M| | |o
-                                                 |        |S|L|A|N|N|t
-                                                 |        |T|D|Y|O|O|t
-FEATURE                                          |SECTION | | | |T|T|e
--------------------------------------------------|--------|-|-|-|-|-|--
-                                                 |        | | | | | |
-Implement IP and ICMP                            |3.1     |x| | | | |
-Handle remote multihoming in application layer   |3.1     |x| | | | |
-Support local multihoming                        |3.1     | | |x| | |
-Meet gateway specs if forward datagrams          |3.1     |x| | | | |
-Configuration switch for embedded gateway        |3.1     |x| | | | |1
-   Config switch default to non-gateway          |3.1     |x| | | | |1
-   Auto-config based on number of interfaces     |3.1     | | | | |x|1
-Able to log discarded datagrams                  |3.1     | |x| | | |
-   Record in counter                             |3.1     | |x| | | |
-                                                 |        | | | | | |
-Silently discard Version != 4                    |3.2.1.1 |x| | | | |
-Verify IP checksum, silently discard bad dgram   |3.2.1.2 |x| | | | |
-Addressing:                                      |        | | | | | |
-  Subnet addressing (RFC-950)                    |3.2.1.3 |x| | | | |
-  Src address must be host's own IP address      |3.2.1.3 |x| | | | |
-  Silently discard datagram with bad dest addr   |3.2.1.3 |x| | | | |
-  Silently discard datagram with bad src addr    |3.2.1.3 |x| | | | |
-Support reassembly                               |3.2.1.4 |x| | | | |
-Retain same Id field in identical datagram       |3.2.1.5 | | |x| | |
-                                                 |        | | | | | |
-TOS:                                             |        | | | | | |
-  Allow transport layer to set TOS               |3.2.1.6 |x| | | | |
-  Pass received TOS up to transport layer        |3.2.1.6 | |x| | | |
-  Use RFC-795 link-layer mappings for TOS        |3.2.1.6 | | | |x| |
-TTL:                                             |        | | | | | |
-  Send packet with TTL of 0                      |3.2.1.7 | | | | |x|
-  Discard received packets with TTL < 2          |3.2.1.7 | | | | |x|
-  Allow transport layer to set TTL               |3.2.1.7 |x| | | | |
-  Fixed TTL is configurable                      |3.2.1.7 |x| | | | |
-                                                 |        | | | | | |
-IP Options:                                      |        | | | | | |
-  Allow transport layer to send IP options       |3.2.1.8 |x| | | | |
-  Pass all IP options rcvd to higher layer       |3.2.1.8 |x| | | | |
-
-
-
-Internet Engineering Task Force                                [Page 72]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-  IP layer silently ignore unknown options       |3.2.1.8 |x| | | | |
-  Security option                                |3.2.1.8a| | |x| | |
-  Send Stream Identifier option                  |3.2.1.8b| | | |x| |
-  Silently ignore Stream Identifer option        |3.2.1.8b|x| | | | |
-  Record Route option                            |3.2.1.8d| | |x| | |
-  Timestamp option                               |3.2.1.8e| | |x| | |
-Source Route Option:                             |        | | | | | |
-  Originate & terminate Source Route options     |3.2.1.8c|x| | | | |
-  Datagram with completed SR passed up to TL     |3.2.1.8c|x| | | | |
-  Build correct (non-redundant) return route     |3.2.1.8c|x| | | | |
-  Send multiple SR options in one header         |3.2.1.8c| | | | |x|
-                                                 |        | | | | | |
-ICMP:                                            |        | | | | | |
-  Silently discard ICMP msg with unknown type    |3.2.2   |x| | | | |
-  Include more than 8 octets of orig datagram    |3.2.2   | | |x| | |
-      Included octets same as received           |3.2.2   |x| | | | |
-  Demux ICMP Error to transport protocol         |3.2.2   |x| | | | |
-  Send ICMP error message with TOS=0             |3.2.2   | |x| | | |
-  Send ICMP error message for:                   |        | | | | | |
-   - ICMP error msg                              |3.2.2   | | | | |x|
-   - IP b'cast or IP m'cast                      |3.2.2   | | | | |x|
-   - Link-layer b'cast                           |3.2.2   | | | | |x|
-   - Non-initial fragment                        |3.2.2   | | | | |x|
-   - Datagram with non-unique src address        |3.2.2   | | | | |x|
-  Return ICMP error msgs (when not prohibited)   |3.3.8   |x| | | | |
-                                                 |        | | | | | |
-  Dest Unreachable:                              |        | | | | | |
-    Generate Dest Unreachable (code 2/3)         |3.2.2.1 | |x| | | |
-    Pass ICMP Dest Unreachable to higher layer   |3.2.2.1 |x| | | | |
-    Higher layer act on Dest Unreach             |3.2.2.1 | |x| | | |
-      Interpret Dest Unreach as only hint        |3.2.2.1 |x| | | | |
-  Redirect:                                      |        | | | | | |
-    Host send Redirect                           |3.2.2.2 | | | |x| |
-    Update route cache when recv Redirect        |3.2.2.2 |x| | | | |
-    Handle both Host and Net Redirects           |3.2.2.2 |x| | | | |
-    Discard illegal Redirect                     |3.2.2.2 | |x| | | |
-  Source Quench:                                 |        | | | | | |
-    Send Source Quench if buffering exceeded     |3.2.2.3 | | |x| | |
-    Pass Source Quench to higher layer           |3.2.2.3 |x| | | | |
-    Higher layer act on Source Quench            |3.2.2.3 | |x| | | |
-  Time Exceeded: pass to higher layer            |3.2.2.4 |x| | | | |
-  Parameter Problem:                             |        | | | | | |
-    Send Parameter Problem messages              |3.2.2.5 | |x| | | |
-    Pass Parameter Problem to higher layer       |3.2.2.5 |x| | | | |
-    Report Parameter Problem to user             |3.2.2.5 | | |x| | |
-                                                 |        | | | | | |
-  ICMP Echo Request or Reply:                    |        | | | | | |
-    Echo server and Echo client                  |3.2.2.6 |x| | | | |
-
-
-
-Internet Engineering Task Force                                [Page 73]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-    Echo client                                  |3.2.2.6 | |x| | | |
-    Discard Echo Request to broadcast address    |3.2.2.6 | | |x| | |
-    Discard Echo Request to multicast address    |3.2.2.6 | | |x| | |
-    Use specific-dest addr as Echo Reply src     |3.2.2.6 |x| | | | |
-    Send same data in Echo Reply                 |3.2.2.6 |x| | | | |
-    Pass Echo Reply to higher layer              |3.2.2.6 |x| | | | |
-    Reflect Record Route, Time Stamp options     |3.2.2.6 | |x| | | |
-    Reverse and reflect Source Route option      |3.2.2.6 |x| | | | |
-                                                 |        | | | | | |
-  ICMP Information Request or Reply:             |3.2.2.7 | | | |x| |
-  ICMP Timestamp and Timestamp Reply:            |3.2.2.8 | | |x| | |
-    Minimize delay variability                   |3.2.2.8 | |x| | | |1
-    Silently discard b'cast Timestamp            |3.2.2.8 | | |x| | |1
-    Silently discard m'cast Timestamp            |3.2.2.8 | | |x| | |1
-    Use specific-dest addr as TS Reply src       |3.2.2.8 |x| | | | |1
-    Reflect Record Route, Time Stamp options     |3.2.2.6 | |x| | | |1
-    Reverse and reflect Source Route option      |3.2.2.8 |x| | | | |1
-    Pass Timestamp Reply to higher layer         |3.2.2.8 |x| | | | |1
-    Obey rules for "standard value"              |3.2.2.8 |x| | | | |1
-                                                 |        | | | | | |
-  ICMP Address Mask Request and Reply:           |        | | | | | |
-    Addr Mask source configurable                |3.2.2.9 |x| | | | |
-    Support static configuration of addr mask    |3.2.2.9 |x| | | | |
-    Get addr mask dynamically during booting     |3.2.2.9 | | |x| | |
-    Get addr via ICMP Addr Mask Request/Reply    |3.2.2.9 | | |x| | |
-      Retransmit Addr Mask Req if no Reply       |3.2.2.9 |x| | | | |3
-      Assume default mask if no Reply            |3.2.2.9 | |x| | | |3
-      Update address mask from first Reply only  |3.2.2.9 |x| | | | |3
-    Reasonableness check on Addr Mask            |3.2.2.9 | |x| | | |
-    Send unauthorized Addr Mask Reply msgs       |3.2.2.9 | | | | |x|
-      Explicitly configured to be agent          |3.2.2.9 |x| | | | |
-    Static config=> Addr-Mask-Authoritative flag |3.2.2.9 | |x| | | |
-      Broadcast Addr Mask Reply when init.       |3.2.2.9 |x| | | | |3
-                                                 |        | | | | | |
-ROUTING OUTBOUND DATAGRAMS:                      |        | | | | | |
-  Use address mask in local/remote decision      |3.3.1.1 |x| | | | |
-  Operate with no gateways on conn network       |3.3.1.1 |x| | | | |
-  Maintain "route cache" of next-hop gateways    |3.3.1.2 |x| | | | |
-  Treat Host and Net Redirect the same           |3.3.1.2 | |x| | | |
-  If no cache entry, use default gateway         |3.3.1.2 |x| | | | |
-    Support multiple default gateways            |3.3.1.2 |x| | | | |
-  Provide table of static routes                 |3.3.1.2 | | |x| | |
-    Flag: route overridable by Redirects         |3.3.1.2 | | |x| | |
-  Key route cache on host, not net address       |3.3.1.3 | | |x| | |
-  Include TOS in route cache                     |3.3.1.3 | |x| | | |
-                                                 |        | | | | | |
-  Able to detect failure of next-hop gateway     |3.3.1.4 |x| | | | |
-  Assume route is good forever                   |3.3.1.4 | | | |x| |
-
-
-
-Internet Engineering Task Force                                [Page 74]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-  Ping gateways continuously                     |3.3.1.4 | | | | |x|
-  Ping only when traffic being sent              |3.3.1.4 |x| | | | |
-  Ping only when no positive indication          |3.3.1.4 |x| | | | |
-  Higher and lower layers give advice            |3.3.1.4 | |x| | | |
-  Switch from failed default g'way to another    |3.3.1.5 |x| | | | |
-  Manual method of entering config info          |3.3.1.6 |x| | | | |
-                                                 |        | | | | | |
-REASSEMBLY and FRAGMENTATION:                    |        | | | | | |
-  Able to reassemble incoming datagrams          |3.3.2   |x| | | | |
-    At least 576 byte datagrams                  |3.3.2   |x| | | | |
-    EMTU_R configurable or indefinite            |3.3.2   | |x| | | |
-  Transport layer able to learn MMS_R            |3.3.2   |x| | | | |
-  Send ICMP Time Exceeded on reassembly timeout  |3.3.2   |x| | | | |
-    Fixed reassembly timeout value               |3.3.2   | |x| | | |
-                                                 |        | | | | | |
-  Pass MMS_S to higher layers                    |3.3.3   |x| | | | |
-  Local fragmentation of outgoing packets        |3.3.3   | | |x| | |
-     Else don't send bigger than MMS_S           |3.3.3   |x| | | | |
-  Send max 576 to off-net destination            |3.3.3   | |x| | | |
-  All-Subnets-MTU configuration flag             |3.3.3   | | |x| | |
-                                                 |        | | | | | |
-MULTIHOMING:                                     |        | | | | | |
-  Reply with same addr as spec-dest addr         |3.3.4.2 | |x| | | |
-  Allow application to choose local IP addr      |3.3.4.2 |x| | | | |
-  Silently discard d'gram in "wrong" interface   |3.3.4.2 | | |x| | |
-  Only send d'gram through "right" interface     |3.3.4.2 | | |x| | |4
-                                                 |        | | | | | |
-SOURCE-ROUTE FORWARDING:                         |        | | | | | |
-  Forward datagram with Source Route option      |3.3.5   | | |x| | |1
-    Obey corresponding gateway rules             |3.3.5   |x| | | | |1
-      Update TTL by gateway rules                |3.3.5   |x| | | | |1
-      Able to generate ICMP err code 4, 5        |3.3.5   |x| | | | |1
-      IP src addr not local host                 |3.3.5   | | |x| | |1
-      Update Timestamp, Record Route options     |3.3.5   |x| | | | |1
-    Configurable switch for non-local SRing      |3.3.5   |x| | | | |1
-      Defaults to OFF                            |3.3.5   |x| | | | |1
-    Satisfy gwy access rules for non-local SRing |3.3.5   |x| | | | |1
-    If not forward, send Dest Unreach (cd 5)     |3.3.5   | |x| | | |2
-                                                 |        | | | | | |
-BROADCAST:                                       |        | | | | | |
-  Broadcast addr as IP source addr               |3.2.1.3 | | | | |x|
-  Receive 0 or -1 broadcast formats OK           |3.3.6   | |x| | | |
-  Config'ble option to send 0 or -1 b'cast       |3.3.6   | | |x| | |
-    Default to -1 broadcast                      |3.3.6   | |x| | | |
-  Recognize all broadcast address formats        |3.3.6   |x| | | | |
-  Use IP b'cast/m'cast addr in link-layer b'cast |3.3.6   |x| | | | |
-  Silently discard link-layer-only b'cast dg's   |3.3.6   | |x| | | |
-  Use Limited Broadcast addr for connected net   |3.3.6   | |x| | | |
-
-
-
-Internet Engineering Task Force                                [Page 75]
-
-
-
-
-RFC1122                      INTERNET LAYER                 October 1989
-
-
-                                                 |        | | | | | |
-MULTICAST:                                       |        | | | | | |
-  Support local IP multicasting (RFC-1112)       |3.3.7   | |x| | | |
-  Support IGMP (RFC-1112)                        |3.3.7   | | |x| | |
-  Join all-hosts group at startup                |3.3.7   | |x| | | |
-  Higher layers learn i'face m'cast capability   |3.3.7   | |x| | | |
-                                                 |        | | | | | |
-INTERFACE:                                       |        | | | | | |
-  Allow transport layer to use all IP mechanisms |3.4     |x| | | | |
-  Pass interface ident up to transport layer     |3.4     |x| | | | |
-  Pass all IP options up to transport layer      |3.4     |x| | | | |
-  Transport layer can send certain ICMP messages |3.4     |x| | | | |
-  Pass spec'd ICMP messages up to transp. layer  |3.4     |x| | | | |
-     Include IP hdr+8 octets or more from orig.  |3.4     |x| | | | |
-  Able to leap tall buildings at a single bound  |3.5     | |x| | | |
-
-Footnotes:
-
-(1)  Only if feature is implemented.
-
-(2)  This requirement is overruled if datagram is an ICMP error message.
-
-(3)  Only if feature is implemented and is configured "on".
-
-(4)  Unless has embedded gateway functionality or is source routed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 76]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- UDP             October 1989
-
-
-4. TRANSPORT PROTOCOLS
-
-   4.1  USER DATAGRAM PROTOCOL -- UDP
-
-      4.1.1  INTRODUCTION
-
-         The User Datagram Protocol UDP [UDP:1] offers only a minimal
-         transport service -- non-guaranteed datagram delivery -- and
-         gives applications direct access to the datagram service of the
-         IP layer.  UDP is used by applications that do not require the
-         level of service of TCP or that wish to use communications
-         services (e.g., multicast or broadcast delivery) not available
-         from TCP.
-
-         UDP is almost a null protocol; the only services it provides
-         over IP are checksumming of data and multiplexing by port
-         number.  Therefore, an application program running over UDP
-         must deal directly with end-to-end communication problems that
-         a connection-oriented protocol would have handled -- e.g.,
-         retransmission for reliable delivery, packetization and
-         reassembly, flow control, congestion avoidance, etc., when
-         these are required.  The fairly complex coupling between IP and
-         TCP will be mirrored in the coupling between UDP and many
-         applications using UDP.
-
-      4.1.2  PROTOCOL WALK-THROUGH
-
-         There are no known errors in the specification of UDP.
-
-      4.1.3  SPECIFIC ISSUES
-
-         4.1.3.1  Ports
-
-            UDP well-known ports follow the same rules as TCP well-known
-            ports; see Section 4.2.2.1 below.
-
-            If a datagram arrives addressed to a UDP port for which
-            there is no pending LISTEN call, UDP SHOULD send an ICMP
-            Port Unreachable message.
-
-         4.1.3.2  IP Options
-
-            UDP MUST pass any IP option that it receives from the IP
-            layer transparently to the application layer.
-
-            An application MUST be able to specify IP options to be sent
-            in its UDP datagrams, and UDP MUST pass these options to the
-            IP layer.
-
-
-
-Internet Engineering Task Force                                [Page 77]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- UDP             October 1989
-
-
-            DISCUSSION:
-                 At present, the only options that need be passed
-                 through UDP are Source Route, Record Route, and Time
-                 Stamp.  However, new options may be defined in the
-                 future, and UDP need not and should not make any
-                 assumptions about the format or content of options it
-                 passes to or from the application; an exception to this
-                 might be an IP-layer security option.
-
-                 An application based on UDP will need to obtain a
-                 source route from a request datagram and supply a
-                 reversed route for sending the corresponding reply.
-
-         4.1.3.3  ICMP Messages
-
-            UDP MUST pass to the application layer all ICMP error
-            messages that it receives from the IP layer.  Conceptually
-            at least, this may be accomplished with an upcall to the
-            ERROR_REPORT routine (see Section 4.2.4.1).
-
-            DISCUSSION:
-                 Note that ICMP error messages resulting from sending a
-                 UDP datagram are received asynchronously.  A UDP-based
-                 application that wants to receive ICMP error messages
-                 is responsible for maintaining the state necessary to
-                 demultiplex these messages when they arrive; for
-                 example, the application may keep a pending receive
-                 operation for this purpose.  The application is also
-                 responsible to avoid confusion from a delayed ICMP
-                 error message resulting from an earlier use of the same
-                 port(s).
-
-         4.1.3.4  UDP Checksums
-
-            A host MUST implement the facility to generate and validate
-            UDP checksums.  An application MAY optionally be able to
-            control whether a UDP checksum will be generated, but it
-            MUST default to checksumming on.
-
-            If a UDP datagram is received with a checksum that is non-
-            zero and invalid, UDP MUST silently discard the datagram.
-            An application MAY optionally be able to control whether UDP
-            datagrams without checksums should be discarded or passed to
-            the application.
-
-            DISCUSSION:
-                 Some applications that normally run only across local
-                 area networks have chosen to turn off UDP checksums for
-
-
-
-Internet Engineering Task Force                                [Page 78]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- UDP             October 1989
-
-
-                 efficiency.  As a result, numerous cases of undetected
-                 errors have been reported.  The advisability of ever
-                 turning off UDP checksumming is very controversial.
-
-            IMPLEMENTATION:
-                 There is a common implementation error in UDP
-                 checksums.  Unlike the TCP checksum, the UDP checksum
-                 is optional; the value zero is transmitted in the
-                 checksum field of a UDP header to indicate the absence
-                 of a checksum.  If the transmitter really calculates a
-                 UDP checksum of zero, it must transmit the checksum as
-                 all 1's (65535).  No special action is required at the
-                 receiver, since zero and 65535 are equivalent in 1's
-                 complement arithmetic.
-
-         4.1.3.5  UDP Multihoming
-
-            When a UDP datagram is received, its specific-destination
-            address MUST be passed up to the application layer.
-
-            An application program MUST be able to specify the IP source
-            address to be used for sending a UDP datagram or to leave it
-            unspecified (in which case the networking software will
-            choose an appropriate source address).  There SHOULD be a
-            way to communicate the chosen source address up to the
-            application layer (e.g, so that the application can later
-            receive a reply datagram only from the corresponding
-            interface).
-
-            DISCUSSION:
-                 A request/response application that uses UDP should use
-                 a source address for the response that is the same as
-                 the specific destination address of the request.  See
-                 the "General Issues" section of [INTRO:1].
-
-         4.1.3.6  Invalid Addresses
-
-            A UDP datagram received with an invalid IP source address
-            (e.g., a broadcast or multicast address) must be discarded
-            by UDP or by the IP layer (see Section 3.2.1.3).
-
-            When a host sends a UDP datagram, the source address MUST be
-            (one of) the IP address(es) of the host.
-
-      4.1.4  UDP/APPLICATION LAYER INTERFACE
-
-         The application interface to UDP MUST provide the full services
-         of the IP/transport interface described in Section 3.4 of this
-
-
-
-Internet Engineering Task Force                                [Page 79]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- UDP             October 1989
-
-
-         document.  Thus, an application using UDP needs the functions
-         of the GET_SRCADDR(), GET_MAXSIZES(), ADVISE_DELIVPROB(), and
-         RECV_ICMP() calls described in Section 3.4.  For example,
-         GET_MAXSIZES() can be used to learn the effective maximum UDP
-         maximum datagram size for a particular {interface,remote
-         host,TOS} triplet.
-
-         An application-layer program MUST be able to set the TTL and
-         TOS values as well as IP options for sending a UDP datagram,
-         and these values must be passed transparently to the IP layer.
-         UDP MAY pass the received TOS up to the application layer.
-
-      4.1.5  UDP REQUIREMENTS SUMMARY
-
-
-                                                 |        | | | |S| |
-                                                 |        | | | |H| |F
-                                                 |        | | | |O|M|o
-                                                 |        | |S| |U|U|o
-                                                 |        | |H| |L|S|t
-                                                 |        |M|O| |D|T|n
-                                                 |        |U|U|M| | |o
-                                                 |        |S|L|A|N|N|t
-                                                 |        |T|D|Y|O|O|t
-FEATURE                                          |SECTION | | | |T|T|e
--------------------------------------------------|--------|-|-|-|-|-|--
-                                                 |        | | | | | |
-    UDP                                          |        | | | | | |
--------------------------------------------------|--------|-|-|-|-|-|--
-                                                 |        | | | | | |
-UDP send Port Unreachable                        |4.1.3.1 | |x| | | |
-                                                 |        | | | | | |
-IP Options in UDP                                |        | | | | | |
- - Pass rcv'd IP options to applic layer         |4.1.3.2 |x| | | | |
- - Applic layer can specify IP options in Send   |4.1.3.2 |x| | | | |
- - UDP passes IP options down to IP layer        |4.1.3.2 |x| | | | |
-                                                 |        | | | | | |
-Pass ICMP msgs up to applic layer                |4.1.3.3 |x| | | | |
-                                                 |        | | | | | |
-UDP checksums:                                   |        | | | | | |
- - Able to generate/check checksum               |4.1.3.4 |x| | | | |
- - Silently discard bad checksum                 |4.1.3.4 |x| | | | |
- - Sender Option to not generate checksum        |4.1.3.4 | | |x| | |
-   - Default is to checksum                      |4.1.3.4 |x| | | | |
- - Receiver Option to require checksum           |4.1.3.4 | | |x| | |
-                                                 |        | | | | | |
-UDP Multihoming                                  |        | | | | | |
- - Pass spec-dest addr to application            |4.1.3.5 |x| | | | |
-
-
-
-Internet Engineering Task Force                                [Page 80]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- UDP             October 1989
-
-
- - Applic layer can specify Local IP addr        |4.1.3.5 |x| | | | |
- - Applic layer specify wild Local IP addr       |4.1.3.5 |x| | | | |
- - Applic layer notified of Local IP addr used   |4.1.3.5 | |x| | | |
-                                                 |        | | | | | |
-Bad IP src addr silently discarded by UDP/IP     |4.1.3.6 |x| | | | |
-Only send valid IP source address                |4.1.3.6 |x| | | | |
-UDP Application Interface Services               |        | | | | | |
-Full IP interface of 3.4 for application         |4.1.4   |x| | | | |
- - Able to spec TTL, TOS, IP opts when send dg   |4.1.4   |x| | | | |
- - Pass received TOS up to applic layer          |4.1.4   | | |x| | |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 81]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-   4.2  TRANSMISSION CONTROL PROTOCOL -- TCP
-
-      4.2.1  INTRODUCTION
-
-         The Transmission Control Protocol TCP [TCP:1] is the primary
-         virtual-circuit transport protocol for the Internet suite.  TCP
-         provides reliable, in-sequence delivery of a full-duplex stream
-         of octets (8-bit bytes).  TCP is used by those applications
-         needing reliable, connection-oriented transport service, e.g.,
-         mail (SMTP), file transfer (FTP), and virtual terminal service
-         (Telnet); requirements for these application-layer protocols
-         are described in [INTRO:1].
-
-      4.2.2  PROTOCOL WALK-THROUGH
-
-         4.2.2.1  Well-Known Ports: RFC-793 Section 2.7
-
-            DISCUSSION:
-                 TCP reserves port numbers in the range 0-255 for
-                 "well-known" ports, used to access services that are
-                 standardized across the Internet.  The remainder of the
-                 port space can be freely allocated to application
-                 processes.  Current well-known port definitions are
-                 listed in the RFC entitled "Assigned Numbers"
-                 [INTRO:6].  A prerequisite for defining a new well-
-                 known port is an RFC documenting the proposed service
-                 in enough detail to allow new implementations.
-
-                 Some systems extend this notion by adding a third
-                 subdivision of the TCP port space: reserved ports,
-                 which are generally used for operating-system-specific
-                 services.  For example, reserved ports might fall
-                 between 256 and some system-dependent upper limit.
-                 Some systems further choose to protect well-known and
-                 reserved ports by permitting only privileged users to
-                 open TCP connections with those port values.  This is
-                 perfectly reasonable as long as the host does not
-                 assume that all hosts protect their low-numbered ports
-                 in this manner.
-
-         4.2.2.2  Use of Push: RFC-793 Section 2.8
-
-            When an application issues a series of SEND calls without
-            setting the PUSH flag, the TCP MAY aggregate the data
-            internally without sending it.  Similarly, when a series of
-            segments is received without the PSH bit, a TCP MAY queue
-            the data internally without passing it to the receiving
-            application.
-
-
-
-Internet Engineering Task Force                                [Page 82]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-            The PSH bit is not a record marker and is independent of
-            segment boundaries.  The transmitter SHOULD collapse
-            successive PSH bits when it packetizes data, to send the
-            largest possible segment.
-
-            A TCP MAY implement PUSH flags on SEND calls.  If PUSH flags
-            are not implemented, then the sending TCP: (1) must not
-            buffer data indefinitely, and (2) MUST set the PSH bit in
-            the last buffered segment (i.e., when there is no more
-            queued data to be sent).
-
-            The discussion in RFC-793 on pages 48, 50, and 74
-            erroneously implies that a received PSH flag must be passed
-            to the application layer.  Passing a received PSH flag to
-            the application layer is now OPTIONAL.
-
-            An application program is logically required to set the PUSH
-            flag in a SEND call whenever it needs to force delivery of
-            the data to avoid a communication deadlock.  However, a TCP
-            SHOULD send a maximum-sized segment whenever possible, to
-            improve performance (see Section 4.2.3.4).
-
-            DISCUSSION:
-                 When the PUSH flag is not implemented on SEND calls,
-                 i.e., when the application/TCP interface uses a pure
-                 streaming model, responsibility for aggregating any
-                 tiny data fragments to form reasonable sized segments
-                 is partially borne by the application layer.
-
-                 Generally, an interactive application protocol must set
-                 the PUSH flag at least in the last SEND call in each
-                 command or response sequence.  A bulk transfer protocol
-                 like FTP should set the PUSH flag on the last segment
-                 of a file or when necessary to prevent buffer deadlock.
-
-                 At the receiver, the PSH bit forces buffered data to be
-                 delivered to the application (even if less than a full
-                 buffer has been received). Conversely, the lack of a
-                 PSH bit can be used to avoid unnecessary wakeup calls
-                 to the application process; this can be an important
-                 performance optimization for large timesharing hosts.
-                 Passing the PSH bit to the receiving application allows
-                 an analogous optimization within the application.
-
-         4.2.2.3  Window Size: RFC-793 Section 3.1
-
-            The window size MUST be treated as an unsigned number, or
-            else large window sizes will appear like negative windows
-
-
-
-Internet Engineering Task Force                                [Page 83]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-            and TCP will not work.  It is RECOMMENDED that
-            implementations reserve 32-bit fields for the send and
-            receive window sizes in the connection record and do all
-            window computations with 32 bits.
-
-            DISCUSSION:
-                 It is known that the window field in the TCP header is
-                 too small for high-speed, long-delay paths.
-                 Experimental TCP options have been defined to extend
-                 the window size; see for example [TCP:11].  In
-                 anticipation of the adoption of such an extension, TCP
-                 implementors should treat windows as 32 bits.
-
-         4.2.2.4  Urgent Pointer: RFC-793 Section 3.1
-
-            The second sentence is in error: the urgent pointer points
-            to the sequence number of the LAST octet (not LAST+1) in a
-            sequence of urgent data.  The description on page 56 (last
-            sentence) is correct.
-
-            A TCP MUST support a sequence of urgent data of any length.
-
-            A TCP MUST inform the application layer asynchronously
-            whenever it receives an Urgent pointer and there was
-            previously no pending urgent data, or whenever the Urgent
-            pointer advances in the data stream.  There MUST be a way
-            for the application to learn how much urgent data remains to
-            be read from the connection, or at least to determine
-            whether or not more urgent data remains to be read.
-
-            DISCUSSION:
-                 Although the Urgent mechanism may be used for any
-                 application, it is normally used to send "interrupt"-
-                 type commands to a Telnet program (see "Using Telnet
-                 Synch Sequence" section in [INTRO:1]).
-
-                 The asynchronous or "out-of-band" notification will
-                 allow the application to go into "urgent mode", reading
-                 data from the TCP connection.  This allows control
-                 commands to be sent to an application whose normal
-                 input buffers are full of unprocessed data.
-
-            IMPLEMENTATION:
-                 The generic ERROR-REPORT() upcall described in Section
-                 4.2.4.1 is a possible mechanism for informing the
-                 application of the arrival of urgent data.
-
-
-
-
-
-Internet Engineering Task Force                                [Page 84]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-         4.2.2.5  TCP Options: RFC-793 Section 3.1
-
-            A TCP MUST be able to receive a TCP option in any segment.
-            A TCP MUST ignore without error any TCP option it does not
-            implement, assuming that the option has a length field (all
-            TCP options defined in the future will have length fields).
-            TCP MUST be prepared to handle an illegal option length
-            (e.g., zero) without crashing; a suggested procedure is to
-            reset the connection and log the reason.
-
-         4.2.2.6  Maximum Segment Size Option: RFC-793 Section 3.1
-
-            TCP MUST implement both sending and receiving the Maximum
-            Segment Size option [TCP:4].
-
-            TCP SHOULD send an MSS (Maximum Segment Size) option in
-            every SYN segment when its receive MSS differs from the
-            default 536, and MAY send it always.
-
-            If an MSS option is not received at connection setup, TCP
-            MUST assume a default send MSS of 536 (576-40) [TCP:4].
-
-            The maximum size of a segment that TCP really sends, the
-            "effective send MSS," MUST be the smaller of the send MSS
-            (which reflects the available reassembly buffer size at the
-            remote host) and the largest size permitted by the IP layer:
-
-               Eff.snd.MSS =
-
-                  min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize
-
-            where:
-
-            *    SendMSS is the MSS value received from the remote host,
-                 or the default 536 if no MSS option is received.
-
-            *    MMS_S is the maximum size for a transport-layer message
-                 that TCP may send.
-
-            *    TCPhdrsize is the size of the TCP header; this is
-                 normally 20, but may be larger if TCP options are to be
-                 sent.
-
-            *    IPoptionsize is the size of any IP options that TCP
-                 will pass to the IP layer with the current message.
-
-
-            The MSS value to be sent in an MSS option must be less than
-
-
-
-Internet Engineering Task Force                                [Page 85]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-            or equal to:
-
-               MMS_R - 20
-
-            where MMS_R is the maximum size for a transport-layer
-            message that can be received (and reassembled).  TCP obtains
-            MMS_R and MMS_S from the IP layer; see the generic call
-            GET_MAXSIZES in Section 3.4.
-
-            DISCUSSION:
-                 The choice of TCP segment size has a strong effect on
-                 performance.  Larger segments increase throughput by
-                 amortizing header size and per-datagram processing
-                 overhead over more data bytes; however, if the packet
-                 is so large that it causes IP fragmentation, efficiency
-                 drops sharply if any fragments are lost [IP:9].
-
-                 Some TCP implementations send an MSS option only if the
-                 destination host is on a non-connected network.
-                 However, in general the TCP layer may not have the
-                 appropriate information to make this decision, so it is
-                 preferable to leave to the IP layer the task of
-                 determining a suitable MTU for the Internet path.  We
-                 therefore recommend that TCP always send the option (if
-                 not 536) and that the IP layer determine MMS_R as
-                 specified in 3.3.3 and 3.4.  A proposed IP-layer
-                 mechanism to measure the MTU would then modify the IP
-                 layer without changing TCP.
-
-         4.2.2.7  TCP Checksum: RFC-793 Section 3.1
-
-            Unlike the UDP checksum (see Section 4.1.3.4), the TCP
-            checksum is never optional.  The sender MUST generate it and
-            the receiver MUST check it.
-
-         4.2.2.8  TCP Connection State Diagram: RFC-793 Section 3.2,
-            page 23
-
-            There are several problems with this diagram:
-
-            (a)  The arrow from SYN-SENT to SYN-RCVD should be labeled
-                 with "snd SYN,ACK", to agree with the text on page 68
-                 and with Figure 8.
-
-            (b)  There could be an arrow from SYN-RCVD state to LISTEN
-                 state, conditioned on receiving a RST after a passive
-                 open (see text page 70).
-
-
-
-
-Internet Engineering Task Force                                [Page 86]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-            (c)  It is possible to go directly from FIN-WAIT-1 to the
-                 TIME-WAIT state (see page 75 of the spec).
-
-
-         4.2.2.9  Initial Sequence Number Selection: RFC-793 Section
-            3.3, page 27
-
-            A TCP MUST use the specified clock-driven selection of
-            initial sequence numbers.
-
-         4.2.2.10  Simultaneous Open Attempts: RFC-793 Section 3.4, page
-            32
-
-            There is an error in Figure 8: the packet on line 7 should
-            be identical to the packet on line 5.
-
-            A TCP MUST support simultaneous open attempts.
-
-            DISCUSSION:
-                 It sometimes surprises implementors that if two
-                 applications attempt to simultaneously connect to each
-                 other, only one connection is generated instead of two.
-                 This was an intentional design decision; don't try to
-                 "fix" it.
-
-         4.2.2.11  Recovery from Old Duplicate SYN: RFC-793 Section 3.4,
-            page 33
-
-            Note that a TCP implementation MUST keep track of whether a
-            connection has reached SYN_RCVD state as the result of a
-            passive OPEN or an active OPEN.
-
-         4.2.2.12  RST Segment: RFC-793 Section 3.4
-
-            A TCP SHOULD allow a received RST segment to include data.
-
-            DISCUSSION
-                 It has been suggested that a RST segment could contain
-                 ASCII text that encoded and explained the cause of the
-                 RST.  No standard has yet been established for such
-                 data.
-
-         4.2.2.13  Closing a Connection: RFC-793 Section 3.5
-
-            A TCP connection may terminate in two ways: (1) the normal
-            TCP close sequence using a FIN handshake, and (2) an "abort"
-            in which one or more RST segments are sent and the
-            connection state is immediately discarded.  If a TCP
-
-
-
-Internet Engineering Task Force                                [Page 87]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-            connection is closed by the remote site, the local
-            application MUST be informed whether it closed normally or
-            was aborted.
-
-            The normal TCP close sequence delivers buffered data
-            reliably in both directions.  Since the two directions of a
-            TCP connection are closed independently, it is possible for
-            a connection to be "half closed," i.e., closed in only one
-            direction, and a host is permitted to continue sending data
-            in the open direction on a half-closed connection.
-
-            A host MAY implement a "half-duplex" TCP close sequence, so
-            that an application that has called CLOSE cannot continue to
-            read data from the connection.  If such a host issues a
-            CLOSE call while received data is still pending in TCP, or
-            if new data is received after CLOSE is called, its TCP
-            SHOULD send a RST to show that data was lost.
-
-            When a connection is closed actively, it MUST linger in
-            TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime).
-            However, it MAY accept a new SYN from the remote TCP to
-            reopen the connection directly from TIME-WAIT state, if it:
-
-            (1)  assigns its initial sequence number for the new
-                 connection to be larger than the largest sequence
-                 number it used on the previous connection incarnation,
-                 and
-
-            (2)  returns to TIME-WAIT state if the SYN turns out to be
-                 an old duplicate.
-
-
-            DISCUSSION:
-                 TCP's full-duplex data-preserving close is a feature
-                 that is not included in the analogous ISO transport
-                 protocol TP4.
-
-                 Some systems have not implemented half-closed
-                 connections, presumably because they do not fit into
-                 the I/O model of their particular operating system.  On
-                 these systems, once an application has called CLOSE, it
-                 can no longer read input data from the connection; this
-                 is referred to as a "half-duplex" TCP close sequence.
-
-                 The graceful close algorithm of TCP requires that the
-                 connection state remain defined on (at least)  one end
-                 of the connection, for a timeout period of 2xMSL, i.e.,
-                 4 minutes.  During this period, the (remote socket,
-
-
-
-Internet Engineering Task Force                                [Page 88]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 local socket) pair that defines the connection is busy
-                 and cannot be reused.  To shorten the time that a given
-                 port pair is tied up, some TCPs allow a new SYN to be
-                 accepted in TIME-WAIT state.
-
-         4.2.2.14  Data Communication: RFC-793 Section 3.7, page 40
-
-            Since RFC-793 was written, there has been extensive work on
-            TCP algorithms to achieve efficient data communication.
-            Later sections of the present document describe required and
-            recommended TCP algorithms to determine when to send data
-            (Section 4.2.3.4), when to send an acknowledgment (Section
-            4.2.3.2), and when to update the window (Section 4.2.3.3).
-
-            DISCUSSION:
-                 One important performance issue is "Silly Window
-                 Syndrome" or "SWS" [TCP:5], a stable pattern of small
-                 incremental window movements resulting in extremely
-                 poor TCP performance.  Algorithms to avoid SWS are
-                 described below for both the sending side (Section
-                 4.2.3.4) and the receiving side (Section 4.2.3.3).
-
-                 In brief, SWS is caused by the receiver advancing the
-                 right window edge whenever it has any new buffer space
-                 available to receive data and by the sender using any
-                 incremental window, no matter how small, to send more
-                 data [TCP:5].  The result can be a stable pattern of
-                 sending tiny data segments, even though both sender and
-                 receiver have a large total buffer space for the
-                 connection.  SWS can only occur during the transmission
-                 of a large amount of data; if the connection goes
-                 quiescent, the problem will disappear.  It is caused by
-                 typical straightforward implementation of window
-                 management, but the sender and receiver algorithms
-                 given below will avoid it.
-
-                 Another important TCP performance issue is that some
-                 applications, especially remote login to character-at-
-                 a-time hosts, tend to send streams of one-octet data
-                 segments.  To avoid deadlocks, every TCP SEND call from
-                 such applications must be "pushed", either explicitly
-                 by the application or else implicitly by TCP.  The
-                 result may be a stream of TCP segments that contain one
-                 data octet each, which makes very inefficient use of
-                 the Internet and contributes to Internet congestion.
-                 The Nagle Algorithm described in Section 4.2.3.4
-                 provides a simple and effective solution to this
-                 problem.  It does have the effect of clumping
-
-
-
-Internet Engineering Task Force                                [Page 89]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 characters over Telnet connections; this may initially
-                 surprise users accustomed to single-character echo, but
-                 user acceptance has not been a problem.
-
-                 Note that the Nagle algorithm and the send SWS
-                 avoidance algorithm play complementary roles in
-                 improving performance.  The Nagle algorithm discourages
-                 sending tiny segments when the data to be sent
-                 increases in small increments, while the SWS avoidance
-                 algorithm discourages small segments resulting from the
-                 right window edge advancing in small increments.
-
-                 A careless implementation can send two or more
-                 acknowledgment segments per data segment received.  For
-                 example, suppose the receiver acknowledges every data
-                 segment immediately.  When the application program
-                 subsequently consumes the data and increases the
-                 available receive buffer space again, the receiver may
-                 send a second acknowledgment segment to update the
-                 window at the sender.  The extreme case occurs with
-                 single-character segments on TCP connections using the
-                 Telnet protocol for remote login service.  Some
-                 implementations have been observed in which each
-                 incoming 1-character segment generates three return
-                 segments: (1) the acknowledgment, (2) a one byte
-                 increase in the window, and (3) the echoed character,
-                 respectively.
-
-         4.2.2.15  Retransmission Timeout: RFC-793 Section 3.7, page 41
-
-            The algorithm suggested in RFC-793 for calculating the
-            retransmission timeout is now known to be inadequate; see
-            Section 4.2.3.1 below.
-
-            Recent work by Jacobson [TCP:7] on Internet congestion and
-            TCP retransmission stability has produced a transmission
-            algorithm combining "slow start" with "congestion
-            avoidance".  A TCP MUST implement this algorithm.
-
-            If a retransmitted packet is identical to the original
-            packet (which implies not only that the data boundaries have
-            not changed, but also that the window and acknowledgment
-            fields of the header have not changed), then the same IP
-            Identification field MAY be used (see Section 3.2.1.5).
-
-            IMPLEMENTATION:
-                 Some TCP implementors have chosen to "packetize" the
-                 data stream, i.e., to pick segment boundaries when
-
-
-
-Internet Engineering Task Force                                [Page 90]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 segments are originally sent and to queue these
-                 segments in a "retransmission queue" until they are
-                 acknowledged.  Another design (which may be simpler) is
-                 to defer packetizing until each time data is
-                 transmitted or retransmitted, so there will be no
-                 segment retransmission queue.
-
-                 In an implementation with a segment retransmission
-                 queue, TCP performance may be enhanced by repacketizing
-                 the segments awaiting acknowledgment when the first
-                 retransmission timeout occurs.  That is, the
-                 outstanding segments that fitted would be combined into
-                 one maximum-sized segment, with a new IP Identification
-                 value.  The TCP would then retain this combined segment
-                 in the retransmit queue until it was acknowledged.
-                 However, if the first two segments in the
-                 retransmission queue totalled more than one maximum-
-                 sized segment, the TCP would retransmit only the first
-                 segment using the original IP Identification field.
-
-         4.2.2.16  Managing the Window: RFC-793 Section 3.7, page 41
-
-            A TCP receiver SHOULD NOT shrink the window, i.e., move the
-            right window edge to the left.  However, a sending TCP MUST
-            be robust against window shrinking, which may cause the
-            "useable window" (see Section 4.2.3.4) to become negative.
-
-            If this happens, the sender SHOULD NOT send new data, but
-            SHOULD retransmit normally the old unacknowledged data
-            between SND.UNA and SND.UNA+SND.WND.  The sender MAY also
-            retransmit old data beyond SND.UNA+SND.WND, but SHOULD NOT
-            time out the connection if data beyond the right window edge
-            is not acknowledged.  If the window shrinks to zero, the TCP
-            MUST probe it in the standard way (see next Section).
-
-            DISCUSSION:
-                 Many TCP implementations become confused if the window
-                 shrinks from the right after data has been sent into a
-                 larger window.  Note that TCP has a heuristic to select
-                 the latest window update despite possible datagram
-                 reordering; as a result, it may ignore a window update
-                 with a smaller window than previously offered if
-                 neither the sequence number nor the acknowledgment
-                 number is increased.
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 91]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-         4.2.2.17  Probing Zero Windows: RFC-793 Section 3.7, page 42
-
-            Probing of zero (offered) windows MUST be supported.
-
-            A TCP MAY keep its offered receive window closed
-            indefinitely.  As long as the receiving TCP continues to
-            send acknowledgments in response to the probe segments, the
-            sending TCP MUST allow the connection to stay open.
-
-            DISCUSSION:
-                 It is extremely important to remember that ACK
-                 (acknowledgment) segments that contain no data are not
-                 reliably transmitted by TCP.  If zero window probing is
-                 not supported, a connection may hang forever when an
-                 ACK segment that re-opens the window is lost.
-
-                 The delay in opening a zero window generally occurs
-                 when the receiving application stops taking data from
-                 its TCP.  For example, consider a printer daemon
-                 application, stopped because the printer ran out of
-                 paper.
-
-            The transmitting host SHOULD send the first zero-window
-            probe when a zero window has existed for the retransmission
-            timeout period (see Section 4.2.2.15), and SHOULD increase
-            exponentially the interval between successive probes.
-
-            DISCUSSION:
-                 This procedure minimizes delay if the zero-window
-                 condition is due to a lost ACK segment containing a
-                 window-opening update.  Exponential backoff is
-                 recommended, possibly with some maximum interval not
-                 specified here.  This procedure is similar to that of
-                 the retransmission algorithm, and it may be possible to
-                 combine the two procedures in the implementation.
-
-         4.2.2.18  Passive OPEN Calls:  RFC-793 Section 3.8
-
-            Every passive OPEN call either creates a new connection
-            record in LISTEN state, or it returns an error; it MUST NOT
-            affect any previously created connection record.
-
-            A TCP that supports multiple concurrent users MUST provide
-            an OPEN call that will functionally allow an application to
-            LISTEN on a port while a connection block with the same
-            local port is in SYN-SENT or SYN-RECEIVED state.
-
-            DISCUSSION:
-
-
-
-Internet Engineering Task Force                                [Page 92]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 Some applications (e.g., SMTP servers) may need to
-                 handle multiple connection attempts at about the same
-                 time.  The probability of a connection attempt failing
-                 is reduced by giving the application some means of
-                 listening for a new connection at the same time that an
-                 earlier connection attempt is going through the three-
-                 way handshake.
-
-            IMPLEMENTATION:
-                 Acceptable implementations of concurrent opens may
-                 permit multiple passive OPEN calls, or they may allow
-                 "cloning" of LISTEN-state connections from a single
-                 passive OPEN call.
-
-         4.2.2.19  Time to Live: RFC-793 Section 3.9, page 52
-
-            RFC-793 specified that TCP was to request the IP layer to
-            send TCP segments with TTL = 60.  This is obsolete; the TTL
-            value used to send TCP segments MUST be configurable.  See
-            Section 3.2.1.7 for discussion.
-
-         4.2.2.20  Event Processing: RFC-793 Section 3.9
-
-            While it is not strictly required, a TCP SHOULD be capable
-            of queueing out-of-order TCP segments.  Change the "may" in
-            the last sentence of the first paragraph on page 70 to
-            "should".
-
-            DISCUSSION:
-                 Some small-host implementations have omitted segment
-                 queueing because of limited buffer space.  This
-                 omission may be expected to adversely affect TCP
-                 throughput, since loss of a single segment causes all
-                 later segments to appear to be "out of sequence".
-
-            In general, the processing of received segments MUST be
-            implemented to aggregate ACK segments whenever possible.
-            For example, if the TCP is processing a series of queued
-            segments, it MUST process them all before sending any ACK
-            segments.
-
-            Here are some detailed error corrections and notes on the
-            Event Processing section of RFC-793.
-
-            (a)  CLOSE Call, CLOSE-WAIT state, p. 61: enter LAST-ACK
-                 state, not CLOSING.
-
-            (b)  LISTEN state, check for SYN (pp. 65, 66): With a SYN
-
-
-
-Internet Engineering Task Force                                [Page 93]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 bit, if the security/compartment or the precedence is
-                 wrong for the segment, a reset is sent.  The wrong form
-                 of reset is shown in the text; it should be:
-
-                   <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
-
-
-            (c)  SYN-SENT state, Check for SYN, p. 68: When the
-                 connection enters ESTABLISHED state, the following
-                 variables must be set:
-                    SND.WND <- SEG.WND
-                    SND.WL1 <- SEG.SEQ
-                    SND.WL2 <- SEG.ACK
-
-
-            (d)  Check security and precedence, p. 71: The first heading
-                 "ESTABLISHED STATE" should really be a list of all
-                 states other than SYN-RECEIVED: ESTABLISHED, FIN-WAIT-
-                 1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, and
-                 TIME-WAIT.
-
-            (e)  Check SYN bit, p. 71:  "In SYN-RECEIVED state and if
-                 the connection was initiated with a passive OPEN, then
-                 return this connection to the LISTEN state and return.
-                 Otherwise...".
-
-            (f)  Check ACK field, SYN-RECEIVED state, p. 72: When the
-                 connection enters ESTABLISHED state, the variables
-                 listed in (c) must be set.
-
-            (g)  Check ACK field, ESTABLISHED state, p. 72: The ACK is a
-                 duplicate if SEG.ACK =< SND.UNA (the = was omitted).
-                 Similarly, the window should be updated if: SND.UNA =<
-                 SEG.ACK =< SND.NXT.
-
-            (h)  USER TIMEOUT, p. 77:
-
-                 It would be better to notify the application of the
-                 timeout rather than letting TCP force the connection
-                 closed.  However, see also Section 4.2.3.5.
-
-
-         4.2.2.21  Acknowledging Queued Segments: RFC-793 Section 3.9
-
-            A TCP MAY send an ACK segment acknowledging RCV.NXT when a
-            valid segment arrives that is in the window but not at the
-            left window edge.
-
-
-
-
-Internet Engineering Task Force                                [Page 94]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-            DISCUSSION:
-                 RFC-793 (see page 74) was ambiguous about whether or
-                 not an ACK segment should be sent when an out-of-order
-                 segment was received, i.e., when SEG.SEQ was unequal to
-                 RCV.NXT.
-
-                 One reason for ACKing out-of-order segments might be to
-                 support an experimental algorithm known as "fast
-                 retransmit".   With this algorithm, the sender uses the
-                 "redundant" ACK's to deduce that a segment has been
-                 lost before the retransmission timer has expired.  It
-                 counts the number of times an ACK has been received
-                 with the same value of SEG.ACK and with the same right
-                 window edge.  If more than a threshold number of such
-                 ACK's is received, then the segment containing the
-                 octets starting at SEG.ACK is assumed to have been lost
-                 and is retransmitted, without awaiting a timeout.  The
-                 threshold is chosen to compensate for the maximum
-                 likely segment reordering in the Internet.  There is
-                 not yet enough experience with the fast retransmit
-                 algorithm to determine how useful it is.
-
-      4.2.3  SPECIFIC ISSUES
-
-         4.2.3.1  Retransmission Timeout Calculation
-
-            A host TCP MUST implement Karn's algorithm and Jacobson's
-            algorithm for computing the retransmission timeout ("RTO").
-
-            o    Jacobson's algorithm for computing the smoothed round-
-                 trip ("RTT") time incorporates a simple measure of the
-                 variance [TCP:7].
-
-            o    Karn's algorithm for selecting RTT measurements ensures
-                 that ambiguous round-trip times will not corrupt the
-                 calculation of the smoothed round-trip time [TCP:6].
-
-            This implementation also MUST include "exponential backoff"
-            for successive RTO values for the same segment.
-            Retransmission of SYN segments SHOULD use the same algorithm
-            as data segments.
-
-            DISCUSSION:
-                 There were two known problems with the RTO calculations
-                 specified in RFC-793.  First, the accurate measurement
-                 of RTTs is difficult when there are retransmissions.
-                 Second, the algorithm to compute the smoothed round-
-                 trip time is inadequate [TCP:7], because it incorrectly
-
-
-
-Internet Engineering Task Force                                [Page 95]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 assumed that the variance in RTT values would be small
-                 and constant.  These problems were solved by Karn's and
-                 Jacobson's algorithm, respectively.
-
-                 The performance increase resulting from the use of
-                 these improvements varies from noticeable to dramatic.
-                 Jacobson's algorithm for incorporating the measured RTT
-                 variance is especially important on a low-speed link,
-                 where the natural variation of packet sizes causes a
-                 large variation in RTT.  One vendor found link
-                 utilization on a 9.6kb line went from 10% to 90% as a
-                 result of implementing Jacobson's variance algorithm in
-                 TCP.
-
-            The following values SHOULD be used to initialize the
-            estimation parameters for a new connection:
-
-            (a)  RTT = 0 seconds.
-
-            (b)  RTO = 3 seconds.  (The smoothed variance is to be
-                 initialized to the value that will result in this RTO).
-
-            The recommended upper and lower bounds on the RTO are known
-            to be inadequate on large internets.  The lower bound SHOULD
-            be measured in fractions of a second (to accommodate high
-            speed LANs) and the upper bound should be 2*MSL, i.e., 240
-            seconds.
-
-            DISCUSSION:
-                 Experience has shown that these initialization values
-                 are reasonable, and that in any case the Karn and
-                 Jacobson algorithms make TCP behavior reasonably
-                 insensitive to the initial parameter choices.
-
-         4.2.3.2  When to Send an ACK Segment
-
-            A host that is receiving a stream of TCP data segments can
-            increase efficiency in both the Internet and the hosts by
-            sending fewer than one ACK (acknowledgment) segment per data
-            segment received; this is known as a "delayed ACK" [TCP:5].
-
-            A TCP SHOULD implement a delayed ACK, but an ACK should not
-            be excessively delayed; in particular, the delay MUST be
-            less than 0.5 seconds, and in a stream of full-sized
-            segments there SHOULD be an ACK for at least every second
-            segment.
-
-            DISCUSSION:
-
-
-
-Internet Engineering Task Force                                [Page 96]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 A delayed ACK gives the application an opportunity to
-                 update the window and perhaps to send an immediate
-                 response.  In particular, in the case of character-mode
-                 remote login, a delayed ACK can reduce the number of
-                 segments sent by the server by a factor of 3 (ACK,
-                 window update, and echo character all combined in one
-                 segment).
-
-                 In addition, on some large multi-user hosts, a delayed
-                 ACK can substantially reduce protocol processing
-                 overhead by reducing the total number of packets to be
-                 processed [TCP:5].  However, excessive delays on ACK's
-                 can disturb the round-trip timing and packet "clocking"
-                 algorithms [TCP:7].
-
-         4.2.3.3  When to Send a Window Update
-
-            A TCP MUST include a SWS avoidance algorithm in the receiver
-            [TCP:5].
-
-            IMPLEMENTATION:
-                 The receiver's SWS avoidance algorithm determines when
-                 the right window edge may be advanced; this is
-                 customarily known as "updating the window".  This
-                 algorithm combines with the delayed ACK algorithm (see
-                 Section 4.2.3.2) to determine when an ACK segment
-                 containing the current window will really be sent to
-                 the receiver.  We use the notation of RFC-793; see
-                 Figures 4 and 5 in that document.
-
-                 The solution to receiver SWS is to avoid advancing the
-                 right window edge RCV.NXT+RCV.WND in small increments,
-                 even if data is received from the network in small
-                 segments.
-
-                 Suppose the total receive buffer space is RCV.BUFF.  At
-                 any given moment, RCV.USER octets of this total may be
-                 tied up with data that has been received and
-                 acknowledged but which the user process has not yet
-                 consumed.  When the connection is quiescent, RCV.WND =
-                 RCV.BUFF and RCV.USER = 0.
-
-                 Keeping the right window edge fixed as data arrives and
-                 is acknowledged requires that the receiver offer less
-                 than its full buffer space, i.e., the receiver must
-                 specify a RCV.WND that keeps RCV.NXT+RCV.WND constant
-                 as RCV.NXT increases.  Thus, the total buffer space
-                 RCV.BUFF is generally divided into three parts:
-
-
-
-Internet Engineering Task Force                                [Page 97]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-
-                 |<------- RCV.BUFF ---------------->|
-                      1             2            3
-             ----|---------|------------------|------|----
-                        RCV.NXT               ^
-                                           (Fixed)
-
-             1 - RCV.USER =  data received but not yet consumed;
-             2 - RCV.WND =   space advertised to sender;
-             3 - Reduction = space available but not yet
-                             advertised.
-
-
-                 The suggested SWS avoidance algorithm for the receiver
-                 is to keep RCV.NXT+RCV.WND fixed until the reduction
-                 satisfies:
-
-                      RCV.BUFF - RCV.USER - RCV.WND  >=
-
-                             min( Fr * RCV.BUFF, Eff.snd.MSS )
-
-                 where Fr is a fraction whose recommended value is 1/2,
-                 and Eff.snd.MSS is the effective send MSS for the
-                 connection (see Section 4.2.2.6).  When the inequality
-                 is satisfied, RCV.WND is set to RCV.BUFF-RCV.USER.
-
-                 Note that the general effect of this algorithm is to
-                 advance RCV.WND in increments of Eff.snd.MSS (for
-                 realistic receive buffers:  Eff.snd.MSS < RCV.BUFF/2).
-                 Note also that the receiver must use its own
-                 Eff.snd.MSS, assuming it is the same as the sender's.
-
-         4.2.3.4  When to Send Data
-
-            A TCP MUST include a SWS avoidance algorithm in the sender.
-
-            A TCP SHOULD implement the Nagle Algorithm [TCP:9] to
-            coalesce short segments.  However, there MUST be a way for
-            an application to disable the Nagle algorithm on an
-            individual connection.  In all cases, sending data is also
-            subject to the limitation imposed by the Slow Start
-            algorithm (Section 4.2.2.15).
-
-            DISCUSSION:
-                 The Nagle algorithm is generally as follows:
-
-                      If there is unacknowledged data (i.e., SND.NXT >
-                      SND.UNA), then the sending TCP buffers all user
-
-
-
-Internet Engineering Task Force                                [Page 98]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                      data (regardless of the PSH bit), until the
-                      outstanding data has been acknowledged or until
-                      the TCP can send a full-sized segment (Eff.snd.MSS
-                      bytes; see Section 4.2.2.6).
-
-                 Some applications (e.g., real-time display window
-                 updates) require that the Nagle algorithm be turned
-                 off, so small data segments can be streamed out at the
-                 maximum rate.
-
-            IMPLEMENTATION:
-                 The sender's SWS avoidance algorithm is more difficult
-                 than the receivers's, because the sender does not know
-                 (directly) the receiver's total buffer space RCV.BUFF.
-                 An approach which has been found to work well is for
-                 the sender to calculate Max(SND.WND), the maximum send
-                 window it has seen so far on the connection, and to use
-                 this value as an estimate of RCV.BUFF.  Unfortunately,
-                 this can only be an estimate; the receiver may at any
-                 time reduce the size of RCV.BUFF.  To avoid a resulting
-                 deadlock, it is necessary to have a timeout to force
-                 transmission of data, overriding the SWS avoidance
-                 algorithm.  In practice, this timeout should seldom
-                 occur.
-
-                 The "useable window" [TCP:5] is:
-
-                      U = SND.UNA + SND.WND - SND.NXT
-
-                 i.e., the offered window less the amount of data sent
-                 but not acknowledged.  If D is the amount of data
-                 queued in the sending TCP but not yet sent, then the
-                 following set of rules is recommended.
-
-                 Send data:
-
-                 (1)  if a maximum-sized segment can be sent, i.e, if:
-
-                           min(D,U) >= Eff.snd.MSS;
-
-
-                 (2)  or if the data is pushed and all queued data can
-                      be sent now, i.e., if:
-
-                          [SND.NXT = SND.UNA and] PUSHED and D <= U
-
-                      (the bracketed condition is imposed by the Nagle
-                      algorithm);
-
-
-
-Internet Engineering Task Force                                [Page 99]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 (3)  or if at least a fraction Fs of the maximum window
-                      can be sent, i.e., if:
-
-                          [SND.NXT = SND.UNA and]
-
-                                  min(D.U) >= Fs * Max(SND.WND);
-
-
-                 (4)  or if data is PUSHed and the override timeout
-                      occurs.
-
-                 Here Fs is a fraction whose recommended value is 1/2.
-                 The override timeout should be in the range 0.1 - 1.0
-                 seconds.  It may be convenient to combine this timer
-                 with the timer used to probe zero windows (Section
-                 4.2.2.17).
-
-                 Finally, note that the SWS avoidance algorithm just
-                 specified is to be used instead of the sender-side
-                 algorithm contained in [TCP:5].
-
-         4.2.3.5  TCP Connection Failures
-
-            Excessive retransmission of the same segment by TCP
-            indicates some failure of the remote host or the Internet
-            path.  This failure may be of short or long duration.  The
-            following procedure MUST be used to handle excessive
-            retransmissions of data segments [IP:11]:
-
-            (a)  There are two thresholds R1 and R2 measuring the amount
-                 of retransmission that has occurred for the same
-                 segment.  R1 and R2 might be measured in time units or
-                 as a count of retransmissions.
-
-            (b)  When the number of transmissions of the same segment
-                 reaches or exceeds threshold R1, pass negative advice
-                 (see Section 3.3.1.4) to the IP layer, to trigger
-                 dead-gateway diagnosis.
-
-            (c)  When the number of transmissions of the same segment
-                 reaches a threshold R2 greater than R1, close the
-                 connection.
-
-            (d)  An application MUST be able to set the value for R2 for
-                 a particular connection.  For example, an interactive
-                 application might set R2 to "infinity," giving the user
-                 control over when to disconnect.
-
-
-
-
-Internet Engineering Task Force                               [Page 100]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-            (d)  TCP SHOULD inform the application of the delivery
-                 problem (unless such information has been disabled by
-                 the application; see Section 4.2.4.1), when R1 is
-                 reached and before R2.  This will allow a remote login
-                 (User Telnet) application program to inform the user,
-                 for example.
-
-            The value of R1 SHOULD correspond to at least 3
-            retransmissions, at the current RTO.  The value of R2 SHOULD
-            correspond to at least 100 seconds.
-
-            An attempt to open a TCP connection could fail with
-            excessive retransmissions of the SYN segment or by receipt
-            of a RST segment or an ICMP Port Unreachable.  SYN
-            retransmissions MUST be handled in the general way just
-            described for data retransmissions, including notification
-            of the application layer.
-
-            However, the values of R1 and R2 may be different for SYN
-            and data segments.  In particular, R2 for a SYN segment MUST
-            be set large enough to provide retransmission of the segment
-            for at least 3 minutes.  The application can close the
-            connection (i.e., give up on the open attempt) sooner, of
-            course.
-
-            DISCUSSION:
-                 Some Internet paths have significant setup times, and
-                 the number of such paths is likely to increase in the
-                 future.
-
-         4.2.3.6  TCP Keep-Alives
-
-            Implementors MAY include "keep-alives" in their TCP
-            implementations, although this practice is not universally
-            accepted.  If keep-alives are included, the application MUST
-            be able to turn them on or off for each TCP connection, and
-            they MUST default to off.
-
-            Keep-alive packets MUST only be sent when no data or
-            acknowledgement packets have been received for the
-            connection within an interval.  This interval MUST be
-            configurable and MUST default to no less than two hours.
-
-            It is extremely important to remember that ACK segments that
-            contain no data are not reliably transmitted by TCP.
-            Consequently, if a keep-alive mechanism is implemented it
-            MUST NOT interpret failure to respond to any specific probe
-            as a dead connection.
-
-
-
-Internet Engineering Task Force                               [Page 101]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-            An implementation SHOULD send a keep-alive segment with no
-            data; however, it MAY be configurable to send a keep-alive
-            segment containing one garbage octet, for compatibility with
-            erroneous TCP implementations.
-
-            DISCUSSION:
-                 A "keep-alive" mechanism periodically probes the other
-                 end of a connection when the connection is otherwise
-                 idle, even when there is no data to be sent.  The TCP
-                 specification does not include a keep-alive mechanism
-                 because it could:  (1) cause perfectly good connections
-                 to break during transient Internet failures; (2)
-                 consume unnecessary bandwidth ("if no one is using the
-                 connection, who cares if it is still good?"); and (3)
-                 cost money for an Internet path that charges for
-                 packets.
-
-                 Some TCP implementations, however, have included a
-                 keep-alive mechanism.  To confirm that an idle
-                 connection is still active, these implementations send
-                 a probe segment designed to elicit a response from the
-                 peer TCP.  Such a segment generally contains SEG.SEQ =
-                 SND.NXT-1 and may or may not contain one garbage octet
-                 of data.  Note that on a quiet connection SND.NXT =
-                 RCV.NXT, so that this SEG.SEQ will be outside the
-                 window.  Therefore, the probe causes the receiver to
-                 return an acknowledgment segment, confirming that the
-                 connection is still live.  If the peer has dropped the
-                 connection due to a network partition or a crash, it
-                 will respond with a RST instead of an acknowledgment
-                 segment.
-
-                 Unfortunately, some misbehaved TCP implementations fail
-                 to respond to a segment with SEG.SEQ = SND.NXT-1 unless
-                 the segment contains data.  Alternatively, an
-                 implementation could determine whether a peer responded
-                 correctly to keep-alive packets with no garbage data
-                 octet.
-
-                 A TCP keep-alive mechanism should only be invoked in
-                 server applications that might otherwise hang
-                 indefinitely and consume resources unnecessarily if a
-                 client crashes or aborts a connection during a network
-                 failure.
-
-
-
-
-
-
-
-Internet Engineering Task Force                               [Page 102]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-         4.2.3.7  TCP Multihoming
-
-            If an application on a multihomed host does not specify the
-            local IP address when actively opening a TCP connection,
-            then the TCP MUST ask the IP layer to select a local IP
-            address before sending the (first) SYN.  See the function
-            GET_SRCADDR() in Section 3.4.
-
-            At all other times, a previous segment has either been sent
-            or received on this connection, and TCP MUST use the same
-            local address is used that was used in those previous
-            segments.
-
-         4.2.3.8  IP Options
-
-            When received options are passed up to TCP from the IP
-            layer, TCP MUST ignore options that it does not understand.
-
-            A TCP MAY support the Time Stamp and Record Route options.
-
-            An application MUST be able to specify a source route when
-            it actively opens a TCP connection, and this MUST take
-            precedence over a source route received in a datagram.
-
-            When a TCP connection is OPENed passively and a packet
-            arrives with a completed IP Source Route option (containing
-            a return route), TCP MUST save the return route and use it
-            for all segments sent on this connection.  If a different
-            source route arrives in a later segment, the later
-            definition SHOULD override the earlier one.
-
-         4.2.3.9  ICMP Messages
-
-            TCP MUST act on an ICMP error message passed up from the IP
-            layer, directing it to the connection that created the
-            error.  The necessary demultiplexing information can be
-            found in the IP header contained within the ICMP message.
-
-            o    Source Quench
-
-                 TCP MUST react to a Source Quench by slowing
-                 transmission on the connection.  The RECOMMENDED
-                 procedure is for a Source Quench to trigger a "slow
-                 start," as if a retransmission timeout had occurred.
-
-            o    Destination Unreachable -- codes 0, 1, 5
-
-                 Since these Unreachable messages indicate soft error
-
-
-
-Internet Engineering Task Force                               [Page 103]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 conditions, TCP MUST NOT abort the connection, and it
-                 SHOULD make the information available to the
-                 application.
-
-                 DISCUSSION:
-                      TCP could report the soft error condition directly
-                      to the application layer with an upcall to the
-                      ERROR_REPORT routine, or it could merely note the
-                      message and report it to the application only when
-                      and if the TCP connection times out.
-
-            o    Destination Unreachable -- codes 2-4
-
-                 These are hard error conditions, so TCP SHOULD abort
-                 the connection.
-
-            o    Time Exceeded -- codes 0, 1
-
-                 This should be handled the same way as Destination
-                 Unreachable codes 0, 1, 5 (see above).
-
-            o    Parameter Problem
-
-                 This should be handled the same way as Destination
-                 Unreachable codes 0, 1, 5 (see above).
-
-
-         4.2.3.10  Remote Address Validation
-
-            A TCP implementation MUST reject as an error a local OPEN
-            call for an invalid remote IP address (e.g., a broadcast or
-            multicast address).
-
-            An incoming SYN with an invalid source address must be
-            ignored either by TCP or by the IP layer (see Section
-            3.2.1.3).
-
-            A TCP implementation MUST silently discard an incoming SYN
-            segment that is addressed to a broadcast or multicast
-            address.
-
-         4.2.3.11  TCP Traffic Patterns
-
-            IMPLEMENTATION:
-                 The TCP protocol specification [TCP:1] gives the
-                 implementor much freedom in designing the algorithms
-                 that control the message flow over the connection --
-                 packetizing, managing the window, sending
-
-
-
-Internet Engineering Task Force                               [Page 104]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                 acknowledgments, etc.  These design decisions are
-                 difficult because a TCP must adapt to a wide range of
-                 traffic patterns.  Experience has shown that a TCP
-                 implementor needs to verify the design on two extreme
-                 traffic patterns:
-
-                 o    Single-character Segments
-
-                      Even if the sender is using the Nagle Algorithm,
-                      when a TCP connection carries remote login traffic
-                      across a low-delay LAN the receiver will generally
-                      get a stream of single-character segments.  If
-                      remote terminal echo mode is in effect, the
-                      receiver's system will generally echo each
-                      character as it is received.
-
-                 o    Bulk Transfer
-
-                      When TCP is used for bulk transfer, the data
-                      stream should be made up (almost) entirely of
-                      segments of the size of the effective MSS.
-                      Although TCP uses a sequence number space with
-                      byte (octet) granularity, in bulk-transfer mode
-                      its operation should be as if TCP used a sequence
-                      space that counted only segments.
-
-                 Experience has furthermore shown that a single TCP can
-                 effectively and efficiently handle these two extremes.
-
-                 The most important tool for verifying a new TCP
-                 implementation is a packet trace program.  There is a
-                 large volume of experience showing the importance of
-                 tracing a variety of traffic patterns with other TCP
-                 implementations and studying the results carefully.
-
-
-         4.2.3.12  Efficiency
-
-            IMPLEMENTATION:
-                 Extensive experience has led to the following
-                 suggestions for efficient implementation of TCP:
-
-                 (a)  Don't Copy Data
-
-                      In bulk data transfer, the primary CPU-intensive
-                      tasks are copying data from one place to another
-                      and checksumming the data.  It is vital to
-                      minimize the number of copies of TCP data.  Since
-
-
-
-Internet Engineering Task Force                               [Page 105]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                      the ultimate speed limitation may be fetching data
-                      across the memory bus, it may be useful to combine
-                      the copy with checksumming, doing both with a
-                      single memory fetch.
-
-                 (b)  Hand-Craft the Checksum Routine
-
-                      A good TCP checksumming routine is typically two
-                      to five times faster than a simple and direct
-                      implementation of the definition.  Great care and
-                      clever coding are often required and advisable to
-                      make the checksumming code "blazing fast".  See
-                      [TCP:10].
-
-                 (c)  Code for the Common Case
-
-                      TCP protocol processing can be complicated, but
-                      for most segments there are only a few simple
-                      decisions to be made.  Per-segment processing will
-                      be greatly speeded up by coding the main line to
-                      minimize the number of decisions in the most
-                      common case.
-
-
-      4.2.4  TCP/APPLICATION LAYER INTERFACE
-
-         4.2.4.1  Asynchronous Reports
-
-            There MUST be a mechanism for reporting soft TCP error
-            conditions to the application.  Generically, we assume this
-            takes the form of an application-supplied ERROR_REPORT
-            routine that may be upcalled [INTRO:7] asynchronously from
-            the transport layer:
-
-               ERROR_REPORT(local connection name, reason, subreason)
-
-            The precise encoding of the reason and subreason parameters
-            is not specified here.  However, the conditions that are
-            reported asynchronously to the application MUST include:
-
-            *    ICMP error message arrived (see 4.2.3.9)
-
-            *    Excessive retransmissions (see 4.2.3.5)
-
-            *    Urgent pointer advance (see 4.2.2.4).
-
-            However, an application program that does not want to
-            receive such ERROR_REPORT calls SHOULD be able to
-
-
-
-Internet Engineering Task Force                               [Page 106]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-            effectively disable these calls.
-
-            DISCUSSION:
-                 These error reports generally reflect soft errors that
-                 can be ignored without harm by many applications.  It
-                 has been suggested that these error report calls should
-                 default to "disabled," but this is not required.
-
-         4.2.4.2  Type-of-Service
-
-            The application layer MUST be able to specify the Type-of-
-            Service (TOS) for segments that are sent on a connection.
-            It not required, but the application SHOULD be able to
-            change the TOS during the connection lifetime.  TCP SHOULD
-            pass the current TOS value without change to the IP layer,
-            when it sends segments on the connection.
-
-            The TOS will be specified independently in each direction on
-            the connection, so that the receiver application will
-            specify the TOS used for ACK segments.
-
-            TCP MAY pass the most recently received TOS up to the
-            application.
-
-            DISCUSSION
-                 Some applications (e.g., SMTP) change the nature of
-                 their communication during the lifetime of a
-                 connection, and therefore would like to change the TOS
-                 specification.
-
-                 Note also that the OPEN call specified in RFC-793
-                 includes a parameter ("options") in which the caller
-                 can specify IP options such as source route, record
-                 route, or timestamp.
-
-         4.2.4.3  Flush Call
-
-            Some TCP implementations have included a FLUSH call, which
-            will empty the TCP send queue of any data for which the user
-            has issued SEND calls but which is still to the right of the
-            current send window.  That is, it flushes as much queued
-            send data as possible without losing sequence number
-            synchronization.  This is useful for implementing the "abort
-            output" function of Telnet.
-
-
-
-
-
-
-
-Internet Engineering Task Force                               [Page 107]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-         4.2.4.4  Multihoming
-
-            The user interface outlined in sections 2.7 and 3.8 of RFC-
-            793 needs to be extended for multihoming.  The OPEN call
-            MUST have an optional parameter:
-
-                OPEN( ... [local IP address,] ... )
-
-            to allow the specification of the local IP address.
-
-            DISCUSSION:
-                 Some TCP-based applications need to specify the local
-                 IP address to be used to open a particular connection;
-                 FTP is an example.
-
-            IMPLEMENTATION:
-                 A passive OPEN call with a specified "local IP address"
-                 parameter will await an incoming connection request to
-                 that address.  If the parameter is unspecified, a
-                 passive OPEN will await an incoming connection request
-                 to any local IP address, and then bind the local IP
-                 address of the connection to the particular address
-                 that is used.
-
-                 For an active OPEN call, a specified "local IP address"
-                 parameter will be used for opening the connection.  If
-                 the parameter is unspecified, the networking software
-                 will choose an appropriate local IP address (see
-                 Section 3.3.4.2) for the connection
-
-      4.2.5  TCP REQUIREMENT SUMMARY
-
-                                                 |        | | | |S| |
-                                                 |        | | | |H| |F
-                                                 |        | | | |O|M|o
-                                                 |        | |S| |U|U|o
-                                                 |        | |H| |L|S|t
-                                                 |        |M|O| |D|T|n
-                                                 |        |U|U|M| | |o
-                                                 |        |S|L|A|N|N|t
-                                                 |        |T|D|Y|O|O|t
-FEATURE                                          |SECTION | | | |T|T|e
--------------------------------------------------|--------|-|-|-|-|-|--
-                                                 |        | | | | | |
-Push flag                                        |        | | | | | |
-  Aggregate or queue un-pushed data              |4.2.2.2 | | |x| | |
-  Sender collapse successive PSH flags           |4.2.2.2 | |x| | | |
-  SEND call can specify PUSH                     |4.2.2.2 | | |x| | |
-
-
-
-Internet Engineering Task Force                               [Page 108]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-    If cannot: sender buffer indefinitely        |4.2.2.2 | | | | |x|
-    If cannot: PSH last segment                  |4.2.2.2 |x| | | | |
-  Notify receiving ALP of PSH                    |4.2.2.2 | | |x| | |1
-  Send max size segment when possible            |4.2.2.2 | |x| | | |
-                                                 |        | | | | | |
-Window                                           |        | | | | | |
-  Treat as unsigned number                       |4.2.2.3 |x| | | | |
-  Handle as 32-bit number                        |4.2.2.3 | |x| | | |
-  Shrink window from right                       |4.2.2.16| | | |x| |
-  Robust against shrinking window                |4.2.2.16|x| | | | |
-  Receiver's window closed indefinitely          |4.2.2.17| | |x| | |
-  Sender probe zero window                       |4.2.2.17|x| | | | |
-    First probe after RTO                        |4.2.2.17| |x| | | |
-    Exponential backoff                          |4.2.2.17| |x| | | |
-  Allow window stay zero indefinitely            |4.2.2.17|x| | | | |
-  Sender timeout OK conn with zero wind          |4.2.2.17| | | | |x|
-                                                 |        | | | | | |
-Urgent Data                                      |        | | | | | |
-  Pointer points to last octet                   |4.2.2.4 |x| | | | |
-  Arbitrary length urgent data sequence          |4.2.2.4 |x| | | | |
-  Inform ALP asynchronously of urgent data       |4.2.2.4 |x| | | | |1
-  ALP can learn if/how much urgent data Q'd      |4.2.2.4 |x| | | | |1
-                                                 |        | | | | | |
-TCP Options                                      |        | | | | | |
-  Receive TCP option in any segment              |4.2.2.5 |x| | | | |
-  Ignore unsupported options                     |4.2.2.5 |x| | | | |
-  Cope with illegal option length                |4.2.2.5 |x| | | | |
-  Implement sending & receiving MSS option       |4.2.2.6 |x| | | | |
-  Send MSS option unless 536                     |4.2.2.6 | |x| | | |
-  Send MSS option always                         |4.2.2.6 | | |x| | |
-  Send-MSS default is 536                        |4.2.2.6 |x| | | | |
-  Calculate effective send seg size              |4.2.2.6 |x| | | | |
-                                                 |        | | | | | |
-TCP Checksums                                    |        | | | | | |
-  Sender compute checksum                        |4.2.2.7 |x| | | | |
-  Receiver check checksum                        |4.2.2.7 |x| | | | |
-                                                 |        | | | | | |
-Use clock-driven ISN selection                   |4.2.2.9 |x| | | | |
-                                                 |        | | | | | |
-Opening Connections                              |        | | | | | |
-  Support simultaneous open attempts             |4.2.2.10|x| | | | |
-  SYN-RCVD remembers last state                  |4.2.2.11|x| | | | |
-  Passive Open call interfere with others        |4.2.2.18| | | | |x|
-  Function: simultan. LISTENs for same port      |4.2.2.18|x| | | | |
-  Ask IP for src address for SYN if necc.        |4.2.3.7 |x| | | | |
-    Otherwise, use local addr of conn.           |4.2.3.7 |x| | | | |
-  OPEN to broadcast/multicast IP Address         |4.2.3.14| | | | |x|
-  Silently discard seg to bcast/mcast addr       |4.2.3.14|x| | | | |
-
-
-
-Internet Engineering Task Force                               [Page 109]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-                                                 |        | | | | | |
-Closing Connections                              |        | | | | | |
-  RST can contain data                           |4.2.2.12| |x| | | |
-  Inform application of aborted conn             |4.2.2.13|x| | | | |
-  Half-duplex close connections                  |4.2.2.13| | |x| | |
-    Send RST to indicate data lost               |4.2.2.13| |x| | | |
-  In TIME-WAIT state for 2xMSL seconds           |4.2.2.13|x| | | | |
-    Accept SYN from TIME-WAIT state              |4.2.2.13| | |x| | |
-                                                 |        | | | | | |
-Retransmissions                                  |        | | | | | |
-  Jacobson Slow Start algorithm                  |4.2.2.15|x| | | | |
-  Jacobson Congestion-Avoidance algorithm        |4.2.2.15|x| | | | |
-  Retransmit with same IP ident                  |4.2.2.15| | |x| | |
-  Karn's algorithm                               |4.2.3.1 |x| | | | |
-  Jacobson's RTO estimation alg.                 |4.2.3.1 |x| | | | |
-  Exponential backoff                            |4.2.3.1 |x| | | | |
-  SYN RTO calc same as data                      |4.2.3.1 | |x| | | |
-  Recommended initial values and bounds          |4.2.3.1 | |x| | | |
-                                                 |        | | | | | |
-Generating ACK's:                                |        | | | | | |
-  Queue out-of-order segments                    |4.2.2.20| |x| | | |
-  Process all Q'd before send ACK                |4.2.2.20|x| | | | |
-  Send ACK for out-of-order segment              |4.2.2.21| | |x| | |
-  Delayed ACK's                                  |4.2.3.2 | |x| | | |
-    Delay < 0.5 seconds                          |4.2.3.2 |x| | | | |
-    Every 2nd full-sized segment ACK'd           |4.2.3.2 |x| | | | |
-  Receiver SWS-Avoidance Algorithm               |4.2.3.3 |x| | | | |
-                                                 |        | | | | | |
-Sending data                                     |        | | | | | |
-  Configurable TTL                               |4.2.2.19|x| | | | |
-  Sender SWS-Avoidance Algorithm                 |4.2.3.4 |x| | | | |
-  Nagle algorithm                                |4.2.3.4 | |x| | | |
-    Application can disable Nagle algorithm      |4.2.3.4 |x| | | | |
-                                                 |        | | | | | |
-Connection Failures:                             |        | | | | | |
-  Negative advice to IP on R1 retxs              |4.2.3.5 |x| | | | |
-  Close connection on R2 retxs                   |4.2.3.5 |x| | | | |
-  ALP can set R2                                 |4.2.3.5 |x| | | | |1
-  Inform ALP of  R1<=retxs<R2                    |4.2.3.5 | |x| | | |1
-  Recommended values for R1, R2                  |4.2.3.5 | |x| | | |
-  Same mechanism for SYNs                        |4.2.3.5 |x| | | | |
-    R2 at least 3 minutes for SYN                |4.2.3.5 |x| | | | |
-                                                 |        | | | | | |
-Send Keep-alive Packets:                         |4.2.3.6 | | |x| | |
-  - Application can request                      |4.2.3.6 |x| | | | |
-  - Default is "off"                             |4.2.3.6 |x| | | | |
-  - Only send if idle for interval               |4.2.3.6 |x| | | | |
-  - Interval configurable                        |4.2.3.6 |x| | | | |
-
-
-
-Internet Engineering Task Force                               [Page 110]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-  - Default at least 2 hrs.                      |4.2.3.6 |x| | | | |
-  - Tolerant of lost ACK's                       |4.2.3.6 |x| | | | |
-                                                 |        | | | | | |
-IP Options                                       |        | | | | | |
-  Ignore options TCP doesn't understand          |4.2.3.8 |x| | | | |
-  Time Stamp support                             |4.2.3.8 | | |x| | |
-  Record Route support                           |4.2.3.8 | | |x| | |
-  Source Route:                                  |        | | | | | |
-    ALP can specify                              |4.2.3.8 |x| | | | |1
-      Overrides src rt in datagram               |4.2.3.8 |x| | | | |
-    Build return route from src rt               |4.2.3.8 |x| | | | |
-    Later src route overrides                    |4.2.3.8 | |x| | | |
-                                                 |        | | | | | |
-Receiving ICMP Messages from IP                  |4.2.3.9 |x| | | | |
-  Dest. Unreach (0,1,5) => inform ALP            |4.2.3.9 | |x| | | |
-  Dest. Unreach (0,1,5) => abort conn            |4.2.3.9 | | | | |x|
-  Dest. Unreach (2-4) => abort conn              |4.2.3.9 | |x| | | |
-  Source Quench => slow start                    |4.2.3.9 | |x| | | |
-  Time Exceeded => tell ALP, don't abort         |4.2.3.9 | |x| | | |
-  Param Problem => tell ALP, don't abort         |4.2.3.9 | |x| | | |
-                                                 |        | | | | | |
-Address Validation                               |        | | | | | |
-  Reject OPEN call to invalid IP address         |4.2.3.10|x| | | | |
-  Reject SYN from invalid IP address             |4.2.3.10|x| | | | |
-  Silently discard SYN to bcast/mcast addr       |4.2.3.10|x| | | | |
-                                                 |        | | | | | |
-TCP/ALP Interface Services                       |        | | | | | |
-  Error Report mechanism                         |4.2.4.1 |x| | | | |
-  ALP can disable Error Report Routine           |4.2.4.1 | |x| | | |
-  ALP can specify TOS for sending                |4.2.4.2 |x| | | | |
-    Passed unchanged to IP                       |4.2.4.2 | |x| | | |
-  ALP can change TOS during connection           |4.2.4.2 | |x| | | |
-  Pass received TOS up to ALP                    |4.2.4.2 | | |x| | |
-  FLUSH call                                     |4.2.4.3 | | |x| | |
-  Optional local IP addr parm. in OPEN           |4.2.4.4 |x| | | | |
--------------------------------------------------|--------|-|-|-|-|-|--
--------------------------------------------------|--------|-|-|-|-|-|--
-
-FOOTNOTES:
-
-(1)  "ALP" means Application-Layer program.
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                               [Page 111]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-5.  REFERENCES
-
-INTRODUCTORY REFERENCES
-
-
-[INTRO:1] "Requirements for Internet Hosts -- Application and Support,"
-     IETF Host Requirements Working Group, R. Braden, Ed., RFC-1123,
-     October 1989.
-
-[INTRO:2]  "Requirements for Internet Gateways,"  R. Braden and J.
-     Postel, RFC-1009, June 1987.
-
-[INTRO:3]  "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006,
-     (three volumes), SRI International, December 1985.
-
-[INTRO:4]  "Official Internet Protocols," J. Reynolds and J. Postel,
-     RFC-1011, May 1987.
-
-     This document is republished periodically with new RFC numbers; the
-     latest version must be used.
-
-[INTRO:5]  "Protocol Document Order Information," O. Jacobsen and J.
-     Postel, RFC-980, March 1986.
-
-[INTRO:6]  "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010, May
-     1987.
-
-     This document is republished periodically with new RFC numbers; the
-     latest version must be used.
-
-[INTRO:7] "Modularity and Efficiency in Protocol Implementations," D.
-     Clark, RFC-817, July 1982.
-
-[INTRO:8] "The Structuring of Systems Using Upcalls," D. Clark, 10th ACM
-     SOSP, Orcas Island, Washington, December 1985.
-
-
-Secondary References:
-
-
-[INTRO:9]  "A Protocol for Packet Network Intercommunication," V. Cerf
-     and R. Kahn, IEEE Transactions on Communication, May 1974.
-
-[INTRO:10]  "The ARPA Internet Protocol," J. Postel, C. Sunshine, and D.
-     Cohen, Computer Networks, Vol. 5, No. 4, July 1981.
-
-[INTRO:11]  "The DARPA Internet Protocol Suite," B. Leiner, J. Postel,
-     R. Cole and D. Mills, Proceedings INFOCOM 85, IEEE, Washington DC,
-
-
-
-Internet Engineering Task Force                               [Page 112]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-     March 1985.  Also in: IEEE Communications Magazine, March 1985.
-     Also available as ISI-RS-85-153.
-
-[INTRO:12] "Final Text of DIS8473, Protocol for Providing the
-     Connectionless Mode Network Service," ANSI, published as RFC-994,
-     March 1986.
-
-[INTRO:13] "End System to Intermediate System Routing Exchange
-     Protocol," ANSI X3S3.3, published as RFC-995, April 1986.
-
-
-LINK LAYER REFERENCES
-
-
-[LINK:1] "Trailer Encapsulations," S. Leffler and M. Karels, RFC-893,
-     April 1984.
-
-[LINK:2] "An Ethernet Address Resolution Protocol," D. Plummer, RFC-826,
-     November 1982.
-
-[LINK:3] "A Standard for the Transmission of IP Datagrams over Ethernet
-     Networks," C. Hornig, RFC-894, April 1984.
-
-[LINK:4] "A Standard for the Transmission of IP Datagrams over IEEE 802
-     "Networks," J. Postel and J. Reynolds, RFC-1042, February 1988.
-
-     This RFC contains a great deal of information of importance to
-     Internet implementers planning to use IEEE 802 networks.
-
-
-IP LAYER REFERENCES
-
-
-[IP:1] "Internet Protocol (IP)," J. Postel, RFC-791, September 1981.
-
-[IP:2] "Internet Control Message Protocol (ICMP)," J. Postel, RFC-792,
-     September 1981.
-
-[IP:3] "Internet Standard Subnetting Procedure," J. Mogul and J. Postel,
-     RFC-950, August 1985.
-
-[IP:4]  "Host Extensions for IP Multicasting," S. Deering, RFC-1112,
-     August 1989.
-
-[IP:5] "Military Standard Internet Protocol," MIL-STD-1777, Department
-     of Defense, August 1983.
-
-     This specification, as amended by RFC-963, is intended to describe
-
-
-
-Internet Engineering Task Force                               [Page 113]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-     the Internet Protocol but has some serious omissions (e.g., the
-     mandatory subnet extension [IP:3] and the optional multicasting
-     extension [IP:4]).  It is also out of date.  If there is a
-     conflict, RFC-791, RFC-792, and RFC-950 must be taken as
-     authoritative, while the present document is authoritative over
-     all.
-
-[IP:6] "Some Problems with the Specification of the Military Standard
-     Internet Protocol," D. Sidhu, RFC-963, November 1985.
-
-[IP:7] "The TCP Maximum Segment Size and Related Topics," J. Postel,
-     RFC-879, November 1983.
-
-     Discusses and clarifies the relationship between the TCP Maximum
-     Segment Size option and the IP datagram size.
-
-[IP:8] "Internet Protocol Security Options,"  B. Schofield, RFC-1108,
-     October 1989.
-
-[IP:9] "Fragmentation Considered Harmful," C. Kent and J. Mogul, ACM
-     SIGCOMM-87, August 1987.  Published as ACM Comp Comm Review, Vol.
-     17, no. 5.
-
-     This useful paper discusses the problems created by Internet
-     fragmentation and presents alternative solutions.
-
-[IP:10] "IP Datagram Reassembly Algorithms," D. Clark, RFC-815, July
-     1982.
-
-     This and the following paper should be read by every implementor.
-
-[IP:11] "Fault Isolation and Recovery," D. Clark, RFC-816, July 1982.
-
-SECONDARY IP REFERENCES:
-
-
-[IP:12] "Broadcasting Internet Datagrams in the Presence of Subnets," J.
-     Mogul, RFC-922, October 1984.
-
-[IP:13] "Name, Addresses, Ports, and Routes," D. Clark, RFC-814, July
-     1982.
-
-[IP:14] "Something a Host Could Do with Source Quench: The Source Quench
-     Introduced Delay (SQUID)," W. Prue and J. Postel, RFC-1016, July
-     1987.
-
-     This RFC first described directed broadcast addresses.  However,
-     the bulk of the RFC is concerned with gateways, not hosts.
-
-
-
-Internet Engineering Task Force                               [Page 114]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-UDP REFERENCES:
-
-
-[UDP:1] "User Datagram Protocol," J. Postel, RFC-768, August 1980.
-
-
-TCP REFERENCES:
-
-
-[TCP:1] "Transmission Control Protocol," J. Postel, RFC-793, September
-     1981.
-
-
-[TCP:2] "Transmission Control Protocol," MIL-STD-1778, US Department of
-     Defense, August 1984.
-
-     This specification as amended by RFC-964 is intended to describe
-     the same protocol as RFC-793 [TCP:1].  If there is a conflict,
-     RFC-793 takes precedence, and the present document is authoritative
-     over both.
-
-
-[TCP:3] "Some Problems with the Specification of the Military Standard
-     Transmission Control Protocol," D. Sidhu and T. Blumer, RFC-964,
-     November 1985.
-
-
-[TCP:4] "The TCP Maximum Segment Size and Related Topics," J. Postel,
-     RFC-879, November 1983.
-
-
-[TCP:5] "Window and Acknowledgment Strategy in TCP," D. Clark, RFC-813,
-     July 1982.
-
-
-[TCP:6] "Round Trip Time Estimation," P. Karn & C. Partridge, ACM
-     SIGCOMM-87, August 1987.
-
-
-[TCP:7] "Congestion Avoidance and Control," V. Jacobson, ACM SIGCOMM-88,
-     August 1988.
-
-
-SECONDARY TCP REFERENCES:
-
-
-[TCP:8] "Modularity and Efficiency in Protocol Implementation," D.
-     Clark, RFC-817, July 1982.
-
-
-
-Internet Engineering Task Force                               [Page 115]
-
-
-
-
-RFC1122                  TRANSPORT LAYER -- TCP             October 1989
-
-
-[TCP:9] "Congestion Control in IP/TCP," J. Nagle, RFC-896, January 1984.
-
-
-[TCP:10] "Computing the Internet Checksum," R. Braden, D. Borman, and C.
-     Partridge, RFC-1071, September 1988.
-
-
-[TCP:11] "TCP Extensions for Long-Delay Paths," V. Jacobson & R. Braden,
-     RFC-1072, October 1988.
-
-
-Security Considerations
-
-   There are many security issues in the communication layers of host
-   software, but a full discussion is beyond the scope of this RFC.
-
-   The Internet architecture generally provides little protection
-   against spoofing of IP source addresses, so any security mechanism
-   that is based upon verifying the IP source address of a datagram
-   should be treated with suspicion.  However, in restricted
-   environments some source-address checking may be possible.  For
-   example, there might be a secure LAN whose gateway to the rest of the
-   Internet discarded any incoming datagram with a source address that
-   spoofed the LAN address.  In this case, a host on the LAN could use
-   the source address to test for local vs. remote source.  This problem
-   is complicated by source routing, and some have suggested that
-   source-routed datagram forwarding by hosts (see Section 3.3.5) should
-   be outlawed for security reasons.
-
-   Security-related issues are mentioned in sections concerning the IP
-   Security option (Section 3.2.1.8), the ICMP Parameter Problem message
-   (Section 3.2.2.5), IP options in UDP datagrams (Section 4.1.3.2), and
-   reserved TCP ports (Section 4.2.2.1).
-
-Author's Address
-
-   Robert Braden
-   USC/Information Sciences Institute
-   4676 Admiralty Way
-   Marina del Rey, CA 90292-6695
-
-   Phone: (213) 822 1511
-
-   EMail: Braden@ISI.EDU
-
-
-
-
-
-
-
-Internet Engineering Task Force                               [Page 116]
-
diff --git a/contrib/bind9/doc/rfc/rfc1123.txt b/contrib/bind9/doc/rfc/rfc1123.txt
deleted file mode 100644
index 51cdf83..0000000
--- a/contrib/bind9/doc/rfc/rfc1123.txt
+++ /dev/null
@@ -1,5782 +0,0 @@
-
-
-
-
-
-
-Network Working Group                    Internet Engineering Task Force
-Request for Comments: 1123                             R. Braden, Editor
-                                                            October 1989
-
-
-       Requirements for Internet Hosts -- Application and Support
-
-Status of This Memo
-
-   This RFC is an official specification for the Internet community.  It
-   incorporates by reference, amends, corrects, and supplements the
-   primary protocol standards documents relating to hosts.  Distribution
-   of this document is unlimited.
-
-Summary
-
-   This RFC is one of a pair that defines and discusses the requirements
-   for Internet host software.  This RFC covers the application and
-   support protocols; its companion RFC-1122 covers the communication
-   protocol layers: link layer, IP layer, and transport layer.
-
-
-
-                           Table of Contents
-
-
-
-
-   1.  INTRODUCTION ...............................................    5
-      1.1  The Internet Architecture ..............................    6
-      1.2  General Considerations .................................    6
-         1.2.1  Continuing Internet Evolution .....................    6
-         1.2.2  Robustness Principle ..............................    7
-         1.2.3  Error Logging .....................................    8
-         1.2.4  Configuration .....................................    8
-      1.3  Reading this Document ..................................   10
-         1.3.1  Organization ......................................   10
-         1.3.2  Requirements ......................................   10
-         1.3.3  Terminology .......................................   11
-      1.4  Acknowledgments ........................................   12
-
-   2.  GENERAL ISSUES .............................................   13
-      2.1  Host Names and Numbers .................................   13
-      2.2  Using Domain Name Service ..............................   13
-      2.3  Applications on Multihomed hosts .......................   14
-      2.4  Type-of-Service ........................................   14
-      2.5  GENERAL APPLICATION REQUIREMENTS SUMMARY ...............   15
-
-
-
-
-Internet Engineering Task Force                                 [Page 1]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-   3.  REMOTE LOGIN -- TELNET PROTOCOL ............................   16
-      3.1  INTRODUCTION ...........................................   16
-      3.2  PROTOCOL WALK-THROUGH ..................................   16
-         3.2.1  Option Negotiation ................................   16
-         3.2.2  Telnet Go-Ahead Function ..........................   16
-         3.2.3  Control Functions .................................   17
-         3.2.4  Telnet "Synch" Signal .............................   18
-         3.2.5  NVT Printer and Keyboard ..........................   19
-         3.2.6  Telnet Command Structure ..........................   20
-         3.2.7  Telnet Binary Option ..............................   20
-         3.2.8  Telnet Terminal-Type Option .......................   20
-      3.3  SPECIFIC ISSUES ........................................   21
-         3.3.1  Telnet End-of-Line Convention .....................   21
-         3.3.2  Data Entry Terminals ..............................   23
-         3.3.3  Option Requirements ...............................   24
-         3.3.4  Option Initiation .................................   24
-         3.3.5  Telnet Linemode Option ............................   25
-      3.4  TELNET/USER INTERFACE ..................................   25
-         3.4.1  Character Set Transparency ........................   25
-         3.4.2  Telnet Commands ...................................   26
-         3.4.3  TCP Connection Errors .............................   26
-         3.4.4  Non-Default Telnet Contact Port ...................   26
-         3.4.5  Flushing Output ...................................   26
-      3.5.  TELNET REQUIREMENTS SUMMARY ...........................   27
-
-   4.  FILE TRANSFER ..............................................   29
-      4.1  FILE TRANSFER PROTOCOL -- FTP ..........................   29
-         4.1.1  INTRODUCTION ......................................   29
-         4.1.2.  PROTOCOL WALK-THROUGH ............................   29
-            4.1.2.1  LOCAL Type ...................................   29
-            4.1.2.2  Telnet Format Control ........................   30
-            4.1.2.3  Page Structure ...............................   30
-            4.1.2.4  Data Structure Transformations ...............   30
-            4.1.2.5  Data Connection Management ...................   31
-            4.1.2.6  PASV Command .................................   31
-            4.1.2.7  LIST and NLST Commands .......................   31
-            4.1.2.8  SITE Command .................................   32
-            4.1.2.9  STOU Command .................................   32
-            4.1.2.10  Telnet End-of-line Code .....................   32
-            4.1.2.11  FTP Replies .................................   33
-            4.1.2.12  Connections .................................   34
-            4.1.2.13  Minimum Implementation; RFC-959 Section .....   34
-         4.1.3  SPECIFIC ISSUES ...................................   35
-            4.1.3.1  Non-standard Command Verbs ...................   35
-            4.1.3.2  Idle Timeout .................................   36
-            4.1.3.3  Concurrency of Data and Control ..............   36
-            4.1.3.4  FTP Restart Mechanism ........................   36
-         4.1.4  FTP/USER INTERFACE ................................   39
-
-
-
-Internet Engineering Task Force                                 [Page 2]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-            4.1.4.1  Pathname Specification .......................   39
-            4.1.4.2  "QUOTE" Command ..............................   40
-            4.1.4.3  Displaying Replies to User ...................   40
-            4.1.4.4  Maintaining Synchronization ..................   40
-         4.1.5   FTP REQUIREMENTS SUMMARY .........................   41
-      4.2  TRIVIAL FILE TRANSFER PROTOCOL -- TFTP .................   44
-         4.2.1  INTRODUCTION ......................................   44
-         4.2.2  PROTOCOL WALK-THROUGH .............................   44
-            4.2.2.1  Transfer Modes ...............................   44
-            4.2.2.2  UDP Header ...................................   44
-         4.2.3  SPECIFIC ISSUES ...................................   44
-            4.2.3.1  Sorcerer's Apprentice Syndrome ...............   44
-            4.2.3.2  Timeout Algorithms ...........................   46
-            4.2.3.3  Extensions ...................................   46
-            4.2.3.4  Access Control ...............................   46
-            4.2.3.5  Broadcast Request ............................   46
-         4.2.4  TFTP REQUIREMENTS SUMMARY .........................   47
-
-   5.  ELECTRONIC MAIL -- SMTP and RFC-822 ........................   48
-      5.1  INTRODUCTION ...........................................   48
-      5.2  PROTOCOL WALK-THROUGH ..................................   48
-         5.2.1  The SMTP Model ....................................   48
-         5.2.2  Canonicalization ..................................   49
-         5.2.3  VRFY and EXPN Commands ............................   50
-         5.2.4  SEND, SOML, and SAML Commands .....................   50
-         5.2.5  HELO Command ......................................   50
-         5.2.6  Mail Relay ........................................   51
-         5.2.7  RCPT Command ......................................   52
-         5.2.8  DATA Command ......................................   53
-         5.2.9  Command Syntax ....................................   54
-         5.2.10  SMTP Replies .....................................   54
-         5.2.11  Transparency .....................................   55
-         5.2.12  WKS Use in MX Processing .........................   55
-         5.2.13  RFC-822 Message Specification ....................   55
-         5.2.14  RFC-822 Date and Time Specification ..............   55
-         5.2.15  RFC-822 Syntax Change ............................   56
-         5.2.16  RFC-822  Local-part ..............................   56
-         5.2.17  Domain Literals ..................................   57
-         5.2.18  Common Address Formatting Errors .................   58
-         5.2.19  Explicit Source Routes ...........................   58
-      5.3  SPECIFIC ISSUES ........................................   59
-         5.3.1  SMTP Queueing Strategies ..........................   59
-            5.3.1.1 Sending Strategy ..............................   59
-            5.3.1.2  Receiving strategy ...........................   61
-         5.3.2  Timeouts in SMTP ..................................   61
-         5.3.3  Reliable Mail Receipt .............................   63
-         5.3.4  Reliable Mail Transmission ........................   63
-         5.3.5  Domain Name Support ...............................   65
-
-
-
-Internet Engineering Task Force                                 [Page 3]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-         5.3.6  Mailing Lists and Aliases .........................   65
-         5.3.7  Mail Gatewaying ...................................   66
-         5.3.8  Maximum Message Size ..............................   68
-      5.4  SMTP REQUIREMENTS SUMMARY ..............................   69
-
-   6. SUPPORT SERVICES ............................................   72
-      6.1 DOMAIN NAME TRANSLATION .................................   72
-         6.1.1 INTRODUCTION .......................................   72
-         6.1.2  PROTOCOL WALK-THROUGH .............................   72
-            6.1.2.1  Resource Records with Zero TTL ...............   73
-            6.1.2.2  QCLASS Values ................................   73
-            6.1.2.3  Unused Fields ................................   73
-            6.1.2.4  Compression ..................................   73
-            6.1.2.5  Misusing Configuration Info ..................   73
-         6.1.3  SPECIFIC ISSUES ...................................   74
-            6.1.3.1  Resolver Implementation ......................   74
-            6.1.3.2  Transport Protocols ..........................   75
-            6.1.3.3  Efficient Resource Usage .....................   77
-            6.1.3.4  Multihomed Hosts .............................   78
-            6.1.3.5  Extensibility ................................   79
-            6.1.3.6  Status of RR Types ...........................   79
-            6.1.3.7  Robustness ...................................   80
-            6.1.3.8  Local Host Table .............................   80
-         6.1.4  DNS USER INTERFACE ................................   81
-            6.1.4.1  DNS Administration ...........................   81
-            6.1.4.2  DNS User Interface ...........................   81
-            6.1.4.3 Interface Abbreviation Facilities .............   82
-         6.1.5  DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY ...........   84
-      6.2  HOST INITIALIZATION ....................................   87
-         6.2.1  INTRODUCTION ......................................   87
-         6.2.2  REQUIREMENTS ......................................   87
-            6.2.2.1  Dynamic Configuration ........................   87
-            6.2.2.2  Loading Phase ................................   89
-      6.3  REMOTE MANAGEMENT ......................................   90
-         6.3.1  INTRODUCTION ......................................   90
-         6.3.2  PROTOCOL WALK-THROUGH .............................   90
-         6.3.3  MANAGEMENT REQUIREMENTS SUMMARY ...................   92
-
-   7.  REFERENCES .................................................   93
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                 [Page 4]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-1.  INTRODUCTION
-
-   This document is one of a pair that defines and discusses the
-   requirements for host system implementations of the Internet protocol
-   suite.  This RFC covers the applications layer and support protocols.
-   Its companion RFC, "Requirements for Internet Hosts -- Communications
-   Layers" [INTRO:1] covers the lower layer protocols: transport layer,
-   IP layer, and link layer.
-
-   These documents are intended to provide guidance for vendors,
-   implementors, and users of Internet communication software.  They
-   represent the consensus of a large body of technical experience and
-   wisdom, contributed by members of the Internet research and vendor
-   communities.
-
-   This RFC enumerates standard protocols that a host connected to the
-   Internet must use, and it incorporates by reference the RFCs and
-   other documents describing the current specifications for these
-   protocols.  It corrects errors in the referenced documents and adds
-   additional discussion and guidance for an implementor.
-
-   For each protocol, this document also contains an explicit set of
-   requirements, recommendations, and options.  The reader must
-   understand that the list of requirements in this document is
-   incomplete by itself; the complete set of requirements for an
-   Internet host is primarily defined in the standard protocol
-   specification documents, with the corrections, amendments, and
-   supplements contained in this RFC.
-
-   A good-faith implementation of the protocols that was produced after
-   careful reading of the RFC's and with some interaction with the
-   Internet technical community, and that followed good communications
-   software engineering practices, should differ from the requirements
-   of this document in only minor ways.  Thus, in many cases, the
-   "requirements" in this RFC are already stated or implied in the
-   standard protocol documents, so that their inclusion here is, in a
-   sense, redundant.  However, they were included because some past
-   implementation has made the wrong choice, causing problems of
-   interoperability, performance, and/or robustness.
-
-   This document includes discussion and explanation of many of the
-   requirements and recommendations.  A simple list of requirements
-   would be dangerous, because:
-
-   o    Some required features are more important than others, and some
-        features are optional.
-
-   o    There may be valid reasons why particular vendor products that
-
-
-
-Internet Engineering Task Force                                 [Page 5]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-        are designed for restricted contexts might choose to use
-        different specifications.
-
-   However, the specifications of this document must be followed to meet
-   the general goal of arbitrary host interoperation across the
-   diversity and complexity of the Internet system.  Although most
-   current implementations fail to meet these requirements in various
-   ways, some minor and some major, this specification is the ideal
-   towards which we need to move.
-
-   These requirements are based on the current level of Internet
-   architecture.  This document will be updated as required to provide
-   additional clarifications or to include additional information in
-   those areas in which specifications are still evolving.
-
-   This introductory section begins with general advice to host software
-   vendors, and then gives some guidance on reading the rest of the
-   document.  Section 2 contains general requirements that may be
-   applicable to all application and support protocols.  Sections 3, 4,
-   and 5 contain the requirements on protocols for the three major
-   applications: Telnet, file transfer, and electronic mail,
-   respectively. Section 6 covers the support applications: the domain
-   name system, system initialization, and management.  Finally, all
-   references will be found in Section 7.
-
-   1.1  The Internet Architecture
-
-      For a brief introduction to the Internet architecture from a host
-      viewpoint, see Section 1.1 of [INTRO:1].  That section also
-      contains recommended references for general background on the
-      Internet architecture.
-
-   1.2  General Considerations
-
-      There are two important lessons that vendors of Internet host
-      software have learned and which a new vendor should consider
-      seriously.
-
-      1.2.1  Continuing Internet Evolution
-
-         The enormous growth of the Internet has revealed problems of
-         management and scaling in a large datagram-based packet
-         communication system.  These problems are being addressed, and
-         as a result there will be continuing evolution of the
-         specifications described in this document.  These changes will
-         be carefully planned and controlled, since there is extensive
-         participation in this planning by the vendors and by the
-         organizations responsible for operations of the networks.
-
-
-
-Internet Engineering Task Force                                 [Page 6]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-         Development, evolution, and revision are characteristic of
-         computer network protocols today, and this situation will
-         persist for some years.  A vendor who develops computer
-         communication software for the Internet protocol suite (or any
-         other protocol suite!) and then fails to maintain and update
-         that software for changing specifications is going to leave a
-         trail of unhappy customers.  The Internet is a large
-         communication network, and the users are in constant contact
-         through it.  Experience has shown that knowledge of
-         deficiencies in vendor software propagates quickly through the
-         Internet technical community.
-
-      1.2.2  Robustness Principle
-
-         At every layer of the protocols, there is a general rule whose
-         application can lead to enormous benefits in robustness and
-         interoperability:
-
-                "Be liberal in what you accept, and
-                 conservative in what you send"
-
-         Software should be written to deal with every conceivable
-         error, no matter how unlikely; sooner or later a packet will
-         come in with that particular combination of errors and
-         attributes, and unless the software is prepared, chaos can
-         ensue.  In general, it is best to assume that the network is
-         filled with malevolent entities that will send in packets
-         designed to have the worst possible effect.  This assumption
-         will lead to suitable protective design, although the most
-         serious problems in the Internet have been caused by
-         unenvisaged mechanisms triggered by low-probability events;
-         mere human malice would never have taken so devious a course!
-
-         Adaptability to change must be designed into all levels of
-         Internet host software.  As a simple example, consider a
-         protocol specification that contains an enumeration of values
-         for a particular header field -- e.g., a type field, a port
-         number, or an error code; this enumeration must be assumed to
-         be incomplete.  Thus, if a protocol specification defines four
-         possible error codes, the software must not break when a fifth
-         code shows up.  An undefined code might be logged (see below),
-         but it must not cause a failure.
-
-         The second part of the principle is almost as important:
-         software on other hosts may contain deficiencies that make it
-         unwise to exploit legal but obscure protocol features.  It is
-         unwise to stray far from the obvious and simple, lest untoward
-         effects result elsewhere.  A corollary of this is "watch out
-
-
-
-Internet Engineering Task Force                                 [Page 7]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-         for misbehaving hosts"; host software should be prepared, not
-         just to survive other misbehaving hosts, but also to cooperate
-         to limit the amount of disruption such hosts can cause to the
-         shared communication facility.
-
-      1.2.3  Error Logging
-
-         The Internet includes a great variety of host and gateway
-         systems, each implementing many protocols and protocol layers,
-         and some of these contain bugs and mis-features in their
-         Internet protocol software.  As a result of complexity,
-         diversity, and distribution of function, the diagnosis of user
-         problems is often very difficult.
-
-         Problem diagnosis will be aided if host implementations include
-         a carefully designed facility for logging erroneous or
-         "strange" protocol events.  It is important to include as much
-         diagnostic information as possible when an error is logged.  In
-         particular, it is often useful to record the header(s) of a
-         packet that caused an error.  However, care must be taken to
-         ensure that error logging does not consume prohibitive amounts
-         of resources or otherwise interfere with the operation of the
-         host.
-
-         There is a tendency for abnormal but harmless protocol events
-         to overflow error logging files; this can be avoided by using a
-         "circular" log, or by enabling logging only while diagnosing a
-         known failure.  It may be useful to filter and count duplicate
-         successive messages.  One strategy that seems to work well is:
-         (1) always count abnormalities and make such counts accessible
-         through the management protocol (see Section 6.3); and (2)
-         allow the logging of a great variety of events to be
-         selectively enabled.  For example, it might useful to be able
-         to "log everything" or to "log everything for host X".
-
-         Note that different managements may have differing policies
-         about the amount of error logging that they want normally
-         enabled in a host.  Some will say, "if it doesn't hurt me, I
-         don't want to know about it", while others will want to take a
-         more watchful and aggressive attitude about detecting and
-         removing protocol abnormalities.
-
-      1.2.4  Configuration
-
-         It would be ideal if a host implementation of the Internet
-         protocol suite could be entirely self-configuring.  This would
-         allow the whole suite to be implemented in ROM or cast into
-         silicon, it would simplify diskless workstations, and it would
-
-
-
-Internet Engineering Task Force                                 [Page 8]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-         be an immense boon to harried LAN administrators as well as
-         system vendors.  We have not reached this ideal; in fact, we
-         are not even close.
-
-         At many points in this document, you will find a requirement
-         that a parameter be a configurable option.  There are several
-         different reasons behind such requirements.  In a few cases,
-         there is current uncertainty or disagreement about the best
-         value, and it may be necessary to update the recommended value
-         in the future.  In other cases, the value really depends on
-         external factors -- e.g., the size of the host and the
-         distribution of its communication load, or the speeds and
-         topology of nearby networks -- and self-tuning algorithms are
-         unavailable and may be insufficient.  In some cases,
-         configurability is needed because of administrative
-         requirements.
-
-         Finally, some configuration options are required to communicate
-         with obsolete or incorrect implementations of the protocols,
-         distributed without sources, that unfortunately persist in many
-         parts of the Internet.  To make correct systems coexist with
-         these faulty systems, administrators often have to "mis-
-         configure" the correct systems.  This problem will correct
-         itself gradually as the faulty systems are retired, but it
-         cannot be ignored by vendors.
-
-         When we say that a parameter must be configurable, we do not
-         intend to require that its value be explicitly read from a
-         configuration file at every boot time.  We recommend that
-         implementors set up a default for each parameter, so a
-         configuration file is only necessary to override those defaults
-         that are inappropriate in a particular installation.  Thus, the
-         configurability requirement is an assurance that it will be
-         POSSIBLE to override the default when necessary, even in a
-         binary-only or ROM-based product.
-
-         This document requires a particular value for such defaults in
-         some cases.  The choice of default is a sensitive issue when
-         the configuration item controls the accommodation to existing
-         faulty systems.  If the Internet is to converge successfully to
-         complete interoperability, the default values built into
-         implementations must implement the official protocol, not
-         "mis-configurations" to accommodate faulty implementations.
-         Although marketing considerations have led some vendors to
-         choose mis-configuration defaults, we urge vendors to choose
-         defaults that will conform to the standard.
-
-         Finally, we note that a vendor needs to provide adequate
-
-
-
-Internet Engineering Task Force                                 [Page 9]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-         documentation on all configuration parameters, their limits and
-         effects.
-
-
-   1.3  Reading this Document
-
-      1.3.1  Organization
-
-         In general, each major section is organized into the following
-         subsections:
-
-         (1)  Introduction
-
-         (2)  Protocol Walk-Through -- considers the protocol
-              specification documents section-by-section, correcting
-              errors, stating requirements that may be ambiguous or
-              ill-defined, and providing further clarification or
-              explanation.
-
-         (3)  Specific Issues -- discusses protocol design and
-              implementation issues that were not included in the walk-
-              through.
-
-         (4)  Interfaces -- discusses the service interface to the next
-              higher layer.
-
-         (5)  Summary -- contains a summary of the requirements of the
-              section.
-
-         Under many of the individual topics in this document, there is
-         parenthetical material labeled "DISCUSSION" or
-         "IMPLEMENTATION".  This material is intended to give
-         clarification and explanation of the preceding requirements
-         text.  It also includes some suggestions on possible future
-         directions or developments.  The implementation material
-         contains suggested approaches that an implementor may want to
-         consider.
-
-         The summary sections are intended to be guides and indexes to
-         the text, but are necessarily cryptic and incomplete.  The
-         summaries should never be used or referenced separately from
-         the complete RFC.
-
-      1.3.2  Requirements
-
-         In this document, the words that are used to define the
-         significance of each particular requirement are capitalized.
-         These words are:
-
-
-
-Internet Engineering Task Force                                [Page 10]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-         *    "MUST"
-
-              This word or the adjective "REQUIRED" means that the item
-              is an absolute requirement of the specification.
-
-         *    "SHOULD"
-
-              This word or the adjective "RECOMMENDED" means that there
-              may exist valid reasons in particular circumstances to
-              ignore this item, but the full implications should be
-              understood and the case carefully weighed before choosing
-              a different course.
-
-         *    "MAY"
-
-              This word or the adjective "OPTIONAL" means that this item
-              is truly optional.  One vendor may choose to include the
-              item because a particular marketplace requires it or
-              because it enhances the product, for example; another
-              vendor may omit the same item.
-
-
-         An implementation is not compliant if it fails to satisfy one
-         or more of the MUST requirements for the protocols it
-         implements.  An implementation that satisfies all the MUST and
-         all the SHOULD requirements for its protocols is said to be
-         "unconditionally compliant"; one that satisfies all the MUST
-         requirements but not all the SHOULD requirements for its
-         protocols is said to be "conditionally compliant".
-
-      1.3.3  Terminology
-
-         This document uses the following technical terms:
-
-         Segment
-              A segment is the unit of end-to-end transmission in the
-              TCP protocol.  A segment consists of a TCP header followed
-              by application data.  A segment is transmitted by
-              encapsulation in an IP datagram.
-
-         Message
-              This term is used by some application layer protocols
-              (particularly SMTP) for an application data unit.
-
-         Datagram
-              A [UDP] datagram is the unit of end-to-end transmission in
-              the UDP protocol.
-
-
-
-
-Internet Engineering Task Force                                [Page 11]
-
-
-
-
-RFC1123                       INTRODUCTION                  October 1989
-
-
-         Multihomed
-              A host is said to be multihomed if it has multiple IP
-              addresses to connected networks.
-
-
-
-   1.4  Acknowledgments
-
-      This document incorporates contributions and comments from a large
-      group of Internet protocol experts, including representatives of
-      university and research labs, vendors, and government agencies.
-      It was assembled primarily by the Host Requirements Working Group
-      of the Internet Engineering Task Force (IETF).
-
-      The Editor would especially like to acknowledge the tireless
-      dedication of the following people, who attended many long
-      meetings and generated 3 million bytes of electronic mail over the
-      past 18 months in pursuit of this document: Philip Almquist, Dave
-      Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve
-      Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore),
-      John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG),
-      Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge
-      (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).
-
-      In addition, the following people made major contributions to the
-      effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia
-      (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),
-      Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL),
-      John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill
-      Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul
-      (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue
-      Technology), and Mike StJohns (DCA).  The following also made
-      significant contributions to particular areas: Eric Allman
-      (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic
-      (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn
-      (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann
-      (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun
-      Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen
-      (Toronto).
-
-      We are grateful to all, including any contributors who may have
-      been inadvertently omitted from this list.
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 12]
-
-
-
-
-RFC1123              APPLICATIONS LAYER -- GENERAL          October 1989
-
-
-2.  GENERAL ISSUES
-
-   This section contains general requirements that may be applicable to
-   all application-layer protocols.
-
-   2.1  Host Names and Numbers
-
-      The syntax of a legal Internet host name was specified in RFC-952
-      [DNS:4].  One aspect of host name syntax is hereby changed: the
-      restriction on the first character is relaxed to allow either a
-      letter or a digit.  Host software MUST support this more liberal
-      syntax.
-
-      Host software MUST handle host names of up to 63 characters and
-      SHOULD handle host names of up to 255 characters.
-
-      Whenever a user inputs the identity of an Internet host, it SHOULD
-      be possible to enter either (1) a host domain name or (2) an IP
-      address in dotted-decimal ("#.#.#.#") form.  The host SHOULD check
-      the string syntactically for a dotted-decimal number before
-      looking it up in the Domain Name System.
-
-      DISCUSSION:
-           This last requirement is not intended to specify the complete
-           syntactic form for entering a dotted-decimal host number;
-           that is considered to be a user-interface issue.  For
-           example, a dotted-decimal number must be enclosed within
-           "[ ]" brackets for SMTP mail (see Section 5.2.17).  This
-           notation could be made universal within a host system,
-           simplifying the syntactic checking for a dotted-decimal
-           number.
-
-           If a dotted-decimal number can be entered without such
-           identifying delimiters, then a full syntactic check must be
-           made, because a segment of a host domain name is now allowed
-           to begin with a digit and could legally be entirely numeric
-           (see Section 6.1.2.4).  However, a valid host name can never
-           have the dotted-decimal form #.#.#.#, since at least the
-           highest-level component label will be alphabetic.
-
-   2.2  Using Domain Name Service
-
-      Host domain names MUST be translated to IP addresses as described
-      in Section 6.1.
-
-      Applications using domain name services MUST be able to cope with
-      soft error conditions.  Applications MUST wait a reasonable
-      interval between successive retries due to a soft error, and MUST
-
-
-
-Internet Engineering Task Force                                [Page 13]
-
-
-
-
-RFC1123              APPLICATIONS LAYER -- GENERAL          October 1989
-
-
-      allow for the possibility that network problems may deny service
-      for hours or even days.
-
-      An application SHOULD NOT rely on the ability to locate a WKS
-      record containing an accurate listing of all services at a
-      particular host address, since the WKS RR type is not often used
-      by Internet sites.  To confirm that a service is present, simply
-      attempt to use it.
-
-   2.3  Applications on Multihomed hosts
-
-      When the remote host is multihomed, the name-to-address
-      translation will return a list of alternative IP addresses.  As
-      specified in Section 6.1.3.4, this list should be in order of
-      decreasing preference.  Application protocol implementations
-      SHOULD be prepared to try multiple addresses from the list until
-      success is obtained.  More specific requirements for SMTP are
-      given in Section 5.3.4.
-
-      When the local host is multihomed, a UDP-based request/response
-      application SHOULD send the response with an IP source address
-      that is the same as the specific destination address of the UDP
-      request datagram.  The "specific destination address" is defined
-      in the "IP Addressing" section of the companion RFC [INTRO:1].
-
-      Similarly, a server application that opens multiple TCP
-      connections to the same client SHOULD use the same local IP
-      address for all.
-
-   2.4  Type-of-Service
-
-      Applications MUST select appropriate TOS values when they invoke
-      transport layer services, and these values MUST be configurable.
-      Note that a TOS value contains 5 bits, of which only the most-
-      significant 3 bits are currently defined; the other two bits MUST
-      be zero.
-
-      DISCUSSION:
-           As gateway algorithms are developed to implement Type-of-
-           Service, the recommended values for various application
-           protocols may change.  In addition, it is likely that
-           particular combinations of users and Internet paths will want
-           non-standard TOS values.  For these reasons, the TOS values
-           must be configurable.
-
-           See the latest version of the "Assigned Numbers" RFC
-           [INTRO:5] for the recommended TOS values for the major
-           application protocols.
-
-
-
-Internet Engineering Task Force                                [Page 14]
-
-
-
-
-RFC1123              APPLICATIONS LAYER -- GENERAL          October 1989
-
-
-   2.5  GENERAL APPLICATION REQUIREMENTS SUMMARY
-
-                                               |          | | | |S| |
-                                               |          | | | |H| |F
-                                               |          | | | |O|M|o
-                                               |          | |S| |U|U|o
-                                               |          | |H| |L|S|t
-                                               |          |M|O| |D|T|n
-                                               |          |U|U|M| | |o
-                                               |          |S|L|A|N|N|t
-                                               |          |T|D|Y|O|O|t
-FEATURE                                        |SECTION   | | | |T|T|e
------------------------------------------------|----------|-|-|-|-|-|--
-                                               |          | | | | | |
-User interfaces:                               |          | | | | | |
-  Allow host name to begin with digit          |2.1       |x| | | | |
-  Host names of up to 635 characters           |2.1       |x| | | | |
-  Host names of up to 255 characters           |2.1       | |x| | | |
-  Support dotted-decimal host numbers          |2.1       | |x| | | |
-  Check syntactically for dotted-dec first     |2.1       | |x| | | |
-                                               |          | | | | | |
-Map domain names per Section 6.1               |2.2       |x| | | | |
-Cope with soft DNS errors                      |2.2       |x| | | | |
-   Reasonable interval between retries         |2.2       |x| | | | |
-   Allow for long outages                      |2.2       |x| | | | |
-Expect WKS records to be available             |2.2       | | | |x| |
-                                               |          | | | | | |
-Try multiple addr's for remote multihomed host |2.3       | |x| | | |
-UDP reply src addr is specific dest of request |2.3       | |x| | | |
-Use same IP addr for related TCP connections   |2.3       | |x| | | |
-Specify appropriate TOS values                 |2.4       |x| | | | |
-  TOS values configurable                      |2.4       |x| | | | |
-  Unused TOS bits zero                         |2.4       |x| | | | |
-                                               |          | | | | | |
-                                               |          | | | | | |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 15]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-3.  REMOTE LOGIN -- TELNET PROTOCOL
-
-   3.1  INTRODUCTION
-
-      Telnet is the standard Internet application protocol for remote
-      login.  It provides the encoding rules to link a user's
-      keyboard/display on a client ("user") system with a command
-      interpreter on a remote server system.  A subset of the Telnet
-      protocol is also incorporated within other application protocols,
-      e.g., FTP and SMTP.
-
-      Telnet uses a single TCP connection, and its normal data stream
-      ("Network Virtual Terminal" or "NVT" mode) is 7-bit ASCII with
-      escape sequences to embed control functions.  Telnet also allows
-      the negotiation of many optional modes and functions.
-
-      The primary Telnet specification is to be found in RFC-854
-      [TELNET:1], while the options are defined in many other RFCs; see
-      Section 7 for references.
-
-   3.2  PROTOCOL WALK-THROUGH
-
-      3.2.1  Option Negotiation: RFC-854, pp. 2-3
-
-         Every Telnet implementation MUST include option negotiation and
-         subnegotiation machinery [TELNET:2].
-
-         A host MUST carefully follow the rules of RFC-854 to avoid
-         option-negotiation loops.  A host MUST refuse (i.e, reply
-         WONT/DONT to a DO/WILL) an unsupported option.  Option
-         negotiation SHOULD continue to function (even if all requests
-         are refused) throughout the lifetime of a Telnet connection.
-
-         If all option negotiations fail, a Telnet implementation MUST
-         default to, and support, an NVT.
-
-         DISCUSSION:
-              Even though more sophisticated "terminals" and supporting
-              option negotiations are becoming the norm, all
-              implementations must be prepared to support an NVT for any
-              user-server communication.
-
-      3.2.2  Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858
-
-         On a host that never sends the Telnet command Go Ahead (GA),
-         the Telnet Server MUST attempt to negotiate the Suppress Go
-         Ahead option (i.e., send "WILL Suppress Go Ahead").  A User or
-         Server Telnet MUST always accept negotiation of the Suppress Go
-
-
-
-Internet Engineering Task Force                                [Page 16]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-         Ahead option.
-
-         When it is driving a full-duplex terminal for which GA has no
-         meaning, a User Telnet implementation MAY ignore GA commands.
-
-         DISCUSSION:
-              Half-duplex ("locked-keyboard") line-at-a-time terminals
-              for which the Go-Ahead mechanism was designed have largely
-              disappeared from the scene.  It turned out to be difficult
-              to implement sending the Go-Ahead signal in many operating
-              systems, even some systems that support native half-duplex
-              terminals.  The difficulty is typically that the Telnet
-              server code does not have access to information about
-              whether the user process is blocked awaiting input from
-              the Telnet connection, i.e., it cannot reliably determine
-              when to send a GA command.  Therefore, most Telnet Server
-              hosts do not send GA commands.
-
-              The effect of the rules in this section is to allow either
-              end of a Telnet connection to veto the use of GA commands.
-
-              There is a class of half-duplex terminals that is still
-              commercially important: "data entry terminals," which
-              interact in a full-screen manner.  However, supporting
-              data entry terminals using the Telnet protocol does not
-              require the Go Ahead signal; see Section 3.3.2.
-
-      3.2.3  Control Functions: RFC-854, pp. 7-8
-
-         The list of Telnet commands has been extended to include EOR
-         (End-of-Record), with code 239 [TELNET:9].
-
-         Both User and Server Telnets MAY support the control functions
-         EOR, EC, EL, and Break, and MUST support AO, AYT, DM, IP, NOP,
-         SB, and SE.
-
-         A host MUST be able to receive and ignore any Telnet control
-         functions that it does not support.
-
-         DISCUSSION:
-              Note that a Server Telnet is required to support the
-              Telnet IP (Interrupt Process) function, even if the server
-              host has an equivalent in-stream function (e.g., Control-C
-              in many systems).  The Telnet IP function may be stronger
-              than an in-stream interrupt command, because of the out-
-              of-band effect of TCP urgent data.
-
-              The EOR control function may be used to delimit the
-
-
-
-Internet Engineering Task Force                                [Page 17]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-              stream.  An important application is data entry terminal
-              support (see Section 3.3.2).  There was concern that since
-              EOR had not been defined in RFC-854, a host that was not
-              prepared to correctly ignore unknown Telnet commands might
-              crash if it received an EOR.  To protect such hosts, the
-              End-of-Record option [TELNET:9] was introduced; however, a
-              properly implemented Telnet program will not require this
-              protection.
-
-      3.2.4  Telnet "Synch" Signal: RFC-854, pp. 8-10
-
-         When it receives "urgent" TCP data, a User or Server Telnet
-         MUST discard all data except Telnet commands until the DM (and
-         end of urgent) is reached.
-
-         When it sends Telnet IP (Interrupt Process), a User Telnet
-         SHOULD follow it by the Telnet "Synch" sequence, i.e., send as
-         TCP urgent data the sequence "IAC IP IAC DM".  The TCP urgent
-         pointer points to the DM octet.
-
-         When it receives a Telnet IP command, a Server Telnet MAY send
-         a Telnet "Synch" sequence back to the user, to flush the output
-         stream.  The choice ought to be consistent with the way the
-         server operating system behaves when a local user interrupts a
-         process.
-
-         When it receives a Telnet AO command, a Server Telnet MUST send
-         a Telnet "Synch" sequence back to the user, to flush the output
-         stream.
-
-         A User Telnet SHOULD have the capability of flushing output
-         when it sends a Telnet IP; see also Section 3.4.5.
-
-         DISCUSSION:
-              There are three possible ways for a User Telnet to flush
-              the stream of server output data:
-
-              (1)  Send AO after IP.
-
-                   This will cause the server host to send a "flush-
-                   buffered-output" signal to its operating system.
-                   However, the AO may not take effect locally, i.e.,
-                   stop terminal output at the User Telnet end, until
-                   the Server Telnet has received and processed the AO
-                   and has sent back a "Synch".
-
-              (2)  Send DO TIMING-MARK [TELNET:7] after IP, and discard
-                   all output locally until a WILL/WONT TIMING-MARK is
-
-
-
-Internet Engineering Task Force                                [Page 18]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-                   received from the Server Telnet.
-
-                   Since the DO TIMING-MARK will be processed after the
-                   IP at the server, the reply to it should be in the
-                   right place in the output data stream.  However, the
-                   TIMING-MARK will not send a "flush buffered output"
-                   signal to the server operating system.  Whether or
-                   not this is needed is dependent upon the server
-                   system.
-
-              (3)  Do both.
-
-              The best method is not entirely clear, since it must
-              accommodate a number of existing server hosts that do not
-              follow the Telnet standards in various ways.  The safest
-              approach is probably to provide a user-controllable option
-              to select (1), (2), or (3).
-
-      3.2.5  NVT Printer and Keyboard: RFC-854, p. 11
-
-         In NVT mode, a Telnet SHOULD NOT send characters with the
-         high-order bit 1, and MUST NOT send it as a parity bit.
-         Implementations that pass the high-order bit to applications
-         SHOULD negotiate binary mode (see Section 3.2.6).
-
-
-         DISCUSSION:
-              Implementors should be aware that a strict reading of
-              RFC-854 allows a client or server expecting NVT ASCII to
-              ignore characters with the high-order bit set.  In
-              general, binary mode is expected to be used for
-              transmission of an extended (beyond 7-bit) character set
-              with Telnet.
-
-              However, there exist applications that really need an 8-
-              bit NVT mode, which is currently not defined, and these
-              existing applications do set the high-order bit during
-              part or all of the life of a Telnet connection.  Note that
-              binary mode is not the same as 8-bit NVT mode, since
-              binary mode turns off end-of-line processing.  For this
-              reason, the requirements on the high-order bit are stated
-              as SHOULD, not MUST.
-
-              RFC-854 defines a minimal set of properties of a "network
-              virtual terminal" or NVT; this is not meant to preclude
-              additional features in a real terminal.  A Telnet
-              connection is fully transparent to all 7-bit ASCII
-              characters, including arbitrary ASCII control characters.
-
-
-
-Internet Engineering Task Force                                [Page 19]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-              For example, a terminal might support full-screen commands
-              coded as ASCII escape sequences; a Telnet implementation
-              would pass these sequences as uninterpreted data.  Thus,
-              an NVT should not be conceived as a terminal type of a
-              highly-restricted device.
-
-      3.2.6  Telnet Command Structure: RFC-854, p. 13
-
-         Since options may appear at any point in the data stream, a
-         Telnet escape character (known as IAC, with the value 255) to
-         be sent as data MUST be doubled.
-
-      3.2.7  Telnet Binary Option: RFC-856
-
-         When the Binary option has been successfully negotiated,
-         arbitrary 8-bit characters are allowed.  However, the data
-         stream MUST still be scanned for IAC characters, any embedded
-         Telnet commands MUST be obeyed, and data bytes equal to IAC
-         MUST be doubled.  Other character processing (e.g., replacing
-         CR by CR NUL or by CR LF) MUST NOT be done.  In particular,
-         there is no end-of-line convention (see Section 3.3.1) in
-         binary mode.
-
-         DISCUSSION:
-              The Binary option is normally negotiated in both
-              directions, to change the Telnet connection from NVT mode
-              to "binary mode".
-
-              The sequence IAC EOR can be used to delimit blocks of data
-              within a binary-mode Telnet stream.
-
-      3.2.8  Telnet Terminal-Type Option: RFC-1091
-
-         The Terminal-Type option MUST use the terminal type names
-         officially defined in the Assigned Numbers RFC [INTRO:5], when
-         they are available for the particular terminal.  However, the
-         receiver of a Terminal-Type option MUST accept any name.
-
-         DISCUSSION:
-              RFC-1091 [TELNET:10] updates an earlier version of the
-              Terminal-Type option defined in RFC-930.  The earlier
-              version allowed a server host capable of supporting
-              multiple terminal types to learn the type of a particular
-              client's terminal, assuming that each physical terminal
-              had an intrinsic type.  However, today a "terminal" is
-              often really a terminal emulator program running in a PC,
-              perhaps capable of emulating a range of terminal types.
-              Therefore, RFC-1091 extends the specification to allow a
-
-
-
-Internet Engineering Task Force                                [Page 20]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-              more general terminal-type negotiation between User and
-              Server Telnets.
-
-   3.3  SPECIFIC ISSUES
-
-      3.3.1  Telnet End-of-Line Convention
-
-         The Telnet protocol defines the sequence CR LF to mean "end-
-         of-line".  For terminal input, this corresponds to a command-
-         completion or "end-of-line" key being pressed on a user
-         terminal; on an ASCII terminal, this is the CR key, but it may
-         also be labelled "Return" or "Enter".
-
-         When a Server Telnet receives the Telnet end-of-line sequence
-         CR LF as input from a remote terminal, the effect MUST be the
-         same as if the user had pressed the "end-of-line" key on a
-         local terminal.  On server hosts that use ASCII, in particular,
-         receipt of the Telnet sequence CR LF must cause the same effect
-         as a local user pressing the CR key on a local terminal.  Thus,
-         CR LF and CR NUL MUST have the same effect on an ASCII server
-         host when received as input over a Telnet connection.
-
-         A User Telnet MUST be able to send any of the forms: CR LF, CR
-         NUL, and LF.  A User Telnet on an ASCII host SHOULD have a
-         user-controllable mode to send either CR LF or CR NUL when the
-         user presses the "end-of-line" key, and CR LF SHOULD be the
-         default.
-
-         The Telnet end-of-line sequence CR LF MUST be used to send
-         Telnet data that is not terminal-to-computer (e.g., for Server
-         Telnet sending output, or the Telnet protocol incorporated
-         another application protocol).
-
-         DISCUSSION:
-              To allow interoperability between arbitrary Telnet clients
-              and servers, the Telnet protocol defined a standard
-              representation for a line terminator.  Since the ASCII
-              character set includes no explicit end-of-line character,
-              systems have chosen various representations, e.g., CR, LF,
-              and the sequence CR LF.  The Telnet protocol chose the CR
-              LF sequence as the standard for network transmission.
-
-              Unfortunately, the Telnet protocol specification in RFC-
-              854 [TELNET:1] has turned out to be somewhat ambiguous on
-              what character(s) should be sent from client to server for
-              the "end-of-line" key.  The result has been a massive and
-              continuing interoperability headache, made worse by
-              various faulty implementations of both User and Server
-
-
-
-Internet Engineering Task Force                                [Page 21]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-              Telnets.
-
-              Although the Telnet protocol is based on a perfectly
-              symmetric model, in a remote login session the role of the
-              user at a terminal differs from the role of the server
-              host.  For example, RFC-854 defines the meaning of CR, LF,
-              and CR LF as output from the server, but does not specify
-              what the User Telnet should send when the user presses the
-              "end-of-line" key on the terminal; this turns out to be
-              the point at issue.
-
-              When a user presses the "end-of-line" key, some User
-              Telnet implementations send CR LF, while others send CR
-              NUL (based on a different interpretation of the same
-              sentence in RFC-854).  These will be equivalent for a
-              correctly-implemented ASCII server host, as discussed
-              above.  For other servers, a mode in the User Telnet is
-              needed.
-
-              The existence of User Telnets that send only CR NUL when
-              CR is pressed creates a dilemma for non-ASCII hosts: they
-              can either treat CR NUL as equivalent to CR LF in input,
-              thus precluding the possibility of entering a "bare" CR,
-              or else lose complete interworking.
-
-              Suppose a user on host A uses Telnet to log into a server
-              host B, and then execute B's User Telnet program to log
-              into server host C.  It is desirable for the Server/User
-              Telnet combination on B to be as transparent as possible,
-              i.e., to appear as if A were connected directly to C.  In
-              particular, correct implementation will make B transparent
-              to Telnet end-of-line sequences, except that CR LF may be
-              translated to CR NUL or vice versa.
-
-         IMPLEMENTATION:
-              To understand Telnet end-of-line issues, one must have at
-              least a general model of the relationship of Telnet to the
-              local operating system.  The Server Telnet process is
-              typically coupled into the terminal driver software of the
-              operating system as a pseudo-terminal.  A Telnet end-of-
-              line sequence received by the Server Telnet must have the
-              same effect as pressing the end-of-line key on a real
-              locally-connected terminal.
-
-              Operating systems that support interactive character-at-
-              a-time applications (e.g., editors) typically have two
-              internal modes for their terminal I/O: a formatted mode,
-              in which local conventions for end-of-line and other
-
-
-
-Internet Engineering Task Force                                [Page 22]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-              formatting rules have been applied to the data stream, and
-              a "raw" mode, in which the application has direct access
-              to every character as it was entered.  A Server Telnet
-              must be implemented in such a way that these modes have
-              the same effect for remote as for local terminals.  For
-              example, suppose a CR LF or CR NUL is received by the
-              Server Telnet on an ASCII host.  In raw mode, a CR
-              character is passed to the application; in formatted mode,
-              the local system's end-of-line convention is used.
-
-      3.3.2  Data Entry Terminals
-
-         DISCUSSION:
-              In addition to the line-oriented and character-oriented
-              ASCII terminals for which Telnet was designed, there are
-              several families of video display terminals that are
-              sometimes known as "data entry terminals" or DETs.  The
-              IBM 3270 family is a well-known example.
-
-              Two Internet protocols have been designed to support
-              generic DETs: SUPDUP [TELNET:16, TELNET:17], and the DET
-              option [TELNET:18, TELNET:19].  The DET option drives a
-              data entry terminal over a Telnet connection using (sub-)
-              negotiation.  SUPDUP is a completely separate terminal
-              protocol, which can be entered from Telnet by negotiation.
-              Although both SUPDUP and the DET option have been used
-              successfully in particular environments, neither has
-              gained general acceptance or wide implementation.
-
-              A different approach to DET interaction has been developed
-              for supporting the IBM 3270 family through Telnet,
-              although the same approach would be applicable to any DET.
-              The idea is to enter a "native DET" mode, in which the
-              native DET input/output stream is sent as binary data.
-              The Telnet EOR command is used to delimit logical records
-              (e.g., "screens") within this binary stream.
-
-         IMPLEMENTATION:
-              The rules for entering and leaving native DET mode are as
-              follows:
-
-              o    The Server uses the Terminal-Type option [TELNET:10]
-                   to learn that the client is a DET.
-
-              o    It is conventional, but not required, that both ends
-                   negotiate the EOR option [TELNET:9].
-
-              o    Both ends negotiate the Binary option [TELNET:3] to
-
-
-
-Internet Engineering Task Force                                [Page 23]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-                   enter native DET mode.
-
-              o    When either end negotiates out of binary mode, the
-                   other end does too, and the mode then reverts to
-                   normal NVT.
-
-
-      3.3.3  Option Requirements
-
-         Every Telnet implementation MUST support the Binary option
-         [TELNET:3] and the Suppress Go Ahead option [TELNET:5], and
-         SHOULD support the Echo [TELNET:4], Status [TELNET:6], End-of-
-         Record [TELNET:9], and Extended Options List [TELNET:8]
-         options.
-
-         A User or Server Telnet SHOULD support the Window Size Option
-         [TELNET:12] if the local operating system provides the
-         corresponding capability.
-
-         DISCUSSION:
-              Note that the End-of-Record option only signifies that a
-              Telnet can receive a Telnet EOR without crashing;
-              therefore, every Telnet ought to be willing to accept
-              negotiation of the End-of-Record option.  See also the
-              discussion in Section 3.2.3.
-
-      3.3.4  Option Initiation
-
-         When the Telnet protocol is used in a client/server situation,
-         the server SHOULD initiate negotiation of the terminal
-         interaction mode it expects.
-
-         DISCUSSION:
-              The Telnet protocol was defined to be perfectly
-              symmetrical, but its application is generally asymmetric.
-              Remote login has been known to fail because NEITHER side
-              initiated negotiation of the required non-default terminal
-              modes.  It is generally the server that determines the
-              preferred mode, so the server needs to initiate the
-              negotiation; since the negotiation is symmetric, the user
-              can also initiate it.
-
-         A client (User Telnet) SHOULD provide a means for users to
-         enable and disable the initiation of option negotiation.
-
-         DISCUSSION:
-              A user sometimes needs to connect to an application
-              service (e.g., FTP or SMTP) that uses Telnet for its
-
-
-
-Internet Engineering Task Force                                [Page 24]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-              control stream but does not support Telnet options.  User
-              Telnet may be used for this purpose if initiation of
-              option negotiation is  disabled.
-
-      3.3.5  Telnet Linemode Option
-
-         DISCUSSION:
-              An important new Telnet option, LINEMODE [TELNET:12], has
-              been proposed.  The LINEMODE option provides a standard
-              way for a User Telnet and a Server Telnet to agree that
-              the client rather than the server will perform terminal
-              character processing.  When the client has prepared a
-              complete line of text, it will send it to the server in
-              (usually) one TCP packet.  This option will greatly
-              decrease the packet cost of Telnet sessions and will also
-              give much better user response over congested or long-
-              delay networks.
-
-              The LINEMODE option allows dynamic switching between local
-              and remote character processing.  For example, the Telnet
-              connection will automatically negotiate into single-
-              character mode while a full screen editor is running, and
-              then return to linemode when the editor is finished.
-
-              We expect that when this RFC is released, hosts should
-              implement the client side of this option, and may
-              implement the server side of this option.  To properly
-              implement the server side, the server needs to be able to
-              tell the local system not to do any input character
-              processing, but to remember its current terminal state and
-              notify the Server Telnet process whenever the state
-              changes.  This will allow password echoing and full screen
-              editors to be handled properly, for example.
-
-   3.4  TELNET/USER INTERFACE
-
-      3.4.1  Character Set Transparency
-
-         User Telnet implementations SHOULD be able to send or receive
-         any 7-bit ASCII character.  Where possible, any special
-         character interpretations by the user host's operating system
-         SHOULD be bypassed so that these characters can conveniently be
-         sent and received on the connection.
-
-         Some character value MUST be reserved as "escape to command
-         mode"; conventionally, doubling this character allows it to be
-         entered as data.  The specific character used SHOULD be user
-         selectable.
-
-
-
-Internet Engineering Task Force                                [Page 25]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-         On binary-mode connections, a User Telnet program MAY provide
-         an escape mechanism for entering arbitrary 8-bit values, if the
-         host operating system doesn't allow them to be entered directly
-         from the keyboard.
-
-         IMPLEMENTATION:
-              The transparency issues are less pressing on servers, but
-              implementors should take care in dealing with issues like:
-              masking off parity bits (sent by an older, non-conforming
-              client) before they reach programs that expect only NVT
-              ASCII, and properly handling programs that request 8-bit
-              data streams.
-
-      3.4.2  Telnet Commands
-
-         A User Telnet program MUST provide a user the capability of
-         entering any of the Telnet control functions IP, AO, or AYT,
-         and SHOULD provide the capability of entering EC, EL, and
-         Break.
-
-      3.4.3  TCP Connection Errors
-
-         A User Telnet program SHOULD report to the user any TCP errors
-         that are reported by the transport layer (see "TCP/Application
-         Layer Interface" section in [INTRO:1]).
-
-      3.4.4  Non-Default Telnet Contact Port
-
-         A User Telnet program SHOULD allow the user to optionally
-         specify a non-standard contact port number at the Server Telnet
-         host.
-
-      3.4.5  Flushing Output
-
-         A User Telnet program SHOULD provide the user the ability to
-         specify whether or not output should be flushed when an IP is
-         sent; see Section 3.2.4.
-
-         For any output flushing scheme that causes the User Telnet to
-         flush output locally until a Telnet signal is received from the
-         Server, there SHOULD be a way for the user to manually restore
-         normal output, in case the Server fails to send the expected
-         signal.
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 26]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-   3.5.  TELNET REQUIREMENTS SUMMARY
-
-
-                                                 |        | | | |S| |
-                                                 |        | | | |H| |F
-                                                 |        | | | |O|M|o
-                                                 |        | |S| |U|U|o
-                                                 |        | |H| |L|S|t
-                                                 |        |M|O| |D|T|n
-                                                 |        |U|U|M| | |o
-                                                 |        |S|L|A|N|N|t
-                                                 |        |T|D|Y|O|O|t
-FEATURE                                          |SECTION | | | |T|T|e
--------------------------------------------------|--------|-|-|-|-|-|--
-                                                 |        | | | | | |
-Option Negotiation                               |3.2.1   |x| | | | |
-  Avoid negotiation loops                        |3.2.1   |x| | | | |
-  Refuse unsupported options                     |3.2.1   |x| | | | |
-  Negotiation OK anytime on connection           |3.2.1   | |x| | | |
-  Default to NVT                                 |3.2.1   |x| | | | |
-  Send official name in Term-Type option         |3.2.8   |x| | | | |
-  Accept any name in Term-Type option            |3.2.8   |x| | | | |
-  Implement Binary, Suppress-GA options          |3.3.3   |x| | | | |
-  Echo, Status, EOL, Ext-Opt-List options        |3.3.3   | |x| | | |
-  Implement Window-Size option if appropriate    |3.3.3   | |x| | | |
-  Server initiate mode negotiations              |3.3.4   | |x| | | |
-  User can enable/disable init negotiations      |3.3.4   | |x| | | |
-                                                 |        | | | | | |
-Go-Aheads                                        |        | | | | | |
-  Non-GA server negotiate SUPPRESS-GA option     |3.2.2   |x| | | | |
-  User or Server accept SUPPRESS-GA option       |3.2.2   |x| | | | |
-  User Telnet ignore GA's                        |3.2.2   | | |x| | |
-                                                 |        | | | | | |
-Control Functions                                |        | | | | | |
-  Support SE NOP DM IP AO AYT SB                 |3.2.3   |x| | | | |
-  Support EOR EC EL Break                        |3.2.3   | | |x| | |
-  Ignore unsupported control functions           |3.2.3   |x| | | | |
-  User, Server discard urgent data up to DM      |3.2.4   |x| | | | |
-  User Telnet send "Synch" after IP, AO, AYT     |3.2.4   | |x| | | |
-  Server Telnet reply Synch to IP                |3.2.4   | | |x| | |
-  Server Telnet reply Synch to AO                |3.2.4   |x| | | | |
-  User Telnet can flush output when send IP      |3.2.4   | |x| | | |
-                                                 |        | | | | | |
-Encoding                                         |        | | | | | |
-  Send high-order bit in NVT mode                |3.2.5   | | | |x| |
-  Send high-order bit as parity bit              |3.2.5   | | | | |x|
-  Negot. BINARY if pass high-ord. bit to applic  |3.2.5   | |x| | | |
-  Always double IAC data byte                    |3.2.6   |x| | | | |
-
-
-
-Internet Engineering Task Force                                [Page 27]
-
-
-
-
-RFC1123                  REMOTE LOGIN -- TELNET             October 1989
-
-
-  Double IAC data byte in binary mode            |3.2.7   |x| | | | |
-  Obey Telnet cmds in binary mode                |3.2.7   |x| | | | |
-  End-of-line, CR NUL in binary mode             |3.2.7   | | | | |x|
-                                                 |        | | | | | |
-End-of-Line                                      |        | | | | | |
-  EOL at Server same as local end-of-line        |3.3.1   |x| | | | |
-  ASCII Server accept CR LF or CR NUL for EOL    |3.3.1   |x| | | | |
-  User Telnet able to send CR LF, CR NUL, or LF  |3.3.1   |x| | | | |
-    ASCII user able to select CR LF/CR NUL       |3.3.1   | |x| | | |
-    User Telnet default mode is CR LF            |3.3.1   | |x| | | |
-  Non-interactive uses CR LF for EOL             |3.3.1   |x| | | | |
-                                                 |        | | | | | |
-User Telnet interface                            |        | | | | | |
-  Input & output all 7-bit characters            |3.4.1   | |x| | | |
-  Bypass local op sys interpretation             |3.4.1   | |x| | | |
-  Escape character                               |3.4.1   |x| | | | |
-     User-settable escape character              |3.4.1   | |x| | | |
-  Escape to enter 8-bit values                   |3.4.1   | | |x| | |
-  Can input IP, AO, AYT                          |3.4.2   |x| | | | |
-  Can input EC, EL, Break                        |3.4.2   | |x| | | |
-  Report TCP connection errors to user           |3.4.3   | |x| | | |
-  Optional non-default contact port              |3.4.4   | |x| | | |
-  Can spec: output flushed when IP sent          |3.4.5   | |x| | | |
-  Can manually restore output mode               |3.4.5   | |x| | | |
-                                                 |        | | | | | |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 28]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-4.  FILE TRANSFER
-
-   4.1  FILE TRANSFER PROTOCOL -- FTP
-
-      4.1.1  INTRODUCTION
-
-         The File Transfer Protocol FTP is the primary Internet standard
-         for file transfer.  The current specification is contained in
-         RFC-959 [FTP:1].
-
-         FTP uses separate simultaneous TCP connections for control and
-         for data transfer.  The FTP protocol includes many features,
-         some of which are not commonly implemented.  However, for every
-         feature in FTP, there exists at least one implementation.  The
-         minimum implementation defined in RFC-959 was too small, so a
-         somewhat larger minimum implementation is defined here.
-
-         Internet users have been unnecessarily burdened for years by
-         deficient FTP implementations.  Protocol implementors have
-         suffered from the erroneous opinion that implementing FTP ought
-         to be a small and trivial task.  This is wrong, because FTP has
-         a user interface, because it has to deal (correctly) with the
-         whole variety of communication and operating system errors that
-         may occur, and because it has to handle the great diversity of
-         real file systems in the world.
-
-      4.1.2.  PROTOCOL WALK-THROUGH
-
-         4.1.2.1  LOCAL Type: RFC-959 Section 3.1.1.4
-
-            An FTP program MUST support TYPE I ("IMAGE" or binary type)
-            as well as TYPE L 8 ("LOCAL" type with logical byte size 8).
-            A machine whose memory is organized into m-bit words, where
-            m is not a multiple of 8, MAY also support TYPE L m.
-
-            DISCUSSION:
-                 The command "TYPE L 8" is often required to transfer
-                 binary data between a machine whose memory is organized
-                 into (e.g.) 36-bit words and a machine with an 8-bit
-                 byte organization.  For an 8-bit byte machine, TYPE L 8
-                 is equivalent to IMAGE.
-
-                 "TYPE L m" is sometimes specified to the FTP programs
-                 on two m-bit word machines to ensure the correct
-                 transfer of a native-mode binary file from one machine
-                 to the other.  However, this command should have the
-                 same effect on these machines as "TYPE I".
-
-
-
-
-Internet Engineering Task Force                                [Page 29]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-         4.1.2.2  Telnet Format Control: RFC-959 Section 3.1.1.5.2
-
-            A host that makes no distinction between TYPE N and TYPE T
-            SHOULD implement TYPE T to be identical to TYPE N.
-
-            DISCUSSION:
-                 This provision should ease interoperation with hosts
-                 that do make this distinction.
-
-                 Many hosts represent text files internally as strings
-                 of ASCII characters, using the embedded ASCII format
-                 effector characters (LF, BS, FF, ...) to control the
-                 format when a file is printed.  For such hosts, there
-                 is no distinction between "print" files and other
-                 files.  However, systems that use record structured
-                 files typically need a special format for printable
-                 files (e.g., ASA carriage control).   For the latter
-                 hosts, FTP allows a choice of TYPE N or TYPE T.
-
-         4.1.2.3  Page Structure: RFC-959 Section 3.1.2.3 and Appendix I
-
-            Implementation of page structure is NOT RECOMMENDED in
-            general. However, if a host system does need to implement
-            FTP for "random access" or "holey" files, it MUST use the
-            defined page structure format rather than define a new
-            private FTP format.
-
-         4.1.2.4  Data Structure Transformations: RFC-959 Section 3.1.2
-
-            An FTP transformation between record-structure and file-
-            structure SHOULD be invertible, to the extent possible while
-            making the result useful on the target host.
-
-            DISCUSSION:
-                 RFC-959 required strict invertibility between record-
-                 structure and file-structure, but in practice,
-                 efficiency and convenience often preclude it.
-                 Therefore, the requirement is being relaxed.  There are
-                 two different objectives for transferring a file:
-                 processing it on the target host, or just storage.  For
-                 storage, strict invertibility is important.  For
-                 processing, the file created on the target host needs
-                 to be in the format expected by application programs on
-                 that host.
-
-                 As an example of the conflict, imagine a record-
-                 oriented operating system that requires some data files
-                 to have exactly 80 bytes in each record.  While STORing
-
-
-
-Internet Engineering Task Force                                [Page 30]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-                 a file on such a host, an FTP Server must be able to
-                 pad each line or record to 80 bytes; a later retrieval
-                 of such a file cannot be strictly invertible.
-
-         4.1.2.5  Data Connection Management: RFC-959 Section 3.3
-
-            A User-FTP that uses STREAM mode SHOULD send a PORT command
-            to assign a non-default data port before each transfer
-            command is issued.
-
-            DISCUSSION:
-                 This is required because of the long delay after a TCP
-                 connection is closed until its socket pair can be
-                 reused, to allow multiple transfers during a single FTP
-                 session.  Sending a port command can avoided if a
-                 transfer mode other than stream is used, by leaving the
-                 data transfer connection open between transfers.
-
-         4.1.2.6  PASV Command: RFC-959 Section 4.1.2
-
-            A server-FTP MUST implement the PASV command.
-
-            If multiple third-party transfers are to be executed during
-            the same session, a new PASV command MUST be issued before
-            each transfer command, to obtain a unique port pair.
-
-            IMPLEMENTATION:
-                 The format of the 227 reply to a PASV command is not
-                 well standardized.  In particular, an FTP client cannot
-                 assume that the parentheses shown on page 40 of RFC-959
-                 will be present (and in fact, Figure 3 on page 43 omits
-                 them).  Therefore, a User-FTP program that interprets
-                 the PASV reply must scan the reply for the first digit
-                 of the host and port numbers.
-
-                 Note that the host number h1,h2,h3,h4 is the IP address
-                 of the server host that is sending the reply, and that
-                 p1,p2 is a non-default data transfer port that PASV has
-                 assigned.
-
-         4.1.2.7  LIST and NLST Commands: RFC-959 Section 4.1.3
-
-            The data returned by an NLST command MUST contain only a
-            simple list of legal pathnames, such that the server can use
-            them directly as the arguments of subsequent data transfer
-            commands for the individual files.
-
-            The data returned by a LIST or NLST command SHOULD use an
-
-
-
-Internet Engineering Task Force                                [Page 31]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-            implied TYPE AN, unless the current type is EBCDIC, in which
-            case an implied TYPE EN SHOULD be used.
-
-            DISCUSSION:
-                 Many FTP clients support macro-commands that will get
-                 or put files matching a wildcard specification, using
-                 NLST to obtain a list of pathnames.  The expansion of
-                 "multiple-put" is local to the client, but "multiple-
-                 get" requires cooperation by the server.
-
-                 The implied type for LIST and NLST is designed to
-                 provide compatibility with existing User-FTPs, and in
-                 particular with multiple-get commands.
-
-         4.1.2.8  SITE Command: RFC-959 Section 4.1.3
-
-            A Server-FTP SHOULD use the SITE command for non-standard
-            features, rather than invent new private commands or
-            unstandardized extensions to existing commands.
-
-         4.1.2.9  STOU Command: RFC-959 Section 4.1.3
-
-            The STOU command stores into a uniquely named file.  When it
-            receives an STOU command, a Server-FTP MUST return the
-            actual file name in the "125 Transfer Starting" or the "150
-            Opening Data Connection" message that precedes the transfer
-            (the 250 reply code mentioned in RFC-959 is incorrect).  The
-            exact format of these messages is hereby defined to be as
-            follows:
-
-                125 FILE: pppp
-                150 FILE: pppp
-
-            where pppp represents the unique pathname of the file that
-            will be written.
-
-         4.1.2.10  Telnet End-of-line Code: RFC-959, Page 34
-
-            Implementors MUST NOT assume any correspondence between READ
-            boundaries on the control connection and the Telnet EOL
-            sequences (CR LF).
-
-            DISCUSSION:
-                 Thus, a server-FTP (or User-FTP) must continue reading
-                 characters from the control connection until a complete
-                 Telnet EOL sequence is encountered, before processing
-                 the command (or response, respectively).  Conversely, a
-                 single READ from the control connection may include
-
-
-
-Internet Engineering Task Force                                [Page 32]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-                 more than one FTP command.
-
-         4.1.2.11  FTP Replies: RFC-959 Section 4.2, Page 35
-
-            A Server-FTP MUST send only correctly formatted replies on
-            the control connection.  Note that RFC-959 (unlike earlier
-            versions of the FTP spec) contains no provision for a
-            "spontaneous" reply message.
-
-            A Server-FTP SHOULD use the reply codes defined in RFC-959
-            whenever they apply.  However, a server-FTP MAY use a
-            different reply code when needed, as long as the general
-            rules of Section 4.2 are followed. When the implementor has
-            a choice between a 4xx and 5xx reply code, a Server-FTP
-            SHOULD send a 4xx (temporary failure) code when there is any
-            reasonable possibility that a failed FTP will succeed a few
-            hours later.
-
-            A User-FTP SHOULD generally use only the highest-order digit
-            of a 3-digit reply code for making a procedural decision, to
-            prevent difficulties when a Server-FTP uses non-standard
-            reply codes.
-
-            A User-FTP MUST be able to handle multi-line replies.  If
-            the implementation imposes a limit on the number of lines
-            and if this limit is exceeded, the User-FTP MUST recover,
-            e.g., by ignoring the excess lines until the end of the
-            multi-line reply is reached.
-
-            A User-FTP SHOULD NOT interpret a 421 reply code ("Service
-            not available, closing control connection") specially, but
-            SHOULD detect closing of the control connection by the
-            server.
-
-            DISCUSSION:
-                 Server implementations that fail to strictly follow the
-                 reply rules often cause FTP user programs to hang.
-                 Note that RFC-959 resolved ambiguities in the reply
-                 rules found in earlier FTP specifications and must be
-                 followed.
-
-                 It is important to choose FTP reply codes that properly
-                 distinguish between temporary and permanent failures,
-                 to allow the successful use of file transfer client
-                 daemons.  These programs depend on the reply codes to
-                 decide whether or not to retry a failed transfer; using
-                 a permanent failure code (5xx) for a temporary error
-                 will cause these programs to give up unnecessarily.
-
-
-
-Internet Engineering Task Force                                [Page 33]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-                 When the meaning of a reply matches exactly the text
-                 shown in RFC-959, uniformity will be enhanced by using
-                 the RFC-959 text verbatim.  However, a Server-FTP
-                 implementor is encouraged to choose reply text that
-                 conveys specific system-dependent information, when
-                 appropriate.
-
-         4.1.2.12  Connections: RFC-959 Section 5.2
-
-            The words "and the port used" in the second paragraph of
-            this section of RFC-959 are erroneous (historical), and they
-            should be ignored.
-
-            On a multihomed server host, the default data transfer port
-            (L-1) MUST be associated with the same local IP address as
-            the corresponding control connection to port L.
-
-            A user-FTP MUST NOT send any Telnet controls other than
-            SYNCH and IP on an FTP control connection. In particular, it
-            MUST NOT attempt to negotiate Telnet options on the control
-            connection.  However, a server-FTP MUST be capable of
-            accepting and refusing Telnet negotiations (i.e., sending
-            DONT/WONT).
-
-            DISCUSSION:
-                 Although the RFC says: "Server- and User- processes
-                 should follow the conventions for the Telnet
-                 protocol...[on the control connection]", it is not the
-                 intent that Telnet option negotiation is to be
-                 employed.
-
-         4.1.2.13  Minimum Implementation; RFC-959 Section 5.1
-
-            The following commands and options MUST be supported by
-            every server-FTP and user-FTP, except in cases where the
-            underlying file system or operating system does not allow or
-            support a particular command.
-
-                 Type: ASCII Non-print, IMAGE, LOCAL 8
-                 Mode: Stream
-                 Structure: File, Record*
-                 Commands:
-                    USER, PASS, ACCT,
-                    PORT, PASV,
-                    TYPE, MODE, STRU,
-                    RETR, STOR, APPE,
-                    RNFR, RNTO, DELE,
-                    CWD,  CDUP, RMD,  MKD,  PWD,
-
-
-
-Internet Engineering Task Force                                [Page 34]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-                    LIST, NLST,
-                    SYST, STAT,
-                    HELP, NOOP, QUIT.
-
-            *Record structure is REQUIRED only for hosts whose file
-            systems support record structure.
-
-            DISCUSSION:
-                 Vendors are encouraged to implement a larger subset of
-                 the protocol.  For example, there are important
-                 robustness features in the protocol (e.g., Restart,
-                 ABOR, block mode) that would be an aid to some Internet
-                 users but are not widely implemented.
-
-                 A host that does not have record structures in its file
-                 system may still accept files with STRU R, recording
-                 the byte stream literally.
-
-      4.1.3  SPECIFIC ISSUES
-
-         4.1.3.1  Non-standard Command Verbs
-
-            FTP allows "experimental" commands, whose names begin with
-            "X".  If these commands are subsequently adopted as
-            standards, there may still be existing implementations using
-            the "X" form.  At present, this is true for the directory
-            commands:
-
-                RFC-959   "Experimental"
-
-                  MKD        XMKD
-                  RMD        XRMD
-                  PWD        XPWD
-                  CDUP       XCUP
-                  CWD        XCWD
-
-            All FTP implementations SHOULD recognize both forms of these
-            commands, by simply equating them with extra entries in the
-            command lookup table.
-
-            IMPLEMENTATION:
-                 A User-FTP can access a server that supports only the
-                 "X" forms by implementing a mode switch, or
-                 automatically using the following procedure: if the
-                 RFC-959 form of one of the above commands is rejected
-                 with a 500 or 502 response code, then try the
-                 experimental form; any other response would be passed
-                 to the user.
-
-
-
-Internet Engineering Task Force                                [Page 35]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-         4.1.3.2  Idle Timeout
-
-            A Server-FTP process SHOULD have an idle timeout, which will
-            terminate the process and close the control connection if
-            the server is inactive (i.e., no command or data transfer in
-            progress) for a long period of time.  The idle timeout time
-            SHOULD be configurable, and the default should be at least 5
-            minutes.
-
-            A client FTP process ("User-PI" in RFC-959) will need
-            timeouts on responses only if it is invoked from a program.
-
-            DISCUSSION:
-                 Without a timeout, a Server-FTP process may be left
-                 pending indefinitely if the corresponding client
-                 crashes without closing the control connection.
-
-         4.1.3.3  Concurrency of Data and Control
-
-            DISCUSSION:
-                 The intent of the designers of FTP was that a user
-                 should be able to send a STAT command at any time while
-                 data transfer was in progress and that the server-FTP
-                 would reply immediately with status -- e.g., the number
-                 of bytes transferred so far.  Similarly, an ABOR
-                 command should be possible at any time during a data
-                 transfer.
-
-                 Unfortunately, some small-machine operating systems
-                 make such concurrent programming difficult, and some
-                 other implementers seek minimal solutions, so some FTP
-                 implementations do not allow concurrent use of the data
-                 and control connections.  Even such a minimal server
-                 must be prepared to accept and defer a STAT or ABOR
-                 command that arrives during data transfer.
-
-         4.1.3.4  FTP Restart Mechanism
-
-            The description of the 110 reply on pp. 40-41 of RFC-959 is
-            incorrect; the correct description is as follows.  A restart
-            reply message, sent over the control connection from the
-            receiving FTP to the User-FTP, has the format:
-
-                110 MARK ssss = rrrr
-
-            Here:
-
-            *    ssss is a text string that appeared in a Restart Marker
-
-
-
-Internet Engineering Task Force                                [Page 36]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-                 in the data stream and encodes a position in the
-                 sender's file system;
-
-            *    rrrr encodes the corresponding position in the
-                 receiver's file system.
-
-            The encoding, which is specific to a particular file system
-            and network implementation, is always generated and
-            interpreted by the same system, either sender or receiver.
-
-            When an FTP that implements restart receives a Restart
-            Marker in the data stream, it SHOULD force the data to that
-            point to be written to stable storage before encoding the
-            corresponding position rrrr.  An FTP sending Restart Markers
-            MUST NOT assume that 110 replies will be returned
-            synchronously with the data, i.e., it must not await a 110
-            reply before sending more data.
-
-            Two new reply codes are hereby defined for errors
-            encountered in restarting a transfer:
-
-              554 Requested action not taken: invalid REST parameter.
-
-                 A 554 reply may result from a FTP service command that
-                 follows a REST command.  The reply indicates that the
-                 existing file at the Server-FTP cannot be repositioned
-                 as specified in the REST.
-
-              555 Requested action not taken: type or stru mismatch.
-
-                 A 555 reply may result from an APPE command or from any
-                 FTP service command following a REST command.  The
-                 reply indicates that there is some mismatch between the
-                 current transfer parameters (type and stru) and the
-                 attributes of the existing file.
-
-            DISCUSSION:
-                 Note that the FTP Restart mechanism requires that Block
-                 or Compressed mode be used for data transfer, to allow
-                 the Restart Markers to be included within the data
-                 stream.  The frequency of Restart Markers can be low.
-
-                 Restart Markers mark a place in the data stream, but
-                 the receiver may be performing some transformation on
-                 the data as it is stored into stable storage.  In
-                 general, the receiver's encoding must include any state
-                 information necessary to restart this transformation at
-                 any point of the FTP data stream.  For example, in TYPE
-
-
-
-Internet Engineering Task Force                                [Page 37]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-                 A transfers, some receiver hosts transform CR LF
-                 sequences into a single LF character on disk.   If a
-                 Restart Marker happens to fall between CR and LF, the
-                 receiver must encode in rrrr that the transfer must be
-                 restarted in a "CR has been seen and discarded" state.
-
-                 Note that the Restart Marker is required to be encoded
-                 as a string of printable ASCII characters, regardless
-                 of the type of the data.
-
-                 RFC-959 says that restart information is to be returned
-                 "to the user".  This should not be taken literally.  In
-                 general, the User-FTP should save the restart
-                 information (ssss,rrrr) in stable storage, e.g., append
-                 it to a restart control file.  An empty restart control
-                 file should be created when the transfer first starts
-                 and deleted automatically when the transfer completes
-                 successfully.  It is suggested that this file have a
-                 name derived in an easily-identifiable manner from the
-                 name of the file being transferred and the remote host
-                 name; this is analogous to the means used by many text
-                 editors for naming "backup" files.
-
-                 There are three cases for FTP restart.
-
-                 (1)  User-to-Server Transfer
-
-                      The User-FTP puts Restart Markers <ssss> at
-                      convenient places in the data stream.  When the
-                      Server-FTP receives a Marker, it writes all prior
-                      data to disk, encodes its file system position and
-                      transformation state as rrrr, and returns a "110
-                      MARK ssss = rrrr" reply over the control
-                      connection.  The User-FTP appends the pair
-                      (ssss,rrrr) to its restart control file.
-
-                      To restart the transfer, the User-FTP fetches the
-                      last (ssss,rrrr) pair from the restart control
-                      file, repositions its local file system and
-                      transformation state using ssss, and sends the
-                      command "REST rrrr" to the Server-FTP.
-
-                 (2)  Server-to-User Transfer
-
-                      The Server-FTP puts Restart Markers <ssss> at
-                      convenient places in the data stream.  When the
-                      User-FTP receives a Marker, it writes all prior
-                      data to disk, encodes its file system position and
-
-
-
-Internet Engineering Task Force                                [Page 38]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-                      transformation state as rrrr, and appends the pair
-                      (rrrr,ssss) to its restart control file.
-
-                      To restart the transfer, the User-FTP fetches the
-                      last (rrrr,ssss) pair from the restart control
-                      file, repositions its local file system and
-                      transformation state using rrrr, and sends the
-                      command "REST ssss" to the Server-FTP.
-
-                 (3)  Server-to-Server ("Third-Party") Transfer
-
-                      The sending Server-FTP puts Restart Markers <ssss>
-                      at convenient places in the data stream.  When it
-                      receives a Marker, the receiving Server-FTP writes
-                      all prior data to disk, encodes its file system
-                      position and transformation state as rrrr, and
-                      sends a "110 MARK ssss = rrrr" reply over the
-                      control connection to the User.  The User-FTP
-                      appends the pair (ssss,rrrr) to its restart
-                      control file.
-
-                      To restart the transfer, the User-FTP fetches the
-                      last (ssss,rrrr) pair from the restart control
-                      file, sends "REST ssss" to the sending Server-FTP,
-                      and sends "REST rrrr" to the receiving Server-FTP.
-
-
-      4.1.4  FTP/USER INTERFACE
-
-         This section discusses the user interface for a User-FTP
-         program.
-
-         4.1.4.1  Pathname Specification
-
-            Since FTP is intended for use in a heterogeneous
-            environment, User-FTP implementations MUST support remote
-            pathnames as arbitrary character strings, so that their form
-            and content are not limited by the conventions of the local
-            operating system.
-
-            DISCUSSION:
-                 In particular, remote pathnames can be of arbitrary
-                 length, and all the printing ASCII characters as well
-                 as space (0x20) must be allowed.  RFC-959 allows a
-                 pathname to contain any 7-bit ASCII character except CR
-                 or LF.
-
-
-
-
-
-Internet Engineering Task Force                                [Page 39]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-         4.1.4.2  "QUOTE" Command
-
-            A User-FTP program MUST implement a "QUOTE" command that
-            will pass an arbitrary character string to the server and
-            display all resulting response messages to the user.
-
-            To make the "QUOTE" command useful, a User-FTP SHOULD send
-            transfer control commands to the server as the user enters
-            them, rather than saving all the commands and sending them
-            to the server only when a data transfer is started.
-
-            DISCUSSION:
-                 The "QUOTE" command is essential to allow the user to
-                 access servers that require system-specific commands
-                 (e.g., SITE or ALLO), or to invoke new or optional
-                 features that are not implemented by the User-FTP.  For
-                 example, "QUOTE" may be used to specify "TYPE A T" to
-                 send a print file to hosts that require the
-                 distinction, even if the User-FTP does not recognize
-                 that TYPE.
-
-         4.1.4.3  Displaying Replies to User
-
-            A User-FTP SHOULD display to the user the full text of all
-            error reply messages it receives.  It SHOULD have a
-            "verbose" mode in which all commands it sends and the full
-            text and reply codes it receives are displayed, for
-            diagnosis of problems.
-
-         4.1.4.4  Maintaining Synchronization
-
-            The state machine in a User-FTP SHOULD be forgiving of
-            missing and unexpected reply messages, in order to maintain
-            command synchronization with the server.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 40]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-      4.1.5   FTP REQUIREMENTS SUMMARY
-
-                                           |               | | | |S| |
-                                           |               | | | |H| |F
-                                           |               | | | |O|M|o
-                                           |               | |S| |U|U|o
-                                           |               | |H| |L|S|t
-                                           |               |M|O| |D|T|n
-                                           |               |U|U|M| | |o
-                                           |               |S|L|A|N|N|t
-                                           |               |T|D|Y|O|O|t
-FEATURE                                    |SECTION        | | | |T|T|e
--------------------------------------------|---------------|-|-|-|-|-|--
-Implement TYPE T if same as TYPE N         |4.1.2.2        | |x| | | |
-File/Record transform invertible if poss.  |4.1.2.4        | |x| | | |
-User-FTP send PORT cmd for stream mode     |4.1.2.5        | |x| | | |
-Server-FTP implement PASV                  |4.1.2.6        |x| | | | |
-  PASV is per-transfer                     |4.1.2.6        |x| | | | |
-NLST reply usable in RETR cmds             |4.1.2.7        |x| | | | |
-Implied type for LIST and NLST             |4.1.2.7        | |x| | | |
-SITE cmd for non-standard features         |4.1.2.8        | |x| | | |
-STOU cmd return pathname as specified      |4.1.2.9        |x| | | | |
-Use TCP READ boundaries on control conn.   |4.1.2.10       | | | | |x|
-                                           |               | | | | | |
-Server-FTP send only correct reply format  |4.1.2.11       |x| | | | |
-Server-FTP use defined reply code if poss. |4.1.2.11       | |x| | | |
-  New reply code following Section 4.2     |4.1.2.11       | | |x| | |
-User-FTP use only high digit of reply      |4.1.2.11       | |x| | | |
-User-FTP handle multi-line reply lines     |4.1.2.11       |x| | | | |
-User-FTP handle 421 reply specially        |4.1.2.11       | | | |x| |
-                                           |               | | | | | |
-Default data port same IP addr as ctl conn |4.1.2.12       |x| | | | |
-User-FTP send Telnet cmds exc. SYNCH, IP   |4.1.2.12       | | | | |x|
-User-FTP negotiate Telnet options          |4.1.2.12       | | | | |x|
-Server-FTP handle Telnet options           |4.1.2.12       |x| | | | |
-Handle "Experimental" directory cmds       |4.1.3.1        | |x| | | |
-Idle timeout in server-FTP                 |4.1.3.2        | |x| | | |
-    Configurable idle timeout              |4.1.3.2        | |x| | | |
-Receiver checkpoint data at Restart Marker |4.1.3.4        | |x| | | |
-Sender assume 110 replies are synchronous  |4.1.3.4        | | | | |x|
-                                           |               | | | | | |
-Support TYPE:                              |               | | | | | |
-  ASCII - Non-Print (AN)                   |4.1.2.13       |x| | | | |
-  ASCII - Telnet (AT) -- if same as AN     |4.1.2.2        | |x| | | |
-  ASCII - Carriage Control (AC)            |959 3.1.1.5.2  | | |x| | |
-  EBCDIC - (any form)                      |959 3.1.1.2    | | |x| | |
-  IMAGE                                    |4.1.2.1        |x| | | | |
-  LOCAL 8                                  |4.1.2.1        |x| | | | |
-
-
-
-Internet Engineering Task Force                                [Page 41]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-  LOCAL m                                  |4.1.2.1        | | |x| | |2
-                                           |               | | | | | |
-Support MODE:                              |               | | | | | |
-  Stream                                   |4.1.2.13       |x| | | | |
-  Block                                    |959 3.4.2      | | |x| | |
-                                           |               | | | | | |
-Support STRUCTURE:                         |               | | | | | |
-  File                                     |4.1.2.13       |x| | | | |
-  Record                                   |4.1.2.13       |x| | | | |3
-  Page                                     |4.1.2.3        | | | |x| |
-                                           |               | | | | | |
-Support commands:                          |               | | | | | |
-  USER                                     |4.1.2.13       |x| | | | |
-  PASS                                     |4.1.2.13       |x| | | | |
-  ACCT                                     |4.1.2.13       |x| | | | |
-  CWD                                      |4.1.2.13       |x| | | | |
-  CDUP                                     |4.1.2.13       |x| | | | |
-  SMNT                                     |959 5.3.1      | | |x| | |
-  REIN                                     |959 5.3.1      | | |x| | |
-  QUIT                                     |4.1.2.13       |x| | | | |
-                                           |               | | | | | |
-  PORT                                     |4.1.2.13       |x| | | | |
-  PASV                                     |4.1.2.6        |x| | | | |
-  TYPE                                     |4.1.2.13       |x| | | | |1
-  STRU                                     |4.1.2.13       |x| | | | |1
-  MODE                                     |4.1.2.13       |x| | | | |1
-                                           |               | | | | | |
-  RETR                                     |4.1.2.13       |x| | | | |
-  STOR                                     |4.1.2.13       |x| | | | |
-  STOU                                     |959 5.3.1      | | |x| | |
-  APPE                                     |4.1.2.13       |x| | | | |
-  ALLO                                     |959 5.3.1      | | |x| | |
-  REST                                     |959 5.3.1      | | |x| | |
-  RNFR                                     |4.1.2.13       |x| | | | |
-  RNTO                                     |4.1.2.13       |x| | | | |
-  ABOR                                     |959 5.3.1      | | |x| | |
-  DELE                                     |4.1.2.13       |x| | | | |
-  RMD                                      |4.1.2.13       |x| | | | |
-  MKD                                      |4.1.2.13       |x| | | | |
-  PWD                                      |4.1.2.13       |x| | | | |
-  LIST                                     |4.1.2.13       |x| | | | |
-  NLST                                     |4.1.2.13       |x| | | | |
-  SITE                                     |4.1.2.8        | | |x| | |
-  STAT                                     |4.1.2.13       |x| | | | |
-  SYST                                     |4.1.2.13       |x| | | | |
-  HELP                                     |4.1.2.13       |x| | | | |
-  NOOP                                     |4.1.2.13       |x| | | | |
-                                           |               | | | | | |
-
-
-
-Internet Engineering Task Force                                [Page 42]
-
-
-
-
-RFC1123                   FILE TRANSFER -- FTP              October 1989
-
-
-User Interface:                            |               | | | | | |
-  Arbitrary pathnames                      |4.1.4.1        |x| | | | |
-  Implement "QUOTE" command                |4.1.4.2        |x| | | | |
-  Transfer control commands immediately    |4.1.4.2        | |x| | | |
-  Display error messages to user           |4.1.4.3        | |x| | | |
-    Verbose mode                           |4.1.4.3        | |x| | | |
-  Maintain synchronization with server     |4.1.4.4        | |x| | | |
-
-Footnotes:
-
-(1)  For the values shown earlier.
-
-(2)  Here m is number of bits in a memory word.
-
-(3)  Required for host with record-structured file system, optional
-     otherwise.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 43]
-
-
-
-
-RFC1123                  FILE TRANSFER -- TFTP              October 1989
-
-
-   4.2  TRIVIAL FILE TRANSFER PROTOCOL -- TFTP
-
-      4.2.1  INTRODUCTION
-
-         The Trivial File Transfer Protocol TFTP is defined in RFC-783
-         [TFTP:1].
-
-         TFTP provides its own reliable delivery with UDP as its
-         transport protocol, using a simple stop-and-wait acknowledgment
-         system.  Since TFTP has an effective window of only one 512
-         octet segment, it can provide good performance only over paths
-         that have a small delay*bandwidth product.  The TFTP file
-         interface is very simple, providing no access control or
-         security.
-
-         TFTP's most important application is bootstrapping a host over
-         a local network, since it is simple and small enough to be
-         easily implemented in EPROM [BOOT:1, BOOT:2].  Vendors are
-         urged to support TFTP for booting.
-
-      4.2.2  PROTOCOL WALK-THROUGH
-
-         The TFTP specification [TFTP:1] is written in an open style,
-         and does not fully specify many parts of the protocol.
-
-         4.2.2.1  Transfer Modes: RFC-783, Page 3
-
-            The transfer mode "mail" SHOULD NOT be supported.
-
-         4.2.2.2  UDP Header: RFC-783, Page 17
-
-            The Length field of a UDP header is incorrectly defined; it
-            includes the UDP header length (8).
-
-      4.2.3  SPECIFIC ISSUES
-
-         4.2.3.1  Sorcerer's Apprentice Syndrome
-
-            There is a serious bug, known as the "Sorcerer's Apprentice
-            Syndrome," in the protocol specification.  While it does not
-            cause incorrect operation of the transfer (the file will
-            always be transferred correctly if the transfer completes),
-            this bug may cause excessive retransmission, which may cause
-            the transfer to time out.
-
-            Implementations MUST contain the fix for this problem: the
-            sender (i.e., the side originating the DATA packets) must
-            never resend the current DATA packet on receipt of a
-
-
-
-Internet Engineering Task Force                                [Page 44]
-
-
-
-
-RFC1123                  FILE TRANSFER -- TFTP              October 1989
-
-
-            duplicate ACK.
-
-            DISCUSSION:
-                 The bug is caused by the protocol rule that either
-                 side, on receiving an old duplicate datagram, may
-                 resend the current datagram.  If a packet is delayed in
-                 the network but later successfully delivered after
-                 either side has timed out and retransmitted a packet, a
-                 duplicate copy of the response may be generated.  If
-                 the other side responds to this duplicate with a
-                 duplicate of its own, then every datagram will be sent
-                 in duplicate for the remainder of the transfer (unless
-                 a datagram is lost, breaking the repetition).  Worse
-                 yet, since the delay is often caused by congestion,
-                 this duplicate transmission will usually causes more
-                 congestion, leading to more delayed packets, etc.
-
-                 The following example may help to clarify this problem.
-
-                     TFTP A                  TFTP B
-
-                 (1)  Receive ACK X-1
-                      Send DATA X
-                 (2)                          Receive DATA X
-                                              Send ACK X
-                        (ACK X is delayed in network,
-                         and  A times out):
-                 (3)  Retransmit DATA X
-
-                 (4)                          Receive DATA X again
-                                              Send ACK X again
-                 (5)  Receive (delayed) ACK X
-                      Send DATA X+1
-                 (6)                          Receive DATA X+1
-                                              Send ACK X+1
-                 (7)  Receive ACK X again
-                      Send DATA X+1 again
-                 (8)                          Receive DATA X+1 again
-                                              Send ACK X+1 again
-                 (9)  Receive ACK X+1
-                      Send DATA X+2
-                 (10)                         Receive DATA X+2
-                                              Send ACK X+3
-                 (11) Receive ACK X+1 again
-                      Send DATA X+2 again
-                 (12)                         Receive DATA X+2 again
-                                              Send ACK X+3 again
-
-
-
-
-Internet Engineering Task Force                                [Page 45]
-
-
-
-
-RFC1123                  FILE TRANSFER -- TFTP              October 1989
-
-
-                 Notice that once the delayed ACK arrives, the protocol
-                 settles down to duplicate all further packets
-                 (sequences 5-8 and 9-12).  The problem is caused not by
-                 either side timing out, but by both sides
-                 retransmitting the current packet when they receive a
-                 duplicate.
-
-                 The fix is to break the retransmission loop, as
-                 indicated above.  This is analogous to the behavior of
-                 TCP.  It is then possible to remove the retransmission
-                 timer on the receiver, since the resent ACK will never
-                 cause any action; this is a useful simplification where
-                 TFTP is used in a bootstrap program.  It is OK to allow
-                 the timer to remain, and it may be helpful if the
-                 retransmitted ACK replaces one that was genuinely lost
-                 in the network.  The sender still requires a retransmit
-                 timer, of course.
-
-         4.2.3.2  Timeout Algorithms
-
-            A TFTP implementation MUST use an adaptive timeout.
-
-            IMPLEMENTATION:
-                 TCP retransmission algorithms provide a useful base to
-                 work from.  At least an exponential backoff of
-                 retransmission timeout is necessary.
-
-         4.2.3.3  Extensions
-
-            A variety of non-standard extensions have been made to TFTP,
-            including additional transfer modes and a secure operation
-            mode (with passwords).  None of these have been
-            standardized.
-
-         4.2.3.4  Access Control
-
-            A server TFTP implementation SHOULD include some
-            configurable access control over what pathnames are allowed
-            in TFTP operations.
-
-         4.2.3.5  Broadcast Request
-
-            A TFTP request directed to a broadcast address SHOULD be
-            silently ignored.
-
-            DISCUSSION:
-                 Due to the weak access control capability of TFTP,
-                 directed broadcasts of TFTP requests to random networks
-
-
-
-Internet Engineering Task Force                                [Page 46]
-
-
-
-
-RFC1123                  FILE TRANSFER -- TFTP              October 1989
-
-
-                 could create a significant security hole.
-
-      4.2.4  TFTP REQUIREMENTS SUMMARY
-
-                                                 |        | | | |S| |
-                                                 |        | | | |H| |F
-                                                 |        | | | |O|M|o
-                                                 |        | |S| |U|U|o
-                                                 |        | |H| |L|S|t
-                                                 |        |M|O| |D|T|n
-                                                 |        |U|U|M| | |o
-                                                 |        |S|L|A|N|N|t
-                                                 |        |T|D|Y|O|O|t
-FEATURE                                          |SECTION | | | |T|T|e
--------------------------------------------------|--------|-|-|-|-|-|--
-Fix Sorcerer's Apprentice Syndrome               |4.2.3.1 |x| | | | |
-Transfer modes:                                  |        | | | | | |
-  netascii                                       |RFC-783 |x| | | | |
-  octet                                          |RFC-783 |x| | | | |
-  mail                                           |4.2.2.1 | | | |x| |
-  extensions                                     |4.2.3.3 | | |x| | |
-Use adaptive timeout                             |4.2.3.2 |x| | | | |
-Configurable access control                      |4.2.3.4 | |x| | | |
-Silently ignore broadcast request                |4.2.3.5 | |x| | | |
--------------------------------------------------|--------|-|-|-|-|-|--
--------------------------------------------------|--------|-|-|-|-|-|--
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 47]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-5.  ELECTRONIC MAIL -- SMTP and RFC-822
-
-   5.1  INTRODUCTION
-
-      In the TCP/IP protocol suite, electronic mail in a format
-      specified in RFC-822 [SMTP:2] is transmitted using the Simple Mail
-      Transfer Protocol (SMTP) defined in RFC-821 [SMTP:1].
-
-      While SMTP has remained unchanged over the years, the Internet
-      community has made several changes in the way SMTP is used.  In
-      particular, the conversion to the Domain Name System (DNS) has
-      caused changes in address formats and in mail routing.  In this
-      section, we assume familiarity with the concepts and terminology
-      of the DNS, whose requirements are given in Section 6.1.
-
-      RFC-822 specifies the Internet standard format for electronic mail
-      messages.  RFC-822 supercedes an older standard, RFC-733, that may
-      still be in use in a few places, although it is obsolete.  The two
-      formats are sometimes referred to simply by number ("822" and
-      "733").
-
-      RFC-822 is used in some non-Internet mail environments with
-      different mail transfer protocols than SMTP, and SMTP has also
-      been adapted for use in some non-Internet environments.  Note that
-      this document presents the rules for the use of SMTP and RFC-822
-      for the Internet environment only; other mail environments that
-      use these protocols may be expected to have their own rules.
-
-   5.2  PROTOCOL WALK-THROUGH
-
-      This section covers both RFC-821 and RFC-822.
-
-      The SMTP specification in RFC-821 is clear and contains numerous
-      examples, so implementors should not find it difficult to
-      understand.  This section simply updates or annotates portions of
-      RFC-821 to conform with current usage.
-
-      RFC-822 is a long and dense document, defining a rich syntax.
-      Unfortunately, incomplete or defective implementations of RFC-822
-      are common.  In fact, nearly all of the many formats of RFC-822
-      are actually used, so an implementation generally needs to
-      recognize and correctly interpret all of the RFC-822 syntax.
-
-      5.2.1  The SMTP Model: RFC-821 Section 2
-
-         DISCUSSION:
-              Mail is sent by a series of request/response transactions
-              between a client, the "sender-SMTP," and a server, the
-
-
-
-Internet Engineering Task Force                                [Page 48]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-              "receiver-SMTP".  These transactions pass (1) the message
-              proper, which is composed of header and body, and (2) SMTP
-              source and destination addresses, referred to as the
-              "envelope".
-
-              The SMTP programs are analogous to Message Transfer Agents
-              (MTAs) of X.400.  There will be another level of protocol
-              software, closer to the end user, that is responsible for
-              composing and analyzing RFC-822 message headers; this
-              component is known as the "User Agent" in X.400, and we
-              use that term in this document.  There is a clear logical
-              distinction between the User Agent and the SMTP
-              implementation, since they operate on different levels of
-              protocol.  Note, however, that this distinction is may not
-              be exactly reflected the structure of typical
-              implementations of Internet mail.  Often there is a
-              program known as the "mailer" that implements SMTP and
-              also some of the User Agent functions; the rest of the
-              User Agent functions are included in a user interface used
-              for entering and reading mail.
-
-              The SMTP envelope is constructed at the originating site,
-              typically by the User Agent when the message is first
-              queued for the Sender-SMTP program.  The envelope
-              addresses may be derived from information in the message
-              header, supplied by the user interface (e.g., to implement
-              a bcc: request), or derived from local configuration
-              information (e.g., expansion of a mailing list).  The SMTP
-              envelope cannot in general be re-derived from the header
-              at a later stage in message delivery, so the envelope is
-              transmitted separately from the message itself using the
-              MAIL and RCPT commands of SMTP.
-
-              The text of RFC-821 suggests that mail is to be delivered
-              to an individual user at a host.  With the advent of the
-              domain system and of mail routing using mail-exchange (MX)
-              resource records, implementors should now think of
-              delivering mail to a user at a domain, which may or may
-              not be a particular host.  This DOES NOT change the fact
-              that SMTP is a host-to-host mail exchange protocol.
-
-      5.2.2  Canonicalization: RFC-821 Section 3.1
-
-         The domain names that a Sender-SMTP sends in MAIL and RCPT
-         commands MUST have been  "canonicalized," i.e., they must be
-         fully-qualified principal names or domain literals, not
-         nicknames or domain abbreviations.  A canonicalized name either
-         identifies a host directly or is an MX name; it cannot be a
-
-
-
-Internet Engineering Task Force                                [Page 49]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-         CNAME.
-
-      5.2.3  VRFY and EXPN Commands: RFC-821 Section 3.3
-
-         A receiver-SMTP MUST implement VRFY and SHOULD implement EXPN
-         (this requirement overrides RFC-821).  However, there MAY be
-         configuration information to disable VRFY and EXPN in a
-         particular installation; this might even allow EXPN to be
-         disabled for selected lists.
-
-         A new reply code is defined for the VRFY command:
-
-              252 Cannot VRFY user (e.g., info is not local), but will
-                  take message for this user and attempt delivery.
-
-         DISCUSSION:
-              SMTP users and administrators make regular use of these
-              commands for diagnosing mail delivery problems.  With the
-              increasing use of multi-level mailing list expansion
-              (sometimes more than two levels), EXPN has been
-              increasingly important for diagnosing inadvertent mail
-              loops.  On the other hand,  some feel that EXPN represents
-              a significant privacy, and perhaps even a security,
-              exposure.
-
-      5.2.4  SEND, SOML, and SAML Commands: RFC-821 Section 3.4
-
-         An SMTP MAY implement the commands to send a message to a
-         user's terminal: SEND, SOML, and SAML.
-
-         DISCUSSION:
-              It has been suggested that the use of mail relaying
-              through an MX record is inconsistent with the intent of
-              SEND to deliver a message immediately and directly to a
-              user's terminal.  However, an SMTP receiver that is unable
-              to write directly to the user terminal can return a "251
-              User Not Local" reply to the RCPT following a SEND, to
-              inform the originator of possibly deferred delivery.
-
-      5.2.5  HELO Command: RFC-821 Section 3.5
-
-         The sender-SMTP MUST ensure that the <domain> parameter in a
-         HELO command is a valid principal host domain name for the
-         client host.  As a result, the receiver-SMTP will not have to
-         perform MX resolution on this name in order to validate the
-         HELO parameter.
-
-         The HELO receiver MAY verify that the HELO parameter really
-
-
-
-Internet Engineering Task Force                                [Page 50]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-         corresponds to the IP address of the sender.  However, the
-         receiver MUST NOT refuse to accept a message, even if the
-         sender's HELO command fails verification.
-
-         DISCUSSION:
-              Verifying the HELO parameter requires a domain name lookup
-              and may therefore take considerable time.  An alternative
-              tool for tracking bogus mail sources is suggested below
-              (see "DATA Command").
-
-              Note also that the HELO argument is still required to have
-              valid <domain> syntax, since it will appear in a Received:
-              line; otherwise, a 501 error is to be sent.
-
-         IMPLEMENTATION:
-              When HELO parameter validation fails, a suggested
-              procedure is to insert a note about the unknown
-              authenticity of the sender into the message header (e.g.,
-              in the "Received:"  line).
-
-      5.2.6  Mail Relay: RFC-821 Section 3.6
-
-         We distinguish three types of mail (store-and-) forwarding:
-
-         (1)  A simple forwarder or "mail exchanger" forwards a message
-              using private knowledge about the recipient; see section
-              3.2 of RFC-821.
-
-         (2)  An SMTP mail "relay" forwards a message within an SMTP
-              mail environment as the result of an explicit source route
-              (as defined in section 3.6 of RFC-821).  The SMTP relay
-              function uses the "@...:" form of source route from RFC-
-              822 (see Section 5.2.19 below).
-
-         (3)  A mail "gateway" passes a message between different
-              environments.  The rules for mail gateways are discussed
-              below in Section 5.3.7.
-
-         An Internet host that is forwarding a message but is not a
-         gateway to a different mail environment (i.e., it falls under
-         (1) or (2)) SHOULD NOT alter any existing header fields,
-         although the host will add an appropriate Received: line as
-         required in Section 5.2.8.
-
-         A Sender-SMTP SHOULD NOT send a RCPT TO: command containing an
-         explicit source route using the "@...:" address form.  Thus,
-         the relay function defined in section  3.6 of RFC-821 should
-         not be used.
-
-
-
-Internet Engineering Task Force                                [Page 51]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-         DISCUSSION:
-              The intent is to discourage all source routing and to
-              abolish explicit source routing for mail delivery within
-              the Internet environment.  Source-routing is unnecessary;
-              the simple target address "user@domain" should always
-              suffice.  This is the result of an explicit architectural
-              decision to use universal naming rather than source
-              routing for mail.  Thus, SMTP provides end-to-end
-              connectivity, and the DNS provides globally-unique,
-              location-independent names.  MX records handle the major
-              case where source routing might otherwise be needed.
-
-         A receiver-SMTP MUST accept the explicit source route syntax in
-         the envelope, but it MAY implement the relay function as
-         defined in section 3.6 of RFC-821.  If it does not implement
-         the relay function, it SHOULD attempt to deliver the message
-         directly to the host to the right of the right-most "@" sign.
-
-         DISCUSSION:
-              For example, suppose a host that does not implement the
-              relay function receives a message with the SMTP command:
-              "RCPT TO:<@ALPHA,@BETA:joe@GAMMA>", where ALPHA, BETA, and
-              GAMMA represent domain names.  Rather than immediately
-              refusing the message with a 550 error reply as suggested
-              on page 20 of RFC-821, the host should try to forward the
-              message to GAMMA directly, using: "RCPT TO:<joe@GAMMA>".
-              Since this host does not support relaying, it is not
-              required to update the reverse path.
-
-              Some have suggested that source routing may be needed
-              occasionally for manually routing mail around failures;
-              however, the reality and importance of this need is
-              controversial.  The use of explicit SMTP mail relaying for
-              this purpose is discouraged, and in fact it may not be
-              successful, as many host systems do not support it.  Some
-              have used the "%-hack" (see Section 5.2.16) for this
-              purpose.
-
-      5.2.7  RCPT Command: RFC-821 Section 4.1.1
-
-         A host that supports a receiver-SMTP MUST support the reserved
-         mailbox "Postmaster".
-
-         The receiver-SMTP MAY verify RCPT parameters as they arrive;
-         however, RCPT responses MUST NOT be delayed beyond a reasonable
-         time (see Section 5.3.2).
-
-         Therefore, a "250 OK" response to a RCPT does not necessarily
-
-
-
-Internet Engineering Task Force                                [Page 52]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-         imply that the delivery address(es) are valid.  Errors found
-         after message acceptance will be reported by mailing a
-         notification message to an appropriate address (see Section
-         5.3.3).
-
-         DISCUSSION:
-              The set of conditions under which a RCPT parameter can be
-              validated immediately is an engineering design choice.
-              Reporting destination mailbox errors to the Sender-SMTP
-              before mail is transferred is generally desirable to save
-              time and network bandwidth, but this advantage is lost if
-              RCPT verification is lengthy.
-
-              For example, the receiver can verify immediately any
-              simple local reference, such as a single locally-
-              registered mailbox.  On the other hand, the "reasonable
-              time" limitation generally implies deferring verification
-              of a mailing list until after the message has been
-              transferred and accepted, since verifying a large mailing
-              list can take a very long time.  An implementation might
-              or might not choose to defer validation of addresses that
-              are non-local and therefore require a DNS lookup.  If a
-              DNS lookup is performed but a soft domain system error
-              (e.g., timeout) occurs, validity must be assumed.
-
-      5.2.8  DATA Command: RFC-821 Section 4.1.1
-
-         Every receiver-SMTP (not just one that "accepts a message for
-         relaying or for final delivery" [SMTP:1]) MUST insert a
-         "Received:" line at the beginning of a message.  In this line,
-         called a "time stamp line" in RFC-821:
-
-         *    The FROM field SHOULD contain both (1) the name of the
-              source host as presented in the HELO command and (2) a
-              domain literal containing the IP address of the source,
-              determined from the TCP connection.
-
-         *    The ID field MAY contain an "@" as suggested in RFC-822,
-              but this is not required.
-
-         *    The FOR field MAY contain a list of <path> entries when
-              multiple RCPT commands have been given.
-
-
-         An Internet mail program MUST NOT change a Received: line that
-         was previously added to the message header.
-
-
-
-
-
-Internet Engineering Task Force                                [Page 53]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-         DISCUSSION:
-              Including both the source host and the IP source address
-              in the Received: line may provide enough information for
-              tracking illicit mail sources and eliminate a need to
-              explicitly verify the HELO parameter.
-
-              Received: lines are primarily intended for humans tracing
-              mail routes, primarily of diagnosis of faults.  See also
-              the discussion under 5.3.7.
-
-         When the receiver-SMTP makes "final delivery" of a message,
-         then it MUST pass the MAIL FROM: address from the SMTP envelope
-         with the message, for use if an error notification message must
-         be sent later (see Section 5.3.3).  There is an analogous
-         requirement when gatewaying from the Internet into a different
-         mail environment; see Section 5.3.7.
-
-         DISCUSSION:
-              Note that the final reply to the DATA command depends only
-              upon the successful transfer and storage of the message.
-              Any problem with the destination address(es) must either
-              (1) have been reported in an SMTP error reply to the RCPT
-              command(s), or (2) be reported in a later error message
-              mailed to the originator.
-
-         IMPLEMENTATION:
-              The MAIL FROM: information may be passed as a parameter or
-              in a Return-Path: line inserted at the beginning of the
-              message.
-
-      5.2.9  Command Syntax: RFC-821 Section 4.1.2
-
-         The syntax shown in RFC-821 for the MAIL FROM: command omits
-         the case of an empty path:  "MAIL FROM: <>" (see RFC-821 Page
-         15).  An empty reverse path MUST be supported.
-
-      5.2.10  SMTP Replies:  RFC-821 Section 4.2
-
-         A receiver-SMTP SHOULD send only the reply codes listed in
-         section 4.2.2 of RFC-821 or in this document.  A receiver-SMTP
-         SHOULD use the text shown in examples in RFC-821 whenever
-         appropriate.
-
-         A sender-SMTP MUST determine its actions only by the reply
-         code, not by the text (except for 251 and 551 replies); any
-         text, including no text at all, must be acceptable.  The space
-         (blank) following the reply code is considered part of the
-         text.  Whenever possible, a sender-SMTP SHOULD test only the
-
-
-
-Internet Engineering Task Force                                [Page 54]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-         first digit of the reply code, as specified in Appendix E of
-         RFC-821.
-
-         DISCUSSION:
-              Interoperability problems have arisen with SMTP systems
-              using reply codes that are not listed explicitly in RFC-
-              821 Section 4.3 but are legal according to the theory of
-              reply codes explained in Appendix E.
-
-      5.2.11  Transparency: RFC-821 Section 4.5.2
-
-         Implementors MUST be sure that their mail systems always add
-         and delete periods to ensure message transparency.
-
-      5.2.12  WKS Use in MX Processing: RFC-974, p. 5
-
-         RFC-974 [SMTP:3] recommended that the domain system be queried
-         for WKS ("Well-Known Service") records, to verify that each
-         proposed mail target does support SMTP.  Later experience has
-         shown that WKS is not widely supported, so the WKS step in MX
-         processing SHOULD NOT be used.
-
-      The following are notes on RFC-822, organized by section of that
-      document.
-
-      5.2.13  RFC-822 Message Specification: RFC-822 Section 4
-
-         The syntax shown for the Return-path line omits the possibility
-         of a null return path, which is used to prevent looping of
-         error notifications (see Section 5.3.3).  The complete syntax
-         is:
-
-             return = "Return-path"  ":" route-addr
-                    / "Return-path"  ":" "<" ">"
-
-         The set of optional header fields is hereby expanded to include
-         the Content-Type field defined in RFC-1049 [SMTP:7].  This
-         field "allows mail reading systems to automatically identify
-         the type of a structured message body and to process it for
-         display accordingly".  [SMTP:7]  A User Agent MAY support this
-         field.
-
-      5.2.14  RFC-822 Date and Time Specification: RFC-822 Section 5
-
-         The syntax for the date is hereby changed to:
-
-            date = 1*2DIGIT month 2*4DIGIT
-
-
-
-
-Internet Engineering Task Force                                [Page 55]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-         All mail software SHOULD use 4-digit years in dates, to ease
-         the transition to the next century.
-
-         There is a strong trend towards the use of numeric timezone
-         indicators, and implementations SHOULD use numeric timezones
-         instead of timezone names.  However, all implementations MUST
-         accept either notation.  If timezone names are used, they MUST
-         be exactly as defined in RFC-822.
-
-         The military time zones are specified incorrectly in RFC-822:
-         they count the wrong way from UT (the signs are reversed).  As
-         a result, military time zones in RFC-822 headers carry no
-         information.
-
-         Finally, note that there is a typo in the definition of "zone"
-         in the syntax summary of appendix D; the correct definition
-         occurs in Section 3 of RFC-822.
-
-      5.2.15  RFC-822 Syntax Change: RFC-822 Section 6.1
-
-         The syntactic definition of "mailbox" in RFC-822 is hereby
-         changed to:
-
-            mailbox =  addr-spec            ; simple address
-                    / [phrase] route-addr   ; name & addr-spec
-
-         That is, the phrase preceding a route address is now OPTIONAL.
-         This change makes the following header field legal, for
-         example:
-
-             From: <craig@nnsc.nsf.net>
-
-      5.2.16  RFC-822  Local-part: RFC-822 Section 6.2
-
-         The basic mailbox address specification has the form: "local-
-         part@domain".  Here "local-part", sometimes called the "left-
-         hand side" of the address, is domain-dependent.
-
-         A host that is forwarding the message but is not the
-         destination host implied by the right-hand side "domain" MUST
-         NOT interpret or modify the "local-part" of the address.
-
-         When mail is to be gatewayed from the Internet mail environment
-         into a foreign mail environment (see Section 5.3.7), routing
-         information for that foreign environment MAY be embedded within
-         the "local-part" of the address.  The gateway will then
-         interpret this local part appropriately for the foreign mail
-         environment.
-
-
-
-Internet Engineering Task Force                                [Page 56]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-         DISCUSSION:
-              Although source routes are discouraged within the Internet
-              (see Section 5.2.6), there are non-Internet mail
-              environments whose delivery mechanisms do depend upon
-              source routes.  Source routes for extra-Internet
-              environments can generally be buried in the "local-part"
-              of the address (see Section 5.2.16) while mail traverses
-              the Internet.  When the mail reaches the appropriate
-              Internet mail gateway, the gateway will interpret the
-              local-part and build the necessary address or route for
-              the target mail environment.
-
-              For example, an Internet host might send mail to:
-              "a!b!c!user@gateway-domain".  The complex local part
-              "a!b!c!user" would be uninterpreted within the Internet
-              domain, but could be parsed and understood by the
-              specified mail gateway.
-
-              An embedded source route is sometimes encoded in the
-              "local-part" using "%" as a right-binding routing
-              operator.  For example, in:
-
-                 user%domain%relay3%relay2@relay1
-
-              the "%" convention implies that the mail is to be routed
-              from "relay1" through "relay2", "relay3", and finally to
-              "user" at "domain".  This is commonly known as the "%-
-              hack".  It is suggested that "%" have lower precedence
-              than any other routing operator (e.g., "!") hidden in the
-              local-part; for example, "a!b%c" would be interpreted as
-              "(a!b)%c".
-
-              Only the target host (in this case, "relay1") is permitted
-              to analyze the local-part "user%domain%relay3%relay2".
-
-      5.2.17  Domain Literals: RFC-822 Section 6.2.3
-
-         A mailer MUST be able to accept and parse an Internet domain
-         literal whose content ("dtext"; see RFC-822) is a dotted-
-         decimal host address.  This satisfies the requirement of
-         Section 2.1 for the case of mail.
-
-         An SMTP MUST accept and recognize a domain literal for any of
-         its own IP addresses.
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 57]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-      5.2.18  Common Address Formatting Errors: RFC-822 Section 6.1
-
-         Errors in formatting or parsing 822 addresses are unfortunately
-         common.  This section mentions only the most common errors.  A
-         User Agent MUST accept all valid RFC-822 address formats, and
-         MUST NOT generate illegal address syntax.
-
-         o    A common error is to leave out the semicolon after a group
-              identifier.
-
-         o    Some systems fail to fully-qualify domain names in
-              messages they generate.  The right-hand side of an "@"
-              sign in a header address field MUST be a fully-qualified
-              domain name.
-
-              For example, some systems fail to fully-qualify the From:
-              address; this prevents a "reply" command in the user
-              interface from automatically constructing a return
-              address.
-
-              DISCUSSION:
-                   Although RFC-822 allows the local use of abbreviated
-                   domain names within a domain, the application of
-                   RFC-822 in Internet mail does not allow this.  The
-                   intent is that an Internet host must not send an SMTP
-                   message header containing an abbreviated domain name
-                   in an address field.  This allows the address fields
-                   of the header to be passed without alteration across
-                   the Internet, as required in Section 5.2.6.
-
-         o    Some systems mis-parse multiple-hop explicit source routes
-              such as:
-
-                  @relay1,@relay2,@relay3:user@domain.
-
-
-         o    Some systems over-qualify domain names by adding a
-              trailing dot to some or all domain names in addresses or
-              message-ids.  This violates RFC-822 syntax.
-
-
-      5.2.19  Explicit Source Routes: RFC-822 Section 6.2.7
-
-         Internet host software SHOULD NOT create an RFC-822 header
-         containing an address with an explicit source route, but MUST
-         accept such headers for compatibility with earlier systems.
-
-         DISCUSSION:
-
-
-
-Internet Engineering Task Force                                [Page 58]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-              In an understatement, RFC-822 says "The use of explicit
-              source routing is discouraged".  Many hosts implemented
-              RFC-822 source routes incorrectly, so the syntax cannot be
-              used unambiguously in practice.  Many users feel the
-              syntax is ugly.  Explicit source routes are not needed in
-              the mail envelope for delivery; see Section 5.2.6.  For
-              all these reasons, explicit source routes using the RFC-
-              822 notations are not to be used in Internet mail headers.
-
-              As stated in Section 5.2.16, it is necessary to allow an
-              explicit source route to be buried in the local-part of an
-              address, e.g., using the "%-hack", in order to allow mail
-              to be gatewayed into another environment in which explicit
-              source routing is necessary.  The vigilant will observe
-              that there is no way for a User Agent to detect and
-              prevent the use of such implicit source routing when the
-              destination is within the Internet.  We can only
-              discourage source routing of any kind within the Internet,
-              as unnecessary and undesirable.
-
-   5.3  SPECIFIC ISSUES
-
-      5.3.1  SMTP Queueing Strategies
-
-         The common structure of a host SMTP implementation includes
-         user mailboxes, one or more areas for queueing messages in
-         transit, and one or more daemon processes for sending and
-         receiving mail.  The exact structure will vary depending on the
-         needs of the users on the host and the number and size of
-         mailing lists supported by the host.  We describe several
-         optimizations that have proved helpful, particularly for
-         mailers supporting high traffic levels.
-
-         Any queueing strategy MUST include:
-
-         o    Timeouts on all activities.  See Section 5.3.2.
-
-         o    Never sending error messages in response to error
-              messages.
-
-
-         5.3.1.1 Sending Strategy
-
-            The general model of a sender-SMTP is one or more processes
-            that periodically attempt to transmit outgoing mail.  In a
-            typical system, the program that composes a message has some
-            method for requesting immediate attention for a new piece of
-            outgoing mail, while mail that cannot be transmitted
-
-
-
-Internet Engineering Task Force                                [Page 59]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-            immediately MUST be queued and periodically retried by the
-            sender.  A mail queue entry will include not only the
-            message itself but also the envelope information.
-
-            The sender MUST delay retrying a particular destination
-            after one attempt has failed.  In general, the retry
-            interval SHOULD be at least 30 minutes; however, more
-            sophisticated and variable strategies will be beneficial
-            when the sender-SMTP can determine the reason for non-
-            delivery.
-
-            Retries continue until the message is transmitted or the
-            sender gives up; the give-up time generally needs to be at
-            least 4-5 days.  The parameters to the retry algorithm MUST
-            be configurable.
-
-            A sender SHOULD keep a list of hosts it cannot reach and
-            corresponding timeouts, rather than just retrying queued
-            mail items.
-
-            DISCUSSION:
-                 Experience suggests that failures are typically
-                 transient (the target system has crashed), favoring a
-                 policy of two connection attempts in the first hour the
-                 message is in the queue, and then backing off to once
-                 every two or three hours.
-
-                 The sender-SMTP can shorten the queueing delay by
-                 cooperation with the receiver-SMTP.  In particular, if
-                 mail is received from a particular address, it is good
-                 evidence that any mail queued for that host can now be
-                 sent.
-
-                 The strategy may be further modified as a result of
-                 multiple addresses per host (see Section 5.3.4), to
-                 optimize delivery time vs. resource usage.
-
-                 A sender-SMTP may have a large queue of messages for
-                 each unavailable destination host, and if it retried
-                 all these messages in every retry cycle, there would be
-                 excessive Internet overhead and the daemon would be
-                 blocked for a long period.  Note that an SMTP can
-                 generally determine that a delivery attempt has failed
-                 only after a timeout of a minute or more; a one minute
-                 timeout per connection will result in a very large
-                 delay if it is repeated for dozens or even hundreds of
-                 queued messages.
-
-
-
-
-Internet Engineering Task Force                                [Page 60]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-            When the same message is to be delivered to several users on
-            the same host, only one copy of the message SHOULD be
-            transmitted.  That is, the sender-SMTP should use the
-            command sequence: RCPT, RCPT,... RCPT, DATA instead of the
-            sequence: RCPT, DATA, RCPT, DATA,... RCPT, DATA.
-            Implementation of this efficiency feature is strongly urged.
-
-            Similarly, the sender-SMTP MAY support multiple concurrent
-            outgoing mail transactions to achieve timely delivery.
-            However, some limit SHOULD be imposed to protect the host
-            from devoting all its resources to mail.
-
-            The use of the different addresses of a multihomed host is
-            discussed below.
-
-         5.3.1.2  Receiving strategy
-
-            The receiver-SMTP SHOULD attempt to keep a pending listen on
-            the SMTP port at all times.  This will require the support
-            of multiple incoming TCP connections for SMTP.  Some limit
-            MAY be imposed.
-
-            IMPLEMENTATION:
-                 When the receiver-SMTP receives mail from a particular
-                 host address, it could notify the sender-SMTP to retry
-                 any mail pending for that host address.
-
-      5.3.2  Timeouts in SMTP
-
-         There are two approaches to timeouts in the sender-SMTP:  (a)
-         limit the time for each SMTP command separately, or (b) limit
-         the time for the entire SMTP dialogue for a single mail
-         message.  A sender-SMTP SHOULD use option (a), per-command
-         timeouts.  Timeouts SHOULD be easily reconfigurable, preferably
-         without recompiling the SMTP code.
-
-         DISCUSSION:
-              Timeouts are an essential feature of an SMTP
-              implementation.  If the timeouts are too long (or worse,
-              there are no timeouts), Internet communication failures or
-              software bugs in receiver-SMTP programs can tie up SMTP
-              processes indefinitely.  If the timeouts are too short,
-              resources will be wasted with attempts that time out part
-              way through message delivery.
-
-              If option (b) is used, the timeout has to be very large,
-              e.g., an hour, to allow time to expand very large mailing
-              lists.  The timeout may also need to increase linearly
-
-
-
-Internet Engineering Task Force                                [Page 61]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-              with the size of the message, to account for the time to
-              transmit a very large message.  A large fixed timeout
-              leads to two problems:  a failure can still tie up the
-              sender for a very long time, and very large messages may
-              still spuriously time out (which is a wasteful failure!).
-
-              Using the recommended option (a), a timer is set for each
-              SMTP command and for each buffer of the data transfer.
-              The latter means that the overall timeout is inherently
-              proportional to the size of the message.
-
-         Based on extensive experience with busy mail-relay hosts, the
-         minimum per-command timeout values SHOULD be as follows:
-
-         o    Initial 220 Message: 5 minutes
-
-              A Sender-SMTP process needs to distinguish between a
-              failed TCP connection and a delay in receiving the initial
-              220 greeting message.  Many receiver-SMTPs will accept a
-              TCP connection but delay delivery of the 220 message until
-              their system load will permit more mail to be processed.
-
-         o    MAIL Command: 5 minutes
-
-
-         o    RCPT Command: 5 minutes
-
-              A longer timeout would be required if processing of
-              mailing lists and aliases were not deferred until after
-              the message was accepted.
-
-         o    DATA Initiation: 2 minutes
-
-              This is while awaiting the "354 Start Input" reply to a
-              DATA command.
-
-         o    Data Block: 3 minutes
-
-              This is while awaiting the completion of each TCP SEND
-              call transmitting a chunk of data.
-
-         o    DATA Termination: 10 minutes.
-
-              This is while awaiting the "250 OK" reply. When the
-              receiver gets the final period terminating the message
-              data, it typically performs processing to deliver the
-              message to a user mailbox.  A spurious timeout at this
-              point would be very wasteful, since the message has been
-
-
-
-Internet Engineering Task Force                                [Page 62]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-              successfully sent.
-
-         A receiver-SMTP SHOULD have a timeout of at least 5 minutes
-         while it is awaiting the next command from the sender.
-
-      5.3.3  Reliable Mail Receipt
-
-         When the receiver-SMTP accepts a piece of mail (by sending a
-         "250 OK" message in response to DATA), it is accepting
-         responsibility for delivering or relaying the message.  It must
-         take this responsibility seriously, i.e., it MUST NOT lose the
-         message for frivolous reasons, e.g., because the host later
-         crashes or because of a predictable resource shortage.
-
-         If there is a delivery failure after acceptance of a message,
-         the receiver-SMTP MUST formulate and mail a notification
-         message.  This notification MUST be sent using a null ("<>")
-         reverse path in the envelope; see Section 3.6 of RFC-821.  The
-         recipient of this notification SHOULD be the address from the
-         envelope return path (or the Return-Path: line).  However, if
-         this address is null ("<>"),  the receiver-SMTP MUST NOT send a
-         notification.  If the address is an explicit source route, it
-         SHOULD be stripped down to its final hop.
-
-         DISCUSSION:
-              For example, suppose that an error notification must be
-              sent for a message that arrived with:
-              "MAIL FROM:<@a,@b:user@d>".  The notification message
-              should be sent to: "RCPT TO:<user@d>".
-
-              Some delivery failures after the message is accepted by
-              SMTP will be unavoidable.  For example, it may be
-              impossible for the receiver-SMTP to validate all the
-              delivery addresses in RCPT command(s) due to a "soft"
-              domain system error or because the target is a mailing
-              list (see earlier discussion of RCPT).
-
-         To avoid receiving duplicate messages as the result of
-         timeouts, a receiver-SMTP MUST seek to minimize the time
-         required to respond to the final "." that ends a message
-         transfer.  See RFC-1047 [SMTP:4] for a discussion of this
-         problem.
-
-      5.3.4  Reliable Mail Transmission
-
-         To transmit a message, a sender-SMTP determines the IP address
-         of the target host from the destination address in the
-         envelope.  Specifically, it maps the string to the right of the
-
-
-
-Internet Engineering Task Force                                [Page 63]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-         "@" sign into an IP address.  This mapping or the transfer
-         itself may fail with a soft error, in which case the sender-
-         SMTP will requeue the outgoing mail for a later retry, as
-         required in Section 5.3.1.1.
-
-         When it succeeds, the mapping can result in a list of
-         alternative delivery addresses rather than a single address,
-         because of (a) multiple MX records, (b) multihoming, or both.
-         To provide reliable mail transmission, the sender-SMTP MUST be
-         able to try (and retry) each of the addresses in this list in
-         order, until a delivery attempt succeeds.  However, there MAY
-         also be a configurable limit on the number of alternate
-         addresses that can be tried.  In any case, a host SHOULD try at
-         least two addresses.
-
-         The following information is to be used to rank the host
-         addresses:
-
-         (1)  Multiple MX Records -- these contain a preference
-              indication that should be used in sorting.  If there are
-              multiple destinations with the same preference and there
-              is no clear reason to favor one (e.g., by address
-              preference), then the sender-SMTP SHOULD pick one at
-              random to spread the load across multiple mail exchanges
-              for a specific organization; note that this is a
-              refinement of the procedure in [DNS:3].
-
-         (2)  Multihomed host -- The destination host (perhaps taken
-              from the preferred MX record) may be multihomed, in which
-              case the domain name resolver will return a list of
-              alternative IP addresses.  It is the responsibility of the
-              domain name resolver interface (see Section 6.1.3.4 below)
-              to have ordered this list by decreasing preference, and
-              SMTP MUST try them in the order presented.
-
-         DISCUSSION:
-              Although the capability to try multiple alternative
-              addresses is required, there may be circumstances where
-              specific installations want to limit or disable the use of
-              alternative addresses.  The question of whether a sender
-              should attempt retries using the different addresses of a
-              multihomed host has been controversial.  The main argument
-              for using the multiple addresses is that it maximizes the
-              probability of timely delivery, and indeed sometimes the
-              probability of any delivery; the counter argument is that
-              it may result in unnecessary resource use.
-
-              Note that resource use is also strongly determined by the
-
-
-
-Internet Engineering Task Force                                [Page 64]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-              sending strategy discussed in Section 5.3.1.
-
-      5.3.5  Domain Name Support
-
-         SMTP implementations MUST use the mechanism defined in Section
-         6.1 for mapping between domain names and IP addresses.  This
-         means that every Internet SMTP MUST include support for the
-         Internet DNS.
-
-         In particular, a sender-SMTP MUST support the MX record scheme
-         [SMTP:3].  See also Section 7.4 of [DNS:2] for information on
-         domain name support for SMTP.
-
-      5.3.6  Mailing Lists and Aliases
-
-         An SMTP-capable host SHOULD support both the alias and the list
-         form of address expansion for multiple delivery.  When a
-         message is delivered or forwarded to each address of an
-         expanded list form, the return address in the envelope
-         ("MAIL FROM:") MUST be changed to be the address of a person
-         who administers the list, but the message header MUST be left
-         unchanged; in particular, the "From" field of the message is
-         unaffected.
-
-         DISCUSSION:
-              An important mail facility is a mechanism for multi-
-              destination delivery of a single message, by transforming
-              or "expanding" a pseudo-mailbox address into a list of
-              destination mailbox addresses.  When a message is sent to
-              such a pseudo-mailbox (sometimes called an "exploder"),
-              copies are forwarded or redistributed to each mailbox in
-              the expanded list.  We classify such a pseudo-mailbox as
-              an "alias" or a "list", depending upon the expansion
-              rules:
-
-              (a)  Alias
-
-                   To expand an alias, the recipient mailer simply
-                   replaces the pseudo-mailbox address in the envelope
-                   with each of the expanded addresses in turn; the rest
-                   of the envelope and the message body are left
-                   unchanged.  The message is then delivered or
-                   forwarded to each expanded address.
-
-              (b)  List
-
-                   A mailing list may be said to operate by
-                   "redistribution" rather than by "forwarding".  To
-
-
-
-Internet Engineering Task Force                                [Page 65]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-                   expand a list, the recipient mailer replaces the
-                   pseudo-mailbox address in the envelope with each of
-                   the expanded addresses in turn. The return address in
-                   the envelope is changed so that all error messages
-                   generated by the final deliveries will be returned to
-                   a list administrator, not to the message originator,
-                   who generally has no control over the contents of the
-                   list and will typically find error messages annoying.
-
-
-      5.3.7  Mail Gatewaying
-
-         Gatewaying mail between different mail environments, i.e.,
-         different mail formats and protocols, is complex and does not
-         easily yield to standardization.  See for example [SMTP:5a],
-         [SMTP:5b].  However, some general requirements may be given for
-         a gateway between the Internet and another mail environment.
-
-         (A)  Header fields MAY be rewritten when necessary as messages
-              are gatewayed across mail environment boundaries.
-
-              DISCUSSION:
-                   This may involve interpreting the local-part of the
-                   destination address, as suggested in Section 5.2.16.
-
-                   The other mail systems gatewayed to the Internet
-                   generally use a subset of RFC-822 headers, but some
-                   of them do not have an equivalent to the SMTP
-                   envelope.  Therefore, when a message leaves the
-                   Internet environment, it may be necessary to fold the
-                   SMTP envelope information into the message header.  A
-                   possible solution would be to create new header
-                   fields to carry the envelope information (e.g., "X-
-                   SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would
-                   require changes in mail programs in the foreign
-                   environment.
-
-         (B)  When forwarding a message into or out of the Internet
-              environment, a gateway MUST prepend a Received: line, but
-              it MUST NOT alter in any way a Received: line that is
-              already in the header.
-
-              DISCUSSION:
-                   This requirement is a subset of the general
-                   "Received:" line requirement of Section 5.2.8; it is
-                   restated here for emphasis.
-
-                   Received: fields of messages originating from other
-
-
-
-Internet Engineering Task Force                                [Page 66]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-                   environments may not conform exactly to RFC822.
-                   However, the most important use of Received: lines is
-                   for debugging mail faults, and this debugging can be
-                   severely hampered by well-meaning gateways that try
-                   to "fix" a Received: line.
-
-                   The gateway is strongly encouraged to indicate the
-                   environment and protocol in the "via" clauses of
-                   Received field(s) that it supplies.
-
-         (C)  From the Internet side, the gateway SHOULD accept all
-              valid address formats in SMTP commands and in RFC-822
-              headers, and all valid RFC-822 messages.  Although a
-              gateway must accept an RFC-822 explicit source route
-              ("@...:" format) in either the RFC-822 header or in the
-              envelope, it MAY or may not act on the source route; see
-              Sections 5.2.6 and 5.2.19.
-
-              DISCUSSION:
-                   It is often tempting to restrict the range of
-                   addresses accepted at the mail gateway to simplify
-                   the translation into addresses for the remote
-                   environment.  This practice is based on the
-                   assumption that mail users have control over the
-                   addresses their mailers send to the mail gateway.  In
-                   practice, however, users have little control over the
-                   addresses that are finally sent; their mailers are
-                   free to change addresses into any legal RFC-822
-                   format.
-
-         (D)  The gateway MUST ensure that all header fields of a
-              message that it forwards into the Internet meet the
-              requirements for Internet mail.  In particular, all
-              addresses in "From:", "To:", "Cc:", etc., fields must be
-              transformed (if necessary) to satisfy RFC-822 syntax, and
-              they must be effective and useful for sending replies.
-
-
-         (E)  The translation algorithm used to convert mail from the
-              Internet protocols to another environment's protocol
-              SHOULD try to ensure that error messages from the foreign
-              mail environment are delivered to the return path from the
-              SMTP envelope, not to the sender listed in the "From:"
-              field of the RFC-822 message.
-
-              DISCUSSION:
-                   Internet mail lists usually place the address of the
-                   mail list maintainer in the envelope but leave the
-
-
-
-Internet Engineering Task Force                                [Page 67]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-                   original message header intact (with the "From:"
-                   field containing the original sender).  This yields
-                   the behavior the average recipient expects: a reply
-                   to the header gets sent to the original sender, not
-                   to a mail list maintainer; however, errors get sent
-                   to the maintainer (who can fix the problem) and not
-                   the sender (who probably cannot).
-
-         (F)  Similarly, when forwarding a message from another
-              environment into the Internet, the gateway SHOULD set the
-              envelope return path in accordance with an error message
-              return address, if any, supplied by the foreign
-              environment.
-
-
-      5.3.8  Maximum Message Size
-
-         Mailer software MUST be able to send and receive messages of at
-         least 64K bytes in length (including header), and a much larger
-         maximum size is highly desirable.
-
-         DISCUSSION:
-              Although SMTP does not define the maximum size of a
-              message, many systems impose implementation limits.
-
-              The current de facto minimum limit in the Internet is 64K
-              bytes.  However, electronic mail is used for a variety of
-              purposes that create much larger messages.  For example,
-              mail is often used instead of FTP for transmitting ASCII
-              files, and in particular to transmit entire documents.  As
-              a result, messages can be 1 megabyte or even larger.  We
-              note that the present document together with its lower-
-              layer companion contains 0.5 megabytes.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 68]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-   5.4  SMTP REQUIREMENTS SUMMARY
-
-                                               |          | | | |S| |
-                                               |          | | | |H| |F
-                                               |          | | | |O|M|o
-                                               |          | |S| |U|U|o
-                                               |          | |H| |L|S|t
-                                               |          |M|O| |D|T|n
-                                               |          |U|U|M| | |o
-                                               |          |S|L|A|N|N|t
-                                               |          |T|D|Y|O|O|t
-FEATURE                                        |SECTION   | | | |T|T|e
------------------------------------------------|----------|-|-|-|-|-|--
-                                               |          | | | | | |
-RECEIVER-SMTP:                                 |          | | | | | |
-  Implement VRFY                               |5.2.3     |x| | | | |
-  Implement EXPN                               |5.2.3     | |x| | | |
-    EXPN, VRFY configurable                    |5.2.3     | | |x| | |
-  Implement SEND, SOML, SAML                   |5.2.4     | | |x| | |
-  Verify HELO parameter                        |5.2.5     | | |x| | |
-    Refuse message with bad HELO               |5.2.5     | | | | |x|
-  Accept explicit src-route syntax in env.     |5.2.6     |x| | | | |
-  Support "postmaster"                         |5.2.7     |x| | | | |
-  Process RCPT when received (except lists)    |5.2.7     | | |x| | |
-      Long delay of RCPT responses             |5.2.7     | | | | |x|
-                                               |          | | | | | |
-  Add Received: line                           |5.2.8     |x| | | | |
-      Received: line include domain literal    |5.2.8     | |x| | | |
-  Change previous Received: line               |5.2.8     | | | | |x|
-  Pass Return-Path info (final deliv/gwy)      |5.2.8     |x| | | | |
-  Support empty reverse path                   |5.2.9     |x| | | | |
-  Send only official reply codes               |5.2.10    | |x| | | |
-  Send text from RFC-821 when appropriate      |5.2.10    | |x| | | |
-  Delete "." for transparency                  |5.2.11    |x| | | | |
-  Accept and recognize self domain literal(s)  |5.2.17    |x| | | | |
-                                               |          | | | | | |
-  Error message about error message            |5.3.1     | | | | |x|
-  Keep pending listen on SMTP port             |5.3.1.2   | |x| | | |
-  Provide limit on recv concurrency            |5.3.1.2   | | |x| | |
-  Wait at least 5 mins for next sender cmd     |5.3.2     | |x| | | |
-  Avoidable delivery failure after "250 OK"    |5.3.3     | | | | |x|
-  Send error notification msg after accept     |5.3.3     |x| | | | |
-    Send using null return path                |5.3.3     |x| | | | |
-    Send to envelope return path               |5.3.3     | |x| | | |
-    Send to null address                       |5.3.3     | | | | |x|
-    Strip off explicit src route               |5.3.3     | |x| | | |
-  Minimize acceptance delay (RFC-1047)         |5.3.3     |x| | | | |
------------------------------------------------|----------|-|-|-|-|-|--
-
-
-
-Internet Engineering Task Force                                [Page 69]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-                                               |          | | | | | |
-SENDER-SMTP:                                   |          | | | | | |
-  Canonicalized domain names in MAIL, RCPT     |5.2.2     |x| | | | |
-  Implement SEND, SOML, SAML                   |5.2.4     | | |x| | |
-  Send valid principal host name in HELO       |5.2.5     |x| | | | |
-  Send explicit source route in RCPT TO:       |5.2.6     | | | |x| |
-  Use only reply code to determine action      |5.2.10    |x| | | | |
-  Use only high digit of reply code when poss. |5.2.10    | |x| | | |
-  Add "." for transparency                     |5.2.11    |x| | | | |
-                                               |          | | | | | |
-  Retry messages after soft failure            |5.3.1.1   |x| | | | |
-    Delay before retry                         |5.3.1.1   |x| | | | |
-    Configurable retry parameters              |5.3.1.1   |x| | | | |
-    Retry once per each queued dest host       |5.3.1.1   | |x| | | |
-  Multiple RCPT's for same DATA                |5.3.1.1   | |x| | | |
-  Support multiple concurrent transactions     |5.3.1.1   | | |x| | |
-    Provide limit on concurrency               |5.3.1.1   | |x| | | |
-                                               |          | | | | | |
-  Timeouts on all activities                   |5.3.1     |x| | | | |
-    Per-command timeouts                       |5.3.2     | |x| | | |
-    Timeouts easily reconfigurable             |5.3.2     | |x| | | |
-    Recommended times                          |5.3.2     | |x| | | |
-  Try alternate addr's in order                |5.3.4     |x| | | | |
-    Configurable limit on alternate tries      |5.3.4     | | |x| | |
-    Try at least two alternates                |5.3.4     | |x| | | |
-  Load-split across equal MX alternates        |5.3.4     | |x| | | |
-  Use the Domain Name System                   |5.3.5     |x| | | | |
-    Support MX records                         |5.3.5     |x| | | | |
-    Use WKS records in MX processing           |5.2.12    | | | |x| |
------------------------------------------------|----------|-|-|-|-|-|--
-                                               |          | | | | | |
-MAIL FORWARDING:                               |          | | | | | |
-  Alter existing header field(s)               |5.2.6     | | | |x| |
-  Implement relay function: 821/section 3.6    |5.2.6     | | |x| | |
-    If not, deliver to RHS domain              |5.2.6     | |x| | | |
-  Interpret 'local-part' of addr               |5.2.16    | | | | |x|
-                                               |          | | | | | |
-MAILING LISTS AND ALIASES                      |          | | | | | |
-  Support both                                 |5.3.6     | |x| | | |
-  Report mail list error to local admin.       |5.3.6     |x| | | | |
-                                               |          | | | | | |
-MAIL GATEWAYS:                                 |          | | | | | |
-  Embed foreign mail route in local-part       |5.2.16    | | |x| | |
-  Rewrite header fields when necessary         |5.3.7     | | |x| | |
-  Prepend Received: line                       |5.3.7     |x| | | | |
-  Change existing Received: line               |5.3.7     | | | | |x|
-  Accept full RFC-822 on Internet side         |5.3.7     | |x| | | |
-  Act on RFC-822 explicit source route         |5.3.7     | | |x| | |
-
-
-
-Internet Engineering Task Force                                [Page 70]
-
-
-
-
-RFC1123                  MAIL -- SMTP & RFC-822             October 1989
-
-
-  Send only valid RFC-822 on Internet side     |5.3.7     |x| | | | |
-  Deliver error msgs to envelope addr          |5.3.7     | |x| | | |
-  Set env return path from err return addr     |5.3.7     | |x| | | |
-                                               |          | | | | | |
-USER AGENT -- RFC-822                          |          | | | | | |
-  Allow user to enter <route> address          |5.2.6     | | | |x| |
-  Support RFC-1049 Content Type field          |5.2.13    | | |x| | |
-  Use 4-digit years                            |5.2.14    | |x| | | |
-  Generate numeric timezones                   |5.2.14    | |x| | | |
-  Accept all timezones                         |5.2.14    |x| | | | |
-  Use non-num timezones from RFC-822           |5.2.14    |x| | | | |
-  Omit phrase before route-addr                |5.2.15    | | |x| | |
-  Accept and parse dot.dec. domain literals    |5.2.17    |x| | | | |
-  Accept all RFC-822 address formats           |5.2.18    |x| | | | |
-  Generate invalid RFC-822 address format      |5.2.18    | | | | |x|
-  Fully-qualified domain names in header       |5.2.18    |x| | | | |
-  Create explicit src route in header          |5.2.19    | | | |x| |
-  Accept explicit src route in header          |5.2.19    |x| | | | |
-                                               |          | | | | | |
-Send/recv at least 64KB messages               |5.3.8     |x| | | | |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 71]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-6. SUPPORT SERVICES
-
-   6.1 DOMAIN NAME TRANSLATION
-
-      6.1.1 INTRODUCTION
-
-         Every host MUST implement a resolver for the Domain Name System
-         (DNS), and it MUST implement a mechanism using this DNS
-         resolver to convert host names to IP addresses and vice-versa
-         [DNS:1, DNS:2].
-
-         In addition to the DNS, a host MAY also implement a host name
-         translation mechanism that searches a local Internet host
-         table.  See Section 6.1.3.8 for more information on this
-         option.
-
-         DISCUSSION:
-              Internet host name translation was originally performed by
-              searching local copies of a table of all hosts.  This
-              table became too large to update and distribute in a
-              timely manner and too large to fit into many hosts, so the
-              DNS was invented.
-
-              The DNS creates a distributed database used primarily for
-              the translation between host names and host addresses.
-              Implementation of DNS software is required.  The DNS
-              consists of two logically distinct parts: name servers and
-              resolvers (although implementations often combine these
-              two logical parts in the interest of efficiency) [DNS:2].
-
-              Domain name servers store authoritative data about certain
-              sections of the database and answer queries about the
-              data.  Domain resolvers query domain name servers for data
-              on behalf of user processes.  Every host therefore needs a
-              DNS resolver; some host machines will also need to run
-              domain name servers.  Since no name server has complete
-              information, in general it is necessary to obtain
-              information from more than one name server to resolve a
-              query.
-
-      6.1.2  PROTOCOL WALK-THROUGH
-
-         An implementor must study references [DNS:1] and [DNS:2]
-         carefully.  They provide a thorough description of the theory,
-         protocol, and implementation of the domain name system, and
-         reflect several years of experience.
-
-
-
-
-
-Internet Engineering Task Force                                [Page 72]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-         6.1.2.1  Resource Records with Zero TTL: RFC-1035 Section 3.2.1
-
-            All DNS name servers and resolvers MUST properly handle RRs
-            with a zero TTL: return the RR to the client but do not
-            cache it.
-
-            DISCUSSION:
-                 Zero TTL values are interpreted to mean that the RR can
-                 only be used for the transaction in progress, and
-                 should not be cached; they are useful for extremely
-                 volatile data.
-
-         6.1.2.2  QCLASS Values: RFC-1035 Section 3.2.5
-
-            A query with "QCLASS=*" SHOULD NOT be used unless the
-            requestor is seeking data from more than one class.  In
-            particular, if the requestor is only interested in Internet
-            data types, QCLASS=IN MUST be used.
-
-         6.1.2.3  Unused Fields: RFC-1035 Section 4.1.1
-
-            Unused fields in a query or response message MUST be zero.
-
-         6.1.2.4  Compression: RFC-1035 Section 4.1.4
-
-            Name servers MUST use compression in responses.
-
-            DISCUSSION:
-                 Compression is essential to avoid overflowing UDP
-                 datagrams; see Section 6.1.3.2.
-
-         6.1.2.5  Misusing Configuration Info: RFC-1035 Section 6.1.2
-
-            Recursive name servers and full-service resolvers generally
-            have some configuration information containing hints about
-            the location of root or local name servers.  An
-            implementation MUST NOT include any of these hints in a
-            response.
-
-            DISCUSSION:
-                 Many implementors have found it convenient to store
-                 these hints as if they were cached data, but some
-                 neglected to ensure that this "cached data" was not
-                 included in responses.  This has caused serious
-                 problems in the Internet when the hints were obsolete
-                 or incorrect.
-
-
-
-
-
-Internet Engineering Task Force                                [Page 73]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-      6.1.3  SPECIFIC ISSUES
-
-         6.1.3.1  Resolver Implementation
-
-            A name resolver SHOULD be able to multiplex concurrent
-            requests if the host supports concurrent processes.
-
-            In implementing a DNS resolver, one of two different models
-            MAY optionally be chosen: a full-service resolver, or a stub
-            resolver.
-
-
-            (A)  Full-Service Resolver
-
-                 A full-service resolver is a complete implementation of
-                 the resolver service, and is capable of dealing with
-                 communication failures, failure of individual name
-                 servers, location of the proper name server for a given
-                 name, etc.  It must satisfy the following requirements:
-
-                 o    The resolver MUST implement a local caching
-                      function to avoid repeated remote access for
-                      identical requests, and MUST time out information
-                      in the cache.
-
-                 o    The resolver SHOULD be configurable with start-up
-                      information pointing to multiple root name servers
-                      and multiple name servers for the local domain.
-                      This insures that the resolver will be able to
-                      access the whole name space in normal cases, and
-                      will be able to access local domain information
-                      should the local network become disconnected from
-                      the rest of the Internet.
-
-
-            (B)  Stub Resolver
-
-                 A "stub resolver" relies on the services of a recursive
-                 name server on the connected network or a "nearby"
-                 network.  This scheme allows the host to pass on the
-                 burden of the resolver function to a name server on
-                 another host.  This model is often essential for less
-                 capable hosts, such as PCs, and is also recommended
-                 when the host is one of several workstations on a local
-                 network, because it allows all of the workstations to
-                 share the cache of the recursive name server and hence
-                 reduce the number of domain requests exported by the
-                 local network.
-
-
-
-Internet Engineering Task Force                                [Page 74]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-                 At a minimum, the stub resolver MUST be capable of
-                 directing its requests to redundant recursive name
-                 servers.  Note that recursive name servers are allowed
-                 to restrict the sources of requests that they will
-                 honor, so the host administrator must verify that the
-                 service will be provided.  Stub resolvers MAY implement
-                 caching if they choose, but if so, MUST timeout cached
-                 information.
-
-
-         6.1.3.2  Transport Protocols
-
-            DNS resolvers and recursive servers MUST support UDP, and
-            SHOULD support TCP, for sending (non-zone-transfer) queries.
-            Specifically, a DNS resolver or server that is sending a
-            non-zone-transfer query MUST send a UDP query first.  If the
-            Answer section of the response is truncated and if the
-            requester supports TCP, it SHOULD try the query again using
-            TCP.
-
-            DNS servers MUST be able to service UDP queries and SHOULD
-            be able to service TCP queries.  A name server MAY limit the
-            resources it devotes to TCP queries, but it SHOULD NOT
-            refuse to service a TCP query just because it would have
-            succeeded with UDP.
-
-            Truncated responses MUST NOT be saved (cached) and later
-            used in such a way that the fact that they are truncated is
-            lost.
-
-            DISCUSSION:
-                 UDP is preferred over TCP for queries because UDP
-                 queries have much lower overhead, both in packet count
-                 and in connection state.  The use of UDP is essential
-                 for heavily-loaded servers, especially the root
-                 servers.  UDP also offers additional robustness, since
-                 a resolver can attempt several UDP queries to different
-                 servers for the cost of a single TCP query.
-
-                 It is possible for a DNS response to be truncated,
-                 although this is a very rare occurrence in the present
-                 Internet DNS.  Practically speaking, truncation cannot
-                 be predicted, since it is data-dependent.  The
-                 dependencies include the number of RRs in the answer,
-                 the size of each RR, and the savings in space realized
-                 by the name compression algorithm.  As a rule of thumb,
-                 truncation in NS and MX lists should not occur for
-                 answers containing 15 or fewer RRs.
-
-
-
-Internet Engineering Task Force                                [Page 75]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-                 Whether it is possible to use a truncated answer
-                 depends on the application.  A mailer must not use a
-                 truncated MX response, since this could lead to mail
-                 loops.
-
-                 Responsible practices can make UDP suffice in the vast
-                 majority of cases.  Name servers must use compression
-                 in responses.  Resolvers must differentiate truncation
-                 of the Additional section of a response (which only
-                 loses extra information) from truncation of the Answer
-                 section (which for MX records renders the response
-                 unusable by mailers).  Database administrators should
-                 list only a reasonable number of primary names in lists
-                 of name servers, MX alternatives, etc.
-
-                 However, it is also clear that some new DNS record
-                 types defined in the future will contain information
-                 exceeding the 512 byte limit that applies to UDP, and
-                 hence will require TCP.  Thus, resolvers and name
-                 servers should implement TCP services as a backup to
-                 UDP today, with the knowledge that they will require
-                 the TCP service in the future.
-
-            By private agreement, name servers and resolvers MAY arrange
-            to use TCP for all traffic between themselves.  TCP MUST be
-            used for zone transfers.
-
-            A DNS server MUST have sufficient internal concurrency that
-            it can continue to process UDP queries while awaiting a
-            response or performing a zone transfer on an open TCP
-            connection [DNS:2].
-
-            A server MAY support a UDP query that is delivered using an
-            IP broadcast or multicast address.  However, the Recursion
-            Desired bit MUST NOT be set in a query that is multicast,
-            and MUST be ignored by name servers receiving queries via a
-            broadcast or multicast address.  A host that sends broadcast
-            or multicast DNS queries SHOULD send them only as occasional
-            probes, caching the IP address(es) it obtains from the
-            response(s) so it can normally send unicast queries.
-
-            DISCUSSION:
-                 Broadcast or (especially) IP multicast can provide a
-                 way to locate nearby name servers without knowing their
-                 IP addresses in advance.  However, general broadcasting
-                 of recursive queries can result in excessive and
-                 unnecessary load on both network and servers.
-
-
-
-
-Internet Engineering Task Force                                [Page 76]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-         6.1.3.3  Efficient Resource Usage
-
-            The following requirements on servers and resolvers are very
-            important to the health of the Internet as a whole,
-            particularly when DNS services are invoked repeatedly by
-            higher level automatic servers, such as mailers.
-
-            (1)  The resolver MUST implement retransmission controls to
-                 insure that it does not waste communication bandwidth,
-                 and MUST impose finite bounds on the resources consumed
-                 to respond to a single request.  See [DNS:2] pages 43-
-                 44 for specific recommendations.
-
-            (2)  After a query has been retransmitted several times
-                 without a response, an implementation MUST give up and
-                 return a soft error to the application.
-
-            (3)  All DNS name servers and resolvers SHOULD cache
-                 temporary failures, with a timeout period of the order
-                 of minutes.
-
-                 DISCUSSION:
-                      This will prevent applications that immediately
-                      retry soft failures (in violation of Section 2.2
-                      of this document) from generating excessive DNS
-                      traffic.
-
-            (4)  All DNS name servers and resolvers SHOULD cache
-                 negative responses that indicate the specified name, or
-                 data of the specified type, does not exist, as
-                 described in [DNS:2].
-
-            (5)  When a DNS server or resolver retries a UDP query, the
-                 retry interval SHOULD be constrained by an exponential
-                 backoff algorithm, and SHOULD also have upper and lower
-                 bounds.
-
-                 IMPLEMENTATION:
-                      A measured RTT and variance (if available) should
-                      be used to calculate an initial retransmission
-                      interval.  If this information is not available, a
-                      default of no less than 5 seconds should be used.
-                      Implementations may limit the retransmission
-                      interval, but this limit must exceed twice the
-                      Internet maximum segment lifetime plus service
-                      delay at the name server.
-
-            (6)  When a resolver or server receives a Source Quench for
-
-
-
-Internet Engineering Task Force                                [Page 77]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-                 a query it has issued, it SHOULD take steps to reduce
-                 the rate of querying that server in the near future.  A
-                 server MAY ignore a Source Quench that it receives as
-                 the result of sending a response datagram.
-
-                 IMPLEMENTATION:
-                      One recommended action to reduce the rate is to
-                      send the next query attempt to an alternate
-                      server, if there is one available.  Another is to
-                      backoff the retry interval for the same server.
-
-
-         6.1.3.4  Multihomed Hosts
-
-            When the host name-to-address function encounters a host
-            with multiple addresses, it SHOULD rank or sort the
-            addresses using knowledge of the immediately connected
-            network number(s) and any other applicable performance or
-            history information.
-
-            DISCUSSION:
-                 The different addresses of a multihomed host generally
-                 imply different Internet paths, and some paths may be
-                 preferable to others in performance, reliability, or
-                 administrative restrictions.  There is no general way
-                 for the domain system to determine the best path.  A
-                 recommended approach is to base this decision on local
-                 configuration information set by the system
-                 administrator.
-
-            IMPLEMENTATION:
-                 The following scheme has been used successfully:
-
-                 (a)  Incorporate into the host configuration data a
-                      Network-Preference List, that is simply a list of
-                      networks in preferred order.  This list may be
-                      empty if there is no preference.
-
-                 (b)  When a host name is mapped into a list of IP
-                      addresses, these addresses should be sorted by
-                      network number, into the same order as the
-                      corresponding networks in the Network-Preference
-                      List.  IP addresses whose networks do not appear
-                      in the Network-Preference List should be placed at
-                      the end of the list.
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 78]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-         6.1.3.5  Extensibility
-
-            DNS software MUST support all well-known, class-independent
-            formats [DNS:2], and SHOULD be written to minimize the
-            trauma associated with the introduction of new well-known
-            types and local experimentation with non-standard types.
-
-            DISCUSSION:
-                 The data types and classes used by the DNS are
-                 extensible, and thus new types will be added and old
-                 types deleted or redefined.  Introduction of new data
-                 types ought to be dependent only upon the rules for
-                 compression of domain names inside DNS messages, and
-                 the translation between printable (i.e., master file)
-                 and internal formats for Resource Records (RRs).
-
-                 Compression relies on knowledge of the format of data
-                 inside a particular RR.  Hence compression must only be
-                 used for the contents of well-known, class-independent
-                 RRs, and must never be used for class-specific RRs or
-                 RR types that are not well-known.  The owner name of an
-                 RR is always eligible for compression.
-
-                 A name server may acquire, via zone transfer, RRs that
-                 the server doesn't know how to convert to printable
-                 format.  A resolver can receive similar information as
-                 the result of queries.  For proper operation, this data
-                 must be preserved, and hence the implication is that
-                 DNS software cannot use textual formats for internal
-                 storage.
-
-                 The DNS defines domain name syntax very generally -- a
-                 string of labels each containing up to 63 8-bit octets,
-                 separated by dots, and with a maximum total of 255
-                 octets.  Particular applications of the DNS are
-                 permitted to further constrain the syntax of the domain
-                 names they use, although the DNS deployment has led to
-                 some applications allowing more general names.  In
-                 particular, Section 2.1 of this document liberalizes
-                 slightly the syntax of a legal Internet host name that
-                 was defined in RFC-952 [DNS:4].
-
-         6.1.3.6  Status of RR Types
-
-            Name servers MUST be able to load all RR types except MD and
-            MF from configuration files.  The MD and MF types are
-            obsolete and MUST NOT be implemented; in particular, name
-            servers MUST NOT load these types from configuration files.
-
-
-
-Internet Engineering Task Force                                [Page 79]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-            DISCUSSION:
-                 The RR types MB, MG, MR, NULL, MINFO and RP are
-                 considered experimental, and applications that use the
-                 DNS cannot expect these RR types to be supported by
-                 most domains.  Furthermore these types are subject to
-                 redefinition.
-
-                 The TXT and WKS RR types have not been widely used by
-                 Internet sites; as a result, an application cannot rely
-                 on the the existence of a TXT or WKS RR in most
-                 domains.
-
-         6.1.3.7  Robustness
-
-            DNS software may need to operate in environments where the
-            root servers or other servers are unavailable due to network
-            connectivity or other problems.  In this situation, DNS name
-            servers and resolvers MUST continue to provide service for
-            the reachable part of the name space, while giving temporary
-            failures for the rest.
-
-            DISCUSSION:
-                 Although the DNS is meant to be used primarily in the
-                 connected Internet, it should be possible to use the
-                 system in networks which are unconnected to the
-                 Internet.  Hence implementations must not depend on
-                 access to root servers before providing service for
-                 local names.
-
-         6.1.3.8  Local Host Table
-
-            DISCUSSION:
-                 A host may use a local host table as a backup or
-                 supplement to the DNS.  This raises the question of
-                 which takes precedence, the DNS or the host table; the
-                 most flexible approach would make this a configuration
-                 option.
-
-                 Typically, the contents of such a supplementary host
-                 table will be determined locally by the site.  However,
-                 a publically-available table of Internet hosts is
-                 maintained by the DDN Network Information Center (DDN
-                 NIC), with a format documented in [DNS:4].  This table
-                 can be retrieved from the DDN NIC using a protocol
-                 described in [DNS:5].  It must be noted that this table
-                 contains only a small fraction of all Internet hosts.
-                 Hosts using this protocol to retrieve the DDN NIC host
-                 table should use the VERSION command to check if the
-
-
-
-Internet Engineering Task Force                                [Page 80]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-                 table has changed before requesting the entire table
-                 with the ALL command.  The VERSION identifier should be
-                 treated as an arbitrary string and tested only for
-                 equality; no numerical sequence may be assumed.
-
-                 The DDN NIC host table includes administrative
-                 information that is not needed for host operation and
-                 is therefore not currently included in the DNS
-                 database; examples include network and gateway entries.
-                 However, much of this additional information will be
-                 added to the DNS in the future.  Conversely, the DNS
-                 provides essential services (in particular, MX records)
-                 that are not available from the DDN NIC host table.
-
-      6.1.4  DNS USER INTERFACE
-
-         6.1.4.1  DNS Administration
-
-            This document is concerned with design and implementation
-            issues in host software, not with administrative or
-            operational issues.  However, administrative issues are of
-            particular importance in the DNS, since errors in particular
-            segments of this large distributed database can cause poor
-            or erroneous performance for many sites.  These issues are
-            discussed in [DNS:6] and [DNS:7].
-
-         6.1.4.2  DNS User Interface
-
-            Hosts MUST provide an interface to the DNS for all
-            application programs running on the host.  This interface
-            will typically direct requests to a system process to
-            perform the resolver function [DNS:1, 6.1:2].
-
-            At a minimum, the basic interface MUST support a request for
-            all information of a specific type and class associated with
-            a specific name, and it MUST return either all of the
-            requested information, a hard error code, or a soft error
-            indication.  When there is no error, the basic interface
-            returns the complete response information without
-            modification, deletion, or ordering, so that the basic
-            interface will not need to be changed to accommodate new
-            data types.
-
-            DISCUSSION:
-                 The soft error indication is an essential part of the
-                 interface, since it may not always be possible to
-                 access particular information from the DNS; see Section
-                 6.1.3.3.
-
-
-
-Internet Engineering Task Force                                [Page 81]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-            A host MAY provide other DNS interfaces tailored to
-            particular functions, transforming the raw domain data into
-            formats more suited to these functions.  In particular, a
-            host MUST provide a DNS interface to facilitate translation
-            between host addresses and host names.
-
-         6.1.4.3 Interface Abbreviation Facilities
-
-            User interfaces MAY provide a method for users to enter
-            abbreviations for commonly-used names.  Although the
-            definition of such methods is outside of the scope of the
-            DNS specification, certain rules are necessary to insure
-            that these methods allow access to the entire DNS name space
-            and to prevent excessive use of Internet resources.
-
-            If an abbreviation method is provided, then:
-
-            (a)  There MUST be some convention for denoting that a name
-                 is already complete, so that the abbreviation method(s)
-                 are suppressed.  A trailing dot is the usual method.
-
-            (b)  Abbreviation expansion MUST be done exactly once, and
-                 MUST be done in the context in which the name was
-                 entered.
-
-
-            DISCUSSION:
-                 For example, if an abbreviation is used in a mail
-                 program for a destination, the abbreviation should be
-                 expanded into a full domain name and stored in the
-                 queued message with an indication that it is already
-                 complete.  Otherwise, the abbreviation might be
-                 expanded with a mail system search list, not the
-                 user's, or a name could grow due to repeated
-                 canonicalizations attempts interacting with wildcards.
-
-            The two most common abbreviation methods are:
-
-            (1)  Interface-level aliases
-
-                 Interface-level aliases are conceptually implemented as
-                 a list of alias/domain name pairs. The list can be
-                 per-user or per-host, and separate lists can be
-                 associated with different functions, e.g. one list for
-                 host name-to-address translation, and a different list
-                 for mail domains.  When the user enters a name, the
-                 interface attempts to match the name to the alias
-                 component of a list entry, and if a matching entry can
-
-
-
-Internet Engineering Task Force                                [Page 82]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-                 be found, the name is replaced by the domain name found
-                 in the pair.
-
-                 Note that interface-level aliases and CNAMEs are
-                 completely separate mechanisms; interface-level aliases
-                 are a local matter while CNAMEs are an Internet-wide
-                 aliasing mechanism which is a required part of any DNS
-                 implementation.
-
-            (2)  Search Lists
-
-                 A search list is conceptually implemented as an ordered
-                 list of domain names.  When the user enters a name, the
-                 domain names in the search list are used as suffixes to
-                 the user-supplied name, one by one, until a domain name
-                 with the desired associated data is found, or the
-                 search list is exhausted.  Search lists often contain
-                 the name of the local host's parent domain or other
-                 ancestor domains.  Search lists are often per-user or
-                 per-process.
-
-                 It SHOULD be possible for an administrator to disable a
-                 DNS search-list facility.  Administrative denial may be
-                 warranted in some cases, to prevent abuse of the DNS.
-
-                 There is danger that a search-list mechanism will
-                 generate excessive queries to the root servers while
-                 testing whether user input is a complete domain name,
-                 lacking a final period to mark it as complete.  A
-                 search-list mechanism MUST have one of, and SHOULD have
-                 both of, the following two provisions to prevent this:
-
-                 (a)  The local resolver/name server can implement
-                      caching  of negative responses (see Section
-                      6.1.3.3).
-
-                 (b)  The search list expander can require two or more
-                      interior dots in a generated domain name before it
-                      tries using the name in a query to non-local
-                      domain servers, such as the root.
-
-                 DISCUSSION:
-                      The intent of this requirement is to avoid
-                      excessive delay for the user as the search list is
-                      tested, and more importantly to prevent excessive
-                      traffic to the root and other high-level servers.
-                      For example, if the user supplied a name "X" and
-                      the search list contained the root as a component,
-
-
-
-Internet Engineering Task Force                                [Page 83]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-                      a query would have to consult a root server before
-                      the next search list alternative could be tried.
-                      The resulting load seen by the root servers and
-                      gateways near the root would be multiplied by the
-                      number of hosts in the Internet.
-
-                      The negative caching alternative limits the effect
-                      to the first time a name is used.  The interior
-                      dot rule is simpler to implement but can prevent
-                      easy use of some top-level names.
-
-
-      6.1.5  DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY
-
-                                               |           | | | |S| |
-                                               |           | | | |H| |F
-                                               |           | | | |O|M|o
-                                               |           | |S| |U|U|o
-                                               |           | |H| |L|S|t
-                                               |           |M|O| |D|T|n
-                                               |           |U|U|M| | |o
-                                               |           |S|L|A|N|N|t
-                                               |           |T|D|Y|O|O|t
-FEATURE                                        |SECTION    | | | |T|T|e
------------------------------------------------|-----------|-|-|-|-|-|--
-GENERAL ISSUES                                 |           | | | | | |
-                                               |           | | | | | |
-Implement DNS name-to-address conversion       |6.1.1      |x| | | | |
-Implement DNS address-to-name conversion       |6.1.1      |x| | | | |
-Support conversions using host table           |6.1.1      | | |x| | |
-Properly handle RR with zero TTL               |6.1.2.1    |x| | | | |
-Use QCLASS=* unnecessarily                     |6.1.2.2    | |x| | | |
-  Use QCLASS=IN for Internet class             |6.1.2.2    |x| | | | |
-Unused fields zero                             |6.1.2.3    |x| | | | |
-Use compression in responses                   |6.1.2.4    |x| | | | |
-                                               |           | | | | | |
-Include config info in responses               |6.1.2.5    | | | | |x|
-Support all well-known, class-indep. types     |6.1.3.5    |x| | | | |
-Easily expand type list                        |6.1.3.5    | |x| | | |
-Load all RR types (except MD and MF)           |6.1.3.6    |x| | | | |
-Load MD or MF type                             |6.1.3.6    | | | | |x|
-Operate when root servers, etc. unavailable    |6.1.3.7    |x| | | | |
------------------------------------------------|-----------|-|-|-|-|-|--
-RESOLVER ISSUES:                               |           | | | | | |
-                                               |           | | | | | |
-Resolver support multiple concurrent requests  |6.1.3.1    | |x| | | |
-Full-service resolver:                         |6.1.3.1    | | |x| | |
-  Local caching                                |6.1.3.1    |x| | | | |
-
-
-
-Internet Engineering Task Force                                [Page 84]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-  Information in local cache times out         |6.1.3.1    |x| | | | |
-  Configurable with starting info              |6.1.3.1    | |x| | | |
-Stub resolver:                                 |6.1.3.1    | | |x| | |
-  Use redundant recursive name servers         |6.1.3.1    |x| | | | |
-  Local caching                                |6.1.3.1    | | |x| | |
-  Information in local cache times out         |6.1.3.1    |x| | | | |
-Support for remote multi-homed hosts:          |           | | | | | |
-  Sort multiple addresses by preference list   |6.1.3.4    | |x| | | |
-                                               |           | | | | | |
------------------------------------------------|-----------|-|-|-|-|-|--
-TRANSPORT PROTOCOLS:                           |           | | | | | |
-                                               |           | | | | | |
-Support UDP queries                            |6.1.3.2    |x| | | | |
-Support TCP queries                            |6.1.3.2    | |x| | | |
-  Send query using UDP first                   |6.1.3.2    |x| | | | |1
-  Try TCP if UDP answers are truncated         |6.1.3.2    | |x| | | |
-Name server limit TCP query resources          |6.1.3.2    | | |x| | |
-  Punish unnecessary TCP query                 |6.1.3.2    | | | |x| |
-Use truncated data as if it were not           |6.1.3.2    | | | | |x|
-Private agreement to use only TCP              |6.1.3.2    | | |x| | |
-Use TCP for zone transfers                     |6.1.3.2    |x| | | | |
-TCP usage not block UDP queries                |6.1.3.2    |x| | | | |
-Support broadcast or multicast queries         |6.1.3.2    | | |x| | |
-  RD bit set in query                          |6.1.3.2    | | | | |x|
-  RD bit ignored by server is b'cast/m'cast    |6.1.3.2    |x| | | | |
-  Send only as occasional probe for addr's     |6.1.3.2    | |x| | | |
------------------------------------------------|-----------|-|-|-|-|-|--
-RESOURCE USAGE:                                |           | | | | | |
-                                               |           | | | | | |
-Transmission controls, per [DNS:2]             |6.1.3.3    |x| | | | |
-  Finite bounds per request                    |6.1.3.3    |x| | | | |
-Failure after retries => soft error            |6.1.3.3    |x| | | | |
-Cache temporary failures                       |6.1.3.3    | |x| | | |
-Cache negative responses                       |6.1.3.3    | |x| | | |
-Retries use exponential backoff                |6.1.3.3    | |x| | | |
-  Upper, lower bounds                          |6.1.3.3    | |x| | | |
-Client handle Source Quench                    |6.1.3.3    | |x| | | |
-Server ignore Source Quench                    |6.1.3.3    | | |x| | |
------------------------------------------------|-----------|-|-|-|-|-|--
-USER INTERFACE:                                |           | | | | | |
-                                               |           | | | | | |
-All programs have access to DNS interface      |6.1.4.2    |x| | | | |
-Able to request all info for given name        |6.1.4.2    |x| | | | |
-Returns complete info or error                 |6.1.4.2    |x| | | | |
-Special interfaces                             |6.1.4.2    | | |x| | |
-  Name<->Address translation                   |6.1.4.2    |x| | | | |
-                                               |           | | | | | |
-Abbreviation Facilities:                       |6.1.4.3    | | |x| | |
-
-
-
-Internet Engineering Task Force                                [Page 85]
-
-
-
-
-RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
-
-
-  Convention for complete names                |6.1.4.3    |x| | | | |
-  Conversion exactly once                      |6.1.4.3    |x| | | | |
-  Conversion in proper context                 |6.1.4.3    |x| | | | |
-  Search list:                                 |6.1.4.3    | | |x| | |
-    Administrator can disable                  |6.1.4.3    | |x| | | |
-    Prevention of excessive root queries       |6.1.4.3    |x| | | | |
-      Both methods                             |6.1.4.3    | |x| | | |
------------------------------------------------|-----------|-|-|-|-|-|--
------------------------------------------------|-----------|-|-|-|-|-|--
-
-1.   Unless there is private agreement between particular resolver and
-     particular server.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 86]
-
-
-
-
-RFC1123            SUPPORT SERVICES -- INITIALIZATION       October 1989
-
-
-   6.2  HOST INITIALIZATION
-
-      6.2.1  INTRODUCTION
-
-         This section discusses the initialization of host software
-         across a connected network, or more generally across an
-         Internet path.  This is necessary for a diskless host, and may
-         optionally be used for a host with disk drives.  For a diskless
-         host, the initialization process is called "network booting"
-         and is controlled by a bootstrap program located in a boot ROM.
-
-         To initialize a diskless host across the network, there are two
-         distinct phases:
-
-         (1)  Configure the IP layer.
-
-              Diskless machines often have no permanent storage in which
-              to store network configuration information, so that
-              sufficient configuration information must be obtained
-              dynamically to support the loading phase that follows.
-              This information must include at least the IP addresses of
-              the host and of the boot server.  To support booting
-              across a gateway, the address mask and a list of default
-              gateways are also required.
-
-         (2)  Load the host system code.
-
-              During the loading phase, an appropriate file transfer
-              protocol is used to copy the system code across the
-              network from the boot server.
-
-         A host with a disk may perform the first step, dynamic
-         configuration.  This is important for microcomputers, whose
-         floppy disks allow network configuration information to be
-         mistakenly duplicated on more than one host.  Also,
-         installation of new hosts is much simpler if they automatically
-         obtain their configuration information from a central server,
-         saving administrator time and decreasing the probability of
-         mistakes.
-
-      6.2.2  REQUIREMENTS
-
-         6.2.2.1  Dynamic Configuration
-
-            A number of protocol provisions have been made for dynamic
-            configuration.
-
-            o    ICMP Information Request/Reply messages
-
-
-
-Internet Engineering Task Force                                [Page 87]
-
-
-
-
-RFC1123            SUPPORT SERVICES -- INITIALIZATION       October 1989
-
-
-                 This obsolete message pair was designed to allow a host
-                 to find the number of the network it is on.
-                 Unfortunately, it was useful only if the host already
-                 knew the host number part of its IP address,
-                 information that hosts requiring dynamic configuration
-                 seldom had.
-
-            o    Reverse Address Resolution Protocol (RARP) [BOOT:4]
-
-                 RARP is a link-layer protocol for a broadcast medium
-                 that allows a host to find its IP address given its
-                 link layer address.  Unfortunately, RARP does not work
-                 across IP gateways and therefore requires a RARP server
-                 on every network.  In addition, RARP does not provide
-                 any other configuration information.
-
-            o    ICMP Address Mask Request/Reply messages
-
-                 These ICMP messages allow a host to learn the address
-                 mask for a particular network interface.
-
-            o    BOOTP Protocol [BOOT:2]
-
-                 This protocol allows a host to determine the IP
-                 addresses of the local host and the boot server, the
-                 name of an appropriate boot file, and optionally the
-                 address mask and list of default gateways.  To locate a
-                 BOOTP server, the host broadcasts a BOOTP request using
-                 UDP.  Ad hoc gateway extensions have been used to
-                 transmit the BOOTP broadcast through gateways, and in
-                 the future the IP Multicasting facility will provide a
-                 standard mechanism for this purpose.
-
-
-            The suggested approach to dynamic configuration is to use
-            the BOOTP protocol with the extensions defined in "BOOTP
-            Vendor Information Extensions" RFC-1084 [BOOT:3].  RFC-1084
-            defines some important general (not vendor-specific)
-            extensions.  In particular, these extensions allow the
-            address mask to be supplied in BOOTP; we RECOMMEND that the
-            address mask be supplied in this manner.
-
-            DISCUSSION:
-                 Historically, subnetting was defined long after IP, and
-                 so a separate mechanism (ICMP Address Mask messages)
-                 was designed to supply the address mask to a host.
-                 However, the IP address mask and the corresponding IP
-                 address conceptually form a pair, and for operational
-
-
-
-Internet Engineering Task Force                                [Page 88]
-
-
-
-
-RFC1123            SUPPORT SERVICES -- INITIALIZATION       October 1989
-
-
-                 simplicity they ought to be defined at the same time
-                 and by the same mechanism, whether a configuration file
-                 or a dynamic mechanism like BOOTP.
-
-                 Note that BOOTP is not sufficiently general to specify
-                 the configurations of all interfaces of a multihomed
-                 host.  A multihomed host must either use BOOTP
-                 separately for each interface, or configure one
-                 interface using BOOTP to perform the loading, and
-                 perform the complete initialization from a file later.
-
-                 Application layer configuration information is expected
-                 to be obtained from files after loading of the system
-                 code.
-
-         6.2.2.2  Loading Phase
-
-            A suggested approach for the loading phase is to use TFTP
-            [BOOT:1] between the IP addresses established by BOOTP.
-
-            TFTP to a broadcast address SHOULD NOT be used, for reasons
-            explained in Section 4.2.3.4.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 89]
-
-
-
-
-RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
-
-
-   6.3  REMOTE MANAGEMENT
-
-      6.3.1  INTRODUCTION
-
-         The Internet community has recently put considerable effort
-         into the development of network management protocols.  The
-         result has been a two-pronged approach [MGT:1, MGT:6]:  the
-         Simple Network Management Protocol (SNMP) [MGT:4] and the
-         Common Management Information Protocol over TCP (CMOT) [MGT:5].
-
-         In order to be managed using SNMP or CMOT, a host will need to
-         implement an appropriate management agent.  An Internet host
-         SHOULD include an agent for either SNMP or CMOT.
-
-         Both SNMP and CMOT operate on a Management Information Base
-         (MIB) that defines a collection of management values.  By
-         reading and setting these values, a remote application may
-         query and change the state of the managed system.
-
-         A standard MIB [MGT:3] has been defined for use by both
-         management protocols, using data types defined by the Structure
-         of Management Information (SMI) defined in [MGT:2].  Additional
-         MIB variables can be introduced under the "enterprises" and
-         "experimental" subtrees of the MIB naming space [MGT:2].
-
-         Every protocol module in the host SHOULD implement the relevant
-         MIB variables.  A host SHOULD implement the MIB variables as
-         defined in the most recent standard MIB, and MAY implement
-         other MIB variables when appropriate and useful.
-
-      6.3.2  PROTOCOL WALK-THROUGH
-
-         The MIB is intended to cover both hosts and gateways, although
-         there may be detailed differences in MIB application to the two
-         cases.  This section contains the appropriate interpretation of
-         the MIB for hosts.  It is likely that later versions of the MIB
-         will include more entries for host management.
-
-         A managed host must implement the following groups of MIB
-         object definitions: System, Interfaces, Address Translation,
-         IP, ICMP, TCP, and UDP.
-
-         The following specific interpretations apply to hosts:
-
-         o    ipInHdrErrors
-
-              Note that the error "time-to-live exceeded" can occur in a
-              host only when it is forwarding a source-routed datagram.
-
-
-
-Internet Engineering Task Force                                [Page 90]
-
-
-
-
-RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
-
-
-         o    ipOutNoRoutes
-
-              This object counts datagrams discarded because no route
-              can be found.  This may happen in a host if all the
-              default gateways in the host's configuration are down.
-
-         o    ipFragOKs, ipFragFails, ipFragCreates
-
-              A host that does not implement intentional fragmentation
-              (see "Fragmentation" section of [INTRO:1]) MUST return the
-              value zero for these three objects.
-
-         o    icmpOutRedirects
-
-              For a host, this object MUST always be zero, since hosts
-              do not send Redirects.
-
-         o    icmpOutAddrMaskReps
-
-              For a host, this object MUST always be zero, unless the
-              host is an authoritative source of address mask
-              information.
-
-         o    ipAddrTable
-
-              For a host, the "IP Address Table" object is effectively a
-              table of logical interfaces.
-
-         o    ipRoutingTable
-
-              For a host, the "IP Routing Table" object is effectively a
-              combination of the host's Routing Cache and the static
-              route table described in "Routing Outbound Datagrams"
-              section of [INTRO:1].
-
-              Within each ipRouteEntry, ipRouteMetric1...4 normally will
-              have no meaning for a host and SHOULD always be -1, while
-              ipRouteType will normally have the value "remote".
-
-              If destinations on the connected network do not appear in
-              the Route Cache (see "Routing Outbound Datagrams section
-              of [INTRO:1]), there will be no entries with ipRouteType
-              of "direct".
-
-
-         DISCUSSION:
-              The current MIB does not include Type-of-Service in an
-              ipRouteEntry, but a future revision is expected to make
-
-
-
-Internet Engineering Task Force                                [Page 91]
-
-
-
-
-RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
-
-
-              this addition.
-
-              We also expect the MIB to be expanded to allow the remote
-              management of applications (e.g., the ability to partially
-              reconfigure mail systems).  Network service applications
-              such as mail systems should therefore be written with the
-              "hooks" for remote management.
-
-      6.3.3  MANAGEMENT REQUIREMENTS SUMMARY
-
-                                               |           | | | |S| |
-                                               |           | | | |H| |F
-                                               |           | | | |O|M|o
-                                               |           | |S| |U|U|o
-                                               |           | |H| |L|S|t
-                                               |           |M|O| |D|T|n
-                                               |           |U|U|M| | |o
-                                               |           |S|L|A|N|N|t
-                                               |           |T|D|Y|O|O|t
-FEATURE                                        |SECTION    | | | |T|T|e
------------------------------------------------|-----------|-|-|-|-|-|--
-Support SNMP or CMOT agent                     |6.3.1      | |x| | | |
-Implement specified objects in standard MIB    |6.3.1      | |x| | | |
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 92]
-
-
-
-
-RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
-
-
-7.  REFERENCES
-
-   This section lists the primary references with which every
-   implementer must be thoroughly familiar.  It also lists some
-   secondary references that are suggested additional reading.
-
-   INTRODUCTORY REFERENCES:
-
-
-   [INTRO:1] "Requirements for Internet Hosts -- Communication Layers,"
-        IETF Host Requirements Working Group, R. Braden, Ed., RFC-1122,
-        October 1989.
-
-   [INTRO:2]  "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006,
-        (three volumes), SRI International, December 1985.
-
-   [INTRO:3]  "Official Internet Protocols," J. Reynolds and J. Postel,
-        RFC-1011, May 1987.
-
-        This document is republished periodically with new RFC numbers;
-        the latest version must be used.
-
-   [INTRO:4]  "Protocol Document Order Information," O. Jacobsen and J.
-        Postel, RFC-980, March 1986.
-
-   [INTRO:5]  "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010,
-        May 1987.
-
-        This document is republished periodically with new RFC numbers;
-        the latest version must be used.
-
-
-   TELNET REFERENCES:
-
-
-   [TELNET:1]  "Telnet Protocol Specification," J. Postel and J.
-        Reynolds, RFC-854, May 1983.
-
-   [TELNET:2]  "Telnet Option Specification," J. Postel and J. Reynolds,
-        RFC-855, May 1983.
-
-   [TELNET:3]  "Telnet Binary Transmission," J. Postel and J. Reynolds,
-        RFC-856, May 1983.
-
-   [TELNET:4]  "Telnet Echo Option," J. Postel and J. Reynolds, RFC-857,
-        May 1983.
-
-   [TELNET:5]  "Telnet Suppress Go Ahead Option," J. Postel and J.
-
-
-
-Internet Engineering Task Force                                [Page 93]
-
-
-
-
-RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
-
-
-        Reynolds, RFC-858, May 1983.
-
-   [TELNET:6]  "Telnet Status Option," J. Postel and J. Reynolds, RFC-
-        859, May 1983.
-
-   [TELNET:7]  "Telnet Timing Mark Option," J. Postel and J. Reynolds,
-        RFC-860, May 1983.
-
-   [TELNET:8]  "Telnet Extended Options List," J. Postel and J.
-        Reynolds, RFC-861, May 1983.
-
-   [TELNET:9]  "Telnet End-Of-Record Option," J. Postel, RFC-855,
-        December 1983.
-
-   [TELNET:10] "Telnet Terminal-Type Option," J. VanBokkelen, RFC-1091,
-        February 1989.
-
-        This document supercedes RFC-930.
-
-   [TELNET:11] "Telnet Window Size Option," D. Waitzman, RFC-1073,
-        October 1988.
-
-   [TELNET:12] "Telnet Linemode Option," D. Borman, RFC-1116, August
-        1989.
-
-   [TELNET:13] "Telnet Terminal Speed Option," C. Hedrick, RFC-1079,
-        December 1988.
-
-   [TELNET:14] "Telnet Remote Flow Control Option," C. Hedrick, RFC-
-        1080, November 1988.
-
-
-   SECONDARY TELNET REFERENCES:
-
-
-   [TELNET:15] "Telnet Protocol," MIL-STD-1782, U.S. Department of
-        Defense, May 1984.
-
-        This document is intended to describe the same protocol as RFC-
-        854.  In case of conflict, RFC-854 takes precedence, and the
-        present document takes precedence over both.
-
-   [TELNET:16] "SUPDUP Protocol," M. Crispin, RFC-734, October 1977.
-
-   [TELNET:17] "Telnet SUPDUP Option," M. Crispin, RFC-736, October
-        1977.
-
-   [TELNET:18] "Data Entry Terminal Option," J. Day, RFC-732, June 1977.
-
-
-
-Internet Engineering Task Force                                [Page 94]
-
-
-
-
-RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
-
-
-   [TELNET:19] "TELNET Data Entry Terminal option -- DODIIS
-        Implementation," A. Yasuda and T. Thompson, RFC-1043, February
-        1988.
-
-
-   FTP REFERENCES:
-
-
-   [FTP:1]  "File Transfer Protocol," J. Postel and J. Reynolds, RFC-
-        959, October 1985.
-
-   [FTP:2]  "Document File Format Standards," J. Postel, RFC-678,
-        December 1974.
-
-   [FTP:3]  "File Transfer Protocol," MIL-STD-1780, U.S. Department of
-        Defense, May 1984.
-
-        This document is based on an earlier version of the FTP
-        specification (RFC-765) and is obsolete.
-
-
-   TFTP REFERENCES:
-
-
-   [TFTP:1]  "The TFTP Protocol Revision 2," K. Sollins, RFC-783, June
-        1981.
-
-
-   MAIL REFERENCES:
-
-
-   [SMTP:1]  "Simple Mail Transfer Protocol," J. Postel, RFC-821, August
-        1982.
-
-   [SMTP:2]  "Standard For The Format of ARPA Internet Text Messages,"
-        D. Crocker, RFC-822, August 1982.
-
-        This document obsoleted an earlier specification, RFC-733.
-
-   [SMTP:3]  "Mail Routing and the Domain System," C. Partridge, RFC-
-        974, January 1986.
-
-        This RFC describes the use of MX records, a mandatory extension
-        to the mail delivery process.
-
-   [SMTP:4]  "Duplicate Messages and SMTP," C. Partridge, RFC-1047,
-        February 1988.
-
-
-
-
-Internet Engineering Task Force                                [Page 95]
-
-
-
-
-RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
-
-
-   [SMTP:5a]  "Mapping between X.400 and RFC 822," S. Kille, RFC-987,
-        June 1986.
-
-   [SMTP:5b]  "Addendum to RFC-987," S. Kille, RFC-???, September 1987.
-
-        The two preceding RFC's define a proposed standard for
-        gatewaying mail between the Internet and the X.400 environments.
-
-   [SMTP:6]  "Simple Mail Transfer Protocol,"  MIL-STD-1781, U.S.
-        Department of Defense, May 1984.
-
-        This specification is intended to describe the same protocol as
-        does RFC-821.  However, MIL-STD-1781 is incomplete; in
-        particular, it does not include MX records [SMTP:3].
-
-   [SMTP:7]  "A Content-Type Field for Internet Messages," M. Sirbu,
-        RFC-1049, March 1988.
-
-
-   DOMAIN NAME SYSTEM REFERENCES:
-
-
-   [DNS:1]  "Domain Names - Concepts and Facilities," P. Mockapetris,
-        RFC-1034, November 1987.
-
-        This document and the following one obsolete RFC-882, RFC-883,
-        and RFC-973.
-
-   [DNS:2]  "Domain Names - Implementation and Specification," RFC-1035,
-        P. Mockapetris, November 1987.
-
-
-   [DNS:3]  "Mail Routing and the Domain System," C. Partridge, RFC-974,
-        January 1986.
-
-
-   [DNS:4]  "DoD Internet Host Table Specification," K. Harrenstein,
-        RFC-952, M. Stahl, E. Feinler, October 1985.
-
-        SECONDARY DNS REFERENCES:
-
-
-   [DNS:5]  "Hostname Server," K. Harrenstein, M. Stahl, E. Feinler,
-        RFC-953, October 1985.
-
-   [DNS:6]  "Domain Administrators Guide," M. Stahl, RFC-1032, November
-        1987.
-
-
-
-
-Internet Engineering Task Force                                [Page 96]
-
-
-
-
-RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
-
-
-   [DNS:7]  "Domain Administrators Operations Guide," M. Lottor, RFC-
-        1033, November 1987.
-
-   [DNS:8]  "The Domain Name System Handbook," Vol. 4 of Internet
-        Protocol Handbook, NIC 50007, SRI Network Information Center,
-        August 1989.
-
-
-   SYSTEM INITIALIZATION REFERENCES:
-
-
-   [BOOT:1] "Bootstrap Loading Using TFTP," R. Finlayson, RFC-906, June
-        1984.
-
-   [BOOT:2] "Bootstrap Protocol (BOOTP)," W. Croft and J. Gilmore, RFC-
-        951, September 1985.
-
-   [BOOT:3] "BOOTP Vendor Information Extensions," J. Reynolds, RFC-
-        1084, December 1988.
-
-        Note: this RFC revised and obsoleted RFC-1048.
-
-   [BOOT:4] "A Reverse Address Resolution Protocol," R. Finlayson, T.
-        Mann, J. Mogul, and M. Theimer, RFC-903, June 1984.
-
-
-   MANAGEMENT REFERENCES:
-
-
-   [MGT:1]  "IAB Recommendations for the Development of Internet Network
-        Management Standards," V. Cerf, RFC-1052, April 1988.
-
-   [MGT:2]  "Structure and Identification of Management Information for
-        TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1065,
-        August 1988.
-
-   [MGT:3]  "Management Information Base for Network Management of
-        TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1066,
-        August 1988.
-
-   [MGT:4]  "A Simple Network Management Protocol," J. Case, M. Fedor,
-        M. Schoffstall, and C. Davin, RFC-1098, April 1989.
-
-   [MGT:5]  "The Common Management Information Services and Protocol
-        over TCP/IP," U. Warrier and L. Besaw, RFC-1095, April 1989.
-
-   [MGT:6]  "Report of the Second Ad Hoc Network Management Review
-        Group," V. Cerf, RFC-1109, August 1989.
-
-
-
-Internet Engineering Task Force                                [Page 97]
-
-
-
-
-RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
-
-
-Security Considerations
-
-   There are many security issues in the application and support
-   programs of host software, but a full discussion is beyond the scope
-   of this RFC.  Security-related issues are mentioned in sections
-   concerning TFTP (Sections 4.2.1, 4.2.3.4, 4.2.3.5), the SMTP VRFY and
-   EXPN commands (Section 5.2.3), the SMTP HELO command (5.2.5), and the
-   SMTP DATA command (Section 5.2.8).
-
-Author's Address
-
-   Robert Braden
-   USC/Information Sciences Institute
-   4676 Admiralty Way
-   Marina del Rey, CA 90292-6695
-
-   Phone: (213) 822 1511
-
-   EMail: Braden@ISI.EDU
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Internet Engineering Task Force                                [Page 98]
-
diff --git a/contrib/bind9/doc/rfc/rfc1183.txt b/contrib/bind9/doc/rfc/rfc1183.txt
deleted file mode 100644
index 6f08044..0000000
--- a/contrib/bind9/doc/rfc/rfc1183.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        C. Everhart
-Request for Comments: 1183                                      Transarc
-Updates: RFCs 1034, 1035                                      L. Mamakos
-                                                  University of Maryland
-                                                              R. Ullmann
-                                                          Prime Computer
-                                                  P. Mockapetris, Editor
-                                                                     ISI
-                                                            October 1990
-
-
-                         New DNS RR Definitions
-
-Status of this Memo
-
-   This memo defines five new DNS types for experimental purposes.  This
-   RFC describes an Experimental Protocol for the Internet community,
-   and requests discussion and suggestions for improvements.
-   Distribution of this memo is unlimited.
-
-Table of Contents
-
-   Introduction....................................................    1
-   1. AFS Data Base location.......................................    2
-   2. Responsible Person...........................................    3
-   2.1. Identification of the guilty party.........................    3
-   2.2. The Responsible Person RR..................................    4
-   3. X.25 and ISDN addresses, Route Binding.......................    6
-   3.1. The X25 RR.................................................    6
-   3.2. The ISDN RR................................................    7
-   3.3. The Route Through RR.......................................    8
-   REFERENCES and BIBLIOGRAPHY.....................................    9
-   Security Considerations.........................................   10
-   Authors' Addresses..............................................   11
-
-Introduction
-
-   This RFC defines the format of new Resource Records (RRs) for the
-   Domain Name System (DNS), and reserves corresponding DNS type
-   mnemonics and numerical codes.  The definitions are in three
-   independent sections: (1) location of AFS database servers, (2)
-   location of responsible persons, and (3) representation of X.25 and
-   ISDN addresses and route binding.  All are experimental.
-
-   This RFC assumes that the reader is familiar with the DNS [3,4].  The
-   data shown is for pedagogical use and does not necessarily reflect
-   the real Internet.
-
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                        [Page 1]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-1. AFS Data Base location
-
-   This section defines an extension of the DNS to locate servers both
-   for AFS (AFS is a registered trademark of Transarc Corporation) and
-   for the Open Software Foundation's (OSF) Distributed Computing
-   Environment (DCE) authenticated naming system using HP/Apollo's NCA,
-   both to be components of the OSF DCE.  The discussion assumes that
-   the reader is familiar with AFS [5] and NCA [6].
-
-   The AFS (originally the Andrew File System) system uses the DNS to
-   map from a domain name to the name of an AFS cell database server.
-   The DCE Naming service uses the DNS for a similar function: mapping
-   from the domain name of a cell to authenticated name servers for that
-   cell.  The method uses a new RR type with mnemonic AFSDB and type
-   code of 18 (decimal).
-
-   AFSDB has the following format:
-
-   <owner> <ttl> <class> AFSDB <subtype> <hostname>
-
-   Both RDATA fields are required in all AFSDB RRs.  The <subtype> field
-   is a 16 bit integer.  The <hostname> field is a domain name of a host
-   that has a server for the cell named by the owner name of the RR.
-
-   The format of the AFSDB RR is class insensitive.  AFSDB records cause
-   type A additional section processing for <hostname>.  This, in fact,
-   is the rationale for using a new type code, rather than trying to
-   build the same functionality with TXT RRs.
-
-   Note that the format of AFSDB in a master file is identical to MX.
-   For purposes of the DNS itself, the subtype is merely an integer.
-   The present subtype semantics are discussed below, but changes are
-   possible and will be announced in subsequent RFCs.
-
-   In the case of subtype 1, the host has an AFS version 3.0 Volume
-   Location Server for the named AFS cell.  In the case of subtype 2,
-   the host has an authenticated name server holding the cell-root
-   directory node for the named DCE/NCA cell.
-
-   The use of subtypes is motivated by two considerations.  First, the
-   space of DNS RR types is limited.  Second, the services provided are
-   sufficiently distinct that it would continue to be confusing for a
-   client to attempt to connect to a cell's servers using the protocol
-   for one service, if the cell offered only the other service.
-
-   As an example of the use of this RR, suppose that the Toaster
-   Corporation has deployed AFS 3.0 but not (yet) the OSF's DCE.  Their
-   cell, named toaster.com, has three "AFS 3.0 cell database server"
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                        [Page 2]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-   machines: bigbird.toaster.com, ernie.toaster.com, and
-   henson.toaster.com.  These three machines would be listed in three
-   AFSDB RRs.  These might appear in a master file as:
-
-   toaster.com.   AFSDB   1 bigbird.toaster.com.
-   toaster.com.   AFSDB   1 ernie.toaster.com.
-   toaster.com.   AFSDB   1 henson.toaster.com.
-
-   As another example use of this RR, suppose that Femto College (domain
-   name femto.edu) has deployed DCE, and that their DCE cell root
-   directory is served by processes running on green.femto.edu and
-   turquoise.femto.edu.  Furthermore, their DCE file servers also run
-   AFS 3.0-compatible volume location servers, on the hosts
-   turquoise.femto.edu and orange.femto.edu.  These machines would be
-   listed in four AFSDB RRs, which might appear in a master file as:
-
-   femto.edu.   AFSDB   2 green.femto.edu.
-   femto.edu.   AFSDB   2 turquoise.femto.edu.
-   femto.edu.   AFSDB   1 turquoise.femto.edu.
-   femto.edu.   AFSDB   1 orange.femto.edu.
-
-2. Responsible Person
-
-   The purpose of this section is to provide a standard method for
-   associating responsible person identification to any name in the DNS.
-
-   The domain name system functions as a distributed database which
-   contains many different form of information.  For a particular name
-   or host, you can discover it's Internet address, mail forwarding
-   information, hardware type and operating system among others.
-
-   A key aspect of the DNS is that the tree-structured namespace can be
-   divided into pieces, called zones, for purposes of distributing
-   control and responsibility.  The responsible person for zone database
-   purposes is named in the SOA RR for that zone.  This section
-   describes an extension which allows different responsible persons to
-   be specified for different names in a zone.
-
-2.1. Identification of the guilty party
-
-   Often it is desirable to be able to identify the responsible entity
-   for a particular host.  When that host is down or malfunctioning, it
-   is difficult to contact those parties which might resolve or repair
-   the host.  Mail sent to POSTMASTER may not reach the person in a
-   timely fashion.  If the host is one of a multitude of workstations,
-   there may be no responsible person which can be contacted on that
-   host.
-
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                        [Page 3]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-   The POSTMASTER mailbox on that host continues to be a good contact
-   point for mail problems, and the zone contact in the SOA record for
-   database problem, but the RP record allows us to associate a mailbox
-   to entities that don't receive mail or are not directly connected
-   (namespace-wise) to the problem (e.g., GATEWAY.ISI.EDU might want to
-   point at HOTLINE@BBN.COM, and GATEWAY doesn't get mail, nor does the
-   ISI zone administrator have a clue about fixing gateways).
-
-2.2. The Responsible Person RR
-
-   The method uses a new RR type with mnemonic RP and type code of 17
-   (decimal).
-
-   RP has the following format:
-
-   <owner> <ttl> <class> RP <mbox-dname> <txt-dname>
-
-   Both RDATA fields are required in all RP RRs.
-
-   The first field, <mbox-dname>, is a domain name that specifies the
-   mailbox for the responsible person.  Its format in master files uses
-   the DNS convention for mailbox encoding, identical to that used for
-   the RNAME mailbox field in the SOA RR.  The root domain name (just
-   ".") may be specified for <mbox-dname> to indicate that no mailbox is
-   available.
-
-   The second field, <txt-dname>, is a domain name for which TXT RR's
-   exist.  A subsequent query can be performed to retrieve the
-   associated TXT resource records at <txt-dname>.  This provides a
-   level of indirection so that the entity can be referred to from
-   multiple places in the DNS.  The root domain name (just ".") may be
-   specified for <txt-dname> to indicate that the TXT_DNAME is absent,
-   and no associated TXT RR exists.
-
-   The format of the RP RR is class insensitive.  RP records cause no
-   additional section processing.  (TXT additional section processing
-   for <txt-dname> is allowed as an option, but only if it is disabled
-   for the root, i.e., ".").
-
-   The Responsible Person RR can be associated with any node in the
-   Domain Name System hierarchy, not just at the leaves of the tree.
-
-   The TXT RR associated with the TXT_DNAME contain free format text
-   suitable for humans.  Refer to [4] for more details on the TXT RR.
-
-   Multiple RP records at a single name may be present in the database.
-   They should have identical TTLs.
-
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                        [Page 4]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-   EXAMPLES
-
-   Some examples of how the RP record might be used.
-
-   sayshell.umd.edu. A     128.8.1.14
-                     MX    10 sayshell.umd.edu.
-                     HINFO NeXT UNIX
-                     WKS   128.8.1.14 tcp ftp telnet smtp
-                     RP    louie.trantor.umd.edu.  LAM1.people.umd.edu.
-
-   LAM1.people.umd.edu. TXT (
-         "Louis A. Mamakos, (301) 454-2946, don't call me at home!" )
-
-   In this example, the responsible person's mailbox for the host
-   SAYSHELL.UMD.EDU is louie@trantor.umd.edu.  The TXT RR at
-   LAM1.people.umd.edu provides additional information and advice.
-
-   TERP.UMD.EDU.    A     128.8.10.90
-                    MX    10 128.8.10.90
-                    HINFO MICROVAX-II UNIX
-                    WKS   128.8.10.90 udp domain
-                    WKS   128.8.10.90 tcp ftp telnet smtp domain
-                    RP    louie.trantor.umd.edu. LAM1.people.umd.edu.
-                    RP    root.terp.umd.edu. ops.CS.UMD.EDU.
-
-   TRANTOR.UMD.EDU. A     128.8.10.14
-                    MX    10 trantor.umd.edu.
-                    HINFO MICROVAX-II UNIX
-                    WKS   128.8.10.14 udp domain
-                    WKS   128.8.10.14 tcp ftp telnet smtp domain
-                    RP    louie.trantor.umd.edu. LAM1.people.umd.edu.
-                    RP    petry.netwolf.umd.edu. petry.people.UMD.EDU.
-                    RP    root.trantor.umd.edu. ops.CS.UMD.EDU.
-                    RP    gregh.sunset.umd.edu.  .
-
-   LAM1.people.umd.edu.  TXT   "Louis A. Mamakos (301) 454-2946"
-   petry.people.umd.edu. TXT   "Michael G. Petry (301) 454-2946"
-   ops.CS.UMD.EDU.       TXT   "CS Operations Staff (301) 454-2943"
-
-   This set of resource records has two hosts, TRANTOR.UMD.EDU and
-   TERP.UMD.EDU, as well as a number of TXT RRs.  Note that TERP.UMD.EDU
-   and TRANTOR.UMD.EDU both reference the same pair of TXT resource
-   records, although the mail box names (root.terp.umd.edu and
-   root.trantor.umd.edu) differ.
-
-   Here, we obviously care much more if the machine flakes out, as we've
-   specified four persons which might want to be notified of problems or
-   other events involving TRANTOR.UMD.EDU.  In this example, the last RP
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                        [Page 5]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-   RR for TRANTOR.UMD.EDU specifies a mailbox (gregh.sunset.umd.edu),
-   but no associated TXT RR.
-
-3. X.25 and ISDN addresses, Route Binding
-
-   This section describes an experimental representation of X.25 and
-   ISDN addresses in the DNS, as well as a route binding method,
-   analogous to the MX for mail routing, for very large scale networks.
-
-   There are several possible uses, all experimental at this time.
-   First, the RRs provide simple documentation of the correct addresses
-   to use in static configurations of IP/X.25 [11] and SMTP/X.25 [12].
-
-   The RRs could also be used automatically by an internet network-layer
-   router, typically IP.  The procedure would be to map IP address to
-   domain name, then name to canonical name if needed, then following RT
-   records, and finally attempting an IP/X.25 call to the address found.
-   Alternately, configured domain names could be resolved to identify IP
-   to X.25/ISDN bindings for a static but periodically refreshed routing
-   table.
-
-   This provides a function similar to ARP for wide area non-broadcast
-   networks that will scale well to a network with hundreds of millions
-   of hosts.
-
-   Also, a standard address binding reference will facilitate other
-   experiments in the use of X.25 and ISDN, especially in serious
-   inter-operability testing.  The majority of work in such a test is
-   establishing the n-squared entries in static tables.
-
-   Finally, the RRs are intended for use in a proposal [13] by one of
-   the authors for a possible next-generation internet.
-
-3.1. The X25 RR
-
-   The X25 RR is defined with mnemonic X25 and type code 19 (decimal).
-
-   X25 has the following format:
-
-   <owner> <ttl> <class> X25 <PSDN-address>
-
-   <PSDN-address> is required in all X25 RRs.
-
-   <PSDN-address> identifies the PSDN (Public Switched Data Network)
-   address in the X.121 [10] numbering plan associated with <owner>.
-   Its format in master files is a <character-string> syntactically
-   identical to that used in TXT and HINFO.
-
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                        [Page 6]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-   The format of X25 is class insensitive.  X25 RRs cause no additional
-   section processing.
-
-   The <PSDN-address> is a string of decimal digits, beginning with the
-   4 digit DNIC (Data Network Identification Code), as specified in
-   X.121. National prefixes (such as a 0) MUST NOT be used.
-
-   For example:
-
-   Relay.Prime.COM.  X25       311061700956
-
-3.2. The ISDN RR
-
-   The ISDN RR is defined with mnemonic ISDN and type code 20 (decimal).
-
-   An ISDN (Integrated Service Digital Network) number is simply a
-   telephone number.  The intent of the members of the CCITT is to
-   upgrade all telephone and data network service to a common service.
-
-   The numbering plan (E.163/E.164) is the same as the familiar
-   international plan for POTS (an un-official acronym, meaning Plain
-   Old Telephone Service).  In E.166, CCITT says "An E.163/E.164
-   telephony subscriber may become an ISDN subscriber without a number
-   change."
-
-   ISDN has the following format:
-
-   <owner> <ttl> <class> ISDN <ISDN-address> <sa>
-
-   The <ISDN-address> field is required; <sa> is optional.
-
-   <ISDN-address> identifies the ISDN number of <owner> and DDI (Direct
-   Dial In) if any, as defined by E.164 [8] and E.163 [7], the ISDN and
-   PSTN (Public Switched Telephone Network) numbering plan.  E.163
-   defines the country codes, and E.164 the form of the addresses.  Its
-   format in master files is a <character-string> syntactically
-   identical to that used in TXT and HINFO.
-
-   <sa> specifies the subaddress (SA).  The format of <sa> in master
-   files is a <character-string> syntactically identical to that used in
-   TXT and HINFO.
-
-   The format of ISDN is class insensitive.  ISDN RRs cause no
-   additional section processing.
-
-   The <ISDN-address> is a string of characters, normally decimal
-   digits, beginning with the E.163 country code and ending with the DDI
-   if any.  Note that ISDN, in Q.931, permits any IA5 character in the
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                        [Page 7]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-   general case.
-
-   The <sa> is a string of hexadecimal digits.  For digits 0-9, the
-   concrete encoding in the Q.931 call setup information element is
-   identical to BCD.
-
-   For example:
-
-   Relay.Prime.COM.   IN   ISDN      150862028003217
-   sh.Prime.COM.      IN   ISDN      150862028003217 004
-
-   (Note: "1" is the country code for the North American Integrated
-   Numbering Area, i.e., the system of "area codes" familiar to people
-   in those countries.)
-
-   The RR data is the ASCII representation of the digits.  It is encoded
-   as one or two <character-string>s, i.e., count followed by
-   characters.
-
-   CCITT recommendation E.166 [9] defines prefix escape codes for the
-   representation of ISDN (E.163/E.164) addresses in X.121, and PSDN
-   (X.121) addresses in E.164.  It specifies that the exact codes are a
-   "national matter", i.e., different on different networks.  A host
-   connected to the ISDN may be able to use both the X25 and ISDN
-   addresses, with the local prefix added.
-
-3.3. The Route Through RR
-
-   The Route Through RR is defined with mnemonic RT and type code 21
-   (decimal).
-
-   The RT resource record provides a route-through binding for hosts
-   that do not have their own direct wide area network addresses.  It is
-   used in much the same way as the MX RR.
-
-   RT has the following format:
-
-   <owner> <ttl> <class> RT <preference> <intermediate-host>
-
-   Both RDATA fields are required in all RT RRs.
-
-   The first field, <preference>, is a 16 bit integer, representing the
-   preference of the route.  Smaller numbers indicate more preferred
-   routes.
-
-   <intermediate-host> is the domain name of a host which will serve as
-   an intermediate in reaching the host specified by <owner>.  The DNS
-   RRs associated with <intermediate-host> are expected to include at
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                        [Page 8]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-   least one A, X25, or ISDN record.
-
-   The format of the RT RR is class insensitive.  RT records cause type
-   X25, ISDN, and A additional section processing for <intermediate-
-   host>.
-
-   For example,
-
-   sh.prime.com.      IN   RT   2    Relay.Prime.COM.
-                      IN   RT   10   NET.Prime.COM.
-   *.prime.com.       IN   RT   90   Relay.Prime.COM.
-
-   When a host is looking up DNS records to attempt to route a datagram,
-   it first looks for RT records for the destination host, which point
-   to hosts with address records (A, X25, ISDN) compatible with the wide
-   area networks available to the host.  If it is itself in the set of
-   RT records, it discards any RTs with preferences higher or equal to
-   its own.  If there are no (remaining) RTs, it can then use address
-   records of the destination itself.
-
-   Wild-card RTs are used exactly as are wild-card MXs.  RT's do not
-   "chain"; that is, it is not valid to use the RT RRs found for a host
-   referred to by an RT.
-
-   The concrete encoding is identical to the MX RR.
-
-REFERENCES and BIBLIOGRAPHY
-
-   [1] Stahl, M., "Domain Administrators Guide", RFC 1032, Network
-       Information Center, SRI International, November 1987.
-
-   [2] Lottor, M., "Domain Administrators Operations Guide", RFC 1033,
-       Network Information Center, SRI International, November, 1987.
-
-   [3] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
-       1034, USC/Information Sciences Institute, November 1987.
-
-   [4] Mockapetris, P., "Domain Names - Implementation and
-       Specification", RFC 1035, USC/Information Sciences Institute,
-       November 1987.
-
-   [5] Spector A., and M. Kazar, "Uniting File Systems", UNIX Review,
-       7(3), pp. 61-69, March 1989.
-
-   [6] Zahn, et al., "Network Computing Architecture", Prentice-Hall,
-       1989.
-
-   [7] International Telegraph and Telephone Consultative Committee,
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                        [Page 9]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-       "Numbering Plan for the International Telephone Service", CCITT
-       Recommendations E.163., IXth Plenary Assembly, Melbourne, 1988,
-       Fascicle II.2 ("Blue Book").
-
-   [8] International Telegraph and Telephone Consultative Committee,
-       "Numbering Plan for the ISDN Era", CCITT Recommendations E.164.,
-       IXth Plenary Assembly, Melbourne, 1988, Fascicle II.2 ("Blue
-       Book").
-
-   [9] International Telegraph and Telephone Consultative Committee.
-       "Numbering Plan Interworking in the ISDN Era", CCITT
-       Recommendations E.166., IXth Plenary Assembly, Melbourne, 1988,
-       Fascicle II.2 ("Blue Book").
-
-  [10] International Telegraph and Telephone Consultative Committee,
-       "International Numbering Plan for the Public Data Networks",
-       CCITT Recommendations X.121., IXth Plenary Assembly, Melbourne,
-       1988, Fascicle VIII.3 ("Blue Book"); provisional, Geneva, 1978;
-       amended, Geneva, 1980, Malaga-Torremolinos, 1984 and Melborne,
-       1988.
-
-  [11] Korb, J., "Standard for the Transmission of IP datagrams Over
-       Public Data Networks", RFC 877, Purdue University, September
-       1983.
-
-  [12] Ullmann, R., "SMTP on X.25", RFC 1090, Prime Computer, February
-       1989.
-
-  [13] Ullmann, R., "TP/IX: The Next Internet", Prime Computer
-       (unpublished), July 1990.
-
-  [14] Mockapetris, P., "DNS Encoding of Network Names and Other Types",
-       RFC 1101, USC/Information Sciences Institute, April 1989.
-
-Security Considerations
-
-   Security issues are not addressed in this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                       [Page 10]
-
-RFC 1183                 New DNS RR Definitions             October 1990
-
-
-Authors' Addresses
-
-   Craig F. Everhart
-   Transarc Corporation
-   The Gulf Tower
-   707 Grant Street
-   Pittsburgh, PA  15219
-
-   Phone: +1 412 338 4467
-
-   EMail: Craig_Everhart@transarc.com
-
-
-   Louis A. Mamakos
-   Network Infrastructure Group
-   Computer Science Center
-   University of Maryland
-   College Park, MD 20742-2411
-
-   Phone: +1-301-405-7836
-
-   Email: louie@Sayshell.UMD.EDU
-
-
-   Robert Ullmann 10-30
-   Prime Computer, Inc.
-   500 Old Connecticut Path
-   Framingham, MA 01701
-
-   Phone: +1 508 620 2800 ext 1736
-
-   Email: Ariel@Relay.Prime.COM
-
-
-   Paul Mockapetris
-   USC Information Sciences Institute
-   4676 Admiralty Way
-   Marina del Rey, CA 90292
-
-   Phone: 213-822-1511
-
-   EMail: pvm@isi.edu
-
-
-
-
-
-
-
-
-
-Everhart, Mamakos, Ullmann & Mockapetris                       [Page 11]
-
\ No newline at end of file
diff --git a/contrib/bind9/doc/rfc/rfc1348.txt b/contrib/bind9/doc/rfc/rfc1348.txt
deleted file mode 100644
index d9e5dea..0000000
--- a/contrib/bind9/doc/rfc/rfc1348.txt
+++ /dev/null
@@ -1,227 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         B. Manning
-Request for Comments: 1348                               Rice University
-Updates: RFCs 1034, 1035                                       July 1992
-
-
-                              DNS NSAP RRs
-
-Status of this Memo
-
-   This memo defines an Experimental Protocol for the Internet
-   community.  Discussion and suggestions for improvement are requested.
-   Please refer to the current edition of the "IAB Official Protocol
-   Standards" for the standardization state and status of this protocol.
-   Distribution of this memo is unlimited.
-
-Table of Contents
-
-   Introduction .....................................................  1
-   Background .......................................................  1
-   NSAP RR ..........................................................  2
-   NSAP-PTR RR ......................................................  2
-   REFERENCES and BIBLIOGRAPHY ......................................  3
-   Security Considerations ..........................................  4
-   Author's Address .................................................  4
-
-Introduction
-
-   This RFC defines the format of two new Resource Records (RRs) for the
-   Domain Name System (DNS), and reserves corresponding DNS type
-   mnemonic and numerical codes.  This format may be used with the any
-   proposal that has variable length addresses, but is targeted for CLNP
-   use.
-
-   This memo assumes that the reader is familiar with the DNS [3,4].
-
-Background
-
-   This section describes an experimental representation of NSAP
-   addresses in the DNS. There are several reasons to take this approch.
-   First, it provides simple documentation of the correct addresses to
-   use in static configurations of CLNP compliant hosts and routers.
-
-   NSAP support requires that a new DNS resource record entry type
-   ("NSAP") be defined, to store longer Internet (i.e., NSAP) addresses.
-   This resource record allows mapping from DNS names to NSAP addresses,
-   and will contain entries for systems which are able to run Internet
-   applications, over TCP or UDP, over CLNP.
-
-
-
-
-Manning                                                         [Page 1]
-
-RFC 1348                      DNS NSAP RRs                     July 1992
-
-
-   The backward translation (from NSAP address to DNS name) is
-   facilitated by definition of an associated resource record. This
-   resource record is known as "NSAP-PTR", and is used in a manner
-   analogous to the existing "in-addr.arpa".
-
-   These RRs are intended for use in a proposal [6] by one of the
-   members of the NOOP WG to address the next-generation internet.
-
-The NSAP RR
-
-   The NSAP RR is defined with mnemonic NSAP and type code 22 (decimal).
-
-   An NSAP (Network Service Access Protocol) number is a unique string
-   to OSI transport service.
-
-   The numbering plan follows RFC 1237 and associated OSI definitions
-   for NSAP format.
-
-   NSAP has the following format:
-
-   <owner> <ttl> <class> NSAP <length> <NSAP-address>
-
-   All fields are required.
-
-   <length> identifies the number of octets in the <NSAP-address> as
-   defined by the various national and international authorities.
-
-   <NSAP-address> enumerates the actual octet values assigned by the
-   assigning authority.  Its format in master files is a <character-
-   string> syntactically identical to that used in TXT and HINFO.
-
-   The format of NSAP is class insensitive.  NSAP RR causes no
-   additional section processing.
-
-   For example:
-
-foo.bar.com.    IN  NSAP   21 47000580ffff000000321099991111222233334444
-host.school.de  IN  NSAP   17 39276f3100111100002222333344449876
-
-   The RR data is the ASCII representation of the digits.  It is encoded
-   as two <character-strings>, i.e., count followed by characters.
-
-The NSAP-PTR RR
-
-   The NSAP-PTR RR is defined with mnemonic NSAP-PTR and a type code 23
-   (decimal).
-
-   Its function is analogous to the PTR record used for IP addresses
-
-
-
-Manning                                                         [Page 2]
-
-RFC 1348                      DNS NSAP RRs                     July 1992
-
-
-   [4,7].
-
-   NSAP-PTR has the following format:
-
-   <NSAP-suffix> <ttl> <class> NSAP-PTR <owner>
-
-   All fields are required.
-
-   <NSAP-suffix> enumerates the actual octet values assigned by the
-   assigning authority for the LOCAL network.  Its format in master
-   files is a <character-string> syntactically identical to that used in
-   TXT and HINFO.
-
-   The format of NSAP-PTR is class insensitive.  NSAP-PTR RR causes no
-   additional section processing.
-
-   For example:
-
-   In net ff08000574.nsap-in-addr.arpa:
-
-   444433332222111199990123000000ff    NSAP-PTR   foo.bar.com.
-
-   Or in net 11110031f67293.nsap-in-addr.arpa:
-
-   67894444333322220000  NSAP-PTR        host.school.de.
-
-   The RR data is the ASCII representation of the digits.  It is encoded
-   as a <character-string>.
-
-REFERENCES and BIBLIOGRAPHY
-
-   [1] Stahl, M., "Domain Administrators Guide", RFC 1032, Network
-       Information Center, SRI International, November 1987.
-
-   [2] Lottor, M., "Domain Administrators Operations Guide", RFC 1033,
-       Network Information Center, SRI International, November, 1987.
-
-   [3] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
-       1034, USC/Information Sciences Institute, November 1987.
-
-   [4] Mockapetris, P., "Domain Names - Implementation and
-       Specification", RFC 1035, USC/Information Sciences Institute,
-       November 1987.
-
-   [5] Colella, R., Gardner, E., and R. Callon, "Guidelines for OSI
-       NSAP Allocation in the Internet", RFC 1237, NIST, Mitre, DEC,
-       July 1991.
-
-
-
-
-Manning                                                         [Page 3]
-
-RFC 1348                      DNS NSAP RRs                     July 1992
-
-
-   [6] Callon, R., "TCP and UDP with Bigger Addresses (TUBA),
-       A Simple Proposal for Internet Addressing and Routing",
-       Digital Equipment Corporation, RFC 1347, June 1992.
-
-   [7] Mockapetris, P., "DNS Encoding of Network Names and Other Types",
-       RFC 1101, USC/Information Sciences Institute, April 1989.
-
-   [8] ISO/IEC.  Information Processing Systems -- Data Communications
-       -- Network Service Definition Addendum 2: Network Layer Address-
-       ing. International Standard 8348/Addendum 2, ISO/IEC JTC 1,
-       Switzerland, 1988.
-
-   [9] Bryant, P., "NSAPs", PB660, IPTAG/92/23, SCIENCE AND ENGINEERING
-       RESEARCH COUNCIL, RUTHERFORD APPLETON LABORATORY May 1992.
-
-Security Considerations
-
-   Security issues are not addressed in this memo.
-
-Author's Address
-
-   Bill Manning
-   Rice University - ONCS
-   PO Box 1892
-   6100 South Main
-   Houston, Texas  77251-1892
-
-   Phone: +1.713.285.5415
-   EMail: bmanning@rice.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Manning                                                         [Page 4]
-
\ No newline at end of file
diff --git a/contrib/bind9/doc/rfc/rfc1535.txt b/contrib/bind9/doc/rfc/rfc1535.txt
deleted file mode 100644
index 03bddee..0000000
--- a/contrib/bind9/doc/rfc/rfc1535.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          E. Gavron
-Request for Comments: 1535                            ACES Research Inc.
-Category: Informational                                     October 1993
-
-
-              A Security Problem and Proposed Correction
-                   With Widely Deployed DNS Software
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard.  Distribution of this memo is
-   unlimited.
-
-Abstract
-
-   This document discusses a flaw in some of the currently distributed
-   name resolver clients.  The flaw exposes a security weakness related
-   to the search heuristic invoked by these same resolvers when users
-   provide a partial domain name, and which is easy to exploit (although
-   not by the masses).  This document points out the flaw, a case in
-   point, and a solution.
-
-Background
-
-   Current Domain Name Server clients are designed to ease the burden of
-   remembering IP dotted quad addresses.  As such they translate human-
-   readable names into addresses and other resource records.  Part of
-   the translation process includes understanding and dealing with
-   hostnames that are not fully qualified domain names (FQDNs).
-
-   An absolute "rooted" FQDN is of the format {name}{.} A non "rooted"
-   domain name is of the format {name}
-
-   A domain name may have many parts and typically these include the
-   host, domain, and type.  Example:  foobar.company.com or
-   fooschool.university.edu.
-
-Flaw
-
-   The problem with most widely distributed resolvers based on the BSD
-   BIND resolver is that they attempt to resolve a partial name by
-   processing a search list of partial domains to be added to portions
-   of the specified host name until a DNS record is found.  This
-   "feature" is disabled by default in the official BIND 4.9.2 release.
-
-   Example: A TELNET attempt by    User@Machine.Tech.ACES.COM
-                             to    UnivHost.University.EDU
-
-
-
-Gavron                                                          [Page 1]
-
-RFC 1535               DNS Software Enhancements            October 1993
-
-
-   The resolver client will realize that since "UnivHost.University.EDU"
-   does not end with a ".", it is not an absolute "rooted" FQDN.  It
-   will then try the following combinations until a resource record is
-   found:
-
-                UnivHost.University.EDU.Tech.ACES.COM.
-                UnivHost.University.EDU.ACES.COM.
-                UnivHost.University.EDU.COM.
-                UnivHost.University.EDU.
-
-Security Issue
-
-   After registering the EDU.COM domain, it was discovered that an
-   unliberal application of one wildcard CNAME record would cause *all*
-   connects from any .COM site to any .EDU site to terminate at one
-   target machine in the private edu.com sub-domain.
-
-   Further, discussion reveals that specific hostnames registered in
-   this private subdomain, or any similarly named subdomain may be used
-   to spoof a host.
-
-        Example:        harvard.edu.com.        CNAME   targethost
-
-   Thus all connects to Harvard.edu from all .com sites would end up at
-   targthost, a machine which could provide a Harvard.edu login banner.
-
-   This is clearly unacceptable.  Further, it could only be made worse
-   with domains like COM.EDU, MIL.GOV, GOV.COM, etc.
-
-Public vs. Local Name Space Administration
-
-   The specification of the Domain Name System and the software that
-   implements it provides an undifferentiated hierarchy which permits
-   delegation of administration for subordinate portions of the name
-   space.  Actual administration of the name space is divided between
-   "public" and "local" portions.  Public administration pertains to all
-   top-level domains, such as .COM and .EDU.  For some domains, it also
-   pertains to some number of sub-domain levels.  The multi-level nature
-   of the public administration is most evident for top-level domains
-   for countries.  For example in the Fully Qualified Domain Name,
-   dbc.mtview.ca.us., the portion "mtview.ca.us" represents three levels
-   of public administration.  Only the left-most portion is subject to
-   local administration.
-
-
-
-
-
-
-
-
-Gavron                                                          [Page 2]
-
-RFC 1535               DNS Software Enhancements            October 1993
-
-
-   The danger of the heuristic search common in current practise is that
-   it it is possible to "intercept" the search by matching against an
-   unintended value while walking up the search list.  While this is
-   potentially dangerous at any level, it is entirely unacceptable when
-   the error impacts users outside of a local administration.
-
-   When attempting to resolve a partial domain name, DNS resolvers use
-   the Domain Name of the searching host for deriving the search list.
-   Existing DNS resolvers do not distinguish the portion of that name
-   which is in the locally administered scope from the part that is
-   publically administered.
-
-Solution(s)
-
-   At a minimum, DNS resolvers must honor the BOUNDARY between local and
-   public administration, by limiting any search lists to locally-
-   administered portions of the Domain Name space.  This requires a
-   parameter which shows the scope of the name space controlled by the
-   local administrator.
-
-   This would permit progressive searches from the most qualified to
-   less qualified up through the locally controlled domain, but not
-   beyond.
-
-   For example, if the local user were trying to reach:
-
-        User@chief.admin.DESERTU.EDU from
-        starburst,astro.DESERTU.EDU,
-
-   it is reasonable to permit the user to enter just chief.admin, and
-   for the search to cover:
-
-        chief.admin.astro.DESERTU.EDU
-        chief.admin.DESERTU.EDU
-
-   but not
-
-        chief.admin.EDU
-
-   In this case, the value of "search" should be set to "DESERTU.EDU"
-   because that's the scope of the name space controlled by the local
-   DNS administrator.
-
-   This is more than a mere optimization hack.  The local administrator
-   has control over the assignment of names within the locally
-   administered domain, so the administrator can make sure that
-   abbreviations result in the right thing.  Outside of the local
-   control, users are necessarily at risk.
-
-
-
-Gavron                                                          [Page 3]
-
-RFC 1535               DNS Software Enhancements            October 1993
-
-
-   A more stringent mechanism is implemented in BIND 4.9.2, to respond
-   to this problem:
-
-   The DNS Name resolver clients narrows its IMPLICIT search list IF ANY
-   to only try the first and the last of the examples shown.
-
-   Any additional search alternatives must be configured into the
-   resolver EXPLICITLY.
-
-   DNS Name resolver software SHOULD NOT use implicit search lists in
-   attempts to resolve partial names into absolute FQDNs other than the
-   hosts's immediate parent domain.
-
-   Resolvers which continue to use implicit search lists MUST limit
-   their scope to locally administered sub-domains.
-
-   DNS Name resolver software SHOULD NOT come pre-configured with
-   explicit search lists that perpetuate this problem.
-
-   Further, in any event where a "." exists in a specified name it
-   should be assumed to be a fully qualified domain name (FQDN) and
-   SHOULD be tried as a rooted name first.
-
-   Example:  Given  user@a.b.c.d connecting to e.f.g.h  only two tries
-             should be attempted as a result of using an implicit
-             search list:
-
-                e.f.g.h.  and e.f.g.h.b.c.d.
-
-             Given user@a.b.c.d. connecting to host those same two
-             tries would appear as:
-
-                x.b.c.d.  and x.
-
-   Some organizations make regular use of multi-part, partially
-   qualified Domain Names.  For example, host foo.loc1.org.city.state.us
-   might be used to making references to bar.loc2, or mumble.loc3, all
-   of which refer to whatever.locN.org.city.state.us
-
-   The stringent implicit search rules for BIND 4.9.2 will now cause
-   these searches to fail.  To return the ability for them to succeed,
-   configuration of the client resolvers must be changed to include an
-   explicit search rule for org.city.state.us.  That is, it must contain
-   an explicit rule for any -- and each -- portion of the locally-
-   administered sub-domain that it wishes to have as part of the search
-   list.
-
-
-
-
-
-Gavron                                                          [Page 4]
-
-RFC 1535               DNS Software Enhancements            October 1993
-
-
-References
-
-   [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
-       RFC 1034, USC/Information Sciences Institute, November 1987.
-
-   [2] Mockapetris, P., "Domain Names Implementation and Specification",
-       STD 13, RFC 1035, USC/Information Sciences Institute, November
-       1987.
-
-   [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
-       974, CSNET CIC BBN, January 1986.
-
-   [4] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller,
-       "Common DNS Implementation Errors and Suggested Fixes", RFC 1536,
-       USC/Information Sciences Institute, USC, October 1993.
-
-   [5] Beertema, P., "Common DNS Data File Configuration Errors", RFC
-       1537, CWI, October 1993.
-
-Security Considerations
-
-   This memo indicates vulnerabilities with all too-forgiving DNS
-   clients.  It points out a correction that would eliminate the future
-   potential of the problem.
-
-Author's Address
-
-   Ehud Gavron
-   ACES Research Inc.
-   PO Box 14546
-   Tucson, AZ 85711
-
-   Phone: (602) 743-9841
-   EMail: gavron@aces.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gavron                                                          [Page 5]
-
diff --git a/contrib/bind9/doc/rfc/rfc1536.txt b/contrib/bind9/doc/rfc/rfc1536.txt
deleted file mode 100644
index 5ff2b25..0000000
--- a/contrib/bind9/doc/rfc/rfc1536.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           A. Kumar
-Request for Comments: 1536                                     J. Postel
-Category: Informational                                        C. Neuman
-                                                                     ISI
-                                                               P. Danzig
-                                                               S. Miller
-                                                                     USC
-                                                            October 1993
-
-
-          Common DNS Implementation Errors and Suggested Fixes
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard.  Distribution of this memo is
-   unlimited.
-
-Abstract
-
-   This memo describes common errors seen in DNS implementations and
-   suggests some fixes. Where applicable, violations of recommendations
-   from STD 13, RFC 1034 and STD 13, RFC 1035 are mentioned. The memo
-   also describes, where relevant, the algorithms followed in BIND
-   (versions 4.8.3 and 4.9 which the authors referred to) to serve as an
-   example.
-
-Introduction
-
-   The last few years have seen, virtually, an explosion of DNS traffic
-   on the NSFnet backbone. Various DNS implementations and various
-   versions of these implementations interact with each other, producing
-   huge amounts of unnecessary traffic. Attempts are being made by
-   researchers all over the internet, to document the nature of these
-   interactions, the symptomatic traffic patterns and to devise remedies
-   for the sick pieces of software.
-
-   This draft is an attempt to document fixes for known DNS problems so
-   people know what problems to watch out for and how to repair broken
-   software.
-
-1. Fast Retransmissions
-
-   DNS implements the classic request-response scheme of client-server
-   interaction. UDP is, therefore, the chosen protocol for communication
-   though TCP is used for zone transfers. The onus of requerying in case
-   no response is seen in a "reasonable" period of time, lies with the
-   client. Although RFC 1034 and 1035 do not recommend any
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                          [Page 1]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-   retransmission policy, RFC 1035 does recommend that the resolvers
-   should cycle through a list of servers. Both name servers and stub
-   resolvers should, therefore, implement some kind of a retransmission
-   policy based on round trip time estimates of the name servers. The
-   client should back-off exponentially, probably to a maximum timeout
-   value.
-
-   However, clients might not implement either of the two. They might
-   not wait a sufficient amount of time before retransmitting or they
-   might not back-off their inter-query times sufficiently.
-
-   Thus, what the server would see will be a series of queries from the
-   same querying entity, spaced very close together. Of course, a
-   correctly implemented server discards all duplicate queries but the
-   queries contribute to wide-area traffic, nevertheless.
-
-   We classify a retransmission of a query as a pure Fast retry timeout
-   problem when a series of query packets meet the following conditions.
-
-      a. Query packets are seen within a time less than a "reasonable
-         waiting period" of each other.
-
-      b. No response to the original query was seen i.e., we see two or
-         more queries, back to back.
-
-      c. The query packets share the same query identifier.
-
-      d. The server eventually responds to the query.
-
-A GOOD IMPLEMENTATION:
-
-   BIND (we looked at versions 4.8.3 and 4.9) implements a good
-   retransmission algorithm which solves or limits all of these
-   problems.  The Berkeley stub-resolver queries servers at an interval
-   that starts at the greater of 4 seconds and 5 seconds divided by the
-   number of servers the resolver queries. The resolver cycles through
-   servers and at the end of a cycle, backs off the time out
-   exponentially.
-
-   The Berkeley full-service resolver (built in with the program
-   "named") starts with a time-out equal to the greater of 4 seconds and
-   two times the round-trip time estimate of the server.  The time-out
-   is backed off with each cycle, exponentially, to a ceiling value of
-   45 seconds.
-
-
-
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                          [Page 2]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-FIXES:
-
-      a. Estimate round-trip times or set a reasonably high initial
-         time-out.
-
-      b. Back-off timeout periods exponentially.
-
-      c. Yet another fundamental though difficult fix is to send the
-         client an acknowledgement of a query, with a round-trip time
-         estimate.
-
-   Since UDP is used, no response is expected by the client until the
-   query is complete.  Thus, it is less likely to have information about
-   previous packets on which to estimate its back-off time.  Unless, you
-   maintain state across queries, so subsequent queries to the same
-   server use information from previous queries.  Unfortunately, such
-   estimates are likely to be inaccurate for chained requests since the
-   variance is likely to be high.
-
-   The fix chosen in the ARDP library used by Prospero is that the
-   server will send an initial acknowledgement to the client in those
-   cases where the server expects the query to take a long time (as
-   might be the case for chained queries).  This initial acknowledgement
-   can include an expected time to wait before retrying.
-
-   This fix is more difficult since it requires that the client software
-   also be trained to expect the acknowledgement packet. This, in an
-   internet of millions of hosts is at best a hard problem.
-
-2. Recursion Bugs
-
-   When a server receives a client request, it first looks up its zone
-   data and the cache to check if the query can be answered. If the
-   answer is unavailable in either place, the server seeks names of
-   servers that are more likely to have the information, in its cache or
-   zone data. It then does one of two things. If the client desires the
-   server to recurse and the server architecture allows recursion, the
-   server chains this request to these known servers closest to the
-   queried name. If the client doesn't seek recursion or if the server
-   cannot handle recursion, it returns the list of name servers to the
-   client assuming the client knows what to do with these records.
-
-   The client queries this new list of name servers to get either the
-   answer, or names of another set of name servers to query. This
-   process repeats until the client is satisfied. Servers might also go
-   through this chaining process if the server returns a CNAME record
-   for the queried name. Some servers reprocess this name to try and get
-   the desired record type.
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                          [Page 3]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-   However, in certain cases, this chain of events may not be good. For
-   example, a broken or malicious name server might list itself as one
-   of the name servers to query again. The unsuspecting client resends
-   the same query to the same server.
-
-   In another situation, more difficult to detect, a set of servers
-   might form a loop wherein A refers to B and B refers to A. This loop
-   might involve more than two servers.
-
-   Yet another error is where the client does not know how to process
-   the list of name servers returned, and requeries the same server
-   since that is one (of the few) servers it knows.
-
-   We, therefore, classify recursion bugs into three distinct
-   categories:
-
-      a. Ignored referral: Client did not know how to handle NS records
-         in the AUTHORITY section.
-
-      b. Too many referrals: Client called on a server too many times,
-         beyond a "reasonable" number, with same query. This is
-         different from a Fast retransmission problem and a Server
-         Failure detection problem in that a response is seen for every
-         query.  Also, the identifiers are always different. It implies
-         client is in a loop and should have detected that and broken
-         it.  (RFC 1035 mentions that client should not recurse beyond
-         a certain depth.)
-
-      c. Malicious Server: a server refers to itself in the authority
-         section. If a server does not have an answer now, it is very
-         unlikely it will be any better the next time you query it,
-         specially when it claims to be authoritative over a domain.
-
-      RFC 1034 warns against such situations, on page 35.
-
-      "Bound the amount of work (packets sent, parallel processes
-       started) so that a request can't get into an infinite loop or
-       start off a chain reaction of requests or queries with other
-       implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED
-       SOME DATA."
-
-A GOOD IMPLEMENTATION:
-
-   BIND fixes at least one of these problems. It places an upper limit
-   on the number of recursive queries it will make, to answer a
-   question.  It chases a maximum of 20 referral links and 8 canonical
-   name translations.
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                          [Page 4]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-FIXES:
-
-      a. Set an upper limit on the number of referral links and CNAME
-         links you are willing to chase.
-
-         Note that this is not guaranteed to break only recursion loops.
-         It could, in a rare case, prune off a very long search path,
-         prematurely.  We know, however, with high probability, that if
-         the number of links cross a certain metric (two times the depth
-         of the DNS tree), it is a recursion problem.
-
-      b. Watch out for self-referring servers. Avoid them whenever
-         possible.
-
-      c. Make sure you never pass off an authority NS record with your
-         own name on it!
-
-      d. Fix clients to accept iterative answers from servers not built
-         to provide recursion. Such clients should either be happy with
-         the non-authoritative answer or be willing to chase the
-         referral links themselves.
-
-3. Zero Answer Bugs:
-
-   Name servers sometimes return an authoritative NOERROR with no
-   ANSWER, AUTHORITY or ADDITIONAL records. This happens when the
-   queried name is valid but it does not have a record of the desired
-   type. Of course, the server has authority over the domain.
-
-   However, once again, some implementations of resolvers do not
-   interpret this kind of a response reasonably. They always expect an
-   answer record when they see an authoritative NOERROR. These entities
-   continue to resend their queries, possibly endlessly.
-
-A GOOD IMPLEMENTATION
-
-   BIND resolver code does not query a server more than 3 times. If it
-   is unable to get an answer from 4 servers, querying them three times
-   each, it returns error.
-
-   Of course, it treats a zero-answer response the way it should be
-   treated; with respect!
-
-FIXES:
-
-      a. Set an upper limit on the number of retransmissions for a given
-         query, at the very least.
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                          [Page 5]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-      b. Fix resolvers to interpret such a response as an authoritative
-         statement of non-existence of the record type for the given
-         name.
-
-4. Inability to detect server failure:
-
-   Servers in the internet are not very reliable (they go down every
-   once in a while) and resolvers are expected to adapt to the changed
-   scenario by not querying the server for a while. Thus, when a server
-   does not respond to a query, resolvers should try another server.
-   Also, non-stub resolvers should update their round trip time estimate
-   for the server to a large value so that server is not tried again
-   before other, faster servers.
-
-   Stub resolvers, however, cycle through a fixed set of servers and if,
-   unfortunately, a server is down while others do not respond for other
-   reasons (high load, recursive resolution of query is taking more time
-   than the resolver's time-out, ....), the resolver queries the dead
-   server again! In fact, some resolvers might not set an upper limit on
-   the number of query retransmissions they will send and continue to
-   query dead servers indefinitely.
-
-   Name servers running system or chained queries might also suffer from
-   the same problem. They store names of servers they should query for a
-   given domain. They cycle through these names and in case none of them
-   answers, hit each one more than one. It is, once again, important
-   that there be an upper limit on the number of retransmissions, to
-   prevent network overload.
-
-   This behavior is clearly in violation of the dictum in RFC 1035 (page
-   46)
-
-      "If a resolver gets a server error or other bizarre response
-       from a name server, it should remove it from SLIST, and may
-       wish to schedule an immediate transmission to the next
-       candidate server address."
-
-   Removal from SLIST implies that the server is not queried again for
-   some time.
-
-   Correctly implemented full-service resolvers should, as pointed out
-   before, update round trip time values for servers that do not respond
-   and query them only after other, good servers. Full-service resolvers
-   might, however, not follow any of these common sense directives. They
-   query dead servers, and they query them endlessly.
-
-
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                          [Page 6]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-A GOOD IMPLEMENTATION:
-
-   BIND places an upper limit on the number of times it queries a
-   server.  Both the stub-resolver and the full-service resolver code do
-   this.  Also, since the full-service resolver estimates round-trip
-   times and sorts name server addresses by these estimates, it does not
-   query a dead server again, until and unless all the other servers in
-   the list are dead too!  Further, BIND implements exponential back-off
-   too.
-
-FIXES:
-
-      a. Set an upper limit on number of retransmissions.
-
-      b. Measure round-trip time from servers (some estimate is better
-         than none). Treat no response as a "very large" round-trip
-         time.
-
-      c. Maintain a weighted rtt estimate and decay the "large" value
-         slowly, with time, so that the server is eventually tested
-         again, but not after an indefinitely long period.
-
-      d. Follow an exponential back-off scheme so that even if you do
-         not restrict the number of queries, you do not overload the
-         net excessively.
-
-5. Cache Leaks:
-
-   Every resource record returned by a server is cached for TTL seconds,
-   where the TTL value is returned with the RR. Full-service (or stub)
-   resolvers cache the RR and answer any queries based on this cached
-   information, in the future, until the TTL expires. After that, one
-   more query to the wide-area network gets the RR in cache again.
-
-   Full-service resolvers might not implement this caching mechanism
-   well. They might impose a limit on the cache size or might not
-   interpret the TTL value correctly. In either case, queries repeated
-   within a TTL period of a RR constitute a cache leak.
-
-A GOOD/BAD IMPLEMENTATION:
-
-   BIND has no restriction on the cache size and the size is governed by
-   the limits on the virtual address space of the machine it is running
-   on. BIND caches RRs for the duration of the TTL returned with each
-   record.
-
-   It does, however, not follow the RFCs with respect to interpretation
-   of a 0 TTL value. If a record has a TTL value of 0 seconds, BIND uses
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                          [Page 7]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-   the minimum TTL value, for that zone, from the SOA record and caches
-   it for that duration. This, though it saves some traffic on the
-   wide-area network, is not correct behavior.
-
-FIXES:
-
-      a. Look over your caching mechanism to ensure TTLs are interpreted
-         correctly.
-
-      b. Do not restrict cache sizes (come on, memory is cheap!).
-         Expired entries are reclaimed periodically, anyway. Of course,
-         the cache size is bound to have some physical limit. But, when
-         possible, this limit should be large (run your name server on
-         a machine with a large amount of physical memory).
-
-      c. Possibly, a mechanism is needed to flush the cache, when it is
-         known or even suspected that the information has changed.
-
-6. Name Error Bugs:
-
-   This bug is very similar to the Zero Answer bug. A server returns an
-   authoritative NXDOMAIN when the queried name is known to be bad, by
-   the server authoritative for the domain, in the absence of negative
-   caching. This authoritative NXDOMAIN response is usually accompanied
-   by the SOA record for the domain, in the authority section.
-
-   Resolvers should recognize that the name they queried for was a bad
-   name and should stop querying further.
-
-   Some resolvers might, however, not interpret this correctly and
-   continue to query servers, expecting an answer record.
-
-   Some applications, in fact, prompt NXDOMAIN answers! When given a
-   perfectly good name to resolve, they append the local domain to it
-   e.g., an application in the domain "foo.bar.com", when trying to
-   resolve the name "usc.edu" first tries "usc.edu.foo.bar.com", then
-   "usc.edu.bar.com" and finally the good name "usc.edu". This causes at
-   least two queries that return NXDOMAIN, for every good query. The
-   problem is aggravated since the negative answers from the previous
-   queries are not cached.  When the same name is sought again, the
-   process repeats.
-
-   Some DNS resolver implementations suffer from this problem, too. They
-   append successive sub-parts of the local domain using an implicit
-   searchlist mechanism, when certain conditions are satisfied and try
-   the original name, only when this first set of iterations fails. This
-   behavior recently caused pandemonium in the Internet when the domain
-   "edu.com" was registered and a wildcard "CNAME" record placed at the
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                          [Page 8]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-   top level. All machines from "com" domains trying to connect to hosts
-   in the "edu" domain ended up with connections to the local machine in
-   the "edu.com" domain!
-
-GOOD/BAD IMPLEMENTATIONS:
-
-   Some local versions of BIND already implement negative caching. They
-   typically cache negative answers with a very small TTL, sufficient to
-   answer a burst of queries spaced close together, as is typically
-   seen.
-
-   The next official public release of BIND (4.9.2) will have negative
-   caching as an ifdef'd feature.
-
-   The BIND resolver appends local domain to the given name, when one of
-   two conditions is met:
-
-      i.  The name has no periods and the flag RES_DEFNAME is set.
-      ii. There is no trailing period and the flag RES_DNSRCH is set.
-
-   The flags RES_DEFNAME and RES_DNSRCH are default resolver options, in
-   BIND, but can be changed at compile time.
-
-   Only if the name, so generated, returns an NXDOMAIN is the original
-   name tried as a Fully Qualified Domain Name. And only if it contains
-   at least one period.
-
-FIXES:
-
-      a. Fix the resolver code.
-
-      b. Negative Caching. Negative caching servers will restrict the
-         traffic seen on the wide-area network, even if not curb it
-         altogether.
-
-      c. Applications and resolvers should not append the local domain to
-         names they seek to resolve, as far as possible. Names
-         interspersed with periods should be treated as Fully Qualified
-         Domain Names.
-
-         In other words, Use searchlists only when explicitly specified.
-         No implicit searchlists should be used. A name that contains
-         any dots should first be tried as a FQDN and if that fails, with
-         the local domain name (or searchlist if specified) appended. A
-         name containing no dots can be appended with the searchlist right
-         away, but once again, no implicit searchlists should be used.
-
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                          [Page 9]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-   Associated with the name error bug is another problem where a server
-   might return an authoritative NXDOMAIN, although the name is valid. A
-   secondary server, on start-up, reads the zone information from the
-   primary, through a zone transfer. While it is in the process of
-   loading the zones, it does not have information about them, although
-   it is authoritative for them.  Thus, any query for a name in that
-   domain is answered with an NXDOMAIN response code. This problem might
-   not be disastrous were it not for negative caching servers that cache
-   this answer and so propagate incorrect information over the internet.
-
-BAD IMPLEMENTATION:
-
-   BIND apparently suffers from this problem.
-
-   Also, a new name added to the primary database will take a while to
-   propagate to the secondaries. Until that time, they will return
-   NXDOMAIN answers for a good name. Negative caching servers store this
-   answer, too and aggravate this problem further. This is probably a
-   more general DNS problem but is apparently more harmful in this
-   situation.
-
-FIX:
-
-      a. Servers should start answering only after loading all the zone
-         data. A failed server is better than a server handing out
-         incorrect information.
-
-      b. Negative cache records for a very small time, sufficient only
-         to ward off a burst of requests for the same bad name. This
-         could be related to the round-trip time of the server from
-         which the negative answer was received. Alternatively, a
-         statistical measure of the amount of time for which queries
-         for such names are received could be used. Minimum TTL value
-         from the SOA record is not advisable since they tend to be
-         pretty large.
-
-      c. A "PUSH" (or, at least, a "NOTIFY") mechanism should be allowed
-         and implemented, to allow the primary server to inform
-         secondaries that the database has been modified since it last
-         transferred zone data.  To alleviate the problem of "too many
-         zone transfers" that this might cause, Incremental Zone
-         Transfers should also be part of DNS.  Also, the primary should
-         not NOTIFY/PUSH with every update but bunch a good number
-         together.
-
-
-
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                         [Page 10]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-7. Format Errors:
-
-   Some resolvers issue query packets that do not necessarily conform to
-   standards as laid out in the relevant RFCs. This unnecessarily
-   increases net traffic and wastes server time.
-
-FIXES:
-
-      a. Fix resolvers.
-
-      b. Each resolver verify format of packets before sending them out,
-         using a mechanism outside of the resolver. This is, obviously,
-         needed only if step 1 cannot be followed.
-
-References
-
-   [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
-       RFC 1034, USC/Information Sciences Institute, November 1987.
-
-   [2] Mockapetris, P., "Domain Names Implementation and Specification",
-       STD 13, RFC 1035, USC/Information Sciences Institute, November
-       1987.
-
-   [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
-       974, CSNET CIC BBN, January 1986.
-
-   [4] Gavron, E., "A Security Problem and Proposed Correction With
-       Widely Deployed DNS Software", RFC 1535, ACES Research Inc.,
-       October 1993.
-
-   [5] Beertema, P., "Common DNS Data File Configuration Errors", RFC
-       1537, CWI, October 1993.
-
-Security Considerations
-
-   Security issues are not discussed in this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                         [Page 11]
-
-RFC 1536            Common DNS Implementation Errors        October 1993
-
-
-Authors' Addresses
-
-   Anant Kumar
-   USC Information Sciences Institute
-   4676 Admiralty Way
-   Marina Del Rey CA 90292-6695
-
-   Phone:(310) 822-1511
-   FAX:  (310) 823-6741
-   EMail: anant@isi.edu
-
-
-   Jon Postel
-   USC Information Sciences Institute
-   4676 Admiralty Way
-   Marina Del Rey CA 90292-6695
-
-   Phone:(310) 822-1511
-   FAX:  (310) 823-6714
-   EMail: postel@isi.edu
-
-
-   Cliff Neuman
-   USC Information Sciences Institute
-   4676 Admiralty Way
-   Marina Del Rey CA 90292-6695
-
-   Phone:(310) 822-1511
-   FAX:  (310) 823-6714
-   EMail: bcn@isi.edu
-
-
-   Peter Danzig
-   Computer Science Department
-   University of Southern California
-   University Park
-
-   EMail: danzig@caldera.usc.edu
-
-
-   Steve Miller
-   Computer Science Department
-   University of Southern California
-   University Park
-   Los Angeles CA 90089
-
-   EMail: smiller@caldera.usc.edu
-
-
-
-
-Kumar, Postel, Neuman, Danzig & Miller                         [Page 12]
-
diff --git a/contrib/bind9/doc/rfc/rfc1537.txt b/contrib/bind9/doc/rfc/rfc1537.txt
deleted file mode 100644
index 81b9768..0000000
--- a/contrib/bind9/doc/rfc/rfc1537.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        P. Beertema
-Request for Comments: 1537                                           CWI
-Category: Informational                                     October 1993
-
-
-               Common DNS Data File Configuration Errors
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard.  Distribution of this memo is
-   unlimited.
-
-Abstract
-
-   This memo describes errors often found in DNS data files. It points
-   out common mistakes system administrators tend to make and why they
-   often go unnoticed for long periods of time.
-
-Introduction
-
-   Due to the lack of extensive documentation and automated tools, DNS
-   zone files have mostly been configured by system administrators, by
-   hand. Some of the rules for writing the data files are rather subtle
-   and a few common mistakes are seen in domains worldwide.
-
-   This document is an attempt to list "surprises" that administrators
-   might find hidden in their zone files. It describes the symptoms of
-   the malady and prescribes medicine to cure that. It also gives some
-   general recommendations and advice on specific nameserver and zone
-   file issues and on the (proper) use of the Domain Name System.
-
-1. SOA records
-
-   A problem I've found in quite some nameservers is that the various
-   timers have been set (far) too low. Especially for top level domain
-   nameservers this causes unnecessary traffic over international and
-   intercontinental links.
-
-   Unfortunately the examples given in the BIND manual, in RFC's and in
-   some expert documents give those very short timer values, and that's
-   most likely what people have modeled their SOA records after.
-
-   First of all a short explanation of the timers used in the SOA
-   record:
-
-
-
-
-
-
-Beertema                                                        [Page 1]
-
-RFC 1537       Common DNS Data File Configuration Errors    October 1993
-
-
-        - Refresh: The SOA record of the primary server is checked
-                   every "refresh" time by the secondary servers;
-                   if it has changed, a zone transfer is done.
-
-        - Retry: If a secondary server cannot reach the primary
-                 server, it tries it again every "retry" time.
-
-        - Expire: If for "expire" time the primary server cannot
-                  be reached, all information about the zone is
-                  invalidated on the secondary servers (i.e., they
-                  are no longer authoritative for that zone).
-
-        - Minimum TTL: The default TTL value for all records in the
-                       zone file; a different TTL value may be given
-                       explicitly in a record when necessary.
-                       (This timer is named "Minimum", and that's
-                       what it's function should be according to
-                       STD 13, RFC 1035, but most (all?)
-                       implementations take it as the default value
-                       exported with records without an explicit TTL
-                       value).
-
-   For top level domain servers I would recommend the following values:
-
-          86400 ; Refresh     24 hours
-           7200 ; Retry        2 hours
-        2592000 ; Expire      30 days
-         345600 ; Minimum TTL  4 days
-
-   For other servers I would suggest:
-
-          28800 ; Refresh     8 hours
-           7200 ; Retry       2 hours
-         604800 ; Expire      7 days
-          86400 ; Minimum TTL 1 day
-
-   but here the frequency of changes, the required speed of propagation,
-   the reachability of the primary server etc. play a role in optimizing
-   the timer values.
-
-2. Glue records
-
-   Quite often, people put unnecessary glue (A) records in their zone
-   files. Even worse is that I've even seen *wrong* glue records for an
-   external host in a primary zone file! Glue records need only be in a
-   zone file if the server host is within the zone and there is no A
-   record for that host elsewhere in the zone file.
-
-
-
-
-Beertema                                                        [Page 2]
-
-RFC 1537       Common DNS Data File Configuration Errors    October 1993
-
-
-   Old BIND versions ("native" 4.8.3 and older versions) showed the
-   problem that wrong glue records could enter secondary servers in a
-   zone transfer.
-
-3. "Secondary server surprise"
-
-   I've seen it happen on various occasions that hosts got bombarded by
-   nameserver requests without knowing why. On investigation it turned
-   out then that such a host was supposed to (i.e., the information was
-   in the root servers) run secondary for some domain (or reverse (in-
-   addr.arpa)) domain, without that host's nameserver manager having
-   been asked or even been told so!
-
-   Newer BIND versions (4.9 and later) solved this problem.  At the same
-   time though the fix has the disadvantage that it's far less easy to
-   spot this problem.
-
-   Practice has shown that most domain registrars accept registrations
-   of nameservers without checking if primary (!) and secondary servers
-   have been set up, informed, or even asked.  It should also be noted
-   that a combination of long-lasting unreachability of primary
-   nameservers, (therefore) expiration of zone information, plus static
-   IP routing, can lead to massive network traffic that can fill up
-   lines completely.
-
-4. "MX records surprise"
-
-   In a sense similar to point 3. Sometimes nameserver managers enter MX
-   records in their zone files that point to external hosts, without
-   first asking or even informing the systems managers of those external
-   hosts.  This has to be fought out between the nameserver manager and
-   the systems managers involved. Only as a last resort, if really
-   nothing helps to get the offending records removed, can the systems
-   manager turn to the naming authority of the domain above the
-   offending domain to get the problem sorted out.
-
-5. "Name extension surprise"
-
-   Sometimes one encounters weird names, which appear to be an external
-   name extended with a local domain. This is caused by forgetting to
-   terminate a name with a dot: names in zone files that don't end with
-   a dot are always expanded with the name of the current zone (the
-   domain that the zone file stands for or the last $ORIGIN).
-
-   Example: zone file for foo.xx:
-
-   pqr          MX 100  relay.yy.
-   xyz          MX 100  relay.yy           (no trailing dot!)
-
-
-
-Beertema                                                        [Page 3]
-
-RFC 1537       Common DNS Data File Configuration Errors    October 1993
-
-
-   When fully written out this stands for:
-
-      pqr.foo.xx.  MX 100  relay.yy.
-      xyz.foo.xx.  MX 100  relay.yy.foo.xx.   (name extension!)
-
-6. Missing secondary servers
-
-   It is required that there be a least 2 nameservers for a domain. For
-   obvious reasons the nameservers for top level domains need to be very
-   well reachable from all over the Internet. This implies that there
-   must be more than just 2 of them; besides, most of the (secondary)
-   servers should be placed at "strategic" locations, e.g., close to a
-   point where international and/or intercontinental lines come
-   together.  To keep things manageable, there shouldn't be too many
-   servers for a domain either.
-
-   Important aspects in selecting the location of primary and secondary
-   servers are reliability (network, host) and expedient contacts: in
-   case of problems, changes/fixes must be carried out quickly.  It
-   should be considered logical that primary servers for European top
-   level domains should run on a host in Europe, preferably (if
-   possible) in the country itself. For each top level domain there
-   should be 2 secondary servers in Europe and 2 in the USA, but there
-   may of course be more on either side.  An excessive number of
-   nameservers is not a good idea though; a recommended maximum is 7
-   nameservers.  In Europe, EUnet has offered to run secondary server
-   for each European top level domain.
-
-7. Wildcard MX records
-
-   Wildcard MX records should be avoided where possible. They often
-   cause confusion and errors: especially beginning nameserver managers
-   tend to overlook the fact that a host/domain listed with ANY type of
-   record in a zone file is NOT covered by an overall wildcard MX record
-   in that zone; this goes not only for simple domain/host names, but
-   also for names that cover one or more domains. Take the following
-   example in zone foo.bar:
-
-         *            MX 100  mailhost
-         pqr          MX 100  mailhost
-         abc.def      MX 100  mailhost
-
-   This makes pqr.foo.bar, def.foo.bar and abd.def.foo.bar valid
-   domains, but the wildcard MX record covers NONE of them, nor anything
-   below them.  To cover everything by MX records, the required entries
-   are:
-
-
-
-
-
-Beertema                                                        [Page 4]
-
-RFC 1537       Common DNS Data File Configuration Errors    October 1993
-
-
-         *            MX 100  mailhost
-         pqr          MX 100  mailhost
-         *.pqr        MX 100  mailhost
-         abc.def      MX 100  mailhost
-         *.def        MX 100  mailhost
-         *.abc.def    MX 100  mailhost
-
-   An overall wildcard MX record is almost never useful.
-
-   In particular the zone file of a top level domain should NEVER
-   contain only an overall wildcard MX record (*.XX). The effect of such
-   a wildcard MX record can be that mail is unnecessarily sent across
-   possibly expensive links, only to fail at the destination or gateway
-   that the record points to. Top level domain zone files should
-   explicitly list at least all the officially registered primary
-   subdomains.
-
-   Whereas overall wildcard MX records should be avoided, wildcard MX
-   records are acceptable as an explicit part of subdomain entries,
-   provided they are allowed under a given subdomain (to be determined
-   by the naming authority for that domain).
-
-   Example:
-
-         foo.xx.      MX 100  gateway.xx.
-                      MX 200  fallback.yy.
-         *.foo.xx.    MX 100  gateway.xx.
-                      MX 200  fallback.yy.
-8. Hostnames
-
-   People appear to sometimes look only at STD 11, RFC 822 to determine
-   whether a particular hostname is correct or not. Hostnames should
-   strictly conform to the syntax given in STD 13, RFC 1034 (page 11),
-   with *addresses* in addition conforming to RFC 822. As an example
-   take "c&w.blues" which is perfectly legal according to RFC 822, but
-   which can have quite surprising effects on particular systems, e.g.,
-   "telnet c&w.blues" on a Unix system.
-
-9. HINFO records
-
-   There appears to be a common misunderstanding that one of the data
-   fields (usually the second field) in HINFO records is optional. A
-   recent scan of all reachable nameservers in only one country revealed
-   some 300 incomplete HINFO records. Specifying two data fields in a
-   HINFO record is mandatory (RFC 1033), but note that this does *not*
-   mean that HINFO records themselves are mandatory.
-
-
-
-
-
-Beertema                                                        [Page 5]
-
-RFC 1537       Common DNS Data File Configuration Errors    October 1993
-
-
-10. Safety measures and specialties
-
-   Nameservers and resolvers aren't flawless. Bogus queries should be
-   kept from being forwarded to the root servers, since they'll only
-   lead to unnecessary intercontinental traffic. Known bogus queries
-   that can easily be dealt with locally are queries for 0 and broadcast
-   addresses.  To catch such queries, every nameserver should run
-   primary for the 0.in-addr.arpa and 255.in-addr.arpa zones; the zone
-   files need only contain a SOA and an NS record.
-
-   Also each nameserver should run primary for 0.0.127.in-addr.arpa;
-   that zone file should contain a SOA and NS record and an entry:
-
-         1    PTR     localhost.
-
-   There has been extensive discussion about whether or not to append
-   the local domain to it. The conclusion was that "localhost." would be
-   the best solution; reasons given were:
-
-   - "localhost" itself is used and expected to work on some systems.
-
-   - translating 127.0.0.1 into "localhost.my_domain" can cause some
-     software to connect to itself using the loopback interface when
-     it didn't want to.
-
-   Note that all domains that contain hosts should have a "localhost" A
-   record in them.
-
-   People maintaining zone files with the Serial number given in dotted
-   decimal notation (e.g., when SCCS is used to maintain the files)
-   should beware of a bug in all BIND versions: if the serial number is
-   in Release.Version (dotted decimal) notation, then it is virtually
-   impossible to change to a higher release: because of the wrong way
-   that notation is turned into an integer, it results in a serial
-   number that is LOWER than that of the former release.
-
-   For this reason and because the Serial is an (unsigned) integer
-   according to STD 13, RFC 1035, it is recommended not to use the
-   dotted decimal notation. A recommended notation is to use the date
-   (yyyymmdd), if necessary with an extra digit (yyyymmddn) if there is
-   or can be more than one change per day in a zone file.
-
-   Very old versions of DNS resolver code have a bug that causes queries
-   for A records with domain names like "192.16.184.3" to go out. This
-   happens when users type in IP addresses and the resolver code does
-   not catch this case before sending out a DNS query. This problem has
-   been fixed in all resolver implementations known to us but if it
-   still pops up it is very serious because all those queries will go to
-
-
-
-Beertema                                                        [Page 6]
-
-RFC 1537       Common DNS Data File Configuration Errors    October 1993
-
-
-   the root servers looking for top level domains like "3" etc. It is
-   strongly recommended to install the latest (publicly) available BIND
-   version plus all available patches to get rid of these and other
-   problems.
-
-   Running secondary nameserver off another secondary nameserver is
-   possible, but not recommended unless really necessary: there are
-   known cases where it has led to problems like bogus TTL values. This
-   can be caused by older or flawed implementations, but secondary
-   nameservers in principle should always transfer their zones from the
-   official primary nameserver.
-
-11. Some general points
-
-   The Domain Name System and nameserver are purely technical tools, not
-   meant in any way to exert control or impose politics. The function of
-   a naming authority is that of a clearing house. Anyone registering a
-   subdomain under a particular (top level) domain becomes naming
-   authority and therewith the sole responsible for that subdomain.
-   Requests to enter MX or NS records concerning such a subdomain
-   therefore always MUST be honored by the registrar of the next higher
-   domain.
-
-   Examples of practices that are not allowed are:
-
-      - imposing specific mail routing (MX records) when registering
-        a subdomain.
-
-      - making registration of a subdomain dependent on to the use of
-        certain networks or services.
-
-      - using TXT records as a means of (free) commercial advertising.
-
-   In the latter case a network service provider could decide to cut off
-   a particular site until the offending TXT records have been removed
-   from the site's zone file.
-
-   Of course there are obvious cases where a naming authority can refuse
-   to register a particular subdomain and can require a proposed name to
-   be changed in order to get it registered (think of DEC trying to
-   register a domain IBM.XX).
-
-   There are also cases were one has to probe the authority of the
-   person: sending in the application - not every systems manager should
-   be able to register a domain name for a whole university.  The naming
-   authority can impose certain extra rules as long as they don't
-   violate or conflict with the rights and interest of the registrars of
-   subdomains; a top level domain registrar may e.g., require that there
-
-
-
-Beertema                                                        [Page 7]
-
-RFC 1537       Common DNS Data File Configuration Errors    October 1993
-
-
-   be primary subdomain "ac" and "co" only and that subdomains be
-   registered under those primary subdomains.
-
-   The naming authority can also interfere in exceptional cases like the
-   one mentioned in point 4, e.g., by temporarily removing a domain's
-   entry from the nameserver zone files; this of course should be done
-   only with extreme care and only as a last resort.
-
-   When adding NS records for subdomains, top level domain nameserver
-   managers should realize that the people setting up the nameserver for
-   a subdomain often are rather inexperienced and can make mistakes that
-   can easily lead to the subdomain becoming completely unreachable or
-   that can cause unnecessary DNS traffic (see point 1). It is therefore
-   highly recommended that, prior to entering such an NS record, the
-   (top level) nameserver manager does a couple of sanity checks on the
-   new nameserver (SOA record and timers OK?, MX records present where
-   needed? No obvious errors made? Listed secondary servers
-   operational?). Things that cannot be caught though by such checks
-   are:
-
-      - resolvers set up to use external hosts as nameservers
-
-      - nameservers set up to use external hosts as forwarders
-        without permission from those hosts.
-
-   Care should also be taken when registering 2-letter subdomains.
-   Although this is allowed, an implication is that abbreviated
-   addressing (see STD 11, RFC 822, paragraph 6.2.2) is not possible in
-   and under that subdomain.  When requested to register such a domain,
-   one should always notify the people of this consequence. As an
-   example take the name "cs", which is commonly used for Computer
-   Science departments: it is also the name of the top level domain for
-   Czecho-Slovakia, so within the domain cs.foo.bar the user@host.cs is
-   ambiguous in that in can denote both a user on the host
-   host.cs.foo.bar and a user on the host "host" in Czecho-Slovakia.
-   (This example does not take into account the recent political changes
-   in the mentioned country).
-
-References
-
-   [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
-       RFC 1034, USC/Information Sciences Institute, November 1987.
-
-   [2] Mockapetris, P., "Domain Names Implementation and Specification",
-       STD 13, RFC 1035, USC/Information Sciences Institute, November
-       1987.
-
-
-
-
-
-Beertema                                                        [Page 8]
-
-RFC 1537       Common DNS Data File Configuration Errors    October 1993
-
-
-   [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
-       974, CSNET CIC BBN, January 1986.
-
-   [4] Gavron, E., "A Security Problem and Proposed Correction With
-       Widely Deployed DNS Software", RFC 1535, ACES Research Inc.,
-       October 1993.
-
-   [5] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller,
-       "Common DNS Implementation Errors and Suggested Fixes", RFC 1536,
-       USC/Information Sciences Institute, USC, October 1993.
-
-Security Considerations
-
-   Security issues are not discussed in this memo.
-
-Author's Address
-
-   Piet Beertema
-   CWI
-   Kruislaan 413
-   NL-1098 SJ Amsterdam
-   The Netherlands
-
-   Phone: +31 20 592 4112
-   FAX:   +31 20 592 4199
-   EMail: Piet.Beertema@cwi.nl
-
-
-Editor's Address
-
-   Anant Kumar
-   USC Information Sciences Institute
-   4676 Admiralty Way
-   Marina Del Rey CA 90292-6695
-
-   Phone:(310) 822-1511
-   FAX:  (310) 823-6741
-   EMail: anant@isi.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-Beertema                                                        [Page 9]
-
\ No newline at end of file
diff --git a/contrib/bind9/doc/rfc/rfc1591.txt b/contrib/bind9/doc/rfc/rfc1591.txt
deleted file mode 100644
index 89e0a25..0000000
--- a/contrib/bind9/doc/rfc/rfc1591.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          J. Postel
-Request for Comments: 1591                                           ISI
-Category: Informational                                       March 1994
-
-
-              Domain Name System Structure and Delegation
-
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  This memo
-   does not specify an Internet standard of any kind.  Distribution of
-   this memo is unlimited.
-
-1. Introduction
-
-   This memo provides some information on the structure of the names in
-   the Domain Name System (DNS), specifically the top-level domain
-   names; and on the administration of domains.  The Internet Assigned
-   Numbers Authority (IANA) is the overall authority for the IP
-   Addresses, the Domain Names, and many other parameters, used in the
-   Internet.  The day-to-day responsibility for the assignment of IP
-   Addresses, Autonomous System Numbers, and most top and second level
-   Domain Names are handled by the Internet Registry (IR) and regional
-   registries.
-
-2.  The Top Level Structure of the Domain Names
-
-   In the Domain Name System (DNS) naming of computers there is a
-   hierarchy of names.  The root of system is unnamed.  There are a set
-   of what are called "top-level domain names" (TLDs).  These are the
-   generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two
-   letter country codes from ISO-3166.  It is extremely unlikely that
-   any other TLDs will be created.
-
-   Under each TLD may be created a hierarchy of names.  Generally, under
-   the generic TLDs the structure is very flat.  That is, many
-   organizations are registered directly under the TLD, and any further
-   structure is up to the individual organizations.
-
-   In the country TLDs, there is a wide variation in the structure, in
-   some countries the structure is very flat, in others there is
-   substantial structural organization.  In some country domains the
-   second levels are generic categories (such as, AC, CO, GO, and RE),
-   in others they are based on political geography, and in still others,
-   organization names are listed directly under the country code.  The
-   organization for the US country domain is described in RFC 1480 [1].
-
-
-
-
-Postel                                                          [Page 1]
-
-RFC 1591      Domain Name System Structure and Delegation     March 1994
-
-
-   Each of the generic TLDs was created for a general category of
-   organizations.  The country code domains (for example, FR, NL, KR,
-   US) are each organized by an administrator for that country.  These
-   administrators may further delegate the management of portions of the
-   naming tree.  These administrators are performing a public service on
-   behalf of the Internet community.  Descriptions of the generic
-   domains and the US country domain follow.
-
-   Of these generic domains, five are international in nature, and two
-   are restricted to use by entities in the United States.
-
-   World Wide Generic Domains:
-
-   COM - This domain is intended for commercial entities, that is
-         companies.  This domain has grown very large and there is
-         concern about the administrative load and system performance if
-         the current growth pattern is continued.  Consideration is
-         being taken to subdivide the COM domain and only allow future
-         commercial registrations in the subdomains.
-
-   EDU - This domain was originally intended for all educational
-         institutions.  Many Universities, colleges, schools,
-         educational service organizations, and educational consortia
-         have registered here.  More recently a decision has been taken
-         to limit further registrations to 4 year colleges and
-         universities.  Schools and 2-year colleges will be registered
-         in the country domains (see US Domain, especially K12 and CC,
-         below).
-
-   NET - This domain is intended to hold only the computers of network
-         providers, that is the NIC and NOC computers, the
-         administrative computers, and the network node computers.  The
-         customers of the network provider would have domain names of
-         their own (not in the NET TLD).
-
-   ORG - This domain is intended as the miscellaneous TLD for
-         organizations that didn't fit anywhere else.  Some non-
-         government organizations may fit here.
-
-   INT - This domain is for organizations established by international
-         treaties, or international databases.
-
-   United States Only Generic Domains:
-
-   GOV - This domain was originally intended for any kind of government
-         office or agency.  More recently a decision was taken to
-         register only agencies of the US Federal government in this
-         domain.  State and local agencies are registered in the country
-
-
-
-Postel                                                          [Page 2]
-
-RFC 1591      Domain Name System Structure and Delegation     March 1994
-
-
-         domains (see US Domain, below).
-
-   MIL - This domain is used by the US military.
-
-   Example country code Domain:
-
-   US - As an example of a country domain, the US domain provides for
-        the registration of all kinds of entities in the United States
-        on the basis of political geography, that is, a hierarchy of
-        <entity-name>.<locality>.<state-code>.US.  For example,
-        "IBM.Armonk.NY.US".  In addition, branches of the US domain are
-        provided within each state for schools (K12), community colleges
-        (CC), technical schools (TEC), state government agencies
-        (STATE), councils of governments (COG),libraries (LIB), museums
-        (MUS), and several other generic types of entities (see RFC 1480
-        for details [1]).
-
-   To find a contact for a TLD use the "whois" program to access the
-   database on the host rs.internic.net.  Append "-dom" to the name of
-   TLD you are interested in.  For example:
-
-                       whois -h rs.internic.net us-dom
-      or
-                       whois -h rs.internic.net edu-dom
-
-3.  The Administration of Delegated Domains
-
-   The Internet Assigned Numbers Authority (IANA) is responsible for the
-   overall coordination and management of the Domain Name System (DNS),
-   and especially the delegation of portions of the name space called
-   top-level domains.  Most of these top-level domains are two-letter
-   country codes taken from the ISO standard 3166.
-
-   A central Internet Registry (IR) has been selected and designated to
-   handled the bulk of the day-to-day administration of the Domain Name
-   System.  Applications for new top-level domains (for example, country
-   code domains) are handled by the IR with consultation with the IANA.
-   The central IR is INTERNIC.NET.  Second level domains in COM, EDU,
-   ORG, NET, and GOV are registered by the Internet Registry at the
-   InterNIC.  The second level domains in the MIL are registered by the
-   DDN registry at NIC.DDN.MIL.  Second level names in INT are
-   registered by the PVM at ISI.EDU.
-
-   While all requests for new top-level domains must be sent to the
-   Internic (at hostmaster@internic.net), the regional registries are
-   often enlisted to assist in the administration of the DNS, especially
-   in solving problems with a country administration.  Currently, the
-   RIPE NCC is the regional registry for Europe and the APNIC is the
-
-
-
-Postel                                                          [Page 3]
-
-RFC 1591      Domain Name System Structure and Delegation     March 1994
-
-
-   regional registry for the Asia-Pacific region, while the INTERNIC
-   administers the North America region, and all the as yet undelegated
-   regions.
-
-      The contact mailboxes for these regional registries are:
-
-         INTERNIC        hostmaster@internic.net
-         APNIC           hostmaster@apnic.net
-         RIPE NCC        ncc@ripe.net
-
-   The policy concerns involved when a new top-level domain is
-   established are described in the following.  Also mentioned are
-   concerns raised when it is necessary to change the delegation of an
-   established domain from one party to another.
-
-   A new top-level domain is usually created and its management
-   delegated to a "designated manager" all at once.
-
-   Most of these same concerns are relevant when a sub-domain is
-   delegated and in general the principles described here apply
-   recursively to all delegations of the Internet DNS name space.
-
-   The major concern in selecting a designated manager for a domain is
-   that it be able to carry out the necessary responsibilities, and have
-   the ability to do a equitable, just, honest, and competent job.
-
-   1) The key requirement is that for each domain there be a designated
-      manager for supervising that domain's name space.  In the case of
-      top-level domains that are country codes this means that there is
-      a manager that supervises the domain names and operates the domain
-      name system in that country.
-
-      The manager must, of course, be on the Internet.  There must be
-      Internet Protocol (IP) connectivity to the nameservers and email
-      connectivity to the management and staff of the manager.
-
-      There must be an administrative contact and a technical contact
-      for each domain.  For top-level domains that are country codes at
-      least the administrative contact must reside in the country
-      involved.
-
-   2) These designated authorities are trustees for the delegated
-      domain, and have a duty to serve the community.
-
-      The designated manager is the trustee of the top-level domain for
-      both the nation, in the case of a country code, and the global
-      Internet community.
-
-
-
-
-Postel                                                          [Page 4]
-
-RFC 1591      Domain Name System Structure and Delegation     March 1994
-
-
-      Concerns about "rights" and "ownership" of domains are
-      inappropriate.  It is appropriate to be concerned about
-      "responsibilities" and "service" to the community.
-
-   3) The designated manager must be equitable to all groups in the
-      domain that request domain names.
-
-      This means that the same rules are applied to all requests, all
-      requests must be processed in a non-discriminatory fashion, and
-      academic and commercial (and other) users are treated on an equal
-      basis.  No bias shall be shown regarding requests that may come
-      from customers of some other business related to the manager --
-      e.g., no preferential service for customers of a particular data
-      network provider.  There can be no requirement that a particular
-      mail system (or other application), protocol, or product be used.
-
-      There are no requirements on subdomains of top-level domains
-      beyond the requirements on higher-level domains themselves.  That
-      is, the requirements in this memo are applied recursively.  In
-      particular, all subdomains shall be allowed to operate their own
-      domain name servers, providing in them whatever information the
-      subdomain manager sees fit (as long as it is true and correct).
-
-   4) Significantly interested parties in the domain should agree that
-      the designated manager is the appropriate party.
-
-      The IANA tries to have any contending parties reach agreement
-      among themselves, and generally takes no action to change things
-      unless all the contending parties agree; only in cases where the
-      designated manager has substantially mis-behaved would the IANA
-      step in.
-
-      However, it is also appropriate for interested parties to have
-      some voice in selecting the designated manager.
-
-      There are two cases where the IANA and the central IR may
-      establish a new top-level domain and delegate only a portion of
-      it: (1) there are contending parties that cannot agree, or (2) the
-      applying party may not be able to represent or serve the whole
-      country.  The later case sometimes arises when a party outside a
-      country is trying to be helpful in getting networking started in a
-      country -- this is sometimes called a "proxy" DNS service.
-
-      The Internet DNS Names Review Board (IDNB), a committee
-      established by the IANA, will act as a review panel for cases in
-      which the parties can not reach agreement among themselves.  The
-      IDNB's decisions will be binding.
-
-
-
-
-Postel                                                          [Page 5]
-
-RFC 1591      Domain Name System Structure and Delegation     March 1994
-
-
-   5) The designated manager must do a satisfactory job of operating the
-      DNS service for the domain.
-
-      That is, the actual management of the assigning of domain names,
-      delegating subdomains and operating nameservers must be done with
-      technical competence.  This includes keeping the central IR (in
-      the case of top-level domains) or other higher-level domain
-      manager advised of the status of the domain, responding to
-      requests in a timely manner, and operating the database with
-      accuracy, robustness, and resilience.
-
-      There must be a primary and a secondary nameserver that have IP
-      connectivity to the Internet and can be easily checked for
-      operational status and database accuracy by the IR and the IANA.
-
-      In cases when there are persistent problems with the proper
-      operation of a domain, the delegation may be revoked, and possibly
-      delegated to another designated manager.
-
-   6) For any transfer of the designated manager trusteeship from one
-      organization to another, the higher-level domain manager (the IANA
-      in the case of top-level domains) must receive communications from
-      both the old organization and the new organization that assure the
-      IANA that the transfer in mutually agreed, and that the new
-      organization understands its responsibilities.
-
-      It is also very helpful for the IANA to receive communications
-      from other parties that may be concerned or affected by the
-      transfer.
-
-4. Rights to Names
-
-   1) Names and Trademarks
-
-      In case of a dispute between domain name registrants as to the
-      rights to a particular name, the registration authority shall have
-      no role or responsibility other than to provide the contact
-      information to both parties.
-
-      The registration of a domain name does not have any Trademark
-      status.  It is up to the requestor to be sure he is not violating
-      anyone else's Trademark.
-
-   2) Country Codes
-
-      The IANA is not in the business of deciding what is and what is
-      not a country.
-
-
-
-
-Postel                                                          [Page 6]
-
-RFC 1591      Domain Name System Structure and Delegation     March 1994
-
-
-      The selection of the ISO 3166 list as a basis for country code
-      top-level domain names was made with the knowledge that ISO has a
-      procedure for determining which entities should be and should not
-      be on that list.
-
-5. Security Considerations
-
-   Security issues are not discussed in this memo.
-
-6. Acknowledgements
-
-   Many people have made comments on draft version of these descriptions
-   and procedures.  Steve Goldstein and John Klensin have been
-   particularly helpful.
-
-7. Author's Address
-
-   Jon Postel
-   USC/Information Sciences Institute
-   4676 Admiralty Way
-   Marina del Rey, CA  90292
-
-   Phone: 310-822-1511
-   Fax:   310-823-6714
-   EMail: Postel@ISI.EDU
-
-7. References
-
-   [1] Cooper, A., and J. Postel, "The US Domain", RFC 1480,
-       USC/Information Sciences Institute, June 1993.
-
-   [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
-       USC/Information Sciences Institute, July 1992.
-
-   [3] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
-       13, RFC 1034, USC/Information Sciences Institute, November 1987.
-
-   [4] Mockapetris, P., "Domain Names - Implementation and
-       Specification", STD 13, RFC 1035, USC/Information Sciences
-       Institute, November 1987.
-
-   [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
-       974, CSNET CIC BBN, January 1986.
-
-   [7] Braden, R., Editor, "Requirements for Internet Hosts --
-       Application and Support", STD 3, RFC 1123, Internet Engineering
-       Task Force, October 1989.
-
-
-
-
-Postel                                                          [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc1611.txt b/contrib/bind9/doc/rfc/rfc1611.txt
deleted file mode 100644
index ed5b93a..0000000
--- a/contrib/bind9/doc/rfc/rfc1611.txt
+++ /dev/null
@@ -1,1683 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         R. Austein
-Request for Comments: 1611               Epilogue Technology Corporation
-Category: Standards Track                                     J. Saperia
-                                           Digital Equipment Corporation
-                                                                May 1994
-
-                       DNS Server MIB Extensions
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Table of Contents
-
-   1. Introduction ..............................................    1
-   2. The SNMPv2 Network Management Framework ...................    2
-   2.1 Object Definitions .......................................    2
-   3. Overview ..................................................    2
-   3.1 Resolvers ................................................    3
-   3.2 Name Servers .............................................    3
-   3.3 Selected Objects .........................................    4
-   3.4 Textual Conventions ......................................    4
-   4. Definitions ...............................................    5
-   5. Acknowledgements ..........................................   28
-   6. References ................................................   28
-   7. Security Considerations ...................................   29
-   8. Authors' Addresses ........................................   30
-
-1.  Introduction
-
-   This memo defines a portion of the Management Information Base (MIB)
-   for use with network management protocols in the Internet community.
-   In particular, it describes a set of extensions which instrument DNS
-   name server functions.  This memo was produced by the DNS working
-   group.
-
-   With the adoption of the Internet-standard Network Management
-   Framework [4,5,6,7], and with a large number of vendor
-   implementations of these standards in commercially available
-   products, it became possible to provide a higher level of effective
-   network management in TCP/IP-based internets than was previously
-   available.  With the growth in the use of these standards, it has
-   become possible to consider the management of other elements of the
-   infrastructure beyond the basic TCP/IP protocols.  A key element of
-
-
-
-Austein & Saperia                                               [Page 1]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   the TCP/IP infrastructure is the DNS.
-
-   Up to this point there has been no mechanism to integrate the
-   management of the DNS with SNMP-based managers.  This memo provides
-   the mechanisms by which IP-based management stations can effectively
-   manage DNS name server software in an integrated fashion.
-
-   We have defined DNS MIB objects to be used in conjunction with the
-   Internet MIB to allow access to and control of DNS name server
-   software via SNMP by the Internet community.
-
-2.  The SNMPv2 Network Management Framework
-
-   The SNMPv2 Network Management Framework consists of four major
-   components.  They are:
-
-      o  RFC 1442 which defines the SMI, the mechanisms used for
-         describing and naming objects for the purpose of management.
-
-      o  STD 17, RFC 1213 defines MIB-II, the core set of managed objects
-         for the Internet suite of protocols.
-
-      o  RFC 1445 which defines the administrative and other architectural
-         aspects of the framework.
-
-      o  RFC 1448 which defines the protocol used for network access to
-         managed objects.
-
-      The Framework permits new objects to be defined for the purpose of
-      experimentation and evaluation.
-
-2.1.  Object Definitions
-
-   Managed objects are accessed via a virtual information store, termed
-   the Management Information Base or MIB.  Objects in the MIB are
-   defined using the subset of Abstract Syntax Notation One (ASN.1)
-   defined in the SMI.  In particular, each object object type is named
-   by an OBJECT IDENTIFIER, an administratively assigned name.  The
-   object type together with an object instance serves to uniquely
-   identify a specific instantiation of the object.  For human
-   convenience, we often use a textual string, termed the descriptor, to
-   refer to the object type.
-
-3.  Overview
-
-   In theory, the DNS world is pretty simple.  There are two kinds of
-   entities: resolvers and name servers.  Resolvers ask questions.  Name
-   servers answer them.  The real world, however, is not so simple.
-
-
-
-Austein & Saperia                                               [Page 2]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   Implementors have made widely differing choices about how to divide
-   DNS functions between resolvers and servers.  They have also
-   constructed various sorts of exotic hybrids.  The most difficult task
-   in defining this MIB was to accommodate this wide range of entities
-   without having to come up with a separate MIB for each.
-
-   We divided up the various DNS functions into two, non-overlapping
-   classes, called "resolver functions" and "name server functions."  A
-   DNS entity that performs what we define as resolver functions
-   contains a resolver, and therefore must implement the MIB groups
-   required of all resolvers which are defined in a separate MIB Module.
-   A DNS entity which implements name server functions is considered to
-   be a name server, and must implement the MIB groups required for name
-   servers in this module.  If the same piece of software performs both
-   resolver and server functions, we imagine that it contains both a
-   resolver and a server and would thus implement both the DNS Server
-   and DNS Resolver MIBs.
-
-3.1.  Resolvers
-
-   In our model, a resolver is a program (or piece thereof) which
-   obtains resource records from servers.  Normally it does so at the
-   behest of an application, but may also do so as part of its own
-   operation.  A resolver sends DNS protocol queries and receives DNS
-   protocol replies.  A resolver neither receives queries nor sends
-   replies.  A full service resolver is one that knows how to resolve
-   queries: it obtains the needed resource records by contacting a
-   server authoritative for the records desired.  A stub resolver does
-   not know how to resolve queries: it sends all queries to a local name
-   server, setting the "recursion desired" flag to indicate that it
-   hopes that the name server will be willing to resolve the query.  A
-   resolver may (optionally) have a cache for remembering previously
-   acquired resource records.  It may also have a negative cache for
-   remembering names or data that have been determined not to exist.
-
-3.2.  Name Servers
-
-   A name server is a program (or piece thereof) that provides resource
-   records to resolvers.  All references in this document to "a name
-   server" imply "the name server's role"; in some cases the name
-   server's role and the resolver's role might be combined into a single
-   program.  A name server receives DNS protocol queries and sends DNS
-   protocol replies.  A name server neither sends queries nor receives
-   replies.  As a consequence, name servers do not have caches.
-   Normally, a name server would expect to receive only those queries to
-   which it could respond with authoritative information.  However, if a
-   name server receives a query that it cannot respond to with purely
-   authoritative information, it may choose to try to obtain the
-
-
-
-Austein & Saperia                                               [Page 3]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   necessary additional information from a resolver which may or may not
-   be a separate process.
-
-3.3.  Selected Objects
-
-   Many of the objects included in this memo have been created from
-   information contained in the DNS specifications [1,2], as amended and
-   clarified by subsequent host requirements documents [3].  Other
-   objects have been created based on experience with existing DNS
-   management tools, expected operational needs, the statistics
-   generated by existing DNS implementations, and the configuration
-   files used by existing DNS implementations.  These objects have been
-   ordered into groups as follows:
-
-      o  Server Configuration Group
-
-      o  Server Counter Group
-
-      o  Server Optional Counter Group
-
-      o  Server Zone Group
-
-   This information has been converted into a standard form using the
-   SNMPv2 SMI defined in [9].  For the most part, the descriptions are
-   influenced by the DNS related RFCs noted above.  For example, the
-   descriptions for counters used for the various types of queries of
-   DNS records are influenced by the definitions used for the various
-   record types found in [2].
-
-3.4.  Textual Conventions
-
-   Several conceptual data types have been introduced as a textual
-   conventions in this DNS MIB document.  These additions will
-   facilitate the common understanding of information used by the DNS.
-   No changes to the SMI or the SNMP are necessary to support these
-   conventions.
-
-   Readers familiar with MIBs designed to manage entities in the lower
-   layers of the Internet protocol suite may be surprised at the number
-   of non-enumerated integers used in this MIB to represent values such
-   as DNS RR class and type numbers.  The reason for this choice is
-   simple: the DNS itself is designed as an extensible protocol,
-   allowing new classes and types of resource records to be added to the
-   protocol without recoding the core DNS software.  Using non-
-   enumerated integers to represent these data types in this MIB allows
-   the MIB to accommodate these changes as well.
-
-
-
-
-
-Austein & Saperia                                               [Page 4]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-4.  Definitions
-
-   DNS-SERVER-MIB DEFINITIONS ::= BEGIN
-
-   IMPORTS
-       mib-2
-           FROM RFC-1213
-       MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY,
-       IpAddress, Counter32, Gauge32
-           FROM SNMPv2-SMI
-       TEXTUAL-CONVENTION, RowStatus, DisplayString, TruthValue
-           FROM SNMPv2-TC
-       MODULE-COMPLIANCE, OBJECT-GROUP
-           FROM SNMPv2-CONF;
-
-   dns OBJECT-IDENTITY
-       STATUS  current
-       DESCRIPTION
-               "The OID assigned to DNS MIB work by the IANA."
-       ::= { mib-2 32 }
-
-   dnsServMIB MODULE-IDENTITY
-       LAST-UPDATED "9401282251Z"
-       ORGANIZATION "IETF DNS Working Group"
-       CONTACT-INFO
-               "       Rob Austein
-               Postal: Epilogue Technology Corporation
-                       268 Main Street, Suite 283
-                       North Reading, MA 10864
-                       US
-                  Tel: +1 617 245 0804
-                  Fax: +1 617 245 8122
-               E-Mail: sra@epilogue.com
-
-                       Jon Saperia
-               Postal: Digital Equipment Corporation
-                       110 Spit Brook Road
-                       ZKO1-3/H18
-                       Nashua, NH 03062-2698
-                       US
-                  Tel: +1 603 881 0480
-                  Fax: +1 603 881 0120
-                Email: saperia@zko.dec.com"
-       DESCRIPTION
-               "The MIB module for entities implementing the server side
-               of the Domain Name System (DNS) protocol."
-       ::= { dns 1 }
-
-
-
-
-Austein & Saperia                                               [Page 5]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   dnsServMIBObjects       OBJECT IDENTIFIER ::= { dnsServMIB 1 }
-
-   -- (Old-style) groups in the DNS server MIB.
-
-   dnsServConfig           OBJECT IDENTIFIER ::= { dnsServMIBObjects 1 }
-   dnsServCounter          OBJECT IDENTIFIER ::= { dnsServMIBObjects 2 }
-   dnsServOptCounter       OBJECT IDENTIFIER ::= { dnsServMIBObjects 3 }
-   dnsServZone             OBJECT IDENTIFIER ::= { dnsServMIBObjects 4 }
-
-
-   -- Textual conventions
-
-   DnsName ::= TEXTUAL-CONVENTION
-       -- A DISPLAY-HINT would be nice, but difficult to express.
-       STATUS  current
-       DESCRIPTION
-               "A DNS name is a sequence of labels.  When DNS names are
-               displayed, the boundaries between labels are typically
-               indicated by dots (e.g. `Acme' and `COM' are labels in
-               the name `Acme.COM').  In the DNS protocol, however, no
-               such separators are needed because each label is encoded
-               as a length octet followed by the indicated number of
-               octets of label.  For example, `Acme.COM' is encoded as
-               the octet sequence { 4, 'A', 'c', 'm', 'e', 3, 'C', 'O',
-               'M', 0 } (the final 0 is the length of the name of the
-               root domain, which appears implicitly at the end of any
-               DNS name).  This MIB uses the same encoding as the DNS
-               protocol.
-
-               A DnsName must always be a fully qualified name.  It is
-               an error to encode a relative domain name as a DnsName
-               without first making it a fully qualified name."
-       REFERENCE
-               "RFC-1034 section 3.1."
-       SYNTAX  OCTET STRING (SIZE (0..255))
-
-   DnsNameAsIndex ::= TEXTUAL-CONVENTION
-       STATUS  current
-       DESCRIPTION
-               "This textual convention is like a DnsName, but is used
-               as an index componant in tables.  Alphabetic characters
-               in names of this type are restricted to uppercase: the
-               characters 'a' through 'z' are mapped to the characters
-               'A' through 'Z'.  This restriction is intended to make
-               the lexical ordering imposed by SNMP useful when applied
-               to DNS names.
-
-               Note that it is theoretically possible for a valid DNS
-
-
-
-Austein & Saperia                                               [Page 6]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-               name to exceed the allowed length of an SNMP object
-               identifer, and thus be impossible to represent in tables
-               in this MIB that are indexed by DNS name.  Sampling of
-               DNS names in current use on the Internet suggests that
-               this limit does not pose a serious problem in practice."
-       REFERENCE
-               "RFC-1034 section 3.1, RFC-1448 section 4.1."
-       SYNTAX  DnsName
-
-   DnsClass ::= TEXTUAL-CONVENTION
-       DISPLAY-HINT "2d"
-       STATUS  current
-       DESCRIPTION
-               "This data type is used to represent the class values
-               which appear in Resource Records in the DNS.  A 16-bit
-               unsigned integer is used to allow room for new classes
-               of records to be defined.  Existing standard classes are
-               listed in the DNS specifications."
-       REFERENCE
-               "RFC-1035 section 3.2.4."
-       SYNTAX  INTEGER (0..65535)
-
-   DnsType ::= TEXTUAL-CONVENTION
-       DISPLAY-HINT "2d"
-       STATUS  current
-       DESCRIPTION
-               "This data type is used to represent the type values
-               which appear in Resource Records in the DNS.  A 16-bit
-               unsigned integer is used to allow room for new record
-               types to be defined.  Existing standard types are listed
-               in the DNS specifications."
-       REFERENCE
-               "RFC-1035 section 3.2.2."
-       SYNTAX  INTEGER (0..65535)
-
-   DnsQClass ::= TEXTUAL-CONVENTION
-       DISPLAY-HINT "2d"
-       STATUS  current
-       DESCRIPTION
-               "This data type is used to represent the QClass values
-               which appear in Resource Records in the DNS.  A 16-bit
-               unsigned integer is used to allow room for new QClass
-               records to be defined.  Existing standard QClasses are
-               listed in the DNS specification."
-       REFERENCE
-               "RFC-1035 section 3.2.5."
-       SYNTAX  INTEGER (0..65535)
-
-
-
-
-Austein & Saperia                                               [Page 7]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   DnsQType ::= TEXTUAL-CONVENTION
-       DISPLAY-HINT "2d"
-       STATUS  current
-       DESCRIPTION
-               "This data type is used to represent the QType values
-               which appear in Resource Records in the DNS.  A 16-bit
-               unsigned integer is used to allow room for new QType
-               records to be defined.  Existing standard QTypes are
-               listed in the DNS specification."
-       REFERENCE
-               "RFC-1035 section 3.2.3."
-       SYNTAX  INTEGER (0..65535)
-
-   DnsTime ::= TEXTUAL-CONVENTION
-       DISPLAY-HINT "4d"
-       STATUS  current
-       DESCRIPTION
-               "DnsTime values are 32-bit unsigned integers which
-               measure time in seconds."
-       REFERENCE
-               "RFC-1035."
-       SYNTAX  Gauge32
-
-
-   DnsOpCode ::= TEXTUAL-CONVENTION
-       STATUS  current
-       DESCRIPTION
-               "This textual convention is used to represent the DNS
-               OPCODE values used in the header section of DNS
-               messages.  Existing standard OPCODE values are listed in
-               the DNS specifications."
-       REFERENCE
-               "RFC-1035 section 4.1.1."
-       SYNTAX  INTEGER (0..15)
-
-   DnsRespCode ::= TEXTUAL-CONVENTION
-       STATUS  current
-       DESCRIPTION
-               "This data type is used to represent the DNS RCODE value
-               in DNS response messages.  Existing standard RCODE
-               values are listed in the DNS specifications."
-       REFERENCE
-               "RFC-1035 section 4.1.1."
-       SYNTAX  INTEGER (0..15)
-
-
-
-
-
-
-
-Austein & Saperia                                               [Page 8]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   -- Server Configuration Group
-
-   dnsServConfigImplementIdent OBJECT-TYPE
-       SYNTAX      DisplayString
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "The implementation identification string for the DNS
-               server software in use on the system, for example;
-               `FNS-2.1'"
-       ::= { dnsServConfig 1 }
-
-   dnsServConfigRecurs  OBJECT-TYPE
-       SYNTAX      INTEGER { available(1),
-                             restricted(2),
-                             unavailable(3) }
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-               "This represents the recursion services offered by this
-               name server.  The values that can be read or written
-               are:
-
-               available(1) - performs recursion on requests from
-               clients.
-
-               restricted(2) - recursion is performed on requests only
-               from certain clients, for example; clients on an access
-               control list.
-
-               unavailable(3) - recursion is not available."
-        ::= { dnsServConfig 2 }
-
-   dnsServConfigUpTime OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "If the server has a persistent state (e.g., a process),
-               this value will be the time elapsed since it started.
-               For software without persistant state, this value will
-               be zero."
-       ::= { dnsServConfig 3 }
-
-   dnsServConfigResetTime OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-
-
-
-Austein & Saperia                                               [Page 9]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       DESCRIPTION
-               "If the server has a persistent state (e.g., a process)
-               and supports a `reset' operation (e.g., can be told to
-               re-read configuration files), this value will be the
-               time elapsed since the last time the name server was
-               `reset.'  For software that does not have persistence or
-               does not support a `reset' operation, this value will be
-               zero."
-       ::= { dnsServConfig 4 }
-
-   dnsServConfigReset OBJECT-TYPE
-       SYNTAX      INTEGER { other(1),
-                             reset(2),
-                             initializing(3),
-                             running(4) }
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-               "Status/action object to reinitialize any persistant name
-               server state.  When set to reset(2), any persistant
-               name server state (such as a process) is reinitialized as
-               if the name server had just been started.  This value
-               will never be returned by a read operation.  When read,
-               one of the following values will be returned:
-                   other(1) - server in some unknown state;
-                   initializing(3) - server (re)initializing;
-                   running(4) - server currently running."
-       ::= { dnsServConfig 5 }
-
-
-   -- Server Counter Group
-
-   dnsServCounterAuthAns OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries which were authoritatively answered."
-       ::= { dnsServCounter 2 }
-
-   dnsServCounterAuthNoNames OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries for which `authoritative no such name'
-               responses were made."
-       ::= { dnsServCounter 3 }
-
-
-
-Austein & Saperia                                              [Page 10]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   dnsServCounterAuthNoDataResps OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries for which `authoritative no such data'
-               (empty answer) responses were made."
-       ::= { dnsServCounter 4 }
-
-   dnsServCounterNonAuthDatas OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries which were non-authoritatively
-               answered (cached data)."
-       ::= { dnsServCounter 5 }
-
-   dnsServCounterNonAuthNoDatas OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries which were non-authoritatively
-               answered with no data (empty answer)."
-       ::= { dnsServCounter 6 }
-
-   dnsServCounterReferrals OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests that were referred to other servers."
-       ::= { dnsServCounter 7 }
-
-   dnsServCounterErrors OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests the server has processed that were
-               answered with errors (RCODE values other than 0 and 3)."
-       REFERENCE
-               "RFC-1035 section 4.1.1."
-       ::= { dnsServCounter 8 }
-
-   dnsServCounterRelNames OBJECT-TYPE
-       SYNTAX      Counter32
-
-
-
-Austein & Saperia                                              [Page 11]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests received by the server for names that
-               are only 1 label long (text form - no internal dots)."
-       ::= { dnsServCounter 9 }
-
-   dnsServCounterReqRefusals OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of DNS requests refused by the server."
-       ::= { dnsServCounter 10 }
-
-   dnsServCounterReqUnparses OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests received which were unparseable."
-       ::= { dnsServCounter 11 }
-
-   dnsServCounterOtherErrors OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests which were aborted for other (local)
-               server errors."
-       ::= { dnsServCounter 12 }
-
-   -- DNS Server Counter Table
-
-   dnsServCounterTable OBJECT-TYPE
-       SYNTAX      SEQUENCE OF DnsServCounterEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Counter information broken down by DNS class and type."
-       ::= { dnsServCounter 13 }
-
-   dnsServCounterEntry OBJECT-TYPE
-       SYNTAX      DnsServCounterEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "This table contains count information for each DNS class
-
-
-
-Austein & Saperia                                              [Page 12]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-               and type value known to the server.  The index allows
-               management software to to create indices to the table to
-               get the specific information desired, e.g., number of
-               queries over UDP for records with type value `A' which
-               came to this server.  In order to prevent an
-               uncontrolled expansion of rows in the table; if
-               dnsServCounterRequests is 0 and dnsServCounterResponses
-               is 0, then the row does not exist and `no such' is
-               returned when the agent is queried for such instances."
-       INDEX     { dnsServCounterOpCode,
-                   dnsServCounterQClass,
-                   dnsServCounterQType,
-                   dnsServCounterTransport }
-       ::= { dnsServCounterTable 1 }
-
-   DnsServCounterEntry ::=
-       SEQUENCE {
-           dnsServCounterOpCode
-               DnsOpCode,
-           dnsServCounterQClass
-               DnsClass,
-           dnsServCounterQType
-               DnsType,
-           dnsServCounterTransport
-               INTEGER,
-           dnsServCounterRequests
-               Counter32,
-           dnsServCounterResponses
-               Counter32
-           }
-
-   dnsServCounterOpCode OBJECT-TYPE
-       SYNTAX      DnsOpCode
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "The DNS OPCODE being counted in this row of the table."
-       ::= { dnsServCounterEntry 1 }
-
-   dnsServCounterQClass OBJECT-TYPE
-       SYNTAX      DnsClass
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "The class of record being counted in this row of the
-               table."
-       ::= { dnsServCounterEntry 2 }
-
-
-
-
-Austein & Saperia                                              [Page 13]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   dnsServCounterQType OBJECT-TYPE
-       SYNTAX      DnsType
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "The type of record which is being counted in this row in
-               the table."
-       ::= { dnsServCounterEntry 3 }
-
-   dnsServCounterTransport OBJECT-TYPE
-       SYNTAX      INTEGER { udp(1), tcp(2), other(3) }
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "A value of udp(1) indicates that the queries reported on
-               this row were sent using UDP.
-
-               A value of tcp(2) indicates that the queries reported on
-               this row were sent using TCP.
-
-               A value of other(3) indicates that the queries reported
-               on this row were sent using a transport that was neither
-               TCP nor UDP."
-       ::= { dnsServCounterEntry 4 }
-
-   dnsServCounterRequests OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests (queries) that have been recorded in
-               this row of the table."
-       ::= { dnsServCounterEntry 5 }
-
-   dnsServCounterResponses OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of responses made by the server since
-               initialization for the kind of query identified on this
-               row of the table."
-       ::= { dnsServCounterEntry 6 }
-
-
-
-
-
-
-
-
-Austein & Saperia                                              [Page 14]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   -- Server Optional Counter Group
-
-   -- The Server Optional Counter Group is intended for those systems
-   -- which make distinctions between the different sources of the DNS
-   -- queries as defined below.
-   --
-   -- Objects in this group are implemented on servers which distinguish
-   -- between queries which originate from the same host as the server,
-   -- queries from one of an arbitrary group of hosts that are on an
-   -- access list defined by the server, and queries from hosts that do
-   -- not fit either of these descriptions.
-   --
-   -- The objects found in the Server Counter group are totals.  Thus if
-   -- one wanted to identify, for example, the number of queries from
-   -- `remote' hosts which have been given authoritative answers, one
-   -- would subtract the current values of ServOptCounterFriendsAuthAns
-   -- and ServOptCounterSelfAuthAns from servCounterAuthAns.
-   --
-   -- The purpose of these distinctions is to allow for implementations
-   -- to group queries and responses on this basis.  One way in which
-   -- servers may make these distinctions is by looking at the source IP
-   -- address of the DNS query.  If the source of the query is `your
-   -- own' then the query should be counted as `yourself' (local host).
-   -- If the source of the query matches an `access list,' the query
-   -- came from a friend.  What constitutes an `access list' is
-   -- implementation dependent and could be as simple as a rule that all
-   -- hosts on the same IP network as the DNS server are classed
-   -- `friends.'
-   --
-   -- In order to avoid double counting, the following rules apply:
-   --
-   -- 1. No host is in more than one of the three groups defined above.
-   --
-   -- 2. All queries from the local host are always counted in the
-   --    `yourself' group regardless of what the access list, if any,
-   --    says.
-   --
-   -- 3. The access list should not define `your friends' in such a way
-   --    that it includes all hosts.   That is, not everybody is your
-   --    `friend.'
-
-   dnsServOptCounterSelfAuthAns OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests the server has processed which
-               originated from a resolver on the same host for which
-
-
-
-Austein & Saperia                                              [Page 15]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-               there has been an authoritative answer."
-       ::= { dnsServOptCounter 1 }
-
-   dnsServOptCounterSelfAuthNoNames OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests the server has processed which
-               originated from a resolver on the same host for which
-               there has been an authoritative no such name answer
-               given."
-       ::= { dnsServOptCounter 2 }
-
-   dnsServOptCounterSelfAuthNoDataResps OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests the server has processed which
-               originated from a resolver on the same host for which
-               there has been an authoritative no such data answer
-               (empty answer) made."
-       ::= { dnsServOptCounter 3 }
-
-   dnsServOptCounterSelfNonAuthDatas OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests the server has processed which
-               originated from a resolver on the same host for which a
-               non-authoritative answer (cached data) was made."
-       ::= { dnsServOptCounter 4 }
-
-   dnsServOptCounterSelfNonAuthNoDatas OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests the server has processed which
-               originated from a resolver on the same host for which a
-               `non-authoritative, no such data' response was made
-               (empty answer)."
-       ::= { dnsServOptCounter 5 }
-
-   dnsServOptCounterSelfReferrals OBJECT-TYPE
-       SYNTAX      Counter32
-
-
-
-Austein & Saperia                                              [Page 16]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries the server has processed which
-               originated from a resolver on the same host and were
-               referred to other servers."
-       ::= { dnsServOptCounter 6 }
-
-   dnsServOptCounterSelfErrors OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests the server has processed which
-               originated from a resolver on the same host which have
-               been answered with errors (RCODEs other than 0 and 3)."
-       REFERENCE
-               "RFC-1035 section 4.1.1."
-       ::= { dnsServOptCounter 7 }
-
-   dnsServOptCounterSelfRelNames OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests received for names that are only 1
-               label long (text form - no internal dots) the server has
-               processed which originated from a resolver on the same
-               host."
-       ::= { dnsServOptCounter 8 }
-
-   dnsServOptCounterSelfReqRefusals OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of DNS requests refused by the server which
-               originated from a resolver on the same host."
-       ::= { dnsServOptCounter 9 }
-
-   dnsServOptCounterSelfReqUnparses OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests received which were unparseable and
-               which originated from a resolver on the same host."
-       ::= { dnsServOptCounter 10 }
-
-
-
-Austein & Saperia                                              [Page 17]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   dnsServOptCounterSelfOtherErrors OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests which were aborted for other (local)
-               server errors and which originated on the same host."
-       ::= { dnsServOptCounter 11 }
-
-   dnsServOptCounterFriendsAuthAns OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries originating from friends which were
-               authoritatively answered.  The definition of friends is
-               a locally defined matter."
-       ::= { dnsServOptCounter 12 }
-
-   dnsServOptCounterFriendsAuthNoNames OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries originating from friends, for which
-               authoritative `no such name' responses were made.  The
-               definition of friends is a locally defined matter."
-       ::= { dnsServOptCounter 13 }
-
-   dnsServOptCounterFriendsAuthNoDataResps OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries originating from friends for which
-               authoritative no such data (empty answer) responses were
-               made.  The definition of friends is a locally defined
-               matter."
-       ::= { dnsServOptCounter 14 }
-
-   dnsServOptCounterFriendsNonAuthDatas OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries originating from friends which were
-               non-authoritatively answered (cached data). The
-               definition of friends is a locally defined matter."
-
-
-
-Austein & Saperia                                              [Page 18]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       ::= { dnsServOptCounter 15 }
-
-   dnsServOptCounterFriendsNonAuthNoDatas OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries originating from friends which were
-               non-authoritatively answered with no such data (empty
-               answer)."
-       ::= { dnsServOptCounter 16 }
-
-   dnsServOptCounterFriendsReferrals OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests which originated from friends that
-               were referred to other servers.  The definition of
-               friends is a locally defined matter."
-       ::= { dnsServOptCounter 17 }
-
-   dnsServOptCounterFriendsErrors OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests the server has processed which
-               originated from friends and were answered with errors
-               (RCODE values other than 0 and 3).  The definition of
-               friends is a locally defined matter."
-       REFERENCE
-               "RFC-1035 section 4.1.1."
-       ::= { dnsServOptCounter 18 }
-
-   dnsServOptCounterFriendsRelNames OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests received for names from friends that
-               are only 1 label long (text form - no internal dots) the
-               server has processed."
-       ::= { dnsServOptCounter 19 }
-
-   dnsServOptCounterFriendsReqRefusals OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-
-
-
-Austein & Saperia                                              [Page 19]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       STATUS      current
-       DESCRIPTION
-               "Number of DNS requests refused by the server which were
-               received from `friends'."
-       ::= { dnsServOptCounter 20 }
-
-   dnsServOptCounterFriendsReqUnparses OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests received which were unparseable and
-               which originated from `friends'."
-       ::= { dnsServOptCounter 21 }
-
-   dnsServOptCounterFriendsOtherErrors OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests which were aborted for other (local)
-               server errors and which originated from `friends'."
-       ::= { dnsServOptCounter 22 }
-
-
-   -- Server Zone Group
-
-   -- DNS Management Zone Configuration Table
-
-   -- This table contains zone configuration information.
-
-   dnsServZoneTable OBJECT-TYPE
-       SYNTAX      SEQUENCE OF DnsServZoneEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Table of zones for which this name server provides
-               information.  Each of the zones may be loaded from stable
-               storage via an implementation-specific mechanism or may
-               be obtained from another name server via a zone transfer.
-
-               If name server doesn't load any zones, this table is
-               empty."
-       ::= { dnsServZone 1 }
-
-   dnsServZoneEntry OBJECT-TYPE
-       SYNTAX      DnsServZoneEntry
-       MAX-ACCESS  not-accessible
-
-
-
-Austein & Saperia                                              [Page 20]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       STATUS      current
-       DESCRIPTION
-               "An entry in the name server zone table.  New rows may be
-               added either via SNMP or by the name server itself."
-       INDEX     { dnsServZoneName,
-                   dnsServZoneClass }
-       ::= { dnsServZoneTable 1 }
-
-   DnsServZoneEntry ::=
-       SEQUENCE {
-           dnsServZoneName
-               DnsNameAsIndex,
-           dnsServZoneClass
-               DnsClass,
-           dnsServZoneLastReloadSuccess
-               DnsTime,
-           dnsServZoneLastReloadAttempt
-               DnsTime,
-           dnsServZoneLastSourceAttempt
-               IpAddress,
-           dnsServZoneStatus
-               RowStatus,
-           dnsServZoneSerial
-               Counter32,
-           dnsServZoneCurrent
-               TruthValue,
-           dnsServZoneLastSourceSuccess
-               IpAddress
-       }
-
-   dnsServZoneName OBJECT-TYPE
-       SYNTAX      DnsNameAsIndex
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS name of the zone described by this row of the table.
-               This is the owner name of the SOA RR that defines the
-               top of the zone. This is name is in uppercase:
-               characters 'a' through 'z' are mapped to 'A' through 'Z'
-               in order to make the lexical ordering useful."
-       ::= { dnsServZoneEntry 1 }
-
-   dnsServZoneClass OBJECT-TYPE
-       SYNTAX      DnsClass
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS class of the RRs in this zone."
-
-
-
-Austein & Saperia                                              [Page 21]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       ::= { dnsServZoneEntry 2 }
-
-   dnsServZoneLastReloadSuccess OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Elapsed time in seconds since last successful reload of
-               this zone."
-       ::= { dnsServZoneEntry 3 }
-
-   dnsServZoneLastReloadAttempt OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Elapsed time in seconds since last attempted reload of
-               this zone."
-       ::= { dnsServZoneEntry 4 }
-
-   dnsServZoneLastSourceAttempt OBJECT-TYPE
-       SYNTAX      IpAddress
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "IP address of host from which most recent zone transfer
-               of this zone was attempted.  This value should match the
-               value of dnsServZoneSourceSuccess if the attempt was
-               succcessful.  If zone transfer has not been attempted
-               within the memory of this name server, this value should
-               be 0.0.0.0."
-       ::= { dnsServZoneEntry 5 }
-
-   dnsServZoneStatus OBJECT-TYPE
-       SYNTAX      RowStatus
-       MAX-ACCESS  read-create
-       STATUS      current
-       DESCRIPTION
-               "The status of the information represented in this row of
-               the table."
-       ::= { dnsServZoneEntry 6 }
-
-   dnsServZoneSerial OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Zone serial number (from the SOA RR) of the zone
-
-
-
-Austein & Saperia                                              [Page 22]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-               represented by this row of the table.  If the zone has
-               not been successfully loaded within the memory of this
-               name server, the value of this variable is zero."
-       ::= { dnsServZoneEntry 7 }
-
-   dnsServZoneCurrent OBJECT-TYPE
-       SYNTAX      TruthValue
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Whether the server's copy of the zone represented by
-               this row of the table is currently valid.  If the zone
-               has never been successfully loaded or has expired since
-               it was last succesfully loaded, this variable will have
-               the value false(2), otherwise this variable will have
-               the value true(1)."
-       ::= { dnsServZoneEntry 8 }
-
-   dnsServZoneLastSourceSuccess OBJECT-TYPE
-       SYNTAX      IpAddress
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "IP address of host which was the source of the most
-               recent successful zone transfer for this zone.  If
-               unknown (e.g., zone has never been successfully
-               transfered) or irrelevant (e.g., zone was loaded from
-               stable storage), this value should be 0.0.0.0."
-       ::= { dnsServZoneEntry 9 }
-
-   -- DNS Zone Source Table
-
-   dnsServZoneSrcTable OBJECT-TYPE
-       SYNTAX      SEQUENCE OF DnsServZoneSrcEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "This table is a list of IP addresses from which the
-               server will attempt to load zone information using DNS
-               zone transfer operations.  A reload may occur due to SNMP
-               operations that create a row in dnsServZoneTable or a
-               SET to object dnsServZoneReload.  This table is only
-               used when the zone is loaded via zone transfer."
-       ::= { dnsServZone 2 }
-
-   dnsServZoneSrcEntry OBJECT-TYPE
-       SYNTAX      DnsServZoneSrcEntry
-       MAX-ACCESS  not-accessible
-
-
-
-Austein & Saperia                                              [Page 23]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       STATUS      current
-       DESCRIPTION
-               "An entry in the name server zone source table."
-       INDEX     { dnsServZoneSrcName,
-                   dnsServZoneSrcClass,
-                   dnsServZoneSrcAddr }
-       ::= { dnsServZoneSrcTable 1 }
-
-   DnsServZoneSrcEntry ::=
-       SEQUENCE {
-           dnsServZoneSrcName
-               DnsNameAsIndex,
-           dnsServZoneSrcClass
-               DnsClass,
-           dnsServZoneSrcAddr
-               IpAddress,
-           dnsServZoneSrcStatus
-               RowStatus
-       }
-
-   dnsServZoneSrcName OBJECT-TYPE
-       SYNTAX      DnsNameAsIndex
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS name of the zone to which this entry applies."
-       ::= { dnsServZoneSrcEntry 1 }
-
-   dnsServZoneSrcClass OBJECT-TYPE
-       SYNTAX      DnsClass
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS class of zone to which this entry applies."
-       ::= { dnsServZoneSrcEntry 2 }
-
-   dnsServZoneSrcAddr OBJECT-TYPE
-       SYNTAX      IpAddress
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "IP address of name server host from which this zone
-               might be obtainable."
-       ::= { dnsServZoneSrcEntry 3 }
-
-   dnsServZoneSrcStatus OBJECT-TYPE
-       SYNTAX      RowStatus
-       MAX-ACCESS  read-create
-
-
-
-Austein & Saperia                                              [Page 24]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       STATUS      current
-       DESCRIPTION
-               "The status of the information represented in this row of
-               the table."
-       ::= { dnsServZoneSrcEntry 4 }
-
-
-   -- SNMPv2 groups.
-
-   dnsServMIBGroups        OBJECT IDENTIFIER ::= { dnsServMIB 2 }
-
-   dnsServConfigGroup OBJECT-GROUP
-       OBJECTS   { dnsServConfigImplementIdent,
-                   dnsServConfigRecurs,
-                   dnsServConfigUpTime,
-                   dnsServConfigResetTime,
-                   dnsServConfigReset }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing basic configuration
-               control of a DNS name server."
-       ::= { dnsServMIBGroups 1 }
-
-   dnsServCounterGroup OBJECT-GROUP
-       OBJECTS   { dnsServCounterAuthAns,
-                   dnsServCounterAuthNoNames,
-                   dnsServCounterAuthNoDataResps,
-                   dnsServCounterNonAuthDatas,
-                   dnsServCounterNonAuthNoDatas,
-                   dnsServCounterReferrals,
-                   dnsServCounterErrors,
-                   dnsServCounterRelNames,
-                   dnsServCounterReqRefusals,
-                   dnsServCounterReqUnparses,
-                   dnsServCounterOtherErrors,
-                   dnsServCounterOpCode,
-                   dnsServCounterQClass,
-                   dnsServCounterQType,
-                   dnsServCounterTransport,
-                   dnsServCounterRequests,
-                   dnsServCounterResponses }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing basic instrumentation
-               of a DNS name server."
-       ::= { dnsServMIBGroups 2 }
-
-
-
-
-
-Austein & Saperia                                              [Page 25]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   dnsServOptCounterGroup OBJECT-GROUP
-       OBJECTS   { dnsServOptCounterSelfAuthAns,
-                   dnsServOptCounterSelfAuthNoNames,
-                   dnsServOptCounterSelfAuthNoDataResps,
-                   dnsServOptCounterSelfNonAuthDatas,
-                   dnsServOptCounterSelfNonAuthNoDatas,
-                   dnsServOptCounterSelfReferrals,
-                   dnsServOptCounterSelfErrors,
-                   dnsServOptCounterSelfRelNames,
-                   dnsServOptCounterSelfReqRefusals,
-                   dnsServOptCounterSelfReqUnparses,
-                   dnsServOptCounterSelfOtherErrors,
-                   dnsServOptCounterFriendsAuthAns,
-                   dnsServOptCounterFriendsAuthNoNames,
-                   dnsServOptCounterFriendsAuthNoDataResps,
-                   dnsServOptCounterFriendsNonAuthDatas,
-                   dnsServOptCounterFriendsNonAuthNoDatas,
-                   dnsServOptCounterFriendsReferrals,
-                   dnsServOptCounterFriendsErrors,
-                   dnsServOptCounterFriendsRelNames,
-                   dnsServOptCounterFriendsReqRefusals,
-                   dnsServOptCounterFriendsReqUnparses,
-                   dnsServOptCounterFriendsOtherErrors }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing extended
-               instrumentation of a DNS name server."
-       ::= { dnsServMIBGroups 3 }
-
-   dnsServZoneGroup OBJECT-GROUP
-       OBJECTS   { dnsServZoneName,
-                   dnsServZoneClass,
-                   dnsServZoneLastReloadSuccess,
-                   dnsServZoneLastReloadAttempt,
-                   dnsServZoneLastSourceAttempt,
-                   dnsServZoneLastSourceSuccess,
-                   dnsServZoneStatus,
-                   dnsServZoneSerial,
-                   dnsServZoneCurrent,
-                   dnsServZoneSrcName,
-                   dnsServZoneSrcClass,
-                   dnsServZoneSrcAddr,
-                   dnsServZoneSrcStatus }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing configuration control
-               of a DNS name server which loads authoritative zones."
-       ::= { dnsServMIBGroups 4 }
-
-
-
-Austein & Saperia                                              [Page 26]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-   -- Compliances.
-
-   dnsServMIBCompliances OBJECT IDENTIFIER ::= { dnsServMIB 3 }
-
-   dnsServMIBCompliance MODULE-COMPLIANCE
-       STATUS      current
-       DESCRIPTION
-               "The compliance statement for agents implementing the DNS
-               name server MIB extensions."
-       MODULE -- This MIB module
-           MANDATORY-GROUPS { dnsServConfigGroup, dnsServCounterGroup }
-           GROUP   dnsServOptCounterGroup
-           DESCRIPTION
-               "The server optional counter group is unconditionally
-               optional."
-           GROUP   dnsServZoneGroup
-           DESCRIPTION
-               "The server zone group is mandatory for any name server
-               that acts as an authoritative server for any DNS zone."
-           OBJECT  dnsServConfigRecurs
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-           OBJECT  dnsServConfigReset
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-       ::= { dnsServMIBCompliances 1 }
-
-   END
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein & Saperia                                              [Page 27]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-5.  Acknowledgements
-
-   This document is the result of work undertaken the by DNS working
-   group.  The authors would particularly like to thank the following
-   people for their contributions to this document: Philip Almquist,
-   Frank Kastenholz (FTP Software), Joe Peck (DEC), Dave Perkins
-   (SynOptics), Win Treese (DEC), and Mimi Zohar (IBM).
-
-6.  References
-
-   [1] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
-       13, RFC 1034, USC/Information Sciences Institute, November 1987.
-
-   [2] Mockapetris, P., "Domain Names -- Implementation and
-       Specification", STD 13, RFC 1035, USC/Information Sciences
-       Institute, November 1987.
-
-   [3] Braden, R., Editor, "Requirements for Internet Hosts --
-       Application and Support, STD 3, RFC 1123, USC/Information
-       Sciences Institute, October 1989.
-
-   [4] Rose, M., and K. McCloghrie, "Structure and Identification of
-       Management Information for TCP/IP-based internets", STD 16, RFC
-       1155, Performance Systems International, Hughes LAN Systems, May
-       1990.
-
-   [5] McCloghrie, K., and M. Rose, "Management Information Base for
-       Network Management of TCP/IP-based internets", RFC 1156, Hughes
-       LAN Systems, Performance Systems International, May 1990.
-
-   [6] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
-       Network Management Protocol", STD 15, RFC 1157, SNMP Research,
-       Performance Systems International, Performance Systems
-       International, MIT Laboratory for Computer Science, May 1990.
-
-   [7] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
-       STD 16, RFC 1212, Performance Systems International, Hughes LAN
-       Systems, March 1991.
-
-   [8] McCloghrie, K., and M. Rose, Editors, "Management Information
-       Base for Network Management of TCP/IP-based internets: MIB-II",
-       STD 17, RFC 1213, Hughes LAN Systems, Performance Systems
-       International, March 1991.
-
-   [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure
-       of Management Information for version 2 of the Simple Network
-       Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc.,
-       Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
-
-
-
-Austein & Saperia                                              [Page 28]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-       University, April 1993.
-
-  [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual
-       Conventions for version 2 of the the Simple Network Management
-       Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN
-       Systems, Dover Beach Consulting, Inc., Carnegie Mellon
-       University, April 1993.
-
-  [11] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
-       "Conformance Statements for version 2 of the the Simple Network
-       Management Protocol (SNMPv2)", RFC 1444, SNMP Research, Inc.,
-       Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
-       University, April 1993.
-
-  [12] Galvin, J., and K. McCloghrie, "Administrative Model for version
-       2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445,
-       Trusted Information Systems, Hughes LAN Systems, April 1993.
-
-  [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
-       Operations for version 2 of the Simple Network Management
-       Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN
-       Systems, Dover Beach Consulting, Inc., Carnegie Mellon
-       University, April 1993.
-
-  [14] "Information processing systems - Open Systems Interconnection -
-       Specification of Abstract Syntax Notation One (ASN.1)",
-       International Organization for Standardization, International
-       Standard 8824, December 1987.
-
-7.  Security Considerations
-
-   Security issues are not discussed in this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein & Saperia                                              [Page 29]
-
-RFC 1611               DNS Server MIB Extensions                May 1994
-
-
-8.  Authors' Addresses
-
-   Rob Austein
-   Epilogue Technology Corporation
-   268 Main Street, Suite 283
-   North Reading, MA 01864
-   USA
-
-   Phone: +1-617-245-0804
-   Fax:   +1-617-245-8122
-   EMail: sra@epilogue.com
-
-
-   Jon Saperia
-   Digital Equipment Corporation
-   110 Spit Brook Road
-   ZKO1-3/H18
-   Nashua, NH 03062-2698
-   USA
-
-   Phone: +1-603-881-0480
-   Fax:   +1-603-881-0120
-   EMail: saperia@zko.dec.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein & Saperia                                              [Page 30]
-
diff --git a/contrib/bind9/doc/rfc/rfc1612.txt b/contrib/bind9/doc/rfc/rfc1612.txt
deleted file mode 100644
index 4ef23b0..0000000
--- a/contrib/bind9/doc/rfc/rfc1612.txt
+++ /dev/null
@@ -1,1795 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         R. Austein
-Request for Comments: 1612               Epilogue Technology Corporation
-Category: Standards Track                                     J. Saperia
-                                           Digital Equipment Corporation
-                                                                May 1994
-
-
-                      DNS Resolver MIB Extensions
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Table of Contents
-
-   1. Introduction ..............................................    1
-   2. The SNMPv2 Network Management Framework ...................    2
-   2.1 Object Definitions .......................................    2
-   3. Overview ..................................................    2
-   3.1 Resolvers ................................................    3
-   3.2 Name Servers .............................................    3
-   3.3 Selected Objects .........................................    4
-   3.4 Textual Conventions ......................................    4
-   4. Definitions ...............................................    5
-   5. Acknowledgements ..........................................   30
-   6. References ................................................   30
-   7. Security Considerations ...................................   32
-   8. Authors' Addresses ........................................   32
-
-1.  Introduction
-
-   This memo defines a portion of the Management Information Base (MIB)
-   for use with network management protocols in the Internet community.
-   In particular, it describes a set of extensions which instrument DNS
-   resolver functions.  This memo was produced by the DNS working group.
-
-   With the adoption of the Internet-standard Network Management
-   Framework [4,5,6,7], and with a large number of vendor
-   implementations of these standards in commercially available
-   products, it became possible to provide a higher level of effective
-   network management in TCP/IP-based internets than was previously
-   available.  With the growth in the use of these standards, it has
-   become possible to consider the management of other elements of the
-   infrastructure beyond the basic TCP/IP protocols.  A key element of
-
-
-
-Austein & Saperia                                               [Page 1]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   the TCP/IP infrastructure is the DNS.
-
-   Up to this point there has been no mechanism to integrate the
-   management of the DNS with SNMP-based managers.  This memo provides
-   the mechanisms by which IP-based management stations can effectively
-   manage DNS resolver software in an integrated fashion.
-
-   We have defined DNS MIB objects to be used in conjunction with the
-   Internet MIB to allow access to and control of DNS resolver software
-   via SNMP by the Internet community.
-
-2.  The SNMPv2 Network Management Framework
-
-   The SNMPv2 Network Management Framework consists of four major
-   components.  They are:
-
-      o  RFC 1442 which defines the SMI, the mechanisms used for
-         describing and naming objects for the purpose of management.
-
-      o  STD 17, RFC 1213 defines MIB-II, the core set of managed
-         objects for the Internet suite of protocols.
-
-      o  RFC 1445 which defines the administrative and other
-         architectural aspects of the framework.
-
-      o  RFC 1448 which defines the protocol used for network access to
-         managed objects.
-
-   The Framework permits new objects to be defined for the purpose of
-   experimentation and evaluation.
-
-2.1.  Object Definitions
-
-   Managed objects are accessed via a virtual information store, termed
-   the Management Information Base or MIB.  Objects in the MIB are
-   defined using the subset of Abstract Syntax Notation One (ASN.1)
-   defined in the SMI.  In particular, each object object type is named
-   by an OBJECT IDENTIFIER, an administratively assigned name.  The
-   object type together with an object instance serves to uniquely
-   identify a specific instantiation of the object.  For human
-   convenience, we often use a textual string, termed the descriptor, to
-   refer to the object type.
-
-3.  Overview
-
-   In theory, the DNS world is pretty simple.  There are two kinds of
-   entities: resolvers and name servers.  Resolvers ask questions.  Name
-   servers answer them.  The real world, however, is not so simple.
-
-
-
-Austein & Saperia                                               [Page 2]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   Implementors have made widely differing choices about how to divide
-   DNS functions between resolvers and servers.  They have also
-   constructed various sorts of exotic hybrids.  The most difficult task
-   in defining this MIB was to accommodate this wide range of entities
-   without having to come up with a separate MIB for each.
-
-   We divided up the various DNS functions into two, non-overlapping
-   classes, called "resolver functions" and "name server functions."  A
-   DNS entity that performs what we define as resolver functions
-   contains a resolver, and therefore must implement the MIB groups
-   required of all resolvers which are defined in this module.  Some
-   resolvers also implement "optional" functions such as a cache, in
-   which case they must also implement the cache group contained in this
-   MIB.  A DNS entity which implements name server functions is
-   considered to be a name server, and must implement the MIB groups
-   required for name servers which are defined in a separate module.  If
-   the same piece of software performs both resolver and server
-   functions, we imagine that it contains both a resolver and a server
-   and would thus implement both the DNS Server and DNS Resolver MIBs.
-
-3.1.  Resolvers
-
-   In our model, a resolver is a program (or piece thereof) which
-   obtains resource records from servers.  Normally it does so at the
-   behest of an application, but may also do so as part of its own
-   operation.  A resolver sends DNS protocol queries and receives DNS
-   protocol replies.  A resolver neither receives queries nor sends
-   replies.  A full service resolver is one that knows how to resolve
-   queries: it obtains the needed resource records by contacting a
-   server authoritative for the records desired.  A stub resolver does
-   not know how to resolve queries: it sends all queries to a local name
-   server, setting the "recursion desired" flag to indicate that it
-   hopes that the name server will be willing to resolve the query.  A
-   resolver may (optionally) have a cache for remembering previously
-   acquired resource records.  It may also have a negative cache for
-   remembering names or data that have been determined not to exist.
-
-3.2.  Name Servers
-
-   A name server is a program (or piece thereof) that provides resource
-   records to resolvers.  All references in this document to "a name
-   server" imply "the name server's role"; in some cases the name
-   server's role and the resolver's role might be combined into a single
-   program.  A name server receives DNS protocol queries and sends DNS
-   protocol replies.  A name server neither sends queries nor receives
-   replies.  As a consequence, name servers do not have caches.
-   Normally, a name server would expect to receive only those queries to
-   which it could respond with authoritative information.  However, if a
-
-
-
-Austein & Saperia                                               [Page 3]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   name server receives a query that it cannot respond to with purely
-   authoritative information, it may choose to try to obtain the
-   necessary additional information from a resolver which may or may not
-   be a separate process.
-
-3.3.  Selected Objects
-
-   Many of the objects included in this memo have been created from
-   information contained in the DNS specifications [1,2], as amended and
-   clarified by subsequent host requirements documents [3].  Other
-   objects have been created based on experience with existing DNS
-   management tools, expected operational needs, the statistics
-   generated by existing DNS implementations, and the configuration
-   files used by existing DNS implementations.  These objects have been
-   ordered into groups as follows:
-
-         o  Resolver Configuration Group
-
-         o  Resolver Counter Group
-
-         o  Resolver Lame Delegation Group
-
-         o  Resolver Cache Group
-
-         o  Resolver Negative Cache Group
-
-         o  Resolver Optional Counter Group
-
-   This information has been converted into a standard form using the
-   SNMPv2 SMI defined in [9].  For the most part, the descriptions are
-   influenced by the DNS related RFCs noted above.  For example, the
-   descriptions for counters used for the various types of queries of
-   DNS records are influenced by the definitions used for the various
-   record types found in [2].
-
-3.4.  Textual Conventions
-
-   Several conceptual data types have been introduced as a textual
-   conventions in the DNS Server MIB document and have been imported
-   into this MIB module.  These additions will facilitate the common
-   understanding of information used by the DNS.  No changes to the SMI
-   or the SNMP are necessary to support these conventions.
-
-   Readers familiar with MIBs designed to manage entities in the lower
-   layers of the Internet protocol suite may be surprised at the number
-   of non-enumerated integers used in this MIB to represent values such
-   as DNS RR class and type numbers.  The reason for this choice is
-   simple: the DNS itself is designed as an extensible protocol,
-
-
-
-Austein & Saperia                                               [Page 4]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   allowing new classes and types of resource records to be added to the
-   protocol without recoding the core DNS software.  Using non-
-   enumerated integers to represent these data types in this MIB allows
-   the MIB to accommodate these changes as well.
-
-4.  Definitions
-
-   DNS-RESOLVER-MIB DEFINITIONS ::= BEGIN
-
-   IMPORTS
-       MODULE-IDENTITY, OBJECT-TYPE, IpAddress, Counter32, Integer32
-           FROM SNMPv2-SMI
-       TEXTUAL-CONVENTION, RowStatus, DisplayString
-           FROM SNMPv2-TC
-       MODULE-COMPLIANCE, OBJECT-GROUP
-           FROM SNMPv2-CONF
-       dns, DnsName, DnsNameAsIndex, DnsClass, DnsType, DnsQClass,
-       DnsQType, DnsTime, DnsOpCode, DnsRespCode
-           FROM DNS-SERVER-MIB;
-
-   -- DNS Resolver MIB
-
-   dnsResMIB MODULE-IDENTITY
-       LAST-UPDATED "9401282250Z"
-       ORGANIZATION "IETF DNS Working Group"
-       CONTACT-INFO
-               "       Rob Austein
-               Postal: Epilogue Technology Corporation
-                       268 Main Street, Suite 283
-                       North Reading, MA 10864
-                       US
-                  Tel: +1 617 245 0804
-                  Fax: +1 617 245 8122
-               E-Mail: sra@epilogue.com
-
-                       Jon Saperia
-               Postal: Digital Equipment Corporation
-                       110 Spit Brook Road
-                       ZKO1-3/H18
-                       Nashua, NH 03062-2698
-                       US
-                  Tel: +1 603 881 0480
-                  Fax: +1 603 881 0120
-               E-mail: saperia@zko.dec.com"
-       DESCRIPTION
-               "The MIB module for entities implementing the client
-               (resolver) side of the Domain Name System (DNS)
-               protocol."
-
-
-
-Austein & Saperia                                               [Page 5]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-       ::= { dns 2 }
-
-   dnsResMIBObjects        OBJECT IDENTIFIER ::= { dnsResMIB 1 }
-
-   -- (Old-style) groups in the DNS resolver MIB.
-
-   dnsResConfig            OBJECT IDENTIFIER ::= { dnsResMIBObjects 1 }
-   dnsResCounter           OBJECT IDENTIFIER ::= { dnsResMIBObjects 2 }
-   dnsResLameDelegation    OBJECT IDENTIFIER ::= { dnsResMIBObjects 3 }
-   dnsResCache             OBJECT IDENTIFIER ::= { dnsResMIBObjects 4 }
-   dnsResNCache            OBJECT IDENTIFIER ::= { dnsResMIBObjects 5 }
-   dnsResOptCounter        OBJECT IDENTIFIER ::= { dnsResMIBObjects 6 }
-
-
-   -- Resolver Configuration Group
-
-   dnsResConfigImplementIdent OBJECT-TYPE
-       SYNTAX      DisplayString
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "The implementation identification string for the
-               resolver software in use on the system, for example;
-               `RES-2.1'"
-       ::= { dnsResConfig 1 }
-
-   dnsResConfigService OBJECT-TYPE
-       SYNTAX      INTEGER { recursiveOnly(1),
-                             iterativeOnly(2),
-                             recursiveAndIterative(3) }
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Kind of DNS resolution service provided:
-
-               recursiveOnly(1) indicates a stub resolver.
-
-               iterativeOnly(2) indicates a normal full service
-               resolver.
-
-               recursiveAndIterative(3) indicates a full-service
-               resolver which performs a mix of recursive and iterative
-               queries."
-        ::= { dnsResConfig 2 }
-
-   dnsResConfigMaxCnames OBJECT-TYPE
-       SYNTAX      INTEGER (0..2147483647)
-       MAX-ACCESS  read-write
-
-
-
-Austein & Saperia                                               [Page 6]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-       STATUS      current
-       DESCRIPTION
-               "Limit on how many CNAMEs the resolver should allow
-               before deciding that there's a CNAME loop.  Zero means
-               that resolver has no explicit CNAME limit."
-       REFERENCE
-               "RFC-1035 section 7.1."
-       ::= { dnsResConfig 3 }
-
-   -- DNS Resolver Safety Belt Table
-
-   dnsResConfigSbeltTable OBJECT-TYPE
-       SYNTAX      SEQUENCE OF DnsResConfigSbeltEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Table of safety belt information used by the resolver
-               when it hasn't got any better idea of where to send a
-               query, such as when the resolver is booting or is a stub
-               resolver."
-       ::= { dnsResConfig 4 }
-
-   dnsResConfigSbeltEntry OBJECT-TYPE
-       SYNTAX      DnsResConfigSbeltEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "An entry in the resolver's Sbelt table.
-               Rows may be created or deleted at any time by the DNS
-               resolver and by SNMP SET requests.  Whether the values
-               changed via SNMP are saved in stable storage across
-               `reset' operations is implementation-specific."
-       INDEX     { dnsResConfigSbeltAddr,
-                   dnsResConfigSbeltSubTree,
-                   dnsResConfigSbeltClass }
-       ::= { dnsResConfigSbeltTable 1 }
-
-   DnsResConfigSbeltEntry ::=
-       SEQUENCE {
-           dnsResConfigSbeltAddr
-               IpAddress,
-           dnsResConfigSbeltName
-               DnsName,
-           dnsResConfigSbeltRecursion
-               INTEGER,
-           dnsResConfigSbeltPref
-               INTEGER,
-           dnsResConfigSbeltSubTree
-
-
-
-Austein & Saperia                                               [Page 7]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-               DnsNameAsIndex,
-           dnsResConfigSbeltClass
-               DnsClass,
-           dnsResConfigSbeltStatus
-               RowStatus
-       }
-
-   dnsResConfigSbeltAddr OBJECT-TYPE
-       SYNTAX      IpAddress
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "The IP address of the Sbelt name server identified by
-               this row of the table."
-       ::= { dnsResConfigSbeltEntry 1 }
-
-   dnsResConfigSbeltName OBJECT-TYPE
-       SYNTAX      DnsName
-       MAX-ACCESS  read-create
-       STATUS      current
-       DESCRIPTION
-               "The DNS name of a Sbelt nameserver identified by this
-               row of the table.  A zero-length string indicates that
-               the name is not known by the resolver."
-       ::= { dnsResConfigSbeltEntry 2 }
-
-   dnsResConfigSbeltRecursion OBJECT-TYPE
-       SYNTAX      INTEGER { iterative(1),
-                             recursive(2),
-                             recursiveAndIterative(3) }
-       MAX-ACCESS  read-create
-       STATUS      current
-       DESCRIPTION
-               "Kind of queries resolver will be sending to the name
-               server identified in this row of the table:
-
-               iterative(1) indicates that resolver will be directing
-               iterative queries to this name server (RD bit turned
-               off).
-
-               recursive(2) indicates that resolver will be directing
-               recursive queries to this name server (RD bit turned
-               on).
-
-               recursiveAndIterative(3) indicates that the resolver
-               will be directing both recursive and iterative queries
-               to the server identified in this row of the table."
-        ::= { dnsResConfigSbeltEntry 3 }
-
-
-
-Austein & Saperia                                               [Page 8]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   dnsResConfigSbeltPref OBJECT-TYPE
-       SYNTAX      INTEGER (0..2147483647)
-       MAX-ACCESS  read-create
-       STATUS      current
-       DESCRIPTION
-               "This value identifies the preference for the name server
-               identified in this row of the table.  The lower the
-               value, the more desirable the resolver considers this
-               server."
-        ::= { dnsResConfigSbeltEntry 4 }
-
-   dnsResConfigSbeltSubTree OBJECT-TYPE
-       SYNTAX      DnsNameAsIndex
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Queries sent to the name server identified by this row
-               of the table are limited to those for names in the name
-               subtree identified by this variable.  If no such
-               limitation applies, the value of this variable is the
-               name of the root domain (a DNS name consisting of a
-               single zero octet)."
-       ::= { dnsResConfigSbeltEntry 5 }
-
-   dnsResConfigSbeltClass OBJECT-TYPE
-       SYNTAX      DnsClass
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "The class of DNS queries that will be sent to the server
-               identified by this row of the table."
-       ::= { dnsResConfigSbeltEntry 6 }
-
-   dnsResConfigSbeltStatus OBJECT-TYPE
-       SYNTAX      RowStatus
-       MAX-ACCESS  read-create
-       STATUS      current
-       DESCRIPTION
-               "Row status column for this row of the Sbelt table."
-       ::= { dnsResConfigSbeltEntry 7 }
-
-   dnsResConfigUpTime OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "If the resolver has a persistent state (e.g., a
-               process), this value will be the time elapsed since it
-
-
-
-Austein & Saperia                                               [Page 9]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-               started.  For software without persistant state, this
-               value will be 0."
-       ::= { dnsResConfig 5 }
-
-   dnsResConfigResetTime OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "If the resolver has a persistent state (e.g., a process)
-               and supports a `reset' operation (e.g., can be told to
-               re-read configuration files), this value will be the
-               time elapsed since the last time the resolver was
-               `reset.'  For software that does not have persistence or
-               does not support a `reset' operation, this value will be
-               zero."
-       ::= { dnsResConfig 6 }
-
-   dnsResConfigReset OBJECT-TYPE
-       SYNTAX      INTEGER { other(1),
-                             reset(2),
-                             initializing(3),
-                             running(4) }
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-               "Status/action object to reinitialize any persistant
-               resolver state.  When set to reset(2), any persistant
-               resolver state (such as a process) is reinitialized as if
-               the resolver had just been started.  This value will
-               never be returned by a read operation.  When read, one of
-               the following values will be returned:
-                   other(1) - resolver in some unknown state;
-                   initializing(3) - resolver (re)initializing;
-                   running(4) - resolver currently running."
-       ::= { dnsResConfig 7 }
-
-
-   -- Resolver Counters Group
-
-   -- Resolver Counter Table
-
-   dnsResCounterByOpcodeTable OBJECT-TYPE
-       SYNTAX      SEQUENCE OF DnsResCounterByOpcodeEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Table of the current count of resolver queries and
-
-
-
-Austein & Saperia                                              [Page 10]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-               answers."
-       ::= { dnsResCounter 3 }
-
-   dnsResCounterByOpcodeEntry OBJECT-TYPE
-       SYNTAX      DnsResCounterByOpcodeEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Entry in the resolver counter table.  Entries are
-               indexed by DNS OpCode."
-       INDEX     { dnsResCounterByOpcodeCode }
-       ::= { dnsResCounterByOpcodeTable 1 }
-
-   DnsResCounterByOpcodeEntry ::=
-       SEQUENCE {
-           dnsResCounterByOpcodeCode
-               DnsOpCode,
-           dnsResCounterByOpcodeQueries
-               Counter32,
-           dnsResCounterByOpcodeResponses
-               Counter32
-       }
-
-   dnsResCounterByOpcodeCode OBJECT-TYPE
-       SYNTAX      DnsOpCode
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "The index to this table.  The OpCodes that have already
-               been defined are found in RFC-1035."
-       REFERENCE
-               "RFC-1035 section 4.1.1."
-       ::= { dnsResCounterByOpcodeEntry 1 }
-
-   dnsResCounterByOpcodeQueries OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Total number of queries that have sent out by the
-               resolver since initialization for the OpCode which is
-               the index to this row of the table."
-       ::= { dnsResCounterByOpcodeEntry 2 }
-
-   dnsResCounterByOpcodeResponses OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-
-
-
-Austein & Saperia                                              [Page 11]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-       DESCRIPTION
-               "Total number of responses that have been received by the
-               resolver since initialization for the OpCode which is
-               the index to this row of the table."
-       ::= { dnsResCounterByOpcodeEntry 3 }
-
-   -- Resolver Response Code Counter Table
-
-   dnsResCounterByRcodeTable OBJECT-TYPE
-       SYNTAX      SEQUENCE OF DnsResCounterByRcodeEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Table of the current count of responses to resolver
-               queries."
-       ::= { dnsResCounter 4 }
-
-   dnsResCounterByRcodeEntry OBJECT-TYPE
-       SYNTAX      DnsResCounterByRcodeEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Entry in the resolver response table.  Entries are
-               indexed by DNS response code."
-       INDEX     { dnsResCounterByRcodeCode }
-       ::= { dnsResCounterByRcodeTable 1 }
-
-   DnsResCounterByRcodeEntry ::=
-       SEQUENCE {
-           dnsResCounterByRcodeCode
-               DnsRespCode,
-           dnsResCounterByRcodeResponses
-               Counter32
-       }
-
-   dnsResCounterByRcodeCode OBJECT-TYPE
-       SYNTAX      DnsRespCode
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "The index to this table.  The Response Codes that have
-               already been defined are found in RFC-1035."
-       REFERENCE
-               "RFC-1035 section 4.1.1."
-       ::= { dnsResCounterByRcodeEntry 1 }
-
-
-
-
-
-
-Austein & Saperia                                              [Page 12]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   dnsResCounterByRcodeResponses OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of responses the resolver has received for the
-               response code value which identifies this row of the
-               table."
-       ::= { dnsResCounterByRcodeEntry 2 }
-
-   -- Additional DNS Resolver Counter Objects
-
-   dnsResCounterNonAuthDataResps OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests made by the resolver for which a
-               non-authoritative answer (cached data) was received."
-       ::= { dnsResCounter 5 }
-
-   dnsResCounterNonAuthNoDataResps OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests made by the resolver for which a
-               non-authoritative answer - no such data response (empty
-               answer) was received."
-       ::= { dnsResCounter 6 }
-
-   dnsResCounterMartians OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of responses received which were received from
-               servers that the resolver does not think it asked."
-       ::= { dnsResCounter 7 }
-
-   dnsResCounterRecdResponses OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of responses received to all queries."
-       ::= { dnsResCounter 8 }
-
-
-
-
-Austein & Saperia                                              [Page 13]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   dnsResCounterUnparseResps OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of responses received which were unparseable."
-       ::= { dnsResCounter 9 }
-
-   dnsResCounterFallbacks OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of times the resolver had to fall back to its
-               seat belt information."
-       ::= { dnsResCounter 10 }
-
-
-   -- Lame Delegation Group
-
-   dnsResLameDelegationOverflows OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of times the resolver attempted to add an entry
-               to the Lame Delegation table but was unable to for some
-               reason such as space constraints."
-       ::= { dnsResLameDelegation 1 }
-
-   -- Lame Delegation Table
-
-   dnsResLameDelegationTable OBJECT-TYPE
-       SYNTAX      SEQUENCE OF DnsResLameDelegationEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Table of name servers returning lame delegations.
-
-               A lame delegation has occured when a parent zone
-               delegates authority for a child zone to a server that
-               appears not to think that it is authoritative for the
-               child zone in question."
-       ::= { dnsResLameDelegation 2 }
-
-   dnsResLameDelegationEntry OBJECT-TYPE
-       SYNTAX      DnsResLameDelegationEntry
-       MAX-ACCESS  not-accessible
-
-
-
-Austein & Saperia                                              [Page 14]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-       STATUS      current
-       DESCRIPTION
-               "Entry in lame delegation table.  Only the resolver may
-               create rows in this table.  SNMP SET requests may be used
-               to delete rows."
-       INDEX     { dnsResLameDelegationSource,
-                   dnsResLameDelegationName,
-                   dnsResLameDelegationClass }
-       ::= { dnsResLameDelegationTable 1 }
-
-   DnsResLameDelegationEntry ::=
-       SEQUENCE {
-           dnsResLameDelegationSource
-               IpAddress,
-           dnsResLameDelegationName
-               DnsNameAsIndex,
-           dnsResLameDelegationClass
-               DnsClass,
-           dnsResLameDelegationCounts
-               Counter32,
-           dnsResLameDelegationStatus
-               RowStatus
-       }
-
-   dnsResLameDelegationSource OBJECT-TYPE
-       SYNTAX      IpAddress
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Source of lame delegation."
-       ::= { dnsResLameDelegationEntry 1 }
-
-   dnsResLameDelegationName OBJECT-TYPE
-       SYNTAX      DnsNameAsIndex
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS name for which lame delegation was received."
-       ::= { dnsResLameDelegationEntry 2 }
-
-   dnsResLameDelegationClass OBJECT-TYPE
-       SYNTAX      DnsClass
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS class of received lame delegation."
-       ::= { dnsResLameDelegationEntry 3 }
-
-
-
-
-Austein & Saperia                                              [Page 15]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   dnsResLameDelegationCounts OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "How many times this lame delegation has been received."
-       ::= { dnsResLameDelegationEntry 4 }
-
-   dnsResLameDelegationStatus OBJECT-TYPE
-       SYNTAX      RowStatus
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-               "Status column for the lame delegation table.  Since only
-               the agent (DNS resolver) creates rows in this table, the
-               only values that a manager may write to this variable
-               are active(1) and destroy(6)."
-       ::= { dnsResLameDelegationEntry 5 }
-
-
-   -- Resolver Cache Group
-
-   dnsResCacheStatus OBJECT-TYPE
-       SYNTAX      INTEGER { enabled(1), disabled(2), clear(3) }
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-               "Status/action for the resolver's cache.
-
-               enabled(1) means that the use of the cache is allowed.
-               Query operations can return this state.
-
-               disabled(2) means that the cache is not being used.
-               Query operations can return this state.
-
-               Setting this variable to clear(3) deletes the entire
-               contents of the resolver's cache, but does not otherwise
-               change the resolver's state.  The status will retain its
-               previous value from before the clear operation (i.e.,
-               enabled(1) or disabled(2)).  The value of clear(3) can
-               NOT be returned by a query operation."
-       ::= { dnsResCache 1 }
-
-   dnsResCacheMaxTTL OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-
-
-
-Austein & Saperia                                              [Page 16]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-               "Maximum Time-To-Live for RRs in this cache.  If the
-               resolver does not implement a TTL ceiling, the value of
-               this field should be zero."
-       ::= { dnsResCache 2 }
-
-   dnsResCacheGoodCaches OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of RRs the resolver has cached successfully."
-       ::= { dnsResCache 3 }
-
-   dnsResCacheBadCaches OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of RRs the resolver has refused to cache because
-               they appear to be dangerous or irrelevant.  E.g., RRs
-               with suspiciously high TTLs, unsolicited root
-               information, or that just don't appear to be relevant to
-               the question the resolver asked."
-       ::= { dnsResCache 4 }
-
-   -- Resolver Cache Table
-
-   dnsResCacheRRTable OBJECT-TYPE
-       SYNTAX      SEQUENCE OF DnsResCacheRREntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "This table contains information about all the resource
-               records currently in the resolver's cache."
-       ::= { dnsResCache 5 }
-
-   dnsResCacheRREntry OBJECT-TYPE
-       SYNTAX      DnsResCacheRREntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "An entry in the resolvers's cache.  Rows may be created
-               only by the resolver.  SNMP SET requests may be used to
-               delete rows."
-       INDEX     { dnsResCacheRRName,
-                   dnsResCacheRRClass,
-                   dnsResCacheRRType,
-                   dnsResCacheRRIndex }
-
-
-
-Austein & Saperia                                              [Page 17]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-       ::= { dnsResCacheRRTable 1 }
-
-   DnsResCacheRREntry ::=
-       SEQUENCE {
-           dnsResCacheRRName
-               DnsNameAsIndex,
-           dnsResCacheRRClass
-               DnsClass,
-           dnsResCacheRRType
-               DnsType,
-           dnsResCacheRRTTL
-               DnsTime,
-           dnsResCacheRRElapsedTTL
-               DnsTime,
-           dnsResCacheRRSource
-               IpAddress,
-           dnsResCacheRRData
-               OCTET STRING,
-           dnsResCacheRRStatus
-               RowStatus,
-           dnsResCacheRRIndex
-               Integer32,
-           dnsResCacheRRPrettyName
-               DnsName
-       }
-
-   dnsResCacheRRName OBJECT-TYPE
-       SYNTAX      DnsNameAsIndex
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "Owner name of the Resource Record in the cache which is
-               identified in this row of the table.  As described in
-               RFC-1034, the owner of the record is the domain name
-               were the RR is found."
-       REFERENCE
-               "RFC-1034 section 3.6."
-       ::= { dnsResCacheRREntry 1 }
-
-   dnsResCacheRRClass OBJECT-TYPE
-       SYNTAX      DnsClass
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS class of the Resource Record in the cache which is
-               identified in this row of the table."
-       ::= { dnsResCacheRREntry 2 }
-
-
-
-
-Austein & Saperia                                              [Page 18]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   dnsResCacheRRType OBJECT-TYPE
-       SYNTAX      DnsType
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS type of the Resource Record in the cache which is
-               identified in this row of the table."
-       ::= { dnsResCacheRREntry 3 }
-
-   dnsResCacheRRTTL OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Time-To-Live of RR in DNS cache.  This is the initial
-               TTL value which was received with the RR when it was
-               originally received."
-       ::= { dnsResCacheRREntry 4 }
-
-   dnsResCacheRRElapsedTTL OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Elapsed seconds since RR was received."
-       ::= { dnsResCacheRREntry 5 }
-
-   dnsResCacheRRSource OBJECT-TYPE
-       SYNTAX      IpAddress
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Host from which RR was received, 0.0.0.0 if unknown."
-       ::= { dnsResCacheRREntry 6 }
-
-   dnsResCacheRRData OBJECT-TYPE
-       SYNTAX      OCTET STRING
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "RDATA portion of a cached RR.  The value is in the
-               format defined for the particular DNS class and type of
-               the resource record."
-       REFERENCE
-               "RFC-1035 section 3.2.1."
-       ::= { dnsResCacheRREntry 7 }
-
-
-
-
-
-Austein & Saperia                                              [Page 19]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   dnsResCacheRRStatus OBJECT-TYPE
-       SYNTAX      RowStatus
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-               "Status column for the resolver cache table.  Since only
-               the agent (DNS resolver) creates rows in this table, the
-               only values that a manager may write to this variable
-               are active(1) and destroy(6)."
-       ::= { dnsResCacheRREntry 8 }
-
-   dnsResCacheRRIndex OBJECT-TYPE
-       SYNTAX      Integer32
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "A value which makes entries in the table unique when the
-               other index values (dnsResCacheRRName,
-               dnsResCacheRRClass, and dnsResCacheRRType) do not
-               provide a unique index."
-       ::= { dnsResCacheRREntry 9 }
-
-   dnsResCacheRRPrettyName OBJECT-TYPE
-       SYNTAX      DnsName
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Name of the RR at this row in the table.  This is
-               identical to the dnsResCacheRRName variable, except that
-               character case is preserved in this variable, per DNS
-               conventions."
-       REFERENCE
-               "RFC-1035 section 2.3.3."
-       ::= { dnsResCacheRREntry 10 }
-
-   -- Resolver Negative Cache Group
-
-   dnsResNCacheStatus OBJECT-TYPE
-       SYNTAX      INTEGER { enabled(1), disabled(2), clear(3) }
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-               "Status/action for the resolver's negative response
-               cache.
-
-               enabled(1) means that the use of the negative response
-               cache is allowed.  Query operations can return this
-               state.
-
-
-
-Austein & Saperia                                              [Page 20]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-               disabled(2) means that the negative response cache is
-               not being used.  Query operations can return this state.
-
-               Setting this variable to clear(3) deletes the entire
-               contents of the resolver's negative response cache.  The
-               status will retain its previous value from before the
-               clear operation (i.e., enabled(1) or disabled(2)).  The
-               value of clear(3) can NOT be returned by a query
-               operation."
-       ::= { dnsResNCache 1 }
-
-   dnsResNCacheMaxTTL OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-               "Maximum Time-To-Live for cached authoritative errors.
-               If the resolver does not implement a TTL ceiling, the
-               value of this field should be zero."
-       ::= { dnsResNCache 2 }
-
-   dnsResNCacheGoodNCaches OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of authoritative errors the resolver has cached
-               successfully."
-       ::= { dnsResNCache 3 }
-
-   dnsResNCacheBadNCaches OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of authoritative errors the resolver would have
-               liked to cache but was unable to because the appropriate
-               SOA RR was not supplied or looked suspicious."
-       REFERENCE
-               "RFC-1034 section 4.3.4."
-       ::= { dnsResNCache 4 }
-
-   -- Resolver Negative Cache Table
-
-   dnsResNCacheErrTable OBJECT-TYPE
-       SYNTAX      SEQUENCE OF DnsResNCacheErrEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-
-
-
-Austein & Saperia                                              [Page 21]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-       DESCRIPTION
-               "The resolver's negative response cache.  This table
-               contains information about authoritative errors that
-               have been cached by the resolver."
-       ::= { dnsResNCache 5 }
-
-   dnsResNCacheErrEntry OBJECT-TYPE
-       SYNTAX      DnsResNCacheErrEntry
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "An entry in the resolver's negative response cache
-               table.  Only the resolver can create rows.  SNMP SET
-               requests may be used to delete rows."
-       INDEX     { dnsResNCacheErrQName,
-                   dnsResNCacheErrQClass,
-                   dnsResNCacheErrQType,
-                   dnsResNCacheErrIndex }
-       ::= { dnsResNCacheErrTable 1 }
-
-   DnsResNCacheErrEntry ::=
-       SEQUENCE {
-           dnsResNCacheErrQName
-               DnsNameAsIndex,
-           dnsResNCacheErrQClass
-               DnsQClass,
-           dnsResNCacheErrQType
-               DnsQType,
-           dnsResNCacheErrTTL
-               DnsTime,
-           dnsResNCacheErrElapsedTTL
-               DnsTime,
-           dnsResNCacheErrSource
-               IpAddress,
-           dnsResNCacheErrCode
-               INTEGER,
-           dnsResNCacheErrStatus
-               RowStatus,
-           dnsResNCacheErrIndex
-               Integer32,
-           dnsResNCacheErrPrettyName
-               DnsName
-       }
-
-   dnsResNCacheErrQName OBJECT-TYPE
-       SYNTAX      DnsNameAsIndex
-       MAX-ACCESS  not-accessible
-       STATUS      current
-
-
-
-Austein & Saperia                                              [Page 22]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-       DESCRIPTION
-               "QNAME associated with a cached authoritative error."
-       REFERENCE
-               "RFC-1034 section 3.7.1."
-       ::= { dnsResNCacheErrEntry 1 }
-
-   dnsResNCacheErrQClass OBJECT-TYPE
-       SYNTAX      DnsQClass
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS QCLASS associated with a cached authoritative
-               error."
-       ::= { dnsResNCacheErrEntry 2 }
-
-   dnsResNCacheErrQType OBJECT-TYPE
-       SYNTAX      DnsQType
-       MAX-ACCESS  not-accessible
-       STATUS      current
-       DESCRIPTION
-               "DNS QTYPE associated with a cached authoritative error."
-       ::= { dnsResNCacheErrEntry 3 }
-
-   dnsResNCacheErrTTL OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Time-To-Live of a cached authoritative error at the time
-               of the error, it should not be decremented by the number
-               of seconds since it was received.  This should be the
-               TTL as copied from the MINIMUM field of the SOA that
-               accompanied the authoritative error, or a smaller value
-               if the resolver implements a ceiling on negative
-               response cache TTLs."
-       REFERENCE
-               "RFC-1034 section 4.3.4."
-       ::= { dnsResNCacheErrEntry 4 }
-
-   dnsResNCacheErrElapsedTTL OBJECT-TYPE
-       SYNTAX      DnsTime
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Elapsed seconds since authoritative error was received."
-       ::= { dnsResNCacheErrEntry 5 }
-
-
-
-
-
-Austein & Saperia                                              [Page 23]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   dnsResNCacheErrSource OBJECT-TYPE
-       SYNTAX      IpAddress
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Host which sent the authoritative error, 0.0.0.0 if
-               unknown."
-       ::= { dnsResNCacheErrEntry 6 }
-
-   dnsResNCacheErrCode OBJECT-TYPE
-       SYNTAX      INTEGER { nonexistantName(1), noData(2), other(3) }
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "The authoritative error that has been cached:
-
-               nonexistantName(1) indicates an authoritative name error
-               (RCODE = 3).
-
-               noData(2) indicates an authoritative response with no
-               error (RCODE = 0) and no relevant data.
-
-               other(3) indicates some other cached authoritative
-               error.  At present, no such errors are known to exist."
-       ::= { dnsResNCacheErrEntry 7 }
-
-   dnsResNCacheErrStatus OBJECT-TYPE
-       SYNTAX      RowStatus
-       MAX-ACCESS  read-write
-       STATUS      current
-       DESCRIPTION
-               "Status column for the resolver negative response cache
-               table.  Since only the agent (DNS resolver) creates rows
-               in this table, the only values that a manager may write
-               to this variable are active(1) and destroy(6)."
-       ::= { dnsResNCacheErrEntry 8 }
-
-   dnsResNCacheErrIndex OBJECT-TYPE
-       SYNTAX      Integer32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "A value which makes entries in the table unique when the
-               other index values (dnsResNCacheErrQName,
-               dnsResNCacheErrQClass, and dnsResNCacheErrQType) do not
-               provide a unique index."
-       ::= { dnsResNCacheErrEntry 9 }
-
-
-
-
-Austein & Saperia                                              [Page 24]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   dnsResNCacheErrPrettyName OBJECT-TYPE
-       SYNTAX      DnsName
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "QNAME associated with this row in the table.  This is
-               identical to the dnsResNCacheErrQName variable, except
-               that character case is preserved in this variable, per
-               DNS conventions."
-       REFERENCE
-               "RFC-1035 section 2.3.3."
-       ::= { dnsResNCacheErrEntry 10 }
-
-
-   -- Resolver Optional Counters Group
-
-   dnsResOptCounterReferals OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of responses which were received from servers
-               redirecting query to another server."
-       ::= { dnsResOptCounter 1 }
-
-   dnsResOptCounterRetrans OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number requests retransmitted for all reasons."
-       ::= { dnsResOptCounter 2 }
-
-   dnsResOptCounterNoResponses OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries that were retransmitted because of no
-               response."
-       ::= { dnsResOptCounter 3 }
-
-   dnsResOptCounterRootRetrans OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of queries that were retransmitted that were to
-
-
-
-Austein & Saperia                                              [Page 25]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-               root servers."
-       ::= { dnsResOptCounter 4 }
-
-   dnsResOptCounterInternals OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests internally generated by the
-               resolver."
-       ::= { dnsResOptCounter 5 }
-
-   dnsResOptCounterInternalTimeOuts OBJECT-TYPE
-       SYNTAX      Counter32
-       MAX-ACCESS  read-only
-       STATUS      current
-       DESCRIPTION
-               "Number of requests internally generated which timed
-               out."
-       ::= { dnsResOptCounter 6 }
-
-
-   -- SNMPv2 groups.
-
-   dnsResMIBGroups         OBJECT IDENTIFIER ::= { dnsResMIB 2 }
-
-   dnsResConfigGroup OBJECT-GROUP
-       OBJECTS   { dnsResConfigImplementIdent,
-                   dnsResConfigService,
-                   dnsResConfigMaxCnames,
-                   dnsResConfigSbeltAddr,
-                   dnsResConfigSbeltName,
-                   dnsResConfigSbeltRecursion,
-                   dnsResConfigSbeltPref,
-                   dnsResConfigSbeltSubTree,
-                   dnsResConfigSbeltClass,
-                   dnsResConfigSbeltStatus,
-                   dnsResConfigUpTime,
-                   dnsResConfigResetTime }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing basic configuration
-               information for a DNS resolver implementation."
-       ::= { dnsResMIBGroups 1 }
-
-   dnsResCounterGroup OBJECT-GROUP
-       OBJECTS   { dnsResCounterByOpcodeCode,
-                   dnsResCounterByOpcodeQueries,
-
-
-
-Austein & Saperia                                              [Page 26]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-                   dnsResCounterByOpcodeResponses,
-                   dnsResCounterByRcodeCode,
-                   dnsResCounterByRcodeResponses,
-                   dnsResCounterNonAuthDataResps,
-                   dnsResCounterNonAuthNoDataResps,
-                   dnsResCounterMartians,
-                   dnsResCounterRecdResponses,
-                   dnsResCounterUnparseResps,
-                   dnsResCounterFallbacks }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing basic instrumentation
-               of a DNS resolver implementation."
-       ::= { dnsResMIBGroups 2 }
-
-   dnsResLameDelegationGroup OBJECT-GROUP
-       OBJECTS   { dnsResLameDelegationOverflows,
-                   dnsResLameDelegationSource,
-                   dnsResLameDelegationName,
-                   dnsResLameDelegationClass,
-                   dnsResLameDelegationCounts,
-                   dnsResLameDelegationStatus }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing instrumentation of
-               `lame delegation' failures."
-       ::= { dnsResMIBGroups 3 }
-
-
-   dnsResCacheGroup OBJECT-GROUP
-       OBJECTS   { dnsResCacheStatus,
-                   dnsResCacheMaxTTL,
-                   dnsResCacheGoodCaches,
-                   dnsResCacheBadCaches,
-                   dnsResCacheRRName,
-                   dnsResCacheRRClass,
-                   dnsResCacheRRType,
-                   dnsResCacheRRTTL,
-                   dnsResCacheRRElapsedTTL,
-                   dnsResCacheRRSource,
-                   dnsResCacheRRData,
-                   dnsResCacheRRStatus,
-                   dnsResCacheRRIndex,
-                   dnsResCacheRRPrettyName }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing access to and control
-               of a DNS resolver's cache."
-
-
-
-Austein & Saperia                                              [Page 27]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-       ::= { dnsResMIBGroups 4 }
-
-   dnsResNCacheGroup OBJECT-GROUP
-       OBJECTS   { dnsResNCacheStatus,
-                   dnsResNCacheMaxTTL,
-                   dnsResNCacheGoodNCaches,
-                   dnsResNCacheBadNCaches,
-                   dnsResNCacheErrQName,
-                   dnsResNCacheErrQClass,
-                   dnsResNCacheErrQType,
-                   dnsResNCacheErrTTL,
-                   dnsResNCacheErrElapsedTTL,
-                   dnsResNCacheErrSource,
-                   dnsResNCacheErrCode,
-                   dnsResNCacheErrStatus,
-                   dnsResNCacheErrIndex,
-                   dnsResNCacheErrPrettyName }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing access to and control
-               of a DNS resolver's negative response cache."
-       ::= { dnsResMIBGroups 5 }
-
-   dnsResOptCounterGroup OBJECT-GROUP
-       OBJECTS   { dnsResOptCounterReferals,
-                   dnsResOptCounterRetrans,
-                   dnsResOptCounterNoResponses,
-                   dnsResOptCounterRootRetrans,
-                   dnsResOptCounterInternals,
-                   dnsResOptCounterInternalTimeOuts }
-       STATUS      current
-       DESCRIPTION
-               "A collection of objects providing further
-               instrumentation applicable to many but not all DNS
-               resolvers."
-       ::= { dnsResMIBGroups 6 }
-
-
-   -- Compliances.
-
-   dnsResMIBCompliances OBJECT IDENTIFIER ::= { dnsResMIB 3 }
-
-   dnsResMIBCompliance MODULE-COMPLIANCE
-       STATUS      current
-       DESCRIPTION
-               "The compliance statement for agents implementing the DNS
-               resolver MIB extensions."
-       MODULE -- This MIB module
-
-
-
-Austein & Saperia                                              [Page 28]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-           MANDATORY-GROUPS { dnsResConfigGroup, dnsResCounterGroup }
-           GROUP   dnsResCacheGroup
-           DESCRIPTION
-               "The resolver cache group is mandatory for resolvers that
-               implement a cache."
-           GROUP   dnsResNCacheGroup
-           DESCRIPTION
-               "The resolver negative cache group is mandatory for
-               resolvers that implement a negative response cache."
-           GROUP   dnsResLameDelegationGroup
-           DESCRIPTION
-               "The lame delegation group is unconditionally optional."
-           GROUP   dnsResOptCounterGroup
-           DESCRIPTION
-               "The optional counters group is unconditionally
-               optional."
-           OBJECT  dnsResConfigMaxCnames
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-           OBJECT  dnsResConfigSbeltName
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-           OBJECT  dnsResConfigSbeltRecursion
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-           OBJECT  dnsResConfigSbeltPref
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-           OBJECT  dnsResConfigReset
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-           OBJECT  dnsResCacheStatus
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-           OBJECT  dnsResCacheMaxTTL
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-           OBJECT  dnsResNCacheStatus
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-
-
-
-Austein & Saperia                                              [Page 29]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-           OBJECT  dnsResNCacheMaxTTL
-           MIN-ACCESS      read-only
-           DESCRIPTION
-               "This object need not be writable."
-       ::= { dnsResMIBCompliances 1 }
-
-   END
-
-5.  Acknowledgements
-
-   This document is the result of work undertaken the by DNS working
-   group.  The authors would particularly like to thank the following
-   people for their contributions to this document: Philip Almquist,
-   Frank Kastenholz (FTP Software), Joe Peck (DEC), Dave Perkins
-   (SynOptics), Win Treese (DEC), and Mimi Zohar (IBM).
-
-6.  References
-
-   [1] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
-       13, RFC 1034, USC/Information Sciences Institute, November 1987.
-
-   [2] Mockapetris, P., "Domain Names -- Implementation and
-       Specification", STD 13, RFC 1035, USC/Information Sciences
-       Institute, November 1987.
-
-   [3] Braden, R., Editor, "Requirements for Internet Hosts --
-       Application and Support, STD 3, RFC 1123, USC/Information
-       Sciences Institute, October 1989.
-
-   [4] Rose, M., and K. McCloghrie, "Structure and Identification of
-       Management Information for TCP/IP-based internets", STD 16, RFC
-       1155, Performance Systems International, Hughes LAN Systems, May
-       1990.
-
-   [5] McCloghrie, K., and M. Rose, "Management Information Base for
-       Network Management of TCP/IP-based internets", RFC 1156, Hughes
-       LAN Systems, Performance Systems International, May 1990.
-
-   [6] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
-       Network Management Protocol", STD 15, RFC 1157, SNMP Research,
-       Performance Systems International, Performance Systems
-       International, MIT Laboratory for Computer Science, May 1990.
-
-   [7] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
-       STD 16, RFC 1212, Performance Systems International, Hughes LAN
-       Systems, March 1991.
-
-
-
-
-
-Austein & Saperia                                              [Page 30]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-   [8] McCloghrie, K., and M. Rose, "Management Information Base for
-       Network Management of TCP/IP-based internets: MIB-II", STD 17,
-       RFC 1213, Hughes LAN Systems, Performance Systems International,
-       March 1991.
-
-   [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure
-       of Management Information for version 2 of the Simple Network
-       Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc.,
-       Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
-       University, April 1993.
-
-  [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual
-       Conventions for version 2 of the the Simple Network Management
-       Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN
-       Systems, Dover Beach Consulting, Inc., Carnegie Mellon
-       University, April 1993.
-
-  [11] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
-       "Conformance Statements for version 2 of the the Simple Network
-       Management Protocol (SNMPv2)", RFC 1444, SNMP Research, Inc.,
-       Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
-       University, April 1993.
-
-  [12] Galvin, J., and K. McCloghrie, "Administrative Model for version
-       2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445,
-       Trusted Information Systems, Hughes LAN Systems, April 1993.
-
-  [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
-       Operations for version 2 of the Simple Network Management
-       Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN
-       Systems, Dover Beach Consulting, Inc., Carnegie Mellon
-       University, April 1993.
-
-  [14] "Information processing systems - Open Systems Interconnection -
-       Specification of Abstract Syntax Notation One (ASN.1)",
-       International Organization for Standardization, International
-       Standard 8824, December 1987.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein & Saperia                                              [Page 31]
-
-RFC 1612                    DNS Resolver MIB                    May 1994
-
-
-7.  Security Considerations
-
-   Security issues are not discussed in this memo.
-
-8.  Authors' Addresses
-
-   Rob Austein
-   Epilogue Technology Corporation
-   268 Main Street, Suite 283
-   North Reading, MA 01864
-   USA
-
-   Phone: +1-617-245-0804
-   Fax:   +1-617-245-8122
-   EMail: sra@epilogue.com
-
-
-   Jon Saperia
-   Digital Equipment Corporation
-   110 Spit Brook Road
-   ZKO1-3/H18
-   Nashua, NH 03062-2698
-   USA
-
-   Phone: +1-603-881-0480
-   Fax:   +1-603-881-0120
-   EMail: saperia@zko.dec.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein & Saperia                                              [Page 32]
-
diff --git a/contrib/bind9/doc/rfc/rfc1706.txt b/contrib/bind9/doc/rfc/rfc1706.txt
deleted file mode 100644
index 5b5d821..0000000
--- a/contrib/bind9/doc/rfc/rfc1706.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         B. Manning
-Request for Comments: 1706                                           ISI
-Obsoletes: 1637, 1348                                         R. Colella
-Category: Informational                                             NIST
-                                                            October 1994
-
-
-                       DNS NSAP Resource Records
-
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  This memo
-   does not specify an Internet standard of any kind.  Distribution of
-   this memo is unlimited.
-
-Abstract
-
-   OSI lower layer protocols, comprising the connectionless network
-   protocol (CLNP) and supporting routing protocols, are deployed in
-   some parts of the global Internet.  Maintenance and debugging of CLNP
-   connectivity is greatly aided by support in the Domain Name System
-   (DNS) for mapping between names and NSAP addresses.
-
-   This document defines the format of one new Resource Record (RR) for
-   the DNS for domain name-to-NSAP mapping. The RR may be used with any
-   NSAP address format.
-
-   NSAP-to-name translation is accomplished through use of the PTR RR
-   (see STD 13, RFC 1035 for a description of the PTR RR). This paper
-   describes how PTR RRs are used to support this translation.
-
-   This document obsoletes RFC 1348 and RFC 1637.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Manning & Colella                                               [Page 1]
-
-RFC 1706                      DNS NSAP RRs                  October 1994
-
-
-1.  Introduction
-
-   OSI lower layer protocols, comprising the connectionless network
-   protocol (CLNP) [5] and supporting routing protocols, are deployed in
-   some parts of the global Internet.  Maintenance and debugging of CLNP
-   connectivity is greatly aided by support in the Domain Name System
-   (DNS) [7] [8] for mapping between names and NSAP (network service
-   access point) addresses [6] [Note: NSAP and NSAP address are used
-   interchangeably throughout this memo].
-
-   This document defines the format of one new Resource Record (RR) for
-   the DNS for domain name-to-NSAP mapping. The RR may be used with any
-   NSAP address format.
-
-   NSAP-to-name translation is accomplished through use of the PTR RR
-   (see RFC 1035 for a description of the PTR RR). This paper describes
-   how PTR RRs are used to support this translation.
-
-   This memo assumes that the reader is familiar with the DNS. Some
-   familiarity with NSAPs is useful; see [1] or Annex A of [6] for
-   additional information.
-
-2.  Background
-
-   The reason for defining DNS mappings for NSAPs is to support the
-   existing CLNP deployment in the Internet.  Debugging with CLNP ping
-   and traceroute has become more difficult with only numeric NSAPs as
-   the scale of deployment has increased. Current debugging is supported
-   by maintaining and exchanging a configuration file with name/NSAP
-   mappings similar in function to hosts.txt. This suffers from the lack
-   of a central coordinator for this file and also from the perspective
-   of scaling.  The former describes the most serious short-term
-   problem. Scaling of a hosts.txt-like solution has well-known long-
-   term scaling difficiencies.
-
-3.  Scope
-
-   The methods defined in this paper are applicable to all NSAP formats.
-
-   As a point of reference, there is a distinction between registration
-   and publication of addresses. For IP addresses, the IANA is the root
-   registration authority and the DNS a publication method. For NSAPs,
-   Annex A of the network service definition, ISO8348 [6], describes the
-   root registration authority and this memo defines how the DNS is used
-   as a publication method.
-
-
-
-
-
-
-Manning & Colella                                               [Page 2]
-
-RFC 1706                      DNS NSAP RRs                  October 1994
-
-
-4.  Structure of NSAPs
-
-   NSAPs are hierarchically structured to allow distributed
-   administration and efficient routing. Distributed administration
-   permits subdelegated addressing authorities to, as allowed by the
-   delegator, further structure the portion of the NSAP space under
-   their delegated control.  Accomodating this distributed authority
-   requires that there be little or no a priori knowledge of the
-   structure of NSAPs built into DNS resolvers and servers.
-
-   For the purposes of this memo, NSAPs can be thought of as a tree of
-   identifiers. The root of the tree is ISO8348 [6], and has as its
-   immediately registered subordinates the one-octet Authority and
-   Format Identifiers (AFIs) defined there. The size of subsequently-
-   defined fields depends on which branch of the tree is taken. The
-   depth of the tree varies according to the authority responsible for
-   defining subsequent fields.
-
-   An example is the authority under which U.S. GOSIP defines NSAPs [2].
-   Under the AFI of 47, NIST (National Institute of Standards and
-   Technology) obtained a value of 0005 (the AFI of 47 defines the next
-   field as being two octets consisting of four BCD digits from the
-   International Code Designator space [3]). NIST defined the subsequent
-   fields in [2], as shown in Figure 1. The field immediately following
-   0005 is a format identifier for the rest of the U.S. GOSIP NSAP
-   structure, with a hex value of 80. Following this is the three-octet
-   field, values for which are allocated to network operators; the
-   registration authority for this field is delegated to GSA (General
-   Services Administration).
-
-   The last octet of the NSAP is the NSelector (NSel). In practice, the
-   NSAP minus the NSel identifies the CLNP protocol machine on a given
-   system, and the NSel identifies the CLNP user. Since there can be
-   more than one CLNP user (meaning multiple NSel values for a given
-   "base" NSAP), the representation of the NSAP should be CLNP-user
-   independent. To achieve this, an NSel value of zero shall be used
-   with all NSAP values stored in the DNS. An NSAP with NSel=0
-   identifies the network layer itself. It is left to the application
-   retrieving the NSAP to determine the appropriate value to use in that
-   instance of communication.
-
-   When CLNP is used to support TCP and UDP services, the NSel value
-   used is the appropriate IP PROTO value as registered with the IANA.
-   For "standard" OSI, the selection of NSel values is left as a matter
-   of local administration. Administrators of systems that support the
-   OSI transport protocol [4] in addition to TCP/UDP must select NSels
-   for use by OSI Transport that do not conflict with the IP PROTO
-   values.
-
-
-
-Manning & Colella                                               [Page 3]
-
-RFC 1706                      DNS NSAP RRs                  October 1994
-
-
-              |--------------|
-              | <-- IDP -->  |
-              |--------------|-------------------------------------|
-              | AFI |  IDI   |            <-- DSP -->              |
-              |-----|--------|-------------------------------------|
-              | 47  |  0005  | DFI | AA |Rsvd | RD |Area | ID |Sel |
-              |-----|--------|-----|----|-----|----|-----|----|----|
-       octets |  1  |   2    |  1  | 3  |  2  | 2  |  2  | 6  | 1  |
-              |-----|--------|-----|----|-----|----|-----|----|----|
-
-                    IDP    Initial Domain Part
-                    AFI    Authority and Format Identifier
-                    IDI    Initial Domain Identifier
-                    DSP    Domain Specific Part
-                    DFI    DSP Format Identifier
-                    AA     Administrative Authority
-                    Rsvd   Reserved
-                    RD     Routing Domain Identifier
-                    Area   Area Identifier
-                    ID     System Identifier
-                    SEL    NSAP Selector
-
-                  Figure 1: GOSIP Version 2 NSAP structure.
-
-
-   In the NSAP RRs in Master Files and in the printed text in this memo,
-   NSAPs are often represented as a string of "."-separated hex values.
-   The values correspond to convenient divisions of the NSAP to make it
-   more readable. For example, the "."-separated fields might correspond
-   to the NSAP fields as defined by the appropriate authority (RARE,
-   U.S. GOSIP, ANSI, etc.). The use of this notation is strictly for
-   readability. The "."s do not appear in DNS packets and DNS servers
-   can ignore them when reading Master Files. For example, a printable
-   representation of the first four fields of a U.S. GOSIP NSAP might
-   look like
-
-                             47.0005.80.005a00
-
-   and a full U.S. GOSIP NSAP might appear as
-
-             47.0005.80.005a00.0000.1000.0020.00800a123456.00.
-
-   Other NSAP formats have different lengths and different
-   administratively defined field widths to accomodate different
-   requirements. For more information on NSAP formats in use see RFC
-   1629 [1].
-
-
-
-
-
-Manning & Colella                                               [Page 4]
-
-RFC 1706                      DNS NSAP RRs                  October 1994
-
-
-5.  The NSAP RR
-
-   The NSAP RR is defined with mnemonic "NSAP" and TYPE code 22
-   (decimal) and is used to map from domain names to NSAPs. Name-to-NSAP
-   mapping in the DNS using the NSAP RR operates analogously to IP
-   address lookup. A query is generated by the resolver requesting an
-   NSAP RR for a provided domain name.
-
-   NSAP RRs conform to the top level RR format and semantics as defined
-   in Section 3.2.1 of RFC 1035.
-
-                                            1  1  1  1  1  1
-              0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-           |                                               |
-           /                                               /
-           /                        NAME                   /
-           |                                               |
-           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-           |                    TYPE = NSAP                |
-           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-           |                    CLASS = IN                 |
-           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-           |                        TTL                    |
-           |                                               |
-           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-           |                      RDLENGTH                 |
-           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-           /                       RDATA                   /
-           /                                               /
-           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   where:
-
-   *  NAME: an owner name, i.e., the name of the node to which this
-      resource record pertains.
-
-   *  TYPE: two octets containing the NSAP RR TYPE code of 22 (decimal).
-
-   *  CLASS: two octets containing the RR IN CLASS code of 1.
-
-   *  TTL: a 32 bit signed integer that specifies the time interval in
-      seconds that the resource record may be cached before the source
-      of the information should again be consulted. Zero values are
-      interpreted to mean that the RR can only be used for the
-      transaction in progress, and should not be cached. For example,
-      SOA records are always distributed with a zero TTL to prohibit
-      caching. Zero values can also be used for extremely volatile data.
-
-
-
-Manning & Colella                                               [Page 5]
-
-RFC 1706                      DNS NSAP RRs                  October 1994
-
-
-   *  RDLENGTH: an unsigned 16 bit integer that specifies the length in
-      octets of the RDATA field.
-
-   *  RDATA: a variable length string of octets containing the NSAP.
-      The value is the binary encoding of the NSAP as it would appear in
-      the CLNP source or destination address field. A typical example of
-      such an NSAP (in hex) is shown below. For this NSAP, RDLENGTH is
-      20 (decimal); "."s have been omitted to emphasize that they don't
-      appear in the DNS packets.
-
-                 39840f80005a0000000001e13708002010726e00
-
-   NSAP RRs cause no additional section processing.
-
-6.  NSAP-to-name Mapping Using the PTR RR
-
-   The PTR RR is defined in RFC 1035. This RR is typically used under
-   the "IN-ADDR.ARPA" domain to map from IPv4 addresses to domain names.
-
-   Similarly, the PTR RR is used to map from NSAPs to domain names under
-   the "NSAP.INT" domain. A domain name is generated from the NSAP
-   according to the rules described below. A query is sent by the
-   resolver requesting a PTR RR for the provided domain name.
-
-   A domain name is generated from an NSAP by reversing the hex nibbles
-   of the NSAP, treating each nibble as a separate subdomain, and
-   appending the top-level subdomain name "NSAP.INT" to it. For example,
-   the domain name used in the reverse lookup for the NSAP
-
-             47.0005.80.005a00.0000.0001.e133.ffffff000162.00
-
-   would appear as
-
-     0.0.2.6.1.0.0.0.f.f.f.f.f.f.3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0. \
-                         0.8.5.0.0.0.7.4.NSAP.INT.
-
-   [Implementation note: For sanity's sake user interfaces should be
-   designed to allow users to enter NSAPs using their natural order,
-   i.e., as they are typically written on paper. Also, arbitrary "."s
-   should be allowed (and ignored) on input.]
-
-7.  Master File Format
-
-   The format of NSAP RRs (and NSAP-related PTR RRs) in Master Files
-   conforms to Section 5, "Master Files," of RFC 1035. Below are
-   examples of the use of these RRs in Master Files to support name-to-
-   NSAP and NSAP-to-name mapping.
-
-
-
-
-Manning & Colella                                               [Page 6]
-
-RFC 1706                      DNS NSAP RRs                  October 1994
-
-
-   The NSAP RR introduces a new hex string format for the RDATA field.
-   The format is "0x" (i.e., a zero followed by an 'x' character)
-   followed by a variable length string of hex characters (0 to 9, a to
-   f). The hex string is case-insensitive. "."s (i.e., periods) may be
-   inserted in the hex string anywhere after the "0x" for readability.
-   The "."s have no significance other than for readability and are not
-   propagated in the protocol (e.g., queries or zone transfers).
-
-
-   ;;;;;;
-   ;;;;;; Master File for domain nsap.nist.gov.
-   ;;;;;;
-
-
-   @      IN     SOA    emu.ncsl.nist.gov.  root.emu.ncsl.nist.gov. (
-                                     1994041800   ; Serial  - date
-                                     1800         ; Refresh - 30 minutes
-                                     300          ; Retry   - 5 minutes
-                                     604800       ; Expire  - 7 days
-                                     3600 )       ; Minimum - 1 hour
-          IN     NS     emu.ncsl.nist.gov.
-          IN     NS     tuba.nsap.lanl.gov.
-   ;
-   ;
-   $ORIGIN nsap.nist.gov.
-   ;
-   ;     hosts
-   ;
-   bsdi1    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000161.00
-            IN  A     129.6.224.161
-            IN  HINFO PC_486    BSDi1.1
-   ;
-   bsdi2    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00
-            IN  A     129.6.224.162
-            IN  HINFO PC_486    BSDi1.1
-   ;
-   cursive  IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000171.00
-            IN  A     129.6.224.171
-            IN  HINFO PC_386    DOS_5.0/NCSA_Telnet(TUBA)
-   ;
-   infidel  IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000164.00
-            IN  A     129.6.55.164
-            IN  HINFO PC/486    BSDi1.0(TUBA)
-   ;
-   ;     routers
-   ;
-   cisco1   IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.aaaaaa000151.00
-            IN  A     129.6.224.151
-
-
-
-Manning & Colella                                               [Page 7]
-
-RFC 1706                      DNS NSAP RRs                  October 1994
-
-
-            IN  A     129.6.225.151
-            IN  A     129.6.229.151
-   ;
-   3com1    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.aaaaaa000111.00
-            IN  A     129.6.224.111
-            IN  A     129.6.225.111
-            IN  A     129.6.228.111
-
-
-
-
-   ;;;;;;
-   ;;;;;; Master File for reverse mapping of NSAPs under the
-   ;;;;;;     NSAP prefix:
-   ;;;;;;
-   ;;;;;;          47.0005.80.005a00.0000.0001.e133
-   ;;;;;;
-
-
-   @      IN     SOA    emu.ncsl.nist.gov.  root.emu.ncsl.nist.gov. (
-                                     1994041800   ; Serial  - date
-                                     1800         ; Refresh - 30 minutes
-                                     300          ; Retry   - 5 minutes
-                                     604800       ; Expire  - 7 days
-                                     3600 )       ; Minimum - 1 hour
-          IN     NS     emu.ncsl.nist.gov.
-          IN     NS     tuba.nsap.lanl.gov.
-   ;
-   ;
-   $ORIGIN 3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0.0.8.5.0.0.0.7.4.NSAP.INT.
-   ;
-   0.0.1.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  bsdi1.nsap.nist.gov.
-   ;
-   0.0.2.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  bsdi2.nsap.nist.gov.
-   ;
-   0.0.1.7.1.0.0.0.f.f.f.f.f.f  IN    PTR  cursive.nsap.nist.gov.
-   ;
-   0.0.4.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  infidel.nsap.nist.gov.
-   ;
-   0.0.1.5.1.0.0.0.a.a.a.a.a.a  IN    PTR  cisco1.nsap.nist.gov.
-   ;
-   0.0.1.1.1.0.0.0.a.a.a.a.a.a  IN    PTR  3com1.nsap.nist.gov.
-
-8.  Security Considerations
-
-   Security issues are not discussed in this memo.
-
-
-
-
-
-Manning & Colella                                               [Page 8]
-
-RFC 1706                      DNS NSAP RRs                  October 1994
-
-
-9.  Authors' Addresses
-
-   Bill Manning
-   USC/Information Sciences Institute
-   4676 Admiralty Way
-   Marina del Rey, CA. 90292
-   USA
-
-   Phone: +1.310.822.1511
-   EMail: bmanning@isi.edu
-
-
-   Richard Colella
-   National Institute of Standards and Technology
-   Technology/B217
-   Gaithersburg, MD 20899
-   USA
-
-   Phone: +1 301-975-3627
-   Fax: +1 301 590-0932
-   EMail: colella@nist.gov
-
-10.  References
-
-   [1] Colella, R., Gardner, E., Callon, R., and Y. Rekhter, "Guidelines
-       for OSI NSAP Allocation inh the Internet", RFC 1629, NIST,
-       Wellfleet, Mitre, T.J. Watson Research Center, IBM Corp., May
-       1994.
-
-   [2] GOSIP Advanced Requirements Group.  Government Open Systems
-       Interconnection Profile (GOSIP) Version 2. Federal Information
-       Processing Standard 146-1, U.S. Department of Commerce, National
-       Institute of Standards and Technology, Gaithersburg, MD, April
-       1991.
-
-   [3] ISO/IEC.  Data interchange - structures for the identification of
-       organization.  International Standard 6523, ISO/IEC JTC 1,
-       Switzerland, 1984.
-
-   [4] ISO/IEC. Connection oriented transport protocol specification.
-       International Standard 8073, ISO/IEC JTC 1, Switzerland, 1986.
-
-   [5] ISO/IEC.  Protocol for Providing the Connectionless-mode Network
-       Service.  International Standard 8473, ISO/IEC JTC 1,
-       Switzerland, 1986.
-
-
-
-
-
-
-Manning & Colella                                               [Page 9]
-
-RFC 1706                      DNS NSAP RRs                  October 1994
-
-
-   [6] ISO/IEC. Information Processing Systems -- Data Communications --
-       Network Service Definition.  International Standard 8348, ISO/IEC
-       JTC 1, Switzerland, 1993.
-
-   [7] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
-       13, RFC 1034, USC/Information Sciences Institute, November 1987.
-
-   [8] Mockapetris, P., "Domain Names -- Implementation and
-       Specification", STD 13, RFC 1035, USC/Information Sciences
-       Institute, November 1987.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Manning & Colella                                              [Page 10]
-
diff --git a/contrib/bind9/doc/rfc/rfc1712.txt b/contrib/bind9/doc/rfc/rfc1712.txt
deleted file mode 100644
index 40d8857..0000000
--- a/contrib/bind9/doc/rfc/rfc1712.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         C. Farrell
-Request for Comments: 1712                                    M. Schulze
-Category: Experimental                                       S. Pleitner
-                                                              D. Baldoni
-                                         Curtin University of Technology
-                                                           November 1994
-
-
-                 DNS Encoding of Geographical Location
-
-Status of this Memo
-
-   This memo defines an Experimental Protocol for the Internet
-   community.  This memo does not specify an Internet standard of any
-   kind.  Discussion and suggestions for improvement are requested.
-   Distribution of this memo is unlimited.
-
-Abstract
-
-   This document defines the format of a new Resource Record (RR) for
-   the Domain Naming System (DNS), and reserves a corresponding DNS type
-   mnemonic and numerical code.  This definition deals with associating
-   geographical host location mappings to host names within a domain.
-   The data shown in this document is fictitious and does not
-   necessarily reflect the real Internet.
-
-1. Introduction
-
-   It has been a long standing problem to relate IP numbers to
-   geographical locations. The availability of Geographical location
-   information has immediate applications in network management.  Such
-   information can be used to supplement the data already provided by
-   utilities such as whois [Har85], traceroute [VJ89], and nslookup
-   [UCB89].  The usefulness and functionality of these already widely
-   used tools would be greatly enhanced by the provision of reliable
-   geographical location information.
-
-   The ideal way to manage and maintain a database of information, such
-   as geographical location of internet hosts, is to delegate
-   responsibility to local domain administrators. A large distributed
-   database could be implemented with a simple mechanism for updating
-   the local information.  A query mechanism also has to be available
-   for checking local entries, as well as inquiring about data from
-   non-local domains.
-
-
-
-
-
-
-
-Farrell, Schulze, Pleitner & Baldoni                            [Page 1]
-
-RFC 1712         DNS Encoding of Geographical Location     November 1994
-
-
-2. Background
-
-   The Internet continues to grow at an ever increasing rate with IP
-   numbers allocated on a first-come-first-serve basis.  Deciding when
-   and how to setup a database of geographical information about
-   internet hosts presented a number of options.  The uumap project
-   [UU85] was the first serious attempt to collect geographical location
-   data from sites and store it centrally.  This project met with
-   limited success because of the difficulty in maintaining and updating
-   a large central database.  Another problem was the lack of tools for
-   the checking the data supplied, this problem resulted in some
-   erroneous data entering the database.
-
-2.1 SNMP:
-
-   Using an SNMP get request on the sysLocation MIB (Management
-   Information Base) variable was also an option, however this would
-   require the host to be running an appropriate agent with public read
-   access.  It was also felt that MIB data should reflect local
-   management data (e.g., "this" host is on level 5 room 74) rather than
-   a hosts geographical position.  This view is supported in the
-   examples given in literature in this area [ROSE91].
-
-2.2 X500:
-
-   The X.500 Directory service [X.500.88] defined as part of the ISO
-   standards also appears as a potential provider of geographical
-   location data. However due to the limited implementations of this
-   service it was decided to defer this until this service gains wider
-   use and acceptance within the Internet community.
-
-2.3 BIND:
-
-   The DNS [Mock87a][Mock87b] represents an existing system ideally
-   suited to the provision of host specific information. The DNS is a
-   widely used and well-understood mechanism for providing a distributed
-   database of such information and its extensible nature allows it to
-   be used to disseminate virtually any information.  The most commonly
-   used DNS implementation is the Berkeley Internet Name Domain server
-   BIND [UCB89].  The information we wished to make available needed to
-   be updated locally but available globally; a perfect match with the
-   services provided by the DNS. Current DNS servers provide a variety
-   of useful information about hosts in their domain but lack the
-   ability to report a host's geographical location.
-
-
-
-
-
-
-
-Farrell, Schulze, Pleitner & Baldoni                            [Page 2]
-
-RFC 1712         DNS Encoding of Geographical Location     November 1994
-
-
-3. RDATA Format
-
-        MSB                                        LSB
-        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-        /                 LONGITUDE                  /
-        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-        /                  LATITUDE                  /
-        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-        /                  ALTITUDE                  /
-        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   where:
-
-   LONGITUDE The real number describing the longitude encoded as a
-             printable string. The precision is limited by 256 charcters
-             within the range -90..90 degrees. Positive numbers
-             indicate locations north of the equator.
-
-   LATITUDE The real number describing the latitude encoded as a
-            printable string. The precision is limited by 256 charcters
-            within the range -180..180 degrees. Positive numbers
-            indicate locations east of the prime meridian.
-
-   ALTITUDE The real number describing the altitude (in meters) from
-            mean sea-level encoded as a printable string. The precision
-            is limited by 256 charcters. Positive numbers indicate
-            locations above mean sea-level.
-
-   Latitude/Longitude/Altitude values are encoded as strings as to avoid
-   the precision limitations imposed by encoding as unsigned integers.
-   Although this might not be considered optimal, it allows for a very
-   high degree of precision with an acceptable average encoded record
-   length.
-
-4. The GPOS RR
-
-   The geographical location is defined with the mnemonic GPOS and type
-   code 27.
-
-   GPOS has the following format:
-           <owner> <ttl> <class> GPOS <longitude> <latitude> <altitude>
-
-   A floating point format was chosen to specify geographical locations
-   for reasons of simplicity.  This also guarantees a concise
-   unambiguous description of a location by enforcing three compulsory
-   numerical values to be specified.
-
-
-
-
-
-Farrell, Schulze, Pleitner & Baldoni                            [Page 3]
-
-RFC 1712         DNS Encoding of Geographical Location     November 1994
-
-
-   The owner, ttl, and class fields are optional and default to the last
-   defined value if omitted. The longitude is a floating point number
-   ranging from -90 to 90 with positive values indicating locations
-   north of the equator.  For example Perth, Western Australia is
-   located at 32^ 7` 19" south of the equator which would be specified
-   as -32.68820.  The latitude is a number ranging from -180.0 to 180.0.
-   For example Perth, Western Australia is located at 116^ 2' 25" east
-   of the prime meridian which would be specified as 116.86520.  Curtin
-   University, Perth is also 10 meters above sea-level.
-
-   The valid GPOS record for a host at Curtin University in  Perth
-   Western Australia would therefore be:
-
-                GPOS -32.6882 116.8652 10.0
-
-   There is no limit imposed on the number of decimal places, although
-   the length of the encoded string is limited to 256 characters for
-   each field. It is also suggested that administrators limit their
-   entries to the minimum number of necessary characters in each field.
-
-5. Master File Format
-
-   Each host requires its own GPOS field in the corresponding  DNS RR to
-   explicitly specify its geographical location and altitude.  If the
-   GPOS field is omitted, a DNS enquiry will return no position
-   information for that host.
-
-   Consider the following example:
-
-; Authoritative data for cs.curtin.edu.au.
-;
-@     IN    SOA     marsh.cs.curtin.edu.au. postmaster.cs.curtin.edu.au.
-                (
-                        94070503        ; Serial (yymmddnn)
-                        10800           ; Refresh (3 hours)
-                        3600            ; Retry (1 hour)
-                        3600000         ; Expire (1000 hours)
-                        86400           ; Minimum (24 hours)
-                )
-
-                IN      NS      marsh.cs.curtin.edu.au.
-
-marsh           IN      A       134.7.1.1
-                IN      MX      0       marsh
-                IN      HINFO   SGI-Indigo IRIX-4.0.5F
-                IN      GPOS    -32.6882 116.8652 10.0
-ftp             IN      CNAME   marsh
-
-
-
-
-Farrell, Schulze, Pleitner & Baldoni                            [Page 4]
-
-RFC 1712         DNS Encoding of Geographical Location     November 1994
-
-
-lillee          IN      A       134.7.1.2
-                IN      MX      0       marsh
-                IN      HINFO   SGI-Indigo IRIX-4.0.5F
-                IN      GPOS    -32.6882 116.8652 10.0
-
-hinault         IN      A       134.7.1.23
-                IN      MX      0       marsh
-                IN      HINFO   SUN-IPC SunOS-4.1.3
-                IN      GPOS    -22.6882 116.8652 250.0
-
-merckx          IN      A       134.7.1.24
-                IN      MX      0       marsh
-                IN      HINFO   SUN-IPC SunOS-4.1.1
-
-ambrose         IN      A       134.7.1.99
-                IN      MX      0       marsh
-                IN      HINFO   SGI-CHALLENGE_L IRIX-5.2
-                IN      GPOS    -32.6882 116.8652 10.0
-
-   The hosts marsh, lillee, and ambrose are all at the same geographical
-   location, Perth Western Australia (-32.68820 116.86520). The host
-   hinault is at a different geographical location, 10 degrees north of
-   Perth in the mountains (-22.6882 116.8652 250.0). For security
-   reasons we do not wish to give the location of the host merckx.
-
-   Although the GPOS clause is not a standard entry within BIND
-   configuration files, most vendor implementations seem to ignore
-   whatever is not understood upon startup of the DNS.  Usually this
-   will result in a number of warnings appearing in system log files,
-   but in no way alters naming information or impedes the DNS from
-   performing its normal duties.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Farrell, Schulze, Pleitner & Baldoni                            [Page 5]
-
-RFC 1712         DNS Encoding of Geographical Location     November 1994
-
-
-7. References
-
-   [ROSE91]        Rose M., "The Simple Book: An Introduction to
-                   Management of TCP/IP-based Internets", Prentice-Hall,
-                   Englewood Cliffs, New Jersey, 1991.
-
-   [X.500.88]      CCITT: The Directory - Overview of Concepts, Models
-                   and Services", Recommendations X.500 - X.521.
-
-   [Har82]         Harrenstein K, Stahl M., and E. Feinler,
-                   "NICNAME/WHOIS" RFC 812, SRI NIC, March 1982.
-
-   [Mock87a]       Mockapetris P., "Domain Names - Concepts and
-                   Facilities", STD 13, RFC 1034, USC/Information
-                   Sciences Institute, November 1987.
-
-   [Mock87b]       Mockapetris P., "Domain Names - Implementation and
-                   Specification", STD 13, RFC 1035, USC/Information
-                   Sciences Institute, November 1987.
-
-   [FRB93]         Ford P., Rekhter Y., and H-W. Braun, "Improving the
-                   Routing and Addressing of IP", IEEE Network
-                   Vol.7, No. 3, pp. 11-15, May 1993.
-
-   [VJ89]          Jacobsen V., "The Traceroute(8) Manual Page",
-                   Lawrence Berkeley Laboratory, Berkeley,
-                   CA, February 1989.
-
-   [UCB89]         University of California, "BIND: Berkeley Internet
-                   Name Domain Server", 1989.
-   [UU85]          UUCP Mapping Project, Software available via
-                   anonymous FTP from ftp.uu.net., 1985.
-
-8. Security Considerations
-
-   Once information has been entered into the DNS, it is considered
-   public.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Farrell, Schulze, Pleitner & Baldoni                            [Page 6]
-
-RFC 1712         DNS Encoding of Geographical Location     November 1994
-
-
-9. Authors' Addresses
-
-   Craig Farrell
-   Department of Computer Science
-   Curtin University of technology
-   GPO Box U1987 Perth,
-   Western Australia
-
-   EMail: craig@cs.curtin.edu.au
-
-
-   Mike Schulze
-   Department of Computer Science
-   Curtin University of technology
-   GPO Box U1987 Perth,
-   Western Australia
-
-   EMail: mike@cs.curtin.edu.au
-
-
-   Scott Pleitner
-   Department of Computer Science
-   Curtin University of technology
-   GPO Box U1987 Perth,
-   Western Australia
-
-   EMail: pleitner@cs.curtin.edu.au
-
-
-   Daniel Baldoni
-   Department of Computer Science
-   Curtin University of technology
-   GPO Box U1987 Perth,
-   Western Australia
-
-   EMail: flint@cs.curtin.edu.au
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Farrell, Schulze, Pleitner & Baldoni                            [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc1750.txt b/contrib/bind9/doc/rfc/rfc1750.txt
deleted file mode 100644
index 56d478c..0000000
--- a/contrib/bind9/doc/rfc/rfc1750.txt
+++ /dev/null
@@ -1,1683 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                   D. Eastlake, 3rd
-Request for Comments: 1750                                           DEC
-Category: Informational                                       S. Crocker
-                                                               Cybercash
-                                                             J. Schiller
-                                                                     MIT
-                                                           December 1994
-
-
-                Randomness Recommendations for Security
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  This memo
-   does not specify an Internet standard of any kind.  Distribution of
-   this memo is unlimited.
-
-Abstract
-
-   Security systems today are built on increasingly strong cryptographic
-   algorithms that foil pattern analysis attempts. However, the security
-   of these systems is dependent on generating secret quantities for
-   passwords, cryptographic keys, and similar quantities.  The use of
-   pseudo-random processes to generate secret quantities can result in
-   pseudo-security.  The sophisticated attacker of these security
-   systems may find it easier to reproduce the environment that produced
-   the secret quantities, searching the resulting small set of
-   possibilities, than to locate the quantities in the whole of the
-   number space.
-
-   Choosing random quantities to foil a resourceful and motivated
-   adversary is surprisingly difficult.  This paper points out many
-   pitfalls in using traditional pseudo-random number generation
-   techniques for choosing such quantities.  It recommends the use of
-   truly random hardware techniques and shows that the existing hardware
-   on many systems can be used for this purpose.  It provides
-   suggestions to ameliorate the problem when a hardware solution is not
-   available.  And it gives examples of how large such quantities need
-   to be for some particular applications.
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 1]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-Acknowledgements
-
-   Comments on this document that have been incorporated were received
-   from (in alphabetic order) the following:
-
-        David M. Balenson (TIS)
-        Don Coppersmith (IBM)
-        Don T. Davis (consultant)
-        Carl Ellison (Stratus)
-        Marc Horowitz (MIT)
-        Christian Huitema (INRIA)
-        Charlie Kaufman (IRIS)
-        Steve Kent (BBN)
-        Hal Murray (DEC)
-        Neil Haller (Bellcore)
-        Richard Pitkin (DEC)
-        Tim Redmond (TIS)
-        Doug Tygar (CMU)
-
-Table of Contents
-
-   1. Introduction........................................... 3
-   2. Requirements........................................... 4
-   3. Traditional Pseudo-Random Sequences.................... 5
-   4. Unpredictability....................................... 7
-   4.1 Problems with Clocks and Serial Numbers............... 7
-   4.2 Timing and Content of External Events................  8
-   4.3 The Fallacy of Complex Manipulation..................  8
-   4.4 The Fallacy of Selection from a Large Database.......  9
-   5. Hardware for Randomness............................... 10
-   5.1 Volume Required...................................... 10
-   5.2 Sensitivity to Skew.................................. 10
-   5.2.1 Using Stream Parity to De-Skew..................... 11
-   5.2.2 Using Transition Mappings to De-Skew............... 12
-   5.2.3 Using FFT to De-Skew............................... 13
-   5.2.4 Using Compression to De-Skew....................... 13
-   5.3 Existing Hardware Can Be Used For Randomness......... 14
-   5.3.1 Using Existing Sound/Video Input................... 14
-   5.3.2 Using Existing Disk Drives......................... 14
-   6. Recommended Non-Hardware Strategy..................... 14
-   6.1 Mixing Functions..................................... 15
-   6.1.1 A Trivial Mixing Function.......................... 15
-   6.1.2 Stronger Mixing Functions.......................... 16
-   6.1.3 Diff-Hellman as a Mixing Function.................. 17
-   6.1.4 Using a Mixing Function to Stretch Random Bits..... 17
-   6.1.5 Other Factors in Choosing a Mixing Function........ 18
-   6.2 Non-Hardware Sources of Randomness................... 19
-   6.3 Cryptographically Strong Sequences................... 19
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 2]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   6.3.1 Traditional Strong Sequences....................... 20
-   6.3.2 The Blum Blum Shub Sequence Generator.............. 21
-   7. Key Generation Standards.............................. 22
-   7.1 US DoD Recommendations for Password Generation....... 23
-   7.2 X9.17 Key Generation................................. 23
-   8. Examples of Randomness Required....................... 24
-   8.1  Password Generation................................. 24
-   8.2 A Very High Security Cryptographic Key............... 25
-   8.2.1 Effort per Key Trial............................... 25
-   8.2.2 Meet in the Middle Attacks......................... 26
-   8.2.3 Other Considerations............................... 26
-   9. Conclusion............................................ 27
-   10. Security Considerations.............................. 27
-   References............................................... 28
-   Authors' Addresses....................................... 30
-
-1. Introduction
-
-   Software cryptography is coming into wider use.  Systems like
-   Kerberos, PEM, PGP, etc. are maturing and becoming a part of the
-   network landscape [PEM].  These systems provide substantial
-   protection against snooping and spoofing.  However, there is a
-   potential flaw.  At the heart of all cryptographic systems is the
-   generation of secret, unguessable (i.e., random) numbers.
-
-   For the present, the lack of generally available facilities for
-   generating such unpredictable numbers is an open wound in the design
-   of cryptographic software.  For the software developer who wants to
-   build a key or password generation procedure that runs on a wide
-   range of hardware, the only safe strategy so far has been to force
-   the local installation to supply a suitable routine to generate
-   random numbers.  To say the least, this is an awkward, error-prone
-   and unpalatable solution.
-
-   It is important to keep in mind that the requirement is for data that
-   an adversary has a very low probability of guessing or determining.
-   This will fail if pseudo-random data is used which only meets
-   traditional statistical tests for randomness or which is based on
-   limited range sources, such as clocks.  Frequently such random
-   quantities are determinable by an adversary searching through an
-   embarrassingly small space of possibilities.
-
-   This informational document suggests techniques for producing random
-   quantities that will be resistant to such attack.  It recommends that
-   future systems include hardware random number generation or provide
-   access to existing hardware that can be used for this purpose.  It
-   suggests methods for use if such hardware is not available.  And it
-   gives some estimates of the number of random bits required for sample
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 3]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   applications.
-
-2. Requirements
-
-   Probably the most commonly encountered randomness requirement today
-   is the user password. This is usually a simple character string.
-   Obviously, if a password can be guessed, it does not provide
-   security.  (For re-usable passwords, it is desirable that users be
-   able to remember the password.  This may make it advisable to use
-   pronounceable character strings or phrases composed on ordinary
-   words.  But this only affects the format of the password information,
-   not the requirement that the password be very hard to guess.)
-
-   Many other requirements come from the cryptographic arena.
-   Cryptographic techniques can be used to provide a variety of services
-   including confidentiality and authentication.  Such services are
-   based on quantities, traditionally called "keys", that are unknown to
-   and unguessable by an adversary.
-
-   In some cases, such as the use of symmetric encryption with the one
-   time pads [CRYPTO*] or the US Data Encryption Standard [DES], the
-   parties who wish to communicate confidentially and/or with
-   authentication must all know the same secret key.  In other cases,
-   using what are called asymmetric or "public key" cryptographic
-   techniques, keys come in pairs.  One key of the pair is private and
-   must be kept secret by one party, the other is public and can be
-   published to the world.  It is computationally infeasible to
-   determine the private key from the public key [ASYMMETRIC, CRYPTO*].
-
-   The frequency and volume of the requirement for random quantities
-   differs greatly for different cryptographic systems.  Using pure RSA
-   [CRYPTO*], random quantities are required when the key pair is
-   generated, but thereafter any number of messages can be signed
-   without any further need for randomness.  The public key Digital
-   Signature Algorithm that has been proposed by the US National
-   Institute of Standards and Technology (NIST) requires good random
-   numbers for each signature.  And encrypting with a one time pad, in
-   principle the strongest possible encryption technique, requires a
-   volume of randomness equal to all the messages to be processed.
-
-   In most of these cases, an adversary can try to determine the
-   "secret" key by trial and error.  (This is possible as long as the
-   key is enough smaller than the message that the correct key can be
-   uniquely identified.)  The probability of an adversary succeeding at
-   this must be made acceptably low, depending on the particular
-   application.  The size of the space the adversary must search is
-   related to the amount of key "information" present in the information
-   theoretic sense [SHANNON].  This depends on the number of different
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 4]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   secret values possible and the probability of each value as follows:
-
-                      -----
-                       \
-        Bits-of-info =  \  - p   * log  ( p  )
-                        /     i       2    i
-                       /
-                      -----
-
-   where i varies from 1 to the number of possible secret values and p
-   sub i is the probability of the value numbered i.  (Since p sub i is
-   less than one, the log will be negative so each term in the sum will
-   be non-negative.)
-
-   If there are 2^n different values of equal probability, then n bits
-   of information are present and an adversary would, on the average,
-   have to try half of the values, or 2^(n-1) , before guessing the
-   secret quantity.  If the probability of different values is unequal,
-   then there is less information present and fewer guesses will, on
-   average, be required by an adversary.  In particular, any values that
-   the adversary can know are impossible, or are of low probability, can
-   be initially ignored by an adversary, who will search through the
-   more probable values first.
-
-   For example, consider a cryptographic system that uses 56 bit keys.
-   If these 56 bit keys are derived by using a fixed pseudo-random
-   number generator that is seeded with an 8 bit seed, then an adversary
-   needs to search through only 256 keys (by running the pseudo-random
-   number generator with every possible seed), not the 2^56 keys that
-   may at first appear to be the case. Only 8 bits of "information" are
-   in these 56 bit keys.
-
-3. Traditional Pseudo-Random Sequences
-
-   Most traditional sources of random numbers use deterministic sources
-   of "pseudo-random" numbers.  These typically start with a "seed"
-   quantity and use numeric or logical operations to produce a sequence
-   of values.
-
-   [KNUTH] has a classic exposition on pseudo-random numbers.
-   Applications he mentions are simulation of natural phenomena,
-   sampling, numerical analysis, testing computer programs, decision
-   making, and games.  None of these have the same characteristics as
-   the sort of security uses we are talking about.  Only in the last two
-   could there be an adversary trying to find the random quantity.
-   However, in these cases, the adversary normally has only a single
-   chance to use a guessed value.  In guessing passwords or attempting
-   to break an encryption scheme, the adversary normally has many,
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 5]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   perhaps unlimited, chances at guessing the correct value and should
-   be assumed to be aided by a computer.
-
-   For testing the "randomness" of numbers, Knuth suggests a variety of
-   measures including statistical and spectral.  These tests check
-   things like autocorrelation between different parts of a "random"
-   sequence or distribution of its values.  They could be met by a
-   constant stored random sequence, such as the "random" sequence
-   printed in the CRC Standard Mathematical Tables [CRC].
-
-   A typical pseudo-random number generation technique, known as a
-   linear congruence pseudo-random number generator, is modular
-   arithmetic where the N+1th value is calculated from the Nth value by
-
-        V    = ( V  * a + b )(Mod c)
-         N+1      N
-
-   The above technique has a strong relationship to linear shift
-   register pseudo-random number generators, which are well understood
-   cryptographically [SHIFT*].  In such generators bits are introduced
-   at one end of a shift register as the Exclusive Or (binary sum
-   without carry) of bits from selected fixed taps into the register.
-
-   For example:
-
-      +----+     +----+     +----+                      +----+
-      | B  | <-- | B  | <-- | B  | <--  . . . . . . <-- | B  | <-+
-      |  0 |     |  1 |     |  2 |                      |  n |   |
-      +----+     +----+     +----+                      +----+   |
-        |                     |            |                     |
-        |                     |            V                  +-----+
-        |                     V            +----------------> |     |
-        V                     +-----------------------------> | XOR |
-        +---------------------------------------------------> |     |
-                                                              +-----+
-
-
-       V    = ( ( V  * 2 ) + B .xor. B ... )(Mod 2^n)
-        N+1         N         0       2
-
-   The goodness of traditional pseudo-random number generator algorithms
-   is measured by statistical tests on such sequences.  Carefully chosen
-   values of the initial V and a, b, and c or the placement of shift
-   register tap in the above simple processes can produce excellent
-   statistics.
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 6]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   These sequences may be adequate in simulations (Monte Carlo
-   experiments) as long as the sequence is orthogonal to the structure
-   of the space being explored.  Even there, subtle patterns may cause
-   problems.  However, such sequences are clearly bad for use in
-   security applications.  They are fully predictable if the initial
-   state is known.  Depending on the form of the pseudo-random number
-   generator, the sequence may be determinable from observation of a
-   short portion of the sequence [CRYPTO*, STERN].  For example, with
-   the generators above, one can determine V(n+1) given knowledge of
-   V(n).  In fact, it has been shown that with these techniques, even if
-   only one bit of the pseudo-random values is released, the seed can be
-   determined from short sequences.
-
-   Not only have linear congruent generators been broken, but techniques
-   are now known for breaking all polynomial congruent generators
-   [KRAWCZYK].
-
-4. Unpredictability
-
-   Randomness in the traditional sense described in section 3 is NOT the
-   same as the unpredictability required for security use.
-
-   For example, use of a widely available constant sequence, such as
-   that from the CRC tables, is very weak against an adversary. Once
-   they learn of or guess it, they can easily break all security, future
-   and past, based on the sequence [CRC].  Yet the statistical
-   properties of these tables are good.
-
-   The following sections describe the limitations of some randomness
-   generation techniques and sources.
-
-4.1 Problems with Clocks and Serial Numbers
-
-   Computer clocks, or similar operating system or hardware values,
-   provide significantly fewer real bits of unpredictability than might
-   appear from their specifications.
-
-   Tests have been done on clocks on numerous systems and it was found
-   that their behavior can vary widely and in unexpected ways.  One
-   version of an operating system running on one set of hardware may
-   actually provide, say, microsecond resolution in a clock while a
-   different configuration of the "same" system may always provide the
-   same lower bits and only count in the upper bits at much lower
-   resolution.  This means that successive reads on the clock may
-   produce identical values even if enough time has passed that the
-   value "should" change based on the nominal clock resolution. There
-   are also cases where frequently reading a clock can produce
-   artificial sequential values because of extra code that checks for
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 7]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   the clock being unchanged between two reads and increases it by one!
-   Designing portable application code to generate unpredictable numbers
-   based on such system clocks is particularly challenging because the
-   system designer does not always know the properties of the system
-   clocks that the code will execute on.
-
-   Use of a hardware serial number such as an Ethernet address may also
-   provide fewer bits of uniqueness than one would guess.  Such
-   quantities are usually heavily structured and subfields may have only
-   a limited range of possible values or values easily guessable based
-   on approximate date of manufacture or other data.  For example, it is
-   likely that most of the Ethernet cards installed on Digital Equipment
-   Corporation (DEC) hardware within DEC were manufactured by DEC
-   itself, which significantly limits the range of built in addresses.
-
-   Problems such as those described above related to clocks and serial
-   numbers make code to produce unpredictable quantities difficult if
-   the code is to be ported across a variety of computer platforms and
-   systems.
-
-4.2 Timing and Content of External Events
-
-   It is possible to measure the timing and content of mouse movement,
-   key strokes, and similar user events.  This is a reasonable source of
-   unguessable data with some qualifications.  On some machines, inputs
-   such as key strokes are buffered.  Even though the user's inter-
-   keystroke timing may have sufficient variation and unpredictability,
-   there might not be an easy way to access that variation.  Another
-   problem is that no standard method exists to sample timing details.
-   This makes it hard to build standard software intended for
-   distribution to a large range of machines based on this technique.
-
-   The amount of mouse movement or the keys actually hit are usually
-   easier to access than timings but may yield less unpredictability as
-   the user may provide highly repetitive input.
-
-   Other external events, such as network packet arrival times, can also
-   be used with care.  In particular, the possibility of manipulation of
-   such times by an adversary must be considered.
-
-4.3 The Fallacy of Complex Manipulation
-
-   One strategy which may give a misleading appearance of
-   unpredictability is to take a very complex algorithm (or an excellent
-   traditional pseudo-random number generator with good statistical
-   properties) and calculate a cryptographic key by starting with the
-   current value of a computer system clock as the seed.  An adversary
-   who knew roughly when the generator was started would have a
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 8]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   relatively small number of seed values to test as they would know
-   likely values of the system clock.  Large numbers of pseudo-random
-   bits could be generated but the search space an adversary would need
-   to check could be quite small.
-
-   Thus very strong and/or complex manipulation of data will not help if
-   the adversary can learn what the manipulation is and there is not
-   enough unpredictability in the starting seed value.  Even if they can
-   not learn what the manipulation is, they may be able to use the
-   limited number of results stemming from a limited number of seed
-   values to defeat security.
-
-   Another serious strategy error is to assume that a very complex
-   pseudo-random number generation algorithm will produce strong random
-   numbers when there has been no theory behind or analysis of the
-   algorithm.  There is a excellent example of this fallacy right near
-   the beginning of chapter 3 in [KNUTH] where the author describes a
-   complex algorithm.  It was intended that the machine language program
-   corresponding to the algorithm would be so complicated that a person
-   trying to read the code without comments wouldn't know what the
-   program was doing.  Unfortunately, actual use of this algorithm
-   showed that it almost immediately converged to a single repeated
-   value in one case and a small cycle of values in another case.
-
-   Not only does complex manipulation not help you if you have a limited
-   range of seeds but blindly chosen complex manipulation can destroy
-   the randomness in a good seed!
-
-4.4 The Fallacy of Selection from a Large Database
-
-   Another strategy that can give a misleading appearance of
-   unpredictability is selection of a quantity randomly from a database
-   and assume that its strength is related to the total number of bits
-   in the database.  For example, typical USENET servers as of this date
-   process over 35 megabytes of information per day.  Assume a random
-   quantity was selected by fetching 32 bytes of data from a random
-   starting point in this data.  This does not yield 32*8 = 256 bits
-   worth of unguessability.  Even after allowing that much of the data
-   is human language and probably has more like 2 or 3 bits of
-   information per byte, it doesn't yield 32*2.5 = 80 bits of
-   unguessability.  For an adversary with access to the same 35
-   megabytes the unguessability rests only on the starting point of the
-   selection.  That is, at best, about 25 bits of unguessability in this
-   case.
-
-   The same argument applies to selecting sequences from the data on a
-   CD ROM or Audio CD recording or any other large public database.  If
-   the adversary has access to the same database, this "selection from a
-
-
-
-Eastlake, Crocker & Schiller                                    [Page 9]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   large volume of data" step buys very little.  However, if a selection
-   can be made from data to which the adversary has no access, such as
-   system buffers on an active multi-user system, it may be of some
-   help.
-
-5. Hardware for Randomness
-
-   Is there any hope for strong portable randomness in the future?
-   There might be.  All that's needed is a physical source of
-   unpredictable numbers.
-
-   A thermal noise or radioactive decay source and a fast, free-running
-   oscillator would do the trick directly [GIFFORD].  This is a trivial
-   amount of hardware, and could easily be included as a standard part
-   of a computer system's architecture.  Furthermore, any system with a
-   spinning disk or the like has an adequate source of randomness
-   [DAVIS].  All that's needed is the common perception among computer
-   vendors that this small additional hardware and the software to
-   access it is necessary and useful.
-
-5.1 Volume Required
-
-   How much unpredictability is needed?  Is it possible to quantify the
-   requirement in, say, number of random bits per second?
-
-   The answer is not very much is needed.  For DES, the key is 56 bits
-   and, as we show in an example in Section 8, even the highest security
-   system is unlikely to require a keying material of over 200 bits.  If
-   a series of keys are needed, it can be generated from a strong random
-   seed using a cryptographically strong sequence as explained in
-   Section 6.3.  A few hundred random bits generated once a day would be
-   enough using such techniques.  Even if the random bits are generated
-   as slowly as one per second and it is not possible to overlap the
-   generation process, it should be tolerable in high security
-   applications to wait 200 seconds occasionally.
-
-   These numbers are trivial to achieve.  It could be done by a person
-   repeatedly tossing a coin.  Almost any hardware process is likely to
-   be much faster.
-
-5.2 Sensitivity to Skew
-
-   Is there any specific requirement on the shape of the distribution of
-   the random numbers?  The good news is the distribution need not be
-   uniform.  All that is needed is a conservative estimate of how non-
-   uniform it is to bound performance.  Two simple techniques to de-skew
-   the bit stream are given below and stronger techniques are mentioned
-   in Section 6.1.2 below.
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 10]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-5.2.1 Using Stream Parity to De-Skew
-
-   Consider taking a sufficiently long string of bits and map the string
-   to "zero" or "one".  The mapping will not yield a perfectly uniform
-   distribution, but it can be as close as desired.  One mapping that
-   serves the purpose is to take the parity of the string.  This has the
-   advantages that it is robust across all degrees of skew up to the
-   estimated maximum skew and is absolutely trivial to implement in
-   hardware.
-
-   The following analysis gives the number of bits that must be sampled:
-
-   Suppose the ratio of ones to zeros is 0.5 + e : 0.5 - e, where e is
-   between 0 and 0.5 and is a measure of the "eccentricity" of the
-   distribution.  Consider the distribution of the parity function of N
-   bit samples.  The probabilities that the parity will be one or zero
-   will be the sum of the odd or even terms in the binomial expansion of
-   (p + q)^N, where p = 0.5 + e, the probability of a one, and q = 0.5 -
-   e, the probability of a zero.
-
-   These sums can be computed easily as
-
-                         N            N
-        1/2 * ( ( p + q )  + ( p - q )  )
-   and
-                         N            N
-        1/2 * ( ( p + q )  - ( p - q )  ).
-
-   (Which one corresponds to the probability the parity will be 1
-   depends on whether N is odd or even.)
-
-   Since p + q = 1 and p - q = 2e, these expressions reduce to
-
-                       N
-        1/2 * [1 + (2e) ]
-   and
-                       N
-        1/2 * [1 - (2e) ].
-
-   Neither of these will ever be exactly 0.5 unless e is zero, but we
-   can bring them arbitrarily close to 0.5.  If we want the
-   probabilities to be within some delta d of 0.5, i.e. then
-
-                            N
-        ( 0.5 + ( 0.5 * (2e)  ) )  <  0.5 + d.
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 11]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   Solving for N yields N > log(2d)/log(2e).  (Note that 2e is less than
-   1, so its log is negative.  Division by a negative number reverses
-   the sense of an inequality.)
-
-   The following table gives the length of the string which must be
-   sampled for various degrees of skew in order to come within 0.001 of
-   a 50/50 distribution.
-
-                       +---------+--------+-------+
-                       | Prob(1) |    e   |    N  |
-                       +---------+--------+-------+
-                       |   0.5   |  0.00  |    1  |
-                       |   0.6   |  0.10  |    4  |
-                       |   0.7   |  0.20  |    7  |
-                       |   0.8   |  0.30  |   13  |
-                       |   0.9   |  0.40  |   28  |
-                       |   0.95  |  0.45  |   59  |
-                       |   0.99  |  0.49  |  308  |
-                       +---------+--------+-------+
-
-   The last entry shows that even if the distribution is skewed 99% in
-   favor of ones, the parity of a string of 308 samples will be within
-   0.001 of a 50/50 distribution.
-
-5.2.2 Using Transition Mappings to De-Skew
-
-   Another technique, originally due to von Neumann [VON NEUMANN], is to
-   examine a bit stream as a sequence of non-overlapping pairs. You
-   could then discard any 00 or 11 pairs found, interpret 01 as a 0 and
-   10 as a 1.  Assume the probability of a 1 is 0.5+e and the
-   probability of a 0 is 0.5-e where e is the eccentricity of the source
-   and described in the previous section.  Then the probability of each
-   pair is as follows:
-
-            +------+-----------------------------------------+
-            | pair |            probability                  |
-            +------+-----------------------------------------+
-            |  00  | (0.5 - e)^2          =  0.25 - e + e^2  |
-            |  01  | (0.5 - e)*(0.5 + e)  =  0.25     - e^2  |
-            |  10  | (0.5 + e)*(0.5 - e)  =  0.25     - e^2  |
-            |  11  | (0.5 + e)^2          =  0.25 + e + e^2  |
-            +------+-----------------------------------------+
-
-   This technique will completely eliminate any bias but at the expense
-   of taking an indeterminate number of input bits for any particular
-   desired number of output bits.  The probability of any particular
-   pair being discarded is 0.5 + 2e^2 so the expected number of input
-   bits to produce X output bits is X/(0.25 - e^2).
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 12]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   This technique assumes that the bits are from a stream where each bit
-   has the same probability of being a 0 or 1 as any other bit in the
-   stream and that bits are not correlated, i.e., that the bits are
-   identical independent distributions.  If alternate bits were from two
-   correlated sources, for example, the above analysis breaks down.
-
-   The above technique also provides another illustration of how a
-   simple statistical analysis can mislead if one is not always on the
-   lookout for patterns that could be exploited by an adversary.  If the
-   algorithm were mis-read slightly so that overlapping successive bits
-   pairs were used instead of non-overlapping pairs, the statistical
-   analysis given is the same; however, instead of provided an unbiased
-   uncorrelated series of random 1's and 0's, it instead produces a
-   totally predictable sequence of exactly alternating 1's and 0's.
-
-5.2.3 Using FFT to De-Skew
-
-   When real world data consists of strongly biased or correlated bits,
-   it may still contain useful amounts of randomness.  This randomness
-   can be extracted through use of the discrete Fourier transform or its
-   optimized variant, the FFT.
-
-   Using the Fourier transform of the data, strong correlations can be
-   discarded.  If adequate data is processed and remaining correlations
-   decay, spectral lines approaching statistical independence and
-   normally distributed randomness can be produced [BRILLINGER].
-
-5.2.4 Using Compression to De-Skew
-
-   Reversible compression techniques also provide a crude method of de-
-   skewing a skewed bit stream.  This follows directly from the
-   definition of reversible compression and the formula in Section 2
-   above for the amount of information in a sequence.  Since the
-   compression is reversible, the same amount of information must be
-   present in the shorter output than was present in the longer input.
-   By the Shannon information equation, this is only possible if, on
-   average, the probabilities of the different shorter sequences are
-   more uniformly distributed than were the probabilities of the longer
-   sequences.  Thus the shorter sequences are de-skewed relative to the
-   input.
-
-   However, many compression techniques add a somewhat predicatable
-   preface to their output stream and may insert such a sequence again
-   periodically in their output or otherwise introduce subtle patterns
-   of their own.  They should be considered only a rough technique
-   compared with those described above or in Section 6.1.2.  At a
-   minimum, the beginning of the compressed sequence should be skipped
-   and only later bits used for applications requiring random bits.
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 13]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-5.3 Existing Hardware Can Be Used For Randomness
-
-   As described below, many computers come with hardware that can, with
-   care, be used to generate truly random quantities.
-
-5.3.1 Using Existing Sound/Video Input
-
-   Increasingly computers are being built with inputs that digitize some
-   real world analog source, such as sound from a microphone or video
-   input from a camera.  Under appropriate circumstances, such input can
-   provide reasonably high quality random bits.  The "input" from a
-   sound digitizer with no source plugged in or a camera with the lens
-   cap on, if the system has enough gain to detect anything, is
-   essentially thermal noise.
-
-   For example, on a SPARCstation, one can read from the /dev/audio
-   device with nothing plugged into the microphone jack.  Such data is
-   essentially random noise although it should not be trusted without
-   some checking in case of hardware failure.  It will, in any case,
-   need to be de-skewed as described elsewhere.
-
-   Combining this with compression to de-skew one can, in UNIXese,
-   generate a huge amount of medium quality random data by doing
-
-        cat /dev/audio | compress - >random-bits-file
-
-5.3.2 Using Existing Disk Drives
-
-   Disk drives have small random fluctuations in their rotational speed
-   due to chaotic air turbulence [DAVIS].  By adding low level disk seek
-   time instrumentation to a system, a series of measurements can be
-   obtained that include this randomness. Such data is usually highly
-   correlated so that significant processing is needed, including FFT
-   (see section 5.2.3).  Nevertheless experimentation has shown that,
-   with such processing, disk drives easily produce 100 bits a minute or
-   more of excellent random data.
-
-   Partly offsetting this need for processing is the fact that disk
-   drive failure will normally be rapidly noticed.  Thus, problems with
-   this method of random number generation due to hardware failure are
-   very unlikely.
-
-6. Recommended Non-Hardware Strategy
-
-   What is the best overall strategy for meeting the requirement for
-   unguessable random numbers in the absence of a reliable hardware
-   source?  It is to obtain random input from a large number of
-   uncorrelated sources and to mix them with a strong mixing function.
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 14]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   Such a function will preserve the randomness present in any of the
-   sources even if other quantities being combined are fixed or easily
-   guessable.  This may be advisable even with a good hardware source as
-   hardware can also fail, though this should be weighed against any
-   increase in the chance of overall failure due to added software
-   complexity.
-
-6.1 Mixing Functions
-
-   A strong mixing function is one which combines two or more inputs and
-   produces an output where each output bit is a different complex non-
-   linear function of all the input bits.  On average, changing any
-   input bit will change about half the output bits.  But because the
-   relationship is complex and non-linear, no particular output bit is
-   guaranteed to change when any particular input bit is changed.
-
-   Consider the problem of converting a stream of bits that is skewed
-   towards 0 or 1 to a shorter stream which is more random, as discussed
-   in Section 5.2 above.  This is simply another case where a strong
-   mixing function is desired, mixing the input bits to produce a
-   smaller number of output bits.  The technique given in Section 5.2.1
-   of using the parity of a number of bits is simply the result of
-   successively Exclusive Or'ing them which is examined as a trivial
-   mixing function immediately below.  Use of stronger mixing functions
-   to extract more of the randomness in a stream of skewed bits is
-   examined in Section 6.1.2.
-
-6.1.1 A Trivial Mixing Function
-
-   A trivial example for single bit inputs is the Exclusive Or function,
-   which is equivalent to addition without carry, as show in the table
-   below.  This is a degenerate case in which the one output bit always
-   changes for a change in either input bit.  But, despite its
-   simplicity, it will still provide a useful illustration.
-
-                   +-----------+-----------+----------+
-                   |  input 1  |  input 2  |  output  |
-                   +-----------+-----------+----------+
-                   |     0     |     0     |     0    |
-                   |     0     |     1     |     1    |
-                   |     1     |     0     |     1    |
-                   |     1     |     1     |     0    |
-                   +-----------+-----------+----------+
-
-   If inputs 1 and 2 are uncorrelated and combined in this fashion then
-   the output will be an even better (less skewed) random bit than the
-   inputs.  If we assume an "eccentricity" e as defined in Section 5.2
-   above, then the output eccentricity relates to the input eccentricity
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 15]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   as follows:
-
-        e       = 2 * e        * e
-         output        input 1    input 2
-
-   Since e is never greater than 1/2, the eccentricity is always
-   improved except in the case where at least one input is a totally
-   skewed constant.  This is illustrated in the following table where
-   the top and left side values are the two input eccentricities and the
-   entries are the output eccentricity:
-
-     +--------+--------+--------+--------+--------+--------+--------+
-     |    e   |  0.00  |  0.10  |  0.20  |  0.30  |  0.40  |  0.50  |
-     +--------+--------+--------+--------+--------+--------+--------+
-     |  0.00  |  0.00  |  0.00  |  0.00  |  0.00  |  0.00  |  0.00  |
-     |  0.10  |  0.00  |  0.02  |  0.04  |  0.06  |  0.08  |  0.10  |
-     |  0.20  |  0.00  |  0.04  |  0.08  |  0.12  |  0.16  |  0.20  |
-     |  0.30  |  0.00  |  0.06  |  0.12  |  0.18  |  0.24  |  0.30  |
-     |  0.40  |  0.00  |  0.08  |  0.16  |  0.24  |  0.32  |  0.40  |
-     |  0.50  |  0.00  |  0.10  |  0.20  |  0.30  |  0.40  |  0.50  |
-     +--------+--------+--------+--------+--------+--------+--------+
-
-   However, keep in mind that the above calculations assume that the
-   inputs are not correlated.  If the inputs were, say, the parity of
-   the number of minutes from midnight on two clocks accurate to a few
-   seconds, then each might appear random if sampled at random intervals
-   much longer than a minute.  Yet if they were both sampled and
-   combined with xor, the result would be zero most of the time.
-
-6.1.2 Stronger Mixing Functions
-
-   The US Government Data Encryption Standard [DES] is an example of a
-   strong mixing function for multiple bit quantities.  It takes up to
-   120 bits of input (64 bits of "data" and 56 bits of "key") and
-   produces 64 bits of output each of which is dependent on a complex
-   non-linear function of all input bits.  Other strong encryption
-   functions with this characteristic can also be used by considering
-   them to mix all of their key and data input bits.
-
-   Another good family of mixing functions are the "message digest" or
-   hashing functions such as The US Government Secure Hash Standard
-   [SHS] and the MD2, MD4, MD5 [MD2, MD4, MD5] series.  These functions
-   all take an arbitrary amount of input and produce an output mixing
-   all the input bits. The MD* series produce 128 bits of output and SHS
-   produces 160 bits.
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 16]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   Although the message digest functions are designed for variable
-   amounts of input, DES and other encryption functions can also be used
-   to combine any number of inputs.  If 64 bits of output is adequate,
-   the inputs can be packed into a 64 bit data quantity and successive
-   56 bit keys, padding with zeros if needed, which are then used to
-   successively encrypt using DES in Electronic Codebook Mode [DES
-   MODES].  If more than 64 bits of output are needed, use more complex
-   mixing.  For example, if inputs are packed into three quantities, A,
-   B, and C, use DES to encrypt A with B as a key and then with C as a
-   key to produce the 1st part of the output, then encrypt B with C and
-   then A for more output and, if necessary, encrypt C with A and then B
-   for yet more output.  Still more output can be produced by reversing
-   the order of the keys given above to stretch things. The same can be
-   done with the hash functions by hashing various subsets of the input
-   data to produce multiple outputs.  But keep in mind that it is
-   impossible to get more bits of "randomness" out than are put in.
-
-   An example of using a strong mixing function would be to reconsider
-   the case of a string of 308 bits each of which is biased 99% towards
-   zero.  The parity technique given in Section 5.2.1 above reduced this
-   to one bit with only a 1/1000 deviance from being equally likely a
-   zero or one.  But, applying the equation for information given in
-   Section 2, this 308 bit sequence has 5 bits of information in it.
-   Thus hashing it with SHS or MD5 and taking the bottom 5 bits of the
-   result would yield 5 unbiased random bits as opposed to the single
-   bit given by calculating the parity of the string.
-
-6.1.3 Diffie-Hellman as a Mixing Function
-
-   Diffie-Hellman exponential key exchange is a technique that yields a
-   shared secret between two parties that can be made computationally
-   infeasible for a third party to determine even if they can observe
-   all the messages between the two communicating parties.  This shared
-   secret is a mixture of initial quantities generated by each of them
-   [D-H].  If these initial quantities are random, then the shared
-   secret contains the combined randomness of them both, assuming they
-   are uncorrelated.
-
-6.1.4 Using a Mixing Function to Stretch Random Bits
-
-   While it is not necessary for a mixing function to produce the same
-   or fewer bits than its inputs, mixing bits cannot "stretch" the
-   amount of random unpredictability present in the inputs.  Thus four
-   inputs of 32 bits each where there is 12 bits worth of
-   unpredicatability (such as 4,096 equally probable values) in each
-   input cannot produce more than 48 bits worth of unpredictable output.
-   The output can be expanded to hundreds or thousands of bits by, for
-   example, mixing with successive integers, but the clever adversary's
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 17]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   search space is still 2^48 possibilities.  Furthermore, mixing to
-   fewer bits than are input will tend to strengthen the randomness of
-   the output the way using Exclusive Or to produce one bit from two did
-   above.
-
-   The last table in Section 6.1.1 shows that mixing a random bit with a
-   constant bit with Exclusive Or will produce a random bit.  While this
-   is true, it does not provide a way to "stretch" one random bit into
-   more than one.  If, for example, a random bit is mixed with a 0 and
-   then with a 1, this produces a two bit sequence but it will always be
-   either 01 or 10.  Since there are only two possible values, there is
-   still only the one bit of original randomness.
-
-6.1.5 Other Factors in Choosing a Mixing Function
-
-   For local use, DES has the advantages that it has been widely tested
-   for flaws, is widely documented, and is widely implemented with
-   hardware and software implementations available all over the world
-   including source code available by anonymous FTP.  The SHS and MD*
-   family are younger algorithms which have been less tested but there
-   is no particular reason to believe they are flawed.  Both MD5 and SHS
-   were derived from the earlier MD4 algorithm.  They all have source
-   code available by anonymous FTP [SHS, MD2, MD4, MD5].
-
-   DES and SHS have been vouched for the the US National Security Agency
-   (NSA) on the basis of criteria that primarily remain secret.  While
-   this is the cause of much speculation and doubt, investigation of DES
-   over the years has indicated that NSA involvement in modifications to
-   its design, which originated with IBM, was primarily to strengthen
-   it.  No concealed or special weakness has been found in DES.  It is
-   almost certain that the NSA modification to MD4 to produce the SHS
-   similarly strengthened the algorithm, possibly against threats not
-   yet known in the public cryptographic community.
-
-   DES, SHS, MD4, and MD5 are royalty free for all purposes.  MD2 has
-   been freely licensed only for non-profit use in connection with
-   Privacy Enhanced Mail [PEM].  Between the MD* algorithms, some people
-   believe that, as with "Goldilocks and the Three Bears", MD2 is strong
-   but too slow, MD4 is fast but too weak, and MD5 is just right.
-
-   Another advantage of the MD* or similar hashing algorithms over
-   encryption algorithms is that they are not subject to the same
-   regulations imposed by the US Government prohibiting the unlicensed
-   export or import of encryption/decryption software and hardware.  The
-   same should be true of DES rigged to produce an irreversible hash
-   code but most DES packages are oriented to reversible encryption.
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 18]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-6.2 Non-Hardware Sources of Randomness
-
-   The best source of input for mixing would be a hardware randomness
-   such as disk drive timing affected by air turbulence, audio input
-   with thermal noise, or radioactive decay.  However, if that is not
-   available there are other possibilities.  These include system
-   clocks, system or input/output buffers, user/system/hardware/network
-   serial numbers and/or addresses and timing, and user input.
-   Unfortunately, any of these sources can produce limited or
-   predicatable values under some circumstances.
-
-   Some of the sources listed above would be quite strong on multi-user
-   systems where, in essence, each user of the system is a source of
-   randomness.  However, on a small single user system, such as a
-   typical IBM PC or Apple Macintosh, it might be possible for an
-   adversary to assemble a similar configuration.  This could give the
-   adversary inputs to the mixing process that were sufficiently
-   correlated to those used originally as to make exhaustive search
-   practical.
-
-   The use of multiple random inputs with a strong mixing function is
-   recommended and can overcome weakness in any particular input.  For
-   example, the timing and content of requested "random" user keystrokes
-   can yield hundreds of random bits but conservative assumptions need
-   to be made.  For example, assuming a few bits of randomness if the
-   inter-keystroke interval is unique in the sequence up to that point
-   and a similar assumption if the key hit is unique but assuming that
-   no bits of randomness are present in the initial key value or if the
-   timing or key value duplicate previous values.  The results of mixing
-   these timings and characters typed could be further combined with
-   clock values and other inputs.
-
-   This strategy may make practical portable code to produce good random
-   numbers for security even if some of the inputs are very weak on some
-   of the target systems.  However, it may still fail against a high
-   grade attack on small single user systems, especially if the
-   adversary has ever been able to observe the generation process in the
-   past.  A hardware based random source is still preferable.
-
-6.3 Cryptographically Strong Sequences
-
-   In cases where a series of random quantities must be generated, an
-   adversary may learn some values in the sequence.  In general, they
-   should not be able to predict other values from the ones that they
-   know.
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 19]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   The correct technique is to start with a strong random seed, take
-   cryptographically strong steps from that seed [CRYPTO2, CRYPTO3], and
-   do not reveal the complete state of the generator in the sequence
-   elements.  If each value in the sequence can be calculated in a fixed
-   way from the previous value, then when any value is compromised, all
-   future values can be determined.  This would be the case, for
-   example, if each value were a constant function of the previously
-   used values, even if the function were a very strong, non-invertible
-   message digest function.
-
-   It should be noted that if your technique for generating a sequence
-   of key values is fast enough, it can trivially be used as the basis
-   for a confidentiality system.  If two parties use the same sequence
-   generating technique and start with the same seed material, they will
-   generate identical sequences.  These could, for example, be xor'ed at
-   one end with data being send, encrypting it, and xor'ed with this
-   data as received, decrypting it due to the reversible properties of
-   the xor operation.
-
-6.3.1 Traditional Strong Sequences
-
-   A traditional way to achieve a strong sequence has been to have the
-   values be produced by hashing the quantities produced by
-   concatenating the seed with successive integers or the like and then
-   mask the values obtained so as to limit the amount of generator state
-   available to the adversary.
-
-   It may also be possible to use an "encryption" algorithm with a
-   random key and seed value to encrypt and feedback some or all of the
-   output encrypted value into the value to be encrypted for the next
-   iteration.  Appropriate feedback techniques will usually be
-   recommended with the encryption algorithm.  An example is shown below
-   where shifting and masking are used to combine the cypher output
-   feedback.  This type of feedback is recommended by the US Government
-   in connection with DES [DES MODES].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 20]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-      +---------------+
-      |       V       |
-      |  |     n      |
-      +--+------------+
-            |      |           +---------+
-            |      +---------> |         |      +-----+
-         +--+                  | Encrypt | <--- | Key |
-         |           +-------- |         |      +-----+
-         |           |         +---------+
-         V           V
-      +------------+--+
-      |      V     |  |
-      |       n+1     |
-      +---------------+
-
-   Note that if a shift of one is used, this is the same as the shift
-   register technique described in Section 3 above but with the all
-   important difference that the feedback is determined by a complex
-   non-linear function of all bits rather than a simple linear or
-   polynomial combination of output from a few bit position taps.
-
-   It has been shown by Donald W. Davies that this sort of shifted
-   partial output feedback significantly weakens an algorithm compared
-   will feeding all of the output bits back as input.  In particular,
-   for DES, repeated encrypting a full 64 bit quantity will give an
-   expected repeat in about 2^63 iterations.  Feeding back anything less
-   than 64 (and more than 0) bits will give an expected repeat in
-   between 2**31 and 2**32 iterations!
-
-   To predict values of a sequence from others when the sequence was
-   generated by these techniques is equivalent to breaking the
-   cryptosystem or inverting the "non-invertible" hashing involved with
-   only partial information available.  The less information revealed
-   each iteration, the harder it will be for an adversary to predict the
-   sequence.  Thus it is best to use only one bit from each value.  It
-   has been shown that in some cases this makes it impossible to break a
-   system even when the cryptographic system is invertible and can be
-   broken if all of each generated value was revealed.
-
-6.3.2 The Blum Blum Shub Sequence Generator
-
-   Currently the generator which has the strongest public proof of
-   strength is called the Blum Blum Shub generator after its inventors
-   [BBS].  It is also very simple and is based on quadratic residues.
-   It's only disadvantage is that is is computationally intensive
-   compared with the traditional techniques give in 6.3.1 above.  This
-   is not a serious draw back if it is used for moderately infrequent
-   purposes, such as generating session keys.
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 21]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   Simply choose two large prime numbers, say p and q, which both have
-   the property that you get a remainder of 3 if you divide them by 4.
-   Let n = p * q.  Then you choose a random number x relatively prime to
-   n.  The initial seed for the generator and the method for calculating
-   subsequent values are then
-
-                   2
-        s    =  ( x  )(Mod n)
-         0
-
-                   2
-        s    = ( s   )(Mod n)
-         i+1      i
-
-   You must be careful to use only a few bits from the bottom of each s.
-   It is always safe to use only the lowest order bit.  If you use no
-   more than the
-
-                  log  ( log  ( s  ) )
-                     2      2    i
-
-   low order bits, then predicting any additional bits from a sequence
-   generated in this manner is provable as hard as factoring n.  As long
-   as the initial x is secret, you can even make n public if you want.
-
-   An intersting characteristic of this generator is that you can
-   directly calculate any of the s values.  In particular
-
-                     i
-               ( ( 2  )(Mod (( p - 1 ) * ( q - 1 )) ) )
-      s  = ( s                                          )(Mod n)
-       i      0
-
-   This means that in applications where many keys are generated in this
-   fashion, it is not necessary to save them all.  Each key can be
-   effectively indexed and recovered from that small index and the
-   initial s and n.
-
-7. Key Generation Standards
-
-   Several public standards are now in place for the generation of keys.
-   Two of these are described below.  Both use DES but any equally
-   strong or stronger mixing function could be substituted.
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 22]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-7.1 US DoD Recommendations for Password Generation
-
-   The United States Department of Defense has specific recommendations
-   for password generation [DoD].  They suggest using the US Data
-   Encryption Standard [DES] in Output Feedback Mode [DES MODES] as
-   follows:
-
-        use an initialization vector determined from
-             the system clock,
-             system ID,
-             user ID, and
-             date and time;
-        use a key determined from
-             system interrupt registers,
-             system status registers, and
-             system counters; and,
-        as plain text, use an external randomly generated 64 bit
-        quantity such as 8 characters typed in by a system
-        administrator.
-
-   The password can then be calculated from the 64 bit "cipher text"
-   generated in 64-bit Output Feedback Mode.  As many bits as are needed
-   can be taken from these 64 bits and expanded into a pronounceable
-   word, phrase, or other format if a human being needs to remember the
-   password.
-
-7.2 X9.17 Key Generation
-
-   The American National Standards Institute has specified a method for
-   generating a sequence of keys as follows:
-
-        s  is the initial 64 bit seed
-         0
-
-        g  is the sequence of generated 64 bit key quantities
-         n
-
-        k is a random key reserved for generating this key sequence
-
-        t is the time at which a key is generated to as fine a resolution
-            as is available (up to 64 bits).
-
-        DES ( K, Q ) is the DES encryption of quantity Q with key K
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 23]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-        g    = DES ( k, DES ( k, t ) .xor. s  )
-         n                                  n
-
-        s    = DES ( k, DES ( k, t ) .xor. g  )
-         n+1                                n
-
-   If g sub n is to be used as a DES key, then every eighth bit should
-   be adjusted for parity for that use but the entire 64 bit unmodified
-   g should be used in calculating the next s.
-
-8. Examples of Randomness Required
-
-   Below are two examples showing rough calculations of needed
-   randomness for security.  The first is for moderate security
-   passwords while the second assumes a need for a very high security
-   cryptographic key.
-
-8.1  Password Generation
-
-   Assume that user passwords change once a year and it is desired that
-   the probability that an adversary could guess the password for a
-   particular account be less than one in a thousand.  Further assume
-   that sending a password to the system is the only way to try a
-   password.  Then the crucial question is how often an adversary can
-   try possibilities.  Assume that delays have been introduced into a
-   system so that, at most, an adversary can make one password try every
-   six seconds.  That's 600 per hour or about 15,000 per day or about
-   5,000,000 tries in a year.  Assuming any sort of monitoring, it is
-   unlikely someone could actually try continuously for a year.  In
-   fact, even if log files are only checked monthly, 500,000 tries is
-   more plausible before the attack is noticed and steps taken to change
-   passwords and make it harder to try more passwords.
-
-   To have a one in a thousand chance of guessing the password in
-   500,000 tries implies a universe of at least 500,000,000 passwords or
-   about 2^29.  Thus 29 bits of randomness are needed. This can probably
-   be achieved using the US DoD recommended inputs for password
-   generation as it has 8 inputs which probably average over 5 bits of
-   randomness each (see section 7.1).  Using a list of 1000 words, the
-   password could be expressed as a three word phrase (1,000,000,000
-   possibilities) or, using case insensitive letters and digits, six
-   would suffice ((26+10)^6 = 2,176,782,336 possibilities).
-
-   For a higher security password, the number of bits required goes up.
-   To decrease the probability by 1,000 requires increasing the universe
-   of passwords by the same factor which adds about 10 bits.  Thus to
-   have only a one in a million chance of a password being guessed under
-   the above scenario would require 39 bits of randomness and a password
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 24]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   that was a four word phrase from a 1000 word list or eight
-   letters/digits.  To go to a one in 10^9 chance, 49 bits of randomness
-   are needed implying a five word phrase or ten letter/digit password.
-
-   In a real system, of course, there are also other factors.  For
-   example, the larger and harder to remember passwords are, the more
-   likely users are to write them down resulting in an additional risk
-   of compromise.
-
-8.2 A Very High Security Cryptographic Key
-
-   Assume that a very high security key is needed for symmetric
-   encryption / decryption between two parties.  Assume an adversary can
-   observe communications and knows the algorithm being used.  Within
-   the field of random possibilities, the adversary can try key values
-   in hopes of finding the one in use.  Assume further that brute force
-   trial of keys is the best the adversary can do.
-
-8.2.1 Effort per Key Trial
-
-   How much effort will it take to try each key?  For very high security
-   applications it is best to assume a low value of effort.  Even if it
-   would clearly take tens of thousands of computer cycles or more to
-   try a single key, there may be some pattern that enables huge blocks
-   of key values to be tested with much less effort per key.  Thus it is
-   probably best to assume no more than a couple hundred cycles per key.
-   (There is no clear lower bound on this as computers operate in
-   parallel on a number of bits and a poor encryption algorithm could
-   allow many keys or even groups of keys to be tested in parallel.
-   However, we need to assume some value and can hope that a reasonably
-   strong algorithm has been chosen for our hypothetical high security
-   task.)
-
-   If the adversary can command a highly parallel processor or a large
-   network of work stations, 2*10^10 cycles per second is probably a
-   minimum assumption for availability today.  Looking forward just a
-   couple years, there should be at least an order of magnitude
-   improvement.  Thus assuming 10^9 keys could be checked per second or
-   3.6*10^11 per hour or 6*10^13 per week or 2.4*10^14 per month is
-   reasonable.  This implies a need for a minimum of 51 bits of
-   randomness in keys to be sure they cannot be found in a month.  Even
-   then it is possible that, a few years from now, a highly determined
-   and resourceful adversary could break the key in 2 weeks (on average
-   they need try only half the keys).
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 25]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-8.2.2 Meet in the Middle Attacks
-
-   If chosen or known plain text and the resulting encrypted text are
-   available, a "meet in the middle" attack is possible if the structure
-   of the encryption algorithm allows it.  (In a known plain text
-   attack, the adversary knows all or part of the messages being
-   encrypted, possibly some standard header or trailer fields.  In a
-   chosen plain text attack, the adversary can force some chosen plain
-   text to be encrypted, possibly by "leaking" an exciting text that
-   would then be sent by the adversary over an encrypted channel.)
-
-   An oversimplified explanation of the meet in the middle attack is as
-   follows: the adversary can half-encrypt the known or chosen plain
-   text with all possible first half-keys, sort the output, then half-
-   decrypt the encoded text with all the second half-keys.  If a match
-   is found, the full key can be assembled from the halves and used to
-   decrypt other parts of the message or other messages.  At its best,
-   this type of attack can halve the exponent of the work required by
-   the adversary while adding a large but roughly constant factor of
-   effort.  To be assured of safety against this, a doubling of the
-   amount of randomness in the key to a minimum of 102 bits is required.
-
-   The meet in the middle attack assumes that the cryptographic
-   algorithm can be decomposed in this way but we can not rule that out
-   without a deep knowledge of the algorithm.  Even if a basic algorithm
-   is not subject to a meet in the middle attack, an attempt to produce
-   a stronger algorithm by applying the basic algorithm twice (or two
-   different algorithms sequentially) with different keys may gain less
-   added security than would be expected.  Such a composite algorithm
-   would be subject to a meet in the middle attack.
-
-   Enormous resources may be required to mount a meet in the middle
-   attack but they are probably within the range of the national
-   security services of a major nation.  Essentially all nations spy on
-   other nations government traffic and several nations are believed to
-   spy on commercial traffic for economic advantage.
-
-8.2.3 Other Considerations
-
-   Since we have not even considered the possibilities of special
-   purpose code breaking hardware or just how much of a safety margin we
-   want beyond our assumptions above, probably a good minimum for a very
-   high security cryptographic key is 128 bits of randomness which
-   implies a minimum key length of 128 bits.  If the two parties agree
-   on a key by Diffie-Hellman exchange [D-H], then in principle only
-   half of this randomness would have to be supplied by each party.
-   However, there is probably some correlation between their random
-   inputs so it is probably best to assume that each party needs to
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 26]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   provide at least 96 bits worth of randomness for very high security
-   if Diffie-Hellman is used.
-
-   This amount of randomness is beyond the limit of that in the inputs
-   recommended by the US DoD for password generation and could require
-   user typing timing, hardware random number generation, or other
-   sources.
-
-   It should be noted that key length calculations such at those above
-   are controversial and depend on various assumptions about the
-   cryptographic algorithms in use.  In some cases, a professional with
-   a deep knowledge of code breaking techniques and of the strength of
-   the algorithm in use could be satisfied with less than half of the
-   key size derived above.
-
-9. Conclusion
-
-   Generation of unguessable "random" secret quantities for security use
-   is an essential but difficult task.
-
-   We have shown that hardware techniques to produce such randomness
-   would be relatively simple.  In particular, the volume and quality
-   would not need to be high and existing computer hardware, such as
-   disk drives, can be used.  Computational techniques are available to
-   process low quality random quantities from multiple sources or a
-   larger quantity of such low quality input from one source and produce
-   a smaller quantity of higher quality, less predictable key material.
-   In the absence of hardware sources of randomness, a variety of user
-   and software sources can frequently be used instead with care;
-   however, most modern systems already have hardware, such as disk
-   drives or audio input, that could be used to produce high quality
-   randomness.
-
-   Once a sufficient quantity of high quality seed key material (a few
-   hundred bits) is available, strong computational techniques are
-   available to produce cryptographically strong sequences of
-   unpredicatable quantities from this seed material.
-
-10. Security Considerations
-
-   The entirety of this document concerns techniques and recommendations
-   for generating unguessable "random" quantities for use as passwords,
-   cryptographic keys, and similar security uses.
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 27]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-References
-
-   [ASYMMETRIC] - Secure Communications and Asymmetric Cryptosystems,
-   edited by Gustavus J. Simmons, AAAS Selected Symposium 69, Westview
-   Press, Inc.
-
-   [BBS] - A Simple Unpredictable Pseudo-Random Number Generator, SIAM
-   Journal on Computing, v. 15, n. 2, 1986, L. Blum, M. Blum, & M. Shub.
-
-   [BRILLINGER] - Time Series: Data Analysis and Theory, Holden-Day,
-   1981, David Brillinger.
-
-   [CRC] - C.R.C. Standard Mathematical Tables, Chemical Rubber
-   Publishing Company.
-
-   [CRYPTO1] - Cryptography: A Primer, A Wiley-Interscience Publication,
-   John Wiley & Sons, 1981, Alan G. Konheim.
-
-   [CRYPTO2] - Cryptography:  A New Dimension in Computer Data Security,
-   A Wiley-Interscience Publication, John Wiley & Sons, 1982, Carl H.
-   Meyer & Stephen M. Matyas.
-
-   [CRYPTO3] - Applied Cryptography: Protocols, Algorithms, and Source
-   Code in C, John Wiley & Sons, 1994, Bruce Schneier.
-
-   [DAVIS] - Cryptographic Randomness from Air Turbulence in Disk
-   Drives, Advances in Cryptology - Crypto '94, Springer-Verlag Lecture
-   Notes in Computer Science #839, 1984, Don Davis, Ross Ihaka, and
-   Philip Fenstermacher.
-
-   [DES] -  Data Encryption Standard, United States of America,
-   Department of Commerce, National Institute of Standards and
-   Technology, Federal Information Processing Standard (FIPS) 46-1.
-   - Data Encryption Algorithm, American National Standards Institute,
-   ANSI X3.92-1981.
-   (See also FIPS 112, Password Usage, which includes FORTRAN code for
-   performing DES.)
-
-   [DES MODES] - DES Modes of Operation, United States of America,
-   Department of Commerce, National Institute of Standards and
-   Technology, Federal Information Processing Standard (FIPS) 81.
-   - Data Encryption Algorithm - Modes of Operation, American National
-   Standards Institute, ANSI X3.106-1983.
-
-   [D-H] - New Directions in Cryptography, IEEE Transactions on
-   Information Technology, November, 1976, Whitfield Diffie and Martin
-   E. Hellman.
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 28]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   [DoD] - Password Management Guideline, United States of America,
-   Department of Defense, Computer Security Center, CSC-STD-002-85.
-   (See also FIPS 112, Password Usage, which incorporates CSC-STD-002-85
-   as one of its appendices.)
-
-   [GIFFORD] - Natural Random Number, MIT/LCS/TM-371, September 1988,
-   David K. Gifford
-
-   [KNUTH] - The Art of Computer Programming, Volume 2: Seminumerical
-   Algorithms, Chapter 3: Random Numbers. Addison Wesley Publishing
-   Company, Second Edition 1982, Donald E. Knuth.
-
-   [KRAWCZYK] - How to Predict Congruential Generators, Journal of
-   Algorithms, V. 13, N. 4, December 1992, H. Krawczyk
-
-   [MD2] - The MD2 Message-Digest Algorithm, RFC1319, April 1992, B.
-   Kaliski
-   [MD4] - The MD4 Message-Digest Algorithm, RFC1320, April 1992, R.
-   Rivest
-   [MD5] - The MD5 Message-Digest Algorithm, RFC1321, April 1992, R.
-   Rivest
-
-   [PEM] - RFCs 1421 through 1424:
-   - RFC 1424, Privacy Enhancement for Internet Electronic Mail: Part
-   IV: Key Certification and Related Services, 02/10/1993, B. Kaliski
-   - RFC 1423, Privacy Enhancement for Internet Electronic Mail: Part
-   III: Algorithms, Modes, and Identifiers, 02/10/1993, D. Balenson
-   - RFC 1422, Privacy Enhancement for Internet Electronic Mail: Part
-   II: Certificate-Based Key Management, 02/10/1993, S. Kent
-   - RFC 1421, Privacy Enhancement for Internet Electronic Mail: Part I:
-   Message Encryption and Authentication Procedures, 02/10/1993, J. Linn
-
-   [SHANNON] - The Mathematical Theory of Communication, University of
-   Illinois Press, 1963, Claude E. Shannon.  (originally from:  Bell
-   System Technical Journal, July and October 1948)
-
-   [SHIFT1] - Shift Register Sequences, Aegean Park Press, Revised
-   Edition 1982, Solomon W. Golomb.
-
-   [SHIFT2] - Cryptanalysis of Shift-Register Generated Stream Cypher
-   Systems, Aegean Park Press, 1984, Wayne G. Barker.
-
-   [SHS] - Secure Hash Standard, United States of American, National
-   Institute of Science and Technology, Federal Information Processing
-   Standard (FIPS) 180, April 1993.
-
-   [STERN] - Secret Linear Congruential Generators are not
-   Cryptograhically Secure, Proceedings of IEEE STOC, 1987, J. Stern.
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 29]
-
-RFC 1750        Randomness Recommendations for Security    December 1994
-
-
-   [VON NEUMANN] - Various techniques used in connection with random
-   digits, von Neumann's Collected Works, Vol. 5, Pergamon Press, 1963,
-   J. von Neumann.
-
-Authors' Addresses
-
-   Donald E. Eastlake 3rd
-   Digital Equipment Corporation
-   550 King Street, LKG2-1/BB3
-   Littleton, MA 01460
-
-   Phone:   +1 508 486 6577(w)  +1 508 287 4877(h)
-   EMail:   dee@lkg.dec.com
-
-
-   Stephen D. Crocker
-   CyberCash Inc.
-   2086 Hunters Crest Way
-   Vienna, VA 22181
-
-   Phone:   +1 703-620-1222(w)  +1 703-391-2651 (fax)
-   EMail:   crocker@cybercash.com
-
-
-   Jeffrey I. Schiller
-   Massachusetts Institute of Technology
-   77 Massachusetts Avenue
-   Cambridge, MA 02139
-
-   Phone:   +1 617 253 0161(w)
-   EMail:   jis@mit.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, Crocker & Schiller                                   [Page 30]
-
diff --git a/contrib/bind9/doc/rfc/rfc1876.txt b/contrib/bind9/doc/rfc/rfc1876.txt
deleted file mode 100644
index a289cff..0000000
--- a/contrib/bind9/doc/rfc/rfc1876.txt
+++ /dev/null
@@ -1,1011 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           C. Davis
-Request for Comments: 1876                             Kapor Enterprises
-Updates: 1034, 1035                                             P. Vixie
-Category: Experimental                                 Vixie Enterprises
-                                                              T. Goodwin
-                                                            FORE Systems
-                                                            I. Dickinson
-                                                   University of Warwick
-                                                            January 1996
-
-
- A Means for Expressing Location Information in the Domain Name System
-
-Status of this Memo
-
-   This memo defines an Experimental Protocol for the Internet
-   community.  This memo does not specify an Internet standard of any
-   kind.  Discussion and suggestions for improvement are requested.
-   Distribution of this memo is unlimited.
-
-1. Abstract
-
-   This memo defines a new DNS RR type for experimental purposes.  This
-   RFC describes a mechanism to allow the DNS to carry location
-   information about hosts, networks, and subnets.  Such information for
-   a small subset of hosts is currently contained in the flat-file UUCP
-   maps.  However, just as the DNS replaced the use of HOSTS.TXT to
-   carry host and network address information, it is possible to replace
-   the UUCP maps as carriers of location information.
-
-   This RFC defines the format of a new Resource Record (RR) for the
-   Domain Name System (DNS), and reserves a corresponding DNS type
-   mnemonic (LOC) and numerical code (29).
-
-   This RFC assumes that the reader is familiar with the DNS [RFC 1034,
-   RFC 1035].  The data shown in our examples is for pedagogical use and
-   does not necessarily reflect the real Internet.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Davis, et al                  Experimental                      [Page 1]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-2. RDATA Format
-
-       MSB                                           LSB
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      0|        VERSION        |         SIZE          |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      2|       HORIZ PRE       |       VERT PRE        |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      4|                   LATITUDE                    |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      6|                   LATITUDE                    |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      8|                   LONGITUDE                   |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-     10|                   LONGITUDE                   |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-     12|                   ALTITUDE                    |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-     14|                   ALTITUDE                    |
-       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-   (octet)
-
-where:
-
-VERSION      Version number of the representation.  This must be zero.
-             Implementations are required to check this field and make
-             no assumptions about the format of unrecognized versions.
-
-SIZE         The diameter of a sphere enclosing the described entity, in
-             centimeters, expressed as a pair of four-bit unsigned
-             integers, each ranging from zero to nine, with the most
-             significant four bits representing the base and the second
-             number representing the power of ten by which to multiply
-             the base.  This allows sizes from 0e0 (<1cm) to 9e9
-             (90,000km) to be expressed.  This representation was chosen
-             such that the hexadecimal representation can be read by
-             eye; 0x15 = 1e5.  Four-bit values greater than 9 are
-             undefined, as are values with a base of zero and a non-zero
-             exponent.
-
-             Since 20000000m (represented by the value 0x29) is greater
-             than the equatorial diameter of the WGS 84 ellipsoid
-             (12756274m), it is therefore suitable for use as a
-             "worldwide" size.
-
-HORIZ PRE    The horizontal precision of the data, in centimeters,
-             expressed using the same representation as SIZE.  This is
-             the diameter of the horizontal "circle of error", rather
-
-
-
-Davis, et al                  Experimental                      [Page 2]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-             than a "plus or minus" value.  (This was chosen to match
-             the interpretation of SIZE; to get a "plus or minus" value,
-             divide by 2.)
-
-VERT PRE     The vertical precision of the data, in centimeters,
-             expressed using the sane representation as for SIZE.  This
-             is the total potential vertical error, rather than a "plus
-             or minus" value.  (This was chosen to match the
-             interpretation of SIZE; to get a "plus or minus" value,
-             divide by 2.)  Note that if altitude above or below sea
-             level is used as an approximation for altitude relative to
-             the [WGS 84] ellipsoid, the precision value should be
-             adjusted.
-
-LATITUDE     The latitude of the center of the sphere described by the
-             SIZE field, expressed as a 32-bit integer, most significant
-             octet first (network standard byte order), in thousandths
-             of a second of arc.  2^31 represents the equator; numbers
-             above that are north latitude.
-
-LONGITUDE    The longitude of the center of the sphere described by the
-             SIZE field, expressed as a 32-bit integer, most significant
-             octet first (network standard byte order), in thousandths
-             of a second of arc, rounded away from the prime meridian.
-             2^31 represents the prime meridian; numbers above that are
-             east longitude.
-
-ALTITUDE     The altitude of the center of the sphere described by the
-             SIZE field, expressed as a 32-bit integer, most significant
-             octet first (network standard byte order), in centimeters,
-             from a base of 100,000m below the [WGS 84] reference
-             spheroid used by GPS (semimajor axis a=6378137.0,
-             reciprocal flattening rf=298.257223563).  Altitude above
-             (or below) sea level may be used as an approximation of
-             altitude relative to the the [WGS 84] spheroid, though due
-             to the Earth's surface not being a perfect spheroid, there
-             will be differences.  (For example, the geoid (which sea
-             level approximates) for the continental US ranges from 10
-             meters to 50 meters below the [WGS 84] spheroid.
-             Adjustments to ALTITUDE and/or VERT PRE will be necessary
-             in most cases.  The Defense Mapping Agency publishes geoid
-             height values relative to the [WGS 84] ellipsoid.
-
-
-
-
-
-
-
-
-
-Davis, et al                  Experimental                      [Page 3]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-3. Master File Format
-
-   The LOC record is expressed in a master file in the following format:
-
-   <owner> <TTL> <class> LOC ( d1 [m1 [s1]] {"N"|"S"} d2 [m2 [s2]]
-                               {"E"|"W"} alt["m"] [siz["m"] [hp["m"]
-                               [vp["m"]]]] )
-
-   (The parentheses are used for multi-line data as specified in [RFC
-   1035] section 5.1.)
-
-   where:
-
-       d1:     [0 .. 90]            (degrees latitude)
-       d2:     [0 .. 180]           (degrees longitude)
-       m1, m2: [0 .. 59]            (minutes latitude/longitude)
-       s1, s2: [0 .. 59.999]        (seconds latitude/longitude)
-       alt:    [-100000.00 .. 42849672.95] BY .01 (altitude in meters)
-       siz, hp, vp: [0 .. 90000000.00] (size/precision in meters)
-
-   If omitted, minutes and seconds default to zero, size defaults to 1m,
-   horizontal precision defaults to 10000m, and vertical precision
-   defaults to 10m.  These defaults are chosen to represent typical
-   ZIP/postal code area sizes, since it is often easy to find
-   approximate geographical location by ZIP/postal code.
-
-4. Example Data
-
-;;;
-;;; note that these data would not all appear in one zone file
-;;;
-
-;; network LOC RR derived from ZIP data.  note use of precision defaults
-cambridge-net.kei.com.        LOC   42 21 54 N 71 06 18 W -24m 30m
-
-;; higher-precision host LOC RR.  note use of vertical precision default
-loiosh.kei.com.               LOC   42 21 43.952 N 71 5 6.344 W
-                                    -24m 1m 200m
-
-pipex.net.                    LOC   52 14 05 N 00 08 50 E 10m
-
-curtin.edu.au.                LOC   32 7 19 S 116 2 25 E 10m
-
-rwy04L.logan-airport.boston.  LOC   42 21 28.764 N 71 00 51.617 W
-                                    -44m 2000m
-
-
-
-
-
-
-Davis, et al                  Experimental                      [Page 4]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-5. Application use of the LOC RR
-
-5.1 Suggested Uses
-
-   Some uses for the LOC RR have already been suggested, including the
-   USENET backbone flow maps, a "visual traceroute" application showing
-   the geographical path of an IP packet, and network management
-   applications that could use LOC RRs to generate a map of hosts and
-   routers being managed.
-
-5.2 Search Algorithms
-
-   This section specifies how to use the DNS to translate domain names
-   and/or IP addresses into location information.
-
-   If an application wishes to have a "fallback" behavior, displaying a
-   less precise or larger area when a host does not have an associated
-   LOC RR, it MAY support use of the algorithm in section 5.2.3, as
-   noted in sections 5.2.1 and 5.2.2.  If fallback is desired, this
-   behaviour is the RECOMMENDED default, but in some cases it may need
-   to be modified based on the specific requirements of the application
-   involved.
-
-   This search algorithm is designed to allow network administrators to
-   specify the location of a network or subnet without requiring LOC RR
-   data for each individual host.  For example, a computer lab with 24
-   workstations, all of which are on the same subnet and in basically
-   the same location, would only need a LOC RR for the subnet.
-   (However, if the file server's location has been more precisely
-   measured, a separate LOC RR for it can be placed in the DNS.)
-
-5.2.1 Searching by Name
-
-   If the application is beginning with a name, rather than an IP
-   address (as the USENET backbone flow maps do), it MUST check for a
-   LOC RR associated with that name.  (CNAME records should be followed
-   as for any other RR type.)
-
-   If there is no LOC RR for that name, all A records (if any)
-   associated with the name MAY be checked for network (or subnet) LOC
-   RRs using the "Searching by Network or Subnet" algorithm (5.2.3).  If
-   multiple A records exist and have associated network or subnet LOC
-   RRs, the application may choose to use any, some, or all of the LOC
-   RRs found, possibly in combination.  It is suggested that multi-homed
-   hosts have LOC RRs for their name in the DNS to avoid any ambiguity
-   in these cases.
-
-
-
-
-
-Davis, et al                  Experimental                      [Page 5]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-   Note that domain names that do not have associated A records must
-   have a LOC RR associated with their name in order for location
-   information to be accessible.
-
-5.2.2 Searching by Address
-
-   If the application is beginning with an IP address (as a "visual
-   traceroute" application might be) it MUST first map the address to a
-   name using the IN-ADDR.ARPA namespace (see [RFC 1034], section
-   5.2.1), then check for a LOC RR associated with that name.
-
-   If there is no LOC RR for the name, the address MAY be checked for
-   network (or subnet) LOC RRs using the "Searching by Network or
-   Subnet" algorithm (5.2.3).
-
-5.2.3 Searching by Network or Subnet
-
-   Even if a host's name does not have any associated LOC RRs, the
-   network(s) or subnet(s) it is on may.  If the application wishes to
-   search for such less specific data, the following algorithm SHOULD be
-   followed to find a network or subnet LOC RR associated with the IP
-   address.  This algorithm is adapted slightly from that specified in
-   [RFC 1101], sections 4.3 and 4.4.
-
-   Since subnet LOC RRs are (if present) more specific than network LOC
-   RRs, it is best to use them if available.  In order to do so, we
-   build a stack of network and subnet names found while performing the
-   [RFC 1101] search, then work our way down the stack until a LOC RR is
-   found.
-
-   1. create a host-zero address using the network portion of the IP
-      address (one, two, or three bytes for class A, B, or C networks,
-      respectively).  For example, for the host 128.9.2.17, on the class
-      B network 128.9, this would result in the address "128.9.0.0".
-
-   2. Reverse the octets, suffix IN-ADDR.ARPA, and query for PTR and A
-      records.  Retrieve:
-
-               0.0.9.128.IN-ADDR.ARPA.  PTR    isi-net.isi.edu.
-                                        A      255.255.255.0
-
-      Push the name "isi-net.isi.edu" onto the stack of names to be
-      searched for LOC RRs later.
-
-
-
-
-
-
-
-
-Davis, et al                  Experimental                      [Page 6]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-   3. Since an A RR was found, repeat using mask from RR
-      (255.255.255.0), constructing a query for 0.2.9.128.IN-ADDR.ARPA.
-      Retrieve:
-
-               0.2.9.128.IN-ADDR.ARPA.  PTR    div2-subnet.isi.edu.
-                                        A      255.255.255.240
-
-      Push the name "div2-subnet.isi.edu" onto the stack of names to be
-      searched for LOC RRs later.
-
-   4. Since another A RR was found, repeat using mask 255.255.255.240
-      (x'FFFFFFF0'), constructing a query for 16.2.9.128.IN-ADDR.ARPA.
-      Retrieve:
-
-               16.2.9.128.IN-ADDR.ARPA. PTR    inc-subsubnet.isi.edu.
-
-      Push the name "inc-subsubnet.isi.edu" onto the stack of names to
-      be searched for LOC RRs later.
-
-   5. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there are no
-      more subnet levels to search.  We now pop the top name from the
-      stack and check for an associated LOC RR.  Repeat until a LOC RR
-      is found.
-
-      In this case, assume that inc-subsubnet.isi.edu does not have an
-      associated LOC RR, but that div2-subnet.isi.edu does.  We will
-      then use div2-subnet.isi.edu's LOC RR as an approximation of this
-      host's location.  (Note that even if isi-net.isi.edu has a LOC RR,
-      it will not be used if a subnet also has a LOC RR.)
-
-5.3 Applicability to non-IN Classes and non-IP Addresses
-
-   The LOC record is defined for all RR classes, and may be used with
-   non-IN classes such as HS and CH.  The semantics of such use are not
-   defined by this memo.
-
-   The search algorithm in section 5.2.3 may be adapted to other
-   addressing schemes by extending [RFC 1101]'s encoding of network
-   names to cover those schemes.  Such extensions are not defined by
-   this memo.
-
-
-
-
-
-
-
-
-
-
-
-Davis, et al                  Experimental                      [Page 7]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-6. References
-
-   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
-              STD 13, RFC 1034, USC/Information Sciences Institute,
-              November 1987.
-
-   [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
-              Specification", STD 13, RFC 1035, USC/Information Sciences
-              Institute, November 1987.
-
-   [RFC 1101] Mockapetris, P., "DNS Encoding of Network Names and Other
-              Types", RFC 1101, USC/Information Sciences Institute,
-              April 1989.
-
-   [WGS 84] United States Department of Defense; DoD WGS-1984 - Its
-            Definition and Relationships with Local Geodetic Systems;
-            Washington, D.C.; 1985; Report AD-A188 815 DMA; 6127; 7-R-
-            138-R; CV, KV;
-
-7. Security Considerations
-
-   High-precision LOC RR information could be used to plan a penetration
-   of physical security, leading to potential denial-of-machine attacks.
-   To avoid any appearance of suggesting this method to potential
-   attackers, we declined the opportunity to name this RR "ICBM".
-
-8. Authors' Addresses
-
-   The authors as a group can be reached as <loc@pipex.net>.
-
-   Christopher Davis
-   Kapor Enterprises, Inc.
-   238 Main Street, Suite 400
-   Cambridge, MA 02142
-
-   Phone: +1 617 576 4532
-   EMail: ckd@kei.com
-
-
-   Paul Vixie
-   Vixie Enterprises
-   Star Route Box 159A
-   Woodside, CA 94062
-
-   Phone: +1 415 747 0204
-   EMail: paul@vix.com
-
-
-
-
-
-Davis, et al                  Experimental                      [Page 8]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-   Tim Goodwin
-   Public IP Exchange Ltd (PIPEX)
-   216 The Science Park
-   Cambridge CB4 4WA
-   UK
-
-   Phone: +44 1223 250250
-   EMail: tim@pipex.net
-
-
-   Ian Dickinson
-   FORE Systems
-   2475 The Crescent
-   Solihull Parkway
-   Birmingham Business Park
-   B37 7YE
-   UK
-
-   Phone: +44 121 717 4444
-   EMail: idickins@fore.co.uk
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Davis, et al                  Experimental                      [Page 9]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-Appendix A: Sample Conversion Routines
-
-/*
- * routines to convert between on-the-wire RR format and zone file
- * format.  Does not contain conversion to/from decimal degrees;
- * divide or multiply by 60*60*1000 for that.
- */
-
-static unsigned int poweroften[10] = {1, 10, 100, 1000, 10000, 100000,
-                                 1000000,10000000,100000000,1000000000};
-
-/* takes an XeY precision/size value, returns a string representation.*/
-static const char *
-precsize_ntoa(prec)
-        u_int8_t prec;
-{
-        static char retbuf[sizeof("90000000.00")];
-        unsigned long val;
-        int mantissa, exponent;
-
-        mantissa = (int)((prec >> 4) & 0x0f) % 10;
-        exponent = (int)((prec >> 0) & 0x0f) % 10;
-
-        val = mantissa * poweroften[exponent];
-
-        (void) sprintf(retbuf,"%d.%.2d", val/100, val%100);
-        return (retbuf);
-}
-
-/* converts ascii size/precision X * 10**Y(cm) to 0xXY. moves pointer.*/
-static u_int8_t
-precsize_aton(strptr)
-        char **strptr;
-{
-        unsigned int mval = 0, cmval = 0;
-        u_int8_t retval = 0;
-        register char *cp;
-        register int exponent;
-        register int mantissa;
-
-        cp = *strptr;
-
-        while (isdigit(*cp))
-                mval = mval * 10 + (*cp++ - '0');
-
-        if (*cp == '.') {               /* centimeters */
-                cp++;
-                if (isdigit(*cp)) {
-
-
-
-Davis, et al                  Experimental                     [Page 10]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-                        cmval = (*cp++ - '0') * 10;
-                        if (isdigit(*cp)) {
-                                cmval += (*cp++ - '0');
-                        }
-                }
-        }
-        cmval = (mval * 100) + cmval;
-
-        for (exponent = 0; exponent < 9; exponent++)
-                if (cmval < poweroften[exponent+1])
-                        break;
-
-        mantissa = cmval / poweroften[exponent];
-        if (mantissa > 9)
-                mantissa = 9;
-
-        retval = (mantissa << 4) | exponent;
-
-        *strptr = cp;
-
-        return (retval);
-}
-
-/* converts ascii lat/lon to unsigned encoded 32-bit number.
- *  moves pointer. */
-static u_int32_t
-latlon2ul(latlonstrptr,which)
-        char **latlonstrptr;
-        int *which;
-{
-        register char *cp;
-        u_int32_t retval;
-        int deg = 0, min = 0, secs = 0, secsfrac = 0;
-
-        cp = *latlonstrptr;
-
-        while (isdigit(*cp))
-                deg = deg * 10 + (*cp++ - '0');
-
-        while (isspace(*cp))
-                cp++;
-
-        if (!(isdigit(*cp)))
-                goto fndhemi;
-
-        while (isdigit(*cp))
-                min = min * 10 + (*cp++ - '0');
-
-
-
-
-Davis, et al                  Experimental                     [Page 11]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-        while (isspace(*cp))
-                cp++;
-
-        if (!(isdigit(*cp)))
-                goto fndhemi;
-
-        while (isdigit(*cp))
-                secs = secs * 10 + (*cp++ - '0');
-
-        if (*cp == '.') {               /* decimal seconds */
-                cp++;
-                if (isdigit(*cp)) {
-                        secsfrac = (*cp++ - '0') * 100;
-                        if (isdigit(*cp)) {
-                                secsfrac += (*cp++ - '0') * 10;
-                                if (isdigit(*cp)) {
-                                        secsfrac += (*cp++ - '0');
-                                }
-                        }
-                }
-        }
-
-        while (!isspace(*cp))   /* if any trailing garbage */
-                cp++;
-
-        while (isspace(*cp))
-                cp++;
-
- fndhemi:
-        switch (*cp) {
-        case 'N': case 'n':
-        case 'E': case 'e':
-                retval = ((unsigned)1<<31)
-                        + (((((deg * 60) + min) * 60) + secs) * 1000)
-                        + secsfrac;
-                break;
-        case 'S': case 's':
-        case 'W': case 'w':
-                retval = ((unsigned)1<<31)
-                        - (((((deg * 60) + min) * 60) + secs) * 1000)
-                        - secsfrac;
-                break;
-        default:
-                retval = 0;     /* invalid value -- indicates error */
-                break;
-        }
-
-        switch (*cp) {
-
-
-
-Davis, et al                  Experimental                     [Page 12]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-        case 'N': case 'n':
-        case 'S': case 's':
-                *which = 1;     /* latitude */
-                break;
-        case 'E': case 'e':
-        case 'W': case 'w':
-                *which = 2;     /* longitude */
-                break;
-        default:
-                *which = 0;     /* error */
-                break;
-        }
-
-        cp++;                   /* skip the hemisphere */
-
-        while (!isspace(*cp))   /* if any trailing garbage */
-                cp++;
-
-        while (isspace(*cp))    /* move to next field */
-                cp++;
-
-        *latlonstrptr = cp;
-
-        return (retval);
-}
-
-/* converts a zone file representation in a string to an RDATA
- * on-the-wire representation. */
-u_int32_t
-loc_aton(ascii, binary)
-        const char *ascii;
-        u_char *binary;
-{
-        const char *cp, *maxcp;
-        u_char *bcp;
-
-        u_int32_t latit = 0, longit = 0, alt = 0;
-        u_int32_t lltemp1 = 0, lltemp2 = 0;
-        int altmeters = 0, altfrac = 0, altsign = 1;
-        u_int8_t hp = 0x16;    /* default = 1e6 cm = 10000.00m = 10km */
-        u_int8_t vp = 0x13;    /* default = 1e3 cm = 10.00m */
-        u_int8_t siz = 0x12;   /* default = 1e2 cm = 1.00m */
-        int which1 = 0, which2 = 0;
-
-        cp = ascii;
-        maxcp = cp + strlen(ascii);
-
-        lltemp1 = latlon2ul(&cp, &which1);
-
-
-
-Davis, et al                  Experimental                     [Page 13]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-        lltemp2 = latlon2ul(&cp, &which2);
-
-        switch (which1 + which2) {
-        case 3:                 /* 1 + 2, the only valid combination */
-                if ((which1 == 1) && (which2 == 2)) { /* normal case */
-                        latit = lltemp1;
-                        longit = lltemp2;
-                } else if ((which1 == 2) && (which2 == 1)) {/*reversed*/
-                        longit = lltemp1;
-                        latit = lltemp2;
-                } else {        /* some kind of brokenness */
-                        return 0;
-                }
-                break;
-        default:                /* we didn't get one of each */
-                return 0;
-        }
-
-        /* altitude */
-        if (*cp == '-') {
-                altsign = -1;
-                cp++;
-        }
-
-        if (*cp == '+')
-                cp++;
-
-        while (isdigit(*cp))
-                altmeters = altmeters * 10 + (*cp++ - '0');
-
-        if (*cp == '.') {               /* decimal meters */
-                cp++;
-                if (isdigit(*cp)) {
-                        altfrac = (*cp++ - '0') * 10;
-                        if (isdigit(*cp)) {
-                                altfrac += (*cp++ - '0');
-                        }
-                }
-        }
-
-        alt = (10000000 + (altsign * (altmeters * 100 + altfrac)));
-
-        while (!isspace(*cp) && (cp < maxcp))
-                                           /* if trailing garbage or m */
-                cp++;
-
-        while (isspace(*cp) && (cp < maxcp))
-                cp++;
-
-
-
-Davis, et al                  Experimental                     [Page 14]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-        if (cp >= maxcp)
-                goto defaults;
-
-        siz = precsize_aton(&cp);
-
-        while (!isspace(*cp) && (cp < maxcp))/*if trailing garbage or m*/
-                cp++;
-
-        while (isspace(*cp) && (cp < maxcp))
-                cp++;
-
-        if (cp >= maxcp)
-                goto defaults;
-
-        hp = precsize_aton(&cp);
-
-        while (!isspace(*cp) && (cp < maxcp))/*if trailing garbage or m*/
-                cp++;
-
-        while (isspace(*cp) && (cp < maxcp))
-                cp++;
-
-        if (cp >= maxcp)
-                goto defaults;
-
-        vp = precsize_aton(&cp);
-
- defaults:
-
-        bcp = binary;
-        *bcp++ = (u_int8_t) 0;  /* version byte */
-        *bcp++ = siz;
-        *bcp++ = hp;
-        *bcp++ = vp;
-        PUTLONG(latit,bcp);
-        PUTLONG(longit,bcp);
-        PUTLONG(alt,bcp);
-
-        return (16);            /* size of RR in octets */
-}
-
-/* takes an on-the-wire LOC RR and prints it in zone file
- * (human readable) format. */
-char *
-loc_ntoa(binary,ascii)
-        const u_char *binary;
-        char *ascii;
-{
-
-
-
-Davis, et al                  Experimental                     [Page 15]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-        static char tmpbuf[255*3];
-
-        register char *cp;
-        register const u_char *rcp;
-
-        int latdeg, latmin, latsec, latsecfrac;
-        int longdeg, longmin, longsec, longsecfrac;
-        char northsouth, eastwest;
-        int altmeters, altfrac, altsign;
-
-        const int referencealt = 100000 * 100;
-
-        int32_t latval, longval, altval;
-        u_int32_t templ;
-        u_int8_t sizeval, hpval, vpval, versionval;
-
-        char *sizestr, *hpstr, *vpstr;
-
-        rcp = binary;
-        if (ascii)
-                cp = ascii;
-        else {
-                cp = tmpbuf;
-        }
-
-        versionval = *rcp++;
-
-        if (versionval) {
-                sprintf(cp,"; error: unknown LOC RR version");
-                return (cp);
-        }
-
-        sizeval = *rcp++;
-
-        hpval = *rcp++;
-        vpval = *rcp++;
-
-        GETLONG(templ,rcp);
-        latval = (templ - ((unsigned)1<<31));
-
-        GETLONG(templ,rcp);
-        longval = (templ - ((unsigned)1<<31));
-
-        GETLONG(templ,rcp);
-        if (templ < referencealt) { /* below WGS 84 spheroid */
-                altval = referencealt - templ;
-                altsign = -1;
-        } else {
-
-
-
-Davis, et al                  Experimental                     [Page 16]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-                altval = templ - referencealt;
-                altsign = 1;
-        }
-
-        if (latval < 0) {
-                northsouth = 'S';
-                latval = -latval;
-        }
-        else
-                northsouth = 'N';
-
-        latsecfrac = latval % 1000;
-        latval = latval / 1000;
-        latsec = latval % 60;
-        latval = latval / 60;
-        latmin = latval % 60;
-        latval = latval / 60;
-        latdeg = latval;
-
-        if (longval < 0) {
-                eastwest = 'W';
-                longval = -longval;
-        }
-        else
-                eastwest = 'E';
-
-        longsecfrac = longval % 1000;
-        longval = longval / 1000;
-        longsec = longval % 60;
-        longval = longval / 60;
-        longmin = longval % 60;
-        longval = longval / 60;
-        longdeg = longval;
-
-        altfrac = altval % 100;
-        altmeters = (altval / 100) * altsign;
-
-        sizestr = savestr(precsize_ntoa(sizeval));
-        hpstr = savestr(precsize_ntoa(hpval));
-        vpstr = savestr(precsize_ntoa(vpval));
-
-        sprintf(cp,
-                "%d %.2d %.2d.%.3d %c %d %.2d %.2d.%.3d %c %d.%.2dm
-                %sm %sm %sm",
-                latdeg, latmin, latsec, latsecfrac, northsouth,
-                longdeg, longmin, longsec, longsecfrac, eastwest,
-                altmeters, altfrac, sizestr, hpstr, vpstr);
-
-
-
-
-Davis, et al                  Experimental                     [Page 17]
-
-RFC 1876            Location Information in the DNS         January 1996
-
-
-        free(sizestr);
-        free(hpstr);
-        free(vpstr);
-
-        return (cp);
-}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Davis, et al                  Experimental                     [Page 18]
-
diff --git a/contrib/bind9/doc/rfc/rfc1886.txt b/contrib/bind9/doc/rfc/rfc1886.txt
deleted file mode 100644
index 9874fdd..0000000
--- a/contrib/bind9/doc/rfc/rfc1886.txt
+++ /dev/null
@@ -1,268 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         S. Thomson
-Request for Comments: 1886                                      Bellcore
-Category: Standards Track                                     C. Huitema
-                                                                   INRIA
-                                                           December 1995
-
-
-                DNS Extensions to support IP version 6
-
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-
-Abstract
-
-   This document defines the changes that need to be made to the Domain
-   Name System to support hosts running IP version 6 (IPv6).  The
-   changes include a new resource record type to store an IPv6 address,
-   a new domain to support lookups based on an IPv6 address, and updated
-   definitions of existing query types that return Internet addresses as
-   part of additional section processing.  The extensions are designed
-   to be compatible with existing applications and, in particular, DNS
-   implementations themselves.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Thompson & Huitema          Standards Track                    [Page 1]
-
-RFC 1886                  IPv6 DNS Extensions              December 1995
-
-
-1. INTRODUCTION
-
-   Current support for the storage of Internet addresses in the Domain
-   Name System (DNS)[1,2] cannot easily be extended to support IPv6
-   addresses[3] since applications assume that address queries return
-   32-bit IPv4 addresses only.
-
-   To support the storage of IPv6 addresses we define the following
-   extensions:
-
-      o A new resource record type is defined to map a domain name to an
-        IPv6 address.
-
-      o A new domain is defined to support lookups based on address.
-
-      o Existing queries that perform additional section processing to
-        locate IPv4 addresses are redefined to perform additional
-        section processing on both IPv4 and IPv6 addresses.
-
-   The changes are designed to be compatible with existing software. The
-   existing support for IPv4 addresses is retained. Transition issues
-   related to the co-existence of both IPv4 and IPv6 addresses in DNS
-   are discussed in [4].
-
-
-2. NEW RESOURCE RECORD DEFINITION AND DOMAIN
-
-   A new record type is defined to store a host's IPv6 address. A host
-   that has more than one IPv6 address must have more than one such
-   record.
-
-
-2.1 AAAA record type
-
-   The AAAA resource record type is a new record specific to the
-   Internet class that stores a single IPv6 address.
-
-   The value of the type is 28 (decimal).
-
-
-2.2 AAAA data format
-
-   A 128 bit IPv6 address is encoded in the data portion of an AAAA
-   resource record in network byte order (high-order byte first).
-
-
-
-
-Thompson & Huitema          Standards Track                    [Page 2]
-
-RFC 1886                  IPv6 DNS Extensions              December 1995
-
-
-2.3 AAAA query
-
-   An AAAA query for a specified domain name in the Internet class
-   returns all associated AAAA resource records in the answer section of
-   a response.
-
-   A type AAAA query does not perform additional section processing.
-
-
-2.4 Textual format of AAAA records
-
-   The textual representation of the data portion of the AAAA resource
-   record used in a master database file is the textual representation
-   of a IPv6 address as defined in [3].
-
-
-2.5 IP6.INT Domain
-
-   A special domain is defined to look up a record given an address. The
-   intent of this domain is to provide a way of mapping an IPv6 address
-   to a host name, although it may be used for other purposes as well.
-   The domain is rooted at IP6.INT.
-
-   An IPv6 address is represented as a name in the IP6.INT domain by a
-   sequence of nibbles separated by dots with the suffix ".IP6.INT". The
-   sequence of nibbles is encoded in reverse order, i.e. the low-order
-   nibble is encoded first, followed by the next low-order nibble and so
-   on. Each nibble is represented by a hexadecimal digit. For example,
-   the inverse lookup domain name corresponding to the address
-
-       4321:0:1:2:3:4:567:89ab
-
-   would be
-
-b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT.
-
-
-
-3. MODIFICATIONS TO EXISTING QUERY TYPES
-
-   All existing query types that perform type A additional section
-   processing, i.e. name server (NS), mail exchange (MX) and mailbox
-   (MB) query types, must be redefined to perform both type A and type
-   AAAA additional section processing. These new definitions mean that a
-   name server must add any relevant IPv4 addresses and any relevant
-
-
-
-Thompson & Huitema          Standards Track                    [Page 3]
-
-RFC 1886                  IPv6 DNS Extensions              December 1995
-
-
-   IPv6 addresses available locally to the additional section of a
-   response when processing any one of the above queries.
-
-
-4. SECURITY CONSIDERATIONS
-
-   Security issues are not discussed in this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Thompson & Huitema          Standards Track                    [Page 4]
-
-RFC 1886                  IPv6 DNS Extensions              December 1995
-
-
-5. REFERENCES
-
-
-   [1]  Mockapetris, P., "Domain Names - Concepts and Facilities", STD
-        13, RFC 1034, USC/Information Sciences Institute, November 1987.
-
-   [2]  Mockapetris, P., "Domain Names - Implementation and Specifica-
-        tion", STD 13, RFC 1035, USC/Information Sciences Institute,
-        November 1987.
-
-   [3]  Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing
-        Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December
-        1995.
-
-
-   [4]  Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6
-        Hosts and Routers", Work in Progress.
-
-
-Authors' Addresses
-
-   Susan Thomson
-   Bellcore
-   MRE 2P343
-   445 South Street
-   Morristown, NJ 07960
-   U.S.A.
-
-   Phone: +1 201-829-4514
-   EMail: set@thumper.bellcore.com
-
-
-   Christian Huitema
-   INRIA, Sophia-Antipolis
-   2004 Route des Lucioles
-   BP 109
-   F-06561 Valbonne Cedex
-   France
-
-   Phone: +33 93 65 77 15
-   EMail: Christian.Huitema@MIRSA.INRIA.FR
-
-
-
-
-
-
-
-Thompson & Huitema          Standards Track                    [Page 5]
-
diff --git a/contrib/bind9/doc/rfc/rfc1982.txt b/contrib/bind9/doc/rfc/rfc1982.txt
deleted file mode 100644
index 5a34bc4..0000000
--- a/contrib/bind9/doc/rfc/rfc1982.txt
+++ /dev/null
@@ -1,394 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                             R. Elz
-Request for Comments: 1982                       University of Melbourne
-Updates: 1034, 1035                                              R. Bush
-Category: Standards Track                                    RGnet, Inc.
-                                                             August 1996
-
-
-                        Serial Number Arithmetic
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Abstract
-
-   This memo defines serial number arithmetic, as used in the Domain
-   Name System.  The DNS has long relied upon serial number arithmetic,
-   a concept which has never really been defined, certainly not in an
-   IETF document, though which has been widely understood.  This memo
-   supplies the missing definition.  It is intended to update RFC1034
-   and RFC1035.
-
-1. Introduction
-
-   The serial number field of the SOA resource record is defined in
-   RFC1035 as
-
-   SERIAL   The unsigned 32 bit version number of the original copy of
-            the zone.  Zone transfers preserve this value.  This value
-            wraps and should be compared using sequence space
-            arithmetic.
-
-   RFC1034 uses the same terminology when defining secondary server zone
-   consistency procedures.
-
-   Unfortunately the term "sequence space arithmetic" is not defined in
-   either RFC1034 or RFC1035, nor do any of their references provide
-   further information.
-
-   This phrase seems to have been intending to specify arithmetic as
-   used in TCP sequence numbers [RFC793], and defined in [IEN-74].
-
-   Unfortunately, the arithmetic defined in [IEN-74] is not adequate for
-   the purposes of the DNS, as no general comparison operator is
-
-
-
-Elz & Bush                  Standards Track                     [Page 1]
-
-RFC 1982                Serial Number Arithmetic             August 1996
-
-
-   defined.
-
-   To avoid further problems with this simple field, this document
-   defines the field and the operations available upon it.  This
-   definition is intended merely to clarify the intent of RFC1034 and
-   RFC1035, and is believed to generally agree with current
-   implementations.  However, older, superseded, implementations are
-   known to have treated the serial number as a simple unsigned integer,
-   with no attempt to implement any kind of "sequence space arithmetic",
-   however that may have been interpreted, and further, ignoring the
-   requirement that the value wraps.  Nothing can be done with these
-   implementations, beyond extermination.
-
-2. Serial Number Arithmetic
-
-   Serial numbers are formed from non-negative integers from a finite
-   subset of the range of all integer values.  The lowest integer in
-   every subset used for this purpose is zero, the maximum is always one
-   less than a power of two.
-
-   When considered as serial numbers however no value has any particular
-   significance, there is no minimum or maximum serial number, every
-   value has a successor and predecessor.
-
-   To define a serial number to be used in this way, the size of the
-   serial number space must be given.  This value, called "SERIAL_BITS",
-   gives the power of two which results in one larger than the largest
-   integer corresponding to a serial number value.  This also specifies
-   the number of bits required to hold every possible value of a serial
-   number of the defined type.  The operations permitted upon serial
-   numbers are defined in the following section.
-
-3. Operations upon the serial number
-
-   Only two operations are defined upon serial numbers, addition of a
-   positive integer of limited range, and comparison with another serial
-   number.
-
-3.1. Addition
-
-   Serial numbers may be incremented by the addition of a positive
-   integer n, where n is taken from the range of integers
-   [0 .. (2^(SERIAL_BITS - 1) - 1)].  For a sequence number s, the
-   result of such an addition, s', is defined as
-
-                   s' = (s + n) modulo (2 ^ SERIAL_BITS)
-
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 2]
-
-RFC 1982                Serial Number Arithmetic             August 1996
-
-
-   where the addition and modulus operations here act upon values that
-   are non-negative values of unbounded size in the usual ways of
-   integer arithmetic.
-
-   Addition of a value outside the range
-   [0 .. (2^(SERIAL_BITS - 1) - 1)] is undefined.
-
-3.2. Comparison
-
-   Any two serial numbers, s1 and s2, may be compared.  The definition
-   of the result of this comparison is as follows.
-
-   For the purposes of this definition, consider two integers, i1 and
-   i2, from the unbounded set of non-negative integers, such that i1 and
-   s1 have the same numeric value, as do i2 and s2.  Arithmetic and
-   comparisons applied to i1 and i2 use ordinary unbounded integer
-   arithmetic.
-
-   Then, s1 is said to be equal to s2 if and only if i1 is equal to i2,
-   in all other cases, s1 is not equal to s2.
-
-   s1 is said to be less than s2 if, and only if, s1 is not equal to s2,
-   and
-
-        (i1 < i2 and i2 - i1 < 2^(SERIAL_BITS - 1)) or
-        (i1 > i2 and i1 - i2 > 2^(SERIAL_BITS - 1))
-
-   s1 is said to be greater than s2 if, and only if, s1 is not equal to
-   s2, and
-
-        (i1 < i2 and i2 - i1 > 2^(SERIAL_BITS - 1)) or
-        (i1 > i2 and i1 - i2 < 2^(SERIAL_BITS - 1))
-
-   Note that there are some pairs of values s1 and s2 for which s1 is
-   not equal to s2, but for which s1 is neither greater than, nor less
-   than, s2.  An attempt to use these ordering operators on such pairs
-   of values produces an undefined result.
-
-   The reason for this is that those pairs of values are such that any
-   simple definition that were to define s1 to be less than s2 where
-   (s1, s2) is such a pair, would also usually cause s2 to be less than
-   s1, when the pair is (s2, s1).  This would mean that the particular
-   order selected for a test could cause the result to differ, leading
-   to unpredictable implementations.
-
-   While it would be possible to define the test in such a way that the
-   inequality would not have this surprising property, while being
-   defined for all pairs of values, such a definition would be
-
-
-
-Elz & Bush                  Standards Track                     [Page 3]
-
-RFC 1982                Serial Number Arithmetic             August 1996
-
-
-   unnecessarily burdensome to implement, and difficult to understand,
-   and would still allow cases where
-
-        s1 < s2 and (s1 + 1) > (s2 + 1)
-
-   which is just as non-intuitive.
-
-   Thus the problem case is left undefined, implementations are free to
-   return either result, or to flag an error, and users must take care
-   not to depend on any particular outcome.  Usually this will mean
-   avoiding allowing those particular pairs of numbers to co-exist.
-
-   The relationships greater than or equal to, and less than or equal
-   to, follow in the natural way from the above definitions.
-
-4. Corollaries
-
-   These definitions give rise to some results of note.
-
-4.1. Corollary 1
-
-   For any sequence number s and any integer n such that addition of n
-   to s is well defined, (s + n) >= s.  Further (s + n) == s only when
-   n == 0, in all other defined cases, (s + n) > s.
-
-4.2. Corollary 2
-
-   If s' is the result of adding the non-zero integer n to the sequence
-   number s, and m is another integer from the range defined as able to
-   be added to a sequence number, and s" is the result of adding m to
-   s', then it is undefined whether s" is greater than, or less than s,
-   though it is known that s" is not equal to s.
-
-4.3. Corollary 3
-
-   If s" from the previous corollary is further incremented, then there
-   is no longer any known relationship between the result and s.
-
-4.4. Corollary 4
-
-   If in corollary 2 the value (n + m) is such that addition of the sum
-   to sequence number s would produce a defined result, then corollary 1
-   applies, and s" is known to be greater than s.
-
-
-
-
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 4]
-
-RFC 1982                Serial Number Arithmetic             August 1996
-
-
-5. Examples
-
-5.1. A trivial example
-
-   The simplest meaningful serial number space has SERIAL_BITS == 2.  In
-   this space, the integers that make up the serial number space are 0,
-   1, 2, and 3.  That is, 3 == 2^SERIAL_BITS - 1.
-
-   In this space, the largest integer that it is meaningful to add to a
-   sequence number is 2^(SERIAL_BITS - 1) - 1, or 1.
-
-   Then, as defined 0+1 == 1, 1+1 == 2, 2+1 == 3, and 3+1 == 0.
-   Further, 1 > 0, 2 > 1, 3 > 2, and 0 > 3.  It is undefined whether
-   2 > 0 or 0 > 2, and whether 1 > 3 or 3 > 1.
-
-5.2. A slightly larger example
-
-   Consider the case where SERIAL_BITS == 8.  In this space the integers
-   that make up the serial number space are 0, 1, 2, ... 254, 255.
-   255 == 2^SERIAL_BITS - 1.
-
-   In this space, the largest integer that it is meaningful to add to a
-   sequence number is 2^(SERIAL_BITS - 1) - 1, or 127.
-
-   Addition is as expected in this space, for example: 255+1 == 0,
-   100+100 == 200, and 200+100 == 44.
-
-   Comparison is more interesting, 1 > 0, 44 > 0, 100 > 0, 100 > 44,
-   200 > 100, 255 > 200, 0 > 255, 100 > 255, 0 > 200, and 44 > 200.
-
-   Note that 100+100 > 100, but that (100+100)+100 < 100.  Incrementing
-   a serial number can cause it to become "smaller".  Of course,
-   incrementing by a smaller number will allow many more increments to
-   be made before this occurs.  However this is always something to be
-   aware of, it can cause surprising errors, or be useful as it is the
-   only defined way to actually cause a serial number to decrease.
-
-   The pairs of values 0 and 128, 1 and 129, 2 and 130, etc, to 127 and
-   255 are not equal, but in each pair, neither number is defined as
-   being greater than, or less than, the other.
-
-   It could be defined (arbitrarily) that 128 > 0, 129 > 1,
-   130 > 2, ..., 255 > 127, by changing the comparison operator
-   definitions, as mentioned above.  However note that that would cause
-   255 > 127, while (255 + 1) < (127 + 1), as 0 < 128.  Such a
-   definition, apart from being arbitrary, would also be more costly to
-   implement.
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 5]
-
-RFC 1982                Serial Number Arithmetic             August 1996
-
-
-6. Citation
-
-   As this defined arithmetic may be useful for purposes other than for
-   the DNS serial number, it may be referenced as Serial Number
-   Arithmetic from RFC1982.  Any such reference shall be taken as
-   implying that the rules of sections 2 to 5 of this document apply to
-   the stated values.
-
-7. The DNS SOA serial number
-
-   The serial number in the DNS SOA Resource Record is a Serial Number
-   as defined above, with SERIAL_BITS being 32.  That is, the serial
-   number is a non negative integer with values taken from the range
-   [0 .. 4294967295].  That is, a 32 bit unsigned integer.
-
-   The maximum defined increment is 2147483647 (2^31 - 1).
-
-   Care should be taken that the serial number not be incremented, in
-   one or more steps, by more than this maximum within the period given
-   by the value of SOA.expire.  Doing so may leave some secondary
-   servers with out of date copies of the zone, but with a serial number
-   "greater" than that of the primary server.  Of course, special
-   circumstances may require this rule be set aside, for example, when
-   the serial number needs to be set lower for some reason.  If this
-   must be done, then take special care to verify that ALL servers have
-   correctly succeeded in following the primary server's serial number
-   changes, at each step.
-
-   Note that each, and every, increment to the serial number must be
-   treated as the start of a new sequence of increments for this
-   purpose, as well as being the continuation of all previous sequences
-   started within the period specified by SOA.expire.
-
-   Caution should also be exercised before causing the serial number to
-   be set to the value zero.  While this value is not in any way special
-   in serial number arithmetic, or to the DNS SOA serial number, many
-   DNS implementations have incorrectly treated zero as a special case,
-   with special properties, and unusual behaviour may be expected if
-   zero is used as a DNS SOA serial number.
-
-
-
-
-
-
-
-
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 6]
-
-RFC 1982                Serial Number Arithmetic             August 1996
-
-
-8. Document Updates
-
-   RFC1034 and RFC1035 are to be treated as if the references to
-   "sequence space arithmetic" therein are replaced by references to
-   serial number arithmetic, as defined in this document.
-
-9. Security Considerations
-
-   This document does not consider security.
-
-   It is not believed that anything in this document adds to any
-   security issues that may exist with the DNS, nor does it do anything
-   to lessen them.
-
-References
-
-   [RFC1034]   Domain Names - Concepts and Facilities,
-               P. Mockapetris, STD 13, ISI, November 1987.
-
-   [RFC1035]   Domain Names - Implementation and Specification
-               P. Mockapetris, STD 13, ISI, November 1987
-
-   [RFC793]    Transmission Control protocol
-               Information Sciences Institute, STD 7, USC, September 1981
-
-   [IEN-74]    Sequence Number Arithmetic
-               William W. Plummer, BB&N Inc, September 1978
-
-Acknowledgements
-
-   Thanks to Rob Austein for suggesting clarification of the undefined
-   comparison operators, and to Michael Patton for attempting to locate
-   another reference for this procedure.  Thanks also to members of the
-   IETF DNSIND working group of 1995-6, in particular, Paul Mockapetris.
-
-Authors' Addresses
-
-   Robert Elz                     Randy Bush
-   Computer Science               RGnet, Inc.
-   University of Melbourne        10361 NE Sasquatch Lane
-   Parkville, Vic,  3052          Bainbridge Island, Washington,  98110
-   Australia.                     United States.
-
-   EMail: kre@munnari.OZ.AU       EMail: randy@psg.com
-
-
-
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 7]
diff --git a/contrib/bind9/doc/rfc/rfc1995.txt b/contrib/bind9/doc/rfc/rfc1995.txt
deleted file mode 100644
index b50bdc6..0000000
--- a/contrib/bind9/doc/rfc/rfc1995.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            M. Ohta
-Request for Comments: 1995                 Tokyo Institute of Technology
-Updates: 1035                                                August 1996
-Category: Standards Track
-
-
-                    Incremental Zone Transfer in DNS
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Abstract
-
-   This document proposes extensions to the DNS protocols to provide an
-   incremental zone transfer (IXFR) mechanism.
-
-1. Introduction
-
-   For rapid propagation of changes to a DNS database [STD13], it is
-   necessary to reduce latency by actively notifying servers of the
-   change.  This is accomplished by the NOTIFY extension of the DNS
-   [NOTIFY].
-
-   The current full zone transfer mechanism (AXFR) is not an efficient
-   means to propagate changes to a small part of a zone, as it transfers
-   the entire zone file.
-
-   Incremental transfer (IXFR) as proposed is a more efficient
-   mechanism, as it transfers only the changed portion(s) of a zone.
-
-   In this document, a secondary name server which requests IXFR is
-   called an IXFR client and a primary or secondary name server which
-   responds to the request is called an IXFR server.
-
-2. Brief Description of the Protocol
-
-   If an IXFR client, which likely has an older version of a zone,
-   thinks it needs new information about the zone (typically through SOA
-   refresh timeout or the NOTIFY mechanism), it sends an IXFR message
-   containing the SOA serial number of its, presumably outdated, copy of
-   the zone.
-
-
-
-
-
-Ohta                        Standards Track                     [Page 1]
-
-RFC 1995            Incremental Zone Transfer in DNS         August 1996
-
-
-   An IXFR server should keep record of the newest version of the zone
-   and the differences between that copy and several older versions.
-   When an IXFR request with an older version number is received, the
-   IXFR server needs to send only the differences required to make that
-   version current.  Alternatively, the server may choose to transfer
-   the entire zone just as in a normal full zone transfer.
-
-   When a zone has been updated, it should be saved in stable storage
-   before the new version is used to respond to IXFR (or AXFR) queries.
-   Otherwise, if the server crashes, data which is no longer available
-   may have been distributed to secondary servers, which can cause
-   persistent database inconsistencies.
-
-   If an IXFR query with the same or newer version number than that of
-   the server is received, it is replied to with a single SOA record of
-   the server's current version, just as in AXFR.
-
-   Transport of a query may be by either UDP or TCP.  If an IXFR query
-   is via UDP, the IXFR server may attempt to reply using UDP if the
-   entire response can be contained in a single DNS packet.  If the UDP
-   reply does not fit, the query is responded to with a single SOA
-   record of the server's current version to inform the client that a
-   TCP query should be initiated.
-
-   Thus, a client should first make an IXFR query using UDP.  If the
-   query type is not recognized by the server, an AXFR (preceded by a
-   UDP SOA query) should be tried, ensuring backward compatibility.  If
-   the query response is a single packet with the entire new zone, or if
-   the server does not have a newer version than the client, everything
-   is done.  Otherwise, a TCP IXFR query should be tried.
-
-   To ensure integrity, servers should use UDP checksums for all UDP
-   responses.  A cautious client which receives a UDP packet with a
-   checksum value of zero should ignore the result and try a TCP IXFR
-   instead.
-
-   The query type value of IXFR assigned by IANA is 251.
-
-3. Query Format
-
-   The IXFR query packet format is the same as that of a normal DNS
-   query, but with the query type being IXFR and the authority section
-   containing the SOA record of client's version of the zone.
-
-
-
-
-
-
-
-
-Ohta                        Standards Track                     [Page 2]
-
-RFC 1995            Incremental Zone Transfer in DNS         August 1996
-
-
-4. Response Format
-
-   If incremental zone transfer is not available, the entire zone is
-   returned.  The first and the last RR of the response is the SOA
-   record of the zone.  I.e. the behavior is the same as an AXFR
-   response except the query type is IXFR.
-
-   If incremental zone transfer is available, one or more difference
-   sequences is returned.  The list of difference sequences is preceded
-   and followed by a copy of the server's current version of the SOA.
-
-   Each difference sequence represents one update to the zone (one SOA
-   serial change) consisting of deleted RRs and added RRs.  The first RR
-   of the deleted RRs is the older SOA RR and the first RR of the added
-   RRs is the newer SOA RR.
-
-   Modification of an RR is performed first by removing the original RR
-   and then adding the modified one.
-
-   The sequences of differential information are ordered oldest first
-   newest last.  Thus, the differential sequences are the history of
-   changes made since the version known by the IXFR client up to the
-   server's current version.
-
-   RRs in the incremental transfer messages may be partial.  That is, if
-   a single RR of multiple RRs of the same RR type changes, only the
-   changed RR is transferred.
-
-   An IXFR client, should only replace an older version with a newer
-   version after all the differences have been successfully processed.
-
-   An incremental response is different from that of a non-incremental
-   response in that it begins with two SOA RRs, the server's current SOA
-   followed by the SOA of the client's version which is about to be
-   replaced.
-
-   5. Purging Strategy
-
-   An IXFR server can not be required to hold all previous versions
-   forever and may delete them anytime. In general, there is a trade-off
-   between the size of storage space and the possibility of using IXFR.
-
-   Information about older versions should be purged if the total length
-   of an IXFR response would be longer than that of an AXFR response.
-   Given that the purpose of IXFR is to reduce AXFR overhead, this
-   strategy is quite reasonable.  The strategy assures that the amount
-   of storage required is at most twice that of the current zone
-   information.
-
-
-
-Ohta                        Standards Track                     [Page 3]
-
-RFC 1995            Incremental Zone Transfer in DNS         August 1996
-
-
-   Information older than the SOA expire period may also be purged.
-
-6. Optional Condensation of Multiple Versions
-
-   An IXFR server may optionally condense multiple difference sequences
-   into a single difference sequence, thus, dropping information on
-   intermediate versions.
-
-   This may be beneficial if a lot of versions, not all of which are
-   useful, are generated. For example, if multiple ftp servers share a
-   single DNS name and the IP address associated with the name is
-   changed once a minute to balance load between the ftp servers, it is
-   not so important to keep track of all the history of changes.
-
-   But, this feature may not be so useful if an IXFR client has access
-   to two IXFR servers: A and B, with inconsistent condensation results.
-   The current version of the IXFR client, received from server A, may
-   be unknown to server B. In such a case, server B can not provide
-   incremental data from the unknown version and a full zone transfer is
-   necessary.
-
-   Condensation is completely optional. Clients can't detect from the
-   response whether the server has condensed the reply or not.
-
-   For interoperability, IXFR servers, including those without the
-   condensation feature, should not flag an error even if it receives a
-   client's IXFR request with a unknown version number and should,
-   instead, attempt to perform a full zone transfer.
-
-7. Example
-
-   Given the following three generations of data with the current serial
-   number of 3,
-
-      JAIN.AD.JP.         IN SOA NS.JAIN.AD.JP. mohta.jain.ad.jp. (
-                                        1 600 600 3600000 604800)
-                          IN NS  NS.JAIN.AD.JP.
-      NS.JAIN.AD.JP.      IN A   133.69.136.1
-      NEZU.JAIN.AD.JP.    IN A   133.69.136.5
-
-   NEZU.JAIN.AD.JP. is removed and JAIN-BB.JAIN.AD.JP. is added.
-
-      jain.ad.jp.         IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
-                                        2 600 600 3600000 604800)
-                          IN NS  NS.JAIN.AD.JP.
-      NS.JAIN.AD.JP.      IN A   133.69.136.1
-      JAIN-BB.JAIN.AD.JP. IN A   133.69.136.4
-                          IN A   192.41.197.2
-
-
-
-Ohta                        Standards Track                     [Page 4]
-
-RFC 1995            Incremental Zone Transfer in DNS         August 1996
-
-
-   One of the IP addresses of JAIN-BB.JAIN.AD.JP. is changed.
-
-      JAIN.AD.JP.         IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
-                                        3 600 600 3600000 604800)
-                          IN NS  NS.JAIN.AD.JP.
-      NS.JAIN.AD.JP.      IN A   133.69.136.1
-      JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3
-                          IN A   192.41.197.2
-
-   The following IXFR query
-
-                 +---------------------------------------------------+
-      Header     | OPCODE=SQUERY                                     |
-                 +---------------------------------------------------+
-      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
-                 +---------------------------------------------------+
-      Answer     | <empty>                                           |
-                 +---------------------------------------------------+
-      Authority  | JAIN.AD.JP.         IN SOA serial=1               |
-                 +---------------------------------------------------+
-      Additional | <empty>                                           |
-                 +---------------------------------------------------+
-
-   could be replied to with the following full zone transfer message:
-
-                 +---------------------------------------------------+
-      Header     | OPCODE=SQUERY, RESPONSE                           |
-                 +---------------------------------------------------+
-      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
-                 +---------------------------------------------------+
-      Answer     | JAIN.AD.JP.         IN SOA serial=3               |
-                 | JAIN.AD.JP.         IN NS  NS.JAIN.AD.JP.         |
-                 | NS.JAIN.AD.JP.      IN A   133.69.136.1           |
-                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3           |
-                 | JAIN-BB.JAIN.AD.JP. IN A   192.41.197.2           |
-                 | JAIN.AD.JP.         IN SOA serial=3               |
-                 +---------------------------------------------------+
-      Authority  | <empty>                                           |
-                 +---------------------------------------------------+
-      Additional | <empty>                                           |
-                 +---------------------------------------------------+
-
-
-
-
-
-
-
-
-
-
-Ohta                        Standards Track                     [Page 5]
-
-RFC 1995            Incremental Zone Transfer in DNS         August 1996
-
-
-   or with the following incremental message:
-
-                 +---------------------------------------------------+
-      Header     | OPCODE=SQUERY, RESPONSE                           |
-                 +---------------------------------------------------+
-      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
-                 +---------------------------------------------------+
-      Answer     | JAIN.AD.JP.         IN SOA serial=3               |
-                 | JAIN.AD.JP.         IN SOA serial=1               |
-                 | NEZU.JAIN.AD.JP.    IN A   133.69.136.5           |
-                 | JAIN.AD.JP.         IN SOA serial=2               |
-                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.4           |
-                 | JAIN-BB.JAIN.AD.JP. IN A   192.41.197.2           |
-                 | JAIN.AD.JP.         IN SOA serial=2               |
-                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.4           |
-                 | JAIN.AD.JP.         IN SOA serial=3               |
-                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3           |
-                 | JAIN.AD.JP.         IN SOA serial=3               |
-                 +---------------------------------------------------+
-      Authority  | <empty>                                           |
-                 +---------------------------------------------------+
-      Additional | <empty>                                           |
-                 +---------------------------------------------------+
-
-   or with the following condensed incremental message:
-
-                 +---------------------------------------------------+
-      Header     | OPCODE=SQUERY, RESPONSE                           |
-                 +---------------------------------------------------+
-      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
-                 +---------------------------------------------------+
-      Answer     | JAIN.AD.JP.         IN SOA serial=3               |
-                 | JAIN.AD.JP.         IN SOA serial=1               |
-                 | NEZU.JAIN.AD.JP.    IN A   133.69.136.5           |
-                 | JAIN.AD.JP.         IN SOA serial=3               |
-                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3           |
-                 | JAIN-BB.JAIN.AD.JP. IN A   192.41.197.2           |
-                 | JAIN.AD.JP.         IN SOA serial=3               |
-                 +---------------------------------------------------+
-      Authority  | <empty>                                           |
-                 +---------------------------------------------------+
-      Additional | <empty>                                           |
-                 +---------------------------------------------------+
-
-
-
-
-
-
-
-
-Ohta                        Standards Track                     [Page 6]
-
-RFC 1995            Incremental Zone Transfer in DNS         August 1996
-
-
-   or, if UDP packet overflow occurs, with the following message:
-
-                 +---------------------------------------------------+
-      Header     | OPCODE=SQUERY, RESPONSE                           |
-                 +---------------------------------------------------+
-      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
-                 +---------------------------------------------------+
-      Answer     | JAIN.AD.JP.         IN SOA serial=3               |
-                 +---------------------------------------------------+
-      Authority  | <empty>                                           |
-                 +---------------------------------------------------+
-      Additional | <empty>                                           |
-                 +---------------------------------------------------+
-
-8. Acknowledgements
-
-   The original idea of IXFR was conceived by Anant Kumar, Steve Hotz
-   and Jon Postel.
-
-   For the refinement of the protocol and documentation, many people
-   have contributed including, but not limited to, Anant Kumar, Robert
-   Austein, Paul Vixie, Randy Bush, Mark Andrews, Robert Elz and the
-   members of the IETF DNSIND working group.
-
-9. References
-
-   [NOTIFY] Vixie, P., "DNS NOTIFY: A Mechanism for Prompt
-   Notification of Zone Changes", RFC 1996, August 1996.
-
-   [STD13] Mockapetris, P., "Domain Name System", STD 13, RFC 1034 and
-   RFC 1035), November 1987.
-
-10. Security Considerations
-
-   Though DNS is related to several security problems, no attempt is
-   made to fix them in this document.
-
-   This document is believed to introduce no additional security
-   problems to the current DNS protocol.
-
-
-
-
-
-
-
-
-
-
-
-
-Ohta                        Standards Track                     [Page 7]
-
-RFC 1995            Incremental Zone Transfer in DNS         August 1996
-
-
-11. Author's Address
-
-   Masataka Ohta
-   Computer Center
-   Tokyo Institute of Technology
-   2-12-1, O-okayama, Meguro-ku, Tokyo 152, JAPAN
-
-   Phone: +81-3-5734-3299
-   Fax: +81-3-5734-3415
-   EMail: mohta@necom830.hpcl.titech.ac.jp
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Ohta                        Standards Track                     [Page 8]
-
diff --git a/contrib/bind9/doc/rfc/rfc1996.txt b/contrib/bind9/doc/rfc/rfc1996.txt
deleted file mode 100644
index b08f200..0000000
--- a/contrib/bind9/doc/rfc/rfc1996.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           P. Vixie
-Request for Comments: 1996                                           ISC
-Updates: 1035                                                August 1996
-Category: Standards Track
-
-
-    A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Abstract
-
-   This memo describes the NOTIFY opcode for DNS, by which a master
-   server advises a set of slave servers that the master's data has been
-   changed and that a query should be initiated to discover the new
-   data.
-
-1. Rationale and Scope
-
-   1.1. Slow propagation of new and changed data in a DNS zone can be
-   due to a zone's relatively long refresh times.  Longer refresh times
-   are beneficial in that they reduce load on the master servers, but
-   that benefit comes at the cost of long intervals of incoherence among
-   authority servers whenever the zone is updated.
-
-   1.2. The DNS NOTIFY transaction allows master servers to inform slave
-   servers when the zone has changed -- an interrupt as opposed to poll
-   model -- which it is hoped will reduce propagation delay while not
-   unduly increasing the masters' load.  This specification only allows
-   slaves to be notified of SOA RR changes, but the architechture of
-   NOTIFY is intended to be extensible to other RR types.
-
-   1.3. This document intentionally gives more definition to the roles
-   of "Master," "Slave" and "Stealth" servers, their enumeration in NS
-   RRs, and the SOA MNAME field.  In that sense, this document can be
-   considered an addendum to [RFC1035].
-
-
-
-
-
-
-
-
-
-Vixie                       Standards Track                     [Page 1]
-
-RFC 1996                       DNS NOTIFY                    August 1996
-
-
-2. Definitions and Invariants
-
-   2.1. The following definitions are used in this document:
-
-   Slave           an authoritative server which uses zone transfer to
-                   retrieve the zone.  All slave servers are named in
-                   the NS RRs for the zone.
-
-   Master          any authoritative server configured to be the source
-                   of zone transfer for one or more slave servers.
-
-   Primary Master  master server at the root of the zone transfer
-                   dependency graph.  The primary master is named in the
-                   zone's SOA MNAME field and optionally by an NS RR.
-                   There is by definition only one primary master server
-                   per zone.
-
-   Stealth         like a slave server except not listed in an NS RR for
-                   the zone.  A stealth server, unless explicitly
-                   configured to do otherwise, will set the AA bit in
-                   responses and be capable of acting as a master.  A
-                   stealth server will only be known by other servers if
-                   they are given static configuration data indicating
-                   its existence.
-
-   Notify Set      set of servers to be notified of changes to some
-                   zone.  Default is all servers named in the NS RRset,
-                   except for any server also named in the SOA MNAME.
-                   Some implementations will permit the name server
-                   administrator to override this set or add elements to
-                   it (such as, for example, stealth servers).
-
-   2.2. The zone's servers must be organized into a dependency graph
-   such that there is a primary master, and all other servers must use
-   AXFR or IXFR either from the primary master or from some slave which
-   is also a master.  No loops are permitted in the AXFR dependency
-   graph.
-
-3. NOTIFY Message
-
-   3.1. When a master has updated one or more RRs in which slave servers
-   may be interested, the master may send the changed RR's name, class,
-   type, and optionally, new RDATA(s), to each known slave server using
-   a best efforts protocol based on the NOTIFY opcode.
-
-   3.2. NOTIFY uses the DNS Message Format, although it uses only a
-   subset of the available fields.  Fields not otherwise described
-   herein are to be filled with binary zero (0), and implementations
-
-
-
-Vixie                       Standards Track                     [Page 2]
-
-RFC 1996                       DNS NOTIFY                    August 1996
-
-
-   must ignore all messages for which this is not the case.
-
-   3.3. NOTIFY is similar to QUERY in that it has a request message with
-   the header QR flag "clear" and a response message with QR "set".  The
-   response message contains no useful information, but its reception by
-   the master is an indication that the slave has received the NOTIFY
-   and that the master can remove the slave from any retry queue for
-   this NOTIFY event.
-
-   3.4. The transport protocol used for a NOTIFY transaction will be UDP
-   unless the master has reason to believe that TCP is necessary; for
-   example, if a firewall has been installed between master and slave,
-   and only TCP has been allowed; or, if the changed RR is too large to
-   fit in a UDP/DNS datagram.
-
-   3.5. If TCP is used, both master and slave must continue to offer
-   name service during the transaction, even when the TCP transaction is
-   not making progress.  The NOTIFY request is sent once, and a
-   "timeout" is said to have occurred if no NOTIFY response is received
-   within a reasonable interval.
-
-   3.6. If UDP is used, a master periodically sends a NOTIFY request to
-   a slave until either too many copies have been sent (a "timeout"), an
-   ICMP message indicating that the port is unreachable, or until a
-   NOTIFY response is received from the slave with a matching query ID,
-   QNAME, IP source address, and UDP source port number.
-
-   Note:
-      The interval between transmissions, and the total number of
-      retransmissions, should be operational parameters specifiable by
-      the name server administrator, perhaps on a per-zone basis.
-      Reasonable defaults are a 60 second interval (or timeout if
-      using TCP), and a maximum of 5 retransmissions (for UDP).  It is
-      considered reasonable to use additive or exponential backoff for
-      the retry interval.
-
-   3.7. A NOTIFY request has QDCOUNT>0, ANCOUNT>=0, AUCOUNT>=0,
-   ADCOUNT>=0.  If ANCOUNT>0, then the answer section represents an
-   unsecure hint at the new RRset for this <QNAME,QCLASS,QTYPE>.  A
-   slave receiving such a hint is free to treat equivilence of this
-   answer section with its local data as a "no further work needs to be
-   done" indication.  If ANCOUNT=0, or ANCOUNT>0 and the answer section
-   differs from the slave's local data, then the slave should query its
-   known masters to retrieve the new data.
-
-   3.8. In no case shall the answer section of a NOTIFY request be used
-   to update a slave's local data, or to indicate that a zone transfer
-   needs to be undertaken, or to change the slave's zone refresh timers.
-
-
-
-Vixie                       Standards Track                     [Page 3]
-
-RFC 1996                       DNS NOTIFY                    August 1996
-
-
-   Only a "data present; data same" condition can lead a slave to act
-   differently if ANCOUNT>0 than it would if ANCOUNT=0.
-
-   3.9. This version of the NOTIFY specification makes no use of the
-   authority or additional data sections, and so conforming
-   implementations should set AUCOUNT=0 and ADCOUNT=0 when transmitting
-   requests.  Since a future revision of this specification may define a
-   backwards compatible use for either or both of these sections,
-   current implementations must ignore these sections, but not the
-   entire message, if AUCOUNT>0 and/or ADCOUNT>0.
-
-   3.10. If a slave receives a NOTIFY request from a host that is not a
-   known master for the zone containing the QNAME, it should ignore the
-   request and produce an error message in its operations log.
-
-   Note:
-      This implies that slaves of a multihomed master must either know
-      their master by the "closest" of the master's interface
-      addresses, or must know all of the master's interface addresses.
-      Otherwise, a valid NOTIFY request might come from an address
-      that is not on the slave's state list of masters for the zone,
-      which would be an error.
-
-   3.11. The only defined NOTIFY event at this time is that the SOA RR
-   has changed.  Upon completion of a NOTIFY transaction for QTYPE=SOA,
-   the slave should behave as though the zone given in the QNAME had
-   reached its REFRESH interval (see [RFC1035]), i.e., it should query
-   its masters for the SOA of the zone given in the NOTIFY QNAME, and
-   check the answer to see if the SOA SERIAL has been incremented since
-   the last time the zone was fetched.  If so, a zone transfer (either
-   AXFR or IXFR) should be initiated.
-
-   Note:
-      Because a deep server dependency graph may have multiple paths
-      from the primary master to any given slave, it is possible that
-      a slave will receive a NOTIFY from one of its known masters even
-      though the rest of its known masters have not yet updated their
-      copies of the zone.  Therefore, when issuing a QUERY for the
-      zone's SOA, the query should be directed at the known master who
-      was the source of the NOTIFY event, and not at any of the other
-      known masters.  This represents a departure from [RFC1035],
-      which specifies that upon expiry of the SOA REFRESH interval,
-      all known masters should be queried in turn.
-
-   3.12. If a NOTIFY request is received by a slave who does not
-   implement the NOTIFY opcode, it will respond with a NOTIMP
-   (unimplemented feature error) message.  A master server who receives
-   such a NOTIMP should consider the NOTIFY transaction complete for
-
-
-
-Vixie                       Standards Track                     [Page 4]
-
-RFC 1996                       DNS NOTIFY                    August 1996
-
-
-   that slave.
-
-4. Details and Examples
-
-   4.1. Retaining query state information across host reboots is
-   optional, but it is reasonable to simply execute an SOA NOTIFY
-   transaction on each authority zone when a server first starts.
-
-   4.2. Each slave is likely to receive several copies of the same
-   NOTIFY request:  One from the primary master, and one from each other
-   slave as that slave transfers the new zone and notifies its potential
-   peers.  The NOTIFY protocol supports this multiplicity by requiring
-   that NOTIFY be sent by a slave/master only AFTER it has updated the
-   SOA RR or has determined that no update is necessary, which in
-   practice means after a successful zone transfer.  Thus, barring
-   delivery reordering, the last NOTIFY any slave receives will be the
-   one indicating the latest change.  Since a slave always requests SOAs
-   and AXFR/IXFRs only from its known masters, it will have an
-   opportunity to retry its QUERY for the SOA after each of its masters
-   have completed each zone update.
-
-   4.3. If a master server seeks to avoid causing a large number of
-   simultaneous outbound zone transfers, it may delay for an arbitrary
-   length of time before sending a NOTIFY message to any given slave.
-   It is expected that the time will be chosen at random, so that each
-   slave will begin its transfer at a unique time.  The delay shall not
-   in any case be longer than the SOA REFRESH time.
-
-   Note:
-      This delay should be a parameter that each primary master name
-      server can specify, perhaps on a per-zone basis.  Random delays
-      of between 30 and 60 seconds would seem adequate if the servers
-      share a LAN and the zones are of moderate size.
-
-   4.4. A slave which receives a valid NOTIFY should defer action on any
-   subsequent NOTIFY with the same <QNAME,QCLASS,QTYPE> until it has
-   completed the transaction begun by the first NOTIFY.  This duplicate
-   rejection is necessary to avoid having multiple notifications lead to
-   pummeling the master server.
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie                       Standards Track                     [Page 5]
-
-RFC 1996                       DNS NOTIFY                    August 1996
-
-
-   4.5 Zone has Updated on Primary Master
-
-   Primary master sends a NOTIFY request to all servers named in Notify
-   Set.  The NOTIFY request has the following characteristics:
-
-      query ID:   (new)
-      op:         NOTIFY (4)
-      resp:       NOERROR
-      flags:      AA
-      qcount:     1
-      qname:      (zone name)
-      qclass:     (zone class)
-      qtype:      T_SOA
-
-   4.6 Zone has Updated on a Slave that is also a Master
-
-   As above in 4.5, except that this server's Notify Set may be
-   different from the Primary Master's due to optional static
-   specification of local stealth servers.
-
-   4.7 Slave Receives a NOTIFY Request from a Master
-
-   When a slave server receives a NOTIFY request from one of its locally
-   designated masters for the zone enclosing the given QNAME, with
-   QTYPE=SOA and QR=0, it should enter the state it would if the zone's
-   refresh timer had expired.  It will also send a NOTIFY response back
-   to the NOTIFY request's source, with the following characteristics:
-
-      query ID:   (same)
-      op:         NOTIFY (4)
-      resp:       NOERROR
-      flags:      QR AA
-      qcount:     1
-      qname:      (zone name)
-      qclass:     (zone class)
-      qtype:      T_SOA
-
-   This is intended to be identical to the NOTIFY request, except that
-   the QR bit is also set.  The query ID of the response must be the
-   same as was received in the request.
-
-   4.8 Master Receives a NOTIFY Response from Slave
-
-   When a master server receives a NOTIFY response, it deletes this
-   query from the retry queue, thus completing the "notification
-   process" of "this" RRset change to "that" server.
-
-
-
-
-
-Vixie                       Standards Track                     [Page 6]
-
-RFC 1996                       DNS NOTIFY                    August 1996
-
-
-5. Security Considerations
-
-   We believe that the NOTIFY operation's only security considerations
-   are:
-
-   1. That a NOTIFY request with a forged IP/UDP source address can
-      cause a slave to send spurious SOA queries to its masters,
-      leading to a benign denial of service attack if the forged
-      requests are sent very often.
-
-   2. That TCP spoofing could be used against a slave server given
-      NOTIFY as a means of synchronizing an SOA query and UDP/DNS
-      spoofing as a means of forcing a zone transfer.
-
-6. References
-
-   [RFC1035]
-      Mockapetris, P., "Domain Names - Implementation and
-      Specification", STD 13, RFC 1035, November 1987.
-
-   [IXFR]
-      Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996.
-
-7. Author's Address
-
-   Paul Vixie
-   Internet Software Consortium
-   Star Route Box 159A
-   Woodside, CA 94062
-
-   Phone: +1 415 747 0204
-   EMail: paul@vix.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie                       Standards Track                     [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc2052.txt b/contrib/bind9/doc/rfc/rfc2052.txt
deleted file mode 100644
index 46ba362..0000000
--- a/contrib/bind9/doc/rfc/rfc2052.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                     A. Gulbrandsen
-Request for Comments: 2052                            Troll Technologies
-Updates: 1035, 1183                                             P. Vixie
-Category: Experimental                                 Vixie Enterprises
-                                                            October 1996
-
-
-       A DNS RR for specifying the location of services (DNS SRV)
-
-Status of this Memo
-
-   This memo defines an Experimental Protocol for the Internet
-   community.  This memo does not specify an Internet standard of any
-   kind.  Discussion and suggestions for improvement are requested.
-   Distribution of this memo is unlimited.
-
-Abstract
-
-   This document describes a DNS RR which specifies the location of the
-   server(s) for a specific protocol and domain (like a more general
-   form of MX).
-
-Overview and rationale
-
-   Currently, one must either know the exact address of a server to
-   contact it, or broadcast a question.  This has led to, for example,
-   ftp.whatever.com aliases, the SMTP-specific MX RR, and using MAC-
-   level broadcasts to locate servers.
-
-   The SRV RR allows administrators to use several servers for a single
-   domain, to move services from host to host with little fuss, and to
-   designate some hosts as primary servers for a service and others as
-   backups.
-
-   Clients ask for a specific service/protocol for a specific domain
-   (the word domain is used here in the strict RFC 1034 sense), and get
-   back the names of any available servers.
-
-Introductory example
-
-   When a SRV-cognizant web-browser wants to retrieve
-
-      http://www.asdf.com/
-
-   it does a lookup of
-
-      http.tcp.www.asdf.com
-
-
-
-
-Gulbrandsen & Vixie           Experimental                      [Page 1]
-
-RFC 2052                       DNS SRV RR                   October 1996
-
-
-   and retrieves the document from one of the servers in the reply.  The
-   example zone file near the end of the memo contains answering RRs for
-   this query.
-
-The format of the SRV RR
-
-   Here is the format of the SRV RR, whose DNS type code is 33:
-
-        Service.Proto.Name TTL Class SRV Priority Weight Port Target
-
-        (There is an example near the end of this document.)
-
-   Service
-        The symbolic name of the desired service, as defined in Assigned
-        Numbers or locally.
-
-        Some widely used services, notably POP, don't have a single
-        universal name.  If Assigned Numbers names the service
-        indicated, that name is the only name which is legal for SRV
-        lookups.  Only locally defined services may be named locally.
-        The Service is case insensitive.
-
-   Proto
-        TCP and UDP are at present the most useful values
-        for this field, though any name defined by Assigned Numbers or
-        locally may be used (as for Service).  The Proto is case
-        insensitive.
-
-   Name
-        The domain this RR refers to.  The SRV RR is unique in that the
-        name one searches for is not this name; the example near the end
-        shows this clearly.
-
-   TTL
-        Standard DNS meaning.
-
-   Class
-        Standard DNS meaning.
-
-   Priority
-        As for MX, the priority of this target host.  A client MUST
-        attempt to contact the target host with the lowest-numbered
-        priority it can reach; target hosts with the same priority
-        SHOULD be tried in pseudorandom order.  The range is 0-65535.
-
-
-
-
-
-
-
-Gulbrandsen & Vixie           Experimental                      [Page 2]
-
-RFC 2052                       DNS SRV RR                   October 1996
-
-
-   Weight
-        Load balancing mechanism.  When selecting a target host among
-        the those that have the same priority, the chance of trying this
-        one first SHOULD be proportional to its weight.  The range of
-        this number is 1-65535.  Domain administrators are urged to use
-        Weight 0 when there isn't any load balancing to do, to make the
-        RR easier to read for humans (less noisy).
-
-   Port
-        The port on this target host of this service.  The range is
-        0-65535.  This is often as specified in Assigned Numbers but
-        need not be.
-
-   Target
-        As for MX, the domain name of the target host.  There MUST be
-        one or more A records for this name. Implementors are urged, but
-        not required, to return the A record(s) in the Additional Data
-        section.  Name compression is to be used for this field.
-
-        A Target of "." means that the service is decidedly not
-        available at this domain.
-
-Domain administrator advice
-
-   Asking everyone to update their telnet (for example) clients when the
-   first internet site adds a SRV RR for Telnet/TCP is futile (even if
-   desirable).  Therefore SRV will have to coexist with A record lookups
-   for a long time, and DNS administrators should try to provide A
-   records to support old clients:
-
-      - Where the services for a single domain are spread over several
-        hosts, it seems advisable to have a list of A RRs at the same
-        DNS node as the SRV RR, listing reasonable (if perhaps
-        suboptimal) fallback hosts for Telnet, NNTP and other protocols
-        likely to be used with this name.  Note that some programs only
-        try the first address they get back from e.g. gethostbyname(),
-        and we don't know how widespread this behaviour is.
-
-      - Where one service is provided by several hosts, one can either
-        provide A records for all the hosts (in which case the round-
-        robin mechanism, where available, will share the load equally)
-        or just for one (presumably the fastest).
-
-      - If a host is intended to provide a service only when the main
-        server(s) is/are down, it probably shouldn't be listed in A
-        records.
-
-
-
-
-
-Gulbrandsen & Vixie           Experimental                      [Page 3]
-
-RFC 2052                       DNS SRV RR                   October 1996
-
-
-      - Hosts that are referenced by backup A records must use the port
-        number specified in Assigned Numbers for the service.
-
-   Currently there's a practical limit of 512 bytes for DNS replies.
-   Until all resolvers can handle larger responses, domain
-   administrators are strongly advised to keep their SRV replies below
-   512 bytes.
-
-   All round numbers, wrote Dr. Johnson, are false, and these numbers
-   are very round: A reply packet has a 30-byte overhead plus the name
-   of the service ("telnet.tcp.asdf.com" for instance); each SRV RR adds
-   20 bytes plus the name of the target host; each NS RR in the NS
-   section is 15 bytes plus the name of the name server host; and
-   finally each A RR in the additional data section is 20 bytes or so,
-   and there are A's for each SRV and NS RR mentioned in the answer.
-   This size estimate is extremely crude, but shouldn't underestimate
-   the actual answer size by much.  If an answer may be close to the
-   limit, using e.g. "dig" to look at the actual answer is a good idea.
-
-The "Weight" field
-
-   Weight, the load balancing field, is not quite satisfactory, but the
-   actual load on typical servers changes much too quickly to be kept
-   around in DNS caches.  It seems to the authors that offering
-   administrators a way to say "this machine is three times as fast as
-   that one" is the best that can practically be done.
-
-   The only way the authors can see of getting a "better" load figure is
-   asking a separate server when the client selects a server and
-   contacts it.  For short-lived services like SMTP an extra step in the
-   connection establishment seems too expensive, and for long-lived
-   services like telnet, the load figure may well be thrown off a minute
-   after the connection is established when someone else starts or
-   finishes a heavy job.
-
-The Port number
-
-   Currently, the translation from service name to port number happens
-   at the client, often using a file such as /etc/services.
-
-   Moving this information to the DNS makes it less necessary to update
-   these files on every single computer of the net every time a new
-   service is added, and makes it possible to move standard services out
-   of the "root-only" port range on unix
-
-
-
-
-
-
-
-Gulbrandsen & Vixie           Experimental                      [Page 4]
-
-RFC 2052                       DNS SRV RR                   October 1996
-
-
-Usage rules
-
-   A SRV-cognizant client SHOULD use this procedure to locate a list of
-   servers and connect to the preferred one:
-
-        Do a lookup for QNAME=service.protocol.target, QCLASS=IN,
-        QTYPE=SRV.
-
-        If the reply is NOERROR, ANCOUNT>0 and there is at least one SRV
-        RR which specifies the requested Service and Protocol in the
-        reply:
-
-             If there is precisely one SRV RR, and its Target is "."
-             (the root domain), abort.
-
-             Else, for all such RR's, build a list of (Priority, Weight,
-             Target) tuples
-
-             Sort the list by priority (lowest number first)
-
-             Create a new empty list
-
-             For each distinct priority level
-                  While there are still elements left at this priority
-                  level
-                       Select an element randomly, with probability
-                       Weight, and move it to the tail of the new list
-
-             For each element in the new list
-
-                  query the DNS for A RR's for the Target or use any
-                  RR's found in the Additional Data secion of the
-                  earlier SRV query.
-
-                  for each A RR found, try to connect to the (protocol,
-                  address, service).
-
-        else if the service desired is SMTP
-
-             skip to RFC 974 (MX).
-
-        else
-
-             Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
-
-             for each A RR found, try to connect to the (protocol,
-             address, service)
-
-
-
-
-Gulbrandsen & Vixie           Experimental                      [Page 5]
-
-RFC 2052                       DNS SRV RR                   October 1996
-
-
-   Notes:
-
-      - Port numbers SHOULD NOT be used in place of the symbolic service
-        or protocol names (for the same reason why variant names cannot
-        be allowed: Applications would have to do two or more lookups).
-
-      - If a truncated response comes back from an SRV query, and the
-        Additional Data section has at least one complete RR in it, the
-        answer MUST be considered complete and the client resolver
-        SHOULD NOT retry the query using TCP, but use normal UDP queries
-        for A RR's missing from the Additional Data section.
-
-      - A client MAY use means other than Weight to choose among target
-        hosts with equal Priority.
-
-      - A client MUST parse all of the RR's in the reply.
-
-      - If the Additional Data section doesn't contain A RR's for all
-        the SRV RR's and the client may want to connect to the target
-        host(s) involved, the client MUST look up the A RR(s).  (This
-        happens quite often when the A RR has shorter TTL than the SRV
-        or NS RR's.)
-
-      - A future standard could specify that a SRV RR whose Protocol was
-        TCP and whose Service was SMTP would override RFC 974's rules
-        with regard to the use of an MX RR.  This would allow firewalled
-        organizations with several SMTP relays to control the load
-        distribution using the Weight field.
-
-      - Future protocols could be designed to use SRV RR lookups as the
-        means by which clients locate their servers.
-
-Fictional example
-
-   This is (part of) the zone file for asdf.com, a still-unused domain:
-
-        $ORIGIN asdf.com.
-        @               SOA server.asdf.com. root.asdf.com. (
-                            1995032001 3600 3600 604800 86400 )
-                        NS  server.asdf.com.
-                        NS  ns1.ip-provider.net.
-                        NS  ns2.ip-provider.net.
-        ftp.tcp         SRV 0 0 21 server.asdf.com.
-        finger.tcp      SRV 0 0 79 server.asdf.com.
-        ; telnet - use old-slow-box or new-fast-box if either is
-        ; available, make three quarters of the logins go to
-        ; new-fast-box.
-        telnet.tcp      SRV 0 1 23 old-slow-box.asdf.com.
-
-
-
-Gulbrandsen & Vixie           Experimental                      [Page 6]
-
-RFC 2052                       DNS SRV RR                   October 1996
-
-
-                        SRV 0 3 23 new-fast-box.asdf.com.
-        ; if neither old-slow-box or new-fast-box is up, switch to
-        ; using the sysdmin's box and the server
-                        SRV 1 0 23 sysadmins-box.asdf.com.
-                        SRV 1 0 23 server.asdf.com.
-        ; HTTP - server is the main server, new-fast-box is the backup
-        ; (On new-fast-box, the HTTP daemon runs on port 8000)
-        http.tcp        SRV 0 0 80 server.asdf.com.
-                        SRV 10 0 8000 new-fast-box.asdf.com.
-        ; since we want to support both http://asdf.com/ and
-        ; http://www.asdf.com/ we need the next two RRs as well
-        http.tcp.www    SRV 0 0 80 server.asdf.com.
-                        SRV 10 0 8000 new-fast-box.asdf.com.
-        ; SMTP - mail goes to the server, and to the IP provider if
-        ; the net is down
-        smtp.tcp        SRV 0 0 25 server.asdf.com.
-                        SRV 1 0 25 mailhost.ip-provider.net.
-        @               MX  0 server.asdf.com.
-                        MX  1 mailhost.ip-provider.net.
-        ; NNTP - use the IP providers's NNTP server
-        nntp.tcp        SRV 0 0 119 nntphost.ip-provider.net.
-        ; IDB is an locally defined protocol
-        idb.tcp         SRV  0 0 2025 new-fast-box.asdf.com.
-        ; addresses
-        server          A   172.30.79.10
-        old-slow-box    A   172.30.79.11
-        sysadmins-box   A   172.30.79.12
-        new-fast-box    A   172.30.79.13
-        ; backup A records - new-fast-box and old-slow-box are
-        ; included, naturally, and server is too, but might go
-        ; if the load got too bad
-        @               A   172.30.79.10
-                        A   172.30.79.11
-                        A   172.30.79.13
-        ; backup A RR for www.asdf.com
-        www             A       172.30.79.10
-        ; NO other services are supported
-        *.tcp           SRV  0 0 0 .
-        *.udp           SRV  0 0 0 .
-
-   In this example, a telnet connection to "asdf.com." needs an SRV
-   lookup of "telnet.tcp.asdf.com." and possibly A lookups of "new-
-   fast-box.asdf.com." and/or the other hosts named.  The size of the
-   SRV reply is approximately 365 bytes:
-
-      30 bytes general overhead
-      20 bytes for the query string, "telnet.tcp.asdf.com."
-      130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of "new-
-
-
-
-Gulbrandsen & Vixie           Experimental                      [Page 7]
-
-RFC 2052                       DNS SRV RR                   October 1996
-
-
-        fast-box", "old-slow-box", "server" and "sysadmins-box" -
-        "asdf.com" in the query section is quoted here and doesn't
-        need to be counted again.
-      75 bytes for 3 NS RRs, 15 bytes each plus the lengths of
-        "server", "ns1.ip-provider.net." and "ns2" - again, "ip-
-        provider.net." is quoted and only needs to be counted once.
-      120 bytes for the 6 A RR's mentioned by the SRV and NS RR's.
-
-Refererences
-
-   RFC 1918: Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G.,
-        and E.  Lear, "Address Allocation for Private Internets",
-        RFC 1918, February 1996.
-
-   RFC 1916 Berkowitz, H., Ferguson, P, Leland, W. and P. Nesser,
-        "Enterprise Renumbering: Experience and Information
-        Solicitation", RFC 1916, February 1996.
-
-   RFC 1912 Barr, D., "Common DNS Operational and Configuration
-        Errors", RFC 1912, February 1996.
-
-   RFC 1900: Carpenter, B., and Y. Rekhter, "Renumbering Needs Work",
-        RFC 1900, February 1996.
-
-   RFC 1920: Postel, J., "INTERNET OFFICIAL PROTOCOL STANDARDS",
-        STD 1, RFC 1920, March 1996.
-
-   RFC 1814: Gerich, E., "Unique Addresses are Good", RFC 1814, June
-             1995.
-
-   RFC 1794: Brisco, T., "DNS Support for Load Balancing", April 1995.
-
-   RFC 1713: Romao, A., "Tools for DNS debugging", November 1994.
-
-   RFC 1712: Farrell, C., Schulze, M., Pleitner, S., and D. Baldoni,
-        "DNS Encoding of Geographical Location", RFC 1712, November
-        1994.
-
-   RFC 1706: Manning, B. and R. Colella, "DNS NSAP Resource Records",
-        RFC 1706, October 1994.
-
-   RFC 1700: Reynolds, J., and J. Postel, "ASSIGNED NUMBERS",
-        STD 2, RFC 1700, October 1994.
-
-   RFC 1183: Ullmann, R., Mockapetris, P., Mamakos, L., and
-        C. Everhart, "New DNS RR Definitions", RFC 1183, November
-        1990.
-
-
-
-
-Gulbrandsen & Vixie           Experimental                      [Page 8]
-
-RFC 2052                       DNS SRV RR                   October 1996
-
-
-   RFC 1101: Mockapetris, P., "DNS encoding of network names and other
-        types", RFC 1101, April 1989.
-
-   RFC 1035: Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   RFC 1034: Mockapetris, P., "Domain names - concepts and
-        facilities", STD 13, RFC 1034, November 1987.
-
-   RFC 1033: Lottor, M., "Domain administrators operations guide",
-        RFC 1033, November 1987.
-
-   RFC 1032: Stahl, M., "Domain administrators guide", RFC 1032,
-        November 1987.
-
-   RFC 974: Partridge, C., "Mail routing and the domain system",
-        STD 14, RFC 974, January 1986.
-
-Security Considerations
-
-   The authors believes this RR to not cause any new security problems.
-   Some problems become more visible, though.
-
-      - The ability to specify ports on a fine-grained basis obviously
-        changes how a router can filter packets.  It becomes impossible
-        to block internal clients from accessing specific external
-        services, slightly harder to block internal users from running
-        unautorised services, and more important for the router
-        operations and DNS operations personnel to cooperate.
-
-      - There is no way a site can keep its hosts from being referenced
-        as servers (as, indeed, some sites become unwilling secondary
-        MXes today).  This could lead to denial of service.
-
-      - With SRV, DNS spoofers can supply false port numbers, as well as
-        host names and addresses.  The authors do not see any practical
-        effect of this.
-
-   We assume that as the DNS-security people invent new features, DNS
-   servers will return the relevant RRs in the Additional Data section
-   when answering an SRV query.
-
-
-
-
-
-
-
-
-
-
-Gulbrandsen & Vixie           Experimental                      [Page 9]
-
-RFC 2052                       DNS SRV RR                   October 1996
-
-
-Authors' Addresses
-
-   Arnt Gulbrandsen
-   Troll Tech
-   Postboks 6133 Etterstad
-   N-0602 Oslo
-   Norway
-
-   Phone: +47 22646966
-   EMail: agulbra@troll.no
-
-
-   Paul Vixie
-   Vixie Enterprises
-   Star Route 159A
-   Woodside, CA  94062
-
-   Phone: (415) 747-0204
-   EMail: paul@vix.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gulbrandsen & Vixie           Experimental                     [Page 10]
-
diff --git a/contrib/bind9/doc/rfc/rfc2104.txt b/contrib/bind9/doc/rfc/rfc2104.txt
deleted file mode 100644
index a205103..0000000
--- a/contrib/bind9/doc/rfc/rfc2104.txt
+++ /dev/null
@@ -1,620 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       H. Krawczyk
-Request for Comments: 2104                                          IBM
-Category: Informational                                      M. Bellare
-                                                                   UCSD
-                                                             R. Canetti
-                                                                    IBM
-                                                          February 1997
-
-
-             HMAC: Keyed-Hashing for Message Authentication
-
-Status of This Memo
-
-   This memo provides information for the Internet community.  This memo
-   does not specify an Internet standard of any kind.  Distribution of
-   this memo is unlimited.
-
-Abstract
-
-   This document describes HMAC, a mechanism for message authentication
-   using cryptographic hash functions. HMAC can be used with any
-   iterative cryptographic hash function, e.g., MD5, SHA-1, in
-   combination with a secret shared key.  The cryptographic strength of
-   HMAC depends on the properties of the underlying hash function.
-
-1. Introduction
-
-   Providing a way to check the integrity of information transmitted
-   over or stored in an unreliable medium is a prime necessity in the
-   world of open computing and communications. Mechanisms that provide
-   such integrity check based on a secret key are usually called
-   "message authentication codes" (MAC). Typically, message
-   authentication codes are used between two parties that share a secret
-   key in order to validate information transmitted between these
-   parties. In this document we present such a MAC mechanism based on
-   cryptographic hash functions. This mechanism, called HMAC, is based
-   on work by the authors [BCK1] where the construction is presented and
-   cryptographically analyzed. We refer to that work for the details on
-   the rationale and security analysis of HMAC, and its comparison to
-   other keyed-hash methods.
-
-
-
-
-
-
-
-
-
-
-
-Krawczyk, et. al.            Informational                      [Page 1]
-
-RFC 2104                          HMAC                     February 1997
-
-
-   HMAC can be used in combination with any iterated cryptographic hash
-   function. MD5 and SHA-1 are examples of such hash functions. HMAC
-   also uses a secret key for calculation and verification of the
-   message authentication values. The main goals behind this
-   construction are
-
-   * To use, without modifications, available hash functions.
-     In particular, hash functions that perform well in software,
-     and for which code is freely and widely available.
-
-   * To preserve the original performance of the hash function without
-     incurring a significant degradation.
-
-   * To use and handle keys in a simple way.
-
-   * To have a well understood cryptographic analysis of the strength of
-     the authentication mechanism based on reasonable assumptions on the
-     underlying hash function.
-
-   * To allow for easy replaceability of the underlying hash function in
-     case that faster or more secure hash functions are found or
-     required.
-
-   This document specifies HMAC using a generic cryptographic hash
-   function (denoted by H). Specific instantiations of HMAC need to
-   define a particular hash function. Current candidates for such hash
-   functions include SHA-1 [SHA], MD5 [MD5], RIPEMD-128/160 [RIPEMD].
-   These different realizations of HMAC will be denoted by HMAC-SHA1,
-   HMAC-MD5, HMAC-RIPEMD, etc.
-
-   Note: To the date of writing of this document MD5 and SHA-1 are the
-   most widely used cryptographic hash functions. MD5 has been recently
-   shown to be vulnerable to collision search attacks [Dobb].  This
-   attack and other currently known weaknesses of MD5 do not compromise
-   the use of MD5 within HMAC as specified in this document (see
-   [Dobb]); however, SHA-1 appears to be a cryptographically stronger
-   function. To this date, MD5 can be considered for use in HMAC for
-   applications where the superior performance of MD5 is critical.   In
-   any case, implementers and users need to be aware of possible
-   cryptanalytic developments regarding any of these cryptographic hash
-   functions, and the eventual need to replace the underlying hash
-   function. (See section 6 for more information on the security of
-   HMAC.)
-
-
-
-
-
-
-
-
-Krawczyk, et. al.            Informational                      [Page 2]
-
-RFC 2104                          HMAC                     February 1997
-
-
-2. Definition of HMAC
-
-   The definition of HMAC requires a cryptographic hash function, which
-   we denote by H, and a secret key K. We assume H to be a cryptographic
-   hash function where data is hashed by iterating a basic compression
-   function on blocks of data.   We denote by B the byte-length of such
-   blocks (B=64 for all the above mentioned examples of hash functions),
-   and by L the byte-length of hash outputs (L=16 for MD5, L=20 for
-   SHA-1).  The authentication key K can be of any length up to B, the
-   block length of the hash function.  Applications that use keys longer
-   than B bytes will first hash the key using H and then use the
-   resultant L byte string as the actual key to HMAC. In any case the
-   minimal recommended length for K is L bytes (as the hash output
-   length). See section 3 for more information on keys.
-
-   We define two fixed and different strings ipad and opad as follows
-   (the 'i' and 'o' are mnemonics for inner and outer):
-
-                   ipad = the byte 0x36 repeated B times
-                  opad = the byte 0x5C repeated B times.
-
-   To compute HMAC over the data `text' we perform
-
-                    H(K XOR opad, H(K XOR ipad, text))
-
-   Namely,
-
-    (1) append zeros to the end of K to create a B byte string
-        (e.g., if K is of length 20 bytes and B=64, then K will be
-         appended with 44 zero bytes 0x00)
-    (2) XOR (bitwise exclusive-OR) the B byte string computed in step
-        (1) with ipad
-    (3) append the stream of data 'text' to the B byte string resulting
-        from step (2)
-    (4) apply H to the stream generated in step (3)
-    (5) XOR (bitwise exclusive-OR) the B byte string computed in
-        step (1) with opad
-    (6) append the H result from step (4) to the B byte string
-        resulting from step (5)
-    (7) apply H to the stream generated in step (6) and output
-        the result
-
-   For illustration purposes, sample code based on MD5 is provided as an
-   appendix.
-
-
-
-
-
-
-
-Krawczyk, et. al.            Informational                      [Page 3]
-
-RFC 2104                          HMAC                     February 1997
-
-
-3. Keys
-
-   The key for HMAC can be of any length (keys longer than B bytes are
-   first hashed using H).  However, less than L bytes is strongly
-   discouraged as it would decrease the security strength of the
-   function.  Keys longer than L bytes are acceptable but the extra
-   length would not significantly increase the function strength. (A
-   longer key may be advisable if the randomness of the key is
-   considered weak.)
-
-   Keys need to be chosen at random (or using a cryptographically strong
-   pseudo-random generator seeded with a random seed), and periodically
-   refreshed.  (Current attacks do not indicate a specific recommended
-   frequency for key changes as these attacks are practically
-   infeasible.  However, 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.)
-
-4. Implementation Note
-
-   HMAC is defined in such a way that the underlying hash function H can
-   be used with no modification to its code. In particular, it uses the
-   function H with the pre-defined initial value IV (a fixed value
-   specified by each iterative hash function to initialize its
-   compression function).  However, if desired, a performance
-   improvement can be achieved at the cost of (possibly) modifying the
-   code of H to support variable IVs.
-
-   The idea is that the intermediate results of the compression function
-   on the B-byte blocks (K XOR ipad) and (K XOR opad) can be precomputed
-   only once at the time of generation of the key K, or before its first
-   use. These intermediate results are stored and then used to
-   initialize the IV of H each time that a message needs to be
-   authenticated.  This method saves, for each authenticated message,
-   the application of the compression function of H on two B-byte blocks
-   (i.e., on (K XOR ipad) and (K XOR opad)). Such a savings may be
-   significant when authenticating short streams of data.  We stress
-   that the stored intermediate values need to be treated and protected
-   the same as secret keys.
-
-   Choosing to implement HMAC in the above way is a decision of the
-   local implementation and has no effect on inter-operability.
-
-
-
-
-
-
-
-
-
-Krawczyk, et. al.            Informational                      [Page 4]
-
-RFC 2104                          HMAC                     February 1997
-
-
-5. Truncated output
-
-   A well-known practice with message authentication codes is to
-   truncate the output of the MAC and output only part of the bits
-   (e.g., [MM, ANSI]).  Preneel and van Oorschot [PV] show some
-   analytical advantages of truncating the output of hash-based MAC
-   functions. The results in this area are not absolute as for the
-   overall security advantages of truncation. It has advantages (less
-   information on the hash result available to an attacker) and
-   disadvantages (less bits to predict for the attacker).  Applications
-   of HMAC can choose to truncate the output of HMAC by outputting the t
-   leftmost bits of the HMAC computation for some parameter t (namely,
-   the computation is carried in the normal way as defined in section 2
-   above but the end result is truncated to t bits). We recommend that
-   the output length t be not less than half the length of the hash
-   output (to match the birthday attack bound) and not less than 80 bits
-   (a suitable lower bound on the number of bits that need to be
-   predicted by an attacker).  We propose denoting a realization of HMAC
-   that uses a hash function H with t bits of output as HMAC-H-t. For
-   example, HMAC-SHA1-80 denotes HMAC computed using the SHA-1 function
-   and with the output truncated to 80 bits.  (If the parameter t is not
-   specified, e.g. HMAC-MD5, then it is assumed that all the bits of the
-   hash are output.)
-
-6. Security
-
-   The security of the message authentication mechanism presented here
-   depends on cryptographic properties of the hash function H: the
-   resistance to collision finding (limited to the case where the
-   initial value is secret and random, and where the output of the
-   function is not explicitly available to the attacker), and the
-   message authentication property of the compression function of H when
-   applied to single blocks (in HMAC these blocks are partially unknown
-   to an attacker as they contain the result of the inner H computation
-   and, in particular, cannot be fully chosen by the attacker).
-
-   These properties, and actually stronger ones, are commonly assumed
-   for hash functions of the kind used with HMAC. In particular, a hash
-   function for which the above properties do not hold would become
-   unsuitable for most (probably, all) cryptographic applications,
-   including alternative message authentication schemes based on such
-   functions.  (For a complete analysis and rationale of the HMAC
-   function the reader is referred to [BCK1].)
-
-
-
-
-
-
-
-
-Krawczyk, et. al.            Informational                      [Page 5]
-
-RFC 2104                          HMAC                     February 1997
-
-
-   Given the limited confidence gained so far as for the cryptographic
-   strength of candidate hash functions, it is important to observe the
-   following two properties of the HMAC construction and its secure use
-   for message authentication:
-
-   1. The construction is independent of the details of the particular
-   hash function H in use and then the latter can be replaced by any
-   other secure (iterative) cryptographic hash function.
-
-   2. Message authentication, as opposed to encryption, has a
-   "transient" effect. A published breaking of a message authentication
-   scheme would lead to the replacement of that scheme, but would have
-   no adversarial effect on information authenticated in the past.  This
-   is in sharp contrast with encryption, where information encrypted
-   today may suffer from exposure in the future if, and when, the
-   encryption algorithm is broken.
-
-   The strongest attack known against HMAC is based on the frequency of
-   collisions for the hash function H ("birthday attack") [PV,BCK2], and
-   is totally impractical for minimally reasonable hash functions.
-
-   As an example, if we consider a hash function like MD5 where the
-   output length equals L=16 bytes (128 bits) the attacker needs to
-   acquire the correct message authentication tags computed (with the
-   _same_ secret key K!) on about 2**64 known plaintexts.  This would
-   require the processing of at least 2**64 blocks under H, an
-   impossible task in any realistic scenario (for a block length of 64
-   bytes this would take 250,000 years in a continuous 1Gbps link, and
-   without changing the secret key K during all this time).  This attack
-   could become realistic only if serious flaws in the collision
-   behavior of the function H are discovered (e.g.  collisions found
-   after 2**30 messages). Such a discovery would determine the immediate
-   replacement of the function H (the effects of such failure would be
-   far more severe for the traditional uses of H in the context of
-   digital signatures, public key certificates, etc.).
-
-   Note: this attack needs to be strongly contrasted with regular
-   collision attacks on cryptographic hash functions where no secret key
-   is involved and where 2**64 off-line parallelizable (!) operations
-   suffice to find collisions.  The latter attack is approaching
-   feasibility [VW] while the birthday attack on HMAC is totally
-   impractical.  (In the above examples, if one uses a hash function
-   with, say, 160 bit of output then 2**64 should be replaced by 2**80.)
-
-
-
-
-
-
-
-
-Krawczyk, et. al.            Informational                      [Page 6]
-
-RFC 2104                          HMAC                     February 1997
-
-
-   A correct implementation of the above construction, the choice of
-   random (or cryptographically pseudorandom) keys, a secure key
-   exchange mechanism, frequent key refreshments, and good secrecy
-   protection of keys are all essential ingredients for the security of
-   the integrity verification mechanism provided by HMAC.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Krawczyk, et. al.            Informational                      [Page 7]
-
-RFC 2104                          HMAC                     February 1997
-
-
-Appendix -- Sample Code
-
-   For the sake of illustration we provide the following sample code for
-   the implementation of HMAC-MD5 as well as some corresponding test
-   vectors (the code is based on MD5 code as described in [MD5]).
-
-/*
-** Function: hmac_md5
-*/
-
-void
-hmac_md5(text, text_len, key, key_len, digest)
-unsigned char*  text;                /* pointer to data stream */
-int             text_len;            /* length of data stream */
-unsigned char*  key;                 /* pointer to authentication key */
-int             key_len;             /* length of authentication key */
-caddr_t         digest;              /* caller digest to be filled in */
-
-{
-        MD5_CTX context;
-        unsigned char k_ipad[65];    /* inner padding -
-                                      * key XORd with ipad
-                                      */
-        unsigned char k_opad[65];    /* outer padding -
-                                      * key XORd with opad
-                                      */
-        unsigned char tk[16];
-        int i;
-        /* if key is longer than 64 bytes reset it to key=MD5(key) */
-        if (key_len > 64) {
-
-                MD5_CTX      tctx;
-
-                MD5Init(&tctx);
-                MD5Update(&tctx, key, key_len);
-                MD5Final(tk, &tctx);
-
-                key = tk;
-                key_len = 16;
-        }
-
-        /*
-         * the HMAC_MD5 transform looks like:
-         *
-         * MD5(K XOR opad, MD5(K XOR ipad, text))
-         *
-         * where K is an n byte key
-         * ipad is the byte 0x36 repeated 64 times
-
-
-
-Krawczyk, et. al.            Informational                      [Page 8]
-
-RFC 2104                          HMAC                     February 1997
-
-
-         * opad is the byte 0x5c repeated 64 times
-         * and text is the data being protected
-         */
-
-        /* start out by storing key in pads */
-        bzero( k_ipad, sizeof k_ipad);
-        bzero( k_opad, sizeof k_opad);
-        bcopy( key, k_ipad, key_len);
-        bcopy( key, k_opad, key_len);
-
-        /* XOR key with ipad and opad values */
-        for (i=0; i<64; i++) {
-                k_ipad[i] ^= 0x36;
-                k_opad[i] ^= 0x5c;
-        }
-        /*
-         * perform inner MD5
-         */
-        MD5Init(&context);                   /* init context for 1st
-                                              * pass */
-        MD5Update(&context, k_ipad, 64)      /* start with inner pad */
-        MD5Update(&context, text, text_len); /* then text of datagram */
-        MD5Final(digest, &context);          /* finish up 1st pass */
-        /*
-         * perform outer MD5
-         */
-        MD5Init(&context);                   /* init context for 2nd
-                                              * pass */
-        MD5Update(&context, k_opad, 64);     /* start with outer pad */
-        MD5Update(&context, digest, 16);     /* then results of 1st
-                                              * hash */
-        MD5Final(digest, &context);          /* finish up 2nd pass */
-}
-
-Test Vectors (Trailing '\0' of a character string not included in test):
-
-  key =         0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
-  key_len =     16 bytes
-  data =        "Hi There"
-  data_len =    8  bytes
-  digest =      0x9294727a3638bb1c13f48ef8158bfc9d
-
-  key =         "Jefe"
-  data =        "what do ya want for nothing?"
-  data_len =    28 bytes
-  digest =      0x750c783e6ab0b503eaa86e310a5db738
-
-  key =         0xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
-
-
-
-Krawczyk, et. al.            Informational                      [Page 9]
-
-RFC 2104                          HMAC                     February 1997
-
-
-  key_len       16 bytes
-  data =        0xDDDDDDDDDDDDDDDDDDDD...
-                ..DDDDDDDDDDDDDDDDDDDD...
-                ..DDDDDDDDDDDDDDDDDDDD...
-                ..DDDDDDDDDDDDDDDDDDDD...
-                ..DDDDDDDDDDDDDDDDDDDD
-  data_len =    50 bytes
-  digest =      0x56be34521d144c88dbb8c733f0e8b3f6
-
-Acknowledgments
-
-   Pau-Chen Cheng, Jeff Kraemer, and Michael Oehler, have provided
-   useful comments on early drafts, and ran the first interoperability
-   tests of this specification. Jeff and Pau-Chen kindly provided the
-   sample code and test vectors that appear in the appendix.  Burt
-   Kaliski, Bart Preneel, Matt Robshaw, Adi Shamir, and Paul van
-   Oorschot have provided useful comments and suggestions during the
-   investigation of the HMAC construction.
-
-References
-
-   [ANSI]  ANSI X9.9, "American National Standard for Financial
-           Institution Message Authentication (Wholesale)," American
-           Bankers Association, 1981.   Revised 1986.
-
-   [Atk]   Atkinson, R., "IP Authentication Header", RFC 1826, August
-           1995.
-
-   [BCK1]  M. Bellare, R. Canetti, and H. Krawczyk,
-           "Keyed Hash Functions and Message Authentication",
-           Proceedings of Crypto'96, LNCS 1109, pp. 1-15.
-           (http://www.research.ibm.com/security/keyed-md5.html)
-
-   [BCK2]  M. Bellare, R. Canetti, and H. Krawczyk,
-           "Pseudorandom Functions Revisited: The Cascade Construction",
-           Proceedings of FOCS'96.
-
-   [Dobb]  H. Dobbertin, "The Status of MD5  After a Recent Attack",
-           RSA Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996.
-           http://www.rsa.com/rsalabs/pubs/cryptobytes.html
-
-   [PV]    B. Preneel and P. van Oorschot, "Building fast MACs from hash
-           functions", Advances in Cryptology -- CRYPTO'95 Proceedings,
-           Lecture Notes in Computer Science, Springer-Verlag Vol.963,
-           1995, pp. 1-14.
-
-   [MD5]   Rivest, R., "The MD5 Message-Digest Algorithm",
-           RFC 1321, April 1992.
-
-
-
-Krawczyk, et. al.            Informational                     [Page 10]
-
-RFC 2104                          HMAC                     February 1997
-
-
-   [MM]    Meyer, S. and Matyas, S.M., Cryptography, New York Wiley,
-           1982.
-
-   [RIPEMD] H. Dobbertin, A. Bosselaers, and B. Preneel, "RIPEMD-160: A
-            strengthened version of RIPEMD", Fast Software Encryption,
-            LNCS Vol 1039, pp. 71-82.
-            ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/bosselae/ripemd/.
-
-   [SHA]   NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
-
-   [Tsu]   G. Tsudik, "Message authentication with one-way hash
-           functions", In Proceedings of Infocom'92, May 1992.
-           (Also in "Access Control and Policy Enforcement in
-            Internetworks", Ph.D. Dissertation, Computer Science
-            Department, University of Southern California, April 1991.)
-
-   [VW]    P. van Oorschot and M. Wiener, "Parallel Collision
-           Search with Applications to Hash Functions and Discrete
-           Logarithms", Proceedings of the 2nd ACM Conf. Computer and
-           Communications Security, Fairfax, VA, November 1994.
-
-Authors' Addresses
-
-   Hugo Krawczyk
-   IBM T.J. Watson Research Center
-   P.O.Box 704
-   Yorktown Heights, NY 10598
-
-   EMail: hugo@watson.ibm.com
-
-   Mihir Bellare
-   Dept of Computer Science and Engineering
-   Mail Code 0114
-   University of California at San Diego
-   9500 Gilman Drive
-   La Jolla, CA 92093
-
-   EMail: mihir@cs.ucsd.edu
-
-   Ran Canetti
-   IBM T.J. Watson Research Center
-   P.O.Box 704
-   Yorktown Heights, NY 10598
-
-   EMail: canetti@watson.ibm.com
-
-
-
-
-
-
-Krawczyk, et. al.            Informational                     [Page 11]
-
-
diff --git a/contrib/bind9/doc/rfc/rfc2119.txt b/contrib/bind9/doc/rfc/rfc2119.txt
deleted file mode 100644
index e31fae4..0000000
--- a/contrib/bind9/doc/rfc/rfc2119.txt
+++ /dev/null
@@ -1,171 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         S. Bradner
-Request for Comments: 2119                            Harvard University
-BCP: 14                                                       March 1997
-Category: Best Current Practice
-
-
-        Key words for use in RFCs to Indicate Requirement Levels
-
-Status of this Memo
-
-   This document specifies an Internet Best Current Practices for the
-   Internet Community, and requests discussion and suggestions for
-   improvements.  Distribution of this memo is unlimited.
-
-Abstract
-
-   In many standards track documents several words are used to signify
-   the requirements in the specification.  These words are often
-   capitalized.  This document defines these words as they should be
-   interpreted in IETF documents.  Authors who follow these guidelines
-   should incorporate this phrase near the beginning of their document:
-
-      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.
-
-   Note that the force of these words is modified by the requirement
-   level of the document in which they are used.
-
-1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
-   definition is an absolute requirement of the specification.
-
-2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
-   definition is an absolute prohibition of the specification.
-
-3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
-   may exist valid reasons in particular circumstances to ignore a
-   particular item, but the full implications must be understood and
-   carefully weighed before choosing a different course.
-
-4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
-   there may exist valid reasons in particular circumstances when the
-   particular behavior is acceptable or even useful, but the full
-   implications should be understood and the case carefully weighed
-   before implementing any behavior described with this label.
-
-
-
-
-
-Bradner                  Best Current Practice                  [Page 1]
-
-RFC 2119                     RFC Key Words                    March 1997
-
-
-5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
-   truly optional.  One vendor may choose to include the item because a
-   particular marketplace requires it or because the vendor feels that
-   it enhances the product while another vendor may omit the same item.
-   An implementation which does not include a particular option MUST be
-   prepared to interoperate with another implementation which does
-   include the option, though perhaps with reduced functionality. In the
-   same vein an implementation which does include a particular option
-   MUST be prepared to interoperate with another implementation which
-   does not include the option (except, of course, for the feature the
-   option provides.)
-
-6. Guidance in the use of these Imperatives
-
-   Imperatives of the type defined in this memo must be used with care
-   and sparingly.  In particular, they MUST only be used where it is
-   actually required for interoperation or to limit behavior which has
-   potential for causing harm (e.g., limiting retransmisssions)  For
-   example, they must not be used to try to impose a particular method
-   on implementors where the method is not required for
-   interoperability.
-
-7. Security Considerations
-
-   These terms are frequently used to specify behavior with security
-   implications.  The effects on security of not implementing a MUST or
-   SHOULD, or doing something the specification says MUST NOT or SHOULD
-   NOT be done may be very subtle. Document authors should take the time
-   to elaborate the security implications of not following
-   recommendations or requirements as most implementors will not have
-   had the benefit of the experience and discussion that produced the
-   specification.
-
-8. Acknowledgments
-
-   The definitions of these terms are an amalgam of definitions taken
-   from a number of RFCs.  In addition, suggestions have been
-   incorporated from a number of people including Robert Ullmann, Thomas
-   Narten, Neal McBurnett, and Robert Elz.
-
-
-
-
-
-
-
-
-
-
-
-
-Bradner                  Best Current Practice                  [Page 2]
-
-RFC 2119                     RFC Key Words                    March 1997
-
-
-9. Author's Address
-
-      Scott Bradner
-      Harvard University
-      1350 Mass. Ave.
-      Cambridge, MA 02138
-
-      phone - +1 617 495 3864
-
-      email - sob@harvard.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bradner                  Best Current Practice                  [Page 3]
-
diff --git a/contrib/bind9/doc/rfc/rfc2133.txt b/contrib/bind9/doc/rfc/rfc2133.txt
deleted file mode 100644
index ea66cf0..0000000
--- a/contrib/bind9/doc/rfc/rfc2133.txt
+++ /dev/null
@@ -1,1795 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        R. Gilligan
-Request for Comments: 2133                                      Freegate
-Category: Informational                                       S. Thomson
-                                                                Bellcore
-                                                                J. Bound
-                                                                 Digital
-                                                              W. Stevens
-                                                              Consultant
-                                                              April 1997
-
-               Basic Socket Interface Extensions for IPv6
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  This memo
-   does not specify an Internet standard of any kind.  Distribution of
-   this memo is unlimited.
-
-Abstract
-
-   The de facto standard application program interface (API) for TCP/IP
-   applications is the "sockets" interface.  Although this API was
-   developed for Unix in the early 1980s it has also been implemented on
-   a wide variety of non-Unix systems.  TCP/IP applications written
-   using the sockets API have in the past enjoyed a high degree of
-   portability and we would like the same portability with IPv6
-   applications.  But changes are required to the sockets API to support
-   IPv6 and this memo describes these changes.  These include a new
-   socket address structure to carry IPv6 addresses, new address
-   conversion functions, and some new socket options.  These extensions
-   are designed to provide access to the basic IPv6 features required by
-   TCP and UDP applications, including multicasting, while introducing a
-   minimum of change into the system and providing complete
-   compatibility for existing IPv4 applications.  Additional extensions
-   for advanced IPv6 features (raw sockets and access to the IPv6
-   extension headers) are defined in another document [5].
-
-Table of Contents
-
-   1.  Introduction ................................................  2
-   2.  Design Considerations .......................................  3
-   2.1.  What Needs to be Changed ..................................  3
-   2.2.  Data Types ................................................  5
-   2.3.  Headers ...................................................  5
-   2.4.  Structures ................................................  5
-   3.  Socket Interface ............................................  5
-   3.1.  IPv6 Address Family and Protocol Family ...................  5
-   3.2.  IPv6 Address Structure ....................................  6
-
-
-
-Gilligan, et. al.            Informational                      [Page 1]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   3.3.  Socket Address Structure for 4.3BSD-Based Systems .........  6
-   3.4.  Socket Address Structure for 4.4BSD-Based Systems .........  7
-   3.5.  The Socket Functions ......................................  8
-   3.6.  Compatibility with IPv4 Applications ......................  9
-   3.7.  Compatibility with IPv4 Nodes .............................  9
-   3.8.  IPv6 Wildcard Address ..................................... 10
-   3.9.  IPv6 Loopback Address ..................................... 11
-   4.  Interface Identification .................................... 12
-   4.1.  Name-to-Index ............................................. 13
-   4.2.  Index-to-Name ............................................. 13
-   4.3.  Return All Interface Names and Indexes .................... 14
-   4.4.  Free Memory ............................................... 14
-   5.  Socket Options .............................................. 14
-   5.1.  Changing Socket Type ...................................... 15
-   5.2.  Unicast Hop Limit ......................................... 16
-   5.3.  Sending and Receiving Multicast Packets ................... 17
-   6.  Library Functions ........................................... 19
-   6.1.  Hostname-to-Address Translation ........................... 19
-   6.2.  Address To Hostname Translation ........................... 22
-   6.3.  Protocol-Independent Hostname and Service Name Translation  22
-   6.4.  Socket Address Structure to Hostname and Service Name ..... 25
-   6.5.  Address Conversion Functions .............................. 27
-   6.6.  Address Testing Macros .................................... 28
-   7.  Summary of New Definitions .................................. 29
-   8.  Security Considerations ..................................... 31
-   9.  Acknowledgments ............................................. 31
-   10.  References ................................................. 31
-   11.  Authors' Addresses ......................................... 32
-
-1.  Introduction
-
-   While IPv4 addresses are 32 bits long, IPv6 interfaces are identified
-   by 128-bit addresses.  The socket interface make the size of an IP
-   address quite visible to an application; virtually all TCP/IP
-   applications for BSD-based systems have knowledge of the size of an
-   IP address.  Those parts of the API that expose the addresses must be
-   changed to accommodate the larger IPv6 address size.  IPv6 also
-   introduces new features (e.g., flow label and priority), some of
-   which must be made visible to applications via the API.  This memo
-   defines a set of extensions to the socket interface to support the
-   larger address size and new features of IPv6.
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 2]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-2.  Design Considerations
-
-   There are a number of important considerations in designing changes
-   to this well-worn API:
-
-   -  The API changes should provide both source and binary
-       compatibility for programs written to the original API.  That is,
-       existing program binaries should continue to operate when run on
-       a system supporting the new API.  In addition, existing
-       applications that are re-compiled and run on a system supporting
-       the new API should continue to operate.  Simply put, the API
-       changes for IPv6 should not break existing programs.
-
-   -  The changes to the API should be as small as possible in order to
-       simplify the task of converting existing IPv4 applications to
-       IPv6.
-
-   -  Where possible, applications should be able to use this API to
-       interoperate with both IPv6 and IPv4 hosts.  Applications should
-       not need to know which type of host they are communicating with.
-
-   -  IPv6 addresses carried in data structures should be 64-bit
-       aligned.  This is necessary in order to obtain optimum
-       performance on 64-bit machine architectures.
-
-   Because of the importance of providing IPv4 compatibility in the API,
-   these extensions are explicitly designed to operate on machines that
-   provide complete support for both IPv4 and IPv6.  A subset of this
-   API could probably be designed for operation on systems that support
-   only IPv6.  However, this is not addressed in this memo.
-
-2.1.  What Needs to be Changed
-
-   The socket interface API consists of a few distinct components:
-
-    -  Core socket functions.
-
-    -  Address data structures.
-
-    -  Name-to-address translation functions.
-
-    -  Address conversion functions.
-
-    The core socket functions -- those functions that deal with such
-    things as setting up and tearing down TCP connections, and sending
-    and receiving UDP packets -- were designed to be transport
-    independent.  Where protocol addresses are passed as function
-    arguments, they are carried via opaque pointers.  A protocol-specific
-
-
-
-Gilligan, et. al.            Informational                      [Page 3]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-    address data structure is defined for each protocol that the socket
-    functions support.  Applications must cast pointers to these
-    protocol-specific address structures into pointers to the generic
-    "sockaddr" address structure when using the socket functions.  These
-    functions need not change for IPv6, but a new IPv6-specific address
-    data structure is needed.
-
-    The "sockaddr_in" structure is the protocol-specific data structure
-    for IPv4.  This data structure actually includes 8-octets of unused
-    space, and it is tempting to try to use this space to adapt the
-    sockaddr_in structure to IPv6.  Unfortunately, the sockaddr_in
-    structure is not large enough to hold the 16-octet IPv6 address as
-    well as the other information (address family and port number) that
-    is needed.  So a new address data structure must be defined for IPv6.
-
-    The name-to-address translation functions in the socket interface are
-    gethostbyname() and gethostbyaddr().  These must be modified to
-    support IPv6 and the semantics defined must provide 100% backward
-    compatibility for all existing IPv4 applications, along with IPv6
-    support for new applications.  Additionally, the POSIX 1003.g work in
-    progress [4] specifies a new hostname-to-address translation function
-    which is protocol independent.  This function can also be used with
-    IPv6.
-
-    The address conversion functions -- inet_ntoa() and inet_addr() --
-    convert IPv4 addresses between binary and printable form.  These
-    functions are quite specific to 32-bit IPv4 addresses.  We have
-    designed two analogous functions that convert both IPv4 and IPv6
-    addresses, and carry an address type parameter so that they can be
-    extended to other protocol families as well.
-
-    Finally, a few miscellaneous features are needed to support IPv6.
-    New interfaces are needed to support the IPv6 flow label, priority,
-    and hop limit header fields.  New socket options are needed to
-    control the sending and receiving of IPv6 multicast packets.
-
-    The socket interface will be enhanced in the future to provide access
-    to other IPv6 features.  These extensions are described in [5].
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 4]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-2.2.  Data Types
-
-   The data types of the structure elements given in this memo are
-   intended to be examples, not absolute requirements.  Whenever
-   possible, POSIX 1003.1g data types are used:  u_intN_t means an
-   unsigned integer of exactly N bits (e.g., u_int16_t) and u_intNm_t
-   means an unsigned integer of at least N bits (e.g., u_int32m_t).  We
-   also assume the argument data types from 1003.1g when possible (e.g.,
-    the final argument to setsockopt() is a size_t value).  Whenever
-   buffer sizes are specified, the POSIX 1003.1 size_t data type is used
-   (e.g., the two length arguments to getnameinfo()).
-
-2.3.  Headers
-
-   When function prototypes and structures are shown we show the headers
-   that must be #included to cause that item to be defined.
-
-2.4.  Structures
-
-   When structures are described the members shown are the ones that
-   must appear in an implementation.  Additional, nonstandard members
-   may also be defined by an implementation.
-
-   The ordering shown for the members of a structure is the recommended
-   ordering, given alignment considerations of multibyte members, but an
-   implementation may order the members differently.
-
-3.  Socket Interface
-
-   This section specifies the socket interface changes for IPv6.
-
-3.1.  IPv6 Address Family and Protocol Family
-
-   A new address family name, AF_INET6, is defined in <sys/socket.h>.
-   The AF_INET6 definition distinguishes between the original
-   sockaddr_in address data structure, and the new sockaddr_in6 data
-   structure.
-
-   A new protocol family name, PF_INET6, is defined in <sys/socket.h>.
-   Like most of the other protocol family names, this will usually be
-   defined to have the same value as the corresponding address family
-   name:
-
-       #define PF_INET6        AF_INET6
-
-   The PF_INET6 is used in the first argument to the socket() function
-   to indicate that an IPv6 socket is being created.
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 5]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-3.2.  IPv6 Address Structure
-
-   A new data structure to hold a single IPv6 address is defined as
-    follows:
-
-       #include <netinet/in.h>
-
-       struct in6_addr {
-           u_int8_t  s6_addr[16];      /* IPv6 address */
-       }
-
-   This data structure contains an array of sixteen 8-bit elements,
-   which make up one 128-bit IPv6 address.  The IPv6 address is stored
-   in network byte order.
-
-3.3.  Socket Address Structure for 4.3BSD-Based Systems
-
-   In the socket interface, a different protocol-specific data structure
-   is defined to carry the addresses for each protocol suite.  Each
-   protocol-specific data structure is designed so it can be cast into a
-   protocol-independent data structure -- the "sockaddr" structure.
-   Each has a "family" field that overlays the "sa_family" of the
-   sockaddr data structure.  This field identifies the type of the data
-   structure.
-
-   The sockaddr_in structure is the protocol-specific address data
-   structure for IPv4.  It is used to pass addresses between
-   applications and the system in the socket functions.  The following
-   structure is defined to carry IPv6 addresses:
-
-       #include <netinet/in.h>
-
-       struct sockaddr_in6 {
-           u_int16m_t      sin6_family;    /* AF_INET6 */
-           u_int16m_t      sin6_port;      /* transport layer port # */
-           u_int32m_t      sin6_flowinfo;  /* IPv6 flow information */
-           struct in6_addr sin6_addr;      /* IPv6 address */
-       };
-
-   This structure is designed to be compatible with the sockaddr data
-   structure used in the 4.3BSD release.
-
-   The sin6_family field identifies this as a sockaddr_in6 structure.
-   This field overlays the sa_family field when the buffer is cast to a
-   sockaddr data structure.  The value of this field must be AF_INET6.
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 6]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The sin6_port field contains the 16-bit UDP or TCP port number.  This
-   field is used in the same way as the sin_port field of the
-   sockaddr_in structure.  The port number is stored in network byte
-   order.
-
-   The sin6_flowinfo field is a 32-bit field that contains two pieces of
-   information: the 24-bit IPv6 flow label and the 4-bit priority field.
-   The contents and interpretation of this member is unspecified at this
-   time.
-
-   The sin6_addr field is a single in6_addr structure (defined in the
-   previous section).  This field holds one 128-bit IPv6 address.  The
-   address is stored in network byte order.
-
-   The ordering of elements in this structure is specifically designed
-   so that the sin6_addr field will be aligned on a 64-bit boundary.
-   This is done for optimum performance on 64-bit architectures.
-
-   Notice that the sockaddr_in6 structure will normally be larger than
-   the generic sockaddr structure.  On many existing implementations the
-   sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both
-   being 16 bytes.  Any existing code that makes this assumption needs
-   to be examined carefully when converting to IPv6.
-
-3.4.  Socket Address Structure for 4.4BSD-Based Systems
-
-   The 4.4BSD release includes a small, but incompatible change to the
-   socket interface.  The "sa_family" field of the sockaddr data
-   structure was changed from a 16-bit value to an 8-bit value, and the
-   space saved used to hold a length field, named "sa_len".  The
-   sockaddr_in6 data structure given in the previous section cannot be
-   correctly cast into the newer sockaddr data structure.  For this
-   reason, the following alternative IPv6 address data structure is
-   provided to be used on systems based on 4.4BSD:
-
-       #include <netinet/in.h>
-
-       #define SIN6_LEN
-
-       struct sockaddr_in6 {
-           u_char          sin6_len;       /* length of this struct */
-           u_char          sin6_family;    /* AF_INET6 */
-           u_int16m_t      sin6_port;      /* transport layer port # */
-           u_int32m_t      sin6_flowinfo;  /* IPv6 flow information */
-           struct in6_addr sin6_addr;      /* IPv6 address */
-       };
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 7]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The only differences between this data structure and the 4.3BSD
-   variant are the inclusion of the length field, and the change of the
-   family field to a 8-bit data type.  The definitions of all the other
-   fields are identical to the structure defined in the previous
-   section.
-
-   Systems that provide this version of the sockaddr_in6 data structure
-   must also declare SIN6_LEN as a result of including the
-   <netinet/in.h> header.  This macro allows applications to determine
-   whether they are being built on a system that supports the 4.3BSD or
-   4.4BSD variants of the data structure.
-
-3.5.  The Socket Functions
-
-   Applications call the socket() function to create a socket descriptor
-   that represents a communication endpoint.  The arguments to the
-   socket() function tell the system which protocol to use, and what
-   format address structure will be used in subsequent functions.  For
-   example, to create an IPv4/TCP socket, applications make the call:
-
-       s = socket(PF_INET, SOCK_STREAM, 0);
-
-   To create an IPv4/UDP socket, applications make the call:
-
-       s = socket(PF_INET, SOCK_DGRAM, 0);
-
-   Applications may create IPv6/TCP and IPv6/UDP sockets by simply using
-   the constant PF_INET6 instead of PF_INET in the first argument.  For
-   example, to create an IPv6/TCP socket, applications make the call:
-
-       s = socket(PF_INET6, SOCK_STREAM, 0);
-
-   To create an IPv6/UDP socket, applications make the call:
-
-       s = socket(PF_INET6, SOCK_DGRAM, 0);
-
-   Once the application has created a PF_INET6 socket, it must use the
-   sockaddr_in6 address structure when passing addresses in to the
-   system.  The functions that the application uses to pass addresses
-   into the system are:
-
-       bind()
-       connect()
-       sendmsg()
-       sendto()
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 8]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The system will use the sockaddr_in6 address structure to return
-   addresses to applications that are using PF_INET6 sockets.  The
-   functions that return an address from the system to an application
-   are:
-
-          accept()
-          recvfrom()
-          recvmsg()
-          getpeername()
-          getsockname()
-
-   No changes to the syntax of the socket functions are needed to
-   support IPv6, since all of the "address carrying" functions use an
-   opaque address pointer, and carry an address length as a function
-   argument.
-
-3.6.  Compatibility with IPv4 Applications
-
-   In order to support the large base of applications using the original
-   API, system implementations must provide complete source and binary
-   compatibility with the original API.  This means that systems must
-   continue to support PF_INET sockets and the sockaddr_in address
-   structure.  Applications must be able to create IPv4/TCP and IPv4/UDP
-   sockets using the PF_INET constant in the socket() function, as
-   described in the previous section.  Applications should be able to
-   hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP
-   sockets simultaneously within the same process.
-
-   Applications using the original API should continue to operate as
-   they did on systems supporting only IPv4.  That is, they should
-   continue to interoperate with IPv4 nodes.
-
-3.7.  Compatibility with IPv4 Nodes
-
-   The API also provides a different type of compatibility: the ability
-   for IPv6 applications to interoperate with IPv4 applications.  This
-   feature uses the IPv4-mapped IPv6 address format defined in the IPv6
-   addressing architecture specification [2].  This address format
-   allows the IPv4 address of an IPv4 node to be represented as an IPv6
-   address.  The IPv4 address is encoded into the low-order 32 bits of
-   the IPv6 address, and the high-order 96 bits hold the fixed prefix
-   0:0:0:0:0:FFFF.  IPv4-mapped addresses are written as follows:
-
-       ::FFFF:<IPv4-address>
-
-   These addresses are often generated automatically by the
-   gethostbyname() function when the specified host has only IPv4
-   addresses (as described in Section 6.1).
-
-
-
-Gilligan, et. al.            Informational                      [Page 9]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   Applications may use PF_INET6 sockets to open TCP connections to IPv4
-   nodes, or send UDP packets to IPv4 nodes, by simply encoding the
-   destination's IPv4 address as an IPv4-mapped IPv6 address, and
-   passing that address, within a sockaddr_in6 structure, in the
-   connect() or sendto() call.  When applications use PF_INET6 sockets
-   to accept TCP connections from IPv4 nodes, or receive UDP packets
-   from IPv4 nodes, the system returns the peer's address to the
-   application in the accept(), recvfrom(), or getpeername() call using
-   a sockaddr_in6 structure encoded this way.
-
-   Few applications will likely need to know which type of node they are
-   interoperating with.  However, for those applications that do need to
-   know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.6, is
-   provided.
-
-3.8.  IPv6 Wildcard Address
-
-   While the bind() function allows applications to select the source IP
-   address of UDP packets and TCP connections, applications often want
-   the system to select the source address for them.  With IPv4, one
-   specifies the address as the symbolic constant INADDR_ANY (called the
-   "wildcard" address) in the bind() call, or simply omits the bind()
-   entirely.
-
-   Since the IPv6 address type is a structure (struct in6_addr), a
-   symbolic constant can be used to initialize an IPv6 address variable,
-   but cannot be used in an assignment.  Therefore systems provide the
-   IPv6 wildcard address in two forms.
-
-   The first version is a global variable named "in6addr_any" that is an
-   in6_addr structure.  The extern declaration for this variable is
-   defined in <netinet/in.h>:
-
-       extern const struct in6_addr in6addr_any;
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 10]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   Applications use in6addr_any similarly to the way they use INADDR_ANY
-   in IPv4.  For example, to bind a socket to port number 23, but let
-   the system select the source address, an application could use the
-   following code:
-
-       struct sockaddr_in6 sin6;
-        . . .
-       sin6.sin6_family = AF_INET6;
-       sin6.sin6_flowinfo = 0;
-       sin6.sin6_port = htons(23);
-       sin6.sin6_addr = in6addr_any;  /* structure assignment */
-        . . .
-       if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
-               . . .
-
-   The other version is a symbolic constant named IN6ADDR_ANY_INIT and
-   is defined in <netinet/in.h>.  This constant can be used to
-   initialize an in6_addr structure:
-
-       struct in6_addr anyaddr = IN6ADDR_ANY_INIT;
-
-   Note that this constant can be used ONLY at declaration time.  It can
-   not be used to assign a previously declared in6_addr structure.  For
-   example, the following code will not work:
-
-       /* This is the WRONG way to assign an unspecified address */
-       struct sockaddr_in6 sin6;
-        . . .
-       sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */
-
-   Be aware that the IPv4 INADDR_xxx constants are all defined in host
-   byte order but the IPv6 IN6ADDR_xxx constants and the IPv6
-   in6addr_xxx externals are defined in network byte order.
-
-3.9.  IPv6 Loopback Address
-
-   Applications may need to send UDP packets to, or originate TCP
-   connections to, services residing on the local node.  In IPv4, they
-   can do this by using the constant IPv4 address INADDR_LOOPBACK in
-   their connect(), sendto(), or sendmsg() call.
-
-   IPv6 also provides a loopback address to contact local TCP and UDP
-   services.  Like the unspecified address, the IPv6 loopback address is
-   provided in two forms -- a global variable and a symbolic constant.
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 11]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The global variable is an in6_addr structure named
-   "in6addr_loopback."  The extern declaration for this variable is
-   defined in <netinet/in.h>:
-
-       extern const struct in6_addr in6addr_loopback;
-
-   Applications use in6addr_loopback as they would use INADDR_LOOPBACK
-   in IPv4 applications (but beware of the byte ordering difference
-   mentioned at the end of the previous section).  For example, to open
-   a TCP connection to the local telnet server, an application could use
-   the following code:
-
-       struct sockaddr_in6 sin6;
-        . . .
-       sin6.sin6_family = AF_INET6;
-       sin6.sin6_flowinfo = 0;
-       sin6.sin6_port = htons(23);
-       sin6.sin6_addr = in6addr_loopback;  /* structure assignment */
-        . . .
-       if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
-               . . .
-
-   The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined
-   in <netinet/in.h>.  It can be used at declaration time ONLY; for
-   example:
-
-       struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT;
-
-   Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment
-   to a previously declared IPv6 address variable.
-
-4.  Interface Identification
-
-   This API uses an interface index (a small positive integer) to
-   identify the local interface on which a multicast group is joined
-   (Section 5.3).  Additionally, the advanced API [5] uses these same
-   interface indexes to identify the interface on which a datagram is
-   received, or to specify the interface on which a datagram is to be
-   sent.
-
-   Interfaces are normally known by names such as "le0", "sl1", "ppp2",
-   and the like.  On Berkeley-derived implementations, when an interface
-   is made known to the system, the kernel assigns a unique positive
-   integer value (called the interface index) to that interface.  These
-   are small positive integers that start at 1.  (Note that 0 is never
-   used for an interface index.)  There may be gaps so that there is no
-   current interface for a particular positive interface index.
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 12]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   This API defines two functions that map between an interface name and
-   index, a third function that returns all the interface names and
-   indexes, and a fourth function to return the dynamic memory allocated
-   by the previous function.  How these functions are implemented is
-   left up to the implementation.  4.4BSD implementations can implement
-   these functions using the existing sysctl() function with the
-   NET_RT_LIST command.  Other implementations may wish to use ioctl()
-   for this purpose.
-
-4.1.  Name-to-Index
-
-   The first function maps an interface name into its corresponding
-   index.
-
-       #include <net/if.h>
-
-       unsigned int  if_nametoindex(const char *ifname);
-
-   If the specified interface does not exist, the return value is 0.
-
-4.2.  Index-to-Name
-
-   The second function maps an interface index into its corresponding
-   name.
-
-       #include <net/if.h>
-
-       char  *if_indextoname(unsigned int ifindex, char *ifname);
-
-   The ifname argument must point to a buffer of at least IFNAMSIZ bytes
-   into which the interface name corresponding to the specified index is
-   returned.  (IFNAMSIZ is also defined in <net/if.h> and its value
-   includes a terminating null byte at the end of the interface name.)
-   This pointer is also the return value of the function.  If there is
-   no interface corresponding to the specified index, NULL is returned.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 13]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-4.3.  Return All Interface Names and Indexes
-
-   The final function returns an array of if_nameindex structures, one
-   structure per interface.
-
-       #include <net/if.h>
-
-       struct if_nameindex {
-         unsigned int   if_index;  /* 1, 2, ... */
-         char          *if_name;   /* null terminated name: "le0", ... */
-       };
-
-       struct if_nameindex  *if_nameindex(void);
-
-   The end of the array of structures is indicated by a structure with
-   an if_index of 0 and an if_name of NULL.  The function returns a NULL
-   pointer upon an error.
-
-   The memory used for this array of structures along with the interface
-   names pointed to by the if_name members is obtained dynamically.
-   This memory is freed by the next function.
-
-4.4.  Free Memory
-
-   The following function frees the dynamic memory that was allocated by
-   if_nameindex().
-
-       #include <net/if.h>
-
-       void  if_freenameindex(struct if_nameindex *ptr);
-
-   The argument to this function must be a pointer that was returned by
-   if_nameindex().
-
-5.  Socket Options
-
-   A number of new socket options are defined for IPv6.  All of these
-   new options are at the IPPROTO_IPV6 level.  That is, the "level"
-   parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6
-   when using these options.  The constant name prefix IPV6_ is used in
-   all of the new socket options.  This serves to clearly identify these
-   options as applying to IPv6.
-
-   The declaration for IPPROTO_IPV6, the new IPv6 socket options, and
-   related constants defined in this section are obtained by including
-   the header <netinet/in.h>.
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 14]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-5.1.  Changing Socket Type
-
-   Unix allows open sockets to be passed between processes via the
-   exec() call and other means.  It is a relatively common application
-   practice to pass open sockets across exec() calls.  Thus it is
-   possible for an application using the original API to pass an open
-   PF_INET socket to an application that is expecting to receive a
-   PF_INET6 socket.  Similarly, it is possible for an application using
-   the extended API to pass an open PF_INET6 socket to an application
-   using the original API, which would be equipped only to deal with
-   PF_INET sockets.  Either of these cases could cause problems, because
-   the application that is passed the open socket might not know how to
-   decode the address structures returned in subsequent socket
-   functions.
-
-   To remedy this problem, a new setsockopt() option is defined that
-   allows an application to "convert" a PF_INET6 socket into a PF_INET
-   socket and vice versa.
-
-   An IPv6 application that is passed an open socket from an unknown
-   process may use the IPV6_ADDRFORM setsockopt() option to "convert"
-   the socket to PF_INET6.  Once that has been done, the system will
-   return sockaddr_in6 address structures in subsequent socket
-   functions.
-
-   An IPv6 application that is about to pass an open PF_INET6 socket to
-   a program that is not be IPv6 capable can "downgrade" the socket to
-   PF_INET before calling exec().  After that, the system will return
-   sockaddr_in address structures to the application that was exec()'ed.
-   Be aware that you cannot downgrade an IPv6 socket to an IPv4 socket
-   unless all nonwildcard addresses already associated with the IPv6
-   socket are IPv4-mapped IPv6 addresses.
-
-   The IPV6_ADDRFORM option is valid at both the IPPROTO_IP and
-   IPPROTO_IPV6 levels.  The only valid option values are PF_INET6 and
-   PF_INET.  For example, to convert a PF_INET6 socket to PF_INET, a
-   program would call:
-
-       int  addrform = PF_INET;
-
-       if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDRFORM,
-                      (char *) &addrform, sizeof(addrform)) == -1)
-           perror("setsockopt IPV6_ADDRFORM");
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 15]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   An application may use IPV6_ADDRFORM with getsockopt() to learn
-   whether an open socket is a PF_INET of PF_INET6 socket.  For example:
-
-       int  addrform;
-       size_t  len = sizeof(addrform);
-
-       if (getsockopt(s, IPPROTO_IPV6, IPV6_ADDRFORM,
-                      (char *) &addrform, &len) == -1)
-           perror("getsockopt IPV6_ADDRFORM");
-       else if (addrform == PF_INET)
-           printf("This is an IPv4 socket.\n");
-       else if (addrform == PF_INET6)
-           printf("This is an IPv6 socket.\n");
-       else
-           printf("This system is broken.\n");
-
-5.2.  Unicast Hop Limit
-
-   A new setsockopt() option controls the hop limit used in outgoing
-   unicast IPv6 packets.  The name of this option is IPV6_UNICAST_HOPS,
-   and it is used at the IPPROTO_IPV6 layer.  The following example
-   illustrates how it is used:
-
-       int  hoplimit = 10;
-
-       if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
-                      (char *) &hoplimit, sizeof(hoplimit)) == -1)
-           perror("setsockopt IPV6_UNICAST_HOPS");
-
-   When the IPV6_UNICAST_HOPS option is set with setsockopt(), the
-   option value given is used as the hop limit for all subsequent
-   unicast packets sent via that socket.  If the option is not set, the
-   system selects a default value.  The integer hop limit value (called
-   x) is interpreted as follows:
-
-       x < -1:        return an error of EINVAL
-       x == -1:       use kernel default
-       0 <= x <= 255: use x
-       x >= 256:      return an error of EINVAL
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 16]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The IPV6_UNICAST_HOPS option may be used with getsockopt() to
-   determine the hop limit value that the system will use for subsequent
-   unicast packets sent via that socket.  For example:
-
-       int  hoplimit;
-       size_t  len = sizeof(hoplimit);
-
-       if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
-                      (char *) &hoplimit, &len) == -1)
-           perror("getsockopt IPV6_UNICAST_HOPS");
-       else
-           printf("Using %d for hop limit.\n", hoplimit);
-
-5.3.  Sending and Receiving Multicast Packets
-
-   IPv6 applications may send UDP multicast packets by simply specifying
-   an IPv6 multicast address in the address argument of the sendto()
-   function.
-
-   Three socket options at the IPPROTO_IPV6 layer control some of the
-   parameters for sending multicast packets.  Setting these options is
-   not required:  applications may send multicast packets without using
-   these options.  The setsockopt() options for controlling the sending
-   of multicast packets are summarized below:
-
-       IPV6_MULTICAST_IF
-
-           Set the interface to use for outgoing multicast packets.  The
-           argument is the index of the interface to use.
-
-           Argument type: unsigned int
-
-       IPV6_MULTICAST_HOPS
-
-           Set the hop limit to use for outgoing multicast packets.
-           (Note a separate option - IPV6_UNICAST_HOPS - is provided to
-           set the hop limit to use for outgoing unicast packets.)  The
-           interpretation of the argument is the same as for the
-           IPV6_UNICAST_HOPS option:
-
-               x < -1:        return an error of EINVAL
-               x == -1:       use kernel default
-               0 <= x <= 255: use x
-               x >= 256:      return an error of EINVAL
-
-           Argument type: int
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 17]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-       IPV6_MULTICAST_LOOP
-
-           Controls whether outgoing multicast packets  sent  should  be
-           delivered  back  to the local application.  A toggle.  If the
-           option is set to 1, multicast packets are looped back.  If it
-           is set to 0, they are not.
-
-           Argument type: unsigned int
-
-   The reception of multicast packets is controlled by the two
-   setsockopt() options summarized below:
-
-       IPV6_ADD_MEMBERSHIP
-
-           Join a multicast group on a specified local interface.  If
-           the interface index is specified as 0, the kernel chooses the
-           local interface.  For example, some kernels look up the
-           multicast group in the normal IPv6 routing table and using
-           the resulting interface.
-
-           Argument type: struct ipv6_mreq
-
-       IPV6_DROP_MEMBERSHIP
-
-           Leave a multicast group on a specified interface.
-
-           Argument type: struct ipv6_mreq
-
-   The argument type of both of these options is the ipv6_mreq
-   structure, defined as:
-
-       #include <netinet/in.h>
-
-       struct ipv6_mreq {
-           struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
-           unsigned int    ipv6mr_interface; /* interface index */
-       };
-
-   Note that to receive multicast datagrams a process must join the
-   multicast group and bind the UDP port to which datagrams will be
-   sent.  Some processes also bind the multicast group address to the
-   socket, in addition to the port, to prevent other datagrams destined
-   to that same port from being delivered to the socket.
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 18]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-6.  Library Functions
-
-   New library functions are needed to perform a variety of operations
-   with IPv6 addresses.  Functions are needed to lookup IPv6 addresses
-   in the Domain Name System (DNS).  Both forward lookup (hostname-to-
-   address translation) and reverse lookup (address-to-hostname
-   translation) need to be supported.  Functions are also needed to
-   convert IPv6 addresses between their binary and textual form.
-
-6.1.  Hostname-to-Address Translation
-
-   The commonly used function gethostbyname() remains unchanged as does
-   the hostent structure to which it returns a pointer.  Existing
-   applications that call this function continue to receive only IPv4
-   addresses that are the result of a query in the DNS for A records.
-   (We assume the DNS is being used; some environments may be using a
-   hosts file or some other name resolution system, either of which may
-   impede renumbering.  We also assume that the RES_USE_INET6 resolver
-   option is not set, which we describe in more detail shortly.)
-
-   Two new changes are made to support IPv6 addresses.  First, the
-   following function is new:
-
-       #include <sys/socket.h>
-       #include <netdb.h>
-
-       struct hostent *gethostbyname2(const char *name, int af);
-
-   The af argument specifies the address family.  The default operation
-   of this function is simple:
-
-    -  If the af argument is AF_INET, then a query is made for A
-       records.  If successful, IPv4 addresses are returned and the
-       h_length member of the hostent structure will be 4, else the
-       function returns a NULL pointer.
-
-    -  If the af argument is AF_INET6, then a query is made for AAAA
-       records.  If successful, IPv6 addresses are returned and the
-       h_length member of the hostent structure will be 16, else the
-       function returns a NULL pointer.
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 19]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The second change, that provides additional functionality, is a new
-   resolver option RES_USE_INET6, which is defined as a result of
-   including the <resolv.h> header.  (This option is provided starting
-   with the BIND 4.9.4 release.)  There are three ways to set this
-   option.
-
-    -  The first way is
-
-           res_init();
-           _res.options |= RES_USE_INET6;
-
-       and then call either gethostbyname() or gethostbyname2().  This
-       option then affects only the process that is calling the
-       resolver.
-
-    -  The second way to set this option is to set the environment
-       variable RES_OPTIONS, as in RES_OPTIONS=inet6.  (This example is
-       for the Bourne and Korn shells.)  This method affects any
-       processes that see this environment variable.
-
-    -  The third way is to set this option in the resolver configuration
-       file (normally /etc/resolv.conf) and the option then affects all
-       applications on the host.  This final method should not be done
-       until all applications on the host are capable of dealing with
-       IPv6 addresses.
-
-   There is no priority among these three methods.  When the
-   RES_USE_INET6 option is set, two changes occur:
-
-    -  gethostbyname(host) first calls gethostbyname2(host, AF_INET6)
-       looking for AAAA records, and if this fails it then calls
-       gethostbyname2(host, AF_INET) looking for A records.
-
-    -  gethostbyname2(host, AF_INET) always returns IPv4-mapped IPv6
-       addresses with the h_length member of the hostent structure set
-       to 16.
-
-   An application must not enable the RES_USE_INET6 option until it is
-   prepared to deal with 16-byte addresses in the returned hostent
-   structure.
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 20]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The following table summarizes the operation of the existing
-   gethostbyname() function, the new function gethostbyname2(), along
-   with the new resolver option RES_USE_INET6.
-
-+------------------+---------------------------------------------------+
-|                  |              RES_USE_INET6 option                 |
-|                  +-------------------------+-------------------------+
-|                  |          off            |           on            |
-+------------------+-------------------------+-------------------------+
-|                  |Search for A records.    |Search for AAAA records. |
-| gethostbyname    | If found, return IPv4   | If found, return IPv6   |
-| (host)           | addresses (h_length=4). | addresses (h_length=16).|
-|                  | Else error.             | Else search for A       |
-|                  |                         | records.  If found,     |
-|                  |Provides backward        | return IPv4-mapped IPv6 |
-|                  | compatibility with all  | addresses (h_length=16).|
-|                  | existing IPv4 appls.    | Else error.             |
-+------------------+-------------------------+-------------------------+
-|                  |Search for A records.    |Search for A records.    |
-| gethostbyname2   | If found, return IPv4   | If found, return        |
-| (host, AF_INET)  | addresses (h_length=4). | IPv4-mapped IPv6        |
-|                  | Else error.             | addresses (h_length=16).|
-|                  |                         | Else error.             |
-+------------------+-------------------------+-------------------------+
-|                  |Search for AAAA records. |Search for AAAA records. |
-| gethostbyname2   | If found, return IPv6   | If found, return IPv6   |
-| (host, AF_INET6) | addresses (h_length=16).| addresses (h_length=16).|
-|                  | Else error.             | Else error.             |
-+------------------+-------------------------+-------------------------+
-
-   It is expected that when a typical naive application that calls
-   gethostbyname() today is modified to use IPv6, it simply changes the
-   program to use IPv6 sockets and then enables the RES_USE_INET6
-   resolver option before calling gethostbyname().  This application
-   will then work with either IPv4 or IPv6 peers.
-
-   Note that gethostbyname() and gethostbyname2() are not thread-safe,
-   since both return a pointer to a static hostent structure.  But
-   several vendors have defined a thread-safe gethostbyname_r() function
-   that requires four additional arguments.  We expect these vendors to
-   also define a gethostbyname2_r() function.
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 21]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-6.2.  Address To Hostname Translation
-
-   The existing gethostbyaddr() function already requires an address
-   family argument and can therefore work with IPv6 addresses:
-
-       #include <sys/socket.h>
-       #include <netdb.h>
-
-       struct hostent *gethostbyaddr(const char *src, int len, int af);
-
-   One possible source of confusion is the handling of IPv4-mapped IPv6
-   addresses and IPv4-compatible IPv6 addresses.  This is addressed in
-   [6] and involves the following logic:
-
-    1.  If af is AF_INET6, and if len equals 16, and if the IPv6 address
-        is an IPv4-mapped IPv6 address or an IPv4-compatible IPv6
-        address, then skip over the first 12 bytes of the IPv6 address,
-        set af to AF_INET, and set len to 4.
-
-    2.  If af is AF_INET, then query for a PTR record in the in-
-        addr.arpa domain.
-
-    3.  If af is AF_INET6, then query for a PTR record in the ip6.int
-        domain.
-
-    4.  If the function is returning success, and if af equals AF_INET,
-        and if the RES_USE_INET6 option was set, then the single address
-        that is returned in the hostent structure (a copy of the first
-        argument to the function) is returned as an IPv4-mapped IPv6
-        address and the h_length member is set to 16.
-
-   All four steps listed are performed, in order.  The same caveats
-   regarding a thread-safe version of gethostbyname() that were made at
-   the end of the previous section apply here as well.
-
-6.3.  Protocol-Independent Hostname and Service Name Translation
-
-   Hostname-to-address translation is done in a protocol-independent
-   fashion using the getaddrinfo() function that is taken from the
-   Institute of Electrical and Electronic Engineers (IEEE) POSIX 1003.1g
-   (Protocol Independent Interfaces) work in progress specification [4].
-
-   The official specification for this function will be the final POSIX
-   standard.  We are providing this independent description of the
-   function because POSIX standards are not freely available (as are
-   IETF documents).  Should there be any discrepancies between this
-   description and the POSIX description, the POSIX description takes
-   precedence.
-
-
-
-Gilligan, et. al.            Informational                     [Page 22]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-       #include <sys/socket.h>
-       #include <netdb.h>
-
-       int getaddrinfo(const char *hostname, const char *servname,
-                       const struct addrinfo *hints,
-                       struct addrinfo **res);
-
-   The addrinfo structure is defined as:
-
-       #include <sys/socket.h>
-       #include <netdb.h>
-
-       struct addrinfo {
-         int     ai_flags;     /* AI_PASSIVE, AI_CANONNAME */
-         int     ai_family;    /* PF_xxx */
-         int     ai_socktype;  /* SOCK_xxx */
-         int     ai_protocol;  /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
-         size_t  ai_addrlen;   /* length of ai_addr */
-         char   *ai_canonname; /* canonical name for hostname */
-         struct sockaddr  *ai_addr; /* binary address */
-         struct addrinfo  *ai_next; /* next structure in linked list */
-       };
-
-   The return value from the function is 0 upon success or a nonzero
-   error code.  The following names are the nonzero error codes from
-   getaddrinfo(), and are defined in <netdb.h>:
-
-       EAI_ADDRFAMILY  address family for hostname not supported
-       EAI_AGAIN       temporary failure in name resolution
-       EAI_BADFLAGS    invalid value for ai_flags
-       EAI_FAIL        non-recoverable failure in name resolution
-       EAI_FAMILY      ai_family not supported
-       EAI_MEMORY      memory allocation failure
-       EAI_NODATA      no address associated with hostname
-       EAI_NONAME      hostname nor servname provided, or not known
-       EAI_SERVICE     servname not supported for ai_socktype
-       EAI_SOCKTYPE    ai_socktype not supported
-       EAI_SYSTEM      system error returned in errno
-
-   The hostname and servname arguments are pointers to null-terminated
-   strings or NULL.  One or both of these two arguments must be a non-
-   NULL pointer.  In the normal client scenario, both the hostname and
-   servname are specified.  In the normal server scenario, only the
-   servname is specified.  A non-NULL hostname string can be either a
-   host name or a numeric host address string (i.e., a dotted-decimal
-   IPv4 address or an IPv6 hex address).  A non-NULL servname string can
-   be either a service name or a decimal port number.
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 23]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The caller can optionally pass an addrinfo structure, pointed to by
-   the third argument, to provide hints concerning the type of socket
-   that the caller supports.  In this hints structure all members other
-   than ai_flags, ai_family, ai_socktype, and ai_protocol must be zero
-   or a NULL pointer.  A value of PF_UNSPEC for ai_family means the
-   caller will accept any protocol family.  A value of 0 for ai_socktype
-   means the caller will accept any socket type.  A value of 0 for
-   ai_protocol means the caller will accept any protocol.  For example,
-   if the caller handles only TCP and not UDP, then the ai_socktype
-   member of the hints structure should be set to SOCK_STREAM when
-   getaddrinfo() is called.  If the caller handles only IPv4 and not
-   IPv6, then the ai_family member of the hints structure should be set
-   to PF_INET when getaddrinfo() is called.  If the third argument to
-   getaddrinfo() is a NULL pointer, this is the same as if the caller
-   had filled in an addrinfo structure initialized to zero with
-   ai_family set to PF_UNSPEC.
-
-   Upon successful return a pointer to a linked list of one or more
-   addrinfo structures is returned through the final argument.  The
-   caller can process each addrinfo structure in this list by following
-   the ai_next pointer, until a NULL pointer is encountered.  In each
-   returned addrinfo structure the three members ai_family, ai_socktype,
-   and ai_protocol are the corresponding arguments for a call to the
-   socket() function.  In each addrinfo structure the ai_addr member
-   points to a filled-in socket address structure whose length is
-   specified by the ai_addrlen member.
-
-   If the AI_PASSIVE bit is set in the ai_flags member of the hints
-   structure, then the caller plans to use the returned socket address
-   structure in a call to bind().  In this case, if the hostname
-   argument is a NULL pointer, then the IP address portion of the socket
-   address structure will be set to INADDR_ANY for an IPv4 address or
-   IN6ADDR_ANY_INIT for an IPv6 address.
-
-   If the AI_PASSIVE bit is not set in the ai_flags member of the hints
-   structure, then the returned socket address structure will be ready
-   for a call to connect() (for a connection-oriented protocol) or
-   either connect(), sendto(), or sendmsg() (for a connectionless
-   protocol).  In this case, if the hostname argument is a NULL pointer,
-   then the IP address portion of the socket address structure will be
-   set to the loopback address.
-
-   If the AI_CANONNAME bit is set in the ai_flags member of the hints
-   structure, then upon successful return the ai_canonname member of the
-   first addrinfo structure in the linked list will point to a null-
-   terminated string containing the canonical name of the specified
-   hostname.
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 24]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   All of the information returned by getaddrinfo() is dynamically
-   allocated: the addrinfo structures, and the socket address structures
-   and canonical host name strings pointed to by the addrinfo
-   structures.  To return this information to the system the function
-   freeaddrinfo() is called:
-
-       #include <sys/socket.h>
-       #include <netdb.h>
-
-       void freeaddrinfo(struct addrinfo *ai);
-
-   The addrinfo structure pointed to by the ai argument is freed, along
-   with any dynamic storage pointed to by the structure.  This operation
-   is repeated until a NULL ai_next pointer is encountered.
-
-   To aid applications in printing error messages based on the EAI_xxx
-   codes returned by getaddrinfo(), the following function is defined.
-
-       #include <sys/socket.h>
-       #include <netdb.h>
-
-       char *gai_strerror(int ecode);
-
-   The argument is one of the EAI_xxx values defined earlier and the
-   eturn value points to a string describing the error.  If the argument
-   is not one of the EAI_xxx values, the function still returns a
-   pointer to a string whose contents indicate an unknown error.
-
-6.4.  Socket Address Structure to Hostname and Service Name
-
-   The POSIX 1003.1g specification includes no function to perform the
-   reverse conversion from getaddrinfo():  to look up a hostname and
-   service name, given the binary address and port.  Therefore, we
-   define the following function:
-
-       #include <sys/socket.h>
-       #include <netdb.h>
-
-       int getnameinfo(const struct sockaddr *sa, size_t salen,
-                       char *host, size_t hostlen,
-                       char *serv, size_t servlen,
-                       int flags);
-
-   This function looks up an IP address and port number provided by the
-   caller in the DNS and system-specific database, and returns text
-   strings for both in buffers provided by the caller.  The function
-   indicates successful completion by a zero return value; a non-zero
-   return value indicates failure.
-
-
-
-Gilligan, et. al.            Informational                     [Page 25]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The first argument, sa, points to either a sockaddr_in structure (for
-   IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP
-   address and port number.  The salen argument gives the length of the
-   sockaddr_in or sockaddr_in6 structure.
-
-   The function returns the hostname associated with the IP address in
-   the buffer pointed to by the host argument.  The caller provides the
-   size of this buffer via the hostlen argument.  The service name
-   associated with the port number is returned in the buffer pointed to
-   by serv, and the servlen argument gives the length of this buffer.
-   The caller specifies not to return either string by providing a zero
-   value for the hostlen or servlen arguments.  Otherwise, the caller
-   must provide buffers large enough to hold the hostname and the
-   service name, including the terminating null characters.
-
-   Unfortunately most systems do not provide constants that specify the
-   maximum size of either a fully-qualified domain name or a service
-   name.  Therefore to aid the application in allocating buffers for
-   these two returned strings the following constants are defined in
-   <netdb.h>:
-
-       #define NI_MAXHOST  1025
-       #define NI_MAXSERV    32
-
-   The first value is actually defined as the constant MAXDNAME in
-   recent versions of BIND's <arpa/nameser.h> header (older versions of
-   BIND define this constant to be 256) and the second is a guess based
-   on the services listed in the current Assigned Numbers RFC.
-
-   The final argument is a flag that changes the default actions of this
-   function.  By default the fully-qualified domain name (FQDN) for the
-   host is looked up in the DNS and returned.  If the flag bit NI_NOFQDN
-   is set, only the hostname portion of the FQDN is returned for local
-   hosts.
-
-   If the flag bit NI_NUMERICHOST is set, or if the host's name cannot
-   be located in the DNS, the numeric form of the host's address is
-   returned instead of its name (e.g., by calling inet_ntop() instead of
-   gethostbyaddr()).  If the flag bit NI_NAMEREQD is set, an error is
-   returned if the host's name cannot be located in the DNS.
-
-   If the flag bit NI_NUMERICSERV is set, the numeric form of the
-   service address is returned (e.g., its port number) instead of its
-   name.  The two NI_NUMERICxxx flags are required to support the "-n"
-   flag that many commands provide.
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 26]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   A fifth flag bit, NI_DGRAM, specifies that the service 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.
-
-   These NI_xxx flags are defined in <netdb.h> along with the AI_xxx
-   flags already defined for getaddrinfo().
-
-6.5.  Address Conversion Functions
-
-   The two functions inet_addr() and inet_ntoa() convert an IPv4 address
-   between binary and text form.  IPv6 applications need similar
-   functions.  The following two functions convert both IPv6 and IPv4
-   addresses:
-
-       #include <sys/socket.h>
-       #include <arpa/inet.h>
-
-       int inet_pton(int af, const char *src, void *dst);
-
-       const char *inet_ntop(int af, const void *src,
-                             char *dst, size_t size);
-
-   The inet_pton() function converts an address in its standard text
-   presentation form into its numeric binary form.  The af argument
-   specifies the family of the address.  Currently the AF_INET and
-   AF_INET6 address families are supported.  The src argument points to
-   the string being passed in.  The dst argument points to a buffer into
-   which the function stores the numeric address.  The address is
-   returned in network byte order.  Inet_pton() returns 1 if the
-   conversion succeeds, 0 if the input is not a valid IPv4 dotted-
-   decimal string or a valid IPv6 address string, or -1 with errno set
-   to EAFNOSUPPORT if the af argument is unknown.  The calling
-   application must ensure that the buffer referred to by dst is large
-   enough to hold the numeric address (e.g., 4 bytes for AF_INET or 16
-   bytes for AF_INET6).
-
-   If the af argument is AF_INET, the function accepts a string in the
-   standard IPv4 dotted-decimal form:
-
-       ddd.ddd.ddd.ddd
-
-   where ddd is a one to three digit decimal number between 0 and 255.
-   Note that many implementations of the existing inet_addr() and
-   inet_aton() functions accept nonstandard input:  octal numbers,
-   hexadecimal numbers, and fewer than four numbers.  inet_pton() does
-   not accept these formats.
-
-
-
-Gilligan, et. al.            Informational                     [Page 27]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   If the af argument is AF_INET6, then the function accepts a string in
-   one of the standard IPv6 text forms defined in Section 2.2 of the
-   addressing architecture specification [2].
-
-   The inet_ntop() function converts a numeric address into a text
-   string suitable for presentation.  The af argument specifies the
-   family of the address.  This can be AF_INET or AF_INET6.  The src
-   argument points to a buffer holding an IPv4 address if the af
-   argument is AF_INET, or an IPv6 address if the af argument is
-   AF_INET6.  The dst argument points to a buffer where the function
-   will store the resulting text string.  The size argument specifies
-   the size of this buffer.  The application must specify a non-NULL dst
-   argument.  For IPv6 addresses, the buffer must be at least 46-octets.
-   For IPv4 addresses, the buffer must be at least 16-octets.  In order
-   to allow applications to easily declare buffers of the proper size to
-   store IPv4 and IPv6 addresses in string form, the following two
-   constants are defined in <netinet/in.h>:
-
-       #define INET_ADDRSTRLEN    16
-       #define INET6_ADDRSTRLEN   46
-
-   The inet_ntop() function returns a pointer to the buffer containing
-   the text string if the conversion succeeds, and NULL otherwise.  Upon
-   failure, errno is set to EAFNOSUPPORT if the af argument is invalid
-   or ENOSPC if the size of the result buffer is inadequate.
-
-6.6.  Address Testing Macros
-
-   The following macros can be used to test for special IPv6 addresses.
-
-       #include <netinet/in.h>
-
-       int  IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *);
-       int  IN6_IS_ADDR_LOOPBACK    (const struct in6_addr *);
-       int  IN6_IS_ADDR_MULTICAST   (const struct in6_addr *);
-       int  IN6_IS_ADDR_LINKLOCAL   (const struct in6_addr *);
-       int  IN6_IS_ADDR_SITELOCAL   (const struct in6_addr *);
-       int  IN6_IS_ADDR_V4MAPPED    (const struct in6_addr *);
-       int  IN6_IS_ADDR_V4COMPAT    (const struct in6_addr *);
-
-       int  IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
-       int  IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
-       int  IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
-       int  IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *);
-       int  IN6_IS_ADDR_MC_GLOBAL   (const struct in6_addr *);
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 28]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   The first seven macros return true if the address is of the specified
-   type, or false otherwise.  The last five test the scope of a
-   multicast address and return true if the address is a multicast
-   address of the specified scope or false if the address is either not
-   a multicast address or not of the specified scope.
-
-7.  Summary of New Definitions
-
-   The following list summarizes the constants, structure, and extern
-   definitions discussed in this memo, sorted by header.
-
-     <net/if.h>      IFNAMSIZ
-     <net/if.h>      struct if_nameindex{};
-
-     <netdb.h>       AI_CANONNAME
-     <netdb.h>       AI_PASSIVE
-     <netdb.h>       EAI_ADDRFAMILY
-     <netdb.h>       EAI_AGAIN
-     <netdb.h>       EAI_BADFLAGS
-     <netdb.h>       EAI_FAIL
-     <netdb.h>       EAI_FAMILY
-     <netdb.h>       EAI_MEMORY
-     <netdb.h>       EAI_NODATA
-     <netdb.h>       EAI_NONAME
-     <netdb.h>       EAI_SERVICE
-     <netdb.h>       EAI_SOCKTYPE
-     <netdb.h>       EAI_SYSTEM
-     <netdb.h>       NI_DGRAM
-     <netdb.h>       NI_MAXHOST
-     <netdb.h>       NI_MAXSERV
-     <netdb.h>       NI_NAMEREQD
-     <netdb.h>       NI_NOFQDN
-     <netdb.h>       NI_NUMERICHOST
-     <netdb.h>       NI_NUMERICSERV
-     <netdb.h>       struct addrinfo{};
-
-     <netinet/in.h>  IN6ADDR_ANY_INIT
-     <netinet/in.h>  IN6ADDR_LOOPBACK_INIT
-     <netinet/in.h>  INET6_ADDRSTRLEN
-     <netinet/in.h>  INET_ADDRSTRLEN
-     <netinet/in.h>  IPPROTO_IPV6
-     <netinet/in.h>  IPV6_ADDRFORM
-     <netinet/in.h>  IPV6_ADD_MEMBERSHIP
-     <netinet/in.h>  IPV6_DROP_MEMBERSHIP
-     <netinet/in.h>  IPV6_MULTICAST_HOPS
-     <netinet/in.h>  IPV6_MULTICAST_IF
-     <netinet/in.h>  IPV6_MULTICAST_LOOP
-     <netinet/in.h>  IPV6_UNICAST_HOPS
-
-
-
-Gilligan, et. al.            Informational                     [Page 29]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-     <netinet/in.h>  SIN6_LEN
-     <netinet/in.h>  extern const struct in6_addr in6addr_any;
-     <netinet/in.h>  extern const struct in6_addr in6addr_loopback;
-     <netinet/in.h>  struct in6_addr{};
-     <netinet/in.h>  struct ipv6_mreq{};
-     <netinet/in.h>  struct sockaddr_in6{};
-
-     <resolv.h>      RES_USE_INET6
-
-     <sys/socket.h>  AF_INET6
-     <sys/socket.h>  PF_INET6
-
-
-   The following list summarizes the function and macro prototypes
-   discussed in this memo, sorted by header.
-
-<arpa/inet.h>   int inet_pton(int, const char *, void *);
-<arpa/inet.h>   const char *inet_ntop(int, const void *,
-                                      char *, size_t);
-
-<net/if.h>      char *if_indextoname(unsigned int, char *);
-<net/if.h>      unsigned int if_nametoindex(const char *);
-<net/if.h>      void if_freenameindex(struct if_nameindex *);
-<net/if.h>      struct if_nameindex *if_nameindex(void);
-
-<netdb.h>       int getaddrinfo(const char *, const char *,
-                                const struct addrinfo *,
-                                struct addrinfo **);
-<netdb.h>       int getnameinfo(const struct sockaddr *, size_t,
-                                char *, size_t, char *, size_t, int);
-<netdb.h>       void freeaddrinfo(struct addrinfo *);
-<netdb.h>       char *gai_strerror(int);
-<netdb.h>       struct hostent *gethostbyname(const char *);
-<netdb.h>       struct hostent *gethostbyaddr(const char *, int, int);
-<netdb.h>       struct hostent *gethostbyname2(const char *, int);
-
-<netinet/in.h>  int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MULTICAST(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *);
-
-
-
-Gilligan, et. al.            Informational                     [Page 30]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-8.  Security Considerations
-
-   IPv6 provides a number of new security mechanisms, many of which need
-   to be accessible to applications.  A companion memo detailing the
-   extensions to the socket interfaces to support IPv6 security is being
-   written [3].
-
-9.  Acknowledgments
-
-   Thanks to the many people who made suggestions and provided feedback
-   to to the numerous revisions of this document, including: Werner
-   Almesberger, Ran Atkinson, Fred Baker, Dave Borman, Andrew Cherenson,
-   Alex Conta, Alan Cox, Steve Deering, Richard Draves, Francis Dupont,
-   Robert Elz, Marc Hasson, Tim Hartrick, Tom Herbert, Bob Hinden, Wan-
-   Yen Hsu, Christian Huitema, Koji Imada, Markus Jork, Ron Lee, Alan
-   Lloyd, Charles Lynn, Jack McCann, Dan McDonald, Dave Mitton, Thomas
-   Narten, Erik Nordmark, Josh Osborne, Craig Partridge, Jean-Luc
-   Richier, Erik Scoredos, Keith Sklower, Matt Thomas, Harvey Thompson,
-   Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David
-   Waitzman, Carl Williams, and Kazuhiko Yamamoto,
-
-   The getaddrinfo() and getnameinfo() functions are taken from an
-   earlier Work in Progress by Keith Sklower.  As noted in that
-   document, William Durst, Steven Wise, Michael Karels, and Eric Allman
-   provided many useful discussions on the subject of protocol-
-   independent name-to-address translation, and reviewed early versions
-   of Keith Sklower's original proposal.  Eric Allman implemented the
-   first prototype of getaddrinfo().  The observation that specifying
-   the pair of name and service would suffice for connecting to a
-   service independent of protocol details was made by Marshall Rose in
-   a proposal to X/Open for a "Uniform Network Interface".
-
-   Craig Metz made many contributions to this document.  Ramesh Govindan
-   made a number of contributions and co-authored an earlier version of
-   this memo.
-
-10.  References
-
-   [1] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6)
-       Specification", RFC 1883, December 1995.
-
-   [2] Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture",
-       RFC 1884, December 1995.
-
-   [3] McDonald, D., "A Simple IP Security API Extension to BSD Sockets",
-       Work in Progress.
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 31]
-
-RFC 2133            IPv6 Socket Interface Extensions          April 1997
-
-
-   [4] IEEE, "Protocol Independent Interfaces", IEEE Std 1003.1g, DRAFT
-       6.3, November 1995.
-
-   [5] Stevens, W., and M. Thomas, "Advanced Sockets API for IPv6",
-       Work in Progress.
-
-   [6] Vixie, P., "Reverse Name Lookups of Encapsulated IPv4 Addresses in
-       IPv6", Work in Progress.
-
-11.  Authors' Addresses
-
-    Robert E. Gilligan
-    Freegate Corporation
-    710 Lakeway Dr.  STE 230
-    Sunnyvale, CA 94086
-
-    Phone: +1 408 524 4804
-    EMail: gilligan@freegate.net
-
-
-    Susan Thomson
-    Bell Communications Research
-    MRE 2P-343, 445 South Street
-    Morristown, NJ 07960
-
-    Phone: +1 201 829 4514
-    EMail: set@thumper.bellcore.com
-
-
-    Jim Bound
-    Digital Equipment Corporation
-    110 Spitbrook Road ZK3-3/U14
-    Nashua, NH 03062-2698
-
-    Phone: +1 603 881 0400
-    Email: bound@zk3.dec.com
-
-
-    W. Richard Stevens
-    1202 E. Paseo del Zorro
-    Tucson, AZ 85718-2826
-
-    Phone: +1 520 297 9416
-    EMail: rstevens@kohala.com
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 32]
-
diff --git a/contrib/bind9/doc/rfc/rfc2136.txt b/contrib/bind9/doc/rfc/rfc2136.txt
deleted file mode 100644
index 4d62702..0000000
--- a/contrib/bind9/doc/rfc/rfc2136.txt
+++ /dev/null
@@ -1,1460 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                  P. Vixie, Editor
-Request for Comments: 2136                                          ISC
-Updates: 1035                                                S. Thomson
-Category: Standards Track                                      Bellcore
-                                                             Y. Rekhter
-                                                                  Cisco
-                                                               J. Bound
-                                                                    DEC
-                                                             April 1997
-
-         Dynamic Updates in the Domain Name System (DNS UPDATE)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Abstract
-
-   The Domain Name System was originally designed to support queries of
-   a statically configured database.  While the data was expected to
-   change, the frequency of those changes was expected to be fairly low,
-   and all updates were made as external edits to a zone's Master File.
-
-   Using this specification of the UPDATE opcode, it is possible to add
-   or delete RRs or RRsets from a specified zone.  Prerequisites are
-   specified separately from update operations, and can specify a
-   dependency upon either the previous existence or nonexistence of an
-   RRset, or the existence of a single RR.
-
-   UPDATE is atomic, i.e., all prerequisites must be satisfied or else
-   no update operations will take place.  There are no data dependent
-   error conditions defined after the prerequisites have been met.
-
-1 - Definitions
-
-   This document intentionally gives more definition to the roles of
-   "Master," "Slave," and "Primary Master" servers, and their
-   enumeration in NS RRs, and the SOA MNAME field.  In that sense, the
-   following server type definitions can be considered an addendum to
-   [RFC1035], and are intended to be consistent with [RFC1996]:
-
-      Slave           an authoritative server that uses AXFR or IXFR to
-                      retrieve the zone and is named in the zone's NS
-                      RRset.
-
-
-
-Vixie, et. al.              Standards Track                     [Page 1]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-      Master          an authoritative server configured to be the
-                      source of AXFR or IXFR data for one or more slave
-                      servers.
-
-      Primary Master  master server at the root of the AXFR/IXFR
-                      dependency graph.  The primary master is named in
-                      the zone's SOA MNAME field and optionally by an NS
-                      RR.  There is by definition only one primary master
-                      server per zone.
-
-   A domain name identifies a node within the domain name space tree
-   structure.  Each node has a set (possibly empty) of Resource Records
-   (RRs).  All RRs having the same NAME, CLASS and TYPE are called a
-   Resource Record Set (RRset).
-
-   The pseudocode used in this document is for example purposes only.
-   If it is found to disagree with the text, the text shall be
-   considered authoritative.  If the text is found to be ambiguous, the
-   pseudocode can be used to help resolve the ambiguity.
-
-   1.1 - Comparison Rules
-
-   1.1.1. Two RRs are considered equal if their NAME, CLASS, TYPE,
-   RDLENGTH and RDATA fields are equal.  Note that the time-to-live
-   (TTL) field is explicitly excluded from the comparison.
-
-   1.1.2. The rules for comparison of character strings in names are
-   specified in [RFC1035 2.3.3].
-
-   1.1.3. Wildcarding is disabled.  That is, a wildcard ("*") in an
-   update only matches a wildcard ("*") in the zone, and vice versa.
-
-   1.1.4. Aliasing is disabled: A CNAME in the zone matches a CNAME in
-   the update, and will not otherwise be followed.  All UPDATE
-   operations are done on the basis of canonical names.
-
-   1.1.5. The following RR types cannot be appended to an RRset.  If the
-   following comparison rules are met, then an attempt to add the new RR
-   will result in the replacement of the previous RR:
-
-      SOA    compare only NAME, CLASS and TYPE -- it is not possible to
-             have more than one SOA per zone, even if any of the data
-             fields differ.
-
-      WKS    compare only NAME, CLASS, TYPE, ADDRESS, and PROTOCOL
-             -- only one WKS RR is possible for this tuple, even if the
-             services masks differ.
-
-
-
-
-Vixie, et. al.              Standards Track                     [Page 2]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-      CNAME  compare only NAME, CLASS, and TYPE -- it is not possible
-             to have more than one CNAME RR, even if their data fields
-             differ.
-
-   1.2 - Glue RRs
-
-   For the purpose of determining whether a domain name used in the
-   UPDATE protocol is contained within a specified zone, a domain name
-   is "in" a zone if it is owned by that zone's domain name.  See
-   section 7.18 for details.
-
-   1.3 - New Assigned Numbers
-
-      CLASS = NONE (254)
-      RCODE = YXDOMAIN (6)
-      RCODE = YXRRSET (7)
-      RCODE = NXRRSET (8)
-      RCODE = NOTAUTH (9)
-      RCODE = NOTZONE (10)
-      Opcode = UPDATE (5)
-
-2 - Update Message Format
-
-   The DNS Message Format is defined by [RFC1035 4.1].  Some extensions
-   are necessary (for example, more error codes are possible under
-   UPDATE than under QUERY) and some fields must be overloaded (see
-   description of CLASS fields below).
-
-   The overall format of an UPDATE message is, following [ibid]:
-
-      +---------------------+
-      |        Header       |
-      +---------------------+
-      |         Zone        | specifies the zone to be updated
-      +---------------------+
-      |     Prerequisite    | RRs or RRsets which must (not) preexist
-      +---------------------+
-      |        Update       | RRs or RRsets to be added or deleted
-      +---------------------+
-      |   Additional Data   | additional data
-      +---------------------+
-
-
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                     [Page 3]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   The Header Section specifies that this message is an UPDATE, and
-   describes the size of the other sections.  The Zone Section names the
-   zone that is to be updated by this message.  The Prerequisite Section
-   specifies the starting invariants (in terms of zone content) required
-   for this update.  The Update Section contains the edits to be made,
-   and the Additional Data Section contains data which may be necessary
-   to complete, but is not part of, this update.
-
-   2.1 - Transport Issues
-
-   An update transaction may be carried in a UDP datagram, if the
-   request fits, or in a TCP connection (at the discretion of the
-   requestor).  When TCP is used, the message is in the format described
-   in [RFC1035 4.2.2].
-
-   2.2 - Message Header
-
-   The header of the DNS Message Format is defined by [RFC 1035 4.1].
-   Not all opcodes define the same set of flag bits, though as a
-   practical matter most of the bits defined for QUERY (in [ibid]) are
-   identically defined by the other opcodes.  UPDATE uses only one flag
-   bit (QR).
-
-   The DNS Message Format specifies record counts for its four sections
-   (Question, Answer, Authority, and Additional).  UPDATE uses the same
-   fields, and the same section formats, but the naming and use of these
-   sections differs as shown in the following modified header, after
-   [RFC1035 4.1.1]:
-
-                                      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         |   RCODE   |
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      |                    ZOCOUNT                    |
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      |                    PRCOUNT                    |
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      |                    UPCOUNT                    |
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      |                    ADCOUNT                    |
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                     [Page 4]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   These fields are used as follows:
-
-   ID      A 16-bit identifier assigned by the entity that generates any
-           kind of request.  This identifier is copied in the
-           corresponding reply and can be used by the requestor to match
-           replies to outstanding requests, or by the server to detect
-           duplicated requests from some requestor.
-
-   QR      A one bit field that specifies whether this message is a
-           request (0), or a response (1).
-
-   Opcode  A four bit field that specifies the kind of request in this
-           message.  This value is set by the originator of a request
-           and copied into the response.  The Opcode value that
-           identifies an UPDATE message is five (5).
-
-   Z       Reserved for future use.  Should be zero (0) in all requests
-           and responses.  A non-zero Z field should be ignored by
-           implementations of this specification.
-
-   RCODE   Response code - this four bit field is undefined in requests
-           and set in responses.  The values and meanings of this field
-           within responses are as follows:
-
-              Mneumonic   Value   Description
-              ------------------------------------------------------------
-              NOERROR     0       No error condition.
-              FORMERR     1       The name server was unable to interpret
-                                  the request due to a format error.
-              SERVFAIL    2       The name server encountered an internal
-                                  failure while processing this request,
-                                  for example an operating system error
-                                  or a forwarding timeout.
-              NXDOMAIN    3       Some name that ought to exist,
-                                  does not exist.
-              NOTIMP      4       The name server does not support
-                                  the specified Opcode.
-              REFUSED     5       The name server refuses to perform the
-                                  specified operation for policy or
-                                  security reasons.
-              YXDOMAIN    6       Some name that ought not to exist,
-                                  does exist.
-              YXRRSET     7       Some RRset that ought not to exist,
-                                  does exist.
-              NXRRSET     8       Some RRset that ought to exist,
-                                  does not exist.
-
-
-
-
-
-Vixie, et. al.              Standards Track                     [Page 5]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-              NOTAUTH     9       The server is not authoritative for
-                                  the zone named in the Zone Section.
-              NOTZONE     10      A name used in the Prerequisite or
-                                  Update Section is not within the
-                                  zone denoted by the Zone Section.
-
-   ZOCOUNT The number of RRs in the Zone Section.
-
-   PRCOUNT The number of RRs in the Prerequisite Section.
-
-   UPCOUNT The number of RRs in the Update Section.
-
-   ADCOUNT The number of RRs in the Additional Data Section.
-
-   2.3 - Zone Section
-
-   The Zone Section has the same format as that specified in [RFC1035
-   4.1.2], with the fields redefined as follows:
-
-                                      1  1  1  1  1  1
-        0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      |                                               |
-      /                     ZNAME                     /
-      /                                               /
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      |                     ZTYPE                     |
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      |                     ZCLASS                    |
-      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   UPDATE uses this section to denote the zone of the records being
-   updated.  All records to be updated must be in the same zone, and
-   therefore the Zone Section is allowed to contain exactly one record.
-   The ZNAME is the zone name, the ZTYPE must be SOA, and the ZCLASS is
-   the zone's class.
-
-   2.4 - Prerequisite Section
-
-   This section contains a set of RRset prerequisites which must be
-   satisfied at the time the UPDATE packet is received by the primary
-   master server.  The format of this section is as specified by
-   [RFC1035 4.1.3].  There are five possible sets of semantics that can
-   be expressed here, summarized as follows and then explained below.
-
-      (1)  RRset exists (value independent).  At least one RR with a
-           specified NAME and TYPE (in the zone and class specified by
-           the Zone Section) must exist.
-
-
-
-Vixie, et. al.              Standards Track                     [Page 6]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-      (2)  RRset exists (value dependent).  A set of RRs with a
-           specified NAME and TYPE exists and has the same members
-           with the same RDATAs as the RRset specified here in this
-           Section.
-
-      (3)  RRset does not exist.  No RRs with a specified NAME and TYPE
-          (in the zone and class denoted by the Zone Section) can exist.
-
-      (4)  Name is in use.  At least one RR with a specified NAME (in
-           the zone and class specified by the Zone Section) must exist.
-           Note that this prerequisite is NOT satisfied by empty
-           nonterminals.
-
-      (5)  Name is not in use.  No RR of any type is owned by a
-           specified NAME.  Note that this prerequisite IS satisfied by
-           empty nonterminals.
-
-   The syntax of these is as follows:
-
-   2.4.1 - RRset Exists (Value Independent)
-
-   At least one RR with a specified NAME and TYPE (in the zone and class
-   specified in the Zone Section) must exist.
-
-   For this prerequisite, a requestor adds to the section a single RR
-   whose NAME and TYPE are equal to that of the zone RRset whose
-   existence is required.  RDLENGTH is zero and RDATA is therefore
-   empty.  CLASS must be specified as ANY to differentiate this
-   condition from that of an actual RR whose RDLENGTH is naturally zero
-   (0) (e.g., NULL).  TTL is specified as zero (0).
-
-   2.4.2 - RRset Exists (Value Dependent)
-
-   A set of RRs with a specified NAME and TYPE exists and has the same
-   members with the same RDATAs as the RRset specified here in this
-   section.  While RRset ordering is undefined and therefore not
-   significant to this comparison, the sets be identical in their
-   extent.
-
-   For this prerequisite, a requestor adds to the section an entire
-   RRset whose preexistence is required.  NAME and TYPE are that of the
-   RRset being denoted.  CLASS is that of the zone.  TTL must be
-   specified as zero (0) and is ignored when comparing RRsets for
-   identity.
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                     [Page 7]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   2.4.3 - RRset Does Not Exist
-
-   No RRs with a specified NAME and TYPE (in the zone and class denoted
-   by the Zone Section) can exist.
-
-   For this prerequisite, a requestor adds to the section a single RR
-   whose NAME and TYPE are equal to that of the RRset whose nonexistence
-   is required.  The RDLENGTH of this record is zero (0), and RDATA
-   field is therefore empty.  CLASS must be specified as NONE in order
-   to distinguish this condition from a valid RR whose RDLENGTH is
-   naturally zero (0) (for example, the NULL RR).  TTL must be specified
-   as zero (0).
-
-   2.4.4 - Name Is In Use
-
-   Name is in use.  At least one RR with a specified NAME (in the zone
-   and class specified by the Zone Section) must exist.  Note that this
-   prerequisite is NOT satisfied by empty nonterminals.
-
-   For this prerequisite, a requestor adds to the section a single RR
-   whose NAME is equal to that of the name whose ownership of an RR is
-   required.  RDLENGTH is zero and RDATA is therefore empty.  CLASS must
-   be specified as ANY to differentiate this condition from that of an
-   actual RR whose RDLENGTH is naturally zero (0) (e.g., NULL).  TYPE
-   must be specified as ANY to differentiate this case from that of an
-   RRset existence test.  TTL is specified as zero (0).
-
-   2.4.5 - Name Is Not In Use
-
-   Name is not in use.  No RR of any type is owned by a specified NAME.
-   Note that this prerequisite IS satisfied by empty nonterminals.
-
-   For this prerequisite, a requestor adds to the section a single RR
-   whose NAME is equal to that of the name whose nonownership of any RRs
-   is required.  RDLENGTH is zero and RDATA is therefore empty.  CLASS
-   must be specified as NONE.  TYPE must be specified as ANY.  TTL must
-   be specified as zero (0).
-
-   2.5 - Update Section
-
-   This section contains RRs to be added to or deleted from the zone.
-   The format of this section is as specified by [RFC1035 4.1.3].  There
-   are four possible sets of semantics, summarized below and with
-   details to follow.
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                     [Page 8]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-      (1) Add RRs to an RRset.
-      (2) Delete an RRset.
-      (3) Delete all RRsets from a name.
-      (4) Delete an RR from an RRset.
-
-   The syntax of these is as follows:
-
-   2.5.1 - Add To An RRset
-
-   RRs are added to the Update Section whose NAME, TYPE, TTL, RDLENGTH
-   and RDATA are those being added, and CLASS is the same as the zone
-   class.  Any duplicate RRs will be silently ignored by the primary
-   master.
-
-   2.5.2 - Delete An RRset
-
-   One RR is added to the Update Section whose NAME and TYPE are those
-   of the RRset to be deleted.  TTL must be specified as zero (0) and is
-   otherwise not used by the primary master.  CLASS must be specified as
-   ANY.  RDLENGTH must be zero (0) and RDATA must therefore be empty.
-   If no such RRset exists, then this Update RR will be silently ignored
-   by the primary master.
-
-   2.5.3 - Delete All RRsets From A Name
-
-   One RR is added to the Update Section whose NAME is that of the name
-   to be cleansed of RRsets.  TYPE must be specified as ANY.  TTL must
-   be specified as zero (0) and is otherwise not used by the primary
-   master.  CLASS must be specified as ANY.  RDLENGTH must be zero (0)
-   and RDATA must therefore be empty.  If no such RRsets exist, then
-   this Update RR will be silently ignored by the primary master.
-
-   2.5.4 - Delete An RR From An RRset
-
-   RRs to be deleted are added to the Update Section.  The NAME, TYPE,
-   RDLENGTH and RDATA must match the RR being deleted.  TTL must be
-   specified as zero (0) and will otherwise be ignored by the primary
-   master.  CLASS must be specified as NONE to distinguish this from an
-   RR addition.  If no such RRs exist, then this Update RR will be
-   silently ignored by the primary master.
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                     [Page 9]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   2.6 - Additional Data Section
-
-   This section contains RRs which are related to the update itself, or
-   to new RRs being added by the update.  For example, out of zone glue
-   (A RRs referred to by new NS RRs) should be presented here.  The
-   server can use or ignore out of zone glue, at the discretion of the
-   server implementor.  The format of this section is as specified by
-   [RFC1035 4.1.3].
-
-3 - Server Behavior
-
-   A server, upon receiving an UPDATE request, will signal NOTIMP to the
-   requestor if the UPDATE opcode is not recognized or if it is
-   recognized but has not been implemented.  Otherwise, processing
-   continues as follows.
-
-   3.1 - Process Zone Section
-
-   3.1.1. The Zone Section is checked to see that there is exactly one
-   RR therein and that the RR's ZTYPE is SOA, else signal FORMERR to the
-   requestor.  Next, the ZNAME and ZCLASS are checked to see if the zone
-   so named is one of this server's authority zones, else signal NOTAUTH
-   to the requestor.  If the server is a zone slave, the request will be
-   forwarded toward the primary master.
-
-   3.1.2 - Pseudocode For Zone Section Processing
-
-      if (zcount != 1 || ztype != SOA)
-           return (FORMERR)
-      if (zone_type(zname, zclass) == SLAVE)
-           return forward()
-      if (zone_type(zname, zclass) == MASTER)
-           return update()
-      return (NOTAUTH)
-
-   Sections 3.2 through 3.8 describe the primary master's behaviour,
-   whereas Section 6 describes a forwarder's behaviour.
-
-   3.2 - Process Prerequisite Section
-
-   Next, the Prerequisite Section is checked to see that all
-   prerequisites are satisfied by the current state of the zone.  Using
-   the definitions expressed in Section 1.2, if any RR's NAME is not
-   within the zone specified in the Zone Section, signal NOTZONE to the
-   requestor.
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 10]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   3.2.1. For RRs in this section whose CLASS is ANY, test to see that
-   TTL and RDLENGTH are both zero (0), else signal FORMERR to the
-   requestor.  If TYPE is ANY, test to see that there is at least one RR
-   in the zone whose NAME is the same as that of the Prerequisite RR,
-   else signal NXDOMAIN to the requestor.  If TYPE is not ANY, test to
-   see that there is at least one RR in the zone whose NAME and TYPE are
-   the same as that of the Prerequisite RR, else signal NXRRSET to the
-   requestor.
-
-   3.2.2. For RRs in this section whose CLASS is NONE, test to see that
-   the TTL and RDLENGTH are both zero (0), else signal FORMERR to the
-   requestor.  If the TYPE is ANY, test to see that there are no RRs in
-   the zone whose NAME is the same as that of the Prerequisite RR, else
-   signal YXDOMAIN to the requestor.  If the TYPE is not ANY, test to
-   see that there are no RRs in the zone whose NAME and TYPE are the
-   same as that of the Prerequisite RR, else signal YXRRSET to the
-   requestor.
-
-   3.2.3. For RRs in this section whose CLASS is the same as the ZCLASS,
-   test to see that the TTL is zero (0), else signal FORMERR to the
-   requestor.  Then, build an RRset for each unique <NAME,TYPE> and
-   compare each resulting RRset for set equality (same members, no more,
-   no less) with RRsets in the zone.  If any Prerequisite RRset is not
-   entirely and exactly matched by a zone RRset, signal NXRRSET to the
-   requestor.  If any RR in this section has a CLASS other than ZCLASS
-   or NONE or ANY, signal FORMERR to the requestor.
-
-   3.2.4 - Table Of Metavalues Used In Prerequisite Section
-
-   CLASS    TYPE     RDATA    Meaning
-   ------------------------------------------------------------
-   ANY      ANY      empty    Name is in use
-   ANY      rrset    empty    RRset exists (value independent)
-   NONE     ANY      empty    Name is not in use
-   NONE     rrset    empty    RRset does not exist
-   zone     rrset    rr       RRset exists (value dependent)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 11]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   3.2.5 - Pseudocode for Prerequisite Section Processing
-
-      for rr in prerequisites
-           if (rr.ttl != 0)
-                return (FORMERR)
-           if (zone_of(rr.name) != ZNAME)
-                return (NOTZONE);
-           if (rr.class == ANY)
-                if (rr.rdlength != 0)
-                     return (FORMERR)
-                if (rr.type == ANY)
-                     if (!zone_name<rr.name>)
-                          return (NXDOMAIN)
-                else
-                     if (!zone_rrset<rr.name, rr.type>)
-                          return (NXRRSET)
-           if (rr.class == NONE)
-                if (rr.rdlength != 0)
-                     return (FORMERR)
-                if (rr.type == ANY)
-                     if (zone_name<rr.name>)
-                          return (YXDOMAIN)
-                else
-                     if (zone_rrset<rr.name, rr.type>)
-                          return (YXRRSET)
-           if (rr.class == zclass)
-                temp<rr.name, rr.type> += rr
-           else
-                return (FORMERR)
-
-      for rrset in temp
-           if (zone_rrset<rrset.name, rrset.type> != rrset)
-                return (NXRRSET)
-
-   3.3 - Check Requestor's Permissions
-
-   3.3.1. Next, the requestor's permission to update the RRs named in
-   the Update Section may be tested in an implementation dependent
-   fashion or using mechanisms specified in a subsequent Secure DNS
-   Update protocol.  If the requestor does not have permission to
-   perform these updates, the server may write a warning message in its
-   operations log, and may either signal REFUSED to the requestor, or
-   ignore the permission problem and proceed with the update.
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 12]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   3.3.2. While the exact processing is implementation defined, if these
-   verification activities are to be performed, this is the point in the
-   server's processing where such performance should take place, since
-   if a REFUSED condition is encountered after an update has been
-   partially applied, it will be necessary to undo the partial update
-   and restore the zone to its original state before answering the
-   requestor.
-
-   3.3.3 - Pseudocode for Permission Checking
-
-      if (security policy exists)
-           if (this update is not permitted)
-                if (local option)
-                     log a message about permission problem
-                if (local option)
-                     return (REFUSED)
-
-   3.4 - Process Update Section
-
-   Next, the Update Section is processed as follows.
-
-   3.4.1 - Prescan
-
-   The Update Section is parsed into RRs and each RR's CLASS is checked
-   to see if it is ANY, NONE, or the same as the Zone Class, else signal
-   a FORMERR to the requestor.  Using the definitions in Section 1.2,
-   each RR's NAME must be in the zone specified by the Zone Section,
-   else signal NOTZONE to the requestor.
-
-   3.4.1.2. For RRs whose CLASS is not ANY, check the TYPE and if it is
-   ANY, AXFR, MAILA, MAILB, or any other QUERY metatype, or any
-   unrecognized type, then signal FORMERR to the requestor.  For RRs
-   whose CLASS is ANY or NONE, check the TTL to see that it is zero (0),
-   else signal a FORMERR to the requestor.  For any RR whose CLASS is
-   ANY, check the RDLENGTH to make sure that it is zero (0) (that is,
-   the RDATA field is empty), and that the TYPE is not AXFR, MAILA,
-   MAILB, or any other QUERY metatype besides ANY, or any unrecognized
-   type, else signal FORMERR to the requestor.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 13]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   3.4.1.3 - Pseudocode For Update Section Prescan
-
-      [rr] for rr in updates
-           if (zone_of(rr.name) != ZNAME)
-                return (NOTZONE);
-           if (rr.class == zclass)
-                if (rr.type & ANY|AXFR|MAILA|MAILB)
-                     return (FORMERR)
-           elsif (rr.class == ANY)
-                if (rr.ttl != 0 || rr.rdlength != 0
-                    || rr.type & AXFR|MAILA|MAILB)
-                     return (FORMERR)
-           elsif (rr.class == NONE)
-                if (rr.ttl != 0 || rr.type & ANY|AXFR|MAILA|MAILB)
-                     return (FORMERR)
-           else
-                return (FORMERR)
-
-   3.4.2 - Update
-
-   The Update Section is parsed into RRs and these RRs are processed in
-   order.
-
-   3.4.2.1. If any system failure (such as an out of memory condition,
-   or a hardware error in persistent storage) occurs during the
-   processing of this section, signal SERVFAIL to the requestor and undo
-   all updates applied to the zone during this transaction.
-
-   3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to
-   the zone.  In case of duplicate RDATAs (which for SOA RRs is always
-   the case, and for WKS RRs is the case if the ADDRESS and PROTOCOL
-   fields both match), the Zone RR is replaced by Update RR.  If the
-   TYPE is SOA and there is no Zone SOA RR, or the new SOA.SERIAL is
-   lower (according to [RFC1982]) than or equal to the current Zone SOA
-   RR's SOA.SERIAL, the Update RR is ignored.  In the case of a CNAME
-   Update RR and a non-CNAME Zone RRset or vice versa, ignore the CNAME
-   Update RR, otherwise replace the CNAME Zone RR with the CNAME Update
-   RR.
-
-   3.4.2.3. For any Update RR whose CLASS is ANY and whose TYPE is ANY,
-   all Zone RRs with the same NAME are deleted, unless the NAME is the
-   same as ZNAME in which case only those RRs whose TYPE is other than
-   SOA or NS are deleted.  For any Update RR whose CLASS is ANY and
-   whose TYPE is not ANY all Zone RRs with the same NAME and TYPE are
-   deleted, unless the NAME is the same as ZNAME in which case neither
-   SOA or NS RRs will be deleted.
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 14]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   3.4.2.4. For any Update RR whose class is NONE, any Zone RR whose
-   NAME, TYPE, RDATA and RDLENGTH are equal to the Update RR is deleted,
-   unless the NAME is the same as ZNAME and either the TYPE is SOA or
-   the TYPE is NS and the matching Zone RR is the only NS remaining in
-   the RRset, in which case this Update RR is ignored.
-
-   3.4.2.5. Signal NOERROR to the requestor.
-
-   3.4.2.6 - Table Of Metavalues Used In Update Section
-
-   CLASS    TYPE     RDATA    Meaning
-   ---------------------------------------------------------
-   ANY      ANY      empty    Delete all RRsets from a name
-   ANY      rrset    empty    Delete an RRset
-   NONE     rrset    rr       Delete an RR from an RRset
-   zone     rrset    rr       Add to an RRset
-
-   3.4.2.7 - Pseudocode For Update Section Processing
-
-      [rr] for rr in updates
-           if (rr.class == zclass)
-                if (rr.type == CNAME)
-                     if (zone_rrset<rr.name, ~CNAME>)
-                          next [rr]
-                elsif (zone_rrset<rr.name, CNAME>)
-                     next [rr]
-                if (rr.type == SOA)
-                     if (!zone_rrset<rr.name, SOA> ||
-                         zone_rr<rr.name, SOA>.serial > rr.soa.serial)
-                          next [rr]
-                for zrr in zone_rrset<rr.name, rr.type>
-                     if (rr.type == CNAME || rr.type == SOA ||
-                         (rr.type == WKS && rr.proto == zrr.proto &&
-                          rr.address == zrr.address) ||
-                         rr.rdata == zrr.rdata)
-                          zrr = rr
-                          next [rr]
-                zone_rrset<rr.name, rr.type> += rr
-           elsif (rr.class == ANY)
-                if (rr.type == ANY)
-                     if (rr.name == zname)
-                          zone_rrset<rr.name, ~(SOA|NS)> = Nil
-                     else
-                          zone_rrset<rr.name, *> = Nil
-                elsif (rr.name == zname &&
-                       (rr.type == SOA || rr.type == NS))
-                     next [rr]
-                else
-
-
-
-Vixie, et. al.              Standards Track                    [Page 15]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-                     zone_rrset<rr.name, rr.type> = Nil
-           elsif (rr.class == NONE)
-                if (rr.type == SOA)
-                     next [rr]
-                if (rr.type == NS && zone_rrset<rr.name, NS> == rr)
-                     next [rr]
-                zone_rr<rr.name, rr.type, rr.data> = Nil
-      return (NOERROR)
-
-   3.5 - Stability
-
-   When a zone is modified by an UPDATE operation, the server must
-   commit the change to nonvolatile storage before sending a response to
-   the requestor or answering any queries or transfers for the modified
-   zone.  It is reasonable for a server to store only the update records
-   as long as a system reboot or power failure will cause these update
-   records to be incorporated into the zone the next time the server is
-   started.  It is also reasonable for the server to copy the entire
-   modified zone to nonvolatile storage after each update operation,
-   though this would have suboptimal performance for large zones.
-
-   3.6 - Zone Identity
-
-   If the zone's SOA SERIAL is changed by an update operation, that
-   change must be in a positive direction (using modulo 2**32 arithmetic
-   as specified by [RFC1982]).  Attempts to replace an SOA with one
-   whose SERIAL is less than the current one will be silently ignored by
-   the primary master server.
-
-   If the zone's SOA's SERIAL is not changed as a result of an update
-   operation, then the server shall increment it automatically before
-   the SOA or any changed name or RR or RRset is included in any
-   response or transfer.  The primary master server's implementor might
-   choose to autoincrement the SOA SERIAL if any of the following events
-   occurs:
-
-   (1)  Each update operation.
-
-   (2)  A name, RR or RRset in the zone has changed and has subsequently
-        been visible to a DNS client since the unincremented SOA was
-        visible to a DNS client, and the SOA is about to become visible
-        to a DNS client.
-
-   (3)  A configurable period of time has elapsed since the last update
-        operation.  This period shall be less than or equal to one third
-        of the zone refresh time, and the default shall be the lesser of
-        that maximum and 300 seconds.
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 16]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   (4)  A configurable number of updates has been applied since the last
-        SOA change.  The default value for this configuration parameter
-        shall be one hundred (100).
-
-   It is imperative that the zone's contents and the SOA's SERIAL be
-   tightly synchronized.  If the zone appears to change, the SOA must
-   appear to change as well.
-
-   3.7 - Atomicity
-
-   During the processing of an UPDATE transaction, the server must
-   ensure atomicity with respect to other (concurrent) UPDATE or QUERY
-   transactions.  No two transactions can be processed concurrently if
-   either depends on the final results of the other; in particular, a
-   QUERY should not be able to retrieve RRsets which have been partially
-   modified by a concurrent UPDATE, and an UPDATE should not be able to
-   start from prerequisites that might not still hold at the completion
-   of some other concurrent UPDATE.  Finally, if two UPDATE transactions
-   would modify the same names, RRs or RRsets, then such UPDATE
-   transactions must be serialized.
-
-   3.8 - Response
-
-   At the end of UPDATE processing, a response code will be known.  A
-   response message is generated by copying the ID and Opcode fields
-   from the request, and either copying the ZOCOUNT, PRCOUNT, UPCOUNT,
-   and ADCOUNT fields and associated sections, or placing zeros (0) in
-   the these "count" fields and not including any part of the original
-   update.  The QR bit is set to one (1), and the response is sent back
-   to the requestor.  If the requestor used UDP, then the response will
-   be sent to the requestor's source UDP port.  If the requestor used
-   TCP, then the response will be sent back on the requestor's open TCP
-   connection.
-
-4 - Requestor Behaviour
-
-   4.1. From a requestor's point of view, any authoritative server for
-   the zone can appear to be able to process update requests, even
-   though only the primary master server is actually able to modify the
-   zone's master file.  Requestors are expected to know the name of the
-   zone they intend to update and to know or be able to determine the
-   name servers for that zone.
-
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 17]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   4.2. If update ordering is desired, the requestor will need to know
-   the value of the existing SOA RR.  Requestors who update the SOA RR
-   must update the SOA SERIAL field in a positive direction (as defined
-   by [RFC1982]) and also preserve the other SOA fields unless the
-   requestor's explicit intent is to change them.  The SOA SERIAL field
-   must never be set to zero (0).
-
-   4.3. If the requestor has reasonable cause to believe that all of a
-   zone's servers will be equally reachable, then it should arrange to
-   try the primary master server (as given by the SOA MNAME field if
-   matched by some NS NSDNAME) first to avoid unnecessary forwarding
-   inside the slave servers.  (Note that the primary master will in some
-   cases not be reachable by all requestors, due to firewalls or network
-   partitioning.)
-
-   4.4. Once the zone's name servers been found and possibly sorted so
-   that the ones more likely to be reachable and/or support the UPDATE
-   opcode are listed first, the requestor composes an UPDATE message of
-   the following form and sends it to the first name server on its list:
-
-      ID:                        (new)
-      Opcode:                    UPDATE
-      Zone zcount:               1
-      Zone zname:                (zone name)
-      Zone zclass:               (zone class)
-      Zone ztype:                T_SOA
-      Prerequisite Section:      (see previous text)
-      Update Section:            (see previous text)
-      Additional Data Section:   (empty)
-
-   4.5. If the requestor receives a response, and the response has an
-   RCODE other than SERVFAIL or NOTIMP, then the requestor returns an
-   appropriate response to its caller.
-
-   4.6. If a response is received whose RCODE is SERVFAIL or NOTIMP, or
-   if no response is received within an implementation dependent timeout
-   period, or if an ICMP error is received indicating that the server's
-   port is unreachable, then the requestor will delete the unusable
-   server from its internal name server list and try the next one,
-   repeating until the name server list is empty.  If the requestor runs
-   out of servers to try, an appropriate error will be returned to the
-   requestor's caller.
-
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 18]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-5 - Duplicate Detection, Ordering and Mutual Exclusion
-
-   5.1. For correct operation, mechanisms may be needed to ensure
-   idempotence, order UPDATE requests and provide mutual exclusion.  An
-   UPDATE message or response might be delivered zero times, one time,
-   or multiple times.  Datagram duplication is of particular interest
-   since it covers the case of the so-called "replay attack" where a
-   correct request is duplicated maliciously by an intruder.
-
-   5.2. Multiple UPDATE requests or responses in transit might be
-   delivered in any order, due to network topology changes or load
-   balancing, or to multipath forwarding graphs wherein several slave
-   servers all forward to the primary master.  In some cases, it might
-   be required that the earlier update not be applied after the later
-   update, where "earlier" and "later" are defined by an external time
-   base visible to some set of requestors, rather than by the order of
-   request receipt at the primary master.
-
-   5.3. A requestor can ensure transaction idempotence by explicitly
-   deleting some "marker RR" (rather than deleting the RRset of which it
-   is a part) and then adding a new "marker RR" with a different RDATA
-   field.  The Prerequisite Section should specify that the original
-   "marker RR" must be present in order for this UPDATE message to be
-   accepted by the server.
-
-   5.4. If the request is duplicated by a network error, all duplicate
-   requests will fail since only the first will find the original
-   "marker RR" present and having its known previous value.  The
-   decisions of whether to use such a "marker RR" and what RR to use are
-   left up to the application programmer, though one obvious choice is
-   the zone's SOA RR as described below.
-
-   5.5. Requestors can ensure update ordering by externally
-   synchronizing their use of successive values of the "marker RR."
-   Mutual exclusion can be addressed as a degenerate case, in that a
-   single succession of the "marker RR" is all that is needed.
-
-   5.6. A special case where update ordering and datagram duplication
-   intersect is when an RR validly changes to some new value and then
-   back to its previous value.  Without a "marker RR" as described
-   above, this sequence of updates can leave the zone in an undefined
-   state if datagrams are duplicated.
-
-   5.7. To achieve an atomic multitransaction "read-modify-write" cycle,
-   a requestor could first retrieve the SOA RR, and build an UPDATE
-   message one of whose prerequisites was the old SOA RR.  It would then
-   specify updates that would delete this SOA RR and add a new one with
-   an incremented SOA SERIAL, along with whatever actual prerequisites
-
-
-
-Vixie, et. al.              Standards Track                    [Page 19]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   and updates were the object of the transaction.  If the transaction
-   succeeds, the requestor knows that the RRs being changed were not
-   otherwise altered by any other requestor.
-
-6 - Forwarding
-
-   When a zone slave forwards an UPDATE message upward toward the zone's
-   primary master server, it must allocate a new ID and prepare to enter
-   the role of "forwarding server," which is a requestor with respect to
-   the forward server.
-
-   6.1. The set of forward servers will be same as the set of servers
-   this zone slave would use as the source of AXFR or IXFR data.  So,
-   while the original requestor might have used the zone's NS RRset to
-   locate its update server, a forwarder always forwards toward its
-   designated zone master servers.
-
-   6.2. If the original requestor used TCP, then the TCP connection from
-   the requestor is still open and the forwarder must use TCP to forward
-   the message.  If the original requestor used UDP, the forwarder may
-   use either UDP or TCP to forward the message, at the whim of the
-   implementor.
-
-   6.3. It is reasonable for forward servers to be forwarders
-   themselves, if the AXFR dependency graph being followed is a deep one
-   involving firewalls and multiple connectivity realms.  In most cases
-   the AXFR dependency graph will be shallow and the forward server will
-   be the primary master server.
-
-   6.4. The forwarder will not respond to its requestor until it
-   receives a response from its forward server.  UPDATE transactions
-   involving forwarders are therefore time synchronized with respect to
-   the original requestor and the primary master server.
-
-   6.5. When there are multiple possible sources of AXFR data and
-   therefore multiple possible forward servers, a forwarder will use the
-   same fallback strategy with respect to connectivity or timeout errors
-   that it would use when performing an AXFR.  This is implementation
-   dependent.
-
-   6.6. When a forwarder receives a response from a forward server, it
-   copies this response into a new response message, assigns its
-   requestor's ID to that message, and sends the response back to the
-   requestor.
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 20]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-7 - Design, Implementation, Operation, and Protocol Notes
-
-   Some of the principles which guided the design of this UPDATE
-   specification are as follows.  Note that these are not part of the
-   formal specification and any disagreement between this section and
-   any other section of this document should be resolved in favour of
-   the other section.
-
-   7.1. Using metavalues for CLASS is possible only because all RRs in
-   the packet are assumed to be in the same zone, and CLASS is an
-   attribute of a zone rather than of an RRset.  (It is for this reason
-   that the Zone Section is not optional.)
-
-   7.2. Since there are no data-present or data-absent errors possible
-   from processing the Update Section, any necessary data-present and
-   data- absent dependencies should be specified in the Prerequisite
-   Section.
-
-   7.3. The Additional Data Section can be used to supply a server with
-   out of zone glue that will be needed in referrals.  For example, if
-   adding a new NS RR to HOME.VIX.COM specifying a nameserver called
-   NS.AU.OZ, the A RR for NS.AU.OZ can be included in the Additional
-   Data Section.  Servers can use this information or ignore it, at the
-   discretion of the implementor.  We discourage caching this
-   information for use in subsequent DNS responses.
-
-   7.4. The Additional Data Section might be used if some of the RRs
-   later needed for Secure DNS Update are not actually zone updates, but
-   rather ancillary keys or signatures not intended to be stored in the
-   zone (as an update would be), yet necessary for validating the update
-   operation.
-
-   7.5. It is expected that in the absence of Secure DNS Update, a
-   server will only accept updates if they come from a source address
-   that has been statically configured in the server's description of a
-   primary master zone.  DHCP servers would be likely candidates for
-   inclusion in this statically configured list.
-
-   7.6. It is not possible to create a zone using this protocol, since
-   there is no provision for a slave server to be told who its master
-   servers are.  It is expected that this protocol will be extended in
-   the future to cover this case.  Therefore, at this time, the addition
-   of SOA RRs is unsupported.  For similar reasons, deletion of SOA RRs
-   is also unsupported.
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 21]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   7.7. The prerequisite for specifying that a name own at least one RR
-   differs semantically from QUERY, in that QUERY would return
-   <NOERROR,ANCOUNT=0> rather than NXDOMAIN if queried for an RRset at
-   this name, while UPDATE's prerequisite condition [Section 2.4.4]
-   would NOT be satisfied.
-
-   7.8. It is possible for a UDP response to be lost in transit and for
-   a request to be retried due to a timeout condition.  In this case an
-   UPDATE that was successful the first time it was received by the
-   primary master might ultimately appear to have failed when the
-   response to a duplicate request is finally received by the requestor.
-   (This is because the original prerequisites may no longer be
-   satisfied after the update has been applied.)  For this reason,
-   requestors who require an accurate response code must use TCP.
-
-   7.9. Because a requestor who requires an accurate response code will
-   initiate their UPDATE transaction using TCP, a forwarder who receives
-   a request via TCP must forward it using TCP.
-
-   7.10. Deferral of SOA SERIAL autoincrements is made possible so that
-   serial numbers can be conserved and wraparound at 2**32 can be made
-   an infrequent occurance.  Visible (to DNS clients) SOA SERIALs need
-   to differ if the zone differs.  Note that the Authority Section SOA
-   in a QUERY response is a form of visibility, for the purposes of this
-   prerequisite.
-
-   7.11. A zone's SOA SERIAL should never be set to zero (0) due to
-   interoperability problems with some older but widely installed
-   implementations of DNS.  When incrementing an SOA SERIAL, if the
-   result of the increment is zero (0) (as will be true when wrapping
-   around 2**32), it is necessary to increment it again or set it to one
-   (1).  See [RFC1982] for more detail on this subject.
-
-   7.12. Due to the TTL minimalization necessary when caching an RRset,
-   it is recommended that all TTLs in an RRset be set to the same value.
-   While the DNS Message Format permits variant TTLs to exist in the
-   same RRset, and this variance can exist inside a zone, such variance
-   will have counterintuitive results and its use is discouraged.
-
-   7.13. Zone cut management presents some obscure corner cases to the
-   add and delete operations in the Update Section.  It is possible to
-   delete an NS RR as long as it is not the last NS RR at the root of a
-   zone.  If deleting all RRs from a name, SOA and NS RRs at the root of
-   a zone are unaffected.  If deleting RRsets, it is not possible to
-   delete either SOA or NS RRsets at the top of a zone.  An attempt to
-   add an SOA will be treated as a replace operation if an SOA already
-   exists, or as a no-op if the SOA would be new.
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 22]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   7.14. No semantic checking is required in the primary master server
-   when adding new RRs.  Therefore a requestor can cause CNAME or NS or
-   any other kind of RR to be added even if their target name does not
-   exist or does not have the proper RRsets to make the original RR
-   useful.  Primary master servers that DO implement this kind of
-   checking should take great care to avoid out-of-zone dependencies
-   (whose veracity cannot be authoritatively checked) and should
-   implement all such checking during the prescan phase.
-
-   7.15. Nonterminal or wildcard CNAMEs are not well specified by
-   [RFC1035] and their use will probably lead to unpredictable results.
-   Their use is discouraged.
-
-   7.16. Empty nonterminals (nodes with children but no RRs of their
-   own) will cause <NOERROR,ANCOUNT=0> responses to be sent in response
-   to a query of any type for that name.  There is no provision for
-   empty terminal nodes -- so if all RRs of a terminal node are deleted,
-   the name is no longer in use, and queries of any type for that name
-   will result in an NXDOMAIN response.
-
-   7.17. In a deep AXFR dependency graph, it has not historically been
-   an error for slaves to depend mutually upon each other.  This
-   configuration has been used to enable a zone to flow from the primary
-   master to all slaves even though not all slaves have continuous
-   connectivity to the primary master.  UPDATE's use of the AXFR
-   dependency graph for forwarding prohibits this kind of dependency
-   loop, since UPDATE forwarding has no loop detection analagous to the
-   SOA SERIAL pretest used by AXFR.
-
-   7.18. Previously existing names which are occluded by a new zone cut
-   are still considered part of the parent zone, for the purposes of
-   zone transfers, even though queries for such names will be referred
-   to the new subzone's servers.  If a zone cut is removed, all parent
-   zone names that were occluded by it will again become visible to
-   queries.  (This is a clarification of [RFC1034].)
-
-   7.19. If a server is authoritative for both a zone and its child,
-   then queries for names at the zone cut between them will be answered
-   authoritatively using only data from the child zone.  (This is a
-   clarification of [RFC1034].)
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 23]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   7.20. Update ordering using the SOA RR is problematic since there is
-   no way to know which of a zone's NS RRs represents the primary
-   master, and the zone slaves can be out of date if their SOA.REFRESH
-   timers have not elapsed since the last time the zone was changed on
-   the primary master.  We recommend that a zone needing ordered updates
-   use only servers which implement NOTIFY (see [RFC1996]) and IXFR (see
-   [RFC1995]), and that a client receiving a prerequisite error while
-   attempting an ordered update simply retry after a random delay period
-   to allow the zone to settle.
-
-8 - Security Considerations
-
-   8.1. In the absence of [RFC2137] or equivilent technology, the
-   protocol described by this document makes it possible for anyone who
-   can reach an authoritative name server to alter the contents of any
-   zones on that server.  This is a serious increase in vulnerability
-   from the current technology.  Therefore it is very strongly
-   recommended that the protocols described in this document not be used
-   without [RFC2137] or other equivalently strong security measures,
-   e.g. IPsec.
-
-   8.2. A denial of service attack can be launched by flooding an update
-   forwarder with TCP sessions containing updates that the primary
-   master server will ultimately refuse due to permission problems.
-   This arises due to the requirement that an update forwarder receiving
-   a request via TCP use a synchronous TCP session for its forwarding
-   operation.  The connection management mechanisms of [RFC1035 4.2.2]
-   are sufficient to prevent large scale damage from such an attack, but
-   not to prevent some queries from going unanswered during the attack.
-
-Acknowledgements
-
-   We would like to thank the IETF DNSIND working group for their input
-   and assistance, in particular, Rob Austein, Randy Bush, Donald
-   Eastlake, Masataka Ohta, Mark Andrews, and Robert Elz.  Special
-   thanks to Bill Simpson, Ken Wallich and Bob Halley for reviewing this
-   document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 24]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-References
-
-   [RFC1035]
-      Mockapetris, P., "Domain Names - Implementation and
-      Specification", STD 13, RFC 1035, USC/Information Sciences
-      Institute, November 1987.
-
-   [RFC1982]
-      Elz, R., "Serial Number Arithmetic", RFC 1982, University of
-      Melbourne, August 1996.
-
-   [RFC1995]
-      Ohta, M., "Incremental Zone Transfer", RFC 1995, Tokyo Institute
-      of Technology, August 1996.
-
-   [RFC1996]
-      Vixie, P., "A Mechanism for Prompt Notification of Zone Changes",
-      RFC 1996, Internet Software Consortium, August 1996.
-
-   [RFC2065]
-      Eastlake, D., and C. Kaufman, "Domain Name System Protocol
-      Security Extensions", RFC 2065, January 1997.
-
-   [RFC2137]
-      Eastlake, D., "Secure Domain Name System Dynamic Update", RFC
-      2137, April 1997.
-
-Authors' Addresses
-
-   Yakov Rekhter
-   Cisco Systems
-   170 West Tasman Drive
-   San Jose, CA 95134-1706
-
-   Phone: +1 914 528 0090
-   EMail: yakov@cisco.com
-
-
-   Susan Thomson
-   Bellcore
-   445 South Street
-   Morristown, NJ 07960
-
-   Phone: +1 201 829 4514
-   EMail: set@thumper.bellcore.com
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 25]
-
-RFC 2136                       DNS Update                     April 1997
-
-
-   Jim Bound
-   Digital Equipment Corp.
-   110 Spitbrook Rd ZK3-3/U14
-   Nashua, NH 03062-2698
-
-   Phone: +1 603 881 0400
-   EMail: bound@zk3.dec.com
-
-
-   Paul Vixie
-   Internet Software Consortium
-   Star Route Box 159A
-   Woodside, CA 94062
-
-   Phone: +1 415 747 0204
-   EMail: paul@vix.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et. al.              Standards Track                    [Page 26]
-
-
diff --git a/contrib/bind9/doc/rfc/rfc2137.txt b/contrib/bind9/doc/rfc/rfc2137.txt
deleted file mode 100644
index ceb3613..0000000
--- a/contrib/bind9/doc/rfc/rfc2137.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                    D. Eastlake 3rd
-Request for Comments: 2137                               CyberCash, Inc.
-Updates: 1035                                                 April 1997
-Category: Standards Track
-
-
-                Secure Domain Name System Dynamic Update
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Abstract
-
-   Domain Name System (DNS) protocol extensions have been defined to
-   authenticate the data in DNS and provide key distribution services
-   [RFC2065].  DNS Dynamic Update operations have also been defined
-   [RFC2136], but without a detailed description of security for the
-   update operation.  This memo describes how to use DNSSEC digital
-   signatures covering requests and data to secure updates and restrict
-   updates to those authorized to perform them as indicated by the
-   updater's possession of cryptographic keys.
-
-Acknowledgements
-
-   The contributions of the following persons (who are listed in
-   alphabetic order) to this memo are gratefully acknowledged:
-
-         Olafur Gudmundsson (ogud@tis.com>
-         Charlie Kaufman <Charlie_Kaufman@iris.com>
-         Stuart Kwan <skwan@microsoft.com>
-         Edward Lewis <lewis@tis.com>
-
-Table of Contents
-
-      1. Introduction............................................2
-      1.1 Overview of DNS Dynamic Update.........................2
-      1.2 Overview of DNS Security...............................2
-      2. Two Basic Modes.........................................3
-      3. Keys....................................................5
-      3.1 Update Keys............................................6
-      3.1.1 Update Key Name Scope................................6
-      3.1.2 Update Key Class Scope...............................6
-      3.1.3 Update Key Signatory Field...........................6
-
-
-
-Eastlake                    Standards Track                     [Page 1]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-      3.2 Zone Keys and Update Modes.............................8
-      3.3 Wildcard Key Punch Through.............................9
-      4. Update Signatures.......................................9
-      4.1 Update Request Signatures..............................9
-      4.2 Update Data Signatures................................10
-      5. Security Considerations................................10
-      References................................................10
-      Author's Address..........................................11
-
-1. Introduction
-
-   Dynamic update operations have been defined for the Domain Name
-   System (DNS) in RFC 2136, but without a detailed description of
-   security for those updates.  Means of securing the DNS and using it
-   for key distribution have been defined in RFC 2065.
-
-   This memo proposes techniques based on the defined DNS security
-   mechanisms to authenticate DNS updates.
-
-   Familiarity with the DNS system [RFC 1034, 1035] is assumed.
-   Familiarity with the DNS security and dynamic update proposals will
-   be helpful.
-
-1.1 Overview of DNS Dynamic Update
-
-   DNS dynamic update defines a new DNS opcode, new DNS request and
-   response structure if that opcode is used, and new error codes.  An
-   update can specify complex combinations of deletion and insertion
-   (with or without pre-existence testing) of resource records (RRs)
-   with one or more owner names; however, all testing and changes for
-   any particular DNS update request are restricted to a single zone.
-   Updates occur at the primary server for a zone.
-
-   The primary server for a secure dynamic zone must increment the zone
-   SOA serial number when an update occurs or the next time the SOA is
-   retrieved if one or more updates have occurred since the previous SOA
-   retrieval and the updates themselves did not update the SOA.
-
-1.2 Overview of DNS Security
-
-   DNS security authenticates data in the DNS by also storing digital
-   signatures in the DNS as SIG resource records (RRs).  A SIG RR
-   provides a digital signature on the set of all RRs with the same
-   owner name and class as the SIG and whose type is the type covered by
-   the SIG.  The SIG RR cryptographically binds the covered RR set to
-   the signer, time signed, signature expiration date, etc.  There are
-   one or more keys associated with every secure zone and all data in
-   the secure zone is signed either by a zone key or by a dynamic update
-
-
-
-Eastlake                    Standards Track                     [Page 2]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-   key tracing its authority to a zone key.
-
-   DNS security also defines transaction SIGs and request SIGs.
-   Transaction SIGs appear at the end of a response.  Transaction SIGs
-   authenticate the response and bind it to the corresponding request
-   with the key of the host where the responding DNS server is.  Request
-   SIGs appear at the end of a request and authenticate the request with
-   the key of the submitting entity.
-
-   Request SIGs are the primary means of authenticating update requests.
-
-   DNS security also permits the storage of public keys in the DNS via
-   KEY RRs.  These KEY RRs are also, of course, authenticated by SIG
-   RRs.  KEY RRs for zones are stored in their superzone and subzone
-   servers, if any, so that the secure DNS tree of zones can be
-   traversed by a security aware resolver.
-
-2. Two Basic Modes
-
-   A dynamic secure zone is any secure DNS zone containing one or more
-   KEY RRs that can authorize dynamic updates, i.e., entity or user KEY
-   RRs with the signatory field non-zero, and whose zone KEY RR
-   signatory field indicates that updates are implemented. There are two
-   basic modes of dynamic secure zone which relate to the update
-   strategy, mode A and mode B.  A summary comparison table is given
-   below and then each mode is described.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 3]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-                   SUMMARY OF DYNAMIC SECURE ZONE MODES
-
-   CRITERIA:                |   MODE A           |   MODE B
-   =========================+====================+===================
-   Definition:              | Zone Key Off line  | Zone Key On line
-   =========================+====================+===================
-   Server Workload          |   Low              |   High
-   -------------------------+--------------------+-------------------
-   Static Data Security     |   Very High        |   Medium-High
-   -------------------------+--------------------+-------------------
-   Dynamic Data Security    |   Medium           |   Medium-High
-   -------------------------+--------------------+-------------------
-   Key Restrictions         |   Fine grain       |   Coarse grain
-   -------------------------+--------------------+-------------------
-   Dynamic Data Temporality |   Transient        |   Permanent
-   -------------------------+--------------------+-------------------
-   Dynamic Key Rollover     |   No               |   Yes
-   -------------------------+--------------------+-------------------
-
-   For mode A, the zone owner key and static zone master file are always
-   kept off-line for maximum security of the static zone contents.
-
-   As a consequence, any dynamicly added or changed RRs are signed in
-   the secure zone by their authorizing dynamic update key and they are
-   backed up, along with this SIG RR, in a separate online dynamic
-   master file.  In this type of zone, server computation is minimized
-   since the server need only check signatures on the update data and
-   request, which have already been signed by the updater, generally a
-   much faster operation than signing data.  However, the AXFR SIG and
-   NXT RRs which covers the zone under the zone key will not cover
-   dynamically added data.  Thus, for type A dynamic secure zones, zone
-   transfer security is not automatically provided for dynamically added
-   RRs, where they could be omitted, and authentication is not provided
-   for the server denial of the existence of a dynamically added type.
-   Because the dynamicly added RRs retain their update KEY signed SIG,
-   finer grained control of updates can be implemented via bits in the
-   KEY RR signatory field.  Because dynamic data is only stored in the
-   online dynamic master file and only authenticated by dynamic keys
-   which expire, updates are transient in nature.  Key rollover for an
-   entity that can authorize dynamic updates is more cumbersome since
-   the authority of their key must be traceable to a zone key and so, in
-   general, they must securely communicate a new key to the zone
-   authority for manual transfer to the off line static master file.
-   NOTE: for this mode the zone SOA must be signed by a dynamic update
-   key and that private key must be kept on line so that the SOA can be
-   changed for updates.
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 4]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-   For mode B, the zone owner key and master file are kept on-line at
-   the zone primary server. When authenticated updates succeed, SIGs
-   under the zone key for the resulting data (including the possible NXT
-   type bit map changes) are calculated and these SIG (and possible NXT)
-   changes are entered into the zone and the unified on-line master
-   file.  (The zone transfer AXFR SIG may be recalculated for each
-   update or on demand when a zone transfer is requested and it is out
-   of date.)
-
-   As a consequence, this mode requires considerably more computational
-   effort on the part of the server as the public/private keys are
-   generally arranged so that signing (calculating a SIG) is more effort
-   than verifying a signature.  The security of static data in the zone
-   is decreased because the ultimate state of the static data being
-   served and the ultimate zone authority private key are all on-line on
-   the net.  This means that if the primary server is subverted, false
-   data could be authenticated to secondaries and other
-   servers/resolvers.  On the other hand, this mode of operation means
-   that data added dynamically is more secure than in mode A.  Dynamic
-   data will be covered by the AXFR SIG and thus always protected during
-   zone transfers and will be included in NXT RRs so that it can be
-   falsely denied by a server only to the same extent that static data
-   can (i.e., if it is within a wild card scope). Because the zone key
-   is used to sign all the zone data, the information as to who
-   originated the current state of dynamic RR sets is lost, making
-   unavailable the effects of some of the update control bits in the KEY
-   RR signatory field.  In addition, the incorporation of the updates
-   into the primary master file and their authentication by the zone key
-   makes then permanent in nature.  Maintaining the zone key on-line
-   also means that dynamic update keys which are signed by the zone key
-   can be dynamically updated since the zone key is available to
-   dynamically sign new values.
-
-   NOTE:  The Mode A / Mode B distinction only effects the validation
-   and performance of update requests.  It has no effect on retrievals.
-   One reasonable operational scheme may be to keep a mostly static main
-   zone operating in Mode A and have one or more dynamic subzones
-   operating in Mode B.
-
-3. Keys
-
-   Dynamic update requests depend on update keys as described in section
-   3.1 below.  In addition, the zone secure dynamic update mode and
-   availability of some options is indicated in the zone key.  Finally,
-   a special rule is used in searching for KEYs to validate updates as
-   described in section 3.3.
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 5]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-3.1 Update Keys
-
-   All update requests to a secure zone must include signatures by one
-   or more key(s) that together can authorize that update.  In order for
-   the Domain Name System (DNS) server receiving the request to confirm
-   this, the key or keys must be available to and authenticated by that
-   server as a specially flagged KEY Resource Record.
-
-   The scope of authority of such keys is indicated by their KEY RR
-   owner name, class, and signatory field flags as described below. In
-   addition, such KEY RRs must be entity or user keys and not have the
-   authentication use prohibited bit on.  All parts of the actual update
-   must be within the scope of at least one of the keys used for a
-   request SIG on the update request as described in section 4.
-
-3.1.1 Update Key Name Scope
-
-   The owner name of any update authorizing KEY RR must (1) be the same
-   as the owner name of any RRs being added or deleted or (2) a wildcard
-   name including within its extended scope (see section 3.3) the name
-   of any RRs being added or deleted and those RRs must be in the same
-   zone.
-
-3.1.2 Update Key Class Scope
-
-   The class of any update authorizing KEY RR must be the same as the
-   class of any RR's being added or deleted.
-
-3.1.3 Update Key Signatory Field
-
-   The four bit "signatory field" (see RFC 2065) of any update
-   authorizing KEY RR must be non-zero.  The bits have the meanings
-   described below for non-zone keys (see section 3.2 for zone type
-   keys).
-
-                    UPDATE KEY RR SIGNATORY FIELD BITS
-
-         0           1           2           3
-   +-----------+-----------+-----------+-----------+
-   |   zone    |  strong   |  unique   |  general  |
-   +-----------+-----------+-----------+-----------+
-
-   Bit 0, zone control - If nonzero, this key is authorized to attach,
-        detach, and move zones by creating and deleting NS, glue A, and
-        zone KEY RR(s).  If zero, the key can not authorize any update
-        that would effect such RRs.  This bit is meaningful for both
-        type A and type B dynamic secure zones.
-
-
-
-
-Eastlake                    Standards Track                     [Page 6]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-        NOTE:  do not confuse the "zone" signatory field bit with the
-        "zone" key type bit.
-
-   Bit 1, strong update - If nonzero, this key is authorized to add and
-        delete RRs even if there are other RRs with the same owner name
-        and class that are authenticated by a SIG signed with a
-        different dynamic update KEY. If zero, the key can only
-        authorize updates where any existing RRs of the same owner and
-        class are authenticated by a SIG using the same key.  This bit
-        is meaningful only for type A dynamic zones and is ignored in
-        type B dynamic zones.
-
-        Keeping this bit zero on multiple KEY RRs with the same or
-        nested wild card owner names permits multiple entities to exist
-        that can create and delete names but can not effect RRs with
-        different owner names from any they created.  In effect, this
-        creates two levels of dynamic update key, strong and weak, where
-        weak keys are limited in interfering with each other but a
-        strong key can interfere with any weak keys or other strong
-        keys.
-
-   Bit 2, unique name update - If nonzero, this key is authorized to add
-        and update RRs for only a single owner name.  If there already
-        exist RRs with one or more names signed by this key, they may be
-        updated but no new name created until the number of existing
-        names is reduced to zero.  This bit is meaningful only for mode
-        A dynamic zones and is ignored in mode B dynamic zones. This bit
-        is meaningful only if the owner name is a wildcard.  (Any
-        dynamic update KEY with a non-wildcard name is, in effect, a
-        unique name update key.)
-
-        This bit can be used to restrict a KEY from flooding a zone with
-        new names.  In conjunction with a local administratively imposed
-        limit on the number of dynamic RRs with a particular name, it
-        can completely restrict a KEY from flooding a zone with RRs.
-
-   Bit 3, general update - The general update signatory field bit has no
-        special meaning.  If the other three bits are all zero, it must
-        be one so that the field is non-zero to designate that the key
-        is an update key.  The meaning of all values of the signatory
-        field with the general bit and one or more other signatory field
-        bits on is reserved.
-
-   All the signatory bit update authorizations described above only
-   apply if the update is within the name and class scope as per
-   sections 3.1.1 and 3.1.2.
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 7]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-3.2 Zone Keys and Update Modes
-
-   Zone type keys are automatically authorized to sign anything in their
-   zone, of course, regardless of the value of their signatory field.
-   For zone keys, the signatory field bits have different means than
-   they they do for update keys, as shown below.  The signatory field
-   MUST be zero if dynamic update is not supported for a zone and MUST
-   be non-zero if it is.
-
-                     ZONE KEY RR SIGNATORY FIELD BITS
-
-                  0           1           2           3
-            +-----------+-----------+-----------+-----------+
-            |   mode    |  strong   |  unique   |  general  |
-            +-----------+-----------+-----------+-----------+
-
-   Bit 0, mode - This bit indicates the update mode for this zone.  Zero
-        indicates mode A while a one indicates mode B.
-
-   Bit 1, strong update - If nonzero, this indicates that the "strong"
-        key feature described in section 3.1.3 above is implemented and
-        enabled for this secure zone.  If zero, the feature is not
-        available.  Has no effect if the zone is a mode B secure update
-        zone.
-
-   Bit 2, unique name update - If nonzero, this indicates that the
-        "unique name" feature described in section 3.1.3 above is
-        implemented and enabled for this secure zone.  If zero, this
-        feature is not available.  Has no effect if the zone is a mode B
-        secure update zone.
-
-   Bit 3, general - This bit has no special meeting.  If dynamic update
-        for a zone is supported and the other bits in the zone key
-        signatory field are zero, it must be a one.  The meaning of zone
-        keys where the signatory field has the general bit and one or
-        more other bits on is reserved.
-
-   If there are multiple dynamic update KEY RRs for a zone and zone
-   policy is in transition, they might have different non-zero signatory
-   fields.  In that case, strong and unique name restrictions must be
-   enforced as long as there is a non-expired zone key being advertised
-   that indicates mode A with the strong or unique name bit on
-   respectively.  Mode B updates MUST be supported as long as there is a
-   non-expired zone key that indicates mode B.  Mode A updates may be
-   treated as mode B updates at server option if non-expired zone keys
-   indicate that both are supported.
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 8]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-   A server that will be executing update operations on a zone, that is,
-   the primary master server, MUST not advertize a zone key that will
-   attract requests for a mode or features that it can not support.
-
-3.3 Wildcard Key Punch Through
-
-   Just as a zone key is valid throughout the entire zone, update keys
-   with wildcard names are valid throughout their extended scope, within
-   the zone. That is, they remain valid for any name that would match
-   them, even existing specific names within their apparent scope.
-
-   If this were not so, then whenever a name within a wildcard scope was
-   created by dynamic update, it would be necessary to first create a
-   copy of the KEY RR with this name, because otherwise the existence of
-   the more specific name would hide the authorizing KEY RR and would
-   make later updates impossible.  An updater could create such a KEY RR
-   but could not zone sign it with their authorizing signer.  They would
-   have to sign it with the same key using the wildcard name as signer.
-   Thus in creating, for example, one hundred type A RRs authorized by a
-   *.1.1.1.in-addr.arpa. KEY RR, without key punch through 100 As, 100
-   KEYs, and 200 SIGs would have to be created as opposed to merely 100
-   As and 100 SIGs with key punch through.
-
-4. Update Signatures
-
-   Two kinds of signatures can appear in updates.  Request signatures,
-   which are always required, cover the entire request and authenticate
-   the DNS header, including opcode, counts, etc., as well as the data.
-   Data signatures, on the other hand, appear only among the RRs to be
-   added and are only required for mode A operation.  These two types of
-   signatures are described further below.
-
-4.1 Update Request Signatures
-
-   An update can effect multiple owner names in a zone.  It may be that
-   these different names are covered by different dynamic update keys.
-   For every owner name effected, the updater must know a private key
-   valid for that name (and the zone's class) and must prove this by
-   appending request SIG RRs under each such key.
-
-   As specified in RFC 2065, a request signature is a SIG RR occurring
-   at the end of a request with a type covered field of zero.  For an
-   update, request signatures occur in the Additional information
-   section.  Each request SIG signs the entire request, including DNS
-   header, but excluding any other request SIG(s) and with the ARCOUNT
-   in the DNS header set to what it wold be without the request SIGs.
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 9]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-4.2 Update Data Signatures
-
-   Mode A dynamic secure zones require that the update requester provide
-   SIG RRs that will authenticate the after update state of all RR sets
-   that are changed by the update and are non-empty after the update.
-   These SIG RRs appear in the request as RRs to be added and the
-   request must delete any previous data SIG RRs that are invalidated by
-   the request.
-
-   In Mode B dynamic secure zones, all zone data is authenticated by
-   zone key SIG RRs.  In this case, data signatures need not be included
-   with the update.  A resolver can determine which mode an updatable
-   secure zone is using by examining the signatory field bits of the
-   zone KEY RR (see section 3.2).
-
-5. Security Considerations
-
-   Any zone permitting dynamic updates is inherently less secure than a
-   static secure zone maintained off line as recommended in RFC 2065. If
-   nothing else, secure dynamic update requires on line change to and
-   re-signing of the zone SOA resource record (RR) to increase the SOA
-   serial number.  This means that compromise of the primary server host
-   could lead to arbitrary serial number changes.
-
-   Isolation of dynamic RRs to separate zones from those holding most
-   static RRs can limit the damage that could occur from breach of a
-   dynamic zone's security.
-
-References
-
-   [RFC2065] Eastlake, D., and C. Kaufman, "Domain Name System Security
-   Extensions", RFC 2065, CyberCash, Iris, January 1997.
-
-   [RFC2136] Vixie, P., Editor, Thomson, T., Rekhter, Y., and J. Bound,
-   "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
-   April 1997.
-
-   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
-   Specifications", STD 13, RFC 1035, November 1987.
-
-   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
-   STD 13, RFC 1034, November 1987.
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 10]
-
-RFC 2137                         SDNSDU                       April 1997
-
-
-Author's Address
-
-   Donald E. Eastlake, 3rd
-   CyberCash, Inc.
-   318 Acton Street
-   Carlisle, MA 01741 USA
-
-   Phone:   +1 508-287-4877
-            +1 508-371-7148 (fax)
-            +1 703-620-4200 (main office, Reston, Virginia, USA)
-   EMail:   dee@cybercash.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 11]
-
diff --git a/contrib/bind9/doc/rfc/rfc2163.txt b/contrib/bind9/doc/rfc/rfc2163.txt
deleted file mode 100644
index 00fcee7..0000000
--- a/contrib/bind9/doc/rfc/rfc2163.txt
+++ /dev/null
@@ -1,1459 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       C. Allocchio
-Request for Comments: 2163                                    GARR-Italy
-Obsoletes: 1664                                             January 1998
-Category: Standards Track
-
-
-                  Using the Internet DNS to Distribute
-            MIXER Conformant Global Address Mapping (MCGAM)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-Abstract
-
-   This memo is the complete technical specification to store in the
-   Internet Domain Name System (DNS) the mapping information (MCGAM)
-   needed by MIXER conformant e-mail gateways and other tools to map
-   RFC822 domain names into X.400 O/R names and vice versa.  Mapping
-   information can be managed in a distributed rather than a centralised
-   way. Organizations can publish their MIXER mapping or preferred
-   gateway routing information using just local resources (their local
-   DNS server), avoiding the need for a strong coordination with any
-   centralised organization. MIXER conformant gateways and tools located
-   on Internet hosts can retrieve the mapping information querying the
-   DNS instead of having fixed tables which need to be centrally updated
-   and distributed.
-
-   This memo obsoletes RFC1664. It includes the changes introduced by
-   MIXER specification with respect to RFC1327: the new 'gate1' (O/R
-   addresses to domain) table is fully supported. Full backward
-   compatibility with RFC1664 specification is mantained, too.
-
-   RFC1664 was a joint effort of IETF X400 operation working group
-   (x400ops) and TERENA (formely named "RARE") Mail and Messaging
-   working group (WG-MSG). This update was performed by the IETF MIXER
-   working group.
-
-
-
-
-
-
-Allocchio                   Standards Track                     [Page 1]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-1. Introduction
-
-   The connectivity between the Internet SMTP mail and other mail
-   services, including the Internet X.400 mail and the commercial X.400
-   service providers, is assured by the Mail eXchanger (MX) record
-   information distributed via the Internet Domain Name System (DNS). A
-   number of documents then specify in details how to convert or encode
-   addresses from/to RFC822 style to the other mail system syntax.
-   However, only conversion methods provide, via some algorithm or a set
-   of mapping rules, a smooth translation, resulting in addresses
-   indistinguishable from the native ones in both RFC822 and foreign
-   world.
-
-   MIXER describes a set of mappings (MIXER Conformant Global Address
-   Mapping - MCGAM) which will enable interworking between systems
-   operating the CCITT X.400 (1984/88/92) Recommendations and systems
-   using using the RFC822 mail protocol, or protocols derived from
-   RFC822. That document addresses conversion of services, addresses,
-   message envelopes, and message bodies between the two mail systems.
-   This document is concerned with one aspect of MIXER: the mechanism
-   for mapping between X.400 O/R addresses and RFC822 domain names. As
-   described in Appendix F of MIXER, implementation of the mappings
-   requires a database which maps between X.400 O/R addresses and domain
-   names; in RFC1327 this database was statically defined.
-
-   The original approach in RFC1327 required many efforts to maintain
-   the correct mapping: all the gateways needed to get coherent tables
-   to apply the same mappings, the conversion tables had to be
-   distributed among all the operational gateways, and also every update
-   needed to be distributed.
-
-   The concept of mapping rules distribution and use has been revised in
-   the new MIXER specification, introducing the concept of MIXER
-   Conformant Global Address Mapping (MCGAM). A MCGAM does not need to
-   be globally installed by any MIXER conformant gateway in the world
-   any more. However MIXER requires now efficient methods to publish its
-   MCGAM.
-
-   Static tables are one of the possible methods to publish MCGAM.
-   However this static mechanism requires quite a long time to be spent
-   modifying and distributing the information, putting heavy constraints
-   on the time schedule of every update.  In fact it does not appear
-   efficient compared to the Internet Domain Name Service (DNS).  More
-   over it does not look feasible to distribute the database to a large
-   number of other useful applications, like local address converters,
-   e-mail User Agents or any other tool requiring the mapping rules to
-   produce correct results.
-
-
-
-
-Allocchio                   Standards Track                     [Page 2]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   Two much more efficient methods are proposed by MIXER for publication
-   of MCGAM: the Internet DNS and X.500. This memo is the complete
-   technical specification for publishing MCGAM via Internet DNS.
-
-   A first proposal to use the Internet DNS to store, retrieve and
-   maintain those mappings was introduced by two of the authors of
-   RFC1664 (B. Cole and R. Hagens) adopting two new DNS resource record
-   (RR)  types: TO-X400 and TO-822. This proposal now adopts a more
-   complete strategy, and requires one new RR only. The distribution of
-   MCGAMs via DNS is in fact an important service for the whole Internet
-   community: it completes the information given by MX resource record
-   and it allows to produce clean addresses when messages are exchanged
-   among the Internet RFC822 world and the X.400 one (both Internet and
-   Public X.400 service providers).
-
-   A first experiment in using the DNS without expanding the current set
-   of RR and using available ones was deployed by some of the authors of
-   RFC1664 at the time of its development. The existing PTR resource
-   records were used to store the mapping rules, and a new DNS tree was
-   created under the ".it" top level domain. The result of the
-   experiment was positive, and a few test applications ran under this
-   provisional set up. This test was also very useful in order to define
-   a possible migration strategy during the deployment of the new DNS
-   containing the new RR. The Internet DNS nameservers wishing to
-   provide this mapping information need in fact to be modified to
-   support the new RR type, and in the real Internet, due to the large
-   number of different implementations, this takes some time.
-
-   The basic idea is to adopt a new DNS RR to store the mapping
-   information. The RFC822 to X.400 mapping rules (including the so
-   called 'gate2' rules) will be stored in the ordinary DNS tree, while
-   the definition of a new branch of the name space defined under each
-   national top level domain is envisaged in order to contain the X.400
-   to RFC822 mappings ('table1' and 'gate1'). A "two-way" mapping
-   resolution schema is thus fully implemented.
-
-   The creation of the new domain name space representing the X.400 O/R
-   names structure also provides the chance to use the DNS to distribute
-   dynamically other X.400 related information, thus solving other
-   efficiency problems currently affecting the X.400 MHS service.
-
-   In this paper we will adopt the MCGAM syntax, showing how it can be
-   stored into the Internet DNS.
-
-
-
-
-
-
-
-
-Allocchio                   Standards Track                     [Page 3]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-1.1 Definitions syntax
-
-   The definitions in this document is given in BNF-like syntax, using
-   the following conventions:
-
-      |   means choice
-      \   is used for continuation of a definition over several lines
-      []  means optional
-      {}  means repeated one or more times
-
-   The definitions, however, are detailed only until a certain level,
-   and below it self-explaining character text strings will be used.
-
-2. Motivation
-
-   Implementations of MIXER gateways require that a database store
-   address mapping information for X.400 and RFC822. This information
-   must be made available (published) to all MIXER gateways. In the
-   Internet community, the DNS has proven to be a practical mean for
-   providing a distributed name service. Advantages of using a DNS based
-   system over a table based approach for mapping between O/R addresses
-   and domain names are:
-
-     - It avoids fetching and storing of entire mapping tables by every
-       host that wishes to implement MIXER gateways and/or tools
-
-     - Modifications to the DNS based mapping information can be made
-       available in a more timely manner than with a table driven
-       approach.
-
-     - It allows full authority delegation, in agreement with the
-       Internet regionalization process.
-
-     - Table management is not necessarily required for DNS-based
-       MIXER gateways.
-
-     - One can determine the mappings in use by a remote gateway by
-       querying the DNS (remote debugging).
-
-   Also many other tools, like address converters and User Agents can
-   take advantage of the real-time availability of MIXER tables,
-   allowing a much easier maintenance of the information.
-
-3. The domain space for X.400 O/R name addresses
-
-   Usual domain names (the ones normally used as the global part of an
-   RFC822 e-mail address) and their associated information, i.e., host
-   IP addresses, mail exchanger names, etc., are stored in the DNS as a
-
-
-
-Allocchio                   Standards Track                     [Page 4]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   distributed database under a number of top-level domains. Some top-
-   level domains are used for traditional categories or international
-   organisations (EDU, COM, NET, ORG, INT, MIL...). On the other hand
-   any country has its own two letter ISO country code as top-level
-   domain (FR, DE, GB, IT, RU, ...), including "US" for USA.  The
-   special top-level/second-level couple IN-ADDR.ARPA is used to store
-   the IP address to domain name relationship. This memo defines in the
-   above structure the appropriate way to locate the X.400 O/R name
-   space, thus enabling to store in DNS the MIXER mappings (MCGAMs).
-
-   The MIXER mapping information is composed by four tables:
-
-    - 'table1' and 'gate1' gives the translation from X.400 to RFC822;
-    - 'table2' and 'gate2' tables map RFC822 into X.400.
-
-   Each mapping table is composed by mapping rules, and a single mapping
-   rule is composed by a keyword (the argument of the mapping function
-   derived from the address to be translated) and a translator (the
-   mapping function parameter):
-
-                            keyword#translator#
-
-   the '#' sign is a delimiter enclosing the translator. An example:
-
-                 foo.bar.us#PRMD$foo\.bar.ADMD$intx.C$us#
-
-   Local mappings are not intended for use outside their restricted
-   environment, thus they should not be included in DNS. If local
-   mappings are used, they should be stored using static local tables,
-   exactly as local static host tables can be used with DNS.
-
-   The keyword of a 'table2' and 'gate2' table entry is a valid RFC822
-   domain; thus the usual domain name space can be used without problems
-   to store these entries.
-   On the other hand, the keyword of a 'table1' and 'gate1' entry
-   belongs to the X.400 O/R name space. The X.400 O/R name space does
-   not usually fit into the usual domain name space, although there are
-   a number of similarities; a new name structure is thus needed to
-   represent it. This new name structure contains the X.400 mail
-   domains.
-
-   To ensure the correct functioning of the DNS system, the new X.400
-   name structure must be hooked to the existing domain name space in a
-   way which respects the existing name hierarchy.
-
-   A possible solution was to create another special branch, starting
-   from the root of the DNS tree, somehow similar to the in-addr.arpa
-   tree. This idea would have required to establish a central authority
-
-
-
-Allocchio                   Standards Track                     [Page 5]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   to coordinate at international level the management of each national
-   X.400 name tree, including the X.400 public service providers. This
-   coordination problem is a heavy burden if approached globally. More
-   over the X.400 name structure is very 'country oriented': thus while
-   it requires a coordination at national level, it does not have
-   concepts like the international root. In fact the X.400 international
-   service is based  on a large number of bilateral agreements, and only
-   within some communities an international coordination service exists.
-
-   The X.400 two letter ISO country codes, however, are the same used
-   for the RFC822 country top-level domains and this gives us an
-   appropriate hook to insert the new branches. The proposal is, in
-   fact, to create under each national top level ISO country code a new
-   branch in the name space. This branch represents exactly the X.400
-   O/R name structure as defined in each single country, following the
-   ADMD, PRMD, O, OU hierarchy. A unique reserved label 'X42D' is placed
-   under each country top-level domain, and hence the national X.400
-   name space derives its own structure:
-
-                                    . (root)
-                                    |
-      +-----------------+-----------+--------+-----------------+...
-      |                 |                    |                 |
-     edu                it                   us                fr
-      |                 |                    |                 |
-  +---+---+...    +-----+-----+...     +-----+-----+...     +--+---+...
-  |       |       |     |     |        |     |     |        |      |
- ...     ...     cnr   X42D  infn      va    ca   X42D     X42D  inria
-                        |                    |     |        |
-           +------------+------------+...   ...   ...  +----+-------+...
-           |            |            |                 |            |
-    ADMD-PtPostel  ADMD-garr  ADMD-Master400        ADMD-atlas  ADMD-red
-                        |            |                 |            |
-             +----------+----+...   ...        +-------+------+... ...
-             |               |                 |              |
-         PRMD-infn       PRMD-STET        PRMD-Telecom   PRMD-Renault
-             |               |                 |              |
-            ...             ...               ...            ...
-
-
-   The creation of the X.400 new name tree at national level solves the
-   problem of the international coordination. Actually the coordination
-   problem is just moved at national level, but it thus becomes easier
-   to solve. The coordination at national level between the X.400
-   communities and the Internet world is already a requirement for the
-   creation of the national static MIXER mapping tables; the use of the
-   Internet DNS gives further motivations for this coordination.
-
-
-
-
-Allocchio                   Standards Track                     [Page 6]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   The coordination at national level also fits in the new concept of
-   MCGAM pubblication. The DNS in fact allows a step by step authority
-   distribution, up to a final complete delegation: thus organizations
-   whishing to publish their MCGAM just need to receive delegation also
-   for their branch of the new X.400 name space. A further advantage of
-   the national based solution is to allow each country to set up its
-   own X.400 name structure in DNS and to deploy its own authority
-   delegation according to its local time scale and requirements, with
-   no loss of global service in the mean time. And last, placing the new
-   X.400 name tree and coordination process at national level fits into
-   the Internet regionalization and internationalisation process, as it
-   requires local bodies to take care of local coordination problems.
-
-   The DNS name space thus contains completely the information required
-   by an e-mail gateway or tool to perform the X.400-RFC822 mapping: a
-   simple query to the nearest nameserver provides it. Moreover there is
-   no more any need to store, maintain and distribute manually any
-   mapping table. The new X.400 name space can also contain further
-   information about the X.400 community, as DNS allows for it a
-   complete set of resource records, and thus it allows further
-   developments. This set of RRs in the new X.400 name space must be
-   considered 'reserved' and thus not used until further specifications.
-
-   The construction of the new domain space trees will follow the same
-   procedures used when organising at first the already existing DNS
-   space: at first the information will be stored in a quite centralised
-   way, and distribution of authority will be gradually achieved. A
-   separate document will describe the implementation phase and the
-   methods to assure a smooth introduction of the new service.
-
-4. The new DNS resource record for MIXER mapping rules: PX
-
-   The specification of the Internet DNS (RFC1035) provides a number of
-   specific resource records (RRs) to contain specific pieces of
-   information. In particular they contain the Mail eXchanger (MX) RR
-   and the host Address (A) records which are used by the Internet SMTP
-   mailers. As we will store the RFC822 to X.400 mapping information in
-   the already existing DNS name tree, we need to define a new DNS RR in
-   order to avoid any possible clash or misuse of already existing data
-   structures. The same new RR will also be used to store the mappings
-   from X.400 to RFC822. More over the mapping information, i.e., the
-   MCGAMs, has a specific format and syntax which require an appropriate
-   data structure and processing. A further advantage of defining a new
-   RR is the ability to include flexibility for some eventual future
-   development.
-
-
-
-
-
-
-Allocchio                   Standards Track                     [Page 7]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   The definition of the new 'PX' DNS resource record is:
-
-      class:        IN   (Internet)
-
-      name:         PX   (pointer to X.400/RFC822 mapping information)
-
-      value:        26
-
-   The PX RDATA format is:
-
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          |                  PREFERENCE                   |
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          /                    MAP822                     /
-          /                                               /
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          /                    MAPX400                    /
-          /                                               /
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   where:
-
-   PREFERENCE   A 16 bit integer which specifies the preference given to
-                this RR among others at the same owner.  Lower values
-                are preferred;
-
-   MAP822       A <domain-name> element containing <rfc822-domain>, the
-                RFC822 part of the MCGAM;
-
-   MAPX400      A <domain-name> element containing the value of
-                <x400-in-domain-syntax> derived from the X.400 part of
-                the MCGAM (see sect. 4.2);
-
-   PX records cause no additional section processing. The PX RR format
-   is the usual one:
-
-             <name> [<class>] [<TTL>] <type> <RDATA>
-
-   When we store in DNS a 'table1' or a 'gate1' entry, then <name> will
-   be an X.400 mail domain name in DNS syntax (see sect. 4.2). When we
-   store a 'table2' or a 'gate2' table entry, <name> will be an RFC822
-   mail domain name, including both fully qualified DNS domains and mail
-   only domains (MX-only domains). All normal DNS conventions, like
-   default values, wildcards, abbreviations and message compression,
-   apply also for all the components of the PX RR. In particular <name>,
-   MAP822 and MAPX400, as <domain-name> elements, must have the final
-   "." (root) when they are fully qualified.
-
-
-
-
-Allocchio                   Standards Track                     [Page 8]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-4.1 Additional features of the PX resource record
-
-   The definition of the RDATA for the PX resource record, and the fact
-   that DNS allows a distinction between an exact value and a wildcard
-   match for the <name> parameter, represent an extension of the MIXER
-   specification for mapping rules. In fact, any MCGAM entry is an
-   implicit wildcard entry, i.e., the rule
-
-      net2.it#PRMD$net2.ADMD$p400.C$it#
-
-   covers any RFC822 domain ending with 'net2.it', unless more detailed
-   rules for some subdomain in 'net2.it' are present. Thus there is no
-   possibility to specify explicitly a MCGAM as an exact match only
-   rule. In DNS an entry like
-
-      *.net2.it.   IN  PX  10   net2.it.  PRMD-net2.ADMD-p400.C-it.
-
-   specify the usual wildcard match as for MIXER tables. However an
-   entry like
-
-      ab.net2.it.  IN  PX  10   ab.net2.it.  O-ab.PRMD-net2.ADMDb.C-it.
-
-   is valid only for an exact match of 'ab.net2.it' RFC822 domain.
-
-   Note also that in DNS syntax there is no '#' delimiter around MAP822
-   and MAPX400 fields: the syntax defined in sect. 4.2 in fact does not
-   allow the <blank> (ASCII decimal 32) character within these fields,
-   making unneeded the use of an explicit delimiter as required in the
-   MIXER original syntax.
-
-   Another extension to the MIXER specifications is the PREFERENCE value
-   defined as part of the PX RDATA section. This numeric value has
-   exactly the same meaning than the similar one used for the MX RR. It
-   is thus possible to specify more than one single mapping for a domain
-   (both from RFC822 to X.400 and vice versa), giving as the preference
-   order. In MIXER static tables, however, you cannot specify more than
-   one mapping per each RFC822 domain, and the same restriction apply
-   for any X.400 domain mapping to an RFC822 one.
-
-   More over, in the X.400 recommendations a note suggests than an
-   ADMD=<blank> should be reserved for some special cases. Various
-   national functional profile specifications for an X.400 MHS states
-   that if an X.400 PRMD is reachable via any of its national ADMDs,
-   independently of its actual single or multiple connectivity with
-   them, it should use ADMD=<blank> to advertise this fact. Again, if a
-   PRMD has no connections to any ADMD it should use ADMD=0 to notify
-   its status, etc. However, in most of the current real situations, the
-   ADMD service providers do not accept messages coming from their
-
-
-
-Allocchio                   Standards Track                     [Page 9]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   subscribers if they have a blank ADMD, forcing them to have their own
-   ADMD value. In such a situation there are problems in indicating
-   properly the actually working mappings for domains with multiple
-   connectivity. The PX RDATA 'PREFERENCE' extension was introduced to
-   take in consideration these problems.
-
-   However, as these extensions are not available with MIXER static
-   tables, it is strongly discouraged to use them when interworking with
-   any table based gateway or application. The extensions were in fact
-   introduced just to add more flexibility, like the PREFERENCE value,
-    or they were already implicit in the DNS mechanism, like the
-   wildcard specification. They should be used very carefully or just
-   considered 'reserved for future use'. In particular, for current use,
-   the PREFERENCE value in the PX record specification should be fixed
-   to a value of 50, and only wildcard specifications should be used
-   when specifying <name> values.
-
-4.2 The DNS syntax for an X.400 'domain'
-
-   The syntax definition of the MCGAM rules is defined in appendix F of
-   that document. However that syntax is not very human oriented and
-   contains a number of characters which have a special meaning in other
-   fields of the Internet DNS. Thus in order to avoid any possible
-   problem, especially due to some old DNS implementations still being
-   used in the Internet, we define a syntax for the X.400 part of any
-   MCGAM rules (and hence for any X.400 O/R name) which makes it
-   compatible with a <domain-name> element, i.e.,
-
-   <domain-name>    ::= <subdomain> | " "
-   <subdomain>      ::= <label> | <label> "." <subdomain>
-   <label>          ::= <alphanum>|
-                        <alphanum> {<alphanumhyphen>} <alphanum>
-   <alphanum>       ::= "0".."9" | "A".."Z" | "a".."z"
-   <alphanumhyphen> ::= "0".."9" | "A".."Z" | "a".."z" | "-"
-
-   (see RFC1035, section 2.3.1, page 8).  The legal character set for
-   <label> does not correspond to the IA5 Printablestring one used in
-   MIXER to define MCGAM rules. However a very simple "escape mechanism"
-   can be applied in order to bypass the problem. We can in fact simply
-   describe the X.400 part of a MCGAM rule format as:
-
-     <map-rule>   ::= <map-elem> | <map-elem> { "." <map-elem> }
-     <map-elem>   ::= <attr-label> "$" <attr-value>
-     <attr-label> ::= "C" | "ADMD" | "PRMD" | "O" | "OU"
-     <attr-value> ::= " " | "@" | IA5-Printablestring
-
-
-
-
-
-
-Allocchio                   Standards Track                    [Page 10]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   As you can notice <domain-name> and <map-rule> look similar, and also
-   <label> and <map-elem> look the same. If we define the correct method
-   to transform a <map-elem> into a <label> and vice versa the problem
-   to write a MCGAM rule in <domain-name> syntax is solved.
-
-   The RFC822 domain part of any MCGAM rule is of course already in
-   <domain-name> syntax, and thus remains unchanged.
-
-   In particular, in a 'table1' or 'gate1' mapping rule the 'keyword'
-   value must be converted into <x400-in-domain-syntax> (X.400 mail DNS
-   mail domain), while the 'translator' value is already a valid RFC822
-   domain.  Vice versa in a 'table2' or 'gate2' mapping rule, the
-   'translator' must be converted into <x400-in-domain-syntax>, while
-   the 'keyword' is already a valid RFC822 domain.
-
-4.2.1 IA5-Printablestring to <alphanumhyphen> mappings
-
-   The problem of unmatching IA5-Printablestring and <label> character
-   set definition is solved by a simple character mapping rule: whenever
-   an IA5 character does not belong to <alphanumhyphen>, then it is
-   mapped using its 3 digit decimal ASCII code, enclosed in hyphens. A
-   small set of special rules is also defined for the most frequent
-   cases. Moreover some frequent characters combinations used in MIXER
-   rules are also mapped as special cases.
-
-   Let's then define the following simple rules:
-
-    MCGAM rule            DNS store translation    conditions
-    -----------------------------------------------------------------
-    <attr-label>$@        <attr-label>             missing attribute
-    <attr-label>$<blank>  <attr-label>"b"          blank attribute
-    <attr-label>$xxx      <attr-label>-xxx         elsewhere
-
-   Non <alphanumhyphen> characters in <attr-value>:
-
-    MCGAM rule            DNS store translation    conditions
-    -----------------------------------------------------------------
-    -                     -h-                      hyphen
-    \.                    -d-                      quoted dot
-    <blank>               -b-                      blank
-    <non A/N character>   -<3digit-decimal>-       elsewhere
-
-   If the DNS store translation of <attr-value> happens to end with an
-   hyphen, then this last hyphen is omitted.
-
-   Let's now have some examples:
-
-
-
-
-
-Allocchio                   Standards Track                    [Page 11]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-    MCGAM rule            DNS store translation    conditions
-    -----------------------------------------------------------------
-    PRMD$@                PRMD                     missing attribute
-    ADMD$<blank>          ADMDb                    blank attribute
-    ADMD$400-net          ADMD-400-h-net           hyphen mapping
-    PRMD$UK\.BD           PRMD-UK-d-BD             quoted dot mapping
-    O$ACME Inc\.          O-ACME-b-Inc-d           blank & final hyphen
-    PRMD$main-400-a       PRMD-main-h-400-h-a      hyphen mapping
-    O$-123-b              O--h-123-h-b             hyphen mapping
-    OU$123-x              OU-123-h-x               hyphen mapping
-    PRMD$Adis+co          PRMD-Adis-043-co         3digit mapping
-
-   Thus, an X.400 part from a MCGAM like
-
-     OU$uuu.O$@.PRMD$ppp\.rrr.ADMD$aaa ddd-mmm.C$cc
-
-   translates to
-
-     OU-uuu.O.PRMD-ppp-d-rrr.ADMD-aaa-b-ddd-h-mmm.C-cc
-
-   Another example:
-
-     OU$sales dept\..O$@.PRMD$ACME.ADMD$ .C$GB
-
-   translates to
-
-     OU-sales-b-dept-d.O.PRMD-ACME.ADMDb.C-GB
-
-4.2.2 Flow chart
-
-   In order to achieve the proper DNS store translations of the X.400
-   part of a MCGAM or any other X.400 O/R name, some software tools will
-   be used. It is in fact evident that the above rules for converting
-   mapping table from MIXER to DNS format (and vice versa) are not user
-   friendly enough to think of a human made conversion.
-
-   To help in designing such tools, we describe hereunder a small flow
-   chart. The fundamental rule to be applied during translation is,
-   however, the following:
-
-      "A string must be parsed from left to right, moving appropriately
-      the pointer in order not to consider again the already translated
-      left section of the string in subsequent analysis."
-
-
-
-
-
-
-
-
-Allocchio                   Standards Track                    [Page 12]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   Flow chart 1 - Translation from MIXER to DNS format:
-
-                 parse  single attribute
-              (enclosed in "." separators)
-                           |
-            (yes)  ---  <label>$@ ?  ---  (no)
-              |                             |
-        map to <label>        (no)  <label>$<blank> ?  (yes)
-              |                 |                        |
-              |           map to <label>-        map to <label>"b"
-              |                 |                        |
-              |           map "\." to -d-                |
-              |                 |                        |
-              |           map "-" to -h-                 |
-              |                 |                        |
-              |    map non A/N char to -<3digit>-        |
-  restart     |                 |                        |
-     ^        |      remove (if any) last "-"            |
-     |        |                 |                        |
-     |        \------->     add a  "."    <--------------/
-     |                          |
-     \----------  take  next  attribute  (if  any)
-
-
-   Flow chart 2 - Translation from DNS to MIXER format:
-
-
-                parse single attribute
-            (enclosed in "." separators)
-                          |
-            (yes) ---- <label> ? ---- (no)
-              |                          |
-      map to <label>$@        (no) <label>"b" ? (yes)
-              |                 |                 |
-              |           map to <label>$    map to <label>$<blank>
-              |                 |                 |
-              |           map -d- to "\."         |
-              |                 |                 |
-              |           map -h- to "-"          |
-              |                 |                 |
-              |           map -b- to " "          |
-  restart     |                 |                 |
-     ^        |   map -<3digit>- to non A/N char  |
-     |        |                 |                 |
-     |        \-------->   add a "."   <----------/
-     |                         |
-     \------------- take next attribute (if any)
-
-
-
-
-Allocchio                   Standards Track                    [Page 13]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   Note that the above flow charts deal with the translation of the
-   attributes syntax, only.
-
-4.2.3 The Country Code convention in the <name> value.
-
-   The RFC822 domain space and the X.400 O/R address space, as said in
-   section 3, have one specific common feature: the X.400 ISO country
-   codes are the same as the RFC822 ISO top level domains for countries.
-   In the previous sections we have also defined a method to write in
-   <domain-name> syntax any X.400 domain, while in section 3 we
-   described the new name space starting at each country top level
-   domain under the X42D.cc (where 'cc' is then two letter ISO country
-   code).
-
-   The <name> value for a 'table1' or 'gate1' entry in DNS should thus
-   be derived from the X.400 domain value, translated to <domain-name>
-   syntax, adding the 'X42D.cc.' post-fix to it, i.e.,
-
-     ADMD$acme.C$fr
-
-   produces in <domain-name> syntax the key:
-
-     ADMD-acme.C-fr
-
-   which is post-fixed by 'X42D.fr.' resulting in:
-
-     ADMD-acme.C-fr.X42D.fr.
-
-   However, due to the identical encoding for X.400 country codes and
-   RFC822 country top level domains, the string 'C-fr.X42D.fr.' is
-   clearly redundant.
-
-   We thus define the 'Country Code convention' for the <name> key,
-   i.e.,
-
-     "The C-cc section of an X.400 domain in <domain-name> syntax must
-     be omitted when creating a <name> key, as it is identical to the
-     top level country code used to identify the DNS zone where the
-     information is stored".
-
-   Thus we obtain the following <name> key examples:
-
-   X.400 domain                       DNS <name> key
-   --------------------------------------------------------------------
-   ADMD$acme.C$fr                     ADMD-acme.X42D.fr.
-   PRMD$ux\.av.ADMD$ .C$gb            PRMD-ux-d-av.ADMDb.X42D.gb.
-   PRMD$ppb.ADMD$Dat 400.C$de         PRMD-ppb.ADMD-Dat-b-400.X42D.de.
-
-
-
-
-Allocchio                   Standards Track                    [Page 14]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-4.3 Creating the appropriate DNS files
-
-   Using MIXER's assumption of an asymmetric mapping between X.400 and
-   RFC822 addresses, two separate relations are required to store the
-   mapping database: MIXER 'table1' and MIXER 'table2'; thus also in DNS
-   we will maintain the two different sections, even if they will both
-   use the PX resource record. More over MIXER also specify two
-   additional tables: MIXER 'gate1' and 'gate2' tables. These additional
-   tables, however, have the same syntax rules than MIXER 'table1' and
-   'table2' respectively, and thus the same translation procedure as
-   'table1' and 'table2' will be applied; some details about the MIXER
-   'gate1' and 'gate2' tables are discussed in section 4.4.
-
-   Let's now check how to create, from an MCGAM entry, the appropriate
-   DNS entry in a DNS data file. We can again define an MCGAM entry as
-   defined in appendix F of that document as:
-
-     <x400-domain>#<rfc822-domain>#  (case A: 'table1' and 'gate1'
-     entry)
-
-   and
-
-     <rfc822-domain>#<x400-domain>#  (case B: 'table2' and 'gate2'
-     entry)
-
-   The two cases must be considered separately. Let's consider case A.
-
-    - take <x400-domain> and translate it into <domain-name> syntax,
-     obtaining <x400-in-domain-syntax>;
-    - create the <name> key from <x400-in-domain-syntax> i.e., apply
-     the Country Code convention described in sect. 4.2.3;
-    - construct the DNS PX record as:
-
-      *.<name>  IN  PX  50  <rfc822-domain>  <x400-in-domain-syntax>
-
-   Please note that within PX RDATA the <rfc822-domain> precedes the
-   <x400-in-domain-syntax> also for a 'table1' and 'gate1' entry.
-
-   an example: from the 'table1' rule
-
-     PRMD$ab.ADMD$ac.C$fr#ab.fr#
-
-   we obtain
-
-     *.PRMD-ab.ADMD-ac.X42D.fr. IN PX 50  ab.fr.  PRMD-ab.ADMD-ac.C-fr.
-
-   Note that <name>, <rfc822-domain> and <x400-in-domain-syntax> are
-   fully qualified <domain-name> elements, thus ending with a ".".
-
-
-
-Allocchio                   Standards Track                    [Page 15]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   Let's now consider case B.
-
-    - take <rfc822-domain> as <name> key;
-    - translate <x400-domain> into <x400-in-domain-syntax>;
-    - construct the DNS PX record as:
-
-     *.<name>  IN  PX  50  <rfc822-domain>  <x400-in-domain-syntax>
-
-   an example: from the 'table2' rule
-
-     ab.fr#PRMD$ab.ADMD$ac.C$fr#
-
-   we obtain
-
-     *.ab.fr.  IN  PX  50  ab.fr.  PRMD-ab.ADMD-ac.C-fr.
-
-   Again note the fully qualified <domain-name> elements.
-
-   A file containing the MIXER mapping rules and MIXER 'gate1' and
-   'gate2' table written in DNS format will look like the following
-   fictious example:
-
-     !
-     ! MIXER table 1: X.400 --> RFC822
-     !
-     *.ADMD-acme.X42D.it.               IN  PX  50  it. ADMD-acme.C-it.
-     *.PRMD-accred.ADMD-tx400.X42D.it.  IN  PX  50   \
-                                accred.it. PRMD-accred.ADMD-tx400.C-it.
-     *.O-u-h-newcity.PRMD-x4net.ADMDb.X42D.it.  IN  PX  50   \
-                       cs.ncty.it. O-u-h-newcity.PRMD-x4net.ADMDb.C-it.
-     !
-     ! MIXER table 2: RFC822 --> X.400
-     !
-     *.nrc.it.    IN  PX  50   nrc.it. PRMD-nrc.ADMD-acme.C-it.
-     *.ninp.it.   IN  PX  50   ninp.it. O.PRMD-ninp.ADMD-acme.C-it.
-     *.bd.it.     IN  PX  50   bd.it. PRMD-uk-d-bd.ADMDb.C-it.
-     !
-     ! MIXER Gate 1 Table
-     !
-     *.ADMD-XKW-h-Mail.X42D.it.         IN  PX  50   \
-                            XKW-gateway.it. ADMD-XKW-h-Mail.C-it.G.
-     *.PRMD-Super-b-Inc.ADMDb.X42D.it.  IN  PX  50   \
-                            GlobalGw.it. PRMD-Super-b-Inc.ADMDb.C-it.G.
-     !
-     ! MIXER Gate 2 Table
-     !
-     my.it.  IN PX 50  my.it. OU-int-h-gw.O.PRMD-ninp.ADMD-acme.C-it.G.
-     co.it.  IN PX 50  co.it. O-mhs-h-relay.PRMD-x4net.ADMDb.C-it.G.
-
-
-
-Allocchio                   Standards Track                    [Page 16]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   (here the "\" indicates continuation on the same line, as wrapping is
-   done only due to typographical reasons).
-
-   Note the special suffix ".G." on the right side of the 'gate1' and
-   'gate2' Tables section whose aim is described in section 4.4. The
-   corresponding MIXER tables are:
-
-     #
-     # MIXER table 1: X.400 --> RFC822
-     #
-     ADMD$acme.C$it#it#
-     PRMD$accred.ADMD$tx400.C$it#accred.it#
-     O$u-newcity.PRMD$x4net.ADMD$ .C$it#cs.ncty.it#
-     #
-     # MIXER table 2: RFC822 --> X.400
-     #
-     nrc.it#PRMD$nrc.ADMD$acme.C$it#
-     ninp.it#O.PRMD$ninp.ADMD$acme.C$it#
-     bd.it#PRMD$uk\.bd.ADMD$ .C$it#
-     #
-     # MIXER Gate 1 Table
-     #
-     ADMD$XKW-Mail.C$it#XKW-gateway.it#
-     PRMD$Super Inc.ADMD$ .C$it#GlobalGw.it#
-     #
-     # MIXER Gate 2 Table
-     #
-     my.it#OU$int-gw.O$@.PRMD$ninp.ADMD$acme.C$it#
-     co.it#O$mhs-relay.PRMD$x4net.ADMD$ .C$t#
-
-4.4 Storing the MIXER 'gate1' and 'gate2' tables
-
-   Section 4.3.4 of MIXER also specify how an address should be
-   converted between RFC822 and X.400 in case a complete mapping is
-   impossible. To allow the use of DDAs for non mappable domains, the
-   MIXER 'gate2' table is thus introduced.
-
-   In a totally similar way, when an X.400 address cannot be completely
-   converted in RFC822, section 4.3.5 of MIXER specifies how to encode
-   (LHS encoding) the address itself, pointing then to the appropriate
-   MIXER conformant gateway, indicated in the MIXER 'gate1' table.
-
-   DNS must store and distribute also these 'gate1' and 'gate2' data.
-
-   One of the major features of the DNS is the ability to distribute the
-   authority: a certain site runs the "primary" nameserver for one
-   determined sub-tree and thus it is also the only place allowed to
-   update information regarding that sub-tree. This fact allows, in our
-
-
-
-Allocchio                   Standards Track                    [Page 17]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   case, a further additional feature to the table based approach. In
-   fact we can avoid one possible ambiguity about the use of the 'gate1'
-   and 'gate2' tables (and thus of LHS and DDAs encoding).
-
-   The authority maintaining a DNS entry in the usual RFC822 domain
-   space is the only one allowed to decide if its domain should be
-   mapped using Standard Attributes (SA) syntax or Domain Defined
-   Attributes (DDA) one. If the authority decides that its RFC822 domain
-   should be mapped using SA, then the PX RDATA will be a 'table2'
-   entry, otherwise it will be a 'gate2' table entry. Thus for an RFC822
-   domain we cannot have any more two possible entries, one from 'table2
-   and another one from 'gate2' table, and the action for a gateway
-   results clearly stated.
-
-   Similarly, the authority mantaining a DNS entry in the new X.400 name
-   space is the only one allowed to decide if its X.400 domain should be
-   mapped using SA syntax or Left Hand Side (LHS) encoding. If the
-   authority decides that its X.400 domain should be mapped using SA,
-   then the PX RDATA will be a 'table1' entry, otherwise it will be a
-   'gate1' table entry. Thus also for an X.400 domain we cannot have any
-   more two possible entries, one from 'table1' and another one from
-   'gate1' table, and the action for a gateway results clearly stated.
-
-   The MIXER 'gate1' table syntax is actually identical to MIXER
-   'table1', and 'gate2' table syntax is identical to MIXER 'table2'.
-   Thus the same syntax translation rules from MIXER to DNS format can
-   be applied in both cases. However a gateway or any other application
-   must know if the answer it got from DNS contains some 'table1',
-   'table2' or some 'gate1', 'gate2' table information. This is easily
-   obtained flagging with an additional ".G." post-fix the PX RDATA
-   value when it contains a 'gate1' or 'gate2' table entry. The example
-   in section 4.3 shows clearly the result. As any X.400 O/R domain must
-   end with a country code ("C-xx" in our DNS syntax) the additional
-   ".G." creates no conflicts or ambiguities at all. This postfix must
-   obviously be removed before using the MIXER 'gate1' or 'gate2' table
-   data.
-
-5. Finding MIXER mapping information from DNS
-
-   The MIXER mapping information is stored in DNS both in the normal
-   RFC822 domain name space, and in the newly defined X.400 name space.
-   The information, stored in PX resource records, does not represent a
-   full RFC822 or X.400 O/R address: it is a template which specifies
-   the fields of the domain that are used by the mapping algorithm.
-
-   When mapping information is stored in the DNS, queries to the DNS are
-   issued whenever an iterative search through the mapping table would
-   be performed (MIXER: section 4.3.4, State I; section 4.3.5, mapping
-
-
-
-Allocchio                   Standards Track                    [Page 18]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   B). Due to the DNS search mechanism, DNS by itself returns the
-   longest possible match in the stored mapping rule with a single
-   query, thus no iteration and/or multiple queries are needed. As
-   specified in MIXER, a search of the mapping table will result in
-   either success (mapping found) or failure (query failed, mapping not
-   found).
-
-   When a DNS query is issued, a third possible result is timeout. If
-   the result is timeout, the gateway operation is delayed and then
-   retried at a later time. A result of success or failure is processed
-   according to the algorithms specified in MIXER. If a DNS error code
-   is returned, an error message should be logged and the gateway
-   operation is delayed as for timeout. These pathological situations,
-   however, should be avoided with a careful duplication and chaching
-   mechanism which DNS itself provides.
-
-   Searching the nameserver which can authoritatively solve the query is
-   automatically performed by the DNS distributed name service.
-
-5.1 A DNS query example
-
-   An MIXER mail-gateway located in the Internet, when translating
-   addresses from RFC822 to X.400, can get information about the MCGAM
-   rule asking the DNS. As an example, when translating the address
-   SUN.CCE.NRC.IT, the gateway will just query DNS for the associated PX
-   resource record. The DNS should contain a PX record like this:
-
-   *.cce.nrc.it.  IN PX 50   cce.nrc.it.  O-cce.PRMD-nrc.ADMD-acme.C-it.
-
-   The first query will return immediately the appropriate mapping rule
-   in DNS store format.
-
-   There is no ".G." at the end of the obtained PX RDATA value, thus
-   applying the syntax translation specified in paragraph 4.2 the MIXER
-   Table 2 mapping rule will be obtained.
-
-   Let's now take another example where a 'gate2' table rule is
-   returned.  If we are looking for an RFC822 domain ending with top
-   level domain "MW", and the DNS contains a PX record like this,
-
-      *.mw.   IN  PX  50  mw.  O-cce.PRMD-nrc.ADMD-acme.C-it.G.
-
-   DNS will return 'mw.' and 'O-cce.PRMD-nrc.ADMD-acme.C-it.G.', i.e., a
-   'gate2' table entry in DNS store format. Dropping the final ".G." and
-   applying the syntax translation specified in paragraph 4.2 the
-   original rule will be available. More over, the ".G." flag also tells
-   the gateway to use DDA encoding for the inquired RFC822 domain.
-
-
-
-
-Allocchio                   Standards Track                    [Page 19]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   On the other hand, translating from X.400 to RFC822 the address
-
-      C=de; ADMD=pkz; PRMD=nfc; O=top;
-
-   the mail gateway should convert the syntax according to paragraph
-   4.2, apply the 'Country code convention' described in 4.2.3 to derive
-   the appropriate DNS translation of the X.400 O/R name and then query
-   DNS for the corresponding PX resource record. The obtained record for
-   which the PX record must be queried is thus:
-
-      O-top.PRMD-nfc.ADMD-pkz.X42D.de.
-
-   The DNS could contain:
-
-      *.ADMD-pkz.X42D.de.  IN  PX  50  pkz.de.  ADMD-pkz.C-de.
-
-   Assuming that there are not more specific records in DNS, the
-   wildcard mechanism will return the MIXER 'table1' rule in encoded
-   format.
-
-   Finally, an example where a 'gate1' rule is involved. If we are
-   looking for an X.400 domain ending with ADMD=PWT400; C=US; , and the
-   DNS contains a PX record like this,
-
-      *.ADMD-PWT400.X42D.us.  IN  PX  50  intGw.com. ADMD-PWT400.C-us.G.
-
-   DNS will return 'intGw.com.' and 'ADMD-PWT400.C-us.G.', i.e., a
-   'gate1' table entry in DNS store format. Dropping the final ".G." and
-   applying the syntax translation specified in paragraph 4.2 the
-   original rule will be available. More over, the ".G." flag also tells
-   the gateway to use LHS encoding for the inquired X.400 domain.
-
-6. Administration of mapping information
-
-   The DNS, using the PX RR, is able to distribute the MCGAM rules to
-   all MIXER gateways located on the Internet. However, not all MIXER
-   gateways will be able to use the Internet DNS. It is expected that
-   some gateways in a particular management domain will conform to one
-   of the following models:
-
-     (a) Table-based, (b) DNS-based, (c) X.500-based
-
-   Table-based management domains will continue to publish their MCGAM
-   rules and retrieve the mapping tables via the International Mapping
-   Table coordinator, manually or via some automated procedures. Their
-   MCGAM information can be made available also in DNS by the
-   appropriate DNS authorities, using the same mechanism already in
-   place for MX records: if a branch has not yet in place its own DNS
-
-
-
-Allocchio                   Standards Track                    [Page 20]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   server, some higher authority in the DNS tree will provide the
-   service for it. A transition procedure similar to the one used to
-   migrate from the 'hosts.txt' tables to DNS can be applied also to the
-   deployment phase of this specification. An informational document
-   describing the implementation phase and the detailed coordination
-   procedures is expected.
-
-   Another distributed directory service which can distribute the MCGAM
-   information is X.500. Coordination with table-based domains can be
-   obtained in an identical way as for the DNS case.
-
-   Coordination of MCGAM information between DNS and X.500 is more
-   complex, as it requies some kind of uploading information between the
-   two systems. The ideal solution is a dynamic alignment mechanism
-   which transparently makes the DNS mapping information available in
-   X.500 and vice versa. Some work in this specific field is already
-   being done [see Costa] which can result in a global transparent
-   directory service, where the information is stored in DNS or in
-   X.500, but is visible completely by any of the two systems.
-
-   However we must remind that MIXER concept of MCGAM rules publication
-   is different from the old RFC1327 concept of globally distributed,
-   coordinated and unique mapping rules. In fact MIXER does not requires
-   any more for any conformant gateway or tool to know the complete set
-   of MCGAM: it only requires to use some set (eventually empty) of
-   valid MCGAM rules, published either by Tables, DNS or X.500
-   mechanisms or any combination of these methods. More over MIXER
-   specifies that also incomplete sets of MCGAM can be used, and
-   supplementary local unpublished (but valid) MCGAM can also be used.
-   As a consequence, the problem of coordination between the three
-   systems proposed by MIXER for MCGAM publication is non essential, and
-   important only for efficient operational matters. It does not in fact
-   affect the correct behaviour of MIXER conformant gateways and tools.
-
-7. Conclusion
-
-   The introduction of the new PX resource record and the definition of
-   the X.400 O/R name space in the DNS structure provide a good
-   repository for MCGAM information. The mapping information is stored
-   in the DNS tree structure so that it can be easily obtained using the
-   DNS distributed name service. At the same time the definition of the
-   appropriate DNS space for X.400 O/R names provide a repository where
-   to store and distribute some other X.400 MHS information. The use of
-   the DNS has many known advantages in storing, managing and updating
-   the information. A successful number of tests were been performed
-   under the provisional top level domain "X400.IT" when RFC1664 was
-   developed, and their results confirmed the advantages of the method.
-   Operational exeprience for over 2 years with RFC1664 specification
-
-
-
-Allocchio                   Standards Track                    [Page 21]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   confirmed the feasibility of the method, and helped identifying some
-   operational procedures to deploy the insertion of MCGAM into DNS.
-
-   Software to query the DNS and then to convert between the textual
-   representation of DNS resource records and the address format defined
-   in MIXER was developed with RFC1664. This software also allows a
-   smooth implementation and deployment period, eventually taking care
-   of the transition phase. This software can be easily used (with
-   little or null modification) also for this updated specification,
-   supporting the new 'gate1' MIXER table. DNS software implementations
-   supporting RFC1664 also supports with no modification this memo new
-   specification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Allocchio                   Standards Track                    [Page 22]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   A further informational document describing operational and
-   implementation of the service is expected.
-
-8. Acknowledgements
-
-   We wish to thanks all those who contributed to the discussion and
-   revision of this document: many of their ideas and suggestions
-   constitute essential parts of this work. In particular thanks to Jon
-   Postel, Paul Mockapetris, Rob Austin and the whole IETF x400ops,
-   TERENA wg-msg and IETF namedroppers groups. A special mention to
-   Christian Huitema for his fundamental contribution to this work.
-
-   This document is a revision of RFC1664, edited by one of its authors
-   on behalf of the IETF MIXER working group. The current editor wishes
-   to thank here also the authors of RFC1664:
-
-     Antonio Blasco Bonito     RFC822: bonito@cnuce.cnr.it
-     CNUCE - CNR               X.400:  C=it;A=garr;P=cnr;
-     Reparto infr. reti                O=cnuce;S=bonito;
-     Viale S. Maria 36
-     I 56126 Pisa
-     Italy
-
-
-     Bruce Cole                RFC822: bcole@cisco.com
-     Cisco Systems Inc.        X.400:  C=us;A= ;P=Internet;
-     P.O. Box 3075                     DD.rfc-822=bcole(a)cisco.com;
-     1525 O'Brien Drive
-     Menlo Park, CA 94026
-     U.S.A.
-
-
-     Silvia Giordano           RFC822: giordano@cscs.ch
-     Centro Svizzero di        X.400:  C=ch;A=arcom;P=switch;O=cscs;
-     Calcolo Scientifico               S=giordano;
-     Via Cantonale
-     CH 6928 Manno
-     Switzerland
-
-
-     Robert Hagens                   RFC822: hagens@ans.net
-     Advanced Network and Services   X.400:  C=us;A= ;P=Internet;
-     1875 Campus Commons Drive               DD.rfc-822=hagens(a)ans.net;
-     Reston, VA 22091
-     U.S.A.
-
-
-
-
-
-
-Allocchio                   Standards Track                    [Page 23]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-9. References
-
-   [CCITT] CCITT SG 5/VII, "Recommendation X.400, Message Handling
-       Systems: System Model - Service Elements", October 1988.
-
-   [RFC 1327] Kille, S., "Mapping between X.400(1988)/ISO 10021 and RFC
-       822", RFC 1327, March 1992.
-
-   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
-       STD 13, RFC 1034, USC/Information Sciences Institute, November
-       1987.
-
-   [RFC 1035] Mockapetris, P., "Domain names - Implementation and
-       Specification", STD 13, RFC 1035, USC/Information Sciences
-       Institute, November 1987.
-
-   [RFC 1033] Lottor, M., "Domain Administrators Operation Guide", RFC
-       1033, SRI International, November 1987.
-
-   [RFC 2156] Kille, S. E., " MIXER (Mime Internet X.400 Enhanced
-       Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156,
-       January 1998.
-
-   [Costa] Costa, A., Macedo, J., and V. Freitas, "Accessing and
-       Managing DNS Information in the X.500 Directory", Proceeding of
-       the 4th Joint European Networking Conference, Trondheim, NO, May
-       1993.
-
-10. Security Considerations
-
-   This document specifies a means by which DNS "PX" records can direct
-   the translation between X.400 and Internet mail addresses.
-
-   This can indirectly affect the routing of mail across an gateway
-   between X.400 and Internet Mail.  A succesful attack on this service
-   could cause incorrect translation of an originator address (thus
-   "forging" the originator address), or incorrect translation of a
-   recipient address (thus directing the mail to an unauthorized
-   recipient, or making it appear to an authorized recipient, that the
-   message was intended for recipients other than those chosen by the
-   originator) or could force the mail path via some particular gateway
-   or message transfer agent where mail security can be affected by
-   compromised software.
-
-
-
-
-
-
-
-
-Allocchio                   Standards Track                    [Page 24]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-   There are several means by which an attacker might be able to deliver
-   incorrect PX records to a client.  These include: (a) compromise of a
-   DNS server,  (b) generating a counterfeit response to a client's DNS
-   query, (c) returning incorrect "additional information" in response
-   to an unrelated query.
-
-   Clients using PX records SHOULD ensure that routing and address
-   translations are based only on authoritative answers.  Once DNS
-   Security mechanisms [RFC 2065] become more widely deployed, clients
-   SHOULD employ those mechanisms to verify the authenticity and
-   integrity of PX records.
-
-11. Author's Address
-
-   Claudio Allocchio
-   Sincrotrone Trieste
-   SS 14 Km 163.5 Basovizza
-   I 34012 Trieste
-   Italy
-
-   RFC822: Claudio.Allocchio@elettra.trieste.it
-   X.400:  C=it;A=garr;P=Trieste;O=Elettra;
-   S=Allocchio;G=Claudio;
-   Phone:  +39 40 3758523
-   Fax:    +39 40 3758565
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Allocchio                   Standards Track                    [Page 25]
-
-RFC 2163                      MIXER MCGAM                   January 1998
-
-
-12.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (1998).  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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Allocchio                   Standards Track                    [Page 26]
-
diff --git a/contrib/bind9/doc/rfc/rfc2168.txt b/contrib/bind9/doc/rfc/rfc2168.txt
deleted file mode 100644
index 3eed1bd..0000000
--- a/contrib/bind9/doc/rfc/rfc2168.txt
+++ /dev/null
@@ -1,1123 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       R. Daniel
-Request for Comments: 2168             Los Alamos National Laboratory
-Category: Experimental                                    M. Mealling
-                                              Network Solutions, Inc.
-                                                            June 1997
-
-
-               Resolution of Uniform Resource Identifiers
-                      using the Domain Name System
-
-Status of this Memo
-===================
-
-   This memo defines an Experimental Protocol for the Internet
-   community.  This memo does not specify an Internet standard of any
-   kind.  Discussion and suggestions for improvement are requested.
-   Distribution of this memo is unlimited.
-
-Abstract:
-=========
-
-   Uniform Resource Locators (URLs) are the foundation of the World Wide
-   Web, and are a vital Internet technology. However, they have proven
-   to be brittle in practice. The basic problem is that URLs typically
-   identify a particular path to a file on a particular host. There is
-   no graceful way of changing the path or host once the URL has been
-   assigned. Neither is there a graceful way of replicating the resource
-   located by the URL to achieve better network utilization and/or fault
-   tolerance. Uniform Resource Names (URNs) have been hypothesized as a
-   adjunct to URLs that would overcome such problems. URNs and URLs are
-   both instances of a broader class of identifiers known as Uniform
-   Resource Identifiers (URIs).
-
-   The requirements document for URN resolution systems[15] defines the
-   concept of a "resolver discovery service". This document describes
-   the first, experimental, RDS. It is implemented by a new DNS Resource
-   Record, NAPTR (Naming Authority PoinTeR), that provides rules for
-   mapping parts of URIs to domain names.  By changing the mapping
-   rules, we can change the host that is contacted to resolve a URI.
-   This will allow a more graceful handling of URLs over long time
-   periods, and forms the foundation for a new proposal for Uniform
-   Resource Names.
-
-
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                      [Page 1]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   In addition to locating resolvers, the NAPTR provides for other
-   naming systems to be grandfathered into the URN world, provides
-   independence between the name assignment system and the resolution
-   protocol system, and allows multiple services (Name to Location, Name
-   to Description, Name to Resource, ...) to be offered.  In conjunction
-   with the SRV RR, the NAPTR record allows those services to be
-   replicated for the purposes of fault tolerance and load balancing.
-
-Introduction:
-=============
-
-   Uniform Resource Locators have been a significant advance in
-   retrieving Internet-accessible resources. However, their  brittle
-   nature over time has been recognized for several years. The Uniform
-   Resource Identifier working group proposed the development of Uniform
-   Resource Names to serve as persistent, location-independent
-   identifiers for Internet resources in order to overcome most of the
-   problems with URLs. RFC-1737 [1] sets forth requirements on URNs.
-
-   During the lifetime of the URI-WG, a number of URN proposals were
-   generated. The developers of several of those proposals met in a
-   series of meetings, resulting in a compromise known as the Knoxville
-   framework.  The major principle behind the Knoxville framework is
-   that the resolution system must be separate from the way names are
-   assigned. This is in marked contrast to most URLs, which identify the
-   host to contact and the protocol to use. Readers are referred to [2]
-   for background on the Knoxville framework and for additional
-   information on the context and purpose of this proposal.
-
-   Separating the way names are resolved from the way they are
-   constructed provides several benefits. It allows multiple naming
-   approaches and resolution approaches to compete, as it allows
-   different protocols and resolvers to be used. There is just one
-   problem with such a separation - how do we resolve a name when it
-   can't give us directions to its resolver?
-
-   For the short term, DNS is the obvious candidate for the resolution
-   framework, since it is widely deployed and understood. However, it is
-   not appropriate to use DNS to maintain information on a per-resource
-   basis. First of all, DNS was never intended to handle that many
-   records. Second, the limited record size is inappropriate for catalog
-   information. Third, domain names are not appropriate as URNs.
-
-   Therefore our approach is to use DNS to locate "resolvers" that can
-   provide information on individual resources, potentially including
-   the resource itself. To accomplish this, we "rewrite" the URI into a
-   domain name following the rules provided in NAPTR records. Rewrite
-   rules provide considerable power, which is important when trying to
-
-
-
-Daniel & Mealling             Experimental                      [Page 2]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   meet the goals listed above. However, collections of rules can become
-   difficult to understand. To lessen this problem, the NAPTR rules are
-   *always* applied to the original URI, *never* to the output of
-   previous rules.
-
-   Locating a resolver through the rewrite procedure may take multiple
-   steps, but the beginning is always the same. The start of the URI is
-   scanned to extract its colon-delimited prefix. (For URNs, the prefix
-   is always "urn:" and we extract the following colon-delimited
-   namespace identifier [3]). NAPTR resolution begins by taking the
-   extracted string, appending the well-known suffix ".urn.net", and
-   querying the DNS for NAPTR records at that domain name.  Based on the
-   results of this query, zero or more additional DNS queries may be
-   needed to locate resolvers for the URI. The details of the
-   conversation between the client and the resolver thus located are
-   outside the bounds of this draft. Three brief examples of this
-   procedure are given in the next section.
-
-   The NAPTR RR provides the level of indirection needed to keep the
-   naming system independent of the resolution system, its protocols,
-   and services.  Coupled with the new SRV resource record proposal[4]
-   there is also the potential for replicating the resolver on multiple
-   hosts, overcoming some of the most significant problems of URLs. This
-   is an important and subtle point. Not only do the NAPTR and SRV
-   records allow us to replicate the resource, we can replicate the
-   resolvers that know about the replicated resource. Preventing a
-   single point of failure at the resolver level is a significant
-   benefit. Separating the resolution procedure from the way names are
-   constructed has additional benefits.  Different resolution procedures
-   can be used over time, and resolution procedures that are determined
-   to be useful can be extended to deal with additional namespaces.
-
-Caveats
-=======
-
-   The NAPTR proposal is the first resolution procedure to be considered
-   by the URN-WG. There are several concerns about the proposal which
-   have motivated the group to recommend it for publication as an
-   Experimental rather than a standards-track RFC.
-
-   First, URN resolution is new to the IETF and we wish to gain
-   operational experience before recommending any procedure for the
-   standards track. Second, the NAPTR proposal is based on DNS and
-   consequently inherits concerns about security and administration. The
-   recent advancement of the DNSSEC and secure update drafts to Proposed
-   Standard reduce these concerns, but we wish to experiment with those
-   new capabilities in the context of URN administration.  A third area
-   of concern is the potential for a noticeable impact on the DNS.  We
-
-
-
-Daniel & Mealling             Experimental                      [Page 3]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   believe that the proposal makes appropriate use of caching and
-   additional information, but it is best to go slow where the potential
-   for impact on a core system like the DNS is concerned. Fourth, the
-   rewrite rules in the NAPTR proposal are based on regular expressions.
-   Since regular expressions are difficult for humans to construct
-   correctly, concerns exist about the usability and maintainability of
-   the rules. This is especially true where international character sets
-   are concerned. Finally, the URN-WG is developing a requirements
-   document for URN Resolution Services[15], but that document is not
-   complete. That document needs to precede any resolution service
-   proposals on the standards track.
-
-Terminology
-===========
-
-   "Must" or "Shall" - Software that does not behave in the manner that
-              this document says it must is not conformant to this
-              document.
-   "Should" - Software that does not follow the behavior that this
-              document says it should may still be conformant, but is
-              probably broken in some fundamental way.
-   "May" -    Implementations may or may not provide the described
-              behavior, while still remaining conformant to this
-              document.
-
-Brief overview and examples of the NAPTR RR:
-============================================
-
-   A detailed description of the NAPTR RR will be given later, but to
-   give a flavor for the proposal we first give a simple description of
-   the record and three examples of its use.
-
-   The key fields in the NAPTR RR are order, preference, service, flags,
-   regexp, and replacement:
-
-   * The order field specifies the order in which records MUST be
-     processed when multiple NAPTR records are returned in response to a
-     single query.  A naming authority may have delegated a portion of
-     its namespace to another agency. Evaluating the NAPTR records in
-     the correct order is necessary for delegation to work properly.
-
-   * The preference field specifies the order in which records SHOULD be
-     processed when multiple NAPTR records have the same value of
-     "order".  This field lets a service provider specify the order in
-     which resolvers are contacted, so that more capable machines are
-     contacted in preference to less capable ones.
-
-
-
-
-
-Daniel & Mealling             Experimental                      [Page 4]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   * The service field specifies the resolution protocol and resolution
-     service(s) that will be available if the rewrite specified by the
-     regexp or replacement fields is applied. Resolution protocols are
-     the protocols used to talk with a resolver. They will be specified
-     in other documents, such as [5]. Resolution services are operations
-     such as N2R (URN to Resource), N2L (URN to URL), N2C (URN to URC),
-     etc.  These will be discussed in the URN Resolution Services
-     document[6], and their behavior in a particular resolution protocol
-     will be given in the specification for that protocol (see [5] for a
-     concrete example).
-
-   * The flags field contains modifiers that affect what happens in the
-     next DNS lookup, typically for optimizing the process. Flags may
-     also affect the interpretation of the other fields in the record,
-     therefore, clients MUST skip NAPTR records which contain an unknown
-     flag value.
-
-   * The regexp field is one of two fields used for the rewrite rules,
-     and is the core concept of the NAPTR record. The regexp field is a
-     String containing a sed-like substitution expression. (The actual
-     grammar for the substitution expressions is given later in this
-     draft). The substitution expression is applied to the original URN
-     to determine the next domain name to be queried. The regexp field
-     should be used when the domain name to be generated is conditional
-     on information in the URI. If the next domain name is always known,
-     which is anticipated to be a common occurrence, the replacement
-     field should be used instead.
-
-   * The replacement field is the other field that may be used for the
-     rewrite rule. It is an optimization of the rewrite process for the
-     case where the next domain name is fixed instead of being
-     conditional on the content of the URI. The replacement field is a
-     domain name (subject to compression if a DNS sender knows that a
-     given recipient is able to decompress names in this RR type's RDATA
-     field). If the rewrite is more complex than a simple substitution
-     of a domain name, the replacement field should be set to . and the
-     regexp field used.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                      [Page 5]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   Note that the client applies all the substitutions and performs all
-   lookups, they are not performed in the DNS servers. Note also that it
-   is the belief of the developers of this document that regexps should
-   rarely be used. The replacement field seems adequate for the vast
-   majority of situations. Regexps are only necessary when portions of a
-   namespace are to be delegated to different resolvers. Finally, note
-   that the regexp and replacement fields are, at present, mutually
-   exclusive. However, developers of client software should be aware
-   that a new flag might be defined which requires values in both
-   fields.
-
-Example 1
----------
-
-   Consider a URN that uses the hypothetical DUNS namespace. DUNS
-   numbers are identifiers for approximately 30 million registered
-   businesses around the world, assigned and maintained by Dunn and
-   Bradstreet. The URN might look like:
-
-                   urn:duns:002372413:annual-report-1997
-
-   The first step in the resolution process is to find out about the
-   DUNS namespace. The namespace identifier, "duns", is extracted from
-   the URN, prepended to urn.net, and the NAPTRs for duns.urn.net looked
-   up. It might return records of the form:
-
-duns.urn.net
-;;      order pref flags service          regexp        replacement
- IN NAPTR 100  10  "s" "dunslink+N2L+N2C" ""  dunslink.udp.isi.dandb.com
- IN NAPTR 100  20  "s" "rcds+N2C"         ""  rcds.udp.isi.dandb.com
- IN NAPTR 100  30  "s" "http+N2L+N2C+N2R" ""  http.tcp.isi.dandb.com
-
-   The order field contains equal values, indicating that no name
-   delegation order has to be followed. The preference field indicates
-   that the provider would like clients to use the special dunslink
-   protocol, followed by the RCDS protocol, and that HTTP is offered as
-   a last resort. All the records specify the "s" flag, which will be
-   explained momentarily.  The service fields say that if we speak
-   dunslink, we will be able to issue either the N2L or N2C requests to
-   obtain a URL or a URC (description) of the resource. The Resource
-   Cataloging and Distribution Service (RCDS)[7] could be used to get a
-   URC for the resource, while HTTP could be used to get a URL, URC, or
-   the resource itself.  All the records supply the next domain name to
-   query, none of them need to be rewritten with the aid of regular
-   expressions.
-
-
-
-
-
-
-Daniel & Mealling             Experimental                      [Page 6]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   The general case might require multiple NAPTR rewrites to locate a
-   resolver, but eventually we will come to the "terminal NAPTR". Once
-   we have the terminal NAPTR, our next probe into the DNS will be for a
-   SRV or A record instead of another NAPTR. Rather than probing for a
-   non-existent NAPTR record to terminate the loop, the flags field is
-   used to indicate a terminal lookup. If it has a value of "s", the
-   next lookup should be for SRV RRs, "a" denotes that A records should
-   sought.  A "p" flag is also provided to indicate that the next action
-   is Protocol-specific, but that looking up another NAPTR will not be
-   part of it.
-
-   Since our example RR specified the "s" flag, it was terminal.
-   Assuming our client does not know the dunslink protocol, our next
-   action is to lookup SRV RRs for rcds.udp.isi.dandb.com, which will
-   tell us hosts that can provide the necessary resolution service. That
-   lookup might return:
-
-    ;;                          Pref Weight Port Target
-    rcds.udp.isi.dandb.com IN SRV 0    0    1000 defduns.isi.dandb.com
-                           IN SRV 0    0    1000 dbmirror.com.au
-                           IN SRV 0    0    1000 ukmirror.com.uk
-
-   telling us three hosts that could actually do the resolution, and
-   giving us the port we should use to talk to their RCDS server.  (The
-   reader is referred to the SRV proposal [4] for the interpretation of
-   the fields above).
-
-   There is opportunity for significant optimization here. We can return
-   the SRV records as additional information for terminal NAPTRs (and
-   the A records as additional information for those SRVs). While this
-   recursive provision of additional information is not explicitly
-   blessed in the DNS specifications, it is not forbidden, and BIND does
-   take advantage of it [8]. This is a significant optimization. In
-   conjunction with a long TTL for *.urn.net records, the average number
-   of probes to DNS for resolving DUNS URNs would approach one.
-   Therefore, DNS server implementors SHOULD provide additional
-   information with NAPTR responses. The additional information will be
-   either SRV or A records.  If SRV records are available, their A
-   records should be provided as recursive additional information.
-
-   Note that the example NAPTR records above are intended to represent
-   the reply the client will see. They are not quite identical to what
-   the domain administrator would put into the zone files. For one
-   thing, the administrator should supply the trailing '.' character on
-   any FQDNs.
-
-
-
-
-
-
-Daniel & Mealling             Experimental                      [Page 7]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-Example 2
----------
-
-   Consider a URN namespace based on MIME Content-Ids. The URN might
-   look like this:
-
-                 urn:cid:199606121851.1@mordred.gatech.edu
-
-   (Note that this example is chosen for pedagogical purposes, and does
-   not conform to the recently-approved CID URL scheme.)
-
-   The first step in the resolution process is to find out about the CID
-   namespace. The namespace identifier, cid, is extracted from the URN,
-   prepended to urn.net, and the NAPTR for cid.urn.net looked up. It
-   might return records of the form:
-
- cid.urn.net
-  ;;       order pref flags service        regexp           replacement
-   IN NAPTR 100   10   ""  ""  "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i"    .
-
-   We have only one NAPTR response, so ordering the responses is not a
-   problem.  The replacement field is empty, so we check the regexp
-   field and use the pattern provided there. We apply that regexp to the
-   entire URN to see if it matches, which it does.  The \2 part of the
-   substitution expression returns the string "gatech.edu". Since the
-   flags field does not contain "s" or "a", the lookup is not terminal
-   and our next probe to DNS is for more NAPTR records:
-   lookup(query=NAPTR, "gatech.edu").
-
-   Note that the rule does not extract the full domain name from the
-   CID, instead it assumes the CID comes from a host and extracts its
-   domain.  While all hosts, such as mordred, could have their very own
-   NAPTR, maintaining those records for all the machines at a site as
-   large as Georgia Tech would be an intolerable burden. Wildcards are
-   not appropriate here since they only return results when there is no
-   exactly matching names already in the system.
-
-   The record returned from the query on "gatech.edu" might look like:
-
-gatech.edu IN NAPTR
-;;       order pref flags service           regexp  replacement
-  IN NAPTR 100  50  "s"  "z3950+N2L+N2C"     ""    z3950.tcp.gatech.edu
-  IN NAPTR 100  50  "s"  "rcds+N2C"          ""    rcds.udp.gatech.edu
-  IN NAPTR 100  50  "s"  "http+N2L+N2C+N2R"  ""    http.tcp.gatech.edu
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                      [Page 8]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   Continuing with our example, we note that the values of the order and
-   preference fields are equal in all records, so the client is free to
-   pick any record. The flags field tells us that these are the last
-   NAPTR patterns we should see, and after the rewrite (a simple
-   replacement in this case) we should look up SRV records to get
-   information on the hosts that can provide the necessary service.
-
-   Assuming we prefer the Z39.50 protocol, our lookup might return:
-
-   ;;                        Pref Weight   Port Target
-   z3950.tcp.gatech.edu IN SRV 0    0      1000 z3950.gatech.edu
-                        IN SRV 0    0      1000 z3950.cc.gatech.edu
-                        IN SRV 0    0      1000 z3950.uga.edu
-
-   telling us three hosts that could actually do the resolution, and
-   giving us the port we should use to talk to their Z39.50 server.
-
-   Recall that the regular expression used \2 to extract a domain name
-   from the CID, and \. for matching the literal '.' characters
-   seperating the domain name components. Since '\' is the escape
-   character, literal occurances of a backslash must be escaped by
-   another backslash. For the case of the cid.urn.net record above, the
-   regular expression entered into the zone file should be
-   "/urn:cid:.+@([^\\.]+\\.)(.*)$/\\2/i".  When the client code actually
-   receives the record, the pattern will have been converted to
-   "/urn:cid:.+@([^.]+\.)(.*)$/\2/i".
-
-Example 3
----------
-
-   Even if URN systems were in place now, there would still be a
-   tremendous number of URLs.  It should be possible to develop a URN
-   resolution system that can also provide location independence for
-   those URLs.  This is related to the requirement in [1] to be able to
-   grandfather in names from other naming systems, such as ISO Formal
-   Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs,
-   etc.
-
-   The NAPTR RR could also be used for URLs that have already been
-   assigned.  Assume we have the URL for a very popular piece of
-   software that the publisher wishes to mirror at multiple sites around
-   the world:
-
-        http://www.foo.com/software/latest-beta.exe
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                      [Page 9]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   We extract the prefix, "http", and lookup NAPTR records for
-   http.urn.net. This might return a record of the form
-
-   http.urn.net IN NAPTR
-   ;;  order   pref flags service      regexp             replacement
-        100     90   ""      ""   "!http://([^/:]+)!\1!i"       .
-
-   This expression returns everything after the first double slash and
-   before the next slash or colon. (We use the '!' character to delimit
-   the parts of the substitution expression. Otherwise we would have to
-   use backslashes to escape the forward slashes, and would have a
-   regexp in the zone file that looked like
-   "/http:\\/\\/([^\\/:]+)/\\1/i".).
-
-   Applying this pattern to the URL extracts "www.foo.com". Looking up
-   NAPTR records for that might return:
-
-   www.foo.com
-   ;;       order pref flags   service  regexp     replacement
-    IN NAPTR 100  100  "s"   "http+L2R"   ""    http.tcp.foo.com
-    IN NAPTR 100  100  "s"   "ftp+L2R"    ""    ftp.tcp.foo.com
-
-   Looking up SRV records for http.tcp.foo.com would return information
-   on the hosts that foo.com has designated to be its mirror sites. The
-   client can then pick one for the user.
-
-NAPTR RR Format
-===============
-
-   The format of the NAPTR RR is given below. The DNS type code for
-   NAPTR is 35.
-
-       Domain TTL Class Order Preference Flags Service Regexp
-       Replacement
-
-   where:
-
-   Domain
-          The domain name this resource record refers to.
-   TTL
-          Standard DNS Time To Live field
-   Class
-          Standard DNS meaning
-
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                     [Page 10]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   Order
-          A 16-bit integer specifying the order in which the NAPTR
-          records MUST be processed to ensure correct delegation of
-          portions of the namespace over time. Low numbers are processed
-          before high numbers, and once a NAPTR is found that "matches"
-          a URN, the client MUST NOT consider any NAPTRs with a higher
-          value for order.
-
-   Preference
-          A 16-bit integer which specifies the order in which NAPTR
-          records with equal "order" values SHOULD be processed, low
-          numbers being processed before high numbers.  This is similar
-          to the preference field in an MX record, and is used so domain
-          administrators can direct clients towards more capable hosts
-          or lighter weight protocols.
-
-   Flags
-          A String giving flags to control aspects of the rewriting and
-          interpretation of the fields in the record. Flags are single
-          characters from the set [A-Z0-9]. The case of the alphabetic
-          characters is not significant.
-
-          At this time only three flags, "S", "A", and "P", are defined.
-          "S" means that the next lookup should be for SRV records
-          instead of NAPTR records. "A" means that the next lookup
-          should be for A records. The "P" flag says that the remainder
-          of the resolution shall be carried out in a Protocol-specific
-          fashion, and we should not do any more DNS queries.
-
-          The remaining alphabetic flags are reserved. The numeric flags
-          may be used for local experimentation. The S, A, and P flags
-          are all mutually exclusive, and resolution libraries MAY
-          signal an error if more than one is given. (Experimental code
-          and code for assisting in the creation of NAPTRs would be more
-          likely to signal such an error than a client such as a
-          browser). We anticipate that multiple flags will be allowed in
-          the future, so implementers MUST NOT assume that the flags
-          field can only contain 0 or 1 characters. Finally, if a client
-          encounters a record with an unknown flag, it MUST ignore it
-          and move to the next record. This test takes precedence even
-          over the "order" field. Since flags can control the
-          interpretation placed on fields, a novel flag might change the
-          interpretation of the regexp and/or replacement fields such
-          that it is impossible to determine if a record matched a URN.
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                     [Page 11]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   Service
-          Specifies the resolution service(s) available down this
-          rewrite path. It may also specify the particular protocol that
-          is used to talk with a resolver. A protocol MUST be specified
-          if the flags field states that the NAPTR is terminal. If a
-          protocol is specified, but the flags field does not state that
-          the NAPTR is terminal, the next lookup MUST be for a NAPTR.
-          The client MAY choose not to perform the next lookup if the
-          protocol is unknown, but that behavior MUST NOT be relied
-          upon.
-
-          The service field may take any of the values below (using the
-          Augmented BNF of RFC 822[9]):
-
-           service_field = [ [protocol] *("+" rs)]
-           protocol      = ALPHA *31ALPHANUM
-           rs            = ALPHA *31ALPHANUM
-        // The protocol and rs fields are limited to 32
-        // characters and must start with an alphabetic.
-        // The current set of "known" strings are:
-        // protocol      = "rcds" / "thttp" / "hdl" / "rwhois" / "z3950"
-        // rs            = "N2L" / "N2Ls" / "N2R" / "N2Rs" / "N2C"
-        //               / "N2Ns" / "L2R" / "L2Ns" / "L2Ls" / "L2C"
-
-          i.e. an optional protocol specification followed by 0 or more
-          resolution services. Each resolution service is indicated by
-          an initial '+' character.
-
-          Note that the empty string is also a valid service field. This
-          will typically be seen at the top levels of a namespace, when
-          it is impossible to know what services and protocols will be
-          offered by a particular publisher within that name space.
-
-          At this time the known protocols are rcds[7], hdl[10] (binary,
-          UDP-based protocols),  thttp[5] (a textual, TCP-based
-          protocol), rwhois[11] (textual, UDP or TCP based), and
-          Z39.50[12] (binary, TCP-based). More will be allowed later.
-          The names of the protocols must be formed from the characters
-          [a-Z0-9]. Case of the characters is not significant.
-
-          The service requests currently allowed will be described in
-          more detail in [6], but in brief they are:
-                N2L  - Given a URN, return a URL
-                N2Ls - Given a URN, return a set of URLs
-                N2R  - Given a URN, return an instance of the resource.
-                N2Rs - Given a URN, return multiple instances of the
-                       resource, typically encoded using
-                       multipart/alternative.
-
-
-
-Daniel & Mealling             Experimental                     [Page 12]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-                N2C  - Given a URN, return a collection of meta-
-                       information on the named resource. The format of
-                       this response is the subject of another document.
-                N2Ns - Given a URN, return all URNs that are also
-                       identifers for the resource.
-                L2R  - Given a URL, return the resource.
-                L2Ns - Given a URL, return all the URNs that are
-                       identifiers for the resource.
-                L2Ls - Given a URL, return all the URLs for instances of
-                       of the same resource.
-                L2C  - Given a URL, return a description of the
-                       resource.
-
-          The actual format of the service request and response will be
-          determined by the resolution protocol, and is the subject for
-          other documents (e.g. [5]). Protocols need not offer all
-          services. The labels for service requests shall be formed from
-          the set of characters [A-Z0-9]. The case of the alphabetic
-          characters is not significant.
-
-   Regexp
-          A STRING containing a substitution expression that is applied
-          to the original URI in order to construct the next domain name
-          to lookup. The grammar of the substitution expression is given
-          in the next section.
-
-   Replacement
-          The next NAME to query for NAPTR, SRV, or A records depending
-          on the value of the flags field. As mentioned above, this may
-          be compressed.
-
-Substitution Expression Grammar:
-================================
-
-   The content of the regexp field is a substitution expression. True
-   sed(1) substitution expressions are not appropriate for use in this
-   application for a variety of reasons, therefore the contents of the
-   regexp field MUST follow the grammar below:
-
-subst_expr   = delim-char  ere  delim-char  repl  delim-char  *flags
-delim-char   = "/" / "!" / ... (Any non-digit or non-flag character other
-               than backslash '\'. All occurances of a delim_char in a
-               subst_expr must be the same character.)
-ere          = POSIX Extended Regular Expression (see [13], section
-               2.8.4)
-repl         = dns_str /  backref / repl dns_str  / repl backref
-dns_str      = 1*DNS_CHAR
-backref      = "\" 1POS_DIGIT
-
-
-
-Daniel & Mealling             Experimental                     [Page 13]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-flags        = "i"
-DNS_CHAR     = "-" / "0" / ... / "9" / "a" / ... / "z" / "A" / ... / "Z"
-POS_DIGIT    = "1" / "2" / ... / "9"  ; 0 is not an allowed backref
-value domain name (see RFC-1123 [14]).
-
-   The result of applying the substitution expression to the original
-   URI MUST result in a string that obeys the syntax for DNS host names
-   [14]. Since it is possible for the regexp field to be improperly
-   specified, such that a non-conforming host name can be constructed,
-   client software SHOULD verify that the result is a legal host name
-   before making queries on it.
-
-   Backref expressions in the repl portion of the substitution
-   expression are replaced by the (possibly empty) string of characters
-   enclosed by '(' and ')' in the ERE portion of the substitution
-   expression. N is a single digit from 1 through 9, inclusive. It
-   specifies the N'th backref expression, the one that begins with the
-   N'th '(' and continues to the matching ')'.  For example, the ERE
-                      (A(B(C)DE)(F)G)
-   has backref expressions:
-                      \1  = ABCDEFG
-                      \2  = BCDE
-                      \3  = C
-                      \4  = F
-                 \5..\9  = error - no matching subexpression
-
-   The "i" flag indicates that the ERE matching SHALL be performed in a
-   case-insensitive fashion. Furthermore, any backref replacements MAY
-   be normalized to lower case when the "i" flag is given.
-
-   The first character in the substitution expression shall be used as
-   the character that delimits the components of the substitution
-   expression.  There must be exactly three non-escaped occurrences of
-   the delimiter character in a substitution expression. Since escaped
-   occurrences of the delimiter character will be interpreted as
-   occurrences of that character, digits MUST NOT be used as delimiters.
-   Backrefs would be confused with literal digits were this allowed.
-   Similarly, if flags are specified in the substitution expression, the
-   delimiter character must not also be a flag character.
-
-
-
-
-
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                     [Page 14]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-Advice to domain administrators:
-================================
-
-   Beware of regular expressions. Not only are they a pain to get
-   correct on their own, but there is the previously mentioned
-   interaction with DNS. Any backslashes in a regexp must be entered
-   twice in a zone file in order to appear once in a query response.
-   More seriously, the need for double backslashes has probably not been
-   tested by all implementors of DNS servers. We anticipate that urn.net
-   will be the heaviest user of regexps. Only when delegating portions
-   of namespaces should the typical domain administrator need to use
-   regexps.
-
-   On a related note, beware of interactions with the shell when
-   manipulating regexps from the command line. Since '\' is a common
-   escape character in shells, there is a good chance that when you
-   think you are saying "\\" you are actually saying "\".  Similar
-   caveats apply to characters such as
-
-   The "a" flag allows the next lookup to be for A records rather than
-   SRV records. Since there is no place for a port specification in the
-   NAPTR record, when the "A" flag is used the specified protocol must
-   be running on its default port.
-
-   The URN Sytnax draft defines a canonical form for each URN, which
-   requires %encoding characters outside a limited repertoire. The
-   regular expressions MUST be written to operate on that canonical
-   form. Since international character sets will end up with extensive
-   use of %encoded characters, regular expressions operating on them
-   will be essentially impossible to read or write by hand.
-
-Usage
-=====
-
-   For the edification of implementers, pseudocode for a client routine
-   using NAPTRs is given below. This code is provided merely as a
-   convience, it does not have any weight as a standard way to process
-   NAPTR records. Also, as is the case with pseudocode, it has never
-   been executed and may contain logical errors. You have been warned.
-
-    //
-    // findResolver(URN)
-    // Given a URN, find a host that can resolve it.
-    //
-    findResolver(string URN) {
-      // prepend prefix to urn.net
-      sprintf(key, "%s.urn.net", extractNS(URN));
-      do {
-
-
-
-Daniel & Mealling             Experimental                     [Page 15]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-        rewrite_flag = false;
-        terminal = false;
-        if (key has been seen) {
-          quit with a loop detected error
-        }
-        add key to list of "seens"
-        records = lookup(type=NAPTR, key); // get all NAPTR RRs for 'key'
-
-        discard any records with an unknown value in the "flags" field.
-        sort NAPTR records by "order" field and "preference" field
-            (with "order" being more significant than "preference").
-        n_naptrs = number of NAPTR records in response.
-        curr_order = records[0].order;
-        max_order = records[n_naptrs-1].order;
-
-        // Process current batch of NAPTRs according to "order" field.
-        for (j=0; j < n_naptrs && records[j].order <= max_order; j++) {
-          if (unknown_flag) // skip this record and go to next one
-             continue;
-          newkey = rewrite(URN, naptr[j].replacement, naptr[j].regexp);
-          if (!newkey) // Skip to next record if the rewrite didn't
-             match continue;
-          // We did do a rewrite, shrink max_order to current value
-          // so that delegation works properly
-          max_order = naptr[j].order;
-          // Will we know what to do with the protocol and services
-          // specified in the NAPTR? If not, try next record.
-          if(!isKnownProto(naptr[j].services)) {
-            continue;
-          }
-          if(!isKnownService(naptr[j].services)) {
-            continue;
-          }
-
-          // At this point we have a successful rewrite and we will
-          // know how to speak the protocol and request a known
-          // resolution service. Before we do the next lookup, check
-          // some optimization possibilities.
-
-          if (strcasecmp(flags, "S")
-           || strcasecmp(flags, "P"))
-           || strcasecmp(flags, "A")) {
-             terminal = true;
-             services = naptr[j].services;
-             addnl = any SRV and/or A records returned as additional
-                     info for naptr[j].
-          }
-          key = newkey;
-
-
-
-Daniel & Mealling             Experimental                     [Page 16]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-          rewriteflag = true;
-          break;
-        }
-      } while (rewriteflag && !terminal);
-
-      // Did we not find our way to a resolver?
-      if (!rewrite_flag) {
-         report an error
-         return NULL;
-      }
-
-
-      // Leave rest to another protocol?
-      if (strcasecmp(flags, "P")) {
-         return key as host to talk to;
-      }
-
-      // If not, keep plugging
-      if (!addnl) { // No SRVs came in as additional info, look them up
-        srvs = lookup(type=SRV, key);
-      }
-
-      sort SRV records by preference, weight, ...
-      foreach (SRV record) { // in order of preference
-        try contacting srv[j].target using the protocol and one of the
-            resolution service requests from the "services" field of the
-            last NAPTR record.
-        if (successful)
-          return (target, protocol, service);
-          // Actually we would probably return a result, but this
-          // code was supposed to just tell us a good host to talk to.
-      }
-      die with an "unable to find a host" error;
-    }
-
-Notes:
-======
-
-     -  A client MUST process multiple NAPTR records in the order
-        specified by the "order" field, it MUST NOT simply use the first
-        record that provides a known protocol and service combination.
-
-
-
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                     [Page 17]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-     -  If a record at a particular order matches the URI, but the
-        client doesn't know the specified protocol and service, the
-        client SHOULD continue to examine records that have the same
-        order. The client MUST NOT consider records with a higher value
-        of order. This is necessary to make delegation of portions of
-        the namespace work.  The order field is what lets site
-        administrators say "all requests for URIs matching pattern x go
-        to server 1, all others go to server 2".
-        (A match is defined as:
-          1)  The NAPTR provides a replacement domain name
-          or
-          2) The regular expression matches the URN
-           )
-
-     -  When multiple RRs have the same "order", the client should use
-        the value of the preference field to select the next NAPTR to
-        consider. However, because of preferred protocols or services,
-        estimates of network distance and bandwidth, etc. clients may
-        use different criteria to sort the records.
-     -  If the lookup after a rewrite fails, clients are strongly
-        encouraged to report a failure, rather than backing up to pursue
-        other rewrite paths.
-     -  When a namespace is to be delegated among a set of resolvers,
-        regexps must be used. Each regexp appears in a separate NAPTR
-        RR.  Administrators should do as little delegation as possible,
-        because of limitations on the size of DNS responses.
-     -  Note that SRV RRs impose additional requirements on clients.
-
-Acknowledgments:
-=================
-
-   The editors would like to thank Keith Moore for all his consultations
-   during the development of this draft. We would also like to thank
-   Paul Vixie for his assistance in debugging our implementation, and
-   his answers on our questions. Finally, we would like to acknowledge
-   our enormous intellectual debt to the participants in the Knoxville
-   series of meetings, as well as to the participants in the URI and URN
-   working groups.
-
-References:
-===========
-
-   [1]  Sollins, Karen and Larry Masinter, "Functional Requirements
-        for Uniform Resource Names", RFC-1737, Dec. 1994.
-
-   [2]  The URN Implementors, Uniform Resource Names: A Progress Report,
-        http://www.dlib.org/dlib/february96/02arms.html, D-Lib Magazine,
-        February 1996.
-
-
-
-Daniel & Mealling             Experimental                     [Page 18]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-   [3]  Moats, Ryan, "URN Syntax", RFC-2141, May 1997.
-
-   [4]  Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying
-        the location of services (DNS SRV)", RFC-2052, October 1996.
-
-   [5]  Daniel, Jr., Ron, "A Trivial Convention for using HTTP in URN
-        Resolution", RFC-2169, June 1997.
-
-   [6]  URN-WG, "URN Resolution Services", Work in Progress.
-
-   [7]  Moore, Keith,  Shirley Browne, Jason Cox, and Jonathan Gettler,
-        Resource Cataloging and Distribution System, Technical Report
-        CS-97-346, University of Tennessee, Knoxville, December 1996
-
-   [8]  Paul Vixie, personal communication.
-
-   [9]  Crocker, Dave H. "Standard for the Format of ARPA Internet Text
-        Messages", RFC-822, August 1982.
-
-   [10] Orth, Charles and Bill Arms; Handle Resolution Protocol
-        Specification, http://www.handle.net/docs/client_spec.html
-
-   [11] Williamson, S., M. Kosters, D. Blacka, J. Singh, K. Zeilstra,
-        "Referral Whois Protocol (RWhois)", RFC-2167, June 1997.
-
-   [12] Information Retrieval (Z39.50): Application Service Definition
-        and Protocol Specification, ANSI/NISO Z39.50-1995, July 1995.
-
-   [13] IEEE Standard for Information Technology - Portable Operating
-        System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1);
-        IEEE Std 1003.2-1992; The Institute of Electrical and
-        Electronics Engineers; New York; 1993. ISBN:1-55937-255-9
-
-   [14] Braden, R., "Requirements for Internet Hosts - Application and
-        and Support", RFC-1123, Oct. 1989.
-
-   [15] Sollins, Karen, "Requirements and a Framework for URN Resolution
-        Systems", November 1996, Work in Progress.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                     [Page 19]
-
-RFC 2168            Resolution of URIs Using the DNS           June 1997
-
-
-Security Considerations
-=======================
-
-   The use of "urn.net" as the registry for URN namespaces is subject to
-   denial of service attacks, as well as other DNS spoofing attacks. The
-   interactions with DNSSEC are currently being studied. It is expected
-   that NAPTR records will be signed with SIG records once the DNSSEC
-   work is deployed.
-
-   The rewrite rules make identifiers from other namespaces subject to
-   the same attacks as normal domain names. Since they have not been
-   easily resolvable before, this may or may not be considered a
-   problem.
-
-   Regular expressions should be checked for sanity, not blindly passed
-   to something like PERL.
-
-   This document has discussed a way of locating a resolver, but has not
-   discussed any detail of how the communication with the resolver takes
-   place. There are significant security considerations attached to the
-   communication with a resolver. Those considerations are outside the
-   scope of this document, and must be addressed by the specifications
-   for particular resolver communication protocols.
-
-Author Contact Information:
-===========================
-
-   Ron Daniel
-   Los Alamos National Laboratory
-   MS B287
-   Los Alamos, NM, USA, 87545
-   voice:  +1 505 665 0597
-   fax:    +1 505 665 4939
-   email:  rdaniel@lanl.gov
-
-
-   Michael Mealling
-   Network Solutions
-   505 Huntmar Park Drive
-   Herndon, VA  22070
-   voice: (703) 742-0400
-   fax: (703) 742-9552
-   email: michaelm@internic.net
-   URL: http://www.netsol.com/
-
-
-
-
-
-
-
-Daniel & Mealling             Experimental                     [Page 20]
-
diff --git a/contrib/bind9/doc/rfc/rfc2181.txt b/contrib/bind9/doc/rfc/rfc2181.txt
deleted file mode 100644
index 7899e1c..0000000
--- a/contrib/bind9/doc/rfc/rfc2181.txt
+++ /dev/null
@@ -1,842 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                             R. Elz
-Request for Comments: 2181                       University of Melbourne
-Updates: 1034, 1035, 1123                                        R. Bush
-Category: Standards Track                                    RGnet, Inc.
-                                                               July 1997
-
-
-                Clarifications to the DNS Specification
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-1. Abstract
-
-   This document considers some areas that have been identified as
-   problems with the specification of the Domain Name System, and
-   proposes remedies for the defects identified.  Eight separate issues
-   are considered:
-
-     + IP packet header address usage from multi-homed servers,
-     + TTLs in sets of records with the same name, class, and type,
-     + correct handling of zone cuts,
-     + three minor issues concerning SOA records and their use,
-     + the precise definition of the Time to Live (TTL)
-     + Use of the TC (truncated) header bit
-     + the issue of what is an authoritative, or canonical, name,
-     + and the issue of what makes a valid DNS label.
-
-   The first six of these are areas where the correct behaviour has been
-   somewhat unclear, we seek to rectify that.  The other two are already
-   adequately specified, however the specifications seem to be sometimes
-   ignored.  We seek to reinforce the existing specifications.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 1]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-
-
-Contents
-
-    1  Abstract  ...................................................   1
-    2  Introduction  ...............................................   2
-    3  Terminology  ................................................   3
-    4  Server Reply Source Address Selection  ......................   3
-    5  Resource Record Sets  .......................................   4
-    6  Zone Cuts  ..................................................   8
-    7  SOA RRs  ....................................................  10
-    8  Time to Live (TTL)  .........................................  10
-    9  The TC (truncated) header bit  ..............................  11
-   10  Naming issues  ..............................................  11
-   11  Name syntax  ................................................  13
-   12  Security Considerations  ....................................  14
-   13  References  .................................................  14
-   14  Acknowledgements  ...........................................  15
-   15  Authors' Addresses  .........................................  15
-
-
-
-
-2. Introduction
-
-   Several problem areas in the Domain Name System specification
-   [RFC1034, RFC1035] have been noted through the years [RFC1123].  This
-   document addresses several additional problem areas.  The issues here
-   are independent.  Those issues are the question of which source
-   address a multi-homed DNS server should use when replying to a query,
-   the issue of differing TTLs for DNS records with the same label,
-   class and type, and the issue of canonical names, what they are, how
-   CNAME records relate, what names are legal in what parts of the DNS,
-   and what is the valid syntax of a DNS name.
-
-   Clarifications to the DNS specification to avoid these problems are
-   made in this memo.  A minor ambiguity in RFC1034 concerned with SOA
-   records is also corrected, as is one in the definition of the TTL
-   (Time To Live) and some possible confusion in use of the TC bit.
-
-
-
-
-
-
-
-
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 2]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-3. Terminology
-
-   This memo does not use the oft used expressions MUST, SHOULD, MAY, or
-   their negative forms.  In some sections it may seem that a
-   specification is worded mildly, and hence some may infer that the
-   specification is optional.  That is not correct.  Anywhere that this
-   memo suggests that some action should be carried out, or must be
-   carried out, or that some behaviour is acceptable, or not, that is to
-   be considered as a fundamental aspect of this specification,
-   regardless of the specific words used.  If some behaviour or action
-   is truly optional, that will be clearly specified by the text.
-
-4. Server Reply Source Address Selection
-
-   Most, if not all, DNS clients, expect the address from which a reply
-   is received to be the same address as that to which the query
-   eliciting the reply was sent.  This is true for servers acting as
-   clients for the purposes of recursive query resolution, as well as
-   simple resolver clients.  The address, along with the identifier (ID)
-   in the reply is used for disambiguating replies, and filtering
-   spurious responses.  This may, or may not, have been intended when
-   the DNS was designed, but is now a fact of life.
-
-   Some multi-homed hosts running DNS servers generate a reply using a
-   source address that is not the same as the destination address from
-   the client's request packet.  Such replies will be discarded by the
-   client because the source address of the reply does not match that of
-   a host to which the client sent the original request.  That is, it
-   appears to be an unsolicited response.
-
-4.1. UDP Source Address Selection
-
-   To avoid these problems, servers when responding to queries using UDP
-   must cause the reply to be sent with the source address field in the
-   IP header set to the address that was in the destination address
-   field of the IP header of the packet containing the query causing the
-   response.  If this would cause the response to be sent from an IP
-   address that is not permitted for this purpose, then the response may
-   be sent from any legal IP address allocated to the server.  That
-   address should be chosen to maximise the possibility that the client
-   will be able to use it for further queries.  Servers configured in
-   such a way that not all their addresses are equally reachable from
-   all potential clients need take particular care when responding to
-   queries sent to anycast, multicast, or similar, addresses.
-
-
-
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 3]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-4.2. Port Number Selection
-
-   Replies to all queries must be directed to the port from which they
-   were sent.  When queries are received via TCP this is an inherent
-   part of the transport protocol.  For queries received by UDP the
-   server must take note of the source port and use that as the
-   destination port in the response.  Replies should always be sent from
-   the port to which they were directed.  Except in extraordinary
-   circumstances, this will be the well known port assigned for DNS
-   queries [RFC1700].
-
-5. Resource Record Sets
-
-   Each DNS Resource Record (RR) has a label, class, type, and data.  It
-   is meaningless for two records to ever have label, class, type and
-   data all equal - servers should suppress such duplicates if
-   encountered.  It is however possible for most record types to exist
-   with the same label, class and type, but with different data.  Such a
-   group of records is hereby defined to be a Resource Record Set
-   (RRSet).
-
-5.1. Sending RRs from an RRSet
-
-   A query for a specific (or non-specific) label, class, and type, will
-   always return all records in the associated RRSet - whether that be
-   one or more RRs.  The response must be marked as "truncated" if the
-   entire RRSet will not fit in the response.
-
-5.2. TTLs of RRs in an RRSet
-
-   Resource Records also have a time to live (TTL).  It is possible for
-   the RRs in an RRSet to have different TTLs.  No uses for this have
-   been found that cannot be better accomplished in other ways.  This
-   can, however, cause partial replies (not marked "truncated") from a
-   caching server, where the TTLs for some but not all the RRs in the
-   RRSet have expired.
-
-   Consequently the use of differing TTLs in an RRSet is hereby
-   deprecated, the TTLs of all RRs in an RRSet must be the same.
-
-   Should a client receive a response containing RRs from an RRSet with
-   differing TTLs, it should treat this as an error.  If the RRSet
-   concerned is from a non-authoritative source for this data, the
-   client should simply ignore the RRSet, and if the values were
-   required, seek to acquire them from an authoritative source.  Clients
-   that are configured to send all queries to one, or more, particular
-   servers should treat those servers as authoritative for this purpose.
-   Should an authoritative source send such a malformed RRSet, the
-
-
-
-Elz & Bush                  Standards Track                     [Page 4]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-   client should treat the RRs for all purposes as if all TTLs in the
-   RRSet had been set to the value of the lowest TTL in the RRSet.  In
-   no case may a server send an RRSet with TTLs not all equal.
-
-5.3. DNSSEC Special Cases
-
-   Two of the record types added by DNS Security (DNSSEC) [RFC2065]
-   require special attention when considering the formation of Resource
-   Record Sets.  Those are the SIG and NXT records.  It should be noted
-   that DNS Security is still very new, and there is, as yet, little
-   experience with it.  Readers should be prepared for the information
-   related to DNSSEC contained in this document to become outdated as
-   the DNS Security specification matures.
-
-5.3.1. SIG records and RRSets
-
-   A SIG record provides signature (validation) data for another RRSet
-   in the DNS.  Where a zone has been signed, every RRSet in the zone
-   will have had a SIG record associated with it.  The data type of the
-   RRSet is included in the data of the SIG RR, to indicate with which
-   particular RRSet this SIG record is associated.  Were the rules above
-   applied, whenever a SIG record was included with a response to
-   validate that response, the SIG records for all other RRSets
-   associated with the appropriate node would also need to be included.
-   In some cases, this could be a very large number of records, not
-   helped by their being rather large RRs.
-
-   Thus, it is specifically permitted for the authority section to
-   contain only those SIG RRs with the "type covered" field equal to the
-   type field of an answer being returned.  However, where SIG records
-   are being returned in the answer section, in response to a query for
-   SIG records, or a query for all records associated with a name
-   (type=ANY) the entire SIG RRSet must be included, as for any other RR
-   type.
-
-   Servers that receive responses containing SIG records in the
-   authority section, or (probably incorrectly) as additional data, must
-   understand that the entire RRSet has almost certainly not been
-   included.  Thus, they must not cache that SIG record in a way that
-   would permit it to be returned should a query for SIG records be
-   received at that server.  RFC2065 actually requires that SIG queries
-   be directed only to authoritative servers to avoid the problems that
-   could be caused here, and while servers exist that do not understand
-   the special properties of SIG records, this will remain necessary.
-   However, careful design of SIG record processing in new
-   implementations should permit this restriction to be relaxed in the
-   future, so resolvers do not need to treat SIG record queries
-   specially.
-
-
-
-Elz & Bush                  Standards Track                     [Page 5]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-   It has been occasionally stated that a received request for a SIG
-   record should be forwarded to an authoritative server, rather than
-   being answered from data in the cache.  This is not necessary - a
-   server that has the knowledge of SIG as a special case for processing
-   this way would be better to correctly cache SIG records, taking into
-   account their characteristics.  Then the server can determine when it
-   is safe to reply from the cache, and when the answer is not available
-   and the query must be forwarded.
-
-5.3.2. NXT RRs
-
-   Next Resource Records (NXT) are even more peculiar.  There will only
-   ever be one NXT record in a zone for a particular label, so
-   superficially, the RRSet problem is trivial.  However, at a zone cut,
-   both the parent zone, and the child zone (superzone and subzone in
-   RFC2065 terminology) will have NXT records for the same name.  Those
-   two NXT records do not form an RRSet, even where both zones are
-   housed at the same server.  NXT RRSets always contain just a single
-   RR.  Where both NXT records are visible, two RRSets exist.  However,
-   servers are not required to treat this as a special case when
-   receiving NXT records in a response.  They may elect to notice the
-   existence of two different NXT RRSets, and treat that as they would
-   two different RRSets of any other type.  That is, cache one, and
-   ignore the other.  Security aware servers will need to correctly
-   process the NXT record in the received response though.
-
-5.4. Receiving RRSets
-
-   Servers must never merge RRs from a response with RRs in their cache
-   to form an RRSet.  If a response contains data that would form an
-   RRSet with data in a server's cache the server must either ignore the
-   RRs in the response, or discard the entire RRSet currently in the
-   cache, as appropriate.  Consequently the issue of TTLs varying
-   between the cache and a response does not cause concern, one will be
-   ignored.  That is, one of the data sets is always incorrect if the
-   data from an answer differs from the data in the cache.  The
-   challenge for the server is to determine which of the data sets is
-   correct, if one is, and retain that, while ignoring the other.  Note
-   that if a server receives an answer containing an RRSet that is
-   identical to that in its cache, with the possible exception of the
-   TTL value, it may, optionally, update the TTL in its cache with the
-   TTL of the received answer.  It should do this if the received answer
-   would be considered more authoritative (as discussed in the next
-   section) than the previously cached answer.
-
-
-
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 6]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-5.4.1. Ranking data
-
-   When considering whether to accept an RRSet in a reply, or retain an
-   RRSet already in its cache instead, a server should consider the
-   relative likely trustworthiness of the various data.  An
-   authoritative answer from a reply should replace cached data that had
-   been obtained from additional information in an earlier reply.
-   However additional information from a reply will be ignored if the
-   cache contains data from an authoritative answer or a zone file.
-
-   The accuracy of data available is assumed from its source.
-   Trustworthiness shall be, in order from most to least:
-
-     + Data from a primary zone file, other than glue data,
-     + Data from a zone transfer, other than glue,
-     + The authoritative data included in the answer section of an
-       authoritative reply.
-     + Data from the authority section of an authoritative answer,
-     + Glue from a primary zone, or glue from a zone transfer,
-     + Data from the answer section of a non-authoritative answer, and
-       non-authoritative data from the answer section of authoritative
-       answers,
-     + Additional information from an authoritative answer,
-       Data from the authority section of a non-authoritative answer,
-       Additional information from non-authoritative answers.
-
-   Note that the answer section of an authoritative answer normally
-   contains only authoritative data.  However when the name sought is an
-   alias (see section 10.1.1) only the record describing that alias is
-   necessarily authoritative.  Clients should assume that other records
-   may have come from the server's cache.  Where authoritative answers
-   are required, the client should query again, using the canonical name
-   associated with the alias.
-
-   Unauthenticated RRs received and cached from the least trustworthy of
-   those groupings, that is data from the additional data section, and
-   data from the authority section of a non-authoritative answer, should
-   not be cached in such a way that they would ever be returned as
-   answers to a received query.  They may be returned as additional
-   information where appropriate.  Ignoring this would allow the
-   trustworthiness of relatively untrustworthy data to be increased
-   without cause or excuse.
-
-   When DNS security [RFC2065] is in use, and an authenticated reply has
-   been received and verified, the data thus authenticated shall be
-   considered more trustworthy than unauthenticated data of the same
-   type.  Note that throughout this document, "authoritative" means a
-   reply with the AA bit set.  DNSSEC uses trusted chains of SIG and KEY
-
-
-
-Elz & Bush                  Standards Track                     [Page 7]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-   records to determine the authenticity of data, the AA bit is almost
-   irrelevant.  However DNSSEC aware servers must still correctly set
-   the AA bit in responses to enable correct operation with servers that
-   are not security aware (almost all currently).
-
-   Note that, glue excluded, it is impossible for data from two
-   correctly configured primary zone files, two correctly configured
-   secondary zones (data from zone transfers) or data from correctly
-   configured primary and secondary zones to ever conflict.  Where glue
-   for the same name exists in multiple zones, and differs in value, the
-   nameserver should select data from a primary zone file in preference
-   to secondary, but otherwise may choose any single set of such data.
-   Choosing that which appears to come from a source nearer the
-   authoritative data source may make sense where that can be
-   determined.  Choosing primary data over secondary allows the source
-   of incorrect glue data to be discovered more readily, when a problem
-   with such data exists.  Where a server can detect from two zone files
-   that one or more are incorrectly configured, so as to create
-   conflicts, it should refuse to load the zones determined to be
-   erroneous, and issue suitable diagnostics.
-
-   "Glue" above includes any record in a zone file that is not properly
-   part of that zone, including nameserver records of delegated sub-
-   zones (NS records), address records that accompany those NS records
-   (A, AAAA, etc), and any other stray data that might appear.
-
-5.5. Sending RRSets (reprise)
-
-   A Resource Record Set should only be included once in any DNS reply.
-   It may occur in any of the Answer, Authority, or Additional
-   Information sections, as required.  However it should not be repeated
-   in the same, or any other, section, except where explicitly required
-   by a specification.  For example, an AXFR response requires the SOA
-   record (always an RRSet containing a single RR) be both the first and
-   last record of the reply.  Where duplicates are required this way,
-   the TTL transmitted in each case must be the same.
-
-6. Zone Cuts
-
-   The DNS tree is divided into "zones", which are collections of
-   domains that are treated as a unit for certain management purposes.
-   Zones are delimited by "zone cuts".  Each zone cut separates a
-   "child" zone (below the cut) from a "parent" zone (above the cut).
-   The domain name that appears at the top of a zone (just below the cut
-   that separates the zone from its parent) is called the zone's
-   "origin".  The name of the zone is the same as the name of the domain
-   at the zone's origin.  Each zone comprises that subset of the DNS
-   tree that is at or below the zone's origin, and that is above the
-
-
-
-Elz & Bush                  Standards Track                     [Page 8]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-   cuts that separate the zone from its children (if any).  The
-   existence of a zone cut is indicated in the parent zone by the
-   existence of NS records specifying the origin of the child zone.  A
-   child zone does not contain any explicit reference to its parent.
-
-6.1. Zone authority
-
-   The authoritative servers for a zone are enumerated in the NS records
-   for the origin of the zone, which, along with a Start of Authority
-   (SOA) record are the mandatory records in every zone.  Such a server
-   is authoritative for all resource records in a zone that are not in
-   another zone.  The NS records that indicate a zone cut are the
-   property of the child zone created, as are any other records for the
-   origin of that child zone, or any sub-domains of it.  A server for a
-   zone should not return authoritative answers for queries related to
-   names in another zone, which includes the NS, and perhaps A, records
-   at a zone cut, unless it also happens to be a server for the other
-   zone.
-
-   Other than the DNSSEC cases mentioned immediately below, servers
-   should ignore data other than NS records, and necessary A records to
-   locate the servers listed in the NS records, that may happen to be
-   configured in a zone at a zone cut.
-
-6.2. DNSSEC issues
-
-   The DNS security mechanisms [RFC2065] complicate this somewhat, as
-   some of the new resource record types added are very unusual when
-   compared with other DNS RRs.  In particular the NXT ("next") RR type
-   contains information about which names exist in a zone, and hence
-   which do not, and thus must necessarily relate to the zone in which
-   it exists.  The same domain name may have different NXT records in
-   the parent zone and the child zone, and both are valid, and are not
-   an RRSet.  See also section 5.3.2.
-
-   Since NXT records are intended to be automatically generated, rather
-   than configured by DNS operators, servers may, but are not required
-   to, retain all differing NXT records they receive regardless of the
-   rules in section 5.4.
-
-   For a secure parent zone to securely indicate that a subzone is
-   insecure, DNSSEC requires that a KEY RR indicating that the subzone
-   is insecure, and the parent zone's authenticating SIG RR(s) be
-   present in the parent zone, as they by definition cannot be in the
-   subzone.  Where a subzone is secure, the KEY and SIG records will be
-   present, and authoritative, in that zone, but should also always be
-   present in the parent zone (if secure).
-
-
-
-
-Elz & Bush                  Standards Track                     [Page 9]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-   Note that in none of these cases should a server for the parent zone,
-   not also being a server for the subzone, set the AA bit in any
-   response for a label at a zone cut.
-
-7. SOA RRs
-
-   Three minor issues concerning the Start of Zone of Authority (SOA)
-   Resource Record need some clarification.
-
-7.1. Placement of SOA RRs in authoritative answers
-
-   RFC1034, in section 3.7, indicates that the authority section of an
-   authoritative answer may contain the SOA record for the zone from
-   which the answer was obtained.  When discussing negative caching,
-   RFC1034 section 4.3.4 refers to this technique but mentions the
-   additional section of the response.  The former is correct, as is
-   implied by the example shown in section 6.2.5 of RFC1034.  SOA
-   records, if added, are to be placed in the authority section.
-
-7.2. TTLs on SOA RRs
-
-   It may be observed that in section 3.2.1 of RFC1035, which defines
-   the format of a Resource Record, that the definition of the TTL field
-   contains a throw away line which states that the TTL of an SOA record
-   should always be sent as zero to prevent caching.  This is mentioned
-   nowhere else, and has not generally been implemented.
-   Implementations should not assume that SOA records will have a TTL of
-   zero, nor are they required to send SOA records with a TTL of zero.
-
-7.3. The SOA.MNAME field
-
-   It is quite clear in the specifications, yet seems to have been
-   widely ignored, that the MNAME field of the SOA record should contain
-   the name of the primary (master) server for the zone identified by
-   the SOA.  It should not contain the name of the zone itself.  That
-   information would be useless, as to discover it, one needs to start
-   with the domain name of the SOA record - that is the name of the
-   zone.
-
-8. Time to Live (TTL)
-
-   The definition of values appropriate to the TTL field in STD 13 is
-   not as clear as it could be, with respect to how many significant
-   bits exist, and whether the value is signed or unsigned.  It is
-   hereby specified that a TTL value is an unsigned number, with a
-   minimum value of 0, and a maximum value of 2147483647.  That is, a
-   maximum of 2^31 - 1.  When transmitted, this value shall be encoded
-   in the less significant 31 bits of the 32 bit TTL field, with the
-
-
-
-Elz & Bush                  Standards Track                    [Page 10]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-   most significant, or sign, bit set to zero.
-
-   Implementations should treat TTL values received with the most
-   significant bit set as if the entire value received was zero.
-
-   Implementations are always free to place an upper bound on any TTL
-   received, and treat any larger values as if they were that upper
-   bound.  The TTL specifies a maximum time to live, not a mandatory
-   time to live.
-
-9. The TC (truncated) header bit
-
-   The TC bit should be set in responses only when an RRSet is required
-   as a part of the response, but could not be included in its entirety.
-   The TC bit should not be set merely because some extra information
-   could have been included, but there was insufficient room.  This
-   includes the results of additional section processing.  In such cases
-   the entire RRSet that will not fit in the response should be omitted,
-   and the reply sent as is, with the TC bit clear.  If the recipient of
-   the reply needs the omitted data, it can construct a query for that
-   data and send that separately.
-
-   Where TC is set, the partial RRSet that would not completely fit may
-   be left in the response.  When a DNS client receives a reply with TC
-   set, it should ignore that response, and query again, using a
-   mechanism, such as a TCP connection, that will permit larger replies.
-
-10. Naming issues
-
-   It has sometimes been inferred from some sections of the DNS
-   specification [RFC1034, RFC1035] that a host, or perhaps an interface
-   of a host, is permitted exactly one authoritative, or official, name,
-   called the canonical name.  There is no such requirement in the DNS.
-
-10.1. CNAME resource records
-
-   The DNS CNAME ("canonical name") record exists to provide the
-   canonical name associated with an alias name.  There may be only one
-   such canonical name for any one alias.  That name should generally be
-   a name that exists elsewhere in the DNS, though there are some rare
-   applications for aliases with the accompanying canonical name
-   undefined in the DNS.  An alias name (label of a CNAME record) may,
-   if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no
-   other data.  That is, for any label in the DNS (any domain name)
-   exactly one of the following is true:
-
-
-
-
-
-
-Elz & Bush                  Standards Track                    [Page 11]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-     + one CNAME record exists, optionally accompanied by SIG, NXT, and
-       KEY RRs,
-     + one or more records exist, none being CNAME records,
-     + the name exists, but has no associated RRs of any type,
-     + the name does not exist at all.
-
-10.1.1. CNAME terminology
-
-   It has been traditional to refer to the label of a CNAME record as "a
-   CNAME".  This is unfortunate, as "CNAME" is an abbreviation of
-   "canonical name", and the label of a CNAME record is most certainly
-   not a canonical name.  It is, however, an entrenched usage.  Care
-   must therefore be taken to be very clear whether the label, or the
-   value (the canonical name) of a CNAME resource record is intended.
-   In this document, the label of a CNAME resource record will always be
-   referred to as an alias.
-
-10.2. PTR records
-
-   Confusion about canonical names has lead to a belief that a PTR
-   record should have exactly one RR in its RRSet.  This is incorrect,
-   the relevant section of RFC1034 (section 3.6.2) indicates that the
-   value of a PTR record should be a canonical name.  That is, it should
-   not be an alias.  There is no implication in that section that only
-   one PTR record is permitted for a name.  No such restriction should
-   be inferred.
-
-   Note that while the value of a PTR record must not be an alias, there
-   is no requirement that the process of resolving a PTR record not
-   encounter any aliases.  The label that is being looked up for a PTR
-   value might have a CNAME record.  That is, it might be an alias.  The
-   value of that CNAME RR, if not another alias, which it should not be,
-   will give the location where the PTR record is found.  That record
-   gives the result of the PTR type lookup.  This final result, the
-   value of the PTR RR, is the label which must not be an alias.
-
-10.3. MX and NS records
-
-   The domain name used as the value of a NS resource record, or part of
-   the value of a MX resource record must not be an alias.  Not only is
-   the specification clear on this point, but using an alias in either
-   of these positions neither works as well as might be hoped, nor well
-   fulfills the ambition that may have led to this approach.  This
-   domain name must have as its value one or more address records.
-   Currently those will be A records, however in the future other record
-   types giving addressing information may be acceptable.  It can also
-   have other RRs, but never a CNAME RR.
-
-
-
-
-Elz & Bush                  Standards Track                    [Page 12]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-   Searching for either NS or MX records causes "additional section
-   processing" in which address records associated with the value of the
-   record sought are appended to the answer.  This helps avoid needless
-   extra queries that are easily anticipated when the first was made.
-
-   Additional section processing does not include CNAME records, let
-   alone the address records that may be associated with the canonical
-   name derived from the alias.  Thus, if an alias is used as the value
-   of an NS or MX record, no address will be returned with the NS or MX
-   value.  This can cause extra queries, and extra network burden, on
-   every query.  It is trivial for the DNS administrator to avoid this
-   by resolving the alias and placing the canonical name directly in the
-   affected record just once when it is updated or installed.  In some
-   particular hard cases the lack of the additional section address
-   records in the results of a NS lookup can cause the request to fail.
-
-11. Name syntax
-
-   Occasionally it is assumed that the Domain Name System serves only
-   the purpose of mapping Internet host names to data, and mapping
-   Internet addresses to host names.  This is not correct, the DNS is a
-   general (if somewhat limited) hierarchical database, and can store
-   almost any kind of data, for almost any purpose.
-
-   The DNS itself places only one restriction on the particular labels
-   that can be used to identify resource records.  That one restriction
-   relates to the length of the label and the full name.  The length of
-   any one label is limited to between 1 and 63 octets.  A full domain
-   name is limited to 255 octets (including the separators).  The zero
-   length full name is defined as representing the root of the DNS tree,
-   and is typically written and displayed as ".".  Those restrictions
-   aside, any binary string whatever can be used as the label of any
-   resource record.  Similarly, any binary string can serve as the value
-   of any record that includes a domain name as some or all of its value
-   (SOA, NS, MX, PTR, CNAME, and any others that may be added).
-   Implementations of the DNS protocols must not place any restrictions
-   on the labels that can be used.  In particular, DNS servers must not
-   refuse to serve a zone because it contains labels that might not be
-   acceptable to some DNS client programs.  A DNS server may be
-   configurable to issue warnings when loading, or even to refuse to
-   load, a primary zone containing labels that might be considered
-   questionable, however this should not happen by default.
-
-   Note however, that the various applications that make use of DNS data
-   can have restrictions imposed on what particular values are
-   acceptable in their environment.  For example, that any binary label
-   can have an MX record does not imply that any binary name can be used
-   as the host part of an e-mail address.  Clients of the DNS can impose
-
-
-
-Elz & Bush                  Standards Track                    [Page 13]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-   whatever restrictions are appropriate to their circumstances on the
-   values they use as keys for DNS lookup requests, and on the values
-   returned by the DNS.  If the client has such restrictions, it is
-   solely responsible for validating the data from the DNS to ensure
-   that it conforms before it makes any use of that data.
-
-   See also [RFC1123] section 6.1.3.5.
-
-12. Security Considerations
-
-   This document does not consider security.
-
-   In particular, nothing in section 4 is any way related to, or useful
-   for, any security related purposes.
-
-   Section 5.4.1 is also not related to security.  Security of DNS data
-   will be obtained by the Secure DNS [RFC2065], which is mostly
-   orthogonal to this memo.
-
-   It is not believed that anything in this document adds to any
-   security issues that may exist with the DNS, nor does it do anything
-   to that will necessarily lessen them.  Correct implementation of the
-   clarifications in this document might play some small part in
-   limiting the spread of non-malicious bad data in the DNS, but only
-   DNSSEC can help with deliberate attempts to subvert DNS data.
-
-13. References
-
-   [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.
-
-   [RFC1123]   Braden, R., "Requirements for Internet Hosts - application
-               and support", STD 3, RFC 1123, January 1989.
-
-   [RFC1700]   Reynolds, J., Postel, J., "Assigned Numbers",
-               STD 2, RFC 1700, October 1994.
-
-   [RFC2065]   Eastlake, D., Kaufman, C., "Domain Name System Security
-               Extensions", RFC 2065, January 1997.
-
-
-
-
-
-
-
-
-
-Elz & Bush                  Standards Track                    [Page 14]
-
-RFC 2181        Clarifications to the DNS Specification        July 1997
-
-
-14. Acknowledgements
-
-   This memo arose from discussions in the DNSIND working group of the
-   IETF in 1995 and 1996, the members of that working group are largely
-   responsible for the ideas captured herein.  Particular thanks to
-   Donald E. Eastlake, 3rd, and Olafur Gudmundsson, for help with the
-   DNSSEC issues in this document, and to John Gilmore for pointing out
-   where the clarifications were not necessarily clarifying.  Bob Halley
-   suggested clarifying the placement of SOA records in authoritative
-   answers, and provided the references.  Michael Patton, as usual, and
-   Mark Andrews, Alan Barrett and Stan Barber provided much assistance
-   with many details.  Josh Littlefield helped make sure that the
-   clarifications didn't cause problems in some irritating corner cases.
-
-15. Authors' Addresses
-
-   Robert Elz
-   Computer Science
-   University of Melbourne
-   Parkville, Victoria, 3052
-   Australia.
-
-   EMail: kre@munnari.OZ.AU
-
-
-   Randy Bush
-   RGnet, Inc.
-   5147 Crystal Springs Drive NE
-   Bainbridge Island, Washington,  98110
-   United States.
-
-   EMail: randy@psg.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Elz & Bush                  Standards Track                    [Page 15]
diff --git a/contrib/bind9/doc/rfc/rfc2230.txt b/contrib/bind9/doc/rfc/rfc2230.txt
deleted file mode 100644
index 03995fe..0000000
--- a/contrib/bind9/doc/rfc/rfc2230.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         R. Atkinson
-Request for Comments: 2230                                            NRL
-Category: Informational                                     November 1997
-
-
-               Key Exchange Delegation Record for the DNS
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1997).  All Rights Reserved.
-
-ABSTRACT
-
-   This note describes a mechanism whereby authorisation for one node to
-   act as key exchanger for a second node is delegated and made
-   available via the Secure DNS.  This mechanism is intended to be used
-   only with the Secure DNS.  It can be used with several security
-   services.  For example, a system seeking to use IP Security [RFC-
-   1825, RFC-1826, RFC-1827] to protect IP packets for a given
-   destination can use this mechanism to determine the set of authorised
-   remote key exchanger systems for that destination.
-
-1. INTRODUCTION
-
-
-   The Domain Name System (DNS) is the standard way that Internet nodes
-   locate information about addresses, mail exchangers, and other data
-   relating to remote Internet nodes. [RFC-1035, RFC-1034] More
-   recently, Eastlake and Kaufman have defined standards-track security
-   extensions to the DNS. [RFC-2065] These security extensions can be
-   used to authenticate signed DNS data records and can also be used to
-   store signed public keys in the DNS.
-
-   The KX record is useful in providing an authenticatible method of
-   delegating authorisation for one node to provide key exchange
-   services on behalf of one or more, possibly different, nodes.  This
-   note specifies the syntax and semantics of the KX record, which is
-   currently in limited deployment in certain IP-based networks.  The
-
-
-
-
-
-
-
-Atkinson                     Informational                      [Page 1]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-   reader is assumed to be familiar with the basics of DNS, including
-   familiarity with [RFC-1035, RFC-1034].  This document is not on the
-   IETF standards-track and does not specify any level of standard.
-   This document merely provides information for the Internet community.
-
-1.1 Identity Terminology
-
-   This document relies upon the concept of "identity domination".  This
-   concept might be new to the reader and so is explained in this
-   section.  The subject of endpoint naming for security associations
-   has historically been somewhat contentious.  This document takes no
-   position on what forms of identity should be used.  In a network,
-   there are several forms of identity that are possible.
-
-   For example, IP Security has defined notions of identity that
-   include: IP Address, IP Address Range, Connection ID, Fully-Qualified
-   Domain Name (FQDN), and User with Fully Qualified Domain Name (USER
-   FQDN).
-
-   A USER FQDN identity dominates a FQDN identity.  A FQDN identity in
-   turn dominates an IP Address identity.  Similarly, a Connection ID
-   dominates an IP Address identity.  An IP Address Range dominates each
-   IP Address identity for each IP address within that IP address range.
-   Also, for completeness, an IP Address identity is considered to
-   dominate itself.
-
-2. APPROACH
-
-   This document specifies a new kind of DNS Resource Record (RR), known
-   as the Key Exchanger (KX) record.  A Key Exchanger Record has the
-   mnemonic "KX" and the type code of 36.  Each KX record is associated
-   with a fully-qualified domain name.  The KX record is modeled on the
-   MX record described in [Part86]. Any given domain, subdomain, or host
-   entry in the DNS might have a KX record.
-
-2.1 IPsec Examples
-
-   In these two examples, let S be the originating node and let D be the
-   destination node.  S2 is another node on the same subnet as S.  D2 is
-   another node on the same subnet as D.  R1 and R2 are IPsec-capable
-   routers.  The path from S to D goes via first R1 and later R2.  The
-   return path from D to S goes via first R2 and later R1.
-
-   IETF-standard IP Security uses unidirectional Security Associations
-   [RFC-1825].  Therefore, a typical IP session will use a pair of
-   related Security Associations, one in each direction.  The examples
-   below talk about how to setup an example Security Association, but in
-   practice a pair of matched Security Associations will normally be
-
-
-
-Atkinson                     Informational                      [Page 2]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-   used.
-
-2.1.1 Subnet-to-Subnet Example
-
-   If neither S nor D implements IPsec, security can still be provided
-   between R1 and R2 by building a secure tunnel.  This can use either
-   AH or ESP.
-
-       S ---+                                          +----D
-            |                                          |
-            +- R1 -----[zero or more routers]-------R2-+
-            |                                          |
-       S2---+                                          +----D2
-
-       Figure 1:  Network Diagram for Subnet-to-Subnet Example
-
-   In this example, R1 makes the policy decision to provide the IPsec
-   service for traffic from R1 destined for R2.  Once R1 has decided
-   that the packet from S to D should be protected, it performs a secure
-   DNS lookup for the records associated with domain D.  If R1 only
-   knows the IP address for D, then a secure reverse DNS lookup will be
-   necessary to determine the domain D, before that forward secure DNS
-   lookup for records associated with domain D.  If these DNS records of
-   domain D include a KX record for the IPsec service, then R1 knows
-   which set of nodes are authorised key exchanger nodes for the
-   destination D.
-
-   In this example, let there be at least one KX record for D and let
-   the most preferred KX record for D point at R2.  R1 then selects a
-   key exchanger (in this example, R2) for D from the list obtained from
-   the secure DNS.  Then R1 initiates a key management session with that
-   key exchanger (in this example, R2) to setup an IPsec Security
-   Association between R1 and D.  In this example, R1 knows (either by
-   seeing an outbound packet arriving from S destined to D or via other
-   methods) that S will be sending traffic to D.  In this example R1's
-   policy requires that traffic from S to D should be segregated at
-   least on a host-to-host basis, so R1 desires an IPsec Security
-   Association with source identity that dominates S, proxy identity
-   that dominates R1, and destination identity that dominates R2.
-
-   In turn, R2 is able to authenticate the delegation of Key Exchanger
-   authorisation for target S to R1 by making an authenticated forward
-   DNS lookup for KX records associated with S and verifying that at
-   least one such record points to R1.  The identity S is typically
-   given to R2 as part of the key management process between R1 and R2.
-
-
-
-
-
-
-Atkinson                     Informational                      [Page 3]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-   If D initially only knows the IP address of S, then it will need to
-   perform a secure reverse DNS lookup to obtain the fully-qualified
-   domain name for S prior to that secure forward DNS lookup.
-
-   If R2 does not receive an authenticated DNS response indicating that
-   R1 is an authorised key exchanger for S, then D will not accept the
-   SA negotiation from R1 on behalf of identity S.
-
-   If the proposed IPsec Security Association is acceptable to both R1
-   and R2, each of which might have separate policies, then they create
-   that IPsec Security Association via Key Management.
-
-   Note that for unicast traffic, Key Management will typically also
-   setup a separate (but related) IPsec Security Association for the
-   return traffic.  That return IPsec Security Association will have
-   equivalent identities.  In this example, that return IPsec Security
-   Association will have a source identity that dominates D, a proxy
-   identity that dominates R2, and a destination identity that dominates
-   R1.
-
-   Once the IPsec Security Association has been created, then R1 uses it
-   to protect traffic from S destined for D via a secure tunnel that
-   originates at R1 and terminates at R2.  For the case of unicast, R2
-   will use the return IPsec Security Association to protect traffic
-   from D destined for S via a secure tunnel that originates at R2 and
-   terminates at R1.
-
-2.1.2 Subnet-to-Host Example
-
-   Consider the case where D and R1 implement IPsec, but S does not
-   implement IPsec, which is an interesting variation on the previous
-   example.  This example is shown in Figure 2 below.
-
-       S ---+
-            |
-            +- R1 -----[zero or more routers]-------D
-            |
-       S2---+
-
-       Figure 2:  Network Diagram for Subnet-to-Host Example
-
-   In this example, R1 makes the policy decision that IP Security is
-   needed for the packet travelling from S to D.  Then, R1 performs the
-   secure DNS lookup for D and determines that D is its own key
-   exchanger, either from the existence of a KX record for D pointing to
-   D or from an authenticated DNS response indicating that no KX record
-   exists for D.  If R1 does not initially know the domain name of D,
-   then prior to the above forward secure DNS lookup, R1 performs a
-
-
-
-Atkinson                     Informational                      [Page 4]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-   secure reverse DNS lookup on the IP address of D to determine the
-   fully-qualified domain name for that IP address.  R1 then initiates
-   key management with D to create an IPsec Security Association on
-   behalf of S.
-
-   In turn, D can verify that R1 is authorised to create an IPsec
-   Security Association on behalf of S by performing a DNS KX record
-   lookup for target S.  R1 usually provides identity S to D via key
-   management.  If D only has the IP address of S, then D will need to
-   perform a secure reverse lookup on the IP address of S to determine
-   domain name S prior to the secure forward DNS lookup on S to locate
-   the KX records for S.
-
-   If D does not receive an authenticated DNS response indicating that
-   R1 is an authorised key exchanger for S, then D will not accept the
-   SA negotiation from R1 on behalf of identity S.
-
-   If the IPsec Security Association is successfully established between
-   R1 and D, that IPsec Security Association has a source identity that
-   dominates S's IP address, a proxy identity that dominates R1's IP
-   address, and a destination identity that dominates D's IP address.
-
-   Finally, R1 begins providing the security service for packets from S
-   that transit R1 destined for D.  When D receives such packets, D
-   examines the SA information during IPsec input processing and sees
-   that R1's address is listed as valid proxy address for that SA and
-   that S is the source address for that SA.  Hence, D knows at input
-   processing time that R1 is authorised to provide security on behalf
-   of S.  Therefore packets coming from R1 with valid IP security that
-   claim to be from S are trusted by D to have really come from S.
-
-2.1.3 Host to Subnet Example
-
-   Now consider the above case from D's perspective (i.e. where D is
-   sending IP packets to S).  This variant is sometimes known as the
-   Mobile Host or "roadwarrier" case. The same basic concepts apply, but
-   the details are covered here in hope of improved clarity.
-
-       S ---+
-            |
-            +- R1 -----[zero or more routers]-------D
-            |
-       S2---+
-
-       Figure 3:  Network Diagram for Host-to-Subnet Example
-
-
-
-
-
-
-Atkinson                     Informational                      [Page 5]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-   In this example, D makes the policy decision that IP Security is
-   needed for the packets from D to S.  Then D performs the secure DNS
-   lookup for S and discovers that a KX record for S exists and points
-   at R1.  If D only has the IP address of S, then it performs a secure
-   reverse DNS lookup on the IP address of S prior to the forward secure
-   DNS lookup for S.
-
-   D then initiates key management with R1, where R1 is acting on behalf
-   of S, to create an appropriate Security Association.  Because D is
-   acting as its own key exchanger, R1 does not need to perform a secure
-   DNS lookup for KX records associated with D.
-
-   D and R1 then create an appropriate IPsec Security Security
-   Association.  This IPsec Security Association is setup as a secure
-   tunnel with a source identity that dominates D's IP Address and a
-   destination identity that dominates R1's IP Address.  Because D
-   performs IPsec for itself, no proxy identity is needed in this IPsec
-   Security Association.  If the proxy identity is non-null in this
-   situation, then the proxy identity must dominate D's IP Address.
-
-   Finally, D sends secured IP packets to R1.  R1 receives those
-   packets, provides IPsec input processing (including appropriate
-   inner/outer IP address validation), and forwards valid packets along
-   to S.
-
-2.2 Other Examples
-
-   This mechanism can be extended for use with other services as well.
-   To give some insight into other possible uses, this section discusses
-   use of KX records in environments using a Key Distribution Center
-   (KDC), such as Kerberos [KN93], and a possible use of KX records in
-   conjunction with mobile nodes accessing the network via a dialup
-   service.
-
-2.2.1 KDC Examples
-
-   This example considers the situation of a destination node
-   implementing IPsec that can only obtain its Security Association
-   information from a Key Distribution Center (KDC).  Let the KDC
-   implement both the KDC protocol and also a non-KDC key management
-   protocol (e.g. ISAKMP).  In such a case, each client node of the KDC
-   might have its own KX record pointing at the KDC so that nodes not
-   implementing the KDC protocol can still create Security Associations
-   with each of the client nodes of the KDC.
-
-   In the event the session initiator were not using the KDC but the
-   session target was an IPsec node that only used the KDC, the
-   initiator would find the KX record for the target pointing at the
-
-
-
-Atkinson                     Informational                      [Page 6]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-   KDC.  Then, the external key management exchange (e.g. ISAKMP) would
-   be between the initiator and the KDC.  Then the KDC would distribute
-   the IPsec SA to the KDC-only IPsec node using the KDC.  The IPsec
-   traffic itself could travel directly between the initiator and the
-   destination node.
-
-   In the event the initiator node could only use the KDC and the target
-   were not using the KDC, the initiator would send its request for a
-   key to the KDC.  The KDC would then initiate an external key
-   management exchange (e.g. ISAKMP) with a node that the target's KX
-   record(s) pointed to, on behalf of the initiator node.
-
-   The target node could verify that the KDC were allowed to proxy for
-   the initiator node by looking up the KX records for the initiator
-   node and finding a KX record for the initiator that listed the KDC.
-
-   Then the external key exchange would be performed between the KDC and
-   the target node.  Then the KDC would distribute the resulting IPsec
-   Security Association to the initiator.  Again, IPsec traffic itself
-   could travel directly between the initiator and the destination.
-
-2.2.2 Dial-Up Host Example
-
-   This example outlines a possible use of KX records with mobile hosts
-   that dial into the network via PPP and are dynamically assigned an IP
-   address and domain-name at dial-in time.
-
-   Consider the situation where each mobile node is dynamically assigned
-   both a domain name and an IP address at the time that node dials into
-   the network.  Let the policy require that each mobile node act as its
-   own Key Exchanger.  In this case, it is important that dial-in nodes
-   use addresses from one or more well known IP subnets or address pools
-   dedicated to dial-in access.  If that is true, then no KX record or
-   other action is needed to ensure that each node will act as its own
-   Key Exchanger because lack of a KX record indicates that the node is
-   its own Key Exchanger.
-
-   Consider the situation where the mobile node's domain name remains
-   constant but its IP address changes.  Let the policy require that
-   each mobile node act as its own Key Exchanger.  In this case, there
-   might be operational problems when another node attempts to perform a
-   secure reverse DNS lookup on the IP address to determine the
-   corresponding domain name.  The authenticated DNS binding (in the
-   form of a PTR record) between the mobile node's currently assigned IP
-   address and its permanent domain name will need to be securely
-   updated each time the node is assigned a new IP address.  There are
-   no mechanisms for accomplishing this that are both IETF-standard and
-   widely deployed as of the time this note was written.  Use of Dynamic
-
-
-
-Atkinson                     Informational                      [Page 7]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-   DNS Update without authentication is a significant security risk and
-   hence is not recommended for this situation.
-
-3. SYNTAX OF KX RECORD
-
-   A KX record has the DNS TYPE of "KX" and a numeric value of 36.  A KX
-   record is a member of the Internet ("IN") CLASS in the DNS.  Each KX
-   record is associated with a <domain-name> entry in the DNS.  A KX
-   record has the following textual syntax:
-
-        <domain-name>  IN  KX  <preference> <domain-name>
-
-   For this description, let the <domain-name> item to the left of the
-   "KX" string be called <domain-name 1> and the <domain-name> item to
-   the right of the "KX" string be called <domain-name 2>.  <preference>
-   is a non-negative integer.
-
-   Internet nodes about to initiate a key exchange with <domain-name 1>
-   should instead contact <domain-name 2> to initiate the key exchange
-   for a security service between the initiator and <domain-name 2>.  If
-   more than one KX record exists for <domain-name 1>, then the
-   <preference> field is used to indicate preference among the systems
-   delegated to.  Lower values are preferred over higher values.  The
-   <domain-name 2> is authorised to provide key exchange services on
-   behalf of <domain-name 1>.  The <domain-name 2> MUST have a CNAME
-   record, an A record, or an AAAA record associated with it.
-
-3.1 KX RDATA format
-
-   The KX DNS record has the following RDATA format:
-
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    |                  PREFERENCE                   |
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-    /                   EXCHANGER                   /
-    /                                               /
-    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   where:
-
-   PREFERENCE      A 16 bit non-negative integer which specifies the
-                   preference given to this RR among other KX records
-                   at the same owner.  Lower values are preferred.
-
-   EXCHANGER       A <domain-name> which specifies a host willing to
-                   act as a mail exchange for the owner name.
-
-
-
-
-
-Atkinson                     Informational                      [Page 8]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-   KX records MUST cause type A additional section processing for the
-   host specified by EXCHANGER.  In the event that the host processing
-   the DNS transaction supports IPv6, KX records MUST also cause type
-   AAAA additional section processing.
-
-   The KX RDATA field MUST NOT be compressed.
-
-4. SECURITY CONSIDERATIONS
-
-   KX records MUST always be signed using the method(s) defined by the
-   DNS Security extensions specified in [RFC-2065].  All unsigned KX
-   records MUST be ignored because of the security vulnerability caused
-   by assuming that unsigned records are valid.  All signed KX records
-   whose signatures do not correctly validate MUST be ignored because of
-   the potential security vulnerability in trusting an invalid KX
-   record.
-
-   KX records MUST be ignored by systems not implementing Secure DNS
-   because such systems have no mechanism to authenticate the KX record.
-
-   If a node does not have a permanent DNS entry and some form of
-   Dynamic DNS Update is in use, then those dynamic DNS updates MUST be
-   fully authenticated to prevent an adversary from injecting false DNS
-   records (especially the KX, A, and PTR records) into the Domain Name
-   System.  If false records were inserted into the DNS without being
-   signed by the Secure DNS mechanisms, then a denial-of-service attack
-   results.  If false records were inserted into the DNS and were
-   (erroneously) signed by the signing authority, then an active attack
-   results.
-
-   Myriad serious security vulnerabilities can arise if the restrictions
-   throuhout this document are not strictly adhered to.  Implementers
-   should carefully consider the openly published issues relating to DNS
-   security [Bell95,Vixie95] as they build their implementations.
-   Readers should also consider the security considerations discussed in
-   the DNS Security Extensions document [RFC-2065].
-
-5. REFERENCES
-
-
-   [RFC-1825]  Atkinson, R., "IP Authentication Header", RFC 1826,
-               August 1995.
-
-   [RFC-1827]  Atkinson, R., "IP Encapsulating Security Payload",
-               RFC 1827, August 1995.
-
-
-
-
-
-
-Atkinson                     Informational                      [Page 9]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-   [Bell95] Bellovin, S., "Using the Domain Name System for System
-            Break-ins", Proceedings of 5th USENIX UNIX Security
-            Symposium, USENIX Association, Berkeley, CA, June 1995.
-            ftp://ftp.research.att.com/dist/smb/dnshack.ps
-
-   [RFC-2065]  Eastlake, D., and C. Kaufman, "Domain Name System
-               Security Extensions", RFC 2065, January 1997.
-
-   [RFC-1510]  Kohl J., and C. Neuman, "The Kerberos Network
-               Authentication Service", RFC 1510, September 1993.
-
-   [RFC-1035]  Mockapetris, P., "Domain names - implementation and
-               specification", STD 13, RFC 1035, November 1987.
-
-   [RFC-1034]  Mockapetris, P., "Domain names - concepts and
-               facilities", STD 13, RFC 1034, November 1987.
-
-   [Vixie95] P. Vixie, "DNS and BIND Security Issues", Proceedings of
-             the 5th USENIX UNIX Security Symposium, USENIX
-             Association, Berkeley, CA, June 1995.
-             ftp://ftp.vix.com/pri/vixie/bindsec.psf
-
-ACKNOWLEDGEMENTS
-
-   Development of this DNS record was primarily performed during 1993
-   through 1995.  The author's work on this was sponsored jointly by the
-   Computing Systems Technology Office (CSTO) of the Advanced Research
-   Projects Agency (ARPA) and by the Information Security Program Office
-   (PD71E), Space & Naval Warface Systems Command (SPAWAR).  In that
-   era, Dave Mihelcic and others provided detailed review and
-   constructive feedback.  More recently, Bob Moscowitz and Todd Welch
-   provided detailed review and constructive feedback of a work in
-   progress version of this document.
-
-AUTHOR'S ADDRESS
-
-   Randall Atkinson
-   Code 5544
-   Naval Research Laboratory
-   4555 Overlook Avenue, SW
-   Washington, DC 20375-5337
-
-   Phone: (DSN) 354-8590
-   EMail: atkinson@itd.nrl.navy.mil
-
-
-
-
-
-
-
-Atkinson                     Informational                     [Page 10]
-
-RFC 2230           DNS Key Exchange Delegation Record      November 1997
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1997).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implmentation may be prepared, copied, published
-   andand 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Atkinson                     Informational                     [Page 11]
-
diff --git a/contrib/bind9/doc/rfc/rfc2308.txt b/contrib/bind9/doc/rfc/rfc2308.txt
deleted file mode 100644
index 9123a95..0000000
--- a/contrib/bind9/doc/rfc/rfc2308.txt
+++ /dev/null
@@ -1,1067 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          M. Andrews
-Request for Comments: 2308                                          CSIRO
-Updates: 1034, 1035                                            March 1998
-Category: Standards Track
-
-
-              Negative Caching of DNS Queries (DNS NCACHE)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-Abstract
-
-   [RFC1034] provided a description of how to cache negative responses.
-   It however had a fundamental flaw in that it did not allow a name
-   server to hand out those cached responses to other resolvers, thereby
-   greatly reducing the effect of the caching.  This document addresses
-   issues raise in the light of experience and replaces [RFC1034 Section
-   4.3.4].
-
-   Negative caching was an optional part of the DNS specification and
-   deals with the caching of the non-existence of an RRset [RFC2181] or
-   domain name.
-
-   Negative caching is useful as it reduces the response time for
-   negative answers.  It also reduces the number of messages that have
-   to be sent between resolvers and name servers hence overall network
-   traffic.  A large proportion of DNS traffic on the Internet could be
-   eliminated if all resolvers implemented negative caching.  With this
-   in mind negative caching should no longer be seen as an optional part
-   of a DNS resolver.
-
-
-
-
-
-
-
-
-
-
-
-Andrews                     Standards Track                     [Page 1]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-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 [RFC2119].
-
-   "Negative caching" - the storage of knowledge that something does not
-   exist.  We can store the knowledge that a record has a particular
-   value.  We can also do the reverse, that is, to store the knowledge
-   that a record does not exist.  It is the storage of knowledge that
-   something does not exist, cannot or does not give an answer that we
-   call negative caching.
-
-   "QNAME" - the name in the query section of an answer, or where this
-   resolves to a CNAME, or CNAME chain, the data field of the last
-   CNAME.  The last CNAME in this sense is that which contains a value
-   which does not resolve to another CNAME.  Implementations should note
-   that including CNAME records in responses in order, so that the first
-   has the label from the query section, and then each in sequence has
-   the label from the data section of the previous (where more than one
-   CNAME is needed) allows the sequence to be processed in one pass, and
-   considerably eases the task of the receiver.  Other relevant records
-   (such as SIG RRs [RFC2065]) can be interspersed amongst the CNAMEs.
-
-   "NXDOMAIN" - an alternate expression for the "Name Error" RCODE as
-   described in [RFC1035 Section 4.1.1] and the two terms are used
-   interchangeably in this document.
-
-   "NODATA" - a pseudo RCODE which indicates that the name is valid, for
-   the given class, but are no records of the given type.  A NODATA
-   response has to be inferred from the answer.
-
-   "FORWARDER" - a nameserver used to resolve queries instead of
-   directly using the authoritative nameserver chain.  The forwarder
-   typically either has better access to the internet, or maintains a
-   bigger cache which may be shared amongst many resolvers.  How a
-   server is identified as a FORWARDER, or knows it is a FORWARDER is
-   outside the scope of this document.  However if you are being used as
-   a forwarder the query will have the recursion desired flag set.
-
-   An understanding of [RFC1034], [RFC1035] and [RFC2065] is expected
-   when reading this document.
-
-
-
-
-
-
-
-
-
-Andrews                     Standards Track                     [Page 2]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-2 - Negative Responses
-
-   The most common negative responses indicate that a particular RRset
-   does not exist in the DNS.  The first sections of this document deal
-   with this case.  Other negative responses can indicate failures of a
-   nameserver, those are dealt with in section 7 (Other Negative
-   Responses).
-
-   A negative response is indicated by one of the following conditions:
-
-2.1 - Name Error
-
-   Name errors (NXDOMAIN) are indicated by the presence of "Name Error"
-   in the RCODE field.  In this case the domain referred to by the QNAME
-   does not exist.  Note: the answer section may have SIG and CNAME RRs
-   and the authority section may have SOA, NXT [RFC2065] and SIG RRsets.
-
-   It is possible to distinguish between a referral and a NXDOMAIN
-   response by the presense of NXDOMAIN in the RCODE regardless of the
-   presence of NS or SOA records in the authority section.
-
-   NXDOMAIN responses can be categorised into four types by the contents
-   of the authority section.  These are shown below along with a
-   referral for comparison.  Fields not mentioned are not important in
-   terms of the examples.
-
-           NXDOMAIN RESPONSE: TYPE 1.
-
-           Header:
-               RDCODE=NXDOMAIN
-           Query:
-               AN.EXAMPLE. A
-           Answer:
-               AN.EXAMPLE. CNAME TRIPPLE.XX.
-           Authority:
-               XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
-               XX. NS NS1.XX.
-               XX. NS NS2.XX.
-           Additional:
-               NS1.XX. A 127.0.0.2
-               NS2.XX. A 127.0.0.3
-
-           NXDOMAIN RESPONSE: TYPE 2.
-
-           Header:
-               RDCODE=NXDOMAIN
-           Query:
-               AN.EXAMPLE. A
-
-
-
-Andrews                     Standards Track                     [Page 3]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-           Answer:
-               AN.EXAMPLE. CNAME TRIPPLE.XX.
-           Authority:
-               XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
-           Additional:
-               <empty>
-
-           NXDOMAIN RESPONSE: TYPE 3.
-
-           Header:
-               RDCODE=NXDOMAIN
-           Query:
-               AN.EXAMPLE. A
-           Answer:
-               AN.EXAMPLE. CNAME TRIPPLE.XX.
-           Authority:
-               <empty>
-           Additional:
-               <empty>
-
-           NXDOMAIN RESPONSE: TYPE 4
-
-           Header:
-               RDCODE=NXDOMAIN
-           Query:
-               AN.EXAMPLE. A
-           Answer:
-               AN.EXAMPLE. CNAME TRIPPLE.XX.
-           Authority:
-               XX. NS NS1.XX.
-               XX. NS NS2.XX.
-           Additional:
-               NS1.XX. A 127.0.0.2
-               NS2.XX. A 127.0.0.3
-
-           REFERRAL RESPONSE.
-
-           Header:
-               RDCODE=NOERROR
-           Query:
-               AN.EXAMPLE. A
-           Answer:
-               AN.EXAMPLE. CNAME TRIPPLE.XX.
-           Authority:
-               XX. NS NS1.XX.
-               XX. NS NS2.XX.
-           Additional:
-               NS1.XX. A 127.0.0.2
-
-
-
-Andrews                     Standards Track                     [Page 4]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-               NS2.XX. A 127.0.0.3
-
-   Note, in the four examples of NXDOMAIN responses, it is known that
-   the name "AN.EXAMPLE." exists, and has as its value a CNAME record.
-   The NXDOMAIN refers to "TRIPPLE.XX", which is then known not to
-   exist.  On the other hand, in the referral example, it is shown that
-   "AN.EXAMPLE" exists, and has a CNAME RR as its value, but nothing is
-   known one way or the other about the existence of "TRIPPLE.XX", other
-   than that "NS1.XX" or "NS2.XX" can be consulted as the next step in
-   obtaining information about it.
-
-   Where no CNAME records appear, the NXDOMAIN response refers to the
-   name in the label of the RR in the question section.
-
-2.1.1 Special Handling of Name Error
-
-   This section deals with errors encountered when implementing negative
-   caching of NXDOMAIN responses.
-
-   There are a large number of resolvers currently in existence that
-   fail to correctly detect and process all forms of NXDOMAIN response.
-   Some resolvers treat a TYPE 1 NXDOMAIN response as a referral.  To
-   alleviate this problem it is recommended that servers that are
-   authoritative for the NXDOMAIN response only send TYPE 2 NXDOMAIN
-   responses, that is the authority section contains a SOA record and no
-   NS records.  If a non- authoritative server sends a type 1 NXDOMAIN
-   response to one of these old resolvers, the result will be an
-   unnecessary query to an authoritative server.  This is undesirable,
-   but not fatal except when the server is being used a FORWARDER.  If
-   however the resolver is using the server as a FORWARDER to such a
-   resolver it will be necessary to disable the sending of TYPE 1
-   NXDOMAIN response to it, use TYPE 2 NXDOMAIN instead.
-
-   Some resolvers incorrectly continue processing if the authoritative
-   answer flag is not set, looping until the query retry threshold is
-   exceeded and then returning SERVFAIL.  This is a problem when your
-   nameserver is listed as a FORWARDER for such resolvers.  If the
-   nameserver is used as a FORWARDER by such resolver, the authority
-   flag will have to be forced on for NXDOMAIN responses to these
-   resolvers.  In practice this causes no problems even if turned on
-   always, and has been the default behaviour in BIND from 4.9.3
-   onwards.
-
-2.2 - No Data
-
-   NODATA is indicated by an answer with the RCODE set to NOERROR and no
-   relevant answers in the answer section.  The authority section will
-   contain an SOA record, or there will be no NS records there.
-
-
-
-Andrews                     Standards Track                     [Page 5]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-   NODATA responses have to be algorithmically determined from the
-   response's contents as there is no RCODE value to indicate NODATA.
-   In some cases to determine with certainty that NODATA is the correct
-   response it can be necessary to send another query.
-
-   The authority section may contain NXT and SIG RRsets in addition to
-   NS and SOA records.  CNAME and SIG records may exist in the answer
-   section.
-
-   It is possible to distinguish between a NODATA and a referral
-   response by the presence of a SOA record in the authority section or
-   the absence of NS records in the authority section.
-
-   NODATA responses can be categorised into three types by the contents
-   of the authority section.  These are shown below along with a
-   referral for comparison.  Fields not mentioned are not important in
-   terms of the examples.
-
-           NODATA RESPONSE: TYPE 1.
-
-           Header:
-               RDCODE=NOERROR
-           Query:
-               ANOTHER.EXAMPLE. A
-           Answer:
-               <empty>
-           Authority:
-               EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
-               EXAMPLE. NS NS1.XX.
-               EXAMPLE. NS NS2.XX.
-           Additional:
-               NS1.XX. A 127.0.0.2
-               NS2.XX. A 127.0.0.3
-
-           NO DATA RESPONSE: TYPE 2.
-
-           Header:
-               RDCODE=NOERROR
-           Query:
-               ANOTHER.EXAMPLE. A
-           Answer:
-               <empty>
-           Authority:
-               EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
-           Additional:
-               <empty>
-
-
-
-
-
-Andrews                     Standards Track                     [Page 6]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-           NO DATA RESPONSE: TYPE 3.
-
-           Header:
-               RDCODE=NOERROR
-           Query:
-               ANOTHER.EXAMPLE. A
-           Answer:
-               <empty>
-           Authority:
-               <empty>
-           Additional:
-               <empty>
-
-           REFERRAL RESPONSE.
-
-           Header:
-               RDCODE=NOERROR
-           Query:
-               ANOTHER.EXAMPLE. A
-           Answer:
-               <empty>
-           Authority:
-               EXAMPLE. NS NS1.XX.
-               EXAMPLE. NS NS2.XX.
-           Additional:
-               NS1.XX. A 127.0.0.2
-               NS2.XX. A 127.0.0.3
-
-
-   These examples, unlike the NXDOMAIN examples above, have no CNAME
-   records, however they could, in just the same way that the NXDOMAIN
-   examples did, in which case it would be the value of the last CNAME
-   (the QNAME) for which NODATA would be concluded.
-
-2.2.1 - Special Handling of No Data
-
-   There are a large number of resolvers currently in existence that
-   fail to correctly detect and process all forms of NODATA response.
-   Some resolvers treat a TYPE 1 NODATA response as a referral.  To
-   alleviate this problem it is recommended that servers that are
-   authoritative for the NODATA response only send TYPE 2 NODATA
-   responses, that is the authority section contains a SOA record and no
-   NS records.  Sending a TYPE 1 NODATA response from a non-
-   authoritative server to one of these resolvers will only result in an
-   unnecessary query.  If a server is listed as a FORWARDER for another
-   resolver it may also be necessary to disable the sending of TYPE 1
-   NODATA response for non-authoritative NODATA responses.
-
-
-
-
-Andrews                     Standards Track                     [Page 7]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-   Some name servers fail to set the RCODE to NXDOMAIN in the presence
-   of CNAMEs in the answer section.  If a definitive NXDOMAIN / NODATA
-   answer is required in this case the resolver must query again using
-   the QNAME as the query label.
-
-3 - Negative Answers from Authoritative Servers
-
-   Name servers authoritative for a zone MUST include the SOA record of
-   the zone in the authority section of the response when reporting an
-   NXDOMAIN or indicating that no data of the requested type exists.
-   This is required so that the response may be cached.  The TTL of this
-   record is set from the minimum of the MINIMUM field of the SOA record
-   and the TTL of the SOA itself, and indicates how long a resolver may
-   cache the negative answer.  The TTL SIG record associated with the
-   SOA record should also be trimmed in line with the SOA's TTL.
-
-   If the containing zone is signed [RFC2065] the SOA and appropriate
-   NXT and SIG records MUST be added.
-
-4 - SOA Minimum Field
-
-   The SOA minimum field has been overloaded in the past to have three
-   different meanings, the minimum TTL value of all RRs in a zone, the
-   default TTL of RRs which did not contain a TTL value and the TTL of
-   negative responses.
-
-   Despite being the original defined meaning, the first of these, the
-   minimum TTL value of all RRs in a zone, has never in practice been
-   used and is hereby deprecated.
-
-   The second, the default TTL of RRs which contain no explicit TTL in
-   the master zone file, is relevant only at the primary server.  After
-   a zone transfer all RRs have explicit TTLs and it is impossible to
-   determine whether the TTL for a record was explicitly set or derived
-   from the default after a zone transfer.  Where a server does not
-   require RRs to include the TTL value explicitly, it should provide a
-   mechanism, not being the value of the MINIMUM field of the SOA
-   record, from which the missing TTL values are obtained.  How this is
-   done is implementation dependent.
-
-   The Master File format [RFC 1035 Section 5] is extended to include
-   the following directive:
-
-                           $TTL <TTL> [comment]
-
-
-
-
-
-
-
-Andrews                     Standards Track                     [Page 8]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-   All resource records appearing after the directive, and which do not
-   explicitly include a TTL value, have their TTL set to the TTL given
-   in the $TTL directive.  SIG records without a explicit TTL get their
-   TTL from the "original TTL" of the SIG record [RFC 2065 Section 4.5].
-
-   The remaining of the current meanings, of being the TTL to be used
-   for negative responses, is the new defined meaning of the SOA minimum
-   field.
-
-5 - Caching Negative Answers
-
-   Like normal answers negative answers have a time to live (TTL).  As
-   there is no record in the answer section to which this TTL can be
-   applied, the TTL must be carried by another method.  This is done by
-   including the SOA record from the zone in the authority section of
-   the reply.  When the authoritative server creates this record its TTL
-   is taken from the minimum of the SOA.MINIMUM field and SOA's TTL.
-   This TTL decrements in a similar manner to a normal cached answer and
-   upon reaching zero (0) indicates the cached negative answer MUST NOT
-   be used again.
-
-   A negative answer that resulted from a name error (NXDOMAIN) should
-   be cached such that it can be retrieved and returned in response to
-   another query for the same <QNAME, QCLASS> that resulted in the
-   cached negative response.
-
-   A negative answer that resulted from a no data error (NODATA) should
-   be cached such that it can be retrieved and returned in response to
-   another query for the same <QNAME, QTYPE, QCLASS> that resulted in
-   the cached negative response.
-
-   The NXT record, if it exists in the authority section of a negative
-   answer received, MUST be stored such that it can be be located and
-   returned with SOA record in the authority section, as should any SIG
-   records in the authority section.  For NXDOMAIN answers there is no
-   "necessary" obvious relationship between the NXT records and the
-   QNAME.  The NXT record MUST have the same owner name as the query
-   name for NODATA responses.
-
-   Negative responses without SOA records SHOULD NOT be cached as there
-   is no way to prevent the negative responses looping forever between a
-   pair of servers even with a short TTL.
-
-   Despite the DNS forming a tree of servers, with various mis-
-   configurations it is possible to form a loop in the query graph, e.g.
-   two servers listing each other as forwarders, various lame server
-   configurations.  Without a TTL count down a cache negative response
-
-
-
-
-Andrews                     Standards Track                     [Page 9]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-   when received by the next server would have its TTL reset.  This
-   negative indication could then live forever circulating between the
-   servers involved.
-
-   As with caching positive responses it is sensible for a resolver to
-   limit for how long it will cache a negative response as the protocol
-   supports caching for up to 68 years.  Such a limit should not be
-   greater than that applied to positive answers and preferably be
-   tunable.  Values of one to three hours have been found to work well
-   and would make sensible a default.  Values exceeding one day have
-   been found to be problematic.
-
-6 - Negative answers from the cache
-
-   When a server, in answering a query, encounters a cached negative
-   response it MUST add the cached SOA record to the authority section
-   of the response with the TTL decremented by the amount of time it was
-   stored in the cache.  This allows the NXDOMAIN / NODATA response to
-   time out correctly.
-
-   If a NXT record was cached along with SOA record it MUST be added to
-   the authority section.  If a SIG record was cached along with a NXT
-   record it SHOULD be added to the authority section.
-
-   As with all answers coming from the cache, negative answers SHOULD
-   have an implicit referral built into the answer.  This enables the
-   resolver to locate an authoritative source.  An implicit referral is
-   characterised by NS records in the authority section referring the
-   resolver towards a authoritative source.  NXDOMAIN types 1 and 4
-   responses contain implicit referrals as does NODATA type 1 response.
-
-7 - Other Negative Responses
-
-   Caching of other negative responses is not covered by any existing
-   RFC.  There is no way to indicate a desired TTL in these responses.
-   Care needs to be taken to ensure that there are not forwarding loops.
-
-7.1 Server Failure (OPTIONAL)
-
-   Server failures fall into two major classes.  The first is where a
-   server can determine that it has been misconfigured for a zone.  This
-   may be where it has been listed as a server, but not configured to be
-   a server for the zone, or where it has been configured to be a server
-   for the zone, but cannot obtain the zone data for some reason.  This
-   can occur either because the zone file does not exist or contains
-   errors, or because another server from which the zone should have
-   been available either did not respond or was unable or unwilling to
-   supply the zone.
-
-
-
-Andrews                     Standards Track                    [Page 10]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-   The second class is where the server needs to obtain an answer from
-   elsewhere, but is unable to do so, due to network failures, other
-   servers that don't reply, or return server failure errors, or
-   similar.
-
-   In either case a resolver MAY cache a server failure response.  If it
-   does so it MUST NOT cache it for longer than five (5) minutes, and it
-   MUST be cached against the specific query tuple <query name, type,
-   class, server IP address>.
-
-7.2 Dead / Unreachable Server (OPTIONAL)
-
-   Dead / Unreachable servers are servers that fail to respond in any
-   way to a query or where the transport layer has provided an
-   indication that the server does not exist or is unreachable.  A
-   server may be deemed to be dead or unreachable if it has not
-   responded to an outstanding query within 120 seconds.
-
-   Examples of transport layer indications are:
-
-      ICMP error messages indicating host, net or port unreachable.
-      TCP resets
-      IP stack error messages providing similar indications to those above.
-
-   A server MAY cache a dead server indication.  If it does so it MUST
-   NOT be deemed dead for longer than five (5) minutes.  The indication
-   MUST be stored against query tuple <query name, type, class, server
-   IP address> unless there was a transport layer indication that the
-   server does not exist, in which case it applies to all queries to
-   that specific IP address.
-
-8 - Changes from RFC 1034
-
-   Negative caching in resolvers is no-longer optional, if a resolver
-   caches anything it must also cache negative answers.
-
-   Non-authoritative negative answers MAY be cached.
-
-   The SOA record from the authority section MUST be cached.  Name error
-   indications must be cached against the tuple <query name, QCLASS>.
-   No data indications must be cached against <query name, QTYPE,
-   QCLASS> tuple.
-
-   A cached SOA record must be added to the response.  This was
-   explicitly not allowed because previously the distinction between a
-   normal cached SOA record, and the SOA cached as a result of a
-   negative response was not made, and simply extracting a normal cached
-   SOA and adding that to a cached negative response causes problems.
-
-
-
-Andrews                     Standards Track                    [Page 11]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-   The $TTL TTL directive was added to the master file format.
-
-9 - History of Negative Caching
-
-   This section presents a potted history of negative caching in the DNS
-   and forms no part of the technical specification of negative caching.
-
-   It is interesting to note that the same concepts were re-invented in
-   both the CHIVES and BIND servers.
-
-   The history of the early CHIVES work (Section 9.1) was supplied by
-   Rob Austein <sra@epilogue.com> and is reproduced here in the form in
-   which he supplied it [MPA].
-
-   Sometime around the spring of 1985, I mentioned to Paul Mockapetris
-   that our experience with his JEEVES DNS resolver had pointed out the
-   need for some kind of negative caching scheme.  Paul suggested that
-   we simply cache authoritative errors, using the SOA MINIMUM value for
-   the zone that would have contained the target RRs.  I'm pretty sure
-   that this conversation took place before RFC-973 was written, but it
-   was never clear to me whether this idea was something that Paul came
-   up with on the spot in response to my question or something he'd
-   already been planning to put into the document that became RFC-973.
-   In any case, neither of us was entirely sure that the SOA MINIMUM
-   value was really the right metric to use, but it was available and
-   was under the control of the administrator of the target zone, both
-   of which seemed to us at the time to be important feature.
-
-   Late in 1987, I released the initial beta-test version of CHIVES, the
-   DNS resolver I'd written to replace Paul's JEEVES resolver.  CHIVES
-   included a search path mechanism that was used pretty heavily at
-   several sites (including my own), so CHIVES also included a negative
-   caching mechanism based on SOA MINIMUM values.  The basic strategy
-   was to cache authoritative error codes keyed by the exact query
-   parameters (QNAME, QCLASS, and QTYPE), with a cache TTL equal to the
-   SOA MINIMUM value.  CHIVES did not attempt to track down SOA RRs if
-   they weren't supplied in the authoritative response, so it never
-   managed to completely eliminate the gratuitous DNS error message
-   traffic, but it did help considerably.  Keep in mind that this was
-   happening at about the same time as the near-collapse of the ARPANET
-   due to congestion caused by exponential growth and the the "old"
-   (pre-VJ) TCP retransmission algorithm, so negative caching resulted
-   in drasticly better DNS response time for our users, mailer daemons,
-   etcetera.
-
-
-
-
-
-
-
-Andrews                     Standards Track                    [Page 12]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-   As far as I know, CHIVES was the first resolver to implement negative
-   caching.  CHIVES was developed during the twilight years of TOPS-20,
-   so it never ran on very many machines, but the few machines that it
-   did run on were the ones that were too critical to shut down quickly
-   no matter how much it cost to keep them running.  So what few users
-   we did have tended to drive CHIVES pretty hard.  Several interesting
-   bits of DNS technology resulted from that, but the one that's
-   relevant here is the MAXTTL configuration parameter.
-
-   Experience with JEEVES had already shown that RRs often showed up
-   with ridiculously long TTLs (99999999 was particularly popular for
-   many years, due to bugs in the code and documentation of several
-   early versions of BIND), and that robust software that blindly
-   believed such TTLs could create so many strange failures that it was
-   often necessary to reboot the resolver frequently just to clear this
-   garbage out of the cache.  So CHIVES had a configuration parameter
-   "MAXTTL", which specified the maximum "reasonable" TTL in a received
-   RR.  RRs with TTLs greater than MAXTTL would either have their TTLs
-   reduced to MAXTTL or would be discarded entirely, depending on the
-   setting of another configuration parameter.
-
-   When we started getting field experience with CHIVES's negative
-   caching code, it became clear that the SOA MINIMUM value was often
-   large enough to cause the same kinds of problems for negative caching
-   as the huge TTLs in RRs had for normal caching (again, this was in
-   part due to a bug in several early versions of BIND, where a
-   secondary server would authoritatively deny all knowledge of its
-   zones if it couldn't contact the primaries on reboot).  So we started
-   running the negative cache TTLs through the MAXTTL check too, and
-   continued to experiment.
-
-   The configuration that seemed to work best on WSMR-SIMTEL20.ARMY.MIL
-   (last of the major Internet TOPS-20 machines to be shut down, thus
-   the last major user of CHIVES, thus the place where we had the
-   longest experimental baseline) was to set MAXTTL to about three days.
-   Most of the traffic initiated by SIMTEL20 in its last years was
-   mail-related, and the mail queue timeout was set to one week, so this
-   gave a "stuck" message several tries at complete DNS resolution,
-   without bogging down the system with a lot of useless queries.  Since
-   (for reasons that now escape me) we only had the single MAXTTL
-   parameter rather than separate ones for positive and negative
-   caching, it's not clear how much effect this setting of MAXTTL had on
-   the negative caching code.
-
-   CHIVES also included a second, somewhat controversial mechanism which
-   took the place of negative caching in some cases.  The CHIVES
-   resolver daemon could be configured to load DNS master files, giving
-   it the ability to act as what today would be called a "stealth
-
-
-
-Andrews                     Standards Track                    [Page 13]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-   secondary".  That is, when configured in this way, the resolver had
-   direct access to authoritative information for heavily-used zones.
-   The search path mechanisms in CHIVES reflected this: there were
-   actually two separate search paths, one of which only searched local
-   authoritative zone data, and one which could generate normal
-   iterative queries.  This cut down on the need for negative caching in
-   cases where usage was predictably heavy (e.g., the resolver on
-   XX.LCS.MIT.EDU always loaded the zone files for both LCS.MIT.EDU and
-   AI.MIT.EDU and put both of these suffixes into the "local" search
-   path, since between them the hosts in these two zones accounted for
-   the bulk of the DNS traffic).  Not all sites running CHIVES chose to
-   use this feature; C.CS.CMU.EDU, for example, chose to use the
-   "remote" search path for everything because there were too many
-   different sub-zones at CMU for zone shadowing to be practical for
-   them, so they relied pretty heavily on negative caching even for
-   local traffic.
-
-   Overall, I still think the basic design we used for negative caching
-   was pretty reasonable: the zone administrator specified how long to
-   cache negative answers, and the resolver configuration chose the
-   actual cache time from the range between zero and the period
-   specified by the zone administrator.  There are a lot of details I'd
-   do differently now (like using a new SOA field instead of overloading
-   the MINIMUM field), but after more than a decade, I'd be more worried
-   if we couldn't think of at least a few improvements.
-
-9.2 BIND
-
-   While not the first attempt to get negative caching into BIND, in
-   July 1993, BIND 4.9.2 ALPHA, Anant Kumar of ISI supplied code that
-   implemented, validation and negative caching (NCACHE).  This code had
-   a 10 minute TTL for negative caching and only cached the indication
-   that there was a negative response, NXDOMAIN or NOERROR_NODATA. This
-   is the origin of the NODATA pseudo response code mentioned above.
-
-   Mark Andrews of CSIRO added code (RETURNSOA) that stored the SOA
-   record such that it could be retrieved by a similar query.  UUnet
-   complained that they were getting old answers after loading a new
-   zone, and the option was turned off, BIND 4.9.3-alpha5, April 1994.
-   In reality this indicated that the named needed to purge the space
-   the zone would occupy.  Functionality to do this was added in BIND
-   4.9.3 BETA11 patch2, December 1994.
-
-   RETURNSOA was re-enabled by default, BIND 4.9.5-T1A, August 1996.
-
-
-
-
-
-
-
-Andrews                     Standards Track                    [Page 14]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-10 Example
-
-   The following example is based on a signed zone that is empty apart
-   from the nameservers.  We will query for WWW.XX.EXAMPLE showing
-   initial response and again 10 minutes later.  Note 1: during the
-   intervening 10 minutes the NS records for XX.EXAMPLE have expired.
-   Note 2: the TTL of the SIG records are not explicitly set in the zone
-   file and are hence the TTL of the RRset they are the signature for.
-
-        Zone File:
-
-        $TTL 86400
-        $ORIGIN XX.EXAMPLE.
-        @       IN      SOA     NS1.XX.EXAMPLE. HOSTMATER.XX.EXAMPLE. (
-                                1997102000      ; serial
-                                1800    ; refresh (30 mins)
-                                900     ; retry (15 mins)
-                                604800  ; expire (7 days)
-                                1200 ) ; minimum (20 mins)
-                IN      SIG     SOA ...
-          1200  IN      NXT     NS1.XX.EXAMPLE. A NXT SIG SOA NS KEY
-                IN      SIG     NXT ... XX.EXAMPLE. ...
-           300  IN      NS      NS1.XX.EXAMPLE.
-           300  IN      NS      NS2.XX.EXAMPLE.
-                IN      SIG     NS ... XX.EXAMPLE. ...
-                IN      KEY     0x4100 1 1 ...
-                IN      SIG     KEY ... XX.EXAMPLE. ...
-                IN      SIG     KEY ... EXAMPLE. ...
-        NS1     IN      A       10.0.0.1
-                IN      SIG     A ... XX.EXAMPLE. ...
-          1200  IN      NXT     NS2.XX.EXAMPLE. A NXT SIG
-                IN      SIG     NXT ...
-        NS2     IN      A       10.0.0.2
-                IN      SIG     A ... XX.EXAMPLE. ...
-          1200  IN      NXT     XX.EXAMPLE. A NXT SIG
-                IN      SIG     NXT ... XX.EXAMPLE. ...
-
-        Initial Response:
-
-        Header:
-            RDCODE=NXDOMAIN, AA=1, QR=1, TC=0
-        Query:
-            WWW.XX.EXAMPLE. IN A
-        Answer:
-            <empty>
-        Authority:
-            XX.EXAMPLE.      1200 IN SOA NS1.XX.EXAMPLE. ...
-            XX.EXAMPLE.      1200 IN SIG SOA ... XX.EXAMPLE. ...
-
-
-
-Andrews                     Standards Track                    [Page 15]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-            NS2.XX.EXAMPLE.  1200 IN NXT XX.EXAMPLE. NXT A NXT SIG
-            NS2.XX.EXAMPLE.  1200 IN SIG NXT ... XX.EXAMPLE. ...
-            XX.EXAMPLE.     86400 IN NS  NS1.XX.EXAMPLE.
-            XX.EXAMPLE.     86400 IN NS  NS2.XX.EXAMPLE.
-            XX.EXAMPLE.     86400 IN SIG NS ... XX.EXAMPLE. ...
-        Additional
-            XX.EXAMPLE.     86400 IN KEY 0x4100 1 1 ...
-            XX.EXAMPLE.     86400 IN SIG KEY ... EXAMPLE. ...
-            NS1.XX.EXAMPLE. 86400 IN A   10.0.0.1
-            NS1.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ...
-            NS2.XX.EXAMPLE. 86400 IN A   10.0.0.2
-            NS3.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ...
-
-         After 10 Minutes:
-
-         Header:
-             RDCODE=NXDOMAIN, AA=0, QR=1, TC=0
-         Query:
-             WWW.XX.EXAMPLE. IN A
-         Answer:
-             <empty>
-         Authority:
-             XX.EXAMPLE.       600 IN SOA NS1.XX.EXAMPLE. ...
-             XX.EXAMPLE.       600 IN SIG SOA ... XX.EXAMPLE. ...
-             NS2.XX.EXAMPLE.   600 IN NXT XX.EXAMPLE. NXT A NXT SIG
-             NS2.XX.EXAMPLE.   600 IN SIG NXT ... XX.EXAMPLE. ...
-             EXAMPLE.        65799 IN NS  NS1.YY.EXAMPLE.
-             EXAMPLE.        65799 IN NS  NS2.YY.EXAMPLE.
-             EXAMPLE.        65799 IN SIG NS ... XX.EXAMPLE. ...
-         Additional
-             XX.EXAMPLE.     65800 IN KEY 0x4100 1 1 ...
-             XX.EXAMPLE.     65800 IN SIG KEY ... EXAMPLE. ...
-             NS1.YY.EXAMPLE. 65799 IN A   10.100.0.1
-             NS1.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ...
-             NS2.YY.EXAMPLE. 65799 IN A   10.100.0.2
-             NS3.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ...
-             EXAMPLE.        65799 IN KEY 0x4100 1 1 ...
-             EXAMPLE.        65799 IN SIG KEY ... . ...
-
-
-11 Security Considerations
-
-   It is believed that this document does not introduce any significant
-   additional security threats other that those that already exist when
-   using data from the DNS.
-
-
-
-
-
-
-Andrews                     Standards Track                    [Page 16]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-   With negative caching it might be possible to propagate a denial of
-   service attack by spreading a NXDOMAIN message with a very high TTL.
-   Without negative caching that would be much harder.  A similar effect
-   could be achieved previously by spreading a bad A record, so that the
-   server could not be reached - which is almost the same.  It has the
-   same effect as far as what the end user is able to do, but with a
-   different psychological effect.  With the bad A, I feel "damn the
-   network is broken again" and try again tomorrow.  With the "NXDOMAIN"
-   I feel "Oh, they've turned off the server and it doesn't exist any
-   more" and probably never bother trying this server again.
-
-   A practical example of this is a SMTP server where this behaviour is
-   encoded.  With a NXDOMAIN attack the mail message would bounce
-   immediately, where as with a bad A attack the mail would be queued
-   and could potentially get through after the attack was suspended.
-
-   For such an attack to be successful, the NXDOMAIN indiction must be
-   injected into a parent server (or a busy caching resolver).  One way
-   this might be done by the use of a CNAME which results in the parent
-   server querying an attackers server.  Resolvers that wish to prevent
-   such attacks can query again the final QNAME ignoring any NS data in
-   the query responses it has received for this query.
-
-   Implementing TTL sanity checking will reduce the effectiveness of
-   such an attack, because a successful attack would require re-
-   injection of the bogus data at more frequent intervals.
-
-   DNS Security [RFC2065] provides a mechanism to verify whether a
-   negative response is valid or not, through the use of NXT and SIG
-   records.  This document supports the use of that mechanism by
-   promoting the transmission of the relevant security records even in a
-   non security aware server.
-
-Acknowledgments
-
-   I would like to thank Rob Austein for his history of the CHIVES
-   nameserver. The DNSIND working group, in particular Robert Elz for
-   his valuable technical and editorial contributions to this document.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Andrews                     Standards Track                    [Page 17]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-References
-
-   [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.
-
-   [RFC2065]
-           Eastlake, D., and C. Kaufman, "Domain Name System Security
-           Extensions," RFC 2065, January 1997.
-
-   [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.
-
-Author's Address
-
-   Mark Andrews
-   CSIRO - Mathematical and Information Sciences
-   Locked Bag 17
-   North Ryde NSW 2113
-   AUSTRALIA
-
-   Phone: +61 2 9325 3148
-   EMail: Mark.Andrews@cmis.csiro.au
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Andrews                     Standards Track                    [Page 18]
-
-RFC 2308                       DNS NCACHE                     March 1998
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1998).  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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Andrews                     Standards Track                    [Page 19]
-
diff --git a/contrib/bind9/doc/rfc/rfc2317.txt b/contrib/bind9/doc/rfc/rfc2317.txt
deleted file mode 100644
index c17bb41..0000000
--- a/contrib/bind9/doc/rfc/rfc2317.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         H. Eidnes
-Request for Comments: 2317                                 SINTEF RUNIT
-BCP: 20                                                     G. de Groot
-Category: Best Current Practice          Berkeley Software Design, Inc.
-                                                               P. Vixie
-                                           Internet Software Consortium
-                                                             March 1998
-
-
-                   Classless IN-ADDR.ARPA delegation
-
-Status of this Memo
-
-   This document specifies an Internet Best Current Practices for the
-   Internet Community, and requests discussion and suggestions for
-   improvements.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-2. Introduction
-
-   This document describes a way to do IN-ADDR.ARPA delegation on non-
-   octet boundaries for address spaces covering fewer than 256
-   addresses.  The proposed method should thus remove one of the
-   objections to subnet on non-octet boundaries but perhaps more
-   significantly, make it possible to assign IP address space in smaller
-   chunks than 24-bit prefixes, without losing the ability to delegate
-   authority for the corresponding IN-ADDR.ARPA mappings.  The proposed
-   method is fully compatible with the original DNS lookup mechanisms
-   specified in [1], i.e. there is no need to modify the lookup
-   algorithm used, and there should be no need to modify any software
-   which does DNS lookups.
-
-   The document also discusses some operational considerations to
-   provide some guidance in implementing this method.
-
-3. Motivation
-
-   With the proliferation of classless routing technology, it has become
-   feasible to assign address space on non-octet boundaries.  In case of
-   a very small organization with only a few hosts, assigning a full
-   24-bit prefix (what was traditionally referred to as a "class C
-   network number") often leads to inefficient address space
-   utilization.
-
-
-
-
-
-Eidnes, et. al.          Best Current Practice                  [Page 1]
-
-RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
-
-
-   One of the problems encountered when assigning a longer prefix (less
-   address space) is that it seems impossible for such an organization
-   to maintain its own reverse ("IN-ADDR.ARPA") zone autonomously.  By
-   use of the reverse delegation method described below, the most
-   important objection to assignment of longer prefixes to unrelated
-   organizations can be removed.
-
-   Let us assume we have assigned the address spaces to three different
-   parties as follows:
-
-           192.0.2.0/25   to organization A
-           192.0.2.128/26 to organization B
-           192.0.2.192/26 to organization C
-
-   In the classical approach, this would lead to a single zone like
-   this:
-
-   $ORIGIN 2.0.192.in-addr.arpa.
-   ;
-   1               PTR     host1.A.domain.
-   2               PTR     host2.A.domain.
-   3               PTR     host3.A.domain.
-   ;
-   129             PTR     host1.B.domain.
-   130             PTR     host2.B.domain.
-   131             PTR     host3.B.domain.
-   ;
-   193             PTR     host1.C.domain.
-   194             PTR     host2.C.domain.
-   195             PTR     host3.C.domain.
-
-   The administration of this zone is problematic.  Authority for this
-   zone can only be delegated once, and this usually translates into
-   "this zone can only be administered by one organization."  The other
-   organizations with address space that corresponds to entries in this
-   zone would thus have to depend on another organization for their
-   address to name translation.  With the proposed method, this
-   potential problem can be avoided.
-
-4. Classless IN-ADDR.ARPA delegation
-
-   Since a single zone can only be delegated once, we need more points
-   to do delegation on to solve the problem above.  These extra points
-   of delegation can be introduced by extending the IN-ADDR.ARPA tree
-   downwards, e.g. by using the first address or the first address and
-   the network mask length (as shown below) in the corresponding address
-
-
-
-
-
-Eidnes, et. al.          Best Current Practice                  [Page 2]
-
-RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
-
-
-   space to form the the first component in the name for the zones.  The
-   following four zone files show how the problem in the motivation
-   section could be solved using this method.
-
-   $ORIGIN 2.0.192.in-addr.arpa.
-   @       IN      SOA     my-ns.my.domain. hostmaster.my.domain. (...)
-   ;...
-   ;  <<0-127>> /25
-   0/25            NS      ns.A.domain.
-   0/25            NS      some.other.name.server.
-   ;
-   1               CNAME   1.0/25.2.0.192.in-addr.arpa.
-   2               CNAME   2.0/25.2.0.192.in-addr.arpa.
-   3               CNAME   3.0/25.2.0.192.in-addr.arpa.
-   ;
-   ;  <<128-191>> /26
-   128/26          NS      ns.B.domain.
-   128/26          NS      some.other.name.server.too.
-   ;
-   129             CNAME   129.128/26.2.0.192.in-addr.arpa.
-   130             CNAME   130.128/26.2.0.192.in-addr.arpa.
-   131             CNAME   131.128/26.2.0.192.in-addr.arpa.
-   ;
-   ;  <<192-255>> /26
-   192/26          NS      ns.C.domain.
-   192/26          NS      some.other.third.name.server.
-   ;
-   193             CNAME   193.192/26.2.0.192.in-addr.arpa.
-   194             CNAME   194.192/26.2.0.192.in-addr.arpa.
-   195             CNAME   195.192/26.2.0.192.in-addr.arpa.
-
-   $ORIGIN 0/25.2.0.192.in-addr.arpa.
-   @       IN      SOA     ns.A.domain. hostmaster.A.domain. (...)
-   @               NS      ns.A.domain.
-   @               NS      some.other.name.server.
-   ;
-   1               PTR     host1.A.domain.
-   2               PTR     host2.A.domain.
-   3               PTR     host3.A.domain.
-
-
-
-
-
-
-
-
-
-
-
-
-Eidnes, et. al.          Best Current Practice                  [Page 3]
-
-RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
-
-
-   $ORIGIN 128/26.2.0.192.in-addr.arpa.
-   @       IN      SOA     ns.B.domain. hostmaster.B.domain. (...)
-   @               NS      ns.B.domain.
-   @               NS      some.other.name.server.too.
-   ;
-   129             PTR     host1.B.domain.
-   130             PTR     host2.B.domain.
-   131             PTR     host3.B.domain.
-
-
-   $ORIGIN 192/26.2.0.192.in-addr.arpa.
-   @       IN      SOA     ns.C.domain. hostmaster.C.domain. (...)
-   @               NS      ns.C.domain.
-   @               NS      some.other.third.name.server.
-   ;
-   193             PTR     host1.C.domain.
-   194             PTR     host2.C.domain.
-   195             PTR     host3.C.domain.
-
-   For each size-256 chunk split up using this method, there is a need
-   to install close to 256 CNAME records in the parent zone.  Some
-   people might view this as ugly; we will not argue that particular
-   point.  It is however quite easy to automatically generate the CNAME
-   resource records in the parent zone once and for all, if the way the
-   address space is partitioned is known.
-
-   The advantage of this approach over the other proposed approaches for
-   dealing with this problem is that there should be no need to modify
-   any already-deployed software.  In particular, the lookup mechanism
-   in the DNS does not have to be modified to accommodate this splitting
-   of the responsibility for the IPv4 address to name translation on
-   "non-dot" boundaries.  Furthermore, this technique has been in use
-   for several years in many installations, apparently with no ill
-   effects.
-
-   As usual, a resource record like
-
-   $ORIGIN 2.0.192.in-addr.arpa.
-   129             CNAME   129.128/26.2.0.192.in-addr.arpa.
-
-   can be convienently abbreviated to
-
-   $ORIGIN 2.0.192.in-addr.arpa.
-   129             CNAME   129.128/26
-
-
-
-
-
-
-
-Eidnes, et. al.          Best Current Practice                  [Page 4]
-
-RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
-
-
-   Some DNS implementations are not kind to special characters in domain
-   names, e.g. the "/" used in the above examples.  As [3] makes clear,
-   these are legal, though some might feel unsightly.  Because these are
-   not host names the restriction of [2] does not apply.  Modern clients
-   and servers have an option to act in the liberal and correct fashion.
-
-   The examples here use "/" because it was felt to be more visible and
-   pedantic reviewers felt that the 'these are not hostnames' argument
-   needed to be repeated.  We advise you not to be so pedantic, and to
-   not precisely copy the above examples, e.g.  substitute a more
-   conservative character, such as hyphen, for "/".
-
-5. Operational considerations
-
-   This technique is intended to be used for delegating address spaces
-   covering fewer than 256 addresses.  For delegations covering larger
-   blocks of addresses the traditional methods (multiple delegations)
-   can be used instead.
-
-5.1 Recommended secondary name service
-
-   Some older versions of name server software will make no effort to
-   find and return the pointed-to name in CNAME records if the pointed-
-   to name is not already known locally as cached or as authoritative
-   data.  This can cause some confusion in resolvers, as only the CNAME
-   record will be returned in the response.  To avoid this problem it is
-   recommended that the authoritative name servers for the delegating
-   zone (the zone containing all the CNAME records) all run as slave
-   (secondary) name servers for the "child" zones delegated and pointed
-   into via the CNAME records.
-
-5.2 Alternative naming conventions
-
-   As a result of this method, the location of the zone containing the
-   actual PTR records is no longer predefined.  This gives flexibility
-   and some examples will be presented here.
-
-   An alternative to using the first address, or the first address and
-   the network mask length in the corresponding address space, to name
-   the new zones is to use some other (non-numeric) name.  Thus it is
-   also possible to point to an entirely different part of the DNS tree
-   (i.e. outside of the IN-ADDR.ARPA tree).  It would be necessary to
-   use one of these alternate methods if two organizations somehow
-   shared the same physical subnet (and corresponding IP address space)
-   with no "neat" alignment of the addresses, but still wanted to
-   administrate their own IN-ADDR.ARPA mappings.
-
-
-
-
-
-Eidnes, et. al.          Best Current Practice                  [Page 5]
-
-RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
-
-
-   The following short example shows how you can point out of the IN-
-   ADDR.ARPA tree:
-
-   $ORIGIN 2.0.192.in-addr.arpa.
-   @       IN      SOA     my-ns.my.domain. hostmaster.my.domain. (...)
-   ; ...
-   1               CNAME   1.A.domain.
-   2               CNAME   2.A.domain.
-   ; ...
-   129             CNAME   129.B.domain.
-   130             CNAME   130.B.domain.
-   ;
-
-
-   $ORIGIN A.domain.
-   @       IN      SOA     my-ns.A.domain. hostmaster.A.domain. (...)
-   ; ...
-   ;
-   host1           A       192.0.2.1
-   1               PTR     host1
-   ;
-   host2           A       192.0.2.2
-   2               PTR     host2
-   ;
-
-   etc.
-
-   This way you can actually end up with the name->address and the
-   (pointed-to) address->name mapping data in the same zone file - some
-   may view this as an added bonus as no separate set of secondaries for
-   the reverse zone is required.  Do however note that the traversal via
-   the IN-ADDR.ARPA tree will still be done, so the CNAME records
-   inserted there need to point in the right direction for this to work.
-
-   Sketched below is an alternative approach using the same solution:
-
-   $ORIGIN 2.0.192.in-addr.arpa.
-   @                  SOA     my-ns.my.domain. hostmaster.my.domain. (...)
-   ; ...
-   1                  CNAME   1.2.0.192.in-addr.A.domain.
-   2                  CNAME   2.2.0.192.in-addr.A.domain.
-
-   $ORIGIN A.domain.
-   @                  SOA     my-ns.A.domain. hostmaster.A.domain. (...)
-   ; ...
-   ;
-   host1              A       192.0.2.1
-   1.2.0.192.in-addr  PTR     host1
-
-
-
-Eidnes, et. al.          Best Current Practice                  [Page 6]
-
-RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
-
-
-   host2              A       192.0.2.2
-   2.2.0.192.in-addr  PTR     host2
-
-   It is clear that many possibilities exist which can be adapted to the
-   specific requirements of the situation at hand.
-
-5.3 Other operational issues
-
-   Note that one cannot provide CNAME referrals twice for the same
-   address space, i.e. you cannot allocate a /25 prefix to one
-   organisation, and run IN-ADDR.ARPA this way, and then have the
-   organisation subnet the /25 into longer prefixes, and attempt to
-   employ the same technique to give each subnet control of its own
-   number space. This would result in a CNAME record pointing to a CNAME
-   record, which may be less robust overall.
-
-   Unfortunately, some old beta releases of the popular DNS name server
-   implementation BIND 4.9.3 had a bug which caused problems if a CNAME
-   record was encountered when a reverse lookup was made.  The beta
-   releases involved have since been obsoleted, and this issue is
-   resolved in the released code.  Some software manufacturers have
-   included the defective beta code in their product. In the few cases
-   we know of, patches from the manufacturers are available or planned
-   to replace the obsolete beta code involved.
-
-6. Security Considerations
-
-   With this scheme, the "leaf sites" will need to rely on one more site
-   running their DNS name service correctly than they would be if they
-   had a /24 allocation of their own, and this may add an extra
-   component which will need to work for reliable name resolution.
-
-   Other than that, the authors are not aware of any additional security
-   issues introduced by this mechanism.
-
-7. Conclusion
-
-   The suggested scheme gives more flexibility in delegating authority
-   in the IN-ADDR.ARPA domain, thus making it possible to assign address
-   space more efficiently without losing the ability to delegate the DNS
-   authority over the corresponding address to name mappings.
-
-8. Acknowledgments
-
-   Glen A. Herrmannsfeldt described this trick on comp.protocols.tcp-
-   ip.domains some time ago.  Alan Barrett and Sam Wilson provided
-   valuable comments on the newsgroup.
-
-
-
-
-Eidnes, et. al.          Best Current Practice                  [Page 7]
-
-RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
-
-
-   We would like to thank Rob Austein, Randy Bush, Matt Crawford, Robert
-   Elz, Glen A. Herrmannsfeldt, Daniel Karrenberg, David Kessens, Tony
-   Li, Paul Mockapetris, Eric Wassenaar, Michael Patton, Hans Maurer,
-   and Peter Koch for their review and constructive comments.
-
-9. References
-
-   [1]  Mockapetris, P., "Domain Names - Concepts and Facilities",
-        STD 13, RFC 1034, November 1987.
-
-   [2]  Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet Host
-        Table Specification", RFC 952, October 1985.
-
-   [3]  Elz, R., and R. Bush, "Clarifications to the DNS
-        Specification", RFC 2181, July 1997.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eidnes, et. al.          Best Current Practice                  [Page 8]
-
-RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
-
-
-10. Authors' Addresses
-
-   Havard Eidnes
-   SINTEF RUNIT
-   N-7034 Trondheim
-   Norway
-
-   Phone: +47 73 59 44 68
-   Fax: +47 73 59 17 00
-   EMail: Havard.Eidnes@runit.sintef.no
-
-
-   Geert Jan de Groot
-   Berkeley Software Design, Inc. (BSDI)
-   Hendrik Staetslaan 69
-   5622 HM Eindhoven
-   The Netherlands
-
-   Phone: +31 40 2960509
-   Fax:   +31 40 2960309
-   EMail: GeertJan.deGroot@bsdi.com
-
-
-   Paul Vixie
-   Internet Software Consortium
-   Star Route Box 159A
-   Woodside, CA 94062
-   USA
-
-   Phone: +1 415 747 0204
-   EMail: paul@vix.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eidnes, et. al.          Best Current Practice                  [Page 9]
-
-RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
-
-
-11.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (1998).  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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eidnes, et. al.          Best Current Practice                 [Page 10]
-
diff --git a/contrib/bind9/doc/rfc/rfc2373.txt b/contrib/bind9/doc/rfc/rfc2373.txt
deleted file mode 100644
index 59fcff8..0000000
--- a/contrib/bind9/doc/rfc/rfc2373.txt
+++ /dev/null
@@ -1,1459 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        R. Hinden
-Request for Comments: 2373                                       Nokia
-Obsoletes: 1884                                             S. Deering
-Category: Standards Track                                Cisco Systems
-							     July 1998
-
-                  IP Version 6 Addressing Architecture
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-Abstract
-
-   This specification defines the addressing architecture of the IP
-   Version 6 protocol [IPV6].  The document includes the IPv6 addressing
-   model, text representations of IPv6 addresses, definition of IPv6
-   unicast addresses, anycast addresses, and multicast addresses, and an
-   IPv6 node's required addresses.
-
-Table of Contents
-
-   1. Introduction.................................................2
-   2. IPv6 Addressing..............................................2
-      2.1 Addressing Model.........................................3
-      2.2 Text Representation of Addresses.........................3
-      2.3 Text Representation of Address Prefixes..................5
-      2.4 Address Type Representation..............................6
-      2.5 Unicast Addresses........................................7
-        2.5.1 Interface Identifiers................................8
-        2.5.2 The Unspecified Address..............................9
-        2.5.3 The Loopback Address.................................9
-        2.5.4 IPv6 Addresses with Embedded IPv4 Addresses.........10
-        2.5.5 NSAP Addresses......................................10
-        2.5.6 IPX Addresses.......................................10
-        2.5.7 Aggregatable Global Unicast Addresses...............11
-        2.5.8 Local-use IPv6 Unicast Addresses....................11
-      2.6 Anycast Addresses.......................................12
-        2.6.1 Required Anycast Address............................13
-      2.7 Multicast Addresses.....................................14
-
-
-
-Hinden & Deering            Standards Track                     [Page 1]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-        2.7.1 Pre-Defined Multicast Addresses.....................15
-        2.7.2 Assignment of New IPv6 Multicast Addresses..........17
-      2.8 A Node's Required Addresses.............................17
-   3. Security Considerations.....................................18
-   APPENDIX A: Creating EUI-64 based Interface Identifiers........19
-   APPENDIX B: ABNF Description of Text Representations...........22
-   APPENDIX C: CHANGES FROM RFC-1884..............................23
-   REFERENCES.....................................................24
-   AUTHORS' ADDRESSES.............................................25
-   FULL COPYRIGHT STATEMENT.......................................26
-
-
-1.0 INTRODUCTION
-
-   This specification defines the addressing architecture of the IP
-   Version 6 protocol.  It includes a detailed description of the
-   currently defined address formats for IPv6 [IPV6].
-
-   The authors would like to acknowledge the contributions of Paul
-   Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford,
-   Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan,
-   Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg
-   Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson,
-   and Sue Thomson.
-
-   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.0 IPv6 ADDRESSING
-
-   IPv6 addresses are 128-bit identifiers for interfaces and sets of
-   interfaces.  There are three types of addresses:
-
-     Unicast:   An identifier for a single interface.  A packet sent to
-                a unicast address is delivered to the interface
-                identified by that address.
-
-     Anycast:   An identifier for a set of interfaces (typically
-                belonging to different nodes).  A packet sent to an
-                anycast address is delivered to one of the interfaces
-                identified by that address (the "nearest" one, according
-                to the routing protocols' measure of distance).
-
-     Multicast: An identifier for a set of interfaces (typically
-                belonging to different nodes).  A packet sent to a
-                multicast address is delivered to all interfaces
-                identified by that address.
-
-
-
-Hinden & Deering            Standards Track                     [Page 2]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-   There are no broadcast addresses in IPv6, their function being
-   superseded by multicast addresses.
-
-   In this document, fields in addresses are given a specific name, for
-   example "subscriber".  When this name is used with the term "ID" for
-   identifier after the name (e.g., "subscriber ID"), it refers to the
-   contents of the named field.  When it is used with the term "prefix"
-   (e.g.  "subscriber prefix") it refers to all of the address up to and
-   including this field.
-
-   In IPv6, all zeros and all ones are legal values for any field,
-   unless specifically excluded.  Specifically, prefixes may contain
-   zero-valued fields or end in zeros.
-
-2.1 Addressing Model
-
-   IPv6 addresses of all types are assigned to interfaces, not nodes.
-   An IPv6 unicast address refers to a single interface.  Since each
-   interface belongs to a single node, any of that node's interfaces'
-   unicast addresses may be used as an identifier for the node.
-
-   All interfaces are required to have at least one link-local unicast
-   address (see section 2.8 for additional required addresses).  A
-   single interface may also be assigned multiple IPv6 addresses of any
-   type (unicast, anycast, and multicast) or scope.  Unicast addresses
-   with scope greater than link-scope are not needed for interfaces that
-   are not used as the origin or destination of any IPv6 packets to or
-   from non-neighbors.  This is sometimes convenient for point-to-point
-   interfaces.  There is one exception to this addressing model:
-
-     An unicast address or a set of unicast addresses may be assigned to
-     multiple physical interfaces if the implementation treats the
-     multiple physical interfaces as one interface when presenting it to
-     the internet layer.  This is useful for load-sharing over multiple
-     physical interfaces.
-
-   Currently IPv6 continues the IPv4 model that a subnet prefix is
-   associated with one link.  Multiple subnet prefixes may be assigned
-   to the same link.
-
-2.2 Text Representation of Addresses
-
-   There are three conventional forms for representing IPv6 addresses as
-   text strings:
-
-   1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the
-      hexadecimal values of the eight 16-bit pieces of the address.
-      Examples:
-
-
-
-Hinden & Deering            Standards Track                     [Page 3]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-         FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
-
-         1080:0:0:0:8:800:200C:417A
-
-      Note that it is not necessary to write the leading zeros in an
-      individual field, but there must be at least one numeral in every
-      field (except for the case described in 2.).
-
-   2. Due to some methods of allocating certain styles of IPv6
-      addresses, it will be common for addresses to contain long strings
-      of zero bits.  In order to make writing addresses containing zero
-      bits easier a special syntax is available to compress the zeros.
-      The use of "::" indicates multiple groups of 16-bits of zeros.
-      The "::" can only appear once in an address.  The "::" can also be
-      used to compress the leading and/or trailing zeros in an address.
-
-      For example the following addresses:
-
-         1080:0:0:0:8:800:200C:417A  a unicast address
-         FF01:0:0:0:0:0:0:101        a multicast address
-         0:0:0:0:0:0:0:1             the loopback address
-         0:0:0:0:0:0:0:0             the unspecified addresses
-
-      may be represented as:
-
-         1080::8:800:200C:417A       a unicast address
-         FF01::101                   a multicast address
-         ::1                         the loopback address
-         ::                          the unspecified addresses
-
-   3. An alternative form that is sometimes more convenient when dealing
-      with a mixed environment of IPv4 and IPv6 nodes is
-      x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of
-      the six high-order 16-bit pieces of the address, and the 'd's are
-      the decimal values of the four low-order 8-bit pieces of the
-      address (standard IPv4 representation).  Examples:
-
-         0:0:0:0:0:0:13.1.68.3
-
-         0:0:0:0:0:FFFF:129.144.52.38
-
-      or in compressed form:
-
-         ::13.1.68.3
-
-         ::FFFF:129.144.52.38
-
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 4]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-2.3 Text Representation of Address Prefixes
-
-   The text representation of IPv6 address prefixes is similar to the
-   way IPv4 addresses prefixes are written in CIDR notation.  An IPv6
-   address prefix is represented by the notation:
-
-      ipv6-address/prefix-length
-
-   where
-
-      ipv6-address    is an IPv6 address in any of the notations listed
-                      in section 2.2.
-
-      prefix-length   is a decimal value specifying how many of the
-                      leftmost contiguous bits of the address comprise
-                      the prefix.
-
-   For example, the following are legal representations of the 60-bit
-   prefix 12AB00000000CD3 (hexadecimal):
-
-      12AB:0000:0000:CD30:0000:0000:0000:0000/60
-      12AB::CD30:0:0:0:0/60
-      12AB:0:0:CD30::/60
-
-   The following are NOT legal representations of the above prefix:
-
-      12AB:0:0:CD3/60   may drop leading zeros, but not trailing zeros,
-                        within any 16-bit chunk of the address
-
-      12AB::CD30/60     address to left of "/" expands to
-                        12AB:0000:0000:0000:0000:000:0000:CD30
-
-      12AB::CD3/60      address to left of "/" expands to
-                        12AB:0000:0000:0000:0000:000:0000:0CD3
-
-   When writing both a node address and a prefix of that node address
-   (e.g., the node's subnet prefix), the two can combined as follows:
-
-      the node address      12AB:0:0:CD30:123:4567:89AB:CDEF
-      and its subnet number 12AB:0:0:CD30::/60
-
-      can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 5]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-2.4 Address Type Representation
-
-   The specific type of an IPv6 address is indicated by the leading bits
-   in the address.  The variable-length field comprising these leading
-   bits is called the Format Prefix (FP).  The initial allocation of
-   these prefixes is as follows:
-
-    Allocation                            Prefix         Fraction of
-                                          (binary)       Address Space
-    -----------------------------------   --------       -------------
-    Reserved                              0000 0000      1/256
-    Unassigned                            0000 0001      1/256
-
-    Reserved for NSAP Allocation          0000 001       1/128
-    Reserved for IPX Allocation           0000 010       1/128
-
-    Unassigned                            0000 011       1/128
-    Unassigned                            0000 1         1/32
-    Unassigned                            0001           1/16
-
-    Aggregatable Global Unicast Addresses 001            1/8
-    Unassigned                            010            1/8
-    Unassigned                            011            1/8
-    Unassigned                            100            1/8
-    Unassigned                            101            1/8
-    Unassigned                            110            1/8
-
-    Unassigned                            1110           1/16
-    Unassigned                            1111 0         1/32
-    Unassigned                            1111 10        1/64
-    Unassigned                            1111 110       1/128
-    Unassigned                            1111 1110 0    1/512
-
-    Link-Local Unicast Addresses          1111 1110 10   1/1024
-    Site-Local Unicast Addresses          1111 1110 11   1/1024
-
-    Multicast Addresses                   1111 1111      1/256
-
-    Notes:
-
-      (1) The "unspecified address" (see section 2.5.2), the loopback
-          address (see section 2.5.3), and the IPv6 Addresses with
-          Embedded IPv4 Addresses (see section 2.5.4), are assigned out
-          of the 0000 0000 format prefix space.
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 6]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-      (2) The format prefixes 001 through 111, except for Multicast
-          Addresses (1111 1111), are all required to have to have 64-bit
-          interface identifiers in EUI-64 format.  See section 2.5.1 for
-          definitions.
-
-   This allocation supports the direct allocation of aggregation
-   addresses, local use addresses, and multicast addresses.  Space is
-   reserved for NSAP addresses and IPX addresses.  The remainder of the
-   address space is unassigned for future use.  This can be used for
-   expansion of existing use (e.g., additional aggregatable addresses,
-   etc.) or new uses (e.g., separate locators and identifiers).  Fifteen
-   percent of the address space is initially allocated.  The remaining
-   85% is reserved for future use.
-
-   Unicast addresses are distinguished from multicast addresses by the
-   value of the high-order octet of the addresses: a value of FF
-   (11111111) identifies an address as a multicast address; any other
-   value identifies an address as a unicast address.  Anycast addresses
-   are taken from the unicast address space, and are not syntactically
-   distinguishable from unicast addresses.
-
-2.5 Unicast Addresses
-
-   IPv6 unicast addresses are aggregatable with contiguous bit-wise
-   masks similar to IPv4 addresses under Class-less Interdomain Routing
-   [CIDR].
-
-   There are several forms of unicast address assignment in IPv6,
-   including the global aggregatable global unicast address, the NSAP
-   address, the IPX hierarchical address, the site-local address, the
-   link-local address, and the IPv4-capable host address.  Additional
-   address types can be defined in the future.
-
-   IPv6 nodes may have considerable or little knowledge of the internal
-   structure of the IPv6 address, depending on the role the node plays
-   (for instance, host versus router).  At a minimum, a node may
-   consider that unicast addresses (including its own) have no internal
-   structure:
-
-   |                           128 bits                              |
-   +-----------------------------------------------------------------+
-   |                          node address                           |
-   +-----------------------------------------------------------------+
-
-   A slightly sophisticated host (but still rather simple) may
-   additionally be aware of subnet prefix(es) for the link(s) it is
-   attached to, where different addresses may have different values for
-   n:
-
-
-
-Hinden & Deering            Standards Track                     [Page 7]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-   |                         n bits                 |   128-n bits   |
-   +------------------------------------------------+----------------+
-   |                   subnet prefix                | interface ID   |
-   +------------------------------------------------+----------------+
-
-   Still more sophisticated hosts may be aware of other hierarchical
-   boundaries in the unicast address.  Though a very simple router may
-   have no knowledge of the internal structure of IPv6 unicast
-   addresses, routers will more generally have knowledge of one or more
-   of the hierarchical boundaries for the operation of routing
-   protocols.  The known boundaries will differ from router to router,
-   depending on what positions the router holds in the routing
-   hierarchy.
-
-2.5.1 Interface Identifiers
-
-   Interface identifiers in IPv6 unicast addresses are used to identify
-   interfaces on a link.  They are required to be unique on that link.
-   They may also be unique over a broader scope.  In many cases an
-   interface's identifier will be the same as that interface's link-
-   layer address.  The same interface identifier may be used on multiple
-   interfaces on a single node.
-
-   Note that the use of the same interface identifier on multiple
-   interfaces of a single node does not affect the interface
-   identifier's global uniqueness or each IPv6 addresses global
-   uniqueness created using that interface identifier.
-
-   In a number of the format prefixes (see section 2.4) Interface IDs
-   are required to be 64 bits long and to be constructed in IEEE EUI-64
-   format [EUI64].  EUI-64 based Interface identifiers may have global
-   scope when a global token is available (e.g., IEEE 48bit MAC) or may
-   have local scope where a global token is not available (e.g., serial
-   links, tunnel end-points, etc.).  It is required that the "u" bit
-   (universal/local bit in IEEE EUI-64 terminology) be inverted when
-   forming the interface identifier from the EUI-64.  The "u" bit is set
-   to one (1) to indicate global scope, and it is set to zero (0) to
-   indicate local scope.  The first three octets in binary of an EUI-64
-   identifier are as follows:
-
-       0       0 0       1 1       2
-      |0       7 8       5 6       3|
-      +----+----+----+----+----+----+
-      |cccc|ccug|cccc|cccc|cccc|cccc|
-      +----+----+----+----+----+----+
-
-
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 8]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-   written in Internet standard bit-order , where "u" is the
-   universal/local bit, "g" is the individual/group bit, and "c" are the
-   bits of the company_id.  Appendix A: "Creating EUI-64 based Interface
-   Identifiers" provides examples on the creation of different EUI-64
-   based interface identifiers.
-
-   The motivation for inverting the "u" bit when forming the interface
-   identifier is to make it easy for system administrators to hand
-   configure local scope identifiers when hardware tokens are not
-   available.  This is expected to be case for serial links, tunnel end-
-   points, etc.  The alternative would have been for these to be of the
-   form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler ::1,
-   ::2, etc.
-
-   The use of the universal/local bit in the IEEE EUI-64 identifier is
-   to allow development of future technology that can take advantage of
-   interface identifiers with global scope.
-
-   The details of forming interface identifiers are defined in the
-   appropriate "IPv6 over <link>" specification such as "IPv6 over
-   Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
-
-2.5.2 The Unspecified Address
-
-   The address 0:0:0:0:0:0:0:0 is called the unspecified address.  It
-   must never be assigned to any node.  It indicates the absence of an
-   address.  One example of its use is in the Source Address field of
-   any IPv6 packets sent by an initializing host before it has learned
-   its own address.
-
-   The unspecified address must not be used as the destination address
-   of IPv6 packets or in IPv6 Routing Headers.
-
-2.5.3 The Loopback Address
-
-   The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
-   It may be used by a node to send an IPv6 packet to itself.  It may
-   never be assigned to any physical interface.  It may be thought of as
-   being associated with a virtual interface (e.g., the loopback
-   interface).
-
-   The loopback address must not be used as the source address in IPv6
-   packets that are sent outside of a single node.  An IPv6 packet with
-   a destination address of loopback must never be sent outside of a
-   single node and must never be forwarded by an IPv6 router.
-
-
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 9]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-2.5.4 IPv6 Addresses with Embedded IPv4 Addresses
-
-   The IPv6 transition mechanisms [TRAN] include a technique for hosts
-   and routers to dynamically tunnel IPv6 packets over IPv4 routing
-   infrastructure.  IPv6 nodes that utilize this technique are assigned
-   special IPv6 unicast addresses that carry an IPv4 address in the low-
-   order 32-bits.  This type of address is termed an "IPv4-compatible
-   IPv6 address" and has the format:
-
-   |                80 bits               | 16 |      32 bits        |
-   +--------------------------------------+--------------------------+
-   |0000..............................0000|0000|    IPv4 address     |
-   +--------------------------------------+----+---------------------+
-
-   A second type of IPv6 address which holds an embedded IPv4 address is
-   also defined.  This address is used to represent the addresses of
-   IPv4-only nodes (those that *do not* support IPv6) as IPv6 addresses.
-   This type of address is termed an "IPv4-mapped IPv6 address" and has
-   the format:
-
-   |                80 bits               | 16 |      32 bits        |
-   +--------------------------------------+--------------------------+
-   |0000..............................0000|FFFF|    IPv4 address     |
-   +--------------------------------------+----+---------------------+
-
-2.5.5 NSAP Addresses
-
-   This mapping of NSAP address into IPv6 addresses is defined in
-   [NSAP].  This document recommends that network implementors who have
-   planned or deployed an OSI NSAP addressing plan, and who wish to
-   deploy or transition to IPv6, should redesign a native IPv6
-   addressing plan to meet their needs.  However, it also defines a set
-   of mechanisms for the support of OSI NSAP addressing in an IPv6
-   network.  These mechanisms are the ones that must be used if such
-   support is required.  This document also defines a mapping of IPv6
-   addresses within the OSI address format, should this be required.
-
-2.5.6 IPX Addresses
-
-   This mapping of IPX address into IPv6 addresses is as follows:
-
-   |   7   |                   121 bits                              |
-   +-------+---------------------------------------------------------+
-   |0000010|                 to be defined                           |
-   +-------+---------------------------------------------------------+
-
-   The draft definition, motivation, and usage are under study.
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 10]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-2.5.7 Aggregatable Global Unicast Addresses
-
-   The global aggregatable global unicast address is defined in [AGGR].
-   This address format is designed to support both the current provider
-   based aggregation and a new type of aggregation called exchanges.
-   The combination will allow efficient routing aggregation for both
-   sites which connect directly to providers and who connect to
-   exchanges.  Sites will have the choice to connect to either type of
-   aggregation point.
-
-   The IPv6 aggregatable global unicast address format is as follows:
-
-   | 3|  13 | 8 |   24   |   16   |          64 bits               |
-   +--+-----+---+--------+--------+--------------------------------+
-   |FP| TLA |RES|  NLA   |  SLA   |         Interface ID           |
-   |  | ID  |   |  ID    |  ID    |                                |
-   +--+-----+---+--------+--------+--------------------------------+
-
-   Where
-
-      001          Format Prefix (3 bit) for Aggregatable Global
-                   Unicast Addresses
-      TLA ID       Top-Level Aggregation Identifier
-      RES          Reserved for future use
-      NLA ID       Next-Level Aggregation Identifier
-      SLA ID       Site-Level Aggregation Identifier
-      INTERFACE ID Interface Identifier
-
-   The contents, field sizes, and assignment rules are defined in
-   [AGGR].
-
-2.5.8 Local-Use IPv6 Unicast Addresses
-
-   There are two types of local-use unicast addresses defined.  These
-   are Link-Local and Site-Local.  The Link-Local is for use on a single
-   link and the Site-Local is for use in a single site.  Link-Local
-   addresses have the following format:
-
-   |   10     |
-   |  bits    |        54 bits          |          64 bits           |
-   +----------+-------------------------+----------------------------+
-   |1111111010|           0             |       interface ID         |
-   +----------+-------------------------+----------------------------+
-
-   Link-Local addresses are designed to be used for addressing on a
-   single link for purposes such as auto-address configuration, neighbor
-   discovery, or when no routers are present.
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 11]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-   Routers must not forward any packets with link-local source or
-   destination addresses to other links.
-
-   Site-Local addresses have the following format:
-
-   |   10     |
-   |  bits    |   38 bits   |  16 bits  |         64 bits            |
-   +----------+-------------+-----------+----------------------------+
-   |1111111011|    0        | subnet ID |       interface ID         |
-   +----------+-------------+-----------+----------------------------+
-
-   Site-Local addresses are designed to be used for addressing inside of
-   a site without the need for a global prefix.
-
-   Routers must not forward any packets with site-local source or
-   destination addresses outside of the site.
-
-2.6 Anycast Addresses
-
-   An IPv6 anycast address is an address that is assigned to more than
-   one interface (typically belonging to different nodes), with the
-   property that a packet sent to an anycast address is routed to the
-   "nearest" interface having that address, according to the routing
-   protocols' measure of distance.
-
-   Anycast addresses are allocated from the unicast address space, using
-   any of the defined unicast address formats.  Thus, anycast addresses
-   are syntactically indistinguishable from unicast addresses.  When a
-   unicast address is assigned to more than one interface, thus turning
-   it into an anycast address, the nodes to which the address is
-   assigned must be explicitly configured to know that it is an anycast
-   address.
-
-   For any assigned anycast address, there is a longest address prefix P
-   that identifies the topological region in which all interfaces
-   belonging to that anycast address reside.  Within the region
-   identified by P, each member of the anycast set must be advertised as
-   a separate entry in the routing system (commonly referred to as a
-   "host route"); outside the region identified by P, the anycast
-   address may be aggregated into the routing advertisement for prefix
-   P.
-
-   Note that in, the worst case, the prefix P of an anycast set may be
-   the null prefix, i.e., the members of the set may have no topological
-   locality.  In that case, the anycast address must be advertised as a
-   separate routing entry throughout the entire internet, which presents
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 12]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-   a severe scaling limit on how many such "global" anycast sets may be
-   supported.  Therefore, it is expected that support for global anycast
-   sets may be unavailable or very restricted.
-
-   One expected use of anycast addresses is to identify the set of
-   routers belonging to an organization providing internet service.
-   Such addresses could be used as intermediate addresses in an IPv6
-   Routing header, to cause a packet to be delivered via a particular
-   aggregation or sequence of aggregations.  Some other possible uses
-   are to identify the set of routers attached to a particular subnet,
-   or the set of routers providing entry into a particular routing
-   domain.
-
-   There is little experience with widespread, arbitrary use of internet
-   anycast addresses, and some known complications and hazards when
-   using them in their full generality [ANYCST].  Until more experience
-   has been gained and solutions agreed upon for those problems, the
-   following restrictions are imposed on IPv6 anycast addresses:
-
-      o An anycast address must not be used as the source address of an
-        IPv6 packet.
-
-      o An anycast address must not be assigned to an IPv6 host, that
-        is, it may be assigned to an IPv6 router only.
-
-2.6.1 Required Anycast Address
-
-   The Subnet-Router anycast address is predefined.  Its format is as
-   follows:
-
-   |                         n bits                 |   128-n bits   |
-   +------------------------------------------------+----------------+
-   |                   subnet prefix                | 00000000000000 |
-   +------------------------------------------------+----------------+
-
-   The "subnet prefix" in an anycast address is the prefix which
-   identifies a specific link.  This anycast address is syntactically
-   the same as a unicast address for an interface on the link with the
-   interface identifier set to zero.
-
-   Packets sent to the Subnet-Router anycast address will be delivered
-   to one router on the subnet.  All routers are required to support the
-   Subnet-Router anycast addresses for the subnets which they have
-   interfaces.
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 13]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-   The subnet-router anycast address is intended to be used for
-   applications where a node needs to communicate with one of a set of
-   routers on a remote subnet.  For example when a mobile host needs to
-   communicate with one of the mobile agents on its "home" subnet.
-
-2.7 Multicast Addresses
-
-   An IPv6 multicast address is an identifier for a group of nodes.  A
-   node may belong to any number of multicast groups.  Multicast
-   addresses have the following format:
-
-   |   8    |  4 |  4 |                  112 bits                   |
-   +------ -+----+----+---------------------------------------------+
-   |11111111|flgs|scop|                  group ID                   |
-   +--------+----+----+---------------------------------------------+
-
-      11111111 at the start of the address identifies the address as
-      being a multicast address.
-
-                                    +-+-+-+-+
-      flgs is a set of 4 flags:     |0|0|0|T|
-                                    +-+-+-+-+
-
-         The high-order 3 flags are reserved, and must be initialized to
-         0.
-
-         T = 0 indicates a permanently-assigned ("well-known") multicast
-         address, assigned by the global internet numbering authority.
-
-         T = 1 indicates a non-permanently-assigned ("transient")
-         multicast address.
-
-      scop is a 4-bit multicast scope value used to limit the scope of
-      the multicast group.  The values are:
-
-         0  reserved
-         1  node-local scope
-         2  link-local scope
-         3  (unassigned)
-         4  (unassigned)
-         5  site-local scope
-         6  (unassigned)
-         7  (unassigned)
-         8  organization-local scope
-         9  (unassigned)
-         A  (unassigned)
-         B  (unassigned)
-         C  (unassigned)
-
-
-
-Hinden & Deering            Standards Track                    [Page 14]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-         D  (unassigned)
-         E  global scope
-         F  reserved
-
-      group ID identifies the multicast group, either permanent or
-      transient, within the given scope.
-
-   The "meaning" of a permanently-assigned multicast address is
-   independent of the scope value.  For example, if the "NTP servers
-   group" is assigned a permanent multicast address with a group ID of
-   101 (hex), then:
-
-      FF01:0:0:0:0:0:0:101 means all NTP servers on the same node as the
-      sender.
-
-      FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as the
-      sender.
-
-      FF05:0:0:0:0:0:0:101 means all NTP servers at the same site as the
-      sender.
-
-      FF0E:0:0:0:0:0:0:101 means all NTP servers in the internet.
-
-   Non-permanently-assigned multicast addresses are meaningful only
-   within a given scope.  For example, a group identified by the non-
-   permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one
-   site bears no relationship to a group using the same address at a
-   different site, nor to a non-permanent group using the same group ID
-   with different scope, nor to a permanent group with the same group
-   ID.
-
-   Multicast addresses must not be used as source addresses in IPv6
-   packets or appear in any routing header.
-
-2.7.1 Pre-Defined Multicast Addresses
-
-   The following well-known multicast addresses are pre-defined:
-
-      Reserved Multicast Addresses:   FF00:0:0:0:0:0:0:0
-                                      FF01:0:0:0:0:0:0:0
-                                      FF02:0:0:0:0:0:0:0
-                                      FF03:0:0:0:0:0:0:0
-                                      FF04:0:0:0:0:0:0:0
-                                      FF05:0:0:0:0:0:0:0
-                                      FF06:0:0:0:0:0:0:0
-                                      FF07:0:0:0:0:0:0:0
-                                      FF08:0:0:0:0:0:0:0
-                                      FF09:0:0:0:0:0:0:0
-
-
-
-Hinden & Deering            Standards Track                    [Page 15]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-                                      FF0A:0:0:0:0:0:0:0
-                                      FF0B:0:0:0:0:0:0:0
-                                      FF0C:0:0:0:0:0:0:0
-                                      FF0D:0:0:0:0:0:0:0
-                                      FF0E:0:0:0:0:0:0:0
-                                      FF0F:0:0:0:0:0:0:0
-
-   The above multicast addresses are reserved and shall never be
-   assigned to any multicast group.
-
-      All Nodes Addresses:    FF01:0:0:0:0:0:0:1
-                              FF02:0:0:0:0:0:0:1
-
-   The above multicast addresses identify the group of all IPv6 nodes,
-   within scope 1 (node-local) or 2 (link-local).
-
-      All Routers Addresses:   FF01:0:0:0:0:0:0:2
-                               FF02:0:0:0:0:0:0:2
-                               FF05:0:0:0:0:0:0:2
-
-   The above multicast addresses identify the group of all IPv6 routers,
-   within scope 1 (node-local), 2 (link-local), or 5 (site-local).
-
-      Solicited-Node Address:  FF02:0:0:0:0:1:FFXX:XXXX
-
-   The above multicast address is computed as a function of a node's
-   unicast and anycast addresses.  The solicited-node multicast address
-   is formed by taking the low-order 24 bits of the address (unicast or
-   anycast) and appending those bits to the prefix
-   FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the
-   range
-
-      FF02:0:0:0:0:1:FF00:0000
-
-   to
-
-      FF02:0:0:0:0:1:FFFF:FFFF
-
-   For example, the solicited node multicast address corresponding to
-   the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C.  IPv6
-   addresses that differ only in the high-order bits, e.g. due to
-   multiple high-order prefixes associated with different aggregations,
-   will map to the same solicited-node address thereby reducing the
-   number of multicast addresses a node must join.
-
-   A node is required to compute and join the associated Solicited-Node
-   multicast addresses for every unicast and anycast address it is
-   assigned.
-
-
-
-Hinden & Deering            Standards Track                    [Page 16]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-2.7.2 Assignment of New IPv6 Multicast Addresses
-
-   The current approach [ETHER] to map IPv6 multicast addresses into
-   IEEE 802 MAC addresses takes the low order 32 bits of the IPv6
-   multicast address and uses it to create a MAC address.  Note that
-   Token Ring networks are handled differently.  This is defined in
-   [TOKEN].  Group ID's less than or equal to 32 bits will generate
-   unique MAC addresses.  Due to this new IPv6 multicast addresses
-   should be assigned so that the group identifier is always in the low
-   order 32 bits as shown in the following:
-
-   |   8    |  4 |  4 |          80 bits          |     32 bits     |
-   +------ -+----+----+---------------------------+-----------------+
-   |11111111|flgs|scop|   reserved must be zero   |    group ID     |
-   +--------+----+----+---------------------------+-----------------+
-
-   While this limits the number of permanent IPv6 multicast groups to
-   2^32 this is unlikely to be a limitation in the future.  If it
-   becomes necessary to exceed this limit in the future multicast will
-   still work but the processing will be sightly slower.
-
-   Additional IPv6 multicast addresses are defined and registered by the
-   IANA [MASGN].
-
-2.8 A Node's Required Addresses
-
-   A host is required to recognize the following addresses as
-   identifying itself:
-
-      o Its Link-Local Address for each interface
-      o Assigned Unicast Addresses
-      o Loopback Address
-      o All-Nodes Multicast Addresses
-      o Solicited-Node Multicast Address for each of its assigned
-        unicast and anycast addresses
-      o Multicast Addresses of all other groups to which the host
-        belongs.
-
-   A router is required to recognize all addresses that a host is
-   required to recognize, plus the following addresses as identifying
-   itself:
-
-      o The Subnet-Router anycast addresses for the interfaces it is
-        configured to act as a router on.
-      o All other Anycast addresses with which the router has been
-        configured.
-      o All-Routers Multicast Addresses
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 17]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-      o Multicast Addresses of all other groups to which the router
-        belongs.
-
-   The only address prefixes which should be predefined in an
-   implementation are the:
-
-      o Unspecified Address
-      o Loopback Address
-      o Multicast Prefix (FF)
-      o Local-Use Prefixes (Link-Local and Site-Local)
-      o Pre-Defined Multicast Addresses
-      o IPv4-Compatible Prefixes
-
-   Implementations should assume all other addresses are unicast unless
-   specifically configured (e.g., anycast addresses).
-
-3. Security Considerations
-
-   IPv6 addressing documents do not have any direct impact on Internet
-   infrastructure security.  Authentication of IPv6 packets is defined
-   in [AUTH].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 18]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-APPENDIX A : Creating EUI-64 based Interface Identifiers
---------------------------------------------------------
-
-   Depending on the characteristics of a specific link or node there are
-   a number of approaches for creating EUI-64 based interface
-   identifiers.  This appendix describes some of these approaches.
-
-Links or Nodes with EUI-64 Identifiers
-
-   The only change needed to transform an EUI-64 identifier to an
-   interface identifier is to invert the "u" (universal/local) bit.  For
-   example, a globally unique EUI-64 identifier of the form:
-
-   |0              1|1              3|3              4|4              6|
-   |0              5|6              1|2              7|8              3|
-   +----------------+----------------+----------------+----------------+
-   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
-   +----------------+----------------+----------------+----------------+
-
-   where "c" are the bits of the assigned company_id, "0" is the value
-   of the universal/local bit to indicate global scope, "g" is
-   individual/group bit, and "m" are the bits of the manufacturer-
-   selected extension identifier.  The IPv6 interface identifier would
-   be of the form:
-
-   |0              1|1              3|3              4|4              6|
-   |0              5|6              1|2              7|8              3|
-   +----------------+----------------+----------------+----------------+
-   |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
-   +----------------+----------------+----------------+----------------+
-
-   The only change is inverting the value of the universal/local bit.
-
-Links or Nodes with IEEE 802 48 bit MAC's
-
-   [EUI64] defines a method to create a EUI-64 identifier from an IEEE
-   48bit MAC identifier.  This is to insert two octets, with hexadecimal
-   values of 0xFF and 0xFE, in the middle of the 48 bit MAC (between the
-   company_id and vendor supplied id).  For example the 48 bit MAC with
-   global scope:
-
-   |0              1|1              3|3              4|
-   |0              5|6              1|2              7|
-   +----------------+----------------+----------------+
-   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|
-   +----------------+----------------+----------------+
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 19]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-   where "c" are the bits of the assigned company_id, "0" is the value
-   of the universal/local bit to indicate global scope, "g" is
-   individual/group bit, and "m" are the bits of the manufacturer-
-   selected extension identifier.  The interface identifier would be of
-   the form:
-
-   |0              1|1              3|3              4|4              6|
-   |0              5|6              1|2              7|8              3|
-   +----------------+----------------+----------------+----------------+
-   |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
-   +----------------+----------------+----------------+----------------+
-
-   When IEEE 802 48bit MAC addresses are available (on an interface or a
-   node), an implementation should use them to create interface
-   identifiers due to their availability and uniqueness properties.
-
-Links with Non-Global Identifiers
-
-   There are a number of types of links that, while multi-access, do not
-   have globally unique link identifiers.  Examples include LocalTalk
-   and Arcnet.  The method to create an EUI-64 formatted identifier is
-   to take the link identifier (e.g., the LocalTalk 8 bit node
-   identifier) and zero fill it to the left.  For example a LocalTalk 8
-   bit node identifier of hexadecimal value 0x4F results in the
-   following interface identifier:
-
-   |0              1|1              3|3              4|4              6|
-   |0              5|6              1|2              7|8              3|
-   +----------------+----------------+----------------+----------------+
-   |0000000000000000|0000000000000000|0000000000000000|0000000001001111|
-   +----------------+----------------+----------------+----------------+
-
-   Note that this results in the universal/local bit set to "0" to
-   indicate local scope.
-
-Links without Identifiers
-
-   There are a number of links that do not have any type of built-in
-   identifier.  The most common of these are serial links and configured
-   tunnels.  Interface identifiers must be chosen that are unique for
-   the link.
-
-   When no built-in identifier is available on a link the preferred
-   approach is to use a global interface identifier from another
-   interface or one which is assigned to the node itself.  To use this
-   approach no other interface connecting the same node to the same link
-   may use the same identifier.
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 20]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-   If there is no global interface identifier available for use on the
-   link the implementation needs to create a local scope interface
-   identifier.  The only requirement is that it be unique on the link.
-   There are many possible approaches to select a link-unique interface
-   identifier.  They include:
-
-      Manual Configuration
-      Generated Random Number
-      Node Serial Number (or other node-specific token)
-
-   The link-unique interface identifier should be generated in a manner
-   that it does not change after a reboot of a node or if interfaces are
-   added or deleted from the node.
-
-   The selection of the appropriate algorithm is link and implementation
-   dependent.  The details on forming interface identifiers are defined
-   in the appropriate "IPv6 over <link>" specification.  It is strongly
-   recommended that a collision detection algorithm be implemented as
-   part of any automatic algorithm.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 21]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-APPENDIX B: ABNF Description of Text Representations
-----------------------------------------------------
-
-   This appendix defines the text representation of IPv6 addresses and
-   prefixes in Augmented BNF [ABNF] for reference purposes.
-
-      IPv6address = hexpart [ ":" IPv4address ]
-      IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
-
-      IPv6prefix  = hexpart "/" 1*2DIGIT
-
-      hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
-      hexseq  = hex4 *( ":" hex4)
-      hex4    = 1*4HEXDIG
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 22]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-APPENDIX C: CHANGES FROM RFC-1884
----------------------------------
-
-   The following changes were made from RFC-1884 "IP Version 6
-   Addressing Architecture":
-
-      - Added an appendix providing a ABNF description of text
-        representations.
-      - Clarification that link unique identifiers not change after
-        reboot or other interface reconfigurations.
-      - Clarification of Address Model based on comments.
-      - Changed aggregation format terminology to be consistent with
-        aggregation draft.
-      - Added text to allow interface identifier to be used on more than
-        one interface on same node.
-      - Added rules for defining new multicast addresses.
-      - Added appendix describing procedures for creating EUI-64 based
-        interface ID's.
-      - Added notation for defining IPv6 prefixes.
-      - Changed solicited node multicast definition to use a longer
-        prefix.
-      - Added site scope all routers multicast address.
-      - Defined Aggregatable Global Unicast Addresses to use "001" Format
-        Prefix.
-      - Changed "010" (Provider-Based Unicast) and "100" (Reserved for
-        Geographic) Format Prefixes to Unassigned.
-      - Added section on Interface ID definition for unicast addresses.
-        Requires use of EUI-64 in range of format prefixes and rules for
-        setting global/local scope bit in EUI-64.
-      - Updated NSAP text to reflect working in RFC1888.
-      - Removed protocol specific IPv6 multicast addresses (e.g., DHCP)
-        and referenced the IANA definitions.
-      - Removed section "Unicast Address Example".  Had become OBE.
-      - Added new and updated references.
-      - Minor text clarifications and improvements.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 23]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-REFERENCES
-
-   [ABNF]    Crocker, D., and P. Overell, "Augmented BNF for
-             Syntax Specifications: ABNF", RFC 2234, November 1997.
-
-   [AGGR]    Hinden, R., O'Dell, M., and S. Deering, "An
-             Aggregatable Global Unicast Address Format", RFC 2374, July
-             1998.
-
-   [AUTH]    Atkinson, R., "IP Authentication Header", RFC 1826, August
-             1995.
-
-   [ANYCST]  Partridge, C., Mendez, T., and W. Milliken, "Host
-             Anycasting Service", RFC 1546, November 1993.
-
-   [CIDR]    Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
-             Inter-Domain Routing (CIDR): An Address Assignment and
-             Aggregation Strategy", RFC 1519, September 1993.
-
-   [ETHER]   Crawford, M., "Transmission of IPv6 Pacekts over Ethernet
-             Networks", Work in Progress.
-
-   [EUI64]   IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
-             Registration Authority",
-             http://standards.ieee.org/db/oui/tutorials/EUI64.html,
-             March 1997.
-
-   [FDDI]    Crawford, M., "Transmission of IPv6 Packets over FDDI
-             Networks", Work in Progress.
-
-   [IPV6]    Deering, S., and R. Hinden, Editors, "Internet Protocol,
-             Version 6 (IPv6) Specification", RFC 1883, December 1995.
-
-   [MASGN]   Hinden, R., and S. Deering, "IPv6 Multicast Address
-             Assignments", RFC 2375, July 1998.
-
-   [NSAP]    Bound, J., Carpenter, B., Harrington, D., Houldsworth, J.,
-             and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [TOKEN]   Thomas, S., "Transmission of IPv6 Packets over Token Ring
-             Networks", Work in Progress.
-
-   [TRAN]    Gilligan, R., and E. Nordmark, "Transition Mechanisms for
-             IPv6 Hosts and Routers", RFC 1993, April 1996.
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 24]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-AUTHORS' ADDRESSES
-
-   Robert M. Hinden
-   Nokia
-   232 Java Drive
-   Sunnyvale, CA 94089
-   USA
-
-   Phone: +1 408 990-2004
-   Fax:   +1 408 743-5677
-   EMail: hinden@iprg.nokia.com
-
-
-   Stephen E. Deering
-   Cisco Systems, Inc.
-   170 West Tasman Drive
-   San Jose, CA 95134-1706
-   USA
-
-   Phone: +1 408 527-8213
-   Fax:   +1 408 527-8254
-   EMail: deering@cisco.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 25]
-
-RFC 2373              IPv6 Addressing Architecture             July 1998
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1998).  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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 26]
-
diff --git a/contrib/bind9/doc/rfc/rfc2374.txt b/contrib/bind9/doc/rfc/rfc2374.txt
deleted file mode 100644
index e3c7f0d..0000000
--- a/contrib/bind9/doc/rfc/rfc2374.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        R. Hinden
-Request for Comments: 2374                                       Nokia
-Obsoletes: 2073                                              M. O'Dell
-Category: Standards Track                                        UUNET
-                                                            S. Deering
-                                                                 Cisco
-                                                             July 1998
-
-
-           An IPv6 Aggregatable Global Unicast Address Format
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-1.0 Introduction
-
-   This document defines an IPv6 aggregatable global unicast address
-   format for use in the Internet.  The address format defined in this
-   document is consistent with the IPv6 Protocol [IPV6] and the "IPv6
-   Addressing Architecture" [ARCH].  It is designed to facilitate
-   scalable Internet routing.
-
-   This documented replaces RFC 2073, "An IPv6 Provider-Based Unicast
-   Address Format".  RFC 2073 will become historic.  The Aggregatable
-   Global Unicast Address Format is an improvement over RFC 2073 in a
-   number of areas.  The major changes include removal of the registry
-   bits because they are not needed for route aggregation, support of
-   EUI-64 based interface identifiers, support of provider and exchange
-   based aggregation, separation of public and site topology, and new
-   aggregation based 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].
-
-
-
-
-
-
-
-
-Hinden, et. al.             Standards Track                     [Page 1]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-2.0 Overview of the IPv6 Address
-
-   IPv6 addresses are 128-bit identifiers for interfaces and sets of
-   interfaces.  There are three types of addresses: Unicast, Anycast,
-   and Multicast.  This document defines a specific type of Unicast
-   address.
-
-   In this document, fields in addresses are given specific names, for
-   example "subnet".  When this name is used with the term "ID" (for
-   "identifier") after the name (e.g., "subnet ID"), it refers to the
-   contents of the named field.  When it is used with the term "prefix"
-   (e.g.  "subnet prefix") it refers to all of the addressing bits to
-   the left of and including this field.
-
-   IPv6 unicast addresses are designed assuming that the Internet
-   routing system makes forwarding decisions based on a "longest prefix
-   match" algorithm on arbitrary bit boundaries and does not have any
-   knowledge of the internal structure of IPv6 addresses.  The structure
-   in IPv6 addresses is for assignment and allocation.  The only
-   exception to this is the distinction made between unicast and
-   multicast addresses.
-
-   The specific type of an IPv6 address is indicated by the leading bits
-   in the address.  The variable-length field comprising these leading
-   bits is called the Format Prefix (FP).
-
-   This document defines an address format for the 001 (binary) Format
-   Prefix for Aggregatable Global Unicast addresses. The same address
-   format could be used for other Format Prefixes, as long as these
-   Format Prefixes also identify IPv6 unicast addresses.  Only the "001"
-   Format Prefix is defined here.
-
-3.0 IPv6 Aggregatable Global Unicast Address Format
-
-   This document defines an address format for the IPv6 aggregatable
-   global unicast address assignment.  The authors believe that this
-   address format will be widely used for IPv6 nodes connected to the
-   Internet.  This address format is designed to support both the
-   current provider-based aggregation and a new type of exchange-based
-   aggregation.  The combination will allow efficient routing
-   aggregation for sites that connect directly to providers and for
-   sites that connect to exchanges.  Sites will have the choice to
-   connect to either type of aggregation entity.
-
-
-
-
-
-
-
-
-Hinden, et. al.             Standards Track                     [Page 2]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-   While this address format is designed to support exchange-based
-   aggregation (in addition to current provider-based aggregation) it is
-   not dependent on exchanges for it's overall route aggregation
-   properties.  It will provide efficient route aggregation with only
-   provider-based aggregation.
-
-   Aggregatable addresses are organized into a three level hierarchy:
-
-      - Public Topology
-      - Site Topology
-      - Interface Identifier
-
-   Public topology is the collection of providers and exchanges who
-   provide public Internet transit services.  Site topology is local to
-   a specific site or organization which does not provide public transit
-   service to nodes outside of the site.  Interface identifiers identify
-   interfaces on links.
-
-        ______________                  ______________
-    --+/              \+--------------+/              \+----------
-      (       P1       )    +----+    (       P3       )  +----+
-      +\______________/     |    |----+\______________/+--|    |--
-      |                  +--| X1 |                       +| X2 |
-      | ______________  /   |    |-+    ______________  / |    |--
-      +/              \+    +-+--+  \  /              \+  +----+
-      (       P2       )     / \     +(      P4        )
-    --+\______________/     /   \      \______________/
-           |               /     \           |      |
-           |              /       |          |      |
-           |             /        |          |      |
-          _|_          _/_       _|_        _|_    _|_
-         /   \        /   \     /   \      /   \  /   \
-        ( S.A )      ( S.B )   ( P5  )    ( P6  )( S.C )
-         \___/        \___/     \___/      \___/  \___/
-                                  |          / \
-                                 _|_       _/_  \   ___
-                                /   \     /   \  +-/   \
-                               ( S.D )   ( S.E )  ( S.F )
-                                \___/     \___/    \___/
-
-   As shown in the figure above, the aggregatable address format is
-   designed to support long-haul providers (shown as P1, P2, P3, and
-   P4), exchanges (shown as X1 and X2), multiple levels of providers
-   (shown at P5 and P6), and subscribers (shown as S.x) Exchanges
-   (unlike current NAPs, FIXes, etc.) will allocate IPv6 addresses.
-   Organizations who connect to these exchanges will also subscribe
-   (directly, indirectly via the exchange, etc.) for long-haul service
-   from one or more long-haul providers.  Doing so, they will achieve
-
-
-
-Hinden, et. al.             Standards Track                     [Page 3]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-   addressing independence from long-haul transit providers.  They will
-   be able to change long-haul providers without having to renumber
-   their organization.  They can also be multihomed via the exchange to
-   more than one long-haul provider without having to have address
-   prefixes from each long-haul provider.  Note that the mechanisms used
-   for this type of provider selection and portability are not discussed
-   in the document.
-
-3.1 Aggregatable Global Unicast Address Structure
-
-   The aggregatable global unicast address format is as follows:
-
-     | 3|  13 | 8 |   24   |   16   |          64 bits               |
-     +--+-----+---+--------+--------+--------------------------------+
-     |FP| TLA |RES|  NLA   |  SLA   |         Interface ID           |
-     |  | ID  |   |  ID    |  ID    |                                |
-     +--+-----+---+--------+--------+--------------------------------+
-
-     <--Public Topology--->   Site
-                           <-------->
-                            Topology
-                                     <------Interface Identifier----->
-
-   Where
-
-      FP           Format Prefix (001)
-      TLA ID       Top-Level Aggregation Identifier
-      RES          Reserved for future use
-      NLA ID       Next-Level Aggregation Identifier
-      SLA ID       Site-Level Aggregation Identifier
-      INTERFACE ID Interface Identifier
-
-   The following sections specify each part of the IPv6 Aggregatable
-   Global Unicast address format.
-
-3.2 Top-Level Aggregation ID
-
-   Top-Level Aggregation Identifiers (TLA ID) are the top level in the
-   routing hierarchy.  Default-free routers must have a routing table
-   entry for every active TLA ID and will probably have additional
-   entries providing routing information for the TLA ID in which they
-   are located.  They may have additional entries in order to optimize
-   routing for their specific topology, but the routing topology at all
-   levels must be designed to minimize the number of additional entries
-   fed into the default free routing tables.
-
-
-
-
-
-
-Hinden, et. al.             Standards Track                     [Page 4]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-   This addressing format supports 8,192 (2^13) TLA ID's.  Additional
-   TLA ID's may be added by either growing the TLA field to the right
-   into the reserved field or by using this format for additional format
-   prefixes.
-
-   The issues relating to TLA ID assignment are beyond the scope of this
-   document.  They will be described in a document under preparation.
-
-3.3 Reserved
-
-   The Reserved field is reserved for future use and must be set to
-   zero.
-
-   The Reserved field allows for future growth of the TLA and NLA fields
-   as appropriate.  See section 4.0 for a discussion.
-
-3.4 Next-Level Aggregation Identifier
-
-   Next-Level Aggregation Identifier's are used by organizations
-   assigned a TLA ID to create an addressing hierarchy and to identify
-   sites.  The organization can assign the top part of the NLA ID in a
-   manner to create an addressing hierarchy appropriate to its network.
-   It can use the remainder of the bits in the field to identify sites
-   it wishes to serve.  This is shown as follows:
-
-      |  n  |      24-n bits     |   16   |    64 bits      |
-      +-----+--------------------+--------+-----------------+
-      |NLA1 |      Site ID       | SLA ID | Interface ID    |
-      +-----+--------------------+--------+-----------------+
-
-   Each organization assigned a TLA ID receives 24 bits of NLA ID space.
-   This NLA ID space allows each organization to provide service to
-   approximately as many organizations as the current IPv4 Internet can
-   support total networks.
-
-   Organizations assigned TLA ID's may also support NLA ID's in their
-   own Site ID space.  This allows the organization assigned a TLA ID to
-   provide service to organizations providing public transit service and
-   to organizations who do not provide public transit service.  These
-   organizations receiving an NLA ID may also choose to use their Site
-   ID space to support other NLA ID's.  This is shown as follows:
-
-
-
-
-
-
-
-
-
-
-Hinden, et. al.             Standards Track                     [Page 5]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-   |  n  |      24-n bits     |   16   |    64 bits      |
-   +-----+--------------------+--------+-----------------+
-   |NLA1 |      Site ID       | SLA ID | Interface ID    |
-   +-----+--------------------+--------+-----------------+
-
-         |  m  |    24-n-m    |   16   |    64 bits      |
-         +-----+--------------+--------+-----------------+
-         |NLA2 |   Site ID    | SLA ID | Interface ID    |
-         +-----+--------------+--------+-----------------+
-
-               |  o  |24-n-m-o|   16   |    64 bits      |
-               +-----+--------+--------+-----------------+
-               |NLA3 | Site ID| SLA ID | Interface ID    |
-               +-----+--------+--------+-----------------+
-
-   The design of the bit layout of the NLA ID space for a specific TLA
-   ID is left to the organization responsible for that TLA ID.  Likewise
-   the design of the bit layout of the next level NLA ID is the
-   responsibility of the previous level NLA ID.  It is recommended that
-   organizations assigning NLA address space use "slow start" allocation
-   procedures similar to [RFC2050].
-
-   The design of an NLA ID allocation plan is a tradeoff between routing
-   aggregation efficiency and flexibility.  Creating hierarchies allows
-   for greater amount of aggregation and results in smaller routing
-   tables.  Flat NLA ID assignment provides for easier allocation and
-   attachment flexibility, but results in larger routing tables.
-
-3.5 Site-Level Aggregation Identifier
-
-   The SLA ID field is used by an individual organization to create its
-   own local addressing hierarchy and to identify subnets.  This is
-   analogous to subnets in IPv4 except that each organization has a much
-   greater number of subnets.  The 16 bit SLA ID field support 65,535
-   individual subnets.
-
-   Organizations may choose to either route their SLA ID "flat" (e.g.,
-   not create any logical relationship between the SLA identifiers that
-   results in larger routing tables), or to create a two or more level
-   hierarchy (that results in smaller routing tables) in the SLA ID
-   field.  The latter is shown as follows:
-
-
-
-
-
-
-
-
-
-
-Hinden, et. al.             Standards Track                     [Page 6]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-   |  n  |   16-n     |              64 bits                |
-   +-----+------------+-------------------------------------+
-   |SLA1 |   Subnet   |            Interface ID             |
-   +-----+------------+-------------------------------------+
-
-         | m  |16-n-m |              64 bits                |
-         +----+-------+-------------------------------------+
-         |SLA2|Subnet |            Interface ID             |
-         +----+-------+-------------------------------------+
-
-   The approach chosen for structuring an SLA ID field is the
-   responsibility of the individual organization.
-
-   The number of subnets supported in this address format should be
-   sufficient for all but the largest of organizations.  Organizations
-   which need additional subnets can arrange with the organization they
-   are obtaining Internet service from to obtain additional site
-   identifiers and use this to create additional subnets.
-
-3.6 Interface ID
-
-   Interface identifiers are used to identify interfaces on a link.
-   They are required to be unique on that link.  They may also be unique
-   over a broader scope.  In many cases an interfaces identifier will be
-   the same or be based on the interface's link-layer address.
-   Interface IDs used in the aggregatable global unicast address format
-   are required to be 64 bits long and to be constructed in IEEE EUI-64
-   format [EUI-64].  These identifiers may have global scope when a
-   global token (e.g., IEEE 48bit MAC) is available or may have local
-   scope where a global token is not available (e.g., serial links,
-   tunnel end-points, etc.).  The "u" bit (universal/local bit in IEEE
-   EUI-64 terminology) in the EUI-64 identifier must be set correctly,
-   as defined in [ARCH], to indicate global or local scope.
-
-   The procedures for creating EUI-64 based Interface Identifiers is
-   defined in [ARCH].  The details on forming interface identifiers is
-   defined in the appropriate "IPv6 over <link>" specification such as
-   "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
-
-4.0 Technical Motivation
-
-   The design choices for the size of the fields in the aggregatable
-   address format were based on the need to meet a number of technical
-   requirements.  These are described in the following paragraphs.
-
-   The size of the Top-Level Aggregation Identifier is 13 bits.  This
-   allows for 8,192 TLA ID's.  This size was chosen to insure that the
-   default-free routing table in top level routers in the Internet is
-
-
-
-Hinden, et. al.             Standards Track                     [Page 7]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-   kept within the limits, with a reasonable margin, of the current
-   routing technology.  The margin is important because default-free
-   routers will also carry a significant number of longer (i.e., more-
-   specific) prefixes for optimizing paths internal to a TLA and between
-   TLAs.
-
-   The important issue is not only the size of the default-free routing
-   table, but the complexity of the topology that determines the number
-   of copies of the default-free routes that a router must examine while
-   computing a forwarding table.  Current practice with IPv4 it is
-   common to see a prefix announced fifteen times via different paths.
-
-   The complexity of Internet topology is very likely to increase in the
-   future.  It is important that IPv6 default-free routing support
-   additional complexity as well as a considerably larger internet.
-
-   It should be noted for comparison that at the time of this writing
-   (spring, 1998) the IPv4 default-free routing table contains
-   approximately 50,000 prefixes.  While this shows that it is possible
-   to support more routes than 8,192 it is matter of debate if the
-   number of prefixes supported today in IPv4 is already too high for
-   current routing technology.  There are serious issues of route
-   stability as well as cases of providers not supporting all top level
-   prefixes.  The technical requirement was to pick a TLA ID size that
-   was below, with a reasonable margin, what was being done with IPv4.
-
-   The choice of 13 bits for the TLA field was an engineering
-   compromise.  Fewer bits would have been too small by not supporting
-   enough top level organizations.  More bits would have exceeded what
-   can be reasonably accommodated, with a reasonable margin, with
-   current routing technology in order to deal with the issues described
-   in the previous paragraphs.
-
-   If in the future, routing technology improves to support a larger
-   number of top level routes in the default-free routing tables there
-   are two choices on how to increase the number TLA identifiers.  The
-   first is to expand the TLA ID field into the reserved field.  This
-   would increase the number of TLA ID's to approximately 2 million.
-   The second approach is to allocate another format prefix (FP) for use
-   with this address format.  Either or a combination of these
-   approaches allows the number of TLA ID's to increase significantly.
-
-   The size of the Reserved field is 8 bits.  This size was chosen to
-   allow significant growth of either the TLA ID and/or the NLA ID
-   fields.
-
-   The size of the Next-Level Aggregation Identifier field is 24 bits.
-
-
-
-
-Hinden, et. al.             Standards Track                     [Page 8]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-   This allows for approximately sixteen million NLA ID's if used in a
-   flat manner.  Used hierarchically it allows for a complexity roughly
-   equivalent to the IPv4 address space (assuming an average network
-   size of 254 interfaces).  If in the future additional room for
-   complexity is needed in the NLA ID, this may be accommodated by
-   extending the NLA ID into the Reserved field.
-
-   The size of the Site-Level Aggregation Identifier field is 16 bits.
-   This supports 65,535 individual subnets per site.  The design goal
-   for the size of this field was to be sufficient for all but the
-   largest of organizations.  Organizations which need additional
-   subnets can arrange with the organization they are obtaining Internet
-   service from to obtain additional site identifiers and use this to
-   create additional subnets.
-
-   The Site-Level Aggregation Identifier field was given a fixed size in
-   order to force the length of all prefixes identifying a particular
-   site to be the same length (i.e., 48 bits).  This facilitates
-   movement of sites in the topology (e.g., changing service providers
-   and multi-homing to multiple service providers).
-
-   The Interface ID Interface Identifier field is 64 bits.  This size
-   was chosen to meet the requirement specified in [ARCH] to support
-   EUI-64 based Interface Identifiers.
-
-5.0 Acknowledgments
-
-   The authors would like to express our thanks to Thomas Narten, Bob
-   Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema,
-   Scott Bradner, Brian Carpenter, John Stewart, and Daniel Karrenberg
-   for their review and constructive comments.
-
-6.0 References
-
-   [ALLOC]   IAB and IESG, "IPv6 Address Allocation Management",
-             RFC 1881, December 1995.
-
-   [ARCH]    Hinden, R., "IP Version 6 Addressing Architecture",
-             RFC 2373, July 1998.
-
-   [AUTH]    Atkinson, R., "IP Authentication Header", RFC 1826, August
-             1995.
-
-   [AUTO]    Thompson, S., and T. Narten., "IPv6 Stateless Address
-             Autoconfiguration", RFC 1971, August 1996.
-
-   [ETHER]   Crawford, M., "Transmission of IPv6 Packets over Ethernet
-             Networks", Work in Progress.
-
-
-
-Hinden, et. al.             Standards Track                     [Page 9]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-   [EUI64]   IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
-             Registration Authority",
-             http://standards.ieee.org/db/oui/tutorials/EUI64.html,
-             March 1997.
-
-   [FDDI]    Crawford, M., "Transmission of IPv6 Packets over FDDI
-             Networks", Work in Progress.
-
-   [IPV6]    Deering, S., and R. Hinden, "Internet Protocol, Version 6
-             (IPv6) Specification", RFC 1883, December 1995.
-
-   [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D.,
-             and J. Postel, "Internet Registry IP Allocation
-             Guidelines", BCP 12, RFC 1466, November 1996.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-7.0 Security Considerations
-
-   IPv6 addressing documents do not have any direct impact on Internet
-   infrastructure security.  Authentication of IPv6 packets is defined
-   in [AUTH].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden, et. al.             Standards Track                    [Page 10]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-8.0 Authors' Addresses
-
-   Robert M. Hinden
-   Nokia
-   232 Java Drive
-   Sunnyvale, CA 94089
-   USA
-
-   Phone: 1 408 990-2004
-   EMail: hinden@iprg.nokia.com
-
-
-   Mike O'Dell
-   UUNET Technologies, Inc.
-   3060 Williams Drive
-   Fairfax, VA 22030
-   USA
-
-   Phone: 1 703 206-5890
-   EMail: mo@uunet.uu.net
-
-
-   Stephen E. Deering
-   Cisco Systems, Inc.
-   170 West Tasman Drive
-   San Jose, CA 95134-1706
-   USA
-
-   Phone: 1 408 527-8213
-   EMail: deering@cisco.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden, et. al.             Standards Track                    [Page 11]
-
-RFC 2374           IPv6 Global Unicast Address Format          July 1998
-
-
-9.0  Full Copyright Statement
-
-   Copyright (C) The Internet Society (1998).  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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden, et. al.             Standards Track                    [Page 12]
-
diff --git a/contrib/bind9/doc/rfc/rfc2375.txt b/contrib/bind9/doc/rfc/rfc2375.txt
deleted file mode 100644
index a1fe8b9..0000000
--- a/contrib/bind9/doc/rfc/rfc2375.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         R. Hinden
-Request for Comments: 2375                             Ipsilon Networks
-Category: Informational                                      S. Deering
-                                                                  Cisco
-                                                              July 1998
-
-
-                   IPv6 Multicast Address Assignments
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-1.0 Introduction
-
-   This document defines the initial assignment of IPv6 multicast
-   addresses.  It is based on the "IP Version 6 Addressing Architecture"
-   [ADDARCH] and current IPv4 multicast address assignment found in
-   <ftp://venera.isi.edu/in-notes/iana/assignments/multicast-addresses>.
-   It adapts the IPv4 assignments that are relevant to IPv6 assignments.
-   IPv4 assignments that were not relevant were not converted into IPv6
-   assignments.  Comments are solicited on this conversion.
-
-   All other IPv6 multicast addresses are reserved.
-
-   Sections 2 and 3 specify reserved and preassigned IPv6 multicast
-   addresses.
-
-   [ADDRARCH] defines rules for assigning new IPv6 multicast addresses.
-
-   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. Fixed Scope Multicast Addresses
-
-   These permanently assigned multicast addresses are valid over a
-   specified scope value.
-
-
-
-
-
-
-
-Hinden & Deering             Informational                      [Page 1]
-
-RFC 2375           IPv6 Multicast Address Assignments          July 1998
-
-
-2.1 Node-Local Scope
-
-   FF01:0:0:0:0:0:0:1     All Nodes Address                  [ADDARCH]
-   FF01:0:0:0:0:0:0:2     All Routers Address                [ADDARCH]
-
-2.2 Link-Local Scope
-
-   FF02:0:0:0:0:0:0:1     All Nodes Address                  [ADDARCH]
-   FF02:0:0:0:0:0:0:2     All Routers Address                [ADDARCH]
-   FF02:0:0:0:0:0:0:3     Unassigned                             [JBP]
-   FF02:0:0:0:0:0:0:4     DVMRP Routers                  [RFC1075,JBP]
-   FF02:0:0:0:0:0:0:5     OSPFIGP                        [RFC2328,Moy]
-   FF02:0:0:0:0:0:0:6     OSPFIGP Designated Routers     [RFC2328,Moy]
-   FF02:0:0:0:0:0:0:7     ST Routers                    [RFC1190,KS14]
-   FF02:0:0:0:0:0:0:8     ST Hosts                      [RFC1190,KS14]
-   FF02:0:0:0:0:0:0:9     RIP Routers                        [RFC2080]
-   FF02:0:0:0:0:0:0:A     EIGRP Routers                    [Farinacci]
-   FF02:0:0:0:0:0:0:B     Mobile-Agents                 [Bill Simpson]
-
-   FF02:0:0:0:0:0:0:D     All PIM Routers                  [Farinacci]
-   FF02:0:0:0:0:0:0:E     RSVP-ENCAPSULATION                  [Braden]
-
-   FF02:0:0:0:0:0:1:1     Link Name                       [Harrington]
-   FF02:0:0:0:0:0:1:2     All-dhcp-agents              [Bound,Perkins]
-
-   FF02:0:0:0:0:1:FFXX:XXXX     Solicited-Node Address       [ADDARCH]
-
-2.3 Site-Local Scope
-
-   FF05:0:0:0:0:0:0:2       All Routers Address              [ADDARCH]
-
-   FF05:0:0:0:0:0:1:3       All-dhcp-servers           [Bound,Perkins]
-   FF05:0:0:0:0:0:1:4       All-dhcp-relays            [Bound,Perkins]
-   FF05:0:0:0:0:0:1:1000    Service Location                 [RFC2165]
-    -FF05:0:0:0:0:0:1:13FF
-
-3.0 All Scope Multicast Addresses
-
-   These permanently assigned multicast addresses are valid over all
-   scope ranges.  This is shown by an "X" in the scope field of the
-   address that means any legal scope value.
-
-   Note that, as defined in [ADDARCH], IPv6 multicast addresses which
-   are only different in scope represent different groups.  Nodes must
-   join each group individually.
-
-   The IPv6 multicast addresses with variable scope are as follows:
-
-
-
-
-Hinden & Deering             Informational                      [Page 2]
-
-RFC 2375           IPv6 Multicast Address Assignments          July 1998
-
-
-   FF0X:0:0:0:0:0:0:0     Reserved Multicast Address         [ADDARCH]
-
-   FF0X:0:0:0:0:0:0:100   VMTP Managers Group           [RFC1045,DRC3]
-   FF0X:0:0:0:0:0:0:101   Network Time Protocol (NTP)   [RFC1119,DLM1]
-   FF0X:0:0:0:0:0:0:102   SGI-Dogfight                           [AXC]
-   FF0X:0:0:0:0:0:0:103   Rwhod                                  [SXD]
-   FF0X:0:0:0:0:0:0:104   VNP                                   [DRC3]
-   FF0X:0:0:0:0:0:0:105   Artificial Horizons - Aviator          [BXF]
-   FF0X:0:0:0:0:0:0:106   NSS - Name Service Server             [BXS2]
-   FF0X:0:0:0:0:0:0:107   AUDIONEWS - Audio News Multicast      [MXF2]
-   FF0X:0:0:0:0:0:0:108   SUN NIS+ Information Service          [CXM3]
-   FF0X:0:0:0:0:0:0:109   MTP Multicast Transport Protocol       [SXA]
-   FF0X:0:0:0:0:0:0:10A   IETF-1-LOW-AUDIO                       [SC3]
-   FF0X:0:0:0:0:0:0:10B   IETF-1-AUDIO                           [SC3]
-   FF0X:0:0:0:0:0:0:10C   IETF-1-VIDEO                           [SC3]
-   FF0X:0:0:0:0:0:0:10D   IETF-2-LOW-AUDIO                       [SC3]
-   FF0X:0:0:0:0:0:0:10E   IETF-2-AUDIO                           [SC3]
-   FF0X:0:0:0:0:0:0:10F   IETF-2-VIDEO                           [SC3]
-
-   FF0X:0:0:0:0:0:0:110   MUSIC-SERVICE             [Guido van Rossum]
-   FF0X:0:0:0:0:0:0:111   SEANET-TELEMETRY             [Andrew Maffei]
-   FF0X:0:0:0:0:0:0:112   SEANET-IMAGE                 [Andrew Maffei]
-   FF0X:0:0:0:0:0:0:113   MLOADD                              [Braden]
-   FF0X:0:0:0:0:0:0:114   any private experiment                 [JBP]
-   FF0X:0:0:0:0:0:0:115   DVMRP on MOSPF                         [Moy]
-   FF0X:0:0:0:0:0:0:116   SVRLOC                            [Veizades]
-   FF0X:0:0:0:0:0:0:117   XINGTV                      <hgxing@aol.com>
-   FF0X:0:0:0:0:0:0:118   microsoft-ds         <arnoldm@microsoft.com>
-   FF0X:0:0:0:0:0:0:119   nbc-pro           <bloomer@birch.crd.ge.com>
-   FF0X:0:0:0:0:0:0:11A   nbc-pfn           <bloomer@birch.crd.ge.com>
-   FF0X:0:0:0:0:0:0:11B   lmsc-calren-1                         [Uang]
-   FF0X:0:0:0:0:0:0:11C   lmsc-calren-2                         [Uang]
-   FF0X:0:0:0:0:0:0:11D   lmsc-calren-3                         [Uang]
-   FF0X:0:0:0:0:0:0:11E   lmsc-calren-4                         [Uang]
-   FF0X:0:0:0:0:0:0:11F   ampr-info                          [Janssen]
-
-   FF0X:0:0:0:0:0:0:120   mtrace                              [Casner]
-   FF0X:0:0:0:0:0:0:121   RSVP-encap-1                        [Braden]
-   FF0X:0:0:0:0:0:0:122   RSVP-encap-2                        [Braden]
-   FF0X:0:0:0:0:0:0:123   SVRLOC-DA                         [Veizades]
-   FF0X:0:0:0:0:0:0:124   rln-server                            [Kean]
-   FF0X:0:0:0:0:0:0:125   proshare-mc                          [Lewis]
-   FF0X:0:0:0:0:0:0:126   dantz                               [Yackle]
-   FF0X:0:0:0:0:0:0:127   cisco-rp-announce                [Farinacci]
-   FF0X:0:0:0:0:0:0:128   cisco-rp-discovery               [Farinacci]
-   FF0X:0:0:0:0:0:0:129   gatekeeper                            [Toga]
-   FF0X:0:0:0:0:0:0:12A   iberiagames                        [Marocho]
-
-
-
-
-Hinden & Deering             Informational                      [Page 3]
-
-RFC 2375           IPv6 Multicast Address Assignments          July 1998
-
-
-   FF0X:0:0:0:0:0:0:201  "rwho" Group (BSD) (unofficial)         [JBP]
-   FF0X:0:0:0:0:0:0:202   SUN RPC PMAPPROC_CALLIT               [BXE1]
-
-   FF0X:0:0:0:0:0:2:0000
-    -FF0X:0:0:0:0:0:2:7FFD  Multimedia Conference Calls          [SC3]
-   FF0X:0:0:0:0:0:2:7FFE    SAPv1 Announcements                  [SC3]
-   FF0X:0:0:0:0:0:2:7FFF    SAPv0 Announcements (deprecated)     [SC3]
-   FF0X:0:0:0:0:0:2:8000
-    -FF0X:0:0:0:0:0:2:FFFF  SAP Dynamic Assignments              [SC3]
-
-5.0 References
-
-   [ADDARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing
-             Architecture", RFC 2373, July 1998.
-
-   [AUTORFC] Thompson, S., and T. Narten, "IPv6 Stateless Address
-             Autoconfiguration", RFC 1971, August 1996.
-
-   [ETHER]   Crawford, M., "Transmission of IPv6 Packets over Ethernet
-             Networks", Work in Progress.
-
-   [RFC1045] Cheriton, D., "VMTP: Versatile Message Transaction Protocol
-             Specification", RFC 1045, February 1988.
-
-   [RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance
-             Vector Multicast Routing Protocol", RFC 1075, November
-             1988.
-
-   [RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5,
-             RFC 1112, Stanford University, August 1989.
-
-   [RFC1119] Mills, D., "Network Time Protocol (Version 1),
-             Specification and Implementation", STD 12, RFC 1119, July
-             1988.
-
-   [RFC1190] Topolcic, C., Editor, "Experimental Internet Stream
-             Protocol, Version 2 (ST-II)", RFC 1190, October 1990.
-
-   [RFC2080] Malkin, G., and R. Minnear, "RIPng for IPv6", RFC 2080,
-             January 1997.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2165] Veizades, J., Guttman, E., Perkins, C., and S. Kaplan
-             "Service Location Protocol", RFC 2165 June 1997.
-
-   [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
-
-
-
-Hinden & Deering             Informational                      [Page 4]
-
-RFC 2375           IPv6 Multicast Address Assignments          July 1998
-
-
-6. People
-
-   <arnoldm@microsoft.com>
-
-   [AXC] Andrew Cherenson <arc@SGI.COM>
-
-   [Braden] Bob Braden, <braden@isi.edu>, April 1996.
-
-   [Bob Brenner]
-
-   [Bressler] David J. Bressler, <bressler@tss.com>, April 1996.
-
-   <bloomer@birch.crd.ge.com>
-
-   [Bound] Jim Bound <bound@zk3.dec.com>
-
-   [BXE1] Brendan Eic <brendan@illyria.wpd.sgi.com>
-
-   [BXF] Bruce Factor <ahi!bigapple!bruce@uunet.UU.NET>
-
-   [BXS2] Bill Schilit <schilit@parc.xerox.com>
-
-   [Casner] Steve Casner, <casner@isi.edu>, January 1995.
-
-   [CXM3] Chuck McManis <cmcmanis@sun.com>
-
-   [Tim Clark]
-
-   [DLM1] David Mills <Mills@HUEY.UDEL.EDU>
-
-   [DRC3] Dave Cheriton <cheriton@PESCADERO.STANFORD.EDU>
-
-   [DXS3] Daniel Steinber <Daniel.Steinberg@Eng.Sun.COM>
-
-   [Farinacci] Dino Farinacci, <dino@cisco.com>
-
-   [GSM11] Gary S. Malkin <GMALKIN@XYLOGICS.COM>
-
-   [Harrington] Dan Harrington, <dan@lucent.com>, July 1996.
-
-   <hgxing@aol.com>
-
-   [IANA] IANA <iana@iana.org>
-
-   [Janssen] Rob Janssen, <rob@pe1chl.ampr.org>, January 1995.
-
-   [JBP] Jon Postel <postel@isi.edu>
-
-
-
-
-Hinden & Deering             Informational                      [Page 5]
-
-RFC 2375           IPv6 Multicast Address Assignments          July 1998
-
-
-   [JXM1] Jim Miner <miner@star.com>
-
-   [Kean] Brian Kean, <bkean@dca.com>, August 1995.
-
-   [KS14] <mystery contact>
-
-   [Lee] Choon Lee, <cwl@nsd.3com.com>, April 1996.
-
-   [Lewis] Mark Lewis, <Mark_Lewis@ccm.jf.intel.com>, October 1995.
-
-   [Malamud] Carl Malamud, <carl@radio.com>, January 1996.
-
-   [Andrew Maffei]
-
-   [Marohco] Jose Luis Marocho, <73374.313@compuserve.com>, July 1996.
-
-   [Moy] John Moy <jmoy@casc.com>
-
-   [MXF2] Martin Forssen <maf@dtek.chalmers.se>
-
-   [Perkins] Charlie Perkins, <cperkins@corp.sun.com>
-
-   [Guido van Rossum]
-
-   [SC3] Steve Casner <casner@isi.edu>
-
-   [Simpson] Bill Simpson <bill.simpson@um.cc.umich.edu> November 1994.
-
-   [Joel Snyder]
-
-   [SXA] Susie Armstrong <Armstrong.wbst128@XEROX.COM>
-
-   [SXD] Steve Deering <deering@PARC.XEROX.COM>
-
-   [tynan] Dermot Tynan, <dtynan@claddagh.ie>, August 1995.
-
-   [Toga] Jim Toga, <jtoga@ibeam.jf.intel.com>, May 1996.
-
-   [Uang] Yea Uang <uang@force.decnet.lockheed.com> November 1994.
-
-   [Veizades] John Veizades,  <veizades@tgv.com>, May 1995.
-
-   [Yackle] Dotty Yackle, <ditty_yackle@dantz.com>, February 1996.
-
-
-
-
-
-
-
-
-Hinden & Deering             Informational                      [Page 6]
-
-RFC 2375           IPv6 Multicast Address Assignments          July 1998
-
-
-7.0 Security Considerations
-
-   This document defines the initial assignment of IPv6 multicast
-   addresses.  As such it does not directly impact the security of the
-   Internet infrastructure or its applications.
-
-8.0 Authors' Addresses
-
-   Robert M. Hinden
-   Ipsilon Networks, Inc.
-   232 Java Drive
-   Sunnyvale, CA 94089
-   USA
-
-   Phone: +1 415 990 2004
-   EMail: hinden@ipsilon.com
-
-
-   Stephen E. Deering
-   Cisco Systems, Inc.
-   170 West Tasman Drive
-   San Jose, CA 95134-1706
-   USA
-
-   Phone: +1 408 527-8213
-   EMail: deering@cisco.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering             Informational                      [Page 7]
-
-RFC 2375           IPv6 Multicast Address Assignments          July 1998
-
-
-9.0  Full Copyright Statement
-
-   Copyright (C) The Internet Society (1998).  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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering             Informational                      [Page 8]
-
diff --git a/contrib/bind9/doc/rfc/rfc2418.txt b/contrib/bind9/doc/rfc/rfc2418.txt
deleted file mode 100644
index 9bdb2c5..0000000
--- a/contrib/bind9/doc/rfc/rfc2418.txt
+++ /dev/null
@@ -1,1459 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         S. Bradner
-Request for Comments: 2418                                        Editor
-Obsoletes: 1603                                       Harvard University
-BCP: 25                                                   September 1998
-Category: Best Current Practice
-
-
-                           IETF Working Group
-                       Guidelines and Procedures
-
-Status of this Memo
-
-   This document specifies an Internet Best Current Practices for the
-   Internet Community, and requests discussion and suggestions for
-   improvements.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-Abstract
-
-   The Internet Engineering Task Force (IETF) has responsibility for
-   developing and reviewing specifications intended as Internet
-   Standards. IETF activities are organized into working groups (WGs).
-   This document describes the guidelines and procedures for formation
-   and operation of IETF working groups. It also describes the formal
-   relationship between IETF participants WG and the Internet
-   Engineering Steering Group (IESG) and the basic duties of IETF
-   participants, including WG Chairs, WG participants, and IETF Area
-   Directors.
-
-Table of Contents
-
-   Abstract .........................................................  1
-   1. Introduction ..................................................  2
-     1.1. IETF approach to standardization ..........................  4
-     1.2. Roles within a Working Group ..............................  4
-   2. Working group formation .......................................  4
-     2.1. Criteria for formation ....................................  4
-     2.2. Charter ...................................................  6
-     2.3. Charter review & approval .................................  8
-     2.4. Birds of a feather (BOF) ..................................  9
-   3. Working Group Operation ....................................... 10
-     3.1. Session planning .......................................... 11
-     3.2. Session venue ............................................. 11
-     3.3. Session management ........................................ 13
-     3.4. Contention and appeals .................................... 15
-
-
-
-Bradner                  Best Current Practice                  [Page 1]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   4. Working Group Termination ..................................... 15
-   5. Rechartering a Working Group .................................. 15
-   6. Staff Roles ................................................... 16
-     6.1. WG Chair .................................................. 16
-     6.2. WG Secretary .............................................. 18
-     6.3. Document Editor ........................................... 18
-     6.4. WG Facilitator ............................................ 18
-     6.5. Design teams .............................................. 19
-     6.6. Working Group Consultant .................................. 19
-     6.7. Area Director ............................................. 19
-   7. Working Group Documents ....................................... 19
-     7.1. Session documents ......................................... 19
-     7.2. Internet-Drafts (I-D) ..................................... 19
-     7.3. Request For Comments (RFC) ................................ 20
-     7.4. Working Group Last-Call ................................... 20
-     7.5. Submission of documents ................................... 21
-   8. Review of documents ........................................... 21
-   9. Security Considerations ....................................... 22
-   10. Acknowledgments .............................................. 23
-   11. References ................................................... 23
-   12. Editor's Address ............................................. 23
-   Appendix:  Sample Working Group Charter .......................... 24
-   Full Copyright Statement ......................................... 26
-
-1. Introduction
-
-   The Internet, a loosely-organized international collaboration of
-   autonomous, interconnected networks, supports host-to-host
-   communication through voluntary adherence to open protocols and
-   procedures defined by Internet Standards.  There are also many
-   isolated interconnected networks, which are not connected to the
-   global Internet but use the Internet Standards. Internet Standards
-   are developed in the Internet Engineering Task Force (IETF).  This
-   document defines guidelines and procedures for IETF working groups.
-   The Internet Standards Process of the IETF is defined in [1]. The
-   organizations involved in the IETF Standards Process are described in
-   [2] as are the roles of specific individuals.
-
-   The IETF is a large, open community of network designers, operators,
-   vendors, users, and researchers concerned with the Internet and the
-   technology used on it. The primary activities of the IETF are
-   performed by committees known as working groups. There are currently
-   more than 100 working groups. (See the IETF web page for an up-to-
-   date list of IETF Working Groups - http://www.ietf.org.) Working
-   groups tend to have a narrow focus and a lifetime bounded by the
-   completion of a specific set of tasks, although there are exceptions.
-
-
-
-
-
-Bradner                  Best Current Practice                  [Page 2]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   For management purposes, the IETF working groups are collected
-   together into areas, with each area having a separate focus.  For
-   example, the security area deals with the development of security-
-   related technology.  Each IETF area is managed by one or two Area
-   Directors (ADs).  There are currently 8 areas in the IETF but the
-   number changes from time to time.  (See the IETF web page for a list
-   of the current areas, the Area Directors for each area, and a list of
-   which working groups are assigned to each area.)
-
-   In many areas, the Area Directors have formed an advisory group or
-   directorate.  These comprise experienced members of the IETF and the
-   technical community represented by the area.  The specific name and
-   the details of the role for each group differ from area to area, but
-   the primary intent is that these groups assist the Area Director(s),
-   e.g., with the review of specifications produced in the area.
-
-   The IETF area directors are selected by a nominating committee, which
-   also selects an overall chair for the IETF.  The nominations process
-   is described in [3].
-
-   The area directors sitting as a body, along with the IETF Chair,
-   comprise the Internet Engineering Steering Group (IESG). The IETF
-   Executive Director is an ex-officio participant of the IESG, as are
-   the IAB Chair and a designated Internet Architecture Board (IAB)
-   liaison.  The IESG approves IETF Standards and approves the
-   publication of other IETF documents.  (See [1].)
-
-   A small IETF Secretariat provides staff and administrative support
-   for the operation of the IETF.
-
-   There is no formal membership in the IETF.  Participation is open to
-   all.  This participation may be by on-line contribution, attendance
-   at face-to-face sessions, or both.  Anyone from the Internet
-   community who has the time and interest is urged to participate in
-   IETF meetings and any of its on-line working group discussions.
-   Participation is by individual technical contributors, rather than by
-   formal representatives of organizations.
-
-   This document defines procedures and guidelines for the formation and
-   operation of working groups in the IETF. It defines the relations of
-   working groups to other bodies within the IETF. The duties of working
-   group Chairs and Area Directors with respect to the operation of the
-   working group are also defined.  When used in this document the key
-   words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
-   "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be
-   interpreted as described in RFC 2119 [6].  RFC 2119 defines the use
-   of these key words to help make the intent of standards track
-   documents as clear as possible.  The same key words are used in this
-
-
-
-Bradner                  Best Current Practice                  [Page 3]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   document to help smooth WG operation and reduce the chance for
-   confusion about the processes.
-
-1.1. IETF approach to standardization
-
-   Familiarity with The Internet Standards Process [1] is essential for
-   a complete understanding of the philosophy, procedures and guidelines
-   described in this document.
-
-1.2. Roles within a Working Group
-
-   The document, "Organizations Involved in the IETF Standards Process"
-   [2] describes the roles of a number of individuals within a working
-   group, including the working group chair and the document editor.
-   These descriptions are expanded later in this document.
-
-2. Working group formation
-
-   IETF working groups (WGs) are the primary mechanism for development
-   of IETF specifications and guidelines, many of which are intended to
-   be standards or recommendations. A working group may be established
-   at the initiative of an Area Director or it may be initiated by an
-   individual or group of individuals. Anyone interested in creating an
-   IETF working group MUST obtain the advice and consent of the IETF
-   Area Director(s) in whose area the working group would fall and MUST
-   proceed through the formal steps detailed in this section.
-
-   Working groups are typically created to address a specific problem or
-   to produce one or more specific deliverables (a guideline, standards
-   specification, etc.).  Working groups are generally expected to be
-   short-lived in nature.  Upon completion of its goals and achievement
-   of its objectives, the working group is terminated. A working group
-   may also be terminated for other reasons (see section 4).
-   Alternatively, with the concurrence of the IESG, Area Director, the
-   WG Chair, and the WG participants, the objectives or assignment of
-   the working group may be extended by modifying the working group's
-   charter through a rechartering process (see section 5).
-
-2.1. Criteria for formation
-
-   When determining whether it is appropriate to create a working group,
-   the Area Director(s) and the IESG will consider several issues:
-
-    - Are the issues that the working group plans to address clear and
-      relevant to the Internet community?
-
-    - Are the goals specific and reasonably achievable, and achievable
-      within a reasonable time frame?
-
-
-
-Bradner                  Best Current Practice                  [Page 4]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-    - What are the risks and urgency of the work, to determine the level
-      of effort required?
-
-    - Do the working group's activities overlap with those of another
-      working group?  If so, it may still be appropriate to create the
-      working group, but this question must be considered carefully by
-      the Area Directors as subdividing efforts often dilutes the
-      available technical expertise.
-
-    - Is there sufficient interest within the IETF in the working
-      group's topic with enough people willing to expend the effort to
-      produce the desired result (e.g., a protocol specification)?
-      Working groups require considerable effort, including management
-      of the working group process, editing of working group documents,
-      and contributing to the document text.  IETF experience suggests
-      that these roles typically cannot all be handled by one person; a
-      minimum of four or five active participants in the management
-      positions are typically required in addition to a minimum of one
-      or two dozen people that will attend the working group meetings
-      and contribute on the mailing list.  NOTE: The interest must be
-      broad enough that a working group would not be seen as merely the
-      activity of a single vendor.
-
-    - Is there enough expertise within the IETF in the working group's
-      topic, and are those people interested in contributing in the
-      working group?
-
-    - Does a base of interested consumers (end-users) appear to exist
-      for the planned work?  Consumer interest can be measured by
-      participation of end-users within the IETF process, as well as by
-      less direct means.
-
-    - Does the IETF have a reasonable role to play in the determination
-      of the technology?  There are many Internet-related technologies
-      that may be interesting to IETF members but in some cases the IETF
-      may not be in a position to effect the course of the technology in
-      the "real world".  This can happen, for example, if the technology
-      is being developed by another standards body or an industry
-      consortium.
-
-    - Are all known intellectual property rights relevant to the
-      proposed working group's efforts issues understood?
-
-    - Is the proposed work plan an open IETF effort or is it an attempt
-      to "bless" non-IETF technology where the effect of input from IETF
-      participants may be limited?
-
-
-
-
-
-Bradner                  Best Current Practice                  [Page 5]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-    - Is there a good understanding of any existing work that is
-      relevant to the topics that the proposed working group is to
-      pursue?  This includes work within the IETF and elsewhere.
-
-    - Do the working group's goals overlap with known work in another
-      standards body, and if so is adequate liaison in place?
-
-   Considering the above criteria, the Area Director(s), using his or
-   her best judgement, will decide whether to pursue the formation of
-   the group through the chartering process.
-
-2.2. Charter
-
-   The formation of a working group requires a charter which is
-   primarily negotiated between a prospective working group Chair and
-   the relevant Area Director(s), although final approval is made by the
-   IESG with advice from the Internet Architecture Board (IAB).  A
-   charter is a contract between a working group and the IETF to perform
-   a set of tasks.  A charter:
-
-   1. Lists relevant administrative information for the working group;
-   2. Specifies the direction or objectives of the working group and
-      describes the approach that will be taken to achieve the goals;
-      and
-   3. Enumerates a set of milestones together with time frames for their
-      completion.
-
-   When the prospective Chair(s), the Area Director and the IETF
-   Secretariat are satisfied with the charter form and content, it
-   becomes the basis for forming a working group. Note that an Area
-   Director MAY require holding an exploratory Birds of a Feather (BOF)
-   meeting, as described below, to gage the level of support for a
-   working group before submitting the charter to the IESG and IAB for
-   approval.
-
-   Charters may be renegotiated periodically to reflect the current
-   status, organization or goals of the working group (see section 5).
-   Hence, a charter is a contract between the IETF and the working group
-   which is committing to meet explicit milestones and delivering
-   specific "products".
-
-   Specifically, each charter consists of the following sections:
-
-   Working group name
-      A working group name should be reasonably descriptive or
-      identifiable. Additionally, the group shall define an acronym
-      (maximum 8 printable ASCII characters) to reference the group in
-      the IETF directories, mailing lists, and general documents.
-
-
-
-Bradner                  Best Current Practice                  [Page 6]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   Chair(s)
-      The working group may have one or more Chairs to perform the
-      administrative functions of the group. The email address(es) of
-      the Chair(s) shall be included.  Generally, a working group is
-      limited to two chairs.
-
-   Area and Area Director(s)
-      The name of the IETF area with which the working group is
-      affiliated and the name and electronic mail address of the
-      associated Area Director(s).
-
-   Responsible Area Director
-      The Area Director who acts as the primary IESG contact for the
-      working group.
-
-   Mailing list
-      An IETF working group MUST have a general Internet mailing list.
-      Most of the work of an IETF working group will be conducted on the
-      mailing list. The working group charter MUST include:
-
-      1. The address to which a participant sends a subscription request
-         and the procedures to follow when subscribing,
-
-      2. The address to which a participant sends submissions and
-         special procedures, if any, and
-
-      3. The location of the mailing list archive. A message archive
-         MUST be maintained in a public place which can be accessed via
-         FTP or via the web.
-
-         As a service to the community, the IETF Secretariat operates a
-         mailing list archive for working group mailing lists. In order
-         to take advantage of this service, working group mailing lists
-         MUST include the address "wg_acronym-archive@lists.ietf.org"
-         (where "wg_acronym" is the working group acronym) in the
-         mailing list in order that a copy of all mailing list messages
-         be recorded in the Secretariat's archive.  Those archives are
-         located at ftp://ftp.ietf.org/ietf-mail-archive.  For
-         robustness, WGs SHOULD maintain an additional archive separate
-         from that maintained by the Secretariat.
-
-   Description of working group
-      The focus and intent of the group shall be set forth briefly. By
-      reading this section alone, an individual should be able to decide
-      whether this group is relevant to their own work. The first
-      paragraph must give a brief summary of the problem area, basis,
-      goal(s) and approach(es) planned for the working group.  This
-      paragraph can be used as an overview of the working group's
-
-
-
-Bradner                  Best Current Practice                  [Page 7]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-      effort.
-
-      To facilitate evaluation of the intended work and to provide on-
-      going guidance to the working group, the charter must describe the
-      problem being solved and should discuss objectives and expected
-      impact with respect to:
-
-         - Architecture
-         - Operations
-         - Security
-         - Network management
-         - Scaling
-         - Transition (where applicable)
-
-   Goals and milestones
-      The working group charter MUST establish a timetable for specific
-      work items.  While this may be renegotiated over time, the list of
-      milestones and dates facilitates the Area Director's tracking of
-      working group progress and status, and it is indispensable to
-      potential participants identifying the critical moments for input.
-      Milestones shall consist of deliverables that can be qualified as
-      showing specific achievement; e.g., "Internet-Draft finished" is
-      fine, but "discuss via email" is not. It is helpful to specify
-      milestones for every 3-6 months, so that progress can be gauged
-      easily.  This milestone list is expected to be updated
-      periodically (see section 5).
-
-      An example of a WG charter is included as Appendix A.
-
-2.3. Charter review & approval
-
-   Proposed working groups often comprise technically competent
-   participants who are not familiar with the history of Internet
-   architecture or IETF processes.  This can, unfortunately, lead to
-   good working group consensus about a bad design.  To facilitate
-   working group efforts, an Area Director may assign a Consultant from
-   among the ranks of senior IETF participants.  (Consultants are
-   described in section 6.)  At the discretion of the Area Director,
-   approval of a new WG may be withheld in the absence of sufficient
-   consultant resources.
-
-   Once the Area Director (and the Area Directorate, as the Area
-   Director deems appropriate) has approved the working group charter,
-   the charter is submitted for review by the IAB and approval by the
-   IESG.  After a review period of at least a week the proposed charter
-   is posted to the IETF-announce mailing list as a public notice that
-   the formation of the working group is being considered.  At the same
-   time the proposed charter is also posted to the "new-work" mailing
-
-
-
-Bradner                  Best Current Practice                  [Page 8]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   list.  This mailing list has been created to let qualified
-   representatives from other standards organizations know about pending
-   IETF working groups.  After another review period lasting at least a
-   week the IESG MAY approve the charter as-is, it MAY request that
-   changes be made in the charter, or MAY decline to approve chartering
-   of the working group
-
-   If the IESG approves the formation of the working group it remands
-   the approved charter to the IETF Secretariat who records and enters
-   the information into the IETF tracking database.  The working group
-   is announced to the IETF-announce a by the IETF Secretariat.
-
-2.4. Birds of a Feather (BOF)
-
-   Often it is not clear whether an issue merits the formation of a
-   working group.  To facilitate exploration of the issues the IETF
-   offers the possibility of a Birds of a Feather (BOF) session, as well
-   as the early formation of an email list for preliminary discussion.
-   In addition, a BOF may serve as a forum for a single presentation or
-   discussion, without any intent to form a working group.
-
-   A BOF is a session at an IETF meeting which permits "market research"
-   and technical "brainstorming".  Any individual may request permission
-   to hold a BOF on a subject. The request MUST be filed with a relevant
-   Area Director who must approve a BOF before it can be scheduled. The
-   person who requests the BOF may be asked to serve as Chair of the
-   BOF.
-
-   The Chair of the BOF is also responsible for providing a report on
-   the outcome of the BOF.  If the Area Director approves, the BOF is
-   then scheduled by submitting a request to agenda@ietf.org with copies
-   to the Area Director(s). A BOF description and agenda are required
-   before a BOF can be scheduled.
-
-   Available time for BOFs is limited, and BOFs are held at the
-   discretion of the ADs for an area.  The AD(s) may require additional
-   assurances before authorizing a BOF.  For example,
-
-    - The Area Director MAY require the establishment of an open email
-      list prior to authorizing a BOF.  This permits initial exchanges
-      and sharing of framework, vocabulary and approaches, in order to
-      make the time spent in the BOF more productive.
-
-    - The Area Director MAY require that a BOF be held, prior to
-      establishing a working group (see section 2.2).
-
-    - The Area Director MAY require that there be a draft of the WG
-      charter prior to holding a BOF.
-
-
-
-Bradner                  Best Current Practice                  [Page 9]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-    - The Area Director MAY require that a BOF not be held until an
-      Internet-Draft describing the proposed technology has been
-      published so it can be used as a basis for discussion in the BOF.
-
-   In general, a BOF on a particular topic is held only once (ONE slot
-   at one IETF Plenary meeting). Under unusual circumstances Area
-   Directors may, at their discretion, allow a BOF to meet for a second
-   time. BOFs are not permitted to meet three times.  Note that all
-   other things being equal, WGs will be given priority for meeting
-   space over BOFs.  Also, occasionally BOFs may be held for other
-   purposes than to discuss formation of a working group.
-
-   Usually the outcome of a BOF will be one of the following:
-
-    - There was enough interest and focus in the subject to warrant the
-      formation of a WG;
-
-    - While there was a reasonable level of interest expressed in the
-      BOF some other criteria for working group formation was not met
-      (see section 2.1).
-
-    - The discussion came to a fruitful conclusion, with results to be
-      written down and published, however there is no need to establish
-      a WG; or
-
-    - There was not enough interest in the subject to warrant the
-      formation of a WG.
-
-3.  Working Group Operation
-
-   The IETF has basic requirements for open and fair participation and
-   for thorough consideration of technical alternatives.  Within those
-   constraints, working groups are autonomous and each determines most
-   of the details of its own operation with respect to session
-   participation, reaching closure, etc. The core rule for operation is
-   that acceptance or agreement is achieved via working group "rough
-   consensus".  WG participants should specifically note the
-   requirements for disclosure of conflicts of interest in [2].
-
-   A number of procedural questions and issues will arise over time, and
-   it is the function of the Working Group Chair(s) to manage the group
-   process, keeping in mind that the overall purpose of the group is to
-   make progress towards reaching rough consensus in realizing the
-   working group's goals and objectives.
-
-   There are few hard and fast rules on organizing or conducting working
-   group activities, but a set of guidelines and practices has evolved
-   over time that have proven successful. These are listed here, with
-
-
-
-Bradner                  Best Current Practice                 [Page 10]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   actual choices typically determined by the working group participants
-   and the Chair(s).
-
-3.1. Session planning
-
-   For coordinated, structured WG interactions, the Chair(s) MUST
-   publish a draft agenda well in advance of the actual session. The
-   agenda should contain at least:
-
-   - The items for discussion;
-   - The estimated time necessary per item; and
-   - A clear indication of what documents the participants will need to
-     read before the session in order to be well prepared.
-
-   Publication of the working group agenda shall include sending a copy
-   of the agenda to the working group mailing list and to
-   agenda@ietf.org.
-
-   All working group actions shall be taken in a public forum, and wide
-   participation is encouraged. A working group will conduct much of its
-   business via electronic mail distribution lists but may meet
-   periodically to discuss and review task status and progress, to
-   resolve specific issues and to direct future activities.  IETF
-   Plenary meetings are the primary venue for these face-to-face working
-   group sessions, and it is common (though not required) that active
-   "interim" face-to-face meetings, telephone conferences, or video
-   conferences may also be held.  Interim meetings are subject to the
-   same rules for advance notification, reporting, open participation,
-   and process, which apply to other working group meetings.
-
-   All working group sessions (including those held outside of the IETF
-   meetings) shall be reported by making minutes available.  These
-   minutes should include the agenda for the session, an account of the
-   discussion including any decisions made, and a list of attendees. The
-   Working Group Chair is responsible for insuring that session minutes
-   are written and distributed, though the actual task may be performed
-   by someone designated by the Working Group Chair. The minutes shall
-   be submitted in printable ASCII text for publication in the IETF
-   Proceedings, and for posting in the IETF Directories and are to be
-   sent to: minutes@ietf.org
-
-3.2. Session venue
-
-   Each working group will determine the balance of email and face-to-
-   face sessions that is appropriate for achieving its milestones.
-   Electronic mail permits the widest participation; face-to-face
-   meetings often permit better focus and therefore can be more
-   efficient for reaching a consensus among a core of the working group
-
-
-
-Bradner                  Best Current Practice                 [Page 11]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   participants.  In determining the balance, the WG must ensure that
-   its process does not serve to exclude contribution by email-only
-   participants.  Decisions reached during a face-to-face meeting about
-   topics or issues which have not been discussed on the mailing list,
-   or are significantly different from previously arrived mailing list
-   consensus MUST be reviewed on the mailing list.
-
-   IETF Meetings
-   If a WG needs a session at an IETF meeting, the Chair must apply for
-   time-slots as soon as the first announcement of that IETF meeting is
-   made by the IETF Secretariat to the WG-chairs list.  Session time is
-   a scarce resource at IETF meetings, so placing requests early will
-   facilitate schedule coordination for WGs requiring the same set of
-   experts.
-
-   The application for a WG session at an IETF meeting MUST be made to
-   the IETF Secretariat at the address agenda@ietf.org.  Some Area
-   Directors may want to coordinate WG sessions in their area and
-   request that time slots be coordinated through them.  If this is the
-   case it will be noted in the IETF meeting announcement. A WG
-   scheduling request MUST contain:
-
-   - The working group name and full title;
-   - The amount of time requested;
-   - The rough outline of the WG agenda that is expected to be covered;
-   - The estimated number of people that will attend the WG session;
-   - Related WGs that should not be scheduled for the same time slot(s);
-     and
-   - Optionally a request can be added for the WG session to be
-     transmitted over the Internet in audio and video.
-
-   NOTE: While open discussion and contribution is essential to working
-   group success, the Chair is responsible for ensuring forward
-   progress.  When acceptable to the WG, the Chair may call for
-   restricted participation (but not restricted attendance!) at IETF
-   working group sessions for the purpose of achieving progress. The
-   Working Group Chair then has the authority to refuse to grant the
-   floor to any individual who is unprepared or otherwise covering
-   inappropriate material, or who, in the opinion of the Chair is
-   disrupting the WG process.  The Chair should consult with the Area
-   Director(s) if the individual persists in disruptive behavior.
-
-   On-line
-   It can be quite useful to conduct email exchanges in the same manner
-   as a face-to-face session, with published schedule and agenda, as
-   well as on-going summarization and consensus polling.
-
-
-
-
-
-Bradner                  Best Current Practice                 [Page 12]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   Many working group participants hold that mailing list discussion is
-   the best place to consider and resolve issues and make decisions. The
-   choice of operational style is made by the working group itself.  It
-   is important to note, however, that Internet email discussion is
-   possible for a much wider base of interested persons than is
-   attendance at IETF meetings, due to the time and expense required to
-   attend.
-
-   As with face-to-face sessions occasionally one or more individuals
-   may engage in behavior on a mailing list which disrupts the WG's
-   progress.  In these cases the Chair should attempt to discourage the
-   behavior by communication directly with the offending individual
-   rather than on the open mailing list.  If the behavior persists then
-   the Chair must involve the Area Director in the issue.  As a last
-   resort and after explicit warnings, the Area Director, with the
-   approval of the IESG, may request that the mailing list maintainer
-   block the ability of the offending individual to post to the mailing
-   list. (If the mailing list software permits this type of operation.)
-   Even if this is done, the individual must not be prevented from
-   receiving messages posted to the list.  Other methods of mailing list
-   control may be considered but must be approved by the AD(s) and the
-   IESG.
-
-3.3. Session management
-
-   Working groups make decisions through a "rough consensus" process.
-   IETF consensus does not require that all participants agree although
-   this is, of course, preferred.  In general, the dominant view of the
-   working group shall prevail.  (However, it must be noted that
-   "dominance" is not to be determined on the basis of volume or
-   persistence, but rather a more general sense of agreement.) Consensus
-   can be determined by a show of hands, humming, or any other means on
-   which the WG agrees (by rough consensus, of course).  Note that 51%
-   of the working group does not qualify as "rough consensus" and 99% is
-   better than rough.  It is up to the Chair to determine if rough
-   consensus has been reached.
-
-   It can be particularly challenging to gauge the level of consensus on
-   a mailing list.  There are two different cases where a working group
-   may be trying to understand the level of consensus via a mailing list
-   discussion. But in both cases the volume of messages on a topic is
-   not, by itself, a good indicator of consensus since one or two
-   individuals may be generating much of the traffic.
-
-   In the case where a consensus which has been reached during a face-
-   to-face meeting is being verified on a mailing list the people who
-   were in the meeting and expressed agreement must be taken into
-   account.  If there were 100 people in a meeting and only a few people
-
-
-
-Bradner                  Best Current Practice                 [Page 13]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   on the mailing list disagree with the consensus of the meeting then
-   the consensus should be seen as being verified.  Note that enough
-   time should be given to the verification process for the mailing list
-   readers to understand and consider any objections that may be raised
-   on the list.  The normal two week last-call period should be
-   sufficient for this.
-
-   The other case is where the discussion has been held entirely over
-   the mailing list.  The determination of the level of consensus may be
-   harder to do in this case since most people subscribed to mailing
-   lists do not actively participate in discussions on the list. It is
-   left to the discretion of the working group chair how to evaluate the
-   level of consensus.  The most common method used is for the working
-   group chair to state what he or she believes to be the consensus view
-   and. at the same time, requests comments from the list about the
-   stated conclusion.
-
-   The challenge to managing working group sessions is to balance the
-   need for open and fair consideration of the issues against the need
-   to make forward progress.  The working group, as a whole, has the
-   final responsibility for striking this balance.  The Chair has the
-   responsibility for overseeing the process but may delegate direct
-   process management to a formally-designated Facilitator.
-
-   It is occasionally appropriate to revisit a topic, to re-evaluate
-   alternatives or to improve the group's understanding of a relevant
-   decision.  However, unnecessary repeated discussions on issues can be
-   avoided if the Chair makes sure that the main arguments in the
-   discussion (and the outcome) are summarized and archived after a
-   discussion has come to conclusion. It is also good practice to note
-   important decisions/consensus reached by email in the minutes of the
-   next 'live' session, and to summarize briefly the decision-making
-   history in the final documents the WG produces.
-
-   To facilitate making forward progress, a Working Group Chair may wish
-   to decide to reject or defer the input from a member, based upon the
-   following criteria:
-
-   Old
-   The input pertains to a topic that already has been resolved and is
-   redundant with information previously available;
-
-   Minor
-   The input is new and pertains to a topic that has already been
-   resolved, but it is felt to be of minor import to the existing
-   decision;
-
-
-
-
-
-Bradner                  Best Current Practice                 [Page 14]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   Timing
-   The input pertains to a topic that the working group has not yet
-   opened for discussion; or
-
-   Scope
-   The input is outside of the scope of the working group charter.
-
-3.4. Contention and appeals
-
-   Disputes are possible at various stages during the IETF process. As
-   much as possible the process is designed so that compromises can be
-   made, and genuine consensus achieved; however, there are times when
-   even the most reasonable and knowledgeable people are unable to
-   agree.  To achieve the goals of openness and fairness, such conflicts
-   must be resolved by a process of open review and discussion.
-
-   Formal procedures for requesting a review of WG, Chair, Area Director
-   or IESG actions and conducting appeals are documented in The Internet
-   Standards Process [1].
-
-4. Working Group Termination
-
-   Working groups are typically chartered to accomplish a specific task
-   or tasks.  After the tasks are complete, the group will be disbanded.
-   However, if a WG produces a Proposed or Draft Standard, the WG will
-   frequently become dormant rather than disband (i.e., the WG will no
-   longer conduct formal activities, but the mailing list will remain
-   available to review the work as it moves to Draft Standard and
-   Standard status.)
-
-   If, at some point, it becomes evident that a working group is unable
-   to complete the work outlined in the charter, or if the assumptions
-   which that work was based have been modified in discussion or by
-   experience, the Area Director, in consultation with the working group
-   can either:
-
-   1. Recharter to refocus its tasks,
-   2. Choose new Chair(s), or
-   3. Disband.
-
-   If the working group disagrees with the Area Director's choice, it
-   may appeal to the IESG (see section 3.4).
-
-5. Rechartering a Working Group
-
-   Updated milestones are renegotiated with the Area Director and the
-   IESG, as needed, and then are submitted to the IESG Secretariat:
-   iesg-secretary@ietf.org.
-
-
-
-Bradner                  Best Current Practice                 [Page 15]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   Rechartering (other than revising milestones) a working group follows
-   the same procedures that the initial chartering does (see section 2).
-   The revised charter must be submitted to the IESG and IAB for
-   approval.  As with the initial chartering, the IESG may approve new
-   charter as-is, it may request that changes be made in the new charter
-   (including having the Working Group continue to use the old charter),
-   or it may decline to approve the rechartered working group.  In the
-   latter case, the working group is disbanded.
-
-6. Staff Roles
-
-   Working groups require considerable care and feeding.  In addition to
-   general participation, successful working groups benefit from the
-   efforts of participants filling specific functional roles.  The Area
-   Director must agree to the specific people performing the WG Chair,
-   and Working Group Consultant roles, and they serve at the discretion
-   of the Area Director.
-
-6.1. WG Chair
-
-   The Working Group Chair is concerned with making forward progress
-   through a fair and open process, and has wide discretion in the
-   conduct of WG business.  The Chair must ensure that a number of tasks
-   are performed, either directly or by others assigned to the tasks.
-
-   The Chair has the responsibility and the authority to make decisions,
-   on behalf of the working group, regarding all matters of working
-   group process and staffing, in conformance with the rules of the
-   IETF.  The AD has the authority and the responsibility to assist in
-   making those decisions at the request of the Chair or when
-   circumstances warrant such an intervention.
-
-   The Chair's responsibility encompasses at least the following:
-
-   Ensure WG process and content management
-
-      The Chair has ultimate responsibility for ensuring that a working
-      group achieves forward progress and meets its milestones.  The
-      Chair is also responsible to ensure that the working group
-      operates in an open and fair manner.  For some working groups,
-      this can be accomplished by having the Chair perform all
-      management-related activities.  In other working groups --
-      particularly those with large or divisive participation -- it is
-      helpful to allocate process and/or secretarial functions to other
-      participants.  Process management pertains strictly to the style
-      of working group interaction and not to its content. It ensures
-      fairness and detects redundancy.  The secretarial function
-      encompasses document editing.  It is quite common for a working
-
-
-
-Bradner                  Best Current Practice                 [Page 16]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-      group to assign the task of specification Editor to one or two
-      participants.  Sometimes, they also are part of the design team,
-      described below.
-
-   Moderate the WG email list
-
-      The Chair should attempt to ensure that the discussions on this
-      list are relevant and that they converge to consensus agreements.
-      The Chair should make sure that discussions on the list are
-      summarized and that the outcome is well documented (to avoid
-      repetition).  The Chair also may choose to schedule organized on-
-      line "sessions" with agenda and deliverables.  These can be
-      structured as true meetings, conducted over the course of several
-      days (to allow participation across the Internet).
-
-      Organize, prepare and chair face-to-face and on-line formal
-      sessions.
-
-   Plan WG Sessions
-
-      The Chair must plan and announce all WG sessions well in advance
-      (see section 3.1).
-
-   Communicate results of sessions
-
-      The Chair and/or Secretary must ensure that minutes of a session
-      are taken and that an attendance list is circulated (see section
-      3.1).
-
-      Immediately after a session, the WG Chair MUST provide the Area
-      Director with a very short report (approximately one paragraph,
-      via email) on the session.
-
-   Distribute the workload
-
-      Of course, each WG will have participants who may not be able (or
-      want) to do any work at all. Most of the time the bulk of the work
-      is done by a few dedicated participants. It is the task of the
-      Chair to motivate enough experts to allow for a fair distribution
-      of the workload.
-
-   Document development
-
-      Working groups produce documents and documents need authors. The
-      Chair must make sure that authors of WG documents incorporate
-      changes as agreed to by the WG (see section 6.3).
-
-
-
-
-
-Bradner                  Best Current Practice                 [Page 17]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   Document publication
-
-      The Chair and/or Document Editor will work with the RFC Editor to
-      ensure document conformance with RFC publication requirements [5]
-      and to coordinate any editorial changes suggested by the RFC
-      Editor.  A particular concern is that all participants are working
-      from the same version of a document at the same time.
-
-   Document implementations
-
-      Under the procedures described in [1], the Chair is responsible
-      for documenting the specific implementations which qualify the
-      specification for Draft or Internet Standard status along with
-      documentation about testing of the interoperation of these
-      implementations.
-
-6.2. WG Secretary
-
-   Taking minutes and editing working group documents often is performed
-   by a specifically-designated participant or set of participants.  In
-   this role, the Secretary's job is to record WG decisions, rather than
-   to perform basic specification.
-
-6.3. Document Editor
-
-   Most IETF working groups focus their efforts on a document, or set of
-   documents, that capture the results of the group's work.  A working
-   group generally designates a person or persons to serve as the Editor
-   for a particular document.  The Document Editor is responsible for
-   ensuring that the contents of the document accurately reflect the
-   decisions that have been made by the working group.
-
-   As a general practice, the Working Group Chair and Document Editor
-   positions are filled by different individuals to help ensure that the
-   resulting documents accurately reflect the consensus of the working
-   group and that all processes are followed.
-
-6.4. WG Facilitator
-
-   When meetings tend to become distracted or divisive, it often is
-   helpful to assign the task of "process management" to one
-   participant.  Their job is to oversee the nature, rather than the
-   content, of participant interactions.  That is, they attend to the
-   style of the discussion and to the schedule of the agenda, rather
-   than making direct technical contributions themselves.
-
-
-
-
-
-
-Bradner                  Best Current Practice                 [Page 18]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-6.5. Design teams
-
-   It is often useful, and perhaps inevitable, for a sub-group of a
-   working group to develop a proposal to solve a particular problem.
-   Such a sub-group is called a design team.  In order for a design team
-   to remain small and agile, it is acceptable to have closed membership
-   and private meetings.  Design teams may range from an informal chat
-   between people in a hallway to a formal set of expert volunteers that
-   the WG chair or AD appoints to attack a controversial problem.  The
-   output of a design team is always subject to approval, rejection or
-   modification by the WG as a whole.
-
-6.6. Working Group Consultant
-
-   At the discretion of the Area Director, a Consultant may be assigned
-   to a working group.  Consultants have specific technical background
-   appropriate to the WG and experience in Internet architecture and
-   IETF process.
-
-6.7. Area Director
-
-   Area Directors are responsible for ensuring that working groups in
-   their area produce coherent, coordinated, architecturally consistent
-   and timely output as a contribution to the overall results of the
-   IETF.
-
-7.  Working Group Documents
-
-7.1. Session documents
-
-   All relevant documents to be discussed at a session should be
-   published and available as Internet-Drafts at least two weeks before
-   a session starts.  Any document which does not meet this publication
-   deadline can only be discussed in a working group session with the
-   specific approval of the working group chair(s).  Since it is
-   important that working group members have adequate time to review all
-   documents, granting such an exception should only be done under
-   unusual conditions.  The final session agenda should be posted to the
-   working group mailing list at least two weeks before the session and
-   sent at that time to agenda@ietf.org for publication on the IETF web
-   site.
-
-7.2. Internet-Drafts (I-D)
-
-   The Internet-Drafts directory is provided to working groups as a
-   resource for posting and disseminating in-process copies of working
-   group documents. This repository is replicated at various locations
-   around the Internet. It is encouraged that draft documents be posted
-
-
-
-Bradner                  Best Current Practice                 [Page 19]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   as soon as they become reasonably stable.
-
-   It is stressed here that Internet-Drafts are working documents and
-   have no official standards status whatsoever. They may, eventually,
-   turn into a standards-track document or they may sink from sight.
-   Internet-Drafts are submitted to: internet-drafts@ietf.org
-
-   The format of an Internet-Draft must be the same as for an RFC [2].
-   Further, an I-D must contain:
-
-   - Beginning, standard, boilerplate text which is provided by the
-     Secretariat on their web site and in the ftp directory;
-   - The I-D filename; and
-   - The expiration date for the I-D.
-
-   Complete specification of requirements for an Internet-Draft are
-   found in the file "1id-guidelines.txt" in the Internet-Drafts
-   directory at an Internet Repository site.  The organization of the
-   Internet-Drafts directory is found in the file "1id-organization" in
-   the Internet-Drafts directory at an Internet Repository site.  This
-   file also contains the rules for naming Internet-Drafts.  (See [1]
-   for more information about Internet-Drafts.)
-
-7.3. Request For Comments (RFC)
-
-   The work of an IETF working group often results in publication of one
-   or more documents, as part of the Request For Comments (RFCs) [1]
-   series. This series is the archival publication record for the
-   Internet community. A document can be written by an individual in a
-   working group, by a group as a whole with a designated Editor, or by
-   others not involved with the IETF.
-
-   NOTE: The RFC series is a publication mechanism only and publication
-   does not determine the IETF status of a document.  Status is
-   determined through separate, explicit status labels assigned by the
-   IESG on behalf of the IETF.  In other words, the reader is reminded
-   that all Internet Standards are published as RFCs, but NOT all RFCs
-   specify standards [4].
-
-7.4. Working Group Last-Call
-
-   When a WG decides that a document is ready for publication it may be
-   submitted to the IESG for consideration. In most cases the
-   determination that a WG feels that a document is ready for
-   publication is done by the WG Chair issuing a working group Last-
-   Call.  The decision to issue a working group Last-Call is at the
-   discretion of the WG Chair working with the Area Director.  A working
-   group Last-Call serves the same purpose within a working group that
-
-
-
-Bradner                  Best Current Practice                 [Page 20]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   an IESG Last-Call does in the broader IETF community (see [1]).
-
-7.5. Submission of documents
-
-   Once that a WG has determined at least rough consensus exists within
-   the WG for the advancement of a document the following must be done:
-
-   - The version of the relevant document exactly as agreed to by the WG
-     MUST be in the Internet-Drafts directory.
-
-   - The relevant document MUST be formatted according to section 7.3.
-
-   - The WG Chair MUST send email to the relevant Area Director.  A copy
-     of the request MUST be also sent to the IESG Secretariat.  The mail
-     MUST contain the reference to the document's ID filename, and the
-     action requested.  The copy of the message to the IESG Secretariat
-     is to ensure that the request gets recorded by the Secretariat so
-     that they can monitor the progress of the document through the
-     process.
-
-   Unless returned by the IESG to the WG for further development,
-   progressing of the document is then the responsibility of the IESG.
-   After IESG approval, responsibility for final disposition is the
-   joint responsibility of the RFC Editor, the WG Chair and the Document
-   Editor.
-
-8. Review of documents
-
-   The IESG reviews all documents submitted for publication as RFCs.
-   Usually minimal IESG review is necessary in the case of a submission
-   from a WG intended as an Informational or Experimental RFC. More
-   extensive review is undertaken in the case of standards-track
-   documents.
-
-   Prior to the IESG beginning their deliberations on standards-track
-   documents, IETF Secretariat will issue a "Last-Call" to the IETF
-   mailing list (see [1]). This Last Call will announce the intention of
-   the IESG to consider the document, and it will solicit final comments
-   from the IETF within a period of two weeks.  It is important to note
-   that a Last-Call is intended as a brief, final check with the
-   Internet community, to make sure that no important concerns have been
-   missed or misunderstood. The Last-Call should not serve as a more
-   general, in-depth review.
-
-   The IESG review takes into account responses to the Last-Call and
-   will lead to one of these possible conclusions:
-
-
-
-
-
-Bradner                  Best Current Practice                 [Page 21]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   1. The document is accepted as is for the status requested.
-      This fact will be announced by the IETF Secretariat to the IETF
-      mailing list and to the RFC Editor.
-
-   2. The document is accepted as-is but not for the status requested.
-      This fact will be announced by the IETF Secretariat to the IETF
-      mailing list and to the RFC Editor (see [1] for more details).
-
-   3. Changes regarding content are suggested to the author(s)/WG.
-      Suggestions from the IESG must be clear and direct, so as to
-      facilitate working group and author correction of the
-      specification.  If the author(s)/WG can explain to the
-      satisfaction of the IESG why the changes are not necessary, the
-      document will be accepted for publication as under point 1, above.
-      If the changes are made the revised document may be resubmitted
-      for IESG review.
-
-   4. Changes are suggested by the IESG and a change in status is
-      recommended.
-      The process described above for 3 and 2 are followed in that
-      order.
-
-   5. The document is rejected.
-      Any document rejection will be accompanied by specific and
-      thorough arguments from the IESG. Although the IETF and working
-      group process is structured such that this alternative is not
-      likely to arise for documents coming from a working group, the
-      IESG has the right and responsibility to reject documents that the
-      IESG feels are fatally flawed in some way.
-
-      If any individual or group of individuals feels that the review
-      treatment has been unfair, there is the opportunity to make a
-      procedural complaint. The mechanism for this type of complaints is
-      described in [1].
-
-9. Security Considerations
-
-   Documents describing IETF processes, such as this one, do not have an
-   impact on the security of the network infrastructure or of Internet
-   applications.
-
-   It should be noted that all IETF working groups are required to
-   examine and understand the security implications of any technology
-   they develop.  This analysis must be included in any resulting RFCs
-   in a Security Considerations section.  Note that merely noting a
-   significant security hole is no longer sufficient.  IETF developed
-   technologies should not add insecurity to the environment in which
-   they are run.
-
-
-
-Bradner                  Best Current Practice                 [Page 22]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-10. Acknowledgments
-
-   This revision of this document relies heavily on the previous version
-   (RFC 1603) which was edited by Erik Huizer and Dave Crocker.  It has
-   been reviewed by the Poisson Working Group.
-
-11. References
-
-   [1] Bradner, S., Editor, "The Internet Standards Process -- Revision
-       3", BCP 9, RFC 2026, October 1996.
-
-   [2] Hovey, R., and S. Bradner, "The Organizations involved in the
-       IETF Standards Process", BCP 11, RFC 2028, October 1996.
-
-   [3] Gavin, J., "IAB and IESG Selection, Confirmation, and Recall
-       Process: Operation of the Nominating and Recall Committees", BCP
-       10, RFC 2282, February 1998.
-
-   [4] Huitema, C., J. Postel, S. Crocker, "Not all RFCs are Standards",
-       RFC 1796, April 1995.
-
-   [5] Postel, J., and J. Reynolds, "Instructions to RFC Authors", RFC
-       2223, October 1997.
-
-   [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
-       Level", BCP 14, RFC 2119, March 1997.
-
-
-12. Editor's Address
-
-   Scott Bradner
-   Harvard University
-   1350 Mass Ave.
-   Cambridge MA
-   02138
-   USA
-
-   Phone +1 617 495 3864
-   EMail: sob@harvard.edu
-
-
-
-
-
-
-
-
-
-
-
-
-Bradner                  Best Current Practice                 [Page 23]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   Appendix:  Sample Working Group Charter
-
-   Working Group Name:
-        IP Telephony (iptel)
-
-   IETF Area:
-        Transport Area
-
-   Chair(s):
-        Jonathan Rosenberg <jdrosen@bell-labs.com>
-
-   Transport Area Director(s):
-        Scott Bradner <sob@harvard.edu>
-        Allyn Romanow <allyn@mci.net>
-
-   Responsible Area Director:
-        Allyn Romanow <allyn@mci.net>
-
-   Mailing Lists:
-        General Discussion:iptel@lists.research.bell-labs.com
-        To Subscribe: iptel-request@lists.research.bell-labs.com
-        Archive: http://www.bell-labs.com/mailing-lists/siptel
-
-   Description of Working Group:
-
-   Before Internet telephony can become a widely deployed service, a
-   number of protocols must be deployed. These include signaling and
-   capabilities exchange, but also include a number of "peripheral"
-   protocols for providing related services.
-
-   The primary purpose of this working group is to develop two such
-   supportive protocols and a frameword document. They are:
-
-   1. Call Processing Syntax. When a call is setup between two
-   endpoints, the signaling will generally pass through several servers
-   (such as an H.323 gatekeeper) which are responsible for forwarding,
-   redirecting, or proxying the signaling messages. For example, a user
-   may make a call to j.doe@bigcompany.com. The signaling message to
-   initiate the call will arrive at some server at bigcompany. This
-   server can inform the caller that the callee is busy, forward the
-   call initiation request to another server closer to the user, or drop
-   the call completely (among other possibilities). It is very desirable
-   to allow the callee to provide input to this process, guiding the
-   server in its decision on how to act. This can enable a wide variety
-   of advanced personal mobility and call agent services.
-
-
-
-
-
-
-Bradner                  Best Current Practice                 [Page 24]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-   Such preferences can be expressed in a call processing syntax, which
-   can be authored by the user (or generated automatically by some
-   tool), and then uploaded to the server. The group will develop this
-   syntax, and specify means of securely transporting and extending it.
-   The result will be a single standards track RFC.
-
-   2. In addition, the group will write a service model document, which
-   describes the services that are enabled by the call processing
-   syntax, and discusses how the syntax can be used. This document will
-   result in a single RFC.
-
-   3. Gateway Attribute Distribution Protocol. When making a call
-   between an IP host and a PSTN user, a telephony gateway must be used.
-   The selection of such gateways can be based on many criteria,
-   including client expressed preferences, service provider preferences,
-   and availability of gateways, in addition to destination telephone
-   number.  Since gateways outside of the hosts' administrative domain
-   might be used, a protocol is required to allow gateways in remote
-   domains to distribute their attributes (such as PSTN connectivity,
-   supported codecs, etc.) to entities in other domains which must make
-   a selection of a gateway. The protocol must allow for scalable,
-   bandwidth efficient, and very secure transmission of these
-   attributes. The group will investigate and design a protocol for this
-   purpose, generate an Internet Draft, and advance it to RFC as
-   appropriate.
-
-   Goals and Milestones:
-
-   May 98    Issue first Internet-Draft on service framework
-   Jul 98    Submit framework ID to IESG for publication as an RFC.
-   Aug 98    Issue first Internet-Draft on Call Processing Syntax
-   Oct 98    Submit Call processing syntax to IESG for consideration
-             as a Proposed Standard.
-   Dec 98    Achieve consensus on basics of gateway attribute
-             distribution protocol
-   Jan 99    Submit Gateway Attribute Distribution protocol to IESG
-             for consideration as a RFC (info, exp, stds track TB
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bradner                  Best Current Practice                 [Page 25]
-
-RFC 2418                Working Group Guidelines          September 1998
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1998).  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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bradner                  Best Current Practice                 [Page 26]
-
diff --git a/contrib/bind9/doc/rfc/rfc2535.txt b/contrib/bind9/doc/rfc/rfc2535.txt
deleted file mode 100644
index fe0b3d0..0000000
--- a/contrib/bind9/doc/rfc/rfc2535.txt
+++ /dev/null
@@ -1,2635 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         D. Eastlake
-Request for Comments: 2535                                            IBM
-Obsoletes: 2065                                                March 1999
-Updates: 2181, 1035, 1034
-Category: Standards Track
-
-                 Domain Name System Security Extensions
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   Extensions to the Domain Name System (DNS) are described that provide
-   data integrity and authentication to security aware resolvers and
-   applications through the use of cryptographic digital signatures.
-   These digital signatures are included in secured zones as resource
-   records.  Security can also be provided through non-security aware
-   DNS servers in some cases.
-
-   The extensions provide for the storage of authenticated public keys
-   in the DNS.  This storage of keys can support general public key
-   distribution services as well as DNS security.  The stored keys
-   enable security aware resolvers to learn the authenticating key of
-   zones in addition to those for which they are initially configured.
-   Keys associated with DNS names can be retrieved to support other
-   protocols.  Provision is made for a variety of key types and
-   algorithms.
-
-   In addition, the security extensions provide for the optional
-   authentication of DNS protocol transactions and requests.
-
-   This document incorporates feedback on RFC 2065 from early
-   implementers and potential users.
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 1]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-Acknowledgments
-
-   The significant contributions and suggestions of the following
-   persons (in alphabetic order) to DNS security are gratefully
-   acknowledged:
-
-      James M. Galvin
-      John Gilmore
-      Olafur Gudmundsson
-      Charlie Kaufman
-      Edward Lewis
-      Thomas Narten
-      Radia J. Perlman
-      Jeffrey I. Schiller
-      Steven (Xunhua) Wang
-      Brian Wellington
-
-Table of Contents
-
-   Abstract...................................................1
-   Acknowledgments............................................2
-   1. Overview of Contents....................................4
-   2. Overview of the DNS Extensions..........................5
-   2.1 Services Not Provided..................................5
-   2.2 Key Distribution.......................................5
-   2.3 Data Origin Authentication and Integrity...............6
-   2.3.1 The SIG Resource Record..............................7
-   2.3.2 Authenticating Name and Type Non-existence...........7
-   2.3.3 Special Considerations With Time-to-Live.............7
-   2.3.4 Special Considerations at Delegation Points..........8
-   2.3.5 Special Considerations with CNAME....................8
-   2.3.6 Signers Other Than The Zone..........................9
-   2.4 DNS Transaction and Request Authentication.............9
-   3. The KEY Resource Record................................10
-   3.1 KEY RDATA format......................................10
-   3.1.1 Object Types, DNS Names, and Keys...................11
-   3.1.2 The KEY RR Flag Field...............................11
-   3.1.3 The Protocol Octet..................................13
-   3.2 The KEY Algorithm Number Specification................14
-   3.3 Interaction of Flags, Algorithm, and Protocol Bytes...15
-   3.4 Determination of Zone Secure/Unsecured Status.........15
-   3.5 KEY RRs in the Construction of Responses..............17
-   4. The SIG Resource Record................................17
-   4.1 SIG RDATA Format......................................17
-   4.1.1 Type Covered Field..................................18
-   4.1.2 Algorithm Number Field..............................18
-   4.1.3 Labels Field........................................18
-   4.1.4 Original TTL Field..................................19
-
-
-
-Eastlake                    Standards Track                     [Page 2]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   4.1.5 Signature Expiration and Inception Fields...........19
-   4.1.6 Key Tag Field.......................................20
-   4.1.7 Signer's Name Field.................................20
-   4.1.8 Signature Field.....................................20
-   4.1.8.1 Calculating Transaction and Request SIGs..........21
-   4.2 SIG RRs in the Construction of Responses..............21
-   4.3 Processing Responses and SIG RRs......................22
-   4.4 Signature Lifetime, Expiration, TTLs, and Validity....23
-   5. Non-existent Names and Types...........................24
-   5.1 The NXT Resource Record...............................24
-   5.2 NXT RDATA Format......................................25
-   5.3 Additional Complexity Due to Wildcards................26
-   5.4 Example...............................................26
-   5.5 Special Considerations at Delegation Points...........27
-   5.6 Zone Transfers........................................27
-   5.6.1 Full Zone Transfers.................................28
-   5.6.2 Incremental Zone Transfers..........................28
-   6. How to Resolve Securely and the AD and CD Bits.........29
-   6.1 The AD and CD Header Bits.............................29
-   6.2 Staticly Configured Keys..............................31
-   6.3 Chaining Through The DNS..............................31
-   6.3.1 Chaining Through KEYs...............................31
-   6.3.2 Conflicting Data....................................33
-   6.4 Secure Time...........................................33
-   7. ASCII Representation of Security RRs...................34
-   7.1 Presentation of KEY RRs...............................34
-   7.2 Presentation of SIG RRs...............................35
-   7.3 Presentation of NXT RRs...............................36
-   8. Canonical Form and Order of Resource Records...........36
-   8.1 Canonical RR Form.....................................36
-   8.2 Canonical DNS Name Order..............................37
-   8.3 Canonical RR Ordering Within An RRset.................37
-   8.4 Canonical Ordering of RR Types........................37
-   9. Conformance............................................37
-   9.1 Server Conformance....................................37
-   9.2 Resolver Conformance..................................38
-   10. Security Considerations...............................38
-   11. IANA Considerations...................................39
-   References................................................39
-   Author's Address..........................................41
-   Appendix A: Base 64 Encoding..............................42
-   Appendix B: Changes from RFC 2065.........................44
-   Appendix C: Key Tag Calculation...........................46
-   Full Copyright Statement..................................47
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 3]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-1. Overview of Contents
-
-   This document standardizes extensions of the Domain Name System (DNS)
-   protocol to support DNS security and public key distribution. It
-   assumes that the reader is familiar with the Domain Name System,
-   particularly as described in RFCs 1033, 1034, 1035 and later RFCs. An
-   earlier version of these extensions appears in RFC 2065.  This
-   replacement for that RFC incorporates early implementation experience
-   and requests from  potential users.
-
-   Section 2 provides an overview of the extensions and the key
-   distribution, data origin authentication, and transaction and request
-   security they provide.
-
-   Section 3 discusses the KEY resource record, its structure, and use
-   in DNS responses.  These resource records represent the public keys
-   of entities named in the DNS and are used for key distribution.
-
-   Section 4 discusses the SIG digital signature resource record, its
-   structure, and use in DNS responses.  These resource records are used
-   to authenticate other resource records in the DNS and optionally to
-   authenticate DNS transactions and requests.
-
-   Section 5 discusses the NXT resource record (RR) and its use in DNS
-   responses including full and incremental zone transfers.  The NXT RR
-   permits authenticated denial of the existence of a name or of an RR
-   type for an existing name.
-
-   Section 6 discusses how a resolver can be configured with a starting
-   key or keys and proceed to securely resolve DNS requests.
-   Interactions between resolvers and servers are discussed for various
-   combinations of security aware and security non-aware.  Two
-   additional DNS header bits are defined for signaling between
-   resolvers and servers.
-
-   Section 7 describes the ASCII representation of the security resource
-   records for use in master files and elsewhere.
-
-   Section 8 defines the canonical form and order of RRs for DNS
-   security purposes.
-
-   Section 9 defines levels of conformance for resolvers and servers.
-
-   Section 10 provides a few paragraphs on overall security
-   considerations.
-
-   Section 11 specified IANA considerations for allocation of additional
-   values of paramters defined in this document.
-
-
-
-Eastlake                    Standards Track                     [Page 4]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   Appendix A gives details of base 64 encoding which is used in the
-   file representation of some RRs defined in this document.
-
-   Appendix B summarizes changes between this memo and RFC 2065.
-
-   Appendix C specified how to calculate the simple checksum used as a
-   key tag in most SIG RRs.
-
-   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].
-
-2. Overview of the DNS Extensions
-
-   The Domain Name System (DNS) protocol security extensions provide
-   three distinct services: key distribution as described in Section 2.2
-   below, data origin authentication as described in Section 2.3 below,
-   and transaction and request authentication, described in Section 2.4
-   below.
-
-   Special considerations related to "time to live", CNAMEs, and
-   delegation points are also discussed in Section 2.3.
-
-2.1 Services Not Provided
-
-   It is part of the design philosophy of the DNS that the data in it is
-   public and that the DNS gives the same answers to all inquirers.
-   Following this philosophy, no attempt has been made to include any
-   sort of access control lists or other means to differentiate
-   inquirers.
-
-   No effort has been made to provide for any confidentiality for
-   queries or responses.  (This service may be available via IPSEC [RFC
-   2401], TLS, or other security protocols.)
-
-   Protection is not provided against denial of service.
-
-2.2 Key Distribution
-
-   A resource record format is defined to associate keys with DNS names.
-   This permits the DNS to be used as a public key distribution
-   mechanism in support of DNS security itself and other protocols.
-
-   The syntax of a KEY resource record (RR) is described in Section 3.
-   It includes an algorithm identifier, the actual public key
-   parameter(s), and a variety of flags including those indicating the
-   type of entity the key is associated with and/or asserting that there
-   is no key associated with that entity.
-
-
-
-Eastlake                    Standards Track                     [Page 5]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   Under conditions described in Section 3.5, security aware DNS servers
-   will automatically attempt to return KEY resources as additional
-   information, along with those resource records actually requested, to
-   minimize the number of queries needed.
-
-2.3 Data Origin Authentication and Integrity
-
-   Authentication is provided by associating with resource record sets
-   (RRsets [RFC 2181]) in the DNS cryptographically generated digital
-   signatures. Commonly, there will be a single private key that
-   authenticates an entire zone but there might be multiple keys for
-   different algorithms, signers, etc. If a security aware resolver
-   reliably learns a public key of the zone, it can authenticate, for
-   signed data read from that zone, that it is properly authorized.  The
-   most secure implementation is for the zone private key(s) to be kept
-   off-line and used to re-sign all of the records in the zone
-   periodically.  However, there are cases, for example dynamic update
-   [RFCs 2136, 2137], where DNS private keys need to be on-line [RFC
-   2541].
-
-   The data origin authentication key(s) are associated with the zone
-   and not with the servers that store copies of the data.  That means
-   compromise of a secondary server or, if the key(s) are kept off line,
-   even the primary server for a zone, will not necessarily affect the
-   degree of assurance that a resolver has that it can determine whether
-   data is genuine.
-
-   A resolver could learn a public key of a zone either by reading it
-   from the DNS or by having it staticly configured.  To reliably learn
-   a public key by reading it from the DNS, the key itself must be
-   signed with a key the resolver trusts. The resolver must be
-   configured with at least a public key which authenticates one zone as
-   a starting point. From there, it can securely read public keys of
-   other zones, if the intervening zones in the DNS tree are secure and
-   their signed keys accessible.
-
-   Adding data origin authentication and integrity requires no change to
-   the "on-the-wire" DNS protocol beyond the addition of the signature
-   resource type and the key resource type needed for key distribution.
-   (Data non-existence authentication also requires the NXT RR as
-   described in 2.3.2.)  This service can be supported by existing
-   resolver and caching server implementations so long as they can
-   support the additional resource types (see Section 9). The one
-   exception is that CNAME referrals in a secure zone can not be
-   authenticated if they are from non-security aware servers (see
-   Section 2.3.5).
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 6]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   If signatures are separately retrieved and verified when retrieving
-   the information they authenticate, there will be more trips to the
-   server and performance will suffer.  Security aware servers mitigate
-   that degradation by attempting to send the signature(s) needed (see
-   Section 4.2).
-
-2.3.1 The SIG Resource Record
-
-   The syntax of a SIG resource record (signature) is described in
-   Section 4.  It cryptographicly binds the RRset being signed to the
-   signer and a validity interval.
-
-   Every name in a secured zone will have associated with it at least
-   one SIG resource record for each resource type under that name except
-   for glue address RRs and delegation point NS RRs.  A security aware
-   server will attempt to return, with RRs retrieved, the corresponding
-   SIGs.  If a server is not security aware, the resolver must retrieve
-   all the SIG records for a name and select the one or ones that sign
-   the resource record set(s) that resolver is interested in.
-
-2.3.2 Authenticating Name and Type Non-existence
-
-   The above security mechanism only provides a way to sign existing
-   RRsets in a zone.  "Data origin" authentication is not obviously
-   provided for the non-existence of a domain name in a zone or the
-   non-existence of a type for an existing name.  This gap is filled by
-   the NXT RR which authenticatably asserts a range of non-existent
-   names in a zone and the non-existence of types for the existing name
-   just before that range.
-
-   Section 5 below covers the NXT RR.
-
-2.3.3 Special Considerations With Time-to-Live
-
-   A digital signature will fail to verify if any change has occurred to
-   the data between the time it was originally signed and the time the
-   signature is verified.  This conflicts with our desire to have the
-   time-to-live (TTL) field of resource records tick down while they are
-   cached.
-
-   This could be avoided by leaving the time-to-live out of the digital
-   signature, but that would allow unscrupulous servers to set
-   arbitrarily long TTL values undetected.  Instead, we include the
-   "original" TTL in the signature and communicate that data along with
-   the current TTL. Unscrupulous servers under this scheme can
-   manipulate the TTL but a security aware resolver will bound the TTL
-   value it uses at the original signed value.  Separately, signatures
-   include a signature inception time and a signature expiration time. A
-
-
-
-Eastlake                    Standards Track                     [Page 7]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   resolver that knows the absolute time can determine securely whether
-   a signature is in effect.  It is not possible to rely solely on the
-   signature expiration as a substitute for the TTL, however, since the
-   TTL is primarily a database consistency mechanism and non-security
-   aware servers that depend on TTL must still be supported.
-
-2.3.4 Special Considerations at Delegation Points
-
-   DNS security would like to view each zone as a unit of data
-   completely under the control of the zone owner with each entry
-   (RRset) signed by a special private key held by the zone manager.
-   But the DNS protocol views the leaf nodes in a zone, which are also
-   the apex nodes of a subzone (i.e., delegation points), as "really"
-   belonging to the subzone.  These nodes occur in two master files and
-   might have RRs signed by both the upper and lower zone's keys. A
-   retrieval could get a mixture of these RRs and SIGs, especially since
-   one server could be serving both the zone above and below a
-   delegation point. [RFC 2181]
-
-   There MUST be a zone KEY RR, signed by its superzone, for every
-   subzone if the superzone is secure. This will normally appear in the
-   subzone and may also be included in the superzone.  But, in the case
-   of an unsecured subzone which can not or will not be modified to add
-   any security RRs, a KEY declaring the subzone to be unsecured MUST
-   appear with the superzone signature in the superzone, if the
-   superzone is secure. For all but one other RR type the data from the
-   subzone is more authoritative so only the subzone KEY RR should be
-   signed in the superzone if it appears there. The NS and any glue
-   address RRs SHOULD only be signed in the subzone. The SOA and any
-   other RRs that have the zone name as owner should appear only in the
-   subzone and thus are signed only there. The NXT RR type is the
-   exceptional case that will always appear differently and
-   authoritatively in both the superzone and subzone, if both are
-   secure, as described in Section 5.
-
-2.3.5 Special Considerations with CNAME
-
-   There is a problem when security related RRs with the same owner name
-   as a CNAME RR are retrieved from a non-security-aware server. In
-   particular, an initial retrieval for the CNAME or any other type may
-   not retrieve any associated SIG, KEY, or NXT RR. For retrieved types
-   other than CNAME, it will retrieve that type at the target name of
-   the CNAME (or chain of CNAMEs) and will also return the CNAME.  In
-   particular, a specific retrieval for type SIG will not get the SIG,
-   if any, at the original CNAME domain name but rather a SIG at the
-   target name.
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 8]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   Security aware servers must be used to securely CNAME in DNS.
-   Security aware servers MUST (1) allow KEY, SIG, and NXT RRs along
-   with CNAME RRs, (2) suppress CNAME processing on retrieval of these
-   types as well as on retrieval of the type CNAME, and (3)
-   automatically return SIG RRs authenticating the CNAME or CNAMEs
-   encountered in resolving a query.  This is a change from the previous
-   DNS standard [RFCs 1034/1035] which prohibited any other RR type at a
-   node where a CNAME RR was present.
-
-2.3.6 Signers Other Than The Zone
-
-   There are cases where the signer in a SIG resource record is other
-   than one of the private key(s) used to authenticate a zone.
-
-   One is for support of dynamic update [RFC 2136] (or future requests
-   which require secure authentication) where an entity is permitted to
-   authenticate/update its records [RFC 2137] and the zone is operating
-   in a mode where the zone key is not on line. The public key of the
-   entity must be present in the DNS and be signed by a zone level key
-   but the other RR(s) may be signed with the entity's key.
-
-   A second case is support of transaction and request authentication as
-   described in Section 2.4.
-
-   In additions, signatures can be included on resource records within
-   the DNS for use by applications other than DNS. DNS related
-   signatures authenticate that data originated with the authority of a
-   zone owner or that a request or transaction originated with the
-   relevant entity. Other signatures can provide other types of
-   assurances.
-
-2.4 DNS Transaction and Request Authentication
-
-   The data origin authentication service described above protects
-   retrieved resource records and the non-existence of resource records
-   but provides no protection for DNS requests or for message headers.
-
-   If header bits are falsely set by a bad server, there is little that
-   can be done.  However, it is possible to add transaction
-   authentication.  Such authentication means that a resolver can be
-   sure it is at least getting messages from the server it thinks it
-   queried and that the response is from the query it sent (i.e., that
-   these messages have not been diddled in transit).  This is
-   accomplished by optionally adding a special SIG resource record at
-   the end of the reply which digitally signs the concatenation of the
-   server's response and the resolver's query.
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 9]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   Requests can also be authenticated by including a special SIG RR at
-   the end of the request.  Authenticating requests serves no function
-   in older DNS servers and requests with a non-empty additional
-   information section produce error returns or may even be ignored by
-   many of them. However, this syntax for signing requests is defined as
-   a way of authenticating secure dynamic update requests [RFC 2137] or
-   future requests requiring authentication.
-
-   The private keys used in transaction security belong to the entity
-   composing the reply, not to the zone involved.  Request
-   authentication may also involve the private key of the host or other
-   entity composing the request or other private keys depending on the
-   request authority it is sought to establish. The corresponding public
-   key(s) are normally stored in and retrieved from the DNS for
-   verification.
-
-   Because requests and replies are highly variable, message
-   authentication SIGs can not be pre-calculated.  Thus it will be
-   necessary to keep the private key on-line, for example in software or
-   in a directly connected piece of hardware.
-
-3. The KEY Resource Record
-
-   The KEY resource record (RR) is used to store a public key that is
-   associated with a Domain Name System (DNS) name.  This can be the
-   public key of a zone, a user, or a host or other end entity. Security
-   aware DNS implementations MUST be designed to handle at least two
-   simultaneously valid keys of the same type associated with the same
-   name.
-
-   The type number for the KEY RR is 25.
-
-   A KEY RR is, like any other RR, authenticated by a SIG RR.  KEY RRs
-   must be signed by a zone level key.
-
-3.1 KEY RDATA format
-
-   The RDATA for a KEY RR consists of flags, a protocol octet, the
-   algorithm number octet, and the public key itself.  The format is as
-   follows:
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 10]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-                        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                           /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
-   The KEY RR is not intended for storage of certificates and a separate
-   certificate RR has been developed for that purpose, defined in [RFC
-   2538].
-
-   The meaning of the KEY RR owner name, flags, and protocol octet are
-   described in Sections 3.1.1 through 3.1.5 below.  The flags and
-   algorithm must be examined before any data following the algorithm
-   octet as they control the existence and format of any following data.
-   The algorithm and public key fields are described in Section 3.2.
-   The format of the public key is algorithm dependent.
-
-   KEY RRs do not specify their validity period but their authenticating
-   SIG RR(s) do as described in Section 4 below.
-
-3.1.1 Object Types, DNS Names, and Keys
-
-   The public key in a KEY RR is for the object named in the owner name.
-
-   A DNS name may refer to three different categories of things.  For
-   example, foo.host.example could be (1) a zone, (2) a host or other
-   end entity , or (3) the mapping into a DNS name of the user or
-   account foo@host.example.  Thus, there are flag bits, as described
-   below, in the KEY RR to indicate with which of these roles the owner
-   name and public key are associated.  Note that an appropriate zone
-   KEY RR MUST occur at the apex node of a secure zone and zone KEY RRs
-   occur only at delegation points.
-
-3.1.2 The KEY RR Flag Field
-
-   In the "flags" field:
-
-     0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
-   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-   |  A/C  | Z | XT| Z | Z | NAMTYP| Z | Z | Z | Z |      SIG      |
-   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-   Bit 0 and 1 are the key "type" bits whose values have the following
-   meanings:
-
-
-
-Eastlake                    Standards Track                    [Page 11]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-           10: Use of the key is prohibited for authentication.
-           01: Use of the key is prohibited for confidentiality.
-           00: Use of the key for authentication and/or confidentiality
-               is permitted. Note that DNS security makes use of keys
-               for authentication only. Confidentiality use flagging is
-               provided for use of keys in other protocols.
-               Implementations not intended to support key distribution
-               for confidentiality MAY require that the confidentiality
-               use prohibited bit be on for keys they serve.
-           11: If both bits are one, the "no key" value, there is no key
-               information and the RR stops after the algorithm octet.
-               By the use of this "no key" value, a signed KEY RR can
-               authenticatably assert that, for example, a zone is not
-               secured.  See section 3.4 below.
-
-   Bits 2 is reserved and must be zero.
-
-   Bits 3 is reserved as a flag extension bit.  If it is a one, a second
-          16 bit flag field is added after the algorithm octet and
-          before the key data.  This bit MUST NOT be set unless one or
-          more such additional bits have been defined and are non-zero.
-
-   Bits 4-5 are reserved and must be zero.
-
-   Bits 6 and 7 form a field that encodes the name type. Field values
-   have the following meanings:
-
-           00: indicates that this is a key associated with a "user" or
-               "account" at an end entity, usually a host.  The coding
-               of the owner name is that used for the responsible
-               individual mailbox in the SOA and RP RRs: The owner name
-               is the user name as the name of a node under the entity
-               name.  For example, "j_random_user" on
-               host.subdomain.example could have a public key associated
-               through a KEY RR with name
-               j_random_user.host.subdomain.example.  It could be used
-               in a security protocol where authentication of a user was
-               desired.  This key might be useful in IP or other
-               security for a user level service such a telnet, ftp,
-               rlogin, etc.
-           01: indicates that this is a zone key for the zone whose name
-               is the KEY RR owner name.  This is the public key used
-               for the primary DNS security feature of data origin
-               authentication.  Zone KEY RRs occur only at delegation
-               points.
-           10: indicates that this is a key associated with the non-zone
-               "entity" whose name is the RR owner name.  This will
-               commonly be a host but could, in some parts of the DNS
-
-
-
-Eastlake                    Standards Track                    [Page 12]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-               tree, be some other type of entity such as a telephone
-               number [RFC 1530] or numeric IP address.  This is the
-               public key used in connection with DNS request and
-               transaction authentication services.  It could also be
-               used in an IP-security protocol where authentication at
-               the host, rather than user, level was desired, such as
-               routing, NTP, etc.
-           11: reserved.
-
-   Bits 8-11 are reserved and must be zero.
-
-   Bits 12-15 are the "signatory" field.  If non-zero, they indicate
-              that the key can validly sign things as specified in DNS
-              dynamic update [RFC 2137].  Note that zone keys (see bits
-              6 and 7 above) always have authority to sign any RRs in
-              the zone regardless of the value of the signatory field.
-
-3.1.3 The Protocol Octet
-
-   It is anticipated that keys stored in DNS will be used in conjunction
-   with a variety of Internet protocols.  It is intended that the
-   protocol octet and possibly some of the currently unused (must be
-   zero) bits in the KEY RR flags as specified in the future will be
-   used to indicate a key's validity for different protocols.
-
-   The following values of the Protocol Octet are reserved as indicated:
-
-        VALUE   Protocol
-
-          0      -reserved
-          1     TLS
-          2     email
-          3     dnssec
-          4     IPSEC
-         5-254   - available for assignment by IANA
-        255     All
-
-   In more detail:
-        1 is reserved for use in connection with TLS.
-        2 is reserved for use in connection with email.
-        3 is used for DNS security.  The protocol field SHOULD be set to
-          this value for zone keys and other keys used in DNS security.
-          Implementations that can determine that a key is a DNS
-          security key by the fact that flags label it a zone key or the
-          signatory flag field is non-zero are NOT REQUIRED to check the
-          protocol field.
-        4 is reserved to refer to the Oakley/IPSEC [RFC 2401] protocol
-          and indicates that this key is valid for use in conjunction
-
-
-
-Eastlake                    Standards Track                    [Page 13]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-          with that security standard.  This key could be used in
-          connection with secured communication on behalf of an end
-          entity or user whose name is the owner name of the KEY RR if
-          the entity or user flag bits are set.  The presence of a KEY
-          resource with this protocol value is an assertion that the
-          host speaks Oakley/IPSEC.
-        255 indicates that the key can be used in connection with any
-          protocol for which KEY RR protocol octet values have been
-          defined.  The use of this value is discouraged and the use of
-          different keys for different protocols is encouraged.
-
-3.2 The KEY Algorithm Number Specification
-
-   This octet is the key algorithm parallel to the same field for the
-   SIG resource as described in Section 4.1.  The following values are
-   assigned:
-
-   VALUE   Algorithm
-
-     0      - reserved, see Section 11
-     1     RSA/MD5 [RFC 2537] - recommended
-     2     Diffie-Hellman [RFC 2539] - optional, key only
-     3     DSA [RFC 2536] - MANDATORY
-     4     reserved for elliptic curve crypto
-   5-251    - available, see Section 11
-   252     reserved for indirect keys
-   253     private - domain name (see below)
-   254     private - OID (see below)
-   255      - reserved, see Section 11
-
-   Algorithm specific formats and procedures are given in separate
-   documents.  The mandatory to implement for interoperability algorithm
-   is number 3, DSA.  It is recommended that the RSA/MD5 algorithm,
-   number 1, also be implemented.  Algorithm 2 is used to indicate
-   Diffie-Hellman keys and algorithm 4 is reserved for elliptic curve.
-
-   Algorithm number 252 indicates an indirect key format where the
-   actual key material is elsewhere.  This format is to be defined in a
-   separate document.
-
-   Algorithm numbers 253 and 254 are reserved for private use and will
-   never be assigned a specific algorithm.  For number 253, the public
-   key area and the signature begin with a wire encoded domain name.
-   Only local domain name compression is permitted.  The domain name
-   indicates the private algorithm to use and the remainder of the
-   public key area is whatever is required by that algorithm.  For
-   number 254, the public key area for the KEY RR and the signature
-   begin with an unsigned length byte followed by a BER encoded Object
-
-
-
-Eastlake                    Standards Track                    [Page 14]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   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 domain names
-   and OIDs they control to designate their private algorithms.
-
-   Values 0 and 255 are reserved but the value 0 is used in the
-   algorithm field when that field is not used.  An example is in a KEY
-   RR with the top two flag bits on, the "no-key" value, where no key is
-   present.
-
-3.3 Interaction of Flags, Algorithm, and Protocol Bytes
-
-   Various combinations of the no-key type flags, algorithm byte,
-   protocol byte, and any future assigned protocol indicating flags are
-   possible.  The meaning of these combinations is indicated below:
-
-   NK = no key type (flags bits 0 and 1 on)
-   AL = algorithm byte
-   PR = protocols indicated by protocol byte or future assigned flags
-
-   x represents any valid non-zero value(s).
-
-    AL  PR   NK  Meaning
-     0   0   0   Illegal, claims key but has bad algorithm field.
-     0   0   1   Specifies total lack of security for owner zone.
-     0   x   0   Illegal, claims key but has bad algorithm field.
-     0   x   1   Specified protocols unsecured, others may be secure.
-     x   0   0   Gives key but no protocols to use it.
-     x   0   1   Denies key for specific algorithm.
-     x   x   0   Specifies key for protocols.
-     x   x   1   Algorithm not understood for protocol.
-
-3.4 Determination of Zone Secure/Unsecured Status
-
-   A zone KEY RR with the "no-key" type field value (both key type flag
-   bits 0 and 1 on) indicates that the zone named is unsecured while a
-   zone KEY RR with a key present indicates that the zone named is
-   secure.  The secured versus unsecured status of a zone may vary with
-   different cryptographic algorithms.  Even for the same algorithm,
-   conflicting zone KEY RRs may be present.
-
-   Zone KEY RRs, like all RRs, are only trusted if they are
-   authenticated by a SIG RR whose signer field is a signer for which
-   the resolver has a public key they trust and where resolver policy
-   permits that signer to sign for the KEY owner name.  Untrusted zone
-   KEY RRs MUST be ignored in determining the security status of the
-   zone.  However, there can be multiple sets of trusted zone KEY RRs
-   for a zone with different algorithms, signers, etc.
-
-
-
-Eastlake                    Standards Track                    [Page 15]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   For any particular algorithm, zones can be (1) secure, indicating
-   that any retrieved RR must be authenticated by a SIG RR or it will be
-   discarded as bogus, (2) unsecured, indicating that SIG RRs are not
-   expected or required for RRs retrieved from the zone, or (3)
-   experimentally secure, which indicates that SIG RRs might or might
-   not be present but must be checked if found.  The status of a zone is
-   determined as follows:
-
-   1. If, for a zone and algorithm, every trusted zone KEY RR for the
-      zone says there is no key for that zone, it is unsecured for that
-      algorithm.
-
-   2. If, there is at least one trusted no-key zone KEY RR and one
-      trusted key specifying zone KEY RR, then that zone is only
-      experimentally secure for the algorithm.  Both authenticated and
-      non-authenticated RRs for it should be accepted by the resolver.
-
-   3. If every trusted zone KEY RR that the zone and algorithm has is
-      key specifying, then it is secure for that algorithm and only
-      authenticated RRs from it will be accepted.
-
-   Examples:
-
-   (1)  A resolver initially trusts only signatures by the superzone of
-   zone Z within the DNS hierarchy.  Thus it will look only at the KEY
-   RRs that are signed by the superzone.  If it finds only no-key KEY
-   RRs, it will assume the zone is not secure.  If it finds only key
-   specifying KEY RRs, it will assume the zone is secure and reject any
-   unsigned responses.  If it finds both, it will assume the zone is
-   experimentally secure
-
-   (2)  A resolver trusts the superzone of zone Z (to which it got
-   securely from its local zone) and a third party, cert-auth.example.
-   When considering data from zone Z, it may be signed by the superzone
-   of Z, by cert-auth.example, by both, or by neither.  The following
-   table indicates whether zone Z will be considered secure,
-   experimentally secure, or unsecured, depending on the signed zone KEY
-   RRs for Z;
-
-                      c e r t - a u t h . e x a m p l e
-
-        KEY RRs|   None    |  NoKeys   |  Mixed   |   Keys   |
-     S       --+-----------+-----------+----------+----------+
-     u  None   | illegal   | unsecured | experim. | secure   |
-     p       --+-----------+-----------+----------+----------+
-     e  NoKeys | unsecured | unsecured | experim. | secure   |
-     r       --+-----------+-----------+----------+----------+
-     Z  Mixed  | experim.  | experim.  | experim. | secure   |
-
-
-
-Eastlake                    Standards Track                    [Page 16]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-     o       --+-----------+-----------+----------+----------+
-     n  Keys   | secure    | secure    | secure   | secure   |
-     e         +-----------+-----------+----------+----------+
-
-3.5 KEY RRs in the Construction of Responses
-
-   An explicit request for KEY RRs does not cause any special additional
-   information processing except, of course, for the corresponding SIG
-   RR from a security aware server (see Section 4.2).
-
-   Security aware DNS servers include KEY RRs as additional information
-   in responses, where a KEY is available, in the following cases:
-
-   (1) On the retrieval of SOA or NS RRs, the KEY RRset with the same
-   name (perhaps just a zone key) SHOULD be included as additional
-   information if space is available. If not all additional information
-   will fit, type A and AAAA glue RRs have higher priority than KEY
-   RR(s).
-
-   (2) On retrieval of type A or AAAA RRs, the KEY RRset with the same
-   name (usually just a host RR and NOT the zone key (which usually
-   would have a different name)) SHOULD be included if space is
-   available.  On inclusion of A or AAAA RRs as additional information,
-   the KEY RRset with the same name should also be included but with
-   lower priority than the A or AAAA RRs.
-
-4. The SIG Resource Record
-
-   The SIG or "signature" resource record (RR) is the fundamental way
-   that data is authenticated in the secure Domain Name System (DNS). As
-   such it is the heart of the security provided.
-
-   The SIG RR unforgably authenticates an RRset [RFC 2181] of a
-   particular type, class, and name and binds it to a time interval and
-   the signer's domain name.  This is done using cryptographic
-   techniques and the signer's private key.  The signer is frequently
-   the owner of the zone from which the RR originated.
-
-   The type number for the SIG RR type is 24.
-
-4.1 SIG RDATA Format
-
-   The RDATA portion of a SIG RR is as shown below.  The integrity of
-   the RDATA information is protected by the signature field.
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 17]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-                           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                          /
-      /                                                               /
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-4.1.1 Type Covered Field
-
-   The "type covered" is the type of the other RRs covered by this SIG.
-
-4.1.2 Algorithm Number Field
-
-   This octet is as described in section 3.2.
-
-4.1.3 Labels Field
-
-   The "labels" octet is an unsigned count of how many labels there are
-   in the original SIG RR owner name not counting the null label for
-   root and not counting any initial "*" for a wildcard.  If a secured
-   retrieval is the result of wild card substitution, it is necessary
-   for the resolver to use the original form of the name in verifying
-   the digital signature.  This field makes it easy to determine the
-   original form.
-
-   If, on retrieval, the RR appears to have a longer name than indicated
-   by "labels", the resolver can tell it is the result of wildcard
-   substitution.  If the RR owner name appears to be shorter than the
-   labels count, the SIG RR must be considered corrupt and ignored.  The
-   maximum number of labels allowed in the current DNS is 127 but the
-   entire octet is reserved and would be required should DNS names ever
-   be expanded to 255 labels.  The following table gives some examples.
-   The value of "labels" is at the top, the retrieved owner name on the
-   left, and the table entry is the name to use in signature
-   verification except that "bad" means the RR is corrupt.
-
-
-
-Eastlake                    Standards Track                    [Page 18]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   labels= |  0  |   1  |    2   |      3   |      4   |
-   --------+-----+------+--------+----------+----------+
-          .|   . | bad  |  bad   |    bad   |    bad   |
-         d.|  *. |   d. |  bad   |    bad   |    bad   |
-       c.d.|  *. | *.d. |   c.d. |    bad   |    bad   |
-     b.c.d.|  *. | *.d. | *.c.d. |   b.c.d. |    bad   |
-   a.b.c.d.|  *. | *.d. | *.c.d. | *.b.c.d. | a.b.c.d. |
-
-4.1.4 Original TTL Field
-
-   The "original TTL" field is included in the RDATA portion to avoid
-   (1) authentication problems that caching servers would otherwise
-   cause by decrementing the real TTL field and (2) security problems
-   that unscrupulous servers could otherwise cause by manipulating the
-   real TTL field.  This original TTL is protected by the signature
-   while the current TTL field is not.
-
-   NOTE:  The "original TTL" must be restored into the covered RRs when
-   the signature is verified (see Section 8).  This generaly implies
-   that all RRs for a particular type, name, and class, that is, all the
-   RRs in any particular RRset, must have the same TTL to start with.
-
-4.1.5 Signature Expiration and Inception Fields
-
-   The SIG is valid from the "signature inception" time until the
-   "signature expiration" time.  Both are unsigned numbers of seconds
-   since the start of 1 January 1970, GMT, ignoring leap seconds.  (See
-   also Section 4.4.)  Ring arithmetic is used as for DNS SOA serial
-   numbers [RFC 1982] which means that these times can never be more
-   than about 68 years in the past or the future.  This means that these
-   times are ambiguous modulo ~136.09 years.  However there is no
-   security flaw because keys are required to be changed to new random
-   keys by [RFC 2541] at least every five years.  This means that the
-   probability that the same key is in use N*136.09 years later should
-   be the same as the probability that a random guess will work.
-
-   A SIG RR may have an expiration time numerically less than the
-   inception time if the expiration time is near the 32 bit wrap around
-   point and/or the signature is long lived.
-
-   (To prevent misordering of network requests to update a zone
-   dynamically, monotonically increasing "signature inception" times may
-   be necessary.)
-
-   A secure zone must be considered changed for SOA serial number
-   purposes not only when its data is updated but also when new SIG RRs
-   are inserted (ie, the zone or any part of it is re-signed).
-
-
-
-
-Eastlake                    Standards Track                    [Page 19]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-4.1.6 Key Tag Field
-
-   The "key Tag" is a two octet quantity that is used to efficiently
-   select between multiple keys which may be applicable and thus check
-   that a public key about to be used for the computationally expensive
-   effort to check the signature is possibly valid.  For algorithm 1
-   (MD5/RSA) as defined in [RFC 2537], it is the next to the bottom two
-   octets of the public key modulus needed to decode the signature
-   field.  That is to say, the most significant 16 of the least
-   significant 24 bits of the modulus in network (big endian) order. For
-   all other algorithms, including private algorithms, it is calculated
-   as a simple checksum of the KEY RR as described in Appendix C.
-
-4.1.7 Signer's Name Field
-
-   The "signer's name" field is the domain name of the signer generating
-   the SIG RR.  This is the owner name of the public KEY RR that can be
-   used to verify the signature.  It is frequently the zone which
-   contained the RRset being authenticated.  Which signers should be
-   authorized to sign what is a significant resolver policy question as
-   discussed in Section 6. The signer's name may be compressed with
-   standard DNS name compression when being transmitted over the
-   network.
-
-4.1.8 Signature Field
-
-   The actual signature portion of the SIG RR binds the other RDATA
-   fields to the RRset of the "type covered" RRs with that owner name
-   and class.  This covered RRset is thereby authenticated.  To
-   accomplish this, a data sequence is constructed as follows:
-
-         data = RDATA | RR(s)...
-
-   where "|" is concatenation,
-
-   RDATA is the wire format of all the RDATA fields in the SIG RR itself
-   (including the canonical form of the signer's name) before but not
-   including the signature, and
-
-   RR(s) is the RRset of the RR(s) of the type covered with the same
-   owner name and class as the SIG RR in canonical form and order as
-   defined in Section 8.
-
-   How this data sequence is processed into the signature is algorithm
-   dependent.  These algorithm dependent formats and procedures are
-   described in separate documents (Section 3.2).
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 20]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   SIGs SHOULD NOT be included in a zone for any "meta-type" such as
-   ANY, AXFR, etc. (but see section 5.6.2 with regard to IXFR).
-
-4.1.8.1 Calculating Transaction and Request SIGs
-
-   A response message from a security aware server may optionally
-   contain a special SIG at the end of the additional information
-   section to authenticate the transaction.
-
-   This SIG has a "type covered" field of zero, which is not a valid RR
-   type.  It is calculated by using a "data" (see Section 4.1.8) of the
-   entire preceding DNS reply message, including DNS header but not the
-   IP header and before the reply RR counts have been adjusted for the
-   inclusion of any transaction SIG, concatenated with the entire DNS
-   query message that produced this response, including the query's DNS
-   header and any request SIGs but not its IP header.  That is
-
-      data = full response (less transaction SIG) | full query
-
-   Verification of the transaction SIG (which is signed by the server
-   host key, not the zone key) by the requesting resolver shows that the
-   query and response were not tampered with in transit, that the
-   response corresponds to the intended query, and that the response
-   comes from the queried server.
-
-   A DNS request may be optionally signed by including one or more SIGs
-   at the end of the query. Such SIGs are identified by having a "type
-   covered" field of zero. They sign the preceding DNS request message
-   including DNS header but not including the IP header or any request
-   SIGs at the end and before the request RR counts have been adjusted
-   for the inclusions of any request SIG(s).
-
-   WARNING: Request SIGs are unnecessary for any currently defined
-   request other than update [RFC 2136, 2137] and will cause some old
-   DNS servers to give an error return or ignore a query.  However, such
-   SIGs may in the future be needed for other requests.
-
-   Except where needed to authenticate an update or similar privileged
-   request, servers are not required to check request SIGs.
-
-4.2 SIG RRs in the Construction of Responses
-
-   Security aware DNS servers SHOULD, for every authenticated RRset the
-   query will return, attempt to send the available SIG RRs which
-   authenticate the requested RRset.  The following rules apply to the
-   inclusion of SIG RRs in responses:
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 21]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-     1. when an RRset is placed in a response, its SIG RR has a higher
-        priority for inclusion than additional RRs that may need to be
-        included.  If space does not permit its inclusion, the response
-        MUST be considered truncated except as provided in 2 below.
-
-     2. When a SIG RR is present in the zone for an additional
-        information section RR, the response MUST NOT be considered
-        truncated merely because space does not permit the inclusion of
-        the SIG RR with the additional information.
-
-     3. SIGs to authenticate glue records and NS RRs for subzones at a
-        delegation point are unnecessary and MUST NOT be sent.
-
-     4. If a SIG covers any RR that would be in the answer section of
-        the response, its automatic inclusion MUST be in the answer
-        section.  If it covers an RR that would appear in the authority
-        section, its automatic inclusion MUST be in the authority
-        section.  If it covers an RR that would appear in the additional
-        information section it MUST appear in the additional information
-        section.  This is a change in the existing standard [RFCs 1034,
-        1035] which contemplates only NS and SOA RRs in the authority
-        section.
-
-     5. Optionally, DNS transactions may be authenticated by a SIG RR at
-        the end of the response in the additional information section
-        (Section 4.1.8.1).  Such SIG RRs are signed by the DNS server
-        originating the response.  Although the signer field MUST be a
-        name of the originating server host, the owner name, class, TTL,
-        and original TTL, are meaningless.  The class and TTL fields
-        SHOULD be zero.  To conserve space, the owner name SHOULD be
-        root (a single zero octet).  If transaction authentication is
-        desired, that SIG RR must be considered the highest priority for
-        inclusion.
-
-4.3 Processing Responses and SIG RRs
-
-   The following rules apply to the processing of SIG RRs included in a
-   response:
-
-     1. A security aware resolver that receives a response from a
-        security aware server via a secure communication with the AD bit
-        (see Section 6.1) set, MAY choose to accept the RRs as received
-        without verifying the zone SIG RRs.
-
-     2. In other cases, a security aware resolver SHOULD verify the SIG
-        RRs for the RRs of interest.  This may involve initiating
-        additional queries for SIG or KEY RRs, especially in the case of
-
-
-
-
-Eastlake                    Standards Track                    [Page 22]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-        getting a response from a server that does not implement
-        security.  (As explained in 2.3.5 above, it will not be possible
-        to secure CNAMEs being served up by non-secure resolvers.)
-
-        NOTE: Implementers might expect the above SHOULD to be a MUST.
-        However, local policy or the calling application may not require
-        the security services.
-
-     3. If SIG RRs are received in response to a user query explicitly
-        specifying the SIG type, no special processing is required.
-
-   If the message does not pass integrity checks or the SIG does not
-   check against the signed RRs, the SIG RR is invalid and should be
-   ignored.  If all of the SIG RR(s) purporting to authenticate an RRset
-   are invalid, then the RRset is not authenticated.
-
-   If the SIG RR is the last RR in a response in the additional
-   information section and has a type covered of zero, it is a
-   transaction signature of the response and the query that produced the
-   response.  It MAY be optionally checked and the message rejected if
-   the checks fail.  But even if the checks succeed, such a transaction
-   authentication SIG does NOT directly authenticate any RRs in the
-   message.  Only a proper SIG RR signed by the zone or a key tracing
-   its authority to the zone or to static resolver configuration can
-   directly authenticate RRs, depending on resolver policy (see Section
-   6).  If a resolver does not implement transaction and/or request
-   SIGs, it MUST ignore them without error.
-
-   If all checks indicate that the SIG RR is valid then RRs verified by
-   it should be considered authenticated.
-
-4.4 Signature Lifetime, Expiration, TTLs, and Validity
-
-   Security aware servers MUST NOT consider SIG RRs to authenticate
-   anything before their signature inception or after its expiration
-   time (see also Section 6).  Security aware servers MUST NOT consider
-   any RR to be authenticated after all its signatures have expired.
-   When a secure server caches authenticated data, if the TTL would
-   expire at a time further in the future than the authentication
-   expiration time, the server SHOULD trim the TTL in the cache entry
-   not to extent beyond the authentication expiration time.  Within
-   these constraints, servers should continue to follow DNS TTL aging.
-   Thus authoritative servers should continue to follow the zone refresh
-   and expire parameters and a non-authoritative server should count
-   down the TTL and discard RRs when the TTL is zero (even for a SIG
-   that has not yet reached its authentication expiration time).  In
-   addition, when RRs are transmitted in a query response, the TTL
-
-
-
-
-Eastlake                    Standards Track                    [Page 23]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   should be trimmed so that current time plus the TTL does not extend
-   beyond the authentication expiration time.  Thus, in general, the TTL
-   on a transmitted RR would be
-
-      min(authExpTim,max(zoneMinTTL,min(originalTTL,currentTTL)))
-
-   When signatures are generated, signature expiration times should be
-   set far enough in the future that it is quite certain that new
-   signatures can be generated before the old ones expire.  However,
-   setting expiration too far into the future could mean a long time to
-   flush any bad data or signatures that may have been generated.
-
-   It is recommended that signature lifetime be a small multiple of the
-   TTL (ie, 4 to 16 times the TTL) but not less than a reasonable
-   maximum re-signing interval and not less than the zone expiry time.
-
-5. Non-existent Names and Types
-
-   The SIG RR mechanism described in Section 4 above provides strong
-   authentication of RRs that exist in a zone.  But it is not clear
-   above how to verifiably deny the existence of a name in a zone or a
-   type for an existent name.
-
-   The nonexistence of a name in a zone is indicated by the NXT ("next")
-   RR for a name interval containing the nonexistent name. An NXT RR or
-   RRs and its or their SIG(s) are returned in the authority section,
-   along with the error, if the server is security aware.  The same is
-   true for a non-existent type under an existing name except that there
-   is no error indication other than an empty answer section
-   accompanying the NXT(s). This is a change in the existing standard
-   [RFCs 1034/1035] which contemplates only NS and SOA RRs in the
-   authority section. NXT RRs will also be returned if an explicit query
-   is made for the NXT type.
-
-   The existence of a complete set of NXT records in a zone means that
-   any query for any name and any type to a security aware server
-   serving the zone will result in an reply containing at least one
-   signed RR unless it is a query for delegation point NS or glue A or
-   AAAA RRs.
-
-5.1 The NXT Resource Record
-
-   The NXT resource record is used to securely indicate that RRs with an
-   owner name in a certain name interval do not exist in a zone and to
-   indicate what RR types are present for an existing name.
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 24]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   The owner name of the NXT RR is an existing name in the zone.  It's
-   RDATA is a "next" name and a type bit map. Thus the NXT RRs in a zone
-   create a chain of all of the literal owner names in that zone,
-   including unexpanded wildcards but omitting the owner name of glue
-   address records unless they would otherwise be included. This implies
-   a canonical ordering of all domain names in a zone as described in
-   Section 8. The presence of the NXT RR means that no name between its
-   owner name and the name in its RDATA area exists and that no other
-   types exist under its owner name.
-
-   There is a potential problem with the last NXT in a zone as it wants
-   to have an owner name which is the last existing name in canonical
-   order, which is easy, but it is not obvious what name to put in its
-   RDATA to indicate the entire remainder of the name space.  This is
-   handled by treating the name space as circular and putting the zone
-   name in the RDATA of the last NXT in a zone.
-
-   The NXT RRs for a zone SHOULD be automatically calculated and added
-   to the zone when SIGs are added.  The NXT RR's TTL SHOULD NOT exceed
-   the zone minimum TTL.
-
-   The type number for the NXT RR is 30.
-
-   NXT RRs are only signed by zone level keys.
-
-5.2 NXT RDATA Format
-
-   The RDATA for an NXT RR consists simply of a domain name followed by
-   a bit map, 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 map                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   The NXT RR type bit map format currently defined is one bit per RR
-   type present for the owner name.  A one bit indicates that at least
-   one RR of that type is present for the owner name.  A zero indicates
-   that no such RR is present.  All bits not specified because they are
-   beyond the end of the bit map are assumed to be zero.  Note that bit
-   30, for NXT, will always be on so the minimum bit map length is
-   actually four octets. Trailing zero octets are prohibited in this
-   format.  The first bit represents RR type zero (an illegal type which
-   can not be present) and so will be zero in this format.  This format
-   is not used if there exists an RR with a type number greater than
-
-
-
-Eastlake                    Standards Track                    [Page 25]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   127.  If the zero bit of the type bit map is a one, it indicates that
-   a different format is being used which will always be the case if a
-   type number greater than 127 is present.
-
-   The domain name may be compressed with standard DNS name compression
-   when being transmitted over the network.  The size of the bit map can
-   be inferred from the RDLENGTH and the length of the next domain name.
-
-5.3 Additional Complexity Due to Wildcards
-
-   Proving that a non-existent name response is correct or that a
-   wildcard expansion response is correct makes things a little more
-   complex.
-
-   In particular, when a non-existent name response is returned, an NXT
-   must be returned showing that the exact name queried did not exist
-   and, in general, one or more additional NXT's need to be returned to
-   also prove that there wasn't a wildcard whose expansion should have
-   been returned. (There is no need to return multiple copies of the
-   same NXT.) These NXTs, if any, are returned in the authority section
-   of the response.
-
-   Furthermore, if a wildcard expansion is returned in a response, in
-   general one or more NXTs needs to also be returned in the authority
-   section to prove that no more specific name (including possibly more
-   specific wildcards in the zone) existed on which the response should
-   have been based.
-
-5.4 Example
-
-   Assume zone foo.nil has entries for
-
-          big.foo.nil,
-          medium.foo.nil.
-          small.foo.nil.
-          tiny.foo.nil.
-
-   Then a query to a security aware server for huge.foo.nil would
-   produce an error reply with an RCODE of NXDOMAIN and the authority
-   section data including something like the following:
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 26]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   foo.nil.    NXT big.foo.nil NS KEY SOA NXT ;prove no *.foo.nil
-   foo.nil.    SIG NXT 1 2 ( ;type-cov=NXT, alg=1, labels=2
-                    19970102030405 ;signature expiration
-                    19961211100908 ;signature inception
-                    2143           ;key identifier
-                    foo.nil.       ;signer
-   AIYADP8d3zYNyQwW2EM4wXVFdslEJcUx/fxkfBeH1El4ixPFhpfHFElxbvKoWmvjDTCm
-   fiYy2X+8XpFjwICHc398kzWsTMKlxovpz2FnCTM= ;signature (640 bits)
-                          )
-   big.foo.nil. NXT medium.foo.nil. A MX SIG NXT ;prove no huge.foo.nil
-   big.foo.nil. SIG NXT 1 3 ( ;type-cov=NXT, alg=1, labels=3
-                    19970102030405 ;signature expiration
-                    19961211100908 ;signature inception
-                    2143           ;key identifier
-                    foo.nil.       ;signer
-    MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoU
-    1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY= ;signature (640 bits)
-                             )
-   Note that this response implies that big.foo.nil is an existing name
-   in the zone and thus has other RR types associated with it than NXT.
-   However, only the NXT (and its SIG) RR appear in the response to this
-   query for huge.foo.nil, which is a non-existent name.
-
-5.5 Special Considerations at Delegation Points
-
-   A name (other than root) which is the head of a zone also appears as
-   the leaf in a superzone.  If both are secure, there will always be
-   two different NXT RRs with the same name.  They can be easily
-   distinguished by their signers, the next domain name fields, the
-   presence of the SOA type bit, etc.  Security aware servers should
-   return the correct NXT automatically when required to authenticate
-   the non-existence of a name and both NXTs, if available, on explicit
-   query for type NXT.
-
-   Non-security aware servers will never automatically return an NXT and
-   some old implementations may only return the NXT from the subzone on
-   explicit queries.
-
-5.6 Zone Transfers
-
-   The subsections below describe how full and incremental zone
-   transfers are secured.
-
-   SIG RRs secure all authoritative RRs transferred for both full and
-   incremental [RFC 1995] zone transfers.  NXT RRs are an essential
-   element in secure zone transfers and assure that every authoritative
-   name and type will be present; however, if there are multiple SIGs
-   with the same name and type covered, a subset of the SIGs could be
-
-
-
-Eastlake                    Standards Track                    [Page 27]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   sent as long as at least one is present and, in the case of unsigned
-   delegation point NS or glue A or AAAA RRs a subset of these RRs or
-   simply a modified set could be sent as long as at least one of each
-   type is included.
-
-   When an incremental or full zone transfer request is received with
-   the same or newer version number than that of the server's copy of
-   the zone, it is replied to with just the SOA RR of the server's
-   current version and the SIG RRset verifying that SOA RR.
-
-   The complete NXT chains specified in this document enable a resolver
-   to obtain, by successive queries chaining through NXTs, all of the
-   names in a zone even if zone transfers are prohibited.  Different
-   format NXTs may be specified in the future to avoid this.
-
-5.6.1 Full Zone Transfers
-
-   To provide server authentication that a complete transfer has
-   occurred, transaction authentication SHOULD be used on full zone
-   transfers.  This provides strong server based protection for the
-   entire zone in transit.
-
-5.6.2 Incremental Zone Transfers
-
-   Individual RRs in an incremental (IXFR) transfer [RFC 1995] can be
-   verified in the same way as for a full zone transfer and the
-   integrity of the NXT name chain and correctness of the NXT type bits
-   for the zone after the incremental RR deletes and adds can check each
-   disjoint area of the zone updated.  But the completeness of an
-   incremental transfer can not be confirmed because usually neither the
-   deleted RR section nor the added RR section has a compete zone NXT
-   chain.  As a result, a server which securely supports IXFR must
-   handle IXFR SIG RRs for each incremental transfer set that it
-   maintains.
-
-   The IXFR SIG is calculated over the incremental zone update
-   collection of RRs in the order in which it is transmitted: old SOA,
-   then deleted RRs, then new SOA and added RRs.  Within each section,
-   RRs must be ordered as specified in Section 8.  If condensation of
-   adjacent incremental update sets is done by the zone owner, the
-   original IXFR SIG for each set included in the condensation must be
-   discarded and a new on IXFR SIG calculated to cover the resulting
-   condensed set.
-
-   The IXFR SIG really belongs to the zone as a whole, not to the zone
-   name.  Although it SHOULD be correct for the zone name, the labels
-   field of an IXFR SIG is otherwise meaningless.  The IXFR SIG is only
-   sent as part of an incremental zone transfer.  After validation of
-
-
-
-Eastlake                    Standards Track                    [Page 28]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   the IXFR SIG, the transferred RRs MAY be considered valid without
-   verification of the internal SIGs if such trust in the server
-   conforms to local policy.
-
-6. How to Resolve Securely and the AD and CD Bits
-
-   Retrieving or resolving secure data from the Domain Name System (DNS)
-   involves starting with one or more trusted public keys that have been
-   staticly configured at the resolver.  With starting trusted keys, a
-   resolver willing to perform cryptography can progress securely
-   through the secure DNS structure to the zone of interest as described
-   in Section 6.3. Such trusted public keys would normally be configured
-   in a manner similar to that described in Section 6.2.  However, as a
-   practical matter, a security aware resolver would still gain some
-   confidence in the results it returns even if it was not configured
-   with any keys but trusted what it got from a local well known server
-   as if it were staticly configured.
-
-   Data stored at a security aware server needs to be internally
-   categorized as Authenticated, Pending, or Insecure. There is also a
-   fourth transient state of Bad which indicates that all SIG checks
-   have explicitly failed on the data. Such Bad data is not retained at
-   a security aware server. Authenticated means that the data has a
-   valid SIG under a KEY traceable via a chain of zero or more SIG and
-   KEY RRs allowed by the resolvers policies to a KEY staticly
-   configured at the resolver. Pending data has no authenticated SIGs
-   and at least one additional SIG the resolver is still trying to
-   authenticate.  Insecure data is data which it is known can never be
-   either Authenticated or found Bad in the zone where it was found
-   because it is in or has been reached via a unsecured zone or because
-   it is unsigned glue address or delegation point NS data. Behavior in
-   terms of control of and flagging based on such data labels is
-   described in Section 6.1.
-
-   The proper validation of signatures requires a reasonably secure
-   shared opinion of the absolute time between resolvers and servers as
-   described in Section 6.4.
-
-6.1 The AD and CD Header Bits
-
-   Two previously unused bits are allocated out of the DNS
-   query/response format header. The AD (authentic data) bit indicates
-   in a response that all the data included in the answer and authority
-   portion of the response has been authenticated by the server
-   according to the policies of that server. The CD (checking disabled)
-   bit indicates in a query that Pending (non-authenticated) data is
-   acceptable to the resolver sending the query.
-
-
-
-
-Eastlake                    Standards Track                    [Page 29]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   These bits are allocated from the previously must-be-zero Z field as
-   follows:
-
-                                           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  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |                    QDCOUNT                    |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |                    ANCOUNT                    |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |                    NSCOUNT                    |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |                    ARCOUNT                    |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   These bits are zero in old servers and resolvers.  Thus the responses
-   of old servers are not flagged as authenticated to security aware
-   resolvers and queries from non-security aware resolvers do not assert
-   the checking disabled bit and thus will be answered by security aware
-   servers only with Authenticated or Insecure data. Security aware
-   resolvers MUST NOT trust the AD bit unless they trust the server they
-   are talking to and either have a secure path to it or use DNS
-   transaction security.
-
-   Any security aware resolver willing to do cryptography SHOULD assert
-   the CD bit on all queries to permit it to impose its own policies and
-   to reduce DNS latency time by allowing security aware servers to
-   answer with Pending data.
-
-   Security aware servers MUST NOT return Bad data.  For non-security
-   aware resolvers or security aware resolvers requesting service by
-   having the CD bit clear, security aware servers MUST return only
-   Authenticated or Insecure data in the answer and authority sections
-   with the AD bit set in the response. Security aware servers SHOULD
-   return Pending data, with the AD bit clear in the response, to
-   security aware resolvers requesting this service by asserting the CD
-   bit in their request.  The AD bit MUST NOT be set on a response
-   unless all of the RRs in the answer and authority sections of the
-   response are either Authenticated or Insecure.  The AD bit does not
-   cover the additional information section.
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 30]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-6.2 Staticly Configured Keys
-
-   The public key to authenticate a zone SHOULD be defined in local
-   configuration files before that zone is loaded at the primary server
-   so the zone can be authenticated.
-
-   While it might seem logical for everyone to start with a public key
-   associated with the root zone and staticly configure this in every
-   resolver, this has problems.  The logistics of updating every DNS
-   resolver in the world should this key ever change would be severe.
-   Furthermore, many organizations will explicitly wish their "interior"
-   DNS implementations to completely trust only their own DNS servers.
-   Interior resolvers of such organizations can then go through the
-   organization's zone servers to access data outside the organization's
-   domain and need not be configured with keys above the organization's
-   DNS apex.
-
-   Host resolvers that are not part of a larger organization may be
-   configured with a key for the domain of their local ISP whose
-   recursive secure DNS caching server they use.
-
-6.3 Chaining Through The DNS
-
-   Starting with one or more trusted keys for any zone, it should be
-   possible to retrieve signed keys for that zone's subzones which have
-   a key. A secure sub-zone is indicated by a KEY RR with non-null key
-   information appearing with the NS RRs in the sub-zone and which may
-   also be present in the parent.  These make it possible to descend
-   within the tree of zones.
-
-6.3.1 Chaining Through KEYs
-
-   In general, some RRset that you wish to validate in the secure DNS
-   will be signed by one or more SIG RRs.  Each of these SIG RRs has a
-   signer under whose name is stored the public KEY to use in
-   authenticating the SIG.  Each of those KEYs will, generally, also be
-   signed with a SIG.  And those SIGs will have signer names also
-   referring to KEYs.  And so on. As a result, authentication leads to
-   chains of alternating SIG and KEY RRs with the first SIG signing the
-   original data whose authenticity is to be shown and the final KEY
-   being some trusted key staticly configured at the resolver performing
-   the authentication.
-
-   In testing such a chain, the validity periods of the SIGs encountered
-   must be intersected to determine the validity period of the
-   authentication of the data, a purely algorithmic process. In
-   addition, the validation of each SIG over the data with reference to
-   a KEY must meet the objective cryptographic test implied by the
-
-
-
-Eastlake                    Standards Track                    [Page 31]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   cryptographic algorithm used (although even here the resolver may
-   have policies as to trusted algorithms and key lengths).  Finally,
-   the judgement that a SIG with a particular signer name can
-   authenticate data (possibly a KEY RRset) with a particular owner
-   name, is primarily a policy question.  Ultimately, this is a policy
-   local to the resolver and any clients that depend on that resolver's
-   decisions.  It is, however, recommended, that the policy below be
-   adopted:
-
-        Let A < B mean that A is a shorter domain name than B formed by
-        dropping one or more whole labels from the left end of B, i.e.,
-        A is a direct or indirect superdomain of B.  Let A = B mean that
-        A and B are the same domain name (i.e., are identical after
-        letter case canonicalization).  Let A > B mean that A is a
-        longer domain name than B formed by adding one or more whole
-        labels on the left end of B, i.e., A is a direct or indirect
-        subdomain of B
-
-        Let Static be the owner names of the set of staticly configured
-        trusted keys at a resolver.
-
-        Then Signer is a valid signer name for a SIG authenticating an
-        RRset (possibly a KEY RRset) with owner name Owner at the
-        resolver if any of the following three rules apply:
-
-        (1) Owner > or = Signer (except that if Signer is root, Owner
-        must be root or a top level domain name).  That is, Owner is the
-        same as or a subdomain of Signer.
-
-        (2) ( Owner < Signer ) and ( Signer > or = some Static ).  That
-        is, Owner is a superdomain of Signer and Signer is staticly
-        configured or a subdomain of a staticly configured key.
-
-        (3) Signer = some Static.  That is, the signer is exactly some
-        staticly configured key.
-
-   Rule 1 is the rule for descending the DNS tree and includes a special
-   prohibition on the root zone key due to the restriction that the root
-   zone be only one label deep.  This is the most fundamental rule.
-
-   Rule 2 is the rule for ascending the DNS tree from one or more
-   staticly configured keys.  Rule 2 has no effect if only root zone
-   keys are staticly configured.
-
-   Rule 3 is a rule permitting direct cross certification.  Rule 3 has
-   no effect if only root zone keys are staticly configured.
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 32]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   Great care should be taken that the consequences have been fully
-   considered before making any local policy adjustments to these rules
-   (other than dispensing with rules 2 and 3 if only root zone keys are
-   staticly configured).
-
-6.3.2 Conflicting Data
-
-   It is possible that there will be multiple SIG-KEY chains that appear
-   to authenticate conflicting RRset answers to the same query.  A
-   resolver should choose only the most reliable answer to return and
-   discard other data.  This choice of most reliable is a matter of
-   local policy which could take into account differing trust in
-   algorithms, key sizes, staticly configured keys, zones traversed,
-   etc.  The technique given below is recommended for taking into
-   account SIG-KEY chain length.
-
-   A resolver should keep track of the number of successive secure zones
-   traversed from a staticly configured key starting point to any secure
-   zone it can reach.  In general, the lower such a distance number is,
-   the greater the confidence in the data.  Staticly configured data
-   should be given a distance number of zero.  If a query encounters
-   different Authenticated data for the same query with different
-   distance values, that with a larger value should be ignored unless
-   some other local policy covers the case.
-
-   A security conscious resolver should completely refuse to step from a
-   secure zone into a unsecured zone unless the unsecured zone is
-   certified to be non-secure by the presence of an authenticated KEY RR
-   for the unsecured zone with the no-key type value.  Otherwise the
-   resolver is getting bogus or spoofed data.
-
-   If legitimate unsecured zones are encountered in traversing the DNS
-   tree, then no zone can be trusted as secure that can be reached only
-   via information from such non-secure zones. Since the unsecured zone
-   data could have been spoofed, the "secure" zone reached via it could
-   be counterfeit.  The "distance" to data in such zones or zones
-   reached via such zones could be set to 256 or more as this exceeds
-   the largest possible distance through secure zones in the DNS.
-
-6.4 Secure Time
-
-   Coordinated interpretation of the time fields in SIG RRs requires
-   that reasonably consistent time be available to the hosts
-   implementing the DNS security extensions.
-
-   A variety of time synchronization protocols exist including the
-   Network Time Protocol (NTP [RFC 1305, 2030]).  If such protocols are
-   used, they MUST be used securely so that time can not be spoofed.
-
-
-
-Eastlake                    Standards Track                    [Page 33]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   Otherwise, for example, a host could get its clock turned back and
-   might then believe old SIG RRs, and the data they authenticate, which
-   were valid but are no longer.
-
-7. ASCII Representation of Security RRs
-
-   This section discusses the format for master file and other ASCII
-   presentation of the three DNS security resource records.
-
-   The algorithm field in KEY and SIG RRs can be represented as either
-   an unsigned integer or symbolicly.  The following initial symbols are
-   defined as indicated:
-
-        Value  Symbol
-
-        001    RSAMD5
-        002    DH
-        003    DSA
-        004    ECC
-        252    INDIRECT
-        253    PRIVATEDNS
-        254    PRIVATEOID
-
-7.1 Presentation of KEY RRs
-
-   KEY RRs may appear as single logical lines in a zone data master file
-   [RFC 1033].
-
-   The flag field is represented as an unsigned integer or a sequence of
-   mnemonics as follows separated by instances of the verticle bar ("|")
-   character:
-
-     BIT  Mnemonic  Explanation
-    0-1           key type
-        NOCONF    =1 confidentiality use prohibited
-        NOAUTH    =2 authentication use prohibited
-        NOKEY     =3 no key present
-    2   FLAG2     - reserved
-    3   EXTEND    flags extension
-    4   FLAG4     - reserved
-    5   FLAG5     - reserved
-    6-7           name type
-        USER      =0 (default, may be omitted)
-        ZONE      =1
-        HOST      =2 (host or other end entity)
-        NTYP3     - reserved
-    8   FLAG8     - reserved
-    9   FLAG9     - reserved
-
-
-
-Eastlake                    Standards Track                    [Page 34]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   10   FLAG10    - reserved
-   11   FLAG11    - reserved
-   12-15          signatory field, values 0 to 15
-            can be represented by SIG0, SIG1, ... SIG15
-
-   No flag mnemonic need be present if the bit or field it represents is
-   zero.
-
-   The protocol octet can be represented as either an unsigned integer
-   or symbolicly.  The following initial symbols are defined:
-
-        000    NONE
-        001    TLS
-        002    EMAIL
-        003    DNSSEC
-        004    IPSEC
-        255    ALL
-
-   Note that if the type flags field has the NOKEY value, nothing
-   appears after the algorithm octet.
-
-   The remaining public key portion is represented in base 64 (see
-   Appendix A) and may be divided up into any number of white space
-   separated substrings, down to single base 64 digits, which are
-   concatenated to obtain the full signature.  These substrings can span
-   lines using the standard parenthesis.
-
-   Note that the public key may have internal sub-fields but these do
-   not appear in the master file representation.  For example, with
-   algorithm 1 there is a public exponent size, then a public exponent,
-   and then a modulus.  With algorithm 254, there will be an OID size,
-   an OID, and algorithm dependent information. But in both cases only a
-   single logical base 64 string will appear in the master file.
-
-7.2 Presentation of SIG RRs
-
-   A data SIG RR may be represented as a single logical line in a zone
-   data file [RFC 1033] but there are some special considerations as
-   described below.  (It does not make sense to include a transaction or
-   request authenticating SIG RR in a file as they are a transient
-   authentication that covers data including an ephemeral transaction
-   number and so must be calculated in real time.)
-
-   There is no particular problem with the signer, covered type, and
-   times.  The time fields appears in the form YYYYMMDDHHMMSS where YYYY
-   is the year, the first 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),
-   the second MM is the minute (00-59), and SS is the second (00-59).
-
-
-
-Eastlake                    Standards Track                    [Page 35]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   The original TTL field appears as an unsigned integer.
-
-   If the original TTL, which applies to the type signed, is the same as
-   the TTL of the SIG RR itself, it may be omitted.  The date field
-   which follows it is larger than the maximum possible TTL so there is
-   no ambiguity.
-
-   The "labels" field appears as an unsigned integer.
-
-   The key tag appears as an unsigned number.
-
-   However, the signature itself can be very long.  It is the last data
-   field and is represented in base 64 (see Appendix A) and may be
-   divided up into any number of white space separated substrings, down
-   to single base 64 digits, which are concatenated to obtain the full
-   signature.  These substrings can be split between lines using the
-   standard parenthesis.
-
-7.3 Presentation of NXT RRs
-
-   NXT RRs do not appear in original unsigned zone master files since
-   they should be derived from the zone as it is being signed.  If a
-   signed file with NXTs added is printed or NXTs are printed by
-   debugging code, they appear as the next domain name followed by the
-   RR type present bits as an unsigned interger or sequence of RR
-   mnemonics.
-
-8. Canonical Form and Order of Resource Records
-
-   This section specifies, for purposes of domain name system (DNS)
-   security, the canonical form of resource records (RRs), their name
-   order, and their overall order.  A canonical name order is necessary
-   to construct the NXT name chain.  A canonical form and ordering
-   within an RRset is necessary in consistently constructing and
-   verifying SIG RRs.  A canonical ordering of types within a name is
-   required in connection with incremental transfer (Section 5.6.2).
-
-8.1 Canonical RR Form
-
-   For purposes of DNS security, the canonical form for an RR is the
-   wire format of the RR with domain names (1) fully expanded (no name
-   compression via pointers), (2) all domain name letters set to lower
-   case, (3) owner name wild cards in master file form (no substitution
-   made for *), and (4) the original TTL substituted for the current
-   TTL.
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 36]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-8.2 Canonical DNS Name Order
-
-   For purposes of DNS security, the canonical ordering of owner names
-   is to sort individual labels as unsigned left justified octet strings
-   where the absence of a octet sorts before a zero value octet and
-   upper case letters are treated as lower case letters.  Names in a
-   zone are sorted by sorting on the highest level label and then,
-   within those names with the same highest level label by the next
-   lower label, etc. down to leaf node labels.  Within a zone, the zone
-   name itself always exists and all other names are the zone name with
-   some prefix of lower level labels.  Thus the zone name itself always
-   sorts first.
-
-   Example:
-          foo.example
-          a.foo.example
-          yljkjljk.a.foo.example
-          Z.a.foo.example
-          zABC.a.FOO.EXAMPLE
-          z.foo.example
-          *.z.foo.example
-          \200.z.foo.example
-
-8.3 Canonical RR Ordering Within An RRset
-
-   Within any particular owner name and type, RRs are sorted by RDATA as
-   a left justified unsigned octet sequence where the absence of an
-   octet sorts before the zero octet.
-
-8.4 Canonical Ordering of RR Types
-
-   When RRs of the same name but different types must be ordered, they
-   are ordered by type, considering the type to be an unsigned integer,
-   except that SIG RRs are placed immediately after the type they cover.
-   Thus, for example, an A record would be put before an MX record
-   because A is type 1 and MX is type 15 but if both were signed, the
-   order would be A < SIG(A) < MX < SIG(MX).
-
-9. Conformance
-
-   Levels of server and resolver conformance are defined below.
-
-9.1 Server Conformance
-
-   Two levels of server conformance for DNS security are defined as
-   follows:
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 37]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   BASIC:  Basic server compliance is the ability to store and retrieve
-   (including zone transfer) SIG, KEY, and NXT RRs.  Any secondary or
-   caching server for a secure zone MUST have at least basic compliance
-   and even then some things, such as secure CNAMEs, will not work
-   without full compliance.
-
-   FULL:  Full server compliance adds the following to basic compliance:
-   (1) ability to read SIG, KEY, and NXT RRs in zone files and (2)
-   ability, given a zone file and private key, to add appropriate SIG
-   and NXT RRs, possibly via a separate application, (3) proper
-   automatic inclusion of SIG, KEY, and NXT RRs in responses, (4)
-   suppression of CNAME following on retrieval of the security type RRs,
-   (5) recognize the CD query header bit and set the AD query header
-   bit, as appropriate, and (6) proper handling of the two NXT RRs at
-   delegation points.  Primary servers for secure zones MUST be fully
-   compliant and for complete secure operation, all secondary, caching,
-   and other servers handling the zone SHOULD be fully compliant as
-   well.
-
-9.2 Resolver Conformance
-
-   Two levels of resolver compliance (including the resolver portion of
-   a server) are defined for DNS Security:
-
-   BASIC: A basic compliance resolver can handle SIG, KEY, and NXT RRs
-   when they are explicitly requested.
-
-   FULL: A fully compliant resolver (1) understands KEY, SIG, and NXT
-   RRs including verification of SIGs at least for the mandatory
-   algorithm, (2) maintains appropriate information in its local caches
-   and database to indicate which RRs have been authenticated and to
-   what extent they have been authenticated, (3) performs additional
-   queries as necessary to attempt to obtain KEY, SIG, or NXT RRs when
-   needed, (4) normally sets the CD query header bit on its queries.
-
-10. Security Considerations
-
-   This document specifies extensions to the Domain Name System (DNS)
-   protocol to provide data integrity and data origin authentication,
-   public key distribution, and optional transaction and request
-   security.
-
-   It should be noted that, at most, these extensions guarantee the
-   validity of resource records, including KEY resource records,
-   retrieved from the DNS.  They do not magically solve other security
-   problems.  For example, using secure DNS you can have high confidence
-   in the IP address you retrieve for a host name; however, this does
-   not stop someone for substituting an unauthorized host at that
-
-
-
-Eastlake                    Standards Track                    [Page 38]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   address or capturing packets sent to that address and falsely
-   responding with packets apparently from that address.  Any reasonably
-   complete security system will require the protection of many
-   additional facets of the Internet beyond DNS.
-
-   The implementation of NXT RRs as described herein enables a resolver
-   to determine all the names in a zone even if zone transfers are
-   prohibited (section 5.6).  This is an active area of work and may
-   change.
-
-   A number of precautions in DNS implementation have evolved over the
-   years to harden the insecure DNS against spoofing.  These precautions
-   should not be abandoned but should be considered to provide
-   additional protection in case of key compromise in secure DNS.
-
-11. IANA Considerations
-
-   KEY RR flag bits 2 and 8-11 and all flag extension field bits can be
-   assigned by IETF consensus as defined in RFC 2434.  The remaining
-   values of the NAMTYP flag field and flag bits 4 and 5 (which could
-   conceivably become an extension of the NAMTYP field) can only be
-   assigned by an IETF Standards Action [RFC 2434].
-
-   Algorithm numbers 5 through 251 are available for assignment should
-   sufficient reason arise.  However, the designation of a new algorithm
-   could have a major impact on interoperability and requires an IETF
-   Standards Action [RFC 2434].  The existence of the private algorithm
-   types 253 and 254 should satify most needs for private or proprietary
-   algorithms.
-
-   Additional values of the Protocol Octet (5-254) can be assigned by
-   IETF Consensus [RFC 2434].
-
-   The meaning of the first bit of the NXT RR "type bit map" being a one
-   can only be assigned by a standards action.
-
-References
-
-   [RFC 1033]  Lottor, M., "Domain Administrators Operations Guide", RFC
-               1033, November 1987.
-
-   [RFC 1034]  Mockapetris, P., "Domain Names - Concepts and
-               Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC 1035]  Mockapetris, P., "Domain Names - Implementation and
-               Specifications", STD 13, RFC 1035, November 1987.
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 39]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   [RFC 1305]  Mills, D., "Network Time Protocol (v3)", RFC 1305, March
-               1992.
-
-   [RFC 1530]  Malamud, C. and M. Rose, "Principles of Operation for the
-               TPC.INT Subdomain: General Principles and Policy", RFC
-               1530, October 1993.
-
-   [RFC 2401]  Kent, S. and R. Atkinson, "Security Architecture for the
-               Internet Protocol", RFC 2401, November 1998.
-
-   [RFC 1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC
-               1982, September 1996.
-
-   [RFC 1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
-               August 1996.
-
-   [RFC 2030]  Mills, D., "Simple Network Time Protocol (SNTP) Version 4
-               for IPv4, IPv6 and OSI", RFC 2030, October 1996.
-
-   [RFC 2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
-               Extensions (MIME) Part One: Format of Internet Message
-               Bodies", RFC 2045, November 1996.
-
-   [RFC 2065]  Eastlake, D. and C. Kaufman, "Domain Name System Security
-               Extensions", RFC 2065, January 1997.
-
-   [RFC 2119]  Bradner, S., "Key words for use in RFCs to Indicate
-               Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC 2136]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
-               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
-               RFC 2136, April 1997.
-
-   [RFC 2137]  Eastlake, D., "Secure Domain Name System Dynamic Update",
-               RFC 2137, April 1997.
-
-   [RFC 2181]  Elz, R. and R. Bush, "Clarifications to the DNS
-               Specification", RFC 2181, July 1997.
-
-   [RFC 2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
-               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
-               October 1998.
-
-   [RFC 2537]  Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
-               System (DNS)", RFC 2537, March 1999.
-
-   [RFC 2539]  Eastlake, D., "Storage of Diffie-Hellman Keys in the
-               Domain Name System (DNS)", RFC 2539, March 1999.
-
-
-
-Eastlake                    Standards Track                    [Page 40]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   [RFC 2536]  Eastlake, D., "DSA KEYs and SIGs in the Domain Name
-               System (DNS)", RFC 2536, March 1999.
-
-   [RFC 2538]  Eastlake, D. and O. Gudmundsson, "Storing Certificates in
-               the Domain Name System", RFC 2538, March 1999.
-
-   [RFC 2541]  Eastlake, D., "DNS Operational Security Considerations",
-               RFC 2541, March 1999.
-
-   [RSA FAQ] - RSADSI Frequently Asked Questions periodic posting.
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   IBM
-   65 Shindegan Hill Road
-   RR #1
-   Carmel, NY 10512
-
-   Phone:   +1-914-784-7913 (w)
-            +1-914-276-2668 (h)
-   Fax:     +1-914-784-3833 (w-fax)
-   EMail:   dee3@us.ibm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 41]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-Appendix A: Base 64 Encoding
-
-   The following encoding technique is taken from [RFC 2045] by N.
-   Borenstein and N. Freed.  It is reproduced here in an edited form for
-   convenience.
-
-   A 65-character subset of US-ASCII is used, enabling 6 bits to be
-   represented per printable character. (The extra 65th character, "=",
-   is used to signify a special processing function.)
-
-   The encoding process represents 24-bit groups of input bits as output
-   strings of 4 encoded characters. Proceeding from left to right, a
-   24-bit input group is formed by concatenating 3 8-bit input groups.
-   These 24 bits are then treated as 4 concatenated 6-bit groups, each
-   of which is translated into a single digit in the base 64 alphabet.
-
-   Each 6-bit group is used as an index into an array of 64 printable
-   characters. The character referenced by the index is placed in the
-   output string.
-
-                         Table 1: The Base 64 Alphabet
-
-      Value Encoding  Value Encoding  Value Encoding  Value Encoding
-          0 A            17 R            34 i            51 z
-          1 B            18 S            35 j            52 0
-          2 C            19 T            36 k            53 1
-          3 D            20 U            37 l            54 2
-          4 E            21 V            38 m            55 3
-          5 F            22 W            39 n            56 4
-          6 G            23 X            40 o            57 5
-          7 H            24 Y            41 p            58 6
-          8 I            25 Z            42 q            59 7
-          9 J            26 a            43 r            60 8
-         10 K            27 b            44 s            61 9
-         11 L            28 c            45 t            62 +
-         12 M            29 d            46 u            63 /
-         13 N            30 e            47 v
-         14 O            31 f            48 w         (pad) =
-         15 P            32 g            49 x
-         16 Q            33 h            50 y
-
-   Special processing is performed if fewer than 24 bits are available
-   at the end of the data being encoded.  A full encoding quantum is
-   always completed at the end of a quantity.  When fewer than 24 input
-   bits are available in an input group, zero bits are added (on the
-   right) to form an integral number of 6-bit groups.  Padding at the
-   end of the data is performed using the '=' character.  Since all base
-   64 input is an integral number of octets, only the following cases
-
-
-
-Eastlake                    Standards Track                    [Page 42]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   can arise: (1) the final quantum of encoding input is an integral
-   multiple of 24 bits; here, the final unit of encoded output will be
-   an integral multiple of 4 characters with no "=" padding, (2) the
-   final quantum of encoding input is exactly 8 bits; here, the final
-   unit of encoded output will be two characters followed by two "="
-   padding characters, or (3) the final quantum of encoding input is
-   exactly 16 bits; here, the final unit of encoded output will be three
-   characters followed by one "=" padding character.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 43]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-Appendix B: Changes from RFC 2065
-
-   This section summarizes the most important changes that have been
-   made since RFC 2065.
-
-   1. Most of Section 7 of [RFC 2065] called "Operational
-      Considerations", has been removed and may be made into a separate
-      document [RFC 2541].
-
-   2. The KEY RR has been changed by (2a) eliminating the "experimental"
-      flag as unnecessary, (2b) reserving a flag  bit for flags
-      expansion, (2c) more compactly encoding a number of bit fields in
-      such a way as to leave unchanged bits actually used by the limited
-      code currently deployed, (2d) eliminating the IPSEC and email flag
-      bits which are replaced by values of the protocol field and adding
-      a protocol field value for DNS security itself, (2e) adding
-      material to indicate that zone KEY RRs occur only at delegation
-      points, and (2f) removing the description of the RSA/MD5 algorithm
-      to a separate document [RFC 2537].  Section 3.4 describing the
-      meaning of various combinations of "no-key" and key present KEY
-      RRs has been added and the secure / unsecure status of a zone has
-      been clarified as being per algorithm.
-
-   3. The SIG RR has been changed by (3a) renaming the "time signed"
-      field to be the "signature inception" field, (3b) clarifying that
-      signature expiration and inception use serial number ring
-      arithmetic, (3c) changing the definition of the key footprint/tag
-      for algorithms other than 1 and adding Appendix C to specify its
-      calculation.  In addition, the SIG covering type AXFR has been
-      eliminated while one covering IXFR [RFC 1995] has been added (see
-      section 5.6).
-
-   4. Algorithm 3, the DSA algorithm, is now designated as the mandatory
-      to implement algorithm.  Algorithm 1, the RSA/MD5 algorithm, is
-      now a recommended option.  Algorithm 2 and 4 are designated as the
-      Diffie-Hellman key and elliptic cryptography algorithms
-      respectively, all to be defined in separate documents. Algorithm
-      code point 252 is designated to indicate "indirect" keys, to be
-      defined in a separate document, where the actual key is elsewhere.
-      Both the KEY and SIG RR definitions have been simplified by
-      eliminating the "null" algorithm 253 as defined in [RFC 2065].
-      That algorithm had been included because at the time it was
-      thought it might be useful in DNS dynamic update [RFC 2136]. It
-      was in fact not so used and it is dropped to simplify DNS
-      security.  Howver, that algorithm number has been re-used to
-      indicate private algorithms where a domain name specifies the
-      algorithm.
-
-
-
-
-Eastlake                    Standards Track                    [Page 44]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-   5. The NXT RR has been changed so that (5a) the NXT RRs in a zone
-      cover all names, including wildcards as literal names without
-      expansion, except for glue address records whose names would not
-      otherwise appear, (5b) all NXT bit map areas whose first octet has
-      bit zero set have been reserved for future definition, (5c) the
-      number of and circumstances under which an NXT must be returned in
-      connection with wildcard names has been extended, and (5d) in
-      connection with the bit map, references to the WKS RR have been
-      removed and verticle bars ("|") have been added between the RR
-      type mnemonics in the ASCII representation.
-
-   6. Information on the canonical form and ordering of RRs has been
-      moved into a separate Section 8.
-
-   7. A subsection covering incremental and full zone transfer has been
-      added in Section 5.
-
-   8. Concerning DNS chaining: Further specification and policy
-      recommendations on secure resolution have been added, primarily in
-      Section 6.3.1.  It is now clearly stated that authenticated data
-      has a validity period of the intersection of the validity periods
-      of the SIG RRs in its authentication chain.  The requirement to
-      staticly configure a superzone's key signed by a zone in all of
-      the zone's authoritative servers has been removed.  The
-      recommendation to continue DNS security checks in a secure island
-      of DNS data that is separated from other parts of the DNS tree by
-      insecure zones and does not contain a zone for which a key has
-      been staticly configured was dropped.
-
-   9. It was clarified that the presence of the AD bit in a response
-      does not apply to the additional information section or to glue
-      address or delegation point NS RRs.  The AD bit only indicates
-      that the answer and authority sections of the response are
-      authoritative.
-
-   10. It is now required that KEY RRs and NXT RRs be signed only with
-       zone-level keys.
-
-   11.  Add IANA Considerations section and references to RFC 2434.
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 45]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-Appendix C: Key Tag Calculation
-
-   The key tag field in the SIG RR is just a means of more efficiently
-   selecting the correct KEY RR to use when there is more than one KEY
-   RR candidate available, for example, in verifying a signature.  It is
-   possible for more than one candidate key to have the same tag, in
-   which case each must be tried until one works or all fail.  The
-   following reference implementation of how to calculate the Key Tag,
-   for all algorithms other than algorithm 1, is in ANSI C.  It is coded
-   for clarity, not efficiency.  (See section 4.1.6 for how to determine
-   the Key Tag of an algorithm 1 key.)
-
-   /* assumes int is at least 16 bits
-      first byte of the key tag is the most significant byte of return
-      value
-      second byte of the key tag is the least significant byte of
-      return value
-      */
-
-   int keytag (
-
-           unsigned char key[],  /* the RDATA part of the KEY RR */
-           unsigned int keysize, /* the RDLENGTH */
-           )
-   {
-   long int    ac;    /* assumed to be 32 bits or larger */
-
-   for ( ac = 0, i = 0; i < keysize; ++i )
-       ac += (i&1) ? key[i] : key[i]<<8;
-   ac += (ac>>16) & 0xFFFF;
-   return ac & 0xFFFF;
-   }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 46]
-
-RFC 2535                DNS Security Extensions               March 1999
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 47]
-
diff --git a/contrib/bind9/doc/rfc/rfc2536.txt b/contrib/bind9/doc/rfc/rfc2536.txt
deleted file mode 100644
index 88be242..0000000
--- a/contrib/bind9/doc/rfc/rfc2536.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        D. EastLake
-Request for Comments: 2536                                           IBM
-Category: Standards Track                                     March 1999
-
-
-           DSA KEYs and SIGs in the Domain Name System (DNS)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   A standard method for storing US Government Digital Signature
-   Algorithm keys and signatures in the Domain Name System is described
-   which utilizes DNS KEY and SIG resource records.
-
-Table of Contents
-
-   Abstract...................................................1
-   1. Introduction............................................1
-   2. DSA KEY Resource Records................................2
-   3. DSA SIG Resource Records................................3
-   4. Performance Considerations..............................3
-   5. Security Considerations.................................4
-   6. IANA Considerations.....................................4
-   References.................................................5
-   Author's Address...........................................5
-   Full Copyright Statement...................................6
-
-1. Introduction
-
-   The Domain Name System (DNS) is the global hierarchical replicated
-   distributed database system for Internet addressing, mail proxy, and
-   other information. The DNS has been extended to include digital
-   signatures and cryptographic keys as described in [RFC 2535].  Thus
-   the DNS can now be secured and can be used for secure key
-   distribution.
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 1]
-
-RFC 2536                     DSA in the DNS                   March 1999
-
-
-   This document describes how to store US Government Digital Signature
-   Algorithm (DSA) keys and signatures in the DNS.  Familiarity with the
-   US Digital Signature Algorithm is assumed [Schneier].  Implementation
-   of DSA is mandatory for DNS security.
-
-2. DSA KEY Resource Records
-
-   DSA public keys are stored in the DNS as KEY RRs using algorithm
-   number 3 [RFC 2535].  The structure of the algorithm specific portion
-   of the RDATA part of this RR is as shown below.  These fields, from Q
-   through Y are the "public key" part of the DSA KEY RR.
-
-   The period of key validity is not in the KEY RR but is indicated by
-   the SIG RR(s) which signs and authenticates the KEY RR(s) at that
-   domain name.
-
-           Field     Size
-           -----     ----
-            T         1  octet
-            Q        20  octets
-            P        64 + T*8  octets
-            G        64 + T*8  octets
-            Y        64 + T*8  octets
-
-   As described in [FIPS 186] and [Schneier]: T is a key size parameter
-   chosen such that 0 <= T <= 8.  (The meaning for algorithm 3 if the T
-   octet is greater than 8 is reserved and the remainder of the RDATA
-   portion may have a different format in that case.)  Q is a prime
-   number selected at key generation time such that 2**159 < Q < 2**160
-   so Q is always 20 octets long and, as with all other fields, is
-   stored in "big-endian" network order.  P, G, and Y are calculated as
-   directed by the FIPS 186 key generation algorithm [Schneier].  P is
-   in the range 2**(511+64T) < P < 2**(512+64T) and so is 64 + 8*T
-   octets long.  G and Y are quantities modulus P and so can be up to
-   the same length as P and are allocated fixed size fields with the
-   same number of octets as P.
-
-   During the key generation process, a random number X must be
-   generated such that 1 <= X <= Q-1.  X is the private key and is used
-   in the final step of public key generation where Y is computed as
-
-             Y = G**X mod P
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 2]
-
-RFC 2536                     DSA in the DNS                   March 1999
-
-
-3. DSA SIG Resource Records
-
-   The signature portion of the SIG RR RDATA area, when using the US
-   Digital Signature Algorithm, is shown below with fields in the order
-   they occur.  See [RFC 2535] for fields in the SIG RR RDATA which
-   precede the signature itself.
-
-           Field     Size
-           -----     ----
-            T         1 octet
-            R        20 octets
-            S        20 octets
-
-   The data signed is determined as specified in [RFC 2535].  Then the
-   following steps are taken, as specified in [FIPS 186], where Q, P, G,
-   and Y are as specified in the public key [Schneier]:
-
-           hash = SHA-1 ( data )
-
-           Generate a random K such that 0 < K < Q.
-
-           R = ( G**K mod P ) mod Q
-
-           S = ( K**(-1) * (hash + X*R) ) mod Q
-
-   Since Q is 160 bits long, R and S can not be larger than 20 octets,
-   which is the space allocated.
-
-   T is copied from the public key.  It is not logically necessary in
-   the SIG but is present so that values of T > 8 can more conveniently
-   be used as an escape for extended versions of DSA or other algorithms
-   as later specified.
-
-4. Performance Considerations
-
-   General signature generation speeds are roughly the same for RSA [RFC
-   2537] and DSA.  With sufficient pre-computation, signature generation
-   with DSA is faster than RSA.  Key generation is also faster for DSA.
-   However, signature verification is an order of magnitude slower than
-   RSA when the RSA public exponent is chosen to be small as is
-   recommended for KEY RRs used in domain name system (DNS) data
-   authentication.
-
-   Current DNS implementations are optimized for small transfers,
-   typically less than 512 bytes including overhead.  While larger
-   transfers will perform correctly and work is underway to make larger
-   transfers more efficient, it is still advisable at this time to make
-   reasonable efforts to minimize the size of KEY RR sets stored within
-
-
-
-Eastlake                    Standards Track                     [Page 3]
-
-RFC 2536                     DSA in the DNS                   March 1999
-
-
-   the DNS consistent with adequate security.  Keep in mind that in a
-   secure zone, at least one authenticating SIG RR will also be
-   returned.
-
-5. Security Considerations
-
-   Many of the general security consideration in [RFC 2535] apply.  Keys
-   retrieved from the DNS should not be trusted unless (1) they have
-   been securely obtained from a secure resolver or independently
-   verified by the user and (2) this secure resolver and secure
-   obtainment or independent verification conform to security policies
-   acceptable to the user.  As with all cryptographic algorithms,
-   evaluating the necessary strength of the key is essential and
-   dependent on local policy.
-
-   The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
-   current DSA standard may limit the security of DSA.  For particularly
-   critical applications, implementors are encouraged to consider the
-   range of available algorithms and key sizes.
-
-   DSA assumes the ability to frequently generate high quality random
-   numbers.  See [RFC 1750] for guidance.  DSA is designed so that if
-   manipulated rather than random numbers are used, very high bandwidth
-   covert channels are possible.  See [Schneier] and more recent
-   research.  The leakage of an entire DSA private key in only two DSA
-   signatures has been demonstrated.  DSA provides security only if
-   trusted implementations, including trusted random number generation,
-   are used.
-
-6. IANA Considerations
-
-   Allocation of meaning to values of the T parameter that are not
-   defined herein requires an IETF standards actions.  It is intended
-   that values unallocated herein be used to cover future extensions of
-   the DSS standard.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 4]
-
-RFC 2536                     DSA in the DNS                   March 1999
-
-
-References
-
-   [FIPS 186]   U.S. Federal Information Processing Standard: Digital
-                Signature Standard.
-
-   [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
-                Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC 1035]   Mockapetris, P., "Domain Names - Implementation and
-                Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC 1750]   Eastlake, D., Crocker, S. and J. Schiller, "Randomness
-                Recommendations for Security", RFC 1750, December 1994.
-
-   [RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",
-                RFC 2535, March 1999.
-
-   [RFC 2537]   Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
-                System (DNS)", RFC 2537, March 1999.
-
-   [Schneier]   Schneier, B., "Applied Cryptography Second Edition:
-                protocols, algorithms, and source code in C", 1996.
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   IBM
-   65 Shindegan Hill Road, RR #1
-   Carmel, NY 10512
-
-   Phone:   +1-914-276-2668(h)
-            +1-914-784-7913(w)
-   Fax:     +1-914-784-3833(w)
-   EMail:   dee3@us.ibm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 5]
-
-RFC 2536                     DSA in the DNS                   March 1999
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 6]
-
diff --git a/contrib/bind9/doc/rfc/rfc2537.txt b/contrib/bind9/doc/rfc/rfc2537.txt
deleted file mode 100644
index cb75cf5..0000000
--- a/contrib/bind9/doc/rfc/rfc2537.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        D. Eastlake
-Request for Comments: 2537                                           IBM
-Category: Standards Track                                     March 1999
-
-
-         RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   A standard method for storing RSA keys and and RSA/MD5 based
-   signatures in the Domain Name System is described which utilizes DNS
-   KEY and SIG resource records.
-
-Table of Contents
-
-   Abstract...................................................1
-   1. Introduction............................................1
-   2. RSA Public KEY Resource Records.........................2
-   3. RSA/MD5 SIG Resource Records............................2
-   4. Performance Considerations..............................3
-   5. Security Considerations.................................4
-   References.................................................4
-   Author's Address...........................................5
-   Full Copyright Statement...................................6
-
-1. Introduction
-
-   The Domain Name System (DNS) is the global hierarchical replicated
-   distributed database system for Internet addressing, mail proxy, and
-   other information. The DNS has been extended to include digital
-   signatures and cryptographic keys as described in [RFC 2535].  Thus
-   the DNS can now be secured and used for secure key distribution.
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 1]
-
-RFC 2537            RSA/MD5 KEYs and SIGs in the DNS          March 1999
-
-
-   This document describes how to store RSA keys and and RSA/MD5 based
-   signatures in the DNS.  Familiarity with the RSA algorithm is assumed
-   [Schneier].  Implementation of the RSA algorithm in DNS is
-   recommended.
-
-   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
-   in this document are to be interpreted as described in RFC 2119.
-
-2. RSA Public KEY Resource Records
-
-   RSA public keys are stored in the DNS as KEY RRs using algorithm
-   number 1 [RFC 2535].  The structure of the algorithm specific portion
-   of the RDATA part of such RRs is as shown below.
-
-           Field             Size
-           -----             ----
-           exponent length   1 or 3 octets (see text)
-           exponent          as specified by length field
-           modulus           remaining space
-
-   For interoperability, the exponent and modulus are each currently
-   limited to 4096 bits in length.  The public key exponent is a
-   variable length unsigned integer.  Its length in octets is
-   represented as one octet if it is in the range of 1 to 255 and by a
-   zero octet followed by a two octet unsigned length if it is longer
-   than 255 bytes.  The public key modulus field is a multiprecision
-   unsigned integer.  The length of the modulus can be determined from
-   the RDLENGTH and the preceding RDATA fields including the exponent.
-   Leading zero octets are prohibited in the exponent and modulus.
-
-3. RSA/MD5 SIG Resource Records
-
-   The signature portion of the SIG RR RDATA area, when using the
-   RSA/MD5 algorithm, is calculated as shown below.  The data signed is
-   determined as specified in [RFC 2535].  See [RFC 2535] for fields in
-   the SIG RR RDATA which precede the signature itself.
-
-
-     hash = MD5 ( data )
-
-     signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 2]
-
-RFC 2537            RSA/MD5 KEYs and SIGs in the DNS          March 1999
-
-
-   where MD5 is the message digest algorithm documented in [RFC 1321],
-   "|" is concatenation, "e" is the private key exponent of the signer,
-   and "n" is the modulus of the signer's public key.  01, FF, and 00
-   are fixed octets of the corresponding hexadecimal value. "prefix" is
-   the ASN.1 BER MD5 algorithm designator prefix specified in [RFC
-   2437], that is,
-
-      hex 3020300c06082a864886f70d020505000410 [NETSEC].
-
-   This prefix is included to make it easier to use RSAREF (or similar
-   packages such as EuroRef).  The FF octet MUST be repeated the maximum
-   number of times such that the value of the quantity being
-   exponentiated is the same length in octets as the value of n.
-
-   (The above specifications are identical to the corresponding part of
-   Public Key Cryptographic Standard #1 [RFC 2437].)
-
-   The size of n, including most and least significant bits (which will
-   be 1) MUST be not less than 512 bits and not more than 4096 bits.  n
-   and e SHOULD be chosen such that the public exponent is small.
-
-   Leading zero bytes are permitted in the RSA/MD5 algorithm signature.
-
-   A public exponent of 3 minimizes the effort needed to verify a
-   signature.  Use of 3 as the public exponent is weak for
-   confidentiality uses since, if the same data can be collected
-   encrypted under three different keys with an exponent of 3 then,
-   using the Chinese Remainder Theorem [NETSEC], the original plain text
-   can be easily recovered.  This weakness is not significant for DNS
-   security because we seek only authentication, not confidentiality.
-
-4. Performance Considerations
-
-   General signature generation speeds are roughly the same for RSA and
-   DSA [RFC 2536].  With sufficient pre-computation, signature
-   generation with DSA is faster than RSA.  Key generation is also
-   faster for DSA.  However, signature verification is an order of
-   magnitude slower with DSA when the RSA public exponent is chosen to
-   be small as is recommended for KEY RRs used in domain name system
-   (DNS) data authentication.
-
-   Current DNS implementations are optimized for small transfers,
-   typically less than 512 bytes including overhead.  While larger
-   transfers will perform correctly and work is underway to make larger
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 3]
-
-RFC 2537            RSA/MD5 KEYs and SIGs in the DNS          March 1999
-
-
-   transfers more efficient, it is still advisable at this time to make
-   reasonable efforts to minimize the size of KEY RR sets stored within
-   the DNS consistent with adequate security.  Keep in mind that in a
-   secure zone, at least one authenticating SIG RR will also be
-   returned.
-
-5. Security Considerations
-
-   Many of the general security consideration in [RFC 2535] apply.  Keys
-   retrieved from the DNS should not be trusted unless (1) they have
-   been securely obtained from a secure resolver or independently
-   verified by the user and (2) this secure resolver and secure
-   obtainment or independent verification conform to security policies
-   acceptable to the user.  As with all cryptographic algorithms,
-   evaluating the necessary strength of the key is essential and
-   dependent on local policy.
-
-   For interoperability, the RSA key size is limited to 4096 bits.  For
-   particularly critical applications, implementors are encouraged to
-   consider the range of available algorithms and key sizes.
-
-References
-
-   [NETSEC]     Kaufman, C., Perlman, R. and M. Speciner, "Network
-                Security: PRIVATE Communications in a PUBLIC World",
-                Series in Computer Networking and Distributed
-                Communications, 1995.
-
-   [RFC 2437]   Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
-                Specifications Version 2.0", RFC 2437, October 1998.
-
-   [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
-                Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC 1035]   Mockapetris, P., "Domain Names - Implementation and
-                Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC 1321]   Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321
-                April 1992.
-
-   [RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",
-                RFC 2535, March 1999.
-
-   [RFC 2536]   EastLake, D., "DSA KEYs and SIGs in the Domain Name
-                System (DNS)", RFC 2536, March 1999.
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 4]
-
-RFC 2537            RSA/MD5 KEYs and SIGs in the DNS          March 1999
-
-
-   [Schneier]   Bruce Schneier, "Applied Cryptography Second Edition:
-                protocols, algorithms, and source code in C", 1996, John
-                Wiley and Sons, ISBN 0-471-11709-9.
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   IBM
-   65 Shindegan Hill Road, RR #1
-   Carmel, NY 10512
-
-   Phone:   +1-914-276-2668(h)
-            +1-914-784-7913(w)
-   Fax:     +1-914-784-3833(w)
-   EMail:   dee3@us.ibm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 5]
-
-RFC 2537            RSA/MD5 KEYs and SIGs in the DNS          March 1999
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 6]
-
diff --git a/contrib/bind9/doc/rfc/rfc2538.txt b/contrib/bind9/doc/rfc/rfc2538.txt
deleted file mode 100644
index c53e3ef..0000000
--- a/contrib/bind9/doc/rfc/rfc2538.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        D. Eastlake
-Request for Comments: 2538                                           IBM
-Category: Standards Track                                 O. Gudmundsson
-                                                                TIS Labs
-                                                              March 1999
-
-
-          Storing Certificates in the Domain Name System (DNS)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   Cryptographic public key are frequently published and their
-   authenticity demonstrated by certificates.  A CERT resource record
-   (RR) is defined so that such certificates and related certificate
-   revocation lists can be stored in the Domain Name System (DNS).
-
-Table of Contents
-
-   Abstract...................................................1
-   1. Introduction............................................2
-   2. The CERT Resource Record................................2
-   2.1 Certificate Type Values................................3
-   2.2 Text Representation of CERT RRs........................4
-   2.3 X.509 OIDs.............................................4
-   3. Appropriate Owner Names for CERT RRs....................5
-   3.1 X.509 CERT RR Names....................................5
-   3.2 PGP CERT RR Names......................................6
-   4. Performance Considerations..............................6
-   5. IANA Considerations.....................................7
-   6. Security Considerations.................................7
-   References.................................................8
-   Authors' Addresses.........................................9
-   Full Copyright Notice.....................................10
-
-
-
-
-
-
-Eastlake & Gudmundsson      Standards Track                     [Page 1]
-
-RFC 2538            Storing Certificates in the DNS           March 1999
-
-
-1. Introduction
-
-   Public keys are frequently published in the form of a certificate and
-   their authenticity is commonly demonstrated by certificates and
-   related certificate revocation lists (CRLs).  A certificate is a
-   binding, through a cryptographic digital signature, of a public key,
-   a validity interval and/or conditions, and identity, authorization,
-   or other information. A certificate revocation list is a list of
-   certificates that are revoked, and incidental information, all signed
-   by the signer (issuer) of the revoked certificates. Examples are
-   X.509 certificates/CRLs in the X.500 directory system or PGP
-   certificates/revocations used by PGP software.
-
-   Section 2 below specifies a CERT resource record (RR) for the storage
-   of certificates in the Domain Name System.
-
-   Section 3 discusses appropriate owner names for CERT RRs.
-
-   Sections 4, 5, and 6 below cover performance, IANA, and security
-   considerations, respectively.
-
-   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].
-
-2. The CERT Resource Record
-
-   The CERT resource record (RR) has the structure given below.  Its RR
-   type code is 37.
-
-                         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              |             key tag           |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |   algorithm   |                                               /
-    +---------------+            certificate or CRL                 /
-    /                                                               /
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
-   The type field is the certificate type as define in section 2.1
-   below.
-
-   The algorithm field has the same meaning as the algorithm field in
-   KEY and SIG RRs [RFC 2535] except that a zero algorithm field
-   indicates the algorithm is unknown to a secure DNS, which may simply
-   be the result of the algorithm not having been standardized for
-   secure DNS.
-
-
-
-Eastlake & Gudmundsson      Standards Track                     [Page 2]
-
-RFC 2538            Storing Certificates in the DNS           March 1999
-
-
-   The key tag field is the 16 bit value computed for the key embedded
-   in the certificate as specified in the DNSSEC Standard [RFC 2535].
-   This field is used as an efficiency measure to pick which CERT RRs
-   may be applicable to a particular key.  The key tag can be calculated
-   for the key in question and then only CERT RRs with the same key tag
-   need be examined. However, the key must always be transformed to the
-   format it would have as the public key portion of a KEY RR before the
-   key tag is computed.  This is only possible if the key is applicable
-   to an algorithm (and limits such as key size limits) defined for DNS
-   security.  If it is not, the algorithm field MUST BE zero and the tag
-   field is meaningless and SHOULD BE zero.
-
-2.1 Certificate Type Values
-
-   The following values are defined or reserved:
-
-    Value  Mnemonic  Certificate Type
-    -----  --------  ----------- ----
-        0            reserved
-        1   PKIX     X.509 as per PKIX
-        2   SPKI     SPKI cert
-        3   PGP      PGP cert
-    4-252            available for IANA assignment
-      253   URI      URI private
-      254   OID      OID private
-    255-65534        available for IANA assignment
-    65535            reserved
-
-   The PKIX type is reserved to indicate an X.509 certificate conforming
-   to the profile being defined by the IETF PKIX working group.  The
-   certificate section will start with a one byte unsigned OID length
-   and then an X.500 OID indicating the nature of the remainder of the
-   certificate section (see 2.3 below).  (NOTE: X.509 certificates do
-   not include their X.500 directory type designating OID as a prefix.)
-
-   The SPKI type is reserved to indicate a certificate formated as to be
-   specified by the IETF SPKI working group.
-
-   The PGP type indicates a Pretty Good Privacy certificate as described
-   in RFC 2440 and its extensions and successors.
-
-   The URI private type indicates a certificate format defined by an
-   absolute URI.  The certificate portion of the CERT RR MUST begin with
-   a null terminated URI [RFC 2396] and the data after the null is the
-   private format certificate itself.  The URI SHOULD be such that a
-   retrieval from it will lead to documentation on the format of the
-   certificate.  Recognition of private certificate types need not be
-   based on URI equality but can use various forms of pattern matching
-
-
-
-Eastlake & Gudmundsson      Standards Track                     [Page 3]
-
-RFC 2538            Storing Certificates in the DNS           March 1999
-
-
-   so that, for example, subtype or version information can also be
-   encoded into the URI.
-
-   The OID private type indicates a private format certificate specified
-   by a an ISO OID prefix.  The certificate section will start with a
-   one byte unsigned OID length and then a BER encoded OID indicating
-   the nature of the remainder of the certificate section.  This can be
-   an X.509 certificate format or some other format.  X.509 certificates
-   that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
-   type, not the OID private type.  Recognition of private certificate
-   types need not be based on OID equality but can use various forms of
-   pattern matching such as OID prefix.
-
-2.2 Text Representation of CERT RRs
-
-   The RDATA portion of a CERT RR has the type field as an unsigned
-   integer or as a mnemonic symbol as listed in section 2.1 above.
-
-   The key tag field is represented as an unsigned integer.
-
-   The algorithm field is represented as an unsigned integer or a
-   mnemonic symbol as listed in [RFC 2535].
-
-   The certificate / CRL portion is represented in base 64 and may be
-   divided up into any number of white space separated substrings, down
-   to single base 64 digits, which are concatenated to obtain the full
-   signature.  These substrings can span lines using the standard
-   parenthesis.
-
-   Note that the certificate / CRL portion may have internal sub-fields
-   but these do not appear in the master file representation.  For
-   example, with type 254, there will be an OID size, an OID, and then
-   the certificate / CRL proper. But only a single logical base 64
-   string will appear in the text representation.
-
-2.3 X.509 OIDs
-
-   OIDs have been defined in connection with the X.500 directory for
-   user certificates, certification authority certificates, revocations
-   of certification authority, and revocations of user certificates.
-   The following table lists the OIDs, their BER encoding, and their
-   length prefixed hex format for use in CERT RRs:
-
-
-
-
-
-
-
-
-
-Eastlake & Gudmundsson      Standards Track                     [Page 4]
-
-RFC 2538            Storing Certificates in the DNS           March 1999
-
-
-    id-at-userCertificate
-        = { joint-iso-ccitt(2) ds(5) at(4) 36 }
-           == 0x 03 55 04 24
-    id-at-cACertificate
-        = { joint-iso-ccitt(2) ds(5) at(4) 37 }
-           == 0x 03 55 04 25
-    id-at-authorityRevocationList
-        = { joint-iso-ccitt(2) ds(5) at(4) 38 }
-           == 0x 03 55 04 26
-    id-at-certificateRevocationList
-        = { joint-iso-ccitt(2) ds(5) at(4) 39 }
-           == 0x 03 55 04 27
-
-3. Appropriate Owner Names for CERT RRs
-
-   It is recommended that certificate CERT RRs be stored under a domain
-   name related to their subject, i.e., the name of the entity intended
-   to control the private key corresponding to the public key being
-   certified.  It is recommended that certificate revocation list CERT
-   RRs be stored under a domain name related to their issuer.
-
-   Following some of the guidelines below may result in the use in DNS
-   names of characters that require DNS quoting which is to use a
-   backslash followed by the octal representation of the ASCII code for
-   the character such as \000 for NULL.
-
-3.1 X.509 CERT RR Names
-
-   Some X.509 versions permit multiple names to be associated with
-   subjects and issuers under "Subject Alternate Name" and "Issuer
-   Alternate Name".  For example, x.509v3 has such Alternate Names with
-   an ASN.1 specification as follows:
-
-         GeneralName ::= CHOICE {
-            otherName                  [0] INSTANCE OF OTHER-NAME,
-            rfc822Name                 [1] IA5String,
-            dNSName                    [2] IA5String,
-            x400Address                [3] EXPLICIT OR-ADDRESS.&Type,
-            directoryName              [4] EXPLICIT Name,
-            ediPartyName               [5] EDIPartyName,
-            uniformResourceIdentifier  [6] IA5String,
-            iPAddress                  [7] OCTET STRING,
-            registeredID               [8] OBJECT IDENTIFIER
-         }
-
-   The recommended locations of CERT storage are as follows, in priority
-   order:
-
-
-
-
-Eastlake & Gudmundsson      Standards Track                     [Page 5]
-
-RFC 2538            Storing Certificates in the DNS           March 1999
-
-
-   (1) If a domain name is included in the identification in the
-       certificate or CRL, that should be used.
-   (2) If a domain name is not included but an IP address is included,
-       then the translation of that IP address into the appropriate
-       inverse domain name should be used.
-   (3) If neither of the above it used but a URI containing a domain
-       name is present, that domain name should be used.
-   (4) If none of the above is included but a character string name is
-       included, then it should be treated as described for PGP names in
-       3.2 below.
-   (5) If none of the above apply, then the distinguished name (DN)
-       should be mapped into a domain name as specified in RFC 2247.
-
-   Example 1: Assume that an X.509v3 certificate is issued to /CN=John
-   Doe/DC=Doe/DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative
-   names of (a) string "John (the Man) Doe", (b) domain name john-
-   doe.com, and (c) uri <https://www.secure.john-doe.com:8080/>.  Then
-   the storage locations recommended, in priority order, would be
-       (1) john-doe.com,
-       (2) www.secure.john-doe.com, and
-       (3) Doe.com.xy.
-
-   Example 2:  Assume that an X.509v3 certificate is issued to /CN=James
-   Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names
-   of (a) domain name widget.foo.example, (b) IPv4 address
-   10.251.13.201, and (c) string "James Hacker
-   <hacker@mail.widget.foo.example>".  Then the storage locations
-   recommended, in priority order, would be
-        (1) widget.foo.example,
-        (2) 201.13.251.10.in-addr.arpa, and
-        (3) hacker.mail.widget.foo.example.
-
-3.2 PGP CERT RR Names
-
-   PGP signed keys (certificates) use a general character string User ID
-   [RFC 2440]. However, it is recommended by PGP that such names include
-   the RFC 822 email address of the party, as in "Leslie Example
-   <Leslie@host.example>".  If such a format is used, the CERT should be
-   under the standard translation of the email address into a domain
-   name, which would be leslie.host.example in this case.  If no RFC 822
-   name can be extracted from the string name no specific domain name is
-   recommended.
-
-4. Performance Considerations
-
-   Current Domain Name System (DNS) implementations are optimized for
-   small transfers, typically not more than 512 bytes including
-   overhead.  While larger transfers will perform correctly and work is
-
-
-
-Eastlake & Gudmundsson      Standards Track                     [Page 6]
-
-RFC 2538            Storing Certificates in the DNS           March 1999
-
-
-   underway to make larger transfers more efficient, it is still
-   advisable at this time to make every reasonable effort to minimize
-   the size of certificates stored within the DNS.  Steps that can be
-   taken may include using the fewest possible optional or extensions
-   fields and using short field values for variable length fields that
-   must be included.
-
-5. IANA Considerations
-
-   Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
-   only be assigned by an IETF standards action [RFC 2434] (and this
-   document assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE).
-   Certificate types 0x0100 through 0xFEFF are assigned through IETF
-   Consensus [RFC 2434] based on RFC documentation of the certificate
-   type.  The availability of private types under 0x00FD and 0x00FE
-   should satisfy most requirements for proprietary or private types.
-
-6. Security Considerations
-
-   By definition, certificates contain their own authenticating
-   signature.  Thus it is reasonable to store certificates in non-secure
-   DNS zones or to retrieve certificates from DNS with DNS security
-   checking not implemented or deferred for efficiency.  The results MAY
-   be trusted if the certificate chain is verified back to a known
-   trusted key and this conforms with the user's security policy.
-
-   Alternatively, if certificates are retrieved from a secure DNS zone
-   with DNS security checking enabled and are verified by DNS security,
-   the key within the retrieved certificate MAY be trusted without
-   verifying the certificate chain if this conforms with the user's
-   security policy.
-
-   CERT RRs are not used in connection with securing the DNS security
-   additions so there are no security considerations related to CERT RRs
-   and securing the DNS itself.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake & Gudmundsson      Standards Track                     [Page 7]
-
-RFC 2538            Storing Certificates in the DNS           March 1999
-
-
-References
-
-   RFC 1034   Mockapetris, P., "Domain Names - Concepts and Facilities",
-              STD 13, RFC 1034, November 1987.
-
-   RFC 1035   Mockapetris, P., "Domain Names - Implementation and
-              Specifications", STD 13, RFC 1035, November 1987.
-
-   RFC 2119   Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   RFC 2247   Kille, S., Wahl, M., Grimstad, A., Huber, R. and S.
-              Sataluri, "Using Domains in LDAP/X.500 Distinguished
-              Names", RFC 2247, January 1998.
-
-   RFC 2396   Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
-              Resource Identifiers (URI): Generic Syntax", RFC 2396,
-              August 1998.
-
-   RFC 2440   Callas, J., Donnerhacke, L., Finney, H. and R.  Thayer,
-              "OpenPGP Message Format", RFC 2240, November 1998.
-
-   RFC 2434   Narten, T. and H. Alvestrand, "Guidelines for Writing an
-              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
-              October 1998.
-
-   RFC 2535   Eastlake, D., "Domain Name System (DNS) Security
-              Extensions", RFC 2535, March 1999.
-
-   RFC 2459   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
-              X.509 Public Key Infrastructure Certificate and CRL
-              Profile", RFC 2459, January 1999.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake & Gudmundsson      Standards Track                     [Page 8]
-
-RFC 2538            Storing Certificates in the DNS           March 1999
-
-
-Authors' Addresses
-
-   Donald E. Eastlake 3rd
-   IBM
-   65 Shindegan Hill Road
-   RR#1
-   Carmel, NY 10512 USA
-
-   Phone:   +1-914-784-7913 (w)
-            +1-914-276-2668 (h)
-   Fax:     +1-914-784-3833 (w-fax)
-   EMail:   dee3@us.ibm.com
-
-
-   Olafur Gudmundsson
-   TIS Labs at Network Associates
-   3060 Washington Rd, Route 97
-   Glenwood MD 21738
-
-   Phone: +1 443-259-2389
-   EMail: ogud@tislabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake & Gudmundsson      Standards Track                     [Page 9]
-
-RFC 2538            Storing Certificates in the DNS           March 1999
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake & Gudmundsson      Standards Track                    [Page 10]
-
diff --git a/contrib/bind9/doc/rfc/rfc2539.txt b/contrib/bind9/doc/rfc/rfc2539.txt
deleted file mode 100644
index cf32523..0000000
--- a/contrib/bind9/doc/rfc/rfc2539.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        D. Eastlake
-Request for Comments: 2539                                           IBM
-Category: Standards Track                                     March 1999
-
-
-     Storage of Diffie-Hellman Keys in the Domain Name System (DNS)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   A standard method for storing Diffie-Hellman keys in the Domain Name
-   System is described which utilizes DNS KEY resource records.
-
-Acknowledgements
-
-   Part of the format for Diffie-Hellman keys and the description
-   thereof was taken from a work in progress by:
-
-      Ashar Aziz <ashar.aziz@eng.sun.com>
-      Tom Markson <markson@incog.com>
-      Hemma Prafullchandra <hemma@eng.sun.com>
-
-   In addition, the following person provided useful comments that have
-   been incorporated:
-
-      Ran Atkinson <rja@inet.org>
-      Thomas Narten <narten@raleigh.ibm.com>
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 1]
-
-RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
-
-
-Table of Contents
-
-   Abstract...................................................1
-   Acknowledgements...........................................1
-   1. Introduction............................................2
-   1.1 About This Document....................................2
-   1.2 About Diffie-Hellman...................................2
-   2. Diffie-Hellman KEY Resource Records.....................3
-   3. Performance Considerations..............................4
-   4. IANA Considerations.....................................4
-   5. Security Considerations.................................4
-   References.................................................5
-   Author's Address...........................................5
-   Appendix A: Well known prime/generator pairs...............6
-   A.1. Well-Known Group 1:  A 768 bit prime..................6
-   A.2. Well-Known Group 2:  A 1024 bit prime.................6
-   Full Copyright Notice......................................7
-
-1. Introduction
-
-   The Domain Name System (DNS) is the current global hierarchical
-   replicated distributed database system for Internet addressing, mail
-   proxy, and similar information. The DNS has been extended to include
-   digital signatures and cryptographic keys as described in [RFC 2535].
-   Thus the DNS can now be used for secure key distribution.
-
-1.1 About This Document
-
-   This document describes how to store Diffie-Hellman keys in the DNS.
-   Familiarity with the Diffie-Hellman key exchange algorithm is assumed
-   [Schneier].
-
-1.2 About Diffie-Hellman
-
-   Diffie-Hellman requires two parties to interact to derive keying
-   information which can then be used for authentication.  Since DNS SIG
-   RRs are primarily used as stored authenticators of zone information
-   for many different resolvers, no Diffie-Hellman algorithm SIG RR is
-   defined. For example, assume that two parties have local secrets "i"
-   and "j".  Assume they each respectively calculate X and Y as follows:
-
-                X = g**i ( mod p ) Y = g**j ( mod p )
-
-   They exchange these quantities and then each calculates a Z as
-   follows:
-
-                Zi = Y**i ( mod p ) Zj = X**j ( mod p )
-
-
-
-
-Eastlake                    Standards Track                     [Page 2]
-
-RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
-
-
-   shared secret between the two parties that an adversary who does not
-   know i or j will not be able to learn from the exchanged messages
-   (unless the adversary can derive i or j by performing a discrete
-   logarithm mod p which is hard for strong p and g).
-
-   The private key for each party is their secret i (or j).  The public
-   key is the pair p and g, which must be the same for the parties, and
-   their individual X (or Y).
-
-2. Diffie-Hellman KEY Resource Records
-
-   Diffie-Hellman keys are stored in the DNS as KEY RRs using algorithm
-   number 2.  The structure of the RDATA portion of this RR is as shown
-   below.  The first 4 octets, including the flags, protocol, and
-   algorithm fields are common to all KEY RRs as described in [RFC
-   2535].  The remainder, from prime length through public value is the
-   "public key" part of the KEY RR. The period of key validity is not in
-   the KEY RR but is indicated by the SIG RR(s) which signs and
-   authenticates the KEY RR(s) at that domain name.
-
-                         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 flags           |    protocol   |  algorithm=2  |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |     prime length (or flag)    |  prime (p) (or special)       /
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    /  prime (p)  (variable length) |       generator length        |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    | generator (g) (variable length)                               |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |     public value length       | public value (variable length)/
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    /  public value (g^i mod p)    (variable length)                |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   Prime length is length of the Diffie-Hellman prime (p) in bytes if it
-   is 16 or greater.  Prime contains the binary representation of the
-   Diffie-Hellman prime with most significant byte first (i.e., in
-   network order). If "prime length" field is 1 or 2, then the "prime"
-   field is actually an unsigned index into a table of 65,536
-   prime/generator pairs and the generator length SHOULD be zero.  See
-   Appedix A for defined table entries and Section 4 for information on
-   allocating additional table entries.  The meaning of a zero or 3
-   through 15 value for "prime length" is reserved.
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 3]
-
-RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
-
-
-   Generator length is the length of the generator (g) in bytes.
-   Generator is the binary representation of generator with most
-   significant byte first.  PublicValueLen is the Length of the Public
-   Value (g**i (mod p)) in bytes.  PublicValue is the binary
-   representation of the DH public value with most significant byte
-   first.
-
-   The corresponding algorithm=2 SIG resource record is not used so no
-   format for it is defined.
-
-3. Performance Considerations
-
-   Current DNS implementations are optimized for small transfers,
-   typically less than 512 bytes including overhead.  While larger
-   transfers will perform correctly and work is underway to make larger
-   transfers more efficient, it is still advisable to make reasonable
-   efforts to minimize the size of KEY RR sets stored within the DNS
-   consistent with adequate security.  Keep in mind that in a secure
-   zone, an authenticating SIG RR will also be returned.
-
-4. IANA Considerations
-
-   Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
-   an IETF consensus.
-
-   Well known prime/generator pairs number 0x0000 through 0x07FF can
-   only be assigned by an IETF standards action and this Proposed
-   Standard assigns 0x0001 through 0x0002. Pairs number 0s0800 through
-   0xBFFF can be assigned based on RFC documentation.  Pairs number
-   0xC000 through 0xFFFF are available for private use and are not
-   centrally coordinated. Use of such private pairs outside of a closed
-   environment may result in conflicts.
-
-5. Security Considerations
-
-   Many of the general security consideration in [RFC 2535] apply.  Keys
-   retrieved from the DNS should not be trusted unless (1) they have
-   been securely obtained from a secure resolver or independently
-   verified by the user and (2) this secure resolver and secure
-   obtainment or independent verification conform to security policies
-   acceptable to the user.  As with all cryptographic algorithms,
-   evaluating the necessary strength of the key is important and
-   dependent on local policy.
-
-   In addition, the usual Diffie-Hellman key strength considerations
-   apply. (p-1)/2 should also be prime, g should be primitive mod p, p
-   should be "large", etc.  [Schneier]
-
-
-
-
-Eastlake                    Standards Track                     [Page 4]
-
-RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
-
-
-References
-
-   [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
-                Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC 1035]   Mockapetris, P., "Domain Names - Implementation and
-                Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",
-                RFC 2535, March 1999.
-
-   [Schneier]   Bruce Schneier, "Applied Cryptography: Protocols,
-                Algorithms, and Source Code in C", 1996, John Wiley and
-                Sons
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   IBM
-   65 Shindegan Hill Road, RR #1
-   Carmel, NY 10512
-
-   Phone:   +1-914-276-2668(h)
-            +1-914-784-7913(w)
-   Fax:     +1-914-784-3833(w)
-   EMail:   dee3@us.ibm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 5]
-
-RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
-
-
-Appendix A: Well known prime/generator pairs
-
-   These numbers are copied from the IPSEC effort where the derivation
-   of these values is more fully explained and additional information is
-   available.  Richard Schroeppel performed all the mathematical and
-   computational work for this appendix.
-
-A.1. Well-Known Group 1:  A 768 bit prime
-
-   The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }.  Its
-   decimal value is
-          155251809230070893513091813125848175563133404943451431320235
-          119490296623994910210725866945387659164244291000768028886422
-          915080371891804634263272761303128298374438082089019628850917
-          0691316593175367469551763119843371637221007210577919
-
-   Prime modulus: Length (32 bit words): 24, Data (hex):
-            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
-            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
-            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
-            E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
-
-   Generator: Length (32 bit words): 1, Data (hex): 2
-
-A.2. Well-Known Group 2:  A 1024 bit prime
-
-   The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
-   Its decimal value is
-         179769313486231590770839156793787453197860296048756011706444
-         423684197180216158519368947833795864925541502180565485980503
-         646440548199239100050792877003355816639229553136239076508735
-         759914822574862575007425302077447712589550957937778424442426
-         617334727629299387668709205606050270810842907692932019128194
-         467627007
-
-   Prime modulus:  Length (32 bit words): 32, Data (hex):
-            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
-            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
-            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
-            E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
-            EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
-            FFFFFFFF FFFFFFFF
-
-   Generator: Length (32 bit words):  1, Data (hex): 2
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 6]
-
-RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc2540.txt b/contrib/bind9/doc/rfc/rfc2540.txt
deleted file mode 100644
index 6314806..0000000
--- a/contrib/bind9/doc/rfc/rfc2540.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        D. Eastlake
-Request for Comments: 2540                                           IBM
-Category: Experimental                                        March 1999
-
-
-             Detached Domain Name System (DNS) Information
-
-Status of this Memo
-
-   This memo defines an Experimental Protocol for the Internet
-   community.  It does not specify an Internet standard of any kind.
-   Discussion and suggestions for improvement are requested.
-   Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   A standard format is defined for representing detached DNS
-   information.  This is anticipated to be of use for storing
-   information retrieved from the Domain Name System (DNS), including
-   security information, in archival contexts or contexts not connected
-   to the Internet.
-
-Table of Contents
-
-   Abstract...................................................1
-   1. Introduction............................................1
-   2. General Format..........................................2
-   2.1 Binary Format..........................................3
-   2.2. Text Format...........................................4
-   3. Usage Example...........................................4
-   4. IANA Considerations.....................................4
-   5. Security Considerations.................................4
-   References.................................................5
-   Author's Address...........................................5
-   Full Copyright Statement...................................6
-
-1. Introduction
-
-   The Domain Name System (DNS) is a replicated hierarchical distributed
-   database system [RFC 1034, 1035] that can provide highly available
-   service.  It provides the operational basis for Internet host name to
-   address translation, automatic SMTP mail routing, and other basic
-   Internet functions.  The DNS has been extended as described in [RFC
-   2535] to permit the general storage of public cryptographic keys in
-
-
-
-Eastlake                      Experimental                      [Page 1]
-
-RFC 2540                Detached DNS Information              March 1999
-
-
-   the DNS and to enable the authentication of information retrieved
-   from the DNS though digital signatures.
-
-   The DNS was not originally designed for storage of information
-   outside of the active zones and authoritative master files that are
-   part of the connected DNS.  However there may be cases where this is
-   useful, particularly in connection with archived security
-   information.
-
-2. General Format
-
-   The formats used for detached Domain Name System (DNS) information
-   are similar to those used for connected DNS information. The primary
-   difference is that elements of the connected DNS system (unless they
-   are an authoritative server for the zone containing the information)
-   are required to count down the Time To Live (TTL) associated with
-   each DNS Resource Record (RR) and discard them (possibly fetching a
-   fresh copy) when the TTL reaches zero.  In contrast to this, detached
-   information may be stored in a off-line file, where it can not be
-   updated, and perhaps used to authenticate historic data or it might
-   be received via non-DNS protocols long after it was retrieved from
-   the DNS.  Therefore, it is not practical to count down detached DNS
-   information TTL and it may be necessary to keep the data beyond the
-   point where the TTL (which is defined as an unsigned field) would
-   underflow.  To preserve information as to the freshness of this
-   detached data, it is accompanied by its retrieval time.
-
-   Whatever retrieves the information from the DNS must associate this
-   retrieval time with it.  The retrieval time remains fixed thereafter.
-   When the current time minus the retrieval time exceeds the TTL for
-   any particular detached RR, it is no longer a valid copy within the
-   normal connected DNS scheme.  This may make it invalid in context for
-   some detached purposes as well.  If the RR is a SIG (signature) RR it
-   also has an expiration time.  Regardless of the TTL, it and any RRs
-   it signs can not be considered authenticated after the signature
-   expiration time.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                      Experimental                      [Page 2]
-
-RFC 2540                Detached DNS Information              March 1999
-
-
-2.1 Binary Format
-
-   The standard binary format for detached DNS information is as
-   follows:
-
-                         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
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |                      first retrieval time                     |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |          RR count             |                               |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Resource Records (RRs)    |
-    /                                                               /
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-    |                       next retrieval time                     |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |          RR count             |                               |
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Resource Records (RRs)    |
-    /                                                               /
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    /                              ...                              /
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    |     hex 20    |
-    +-+-+-+-+-+-+-+-+
-
-   Retrieval time - the time that the immediately following information
-       was obtained from the connected DNS system.  It is an unsigned
-       number of seconds since the start of 1 January 1970, GMT,
-       ignoring leap seconds, in network (big-endian) order.  Note that
-       this time can not be before the initial proposal of this
-       standard.  Therefore, the initial byte of an actual retrieval
-       time, considered as a 32 bit unsigned quantity, would always be
-       larger than 20 hex.  The end of detached DNS information is
-       indicated by a "retrieval time" field initial byte equal to 0x20.
-       Use of a "retrieval time" field with a leading unsigned byte of
-       zero indicates a 64 bit (actually 8 leading zero bits plus a 56
-       bit quantity).  This 64 bit format will be required when
-       retrieval time is larger than 0xFFFFFFFF, which is some time in
-       the year 2106.  The meaning of retrieval times with an initial
-       byte between 0x01 and 0x1F is reserved (see section 5).
-       Retrieval times will not generally be 32 bit aligned with respect
-       to each other due to the variable length nature of RRs.
-
-   RR count - an unsigned integer number (with bytes in network order)
-       of following resource records retrieved at the preceding
-       retrieval time.
-
-
-
-
-
-Eastlake                      Experimental                      [Page 3]
-
-RFC 2540                Detached DNS Information              March 1999
-
-
-   Resource Records - the actual data which is in the same format as if
-       it were being transmitted in a DNS response.  In particular, name
-       compression via pointers is permitted with the origin at the
-       beginning of the particular detached information data section,
-       just after the RR count.
-
-2.2. Text Format
-
-   The standard text format for detached DNS information is as
-   prescribed for zone master files [RFC 1035] except that the $INCLUDE
-   control entry is prohibited and the new $DATE entry is required
-   (unless the information set is empty). $DATE is followed by the date
-   and time that the following information was obtained from the DNS
-   system as described for retrieval time in section 2.1 above.  It is
-   in the text format YYYYMMDDHHMMSS where YYYY is the year (which may
-   be more than four digits to cover years after 9999), the first 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), the second MM is the minute
-   (00-59), and SS is the second (00-59).  Thus a $DATE must appear
-   before the first RR and at every change in retrieval time through the
-   detached information.
-
-3. Usage Example
-
-   A document might be authenticated by a key retrieved from the DNS in
-   a KEY resource record (RR).  To later prove the authenticity of this
-   document, it would be desirable to preserve the KEY RR for that
-   public key, the SIG RR signing that KEY RR, the KEY RR for the key
-   used to authenticate that SIG, and so on through SIG and KEY RRs
-   until a well known trusted key is reached, perhaps the key for the
-   DNS root or some third party authentication service. (In some cases
-   these KEY RRs will actually be sets of KEY RRs with the same owner
-   and class because SIGs actually sign such record sets.)
-
-   This information could be preserved as a set of detached DNS
-   information blocks.
-
-4. IANA Considerations
-
-   Allocation of meanings to retrieval time fields with a initial byte
-   of between 0x01 and 0x1F requires an IETF consensus.
-
-5. Security Considerations
-
-   The entirety of this document concerns a means to represent detached
-   DNS information.  Such detached resource records may be security
-   relevant and/or secured information as described in [RFC 2535].  The
-   detached format provides no overall security for sets of detached
-
-
-
-Eastlake                      Experimental                      [Page 4]
-
-RFC 2540                Detached DNS Information              March 1999
-
-
-   information or for the association between retrieval time and
-   information.  This can be provided by wrapping the detached
-   information format with some other form of signature.  However, if
-   the detached information is accompanied by SIG RRs, its validity
-   period is indicated in those SIG RRs so the retrieval time might be
-   of secondary importance.
-
-References
-
-   [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
-                Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC 1035]   Mockapetris, P., " Domain Names - Implementation and
-                Specifications", STD 13, RFC 1035, November 1987.
-
-   [RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",
-                RFC 2535, March 1999.
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   IBM
-   65 Shindegan Hill Road, RR #1
-   Carmel, NY 10512
-
-   Phone:   +1-914-276-2668(h)
-            +1-914-784-7913(w)
-   Fax:     +1-914-784-3833(w)
-   EMail:   dee3@us.ibm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                      Experimental                      [Page 5]
-
-RFC 2540                Detached DNS Information              March 1999
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                      Experimental                      [Page 6]
-
diff --git a/contrib/bind9/doc/rfc/rfc2541.txt b/contrib/bind9/doc/rfc/rfc2541.txt
deleted file mode 100644
index a62ed2b..0000000
--- a/contrib/bind9/doc/rfc/rfc2541.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        D. Eastlake
-Request for Comments: 2541                                           IBM
-Category: Informational                                       March 1999
-
-
-                DNS Security Operational Considerations
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   Secure DNS is based on cryptographic techniques.  A necessary part of
-   the strength of these techniques is careful attention to the
-   operational aspects of key and signature generation, lifetime, size,
-   and storage.  In addition, special attention must be paid to the
-   security of the high level zones, particularly the root zone.  This
-   document discusses these operational aspects for keys and signatures
-   used in connection with the KEY and SIG DNS resource records.
-
-Acknowledgments
-
-   The contributions and suggestions of the following persons (in
-   alphabetic order) are gratefully acknowledged:
-
-         John Gilmore
-         Olafur Gudmundsson
-         Charlie Kaufman
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                     Informational                      [Page 1]
-
-RFC 2541        DNS Security Operational Considerations       March 1999
-
-
-Table of Contents
-
-   Abstract...................................................1
-   Acknowledgments............................................1
-   1. Introduction............................................2
-   2. Public/Private Key Generation...........................2
-   3. Public/Private Key Lifetimes............................2
-   4. Public/Private Key Size Considerations..................3
-   4.1 RSA Key Sizes..........................................3
-   4.2 DSS Key Sizes..........................................4
-   5. Private Key Storage.....................................4
-   6. High Level Zones, The Root Zone, and The Meta-Root Key..5
-   7. Security Considerations.................................5
-   References.................................................6
-   Author's Address...........................................6
-   Full Copyright Statement...................................7
-
-1. Introduction
-
-   This document describes operational considerations for the
-   generation, lifetime, size, and storage of DNS cryptographic keys and
-   signatures for use in the KEY and SIG resource records [RFC 2535].
-   Particular attention is paid to high level zones and the root zone.
-
-2. Public/Private Key Generation
-
-   Careful generation of all keys is a sometimes overlooked but
-   absolutely essential element in any cryptographically secure system.
-   The strongest algorithms used with the longest keys are still of no
-   use if an adversary can guess enough to lower the size of the likely
-   key space so that it can be exhaustively searched.  Technical
-   suggestions for the generation of random keys will be found in [RFC
-   1750].
-
-   Long term keys are particularly sensitive as they will represent a
-   more valuable target and be subject to attack for a longer time than
-   short period keys.  It is strongly recommended that long term key
-   generation occur off-line in a manner isolated from the network via
-   an air gap or, at a minimum, high level secure hardware.
-
-3. Public/Private Key Lifetimes
-
-   No key should be used forever.  The longer a key is in use, the
-   greater the probability that it will have been compromised through
-   carelessness, accident, espionage, or cryptanalysis.  Furthermore, if
-
-
-
-
-
-
-Eastlake                     Informational                      [Page 2]
-
-RFC 2541        DNS Security Operational Considerations       March 1999
-
-
-   key rollover is a rare event, there is an increased risk that, when
-   the time does come to change the key, no one at the site will
-   remember how to do it or operational problems will have developed in
-   the key rollover procedures.
-
-   While public key lifetime is a matter of local policy, these
-   considerations imply that, unless there are extraordinary
-   circumstances, no long term key should have a lifetime significantly
-   over four years.  In fact, a reasonable guideline for long term keys
-   that are kept off-line and carefully guarded is a 13 month lifetime
-   with the intent that they be replaced every year.  A reasonable
-   maximum lifetime for keys that are used for transaction security or
-   the like and are kept on line is 36 days with the intent that they be
-   replaced monthly or more often.  In many cases, a key lifetime of
-   somewhat over a day may be reasonable.
-
-   On the other hand, public keys with too short a lifetime can lead to
-   excessive resource consumption in re-signing data and retrieving
-   fresh information because cached information becomes stale.  In the
-   Internet environment, almost all public keys should have lifetimes no
-   shorter than three minutes, which is a reasonable estimate of maximum
-   packet delay even in unusual circumstances.
-
-4. Public/Private Key Size Considerations
-
-   There are a number of factors that effect public key size choice for
-   use in the DNS security extension.  Unfortunately, these factors
-   usually do not all point in the same direction.  Choice of zone key
-   size should generally be made by the zone administrator depending on
-   their local conditions.
-
-   For most schemes, larger keys are more secure but slower.  In
-   addition, larger keys increase the size of the KEY and SIG RRs.  This
-   increases the chance of DNS UDP packet overflow and the possible
-   necessity for using higher overhead TCP in responses.
-
-4.1 RSA Key Sizes
-
-   Given a small public exponent, verification (the most common
-   operation) for the MD5/RSA algorithm will vary roughly with the
-   square of the modulus length, signing will vary with the cube of the
-   modulus length, and key generation (the least common operation) will
-   vary with the fourth power of the modulus length.  The current best
-   algorithms for factoring a modulus and breaking RSA security vary
-   roughly with the 1.6 power of the modulus itself.  Thus going from a
-   640 bit modulus to a 1280 bit modulus only increases the verification
-   time by a factor of 4 but may increase the work factor of breaking
-   the key by over 2^900.
-
-
-
-Eastlake                     Informational                      [Page 3]
-
-RFC 2541        DNS Security Operational Considerations       March 1999
-
-
-   The recommended minimum RSA algorithm modulus size is 704 bits which
-   is believed by the author to be secure at this time.  But high level
-   zones in the DNS tree may wish to set a higher minimum, perhaps 1000
-   bits, for security reasons.  (Since the United States National
-   Security Agency generally permits export of encryption systems using
-   an RSA modulus of up to 512 bits, use of that small a modulus, i.e.
-   n, must be considered weak.)
-
-   For an RSA key used only to secure data and not to secure other keys,
-   704 bits should be adequate at this time.
-
-4.2 DSS Key Sizes
-
-   DSS keys are probably roughly as strong as an RSA key of the same
-   length but DSS signatures are significantly smaller.
-
-5. Private Key Storage
-
-   It is recommended that, where possible, zone private keys and the
-   zone file master copy be kept and used in off-line, non-network
-   connected, physically secure machines only.  Periodically an
-   application can be run to add authentication to a zone by adding SIG
-   and NXT RRs and adding no-key type KEY RRs for subzones/algorithms
-   where a real KEY RR for the subzone with that algorithm is not
-   provided. Then the augmented file can be transferred, perhaps by
-   sneaker-net, to the networked zone primary server machine.
-
-   The idea is to have a one way information flow to the network to
-   avoid the possibility of tampering from the network.  Keeping the
-   zone master file on-line on the network and simply cycling it through
-   an off-line signer does not do this.  The on-line version could still
-   be tampered with if the host it resides on is compromised.  For
-   maximum security, the master copy of the zone file should be off net
-   and should not be updated based on an unsecured network mediated
-   communication.
-
-   This is not possible if the zone is to be dynamically updated
-   securely [RFC 2137]. At least a private key capable of updating the
-   SOA and NXT chain must be on line in that case.
-
-   Secure resolvers must be configured with some trusted on-line public
-   key information (or a secure path to such a resolver) or they will be
-   unable to authenticate.  Although on line, this public key
-   information must be protected or it could be altered so that spoofed
-   DNS data would appear authentic.
-
-
-
-
-
-
-Eastlake                     Informational                      [Page 4]
-
-RFC 2541        DNS Security Operational Considerations       March 1999
-
-
-   Non-zone private keys, such as host or user keys, generally have to
-   be kept on line to be used for real-time purposes such as DNS
-   transaction security.
-
-6. High Level Zones, The Root Zone, and The Meta-Root Key
-
-   Higher level zones are generally more sensitive than lower level
-   zones.  Anyone controlling or breaking the security of a zone thereby
-   obtains authority over all of its subdomains (except in the case of
-   resolvers that have locally configured the public key of a
-   subdomain).  Therefore, extra care should be taken with high level
-   zones and strong keys used.
-
-   The root zone is the most critical of all zones.  Someone controlling
-   or compromising the security of the root zone would control the
-   entire DNS name space of all resolvers using that root zone (except
-   in the case of resolvers that have locally configured the public key
-   of a subdomain). Therefore, the utmost care must be taken in the
-   securing of the root zone. The strongest and most carefully handled
-   keys should be used.  The root zone private key should always be kept
-   off line.
-
-   Many resolvers will start at a root server for their access to and
-   authentication of DNS data.  Securely updating an enormous population
-   of resolvers around the world will be extremely difficult.  Yet the
-   guidelines in section 3 above would imply that the root zone private
-   key be changed annually or more often and if it were staticly
-   configured at all these resolvers, it would have to be updated when
-   changed.
-
-   To permit relatively frequent change to the root zone key yet
-   minimize exposure of the ultimate key of the DNS tree, there will be
-   a "meta-root" key used very rarely and then only to sign a sequence
-   of regular root key RRsets with overlapping time validity periods
-   that are to be rolled out. The root zone contains the meta-root and
-   current regular root KEY RR(s) signed by SIG RRs under both the
-   meta-root and other root private key(s) themselves.
-
-   The utmost security in the storage and use of the meta-root key is
-   essential.  The exact techniques are precautions to be used are
-   beyond the scope of this document.  Because of its special position,
-   it may be best to continue with the same meta-root key for an
-   extended period of time such as ten to fifteen years.
-
-7. Security Considerations
-
-   The entirety of this document is concerned with operational
-   considerations of public/private key pair DNS Security.
-
-
-
-Eastlake                     Informational                      [Page 5]
-
-RFC 2541        DNS Security Operational Considerations       March 1999
-
-
-References
-
-   [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
-                Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC 1035]   Mockapetris, P., "Domain Names - Implementation and
-                Specifications", STD 13, RFC 1035, November 1987.
-
-   [RFC 1750]   Eastlake, D., Crocker, S. and J. Schiller, "Randomness
-                Requirements for Security", RFC 1750, December 1994.
-
-   [RFC 2065]   Eastlake, D. and C. Kaufman, "Domain Name System
-                Security Extensions", RFC 2065, January 1997.
-
-   [RFC 2137]   Eastlake, D., "Secure Domain Name System Dynamic
-                Update", RFC 2137, April 1997.
-
-   [RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",
-                RFC 2535, March 1999.
-
-   [RSA FAQ]    RSADSI Frequently Asked Questions periodic posting.
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   IBM
-   65 Shindegan Hill Road, RR #1
-   Carmel, NY 10512
-
-   Phone:   +1-914-276-2668(h)
-            +1-914-784-7913(w)
-   Fax:     +1-914-784-3833(w)
-   EMail:   dee3@us.ibm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                     Informational                      [Page 6]
-
-RFC 2541        DNS Security Operational Considerations       March 1999
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                     Informational                      [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc2553.txt b/contrib/bind9/doc/rfc/rfc2553.txt
deleted file mode 100644
index 6989bf3..0000000
--- a/contrib/bind9/doc/rfc/rfc2553.txt
+++ /dev/null
@@ -1,2299 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        R. Gilligan
-Request for Comments: 2553                                      FreeGate
-Obsoletes: 2133                                               S. Thomson
-Category: Informational                                         Bellcore
-                                                                J. Bound
-                                                                  Compaq
-                                                              W. Stevens
-                                                              Consultant
-                                                              March 1999
-
-
-               Basic Socket Interface Extensions for IPv6
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   The de facto standard application program interface (API) for TCP/IP
-   applications is the "sockets" interface.  Although this API was
-   developed for Unix in the early 1980s it has also been implemented on
-   a wide variety of non-Unix systems.  TCP/IP applications written
-   using the sockets API have in the past enjoyed a high degree of
-   portability and we would like the same portability with IPv6
-   applications.  But changes are required to the sockets API to support
-   IPv6 and this memo describes these changes.  These include a new
-   socket address structure to carry IPv6 addresses, new address
-   conversion functions, and some new socket options.  These extensions
-   are designed to provide access to the basic IPv6 features required by
-   TCP and UDP applications, including multicasting, while introducing a
-   minimum of change into the system and providing complete
-   compatibility for existing IPv4 applications.  Additional extensions
-   for advanced IPv6 features (raw sockets and access to the IPv6
-   extension headers) are defined in another document [4].
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 1]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-Table of Contents
-
-   1. Introduction.................................................3
-   2. Design Considerations........................................3
-   2.1 What Needs to be Changed....................................4
-   2.2 Data Types..................................................5
-   2.3 Headers.....................................................5
-   2.4 Structures..................................................5
-   3. Socket Interface.............................................6
-   3.1 IPv6 Address Family and Protocol Family.....................6
-   3.2 IPv6 Address Structure......................................6
-   3.3 Socket Address Structure for 4.3BSD-Based Systems...........7
-   3.4 Socket Address Structure for 4.4BSD-Based Systems...........8
-   3.5 The Socket Functions........................................9
-   3.6 Compatibility with IPv4 Applications.......................10
-   3.7 Compatibility with IPv4 Nodes..............................10
-   3.8 IPv6 Wildcard Address......................................11
-   3.9 IPv6 Loopback Address......................................12
-   3.10 Portability Additions.....................................13
-   4. Interface Identification....................................16
-   4.1 Name-to-Index..............................................16
-   4.2 Index-to-Name..............................................17
-   4.3 Return All Interface Names and Indexes.....................17
-   4.4 Free Memory................................................18
-   5. Socket Options..............................................18
-   5.1 Unicast Hop Limit..........................................18
-   5.2 Sending and Receiving Multicast Packets....................19
-   6. Library Functions...........................................21
-   6.1 Nodename-to-Address Translation............................21
-   6.2 Address-To-Nodename Translation............................24
-   6.3 Freeing memory for getipnodebyname and getipnodebyaddr.....26
-   6.4 Protocol-Independent Nodename and Service Name Translation.26
-   6.5 Socket Address Structure to Nodename and Service Name......29
-   6.6 Address Conversion Functions...............................31
-   6.7 Address Testing Macros.....................................32
-   7. Summary of New Definitions..................................33
-   8. Security Considerations.....................................35
-   9. Year 2000 Considerations....................................35
-   Changes From RFC 2133..........................................35
-   Acknowledgments................................................38
-   References.....................................................39
-   Authors' Addresses.............................................40
-   Full Copyright Statement.......................................41
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 2]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-1. Introduction
-
-   While IPv4 addresses are 32 bits long, IPv6 interfaces are identified
-   by 128-bit addresses.  The socket interface makes the size of an IP
-   address quite visible to an application; virtually all TCP/IP
-   applications for BSD-based systems have knowledge of the size of an
-   IP address.  Those parts of the API that expose the addresses must be
-   changed to accommodate the larger IPv6 address size.  IPv6 also
-   introduces new features (e.g., traffic class and flowlabel), some of
-   which must be made visible to applications via the API.  This memo
-   defines a set of extensions to the socket interface to support the
-   larger address size and new features of IPv6.
-
-2. Design Considerations
-
-   There are a number of important considerations in designing changes
-   to this well-worn API:
-
-      - The API changes should provide both source and binary
-        compatibility for programs written to the original API.  That
-        is, existing program binaries should continue to operate when
-        run on a system supporting the new API.  In addition, existing
-        applications that are re-compiled and run on a system supporting
-        the new API should continue to operate.  Simply put, the API
-        changes for IPv6 should not break existing programs.  An
-        additonal mechanism for implementations to verify this is to
-        verify the new symbols are protected by Feature Test Macros as
-        described in IEEE Std 1003.1.  (Such Feature Test Macros are not
-        defined by this RFC.)
-
-      - The changes to the API should be as small as possible in order
-        to simplify the task of converting existing IPv4 applications to
-        IPv6.
-
-      - Where possible, applications should be able to use this API to
-        interoperate with both IPv6 and IPv4 hosts.  Applications should
-        not need to know which type of host they are communicating with.
-
-      - IPv6 addresses carried in data structures should be 64-bit
-        aligned.  This is necessary in order to obtain optimum
-        performance on 64-bit machine architectures.
-
-   Because of the importance of providing IPv4 compatibility in the API,
-   these extensions are explicitly designed to operate on machines that
-   provide complete support for both IPv4 and IPv6.  A subset of this
-   API could probably be designed for operation on systems that support
-   only IPv6.  However, this is not addressed in this memo.
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 3]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-2.1 What Needs to be Changed
-
-   The socket interface API consists of a few distinct components:
-
-      -  Core socket functions.
-
-      -  Address data structures.
-
-      -  Name-to-address translation functions.
-
-      -  Address conversion functions.
-
-   The core socket functions -- those functions that deal with such
-   things as setting up and tearing down TCP connections, and sending
-   and receiving UDP packets -- were designed to be transport
-   independent.  Where protocol addresses are passed as function
-   arguments, they are carried via opaque pointers.  A protocol-specific
-   address data structure is defined for each protocol that the socket
-   functions support.  Applications must cast pointers to these
-   protocol-specific address structures into pointers to the generic
-   "sockaddr" address structure when using the socket functions.  These
-   functions need not change for IPv6, but a new IPv6-specific address
-   data structure is needed.
-
-   The "sockaddr_in" structure is the protocol-specific data structure
-   for IPv4.  This data structure actually includes 8-octets of unused
-   space, and it is tempting to try to use this space to adapt the
-   sockaddr_in structure to IPv6.  Unfortunately, the sockaddr_in
-   structure is not large enough to hold the 16-octet IPv6 address as
-   well as the other information (address family and port number) that
-   is needed.  So a new address data structure must be defined for IPv6.
-
-   IPv6 addresses are scoped [2] so they could be link-local, site,
-   organization, global, or other scopes at this time undefined.  To
-   support applications that want to be able to identify a set of
-   interfaces for a specific scope, the IPv6 sockaddr_in structure must
-   support a field that can be used by an implementation to identify a
-   set of interfaces identifying the scope for an IPv6 address.
-
-   The name-to-address translation functions in the socket interface are
-   gethostbyname() and gethostbyaddr().  These are left as is and new
-   functions are defined to support IPv4 and IPv6.  Additionally, the
-   POSIX 1003.g draft [3] specifies a new nodename-to-address
-   translation function which is protocol independent.  This function
-   can also be used with IPv4 and IPv6.
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 4]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   The address conversion functions -- inet_ntoa() and inet_addr() --
-   convert IPv4 addresses between binary and printable form.  These
-   functions are quite specific to 32-bit IPv4 addresses.  We have
-   designed two analogous functions that convert both IPv4 and IPv6
-   addresses, and carry an address type parameter so that they can be
-   extended to other protocol families as well.
-
-   Finally, a few miscellaneous features are needed to support IPv6.
-   New interfaces are needed to support the IPv6 traffic class, flow
-   label, and hop limit header fields.  New socket options are needed to
-   control the sending and receiving of IPv6 multicast packets.
-
-   The socket interface will be enhanced in the future to provide access
-   to other IPv6 features.  These extensions are described in [4].
-
-2.2 Data Types
-
-   The data types of the structure elements given in this memo are
-   intended to be examples, not absolute requirements.  Whenever
-   possible, data types from Draft 6.6 (March 1997) of POSIX 1003.1g are
-   used: uintN_t means an unsigned integer of exactly N bits (e.g.,
-   uint16_t).  We also assume the argument data types from 1003.1g when
-   possible (e.g., the final argument to setsockopt() is a size_t
-   value).  Whenever buffer sizes are specified, the POSIX 1003.1 size_t
-   data type is used (e.g., the two length arguments to getnameinfo()).
-
-2.3 Headers
-
-   When function prototypes and structures are shown we show the headers
-   that must be #included to cause that item to be defined.
-
-2.4 Structures
-
-   When structures are described the members shown are the ones that
-   must appear in an implementation.  Additional, nonstandard members
-   may also be defined by an implementation.  As an additional
-   precaution nonstandard members could be verified by Feature Test
-   Macros as described in IEEE Std 1003.1.  (Such Feature Test Macros
-   are not defined by this RFC.)
-
-   The ordering shown for the members of a structure is the recommended
-   ordering, given alignment considerations of multibyte members, but an
-   implementation may order the members differently.
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 5]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-3. Socket Interface
-
-   This section specifies the socket interface changes for IPv6.
-
-3.1 IPv6 Address Family and Protocol Family
-
-   A new address family name, AF_INET6, is defined in <sys/socket.h>.
-   The AF_INET6 definition distinguishes between the original
-   sockaddr_in address data structure, and the new sockaddr_in6 data
-   structure.
-
-   A new protocol family name, PF_INET6, is defined in <sys/socket.h>.
-   Like most of the other protocol family names, this will usually be
-   defined to have the same value as the corresponding address family
-   name:
-
-      #define PF_INET6        AF_INET6
-
-   The PF_INET6 is used in the first argument to the socket() function
-   to indicate that an IPv6 socket is being created.
-
-3.2 IPv6 Address Structure
-
-   A new in6_addr structure holds a single IPv6 address and is defined
-   as a result of including <netinet/in.h>:
-
-      struct in6_addr {
-          uint8_t  s6_addr[16];      /* IPv6 address */
-      };
-
-   This data structure contains an array of sixteen 8-bit elements,
-   which make up one 128-bit IPv6 address.  The IPv6 address is stored
-   in network byte order.
-
-   The structure in6_addr above is usually implemented with an embedded
-   union with extra fields that force the desired alignment level in a
-   manner similar to BSD implementations of "struct in_addr". Those
-   additional implementation details are omitted here for simplicity.
-
-   An example is as follows:
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 6]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   struct in6_addr {
-        union {
-            uint8_t  _S6_u8[16];
-            uint32_t _S6_u32[4];
-            uint64_t _S6_u64[2];
-        } _S6_un;
-   };
-   #define s6_addr _S6_un._S6_u8
-
-3.3 Socket Address Structure for 4.3BSD-Based Systems
-
-   In the socket interface, a different protocol-specific data structure
-   is defined to carry the addresses for each protocol suite.  Each
-   protocol- specific data structure is designed so it can be cast into a
-   protocol- independent data structure -- the "sockaddr" structure.
-   Each has a "family" field that overlays the "sa_family" of the
-   sockaddr data structure.  This field identifies the type of the data
-   structure.
-
-   The sockaddr_in structure is the protocol-specific address data
-   structure for IPv4.  It is used to pass addresses between applications
-   and the system in the socket functions.  The following sockaddr_in6
-   structure holds IPv6 addresses and is defined as a result of including
-   the <netinet/in.h> header:
-
-struct sockaddr_in6 {
-    sa_family_t     sin6_family;    /* AF_INET6 */
-    in_port_t       sin6_port;      /* transport layer port # */
-    uint32_t        sin6_flowinfo;  /* IPv6 traffic class & flow info */
-    struct in6_addr sin6_addr;      /* IPv6 address */
-    uint32_t        sin6_scope_id;  /* set of interfaces for a scope */
-};
-
-   This structure is designed to be compatible with the sockaddr data
-   structure used in the 4.3BSD release.
-
-   The sin6_family field identifies this as a sockaddr_in6 structure.
-   This field overlays the sa_family field when the buffer is cast to a
-   sockaddr data structure.  The value of this field must be AF_INET6.
-
-   The sin6_port field contains the 16-bit UDP or TCP port number.  This
-   field is used in the same way as the sin_port field of the
-   sockaddr_in structure.  The port number is stored in network byte
-   order.
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 7]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   The sin6_flowinfo field is a 32-bit field that contains two pieces of
-   information: the traffic class and the flow label.  The contents and
-   interpretation of this member is specified in [1].  The sin6_flowinfo
-   field SHOULD be set to zero by an implementation prior to using the
-   sockaddr_in6 structure by an application on receive operations.
-
-   The sin6_addr field is a single in6_addr structure (defined in the
-   previous section).  This field holds one 128-bit IPv6 address.  The
-   address is stored in network byte order.
-
-   The ordering of elements in this structure is specifically designed
-   so that when sin6_addr field is aligned on a 64-bit boundary, the
-   start of the structure will also be aligned on a 64-bit boundary.
-   This is done for optimum performance on 64-bit architectures.
-
-   The sin6_scope_id field is a 32-bit integer that identifies a set of
-   interfaces as appropriate for the scope of the address carried in the
-   sin6_addr field.  For a link scope sin6_addr sin6_scope_id would be
-   an interface index.  For a site scope sin6_addr, sin6_scope_id would
-   be a site identifier.  The mapping of sin6_scope_id to an interface
-   or set of interfaces is left to implementation and future
-   specifications on the subject of site identifiers.
-
-   Notice that the sockaddr_in6 structure will normally be larger than
-   the generic sockaddr structure.  On many existing implementations the
-   sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both
-   being 16 bytes.  Any existing code that makes this assumption needs
-   to be examined carefully when converting to IPv6.
-
-3.4 Socket Address Structure for 4.4BSD-Based Systems
-
-   The 4.4BSD release includes a small, but incompatible change to the
-   socket interface.  The "sa_family" field of the sockaddr data
-   structure was changed from a 16-bit value to an 8-bit value, and the
-   space saved used to hold a length field, named "sa_len".  The
-   sockaddr_in6 data structure given in the previous section cannot be
-   correctly cast into the newer sockaddr data structure.  For this
-   reason, the following alternative IPv6 address data structure is
-   provided to be used on systems based on 4.4BSD.  It is defined as a
-   result of including the <netinet/in.h> header.
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 8]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-struct sockaddr_in6 {
-    uint8_t         sin6_len;       /* length of this struct */
-    sa_family_t     sin6_family;    /* AF_INET6 */
-    in_port_t       sin6_port;      /* transport layer port # */
-    uint32_t        sin6_flowinfo;  /* IPv6 flow information */
-    struct in6_addr sin6_addr;      /* IPv6 address */
-    uint32_t        sin6_scope_id;  /* set of interfaces for a scope */
-};
-
-   The only differences between this data structure and the 4.3BSD
-   variant are the inclusion of the length field, and the change of the
-   family field to a 8-bit data type.  The definitions of all the other
-   fields are identical to the structure defined in the previous
-   section.
-
-   Systems that provide this version of the sockaddr_in6 data structure
-   must also declare SIN6_LEN as a result of including the
-   <netinet/in.h> header.  This macro allows applications to determine
-   whether they are being built on a system that supports the 4.3BSD or
-   4.4BSD variants of the data structure.
-
-3.5 The Socket Functions
-
-   Applications call the socket() function to create a socket descriptor
-   that represents a communication endpoint.  The arguments to the
-   socket() function tell the system which protocol to use, and what
-   format address structure will be used in subsequent functions.  For
-   example, to create an IPv4/TCP socket, applications make the call:
-
-      s = socket(PF_INET, SOCK_STREAM, 0);
-
-   To create an IPv4/UDP socket, applications make the call:
-
-      s = socket(PF_INET, SOCK_DGRAM, 0);
-
-   Applications may create IPv6/TCP and IPv6/UDP sockets by simply using
-   the constant PF_INET6 instead of PF_INET in the first argument.  For
-   example, to create an IPv6/TCP socket, applications make the call:
-
-      s = socket(PF_INET6, SOCK_STREAM, 0);
-
-   To create an IPv6/UDP socket, applications make the call:
-
-      s = socket(PF_INET6, SOCK_DGRAM, 0);
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                      [Page 9]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   Once the application has created a PF_INET6 socket, it must use the
-   sockaddr_in6 address structure when passing addresses in to the
-   system.  The functions that the application uses to pass addresses
-   into the system are:
-
-      bind()
-      connect()
-      sendmsg()
-      sendto()
-
-   The system will use the sockaddr_in6 address structure to return
-   addresses to applications that are using PF_INET6 sockets.  The
-   functions that return an address from the system to an application
-   are:
-
-      accept()
-      recvfrom()
-      recvmsg()
-      getpeername()
-      getsockname()
-
-   No changes to the syntax of the socket functions are needed to
-   support IPv6, since all of the "address carrying" functions use an
-   opaque address pointer, and carry an address length as a function
-   argument.
-
-3.6 Compatibility with IPv4 Applications
-
-   In order to support the large base of applications using the original
-   API, system implementations must provide complete source and binary
-   compatibility with the original API.  This means that systems must
-   continue to support PF_INET sockets and the sockaddr_in address
-   structure.  Applications must be able to create IPv4/TCP and IPv4/UDP
-   sockets using the PF_INET constant in the socket() function, as
-   described in the previous section.  Applications should be able to
-   hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP
-   sockets simultaneously within the same process.
-
-   Applications using the original API should continue to operate as
-   they did on systems supporting only IPv4.  That is, they should
-   continue to interoperate with IPv4 nodes.
-
-3.7 Compatibility with IPv4 Nodes
-
-   The API also provides a different type of compatibility: the ability
-   for IPv6 applications to interoperate with IPv4 applications.  This
-   feature uses the IPv4-mapped IPv6 address format defined in the IPv6
-   addressing architecture specification [2].  This address format
-
-
-
-Gilligan, et. al.            Informational                     [Page 10]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   allows the IPv4 address of an IPv4 node to be represented as an IPv6
-   address.  The IPv4 address is encoded into the low-order 32 bits of
-   the IPv6 address, and the high-order 96 bits hold the fixed prefix
-   0:0:0:0:0:FFFF.  IPv4- mapped addresses are written as follows:
-
-      ::FFFF:<IPv4-address>
-
-   These addresses can be generated automatically by the
-   getipnodebyname() function when the specified host has only IPv4
-   addresses (as described in Section 6.1).
-
-   Applications may use PF_INET6 sockets to open TCP connections to IPv4
-   nodes, or send UDP packets to IPv4 nodes, by simply encoding the
-   destination's IPv4 address as an IPv4-mapped IPv6 address, and
-   passing that address, within a sockaddr_in6 structure, in the
-   connect() or sendto() call.  When applications use PF_INET6 sockets
-   to accept TCP connections from IPv4 nodes, or receive UDP packets
-   from IPv4 nodes, the system returns the peer's address to the
-   application in the accept(), recvfrom(), or getpeername() call using
-   a sockaddr_in6 structure encoded this way.
-
-   Few applications will likely need to know which type of node they are
-   interoperating with.  However, for those applications that do need to
-   know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.7, is
-   provided.
-
-3.8 IPv6 Wildcard Address
-
-   While the bind() function allows applications to select the source IP
-   address of UDP packets and TCP connections, applications often want
-   the system to select the source address for them.  With IPv4, one
-   specifies the address as the symbolic constant INADDR_ANY (called the
-   "wildcard" address) in the bind() call, or simply omits the bind()
-   entirely.
-
-   Since the IPv6 address type is a structure (struct in6_addr), a
-   symbolic constant can be used to initialize an IPv6 address variable,
-   but cannot be used in an assignment.  Therefore systems provide the
-   IPv6 wildcard address in two forms.
-
-   The first version is a global variable named "in6addr_any" that is an
-   in6_addr structure.  The extern declaration for this variable is
-   defined in <netinet/in.h>:
-
-      extern const struct in6_addr in6addr_any;
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 11]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   Applications use in6addr_any similarly to the way they use INADDR_ANY
-   in IPv4.  For example, to bind a socket to port number 23, but let
-   the system select the source address, an application could use the
-   following code:
-
-      struct sockaddr_in6 sin6;
-       . . .
-      sin6.sin6_family = AF_INET6;
-      sin6.sin6_flowinfo = 0;
-      sin6.sin6_port = htons(23);
-      sin6.sin6_addr = in6addr_any;  /* structure assignment */
-       . . .
-      if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
-              . . .
-
-   The other version is a symbolic constant named IN6ADDR_ANY_INIT and
-   is defined in <netinet/in.h>.  This constant can be used to
-   initialize an in6_addr structure:
-
-      struct in6_addr anyaddr = IN6ADDR_ANY_INIT;
-
-   Note that this constant can be used ONLY at declaration time.  It can
-   not be used to assign a previously declared in6_addr structure.  For
-   example, the following code will not work:
-
-      /* This is the WRONG way to assign an unspecified address */
-      struct sockaddr_in6 sin6;
-       . . .
-      sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */
-
-   Be aware that the IPv4 INADDR_xxx constants are all defined in host
-   byte order but the IPv6 IN6ADDR_xxx constants and the IPv6
-   in6addr_xxx externals are defined in network byte order.
-
-3.9 IPv6 Loopback Address
-
-   Applications may need to send UDP packets to, or originate TCP
-   connections to, services residing on the local node.  In IPv4, they
-   can do this by using the constant IPv4 address INADDR_LOOPBACK in
-   their connect(), sendto(), or sendmsg() call.
-
-   IPv6 also provides a loopback address to contact local TCP and UDP
-   services.  Like the unspecified address, the IPv6 loopback address is
-   provided in two forms -- a global variable and a symbolic constant.
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 12]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   The global variable is an in6_addr structure named
-   "in6addr_loopback."  The extern declaration for this variable is
-   defined in <netinet/in.h>:
-
-      extern const struct in6_addr in6addr_loopback;
-
-   Applications use in6addr_loopback as they would use INADDR_LOOPBACK
-   in IPv4 applications (but beware of the byte ordering difference
-   mentioned at the end of the previous section).  For example, to open
-   a TCP connection to the local telnet server, an application could use
-   the following code:
-
-      struct sockaddr_in6 sin6;
-       . . .
-      sin6.sin6_family = AF_INET6;
-      sin6.sin6_flowinfo = 0;
-      sin6.sin6_port = htons(23);
-      sin6.sin6_addr = in6addr_loopback;  /* structure assignment */
-       . . .
-      if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
-              . . .
-
-   The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined
-   in <netinet/in.h>.  It can be used at declaration time ONLY; for
-   example:
-
-      struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT;
-
-   Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment
-   to a previously declared IPv6 address variable.
-
-3.10 Portability Additions
-
-   One simple addition to the sockets API that can help application
-   writers is the "struct sockaddr_storage". This data structure can
-   simplify writing code portable across multiple address families and
-   platforms.  This data structure is designed with the following goals.
-
-      - It has a large enough implementation specific maximum size to
-        store the desired set of protocol specific socket address data
-        structures. Specifically, it is at least large enough to
-        accommodate sockaddr_in and sockaddr_in6 and possibly other
-        protocol specific socket addresses too.
-      - It is aligned at an appropriate boundary so protocol specific
-        socket address data structure pointers can be cast to it and
-        access their fields without alignment problems. (e.g. pointers
-        to sockaddr_in6 and/or sockaddr_in can be cast to it and access
-        fields without alignment problems).
-
-
-
-Gilligan, et. al.            Informational                     [Page 13]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-      - It has the initial field(s) isomorphic to the fields of the
-        "struct sockaddr" data structure on that implementation which
-        can be used as a discriminants for deriving the protocol in use.
-        These initial field(s) would on most implementations either be a
-        single field of type "sa_family_t" (isomorphic to sa_family
-        field, 16 bits) or two fields of type uint8_t and sa_family_t
-        respectively, (isomorphic to sa_len and sa_family_t, 8 bits
-        each).
-
-   An example implementation design of such a data structure would be as
-   follows.
-
-/*
- * Desired design of maximum size and alignment
- */
-#define _SS_MAXSIZE    128  /* Implementation specific max size */
-#define _SS_ALIGNSIZE  (sizeof (int64_t))
-                         /* Implementation specific desired alignment */
-/*
- * Definitions used for sockaddr_storage structure paddings design.
- */
-#define _SS_PAD1SIZE   (_SS_ALIGNSIZE - sizeof (sa_family_t))
-#define _SS_PAD2SIZE   (_SS_MAXSIZE - (sizeof (sa_family_t)+
-                              _SS_PAD1SIZE + _SS_ALIGNSIZE))
-struct sockaddr_storage {
-    sa_family_t  __ss_family;     /* address family */
-    /* Following fields are implementation specific */
-    char      __ss_pad1[_SS_PAD1SIZE];
-              /* 6 byte pad, this is to make implementation
-              /* specific pad up to alignment field that */
-              /* follows explicit in the data structure */
-    int64_t   __ss_align;     /* field to force desired structure */
-               /* storage alignment */
-    char      __ss_pad2[_SS_PAD2SIZE];
-              /* 112 byte pad to achieve desired size, */
-              /* _SS_MAXSIZE value minus size of ss_family */
-              /* __ss_pad1, __ss_align fields is 112 */
-};
-
-   On implementations where sockaddr data structure includes a "sa_len",
-   field this data structure would look like this:
-
-/*
- * Definitions used for sockaddr_storage structure paddings design.
- */
-#define _SS_PAD1SIZE (_SS_ALIGNSIZE -
-                            (sizeof (uint8_t) + sizeof (sa_family_t))
-#define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t)+
-
-
-
-Gilligan, et. al.            Informational                     [Page 14]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-                              _SS_PAD1SIZE + _SS_ALIGNSIZE))
-struct sockaddr_storage {
-    uint8_t      __ss_len;        /* address length */
-    sa_family_t  __ss_family;     /* address family */
-    /* Following fields are implementation specific */
-    char         __ss_pad1[_SS_PAD1SIZE];
-                  /* 6 byte pad, this is to make implementation
-                  /* specific pad up to alignment field that */
-                  /* follows explicit in the data structure */
-    int64_t      __ss_align;  /* field to force desired structure */
-                  /* storage alignment */
-    char         __ss_pad2[_SS_PAD2SIZE];
-                  /* 112 byte pad to achieve desired size, */
-                  /* _SS_MAXSIZE value minus size of ss_len, */
-                  /* __ss_family, __ss_pad1, __ss_align fields is 112 */
-};
-
-   The above example implementation illustrates a data structure which
-   will align on a 64 bit boundary. An implementation specific field
-   "__ss_align" along "__ss_pad1" is used to force a 64-bit alignment
-   which covers proper alignment good enough for needs of sockaddr_in6
-   (IPv6), sockaddr_in (IPv4) address data structures.  The size of
-   padding fields __ss_pad1 depends on the chosen alignment boundary.
-   The size of padding field __ss_pad2 depends on the value of overall
-   size chosen for the total size of the structure. This size and
-   alignment are represented in the above example by implementation
-   specific (not required) constants _SS_MAXSIZE (chosen value 128) and
-   _SS_ALIGNMENT (with chosen value 8).  Constants _SS_PAD1SIZE (derived
-   value 6) and _SS_PAD2SIZE (derived value 112) are also for
-   illustration and not required.  The implementation specific
-   definitions and structure field names above start with an underscore
-   to denote implementation private namespace.  Portable code is not
-   expected to access or reference those fields or constants.
-
-   The sockaddr_storage structure solves the problem of declaring
-   storage for automatic variables which is large enough and aligned
-   enough for storing socket address data structure of any family. For
-   example, code with a file descriptor and without the context of the
-   address family can pass a pointer to a variable of this type where a
-   pointer to a socket address structure is expected in calls such as
-   getpeername() and determine the address family by accessing the
-   received content after the call.
-
-   The sockaddr_storage structure may also be useful and applied to
-   certain other interfaces where a generic socket address large enough
-   and aligned for use with multiple address families may be needed. A
-   discussion of those interfaces is outside the scope of this document.
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 15]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   Also, much existing code assumes that any socket address structure
-   can fit in a generic sockaddr structure.  While this has been true
-   for IPv4 socket address structures, it has always been false for Unix
-   domain socket address structures (but in practice this has not been a
-   problem) and it is also false for IPv6 socket address structures
-   (which can be a problem).
-
-   So now an application can do the following:
-
-      struct sockaddr_storage __ss;
-      struct sockaddr_in6 *sin6;
-      sin6 = (struct sockaddr_in6 *) &__ss;
-
-4. Interface Identification
-
-   This API uses an interface index (a small positive integer) to
-   identify the local interface on which a multicast group is joined
-   (Section 5.3).  Additionally, the advanced API [4] uses these same
-   interface indexes to identify the interface on which a datagram is
-   received, or to specify the interface on which a datagram is to be
-   sent.
-
-   Interfaces are normally known by names such as "le0", "sl1", "ppp2",
-   and the like.  On Berkeley-derived implementations, when an interface
-   is made known to the system, the kernel assigns a unique positive
-   integer value (called the interface index) to that interface.  These
-   are small positive integers that start at 1.  (Note that 0 is never
-   used for an interface index.) There may be gaps so that there is no
-   current interface for a particular positive interface index.
-
-   This API defines two functions that map between an interface name and
-   index, a third function that returns all the interface names and
-   indexes, and a fourth function to return the dynamic memory allocated
-   by the previous function.  How these functions are implemented is
-   left up to the implementation.  4.4BSD implementations can implement
-   these functions using the existing sysctl() function with the
-   NET_RT_IFLIST command.  Other implementations may wish to use ioctl()
-   for this purpose.
-
-4.1 Name-to-Index
-
-   The first function maps an interface name into its corresponding
-   index.
-
-      #include <net/if.h>
-
-      unsigned int  if_nametoindex(const char *ifname);
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 16]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   If the specified interface name does not exist, the return value is
-   0, and errno is set to ENXIO.  If there was a system error (such as
-   running out of memory), the return value is 0 and errno is set to the
-   proper value (e.g., ENOMEM).
-
-4.2 Index-to-Name
-
-   The second function maps an interface index into its corresponding
-   name.
-
-      #include <net/if.h>
-
-      char  *if_indextoname(unsigned int ifindex, char *ifname);
-
-   The ifname argument must point to a buffer of at least IF_NAMESIZE
-   bytes into which the interface name corresponding to the specified
-   index is returned.  (IF_NAMESIZE is also defined in <net/if.h> and
-   its value includes a terminating null byte at the end of the
-   interface name.) This pointer is also the return value of the
-   function.  If there is no interface corresponding to the specified
-   index, NULL is returned, and errno is set to ENXIO, if there was a
-   system error (such as running out of memory), if_indextoname returns
-   NULL and errno would be set to the proper value (e.g., ENOMEM).
-
-4.3 Return All Interface Names and Indexes
-
-   The if_nameindex structure holds the information about a single
-   interface and is defined as a result of including the <net/if.h>
-   header.
-
-      struct if_nameindex {
-        unsigned int   if_index;  /* 1, 2, ... */
-        char          *if_name;   /* null terminated name: "le0", ... */
-      };
-
-   The final function returns an array of if_nameindex structures, one
-   structure per interface.
-
-      struct if_nameindex  *if_nameindex(void);
-
-   The end of the array of structures is indicated by a structure with
-   an if_index of 0 and an if_name of NULL.  The function returns a NULL
-   pointer upon an error, and would set errno to the appropriate value.
-
-   The memory used for this array of structures along with the interface
-   names pointed to by the if_name members is obtained dynamically.
-   This memory is freed by the next function.
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 17]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-4.4 Free Memory
-
-   The following function frees the dynamic memory that was allocated by
-   if_nameindex().
-
-      #include <net/if.h>
-
-      void  if_freenameindex(struct if_nameindex *ptr);
-
-   The argument to this function must be a pointer that was returned by
-   if_nameindex().
-
-   Currently net/if.h doesn't have prototype definitions for functions
-   and it is recommended that these definitions be defined in net/if.h
-   as well and the struct if_nameindex{}.
-
-5. Socket Options
-
-   A number of new socket options are defined for IPv6.  All of these
-   new options are at the IPPROTO_IPV6 level.  That is, the "level"
-   parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6
-   when using these options.  The constant name prefix IPV6_ is used in
-   all of the new socket options.  This serves to clearly identify these
-   options as applying to IPv6.
-
-   The declaration for IPPROTO_IPV6, the new IPv6 socket options, and
-   related constants defined in this section are obtained by including
-   the header <netinet/in.h>.
-
-5.1 Unicast Hop Limit
-
-   A new setsockopt() option controls the hop limit used in outgoing
-   unicast IPv6 packets.  The name of this option is IPV6_UNICAST_HOPS,
-   and it is used at the IPPROTO_IPV6 layer.  The following example
-   illustrates how it is used:
-
-      int  hoplimit = 10;
-
-      if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
-                     (char *) &hoplimit, sizeof(hoplimit)) == -1)
-          perror("setsockopt IPV6_UNICAST_HOPS");
-
-   When the IPV6_UNICAST_HOPS option is set with setsockopt(), the
-   option value given is used as the hop limit for all subsequent
-   unicast packets sent via that socket.  If the option is not set, the
-   system selects a default value.  The integer hop limit value (called
-   x) is interpreted as follows:
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 18]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-      x < -1:        return an error of EINVAL
-      x == -1:       use kernel default
-      0 <= x <= 255: use x
-      x >= 256:      return an error of EINVAL
-
-   The IPV6_UNICAST_HOPS option may be used with getsockopt() to
-   determine the hop limit value that the system will use for subsequent
-   unicast packets sent via that socket.  For example:
-
-      int  hoplimit;
-      size_t  len = sizeof(hoplimit);
-
-      if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
-                     (char *) &hoplimit, &len) == -1)
-          perror("getsockopt IPV6_UNICAST_HOPS");
-      else
-          printf("Using %d for hop limit.\n", hoplimit);
-
-5.2 Sending and Receiving Multicast Packets
-
-   IPv6 applications may send UDP multicast packets by simply specifying
-   an IPv6 multicast address in the address argument of the sendto()
-   function.
-
-   Three socket options at the IPPROTO_IPV6 layer control some of the
-   parameters for sending multicast packets.  Setting these options is
-   not required: applications may send multicast packets without using
-   these options.  The setsockopt() options for controlling the sending
-   of multicast packets are summarized below.  These three options can
-   also be used with getsockopt().
-
-      IPV6_MULTICAST_IF
-
-         Set the interface to use for outgoing multicast packets.  The
-         argument is the index of the interface to use.
-
-         Argument type: unsigned int
-
-      IPV6_MULTICAST_HOPS
-
-         Set the hop limit to use for outgoing multicast packets.  (Note
-         a separate option - IPV6_UNICAST_HOPS - is provided to set the
-         hop limit to use for outgoing unicast packets.)
-
-         The interpretation of the argument is the same as for the
-         IPV6_UNICAST_HOPS option:
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 19]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-           x < -1:        return an error of EINVAL
-           x == -1:       use kernel default
-           0 <= x <= 255: use x
-           x >= 256:      return an error of EINVAL
-
-           If IPV6_MULTICAST_HOPS is not set, the default is 1
-           (same as IPv4 today)
-
-         Argument type: int
-
-      IPV6_MULTICAST_LOOP
-
-         If a multicast datagram is sent to a group to which the sending
-         host itself belongs (on the outgoing interface), a copy of the
-         datagram is looped back by the IP layer for local delivery if
-         this option is set to 1.  If this option is set to 0 a copy
-         is not looped back.  Other option values return an error of
-         EINVAL.
-
-         If IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback;
-         same as IPv4 today).
-
-         Argument type: unsigned int
-
-   The reception of multicast packets is controlled by the two
-   setsockopt() options summarized below.  An error of EOPNOTSUPP is
-   returned if these two options are used with getsockopt().
-
-      IPV6_JOIN_GROUP
-
-         Join a multicast group on a specified local interface.  If the
-         interface index is specified as 0, the kernel chooses the local
-         interface.  For example, some kernels look up the multicast
-         group in the normal IPv6 routing table and using the resulting
-         interface.
-
-         Argument type: struct ipv6_mreq
-
-      IPV6_LEAVE_GROUP
-
-         Leave a multicast group on a specified interface.
-
-         Argument type: struct ipv6_mreq
-
-   The argument type of both of these options is the ipv6_mreq structure,
-   defined as a result of including the <netinet/in.h> header;
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 20]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   struct ipv6_mreq {
-       struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
-       unsigned int    ipv6mr_interface; /* interface index */
-   };
-
-   Note that to receive multicast datagrams a process must join the
-   multicast group and bind the UDP port to which datagrams will be
-   sent.  Some processes also bind the multicast group address to the
-   socket, in addition to the port, to prevent other datagrams destined
-   to that same port from being delivered to the socket.
-
-6. Library Functions
-
-   New library functions are needed to perform a variety of operations
-   with IPv6 addresses.  Functions are needed to lookup IPv6 addresses
-   in the Domain Name System (DNS).  Both forward lookup (nodename-to-
-   address translation) and reverse lookup (address-to-nodename
-   translation) need to be supported.  Functions are also needed to
-   convert IPv6 addresses between their binary and textual form.
-
-   We note that the two existing functions, gethostbyname() and
-   gethostbyaddr(), are left as-is.  New functions are defined to handle
-   both IPv4 and IPv6 addresses.
-
-6.1 Nodename-to-Address Translation
-
-   The commonly used function gethostbyname() is inadequate for many
-   applications, first because it provides no way for the caller to
-   specify anything about the types of addresses desired (IPv4 only,
-   IPv6 only, IPv4-mapped IPv6 are OK, etc.), and second because many
-   implementations of this function are not thread safe.  RFC 2133
-   defined a function named gethostbyname2() but this function was also
-   inadequate, first because its use required setting a global option
-   (RES_USE_INET6) when IPv6 addresses were required, and second because
-   a flag argument is needed to provide the caller with additional
-   control over the types of addresses required.
-
-   The following function is new and must be thread safe:
-
-   #include <sys/socket.h>
-   #include <netdb.h>
-
-   struct hostent *getipnodebyname(const char *name, int af, int flags
-                                       int *error_num);
-
-   The name argument can be either a node name or a numeric address
-   string (i.e., a dotted-decimal IPv4 address or an IPv6 hex address).
-   The af argument specifies the address family, either AF_INET or
-
-
-
-Gilligan, et. al.            Informational                     [Page 21]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   AF_INET6. The error_num value is returned to the caller, via a
-   pointer, with the appropriate error code in error_num, to support
-   thread safe error code returns.  error_num will be set to one of the
-   following values:
-
-      HOST_NOT_FOUND
-
-         No such host is known.
-
-      NO_ADDRESS
-
-         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.
-
-      NO_RECOVERY
-
-         An unexpected server failure occurred which cannot be recovered.
-
-      TRY_AGAIN
-
-         A temporary and possibly transient error occurred, such as a
-         failure of a server to respond.
-
-   The flags argument specifies the types of addresses that are searched
-   for, and the types of addresses that are returned.  We note that a
-   special flags value of AI_DEFAULT (defined below) should handle most
-   applications.
-
-   That is, porting simple applications to use IPv6 replaces the call
-
-      hptr = gethostbyname(name);
-
-   with
-
-      hptr = getipnodebyname(name, AF_INET6, AI_DEFAULT, &error_num);
-
-   and changes any subsequent error diagnosis code to use error_num
-   instead of externally declared variables, such as h_errno.
-
-   Applications desiring finer control over the types of addresses
-   searched for and returned, can specify other combinations of the
-   flags argument.
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 22]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   A flags of 0 implies a strict interpretation of the af argument:
-
-      - If flags is 0 and af is AF_INET, then the caller wants only
-        IPv4 addresses.  A query is made for A records.  If successful,
-        the IPv4 addresses are returned and the h_length member of the
-        hostent structure will be 4, else the function returns a NULL
-        pointer.
-
-      -  If flags is 0 and if af is AF_INET6, then the caller wants only
-        IPv6 addresses.  A query is made for AAAA records.  If
-        successful, the IPv6 addresses are returned and the h_length
-        member of the hostent structure will be 16, else the function
-        returns a NULL pointer.
-
-   Other constants can be logically-ORed into the flags argument, to
-   modify the behavior of the function.
-
-      - If the AI_V4MAPPED flag is specified along with an af of
-        AF_INET6, then the caller will accept IPv4-mapped IPv6
-        addresses.  That is, if no AAAA records are found then a query
-        is made for A records and any found are returned as IPv4-mapped
-        IPv6 addresses (h_length will be 16).  The AI_V4MAPPED flag is
-        ignored unless af equals AF_INET6.
-
-      - The AI_ALL flag is used in conjunction with the AI_V4MAPPED
-        flag, and is only used with the IPv6 address family.  When AI_ALL
-        is logically or'd with AI_V4MAPPED flag then the caller wants
-        all addresses: IPv6 and IPv4-mapped IPv6.  A query is first made
-        for AAAA records and if successful, the IPv6 addresses are
-        returned. Another query is then made for A records and any found
-        are returned as IPv4-mapped IPv6 addresses. h_length will be 16.
-        Only if both queries fail does the function return a NULL pointer.
-        This flag is ignored unless af equals AF_INET6.
-
-      - The AI_ADDRCONFIG flag specifies that a query for AAAA records
-        should occur only if the node has at least one IPv6 source
-        address configured and a query for A records should occur only
-        if the node has at least one IPv4 source address configured.
-
-        For example, if the node has no IPv6 source addresses
-        configured, and af equals AF_INET6, and the node name being
-        looked up has both AAAA and A records, then:
-
-            (a) if only AI_ADDRCONFIG is specified, the function
-                returns a NULL pointer;
-            (b) if AI_ADDRCONFIG | AI_V4MAPPED is specified, the A
-                records are returned as IPv4-mapped IPv6 addresses;
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 23]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   The special flags value of AI_DEFAULT is defined as
-
-      #define  AI_DEFAULT  (AI_V4MAPPED | AI_ADDRCONFIG)
-
-   We noted that the getipnodebyname() function must allow the name
-   argument to be either a node name or a literal address string (i.e.,
-   a dotted-decimal IPv4 address or an IPv6 hex address).  This saves
-   applications from having to call inet_pton() to handle literal
-   address strings.
-
-   There are four scenarios based on the type of literal address string
-   and the value of the af argument.
-
-   The two simple cases are:
-
-   When name is a dotted-decimal IPv4 address and af equals AF_INET, or
-   when name is an IPv6 hex address and af equals AF_INET6.  The members
-   of the returned hostent structure are: h_name points to a copy of the
-   name argument, h_aliases is a NULL pointer, h_addrtype is a copy of
-   the af argument, h_length is either 4 (for AF_INET) or 16 (for
-   AF_INET6), h_addr_list[0] is a pointer to the 4-byte or 16-byte
-   binary address, and h_addr_list[1] is a NULL pointer.
-
-   When name is a dotted-decimal IPv4 address and af equals AF_INET6,
-   and flags equals AI_V4MAPPED, an IPv4-mapped IPv6 address is
-   returned:  h_name points to an IPv6 hex address containing the IPv4-
-   mapped IPv6 address, h_aliases is a NULL pointer, h_addrtype is
-   AF_INET6, h_length is 16, h_addr_list[0] is a pointer to the 16-byte
-   binary address, and h_addr_list[1] is a NULL pointer.  If AI_V4MAPPED
-   is set (with or without AI_ALL) return IPv4-mapped otherwise return
-   NULL.
-
-   It is an error when name is an IPv6 hex address and af equals
-   AF_INET.  The function's return value is a NULL pointer and error_num
-   equals HOST_NOT_FOUND.
-
-6.2 Address-To-Nodename Translation
-
-   The following function has the same arguments as the existing
-   gethostbyaddr() function, but adds an error number.
-
-      #include <sys/socket.h> #include <netdb.h>
-
-      struct hostent *getipnodebyaddr(const void *src, size_t len,
-                                          int af, int *error_num);
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 24]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   As with getipnodebyname(), getipnodebyaddr() must be thread safe.
-   The error_num value is returned to the caller with the appropriate
-   error code, to support thread safe error code returns.  The following
-   error conditions may be returned for error_num:
-
-      HOST_NOT_FOUND
-
-         No such host is known.
-
-      NO_ADDRESS
-
-         The server recognized 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.
-
-      NO_RECOVERY
-
-         An unexpected server failure occurred which cannot be
-         recovered.
-
-      TRY_AGAIN
-
-         A temporary and possibly transient error occurred, such as a
-         failure of a server to respond.
-
-   One possible source of confusion is the handling of IPv4-mapped IPv6
-   addresses and IPv4-compatible IPv6 addresses, but the following logic
-   should apply.
-
-      1.  If af is AF_INET6, and if len equals 16, and if the IPv6
-          address is an IPv4-mapped IPv6 address or an IPv4-compatible
-          IPv6 address, then skip over the first 12 bytes of the IPv6
-          address, set af to AF_INET, and set len to 4.
-
-      2.  If af is AF_INET, lookup the name for the given IPv4 address
-          (e.g., query for a PTR record in the in-addr.arpa domain).
-
-      3.  If af is AF_INET6, lookup the name for the given IPv6 address
-          (e.g., query for a PTR record in the ip6.int domain).
-
-      4.  If the function is returning success, then the single address
-          that is returned in the hostent structure is a copy of the
-          first argument to the function with the same address family
-          that was passed as an argument to this function.
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 25]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   All four steps listed are performed, in order.  Also note that the
-   IPv6 hex addresses "::" and "::1" MUST NOT be treated as IPv4-
-   compatible addresses, and if the address is "::", HOST_NOT_FOUND MUST
-   be returned and a query of the address not performed.
-
-   Also for the macro in section 6.7 IN6_IS_ADDR_V4COMPAT MUST return
-   false for "::" and "::1".
-
-6.3 Freeing memory for getipnodebyname and getipnodebyaddr
-
-   The hostent structure does not change from its existing definition.
-   This structure, and the information pointed to by this structure, are
-   dynamically allocated by getipnodebyname and getipnodebyaddr.  The
-   following function frees this memory:
-
-      #include <netdb.h>
-
-      void freehostent(struct hostent *ptr);
-
-6.4 Protocol-Independent Nodename and Service Name Translation
-
-   Nodename-to-address translation is done in a protocol-independent
-   fashion using the getaddrinfo() function that is taken from the
-   Institute of Electrical and Electronic Engineers (IEEE) POSIX 1003.1g
-   (Protocol Independent Interfaces) draft specification [3].
-
-   The official specification for this function will be the final POSIX
-   standard, with the following additional requirements:
-
-      -  getaddrinfo() (along with the getnameinfo() function described
-         in the next section) must be thread safe.
-
-      -  The AI_NUMERICHOST is new with this document.
-
-      -  All fields in socket address structures returned by
-         getaddrinfo() that are not filled in through an explicit
-         argument (e.g., sin6_flowinfo and sin_zero) must be set to 0.
-         (This makes it easier to compare socket address structures.)
-
-      -  getaddrinfo() must fill in the length field of a socket address
-         structure (e.g., sin6_len) on systems that support this field.
-
-   We are providing this independent description of the function because
-   POSIX standards are not freely available (as are IETF documents).
-
-      #include <sys/socket.h>
-      #include <netdb.h>
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 26]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-      int getaddrinfo(const char *nodename, const char *servname,
-                      const struct addrinfo *hints,
-                      struct addrinfo **res);
-
-   The addrinfo structure is defined as a result of including the
-   <netdb.h> header.
-
-  struct addrinfo {
-    int     ai_flags;     /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST */
-    int     ai_family;    /* PF_xxx */
-    int     ai_socktype;  /* SOCK_xxx */
-    int     ai_protocol;  /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
-    size_t  ai_addrlen;   /* length of ai_addr */
-    char   *ai_canonname; /* canonical name for nodename */
-    struct sockaddr  *ai_addr; /* binary address */
-    struct addrinfo  *ai_next; /* next structure in linked list */
-  };
-
-   The return value from the function is 0 upon success or a nonzero
-   error code.  The following names are the nonzero error codes from
-   getaddrinfo(), and are defined in <netdb.h>:
-
-      EAI_ADDRFAMILY  address family for nodename not supported
-      EAI_AGAIN       temporary failure in name resolution
-      EAI_BADFLAGS    invalid value for ai_flags
-      EAI_FAIL        non-recoverable failure in name resolution
-      EAI_FAMILY      ai_family not supported
-      EAI_MEMORY      memory allocation failure
-      EAI_NODATA      no address associated with nodename
-      EAI_NONAME      nodename nor servname provided, or not known
-      EAI_SERVICE     servname not supported for ai_socktype
-      EAI_SOCKTYPE    ai_socktype not supported
-      EAI_SYSTEM      system error returned in errno
-
-   The nodename and servname arguments are pointers to null-terminated
-   strings or NULL.  One or both of these two arguments must be a non-
-   NULL pointer.  In the normal client scenario, both the nodename and
-   servname are specified.  In the normal server scenario, only the
-   servname is specified.  A non-NULL nodename string can be either a
-   node name or a numeric host address string (i.e., a dotted-decimal
-   IPv4 address or an IPv6 hex address).  A non-NULL servname string can
-   be either a service name or a decimal port number.
-
-   The caller can optionally pass an addrinfo structure, pointed to by
-   the third argument, to provide hints concerning the type of socket
-   that the caller supports.  In this hints structure all members other
-   than ai_flags, ai_family, ai_socktype, and ai_protocol must be zero
-   or a NULL pointer.  A value of PF_UNSPEC for ai_family means the
-
-
-
-Gilligan, et. al.            Informational                     [Page 27]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   caller will accept any protocol family.  A value of 0 for ai_socktype
-   means the caller will accept any socket type.  A value of 0 for
-   ai_protocol means the caller will accept any protocol.  For example,
-   if the caller handles only TCP and not UDP, then the ai_socktype
-   member of the hints structure should be set to SOCK_STREAM when
-   getaddrinfo() is called.  If the caller handles only IPv4 and not
-   IPv6, then the ai_family member of the hints structure should be set
-   to PF_INET when getaddrinfo() is called.  If the third argument to
-   getaddrinfo() is a NULL pointer, this is the same as if the caller
-   had filled in an addrinfo structure initialized to zero with
-   ai_family set to PF_UNSPEC.
-
-   Upon successful return a pointer to a linked list of one or more
-   addrinfo structures is returned through the final argument.  The
-   caller can process each addrinfo structure in this list by following
-   the ai_next pointer, until a NULL pointer is encountered.  In each
-   returned addrinfo structure the three members ai_family, ai_socktype,
-   and ai_protocol are the corresponding arguments for a call to the
-   socket() function.  In each addrinfo structure the ai_addr member
-   points to a filled-in socket address structure whose length is
-   specified by the ai_addrlen member.
-
-   If the AI_PASSIVE bit is set in the ai_flags member of the hints
-   structure, then the caller plans to use the returned socket address
-   structure in a call to bind().  In this case, if the nodename
-   argument is a NULL pointer, then the IP address portion of the socket
-   address structure will be set to INADDR_ANY for an IPv4 address or
-   IN6ADDR_ANY_INIT for an IPv6 address.
-
-   If the AI_PASSIVE bit is not set in the ai_flags member of the hints
-   structure, then the returned socket address structure will be ready
-   for a call to connect() (for a connection-oriented protocol) or
-   either connect(), sendto(), or sendmsg() (for a connectionless
-   protocol).  In this case, if the nodename argument is a NULL pointer,
-   then the IP address portion of the socket address structure will be
-   set to the loopback address.
-
-   If the AI_CANONNAME bit is set in the ai_flags member of the hints
-   structure, then upon successful return the ai_canonname member of the
-   first addrinfo structure in the linked list will point to a null-
-   terminated string containing the canonical name of the specified
-   nodename.
-
-   If the AI_NUMERICHOST bit is set in the ai_flags member of the hints
-   structure, then a non-NULL nodename string must be a numeric host
-   address string.  Otherwise an error of EAI_NONAME is returned.  This
-   flag prevents any type of name resolution service (e.g., the DNS)
-   from being called.
-
-
-
-Gilligan, et. al.            Informational                     [Page 28]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   All of the information returned by getaddrinfo() is dynamically
-   allocated: the addrinfo structures, and the socket address structures
-   and canonical node name strings pointed to by the addrinfo
-   structures.  To return this information to the system the function
-   freeaddrinfo() is called:
-
-      #include <sys/socket.h> #include <netdb.h>
-
-      void freeaddrinfo(struct addrinfo *ai);
-
-   The addrinfo structure pointed to by the ai argument is freed, along
-   with any dynamic storage pointed to by the structure.  This operation
-   is repeated until a NULL ai_next pointer is encountered.
-
-   To aid applications in printing error messages based on the EAI_xxx
-   codes returned by getaddrinfo(), the following function is defined.
-
-      #include <sys/socket.h> #include <netdb.h>
-
-      char *gai_strerror(int ecode);
-
-   The argument is one of the EAI_xxx values defined earlier and the
-   return value points to a string describing the error.  If the
-   argument is not one of the EAI_xxx values, the function still returns
-   a pointer to a string whose contents indicate an unknown error.
-
-6.5 Socket Address Structure to Nodename and Service Name
-
-   The POSIX 1003.1g specification includes no function to perform the
-   reverse conversion from getaddrinfo(): to look up a nodename and
-   service name, given the binary address and port.  Therefore, we
-   define the following function:
-
-      #include <sys/socket.h>
-      #include <netdb.h>
-
-      int getnameinfo(const struct sockaddr *sa, socklen_t salen,
-                      char *host, size_t hostlen,
-                      char *serv, size_t servlen,
-                      int flags);
-
-   This function looks up an IP address and port number provided by the
-   caller in the DNS and system-specific database, and returns text
-   strings for both in buffers provided by the caller.  The function
-   indicates successful completion by a zero return value; a non-zero
-   return value indicates failure.
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 29]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   The first argument, sa, points to either a sockaddr_in structure (for
-   IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP
-   address and port number.  The salen argument gives the length of the
-   sockaddr_in or sockaddr_in6 structure.
-
-   The function returns the nodename associated with the IP address in
-   the buffer pointed to by the host argument.  The caller provides the
-   size of this buffer via the hostlen argument.  The service name
-   associated with the port number is returned in the buffer pointed to
-   by serv, and the servlen argument gives the length of this buffer.
-   The caller specifies not to return either string by providing a zero
-   value for the hostlen or servlen arguments.  Otherwise, the caller
-   must provide buffers large enough to hold the nodename and the
-   service name, including the terminating null characters.
-
-   Unfortunately most systems do not provide constants that specify the
-   maximum size of either a fully-qualified domain name or a service
-   name.  Therefore to aid the application in allocating buffers for
-   these two returned strings the following constants are defined in
-   <netdb.h>:
-
-      #define NI_MAXHOST  1025
-      #define NI_MAXSERV    32
-
-   The first value is actually defined as the constant MAXDNAME in recent
-   versions of BIND's <arpa/nameser.h> header (older versions of BIND
-   define this constant to be 256) and the second is a guess based on the
-   services listed in the current Assigned Numbers RFC.
-
-   The final argument is a flag that changes the default actions of this
-   function.  By default the fully-qualified domain name (FQDN) for the
-   host is looked up in the DNS and returned.  If the flag bit NI_NOFQDN
-   is set, only the nodename portion of the FQDN is returned for local
-   hosts.
-
-   If the flag bit NI_NUMERICHOST is set, or if the host's name cannot be
-   located in the DNS, the numeric form of the host's address is returned
-   instead of its name (e.g., by calling inet_ntop() instead of
-   getipnodebyaddr()).  If the flag bit NI_NAMEREQD is set, an error is
-   returned if the host's name cannot be located in the DNS.
-
-   If the flag bit NI_NUMERICSERV is set, the numeric form of the service
-   address is returned (e.g., its port number) instead of its name.  The
-   two NI_NUMERICxxx flags are required to support the "-n" flag that
-   many commands provide.
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 30]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   A fifth flag bit, NI_DGRAM, specifies that the service 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 (e.g. 512-514) that have different services for UDP
-   and TCP.
-
-   These NI_xxx flags are defined in <netdb.h> along with the AI_xxx
-   flags already defined for getaddrinfo().
-
-6.6 Address Conversion Functions
-
-   The two functions inet_addr() and inet_ntoa() convert an IPv4 address
-   between binary and text form.  IPv6 applications need similar
-   functions.  The following two functions convert both IPv6 and IPv4
-   addresses:
-
-      #include <sys/socket.h>
-      #include <arpa/inet.h>
-
-      int inet_pton(int af, const char *src, void *dst);
-
-      const char *inet_ntop(int af, const void *src,
-                            char *dst, size_t size);
-
-   The inet_pton() function converts an address in its standard text
-   presentation form into its numeric binary form.  The af argument
-   specifies the family of the address.  Currently the AF_INET and
-   AF_INET6 address families are supported.  The src argument points to
-   the string being passed in.  The dst argument points to a buffer into
-   which the function stores the numeric address.  The address is
-   returned in network byte order.  Inet_pton() returns 1 if the
-   conversion succeeds, 0 if the input is not a valid IPv4 dotted-
-   decimal string or a valid IPv6 address string, or -1 with errno set
-   to EAFNOSUPPORT if the af argument is unknown.  The calling
-   application must ensure that the buffer referred to by dst is large
-   enough to hold the numeric address (e.g., 4 bytes for AF_INET or 16
-   bytes for AF_INET6).
-
-   If the af argument is AF_INET, the function accepts a string in the
-   standard IPv4 dotted-decimal form:
-
-      ddd.ddd.ddd.ddd
-
-   where ddd is a one to three digit decimal number between 0 and 255.
-   Note that many implementations of the existing inet_addr() and
-   inet_aton() functions accept nonstandard input: octal numbers,
-   hexadecimal numbers, and fewer than four numbers.  inet_pton() does
-   not accept these formats.
-
-
-
-Gilligan, et. al.            Informational                     [Page 31]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   If the af argument is AF_INET6, then the function accepts a string in
-   one of the standard IPv6 text forms defined in Section 2.2 of the
-   addressing architecture specification [2].
-
-   The inet_ntop() function converts a numeric address into a text
-   string suitable for presentation.  The af argument specifies the
-   family of the address.  This can be AF_INET or AF_INET6.  The src
-   argument points to a buffer holding an IPv4 address if the af
-   argument is AF_INET, or an IPv6 address if the af argument is
-   AF_INET6, the address must be in network byte order.  The dst
-   argument points to a buffer where the function will store the
-   resulting text string.  The size argument specifies the size of this
-   buffer.  The application must specify a non-NULL dst argument.  For
-   IPv6 addresses, the buffer must be at least 46-octets.  For IPv4
-   addresses, the buffer must be at least 16-octets.  In order to allow
-   applications to easily declare buffers of the proper size to store
-   IPv4 and IPv6 addresses in string form, the following two constants
-   are defined in <netinet/in.h>:
-
-      #define INET_ADDRSTRLEN    16
-      #define INET6_ADDRSTRLEN   46
-
-   The inet_ntop() function returns a pointer to the buffer containing
-   the text string if the conversion succeeds, and NULL otherwise.  Upon
-   failure, errno is set to EAFNOSUPPORT if the af argument is invalid or
-   ENOSPC if the size of the result buffer is inadequate.
-
-6.7 Address Testing Macros
-
-   The following macros can be used to test for special IPv6 addresses.
-
-      #include <netinet/in.h>
-
-      int  IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *);
-      int  IN6_IS_ADDR_LOOPBACK    (const struct in6_addr *);
-      int  IN6_IS_ADDR_MULTICAST   (const struct in6_addr *);
-      int  IN6_IS_ADDR_LINKLOCAL   (const struct in6_addr *);
-      int  IN6_IS_ADDR_SITELOCAL   (const struct in6_addr *);
-      int  IN6_IS_ADDR_V4MAPPED    (const struct in6_addr *);
-      int  IN6_IS_ADDR_V4COMPAT    (const struct in6_addr *);
-
-      int  IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
-      int  IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
-      int  IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
-      int  IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *);
-      int  IN6_IS_ADDR_MC_GLOBAL   (const struct in6_addr *);
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 32]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   The first seven macros return true if the address is of the specified
-   type, or false otherwise.  The last five test the scope of a
-   multicast address and return true if the address is a multicast
-   address of the specified scope or false if the address is either not
-   a multicast address or not of the specified scope.  Note that
-   IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL return true only for
-   the two local-use IPv6 unicast addresses.  These two macros do not
-   return true for IPv6 multicast addresses of either link-local scope
-   or site-local scope.
-
-7. Summary of New Definitions
-
-   The following list summarizes the constants, structure, and extern
-   definitions discussed in this memo, sorted by header.
-
-      <net/if.h>      IF_NAMESIZE
-      <net/if.h>      struct if_nameindex{};
-
-      <netdb.h>       AI_ADDRCONFIG
-      <netdb.h>       AI_DEFAULT
-      <netdb.h>       AI_ALL
-      <netdb.h>       AI_CANONNAME
-      <netdb.h>       AI_NUMERICHOST
-      <netdb.h>       AI_PASSIVE
-      <netdb.h>       AI_V4MAPPED
-      <netdb.h>       EAI_ADDRFAMILY
-      <netdb.h>       EAI_AGAIN
-      <netdb.h>       EAI_BADFLAGS
-      <netdb.h>       EAI_FAIL
-      <netdb.h>       EAI_FAMILY
-      <netdb.h>       EAI_MEMORY
-      <netdb.h>       EAI_NODATA
-      <netdb.h>       EAI_NONAME
-      <netdb.h>       EAI_SERVICE
-      <netdb.h>       EAI_SOCKTYPE
-      <netdb.h>       EAI_SYSTEM
-      <netdb.h>       NI_DGRAM
-      <netdb.h>       NI_MAXHOST
-      <netdb.h>       NI_MAXSERV
-      <netdb.h>       NI_NAMEREQD
-      <netdb.h>       NI_NOFQDN
-      <netdb.h>       NI_NUMERICHOST
-      <netdb.h>       NI_NUMERICSERV
-      <netdb.h>       struct addrinfo{};
-
-      <netinet/in.h>  IN6ADDR_ANY_INIT
-      <netinet/in.h>  IN6ADDR_LOOPBACK_INIT
-      <netinet/in.h>  INET6_ADDRSTRLEN
-
-
-
-Gilligan, et. al.            Informational                     [Page 33]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-      <netinet/in.h>  INET_ADDRSTRLEN
-      <netinet/in.h>  IPPROTO_IPV6
-      <netinet/in.h>  IPV6_JOIN_GROUP
-      <netinet/in.h>  IPV6_LEAVE_GROUP
-      <netinet/in.h>  IPV6_MULTICAST_HOPS
-      <netinet/in.h>  IPV6_MULTICAST_IF
-      <netinet/in.h>  IPV6_MULTICAST_LOOP
-      <netinet/in.h>  IPV6_UNICAST_HOPS
-      <netinet/in.h>  SIN6_LEN
-      <netinet/in.h>  extern const struct in6_addr in6addr_any;
-      <netinet/in.h>  extern const struct in6_addr in6addr_loopback;
-      <netinet/in.h>  struct in6_addr{};
-      <netinet/in.h>  struct ipv6_mreq{};
-      <netinet/in.h>  struct sockaddr_in6{};
-
-      <sys/socket.h>  AF_INET6
-      <sys/socket.h>  PF_INET6
-      <sys/socket.h>  struct sockaddr_storage;
-
-   The following list summarizes the function and macro prototypes
-   discussed in this memo, sorted by header.
-
-<arpa/inet.h>   int inet_pton(int, const char *, void *);
-<arpa/inet.h>   const char *inet_ntop(int, const void *,
-                                      char *, size_t);
-
-<net/if.h>      char *if_indextoname(unsigned int, char *);
-<net/if.h>      unsigned int if_nametoindex(const char *);
-<net/if.h>      void if_freenameindex(struct if_nameindex *);
-<net/if.h>      struct if_nameindex *if_nameindex(void);
-
-<netdb.h>       int getaddrinfo(const char *, const char *,
-                                const struct addrinfo *,
-                                struct addrinfo **);
-<netdb.h>       int getnameinfo(const struct sockaddr *, socklen_t,
-                                char *, size_t, char *, size_t, int);
-<netdb.h>       void freeaddrinfo(struct addrinfo *);
-<netdb.h>       char *gai_strerror(int);
-<netdb.h>       struct hostent *getipnodebyname(const char *, int, int,
-                                       int *);
-<netdb.h>       struct hostent *getipnodebyaddr(const void *, size_t,
-                                       int, int *);
-<netdb.h>       void freehostent(struct hostent *);
-
-<netinet/in.h>  int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
-
-
-
-Gilligan, et. al.            Informational                     [Page 34]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-<netinet/in.h>  int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MULTICAST(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *);
-
-8. Security Considerations
-
-   IPv6 provides a number of new security mechanisms, many of which need
-   to be accessible to applications.  Companion memos detailing the
-   extensions to the socket interfaces to support IPv6 security are
-   being written.
-
-9. Year 2000 Considerations
-
-   There are no issues for this memo concerning the Year 2000 issue
-   regarding the use of dates.
-
-Changes From RFC 2133
-
-   Changes made in the March 1998 Edition (-01 draft):
-
-      Changed all "hostname" to "nodename" for consistency with other
-      IPv6 documents.
-
-      Section 3.3: changed comment for sin6_flowinfo to be "traffic
-      class & flow info" and updated corresponding text description to
-      current definition of these two fields.
-
-      Section 3.10 ("Portability Additions") is new.
-
-      Section 6: a new paragraph was added reiterating that the existing
-      gethostbyname() and gethostbyaddr() are not changed.
-
-      Section 6.1: change gethostbyname3() to getnodebyname().  Add
-      AI_DEFAULT to handle majority of applications.  Renamed
-      AI_V6ADDRCONFIG to AI_ADDRCONFIG and define it for A records and
-      IPv4 addresses too.  Defined exactly what getnodebyname() must
-      return if the name argument is a numeric address string.
-
-      Section 6.2: change gethostbyaddr() to getnodebyaddr().  Reword
-      items 2 and 3 in the description of how to handle IPv4-mapped and
-      IPv4- compatible addresses to "lookup a name" for a given address,
-      instead of specifying what type of DNS query to issue.
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 35]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-      Section 6.3: added two more requirements to getaddrinfo().
-
-      Section 7: added the following constants to the list for
-      <netdb.h>:  AI_ADDRCONFIG, AI_ALL, and AI_V4MAPPED.  Add union
-      sockaddr_union and SA_LEN to the lists for <sys/socket.h>.
-
-      Updated references.
-
-   Changes made in the November 1997 Edition (-00 draft):
-
-      The data types have been changed to conform with Draft 6.6 of the
-      Posix 1003.1g standard.
-
-      Section 3.2: data type of s6_addr changed to "uint8_t".
-
-      Section 3.3: data type of sin6_family changed to "sa_family_t".
-      data type of sin6_port changed to "in_port_t", data type of
-      sin6_flowinfo changed to "uint32_t".
-
-      Section 3.4: same as Section 3.3, plus data type of sin6_len
-      changed to "uint8_t".
-
-      Section 6.2: first argument of gethostbyaddr() changed from "const
-      char *" to "const void *" and second argument changed from "int"
-      to "size_t".
-
-      Section 6.4: second argument of getnameinfo() changed from
-      "size_t" to "socklen_t".
-
-      The wording was changed when new structures were defined, to be
-      more explicit as to which header must be included to define the
-      structure:
-
-      Section 3.2 (in6_addr{}), Section 3.3 (sockaddr_in6{}), Section
-      3.4 (sockaddr_in6{}), Section 4.3 (if_nameindex{}), Section 5.3
-      (ipv6_mreq{}), and Section 6.3 (addrinfo{}).
-
-      Section 4: NET_RT_LIST changed to NET_RT_IFLIST.
-
-      Section 5.1: The IPV6_ADDRFORM socket option was removed.
-
-      Section 5.3: Added a note that an option value other than 0 or 1
-      for IPV6_MULTICAST_LOOP returns an error.  Added a note that
-      IPV6_MULTICAST_IF, IPV6_MULTICAST_HOPS, and IPV6_MULTICAST_LOOP
-      can also be used with getsockopt(), but IPV6_ADD_MEMBERSHIP and
-      IPV6_DROP_MEMBERSHIP cannot be used with getsockopt().
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 36]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-      Section 6.1: Removed the description of gethostbyname2() and its
-      associated RES_USE_INET6 option, replacing it with
-      gethostbyname3().
-
-      Section 6.2: Added requirement that gethostbyaddr() be thread
-      safe.  Reworded step 4 to avoid using the RES_USE_INET6 option.
-
-      Section 6.3: Added the requirement that getaddrinfo() and
-      getnameinfo() be thread safe.  Added the AI_NUMERICHOST flag.
-
-      Section 6.6: Added clarification about IN6_IS_ADDR_LINKLOCAL and
-      IN6_IS_ADDR_SITELOCAL macros.
-
-   Changes made to the draft -01 specification Sept 98
-
-      Changed priority to traffic class in the spec.
-
-      Added the need for scope identification in section 2.1.
-
-      Added sin6_scope_id to struct sockaddr_in6 in sections 3.3 and
-      3.4.
-
-      Changed 3.10 to use generic storage structure to support holding
-      IPv6 addresses and removed the SA_LEN macro.
-
-      Distinguished between invalid input parameters and system failures
-      for Interface Identification in Section 4.1 and 4.2.
-
-      Added defaults for multicast operations in section 5.2 and changed
-      the names from ADD to JOIN and DROP to LEAVE to be consistent with
-      IPv6 multicast terminology.
-
-      Changed getnodebyname to getipnodebyname, getnodebyaddr to
-      getipnodebyaddr, and added MT safe error code to function
-      parameters in section 6.
-
-      Moved freehostent to its own sub-section after getipnodebyaddr now
-      6.3 (so this bumps all remaining sections in section 6.
-
-      Clarified the use of AI_ALL and AI_V4MAPPED that these are
-      dependent on the AF parameter and must be used as a conjunction in
-      section 6.1.
-
-      Removed the restriction that literal addresses cannot be used with
-      a flags argument in section 6.1.
-
-      Added Year 2000 Section to the draft
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 37]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-      Deleted Reference to the following because the attached is deleted
-      from the ID directory and has expired.  But the logic from the
-      aforementioned draft still applies, so that was kept in Section
-      6.2 bullets after 3rd paragraph.
-
-      [7]  P. Vixie, "Reverse Name Lookups of Encapsulated IPv4
-           Addresses in IPv6", Internet-Draft, <draft-vixie-ipng-
-           ipv4ptr-00.txt>, May 1996.
-
-      Deleted the following reference as it is no longer referenced.
-      And the draft has expired.
-
-      [3]  D. McDonald, "A Simple IP Security API Extension to BSD
-           Sockets", Internet-Draft, <draft-mcdonald-simple-ipsec-api-
-           01.txt>, March 1997.
-
-      Deleted the following reference as it is no longer referenced.
-
-      [4]  C. Metz, "Network Security API for Sockets",
-           Internet-Draft, <draft-metz-net-security-api-01.txt>, January
-           1998.
-
-      Update current references to current status.
-
-      Added alignment notes for in6_addr and sin6_addr.
-
-      Clarified further that AI_V4MAPPED must be used with a dotted IPv4
-      literal address for getipnodebyname(), when address family is
-      AF_INET6.
-
-      Added text to clarify "::" and "::1" when used by
-      getipnodebyaddr().
-
-Acknowledgments
-
-   Thanks to the many people who made suggestions and provided feedback
-   to this document, including: Werner Almesberger, Ran Atkinson, Fred
-   Baker, Dave Borman, Andrew Cherenson, Alex Conta, Alan Cox, Steve
-   Deering, Richard Draves, Francis Dupont, Robert Elz, Marc Hasson, Tom
-   Herbert, Bob Hinden, Wan-Yen Hsu, Christian Huitema, Koji Imada,
-   Markus Jork, Ron Lee, Alan Lloyd, Charles Lynn, Dan McDonald, Dave
-   Mitton, Thomas Narten, Josh Osborne, Craig Partridge, Jean-Luc
-   Richier, Erik Scoredos, Keith Sklower, Matt Thomas, Harvey Thompson,
-   Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David
-   Waitzman, Carl Williams, and Kazu Yamamoto,
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 38]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-   The getaddrinfo() and getnameinfo() functions are taken from an
-   earlier Internet Draft by Keith Sklower.  As noted in that draft,
-   William Durst, Steven Wise, Michael Karels, and Eric Allman provided
-   many useful discussions on the subject of protocol-independent name-
-   to-address translation, and reviewed early versions of Keith
-   Sklower's original proposal.  Eric Allman implemented the first
-   prototype of getaddrinfo().  The observation that specifying the pair
-   of name and service would suffice for connecting to a service
-   independent of protocol details was made by Marshall Rose in a
-   proposal to X/Open for a "Uniform Network Interface".
-
-   Craig Metz, Jack McCann, Erik Nordmark, Tim Hartrick, and Mukesh
-   Kacker made many contributions to this document.  Ramesh Govindan
-   made a number of contributions and co-authored an earlier version of
-   this memo.
-
-References
-
-   [1]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
-        Specification", RFC 2460, December 1998.
-
-   [2]  Hinden, R. and S. Deering, "IP Version 6 Addressing
-        Architecture", RFC 2373, July 1998.
-
-   [3]  IEEE, "Protocol Independent Interfaces", IEEE Std 1003.1g, DRAFT
-        6.6, March 1997.
-
-   [4]  Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", RFC
-        2292, February 1998.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 39]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-Authors' Addresses
-
-   Robert E. Gilligan
-   FreeGate Corporation
-   1208 E. Arques Ave.
-   Sunnyvale, CA 94086
-
-   Phone: +1 408 617 1004
-   EMail: gilligan@freegate.com
-
-
-   Susan Thomson
-   Bell Communications Research
-   MRE 2P-343, 445 South Street
-   Morristown, NJ 07960
-
-   Phone: +1 201 829 4514
-   EMail: set@thumper.bellcore.com
-
-
-   Jim Bound
-   Compaq Computer Corporation
-   110 Spitbrook Road ZK3-3/U14
-   Nashua, NH 03062-2698
-
-   Phone: +1 603 884 0400
-   EMail: bound@zk3.dec.com
-
-
-   W. Richard Stevens
-   1202 E. Paseo del Zorro
-   Tucson, AZ 85718-2826
-
-   Phone: +1 520 297 9416
-   EMail: rstevens@kohala.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 40]
-
-RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et. al.            Informational                     [Page 41]
-
diff --git a/contrib/bind9/doc/rfc/rfc2671.txt b/contrib/bind9/doc/rfc/rfc2671.txt
deleted file mode 100644
index ec05f80..0000000
--- a/contrib/bind9/doc/rfc/rfc2671.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            P. Vixie
-Request for Comments: 2671                                            ISC
-Category: Standards Track                                     August 1999
-
-
-                  Extension Mechanisms for DNS (EDNS0)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-Abstract
-
-   The Domain Name System's wire protocol includes a number of fixed
-   fields whose range has been or soon will be exhausted and does not
-   allow clients to advertise their capabilities to servers.  This
-   document describes backward compatible mechanisms for allowing the
-   protocol to grow.
-
-1 - Rationale and Scope
-
-1.1. DNS (see [RFC1035]) specifies a Message Format and within such
-     messages there are standard formats for encoding options, errors,
-     and name compression.  The maximum allowable size of a DNS Message
-     is fixed.  Many of DNS's protocol limits are too small for uses
-     which are or which are desired to become common.  There is no way
-     for implementations to advertise their capabilities.
-
-1.2. Existing clients will not know how to interpret the protocol
-     extensions detailed here.  In practice, these clients will be
-     upgraded when they have need of a new feature, and only new
-     features will make use of the extensions.  We must however take
-     account of client behaviour in the face of extra fields, and design
-     a fallback scheme for interoperability with these clients.
-
-
-
-
-
-
-
-
-
-Vixie                       Standards Track                     [Page 1]
-
-RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
-
-
-2 - Affected Protocol Elements
-
-2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit
-     word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of
-     1-bit flags.  The original reserved Z bits have been allocated to
-     various purposes, and most of the RCODE values are now in use.
-     More flags and more possible RCODEs are needed.
-
-2.2. The first two bits of a wire format domain label are used to denote
-     the type of the label.  [RFC1035 4.1.4] allocates two of the four
-     possible types and reserves the other two.  Proposals for use of
-     the remaining types far outnumber those available.  More label
-     types are needed.
-
-2.3. DNS Messages are limited to 512 octets in size when sent over UDP.
-     While the minimum maximum reassembly buffer size still allows a
-     limit of 512 octets of UDP payload, most of the hosts now connected
-     to the Internet are able to reassemble larger datagrams.  Some
-     mechanism must be created to allow requestors to advertise larger
-     buffer sizes to responders.
-
-3 - Extended Label Types
-
-3.1. The "0 1" label type will now indicate an extended label type,
-     whose value is encoded in the lower six bits of the first octet of
-     a label.  All subsequently developed label types should be encoded
-     using an extended label type.
-
-3.2. The "1 1 1 1 1 1" extended label type will be reserved for future
-     expansion of the extended label type code space.
-
-4 - OPT pseudo-RR
-
-4.1. One OPT pseudo-RR can be added to the additional data section of
-     either a request or a response.  An OPT is called a pseudo-RR
-     because it pertains to a particular transport level message and not
-     to any actual DNS data.  OPT RRs shall never be cached, forwarded,
-     or stored in or loaded from master files.  The quantity of OPT
-     pseudo-RRs per message shall be either zero or one, but not
-     greater.
-
-4.2. An OPT RR has a fixed part and a variable set of options expressed
-     as {attribute, value} pairs.  The fixed part holds some DNS meta
-     data and also a small collection of new protocol elements which we
-     expect to be so popular that it would be a waste of wire space to
-     encode them as {attribute, value} pairs.
-
-
-
-
-
-Vixie                       Standards Track                     [Page 2]
-
-RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
-
-
-4.3. The fixed part of an OPT RR is structured as follows:
-
-     Field Name   Field Type     Description
-     ------------------------------------------------------
-     NAME         domain name    empty (root domain)
-     TYPE         u_int16_t      OPT
-     CLASS        u_int16_t      sender's UDP payload size
-     TTL          u_int32_t      extended RCODE and flags
-     RDLEN        u_int16_t      describes RDATA
-     RDATA        octet stream   {attribute,value} pairs
-
-4.4. The variable part of an OPT RR is encoded in its RDATA and is
-     structured as zero or more of the following:
-
-                +0 (MSB)                            +1 (LSB)
-     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-  0: |                          OPTION-CODE                          |
-     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-  2: |                         OPTION-LENGTH                         |
-     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-  4: |                                                               |
-     /                          OPTION-DATA                          /
-     /                                                               /
-     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-   OPTION-CODE    (Assigned by IANA.)
-
-   OPTION-LENGTH  Size (in octets) of OPTION-DATA.
-
-   OPTION-DATA    Varies per OPTION-CODE.
-
-4.5. The sender's UDP payload size (which OPT stores in the RR CLASS
-     field) is the number of octets of the largest UDP payload that can
-     be reassembled and delivered in the sender's network stack.  Note
-     that path MTU, with or without fragmentation, may be smaller than
-     this.
-
-4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP
-       reassembly buffer.  Choosing 1280 on an Ethernet connected
-       requestor would be reasonable.  The consequence of choosing too
-       large a value may be an ICMP message from an intermediate
-       gateway, or even a silent drop of the response message.
-
-4.5.2. Both requestors and responders are advised to take account of the
-       path's discovered MTU (if already known) when considering message
-       sizes.
-
-
-
-
-
-Vixie                       Standards Track                     [Page 3]
-
-RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
-
-
-4.5.3. The requestor's maximum payload size can change over time, and
-       should therefore not be cached for use beyond the transaction in
-       which it is advertised.
-
-4.5.4. The responder's maximum payload size can change over time, but
-       can be reasonably expected to remain constant between two
-       sequential transactions; for example, a meaningless QUERY to
-       discover a responder's maximum UDP payload size, followed
-       immediately by an UPDATE which takes advantage of this size.
-       (This is considered preferrable to the outright use of TCP for
-       oversized requests, if there is any reason to suspect that the
-       responder implements EDNS, and if a request will not fit in the
-       default 512 payload size limit.)
-
-4.5.5. Due to transaction overhead, it is unwise to advertise an
-       architectural limit as a maximum UDP payload size.  Just because
-       your stack can reassemble 64KB datagrams, don't assume that you
-       want to spend more than about 4KB of state memory per ongoing
-       transaction.
-
-4.6. The extended RCODE and flags (which OPT stores in the RR TTL field)
-     are structured as follows:
-
-                 +0 (MSB)                            +1 (LSB)
-      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-   0: |         EXTENDED-RCODE        |            VERSION            |
-      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-   2: |                               Z                               |
-      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-   EXTENDED-RCODE  Forms upper 8 bits of extended 12-bit RCODE.  Note
-                   that EXTENDED-RCODE value "0" indicates that an
-                   unextended RCODE is in use (values "0" through "15").
-
-   VERSION         Indicates the implementation level of whoever sets
-                   it.  Full conformance with this specification is
-                   indicated by version "0."  Requestors are encouraged
-                   to set this to the lowest implemented level capable
-                   of expressing a transaction, to minimize the
-                   responder and network load of discovering the
-                   greatest common implementation level between
-                   requestor and responder.  A requestor's version
-                   numbering strategy should ideally be a run time
-                   configuration option.
-
-                   If a responder does not implement the VERSION level
-                   of the request, then it answers with RCODE=BADVERS.
-                   All responses will be limited in format to the
-
-
-
-Vixie                       Standards Track                     [Page 4]
-
-RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
-
-
-                   VERSION level of the request, but the VERSION of each
-                   response will be the highest implementation level of
-                   the responder.  In this way a requestor will learn
-                   the implementation level of a responder as a side
-                   effect of every response, including error responses,
-                   including RCODE=BADVERS.
-
-   Z               Set to zero by senders and ignored by receivers,
-                   unless modified in a subsequent specification.
-
-5 - Transport Considerations
-
-5.1. The presence of an OPT pseudo-RR in a request should be taken as an
-     indication that the requestor fully implements the given version of
-     EDNS, and can correctly understand any response that conforms to
-     that feature's specification.
-
-5.2. Lack of use of these features in a request must be taken as an
-     indication that the requestor does not implement any part of this
-     specification and that the responder may make no use of any
-     protocol extension described here in its response.
-
-5.3. Responders who do not understand these protocol extensions are
-     expected to send a response with RCODE NOTIMPL, FORMERR, or
-     SERVFAIL.  Therefore use of extensions should be "probed" such that
-     a responder who isn't known to support them be allowed a retry with
-     no extensions if it responds with such an RCODE.  If a responder's
-     capability level is cached by a requestor, a new probe should be
-     sent periodically to test for changes to responder capability.
-
-6 - Security Considerations
-
-     Requestor-side specification of the maximum buffer size may open a
-     new DNS denial of service attack if responders can be made to send
-     messages which are too large for intermediate gateways to forward,
-     thus leading to potential ICMP storms between gateways and
-     responders.
-
-7 - IANA Considerations
-
-     The IANA has assigned RR type code 41 for OPT.
-
-     It is the recommendation of this document and its working group
-     that IANA create a registry for EDNS Extended Label Types, for EDNS
-     Option Codes, and for EDNS Version Numbers.
-
-     This document assigns label type 0b01xxxxxx as "EDNS Extended Label
-     Type."  We request that IANA record this assignment.
-
-
-
-Vixie                       Standards Track                     [Page 5]
-
-RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
-
-
-     This document assigns extended label type 0bxx111111 as "Reserved
-     for future extended label types."  We request that IANA record this
-     assignment.
-
-     This document assigns option code 65535 to "Reserved for future
-     expansion."
-
-     This document expands the RCODE space from 4 bits to 12 bits.  This
-     will allow IANA to assign more than the 16 distinct RCODE values
-     allowed in [RFC1035].
-
-     This document assigns EDNS Extended RCODE "16" to "BADVERS".
-
-     IESG approval should be required to create new entries in the EDNS
-     Extended Label Type or EDNS Version Number registries, while any
-     published RFC (including Informational, Experimental, or BCP)
-     should be grounds for allocation of an EDNS Option Code.
-
-8 - Acknowledgements
-
-     Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley,
-     Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas
-     Narten were each instrumental in creating and refining this
-     specification.
-
-9 - References
-
-    [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
-               Specification", STD 13, RFC 1035, November 1987.
-
-10 - Author's Address
-
-   Paul Vixie
-   Internet Software Consortium
-   950 Charter Street
-   Redwood City, CA 94063
-
-   Phone: +1 650 779 7001
-   EMail: vixie@isc.org
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie                       Standards Track                     [Page 6]
-
-RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
-
-
-11 - Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie                       Standards Track                     [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc2672.txt b/contrib/bind9/doc/rfc/rfc2672.txt
deleted file mode 100644
index 1103016..0000000
--- a/contrib/bind9/doc/rfc/rfc2672.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        M. Crawford
-Request for Comments: 2672                                      Fermilab
-Category: Standards Track                                    August 1999
-
-
-                   Non-Terminal DNS Name Redirection
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-1.  Introduction
-
-   This document defines a new DNS Resource Record called "DNAME", which
-   provides the capability to map an entire subtree of the DNS name
-   space to another domain.  It differs from the CNAME record which maps
-   a single node of the name space.
-
-   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 [KWORD].
-
-2.  Motivation
-
-   This Resource Record and its processing rules were conceived as a
-   solution to the problem of maintaining address-to-name mappings in a
-   context of network renumbering.  Without the DNAME mechanism, an
-   authoritative DNS server for the address-to-name mappings of some
-   network must be reconfigured when that network is renumbered.  With
-   DNAME, the zone can be constructed so that it needs no modification
-   when renumbered.  DNAME can also be useful in other situations, such
-   as when an organizational unit is renamed.
-
-3. The DNAME Resource Record
-
-   The DNAME RR has mnemonic DNAME and type code 39 (decimal).
-
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 1]
-
-RFC 2672           Non-Terminal DNS Name Redirection         August 1999
-
-
-   DNAME has the following format:
-
-      <owner> <ttl> <class> DNAME <target>
-
-   The format is not class-sensitive.  All fields are required.  The
-   RDATA field <target> is a <domain-name> [DNSIS].
-
-   The DNAME RR causes type NS additional section processing.
-
-   The effect of the DNAME record is the substitution of the record's
-   <target> for its <owner> as a suffix of a domain name.  A "no-
-   descendants" limitation governs the use of DNAMEs in a zone file:
-
-      If a DNAME RR is present at a node N, there may be other data at N
-      (except a CNAME or another DNAME), but there MUST be no data at
-      any descendant of N.  This restriction applies only to records of
-      the same class as the DNAME record.
-
-   This rule assures predictable results when a DNAME record is cached
-   by a server which is not authoritative for the record's zone.  It
-   MUST be enforced when authoritative zone data is loaded.  Together
-   with the rules for DNS zone authority [DNSCLR] it implies that DNAME
-   and NS records can only coexist at the top of a zone which has only
-   one node.
-
-   The compression scheme of [DNSIS] MUST NOT be applied to the RDATA
-   portion of a DNAME record unless the sending server has some way of
-   knowing that the receiver understands the DNAME record format.
-   Signalling such understanding is expected to be the subject of future
-   DNS Extensions.
-
-   Naming loops can be created with DNAME records or a combination of
-   DNAME and CNAME records, just as they can with CNAME records alone.
-   Resolvers, including resolvers embedded in DNS servers, MUST limit
-   the resources they devote to any query.  Implementors should note,
-   however, that fairly lengthy chains of DNAME records may be valid.
-
-4.  Query Processing
-
-   To exploit the DNAME mechanism the name resolution algorithms [DNSCF]
-   must be modified slightly for both servers and resolvers.
-
-   Both modified algorithms incorporate the operation of making a
-   substitution on a name (either QNAME or SNAME) under control of a
-   DNAME record.  This operation will be referred to as "the DNAME
-   substitution".
-
-
-
-
-
-Crawford                    Standards Track                     [Page 2]
-
-RFC 2672           Non-Terminal DNS Name Redirection         August 1999
-
-
-4.1.  Processing by Servers
-
-   For a server performing non-recursive service steps 3.c and 4 of
-   section 4.3.2 [DNSCF] are changed to check for a DNAME record before
-   checking for a wildcard ("*") label, and to return certain DNAME
-   records from zone data and the cache.
-
-   DNS clients sending Extended DNS [EDNS0] queries with Version 0 or
-   non-extended queries are presumed not to understand the semantics of
-   the DNAME record, so a server which implements this specification,
-   when answering a non-extended query, SHOULD synthesize a CNAME record
-   for each DNAME record encountered during query processing to help the
-   client reach the correct DNS data.  The behavior of clients and
-   servers under Extended DNS versions greater than 0 will be specified
-   when those versions are defined.
-
-   The synthesized CNAME RR, if provided, MUST have
-
-      The same CLASS as the QCLASS of the query,
-
-      TTL equal to zero,
-
-      An <owner> equal to the QNAME in effect at the moment the DNAME RR
-      was encountered, and
-
-      An RDATA field containing the new QNAME formed by the action of
-      the DNAME substitution.
-
-   If the server has the appropriate key on-line [DNSSEC, SECDYN], it
-   MAY generate and return a SIG RR for the synthesized CNAME RR.
-
-   The revised server algorithm is:
-
-   1. Set or clear the value of recursion available in the response
-      depending on whether the name server is willing to provide
-      recursive service.  If recursive service is available and
-      requested via the RD bit in the query, go to step 5, otherwise
-      step 2.
-
-   2. Search the available zones for the zone which is the nearest
-      ancestor to QNAME.  If such a zone is found, go to step 3,
-      otherwise step 4.
-
-   3. Start matching down, label by label, in the zone.  The matching
-      process can terminate several ways:
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 3]
-
-RFC 2672           Non-Terminal DNS Name Redirection         August 1999
-
-
-      a. If the whole of QNAME is matched, we have found the node.
-
-         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, change QNAME to the canonical name in the CNAME RR,
-         and go back to step 1.
-
-         Otherwise, copy all RRs which match QTYPE into the answer
-         section and go to step 6.
-
-      b. If a match would take us out of the authoritative data, we have
-         a referral.  This happens when we encounter a node with NS RRs
-         marking cuts along the bottom of a zone.
-
-         Copy the NS RRs for the subzone into the authority section of
-         the reply.  Put whatever addresses are available into the
-         additional section, using glue RRs if the addresses are not
-         available from authoritative data or the cache.  Go to step 4.
-
-      c. If at some label, a match is impossible (i.e., the
-         corresponding label does not exist), look to see whether the
-         last label matched has a DNAME record.
-
-         If a DNAME record exists at that point, copy that record into
-         the answer section.  If substitution of its <target> for its
-         <owner> in QNAME would overflow the legal size for a <domain-
-         name>, set RCODE to YXDOMAIN [DNSUPD] and exit; otherwise
-         perform the substitution and continue.  If the query was not
-         extended [EDNS0] with a Version indicating understanding of the
-         DNAME record, the server SHOULD synthesize a CNAME record as
-         described above and include it in the answer section.  Go back
-         to step 1.
-
-         If there was no DNAME record, look to see if the "*" label
-         exists.
-
-         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.
-
-         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.
-
-
-
-
-
-Crawford                    Standards Track                     [Page 4]
-
-RFC 2672           Non-Terminal DNS Name Redirection         August 1999
-
-
-   4. Start matching down in the cache.  If QNAME is found in the cache,
-      copy all RRs attached to it that match QTYPE into the answer
-      section.  If QNAME is not found in the cache but a DNAME record is
-      present at an ancestor of QNAME, copy that DNAME record into the
-      answer section.  If there was no delegation from authoritative
-      data, look for the best one from the cache, and put it in the
-      authority section.  Go to step 6.
-
-   5. Use the local resolver or a copy of its algorithm (see resolver
-      section of this memo) to answer the query.  Store the results,
-      including any intermediate CNAMEs and DNAMEs, in the answer
-      section of the response.
-
-   6. Using local data only, attempt to add other RRs which may be
-      useful to the additional section of the query.  Exit.
-
-   Note that there will be at most one ancestor with a DNAME as
-   described in step 4 unless some zone's data is in violation of the
-   no-descendants limitation in section 3.  An implementation might take
-   advantage of this limitation by stopping the search of step 3c or
-   step 4 when a DNAME record is encountered.
-
-4.2.  Processing by Resolvers
-
-   A resolver or a server providing recursive service must be modified
-   to treat a DNAME as somewhat analogous to a CNAME.  The resolver
-   algorithm of [DNSCF] section 5.3.3 is modified to renumber step 4.d
-   as 4.e and insert a new 4.d.  The complete algorithm becomes:
-
-   1. See if the answer is in local information, and if so return it to
-      the client.
-
-   2. Find the best servers to ask.
-
-   3. Send them queries until one returns a response.
-
-   4. Analyze the response, either:
-
-      a. if the response answers the question or contains a name error,
-         cache the data as well as returning it back to the client.
-
-      b. if the response contains a better delegation to other servers,
-         cache the delegation information, and go to step 2.
-
-      c. if the response shows a CNAME and that is not the answer
-         itself, cache the CNAME, change the SNAME to the canonical name
-         in the CNAME RR and go to step 1.
-
-
-
-
-Crawford                    Standards Track                     [Page 5]
-
-RFC 2672           Non-Terminal DNS Name Redirection         August 1999
-
-
-      d. if the response shows a DNAME and that is not the answer
-         itself, cache the DNAME.  If substitution of the DNAME's
-         <target> for its <owner> in the SNAME would overflow the legal
-         size for a <domain-name>, return an implementation-dependent
-         error to the application; otherwise perform the substitution
-         and go to step 1.
-
-      e. if the response shows a server failure or other bizarre
-         contents, delete the server from the SLIST and go back to step
-         3.
-
-   A resolver or recursive server which understands DNAME records but
-   sends non-extended queries MUST augment step 4.c by deleting from the
-   reply any CNAME records which have an <owner> which is a subdomain of
-   the <owner> of any DNAME record in the response.
-
-5.  Examples of Use
-
-5.1.  Organizational Renaming
-
-   If an organization with domain name FROBOZZ.EXAMPLE became part of an
-   organization with domain name ACME.EXAMPLE, it might ease transition
-   by placing information such as this in its old zone.
-
-       frobozz.example.  DNAME    frobozz-division.acme.example.
-                         MX       10       mailhub.acme.example.
-
-   The response to an extended recursive query for www.frobozz.example
-   would contain, in the answer section, the DNAME record shown above
-   and the relevant RRs for www.frobozz-division.acme.example.
-
-5.2.  Classless Delegation of Shorter Prefixes
-
-   The classless scheme for in-addr.arpa delegation [INADDR] can be
-   extended to prefixes shorter than 24 bits by use of the DNAME record.
-   For example, the prefix 192.0.8.0/22 can be delegated by the
-   following records.
-
-       $ORIGIN 0.192.in-addr.arpa.
-       8/22    NS       ns.slash-22-holder.example.
-       8       DNAME    8.8/22
-       9       DNAME    9.8/22
-       10      DNAME    10.8/22
-       11      DNAME    11.8/22
-
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 6]
-
-RFC 2672           Non-Terminal DNS Name Redirection         August 1999
-
-
-   A typical entry in the resulting reverse zone for some host with
-   address 192.0.9.33 might be
-
-       $ORIGIN 8/22.0.192.in-addr.arpa.
-       33.9    PTR     somehost.slash-22-holder.example.
-
-   The same advisory remarks concerning the choice of the "/" character
-   apply here as in [INADDR].
-
-5.3.  Network Renumbering Support
-
-   If IPv4 network renumbering were common, maintenance of address space
-   delegation could be simplified by using DNAME records instead of NS
-   records to delegate.
-
-      $ORIGIN new-style.in-addr.arpa.
-      189.190           DNAME    in-addr.example.net.
-
-      $ORIGIN in-addr.example.net.
-      188               DNAME    in-addr.customer.example.
-
-      $ORIGIN in-addr.customer.example.
-      1                 PTR      www.customer.example.
-      2                 PTR      mailhub.customer.example.
-      ; etc ...
-
-   This would allow the address space 190.189.0.0/16 assigned to the ISP
-   "example.net" to be changed without the necessity of altering the
-   zone files describing the use of that space by the ISP and its
-   customers.
-
-   Renumbering IPv4 networks is currently so arduous a task that
-   updating the DNS is only a small part of the labor, so this scheme
-   may have a low value.  But it is hoped that in IPv6 the renumbering
-   task will be quite different and the DNAME mechanism may play a
-   useful part.
-
-6.  IANA Considerations
-
-   This document defines a new DNS Resource Record type with the
-   mnemonic DNAME and type code 39 (decimal).  The naming/numbering
-   space is defined in [DNSIS].  This name and number have already been
-   registered with the IANA.
-
-
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 7]
-
-RFC 2672           Non-Terminal DNS Name Redirection         August 1999
-
-
-7.  Security Considerations
-
-   The DNAME record is similar to the CNAME record with regard to the
-   consequences of insertion of a spoofed record into a DNS server or
-   resolver, differing in that the DNAME's effect covers a whole subtree
-   of the name space.  The facilities of [DNSSEC] are available to
-   authenticate this record type.
-
-8.  References
-
-   [DNSCF]  Mockapetris, P., "Domain names - concepts and facilities",
-            STD 13, RFC 1034, November 1987.
-
-   [DNSCLR] Elz, R. and R. Bush, "Clarifications to the DNS
-            Specification", RFC 2181, July 1997.
-
-   [DNSIS]  Mockapetris, P., "Domain names - implementation and
-            specification", STD 13, RFC 1035, November 1987.
-
-   [DNSSEC] Eastlake, 3rd, D. and C. Kaufman, "Domain Name System
-            Security Extensions", RFC 2065, January 1997.
-
-   [DNSUPD] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
-            "Dynamic Updates in the Domain Name System", RFC 2136, April
-            1997.
-
-   [EDNS0]  Vixie, P., "Extensions mechanisms for DNS (EDNS0)", RFC
-            2671, August 1999.
-
-   [INADDR] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
-            ADDR.ARPA delegation", RFC 2317, March 1998.
-
-   [KWORD]  Bradner, S., "Key words for use in RFCs to Indicate
-            Requirement Levels," BCP 14, RFC 2119, March 1997.
-
-   [SECDYN] D. Eastlake, 3rd, "Secure Domain Name System Dynamic
-            Update", RFC 2137, April 1997.
-
-9.  Author's Address
-
-   Matt Crawford
-   Fermilab MS 368
-   PO Box 500
-   Batavia, IL 60510
-   USA
-
-   Phone: +1 630 840-3461
-   EMail: crawdad@fnal.gov
-
-
-
-Crawford                    Standards Track                     [Page 8]
-
-RFC 2672           Non-Terminal DNS Name Redirection         August 1999
-
-
-10.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 9]
-
diff --git a/contrib/bind9/doc/rfc/rfc2673.txt b/contrib/bind9/doc/rfc/rfc2673.txt
deleted file mode 100644
index 19d272e..0000000
--- a/contrib/bind9/doc/rfc/rfc2673.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        M. Crawford
-Request for Comments: 2673                                      Fermilab
-Category: Standards Track                                    August 1999
-
-
-                Binary Labels in the Domain Name System
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-1.  Introduction and Terminology
-
-   This document defines a "Bit-String Label" which may appear within
-   domain names.  This new label type compactly represents a sequence of
-   "One-Bit Labels" and enables resource records to be stored at any
-   bit-boundary in a binary-named section of the domain name tree.
-
-   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 [KWORD].
-
-2.  Motivation
-
-   Binary labels are intended to efficiently solve the problem of
-   storing data and delegating authority on arbitrary boundaries when
-   the structure of underlying name space is most naturally represented
-   in binary.
-
-3.  Label Format
-
-   Up to 256 One-Bit Labels can be grouped into a single Bit-String
-   Label.  Within a Bit-String Label the most significant or "highest
-   level" bit appears first.  This is unlike the ordering of DNS labels
-   themselves, which has the least significant or "lowest level" label
-   first.  Nonetheless, this ordering seems to be the most natural and
-   efficient for representing binary labels.
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 1]
-
-RFC 2673        Binary Labels in the Domain Name System      August 1999
-
-
-   Among consecutive Bit-String Labels, the bits in the first-appearing
-   label are less significant or "at a lower level" than the bits in
-   subsequent Bit-String Labels, just as ASCII labels are ordered.
-
-3.1.  Encoding
-
-      0                   1                   2
-      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2     . . .
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+
-     |0 1|    ELT    |     Count     |           Label ...         |
-     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+
-
-   (Each tic mark represents one bit.)
-
-
-   ELT       000001 binary, the six-bit extended label type [EDNS0]
-             assigned to the Bit-String Label.
-
-   Count     The number of significant bits in the Label field.  A Count
-             value of zero indicates that 256 bits are significant.
-             (Thus the null label representing the DNS root cannot be
-             represented as a Bit String Label.)
-
-   Label     The bit string representing a sequence of One-Bit Labels,
-             with the most significant bit first.  That is, the One-Bit
-             Label in position 17 in the diagram above represents a
-             subdomain of the domain represented by the One-Bit Label in
-             position 16, and so on.
-
-             The Label field is padded on the right with zero to seven
-             pad bits to make the entire field occupy an integral number
-             of octets.  These pad bits MUST be zero on transmission and
-             ignored on reception.
-
-   A sequence of bits may be split into two or more Bit-String Labels,
-   but the division points have no significance and need not be
-   preserved.  An excessively clever server implementation might split
-   Bit-String Labels so as to maximize the effectiveness of message
-   compression [DNSIS].  A simpler server might divide Bit-String Labels
-   at zone boundaries, if any zone boundaries happen to fall between
-   One-Bit Labels.
-
-3.2.  Textual Representation
-
-   A Bit-String Label is represented in text -- in a zone file, for
-   example -- as a <bit-spec> surrounded by the delimiters "\[" and "]".
-   The <bit-spec> is either a dotted quad or a base indicator and a
-   sequence of digits appropriate to that base, optionally followed by a
-
-
-
-Crawford                    Standards Track                     [Page 2]
-
-RFC 2673        Binary Labels in the Domain Name System      August 1999
-
-
-   slash and a length.  The base indicators are "b", "o" and "x",
-   denoting base 2, 8 and 16 respectively.  The length counts the
-   significant bits and MUST be between 1 and 32, inclusive, after a
-   dotted quad, or between 1 and 256, inclusive, after one of the other
-   forms.  If the length is omitted, the implicit length is 32 for a
-   dotted quad or 1, 3 or 4 times the number of binary, octal or
-   hexadecimal digits supplied, respectively, for the other forms.
-
-   In augmented Backus-Naur form [ABNF],
-
-     bit-string-label =  "\[" bit-spec "]"
-
-     bit-spec         =  bit-data [ "/" length ]
-                       / dotted-quad [ "/" slength ]
-
-     bit-data         =  "x" 1*64HEXDIG
-                       / "o" 1*86OCTDIG
-                       / "b" 1*256BIT
-
-     dotted-quad      =  decbyte "." decbyte "." decbyte "." decbyte
-
-     decbyte          =  1*3DIGIT
-
-     length           =  NZDIGIT *2DIGIT
-
-     slength          =  NZDIGIT [ DIGIT ]
-
-     OCTDIG           =  %x30-37
-
-     NZDIGIT          =  %x31-39
-
-   If a <length> is present, the number of digits in the <bit-data> MUST
-   be just sufficient to contain the number of bits specified by the
-   <length>.  If there are insignificant bits in a final hexadecimal or
-   octal digit, they MUST be zero.  A <dotted-quad> always has all four
-   parts even if the associated <slength> is less than 24, but, like the
-   other forms, insignificant bits MUST be zero.
-
-   Each number represented by a <decbyte> must be between 0 and 255,
-   inclusive.
-
-   The number represented by <length> must be between 1 and 256
-   inclusive.
-
-   The number represented by <slength> must be between 1 and 32
-   inclusive.
-
-
-
-
-
-Crawford                    Standards Track                     [Page 3]
-
-RFC 2673        Binary Labels in the Domain Name System      August 1999
-
-
-   When the textual form of a Bit-String Label is generated by machine,
-   the length SHOULD be explicit, not implicit.
-
-3.2.1.  Examples
-
-   The following four textual forms represent the same Bit-String Label.
-
-                             \[b11010000011101]
-                             \[o64072/14]
-                             \[xd074/14]
-                             \[208.116.0.0/14]
-
-   The following represents two consecutive Bit-String Labels which
-   denote the same relative point in the DNS tree as any of the above
-   single Bit-String Labels.
-
-                             \[b11101].\[o640]
-
-3.3.  Canonical Representation and Sort Order
-
-   Both the wire form and the text form of binary labels have a degree
-   of flexibility in their grouping into multiple consecutive Bit-String
-   Labels.  For generating and checking DNS signature records [DNSSEC]
-   binary labels must be in a predictable form.  This canonical form is
-   defined as the form which has the fewest possible Bit-String Labels
-   and in which all except possibly the first (least significant) label
-   in any sequence of consecutive Bit-String Labels is of maximum
-   length.
-
-   For example, the canonical form of any sequence of up to 256 One-Bit
-   Labels has a single Bit-String Label, and the canonical form of a
-   sequence of 513 to 768 One-Bit Labels has three Bit-String Labels of
-   which the second and third contain 256 label bits.
-
-   The canonical sort order of domain names [DNSSEC] is extended to
-   encompass binary labels as follows.  Sorting is still label-by-label,
-   from most to least significant, where a label may now be a One-Bit
-   Label or a standard (code 00) label.  Any One-Bit Label sorts before
-   any standard label, and a 0 bit sorts before a 1 bit.  The absence of
-   a label sorts before any label, as specified in [DNSSEC].
-
-
-
-
-
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 4]
-
-RFC 2673        Binary Labels in the Domain Name System      August 1999
-
-
-   For example, the following domain names are correctly sorted.
-
-                         foo.example
-                         \[b1].foo.example
-                         \[b100].foo.example
-                         \[b101].foo.example
-                         bravo.\[b10].foo.example
-                         alpha.foo.example
-
-4.  Processing Rules
-
-   A One-Bit Label never matches any other kind of label.  In
-   particular, the DNS labels represented by the single ASCII characters
-   "0" and "1" do not match One-Bit Labels represented by the bit values
-   0 and 1.
-
-5.  Discussion
-
-   A Count of zero in the wire-form represents a 256-bit sequence, not
-   to optimize that particular case, but to make it completely
-   impossible to have a zero-bit label.
-
-6.  IANA Considerations
-
-   This document defines one Extended Label Type, termed the Bit-String
-   Label, and requests registration of the code point 000001 binary in
-   the space defined by [EDNS0].
-
-7.  Security Considerations
-
-   All security considerations which apply to traditional ASCII DNS
-   labels apply equally to binary labels.  he canonicalization and
-   sorting rules of section 3.3 allow these to be addressed by DNS
-   Security [DNSSEC].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 5]
-
-RFC 2673        Binary Labels in the Domain Name System      August 1999
-
-
-8.  References
-
-   [ABNF]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
-            Specifications: ABNF", RFC 2234, November 1997.
-
-   [DNSIS]  Mockapetris, P., "Domain names - implementation and
-            specification", STD 13, RFC 1035, November 1987.
-
-   [DNSSEC] Eastlake, D., 3rd, C. Kaufman, "Domain Name System Security
-            Extensions", RFC 2065, January 1997
-
-   [EDNS0]  Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC 2671,
-            August 1999.
-
-   [KWORD]  Bradner, S., "Key words for use in RFCs to Indicate
-            Requirement Levels," BCP 14, RFC 2119, March 1997.
-
-9.  Author's Address
-
-   Matt Crawford
-   Fermilab MS 368
-   PO Box 500
-   Batavia, IL 60510
-   USA
-
-   Phone: +1 630 840-3461
-   EMail: crawdad@fnal.gov
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 6]
-
-RFC 2673        Binary Labels in the Domain Name System      August 1999
-
-
-10.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crawford                    Standards Track                     [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc2782.txt b/contrib/bind9/doc/rfc/rfc2782.txt
deleted file mode 100644
index 1827f10..0000000
--- a/contrib/bind9/doc/rfc/rfc2782.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                     A. Gulbrandsen
-Request for Comments: 2782                            Troll Technologies
-Obsoletes: 2052                                                 P. Vixie
-Category: Standards Track                   Internet Software Consortium
-                                                               L. Esibov
-                                                         Microsoft Corp.
-                                                           February 2000
-
-
-       A DNS RR for specifying the location of services (DNS SRV)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   This document describes a DNS RR which specifies the location of the
-   server(s) for a specific protocol and domain.
-
-Overview and rationale
-
-   Currently, one must either know the exact address of a server to
-   contact it, or broadcast a question.
-
-   The SRV RR allows administrators to use several servers for a single
-   domain, to move services from host to host with little fuss, and to
-   designate some hosts as primary servers for a service and others as
-   backups.
-
-   Clients ask for a specific service/protocol for a specific domain
-   (the word domain is used here in the strict RFC 1034 sense), and get
-   back the names of any available servers.
-
-   Note that where this document refers to "address records", it means A
-   RR's, AAAA RR's, or their most modern equivalent.
-
-
-
-
-
-
-
-Gulbrandsen, et al.         Standards Track                     [Page 1]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-Definitions
-
-   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY"
-   used in this document are to be interpreted as specified in [BCP 14].
-   Other terms used in this document are defined in the DNS
-   specification, RFC 1034.
-
-Applicability Statement
-
-   In general, it is expected that SRV records will be used by clients
-   for applications where the relevant protocol specification indicates
-   that clients should use the SRV record. Such specification MUST
-   define the symbolic name to be used in the Service field of the SRV
-   record as described below. It also MUST include security
-   considerations. Service SRV records SHOULD NOT be used in the absence
-   of such specification.
-
-Introductory example
-
-   If a SRV-cognizant LDAP client wants to discover a LDAP server that
-   supports TCP protocol and provides LDAP service for the domain
-   example.com., it does a lookup of
-
-      _ldap._tcp.example.com
-
-   as described in [ARM].  The example zone file near the end of this
-   memo contains answering RRs for an SRV query.
-
-   Note: LDAP is chosen as an example for illustrative purposes only,
-   and the LDAP examples used in this document should not be considered
-   a definitive statement on the recommended way for LDAP to use SRV
-   records. As described in the earlier applicability section, consult
-   the appropriate LDAP documents for the recommended procedures.
-
-The format of the SRV RR
-
-   Here is the format of the SRV RR, whose DNS type code is 33:
-
-        _Service._Proto.Name TTL Class SRV Priority Weight Port Target
-
-        (There is an example near the end of this document.)
-
-   Service
-        The symbolic name of the desired service, as defined in Assigned
-        Numbers [STD 2] or locally.  An underscore (_) is prepended to
-        the service identifier to avoid collisions with DNS labels that
-        occur in nature.
-
-
-
-
-Gulbrandsen, et al.         Standards Track                     [Page 2]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-        Some widely used services, notably POP, don't have a single
-        universal name.  If Assigned Numbers names the service
-        indicated, that name is the only name which is legal for SRV
-        lookups.  The Service is case insensitive.
-
-   Proto
-        The symbolic name of the desired protocol, with an underscore
-        (_) prepended to prevent collisions with DNS labels that occur
-        in nature.  _TCP and _UDP are at present the most useful values
-        for this field, though any name defined by Assigned Numbers or
-        locally may be used (as for Service).  The Proto is case
-        insensitive.
-
-   Name
-        The domain this RR refers to.  The SRV RR is unique in that the
-        name one searches for is not this name; the example near the end
-        shows this clearly.
-
-   TTL
-        Standard DNS meaning [RFC 1035].
-
-   Class
-        Standard DNS meaning [RFC 1035].   SRV records occur in the IN
-        Class.
-
-   Priority
-        The priority of this target host.  A client MUST attempt to
-        contact the target host with the lowest-numbered priority it can
-        reach; target hosts with the same priority SHOULD be tried in an
-        order defined by the weight field.  The range is 0-65535.  This
-        is a 16 bit unsigned integer in network byte order.
-
-   Weight
-        A server selection mechanism.  The weight field specifies a
-        relative weight for entries with the same priority. Larger
-        weights SHOULD be given a proportionately higher probability of
-        being selected. The range of this number is 0-65535.  This is a
-        16 bit unsigned integer in network byte order.  Domain
-        administrators SHOULD use Weight 0 when there isn't any server
-        selection to do, to make the RR easier to read for humans (less
-        noisy).  In the presence of records containing weights greater
-        than 0, records with weight 0 should have a very small chance of
-        being selected.
-
-        In the absence of a protocol whose specification calls for the
-        use of other weighting information, a client arranges the SRV
-        RRs of the same Priority in the order in which target hosts,
-
-
-
-
-Gulbrandsen, et al.         Standards Track                     [Page 3]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-        specified by the SRV RRs, will be contacted. The following
-        algorithm SHOULD be used to order the SRV RRs of the same
-        priority:
-
-        To select a target to be contacted next, arrange all SRV RRs
-        (that have not been ordered yet) in any order, except that all
-        those with weight 0 are placed at the beginning of the list.
-
-        Compute the sum of the weights of those RRs, and with each RR
-        associate the running sum in the selected order. Then choose a
-        uniform random number between 0 and the sum computed
-        (inclusive), and select the RR whose running sum value is the
-        first in the selected order which is greater than or equal to
-        the random number selected. The target host specified in the
-        selected SRV RR is the next one to be contacted by the client.
-        Remove this SRV RR from the set of the unordered SRV RRs and
-        apply the described algorithm to the unordered SRV RRs to select
-        the next target host.  Continue the ordering process until there
-        are no unordered SRV RRs.  This process is repeated for each
-        Priority.
-
-   Port
-        The port on this target host of this service.  The range is 0-
-        65535.  This is a 16 bit unsigned integer in network byte order.
-        This is often as specified in Assigned Numbers but need not be.
-
-   Target
-        The domain name of the target host.  There MUST be one or more
-        address records for this name, the name MUST NOT be an alias (in
-        the sense of RFC 1034 or RFC 2181).  Implementors are urged, but
-        not required, to return the address record(s) in the Additional
-        Data section.  Unless and until permitted by future standards
-        action, name compression is not to be used for this field.
-
-        A Target of "." means that the service is decidedly not
-        available at this domain.
-
-Domain administrator advice
-
-   Expecting everyone to update their client applications when the first
-   server publishes a SRV RR is futile (even if desirable).  Therefore
-   SRV would have to coexist with address record lookups for existing
-   protocols, and DNS administrators should try to provide address
-   records to support old clients:
-
-      - Where the services for a single domain are spread over several
-        hosts, it seems advisable to have a list of address records at
-        the same DNS node as the SRV RR, listing reasonable (if perhaps
-
-
-
-Gulbrandsen, et al.         Standards Track                     [Page 4]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-        suboptimal) fallback hosts for Telnet, NNTP and other protocols
-        likely to be used with this name.  Note that some programs only
-        try the first address they get back from e.g. gethostbyname(),
-        and we don't know how widespread this behavior is.
-
-      - Where one service is provided by several hosts, one can either
-        provide address records for all the hosts (in which case the
-        round-robin mechanism, where available, will share the load
-        equally) or just for one (presumably the fastest).
-
-      - If a host is intended to provide a service only when the main
-        server(s) is/are down, it probably shouldn't be listed in
-        address records.
-
-      - Hosts that are referenced by backup address records must use the
-        port number specified in Assigned Numbers for the service.
-
-      - Designers of future protocols for which "secondary servers" is
-        not useful (or meaningful) may choose to not use SRV's support
-        for secondary servers.  Clients for such protocols may use or
-        ignore SRV RRs with Priority higher than the RR with the lowest
-        Priority for a domain.
-
-   Currently there's a practical limit of 512 bytes for DNS replies.
-   Until all resolvers can handle larger responses, domain
-   administrators are strongly advised to keep their SRV replies below
-   512 bytes.
-
-   All round numbers, wrote Dr. Johnson, are false, and these numbers
-   are very round: A reply packet has a 30-byte overhead plus the name
-   of the service ("_ldap._tcp.example.com" for instance); each SRV RR
-   adds 20 bytes plus the name of the target host; each NS RR in the NS
-   section is 15 bytes plus the name of the name server host; and
-   finally each A RR in the additional data section is 20 bytes or so,
-   and there are A's for each SRV and NS RR mentioned in the answer.
-   This size estimate is extremely crude, but shouldn't underestimate
-   the actual answer size by much.  If an answer may be close to the
-   limit, using a DNS query tool (e.g. "dig") to look at the actual
-   answer is a good idea.
-
-The "Weight" field
-
-   Weight, the server selection field, is not quite satisfactory, but
-   the actual load on typical servers changes much too quickly to be
-   kept around in DNS caches.  It seems to the authors that offering
-   administrators a way to say "this machine is three times as fast as
-   that one" is the best that can practically be done.
-
-
-
-
-Gulbrandsen, et al.         Standards Track                     [Page 5]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-   The only way the authors can see of getting a "better" load figure is
-   asking a separate server when the client selects a server and
-   contacts it.  For short-lived services an extra step in the
-   connection establishment seems too expensive, and for long-lived
-   services, the load figure may well be thrown off a minute after the
-   connection is established when someone else starts or finishes a
-   heavy job.
-
-   Note: There are currently various experiments at providing relative
-   network proximity estimation, available bandwidth estimation, and
-   similar services.  Use of the SRV record with such facilities, and in
-   particular the interpretation of the Weight field when these
-   facilities are used, is for further study.  Weight is only intended
-   for static, not dynamic, server selection.  Using SRV weight for
-   dynamic server selection would require assigning unreasonably short
-   TTLs to the SRV RRs, which would limit the usefulness of the DNS
-   caching mechanism, thus increasing overall network load and
-   decreasing overall reliability.  Server selection via SRV is only
-   intended to express static information such as "this server has a
-   faster CPU than that one" or "this server has a much better network
-   connection than that one".
-
-The Port number
-
-   Currently, the translation from service name to port number happens
-   at the client, often using a file such as /etc/services.
-
-   Moving this information to the DNS makes it less necessary to update
-   these files on every single computer of the net every time a new
-   service is added, and makes it possible to move standard services out
-   of the "root-only" port range on unix.
-
-Usage rules
-
-   A SRV-cognizant client SHOULD use this procedure to locate a list of
-   servers and connect to the preferred one:
-
-        Do a lookup for QNAME=_service._protocol.target, QCLASS=IN,
-        QTYPE=SRV.
-
-        If the reply is NOERROR, ANCOUNT>0 and there is at least one
-        SRV RR which specifies the requested Service and Protocol in
-        the reply:
-
-            If there is precisely one SRV RR, and its Target is "."
-            (the root domain), abort.
-
-
-
-
-
-Gulbrandsen, et al.         Standards Track                     [Page 6]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-            Else, for all such RR's, build a list of (Priority, Weight,
-            Target) tuples
-
-            Sort the list by priority (lowest number first)
-
-            Create a new empty list
-
-            For each distinct priority level
-                While there are still elements left at this priority
-                level
-
-                    Select an element as specified above, in the
-                    description of Weight in "The format of the SRV
-                    RR" Section, and move it to the tail of the new
-                    list
-
-            For each element in the new list
-
-                query the DNS for address records for the Target or
-                use any such records found in the Additional Data
-                section of the earlier SRV response.
-
-                for each address record found, try to connect to the
-               (protocol, address, service).
-
-        else
-
-            Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
-
-            for each address record found, try to connect to the
-           (protocol, address, service)
-
-Notes:
-
-   - Port numbers SHOULD NOT be used in place of the symbolic service
-     or protocol names (for the same reason why variant names cannot
-     be allowed: Applications would have to do two or more lookups).
-
-   - If a truncated response comes back from an SRV query, the rules
-     described in [RFC 2181] shall apply.
-
-   - A client MUST parse all of the RR's in the reply.
-
-   - If the Additional Data section doesn't contain address records
-     for all the SRV RR's and the client may want to connect to the
-     target host(s) involved, the client MUST look up the address
-     record(s).  (This happens quite often when the address record
-     has shorter TTL than the SRV or NS RR's.)
-
-
-
-Gulbrandsen, et al.         Standards Track                     [Page 7]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-   - Future protocols could be designed to use SRV RR lookups as the
-     means by which clients locate their servers.
-
-Fictional example
-
-   This example uses fictional service "foobar" as an aid in
-   understanding SRV records. If ever service "foobar" is implemented,
-   it is not intended that it will necessarily use SRV records.  This is
-   (part of) the zone file for example.com, a still-unused domain:
-
-      $ORIGIN example.com.
-      @               SOA server.example.com. root.example.com. (
-                          1995032001 3600 3600 604800 86400 )
-                      NS  server.example.com.
-                      NS  ns1.ip-provider.net.
-                      NS  ns2.ip-provider.net.
-      ; foobar - use old-slow-box or new-fast-box if either is
-      ; available, make three quarters of the logins go to
-      ; new-fast-box.
-      _foobar._tcp    SRV 0 1 9 old-slow-box.example.com.
-                       SRV 0 3 9 new-fast-box.example.com.
-      ; if neither old-slow-box or new-fast-box is up, switch to
-      ; using the sysdmin's box and the server
-                       SRV 1 0 9 sysadmins-box.example.com.
-                       SRV 1 0 9 server.example.com.
-      server           A   172.30.79.10
-      old-slow-box     A   172.30.79.11
-      sysadmins-box    A   172.30.79.12
-      new-fast-box     A   172.30.79.13
-      ; NO other services are supported
-      *._tcp          SRV  0 0 0 .
-      *._udp          SRV  0 0 0 .
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gulbrandsen, et al.         Standards Track                     [Page 8]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-   In this example, a client of the "foobar" service in the
-   "example.com." domain needs an SRV lookup of
-   "_foobar._tcp.example.com." and possibly A lookups of "new-fast-
-   box.example.com." and/or the other hosts named.  The size of the SRV
-   reply is approximately 365 bytes:
-
-      30 bytes general overhead
-      20 bytes for the query string, "_foobar._tcp.example.com."
-      130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of "new-
-        fast-box", "old-slow-box", "server" and "sysadmins-box" -
-        "example.com" in the query section is quoted here and doesn't
-        need to be counted again.
-      75 bytes for 3 NS RRs, 15 bytes each plus the lengths of "server",
-        "ns1.ip-provider.net." and "ns2" - again, "ip-provider.net." is
-        quoted and only needs to be counted once.
-      120 bytes for the 6 address records (assuming IPv4 only) mentioned
-        by the SRV and NS RR's.
-
-IANA Considerations
-
-   The IANA has assigned RR type value 33 to the SRV RR.  No other IANA
-   services are required by this document.
-
-Changes from RFC 2052
-
-   This document obsoletes RFC 2052.   The major change from that
-   previous, experimental, version of this specification is that now the
-   protocol and service labels are prepended with an underscore, to
-   lower the probability of an accidental clash with a similar name used
-   for unrelated purposes.  Aside from that, changes are only intended
-   to increase the clarity and completeness of the document. This
-   document especially clarifies the use of the Weight field of the SRV
-   records.
-
-Security Considerations
-
-   The authors believe this RR to not cause any new security problems.
-   Some problems become more visible, though.
-
-   - The ability to specify ports on a fine-grained basis obviously
-     changes how a router can filter packets.  It becomes impossible
-     to block internal clients from accessing specific external
-     services, slightly harder to block internal users from running
-     unauthorized services, and more important for the router
-     operations and DNS operations personnel to cooperate.
-
-   - There is no way a site can keep its hosts from being referenced
-     as servers.  This could lead to denial of service.
-
-
-
-Gulbrandsen, et al.         Standards Track                     [Page 9]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-   - With SRV, DNS spoofers can supply false port numbers, as well as
-     host names and addresses.   Because this vulnerability exists
-     already, with names and addresses, this is not a new
-     vulnerability, merely a slightly extended one, with little
-     practical effect.
-
-References
-
-   STD 2:    Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
-             1700, October 1994.
-
-   RFC 1034: Mockapetris, P., "Domain names - concepts and facilities",
-             STD 13, RFC 1034, November 1987.
-
-   RFC 1035: Mockapetris, P., "Domain names - Implementation and
-             Specification", STD 13, RFC 1035, November 1987.
-
-   RFC 974:  Partridge, C., "Mail routing and the domain system", STD
-             14, RFC 974, January 1986.
-
-   BCP 14:   Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   RFC 2181: Elz, R. and R. Bush, "Clarifications to the DNS
-             Specification", RFC 2181, July 1997.
-
-   RFC 2219: Hamilton, M. and R. Wright, "Use of DNS Aliases for Network
-             Services", BCP 17, RFC 2219, October 1997.
-
-   BCP 14:   Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   ARM:      Armijo, M., Esibov, L. and P. Leach, "Discovering LDAP
-             Services with DNS", Work in Progress.
-
-   KDC-DNS:  Hornstein, K. and J. Altman, "Distributing Kerberos KDC and
-             Realm Information with DNS", Work in Progress.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gulbrandsen, et al.         Standards Track                    [Page 10]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-Acknowledgements
-
-   The algorithm used to select from the weighted SRV RRs of equal
-   priority is adapted from one supplied by Dan Bernstein.
-
-Authors' Addresses
-
-   Arnt Gulbrandsen
-   Troll Tech
-   Waldemar Thranes gate 98B
-   N-0175 Oslo, Norway
-
-   Fax:   +47 22806380
-   Phone: +47 22806390
-   EMail: arnt@troll.no
-
-
-   Paul Vixie
-   Internet Software Consortium
-   950 Charter Street
-   Redwood City, CA 94063
-
-   Phone: +1 650 779 7001
-
-
-   Levon Esibov
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA 98052
-
-   EMail: levone@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gulbrandsen, et al.         Standards Track                    [Page 11]
-
-RFC 2782                       DNS SRV RR                  February 2000
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gulbrandsen, et al.         Standards Track                    [Page 12]
-
diff --git a/contrib/bind9/doc/rfc/rfc2825.txt b/contrib/bind9/doc/rfc/rfc2825.txt
deleted file mode 100644
index fd8ef7c..0000000
--- a/contrib/bind9/doc/rfc/rfc2825.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-

-

-

-

-

-

-Network Working Group                  Internet Architecture Board (IAB)

-Request for Comments: 2825                             L. Daigle, Editor

-Category: Informational                                         May 2000

-

-

-         A Tangled Web: Issues of I18N, Domain Names, and the

-                        Other Internet protocols

-

-Status of this Memo

-

-   This memo provides information for the Internet community.  It does

-   not specify an Internet standard of any kind.  Distribution of this

-   memo is unlimited.

-

-Copyright Notice

-

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

-

-Abstract

-

-   The goals of the work to "internationalize" Internet protocols

-   include providing all users of the Internet with the capability of

-   using their own language and its standard character set to express

-   themselves, write names, and to navigate the network. This impacts

-   the domain names visible in e-mail addresses and so many of today's

-   URLs used to locate information on the World Wide Web, etc.  However,

-   domain names are used by Internet protocols that are used across

-   national boundaries. These services must interoperate worldwide, or

-   we risk isolating components of the network from each other along

-   locale boundaries.  This type of isolation could impede not only

-   communications among people, but opportunities of the areas involved

-   to participate effectively in e-commerce, distance learning, and

-   other activities at an international scale, thereby retarding

-   economic development.

-

-   There are several proposals for internationalizing domain names,

-   however it it is still to be determined whether any of them will

-   ensure this interoperability and global reach while addressing

-   visible-name representation.  Some of them obviously do not. This

-   document does not attempt to review any specific proposals, as that

-   is the work of the Internationalized Domain Name (IDN) Working Group

-   of the IETF, which is tasked with evaluating them in consideration of

-   the continued global network interoperation that is the deserved

-   expectation of all Internet users.

-

-

-

-

-

-

-

-IAB                          Informational                      [Page 1]

-

-RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000

-

-

-   This document is a statement by the Internet Architecture Board. It

-   is not a protocol specification, but an attempt to clarify the range

-   of architectural issues that the internationalization of domain names

-   faces.

-

-1. A Definition of Success

-

-   The Internationalized Domain Names (IDN) Working Group is one

-   component of the IETF's continuing comprehensive effort to

-   internationalize language representation facilities in the protocols

-   that support the global functioning of the Internet.

-

-   In keeping with the principles of rough consensus, running code,

-   architectural integrity, and in the interest of ensuring the global

-   stability of the Internet, the IAB emphasizes that all solutions

-   proposed to the (IDN) Working Group will have to be evaluated not

-   only on their individual technical features, but also in terms of

-   impact on existing standards and operations of the Internet and the

-   total effect for end-users: solutions must not cause users to become

-   more isolated from their global neighbors even if they appear to

-   solve a local problem.  In some cases, existing protocols have

-   limitations on allowable characters, and in other cases

-   implementations of protocols used in the core of the Internet (beyond

-   individual organizations) have in practice not implemented all the

-   requisite options of the standards.

-

-2. Technical Challenges within the Domain Name System (DNS)

-

-   In many technical respects, the IDN work is not different from any

-   other effort to enable multiple character set representations in

-   textual elements that were traditionally restricted to English

-   language characters.

-

-   One aspect of the challenge is to decide how to represent the names

-   users want in the DNS in a way that is clear, technically feasible,

-   and ensures that a name always means the same thing.  Several

-   proposals have been suggested to address these issues.

-

-   These issues are being outlined in more detail in the IDN WG's

-   evolving draft requirements document; further discussion is deferred

-   to the WG and its documents.

-

-3. Integrating with Current Realities

-

-   Nevertheless, issues faced by the IDN working group are complex and

-   intricately intertwined with other operational components of the

-   Internet.  A key challenge in evaluating any proposed solution is the

-   analysis of the impact on existing critical operational standards

-

-

-

-IAB                          Informational                      [Page 2]

-

-RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000

-

-

-   which use fully-qualified domain names [RFC1034], or simply host

-   names [RFC1123].  Standards-changes can be effected, but the best

-   path forward is one that takes into account current realities and

-   (re)deployment latencies. In the Internet's global context, it is not

-   enough to update a few isolated systems, or even most of the systems

-   in a country or region.  Deployment must be nearly universal in order

-   to avoid the creation of "islands" of interoperation that provide

-   users with less access to and connection from the rest of the world.

-

-   These are not esoteric or ephemeral concerns.  Some specific issues

-   have already been identified as part of the IDN WG's efforts.  These

-   include (but are not limited to) the following examples.

-

-3.1 Domain Names and E-mail

-

-   As indicated in the IDN WG's draft requirements document, the issue

-   goes beyond standardization of DNS usage.  Electronic mail has long

-   been one of the most-used and most important applications of the

-   Internet.  Internet e-mail is also used as the bridge that permits

-   the users of a variety of local and proprietary mail systems to

-   communicate. The standard protocols that define its use (e.g., SMTP

-   [RFC821, RFC822] and MIME [RFC2045]) do not permit the full range of

-   characters allowed in the DNS specification. Certain characters are

-   not allowed in e-mail address domain portions of these

-   specifications.  Some mailers, built to adhere to these

-   specifications, are known to fail when on mail having non-ASCII

-   domain names in its address -- by discarding, misrouting or damaging

-   the mail.  Thus, it's not possible to simply switch to

-   internationalized domain names and expect global e-mail to continue

-   to work until most of the servers in the world are upgraded.

-

-3.2 Domain Names and Routing

-

-   At a lower level, the Routing Policy Specification Language (RPLS)

-   [RFC2622] makes use of "named objects" -- and inherits object naming

-   restrictions from older standards ([RFC822] for the same e-mail

-   address restrictions, [RFC1034] for hostnames).  This means that

-   until routing registries and their protocols are updated, it is not

-   possible to enter or retrieve network descriptions utilizing

-   internationalized domain names.

-

-3.3 Domain Names and Network Management

-

-   Also, the Simple Network Management Protocol (SNMP) uses the textual

-   representation defined in [RFC2579].  While that specification does

-   allow for UTF-8-based domain names, an informal survey of deployed

-   implementations of software libraries being used to build SNMP-

-   compliant software uncovered the fact that few (if any) implement it.

-

-

-

-IAB                          Informational                      [Page 3]

-

-RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000

-

-

-   This may cause inability to enter or display correct data in network

-   management tools, if such names are internationalized domain names.

-

-3.4 Domain Names and Security

-

-   Critical components of Internet public key technologies (PKIX,

-   [RFC2459], IKE [RFC2409]) rely heavily on identification of servers

-   (hostnames, or fully qualified domain names) and users (e-mail

-   addresses).  Failure to respect the character restrictions in these

-   protocols will impact security tools built to use them -- Transport

-   Layer Security protocol (TLS, [RFC2246]), and IPsec [RFC2401] to name

-   two.

-

-   Failure may not be obvious.  For example, in TLS, it is common usage

-   for a server to display a certificate containing a domain name

-   purporting to be the domain name of the server, which the client can

-   then match with the server name he thought he used to reach the

-   service.

-

-   Unless comparison of domain names is properly defined, the client may

-   either fail to match the domain name of a legitimate server, or match

-   incorrectly the domain name of a server performing a man-in-the-

-   middle attack.  Either failure could enable attacks on systems that

-   are now impossible or at least far more difficult.

-

-4. Conclusion

-

-   It is therefore clear that, although there are many possible ways to

-   assign internationalized names that are compatible with today's DNS

-   (or a version that is easily-deployable in the near future), not all

-   of them are compatible with the full range of necessary networking

-   tools.  When designing a solution for internationalization of domain

-   names, the effects on the current Internet must be carefully

-   evaluated. Some types of solutions proposed would, if put into effect

-   immediately, cause Internet communications to fail in ways that would

-   be hard to detect by and pose problems for those who deploy the new

-   services, but also for those who do not; this would have the effect

-   of cutting those who deploy them off from effective use of the

-   Internet.

-

-   The IDN WG has been identified as the appropriate forum for

-   identifying and discussing solutions for such potential

-   interoperability issues.

-

-   Experience with deployment of other protocols has indicated that it

-   will take years before a new protocol or enhancement is used all over

-   the Internet.  So far, the IDN WG has benefited from proposed

-   solutions from all quarters, including organizations hoping to

-

-

-

-IAB                          Informational                      [Page 4]

-

-RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000

-

-

-   provide services that address visible-name representation and

-   registration -- continuing this process with the aim of getting a

-   single, scalable and deployable solution to this problem is the only

-   way to ensure the continued global interoperation that is the

-   deserved expectation of all Internet users.

-

-5. Security Considerations

-

-   In general, assignment and use of names does not raise any special

-   security problems.  However, as noted above, some existing security

-   mechanisms are reliant on the current specification of domain names

-   and may not be expected to work, as is, with Internationalized domain

-   names.  Additionally, deployment of non-standard systems (e.g., in

-   response to current pressures to address national or regional

-   characterset representation) might result in name strings that are

-   not globally unique, thereby opening up the possibility of "spoofing"

-   hosts from one domain in another, as described in [RFC2826].

-

-6. Acknowledgements

-

-   This document is the outcome of the joint effort of the members of

-   the IAB.  Additionally, valuable remarks were provided by Randy Bush,

-   Patrik Faltstrom, Ted Hardie, Paul Hoffman, and Mark Kosters.

-

-7. References

-

-   [RFC821]  Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC

-             821, August 1982.

-

-   [RFC822]  Crocker, D., "Standard for the Format of ARPA Internet Text

-             Messages", STD 11, RFC 822, August 1982.

-

-   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",

-             STD 13, RFC 1034, November 1987.

-

-   [RFC1123] Braden, R., "Requirements for Internet Hosts -- Application

-             and Support", STD 3, RFC 1123, November 1989.

-

-   [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the

-             Internet Protocol", RFC 2401, November 1998.

-

-   [RFC2409] Harkins, D and D. Carrel, "The Internet Key Exchange

-             (IKE)", RFC 2409, November 1998.

-

-   [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail

-             Extensions (MIME) Part One:  Format of Internet Message

-             Bodies", RFC 2045, November 1996.

-

-

-

-

-IAB                          Informational                      [Page 5]

-

-RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000

-

-

-   [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",

-             RFC 2246, January 1999.

-

-   [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet

-             X.509 Public Key Infrastructure Certificate and CRL

-             Profile", RFC 2459, January 1999.

-

-   [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.

-             and M. Rose, "Textual Conventions for SMIv2", RFC 2579,

-             April 1999.

-

-   [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,

-             Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra,

-             "Routing Policy Specification Language (RPSL)", RFC 2622,

-             June 1999.

-

-   [RFC2826] IAB, "IAB Technical Comment on the Unique DNS Root", RFC

-             2826, May 2000.

-

-8. Author's Address

-

-   Internet Architecture Board

-

-   EMail:  iab@iab.org

-

-

-   Membership at time this document was completed:

-

-      Harald Alvestrand

-      Ran Atkinson

-      Rob Austein

-      Brian Carpenter

-      Steve Bellovin

-      Jon Crowcroft

-      Leslie Daigle

-      Steve Deering

-      Tony Hain

-      Geoff Huston

-      John Klensin

-      Henning Schulzrinne

-

-

-

-

-

-

-

-

-

-

-

-IAB                          Informational                      [Page 6]

-

-RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000

-

-

-9. Full Copyright Statement

-

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

-

-   This document and translations of it may be copied and furnished to

-   others, and derivative works that comment on or otherwise explain it

-   or assist in its 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.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-IAB                          Informational                      [Page 7]

-

diff --git a/contrib/bind9/doc/rfc/rfc2826.txt b/contrib/bind9/doc/rfc/rfc2826.txt
deleted file mode 100644
index b4d8869..0000000
--- a/contrib/bind9/doc/rfc/rfc2826.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-

-

-

-

-

-

-Network Working Group                        Internet Architecture Board

-Request for Comments: 2826                                      May 2000

-Category: Informational

-

-

-              IAB Technical Comment on the Unique DNS Root

-

-Status of this Memo

-

-   This memo provides information for the Internet community.  It does

-   not specify an Internet standard of any kind.  Distribution of this

-   memo is unlimited.

-

-Copyright Notice

-

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

-

-Summary

-

-   To remain a global network, the Internet requires the existence of a

-   globally unique public name space.  The DNS name space is a

-   hierarchical name space derived from a single, globally unique root.

-   This is a technical constraint inherent in the design of the DNS.

-   Therefore it is not technically feasible for there to be more than

-   one root in the public DNS.  That one root must be supported by a set

-   of coordinated root servers administered by a unique naming

-   authority.

-

-   Put simply, deploying multiple public DNS roots would raise a very

-   strong possibility that users of different ISPs who click on the same

-   link on a web page could end up at different destinations, against

-   the will of the web page designers.

-

-   This does not preclude private networks from operating their own

-   private name spaces, but if they wish to make use of names uniquely

-   defined for the global Internet, they have to fetch that information

-   from the global DNS naming hierarchy, and in particular from the

-   coordinated root servers of the global DNS naming hierarchy.

-

-1.  Detailed Explanation

-

-   There are several distinct reasons why the DNS requires a single root

-   in order to operate properly.

-

-1.1.  Maintenance of a Common Symbol Set

-

-   Effective communications between two parties requires two essential

-   preconditions:

-

-

-

-IAB                          Informational                      [Page 1]

-

-RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000

-

-

-   -  The existence of a common symbol set, and

-

-   -  The existence of a common semantic interpretation of these

-      symbols.

-

-   Failure to meet the first condition implies a failure to communicate

-   at all, while failure to meet the second implies that the meaning of

-   the communication is lost.

-

-   In the case of a public communications system this condition of a

-   common symbol set with a common semantic interpretation must be

-   further strengthened to that of a unique symbol set with a unique

-   semantic interpretation.  This condition of uniqueness allows any

-   party to initiate a communication that can be received and understood

-   by any other party.  Such a condition rules out the ability to define

-   a symbol within some bounded context.  In such a case, once the

-   communication moves out of the context of interpretation in which it

-   was defined, the meaning of the symbol becomes lost.

-

-   Within public digital communications networks such as the Internet

-   this requirement for a uniquely defined symbol set with a uniquely

-   defined meaning exists at many levels, commencing with the binary

-   encoding scheme, extending to packet headers and payload formats and

-   the protocol that an application uses to interact.  In each case a

-   variation of the symbol set or a difference of interpretation of the

-   symbols being used within the interaction causes a protocol failure,

-   and the communication fails.  The property of uniqueness allows a

-   symbol to be used unambiguously in any context, allowing the symbol

-   to be passed on, referred to, and reused, while still preserving the

-   meaning of the original use.

-

-   The DNS fulfills an essential role within the Internet protocol

-   environment, allowing network locations to be referred to using a

-   label other than a protocol address.  As with any other such symbol

-   set, DNS names are designed to be globally unique, that is, for any

-   one DNS name at any one time there must be a single set of DNS

-   records uniquely describing protocol addresses, network resources and

-   services associated with that DNS name.  All of the applications

-   deployed on the Internet which use the DNS assume this, and Internet

-   users expect such behavior from DNS names.  Names are then constant

-   symbols, whose interpretation does not specifically require knowledge

-   of the context of any individual party.  A DNS name can be passed

-   from one party to another without altering the semantic intent of the

-   name.

-

-   Since the DNS is hierarchically structured into domains, the

-   uniqueness requirement for DNS names in their entirety implies that

-   each of the names (sub-domains) defined within a domain has a unique

-

-

-

-IAB                          Informational                      [Page 2]

-

-RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000

-

-

-   meaning (i.e., set of DNS records) within that domain.  This is as

-   true for the root domain as for any other DNS domain.  The

-   requirement for uniqueness within a domain further implies that there

-   be some mechanism to prevent name conflicts within a domain.  In DNS

-   this is accomplished by assigning a single owner or maintainer to

-   every domain, including the root domain, who is responsible for

-   ensuring that each sub-domain of that domain has the proper records

-   associated with it.  This is a technical requirement, not a policy

-   choice.

-

-1.2.  Coordination of Updates

-

-   Both the design and implementations of the DNS protocol are heavily

-   based on the assumption that there is a single owner or maintainer

-   for every domain, and that any set of resources records associated

-   with a domain is modified in a single-copy serializable fashion.

-   That is, even assuming that a single domain could somehow be "shared"

-   by uncooperating parties, there is no means within the DNS protocol

-   by which a user or client could discover, and choose between,

-   conflicting definitions of a DNS name made by different parties.  The

-   client will simply return the first set of resource records that it

-   finds that matches the requested domain, and assume that these are

-   valid.  This protocol is embedded in the operating software of

-   hundreds of millions of computer systems, and is not easily updated

-   to support a shared domain scenario.

-

-   Moreover, even supposing that some other means of resolving

-   conflicting definitions could be provided in the future, it would

-   have to be based on objective rules established in advance.  For

-   example, zone A.B could declare that naming authority Y had been

-   delegated all subdomains of A.B with an odd number of characters, and

-   that naming authority Z had been delegated authority to define

-   subdomains of A.B with an even number of characters.  Thus, a single

-   set of rules would have to be agreed to prevent Y and Z from making

-   conflicting assignments, and with this train of actions a single

-   unique space has been created in any case.  Even this would not allow

-   multiple non-cooperating authorities to assign arbitrary sub-domains

-   within a single domain.

-

-   It seems that a degree of cooperation and agreed technical rules are

-   required in order to guarantee the uniqueness of names.  In the DNS,

-   these rules are established independently for each part of the naming

-   hierarchy, and the root domain is no exception.  Thus, there must be

-   a generally agreed single set of rules for the root.

-

-

-

-

-

-

-

-IAB                          Informational                      [Page 3]

-

-RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000

-

-

-1.3.  Difficulty of Relocating the Root Zone

-

-   There is one specific technical respect in which the root zone

-   differs from all other DNS zones: the addresses of the name servers

-   for the root zone come primarily from out-of-band information.  This

-   out-of-band information is often poorly maintained and, unlike all

-   other data in the DNS, the out-of-band information has no automatic

-   timeout mechanism.  It is not uncommon for this information to be

-   years out of date at many sites.

-

-   Like any other zone, the root zone contains a set of "name server"

-   resource records listing its servers, but a resolver with no valid

-   addresses for the current set of root servers will never be able to

-   obtain these records.  More insidiously, a resolver that has a mixed

-   set of partially valid and partially stale out-of-band configuration

-   information will not be able to tell which are the "real" root

-   servers if it gets back conflicting answers; thus, it is very

-   difficult to revoke the status of a malicious root server, or even to

-   route around a buggy root server.

-

-   In effect, every full-service resolver in the world "delegates" the

-   root of the public tree to the public root server(s) of its choice.

-

-   As a direct consequence, any change to the list of IP addresses that

-   specify the public root zone is significantly more difficult than

-   changing any other aspect of the DNS delegation chain.   Thus,

-   stability of the system calls for extremely conservative and cautious

-   management of the public root zone: the frequency of updates to the

-   root zone must be kept low, and the servers for the root zone must be

-   closely coordinated.

-

-   These problems can be ameliorated to some extent by the DNS Security

-   Extensions [DNSSEC], but a similar out-of-band configuration problem

-   exists for the cryptographic signature key to the root zone, so the

-   root zone still requires tight coupling and coordinated management

-   even in the presence of DNSSEC.

-

-2.  Conclusion

-

-   The DNS type of unique naming and name-mapping system may not be

-   ideal for a number of purposes for which it was never designed, such

-   a locating information when the user doesn't precisely know the

-   correct names.  As the Internet continues to expand, we would expect

-   directory systems to evolve which can assist the user in dealing with

-   vague or ambiguous references.  To preserve the many important

-   features of the DNS and its multiple record types -- including the

-   Internet's equivalent of telephone number portability -- we would

-   expect the result of directory lookups and identification of the

-

-

-

-IAB                          Informational                      [Page 4]

-

-RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000

-

-

-   correct names for a particular purpose to be unique DNS names that

-   are then resolved normally, rather than having directory systems

-   "replace" the DNS.

-

-   There is no getting away from the unique root of the public DNS.

-

-3.  Security Considerations

-

-   This memo does not introduce any new security issues, but it does

-   attempt to identify some of the problems inherent in a family of

-   recurring technically naive proposals.

-

-4.  IANA Considerations

-

-   This memo is not intended to create any new issues for IANA.

-

-5.  References

-

-   [DNS-CONCEPTS]        Mockapetris, P., "Domain Names - Concepts and

-                         Facilities", STD 13, RFC 1034, November 1987.

-

-   [DNS-IMPLEMENTATION]  Mockapetris, P., "Domain Names - Implementation

-                         and Specification", STD 13, RFC 1035, November

-                         1987.

-

-   [DNSSEC]              Eastlake, D., "Domain Name System Security

-                         Extensions", RFC 2535, March 1999.

-

-6.  Author's Address

-

-   Internet Architecture Board

-

-   EMail: iab@iab.org

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-IAB                          Informational                      [Page 5]

-

-RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000

-

-

-7.  Full Copyright Statement

-

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

-

-   This document and translations of it may be copied and furnished to

-   others, and derivative works that comment on or otherwise explain it

-   or assist in its 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.

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-

-IAB                          Informational                      [Page 6]

-

diff --git a/contrib/bind9/doc/rfc/rfc2845.txt b/contrib/bind9/doc/rfc/rfc2845.txt
deleted file mode 100644
index aa9f385..0000000
--- a/contrib/bind9/doc/rfc/rfc2845.txt
+++ /dev/null
@@ -1,843 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                             P. Vixie
-Request for Comments: 2845                                             ISC
-Category: Standards Track                                   O. Gudmundsson
-Updates: 1035                                                     NAI Labs
-                                                           D. Eastlake 3rd
-                                                                  Motorola
-                                                             B. Wellington
-                                                                   Nominum
-                                                                  May 2000
-
-
-          Secret Key Transaction Authentication for DNS (TSIG)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   This protocol allows for transaction level authentication using
-   shared secrets and one way hashing.  It can be used to authenticate
-   dynamic updates as coming from an approved client, or to authenticate
-   responses as coming from an approved recursive name server.
-
-   No provision has been made here for distributing the shared secrets;
-   it is expected that a network administrator will statically configure
-   name servers and clients using some out of band mechanism such as
-   sneaker-net until a secure automated mechanism for key distribution
-   is available.
-
-1 - Introduction
-
-   1.1. The Domain Name System (DNS) [RFC1034, RFC1035] is a replicated
-   hierarchical distributed database system that provides information
-   fundamental to Internet operations, such as name <=> address
-   translation and mail handling information.  DNS has recently been
-   extended [RFC2535] to provide for data origin authentication, and
-   public key distribution, all based on public key cryptography and
-   public key based digital signatures.  To be practical, this form of
-
-
-
-
-Vixie, et al.               Standards Track                     [Page 1]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   security generally requires extensive local caching of keys and
-   tracing of authentication through multiple keys and signatures to a
-   pre-trusted locally configured key.
-
-   1.2. One difficulty with the [RFC2535] scheme is that common DNS
-   implementations include simple "stub" resolvers which do not have
-   caches.  Such resolvers typically rely on a caching DNS server on
-   another host.  It is impractical for these stub resolvers to perform
-   general [RFC2535] authentication and they would naturally depend on
-   their caching DNS server to perform such services for them.  To do so
-   securely requires secure communication of queries and responses.
-   [RFC2535] provides public key transaction signatures to support this,
-   but such signatures are very expensive computationally to generate.
-   In general, these require the same complex public key logic that is
-   impractical for stubs.  This document specifies use of a message
-   authentication code (MAC), specifically HMAC-MD5 (a keyed hash
-   function), to provide an efficient means of point-to-point
-   authentication and integrity checking for transactions.
-
-   1.3. A second area where use of straight [RFC2535] public key based
-   mechanisms may be impractical is authenticating dynamic update
-   [RFC2136] requests.  [RFC2535] provides for request signatures but
-   with [RFC2535] they, like transaction signatures, require
-   computationally expensive public key cryptography and complex
-   authentication logic.  Secure Domain Name System Dynamic Update
-   ([RFC2137]) describes how different keys are used in dynamically
-   updated zones.  This document's secret key based MACs can be used to
-   authenticate DNS update requests as well as transaction responses,
-   providing a lightweight alternative to the protocol described by
-   [RFC2137].
-
-   1.4. A further use of this mechanism is to protect zone transfers.
-   In this case the data covered would be the whole zone transfer
-   including any glue records sent.  The protocol described by [RFC2535]
-   does not protect glue records and unsigned records unless SIG(0)
-   (transaction signature) is used.
-
-   1.5. The authentication mechanism proposed in this document uses
-   shared secret keys to establish a trust relationship between two
-   entities.  Such keys must be protected in a fashion similar to
-   private keys, lest a third party masquerade as one of the intended
-   parties (forge MACs).  There is an urgent need to provide simple and
-   efficient authentication between clients and local servers and this
-   proposal addresses that need.  This proposal is unsuitable for
-   general server to server authentication for servers which speak with
-   many other servers, since key management would become unwieldy with
-
-
-
-
-
-Vixie, et al.               Standards Track                     [Page 2]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   the number of shared keys going up quadratically.  But it is suitable
-   for many resolvers on hosts that only talk to a few recursive
-   servers.
-
-   1.6. A server acting as an indirect caching resolver -- a "forwarder"
-   in common usage -- might use transaction-based authentication when
-   communicating with its small number of preconfigured "upstream"
-   servers.  Other uses of DNS secret key authentication and possible
-   systems for automatic secret key distribution may be proposed in
-   separate future documents.
-
-   1.7. New Assigned Numbers
-
-      RRTYPE = TSIG (250)
-      ERROR = 0..15 (a DNS RCODE)
-      ERROR = 16 (BADSIG)
-      ERROR = 17 (BADKEY)
-      ERROR = 18 (BADTIME)
-
-   1.8. The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED",  and
-   "MAY" in this document are to be interpreted as described in [RFC
-   2119].
-
-2 - TSIG RR Format
-
-   2.1 TSIG RR Type
-
-   To provide secret key authentication, we use a new RR type whose
-   mnemonic is TSIG and whose type code is 250.  TSIG is a meta-RR and
-   MUST not be cached.  TSIG RRs are used for authentication between DNS
-   entities that have established a shared secret key.  TSIG RRs are
-   dynamically computed to cover a particular DNS transaction and are
-   not DNS RRs in the usual sense.
-
-   2.2 TSIG Calculation
-
-   As the TSIG RRs are related to one DNS request/response, there is no
-   value in storing or retransmitting them, thus the TSIG RR is
-   discarded once it has been used to authenticate a DNS message.  The
-   only message digest algorithm specified in this document is "HMAC-
-   MD5" (see [RFC1321], [RFC2104]).  The "HMAC-MD5" algorithm is
-   mandatory to implement for interoperability.  Other algorithms can be
-   specified at a later date.  Names and definitions of new algorithms
-   MUST be registered with IANA.  All multi-octet integers in the TSIG
-   record are sent in network byte order (see [RFC1035 2.3.2]).
-
-
-
-
-
-
-Vixie, et al.               Standards Track                     [Page 3]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   2.3. Record Format
-
-    NAME The name of the key used in domain name syntax.  The name
-         should reflect the names of the hosts and uniquely identify
-         the key among a set of keys these two hosts may share at any
-         given time.  If hosts A.site.example and B.example.net share a
-         key, possibilities for the key name include
-         <id>.A.site.example, <id>.B.example.net, and
-         <id>.A.site.example.B.example.net.  It should be possible for
-         more than one key to be in simultaneous use among a set of
-         interacting hosts.  The name only needs to be meaningful to
-         the communicating hosts but a meaningful mnemonic name as
-         above is strongly recommended.
-
-         The name may be used as a local index to the key involved and
-         it is recommended that it be globally unique.  Where a key is
-         just shared between two hosts, its name actually only need
-         only be meaningful to them but it is recommended that the key
-         name be mnemonic and incorporate the resolver and server host
-         names in that order.
-
-    TYPE TSIG (250: Transaction SIGnature)
-
-    CLASS ANY
-
-    TTL  0
-
-    RdLen (variable)
-
-    RDATA
-
-      Field Name       Data Type      Notes
-      --------------------------------------------------------------
-      Algorithm Name   domain-name    Name of the algorithm
-                                      in domain name syntax.
-      Time Signed      u_int48_t      seconds since 1-Jan-70 UTC.
-      Fudge            u_int16_t      seconds of error permitted
-                                      in Time Signed.
-      MAC Size         u_int16_t      number of octets in MAC.
-      MAC              octet stream   defined by Algorithm Name.
-      Original ID      u_int16_t      original message ID
-      Error            u_int16_t      expanded RCODE covering
-                                      TSIG processing.
-      Other Len        u_int16_t      length, in octets, of
-                                      Other Data.
-      Other Data       octet stream   empty unless Error == BADTIME
-
-
-
-
-
-Vixie, et al.               Standards Track                     [Page 4]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   2.4. Example
-
-      NAME   HOST.EXAMPLE.
-
-      TYPE   TSIG
-
-      CLASS  ANY
-
-      TTL    0
-
-      RdLen  as appropriate
-
-      RDATA
-
-         Field Name       Contents
-         -------------------------------------
-         Algorithm Name   SAMPLE-ALG.EXAMPLE.
-         Time Signed      853804800
-         Fudge            300
-         MAC Size         as appropriate
-         MAC              as appropriate
-         Original ID      as appropriate
-         Error            0 (NOERROR)
-         Other Len        0
-         Other Data       empty
-
-3 - Protocol Operation
-
-   3.1. Effects of adding TSIG to outgoing message
-
-   Once the outgoing message has been constructed, the keyed message
-   digest operation can be performed.  The resulting message digest will
-   then be stored in a TSIG which is appended to the additional data
-   section (the ARCOUNT is incremented to reflect this).  If the TSIG
-   record cannot be added without causing the message to be truncated,
-   the server MUST alter the response so that a TSIG can be included.
-   This response consists of only the question and a TSIG record, and
-   has the TC bit set and RCODE 0 (NOERROR).  The client SHOULD at this
-   point retry the request using TCP (per [RFC1035 4.2.2]).
-
-   3.2. TSIG processing on incoming messages
-
-   If an incoming message contains a TSIG record, it MUST be the last
-   record in the additional section.  Multiple TSIG records are not
-   allowed.  If a TSIG record is present in any other position, the
-   packet is dropped and a response with RCODE 1 (FORMERR) MUST be
-   returned.  Upon receipt of a message with a correctly placed TSIG RR,
-   the TSIG RR is copied to a safe location, removed from the DNS
-
-
-
-Vixie, et al.               Standards Track                     [Page 5]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   Message, and decremented out of the DNS message header's ARCOUNT.  At
-   this point the keyed message digest operation is performed.  If the
-   algorithm name or key name is unknown to the recipient, or if the
-   message digests do not match, the whole DNS message MUST be
-   discarded.  If the message is a query, a response with RCODE 9
-   (NOTAUTH) MUST be sent back to the originator with TSIG ERROR 17
-   (BADKEY) or TSIG ERROR 16 (BADSIG).  If no key is available to sign
-   this message it MUST be sent unsigned (MAC size == 0 and empty MAC).
-   A message to the system operations log SHOULD be generated, to warn
-   the operations staff of a possible security incident in progress.
-   Care should be taken to ensure that logging of this type of event
-   does not open the system to a denial of service attack.
-
-   3.3. Time values used in TSIG calculations
-
-   The data digested includes the two timer values in the TSIG header in
-   order to defend against replay attacks.  If this were not done, an
-   attacker could replay old messages but update the "Time Signed" and
-   "Fudge" fields to make the message look new.  This data is named
-   "TSIG Timers", and for the purpose of digest calculation they are
-   invoked in their "on the wire" format, in the following order: first
-   Time Signed, then Fudge.  For example:
-
-Field Name    Value       Wire Format         Meaning
-----------------------------------------------------------------------
-Time Signed   853804800   00 00 32 e4 07 00   Tue Jan 21 00:00:00 1997
-Fudge         300         01 2C               5 minutes
-
-   3.4. TSIG Variables and Coverage
-
-   When generating or verifying the contents of a TSIG record, the
-   following data are digested, in network byte order or wire format, as
-   appropriate:
-
-   3.4.1. DNS Message
-
-   A whole and complete DNS message in wire format, before the TSIG RR
-   has been added to the additional data section and before the DNS
-   Message Header's ARCOUNT field has been incremented to contain the
-   TSIG RR.  If the message ID differs from the original message ID, the
-   original message ID is substituted for the message ID.  This could
-   happen when forwarding a dynamic update request, for example.
-
-
-
-
-
-
-
-
-
-Vixie, et al.               Standards Track                     [Page 6]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   3.4.2. TSIG Variables
-
-Source       Field Name       Notes
------------------------------------------------------------------------
-TSIG RR      NAME             Key name, in canonical wire format
-TSIG RR      CLASS            (Always ANY in the current specification)
-TSIG RR      TTL              (Always 0 in the current specification)
-TSIG RDATA   Algorithm Name   in canonical wire format
-TSIG RDATA   Time Signed      in network byte order
-TSIG RDATA   Fudge            in network byte order
-TSIG RDATA   Error            in network byte order
-TSIG RDATA   Other Len        in network byte order
-TSIG RDATA   Other Data       exactly as transmitted
-
-   The RR RDLEN and RDATA MAC Length are not included in the hash since
-   they are not guaranteed to be knowable before the MAC is generated.
-
-   The Original ID field is not included in this section, as it has
-   already been substituted for the message ID in the DNS header and
-   hashed.
-
-   For each label type, there must be a defined "Canonical wire format"
-   that specifies how to express a label in an unambiguous way.  For
-   label type 00, this is defined in [RFC2535], for label type 01, this
-   is defined in [RFC2673].  The use of label types other than 00 and 01
-   is not defined for this specification.
-
-   3.4.3. Request MAC
-
-   When generating the MAC to be included in a response, the request MAC
-   must be included in the digest.  The request's MAC is digested in
-   wire format, including the following fields:
-
-   Field        Type           Description
-   ---------------------------------------------------
-   MAC Length   u_int16_t      in network byte order
-   MAC Data     octet stream   exactly as transmitted
-
-   3.5. Padding
-
-   Digested components are fed into the hashing function as a continuous
-   octet stream with no interfield padding.
-
-
-
-
-
-
-
-
-
-Vixie, et al.               Standards Track                     [Page 7]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-4 - Protocol Details
-
-   4.1. TSIG generation on requests
-
-   Client performs the message digest operation and appends a TSIG
-   record to the additional data section and transmits the request to
-   the server.  The client MUST store the message digest from the
-   request while awaiting an answer.  The digest components for a
-   request are:
-
-      DNS Message (request)
-      TSIG Variables (request)
-
-   Note that some older name servers will not accept requests with a
-   nonempty additional data section.  Clients SHOULD only attempt signed
-   transactions with servers who are known to support TSIG and share
-   some secret key with the client -- so, this is not a problem in
-   practice.
-
-   4.2. TSIG on Answers
-
-   When a server has generated a response to a signed request, it signs
-   the response using the same algorithm and key.  The server MUST not
-   generate a signed response to an unsigned request.  The digest
-   components are:
-
-      Request MAC
-      DNS Message (response)
-      TSIG Variables (response)
-
-   4.3. TSIG on TSIG Error returns
-
-   When a server detects an error relating to the key or MAC, the server
-   SHOULD send back an unsigned error message (MAC size == 0 and empty
-   MAC).  If an error is detected relating to the TSIG validity period,
-   the server SHOULD send back a signed error message.  The digest
-   components are:
-
-      Request MAC (if the request MAC validated)
-      DNS Message (response)
-      TSIG Variables (response)
-
-   The reason that the request is not included in this digest in some
-   cases is to make it possible for the client to verify the error.  If
-   the error is not a TSIG error the response MUST be generated as
-   specified in [4.2].
-
-
-
-
-
-Vixie, et al.               Standards Track                     [Page 8]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   4.4. TSIG on TCP connection
-
-   A DNS TCP session can include multiple DNS envelopes.  This is, for
-   example, commonly used by zone transfer.  Using TSIG on such a
-   connection can protect the connection from hijacking and provide data
-   integrity.  The TSIG MUST be included on the first and last DNS
-   envelopes.  It can be optionally placed on any intermediary
-   envelopes.  It is expensive to include it on every envelopes, but it
-   MUST be placed on at least every 100'th envelope.  The first envelope
-   is processed as a standard answer, and subsequent messages have the
-   following digest components:
-
-      Prior Digest (running)
-      DNS Messages (any unsigned messages since the last TSIG)
-      TSIG Timers (current message)
-
-   This allows the client to rapidly detect when the session has been
-   altered; at which point it can close the connection and retry.  If a
-   client TSIG verification fails, the client MUST close the connection.
-   If the client does not receive TSIG records frequently enough (as
-   specified above) it SHOULD assume the connection has been hijacked
-   and it SHOULD close the connection.  The client SHOULD treat this the
-   same way as they would any other interrupted transfer (although the
-   exact behavior is not specified).
-
-   4.5. Server TSIG checks
-
-   Upon receipt of a message, server will check if there is a TSIG RR.
-   If one exists, the server is REQUIRED to return a TSIG RR in the
-   response.  The server MUST perform the following checks in the
-   following order, check KEY, check TIME values, check MAC.
-
-   4.5.1. KEY check and error handling
-
-   If a non-forwarding server does not recognize the key used by the
-   client, the server MUST generate an error response with RCODE 9
-   (NOTAUTH) and TSIG ERROR 17 (BADKEY).  This response MUST be unsigned
-   as specified in [4.3].  The server SHOULD log the error.
-
-   4.5.2. TIME check and error handling
-
-   If the server time is outside the time interval specified by the
-   request (which is: Time Signed, plus/minus Fudge), the server MUST
-   generate an error response with RCODE 9 (NOTAUTH) and TSIG ERROR 18
-   (BADTIME).  The server SHOULD also cache the most recent time signed
-   value in a message generated by a key, and SHOULD return BADTIME if a
-   message received later has an earlier time signed value.  A response
-   indicating a BADTIME error MUST be signed by the same key as the
-
-
-
-Vixie, et al.               Standards Track                     [Page 9]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   request.  It MUST include the client's current time in the time
-   signed field, the server's current time (a u_int48_t) in the other
-   data field, and 6 in the other data length field.  This is done so
-   that the client can verify a message with a BADTIME error without the
-   verification failing due to another BADTIME error.  The data signed
-   is specified in [4.3].  The server SHOULD log the error.
-
-   4.5.3. MAC check and error handling
-
-   If a TSIG fails to verify, the server MUST generate an error response
-   as specified in [4.3] with RCODE 9 (NOTAUTH) and TSIG ERROR 16
-   (BADSIG).  This response MUST be unsigned as specified in [4.3].  The
-   server SHOULD log the error.
-
-   4.6. Client processing of answer
-
-   When a client receives a response from a server and expects to see a
-   TSIG, it first checks if the TSIG RR is present in the response.
-   Otherwise, the response is treated as having a format error and
-   discarded.  The client then extracts the TSIG, adjusts the ARCOUNT,
-   and calculates the keyed digest in the same way as the server.  If
-   the TSIG does not validate, that response MUST be discarded, unless
-   the RCODE is 9 (NOTAUTH), in which case the client SHOULD attempt to
-   verify the response as if it were a TSIG Error response, as specified
-   in [4.3].  A message containing an unsigned TSIG record or a TSIG
-   record which fails verification SHOULD not be considered an
-   acceptable response; the client SHOULD log an error and continue to
-   wait for a signed response until the request times out.
-
-   4.6.1. Key error handling
-
-   If an RCODE on a response is 9 (NOTAUTH), and the response TSIG
-   validates, and the TSIG key is different from the key used on the
-   request, then this is a KEY error.  The client MAY retry the request
-   using the key specified by the server.  This should never occur, as a
-   server MUST NOT sign a response with a different key than signed the
-   request.
-
-   4.6.2. Time error handling
-
-   If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR is 18
-   (BADTIME), or the current time does not fall in the range specified
-   in the TSIG record, then this is a TIME error.  This is an indication
-   that the client and server clocks are not synchronized.  In this case
-   the client SHOULD log the event.  DNS resolvers MUST NOT adjust any
-   clocks in the client based on BADTIME errors, but the server's time
-   in the other data field SHOULD be logged.
-
-
-
-
-Vixie, et al.               Standards Track                    [Page 10]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   4.6.3. MAC error handling
-
-   If the response RCODE is 9 (NOTAUTH) and TSIG ERROR is 16 (BADSIG),
-   this is a MAC error, and client MAY retry the request with a new
-   request ID but it would be better to try a different shared key if
-   one is available.  Client SHOULD keep track of how many MAC errors
-   are associated with each key.  Clients SHOULD log this event.
-
-   4.7. Special considerations for forwarding servers
-
-   A server acting as a forwarding server of a DNS message SHOULD check
-   for the existence of a TSIG record.  If the name on the TSIG is not
-   of a secret that the server shares with the originator the server
-   MUST forward the message unchanged including the TSIG.  If the name
-   of the TSIG is of a key this server shares with the originator, it
-   MUST process the TSIG.  If the TSIG passes all checks, the forwarding
-   server MUST, if possible, include a TSIG of his own, to the
-   destination or the next forwarder.  If no transaction security is
-   available to the destination and the response has the AD flag (see
-   [RFC2535]), the forwarder MUST unset the AD flag before adding the
-   TSIG to the answer.
-
-5 - Shared Secrets
-
-   5.1. Secret keys are very sensitive information and all available
-   steps should be taken to protect them on every host on which they are
-   stored.  Generally such hosts need to be physically protected.  If
-   they are multi-user machines, great care should be taken that
-   unprivileged users have no access to keying material.  Resolvers
-   often run unprivileged, which means all users of a host would be able
-   to see whatever configuration data is used by the resolver.
-
-   5.2. A name server usually runs privileged, which means its
-   configuration data need not be visible to all users of the host.  For
-   this reason, a host that implements transaction-based authentication
-   should probably be configured with a "stub resolver" and a local
-   caching and forwarding name server.  This presents a special problem
-   for [RFC2136] which otherwise depends on clients to communicate only
-   with a zone's authoritative name servers.
-
-   5.3. Use of strong random shared secrets is essential to the security
-   of TSIG.  See [RFC1750] for a discussion of this issue.  The secret
-   should be at least as long as the keyed message digest, i.e. 16 bytes
-   for HMAC-MD5 or 20 bytes for HMAC-SHA1.
-
-
-
-
-
-
-
-Vixie, et al.               Standards Track                    [Page 11]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-6 - Security Considerations
-
-   6.1. The approach specified here is computationally much less
-   expensive than the signatures specified in [RFC2535].  As long as the
-   shared secret key is not compromised, strong authentication is
-   provided for the last hop from a local name server to the user
-   resolver.
-
-   6.2. Secret keys should be changed periodically.  If the client host
-   has been compromised, the server should suspend the use of all
-   secrets known to that client.  If possible, secrets should be stored
-   in encrypted form.  Secrets should never be transmitted in the clear
-   over any network.  This document does not address the issue on how to
-   distribute secrets. Secrets should never be shared by more than two
-   entities.
-
-   6.3. This mechanism does not authenticate source data, only its
-   transmission between two parties who share some secret.  The original
-   source data can come from a compromised zone master or can be
-   corrupted during transit from an authentic zone master to some
-   "caching forwarder."  However, if the server is faithfully performing
-   the full [RFC2535] security checks, then only security checked data
-   will be available to the client.
-
-   6.4. A fudge value that is too large may leave the server open to
-   replay attacks.  A fudge value that is too small may cause failures
-   if machines are not time synchronized or there are unexpected network
-   delays.  The recommended value in most situation is 300 seconds.
-
-7 - IANA Considerations
-
-   IANA is expected to create and maintain a registry of algorithm names
-   to be used as "Algorithm Names" as defined in Section 2.3.  The
-   initial value should be "HMAC-MD5.SIG-ALG.REG.INT".  Algorithm names
-   are text strings encoded using the syntax of a domain name.  There is
-   no structure required other than names for different algorithms must
-   be unique when compared as DNS names, i.e., comparison is case
-   insensitive.  Note that the initial value mentioned above is not a
-   domain name, and therefore need not be a registered name within the
-   DNS.  New algorithms are assigned using the IETF Consensus policy
-   defined in RFC 2434. The algorithm name HMAC-MD5.SIG-ALG.REG.INT
-   looks like a FQDN for historical reasons; future algorithm names are
-   expected to be simple (i.e., single-component) names.
-
-
-
-
-
-
-
-
-Vixie, et al.               Standards Track                    [Page 12]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-   IANA is expected to create and maintain a registry of "TSIG Error
-   values" to be used for "Error" values as defined in section 2.3.
-   Initial values should be those defined in section 1.7.  New TSIG
-   error codes for the TSIG error field are assigned using the IETF
-   Consensus policy defined in RFC 2434.
-
-8 - References
-
-   [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 1034, November 1987.
-
-   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
-              April 1992.
-
-   [RFC1750]  Eastlake, D., Crocker, S. and J. Schiller, "Randomness
-              Recommendations for Security", RFC 1750, December 1995.
-
-   [RFC2104]  Krawczyk, H., Bellare, M. and R. Canetti, "HMAC-MD5:
-              Keyed-MD5 for Message Authentication", RFC 2104, February
-              1997.
-
-   [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", RFC 2136, April 1997.
-
-   [RFC2137]  Eastlake 3rd, D., "Secure Domain Name System Dynamic
-              Update", RFC 2137, April 1997.
-
-   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC2673]  Crawford, M., "Binary Labels in the Domain Name System",
-              RFC 2673, August 1999.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et al.               Standards Track                    [Page 13]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-9 - Authors' Addresses
-
-   Paul Vixie
-   Internet Software Consortium
-   950 Charter Street
-   Redwood City, CA 94063
-
-   Phone: +1 650 779 7001
-   EMail: vixie@isc.org
-
-
-   Olafur Gudmundsson
-   NAI Labs
-   3060 Washington Road, Route 97
-   Glenwood, MD 21738
-
-   Phone: +1 443 259 2389
-   EMail: ogud@tislabs.com
-
-
-   Donald E. Eastlake 3rd
-   Motorola
-   140 Forest Avenue
-   Hudson, MA 01749 USA
-
-   Phone: +1 508 261 5434
-   EMail: dee3@torque.pothole.com
-
-
-   Brian Wellington
-   Nominum, Inc.
-   950 Charter Street
-   Redwood City, CA 94063
-
-   Phone: +1 650 779 6022
-   EMail: Brian.Wellington@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et al.               Standards Track                    [Page 14]
-
-RFC 2845                        DNS TSIG                        May 2000
-
-
-10  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vixie, et al.               Standards Track                    [Page 15]
-
diff --git a/contrib/bind9/doc/rfc/rfc2874.txt b/contrib/bind9/doc/rfc/rfc2874.txt
deleted file mode 100644
index 915c104..0000000
--- a/contrib/bind9/doc/rfc/rfc2874.txt
+++ /dev/null
@@ -1,1123 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        M. Crawford
-Request for Comments: 2874                                      Fermilab
-Category: Standards Track                                     C. Huitema
-                                                   Microsoft Corporation
-                                                               July 2000
-
-
-   DNS Extensions to Support IPv6 Address Aggregation and Renumbering
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   This document defines changes to the Domain Name System to support
-   renumberable and aggregatable IPv6 addressing.  The changes include a
-   new resource record type to store an IPv6 address in a manner which
-   expedites network renumbering and updated definitions of existing
-   query types that return Internet addresses as part of additional
-   section processing.
-
-   For lookups keyed on IPv6 addresses (often called reverse lookups),
-   this document defines a new zone structure which allows a zone to be
-   used without modification for parallel copies of an address space (as
-   for a multihomed provider or site) and across network renumbering
-   events.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crawford, et al.            Standards Track                     [Page 1]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-Table of Contents
-
-   1.  Introduction ...............................................  2
-   2.  Overview ...................................................  3
-       2.1.  Name-to-Address Lookup ...............................  4
-       2.2.  Underlying Mechanisms for Reverse Lookups ............  4
-           2.2.1.  Delegation on Arbitrary Boundaries .............  4
-           2.2.2.  Reusable Zones .................................  5
-   3.  Specifications .............................................  5
-       3.1.  The A6 Record Type ...................................  5
-           3.1.1.  Format .........................................  6
-           3.1.2.  Processing .....................................  6
-           3.1.3.  Textual Representation .........................  7
-           3.1.4.  Name Resolution Procedure ......................  7
-       3.2.  Zone Structure for Reverse Lookups ...................  7
-   4.  Modifications to Existing Query Types ......................  8
-   5.  Usage Illustrations ........................................  8
-       5.1.  A6 Record Chains .....................................  9
-           5.1.1.  Authoritative Data .............................  9
-           5.1.2.  Glue ........................................... 10
-           5.1.3.  Variations ..................................... 12
-       5.2.  Reverse Mapping Zones ................................ 13
-           5.2.1.  The TLA level .................................. 13
-           5.2.2.  The ISP level .................................. 13
-           5.2.3.  The Site Level ................................. 13
-       5.3.  Lookups .............................................. 14
-       5.4.  Operational Note ..................................... 15
-   6.  Transition from RFC 1886 and Deployment Notes .............. 15
-       6.1.  Transition from AAAA and Coexistence with A Records .. 16
-       6.2.  Transition from Nibble Labels to Binary Labels ....... 17
-   7.  Security Considerations .................................... 17
-   8.  IANA Considerations ........................................ 17
-   9.  Acknowledgments ............................................ 18
-   10.  References ................................................ 18
-   11.  Authors' Addresses ........................................ 19
-   12.  Full Copyright Statement .................................. 20
-
-1.  Introduction
-
-   Maintenance of address information in the DNS is one of several
-   obstacles which have prevented site and provider renumbering from
-   being feasible in IP version 4.  Arguments about the importance of
-   network renumbering for the preservation of a stable routing system
-   and for other purposes may be read in [RENUM1, RENUM2, RENUM3].  To
-   support the storage of IPv6 addresses without impeding renumbering we
-   define the following extensions.
-
-
-
-
-
-Crawford, et al.            Standards Track                     [Page 2]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-   o  A new resource record type, "A6", is defined to map a domain name
-      to an IPv6 address, with a provision for indirection for leading
-      "prefix" bits.
-
-   o  Existing queries that perform additional section processing to
-      locate IPv4 addresses are redefined to do that processing for both
-      IPv4 and IPv6 addresses.
-
-   o  A new domain, IP6.ARPA, is defined to support lookups based on
-      IPv6 address.
-
-   o  A new prefix-delegation method is defined, relying on new DNS
-      features [BITLBL, DNAME].
-
-   The changes are designed to be compatible with existing application
-   programming interfaces.  The existing support for IPv4 addresses is
-   retained.  Transition issues related to the coexistence of both IPv4
-   and IPv6 addresses in DNS are discussed in [TRANS].
-
-   This memo proposes a replacement for the specification in RFC 1886
-   [AAAA] and a departure from current implementation practices.  The
-   changes are designed to facilitate network renumbering and
-   multihoming.  Domains employing the A6 record for IPv6 addresses can
-   insert automatically-generated AAAA records in zone files to ease
-   transition.  It is expected that after a reasonable period, RFC 1886
-   will become Historic.
-
-   The next three major sections of this document are an overview of the
-   facilities defined or employed by this specification, the
-   specification itself, and examples of use.
-
-   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 [KWORD].  The key word
-   "SUGGESTED" signifies a strength between MAY and SHOULD: it is
-   believed that compliance with the suggestion has tangible benefits in
-   most instances.
-
-2.  Overview
-
-   This section provides an overview of the DNS facilities for storage
-   of IPv6 addresses and for lookups based on IPv6 address, including
-   those defined here and elsewhere.
-
-
-
-
-
-
-
-
-Crawford, et al.            Standards Track                     [Page 3]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-2.1.  Name-to-Address Lookup
-
-   IPv6 addresses are stored in one or more A6 resource records.  A
-   single A6 record may include a complete IPv6 address, or a contiguous
-   portion of an address and information leading to one or more
-   prefixes.  Prefix information comprises a prefix length and a DNS
-   name which is in turn the owner of one or more A6 records defining
-   the prefix or prefixes which are needed to form one or more complete
-   IPv6 addresses.  When the prefix length is zero, no DNS name is
-   present and all the leading bits of the address are significant.
-   There may be multiple levels of indirection and the existence of
-   multiple A6 records at any level multiplies the number of IPv6
-   addresses which are formed.
-
-   An application looking up an IPv6 address will generally cause the
-   DNS resolver to access several A6 records, and multiple IPv6
-   addresses may be returned even if the queried name was the owner of
-   only one A6 record.  The authenticity of the returned address(es)
-   cannot be directly verified by DNS Security [DNSSEC].  The A6 records
-   which contributed to the address(es) may of course be verified if
-   signed.
-
-   Implementers are reminded of the necessity to limit the amount of
-   work a resolver will perform in response to a client request.  This
-   principle MUST be extended to also limit the generation of DNS
-   requests in response to one name-to-address (or address-to-name)
-   lookup request.
-
-2.2.  Underlying Mechanisms for Reverse Lookups
-
-   This section describes the new DNS features which this document
-   exploits.  This section is an overview, not a specification of those
-   features.  The reader is directed to the referenced documents for
-   more details on each.
-
-2.2.1.  Delegation on Arbitrary Boundaries
-
-   This new scheme for reverse lookups relies on a new type of DNS label
-   called the "bit-string label" [BITLBL].  This label compactly
-   represents an arbitrary string of bits which is treated as a
-   hierarchical sequence of one-bit domain labels.  Resource records can
-   thereby be stored at arbitrary bit-boundaries.
-
-   Examples in section 5 will employ the following textual
-   representation for bit-string labels, which is a subset of the syntax
-   defined in [BITLBL].  A base indicator "x" for hexadecimal and a
-   sequence of hexadecimal digits is enclosed between "\[" and "]".  The
-   bits denoted by the digits represent a sequence of one-bit domain
-
-
-
-Crawford, et al.            Standards Track                     [Page 4]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-   labels ordered from most to least significant.  (This is the opposite
-   of the order they would appear if listed one bit at a time, but it
-   appears to be a convenient notation.)  The digit string may be
-   followed by a slash ("/") and a decimal count.  If omitted, the
-   implicit count is equal to four times the number of hexadecimal
-   digits.
-
-   Consecutive bit-string labels are equivalent (up to the limit imposed
-   by the size of the bit count field) to a single bit-string label
-   containing all the bits of the consecutive labels in the proper
-   order.  As an example, either of the following domain names could be
-   used in a QCLASS=IN, QTYPE=PTR query to find the name of the node
-   with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32.
-
-    \[x3FFE07C0004000090A0020FFFE812B32/128].IP6.ARPA.
-
-    \[x0A0020FFFE812B32/64].\[x0009/16].\[x3FFE07C00040/48].IP6.ARPA.
-
-2.2.2.  Reusable Zones
-
-   DNS address space delegation is implemented not by zone cuts and NS
-   records, but by a new analogue to the CNAME record, called the DNAME
-   resource record [DNAME].  The DNAME record provides alternate naming
-   to an entire subtree of the domain name space, rather than to a
-   single node.  It causes some suffix of a queried name to be
-   substituted with a name from the DNAME record's RDATA.
-
-   For example, a resolver or server providing recursion, while looking
-   up a QNAME a.b.c.d.e.f may encounter a DNAME record
-
-                        d.e.f.     DNAME     w.xy.
-
-   which will cause it to look for a.b.c.w.xy.
-
-3.  Specifications
-
-3.1.  The A6 Record Type
-
-   The A6 record type is specific to the IN (Internet) class and has
-   type number 38 (decimal).
-
-
-
-
-
-
-
-
-
-
-
-Crawford, et al.            Standards Track                     [Page 5]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-3.1.1.  Format
-
-   The RDATA portion of the A6 record contains two or three fields.
-
-           +-----------+------------------+-------------------+
-           |Prefix len.|  Address suffix  |    Prefix name    |
-           | (1 octet) |  (0..16 octets)  |  (0..255 octets)  |
-           +-----------+------------------+-------------------+
-
-   o  A prefix length, encoded as an eight-bit unsigned integer with
-      value between 0 and 128 inclusive.
-
-   o  An IPv6 address suffix, encoded in network order (high-order octet
-      first).  There MUST be exactly enough octets in this field to
-      contain a number of bits equal to 128 minus prefix length, with 0
-      to 7 leading pad bits to make this field an integral number of
-      octets.  Pad bits, if present, MUST be set to zero when loading a
-      zone file and ignored (other than for SIG [DNSSEC] verification)
-      on reception.
-
-   o  The name of the prefix, encoded as a domain name.  By the rules of
-      [DNSIS], this name MUST NOT be compressed.
-
-   The domain name component SHALL NOT be present if the prefix length
-   is zero.  The address suffix component SHALL NOT be present if the
-   prefix length is 128.
-
-   It is SUGGESTED that an A6 record intended for use as a prefix for
-   other A6 records have all the insignificant trailing bits in its
-   address suffix field set to zero.
-
-3.1.2.  Processing
-
-   A query with QTYPE=A6 causes type A6 and type NS additional section
-   processing for the prefix names, if any, in the RDATA field of the A6
-   records in the answer section.  This processing SHOULD be recursively
-   applied to the prefix names of A6 records included as additional
-   data.  When space in the reply packet is a limit, inclusion of
-   additional A6 records takes priority over NS records.
-
-   It is an error for an A6 record with prefix length L1 > 0 to refer to
-   a domain name which owns an A6 record with a prefix length L2 > L1.
-   If such a situation is encountered by a resolver, the A6 record with
-   the offending (larger) prefix length MUST be ignored.  Robustness
-   precludes signaling an error if addresses can still be formed from
-   valid A6 records, but it is SUGGESTED that zone maintainers from time
-   to time check all the A6 records their zones reference.
-
-
-
-
-Crawford, et al.            Standards Track                     [Page 6]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-3.1.3.  Textual Representation
-
-   The textual representation of the RDATA portion of the A6 resource
-   record in a zone file comprises two or three fields separated by
-   whitespace.
-
-   o  A prefix length, represented as a decimal number between 0 and 128
-      inclusive,
-
-   o  the textual representation of an IPv6 address as defined in
-      [AARCH] (although some leading and/or trailing bits may not be
-      significant),
-
-   o  a domain name, if the prefix length is not zero.
-
-   The domain name MUST be absent if the prefix length is zero.  The
-   IPv6 address MAY be be absent if the prefix length is 128.  A number
-   of leading address bits equal to the prefix length SHOULD be zero,
-   either implicitly (through the :: notation) or explicitly, as
-   specified in section 3.1.1.
-
-3.1.4.  Name Resolution Procedure
-
-   To obtain the IPv6 address or addresses which belong to a given name,
-   a DNS client MUST obtain one or more complete chains of A6 records,
-   each chain beginning with a record owned by the given name and
-   including a record owned by the prefix name in that record, and so on
-   recursively, ending with an A6 record with a prefix length of zero.
-   One IPv6 address is formed from one such chain by taking the value of
-   each bit position from the earliest A6 record in the chain which
-   validly covers that position, as indicated by the prefix length.  The
-   set of all IPv6 addresses for the given name comprises the addresses
-   formed from all complete chains of A6 records beginning at that name,
-   discarding records which have invalid prefix lengths as defined in
-   section 3.1.2.
-
-   If some A6 queries fail and others succeed, a client might obtain a
-   non-empty but incomplete set of IPv6 addresses for a host.  In many
-   situations this may be acceptable.  The completeness of a set of A6
-   records may always be determined by inspection.
-
-3.2.  Zone Structure for Reverse Lookups
-
-   Very little of the new scheme's data actually appears under IP6.ARPA;
-   only the first level of delegation needs to be under that domain.
-   More levels of delegation could be placed under IP6.ARPA if some
-   top-level delegations were done via NS records instead of DNAME
-   records, but this would incur some cost in renumbering ease at the
-
-
-
-Crawford, et al.            Standards Track                     [Page 7]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-   level of TLAs [AGGR].  Therefore, it is declared here that all
-   address space delegations SHOULD be done by the DNAME mechanism
-   rather than NS.
-
-   In addition, since uniformity in deployment will simplify maintenance
-   of address delegations, it is SUGGESTED that address and prefix
-   information be stored immediately below a DNS label "IP6".  Stated
-   another way, conformance with this suggestion would mean that "IP6"
-   is the first label in the RDATA field of DNAME records which support
-   IPv6 reverse lookups.
-
-   When any "reserved" or "must be zero" bits are adjacent to a
-   delegation boundary, the higher-level entity MUST retain those bits
-   in its own control and delegate only the bits over which the lower-
-   level entity has authority.
-
-   To find the name of a node given its IPv6 address, a DNS client MUST
-   perform a query with QCLASS=IN, QTYPE=PTR on the name formed from the
-   128 bit address as one or more bit-string labels [BITLBL], followed
-   by the two standard labels "IP6.ARPA".  If recursive service was not
-   obtained from a server and the desired PTR record was not returned,
-   the resolver MUST handle returned DNAME records as specified in
-   [DNAME], and NS records as specified in [DNSCF], and iterate.
-
-4.  Modifications to Existing Query Types
-
-   All existing query types that perform type A additional section
-   processing, i.e. the name server (NS), mail exchange (MX), and
-   mailbox (MB) query types, and the experimental AFS data base (AFSDB)
-   and route through (RT) types, must be redefined to perform type A, A6
-   and AAAA additional section processing, with type A having the
-   highest priority for inclusion and type AAAA the lowest.  This
-   redefinition means that a name server may add any relevant IPv4 and
-   IPv6 address information available locally to the additional section
-   of a response when processing any one of the above queries.  The
-   recursive inclusion of A6 records referenced by A6 records already
-   included in the additional section is OPTIONAL.
-
-5.  Usage Illustrations
-
-   This section provides examples of use of the mechanisms defined in
-   the previous section.  All addresses and domains mentioned here are
-   intended to be fictitious and for illustrative purposes only.
-   Example delegations will be on 4-bit boundaries solely for
-   readability; this specification is indifferent to bit alignment.
-
-   Use of the IPv6 aggregatable address format [AGGR] is assumed in the
-   examples.
-
-
-
-Crawford, et al.            Standards Track                     [Page 8]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-5.1.  A6 Record Chains
-
-   Let's take the example of a site X that is multi-homed to two
-   "intermediate" providers A and B.  The provider A is itself multi-
-   homed to two "transit" providers, C and D.  The provider B gets its
-   transit service from a single provider, E.  For simplicity suppose
-   that C, D and E all belong to the same top-level aggregate (TLA) with
-   identifier (including format prefix) '2345', and the TLA authority at
-   ALPHA-TLA.ORG assigns to C, D and E respectively the next level
-   aggregate (NLA) prefixes 2345:00C0::/28, 2345:00D0::/28 and
-   2345:000E::/32.
-
-   C assigns the NLA prefix 2345:00C1:CA00::/40 to A, D assigns the
-   prefix 2345:00D2:DA00::/40 to A and E assigns 2345:000E:EB00::/40 to
-   B.
-
-   A assigns to X the subscriber identification '11' and B assigns the
-   subscriber identification '22'.  As a result, the site X inherits
-   three address prefixes:
-
-   o  2345:00C1:CA11::/48 from A, for routes through C.
-   o  2345:00D2:DA11::/48 from A, for routes through D.
-   o  2345:000E:EB22::/48 from B, for routes through E.
-
-   Let us suppose that N is a node in the site X, that it is assigned to
-   subnet number 1 in this site, and that it uses the interface
-   identifier '1234:5678:9ABC:DEF0'.  In our configuration, this node
-   will have three addresses:
-
-   o  2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
-   o  2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
-   o  2345:000E:EB22:0001:1234:5678:9ABC:DEF0
-
-5.1.1.  Authoritative Data
-
-   We will assume that the site X is represented in the DNS by the
-   domain name X.EXAMPLE, while A, B, C, D and E are represented by
-   A.NET, B.NET, C.NET, D.NET and E.NET.  In each of these domains, we
-   assume a subdomain "IP6" that will hold the corresponding prefixes.
-   The node N is identified by the domain name N.X.EXAMPLE.  The
-   following records would then appear in X's DNS.
-
-          $ORIGIN X.EXAMPLE.
-          N            A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
-          SUBNET-1.IP6 A6 48 0:0:0:1::  IP6
-          IP6          A6 48 0::0       SUBSCRIBER-X.IP6.A.NET.
-          IP6          A6 48 0::0       SUBSCRIBER-X.IP6.B.NET.
-
-
-
-
-Crawford, et al.            Standards Track                     [Page 9]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-   And elsewhere there would appear
-
-        SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET.
-        SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET.
-
-        SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET.
-
-        A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG.
-
-        A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG.
-
-        B-NET.IP6.E.NET. A6 32 0:0:EB00::    E.NET.ALPHA-TLA.ORG.
-
-        C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0::
-        D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0::
-        E.NET.ALPHA-TLA.ORG. A6 0 2345:000E::
-
-5.1.2.  Glue
-
-   When, as is common, some or all DNS servers for X.EXAMPLE are within
-   the X.EXAMPLE zone itself, the top-level zone EXAMPLE must carry
-   enough "glue" information to enable DNS clients to reach those
-   nameservers.  This is true in IPv6 just as in IPv4.  However, the A6
-   record affords the DNS administrator some choices.  The glue could be
-   any of
-
-   o  a minimal set of A6 records duplicated from the X.EXAMPLE zone,
-
-   o  a (possibly smaller) set of records which collapse the structure
-      of that minimal set,
-
-   o  or a set of A6 records with prefix length zero, giving the entire
-      global addresses of the servers.
-
-   The trade-off is ease of maintenance against robustness.  The best
-   and worst of both may be had together by implementing either the
-   first or second option together with the third.  To illustrate the
-   glue options, suppose that X.EXAMPLE is served by two nameservers
-   NS1.X.EXAMPLE and NS2.X.EXAMPLE, having interface identifiers
-   ::1:11:111:1111 and ::2:22:222:2222 on subnets 1 and 2 respectively.
-   Then the top-level zone EXAMPLE would include one (or more) of the
-   following sets of A6 records as glue.
-
-
-
-
-
-
-
-
-
-Crawford, et al.            Standards Track                    [Page 10]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-   $ORIGIN EXAMPLE.            ; first option
-   X               NS NS1.X
-                   NS NS2.X
-   NS1.X           A6 64 ::1:11:111:1111 SUBNET-1.IP6.X
-   NS2.X           A6 64 ::2:22:222:2222 SUBNET-2.IP6.X
-   SUBNET-1.IP6.X  A6 48 0:0:0:1::       IP6.X
-   SUBNET-2.IP6.X  A6 48 0:0:0:2::       IP6.X
-   IP6.X           A6 48 0::0            SUBSCRIBER-X.IP6.A.NET.
-   IP6.X           A6 48 0::0            SUBSCRIBER-X.IP6.B.NET.
-
-
-   $ORIGIN EXAMPLE.            ; second option
-   X               NS NS1.X
-                   NS NS2.X
-   NS1.X           A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.A.NET.
-                   A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.B.NET.
-   NS2.X           A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.A.NET.
-                   A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.B.NET.
-
-
-   $ORIGIN EXAMPLE.            ; third option
-   X               NS NS1.X
-                   NS NS2.X
-   NS1.X           A6 0  2345:00C1:CA11:1:1:11:111:1111
-                   A6 0  2345:00D2:DA11:1:1:11:111:1111
-                   A6 0  2345:000E:EB22:1:1:11:111:1111
-   NS2.X           A6 0  2345:00C1:CA11:2:2:22:222:2222
-                   A6 0  2345:00D2:DA11:2:2:22:222:2222
-                   A6 0  2345:000E:EB22:2:2:22:222:2222
-
-   The first and second glue options are robust against renumbering of
-   X.EXAMPLE's prefixes by providers A.NET and B.NET, but will fail if
-   those providers' own DNS is unreachable.  The glue records of the
-   third option are robust against DNS failures elsewhere than the zones
-   EXAMPLE and X.EXAMPLE themselves, but must be updated when X's
-   address space is renumbered.
-
-   If the EXAMPLE zone includes redundant glue, for instance the union
-   of the A6 records of the first and third options, then under normal
-   circumstances duplicate IPv6 addresses will be derived by DNS
-   clients.  But if provider DNS fails, addresses will still be obtained
-   from the zero-prefix-length records, while if the EXAMPLE zone lags
-   behind a renumbering of X.EXAMPLE, half of the addresses obtained by
-   DNS clients will still be up-to-date.
-
-   The zero-prefix-length glue records can of course be automatically
-   generated and/or checked in practice.
-
-
-
-
-Crawford, et al.            Standards Track                    [Page 11]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-5.1.3.  Variations
-
-   Several more-or-less arbitrary assumptions are reflected in the above
-   structure.  All of the following choices could have been made
-   differently, according to someone's notion of convenience or an
-   agreement between two parties.
-
-      First, that site X has chosen to put subnet information in a
-      separate A6 record rather than incorporate it into each node's A6
-      records.
-
-      Second, that site X is referred to as "SUBSCRIBER-X" by both of
-      its providers A and B.
-
-      Third, that site X chose to indirect its provider information
-      through A6 records at IP6.X.EXAMPLE containing no significant
-      bits.  An alternative would have been to replicate each subnet
-      record for each provider.
-
-      Fourth, B and E used a slightly different prefix naming convention
-      between themselves than did A, C and D.  Each hierarchical pair of
-      network entities must arrange this naming between themselves.
-
-      Fifth, that the upward prefix referral chain topped out at ALPHA-
-      TLA.ORG.  There could have been another level which assigned the
-      TLA values and holds A6 records containing those bits.
-
-   Finally, the above structure reflects an assumption that address
-   fields assigned by a given entity are recorded only in A6 records
-   held by that entity.  Those bits could be entered into A6 records in
-   the lower-level entity's zone instead, thus:
-
-                IP6.X.EXAMPLE. A6 40 0:0:11::   IP6.A.NET.
-                IP6.X.EXAMPLE. A6 40 0:0:22::   IP6.B.NET.
-
-                IP6.A.NET.     A6 28 0:1:CA00:: IP6.C.NET.
-                and so on.
-
-   Or the higher-level entities could hold both sorts of A6 records
-   (with different DNS owner names) and allow the lower-level entities
-   to choose either mode of A6 chaining.  But the general principle of
-   avoiding data duplication suggests that the proper place to store
-   assigned values is with the entity that assigned them.
-
-   It is possible, but not necessarily recommended, for a zone
-   maintainer to forego the renumbering support afforded by the chaining
-   of A6 records and to record entire IPv6 addresses within one zone
-   file.
-
-
-
-Crawford, et al.            Standards Track                    [Page 12]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-5.2.  Reverse Mapping Zones
-
-   Supposing that address space assignments in the TLAs with Format
-   Prefix (001) binary and IDs 0345, 0678 and 09AB were maintained in
-   zones called ALPHA-TLA.ORG, BRAVO-TLA.ORG and CHARLIE-TLA.XY, then
-   the IP6.ARPA zone would include
-
-               $ORIGIN IP6.ARPA.
-               \[x234500/24]   DNAME   IP6.ALPHA-TLA.ORG.
-               \[x267800/24]   DNAME   IP6.BRAVO-TLA.ORG.
-               \[x29AB00/24]   DNAME   IP6.CHARLIE-TLA.XY.
-
-   Eight trailing zero bits have been included in each TLA ID to reflect
-   the eight reserved bits in the current aggregatable global unicast
-   addresses format [AGGR].
-
-5.2.1.  The TLA level
-
-   ALPHA-TLA's assignments to network providers C, D and E are reflected
-   in the reverse data as follows.
-
-              \[xC/4].IP6.ALPHA-TLA.ORG.   DNAME  IP6.C.NET.
-              \[xD/4].IP6.ALPHA-TLA.ORG.   DNAME  IP6.D.NET.
-              \[x0E/8].IP6.ALPHA-TLA.ORG.  DNAME  IP6.E.NET.
-
-5.2.2.  The ISP level
-
-   The providers A through E carry the following delegation information
-   in their zone files.
-
-               \[x1CA/12].IP6.C.NET.  DNAME  IP6.A.NET.
-               \[x2DA/12].IP6.D.NET.  DNAME  IP6.A.NET.
-               \[xEB/8].IP6.E.NET.    DNAME  IP6.B.NET.
-               \[x11/8].IP6.A.NET.    DNAME  IP6.X.EXAMPLE.
-               \[x22/8].IP6.B.NET.    DNAME  IP6.X.EXAMPLE.
-
-   Note that some domain names appear in the RDATA of more than one
-   DNAME record.  In those cases, one zone is being used to map multiple
-   prefixes.
-
-5.2.3.  The Site Level
-
-   Consider the customer X.EXAMPLE using IP6.X.EXAMPLE for address-to-
-   name translations.  This domain is now referenced by two different
-   DNAME records held by two different providers.
-
-
-
-
-
-
-Crawford, et al.            Standards Track                    [Page 13]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-           $ORIGIN IP6.X.EXAMPLE.
-           \[x0001/16]                    DNAME   SUBNET-1
-           \[x123456789ABCDEF0].SUBNET-1  PTR     N.X.EXAMPLE.
-           and so on.
-
-   SUBNET-1 need not have been named in a DNAME record; the subnet bits
-   could have been joined with the interface identifier.  But if subnets
-   are treated alike in both the A6 records and in the reverse zone, it
-   will always be possible to keep the forward and reverse definition
-   data for each prefix in one zone.
-
-5.3.  Lookups
-
-   A DNS resolver looking for a hostname for the address
-   2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 would acquire certain of the
-   DNAME records shown above and would form new queries.  Assuming that
-   it began the process knowing servers for IP6.ARPA, but that no server
-   it consulted provided recursion and none had other useful additional
-   information cached, the sequence of queried names and responses would
-   be (all with QCLASS=IN, QTYPE=PTR):
-
-   To a server for IP6.ARPA:
-   QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.ARPA.
-
-        Answer:
-        \[x234500/24].IP6.ARPA. DNAME IP6.ALPHA-TLA.ORG.
-
-   To a server for IP6.ALPHA-TLA.ORG:
-   QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG.
-
-        Answer:
-        \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.
-
-   To a server for IP6.C.NET.:
-   QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET.
-
-        Answer:
-        \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.
-
-   To a server for IP6.A.NET.:
-   QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET.
-
-        Answer:
-        \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.
-
-   To a server for IP6.X.EXAMPLE.:
-   QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE.
-
-
-
-
-Crawford, et al.            Standards Track                    [Page 14]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-        Answer:
-        \[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE.
-        \[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE.
-
-   All the DNAME (and NS) records acquired along the way can be cached
-   to expedite resolution of addresses topologically near to this
-   address.  And if another global address of N.X.EXAMPLE were resolved
-   within the TTL of the final PTR record, that record would not have to
-   be fetched again.
-
-5.4.  Operational Note
-
-   In the illustrations in section 5.1, hierarchically adjacent
-   entities, such as a network provider and a customer, must agree on a
-   DNS name which will own the definition of the delegated prefix(es).
-   One simple convention would be to use a bit-string label representing
-   exactly the bits which are assigned to the lower-level entity by the
-   higher.  For example, "SUBSCRIBER-X" could be replaced by "\[x11/8]".
-   This would place the A6 record(s) defining the delegated prefix at
-   exactly the same point in the DNS tree as the DNAME record associated
-   with that delegation.  The cost of this simplification is that the
-   lower-level zone must update its upward-pointing A6 records when it
-   is renumbered.  This cost may be found quite acceptable in practice.
-
-6.  Transition from RFC 1886 and Deployment Notes
-
-   When prefixes have been "delegated upward" with A6 records, the
-   number of DNS resource records required to establish a single IPv6
-   address increases by some non-trivial factor.  Those records will
-   typically, but not necessarily, come from different DNS zones (which
-   can independently suffer failures for all the usual reasons).  When
-   obtaining multiple IPv6 addresses together, this increase in RR count
-   will be proportionally less -- and the total size of a DNS reply
-   might even decrease -- if the addresses are topologically clustered.
-   But the records could still easily exceed the space available in a
-   UDP response which returns a large RRset [DNSCLAR] to an MX, NS, or
-   SRV query, for example.  The possibilities for overall degradation of
-   performance and reliability of DNS lookups are numerous, and increase
-   with the number of prefix delegations involved, especially when those
-   delegations point to records in other zones.
-
-   DNS Security [DNSSEC] addresses the trustworthiness of cached data,
-   which is a problem intrinsic to DNS, but the cost of applying this to
-   an IPv6 address is multiplied by a factor which may be greater than
-   the number of prefix delegations involved if different signature
-   chains must be verified for different A6 records.  If a trusted
-   centralized caching server (as in [TSIG], for example) is used, this
-   cost might be amortized to acceptable levels.  One new phenomenon is
-
-
-
-Crawford, et al.            Standards Track                    [Page 15]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-   the possibility that IPv6 addresses may be formed from a A6 records
-   from a combination of secure and unsecured zones.
-
-   Until more deployment experience is gained with the A6 record, it is
-   recommended that prefix delegations be limited to one or two levels.
-   A reasonable phasing-in mechanism would be to start with no prefix
-   delegations (all A6 records having prefix length 0) and then to move
-   to the use of a single level of delegation within a single zone.  (If
-   the TTL of the "prefix" A6 records is kept to an appropriate duration
-   the capability for rapid renumbering is not lost.)  More aggressively
-   flexible delegation could be introduced for a subset of hosts for
-   experimentation.
-
-6.1.  Transition from AAAA and Coexistence with A Records
-
-   Administrators of zones which contain A6 records can easily
-   accommodate deployed resolvers which understand AAAA records but not
-   A6 records.  Such administrators can do automatic generation of AAAA
-   records for all of a zone's names which own A6 records by a process
-   which mimics the resolution of a hostname to an IPv6 address (see
-   section 3.1.4).  Attention must be paid to the TTL assigned to a
-   generated AAAA record, which MUST be no more than the minimum of the
-   TTLs of the A6 records that were used to form the IPv6 address in
-   that record.  For full robustness, those A6 records which were in
-   different zones should be monitored for changes (in TTL or RDATA)
-   even when there are no changes to zone for which AAAA records are
-   being generated.  If the zone is secure [DNSSEC], the generated AAAA
-   records MUST be signed along with the rest of the zone data.
-
-   A zone-specific heuristic MAY be used to avoid generation of AAAA
-   records for A6 records which record prefixes, although such
-   superfluous records would be relatively few in number and harmless.
-   Examples of such heuristics include omitting A6 records with a prefix
-   length less than the largest value found in the zone file, or records
-   with an address suffix field with a certain number of trailing zero
-   bits.
-
-   On the client side, when looking up and IPv6 address, the order of A6
-   and AAAA queries MAY be configurable to be one of: A6, then AAAA;
-   AAAA, then A6; A6 only; or both in parallel.  The default order (or
-   only order, if not configurable) MUST be to try A6 first, then AAAA.
-   If and when the AAAA becomes deprecated a new document will change
-   the default.
-
-   The guidelines and options for precedence between IPv4 and IPv6
-   addresses are specified in [TRANS].  All mentions of AAAA records in
-   that document are henceforth to be interpreted as meaning A6 and/or
-   AAAA records in the order specified in the previous paragraph.
-
-
-
-Crawford, et al.            Standards Track                    [Page 16]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-6.2.  Transition from Nibble Labels to Binary Labels
-
-   Implementations conforming to RFC 1886 [AAAA] perform reverse lookups
-   as follows:
-
-      An IPv6 address is represented as a name in the IP6.INT domain by
-      a sequence of nibbles separated by dots with the suffix
-      ".IP6.INT". The sequence of nibbles is encoded in reverse order,
-      i.e. the low-order nibble is encoded first, followed by the next
-      low-order nibble and so on. Each nibble is represented by a
-      hexadecimal digit. For example, a name for the address
-      2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 of the example in section
-      5.3 would be sought at the DNS name "0.f.e.d.c.b.a.9.-
-      8.7.6.5.4.3.2.1.1.0.0.0.1.1.a.c.1.c.0.0.5.4.3.2.ip6.int."
-
-   Implementations conforming to this specification will perform a
-   lookup of a binary label in IP6.ARPA as specified in Section 3.2.  It
-   is RECOMMENDED that for a transition period implementations first
-   lookup the binary label in IP6.ARPA and if this fails try to lookup
-   the 'nibble' label in IP6.INT.
-
-7.  Security Considerations
-
-   The signing authority [DNSSEC] for the A6 records which determine an
-   IPv6 address is distributed among several entities, reflecting the
-   delegation path of the address space which that address occupies.
-   DNS Security is fully applicable to bit-string labels and DNAME
-   records.  And just as in IPv4, verification of name-to-address
-   mappings is logically independent of verification of address-to-name
-   mappings.
-
-   With or without DNSSEC, the incomplete but non-empty address set
-   scenario of section 3.1.4 could be caused by selective interference
-   with DNS lookups.  If in some situation this would be more harmful
-   than complete DNS failure, it might be mitigated on the client side
-   by refusing to act on an incomplete set, or on the server side by
-   listing all addresses in A6 records with prefix length 0.
-
-8.  IANA Considerations
-
-   The A6 resource record has been assigned a Type value of 38.
-
-
-
-
-
-
-
-
-
-
-Crawford, et al.            Standards Track                    [Page 17]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-9.  Acknowledgments
-
-   The authors would like to thank the following persons for valuable
-   discussions and reviews:  Mark Andrews, Rob Austein, Jim Bound, Randy
-   Bush, Brian Carpenter, David Conrad, Steve Deering, Francis Dupont,
-   Robert Elz, Bob Fink, Olafur Gudmundsson, Bob Halley, Bob Hinden,
-   Edward Lewis, Bill Manning, Keith Moore, Thomas Narten, Erik
-   Nordmark, Mike O'Dell, Michael Patton and Ken Powell.
-
-10.  References
-
-   [AAAA]    Thomson, S. and C. Huitema, "DNS Extensions to support IP
-             version 6, RFC 1886, December 1995.
-
-   [AARCH]   Hinden, R. and S. Deering, "IP Version 6 Addressing
-             Architecture", RFC 2373, July 1998.
-
-   [AGGR]    Hinden, R., O'Dell, M. and S. Deering, "An IPv6
-             Aggregatable Global Unicast Address Format", RFC 2374, July
-             1998.
-
-   [BITLBL]  Crawford, M., "Binary Labels in the Domain Name System",
-             RFC 2673, August 1999.
-
-   [DNAME]   Crawford, M., "Non-Terminal DNS Name Redirection", RFC
-             2672, August 1999.
-
-   [DNSCLAR] Elz, R. and R. Bush, "Clarifications to the DNS
-             Specification", RFC 2181, July 1997.
-
-   [DNSIS]   Mockapetris, P., "Domain names - implementation and
-             specification", STD 13, RFC 1035, November 1987.
-
-   [DNSSEC]  Eastlake, D. 3rd and C. Kaufman, "Domain Name System
-             Security Extensions", RFC 2535, March 1999.
-
-   [KWORD]   Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RENUM1]  Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
-             1900, February 1996.
-
-   [RENUM2]  Ferguson, P. and H. Berkowitz, "Network Renumbering
-             Overview:  Why would I want it and what is it anyway?", RFC
-             2071, January 1997.
-
-   [RENUM3]  Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
-             Behaviour Today", RFC 2101, February 1997.
-
-
-
-Crawford, et al.            Standards Track                    [Page 18]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-   [TRANS]   Gilligan, R. and E. Nordmark, "Transition Mechanisms for
-             IPv6 Hosts and Routers", RFC 1933, April 1996.
-
-   [TSIG]    Vixie, P., Gudmundsson, O., Eastlake, D. 3rd and B.
-             Wellington, "Secret Key Transaction Authentication for DNS
-             (TSIG)", RFC 2845, May 2000.
-
-11.  Authors' Addresses
-
-   Matt Crawford
-   Fermilab
-   MS 368
-   PO Box 500
-   Batavia, IL 60510
-   USA
-
-   Phone: +1 630 840-3461
-   EMail: crawdad@fnal.gov
-
-
-   Christian Huitema
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA 98052-6399
-
-   EMail: huitema@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crawford, et al.            Standards Track                    [Page 19]
-
-RFC 2874                        IPv6 DNS                       July 2000
-
-
-12.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crawford, et al.            Standards Track                    [Page 20]
-
diff --git a/contrib/bind9/doc/rfc/rfc2915.txt b/contrib/bind9/doc/rfc/rfc2915.txt
deleted file mode 100644
index 2022ba1..0000000
--- a/contrib/bind9/doc/rfc/rfc2915.txt
+++ /dev/null
@@ -1,1011 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         M. Mealling
-Request for Comments: 2915                        Network Solutions, Inc.
-Updates: 2168                                                   R. Daniel
-Category: Standards Track                                DATAFUSION, Inc.
-                                                           September 2000
-
-
-        The Naming Authority Pointer (NAPTR) DNS Resource Record
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-Abstract
-
-   This document describes a Domain Name System (DNS) resource record
-   which specifies a regular expression based rewrite rule that, when
-   applied to an existing string, will produce a new domain label or
-   Uniform Resource Identifier (URI).  Depending on the value of the
-   flags field of the resource record, the resulting domain label or URI
-   may be used in subsequent queries for the Naming Authority Pointer
-   (NAPTR) resource records (to delegate the name lookup) or as the
-   output of the entire process for which this system is used (a
-   resolution server for URI resolution, a service URI for ENUM style
-   e.164 number to URI mapping, etc).
-
-   This allows the DNS to be used to lookup services for a wide variety
-   of resource names (including URIs) which are not in domain name
-   syntax.  Reasons for doing this range from URN Resource Discovery
-   Systems to moving out-of-date services to new domains.
-
-   This document updates the portions of RFC 2168 specifically dealing
-   with the definition of the NAPTR records and how other, non-URI
-   specific applications, might use NAPTR.
-
-
-
-
-
-
-
-
-
-Mealling & Daniel           Standards Track                     [Page 1]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .   2
-   2.  NAPTR RR Format  . . . . . . . . . . . . . . . . . . . . . .   3
-   3.  Substitution Expression Grammar  . . . . . . . . . . . . . .   7
-   4.  The Basic NAPTR Algorithm  . . . . . . . . . . . . . . . . .   8
-   5.  Concerning How NAPTR Uses SRV Records  . . . . . . . . . . .   9
-   6.  Application Specifications . . . . . . . . . . . . . . . . .  10
-   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  10
-   7.1 Example 1  . . . . . . . . . . . . . . . . . . . . . . . . .  10
-   7.2 Example 2  . . . . . . . . . . . . . . . . . . . . . . . . .  12
-   7.3 Example 3  . . . . . . . . . . . . . . . . . . . . . . . . .  13
-   8.  DNS Packet Format  . . . . . . . . . . . . . . . . . . . . .  13
-   9.  Master File Format . . . . . . . . . . . . . . . . . . . . .  14
-   10. Advice for DNS Administrators  . . . . . . . . . . . . . . .  14
-   11. Notes  . . . . . . . . . . . . . . . . . . . . . . . . . . .  15
-   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . .  15
-   13. Security Considerations  . . . . . . . . . . . . . . . . . .  15
-   14. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  16
-       References . . . . . . . . . . . . . . . . . . . . . . . . .  16
-       Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  17
-       Full Copyright Statement . . . . . . . . . . . . . . . . . .  18
-
-1. Introduction
-
-   This RR was originally produced by the URN Working Group [3] as a way
-   to encode rule-sets in DNS so that the delegated sections of a URI
-   could be decomposed in such a way that they could be changed and re-
-   delegated over time.  The result was a Resource Record that included
-   a regular expression that would be used by a client program to
-   rewrite a string into a domain name.  Regular expressions were chosen
-   for their compactness to expressivity ratio allowing for a great deal
-   of information to be encoded in a rather small DNS packet.
-
-   The function of rewriting a string according to the rules in a record
-   has usefulness in several different applications.  This document
-   defines the basic assumptions to which all of those applications must
-   adhere to.  It does not define the reasons the rewrite is used, what
-   the expected outcomes are, or what they are used for.  Those are
-   specified by applications that define how they use the NAPTR record
-   and algorithms within their contexts.
-
-   Flags and other fields are also specified in the RR to control the
-   rewrite procedure in various ways or to provide information on how to
-   communicate with the host at the domain name that was the result of
-   the rewrite.
-
-
-
-
-
-Mealling & Daniel           Standards Track                     [Page 2]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-   The final result is a RR that has several fields that interact in a
-   non-trivial but implementable way.  This document specifies those
-   fields and their values.
-
-   This document does not define applications that utilizes this rewrite
-   functionality. Instead it specifies just the mechanics of how it is
-   done.  Why its done, what the rules concerning the inputs, and the
-   types of rules used are reserved for other documents that fully
-   specify a particular application.  This separation is due to several
-   different applications all wanting to take advantage of the rewrite
-   rule lookup process.  Each one has vastly different reasons for why
-   and how it uses the service, thus requiring that the definition of
-   the service be generic.
-
-      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.
-
-      All references to Uniform Resource Identifiers in this document
-      adhere to the 'absoluteURI' production of the "Collected ABNF"
-      found in RFC 2396 [9].  Specifically, the semantics of URI
-      References do not apply since the concept of a Base makes no sense
-      here.
-
-2. NAPTR RR Format
-
-   The format of the NAPTR RR is given below.  The DNS type code [1] for
-   NAPTR is 35.
-
-   Domain TTL Class Type Order Preference Flags Service Regexp
-   Replacement
-
-   Domain
-      The domain name to which this resource record refers.  This is the
-      'key' for this entry in the rule database.  This value will either
-      be the first well known key (<something>.uri.arpa for example) or
-      a new key that is the output of a replacement or regexp rewrite.
-      Beyond this, it has the standard DNS requirements [1].
-
-   TTL
-      Standard DNS meaning [1].
-
-   Class
-      Standard DNS meaning [1].
-
-   Type
-      The Type Code [1] for NAPTR is 35.
-
-
-
-
-Mealling & Daniel           Standards Track                     [Page 3]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-   Order
-      A 16-bit unsigned integer specifying the order in which the NAPTR
-      records MUST be processed to ensure the correct ordering of
-      rules.  Low numbers are processed before high numbers, and once a
-      NAPTR is found whose rule "matches" the target, the client MUST
-      NOT consider any NAPTRs with a higher value for order (except as
-      noted below for the Flags field).
-
-   Preference
-      A 16-bit unsigned integer that specifies the order in which NAPTR
-      records with equal "order" values SHOULD be processed, low
-      numbers being processed before high numbers.  This is similar to
-      the preference field in an MX record, and is used so domain
-      administrators can direct clients towards more capable hosts or
-      lighter weight protocols.  A client MAY look at records with
-      higher preference values if it has a good reason to do so such as
-      not understanding the preferred protocol or service.
-
-      The important difference between Order and Preference is that
-      once a match is found the client MUST NOT consider records with a
-      different Order but they MAY process records with the same Order
-      but different Preferences.  I.e., Preference is used to give weight
-      to rules that are considered the same from an authority
-      standpoint but not from a simple load balancing standpoint.
-
-   Flags
-      A <character-string> containing flags to control aspects of the
-      rewriting and interpretation of the fields in the record.  Flags
-      are single characters from the set [A-Z0-9].  The case of the
-      alphabetic characters is not significant.
-
-      At this time only four flags, "S", "A", "U", and "P", are
-      defined.  The "S", "A" and "U" flags denote a terminal lookup.
-      This means that this NAPTR record is the last one and that the
-      flag determines what the next stage should be.  The "S" flag
-      means that the next lookup should be for SRV records [4].  See
-      Section 5 for additional information on how NAPTR uses the SRV
-      record type.  "A" means that the next lookup should be for either
-      an A, AAAA, or A6 record.  The "U" flag means that the next step
-      is not a DNS lookup but that the output of the Regexp field is an
-      URI that adheres to the 'absoluteURI' production found in the
-      ABNF of RFC 2396 [9].  Since there may be applications that use
-      NAPTR to also lookup aspects of URIs, implementors should be
-      aware that this may cause loop conditions and should act
-      accordingly.
-
-
-
-
-
-
-Mealling & Daniel           Standards Track                     [Page 4]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-      The "P" flag says that the remainder of the application side
-      algorithm shall be carried out in a Protocol-specific fashion.
-      The new set of rules is identified by the Protocol specified in
-      the Services field.  The record that contains the 'P' flag is the
-      last record that is interpreted by the rules specified in this
-      document.  The new rules are dependent on the application for
-      which they are being used and the protocol specified.  For
-      example, if the application is a URI RDS and the protocol is WIRE
-      then the new set of rules are governed by the algorithms
-      surrounding the WIRE HTTP specification and not this document.
-
-      The remaining alphabetic flags are reserved for future versions
-      of the NAPTR specification.  The numeric flags may be used for
-      local experimentation.  The S, A, U and P flags are all mutually
-      exclusive, and resolution libraries MAY signal an error if more
-      than one is given.  (Experimental code and code for assisting in
-      the creation of NAPTRs would be more likely to signal such an
-      error than a client such as a browser).  It is anticipated that
-      multiple flags will be allowed in the future, so implementers
-      MUST NOT assume that the flags field can only contain 0 or 1
-      characters.  Finally, if a client encounters a record with an
-      unknown flag, it MUST ignore it and move to the next record.  This
-      test takes precedence even over the "order" field.  Since flags
-      can control the interpretation placed on fields, a novel flag
-      might change the interpretation of the regexp and/or replacement
-      fields such that it is impossible to determine if a record
-      matched a given target.
-
-      The "S", "A", and "U"  flags are called 'terminal' flags since
-      they halt the looping rewrite algorithm.  If those flags are not
-      present, clients may assume that another NAPTR RR exists at the
-      domain name produced by the current rewrite rule.  Since the "P"
-      flag specifies a new algorithm, it may or may not be 'terminal'.
-      Thus, the client cannot assume that another NAPTR exists since
-      this case is determined elsewhere.
-
-      DNS servers MAY interpret these flags and values and use that
-      information to include appropriate SRV and A,AAAA, or A6 records
-      in the additional information portion of the DNS packet.  Clients
-      are encouraged to check for additional information but are not
-      required to do so.
-
-   Service
-      Specifies the service(s) available down this rewrite path.  It may
-      also specify the particular protocol that is used to talk with a
-      service.  A protocol MUST be specified if the flags field states
-      that the NAPTR is terminal.  If a protocol is specified, but the
-      flags field does not state that the NAPTR is terminal, the next
-
-
-
-Mealling & Daniel           Standards Track                     [Page 5]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-      lookup MUST be for a NAPTR.  The client MAY choose not to perform
-      the next lookup if the protocol is unknown, but that behavior
-      MUST NOT be relied upon.
-
-      The service field may take any of the values below (using the
-      Augmented BNF of RFC 2234 [5]):
-
-                 service_field = [ [protocol] *("+" rs)]
-                 protocol      = ALPHA *31ALPHANUM
-                 rs            = ALPHA *31ALPHANUM
-                 ; The protocol and rs fields are limited to 32
-                 ; characters and must start with an alphabetic.
-
-      For example, an optional protocol specification followed by 0 or
-      more resolution services.  Each resolution service is indicated by
-      an initial '+' character.
-
-      Note that the empty string is also a valid service field.  This
-      will typically be seen at the beginning of a series of rules,
-      when it is impossible to know what services and protocols will be
-      offered by a particular service.
-
-      The actual format of the service request and response will be
-      determined by the resolution protocol, and is the subject for
-      other documents.  Protocols need not offer all services.  The
-      labels for service requests shall be formed from the set of
-      characters [A-Z0-9].  The case of the alphabetic characters is
-      not significant.
-
-      The list of "valid" protocols for any given NAPTR record is any
-      protocol that implements some or all of the services defined for
-      a NAPTR application.  Currently, THTTP [6] is the only protocol
-      that is known to make that claim at the time of publication.  Any
-      other protocol that is to be used must have documentation
-      specifying:
-
-      *  how it implements the services of the application
-
-      *  how it is to appear in the NAPTR record (i.e., the string id
-         of the protocol)
-
-      The list of valid Resolution Services is defined by the documents
-      that specify individual NAPTR based applications.
-
-      It is worth noting that the interpretation of this field is
-      subject to being changed by new flags, and that the current
-      specification is oriented towards telling clients how to talk
-      with a URN resolver.
-
-
-
-Mealling & Daniel           Standards Track                     [Page 6]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-   Regexp
-      A STRING containing a substitution expression that is applied to
-      the original string held by the client in order to construct the
-      next domain name to lookup.  The grammar of the substitution
-      expression is given in the next section.
-
-      The regular expressions MUST NOT be used in a cumulative fashion,
-      that is, they should only be applied to the original string held
-      by the client, never to the domain name produced by a previous
-      NAPTR rewrite.  The latter is tempting in some applications but
-      experience has shown such use to be extremely fault sensitive,
-      very error prone, and extremely difficult to debug.
-
-   Replacement
-      The next NAME to query for NAPTR, SRV, or address records
-      depending on the value of the flags field.  This MUST be a fully
-      qualified domain-name. Unless and until permitted by future
-      standards action, name compression is not to be used for this
-      field.
-
-3. Substitution Expression Grammar
-
-   The content of the regexp field is a substitution expression.  True
-   sed(1) and Perl style substitution expressions are not appropriate
-   for use in this application for a variety of reasons stemming from
-   internationalization requirements and backref limitations, therefore
-   the contents of the regexp field MUST follow the grammar below:
-
-subst_expr   = delim-char  ere  delim-char  repl  delim-char  *flags
-delim-char   = "/" / "!" / ... <Any non-digit or non-flag character
-               other than backslash '\'. All occurances of a delim_char
-               in a subst_expr must be the same character.>
-ere          = POSIX Extended Regular Expression
-repl         = 1 * ( OCTET /  backref )
-backref      = "\" 1POS_DIGIT
-flags        = "i"
-POS_DIGIT    = %x31-39                 ; 0 is not an allowed backref
-
-   The definition of a POSIX Extended Regular Expression can be found in
-   [8], section 2.8.4.
-
-   The result of applying the substitution expression to the original
-   URI MUST result in either a string that obeys the syntax for DNS
-   domain-names [1] or a URI [9] if the Flags field contains a 'u'.
-   Since it is possible for the regexp field to be improperly specified,
-   such that a non-conforming domain-name can be constructed, client
-   software SHOULD verify that the result is a legal DNS domain-name
-   before making queries on it.
-
-
-
-Mealling & Daniel           Standards Track                     [Page 7]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-   Backref expressions in the repl portion of the substitution
-   expression are replaced by the (possibly empty) string of characters
-   enclosed by '(' and ')' in the ERE portion of the substitution
-   expression. N is a single digit from 1 through 9, inclusive.  It
-   specifies the N'th backref expression, the one that begins with the
-   N'th '(' and continues to the matching ')'.  For example, the ERE
-
-                            (A(B(C)DE)(F)G)
-
-         has backref expressions:
-
-                            \1  = ABCDEFG
-                            \2  = BCDE
-                            \3  = C
-                            \4  = F
-                            \5..\9  = error - no matching subexpression
-
-   The "i" flag indicates that the ERE matching SHALL be performed in a
-   case-insensitive fashion. Furthermore, any backref replacements MAY
-   be normalized to lower case when the "i" flag is given.
-
-   The first character in the substitution expression shall be used as
-   the character that delimits the components of the substitution
-   expression.  There must be exactly three non-escaped occurrences of
-   the delimiter character in a substitution expression.  Since escaped
-   occurrences of the delimiter character will be interpreted as
-   occurrences of that character, digits MUST NOT be used as delimiters.
-   Backrefs would be confused with literal digits were this allowed.
-   Similarly, if flags are specified in the substitution expression, the
-   delimiter character must not also be a flag character.
-
-4. The Basic NAPTR Algorithm
-
-   The behavior and meaning of the flags and services assume an
-   algorithm where the output of one rewrite is a new key that points to
-   another rule.  This looping algorithm allows NAPTR records to
-   incrementally specify a complete rule.  These incremental rules can
-   be delegated which allows other entities to specify rules so that one
-   entity does not need to understand _all_ rules.
-
-   The algorithm starts with a string and some known key (domain).
-   NAPTR records for this key are retrieved, those with unknown Flags or
-   inappropriate Services are discarded and the remaining records are
-   sorted by their Order field.  Within each value of Order, the records
-   are further sorted by the Preferences field.
-
-   The records are examined in sorted order until a matching record is
-   found.  A record is considered a match iff:
-
-
-
-Mealling & Daniel           Standards Track                     [Page 8]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-   o  it has a Replacement field value instead of a Regexp field value.
-
-   o  or the Regexp field matches the string held by the client.
-
-   The first match MUST be the match that is used.  Once a match is
-   found, the Services field is examined for whether or not this rule
-   advances toward the desired result.  If so, the rule is applied to
-   the target string.  If not, the process halts.  The domain that
-   results from the regular expression is then used as the domain of the
-   next loop through the NAPTR algorithm.  Note that the same target
-   string is used throughout the algorithm.
-
-   This looping is extremely important since it is the method by which
-   complex rules are broken down into manageable delegated chunks.  The
-   flags fields simply determine at which point the looping should stop
-   (or other specialized behavior).
-
-   Since flags are valid at any level of the algorithm, the degenerative
-   case is to never loop but to look up the NAPTR and then stop.  In
-   many specialized cases this is all that is needed.  Implementors
-   should be aware that the degenerative case should not become the
-   common case.
-
-5. Concerning How NAPTR Uses SRV Records
-
-   When the SRV record type was originally specified it assumed that the
-   client did not know the specific domain-name before hand.  The client
-   would construct a domain-name more in the form of a question than the
-   usual case of knowing ahead of time that the domain-name should
-   exist.  I.e., if the client wants to know if there is a TCP based
-   HTTP server running at a particular domain, the client would
-   construct the domain-name _http._tcp.somedomain.com and ask the DNS
-   if that records exists. The underscores are used to avoid collisions
-   with potentially 'real' domain-names.
-
-   In the case of NAPTR, the actual domain-name is specified by the
-   various fields in the NAPTR record.  In this case the client isn't
-   asking a question but is instead attempting to get at information
-   that it has been told exists in an SRV record at that particular
-   domain-name.  While this usage of SRV is slightly different than the
-   SRV authors originally intended it does not break any of the
-   assumptions concerning what SRV contains.  Also, since the NAPTR
-   explicitly spells out the domain-name for which an SRV exists, that
-   domain-name MUST be used in SRV queries with NO transformations.  Any
-   given NAPTR record may result in a domain-name to be used for SRV
-   queries that may or may not contain the SRV standardized underscore
-
-
-
-
-
-Mealling & Daniel           Standards Track                     [Page 9]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-   characters.  NAPTR applications that make use of SRV MUST NOT attempt
-   to understand these domains or use them according to how the SRV
-   specification structures its query domains.
-
-6. Application Specifications
-
-   It should be noted that the NAPTR algorithm is the basic assumption
-   about how NAPTR works.  The reasons for the rewrite and the expected
-   output and its use are specified by documents that define what
-   applications the NAPTR record and algorithm are used for.  Any
-   document that defines such an application must define the following:
-
-   o  The first known domain-name or how to build it
-
-   o  The valid Services and Protocols
-
-   o  What the expected use is for the output of the last rewrite
-
-   o  The validity and/or behavior of any 'P' flag protocols.
-
-   o  The general semantics surrounding why and how NAPTR and its
-      algorithm are being used.
-
-7. Examples
-
-   NOTE: These are examples only.  They are taken from ongoing work and
-   may not represent the end result of that work. They are here for
-   pedagogical reasons only.
-
-7.1 Example 1
-
-   NAPTR was originally specified for use with the a Uniform Resource
-   Name Resolver Discovery System.  This example details how a
-   particular URN would use the NAPTR record to find a resolver service.
-
-   Consider a URN namespace based on MIME Content-Ids.  The URN might
-   look like this:
-
-      urn:cid:39CB83F7.A8450130@fake.gatech.edu
-
-   (Note that this example is chosen for pedagogical purposes, and does
-   not conform to the CID URL scheme.)
-
-   The first step in the resolution process is to find out about the CID
-   namespace.  The namespace identifier [3], 'cid', is extracted from
-   the URN, prepended to urn.arpa. 'cid.urn.arpa' then becomes the first
-   'known' key in the NAPTR algorithm.  The NAPTR records for
-   cid.urn.arpa looked up and return a single record:
-
-
-
-Mealling & Daniel           Standards Track                    [Page 10]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-   cid.urn.arpa.
-   ;;       order pref flags service        regexp           replacement
-   IN NAPTR 100   10   ""  ""  "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i"    .
-
-   There is only one NAPTR response, so ordering the responses is not a
-   problem.  The replacement field is empty, so the pattern provided in
-   the regexp field is used.  We apply that regexp to the entire URN to
-   see if it matches, which it does.  The \2 part of the substitution
-   expression returns the string "gatech.edu".  Since the flags field
-   does not contain "s" or "a", the lookup is not terminal and our next
-   probe to DNS is for more NAPTR records where the new domain is '
-   gatech.edu' and the string is the same string as before.
-
-   Note that the rule does not extract the full domain name from the
-   CID, instead it assumes the CID comes from a host and extracts its
-   domain.  While all hosts, such as mordred, could have their very own
-   NAPTR, maintaining those records for all the machines at a site as
-   large as Georgia Tech would be an intolerable burden.  Wildcards are
-   not appropriate here since they only return results when there is no
-   exactly matching names already in the system.
-
-   The record returned from the query on "gatech.edu" might look like:
-
-;;       order pref flags service           regexp  replacement
- IN NAPTR 100  50  "s"  "z3950+I2L+I2C"     ""  _z3950._tcp.gatech.edu.
- IN NAPTR 100  50  "s"  "rcds+I2C"          ""  _rcds._udp.gatech.edu.
- IN NAPTR 100  50  "s"  "http+I2L+I2C+I2R"  ""  _http._tcp.gatech.edu.
-
-   Continuing with the example, note that the values of the order and
-   preference fields are equal in all records, so the client is free to
-   pick any record.  The flags field tells us that these are the last
-   NAPTR patterns we should see, and after the rewrite (a simple
-   replacement in this case) we should look up SRV records to get
-   information on the hosts that can provide the necessary service.
-
-   Assuming we prefer the Z39.50 protocol, our lookup might return:
-
- ;;                        Pref Weight   Port Target
- _z3950._tcp.gatech.edu. IN SRV 0    0      1000 z3950.gatech.edu.
-                         IN SRV 0    0      1000 z3950.cc.gatech.edu.
-                         IN SRV 0    0      1000 z3950.uga.edu.
-
-   telling us three hosts that could actually do the resolution, and
-   giving us the port we should use to talk to their Z39.50 server.
-
-   Recall that the regular expression used \2 to extract a domain name
-   from the CID, and \. for matching the literal '.' characters
-   separating the domain name components. Since '\' is the escape
-
-
-
-Mealling & Daniel           Standards Track                    [Page 11]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-   character, literal occurances of a backslash must be escaped by
-   another backslash.  For the case of the cid.urn.arpa record above,
-   the regular expression entered into the master file should be
-   "/urn:cid:.+@([^\\.]+\\.)(.*)$/\\2/i".  When the client code actually
-   receives the record, the pattern will have been converted to
-   "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i".
-
-7.2 Example 2
-
-   Even if URN systems were in place now, there would still be a
-   tremendous number of URLs.  It should be possible to develop a URN
-   resolution system that can also provide location independence for
-   those URLs.  This is related to the requirement that URNs be able to
-   grandfather in names from other naming systems, such as ISO Formal
-   Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs,
-   etc.
-
-   The NAPTR RR could also be used for URLs that have already been
-   assigned.  Assume we have the URL for a very popular piece of
-   software that the publisher wishes to mirror at multiple sites around
-   the world:
-
-   Using the rules specified for this application we extract the prefix,
-   "http", and lookup NAPTR records for http.uri.arpa.  This might
-   return a record of the form
-
-     http.uri.arpa. IN NAPTR
-     ;;  order   pref flags service      regexp             replacement
-          100     90   ""      ""   "!http://([^/:]+)!\1!i"       .
-
-   This expression returns everything after the first double slash and
-   before the next slash or colon.  (We use the '!' character to delimit
-   the parts of the substitution expression.  Otherwise we would have to
-   use backslashes to escape the forward slashes and would have a regexp
-   in the zone file that looked like "/http:\\/\\/([^\\/:]+)/\\1/i".).
-
-   Applying this pattern to the URL extracts "www.foo.com".  Looking up
-   NAPTR records for that might return:
-
-     www.foo.com.
-     ;;       order pref flags   service  regexp     replacement
-      IN NAPTR 100  100  "s"   "http+I2R"   ""    _http._tcp.foo.com.
-      IN NAPTR 100  100  "s"   "ftp+I2R"    ""    _ftp._tcp.foo.com.
-
-   Looking up SRV records for http.tcp.foo.com would return information
-   on the hosts that foo.com has designated to be its mirror sites.  The
-   client can then pick one for the user.
-
-
-
-
-Mealling & Daniel           Standards Track                    [Page 12]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-7.3 Example 3
-
-   A non-URI example is the ENUM application which uses a NAPTR record
-   to map an e.164 telephone number to a URI.  In order to convert the
-   phone number to a domain name for the first iteration all characters
-   other than digits are removed from the the telephone number, the
-   entire number is inverted, periods are put between each digit and the
-   string ".e164.arpa" is put on the left-hand side.  For example, the
-   E.164 phone number "+1-770-555-1212" converted to a domain-name it
-   would be "2.1.2.1.5.5.5.0.7.7.1.e164.arpa."
-
-   For this example telephone number we might get back the following
-   NAPTR records:
-
-$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa.
- IN NAPTR 100 10 "u" "sip+E2U"  "!^.*$!sip:information@tele2.se!"     .
- IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:information@tele2.se!"  .
-
-   This application uses the same 'u' flag as the URI Resolution
-   application. This flag states that the Rule is terminal and that the
-   output is a URI which contains the information needed to contact that
-   telephone service.  ENUM also uses the same format for its Service
-   field except that it defines the 'E2U' service instead of the 'I2*'
-   services that URI resolution uses.  The example above states that the
-   available protocols used to access that telephone's service are
-   either the Session Initiation Protocol or SMTP mail.
-
-8. DNS Packet Format
-
-         The packet format for the NAPTR record is:
-
-                                          1  1  1  1  1  1
-            0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          |                     ORDER                     |
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          |                   PREFERENCE                  |
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          /                     FLAGS                     /
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          /                   SERVICES                    /
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          /                    REGEXP                     /
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-          /                  REPLACEMENT                  /
-          /                                               /
-          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-
-
-
-Mealling & Daniel           Standards Track                    [Page 13]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-    where:
-
-   FLAGS A <character-string> which contains various flags.
-
-   SERVICES A <character-string> which contains protocol and service
-      identifiers.
-
-   REGEXP A <character-string> which contains a regular expression.
-
-   REPLACEMENT A <domain-name> which specifies the new value in the
-      case where the regular expression is a simple replacement
-      operation.
-
-   <character-string> and <domain-name> as used here are defined in
-   RFC1035 [1].
-
-9. Master File Format
-
-   The master file format follows the standard rules in RFC-1035 [1].
-   Order and preference, being 16-bit unsigned integers, shall be an
-   integer between 0 and 65535.  The Flags and Services and Regexp
-   fields are all quoted <character-string>s.  Since the Regexp field
-   can contain numerous backslashes and thus should be treated with
-   care.  See Section 10 for how to correctly enter and escape the
-   regular expression.
-
-10. Advice for DNS Administrators
-
-   Beware of regular expressions.  Not only are they difficult to get
-   correct on their own, but there is the previously mentioned
-   interaction with DNS.  Any backslashes in a regexp must be entered
-   twice in a zone file in order to appear once in a query response.
-   More seriously, the need for double backslashes has probably not been
-   tested by all implementors of DNS servers.
-
-   The "a" flag allows the next lookup to be for address records (A,
-   AAAA, A6) rather than SRV records.  Since there is no place for a
-   port specification in the NAPTR record, when the "A" flag is used the
-   specified protocol must be running on its default port.
-
-   The URN Syntax draft defines a canonical form for each URN, which
-   requires %encoding characters outside a limited repertoire.  The
-   regular expressions MUST be written to operate on that canonical
-   form.  Since international character sets will end up with extensive
-   use of %encoded characters, regular expressions operating on them
-   will be essentially impossible to read or write by hand.
-
-
-
-
-
-Mealling & Daniel           Standards Track                    [Page 14]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-11. Notes
-
-   o  A client MUST process multiple NAPTR records in the order
-      specified by the "order" field, it MUST NOT simply use the first
-      record that provides a known protocol and service combination.
-
-   o  When multiple RRs have the same "order" and all other criteria
-      being equal, the client should use the value of the preference
-      field to select the next NAPTR to consider.  However, because it
-      will often be the case where preferred protocols or services
-      exist, clients may use this additional criteria to sort
-      the records.
-
-   o  If the lookup after a rewrite fails, clients are strongly
-      encouraged to report a failure, rather than backing up to pursue
-      other rewrite paths.
-
-   o  Note that SRV RRs impose additional requirements on clients.
-
-12. IANA Considerations
-
-   The only registration function that impacts the IANA is for the
-   values that are standardized for the Services and Flags fields.  To
-   extend the valid values of the Flags field beyond what is specified
-   in this document requires a published specification that is approved
-   by the IESG.
-
-   The values for the Services field will be determined by the
-   application that makes use of the NAPTR record.  Those values must be
-   specified in a published specification and approved by the IESG.
-
-13. Security Considerations
-
-   The interactions with DNSSEC are currently being studied.  It is
-   expected that NAPTR records will be signed with SIG records once the
-   DNSSEC work is deployed.
-
-   The rewrite rules make identifiers from other namespaces subject to
-   the same attacks as normal domain names.  Since they have not been
-   easily resolvable before, this may or may not be considered a
-   problem.
-
-   Regular expressions should be checked for sanity, not blindly passed
-   to something like PERL.
-
-   This document has discussed a way of locating a service, but has not
-   discussed any detail of how the communication with that service takes
-   place.  There are significant security considerations attached to the
-
-
-
-Mealling & Daniel           Standards Track                    [Page 15]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-   communication with a service.  Those considerations are outside the
-   scope of this document, and must be addressed by the specifications
-   for particular communication protocols.
-
-14. Acknowledgments
-
-   The editors would like to thank Keith Moore for all his consultations
-   during the development of this memo.  We would also like to thank
-   Paul Vixie for his assistance in debugging our implementation, and
-   his answers on our questions.  Finally, we would like to acknowledge
-   our enormous intellectual debt to the participants in the Knoxville
-   series of meetings, as well as to the participants in the URI and URN
-   working groups.
-
-References
-
-   [1]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [2]  Mockapetris, P., "Domain names - concepts and facilities", STD
-        13, RFC 1034, November 1987.
-
-   [3]  Moats, R., "URN Syntax", RFC 2141, May 1997.
-
-   [4]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
-        specifying the location of services (DNS SRV)", RFC 2782,
-        February 2000.
-
-   [5]  Crocker, D., "Augmented BNF for Syntax Specifications: ABNF",
-        RFC 2234, November 1997.
-
-   [6]  Daniel, R., "A Trivial Convention for using HTTP in URN
-        Resolution", RFC 2169, June 1997.
-
-   [7]  Daniel, R. and M. Mealling, "Resolution of Uniform Resource
-        Identifiers using the Domain Name System", RFC 2168, June 1997.
-
-   [8]  IEEE, "IEEE Standard for Information Technology - Portable
-        Operating System Interface (POSIX) - Part 2: Shell and Utilities
-        (Vol. 1)", IEEE Std 1003.2-1992, January 1993.
-
-   [9]  Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform
-        Resource Identifiers (URI): Generic Syntax", RFC 2396, August
-        1998.
-
-
-
-
-
-
-
-Mealling & Daniel           Standards Track                    [Page 16]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-Authors' Addresses
-
-   Michael Mealling
-   Network Solutions, Inc.
-   505 Huntmar Park Drive
-   Herndon, VA  22070
-   US
-
-   Phone: +1 770 921 2251
-   EMail: michaelm@netsol.com
-   URI:   http://www.netsol.com
-
-
-   Ron Daniel
-   DATAFUSION, Inc.
-   139 Townsend Street, Ste. 100
-   San Francisco, CA  94107
-   US
-
-   Phone: +1 415 222 0100
-   EMail: rdaniel@datafusion.net
-   URI:   http://www.datafusion.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mealling & Daniel           Standards Track                    [Page 17]
-
-RFC 2915                      NAPTR DNS RR                September 2000
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mealling & Daniel           Standards Track                    [Page 18]
-
diff --git a/contrib/bind9/doc/rfc/rfc2929.txt b/contrib/bind9/doc/rfc/rfc2929.txt
deleted file mode 100644
index f055968..0000000
--- a/contrib/bind9/doc/rfc/rfc2929.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                   D. Eastlake, 3rd
-Request for Comments: 2929                                      Motorola
-BCP: 42                                              E. Brunner-Williams
-Category: Best Current Practice                                   Engage
-                                                              B. Manning
-                                                                     ISI
-                                                          September 2000
-
-              Domain Name System (DNS) IANA Considerations
-
-Status of this Memo
-
-   This document specifies an Internet Best Current Practices for the
-   Internet Community, and requests discussion and suggestions for
-   improvements.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   Internet Assigned Number Authority (IANA) parameter assignment
-   considerations are given for the allocation of Domain Name System
-   (DNS) classes, Resource Record (RR) types, operation codes, error
-   codes, etc.
-
-Table of Contents
-
-   1. Introduction.................................................  2
-   2. DNS Query/Response Headers...................................  2
-   2.1 One Spare Bit?..............................................  3
-   2.2 Opcode Assignment...........................................  3
-   2.3 RCODE Assignment............................................  4
-   3. DNS Resource Records.........................................  5
-   3.1 RR TYPE IANA Considerations.................................  6
-   3.1.1 Special Note on the OPT RR................................  7
-   3.2 RR CLASS IANA Considerations................................  7
-   3.3 RR NAME Considerations......................................  8
-   4. Security Considerations......................................  9
-   References......................................................  9
-   Authors' Addresses.............................................. 11
-   Full Copyright Statement........................................ 12
-
-
-
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                  [Page 1]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-1. Introduction
-
-   The Domain Name System (DNS) provides replicated distributed secure
-   hierarchical databases which hierarchically store "resource records"
-   (RRs) under domain names.
-
-   This data is structured into CLASSes and zones which can be
-   independently maintained.  See [RFC 1034, 1035, 2136, 2181, 2535]
-   familiarity with which is assumed.
-
-   This document covers, either directly or by reference, general IANA
-   parameter assignment considerations applying across DNS query and
-   response headers and all RRs.  There may be additional IANA
-   considerations that apply to only a particular RR type or
-   query/response opcode.  See the specific RFC defining that RR type or
-   query/response opcode for such considerations if they have been
-   defined.
-
-   IANA currently maintains a web page of DNS parameters.  See
-   <http://www.iana.org/numbers.htm>.
-
-   "IETF Standards Action", "IETF Consensus", "Specification Required",
-   and "Private Use" are as defined in [RFC 2434].
-
-2. DNS Query/Response Headers
-
-   The header for DNS queries and responses contains field/bits in the
-   following diagram taken from [RFC 2136, 2535]:
-
-                                           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  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |                QDCOUNT/ZOCOUNT                |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |                ANCOUNT/PRCOUNT                |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |                NSCOUNT/UPCOUNT                |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-            |                    ARCOUNT                    |
-            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   The ID field identifies the query and is echoed in the response so
-   they can be matched.
-
-
-
-
-Eastlake, et al.         Best Current Practice                  [Page 2]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-   The QR bit indicates whether the header is for a query or a response.
-
-   The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
-   only in queries or only in responses, depending on the bit.  However,
-   many DNS implementations copy the query header as the initial value
-   of the response header without clearing bits.  Thus any attempt to
-   use a "query" bit with a different meaning in a response or to define
-   a query meaning for a "response" bit is dangerous given existing
-   implementation.  Such meanings may only be assigned by an IETF
-   Standards Action.
-
-   The unsigned fields query count (QDCOUNT), answer count (ANCOUNT),
-   authority count (NSCOUNT), and additional information count (ARCOUNT)
-   express the number of records in each section for all opcodes except
-   Update.  These fields have the same structure and data type for
-   Update but are instead the counts for the zone (ZOCOUNT),
-   prerequisite (PRCOUNT), update (UPCOUNT), and additional information
-   (ARCOUNT) sections.
-
-2.1 One Spare Bit?
-
-   There have been ancient DNS implementations for which the Z bit being
-   on in a query meant that only a response from the primary server for
-   a zone is acceptable.  It is believed that current DNS
-   implementations ignore this bit.
-
-   Assigning a meaning to the Z bit requires an IETF Standards Action.
-
-2.2 Opcode Assignment
-
-   New OpCode assignments require an IETF Standards Action.
-
-   Currently DNS OpCodes are assigned as follows:
-
-       OpCode Name                      Reference
-
-        0     Query                     [RFC 1035]
-        1     IQuery  (Inverse Query)   [RFC 1035]
-        2     Status                    [RFC 1035]
-        3     available for assignment
-        4     Notify                    [RFC 1996]
-        5     Update                    [RFC 2136]
-       6-15   available for assignment
-
-
-
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                  [Page 3]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-2.3 RCODE Assignment
-
-   It would appear from the DNS header above that only four bits of
-   RCODE, or response/error code are available.  However, RCODEs can
-   appear not only at the top level of a DNS response but also inside
-   OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930].
-   The OPT RR provides an eight bit extension resulting in a 12 bit
-   RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field.
-
-   Error codes appearing in the DNS header and in these three RR types
-   all refer to the same error code space with the single exception of
-   error code 16 which has a different meaning in the OPT RR from its
-   meaning in other contexts.  See table below.
-
-   RCODE   Name    Description                        Reference
-   Decimal
-     Hexadecimal
-    0    NoError   No Error                           [RFC 1035]
-    1    FormErr   Format Error                       [RFC 1035]
-    2    ServFail  Server Failure                     [RFC 1035]
-    3    NXDomain  Non-Existent Domain                [RFC 1035]
-    4    NotImp    Not Implemented                    [RFC 1035]
-    5    Refused   Query Refused                      [RFC 1035]
-    6    YXDomain  Name Exists when it should not     [RFC 2136]
-    7    YXRRSet   RR Set Exists when it should not   [RFC 2136]
-    8    NXRRSet   RR Set that should exist does not  [RFC 2136]
-    9    NotAuth   Server Not Authoritative for zone  [RFC 2136]
-   10    NotZone   Name not contained in zone         [RFC 2136]
-   11-15           available for assignment
-   16    BADVERS   Bad OPT Version                    [RFC 2671]
-   16    BADSIG    TSIG Signature Failure             [RFC 2845]
-   17    BADKEY    Key not recognized                 [RFC 2845]
-   18    BADTIME   Signature out of time window       [RFC 2845]
-   19    BADMODE   Bad TKEY Mode                      [RFC 2930]
-   20    BADNAME   Duplicate key name                 [RFC 2930]
-   21    BADALG    Algorithm not supported            [RFC 2930]
-   22-3840         available for assignment
-     0x0016-0x0F00
-   3841-4095       Private Use
-     0x0F01-0x0FFF
-   4096-65535      available for assignment
-     0x1000-0xFFFF
-
-   Since it is important that RCODEs be understood for interoperability,
-   assignment of new RCODE listed above as "available for assignment"
-   requires an IETF Consensus.
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                  [Page 4]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-3. DNS Resource Records
-
-   All RRs have the same top level format shown in the figure below
-   taken from [RFC 1035]:
-
-                                         1  1  1  1  1  1
-           0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-         |                                               |
-         /                                               /
-         /                      NAME                     /
-         |                                               |
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-         |                      TYPE                     |
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-         |                     CLASS                     |
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-         |                      TTL                      |
-         |                                               |
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-         |                   RDLENGTH                    |
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
-         /                     RDATA                     /
-         /                                               /
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   NAME is an owner name, i.e., the name of the node to which this
-   resource record pertains.  NAMEs are specific to a CLASS as described
-   in section 3.2.  NAMEs consist of an ordered sequence of one or more
-   labels each of which has a label type [RFC 1035, 2671].
-
-   TYPE is a two octet unsigned integer containing one of the RR TYPE
-   codes.  See section 3.1.
-
-   CLASS is a two octet unsigned integer containing one of the RR CLASS
-   codes.  See section 3.2.
-
-   TTL is a four octet (32 bit) bit unsigned integer that specifies the
-   number of seconds that the resource record may be cached before the
-   source of the information should again be consulted.  Zero is
-   interpreted to mean that the RR can only be used for the transaction
-   in progress.
-
-   RDLENGTH is an unsigned 16 bit integer that specifies the length in
-   octets of the RDATA field.
-
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                  [Page 5]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-   RDATA is a variable length string of octets that constitutes the
-   resource.  The format of this information varies according to the
-   TYPE and in some cases the CLASS of the resource record.
-
-3.1 RR TYPE IANA Considerations
-
-   There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
-   and MetaTYPEs.
-
-   Data TYPEs are the primary means of storing data.  QTYPES can only be
-   used in queries.  Meta-TYPEs designate transient data associated with
-   an particular DNS message and in some cases can also be used in
-   queries.  Thus far, data TYPEs have been assigned from 1 upwards plus
-   the block from 100 through 103 while Q and Meta Types have been
-   assigned from 255 downwards (except for the OPT Meta-RR which is
-   assigned TYPE 41).  There have been DNS implementations which made
-   caching decisions based on the top bit of the bottom byte of the RR
-   TYPE.
-
-   There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG
-   [RFC 2845], and TKEY [RFC 2930].
-
-   There are currently five QTYPEs assigned: * (all), MAILA, MAILB,
-   AXFR, and IXFR.
-
-   Considerations for the allocation of new RR TYPEs are as follows:
-
-     Decimal
-   Hexadecimal
-
-     0
-   0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC
-          2535] and in other circumstances and must never be allocated
-          for ordinary use.
-
-     1 - 127
-   0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
-          TYPEs by IETF Consensus.
-
-     128 - 255
-   0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
-          Meta TYPEs by IETF Consensus.
-
-     256 - 32767
-   0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by IETF
-          Consensus.
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                  [Page 6]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-     32768 - 65279
-   0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
-
-     65280 - 65535
-   0xFF00 - 0xFFFF - Private Use.
-
-3.1.1 Special Note on the OPT RR
-
-   The OPT (OPTion) RR, number 41, is specified in [RFC 2671].  Its
-   primary purpose is to extend the effective field size of various DNS
-   fields including RCODE, label type, flag bits, and RDATA size.  In
-   particular, for resolvers and servers that recognize it, it extends
-   the RCODE field from 4 to 12 bits.
-
-3.2 RR CLASS IANA Considerations
-
-   DNS CLASSes have been little used but constitute another dimension of
-   the DNS distributed database.  In particular, there is no necessary
-   relationship between the name space or root servers for one CLASS and
-   those for another CLASS.  The same name can have completely different
-   meanings in different CLASSes although the label types are the same
-   and the null label is usable only as root in every CLASS.  However,
-   as global networking and DNS have evolved, the IN, or Internet, CLASS
-   has dominated DNS use.
-
-   There are two subcategories of DNS CLASSes: normal data containing
-   classes and QCLASSes that are only meaningful in queries or updates.
-
-   The current CLASS assignments and considerations for future
-   assignments are as follows:
-
-     Decimal
-   Hexadecimal
-
-     0
-   0x0000 - assignment requires an IETF Standards Action.
-
-     1
-   0x0001 - Internet (IN).
-
-     2
-   0x0002 - available for assignment by IETF Consensus as a data CLASS.
-
-     3
-   0x0003 - Chaos (CH) [Moon 1981].
-
-     4
-   0x0004 - Hesiod (HS) [Dyer 1987].
-
-
-
-Eastlake, et al.         Best Current Practice                  [Page 7]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-     5 - 127
-   0x0005 - 0x007F - available for assignment by IETF Consensus as data
-          CLASSes only.
-
-     128 - 253
-   0x0080 - 0x00FD - available for assignment by IETF Consensus as
-          QCLASSes only.
-
-     254
-   0x00FE - QCLASS None [RFC 2136].
-
-     255
-   0x00FF - QCLASS Any [RFC 1035].
-
-     256 - 32767
-   0x0100 - 0x7FFF - assigned by IETF Consensus.
-
-     32768 - 65280
-   0x8000 - 0xFEFF - assigned based on Specification Required as defined
-          in [RFC 2434].
-
-     65280 - 65534
-   0xFF00 - 0xFFFE - Private Use.
-
-     65535
-   0xFFFF - can only be assigned by an IETF Standards Action.
-
-3.3 RR NAME Considerations
-
-   DNS NAMEs are sequences of labels [RFC 1035].  The last label in each
-   NAME is "ROOT" which is the zero length label.  By definition, the
-   null or ROOT label can not be used for any other NAME purpose.
-
-   At the present time, there are two categories of label types, data
-   labels and compression labels.  Compression labels are pointers to
-   data labels elsewhere within an RR or DNS message and are intended to
-   shorten the wire encoding of NAMEs.  The two existing data label
-   types are sometimes referred to as Text and Binary.  Text labels can,
-   in fact, include any octet value including zero octets but most
-   current uses involve only [US-ASCII].  For retrieval, Text labels are
-   defined to treat ASCII upper and lower case letter codes as matching.
-   Binary labels are bit sequences [RFC 2673].
-
-   IANA considerations for label types are given in [RFC 2671].
-
-
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                  [Page 8]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-   NAMEs are local to a CLASS.  The Hesiod [Dyer 1987] and Chaos [Moon
-   1981] CLASSes are essentially for local use.  The IN or Internet
-   CLASS is thus the only DNS CLASS in global use on the Internet at
-   this time.
-
-   A somewhat dated description of name allocation in the IN Class is
-   given in [RFC 1591].  Some information on reserved top level domain
-   names is in Best Current Practice 32 [RFC 2606].
-
-4. Security Considerations
-
-   This document addresses IANA considerations in the allocation of
-   general DNS parameters, not security.  See [RFC 2535] for secure DNS
-   considerations.
-
-References
-
-   [Dyer 1987] Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical
-               Plan - Name Service, April 1987,
-
-   [Moon 1981] D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
-               Institute of Technology Artificial Intelligence
-               Laboratory, June 1981.
-
-   [RFC 1034]  Mockapetris, P., "Domain Names - Concepts and
-               Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC 1035]  Mockapetris, P., "Domain Names - Implementation and
-               Specifications", STD 13, RFC 1035, November 1987.
-
-   [RFC 1591]  Postel, J., "Domain Name System Structure and
-               Delegation", RFC 1591, March 1994.
-
-   [RFC 1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
-               Changes (DNS NOTIFY)", RFC 1996, August 1996.
-
-   [RFC 2136]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
-               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
-               RFC 2136, April 1997.
-
-   [RFC 2181]  Elz, R. and R. Bush, "Clarifications to the DNS
-               Specification", RFC 2181, July 1997.
-
-   [RFC 2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
-               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
-               October 1998.
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                  [Page 9]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-   [RFC 2535]  Eastlake, D., "Domain Name System Security Extensions",
-               RFC 2535, March 1999.
-
-   [RFC 2606]  Eastlake, D. and A. Panitz, "Reserved Top Level DNS
-               Names", RFC 2606, June 1999.
-
-   [RFC 2671]  Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC
-               2671, August 1999.
-
-   [RFC 2672]  Crawford, M., "Non-Terminal DNS Name Redirection", RFC
-               2672, August 1999.
-
-   [RFC 2673]  Crawford, M., "Binary Labels in the Domain Name System",
-               RFC 2673, August 1999.
-
-   [RFC 2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B.
-               Wellington, "Secret Key Transaction Authentication for
-               DNS (TSIG)", RFC 2845, May 2000.
-
-   [RFC 2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY
-               RR)", RFC 2930, September 2000.
-
-   [US-ASCII]  ANSI, "USA Standard Code for Information Interchange",
-               X3.4, American National Standards Institute: New York,
-               1968.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                 [Page 10]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-Authors' Addresses
-
-   Donald E. Eastlake 3rd
-   Motorola
-   140 Forest Avenue
-   Hudson, MA 01749 USA
-
-   Phone: +1-978-562-2827 (h)
-          +1-508-261-5434 (w)
-   Fax:   +1-508-261-4447 (w)
-   EMail: Donald.Eastlake@motorola.com
-
-
-   Eric Brunner-Williams
-   Engage
-   100 Brickstone Square, 2nd Floor
-   Andover, MA 01810
-
-   Phone: +1-207-797-0525 (h)
-          +1-978-684-7796 (w)
-   Fax:   +1-978-684-3118
-   EMail: brunner@engage.com
-
-
-   Bill Manning
-   USC/ISI
-   4676 Admiralty Way, #1001
-   Marina del Rey, CA 90292 USA
-
-   Phone: +1-310-822-1511
-   EMail: bmanning@isi.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                 [Page 11]
-
-RFC 2929                DNS IANA Considerations           September 2000
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake, et al.         Best Current Practice                 [Page 12]
-
diff --git a/contrib/bind9/doc/rfc/rfc2930.txt b/contrib/bind9/doc/rfc/rfc2930.txt
deleted file mode 100644
index f99573d..0000000
--- a/contrib/bind9/doc/rfc/rfc2930.txt
+++ /dev/null
@@ -1,899 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                   D. Eastlake, 3rd
-Request for Comments: 2930                                      Motorola
-Category: Standards Track                                 September 2000
-
-
-               Secret Key Establishment for DNS (TKEY RR)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   [RFC 2845] provides a means of authenticating Domain Name System
-   (DNS) queries and responses using shared secret keys via the
-   Transaction Signature (TSIG) resource record (RR).  However, it
-   provides no mechanism for setting up such keys other than manual
-   exchange. This document describes a Transaction Key (TKEY) RR that
-   can be used in a number of different modes to establish shared secret
-   keys between a DNS resolver and server.
-
-Acknowledgments
-
-   The comments and ideas of the following persons (listed in alphabetic
-   order) have been incorporated herein and are gratefully acknowledged:
-
-         Olafur Gudmundsson (TIS)
-
-         Stuart Kwan (Microsoft)
-
-         Ed Lewis (TIS)
-
-         Erik Nordmark (SUN)
-
-         Brian Wellington (Nominum)
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 1]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-Table of Contents
-
-   1. Introduction...............................................  2
-   1.1 Overview of Contents......................................  3
-   2. The TKEY Resource Record...................................  4
-   2.1 The Name Field............................................  4
-   2.2 The TTL Field.............................................  5
-   2.3 The Algorithm Field.......................................  5
-   2.4 The Inception and Expiration Fields.......................  5
-   2.5 The Mode Field............................................  5
-   2.6 The Error Field...........................................  6
-   2.7 The Key Size and Data Fields..............................  6
-   2.8 The Other Size and Data Fields............................  6
-   3. General TKEY Considerations................................  7
-   4. Exchange via Resolver Query................................  8
-   4.1 Query for Diffie-Hellman Exchanged Keying.................  8
-   4.2 Query for TKEY Deletion...................................  9
-   4.3 Query for GSS-API Establishment........................... 10
-   4.4 Query for Server Assigned Keying.......................... 10
-   4.5 Query for Resolver Assigned Keying........................ 11
-   5. Spontaneous Server Inclusion............................... 12
-   5.1 Spontaneous Server Key Deletion........................... 12
-   6. Methods of Encryption...................................... 12
-   7. IANA Considerations........................................ 13
-   8. Security Considerations.................................... 13
-   References.................................................... 14
-   Author's Address.............................................. 15
-   Full Copyright Statement...................................... 16
-
-1. Introduction
-
-   The Domain Name System (DNS) is a hierarchical, distributed, highly
-   available database used for bi-directional mapping between domain
-   names and addresses, for email routing, and for other information
-   [RFC 1034, 1035].  It has been extended to provide for public key
-   security and dynamic update [RFC 2535, RFC 2136].  Familiarity with
-   these RFCs is assumed.
-
-   [RFC 2845] provides a means of efficiently authenticating DNS
-   messages using shared secret keys via the TSIG resource record (RR)
-   but provides no mechanism for setting up such keys other than manual
-   exchange. This document specifies a TKEY RR that can be used in a
-   number of different modes to establish and delete such shared secret
-   keys between a DNS resolver and server.
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 2]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-   Note that TKEY established keying material and TSIGs that use it are
-   associated with DNS servers or resolvers.  They are not associated
-   with zones.  They may be used to authenticate queries and responses
-   but they do not provide zone based DNS data origin or denial
-   authentication [RFC 2535].
-
-   Certain modes of TKEY perform encryption which may affect their
-   export or import status for some countries.  The affected modes
-   specified in this document are the server assigned mode and the
-   resolver assigned mode.
-
-   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].
-
-   In all cases herein, the term "resolver" includes that part of a
-   server which may make full and incremental [RFC 1995] zone transfer
-   queries, forwards recursive queries, etc.
-
-1.1 Overview of Contents
-
-   Section 2 below specifies the TKEY RR and provides a description of
-   and considerations for its constituent fields.
-
-   Section 3 describes general principles of operations with TKEY.
-
-   Section 4 discusses key agreement and deletion via DNS requests with
-   the Query opcode for RR type TKEY.  This method is applicable to all
-   currently defined TKEY modes, although in some cases it is not what
-   would intuitively be called a "query".
-
-   Section 5 discusses spontaneous inclusion of TKEY RRs in responses by
-   servers which is currently used only for key deletion.
-
-   Section 6 describes encryption methods for transmitting secret key
-   information. In this document these are used only for the server
-   assigned mode and the resolver assigned mode.
-
-   Section 7 covers IANA considerations in assignment of TKEY modes.
-
-   Finally, Section 8 provides the required security considerations
-   section.
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 3]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-2. The TKEY Resource Record
-
-   The TKEY resource record (RR) has the structure given below.  Its RR
-   type code is 249.
-
-      Field       Type         Comment
-      -----       ----         -------
-
-      NAME         domain      see description below
-      TTYPE        u_int16_t   TKEY = 249
-      CLASS        u_int16_t   ignored, SHOULD be 255 (ANY)
-      TTL          u_int32_t   ignored, SHOULD be zero
-      RDLEN        u_int16_t   size of RDATA
-      RDATA:
-       Algorithm:   domain
-       Inception:   u_int32_t
-       Expiration:  u_int32_t
-       Mode:        u_int16_t
-       Error:       u_int16_t
-       Key Size:    u_int16_t
-       Key Data:    octet-stream
-       Other Size:  u_int16_t
-       Other Data:  octet-stream  undefined by this specification
-
-2.1 The Name Field
-
-   The Name field relates to naming keys.  Its meaning differs somewhat
-   with mode and context as explained in subsequent sections.
-
-   At any DNS server or resolver only one octet string of keying
-   material may be in place for any particular key name.  An attempt to
-   establish another set of keying material at a server for an existing
-   name returns a BADNAME error.
-
-   For a TKEY with a non-root name appearing in a query, the TKEY RR
-   name SHOULD be a domain locally unique at the resolver, less than 128
-   octets long in wire encoding, and meaningful to the resolver to
-   assist in distinguishing keys and/or key agreement sessions.   For
-   TKEY(s) appearing in a response to a query, the TKEY RR name SHOULD
-   be a globally unique server assigned domain.
-
-   A reasonable key naming strategy is as follows:
-
-      If the key is generated as the result of a query with root as its
-      owner name, then the server SHOULD create a globally unique domain
-      name, to be the key name, by suffixing a pseudo-random [RFC 1750]
-      label with a domain name of the server.  For example
-      89n3mDgX072pp.server1.example.com.  If generation of a new
-
-
-
-Eastlake                    Standards Track                     [Page 4]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-      pseudo-random name in each case is an excessive computation load
-      or entropy drain, a serial number prefix can be added to a fixed
-      pseudo-random name generated an DNS server start time, such as
-      1001.89n3mDgX072pp.server1.example.com.
-
-      If the key is generated as the result of a query with a non-root
-      name, say 789.resolver.example.net, then use the concatenation of
-      that with a name of the server.  For example
-      789.resolver.example.net.server1.example.com.
-
-2.2 The TTL Field
-
-   The TTL field is meaningless in TKEY RRs. It SHOULD always be zero to
-   be sure that older DNS implementations do not cache TKEY RRs.
-
-2.3 The Algorithm Field
-
-   The algorithm name is in the form of a domain name with the same
-   meaning as in [RFC 2845].  The algorithm determines how the secret
-   keying material agreed to using the TKEY RR is actually used to
-   derive the algorithm specific key.
-
-2.4 The Inception and Expiration Fields
-
-   The inception time and expiration times are in number of seconds
-   since the beginning of 1 January 1970 GMT ignoring leap seconds
-   treated as modulo 2**32 using ring arithmetic [RFC 1982]. In messages
-   between a DNS resolver and a DNS server where these fields are
-   meaningful, they are either the requested validity interval for the
-   keying material asked for or specify the validity interval of keying
-   material provided.
-
-   To avoid different interpretations of the inception and expiration
-   times in TKEY RRs, resolvers and servers exchanging them must have
-   the same idea of what time it is.  One way of doing this is with the
-   NTP protocol [RFC 2030] but that or any other time synchronization
-   used for this purpose MUST be done securely.
-
-2.5 The Mode Field
-
-   The mode field specifies the general scheme for key agreement or the
-   purpose of the TKEY DNS message.  Servers and resolvers supporting
-   this specification MUST implement the Diffie-Hellman key agreement
-   mode and the key deletion mode for queries.  All other modes are
-   OPTIONAL.  A server supporting TKEY that receives a TKEY request with
-   a mode it does not support returns the BADMODE error.  The following
-   values of the Mode octet are defined, available, or reserved:
-
-
-
-
-Eastlake                    Standards Track                     [Page 5]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-         Value    Description
-         -----    -----------
-          0        - reserved, see section 7
-          1       server assignment
-          2       Diffie-Hellman exchange
-          3       GSS-API negotiation
-          4       resolver assignment
-          5       key deletion
-         6-65534   - available, see section 7
-         65535     - reserved, see section 7
-
-2.6 The Error Field
-
-   The error code field is an extended RCODE.  The following values are
-   defined:
-
-         Value   Description
-         -----   -----------
-          0       - no error
-          1-15   a non-extended RCODE
-          16     BADSIG   (TSIG)
-          17     BADKEY   (TSIG)
-          18     BADTIME  (TSIG)
-          19     BADMODE
-          20     BADNAME
-          21     BADALG
-
-   When the TKEY Error Field is non-zero in a response to a TKEY query,
-   the DNS header RCODE field indicates no error. However, it is
-   possible if a TKEY is spontaneously included in a response the TKEY
-   RR and DNS header error field could have unrelated non-zero error
-   codes.
-
-2.7 The Key Size and Data Fields
-
-   The key data size field is an unsigned 16 bit integer in network
-   order which specifies the size of the key exchange data field in
-   octets. The meaning of this data depends on the mode.
-
-2.8 The Other Size and Data Fields
-
-   The Other Size and Other Data fields are not used in this
-   specification but may be used in future extensions.  The RDLEN field
-   MUST equal the length of the RDATA section through the end of Other
-   Data or the RR is to be considered malformed and rejected.
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 6]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-3. General TKEY Considerations
-
-   TKEY is a meta-RR that is not stored or cached in the DNS and does
-   not appear in zone files.  It supports a variety of modes for the
-   establishment and deletion of shared secret keys information between
-   DNS resolvers and servers.  The establishment of such a shared key
-   requires that state be maintained at both ends and the allocation of
-   the resources to maintain such state may require mutual agreement. In
-   the absence of willingness to provide such state, servers MUST return
-   errors such as NOTIMP or REFUSED for an attempt to use TKEY and
-   resolvers are free to ignore any TKEY RRs they receive.
-
-   The shared secret keying material developed by using TKEY is a plain
-   octet sequence.  The means by which this shared secret keying
-   material, exchanged via TKEY, is actually used in any particular TSIG
-   algorithm is algorithm dependent and is defined in connection with
-   that algorithm.  For example, see [RFC 2104] for how TKEY agreed
-   shared secret keying material is used in the HMAC-MD5 algorithm or
-   other HMAC algorithms.
-
-   There MUST NOT be more than one TKEY RR in a DNS query or response.
-
-   Except for GSS-API mode, TKEY responses MUST always have DNS
-   transaction authentication to protect the integrity of any keying
-   data, error codes, etc.  This authentication MUST use a previously
-   established secret (TSIG) or public (SIG(0) [RFC 2931]) key and MUST
-   NOT use any key that the response to be verified is itself providing.
-
-   TKEY queries MUST be authenticated for all modes except GSS-API and,
-   under some circumstances, server assignment mode.  In particular, if
-   the query for a server assigned key is for a key to assert some
-   privilege, such as update authority, then the query must be
-   authenticated to avoid spoofing.  However, if the key is just to be
-   used for transaction security, then spoofing will lead at worst to
-   denial of service.  Query authentication SHOULD use an established
-   secret (TSIG) key authenticator if available.  Otherwise, it must use
-   a public (SIG(0)) key signature.  It MUST NOT use any key that the
-   query is itself providing.
-
-   In the absence of required TKEY authentication, a NOTAUTH error MUST
-   be returned.
-
-   To avoid replay attacks, it is necessary that a TKEY response or
-   query not be valid if replayed on the order of 2**32 second (about
-   136 years), or a multiple thereof, later.  To accomplish this, the
-   keying material used in any TSIG or SIG(0) RR that authenticates a
-   TKEY message MUST NOT have a lifetime of more then 2**31 - 1 seconds
-
-
-
-
-Eastlake                    Standards Track                     [Page 7]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-   (about 68 years).  Thus, on attempted replay, the authenticating TSIG
-   or SIG(0) RR will not be verifiable due to key expiration and the
-   replay will fail.
-
-4. Exchange via Resolver Query
-
-   One method for a resolver and a server to agree about shared secret
-   keying material for use in TSIG is through DNS requests from the
-   resolver which are syntactically DNS queries for type TKEY.  Such
-   queries MUST be accompanied by a TKEY RR in the additional
-   information section to indicate the mode in use and accompanied by
-   other information where required.
-
-   Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY
-   ignore the recursive header bit in TKEY queries they receive.
-
-4.1 Query for Diffie-Hellman Exchanged Keying
-
-   Diffie-Hellman (DH) key exchange is a means whereby two parties can
-   derive some shared secret information without requiring any secrecy
-   of the messages they exchange [Schneier].  Provisions have been made
-   for the storage of DH public keys in the DNS [RFC 2539].
-
-   A resolver sends a query for type TKEY accompanied by a TKEY RR in
-   the additional information section specifying the Diffie-Hellman mode
-   and accompanied by a KEY RR also in the additional information
-   section specifying a resolver Diffie-Hellman key.  The TKEY RR
-   algorithm field is set to the authentication algorithm the resolver
-   plans to use. The "key data" provided in the TKEY is used as a random
-   [RFC 1750] nonce to avoid always deriving the same keying material
-   for the same pair of DH KEYs.
-
-   The server response contains a TKEY in its answer section with the
-   Diffie-Hellman mode. The "key data" provided in this TKEY is used as
-   an additional nonce to avoid always deriving the same keying material
-   for the same pair of DH KEYs. If the TKEY error field is non-zero,
-   the query failed for the reason given. FORMERR is given if the query
-   included no DH KEY and BADKEY is given if the query included an
-   incompatible DH KEY.
-
-   If the TKEY error field is zero, the resolver supplied Diffie-Hellman
-   KEY RR SHOULD be echoed in the additional information section and a
-   server Diffie-Hellman KEY RR will also be present in the answer
-   section of the response.  Both parties can then calculate the same
-   shared secret quantity from the pair of Diffie-Hellman (DH) keys used
-   [Schneier] (provided these DH keys use the same generator and
-   modulus) and the data in the TKEY RRs.  The TKEY RR data is mixed
-   with the DH result as follows:
-
-
-
-Eastlake                    Standards Track                     [Page 8]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-      keying material =
-           XOR ( DH value, MD5 ( query data | DH value ) |
-                           MD5 ( server data | DH value ) )
-
-   Where XOR is an exclusive-OR operation and "|" is byte-stream
-   concatenation.  The shorter of the two operands to XOR is byte-wise
-   left justified and padded with zero-valued bytes to match the length
-   of the other operand.  "DH value" is the Diffie-Hellman value derived
-   from the KEY RRs. Query data and server data are the values sent in
-   the TKEY RR data fields.  These "query data" and "server data" nonces
-   are suffixed by the DH value, digested by MD5, the results
-   concatenated, and then XORed with the DH value.
-
-   The inception and expiry times in the query TKEY RR are those
-   requested for the keying material.  The inception and expiry times in
-   the response TKEY RR are the maximum period the server will consider
-   the keying material valid.  Servers may pre-expire keys so this is
-   not a guarantee.
-
-4.2 Query for TKEY Deletion
-
-   Keys established via TKEY can be treated as soft state.  Since DNS
-   transactions are originated by the resolver, the resolver can simply
-   toss keys, although it may have to go through another key exchange if
-   it later needs one.  Similarly, the server can discard keys although
-   that will result in an error on receiving a query with a TSIG using
-   the discarded key.
-
-   To avoid attempted reliance in requests on keys no longer in effect,
-   servers MUST implement key deletion whereby the server "discards" a
-   key on receipt from a resolver of an authenticated delete request for
-   a TKEY RR with the key's name.  If the server has no record of a key
-   with that name, it returns BADNAME.
-
-   Key deletion TKEY queries MUST be authenticated.  This authentication
-   MAY be a TSIG RR using the key to be deleted.
-
-   For querier assigned and Diffie-Hellman keys, the server MUST truly
-   "discard" all active state associated with the key.  For server
-   assigned keys, the server MAY simply mark the key as no longer
-   retained by the client and may re-send it in response to a future
-   query for server assigned keying material.
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 9]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-4.3 Query for GSS-API Establishment
-
-   This mode is described in a separate document under preparation which
-   should be seen for the full description.  Basically the resolver and
-   server can exchange queries and responses for type TKEY with a TKEY
-   RR specifying the GSS-API mode in the additional information section
-   and a GSS-API token in the key data portion of the TKEY RR.
-
-   Any issues of possible encryption of parts the GSS-API token data
-   being transmitted are handled by the GSS-API level.  In addition, the
-   GSS-API level provides its own authentication so that this mode of
-   TKEY query and response MAY be, but do not need to be, authenticated
-   with TSIG RR or SIG(0) RR [RFC 2931].
-
-   The inception and expiry times in a GSS-API mode TKEY RR are ignored.
-
-4.4 Query for Server Assigned Keying
-
-   Optionally, the server can assign keying for the resolver.  It is
-   sent to the resolver encrypted under a resolver public key.  See
-   section 6 for description of encryption methods.
-
-   A resolver sends a query for type TKEY accompanied by a TKEY RR
-   specifying the "server assignment" mode and a resolver KEY RR to be
-   used in encrypting the response, both in the additional information
-   section. The TKEY algorithm field is set to the authentication
-   algorithm the resolver plans to use.  It is RECOMMENDED that any "key
-   data" provided in the query TKEY RR by the resolver be strongly mixed
-   by the server with server generated randomness [RFC 1750] to derive
-   the keying material to be used.  The KEY RR that appears in the query
-   need not be accompanied by a SIG(KEY) RR.  If the query is
-   authenticated by the resolver with a TSIG RR [RFC 2845] or SIG(0) RR
-   and that authentication is verified, then any SIG(KEY) provided in
-   the query SHOULD be ignored.  The KEY RR in such a query SHOULD have
-   a name that corresponds to the resolver but it is only essential that
-   it be a public key for which the resolver has the corresponding
-   private key so it can decrypt the response data.
-
-   The server response contains a TKEY RR in its answer section with the
-   server assigned mode and echoes the KEY RR provided in the query in
-   its additional information section.
-
-   If the response TKEY error field is zero, the key data portion of the
-   response TKEY RR will be the server assigned keying data encrypted
-   under the public key in the resolver provided KEY RR.  In this case,
-   the owner name of the answer TKEY RR will be the server assigned name
-   of the key.
-
-
-
-
-Eastlake                    Standards Track                    [Page 10]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-   If the error field of the response TKEY is non-zero, the query failed
-   for the reason given.  FORMERR is given if the query specified no
-   encryption key.
-
-   The inception and expiry times in the query TKEY RR are those
-   requested for the keying material.  The inception and expiry times in
-   the response TKEY are the maximum period the server will consider the
-   keying material valid.  Servers may pre-expire keys so this is not a
-   guarantee.
-
-   The resolver KEY RR MUST be authenticated, through the authentication
-   of this query with a TSIG or SIG(0) or the signing of the resolver
-   KEY with a SIG(KEY).  Otherwise, an attacker can forge a resolver KEY
-   for which they know the private key, and thereby the attacker could
-   obtain a valid shared secret key from the server.
-
-4.5 Query for Resolver Assigned Keying
-
-   Optionally, a server can accept resolver assigned keys.  The keying
-   material MUST be encrypted under a server key for protection in
-   transmission as described in Section 6.
-
-   The resolver sends a TKEY query with a TKEY RR that specifies the
-   encrypted keying material and a KEY RR specifying the server public
-   key used to encrypt the data, both in the additional information
-   section.  The name of the key and the keying data are completely
-   controlled by the sending resolver so a globally unique key name
-   SHOULD be used.  The KEY RR used MUST be one for which the server has
-   the corresponding private key, or it will not be able to decrypt the
-   keying material and will return a FORMERR. It is also important that
-   no untrusted party (preferably no other party than the server) has
-   the private key corresponding to the KEY RR because, if they do, they
-   can capture the messages to the server, learn the shared secret, and
-   spoof valid TSIGs.
-
-   The query TKEY RR inception and expiry give the time period the
-   querier intends to consider the keying material valid.  The server
-   can return a lesser time interval to advise that it will not maintain
-   state for that long and can pre-expire keys in any case.
-
-   This mode of query MUST be authenticated with a TSIG or SIG(0).
-   Otherwise, an attacker can forge a resolver assigned TKEY query, and
-   thereby the attacker could specify a shared secret key that would be
-   accepted, used, and honored by the server.
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 11]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-5. Spontaneous Server Inclusion
-
-   A DNS server may include a TKEY RR spontaneously as additional
-   information in responses.  This SHOULD only be done if the server
-   knows the querier understands TKEY and has this option implemented.
-   This technique can be used to delete a key and may be specified for
-   modes defined in the future.  A disadvantage of this technique is
-   that there is no way for the server to get any error or success
-   indication back and, in the case of UDP, no way to even know if the
-   DNS response reached the resolver.
-
-5.1 Spontaneous Server Key Deletion
-
-   A server can optionally tell a client that it has deleted a secret
-   key by spontaneously including a TKEY RR in the additional
-   information section of a response with the key's name and specifying
-   the key deletion mode.  Such a response SHOULD be authenticated.  If
-   authenticated, it "deletes" the key with the given name.  The
-   inception and expiry times of the delete TKEY RR are ignored. Failure
-   by a client to receive or properly process such additional
-   information in a response would mean that the client might use a key
-   that the server had discarded and would then get an error indication.
-
-   For server assigned and Diffie-Hellman keys, the client MUST
-   "discard" active state associated with the key.  For querier assigned
-   keys, the querier MAY simply mark the key as no longer retained by
-   the server and may re-send it in a future query specifying querier
-   assigned keying material.
-
-6. Methods of Encryption
-
-   For the server assigned and resolver assigned key agreement modes,
-   the keying material is sent within the key data field of a TKEY RR
-   encrypted under the public key in an accompanying KEY RR [RFC 2535].
-   This KEY RR MUST be for a public key algorithm where the public and
-   private keys can be used for encryption and the corresponding
-   decryption which recovers the originally encrypted data.  The KEY RR
-   SHOULD correspond to a name for the decrypting resolver/server such
-   that the decrypting process has access to the corresponding private
-   key to decrypt the data.  The secret keying material being sent will
-   generally be fairly short, usually less than 256 bits, because that
-   is adequate for very strong protection with modern keyed hash or
-   symmetric algorithms.
-
-   If the KEY RR specifies the RSA algorithm, then the keying material
-   is encrypted as per the description of RSAES-PKCS1-v1_5 encryption in
-   PKCS#1 [RFC 2437].  (Note, the secret keying material being sent is
-   directly RSA encrypted in PKCS#1 format. It is not "enveloped" under
-
-
-
-Eastlake                    Standards Track                    [Page 12]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-   some other symmetric algorithm.)  In the unlikely event that the
-   keying material will not fit within one RSA modulus of the chosen
-   public key, additional RSA encryption blocks are included.  The
-   length of each block is clear from the public RSA key specified and
-   the RSAES-PKCS1-v1_5 padding makes it clear what part of the
-   encrypted data is actually keying material and what part is
-   formatting or the required at least eight bytes of random [RFC 1750]
-   padding.
-
-7. IANA Considerations
-
-   This section is to be interpreted as provided in [RFC 2434].
-
-   Mode field values 0x0000 and 0xFFFF are reserved.
-
-   Mode field values 0x0001 through 0x00FF, and 0XFF00 through 0XFFFE
-   can only be assigned by an IETF Standards Action.
-
-   Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF
-   are allocated by IESG approval or IETF consensus.
-
-   Mode field values 0x1000 through 0xEFFF are allocated based on
-   Specification Required as defined in [RFC 2434].
-
-   Mode values should not be changed when the status of their use
-   changes.  For example, a mode value assigned based just on providing
-   a specification should not be changed later just because that use's
-   status is changed to standards track.
-
-   The following assignments are documented herein:
-
-      RR Type 249 for TKEY.
-
-      TKEY Modes 1 through 5 as listed in section 2.5.
-
-      Extended RCODE Error values of 19, 20, and 21 as listed in section
-      2.6.
-
-8. Security Considerations
-
-   The entirety of this specification is concerned with the secure
-   establishment of a shared secret between DNS clients and servers in
-   support of TSIG [RFC 2845].
-
-   Protection against denial of service via the use of TKEY is not
-   provided.
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 13]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-References
-
-   [Schneier] Bruce Schneier, "Applied Cryptography: Protocols,
-              Algorithms, and Source Code in C", 1996, John Wiley and
-              Sons
-
-   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
-              Specifications", STD 13, RFC 1035, November 1987.
-
-   [RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
-              Recommendations for Security", RFC 1750, December 1994.
-
-   [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
-              September 1996.
-
-   [RFC 1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
-              August 1996.
-
-   [RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
-              for IPv4, IPv6 and OSI", RFC 2030, October 1996.
-
-   [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:  Keyed-
-              Hashing for Message Authentication", RFC 2104, February
-              1997.
-
-   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
-              Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
-              April 1997.
-
-   [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
-              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
-              October 1998.
-
-   [RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
-              Specifications Version 2.0", RFC 2437, October 1998.
-
-   [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC 2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
-              Domain Name System (DNS)", RFC 2539, March 1999.
-
-
-
-
-Eastlake                    Standards Track                    [Page 14]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-   [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
-              Wellington, "Secret Key Transaction Authentication for DNS
-              (TSIG)", RFC 2845, May 2000.
-
-   [RFC 2931] Eastlake, D., "DNS Request and Transaction Signatures
-              (SIG(0)s )", RFC 2931, September 2000.
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   Motorola
-   140 Forest Avenue
-   Hudson, MA 01749 USA
-
-   Phone: +1 978-562-2827 (h)
-          +1 508-261-5434 (w)
-   Fax:   +1 508-261-4447 (w)
-   EMail: Donald.Eastlake@motorola.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 15]
-
-RFC 2930                    The DNS TKEY RR               September 2000
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 16]
-
diff --git a/contrib/bind9/doc/rfc/rfc2931.txt b/contrib/bind9/doc/rfc/rfc2931.txt
deleted file mode 100644
index 84cc97e..0000000
--- a/contrib/bind9/doc/rfc/rfc2931.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                    D. Eastlake 3rd
-Request for Comments: 2931                                      Motorola
-Updates: 2535                                             September 2000
-Category: Standards Track
-
-
-           DNS Request and Transaction Signatures ( SIG(0)s )
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   Extensions to the Domain Name System (DNS) are described in [RFC
-   2535] that can provide data origin and transaction integrity and
-   authentication to security aware resolvers and applications through
-   the use of cryptographic digital signatures.
-
-   Implementation experience has indicated the need for minor but non-
-   interoperable changes in Request and Transaction signature resource
-   records ( SIG(0)s ).  These changes are documented herein.
-
-Acknowledgments
-
-   The contributions and suggestions of the following persons (in
-   alphabetic order) to this memo are gratefully acknowledged:
-
-         Olafur Gudmundsson
-
-         Ed Lewis
-
-         Erik Nordmark
-
-         Brian Wellington
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 1]
-
-RFC 2931                       DNS SIG(0)                 September 2000
-
-
-Table of Contents
-
-   1. Introduction.................................................  2
-   2. SIG(0) Design Rationale......................................  3
-   2.1 Transaction Authentication..................................  3
-   2.2 Request Authentication......................................  3
-   2.3 Keying......................................................  3
-   2.4 Differences Between TSIG and SIG(0).........................  4
-   3. The SIG(0) Resource Record...................................  4
-   3.1 Calculating Request and Transaction SIGs....................  5
-   3.2 Processing Responses and SIG(0) RRs.........................  6
-   3.3 SIG(0) Lifetime and Expiration..............................  7
-   4. Security Considerations......................................  7
-   5. IANA Considerations..........................................  7
-   References......................................................  7
-   Author's Address................................................  8
-   Appendix: SIG(0) Changes from RFC 2535..........................  9
-   Full Copyright Statement........................................ 10
-
-1. Introduction
-
-   This document makes minor but non-interoperable changes to part of
-   [RFC 2535], familiarity with which is assumed, and includes
-   additional explanatory text.  These changes concern SIG Resource
-   Records (RRs) that are used to digitally sign DNS requests and
-   transactions / responses.  Such a resource record, because it has a
-   type covered field of zero, is frequently called a SIG(0). The
-   changes are based on implementation and attempted implementation
-   experience with TSIG [RFC 2845] and the [RFC 2535] specification for
-   SIG(0).
-
-   Sections of [RFC 2535] updated are all of 4.1.8.1 and parts of 4.2
-   and 4.3.  No changes are made herein related to the KEY or NXT RRs or
-   to the processing involved with data origin and denial authentication
-   for DNS data.
-
-   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].
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 2]
-
-RFC 2931                       DNS SIG(0)                 September 2000
-
-
-2. SIG(0) Design Rationale
-
-   SIG(0) provides protection for DNS transactions and requests that is
-   not provided by the regular SIG, KEY, and NXT RRs specified in [RFC
-   2535].  The authenticated data origin services of secure DNS either
-   provide protected data resource records (RRs) or authenticatably deny
-   their nonexistence.  These services provide no protection for glue
-   records, DNS requests, no protection for message headers on requests
-   or responses, and no protection of the overall integrity of a
-   response.
-
-2.1 Transaction Authentication
-
-   Transaction authentication means that a requester can be sure it is
-   at least getting the messages from the server it queried and that the
-   received messages are in response to the query it sent.  This is
-   accomplished by optionally adding either a TSIG RR [RFC 2845] or, as
-   described herein, a SIG(0) resource record at the end of the response
-   which digitally signs the concatenation of the server's response and
-   the corresponding resolver query.
-
-2.2 Request Authentication
-
-   Requests can also be authenticated by including a TSIG or, as
-   described herein, a special SIG(0) RR at the end of the request.
-   Authenticating requests serves no function in DNS servers that
-   predate the specification of dynamic update.  Requests with a non-
-   empty additional information section produce error returns or may
-   even be ignored by a few such older DNS servers. However, this syntax
-   for signing requests is defined for authenticating dynamic update
-   requests [RFC 2136], TKEY requests [RFC 2930], or future requests
-   requiring authentication.
-
-2.3 Keying
-
-   The private keys used in transaction security belong to the host
-   composing the DNS response message, not to the zone involved.
-   Request authentication may also involve the private key of the host
-   or other entity composing the request or of a zone to be affected by
-   the request or other private keys depending on the request authority
-   it is sought to establish. The corresponding public key(s) are
-   normally stored in and retrieved from the DNS for verification as KEY
-   RRs with a protocol byte of 3 (DNSSEC) or 255 (ANY).
-
-   Because requests and replies are highly variable, message
-   authentication SIGs can not be pre-calculated.  Thus it will be
-   necessary to keep the private key on-line, for example in software or
-   in a directly connected piece of hardware.
-
-
-
-Eastlake                    Standards Track                     [Page 3]
-
-RFC 2931                       DNS SIG(0)                 September 2000
-
-
-2.4 Differences Between TSIG and SIG(0)
-
-   There are significant differences between TSIG and SIG(0).
-
-   Because TSIG involves secret keys installed at both the requester and
-   server the presence of such a key implies that the other party
-   understands TSIG and very likely has the same key installed.
-   Furthermore, TSIG uses keyed hash authentication codes which are
-   relatively inexpensive to compute.  Thus it is common to authenticate
-   requests with TSIG and responses are authenticated with TSIG if the
-   corresponding request is authenticated.
-
-   SIG(0) on the other hand, uses public key authentication, where the
-   public keys are stored in DNS as KEY RRs and a private key is stored
-   at the signer.  Existence of such a KEY RR does not necessarily imply
-   implementation of SIG(0).  In addition, SIG(0) involves relatively
-   expensive public key cryptographic operations that should be
-   minimized and the verification of a SIG(0) involves obtaining and
-   verifying the corresponding KEY which can be an expensive and lengthy
-   operation.  Indeed, a policy of using SIG(0) on all requests and
-   verifying it before responding would, for some configurations, lead
-   to a deadly embrace with the attempt to obtain and verify the KEY
-   needed to authenticate the request SIG(0) resulting in additional
-   requests accompanied by a SIG(0) leading to further requests
-   accompanied by a SIG(0), etc.  Furthermore, omitting SIG(0)s when not
-   required on requests halves the number of public key operations
-   required by the transaction.
-
-   For these reasons, SIG(0)s SHOULD only be used on requests when
-   necessary to authenticate that the requester has some required
-   privilege or identity.  SIG(0)s on replies are defined in such a way
-   as to not require a SIG(0) on the corresponding request and still
-   provide transaction protection.  For other replies, whether they are
-   authenticated by the server or required to be authenticated by the
-   requester SHOULD be a local configuration option.
-
-3. The SIG(0) Resource Record
-
-   The structure of and type number of SIG resource records (RRs) is
-   given in [RFC 2535] Section 4.1.  However all of Section 4.1.8.1 and
-   the parts of Sections 4.2 and 4.3 related to SIG(0) should be
-   considered replaced by the material below.  Any conflict between [RFC
-   2535] and this document concerning SIG(0) RRs should be resolved in
-   favor of this document.
-
-   For all transaction SIG(0)s, the signer field MUST be a name of the
-   originating host and there MUST be a KEY RR at that name with the
-   public key corresponding to the private key used to calculate the
-
-
-
-Eastlake                    Standards Track                     [Page 4]
-
-RFC 2931                       DNS SIG(0)                 September 2000
-
-
-   signature.  (The host domain name used may be the inverse IP address
-   mapping name for an IP address of the host if the relevant KEY is
-   stored there.)
-
-   For all SIG(0) RRs, the owner name, class, TTL, and original TTL, are
-   meaningless.  The TTL fields SHOULD be zero and the CLASS field
-   SHOULD be ANY.  To conserve space, the owner name SHOULD be root (a
-   single zero octet).  When SIG(0) authentication on a response is
-   desired, that SIG RR MUST be considered the highest priority of any
-   additional information for inclusion in the response. If the SIG(0)
-   RR cannot be added without causing the message to be truncated, the
-   server MUST alter the response so that a SIG(0) can be included.
-   This response consists of only the question and a SIG(0) record, and
-   has the TC bit set and RCODE 0 (NOERROR).  The client should at this
-   point retry the request using TCP.
-
-3.1 Calculating Request and Transaction SIGs
-
-   A DNS request may be optionally signed by including one SIG(0)s at
-   the end of the query additional information section.  Such a SIG is
-   identified by having a "type covered" field of zero. It signs the
-   preceding DNS request message including DNS header but not including
-   the UDP/IP header and before the request RR counts have been adjusted
-   for the inclusions of the request SIG(0).
-
-   It is calculated by using a "data" (see [RFC 2535], Section 4.1.8) of
-   (1) the SIG's RDATA section entirely omitting (not just zeroing) the
-   signature subfield itself, (2) the DNS query messages, including DNS
-   header, but not the UDP/IP header and before the reply RR counts have
-   been adjusted for the inclusion of the SIG(0).  That is
-
-      data = RDATA | request - SIG(0)
-
-   where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
-   calculated less the signature itself.
-
-   Similarly, a SIG(0) can be used to secure a response and the request
-   that produced it.  Such transaction signatures are calculated by
-   using a "data" of (1) the SIG's RDATA section omitting the signature
-   itself, (2) the entire DNS query message that produced this response,
-   including the query's DNS header but not its UDP/IP header, and (3)
-   the entire DNS response message, including DNS header but not the
-   UDP/IP header and before the response RR counts have been adjusted
-   for the inclusion of the SIG(0).
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 5]
-
-RFC 2931                       DNS SIG(0)                 September 2000
-
-
-   That is
-
-      data = RDATA | full query | response - SIG(0)
-
-   where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
-   calculated less the signature itself.
-
-   Verification of a response SIG(0) (which is signed by the server host
-   key, not the zone key) by the requesting resolver shows that the
-   query and response were not tampered with in transit, that the
-   response corresponds to the intended query, and that the response
-   comes from the queried server.
-
-   In the case of a DNS message via TCP, a SIG(0) on the first data
-   packet is calculated with "data" as above and for each subsequent
-   packet, it is calculated as follows:
-
-      data = RDATA | DNS payload - SIG(0) | previous packet
-
-   where "|" is concatenations, RDATA is as above, and previous packet
-   is the previous DNS payload including DNS header and the SIG(0) but
-   not the TCP/IP header.  Support of SIG(0) for TCP is OPTIONAL.  As an
-   alternative, TSIG may be used after, if necessary, setting up a key
-   with TKEY [RFC 2930].
-
-   Except where needed to authenticate an update, TKEY, or similar
-   privileged request, servers are not required to check a request
-   SIG(0).
-
-   Note: requests and responses can either have a single TSIG or one
-   SIG(0) but not both a TSIG and a SIG(0).
-
-3.2 Processing Responses and SIG(0) RRs
-
-   If a SIG RR is at the end of the additional information section of a
-   response and has a type covered of zero, it is a transaction
-   signature covering the response and the query that produced the
-   response.  For TKEY responses, it MUST be checked and the message
-   rejected if the checks fail unless otherwise specified for the TKEY
-   mode in use.  For all other responses, it MAY be checked and the
-   message rejected if the checks fail.
-
-   If a response's SIG(0) check succeed, such a transaction
-   authentication SIG does NOT directly authenticate the validity any
-   data-RRs in the message.  However, it authenticates that they were
-   sent by the queried server and have not been diddled.  (Only a proper
-   SIG(0) RR signed by the zone or a key tracing its authority to the
-   zone or to static resolver configuration can directly authenticate
-
-
-
-Eastlake                    Standards Track                     [Page 6]
-
-RFC 2931                       DNS SIG(0)                 September 2000
-
-
-   data-RRs, depending on resolver policy.) If a resolver or server does
-   not implement transaction and/or request SIGs, it MUST ignore them
-   without error where they are optional and treat them as failing where
-   they are required.
-
-3.3 SIG(0) Lifetime and Expiration
-
-   The inception and expiration times in SIG(0)s are for the purpose of
-   resisting replay attacks.  They should be set to form a time bracket
-   such that messages outside that bracket can be ignored.  In IP
-   networks, this time bracket should not normally extend further than 5
-   minutes into the past and 5 minutes into the future.
-
-4. Security Considerations
-
-   No additional considerations beyond those in [RFC 2535].
-
-   The inclusion of the SIG(0) inception and expiration time under the
-   signature improves resistance to replay attacks.
-
-5. IANA Considerations
-
-   No new parameters are created or parameter values assigned by this
-   document.
-
-References
-
-   [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
-              September 1996.
-
-   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
-              Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
-              April 1997.
-
-   [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
-              Wellington, "Secret Key Transaction Signatures for DNS
-              (TSIG)", RFC 2845, May 2000.
-
-   [RFC 2930] Eastlake, D., "Secret Key Establishment for DNS (RR)", RFC
-              2930, September 2000.
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 7]
-
-RFC 2931                       DNS SIG(0)                 September 2000
-
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   Motorola
-   140 Forest Avenue
-   Hudson, MA 01749 USA
-
-   Phone: +1-978-562-2827(h)
-          +1-508-261-5434(w)
-   Fax:   +1 978-567-7941(h)
-          +1-508-261-4447(w)
-   EMail: Donald.Eastlake@motorola.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 8]
-
-RFC 2931                       DNS SIG(0)                 September 2000
-
-
-Appendix: SIG(0) Changes from RFC 2535
-
-   Add explanatory text concerning the differences between TSIG and
-   SIG(0).
-
-   Change the data over which SIG(0) is calculated to include the SIG(0)
-   RDATA other than the signature itself so as to secure the signature
-   inception and expiration times and resist replay attacks.  Specify
-   SIG(0) for TCP.
-
-   Add discussion of appropriate inception and expiration times for
-   SIG(0).
-
-   Add wording to indicate that either a TSIG or one or more SIG(0)s may
-   be present but not both.
-
-   Reword some areas for clarity.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                     [Page 9]
-
-RFC 2931                       DNS SIG(0)                 September 2000
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake                    Standards Track                    [Page 10]
-
diff --git a/contrib/bind9/doc/rfc/rfc3007.txt b/contrib/bind9/doc/rfc/rfc3007.txt
deleted file mode 100644
index 1697475..0000000
--- a/contrib/bind9/doc/rfc/rfc3007.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                      B. Wellington
-Request for Comments: 3007                                       Nominum
-Updates: 2535, 2136                                        November 2000
-Obsoletes: 2137
-Category: Standards Track
-
-
-             Secure Domain Name System (DNS) Dynamic Update
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   This document proposes a method for performing secure Domain Name
-   System (DNS) dynamic updates.  The method described here is intended
-   to be flexible and useful while requiring as few changes to the
-   protocol as possible.  The authentication of the dynamic update
-   message is separate from later DNSSEC validation of the data.  Secure
-   communication based on authenticated requests and transactions is
-   used to provide authorization.
-
-   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].
-
-1 - Introduction
-
-   This document defines a means to secure dynamic updates of the Domain
-   Name System (DNS), allowing only authorized sources to make changes
-   to a zone's contents.  The existing unsecured dynamic update
-   operations form the basis for this work.
-
-   Familiarity with the DNS system [RFC1034, RFC1035] and dynamic update
-   [RFC2136] is helpful and is assumed by this document.  In addition,
-   knowledge of DNS security extensions [RFC2535], SIG(0) transaction
-   security [RFC2535, RFC2931], and TSIG transaction security [RFC2845]
-   is recommended.
-
-
-
-
-Wellington                  Standards Track                     [Page 1]
-
-RFC 3007                 Secure Dynamic Update             November 2000
-
-
-   This document updates portions of RFC 2535, in particular section
-   3.1.2, and RFC 2136.  This document obsoletes RFC 2137, an alternate
-   proposal for secure dynamic update, due to implementation experience.
-
-1.1 - Overview of DNS Dynamic Update
-
-   DNS dynamic update defines a new DNS opcode and a new interpretation
-   of the DNS message if that opcode is used.  An update can specify
-   insertions or deletions of data, along with prerequisites necessary
-   for the updates to occur.  All tests and changes for a DNS update
-   request are restricted to a single zone, and are performed at the
-   primary server for the zone.  The primary server for a dynamic zone
-   must increment the zone SOA serial number when an update occurs or
-   before the next retrieval of the SOA.
-
-1.2 - Overview of DNS Transaction Security
-
-   Exchanges of DNS messages which include TSIG [RFC2845] or SIG(0)
-   [RFC2535, RFC2931] records allow two DNS entities to authenticate DNS
-   requests and responses sent between them.  A TSIG MAC (message
-   authentication code) is derived from a shared secret, and a SIG(0) is
-   generated from a private key whose public counterpart is stored in
-   DNS.  In both cases, a record containing the message signature/MAC is
-   included as the final resource record in a DNS message.  Keyed
-   hashes, used in TSIG, are inexpensive to calculate and verify.
-   Public key encryption, as used in SIG(0), is more scalable as the
-   public keys are stored in DNS.
-
-1.3 - Comparison of data authentication and message authentication
-
-   Message based authentication, using TSIG or SIG(0), provides
-   protection for the entire message with a single signing and single
-   verification which, in the case of TSIG, is a relatively inexpensive
-   MAC creation and check.  For update requests, this signature can
-   establish, based on policy or key negotiation, the authority to make
-   the request.
-
-   DNSSEC SIG records can be used to protect the integrity of individual
-   RRs or RRsets in a DNS message with the authority of the zone owner.
-   However, this cannot sufficiently protect the dynamic update request.
-
-   Using SIG records to secure RRsets in an update request is
-   incompatible with the design of update, as described below, and would
-   in any case require multiple expensive public key signatures and
-   verifications.
-
-
-
-
-
-
-Wellington                  Standards Track                     [Page 2]
-
-RFC 3007                 Secure Dynamic Update             November 2000
-
-
-   SIG records do not cover the message header, which includes record
-   counts.  Therefore, it is possible to maliciously insert or remove
-   RRsets in an update request without causing a verification failure.
-
-   If SIG records were used to protect the prerequisite section, it
-   would be impossible to determine whether the SIGs themselves were a
-   prerequisite or simply used for validation.
-
-   In the update section of an update request, signing requests to add
-   an RRset is straightforward, and this signature could be permanently
-   used to protect the data, as specified in [RFC2535].  However, if an
-   RRset is deleted, there is no data for a SIG to cover.
-
-1.4 - Data and message signatures
-
-   As specified in [RFC3008], the DNSSEC validation process performed by
-   a resolver MUST NOT process any non-zone keys unless local policy
-   dictates otherwise.  When performing secure dynamic update, all zone
-   data modified in a signed zone MUST be signed by a relevant zone key.
-   This completely disassociates authentication of an update request
-   from authentication of the data itself.
-
-   The primary usefulness of host and user keys, with respect to DNSSEC,
-   is to authenticate messages, including dynamic updates.  Thus, host
-   and user keys MAY be used to generate SIG(0) records to authenticate
-   updates and MAY be used in the TKEY [RFC2930] process to generate
-   TSIG shared secrets.  In both cases, no SIG records generated by
-   non-zone keys will be used in a DNSSEC validation process unless
-   local policy dictates.
-
-   Authentication of data, once it is present in DNS, only involves
-   DNSSEC zone keys and signatures generated by them.
-
-1.5 - Signatory strength
-
-   [RFC2535, section 3.1.2] defines the signatory field of a key as the
-   final 4 bits of the flags field, but does not define its value.  This
-   proposal leaves this field undefined.  Updating [RFC2535], this field
-   SHOULD be set to 0 in KEY records, and MUST be ignored.
-
-2 - Authentication
-
-   TSIG or SIG(0) records MUST be included in all secure dynamic update
-   messages.  This allows the server to verifiably determine the
-   originator of a message.  If the message contains authentication in
-   the form of a SIG(0), the identity of the sender (that is, the
-   principal) is the owner of the KEY RR that generated the SIG(0).  If
-   the message contains a TSIG generated by a statically configured
-
-
-
-Wellington                  Standards Track                     [Page 3]
-
-RFC 3007                 Secure Dynamic Update             November 2000
-
-
-   shared secret, the principal is the same as or derived from the
-   shared secret name.  If the message contains a TSIG generated by a
-   dynamically configured shared secret, the principal is the same as
-   the one that authenticated the TKEY process; if the TKEY process was
-   unauthenticated, no information is known about the principal, and the
-   associated TSIG shared secret MUST NOT be used for secure dynamic
-   update.
-
-   SIG(0) signatures SHOULD NOT be generated by zone keys, since
-   transactions are initiated by a host or user, not a zone.
-
-   DNSSEC SIG records (other than SIG(0)) MAY be included in an update
-   message, but MUST NOT be used to authenticate the update request.
-
-   If an update fails because it is signed with an unauthorized key, the
-   server MUST indicate failure by returning a message with RCODE
-   REFUSED.  Other TSIG, SIG(0), or dynamic update errors are returned
-   as specified in the appropriate protocol description.
-
-3 - Policy
-
-   All policy is configured by the zone administrator and enforced by
-   the zone's primary name server.  Policy dictates the authorized
-   actions that an authenticated principal can take.  Policy checks are
-   based on the principal and the desired action, where the principal is
-   derived from the message signing key and applied to dynamic update
-   messages signed with that key.
-
-   The server's policy defines criteria which determine if the key used
-   to sign the update is permitted to perform the requested updates.  By
-   default, a principal MUST NOT be permitted to make any changes to
-   zone data; any permissions MUST be enabled though configuration.
-
-   The policy is fully implemented in the primary zone server's
-   configuration for several reasons.  This removes limitations imposed
-   by encoding policy into a fixed number of bits (such as the KEY RR's
-   signatory field).  Policy is only relevant in the server applying it,
-   so there is no reason to expose it.  Finally, a change in policy or a
-   new type of policy should not affect the DNS protocol or data format,
-   and should not cause interoperability failures.
-
-3.1 - Standard policies
-
-   Implementations SHOULD allow access control policies to use the
-   principal as an authorization token, and MAY also allow policies to
-   grant permission to a signed message regardless of principal.
-
-
-
-
-
-Wellington                  Standards Track                     [Page 4]
-
-RFC 3007                 Secure Dynamic Update             November 2000
-
-
-   A common practice would be to restrict the permissions of a principal
-   by domain name.  That is, a principal could be permitted to add,
-   delete, or modify entries corresponding to one or more domain names.
-   Implementations SHOULD allow per-name access control, and SHOULD
-   provide a concise representation of the principal's own name, its
-   subdomains, and all names in the zone.
-
-   Additionally, a server SHOULD allow restricting updates by RR type,
-   so that a principal could add, delete, or modify specific record
-   types at certain names.  Implementations SHOULD allow per-type access
-   control, and SHOULD provide concise representations of all types and
-   all "user" types, where a user type is defined as one that does not
-   affect the operation of DNS itself.
-
-3.1.1 - User types
-
-   User types include all data types except SOA, NS, SIG, and NXT.  SOA
-   and NS records SHOULD NOT be modified by normal users, since these
-   types create or modify delegation points.  The addition of SIG
-   records can lead to attacks resulting in additional workload for
-   resolvers, and the deletion of SIG records could lead to extra work
-   for the server if the zone SIG was deleted.  Note that these records
-   are not forbidden, but not recommended for normal users.
-
-   NXT records MUST NOT be created, modified, or deleted by dynamic
-   update, as their update may cause instability in the protocol.  This
-   is an update to RFC 2136.
-
-   Issues concerning updates of KEY records are discussed in the
-   Security Considerations section.
-
-3.2 - Additional policies
-
-   Users are free to implement any policies.  Policies may be as
-   specific or general as desired, and as complex as desired.  They may
-   depend on the principal or any other characteristics of the signed
-   message.
-
-4 - Interaction with DNSSEC
-
-   Although this protocol does not change the way updates to secure
-   zones are processed, there are a number of issues that should be
-   clarified.
-
-
-
-
-
-
-
-
-Wellington                  Standards Track                     [Page 5]
-
-RFC 3007                 Secure Dynamic Update             November 2000
-
-
-4.1 - Adding SIGs
-
-   An authorized update request MAY include SIG records with each RRset.
-   Since SIG records (except SIG(0) records) MUST NOT be used for
-   authentication of the update message, they are not required.
-
-   If a principal is authorized to update SIG records and there are SIG
-   records in the update, the SIG records are added without
-   verification.  The server MAY examine SIG records and drop SIGs with
-   a temporal validity period in the past.
-
-4.2 - Deleting SIGs
-
-   If a principal is authorized to update SIG records and the update
-   specifies the deletion of SIG records, the server MAY choose to
-   override the authority and refuse the update.  For example, the
-   server may allow all SIG records not generated by a zone key to be
-   deleted.
-
-4.3 - Non-explicit updates to SIGs
-
-   If the updated zone is secured, the RRset affected by an update
-   operation MUST, at the completion of the update, be signed in
-   accordance with the zone's signing policy.  This will usually require
-   one or more SIG records to be generated by one or more zone keys
-   whose private components MUST be online [RFC3008].
-
-   When the contents of an RRset are updated, the server MAY delete all
-   associated SIG records, since they will no longer be valid.
-
-4.4 - Effects on the zone
-
-   If any changes are made, the server MUST, if necessary, generate a
-   new SOA record and new NXT records, and sign these with the
-   appropriate zone keys.  Changes to NXT records by secure dynamic
-   update are explicitly forbidden.  SOA updates are allowed, since the
-   maintenance of SOA parameters is outside of the scope of the DNS
-   protocol.
-
-5 - Security Considerations
-
-   This document requires that a zone key and possibly other
-   cryptographic secret material be held in an on-line, network-
-   connected host, most likely a name server.  This material is at the
-   mercy of host security to remain a secret.  Exposing this secret puts
-   DNS data at risk of masquerade attacks.  The data at risk is that in
-   both zones served by the machine and delegated from this machine.
-
-
-
-
-Wellington                  Standards Track                     [Page 6]
-
-RFC 3007                 Secure Dynamic Update             November 2000
-
-
-   Allowing updates of KEY records may lead to undesirable results,
-   since a principal may be allowed to insert a public key without
-   holding the private key, and possibly masquerade as the key owner.
-
-6 - Acknowledgements
-
-   The author would like to thank the following people for review and
-   informative comments (in alphabetical order):
-
-   Harald Alvestrand
-   Donald Eastlake
-   Olafur Gudmundsson
-   Andreas Gustafsson
-   Bob Halley
-   Stuart Kwan
-   Ed Lewis
-
-7 - References
-
-   [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.
-
-   [RFC2136]  Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound,
-              "Dynamic Updates in the Domain Name System", RFC 2136,
-              April 1997.
-
-   [RFC2137]  Eastlake, D., "Secure Domain Name System Dynamic Update",
-              RFC 2137, April 1997.
-
-   [RFC2535]  Eastlake, G., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B.
-              Wellington, "Secret Key Transaction Signatures for DNS
-              (TSIG)", RFC 2845, May 2000.
-
-   [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.
-
-   [RFC3008]  Wellington, B., "Domain Name System Security (DNSSEC)
-              Signing Authority", RFC 3008, November 2000.
-
-
-
-
-Wellington                  Standards Track                     [Page 7]
-
-RFC 3007                 Secure Dynamic Update             November 2000
-
-
-8 - Author's Address
-
-   Brian Wellington
-   Nominum, Inc.
-   950 Charter Street
-   Redwood City, CA 94063
-
-   Phone: +1 650 381 6022
-   EMail: Brian.Wellington@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wellington                  Standards Track                     [Page 8]
-
-RFC 3007                 Secure Dynamic Update             November 2000
-
-
-9.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wellington                  Standards Track                     [Page 9]
-
diff --git a/contrib/bind9/doc/rfc/rfc3008.txt b/contrib/bind9/doc/rfc/rfc3008.txt
deleted file mode 100644
index 08a4a8f..0000000
--- a/contrib/bind9/doc/rfc/rfc3008.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                      B. Wellington
-Request for Comments: 3008                                       Nominum
-Updates: 2535                                              November 2000
-Category: Standards Track
-
-
-         Domain Name System Security (DNSSEC) Signing Authority
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-Abstract
-
-   This document proposes a revised model of Domain Name System Security
-   (DNSSEC) Signing Authority.  The revised model is designed to clarify
-   earlier documents and add additional restrictions to simplify the
-   secure resolution process.  Specifically, this affects the
-   authorization of keys to sign sets of records.
-
-   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].
-
-1 - Introduction
-
-   This document defines additional restrictions on DNSSEC signatures
-   (SIG) records relating to their authority to sign associated data.
-   The intent is to establish a standard policy followed by a secure
-   resolver; this policy can be augmented by local rules.  This builds
-   upon [RFC2535], updating section 2.3.6 of that document.
-
-   The most significant change is that in a secure zone, zone data is
-   required to be signed by the zone key.
-
-   Familiarity with the DNS system [RFC1034, RFC1035] and the DNS
-   security extensions [RFC2535] is assumed.
-
-
-
-
-
-
-Wellington                  Standards Track                     [Page 1]
-
-RFC 3008                DNSSEC Signing Authority           November 2000
-
-
-2 - The SIG Record
-
-   A SIG record is normally associated with an RRset, and "covers" (that
-   is, demonstrates the authenticity and integrity of) the RRset.  This
-   is referred to as a "data SIG".  Note that there can be multiple SIG
-   records covering an RRset, and the same validation process should be
-   repeated for each of them.  Some data SIGs are considered "material",
-   that is, relevant to a DNSSEC capable resolver, and some are
-   "immaterial" or "extra-DNSSEC", as they are not relevant to DNSSEC
-   validation.  Immaterial SIGs may have application defined roles.  SIG
-   records may exist which are not bound to any RRset; these are also
-   considered immaterial.  The validation process determines which SIGs
-   are material; once a SIG is shown to be immaterial, no other
-   validation is necessary.
-
-   SIGs may also be used for transaction security.  In this case, a SIG
-   record with a type covered field of 0 is attached to a message, and
-   is used to protect message integrity.  This is referred to as a
-   SIG(0) [RFC2535, RFC2931].
-
-   The following sections define requirements for all of the fields of a
-   SIG record.  These requirements MUST be met in order for a DNSSEC
-   capable resolver to process this signature.  If any of these
-   requirements are not met, the SIG cannot be further processed.
-   Additionally, once a KEY has been identified as having generated this
-   SIG, there are requirements that it MUST meet.
-
-2.1 - Type Covered
-
-   For a data SIG, the type covered MUST be the same as the type of data
-   in the associated RRset.  For a SIG(0), the type covered MUST be 0.
-
-2.2 - Algorithm Number
-
-   The algorithm specified in a SIG MUST be recognized by the client,
-   and it MUST be an algorithm that has a defined SIG rdata format.
-
-2.3 - Labels
-
-   The labels count MUST be less than or equal to the number of labels
-   in the SIG owner name, as specified in [RFC2535, section 4.1.3].
-
-2.4 - Original TTL
-
-   The original TTL MUST be greater than or equal to the TTL of the SIG
-   record itself, since the TTL cannot be increased by intermediate
-   servers.  This field can be ignored for SIG(0) records.
-
-
-
-
-Wellington                  Standards Track                     [Page 2]
-
-RFC 3008                DNSSEC Signing Authority           November 2000
-
-
-2.5 - Signature Expiration and Inception
-
-   The current time at the time of validation MUST lie within the
-   validity period bounded by the inception and expiration times.
-
-2.6 - Key Tag
-
-   There are no restrictions on the Key Tag field, although it is
-   possible that future algorithms will impose constraints.
-
-2.7 - Signer's Name
-
-   The signer's name field of a data SIG MUST contain the name of the
-   zone to which the data and signature belong.  The combination of
-   signer's name, key tag, and algorithm MUST identify a zone key if the
-   SIG is to be considered material.  The only exception that the
-   signer's name field in a SIG KEY at a zone apex SHOULD contain the
-   parent zone's name, unless the KEY set is self-signed.  This document
-   defines a standard policy for DNSSEC validation; local policy may
-   override the standard policy.
-
-   There are no restrictions on the signer field of a SIG(0) record.
-   The combination of signer's name, key tag, and algorithm MUST
-   identify a key if this SIG(0) is to be processed.
-
-2.8 - Signature
-
-   There are no restrictions on the signature field.  The signature will
-   be verified at some point, but does not need to be examined prior to
-   verification unless a future algorithm imposes constraints.
-
-3 - The Signing KEY Record
-
-   Once a signature has been examined and its fields validated (but
-   before the signature has been verified), the resolver attempts to
-   locate a KEY that matches the signer name, key tag, and algorithm
-   fields in the SIG.  If one is not found, the SIG cannot be verified
-   and is considered immaterial.  If KEYs are found, several fields of
-   the KEY record MUST have specific values if the SIG is to be
-   considered material and authorized.  If there are multiple KEYs, the
-   following checks are performed on all of them, as there is no way to
-   determine which one generated the signature until the verification is
-   performed.
-
-
-
-
-
-
-
-
-Wellington                  Standards Track                     [Page 3]
-
-RFC 3008                DNSSEC Signing Authority           November 2000
-
-
-3.1 - Type Flags
-
-   The signing KEY record MUST have a flags value of 00 or 01
-   (authentication allowed, confidentiality optional) [RFC2535, 3.1.2].
-   A DNSSEC resolver MUST only trust signatures generated by keys that
-   are permitted to authenticate data.
-
-3.2 - Name Flags
-
-   The interpretation of this field is considerably different for data
-   SIGs and SIG(0) records.
-
-3.2.1 - Data SIG
-
-   If the SIG record covers an RRset, the name type of the associated
-   KEY MUST be 01 (zone) [RFC2535, 3.1.2].  This updates RFC 2535,
-   section 2.3.6.  The DNSSEC validation process performed by a resolver
-   MUST ignore all keys that are not zone keys unless local policy
-   dictates otherwise.
-
-   The primary reason that RFC 2535 allows host and user keys to
-   generate material DNSSEC signatures is to allow dynamic update
-   without online zone keys; that is, avoid storing private keys in an
-   online server.  The desire to avoid online signing keys cannot be
-   achieved, though, because they are necessary to sign NXT and SOA sets
-   [RFC3007].  These online zone keys can sign any incoming data.
-   Removing the goal of having no online keys removes the reason to
-   allow host and user keys to generate material signatures.
-
-   Limiting material signatures to zone keys simplifies the validation
-   process.  The length of the verification chain is bounded by the
-   name's label depth.  The authority of a key is clearly defined; a
-   resolver does not need to make a potentially complicated decision to
-   determine whether a key has the proper authority to sign data.
-
-   Finally, there is no additional flexibility granted by allowing
-   host/user key generated material signatures.  As long as users and
-   hosts have the ability to authenticate update requests to the primary
-   zone server, signatures by zone keys are sufficient to protect the
-   integrity of the data to the world at large.
-
-3.2.2 - SIG(0)
-
-   If the SIG record is a SIG(0) protecting a message, the name type of
-   the associated KEY SHOULD be 00 (user) or 10 (host/entity).
-   Transactions are initiated by a host or user, not a zone, so zone
-   keys SHOULD not generate SIG(0) records.
-
-
-
-
-Wellington                  Standards Track                     [Page 4]
-
-RFC 3008                DNSSEC Signing Authority           November 2000
-
-
-   A client is either explicitly executed by a user or on behalf of a
-   host, therefore the name type of a SIG(0) generated by a client
-   SHOULD be either user or host.  A nameserver is associated with a
-   host, and its use of SIG(0) is not associated with a particular zone,
-   so the name type of a SIG(0) generated by a nameserver SHOULD be
-   host.
-
-3.3 - Signatory Flags
-
-   This document does not assign any values to the signatory field, nor
-   require any values to be present.
-
-3.4 - Protocol
-
-   The signing KEY record MUST have a protocol value of 3 (DNSSEC) or
-   255 (ALL).  If a key is not specified for use with DNSSEC, a DNSSEC
-   resolver MUST NOT trust any signature that it generates.
-
-3.5 - Algorithm Number
-
-   The algorithm field MUST be identical to that of the generated SIG
-   record, and MUST meet all requirements for an algorithm value in a
-   SIG record.
-
-4 - Security Considerations
-
-   This document defines a standard baseline for a DNSSEC capable
-   resolver.  This is necessary for a thorough security analysis of
-   DNSSEC, if one is to be done.
-
-   Specifically, this document places additional restrictions on SIG
-   records that a resolver must validate before the signature can be
-   considered worthy of DNSSEC trust.  This simplifies the protocol,
-   making it more robust and able to withstand scrutiny by the security
-   community.
-
-5 - Acknowledgements
-
-   The author would like to thank the following people for review and
-   informative comments (in alphabetical order):
-
-   Olafur Gudmundsson
-   Ed Lewis
-
-
-
-
-
-
-
-
-Wellington                  Standards Track                     [Page 5]
-
-RFC 3008                DNSSEC Signing Authority           November 2000
-
-
-6 - References
-
-   [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.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2136]  Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound,
-              "Dynamic Updates in the Domain Name System", RFC 2136,
-              April 1997.
-
-   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures
-              (SIG(0)s )", RFC 2931, September 2000.
-
-   [RFC3007]      Wellington, B., "Simple Secure Domain Name System
-              (DNS) Dynamic Update", RFC 3007, November 2000.
-
-7 - Author's Address
-
-   Brian Wellington
-   Nominum, Inc.
-   950 Charter Street
-   Redwood City, CA 94063
-
-   Phone: +1 650 381 6022
-   EMail: Brian.Wellington@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wellington                  Standards Track                     [Page 6]
-
-RFC 3008                DNSSEC Signing Authority           November 2000
-
-
-8  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wellington                  Standards Track                     [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc3071.txt b/contrib/bind9/doc/rfc/rfc3071.txt
deleted file mode 100644
index 2c4d52f..0000000
--- a/contrib/bind9/doc/rfc/rfc3071.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         J. Klensin
-Request for Comments: 3071                                 February 2001
-Category: Informational
-
-
-      Reflections on the DNS, RFC 1591, and Categories of Domains
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-Abstract
-
-   RFC 1591, "Domain Name System Structure and Delegation", laid out the
-   basic administrative design and principles for the allocation and
-   administration of domains, from the top level down.  It was written
-   before the introduction of the world wide web (WWW) and rapid growth
-   of the Internet put significant market, social, and political
-   pressure on domain name allocations.  In recent years, 1591 has been
-   cited by all sides in various debates, and attempts have been made by
-   various bodies to update it or adjust its provisions, sometimes under
-   pressures that have arguably produced policies that are less well
-   thought out than the original.  Some of those efforts have begun from
-   misconceptions about the provisions of 1591 or the motivation for
-   those provisions.  The current directions of the Internet Corporation
-   for Assigned Names and Numbers (ICANN) and other groups who now
-   determine the Domain Name System (DNS) policy directions appear to be
-   drifting away from the policies and philosophy of 1591.  This
-   document is being published primarily for historical context and
-   comparative purposes, essentially to document some thoughts about how
-   1591 might have been interpreted and adjusted by the Internet
-   Assigned Numbers Authority (IANA) and ICANN to better reflect today's
-   world while retaining characteristics and policies that have proven
-   to be effective in supporting Internet growth and stability.  An
-   earlier variation of this memo was submitted to ICANN as a comment on
-   its evolving Top-level Domain (TLD) policies.
-
-
-
-
-
-
-
-
-
-Klensin                      Informational                      [Page 1]
-
-RFC 3071          Reflections on the DNS and RFC 1591      February 2001
-
-
-1.  Introduction
-
-   RFC 1591 [1] has been heavily discussed and referenced in the last
-   year or two, especially in discussions within ICANN and its
-   predecessors about the creation, delegation, and management of top-
-   level domains.  In particular, the ICANN Domain Name Supporting
-   Organization (DNSO), and especially its ccTLD constituency, have been
-   the home of many discussions in which 1591 and interpretations of it
-   have been cited in support of a variety of sometimes-contradictory
-   positions.  During that period, other discussions have gone on to try
-   to reconstruct the thinking that went into RFC 1591.  Those in turn
-   have led me and others to muse on how that original thinking might
-   relate to some of the issues being raised.  1591 is, I believe, one
-   of Jon Postel's masterpieces, drawing together very different
-   philosophies (e.g., his traditional view that people are basically
-   reasonable and will do the right thing if told what it is with some
-   stronger mechanisms when that model is not successful) into a single
-   whole.
-
-   RFC 1591 was written in the context of the assumption that what it
-   described as generic TLDs would be bound to policies and categories
-   of registration (see the "This domain is intended..."  text in
-   section 2) while ccTLDs were expected to be used primarily to support
-   users and uses within and for a country and its residents.  The
-   notion that different domains would be run in different ways --albeit
-   within the broad contexts of "public service on behalf of the
-   Internet community" and "trustee... for the global Internet
-   community"-- was considered a design feature and a safeguard against
-   a variety of potential abuses.  Obviously the world has changed in
-   many ways in the seven or eight years since 1591 was written.  In
-   particular, the Internet has become more heavily used and, because
-   the design of the world wide web has put domain names in front of
-   users, top-level domain names and registrations in them have been
-   heavily in demand: not only has the number of hosts increased
-   dramatically during that time, but the ratio between registered
-   domain names and physical hosts has increased very significantly.
-
-   The issues 1591 attempted to address when it was written and those we
-   face today have not changed significantly in principle.  But one
-   alternative to present trends would be to take a step back to refine
-   it into a model that can function effectively today.  Therefore, it
-   may be useful to try to reconstruct 1591's principles and think about
-   their applicability today as a model that could continue to be
-   applied: not because it is historically significant, but because many
-   of its elements have proven to work reasonably well, even in
-   difficult situations.  In particular, for many domains (some in
-   1591's "generic" list and others in its "country code" category) the
-   notion of "public service" --expected then to imply being carried out
-
-
-
-Klensin                      Informational                      [Page 2]
-
-RFC 3071          Reflections on the DNS and RFC 1591      February 2001
-
-
-   at no or minimal cost to the users, not merely on a non-profit
-   basis-- has yielded to profitability calculations.  And, in most of
-   the rest, considerations of at least calculating and recovering costs
-   have crept in.  While many of us feel some nostalgia for the old
-   system, it is clear that its days are waning if not gone: perhaps the
-   public service notions as understood when 1591 was written just don't
-   scale to rapid internet growth and very large numbers of
-   yregistrations.
-
-   In particular, some ccTLDs have advertised for registrations outside
-   the designated countries (or other entities), while others have made
-   clear decisions to allow registrations by non-nationals.  These
-   decisions and others have produced protests from many sides,
-   suggesting, in turn, that a recategorization is in order.  For
-   example, we have heard concerns by governments and managers of
-   traditional, "public service", in-country, ccTLDs about excessive
-   ICANN interference and fears of being forced to conform to
-   internationally-set policies for dispute resolution when their
-   domestic ones are considered more appropriate.  We have also heard
-   concerns from registrars and operators of externally-marketed ccTLDs
-   about unreasonable government interference and from gTLD registrars
-   and registries about unreasonable competition from aggressively
-   marketed ccTLDs.  The appropriate distinction is no longer between
-   what RFC 1591 described as "generic" TLDs (but which were really
-   intended to be "purpose-specific", a term I will use again below) and
-   ccTLDs but among:
-
-      (i) true "generic" TLDs, in which any registration is acceptable
-      and, ordinarily, registrations from all sources are actively
-      promoted.  This list currently includes (the formerly purpose-
-      specific) COM, NET, and ORG, and some ccTLDs.  There have been
-      proposals from time to time for additional TLDs of this variety in
-      which, as with COM (and, more recently, NET and ORG) anyone
-      (generally subject only to name conflicts and national law) could
-      register who could pay the fees.
-
-      (ii) purpose-specific TLDs, in which registration is accepted only
-      from organizations or individuals meeting particular
-      qualifications, but where those qualifications are not tied to
-      national boundaries.  This list currently includes INT, EDU, the
-      infrastructure domain ARPA, and, arguably, the specialized US
-      Government TLDs MIL and GOV.  There have been proposals from time
-      to time for other international TLDs of this variety, e.g., for
-      medical entities such as physicians and hospitals and for museums.
-      ICANN has recently approved several TLDs of this type and
-      describes them as "sponsored" TLDs.
-
-
-
-
-
-Klensin                      Informational                      [Page 3]
-
-RFC 3071          Reflections on the DNS and RFC 1591      February 2001
-
-
-      (iii) Country domains, operated according to the original
-      underlying assumptions of 1591, i.e., registrants are largely
-      expected to be people or other entities within the country.  While
-      external registrations might be accepted by some of these, the
-      country does not aggressively advertise for such registrations,
-      nor does anyone expect to derive significant fee revenue from
-      them.  All current domains in this category are ccTLDs, but not
-      all ccTLDs are in this category.
-
-   These categories are clearly orthogonal to the association between
-   the use of the IS 3166-1 registered code list [2] and two-letter
-   "country" domain names.  If that relationship is to be maintained
-   (and I believe it is desirable), the only inherent requirement is
-   that no two-letter TLDs be created except from that list (in order to
-   avoid future conflicts).  ICANN should control the allocation and
-   delegation of TLDs using these, and other, criteria, but only
-   registered 3166-1 two letter codes should be used as two-letter TLDs.
-
-2. Implications of the Categories
-
-   If we had adopted this type of three-way categorization and could
-   make it work, I believe it would have presented several opportunities
-   for ICANN and the community more generally to reduce controversies
-   and move forward.  Of course, there will be cases where the
-   categorization of a particular domain and its operating style will
-   not be completely clear-cut (see section 3, below).  But having ICANN
-   work out procedures for dealing with those (probably few) situations
-   appears preferable to strategies that would tend to propel ICANN into
-   areas that are beyond its competence or that might require
-   significant expansion of its mandate.
-
-   First, the internally-operated ccTLDs (category iii above) should not
-   be required to have much interaction with ICANN or vice versa.  Once
-   a domain of this sort is established and delegated, and assuming that
-   the "admin contact in the country" rule is strictly observed, the
-   domain should be able to function effectively without ICANN
-   intervention or oversight.  In particular, while a country might
-   choose to adopt the general ICANN policies about dispute resolution
-   or name management, issues that arise in these areas might equally
-   well be dealt with exclusively under applicable national laws.  If a
-   domain chooses to use ICANN services that cost resources to provide,
-   it should contribute to ICANN's support, but, if it does not, ICANN
-   should not presume to charge it for other than a reasonable fraction
-   of the costs to ICANN of operating the root, root servers, and any
-   directory systems that are generally agreed upon to be necessary and
-   in which the domain participates.
-
-
-
-
-
-Klensin                      Informational                      [Page 4]
-
-RFC 3071          Reflections on the DNS and RFC 1591      February 2001
-
-
-   By contrast, ccTLDs operated as generic domains ought to be treated
-   as generic domains.  ICANN dispute resolution and name management
-   policies and any special rules developed to protect the Internet
-   public in multiple registrar or registry situations should reasonably
-   apply.
-
-3.  Telling TLD types apart
-
-   If appropriate policies are adopted, ccTLDs operated as generic
-   domains (category (i) above) and those operated as country domains
-   (category (iii) above) ought to be able to be self-identified.  There
-   are several criteria that could be applied to make this
-   determination.  For example, either a domain is aggressively seeking
-   outside registrations or it is not and either the vast majority of
-   registrants in a domain are in-country or they are not.  One could
-   also think of this as the issue of having some tangible level of
-   presence in the jurisdiction - e.g., is the administrative contact
-   subject, in practical terms, to the in-country laws, or are the
-   registration rules such that it is reasonably likely that a court in
-   the jurisdiction of the country associated with the domain can
-   exercise jurisdiction and enforce a judgment against the registrant.
-
-   One (fairly non-intrusive) rule ICANN might well impose on all top-
-   level domains is that they identify and publish the policies they
-   intend to use.  E.g., registrants in a domain that will use the laws
-   of one particular country to resolve disputes should have a
-   reasonable opportunity to understand those policies prior to
-   registration and to make other arrangements (e.g., to register
-   elsewhere) if that mechanism for dispute resolution is not
-   acceptable.  Giving IANA (as the root registrar) incorrect
-   information about the purpose and use of a domain should be subject
-   to challenge, and should be grounds for reviewing the appropriateness
-   of the domain delegation, just as not acting consistently and
-   equitably provides such grounds under the original provisions of RFC
-   1591.
-
-   In order to ensure the availability of accurate and up-to-date
-   registration information the criteria must be consistent, and
-   consistent with more traditional gTLDs, for all nominally country
-   code domains operating as generic TLDs.
-
-4. The role of ICANN in country domains
-
-   ICANN (and IANA) should, as described above, have as little
-   involvement as possible in the direction of true country [code]
-   domains (i.e., category (iii)).  There is no particular reason why
-
-
-
-
-
-Klensin                      Informational                      [Page 5]
-
-RFC 3071          Reflections on the DNS and RFC 1591      February 2001
-
-
-   these domains should be subject to ICANN regulation beyond the basic
-   principles of 1591 and associated arrangements needed to ensure
-   Internet interoperability and stability.
-
-   ICANN's avoiding such involvement strengthens it: the desirability of
-   avoiding collisions with national sovereignty, determinations about
-   government legitimacy, and the authority of someone purportedly
-   writing on behalf of a government, is as important today as it was
-   when 1591 was written.  The alternatives take us quickly from
-   "administration" into "internet governance" or, in the case of
-   determining which claimant is the legitimate government of a country,
-   "international relations", and the reasons for not moving in that
-   particular direction are legion.
-
-5. The role of governments
-
-   The history of IANA strategy in handling ccTLDs included three major
-   "things to avoid" considerations:
-
-      * Never get involved in determining which entities were countries
-        and which ones were not.
-
-      * Never get involved in determining who was, or was not, the
-        legitimate government of a country.  And, more generally, avoid
-        deciding what entity --government, religion, commercial,
-        academic, etc.-- has what legitimacy or rights.
-
-      * If possible, never become involved in in-country disputes.
-        Instead, very strongly encourage internal parties to work
-        problems out among themselves.  At most, adopt a role as
-        mediator and educator, rather than judge, unless abuses are very
-        clear and clearly will not be settled by any internal mechanism.
-
-   All three considerations were obviously intended to avoid IANA's
-   being dragged into a political morass in which it had (and, I
-   suggest, has) no competence to resolve the issues and could only get
-   bogged down.  The first consideration was the most visible (and the
-   easiest) and was implemented by strict and careful adherence (see
-   below) to the ISO 3166 registered Country Code list.  If an entity
-   had a code, it was eligible to be registered with a TLD (although
-   IANA was free to apply additional criteria-most of them stated in
-   1591).  If it did not, there were no exceptions: the applicant's only
-   recourse was a discussion with the 3166 Registration Authority (now
-   Maintenance Agency, often known just as "3166/MA") or the UN
-   Statistical Office (now Statistics Bureau), not with IANA.
-
-
-
-
-
-
-Klensin                      Informational                      [Page 6]
-
-RFC 3071          Reflections on the DNS and RFC 1591      February 2001
-
-
-   There are actually five ccTLD exceptions to the strict rules.  One,
-   "UK", is historical: it predates the adoption of ISO 3166 for this
-   purpose.  The others --Ascension Island, Guernsey, Isle of Man, and
-   Jersey --are arguably, at least in retrospect, just mistakes.
-   Regardless of the historical reasons (about which there has been much
-   speculation), it is almost certainly the case that the right way to
-   handle mistakes of this sort is to acknowledge them and move on,
-   rather than trying to use them as precedents to justify more
-   mistakes.
-
-   This, obviously, is also the argument against use of the "reserved"
-   list (technically internal to the 3166 maintenance activity, and not
-   part of the Standard): since IANA (or ICANN) can ask that a name be
-   placed on that list, there is no rule of an absolute determination by
-   an external organization.  Purported countries can come to ICANN,
-   insist on having delegations made and persuade ICANN to ask that the
-   names be reserved.  Then, since the reserved name would exist, they
-   could insist that the domain be delegated.  Worse, someone could use
-   another organization to request reservation of the name by 3166/MA;
-   once it was reserved, ICANN might be hard-pressed not to do the
-   delegation.  Of course, ICANN could (and probably would be forced to)
-   adopt additional criteria other than appearance on the "reserved
-   list" in order to delegate such domains.  But those criteria would
-   almost certainly be nearly equivalent to determining which applicants
-   were legitimate and stable enough to be considered a country, the
-   exact decision process that 1591 strove to avoid.
-
-   The other two considerations were more subtle and not always
-   successful: from time to time, both before and after the formal
-   policy shifted toward "governments could have their way", IANA
-   received letters from people purporting to be competent government
-   authorities asking for changes.  Some of them turned out later to not
-   have that authority or appropriate qualifications.  The assumption of
-   1591 itself was that, if the "administrative contact in country" rule
-   was strictly observed, as was the rule that delegation changes
-   requested by the administrative contact would be honored, then, if a
-   government _really_ wanted to assert itself, it could pressure the
-   administrative contact into requesting the changes it wanted, using
-   whatever would pass for due process in that country.  And the ability
-   to apply that process and pressure would effectively determine who
-   was the government and who wasn't, and would do so far more
-   effectively than any IANA evaluation of, e.g., whether the letterhead
-   on a request looked authentic (and far more safely for ICANN than
-   asking the opinion of any particular other government or selection of
-   governments).
-
-
-
-
-
-
-Klensin                      Informational                      [Page 7]
-
-RFC 3071          Reflections on the DNS and RFC 1591      February 2001
-
-
-   Specific language in 1591 permitted IANA to adopt a "work it out
-   yourselves; if we have to decide, we will strive for a solution that
-   is not satisfactory to any party" stance.  That approach was used
-   successfully, along with large doses of education, on many occasions
-   over the years, to avoid IANA's having to assume the role of judge
-   between conflicting parties.
-
-   Similar principles could be applied to the boundary between country-
-   code-based generic TLDs and country domains.  Different countries,
-   under different circumstances, might prefer to operate the ccTLD
-   either as a national service or as a profit center where the
-   "customers" were largely external.  Whatever decisions were made
-   historically, general Internet stability argues that changes should
-   not be made lightly.  At the same time, if a government wishes to
-   make a change, the best mechanism for doing so is not to involve
-   ICANN in a potential determination of legitimacy (or even to have
-   ICANN's Government Advisory Committee (GAC) try to formally make that
-   decision for individual countries) but for the relevant government to
-   use its own procedures to persuade the administrative contact to
-   request the change and for IANA to promptly and efficiently carry out
-   requests made by administrative contacts.
-
-6. Implications for the current ICANN DNSO structure.
-
-   The arguments by some of the ccTLD administrators that they are
-   different from the rest of the ICANN and DNSO structures are (in this
-   model) correct: they are different.  The ccTLDs that are operating as
-   generic TLDs should be separated from the ccTLD constituency and
-   joined to the gTLD constituency.  The country ccTLDs should be
-   separated from ICANN's immediate Supporting Organization structure,
-   and operate in a parallel and advisory capacity to ICANN, similar to
-   the arrangements used with the GAC.  The DNSO and country TLDs should
-   not be required to interact with each other except on a mutually
-   voluntary basis and, if ICANN needs interaction or advice from some
-   of all of those TLDs, it would be more appropriate to get it in the
-   form of an advisory body like the GAC rather than as DNSO
-   constituency.
-
-7. References
-
-   [1] Postel, J., "Domain Name System Structure and Delegation", RFC
-       1591, March 1994.
-
-   [2] ISO 3166. ISO 3166-1. Codes for the representation of names of
-       countries and their subdivisions - Part 1: Country codes (1997).
-
-
-
-
-
-
-Klensin                      Informational                      [Page 8]
-
-RFC 3071          Reflections on the DNS and RFC 1591      February 2001
-
-
-8. Acknowledgements and disclaimer
-
-   These reflections have been prepared in my individual capacity and do
-   not necessarily reflect the views of my past or present employers.
-   Several people, including Randy Bush, Theresa Swinehart, Zita Wenzel,
-   Geoff Huston, Havard Eidnes, and several anonymous reviewers, made
-   suggestions or offered editorial comments about earlier versions of
-   this document.  Cord Wischhoefer, of the ISO 3166/MA, was also kind
-   enough to look at the draft and supplied some useful details.  Those
-   comments contributed significantly to whatever clarity the document
-   has, but the author bears responsibility for the selection of
-   comments which were ultimately incorporated and the way in which the
-   conclusions were presented.
-
-9.  Security Considerations
-
-   This memo addresses the context for a set of administrative decisions
-   and procedures, and does not raise or address security issues.
-
-10. Author's Address
-
-   John C. Klensin
-   1770 Massachusetts Ave, Suite 322
-   Cambridge, MA 02140, USA
-
-   EMail: klensin@jck.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Klensin                      Informational                      [Page 9]
-
-RFC 3071          Reflections on the DNS and RFC 1591      February 2001
-
-
-11. Full Copyright Statement
-
-   Copyright (C) The Internet Society 2001. All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others provided that the above copyright notice and this paragraph
-   are included on all such copies.  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 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Klensin                      Informational                     [Page 10]
-
diff --git a/contrib/bind9/doc/rfc/rfc3090.txt b/contrib/bind9/doc/rfc/rfc3090.txt
deleted file mode 100644
index 08008f7..0000000
--- a/contrib/bind9/doc/rfc/rfc3090.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           E. Lewis
-Request for Comments: 3090                                      NAI Labs
-Category: Standards Track                                     March 2001
-
-
-          DNS Security Extension Clarification on Zone Status
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-Abstract
-
-   The definition of a secured zone is presented, clarifying and
-   updating sections of RFC 2535.  RFC 2535 defines a zone to be secured
-   based on a per algorithm basis, e.g., a zone can be secured with RSA
-   keys, and not secured with DSA keys.  This document changes this to
-   define a zone to be secured or not secured regardless of the key
-   algorithm used (or not used).  To further simplify the determination
-   of a zone's status, "experimentally secure" status is deprecated.
-
-1 Introduction
-
-   Whether a DNS zone is "secured" or not is a question asked in at
-   least four contexts.  A zone administrator asks the question when
-   configuring a zone to use DNSSEC.  A dynamic update server asks the
-   question when an update request arrives, which may require DNSSEC
-   processing.  A delegating zone asks the question of a child zone when
-   the parent enters data indicating the status the child.  A resolver
-   asks the question upon receipt of data belonging to the zone.
-
-1.1 When a Zone's Status is Important
-
-   A zone administrator needs to be able to determine what steps are
-   needed to make the zone as secure as it can be.  Realizing that due
-   to the distributed nature of DNS and its administration, any single
-   zone is at the mercy of other zones when it comes to the appearance
-   of security.  This document will define what makes a zone qualify as
-   secure.
-
-
-
-
-Lewis                       Standards Track                     [Page 1]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-   A name server performing dynamic updates needs to know whether a zone
-   being updated is to have signatures added to the updated data, NXT
-   records applied, and other required processing.  In this case, it is
-   conceivable that the name server is configured with the knowledge,
-   but being able to determine the status of a zone by examining the
-   data is a desirable alternative to configuration parameters.
-
-   A delegating zone is required to indicate whether a child zone is
-   secured.  The reason for this requirement lies in the way in which a
-   resolver makes its own determination about a zone (next paragraph).
-   To shorten a long story, a parent needs to know whether a child
-   should be considered secured.  This is a two part question.  Under
-   what circumstances does a parent consider a child zone to be secure,
-   and how does a parent know if the child conforms?
-
-   A resolver needs to know if a zone is secured when the resolver is
-   processing data from the zone.  Ultimately, a resolver needs to know
-   whether or not to expect a usable signature covering the data.  How
-   this determination is done is out of the scope of this document,
-   except that, in some cases, the resolver will need to contact the
-   parent of the zone to see if the parent states that the child is
-   secured.
-
-1.2 Islands of Security
-
-   The goal of DNSSEC is to have each zone secured, from the root zone
-   and the top-level domains down the hierarchy to the leaf zones.
-   Transitioning from an unsecured DNS, as we have now, to a fully
-   secured - or "as much as will be secured" - tree will take some time.
-   During this time, DNSSEC will be applied in various locations in the
-   tree, not necessarily "top down."
-
-   For example, at a particular instant, the root zone and the "test."
-   TLD might be secured, but region1.test. might not be.  (For
-   reference, let's assume that region2.test. is secured.)  However,
-   subarea1.region1.test. may have gone through the process of becoming
-   secured, along with its delegations.  The dilemma here is that
-   subarea1 cannot get its zone keys properly signed as its parent zone,
-   region1, is not secured.
-
-   The colloquial phrase describing the collection of contiguous secured
-   zones at or below subarea1.region1.test. is an "island of security."
-   The only way in which a DNSSEC resolver will come to trust any data
-   from this island is if the resolver is pre-configured with the zone
-   key(s) for subarea1.region1.test., i.e., the root of the island of
-   security.  Other resolvers (not so configured) will recognize this
-   island as unsecured.
-
-
-
-
-Lewis                       Standards Track                     [Page 2]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-   An island of security begins with one zone whose public key is pre-
-   configured in resolvers.  Within this island are subzones which are
-   also secured.  The "bottom" of the island is defined by delegations
-   to unsecured zones.  One island may also be on top of another -
-   meaning that there is at least one unsecured zone between the bottom
-   of the upper island and the root of the lower secured island.
-
-   Although both subarea1.region1.test. and region2.test. have both been
-   properly brought to a secured state by the administering staff, only
-   the latter of the two is actually "globally" secured - in the sense
-   that all DNSSEC resolvers can and will verify its data.  The former,
-   subarea1, will be seen as secured by a subset of those resolvers,
-   just those appropriately configured.  This document refers to such
-   zones as being "locally" secured.
-
-   In RFC 2535, there is a provision for "certification authorities,"
-   entities that will sign public keys for zones such as subarea1.
-   There is another document, [RFC3008], that restricts this activity.
-   Regardless of the other document, resolvers would still need proper
-   configuration to be able to use the certification authority to verify
-   the data for the subarea1 island.
-
-1.2.1 Determining the closest security root
-
-   Given a domain, in order to determine whether it is secure or not,
-   the first step is to determine the closest security root.  The
-   closest security root is the top of an island of security whose name
-   has the most matching (in order from the root) right-most labels to
-   the given domain.
-
-   For example, given a name "sub.domain.testing.signed.exp.test.", and
-   given the secure roots "exp.test.", "testing.signed.exp.test." and
-   "not-the-same.xy.", the middle one is the closest.  The first secure
-   root shares 2 labels, the middle 4, and the last 0.
-
-   The reason why the closest is desired is to eliminate false senses of
-   insecurity because of a NULL key.  Continuing with the example, the
-   reason both "testing..." and "exp.test." are listed as secure root is
-   presumably because "signed.exp.test." is unsecured (has a NULL key).
-   If we started to descend from "exp.test." to our given domain
-   (sub...), we would encounter a NULL key and conclude that sub... was
-   unsigned.  However, if we descend from "testing..." and find keys
-   "domain...." then we can conclude that "sub..." is secured.
-
-   Note that this example assumes one-label deep zones, and assumes that
-   we do not configure overlapping islands of security.  To be clear,
-   the definition given should exclude "short.xy.test." from being a
-   closest security root for "short.xy." even though 2 labels match.
-
-
-
-Lewis                       Standards Track                     [Page 3]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-   Overlapping islands of security introduce no conceptually interesting
-   ideas and do not impact the protocol in anyway.  However, protocol
-   implementers are advised to make sure their code is not thrown for a
-   loop by overlaps.  Overlaps are sure to be configuration problems as
-   islands of security grow to encompass larger regions of the name
-   space.
-
-1.3 Parent Statement of Child Security
-
-   In 1.1 of this document, there is the comment "the parent states that
-   the child is secured."  This has caused quite a bit of confusion.
-
-   The need to have the parent "state" the status of a child is derived
-   from the following observation.  If you are looking to see if an
-   answer is secured, that it comes from an "island of security" and is
-   properly signed, you must begin at the (appropriate) root of the
-   island of security.
-
-   To find the answer you are inspecting, you may have to descend
-   through zones within the island of security.  Beginning with the
-   trusted root of the island, you descend into the next zone down.  As
-   you trust the upper zone, you need to get data from it about the next
-   zone down, otherwise there is a vulnerable point in which a zone can
-   be hijacked. When or if you reach a point of traversing from a
-   secured zone to an unsecured zone, you have left the island of
-   security and should conclude that the answer is unsecured.
-
-   However, in RFC 2535, section 2.3.4, these words seem to conflict
-   with the need to have the parent "state" something about a child:
-
-      There MUST be a zone KEY RR, signed by its superzone, for every
-      subzone if the superzone is secure.  This will normally appear in
-      the subzone and may also be included in the superzone.  But, in
-      the case of an unsecured subzone which can not or will not be
-      modified to add any security RRs, a KEY declaring the subzone to
-      be unsecured MUST appear with the superzone signature in the
-      superzone, if the superzone is secure.
-
-   The confusion here is that in RFC 2535, a secured parent states that
-   a child is secured by SAYING NOTHING ("may also be" as opposed to
-   "MUST also be").  This is counter intuitive, the fact that an absence
-   of data means something is "secured."  This notion, while acceptable
-   in a theoretic setting has met with some discomfort in an operation
-   setting.  However, the use of "silence" to state something does
-   indeed work in this case, so there hasn't been sufficient need
-   demonstrated to change the definition.
-
-
-
-
-
-Lewis                       Standards Track                     [Page 4]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-1.4 Impact on RFC 2535
-
-   This document updates sections of RFC 2535.  The definition of a
-   secured zone is an update to section 3.4 of the RFC.  Section 3.4 is
-   updated to eliminate the definition of experimental keys and
-   illustrate a way to still achieve the functionality they were
-   designed to provide.  Section 3.1.3 is updated by the specifying the
-   value of the protocol octet in a zone key.
-
-1.5 "MUST" and other key words
-
-   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
-   in this document are to be interpreted as described in [RFC 2119].
-   Currently, only "MUST" is used in this document.
-
-2 Status of a Zone
-
-   In this section, rules governing a zone's DNSSEC status are
-   presented.  There are three levels of security defined: global,
-   local, and unsecured.  A zone is globally secure when it complies
-   with the strictest set of DNSSEC processing rules.  A zone is locally
-   secured when it is configured in such a way that only resolvers that
-   are appropriately configured see the zone as secured.  All other
-   zones are unsecured.
-
-   Note: there currently is no document completely defining DNSSEC
-   verification rules.  For the purposes of this document, the strictest
-   rules are assumed to state that the verification chain of zone keys
-   parallels the delegation tree up to the root zone.  (See 2.b below.)
-   This is not intended to disallow alternate verification paths, just
-   to establish a baseline definition.
-
-   To avoid repetition in the rules below, the following terms are
-   defined.
-
-   2.a Zone signing KEY RR - A KEY RR whose flag field has the value 01
-   for name type (indicating a zone key) and either value 00 or value 01
-   for key type (indicating a key permitted to authenticate data).  (See
-   RFC 2535, section 3.1.2).  The KEY RR also has a protocol octet value
-   of DNSSEC (3) or ALL (255).
-
-   The definition updates RFC 2535's definition of a zone key.  The
-   requirement that the protocol field be either DNSSEC or ALL is a new
-   requirement (a change to section 3.1.3.)
-
-   2.b On-tree Validation - The authorization model in which only the
-   parent zone is recognized to supply a DNSSEC-meaningful signature
-   that is used by a resolver to build a chain of trust from the child's
-
-
-
-Lewis                       Standards Track                     [Page 5]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-   keys to a recognized root of security.  The term "on-tree" refers to
-   following the DNS domain hierarchy (upwards) to reach a trusted key,
-   presumably the root key if no other key is available.  The term
-   "validation" refers to the digital signature by the parent to prove
-   the integrity, authentication and authorization of the child's key to
-   sign the child's zone data.
-
-   2.c Off-tree Validation - Any authorization model that permits domain
-   names other than the parent's to provide a signature over a child's
-   zone keys that will enable a resolver to trust the keys.
-
-2.1 Globally Secured
-
-   A globally secured zone, in a nutshell, is a zone that uses only
-   mandatory to implement algorithms (RFC 2535, section 3.2) and relies
-   on a key certification chain that parallels the delegation tree (on-
-   tree validation).  Globally secured zones are defined by the
-   following rules.
-
-   2.1.a. The zone's apex MUST have a KEY RR set.  There MUST be at
-   least one zone signing KEY RR (2.a) of a mandatory to implement
-   algorithm in the set.
-
-   2.1.b. The zone's apex KEY RR set MUST be signed by a private key
-   belonging to the parent zone.  The private key's public companion
-   MUST be a zone signing KEY RR (2.a) of a mandatory to implement
-   algorithm and owned by the parent's apex.
-
-   If a zone cannot get a conforming signature from the parent zone, the
-   child zone cannot be considered globally secured.  The only exception
-   to this is the root zone, for which there is no parent zone.
-
-   2.1.c. NXT records MUST be deployed throughout the zone.  (Clarifies
-   RFC 2535, section 2.3.2.)  Note: there is some operational discomfort
-   with the current NXT record.  This requirement is open to
-   modification when two things happen.  First, an alternate mechanism
-   to the NXT is defined and second, a means by which a zone can
-   indicate that it is using an alternate method.
-
-   2.1.d. Each RR set that qualifies for zone membership MUST be signed
-   by a key that is in the apex's KEY RR set and is a zone signing KEY
-   RR (2.a) of a mandatory to implement algorithm.  (Updates 2535,
-   section 2.3.1.)
-
-   Mentioned earlier, the root zone is a special case.  The root zone
-   will be considered to be globally secured provided that if conforms
-   to the rules for locally secured, with the exception that rule 2.1.a.
-   be also met (mandatory to implement requirement).
-
-
-
-Lewis                       Standards Track                     [Page 6]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-2.2 Locally Secured
-
-   The term "locally" stems from the likely hood that the only resolvers
-   to be configured for a particular zone will be resolvers "local" to
-   an organization.
-
-   A locally secured zone is a zone that complies with rules like those
-   for a globally secured zone with the following exceptions.  The
-   signing keys may be of an algorithm that is not mandatory to
-   implement and/or the verification of the zone keys in use may rely on
-   a verification chain that is not parallel to the delegation tree
-   (off-tree validation).
-
-   2.2.a. The zone's apex MUST have a KEY RR set.  There MUST be at
-   least one zone signing KEY RR (2.a) in the set.
-
-   2.2.b. The zone's apex KEY RR set MUST be signed by a private key and
-   one of the following two subclauses MUST hold true.
-
-   2.2.b.1 The private key's public companion MUST be pre-configured in
-   all the resolvers of interest.
-
-   2.2.b.2 The private key's public companion MUST be a zone signing KEY
-   RR (2.a) authorized to provide validation of the zone's apex KEY RR
-   set, as recognized by resolvers of interest.
-
-   The previous sentence is trying to convey the notion of using a
-   trusted third party to provide validation of keys.  If the domain
-   name owning the validating key is not the parent zone, the domain
-   name must represent someone the resolver trusts to provide
-   validation.
-
-   2.2.c. NXT records MUST be deployed throughout the zone.  Note: see
-   the discussion following 2.1.c.
-
-   2.2.d. Each RR set that qualifies for zone membership MUST be signed
-   by a key that is in the apex's KEY RR set and is a zone signing KEY
-   RR (2.a).  (Updates 2535, section 2.3.1.)
-
-2.3 Unsecured
-
-   All other zones qualify as unsecured.  This includes zones that are
-   designed to be experimentally secure, as defined in a later section
-   on that topic.
-
-
-
-
-
-
-
-Lewis                       Standards Track                     [Page 7]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-2.4 Wrap up
-
-   The designation of globally secured, locally secured, and unsecured
-   are merely labels to apply to zones, based on their contents.
-   Resolvers, when determining whether a signature is expected or not,
-   will only see a zone as secured or unsecured.
-
-   Resolvers that follow the most restrictive DNSSEC verification rules
-   will only see globally secured zones as secured, and all others as
-   unsecured, including zones which are locally secured.  Resolvers that
-   are not as restrictive, such as those that implement algorithms in
-   addition to the mandatory to implement algorithms, will see some
-   locally secured zones as secured.
-
-   The intent of the labels "global" and "local" is to identify the
-   specific attributes of a zone.  The words are chosen to assist in the
-   writing of a document recommending the actions a zone administrator
-   take in making use of the DNS security extensions.  The words are
-   explicitly not intended to convey a state of compliance with DNS
-   security standards.
-
-3 Experimental Status
-
-   The purpose of an experimentally secured zone is to facilitate the
-   migration from an unsecured zone to a secured zone.  This distinction
-   is dropped.
-
-   The objective of facilitating the migration can be achieved without a
-   special designation of an experimentally secure status.
-   Experimentally secured is a special case of locally secured.  A zone
-   administrator can achieve this by publishing a zone with signatures
-   and configuring a set of test resolvers with the corresponding public
-   keys.  Even if the public key is published in a KEY RR, as long as
-   there is no parent signature, the resolvers will need some pre-
-   configuration to know to process the signatures.  This allows a zone
-   to be secured with in the sphere of the experiment, yet still be
-   registered as unsecured in the general Internet.
-
-4 IANA Considerations
-
-   This document does not request any action from an assigned number
-   authority nor recommends any actions.
-
-
-
-
-
-
-
-
-
-Lewis                       Standards Track                     [Page 8]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-5 Security Considerations
-
-   Without a means to enforce compliance with specified protocols or
-   recommended actions, declaring a DNS zone to be "completely" secured
-   is impossible.  Even if, assuming an omnipotent view of DNS, one can
-   declare a zone to be properly configured for security, and all of the
-   zones up to the root too, a misbehaving resolver could be duped into
-   believing bad data.  If a zone and resolver comply, a non-compliant
-   or subverted parent could interrupt operations.  The best that can be
-   hoped for is that all parties are prepared to be judged secure and
-   that security incidents can be traced to the cause in short order.
-
-6 Acknowledgements
-
-   The need to refine the definition of a secured zone has become
-   apparent through the efforts of the participants at two DNSSEC
-   workshops, sponsored by the NIC-SE (.se registrar), CAIRN (a DARPA-
-   funded research network), and other workshops.  Further discussions
-   leading to the document include Olafur Gudmundsson, Russ Mundy,
-   Robert Watson, and Brian Wellington.  Roy Arends, Ted Lindgreen and
-   others have contributed significant input via the namedroppers
-   mailing list.
-
-7 References
-
-   [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.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2136] Vixie, P., (Ed.), Thomson, S., Rekhter, Y. and J. Bound,
-             "Dynamic Updates in the Domain Name System", RFC 2136,
-             April 1997.
-
-   [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
-             2535, March 1999.
-
-   [RFC3007] Wellington, B., "Simple 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.
-
-
-
-
-
-Lewis                       Standards Track                     [Page 9]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-10 Author's Address
-
-   Edward Lewis
-   NAI Labs
-   3060 Washington Road Glenwood
-   MD 21738
-
-   Phone: +1 443 259 2352
-   EMail: lewis@tislabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis                       Standards Track                    [Page 10]
-
-RFC 3090         DNS Security Extension on Zone Status        March 2001
-
-
-11 Full Copyright Statement
-
-   Copyright (C) The Internet Society (2001).  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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lewis                       Standards Track                    [Page 11]
-
diff --git a/contrib/bind9/doc/rfc/rfc3110.txt b/contrib/bind9/doc/rfc/rfc3110.txt
deleted file mode 100644
index 7646948..0000000
--- a/contrib/bind9/doc/rfc/rfc3110.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                    D. Eastlake 3rd
-Request for Comments: 3110                                      Motorola
-Obsoletes: 2537                                                 May 2001
-Category: Standards Track
-
-
-      RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-Abstract
-
-   This document describes how to produce RSA/SHA1 SIG resource records
-   (RRs) in Section 3 and, so as to completely replace RFC 2537,
-   describes how to produce RSA KEY RRs in Section 2.
-
-   Since the adoption of a Proposed Standard for RSA signatures in the
-   DNS (Domain Name Space), advances in hashing have been made.  A new
-   DNS signature algorithm is defined to make these advances available
-   in SIG RRs.  The use of the previously specified weaker mechanism is
-   deprecated.  The algorithm number of the RSA KEY RR is changed to
-   correspond to this new SIG algorithm.  No other changes are made to
-   DNS security.
-
-Acknowledgements
-
-   Material and comments from the following have been incorporated and
-   are gratefully acknowledged:
-
-      Olafur Gudmundsson
-
-      The IESG
-
-      Charlie Kaufman
-
-      Steve Wang
-
-
-
-
-
-D. Eastlake 3rd             Standards Track                     [Page 1]
-
-RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
-
-
-Table of Contents
-
-   1. Introduction................................................... 2
-   2. RSA Public KEY Resource Records................................ 3
-   3. RSA/SHA1 SIG Resource Records.................................. 3
-   4. Performance Considerations..................................... 4
-   5. IANA Considerations............................................ 5
-   6. Security Considerations........................................ 5
-   References........................................................ 5
-   Author's Address.................................................. 6
-   Full Copyright Statement.......................................... 7
-
-1. Introduction
-
-   The Domain Name System (DNS) is the global hierarchical replicated
-   distributed database system for Internet addressing, mail proxy, and
-   other information [RFC1034, 1035, etc.].  The DNS has been extended
-   to include digital signatures and cryptographic keys as described in
-   [RFC2535].  Thus the DNS can now be secured and used for secure key
-   distribution.
-
-   Familiarity with the RSA and SHA-1 algorithms is assumed [Schneier,
-   FIP180] in this document.
-
-   RFC 2537 described how to store RSA keys and RSA/MD5 based signatures
-   in the DNS.  However, since the adoption of RFC 2537, continued
-   cryptographic research has revealed hints of weakness in the MD5
-   [RFC1321] algorithm used in RFC 2537.  The SHA1 Secure Hash Algorithm
-   [FIP180], which produces a larger hash, has been developed.  By now
-   there has been sufficient experience with SHA1 that it is generally
-   acknowledged to be stronger than MD5.  While this stronger hash is
-   probably not needed today in most secure DNS zones, critical zones
-   such a root, most top level domains, and some second and third level
-   domains, are sufficiently valuable targets that it would be negligent
-   not to provide what are generally agreed to be stronger mechanisms.
-   Furthermore, future advances in cryptanalysis and/or computer speeds
-   may require a stronger hash everywhere.  In addition, the additional
-   computation required by SHA1 above that required by MD5 is
-   insignificant compared with the computational effort required by the
-   RSA modular exponentiation.
-
-   This document describes how to produce RSA/SHA1 SIG RRs in Section 3
-   and, so as to completely replace RFC 2537, describes how to produce
-   RSA KEY RRs in Section 2.
-
-   Implementation of the RSA algorithm in DNS with SHA1 is MANDATORY for
-   DNSSEC.  The generation of RSA/MD5 SIG RRs as described in RFC 2537
-   is NOT RECOMMENDED.
-
-
-
-D. Eastlake 3rd             Standards Track                     [Page 2]
-
-RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
-
-
-   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", "NOT
-   RECOMMENDED", and "MAY" in this document are to be interpreted as
-   described in RFC 2119.
-
-2. RSA Public KEY Resource Records
-
-   RSA public keys are stored in the DNS as KEY RRs using algorithm
-   number 5 [RFC2535].  The structure of the algorithm specific portion
-   of the RDATA part of such RRs is as shown below.
-
-         Field             Size
-         -----             ----
-         exponent length   1 or 3 octets (see text)
-         exponent          as specified by length field
-         modulus           remaining space
-
-   For interoperability, the exponent and modulus are each limited to
-   4096 bits in length.  The public key exponent is a variable length
-   unsigned integer.  Its length in octets is represented as one octet
-   if it is in the range of 1 to 255 and by a zero octet followed by a
-   two octet unsigned length if it is longer than 255 bytes.  The public
-   key modulus field is a multiprecision unsigned integer.  The length
-   of the modulus can be determined from the RDLENGTH and the preceding
-   RDATA fields including the exponent.  Leading zero octets are
-   prohibited in the exponent and modulus.
-
-   Note: KEY RRs for use with RSA/SHA1 DNS signatures MUST use this
-   algorithm number (rather than the algorithm number specified in the
-   obsoleted RFC 2537).
-
-   Note: This changes the algorithm number for RSA KEY RRs to be the
-   same as the new algorithm number for RSA/SHA1 SIGs.
-
-3. RSA/SHA1 SIG Resource Records
-
-   RSA/SHA1 signatures are stored in the DNS using SIG resource records
-   (RRs) with algorithm number 5.
-
-   The signature portion of the SIG RR RDATA area, when using the
-   RSA/SHA1 algorithm, is calculated as shown below.  The data signed is
-   determined as specified in RFC 2535.  See RFC 2535 for fields in the
-   SIG RR RDATA which precede the signature itself.
-
-         hash = SHA1 ( data )
-
-         signature = ( 01 | FF* | 00 | prefix | hash ) ** e (mod n)
-
-
-
-
-
-D. Eastlake 3rd             Standards Track                     [Page 3]
-
-RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
-
-
-   where SHA1 is the message digest algorithm documented in [FIP180],
-   "|" is concatenation, "e" is the private key exponent of the signer,
-   and "n" is the modulus of the signer's public key.  01, FF, and 00
-   are fixed octets of the corresponding hexadecimal value.  "prefix" is
-   the ASN.1 BER SHA1 algorithm designator prefix required in PKCS1
-   [RFC2437], that is,
-
-         hex 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14
-
-   This prefix is included to make it easier to use standard
-   cryptographic libraries.  The FF octet MUST be repeated the maximum
-   number of times such that the value of the quantity being
-   exponentiated is one octet shorter than the value of n.
-
-   (The above specifications are identical to the corresponding parts of
-   Public Key Cryptographic Standard #1 [RFC2437].)
-
-   The size of "n", including most and least significant bits (which
-   will be 1) MUST be not less than 512 bits and not more than 4096
-   bits.  "n" and "e" SHOULD be chosen such that the public exponent is
-   small.  These are protocol limits.  For a discussion of key size see
-   RFC 2541.
-
-   Leading zero bytes are permitted in the RSA/SHA1 algorithm signature.
-
-4. Performance Considerations
-
-   General signature generation speeds are roughly the same for RSA and
-   DSA [RFC2536].  With sufficient pre-computation, signature generation
-   with DSA is faster than RSA.  Key generation is also faster for DSA.
-   However, signature verification is an order of magnitude slower with
-   DSA when the RSA public exponent is chosen to be small as is
-   recommended for KEY RRs used in domain name system (DNS) data
-   authentication.
-
-   A public exponent of 3 minimizes the effort needed to verify a
-   signature.  Use of 3 as the public exponent is weak for
-   confidentiality uses since, if the same data can be collected
-   encrypted under three different keys with an exponent of 3 then,
-   using the Chinese Remainder Theorem [NETSEC], the original plain text
-   can be easily recovered.  If a key is known to be used only for
-   authentication, as is the case with DNSSEC, then an exponent of 3 is
-   acceptable.  However other applications in the future may wish to
-   leverage DNS distributed keys for applications that do require
-   confidentiality.  For keys which might have such other uses, a more
-   conservative choice would be 65537 (F4, the fourth fermat number).
-
-
-
-
-
-D. Eastlake 3rd             Standards Track                     [Page 4]
-
-RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
-
-
-   Current DNS implementations are optimized for small transfers,
-   typically less than 512 bytes including DNS overhead.  Larger
-   transfers will perform correctly and extensions have been
-   standardized [RFC2671] to make larger transfers more efficient, it is
-   still advisable at this time to make reasonable efforts to minimize
-   the size of KEY RR sets stored within the DNS consistent with
-   adequate security.  Keep in mind that in a secure zone, at least one
-   authenticating SIG RR will also be returned.
-
-5. IANA Considerations
-
-   The DNSSEC algorithm number 5 is allocated for RSA/SHA1 SIG RRs and
-   RSA KEY RRs.
-
-6. Security Considerations
-
-   Many of the general security considerations in RFC 2535 apply.  Keys
-   retrieved from the DNS should not be trusted unless (1) they have
-   been securely obtained from a secure resolver or independently
-   verified by the user and (2) this secure resolver and secure
-   obtainment or independent verification conform to security policies
-   acceptable to the user.  As with all cryptographic algorithms,
-   evaluating the necessary strength of the key is essential and
-   dependent on local policy.  For particularly critical applications,
-   implementers are encouraged to consider the range of available
-   algorithms and key sizes.  See also RFC 2541, "DNS Security
-   Operational Considerations".
-
-References
-
-   [FIP180]   U.S. Department of Commerce, "Secure Hash Standard", FIPS
-              PUB 180-1, 17 Apr 1995.
-
-   [NETSEC]   Network Security: PRIVATE Communications in a PUBLIC
-              World, Charlie Kaufman, Radia Perlman, & Mike Speciner,
-              Prentice Hall Series in Computer Networking and
-              Distributed Communications, 1995.
-
-   [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.
-
-   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
-              April 1992.
-
-
-
-
-
-D. Eastlake 3rd             Standards Track                     [Page 5]
-
-RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
-
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2437]  Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
-              Specifications Version 2.0", RFC 2437, October 1998.
-
-   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [RFC2536]  Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
-              (DNS)", RFC 2536, March 1999.
-
-   [RFC2537]  Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
-              System (DNS)", RFC 2537, March 1999.
-
-   [RFC2541]  Eastlake, D., "DNS Security Operational Considerations",
-              RFC 2541, March 1999.
-
-   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-              2671, August 1999.
-
-   [Schneier] Bruce Schneier, "Applied Cryptography Second Edition:
-              protocols, algorithms, and source code in C", 1996, John
-              Wiley and Sons, ISBN 0-471-11709-9.
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   Motorola
-   155 Beaver Street
-   Milford, MA 01757 USA
-
-   Phone:   +1-508-261-5434 (w)
-            +1-508-634-2066 (h)
-   Fax      +1-508-261-4777 (w)
-   EMail:   Donald.Eastlake@motorola.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd             Standards Track                     [Page 6]
-
-RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2001).  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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd             Standards Track                     [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc3123.txt b/contrib/bind9/doc/rfc/rfc3123.txt
deleted file mode 100644
index 3b2fe00..0000000
--- a/contrib/bind9/doc/rfc/rfc3123.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            P. Koch
-Request for Comments: 3123                        Universitaet Bielefeld
-Category: Experimental                                         June 2001
-
-
-          A DNS RR Type for Lists of Address Prefixes (APL RR)
-
-Status of this Memo
-
-   This memo defines an Experimental Protocol for the Internet
-   community.  It does not specify an Internet standard of any kind.
-   Discussion and suggestions for improvement are requested.
-   Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-Abstract
-
-   The Domain Name System (DNS) is primarily used to translate domain
-   names into IPv4 addresses using A RRs (Resource Records).  Several
-   approaches exist to describe networks or address ranges.  This
-   document specifies a new DNS RR type "APL" for address prefix lists.
-
-1. Conventions used in this document
-
-   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].
-
-   Domain names herein are for explanatory purposes only and should not
-   be expected to lead to useful information in real life [RFC2606].
-
-2. Background
-
-   The Domain Name System [RFC1034], [RFC1035] provides a mechanism to
-   associate addresses and other Internet infrastructure elements with
-   hierarchically built domain names.  Various types of resource records
-   have been defined, especially those for IPv4 and IPv6 [RFC2874]
-   addresses.  In [RFC1101] a method is described to publish information
-   about the address space allocated to an organisation.  In older BIND
-   versions, a weak form of controlling access to zone data was
-   implemented using TXT RRs describing address ranges.
-
-   This document specifies a new RR type for address prefix lists.
-
-
-
-
-
-Koch                          Experimental                      [Page 1]
-
-RFC 3123                       DNS APL RR                      June 2001
-
-
-3. APL RR Type
-
-   An APL record has the DNS type of "APL" and a numeric value of 42
-   [IANA].  The APL RR is defined in the IN class only.  APL RRs cause
-   no additional section processing.
-
-4. APL RDATA format
-
-   The RDATA section consists of zero or more items (<apitem>) of the
-   form
-
-      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-      |                          ADDRESSFAMILY                        |
-      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-      |             PREFIX            | N |         AFDLENGTH         |
-      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-      /                            AFDPART                            /
-      |                                                               |
-      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-      ADDRESSFAMILY     16 bit unsigned value as assigned by IANA
-                        (see IANA Considerations)
-      PREFIX            8 bit unsigned binary coded prefix length.
-                        Upper and lower bounds and interpretation of
-                        this value are address family specific.
-      N                 negation flag, indicates the presence of the
-                        "!" character in the textual format.  It has
-                        the value "1" if the "!" was given, "0" else.
-      AFDLENGTH         length in octets of the following address
-                        family dependent part (7 bit unsigned).
-      AFDPART           address family dependent part.  See below.
-
-   This document defines the AFDPARTs for address families 1 (IPv4) and
-   2 (IPv6).  Future revisions may deal with additional address
-   families.
-
-4.1. AFDPART for IPv4
-
-   The encoding of an IPv4 address (address family 1) follows the
-   encoding specified for the A RR by [RFC1035], section 3.4.1.
-
-   PREFIX specifies the number of bits of the IPv4 address starting at
-   the most significant bit.  Legal values range from 0 to 32.
-
-   Trailing zero octets do not bear any information (e.g., there is no
-   semantic difference between 10.0.0.0/16 and 10/16) in an address
-   prefix, so the shortest possible AFDLENGTH can be used to encode it.
-   However, for DNSSEC [RFC2535] a single wire encoding must be used by
-
-
-
-Koch                          Experimental                      [Page 2]
-
-RFC 3123                       DNS APL RR                      June 2001
-
-
-   all.  Therefore the sender MUST NOT include trailing zero octets in
-   the AFDPART regardless of the value of PREFIX.  This includes cases
-   in which AFDLENGTH times 8 results in a value less than PREFIX.  The
-   AFDPART is padded with zero bits to match a full octet boundary.
-
-   An IPv4 AFDPART has a variable length of 0 to 4 octets.
-
-4.2. AFDPART for IPv6
-
-   The 128 bit IPv6 address (address family 2) is encoded in network
-   byte order (high-order byte first).
-
-   PREFIX specifies the number of bits of the IPv6 address starting at
-   the most significant bit.  Legal values range from 0 to 128.
-
-   With the same reasoning as in 4.1 above, the sender MUST NOT include
-   trailing zero octets in the AFDPART regardless of the value of
-   PREFIX.  This includes cases in which AFDLENGTH times 8 results in a
-   value less than PREFIX.  The AFDPART is padded with zero bits to
-   match a full octet boundary.
-
-   An IPv6 AFDPART has a variable length of 0 to 16 octets.
-
-5. Zone File Syntax
-
-   The textual representation of an APL RR in a DNS zone file is as
-   follows:
-
-   <owner>   IN   <TTL>   APL   {[!]afi:address/prefix}*
-
-   The data consists of zero or more strings of the address family
-   indicator <afi>, immediately followed by a colon ":", an address,
-   immediately followed by the "/" character, immediately followed by a
-   decimal numeric value for the prefix length.  Any such string may be
-   preceded by a "!" character.  The strings are separated by
-   whitespace.  The <afi> is the decimal numeric value of that
-   particular address family.
-
-5.1. Textual Representation of IPv4 Addresses
-
-   An IPv4 address in the <address> part of an <apitem> is in dotted
-   quad notation, just as in an A RR.  The <prefix> has values from the
-   interval 0..32 (decimal).
-
-
-
-
-
-
-
-
-Koch                          Experimental                      [Page 3]
-
-RFC 3123                       DNS APL RR                      June 2001
-
-
-5.2. Textual Representation of IPv6 Addresses
-
-   The representation of an IPv6 address in the <address> part of an
-   <apitem> follows [RFC2373], section 2.2.  Legal values for <prefix>
-   are from the interval 0..128 (decimal).
-
-6. APL RR usage
-
-   An APL RR with empty RDATA is valid and implements an empty list.
-   Multiple occurrences of the same <apitem> in a single APL RR are
-   allowed and MUST NOT be merged by a DNS server or resolver.
-   <apitems> MUST be kept in order and MUST NOT be rearranged or
-   aggregated.
-
-   A single APL RR may contain <apitems> belonging to different address
-   families.  The maximum number of <apitems> is upper bounded by the
-   available RDATA space.
-
-   RRSets consisting of more than one APL RR are legal but the
-   interpretation is left to the particular application.
-
-7. Applicability Statement
-
-   The APL RR defines a framework without specifying any particular
-   meaning for the list of prefixes.  It is expected that APL RRs will
-   be used in different application scenarios which have to be
-   documented separately.  Those scenarios may be distinguished by
-   characteristic prefixes placed in front of the DNS owner name.
-
-   An APL application specification MUST include information on
-
-   o  the characteristic prefix, if any
-
-   o  how to interpret APL RRSets consisting of more than one RR
-
-   o  how to interpret an empty APL RR
-
-   o  which address families are expected to appear in the APL RRs for
-      that application
-
-   o  how to deal with APL RR list elements which belong to other
-      address families, including those not yet defined
-
-   o  the exact semantics of list elements negated by the "!" character
-
-
-
-
-
-
-
-Koch                          Experimental                      [Page 4]
-
-RFC 3123                       DNS APL RR                      June 2001
-
-
-   Possible applications include the publication of address ranges
-   similar to [RFC1101], description of zones built following [RFC2317]
-   and in-band access control to limit general access or zone transfer
-   (AXFR) availability for zone data held in DNS servers.
-
-   The specification of particular application scenarios is out of the
-   scope of this document.
-
-8. Examples
-
-   The following examples only illustrate some of the possible usages
-   outlined in the previous section.  None of those applications are
-   hereby specified nor is it implied that any particular APL RR based
-   application does exist now or will exist in the future.
-
-  ; RFC 1101-like announcement of address ranges for foo.example
-  foo.example.             IN APL 1:192.168.32.0/21 !1:192.168.38.0/28
-
-  ; CIDR blocks covered by classless delegation
-  42.168.192.IN-ADDR.ARPA. IN APL ( 1:192.168.42.0/26 1:192.168.42.64/26
-                                  1:192.168.42.128/25 )
-
-  ; Zone transfer restriction
-  _axfr.sbo.example.       IN APL 1:127.0.0.1/32 1:172.16.64.0/22
-
-  ; List of address ranges for multicast
-  multicast.example.       IN APL 1:224.0.0.0/4  2:FF00:0:0:0:0:0:0:0/8
-
-   Note that since trailing zeroes are ignored in the first APL RR the
-   AFDLENGTH of both <apitems> is three.
-
-9. Security Considerations
-
-   Any information obtained from the DNS should be regarded as unsafe
-   unless techniques specified in [RFC2535] or [RFC2845] were used.  The
-   definition of a new RR type does not introduce security problems into
-   the DNS, but usage of information made available by APL RRs may
-   compromise security.  This includes disclosure of network topology
-   information and in particular the use of APL RRs to construct access
-   control lists.
-
-
-
-
-
-
-
-
-
-
-
-Koch                          Experimental                      [Page 5]
-
-RFC 3123                       DNS APL RR                      June 2001
-
-
-10. IANA Considerations
-
-   This section is to be interpreted as following [RFC2434].
-
-   This document does not define any new namespaces.  It uses the 16 bit
-   identifiers for address families maintained by IANA in
-   http://www.iana.org/numbers.html.
-
-   The IANA assigned numeric RR type value 42 for APL [IANA].
-
-11. Acknowledgements
-
-   The author would like to thank Mark Andrews, Olafur Gudmundsson, Ed
-   Lewis, Thomas Narten, Erik Nordmark, and Paul Vixie for their review
-   and constructive comments.
-
-12. References
-
-   [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.
-
-   [RFC1101] Mockapetris, P., "DNS Encoding of Network Names and Other
-             Types", RFC 1101, April 1989.
-
-   [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.
-
-   [RFC2317] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
-             ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.
-
-   [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
-             Architecture", RFC 2373, July 1998.
-
-   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
-             IANA Considerations Section in RFCs", BCP 26, RFC 2434,
-             October 1998.
-
-   [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
-             2535, March 1999.
-
-   [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names",
-             BCP 32, RFC 2606, June 1999.
-
-
-
-Koch                          Experimental                      [Page 6]
-
-RFC 3123                       DNS APL RR                      June 2001
-
-
-   [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
-             "Secret Key Transaction Authentication for DNS (TSIG)", RFC
-             2845, May 2000.
-
-   [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
-             IPv6 Address Aggregation and Renumbering", RFC 2874, July
-             2000.
-
-   [IANA]    http://www.iana.org/assignments/dns-parameters
-
-13. Author's Address
-
-   Peter Koch
-   Universitaet Bielefeld
-   Technische Fakultaet
-   D-33594 Bielefeld
-   Germany
-
-   Phone: +49 521 106 2902
-   EMail: pk@TechFak.Uni-Bielefeld.DE
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Koch                          Experimental                      [Page 7]
-
-RFC 3123                       DNS APL RR                      June 2001
-
-
-14. Full Copyright Statement
-
-   Copyright (C) The Internet Society (2001).  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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Koch                          Experimental                      [Page 8]
-
diff --git a/contrib/bind9/doc/rfc/rfc3152.txt b/contrib/bind9/doc/rfc/rfc3152.txt
deleted file mode 100644
index b226ce6..0000000
--- a/contrib/bind9/doc/rfc/rfc3152.txt
+++ /dev/null
@@ -1,227 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            R. Bush
-Request for Comments: 3152                                         RGnet
-BCP: 49                                                      August 2001
-Updates: 2874, 2772, 2766, 2553, 1886
-Category: Best Current Practice
-
-
-                         Delegation of IP6.ARPA
-
-Status of this Memo
-
-   This document specifies an Internet Best Current Practices for the
-   Internet Community, and requests discussion and suggestions for
-   improvements.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-Abstract
-
-   This document discusses the need for delegation of the IP6.ARPA DNS
-   zone, and specifies a plan for the technical operation thereof.
-
-1. Why IP6.ARPA?
-
-   In the IPv6 address space, there is a need for 'reverse mapping' of
-   addresses to DNS names analogous to that provided by the IN-ADDR.ARPA
-   zone for IPv4.
-
-   The IAB recommended that the ARPA top level domain (the name is now
-   considered an acronym for "Address and Routing Parameters Area") be
-   used for technical infrastructure sub-domains when possible.  It is
-   already in use for IPv4 reverse mapping and has been established as
-   the location for E.164 numbering on the Internet [RFC2916 RFC3026].
-
-   IETF consensus was reached that the IP6.ARPA domain be used for
-   address to DNS name mapping for the IPv6 address space [RFC2874].
-
-2. Obsoleted Usage
-
-   This document deprecates references to IP6.INT in [RFC1886] section
-   2.5, [RFC2553] section 6.2.3, [RFC2766] section 4.1, [RFC2772]
-   section 7.1.c, and [RFC2874] section 2.5.
-
-   In this context, 'deprecate' means that the old usage is not
-   appropriate for new implementations, and IP6.INT will likely be
-   phased out in an orderly fashion.
-
-
-
-Bush                     Best Current Practice                  [Page 1]
-
-RFC 3152                 Delegation of IP6.ARPA              August 2001
-
-
-3. IANA Considerations
-
-   This memo requests that the IANA delegate the IP6.ARPA domain
-   following instructions to be provided by the IAB.  Names within this
-   zone are to be further delegated to the regional IP registries in
-   accordance with the delegation of IPv6 address space to those
-   registries.  The names allocated should be hierarchic in accordance
-   with the address space assignment.
-
-4. Security Considerations
-
-   While DNS spoofing of address to name mapping has been exploited in
-   IPv4, delegation of the IP6.ARPA zone creates no new threats to the
-   security of the internet.
-
-5. References
-
-   [RFC1886]   Thomson, S. and C. Huitema, "DNS Extensions to support IP
-               version 6", RFC 1886, December 1995.
-
-   [RFC2553]   Gilligan, R., Thomson, S., Bound, J. and W. Stevens,
-               "Basic Socket Interface Extensions for IPv6", RFC 2553,
-               March 1999.
-
-   [RFC2766]   Tsirtsis, G. and P. Srisuresh, "Network Address
-               Translation - Protocol Translation (NAT-PT)", RFC 2766,
-               February 2000.
-
-   [RFC2772]   Rockell, R. and R. Fink, "6Bone Backbone Routing
-               Guidelines", RFC 2772, February 2000.
-
-   [RFC2874]   Crawford, M. and C. Huitema, "DNS Extensions to Support
-               IPv6 Address Aggregation and Renumbering", RFC 2874, July
-               2001.
-
-   [RFC2916]   Faltstrom, P., "E.164 number and DNS", RFC 2916,
-               September 2000.
-
-   [RFC3026]   Blane, R., "Liaison to IETF/ISOC on ENUM", RFC 3026,
-               January 2001.
-
-
-
-
-
-
-
-
-
-
-
-Bush                     Best Current Practice                  [Page 2]
-
-RFC 3152                 Delegation of IP6.ARPA              August 2001
-
-
-6. Author's Address
-
-   Randy Bush
-   5147 Crystal Springs
-   Bainbridge Island, WA US-98110
-
-   Phone: +1 206 780 0431
-   EMail: randy@psg.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bush                     Best Current Practice                  [Page 3]
-
-RFC 3152                 Delegation of IP6.ARPA              August 2001
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2001).  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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bush                     Best Current Practice                  [Page 4]
-
diff --git a/contrib/bind9/doc/rfc/rfc3197.txt b/contrib/bind9/doc/rfc/rfc3197.txt
deleted file mode 100644
index 94cefa4..0000000
--- a/contrib/bind9/doc/rfc/rfc3197.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         R. Austein
-Request for Comments: 3197                                 InterNetShare
-Category: Informational                                    November 2001
-
-
-             Applicability Statement for DNS MIB Extensions
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-Abstract
-
-   This document explains why, after more than six years as proposed
-   standards, the DNS Server and Resolver MIB extensions were never
-   deployed, and recommends retiring these MIB extensions by moving them
-   to Historical status.
-
-1. History
-
-   The road to the DNS MIB extensions was paved with good intentions.
-
-   In retrospect, it's obvious that the working group never had much
-   agreement on what belonged in the MIB extensions, just that we should
-   have some.  This happened during the height of the craze for MIB
-   extensions in virtually every protocol that the IETF was working on
-   at the time, so the question of why we were doing this in the first
-   place never got a lot of scrutiny.  Very late in the development
-   cycle we discovered that much of the support for writing the MIB
-   extensions in the first place had come from people who wanted to use
-   SNMP SET operations to update DNS zones on the fly.  Examination of
-   the security model involved, however, led us to conclude that this
-   was not a good way to do dynamic update and that a separate DNS
-   Dynamic Update protocol would be necessary.
-
-   The MIB extensions started out being fairly specific to one
-   particular DNS implementation (BIND-4.8.3); as work progressed, the
-   BIND-specific portions were rewritten to be as implementation-neutral
-   as we knew how to make them, but somehow every revision of the MIB
-   extensions managed to create new counters that just happened to
-   closely match statistics kept by some version of BIND.  As a result,
-   the MIB extensions ended up being much too big, which raised a number
-
-
-
-Austein                      Informational                      [Page 1]
-
-RFC 3197      Applicability Statement - DNS MIB Extensions November 2001
-
-
-   of concerns with the network management directorate, but the WG
-   resisted every attempt to remove any of these variables.  In the end,
-   large portions of the MIB extensions were moved into optional groups
-   in an attempt to get the required subset down to a manageable size.
-
-   The DNS Server and Resolver MIB extensions were one of the first
-   attempts to write MIB extensions for a protocol usually considered to
-   be at the application layer.  Fairly early on it became clear that,
-   while it was certainly possible to write MIB extensions for DNS, the
-   SMI was not really designed with this sort of thing in mind.  A case
-   in point was the attempt to provide direct indexing into the caches
-   in the resolver MIB extensions: while arguably the only sane way to
-   do this for a large cache, this required much more complex indexing
-   clauses than is usual, and ended up running into known length limits
-   for object identifiers in some SNMP implementations.
-
-   Furthermore, the lack of either real proxy MIB support in SNMP
-   managers or a standard subagent protocol meant that there was no
-   reasonable way to implement the MIB extensions in the dominant
-   implementation (BIND).  When the AgentX subagent protocol was
-   developed a few years later, we initially hoped that this would
-   finally clear the way for an implementation of the DNS MIB
-   extensions, but by the time AgentX was a viable protocol it had
-   become clear that nobody really wanted to implement these MIB
-   extensions.
-
-   Finally, the MIB extensions took much too long to produce.  In
-   retrospect, this should have been a clear warning sign, particularly
-   when the WG had clearly become so tired of the project that the
-   authors found it impossible to elicit any comments whatsoever on the
-   documents.
-
-2. Lessons
-
-   Observations based on the preceding list of mistakes, for the benefit
-   of anyone else who ever attempts to write DNS MIB extensions again:
-
-   -  Define a clear set of goals before writing any MIB extensions.
-      Know who the constituency is and make sure that what you write
-      solves their problem.
-
-   -  Keep the MIB extensions short, and don't add variables just
-      because somebody in the WG thinks they'd be a cool thing to
-      measure.
-
-   -  If some portion of the task seems to be very hard to do within the
-      SMI, that's a strong hint that SNMP is not the right tool for
-      whatever it is that you're trying to do.
-
-
-
-Austein                      Informational                      [Page 2]
-
-RFC 3197      Applicability Statement - DNS MIB Extensions November 2001
-
-
-   -  If the entire project is taking too long, perhaps that's a hint
-      too.
-
-3. Recommendation
-
-   In view of the community's apparent total lack of interest in
-   deploying these MIB extensions, we recommend that RFCs 1611 and 1612
-   be reclassified as Historical documents.
-
-4. Security Considerations
-
-   Re-classifying an existing MIB document from Proposed Standard to
-   Historic should not have any negative impact on security for the
-   Internet.
-
-5. IANA Considerations
-
-   Getting rid of the DNS MIB extensions should not impose any new work
-   on IANA.
-
-6. Acknowledgments
-
-   The author would like to thank all the people who were involved in
-   this project over the years for their optimism and patience,
-   misguided though it may have been.
-
-7. References
-
-   [DNS-SERVER-MIB]     Austein, R. and J. Saperia, "DNS Server MIB
-                        Extensions", RFC 1611, May 1994.
-
-   [DNS-RESOLVER-MIB]   Austein, R. and J. Saperia, "DNS Resolver MIB
-                        Extensions", RFC 1612, May 1994.
-
-   [DNS-DYNAMIC-UPDATE] Vixie, P., Thomson, S., Rekhter, Y. and J.
-                        Bound, "Dynamic Updates in the Domain Name
-                        System (DNS UPDATE)", RFC 2136, April 1997.
-
-   [AGENTX]             Daniele, M., Wijnen, B., Ellison, M., and D.
-                        Francisco, "Agent Extensibility (AgentX)
-                        Protocol Version 1", RFC 2741, January 2000.
-
-
-
-
-
-
-
-
-
-
-Austein                      Informational                      [Page 3]
-
-RFC 3197      Applicability Statement - DNS MIB Extensions November 2001
-
-
-8. Author's Address
-
-   Rob Austein
-   InterNetShare, Incorporated
-   325M Sharon Park Drive, Suite 308
-   Menlo Park, CA  94025
-   USA
-
-   EMail: sra@hactrn.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                      Informational                      [Page 4]
-
-RFC 3197      Applicability Statement - DNS MIB Extensions November 2001
-
-
-9. Full Copyright Statement
-
-   Copyright (C) The Internet Society (2001).  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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                      Informational                      [Page 5]
-
diff --git a/contrib/bind9/doc/rfc/rfc3225.txt b/contrib/bind9/doc/rfc/rfc3225.txt
deleted file mode 100644
index 13e6768..0000000
--- a/contrib/bind9/doc/rfc/rfc3225.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          D. Conrad
-Request for Comments: 3225                                 Nominum, Inc.
-Category: Standards Track                                  December 2001
-
-
-                 Indicating Resolver Support of DNSSEC
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-Abstract
-
-   In order to deploy DNSSEC (Domain Name System Security Extensions)
-   operationally, DNSSEC aware servers should only perform automatic
-   inclusion of DNSSEC RRs when there is an explicit indication that the
-   resolver can understand those RRs.  This document proposes the use of
-   a bit in the EDNS0 header to provide that explicit indication and
-   describes the necessary protocol changes to implement that
-   notification.
-
-1. Introduction
-
-   DNSSEC [RFC2535] has been specified to provide data integrity and
-   authentication to security aware resolvers and applications through
-   the use of cryptographic digital signatures.  However, as DNSSEC is
-   deployed, non-DNSSEC-aware clients will likely query DNSSEC-aware
-   servers.  In such situations, the DNSSEC-aware server (responding to
-   a request for data in a signed zone) will respond with SIG, KEY,
-   and/or NXT records.  For reasons described in the subsequent section,
-   such responses can have significant negative operational impacts for
-   the DNS infrastructure.
-
-   This document discusses a method to avoid these negative impacts,
-   namely DNSSEC-aware servers should only respond with SIG, KEY, and/or
-   NXT RRs when there is an explicit indication from the resolver that
-   it can understand those RRs.
-
-   For the purposes of this document, "DNSSEC security RRs" are
-   considered RRs of type SIG, KEY, or NXT.
-
-
-
-Conrad                      Standards Track                     [Page 1]
-
-RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
-
-
-   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].
-
-2. Rationale
-
-   Initially, as DNSSEC is deployed, the vast majority of queries will
-   be from resolvers that are not DNSSEC aware and thus do not
-   understand or support the DNSSEC security RRs.  When a query from
-   such a resolver is received for a DNSSEC signed zone, the DNSSEC
-   specification indicates the nameserver must respond with the
-   appropriate DNSSEC security RRs.  As DNS UDP datagrams are limited to
-   512 bytes [RFC1035], responses including DNSSEC security RRs have a
-   high probability of resulting in a truncated response being returned
-   and the resolver retrying the query using TCP.
-
-   TCP DNS queries result in significant overhead due to connection
-   setup and teardown.  Operationally, the impact of these TCP queries
-   will likely be quite detrimental in terms of increased network
-   traffic (typically five packets for a single query/response instead
-   of two), increased latency resulting from the additional round trip
-   times, increased incidences of queries failing due to timeouts, and
-   significantly increased load on nameservers.
-
-   In addition, in preliminary and experimental deployment of DNSSEC,
-   there have been reports of non-DNSSEC aware resolvers being unable to
-   handle responses which contain DNSSEC security RRs, resulting in the
-   resolver failing (in the worst case) or entire responses being
-   ignored (in the better case).
-
-   Given these operational implications, explicitly notifying the
-   nameserver that the client is prepared to receive (if not understand)
-   DNSSEC security RRs would be prudent.
-
-   Client-side support of DNSSEC is assumed to be binary -- either the
-   client is willing to receive all DNSSEC security RRs or it is not
-   willing to accept any.  As such, a single bit is sufficient to
-   indicate client-side DNSSEC support.  As effective use of DNSSEC
-   implies the need of EDNS0 [RFC2671], bits in the "classic" (non-EDNS
-   enhanced DNS header) are scarce, and there may be situations in which
-   non-compliant caching or forwarding servers inappropriately copy data
-   from classic headers as queries are passed on to authoritative
-   servers, the use of a bit from the EDNS0 header is proposed.
-
-   An alternative approach would be to use the existence of an EDNS0
-   header as an implicit indication of client-side support of DNSSEC.
-   This approach was not chosen as there may be applications in which
-   EDNS0 is supported but in which the use of DNSSEC is inappropriate.
-
-
-
-Conrad                      Standards Track                     [Page 2]
-
-RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
-
-
-3. Protocol Changes
-
-   The mechanism chosen for the explicit notification of the ability of
-   the client to accept (if not understand) DNSSEC security RRs is using
-   the most significant bit of the Z field on the EDNS0 OPT header in
-   the query.  This bit is referred to as the "DNSSEC OK" (DO) bit.  In
-   the context of the EDNS0 OPT meta-RR, the DO bit is the first bit of
-   the third and fourth bytes of the "extended RCODE and flags" portion
-   of the EDNS0 OPT meta-RR, structured as follows:
-
-                +0 (MSB)                +1 (LSB)
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      0: |   EXTENDED-RCODE      |       VERSION         |
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      2: |DO|                    Z                       |
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-   Setting the DO bit to one in a query indicates to the server that the
-   resolver is able to accept DNSSEC security RRs.  The DO bit cleared
-   (set to zero) indicates the resolver is unprepared to handle DNSSEC
-   security RRs and those RRs MUST NOT be returned in the response
-   (unless DNSSEC security RRs are explicitly queried for).  The DO bit
-   of the query MUST be copied in the response.
-
-   More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY,
-   or NXT RRs to authenticate a response as specified in [RFC2535]
-   unless the DO bit was set on the request.  Security records that
-   match an explicit SIG, KEY, NXT, or ANY query, or are part of the
-   zone data for an AXFR or IXFR query, are included whether or not the
-   DO bit was set.
-
-   A recursive DNSSEC-aware server MUST set the DO bit on recursive
-   requests, regardless of the status of the DO bit on the initiating
-   resolver request.  If the initiating resolver request does not have
-   the DO bit set, the recursive DNSSEC-aware server MUST remove DNSSEC
-   security RRs before returning the data to the client, however cached
-   data MUST NOT be modified.
-
-   In the event a server returns a NOTIMP, FORMERR or SERVFAIL response
-   to a query that has the DO bit set, the resolver SHOULD NOT expect
-   DNSSEC security RRs and SHOULD retry the query without EDNS0 in
-   accordance with section 5.3 of [RFC2671].
-
-
-
-
-
-
-
-
-
-Conrad                      Standards Track                     [Page 3]
-
-RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
-
-
-Security Considerations
-
-   The absence of DNSSEC data in response to a query with the DO bit set
-   MUST NOT be taken to mean no security information is available for
-   that zone as the response may be forged or a non-forged response of
-   an altered (DO bit cleared) query.
-
-IANA Considerations
-
-   EDNS0 [RFC2671] defines 16 bits as extended flags in the OPT record,
-   these bits are encoded into the TTL field of the OPT record (RFC2671
-   section 4.6).
-
-   This document reserves one of these bits as the OK bit.  It is
-   requested that the left most bit be allocated.  Thus the USE of the
-   OPT record TTL field would look like
-
-                +0 (MSB)                +1 (LSB)
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      0: |   EXTENDED-RCODE      |       VERSION         |
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-      2: |DO|                    Z                       |
-         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-Acknowledgements
-
-   This document is based on a rough draft by Bob Halley with input from
-   Olafur Gudmundsson, Andreas Gustafsson, Brian Wellington, Randy Bush,
-   Rob Austein, Steve Bellovin, and Erik Nordmark.
-
-References
-
-   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
-             STD 13, RFC 1034, November 1987.
-
-   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
-             Specifications", STD 13, RFC 1035, November 1987.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
-             2535, March 1999.
-
-   [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-             2671, August 1999.
-
-
-
-
-
-Conrad                      Standards Track                     [Page 4]
-
-RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
-
-
-Author's Address
-
-   David Conrad
-   Nominum Inc.
-   950 Charter Street
-   Redwood City, CA 94063
-   USA
-
-   Phone: +1 650 381 6003
-   EMail: david.conrad@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Conrad                      Standards Track                     [Page 5]
-
-RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2001).  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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Conrad                      Standards Track                     [Page 6]
-
diff --git a/contrib/bind9/doc/rfc/rfc3226.txt b/contrib/bind9/doc/rfc/rfc3226.txt
deleted file mode 100644
index dac0e11..0000000
--- a/contrib/bind9/doc/rfc/rfc3226.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                     O. Gudmundsson
-Request for Comments: 3226                                 December 2001
-Updates: 2874, 2535
-Category: Standards Track
-
-
-   DNSSEC and IPv6 A6 aware server/resolver message size requirements
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2001).  All Rights Reserved.
-
-Abstract
-
-   This document mandates support for EDNS0 (Extension Mechanisms for
-   DNS) in DNS entities claiming to support either DNS Security
-   Extensions or A6 records.  This requirement is necessary because
-   these new features increase the size of DNS messages.  If EDNS0 is
-   not supported fall back to TCP will happen, having a detrimental
-   impact on query latency and DNS server load.  This document updates
-   RFC 2535 and RFC 2874, by adding new requirements.
-
-1.  Introduction
-
-   Familiarity with the DNS [RFC1034, RFC1035], DNS Security Extensions
-   [RFC2535], EDNS0 [RFC2671] and A6 [RFC2874] is helpful.
-
-   STD 13, RFC 1035 Section 2.3.4 requires that DNS messages over UDP
-   have a data payload of 512 octets or less.  Most DNS software today
-   will not accept larger UDP datagrams.  Any answer that requires more
-   than 512 octets, results in a partial and sometimes useless reply
-   with the Truncation Bit set; in most cases the requester will then
-   retry using TCP.  Furthermore, server delivery of truncated responses
-   varies widely and resolver handling of these responses also varies,
-   leading to additional inefficiencies in handling truncation.
-
-   Compared to UDP, TCP is an expensive protocol to use for a simple
-   transaction like DNS: a TCP connection requires 5 packets for setup
-   and tear down, excluding data packets, thus requiring at least 3
-   round trips on top of the one for the original UDP query.  The DNS
-
-
-
-Gudmundsson                 Standards Track                     [Page 1]
-
-RFC 3226            DNSSEC and IPv6 A6 requirements        December 2001
-
-
-   server also needs to keep a state of the connection during this
-   transaction.  Many DNS servers answer thousands of queries per
-   second, requiring them to use TCP will cause significant overhead and
-   delays.
-
-1.1.  Requirements
-
-   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
-   in this document are to be interpreted as described in RFC 2119.
-
-2.  Motivating factors
-
-2.1.  DNSSEC motivations
-
-   DNSSEC [RFC2535] secures DNS by adding a Public Key signature on each
-   RR set.  These signatures range in size from about 80 octets to 800
-   octets, most are going to be in the range of 80 to 200 octets.  The
-   addition of signatures on each or most RR sets in an answer
-   significantly increases the size of DNS answers from secure zones.
-
-   For performance reasons and to reduce load on DNS servers, it is
-   important that security aware servers and resolvers get all the data
-   in Answer and Authority section in one query without truncation.
-   Sending Additional Data in the same query is helpful when the server
-   is authoritative for the data, and this reduces round trips.
-
-   DNSSEC OK[OK] specifies how a client can, using EDNS0, indicate that
-   it is interested in receiving DNSSEC records.  The OK bit does not
-   eliminate the need for large answers for DNSSEC capable clients.
-
-2.1.1.  Message authentication or TSIG motivation
-
-   TSIG [RFC2845] allows for the light weight authentication of DNS
-   messages, but increases the size of the messages by at least 70
-   octets.  DNSSEC specifies for computationally expensive message
-   authentication SIG(0) using a standard public key signature.  As only
-   one TSIG or SIG(0) can be attached to each DNS answer the size
-   increase of message authentication is not significant, but may still
-   lead to a truncation.
-
-2.2.  IPv6 Motivations
-
-   IPv6 addresses [RFC2874] are 128 bits and can be represented in the
-   DNS by multiple A6 records, each consisting of a domain name and a
-   bit field.  The domain name refers to an address prefix that may
-   require additional A6 RRs to be included in the answer.  Answers
-   where the queried name has multiple A6 addresses may overflow a 512-
-   octet UDP packet size.
-
-
-
-Gudmundsson                 Standards Track                     [Page 2]
-
-RFC 3226            DNSSEC and IPv6 A6 requirements        December 2001
-
-
-2.3.  Root server and TLD server motivations
-
-   The current number of root servers is limited to 13 as that is the
-   maximum number of name servers and their address records that fit in
-   one 512-octet answer for a SOA record.  If root servers start
-   advertising A6 or KEY records then the answer for the root NS records
-   will not fit in a single 512-octet DNS message, resulting in a large
-   number of TCP query connections to the root servers.  Even if all
-   client resolver query their local name server for information, there
-   are millions of these servers.  Each name server must periodically
-   update its information about the high level servers.
-
-   For redundancy, latency and load balancing reasons, large numbers of
-   DNS servers are required for some zones.  Since the root zone is used
-   by the entire net, it is important to have as many servers as
-   possible.  Large TLDs (and many high-visibility SLDs) often have
-   enough servers that either A6 or KEY records would cause the NS
-   response to overflow the 512 byte limit.  Note that these zones with
-   large numbers of servers are often exactly those zones that are
-   critical to network operation and that already sustain fairly high
-   loads.
-
-2.4.  UDP vs TCP for DNS messages
-
-   Given all these factors, it is essential that any implementation that
-   supports DNSSEC and or A6 be able to use larger DNS messages than 512
-   octets.
-
-   The original 512 restriction was put in place to reduce the
-   probability of fragmentation of DNS responses.  A fragmented UDP
-   message that suffers a loss of one of the fragments renders the
-   answer useless and the query must be retried.  A TCP connection
-   requires a larger number of round trips for establishment, data
-   transfer and tear down, but only the lost data segments are
-   retransmitted.
-
-   In the early days a number of IP implementations did not handle
-   fragmentation well, but all modern operating systems have overcome
-   that issue thus sending fragmented messages is fine from that
-   standpoint.  The open issue is the effect of losses on fragmented
-   messages.  If connection has high loss ratio only TCP will allow
-   reliable transfer of DNS data, most links have low loss ratios thus
-   sending fragmented UDP packet in one round trip is better than
-   establishing a TCP connection to transfer a few thousand octets.
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 3]
-
-RFC 3226            DNSSEC and IPv6 A6 requirements        December 2001
-
-
-2.5.  EDNS0 and large UDP messages
-
-   EDNS0 [RFC2671] allows clients to declare the maximum size of UDP
-   message they are willing to handle.  Thus, if the expected answer is
-   between 512 octets and the maximum size that the client can accept,
-   the additional overhead of a TCP connection can be avoided.
-
-3.  Protocol changes:
-
-   This document updates RFC 2535 and RFC 2874, by adding new
-   requirements.
-
-   All RFC 2535 compliant servers and resolvers MUST support EDNS0 and
-   advertise message size of at least 1220 octets, but SHOULD advertise
-   message size of 4000.  This value might be too low to get full
-   answers for high level servers and successor of this document may
-   require a larger value.
-
-   All RFC 2874 compliant servers and resolver MUST support EDNS0 and
-   advertise message size of at least 1024 octets, but SHOULD advertise
-   message size of 2048.  The IPv6 datagrams should be 1024 octets,
-   unless the MTU of the path is known.  (Note that this is smaller than
-   the minimum IPv6 MTU to allow for some extension headers and/or
-   encapsulation without exceeding the minimum MTU.)
-
-   All RFC 2535 and RFC 2874 compliant entities MUST be able to handle
-   fragmented IPv4 and IPv6 UDP packets.
-
-   All hosts supporting both RFC 2535 and RFC 2874 MUST use the larger
-   required value in EDNS0 advertisements.
-
-4.  Acknowledgments
-
-   Harald Alvestrand, Rob Austein, Randy Bush, David Conrad, Andreas
-   Gustafsson, Jun-ichiro itojun Hagino, Bob Halley, Edward Lewis
-   Michael Patton and Kazu Yamamoto were instrumental in motivating and
-   shaping this document.
-
-5.  Security Considerations:
-
-   There are no additional security considerations other than those in
-   RFC 2671.
-
-6.  IANA Considerations:
-
-   None
-
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 4]
-
-RFC 3226            DNSSEC and IPv6 A6 requirements        December 2001
-
-
-7.  References
-
-   [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.
-
-   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B.
-              Wellington, "Secret Key Transaction Authentication for DNS
-              (TSIG)", RFC 2845, May 2000.
-
-   [RFC2874]  Crawford, M. and C. Huitema, "DNS Extensions to Support
-              IPv6 Address Aggregation and Renumbering", RFC 2874, July
-              2000.
-
-   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
-              3225, December 2001.
-
-8.  Author Address
-
-   Olafur Gudmundsson
-   3826 Legation Street, NW
-   Washington, DC 20015
-   USA
-
-   EMail: ogud@ogud.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 5]
-
-RFC 3226            DNSSEC and IPv6 A6 requirements        December 2001
-
-
-9.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2001).  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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 6]
-
diff --git a/contrib/bind9/doc/rfc/rfc3258.txt b/contrib/bind9/doc/rfc/rfc3258.txt
deleted file mode 100644
index dcd4b34..0000000
--- a/contrib/bind9/doc/rfc/rfc3258.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          T. Hardie
-Request for Comments: 3258                                 Nominum, Inc.
-Category: Informational                                       April 2002
-
-
-  Distributing Authoritative Name Servers via Shared Unicast Addresses
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-Abstract
-
-   This memo describes a set of practices intended to enable an
-   authoritative name server operator to provide access to a single
-   named server in multiple locations.  The primary motivation for the
-   development and deployment of these practices is to increase the
-   distribution of Domain Name System (DNS) servers to previously
-   under-served areas of the network topology and to reduce the latency
-   for DNS  query responses in those areas.
-
-1.  Introduction
-
-   This memo describes a set of practices intended to enable an
-   authoritative name server operator to provide access to a single
-   named server in multiple locations.  The primary motivation for the
-   development and deployment of these practices is to increase the
-   distribution of DNS servers to previously under-served areas of the
-   network topology and to reduce the latency for DNS query responses in
-   those areas.  This document presumes a one-to-one mapping between
-   named authoritative servers and administrative entities (operators).
-   This document contains no guidelines or recommendations for caching
-   name servers.  The shared unicast system described here is specific
-   to IPv4; applicability to IPv6 is an area for further study.  It
-   should also be noted that the system described here is related to
-   that described in [ANYCAST], but it does not require dedicated
-   address space, routing changes, or the other elements of a full
-   anycast infrastructure which that document describes.
-
-
-
-
-
-
-
-Hardie                       Informational                      [Page 1]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-2.  Architecture
-
-2.1 Server Requirements
-
-   Operators of authoritative name servers may wish to refer to
-   [SECONDARY] and [ROOT] for general guidance on appropriate practice
-   for authoritative name servers.  In addition to proper configuration
-   as a standard authoritative name server, each of the hosts
-   participating in a shared-unicast system should be configured with
-   two network interfaces.  These interfaces may be either two physical
-   interfaces or one physical interface mapped to two logical
-   interfaces.  One of the network interfaces should use the IPv4 shared
-   unicast address associated with the authoritative name server.  The
-   other interface, referred to as the administrative interface below,
-   should use a distinct IPv4 address specific to that host.  The host
-   should respond to DNS queries only on the shared-unicast interface.
-   In order to provide the most consistent set of responses from the
-   mesh of anycast hosts, it is good practice to limit responses on that
-   interface to zones for which the host is authoritative.
-
-2.2 Zone file delivery
-
-   In order to minimize the risk of man-in-the-middle attacks, zone
-   files should be delivered to the administrative interface of the
-   servers participating in the mesh.  Secure file transfer methods and
-   strong authentication should be used for all transfers.  If the hosts
-   in the mesh make their zones available for zone transfer, the
-   administrative interfaces should be used for those transfers as well,
-   in order to avoid the problems with potential routing changes for TCP
-   traffic noted in section 2.5 below.
-
-2.3 Synchronization
-
-   Authoritative name servers may be loosely or tightly synchronized,
-   depending on the practices set by the operating organization.  As
-   noted below in section 4.1.2, lack of synchronization among servers
-   using the same shared unicast address could create problems for some
-   users of this service.  In order to minimize that risk, switch-overs
-   from one data set to another data set should be coordinated as much
-   as possible.  The use of synchronized clocks on the participating
-   hosts and set times for switch-overs provides a basic level of
-   coordination.  A more complete coordination process would involve:
-
-      a) receipt of zones at a distribution host
-      b) confirmation of the integrity of zones received
-      c) distribution of the zones to all of the servers in the mesh
-      d) confirmation of the integrity of the zones at each server
-
-
-
-
-Hardie                       Informational                      [Page 2]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-      e) coordination of the switchover times for the servers in the
-         mesh
-      f) institution of a failure process to ensure that servers that
-         did not receive correct data or could not switchover to the new
-         data ceased to respond to incoming queries until the problem
-         could be resolved.
-
-   Depending on the size of the mesh, the distribution host may also be
-   a participant; for authoritative servers, it may also be the host on
-   which zones are generated.
-
-   This document presumes that the usual DNS failover methods are the
-   only ones used to ensure reachability of the data for clients.  It
-   does not advise that the routes be withdrawn in the case of failure;
-   it advises instead that the DNS process shutdown so that servers on
-   other addresses are queried.  This recommendation reflects a choice
-   between performance and operational complexity.  While it would be
-   possible to have some process withdraw the route for a specific
-   server instance when it is not available, there is considerable
-   operational complexity involved in ensuring that this occurs
-   reliably.  Given the existing DNS failover methods, the marginal
-   improvement in performance will not be sufficient to justify the
-   additional complexity for most uses.
-
-2.4 Server Placement
-
-   Though the geographic diversity of server placement helps reduce the
-   effects of service disruptions due to local problems, it is diversity
-   of placement in the network topology which is the driving force
-   behind these distribution practices.  Server placement should
-   emphasize that diversity.  Ideally, servers should be placed
-   topologically near the points at which the operator exchanges routes
-   and traffic with other networks.
-
-2.5 Routing
-
-   The organization administering the mesh of servers sharing a unicast
-   address must have an autonomous system number and speak BGP to its
-   peers.  To those peers, the organization announces a route to the
-   network containing the shared-unicast address of the name server.
-   The organization's border routers must then deliver the traffic
-   destined for the name server to the nearest instantiation.  Routing
-   to the administrative interfaces for the servers can use the normal
-   routing methods for the administering organization.
-
-   One potential problem with using shared unicast addresses is that
-   routers forwarding traffic to them may have more than one available
-   route, and those routes may, in fact, reach different instances of
-
-
-
-Hardie                       Informational                      [Page 3]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-   the shared unicast address.  Applications like the DNS, whose
-   communication typically consists of independent request-response
-   messages each fitting in a single UDP packet present no problem.
-   Other applications, in which multiple packets must reach the same
-   endpoint (e.g., TCP) may fail or present unworkable performance
-   characteristics in some circumstances.  Split-destination failures
-   may occur when a router does per-packet (or round-robin) load
-   sharing, a topology change occurs that changes the relative metrics
-   of two paths to the same anycast destination, etc.
-
-   Four things mitigate the severity of this problem.  The first is that
-   UDP is a fairly high proportion of the query traffic to name servers.
-   The second is that the aim of this proposal is to diversify
-   topological placement; for most users, this means that the
-   coordination of placement will ensure that new instances of a name
-   server will be at a significantly different cost metric from existing
-   instances.  Some set of users may end up in the middle, but that
-   should be relatively rare.  The third is that per packet load sharing
-   is only one of the possible load sharing mechanisms, and other
-   mechanisms are increasing in popularity.
-
-   Lastly, in the case where the traffic is TCP, per packet load sharing
-   is used, and equal cost routes to different instances of a name
-   server are available, any DNS implementation which measures the
-   performance of servers to select a preferred server will quickly
-   prefer a server for which this problem does not occur.  For the DNS
-   failover mechanisms to reliably avoid this problem, however, those
-   using shared unicast distribution mechanisms must take care that all
-   of the servers for a specific zone are not participants in the same
-   shared-unicast mesh.  To guard even against the case where multiple
-   meshes have a set of users affected by per packet load sharing along
-   equal cost routes, organizations implementing these practices should
-   always provide at least one authoritative server which is not a
-   participant in any shared unicast mesh.  Those deploying shared-
-   unicast meshes should note that any specific host may become
-   unreachable to a client should a server fail, a path fail, or the
-   route to that host be withdrawn.  These error conditions are,
-   however, not specific to shared-unicast distributions, but would
-   occur for standard unicast hosts.
-
-   Since ICMP response packets might go to a different member of the
-   mesh than that sending a packet, packets sent with a shared unicast
-   source address should also avoid using path MTU discovery.
-
-   Appendix A. contains an ASCII diagram of an example of a simple
-   implementation of this system.  In it, the odd numbered routers
-   deliver traffic to the shared-unicast interface network and filter
-   traffic from the administrative network; the even numbered routers
-
-
-
-Hardie                       Informational                      [Page 4]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-   deliver traffic to the administrative network and filter traffic from
-   the shared-unicast network.  These are depicted as separate routers
-   for the ease this gives in explanation, but they could easily be
-   separate interfaces on the same router.  Similarly, a local NTP
-   source is depicted for synchronization, but the level of
-   synchronization needed would not require that source to be either
-   local or a stratum one NTP server.
-
-3. Administration
-
-3.1 Points of Contact
-
-   A single point of contact for reporting problems is crucial to the
-   correct administration of this system.  If an external user of the
-   system needs to report a problem related to the service, there must
-   be no ambiguity about whom to contact.  If internal monitoring does
-   not indicate a problem, the contact may, of course, need to work with
-   the external user to identify which server generated the error.
-
-4. Security Considerations
-
-   As a core piece of Internet infrastructure, authoritative name
-   servers are common targets of attack.  The practices outlined here
-   increase the risk of certain kinds of attacks and reduce the risk of
-   others.
-
-4.1 Increased Risks
-
-4.1.1 Increase in physical servers
-
-   The architecture outlined in this document increases the number of
-   physical servers, which could increase the possibility that a server
-   mis-configuration will occur which allows for a security breach.  In
-   general, the entity administering a mesh should ensure that patches
-   and security mechanisms applied to a single member of the mesh are
-   appropriate for and applied to all of the members of a mesh.
-   "Genetic diversity" (code from different code bases) can be a useful
-   security measure in avoiding attacks based on vulnerabilities in a
-   specific code base; in order to ensure consistency of responses from
-   a single named server, however, that diversity should be applied to
-   different shared-unicast meshes or between a mesh and a related
-   unicast authoritative server.
-
-4.1.2 Data synchronization problems
-
-   The level of systemic synchronization described above should be
-   augmented by synchronization of the data present at each of the
-   servers.  While the DNS itself is a loosely coupled system, debugging
-
-
-
-Hardie                       Informational                      [Page 5]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-   problems with data in specific zones would be far more difficult if
-   two different servers sharing a single unicast address might return
-   different responses to the same query.  For example, if the data
-   associated with www.example.com has changed and the administrators of
-   the domain are testing for the changes at the example.com
-   authoritative name servers, they should not need to check each
-   instance of a named authoritative server.  The use of NTP to provide
-   a synchronized time for switch-over eliminates some aspects of this
-   problem, but mechanisms to handle failure during the switchover are
-   required.  In particular, a server which cannot make the switchover
-   must not roll-back to a previous version; it must cease to respond to
-   queries so that other servers are queried.
-
-4.1.3 Distribution risks
-
-   If the mechanism used to distribute zone files among the servers is
-   not well secured, a man-in-the-middle attack could result in the
-   injection of false information.  Digital signatures will alleviate
-   this risk, but encrypted transport and tight access lists are a
-   necessary adjunct to them.  Since zone files will be distributed to
-   the administrative interfaces of meshed servers, the access control
-   list for distribution of the zone files should include the
-   administrative interface of the server or servers, rather than their
-   shared unicast addresses.
-
-4.2 Decreased Risks
-
-   The increase in number of physical servers reduces the likelihood
-   that a denial-of-service attack will take out a significant portion
-   of the DNS infrastructure.  The increase in servers also reduces the
-   effect of machine crashes, fiber cuts, and localized disasters by
-   reducing the number of users dependent on a specific machine.
-
-5. Acknowledgments
-
-   Masataka Ohta, Bill Manning, Randy Bush, Chris Yarnell, Ray Plzak,
-   Mark Andrews, Robert Elz, Geoff Huston, Bill Norton, Akira Kato,
-   Suzanne Woolf, Bernard Aboba, Casey Ajalat, and Gunnar Lindberg all
-   provided input and commentary on this work.  The editor wishes to
-   remember in particular the contribution of the late Scott Tucker,
-   whose extensive systems experience and plain common sense both
-   contributed greatly to the editor's own deployment experience and are
-   missed by all who knew him.
-
-
-
-
-
-
-
-
-Hardie                       Informational                      [Page 6]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-6. References
-
-   [SECONDARY] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection
-               and Operation of Secondary DNS Servers", BCP 16, RFC
-               2182, July 1997.
-
-   [ROOT]      Bush, R., Karrenberg, D., Kosters, M. and R. Plzak, "Root
-               Name Server Operational Requirements", BCP 40, RFC 2870,
-               June 2000.
-
-   [ANYCAST]   Patridge, C., Mendez, T. and W. Milliken, "Host
-               Anycasting Service", RFC 1546, November 1993.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardie                       Informational                      [Page 7]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-Appendix A.
-
-       __________________
-Peer 1-|                |
-Peer 2-|                |
-Peer 3-|     Switch     |
-Transit|                |  _________                   _________
-etc    |                |--|Router1|---|----|----------|Router2|---WAN-|
-       |                |  ---------   |    |          ---------       |
-       |                |              |    |                          |
-       |                |              |    |                          |
-       ------------------            [NTP] [DNS]                       |
-                                                                       |
-                                                                       |
-                                                                       |
-                                                                       |
-       __________________                                              |
-Peer 1-|                |                                              |
-Peer 2-|                |                                              |
-Peer 3-|     Switch     |                                              |
-Transit|                |  _________                   _________       |
-etc    |                |--|Router3|---|----|----------|Router4|---WAN-|
-       |                |  ---------   |    |          ---------       |
-       |                |              |    |                          |
-       |                |              |    |                          |
-       ------------------            [NTP] [DNS]                       |
-                                                                       |
-                                                                       |
-                                                                       |
-                                                                       |
-       __________________                                              |
-Peer 1-|                |                                              |
-Peer 2-|                |                                              |
-Peer 3-|     Switch     |                                              |
-Transit|                |  _________                   _________       |
-etc    |                |--|Router5|---|----|----------|Router6|---WAN-|
-       |                |  ---------   |    |          ---------       |
-       |                |              |    |                          |
-       |                |              |    |                          |
-       ------------------            [NTP] [DNS]                       |
-                                                                       |
-                                                                       |
-                                                                       |
-
-
-
-
-
-
-
-
-Hardie                       Informational                      [Page 8]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-                                                                       |
-       __________________                                              |
-Peer 1-|                |                                              |
-Peer 2-|                |                                              |
-Peer 3-|     Switch     |                                              |
-Transit|                |  _________                   _________       |
-etc    |                |--|Router7|---|----|----------|Router8|---WAN-|
-       |                |  ---------   |    |          ---------
-       |                |              |    |
-       |                |              |    |
-       ------------------            [NTP] [DNS]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardie                       Informational                      [Page 9]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-7. Editor's Address
-
-   Ted Hardie
-   Nominum, Inc.
-   2385 Bay Road.
-   Redwood City, CA 94063
-
-   Phone: 1.650.381.6226
-   EMail: Ted.Hardie@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardie                       Informational                     [Page 10]
-
-RFC 3258        Distributing Authoritative Name Servers       April 2002
-
-
-8.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hardie                       Informational                     [Page 11]
-
diff --git a/contrib/bind9/doc/rfc/rfc3363.txt b/contrib/bind9/doc/rfc/rfc3363.txt
deleted file mode 100644
index 9d7a39c..0000000
--- a/contrib/bind9/doc/rfc/rfc3363.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            R. Bush
-Request for Comments: 3363                                     A. Durand
-Updates: 2673, 2874                                              B. Fink
-Category: Informational                                   O. Gudmundsson
-                                                                 T. Hain
-                                                                 Editors
-                                                             August 2002
-
-
-            Representing Internet Protocol version 6 (IPv6)
-               Addresses in the Domain Name System (DNS)
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-Abstract
-
-   This document clarifies and updates the standards status of RFCs that
-   define direct and reverse map of IPv6 addresses in DNS.  This
-   document moves the A6 and Bit label specifications to experimental
-   status.
-
-1.  Introduction
-
-   The IETF had begun the process of standardizing two different address
-   formats for IPv6 addresses AAAA [RFC1886] and A6 [RFC2874] and both
-   are at proposed standard.  This had led to confusion and conflicts on
-   which one to deploy.  It is important for deployment that any
-   confusion in this area be cleared up, as there is a feeling in the
-   community that having more than one choice will lead to delays in the
-   deployment of IPv6.  The goal of this document is to clarify the
-   situation.
-
-   This document also discusses issues relating to the usage of Binary
-   Labels [RFC 2673] to support the reverse mapping of IPv6 addresses.
-
-   This document is based on extensive technical discussion on various
-   relevant working groups mailing lists and a joint DNSEXT and NGTRANS
-   meeting at the 51st IETF in August 2001.  This document attempts to
-   capture the sense of the discussions and reflect them in this
-   document to represent the consensus of the community.
-
-
-
-Bush, et. al.                Informational                      [Page 1]
-
-RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
-
-
-   The main arguments and the issues are covered in a separate document
-   [RFC3364] that reflects the current understanding of the issues.
-   This document summarizes the outcome of these discussions.
-
-   The issue of the root of reverse IPv6 address map is outside the
-   scope of this document and is covered in a different document
-   [RFC3152].
-
-1.1 Standards Action Taken
-
-   This document changes the status of RFCs 2673 and 2874 from Proposed
-   Standard to Experimental.
-
-2.  IPv6 Addresses: AAAA RR vs A6 RR
-
-   Working group consensus as perceived by the chairs of the DNSEXT and
-   NGTRANS working groups is that:
-
-   a) AAAA records are preferable at the moment for production
-      deployment of IPv6, and
-
-   b) that A6 records have interesting properties that need to be better
-      understood before deployment.
-
-   c) It is not known if the benefits of A6 outweigh the costs and
-      risks.
-
-2.1 Rationale
-
-   There are several potential issues with A6 RRs that stem directly
-   from the feature that makes them different from AAAA RRs: the ability
-   to build up addresses via chaining.
-
-   Resolving a chain of A6 RRs involves resolving a series of what are
-   nearly-independent queries.  Each of these sub-queries takes some
-   non-zero amount of time, unless the answer happens to be in the
-   resolver's local cache already.  Other things being equal, we expect
-   that the time it takes to resolve an N-link chain of A6 RRs will be
-   roughly proportional to N.  What data we have suggests that users are
-   already impatient with the length of time it takes to resolve A RRs
-   in the IPv4 Internet, which suggests that users are not likely to be
-   patient with significantly longer delays in the IPv6 Internet, but
-   terminating queries prematurely is both a waste of resources and
-   another source of user frustration.  Thus, we are forced to conclude
-   that indiscriminate use of long A6 chains is likely to lead to
-   increased user frustration.
-
-
-
-
-
-Bush, et. al.                Informational                      [Page 2]
-
-RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
-
-
-   The probability of failure during the process of resolving an N-link
-   A6 chain also appears to be roughly proportional to N, since each of
-   the queries involved in resolving an A6 chain has roughly the same
-   probability of failure as a single AAAA query.
-
-   Last, several of the most interesting potential applications for A6
-   RRs involve situations where the prefix name field in the A6 RR
-   points to a target that is not only outside the DNS zone containing
-   the A6 RR, but is administered by a different organization entirely.
-   While pointers out of zone are not a problem per se, experience both
-   with glue RRs and with PTR RRs in the IN-ADDR.ARPA tree suggests that
-   pointers to other organizations are often not maintained properly,
-   perhaps because they're less susceptible to automation than pointers
-   within a single organization would be.
-
-2.2 Recommended Standard Action
-
-   Based on the perceived consensus, this document recommends that RFC
-   1886 stay on standards track and be advanced, while moving RFC 2874
-   to Experimental status.
-
-3.  Bitlabels in the Reverse DNS Tree
-
-   RFC 2673 defines a new DNS label type.  This was the first new type
-   defined since RFC 1035 [RFC1035].  Since the development of 2673 it
-   has been learned that deployment of a new type is difficult since DNS
-   servers that do not support bitlabels reject queries containing bit
-   labels as being malformed.  The community has also indicated that
-   this new label type is not needed for mapping reverse addresses.
-
-3.1 Rationale
-
-   The hexadecimal text representation of IPv6 addresses appears to be
-   capable of expressing all of the delegation schemes that we expect to
-   be used in the DNS reverse tree.
-
-3.2 Recommended Standard Action
-
-   RFC 2673 standard status is to be changed from Proposed to
-   Experimental.  Future standardization of these documents is to be
-   done by the DNSEXT working group or its successor.
-
-
-
-
-
-
-
-
-
-
-Bush, et. al.                Informational                      [Page 3]
-
-RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
-
-
-4.  DNAME in IPv6 Reverse Tree
-
-   The issues for DNAME in the reverse mapping tree appears to be
-   closely tied to the need to use fragmented A6 in the main tree: if
-   one is necessary, so is the other, and if one isn't necessary, the
-   other isn't either.  Therefore, in moving RFC 2874 to experimental,
-   the intent of this document is that use of DNAME RRs in the reverse
-   tree be deprecated.
-
-5.  Acknowledgments
-
-   This document is based on input from many members of the various IETF
-   working groups involved in this issues.  Special thanks go to the
-   people that prepared reading material for the joint DNSEXT and
-   NGTRANS working group meeting at the 51st IETF in London, Rob
-   Austein, Dan Bernstein, Matt Crawford, Jun-ichiro itojun Hagino,
-   Christian Huitema.  Number of other people have made number of
-   comments on mailing lists about this issue including Andrew W.
-   Barclay, Robert Elz, Johan Ihren, Edward Lewis, Bill Manning, Pekka
-   Savola, Paul Vixie.
-
-6.  Security Considerations
-
-   As this document specifies a course of action, there are no direct
-   security considerations.  There is an indirect security impact of the
-   choice, in that the relationship between A6 and DNSSEC is not well
-   understood throughout the community, while the choice of AAAA does
-   leads to a model for use of DNSSEC in IPv6 networks which parallels
-   current IPv4 practice.
-
-7.  IANA Considerations
-
-   None.
-
-Normative References
-
-   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
-              Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC1886]  Thompson, S. and C. Huitema, "DNS Extensions to support IP
-              version 6", RFC 1886, December 1995.
-
-   [RFC2673]  Crawford, M., "Binary Labels in the Domain Name System",
-              RFC 2673, August 1999.
-
-   [RFC2874]  Crawford, M. and C. Huitema, "DNS Extensions to Support
-              IPv6 Address Aggregation and Renumbering", RFC 2874, July
-              2000.
-
-
-
-Bush, et. al.                Informational                      [Page 4]
-
-RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
-
-
-   [RFC3152]  Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152
-              August 2001.
-
-Informative References
-
-   [RFC3364]  Austein, R., "Tradeoffs in Domain Name System (DNS)
-              Support for Internet Protocol version 6 (IPv6)", RFC 3364,
-              August 2002.
-
-Editors' Addresses
-
-   Randy Bush
-   EMail: randy@psg.com
-
-
-   Alain Durand
-   EMail: alain.durand@sun.com
-
-
-   Bob Fink
-   EMail: fink@es.net
-
-
-   Olafur Gudmundsson
-   EMail: ogud@ogud.com
-
-
-   Tony Hain
-   EMail: hain@tndh.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bush, et. al.                Informational                      [Page 5]
-
-RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bush, et. al.                Informational                      [Page 6]
-
diff --git a/contrib/bind9/doc/rfc/rfc3364.txt b/contrib/bind9/doc/rfc/rfc3364.txt
deleted file mode 100644
index 189c0d2..0000000
--- a/contrib/bind9/doc/rfc/rfc3364.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         R. Austein
-Request for Comments: 3364                           Bourgeois Dilettant
-Updates: 2673, 2874                                          August 2002
-Category: Informational
-
-
-             Tradeoffs in Domain Name System (DNS) Support
-                 for Internet Protocol version 6 (IPv6)
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-Abstract
-
-   The IETF has two different proposals on the table for how to do DNS
-   support for IPv6, and has thus far failed to reach a clear consensus
-   on which approach is better.  This note attempts to examine the pros
-   and cons of each approach, in the hope of clarifying the debate so
-   that we can reach closure and move on.
-
-Introduction
-
-   RFC 1886 [RFC1886] specified straightforward mechanisms to support
-   IPv6 addresses in the DNS.  These mechanisms closely resemble the
-   mechanisms used to support IPv4, with a minor improvement to the
-   reverse mapping mechanism based on experience with CIDR.  RFC 1886 is
-   currently listed as a Proposed Standard.
-
-   RFC 2874 [RFC2874] specified enhanced mechanisms to support IPv6
-   addresses in the DNS.  These mechanisms provide new features that
-   make it possible for an IPv6 address stored in the DNS to be broken
-   up into multiple DNS resource records in ways that can reflect the
-   network topology underlying the address, thus making it possible for
-   the data stored in the DNS to reflect certain kinds of network
-   topology changes or routing architectures that are either impossible
-   or more difficult to represent without these mechanisms.  RFC 2874 is
-   also currently listed as a Proposed Standard.
-
-
-
-
-
-
-
-Austein                      Informational                      [Page 1]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-   Both of these Proposed Standards were the output of the IPNG Working
-   Group.  Both have been implemented, although implementation of
-   [RFC1886] is more widespread, both because it was specified earlier
-   and because it's simpler to implement.
-
-   There's little question that the mechanisms proposed in [RFC2874] are
-   more general than the mechanisms proposed in [RFC1886], and that
-   these enhanced mechanisms might be valuable if IPv6's evolution goes
-   in certain directions.  The questions are whether we really need the
-   more general mechanism, what new usage problems might come along with
-   the enhanced mechanisms, and what effect all this will have on IPv6
-   deployment.
-
-   The one thing on which there does seem to be widespread agreement is
-   that we should make up our minds about all this Real Soon Now.
-
-Main Advantages of Going with A6
-
-   While the A6 RR proposed in [RFC2874] is very general and provides a
-   superset of the functionality provided by the AAAA RR in [RFC1886],
-   many of the features of A6 can also be implemented with AAAA RRs via
-   preprocessing during zone file generation.
-
-   There is one specific area where A6 RRs provide something that cannot
-   be provided using AAAA RRs: A6 RRs can represent addresses in which a
-   prefix portion of the address can change without any action (or
-   perhaps even knowledge) by the parties controlling the DNS zone
-   containing the terminal portion (least significant bits) of the
-   address.  This includes both so-called "rapid renumbering" scenarios
-   (where an entire network's prefix may change very quickly) and
-   routing architectures such as the former "GSE" proposal [GSE] (where
-   the "routing goop" portion of an address may be subject to change
-   without warning).  A6 RRs do not completely remove the need to update
-   leaf zones during all renumbering events (for example, changing ISPs
-   would usually require a change to the upward delegation pointer), but
-   careful use of A6 RRs could keep the number of RRs that need to
-   change during such an event to a minimum.
-
-   Note that constructing AAAA RRs via preprocessing during zone file
-   generation requires exactly the sort of information that A6 RRs store
-   in the DNS.  This begs the question of where the hypothetical
-   preprocessor obtains that information if it's not getting it from the
-   DNS.
-
-   Note also that the A6 RR, when restricted to its zero-length-prefix
-   form ("A6 0"), is semantically equivalent to an AAAA RR (with one
-   "wasted" octet in the wire representation), so anything that can be
-   done with an AAAA RR can also be done with an A6 RR.
-
-
-
-Austein                      Informational                      [Page 2]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-Main Advantages of Going with AAAA
-
-   The AAAA RR proposed in [RFC1886], while providing only a subset of
-   the functionality provided by the A6 RR proposed in [RFC2874], has
-   two main points to recommend it:
-
-   - AAAA RRs are essentially identical (other than their length) to
-     IPv4's A RRs, so we have more than 15 years of experience to help
-     us predict the usage patterns, failure scenarios and so forth
-     associated with AAAA RRs.
-
-   - The AAAA RR is "optimized for read", in the sense that, by storing
-     a complete address rather than making the resolver fetch the
-     address in pieces, it minimizes the effort involved in fetching
-     addresses from the DNS (at the expense of increasing the effort
-     involved in injecting new data into the DNS).
-
-Less Compelling Arguments in Favor of A6
-
-   Since the A6 RR allows a zone administrator to write zone files whose
-   description of addresses maps to the underlying network topology, A6
-   RRs can be construed as a "better" way of representing addresses than
-   AAAA.  This may well be a useful capability, but in and of itself
-   it's more of an argument for better tools for zone administrators to
-   use when constructing zone files than a justification for changing
-   the resolution protocol used on the wire.
-
-Less Compelling Arguments in Favor of AAAA
-
-   Some of the pressure to go with AAAA instead of A6 appears to be
-   based on the wider deployment of AAAA.  Since it is possible to
-   construct transition tools (see discussion of AAAA synthesis, later
-   in this note), this does not appear to be a compelling argument if A6
-   provides features that we really need.
-
-   Another argument in favor of AAAA RRs over A6 RRs appears to be that
-   the A6 RR's advanced capabilities increase the number of ways in
-   which a zone administrator could build a non-working configuration.
-   While operational issues are certainly important, this is more of
-   argument that we need better tools for zone administrators than it is
-   a justification for turning away from A6 if A6 provides features that
-   we really need.
-
-
-
-
-
-
-
-
-
-Austein                      Informational                      [Page 3]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-Potential Problems with A6
-
-   The enhanced capabilities of the A6 RR, while interesting, are not in
-   themselves justification for choosing A6 if we don't really need
-   those capabilities.  The A6 RR is "optimized for write", in the sense
-   that, by making it possible to store fragmented IPv6 addresses in the
-   DNS, it makes it possible to reduce the effort that it takes to
-   inject new data into the DNS (at the expense of increasing the effort
-   involved in fetching data from the DNS).  This may be justified if we
-   expect the effort involved in maintaining AAAA-style DNS entries to
-   be prohibitive, but in general, we expect the DNS data to be read
-   more frequently than it is written, so we need to evaluate this
-   particular tradeoff very carefully.
-
-   There are also several potential issues with A6 RRs that stem
-   directly from the feature that makes them different from AAAA RRs:
-   the ability to build up address via chaining.
-
-   Resolving a chain of A6 RRs involves resolving a series of what are
-   almost independent queries, but not quite.  Each of these sub-queries
-   takes some non-zero amount of time, unless the answer happens to be
-   in the resolver's local cache already.  Assuming that resolving an
-   AAAA RR takes time T as a baseline, we can guess that, on the
-   average, it will take something approaching time N*T to resolve an
-   N-link chain of A6 RRs, although we would expect to see a fairly good
-   caching factor for the A6 fragments representing the more significant
-   bits of an address.  This leaves us with two choices, neither of
-   which is very good:  we can decrease the amount of time that the
-   resolver is willing to wait for each fragment, or we can increase the
-   amount of time that a resolver is willing to wait before returning
-   failure to a client.  What little data we have on this subject
-   suggests that users are already impatient with the length of time it
-   takes to resolve A RRs in the IPv4 Internet, which suggests that they
-   are not likely to be patient with significantly longer delays in the
-   IPv6 Internet.  At the same time, terminating queries prematurely is
-   both a waste of resources and another source of user frustration.
-   Thus, we are forced to conclude that indiscriminate use of long A6
-   chains is likely to lead to problems.
-
-   To make matters worse, the places where A6 RRs are likely to be most
-   critical for rapid renumbering or GSE-like routing are situations
-   where the prefix name field in the A6 RR points to a target that is
-   not only outside the DNS zone containing the A6 RR, but is
-   administered by a different organization (for example, in the case of
-   an end user's site, the prefix name will most likely point to a name
-   belonging to an ISP that provides connectivity for the site).  While
-   pointers out of zone are not a problem per se, pointers to other
-   organizations are somewhat more difficult to maintain and less
-
-
-
-Austein                      Informational                      [Page 4]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-   susceptible to automation than pointers within a single organization
-   would be.  Experience both with glue RRs and with PTR RRs in the IN-
-   ADDR.ARPA tree suggests that many zone administrators do not really
-   understand how to set up and maintain these pointers properly, and we
-   have no particular reason to believe that these zone administrators
-   will do a better job with A6 chains than they do today.  To be fair,
-   however, the alternative case of building AAAA RRs via preprocessing
-   before loading zones has many of the same problems; at best, one can
-   claim that using AAAA RRs for this purpose would allow DNS clients to
-   get the wrong answer somewhat more efficiently than with A6 RRs.
-
-   Finally, assuming near total ignorance of how likely a query is to
-   fail, the probability of failure with an N-link A6 chain would appear
-   to be roughly proportional to N, since each of the queries involved
-   in resolving an A6 chain would have the same probability of failure
-   as a single AAAA query.  Note again that this comment applies to
-   failures in the the process of resolving a query, not to the data
-   obtained via that process.  Arguably, in an ideal world, A6 RRs would
-   increase the probability of the answer a client (finally) gets being
-   right, assuming that nothing goes wrong in the query process, but we
-   have no real idea how to quantify that assumption at this point even
-   to the hand-wavey extent used elsewhere in this note.
-
-   One potential problem that has been raised in the past regarding A6
-   RRs turns out not to be a serious issue.  The A6 design includes the
-   possibility of there being more than one A6 RR matching the prefix
-   name portion of a leaf A6 RR.  That is, an A6 chain may not be a
-   simple linked list, it may in fact be a tree, where each branch
-   represents a possible prefix.  Some critics of A6 have been concerned
-   that this will lead to a wild expansion of queries, but this turns
-   out not to be a problem if a resolver simply follows the "bounded
-   work per query" rule described in RFC 1034 (page 35).  That rule
-   applies to all work resulting from attempts to process a query,
-   regardless of whether it's a simple query, a CNAME chain, an A6 tree,
-   or an infinite loop.  The client may not get back a useful answer in
-   cases where the zone has been configured badly, but a proper
-   implementation should not produce a query explosion as a result of
-   processing even the most perverse A6 tree, chain, or loop.
-
-Interactions with DNSSEC
-
-   One of the areas where AAAA and A6 RRs differ is in the precise
-   details of how they interact with DNSSEC.  The following comments
-   apply only to non-zero-prefix A6 RRs (A6 0 RRs, once again, are
-   semantically equivalent to AAAA RRs).
-
-
-
-
-
-
-Austein                      Informational                      [Page 5]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-   Other things being equal, the time it takes to re-sign all of the
-   addresses in a zone after a renumbering event is longer with AAAA RRs
-   than with A6 RRs (because each address record has to be re-signed
-   rather than just signing a common prefix A6 RR and a few A6 0 RRs
-   associated with the zone's name servers).  Note, however, that in
-   general this does not present a serious scaling problem, because the
-   re-signing is performed in the leaf zones.
-
-   Other things being equal, there's more work involved in verifying the
-   signatures received back for A6 RRs, because each address fragment
-   has a separate associated signature.  Similarly, a DNS message
-   containing a set of A6 address fragments and their associated
-   signatures will be larger than the equivalent packet with a single
-   AAAA (or A6 0) and a single associated signature.
-
-   Since AAAA RRs cannot really represent rapid renumbering or GSE-style
-   routing scenarios very well, it should not be surprising that DNSSEC
-   signatures of AAAA RRs are also somewhat problematic.  In cases where
-   the AAAA RRs would have to be changing very quickly to keep up with
-   prefix changes, the time required to re-sign the AAAA RRs may be
-   prohibitive.
-
-   Empirical testing by Bill Sommerfeld [Sommerfeld] suggests that
-   333MHz Celeron laptop with 128KB L2 cache and 64MB RAM running the
-   BIND-9 dnssec-signzone program under NetBSD can generate roughly 40
-   1024-bit RSA signatures per second.  Extrapolating from this,
-   assuming one A RR, one AAAA RR, and one NXT RR per host, this
-   suggests that it would take this laptop a few hours to sign a zone
-   listing 10**5 hosts, or about a day to sign a zone listing 10**6
-   hosts using AAAA RRs.
-
-   This suggests that the additional effort of re-signing a large zone
-   full of AAAA RRs during a re-numbering event, while noticeable, is
-   only likely to be prohibitive in the rapid renumbering case where
-   AAAA RRs don't work well anyway.
-
-Interactions with Dynamic Update
-
-   DNS dynamic update appears to work equally well for AAAA or A6 RRs,
-   with one minor exception: with A6 RRs, the dynamic update client
-   needs to know the prefix length and prefix name.  At present, no
-   mechanism exists to inform a dynamic update client of these values,
-   but presumably such a mechanism could be provided via an extension to
-   DHCP, or some other equivalent could be devised.
-
-
-
-
-
-
-
-Austein                      Informational                      [Page 6]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-Transition from AAAA to A6 Via AAAA Synthesis
-
-   While AAAA is at present more widely deployed than A6, it is possible
-   to transition from AAAA-aware DNS software to A6-aware DNS software.
-   A rough plan for this was presented at IETF-50 in Minneapolis and has
-   been discussed on the ipng mailing list.  So if the IETF concludes
-   that A6's enhanced capabilities are necessary, it should be possible
-   to transition from AAAA to A6.
-
-   The details of this transition have been left to a separate document,
-   but the general idea is that the resolver that is performing
-   iterative resolution on behalf of a DNS client program could
-   synthesize AAAA RRs representing the result of performing the
-   equivalent A6 queries.  Note that in this case it is not possible to
-   generate an equivalent DNSSEC signature for the AAAA RR, so clients
-   that care about performing DNSSEC validation for themselves would
-   have to issue A6 queries directly rather than relying on AAAA
-   synthesis.
-
-Bitlabels
-
-   While the differences between AAAA and A6 RRs have generated most of
-   the discussion to date, there are also two proposed mechanisms for
-   building the reverse mapping tree (the IPv6 equivalent of IPv4's IN-
-   ADDR.ARPA tree).
-
-   [RFC1886] proposes a mechanism very similar to the IN-ADDR.ARPA
-   mechanism used for IPv4 addresses: the RR name is the hexadecimal
-   representation of the IPv6 address, reversed and concatenated with a
-   well-known suffix, broken up with a dot between each hexadecimal
-   digit.  The resulting DNS names are somewhat tedious for humans to
-   type, but are very easy for programs to generate.  Making each
-   hexadecimal digit a separate label means that delegation on arbitrary
-   bit boundaries will result in a maximum of 16 NS RRsets per label
-   level; again, the mechanism is somewhat tedious for humans, but is
-   very easy to program.  As with IPv4's IN-ADDR.ARPA tree, the one
-   place where this scheme is weak is in handling delegations in the
-   least significant label; however, since there appears to be no real
-   need to delegate the least significant four bits of an IPv6 address,
-   this does not appear to be a serious restriction.
-
-   [RFC2874] proposed a radically different way of naming entries in the
-   reverse mapping tree: rather than using textual representations of
-   addresses, it proposes to use a new kind of DNS label (a "bit label")
-   to represent binary addresses directly in the DNS.  This has the
-   advantage of being significantly more compact than the textual
-   representation, and arguably might have been a better solution for
-   DNS to use for this purpose if it had been designed into the protocol
-
-
-
-Austein                      Informational                      [Page 7]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-   from the outset.  Unfortunately, experience to date suggests that
-   deploying a new DNS label type is very hard: all of the DNS name
-   servers that are authoritative for any portion of the name in
-   question must be upgraded before the new label type can be used, as
-   must any resolvers involved in the resolution process.  Any name
-   server that has not been upgraded to understand the new label type
-   will reject the query as being malformed.
-
-   Since the main benefit of the bit label approach appears to be an
-   ability that we don't really need (delegation in the least
-   significant four bits of an IPv6 address), and since the upgrade
-   problem is likely to render bit labels unusable until a significant
-   portion of the DNS code base has been upgraded, it is difficult to
-   escape the conclusion that the textual solution is good enough.
-
-DNAME RRs
-
-   [RFC2874] also proposes using DNAME RRs as a way of providing the
-   equivalent of A6's fragmented addresses in the reverse mapping tree.
-   That is, by using DNAME RRs, one can write zone files for the reverse
-   mapping tree that have the same ability to cope with rapid
-   renumbering or GSE-style routing that the A6 RR offers in the main
-   portion of the DNS tree.  Consequently, the need to use DNAME in the
-   reverse mapping tree appears to be closely tied to the need to use
-   fragmented A6 in the main tree: if one is necessary, so is the other,
-   and if one isn't necessary, the other isn't either.
-
-   Other uses have also been proposed for the DNAME RR, but since they
-   are outside the scope of the IPv6 address discussion, they will not
-   be addressed here.
-
-Recommendation
-
-   Distilling the above feature comparisons down to their key elements,
-   the important questions appear to be:
-
-   (a) Is IPv6 going to do rapid renumbering or GSE-like routing?
-
-   (b) Is the reverse mapping tree for IPv6 going to require delegation
-       in the least significant four bits of the address?
-
-   Question (a) appears to be the key to the debate.  This is really a
-   decision for the IPv6 community to make, not the DNS community.
-
-   Question (b) is also for the IPv6 community to make, but it seems
-   fairly obvious that the answer is "no".
-
-
-
-
-
-Austein                      Informational                      [Page 8]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-   Recommendations based on these questions:
-
-   (1) If the IPv6 working groups seriously intend to specify and deploy
-       rapid renumbering or GSE-like routing, we should transition to
-       using the A6 RR in the main tree and to using DNAME RRs as
-       necessary in the reverse tree.
-
-   (2) Otherwise, we should keep the simpler AAAA solution in the main
-       tree and should not use DNAME RRs in the reverse tree.
-
-   (3) In either case, the reverse tree should use the textual
-       representation described in [RFC1886] rather than the bit label
-       representation described in [RFC2874].
-
-   (4) If we do go to using A6 RRs in the main tree and to using DNAME
-       RRs in the reverse tree, we should write applicability statements
-       and implementation guidelines designed to discourage excessively
-       complex uses of these features; in general, any network that can
-       be described adequately using A6 0 RRs and without using DNAME
-       RRs should be described that way, and the enhanced features
-       should be used only when absolutely necessary, at least until we
-       have much more experience with them and have a better
-       understanding of their failure modes.
-
-Security Considerations
-
-   This note compares two mechanisms with similar security
-   characteristics, but there are a few security implications to the
-   choice between these two mechanisms:
-
-   (1) The two mechanisms have similar but not identical interactions
-       with DNSSEC.  Please see the section entitled "Interactions with
-       DNSSEC" (above) for a discussion of these issues.
-
-   (2) To the extent that operational complexity is the enemy of
-       security, the tradeoffs in operational complexity discussed
-       throughout this note have an impact on security.
-
-   (3) To the extent that protocol complexity is the enemy of security,
-       the additional protocol complexity of [RFC2874] as compared to
-       [RFC1886] has some impact on security.
-
-IANA Considerations
-
-   None, since all of these RR types have already been allocated.
-
-
-
-
-
-
-Austein                      Informational                      [Page 9]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-Acknowledgments
-
-   This note is based on a number of discussions both public and private
-   over a period of (at least) eight years, but particular thanks go to
-   Alain Durand, Bill Sommerfeld, Christian Huitema, Jun-ichiro itojun
-   Hagino, Mark Andrews, Matt Crawford, Olafur Gudmundsson, Randy Bush,
-   and Sue Thomson, none of whom are responsible for what the author did
-   with their ideas.
-
-References
-
-   [RFC1886]    Thomson, S. and C. Huitema, "DNS Extensions to support
-                IP version 6", RFC 1886, December 1995.
-
-   [RFC2874]    Crawford, M. and C. Huitema, "DNS Extensions to Support
-                IPv6 Address Aggregation and Renumbering", RFC 2874,
-                July 2000.
-
-   [Sommerfeld] Private message to the author from Bill Sommerfeld dated
-                21 March 2001, summarizing the result of experiments he
-                performed on a copy of the MIT.EDU zone.
-
-   [GSE]       "GSE" was an evolution of the so-called "8+8" proposal
-                discussed by the IPng working group in 1996 and 1997.
-                The GSE proposal itself was written up as an Internet-
-                Draft, which has long since expired.  Readers interested
-                in the details and history of GSE should review the IPng
-                working group's mailing list archives and minutes from
-                that period.
-
-Author's Address
-
-   Rob Austein
-
-   EMail: sra@hactrn.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                      Informational                     [Page 10]
-
-RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein                      Informational                     [Page 11]
-
diff --git a/contrib/bind9/doc/rfc/rfc3425.txt b/contrib/bind9/doc/rfc/rfc3425.txt
deleted file mode 100644
index 707cafd..0000000
--- a/contrib/bind9/doc/rfc/rfc3425.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        D. Lawrence
-Request for Comments: 3425                                       Nominum
-Updates: 1035                                              November 2002
-Category: Standards Track
-
-
-                           Obsoleting IQUERY
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-Abstract
-
-   The IQUERY method of performing inverse DNS lookups, specified in RFC
-   1035, has not been generally implemented and has usually been
-   operationally disabled where it has been implemented.  Both reflect a
-   general view in the community that the concept was unwise and that
-   the widely-used alternate approach of using pointer (PTR) queries and
-   reverse-mapping records is preferable.  Consequently, this document
-   deprecates the IQUERY operation, declaring it entirely obsolete.
-   This document updates RFC 1035.
-
-1 - Introduction
-
-   As specified in RFC 1035 (section 6.4), the IQUERY operation for DNS
-   queries is used to look up the name(s) which are associated with the
-   given value.  The value being sought is provided in the query's
-   answer section and the response fills in the question section with
-   one or more 3-tuples of type, name and class.
-
-   As noted in [RFC1035], section 6.4.3, inverse query processing can
-   put quite an arduous burden on a server.  A server would need to
-   perform either an exhaustive search of its database or maintain a
-   separate database that is keyed by the values of the primary
-   database.  Both of these approaches could strain system resource use,
-   particularly for servers that are authoritative for millions of
-   names.
-
-
-
-
-
-Lawrence                    Standards Track                     [Page 1]
-
-RFC 3425                   Obsoleting IQUERY               November 2002
-
-
-   Response packets from these megaservers could be exceptionally large,
-   and easily run into megabyte sizes.  For example, using IQUERY to
-   find every domain that is delegated to one of the nameservers of a
-   large ISP could return tens of thousands of 3-tuples in the question
-   section.  This could easily be used to launch denial of service
-   attacks.
-
-   Operators of servers that do support IQUERY in some form (such as
-   very old BIND 4 servers) generally opt to disable it.  This is
-   largely due to bugs in insufficiently-exercised code, or concerns
-   about exposure of large blocks of names in their zones by probes such
-   as inverse MX queries.
-
-   IQUERY is also somewhat inherently crippled by being unable to tell a
-   requester where it needs to go to get the information that was
-   requested.  The answer is very specific to the single server that was
-   queried.  This is sometimes a handy diagnostic tool, but apparently
-   not enough so that server operators like to enable it, or request
-   implementation where it is lacking.
-
-   No known clients use IQUERY to provide any meaningful service.  The
-   only common reverse mapping support on the Internet, mapping address
-   records to names, is provided through the use of pointer (PTR)
-   records in the in-addr.arpa tree and has served the community well
-   for many years.
-
-   Based on all of these factors, this document recommends that the
-   IQUERY operation for DNS servers be officially obsoleted.
-
-2 - Requirements
-
-   The key word "SHOULD" in this document is to be interpreted as
-   described in BCP 14, RFC 2119, namely that there may exist valid
-   reasons to ignore a particular item, but the full implications must
-   be understood and carefully weighed before choosing a different
-   course.
-
-3 - Effect on RFC 1035
-
-   The effect of this document is to change the definition of opcode 1
-   from that originally defined in section 4.1.1 of RFC 1035, and to
-   entirely supersede section 6.4 (including subsections) of RFC 1035.
-
-   The definition of opcode 1 is hereby changed to:
-
-      "1               an inverse query (IQUERY) (obsolete)"
-
-
-
-
-
-Lawrence                    Standards Track                     [Page 2]
-
-RFC 3425                   Obsoleting IQUERY               November 2002
-
-
-   The text in section 6.4 of RFC 1035 is now considered obsolete.  The
-   following is an applicability statement regarding the IQUERY opcode:
-
-   Inverse queries using the IQUERY opcode were originally described as
-   the ability to look up the names that are associated with a
-   particular Resource Record (RR).  Their implementation was optional
-   and never achieved widespread use.  Therefore IQUERY is now obsolete,
-   and name servers SHOULD return a "Not Implemented" error when an
-   IQUERY request is received.
-
-4 - Security Considerations
-
-   Since this document obsoletes an operation that was once available,
-   it is conceivable that someone was using it as the basis of a
-   security policy.  However, since the most logical course for such a
-   policy to take in the face of a lack of positive response from a
-   server is to deny authentication/authorization, it is highly unlikely
-   that removing support for IQUERY will open any new security holes.
-
-   Note that if IQUERY is not obsoleted, securing the responses with DNS
-   Security (DNSSEC) is extremely difficult without out-on-the-fly
-   digital signing.
-
-5 - IANA Considerations
-
-   The IQUERY opcode of 1 should be permanently retired, not to be
-   assigned to any future opcode.
-
-6 - Acknowledgments
-
-   Olafur Gudmundsson instigated this action.  Matt Crawford, John
-   Klensin, Erik Nordmark and Keith Moore contributed some improved
-   wording in how to handle obsoleting functionality described by an
-   Internet Standard.
-
-7 - References
-
-   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
-              Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
-              3", BCP 9, RFC 2026, October 1996.
-
-   [RFC2119]  Bradner, S., "Key Words for Use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-
-
-Lawrence                    Standards Track                     [Page 3]
-
-RFC 3425                   Obsoleting IQUERY               November 2002
-
-
-8 - Author's Address
-
-   David C Lawrence
-   Nominum, Inc.
-   2385 Bay Rd
-   Redwood City CA 94063
-   USA
-
-   Phone: +1.650.779.6042
-   EMail: tale@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lawrence                    Standards Track                     [Page 4]
-
-RFC 3425                   Obsoleting IQUERY               November 2002
-
-
-9 - Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Lawrence                    Standards Track                     [Page 5]
-
diff --git a/contrib/bind9/doc/rfc/rfc3445.txt b/contrib/bind9/doc/rfc/rfc3445.txt
deleted file mode 100644
index 67f9b2d..0000000
--- a/contrib/bind9/doc/rfc/rfc3445.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          D. Massey
-Request for Comments: 3445                                       USC/ISI
-Updates: 2535                                                    S. Rose
-Category: Standards Track                                           NIST
-                                                           December 2002
-
-
-           Limiting the Scope of the KEY Resource Record (RR)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-Abstract
-
-   This document limits the Domain Name System (DNS) KEY Resource Record
-   (RR) to only keys used by the Domain Name System Security Extensions
-   (DNSSEC).  The original KEY RR used sub-typing to store both DNSSEC
-   keys and arbitrary application keys.  Storing both DNSSEC and
-   application keys with the same record type is a mistake.  This
-   document removes application keys from the KEY record by redefining
-   the Protocol Octet field in the KEY RR Data.  As a result of removing
-   application keys, all but one of the flags in the KEY record become
-   unnecessary and are redefined.  Three existing application key sub-
-   types are changed to reserved, but the format of the KEY record is
-   not changed.  This document updates RFC 2535.
-
-1. Introduction
-
-   This document limits the scope of the KEY Resource Record (RR).  The
-   KEY RR was defined in [3] and used resource record sub-typing to hold
-   arbitrary public keys such as Email, IPSEC, DNSSEC, and TLS keys.
-   This document eliminates the existing Email, IPSEC, and TLS sub-types
-   and prohibits the introduction of new sub-types.  DNSSEC will be the
-   only allowable sub-type for the KEY RR (hence sub-typing is
-   essentially eliminated) and all but one of the KEY RR flags are also
-   eliminated.
-
-
-
-
-
-
-Massey & Rose               Standards Track                     [Page 1]
-
-RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
-
-
-   Section 2 presents the motivation for restricting the KEY record and
-   Section 3 defines the revised KEY RR.  Sections 4 and 5 summarize the
-   changes from RFC 2535 and discuss backwards compatibility.  It is
-   important to note that this document restricts the use of the KEY RR
-   and simplifies the flags, but does not change the definition or use
-   of DNSSEC keys.
-
-   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 [1].
-
-2. Motivation for Restricting the KEY RR
-
-   The KEY RR RDATA [3] consists of Flags, a Protocol Octet, an
-   Algorithm type, and a Public Key.  The Protocol Octet identifies the
-   KEY RR sub-type.  DNSSEC public keys are stored in the KEY RR using a
-   Protocol Octet value of 3.  Email, IPSEC, and TLS keys were also
-   stored in the KEY RR and used Protocol Octet values of 1,2, and 4
-   (respectively).  Protocol Octet values 5-254 were available for
-   assignment by IANA and values were requested (but not assigned) for
-   applications such as SSH.
-
-   Any use of sub-typing has inherent limitations.  A resolver can not
-   specify the desired sub-type in a DNS query and most DNS operations
-   apply only to resource records sets.  For example, a resolver can not
-   directly request the DNSSEC subtype KEY RRs.  Instead, the resolver
-   has to request all KEY RRs associated with a DNS name and then search
-   the set for the desired DNSSEC sub-type.  DNSSEC signatures also
-   apply to the set of all KEY RRs associated with the DNS name,
-   regardless of sub-type.
-
-   In the case of the KEY RR, the inherent sub-type limitations are
-   exacerbated since the sub-type is used to distinguish between DNSSEC
-   keys and application keys.  DNSSEC keys and application keys differ
-   in virtually every respect and Section 2.1 discusses these
-   differences in more detail.  Combining these very different types of
-   keys into a single sub-typed resource record adds unnecessary
-   complexity and increases the potential for implementation and
-   deployment errors.  Limited experimental deployment has shown that
-   application keys stored in KEY RRs are problematic.
-
-   This document addresses these issues by removing all application keys
-   from the KEY RR.  Note that the scope of this document is strictly
-   limited to the KEY RR and this document does not endorse or restrict
-   the storage of application keys in other, yet undefined, resource
-   records.
-
-
-
-
-
-Massey & Rose               Standards Track                     [Page 2]
-
-RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
-
-
-2.1 Differences Between DNSSEC and Application Keys
-
-   DNSSEC keys are an essential part of the DNSSEC protocol and are used
-   by both name servers and resolvers in order to perform DNS tasks.  A
-   DNS zone key, used to sign and authenticate RR sets, is the most
-   common example of a DNSSEC key.  SIG(0) [4] and TKEY [3]  also use
-   DNSSEC keys.
-
-   Application keys such as Email keys, IPSEC keys, and TLS keys are
-   simply another type of data.  These keys have no special meaning to a
-   name server or resolver.
-
-   The following table summarizes some of the differences between DNSSEC
-   keys and application keys:
-
-      1.  They serve different purposes.
-
-      2.  They are managed by different administrators.
-
-      3.  They are authenticated according to different rules.
-
-      4.  Nameservers use different rules when including them in
-          responses.
-
-      5.  Resolvers process them in different ways.
-
-      6.  Faults/key compromises have different consequences.
-
-   1.  The purpose of a DNSSEC key is to sign resource records
-   associated with a DNS zone (or generate DNS transaction signatures in
-   the case of SIG(0)/TKEY).  But the purpose of an application key is
-   specific to the application.  Application keys, such as PGP/email,
-   IPSEC, TLS, and SSH keys, are not a mandatory part of any zone and
-   the purpose and proper use of application keys is outside the scope
-   of DNS.
-
-   2.  DNSSEC keys are managed by DNS administrators, but application
-   keys are managed by application administrators.  The DNS zone
-   administrator determines the key lifetime, handles any suspected key
-   compromises, and manages any DNSSEC key changes.  Likewise, the
-   application administrator is responsible for the same functions for
-   the application keys related to the application.  For example, a user
-   typically manages her own PGP key and a server manages its own TLS
-   key.  Application key management tasks are outside the scope of DNS
-   administration.
-
-
-
-
-
-
-Massey & Rose               Standards Track                     [Page 3]
-
-RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
-
-
-   3.  DNSSEC zone keys are used to authenticate application keys, but
-   by definition, application keys are not allowed to authenticate DNS
-   zone keys.  A DNS zone key is either configured as a trusted key or
-   authenticated by constructing a chain of trust in the DNS hierarchy.
-   To participate in the chain of trust, a DNS zone needs to exchange
-   zone key information with its parent zone [3].  Application keys are
-   not configured as trusted keys in the DNS and are never part of any
-   DNS chain of trust.  Application key data is not needed by the parent
-   and does not need to be exchanged with the parent zone for secure DNS
-   resolution to work.  A resolver considers an application key RRset as
-   authenticated DNS information if it has a valid signature from the
-   local DNS zone keys, but applications could impose additional
-   security requirements before the application key is accepted as
-   authentic for use with the application.
-
-   4.  It may be useful for nameservers to include DNS zone keys in the
-   additional section of a response, but application keys are typically
-   not useful unless they have been specifically requested.  For
-   example, it could be useful to include the example.com zone key along
-   with a response that contains the www.example.com A record and SIG
-   record.  A secure resolver will need the example.com zone key in
-   order to check the SIG and authenticate the www.example.com A record.
-   It is typically not useful to include the IPSEC, email, and TLS keys
-   along with the A record.  Note that by placing application keys in
-   the KEY record, a resolver would need the IPSEC, email, TLS, and
-   other key associated with example.com if the resolver intends to
-   authenticate the example.com zone key (since signatures only apply to
-   the entire KEY RR set).  Depending on the number of protocols
-   involved, the KEY RR set could grow unwieldy for resolvers, and DNS
-   administrators to manage.
-
-   5.  DNS zone keys require special handling by resolvers, but
-   application keys are treated the same as any other type of DNS data.
-   The DNSSEC keys are of no value to end applications, unless the
-   applications plan to do their own DNS authentication.  By definition,
-   secure resolvers are not allowed to use application keys as part of
-   the authentication process.  Application keys have no unique meaning
-   to resolvers and are only useful to the application requesting the
-   key.  Note that if sub-types are used to identify the application
-   key, then either the interface to the resolver needs to specify the
-   sub-type or the application needs to be able to accept all KEY RRs
-   and pick out the desired sub-type.
-
-   6.  A fault or compromise of a DNS zone key can lead to invalid or
-   forged DNS data, but a fault or compromise of an application key
-   should have no impact on other DNS data.  Incorrectly adding or
-   changing a DNS zone key can invalidate all of the DNS data in the
-   zone and in all of its subzones.  By using a compromised key, an
-
-
-
-Massey & Rose               Standards Track                     [Page 4]
-
-RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
-
-
-   attacker can forge data from the effected zone and for any of its
-   sub-zones.  A fault or compromise of an application key has
-   implications for that application, but it should not have an impact
-   on the DNS.  Note that application key faults and key compromises can
-   have an impact on the entire DNS if the application key and DNS zone
-   keys are both stored in the KEY RR.
-
-   In summary, DNSSEC keys and application keys differ in most every
-   respect.  DNSSEC keys are an essential part of the DNS infrastructure
-   and require special handling by DNS administrators and DNS resolvers.
-   Application keys are simply another type of data and have no special
-   meaning to DNS administrators or resolvers.  These two different
-   types of data do not belong in the same resource record.
-
-3. Definition of the KEY RR
-
-   The KEY RR uses type 25 and is used as resource record for storing
-   DNSSEC keys.  The RDATA for a KEY RR consists of flags, a protocol
-   octet, the algorithm number octet, and the public key itself.  The
-   format is as follows:
-
-   ---------------------------------------------------------------------
-
-
-                        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                             /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-                             KEY RR Format
-
-   ---------------------------------------------------------------------
-
-   In the flags field, all bits except bit 7 are reserved and MUST be
-   zero.  If Bit 7 (Zone bit) is set to 1, then the KEY is a DNS Zone
-   key.  If Bit 7 is set to 0, the KEY is not a zone key.  SIG(0)/TKEY
-   are examples of DNSSEC keys that are not zone keys.
-
-   The protocol field MUST be set to 3.
-
-   The algorithm and public key fields are not changed.
-
-
-
-
-
-Massey & Rose               Standards Track                     [Page 5]
-
-RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
-
-
-4. Changes from RFC 2535 KEY RR
-
-   The KEY RDATA format is not changed.
-
-   All flags except for the zone key flag are eliminated:
-
-      The A/C bits (bits 0 and 1) are eliminated.  They MUST be set to 0
-      and MUST be ignored by the receiver.
-
-      The extended flags bit (bit 3) is eliminated.  It MUST be set to 0
-      and MUST be ignored by the receiver.
-
-      The host/user bit (bit 6) is eliminated.  It MUST be set to 0 and
-      MUST be ignored by the receiver.
-
-      The zone bit (bit 7) remains unchanged.
-
-      The signatory field (bits 12-15) are eliminated by [5].  They MUST
-      be set to 0 and MUST be ignored by the receiver.
-
-      Bits 2,4,5,8,9,10,11 remain unchanged.  They are reserved, MUST be
-      set to zero and MUST be ignored by the receiver.
-
-   Assignment of any future KEY RR Flag values requires a standards
-   action.
-
-   All Protocol Octet values except DNSSEC (3) are eliminated:
-
-      Value 1 (Email) is renamed to RESERVED.
-
-      Value 2 (IPSEC) is renamed to RESERVED.
-
-      Value 3 (DNSSEC) is unchanged.
-
-      Value 4 (TLS) is renamed to RESERVED.
-
-      Value 5-254 remains unchanged (reserved).
-
-      Value 255 (ANY) is renamed to RESERVED.
-
-   The authoritative data for a zone MUST NOT include any KEY records
-   with a protocol octet other than 3.  The registry maintained by IANA
-   for protocol values is closed for new assignments.
-
-   Name servers and resolvers SHOULD accept KEY RR sets that contain KEY
-   RRs with a value other than 3.  If out of date DNS zones contain
-   deprecated KEY RRs with a protocol octet value other than 3, then
-   simply dropping the deprecated KEY RRs from the KEY RR set would
-
-
-
-Massey & Rose               Standards Track                     [Page 6]
-
-RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
-
-
-   invalidate any associated SIG record(s) and could create caching
-   consistency problems.  Note that KEY RRs with a protocol octet value
-   other than 3 MUST NOT be used to authenticate DNS data.
-
-   The algorithm and public key fields are not changed.
-
-5. Backward Compatibility
-
-   DNSSEC zone KEY RRs are not changed and remain backwards compatible.
-   A properly formatted RFC 2535 zone KEY would have all flag bits,
-   other than the Zone Bit (Bit 7), set to 0 and would have the Protocol
-   Octet set to 3.  This remains true under the restricted KEY.
-
-   DNSSEC non-zone KEY RRs (SIG(0)/TKEY keys) are backwards compatible,
-   but the distinction between host and user keys (flag bit 6) is lost.
-
-   No backwards compatibility is provided for application keys.  Any
-   Email, IPSEC, or TLS keys are now deprecated.  Storing application
-   keys in the KEY RR created problems such as keys at the apex and
-   large RR sets and some change in the definition and/or usage of the
-   KEY RR would have been required even if the approach described here
-   were not adopted.
-
-   Overall, existing nameservers and resolvers will continue to
-   correctly process KEY RRs with a sub-type of DNSSEC keys.
-
-6. Storing Application Keys in the DNS
-
-   The scope of this document is strictly limited to the KEY record.
-   This document prohibits storing application keys in the KEY record,
-   but it does not endorse or restrict the storing application keys in
-   other record types.  Other documents can describe how DNS handles
-   application keys.
-
-7. IANA Considerations
-
-   RFC 2535 created an IANA registry for DNS KEY RR Protocol Octet
-   values.  Values 1, 2, 3, 4, and 255 were assigned by RFC 2535 and
-   values 5-254 were made available for assignment by IANA.  This
-   document makes two sets of changes to this registry.
-
-   First, this document re-assigns DNS KEY RR Protocol Octet values 1,
-   2, 4, and 255 to "reserved".  DNS Key RR Protocol Octet Value 3
-   remains unchanged as "DNSSEC".
-
-
-
-
-
-
-
-Massey & Rose               Standards Track                     [Page 7]
-
-RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
-
-
-   Second, new values are no longer available for assignment by IANA and
-   this document closes the IANA registry for DNS KEY RR Protocol Octet
-   Values.  Assignment of any future KEY RR Protocol Octet values
-   requires a standards action.
-
-8. Security Considerations
-
-   This document eliminates potential security problems that could arise
-   due to the coupling of DNS zone keys and application keys.  Prior to
-   the change described in this document, a correctly authenticated KEY
-   set could include both application keys and DNSSEC keys.  This
-   document restricts the KEY RR to DNS security usage only.  This is an
-   attempt to simplify the security model and make it less user-error
-   prone.  If one of the application keys is compromised, it could be
-   used as a false zone key to create false DNS signatures (SIG
-   records).  Resolvers that do not carefully check the KEY sub-type
-   could believe these false signatures and incorrectly authenticate DNS
-   data.  With this change, application keys cannot appear in an
-   authenticated KEY set and this vulnerability is eliminated.
-
-   The format and correct usage of DNSSEC keys is not changed by this
-   document and no new security considerations are introduced.
-
-9. Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Eastlake, D., "Domain Name System Security Extensions", RFC
-        2535, March 1999.
-
-   [3]  Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
-        2930, September 2000.
-
-   [4]  Eastlake, D., "DNS Request and Transaction Signatures
-        (SIG(0)s)", RFC 2931, September 2000.
-
-   [5]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
-        Update", RFC 3007, November 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-Massey & Rose               Standards Track                     [Page 8]
-
-RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
-
-
-10. Authors' Addresses
-
-   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-3460
-   USA
-
-   EMail: scott.rose@nist.gov
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Massey & Rose               Standards Track                     [Page 9]
-
-RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
-
-
-11.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Massey & Rose               Standards Track                    [Page 10]
-
diff --git a/contrib/bind9/doc/rfc/rfc3467.txt b/contrib/bind9/doc/rfc/rfc3467.txt
deleted file mode 100644
index 37ac7ec..0000000
--- a/contrib/bind9/doc/rfc/rfc3467.txt
+++ /dev/null
@@ -1,1739 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         J. Klensin
-Request for Comments: 3467                                 February 2003
-Category: Informational
-
-
-                  Role of the Domain Name System (DNS)
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   This document reviews the original function and purpose of the domain
-   name system (DNS).  It contrasts that history with some of the
-   purposes for which the DNS has recently been applied and some of the
-   newer demands being placed upon it or suggested for it.  A framework
-   for an alternative to placing these additional stresses on the DNS is
-   then outlined.  This document and that framework are not a proposed
-   solution, only a strong suggestion that the time has come to begin
-   thinking more broadly about the problems we are encountering and
-   possible approaches to solving them.
-
-Table of Contents
-
-   1.  Introduction and History .....................................  2
-      1.1 Context for DNS Development ...............................  3
-      1.2 Review of the DNS and Its Role as Designed ................  4
-      1.3 The Web and User-visible Domain Names .....................  6
-      1.4 Internet Applications Protocols and Their Evolution .......  7
-   2.  Signs of DNS Overloading .....................................  8
-   3.  Searching, Directories, and the DNS .......................... 12
-      3.1 Overview  ................................................. 12
-      3.2 Some Details and Comments ................................. 14
-   4.  Internationalization ......................................... 15
-      4.1 ASCII Isn't Just Because of English ....................... 16
-      4.2 The "ASCII Encoding" Approaches ........................... 17
-      4.3 "Stringprep" and Its Complexities ......................... 17
-      4.4 The Unicode Stability Problem ............................. 19
-      4.5 Audiences, End Users, and the User Interface Problem ...... 20
-      4.6 Business Cards and Other Natural Uses of Natural Languages. 22
-      4.7 ASCII Encodings and the Roman Keyboard Assumption ......... 22
-
-
-
-Klensin                      Informational                      [Page 1]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-      4.8 Intra-DNS Approaches for "Multilingual Names" ............. 23
-   5.  Search-based Systems: The Key Controversies .................. 23
-   6.  Security Considerations ...................................... 24
-   7.  References ................................................... 25
-      7.1 Normative References ...................................... 25
-      7.2 Explanatory and Informative References .................... 25
-   8.  Acknowledgements ............................................. 30
-   9.  Author's Address ............................................. 30
-   10. Full Copyright Statement ..................................... 31
-
-1. Introduction and History
-
-   The DNS was designed as a replacement for the older "host table"
-   system.  Both were intended to provide names for network resources at
-   a more abstract level than network (IP) addresses (see, e.g.,
-   [RFC625], [RFC811], [RFC819], [RFC830], [RFC882]).  In recent years,
-   the DNS has become a database of convenience for the Internet, with
-   many proposals to add new features.  Only some of these proposals
-   have been successful.  Often the main (or only) motivation for using
-   the DNS is because it exists and is widely deployed, not because its
-   existing structure, facilities, and content are appropriate for the
-   particular application of data involved.  This document reviews the
-   history of the DNS, including examination of some of those newer
-   applications.  It then argues that the overloading process is often
-   inappropriate.  Instead, it suggests that the DNS should be
-   supplemented by systems better matched to the intended applications
-   and outlines a framework and rationale for one such system.
-
-   Several of the comments that follow are somewhat revisionist.  Good
-   design and engineering often requires a level of intuition by the
-   designers about things that will be necessary in the future; the
-   reasons for some of these design decisions are not made explicit at
-   the time because no one is able to articulate them.  The discussion
-   below reconstructs some of the decisions about the Internet's primary
-   namespace (the "Class=IN" DNS) in the light of subsequent development
-   and experience.  In addition, the historical reasons for particular
-   decisions about the Internet were often severely underdocumented
-   contemporaneously and, not surprisingly, different participants have
-   different recollections about what happened and what was considered
-   important.  Consequently, the quasi-historical story below is just
-   one story.  There may be (indeed, almost certainly are) other stories
-   about how the DNS evolved to its present state, but those variants do
-   not invalidate the inferences and conclusions.
-
-   This document presumes a general understanding of the terminology of
-   RFC 1034 [RFC1034] or of any good DNS tutorial (see, e.g., [Albitz]).
-
-
-
-
-
-Klensin                      Informational                      [Page 2]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-1.1  Context for DNS Development
-
-   During the entire post-startup-period life of the ARPANET and nearly
-   the first decade or so of operation of the Internet, the list of host
-   names and their mapping to and from addresses was maintained in a
-   frequently-updated "host table" [RFC625], [RFC811], [RFC952].  The
-   names themselves were restricted to a subset of ASCII [ASCII] chosen
-   to avoid ambiguities in printed form, to permit interoperation with
-   systems using other character codings (notably EBCDIC), and to avoid
-   the "national use" code positions of ISO 646 [IS646].  These
-   restrictions later became collectively known as the "LDH" rules for
-   "letter-digit-hyphen", the permitted characters.  The table was just
-   a list with a common format that was eventually agreed upon; sites
-   were expected to frequently obtain copies of, and install, new
-   versions.  The host tables themselves were introduced to:
-
-   o  Eliminate the requirement for people to remember host numbers
-      (addresses).  Despite apparent experience to the contrary in the
-      conventional telephone system, numeric numbering systems,
-      including the numeric host number strategy, did not (and do not)
-      work well for more than a (large) handful of hosts.
-
-   o  Provide stability when addresses changed.  Since addresses -- to
-      some degree in the ARPANET and more importantly in the
-      contemporary Internet -- are a function of network topology and
-      routing, they often had to be changed when connectivity or
-      topology changed.  The names could be kept stable even as
-      addresses changed.
-
-   o  Provide the capability to have multiple addresses associated with
-      a given host to reflect different types of connectivity and
-      topology.  Use of names, rather than explicit addresses, avoided
-      the requirement that would otherwise exist for users and other
-      hosts to track these multiple host numbers and addresses and the
-      topological considerations for selecting one over others.
-
-   After several years of using the host table approach, the community
-   concluded that model did not scale adequately and that it would not
-   adequately support new service variations.  A number of discussions
-   and meetings were held which drew several ideas and incomplete
-   proposals together.  The DNS was the result of that effort.  It
-   continued to evolve during the design and initial implementation
-   period, with a number of documents recording the changes (see
-   [RFC819], [RFC830], and [RFC1034]).
-
-
-
-
-
-
-
-Klensin                      Informational                      [Page 3]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   The goals for the DNS included:
-
-   o  Preservation of the capabilities of the host table arrangements
-      (especially unique, unambiguous, host names),
-
-   o  Provision for addition of additional services (e.g., the special
-      record types for electronic mail routing which quickly followed
-      introduction of the DNS), and
-
-   o  Creation of a robust, hierarchical, distributed, name lookup
-      system to accomplish the other goals.
-
-   The DNS design also permitted distribution of name administration,
-   rather than requiring that each host be entered into a single,
-   central, table by a central administration.
-
-1.2 Review of the DNS and Its Role as Designed
-
-   The DNS was designed to identify network resources.  Although there
-   was speculation about including, e.g., personal names and email
-   addresses, it was not designed primarily to identify people, brands,
-   etc.  At the same time, the system was designed with the flexibility
-   to accommodate new data types and structures, both through the
-   addition of new record types to the initial "INternet" class, and,
-   potentially, through the introduction of new classes.  Since the
-   appropriate identifiers and content of those future extensions could
-   not be anticipated, the design provided that these fields could
-   contain any (binary) information, not just the restricted text forms
-   of the host table.
-
-   However, the DNS, as it is actually used, is intimately tied to the
-   applications and application protocols that utilize it, often at a
-   fairly low level.
-
-   In particular, despite the ability of the protocols and data
-   structures themselves to accommodate any binary representation, DNS
-   names as used were historically not even unrestricted ASCII, but a
-   very restricted subset of it, a subset that derives from the original
-   host table naming rules.  Selection of that subset was driven in part
-   by human factors considerations, including a desire to eliminate
-   possible ambiguities in an international context.  Hence character
-   codes that had international variations in interpretation were
-   excluded, the underscore character and case distinctions were
-   eliminated as being confusing (in the underscore's case, with the
-   hyphen character) when written or read by people, and so on.  These
-   considerations appear to be very similar to those that resulted in
-   similarly restricted character sets being used as protocol elements
-   in many ITU and ISO protocols (cf. [X29]).
-
-
-
-Klensin                      Informational                      [Page 4]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   Another assumption was that there would be a high ratio of physical
-   hosts to second level domains and, more generally, that the system
-   would be deeply hierarchical, with most systems (and names) at the
-   third level or below and a very large percentage of the total names
-   representing physical hosts.  There are domains that follow this
-   model: many university and corporate domains use fairly deep
-   hierarchies, as do a few country-oriented top level domains
-   ("ccTLDs").  Historically, the "US." domain has been an excellent
-   example of the deeply hierarchical approach.  However, by 1998,
-   comparison of several efforts to survey the DNS showed a count of SOA
-   records that approached (and may have passed) the number of distinct
-   hosts.  Looked at differently, we appear to be moving toward a
-   situation in which the number of delegated domains on the Internet is
-   approaching or exceeding the number of hosts, or at least the number
-   of hosts able to provide services to others on the network.  This
-   presumably results from synonyms or aliases that map a great many
-   names onto a smaller number of hosts.  While experience up to this
-   time has shown that the DNS is robust enough -- given contemporary
-   machines as servers and current bandwidth norms -- to be able to
-   continue to operate reasonably well when those historical assumptions
-   are not met (e.g., with a flat, structure under ".COM" containing
-   well over ten million delegated subdomains [COMSIZE]), it is still
-   useful to remember that the system could have been designed to work
-   optimally with a flat structure (and very large zones) rather than a
-   deeply hierarchical one, and was not.
-
-   Similarly, despite some early speculation about entering people's
-   names and email addresses into the DNS directly (e.g., see
-   [RFC1034]), electronic mail addresses in the Internet have preserved
-   the original, pre-DNS, "user (or mailbox) at location" conceptual
-   format rather than a flatter or strictly dot-separated one.
-   Location, in that instance, is a reference to a host. The sole
-   exception, at least in the "IN" class, has been one field of the SOA
-   record.
-
-   Both the DNS architecture itself and the two-level (host name and
-   mailbox name) provisions for email and similar functions (e.g., see
-   the finger protocol [FINGER]), also anticipated a relatively high
-   ratio of users to actual hosts.  Despite the observation in RFC 1034
-   that the DNS was expected to grow to be proportional to the number of
-   users (section 2.3), it has never been clear that the DNS was
-   seriously designed for, or could, scale to the order of magnitude of
-   number of users (or, more recently, products or document objects),
-   rather than that of physical hosts.
-
-   Just as was the case for the host table before it, the DNS provided
-   critical uniqueness for names, and universal accessibility to them,
-   as part of overall "single internet" and "end to end" models (cf.
-
-
-
-Klensin                      Informational                      [Page 5]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   [RFC2826]).  However, there are many signs that, as new uses evolved
-   and original assumptions were abused (if not violated outright), the
-   system was being stretched to, or beyond, its practical limits.
-
-   The original design effort that led to the DNS included examination
-   of the directory technologies available at the time.  The design
-   group concluded that the DNS design, with its simplifying assumptions
-   and restricted capabilities, would be feasible to deploy and make
-   adequately robust, which the more comprehensive directory approaches
-   were not.  At the same time, some of the participants feared that the
-   limitations might cause future problems; this document essentially
-   takes the position that they were probably correct.  On the other
-   hand, directory technology and implementations have evolved
-   significantly in the ensuing years: it may be time to revisit the
-   assumptions, either in the context of the two- (or more) level
-   mechanism contemplated by the rest of this document or, even more
-   radically, as a path toward a DNS replacement.
-
-1.3 The Web and User-visible Domain Names
-
-   From the standpoint of the integrity of the domain name system -- and
-   scaling of the Internet, including optimal accessibility to content
-   -- the web design decision to use "A record" domain names directly in
-   URLs, rather than some system of indirection, has proven to be a
-   serious mistake in several respects.  Convenience of typing, and the
-   desire to make domain names out of easily-remembered product names,
-   has led to a flattening of the DNS, with many people now perceiving
-   that second-level names under COM (or in some countries, second- or
-   third-level names under the relevant ccTLD) are all that is
-   meaningful.  This perception has been reinforced by some domain name
-   registrars [REGISTRAR] who have been anxious to "sell" additional
-   names.  And, of course, the perception that one needed a second-level
-   (or even top-level) domain per product, rather than having names
-   associated with a (usually organizational) collection of network
-   resources, has led to a rapid acceleration in the number of names
-   being registered.  That acceleration has, in turn, clearly benefited
-   registrars charging on a per-name basis, "cybersquatters", and others
-   in the business of "selling" names, but it has not obviously
-   benefited the Internet as a whole.
-
-   This emphasis on second-level domain names has also created a problem
-   for the trademark community.  Since the Internet is international,
-   and names are being populated in a flat and unqualified space,
-   similarly-named entities are in conflict even if there would
-   ordinarily be no chance of confusing them in the marketplace.  The
-   problem appears to be unsolvable except by a choice between draconian
-   measures.  These might include significant changes to the legislation
-   and conventions that govern disputes over "names" and "marks".  Or
-
-
-
-Klensin                      Informational                      [Page 6]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   they might result in a situation in which the "rights" to a name are
-   typically not settled using the subtle and traditional product (or
-   industry) type and geopolitical scope rules of the trademark system.
-   Instead they have depended largely on political or economic power,
-   e.g., the organization with the greatest resources to invest in
-   defending (or attacking) names will ultimately win out.  The latter
-   raises not only important issues of equity, but also the risk of
-   backlash as the numerous small players are forced to relinquish names
-   they find attractive and to adopt less-desirable naming conventions.
-
-   Independent of these sociopolitical problems, content distribution
-   issues have made it clear that it should be possible for an
-   organization to have copies of data it wishes to make available
-   distributed around the network, with a user who asks for the
-   information by name getting the topologically-closest copy.  This is
-   not possible with simple, as-designed, use of the DNS: DNS names
-   identify target resources or, in the case of email "MX" records, a
-   preferentially-ordered list of resources "closest" to a target (not
-   to the source/user).  Several technologies (and, in some cases,
-   corresponding business models) have arisen to work around these
-   problems, including intercepting and altering DNS requests so as to
-   point to other locations.
-
-   Additional implications are still being discovered and evaluated.
-
-   Approaches that involve interception of DNS queries and rewriting of
-   DNS names (or otherwise altering the resolution process based on the
-   topological location of the user) seem, however, to risk disrupting
-   end-to-end applications in the general case and raise many of the
-   issues discussed by the IAB in [IAB-OPES].  These problems occur even
-   if the rewriting machinery is accompanied by additional workarounds
-   for particular applications.  For example, security associations and
-   applications that need to identify "the same host" often run into
-   problems if DNS names or other references are changed in the network
-   without participation of the applications that are trying to invoke
-   the associated services.
-
-1.4 Internet Applications Protocols and Their Evolution
-
-   At the applications level, few of the protocols in active,
-   widespread, use on the Internet reflect either contemporary knowledge
-   in computer science or human factors or experience accumulated
-   through deployment and use.  Instead, protocols tend to be deployed
-   at a just-past-prototype level, typically including the types of
-   expedient compromises typical with prototypes.  If they prove useful,
-   the nature of the network permits very rapid dissemination (i.e.,
-   they fill a vacuum, even if a vacuum that no one previously knew
-   existed).  But, once the vacuum is filled, the installed base
-
-
-
-Klensin                      Informational                      [Page 7]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   provides its own inertia: unless the design is so seriously faulty as
-   to prevent effective use (or there is a widely-perceived sense of
-   impending disaster unless the protocol is replaced), future
-   developments must maintain backward compatibility and workarounds for
-   problematic characteristics rather than benefiting from redesign in
-   the light of experience.  Applications that are "almost good enough"
-   prevent development and deployment of high-quality replacements.
-
-   The DNS is both an illustration of, and an exception to, parts of
-   this pessimistic interpretation. It was a second-generation
-   development, with the host table system being seen as at the end of
-   its useful life.  There was a serious attempt made to reflect the
-   computing state of the art at the time.  However, deployment was much
-   slower than expected (and very painful for many sites) and some fixed
-   (although relaxed several times) deadlines from a central network
-   administration were necessary for deployment to occur at all.
-   Replacing it now, in order to add functionality, while it continues
-   to perform its core functions at least reasonably well, would
-   presumably be extremely difficult.
-
-   There are many, perhaps obvious, examples of this.  Despite many
-   known deficiencies and weaknesses of definition, the "finger" and
-   "whois" [WHOIS] protocols have not been replaced (despite many
-   efforts to update or replace the latter [WHOIS-UPDATE]).  The Telnet
-   protocol and its many options drove out the SUPDUP [RFC734] one,
-   which was arguably much better designed for a diverse collection of
-   network hosts.  A number of efforts to replace the email or file
-   transfer protocols with models which their advocates considered much
-   better have failed.  And, more recently and below the applications
-   level, there is some reason to believe that this resistance to change
-   has been one of the factors impeding IPv6 deployment.
-
-2. Signs of DNS Overloading
-
-   Parts of the historical discussion above identify areas in which the
-   DNS has become overloaded (semantically if not in the mechanical
-   ability to resolve names).  Despite this overloading, it appears that
-   DNS performance and reliability are still within an acceptable range:
-   there is little evidence of serious performance degradation.  Recent
-   proposals and mechanisms to better respond to overloading and scaling
-   issues have all focused on patching or working around limitations
-   that develop when the DNS is utilized for out-of-design functions,
-   rather than on dramatic rethinking of either DNS design or those
-   uses.  The number of these issues that have arisen at much the same
-   time may argue for just that type of rethinking, and not just for
-   adding complexity and attempting to incrementally alter the design
-   (see, for example, the discussion of simplicity in section 2 of
-   [RFC3439]).
-
-
-
-Klensin                      Informational                      [Page 8]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   For example:
-
-   o  While technical approaches such as larger and higher-powered
-      servers and more bandwidth, and legal/political mechanisms such as
-      dispute resolution policies, have arguably kept the problems from
-      becoming critical, the DNS has not proven adequately responsive to
-      business and individual needs to describe or identify things (such
-      as product names and names of individuals) other than strict
-      network resources.
-
-   o  While stacks have been modified to better handle multiple
-      addresses on a physical interface and some protocols have been
-      extended to include DNS names for determining context, the DNS
-      does not deal especially well with many names associated with a
-      given host (e.g., web hosting facilities with multiple domains on
-      a server).
-
-   o  Efforts to add names deriving from languages or character sets
-      based on other than simple ASCII and English-like names (see
-      below), or even to utilize complex company or product names
-      without the use of hierarchy, have created apparent requirements
-      for names (labels) that are over 63 octets long.  This requirement
-      will undoubtedly increase over time; while there are workarounds
-      to accommodate longer names, they impose their own restrictions
-      and cause their own problems.
-
-   o  Increasing commercialization of the Internet, and visibility of
-      domain names that are assumed to match names of companies or
-      products, has turned the DNS and DNS names into a trademark
-      battleground.  The traditional trademark system in (at least) most
-      countries makes careful distinctions about fields of
-      applicability.  When the space is flattened, without
-      differentiation by either geography or industry sector, not only
-      are there likely conflicts between "Joe's Pizza" (of Boston) and
-      "Joe's Pizza" (of San Francisco) but between both and "Joe's Auto
-      Repair" (of Los Angeles).  All three would like to control
-      "Joes.com" (and would prefer, if it were permitted by DNS naming
-      rules, to also spell it as "Joe's.com" and have both resolve the
-      same way) and may claim trademark rights to do so, even though
-      conflict or confusion would not occur with traditional trademark
-      principles.
-
-   o  Many organizations wish to have different web sites under the same
-      URL and domain name.  Sometimes this is to create local variations
-      -- the Widget Company might want to present different material to
-      a UK user relative to a US one -- and sometimes it is to provide
-      higher performance by supplying information from the server
-      topologically closest to the user.  If the name resolution
-
-
-
-Klensin                      Informational                      [Page 9]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-      mechanism is expected to provide this functionality, there are
-      three possible models (which might be combined):
-
-      -  supply information about multiple sites (or locations or
-         references).  Those sites would, in turn, provide information
-         associated with the name and sufficient site-specific
-         attributes to permit the application to make a sensible choice
-         of destination, or
-
-      -  accept client-site attributes and utilize them in the search
-         process, or
-
-      -  return different answers based on the location or identity of
-         the requestor.
-
-   While there are some tricks that can provide partial simulations of
-   these types of function, DNS responses cannot be reliably conditioned
-   in this way.
-
-   These, and similar, issues of performance or content choices can, of
-   course, be thought of as not involving the DNS at all.  For example,
-   the commonly-cited alternate approach of coupling these issues to
-   HTTP content negotiation (cf. [RFC2295]), requires that an HTTP
-   connection first be opened to some "common" or "primary" host so that
-   preferences can be negotiated and then the client redirected or sent
-   alternate data.  At least from the standpoint of improving
-   performance by accessing a "closer" location, both initially and
-   thereafter, this approach sacrifices the desired result before the
-   client initiates any action.  It could even be argued that some of
-   the characteristics of common content negotiation approaches are
-   workarounds for the non-optimal use of the DNS in web URLs.
-
-   o  Many existing and proposed systems for "finding things on the
-      Internet" require a true search capability in which near matches
-      can be reported to the user (or to some user agent with an
-      appropriate rule-set) and to which queries may be ambiguous or
-      fuzzy.  The DNS, by contrast, can accommodate only one set of
-      (quite rigid) matching rules.  Proposals to permit different rules
-      in different localities (e.g., matching rules that are TLD- or
-      zone-specific) help to identify the problem.  But they cannot be
-      applied directly to the DNS without either abandoning the desired
-      level of flexibility or isolating different parts of the Internet
-      from each other (or both).  Fuzzy or ambiguous searches are
-      desirable for resolution of names that might have spelling
-      variations and for names that can be resolved into different sets
-      of glyphs depending on context.  Especially when
-      internationalization is considered, variant name problems go
-      beyond simple differences in representation of a character or
-
-
-
-Klensin                      Informational                     [Page 10]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-      ordering of a string.  Instead, avoiding user astonishment and
-      confusion requires consideration of relationships such as
-      languages that can be written with different alphabets, Kanji-
-      Hiragana relationships, Simplified and Traditional Chinese, etc.
-      See [Seng] for a discussion and suggestions for addressing a
-      subset of these issues in the context of characters based on
-      Chinese ones.  But that document essentially illustrates the
-      difficulty of providing the type of flexible matching that would
-      be anticipated by users; instead, it tries to protect against the
-      worst types of confusion (and opportunities for fraud).
-
-   o  The historical DNS, and applications that make assumptions about
-      how it works, impose significant risk (or forces technical kludges
-      and consequent odd restrictions), when one considers adding
-      mechanisms for use with various multi-character-set and
-      multilingual "internationalization" systems.  See the IAB's
-      discussion of some of these issues [RFC2825] for more information.
-
-   o  In order to provide proper functionality to the Internet, the DNS
-      must have a single unique root (the IAB provides more discussion
-      of this issue [RFC2826]).  There are many desires for local
-      treatment of names or character sets that cannot be accommodated
-      without either multiple roots (e.g., a separate root for
-      multilingual names, proposed at various times by MINC [MINC] and
-      others), or mechanisms that would have similar effects in terms of
-      Internet fragmentation and isolation.
-
-   o  For some purposes, it is desirable to be able to search not only
-      an index entry (labels or fully-qualified names in the DNS case),
-      but their values or targets (DNS data).  One might, for example,
-      want to locate all of the host (and virtual host) names which
-      cause mail to be directed to a given server via MX records.  The
-      DNS does not support this capability (see the discussion in
-      [IQUERY]) and it can be simulated only by extracting all of the
-      relevant records (perhaps by zone transfer if the source permits
-      doing so, but that permission is becoming less frequently
-      available) and then searching a file built from those records.
-
-   o  Finally, as additional types of personal or identifying
-      information are added to the DNS, issues arise with protection of
-      that information.  There are increasing calls to make different
-      information available based on the credentials and authorization
-      of the source of the inquiry.  As with information keyed to site
-      locations or proximity (as discussed above), the DNS protocols
-      make providing these differentiated services quite difficult if
-      not impossible.
-
-
-
-
-
-Klensin                      Informational                     [Page 11]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   In each of these cases, it is, or might be, possible to devise ways
-   to trick the DNS system into supporting mechanisms that were not
-   designed into it.  Several ingenious solutions have been proposed in
-   many of these areas already, and some have been deployed into the
-   marketplace with some success.  But the price of each of these
-   changes is added complexity and, with it, added risk of unexpected
-   and destabilizing problems.
-
-   Several of the above problems are addressed well by a good directory
-   system (supported by the LDAP protocol or some protocol more
-   precisely suited to these specific applications) or searching
-   environment (such as common web search engines) although not by the
-   DNS.  Given the difficulty of deploying new applications discussed
-   above, an important question is whether the tricks and kludges are
-   bad enough, or will become bad enough as usage grows, that new
-   solutions are needed and can be deployed.
-
-3. Searching, Directories, and the DNS
-
-3.1 Overview
-
-   The constraints of the DNS and the discussion above suggest the
-   introduction of an intermediate protocol mechanism, referred to below
-   as a "search layer" or "searchable system".  The terms "directory"
-   and "directory system" are used interchangeably with "searchable
-   system" in this document, although the latter is far more precise.
-   Search layer proposals would use a two (or more) stage lookup, not
-   unlike several of the proposals for internationalized names in the
-   DNS (see section 4), but all operations but the final one would
-   involve searching other systems, rather than looking up identifiers
-   in the DNS itself.  As explained below, this would permit relaxation
-   of several constraints, leading to a more capable and comprehensive
-   overall system.
-
-   Ultimately, many of the issues with domain names arise as the result
-   of efforts to use the DNS as a directory.  While, at the time this
-   document was written, sufficient pressure or demand had not occurred
-   to justify a change, it was already quite clear that, as a directory
-   system, the DNS is a good deal less than ideal.  This document
-   suggests that there actually is a requirement for a directory system,
-   and that the right solution to a searchable system requirement is a
-   searchable system, not a series of DNS patches, kludges, or
-   workarounds.
-
-
-
-
-
-
-
-
-Klensin                      Informational                     [Page 12]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   The following points illustrate particular aspects of this
-   conclusion.
-
-   o  A directory system would not require imposition of particular
-      length limits on names.
-
-   o  A directory system could permit explicit association of
-      attributes, e.g., language and country, with a name, without
-      having to utilize trick encodings to incorporate that information
-      in DNS labels (or creating artificial hierarchy for doing so).
-
-   o  There is considerable experience (albeit not much of it very
-      successful) in doing fuzzy and "sonex" (similar-sounding) matching
-      in directory systems.  Moreover, it is plausible to think about
-      different matching rules for different areas and sets of names so
-      that these can be adapted to local cultural requirements.
-      Specifically, it might be possible to have a single form of a name
-      in a directory, but to have great flexibility about what queries
-      matched that name (and even have different variations in different
-      areas).  Of course, the more flexibility that a system provides,
-      the greater the possibility of real or imagined trademark
-      conflicts.  But the opportunity would exist to design a directory
-      structure that dealt with those issues in an intelligent way,
-      while DNS constraints almost certainly make a general and
-      equitable DNS-only solution impossible.
-
-   o  If a directory system is used to translate to DNS names, and then
-      DNS names are looked up in the normal fashion, it may be possible
-      to relax several of the constraints that have been traditional
-      (and perhaps necessary) with the DNS.  For example, reverse-
-      mapping of addresses to directory names may not be a requirement
-      even if mapping of addresses to DNS names continues to be, since
-      the DNS name(s) would (continue to) uniquely identify the host.
-
-   o  Solutions to multilingual transcription problems that are common
-      in "normal life" (e.g., two-sided business cards to be sure that
-      recipients trying to contact a person can access romanized
-      spellings and numbers if the original language is not
-      comprehensible to them) can be easily handled in a directory
-      system by inserting both sets of entries.
-
-   o  A directory system could be designed that would return, not a
-      single name, but a set of names paired with network-locational
-      information or other context-establishing attributes.  This type
-      of information might be of considerable use in resolving the
-      "nearest (or best) server for a particular named resource"
-
-
-
-
-
-Klensin                      Informational                     [Page 13]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-      problems that are a significant concern for organizations hosting
-      web and other sites that are accessed from a wide range of
-      locations and subnets.
-
-   o  Names bound to countries and languages might help to manage
-      trademark realities, while, as discussed in section 1.3 above, use
-      of the DNS in trademark-significant contexts tends to require
-      worldwide "flattening" of the trademark system.
-
-   Many of these issues are a consequence of another property of the
-   DNS:  names must be unique across the Internet.  The need to have a
-   system of unique identifiers is fairly obvious (see [RFC2826]).
-   However, if that requirement were to be eliminated in a search or
-   directory system that was visible to users instead of the DNS, many
-   difficult problems -- of both an engineering and a policy nature --
-   would be likely to vanish.
-
-3.2 Some Details and Comments
-
-   Almost any internationalization proposal for names that are in, or
-   map into, the DNS will require changing DNS resolver API calls
-   ("gethostbyname" or equivalent), or adding some pre-resolution
-   preparation mechanism, in almost all Internet applications -- whether
-   to cause the API to take a different character set (no matter how it
-   is then mapped into the bits used in the DNS or another system), to
-   accept or return more arguments with qualifying or identifying
-   information, or otherwise.  Once applications must be opened to make
-   such changes, it is a relatively small matter to switch from calling
-   into the DNS to calling a directory service and then the DNS (in many
-   situations, both actions could be accomplished in a single API call).
-
-   A directory approach can be consistent both with "flat" models and
-   multi-attribute ones.  The DNS requires strict hierarchies, limiting
-   its ability to differentiate among names by their properties.  By
-   contrast, modern directories can utilize independently-searched
-   attributes and other structured schema to provide flexibilities not
-   present in a strictly hierarchical system.
-
-   There is a strong historical argument for a single directory
-   structure (implying a need for mechanisms for registration,
-   delegation, etc.).  But a single structure is not a strict
-   requirement, especially if in-depth case analysis and design work
-   leads to the conclusion that reverse-mapping to directory names is
-   not a requirement (see section 5).  If a single structure is not
-   needed, then, unlike the DNS, there would be no requirement for a
-   global organization to authorize or delegate operation of portions of
-   the structure.
-
-
-
-
-Klensin                      Informational                     [Page 14]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   The "no single structure" concept could be taken further by moving
-   away from simple "names" in favor of, e.g., multiattribute,
-   multihierarchical, faceted systems in which most of the facets use
-   restricted vocabularies.  (These terms are fairly standard in the
-   information retrieval and classification system literature, see,
-   e.g., [IS5127].)  Such systems could be designed to avoid the need
-   for procedures to ensure uniqueness across, or even within, providers
-   and databases of the faceted entities for which the search is to be
-   performed.  (See [DNS-Search] for further discussion.)
-
-   While the discussion above includes very general comments about
-   attributes, it appears that only a very small number of attributes
-   would be needed.  The list would almost certainly include country and
-   language for internationalization purposes.  It might require
-   "charset" if we cannot agree on a character set and encoding,
-   although there are strong arguments for simply using ISO 10646 (also
-   known as Unicode or "UCS" (for Universal Character Set) [UNICODE],
-   [IS10646] coding in interchange.  Trademark issues might motivate
-   "commercial" and "non-commercial" (or other) attributes if they would
-   be helpful in bypassing trademark problems.  And applications to
-   resource location, such as those contemplated for Uniform Resource
-   Identifiers (URIs) [RFC2396, RFC3305] or the Service Location
-   Protocol [RFC2608], might argue for a few other attributes (as
-   outlined above).
-
-4.  Internationalization
-
-   Much of the thinking underlying this document was driven by
-   considerations of internationalizing the DNS or, more specifically,
-   providing access to the functions of the DNS from languages and
-   naming systems that cannot be accurately expressed in the traditional
-   DNS subset of ASCII.  Much of the relevant work was done in the
-   IETF's "Internationalized Domain Names" Working Group (IDN-WG),
-   although this document also draws on extensive parallel discussions
-   in other forums.  This section contains an evaluation of what was
-   learned as an "internationalized DNS" or "multilingual DNS" was
-   explored and suggests future steps based on that evaluation.
-
-   When the IDN-WG was initiated, it was obvious to several of the
-   participants that its first important task was an undocumented one:
-   to increase the understanding of the complexities of the problem
-   sufficiently that naive solutions could be rejected and people could
-   go to work on the harder problems.  The IDN-WG clearly accomplished
-   that task. The beliefs that the problems were simple, and in the
-   corresponding simplistic approaches and their promises of quick and
-   painless deployment, effectively disappeared as the WG's efforts
-   matured.
-
-
-
-
-Klensin                      Informational                     [Page 15]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   Some of the lessons learned from increased understanding and the
-   dissipation of naive beliefs should be taken as cautions by the wider
-   community: the problems are not simple. Specifically, extracting
-   small elements for solution rather than looking at whole systems, may
-   result in obscuring the problems but not solving any problem that is
-   worth the trouble.
-
-4.1 ASCII Isn't Just Because of English
-
-   The hostname rules chosen in the mid-70s weren't just "ASCII because
-   English uses ASCII", although that was a starting point.  We have
-   discovered that almost every other script (and even ASCII if we
-   permit the rest of the characters specified in the ISO 646
-   International Reference Version) is more complex than hostname-
-   restricted-ASCII (the "LDH" form, see section 1.1).  And ASCII isn't
-   sufficient to completely represent English -- there are several words
-   in the language that are correctly spelled only with characters or
-   diacritical marks that do not appear in ASCII.  With a broader
-   selection of scripts, in some examples, case mapping works from one
-   case to the other but is not reversible.  In others, there are
-   conventions about alternate ways to represent characters (in the
-   language, not [only] in character coding) that work most of the time,
-   but not always.  And there are issues in coding, with Unicode/10646
-   providing different ways to represent the same character
-   ("character", rather than "glyph", is used deliberately here).  And,
-   in still others, there are questions as to whether two glyphs
-   "match", which may be a distance-function question, not one with a
-   binary answer.  The IETF approach to these problems is to require
-   pre-matching canonicalization (see the "stringprep" discussion
-   below).
-
-   The IETF has resisted the temptations to either try to specify an
-   entirely new coded character set, or to pick and choose Unicode/10646
-   characters on a per-character basis rather than by using well-defined
-   blocks.  While it may appear that a character set designed to meet
-   Internet-specific needs would be very attractive, the IETF has never
-   had the expertise, resources, and representation from critically-
-   important communities to actually take on that job.  Perhaps more
-   important, a new effort might have chosen to make some of the many
-   complex tradeoffs differently than the Unicode committee did,
-   producing a code with somewhat different characteristics.  But there
-   is no evidence that doing so would produce a code with fewer problems
-   and side-effects.  It is much more likely that making tradeoffs
-   differently would simply result in a different set of problems, which
-   would be equally or more difficult.
-
-
-
-
-
-
-Klensin                      Informational                     [Page 16]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-4.2 The "ASCII Encoding" Approaches
-
-   While the DNS can handle arbitrary binary strings without known
-   internal problems (see [RFC2181]), some restrictions are imposed by
-   the requirement that text be interpreted in a case-independent way
-   ([RFC1034], [RFC1035]).  More important, most internet applications
-   assume the hostname-restricted "LDH" syntax that is specified in the
-   host table RFCs and as "prudent" in RFC 1035.  If those assumptions
-   are not met, many conforming implementations of those applications
-   may exhibit behavior that would surprise implementors and users.  To
-   avoid these potential problems, IETF internationalization work has
-   focused on "ASCII-Compatible Encodings" (ACE).  These encodings
-   preserve the LDH conventions in the DNS itself.  Implementations of
-   applications that have not been upgraded utilize the encoded forms,
-   while newer ones can be written to recognize the special codings and
-   map them into non-ASCII characters. These approaches are, however,
-   not problem-free even if human interface issues are ignored.  Among
-   other issues, they rely on what is ultimately a heuristic to
-   determine whether a DNS label is to be considered as an
-   internationalized name (i.e., encoded Unicode) or interpreted as an
-   actual LDH name in its own right.  And, while all determinations of
-   whether a particular query matches a stored object are traditionally
-   made by DNS servers, the ACE systems, when combined with the
-   complexities of international scripts and names, require that much of
-   the matching work be separated into a separate, client-side,
-   canonicalization or "preparation" process before the DNS matching
-   mechanisms are invoked [STRINGPREP].
-
-4.3 "Stringprep" and Its Complexities
-
-   As outlined above, the model for avoiding problems associated with
-   putting non-ASCII names in the DNS and elsewhere evolved into the
-   principle that strings are to be placed into the DNS only after being
-   passed through a string preparation function that eliminates or
-   rejects spurious character codes, maps some characters onto others,
-   performs some sequence canonicalization, and generally creates forms
-   that can be accurately compared.  The impact of this process on
-   hostname-restricted ASCII (i.e., "LDH") strings is trivial and
-   essentially adds only overhead.  For other scripts, the impact is, of
-   necessity, quite significant.
-
-   Although the general notion underlying stringprep is simple, the many
-   details are quite subtle and the associated tradeoffs are complex. A
-   design team worked on it for months, with considerable effort placed
-   into clarifying and fine-tuning the protocol and tables.  Despite
-   general agreement that the IETF would avoid getting into the business
-   of defining character sets, character codings, and the associated
-   conventions, the group several times considered and rejected special
-
-
-
-Klensin                      Informational                     [Page 17]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   treatment of code positions to more nearly match the distinctions
-   made by Unicode with user perceptions about similarities and
-   differences between characters.  But there were intense temptations
-   (and pressures) to incorporate language-specific or country-specific
-   rules.  Those temptations, even when resisted, were indicative of
-   parts of the ongoing controversy or of the basic unsuitability of the
-   DNS for fully internationalized names that are visible,
-   comprehensible, and predictable for end users.
-
-   There have also been controversies about how far one should go in
-   these processes of preparation and transformation and, ultimately,
-   about the validity of various analogies.  For example, each of the
-   following operations has been claimed to be similar to case-mapping
-   in ASCII:
-
-   o  stripping of vowels in Arabic or Hebrew
-
-   o  matching of "look-alike" characters such as upper-case Alpha in
-      Greek and upper-case A in Roman-based alphabets
-
-   o  matching of Traditional and Simplified Chinese characters that
-      represent the same words,
-
-   o  matching of Serbo-Croatian words whether written in Roman-derived
-      or Cyrillic characters
-
-   A decision to support any of these operations would have implications
-   for other scripts or languages and would increase the overall
-   complexity of the process.  For example, unless language-specific
-   information is somehow available, performing matching between
-   Traditional and Simplified Chinese has impacts on Japanese and Korean
-   uses of the same "traditional" characters (e.g., it would not be
-   appropriate to map Kanji into Simplified Chinese).
-
-   Even were the IDN-WG's other work to have been abandoned completely
-   or if it were to fail in the marketplace, the stringprep and nameprep
-   work will continue to be extremely useful, both in identifying issues
-   and problem code points and in providing a reasonable set of basic
-   rules.  Where problems remain, they are arguably not with nameprep,
-   but with the DNS-imposed requirement that its results, as with all
-   other parts of the matching and comparison process, yield a binary
-   "match or no match" answer, rather than, e.g., a value on a
-   similarity scale that can be evaluated by the user or by user-driven
-   heuristic functions.
-
-
-
-
-
-
-
-Klensin                      Informational                     [Page 18]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-4.4 The Unicode Stability Problem
-
-   ISO 10646 basically defines only code points, and not rules for using
-   or comparing the characters.  This is part of a long-standing
-   tradition with the work of what is now ISO/IEC JTC1/SC2: they have
-   performed code point assignments and have typically treated the ways
-   in which characters are used as beyond their scope.  Consequently,
-   they have not dealt effectively with the broader range of
-   internationalization issues.  By contrast, the Unicode Technical
-   Committee (UTC) has defined, in annexes and technical reports (see,
-   e.g., [UTR15]), some additional rules for canonicalization and
-   comparison.  Many of those rules and conventions have been factored
-   into the "stringprep" and "nameprep" work, but it is not
-   straightforward to make or define them in a fashion that is
-   sufficiently precise and permanent to be relied on by the DNS.
-
-   Perhaps more important, the discussions leading to nameprep also
-   identified several areas in which the UTC definitions are inadequate,
-   at least without additional information, to make matching precise and
-   unambiguous.  In some of these cases, the Unicode Standard permits
-   several alternate approaches, none of which are an exact and obvious
-   match to DNS needs.  That has left these sensitive choices up to
-   IETF, which lacks sufficient in-depth expertise, much less any
-   mechanism for deciding to optimize one language at the expense of
-   another.
-
-   For example, it is tempting to define some rules on the basis of
-   membership in particular scripts, or for punctuation characters, but
-   there is no precise definition of what characters belong to which
-   script or which ones are, or are not, punctuation.  The existence of
-   these areas of vagueness raises two issues: whether trying to do
-   precise matching at the character set level is actually possible
-   (addressed below) and whether driving toward more precision could
-   create issues that cause instability in the implementation and
-   resolution models for the DNS.
-
-   The Unicode definition also evolves.  Version 3.2 appeared shortly
-   after work on this document was initiated.  It added some characters
-   and functionality and included a few minor incompatible code point
-   changes.  IETF has secured an agreement about constraints on future
-   changes, but it remains to be seen how that agreement will work out
-   in practice.  The prognosis actually appears poor at this stage,
-   since UTC chose to ballot a recent possible change which should have
-   been prohibited by the agreement (the outcome of the ballot is not
-   relevant, only that the ballot was issued rather than having the
-   result be a foregone conclusion).  However, some members of the
-   community consider some of the changes between Unicode 3.0 and 3.1
-   and between 3.1 and 3.2, as well as this recent ballot, to be
-
-
-
-Klensin                      Informational                     [Page 19]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   evidence of instability and that these instabilities are better
-   handled in a system that can be more flexible about handling of
-   characters, scripts, and ancillary information than the DNS.
-
-   In addition, because the systems implications of internationalization
-   are considered out of scope in SC2, ISO/IEC JTC1 has assigned some of
-   those issues to its SC22/WG20 (the Internationalization working group
-   within the subcommittee that deals with programming languages,
-   systems, and environments).  WG20 has historically dealt with
-   internationalization issues thoughtfully and in depth, but its status
-   has several times been in doubt in recent years.  However, assignment
-   of these matters to WG20 increases the risk of eventual ISO
-   internationalization standards that specify different behavior than
-   the UTC specifications.
-
-4.5 Audiences, End Users, and the User Interface Problem
-
-   Part of what has "caused" the DNS internationalization problem, as
-   well as the DNS trademark problem and several others, is that we have
-   stopped thinking about "identifiers for objects" -- which normal
-   people are not expected to see -- and started thinking about "names"
-   -- strings that are expected not only to be readable, but to have
-   linguistically-sensible and culturally-dependent meaning to non-
-   specialist users.
-
-   Within the IETF, the IDN-WG, and sometimes other groups, avoided
-   addressing the implications of that transition by taking "outside our
-   scope -- someone else's problem" approaches or by suggesting that
-   people will just become accustomed to whatever conventions are
-   adopted.  The realities of user and vendor behavior suggest that
-   these approaches will not serve the Internet community well in the
-   long term:
-
-   o  If we want to make it a problem in a different part of the user
-      interface structure, we need to figure out where it goes in order
-      to have proof of concept of our solution.  Unlike vendors whose
-      sole [business] model is the selling or registering of names, the
-      IETF must produce solutions that actually work, in the
-      applications context as seen by the end user.
-
-   o  The principle that "they will get used to our conventions and
-      adapt" is fine if we are writing rules for programming languages
-      or an API.  But the conventions under discussion are not part of a
-      semi-mathematical system, they are deeply ingrained in culture.
-      No matter how often an English-speaking American is told that the
-      Internet requires that the correct spelling of "colour" be used,
-      he or she isn't going to be convinced. Getting a French-speaker in
-      Lyon to use exactly the same lexical conventions as a French-
-
-
-
-Klensin                      Informational                     [Page 20]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-      speaker in Quebec in order to accommodate the decisions of the
-      IETF or of a registrar or registry is just not likely.  "Montreal"
-      is either a misspelling or an anglicization of a similar word with
-      an acute accent mark over the "e" (i.e., using the Unicode
-      character U+00E9 or one of its equivalents). But global agreement
-      on a rule that will determine whether the two forms should match
-      -- and that won't astonish end users and speakers of one language
-      or the other -- is as unlikely as agreement on whether
-      "misspelling" or "anglicization" is the greater travesty.
-
-   More generally, it is not clear that the outcome of any conceivable
-   nameprep-like process is going to be good enough for practical,
-   user-level, use.  In the use of human languages by humans, there are
-   many cases in which things that do not match are nonetheless
-   interpreted as matching.  The Norwegian/Danish character that appears
-   in U+00F8 (visually, a lower case 'o' overstruck with a forward
-   slash) and the "o-umlaut" German character that appears in U+00F6
-   (visually, a lower case 'o' with diaeresis (or umlaut)) are clearly
-   different and no matching program should yield an "equal" comparison.
-   But they are more similar to each other than either of them is to,
-   e.g., "e".  Humans are able to mentally make the correction in
-   context, and do so easily, and they can be surprised if computers
-   cannot do so.  Worse, there is a Swedish character whose appearance
-   is identical to the German o-umlaut, and which shares code point
-   U+00F6, but that, if the languages are known and the sounds of the
-   letters or meanings of words including the character are considered,
-   actually should match the Norwegian/Danish use of U+00F8.
-
-   This text uses examples in Roman scripts because it is being written
-   in English and those examples are relatively easy to render.  But one
-   of the important lessons of the discussions about domain name
-   internationalization in recent years is that problems similar to
-   those described above exist in almost every language and script.
-   Each one has its idiosyncrasies, and each set of idiosyncracies is
-   tied to common usage and cultural issues that are very familiar in
-   the relevant group, and often deeply held as cultural values.  As
-   long as a schoolchild in the US can get a bad grade on a spelling
-   test for using a perfectly valid British spelling, or one in France
-   or Germany can get a poor grade for leaving off a diacritical mark,
-   there are issues with the relevant language.  Similarly, if children
-   in Egypt or Israel are taught that it is acceptable to write a word
-   with or without vowels or stress marks, but that, if those marks are
-   included, they must be the correct ones, or a user in Korea is
-   potentially offended or astonished by out-of-order sequences of Jamo,
-   systems based on character-at-a-time processing and simplistic
-   matching, with no contextual information, are not going to satisfy
-   user needs.
-
-
-
-
-Klensin                      Informational                     [Page 21]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   Users are demanding solutions that deal with language and culture.
-   Systems of identifier symbol-strings that serve specialists or
-   computers are, at best, a solution to a rather different (and, at the
-   time this document was written, somewhat ill-defined), problem.  The
-   recent efforts have made it ever more clear that, if we ignore the
-   distinction between the user requirements and narrowly-defined
-   identifiers, we are solving an insufficient problem.  And,
-   conversely, the approaches that have been proposed to approximate
-   solutions to the user requirement may be far more complex than simple
-   identifiers require.
-
-4.6 Business Cards and Other Natural Uses of Natural Languages
-
-   Over the last few centuries, local conventions have been established
-   in various parts of the world for dealing with multilingual
-   situations.  It may be helpful to examine some of these.  For
-   example, if one visits a country where the language is different from
-   ones own, business cards are often printed on two sides, one side in
-   each language.  The conventions are not completely consistent and the
-   technique assumes that recipients will be tolerant. Translations of
-   names or places are attempted in some situations and transliterations
-   in others.  Since it is widely understood that exact translations or
-   transliterations are often not possible, people typically smile at
-   errors, appreciate the effort, and move on.
-
-   The DNS situation differs from these practices in at least two ways.
-   Since a global solution is required, the business card would need a
-   number of sides approximating the number of languages in the world,
-   which is probably impossible without violating laws of physics.  More
-   important, the opportunities for tolerance don't exist:  the DNS
-   requires a exact match or the lookup fails.
-
-4.7 ASCII Encodings and the Roman Keyboard Assumption
-
-   Part of the argument for ACE-based solutions is that they provide an
-   escape for multilingual environments when applications have not been
-   upgraded.  When an older application encounters an ACE-based name,
-   the assumption is that the (admittedly ugly) ASCII-coded string will
-   be displayed and can be typed in.  This argument is reasonable from
-   the standpoint of mixtures of Roman-based alphabets, but may not be
-   relevant if user-level systems and devices are involved that do not
-   support the entry of Roman-based characters or which cannot
-   conveniently render such characters.  Such systems are few in the
-   world today, but the number can reasonably be expected to rise as the
-   Internet is increasingly used by populations whose primary concern is
-   with local issues, local information, and local languages.  It is,
-
-
-
-
-
-Klensin                      Informational                     [Page 22]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   for example, fairly easy to imagine populations who use Arabic or
-   Thai scripts and who do not have routine access to scripts or input
-   devices based on Roman-derived alphabets.
-
-4.8 Intra-DNS Approaches for "Multilingual Names"
-
-   It appears, from the cases above and others, that none of the intra-
-   DNS-based solutions for "multilingual names" are workable.  They rest
-   on too many assumptions that do not appear to be feasible -- that
-   people will adapt deeply-entrenched language habits to conventions
-   laid down to make the lives of computers easy; that we can make
-   "freeze it now, no need for changes in these areas" decisions about
-   Unicode and nameprep; that ACE will smooth over applications
-   problems, even in environments without the ability to key or render
-   Roman-based glyphs (or where user experience is such that such glyphs
-   cannot easily be distinguished from each other); that the Unicode
-   Consortium will never decide to repair an error in a way that creates
-   a risk of DNS incompatibility; that we can either deploy EDNS
-   [RFC2671] or that long names are not really important; that Japanese
-   and Chinese computer users (and others) will either give up their
-   local or IS 2022-based character coding solutions (for which addition
-   of a large fraction of a million new code points to Unicode is almost
-   certainly a necessary, but probably not sufficient, condition) or
-   build leakproof and completely accurate boundary conversion
-   mechanisms; that out of band or contextual information will always be
-   sufficient for the "map glyph onto script" problem; and so on.  In
-   each case, it is likely that about 80% or 90% of cases will work
-   satisfactorily, but it is unlikely that such partial solutions will
-   be good enough.  For example, suppose someone can spell her name 90%
-   correctly, or a company name is matched correctly 80% of the time but
-   the other 20% of attempts identify a competitor: are either likely to
-   be considered adequate?
-
-5. Search-based Systems: The Key Controversies
-
-   For many years, a common response to requirements to locate people or
-   resources on the Internet has been to invoke the term "directory".
-   While an in-depth analysis of the reasons would require a separate
-   document, the history of failure of these invocations has given
-   "directory" efforts a bad reputation.  The effort proposed here is
-   different from those predecessors for several reasons, perhaps the
-   most important of which is that it focuses on a fairly-well-
-   understood set of problems and needs, rather than on finding uses for
-   a particular technology.
-
-   As suggested in some of the text above, it is an open question as to
-   whether the needs of the community would be best served by a single
-   (even if functionally, and perhaps administratively, distributed)
-
-
-
-Klensin                      Informational                     [Page 23]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   directory with universal applicability, a single directory that
-   supports locally-tailored search (and, most important, matching)
-   functions, or multiple, locally-determined, directories.  Each has
-   its attractions.  Any but the first would essentially prevent
-   reverse-mapping (determination of the user-visible name of the host
-   or resource from target information such as an address or DNS name).
-   But reverse mapping has become less useful over the years --at least
-   to users -- as more and more names have been associated with many
-   host addresses and as CIDR [CIDR] has proven problematic for mapping
-   smaller address blocks to meaningful names.
-
-   Locally-tailored searches and mappings would permit national
-   variations on interpretation of which strings matched which other
-   ones, an arrangement that is especially important when different
-   localities apply different rules to, e.g., matching of characters
-   with and without diacriticals.  But, of course, this implies that a
-   URL may evaluate properly or not depending on either settings on a
-   client machine or the network connectivity of the user.  That is not,
-   in general, a desirable situation, since it implies that users could
-   not, in the general case, share URLs (or other host references) and
-   that a particular user might not be able to carry references from one
-   host or location to another.
-
-   And, of course, completely separate directories would permit
-   translation and transliteration functions to be embedded in the
-   directory, giving much of the Internet a different appearance
-   depending on which directory was chosen.  The attractions of this are
-   obvious, but, unless things were very carefully designed to preserve
-   uniqueness and precise identities at the right points (which may or
-   may not be possible), such a system would have many of the
-   difficulties associated with multiple DNS roots.
-
-   Finally, a system of separate directories and databases, if coupled
-   with removal of the DNS-imposed requirement for unique names, would
-   largely eliminate the need for a single worldwide authority to manage
-   the top of the naming hierarchy.
-
-6.  Security Considerations
-
-   The set of proposals implied by this document suggests an interesting
-   set of security issues (i.e., nothing important is ever easy).  A
-   directory system used for locating network resources would presumably
-   need to be as carefully protected against unauthorized changes as the
-   DNS itself.  There also might be new opportunities for problems in an
-   arrangement involving two or more (sub)layers, especially if such a
-   system were designed without central authority or uniqueness of
-   names.  It is uncertain how much greater those risks would be as
-   compared to a DNS lookup sequence that involved looking up one name,
-
-
-
-Klensin                      Informational                     [Page 24]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   getting back information, and then doing additional lookups
-   potentially in different subtrees.  That multistage lookup will often
-   be the case with, e.g., NAPTR records [RFC 2915] unless additional
-   restrictions are imposed.  But additional steps, systems, and
-   databases almost certainly involve some additional risks of
-   compromise.
-
-7.  References
-
-7.1 Normative References
-
-   None
-
-7.2 Explanatory and Informative References
-
-   [Albitz]       Any of the editions of Albitz, P. and C. Liu, DNS and
-                  BIND, O'Reilly and Associates, 1992, 1997, 1998, 2001.
-
-   [ASCII]        American National Standards Institute (formerly United
-                  States of America Standards Institute), X3.4, 1968,
-                  "USA Code for Information Interchange". ANSI X3.4-1968
-                  has been replaced by newer versions with slight
-                  modifications, but the 1968 version remains definitive
-                  for the Internet.  Some time after ASCII was first
-                  formulated as a standard, ISO adopted international
-                  standard 646, which uses ASCII as a base.  IS 646
-                  actually contained two code tables: an "International
-                  Reference Version" (often referenced as ISO 646-IRV)
-                  which was essentially identical to the ASCII of the
-                  time, and a "Basic Version" (ISO 646-BV), which
-                  designates a number of character positions for
-                  national use.
-
-   [CIDR]         Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless
-                  Inter-Domain Routing (CIDR): an Address Assignment and
-                  Aggregation Strategy", RFC 1519, September 1993.
-
-                  Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
-                  ADDR.ARPA delegation", RFC 2317, March 1998.
-
-   [COM-SIZE]     Size information supplied by Verisign Global Registry
-                  Services (the zone administrator, or "registry
-                  operator", for COM, see [REGISTRAR], below) to ICANN,
-                  third quarter 2002.
-
-   [DNS-Search]   Klensin, J., "A Search-based access model for the
-                  DNS", Work in Progress.
-
-
-
-
-Klensin                      Informational                     [Page 25]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   [FINGER]       Zimmerman, D., "The Finger User Information Protocol",
-                  RFC 1288, December 1991.
-
-                  Harrenstien, K., "NAME/FINGER Protocol", RFC 742,
-                  December 1977.
-
-   [IAB-OPES]     Floyd, S. and L. Daigle, "IAB Architectural and Policy
-                  Considerations for Open Pluggable Edge Services", RFC
-                  3238, January 2002.
-
-   [IQUERY]       Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
-                  2002.
-
-   [IS646]        ISO/IEC 646:1991 Information technology -- ISO 7-bit
-                  coded character set for information interchange
-
-   [IS10646]      ISO/IEC 10646-1:2000 Information technology --
-                  Universal Multiple-Octet Coded Character Set (UCS) --
-                  Part 1: Architecture and Basic Multilingual Plane and
-                  ISO/IEC 10646-2:2001 Information technology --
-                  Universal Multiple-Octet Coded Character Set (UCS) --
-                  Part 2: Supplementary Planes
-
-   [MINC]         The Multilingual Internet Names Consortium,
-                  http://www.minc.org/ has been an early advocate for
-                  the importance of expansion of DNS names to
-                  accommodate non-ASCII characters.  Some of their
-                  specific proposals, while helping people to understand
-                  the problems better, were not compatible with the
-                  design of the DNS.
-
-   [NAPTR]        Mealling, M. and R. Daniel, "The Naming Authority
-                  Pointer (NAPTR) DNS Resource Record", RFC 2915,
-                  September 2000.
-
-                  Mealling, M., "Dynamic Delegation Discovery System
-                  (DDDS) Part One: The Comprehensive DDDS", RFC 3401,
-                  October 2002.
-
-                  Mealling, M., "Dynamic Delegation Discovery System
-                  (DDDS) Part Two: The Algorithm", RFC 3402, October
-                  2002.
-
-                  Mealling, M., "Dynamic Delegation Discovery System
-                  (DDDS) Part Three: The Domain Name System (DNS)
-                  Database", RFC 3403, October 2002.
-
-
-
-
-
-Klensin                      Informational                     [Page 26]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   [REGISTRAR]    In an early stage of the process that created the
-                  Internet Corporation for Assigned Names and Numbers
-                  (ICANN), a "Green Paper" was released by the US
-                  Government.   That paper introduced new terminology
-                  and some concepts not needed by traditional DNS
-                  operations.  The term "registry" was applied to the
-                  actual operator and database holder of a domain
-                  (typically at the top level, since the Green Paper was
-                  little concerned with anything else), while
-                  organizations that marketed names and made them
-                  available to "registrants" were known as "registrars".
-                  In the classic DNS model, the function of "zone
-                  administrator" encompassed both registry and registrar
-                  roles, although that model did not anticipate a
-                  commercial market in names.
-
-   [RFC625]       Kudlick, M. and E. Feinler, "On-line hostnames
-                  service", RFC 625, March 1974.
-
-   [RFC734]       Crispin, M., "SUPDUP Protocol", RFC 734, October 1977.
-
-   [RFC811]       Harrenstien, K., White, V. and E. Feinler, "Hostnames
-                  Server", RFC 811, March 1982.
-
-   [RFC819]       Su, Z. and J. Postel, "Domain naming convention for
-                  Internet user applications", RFC 819, August 1982.
-
-   [RFC830]       Su, Z., "Distributed system for Internet name
-                  service", RFC 830, October 1982.
-
-   [RFC882]       Mockapetris, P., "Domain names: Concepts and
-                  facilities", RFC 882, November 1983.
-
-   [RFC883]       Mockapetris, P., "Domain names: Implementation
-                  specification", RFC 883, November 1983.
-
-   [RFC952]       Harrenstien, K, Stahl, M. and E. Feinler, "DoD
-                  Internet host table specification", RFC 952, October
-                  1985.
-
-   [RFC953]       Harrenstien, K., Stahl, M. and E. Feinler, "HOSTNAME
-                  SERVER", RFC 953, October 1985.
-
-   [RFC1034]      Mockapetris, P., "Domain names, Concepts and
-                  facilities", STD 13, RFC 1034, November 1987.
-
-
-
-
-
-
-Klensin                      Informational                     [Page 27]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   [RFC1035]      Mockapetris, P., "Domain names - implementation and
-                  specification", STD 13, RFC 1035, November 1987.
-
-   [RFC1591]      Postel, J., "Domain Name System Structure and
-                  Delegation", RFC 1591, March 1994.
-
-   [RFC2181]      Elz, R. and  R. Bush, "Clarifications to the DNS
-                  Specification", RFC 2181, July 1997.
-
-   [RFC2295]      Holtman, K. and A. Mutz, "Transparent Content
-                  Negotiation in HTTP", RFC 2295, March 1998
-
-   [RFC2396]      Berners-Lee, T., Fielding, R. and L. Masinter,
-                  "Uniform Resource Identifiers (URI): Generic Syntax",
-                  RFC 2396, August 1998.
-
-   [RFC2608]      Guttman, E., Perkins, C., Veizades, J. and M. Day,
-                  "Service Location Protocol, Version 2", RFC 2608, June
-                  1999.
-
-   [RFC2671]      Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-                  2671, August 1999.
-
-   [RFC2825]      IAB, Daigle, L., Ed., "A Tangled Web: Issues of I18N,
-                  Domain Names, and the Other Internet protocols", RFC
-                  2825, May 2000.
-
-   [RFC2826]      IAB, "IAB Technical Comment on the Unique DNS Root",
-                  RFC 2826, May 2000.
-
-   [RFC2972]      Popp, N., Mealling, M., Masinter, L. and K. Sollins,
-                  "Context and Goals for Common Name Resolution", RFC
-                  2972, October 2000.
-
-   [RFC3305]      Mealling, M. and R. Denenberg, Eds., "Report from the
-                  Joint W3C/IETF URI Planning Interest Group: Uniform
-                  Resource Identifiers (URIs), URLs, and Uniform
-                  Resource Names (URNs):  Clarifications and
-                  Recommendations", RFC 3305, August 2002.
-
-   [RFC3439]      Bush, R. and D. Meyer, "Some Internet Architectural
-                  Guidelines and Philosophy", RFC 3439, December 2002.
-
-   [Seng]         Seng, J., et al., Eds., "Internationalized Domain
-                  Names:  Registration and Administration Guideline for
-                  Chinese, Japanese, and Korean", Work in Progress.
-
-
-
-
-
-Klensin                      Informational                     [Page 28]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   [STRINGPREP]   Hoffman, P. and M. Blanchet, "Preparation of
-                  Internationalized Strings (stringprep)", RFC 3454,
-                  December 2002.
-
-                  The particular profile used for placing
-                  internationalized strings in the DNS is called
-                  "nameprep", described in Hoffman, P. and M. Blanchet,
-                  "Nameprep: A Stringprep Profile for Internationalized
-                  Domain Names", Work in Progress.
-
-   [TELNET]       Postel, J. and J. Reynolds, "Telnet Protocol
-                  Specification", STD 8, RFC 854, May 1983.
-
-                  Postel, J. and J. Reynolds, "Telnet Option
-                  Specifications", STD 8, RFC 855, May 1983.
-
-   [UNICODE]      The Unicode Consortium, The Unicode Standard, Version
-                  3.0, Addison-Wesley: Reading, MA, 2000.  Update to
-                  version 3.1, 2001.  Update to version 3.2, 2002.
-
-   [UTR15]        Davis, M. and M. Duerst, "Unicode Standard Annex #15:
-                  Unicode Normalization Forms", Unicode Consortium,
-                  March 2002.  An integral part of The Unicode Standard,
-                  Version 3.1.1.  Available at
-                  (http://www.unicode.org/reports/tr15/tr15-21.html).
-
-   [WHOIS]        Harrenstien, K, Stahl, M. and E. Feinler,
-                  "NICNAME/WHOIS", RFC 954, October 1985.
-
-   [WHOIS-UPDATE] Gargano, J. and K. Weiss, "Whois and Network
-                  Information Lookup Service, Whois++", RFC 1834, August
-                  1995.
-
-                  Weider, C., Fullton, J. and S. Spero, "Architecture of
-                  the Whois++ Index Service", RFC 1913, February 1996.
-
-                  Williamson, S., Kosters, M., Blacka, D., Singh, J. and
-                  K. Zeilstra, "Referral Whois (RWhois) Protocol V1.5",
-                  RFC 2167, June 1997;
-
-                  Daigle, L. and P. Faltstrom, "The
-                  application/whoispp-query Content-Type", RFC 2957,
-                  October 2000.
-
-                  Daigle, L. and P. Falstrom, "The application/whoispp-
-                  response Content-type", RFC 2958, October 2000.
-
-
-
-
-
-Klensin                      Informational                     [Page 29]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-   [X29]          International Telecommuncations Union, "Recommendation
-                  X.29: Procedures for the exchange of control
-                  information and user data between a Packet
-                  Assembly/Disassembly (PAD) facility and a packet mode
-                  DTE or another PAD", December 1997.
-
-8. Acknowledgements
-
-   Many people have contributed to versions of this document or the
-   thinking that went into it.  The author would particularly like to
-   thank Harald Alvestrand, Rob Austein, Bob Braden, Vinton Cerf, Matt
-   Crawford, Leslie Daigle, Patrik Faltstrom, Eric A. Hall, Ted Hardie,
-   Paul Hoffman, Erik Nordmark, and Zita Wenzel for making specific
-   suggestions and/or challenging the assumptions and presentation of
-   earlier versions and suggesting ways to improve them.
-
-9. Author's Address
-
-   John C. Klensin
-   1770 Massachusetts Ave, #322
-   Cambridge, MA 02140
-
-   EMail: klensin+srch@jck.com
-
-   A mailing list has been initiated for discussion of the topics
-   discussed in this document, and closely-related issues, at
-   ietf-irnss@lists.elistx.com.  See http://lists.elistx.com/archives/
-   for subscription and archival information.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Klensin                      Informational                     [Page 30]
-
-RFC 3467          Role of the Domain Name System (DNS)     February 2003
-
-
-10. 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Klensin                      Informational                     [Page 31]
-
diff --git a/contrib/bind9/doc/rfc/rfc3490.txt b/contrib/bind9/doc/rfc/rfc3490.txt
deleted file mode 100644
index d2e0b3b..0000000
--- a/contrib/bind9/doc/rfc/rfc3490.txt
+++ /dev/null
@@ -1,1235 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       P. Faltstrom
-Request for Comments: 3490                                         Cisco
-Category: Standards Track                                     P. Hoffman
-                                                              IMC & VPNC
-                                                             A. Costello
-                                                             UC Berkeley
-                                                              March 2003
-
-
-         Internationalizing Domain Names in Applications (IDNA)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   Until now, there has been no standard method for domain names to use
-   characters outside the ASCII repertoire.  This document defines
-   internationalized domain names (IDNs) and a mechanism called
-   Internationalizing Domain Names in Applications (IDNA) for handling
-   them in a standard fashion.  IDNs use characters drawn from a large
-   repertoire (Unicode), but IDNA allows the non-ASCII characters to be
-   represented using only the ASCII characters already allowed in so-
-   called host names today.  This backward-compatible representation is
-   required in existing protocols like DNS, so that IDNs can be
-   introduced with no changes to the existing infrastructure.  IDNA is
-   only meant for processing domain names, not free text.
-
-Table of Contents
-
-   1. Introduction..................................................  2
-      1.1 Problem Statement.........................................  3
-      1.2 Limitations of IDNA.......................................  3
-      1.3 Brief overview for application developers.................  4
-   2. Terminology...................................................  5
-   3. Requirements and applicability................................  7
-      3.1 Requirements..............................................  7
-      3.2 Applicability.............................................  8
-         3.2.1. DNS resource records................................  8
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 1]
-
-RFC 3490                          IDNA                        March 2003
-
-
-         3.2.2. Non-domain-name data types stored in domain names...  9
-   4. Conversion operations.........................................  9
-      4.1 ToASCII................................................... 10
-      4.2 ToUnicode................................................. 11
-   5. ACE prefix.................................................... 12
-   6. Implications for typical applications using DNS............... 13
-      6.1 Entry and display in applications......................... 14
-      6.2 Applications and resolver libraries....................... 15
-      6.3 DNS servers............................................... 15
-      6.4 Avoiding exposing users to the raw ACE encoding........... 16
-      6.5  DNSSEC authentication of IDN domain names................ 16
-   7. Name server considerations.................................... 17
-   8. Root server considerations.................................... 17
-   9. References.................................................... 18
-      9.1 Normative References...................................... 18
-      9.2 Informative References.................................... 18
-   10. Security Considerations...................................... 19
-   11. IANA Considerations.......................................... 20
-   12. Authors' Addresses........................................... 21
-   13. Full Copyright Statement..................................... 22
-
-1. Introduction
-
-   IDNA works by allowing applications to use certain ASCII name labels
-   (beginning with a special prefix) to represent non-ASCII name labels.
-   Lower-layer protocols need not be aware of this; therefore IDNA does
-   not depend on changes to any infrastructure.  In particular, IDNA
-   does not depend on any changes to DNS servers, resolvers, or protocol
-   elements, because the ASCII name service provided by the existing DNS
-   is entirely sufficient for IDNA.
-
-   This document does not require any applications to conform to IDNA,
-   but applications can elect to use IDNA in order to support IDN while
-   maintaining interoperability with existing infrastructure.  If an
-   application wants to use non-ASCII characters in domain names, IDNA
-   is the only currently-defined option.  Adding IDNA support to an
-   existing application entails changes to the application only, and
-   leaves room for flexibility in the user interface.
-
-   A great deal of the discussion of IDN solutions has focused on
-   transition issues and how IDN will work in a world where not all of
-   the components have been updated.  Proposals that were not chosen by
-   the IDN Working Group would depend on user applications, resolvers,
-   and DNS servers being updated in order for a user to use an
-   internationalized domain name.  Rather than rely on widespread
-   updating of all components, IDNA depends on updates to user
-   applications only; no changes are needed to the DNS protocol or any
-   DNS servers or the resolvers on user's computers.
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 2]
-
-RFC 3490                          IDNA                        March 2003
-
-
-1.1 Problem Statement
-
-   The IDNA specification solves the problem of extending the repertoire
-   of characters that can be used in domain names to include the Unicode
-   repertoire (with some restrictions).
-
-   IDNA does not extend the service offered by DNS to the applications.
-   Instead, the applications (and, by implication, the users) continue
-   to see an exact-match lookup service.  Either there is a single
-   exactly-matching name or there is no match.  This model has served
-   the existing applications well, but it requires, with or without
-   internationalized domain names, that users know the exact spelling of
-   the domain names that the users type into applications such as web
-   browsers and mail user agents.  The introduction of the larger
-   repertoire of characters potentially makes the set of misspellings
-   larger, especially given that in some cases the same appearance, for
-   example on a business card, might visually match several Unicode code
-   points or several sequences of code points.
-
-   IDNA allows the graceful introduction of IDNs not only by avoiding
-   upgrades to existing infrastructure (such as DNS servers and mail
-   transport agents), but also by allowing some rudimentary use of IDNs
-   in applications by using the ASCII representation of the non-ASCII
-   name labels.  While such names are very user-unfriendly to read and
-   type, and hence are not suitable for user input, they allow (for
-   instance) replying to email and clicking on URLs even though the
-   domain name displayed is incomprehensible to the user.  In order to
-   allow user-friendly input and output of the IDNs, the applications
-   need to be modified to conform to this specification.
-
-   IDNA uses the Unicode character repertoire, which avoids the
-   significant delays that would be inherent in waiting for a different
-   and specific character set be defined for IDN purposes by some other
-   standards developing organization.
-
-1.2 Limitations of IDNA
-
-   The IDNA protocol does not solve all linguistic issues with users
-   inputting names in different scripts.  Many important language-based
-   and script-based mappings are not covered in IDNA and need to be
-   handled outside the protocol.  For example, names that are entered in
-   a mix of traditional and simplified Chinese characters will not be
-   mapped to a single canonical name.  Another example is Scandinavian
-   names that are entered with U+00F6 (LATIN SMALL LETTER O WITH
-   DIAERESIS) will not be mapped to U+00F8 (LATIN SMALL LETTER O WITH
-   STROKE).
-
-
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 3]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   An example of an important issue that is not considered in detail in
-   IDNA is how to provide a high probability that a user who is entering
-   a domain name based on visual information (such as from a business
-   card or billboard) or aural information (such as from a telephone or
-   radio) would correctly enter the IDN.  Similar issues exist for ASCII
-   domain names, for example the possible visual confusion between the
-   letter 'O' and the digit zero, but the introduction of the larger
-   repertoire of characters creates more opportunities of similar
-   looking and similar sounding names.  Note that this is a complex
-   issue relating to languages, input methods on computers, and so on.
-   Furthermore, the kind of matching and searching necessary for a high
-   probability of success would not fit the role of the DNS and its
-   exact matching function.
-
-1.3 Brief overview for application developers
-
-   Applications can use IDNA to support internationalized domain names
-   anywhere that ASCII domain names are already supported, including DNS
-   master files and resolver interfaces.  (Applications can also define
-   protocols and interfaces that support IDNs directly using non-ASCII
-   representations.  IDNA does not prescribe any particular
-   representation for new protocols, but it still defines which names
-   are valid and how they are compared.)
-
-   The IDNA protocol is contained completely within applications.  It is
-   not a client-server or peer-to-peer protocol: everything is done
-   inside the application itself.  When used with a DNS resolver
-   library, IDNA is inserted as a "shim" between the application and the
-   resolver library.  When used for writing names into a DNS zone, IDNA
-   is used just before the name is committed to the zone.
-
-   There are two operations described in section 4 of this document:
-
-   -  The ToASCII operation is used before sending an IDN to something
-      that expects ASCII names (such as a resolver) or writing an IDN
-      into a place that expects ASCII names (such as a DNS master file).
-
-   -  The ToUnicode operation is used when displaying names to users,
-      for example names obtained from a DNS zone.
-
-   It is important to note that the ToASCII operation can fail.  If it
-   fails when processing a domain name, that domain name cannot be used
-   as an internationalized domain name and the application has to have
-   some method of dealing with this failure.
-
-   IDNA requires that implementations process input strings with
-   Nameprep [NAMEPREP], which is a profile of Stringprep [STRINGPREP],
-   and then with Punycode [PUNYCODE].  Implementations of IDNA MUST
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 4]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   fully implement Nameprep and Punycode; neither Nameprep nor Punycode
-   are optional.
-
-2. Terminology
-
-   The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
-   and "MAY" in this document are to be interpreted as described in BCP
-   14, RFC 2119 [RFC2119].
-
-   A code point is an integer value associated with a character in a
-   coded character set.
-
-   Unicode [UNICODE] is a coded character set containing tens of
-   thousands of characters.  A single Unicode code point is denoted by
-   "U+" followed by four to six hexadecimal digits, while a range of
-   Unicode code points is denoted by two hexadecimal numbers separated
-   by "..", with no prefixes.
-
-   ASCII means US-ASCII [USASCII], a coded character set containing 128
-   characters associated with code points in the range 0..7F.  Unicode
-   is an extension of ASCII: it includes all the ASCII characters and
-   associates them with the same code points.
-
-   The term "LDH code points" is defined in this document to mean the
-   code points associated with ASCII letters, digits, and the hyphen-
-   minus; that is, U+002D, 30..39, 41..5A, and 61..7A. "LDH" is an
-   abbreviation for "letters, digits, hyphen".
-
-   [STD13] talks about "domain names" and "host names", but many people
-   use the terms interchangeably.  Further, because [STD13] was not
-   terribly clear, many people who are sure they know the exact
-   definitions of each of these terms disagree on the definitions.  In
-   this document the term "domain name" is used in general.  This
-   document explicitly cites [STD3] whenever referring to the host name
-   syntax restrictions defined therein.
-
-   A label is an individual part of a domain name.  Labels are usually
-   shown separated by dots; for example, the domain name
-   "www.example.com" is composed of three labels: "www", "example", and
-   "com".  (The zero-length root label described in [STD13], which can
-   be explicit as in "www.example.com." or implicit as in
-   "www.example.com", is not considered a label in this specification.)
-   IDNA extends the set of usable characters in labels that are text.
-   For the rest of this document, the term "label" is shorthand for
-   "text label", and "every label" means "every text label".
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 5]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   An "internationalized label" is a label to which the ToASCII
-   operation (see section 4) can be applied without failing (with the
-   UseSTD3ASCIIRules flag unset).  This implies that every ASCII label
-   that satisfies the [STD13] length restriction is an internationalized
-   label.  Therefore the term "internationalized label" is a
-   generalization, embracing both old ASCII labels and new non-ASCII
-   labels.  Although most Unicode characters can appear in
-   internationalized labels, ToASCII will fail for some input strings,
-   and such strings are not valid internationalized labels.
-
-   An "internationalized domain name" (IDN) is a domain name in which
-   every label is an internationalized label.  This implies that every
-   ASCII domain name is an IDN (which implies that it is possible for a
-   name to be an IDN without it containing any non-ASCII characters).
-   This document does not attempt to define an "internationalized host
-   name".  Just as has been the case with ASCII names, some DNS zone
-   administrators may impose restrictions, beyond those imposed by DNS
-   or IDNA, on the characters or strings that may be registered as
-   labels in their zones.  Such restrictions have no impact on the
-   syntax or semantics of DNS protocol messages; a query for a name that
-   matches no records will yield the same response regardless of the
-   reason why it is not in the zone.  Clients issuing queries or
-   interpreting responses cannot be assumed to have any knowledge of
-   zone-specific restrictions or conventions.
-
-   In IDNA, equivalence of labels is defined in terms of the ToASCII
-   operation, which constructs an ASCII form for a given label, whether
-   or not the label was already an ASCII label.  Labels are defined to
-   be equivalent if and only if their ASCII forms produced by ToASCII
-   match using a case-insensitive ASCII comparison.  ASCII labels
-   already have a notion of equivalence: upper case and lower case are
-   considered equivalent.  The IDNA notion of equivalence is an
-   extension of that older notion.  Equivalent labels in IDNA are
-   treated as alternate forms of the same label, just as "foo" and "Foo"
-   are treated as alternate forms of the same label.
-
-   To allow internationalized labels to be handled by existing
-   applications, IDNA uses an "ACE label" (ACE stands for ASCII
-   Compatible Encoding).  An ACE label is an internationalized label
-   that can be rendered in ASCII and is equivalent to an
-   internationalized label that cannot be rendered in ASCII.  Given any
-   internationalized label that cannot be rendered in ASCII, the ToASCII
-   operation will convert it to an equivalent ACE label (whereas an
-   ASCII label will be left unaltered by ToASCII).  ACE labels are
-   unsuitable for display to users.  The ToUnicode operation will
-   convert any label to an equivalent non-ACE label.  In fact, an ACE
-   label is formally defined to be any label that the ToUnicode
-   operation would alter (whereas non-ACE labels are left unaltered by
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 6]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   ToUnicode).  Every ACE label begins with the ACE prefix specified in
-   section 5.  The ToASCII and ToUnicode operations are specified in
-   section 4.
-
-   The "ACE prefix" is defined in this document to be a string of ASCII
-   characters that appears at the beginning of every ACE label.  It is
-   specified in section 5.
-
-   A "domain name slot" is defined in this document to be a protocol
-   element or a function argument or a return value (and so on)
-   explicitly designated for carrying a domain name.  Examples of domain
-   name slots include: the QNAME field of a DNS query; the name argument
-   of the gethostbyname() library function; the part of an email address
-   following the at-sign (@) in the From: field of an email message
-   header; and the host portion of the URI in the src attribute of an
-   HTML <IMG> tag.  General text that just happens to contain a domain
-   name is not a domain name slot; for example, a domain name appearing
-   in the plain text body of an email message is not occupying a domain
-   name slot.
-
-   An "IDN-aware domain name slot" is defined in this document to be a
-   domain name slot explicitly designated for carrying an
-   internationalized domain name as defined in this document.  The
-   designation may be static (for example, in the specification of the
-   protocol or interface) or dynamic (for example, as a result of
-   negotiation in an interactive session).
-
-   An "IDN-unaware domain name slot" is defined in this document to be
-   any domain name slot that is not an IDN-aware domain name slot.
-   Obviously, this includes any domain name slot whose specification
-   predates IDNA.
-
-3. Requirements and applicability
-
-3.1 Requirements
-
-   IDNA conformance means adherence to the following four requirements:
-
-   1) Whenever dots are used as label separators, the following
-      characters MUST be recognized as dots: U+002E (full stop), U+3002
-      (ideographic full stop), U+FF0E (fullwidth full stop), U+FF61
-      (halfwidth ideographic full stop).
-
-   2) Whenever a domain name is put into an IDN-unaware domain name slot
-      (see section 2), it MUST contain only ASCII characters.  Given an
-      internationalized domain name (IDN), an equivalent domain name
-      satisfying this requirement can be obtained by applying the
-
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 7]
-
-RFC 3490                          IDNA                        March 2003
-
-
-      ToASCII operation (see section 4) to each label and, if dots are
-      used as label separators, changing all the label separators to
-      U+002E.
-
-   3) ACE labels obtained from domain name slots SHOULD be hidden from
-      users when it is known that the environment can handle the non-ACE
-      form, except when the ACE form is explicitly requested.  When it
-      is not known whether or not the environment can handle the non-ACE
-      form, the application MAY use the non-ACE form (which might fail,
-      such as by not being displayed properly), or it MAY use the ACE
-      form (which will look unintelligle to the user).  Given an
-      internationalized domain name, an equivalent domain name
-      containing no ACE labels can be obtained by applying the ToUnicode
-      operation (see section 4) to each label.  When requirements 2 and
-      3 both apply, requirement 2 takes precedence.
-
-   4) Whenever two labels are compared, they MUST be considered to match
-      if and only if they are equivalent, that is, their ASCII forms
-      (obtained by applying ToASCII) match using a case-insensitive
-      ASCII comparison.  Whenever two names are compared, they MUST be
-      considered to match if and only if their corresponding labels
-      match, regardless of whether the names use the same forms of label
-      separators.
-
-3.2 Applicability
-
-   IDNA is applicable to all domain names in all domain name slots
-   except where it is explicitly excluded.
-
-   This implies that IDNA is applicable to many protocols that predate
-   IDNA.  Note that IDNs occupying domain name slots in those protocols
-   MUST be in ASCII form (see section 3.1, requirement 2).
-
-3.2.1. DNS resource records
-
-   IDNA does not apply to domain names in the NAME and RDATA fields of
-   DNS resource records whose CLASS is not IN.  This exclusion applies
-   to every non-IN class, present and future, except where future
-   standards override this exclusion by explicitly inviting the use of
-   IDNA.
-
-   There are currently no other exclusions on the applicability of IDNA
-   to DNS resource records; it depends entirely on the CLASS, and not on
-   the TYPE.  This will remain true, even as new types are defined,
-   unless there is a compelling reason for a new type to complicate
-   matters by imposing type-specific rules.
-
-
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 8]
-
-RFC 3490                          IDNA                        March 2003
-
-
-3.2.2. Non-domain-name data types stored in domain names
-
-   Although IDNA enables the representation of non-ASCII characters in
-   domain names, that does not imply that IDNA enables the
-   representation of non-ASCII characters in other data types that are
-   stored in domain names.  For example, an email address local part is
-   sometimes stored in a domain label (hostmaster@example.com would be
-   represented as hostmaster.example.com in the RDATA field of an SOA
-   record).  IDNA does not update the existing email standards, which
-   allow only ASCII characters in local parts.  Therefore, unless the
-   email standards are revised to invite the use of IDNA for local
-   parts, a domain label that holds the local part of an email address
-   SHOULD NOT begin with the ACE prefix, and even if it does, it is to
-   be interpreted literally as a local part that happens to begin with
-   the ACE prefix.
-
-4. Conversion operations
-
-   An application converts a domain name put into an IDN-unaware slot or
-   displayed to a user.  This section specifies the steps to perform in
-   the conversion, and the ToASCII and ToUnicode operations.
-
-   The input to ToASCII or ToUnicode is a single label that is a
-   sequence of Unicode code points (remember that all ASCII code points
-   are also Unicode code points).  If a domain name is represented using
-   a character set other than Unicode or US-ASCII, it will first need to
-   be transcoded to Unicode.
-
-   Starting from a whole domain name, the steps that an application
-   takes to do the conversions are:
-
-   1) Decide whether the domain name is a "stored string" or a "query
-      string" as described in [STRINGPREP].  If this conversion follows
-      the "queries" rule from [STRINGPREP], set the flag called
-      "AllowUnassigned".
-
-   2) Split the domain name into individual labels as described in
-      section 3.1.  The labels do not include the separator.
-
-   3) For each label, decide whether or not to enforce the restrictions
-      on ASCII characters in host names [STD3].  (Applications already
-      faced this choice before the introduction of IDNA, and can
-      continue to make the decision the same way they always have; IDNA
-      makes no new recommendations regarding this choice.)  If the
-      restrictions are to be enforced, set the flag called
-      "UseSTD3ASCIIRules" for that label.
-
-
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 9]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   4) Process each label with either the ToASCII or the ToUnicode
-      operation as appropriate.  Typically, you use the ToASCII
-      operation if you are about to put the name into an IDN-unaware
-      slot, and you use the ToUnicode operation if you are displaying
-      the name to a user; section 3.1 gives greater detail on the
-      applicable requirements.
-
-   5) If ToASCII was applied in step 4 and dots are used as label
-      separators, change all the label separators to U+002E (full stop).
-
-   The following two subsections define the ToASCII and ToUnicode
-   operations that are used in step 4.
-
-   This description of the protocol uses specific procedure names, names
-   of flags, and so on, in order to facilitate the specification of the
-   protocol.  These names, as well as the actual steps of the
-   procedures, are not required of an implementation.  In fact, any
-   implementation which has the same external behavior as specified in
-   this document conforms to this specification.
-
-4.1 ToASCII
-
-   The ToASCII operation takes a sequence of Unicode code points that
-   make up one label and transforms it into a sequence of code points in
-   the ASCII range (0..7F).  If ToASCII succeeds, the original sequence
-   and the resulting sequence are equivalent labels.
-
-   It is important to note that the ToASCII operation can fail.  ToASCII
-   fails if any step of it fails.  If any step of the ToASCII operation
-   fails on any label in a domain name, that domain name MUST NOT be
-   used as an internationalized domain name.  The method for dealing
-   with this failure is application-specific.
-
-   The inputs to ToASCII are a sequence of code points, the
-   AllowUnassigned flag, and the UseSTD3ASCIIRules flag.  The output of
-   ToASCII is either a sequence of ASCII code points or a failure
-   condition.
-
-   ToASCII never alters a sequence of code points that are all in the
-   ASCII range to begin with (although it could fail).  Applying the
-   ToASCII operation multiple times has exactly the same effect as
-   applying it just once.
-
-   ToASCII consists of the following steps:
-
-   1. If the sequence contains any code points outside the ASCII range
-      (0..7F) then proceed to step 2, otherwise skip to step 3.
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 10]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   2. Perform the steps specified in [NAMEPREP] and fail if there is an
-      error.  The AllowUnassigned flag is used in [NAMEPREP].
-
-   3. If the UseSTD3ASCIIRules flag is set, then perform these checks:
-
-     (a) Verify the absence of non-LDH ASCII code points; that is, the
-         absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F.
-
-     (b) Verify the absence of leading and trailing hyphen-minus; that
-         is, the absence of U+002D at the beginning and end of the
-         sequence.
-
-   4. If the sequence contains any code points outside the ASCII range
-      (0..7F) then proceed to step 5, otherwise skip to step 8.
-
-   5. Verify that the sequence does NOT begin with the ACE prefix.
-
-   6. Encode the sequence using the encoding algorithm in [PUNYCODE] and
-      fail if there is an error.
-
-   7. Prepend the ACE prefix.
-
-   8. Verify that the number of code points is in the range 1 to 63
-      inclusive.
-
-4.2 ToUnicode
-
-   The ToUnicode operation takes a sequence of Unicode code points that
-   make up one label and returns a sequence of Unicode code points.  If
-   the input sequence is a label in ACE form, then the result is an
-   equivalent internationalized label that is not in ACE form, otherwise
-   the original sequence is returned unaltered.
-
-   ToUnicode never fails.  If any step fails, then the original input
-   sequence is returned immediately in that step.
-
-   The ToUnicode output never contains more code points than its input.
-   Note that the number of octets needed to represent a sequence of code
-   points depends on the particular character encoding used.
-
-   The inputs to ToUnicode are a sequence of code points, the
-   AllowUnassigned flag, and the UseSTD3ASCIIRules flag.  The output of
-   ToUnicode is always a sequence of Unicode code points.
-
-   1. If all code points in the sequence are in the ASCII range (0..7F)
-      then skip to step 3.
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 11]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   2. Perform the steps specified in [NAMEPREP] and fail if there is an
-      error.  (If step 3 of ToASCII is also performed here, it will not
-      affect the overall behavior of ToUnicode, but it is not
-      necessary.)  The AllowUnassigned flag is used in [NAMEPREP].
-
-   3. Verify that the sequence begins with the ACE prefix, and save a
-      copy of the sequence.
-
-   4. Remove the ACE prefix.
-
-   5. Decode the sequence using the decoding algorithm in [PUNYCODE] and
-      fail if there is an error.  Save a copy of the result of this
-      step.
-
-   6. Apply ToASCII.
-
-   7. Verify that the result of step 6 matches the saved copy from step
-      3, using a case-insensitive ASCII comparison.
-
-   8. Return the saved copy from step 5.
-
-5. ACE prefix
-
-   The ACE prefix, used in the conversion operations (section 4), is two
-   alphanumeric ASCII characters followed by two hyphen-minuses.  It
-   cannot be any of the prefixes already used in earlier documents,
-   which includes the following: "bl--", "bq--", "dq--", "lq--", "mq--",
-   "ra--", "wq--" and "zq--".  The ToASCII and ToUnicode operations MUST
-   recognize the ACE prefix in a case-insensitive manner.
-
-   The ACE prefix for IDNA is "xn--" or any capitalization thereof.
-
-   This means that an ACE label might be "xn--de-jg4avhby1noc0d", where
-   "de-jg4avhby1noc0d" is the part of the ACE label that is generated by
-   the encoding steps in [PUNYCODE].
-
-   While all ACE labels begin with the ACE prefix, not all labels
-   beginning with the ACE prefix are necessarily ACE labels.  Non-ACE
-   labels that begin with the ACE prefix will confuse users and SHOULD
-   NOT be allowed in DNS zones.
-
-
-
-
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 12]
-
-RFC 3490                          IDNA                        March 2003
-
-
-6. Implications for typical applications using DNS
-
-   In IDNA, applications perform the processing needed to input
-   internationalized domain names from users, display internationalized
-   domain names to users, and process the inputs and outputs from DNS
-   and other protocols that carry domain names.
-
-   The components and interfaces between them can be represented
-   pictorially as:
-
-                    +------+
-                    | User |
-                    +------+
-                       ^
-                       | Input and display: local interface methods
-                       | (pen, keyboard, glowing phosphorus, ...)
-   +-------------------|-------------------------------+
-   |                   v                               |
-   |          +-----------------------------+          |
-   |          |        Application          |          |
-   |          |   (ToASCII and ToUnicode    |          |
-   |          |      operations may be      |          |
-   |          |        called here)         |          |
-   |          +-----------------------------+          |
-   |                   ^        ^                      | End system
-   |                   |        |                      |
-   | Call to resolver: |        | Application-specific |
-   |              ACE  |        | protocol:            |
-   |                   v        | ACE unless the       |
-   |           +----------+     | protocol is updated  |
-   |           | Resolver |     | to handle other      |
-   |           +----------+     | encodings            |
-   |                 ^          |                      |
-   +-----------------|----------|----------------------+
-       DNS protocol: |          |
-                 ACE |          |
-                     v          v
-          +-------------+    +---------------------+
-          | DNS servers |    | Application servers |
-          +-------------+    +---------------------+
-
-   The box labeled "Application" is where the application splits a
-   domain name into labels, sets the appropriate flags, and performs the
-   ToASCII and ToUnicode operations.  This is described in section 4.
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 13]
-
-RFC 3490                          IDNA                        March 2003
-
-
-6.1 Entry and display in applications
-
-   Applications can accept domain names using any character set or sets
-   desired by the application developer, and can display domain names in
-   any charset.  That is, the IDNA protocol does not affect the
-   interface between users and applications.
-
-   An IDNA-aware application can accept and display internationalized
-   domain names in two formats: the internationalized character set(s)
-   supported by the application, and as an ACE label.  ACE labels that
-   are displayed or input MUST always include the ACE prefix.
-   Applications MAY allow input and display of ACE labels, but are not
-   encouraged to do so except as an interface for special purposes,
-   possibly for debugging, or to cope with display limitations as
-   described in section 6.4..  ACE encoding is opaque and ugly, and
-   should thus only be exposed to users who absolutely need it.  Because
-   name labels encoded as ACE name labels can be rendered either as the
-   encoded ASCII characters or the proper decoded characters, the
-   application MAY have an option for the user to select the preferred
-   method of display; if it does, rendering the ACE SHOULD NOT be the
-   default.
-
-   Domain names are often stored and transported in many places.  For
-   example, they are part of documents such as mail messages and web
-   pages.  They are transported in many parts of many protocols, such as
-   both the control commands and the RFC 2822 body parts of SMTP, and
-   the headers and the body content in HTTP.  It is important to
-   remember that domain names appear both in domain name slots and in
-   the content that is passed over protocols.
-
-   In protocols and document formats that define how to handle
-   specification or negotiation of charsets, labels can be encoded in
-   any charset allowed by the protocol or document format.  If a
-   protocol or document format only allows one charset, the labels MUST
-   be given in that charset.
-
-   In any place where a protocol or document format allows transmission
-   of the characters in internationalized labels, internationalized
-   labels SHOULD be transmitted using whatever character encoding and
-   escape mechanism that the protocol or document format uses at that
-   place.
-
-   All protocols that use domain name slots already have the capacity
-   for handling domain names in the ASCII charset.  Thus, ACE labels
-   (internationalized labels that have been processed with the ToASCII
-   operation) can inherently be handled by those protocols.
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 14]
-
-RFC 3490                          IDNA                        March 2003
-
-
-6.2 Applications and resolver libraries
-
-   Applications normally use functions in the operating system when they
-   resolve DNS queries.  Those functions in the operating system are
-   often called "the resolver library", and the applications communicate
-   with the resolver libraries through a programming interface (API).
-
-   Because these resolver libraries today expect only domain names in
-   ASCII, applications MUST prepare labels that are passed to the
-   resolver library using the ToASCII operation.  Labels received from
-   the resolver library contain only ASCII characters; internationalized
-   labels that cannot be represented directly in ASCII use the ACE form.
-   ACE labels always include the ACE prefix.
-
-   An operating system might have a set of libraries for performing the
-   ToASCII operation.  The input to such a library might be in one or
-   more charsets that are used in applications (UTF-8 and UTF-16 are
-   likely candidates for almost any operating system, and script-
-   specific charsets are likely for localized operating systems).
-
-   IDNA-aware applications MUST be able to work with both non-
-   internationalized labels (those that conform to [STD13] and [STD3])
-   and internationalized labels.
-
-   It is expected that new versions of the resolver libraries in the
-   future will be able to accept domain names in other charsets than
-   ASCII, and application developers might one day pass not only domain
-   names in Unicode, but also in local script to a new API for the
-   resolver libraries in the operating system.  Thus the ToASCII and
-   ToUnicode operations might be performed inside these new versions of
-   the resolver libraries.
-
-   Domain names passed to resolvers or put into the question section of
-   DNS requests follow the rules for "queries" from [STRINGPREP].
-
-6.3 DNS servers
-
-   Domain names stored in zones follow the rules for "stored strings"
-   from [STRINGPREP].
-
-   For internationalized labels that cannot be represented directly in
-   ASCII, DNS servers MUST use the ACE form produced by the ToASCII
-   operation.  All IDNs served by DNS servers MUST contain only ASCII
-   characters.
-
-   If a signaling system which makes negotiation possible between old
-   and new DNS clients and servers is standardized in the future, the
-   encoding of the query in the DNS protocol itself can be changed from
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 15]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   ACE to something else, such as UTF-8.  The question whether or not
-   this should be used is, however, a separate problem and is not
-   discussed in this memo.
-
-6.4 Avoiding exposing users to the raw ACE encoding
-
-   Any application that might show the user a domain name obtained from
-   a domain name slot, such as from gethostbyaddr or part of a mail
-   header, will need to be updated if it is to prevent users from seeing
-   the ACE.
-
-   If an application decodes an ACE name using ToUnicode but cannot show
-   all of the characters in the decoded name, such as if the name
-   contains characters that the output system cannot display, the
-   application SHOULD show the name in ACE format (which always includes
-   the ACE prefix) instead of displaying the name with the replacement
-   character (U+FFFD).  This is to make it easier for the user to
-   transfer the name correctly to other programs.  Programs that by
-   default show the ACE form when they cannot show all the characters in
-   a name label SHOULD also have a mechanism to show the name that is
-   produced by the ToUnicode operation with as many characters as
-   possible and replacement characters in the positions where characters
-   cannot be displayed.
-
-   The ToUnicode operation does not alter labels that are not valid ACE
-   labels, even if they begin with the ACE prefix.  After ToUnicode has
-   been applied, if a label still begins with the ACE prefix, then it is
-   not a valid ACE label, and is not equivalent to any of the
-   intermediate Unicode strings constructed by ToUnicode.
-
-6.5  DNSSEC authentication of IDN domain names
-
-   DNS Security [RFC2535] is a method for supplying cryptographic
-   verification information along with DNS messages.  Public Key
-   Cryptography is used in conjunction with digital signatures to
-   provide a means for a requester of domain information to authenticate
-   the source of the data.  This ensures that it can be traced back to a
-   trusted source, either directly, or via a chain of trust linking the
-   source of the information to the top of the DNS hierarchy.
-
-   IDNA specifies that all internationalized domain names served by DNS
-   servers that cannot be represented directly in ASCII must use the ACE
-   form produced by the ToASCII operation.  This operation must be
-   performed prior to a zone being signed by the private key for that
-   zone.  Because of this ordering, it is important to recognize that
-   DNSSEC authenticates the ASCII domain name, not the Unicode form or
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 16]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   the mapping between the Unicode form and the ASCII form.  In the
-   presence of DNSSEC, this is the name that MUST be signed in the zone
-   and MUST be validated against.
-
-   One consequence of this for sites deploying IDNA in the presence of
-   DNSSEC is that any special purpose proxies or forwarders used to
-   transform user input into IDNs must be earlier in the resolution flow
-   than DNSSEC authenticating nameservers for DNSSEC to work.
-
-7. Name server considerations
-
-   Existing DNS servers do not know the IDNA rules for handling non-
-   ASCII forms of IDNs, and therefore need to be shielded from them.
-   All existing channels through which names can enter a DNS server
-   database (for example, master files [STD13] and DNS update messages
-   [RFC2136]) are IDN-unaware because they predate IDNA, and therefore
-   requirement 2 of section 3.1 of this document provides the needed
-   shielding, by ensuring that internationalized domain names entering
-   DNS server databases through such channels have already been
-   converted to their equivalent ASCII forms.
-
-   It is imperative that there be only one ASCII encoding for a
-   particular domain name.  Because of the design of the ToASCII and
-   ToUnicode operations, there are no ACE labels that decode to ASCII
-   labels, and therefore name servers cannot contain multiple ASCII
-   encodings of the same domain name.
-
-   [RFC2181] explicitly allows domain labels to contain octets beyond
-   the ASCII range (0..7F), and this document does not change that.
-   Note, however, that there is no defined interpretation of octets
-   80..FF as characters.  If labels containing these octets are returned
-   to applications, unpredictable behavior could result.  The ASCII form
-   defined by ToASCII is the only standard representation for
-   internationalized labels in the current DNS protocol.
-
-8. Root server considerations
-
-   IDNs are likely to be somewhat longer than current domain names, so
-   the bandwidth needed by the root servers is likely to go up by a
-   small amount.  Also, queries and responses for IDNs will probably be
-   somewhat longer than typical queries today, so more queries and
-   responses may be forced to go to TCP instead of UDP.
-
-
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 17]
-
-RFC 3490                          IDNA                        March 2003
-
-
-9. References
-
-9.1 Normative References
-
-   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
-                Internationalized Strings ("stringprep")", RFC 3454,
-                December 2002.
-
-   [NAMEPREP]   Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
-                Profile for Internationalized Domain Names (IDN)", RFC
-                3491, March 2003.
-
-   [PUNYCODE]   Costello, A., "Punycode: A Bootstring encoding of
-                Unicode for use with Internationalized Domain Names in
-                Applications (IDNA)", RFC 3492, March 2003.
-
-   [STD3]       Braden, R., "Requirements for Internet Hosts --
-                Communication Layers", STD 3, RFC 1122, and
-                "Requirements for Internet Hosts -- Application and
-                Support", STD 3, RFC 1123, October 1989.
-
-   [STD13]      Mockapetris, P., "Domain names - concepts and
-                facilities", STD 13, RFC 1034 and "Domain names -
-                implementation and specification", STD 13, RFC 1035,
-                November 1987.
-
-9.2 Informative References
-
-   [RFC2535]    Eastlake, D., "Domain Name System Security Extensions",
-                RFC 2535, March 1999.
-
-   [RFC2181]    Elz, R. and R. Bush, "Clarifications to the DNS
-                Specification", RFC 2181, July 1997.
-
-   [UAX9]       Unicode Standard Annex #9, The Bidirectional Algorithm,
-                <http://www.unicode.org/unicode/reports/tr9/>.
-
-   [UNICODE]    The Unicode Consortium. The Unicode Standard, Version
-                3.2.0 is defined by The Unicode Standard, Version 3.0
-                (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
-                as amended by the Unicode Standard Annex #27: Unicode
-                3.1 (http://www.unicode.org/reports/tr27/) and by the
-                Unicode Standard Annex #28: Unicode 3.2
-                (http://www.unicode.org/reports/tr28/).
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 18]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   [USASCII]    Cerf, V., "ASCII format for Network Interchange", RFC
-                20, October 1969.
-
-10. Security Considerations
-
-   Security on the Internet partly relies on the DNS.  Thus, any change
-   to the characteristics of the DNS can change the security of much of
-   the Internet.
-
-   This memo describes an algorithm which encodes characters that are
-   not valid according to STD3 and STD13 into octet values that are
-   valid.  No security issues such as string length increases or new
-   allowed values are introduced by the encoding process or the use of
-   these encoded values, apart from those introduced by the ACE encoding
-   itself.
-
-   Domain names are used by users to identify and connect to Internet
-   servers.  The security of the Internet is compromised if a user
-   entering a single internationalized name is connected to different
-   servers based on different interpretations of the internationalized
-   domain name.
-
-   When systems use local character sets other than ASCII and Unicode,
-   this specification leaves the the problem of transcoding between the
-   local character set and Unicode up to the application.  If different
-   applications (or different versions of one application) implement
-   different transcoding rules, they could interpret the same name
-   differently and contact different servers.  This problem is not
-   solved by security protocols like TLS that do not take local
-   character sets into account.
-
-   Because this document normatively refers to [NAMEPREP], [PUNYCODE],
-   and [STRINGPREP], it includes the security considerations from those
-   documents as well.
-
-   If or when this specification is updated to use a more recent Unicode
-   normalization table, the new normalization table will need to be
-   compared with the old to spot backwards incompatible changes.  If
-   there are such changes, they will need to be handled somehow, or
-   there will be security as well as operational implications.  Methods
-   to handle the conflicts could include keeping the old normalization,
-   or taking care of the conflicting characters by operational means, or
-   some other method.
-
-   Implementations MUST NOT use more recent normalization tables than
-   the one referenced from this document, even though more recent tables
-   may be provided by operating systems.  If an application is unsure of
-   which version of the normalization tables are in the operating
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 19]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   system, the application needs to include the normalization tables
-   itself.  Using normalization tables other than the one referenced
-   from this specification could have security and operational
-   implications.
-
-   To help prevent confusion between characters that are visually
-   similar, it is suggested that implementations provide visual
-   indications where a domain name contains multiple scripts.  Such
-   mechanisms can also be used to show when a name contains a mixture of
-   simplified and traditional Chinese characters, or to distinguish zero
-   and one from O and l.  DNS zone adminstrators may impose restrictions
-   (subject to the limitations in section 2) that try to minimize
-   homographs.
-
-   Domain names (or portions of them) are sometimes compared against a
-   set of privileged or anti-privileged domains.  In such situations it
-   is especially important that the comparisons be done properly, as
-   specified in section 3.1 requirement 4.  For labels already in ASCII
-   form, the proper comparison reduces to the same case-insensitive
-   ASCII comparison that has always been used for ASCII labels.
-
-   The introduction of IDNA means that any existing labels that start
-   with the ACE prefix and would be altered by ToUnicode will
-   automatically be ACE labels, and will be considered equivalent to
-   non-ASCII labels, whether or not that was the intent of the zone
-   adminstrator or registrant.
-
-11. IANA Considerations
-
-   IANA has assigned the ACE prefix in consultation with the IESG.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 20]
-
-RFC 3490                          IDNA                        March 2003
-
-
-12. Authors' Addresses
-
-   Patrik Faltstrom
-   Cisco Systems
-   Arstaangsvagen 31 J
-   S-117 43 Stockholm  Sweden
-
-   EMail: paf@cisco.com
-
-
-   Paul Hoffman
-   Internet Mail Consortium and VPN Consortium
-   127 Segre Place
-   Santa Cruz, CA  95060  USA
-
-   EMail: phoffman@imc.org
-
-
-   Adam M. Costello
-   University of California, Berkeley
-
-   URL: http://www.nicemice.net/amc/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 21]
-
-RFC 3490                          IDNA                        March 2003
-
-
-13. 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 22]
-
diff --git a/contrib/bind9/doc/rfc/rfc3491.txt b/contrib/bind9/doc/rfc/rfc3491.txt
deleted file mode 100644
index dbc86c7..0000000
--- a/contrib/bind9/doc/rfc/rfc3491.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         P. Hoffman
-Request for Comments: 3491                                    IMC & VPNC
-Category: Standards Track                                    M. Blanchet
-                                                                Viagenie
-                                                              March 2003
-
-
-                   Nameprep: A Stringprep Profile for
-                  Internationalized Domain Names (IDN)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   This document describes how to prepare internationalized domain name
-   (IDN) labels in order to increase the likelihood that name input and
-   name comparison work in ways that make sense for typical users
-   throughout the world.  This profile of the stringprep protocol is
-   used as part of a suite of on-the-wire protocols for
-   internationalizing the Domain Name System (DNS).
-
-1. Introduction
-
-   This document specifies processing rules that will allow users to
-   enter internationalized domain names (IDNs) into applications and
-   have the highest chance of getting the content of the strings
-   correct.  It is a profile of stringprep [STRINGPREP].  These
-   processing rules are only intended for internationalized domain
-   names, not for arbitrary text.
-
-   This profile defines the following, as required by [STRINGPREP].
-
-   -  The intended applicability of the profile: internationalized
-      domain names processed by IDNA.
-
-   -  The character repertoire that is the input and output to
-      stringprep:  Unicode 3.2, specified in section 2.
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 1]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-   -  The mappings used: specified in section 3.
-
-   -  The Unicode normalization used: specified in section 4.
-
-   -  The characters that are prohibited as output: specified in section
-      5.
-
-   -  Bidirectional character handling: specified in section 6.
-
-1.1 Interaction of protocol parts
-
-   Nameprep is used by the IDNA [IDNA] protocol for preparing domain
-   names; it is not designed for any other purpose.  It is explicitly
-   not designed for processing arbitrary free text and SHOULD NOT be
-   used for that purpose.  Nameprep is a profile of Stringprep
-   [STRINGPREP].  Implementations of Nameprep MUST fully implement
-   Stringprep.
-
-   Nameprep is used to process domain name labels, not domain names.
-   IDNA calls nameprep for each label in a domain name, not for the
-   whole domain name.
-
-1.2 Terminology
-
-   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
-   in this document are to be interpreted as described in BCP 14, RFC
-   2119 [RFC2119].
-
-2. Character Repertoire
-
-   This profile uses Unicode 3.2, as defined in [STRINGPREP] Appendix A.
-
-3. Mapping
-
-   This profile specifies mapping using the following tables from
-   [STRINGPREP]:
-
-   Table B.1
-   Table B.2
-
-4. Normalization
-
-   This profile specifies using Unicode normalization form KC, as
-   described in [STRINGPREP].
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 2]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-5. Prohibited Output
-
-   This profile specifies prohibiting using the following tables from
-   [STRINGPREP]:
-
-   Table C.1.2
-   Table C.2.2
-   Table C.3
-   Table C.4
-   Table C.5
-   Table C.6
-   Table C.7
-   Table C.8
-   Table C.9
-
-   IMPORTANT NOTE: This profile MUST be used with the IDNA protocol.
-   The IDNA protocol has additional prohibitions that are checked
-   outside of this profile.
-
-6. Bidirectional characters
-
-   This profile specifies checking bidirectional strings as described in
-   [STRINGPREP] section 6.
-
-7. Unassigned Code Points in Internationalized Domain Names
-
-   If the processing in [IDNA] specifies that a list of unassigned code
-   points be used, the system uses table A.1 from [STRINGPREP] as its
-   list of unassigned code points.
-
-8. References
-
-8.1 Normative References
-
-   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
-                Internationalized Strings ("stringprep")", RFC 3454,
-                December 2002.
-
-   [IDNA]       Faltstrom, P., Hoffman, P. and A. Costello,
-                "Internationalizing Domain Names in Applications
-                (IDNA)", RFC 3490, March 2003.
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 3]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-8.2 Informative references
-
-   [STD13]      Mockapetris, P., "Domain names - concepts and
-                facilities", STD 13, RFC 1034, and "Domain names -
-                implementation and specification", STD 13, RFC 1035,
-                November 1987.
-
-9. Security Considerations
-
-   The Unicode and ISO/IEC 10646 repertoires have many characters that
-   look similar.  In many cases, users of security protocols might do
-   visual matching, such as when comparing the names of trusted third
-   parties.  Because it is impossible to map similar-looking characters
-   without a great deal of context such as knowing the fonts used,
-   stringprep does nothing to map similar-looking characters together
-   nor to prohibit some characters because they look like others.
-
-   Security on the Internet partly relies on the DNS.  Thus, any change
-   to the characteristics of the DNS can change the security of much of
-   the Internet.
-
-   Domain names are used by users to connect to Internet servers.  The
-   security of the Internet would be compromised if a user entering a
-   single internationalized name could be connected to different servers
-   based on different interpretations of the internationalized domain
-   name.
-
-   Current applications might assume that the characters allowed in
-   domain names will always be the same as they are in [STD13].  This
-   document vastly increases the number of characters available in
-   domain names.  Every program that uses "special" characters in
-   conjunction with domain names may be vulnerable to attack based on
-   the new characters allowed by this specification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 4]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-10. IANA Considerations
-
-   This is a profile of stringprep.  It has been registered by the IANA
-   in the stringprep profile registry
-   (www.iana.org/assignments/stringprep-profiles).
-
-      Name of this profile:
-         Nameprep
-
-      RFC in which the profile is defined:
-         This document.
-
-      Indicator whether or not this is the newest version of the
-      profile:
-         This is the first version of Nameprep.
-
-11. Acknowledgements
-
-   Many people from the IETF IDN Working Group and the Unicode Technical
-   Committee contributed ideas that went into this document.
-
-   The IDN Nameprep design team made many useful changes to the
-   document.  That team and its advisors include:
-
-      Asmus Freytag
-      Cathy Wissink
-      Francois Yergeau
-      James Seng
-      Marc Blanchet
-      Mark Davis
-      Martin Duerst
-      Patrik Faltstrom
-      Paul Hoffman
-
-   Additional significant improvements were proposed by:
-
-      Jonathan Rosenne
-      Kent Karlsson
-      Scott Hollenbeck
-      Dave Crocker
-      Erik Nordmark
-      Matitiahu Allouche
-
-
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 5]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-12. Authors' Addresses
-
-   Paul Hoffman
-   Internet Mail Consortium and VPN Consortium
-   127 Segre Place
-   Santa Cruz, CA  95060 USA
-
-   EMail: paul.hoffman@imc.org and paul.hoffman@vpnc.org
-
-
-   Marc Blanchet
-   Viagenie inc.
-   2875 boul. Laurier, bur. 300
-   Ste-Foy, Quebec, Canada, G1V 2M2
-
-   EMail: Marc.Blanchet@viagenie.qc.ca
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 6]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-13.  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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc3492.txt b/contrib/bind9/doc/rfc/rfc3492.txt
deleted file mode 100644
index e72ad81..0000000
--- a/contrib/bind9/doc/rfc/rfc3492.txt
+++ /dev/null
@@ -1,1963 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        A. Costello
-Request for Comments: 3492                 Univ. of California, Berkeley
-Category: Standards Track                                     March 2003
-
-
-              Punycode: A Bootstring encoding of Unicode
-       for Internationalized Domain Names in Applications (IDNA)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   Punycode is a simple and efficient transfer encoding syntax designed
-   for use with Internationalized Domain Names in Applications (IDNA).
-   It uniquely and reversibly transforms a Unicode string into an ASCII
-   string.  ASCII characters in the Unicode string are represented
-   literally, and non-ASCII characters are represented by ASCII
-   characters that are allowed in host name labels (letters, digits, and
-   hyphens).  This document defines a general algorithm called
-   Bootstring that allows a string of basic code points to uniquely
-   represent any string of code points drawn from a larger set.
-   Punycode is an instance of Bootstring that uses particular parameter
-   values specified by this document, appropriate for IDNA.
-
-Table of Contents
-
-   1. Introduction...............................................2
-       1.1 Features..............................................2
-       1.2 Interaction of protocol parts.........................3
-   2. Terminology................................................3
-   3. Bootstring description.....................................4
-       3.1 Basic code point segregation..........................4
-       3.2 Insertion unsort coding...............................4
-       3.3 Generalized variable-length integers..................5
-       3.4 Bias adaptation.......................................7
-   4. Bootstring parameters......................................8
-   5. Parameter values for Punycode..............................8
-   6. Bootstring algorithms......................................9
-
-
-
-Costello                    Standards Track                     [Page 1]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-       6.1 Bias adaptation function.............................10
-       6.2 Decoding procedure...................................11
-       6.3 Encoding procedure...................................12
-       6.4 Overflow handling....................................13
-   7. Punycode examples.........................................14
-       7.1 Sample strings.......................................14
-       7.2 Decoding traces......................................17
-       7.3 Encoding traces......................................19
-   8. Security Considerations...................................20
-   9. References................................................21
-       9.1 Normative References.................................21
-       9.2 Informative References...............................21
-   A. Mixed-case annotation.....................................22
-   B. Disclaimer and license....................................22
-   C. Punycode sample implementation............................23
-   Author's Address.............................................34
-   Full Copyright Statement.....................................35
-
-1. Introduction
-
-   [IDNA] describes an architecture for supporting internationalized
-   domain names.  Labels containing non-ASCII characters can be
-   represented by ACE labels, which begin with a special ACE prefix and
-   contain only ASCII characters.  The remainder of the label after the
-   prefix is a Punycode encoding of a Unicode string satisfying certain
-   constraints.  For the details of the prefix and constraints, see
-   [IDNA] and [NAMEPREP].
-
-   Punycode is an instance of a more general algorithm called
-   Bootstring, which allows strings composed from a small set of "basic"
-   code points to uniquely represent any string of code points drawn
-   from a larger set.  Punycode is Bootstring with particular parameter
-   values appropriate for IDNA.
-
-1.1 Features
-
-   Bootstring has been designed to have the following features:
-
-   *  Completeness:  Every extended string (sequence of arbitrary code
-      points) can be represented by a basic string (sequence of basic
-      code points).  Restrictions on what strings are allowed, and on
-      length, can be imposed by higher layers.
-
-   *  Uniqueness:  There is at most one basic string that represents a
-      given extended string.
-
-   *  Reversibility:  Any extended string mapped to a basic string can
-      be recovered from that basic string.
-
-
-
-Costello                    Standards Track                     [Page 2]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   *  Efficient encoding:  The ratio of basic string length to extended
-      string length is small.  This is important in the context of
-      domain names because RFC 1034 [RFC1034] restricts the length of a
-      domain label to 63 characters.
-
-   *  Simplicity:  The encoding and decoding algorithms are reasonably
-      simple to implement.  The goals of efficiency and simplicity are
-      at odds; Bootstring aims at a good balance between them.
-
-   *  Readability:  Basic code points appearing in the extended string
-      are represented as themselves in the basic string (although the
-      main purpose is to improve efficiency, not readability).
-
-   Punycode can also support an additional feature that is not used by
-   the ToASCII and ToUnicode operations of [IDNA].  When extended
-   strings are case-folded prior to encoding, the basic string can use
-   mixed case to tell how to convert the folded string into a mixed-case
-   string.  See appendix A "Mixed-case annotation".
-
-1.2 Interaction of protocol parts
-
-   Punycode is used by the IDNA protocol [IDNA] for converting domain
-   labels into ASCII; it is not designed for any other purpose.  It is
-   explicitly not designed for processing arbitrary free text.
-
-2. 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 BCP 14, RFC 2119
-   [RFC2119].
-
-   A code point is an integral value associated with a character in a
-   coded character set.
-
-   As in the Unicode Standard [UNICODE], Unicode code points are denoted
-   by "U+" followed by four to six hexadecimal digits, while a range of
-   code points is denoted by two hexadecimal numbers separated by "..",
-   with no prefixes.
-
-   The operators div and mod perform integer division; (x div y) is the
-   quotient of x divided by y, discarding the remainder, and (x mod y)
-   is the remainder, so (x div y) * y + (x mod y) == x.  Bootstring uses
-   these operators only with nonnegative operands, so the quotient and
-   remainder are always nonnegative.
-
-   The break statement jumps out of the innermost loop (as in C).
-
-
-
-
-Costello                    Standards Track                     [Page 3]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   An overflow is an attempt to compute a value that exceeds the maximum
-   value of an integer variable.
-
-3. Bootstring description
-
-   Bootstring represents an arbitrary sequence of code points (the
-   "extended string") as a sequence of basic code points (the "basic
-   string").  This section describes the representation.  Section 6
-   "Bootstring algorithms" presents the algorithms as pseudocode.
-   Sections 7.1 "Decoding traces" and 7.2 "Encoding traces" trace the
-   algorithms for sample inputs.
-
-   The following sections describe the four techniques used in
-   Bootstring.  "Basic code point segregation" is a very simple and
-   efficient encoding for basic code points occurring in the extended
-   string: they are simply copied all at once.  "Insertion unsort
-   coding" encodes the non-basic code points as deltas, and processes
-   the code points in numerical order rather than in order of
-   appearance, which typically results in smaller deltas.  The deltas
-   are represented as "generalized variable-length integers", which use
-   basic code points to represent nonnegative integers.  The parameters
-   of this integer representation are dynamically adjusted using "bias
-   adaptation", to improve efficiency when consecutive deltas have
-   similar magnitudes.
-
-3.1 Basic code point segregation
-
-   All basic code points appearing in the extended string are
-   represented literally at the beginning of the basic string, in their
-   original order, followed by a delimiter if (and only if) the number
-   of basic code points is nonzero.  The delimiter is a particular basic
-   code point, which never appears in the remainder of the basic string.
-   The decoder can therefore find the end of the literal portion (if
-   there is one) by scanning for the last delimiter.
-
-3.2 Insertion unsort coding
-
-   The remainder of the basic string (after the last delimiter if there
-   is one) represents a sequence of nonnegative integral deltas as
-   generalized variable-length integers, described in section 3.3.  The
-   meaning of the deltas is best understood in terms of the decoder.
-
-   The decoder builds the extended string incrementally.  Initially, the
-   extended string is a copy of the literal portion of the basic string
-   (excluding the last delimiter).  The decoder inserts non-basic code
-   points, one for each delta, into the extended string, ultimately
-   arriving at the final decoded string.
-
-
-
-
-Costello                    Standards Track                     [Page 4]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   At the heart of this process is a state machine with two state
-   variables: an index i and a counter n.  The index i refers to a
-   position in the extended string; it ranges from 0 (the first
-   position) to the current length of the extended string (which refers
-   to a potential position beyond the current end).  If the current
-   state is <n,i>, the next state is <n,i+1> if i is less than the
-   length of the extended string, or <n+1,0> if i equals the length of
-   the extended string.  In other words, each state change causes i to
-   increment, wrapping around to zero if necessary, and n counts the
-   number of wrap-arounds.
-
-   Notice that the state always advances monotonically (there is no way
-   for the decoder to return to an earlier state).  At each state, an
-   insertion is either performed or not performed.  At most one
-   insertion is performed in a given state.  An insertion inserts the
-   value of n at position i in the extended string.  The deltas are a
-   run-length encoding of this sequence of events: they are the lengths
-   of the runs of non-insertion states preceeding the insertion states.
-   Hence, for each delta, the decoder performs delta state changes, then
-   an insertion, and then one more state change.  (An implementation
-   need not perform each state change individually, but can instead use
-   division and remainder calculations to compute the next insertion
-   state directly.)  It is an error if the inserted code point is a
-   basic code point (because basic code points were supposed to be
-   segregated as described in section 3.1).
-
-   The encoder's main task is to derive the sequence of deltas that will
-   cause the decoder to construct the desired string.  It can do this by
-   repeatedly scanning the extended string for the next code point that
-   the decoder would need to insert, and counting the number of state
-   changes the decoder would need to perform, mindful of the fact that
-   the decoder's extended string will include only those code points
-   that have already been inserted.  Section 6.3 "Encoding procedure"
-   gives a precise algorithm.
-
-3.3 Generalized variable-length integers
-
-   In a conventional integer representation the base is the number of
-   distinct symbols for digits, whose values are 0 through base-1.  Let
-   digit_0 denote the least significant digit, digit_1 the next least
-   significant, and so on.  The value represented is the sum over j of
-   digit_j * w(j), where w(j) = base^j is the weight (scale factor) for
-   position j.  For example, in the base 8 integer 437, the digits are
-   7, 3, and 4, and the weights are 1, 8, and 64, so the value is 7 +
-   3*8 + 4*64 = 287.  This representation has two disadvantages:  First,
-   there are multiple encodings of each value (because there can be
-   extra zeros in the most significant positions), which is inconvenient
-
-
-
-
-Costello                    Standards Track                     [Page 5]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   when unique encodings are needed.  Second, the integer is not self-
-   delimiting, so if multiple integers are concatenated the boundaries
-   between them are lost.
-
-   The generalized variable-length representation solves these two
-   problems.  The digit values are still 0 through base-1, but now the
-   integer is self-delimiting by means of thresholds t(j), each of which
-   is in the range 0 through base-1.  Exactly one digit, the most
-   significant, satisfies digit_j < t(j).  Therefore, if several
-   integers are concatenated, it is easy to separate them, starting with
-   the first if they are little-endian (least significant digit first),
-   or starting with the last if they are big-endian (most significant
-   digit first).  As before, the value is the sum over j of digit_j *
-   w(j), but the weights are different:
-
-      w(0) = 1
-      w(j) = w(j-1) * (base - t(j-1)) for j > 0
-
-   For example, consider the little-endian sequence of base 8 digits
-   734251...  Suppose the thresholds are 2, 3, 5, 5, 5, 5...  This
-   implies that the weights are 1, 1*(8-2) = 6, 6*(8-3) = 30, 30*(8-5) =
-   90, 90*(8-5) = 270, and so on.  7 is not less than 2, and 3 is not
-   less than 3, but 4 is less than 5, so 4 is the last digit.  The value
-   of 734 is 7*1 + 3*6 + 4*30 = 145.  The next integer is 251, with
-   value 2*1 + 5*6 + 1*30 = 62.  Decoding this representation is very
-   similar to decoding a conventional integer:  Start with a current
-   value of N = 0 and a weight w = 1.  Fetch the next digit d and
-   increase N by d * w.  If d is less than the current threshold (t)
-   then stop, otherwise increase w by a factor of (base - t), update t
-   for the next position, and repeat.
-
-   Encoding this representation is similar to encoding a conventional
-   integer:  If N < t then output one digit for N and stop, otherwise
-   output the digit for t + ((N - t) mod (base - t)), then replace N
-   with (N - t) div (base - t), update t for the next position, and
-   repeat.
-
-   For any particular set of values of t(j), there is exactly one
-   generalized variable-length representation of each nonnegative
-   integral value.
-
-   Bootstring uses little-endian ordering so that the deltas can be
-   separated starting with the first.  The t(j) values are defined in
-   terms of the constants base, tmin, and tmax, and a state variable
-   called bias:
-
-      t(j) = base * (j + 1) - bias,
-      clamped to the range tmin through tmax
-
-
-
-Costello                    Standards Track                     [Page 6]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   The clamping means that if the formula yields a value less than tmin
-   or greater than tmax, then t(j) = tmin or tmax, respectively.  (In
-   the pseudocode in section 6 "Bootstring algorithms", the expression
-   base * (j + 1) is denoted by k for performance reasons.)  These t(j)
-   values cause the representation to favor integers within a particular
-   range determined by the bias.
-
-3.4 Bias adaptation
-
-   After each delta is encoded or decoded, bias is set for the next
-   delta as follows:
-
-   1. Delta is scaled in order to avoid overflow in the next step:
-
-         let delta = delta div 2
-
-      But when this is the very first delta, the divisor is not 2, but
-      instead a constant called damp.  This compensates for the fact
-      that the second delta is usually much smaller than the first.
-
-   2. Delta is increased to compensate for the fact that the next delta
-      will be inserting into a longer string:
-
-         let delta = delta + (delta div numpoints)
-
-      numpoints is the total number of code points encoded/decoded so
-      far (including the one corresponding to this delta itself, and
-      including the basic code points).
-
-   3. Delta is repeatedly divided until it falls within a threshold, to
-      predict the minimum number of digits needed to represent the next
-      delta:
-
-         while delta > ((base - tmin) * tmax) div 2
-         do let delta = delta div (base - tmin)
-
-   4. The bias is set:
-
-         let bias =
-           (base * the number of divisions performed in step 3) +
-           (((base - tmin + 1) * delta) div (delta + skew))
-
-      The motivation for this procedure is that the current delta
-      provides a hint about the likely size of the next delta, and so
-      t(j) is set to tmax for the more significant digits starting with
-      the one expected to be last, tmin for the less significant digits
-      up through the one expected to be third-last, and somewhere
-      between tmin and tmax for the digit expected to be second-last
-
-
-
-Costello                    Standards Track                     [Page 7]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-      (balancing the hope of the expected-last digit being unnecessary
-      against the danger of it being insufficient).
-
-4. Bootstring parameters
-
-   Given a set of basic code points, one needs to be designated as the
-   delimiter.  The base cannot be greater than the number of
-   distinguishable basic code points remaining.  The digit-values in the
-   range 0 through base-1 need to be associated with distinct non-
-   delimiter basic code points.  In some cases multiple code points need
-   to have the same digit-value; for example, uppercase and lowercase
-   versions of the same letter need to be equivalent if basic strings
-   are case-insensitive.
-
-   The initial value of n cannot be greater than the minimum non-basic
-   code point that could appear in extended strings.
-
-   The remaining five parameters (tmin, tmax, skew, damp, and the
-   initial value of bias) need to satisfy the following constraints:
-
-      0 <= tmin <= tmax <= base-1
-      skew >= 1
-      damp >= 2
-      initial_bias mod base <= base - tmin
-
-   Provided the constraints are satisfied, these five parameters affect
-   efficiency but not correctness.  They are best chosen empirically.
-
-   If support for mixed-case annotation is desired (see appendix A),
-   make sure that the code points corresponding to 0 through tmax-1 all
-   have both uppercase and lowercase forms.
-
-5. Parameter values for Punycode
-
-   Punycode uses the following Bootstring parameter values:
-
-      base         = 36
-      tmin         = 1
-      tmax         = 26
-      skew         = 38
-      damp         = 700
-      initial_bias = 72
-      initial_n    = 128 = 0x80
-
-   Although the only restriction Punycode imposes on the input integers
-   is that they be nonnegative, these parameters are especially designed
-   to work well with Unicode [UNICODE] code points, which are integers
-   in the range 0..10FFFF (but not D800..DFFF, which are reserved for
-
-
-
-Costello                    Standards Track                     [Page 8]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   use by the UTF-16 encoding of Unicode).  The basic code points are
-   the ASCII [ASCII] code points (0..7F), of which U+002D (-) is the
-   delimiter, and some of the others have digit-values as follows:
-
-      code points    digit-values
-      ------------   ----------------------
-      41..5A (A-Z) =  0 to 25, respectively
-      61..7A (a-z) =  0 to 25, respectively
-      30..39 (0-9) = 26 to 35, respectively
-
-   Using hyphen-minus as the delimiter implies that the encoded string
-   can end with a hyphen-minus only if the Unicode string consists
-   entirely of basic code points, but IDNA forbids such strings from
-   being encoded.  The encoded string can begin with a hyphen-minus, but
-   IDNA prepends a prefix.  Therefore IDNA using Punycode conforms to
-   the RFC 952 rule that host name labels neither begin nor end with a
-   hyphen-minus [RFC952].
-
-   A decoder MUST recognize the letters in both uppercase and lowercase
-   forms (including mixtures of both forms).  An encoder SHOULD output
-   only uppercase forms or only lowercase forms, unless it uses mixed-
-   case annotation (see appendix A).
-
-   Presumably most users will not manually write or type encoded strings
-   (as opposed to cutting and pasting them), but those who do will need
-   to be alert to the potential visual ambiguity between the following
-   sets of characters:
-
-      G 6
-      I l 1
-      O 0
-      S 5
-      U V
-      Z 2
-
-   Such ambiguities are usually resolved by context, but in a Punycode
-   encoded string there is no context apparent to humans.
-
-6. Bootstring algorithms
-
-   Some parts of the pseudocode can be omitted if the parameters satisfy
-   certain conditions (for which Punycode qualifies).  These parts are
-   enclosed in {braces}, and notes immediately following the pseudocode
-   explain the conditions under which they can be omitted.
-
-
-
-
-
-
-
-Costello                    Standards Track                     [Page 9]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   Formally, code points are integers, and hence the pseudocode assumes
-   that arithmetic operations can be performed directly on code points.
-   In some programming languages, explicit conversion between code
-   points and integers might be necessary.
-
-6.1 Bias adaptation function
-
-   function adapt(delta,numpoints,firsttime):
-     if firsttime then let delta = delta div damp
-     else let delta = delta div 2
-     let delta = delta + (delta div numpoints)
-     let k = 0
-     while delta > ((base - tmin) * tmax) div 2 do begin
-       let delta = delta div (base - tmin)
-       let k = k + base
-     end
-     return k + (((base - tmin + 1) * delta) div (delta + skew))
-
-   It does not matter whether the modifications to delta and k inside
-   adapt() affect variables of the same name inside the
-   encoding/decoding procedures, because after calling adapt() the
-   caller does not read those variables before overwriting them.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 10]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-6.2 Decoding procedure
-
-   let n = initial_n
-   let i = 0
-   let bias = initial_bias
-   let output = an empty string indexed from 0
-   consume all code points before the last delimiter (if there is one)
-     and copy them to output, fail on any non-basic code point
-   if more than zero code points were consumed then consume one more
-     (which will be the last delimiter)
-   while the input is not exhausted do begin
-     let oldi = i
-     let w = 1
-     for k = base to infinity in steps of base do begin
-       consume a code point, or fail if there was none to consume
-       let digit = the code point's digit-value, fail if it has none
-       let i = i + digit * w, fail on overflow
-       let t = tmin if k <= bias {+ tmin}, or
-               tmax if k >= bias + tmax, or k - bias otherwise
-       if digit < t then break
-       let w = w * (base - t), fail on overflow
-     end
-     let bias = adapt(i - oldi, length(output) + 1, test oldi is 0?)
-     let n = n + i div (length(output) + 1), fail on overflow
-     let i = i mod (length(output) + 1)
-     {if n is a basic code point then fail}
-     insert n into output at position i
-     increment i
-   end
-
-   The full statement enclosed in braces (checking whether n is a basic
-   code point) can be omitted if initial_n exceeds all basic code points
-   (which is true for Punycode), because n is never less than initial_n.
-
-   In the assignment of t, where t is clamped to the range tmin through
-   tmax, "+ tmin" can always be omitted.  This makes the clamping
-   calculation incorrect when bias < k < bias + tmin, but that cannot
-   happen because of the way bias is computed and because of the
-   constraints on the parameters.
-
-   Because the decoder state can only advance monotonically, and there
-   is only one representation of any delta, there is therefore only one
-   encoded string that can represent a given sequence of integers.  The
-   only error conditions are invalid code points, unexpected end-of-
-   input, overflow, and basic code points encoded using deltas instead
-   of appearing literally.  If the decoder fails on these errors as
-   shown above, then it cannot produce the same output for two distinct
-   inputs.  Without this property it would have been necessary to re-
-
-
-
-Costello                    Standards Track                    [Page 11]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   encode the output and verify that it matches the input in order to
-   guarantee the uniqueness of the encoding.
-
-6.3 Encoding procedure
-
-   let n = initial_n
-   let delta = 0
-   let bias = initial_bias
-   let h = b = the number of basic code points in the input
-   copy them to the output in order, followed by a delimiter if b > 0
-   {if the input contains a non-basic code point < n then fail}
-   while h < length(input) do begin
-     let m = the minimum {non-basic} code point >= n in the input
-     let delta = delta + (m - n) * (h + 1), fail on overflow
-     let n = m
-     for each code point c in the input (in order) do begin
-       if c < n {or c is basic} then increment delta, fail on overflow
-       if c == n then begin
-         let q = delta
-         for k = base to infinity in steps of base do begin
-           let t = tmin if k <= bias {+ tmin}, or
-                   tmax if k >= bias + tmax, or k - bias otherwise
-           if q < t then break
-           output the code point for digit t + ((q - t) mod (base - t))
-           let q = (q - t) div (base - t)
-         end
-         output the code point for digit q
-         let bias = adapt(delta, h + 1, test h equals b?)
-         let delta = 0
-         increment h
-       end
-     end
-     increment delta and n
-   end
-
-   The full statement enclosed in braces (checking whether the input
-   contains a non-basic code point less than n) can be omitted if all
-   code points less than initial_n are basic code points (which is true
-   for Punycode if code points are unsigned).
-
-   The brace-enclosed conditions "non-basic" and "or c is basic" can be
-   omitted if initial_n exceeds all basic code points (which is true for
-   Punycode), because the code point being tested is never less than
-   initial_n.
-
-   In the assignment of t, where t is clamped to the range tmin through
-   tmax, "+ tmin" can always be omitted.  This makes the clamping
-   calculation incorrect when bias < k < bias + tmin, but that cannot
-
-
-
-Costello                    Standards Track                    [Page 12]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   happen because of the way bias is computed and because of the
-   constraints on the parameters.
-
-   The checks for overflow are necessary to avoid producing invalid
-   output when the input contains very large values or is very long.
-
-   The increment of delta at the bottom of the outer loop cannot
-   overflow because delta < length(input) before the increment, and
-   length(input) is already assumed to be representable.  The increment
-   of n could overflow, but only if h == length(input), in which case
-   the procedure is finished anyway.
-
-6.4 Overflow handling
-
-   For IDNA, 26-bit unsigned integers are sufficient to handle all valid
-   IDNA labels without overflow, because any string that needed a 27-bit
-   delta would have to exceed either the code point limit (0..10FFFF) or
-   the label length limit (63 characters).  However, overflow handling
-   is necessary because the inputs are not necessarily valid IDNA
-   labels.
-
-   If the programming language does not provide overflow detection, the
-   following technique can be used.  Suppose A, B, and C are
-   representable nonnegative integers and C is nonzero.  Then A + B
-   overflows if and only if B > maxint - A, and A + (B * C) overflows if
-   and only if B > (maxint - A) div C, where maxint is the greatest
-   integer for which maxint + 1 cannot be represented.  Refer to
-   appendix C "Punycode sample implementation" for demonstrations of
-   this technique in the C language.
-
-   The decoding and encoding algorithms shown in sections 6.2 and 6.3
-   handle overflow by detecting it whenever it happens.  Another
-   approach is to enforce limits on the inputs that prevent overflow
-   from happening.  For example, if the encoder were to verify that no
-   input code points exceed M and that the input length does not exceed
-   L, then no delta could ever exceed (M - initial_n) * (L + 1), and
-   hence no overflow could occur if integer variables were capable of
-   representing values that large.  This prevention approach would
-   impose more restrictions on the input than the detection approach
-   does, but might be considered simpler in some programming languages.
-
-   In theory, the decoder could use an analogous approach, limiting the
-   number of digits in a variable-length integer (that is, limiting the
-   number of iterations in the innermost loop).  However, the number of
-   digits that suffice to represent a given delta can sometimes
-   represent much larger deltas (because of the adaptation), and hence
-   this approach would probably need integers wider than 32 bits.
-
-
-
-
-Costello                    Standards Track                    [Page 13]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   Yet another approach for the decoder is to allow overflow to occur,
-   but to check the final output string by re-encoding it and comparing
-   to the decoder input.  If and only if they do not match (using a
-   case-insensitive ASCII comparison) overflow has occurred.  This
-   delayed-detection approach would not impose any more restrictions on
-   the input than the immediate-detection approach does, and might be
-   considered simpler in some programming languages.
-
-   In fact, if the decoder is used only inside the IDNA ToUnicode
-   operation [IDNA], then it need not check for overflow at all, because
-   ToUnicode performs a higher level re-encoding and comparison, and a
-   mismatch has the same consequence as if the Punycode decoder had
-   failed.
-
-7. Punycode examples
-
-7.1 Sample strings
-
-   In the Punycode encodings below, the ACE prefix is not shown.
-   Backslashes show where line breaks have been inserted in strings too
-   long for one line.
-
-   The first several examples are all translations of the sentence "Why
-   can't they just speak in <language>?" (courtesy of Michael Kaplan's
-   "provincial" page [PROVINCIAL]).  Word breaks and punctuation have
-   been removed, as is often done in domain names.
-
-   (A) Arabic (Egyptian):
-       u+0644 u+064A u+0647 u+0645 u+0627 u+0628 u+062A u+0643 u+0644
-       u+0645 u+0648 u+0634 u+0639 u+0631 u+0628 u+064A u+061F
-       Punycode: egbpdaj6bu4bxfgehfvwxn
-
-   (B) Chinese (simplified):
-       u+4ED6 u+4EEC u+4E3A u+4EC0 u+4E48 u+4E0D u+8BF4 u+4E2D u+6587
-       Punycode: ihqwcrb4cv8a8dqg056pqjye
-
-   (C) Chinese (traditional):
-       u+4ED6 u+5011 u+7232 u+4EC0 u+9EBD u+4E0D u+8AAA u+4E2D u+6587
-       Punycode: ihqwctvzc91f659drss3x8bo0yb
-
-   (D) Czech: Pro<ccaron>prost<ecaron>nemluv<iacute><ccaron>esky
-       U+0050 u+0072 u+006F u+010D u+0070 u+0072 u+006F u+0073 u+0074
-       u+011B u+006E u+0065 u+006D u+006C u+0075 u+0076 u+00ED u+010D
-       u+0065 u+0073 u+006B u+0079
-       Punycode: Proprostnemluvesky-uyb24dma41a
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 14]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   (E) Hebrew:
-       u+05DC u+05DE u+05D4 u+05D4 u+05DD u+05E4 u+05E9 u+05D5 u+05D8
-       u+05DC u+05D0 u+05DE u+05D3 u+05D1 u+05E8 u+05D9 u+05DD u+05E2
-       u+05D1 u+05E8 u+05D9 u+05EA
-       Punycode: 4dbcagdahymbxekheh6e0a7fei0b
-
-   (F) Hindi (Devanagari):
-       u+092F u+0939 u+0932 u+094B u+0917 u+0939 u+093F u+0928 u+094D
-       u+0926 u+0940 u+0915 u+094D u+092F u+094B u+0902 u+0928 u+0939
-       u+0940 u+0902 u+092C u+094B u+0932 u+0938 u+0915 u+0924 u+0947
-       u+0939 u+0948 u+0902
-       Punycode: i1baa7eci9glrd9b2ae1bj0hfcgg6iyaf8o0a1dig0cd
-
-   (G) Japanese (kanji and hiragana):
-       u+306A u+305C u+307F u+3093 u+306A u+65E5 u+672C u+8A9E u+3092
-       u+8A71 u+3057 u+3066 u+304F u+308C u+306A u+3044 u+306E u+304B
-       Punycode: n8jok5ay5dzabd5bym9f0cm5685rrjetr6pdxa
-
-   (H) Korean (Hangul syllables):
-       u+C138 u+ACC4 u+C758 u+BAA8 u+B4E0 u+C0AC u+B78C u+B4E4 u+C774
-       u+D55C u+AD6D u+C5B4 u+B97C u+C774 u+D574 u+D55C u+B2E4 u+BA74
-       u+C5BC u+B9C8 u+B098 u+C88B u+C744 u+AE4C
-       Punycode: 989aomsvi5e83db1d2a355cv1e0vak1dwrv93d5xbh15a0dt30a5j\
-                 psd879ccm6fea98c
-
-   (I) Russian (Cyrillic):
-       U+043F u+043E u+0447 u+0435 u+043C u+0443 u+0436 u+0435 u+043E
-       u+043D u+0438 u+043D u+0435 u+0433 u+043E u+0432 u+043E u+0440
-       u+044F u+0442 u+043F u+043E u+0440 u+0443 u+0441 u+0441 u+043A
-       u+0438
-       Punycode: b1abfaaepdrnnbgefbaDotcwatmq2g4l
-
-   (J) Spanish: Porqu<eacute>nopuedensimplementehablarenEspa<ntilde>ol
-       U+0050 u+006F u+0072 u+0071 u+0075 u+00E9 u+006E u+006F u+0070
-       u+0075 u+0065 u+0064 u+0065 u+006E u+0073 u+0069 u+006D u+0070
-       u+006C u+0065 u+006D u+0065 u+006E u+0074 u+0065 u+0068 u+0061
-       u+0062 u+006C u+0061 u+0072 u+0065 u+006E U+0045 u+0073 u+0070
-       u+0061 u+00F1 u+006F u+006C
-       Punycode: PorqunopuedensimplementehablarenEspaol-fmd56a
-
-   (K) Vietnamese:
-       T<adotbelow>isaoh<odotbelow>kh<ocirc>ngth<ecirchookabove>ch\
-       <ihookabove>n<oacute>iti<ecircacute>ngVi<ecircdotbelow>t
-       U+0054 u+1EA1 u+0069 u+0073 u+0061 u+006F u+0068 u+1ECD u+006B
-       u+0068 u+00F4 u+006E u+0067 u+0074 u+0068 u+1EC3 u+0063 u+0068
-       u+1EC9 u+006E u+00F3 u+0069 u+0074 u+0069 u+1EBF u+006E u+0067
-       U+0056 u+0069 u+1EC7 u+0074
-       Punycode: TisaohkhngthchnitingVit-kjcr8268qyxafd2f1b9g
-
-
-
-Costello                    Standards Track                    [Page 15]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   The next several examples are all names of Japanese music artists,
-   song titles, and TV programs, just because the author happens to have
-   them handy (but Japanese is useful for providing examples of single-
-   row text, two-row text, ideographic text, and various mixtures
-   thereof).
-
-   (L) 3<nen>B<gumi><kinpachi><sensei>
-       u+0033 u+5E74 U+0042 u+7D44 u+91D1 u+516B u+5148 u+751F
-       Punycode: 3B-ww4c5e180e575a65lsy2b
-
-   (M) <amuro><namie>-with-SUPER-MONKEYS
-       u+5B89 u+5BA4 u+5948 u+7F8E u+6075 u+002D u+0077 u+0069 u+0074
-       u+0068 u+002D U+0053 U+0055 U+0050 U+0045 U+0052 u+002D U+004D
-       U+004F U+004E U+004B U+0045 U+0059 U+0053
-       Punycode: -with-SUPER-MONKEYS-pc58ag80a8qai00g7n9n
-
-   (N) Hello-Another-Way-<sorezore><no><basho>
-       U+0048 u+0065 u+006C u+006C u+006F u+002D U+0041 u+006E u+006F
-       u+0074 u+0068 u+0065 u+0072 u+002D U+0057 u+0061 u+0079 u+002D
-       u+305D u+308C u+305E u+308C u+306E u+5834 u+6240
-       Punycode: Hello-Another-Way--fc4qua05auwb3674vfr0b
-
-   (O) <hitotsu><yane><no><shita>2
-       u+3072 u+3068 u+3064 u+5C4B u+6839 u+306E u+4E0B u+0032
-       Punycode: 2-u9tlzr9756bt3uc0v
-
-   (P) Maji<de>Koi<suru>5<byou><mae>
-       U+004D u+0061 u+006A u+0069 u+3067 U+004B u+006F u+0069 u+3059
-       u+308B u+0035 u+79D2 u+524D
-       Punycode: MajiKoi5-783gue6qz075azm5e
-
-   (Q) <pafii>de<runba>
-       u+30D1 u+30D5 u+30A3 u+30FC u+0064 u+0065 u+30EB u+30F3 u+30D0
-       Punycode: de-jg4avhby1noc0d
-
-   (R) <sono><supiido><de>
-       u+305D u+306E u+30B9 u+30D4 u+30FC u+30C9 u+3067
-       Punycode: d9juau41awczczp
-
-   The last example is an ASCII string that breaks the existing rules
-   for host name labels.  (It is not a realistic example for IDNA,
-   because IDNA never encodes pure ASCII labels.)
-
-   (S) -> $1.00 <-
-       u+002D u+003E u+0020 u+0024 u+0031 u+002E u+0030 u+0030 u+0020
-       u+003C u+002D
-       Punycode: -> $1.00 <--
-
-
-
-
-Costello                    Standards Track                    [Page 16]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-7.2 Decoding traces
-
-   In the following traces, the evolving state of the decoder is shown
-   as a sequence of hexadecimal values, representing the code points in
-   the extended string.  An asterisk appears just after the most
-   recently inserted code point, indicating both n (the value preceeding
-   the asterisk) and i (the position of the value just after the
-   asterisk).  Other numerical values are decimal.
-
-   Decoding trace of example B from section 7.1:
-
-   n is 128, i is 0, bias is 72
-   input is "ihqwcrb4cv8a8dqg056pqjye"
-   there is no delimiter, so extended string starts empty
-   delta "ihq" decodes to 19853
-   bias becomes 21
-   4E0D *
-   delta "wc" decodes to 64
-   bias becomes 20
-   4E0D 4E2D *
-   delta "rb" decodes to 37
-   bias becomes 13
-   4E3A * 4E0D 4E2D
-   delta "4c" decodes to 56
-   bias becomes 17
-   4E3A 4E48 * 4E0D 4E2D
-   delta "v8a" decodes to 599
-   bias becomes 32
-   4E3A 4EC0 * 4E48 4E0D 4E2D
-   delta "8d" decodes to 130
-   bias becomes 23
-   4ED6 * 4E3A 4EC0 4E48 4E0D 4E2D
-   delta "qg" decodes to 154
-   bias becomes 25
-   4ED6 4EEC * 4E3A 4EC0 4E48 4E0D 4E2D
-   delta "056p" decodes to 46301
-   bias becomes 84
-   4ED6 4EEC 4E3A 4EC0 4E48 4E0D 4E2D 6587 *
-   delta "qjye" decodes to 88531
-   bias becomes 90
-   4ED6 4EEC 4E3A 4EC0 4E48 4E0D 8BF4 * 4E2D 6587
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 17]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   Decoding trace of example L from section 7.1:
-
-   n is 128, i is 0, bias is 72
-   input is "3B-ww4c5e180e575a65lsy2b"
-   literal portion is "3B-", so extended string starts as:
-   0033 0042
-   delta "ww4c" decodes to 62042
-   bias becomes 27
-   0033 0042 5148 *
-   delta "5e" decodes to 139
-   bias becomes 24
-   0033 0042 516B * 5148
-   delta "180e" decodes to 16683
-   bias becomes 67
-   0033 5E74 * 0042 516B 5148
-   delta "575a" decodes to 34821
-   bias becomes 82
-   0033 5E74 0042 516B 5148 751F *
-   delta "65l" decodes to 14592
-   bias becomes 67
-   0033 5E74 0042 7D44 * 516B 5148 751F
-   delta "sy2b" decodes to 42088
-   bias becomes 84
-   0033 5E74 0042 7D44 91D1 * 516B 5148 751F
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 18]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-7.3 Encoding traces
-
-   In the following traces, code point values are hexadecimal, while
-   other numerical values are decimal.
-
-   Encoding trace of example B from section 7.1:
-
-   bias is 72
-   input is:
-   4ED6 4EEC 4E3A 4EC0 4E48 4E0D 8BF4 4E2D 6587
-   there are no basic code points, so no literal portion
-   next code point to insert is 4E0D
-   needed delta is 19853, encodes as "ihq"
-   bias becomes 21
-   next code point to insert is 4E2D
-   needed delta is 64, encodes as "wc"
-   bias becomes 20
-   next code point to insert is 4E3A
-   needed delta is 37, encodes as "rb"
-   bias becomes 13
-   next code point to insert is 4E48
-   needed delta is 56, encodes as "4c"
-   bias becomes 17
-   next code point to insert is 4EC0
-   needed delta is 599, encodes as "v8a"
-   bias becomes 32
-   next code point to insert is 4ED6
-   needed delta is 130, encodes as "8d"
-   bias becomes 23
-   next code point to insert is 4EEC
-   needed delta is 154, encodes as "qg"
-   bias becomes 25
-   next code point to insert is 6587
-   needed delta is 46301, encodes as "056p"
-   bias becomes 84
-   next code point to insert is 8BF4
-   needed delta is 88531, encodes as "qjye"
-   bias becomes 90
-   output is "ihqwcrb4cv8a8dqg056pqjye"
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 19]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   Encoding trace of example L from section 7.1:
-
-   bias is 72
-   input is:
-   0033 5E74 0042 7D44 91D1 516B 5148 751F
-   basic code points (0033, 0042) are copied to literal portion: "3B-"
-   next code point to insert is 5148
-   needed delta is 62042, encodes as "ww4c"
-   bias becomes 27
-   next code point to insert is 516B
-   needed delta is 139, encodes as "5e"
-   bias becomes 24
-   next code point to insert is 5E74
-   needed delta is 16683, encodes as "180e"
-   bias becomes 67
-   next code point to insert is 751F
-   needed delta is 34821, encodes as "575a"
-   bias becomes 82
-   next code point to insert is 7D44
-   needed delta is 14592, encodes as "65l"
-   bias becomes 67
-   next code point to insert is 91D1
-   needed delta is 42088, encodes as "sy2b"
-   bias becomes 84
-   output is "3B-ww4c5e180e575a65lsy2b"
-
-8. Security Considerations
-
-   Users expect each domain name in DNS to be controlled by a single
-   authority.  If a Unicode string intended for use as a domain label
-   could map to multiple ACE labels, then an internationalized domain
-   name could map to multiple ASCII domain names, each controlled by a
-   different authority, some of which could be spoofs that hijack
-   service requests intended for another.  Therefore Punycode is
-   designed so that each Unicode string has a unique encoding.
-
-   However, there can still be multiple Unicode representations of the
-   "same" text, for various definitions of "same".  This problem is
-   addressed to some extent by the Unicode standard under the topic of
-   canonicalization, and this work is leveraged for domain names by
-   Nameprep [NAMEPREP].
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 20]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-9. References
-
-9.1 Normative References
-
-   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-9.2 Informative References
-
-   [RFC952]     Harrenstien, K., Stahl, M. and E. Feinler, "DOD Internet
-                Host Table Specification", RFC 952, October 1985.
-
-   [RFC1034]    Mockapetris, P., "Domain Names - Concepts and
-                Facilities", STD 13, RFC 1034, November 1987.
-
-   [IDNA]       Faltstrom, P., Hoffman, P. and A. Costello,
-                "Internationalizing Domain Names in Applications
-                (IDNA)", RFC 3490, March 2003.
-
-   [NAMEPREP]   Hoffman, P. and  M. Blanchet, "Nameprep: A Stringprep
-                Profile for Internationalized Domain Names (IDN)", RFC
-                3491, March 2003.
-
-   [ASCII]      Cerf, V., "ASCII format for Network Interchange", RFC
-                20, October 1969.
-
-   [PROVINCIAL] Kaplan, M., "The 'anyone can be provincial!' page",
-                http://www.trigeminal.com/samples/provincial.html.
-
-   [UNICODE]    The Unicode Consortium, "The Unicode Standard",
-                http://www.unicode.org/unicode/standard/standard.html.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 21]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-A. Mixed-case annotation
-
-   In order to use Punycode to represent case-insensitive strings,
-   higher layers need to case-fold the strings prior to Punycode
-   encoding.  The encoded string can use mixed case as an annotation
-   telling how to convert the folded string into a mixed-case string for
-   display purposes.  Note, however, that mixed-case annotation is not
-   used by the ToASCII and ToUnicode operations specified in [IDNA], and
-   therefore implementors of IDNA can disregard this appendix.
-
-   Basic code points can use mixed case directly, because the decoder
-   copies them verbatim, leaving lowercase code points lowercase, and
-   leaving uppercase code points uppercase.  Each non-basic code point
-   is represented by a delta, which is represented by a sequence of
-   basic code points, the last of which provides the annotation.  If it
-   is uppercase, it is a suggestion to map the non-basic code point to
-   uppercase (if possible); if it is lowercase, it is a suggestion to
-   map the non-basic code point to lowercase (if possible).
-
-   These annotations do not alter the code points returned by decoders;
-   the annotations are returned separately, for the caller to use or
-   ignore.  Encoders can accept annotations in addition to code points,
-   but the annotations do not alter the output, except to influence the
-   uppercase/lowercase form of ASCII letters.
-
-   Punycode encoders and decoders need not support these annotations,
-   and higher layers need not use them.
-
-B. Disclaimer and license
-
-   Regarding this entire document or any portion of it (including the
-   pseudocode and C code), the author makes no guarantees and is not
-   responsible for any damage resulting from its use.  The author grants
-   irrevocable permission to anyone to use, modify, and distribute it in
-   any way that does not diminish the rights of anyone else to use,
-   modify, and distribute it, provided that redistributed derivative
-   works do not contain misleading author or version information.
-   Derivative works need not be licensed under similar terms.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 22]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-C. Punycode sample implementation
-
-/*
-punycode.c from RFC 3492
-http://www.nicemice.net/idn/
-Adam M. Costello
-http://www.nicemice.net/amc/
-
-This is ANSI C code (C89) implementing Punycode (RFC 3492).
-
-*/
-
-
-/************************************************************/
-/* Public interface (would normally go in its own .h file): */
-
-#include <limits.h>
-
-enum punycode_status {
-  punycode_success,
-  punycode_bad_input,   /* Input is invalid.                       */
-  punycode_big_output,  /* Output would exceed the space provided. */
-  punycode_overflow     /* Input needs wider integers to process.  */
-};
-
-#if UINT_MAX >= (1 << 26) - 1
-typedef unsigned int punycode_uint;
-#else
-typedef unsigned long punycode_uint;
-#endif
-
-enum punycode_status punycode_encode(
-  punycode_uint input_length,
-  const punycode_uint input[],
-  const unsigned char case_flags[],
-  punycode_uint *output_length,
-  char output[] );
-
-    /* punycode_encode() converts Unicode to Punycode.  The input     */
-    /* is represented as an array of Unicode code points (not code    */
-    /* units; surrogate pairs are not allowed), and the output        */
-    /* will be represented as an array of ASCII code points.  The     */
-    /* output string is *not* null-terminated; it will contain        */
-    /* zeros if and only if the input contains zeros.  (Of course     */
-    /* the caller can leave room for a terminator and add one if      */
-    /* needed.)  The input_length is the number of code points in     */
-    /* the input.  The output_length is an in/out argument: the       */
-    /* caller passes in the maximum number of code points that it     */
-
-
-
-Costello                    Standards Track                    [Page 23]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-    /* can receive, and on successful return it will contain the      */
-    /* number of code points actually output.  The case_flags array   */
-    /* holds input_length boolean values, where nonzero suggests that */
-    /* the corresponding Unicode character be forced to uppercase     */
-    /* after being decoded (if possible), and zero suggests that      */
-    /* it be forced to lowercase (if possible).  ASCII code points    */
-    /* are encoded literally, except that ASCII letters are forced    */
-    /* to uppercase or lowercase according to the corresponding       */
-    /* uppercase flags.  If case_flags is a null pointer then ASCII   */
-    /* letters are left as they are, and other code points are        */
-    /* treated as if their uppercase flags were zero.  The return     */
-    /* value can be any of the punycode_status values defined above   */
-    /* except punycode_bad_input; if not punycode_success, then       */
-    /* output_size and output might contain garbage.                  */
-
-enum punycode_status punycode_decode(
-  punycode_uint input_length,
-  const char input[],
-  punycode_uint *output_length,
-  punycode_uint output[],
-  unsigned char case_flags[] );
-
-    /* punycode_decode() converts Punycode to Unicode.  The input is  */
-    /* represented as an array of ASCII code points, and the output   */
-    /* will be represented as an array of Unicode code points.  The   */
-    /* input_length is the number of code points in the input.  The   */
-    /* output_length is an in/out argument: the caller passes in      */
-    /* the maximum number of code points that it can receive, and     */
-    /* on successful return it will contain the actual number of      */
-    /* code points output.  The case_flags array needs room for at    */
-    /* least output_length values, or it can be a null pointer if the */
-    /* case information is not needed.  A nonzero flag suggests that  */
-    /* the corresponding Unicode character be forced to uppercase     */
-    /* by the caller (if possible), while zero suggests that it be    */
-    /* forced to lowercase (if possible).  ASCII code points are      */
-    /* output already in the proper case, but their flags will be set */
-    /* appropriately so that applying the flags would be harmless.    */
-    /* The return value can be any of the punycode_status values      */
-    /* defined above; if not punycode_success, then output_length,    */
-    /* output, and case_flags might contain garbage.  On success, the */
-    /* decoder will never need to write an output_length greater than */
-    /* input_length, because of how the encoding is defined.          */
-
-/**********************************************************/
-/* Implementation (would normally go in its own .c file): */
-
-#include <string.h>
-
-
-
-
-Costello                    Standards Track                    [Page 24]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-/*** Bootstring parameters for Punycode ***/
-
-enum { base = 36, tmin = 1, tmax = 26, skew = 38, damp = 700,
-       initial_bias = 72, initial_n = 0x80, delimiter = 0x2D };
-
-/* basic(cp) tests whether cp is a basic code point: */
-#define basic(cp) ((punycode_uint)(cp) < 0x80)
-
-/* delim(cp) tests whether cp is a delimiter: */
-#define delim(cp) ((cp) == delimiter)
-
-/* decode_digit(cp) returns the numeric value of a basic code */
-/* point (for use in representing integers) in the range 0 to */
-/* base-1, or base if cp is does not represent a value.       */
-
-static punycode_uint decode_digit(punycode_uint cp)
-{
-  return  cp - 48 < 10 ? cp - 22 :  cp - 65 < 26 ? cp - 65 :
-          cp - 97 < 26 ? cp - 97 :  base;
-}
-
-/* encode_digit(d,flag) returns the basic code point whose value      */
-/* (when used for representing integers) is d, which needs to be in   */
-/* the range 0 to base-1.  The lowercase form is used unless flag is  */
-/* nonzero, in which case the uppercase form is used.  The behavior   */
-/* is undefined if flag is nonzero and digit d has no uppercase form. */
-
-static char encode_digit(punycode_uint d, int flag)
-{
-  return d + 22 + 75 * (d < 26) - ((flag != 0) << 5);
-  /*  0..25 map to ASCII a..z or A..Z */
-  /* 26..35 map to ASCII 0..9         */
-}
-
-/* flagged(bcp) tests whether a basic code point is flagged */
-/* (uppercase).  The behavior is undefined if bcp is not a  */
-/* basic code point.                                        */
-
-#define flagged(bcp) ((punycode_uint)(bcp) - 65 < 26)
-
-/* encode_basic(bcp,flag) forces a basic code point to lowercase */
-/* if flag is zero, uppercase if flag is nonzero, and returns    */
-/* the resulting code point.  The code point is unchanged if it  */
-/* is caseless.  The behavior is undefined if bcp is not a basic */
-/* code point.                                                   */
-
-static char encode_basic(punycode_uint bcp, int flag)
-{
-
-
-
-Costello                    Standards Track                    [Page 25]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-  bcp -= (bcp - 97 < 26) << 5;
-  return bcp + ((!flag && (bcp - 65 < 26)) << 5);
-}
-
-/*** Platform-specific constants ***/
-
-/* maxint is the maximum value of a punycode_uint variable: */
-static const punycode_uint maxint = -1;
-/* Because maxint is unsigned, -1 becomes the maximum value. */
-
-/*** Bias adaptation function ***/
-
-static punycode_uint adapt(
-  punycode_uint delta, punycode_uint numpoints, int firsttime )
-{
-  punycode_uint k;
-
-  delta = firsttime ? delta / damp : delta >> 1;
-  /* delta >> 1 is a faster way of doing delta / 2 */
-  delta += delta / numpoints;
-
-  for (k = 0;  delta > ((base - tmin) * tmax) / 2;  k += base) {
-    delta /= base - tmin;
-  }
-
-  return k + (base - tmin + 1) * delta / (delta + skew);
-}
-
-/*** Main encode function ***/
-
-enum punycode_status punycode_encode(
-  punycode_uint input_length,
-  const punycode_uint input[],
-  const unsigned char case_flags[],
-  punycode_uint *output_length,
-  char output[] )
-{
-  punycode_uint n, delta, h, b, out, max_out, bias, j, m, q, k, t;
-
-  /* Initialize the state: */
-
-  n = initial_n;
-  delta = out = 0;
-  max_out = *output_length;
-  bias = initial_bias;
-
-  /* Handle the basic code points: */
-
-
-
-
-Costello                    Standards Track                    [Page 26]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-  for (j = 0;  j < input_length;  ++j) {
-    if (basic(input[j])) {
-      if (max_out - out < 2) return punycode_big_output;
-      output[out++] =
-        case_flags ?  encode_basic(input[j], case_flags[j]) : input[j];
-    }
-    /* else if (input[j] < n) return punycode_bad_input; */
-    /* (not needed for Punycode with unsigned code points) */
-  }
-
-  h = b = out;
-
-  /* h is the number of code points that have been handled, b is the  */
-  /* number of basic code points, and out is the number of characters */
-  /* that have been output.                                           */
-
-  if (b > 0) output[out++] = delimiter;
-
-  /* Main encoding loop: */
-
-  while (h < input_length) {
-    /* All non-basic code points < n have been     */
-    /* handled already.  Find the next larger one: */
-
-    for (m = maxint, j = 0;  j < input_length;  ++j) {
-      /* if (basic(input[j])) continue; */
-      /* (not needed for Punycode) */
-      if (input[j] >= n && input[j] < m) m = input[j];
-    }
-
-    /* Increase delta enough to advance the decoder's    */
-    /* <n,i> state to <m,0>, but guard against overflow: */
-
-    if (m - n > (maxint - delta) / (h + 1)) return punycode_overflow;
-    delta += (m - n) * (h + 1);
-    n = m;
-
-    for (j = 0;  j < input_length;  ++j) {
-      /* Punycode does not need to check whether input[j] is basic: */
-      if (input[j] < n /* || basic(input[j]) */ ) {
-        if (++delta == 0) return punycode_overflow;
-      }
-
-      if (input[j] == n) {
-        /* Represent delta as a generalized variable-length integer: */
-
-        for (q = delta, k = base;  ;  k += base) {
-          if (out >= max_out) return punycode_big_output;
-
-
-
-Costello                    Standards Track                    [Page 27]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-          t = k <= bias /* + tmin */ ? tmin :     /* +tmin not needed */
-              k >= bias + tmax ? tmax : k - bias;
-          if (q < t) break;
-          output[out++] = encode_digit(t + (q - t) % (base - t), 0);
-          q = (q - t) / (base - t);
-        }
-
-        output[out++] = encode_digit(q, case_flags && case_flags[j]);
-        bias = adapt(delta, h + 1, h == b);
-        delta = 0;
-        ++h;
-      }
-    }
-
-    ++delta, ++n;
-  }
-
-  *output_length = out;
-  return punycode_success;
-}
-
-/*** Main decode function ***/
-
-enum punycode_status punycode_decode(
-  punycode_uint input_length,
-  const char input[],
-  punycode_uint *output_length,
-  punycode_uint output[],
-  unsigned char case_flags[] )
-{
-  punycode_uint n, out, i, max_out, bias,
-                 b, j, in, oldi, w, k, digit, t;
-
-  /* Initialize the state: */
-
-  n = initial_n;
-  out = i = 0;
-  max_out = *output_length;
-  bias = initial_bias;
-
-  /* Handle the basic code points:  Let b be the number of input code */
-  /* points before the last delimiter, or 0 if there is none, then    */
-  /* copy the first b code points to the output.                      */
-
-  for (b = j = 0;  j < input_length;  ++j) if (delim(input[j])) b = j;
-  if (b > max_out) return punycode_big_output;
-
-  for (j = 0;  j < b;  ++j) {
-
-
-
-Costello                    Standards Track                    [Page 28]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-    if (case_flags) case_flags[out] = flagged(input[j]);
-    if (!basic(input[j])) return punycode_bad_input;
-    output[out++] = input[j];
-  }
-
-  /* Main decoding loop:  Start just after the last delimiter if any  */
-  /* basic code points were copied; start at the beginning otherwise. */
-
-  for (in = b > 0 ? b + 1 : 0;  in < input_length;  ++out) {
-
-    /* in is the index of the next character to be consumed, and */
-    /* out is the number of code points in the output array.     */
-
-    /* Decode a generalized variable-length integer into delta,  */
-    /* which gets added to i.  The overflow checking is easier   */
-    /* if we increase i as we go, then subtract off its starting */
-    /* value at the end to obtain delta.                         */
-
-    for (oldi = i, w = 1, k = base;  ;  k += base) {
-      if (in >= input_length) return punycode_bad_input;
-      digit = decode_digit(input[in++]);
-      if (digit >= base) return punycode_bad_input;
-      if (digit > (maxint - i) / w) return punycode_overflow;
-      i += digit * w;
-      t = k <= bias /* + tmin */ ? tmin :     /* +tmin not needed */
-          k >= bias + tmax ? tmax : k - bias;
-      if (digit < t) break;
-      if (w > maxint / (base - t)) return punycode_overflow;
-      w *= (base - t);
-    }
-
-    bias = adapt(i - oldi, out + 1, oldi == 0);
-
-    /* i was supposed to wrap around from out+1 to 0,   */
-    /* incrementing n each time, so we'll fix that now: */
-
-    if (i / (out + 1) > maxint - n) return punycode_overflow;
-    n += i / (out + 1);
-    i %= (out + 1);
-
-    /* Insert n at position i of the output: */
-
-    /* not needed for Punycode: */
-    /* if (decode_digit(n) <= base) return punycode_invalid_input; */
-    if (out >= max_out) return punycode_big_output;
-
-    if (case_flags) {
-      memmove(case_flags + i + 1, case_flags + i, out - i);
-
-
-
-Costello                    Standards Track                    [Page 29]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-      /* Case of last character determines uppercase flag: */
-      case_flags[i] = flagged(input[in - 1]);
-    }
-
-    memmove(output + i + 1, output + i, (out - i) * sizeof *output);
-    output[i++] = n;
-  }
-
-  *output_length = out;
-  return punycode_success;
-}
-
-/******************************************************************/
-/* Wrapper for testing (would normally go in a separate .c file): */
-
-#include <assert.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-
-/* For testing, we'll just set some compile-time limits rather than */
-/* use malloc(), and set a compile-time option rather than using a  */
-/* command-line option.                                             */
-
-enum {
-  unicode_max_length = 256,
-  ace_max_length = 256
-};
-
-static void usage(char **argv)
-{
-  fprintf(stderr,
-    "\n"
-    "%s -e reads code points and writes a Punycode string.\n"
-    "%s -d reads a Punycode string and writes code points.\n"
-    "\n"
-    "Input and output are plain text in the native character set.\n"
-    "Code points are in the form u+hex separated by whitespace.\n"
-    "Although the specification allows Punycode strings to contain\n"
-    "any characters from the ASCII repertoire, this test code\n"
-    "supports only the printable characters, and needs the Punycode\n"
-    "string to be followed by a newline.\n"
-    "The case of the u in u+hex is the force-to-uppercase flag.\n"
-    , argv[0], argv[0]);
-  exit(EXIT_FAILURE);
-}
-
-static void fail(const char *msg)
-
-
-
-Costello                    Standards Track                    [Page 30]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-{
-  fputs(msg,stderr);
-  exit(EXIT_FAILURE);
-}
-
-static const char too_big[] =
-  "input or output is too large, recompile with larger limits\n";
-static const char invalid_input[] = "invalid input\n";
-static const char overflow[] = "arithmetic overflow\n";
-static const char io_error[] = "I/O error\n";
-
-/* The following string is used to convert printable */
-/* characters between ASCII and the native charset:  */
-
-static const char print_ascii[] =
-  "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
-  "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
-  " !\"#$%&'()*+,-./"
-  "0123456789:;<=>?"
-  "@ABCDEFGHIJKLMNO"
-  "PQRSTUVWXYZ[\\]^_"
-  "`abcdefghijklmno"
-  "pqrstuvwxyz{|}~\n";
-
-int main(int argc, char **argv)
-{
-  enum punycode_status status;
-  int r;
-  unsigned int input_length, output_length, j;
-  unsigned char case_flags[unicode_max_length];
-
-  if (argc != 2) usage(argv);
-  if (argv[1][0] != '-') usage(argv);
-  if (argv[1][2] != 0) usage(argv);
-
-  if (argv[1][1] == 'e') {
-    punycode_uint input[unicode_max_length];
-    unsigned long codept;
-    char output[ace_max_length+1], uplus[3];
-    int c;
-
-    /* Read the input code points: */
-
-    input_length = 0;
-
-    for (;;) {
-      r = scanf("%2s%lx", uplus, &codept);
-      if (ferror(stdin)) fail(io_error);
-
-
-
-Costello                    Standards Track                    [Page 31]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-      if (r == EOF || r == 0) break;
-
-      if (r != 2 || uplus[1] != '+' || codept > (punycode_uint)-1) {
-        fail(invalid_input);
-      }
-
-      if (input_length == unicode_max_length) fail(too_big);
-
-      if (uplus[0] == 'u') case_flags[input_length] = 0;
-      else if (uplus[0] == 'U') case_flags[input_length] = 1;
-      else fail(invalid_input);
-
-      input[input_length++] = codept;
-    }
-
-    /* Encode: */
-
-    output_length = ace_max_length;
-    status = punycode_encode(input_length, input, case_flags,
-                             &output_length, output);
-    if (status == punycode_bad_input) fail(invalid_input);
-    if (status == punycode_big_output) fail(too_big);
-    if (status == punycode_overflow) fail(overflow);
-    assert(status == punycode_success);
-
-    /* Convert to native charset and output: */
-
-    for (j = 0;  j < output_length;  ++j) {
-      c = output[j];
-      assert(c >= 0 && c <= 127);
-      if (print_ascii[c] == 0) fail(invalid_input);
-      output[j] = print_ascii[c];
-    }
-
-    output[j] = 0;
-    r = puts(output);
-    if (r == EOF) fail(io_error);
-    return EXIT_SUCCESS;
-  }
-
-  if (argv[1][1] == 'd') {
-    char input[ace_max_length+2], *p, *pp;
-    punycode_uint output[unicode_max_length];
-
-    /* Read the Punycode input string and convert to ASCII: */
-
-    fgets(input, ace_max_length+2, stdin);
-    if (ferror(stdin)) fail(io_error);
-
-
-
-Costello                    Standards Track                    [Page 32]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-    if (feof(stdin)) fail(invalid_input);
-    input_length = strlen(input) - 1;
-    if (input[input_length] != '\n') fail(too_big);
-    input[input_length] = 0;
-
-    for (p = input;  *p != 0;  ++p) {
-      pp = strchr(print_ascii, *p);
-      if (pp == 0) fail(invalid_input);
-      *p = pp - print_ascii;
-    }
-
-    /* Decode: */
-
-    output_length = unicode_max_length;
-    status = punycode_decode(input_length, input, &output_length,
-                             output, case_flags);
-    if (status == punycode_bad_input) fail(invalid_input);
-    if (status == punycode_big_output) fail(too_big);
-    if (status == punycode_overflow) fail(overflow);
-    assert(status == punycode_success);
-
-    /* Output the result: */
-
-    for (j = 0;  j < output_length;  ++j) {
-      r = printf("%s+%04lX\n",
-                 case_flags[j] ? "U" : "u",
-                 (unsigned long) output[j] );
-      if (r < 0) fail(io_error);
-    }
-
-    return EXIT_SUCCESS;
-  }
-
-  usage(argv);
-  return EXIT_SUCCESS;  /* not reached, but quiets compiler warning */
-}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 33]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-Author's Address
-
-   Adam M. Costello
-   University of California, Berkeley
-   http://www.nicemice.net/amc/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 34]
-
-RFC 3492                     IDNA Punycode                    March 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 35]
-
diff --git a/contrib/bind9/doc/rfc/rfc3493.txt b/contrib/bind9/doc/rfc/rfc3493.txt
deleted file mode 100644
index 5fea6c1..0000000
--- a/contrib/bind9/doc/rfc/rfc3493.txt
+++ /dev/null
@@ -1,2187 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        R. Gilligan
-Request for Comments: 3493                                Intransa, Inc.
-Obsoletes: 2553                                               S. Thomson
-Category: Informational                                            Cisco
-                                                                J. Bound
-                                                               J. McCann
-                                                         Hewlett-Packard
-                                                              W. Stevens
-                                                           February 2003
-
-
-               Basic Socket Interface Extensions for IPv6
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   The de facto standard Application Program Interface (API) for TCP/IP
-   applications is the "sockets" interface.  Although this API was
-   developed for Unix in the early 1980s it has also been implemented on
-   a wide variety of non-Unix systems.  TCP/IP applications written
-   using the sockets API have in the past enjoyed a high degree of
-   portability and we would like the same portability with IPv6
-   applications.  But changes are required to the sockets API to support
-   IPv6 and this memo describes these changes.  These include a new
-   socket address structure to carry IPv6 addresses, new address
-   conversion functions, and some new socket options.  These extensions
-   are designed to provide access to the basic IPv6 features required by
-   TCP and UDP applications, including multicasting, while introducing a
-   minimum of change into the system and providing complete
-   compatibility for existing IPv4 applications.  Additional extensions
-   for advanced IPv6 features (raw sockets and access to the IPv6
-   extension headers) are defined in another document.
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                      [Page 1]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-Table of Contents
-
-   1.  Introduction................................................3
-   2.  Design Considerations.......................................4
-       2.1  What Needs to be Changed...............................4
-       2.2  Data Types.............................................6
-       2.3  Headers................................................6
-       2.4  Structures.............................................6
-   3.  Socket Interface............................................6
-       3.1  IPv6 Address Family and Protocol Family................6
-       3.2  IPv6 Address Structure.................................7
-       3.3  Socket Address Structure for 4.3BSD-Based Systems......7
-       3.4  Socket Address Structure for 4.4BSD-Based Systems......9
-       3.5  The Socket Functions...................................9
-       3.6  Compatibility with IPv4 Applications..................10
-       3.7  Compatibility with IPv4 Nodes.........................11
-       3.8  IPv6 Wildcard Address.................................11
-       3.9  IPv6 Loopback Address.................................13
-       3.10 Portability Additions.................................14
-   4.  Interface Identification...................................16
-       4.1  Name-to-Index.........................................17
-       4.2  Index-to-Name.........................................17
-       4.3  Return All Interface Names and Indexes................18
-       4.4  Free Memory...........................................18
-   5.  Socket Options.............................................18
-       5.1  Unicast Hop Limit.....................................19
-       5.2  Sending and Receiving Multicast Packets...............19
-       5.3  IPV6_V6ONLY option for AF_INET6 Sockets...............22
-   6.  Library Functions..........................................22
-       6.1  Protocol-Independent Nodename and
-            Service Name Translation..............................23
-       6.2  Socket Address Structure to Node Name
-            and Service Name......................................28
-       6.3  Address Conversion Functions..........................31
-       6.4  Address Testing Macros................................33
-   7.  Summary of New Definitions.................................33
-   8.  Security Considerations....................................35
-   9.  Changes from RFC 2553......................................35
-   10. Acknowledgments............................................36
-   11. References.................................................37
-   12. Authors' Addresses.........................................38
-   13. Full Copyright Statement...................................39
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                      [Page 2]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-1. Introduction
-
-   While IPv4 addresses are 32 bits long, IPv6 addresses are 128 bits
-   long.  The socket interface makes the size of an IP address quite
-   visible to an application; virtually all TCP/IP applications for
-   BSD-based systems have knowledge of the size of an IP address.  Those
-   parts of the API that expose the addresses must be changed to
-   accommodate the larger IPv6 address size.  IPv6 also introduces new
-   features, some of which must be made visible to applications via the
-   API.  This memo defines a set of extensions to the socket interface
-   to support the larger address size and new features of IPv6.  It
-   defines "basic" extensions that are of use to a broad range of
-   applications.  A companion document, the "advanced" API [4], covers
-   extensions that are of use to more specialized applications, examples
-   of which include routing daemons, and the "ping" and "traceroute"
-   utilities.
-
-   The development of this API was started in 1994 in the IETF IPng
-   working group.  The API has evolved over the years, published first
-   in RFC 2133, then again in RFC 2553, and reaching its final form in
-   this document.
-
-   As the API matured and stabilized, it was incorporated into the Open
-   Group's Networking Services (XNS) specification, issue 5.2, which was
-   subsequently incorporated into a joint Open Group/IEEE/ISO standard
-   [3].
-
-   Effort has been made to ensure that this document and [3] contain the
-   same information with regard to the API definitions.  However, the
-   reader should note that this document is for informational purposes
-   only, and that the official standard specification of the sockets API
-   is [3].
-
-   It is expected that any future standardization work on this API would
-   be done by the Open Group Base Working Group [6].
-
-   It should also be noted that this document describes only those
-   portions of the API needed for IPv4 and IPv6 communications.  Other
-   potential uses of the API, for example the use of getaddrinfo() and
-   getnameinfo() with the AF_UNIX address family, are beyond the scope
-   of this document.
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                      [Page 3]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-2. Design Considerations
-
-   There are a number of important considerations in designing changes
-   to this well-worn API:
-
-   -  The API changes should provide both source and binary
-      compatibility for programs written to the original API.  That is,
-      existing program binaries should continue to operate when run on a
-      system supporting the new API.  In addition, existing applications
-      that are re-compiled and run on a system supporting the new API
-      should continue to operate.  Simply put, the API changes for IPv6
-      should not break existing programs.  An additional mechanism for
-      implementations to verify this is to verify the new symbols are
-      protected by Feature Test Macros as described in [3].  (Such
-      Feature Test Macros are not defined by this RFC.)
-
-   -  The changes to the API should be as small as possible in order to
-      simplify the task of converting existing IPv4 applications to
-      IPv6.
-
-   -  Where possible, applications should be able to use this API to
-      interoperate with both IPv6 and IPv4 hosts.  Applications should
-      not need to know which type of host they are communicating with.
-
-   -  IPv6 addresses carried in data structures should be 64-bit
-      aligned.  This is necessary in order to obtain optimum performance
-      on 64-bit machine architectures.
-
-   Because of the importance of providing IPv4 compatibility in the API,
-   these extensions are explicitly designed to operate on machines that
-   provide complete support for both IPv4 and IPv6.  A subset of this
-   API could probably be designed for operation on systems that support
-   only IPv6.  However, this is not addressed in this memo.
-
-2.1 What Needs to be Changed
-
-   The socket interface API consists of a few distinct components:
-
-   -  Core socket functions.
-
-   -  Address data structures.
-
-   -  Name-to-address translation functions.
-
-   -  Address conversion functions.
-
-
-
-
-
-
-Gilligan, et al.             Informational                      [Page 4]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   The core socket functions -- those functions that deal with such
-   things as setting up and tearing down TCP connections, and sending
-   and receiving UDP packets -- were designed to be transport
-   independent.  Where protocol addresses are passed as function
-   arguments, they are carried via opaque pointers.  A protocol-specific
-   address data structure is defined for each protocol that the socket
-   functions support.  Applications must cast pointers to these
-   protocol-specific address structures into pointers to the generic
-   "sockaddr" address structure when using the socket functions.  These
-   functions need not change for IPv6, but a new IPv6-specific address
-   data structure is needed.
-
-   The "sockaddr_in" structure is the protocol-specific data structure
-   for IPv4.  This data structure actually includes 8-octets of unused
-   space, and it is tempting to try to use this space to adapt the
-   sockaddr_in structure to IPv6.  Unfortunately, the sockaddr_in
-   structure is not large enough to hold the 16-octet IPv6 address as
-   well as the other information (address family and port number) that
-   is needed.  So a new address data structure must be defined for IPv6.
-
-   IPv6 addresses are scoped [2] so they could be link-local, site,
-   organization, global, or other scopes at this time undefined.  To
-   support applications that want to be able to identify a set of
-   interfaces for a specific scope, the IPv6 sockaddr_in structure must
-   support a field that can be used by an implementation to identify a
-   set of interfaces identifying the scope for an IPv6 address.
-
-   The IPv4 name-to-address translation functions in the socket
-   interface are gethostbyname() and gethostbyaddr().  These are left as
-   is, and new functions are defined which support both IPv4 and IPv6.
-
-   The IPv4 address conversion functions -- inet_ntoa() and inet_addr()
-   -- convert IPv4 addresses between binary and printable form.  These
-   functions are quite specific to 32-bit IPv4 addresses.  We have
-   designed two analogous functions that convert both IPv4 and IPv6
-   addresses, and carry an address type parameter so that they can be
-   extended to other protocol families as well.
-
-   Finally, a few miscellaneous features are needed to support IPv6.  A
-   new interface is needed to support the IPv6 hop limit header field.
-   New socket options are needed to control the sending and receiving of
-   IPv6 multicast packets.
-
-   The socket interface will be enhanced in the future to provide access
-   to other IPv6 features.  Some of these extensions are described in
-   [4].
-
-
-
-
-
-Gilligan, et al.             Informational                      [Page 5]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-2.2 Data Types
-
-   The data types of the structure elements given in this memo are
-   intended to track the relevant standards.  uintN_t means an unsigned
-   integer of exactly N bits (e.g., uint16_t).  The sa_family_t and
-   in_port_t types are defined in [3].
-
-2.3 Headers
-
-   When function prototypes and structures are shown we show the headers
-   that must be #included to cause that item to be defined.
-
-2.4 Structures
-
-   When structures are described the members shown are the ones that
-   must appear in an implementation.  Additional, nonstandard members
-   may also be defined by an implementation.  As an additional
-   precaution nonstandard members could be verified by Feature Test
-   Macros as described in [3].  (Such Feature Test Macros are not
-   defined by this RFC.)
-
-   The ordering shown for the members of a structure is the recommended
-   ordering, given alignment considerations of multibyte members, but an
-   implementation may order the members differently.
-
-3. Socket Interface
-
-   This section specifies the socket interface changes for IPv6.
-
-3.1 IPv6 Address Family and Protocol Family
-
-   A new address family name, AF_INET6, is defined in <sys/socket.h>.
-   The AF_INET6 definition distinguishes between the original
-   sockaddr_in address data structure, and the new sockaddr_in6 data
-   structure.
-
-   A new protocol family name, PF_INET6, is defined in <sys/socket.h>.
-   Like most of the other protocol family names, this will usually be
-   defined to have the same value as the corresponding address family
-   name:
-
-      #define PF_INET6        AF_INET6
-
-   The AF_INET6 is used in the first argument to the socket() function
-   to indicate that an IPv6 socket is being created.
-
-
-
-
-
-
-Gilligan, et al.             Informational                      [Page 6]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-3.2 IPv6 Address Structure
-
-   A new in6_addr structure holds a single IPv6 address and is defined
-   as a result of including <netinet/in.h>:
-
-      struct in6_addr {
-          uint8_t  s6_addr[16];      /* IPv6 address */
-      };
-
-   This data structure contains an array of sixteen 8-bit elements,
-   which make up one 128-bit IPv6 address.  The IPv6 address is stored
-   in network byte order.
-
-   The structure in6_addr above is usually implemented with an embedded
-   union with extra fields that force the desired alignment level in a
-   manner similar to BSD implementations of "struct in_addr".  Those
-   additional implementation details are omitted here for simplicity.
-
-   An example is as follows:
-
-   struct in6_addr {
-        union {
-            uint8_t  _S6_u8[16];
-            uint32_t _S6_u32[4];
-            uint64_t _S6_u64[2];
-        } _S6_un;
-   };
-   #define s6_addr _S6_un._S6_u8
-
-3.3 Socket Address Structure for 4.3BSD-Based Systems
-
-   In the socket interface, a different protocol-specific data structure
-   is defined to carry the addresses for each protocol suite.  Each
-   protocol-specific data structure is designed so it can be cast into a
-   protocol-independent data structure -- the "sockaddr" structure.
-   Each has a "family" field that overlays the "sa_family" of the
-   sockaddr data structure.  This field identifies the type of the data
-   structure.
-
-   The sockaddr_in structure is the protocol-specific address data
-   structure for IPv4.  It is used to pass addresses between
-   applications and the system in the socket functions.  The following
-   sockaddr_in6 structure holds IPv6 addresses and is defined as a
-   result of including the <netinet/in.h> header:
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                      [Page 7]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-struct sockaddr_in6 {
-    sa_family_t     sin6_family;    /* AF_INET6 */
-    in_port_t       sin6_port;      /* transport layer port # */
-    uint32_t        sin6_flowinfo;  /* IPv6 flow information */
-    struct in6_addr sin6_addr;      /* IPv6 address */
-    uint32_t        sin6_scope_id;  /* set of interfaces for a scope */
-};
-
-   This structure is designed to be compatible with the sockaddr data
-   structure used in the 4.3BSD release.
-
-   The sin6_family field identifies this as a sockaddr_in6 structure.
-   This field overlays the sa_family field when the buffer is cast to a
-   sockaddr data structure.  The value of this field must be AF_INET6.
-
-   The sin6_port field contains the 16-bit UDP or TCP port number.  This
-   field is used in the same way as the sin_port field of the
-   sockaddr_in structure.  The port number is stored in network byte
-   order.
-
-   The sin6_flowinfo field is a 32-bit field intended to contain flow-
-   related information.  The exact way this field is mapped to or from a
-   packet is not currently specified.  Until such time as its use is
-   specified, applications should set this field to zero when
-   constructing a sockaddr_in6, and ignore this field in a sockaddr_in6
-   structure constructed by the system.
-
-   The sin6_addr field is a single in6_addr structure (defined in the
-   previous section).  This field holds one 128-bit IPv6 address.  The
-   address is stored in network byte order.
-
-   The ordering of elements in this structure is specifically designed
-   so that when sin6_addr field is aligned on a 64-bit boundary, the
-   start of the structure will also be aligned on a 64-bit boundary.
-   This is done for optimum performance on 64-bit architectures.
-
-   The sin6_scope_id field is a 32-bit integer that identifies a set of
-   interfaces as appropriate for the scope [2] of the address carried in
-   the sin6_addr field.  The mapping of sin6_scope_id to an interface or
-   set of interfaces is left to implementation and future specifications
-   on the subject of scoped addresses.
-
-   Notice that the sockaddr_in6 structure will normally be larger than
-   the generic sockaddr structure.  On many existing implementations the
-   sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both
-   being 16 bytes.  Any existing code that makes this assumption needs
-   to be examined carefully when converting to IPv6.
-
-
-
-
-Gilligan, et al.             Informational                      [Page 8]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-3.4 Socket Address Structure for 4.4BSD-Based Systems
-
-   The 4.4BSD release includes a small, but incompatible change to the
-   socket interface.  The "sa_family" field of the sockaddr data
-   structure was changed from a 16-bit value to an 8-bit value, and the
-   space saved used to hold a length field, named "sa_len".  The
-   sockaddr_in6 data structure given in the previous section cannot be
-   correctly cast into the newer sockaddr data structure.  For this
-   reason, the following alternative IPv6 address data structure is
-   provided to be used on systems based on 4.4BSD.  It is defined as a
-   result of including the <netinet/in.h> header.
-
-struct sockaddr_in6 {
-    uint8_t         sin6_len;       /* length of this struct */
-    sa_family_t     sin6_family;    /* AF_INET6 */
-    in_port_t       sin6_port;      /* transport layer port # */
-    uint32_t        sin6_flowinfo;  /* IPv6 flow information */
-    struct in6_addr sin6_addr;      /* IPv6 address */
-    uint32_t        sin6_scope_id;  /* set of interfaces for a scope */
-};
-
-   The only differences between this data structure and the 4.3BSD
-   variant are the inclusion of the length field, and the change of the
-   family field to a 8-bit data type.  The definitions of all the other
-   fields are identical to the structure defined in the previous
-   section.
-
-   Systems that provide this version of the sockaddr_in6 data structure
-   must also declare SIN6_LEN as a result of including the
-   <netinet/in.h> header.  This macro allows applications to determine
-   whether they are being built on a system that supports the 4.3BSD or
-   4.4BSD variants of the data structure.
-
-3.5 The Socket Functions
-
-   Applications call the socket() function to create a socket descriptor
-   that represents a communication endpoint.  The arguments to the
-   socket() function tell the system which protocol to use, and what
-   format address structure will be used in subsequent functions.  For
-   example, to create an IPv4/TCP socket, applications make the call:
-
-      s = socket(AF_INET, SOCK_STREAM, 0);
-
-   To create an IPv4/UDP socket, applications make the call:
-
-      s = socket(AF_INET, SOCK_DGRAM, 0);
-
-
-
-
-
-Gilligan, et al.             Informational                      [Page 9]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   Applications may create IPv6/TCP and IPv6/UDP sockets (which may also
-   handle IPv4 communication as described in section 3.7) by simply
-   using the constant AF_INET6 instead of AF_INET in the first argument.
-   For example, to create an IPv6/TCP socket, applications make the
-   call:
-
-      s = socket(AF_INET6, SOCK_STREAM, 0);
-
-   To create an IPv6/UDP socket, applications make the call:
-
-      s = socket(AF_INET6, SOCK_DGRAM, 0);
-
-   Once the application has created a AF_INET6 socket, it must use the
-   sockaddr_in6 address structure when passing addresses in to the
-   system.  The functions that the application uses to pass addresses
-   into the system are:
-
-      bind()
-      connect()
-      sendmsg()
-      sendto()
-
-   The system will use the sockaddr_in6 address structure to return
-   addresses to applications that are using AF_INET6 sockets.  The
-   functions that return an address from the system to an application
-   are:
-
-      accept()
-      recvfrom()
-      recvmsg()
-      getpeername()
-      getsockname()
-
-   No changes to the syntax of the socket functions are needed to
-   support IPv6, since all of the "address carrying" functions use an
-   opaque address pointer, and carry an address length as a function
-   argument.
-
-3.6 Compatibility with IPv4 Applications
-
-   In order to support the large base of applications using the original
-   API, system implementations must provide complete source and binary
-   compatibility with the original API.  This means that systems must
-   continue to support AF_INET sockets and the sockaddr_in address
-   structure.  Applications must be able to create IPv4/TCP and IPv4/UDP
-   sockets using the AF_INET constant in the socket() function, as
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 10]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   described in the previous section.  Applications should be able to
-   hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP
-   sockets simultaneously within the same process.
-
-   Applications using the original API should continue to operate as
-   they did on systems supporting only IPv4.  That is, they should
-   continue to interoperate with IPv4 nodes.
-
-3.7 Compatibility with IPv4 Nodes
-
-   The API also provides a different type of compatibility: the ability
-   for IPv6 applications to interoperate with IPv4 applications.  This
-   feature uses the IPv4-mapped IPv6 address format defined in the IPv6
-   addressing architecture specification [2].  This address format
-   allows the IPv4 address of an IPv4 node to be represented as an IPv6
-   address.  The IPv4 address is encoded into the low-order 32 bits of
-   the IPv6 address, and the high-order 96 bits hold the fixed prefix
-   0:0:0:0:0:FFFF.  IPv4-mapped addresses are written as follows:
-
-      ::FFFF:<IPv4-address>
-
-   These addresses can be generated automatically by the getaddrinfo()
-   function, as described in Section 6.1.
-
-   Applications may use AF_INET6 sockets to open TCP connections to IPv4
-   nodes, or send UDP packets to IPv4 nodes, by simply encoding the
-   destination's IPv4 address as an IPv4-mapped IPv6 address, and
-   passing that address, within a sockaddr_in6 structure, in the
-   connect() or sendto() call.  When applications use AF_INET6 sockets
-   to accept TCP connections from IPv4 nodes, or receive UDP packets
-   from IPv4 nodes, the system returns the peer's address to the
-   application in the accept(), recvfrom(), or getpeername() call using
-   a sockaddr_in6 structure encoded this way.
-
-   Few applications will likely need to know which type of node they are
-   interoperating with.  However, for those applications that do need to
-   know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.4, is
-   provided.
-
-3.8 IPv6 Wildcard Address
-
-   While the bind() function allows applications to select the source IP
-   address of UDP packets and TCP connections, applications often want
-   the system to select the source address for them.  With IPv4, one
-   specifies the address as the symbolic constant INADDR_ANY (called the
-   "wildcard" address) in the bind() call, or simply omits the bind()
-   entirely.
-
-
-
-
-Gilligan, et al.             Informational                     [Page 11]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   Since the IPv6 address type is a structure (struct in6_addr), a
-   symbolic constant can be used to initialize an IPv6 address variable,
-   but cannot be used in an assignment.  Therefore systems provide the
-   IPv6 wildcard address in two forms.
-
-   The first version is a global variable named "in6addr_any" that is an
-   in6_addr structure.  The extern declaration for this variable is
-   defined in <netinet/in.h>:
-
-      extern const struct in6_addr in6addr_any;
-
-   Applications use in6addr_any similarly to the way they use INADDR_ANY
-   in IPv4.  For example, to bind a socket to port number 23, but let
-   the system select the source address, an application could use the
-   following code:
-
-      struct sockaddr_in6 sin6;
-       . . .
-      sin6.sin6_family = AF_INET6;
-      sin6.sin6_flowinfo = 0;
-      sin6.sin6_port = htons(23);
-      sin6.sin6_addr = in6addr_any;  /* structure assignment */
-       . . .
-      if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
-              . . .
-
-   The other version is a symbolic constant named IN6ADDR_ANY_INIT and
-   is defined in <netinet/in.h>.  This constant can be used to
-   initialize an in6_addr structure:
-
-      struct in6_addr anyaddr = IN6ADDR_ANY_INIT;
-
-   Note that this constant can be used ONLY at declaration time.  It can
-   not be used to assign a previously declared in6_addr structure.  For
-   example, the following code will not work:
-
-      /* This is the WRONG way to assign an unspecified address */
-      struct sockaddr_in6 sin6;
-       . . .
-      sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */
-
-   Be aware that the IPv4 INADDR_xxx constants are all defined in host
-   byte order but the IPv6 IN6ADDR_xxx constants and the IPv6
-   in6addr_xxx externals are defined in network byte order.
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 12]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-3.9 IPv6 Loopback Address
-
-   Applications may need to send UDP packets to, or originate TCP
-   connections to, services residing on the local node.  In IPv4, they
-   can do this by using the constant IPv4 address INADDR_LOOPBACK in
-   their connect(), sendto(), or sendmsg() call.
-
-   IPv6 also provides a loopback address to contact local TCP and UDP
-   services.  Like the unspecified address, the IPv6 loopback address is
-   provided in two forms -- a global variable and a symbolic constant.
-
-   The global variable is an in6_addr structure named
-   "in6addr_loopback."  The extern declaration for this variable is
-   defined in <netinet/in.h>:
-
-      extern const struct in6_addr in6addr_loopback;
-
-   Applications use in6addr_loopback as they would use INADDR_LOOPBACK
-   in IPv4 applications (but beware of the byte ordering difference
-   mentioned at the end of the previous section).  For example, to open
-   a TCP connection to the local telnet server, an application could use
-   the following code:
-
-   struct sockaddr_in6 sin6;
-    . . .
-   sin6.sin6_family = AF_INET6;
-   sin6.sin6_flowinfo = 0;
-   sin6.sin6_port = htons(23);
-   sin6.sin6_addr = in6addr_loopback;  /* structure assignment */
-    . . .
-   if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
-           . . .
-
-   The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined
-   in <netinet/in.h>.  It can be used at declaration time ONLY; for
-   example:
-
-      struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT;
-
-   Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment
-   to a previously declared IPv6 address variable.
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 13]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-3.10 Portability Additions
-
-   One simple addition to the sockets API that can help application
-   writers is the "struct sockaddr_storage".  This data structure can
-   simplify writing code that is portable across multiple address
-   families and platforms.  This data structure is designed with the
-   following goals.
-
-   - Large enough to accommodate all supported protocol-specific address
-      structures.
-
-   - Aligned at an appropriate boundary so that pointers to it can be
-      cast as pointers to protocol specific address structures and used
-      to access the fields of those structures without alignment
-      problems.
-
-   The sockaddr_storage structure contains field ss_family which is of
-   type sa_family_t.  When a sockaddr_storage structure is cast to a
-   sockaddr structure, the ss_family field of the sockaddr_storage
-   structure maps onto the sa_family field of the sockaddr structure.
-   When a sockaddr_storage structure is cast as a protocol specific
-   address structure, the ss_family field maps onto a field of that
-   structure that is of type sa_family_t and that identifies the
-   protocol's address family.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 14]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   An example implementation design of such a data structure would be as
-   follows.
-
-/*
- * Desired design of maximum size and alignment
- */
-#define _SS_MAXSIZE    128  /* Implementation specific max size */
-#define _SS_ALIGNSIZE  (sizeof (int64_t))
-                         /* Implementation specific desired alignment */
-/*
- * Definitions used for sockaddr_storage structure paddings design.
- */
-#define _SS_PAD1SIZE   (_SS_ALIGNSIZE - sizeof (sa_family_t))
-#define _SS_PAD2SIZE   (_SS_MAXSIZE - (sizeof (sa_family_t) +
-                              _SS_PAD1SIZE + _SS_ALIGNSIZE))
-struct sockaddr_storage {
-    sa_family_t  ss_family;     /* address family */
-    /* Following fields are implementation specific */
-    char      __ss_pad1[_SS_PAD1SIZE];
-              /* 6 byte pad, this is to make implementation
-              /* specific pad up to alignment field that */
-              /* follows explicit in the data structure */
-    int64_t   __ss_align;     /* field to force desired structure */
-               /* storage alignment */
-    char      __ss_pad2[_SS_PAD2SIZE];
-              /* 112 byte pad to achieve desired size, */
-              /* _SS_MAXSIZE value minus size of ss_family */
-              /* __ss_pad1, __ss_align fields is 112 */
-};
-
-   The above example implementation illustrates a data structure which
-   will align on a 64-bit boundary.  An implementation-specific field
-   "__ss_align" along with "__ss_pad1" is used to force a 64-bit
-   alignment which covers proper alignment good enough for the needs of
-   sockaddr_in6 (IPv6), sockaddr_in (IPv4) address data structures.  The
-   size of padding field __ss_pad1 depends on the chosen alignment
-   boundary.  The size of padding field __ss_pad2 depends on the value
-   of overall size chosen for the total size of the structure.  This
-   size and alignment are represented in the above example by
-   implementation specific (not required) constants _SS_MAXSIZE (chosen
-   value 128) and _SS_ALIGNSIZE (with chosen value 8).  Constants
-   _SS_PAD1SIZE (derived value 6) and _SS_PAD2SIZE (derived value 112)
-   are also for illustration and not required.  The derived values
-   assume sa_family_t is 2 bytes.  The implementation specific
-   definitions and structure field names above start with an underscore
-   to denote implementation private namespace.  Portable code is not
-   expected to access or reference those fields or constants.
-
-
-
-
-Gilligan, et al.             Informational                     [Page 15]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   On implementations where the sockaddr data structure includes a
-   "sa_len" field this data structure would look like this:
-
-/*
- * Definitions used for sockaddr_storage structure paddings design.
- */
-#define _SS_PAD1SIZE (_SS_ALIGNSIZE -
-                            (sizeof (uint8_t) + sizeof (sa_family_t))
-#define _SS_PAD2SIZE (_SS_MAXSIZE -
-                            (sizeof (uint8_t) + sizeof (sa_family_t) +
-                             _SS_PAD1SIZE + _SS_ALIGNSIZE))
-struct sockaddr_storage {
-    uint8_t      ss_len;        /* address length */
-    sa_family_t  ss_family;     /* address family */
-    /* Following fields are implementation specific */
-    char         __ss_pad1[_SS_PAD1SIZE];
-                  /* 6 byte pad, this is to make implementation
-                  /* specific pad up to alignment field that */
-                  /* follows explicit in the data structure */
-    int64_t      __ss_align;  /* field to force desired structure */
-                  /* storage alignment */
-    char         __ss_pad2[_SS_PAD2SIZE];
-                  /* 112 byte pad to achieve desired size, */
-                  /* _SS_MAXSIZE value minus size of ss_len, */
-                  /* __ss_family, __ss_pad1, __ss_align fields is 112 */
-};
-
-4. Interface Identification
-
-   This API uses an interface index (a small positive integer) to
-   identify the local interface on which a multicast group is joined
-   (Section 5.2).  Additionally, the advanced API [4] uses these same
-   interface indexes to identify the interface on which a datagram is
-   received, or to specify the interface on which a datagram is to be
-   sent.
-
-   Interfaces are normally known by names such as "le0", "sl1", "ppp2",
-   and the like.  On Berkeley-derived implementations, when an interface
-   is made known to the system, the kernel assigns a unique positive
-   integer value (called the interface index) to that interface.  These
-   are small positive integers that start at 1.  (Note that 0 is never
-   used for an interface index.)  There may be gaps so that there is no
-   current interface for a particular positive interface index.
-
-   This API defines two functions that map between an interface name and
-   index, a third function that returns all the interface names and
-   indexes, and a fourth function to return the dynamic memory allocated
-   by the previous function.  How these functions are implemented is
-
-
-
-Gilligan, et al.             Informational                     [Page 16]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   left up to the implementation.  4.4BSD implementations can implement
-   these functions using the existing sysctl() function with the
-   NET_RT_IFLIST command.  Other implementations may wish to use ioctl()
-   for this purpose.
-
-4.1 Name-to-Index
-
-   The first function maps an interface name into its corresponding
-   index.
-
-      #include <net/if.h>
-
-      unsigned int  if_nametoindex(const char *ifname);
-
-   If ifname is the name of an interface, the if_nametoindex() function
-   shall return the interface index corresponding to name ifname;
-   otherwise, it shall return zero.  No errors are defined.
-
-4.2 Index-to-Name
-
-   The second function maps an interface index into its corresponding
-   name.
-
-      #include <net/if.h>
-
-      char  *if_indextoname(unsigned int ifindex, char *ifname);
-
-   When this function is called, the ifname argument shall point to a
-   buffer of at least IF_NAMESIZE bytes.  The function shall place in
-   this buffer the name of the interface with index ifindex.
-   (IF_NAMESIZE is also defined in <net/if.h> and its value includes a
-   terminating null byte at the end of the interface name.)  If ifindex
-   is an interface index, then the function shall return the value
-   supplied in ifname, which points to a buffer now containing the
-   interface name.  Otherwise, the function shall return a NULL pointer
-   and set errno to indicate the error.  If there is no interface
-   corresponding to the specified index, errno is set to ENXIO.  If
-   there was a system error (such as running out of memory), errno would
-   be set to the proper value (e.g., ENOMEM).
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 17]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-4.3 Return All Interface Names and Indexes
-
-   The if_nameindex structure holds the information about a single
-   interface and is defined as a result of including the <net/if.h>
-   header.
-
-   struct if_nameindex {
-     unsigned int   if_index;  /* 1, 2, ... */
-     char          *if_name;   /* null terminated name: "le0", ... */
-   };
-
-   The final function returns an array of if_nameindex structures, one
-   structure per interface.
-
-      #include <net/if.h>
-
-      struct if_nameindex  *if_nameindex(void);
-
-   The end of the array of structures is indicated by a structure with
-   an if_index of 0 and an if_name of NULL.  The function returns a NULL
-   pointer upon an error, and would set errno to the appropriate value.
-
-   The memory used for this array of structures along with the interface
-   names pointed to by the if_name members is obtained dynamically.
-   This memory is freed by the next function.
-
-4.4 Free Memory
-
-   The following function frees the dynamic memory that was allocated by
-   if_nameindex().
-
-      #include <net/if.h>
-
-      void  if_freenameindex(struct if_nameindex *ptr);
-
-   The ptr argument shall be a pointer that was returned by
-   if_nameindex().  After if_freenameindex() has been called, the
-   application shall not use the array of which ptr is the address.
-
-5. Socket Options
-
-   A number of new socket options are defined for IPv6.  All of these
-   new options are at the IPPROTO_IPV6 level.  That is, the "level"
-   parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6
-   when using these options.  The constant name prefix IPV6_ is used in
-   all of the new socket options.  This serves to clearly identify these
-   options as applying to IPv6.
-
-
-
-
-Gilligan, et al.             Informational                     [Page 18]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   The declaration for IPPROTO_IPV6, the new IPv6 socket options, and
-   related constants defined in this section are obtained by including
-   the header <netinet/in.h>.
-
-5.1 Unicast Hop Limit
-
-   A new setsockopt() option controls the hop limit used in outgoing
-   unicast IPv6 packets.  The name of this option is IPV6_UNICAST_HOPS,
-   and it is used at the IPPROTO_IPV6 layer.  The following example
-   illustrates how it is used:
-
-   int  hoplimit = 10;
-
-   if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
-                  (char *) &hoplimit, sizeof(hoplimit)) == -1)
-       perror("setsockopt IPV6_UNICAST_HOPS");
-
-   When the IPV6_UNICAST_HOPS option is set with setsockopt(), the
-   option value given is used as the hop limit for all subsequent
-   unicast packets sent via that socket.  If the option is not set, the
-   system selects a default value.  The integer hop limit value (called
-   x) is interpreted as follows:
-
-      x < -1:        return an error of EINVAL
-      x == -1:       use kernel default
-      0 <= x <= 255: use x
-      x >= 256:      return an error of EINVAL
-
-   The IPV6_UNICAST_HOPS option may be used with getsockopt() to
-   determine the hop limit value that the system will use for subsequent
-   unicast packets sent via that socket.  For example:
-
-      int  hoplimit;
-      socklen_t  len = sizeof(hoplimit);
-
-      if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
-                     (char *) &hoplimit, &len) == -1)
-          perror("getsockopt IPV6_UNICAST_HOPS");
-      else
-          printf("Using %d for hop limit.\n", hoplimit);
-
-5.2 Sending and Receiving Multicast Packets
-
-   IPv6 applications may send multicast packets by simply specifying an
-   IPv6 multicast address as the destination address, for example in the
-   destination address argument of the sendto() function.
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 19]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   Three socket options at the IPPROTO_IPV6 layer control some of the
-   parameters for sending multicast packets.  Setting these options is
-   not required: applications may send multicast packets without using
-   these options.  The setsockopt() options for controlling the sending
-   of multicast packets are summarized below.  These three options can
-   also be used with getsockopt().
-
-      IPV6_MULTICAST_IF
-
-         Set the interface to use for outgoing multicast packets.  The
-         argument is the index of the interface to use.  If the
-         interface index is specified as zero, the system selects the
-         interface (for example, by looking up the address in a routing
-         table and using the resulting interface).
-
-         Argument type: unsigned int
-
-      IPV6_MULTICAST_HOPS
-
-         Set the hop limit to use for outgoing multicast packets.  (Note
-         a separate option - IPV6_UNICAST_HOPS - is provided to set the
-         hop limit to use for outgoing unicast packets.)
-
-         The interpretation of the argument is the same as for the
-         IPV6_UNICAST_HOPS option:
-
-            x < -1:        return an error of EINVAL
-            x == -1:       use kernel default
-            0 <= x <= 255: use x
-            x >= 256:      return an error of EINVAL
-
-            If IPV6_MULTICAST_HOPS is not set, the default is 1
-            (same as IPv4 today)
-
-         Argument type: int
-
-      IPV6_MULTICAST_LOOP
-
-         If a multicast datagram is sent to a group to which the sending
-         host itself belongs (on the outgoing interface), a copy of the
-         datagram is looped back by the IP layer for local delivery if
-         this option is set to 1.  If this option is set to 0 a copy is
-         not looped back.  Other option values return an error of
-         EINVAL.
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 20]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-         If IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback;
-         same as IPv4 today).
-
-         Argument type: unsigned int
-
-   The reception of multicast packets is controlled by the two
-   setsockopt() options summarized below.  An error of EOPNOTSUPP is
-   returned if these two options are used with getsockopt().
-
-      IPV6_JOIN_GROUP
-
-         Join a multicast group on a specified local interface.
-         If the interface index is specified as 0,
-         the kernel chooses the local interface.
-         For example, some kernels look up the multicast group
-         in the normal IPv6 routing table and use the resulting
-         interface.
-
-         Argument type: struct ipv6_mreq
-
-      IPV6_LEAVE_GROUP
-
-         Leave a multicast group on a specified interface.
-         If the interface index is specified as 0, the system
-         may choose a multicast group membership to drop by
-         matching the multicast address only.
-
-         Argument type: struct ipv6_mreq
-
-   The argument type of both of these options is the ipv6_mreq
-   structure, defined as a result of including the <netinet/in.h>
-   header;
-
-   struct ipv6_mreq {
-       struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
-       unsigned int    ipv6mr_interface; /* interface index */
-   };
-
-   Note that to receive multicast datagrams a process must join the
-   multicast group to which datagrams will be sent.  UDP applications
-   must also bind the UDP port to which datagrams will be sent.  Some
-   processes also bind the multicast group address to the socket, in
-   addition to the port, to prevent other datagrams destined to that
-   same port from being delivered to the socket.
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 21]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-5.3 IPV6_V6ONLY option for AF_INET6 Sockets
-
-   This socket option restricts AF_INET6 sockets to IPv6 communications
-   only.  As stated in section <3.7 Compatibility with IPv4 Nodes>,
-   AF_INET6 sockets may be used for both IPv4 and IPv6 communications.
-   Some applications may want to restrict their use of an AF_INET6
-   socket to IPv6 communications only.  For these applications the
-   IPV6_V6ONLY socket option is defined.  When this option is turned on,
-   the socket can be used to send and receive IPv6 packets only.  This
-   is an IPPROTO_IPV6 level option.  This option takes an int value.
-   This is a boolean option.  By default this option is turned off.
-
-   Here is an example of setting this option:
-
-      int on = 1;
-
-      if (setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY,
-                     (char *)&on, sizeof(on)) == -1)
-          perror("setsockopt IPV6_V6ONLY");
-      else
-          printf("IPV6_V6ONLY set\n");
-
-   Note - This option has no effect on the use of IPv4 Mapped addresses
-   which enter a node as a valid IPv6 addresses for IPv6 communications
-   as defined by Stateless IP/ICMP Translation Algorithm (SIIT) [5].
-
-   An example use of this option is to allow two versions of the same
-   server process to run on the same port, one providing service over
-   IPv6, the other providing the same service over IPv4.
-
-6. Library Functions
-
-   New library functions are needed to perform a variety of operations
-   with IPv6 addresses.  Functions are needed to lookup IPv6 addresses
-   in the Domain Name System (DNS).  Both forward lookup (nodename-to-
-   address translation) and reverse lookup (address-to-nodename
-   translation) need to be supported.  Functions are also needed to
-   convert IPv6 addresses between their binary and textual form.
-
-   We note that the two existing functions, gethostbyname() and
-   gethostbyaddr(), are left as-is.  New functions are defined to handle
-   both IPv4 and IPv6 addresses.
-
-   The commonly used function gethostbyname() is inadequate for many
-   applications, first because it provides no way for the caller to
-   specify anything about the types of addresses desired (IPv4 only,
-   IPv6 only, IPv4-mapped IPv6 are OK, etc.), and second because many
-   implementations of this function are not thread safe.  RFC 2133
-
-
-
-Gilligan, et al.             Informational                     [Page 22]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   defined a function named gethostbyname2() but this function was also
-   inadequate, first because its use required setting a global option
-   (RES_USE_INET6) when IPv6 addresses were required, and second because
-   a flag argument is needed to provide the caller with additional
-   control over the types of addresses required.  The gethostbyname2()
-   function was deprecated in RFC 2553 and is no longer part of the
-   basic API.
-
-6.1 Protocol-Independent Nodename and Service Name Translation
-
-   Nodename-to-address translation is done in a protocol-independent
-   fashion using the getaddrinfo() function.
-
-#include <sys/socket.h>
-#include <netdb.h>
-
-
-int getaddrinfo(const char *nodename, const char *servname,
-                const struct addrinfo *hints, struct addrinfo **res);
-
-void freeaddrinfo(struct addrinfo *ai);
-
-struct addrinfo {
-  int     ai_flags;     /* AI_PASSIVE, AI_CANONNAME,
-                           AI_NUMERICHOST, .. */
-  int     ai_family;    /* AF_xxx */
-  int     ai_socktype;  /* SOCK_xxx */
-  int     ai_protocol;  /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
-  socklen_t  ai_addrlen;   /* length of ai_addr */
-  char   *ai_canonname; /* canonical name for nodename */
-  struct sockaddr  *ai_addr; /* binary address */
-  struct addrinfo  *ai_next; /* next structure in linked list */
-};
-
-   The getaddrinfo() function translates the name of a service location
-   (for example, a host name) and/or a service name and returns a set of
-   socket addresses and associated information to be used in creating a
-   socket with which to address the specified service.
-
-   The nodename and servname arguments are either null pointers or
-   pointers to null-terminated strings.  One or both of these two
-   arguments must be a non-null pointer.
-
-   The format of a valid name depends on the address family or families.
-   If a specific family is not given and the name could be interpreted
-   as valid within multiple supported families, the implementation will
-   attempt to resolve the name in all supported families and, in absence
-   of errors, one or more results shall be returned.
-
-
-
-Gilligan, et al.             Informational                     [Page 23]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   If the nodename argument is not null, it can be a descriptive name or
-   can be an address string.  If the specified address family is
-   AF_INET, AF_INET6, or AF_UNSPEC, valid descriptive names include host
-   names. If the specified address family is AF_INET or AF_UNSPEC,
-   address strings using Internet standard dot notation as specified in
-   inet_addr() are valid.  If the specified address family is AF_INET6
-   or AF_UNSPEC, standard IPv6 text forms described in inet_pton() are
-   valid.
-
-   If nodename is not null, the requested service location is named by
-   nodename; otherwise, the requested service location is local to the
-   caller.
-
-   If servname is null, the call shall return network-level addresses
-   for the specified nodename.  If servname is not null, it is a null-
-   terminated character string identifying the requested service.  This
-   can be either a descriptive name or a numeric representation suitable
-   for use with the address family or families.  If the specified
-   address family is AF_INET, AF_INET6 or AF_UNSPEC, the service can be
-   specified as a string specifying a decimal port number.
-
-   If the argument hints is not null, it refers to a structure
-   containing input values that may direct the operation by providing
-   options and by limiting the returned information to a specific socket
-   type, address family and/or protocol.  In this hints structure every
-   member other than ai_flags, ai_family, ai_socktype and ai_protocol
-   shall be set to zero or a null pointer.  A value of AF_UNSPEC for
-   ai_family means that the caller shall accept any address family.  A
-   value of zero for ai_socktype means that the caller shall accept any
-   socket type.  A value of zero for ai_protocol means that the caller
-   shall accept any protocol.  If hints is a null pointer, the behavior
-   shall be as if it referred to a structure containing the value zero
-   for the ai_flags, ai_socktype and ai_protocol fields, and AF_UNSPEC
-   for the ai_family field.
-
-   Note:
-
-   1. If the caller handles only TCP and not UDP, for example, then the
-      ai_protocol member of the hints structure should be set to
-      IPPROTO_TCP when getaddrinfo() is called.
-
-   2. If the caller handles only IPv4 and not IPv6, then the ai_family
-      member of the hints structure should be set to AF_INET when
-      getaddrinfo() is called.
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 24]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   The ai_flags field to which hints parameter points shall be set to
-   zero or be the bitwise-inclusive OR of one or more of the values
-   AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, AI_NUMERICSERV,
-   AI_V4MAPPED, AI_ALL, and AI_ADDRCONFIG.
-
-   If the AI_PASSIVE flag is specified, the returned address information
-   shall be suitable for use in binding a socket for accepting incoming
-   connections for the specified service (i.e., a call to bind()).  In
-   this case, if the nodename argument is null, then the IP address
-   portion of the socket address structure shall be set to INADDR_ANY
-   for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6 address.  If the
-   AI_PASSIVE flag is not specified, the returned address information
-   shall be suitable for a call to connect() (for a connection-mode
-   protocol) or for a call to connect(), sendto() or sendmsg() (for a
-   connectionless protocol).  In this case, if the nodename argument is
-   null, then the IP address portion of the socket address structure
-   shall be set to the loopback address.  This flag is ignored if the
-   nodename argument is not null.
-
-   If the AI_CANONNAME flag is specified and the nodename argument is
-   not null, the function shall attempt to determine the canonical name
-   corresponding to nodename (for example, if nodename is an alias or
-   shorthand notation for a complete name).
-
-   If the AI_NUMERICHOST flag is specified, then a non-null nodename
-   string supplied shall be a numeric host address string.  Otherwise,
-   an [EAI_NONAME] error is returned.  This flag shall prevent any type
-   of name resolution service (for example, the DNS) from being invoked.
-
-   If the AI_NUMERICSERV flag is specified, then a non-null servname
-   string supplied shall be a numeric port string.  Otherwise, an
-   [EAI_NONAME] error shall be returned.  This flag shall prevent any
-   type of name resolution service (for example, NIS+) from being
-   invoked.
-
-   If the AI_V4MAPPED flag is specified along with an ai_family of
-   AF_INET6, then getaddrinfo() shall return IPv4-mapped IPv6 addresses
-   on finding no matching IPv6 addresses (ai_addrlen shall be 16).
-
-      For example, when using the DNS, if no AAAA records are found then
-      a query is made for A records and any found are returned as IPv4-
-      mapped IPv6 addresses.
-
-   The AI_V4MAPPED flag shall be ignored unless ai_family equals
-   AF_INET6.
-
-   If the AI_ALL flag is used with the AI_V4MAPPED flag, then
-   getaddrinfo() shall return all matching IPv6 and IPv4 addresses.
-
-
-
-Gilligan, et al.             Informational                     [Page 25]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-      For example, when using the DNS, queries are made for both AAAA
-      records and A records, and getaddrinfo() returns the combined
-      results of both queries.  Any IPv4 addresses found are returned as
-      IPv4-mapped IPv6 addresses.
-
-   The AI_ALL flag without the AI_V4MAPPED flag is ignored.
-
-      Note:
-
-      When ai_family is not specified (AF_UNSPEC), AI_V4MAPPED and
-      AI_ALL flags will only be used if AF_INET6 is supported.
-
-   If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be
-   returned only if an IPv4 address is configured on the local system,
-   and IPv6 addresses shall be returned only if an IPv6 address is
-   configured on the local system.  The loopback address is not
-   considered for this case as valid as a configured address.
-
-      For example, when using the DNS, a query for AAAA records should
-      occur only if the node has at least one IPv6 address configured
-      (other than IPv6 loopback) and a query for A records should occur
-      only if the node has at least one IPv4 address configured (other
-      than the IPv4 loopback).
-
-   The ai_socktype field to which argument hints points specifies the
-   socket type for the service, as defined for socket().  If a specific
-   socket type is not given (for example, a value of zero) and the
-   service name could be interpreted as valid with multiple supported
-   socket types, the implementation shall attempt to resolve the service
-   name for all supported socket types and, in the absence of errors,
-   all possible results shall be returned.  A non-zero socket type value
-   shall limit the returned information to values with the specified
-   socket type.
-
-   If the ai_family field to which hints points has the value AF_UNSPEC,
-   addresses shall be returned for use with any address family that can
-   be used with the specified nodename and/or servname.  Otherwise,
-   addresses shall be returned for use only with the specified address
-   family.  If ai_family is not AF_UNSPEC and ai_protocol is not zero,
-   then addresses are returned for use only with the specified address
-   family and protocol; the value of ai_protocol shall be interpreted as
-   in a call to the socket() function with the corresponding values of
-   ai_family and ai_protocol.
-
-   The freeaddrinfo() function frees one or more addrinfo structures
-   returned by getaddrinfo(), along with any additional storage
-   associated with those structures (for example, storage pointed to by
-   the ai_canonname and ai_addr fields; an application must not
-
-
-
-Gilligan, et al.             Informational                     [Page 26]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   reference this storage after the associated addrinfo structure has
-   been freed).  If the ai_next field of the structure is not null, the
-   entire list of structures is freed.  The freeaddrinfo() function must
-   support the freeing of arbitrary sublists of an addrinfo list
-   originally returned by getaddrinfo().
-
-   Functions getaddrinfo() and freeaddrinfo() must be thread-safe.
-
-   A zero return value for getaddrinfo() indicates successful
-   completion; a non-zero return value indicates failure.  The possible
-   values for the failures are listed below under Error Return Values.
-
-   Upon successful return of getaddrinfo(), the location to which res
-   points shall refer to a linked list of addrinfo structures, each of
-   which shall specify a socket address and information for use in
-   creating a socket with which to use that socket address.  The list
-   shall include at least one addrinfo structure.  The ai_next field of
-   each structure contains a pointer to the next structure on the list,
-   or a null pointer if it is the last structure on the list.  Each
-   structure on the list shall include values for use with a call to the
-   socket() function, and a socket address for use with the connect()
-   function or, if the AI_PASSIVE flag was specified, for use with the
-   bind() function.  The fields ai_family, ai_socktype, and ai_protocol
-   shall be usable as the arguments to the socket() function to create a
-   socket suitable for use with the returned address.  The fields
-   ai_addr and ai_addrlen are usable as the arguments to the connect()
-   or bind() functions with such a socket, according to the AI_PASSIVE
-   flag.
-
-   If nodename is not null, and if requested by the AI_CANONNAME flag,
-   the ai_canonname field of the first returned addrinfo structure shall
-   point to a null-terminated string containing the canonical name
-   corresponding to the input nodename; if the canonical name is not
-   available, then ai_canonname shall refer to the nodename argument or
-   a string with the same contents.  The contents of the ai_flags field
-   of the returned structures are undefined.
-
-   All fields in socket address structures returned by getaddrinfo()
-   that are not filled in through an explicit argument (for example,
-   sin6_flowinfo) shall be set to zero.
-
-   Note: This makes it easier to compare socket address structures.
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 27]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   Error Return Values:
-
-   The getaddrinfo() function shall fail and return the corresponding
-   value if:
-
-   [EAI_AGAIN]     The name could not be resolved at this time.  Future
-                   attempts may succeed.
-
-   [EAI_BADFLAGS]  The flags parameter had an invalid value.
-
-   [EAI_FAIL]      A non-recoverable error occurred when attempting to
-                   resolve the name.
-
-   [EAI_FAMILY]    The address family was not recognized.
-
-   [EAI_MEMORY]    There was a memory allocation failure when trying to
-                   allocate storage for the return value.
-
-   [EAI_NONAME]    The name does not resolve for the supplied
-                   parameters.  Neither nodename nor servname were
-                   supplied.  At least one of these must be supplied.
-
-   [EAI_SERVICE]   The service passed was not recognized for the
-                   specified socket type.
-
-   [EAI_SOCKTYPE]  The intended socket type was not recognized.
-
-   [EAI_SYSTEM]    A system error occurred; the error code can be found
-                   in errno.
-
-   The gai_strerror() function provides a descriptive text string
-   corresponding to an EAI_xxx error value.
-
-      #include <netdb.h>
-
-      const char *gai_strerror(int ecode);
-
-   The argument is one of the EAI_xxx values defined for the
-   getaddrinfo() and getnameinfo() functions.  The return value points
-   to a string describing the error.  If the argument is not one of the
-   EAI_xxx values, the function still returns a pointer to a string
-   whose contents indicate an unknown error.
-
-6.2 Socket Address Structure to Node Name and Service Name
-
-   The getnameinfo() function is used to translate the contents of a
-   socket address structure to a node name and/or service name.
-
-
-
-
-Gilligan, et al.             Informational                     [Page 28]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   #include <sys/socket.h>
-   #include <netdb.h>
-
-   int getnameinfo(const struct sockaddr *sa, socklen_t salen,
-                       char *node, socklen_t nodelen,
-                       char *service, socklen_t servicelen,
-                         int flags);
-
-   The getnameinfo() function shall translate a socket address to a node
-   name and service location, all of which are defined as in
-   getaddrinfo().
-
-   The sa argument points to a socket address structure to be
-   translated.
-
-   The salen argument holds the size of the socket address structure
-   pointed to by sa.
-
-   If the socket address structure contains an IPv4-mapped IPv6 address
-   or an IPv4-compatible IPv6 address, the implementation shall extract
-   the embedded IPv4 address and lookup the node name for that IPv4
-   address.
-
-      Note: The IPv6 unspecified address ("::") and the IPv6 loopback
-      address ("::1") are not IPv4-compatible addresses.  If the address
-      is the IPv6 unspecified address ("::"), a lookup is not performed,
-      and the [EAI_NONAME] error is returned.
-
-   If the node argument is non-NULL and the nodelen argument is nonzero,
-   then the node argument points to a buffer able to contain up to
-   nodelen characters that receives the node name as a null-terminated
-   string.  If the node argument is NULL or the nodelen argument is
-   zero, the node name shall not be returned.  If the node's name cannot
-   be located, the numeric form of the node's address is returned
-   instead of its name.
-
-   If the service argument is non-NULL and the servicelen argument is
-   non-zero, then the service argument points to a buffer able to
-   contain up to servicelen bytes that receives the service name as a
-   null-terminated string.  If the service argument is NULL or the
-   servicelen argument is zero, the service name shall not be returned.
-   If the service's name cannot be located, the numeric form of the
-   service address (for example, its port number) shall be returned
-   instead of its name.
-
-   The arguments node and service cannot both be NULL.
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 29]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   The flags argument is a flag that changes the default actions of the
-   function.  By default the fully-qualified domain name (FQDN) for the
-   host shall be returned, but:
-
-   -  If the flag bit NI_NOFQDN is set, only the node name portion of
-      the FQDN shall be returned for local hosts.
-
-   -  If the flag bit NI_NUMERICHOST is set, the numeric form of the
-      host's address shall be returned instead of its name, under all
-      circumstances.
-
-   -  If the flag bit NI_NAMEREQD is set, an error shall be returned if
-      the host's name cannot be located.
-
-   -  If the flag bit NI_NUMERICSERV is set, the numeric form of the
-      service address shall be returned (for example, its port number)
-      instead of its name, under all circumstances.
-
-   -  If the flag bit NI_DGRAM is set, this indicates that the service
-      is a datagram service (SOCK_DGRAM).  The default behavior shall
-      assume that the service is a stream service (SOCK_STREAM).
-
-   Note:
-
-   1. The NI_NUMERICxxx flags are required to support the "-n" flags
-      that many commands provide.
-
-   2. The NI_DGRAM flag is required for the few AF_INET and AF_INET6
-      port numbers (for example, [512,514]) that represent different
-      services for UDP and TCP.
-
-   The getnameinfo() function shall be thread safe.
-
-   A zero return value for getnameinfo() indicates successful
-   completion; a non-zero return value indicates failure.
-
-   Upon successful completion, getnameinfo() shall return the node and
-   service names, if requested, in the buffers provided.  The returned
-   names are always null-terminated strings.
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 30]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   Error Return Values:
-
-   The getnameinfo() function shall fail and return the corresponding
-   value if:
-
-   [EAI_AGAIN]    The name could not be resolved at this time.
-                  Future attempts may succeed.
-
-   [EAI_BADFLAGS] The flags had an invalid value.
-
-   [EAI_FAIL]     A non-recoverable error occurred.
-
-   [EAI_FAMILY]   The address family was not recognized or the address
-                  length was invalid for the specified family.
-
-   [EAI_MEMORY]   There was a memory allocation failure.
-
-   [EAI_NONAME]   The name does not resolve for the supplied parameters.
-                  NI_NAMEREQD is set and the host's name cannot be
-                  located, or both nodename and servname were null.
-
-   [EAI_OVERFLOW] An argument buffer overflowed.
-
-   [EAI_SYSTEM]   A system error occurred.  The error code can be found
-                  in errno.
-
-6.3 Address Conversion Functions
-
-   The two IPv4 functions inet_addr() and inet_ntoa() convert an IPv4
-   address between binary and text form.  IPv6 applications need similar
-   functions.  The following two functions convert both IPv6 and IPv4
-   addresses:
-
-   #include <arpa/inet.h>
-
-   int inet_pton(int af, const char *src, void *dst);
-
-   const char *inet_ntop(int af, const void *src,
-                            char *dst, socklen_t size);
-
-   The inet_pton() function shall convert an address in its standard
-   text presentation form into its numeric binary form.  The af argument
-   shall specify the family of the address.  The AF_INET and AF_INET6
-   address families shall be supported.  The src argument points to the
-   string being passed in.  The dst argument points to a buffer into
-   which the function stores the numeric address; this shall be large
-   enough to hold the numeric address (32 bits for AF_INET, 128 bits for
-   AF_INET6).  The inet_pton() function shall return 1 if the conversion
-
-
-
-Gilligan, et al.             Informational                     [Page 31]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   succeeds, with the address pointed to by dst in network byte order.
-   It shall return 0 if the input is not a valid IPv4 dotted-decimal
-   string or a valid IPv6 address string, or -1 with errno set to
-   EAFNOSUPPORT if the af argument is unknown.
-
-   If the af argument of inet_pton() is AF_INET, the src string shall be
-   in the standard IPv4 dotted-decimal form:
-
-      ddd.ddd.ddd.ddd
-
-   where "ddd" is a one to three digit decimal number between 0 and 255.
-   The inet_pton() function does not accept other formats (such as the
-   octal numbers, hexadecimal numbers, and fewer than four numbers that
-   inet_addr() accepts).
-
-   If the af argument of inet_pton() is AF_INET6, the src string shall
-   be in one of the standard IPv6 text forms defined in Section 2.2 of
-   the addressing architecture specification [2].
-
-   The inet_ntop() function shall convert a numeric address into a text
-   string suitable for presentation.  The af argument shall specify the
-   family of the address.  This can be AF_INET or AF_INET6.  The src
-   argument points to a buffer holding an IPv4 address if the af
-   argument is AF_INET, or an IPv6 address if the af argument is
-   AF_INET6; the address must be in network byte order.  The dst
-   argument points to a buffer where the function stores the resulting
-   text string; it shall not be NULL.  The size argument specifies the
-   size of this buffer, which shall be large enough to hold the text
-   string (INET_ADDRSTRLEN characters for IPv4, INET6_ADDRSTRLEN
-   characters for IPv6).
-
-   In order to allow applications to easily declare buffers of the
-   proper size to store IPv4 and IPv6 addresses in string form, the
-   following two constants are defined in <netinet/in.h>:
-
-      #define INET_ADDRSTRLEN    16
-      #define INET6_ADDRSTRLEN   46
-
-   The inet_ntop() function shall return a pointer to the buffer
-   containing the text string if the conversion succeeds, and NULL
-   otherwise.  Upon failure, errno is set to EAFNOSUPPORT if the af
-   argument is invalid or ENOSPC if the size of the result buffer is
-   inadequate.
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 32]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-6.4 Address Testing Macros
-
-   The following macros can be used to test for special IPv6 addresses.
-
-   #include <netinet/in.h>
-
-   int  IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *);
-   int  IN6_IS_ADDR_LOOPBACK    (const struct in6_addr *);
-   int  IN6_IS_ADDR_MULTICAST   (const struct in6_addr *);
-   int  IN6_IS_ADDR_LINKLOCAL   (const struct in6_addr *);
-   int  IN6_IS_ADDR_SITELOCAL   (const struct in6_addr *);
-   int  IN6_IS_ADDR_V4MAPPED    (const struct in6_addr *);
-   int  IN6_IS_ADDR_V4COMPAT    (const struct in6_addr *);
-
-   int  IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
-   int  IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
-   int  IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
-   int  IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *);
-   int  IN6_IS_ADDR_MC_GLOBAL   (const struct in6_addr *);
-
-   The first seven macros return true if the address is of the specified
-   type, or false otherwise.  The last five test the scope of a
-   multicast address and return true if the address is a multicast
-   address of the specified scope or false if the address is either not
-   a multicast address or not of the specified scope.
-
-   Note that IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL return true
-   only for the two types of local-use IPv6 unicast addresses (Link-
-   Local and Site-Local) defined in [2], and that by this definition,
-   the IN6_IS_ADDR_LINKLOCAL macro returns false for the IPv6 loopback
-   address (::1).  These two macros do not return true for IPv6
-   multicast addresses of either link-local scope or site-local scope.
-
-7. Summary of New Definitions
-
-   The following list summarizes the constants, structure, and extern
-   definitions discussed in this memo, sorted by header.
-
-<net/if.h>      IF_NAMESIZE
-<net/if.h>      struct if_nameindex{};
-
-<netdb.h>       AI_ADDRCONFIG
-<netdb.h>       AI_ALL
-<netdb.h>       AI_CANONNAME
-<netdb.h>       AI_NUMERICHOST
-<netdb.h>       AI_NUMERICSERV
-<netdb.h>       AI_PASSIVE
-<netdb.h>       AI_V4MAPPED
-
-
-
-Gilligan, et al.             Informational                     [Page 33]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-<netdb.h>       EAI_AGAIN
-<netdb.h>       EAI_BADFLAGS
-<netdb.h>       EAI_FAIL
-<netdb.h>       EAI_FAMILY
-<netdb.h>       EAI_MEMORY
-<netdb.h>       EAI_NONAME
-<netdb.h>       EAI_OVERFLOW
-<netdb.h>       EAI_SERVICE
-<netdb.h>       EAI_SOCKTYPE
-<netdb.h>       EAI_SYSTEM
-<netdb.h>       NI_DGRAM
-<netdb.h>       NI_NAMEREQD
-<netdb.h>       NI_NOFQDN
-<netdb.h>       NI_NUMERICHOST
-<netdb.h>       NI_NUMERICSERV
-<netdb.h>       struct addrinfo{};
-
-<netinet/in.h>  IN6ADDR_ANY_INIT
-<netinet/in.h>  IN6ADDR_LOOPBACK_INIT
-<netinet/in.h>  INET6_ADDRSTRLEN
-<netinet/in.h>  INET_ADDRSTRLEN
-<netinet/in.h>  IPPROTO_IPV6
-<netinet/in.h>  IPV6_JOIN_GROUP
-<netinet/in.h>  IPV6_LEAVE_GROUP
-<netinet/in.h>  IPV6_MULTICAST_HOPS
-<netinet/in.h>  IPV6_MULTICAST_IF
-<netinet/in.h>  IPV6_MULTICAST_LOOP
-<netinet/in.h>  IPV6_UNICAST_HOPS
-<netinet/in.h>  IPV6_V6ONLY
-<netinet/in.h>  SIN6_LEN
-<netinet/in.h>  extern const struct in6_addr in6addr_any;
-<netinet/in.h>  extern const struct in6_addr in6addr_loopback;
-<netinet/in.h>  struct in6_addr{};
-<netinet/in.h>  struct ipv6_mreq{};
-<netinet/in.h>  struct sockaddr_in6{};
-
-<sys/socket.h>  AF_INET6
-<sys/socket.h>  PF_INET6
-<sys/socket.h>  struct sockaddr_storage;
-
-   The following list summarizes the function and macro prototypes
-   discussed in this memo, sorted by header.
-
-<arpa/inet.h>   int inet_pton(int, const char *, void *);
-<arpa/inet.h>   const char *inet_ntop(int, const void *,
-                               char *, socklen_t);
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 34]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-<net/if.h>      char *if_indextoname(unsigned int, char *);
-<net/if.h>      unsigned int if_nametoindex(const char *);
-<net/if.h>      void if_freenameindex(struct if_nameindex *);
-<net/if.h>      struct if_nameindex *if_nameindex(void);
-
-<netdb.h>       int getaddrinfo(const char *, const char *,
-                                const struct addrinfo *,
-                                struct addrinfo **);
-<netdb.h>       int getnameinfo(const struct sockaddr *, socklen_t,
-                  char *, socklen_t, char *, socklen_t, int);
-<netdb.h>       void freeaddrinfo(struct addrinfo *);
-<netdb.h>       const char *gai_strerror(int);
-
-<netinet/in.h>  int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_MULTICAST(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *);
-<netinet/in.h>  int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *);
-
-8. Security Considerations
-
-   IPv6 provides a number of new security mechanisms, many of which need
-   to be accessible to applications.  Companion memos detailing the
-   extensions to the socket interfaces to support IPv6 security are
-   being written.
-
-9. Changes from RFC 2553
-
-   1. Add brief description of the history of this API and its relation
-      to the Open Group/IEEE/ISO standards.
-
-   2. Alignments with [3].
-
-   3. Removed all references to getipnodebyname() and getipnodebyaddr(),
-      which are deprecated in favor of getaddrinfo() and getnameinfo().
-
-   4. Added IPV6_V6ONLY IP level socket option to permit nodes to not
-      process IPv4 packets as IPv4 Mapped addresses in implementations.
-
-   5. Added SIIT to references and added new contributors.
-
-
-
-
-Gilligan, et al.             Informational                     [Page 35]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-   6. In previous versions of this specification, the sin6_flowinfo
-      field was associated with the IPv6 traffic class and flow label,
-      but its usage was not completely specified.  The complete
-      definition of the sin6_flowinfo field, including its association
-      with the traffic class or flow label, is now deferred to a future
-      specification.
-
-10. Acknowledgments
-
-   This specification's evolution and completeness were significantly
-   influenced by the efforts of Richard Stevens, who has passed on.
-   Richard's wisdom and talent made the specification what it is today.
-   The co-authors will long think of Richard with great respect.
-
-   Thanks to the many people who made suggestions and provided feedback
-   to this document, including:
-
-   Werner Almesberger, Ran Atkinson, Fred Baker, Dave Borman, Andrew
-   Cherenson, Alex Conta, Alan Cox, Steve Deering, Richard Draves,
-   Francis Dupont, Robert Elz, Brian Haberman, Jun-ichiro itojun Hagino,
-   Marc Hasson, Tom Herbert, Bob Hinden, Wan-Yen Hsu, Christian Huitema,
-   Koji Imada, Markus Jork, Ron Lee, Alan Lloyd, Charles Lynn, Dan
-   McDonald, Dave Mitton, Finnbarr Murphy, Thomas Narten, Josh Osborne,
-   Craig Partridge, Jean-Luc Richier, Bill Sommerfield, Erik Scoredos,
-   Keith Sklower, JINMEI Tatuya, Dave Thaler, Matt Thomas, Harvey
-   Thompson, Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie,
-   David Waitzman, Carl Williams, Kazu Yamamoto, Vlad Yasevich, Stig
-   Venaas, and Brian Zill.
-
-   The getaddrinfo() and getnameinfo() functions are taken from an
-   earlier document by Keith Sklower.  As noted in that document,
-   William Durst, Steven Wise, Michael Karels, and Eric Allman provided
-   many useful discussions on the subject of protocol-independent name-
-   to-address translation, and reviewed early versions of Keith
-   Sklower's original proposal.  Eric Allman implemented the first
-   prototype of getaddrinfo().  The observation that specifying the pair
-   of name and service would suffice for connecting to a service
-   independent of protocol details was made by Marshall Rose in a
-   proposal to X/Open for a "Uniform Network Interface".
-
-   Craig Metz, Jack McCann, Erik Nordmark, Tim Hartrick, and Mukesh
-   Kacker made many contributions to this document.  Ramesh Govindan
-   made a number of contributions and co-authored an earlier version of
-   this memo.
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 36]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-11. References
-
-   [1]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
-        Specification", RFC 2460, December 1998.
-
-   [2]  Hinden, R. and S. Deering, "IP Version 6 Addressing
-        Architecture", RFC 2373, July 1998.
-
-   [3]  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
-
-   [4]  Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", RFC
-        2292, February 1998.
-
-   [5]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
-        RFC 2765, February 2000.
-
-   [6]  The Open Group Base Working Group
-        http://www.opengroup.org/platform/base.html
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 37]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-12. Authors' Addresses
-
-   Bob Gilligan
-   Intransa, Inc.
-   2870 Zanker Rd.
-   San Jose, CA 95134
-
-   Phone: 408-678-8647
-   EMail: gilligan@intransa.com
-
-
-   Susan Thomson
-   Cisco Systems
-   499 Thornall Street, 8th floor
-   Edison, NJ 08837
-
-   Phone: 732-635-3086
-   EMail:  sethomso@cisco.com
-
-
-   Jim Bound
-   Hewlett-Packard Company
-   110 Spitbrook Road ZKO3-3/W20
-   Nashua, NH 03062
-
-   Phone: 603-884-0062
-   EMail: Jim.Bound@hp.com
-
-
-   Jack McCann
-   Hewlett-Packard Company
-   110 Spitbrook Road ZKO3-3/W20
-   Nashua, NH 03062
-
-   Phone: 603-884-2608
-   EMail: Jack.McCann@hp.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 38]
-
-RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
-
-
-13. 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gilligan, et al.             Informational                     [Page 39]
-
diff --git a/contrib/bind9/doc/rfc/rfc3513.txt b/contrib/bind9/doc/rfc/rfc3513.txt
deleted file mode 100644
index 49c0fa4..0000000
--- a/contrib/bind9/doc/rfc/rfc3513.txt
+++ /dev/null
@@ -1,1459 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          R. Hinden
-Request for Comments: 3513                                         Nokia
-Obsoletes: 2373                                               S. Deering
-Category: Standards Track                                  Cisco Systems
-                                                              April 2003
-
-
-       Internet Protocol Version 6 (IPv6) Addressing Architecture
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   This specification defines the addressing architecture of the IP
-   Version 6 (IPv6) protocol.  The document includes the IPv6 addressing
-   model, text representations of IPv6 addresses, definition of IPv6
-   unicast addresses, anycast addresses, and multicast addresses, and an
-   IPv6 node's required addresses.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 1]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-Table of Contents
-
-   1. Introduction.................................................3
-   2. IPv6 Addressing..............................................3
-      2.1 Addressing Model.........................................4
-      2.2 Text Representation of Addresses.........................4
-      2.3 Text Representation of Address Prefixes..................5
-      2.4 Address Type Identification..............................6
-      2.5 Unicast Addresses........................................7
-          2.5.1 Interface Identifiers..............................8
-          2.5.2 The Unspecified Address............................9
-          2.5.3 The Loopback Address...............................9
-          2.5.4 Global Unicast Addresses..........................10
-          2.5.5 IPv6 Addresses with Embedded IPv4 Addresses.......10
-          2.5.6 Local-use IPv6 Unicast Addresses..................11
-      2.6 Anycast Addresses.......................................12
-          2.6.1 Required Anycast Address..........................13
-      2.7 Multicast Addresses.....................................13
-          2.7.1 Pre-Defined Multicast Addresses...................15
-      2.8 A Node's Required Addresses.............................17
-   3. Security Considerations.....................................17
-   4. IANA Considerations.........................................18
-   5. References..................................................19
-      5.1 Normative References....................................19
-      5.2 Informative References..................................19
-   APPENDIX A: Creating Modified EUI-64 format Interface IDs......21
-   APPENDIX B: Changes from RFC-2373..............................24
-   Authors' Addresses.............................................25
-   Full Copyright Statement.......................................26
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 2]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-1.  Introduction
-
-   This specification defines the addressing architecture of the IP
-   Version 6 (IPv6) protocol.  It includes the basic formats for the
-   various types of IPv6 addresses (unicast, anycast, and multicast).
-
-   The authors would like to acknowledge the contributions of Paul
-   Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford,
-   Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan,
-   Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg
-   Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson,
-   Sue Thomson, Markku Savela, and Larry Masinter.
-
-2. IPv6 Addressing
-
-   IPv6 addresses are 128-bit identifiers for interfaces and sets of
-   interfaces (where "interface" is as defined in section 2 of [IPV6]).
-   There are three types of addresses:
-
-   Unicast:   An identifier for a single interface.  A packet sent to a
-              unicast address is delivered to the interface identified
-              by that address.
-
-   Anycast:   An identifier for a set of interfaces (typically belonging
-              to different nodes).  A packet sent to an anycast address
-              is delivered to one of the interfaces identified by that
-              address (the "nearest" one, according to the routing
-              protocols' measure of distance).
-
-   Multicast: An identifier for a set of interfaces (typically belonging
-              to different nodes).  A packet sent to a multicast address
-              is delivered to all interfaces identified by that address.
-
-   There are no broadcast addresses in IPv6, their function being
-   superseded by multicast addresses.
-
-   In this document, fields in addresses are given a specific name, for
-   example "subnet".  When this name is used with the term "ID" for
-   identifier after the name (e.g., "subnet ID"), it refers to the
-   contents of the named field.  When it is used with the term "prefix"
-   (e.g., "subnet prefix") it refers to all of the address from the left
-   up to and including this field.
-
-   In IPv6, all zeros and all ones are legal values for any field,
-   unless specifically excluded.  Specifically, prefixes may contain, or
-   end with, zero-valued fields.
-
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 3]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-2.1 Addressing Model
-
-   IPv6 addresses of all types are assigned to interfaces, not nodes.
-   An IPv6 unicast address refers to a single interface.  Since each
-   interface belongs to a single node, any of that node's interfaces'
-   unicast addresses may be used as an identifier for the node.
-
-   All interfaces are required to have at least one link-local unicast
-   address (see section 2.8 for additional required addresses).  A
-   single interface may also have multiple IPv6 addresses of any type
-   (unicast, anycast, and multicast) or scope.  Unicast addresses with
-   scope greater than link-scope are not needed for interfaces that are
-   not used as the origin or destination of any IPv6 packets to or from
-   non-neighbors.  This is sometimes convenient for point-to-point
-   interfaces.  There is one exception to this addressing model:
-
-      A unicast address or a set of unicast addresses may be assigned to
-      multiple physical interfaces if the implementation treats the
-      multiple physical interfaces as one interface when presenting it
-      to the internet layer.  This is useful for load-sharing over
-      multiple physical interfaces.
-
-   Currently IPv6 continues the IPv4 model that a subnet prefix is
-   associated with one link.  Multiple subnet prefixes may be assigned
-   to the same link.
-
-2.2 Text Representation of Addresses
-
-   There are three conventional forms for representing IPv6 addresses as
-   text strings:
-
-   1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the
-      hexadecimal values of the eight 16-bit pieces of the address.
-
-      Examples:
-
-         FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
-
-         1080:0:0:0:8:800:200C:417A
-
-      Note that it is not necessary to write the leading zeros in an
-      individual field, but there must be at least one numeral in every
-      field (except for the case described in 2.).
-
-   2. Due to some methods of allocating certain styles of IPv6
-      addresses, it will be common for addresses to contain long strings
-      of zero bits.  In order to make writing addresses containing zero
-      bits easier a special syntax is available to compress the zeros.
-
-
-
-Hinden & Deering            Standards Track                     [Page 4]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-      The use of "::" indicates one or more groups of 16 bits of zeros.
-      The "::" can only appear once in an address.  The "::" can also be
-      used to compress leading or trailing zeros in an address.
-
-      For example, the following addresses:
-
-         1080:0:0:0:8:800:200C:417A  a unicast address
-         FF01:0:0:0:0:0:0:101        a multicast address
-         0:0:0:0:0:0:0:1             the loopback address
-         0:0:0:0:0:0:0:0             the unspecified addresses
-
-      may be represented as:
-
-         1080::8:800:200C:417A       a unicast address
-         FF01::101                   a multicast address
-         ::1                         the loopback address
-         ::                          the unspecified addresses
-
-   3. An alternative form that is sometimes more convenient when dealing
-      with a mixed environment of IPv4 and IPv6 nodes is
-      x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of
-      the six high-order 16-bit pieces of the address, and the 'd's are
-      the decimal values of the four low-order 8-bit pieces of the
-      address (standard IPv4 representation).  Examples:
-
-         0:0:0:0:0:0:13.1.68.3
-
-         0:0:0:0:0:FFFF:129.144.52.38
-
-      or in compressed form:
-
-         ::13.1.68.3
-
-         ::FFFF:129.144.52.38
-
-2.3 Text Representation of Address Prefixes
-
-   The text representation of IPv6 address prefixes is similar to the
-   way IPv4 addresses prefixes are written in CIDR notation [CIDR].  An
-   IPv6 address prefix is represented by the notation:
-
-      ipv6-address/prefix-length
-
-   where
-
-      ipv6-address    is an IPv6 address in any of the notations listed
-                      in section 2.2.
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 5]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-      prefix-length   is a decimal value specifying how many of the
-                      leftmost contiguous bits of the address comprise
-                      the prefix.
-
-   For example, the following are legal representations of the 60-bit
-   prefix 12AB00000000CD3 (hexadecimal):
-
-      12AB:0000:0000:CD30:0000:0000:0000:0000/60
-      12AB::CD30:0:0:0:0/60
-      12AB:0:0:CD30::/60
-
-   The following are NOT legal representations of the above prefix:
-
-      12AB:0:0:CD3/60   may drop leading zeros, but not trailing zeros,
-                        within any 16-bit chunk of the address
-
-      12AB::CD30/60     address to left of "/" expands to
-                        12AB:0000:0000:0000:0000:000:0000:CD30
-
-      12AB::CD3/60      address to left of "/" expands to
-                        12AB:0000:0000:0000:0000:000:0000:0CD3
-
-   When writing both a node address and a prefix of that node address
-   (e.g., the node's subnet prefix), the two can combined as follows:
-
-      the node address      12AB:0:0:CD30:123:4567:89AB:CDEF
-      and its subnet number 12AB:0:0:CD30::/60
-
-      can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60
-
-2.4 Address Type Identification
-
-   The type of an IPv6 address is identified by the high-order bits of
-   the address, as follows:
-
-   Address type         Binary prefix        IPv6 notation   Section
-   ------------         -------------        -------------   -------
-   Unspecified          00...0  (128 bits)   ::/128          2.5.2
-   Loopback             00...1  (128 bits)   ::1/128         2.5.3
-   Multicast            11111111             FF00::/8        2.7
-   Link-local unicast   1111111010           FE80::/10       2.5.6
-   Site-local unicast   1111111011           FEC0::/10       2.5.6
-   Global unicast       (everything else)
-
-   Anycast addresses are taken from the unicast address spaces (of any
-   scope) and are not syntactically distinguishable from unicast
-   addresses.
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 6]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   The general format of global unicast addresses is described in
-   section 2.5.4.  Some special-purpose subtypes of global unicast
-   addresses which contain embedded IPv4 addresses (for the purposes of
-   IPv4-IPv6 interoperation) are described in section 2.5.5.
-
-   Future specifications may redefine one or more sub-ranges of the
-   global unicast space for other purposes, but unless and until that
-   happens, implementations must treat all addresses that do not start
-   with any of the above-listed prefixes as global unicast addresses.
-
-2.5 Unicast Addresses
-
-   IPv6 unicast addresses are aggregable with prefixes of arbitrary
-   bit-length similar to IPv4 addresses under Classless Interdomain
-   Routing.
-
-   There are several types of unicast addresses in IPv6, in particular
-   global unicast, site-local unicast, and link-local unicast.  There
-   are also some special-purpose subtypes of global unicast, such as
-   IPv6 addresses with embedded IPv4 addresses or encoded NSAP
-   addresses.  Additional address types or subtypes can be defined in
-   the future.
-
-   IPv6 nodes may have considerable or little knowledge of the internal
-   structure of the IPv6 address, depending on the role the node plays
-   (for instance, host versus router).  At a minimum, a node may
-   consider that unicast addresses (including its own) have no internal
-   structure:
-
-   |                           128 bits                              |
-   +-----------------------------------------------------------------+
-   |                          node address                           |
-   +-----------------------------------------------------------------+
-
-   A slightly sophisticated host (but still rather simple) may
-   additionally be aware of subnet prefix(es) for the link(s) it is
-   attached to, where different addresses may have different values for
-   n:
-
-   |                         n bits                 |   128-n bits   |
-   +------------------------------------------------+----------------+
-   |                   subnet prefix                | interface ID   |
-   +------------------------------------------------+----------------+
-
-   Though a very simple router may have no knowledge of the internal
-   structure of IPv6 unicast addresses, routers will more generally have
-   knowledge of one or more of the hierarchical boundaries for the
-   operation of routing protocols.  The known boundaries will differ
-
-
-
-Hinden & Deering            Standards Track                     [Page 7]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   from router to router, depending on what positions the router holds
-   in the routing hierarchy.
-
-2.5.1 Interface Identifiers
-
-   Interface identifiers in IPv6 unicast addresses are used to identify
-   interfaces on a link.  They are required to be unique within a subnet
-   prefix.  It is recommended that the same interface identifier not be
-   assigned to different nodes on a link.  They may also be unique over
-   a broader scope.  In some cases an interface's identifier will be
-   derived directly from that interface's link-layer address.  The same
-   interface identifier may be used on multiple interfaces on a single
-   node, as long as they are attached to different subnets.
-
-   Note that the uniqueness of interface identifiers is independent of
-   the uniqueness of IPv6 addresses.  For example, a global unicast
-   address may be created with a non-global scope interface identifier
-   and a site-local address may be created with a global scope interface
-   identifier.
-
-   For all unicast addresses, except those that start with binary value
-   000, Interface IDs are required to be 64 bits long and to be
-   constructed in Modified EUI-64 format.
-
-   Modified EUI-64 format based Interface identifiers may have global
-   scope when derived from a global token (e.g., IEEE 802 48-bit MAC or
-   IEEE EUI-64 identifiers [EUI64]) or may have local scope where a
-   global token is not available (e.g., serial links, tunnel end-points,
-   etc.) or where global tokens are undesirable (e.g., temporary tokens
-   for privacy [PRIV]).
-
-   Modified EUI-64 format interface identifiers are formed by inverting
-   the "u" bit (universal/local bit in IEEE EUI-64 terminology) when
-   forming the interface identifier from IEEE EUI-64 identifiers.  In
-   the resulting Modified EUI-64 format the "u" bit is set to one (1) to
-   indicate global scope, and it is set to zero (0) to indicate local
-   scope.  The first three octets in binary of an IEEE EUI-64 identifier
-   are as follows:
-
-       0       0 0       1 1       2
-      |0       7 8       5 6       3|
-      +----+----+----+----+----+----+
-      |cccc|ccug|cccc|cccc|cccc|cccc|
-      +----+----+----+----+----+----+
-
-   written in Internet standard bit-order , where "u" is the
-   universal/local bit, "g" is the individual/group bit, and "c" are the
-   bits of the company_id.  Appendix A: "Creating Modified EUI-64 format
-
-
-
-Hinden & Deering            Standards Track                     [Page 8]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   Interface Identifiers" provides examples on the creation of Modified
-   EUI-64 format based interface identifiers.
-
-   The motivation for inverting the "u" bit when forming an interface
-   identifier is to make it easy for system administrators to hand
-   configure non-global identifiers when hardware tokens are not
-   available.  This is expected to be case for serial links, tunnel end-
-   points, etc.  The alternative would have been for these to be of the
-   form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler 1, 2,
-   etc.
-
-   The use of the universal/local bit in the Modified EUI-64 format
-   identifier is to allow development of future technology that can take
-   advantage of interface identifiers with global scope.
-
-   The details of forming interface identifiers are defined in the
-   appropriate "IPv6 over <link>" specification such as "IPv6 over
-   Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
-
-2.5.2 The Unspecified Address
-
-   The address 0:0:0:0:0:0:0:0 is called the unspecified address.  It
-   must never be assigned to any node.  It indicates the absence of an
-   address.  One example of its use is in the Source Address field of
-   any IPv6 packets sent by an initializing host before it has learned
-   its own address.
-
-   The unspecified address must not be used as the destination address
-   of IPv6 packets or in IPv6 Routing Headers.  An IPv6 packet with a
-   source address of unspecified must never be forwarded by an IPv6
-   router.
-
-2.5.3 The Loopback Address
-
-   The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
-   It may be used by a node to send an IPv6 packet to itself.  It may
-   never be assigned to any physical interface.   It is treated as
-   having link-local scope, and may be thought of as the link-local
-   unicast address of a virtual interface (typically called "the
-   loopback interface") to an imaginary link that goes nowhere.
-
-   The loopback address must not be used as the source address in IPv6
-   packets that are sent outside of a single node.  An IPv6 packet with
-   a destination address of loopback must never be sent outside of a
-   single node and must never be forwarded by an IPv6 router.  A packet
-   received on an interface with destination address of loopback must be
-   dropped.
-
-
-
-
-Hinden & Deering            Standards Track                     [Page 9]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-2.5.4 Global Unicast Addresses
-
-   The general format for IPv6 global unicast addresses is as follows:
-
-   |         n bits         |   m bits  |       128-n-m bits         |
-   +------------------------+-----------+----------------------------+
-   | global routing prefix  | subnet ID |       interface ID         |
-   +------------------------+-----------+----------------------------+
-
-   where the global routing prefix is a (typically hierarchically-
-   structured) value assigned to a site (a cluster of subnets/links),
-   the subnet ID is an identifier of a link within the site, and the
-   interface ID is as defined in section 2.5.1.
-
-   All global unicast addresses other than those that start with binary
-   000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
-   described in section 2.5.1.  Global unicast addresses that start with
-   binary 000 have no such constraint on the size or structure of the
-   interface ID field.
-
-   Examples of global unicast addresses that start with binary 000 are
-   the IPv6 address with embedded IPv4 addresses described in section
-   2.5.5 and the IPv6 address containing encoded NSAP addresses
-   specified in [NSAP].  An example of global addresses starting with a
-   binary value other than 000 (and therefore having a 64-bit interface
-   ID field) can be found in [AGGR].
-
-2.5.5 IPv6 Addresses with Embedded IPv4 Addresses
-
-   The IPv6 transition mechanisms [TRAN] include a technique for hosts
-   and routers to dynamically tunnel IPv6 packets over IPv4 routing
-   infrastructure.  IPv6 nodes that use this technique are assigned
-   special IPv6 unicast addresses that carry a global IPv4 address in
-   the low-order 32 bits.  This type of address is termed an "IPv4-
-   compatible IPv6 address" and has the format:
-
-   |                80 bits               | 16 |      32 bits        |
-   +--------------------------------------+--------------------------+
-   |0000..............................0000|0000|    IPv4 address     |
-   +--------------------------------------+----+---------------------+
-
-   Note: The IPv4 address used in the "IPv4-compatible IPv6 address"
-   must be a globally-unique IPv4 unicast address.
-
-   A second type of IPv6 address which holds an embedded IPv4 address is
-   also defined.  This address type is used to represent the addresses
-   of IPv4 nodes as IPv6 addresses.  This type of address is termed an
-   "IPv4-mapped IPv6 address" and has the format:
-
-
-
-Hinden & Deering            Standards Track                    [Page 10]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   |                80 bits               | 16 |      32 bits        |
-   +--------------------------------------+--------------------------+
-   |0000..............................0000|FFFF|    IPv4 address     |
-   +--------------------------------------+----+---------------------+
-
-2.5.6 Local-Use IPv6 Unicast Addresses
-
-   There are two types of local-use unicast addresses defined.  These
-   are Link-Local and Site-Local.  The Link-Local is for use on a single
-   link and the Site-Local is for use in a single site.  Link-Local
-   addresses have the following format:
-
-   |   10     |
-   |  bits    |         54 bits         |          64 bits           |
-   +----------+-------------------------+----------------------------+
-   |1111111010|           0             |       interface ID         |
-   +----------+-------------------------+----------------------------+
-
-   Link-Local addresses are designed to be used for addressing on a
-   single link for purposes such as automatic address configuration,
-   neighbor discovery, or when no routers are present.
-
-   Routers must not forward any packets with link-local source or
-   destination addresses to other links.
-
-   Site-Local addresses have the following format:
-
-   |   10     |
-   |  bits    |         54 bits         |         64 bits            |
-   +----------+-------------------------+----------------------------+
-   |1111111011|        subnet ID        |       interface ID         |
-   +----------+-------------------------+----------------------------+
-
-   Site-local addresses are designed to be used for addressing inside of
-   a site without the need for a global prefix.  Although a subnet ID
-   may be up to 54-bits long, it is expected that globally-connected
-   sites will use the same subnet IDs for site-local and global
-   prefixes.
-
-   Routers must not forward any packets with site-local source or
-   destination addresses outside of the site.
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 11]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-2.6 Anycast Addresses
-
-   An IPv6 anycast address is an address that is assigned to more than
-   one interface (typically belonging to different nodes), with the
-   property that a packet sent to an anycast address is routed to the
-   "nearest" interface having that address, according to the routing
-   protocols' measure of distance.
-
-   Anycast addresses are allocated from the unicast address space, using
-   any of the defined unicast address formats.  Thus, anycast addresses
-   are syntactically indistinguishable from unicast addresses.  When a
-   unicast address is assigned to more than one interface, thus turning
-   it into an anycast address, the nodes to which the address is
-   assigned must be explicitly configured to know that it is an anycast
-   address.
-
-   For any assigned anycast address, there is a longest prefix P of that
-   address that identifies the topological region in which all
-   interfaces belonging to that anycast address reside.  Within the
-   region identified by P, the anycast address must be maintained as a
-   separate entry in the routing system (commonly referred to as a "host
-   route"); outside the region identified by P, the anycast address may
-   be aggregated into the routing entry for prefix P.
-
-   Note that in the worst case, the prefix P of an anycast set may be
-   the null prefix, i.e., the members of the set may have no topological
-   locality.  In that case, the anycast address must be maintained as a
-   separate routing entry throughout the entire internet, which presents
-   a severe scaling limit on how many such "global" anycast sets may be
-   supported.  Therefore, it is expected that support for global anycast
-   sets may be unavailable or very restricted.
-
-   One expected use of anycast addresses is to identify the set of
-   routers belonging to an organization providing internet service.
-   Such addresses could be used as intermediate addresses in an IPv6
-   Routing header, to cause a packet to be delivered via a particular
-   service provider or sequence of service providers.
-
-   Some other possible uses are to identify the set of routers attached
-   to a particular subnet, or the set of routers providing entry into a
-   particular routing domain.
-
-   There is little experience with widespread, arbitrary use of internet
-   anycast addresses, and some known complications and hazards when
-   using them in their full generality [ANYCST].  Until more experience
-   has been gained and solutions are specified, the following
-   restrictions are imposed on IPv6 anycast addresses:
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 12]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   o  An anycast address must not be used as the source address of an
-      IPv6 packet.
-
-   o  An anycast address must not be assigned to an IPv6 host, that is,
-      it may be assigned to an IPv6 router only.
-
-2.6.1 Required Anycast Address
-
-   The Subnet-Router anycast address is predefined.  Its format is as
-   follows:
-
-   |                         n bits                 |   128-n bits   |
-   +------------------------------------------------+----------------+
-   |                   subnet prefix                | 00000000000000 |
-   +------------------------------------------------+----------------+
-
-   The "subnet prefix" in an anycast address is the prefix which
-   identifies a specific link.  This anycast address is syntactically
-   the same as a unicast address for an interface on the link with the
-   interface identifier set to zero.
-
-   Packets sent to the Subnet-Router anycast address will be delivered
-   to one router on the subnet.  All routers are required to support the
-   Subnet-Router anycast addresses for the subnets to which they have
-   interfaces.
-
-   The subnet-router anycast address is intended to be used for
-   applications where a node needs to communicate with any one of the
-   set of routers.
-
-2.7 Multicast Addresses
-
-   An IPv6 multicast address is an identifier for a group of interfaces
-   (typically on different nodes).  An interface may belong to any
-   number of multicast groups.  Multicast addresses have the following
-   format:
-
-   |   8    |  4 |  4 |                  112 bits                   |
-   +------ -+----+----+---------------------------------------------+
-   |11111111|flgs|scop|                  group ID                   |
-   +--------+----+----+---------------------------------------------+
-
-         binary 11111111 at the start of the address identifies the
-         address as being a multicast address.
-
-                                       +-+-+-+-+
-         flgs is a set of 4 flags:     |0|0|0|T|
-                                       +-+-+-+-+
-
-
-
-Hinden & Deering            Standards Track                    [Page 13]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-            The high-order 3 flags are reserved, and must be initialized
-            to 0.
-
-            T = 0 indicates a permanently-assigned ("well-known")
-            multicast address, assigned by the Internet Assigned Number
-            Authority (IANA).
-
-            T = 1 indicates a non-permanently-assigned ("transient")
-            multicast address.
-
-         scop is a 4-bit multicast scope value used to limit the scope
-         of the multicast group.  The values are:
-
-            0  reserved
-            1  interface-local scope
-            2  link-local scope
-            3  reserved
-            4  admin-local scope
-            5  site-local scope
-            6  (unassigned)
-            7  (unassigned)
-            8  organization-local scope
-            9  (unassigned)
-            A  (unassigned)
-            B  (unassigned)
-            C  (unassigned)
-            D  (unassigned)
-            E  global scope
-            F  reserved
-
-            interface-local scope spans only a single interface on a
-            node, and is useful only for loopback transmission of
-            multicast.
-
-            link-local and site-local multicast scopes span the same
-            topological regions as the corresponding unicast scopes.
-
-            admin-local scope is the smallest scope that must be
-            administratively configured, i.e., not automatically derived
-            from physical connectivity or other, non- multicast-related
-            configuration.
-
-            organization-local scope is intended to span multiple sites
-            belonging to a single organization.
-
-            scopes labeled "(unassigned)" are available for
-            administrators to define additional multicast regions.
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 14]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-         group ID identifies the multicast group, either permanent or
-         transient, within the given scope.
-
-   The "meaning" of a permanently-assigned multicast address is
-   independent of the scope value.  For example, if the "NTP servers
-   group" is assigned a permanent multicast address with a group ID of
-   101 (hex), then:
-
-      FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface
-      (i.e., the same node) as the sender.
-
-      FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as the
-      sender.
-
-      FF05:0:0:0:0:0:0:101 means all NTP servers in the same site as the
-      sender.
-
-      FF0E:0:0:0:0:0:0:101 means all NTP servers in the internet.
-
-   Non-permanently-assigned multicast addresses are meaningful only
-   within a given scope.  For example, a group identified by the non-
-   permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one
-   site bears no relationship to a group using the same address at a
-   different site, nor to a non-permanent group using the same group ID
-   with different scope, nor to a permanent group with the same group
-   ID.
-
-   Multicast addresses must not be used as source addresses in IPv6
-   packets or appear in any Routing header.
-
-   Routers must not forward any multicast packets beyond of the scope
-   indicated by the scop field in the destination multicast address.
-
-   Nodes must not originate a packet to a multicast address whose scop
-   field contains the reserved value 0; if such a packet is received, it
-   must be silently dropped.  Nodes should not originate a packet to a
-   multicast address whose scop field contains the reserved value F; if
-   such a packet is sent or received, it must be treated the same as
-   packets destined to a global (scop E) multicast address.
-
-2.7.1 Pre-Defined Multicast Addresses
-
-   The following well-known multicast addresses are pre-defined.  The
-   group ID's defined in this section are defined for explicit scope
-   values.
-
-   Use of these group IDs for any other scope values, with the T flag
-   equal to 0, is not allowed.
-
-
-
-Hinden & Deering            Standards Track                    [Page 15]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-      Reserved Multicast Addresses:   FF00:0:0:0:0:0:0:0
-                                      FF01:0:0:0:0:0:0:0
-                                      FF02:0:0:0:0:0:0:0
-                                      FF03:0:0:0:0:0:0:0
-                                      FF04:0:0:0:0:0:0:0
-                                      FF05:0:0:0:0:0:0:0
-                                      FF06:0:0:0:0:0:0:0
-                                      FF07:0:0:0:0:0:0:0
-                                      FF08:0:0:0:0:0:0:0
-                                      FF09:0:0:0:0:0:0:0
-                                      FF0A:0:0:0:0:0:0:0
-                                      FF0B:0:0:0:0:0:0:0
-                                      FF0C:0:0:0:0:0:0:0
-                                      FF0D:0:0:0:0:0:0:0
-                                      FF0E:0:0:0:0:0:0:0
-                                      FF0F:0:0:0:0:0:0:0
-
-   The above multicast addresses are reserved and shall never be
-   assigned to any multicast group.
-
-      All Nodes Addresses:    FF01:0:0:0:0:0:0:1
-                              FF02:0:0:0:0:0:0:1
-
-   The above multicast addresses identify the group of all IPv6 nodes,
-   within scope 1 (interface-local) or 2 (link-local).
-
-      All Routers Addresses:   FF01:0:0:0:0:0:0:2
-                               FF02:0:0:0:0:0:0:2
-                               FF05:0:0:0:0:0:0:2
-
-   The above multicast addresses identify the group of all IPv6 routers,
-   within scope 1 (interface-local), 2 (link-local), or 5 (site-local).
-
-      Solicited-Node Address:  FF02:0:0:0:0:1:FFXX:XXXX
-
-   Solicited-node multicast address are computed as a function of a
-   node's unicast and anycast addresses.  A solicited-node multicast
-   address is formed by taking the low-order 24 bits of an address
-   (unicast or anycast) and appending those bits to the prefix
-   FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the
-   range
-
-      FF02:0:0:0:0:1:FF00:0000
-
-   to
-
-      FF02:0:0:0:0:1:FFFF:FFFF
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 16]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   For example, the solicited node multicast address corresponding to
-   the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C.  IPv6
-   addresses that differ only in the high-order bits, e.g., due to
-   multiple high-order prefixes associated with different aggregations,
-   will map to the same solicited-node address thereby, reducing the
-   number of multicast addresses a node must join.
-
-   A node is required to compute and join (on the appropriate interface)
-   the associated Solicited-Node multicast addresses for every unicast
-   and anycast address it is assigned.
-
-2.8 A Node's Required Addresses
-
-   A host is required to recognize the following addresses as
-   identifying itself:
-
-      o  Its required Link-Local Address for each interface.
-      o  Any additional Unicast and Anycast Addresses that have been
-         configured for the node's interfaces (manually or
-         automatically).
-      o  The loopback address.
-      o  The All-Nodes Multicast Addresses defined in section 2.7.1.
-      o  The Solicited-Node Multicast Address for each of its unicast
-         and anycast addresses.
-      o  Multicast Addresses of all other groups to which the node
-         belongs.
-
-   A router is required to recognize all addresses that a host is
-   required to recognize, plus the following addresses as identifying
-   itself:
-
-      o  The Subnet-Router Anycast Addresses for all interfaces for
-         which it is configured to act as a router.
-      o  All other Anycast Addresses with which the router has been
-         configured.
-      o  The All-Routers Multicast Addresses defined in section 2.7.1.
-
-3. Security Considerations
-
-   IPv6 addressing documents do not have any direct impact on Internet
-   infrastructure security.  Authentication of IPv6 packets is defined
-   in [AUTH].
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 17]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-4. IANA Considerations
-
-   The table and notes at http://www.isi.edu/in-
-   notes/iana/assignments/ipv6-address-space.txt should be replaced with
-   the following:
-
-   INTERNET PROTOCOL VERSION 6 ADDRESS SPACE
-
-   The initial assignment of IPv6 address space is as follows:
-
-   Allocation                            Prefix         Fraction of
-                                         (binary)       Address Space
-   -----------------------------------   --------       -------------
-   Unassigned (see Note 1 below)         0000 0000      1/256
-   Unassigned                            0000 0001      1/256
-   Reserved for NSAP Allocation          0000 001       1/128 [RFC1888]
-   Unassigned                            0000 01        1/64
-   Unassigned                            0000 1         1/32
-   Unassigned                            0001           1/16
-   Global Unicast                        001            1/8   [RFC2374]
-   Unassigned                            010            1/8
-   Unassigned                            011            1/8
-   Unassigned                            100            1/8
-   Unassigned                            101            1/8
-   Unassigned                            110            1/8
-   Unassigned                            1110           1/16
-   Unassigned                            1111 0         1/32
-   Unassigned                            1111 10        1/64
-   Unassigned                            1111 110       1/128
-   Unassigned                            1111 1110 0    1/512
-   Link-Local Unicast Addresses          1111 1110 10   1/1024
-   Site-Local Unicast Addresses          1111 1110 11   1/1024
-   Multicast Addresses                   1111 1111      1/256
-
-   Notes:
-
-   1. The "unspecified address", the "loopback address", and the IPv6
-      Addresses with Embedded IPv4 Addresses are assigned out of the
-      0000 0000 binary prefix space.
-
-   2. For now, IANA should limit its allocation of IPv6 unicast address
-      space to the range of addresses that start with binary value 001.
-      The rest of the global unicast address space (approximately 85% of
-      the IPv6 address space) is reserved for future definition and use,
-      and is not to be assigned by IANA at this time.
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 18]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-5.  References
-
-5.1  Normative References
-
-   [IPV6]    Deering, S. and R. Hinden, "Internet Protocol, Version 6
-             (IPv6) Specification", RFC 2460, December 1998.
-
-   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
-             3", BCP 9 , RFC 2026, October 1996.
-
-5.2  Informative References
-
-   [ANYCST]  Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting
-             Service", RFC 1546, November 1993.
-
-   [AUTH]    Kent, S. and R. Atkinson, "IP Authentication Header", RFC
-             2402, November 1998.
-
-   [AGGR]    Hinden, R., O'Dell, M. and S. Deering, "An Aggregatable
-             Global Unicast Address Format", RFC 2374, July 1998.
-
-   [CIDR]    Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless
-             Inter-Domain Routing (CIDR): An Address Assignment and
-             Aggregation Strategy", RFC 1519, September 1993.
-
-   [ETHER]   Crawford, M., "Transmission of IPv6 Packets over Ethernet
-             Networks", RFC 2464, December 1998.
-
-   [EUI64]   IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
-             Registration Authority",
-             http://standards.ieee.org/regauth/oui/tutorials/EUI64.html,
-             March 1997.
-
-   [FDDI]    Crawford, M., "Transmission of IPv6 Packets over FDDI
-             Networks", RFC 2467, December 1998.
-
-   [MASGN]   Hinden, R. and S. Deering, "IPv6 Multicast Address
-             Assignments", RFC 2375, July 1998.
-
-   [NSAP]    Bound, J., Carpenter, B., Harrington, D., Houldsworth, J.
-             and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996.
-
-   [PRIV]    Narten, T. and R. Draves, "Privacy Extensions for Stateless
-             Address Autoconfiguration in IPv6", RFC 3041, January 2001.
-
-   [TOKEN]   Crawford, M., Narten, T. and S. Thomas, "Transmission of
-             IPv6 Packets over Token Ring Networks", RFC 2470, December
-             1998.
-
-
-
-Hinden & Deering            Standards Track                    [Page 19]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   [TRAN]    Gilligan, R. and E. Nordmark, "Transition Mechanisms for
-             IPv6 Hosts and Routers", RFC 2893, August 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 20]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-APPENDIX A: Creating Modified EUI-64 format Interface Identifiers
-
-   Depending on the characteristics of a specific link or node there are
-   a number of approaches for creating Modified EUI-64 format interface
-   identifiers.  This appendix describes some of these approaches.
-
-Links or Nodes with IEEE EUI-64 Identifiers
-
-   The only change needed to transform an IEEE EUI-64 identifier to an
-   interface identifier is to invert the "u" (universal/local) bit.  For
-   example, a globally unique IEEE EUI-64 identifier of the form:
-
-   |0              1|1              3|3              4|4              6|
-   |0              5|6              1|2              7|8              3|
-   +----------------+----------------+----------------+----------------+
-   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
-   +----------------+----------------+----------------+----------------+
-
-   where "c" are the bits of the assigned company_id, "0" is the value
-   of the universal/local bit to indicate global scope, "g" is
-   individual/group bit, and "m" are the bits of the manufacturer-
-   selected extension identifier.  The IPv6 interface identifier would
-   be of the form:
-
-   |0              1|1              3|3              4|4              6|
-   |0              5|6              1|2              7|8              3|
-   +----------------+----------------+----------------+----------------+
-   |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
-   +----------------+----------------+----------------+----------------+
-
-   The only change is inverting the value of the universal/local bit.
-
-Links or Nodes with IEEE 802 48 bit MAC's
-
-   [EUI64] defines a method to create a IEEE EUI-64 identifier from an
-   IEEE 48bit MAC identifier.  This is to insert two octets, with
-   hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC
-   (between the company_id and vendor supplied id).  For example, the 48
-   bit IEEE MAC with global scope:
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 21]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   |0              1|1              3|3              4|
-   |0              5|6              1|2              7|
-   +----------------+----------------+----------------+
-   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|
-   +----------------+----------------+----------------+
-
-   where "c" are the bits of the assigned company_id, "0" is the value
-   of the universal/local bit to indicate global scope, "g" is
-   individual/group bit, and "m" are the bits of the manufacturer-
-   selected extension identifier.  The interface identifier would be of
-   the form:
-
-   |0              1|1              3|3              4|4              6|
-   |0              5|6              1|2              7|8              3|
-   +----------------+----------------+----------------+----------------+
-   |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
-   +----------------+----------------+----------------+----------------+
-
-   When IEEE 802 48bit MAC addresses are available (on an interface or a
-   node), an implementation may use them to create interface identifiers
-   due to their availability and uniqueness properties.
-
-Links with Other Kinds of Identifiers
-
-   There are a number of types of links that have link-layer interface
-   identifiers other than IEEE EIU-64 or IEEE 802 48-bit MACs.  Examples
-   include LocalTalk and Arcnet.  The method to create an Modified EUI-
-   64 format identifier is to take the link identifier (e.g., the
-   LocalTalk 8 bit node identifier) and zero fill it to the left.  For
-   example, a LocalTalk 8 bit node identifier of hexadecimal value 0x4F
-   results in the following interface identifier:
-
-   |0              1|1              3|3              4|4              6|
-   |0              5|6              1|2              7|8              3|
-   +----------------+----------------+----------------+----------------+
-   |0000000000000000|0000000000000000|0000000000000000|0000000001001111|
-   +----------------+----------------+----------------+----------------+
-
-   Note that this results in the universal/local bit set to "0" to
-   indicate local scope.
-
-Links without Identifiers
-
-   There are a number of links that do not have any type of built-in
-   identifier.  The most common of these are serial links and configured
-   tunnels.  Interface identifiers must be chosen that are unique within
-   a subnet-prefix.
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 22]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   When no built-in identifier is available on a link the preferred
-   approach is to use a global interface identifier from another
-   interface or one which is assigned to the node itself.  When using
-   this approach no other interface connecting the same node to the same
-   subnet-prefix may use the same identifier.
-
-   If there is no global interface identifier available for use on the
-   link the implementation needs to create a local-scope interface
-   identifier.  The only requirement is that it be unique within a
-   subnet prefix.  There are many possible approaches to select a
-   subnet-prefix-unique interface identifier.  These include:
-
-      Manual Configuration
-      Node Serial Number
-      Other node-specific token
-
-   The subnet-prefix-unique interface identifier should be generated in
-   a manner that it does not change after a reboot of a node or if
-   interfaces are added or deleted from the node.
-
-   The selection of the appropriate algorithm is link and implementation
-   dependent.  The details on forming interface identifiers are defined
-   in the appropriate "IPv6 over <link>" specification.  It is strongly
-   recommended that a collision detection algorithm be implemented as
-   part of any automatic algorithm.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 23]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-APPENDIX B: Changes from RFC-2373
-
-   The following changes were made from RFC-2373 "IP Version 6
-   Addressing Architecture":
-
-   -  Clarified text in section 2.2 to allow "::" to represent one or
-      more groups of 16 bits of zeros.
-   -  Changed uniqueness requirement of Interface Identifiers from
-      unique on a link to unique within a subnet prefix.  Also added a
-      recommendation that the same interface identifier not be assigned
-      to different machines on a link.
-   -  Change site-local format to make the subnet ID field 54-bit long
-      and remove the 38-bit zero's field.
-   -  Added description of multicast scop values and rules to handle the
-      reserved scop value 0.
-   -  Revised sections 2.4 and 2.5.6 to simplify and clarify how
-      different address types  are identified.  This was done to insure
-      that implementations do not build in any knowledge about global
-      unicast format prefixes.  Changes include:
-         o  Removed Format Prefix (FP) terminology
-         o  Revised list of address types to only include exceptions to
-            global unicast and a singe entry that identifies everything
-            else as Global Unicast.
-         o  Removed list of defined prefix exceptions from section 2.5.6
-            as it is now the main part of section 2.4.
-   -  Clarified text relating to EUI-64 identifiers to distinguish
-      between IPv6's "Modified EUI-64 format" identifiers and IEEE EUI-
-      64 identifiers.
-   -  Combined the sections on the Global Unicast Addresses and NSAP
-      Addresses into a single section on Global Unicast Addresses,
-      generalized the Global Unicast format, and cited [AGGR] and [NSAP]
-      as examples.
-   -  Reordered sections 2.5.4 and 2.5.5.
-   -  Removed section 2.7.2 Assignment of New IPv6 Multicast Addresses
-      because this is being redefined elsewhere.
-   -  Added an IANA considerations section that updates the IANA IPv6
-      address allocations and documents the NSAP and AGGR allocations.
-   -  Added clarification that the "IPv4-compatible IPv6 address" must
-      use global IPv4 unicast addresses.
-   -  Divided references in to normative and non-normative sections.
-   -  Added reference to [PRIV] in section 2.5.1
-   -  Added clarification that routers must not forward multicast
-      packets outside of the scope indicated in the multicast address.
-   -  Added clarification that routers must not forward packets with
-       source address of the unspecified address.
-   -  Added clarification that routers must drop packets received on an
-      interface with destination address of loopback.
-   -  Clarified the definition of IPv4-mapped addresses.
-
-
-
-Hinden & Deering            Standards Track                    [Page 24]
-
-RFC 3513              IPv6 Addressing Architecture            April 2003
-
-
-   -  Removed the ABNF Description of Text Representations Appendix.
-   -  Removed the address block reserved for IPX addresses.
-   -  Multicast scope changes:
-         o  Changed name of scope value 1 from "node-local" to
-            "interface-local"
-         o  Defined scope value 4 as "admin-local"
-   -  Corrected reference to RFC1933 and updated references.
-   -  Many small changes to clarify and make the text more consistent.
-
-Authors' Addresses
-
-   Robert M. Hinden
-   Nokia
-   313 Fairchild Drive
-   Mountain View, CA 94043
-   USA
-
-   Phone: +1 650 625-2004
-   EMail: hinden@iprg.nokia.com
-
-
-   Stephen E. Deering
-   Cisco Systems, Inc.
-   170 West Tasman Drive
-   San Jose, CA 95134-1706
-   USA
-
-   Phone: +1 408 527-8213
-   EMail: deering@cisco.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 25]
-
-RFC 3513              IPv6 Addressing Architecture            April 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Deering            Standards Track                    [Page 26]
-
diff --git a/contrib/bind9/doc/rfc/rfc3596.txt b/contrib/bind9/doc/rfc/rfc3596.txt
deleted file mode 100644
index f65690c..0000000
--- a/contrib/bind9/doc/rfc/rfc3596.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         S. Thomson
-Request for Comments: 3596                                         Cisco
-Obsoletes: 3152, 1886                                         C. Huitema
-Category: Standards Track                                      Microsoft
-                                                              V. Ksinant
-                                                                   6WIND
-                                                              M. Souissi
-                                                                   AFNIC
-                                                            October 2003
-
-
-                 DNS Extensions to Support IP Version 6
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   This document defines the changes that need to be made to the Domain
-   Name System (DNS) to support hosts running IP version 6 (IPv6).  The
-   changes include a resource record type to store an IPv6 address, a
-   domain to support lookups based on an IPv6 address, and updated
-   definitions of existing query types that return Internet addresses as
-   part of additional section processing.  The extensions are designed
-   to be compatible with existing applications and, in particular, DNS
-   implementations themselves.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
-   2.  New resource record definition and domain. . . . . . . . . . .  2
-       2.1.  AAAA record type . . . . . . . . . . . . . . . . . . . .  3
-       2.2.  AAAA data format . . . . . . . . . . . . . . . . . . . .  3
-       2.3.  AAAA query . . . . . . . . . . . . . . . . . . . . . . .  3
-       2.4.  Textual format of AAAA records . . . . . . . . . . . . .  3
-       2.5.  IP6.ARPA domain. . . . . . . . . . . . . . . . . . . . .  3
-   3.  Modifications to existing query types. . . . . . . . . . . . .  4
-   4.  Security Considerations. . . . . . . . . . . . . . . . . . . .  4
-   5.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  4
-
-
-
-Thomson, et al.             Standards Track                     [Page 1]
-
-RFC 3596             DNS Extensions to Support IPv6         October 2003
-
-
-   6.  Intellectual Property Statement. . . . . . . . . . . . . . . .  4
-   Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . .  5
-   Appendix A: Changes from RFC 1886. . . . . . . . . . . . . . . . .  6
-   Normative References . . . . . . . . . . . . . . . . . . . . . . .  6
-   Informative References . . . . . . . . . . . . . . . . . . . . . .  6
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  7
-   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . .  8
-
-1. Introduction
-
-   Current support for the storage of Internet addresses in the Domain
-   Name System (DNS) [1,2] cannot easily be extended to support IPv6
-   addresses [3] since applications assume that address queries return
-   32-bit IPv4 addresses only.
-
-   To support the storage of IPv6 addresses in the DNS, this document
-   defines the following extensions:
-
-      o A resource record type is defined to map a domain name to an
-        IPv6 address.
-
-      o A domain is defined to support lookups based on address.
-
-      o Existing queries that perform additional section processing to
-        locate IPv4 addresses are redefined to perform additional
-        section processing on both IPv4 and IPv6 addresses.
-
-   The changes are designed to be compatible with existing software.
-   The existing support for IPv4 addresses is retained.  Transition
-   issues related to the co-existence of both IPv4 and IPv6 addresses in
-   the DNS are discussed in [4].
-
-   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.
-
-   This document combines RFC 1886 [5] and changes to RFC 1886 made by
-   RFC 3152 [6], obsoleting both.  Changes mainly consist in replacing
-   the IP6.INT domain by IP6.ARPA as defined in RFC 3152.
-
-2. New resource record definition and domain
-
-   A record type is defined to store a host's IPv6 address.  A host that
-   has more than one IPv6 address must have more than one such record.
-
-
-
-
-
-
-
-Thomson, et al.             Standards Track                     [Page 2]
-
-RFC 3596             DNS Extensions to Support IPv6         October 2003
-
-
-2.1 AAAA record type
-
-   The AAAA resource record type is a record specific to the Internet
-   class that stores a single IPv6 address.
-
-   The IANA assigned value of the type is 28 (decimal).
-
-2.2 AAAA data format
-
-   A 128 bit IPv6 address is encoded in the data portion of an AAAA
-   resource record in network byte order (high-order byte first).
-
-2.3 AAAA query
-
-   An AAAA query for a specified domain name in the Internet class
-   returns all associated AAAA resource records in the answer section of
-   a response.
-
-   A type AAAA query does not trigger additional section processing.
-
-2.4 Textual format of AAAA records
-
-   The textual representation of the data portion of the AAAA resource
-   record used in a master database file is the textual representation
-   of an IPv6 address as defined in [3].
-
-2.5 IP6.ARPA Domain
-
-   A special domain is defined to look up a record given an IPv6
-   address.  The intent of this domain is to provide a way of mapping an
-   IPv6 address to a host name, although it may be used for other
-   purposes as well.  The domain is rooted at IP6.ARPA.
-
-   An IPv6 address is represented as a name in the IP6.ARPA domain by a
-   sequence of nibbles separated by dots with the suffix ".IP6.ARPA".
-   The sequence of nibbles is encoded in reverse order, i.e., the
-   low-order nibble is encoded first, followed by the next low-order
-   nibble and so on.  Each nibble is represented by a hexadecimal digit.
-   For example, the reverse lookup domain name corresponding to the
-   address
-
-       4321:0:1:2:3:4:567:89ab
-
-   would be
-
-   b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.
-                                                                  ARPA.
-
-
-
-
-Thomson, et al.             Standards Track                     [Page 3]
-
-RFC 3596             DNS Extensions to Support IPv6         October 2003
-
-
-3. Modifications to existing query types
-
-   All existing query types that perform type A additional section
-   processing, i.e., name server (NS), location of services (SRV) and
-   mail exchange (MX) query types, must be redefined to perform both
-   type A and type AAAA additional section processing.  These
-   definitions mean that a name server must add any relevant IPv4
-   addresses and any relevant IPv6 addresses available locally to the
-   additional section of a response when processing any one of the above
-   queries.
-
-4. Security Considerations
-
-   Any information obtained from the DNS must be regarded as unsafe
-   unless techniques specified in [7] or [8] are used.  The definitions
-   of the AAAA record type and of the IP6.ARPA domain do not change the
-   model for use of these techniques.
-
-   So, this specification is not believed to cause any new security
-   problems, nor to solve any existing ones.
-
-5. IANA Considerations
-
-   There are no IANA assignments to be performed.
-
-6. 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.
-
-
-
-
-
-Thomson, et al.             Standards Track                     [Page 4]
-
-RFC 3596             DNS Extensions to Support IPv6         October 2003
-
-
-Acknowledgments
-
-   Vladimir Ksinant and Mohsen Souissi would like to thank Sebastien
-   Barbin (IRISA), Luc Beloeil (France Telecom R&D), Jean-Mickael Guerin
-   (6WIND), Vincent Levigneron (AFNIC), Alain Ritoux (6WIND), Frederic
-   Roudaut (IRISA) and G6 group for their help during the RFC 1886
-   Interop tests sessions.
-
-   Many thanks to Alain Durand and Olafur Gudmundsson for their support.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Thomson, et al.             Standards Track                     [Page 5]
-
-RFC 3596             DNS Extensions to Support IPv6         October 2003
-
-
-Appendix A: Changes from RFC 1886
-
-   The following changes were made from RFC 1886 "DNS Extensions to
-   support IP version 6":
-
-   - Replaced the "IP6.INT" domain by "IP6.ARPA".
-   - Mentioned SRV query types in section 3 "MODIFICATIONS TO
-     EXISTING QUERY TYPES"
-   - Added security considerations.
-   - Updated references :
-     * From RFC 1884 to RFC 3513 (IP Version 6 Addressing
-       Architecture).
-     * From "work in progress" to RFC 2893 (Transition Mechanisms for
-       IPv6 Hosts and Routers).
-     * Added reference to RFC 1886, RFC 3152, RFC 2535 and RFC 2845.
-   - Updated document abstract
-   - Added table of contents
-   - Added full copyright statement
-   - Added IANA considerations section
-   - Added Intellectual Property Statement
-
-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]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
-        Addressing Architecture", RFC 3513, April 2003.
-
-Informative References
-
-   [4]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
-        Hosts and Routers", RFC 2893, August 2000.
-
-   [5]  Thomson, S. and C. Huitema, "DNS Extensions to support IP
-        version 6", RFC 1886, December 1995.
-
-   [6]  Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August
-        2001.
-
-   [7]  Eastlake, D., "Domain Name System Security Extensions", RFC
-        2535, March 1999
-
-
-
-
-
-
-Thomson, et al.             Standards Track                     [Page 6]
-
-RFC 3596             DNS Extensions to Support IPv6         October 2003
-
-
-   [8]  Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
-        "Secret Key Transaction Authentication for DNS (TSIG)", RFC
-        2845, May 2000.
-
-Authors' Addresses
-
-   Susan Thomson
-   Cisco Systems
-   499 Thornall Street, 8th floor
-   Edison, NJ 08837
-
-   Phone: +1 732-635-3086
-   EMail:  sethomso@cisco.com
-
-
-   Christian Huitema
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA 98052-6399
-
-   EMail: huitema@microsoft.com
-
-
-   Vladimir Ksinant
-   6WIND S.A.
-   Immeuble Central Gare - Bat.C
-   1, place Charles de Gaulle
-   78180, Montigny-Le-Bretonneux - France
-
-   Phone: +33 1 39 30 92 36
-   EMail: vladimir.ksinant@6wind.com
-
-
-   Mohsen Souissi
-   AFNIC
-   Immeuble International
-   2, rue Stephenson,
-   78181, Saint-Quentin en Yvelines Cedex - France
-
-   Phone: +33 1 39 30 83 40
-   EMail: Mohsen.Souissi@nic.fr
-
-
-
-
-
-
-
-
-
-
-Thomson, et al.             Standards Track                     [Page 7]
-
-RFC 3596             DNS Extensions to Support IPv6         October 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 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
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Thomson, et al.             Standards Track                     [Page 8]
-
diff --git a/contrib/bind9/doc/rfc/rfc3597.txt b/contrib/bind9/doc/rfc/rfc3597.txt
deleted file mode 100644
index 19e9a55..0000000
--- a/contrib/bind9/doc/rfc/rfc3597.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                      A. Gustafsson
-Request for Comments: 3597                                  Nominum Inc.
-Category: Standards Track                                 September 2003
-
-
-           Handling of Unknown DNS Resource Record (RR) Types
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   Extending the Domain Name System (DNS) with new Resource Record (RR)
-   types currently requires changes to name server software.  This
-   document specifies the changes necessary to allow future DNS
-   implementations to handle new RR types transparently.
-
-1.  Introduction
-
-   The DNS is designed to be extensible to support new services through
-   the introduction of new resource record (RR) types.  In practice,
-   deploying a new RR type currently requires changes to the name server
-   software not only at the authoritative DNS server that is providing
-   the new information and the client making use of it, but also at all
-   slave servers for the zone containing it, and in some cases also at
-   caching name servers and forwarders used by the client.
-
-   Because the deployment of new server software is slow and expensive,
-   the potential of the DNS in supporting new services has never been
-   fully realized.  This memo proposes changes to name servers and to
-   procedures for defining new RR types aimed at simplifying the future
-   deployment of new RR types.
-
-   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].
-
-
-
-
-
-
-Gustafsson                  Standards Track                     [Page 1]
-
-RFC 3597            Handling of Unknown DNS RR Types      September 2003
-
-
-2.  Definition
-
-   An "RR of unknown type" is an RR whose RDATA format is not known to
-   the DNS implementation at hand, and whose type is not an assigned
-   QTYPE or Meta-TYPE as specified in [RFC 2929] (section 3.1) nor
-   within the range reserved in that section for assignment only to
-   QTYPEs and Meta-TYPEs.  Such an RR cannot be converted to a type-
-   specific text format, compressed, or otherwise handled in a type-
-   specific way.
-
-   In the case of a type whose RDATA format is class specific, an RR is
-   considered to be of unknown type when the RDATA format for that
-   combination of type and class is not known.
-
-3.  Transparency
-
-   To enable new RR types to be deployed without server changes, name
-   servers and resolvers MUST handle RRs of unknown type transparently.
-   That is, they must treat the RDATA section of such RRs as
-   unstructured binary data, storing and transmitting it without change
-   [RFC1123].
-
-   To ensure the correct operation of equality comparison (section 6)
-   and of the DNSSEC canonical form (section 7) when an RR type is known
-   to some but not all of the servers involved, servers MUST also
-   exactly preserve the RDATA of RRs of known type, except for changes
-   due to compression or decompression where allowed by section 4 of
-   this memo.  In particular, the character case of domain names that
-   are not subject to compression MUST be preserved.
-
-4.  Domain Name Compression
-
-   RRs containing compression pointers in the RDATA part cannot be
-   treated transparently, as the compression pointers are only
-   meaningful within the context of a DNS message.  Transparently
-   copying the RDATA into a new DNS message would cause the compression
-   pointers to point at the corresponding location in the new message,
-   which now contains unrelated data.  This would cause the compressed
-   name to be corrupted.
-
-   To avoid such corruption, servers MUST NOT compress domain names
-   embedded in the RDATA of types that are class-specific or not well-
-   known.  This requirement was stated in [RFC1123] without defining the
-   term "well-known"; it is hereby specified that only the RR types
-   defined in [RFC1035] are to be considered "well-known".
-
-
-
-
-
-
-Gustafsson                  Standards Track                     [Page 2]
-
-RFC 3597            Handling of Unknown DNS RR Types      September 2003
-
-
-   The specifications of a few existing RR types have explicitly allowed
-   compression contrary to this specification: [RFC2163] specified that
-   compression applies to the PX RR, and [RFC2535] allowed compression
-   in SIG RRs and NXT RRs records.  Since this specification disallows
-   compression in these cases, it is an update to [RFC2163] (section 4)
-   and [RFC2535] (sections 4.1.7 and 5.2).
-
-   Receiving servers MUST decompress domain names in RRs of well-known
-   type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX,
-   NXT, NAPTR, and SRV (although the current specification of the SRV RR
-   in [RFC2782] prohibits compression, [RFC2052] mandated it, and some
-   servers following that earlier specification are still in use).
-
-   Future specifications for new RR types that contain domain names
-   within their RDATA MUST NOT allow the use of name compression for
-   those names, and SHOULD explicitly state that the embedded domain
-   names MUST NOT be compressed.
-
-   As noted in [RFC1123], the owner name of an RR is always eligible for
-   compression.
-
-5.  Text Representation
-
-   In the "type" field of a master file line, an unknown RR type is
-   represented by the word "TYPE" immediately followed by the decimal RR
-   type number, with no intervening whitespace.  In the "class" field,
-   an unknown class is similarly represented as the word "CLASS"
-   immediately followed by the decimal class number.
-
-   This convention allows types and classes to be distinguished from
-   each other and from TTL values, allowing the "[<TTL>] [<class>]
-   <type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" forms of
-   [RFC1035] to both be unambiguously parsed.
-
-   The RDATA section of an RR of unknown type is represented as a
-   sequence of white space separated words as follows:
-
-      The special token \# (a backslash immediately followed by a hash
-      sign), which identifies the RDATA as having the generic encoding
-      defined herein rather than a traditional type-specific encoding.
-
-      An unsigned decimal integer specifying the RDATA length in octets.
-
-      Zero or more words of hexadecimal data encoding the actual RDATA
-      field, each containing an even number of hexadecimal digits.
-
-   If the RDATA is of zero length, the text representation contains only
-   the \# token and the single zero representing the length.
-
-
-
-Gustafsson                  Standards Track                     [Page 3]
-
-RFC 3597            Handling of Unknown DNS RR Types      September 2003
-
-
-   An implementation MAY also choose to represent some RRs of known type
-   using the above generic representations for the type, class and/or
-   RDATA, which carries the benefit of making the resulting master file
-   portable to servers where these types are unknown.  Using the generic
-   representation for the RDATA of an RR of known type can also be
-   useful in the case of an RR type where the text format varies
-   depending on a version, protocol, or similar field (or several)
-   embedded in the RDATA when such a field has a value for which no text
-   format is known, e.g., a LOC RR [RFC1876] with a VERSION other than
-   0.
-
-   Even though an RR of known type represented in the \# format is
-   effectively treated as an unknown type for the purpose of parsing the
-   RDATA text representation, all further processing by the server MUST
-   treat it as a known type and take into account any applicable type-
-   specific rules regarding compression, canonicalization, etc.
-
-   The following are examples of RRs represented in this manner,
-   illustrating various combinations of generic and type-specific
-   encodings for the different fields of the master file format:
-
-      a.example.   CLASS32     TYPE731         \# 6 abcd (
-                                               ef 01 23 45 )
-      b.example.   HS          TYPE62347       \# 0
-      e.example.   IN          A               \# 4 0A000001
-      e.example.   CLASS1      TYPE1           10.0.0.2
-
-6.  Equality Comparison
-
-   Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs
-   to be compared for equality.  Two RRs of the same unknown type are
-   considered equal when their RDATA is bitwise equal.  To ensure that
-   the outcome of the comparison is identical whether the RR is known to
-   the server or not, specifications for new RR types MUST NOT specify
-   type-specific comparison rules.
-
-   This implies that embedded domain names, being included in the
-   overall bitwise comparison, are compared in a case-sensitive manner.
-
-   As a result, when a new RR type contains one or more embedded domain
-   names, it is possible to have multiple RRs owned by the same name
-   that differ only in the character case of the embedded domain
-   name(s).  This is similar to the existing possibility of multiple TXT
-   records differing only in character case, and not expected to cause
-   any problems in practice.
-
-
-
-
-
-
-Gustafsson                  Standards Track                     [Page 4]
-
-RFC 3597            Handling of Unknown DNS RR Types      September 2003
-
-
-7.  DNSSEC Canonical Form and Ordering
-
-   DNSSEC defines a canonical form and ordering for RRs [RFC2535]
-   (section 8.1).  In that canonical form, domain names embedded in the
-   RDATA are converted to lower case.
-
-   The downcasing is necessary to ensure the correctness of DNSSEC
-   signatures when case distinctions in domain names are lost due to
-   compression, but since it requires knowledge of the presence and
-   position of embedded domain names, it cannot be applied to unknown
-   types.
-
-   To ensure continued consistency of the canonical form of RR types
-   where compression is allowed, and for continued interoperability with
-   existing implementations that already implement the [RFC2535]
-   canonical form and apply it to their known RR types, the canonical
-   form remains unchanged for all RR types whose whose initial
-   publication as an RFC was prior to the initial publication of this
-   specification as an RFC (RFC 3597).
-
-   As a courtesy to implementors, it is hereby noted that the complete
-   set of such previously published RR types that contain embedded
-   domain names, and whose DNSSEC canonical form therefore involves
-   downcasing according to the DNS rules for character comparisons,
-   consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
-   HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV,
-   DNAME, and A6.
-
-   This document specifies that for all other RR types (whether treated
-   as unknown types or treated as known types according to an RR type
-   definition RFC more recent than RFC 3597), the canonical form is such
-   that no downcasing of embedded domain names takes place, and
-   otherwise identical to the canonical form specified in [RFC2535]
-   section 8.1.
-
-   Note that the owner name is always set to lower case according to the
-   DNS rules for character comparisons, regardless of the RR type.
-
-   The DNSSEC canonical RR ordering is as specified in [RFC2535] section
-   8.3, where the octet sequence is the canonical form as revised by
-   this specification.
-
-8.  Additional Section Processing
-
-   Unknown RR types cause no additional section processing.  Future RR
-   type specifications MAY specify type-specific additional section
-   processing rules, but any such processing MUST be optional as it can
-   only be performed by servers for which the RR type in case is known.
-
-
-
-Gustafsson                  Standards Track                     [Page 5]
-
-RFC 3597            Handling of Unknown DNS RR Types      September 2003
-
-
-9.  IANA Considerations
-
-   This document does not require any IANA actions.
-
-10.  Security Considerations
-
-   This specification is not believed to cause any new security
-   problems, nor to solve any existing ones.
-
-11.  Normative References
-
-   [RFC1034]   Mockapetris, P., "Domain Names - Concepts and
-               Facilities", STD 13, RFC 1034, November 1987.
-
-   [RFC1035]   Mockapetris, P., "Domain Names - Implementation and
-               Specifications", STD 13, RFC 1035, November 1987.
-
-   [RFC1123]   Braden, R., Ed., "Requirements for Internet Hosts --
-               Application and Support", STD 3, RFC 1123, October 1989.
-
-   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
-               Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2535]   Eastlake, D., "Domain Name System Security Extensions",
-               RFC 2535, March 1999.
-
-   [RFC2163]   Allocchio, C., "Using the Internet DNS to Distribute
-               MIXER Conformant Global Address Mapping (MCGAM)", RFC
-               2163, January 1998.
-
-   [RFC2929]   Eastlake, D., Brunner-Williams, E. and B. Manning,
-               "Domain Name System (DNS) IANA Considerations", BCP 42,
-               RFC 2929, September 2000.
-
-12.  Informative References
-
-   [RFC1876]   Davis, C., Vixie, P., Goodwin, T. and I. Dickinson, "A
-               Means for Expressing Location Information in the Domain
-               Name System", RFC 1876, January 1996.
-
-   [RFC2052]   Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying
-               the location of services (DNS SRV)", RFC 2052, October
-               1996.
-
-   [RFC2136]   Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
-               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
-               RFC 2136, April 1997.
-
-
-
-
-Gustafsson                  Standards Track                     [Page 6]
-
-RFC 3597            Handling of Unknown DNS RR Types      September 2003
-
-
-   [RFC2782]   Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
-               specifying the location of services (DNS SRV)", RFC 2782,
-               February 2000.
-
-13.  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.
-
-14.  Author's Address
-
-   Andreas Gustafsson
-   Nominum, Inc.
-   2385 Bay Rd
-   Redwood City, CA 94063
-   USA
-
-   Phone: +1 650 381 6004
-   EMail: gson@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gustafsson                  Standards Track                     [Page 7]
-
-RFC 3597            Handling of Unknown DNS RR Types      September 2003
-
-
-15.  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 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
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gustafsson                  Standards Track                     [Page 8]
-
diff --git a/contrib/bind9/doc/rfc/rfc3645.txt b/contrib/bind9/doc/rfc/rfc3645.txt
deleted file mode 100644
index 6126678..0000000
--- a/contrib/bind9/doc/rfc/rfc3645.txt
+++ /dev/null
@@ -1,1459 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            S. Kwan
-Request for Comments: 3645                                       P. Garg
-Updates: 2845                                                  J. Gilroy
-Category: Standards Track                                      L. Esibov
-                                                             J. Westhead
-                                                         Microsoft Corp.
-                                                                 R. Hall
-                                                     Lucent Technologies
-                                                            October 2003
-
-
-                 Generic Security Service Algorithm for
-        Secret Key Transaction Authentication for DNS (GSS-TSIG)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   The Secret Key Transaction Authentication for DNS (TSIG) protocol
-   provides transaction level authentication for DNS.  TSIG is
-   extensible through the definition of new algorithms.  This document
-   specifies an algorithm based on the Generic Security Service
-   Application Program Interface (GSS-API) (RFC2743).  This document
-   updates RFC 2845.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                     [Page 1]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
-   2.  Algorithm Overview . . . . . . . . . . . . . . . . . . . . . .  3
-       2.1.  GSS Details. . . . . . . . . . . . . . . . . . . . . . .  4
-       2.2.  Modifications to the TSIG protocol (RFC 2845). . . . . .  4
-   3.  Client Protocol Details. . . . . . . . . . . . . . . . . . . .  5
-       3.1.  Negotiating Context. . . . . . . . . . . . . . . . . . .  5
-           3.1.1.  Call GSS_Init_sec_context. . . . . . . . . . . . .  6
-           3.1.2.  Send TKEY Query to Server. . . . . . . . . . . . .  8
-           3.1.3.  Receive TKEY Query-Response from Server. . . . . .  8
-       3.2.  Context Established. . . . . . . . . . . . . . . . . . . 11
-           3.2.1.  Terminating a Context. . . . . . . . . . . . . . . 11
-   4.  Server Protocol Details. . . . . . . . . . . . . . . . . . . . 12
-       4.1.  Negotiating Context. . . . . . . . . . . . . . . . . . . 12
-           4.1.1.  Receive TKEY Query from Client . . . . . . . . . . 12
-           4.1.2.  Call GSS_Accept_sec_context. . . . . . . . . . . . 12
-           4.1.3.  Send TKEY Query-Response to Client . . . . . . . . 13
-       4.2.  Context Established. . . . . . . . . . . . . . . . . . . 15
-           4.2.1.  Terminating a Context. . . . . . . . . . . . . . . 15
-   5.  Sending and Verifying Signed Messages. . . . . . . . . . . . . 15
-       5.1.  Sending a Signed Message - Call GSS_GetMIC . . . . . . . 15
-       5.2.  Verifying a Signed Message - Call GSS_VerifyMIC. . . . . 16
-   6.  Example usage of GSS-TSIG algorithm. . . . . . . . . . . . . . 18
-   7.  Security Considerations. . . . . . . . . . . . . . . . . . . . 22
-   8.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 22
-   9.  Conformance. . . . . . . . . . . . . . . . . . . . . . . . . . 22
-   10. Intellectual Property Statement. . . . . . . . . . . . . . . . 23
-   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
-   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
-       12.1.  Normative References. . . . . . . . . . . . . . . . . . 24
-       12.2.  Informative References. . . . . . . . . . . . . . . . . 24
-   13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
-   14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26
-
-1.  Introduction
-
-   The Secret Key Transaction Authentication for DNS (TSIG) [RFC2845]
-   protocol was developed to provide a lightweight authentication and
-   integrity of messages between two DNS entities, such as client and
-   server or server and server.  TSIG can be used to protect dynamic
-   update messages, authenticate regular message or to off-load
-   complicated DNSSEC [RFC2535] processing from a client to a server and
-   still allow the client to be assured of the integrity of the answers.
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                     [Page 2]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-   The TSIG protocol [RFC2845] is extensible through the definition of
-   new algorithms.  This document specifies an algorithm based on the
-   Generic Security Service Application Program Interface (GSS-API)
-   [RFC2743].  GSS-API is a framework that provides an abstraction of
-   security to the application protocol developer.  The security
-   services offered can include authentication, integrity, and
-   confidentiality.
-
-   The GSS-API framework has several benefits:
-
-   *  Mechanism and protocol independence.  The underlying mechanisms
-      that realize the security services can be negotiated on the fly
-      and varied over time.  For example, a client and server MAY use
-      Kerberos [RFC1964] for one transaction, whereas that same server
-      MAY use SPKM [RFC2025] with a different client.
-
-   *  The protocol developer is removed from the responsibility of
-      creating and managing a security infrastructure.  For example, the
-      developer does not need to create new key distribution or key
-      management systems.  Instead the developer relies on the security
-      service mechanism to manage this on its behalf.
-
-   The scope of this document is limited to the description of an
-   authentication mechanism only.  It does not discuss and/or propose an
-   authorization mechanism.  Readers that are unfamiliar with GSS-API
-   concepts are encouraged to read the characteristics and concepts
-   section of [RFC2743] before examining this protocol in detail.  It is
-   also assumed that the reader is familiar with [RFC2845], [RFC2930],
-   [RFC1034] and [RFC1035].
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
-   "RECOMMENDED", and "MAY" in this document are to be interpreted as
-   described in BCP 14, RFC 2119 [RFC2119].
-
-2.  Algorithm Overview
-
-   In GSS, client and server interact to create a "security context".
-   The security context can be used to create and verify transaction
-   signatures on messages between the two parties.  A unique security
-   context is required for each unique connection between client and
-   server.
-
-   Creating a security context involves a negotiation between client and
-   server.  Once a context has been established, it has a finite
-   lifetime for which it can be used to secure messages.  Thus there are
-   three states of a context associated with a connection:
-
-
-
-
-
-Kwan, et al.                Standards Track                     [Page 3]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-                              +----------+
-                              |          |
-                              V          |
-                      +---------------+  |
-                      | Uninitialized |  |
-                      |               |  |
-                      +---------------+  |
-                              |          |
-                              V          |
-                      +---------------+  |
-                      | Negotiating   |  |
-                      | Context       |  |
-                      +---------------+  |
-                              |          |
-                              V          |
-                      +---------------+  |
-                      | Context       |  |
-                      | Established   |  |
-                      +---------------+  |
-                              |          |
-                              +----------+
-
-   Every connection begins in the uninitialized state.
-
-2.1.  GSS Details
-
-   Client and server MUST be locally authenticated and have acquired
-   default credentials before using this protocol as specified in
-   Section 1.1.1 "Credentials" in RFC 2743 [RFC2743].
-
-   The GSS-TSIG algorithm consists of two stages:
-
-   I.  Establish security context.  The Client and Server use the
-       GSS_Init_sec_context and GSS_Accept_sec_context APIs to generate
-       the tokens that they pass to each other using [RFC2930] as a
-       transport mechanism.
-
-   II. Once the security context is established it is used to generate
-       and verify signatures using GSS_GetMIC and GSS_VerifyMIC APIs.
-       These signatures are exchanged by the Client and Server as a part
-       of the TSIG records exchanged in DNS messages sent between the
-       Client and Server, as described in [RFC2845].
-
-2.2.  Modifications to the TSIG protocol (RFC 2845)
-
-   Modification to RFC 2845 allows use of TSIG through signing server's
-   response in an explicitly specified place in multi message exchange
-   between two DNS entities even if client's request wasn't signed.
-
-
-
-Kwan, et al.                Standards Track                     [Page 4]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-   Specifically, Section 4.2 of RFC 2845 MUST be modified as follows:
-
-   Replace:
-      "The server MUST not generate a signed response to an unsigned
-      request."
-
-   With:
-      "The server MUST not generate a signed response to an unsigned
-      request, except in case of response to client's unsigned TKEY
-      query if secret key is established on server side after server
-      processed client's query.  Signing responses to unsigned TKEY
-      queries MUST be explicitly specified in the description of an
-      individual secret key establishment algorithm."
-
-3.  Client Protocol Details
-
-   A unique context is required for each server to which the client
-   sends secure messages.  A context is identified by a context handle.
-   A client maintains a mapping of servers to handles:
-
-      (target_name, key_name, context_handle)
-
-   The value key_name also identifies a context handle.  The key_name is
-   the owner name of the TKEY and TSIG records sent between a client and
-   a server to indicate to each other which context MUST be used to
-   process the current request.
-
-   DNS client and server MAY use various underlying security mechanisms
-   to establish security context as described in sections 3 and 4.  At
-   the same time, in order to guarantee interoperability between DNS
-   clients and servers that support GSS-TSIG it is REQUIRED that
-   security mechanism used by client enables use of Kerberos v5 (see
-   Section 9 for more information).
-
-3.1.  Negotiating Context
-
-   In GSS, establishing a security context involves the passing of
-   opaque tokens between the client and the server.  The client
-   generates the initial token and sends it to the server.  The server
-   processes the token and if necessary, returns a subsequent token to
-   the client.  The client processes this token, and so on, until the
-   negotiation is complete.  The number of times the client and server
-   exchange tokens depends on the underlying security mechanism.  A
-   completed negotiation results in a context handle.
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                     [Page 5]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-   The TKEY resource record [RFC2930] is used as the vehicle to transfer
-   tokens between client and server.  The TKEY record is a general
-   mechanism for establishing secret keys for use with TSIG.  For more
-   information, see [RFC2930].
-
-3.1.1.  Call GSS_Init_sec_context
-
-   To obtain the first token to be sent to a server, a client MUST call
-   GSS_Init_sec_context API.
-
-   The following input parameters MUST be used.  The outcome of the call
-   is indicated with the output values below.  Consult Sections 2.2.1,
-   "GSS_Init_sec_context call", of [RFC2743] for syntax definitions.
-
-   INPUTS
-     CREDENTIAL HANDLE claimant_cred_handle = NULL (NULL specifies "use
-         default").  Client MAY instead specify some other valid
-         handle to its credentials.
-     CONTEXT HANDLE input_context_handle  = 0
-     INTERNAL NAME  targ_name             = "DNS@<target_server_name>"
-     OBJECT IDENTIFIER mech_type          = Underlying security
-         mechanism chosen by implementers.  To guarantee
-         interoperability of the implementations of the GSS-TSIG
-         mechanism client MUST specify a valid underlying security
-         mechanism that enables use of Kerberos v5 (see Section 9 for
-         more information).
-     OCTET STRING   input_token           = NULL
-     BOOLEAN        replay_det_req_flag   = TRUE
-     BOOLEAN        mutual_req_flag       = TRUE
-     BOOLEAN        deleg_req_flag        = TRUE
-     BOOLEAN        sequence_req_flag     = TRUE
-     BOOLEAN        anon_req_flag         = FALSE
-     BOOLEAN        integ_req_flag        = TRUE
-     INTEGER        lifetime_req          = 0 (0 requests a default
-         value).  Client MAY instead specify another upper bound for the
-         lifetime of the context to be established in seconds.
-     OCTET STRING   chan_bindings         = Any valid channel bindings
-         as specified in Section 1.1.6 "Channel Bindings" in [RFC2743]
-
-   OUTPUTS
-     INTEGER        major_status
-     CONTEXT HANDLE output_context_handle
-     OCTET STRING   output_token
-     BOOLEAN        replay_det_state
-     BOOLEAN        mutual_state
-     INTEGER        minor_status
-     OBJECT IDENTIFIER mech_type
-     BOOLEAN        deleg_state
-
-
-
-Kwan, et al.                Standards Track                     [Page 6]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-     BOOLEAN        sequence_state
-     BOOLEAN        anon_state
-     BOOLEAN        trans_state
-     BOOLEAN        prot_ready_state
-     BOOLEAN        conf_avail
-     BOOLEAN        integ_avail
-     INTEGER        lifetime_rec
-
-   If returned major_status is set to one of the following errors:
-
-     GSS_S_DEFECTIVE_TOKEN
-     GSS_S_DEFECTIVE_CREDENTIAL
-     GSS_S_BAD_SIG (GSS_S_BAD_MIC)
-     GSS_S_NO_CRED
-     GSS_S_CREDENTIALS_EXPIRED
-     GSS_S_BAD_BINDINGS
-     GSS_S_OLD_TOKEN
-     GSS_S_DUPLICATE_TOKEN
-     GSS_S_NO_CONTEXT
-     GSS_S_BAD_NAMETYPE
-     GSS_S_BAD_NAME
-     GSS_S_BAD_MECH
-     GSS_S_FAILURE
-
-   then the client MUST abandon the algorithm and MUST NOT use the GSS-
-   TSIG algorithm to establish this security context.  This document
-   does not prescribe which other mechanism could be used to establish a
-   security context.  Next time when this client needs to establish
-   security context, the client MAY use GSS-TSIG algorithm.
-
-   Success values of major_status are GSS_S_CONTINUE_NEEDED and
-   GSS_S_COMPLETE.  The exact success code is important during later
-   processing.
-
-   The values of replay_det_state and mutual_state indicate if the
-   security package provides replay detection and mutual authentication,
-   respectively.  If returned major_status is GSS_S_COMPLETE AND one or
-   both of these values are FALSE, the client MUST abandon this
-   algorithm.
-
-   Client's behavior MAY depend on other OUTPUT parameters according to
-   the policy local to the client.
-
-   The handle output_context_handle is unique to this negotiation and is
-   stored in the client's mapping table as the context_handle that maps
-   to target_name.
-
-
-
-
-
-Kwan, et al.                Standards Track                     [Page 7]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-3.1.2.  Send TKEY Query to Server
-
-   An opaque output_token returned by GSS_Init_sec_context is
-   transmitted to the server in a query request with QTYPE=TKEY.  The
-   token itself will be placed in a Key Data field of the RDATA field in
-   the TKEY resource record in the additional records section of the
-   query.  The owner name of the TKEY resource record set queried for
-   and the owner name of the supplied TKEY resource record in the
-   additional records section MUST be the same.  This name uniquely
-   identifies the security context to both the client and server, and
-   thus the client SHOULD use a value which is globally unique as
-   described in [RFC2930].  To achieve global uniqueness, the name MAY
-   contain a UUID/GUID [ISO11578].
-
-      TKEY Record
-        NAME = client-generated globally unique domain name string
-               (as described in [RFC2930])
-        RDATA
-           Algorithm Name      = gss-tsig
-           Mode                = 3 (GSS-API negotiation - per [RFC2930])
-           Key Size            = size of output_token in octets
-           Key Data            = output_token
-
-   The remaining fields in the TKEY RDATA, i.e., Inception, Expiration,
-   Error, Other Size and Data Fields, MUST be set according to
-   [RFC2930].
-
-   The query is transmitted to the server.
-
-   Note: if the original client call to GSS_Init_sec_context returned
-   any major_status other than GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE,
-   then the client MUST NOT send TKEY query.  Client's behavior in this
-   case is described above in Section 3.1.1.
-
-3.1.3.  Receive TKEY Query-Response from Server
-
-   Upon the reception of the TKEY query the DNS server MUST respond
-   according to the description in Section 4.  This section specifies
-   the behavior of the client after it receives the matching response to
-   its query.
-
-   The next processing step depends on the value of major_status from
-   the most recent call that client performed to GSS_Init_sec_context:
-   either GSS_S_COMPLETE or GSS_S_CONTINUE.
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                     [Page 8]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-3.1.3.1.  Value of major_status == GSS_S_COMPLETE
-
-   If the last call to GSS_Init_sec_context yielded a major_status value
-   of GSS_S_COMPLETE and a non-NULL output_token was sent to the server,
-   then the client side component of the negotiation is complete and the
-   client is awaiting confirmation from the server.
-
-   Confirmation is in the form of a query response with RCODE=NOERROR
-   and with the last client supplied TKEY record in the answer section
-   of the query.  The response MUST be signed with a TSIG record.  Note
-   that the server is allowed to sign a response to unsigned client's
-   query due to modification to the RFC 2845 specified in Section 2.2
-   above.  The signature in the TSIG record MUST be verified using the
-   procedure detailed in section 5, Sending and Verifying Signed
-   Messages.  If the response is not signed, OR if the response is
-   signed but the signature is invalid, then an attacker has tampered
-   with the message in transit or has attempted to send the client a
-   false response.  In this case, the client MAY continue waiting for a
-   response to its last TKEY query until the time period since the
-   client sent last TKEY query expires.  Such a time period is specified
-   by the policy local to the client.  This is a new option that allows
-   the DNS client to accept multiple answers for one query ID and select
-   one (not necessarily the first one) based on some criteria.
-
-   If the signature is verified, the context state is advanced to
-   Context Established.  Proceed to section 3.2 for usage of the
-   security context.
-
-3.1.3.2.  Value of major_status == GSS_S_CONTINUE_NEEDED
-
-   If the last call to GSS_Init_sec_context yielded a major_status value
-   of GSS_S_CONTINUE_NEEDED, then the negotiation is not yet complete.
-   The server will return to the client a query response with a TKEY
-   record in the Answer section.  If the DNS message error is not
-   NO_ERROR or error field in the TKEY record is not 0 (i.e., no error),
-   then the client MUST abandon this negotiation sequence.  The client
-   MUST delete an active context by calling GSS_Delete_sec_context
-   providing the associated context_handle.  The client MAY repeat the
-   negotiation sequence starting with the uninitialized state as
-   described in section 3.1.  To prevent infinite looping the number of
-   attempts to establish a security context MUST be limited to ten or
-   less.
-
-   If the DNS message error is NO_ERROR and the error field in the TKEY
-   record is 0 (i.e., no error), then the client MUST pass a token
-   specified in the Key Data field in the TKEY resource record to
-
-
-
-
-
-Kwan, et al.                Standards Track                     [Page 9]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-   GSS_Init_sec_context using the same parameters values as in previous
-   call except values for CONTEXT HANDLE input_context_handle and OCTET
-   STRING input_token as described below:
-
-   INPUTS
-     CONTEXT HANDLE input_context_handle  = context_handle (this is the
-          context_handle corresponding to the key_name which is the
-          owner name of the TKEY record in the answer section in the
-          TKEY query response)
-
-     OCTET STRING   input_token           = token from Key field of
-                                            TKEY record
-
-   Depending on the following OUTPUT values of GSS_Init_sec_context
-
-        INTEGER        major_status
-        OCTET STRING   output_token
-
-   the client MUST take one of the following actions:
-
-   If OUTPUT major_status is set to one of the following values:
-
-        GSS_S_DEFECTIVE_TOKEN
-        GSS_S_DEFECTIVE_CREDENTIAL
-        GSS_S_BAD_SIG (GSS_S_BAD_MIC)
-        GSS_S_NO_CRED
-        GSS_S_CREDENTIALS_EXPIRED
-        GSS_S_BAD_BINDINGS
-        GSS_S_OLD_TOKEN
-        GSS_S_DUPLICATE_TOKEN
-        GSS_S_NO_CONTEXT
-        GSS_S_BAD_NAMETYPE
-        GSS_S_BAD_NAME
-        GSS_S_BAD_MECH
-        GSS_S_FAILURE
-
-   the client MUST abandon this negotiation sequence.  This means that
-   the client MUST delete an active context by calling
-   GSS_Delete_sec_context providing the associated context_handle.  The
-   client MAY repeat the negotiation sequence starting with the
-   uninitialized state as described in section 3.1.  To prevent infinite
-   looping the number of attempts to establish a security context MUST
-   be limited to ten or less.
-
-   If OUTPUT major_status is GSS_S_CONTINUE_NEEDED OR GSS_S_COMPLETE
-   then client MUST act as described below.
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 10]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-   If the response from the server was signed, and the OUTPUT
-   major_status is GSS_S_COMPLETE,then the signature in the TSIG record
-   MUST be verified using the procedure detailed in section 5, Sending
-   and Verifying Signed Messages.  If the signature is invalid, then the
-   client MUST abandon this negotiation sequence.  This means that the
-   client MUST delete an active context by calling
-   GSS_Delete_sec_context providing the associated context_handle.  The
-   client MAY repeat the negotiation sequence starting with the
-   uninitialized state as described in section 3.1.  To prevent infinite
-   looping the number of attempts to establish a security context MUST
-   be limited to ten or less.
-
-   If major_status is GSS_S_CONTINUE_NEEDED the negotiation is not yet
-   finished.  The token output_token MUST be passed to the server in a
-   TKEY record by repeating the negotiation sequence beginning with
-   section 3.1.2.  The client MUST place a limit on the number of
-   continuations in a context negotiation to prevent endless looping.
-   Such limit SHOULD NOT exceed value of 10.
-
-   If major_status is GSS_S_COMPLETE and output_token is non-NULL, the
-   client-side component of the negotiation is complete but the token
-   output_token MUST be passed to the server by repeating the
-   negotiation sequence beginning with section 3.1.2.
-
-   If major_status is GSS_S_COMPLETE and output_token is NULL, context
-   negotiation is complete.  The context state is advanced to Context
-   Established.  Proceed to section 3.2 for usage of the security
-   context.
-
-3.2.  Context Established
-
-   When context negotiation is complete, the handle context_handle MUST
-   be used for the generation and verification of transaction
-   signatures.
-
-   The procedures for sending and receiving signed messages are
-   described in section 5, Sending and Verifying Signed Messages.
-
-3.2.1.  Terminating a Context
-
-   When the client is not intended to continue using the established
-   security context, the client SHOULD delete an active context by
-   calling GSS_Delete_sec_context providing the associated
-   context_handle, AND client SHOULD delete the established context on
-   the DNS server by using TKEY RR with the Mode field set to 5, i.e.,
-   "key deletion" [RFC2930].
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 11]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-4.  Server Protocol Details
-
-   As on the client-side, the result of a successful context negotiation
-   is a context handle used in future generation and verification of the
-   transaction signatures.
-
-   A server MAY be managing several contexts with several clients.
-   Clients identify their contexts by providing a key name in their
-   request.  The server maintains a mapping of key names to handles:
-
-      (key_name, context_handle)
-
-4.1.  Negotiating Context
-
-   A server MUST recognize TKEY queries as security context negotiation
-   messages.
-
-4.1.1.  Receive TKEY Query from Client
-
-   Upon receiving a query with QTYPE = TKEY, the server MUST examine
-   whether the Mode and Algorithm Name fields of the TKEY record in the
-   additional records section of the message contain values of 3 and
-   gss-tsig, respectively.  If they do, then the (key_name,
-   context_handle) mapping table is searched for the key_name matching
-   the owner name of the TKEY record in the additional records section
-   of the query.  If the name is found in the table and the security
-   context for this name is established and not expired, then the server
-   MUST respond to the query with BADNAME error in the TKEY error field.
-   If the name is found in the table and the security context is not
-   established, the corresponding context_handle is used in subsequent
-   GSS operations.  If the name is found but the security context is
-   expired, then the server deletes this security context, as described
-   in Section 4.2.1, and interprets this query as a start of new
-   security context negotiation and performs operations described in
-   Section 4.1.2 and 4.1.3.  If the name is not found, then the server
-   interprets this query as a start of new security context negotiation
-   and performs operations described in Section 4.1.2 and 4.1.3.
-
-4.1.2.  Call GSS_Accept_sec_context
-
-   The server performs its side of a context negotiation by calling
-   GSS_Accept_sec_context.  The following input parameters MUST be used.
-   The outcome of the call is indicated with the output values below.
-   Consult Sections 2.2.2 "GSS_Accept_sec_context call" of the RFC 2743
-   [RFC2743] for syntax definitions.
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 12]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-   INPUTS
-     CONTEXT HANDLE input_context_handle  = 0 if new negotiation,
-                                            context_handle matching
-                                         key_name if ongoing negotiation
-     OCTET STRING   input_token           = token specified in the Key
-           field from TKEY RR (from Additional records Section of
-           the client's query)
-
-     CREDENTIAL HANDLE acceptor_cred_handle = NULL (NULL specifies "use
-           default").  Server MAY instead specify some other valid
-           handle to its credentials.
-     OCTET STRING   chan_bindings          = Any valid channel bindings
-           as specified in Section 1.1.6 "Channel Bindings" in [RFC2743]
-
-   OUTPUTS
-     INTEGER        major_status
-     CONTEXT_HANDLE output_context_handle
-     OCTET STRING   output_token
-     INTEGER        minor_status
-     INTERNAL NAME  src_name
-     OBJECT IDENTIFIER  mech_type
-     BOOLEAN        deleg_state
-     BOOLEAN        mutual_state
-     BOOLEAN        replay_det_state
-     BOOLEAN        sequence_state
-     BOOLEAN        anon_state
-     BOOLEAN        trans_state
-     BOOLEAN        prot_ready_state
-     BOOLEAN        conf_avail
-     BOOLEAN        integ_avail
-     INTEGER        lifetime_rec
-     CONTEXT_HANDLE delegated_cred_handle
-
-   If this is the first call to GSS_Accept_sec_context in a new
-   negotiation, then output_context_handle is stored in the server's
-   key-mapping table as the context_handle that maps to the name of the
-   TKEY record.
-
-4.1.3.  Send TKEY Query-Response to Client
-
-   The server MUST respond to the client with a TKEY query response with
-   RCODE = NOERROR, that contains a TKEY record in the answer section.
-
-   If OUTPUT major_status is one of the following errors the error field
-   in the TKEY record set to BADKEY.
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 13]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-        GSS_S_DEFECTIVE_TOKEN
-        GSS_S_DEFECTIVE_CREDENTIAL
-        GSS_S_BAD_SIG (GSS_S_BAD_MIC)
-        GSS_S_DUPLICATE_TOKEN
-        GSS_S_OLD_TOKEN
-        GSS_S_NO_CRED
-        GSS_S_CREDENTIALS_EXPIRED
-        GSS_S_BAD_BINDINGS
-        GSS_S_NO_CONTEXT
-        GSS_S_BAD_MECH
-        GSS_S_FAILURE
-
-   If OUTPUT major_status is set to  GSS_S_COMPLETE or
-   GSS_S_CONTINUE_NEEDED then server MUST act as described below.
-
-   If major_status is GSS_S_COMPLETE the server component of the
-   negotiation is finished.  If output_token is non-NULL, then it MUST
-   be returned to the client in a Key Data field of the RDATA in TKEY.
-   The error field in the TKEY record is set to NOERROR.  The message
-   MUST be signed with a TSIG record as described in section 5, Sending
-   and Verifying Signed Messages.  Note that server is allowed to sign a
-   response to unsigned client's query due to modification to the RFC
-   2845 specified in Section 2.2 above.  The context state is advanced
-   to Context Established.  Section 4.2 discusses the usage of the
-   security context.
-
-   If major_status is GSS_S_COMPLETE and output_token is NULL, then the
-   TKEY record received from the client MUST be returned in the Answer
-   section of the response.  The message MUST be signed with a TSIG
-   record as described in section 5, Sending and Verifying Signed
-   Messages.  Note that server is allowed to sign a response to unsigned
-   client's query due to modification to the RFC 2845 specified in
-   section 2.2 above.  The context state is advanced to Context
-   Established.  Section 4.2 discusses the usage of the security
-   context.
-
-   If major_status is GSS_S_CONTINUE_NEEDED, the server component of the
-   negotiation is not yet finished.  The server responds to the TKEY
-   query with a standard query response, placing in the answer section a
-   TKEY record containing output_token in the Key Data RDATA field.  The
-   error field in the TKEY record is set to NOERROR.  The server MUST
-   limit the number of times that a given context is allowed to repeat,
-   to prevent endless looping.  Such limit SHOULD NOT exceed value of
-   10.
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 14]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-   In all cases, except if major_status is GSS_S_COMPLETE and
-   output_token is NULL, other TKEY record fields MUST contain the
-   following values:
-
-        NAME = key_name
-        RDATA
-           Algorithm Name      = gss-tsig
-           Mode                = 3 (GSS-API negotiation - per [RFC2930])
-           Key Size            = size of output_token in octets
-
-   The remaining fields in the TKEY RDATA, i.e., Inception, Expiration,
-   Error, Other Size and Data Fields, MUST be set according to
-   [RFC2930].
-
-4.2.  Context Established
-
-   When context negotiation is complete, the handle context_handle is
-   used for the generation and verification of transaction signatures.
-   The handle is valid for a finite amount of time determined by the
-   underlying security mechanism.  A server MAY unilaterally terminate a
-   context at any time (see section 4.2.1).
-
-   Server SHOULD limit the amount of memory used to cache established
-   contexts.
-
-   The procedures for sending and receiving signed messages are given in
-   section 5, Sending and Verifying Signed Messages.
-
-4.2.1.  Terminating a Context
-
-   A server can terminate any established context at any time.  The
-   server MAY hint to the client that the context is being deleted by
-   including a TKEY RR in a response with the Mode field set to 5, i.e.,
-   "key deletion" [RFC2930].  An active context is deleted by calling
-   GSS_Delete_sec_context providing the associated context_handle.
-
-5.  Sending and Verifying Signed Messages
-
-5.1.  Sending a Signed Message - Call GSS_GetMIC
-
-   The procedure for sending a signature-protected message is specified
-   in [RFC2845].  The data to be passed to the signature routine
-   includes the whole DNS message with specific TSIG variables appended.
-   For the exact format, see [RFC2845].  For this protocol, use the
-   following TSIG variable values:
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 15]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-      TSIG Record
-        NAME = key_name that identifies this context
-        RDATA
-           Algorithm Name = gss-tsig
-
-   Assign the remaining fields in the TSIG RDATA appropriate values as
-   described in [RFC2845].
-
-   The signature is generated by calling GSS_GetMIC.  The following
-   input parameters MUST be used.  The outcome of the call is indicated
-   with the output values specified below.  Consult Sections 2.3.1
-   "GSS_GetMIC call" of the RFC 2743[RFC2743] for syntax definitions.
-
-   INPUTS
-     CONTEXT HANDLE context_handle = context_handle for key_name
-     OCTET STRING   message        = outgoing message plus TSIG
-                                     variables (per [RFC2845])
-     INTEGER qop_req               = 0 (0 requests a default
-         value).  Caller MAY instead specify other valid value (for
-         details see Section 1.2.4 in [RFC2743])
-
-   OUTPUTS
-     INTEGER        major_status
-     INTEGER        minor_status
-     OCTET STRING   per_msg_token
-
-   If major_status is GSS_S_COMPLETE, then signature generation
-   succeeded.  The signature in per_msg_token is inserted into the
-   Signature field of the TSIG RR and the message is transmitted.
-
-   If major_status is GSS_S_CONTEXT_EXPIRED, GSS_S_CREDENTIALS_EXPIRED
-   or GSS_S_FAILURE the caller MUST delete the security context, return
-   to the uninitialized state and SHOULD negotiate a new security
-   context, as described above in Section 3.1
-
-   If major_status is GSS_S_NO_CONTEXT, the caller MUST remove the entry
-   for key_name from the (target_ name, key_name, context_handle)
-   mapping table, return to the uninitialized state and SHOULD negotiate
-   a new security context, as described above in Section 3.1
-
-   If major_status is GSS_S_BAD_QOP, the caller SHOULD repeat the
-   GSS_GetMIC call with allowed QOP value.  The number of such
-   repetitions MUST be limited to prevent infinite loops.
-
-5.2.  Verifying a Signed Message - Call GSS_VerifyMIC
-
-   The procedure for verifying a signature-protected message is
-   specified in [RFC2845].
-
-
-
-Kwan, et al.                Standards Track                    [Page 16]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-   The NAME of the TSIG record determines which context_handle maps to
-   the context that MUST be used to verify the signature.  If the NAME
-   does not map to an established context, the server MUST send a
-   standard TSIG error response to the client indicating BADKEY in the
-   TSIG error field (as described in [RFC2845]).
-
-   For the GSS algorithm, a signature is verified by using
-   GSS_VerifyMIC:
-
-   INPUTS
-     CONTEXT HANDLE context_handle = context_handle for key_name
-     OCTET STRING   message        = incoming message plus TSIG
-                                     variables (per [RFC2845])
-     OCTET STRING   per_msg_token  = Signature field from TSIG RR
-
-   OUTPUTS
-     INTEGER        major_status
-     INTEGER        minor_status
-     INTEGER        qop_state
-
-   If major_status is GSS_S_COMPLETE, the signature is authentic and the
-   message was delivered intact.  Per [RFC2845], the timer values of the
-   TSIG record MUST also be valid before considering the message to be
-   authentic.  The caller MUST not act on the request or response in the
-   message until these checks are verified.
-
-   When a server is processing a client request, the server MUST send a
-   standard TSIG error response to the client indicating BADKEY in the
-   TSIG error field as described in [RFC2845], if major_status is set to
-   one of the following values
-
-        GSS_S_DEFECTIVE_TOKEN
-        GSS_S_BAD_SIG (GSS_S_BAD_MIC)
-        GSS_S_DUPLICATE_TOKEN
-        GSS_S_OLD_TOKEN
-        GSS_S_UNSEQ_TOKEN
-        GSS_S_GAP_TOKEN
-        GSS_S_CONTEXT_EXPIRED
-        GSS_S_NO_CONTEXT
-        GSS_S_FAILURE
-
-   If the timer values of the TSIG record are invalid, the message MUST
-   NOT be considered authentic.  If this error checking fails when a
-   server is processing a client request, the appropriate error response
-   MUST be sent to the client according to [RFC2845].
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 17]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-6.  Example usage of GSS-TSIG algorithm
-
-   This Section describes an example where a Client, client.example.com,
-   and a Server, server.example.com, establish a security context
-   according to the algorithm described above.
-
-  I.  Client initializes security context negotiation
-
-  To establish a security context with a server, server.example.com, the
-  Client calls GSS_Init_sec_context with the following parameters.
-  (Note that some INPUT and OUTPUT parameters not critical for this
-  algorithm are not described in this example.)
-
-     CONTEXT HANDLE input_context_handle  = 0
-     INTERNAL NAME  targ_name             = "DNS@server.example.com"
-     OCTET STRING   input_token           = NULL
-     BOOLEAN        replay_det_req_flag   = TRUE
-     BOOLEAN        mutual_req_flag       = TRUE
-
-  The OUTPUTS parameters returned by GSS_Init_sec_context include
-     INTEGER        major_status = GSS_S_CONTINUE_NEEDED
-     CONTEXT HANDLE output_context_handle context_handle
-     OCTET STRING   output_token output_token
-     BOOLEAN        replay_det_state = TRUE
-     BOOLEAN        mutual_state = TRUE
-
-  Client verifies that replay_det_state and mutual_state values are
-  TRUE.  Since the major_status is GSS_S_CONTINUE_NEEDED, which is a
-  success OUTPUT major_status value, client stores context_handle that
-  maps to "DNS@server.example.com" and proceeds to the next step.
-
-  II.  Client sends a query with QTYPE = TKEY to server
-
-  Client sends a query with QTYPE = TKEY for a client-generated globally
-  unique domain name string, 789.client.example.com.server.example.com.
-  Query contains a TKEY record in its Additional records section with
-  the following fields.  (Note that some fields not specific to this
-  algorithm are not specified.)
-
-     NAME = 789.client.example.com.server.example.com.
-     RDATA
-        Algorithm Name      = gss-tsig
-        Mode                = 3 (GSS-API negotiation - per [RFC2930])
-        Key Size            = size of output_token in octets
-        Key Data            = output_token
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 18]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-  After the key_name 789.client.example.com.server.example.com.
-  is generated it is stored in the client's (target_name, key_name,
-  context_handle) mapping table.
-
-  III.  Server receives a query with QTYPE = TKEY
-
-  When server receives a query with QTYPE = TKEY, the server verifies
-  that Mode and Algorithm fields in the TKEY record in the Additional
-  records section of the query are set to 3 and "gss-tsig" respectively.
-  It finds that the key_name 789.client.example.com.server.example.com.
-  is not listed in its (key_name, context_handle) mapping table.
-
-  IV.  Server calls GSS_Accept_sec_context
-
-  To continue security context negotiation server calls
-  GSS_Accept_sec_context with the following parameters.  (Note that
-  some INPUT and OUTPUT parameters not critical for this algorithm
-  are not described in this example.)
-
-   INPUTS
-     CONTEXT HANDLE input_context_handle  = 0
-     OCTET STRING   input_token           = token specified in the Key
-                              field from TKEY RR (from Additional
-                              records section of the client's query)
-
-  The OUTPUTS parameters returned by GSS_Accept_sec_context include
-     INTEGER        major_status = GSS_S_CONTINUE_NEEDED
-     CONTEXT_HANDLE output_context_handle context_handle
-     OCTET STRING   output_token output_token
-
-  Server stores the mapping of the
-  789.client.example.com.server.example.com. to OUTPUT context_handle
-  in its (key_name, context_handle) mapping table.
-
-  V.  Server responds to the TKEY query
-
-  Since the major_status = GSS_S_CONTINUE_NEEDED in the last server's
-  call to GSS_Accept_sec_context, the server responds to the TKEY query
-  placing in the answer section a TKEY record containing output_token in
-  the Key Data RDATA field.  The error field in the TKEY record is set
-  to 0.  The RCODE in the query response is set to NOERROR.
-
-  VI.  Client processes token returned by server
-
-  When the client receives the TKEY query response from the server, the
-  client calls GSS_Init_sec_context with the following parameters.
-  (Note that some INPUT and OUTPUT parameters not critical for this
-  algorithm are not described in this example.)
-
-
-
-Kwan, et al.                Standards Track                    [Page 19]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-     CONTEXT HANDLE input_context_handle  = the context_handle stored
-          in the client's mapping table entry (DNS@server.example.com.,
-          789.client.example.com.server.example.com., context_handle)
-     INTERNAL NAME  targ_name             = "DNS@server.example.com"
-     OCTET STRING   input_token           = token from Key field of TKEY
-          record from the Answer section of the server's response
-     BOOLEAN        replay_det_req_flag   = TRUE
-     BOOLEAN        mutual_req_flag       = TRUE
-
-  The OUTPUTS parameters returned by GSS_Init_sec_context include
-     INTEGER        major_status = GSS_S_COMPLETE
-     CONTEXT HANDLE output_context_handle = context_handle
-     OCTET STRING   output_token = output_token
-     BOOLEAN        replay_det_state = TRUE
-     BOOLEAN        mutual_state = TRUE
-
-  Since the major_status is set to GSS_S_COMPLETE the client side
-  security context is established, but since the output_token is not
-  NULL client MUST send a TKEY query to the server as described below.
-
-  VII.  Client sends a query with QTYPE = TKEY to server
-
-  Client sends to the server a TKEY query for the
-  789.client.example.com.server.example.com. name.  Query contains a
-  TKEY record in its Additional records section with the following
-  fields.  (Note that some INPUT and OUTPUT parameters not critical to
-  this algorithm are not described in this example.)
-
-     NAME = 789.client.example.com.server.example.com.
-     RDATA
-        Algorithm Name      = gss-tsig
-        Mode                = 3 (GSS-API negotiation - per [RFC2930])
-        Key Size            = size of output_token in octets
-        Key Data            = output_token
-
-  VIII.  Server receives a TKEY query
-
-  When the server receives a TKEY query, the server verifies that Mode
-  and Algorithm fields in the TKEY record in the Additional records
-  section of the query are set to 3 and gss-tsig, respectively.  It
-  finds that the key_name 789.client.example.com.server.example.com. is
-  listed in its (key_name, context_handle) mapping table.
-
-
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 20]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-  IX.  Server calls GSS_Accept_sec_context
-
-  To continue security context negotiation server calls
-  GSS_Accept_sec_context with the following parameters (Note that some
-  INPUT and OUTPUT parameters not critical for this algorithm are not
-  described in this example)
-
-   INPUTS
-     CONTEXT HANDLE input_context_handle  = context_handle from the
-           (789.client.example.com.server.example.com., context_handle)
-           entry in the server's mapping table
-     OCTET STRING   input_token           = token specified in the Key
-           field of TKEY RR (from Additional records Section of
-           the client's query)
-
-  The OUTPUTS parameters returned by GSS_Accept_sec_context include
-     INTEGER        major_status = GSS_S_COMPLETE
-     CONTEXT_HANDLE output_context_handle = context_handle
-     OCTET STRING   output_token = NULL
-
-  Since major_status = GSS_S_COMPLETE, the security context on the
-  server side is established, but the server still needs to respond to
-  the client's TKEY query, as described below.  The security context
-  state is advanced to Context Established.
-
-  X.  Server responds to the TKEY query
-
-  Since the major_status = GSS_S_COMPLETE in the last server's call to
-  GSS_Accept_sec_context and the output_token is NULL, the server
-  responds to the TKEY query placing in the answer section a TKEY record
-  that was sent by the client in the Additional records section of the
-  client's latest TKEY query.  In addition, this server places a
-  TSIG record in additional records section of its response.  Server
-  calls GSS_GetMIC to generate a signature to include it in the TSIG
-  record.  The server specifies the following GSS_GetMIC INPUT
-  parameters:
-
-     CONTEXT HANDLE context_handle = context_handle from the
-           (789.client.example.com.server.example.com., context_handle)
-           entry in the server's mapping table
-     OCTET STRING   message        = outgoing message plus TSIG
-                                   variables (as described in [RFC2845])
-
-  The OUTPUTS parameters returned by GSS_GetMIC include
-     INTEGER        major_status = GSS_S_COMPLETE
-     OCTET STRING   per_msg_token
-
-  Signature field in the TSIG record is set to per_msg_token.
-
-
-
-Kwan, et al.                Standards Track                    [Page 21]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-  XI.  Client processes token returned by server
-
-  Client receives the TKEY query response from the server.  Since the
-  major_status was GSS_S_COMPLETE in the last client's call to
-  GSS_Init_sec_context, the client verifies that the server's response
-  is signed.  To validate the signature, the client calls
-  GSS_VerifyMIC with the following parameters:
-
-   INPUTS
-     CONTEXT HANDLE context_handle = context_handle for
-                  789.client.example.com.server.example.com. key_name
-     OCTET STRING   message        = incoming message plus TSIG
-                                  variables (as described in [RFC2845])
-     OCTET STRING   per_msg_token  = Signature field from TSIG RR
-                  included in the server's query response
-
-  Since the OUTPUTS parameter major_status = GSS_S_COMPLETE, the
-  signature is validated, security negotiation is complete and the
-  security context state is advanced to Context Established.  These
-  client and server will use the established security context to sign
-  and validate the signatures when they exchange packets with each
-  other until the context expires.
-
-7.  Security Considerations
-
-   This document describes a protocol for DNS security using GSS-API.
-   The security provided by this protocol is only as effective as the
-   security provided by the underlying GSS mechanisms.
-
-   All the security considerations from RFC 2845, RFC 2930 and RFC 2743
-   apply to the protocol described in this document.
-
-8.  IANA Considerations
-
-   The IANA has reserved the TSIG Algorithm name gss-tsig for the use in
-   the Algorithm fields of TKEY and TSIG resource records.  This
-   Algorithm name refers to the algorithm described in this document.
-   The requirement to have this name registered with IANA is specified
-   in RFC 2845.
-
-9.  Conformance
-
-   The GSS API using SPNEGO [RFC2478] provides maximum flexibility to
-   choose the underlying security mechanisms that enables security
-   context negotiation.  GSS API using SPNEGO [RFC2478] enables client
-   and server to negotiate and choose such underlying security
-   mechanisms on the fly.  To support such flexibility, DNS clients and
-   servers SHOULD specify SPNEGO mech_type in their GSS API calls.  At
-
-
-
-Kwan, et al.                Standards Track                    [Page 22]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-   the same time, in order to guarantee interoperability between DNS
-   clients and servers that support GSS-TSIG it is required that
-
-   -  DNS servers specify SPNEGO mech_type
-   -  GSS APIs called by DNS client support Kerberos v5
-   -  GSS APIs called by DNS server support SPNEGO [RFC2478] and
-      Kerberos v5.
-
-   In addition to these, GSS APIs used by DNS client and server MAY also
-   support other underlying security mechanisms.
-
-10.  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.
-
-11.  Acknowledgements
-
-   The authors of this document would like to thank the following people
-   for their contribution to this specification:  Chuck Chan, Mike
-   Swift, Ram Viswanathan, Olafur Gudmundsson, Donald E. Eastlake, 3rd
-   and Erik Nordmark.
-
-
-
-
-
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 23]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-12.  References
-
-12.1.  Normative References
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
-             Negotiation Mechanism", RFC 2478, December 1998.
-
-   [RFC2743] Linn, J., "Generic Security Service Application Program
-             Interface, Version 2 , Update 1", RFC 2743, January 2000.
-
-   [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D. and B.
-             Wellington, "Secret Key Transaction Authentication for DNS
-             (TSIG)", RFC 2845, May 2000.
-
-   [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
-             RR)", RFC 2930, September 2000.
-
-12.2.  Informative References
-
-
-   [ISO11578] "Information technology", "Open Systems Interconnection",
-              "Remote Procedure Call", ISO/IEC 11578:1996,
-              http://www.iso.ch/cate/d2229.html.
-
-   [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 1034, November 1987.
-
-   [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
-             1964, June 1996.
-
-   [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
-             (SPKM)", RFC 2025, October 1996.
-
-   [RFC2137] Eastlake 3rd, D., "Secure Domain Name System Dynamic
-             Update", RFC 2137, April 1997.
-
-   [RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions",
-             RFC 2535, March 1999.
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 24]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-13.  Authors' Addresses
-
-   Stuart Kwan
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   USA
-   EMail: skwan@microsoft.com
-
-   Praerit Garg
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   USA
-   EMail: praeritg@microsoft.com
-
-   James Gilroy
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   USA
-   EMail: jamesg@microsoft.com
-
-   Levon Esibov
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   USA
-   EMail: levone@microsoft.com
-
-   Randy Hall
-   Lucent Technologies
-   400 Lapp Road
-   Malvern PA 19355
-   USA
-   EMail: randyhall@lucent.com
-
-   Jeff Westhead
-   Microsoft Corporation
-   One Microsoft Way
-   Redmond, WA  98052
-   USA
-   EMail: jwesth@microsoft.com
-
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 25]
-
-RFC 3645                        GSS-TSIG                    October 2003
-
-
-14.  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 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
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kwan, et al.                Standards Track                    [Page 26]
-
diff --git a/contrib/bind9/doc/rfc/rfc3655.txt b/contrib/bind9/doc/rfc/rfc3655.txt
deleted file mode 100644
index 13e586b..0000000
--- a/contrib/bind9/doc/rfc/rfc3655.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                      B. Wellington
-Request for Comments: 3655                                O. Gudmundsson
-Updates: 2535                                              November 2003
-Category: Standards Track
-
-
-            Redefinition of DNS Authenticated Data (AD) bit
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   This document alters the specification defined in RFC 2535.  Based on
-   implementation experience, the Authenticated Data (AD) bit in the DNS
-   header is not useful.  This document redefines the AD bit such that
-   it is only set if all answers or records proving that no answers
-   exist in the response has been cryptographically verified or
-   otherwise meets the server's local security policy.
-
-1.  Introduction
-
-   Familiarity with the DNS system [RFC1035] and DNS security extensions
-   [RFC2535] is helpful but not necessary.
-
-   As specified in RFC 2535 (section 6.1), the AD (Authenticated Data)
-   bit indicates in a response that all data included in the answer and
-   authority sections of the response have been authenticated by the
-   server according to the policies of that server.  This is not
-   especially useful in practice, since a conformant server SHOULD never
-   reply with data that failed its security policy.
-
-   This document redefines the AD bit such that it is only set if all
-   data in the response has been cryptographically verified or otherwise
-   meets the server's local security policy.  Thus, neither a response
-   containing properly delegated insecure data, nor a server configured
-   without DNSSEC keys, will have the AD set.  As before, data that
-   failed to verify will not be returned.  An application running on a
-   host that has a trust relationship with the server performing the
-
-
-
-Wellington & Gudmundsson    Standards Track                     [Page 1]
-
-RFC 3655               Redefinition of DNS AD bit          November 2003
-
-
-   recursive query can now use the value of the AD bit to determine
-   whether the data is secure.
-
-1.1.  Motivation
-
-   A full DNSSEC capable resolver called directly from an application
-   can return to the application the security status of the RRsets in
-   the answer.  However, most applications use a limited stub resolver
-   that relies on an external recursive name server which incorporates a
-   full resolver.  The recursive nameserver can use the AD bit in a
-   response to indicate the security status of the data in the answer,
-   and the local resolver can pass this information to the application.
-   The application in this context can be either a human using a DNS
-   tool or a software application.
-
-   The AD bit SHOULD be used by the local resolver if and only if it has
-   been explicitly configured to trust the remote resolver.  The AD bit
-   SHOULD be ignored when the recursive name server is not trusted.
-
-   An alternate solution would be to embed a full DNSSEC resolver into
-   every application, but this has several disadvantages.
-
-   -  DNSSEC validation is both CPU and network intensive, and caching
-      SHOULD be used whenever possible.
-
-   -  DNSSEC requires non-trivial configuration - the root key must be
-      configured, as well as keys for any "islands of security" that
-      will exist until DNSSEC is fully deployed.  The number of
-      configuration points should be minimized.
-
-1.2.  Requirements
-
-   The key words "MAY", "MAY NOT" "MUST", "MUST NOT", "SHOULD", "SHOULD
-   NOT", "RECOMMENDED", in this document are to be interpreted as
-   described in BCP 14, RFC 2119 [RFC2119].
-
-1.3.  Updated documents and sections
-
-   The definition of the AD bit in RFC 2535, Section 6.1, is changed.
-
-2.  Setting of AD bit
-
-   The presence of the CD (Checking Disabled) bit in a query does not
-   affect the setting of the AD bit in the response.  If the CD bit is
-   set, the server will not perform checking, but SHOULD still set the
-   AD bit if the data has already been cryptographically verified or
-
-
-
-
-
-Wellington & Gudmundsson    Standards Track                     [Page 2]
-
-RFC 3655               Redefinition of DNS AD bit          November 2003
-
-
-   complies with local policy.  The AD bit MUST only be set if DNSSEC
-   records have been requested via the DO bit [RFC3225] and relevant SIG
-   records are returned.
-
-2.1.  Setting of AD bit by recursive servers
-
-   Section 6.1 of RFC 2535 says:
-
-   "The AD bit MUST NOT be set on a response unless all of the RRs in
-   the answer and authority sections of the response are either
-   Authenticated or Insecure."
-
-   The replacement text reads:
-
-   "The AD bit MUST NOT be set on a response unless all of the RRsets in
-   the answer and authority sections of the response are Authenticated."
-
-   "The AD bit SHOULD be set if and only if all RRs in the answer
-   section and any relevant negative response RRs in the authority
-   section are Authenticated."
-
-   A recursive DNS server following this modified specification will
-   only set the AD bit when it has cryptographically verified the data
-   in the answer.
-
-2.2.  Setting of AD bit by authoritative servers
-
-   A primary server for a secure zone MAY have the policy of treating
-   authoritative secure zones as Authenticated.  Secondary servers MAY
-   have the same policy, but SHOULD NOT consider zone data Authenticated
-   unless the zone was transferred securely and/or the data was
-   verified.  An authoritative server MUST only set the AD bit for
-   authoritative answers from a secure zone if it has been explicitly
-   configured to do so.  The default for this behavior SHOULD be off.
-
-   Note that having the AD bit clear on an authoritative answer is
-   normal and expected behavior.
-
-2.2.1.  Justification for setting AD bit w/o verifying data
-
-   The setting of the AD bit by authoritative servers affects only the
-   small set of resolvers that are configured to directly query and
-   trust authoritative servers.  This only affects servers that function
-   as both recursive and authoritative.  Iterative resolvers SHOULD
-   ignore the AD bit.
-
-   The cost of verifying all signatures on load by an authoritative
-   server can be high and increases the delay before it can begin
-
-
-
-Wellington & Gudmundsson    Standards Track                     [Page 3]
-
-RFC 3655               Redefinition of DNS AD bit          November 2003
-
-
-   answering queries.  Verifying signatures at query time is also
-   expensive and could lead to resolvers timing out on many queries
-   after the server reloads zones.
-
-   Organizations requiring that all DNS responses contain
-   cryptographically verified data will need to separate the
-   authoritative name server and signature verification functions, since
-   name servers are not required to validate signatures of data for
-   which they are authoritative.
-
-3.  Interpretation of the AD bit
-
-   A response containing data marked Insecure in the answer or authority
-   section MUST never have the AD bit set.  In this case, the resolver
-   SHOULD treat the data as Insecure whether or not SIG records are
-   present.
-
-   A resolver MUST NOT blindly trust the AD bit unless it communicates
-   with a recursive nameserver over a secure transport mechanism or
-   using a message authentication such as TSIG [RFC2845] or SIG(0)
-   [RFC2931] and is explicitly configured to trust this recursive name
-   server.
-
-4.  Applicability statement
-
-   The AD bit is intended to allow the transmission of the indication
-   that a resolver has verified the DNSSEC signatures accompanying the
-   records in the Answer and Authority section.  The AD bit MUST only be
-   trusted when the end consumer of the DNS data has confidence that the
-   intermediary resolver setting the AD bit is trustworthy.  This can
-   only be accomplished via an out of band mechanism such as:
-
-   -  Fiat: An organization that can dictate whether it is OK to trust
-      certain DNS servers.
-
-   -  Personal: Because of a personal relationship or the reputation of
-      a recursive nameserver operator, a DNS consumer can decide to
-      trust that recursive nameserver.
-
-   -  Knowledge: If a recursive nameserver operator posts the configured
-      policy of a recursive nameserver, a consumer can decide that
-      recursive nameserver is trustworthy.
-
-   In the absence of one or more of these factors AD bit from a
-   recursive name server SHOULD NOT be trusted.  For example, home users
-   frequently depend on their ISP to provide recursive DNS service; it
-
-
-
-
-
-Wellington & Gudmundsson    Standards Track                     [Page 4]
-
-RFC 3655               Redefinition of DNS AD bit          November 2003
-
-
-   is not advisable to trust these recursive nameservers.  A
-   roaming/traveling host SHOULD not use recursive DNS servers offered
-   by DHCP when looking up information where security status matters.
-
-   In the latter two cases, the end consumer must also completely trust
-   the path to the trusted recursive name servers, or a secure transport
-   must be employed to protect the traffic.
-
-   When faced with a situation where there are no satisfactory recursive
-   nameservers available, running one locally is RECOMMENDED.  This has
-   the advantage that it can be trusted, and the AD bit can still be
-   used to allow applications to use stub resolvers.
-
-5.  Security Considerations
-
-   This document redefines a bit in the DNS header.  If a resolver
-   trusts the value of the AD bit, it must be sure that the responder is
-   using the updated definition, which is any DNS server/resolver
-   supporting the DO bit [RFC3225].
-
-   Authoritative servers can be explicitly configured to set the AD bit
-   on answers without doing cryptographic checks.  This behavior MUST be
-   off by default.  The only affected resolvers are those that directly
-   query and trust the authoritative server, and this functionality
-   SHOULD only be used on servers that act both as authoritative and
-   recursive name servers.
-
-   Resolvers (full or stub) that blindly trust the AD bit without
-   knowing the security policy of the server generating the answer can
-   not be considered security aware.
-
-   A resolver MUST NOT blindly trust the AD bit unless it communicates
-   such as IPsec, or using message authentication such as TSIG [RFC2845]
-   or SIG(0) [RFC2931].  In addition, the resolver must have been
-   explicitly configured to trust this recursive name server.
-
-6.  IANA Considerations
-
-   None.
-
-7.  Internationalization Considerations
-
-   None.  This document does not change any textual data in any
-   protocol.
-
-
-
-
-
-
-
-Wellington & Gudmundsson    Standards Track                     [Page 5]
-
-RFC 3655               Redefinition of DNS AD bit          November 2003
-
-
-8.  Intellectual Property Rights Notice
-
-   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.
-
-9.  Acknowledgments
-
-   The following people have provided input on this document: Robert
-   Elz, Andreas Gustafsson, Bob Halley, Steven Jacob, Erik Nordmark,
-   Edward Lewis, Jakob Schlyter, Roy Arends, Ted Lindgreen.
-
-10.  Normative References
-
-   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
-             Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
-             2535, March 1999.
-
-   [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, 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))", RFC 2931, September 2000.
-
-   [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
-             3225, December 2001.
-
-
-
-Wellington & Gudmundsson    Standards Track                     [Page 6]
-
-RFC 3655               Redefinition of DNS AD bit          November 2003
-
-
-11.  Authors' Addresses
-
-   Brian Wellington
-   Nominum Inc.
-   2385 Bay Road
-   Redwood City, CA, 94063
-   USA
-
-   EMail: Brian.Wellington@nominum.com
-
-
-   Olafur Gudmundsson
-   3821 Village Park Drive
-   Chevy Chase, MD, 20815
-   USA
-
-   EMail: ogud@ogud.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wellington & Gudmundsson    Standards Track                     [Page 7]
-
-RFC 3655               Redefinition of DNS AD bit          November 2003
-
-
-12.  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 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
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wellington & Gudmundsson    Standards Track                     [Page 8]
-
diff --git a/contrib/bind9/doc/rfc/rfc3658.txt b/contrib/bind9/doc/rfc/rfc3658.txt
deleted file mode 100644
index 88cfb5a..0000000
--- a/contrib/bind9/doc/rfc/rfc3658.txt
+++ /dev/null
@@ -1,1067 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                     O. Gudmundsson
-Request for Comments: 3658                                 December 2003
-Updates: 3090, 3008, 2535, 1035
-Category: Standards Track
-
-
-              Delegation Signer (DS) Resource Record (RR)
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-Abstract
-
-   The delegation signer (DS) resource record (RR) is inserted at a zone
-   cut (i.e., a delegation point) to indicate that the delegated zone is
-   digitally signed and that the delegated zone recognizes the indicated
-   key as a valid zone key for the delegated zone.  The DS RR is a
-   modification to the DNS Security Extensions definition, motivated by
-   operational considerations.  The intent is to use this resource
-   record as an explicit statement about the delegation, rather than
-   relying on inference.
-
-   This document defines the DS RR, gives examples of how it is used and
-   describes the implications on resolvers.  This change is not
-   backwards compatible with RFC 2535.  This document updates RFC 1035,
-   RFC 2535, RFC 3008 and RFC 3090.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 1]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-Table of Contents
-
-   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   3
-       1.2.  Reserved Words. . . . . . . . . . . . . . . . . . . . .   4
-   2.  Specification of the Delegation key Signer. . . . . . . . . .   4
-       2.1.  Delegation Signer Record Model. . . . . . . . . . . . .   4
-       2.2.  Protocol Change . . . . . . . . . . . . . . . . . . . .   5
-             2.2.1.  RFC 2535 2.3.4 and 3.4: Special Considerations
-                     at Delegation Points  . . . . . . . . . . . . .   6
-                     2.2.1.1. Special processing for DS queries. . .   6
-                     2.2.1.2. Special processing when child and an
-                              ancestor share nameserver. . . . . . .   7
-                     2.2.1.3. Modification on use of KEY RR in the
-                              construction of Responses. . . . . . .   8
-             2.2.2.  Signer's Name (replaces RFC3008 section 2.7). .   9
-             2.2.3.  Changes to RFC 3090 . . . . . . . . . . . . . .   9
-                     2.2.3.1. RFC 3090: Updates to section 1:
-                              Introduction . . . . . . . . . . . . .   9
-                     2.2.3.2. RFC 3090 section 2.1: Globally
-                              Secured. . . . . . . . . . . . . . . .  10
-                     2.2.3.3. RFC 3090 section 3: Experimental
-                              Status . . . . . . . . . . . . . . . .  10
-             2.2.4.  NULL KEY elimination. . . . . . . . . . . . . .  10
-       2.3.  Comments on Protocol Changes. . . . . . . . . . . . . .  10
-       2.4.  Wire Format of the DS record. . . . . . . . . . . . . .  11
-             2.4.1.  Justifications for Fields . . . . . . . . . . .  12
-       2.5.  Presentation Format of the DS Record. . . . . . . . . .  12
-       2.6.  Transition Issues for Installed Base. . . . . . . . . .  12
-             2.6.1.  Backwards compatibility with RFC 2535 and
-                     RFC 1035. . . . . . . . . . . . . . . . . . . .  12
-       2.7.  KEY and corresponding DS record example . . . . . . . .  13
-   3.  Resolver. . . . . . . . . . . . . . . . . . . . . . . . . . .  14
-       3.1.  DS Example" . . . . . . . . . . . . . . . . . . . . . .  14
-       3.2.  Resolver Cost Estimates for DS Records" . . . . . . . .  15
-   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
-   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
-   6.  Intellectual Property Statement . . . . . . . . . . . . . . .  16
-   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  17
-   8.  References. . . . . . . . . . . . . . . . . . . . . . . . . .  17
-       8.1.  Normative References. . . . . . . . . . . . . . . . . .  17
-       8.2.  Informational References. . . . . . . . . . . . . . . .  17
-   9.  Author's Address. . . . . . . . . . . . . . . . . . . . . . .  18
-   10. Full Copyright Statement. . . . . . . . . . . . . . . . . . .  19
-
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 2]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-1.  Introduction
-
-   Familiarity with the DNS system [RFC1035], DNS security extensions
-   [RFC2535], and DNSSEC terminology [RFC3090] is important.
-
-   Experience shows that when the same data can reside in two
-   administratively different DNS zones, the data frequently gets out of
-   sync.  The presence of an NS RRset in a zone anywhere other than at
-   the apex indicates a zone cut or delegation.  The RDATA of the NS
-   RRset specifies the authoritative nameservers for the delegated or
-   "child" zone.  Based on actual measurements, 10-30% of all
-   delegations on the Internet have differing NS RRsets at parent and
-   child.  There are a number of reasons for this, including a lack of
-   communication between parent and child and bogus name servers being
-   listed to meet registry requirements.
-
-   DNSSEC [RFC2535, RFC3008, RFC3090] specifies that a child zone needs
-   to have its KEY RRset signed by its parent to create a verifiable
-   chain of KEYs.  There has been some debate on where the signed KEY
-   RRset should reside, whether at the child [RFC2535] or at the parent.
-   If the KEY RRset resides at the child, maintaining the signed KEY
-   RRset in the child requires frequent two-way communication between
-   the two parties.  First, the child transmits the KEY RRset to the
-   parent and then the parent sends the signature(s) to the child.
-   Storing the KEY RRset at the parent was thought to simplify the
-   communication.
-
-   DNSSEC [RFC2535] requires that the parent store a NULL KEY record for
-   an unsecure child zone to indicate that the child is unsecure.  A
-   NULL KEY record is a waste: an entire signed RRset is used to
-   communicate effectively one bit of information - that the child is
-   unsecure. Chasing down NULL KEY RRsets complicates the resolution
-   process in many cases, because nameservers for both parent and child
-   need to be queried for the KEY RRset if the child nameserver does not
-   return it.  Storing the KEY RRset only in the parent zone simplifies
-   this and would allow the elimination of the NULL KEY RRsets entirely.
-   For large delegation zones, the cost of NULL keys is a significant
-   barrier to deployment.
-
-   Prior to the restrictions imposed by RFC 3445 [RFC3445], another
-   implication of the DNSSEC key model is that the KEY record could be
-   used to store public keys for other protocols in addition to DNSSEC
-   keys.  There are a number of potential problems with this, including:
-
-   1. The KEY RRset can become quite large if many applications and
-      protocols store their keys at the zone apex.  Possible protocols
-      are IPSEC, HTTP, SMTP, SSH and others that use public key
-      cryptography.
-
-
-
-Gudmundsson                 Standards Track                     [Page 3]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-   2. The KEY RRset may require frequent updates.
-
-   3. The probability of compromised or lost keys, which trigger
-      emergency key roll-over procedures, increases.
-
-   4. The parent may refuse to sign KEY RRsets with non-DNSSEC zone
-      keys.
-
-   5. The parent may not meet the child's expectations of turnaround
-      time for resigning the KEY RRset.
-
-   Given these reasons, SIG@parent isn't any better than SIG/KEY@Child.
-
-1.2.  Reserved Words
-
-   The key words "MAY", "MAY NOT", "MUST", "MUST NOT", "REQUIRED",
-   "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
-   interpreted as described in BCP 14, RFC 2119 [RFC2119].
-
-2.  Specification of the Delegation key Signer
-
-   This section defines the Delegation Signer (DS) RR type (type code
-   43) and the changes to DNS to accommodate it.
-
-2.1.  Delegation Signer Record Model
-
-   This document presents a replacement for the DNSSEC KEY record chain
-   of trust [RFC2535] that uses a new RR that resides only at the
-   parent.  This record identifies the key(s) that the child uses to
-   self-sign its own KEY RRset.
-
-   Even though DS identifies two roles for KEYs, Key Signing Key (KSK)
-   and Zone Signing Key (ZSK), there is no requirement that zone uses
-   two different keys for these roles.  It is expected that many small
-   zones will only use one key, while larger zones will be more likely
-   to use multiple keys.
-
-   The chain of trust is now established by verifying the parent KEY
-   RRset, the DS RRset from the parent and the KEY RRset at the child.
-   This is cryptographically equivalent to using just KEY records.
-
-   Communication between the parent and child is greatly reduced, since
-   the child only needs to notify the parent about changes in keys that
-   sign its apex KEY RRset.  The parent is ignorant of all other keys in
-   the child's apex KEY RRset.  Furthermore, the child maintains full
-   control over the apex KEY RRset and its content.  The child can
-   maintain any policies regarding its KEY usage for DNSSEC with minimal
-   impact on the parent.  Thus, if the child wants to have frequent key
-
-
-
-Gudmundsson                 Standards Track                     [Page 4]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-   roll-over for its DNS zone keys, the parent does not need to be aware
-   of it.  The child can use one key to sign only its apex KEY RRset and
-   a different key to sign the other RRsets in the zone.
-
-   This model fits well with a slow roll out of DNSSEC and the islands
-   of security model.  In this model, someone who trusts "good.example."
-   can preconfigure a key from "good.example." as a trusted key, and
-   from then on trusts any data signed by that key or that has a chain
-   of trust to that key.  If "example." starts advertising DS records,
-   "good.example." does not have to change operations by suspending
-   self-signing.  DS records can be used in configuration files to
-   identify trusted keys instead of KEY records.  Another significant
-   advantage is that the amount of information stored in large
-   delegation zones is reduced: rather than the NULL KEY record at every
-   unsecure delegation demanded by RFC 2535, only secure delegations
-   require additional information in the form of a signed DS RRset.
-
-   The main disadvantage of this approach is that verifying a zone's KEY
-   RRset requires two signature verification operations instead of the
-   one in RFC 2535 chain of trust.  There is no impact on the number of
-   signatures verified for other types of RRsets.
-
-2.2.  Protocol Change
-
-   All DNS servers and resolvers that support DS MUST support the OK bit
-   [RFC3225] and a larger message size [RFC3226].  In order for a
-   delegation to be considered secure the delegation MUST contain a DS
-   RRset.  If a query contains the OK bit, a nameserver returning a
-   referral for the delegation MUST include the following RRsets in the
-   authority section in this order:
-
-   If DS RRset is present:
-      parent's copy of child's NS RRset
-      DS and SIG(DS)
-
-   If no DS RRset is present:
-      parent's copy of child's NS RRset
-      parent's zone NXT and SIG(NXT)
-
-   This increases the size of referral messages, possibly causing some
-   or all glue to be omitted.  If the DS or NXT RRsets with signatures
-   do not fit in the DNS message, the TC bit MUST be set.  Additional
-   section processing is not changed.
-
-   A DS RRset accompanying a NS RRset indicates that the child zone is
-   secure.  If a NS RRset exists without a DS RRset, the child zone is
-   unsecure (from the parents point of view).  DS RRsets MUST NOT appear
-   at non-delegation points or at a zone's apex.
-
-
-
-Gudmundsson                 Standards Track                     [Page 5]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-   Section 2.2.1 defines special considerations related to authoritative
-   nameservers responding to DS queries and replaces RFC 2535 sections
-   2.3.4 and 3.4.  Section 2.2.2 replaces RFC 3008 section 2.7, and
-   section 2.2.3 updates RFC 3090.
-
-2.2.1.  RFC 2535 2.3.4 and 3.4: Special Considerations at Delegation
-        Points
-
-   DNS security views each zone as a unit of data completely under the
-   control of the zone owner with each entry (RRset) signed by a special
-   private key held by the zone manager.  But the DNS protocol views the
-   leaf nodes in a zone that are also the apex nodes of a child zone
-   (i.e., delegation points) as "really" belonging to the child zone.
-   The corresponding domain names appear in two master files and might
-   have RRsets signed by both the parent and child zones' keys.  A
-   retrieval could get a mixture of these RRsets and SIGs, especially
-   since one nameserver could be serving both the zone above and below a
-   delegation point [RFC2181].
-
-   Each DS RRset stored in the parent zone MUST be signed by at least
-   one of the parent zone's private keys.  The parent zone MUST NOT
-   contain a KEY RRset at any delegation point.  Delegations in the
-   parent MAY contain only the following RR types: NS, DS, NXT and SIG.
-   The NS RRset MUST NOT be signed.  The NXT RRset is the exceptional
-   case: it will always appear differently and authoritatively in both
-   the parent and child zones, if both are secure.
-
-   A secure zone MUST contain a self-signed KEY RRset at its apex.  Upon
-   verifying the DS RRset from the parent, a resolver MAY trust any KEY
-   identified in the DS RRset as a valid signer of the child's apex KEY
-   RRset.  Resolvers configured to trust one of the keys signing the KEY
-   RRset MAY now treat any data signed by the zone keys in the KEY RRset
-   as secure.  In all other cases, resolvers MUST consider the zone
-   unsecure.
-
-   An authoritative nameserver queried for type DS MUST return the DS
-   RRset in the answer section.
-
-2.2.1.1.  Special processing for DS queries
-
-   When a nameserver is authoritative for the parent zone at a
-   delegation point and receives a query for the DS record at that name,
-   it MUST answer based on data in the parent zone, return DS or
-   negative answer.  This is true whether or not it is also
-   authoritative for the child zone.
-
-
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 6]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-   When the nameserver is authoritative for the child zone at a
-   delegation point but not the parent zone, there is no natural
-   response, since the child zone is not authoritative for the DS record
-   at the zone's apex.  As these queries are only expected to originate
-   from recursive nameservers which are not DS-aware, the authoritative
-   nameserver MUST answer with:
-
-      RCODE:             NOERROR
-      AA bit:            set
-      Answer Section:    Empty
-      Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]
-
-   That is, it answers as if it is authoritative and the DS record does
-   not exist.  DS-aware recursive nameservers will query the parent zone
-   at delegation points, so will not be affected by this.
-
-   A nameserver authoritative for only the child zone, that is also a
-   caching server MAY (if the RD bit is set in the query) perform
-   recursion to find the DS record at the delegation point, or MAY
-   return the DS record from its cache.  In this case, the AA bit MUST
-   NOT be set in the response.
-
-2.2.1.2.  Special processing when child and an ancestor share
-          nameserver
-
-   Special rules are needed to permit DS RR aware nameservers to
-   gracefully interact with older caches which otherwise might falsely
-   label a nameserver as lame because of the placement of the DS RR set.
-
-   Such a situation might arise when a nameserver is authoritative for
-   both a zone and it's grandparent, but not the parent.  This sounds
-   like an obscure example, but it is very real.  The root zone is
-   currently served on 13 machines, and "root-servers.net." is served on
-   4 of the 13, but "net." is severed on different nameservers.
-
-   When a nameserver receives a query for (<QNAME>, DS, <QCLASS>), the
-   response MUST be determined from reading these rules in order:
-
-   1) If the nameserver is authoritative for the zone that holds the DS
-      RR set (i.e., the zone that delegates <QNAME>, a.k.a. the "parent"
-      zone), the response contains the DS RR set as an authoritative
-      answer.
-
-   2) If the nameserver is offering recursive service and the RD bit is
-      set in the query, the nameserver performs the query itself
-      (according to the rules for resolvers described below) and returns
-      its findings.
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 7]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-   3) If the nameserver is authoritative for the zone that holds the
-      <QNAME>'s SOA RR set, the response is an authoritative negative
-      answer as described in 2.2.1.1.
-
-   4) If the nameserver is authoritative for a zone or zones above the
-      QNAME, a referral to the most enclosing (deepest match) zone's
-      servers is made.
-
-   5) If the nameserver is not authoritative for any part of the QNAME,
-      a response indicating a lame nameserver for QNAME is given.
-
-   Using these rules will require some special processing on the part of
-   a DS RR aware resolver.  To illustrate this, an example is used.
-
-   Assuming a nameserver is authoritative for roots.example.net. and for
-   the root zone but not the intervening two zones (or the intervening
-   two label deep zone).  Assume that QNAME=roots.example.net.,
-   QTYPE=DS, and QCLASS=IN.
-
-   The resolver will issue this request (assuming no cached data)
-   expecting a referral to a nameserver for .net.  Instead, rule number
-   3 above applies and a negative answer is returned by the nameserver.
-   The reaction by the resolver is not to accept this answer as final,
-   as it can determine from the SOA RR in the negative answer the
-   context within which the nameserver has answered.
-
-   A solution would be to instruct the resolver to hunt for the
-   authoritative zone of the data in a brute force manner.
-
-   This can be accomplished by taking the owner name of the returned SOA
-   RR and striping off enough left-hand labels until a successful NS
-   response is obtained.  A successful response here means that the
-   answer has NS records in it.  (Entertaining the possibility that a
-   cut point can be two labels down in a zone.)
-
-   Returning to the example, the response will include a negative answer
-   with either the SOA RR for "roots.example.net." or "example.net."
-   depending on whether roots.example.net is a delegated domain.  In
-   either case, removing the left most label of the SOA owner name will
-   lead to the location of the desired data.
-
-2.2.1.3.  Modification on use of KEY RR in the construction of Responses
-
-   This section updates RFC 2535 section 3.5 by replacing it with the
-   following:
-
-
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 8]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-   A query for KEY RR MUST NOT trigger any additional section
-   processing.  Security aware resolvers will include corresponding SIG
-   records in the answer section.
-
-   KEY records SHOULD NOT be added to the additional records section in
-   response to any query.
-
-   RFC 2535 specified that KEY records be added to the additional
-   section when SOA or NS records were included in an answer.  This was
-   done to reduce round trips (in the case of SOA) and to force out NULL
-   KEYs (in the NS case).  As this document obsoletes NULL keys, there
-   is no need for the inclusion of KEYs with NSs.  Furthermore, as SOAs
-   are included in the authority section of negative answers, including
-   the KEYs each time will cause redundant transfers of KEYs.
-
-   RFC 2535 section 3.5 also included a rule for adding the KEY RRset to
-   the response for a query for A and AAAA types.  As Restrict KEY
-   [RFC3445] eliminated use of KEY RR by all applications, this rule is
-   no longer needed.
-
-2.2.2.  Signer's Name (replaces RFC 3008 section 2.7)
-
-   The signer's name field of a SIG RR MUST contain the name of the zone
-   to which the data and signature belong.  The combination of signer's
-   name, key tag, and algorithm MUST identify a zone key if the SIG is
-   to be considered material.  This document defines a standard policy
-   for DNSSEC validation; local policy MAY override the standard policy.
-
-   There are no restrictions on the signer field of a SIG(0) record. The
-   combination of signer's name, key tag, and algorithm MUST identify a
-   key if this SIG(0) is to be processed.
-
-2.2.3.  Changes to RFC 3090
-
-   A number of sections in RFC 3090 need to be updated to reflect the DS
-   record.
-
-2.2.3.1.  RFC 3090: Updates to section 1: Introduction
-
-   Most of the text is still relevant but the words "NULL key" are to be
-   replaced with "missing DS RRset".  In section 1.3, the last three
-   paragraphs discuss the confusion in sections of RFC 2535 that are
-   replaced in section 2.2.1 above.  Therefore, these paragraphs are now
-   obsolete.
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                     [Page 9]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-2.2.3.2.  RFC 3090 section 2.1: Globally Secured
-
-   Rule 2.1.b is replaced by the following rule:
-
-   2.1.b. The KEY RRset at a zone's apex MUST be self-signed by a
-   private key whose public counterpart MUST appear in a zone signing
-   KEY RR (2.a) owned by the zone's apex and specifying a mandatory-to-
-   implement algorithm.  This KEY RR MUST be identified by a DS RR in a
-   signed DS RRset in the parent zone.
-
-   If a zone cannot get its parent to advertise a DS record for it, the
-   child zone cannot be considered globally secured.  The only exception
-   to this is the root zone, for which there is no parent zone.
-
-2.2.3.3.  RFC 3090 section 3: Experimental Status.
-
-   The only difference between experimental status and globally secured
-   is the missing DS RRset in the parent zone.  All locally secured
-   zones are experimental.
-
-2.2.4.  NULL KEY elimination
-
-   RFC 3445 section 3 eliminates the top two bits in the flags field of
-   KEY RR.  These two bits were used to indicate NULL KEY or NO KEY. RFC
-   3090 defines that zone as either secure or not and these rules
-   eliminate the need to put NULL keys in the zone apex to indicate that
-   the zone is not secured for a algorithm.  Along with this document,
-   these other two eliminate all uses for the NULL KEY.  This document
-   obsoletes NULL KEY.
-
-2.3.  Comments on Protocol Changes
-
-   Over the years, there have been various discussions surrounding the
-   DNS delegation model, declaring it to be broken because there is no
-   good way to assert if a delegation exists.  In the RFC 2535 version
-   of DNSSEC, the presence of the NS bit in the NXT bit map proves there
-   is a delegation at this name.  Something more explicit is required
-   and the DS record addresses this need for secure delegations.
-
-   The DS record is a major change to DNS: it is the first resource
-   record that can appear only on the upper side of a delegation.
-   Adding it will cause interoperability problems and requires a flag
-   day for DNSSEC.  Many old nameservers and resolvers MUST be upgraded
-   to take advantage of DS.  Some old nameservers will be able to be
-   authoritative for zones with DS records but will not add the NXT or
-   DS records to the authority section.  The same is true for caching
-   nameservers; in fact, some might even refuse to pass on the DS or NXT
-   records.
-
-
-
-Gudmundsson                 Standards Track                    [Page 10]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-2.4.  Wire Format of the DS record
-
-   The DS (type=43) record contains these fields: key tag, algorithm,
-   digest type, and the digest of a public key KEY record that is
-   allowed and/or used to sign the child's apex KEY RRset.  Other keys
-   MAY sign the child's apex KEY RRset.
-
-                        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  (length depends on type)               |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                (SHA-1 digest is 20 bytes)                     |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                                                               |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-   |                                                               |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-   |                                                               |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   The key tag is calculated as specified in RFC 2535.  Algorithm MUST
-   be allowed to sign DNS data.  The digest type is an identifier for
-   the digest algorithm used.  The digest is calculated over the
-   canonical name of the delegated domain name followed by the whole
-   RDATA of the KEY record (all four fields).
-
-      digest = hash( canonical FQDN on KEY RR | KEY_RR_rdata)
-
-      KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key
-
-   Digest type value 0 is reserved, value 1 is SHA-1, and reserving
-   other types requires IETF standards action.  For interoperability
-   reasons, keeping number of digest algorithms low is strongly
-   RECOMMENDED.  The only reason to reserve additional digest types is
-   to increase security.
-
-   DS records MUST point to zone KEY records that are allowed to
-   authenticate DNS data.  The indicated KEY records protocol field MUST
-   be set to 3; flag field bit 7 MUST be set to 1.  The value of other
-   flag bits is not significant for the purposes of this document.
-
-   The size of the DS RDATA for type 1 (SHA-1) is 24 bytes, regardless
-   of key size.  New digest types probably will have larger digests.
-
-
-
-
-
-Gudmundsson                 Standards Track                    [Page 11]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-2.4.1.  Justifications for Fields
-
-   The algorithm and key tag fields are present to allow resolvers to
-   quickly identify the candidate KEY records to examine.  SHA-1 is a
-   strong cryptographic checksum: it is computationally infeasible for
-   an attacker to generate a KEY record that has the same SHA-1 digest.
-   Combining the name of the key and the key rdata as input to the
-   digest provides stronger assurance of the binding.  Having the key
-   tag in the DS record adds greater assurance than the SHA-1 digest
-   alone, as there are now two different mapping functions.
-
-   This format allows concise representation of the keys that the child
-   will use, thus keeping down the size of the answer for the
-   delegation, reducing the probability of DNS message overflow.  The
-   SHA-1 hash is strong enough to uniquely identify the key and is
-   similar to the PGP key footprint.  The digest type field is present
-   for possible future expansion.
-
-   The DS record is well suited to listing trusted keys for islands of
-   security in configuration files.
-
-2.5.  Presentation Format of the DS Record
-
-   The presentation format of the DS record consists of three numbers
-   (key tag, algorithm, and digest type) followed by the digest itself
-   presented in hex:
-
-      example.   DS  12345 3 1 123456789abcdef67890123456789abcdef67890
-
-2.6.  Transition Issues for Installed Base
-
-   No backwards compatibility with RFC 2535 is provided.
-
-   RFC 2535-compliant resolvers will assume that all DS-secured
-   delegations are locally secure.  This is bad, but the DNSEXT Working
-   Group has determined that rather than dealing with both RFC 2535-
-   secured zones and DS-secured zones, a rapid adoption of DS is
-   preferable.  Thus, the only option for early adopters is to upgrade
-   to DS as soon as possible.
-
-2.6.1.  Backwards compatibility with RFC 2535 and RFC 1035
-
-   This section documents how a resolver determines the type of
-   delegation.
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                    [Page 12]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-   RFC 1035 delegation (in parent) has:
-
-   RFC 1035           NS
-
-   RFC 2535 adds the following two cases:
-
-   Secure RFC 2535:   NS + NXT + SIG(NXT)
-                      NXT bit map contains: NS SIG NXT
-   Unsecure RFC 2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT)
-                      NXT bit map contains: NS SIG KEY NXT
-                      KEY must be a NULL key.
-
-   DNSSEC with DS has the following two states:
-
-   Secure DS:         NS + DS + SIG(DS)
-                      NXT bit map contains: NS SIG NXT DS
-   Unsecure DS:       NS + NXT + SIG(NXT)
-                      NXT bit map contains: NS SIG NXT
-
-   It is difficult for a resolver to determine if a delegation is secure
-   RFC 2535 or unsecure DS.  This could be overcome by adding a flag to
-   the NXT bit map, but only upgraded resolvers would understand this
-   flag, anyway.  Having both parent and child signatures for a KEY
-   RRset might allow old resolvers to accept a zone as secure, but the
-   cost of doing this for a long time is much higher than just
-   prohibiting RFC 2535-style signatures at child zone apexes and
-   forcing rapid deployment of DS-enabled nameservers and resolvers.
-
-   RFC 2535 and DS can, in theory, be deployed in parallel, but this
-   would require resolvers to deal with RFC 2535 configurations forever.
-   This document obsoletes the NULL KEY in parent zones, which is a
-   difficult enough change that to cause a flag day.
-
-2.7.  KEY and corresponding DS record example
-
-   This is an example of a KEY record and the corresponding DS record.
-
-   dskey.example. KEY  256 3 1 (
-                  AQPwHb4UL1U9RHaU8qP+Ts5bVOU1s7fYbj2b3CCbzNdj
-                  4+/ECd18yKiyUQqKqQFWW5T3iVc8SJOKnueJHt/Jb/wt
-                  ) ; key id = 28668
-             DS   28668 1  1  49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE
-
-
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                    [Page 13]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-3.  Resolver
-
-3.1.  DS Example
-
-   To create a chain of trust, a resolver goes from trusted KEY to DS to
-   KEY.
-
-      Assume the key for domain "example." is trusted.  Zone "example."
-      contains at least the following records:
-      example.          SOA     <soa stuff>
-      example.          NS       ns.example.
-      example.          KEY     <stuff>
-      example.          NXT      secure.example. NS SOA KEY SIG NXT
-      example.          SIG(SOA)
-      example.          SIG(NS)
-      example.          SIG(NXT)
-      example.          SIG(KEY)
-      secure.example.   NS      ns1.secure.example.
-      secure.example.   DS      tag=12345 alg=3 digest_type=1 <foofoo>
-      secure.example.   NXT     unsecure.example. NS SIG NXT DS
-      secure.example.   SIG(NXT)
-      secure.example.   SIG(DS)
-      unsecure.example  NS      ns1.unsecure.example.
-      unsecure.example. NXT     example. NS SIG NXT
-      unsecure.example. SIG(NXT)
-
-      In zone "secure.example." following records exist:
-      secure.example.   SOA      <soa stuff>
-      secure.example.   NS       ns1.secure.example.
-      secure.example.   KEY      <tag=12345 alg=3>
-      secure.example.   KEY      <tag=54321 alg=5>
-      secure.example.   NXT      <nxt stuff>
-      secure.example.   SIG(KEY) <key-tag=12345 alg=3>
-      secure.example.   SIG(SOA) <key-tag=54321 alg=5>
-      secure.example.   SIG(NS)  <key-tag=54321 alg=5>
-      secure.example.   SIG(NXT) <key-tag=54321 alg=5>
-
-   In this example, the private key for "example." signs the DS record
-   for "secure.example.", making that a secure delegation.  The DS
-   record states which key is expected to sign the KEY RRset at
-   "secure.example.".  Here "secure.example." signs its KEY RRset with
-   the KEY identified in the DS RRset, thus the KEY RRset is validated
-   and trusted.
-
-   This example has only one DS record for the child, but parents MUST
-   allow multiple DS records to facilitate key roll-over and multiple
-   KEY algorithms.
-
-
-
-
-Gudmundsson                 Standards Track                    [Page 14]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-   The resolver determines the security status of "unsecure.example." by
-   examining the parent zone's NXT record for this name.  The absence of
-   the DS bit indicates an unsecure delegation.  Note the NXT record
-   SHOULD only be examined after verifying the corresponding signature.
-
-3.2.  Resolver Cost Estimates for DS Records
-
-   From a RFC 2535 recursive resolver point of view, for each delegation
-   followed to chase down an answer, one KEY RRset has to be verified.
-   Additional RRsets might also need to be verified based on local
-   policy (e.g., the contents of the NS RRset).  Once the resolver gets
-   to the appropriate delegation, validating the answer might require
-   verifying one or more signatures.  A simple A record lookup requires
-   at least N delegations to be verified and one RRset.  For a DS-
-   enabled recursive resolver, the cost is 2N+1.  For an MX record,
-   where the target of the MX record is in the same zone as the MX
-   record, the costs are N+2 and 2N+2, for RFC 2535 and DS,
-   respectively.  In the case of a negative answer, the same ratios hold
-   true.
-
-   The recursive resolver has to do an extra query to get the DS record,
-   which will increase the overall cost of resolving this question, but
-   it will never be worse than chasing down NULL KEY records from the
-   parent in RFC 2535 DNSSEC.
-
-   DS adds processing overhead on resolvers and increases the size of
-   delegation answers, but much less than storing signatures in the
-   parent zone.
-
-4.  Security Considerations
-
-   This document proposes a change to the validation chain of KEY
-   records in DNSSEC.  The change is not believed to reduce security in
-   the overall system.  In RFC 2535 DNSSEC, the child zone has to
-   communicate keys to its parent and prudent parents will require some
-   authentication with that transaction.  The modified protocol will
-   require the same authentication, but allows the child to exert more
-   local control over its own KEY RRset.
-
-   There is a remote possibility that an attacker could generate a valid
-   KEY that matches all the DS fields, of a specific DS set, and thus
-   forge data from the child.  This possibility is considered
-   impractical, as on average more than
-
-      2 ^ (160 - <Number of keys in DS set>)
-
-   keys would have to be generated before a match would be found.
-
-
-
-
-Gudmundsson                 Standards Track                    [Page 15]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-   An attacker that wants to match any DS record will have to generate
-   on average at least 2^80 keys.
-
-   The DS record represents a change to the DNSSEC protocol and there is
-   an installed base of implementations, as well as textbooks on how to
-   set up secure delegations.  Implementations that do not understand
-   the DS record will not be able to follow the KEY to DS to KEY chain
-   and will consider all zones secured that way as unsecure.
-
-5.  IANA Considerations
-
-   IANA has allocated an RR type code for DS from the standard RR type
-   space (type 43).
-
-   IANA has established a new registry for the DS RR type for digest
-   algorithms.  Defined types are:
-
-      0 is Reserved,
-      1 is SHA-1.
-
-   Adding new reservations requires IETF standards action.
-
-6.  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.
-
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                    [Page 16]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-7.  Acknowledgments
-
-   Over the last few years a number of people have contributed ideas
-   that are captured in this document.  The core idea of using one key
-   to sign only the KEY RRset comes from discussions with Bill Manning
-   and Perry Metzger on how to put in a single root key in all
-   resolvers. Alexis Yushin, Brian Wellington, Sam Weiler, Paul Vixie,
-   Jakob Schlyter, Scott Rose, Edward Lewis, Lars-Johan Liman, Matt
-   Larson, Mark Kosters, Dan Massey, Olaf Kolman, Phillip Hallam-Baker,
-   Miek Gieben, Havard Eidnes, Donald Eastlake 3rd., Randy Bush, David
-   Blacka, Steve Bellovin, Rob Austein, Derek Atkins, Roy Arends, Mark
-   Andrews, Harald Alvestrand, and others have provided useful comments.
-
-8.  References
-
-8.1.  Normative References
-
-   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
-              Specification", STD 13, RFC 1035, November 1987.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
-              RFC 2535, March 1999.
-
-   [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.
-
-   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
-              3225, December 2001.
-
-   [RFC3445]  Massey, D. and S. Rose, "Limiting the scope of the KEY
-              Resource Record (RR)", RFC 3445, December 2002.
-
-8.2.  Informational References
-
-   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
-              Specification", RFC 2181, July 1997.
-
-   [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
-              message size requirements", RFC 3226, December 2001.
-
-
-
-
-
-
-Gudmundsson                 Standards Track                    [Page 17]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-9.  Author's Address
-
-   Olafur Gudmundsson
-   3821 Village Park Drive
-   Chevy Chase, MD,  20815
-
-   EMail: ds-rfc@ogud.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                    [Page 18]
-
-RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
-
-
-10.  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 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
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gudmundsson                 Standards Track                    [Page 19]
-
diff --git a/contrib/bind9/doc/rfc/rfc3757.txt b/contrib/bind9/doc/rfc/rfc3757.txt
deleted file mode 100644
index 31890a4..0000000
--- a/contrib/bind9/doc/rfc/rfc3757.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         O. Kolkman
-Request for Comments: 3757                                      RIPE NCC
-Updates: 3755, 2535                                          J. Schlyter
-Category: Standards Track                                         NIC-SE
-                                                                E. Lewis
-                                                                    ARIN
-                                                              April 2004
-
-
-         Domain Name System KEY (DNSKEY) Resource Record (RR)
-                     Secure Entry Point (SEP) Flag
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).  All Rights Reserved.
-
-Abstract
-
-   With the Delegation Signer (DS) resource record (RR), the concept of
-   a public key acting as a secure entry point (SEP) has been
-   introduced.  During exchanges of public keys with the parent there is
-   a need to differentiate SEP keys from other public keys in the Domain
-   Name System KEY (DNSKEY) resource record set.  A flag bit in the
-   DNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP.
-   The flag bit is intended to assist in operational procedures to
-   correctly generate DS resource records, or to indicate what DNSKEYs
-   are intended for static configuration.  The flag bit is not to be
-   used in the DNS verification protocol.  This document updates RFC
-   2535 and RFC 3755.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al.              Standard Track                     [Page 1]
-
-RFC 3757                   DNSKEY RR SEP Flag                 April 2004
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
-   2.  The Secure Entry Point (SEP) Flag. . . . . . . . . . . . . . .  4
-   3.  DNSSEC Protocol Changes. . . . . . . . . . . . . . . . . . . .  4
-   4.  Operational Guidelines . . . . . . . . . . . . . . . . . . . .  4
-   5.  Security Considerations. . . . . . . . . . . . . . . . . . . .  5
-   6.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  6
-   7.  Internationalization Considerations. . . . . . . . . . . . . .  6
-   8.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .  6
-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
-       9.1.  Normative References . . . . . . . . . . . . . . . . . .  6
-       9.2.  Informative References . . . . . . . . . . . . . . . . .  6
-   10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  7
-   11. Full Copyright Statement . . . . . . . . . . . . . . . . . . .  8
-
-1.  Introduction
-
-   "All keys are equal but some keys are more equal than others" [6].
-
-   With the definition of the Delegation Signer Resource Record (DS RR)
-   [5], it has become important to differentiate between the keys in the
-   DNSKEY RR set that are (to be) pointed to by parental DS RRs and the
-   other keys in the DNSKEY RR set.  We refer to these public keys as
-   Secure Entry Point (SEP) keys.  A SEP key either used to generate a
-   DS RR or is distributed to resolvers that use the key as the root of
-   a trusted subtree [3].
-
-   In early deployment tests, the use of two (kinds of) key pairs for
-   each zone has been prevalent.  For one kind of key pair the private
-   key is used to sign just the zone's DNSKEY resource record (RR) set.
-   Its public key is intended to be referenced by a DS RR at the parent
-   or configured statically in a resolver.  The private key of the other
-   kind of key pair is used to sign the rest of the zone's data sets.
-   The former key pair is called a key-signing key (KSK) and the latter
-   is called a zone-signing key (ZSK).  In practice there have been
-   usually one of each kind of key pair, but there will be multiples of
-   each at times.
-
-   It should be noted that division of keys pairs into KSK's and ZSK's
-   is not mandatory in any definition of DNSSEC, not even with the
-   introduction of the DS RR.  But, in testing, this distinction has
-   been helpful when designing key roll over (key super-cession)
-   schemes.  Given that the distinction has proven helpful, the labels
-   KSK and ZSK have begun to stick.
-
-
-
-
-
-
-Kolkman, et al.              Standard Track                     [Page 2]
-
-RFC 3757                   DNSKEY RR SEP Flag                 April 2004
-
-
-   There is a need to differentiate the public keys for the key pairs
-   that are used for key signing from keys that are not used key signing
-   (KSKs vs ZSKs).  This need is driven by knowing which DNSKEYs are to
-   be sent for generating DS RRs, which DNSKEYs are to be distributed to
-   resolvers, and which keys are fed to the signer application at the
-   appropriate time.
-
-   In other words, the SEP bit provides an in-band method to communicate
-   a DNSKEY RR's intended use to third parties.  As an example we
-   present 3 use cases in which the bit is useful:
-
-      The parent is a registry, the parent and the child use secured DNS
-      queries and responses, with a preexisting trust-relation, or plain
-      DNS over a secured channel to exchange the child's DNSKEY RR sets.
-      Since a DNSKEY RR set will contain a complete DNSKEY RRset the SEP
-      bit can be used to isolate the DNSKEYs for which a DS RR needs to
-      be created.
-
-      An administrator has configured a DNSKEY as root for a trusted
-      subtree into security aware resolver.  Using a special purpose
-      tool that queries for the KEY RRs from that domain's apex, the
-      administrator will be able to notice the roll over of the trusted
-      anchor by a change of the subset of KEY RRs with the DS flag set.
-
-      A signer might use the SEP bit on the public key to determine
-      which private key to use to exclusively sign the DNSKEY RRset and
-      which private key to use to sign the other RRsets in the zone.
-
-   As demonstrated in the above examples it is important to be able to
-   differentiate the SEP keys from the other keys in a DNSKEY RR set in
-   the flow between signer and (parental) key-collector and in the flow
-   between the signer and the resolver configuration.  The SEP flag is
-   to be of no interest to the flow between the verifier and the
-   authoritative data store.
-
-   The reason for the term "SEP" is a result of the observation that the
-   distinction between KSK and ZSK key pairs is made by the signer, a
-   key pair could be used as both a KSK and a ZSK at the same time.  To
-   be clear, the term SEP was coined to lessen the confusion caused by
-   the overlap.  (Once this label was applied, it had the side effect of
-   removing the temptation to have both a KSK flag bit and a ZSK flag
-   bit.)
-
-   The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
-   "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
-   interpreted as described in BCP 14, RFC 2119 [1].
-
-
-
-
-
-Kolkman, et al.              Standard Track                     [Page 3]
-
-RFC 3757                   DNSKEY RR SEP Flag                 April 2004
-
-
-2.  The Secure Entry Point (SEP) Flag
-
-                        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          |S|   protocol    |   algorithm   |
-   |                             |E|               |               |
-   |                             |P|               |               |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                                                               /
-   /                        public key                             /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-                          DNSKEY RR Format
-   This document assigns the 15th bit in the flags field as the secure
-   entry point (SEP) bit.  If the bit is set to 1 the key is intended to
-   be used as secure entry point key.  One SHOULD NOT assign special
-   meaning to the key if the bit is set to 0.  Operators can recognize
-   the secure entry point key by the even or odd-ness of the decimal
-   representation of the flag field.
-
-3.  DNSSEC Protocol Changes
-
-   The bit MUST NOT be used during the resolving and verification
-   process.  The SEP flag is only used to provide a hint about the
-   different administrative properties of the key and therefore the use
-   of the SEP flag does not change the DNS resolution protocol or the
-   resolution process.
-
-4.  Operational Guidelines
-
-   The SEP bit is set by the key-pair-generator and MAY be used by the
-   zone signer to decide whether the public part of the key pair is to
-   be prepared for input to a DS RR generation function.  The SEP bit is
-   recommended to be set (to 1) whenever the public key of the key pair
-   will be distributed to the parent zone to build the authentication
-   chain or if the public key is to be distributed for static
-   configuration in verifiers.
-
-   When a key pair is created, the operator needs to indicate whether
-   the SEP bit is to be set in the DNSKEY RR.  As the SEP bit is within
-   the data that is used to compute the 'key tag field' in the SIG RR,
-   changing the SEP bit will change the identity of the key within DNS.
-   In other words, once a key is used to generate signatures, the
-   setting of the SEP bit is to remain constant.  If not, a verifier
-   will not be able to find the relevant KEY RR.
-
-
-
-
-Kolkman, et al.              Standard Track                     [Page 4]
-
-RFC 3757                   DNSKEY RR SEP Flag                 April 2004
-
-
-   When signing a zone, it is intended that the key(s) with the SEP bit
-   set (if such keys exist) are used to sign the KEY RR set of the zone.
-   The same key can be used to sign the rest of the zone data too.  It
-   is conceivable that not all keys with a SEP bit set will sign the
-   DNSKEY RR set, such keys might be pending retirement or not yet in
-   use.
-
-   When verifying a RR set, the SEP bit is not intended to play a role.
-   How the key is used by the verifier is not intended to be a
-   consideration at key creation time.
-
-   Although the SEP flag provides a hint on which public key is to be
-   used as trusted root, administrators can choose to ignore the fact
-   that a DNSKEY has its SEP bit set or not when configuring a trusted
-   root for their resolvers.
-
-   Using the SEP flag a key roll over can be automated.  The parent can
-   use an existing trust relation to verify DNSKEY RR sets in which a
-   new DNSKEY RR with the SEP flag appears.
-
-5.  Security Considerations
-
-   As stated in Section 3 the flag is not to be used in the resolution
-   protocol or to determine the security status of a key.  The flag is
-   to be used for administrative purposes only.
-
-   No trust in a key should be inferred from this flag - trust MUST be
-   inferred from an existing chain of trust or an out-of-band exchange.
-
-   Since this flag might be used for automating public key exchanges, we
-   think the following consideration is in place.
-
-   Automated mechanisms for roll over of the DS RR might be vulnerable
-   to a class of replay attacks.  This might happen after a public key
-   exchange where a DNSKEY RR set, containing two DNSKEY RRs with the
-   SEP flag set, is sent to the parent.  The parent verifies the DNSKEY
-   RR set with the existing trust relation and creates the new DS RR
-   from the DNSKEY RR that the current DS RR is not pointing to.  This
-   key exchange might be replayed.  Parents are encouraged to implement
-   a replay defense.  A simple defense can be based on a registry of
-   keys that have been used to generate DS RRs during the most recent
-   roll over.  These same considerations apply to entities that
-   configure keys in resolvers.
-
-
-
-
-
-
-
-
-Kolkman, et al.              Standard Track                     [Page 5]
-
-RFC 3757                   DNSKEY RR SEP Flag                 April 2004
-
-
-6.  IANA Considerations
-
-   IANA has assigned the 15th bit in the DNSKEY Flags Registry (see
-   Section 4.3 of [4]) as the Secure Entry Point (SEP) bit.
-
-7.  Internationalization Considerations
-
-   Although SEP is a popular acronym in many different languages, there
-   are no internationalization considerations.
-
-8.  Acknowledgments
-
-   The ideas documented in this document are inspired by communications
-   we had with numerous people and ideas published by other folk.  Among
-   others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson,
-   Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler
-   have contributed ideas and provided feedback.
-
-   This document saw the light during a workshop on DNSSEC operations
-   hosted by USC/ISI in August 2002.
-
-9.  References
-
-9.1.  Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Eastlake, D., "Domain Name System Security Extensions", RFC
-        2535, March 1999.
-
-   [3]  Lewis, E., "DNS Security Extension Clarification on Zone
-        Status", RFC 3090, March 2001.
-
-   [4]  Weiler, S., "Legacy Resolver Compatibility for Delegation Signer
-        (DS)", RFC 3755, April 2004.
-
-9.2.  Informative References
-
-   [5]  Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
-        RFC 3658, December 2003.
-
-   [6]  Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy
-        Story", ISBN 0151002177 (50th anniversary edition), April 1996.
-
-
-
-
-
-
-
-Kolkman, et al.              Standard Track                     [Page 6]
-
-RFC 3757                   DNSKEY RR SEP Flag                 April 2004
-
-
-10.  Authors' Addresses
-
-   Olaf M. Kolkman
-   RIPE NCC
-   Singel 256
-   Amsterdam  1016 AB
-   NL
-
-   Phone: +31 20 535 4444
-   EMail: olaf@ripe.net
-   URI:   http://www.ripe.net/
-
-
-   Jakob Schlyter
-   NIC-SE
-   Box 5774
-   SE-114 87 Stockholm
-   Sweden
-
-   EMail: jakob@nic.se
-   URI:   http://www.nic.se/
-
-
-   Edward P. Lewis
-   ARIN
-   3635 Concorde Parkway Suite 200
-   Chantilly, VA  20151
-   US
-
-   Phone: +1 703 227 9854
-   EMail: edlewis@arin.net
-   URI:   http://www.arin.net/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al.              Standard Track                     [Page 7]
-
-RFC 3757                   DNSKEY RR SEP Flag                 April 2004
-
-
-11.  Full 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.
-
-   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.
-
-Intellectual Property
-
-   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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-Kolkman, et al.              Standard Track                     [Page 8]
-
diff --git a/contrib/bind9/doc/rfc/rfc3833.txt b/contrib/bind9/doc/rfc/rfc3833.txt
deleted file mode 100644
index 8ce4d34..0000000
--- a/contrib/bind9/doc/rfc/rfc3833.txt
+++ /dev/null
@@ -1,899 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          D. Atkins
-Request for Comments: 3833                              IHTFP Consulting
-Category: Informational                                       R. Austein
-                                                                     ISC
-                                                             August 2004
-
-
-            Threat Analysis of the Domain Name System (DNS)
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).
-
-Abstract
-
-   Although the DNS Security Extensions (DNSSEC) have been under
-   development for most of the last decade, the IETF has never written
-   down the specific set of threats against which DNSSEC is designed to
-   protect.  Among other drawbacks, this cart-before-the-horse situation
-   has made it difficult to determine whether DNSSEC meets its design
-   goals, since its design goals are not well specified.  This note
-   attempts to document some of the known threats to the DNS, and, in
-   doing so, attempts to measure to what extent (if any) DNSSEC is a
-   useful tool in defending against these threats.
-
-1. Introduction
-
-   The earliest organized work on DNSSEC within the IETF was an open
-   design team meeting organized by members of the DNS working group in
-   November 1993 at the 28th IETF meeting in Houston.  The broad
-   outlines of DNSSEC as we know it today are already clear in Jim
-   Galvin's summary of the results of that meeting [Galvin93]:
-
-   - While some participants in the meeting were interested in
-     protecting against disclosure of DNS data to unauthorized parties,
-     the design team made an explicit decision that "DNS data is
-     `public'", and ruled all threats of data disclosure explicitly out
-     of scope for DNSSEC.
-
-   - While some participants in the meeting were interested in
-     authentication of DNS clients and servers as a basis for access
-     control, this work was also ruled out of scope for DNSSEC per se.
-
-
-
-Atkins & Austein             Informational                      [Page 1]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   - Backwards compatibility and co-existence with "insecure DNS" was
-     listed as an explicit requirement.
-
-   - The resulting list of desired security services was
-     1) data integrity, and
-     2) data origin authentication.
-
-   - The design team noted that a digital signature mechanism would
-     support the desired services.
-
-   While a number of detail decisions were yet to be made (and in some
-   cases remade after implementation experience) over the subsequent
-   decade, the basic model and design goals have remained fixed.
-
-   Nowhere, however, does any of the DNSSEC work attempt to specify in
-   any detail the sorts of attacks against which DNSSEC is intended to
-   protect, or the reasons behind the list of desired security services
-   that came out of the Houston meeting.  For that, we have to go back
-   to a paper originally written by Steve Bellovin in 1990 but not
-   published until 1995, for reasons that Bellovin explained in the
-   paper's epilogue [Bellovin95].
-
-   While it may seem a bit strange to publish the threat analysis a
-   decade after starting work on the protocol designed to defend against
-   it, that is, nevertheless, what this note attempts to do.  Better
-   late than never.
-
-   This note assumes that the reader is familiar with both the DNS and
-   with DNSSEC, and does not attempt to provide a tutorial on either.
-   The DNS documents most relevant to the subject of this note are:
-   [RFC1034], [RFC1035], section 6.1 of [RFC1123], [RFC2181], [RFC2308],
-   [RFC2671], [RFC2845], [RFC2930], [RFC3007], and [RFC2535].
-
-   For purposes of discussion, this note uses the term "DNSSEC" to refer
-   to the core hierarchical public key and signature mechanism specified
-   in the DNSSEC documents, and refers to TKEY and TSIG as separate
-   mechanisms, even though channel security mechanisms such as TKEY and
-   TSIG are also part of the larger problem of "securing DNS" and thus
-   are often considered part of the overall set of "DNS security
-   extensions".  This is an arbitrary distinction that in part reflects
-   the way in which the protocol has evolved (introduction of a
-   putatively simpler channel security model for certain operations such
-   as zone transfers and dynamic update requests), and perhaps should be
-   changed in a future revision of this note.
-
-
-
-
-
-
-
-Atkins & Austein             Informational                      [Page 2]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-2.  Known Threats
-
-   There are several distinct classes of threats to the DNS, most of
-   which are DNS-related instances of more general problems, but a few
-   of which are specific to peculiarities of the DNS protocol.
-
-2.1.  Packet Interception
-
-   Some of the simplest threats against DNS are various forms of packet
-   interception: monkey-in-the-middle attacks, eavesdropping on requests
-   combined with spoofed responses that beat the real response back to
-   the resolver, and so forth.  In any of these scenarios, the attacker
-   can simply tell either party (usually the resolver) whatever it wants
-   that party to believe.  While packet interception attacks are far
-   from unique to DNS, DNS's usual behavior of sending an entire query
-   or response in a single unsigned, unencrypted UDP packet makes these
-   attacks particularly easy for any bad guy with the ability to
-   intercept packets on a shared or transit network.
-
-   To further complicate things, the DNS query the attacker intercepts
-   may just be a means to an end for the attacker: the attacker might
-   even choose to return the correct result in the answer section of a
-   reply message while using other parts of the message to set the stage
-   for something more complicated, for example, a name chaining attack
-   (see section 2.3).
-
-   While it certainly would be possible to sign DNS messages using a
-   channel security mechanism such as TSIG or IPsec, or even to encrypt
-   them using IPsec, this would not be a very good solution for
-   interception attacks.  First, this approach would impose a fairly
-   high processing cost per DNS message, as well as a very high cost
-   associated with establishing and maintaining bilateral trust
-   relationships between all the parties that might be involved in
-   resolving any particular query.  For heavily used name servers (such
-   as the servers for the root zone), this cost would almost certainly
-   be prohibitively high.  Even more important, however, is that the
-   underlying trust model in such a design would be wrong, since at best
-   it would only provide a hop-by-hop integrity check on DNS messages
-   and would not provide any sort of end-to-end integrity check between
-   the producer of DNS data (the zone administrator) and the consumer of
-   DNS data (the application that triggered the query).
-
-   By contrast, DNSSEC (when used properly) does provide an end-to-end
-   data integrity check, and is thus a much better solution for this
-   class of problems during basic DNS lookup operations.
-
-
-
-
-
-
-Atkins & Austein             Informational                      [Page 3]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   TSIG does have its place in corners of the DNS protocol where there's
-   a specific trust relationship between a particular client and a
-   particular server, such as zone transfer, dynamic update, or a
-   resolver (stub or otherwise) that is not going to check all the
-   DNSSEC signatures itself.
-
-   Note that DNSSEC does not provide any protection against modification
-   of the DNS message header, so any properly paranoid resolver must:
-
-   - Perform all of the DNSSEC signature checking on its own,
-
-   - Use TSIG (or some equivalent mechanism) to ensure the integrity of
-     its communication with whatever name servers it chooses to trust,
-     or
-
-   - Resign itself to the possibility of being attacked via packet
-     interception (and via other techniques discussed below).
-
-2.2.  ID Guessing and Query Prediction
-
-   Since DNS is for the most part used over UDP/IP, it is relatively
-   easy for an attacker to generate packets which will match the
-   transport protocol parameters.  The ID field in the DNS header is
-   only a 16-bit field and the server UDP port associated with DNS is a
-   well-known value, so there are only 2**32 possible combinations of ID
-   and client UDP port for a given client and server.  This is not a
-   particularly large range, and is not sufficient to protect against a
-   brute force search; furthermore, in practice both the client UDP port
-   and the ID can often be predicted from previous traffic, and it is
-   not uncommon for the client port to be a known fixed value as well
-   (due to firewalls or other restrictions), thus frequently reducing
-   the search space to a range smaller than 2**16.
-
-   By itself, ID guessing is not enough to allow an attacker to inject
-   bogus data, but combined with knowledge (or guesses) about QNAMEs and
-   QTYPEs for which a resolver might be querying, this leaves the
-   resolver only weakly defended against injection of bogus responses.
-
-   Since this attack relies on predicting a resolver's behavior, it's
-   most likely to be successful when the victim is in a known state,
-   whether because the victim rebooted recently, or because the victim's
-   behavior has been influenced by some other action by the attacker, or
-   because the victim is responding (in a predictable way) to some third
-   party action known to the attacker.
-
-
-
-
-
-
-
-Atkins & Austein             Informational                      [Page 4]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   This attack is both more and less difficult for the attacker than the
-   simple interception attack described above: more difficult, because
-   the attack only works when the attacker guesses correctly; less
-   difficult, because the attacker doesn't need to be on a transit or
-   shared network.
-
-   In most other respects, this attack is similar to a packet
-   interception attack.  A resolver that checks DNSSEC signatures will
-   be able to detect the forged response; resolvers that do not perform
-   DNSSEC signature checking themselves should use TSIG or some
-   equivalent mechanism to ensure the integrity of their communication
-   with a recursive name server that does perform DNSSEC signature
-   checking.
-
-2.3.  Name Chaining
-
-   Perhaps the most interesting class of DNS-specific threats are the
-   name chaining attacks.  These are a subset of a larger class of
-   name-based attacks, sometimes called "cache poisoning" attacks.  Most
-   name-based attacks can be partially mitigated by the long-standing
-   defense of checking RRs in response messages for relevance to the
-   original query, but such defenses do not catch name chaining attacks.
-   There are several variations on the basic attack, but what they all
-   have in common is that they all involve DNS RRs whose RDATA portion
-   (right hand side) includes a DNS name (or, in a few cases, something
-   that is not a DNS name but which directly maps to a DNS name).  Any
-   such RR is, at least in principle, a hook that lets an attacker feed
-   bad data into a victim's cache, thus potentially subverting
-   subsequent decisions based on DNS names.
-
-   The worst examples in this class of RRs are CNAME, NS, and DNAME RRs
-   because they can redirect a victim's query to a location of the
-   attacker's choosing.  RRs like MX and SRV are somewhat less
-   dangerous, but in principle they can also be used to trigger further
-   lookups at a location of the attacker's choosing.  Address RR types
-   such as A or AAAA don't have DNS names in their RDATA, but since the
-   IN-ADDR.ARPA and IP6.ARPA trees are indexed using a DNS encoding of
-   IPv4 and IPv6 addresses, these record types can also be used in a
-   name chaining attack.
-
-   The general form of a name chaining attack is something like this:
-
-   - Victim issues a query, perhaps at the instigation of the attacker
-     or some third party; in some cases the query itself may be
-     unrelated to the name under attack (that is, the attacker is just
-     using this query as a means to inject false information about some
-     other name).
-
-
-
-
-Atkins & Austein             Informational                      [Page 5]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   - Attacker injects response, whether via packet interception, query
-     guessing, or by being a legitimate name server that's involved at
-     some point in the process of answering the query that the victim
-     issued.
-
-   - Attacker's response includes one or more RRs with DNS names in
-     their RDATA; depending on which particular form this attack takes,
-     the object may be to inject false data associated with those names
-     into the victim's cache via the Additional section of this
-     response, or may be to redirect the next stage of the query to a
-     server of the attacker's choosing (in order to inject more complex
-     lies into the victim's cache than will fit easily into a single
-     response, or in order to place the lies in the Authority or Answer
-     section of a response where they will have a better chance of
-     sneaking past a resolver's defenses).
-
-   Any attacker who can insert resource records into a victim's cache
-   can almost certainly do some kind of damage, so there are cache
-   poisoning attacks which are not name chaining attacks in the sense
-   discussed here.  However, in the case of name chaining attacks, the
-   cause and effect relationship between the initial attack and the
-   eventual result may be significantly more complex than in the other
-   forms of cache poisoning, so name chaining attacks merit special
-   attention.
-
-   The common thread in all of the name chaining attacks is that
-   response messages allow the attacker to introduce arbitrary DNS names
-   of the attacker's choosing and provide further information that the
-   attacker claims is associated with those names; unless the victim has
-   better knowledge of the data associated with those names, the victim
-   is going to have a hard time defending against this class of attacks.
-
-   This class of attack is particularly insidious given that it's quite
-   easy for an attacker to provoke a victim into querying for a
-   particular name of the attacker's choosing, for example, by embedding
-   a link to a 1x1-pixel "web bug" graphic in a piece of Text/HTML mail
-   to the victim.  If the victim's mail reading program attempts to
-   follow such a link, the result will be a DNS query for a name chosen
-   by the attacker.
-
-   DNSSEC should provide a good defense against most (all?) variations
-   on this class of attack.  By checking signatures, a resolver can
-   determine whether the data associated with a name really was inserted
-   by the delegated authority for that portion of the DNS name space.
-   More precisely, a resolver can determine whether the entity that
-   injected the data had access to an allegedly secret key whose
-
-
-
-
-
-Atkins & Austein             Informational                      [Page 6]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   corresponding public key appears at an expected location in the DNS
-   name space with an expected chain of parental signatures that start
-   with a public key of which the resolver has prior knowledge.
-
-   DNSSEC signatures do not cover glue records, so there's still a
-   possibility of a name chaining attack involving glue, but with DNSSEC
-   it is possible to detect the attack by temporarily accepting the glue
-   in order to fetch the signed authoritative version of the same data,
-   then checking the signatures on the authoritative version.
-
-2.4.  Betrayal By Trusted Server
-
-   Another variation on the packet interception attack is the trusted
-   server that turns out not to be so trustworthy, whether by accident
-   or by intent.  Many client machines are only configured with stub
-   resolvers, and use trusted servers to perform all of their DNS
-   queries on their behalf.  In many cases the trusted server is
-   furnished by the user's ISP and advertised to the client via DHCP or
-   PPP options.  Besides accidental betrayal of this trust relationship
-   (via server bugs, successful server break-ins, etc), the server
-   itself may be configured to give back answers that are not what the
-   user would expect, whether in an honest attempt to help the user or
-   to promote some other goal such as furthering a business partnership
-   between the ISP and some third party.
-
-   This problem is particularly acute for frequent travelers who carry
-   their own equipment and expect it to work in much the same way
-   wherever they go.  Such travelers need trustworthy DNS service
-   without regard to who operates the network into which their equipment
-   is currently plugged or what brand of middle boxes the local
-   infrastructure might use.
-
-   While the obvious solution to this problem would be for the client to
-   choose a more trustworthy server, in practice this may not be an
-   option for the client.  In many network environments a client machine
-   has only a limited set of recursive name servers from which to
-   choose, and none of them may be particularly trustworthy.  In extreme
-   cases, port filtering or other forms of packet interception may
-   prevent the client host from being able to run an iterative resolver
-   even if the owner of the client machine is willing and able to do so.
-   Thus, while the initial source of this problem is not a DNS protocol
-   attack per se, this sort of betrayal is a threat to DNS clients, and
-   simply switching to a different recursive name server is not an
-   adequate defense.
-
-   Viewed strictly from the DNS protocol standpoint, the only difference
-   between this sort of betrayal and a packet interception attack is
-   that in this case the client has voluntarily sent its request to the
-
-
-
-Atkins & Austein             Informational                      [Page 7]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   attacker.  The defense against this is the same as with a packet
-   interception attack: the resolver must either check DNSSEC signatures
-   itself or use TSIG (or equivalent) to authenticate the server that it
-   has chosen to trust.  Note that use of TSIG does not by itself
-   guarantee that a name server is at all trustworthy: all TSIG can do
-   is help a resolver protect its communication with a name server that
-   it has already decided to trust for other reasons.  Protecting a
-   resolver's communication with a server that's giving out bogus
-   answers is not particularly useful.
-
-   Also note that if the stub resolver does not trust the name server
-   that is doing work on its behalf and wants to check the DNSSEC
-   signatures itself, the resolver really does need to have independent
-   knowledge of the DNSSEC public key(s) it needs in order to perform
-   the check.  Usually the public key for the root zone is enough, but
-   in some cases knowledge of additional keys may also be appropriate.
-
-   It is difficult to escape the conclusion that a properly paranoid
-   resolver must always perform its own signature checking, and that
-   this rule even applies to stub resolvers.
-
-2.5.  Denial of Service
-
-   As with any network service (or, indeed, almost any service of any
-   kind in any domain of discourse), DNS is vulnerable to denial of
-   service attacks.  DNSSEC does not help this, and may in fact make the
-   problem worse for resolvers that check signatures, since checking
-   signatures both increases the processing cost per DNS message and in
-   some cases can also increase the number of messages needed to answer
-   a query.  TSIG (and similar mechanisms) have equivalent problems.
-
-   DNS servers are also at risk of being used as denial of service
-   amplifiers, since DNS response packets tend to be significantly
-   longer than DNS query packets.  Unsurprisingly, DNSSEC doesn't help
-   here either.
-
-2.6.  Authenticated Denial of Domain Names
-
-   Much discussion has taken place over the question of authenticated
-   denial of domain names.  The particular question is whether there is
-   a requirement for authenticating the non-existence of a name.  The
-   issue is whether the resolver should be able to detect when an
-   attacker removes RRs from a response.
-
-   General paranoia aside, the existence of RR types whose absence
-   causes an action other than immediate failure (such as missing MX and
-   SRV RRs, which fail over to A RRs) constitutes a real threat.
-   Arguably, in some cases, even the absence of an RR might be
-
-
-
-Atkins & Austein             Informational                      [Page 8]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   considered a problem.  The question remains: how serious is this
-   threat?  Clearly the threat does exist; general paranoia says that
-   some day it'll be on the front page of some major newspaper, even if
-   we cannot conceive of a plausible scenario involving this attack
-   today.  This implies that some mitigation of this risk is required.
-
-   Note that it's necessary to prove the non-existence of applicable
-   wildcard RRs as part of the authenticated denial mechanism, and that,
-   in a zone that is more than one label deep, such a proof may require
-   proving the non-existence of multiple discrete sets of wildcard RRs.
-
-   DNSSEC does include mechanisms which make it possible to determine
-   which authoritative names exist in a zone, and which authoritative
-   resource record types exist at those names.  The DNSSEC protections
-   do not cover non-authoritative data such as glue records.
-
-2.7.  Wildcards
-
-   Much discussion has taken place over whether and how to provide data
-   integrity and data origin authentication for "wildcard" DNS names.
-   Conceptually, RRs with wildcard names are patterns for synthesizing
-   RRs on the fly according to the matching rules described in section
-   4.3.2 of RFC 1034.  While the rules that control the behavior of
-   wildcard names have a few quirks that can make them a trap for the
-   unwary zone administrator, it's clear that a number of sites make
-   heavy use of wildcard RRs, particularly wildcard MX RRs.
-
-   In order to provide the desired services for wildcard RRs, we need to
-   do two things:
-
-   - We need a way to attest to the existence of the wildcard RR itself
-     (that is, we need to show that the synthesis rule exists), and
-
-   - We need a way to attest to the non-existence of any RRs which, if
-     they existed, would make the wildcard RR irrelevant according to
-     the synthesis rules that govern the way in which wildcard RRs are
-     used (that is, we need to show that the synthesis rule is
-     applicable).
-
-   Note that this makes the wildcard mechanisms dependent upon the
-   authenticated denial mechanism described in the previous section.
-
-   DNSSEC includes mechanisms along the lines described above, which
-   make it possible for a resolver to verify that a name server applied
-   the wildcard expansion rules correctly when generating an answer.
-
-
-
-
-
-
-Atkins & Austein             Informational                      [Page 9]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-3.  Weaknesses of DNSSEC
-
-   DNSSEC has some problems of its own:
-
-   - DNSSEC is complex to implement and includes some nasty edge cases
-     at the zone cuts that require very careful coding.  Testbed
-     experience to date suggests that trivial zone configuration errors
-     or expired keys can cause serious problems for a DNSSEC-aware
-     resolver, and that the current protocol's error reporting
-     capabilities may leave something to be desired.
-
-   - DNSSEC significantly increases the size of DNS response packets;
-     among other issues, this makes DNSSEC-aware DNS servers even more
-     effective as denial of service amplifiers.
-
-   - DNSSEC answer validation increases the resolver's work load, since
-     a DNSSEC-aware resolver will need to perform signature validation
-     and in some cases will also need to issue further queries.  This
-     increased workload will also increase the time it takes to get an
-     answer back to the original DNS client, which is likely to trigger
-     both timeouts and re-queries in some cases.  Arguably, many current
-     DNS clients are already too impatient even before taking the
-     further delays that DNSSEC will impose into account, but that topic
-     is beyond the scope of this note.
-
-   - Like DNS itself, DNSSEC's trust model is almost totally
-     hierarchical.  While DNSSEC does allow resolvers to have special
-     additional knowledge of public keys beyond those for the root, in
-     the general case the root key is the one that matters.  Thus any
-     compromise in any of the zones between the root and a particular
-     target name can damage DNSSEC's ability to protect the integrity of
-     data owned by that target name.  This is not a change, since
-     insecure DNS has the same model.
-
-   - Key rollover at the root is really hard.  Work to date has not even
-     come close to adequately specifying how the root key rolls over, or
-     even how it's configured in the first place.
-
-   - DNSSEC creates a requirement of loose time synchronization between
-     the validating resolver and the entity creating the DNSSEC
-     signatures.  Prior to DNSSEC, all time-related actions in DNS could
-     be performed by a machine that only knew about "elapsed" or
-     "relative" time.  Because the validity period of a DNSSEC signature
-     is based on "absolute" time, a validating resolver must have the
-     same concept of absolute time as the zone signer in order to
-     determine whether the signature is within its validity period or
-     has expired.  An attacker that can change a resolver's opinion of
-     the current absolute time can fool the resolver using expired
-
-
-
-Atkins & Austein             Informational                     [Page 10]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-     signatures.  An attacker that can change the zone signer's opinion
-     of the current absolute time can fool the zone signer into
-     generating signatures whose validity period does not match what the
-     signer intended.
-
-   - The possible existence of wildcard RRs in a zone complicates the
-     authenticated denial mechanism considerably.  For most of the
-     decade that DNSSEC has been under development these issues were
-     poorly understood.  At various times there have been questions as
-     to whether the authenticated denial mechanism is completely
-     airtight and whether it would be worthwhile to optimize the
-     authenticated denial mechanism for the common case in which
-     wildcards are not present in a zone.  However, the main problem is
-     just the inherent complexity of the wildcard mechanism itself.
-     This complexity probably makes the code for generating and checking
-     authenticated denial attestations somewhat fragile, but since the
-     alternative of giving up wildcards entirely is not practical due to
-     widespread use, we are going to have to live with wildcards. The
-     question just becomes one of whether or not the proposed
-     optimizations would make DNSSEC's mechanisms more or less fragile.
-
-   - Even with DNSSEC, the class of attacks discussed in section 2.4 is
-     not easy to defeat.  In order for DNSSEC to be effective in this
-     case, it must be possible to configure the resolver to expect
-     certain categories of DNS records to be signed.  This may require
-     manual configuration of the resolver, especially during the initial
-     DNSSEC rollout period when the resolver cannot reasonably expect
-     the root and TLD zones to be signed.
-
-4.  Topics for Future Work
-
-   This section lists a few subjects not covered above which probably
-   need additional study, additional mechanisms, or both.
-
-4.1.  Interactions With Other Protocols
-
-   The above discussion has concentrated exclusively on attacks within
-   the boundaries of the DNS protocol itself, since those are (some of)
-   the problems against which DNSSEC was intended to protect.  There
-   are, however, other potential problems at the boundaries where DNS
-   interacts with other protocols.
-
-4.2.  Securing DNS Dynamic Update
-
-   DNS dynamic update opens a number of potential problems when combined
-   with DNSSEC.  Dynamic update of a non-secure zone can use TSIG to
-   authenticate the updating client to the server.  While TSIG does not
-   scale very well (it requires manual configuration of shared keys
-
-
-
-Atkins & Austein             Informational                     [Page 11]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   between the DNS name server and each TSIG client), it works well in a
-   limited or closed environment such as a DHCP server updating a local
-   DNS name server.
-
-   Major issues arise when trying to use dynamic update on a secure
-   zone.  TSIG can similarly be used in a limited fashion to
-   authenticate the client to the server, but TSIG only protects DNS
-   transactions, not the actual data, and the TSIG is not inserted into
-   the DNS zone, so resolvers cannot use the TSIG as a way of verifying
-   the changes to the zone.  This means that either:
-
-   a) The updating client must have access to a zone-signing key in
-      order to sign the update before sending it to the server, or
-
-   b) The DNS name server must have access to an online zone-signing key
-      in order to sign the update.
-
-   In either case, a zone-signing key must be available to create signed
-   RRsets to place in the updated zone.  The fact that this key must be
-   online (or at least available) is a potential security risk.
-
-   Dynamic update also requires an update to the SERIAL field of the
-   zone's SOA RR.  In theory, this could also be handled via either of
-   the above options, but in practice (a) would almost certainly be
-   extremely fragile, so (b) is the only workable mechanism.
-
-   There are other threats in terms of describing the policy of who can
-   make what changes to which RRsets in the zone.  The current access
-   control scheme in Secure Dynamic Update is fairly limited.  There is
-   no way to give fine-grained access to updating DNS zone information
-   to multiple entities, each of whom may require different kinds of
-   access.  For example, Alice may need to be able to add new nodes to
-   the zone or change existing nodes, but not remove them; Bob may need
-   to be able to remove zones but not add them; Carol may need to be
-   able to add, remove, or modify nodes, but only A records.
-
-   Scaling properties of the key management problem here are a
-   particular concern that needs more study.
-
-4.3.  Securing DNS Zone Replication
-
-   As discussed in previous sections, DNSSEC per se attempts to provide
-   data integrity and data origin authentication services on top of the
-   normal DNS query protocol.  Using the terminology discussed in
-   [RFC3552], DNSSEC provides "object security" for the normal DNS query
-   protocol.  For purposes of replicating entire DNS zones, however,
-   DNSSEC does not provide object security, because zones include
-   unsigned NS RRs and glue at delegation points.  Use of TSIG to
-
-
-
-Atkins & Austein             Informational                     [Page 12]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   protect zone transfer (AXFR or IXFR) operations provides "channel
-   security", but still does not provide object security for complete
-   zones. The trust relationships involved in zone transfer are still
-   very much a hop-by-hop matter of name server operators trusting other
-   name server operators rather than an end-to-end matter of name server
-   operators trusting zone administrators.
-
-   Zone object security was not an explicit design goal of DNSSEC, so
-   failure to provide this service should not be a surprise.
-   Nevertheless, there are some zone replication scenarios for which
-   this would be a very useful additional service, so this seems like a
-   useful area for future work.  In theory it should not be difficult to
-   add zone object security as a backwards compatible enhancement to the
-   existing DNSSEC model, but the DNSEXT WG has not yet discussed either
-   the desirability of or the requirements for such an enhancement.
-
-5.  Conclusion
-
-   Based on the above analysis, the DNSSEC extensions do appear to solve
-   a set of problems that do need to be solved, and are worth deploying.
-
-Security Considerations
-
-   This entire document is about security considerations of the DNS.
-   The authors believe that deploying DNSSEC will help to address some,
-   but not all, of the known threats to the DNS.
-
-Acknowledgments
-
-   This note is based both on previous published works by others and on
-   a number of discussions both public and private over a period of many
-   years, but particular thanks go to
-
-   Jaap Akkerhuis,
-   Steve Bellovin,
-   Dan Bernstein,
-   Randy Bush,
-   Steve Crocker,
-   Olafur Gudmundsson,
-   Russ Housley,
-   Rip Loomis,
-   Allison Mankin,
-   Paul Mockapetris,
-   Thomas Narten
-   Mans Nilsson,
-   Pekka Savola,
-   Paul Vixie,
-   Xunhua Wang,
-
-
-
-Atkins & Austein             Informational                     [Page 13]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-   and any other members of the DNS, DNSSEC, DNSIND, and DNSEXT working
-   groups whose names and contributions the authors have forgotten, none
-   of whom are responsible for what the authors did with their ideas.
-
-   As with any work of this nature, the authors of this note acknowledge
-   that we are standing on the toes of those who have gone before us.
-   Readers interested in this subject may also wish to read
-   [Bellovin95], [Schuba93], and [Vixie95].
-
-Normative References
-
-   [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.
-
-   [RFC1123]    Braden, R., "Requirements for Internet Hosts -
-                Application and Support", STD 3, RFC 1123, October 1989.
-
-   [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.
-
-   [RFC2845]    Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
-                Wellington, "Secret Key Transaction Authentication for
-                DNS (TSIG)", RFC 2845, May 2000.
-
-   [RFC2930]    Eastlake 3rd, D., "Secret Key Establishment for DNS
-                (TKEY RR)", RFC 2930, September 2000.
-
-   [RFC3007]    Wellington, B., "Secure Domain Name System (DNS) Dynamic
-                Update", RFC 3007, November 2000.
-
-   [RFC2535]    Eastlake 3rd, D., "Domain Name System Security
-                Extensions", RFC 2535, March 1999.
-
-
-
-
-
-
-
-
-
-
-Atkins & Austein             Informational                     [Page 14]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-Informative References
-
-   [RFC3552]    Rescorla, E. and B. Korver, "Guidelines for Writing RFC
-                Text on Security Considerations", BCP 72, RFC 3552, July
-                2003.
-
-   [Bellovin95] Bellovin, S., "Using the Domain Name System for System
-                Break-Ins", Proceedings of the Fifth Usenix Unix
-                Security Symposium, June 1995.
-
-   [Galvin93]   Design team meeting summary message posted to dns-
-                security@tis.com mailing list by Jim Galvin on 19
-                November 1993.
-
-   [Schuba93]   Schuba, C., "Addressing Weaknesses in the Domain Name
-                System Protocol", Master's thesis, Purdue University
-                Department of Computer Sciences,  August 1993.
-
-   [Vixie95]    Vixie, P, "DNS and BIND Security Issues", Proceedings of
-                the Fifth Usenix Unix Security Symposium, June 1995.
-
-Authors' Addresses
-
-   Derek Atkins
-   IHTFP Consulting, Inc.
-   6 Farragut Ave
-   Somerville, MA  02144
-   USA
-
-   EMail: derek@ihtfp.com
-
-
-   Rob Austein
-   Internet Systems Consortium
-   950 Charter Street
-   Redwood City, CA 94063
-   USA
-
-   EMail: sra@isc.org
-
-
-
-
-
-
-
-
-
-
-
-
-Atkins & Austein             Informational                     [Page 15]
-
-RFC 3833                  DNS Threat Analysis                August 2004
-
-
-Full 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.
-
-   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.
-
-Intellectual Property
-
-   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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-Atkins & Austein             Informational                     [Page 16]
-
diff --git a/contrib/bind9/doc/rfc/rfc3845.txt b/contrib/bind9/doc/rfc/rfc3845.txt
deleted file mode 100644
index 9887a20..0000000
--- a/contrib/bind9/doc/rfc/rfc3845.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                   J. Schlyter, Ed.
-Request for Comments: 3845                                   August 2004
-Updates: 3755, 2535
-Category: Standards Track
-
-
-          DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).
-
-Abstract
-
-   This document redefines the wire format of the "Type Bit Map" field
-   in the DNS NextSECure (NSEC) resource record RDATA format to cover
-   the full resource record (RR) type space.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
-   2.  The NSEC Resource Record . . . . . . . . . . . . . . . . . . .  2
-       2.1.  NSEC RDATA Wire Format . . . . . . . . . . . . . . . . .  3
-             2.1.1.  The Next Domain Name Field . . . . . . . . . . .  3
-             2.1.2.  The List of Type Bit Map(s) Field  . . . . . . .  3
-             2.1.3.  Inclusion of Wildcard Names in NSEC RDATA  . . .  4
-       2.2.  The NSEC RR Presentation Format  . . . . . . . . . . . .  4
-       2.3.  NSEC RR Example  . . . . . . . . . . . . . . . . . . . .  5
-   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  5
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  5
-   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
-       5.1.  Normative References . . . . . . . . . . . . . . . . . .  6
-       5.2.  Informative References . . . . . . . . . . . . . . . . .  6
-   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  6
-   7.  Author's Address . . . . . . . . . . . . . . . . . . . . . . .  6
-   8.  Full Copyright Statement . . . . . . . . . . . . . . . . . . .  7
-
-
-
-
-
-
-
-Schlyter, Ed.               Standards Track                     [Page 1]
-
-RFC 3845                DNSSEC NSEC RDATA Format             August 2004
-
-
-1.  Introduction
-
-   The DNS [6][7] NSEC [5] Resource Record (RR) is used for
-   authenticated proof of the non-existence of DNS owner names and
-   types.  The NSEC RR is based on the NXT RR as described in RFC 2535
-   [2], and is similar except for the name and typecode.  The RDATA
-   format for the NXT RR has the limitation in that the RDATA could only
-   carry information about the existence of the first 127 types.  RFC
-   2535 did reserve a bit to specify an extension mechanism, but the
-   mechanism was never actually defined.
-
-   In order to avoid needing to develop an extension mechanism into a
-   deployed base of DNSSEC aware servers and resolvers once the first
-   127 type codes are allocated, this document redefines the wire format
-   of the "Type Bit Map" field in the NSEC RDATA to cover the full RR
-   type space.
-
-   This document introduces a new format for the type bit map.  The
-   properties of the type bit map format are that it can cover the full
-   possible range of typecodes, that it is relatively economical in the
-   amount of space it uses for the common case of a few types with an
-   owner name, that it can represent owner names with all possible types
-   present in packets of approximately 8.5 kilobytes, and that the
-   representation is simple to implement.  Efficient searching of the
-   type bitmap for the presence of certain types is not a requirement.
-
-   For convenience and completeness, this document presents the syntax
-   and semantics for the NSEC RR based on the specification in RFC 2535
-   [2] and as updated by RFC 3755 [5], thereby not introducing changes
-   except for the syntax of the type bit map.
-
-   This document updates RFC 2535 [2] and RFC 3755 [5].
-
-   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 BCP 14, RFC 2119 [1].
-
-2.  The NSEC Resource Record
-
-   The NSEC resource record lists two separate things: the owner name of
-   the next RRset in the canonical ordering of the zone, and the set of
-   RR types present at the NSEC RR's owner name.  The complete set of
-   NSEC RRs in a zone indicate which RRsets exist in a zone, and form a
-   chain of owner names in the zone.  This information is used to
-   provide authenticated denial of existence for DNS data, as described
-   in RFC 2535 [2].
-
-   The type value for the NSEC RR is 47.
-
-
-
-Schlyter, Ed.               Standards Track                     [Page 2]
-
-RFC 3845                DNSSEC NSEC RDATA Format             August 2004
-
-
-   The NSEC RR RDATA format is class independent and defined for all
-   classes.
-
-   The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
-   field.  This is in the spirit of negative caching [8].
-
-2.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                         /
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-    /                   List of Type Bit Map(s)                     /
-    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-2.1.1.  The Next Domain Name Field
-
-   The Next Domain Name field contains the owner name of the next RR in
-   the canonical ordering of the zone.  The value of the Next Domain
-   Name field in the last NSEC record in the zone is the name of the
-   zone apex (the owner name of the zone's SOA RR).
-
-   A sender MUST NOT use DNS name compression on the Next Domain Name
-   field when transmitting an NSEC RR.
-
-   Owner names of RRsets that are 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.
-
-2.1.2.  The List of Type Bit Map(s) Field
-
-   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.
-
-   Window blocks are present in the NSEC RR RDATA in increasing
-   numerical order.
-
-   "|" denotes concatenation
-
-   Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +
-
-
-
-Schlyter, Ed.               Standards Track                     [Page 3]
-
-RFC 3845                DNSSEC NSEC RDATA Format             August 2004
-
-
-   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, and bit 2 to RR type 258.  If a bit is
-   set to 1, it indicates that an RRset of that type is present for the
-   NSEC RR's owner name.  If a bit is set to 0, it indicates that no
-   RRset of that type is present for the NSEC RR's owner name.
-
-   Since bit 0 in window block 0 refers to the non-existing RR type 0,
-   it MUST be set to 0.  After verification, the validator MUST ignore
-   the value of bit 0 in window block 0.
-
-   Bits representing Meta-TYPEs or QTYPEs, as specified in RFC 2929 [3]
-   (section 3.1), or within the range reserved for assignment only to
-   QTYPEs and Meta-TYPEs MUST be set to 0, 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
-   interpreted as zero octets.
-
-2.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.
-   RFC 2535 [2] describes the impact of wildcards on authenticated
-   denial of existence.
-
-2.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 List of Type Bit Map(s) Field is represented as a sequence of RR
-   type mnemonics.  When the mnemonic is not known, the TYPE
-   representation as described in RFC 3597 [4] (section 5) MUST be used.
-
-
-
-
-
-
-
-
-Schlyter, Ed.               Standards Track                     [Page 4]
-
-RFC 3845                DNSSEC NSEC RDATA Format             August 2004
-
-
-2.3.  NSEC RR Example
-
-   The following NSEC RR identifies the RRsets associated with
-   alfa.example.com. and 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:
-
-      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 resolver can authenticate this NSEC record, it
-   could be used to prove that beta.example.com does not exist, or could
-   be used to prove that there is no AAAA record associated with
-   alfa.example.com.  Authenticated denial of existence is discussed in
-   RFC 2535 [2].
-
-3.  IANA Considerations
-
-   This document introduces no new IANA considerations, because all of
-   the protocol parameters used in this document have already been
-   assigned by RFC 3755 [5].
-
-4.  Security Considerations
-
-   The update of the RDATA format and encoding does not affect the
-   security of the use of NSEC RRs.
-
-
-
-
-
-
-
-
-
-Schlyter, Ed.               Standards Track                     [Page 5]
-
-RFC 3845                DNSSEC NSEC RDATA Format             August 2004
-
-
-5.  References
-
-5.1.  Normative References
-
-   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [2]  Eastlake 3rd, D., "Domain Name System Security Extensions", RFC
-        2535, March 1999.
-
-   [3]  Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, "Domain
-        Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
-        September 2000.
-
-   [4]  Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
-        Types", RFC 3597, September 2003.
-
-   [5]  Weiler, S., "Legacy Resolver Compatibility for Delegation Signer
-        (DS)", RFC 3755, May 2004.
-
-5.2.  Informative References
-
-   [6]  Mockapetris, P., "Domain names - concepts and facilities", STD
-        13, RFC 1034, November 1987.
-
-   [7]  Mockapetris, P., "Domain names - implementation and
-        specification", STD 13, RFC 1035, November 1987.
-
-   [8]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC
-        2308, March 1998.
-
-6.  Acknowledgements
-
-   The encoding described in this document was initially proposed by
-   Mark Andrews.  Other encodings where proposed by David Blacka and
-   Michael Graff.
-
-7.  Author's Address
-
-   Jakob Schlyter (editor)
-   NIC-SE
-   Box 5774
-   Stockholm  SE-114 87
-   Sweden
-
-   EMail: jakob@nic.se
-   URI: http://www.nic.se/
-
-
-
-
-Schlyter, Ed.               Standards Track                     [Page 6]
-
-RFC 3845                DNSSEC NSEC RDATA Format             August 2004
-
-
-8.  Full 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.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
-   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.
-
-Intellectual Property
-
-   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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Schlyter, Ed.               Standards Track                     [Page 7]
-
diff --git a/contrib/bind9/doc/rfc/rfc3901.txt b/contrib/bind9/doc/rfc/rfc3901.txt
deleted file mode 100644
index 43b7356..0000000
--- a/contrib/bind9/doc/rfc/rfc3901.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          A. Durand
-Request for Comments: 3901                        SUN Microsystems, Inc.
-BCP: 91                                                         J. Ihren
-Category: Best Current Practice                               Autonomica
-                                                          September 2004
-
-
-               DNS IPv6 Transport Operational Guidelines
-
-Status of this Memo
-
-   This document specifies an Internet Best Current Practices for the
-   Internet Community, and requests discussion and suggestions for
-   improvements.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2004).
-
-Abstract
-
-   This memo provides guidelines and Best Current Practice for operating
-   DNS in a world where queries and responses are carried in a mixed
-   environment of IPv4 and IPv6 networks.
-
-1.  Introduction to the Problem of Name Space Fragmentation:
-    following the referral chain
-
-   A resolver that tries to look up a name starts out at the root, and
-   follows referrals until it is referred to a name server that is
-   authoritative for the name.  If somewhere down the chain of referrals
-   it is referred to a name server that is only accessible over a
-   transport which the resolver cannot use, the resolver is unable to
-   finish the task.
-
-   When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is
-   only a matter of time until this starts to happen.  The complete DNS
-   hierarchy then starts to fragment into a graph where authoritative
-   name servers for certain nodes are only accessible over a certain
-   transport.  The concern is that a resolver using only a particular
-   version of IP and querying information about another node using the
-   same version of IP can not do it because somewhere in the chain of
-   servers accessed during the resolution process, one or more of them
-   will only be accessible with the other version of IP.
-
-   With all DNS data only available over IPv4 transport everything is
-   simple.  IPv4 resolvers can use the intended mechanism of following
-   referrals from the root and down while IPv6 resolvers have to work
-
-
-
-Durand & Ihren           Best Current Practice                  [Page 1]
-
-RFC 3901             DNS IPv6 Transport Guidelines        September 2004
-
-
-   through a "translator", i.e., they have to use a recursive name
-   server on a so-called "dual stack" host as a "forwarder" since they
-   cannot access the DNS data directly.
-
-   With all DNS data only available over IPv6 transport everything would
-   be equally simple, with the exception of IPv4 recursive name servers
-   having to switch to a forwarding configuration.
-
-   However, the second situation will not arise in the foreseeable
-   future.  Instead, the transition will be from IPv4 only to a mixture
-   of IPv4 and IPv6, with three categories of DNS data depending on
-   whether the information is available only over IPv4 transport, only
-   over IPv6 or both.
-
-   Having DNS data available on both transports is the best situation.
-   The major question is how to ensure that it becomes the norm as
-   quickly as possible.  However, while it is obvious that some DNS data
-   will only be available over v4 transport for a long time it is also
-   obvious that it is important to avoid fragmenting the name space
-   available to IPv4 only hosts.  For example, during transition it is
-   not acceptable to break the name space that we presently have
-   available for IPv4-only hosts.
-
-2.  Terminology
-
-   The phrase "IPv4 name server" indicates a name server available over
-   IPv4 transport.  It does not imply anything about what DNS [1,2] data
-   is served.  Likewise, "IPv6 [4,5,6] name server" indicates a name
-   server available over IPv6 transport.  The phrase "dual-stack name
-   server" indicates a name server that is actually configured to run
-   both protocols, IPv4 and IPv6, and not merely a server running on a
-   system capable of running both but actually configured to run only
-   one.
-
-3.  Policy Based Avoidance of Name Space Fragmentation
-
-   Today there are only a few DNS "zones" on the public Internet that
-   are available over IPv6 transport, and most of them can be regarded
-   as "experimental".  However, as soon as the root and top level
-   domains are available over IPv6 transport, it is reasonable to expect
-   that it will become more common to have zones served by IPv6 servers.
-
-   Having those zones served only by IPv6-only name server would not be
-   a good development, since this will fragment the previously
-   unfragmented IPv4 name space and there are strong reasons to find a
-   mechanism to avoid it.
-
-
-
-
-
-Durand & Ihren           Best Current Practice                  [Page 2]
-
-RFC 3901             DNS IPv6 Transport Guidelines        September 2004
-
-
-   The recommended approach to maintain name space continuity is to use
-   administrative policies, as described in the next section.
-
-4.  DNS IPv6 Transport recommended Guidelines
-
-   In order to preserve name space continuity, the following
-   administrative policies are recommended:
-
-      - every recursive name server SHOULD be either IPv4-only or dual
-        stack,
-
-         This rules out IPv6-only recursive servers.  However, one might
-         design configurations where a chain of IPv6-only name server
-         forward queries to a set of dual stack recursive name server
-         actually performing those recursive queries.
-
-      - every DNS zone SHOULD be served by at least one IPv4-reachable
-        authoritative name server.
-
-         This rules out DNS zones served only by IPv6-only authoritative
-         name servers.
-
-   Note: zone validation processes SHOULD ensure that there is at least
-   one IPv4 address record available for the name servers of any child
-   delegations within the zone.
-
-5.  Security Considerations
-
-   The guidelines described in this memo introduce no new security
-   considerations into the DNS protocol or associated operational
-   scenarios.
-
-6.  Acknowledgment
-
-   This document is the result of many conversations that happened in
-   the DNS community at IETF and elsewhere since 2001.  During that
-   period of time, a number of Internet drafts have been published to
-   clarify various aspects of the issues at stake.  This document
-   focuses on the conclusion of those discussions.
-
-   The authors would like to acknowledge the role of Pekka Savola in his
-   thorough review of the document.
-
-
-
-
-
-
-
-
-
-Durand & Ihren           Best Current Practice                  [Page 3]
-
-RFC 3901             DNS IPv6 Transport Guidelines        September 2004
-
-
-7.  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]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
-        Specification", RFC 2460, December 1998.
-
-   [5]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
-        Addressing Architecture", RFC 3513, April 2003.
-
-   [6]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS
-        Extensions to Support IP Version 6", RFC 3596, October 2003.
-
-8.  Authors' Addresses
-
-   Alain Durand
-   SUN Microsystems, Inc
-   17 Network circle UMPK17-202
-   Menlo Park, CA, 94025
-   USA
-
-   EMail: Alain.Durand@sun.com
-
-
-   Johan Ihren
-   Autonomica
-   Bellmansgatan 30
-   SE-118 47 Stockholm
-   Sweden
-
-   EMail: johani@autonomica.se
-
-
-
-
-
-
-
-
-
-
-
-
-
-Durand & Ihren           Best Current Practice                  [Page 4]
-
-RFC 3901             DNS IPv6 Transport Guidelines        September 2004
-
-
-9.  Full 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.
-
-   This document and the information contained herein are provided on an
-   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
-   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.
-
-Intellectual Property
-
-   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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Durand & Ihren           Best Current Practice                  [Page 5]
-
diff --git a/contrib/bind9/doc/rfc/rfc4025.txt b/contrib/bind9/doc/rfc/rfc4025.txt
deleted file mode 100644
index 92e7f40..0000000
--- a/contrib/bind9/doc/rfc/rfc4025.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                      M. Richardson
-Request for Comments: 4025                                           SSW
-Category: Standards Track                                   February 2005
-
-
-           A Method for Storing IPsec Keying Material in DNS
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document describes a new resource record for the 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 an IPsec tunnel
-   is established with the entity in question.
-
-   This record replaces the functionality of the sub-type #4 of the KEY
-   Resource Record, which has been obsoleted by RFC 3445.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
-       1.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . .  2
-       1.2.  Use of DNS Address-to-Name Maps (IN-ADDR.ARPA and
-             IP6.ARPA)  . . . . . . . . . . . . . . . . . . . . . . .  3
-       1.3.  Usage Criteria . . . . . . . . . . . . . . . . . . . . .  3
-   2.  Storage Formats  . . . . . . . . . . . . . . . . . . . . . . .  3
-       2.1.  IPSECKEY RDATA Format  . . . . . . . . . . . . . . . . .  3
-       2.2.  RDATA Format - Precedence  . . . . . . . . . . . . . . .  4
-       2.3.  RDATA Format - Gateway Type  . . . . . . . . . . . . . .  4
-       2.4.  RDATA Format - Algorithm Type  . . . . . . . . . . . . .  4
-       2.5.  RDATA Format - Gateway . . . . . . . . . . . . . . . . .  5
-       2.6.  RDATA Format - Public Keys . . . . . . . . . . . . . . .  5
-   3.  Presentation Formats . . . . . . . . . . . . . . . . . . . . .  6
-       3.1.  Representation of IPSECKEY RRs . . . . . . . . . . . . .  6
-       3.2.  Examples . . . . . . . . . . . . . . . . . . . . . . . .  6
-   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
-
-
-
-Richardson                  Standards Track                     [Page 1]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-       4.1.  Active Attacks Against Unsecured IPSECKEY Resource
-             Records  . . . . . . . . . . . . . . . . . . . . . . . .  8
-             4.1.1.  Active Attacks Against IPSECKEY Keying
-                     Materials. . . . . . . . . . . . . . . . . . . .  8
-             4.1.2.  Active Attacks Against IPSECKEY Gateway
-                     Material. . . . . . . . . . . . . . . . . . . .   8
-   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
-   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
-   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
-       7.1.  Normative References . . . . . . . . . . . . . . . . . . 10
-       7.2.  Informative References . . . . . . . . . . . . . . . . . 10
-   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
-   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 12
-
-1.  Introduction
-
-   Suppose a host wishes (or is required by policy) to establish an
-   IPsec tunnel with some remote entity on the network prior to allowing
-   normal communication to take place.  In many cases, this end system
-   will be able to determine the DNS name for the remote entity (either
-   by having the DNS name given explicitly, by performing a DNS PTR
-   query for a particular IP address, or through some other means, e.g.,
-   by extracting the DNS portion of a "user@FQDN" name for a remote
-   entity).  In these cases, the host will need to obtain a public key
-   to authenticate the remote entity, and may also need some guidance
-   about whether it should contact the entity directly or use another
-   node as a gateway to the target entity.  The IPSECKEY RR provides a
-   mechanism for storing such information.
-
-   The type number for the IPSECKEY RR is 45.
-
-   This record replaces the functionality of the sub-type #4 of the KEY
-   Resource Record, which has been obsoleted by RFC 3445 [11].
-
-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) [1] 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 RFC 2119 [3].
-
-
-
-
-
-
-
-Richardson                  Standards Track                     [Page 2]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-1.2.  Use of DNS Address-to-Name Maps (IN-ADDR.ARPA and IP6.ARPA)
-
-   Often a security gateway will only have access to the IP address of
-   the node with which communication is desired and will not know any
-   other name for the target node.  Because of this, frequently the best
-   way of looking up IPSECKEY RRs will be by using the IP address as an
-   index into one of the reverse mapping trees (IN-ADDR.ARPA for IPv4 or
-   IP6.ARPA for IPv6).
-
-   The lookup is done in the fashion usual for PTR records.  The IP
-   address' octets (IPv4) or nibbles (IPv6) are reversed and looked up
-   with the appropriate suffix.  Any CNAMEs or DNAMEs found MUST be
-   followed.
-
-   Note: even when the IPsec function is contained in the end-host,
-   often only the application will know the forward name used.  Although
-   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
-   [8] 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 a need to roll over keys.
-
-   This resource record is class independent.
-
-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.
-
-
-
-
-
-
-
-
-
-
-
-Richardson                  Standards Track                     [Page 3]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-       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.  It is interpreted in
-   the same way as the PREFERENCE field described in section 3.3.9 of
-   RFC 1035 [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 RFC 1035 [2].)
-
-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 RFC 2536 [9].
-   2  A RSA key is present, in the format defined in RFC 3110 [10].
-
-
-
-
-
-
-Richardson                  Standards Track                     [Page 4]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-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 RFC 1035
-   [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 RFC 3596
-   [12].  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 RFC 1035 [2].  Compression MUST NOT be used.
-
-2.6.  RDATA Format - Public Keys
-
-   Both 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 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 RRs.
-
-   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
-   for the corresponding algorithm.  The algorithm must still be
-   designated for use by IPSECKEY, and an IPSECKEY algorithm type number
-   (which might be different from the DNSSEC algorithm number) must be
-   assigned to it.
-
-   The DSA key format is defined in RFC 2536 [9]
-
-   The RSA key format is defined in RFC 3110 [10], with the following
-   changes:
-
-   The earlier definition of RSA/MD5 in RFC 2065 [4] limited the
-   exponent and modulus to 2552 bits in length.  RFC 3110 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
-
-
-
-Richardson                  Standards Track                     [Page 5]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-   imposed by the two-octet length encoding.  This length extension is
-   applicable only to IPSECKEY; it is not applicable to KEY RRs.
-
-3.  Presentation Formats
-
-3.1.  Representation of IPSECKEY RRs
-
-   IPSECKEY RRs may appear in a zone data master file.  The precedence,
-   gateway type, algorithm, and gateway fields are REQUIRED.  The base64
-   encoded public key block is OPTIONAL; if it is not present, the
-   public key field of the resource record MUST be construed to be 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 RFC 3548 [6], Section 5.2.
-
-   The general presentation for the record is 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== )
-
-
-
-
-
-
-
-
-
-Richardson                  Standards Track                     [Page 6]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-   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== )
-
-   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== )
-
-4.  Security Considerations
-
-   This entire memo pertains to the provision of public keying material
-   for use by key management protocols such as ISAKMP/IKE (RFC 2407)
-   [7].
-
-   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 defense
-   against both active and passive attacks.
-
-   Any derivative specification that makes use of this resource record
-   MUST carefully document its trust model and why the trust model of
-   DNSSEC is appropriate, if that is the secure channel used.
-
-
-
-
-
-Richardson                  Standards Track                     [Page 7]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-   An active attack on the DNS that caused the wrong IP address to be
-   retrieved (via forged address), and therefore the wrong QNAME to be
-   queried, would also result in a man-in-the-middle attack.  This
-   situation is independent of whether the IPSECKEY RR is 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.
-   This section deals with the situation in which DNSSEC is not
-   available.  This is not the recommended deployment scenario.
-
-4.1.1.  Active Attacks Against IPSECKEY Keying Materials
-
-   The first kind of active attack is when the attacker replaces the
-   keying material with either a key under its control or with garbage.
-
-   The gateway field is either untouched or is null.  The IKE
-   negotiation will therefore occur with the original end-system.  For
-   this attack to succeed, the attacker must perform a man-in-the-middle
-   attack on the IKE negotiation.  This attack requires that the
-   attacker be able to intercept and modify packets on the forwarding
-   path for the IKE and data packets.
-
-   If the attacker is not able to perform this man-in-the-middle attack
-   on the IKE negotiation, then a denial of service will result, as the
-   IKE negotiation will fail.
-
-   If the attacker is not only able to mount active attacks against DNS
-   but also in a position to perform a man-in-the-middle attack on IKE
-   and IPsec negotiations, then the attacker will be able 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 for
-   this to succeed.
-
-4.1.2.  Active Attacks Against IPSECKEY Gateway Material
-
-   The second kind of active attack is one in which the attacker
-   replaces the gateway address to point to a node under the attacker's
-   control.  The attacker then either replaces the public key or removes
-   it.  If the public key were removed, then the attacker could provide
-   an accurate public key of its own in a second record.
-
-   This second form creates a simple man-in-the-middle attacks 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.
-
-
-
-Richardson                  Standards Track                     [Page 8]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-   Note that the man-in-the-middle cannot 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
-   already have created a policy expecting ciphertext.  Thus, the
-   attacker will need to intercept traffic in both directions.  In some
-   cases, the attacker may be able to accomplish the full intercept by
-   use of Network Address/Port Translation (NAT/NAPT) technology.
-
-   This attack is easier than the first one because the attacker does
-   NOT need to be on the end-to-end forwarding path.  The attacker need
-   only be able to modify DNS replies.  This can be done by packet
-   modification, by various kinds of race attacks, or through methods
-   that pollute DNS caches.
-
-   If 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.  As the RR owner
-   name is assumed when the gateway field is null, a null gateway field
-   is considered a match.
-
-   Thus, any records obtained under unverified conditions (e.g., no
-   DNSSEC or trusted path to source) that have a non-null gateway field
-   MUST be ignored.
-
-   This restriction eliminates attacks against the gateway field, which
-   are considered much easier, as the attack does not need to be on the
-   forwarding path.
-
-   In the case of an IPSECKEY RR with a value of three in its gateway
-   type field, the gateway field contains a domain name.  The subsequent
-   query required to translate that name into an IP address or IPSECKEY
-   RR will also be subject to man-in-the-middle attacks.  If the
-   end-to-end integrity of this second query is suspect, then the
-   provisions above also apply.  The IPSECKEY RR MUST be ignored
-   whenever the resulting gateway does not match the QNAME of the
-   original IPSECKEY RR query.
-
-5.  IANA Considerations
-
-   This document updates the IANA Registry for DNS Resource Record Types
-   by assigning type 45 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.
-
-
-
-
-
-Richardson                  Standards Track                     [Page 9]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-   Values 0, 1, and 2 are defined in Section 2.4.  Algorithm numbers 3
-   through 255 can be assigned by IETF Consensus (see RFC 2434 [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 RFC
-   2434 [5]).
-
-6.  Acknowledgements
-
-   My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob
-   Austein, and Olafur Gudmundsson, who reviewed this document
-   carefully.  Additional thanks to Olafur Gurmundsson for a reference
-   implementation.
-
-7.  References
-
-7.1.  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., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [4]  Eastlake 3rd, 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.
-
-7.2.  Informative References
-
-   [7]  Piper, D., "The Internet IP Security Domain of Interpretation
-        for ISAKMP", RFC 2407, November 1998.
-
-   [8]  Eastlake 3rd, D., "Domain Name System Security Extensions", RFC
-        2535, March 1999.
-
-   [9]  Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name System
-        (DNS)", RFC 2536, March 1999.
-
-
-
-Richardson                  Standards Track                    [Page 10]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-   [10] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
-        Name System (DNS)", RFC 3110, May 2001.
-
-   [11] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
-        Record (RR)", RFC 3445, December 2002.
-
-   [12] 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                  Standards Track                    [Page 11]
-
-RFC 4025          Storing IPsec Keying Material in DNS     February 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   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.
-
-Intellectual Property
-
-   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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Richardson                  Standards Track                    [Page 12]
-
diff --git a/contrib/bind9/doc/rfc/rfc4033.txt b/contrib/bind9/doc/rfc/rfc4033.txt
deleted file mode 100644
index 7f0a464..0000000
--- a/contrib/bind9/doc/rfc/rfc4033.txt
+++ /dev/null
@@ -1,1179 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          R. Arends
-Request for Comments: 4033                          Telematica Instituut
-Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658,                R. Austein
-           3755, 3757, 3845                                          ISC
-Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
-         3007, 3597, 3226                                       VeriSign
-Category: Standards Track                                      D. Massey
-                                               Colorado State University
-                                                                 S. Rose
-                                                                    NIST
-                                                              March 2005
-
-
-               DNS Security Introduction and Requirements
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   The Domain Name System Security Extensions (DNSSEC) add data origin
-   authentication and data integrity to the Domain Name System.  This
-   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 documents that
-   collectively describe DNSSEC.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 1]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .   2
-   2.  Definitions of Important DNSSEC Terms  . . . . . . . . . . .   3
-   3.  Services Provided by DNS Security  . . . . . . . . . . . . .   7
-       3.1.  Data Origin Authentication and Data Integrity  . . . .   7
-       3.2.  Authenticating Name and Type Non-Existence . . . . . .   9
-   4.  Services Not Provided by DNS Security  . . . . . . . . . . .   9
-   5.  Scope of the DNSSEC Document Set and Last Hop Issues . . . .   9
-   6.  Resolver Considerations  . . . . . . . . . . . . . . . . . .  10
-   7.  Stub Resolver Considerations . . . . . . . . . . . . . . . .  11
-   8.  Zone Considerations  . . . . . . . . . . . . . . . . . . . .  12
-       8.1.  TTL Values vs. RRSIG Validity Period . . . . . . . . .  13
-       8.2.  New Temporal Dependency Issues for Zones . . . . . . .  13
-   9.  Name Server Considerations . . . . . . . . . . . . . . . . .  13
-   10. DNS Security Document Family . . . . . . . . . . . . . . . .  14
-   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . .  15
-   12. Security Considerations  . . . . . . . . . . . . . . . . . .  15
-   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  17
-   14. References . . . . . . . . . . . . . . . . . . . . . . . . .  17
-       14.1. Normative References . . . . . . . . . . . . . . . . .  17
-       14.2. Informative References . . . . . . . . . . . . . . . .  18
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .  20
-   Full Copyright Statement . . . . . . . . . . . . . . . . . . . .  21
-
-1.  Introduction
-
-   This document introduces the Domain Name System Security Extensions
-   (DNSSEC).  This document and its two companion documents ([RFC4034]
-   and [RFC4035]) update, clarify, and refine the security extensions
-   defined in [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.  Sections
-   3 and 4 describe the capabilities and limitations of the security
-   extensions in greater detail.  Section 5 discusses the scope of the
-   document set.  Sections 6, 7, 8, and 9 discuss the effect that these
-   security extensions will have on resolvers, stub resolvers, zones,
-   and name servers.
-
-   This document and its two companions obsolete [RFC2535], [RFC3008],
-   [RFC3090], [RFC3445], [RFC3655], [RFC3658], [RFC3755], [RFC3757], and
-   [RFC3845].  This document set also updates but does not obsolete
-   [RFC1034], [RFC1035], [RFC2136], [RFC2181], [RFC2308], [RFC3225],
-   [RFC3007], [RFC3597], and the portions of [RFC3226] that deal with
-   DNSSEC.
-
-
-
-
-Arends, et al.              Standards Track                     [Page 2]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   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.
-
-2.  Definitions of Important DNSSEC Terms
-
-   This section defines a number of terms used in this document set.
-   Because 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, and then come
-   back to this section.
-
-   Authentication Chain: An alternating sequence of DNS public key
-      (DNSKEY) RRsets and Delegation Signer (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." and 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 that 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.
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 3]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   Authoritative RRset: Within the context of a particular zone, an
-      RRset is "authoritative" if and only if the owner name of the
-      RRset lies within the subset of the name space that is at or below
-      the zone apex and at or above the cuts that separate the zone from
-      its children, if any.  All RRsets at the zone apex are
-      authoritative, except for certain RRsets at this domain name that,
-      if present, belong to this zone's parent.  These RRset could
-      include a DS RRset, the NSEC RRset referencing this DS RRset (the
-      "parental NSEC"), and RRSIG RRs associated with these RRsets, all
-      of which are authoritative in the parent zone.  Similarly, if this
-      zone contains any delegation points, only the parental NSEC RRset,
-      DS RRsets, and any RRSIG RRs associated with these RRsets are
-      authoritative for this zone.
-
-   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).  See also zone apex.
-
-   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 [RFC4034]).
-      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 that will sign other zone data.  Local
-      policy may require that the zone signing key 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.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 4]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   Non-Validating Security-Aware Stub Resolver: A security-aware stub
-      resolver that 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 that sends DNS queries, receives DNS
-      responses, and is capable of establishing an appropriately secured
-      channel to a security-aware recursive name server that 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 that
-      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.
-
-   Security-Aware Recursive Name Server: An entity that acts in both the
-      security-aware name server and security-aware resolver roles.  A
-      more cumbersome but equivalent phrase would be "a security-aware
-      name server that offers recursive service".
-
-   Security-Aware Resolver: An entity acting in the role of a resolver
-      (defined in section 2.4 of [RFC1034]) that understands the DNS
-      security extensions defined in this document set.  In particular,
-      a security-aware resolver is an entity that 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]) that 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.
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 5]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   Security-Oblivious <anything>: An <anything> that is not
-      "security-aware".
-
-   Signed Zone: A zone whose RRsets are signed and that contains
-      properly constructed DNSKEY, Resource Record Signature (RRSIG),
-      Next Secure (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 have 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 that 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.
-
-   Validating Stub Resolver: A less tedious term for a validating
-      security-aware stub resolver.
-
-   Zone Apex: Term used to describe the name at the child's side of a
-      zone cut.  See also delegation point.
-
-   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.              Standards Track                     [Page 6]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-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: Resource Record Signature (RRSIG),
-   DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure
-   (NSEC).  It also adds two new message header bits: Checking Disabled
-   (CD) and Authenticated Data (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 DNSSEC OK (DO) EDNS header 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 [RFC3833].  Please see Section 12 for a
-   discussion of the limitations of these extensions.
-
-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 discover a public key reliably via DNS
-   resolution, the target key itself has to be signed by either a
-   configured authentication key or another key that has been
-
-
-
-Arends, et al.              Standards Track                     [Page 7]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   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,
-   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 trust anchor 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
-   configured trust anchor is the hash of a key rather than the key
-   itself, the resolver may have 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 that 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, 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.
-
-
-
-
-Arends, et al.              Standards Track                     [Page 8]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-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
-   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
-   with 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 and list
-   the types of RRsets present at existing names.  Each NSEC record is
-   signed and authenticated using the mechanisms described in Section
-   3.1.
-
-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
-   ([RFC2136], [RFC3007]).  Message authentication schemes described in
-   [RFC2845] and [RFC2931] address security operations that pertain to
-   these transactions.
-
-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 the following 4 states:
-
-   Secure: The validating resolver has a trust anchor, has a chain of
-      trust, and is able to verify all the signatures in the response.
-
-
-
-Arends, et al.              Standards Track                     [Page 9]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   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.  This indicates that subsequent
-      branches in the tree are provably insecure.  A validating resolver
-      may have a local policy to mark parts of the domain space as
-      insecure.
-
-   Bogus: The validating resolver has a trust anchor and a secure
-      delegation indicating that subsidiary data is signed, but the
-      response fails to validate for some reason: missing signatures,
-      expired signatures, signatures with unsupported algorithms, data
-      missing that the relevant NSEC RR says should be present, and so
-      forth.
-
-   Indeterminate: There is no trust anchor that 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 [RFC4035]).
-
-   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 [RFC4035]).
-
-   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 states.
-
-   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
-   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.
-
-6.  Resolver Considerations
-
-   A security-aware resolver has 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
-
-
-
-Arends, et al.              Standards Track                    [Page 10]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   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 intermediary device that acts as a proxy for DNS, and if the
-   recursive name server or intermediary device 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 (NAT) device that
-   includes a DNS proxy that is not security-aware, the security-aware
-   resolver may find it difficult or impossible to obtain or validate
-   signed DNS data.  The security-aware resolver may have a particularly
-   difficult time obtaining DS RRs in such a case, as DS RRs do not
-   follow the usual DNS rules for ownership of RRs at zone cuts.  Note
-   that this problem is not specific to NATs: any security-oblivious DNS
-   software of any kind between the security-aware resolver and the
-   authoritative name servers will interfere with DNSSEC.
-
-   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.  However, it should also allow for the possibility that
-   the security-aware resolver's own clock is wrong.  Thus, a
-   security-aware resolver that is part of a security-aware recursive
-   name server will have to pay careful attention to the DNSSEC
-   "checking disabled" (CD) bit ([RFC4034]).  This is in order to avoid
-   blocking valid signatures from getting through to other
-   security-aware resolvers that are clients of this recursive name
-   server.  See [RFC4035] for how a secure recursive server handles
-   queries with the CD bit set.
-
-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 that 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
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 11]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   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 security-aware iterative resolver.
-
-   Even a security-oblivious stub resolver may 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 choice but to place itself at
-   the mercy of the recursive name servers that it uses, as 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) ([RFC2931]) or
-   TSIG ([RFC2845]) would suffice, as would appropriate use of IPsec.
-   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 Authenticated Data (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 that 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 trust relationships between
-   the zone administrators and the stub resolver itself.
-
-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 that establish a validity period for the signatures
-   and the zone data the signatures cover.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 12]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-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 the resolver is security-aware.
-
-   The inception and expiration fields in the RRSIG RR ([RFC4034]), 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 that 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 will in turn 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 transfer operations.
-
-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 that have signaled their willingness to receive such
-   records via use of the DO bit in the EDNS header, subject to message
-   size limitations.  Because 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.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 13]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   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
-   it is updated, so the private key corresponding to the zone signing
-   key will have to be kept online.  This is an example of a situation
-   in which the ability to separate the zone's DNSKEY RRset into zone
-   signing key(s) and key signing key(s) may be useful, as 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).
-
-   By itself, DNSSEC is not enough to protect the integrity of an entire
-   zone during zone transfer operations, as 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).
-
-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 that
-   form the core of the DNS security extensions:
-
-   1.  DNS Security Introduction and Requirements (this document)
-
-   2.  Resource Records for DNS Security Extensions [RFC4034]
-
-   3.  Protocol Modifications for the DNS Security Extensions [RFC4035]
-
-   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.  Please see the appendix on "DNSSEC
-   Algorithm and Digest Types" in [RFC4034] for a list of the algorithms
-   that were defined when this core specification was written.
-
-   The "Transaction Authentication Protocol" document set refers to the
-   group of documents that deal with DNS message authentication,
-   including secret key establishment and verification.  Although not
-
-
-
-Arends, et al.              Standards Track                    [Page 14]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   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 those describing the use of DNS in the
-   storage and distribution of certificates ([RFC2538]).
-
-11.  IANA Considerations
-
-   This overview document introduces no new IANA considerations.  Please
-   see [RFC4034] for a complete review of the IANA considerations
-   introduced by DNSSEC.
-
-12.  Security Considerations
-
-   This document introduces 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 section discusses the 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 that the resolver is only able to obtain through a recursive
-   name server that 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 such as TSIG ([RFC2845]) or
-   SIG(0) ([RFC2931]), 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 that perform these checks on its behalf and to attacks
-   on its communication with those security-aware recursive name
-
-
-
-Arends, et al.              Standards Track                    [Page 15]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   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, as 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
-   consume resources in a security-aware name server that 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.
-
-   Due to a deliberate design choice, DNSSEC does not provide
-   confidentiality.
-
-   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.  Although this is not an attack on
-   the DNS itself, it 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 it 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 (such as TSIG, SIG(0), or IPsec) must be
-   used to protect zone transfer operations.
-
-
-
-Arends, et al.              Standards Track                    [Page 16]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   Please see [RFC4034] and [RFC4035] for additional security
-   considerations.
-
-13.  Acknowledgements
-
-   This document was created from the input and ideas of the members of
-   the DNS Extensions Working Group.  Although explicitly listing
-   everyone who has contributed during the decade in which DNSSEC has
-   been under development would be impossible, 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, Thomas Narten, 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.
-
-14.  References
-
-14.1.  Normative References
-
-   [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 3rd, 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.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 17]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   [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.
-
-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Resource Records for DNS Security Extensions", RFC
-              4034, March 2005.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-14.2.  Informative References
-
-   [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 3rd, D. and O. Gudmundsson, "Storing Certificates
-              in the Domain Name System (DNS)", RFC 2538, March 1999.
-
-   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
-              Wellington, "Secret Key Transaction Authentication for DNS
-              (TSIG)", RFC 2845, May 2000.
-
-   [RFC2931]  Eastlake 3rd, 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.
-
-
-
-
-Arends, et al.              Standards Track                    [Page 18]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-   [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 (DS)", RFC 3755, May 2004.
-
-   [RFC3757]  Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name
-              System KEY (DNSKEY) Resource Record (RR) Secure Entry
-              Point (SEP) Flag", RFC 3757, April 2004.
-
-   [RFC3833]  Atkins, D. and R. Austein, "Threat Analysis of the Domain
-              Name System (DNS)", RFC 3833, August 2004.
-
-   [RFC3845]  Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)
-              RDATA Format", RFC 3845, August 2004.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 19]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-Authors' Addresses
-
-   Roy Arends
-   Telematica Instituut
-   Brouwerijstraat 1
-   7523 XC  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
-   Colorado State University
-   Department of Computer Science
-   Fort Collins, CO 80523-1873
-
-   EMail: massey@cs.colostate.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.              Standards Track                    [Page 20]
-
-RFC 4033       DNS Security Introduction and Requirements     March 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   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.
-
-Intellectual Property
-
-   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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 21]
-
diff --git a/contrib/bind9/doc/rfc/rfc4034.txt b/contrib/bind9/doc/rfc/rfc4034.txt
deleted file mode 100644
index 6a12c6b..0000000
--- a/contrib/bind9/doc/rfc/rfc4034.txt
+++ /dev/null
@@ -1,1627 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          R. Arends
-Request for Comments: 4034                          Telematica Instituut
-Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658,                R. Austein
-           3755, 3757, 3845                                          ISC
-Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
-         3007, 3597, 3226                                       VeriSign
-Category: Standards Track                                      D. Massey
-                                               Colorado State University
-                                                                 S. Rose
-                                                                    NIST
-                                                              March 2005
-
-
-            Resource Records for the DNS Security Extensions
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document is part of a family of documents that describe the DNS
-   Security Extensions (DNSSEC).  The DNS Security Extensions are a
-   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.
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 1]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
-       1.1.  Background and Related Documents . . . . . . . . . . .  3
-       1.2.  Reserved Words . . . . . . . . . . . . . . . . . . . .  3
-   2.  The DNSKEY Resource Record . . . . . . . . . . . . . . . . .  4
-       2.1.  DNSKEY RDATA Wire Format . . . . . . . . . . . . . . .  4
-             2.1.1.  The Flags Field. . . . . . . . . . . . . . . .  4
-             2.1.2.  The Protocol Field . . . . . . . . . . . . . .  5
-             2.1.3.  The Algorithm Field. . . . . . . . . . . . . .  5
-             2.1.4.  The Public Key Field . . . . . . . . . . . . .  5
-             2.1.5.  Notes on DNSKEY RDATA Design . . . . . . . . .  5
-       2.2.  The DNSKEY RR Presentation Format. . . . . . . . . . .  5
-       2.3.  DNSKEY RR Example  . . . . . . . . . . . . . . . . . .  6
-   3.  The RRSIG Resource Record  . . . . . . . . . . . . . . . . .  6
-       3.1.  RRSIG RDATA Wire Format. . . . . . . . . . . . . . . .  7
-             3.1.1.  The Type Covered Field . . . . . . . . . . . .  7
-             3.1.2.  The Algorithm Number Field . . . . . . . . . .  8
-             3.1.3.  The Labels Field . . . . . . . . . . . . . . .  8
-             3.1.4.  Original TTL Field . . . . . . . . . . . . . .  8
-             3.1.5.  Signature Expiration and Inception Fields. . .  9
-             3.1.6.  The Key Tag Field. . . . . . . . . . . . . . .  9
-             3.1.7.  The Signer's Name Field. . . . . . . . . . . .  9
-             3.1.8.  The Signature Field. . . . . . . . . . . . . .  9
-       3.2.  The RRSIG RR Presentation Format . . . . . . . . . . . 10
-       3.3.  RRSIG RR Example . . . . . . . . . . . . . . . . . . . 11
-   4.  The NSEC Resource Record . . . . . . . . . . . . . . . . . . 12
-       4.1.  NSEC RDATA Wire Format . . . . . . . . . . . . . . . . 13
-             4.1.1.  The Next Domain Name Field . . . . . . . . . . 13
-             4.1.2.  The Type Bit Maps Field. . . . . . . . . . . . 13
-             4.1.3.  Inclusion of Wildcard Names in NSEC RDATA. . . 14
-       4.2.  The NSEC RR Presentation Format. . . . . . . . . . . . 14
-       4.3.  NSEC RR Example. . . . . . . . . . . . . . . . . . . . 15
-   5.  The DS Resource Record . . . . . . . . . . . . . . . . . . . 15
-       5.1.  DS RDATA Wire Format . . . . . . . . . . . . . . . . . 16
-             5.1.1.  The Key Tag Field. . . . . . . . . . . . . . . 16
-             5.1.2.  The Algorithm Field. . . . . . . . . . . . . . 16
-             5.1.3.  The Digest Type Field. . . . . . . . . . . . . 17
-             5.1.4.  The Digest Field . . . . . . . . . . . . . . . 17
-       5.2.  Processing of DS RRs When Validating Responses . . . . 17
-       5.3.  The DS RR Presentation Format. . . . . . . . . . . . . 17
-       5.4.  DS RR Example. . . . . . . . . . . . . . . . . . . . . 18
-   6.  Canonical Form and Order of Resource Records . . . . . . . . 18
-       6.1.  Canonical DNS Name Order . . . . . . . . . . . . . . . 18
-       6.2.  Canonical RR Form. . . . . . . . . . . . . . . . . . . 19
-       6.3.  Canonical RR Ordering within an RRset. . . . . . . . . 20
-   7.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . 20
-   8.  Security Considerations. . . . . . . . . . . . . . . . . . . 21
-
-
-
-Arends, et al.              Standards Track                     [Page 2]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
-       10.1. Normative References . . . . . . . . . . . . . . . . . 22
-       10.2. Informative References . . . . . . . . . . . . . . . . 23
-   A.  DNSSEC Algorithm and Digest Types. . . . . . . . . . . . . . 24
-       A.1.  DNSSEC Algorithm Types . . . . . . . . . . . . . . . . 24
-             A.1.1.  Private Algorithm Types. . . . . . . . . . . . 25
-       A.2.  DNSSEC Digest Types. . . . . . . . . . . . . . . . . . 25
-   B.  Key Tag Calculation. . . . . . . . . . . . . . . . . . . . . 25
-       B.1.  Key Tag for Algorithm 1 (RSA/MD5). . . . . . . . . . . 27
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
-   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 29
-
-1.  Introduction
-
-   The DNS Security Extensions (DNSSEC) introduce four new DNS resource
-   record types: DNS Public Key (DNSKEY), Resource Record Signature
-   (RRSIG), Next Secure (NSEC), and Delegation Signer (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
-
-   This document is part of a family of documents defining DNSSEC, which
-   should be read together as a set.
-
-   [RFC4033] contains an introduction to DNSSEC and definition of common
-   terms; the reader is assumed to be familiar with this document.
-   [RFC4033] also contains a list of other documents updated by and
-   obsoleted by this document set.
-
-   [RFC4035] defines the DNSSEC protocol operations.
-
-   The reader is also assumed to be familiar with the basic DNS concepts
-   described in [RFC1034], [RFC1035], and the subsequent documents that
-   update them, particularly [RFC2181] and [RFC2308].
-
-   This document defines the DNSSEC resource records.  All numeric DNS
-   type codes given in this document are decimal integers.
-
-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 [RFC2119].
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 3]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-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 [RFC4035]: A zone signs its authoritative RRsets by
-   using a private key and stores the corresponding public key in a
-   DNSKEY RR.  A resolver can then use the public key to validate
-   signatures covering the RRsets in the zone, and thus to authenticate
-   them.
-
-   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.              Standards Track                     [Page 4]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   intended to be 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 that a DNSKEY RR with the
-   SEP bit set would also need the Zone Key flag set in order to be able
-   to generate signatures legally.  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 receipt.
-
-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 it is 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 is 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,
-   and 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.              Standards Track                     [Page 5]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   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.
-
-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 [RFC4035].  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], which 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.
-
-
-
-
-Arends, et al.              Standards Track                     [Page 6]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   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 RRs 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.
-
-                        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.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 7]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-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 whether 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 have to reconstruct the original owner name in order
-   to validate the signature.  [RFC4035] describes how to use the Labels
-   field to reconstruct the original owner name.
-
-   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 the signature is generated or verified.
-
-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.  [RFC4035]
-   describes how to use the Original TTL field value to reconstruct the
-   original TTL.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 8]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-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.
-
-   The Signature Expiration and Inception field values specify a date
-   and time in the form of 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 that can be expressed by this
-   format without wrapping is approximately 136 years.  An RRSIG RR can
-   have an Expiration field value that 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.
-
-3.1.7.  The Signer's Name Field
-
-   The Signer's Name field value identifies the owner name of the DNSKEY
-   RR that 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:
-
-
-
-Arends, et al.              Standards Track                     [Page 9]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-         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
-               canonical form; and
-
-               The RRset MUST be sorted in canonical order.
-
-   See Sections 6.2 and 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 an 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.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 10]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   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 an unsigned decimal integer indicating 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 hour notation (00-23);
-      mm is the minute (00-59); and
-      SS is the second (00-59).
-
-   Note that it is always possible to distinguish between these two
-   formats because the YYYYMMDDHHmmSS format will always be exactly 14
-   digits, while the decimal representation of a 32-bit unsigned integer
-   can never be longer than 10 digits.
-
-   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:
-
-   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
-
-
-
-
-Arends, et al.              Standards Track                    [Page 11]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   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
-   indicates 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 that this signature
-   can be authenticated using an example.com zone DNSKEY RR whose
-   algorithm is 5 and whose key tag is 2642.
-
-4.  The NSEC Resource Record
-
-   The NSEC resource record lists two separate things: the next owner
-   name (in the canonical ordering of the zone) that contains
-   authoritative data or a delegation point NS RRset, and the set of RR
-   types present at the NSEC RR's owner name [RFC3845].  The complete
-   set of NSEC RRs in a zone indicates 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 [RFC4035].
-
-   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],
-   which 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 does a CNAME resource record in a signed
-   zone.
-
-   See [RFC4035] for discussion of how a zone signer determines
-   precisely which NSEC RRs it has 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]).
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 12]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-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) that 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
-   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 for which the given zone is not authoritative
-   (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 that 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.
-
-
-
-Arends, et al.              Standards Track                    [Page 13]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   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, and 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, as they do not appear
-   in zone data.  If encountered, they MUST be ignored upon being read.
-
-   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
-   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 the purposes of generating NSEC RRs.  Wildcard owner
-   names appear in the Next Domain Name field without any wildcard
-   expansion.  [RFC4035] 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
-   described in [RFC3597], Section 5, MUST be used.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 14]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-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 that 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:
-
-            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 to
-   prove that there is no AAAA record associated with alfa.example.com.
-   Authenticated denial of existence is discussed in [RFC4035].
-
-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
-   [RFC4035].
-
-   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
-
-
-
-Arends, et al.              Standards Track                    [Page 15]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   "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
-   [RFC4035].
-
-   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 1 octet
-   Algorithm field, a 1 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                             /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-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.
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 16]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-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 this 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
-   have Flags bit 7 set.  If the DNSKEY flags do not indicate a DNSSEC
-   zone key, the DS RR (and the 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.
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 17]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   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.
-
-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 in order to construct and verify RRSIG
-   RRs.
-
-6.1.  Canonical DNS Name Order
-
-   For the 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 uppercase
-   US-ASCII letters are treated as if they were lowercase US-ASCII
-   letters.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 18]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   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
-   by 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 the 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;
-
-   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.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 19]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-6.3.  Canonical RR Ordering within an RRset
-
-   For the 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
-   in which 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, it 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), it MUST remove all but one of the duplicate RR(s) for the
-   purposes of calculating the canonical form of the RRset.
-
-7.  IANA Considerations
-
-   This document introduces no new IANA considerations, as 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 that are (or once were) related to DNSSEC.
-
-   Please refer to [RFC4035] 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 to 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 ([RFC3755]).
-      See Appendix A for a full listing of the DNS Security Algorithm
-      Numbers entries at the time of this writing and their status for
-      use in DNSSEC.
-
-
-
-
-Arends, et al.              Standards Track                    [Page 20]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-      [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] reassigned 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 a
-      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 assignments for bit 7 (the ZONE bit)
-      and bit 15 (the Secure Entry Point flag (SEP) bit; see [RFC3757]).
-      As stated in [RFC3755], bits 0-6 and 8-14 are available for
-      assignment by IETF Standards Action.
-
-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 [RFC4033] and [RFC4035] for
-   additional security considerations related to the use of these
-   records.
-
-   The DS record points to a DNSKEY RR by 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 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 that 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 that uses only the key tag to select a DNSKEY RR
-   might select the wrong public key in some circumstances.  Please see
-   Appendix B for further details.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 21]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   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].
-
-9.  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.  Although explicitly listing everyone who has
-   contributed during the decade in which DNSSEC has been under
-   development would be impossible, [RFC4033] includes a list of some of
-   the participants who were kind enough to comment on these documents.
-
-10.  References
-
-10.1.  Normative References
-
-   [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.
-
-   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
-              NCACHE)", RFC 2308, March 1998.
-
-   [RFC2536]  Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name
-              System (DNS)", RFC 2536, March 1999.
-
-   [RFC2931]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
-              ( SIG(0)s )", RFC 2931, September 2000.
-
-   [RFC3110]  Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the
-              Domain Name System (DNS)", RFC 3110, May 2001.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 22]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   [RFC3445]  Massey, D. and S. Rose, "Limiting the Scope of the KEY
-              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 (DS)", RFC 3755, May 2004.
-
-   [RFC3757]  Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name
-              System KEY (DNSKEY) Resource Record (RR) Secure Entry
-              Point (SEP) Flag", RFC 3757, April 2004.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements", RFC
-              4033, March 2005.
-
-   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Protocol Modifications for the DNS Security
-              Extensions", RFC 4035, March 2005.
-
-10.2.  Informative References
-
-   [RFC2535]  Eastlake 3rd, D., "Domain Name System Security
-              Extensions", RFC 2535, March 1999.
-
-   [RFC2537]  Eastlake 3rd, D., "RSA/MD5 KEYs and SIGs in the Domain
-              Name System (DNS)", RFC 2537, March 1999.
-
-   [RFC2539]  Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the
-              Domain Name System (DNS)", RFC 2539, March 1999.
-
-   [RFC2930]  Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
-              RR)", RFC 2930, September 2000.
-
-   [RFC3845]  Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)
-              RDATA Format", RFC 3845, August 2004.
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 23]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-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 them.
-
-   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 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      [RFC2537]  NOT RECOMMENDED
-     2   Diffie-Hellman [DH]      n      [RFC2539]   -
-     3   DSA/SHA-1 [DSA]          y      [RFC2536]  OPTIONAL
-     4   Elliptic Curve [ECC]              TBA       -
-     5   RSA/SHA-1 [RSASHA1]      y      [RFC3110]  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.
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 24]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-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
-   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                 -
-
-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.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 25]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-   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.
-
-   /*
-    * 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;
-   }
-
-
-
-Arends, et al.              Standards Track                    [Page 26]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-B.1.  Key Tag for Algorithm 1 (RSA/MD5)
-
-   The key tag for algorithm 1 (RSA/MD5) is defined differently from 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.              Standards Track                    [Page 27]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-Authors' Addresses
-
-   Roy Arends
-   Telematica Instituut
-   Brouwerijstraat 1
-   7523 XC  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
-   Colorado State University
-   Department of Computer Science
-   Fort Collins, CO 80523-1873
-
-   EMail: massey@cs.colostate.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.              Standards Track                    [Page 28]
-
-RFC 4034                DNSSEC Resource Records               March 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   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.
-
-Intellectual Property
-
-   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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 29]
-
diff --git a/contrib/bind9/doc/rfc/rfc4035.txt b/contrib/bind9/doc/rfc/rfc4035.txt
deleted file mode 100644
index b701cd2..0000000
--- a/contrib/bind9/doc/rfc/rfc4035.txt
+++ /dev/null
@@ -1,2971 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          R. Arends
-Request for Comments: 4035                          Telematica Instituut
-Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658,                R. Austein
-           3755, 3757, 3845                                          ISC
-Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
-         3007, 3597, 3226                                       VeriSign
-Category: Standards Track                                      D. Massey
-                                               Colorado State University
-                                                                 S. Rose
-                                                                    NIST
-                                                              March 2005
-
-
-         Protocol Modifications for the DNS Security Extensions
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document is part of a family of documents that describe the DNS
-   Security Extensions (DNSSEC).  The DNS Security Extensions are a
-   collection of new resource records and protocol modifications that
-   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 by 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.
-
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 1]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
-       1.1.  Background and Related Documents . . . . . . . . . . . .  4
-       1.2.  Reserved Words . . . . . . . . . . . . . . . . . . . . .  4
-   2.  Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . .  4
-       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  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
-       3.1.  Authoritative Name Servers . . . . . . . . . . . . . . .  9
-             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 . . . . . . . . . . . . . . . . 19
-   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 . . . . . . . . . . . . . . . . 21
-       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 . . . . . . . . . . . . . 24
-             4.9.2.  Handling of the CD Bit . . . . . . . . . . . . . 24
-             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 with an RRSIG RR . . . . . . . . 28
-             5.3.1.  Checking the RRSIG RR Validity . . . . . . . . . 28
-             5.3.2.  Reconstructing the Signed Data . . . . . . . . . 29
-             5.3.3.  Checking the Signature . . . . . . . . . . . . . 31
-             5.3.4.  Authenticating a Wildcard Expanded RRset
-                     Positive Response. . . . . . . . . . . . . . . . 32
-
-
-
-Arends, et al.              Standards Track                     [Page 2]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-       5.4.  Authenticated Denial of Existence  . . . . . . . . . . . 32
-       5.5.  Resolver Behavior When Signatures Do Not Validate  . . . 33
-       5.6.  Authentication Example . . . . . . . . . . . . . . . . . 33
-   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33
-   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 33
-   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
-   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
-       9.1.  Normative References . . . . . . . . . . . . . . . . . . 34
-       9.2.  Informative References . . . . . . . . . . . . . . . . . 35
-   A.  Signed Zone Example  . . . . . . . . . . . . . . . . . . . . . 36
-   B.  Example Responses  . . . . . . . . . . . . . . . . . . . . . . 41
-       B.1.  Answer . . . . . . . . . . . . . . . . . . . . . . . . . 41
-       B.2.  Name Error . . . . . . . . . . . . . . . . . . . . . . . 43
-       B.3.  No Data Error  . . . . . . . . . . . . . . . . . . . . . 44
-       B.4.  Referral to Signed Zone  . . . . . . . . . . . . . . . . 44
-       B.5.  Referral to Unsigned Zone  . . . . . . . . . . . . . . . 45
-       B.6.  Wildcard Expansion . . . . . . . . . . . . . . . . . . . 46
-       B.7.  Wildcard No Data Error . . . . . . . . . . . . . . . . . 47
-       B.8.  DS Child Zone No Data Error  . . . . . . . . . . . . . . 48
-   C.  Authentication Examples  . . . . . . . . . . . . . . . . . . . 49
-       C.1.  Authenticating an Answer . . . . . . . . . . . . . . . . 49
-             C.1.1.  Authenticating the Example DNSKEY RR . . . . . . 49
-       C.2.  Name Error . . . . . . . . . . . . . . . . . . . . . . . 50
-       C.3.  No Data Error  . . . . . . . . . . . . . . . . . . . . . 50
-       C.4.  Referral to Signed Zone  . . . . . . . . . . . . . . . . 50
-       C.5.  Referral to Unsigned Zone  . . . . . . . . . . . . . . . 51
-       C.6.  Wildcard Expansion . . . . . . . . . . . . . . . . . . . 51
-       C.7.  Wildcard No Data Error . . . . . . . . . . . . . . . . . 51
-       C.8.  DS Child Zone No Data Error  . . . . . . . . . . . . . . 51
-   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
-   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53
-
-1.  Introduction
-
-   The DNS Security Extensions (DNSSEC) are a collection of new resource
-   records and protocol modifications that 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 for handling signed zones.  Section 4
-   describes the behavior of entities that include security-aware
-   resolver functions.  Finally, Section 5 defines how to use DNSSEC RRs
-   to authenticate a response.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 3]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-1.1.  Background and Related Documents
-
-   This document is part of a family of documents defining DNSSEC that
-   should be read together as a set.
-
-   [RFC4033] contains an introduction to DNSSEC and definitions of
-   common terms; the reader is assumed to be familiar with this
-   document.  [RFC4033] also contains a list of other documents updated
-   by and obsoleted by this document set.
-
-   [RFC4034] defines the DNSSEC resource records.
-
-   The reader is also assumed to be familiar with the basic DNS concepts
-   described in [RFC1034], [RFC1035], and the subsequent documents that
-   update them; particularly, [RFC2181] and [RFC2308].
-
-   This document defines the DNSSEC protocol operations.
-
-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 [RFC2119].
-
-2.  Zone Signing
-
-   DNSSEC introduces the concept of signed zones.  A signed zone
-   includes DNS Public Key (DNSKEY), Resource Record Signature (RRSIG),
-   Next Secure (NSEC), and (optionally) Delegation Signer (DS) records
-   according to the rules specified in Sections 2.1, 2.2, 2.3, and 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 does 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.
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 4]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-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 [RFC4034]).  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
-   [RFC4034]).
-
-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 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
-      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.
-
-   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 [RFC4034].  An RRset MAY have multiple RRSIG RRs
-   associated with it.  Note that as RRSIG RRs are closely tied to the
-   RRsets whose signatures they contain, RRSIG RRs, unlike all other DNS
-
-
-
-Arends, et al.              Standards Track                     [Page 5]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   RR types, do not form RRsets.  In particular, the TTL values among
-   RRSIG RRs with a common owner name do not follow the RRset rules
-   described in [RFC2181].
-
-   An RRSIG RR itself MUST NOT be signed, as 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 that 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 [RFC4034].
-
-   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 name nodes that 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.
-
-   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
-
-
-
-Arends, et al.              Standards Track                     [Page 6]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   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
-   visible only during the zone signing process, as NSEC RRsets are
-   authoritative data and are therefore signed.  Thus, any owner name
-   that 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 that is present in the child's
-   apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
-   by the corresponding private key.  DS RRs that fail to meet these
-   conditions are not useful for validation, but because the DS RR and
-   its corresponding DNSKEY RR are in different zones, and because the
-   DNS is only loosely consistent, temporary mismatches can occur.
-
-   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 ([RFC3007]).
-   Other types MUST NOT be present at that name.
-
-   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
-
-
-
-Arends, et al.              Standards Track                     [Page 7]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   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 seeks 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.
-
-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.
-
-   In the following discussion, the terms "SNAME", "SCLASS", and "STYPE"
-   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.  As IPv6
-   packets can only be fragmented by the source host, a security aware
-   name server SHOULD take steps to ensure that UDP datagrams it
-   transmits over IPv6 are fragmented, if necessary, at the minimum IPv6
-   MTU, unless the path MTU is known.  Please see [RFC1122], [RFC2460],
-   and [RFC3226] for further discussion of packet size and fragmentation
-   issues.
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 8]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   A security-aware name server that 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.
-   Because 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 that 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.  As long as the response is always
-   consistent for each query to the name server, 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.
-
-   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 Sections 3.1.6,
-   3.2.2, 3.2.3, 4, and 4.9 for details on the behavior of these bits.
-
-   A security aware name server that 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.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                     [Page 9]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   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 where the semantics 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 have 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 have 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
-      associated RRSIG RRs, the name server MAY retain the RRset while
-      dropping the RRSIG RRs.  If this happens, the name server MUST NOT
-      set the TC bit solely because these RRSIG RRs didn't fit.
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 10]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-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 does
-   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> and 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 in the zone.
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 11]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-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 that 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>.
-
-   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.  If
-   it does, 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
-   that is not the owner name for any RRset but that 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 that exactly match <SNAME,
-   SCLASS> but does contain an RRset that matches <SNAME, SCLASS, STYPE>
-   via wildcard name expansion, the name server MUST include the
-
-
-
-Arends, et al.              Standards Track                    [Page 12]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   wildcard-expanded answer and the corresponding wildcard-expanded
-   RRSIG RRs in the Answer section and MUST include in the Authority
-   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 although the zone
-   does contain RRsets that match <SNAME, SCLASS> via wildcard
-   expansion, none of those RRsets matches 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 that matched <SNAME, SCLASS> via wildcard
-      expansion.
-
-   o  An NSEC RR proving that there are no RRsets in the zone that would
-      have been a closer match for <SNAME, SCLASS>.
-
-   In some cases, a single NSEC RR may prove both of these points.  If
-   it does, 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 has to locate an NSEC RR
-   that 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 that would have held
-   the non-existent RRsets matching SNAME.  The algorithm below is
-   written for clarity, not for efficiency.
-
-   To find the NSEC that proves that no RRsets matching name N exist in
-   the zone Z that would have held them, construct a sequence, S,
-   consisting of the owner names of every RRset in Z, sorted into
-
-
-
-Arends, et al.              Standards Track                    [Page 13]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   canonical order ([RFC4034]), with no duplicate names.  Find the name
-   M that 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 that
-   proves that no RRsets exist with owner name N.
-
-   The algorithm for finding the NSEC RR that 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 that
-   proves that RRsets with any other owner name do not exist.  The part
-   that's missing is a method of determining the name of the non-
-   existent 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 that 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.
-
-   If no DS RRset is present at the delegation point, the name server
-   MUST return both the NSEC RR that 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, as 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.
-
-
-
-Arends, et al.              Standards Track                    [Page 14]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   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).
-   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.
-
-   o  The name server is authoritative for the child zone.
-
-   o  The name server is not authoritative for the parent zone.
-
-   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 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 to meet 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
-
-
-
-Arends, et al.              Standards Track                    [Page 15]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   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
-   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, as the NSEC RR in the child zone's apex will always indicate
-   the presence of the child zone's SOA RR whereas 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 in zone transfers of
-   the parent zone, and 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, and 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, as 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 whereas 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.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 16]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   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.  However, 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 NOT do so unless this behavior has been
-   configured explicitly.
-
-   A security-aware name server that 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 [RFC4033], a security-aware recursive name server is
-   an entity that 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 that implements the
-   security-aware name server role and the code that implements the
-   security-aware resolver role, respectively.
-
-   The resolver side follows the usual rules for caching and negative
-   caching that 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 state of the CD bit to the resolver side along with the rest
-
-
-
-Arends, et al.              Standards Track                    [Page 17]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   of an initiating query, so that the resolver side will know whether
-   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, 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 that matches an entry in the
-   resolver side's BAD cache, the name server side's response depends on
-   the state 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
-   that are capable of performing their own signature verification
-   checks while protecting clients that 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 that may not apply equally to the recursive name server
-   and the client that 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 that the recursive name
-   server does not share.  In such cases, "protecting" a client that 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 backward compatibility, a recursive name server MAY set
-   the AD bit when a response includes unsigned CNAME RRs if those CNAME
-
-
-
-
-Arends, et al.              Standards Track                    [Page 18]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   RRs demonstrably could have been synthesized from an authentic DNAME
-   RR that 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.
-
-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
-   use the "sender's UDP payload size" field in the EDNS OPT pseudo-RR
-   to advertise the message size that it is willing to accept.  A
-   security-aware resolver's IP layer MUST handle fragmented UDP packets
-   correctly regardless of whether any such fragmented packets were
-   received via IPv4 or IPv6.  Please see [RFC1122], [RFC2460], and
-   [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 that instructed the security-aware
-      resolver not to perform validation for this query; or
-
-   o  validation for this query has been disabled by local policy.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 19]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   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.  For example, a zone update may have
-   changed (or deleted) the desired information between the original and
-   follow-up queries.
-
-   When attempting to retrieve missing NSEC RRs that 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
-   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 off 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 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.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 20]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   Bogus: An RRset for which the resolver believes that it ought to be
-      able to establish a chain of trust but for which it is unable to
-      do so, either due to signatures that for some reason fail to
-      validate or due to missing data that 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 the RRset should be signed, as 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
-   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 cover 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).
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 21]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   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 that follow this
-   recommendation will have a more consistent view of the namespace.
-
-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 that blindly copy
-   header bits that 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 by 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.
-
-
-
-Arends, et al.              Standards Track                    [Page 22]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   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 that implement a BAD cache MUST take steps to prevent the
-   cache from being useful as a denial-of-service attack amplifier,
-   particularly the following:
-
-   o  Since RRsets that 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.
-
-   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 that 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.
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 23]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-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 that
-   invoked it, but is not required to do so.  A non-validating stub
-   resolver that seeks to do this will need to set the DO bit in order
-   to receive DNSSEC RRs from the recursive name server.
-
-   A validating security-aware stub resolver MUST set the DO bit,
-   because 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 it is requested by the application
-   layer, as 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,
-   because 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 that would be
-   acceptable to the stub resolver's local policy.
-
-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
-   that 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.  Therefore, there may be little
-   practical value in 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, as, by definition, the
-   stub resolver performs its own signature validation regardless of the
-   setting of the AD bit.
-
-
-
-Arends, et al.              Standards Track                    [Page 24]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-5.  Authenticating DNS Responses
-
-   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 anchor 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 to 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 by using an initial key,
-   the resolver MUST:
-
-   1.  verify that the initial DNSKEY RR appears in the apex DNSKEY
-       RRset, and that the DNSKEY RR has the Zone Key Flag (DNSKEY RDATA
-       bit 7) set; and
-
-   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 by using an
-   initial DNSKEY RR, delegations from that zone can be authenticated by
-   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.
-
-   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 once the resolver has authenticated a zone's apex
-   DNSKEY RRset.  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
-   lacks the appropriate DNSSEC RRs, whether due to configuration issues
-   such as an upstream security-oblivious recursive name server that
-
-
-
-Arends, et al.              Standards Track                    [Page 25]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   accidentally interferes with DNSSEC RRs or due to a deliberate attack
-   in which an adversary forges a response, strips DNSSEC RRs 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 [RFC4033]) 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 that the validator 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.  Use of a strong cryptographic digest
-   algorithm ensures that it is computationally infeasible for an
-   adversary to 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).
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 26]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   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 the DNSKEY RR's owner name and RDATA are hashed
-      using the digest algorithm specified in the DS RR's Digest Type
-      field, the resulting digest value matches the Digest field of the
-      DS RR.
-
-   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 cannot 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 because 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.
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 27]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   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 with 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
-   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.  Sections 5.3.1, 5.3.2,
-   and 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.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 28]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   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, and it 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
-   Section 5.3.1, the validator has 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
-
-
-
-
-Arends, et al.              Standards Track                    [Page 29]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-               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
-                  RRset.
-
-   The canonical forms for names and RRsets are defined in [RFC4034].
-
-   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
-   RRsets 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 as only a child NSEC RR will indicate that 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.  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 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.
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 30]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-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).  [RFC4034]
-   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 is correct by trying each matching public
-   key until the validator either succeeds in validating the signature
-   or runs out of keys to try.
-
-   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 has to test these RRSIG
-   RRs and 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.
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 31]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-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
-      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 [RFC4034], 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 the 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
-
-
-
-Arends, et al.              Standards Track                    [Page 32]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   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 the 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.  Also see Section
-   4.7 on caching responses that do not validate.
-
-5.6.  Authentication Example
-
-   Appendix C shows an example of the authentication process.
-
-6.  IANA Considerations
-
-   [RFC4034] contains a review of the IANA considerations introduced by
-   DNSSEC.  The following are 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.
-
-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 [RFC4033] for terminology and general security
-   considerations related to DNSSEC; see [RFC4034] for considerations
-   specific to the DNSSEC resource record types.
-
-
-
-
-Arends, et al.              Standards Track                    [Page 33]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   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 that 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 Sections 3.2.2 and 4.9 for further discussion.
-
-   The protocol described in this document attempts to extend the
-   benefits of DNSSEC to security-oblivious stub resolvers.  However, as
-   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 have to pay close attention to the
-   behavior of the applications that 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.
-
-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.  Although explicitly listing everyone who has
-   contributed during the decade in which DNSSEC has been under
-   development would be impossible, [RFC4033] includes a list of some of
-   the participants who were kind enough to comment on these documents.
-
-9.  References
-
-9.1.  Normative References
-
-   [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.
-
-   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
-              Communication Layers", STD 3, RFC 1122, October 1989.
-
-   [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.
-
-
-
-
-Arends, et al.              Standards Track                    [Page 34]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
-              (IPv6) Specification", RFC 2460, December 1998.
-
-   [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.
-
-   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "DNS Security Introduction and Requirements", RFC
-              4033, March 2005.
-
-   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
-              Rose, "Resource Records for DNS Security Extensions", RFC
-              4034, March 2005.
-
-9.2.  Informative References
-
-   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
-              NCACHE)", RFC 2308, March 1998.
-
-   [RFC2535]  Eastlake 3rd, D., "Domain Name System Security
-              Extensions", RFC 2535, March 1999.
-
-   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
-              Update", RFC 3007, November 2000.
-
-   [RFC3655]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS
-              Authenticated Data (AD) bit", RFC 3655, November 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 35]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-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.              Standards Track                    [Page 36]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-                              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.              Standards Track                    [Page 37]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-                              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.              Standards Track                    [Page 38]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-                              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.              Standards Track                    [Page 39]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-                              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.              Standards Track                    [Page 40]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-                              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 that 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.
-
-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
-
-
-
-Arends, et al.              Standards Track                    [Page 41]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-                              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
-                              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= )
-
-
-
-
-Arends, et al.              Standards Track                    [Page 42]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-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
-                              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)
-
-
-
-
-Arends, et al.              Standards Track                    [Page 43]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-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.
-
-   ;; 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.
-
-   ;; Header: QR DO RCODE=0
-   ;;
-
-
-
-Arends, et al.              Standards Track                    [Page 44]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   ;; 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.
-
-   ;; 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= )
-
-
-
-Arends, et al.              Standards Track                    [Page 45]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   ;; 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 that 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
-   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 (
-
-
-
-Arends, et al.              Standards Track                    [Page 46]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-                              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
-
-   ;; 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
-
-
-
-Arends, et al.              Standards Track                    [Page 47]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-                              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 that was mistakenly sent to
-   a name server for the child zone.
-
-   ;; 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
-
-
-
-Arends, et al.              Standards Track                    [Page 48]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-                              FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
-                              Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
-                              SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
-                              jfFJ5arXf4nPxp/kEowGgBRzY/U= )
-
-   ;; Additional
-   ;; (empty)
-
-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 Appendix B.1 returned an MX RRset for "x.w.example.com".
-   The corresponding RRSIG indicates that 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 that 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 that the
-   logical order is presented for clarity.  An implementation may choose
-   to construct the authentication as referrals are received or 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 a configured DNSKEY RR for the
-   root zone (or a configured DS RR for the root zone).  The resolver
-   checks whether this configured DNSKEY RR is present in the root
-   DNSKEY RRset (or whether the DS RR matches some DNSKEY in the root
-   DNSKEY RRset), whether this DNSKEY RR has signed the root DNSKEY
-   RRset, and whether the signature lifetime is valid.  If all these
-
-
-
-Arends, et al.              Standards Track                    [Page 49]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   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 that the
-   resolver may have 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
-   matching "example" DNSKEY is found, the resolver checks whether this
-   DNSKEY RR has signed the "example" DNSKEY RRset and the signature
-   lifetime is valid.  If 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 authenticate 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 validate the signature as described above.
-
-C.2.  Name Error
-
-   The query in Appendix B.2 returned NSEC RRs that prove that 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 Appendix B.3 returned an NSEC RR that proves that 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 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 whether
-
-
-
-Arends, et al.              Standards Track                    [Page 50]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-   this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether
-   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 Appendix B.5 returned a referral to an unsigned
-   "b.example." zone.  The NSEC proves that no authentication leads from
-   "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 Appendix B.6 returned an answer that was produced as a
-   result of wildcard expansion.  The answer section contains a wildcard
-   RRset expanded as it would be in a traditional DNS response, and the
-   corresponding RRSIG indicates that the expanded wildcard MX RRset was
-   signed by an "example" DNSKEY with algorithm 5 and key tag 38519.
-   The RRSIG indicates that 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 that the answer
-   is the result of wildcard expansion, as 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 that 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 Appendix B.7 returned NSEC RRs that prove that 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 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 that the answer is from
-   the child .  Queries for the "example" DS RRset should be sent to the
-   parent servers ("root" servers).
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 51]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-Authors' Addresses
-
-   Roy Arends
-   Telematica Instituut
-   Brouwerijstraat 1
-   7523 XC  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
-   Colorado State University
-   Department of Computer Science
-   Fort Collins, CO 80523-1873
-
-   EMail: massey@cs.colostate.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.              Standards Track                    [Page 52]
-
-RFC 4035             DNSSEC Protocol Modifications            March 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   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.
-
-Intellectual Property
-
-   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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Arends, et al.              Standards Track                    [Page 53]
-
diff --git a/contrib/bind9/doc/rfc/rfc4074.txt b/contrib/bind9/doc/rfc/rfc4074.txt
deleted file mode 100644
index d9252b3..0000000
--- a/contrib/bind9/doc/rfc/rfc4074.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       Y. Morishita
-Request for Comments: 4074                                          JPRS
-Category: Informational                                        T. Jinmei
-                                                                 Toshiba
-                                                                May 2005
-
-
-       Common Misbehavior Against DNS Queries for IPv6 Addresses
-
-Status of This Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   There is some known misbehavior of DNS authoritative servers when
-   they are queried for AAAA resource records.  Such behavior can block
-   IPv4 communication that should actually be available, cause a
-   significant delay in name resolution, or even make a denial of
-   service attack.  This memo describes details of known cases and
-   discusses their effects.
-
-1.  Introduction
-
-   Many existing DNS clients (resolvers) that support IPv6 first search
-   for AAAA Resource Records (RRs) of a target host name, and then for A
-   RRs of 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 reach.
-   In the following sections, this memo describes some typical cases of
-   such 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 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, so the problem for the other cases is
-   relatively minor.
-
-
-
-Morishita & Jinmei           Informational                      [Page 1]
-
-RFC 4074         Common Misbehavior Against DNS Queries         May 2005
-
-
-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 and 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 has no AAAA RR
-   for a host name.  Then, the server should return a response to a
-   query for an AAAA RR of the name with the response code (RCODE) being
-   0 (indicating no error) and with an empty answer section (see
-   Sections 4.3.2 and 6.2.4 of [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
-   has no AAAA RR (but may have other types of RRs), and thus improve
-   the response time to further queries for an 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.
-
-4.1.  Ignore Queries for AAAA
-
-   Some authoritative servers seem to ignore queries for an AAAA RR,
-   causing a delay at the stub resolver to fall back to a query for an A
-   RR.  This behavior may cause a fatal timeout at the resolver or at
-   the application that calls the resolver.  Even if the resolver
-   eventually falls back, the result can be an unacceptable delay for
-   the application user, especially with interactive applications like
-   web browsing.
-
-4.2.  Return "Name Error"
-
-   This type of server returns a response with RCODE 3 ("Name Error") to
-   a query for an AAAA RR, indicating that it does not have any RRs of
-   any type for the queried name.
-
-
-
-
-Morishita & Jinmei           Informational                      [Page 2]
-
-RFC 4074         Common Misbehavior Against DNS Queries         May 2005
-
-
-   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 to be a
-   fatal error in name resolution.
-
-   Several examples of this behavior are known to the authors.  As of
-   this writing, all have been fixed.
-
-4.3.  Return Other Erroneous Codes
-
-   Other authoritative servers return a response with erroneous response
-   codes other than RCODE 3 ("Name Error").  One such RCODE is 4 ("Not
-   Implemented"), indicating that the servers do not support the
-   requested type of query.
-
-   These cases are 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.
-
-   However, these can still cause a serious effect.  There was an
-   authoritative server implementation that returned RCODE 2 ("Server
-   failure") to queries for AAAA RRs.  One widely deployed mail server
-   implementation with a certain type of resolver library interpreted
-   this result as an indication of retry and did not fall back to
-   queries for A RRs, causing message delivery failure.
-
-   If the caching server receives a response with these response codes,
-   it 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 RCODE 1 ("Format error") would cause a similar effect, though
-   the authors have not seen such implementations yet.
-
-4.4.  Return a Broken Response
-
-   Another type of authoritative servers returns broken responses to
-   AAAA queries.  Returning a response whose RR type is AAAA with the
-   length of the RDATA being 4 bytes is a known behavior of this
-   category.  The 4-byte data looks like the IPv4 address of the queried
-   host name.
-
-
-
-
-
-
-
-Morishita & Jinmei           Informational                      [Page 3]
-
-RFC 4074         Common Misbehavior Against DNS Queries         May 2005
-
-
-   That is, the RR in the answer section would be described as follows:
-
-     www.bad.example. 600 IN AAAA 192.0.2.1
-
-   which is, of course, bogus (or at least meaningless).
-
-   A widely deployed caching server implementation transparently returns
-   the broken response (and caches it) to the stub resolver.  Another
-   known server implementation parses the response by itself, and sends
-   a separate response with RCODE 2 ("Server failure").
-
-   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.5.  Make Lame Delegation
-
-   Some authoritative servers respond to AAAA queries in a way that
-   causes lame delegation.  In this case, the parent zone specifies that
-   the authoritative server should have the authority of a zone, but the
-   server should 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 returns a response with RCODE
-   2 ("Server failure") 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 RCODE 2, since all the servers are known to be "lame."
-
-   There is also an implementation that relaxes the behavior a little
-   bit.  It tries to avoid using the lame server, but 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 Server
-   failure.  However, this still causes redundant AAAA queries, as
-   explained in the previous sections.
-
-
-
-
-
-
-
-Morishita & Jinmei           Informational                      [Page 4]
-
-RFC 4074         Common Misbehavior Against DNS Queries         May 2005
-
-
-5.  Security Considerations
-
-   The CERT/CC pointed out that the response with RCODE 3 ("Name
-   Error"), described in Section 4.2, can be used for a denial of
-   service attack [2].  The same argument applies to the case of "lame
-   delegation", described in Section 4.5, with a certain type of caching
-   server.
-
-6.  Acknowledgements
-
-   Erik Nordmark encouraged the authors to publish this document as an
-   RFC.  Akira Kato and Paul Vixie reviewed a preliminary version of
-   this document.  Pekka Savola carefully reviewed a previous version
-   and provided detailed comments.  Bill Fenner, Scott Hollenbeck,
-   Thomas Narten, and Alex Zinin reviewed and helped improve the
-   document at the last stage for publication.
-
-7.  Informative References
-
-   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
-        13, 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 Services Co.,Ltd.
-   Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
-   Chiyoda-ku, Tokyo  101-0065
-   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
-
-
-
-
-
-
-
-Morishita & Jinmei           Informational                      [Page 5]
-
-RFC 4074         Common Misbehavior Against DNS Queries         May 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   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.
-
-Intellectual Property
-
-   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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Morishita & Jinmei           Informational                      [Page 6]
-
diff --git a/contrib/bind9/doc/rfc/rfc4159.txt b/contrib/bind9/doc/rfc/rfc4159.txt
deleted file mode 100644
index 1ab4bd1..0000000
--- a/contrib/bind9/doc/rfc/rfc4159.txt
+++ /dev/null
@@ -1,171 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          G. Huston
-Request for Comments: 4159                                         APNIC
-BCP: 109                                                     August 2005
-Category: Best Current Practice
-
-
-                        Deprecation of "ip6.int"
-
-Status of This Memo
-
-   This document specifies an Internet Best Current Practices for the
-   Internet Community, and requests discussion and suggestions for
-   improvements.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document advises of the deprecation of the use of "ip6.int" for
-   Standards Conformant IPv6 implementations.
-
-1.  IPv6 Standards Action
-
-   In August 2001 the IETF published [RFC3152], which advised that the
-   use of "ip6.int" as the domain for reverse-mapping of IPv6 addresses
-   to DNS names was deprecated.  The document noted that the use of
-   "ip6.int" would be phased out in an orderly fashion.
-
-   As of 1 September 2005, the IETF advises the community that the DNS
-   domain "ip6.int" should no longer be used to perform reverse mapping
-   of IPv6 addresses to domain names, and that the domain "ip6.arpa"
-   should be used henceforth, in accordance with the IANA Considerations
-   described in [RFC3596].  The domain "ip6.int" is deprecated, and its
-   use in IPv6 implementations that conform to the IPv6 Internet
-   Standards is discontinued.
-
-   The Regional Internet Registries (RIRs) are advised that maintenance
-   of delegation of entries in "ip6.int" is no longer required as part
-   of infrastructure services in support of Internet Standards
-   Conformant IPv6 implementations as of 1 September 2005.  The RIRs are
-   requested to work with their communities to adopt a schedule
-   regarding the cessation of support of registration services for the
-   "ip6.int" domain.
-
-
-
-
-
-
-Huston                   Best Current Practice                  [Page 1]
-
-RFC 4159                        ip6.int                      August 2005
-
-
-2.  IANA Considerations
-
-   IANA is advised that the "ip6.int" domain for reverse mapping of IPv6
-   addresses to domain names is no longer part of Internet Standards
-   Conformant support of IPv6 as of 1 September 2005.
-
-3.  Security Considerations
-
-   While DNS spoofing of address to name mapping has been exploited in
-   IPv4, removal of the "ip6.int" zone from the standard IPv6
-   specification creates no new threats to the security of the internet.
-
-4.  Acknowledgements
-
-   The document was prepared with the assistance of Kurt Lindqvist,
-   Thomas Narten, Paul Wilson, David Kessens, Bob Hinden, Brian
-   Haberman, and Bill Manning.
-
-5.  Normative References
-
-   [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
-             August 2001.
-
-   [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS
-             Extensions to Support IP Version 6", RFC 3596, October
-             2003.
-
-Author's Address
-
-   Geoff Huston
-   APNIC
-
-   EMail: gih@apnic.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Huston                   Best Current Practice                  [Page 2]
-
-RFC 4159                        ip6.int                      August 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   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.
-
-Intellectual Property
-
-   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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Huston                   Best Current Practice                  [Page 3]
-
diff --git a/contrib/bind9/doc/rfc/rfc4193.txt b/contrib/bind9/doc/rfc/rfc4193.txt
deleted file mode 100644
index 17e2c0b..0000000
--- a/contrib/bind9/doc/rfc/rfc4193.txt
+++ /dev/null
@@ -1,899 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          R. Hinden
-Request for Comments: 4193                                         Nokia
-Category: Standards Track                                    B. Haberman
-                                                                 JHU-APL
-                                                            October 2005
-
-
-                  Unique Local IPv6 Unicast Addresses
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2005).
-
-Abstract
-
-   This document defines an IPv6 unicast address format that is globally
-   unique and is intended for local communications, usually inside of a
-   site.  These addresses are not expected to be routable on the global
-   Internet.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. Acknowledgements ................................................3
-   3. Local IPv6 Unicast Addresses ....................................3
-      3.1. Format .....................................................3
-           3.1.1. Background ..........................................4
-      3.2. Global ID ..................................................4
-           3.2.1. Locally Assigned Global IDs .........................5
-           3.2.2. Sample Code for Pseudo-Random Global ID Algorithm ...5
-           3.2.3. Analysis of the Uniqueness of Global IDs ............6
-      3.3. Scope Definition ...........................................6
-   4. Operational Guidelines ..........................................7
-      4.1. Routing ....................................................7
-      4.2. Renumbering and Site Merging ...............................7
-      4.3. Site Border Router and Firewall Packet Filtering ...........8
-      4.4. DNS Issues .................................................8
-      4.5. Application and Higher Level Protocol Issues ...............9
-      4.6. Use of Local IPv6 Addresses for Local Communication ........9
-      4.7. Use of Local IPv6 Addresses with VPNs .....................10
-
-
-
-Hinden & Haberman           Standards Track                     [Page 1]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-   5. Global Routing Considerations ..................................11
-      5.1. From the Standpoint of the Internet .......................11
-      5.2. From the Standpoint of a Site .............................11
-   6. Advantages and Disadvantages ...................................12
-      6.1. Advantages ................................................12
-      6.2. Disadvantages .............................................13
-   7. Security Considerations ........................................13
-   8. IANA Considerations ............................................13
-   9. References .....................................................13
-      9.1. Normative References ......................................13
-      9.2. Informative References ....................................14
-
-1.  Introduction
-
-   This document defines an IPv6 unicast address format that is globally
-   unique and is intended for local communications [IPV6].  These
-   addresses are called Unique Local IPv6 Unicast Addresses and are
-   abbreviated in this document as Local IPv6 addresses.  They are not
-   expected to be routable on the global Internet.  They are routable
-   inside of a more limited area such as a site.  They may also be
-   routed between a limited set of sites.
-
-   Local IPv6 unicast addresses have the following characteristics:
-
-      - Globally unique prefix (with high probability of uniqueness).
-
-      - Well-known prefix to allow for easy filtering at site
-        boundaries.
-
-      - Allow sites to be combined or privately interconnected without
-        creating any address conflicts or requiring renumbering of
-        interfaces that use these prefixes.
-
-      - Internet Service Provider independent and can be used for
-        communications inside of a site without having any permanent or
-        intermittent Internet connectivity.
-
-      - If accidentally leaked outside of a site via routing or DNS,
-        there is no conflict with any other addresses.
-
-      - In practice, applications may treat these addresses like global
-        scoped addresses.
-
-   This document defines the format of Local IPv6 addresses, how to
-   allocate them, and usage considerations including routing, site
-   border routers, DNS, application support, VPN usage, and guidelines
-   for how to use for local communication inside a site.
-
-
-
-
-Hinden & Haberman           Standards Track                     [Page 2]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-   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].
-
-2.  Acknowledgements
-
-   The underlying idea of creating Local IPv6 addresses described in
-   this document has been proposed a number of times by a variety of
-   people.  The authors of this document do not claim exclusive credit.
-   Credit goes to Brian Carpenter, Christian Huitema, Aidan Williams,
-   Andrew White, Charlie Perkins, and many others.  The authors would
-   also like to thank Brian Carpenter, Charlie Perkins, Harald
-   Alvestrand, Keith Moore, Margaret Wasserman, Shannon Behrens, Alan
-   Beard, Hans Kruse, Geoff Huston, Pekka Savola, Christian Huitema, Tim
-   Chown, Steve Bellovin, Alex Zinin, Tony Hain, Bill Fenner, Sam
-   Hartman, and Elwyn Davies for their comments and suggestions on this
-   document.
-
-3.  Local IPv6 Unicast Addresses
-
-3.1.  Format
-
-   The Local IPv6 addresses are created using a pseudo-randomly
-   allocated global ID.  They have the following format:
-
-      | 7 bits |1|  40 bits   |  16 bits  |          64 bits           |
-      +--------+-+------------+-----------+----------------------------+
-      | Prefix |L| Global ID  | Subnet ID |        Interface ID        |
-      +--------+-+------------+-----------+----------------------------+
-
-   Where:
-
-      Prefix            FC00::/7 prefix to identify Local IPv6 unicast
-                        addresses.
-
-      L                 Set to 1 if the prefix is locally assigned.
-                        Set to 0 may be defined in the future.  See
-                        Section 3.2 for additional information.
-
-      Global ID         40-bit global identifier used to create a
-                        globally unique prefix.  See Section 3.2 for
-                        additional information.
-
-      Subnet ID         16-bit Subnet ID is an identifier of a subnet
-                        within the site.
-
-      Interface ID      64-bit Interface ID as defined in [ADDARCH].
-
-
-
-
-Hinden & Haberman           Standards Track                     [Page 3]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-3.1.1.  Background
-
-   There were a range of choices available when choosing the size of the
-   prefix and Global ID field length.  There is a direct tradeoff
-   between having a Global ID field large enough to support foreseeable
-   future growth and not using too much of the IPv6 address space
-   needlessly.  A reasonable way of evaluating a specific field length
-   is to compare it to a projected 2050 world population of 9.3 billion
-   [POPUL] and the number of resulting /48 prefixes per person.  A range
-   of prefix choices is shown in the following table:
-
-    Prefix  Global ID     Number of          Prefixes    % of IPv6
-            Length        /48 Prefixes       per Person  Address Space
-
-    /11       37           137,438,953,472     15         0.049%
-    /10       38           274,877,906,944     30         0.098%
-    /9        39           549,755,813,888     59         0.195%
-    /8        40         1,099,511,627,776    118         0.391%
-    /7        41         2,199,023,255,552    236         0.781%
-    /6        42         4,398,046,511,104    473         1.563%
-
-   A very high utilization ratio of these allocations can be assumed
-   because the Global ID field does not require internal structure, and
-   there is no reason to be able to aggregate the prefixes.
-
-   The authors believe that a /7 prefix resulting in a 41-bit Global ID
-   space (including the L bit) is a good choice.  It provides for a
-   large number of assignments (i.e., 2.2 trillion) and at the same time
-   uses less than .8% of the total IPv6 address space.  It is unlikely
-   that this space will be exhausted.  If more than this were to be
-   needed, then additional IPv6 address space could be allocated for
-   this purpose.
-
-3.2.  Global ID
-
-   The allocation of Global IDs is pseudo-random [RANDOM].  They MUST
-   NOT be assigned sequentially or with well-known numbers.  This is to
-   ensure that there is not any relationship between allocations and to
-   help clarify that these prefixes are not intended to be routed
-   globally.  Specifically, these prefixes are not designed to
-   aggregate.
-
-   This document defines a specific local method to allocate Global IDs,
-   indicated by setting the L bit to 1.  Another method, indicated by
-   clearing the L bit, may be defined later.  Apart from the allocation
-   method, all Local IPv6 addresses behave and are treated identically.
-
-
-
-
-
-Hinden & Haberman           Standards Track                     [Page 4]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-   The local assignments are self-generated and do not need any central
-   coordination or assignment, but have an extremely high probability of
-   being unique.
-
-3.2.1.  Locally Assigned Global IDs
-
-   Locally assigned Global IDs MUST be generated with a pseudo-random
-   algorithm consistent with [RANDOM].  Section 3.2.2 describes a
-   suggested algorithm.  It is important that all sites generating
-   Global IDs use a functionally similar algorithm to ensure there is a
-   high probability of uniqueness.
-
-   The use of a pseudo-random algorithm to generate Global IDs in the
-   locally assigned prefix gives an assurance that any network numbered
-   using such a prefix is highly unlikely to have that address space
-   clash with any other network that has another locally assigned prefix
-   allocated to it.  This is a particularly useful property when
-   considering a number of scenarios including networks that merge,
-   overlapping VPN address space, or hosts mobile between such networks.
-
-3.2.2.  Sample Code for Pseudo-Random Global ID Algorithm
-
-   The algorithm described below is intended to be used for locally
-   assigned Global IDs.  In each case the resulting global ID will be
-   used in the appropriate prefix as defined in Section 3.2.
-
-     1) Obtain the current time of day in 64-bit NTP format [NTP].
-
-     2) Obtain an EUI-64 identifier from the system running this
-        algorithm.  If an EUI-64 does not exist, one can be created from
-        a 48-bit MAC address as specified in [ADDARCH].  If an EUI-64
-        cannot be obtained or created, a suitably unique identifier,
-        local to the node, should be used (e.g., system serial number).
-
-     3) Concatenate the time of day with the system-specific identifier
-        in order to create a key.
-
-     4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1];
-        the resulting value is 160 bits.
-
-     5) Use the least significant 40 bits as the Global ID.
-
-     6) Concatenate FC00::/7, the L bit set to 1, and the 40-bit Global
-        ID to create a Local IPv6 address prefix.
-
-   This algorithm will result in a Global ID that is reasonably unique
-   and can be used to create a locally assigned Local IPv6 address
-   prefix.
-
-
-
-Hinden & Haberman           Standards Track                     [Page 5]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-3.2.3.  Analysis of the Uniqueness of Global IDs
-
-   The selection of a pseudo random Global ID is similar to the
-   selection of an SSRC identifier in RTP/RTCP defined in Section 8.1 of
-   [RTP].  This analysis is adapted from that document.
-
-   Since Global IDs are chosen randomly (and independently), it is
-   possible that separate networks have chosen the same Global ID.  For
-   any given network, with one or more random Global IDs, that has
-   inter-connections to other such networks, having a total of N such
-   IDs, the probability that two or more of these IDs will collide can
-   be approximated using the formula:
-
-      P = 1 - exp(-N**2 / 2**(L+1))
-
-   where P is the probability of collision, N is the number of
-   interconnected Global IDs, and L is the length of the Global ID.
-
-   The following table shows the probability of a collision for a range
-   of connections using a 40-bit Global ID field.
-
-      Connections      Probability of Collision
-
-          2                1.81*10^-12
-         10                4.54*10^-11
-        100                4.54*10^-09
-       1000                4.54*10^-07
-      10000                4.54*10^-05
-
-   Based on this analysis, the uniqueness of locally generated Global
-   IDs is adequate for sites planning a small to moderate amount of
-   inter-site communication using locally generated Global IDs.
-
-3.3.  Scope Definition
-
-   By default, the scope of these addresses is global.  That is, they
-   are not limited by ambiguity like the site-local addresses defined in
-   [ADDARCH].  Rather, these prefixes are globally unique, and as such,
-   their applicability is greater than site-local addresses.  Their
-   limitation is in the routability of the prefixes, which is limited to
-   a site and any explicit routing agreements with other sites to
-   propagate them (also see Section 4.1).  Also, unlike site-locals, a
-   site may have more than one of these prefixes and use them at the
-   same time.
-
-
-
-
-
-
-
-Hinden & Haberman           Standards Track                     [Page 6]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-4.  Operational Guidelines
-
-   The guidelines in this section do not require any change to the
-   normal routing and forwarding functionality in an IPv6 host or
-   router.  These are configuration and operational usage guidelines.
-
-4.1.  Routing
-
-   Local IPv6 addresses are designed to be routed inside of a site in
-   the same manner as other types of unicast addresses.  They can be
-   carried in any IPv6 routing protocol without any change.
-
-   It is expected that they would share the same Subnet IDs with
-   provider-based global unicast addresses, if they were being used
-   concurrently [GLOBAL].
-
-   The default behavior of exterior routing protocol sessions between
-   administrative routing regions must be to ignore receipt of and not
-   advertise prefixes in the FC00::/7 block.  A network operator may
-   specifically configure prefixes longer than FC00::/7 for inter-site
-   communication.
-
-   If BGP is being used at the site border with an ISP, the default BGP
-   configuration must filter out any Local IPv6 address prefixes, both
-   incoming and outgoing.  It must be set both to keep any Local IPv6
-   address prefixes from being advertised outside of the site as well as
-   to keep these prefixes from being learned from another site.  The
-   exception to this is if there are specific /48 or longer routes
-   created for one or more Local IPv6 prefixes.
-
-   For link-state IGPs, it is suggested that a site utilizing IPv6 local
-   address prefixes be contained within one IGP domain or area.  By
-   containing an IPv6 local address prefix to a single link-state area
-   or domain, the distribution of prefixes can be controlled.
-
-4.2.  Renumbering and Site Merging
-
-   The use of Local IPv6 addresses in a site results in making
-   communication that uses these addresses independent of renumbering a
-   site's provider-based global addresses.
-
-   When merging multiple sites, the addresses created with these
-   prefixes are unlikely to need to be renumbered because all of the
-   addresses have a high probability of being unique.  Routes for each
-   specific prefix would have to be configured to allow routing to work
-   correctly between the formerly separate sites.
-
-
-
-
-
-Hinden & Haberman           Standards Track                     [Page 7]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-4.3.  Site Border Router and Firewall Packet Filtering
-
-   While no serious harm will be done if packets with these addresses
-   are sent outside of a site via a default route, it is recommended
-   that routers be configured by default to keep any packets with Local
-   IPv6 addresses from leaking outside of the site and to keep any site
-   prefixes from being advertised outside of their site.
-
-   Site border routers and firewalls should be configured to not forward
-   any packets with Local IPv6 source or destination addresses outside
-   of the site, unless they have been explicitly configured with routing
-   information about specific /48 or longer Local IPv6 prefixes.  This
-   will ensure that packets with Local IPv6 destination addresses will
-   not be forwarded outside of the site via a default route.  The
-   default behavior of these devices should be to install a "reject"
-   route for these prefixes.  Site border routers should respond with
-   the appropriate ICMPv6 Destination Unreachable message to inform the
-   source that the packet was not forwarded. [ICMPV6].  This feedback is
-   important to avoid transport protocol timeouts.
-
-   Routers that maintain peering arrangements between Autonomous Systems
-   throughout the Internet should obey the recommendations for site
-   border routers, unless configured otherwise.
-
-4.4.  DNS Issues
-
-   At the present time, AAAA and PTR records for locally assigned local
-   IPv6 addresses are not recommended to be installed in the global DNS.
-
-   For background on this recommendation, one of the concerns about
-   adding AAAA and PTR records to the global DNS for locally assigned
-   Local IPv6 addresses stems from the lack of complete assurance that
-   the prefixes are unique.  There is a small possibility that the same
-   locally assigned IPv6 Local addresses will be used by two different
-   organizations both claiming to be authoritative with different
-   contents.  In this scenario, it is likely there will be a connection
-   attempt to the closest host with the corresponding locally assigned
-   IPv6 Local address.  This may result in connection timeouts,
-   connection failures indicated by ICMP Destination Unreachable
-   messages, or successful connections to the wrong host.  Due to this
-   concern, adding AAAA records for these addresses to the global DNS is
-   thought to be unwise.
-
-   Reverse (address-to-name) queries for locally assigned IPv6 Local
-   addresses MUST NOT be sent to name servers for the global DNS, due to
-   the load that such queries would create for the authoritative name
-   servers for the ip6.arpa zone.  This form of query load is not
-   specific to locally assigned Local IPv6 addresses; any current form
-
-
-
-Hinden & Haberman           Standards Track                     [Page 8]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-   of local addressing creates additional load of this kind, due to
-   reverse queries leaking out of the site.  However, since allowing
-   such queries to escape from the site serves no useful purpose, there
-   is no good reason to make the existing load problems worse.
-
-   The recommended way to avoid sending such queries to nameservers for
-   the global DNS is for recursive name server implementations to act as
-   if they were authoritative for an empty d.f.ip6.arpa zone and return
-   RCODE 3 for any such query.  Implementations that choose this
-   strategy should allow it to be overridden, but returning an RCODE 3
-   response for such queries should be the default, both because this
-   will reduce the query load problem and also because, if the site
-   administrator has not set up the reverse tree corresponding to the
-   locally assigned IPv6 Local addresses in use, returning RCODE 3 is in
-   fact the correct answer.
-
-4.5.  Application and Higher Level Protocol Issues
-
-   Application and other higher level protocols can treat Local IPv6
-   addresses in the same manner as other types of global unicast
-   addresses.  No special handling is required.  This type of address
-   may not be reachable, but that is no different from other types of
-   IPv6 global unicast address.  Applications need to be able to handle
-   multiple addresses that may or may not be reachable at any point in
-   time.  In most cases, this complexity should be hidden in APIs.
-
-   From a host's perspective, the difference between Local IPv6 and
-   other types of global unicast addresses shows up as different
-   reachability and could be handled by default in that way.  In some
-   cases, it is better for nodes and applications to treat them
-   differently from global unicast addresses.  A starting point might be
-   to give them preference over global unicast, but fall back to global
-   unicast if a particular destination is found to be unreachable.  Much
-   of this behavior can be controlled by how they are allocated to nodes
-   and put into the DNS.  However, it is useful if a host can have both
-   types of addresses and use them appropriately.
-
-   Note that the address selection mechanisms of [ADDSEL], and in
-   particular the policy override mechanism replacing default address
-   selection, are expected to be used on a site where Local IPv6
-   addresses are configured.
-
-4.6.  Use of Local IPv6 Addresses for Local Communication
-
-   Local IPv6 addresses, like global scope unicast addresses, are only
-   assigned to nodes if their use has been enabled (via IPv6 address
-   autoconfiguration [ADDAUTO], DHCPv6 [DHCP6], or manually).  They are
-
-
-
-
-Hinden & Haberman           Standards Track                     [Page 9]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-   not created automatically in the way that IPv6 link-local addresses
-   are and will not appear or be used unless they are purposely
-   configured.
-
-   In order for hosts to autoconfigure Local IPv6 addresses, routers
-   have to be configured to advertise Local IPv6 /64 prefixes in router
-   advertisements, or a DHCPv6 server must have been configured to
-   assign them.  In order for a node to learn the Local IPv6 address of
-   another node, the Local IPv6 address must have been installed in a
-   naming system (e.g., DNS, proprietary naming system, etc.)  For these
-   reasons, controlling their usage in a site is straightforward.
-
-   To limit the use of Local IPv6 addresses the following guidelines
-   apply:
-
-      - Nodes that are to only be reachable inside of a site:  The local
-        DNS should be configured to only include the Local IPv6
-        addresses of these nodes.  Nodes with only Local IPv6 addresses
-        must not be installed in the global DNS.
-
-      - Nodes that are to be limited to only communicate with other
-        nodes in the site:  These nodes should be set to only
-        autoconfigure Local IPv6 addresses via [ADDAUTO] or to only
-        receive Local IPv6 addresses via [DHCP6].  Note: For the case
-        where both global and Local IPv6 prefixes are being advertised
-        on a subnet, this will require a switch in the devices to only
-        autoconfigure Local IPv6 addresses.
-
-      - Nodes that are to be reachable from inside of the site and from
-        outside of the site:  The DNS should be configured to include
-        the global addresses of these nodes.  The local DNS may be
-        configured to also include the Local IPv6 addresses of these
-        nodes.
-
-      - Nodes that can communicate with other nodes inside of the site
-        and outside of the site: These nodes should autoconfigure global
-        addresses via [ADDAUTO] or receive global address via [DHCP6].
-        They may also obtain Local IPv6 addresses via the same
-        mechanisms.
-
-4.7.  Use of Local IPv6 Addresses with VPNs
-
-   Local IPv6 addresses can be used for inter-site Virtual Private
-   Networks (VPN) if appropriate routes are set up.  Because the
-   addresses are unique, these VPNs will work reliably and without the
-   need for translation.  They have the additional property that they
-   will continue to work if the individual sites are renumbered or
-   merged.
-
-
-
-Hinden & Haberman           Standards Track                    [Page 10]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-5.  Global Routing Considerations
-
-   Section 4.1 provides operational guidelines that forbid default
-   routing of local addresses between sites.  Concerns were raised to
-   the IPv6 working group and to the IETF as a whole that sites may
-   attempt to use local addresses as globally routed provider-
-   independent addresses.  This section describes why using local
-   addresses as globally-routed provider-independent addresses is
-   unadvisable.
-
-5.1.  From the Standpoint of the Internet
-
-   There is a mismatch between the structure of IPv6 local addresses and
-   the normal IPv6 wide area routing model.  The /48 prefix of an IPv6
-   local addresses fits nowhere in the normal hierarchy of IPv6 unicast
-   addresses.  Normal IPv6 unicast addresses can be routed
-   hierarchically down to physical subnet (link) level and only have to
-   be flat-routed on the physical subnet.  IPv6 local addresses would
-   have to be flat-routed even over the wide area Internet.
-
-   Thus, packets whose destination address is an IPv6 local address
-   could be routed over the wide area only if the corresponding /48
-   prefix were carried by the wide area routing protocol in use, such as
-   BGP.  This contravenes the operational assumption that long prefixes
-   will be aggregated into many fewer short prefixes, to limit the table
-   size and convergence time of the routing protocol.  If a network uses
-   both normal IPv6 addresses [ADDARCH] and IPv6 local addresses, these
-   types of addresses will certainly not aggregate with each other,
-   since they differ from the most significant bit onwards.  Neither
-   will IPv6 local addresses aggregate with each other, due to their
-   random bit patterns.  This means that there would be a very
-   significant operational penalty for attempting to use IPv6 local
-   address prefixes generically with currently known wide area routing
-   technology.
-
-5.2.  From the Standpoint of a Site
-
-   There are a number of design factors in IPv6 local addresses that
-   reduce the likelihood that IPv6 local addresses will be used as
-   arbitrary global unicast addresses.  These include:
-
-      - The default rules to filter packets and routes make it very
-        difficult to use IPv6 local addresses for arbitrary use across
-        the Internet.  For a site to use them as general purpose unicast
-        addresses, it would have to make sure that the default rules
-        were not being used by all other sites and intermediate ISPs
-        used for their current and future communication.
-
-
-
-
-Hinden & Haberman           Standards Track                    [Page 11]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-      - They are not mathematically guaranteed to be unique and are not
-        registered in public databases.  Collisions, while highly
-        unlikely, are possible and a collision can compromise the
-        integrity of the communications.  The lack of public
-        registration creates operational problems.
-
-      - The addresses are allocated randomly.  If a site had multiple
-        prefixes that it wanted to be used globally, the cost of
-        advertising them would be very high because they could not be
-        aggregated.
-
-      - They have a long prefix (i.e., /48) so a single local address
-        prefix doesn't provide enough address space to be used
-        exclusively by the largest organizations.
-
-6.  Advantages and Disadvantages
-
-6.1.  Advantages
-
-   This approach has the following advantages:
-
-      - Provides Local IPv6 prefixes that can be used independently of
-        any provider-based IPv6 unicast address allocations.  This is
-        useful for sites not always connected to the Internet or sites
-        that wish to have a distinct prefix that can be used to localize
-        traffic inside of the site.
-
-      - Applications can treat these addresses in an identical manner as
-        any other type of global IPv6 unicast addresses.
-
-      - Sites can be merged without any renumbering of the Local IPv6
-        addresses.
-
-      - Sites can change their provider-based IPv6 unicast address
-        without disrupting any communication that uses Local IPv6
-        addresses.
-
-      - Well-known prefix that allows for easy filtering at site
-        boundary.
-
-      - Can be used for inter-site VPNs.
-
-      - If accidently leaked outside of a site via routing or DNS, there
-        is no conflict with any other addresses.
-
-
-
-
-
-
-
-Hinden & Haberman           Standards Track                    [Page 12]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-6.2.  Disadvantages
-
-   This approach has the following disadvantages:
-
-      - Not possible to route Local IPv6 prefixes on the global Internet
-        with current routing technology.  Consequentially, it is
-        necessary to have the default behavior of site border routers to
-        filter these addresses.
-
-      - There is a very low probability of non-unique locally assigned
-        Global IDs being generated by the algorithm in Section 3.2.3.
-        This risk can be ignored for all practical purposes, but it
-        leads to a theoretical risk of clashing address prefixes.
-
-7.  Security Considerations
-
-   Local IPv6 addresses do not provide any inherent security to the
-   nodes that use them.  They may be used with filters at site
-   boundaries to keep Local IPv6 traffic inside of the site, but this is
-   no more or less secure than filtering any other type of global IPv6
-   unicast addresses.
-
-   Local IPv6 addresses do allow for address-based security mechanisms,
-   including IPsec, across end to end VPN connections.
-
-8.  IANA Considerations
-
-   The IANA has assigned the FC00::/7 prefix to "Unique Local Unicast".
-
-9.  References
-
-9.1.  Normative References
-
-   [ADDARCH]  Hinden, R. and S. Deering, "Internet Protocol Version 6
-             (IPv6) Addressing Architecture", RFC 3513, April 2003.
-
-   [FIPS]    "Federal Information Processing Standards Publication",
-             (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
-
-   [GLOBAL]  Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
-             Unicast Address Format", RFC 3587, August 2003.
-
-   [ICMPV6]  Conta, A. and S. Deering, "Internet Control Message
-             Protocol (ICMPv6) for the Internet Protocol Version 6
-             (IPv6) Specification", RFC 2463, December 1998.
-
-
-
-
-
-
-Hinden & Haberman           Standards Track                    [Page 13]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-   [IPV6]    Deering, S. and R. Hinden, "Internet Protocol, Version 6
-             (IPv6) Specification", RFC 2460, December 1998.
-
-   [NTP]     Mills, D., "Network Time Protocol (Version 3)
-             Specification, Implementation and Analysis", RFC 1305,
-             March 1992.
-
-   [RANDOM]  Eastlake, D., 3rd, Schiller, J., and S. Crocker,
-             "Randomness Requirements for Security", BCP 106, RFC 4086,
-             June 2005.
-
-   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [SHA1]    Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
-             (SHA1)", RFC 3174, September 2001.
-
-9.2.  Informative References
-
-   [ADDAUTO] Thomson, S. and T. Narten, "IPv6 Stateless Address
-             Autoconfiguration", RFC 2462, December 1998.
-
-   [ADDSEL]  Draves, R., "Default Address Selection for Internet
-             Protocol version 6 (IPv6)", RFC 3484, February 2003.
-
-   [DHCP6]   Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and
-             M. Carney, "Dynamic Host Configuration Protocol for IPv6
-             (DHCPv6)", RFC 3315, July 2003.
-
-   [POPUL]   Population Reference Bureau, "World Population Data Sheet
-             of the Population Reference Bureau 2002",  August 2002.
-
-   [RTP]     Schulzrinne, H.,  Casner, S., Frederick, R., and V.
-             Jacobson, "RTP: A Transport Protocol for Real-Time
-             Applications", STD 64, RFC 3550, July 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Haberman           Standards Track                    [Page 14]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-Authors' Addresses
-
-   Robert M. Hinden
-   Nokia
-   313 Fairchild Drive
-   Mountain View, CA 94043
-   USA
-
-   Phone: +1 650 625-2004
-   EMail: bob.hinden@nokia.com
-
-
-   Brian Haberman
-   Johns Hopkins University
-   Applied Physics Lab
-   11100 Johns Hopkins Road
-   Laurel, MD 20723
-   USA
-
-   Phone: +1 443 778 1319
-   EMail: brian@innovationslab.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hinden & Haberman           Standards Track                    [Page 15]
-
-RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   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.
-
-Intellectual Property
-
-   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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-Hinden & Haberman           Standards Track                    [Page 16]
-
diff --git a/contrib/bind9/doc/rfc/rfc4255.txt b/contrib/bind9/doc/rfc/rfc4255.txt
deleted file mode 100644
index f350b7a..0000000
--- a/contrib/bind9/doc/rfc/rfc4255.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        J. Schlyter
-Request for Comments: 4255                                       OpenSSH
-Category: Standards Track                                     W. Griffin
-                                                                  SPARTA
-                                                            January 2006
-
-
-   Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes a method of verifying Secure Shell (SSH) host
-   keys using Domain Name System Security (DNSSEC).  The document
-   defines a new DNS resource record that contains a standard SSH key
-   fingerprint.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. SSH Host Key Verification .......................................2
-      2.1. Method .....................................................2
-      2.2. Implementation Notes .......................................2
-      2.3. Fingerprint Matching .......................................3
-      2.4. Authentication .............................................3
-   3. The SSHFP Resource Record .......................................3
-      3.1. The SSHFP RDATA Format .....................................4
-           3.1.1. Algorithm Number Specification ......................4
-           3.1.2. Fingerprint Type Specification ......................4
-           3.1.3. Fingerprint .........................................5
-      3.2. Presentation Format of the SSHFP RR ........................5
-   4. Security Considerations .........................................5
-   5. IANA Considerations .............................................6
-   6. Normative References ............................................7
-   7. Informational References ........................................7
-   8. Acknowledgements ................................................8
-
-
-
-
-Schlyter & Griffin          Standards Track                     [Page 1]
-
-RFC 4255                DNS and SSH Fingerprints            January 2006
-
-
-1.  Introduction
-
-   The SSH [6] protocol provides secure remote login and other secure
-   network services over an insecure network.  The security of the
-   connection relies on the server authenticating itself to the client
-   as well as the user authenticating itself to the server.
-
-   If a connection is established to a server whose public key is not
-   already known to the client, a fingerprint of the key is presented to
-   the user for verification.  If the user decides that the fingerprint
-   is correct and accepts the key, the key is saved locally and used for
-   verification for all following connections.  While some security-
-   conscious users verify the fingerprint out-of-band before accepting
-   the key, many users blindly accept the presented key.
-
-   The method described here can provide out-of-band verification by
-   looking up a fingerprint of the server public key in the DNS [1][2]
-   and using DNSSEC [5] to verify the lookup.
-
-   In order to distribute the fingerprint using DNS, this document
-   defines a new DNS resource record, "SSHFP", to carry the fingerprint.
-
-   Basic understanding of the DNS system [1][2] and the DNS security
-   extensions [5] is assumed by this document.
-
-   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 [3].
-
-2.  SSH Host Key Verification
-
-2.1.  Method
-
-   Upon connection to an SSH server, the SSH client MAY look up the
-   SSHFP resource record(s) for the host it is connecting to.  If the
-   algorithm and fingerprint of the key received from the SSH server
-   match the algorithm and fingerprint of one of the SSHFP resource
-   record(s) returned from DNS, the client MAY accept the identity of
-   the server.
-
-2.2.  Implementation Notes
-
-   Client implementors SHOULD provide a configurable policy used to
-   select the order of methods used to verify a host key.  This document
-   defines one method: Fingerprint storage in DNS.  Another method
-   defined in the SSH Architecture [6] uses local files to store keys
-   for comparison.  Other methods that could be defined in the future
-   might include storing fingerprints in LDAP or other databases.  A
-
-
-
-Schlyter & Griffin          Standards Track                     [Page 2]
-
-RFC 4255                DNS and SSH Fingerprints            January 2006
-
-
-   configurable policy will allow administrators to determine which
-   methods they want to use and in what order the methods should be
-   prioritized.  This will allow administrators to determine how much
-   trust they want to place in the different methods.
-
-   One specific scenario for having a configurable policy is where
-   clients do not use fully qualified host names to connect to servers.
-   In this scenario, the implementation SHOULD verify the host key
-   against a local database before verifying the key via the fingerprint
-   returned from DNS.  This would help prevent an attacker from
-   injecting a DNS search path into the local resolver and forcing the
-   client to connect to a different host.
-
-2.3.  Fingerprint Matching
-
-   The public key and the SSHFP resource record are matched together by
-   comparing algorithm number and fingerprint.
-
-      The public key algorithm and the SSHFP algorithm number MUST
-      match.
-
-      A message digest of the public key, using the message digest
-      algorithm specified in the SSHFP fingerprint type, MUST match the
-      SSHFP fingerprint.
-
-2.4.  Authentication
-
-   A public key verified using this method MUST NOT be trusted if the
-   SSHFP resource record (RR) used for verification was not
-   authenticated by a trusted SIG RR.
-
-   Clients that do validate the DNSSEC signatures themselves SHOULD use
-   standard DNSSEC validation procedures.
-
-   Clients that do not validate the DNSSEC signatures themselves MUST
-   use a secure transport (e.g., TSIG [9], SIG(0) [10], or IPsec [8])
-   between themselves and the entity performing the signature
-   validation.
-
-3.  The SSHFP Resource Record
-
-   The SSHFP resource record (RR) is used to store a fingerprint of an
-   SSH public host key that is associated with a Domain Name System
-   (DNS) name.
-
-   The RR type code for the SSHFP RR is 44.
-
-
-
-
-
-Schlyter & Griffin          Standards Track                     [Page 3]
-
-RFC 4255                DNS and SSH Fingerprints            January 2006
-
-
-3.1.  The SSHFP RDATA Format
-
-   The RDATA for a SSHFP RR consists of an algorithm number, fingerprint
-   type and the fingerprint of the public host key.
-
-       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
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-       |   algorithm   |    fp type    |                               /
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
-       /                                                               /
-       /                          fingerprint                          /
-       /                                                               /
-       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-3.1.1.  Algorithm Number Specification
-
-   This algorithm number octet describes the algorithm of the public
-   key.  The following values are assigned:
-
-          Value    Algorithm name
-          -----    --------------
-          0        reserved
-          1        RSA
-          2        DSS
-
-   Reserving other types requires IETF consensus [4].
-
-3.1.2.  Fingerprint Type Specification
-
-   The fingerprint type octet describes the message-digest algorithm
-   used to calculate the fingerprint of the public key.  The following
-   values are assigned:
-
-          Value    Fingerprint type
-          -----    ----------------
-          0        reserved
-          1        SHA-1
-
-   Reserving other types requires IETF consensus [4].
-
-   For interoperability reasons, as few fingerprint types as possible
-   should be reserved.  The only reason to reserve additional types is
-   to increase security.
-
-
-
-
-
-
-
-Schlyter & Griffin          Standards Track                     [Page 4]
-
-RFC 4255                DNS and SSH Fingerprints            January 2006
-
-
-3.1.3.  Fingerprint
-
-   The fingerprint is calculated over the public key blob as described
-   in [7].
-
-   The message-digest algorithm is presumed to produce an opaque octet
-   string output, which is placed as-is in the RDATA fingerprint field.
-
-3.2.  Presentation Format of the SSHFP RR
-
-   The RDATA of the presentation format of the SSHFP resource record
-   consists of two numbers (algorithm and fingerprint type) followed by
-   the fingerprint itself, presented in hex, e.g.:
-
-       host.example.  SSHFP 2 1 123456789abcdef67890123456789abcdef67890
-
-   The use of mnemonics instead of numbers is not allowed.
-
-4.  Security Considerations
-
-   Currently, the amount of trust a user can realistically place in a
-   server key is proportional to the amount of attention paid to
-   verifying that the public key presented actually corresponds to the
-   private key of the server.  If a user accepts a key without verifying
-   the fingerprint with something learned through a secured channel, the
-   connection is vulnerable to a man-in-the-middle attack.
-
-   The overall security of using SSHFP for SSH host key verification is
-   dependent on the security policies of the SSH host administrator and
-   DNS zone administrator (in transferring the fingerprint), detailed
-   aspects of how verification is done in the SSH implementation, and in
-   the client's diligence in accessing the DNS in a secure manner.
-
-   One such aspect is in which order fingerprints are looked up (e.g.,
-   first checking local file and then SSHFP).  We note that, in addition
-   to protecting the first-time transfer of host keys, SSHFP can
-   optionally be used for stronger host key protection.
-
-      If SSHFP is checked first, new SSH host keys may be distributed by
-      replacing the corresponding SSHFP in DNS.
-
-      If SSH host key verification can be configured to require SSHFP,
-      SSH host key revocation can be implemented by removing the
-      corresponding SSHFP from DNS.
-
-
-
-
-
-
-
-Schlyter & Griffin          Standards Track                     [Page 5]
-
-RFC 4255                DNS and SSH Fingerprints            January 2006
-
-
-   As stated in Section 2.2, we recommend that SSH implementors provide
-   a policy mechanism to control the order of methods used for host key
-   verification.  One specific scenario for having a configurable policy
-   is where clients use unqualified host names to connect to servers.
-   In this case, we recommend that SSH implementations check the host
-   key against a local database before verifying the key via the
-   fingerprint returned from DNS.  This would help prevent an attacker
-   from injecting a DNS search path into the local resolver and forcing
-   the client to connect to a different host.
-
-   A different approach to solve the DNS search path issue would be for
-   clients to use a trusted DNS search path, i.e., one not acquired
-   through DHCP or other autoconfiguration mechanisms.  Since there is
-   no way with current DNS lookup APIs to tell whether a search path is
-   from a trusted source, the entire client system would need to be
-   configured with this trusted DNS search path.
-
-   Another dependency is on the implementation of DNSSEC itself.  As
-   stated in Section 2.4, we mandate the use of secure methods for
-   lookup and that SSHFP RRs are authenticated by trusted SIG RRs.  This
-   is especially important if SSHFP is to be used as a basis for host
-   key rollover and/or revocation, as described above.
-
-   Since DNSSEC only protects the integrity of the host key fingerprint
-   after it is signed by the DNS zone administrator, the fingerprint
-   must be transferred securely from the SSH host administrator to the
-   DNS zone administrator.  This could be done manually between the
-   administrators or automatically using secure DNS dynamic update [11]
-   between the SSH server and the nameserver.  We note that this is no
-   different from other key enrollment situations, e.g., a client
-   sending a certificate request to a certificate authority for signing.
-
-5.  IANA Considerations
-
-   IANA has allocated the RR type code 44 for SSHFP from the standard RR
-   type space.
-
-   IANA has opened a new registry for the SSHFP RR type for public key
-   algorithms.  The defined types are:
-
-      0 is reserved
-      1 is RSA
-      2 is DSA
-
-   Adding new reservations requires IETF consensus [4].
-
-
-
-
-
-
-Schlyter & Griffin          Standards Track                     [Page 6]
-
-RFC 4255                DNS and SSH Fingerprints            January 2006
-
-
-   IANA has opened a new registry for the SSHFP RR type for fingerprint
-   types.  The defined types are:
-
-      0 is reserved
-      1 is SHA-1
-
-   Adding new reservations requires IETF consensus [4].
-
-6.  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., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-   [4]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-         Considerations Section in RFCs", BCP 26, RFC 2434, October
-         1998.
-
-   [5]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "DNS Security Introduction and Requirements", RFC 4033, March
-         2005.
-
-         Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Resource Records for the DNS Security Extensions", RFC 4034,
-         March 2005.
-
-         Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Protocol Modifications for the DNS Security Extensions", RFC
-         4035, March 2005.
-
-   [6]   Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
-         Protocol Architecture", RFC 4251, January 2006.
-
-   [7]   Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
-         Transport Layer Protocol", RFC 4253, January 2006.
-
-7.  Informational References
-
-   [8]   Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document
-         Roadmap", RFC 2411, November 1998.
-
-
-
-
-
-
-Schlyter & Griffin          Standards Track                     [Page 7]
-
-RFC 4255                DNS and SSH Fingerprints            January 2006
-
-
-   [9]   Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
-         Wellington, "Secret Key Transaction Authentication for DNS
-         (TSIG)", RFC 2845, May 2000.
-
-   [10]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
-         ( SIG(0)s )", RFC 2931, September 2000.
-
-   [11]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
-         Update", RFC 3007, November 2000.
-
-8.  Acknowledgements
-
-   The authors gratefully acknowledge, in no particular order, the
-   contributions of the following persons:
-
-      Martin Fredriksson
-
-      Olafur Gudmundsson
-
-      Edward Lewis
-
-      Bill Sommerfeld
-
-Authors' Addresses
-
-   Jakob Schlyter
-   OpenSSH
-   812 23rd Avenue SE
-   Calgary, Alberta  T2G 1N8
-   Canada
-
-   EMail: jakob@openssh.com
-   URI:   http://www.openssh.com/
-
-
-   Wesley Griffin
-   SPARTA
-   7075 Samuel Morse Drive
-   Columbia, MD  21046
-   USA
-
-   EMail: wgriffin@sparta.com
-   URI:   http://www.sparta.com/
-
-
-
-
-
-
-
-
-Schlyter & Griffin          Standards Track                     [Page 8]
-
-RFC 4255                DNS and SSH Fingerprints            January 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   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.
-
-Intellectual Property
-
-   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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Schlyter & Griffin          Standards Track                     [Page 9]
-
diff --git a/contrib/bind9/doc/rfc/rfc4343.txt b/contrib/bind9/doc/rfc/rfc4343.txt
deleted file mode 100644
index 621420a..0000000
--- a/contrib/bind9/doc/rfc/rfc4343.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                    D. Eastlake 3rd
-Request for Comments: 4343                         Motorola Laboratories
-Updates: 1034, 1035, 2181                                   January 2006
-Category: Standards Track
-
-
-       Domain Name System (DNS) Case Insensitivity Clarification
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-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 updates RFCs 1034, 1035, and 2181.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. Case Insensitivity of DNS Labels ................................2
-      2.1. Escaping Unusual DNS Label Octets ..........................2
-      2.2. Example Labels with Escapes ................................3
-   3. Name Lookup, Label Types, and CLASS .............................3
-      3.1. Original DNS Label Types ...................................4
-      3.2. Extended Label Type Case Insensitivity Considerations ......4
-      3.3. CLASS Case Insensitivity Considerations ....................4
-   4. Case on Input and Output ........................................5
-      4.1. DNS Output Case Preservation ...............................5
-      4.2. DNS Input Case Preservation ................................5
-   5. Internationalized Domain Names ..................................6
-   6. Security Considerations .........................................6
-   7. Acknowledgements ................................................7
-   Normative References................................................7
-   Informative References..............................................8
-
-
-
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 1]
-
-RFC 4343          DNS Case Insensitivity Clarification      January 2006
-
-
-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 [STD13, RFC1591, RFC2606] that are treated in
-   a case insensitive fashion.  This document clarifies the meaning of
-   "case insensitive" for the DNS.  This clarification updates RFCs
-   1034, 1035 [STD13], and [RFC2181].
-
-   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].
-
-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 to 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 [RFC3092] 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 [STD13] 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 from 0x21
-   ("!") to 0x7E ("~").  That is to say, 0x2E and all octet values in
-   the two inclusive ranges from 0x00 to 0x20 and from 0x7F to 0xFF.
-
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 2]
-
-RFC 4343          DNS Case Insensitivity Clarification      January 2006
-
-
-   One typographic convention for octets that do not correspond to an
-   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 \.  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 shows 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
-
-   According to the original DNS design decision, comparisons on name
-   lookup for DNS queries should be case insensitive [STD13].  That is
-   to say, a lookup string octet with a value in the inclusive range
-   from 0x41 to 0x5A, the uppercase ASCII letters, MUST match the
-   identical value and also match the corresponding value in the
-   inclusive range from 0x61 to 0x7A, the lowercase ASCII letters.  A
-   lookup string octet with a lowercase ASCII letter value MUST
-   similarly match the identical value and also match the corresponding
-   value in the uppercase ASCII letter range.
-
-   (Historical note: The terms "uppercase" and "lowercase" 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".)
-
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 3]
-
-RFC 4343          DNS Case Insensitivity Clarification      January 2006
-
-
-   One way to implement this rule would be to subtract 0x20 from all
-   octets in the inclusive range from 0x61 to 0x7A before comparing
-   octets.  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 [STD13] had only two types: ASCII labels,
-   with a length from zero to 63 octets, and indirect (or compression)
-   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 [RFC2671] so that additional label type numbers
-   would be available.  (The only such type defined so far is the BINARY
-   type [RFC2673], which is now Experimental [RFC3363].)
-
-   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 [STD13] and [RFC2929], DNS has an additional axis for
-   data location called CLASS.  The only CLASS in global use at this
-   time is the "IN" (Internet) CLASS.
-
-   The handling of DNS label case is not CLASS dependent.  With the
-   original design of DNS, it was intended that a recursive DNS resolver
-   be able to handle new CLASSes that were unknown at the time of its
-   implementation.  This requires uniform handling of label case
-   insensitivity.  Should it become desirable, for example, to allocate
-   a CLASS with "case sensitive ASCII labels", it would be necessary to
-   allocate a new label type for these labels.
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 4]
-
-RFC 4343          DNS Case Insensitivity Clarification      January 2006
-
-
-4.  Case on Input and Output
-
-   While ASCII label comparisons are case insensitive, [STD13] 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
-
-   [STD13] views the DNS namespace as a node tree.  ASCII output is as
-   if a name were 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 are 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 data came from an ASCII Master File as defined in
-   [STD13] or a zone transfer.  DNS Dynamic update and incremental zone
-   transfers [RFC1995] have been added as a source of DNS data [RFC2136,
-   RFC3007].  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 exists in DNS data being
-   held, the situation is more complex.  Implementations are free to
-   retain the case first loaded for such a label, to allow new input to
-   override the old case, or even to maintain separate copies preserving
-   the input case.
-
-   For example, if data with owner name "foo.bar.example" [RFC3092] is
-   loaded 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" in the DNS stored data.  Thus,
-   later retrieval of data stored under "xyz.bar.example" in this case
-   can use "xyz.BAR.example" in all returned data, use "xyz.bar.example"
-   in all returned data, or even, when more than one RR is being
-   returned, use a mixture of these two capitalizations.  This last case
-
-
-
-Eastlake 3rd                Standards Track                     [Page 5]
-
-RFC 4343          DNS Case Insensitivity Clarification      January 2006
-
-
-   is unlikely, as optimization of answer length through indirect labels
-   tends to cause only one copy of the name tail ("bar.example" or
-   "BAR.example") to be used for all returned RRs.  Note that none of
-   this has any effect on the number or completeness of the RR set
-   returned, only on the case of the names in the RR set returned.
-
-   The same considerations apply when inputting multiple data records
-   with owner names differing only in case.  For example, if an "A"
-   record is the first resource record stored 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, the second MAY override the first so that
-   only an uppercase initial label is retained, or both capitalizations
-   MAY be kept in the DNS stored data.  In any case, a retrieval with
-   either capitalization will retrieve all RRs with either
-   capitalization.
-
-   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 [RFC3490, RFC3454,
-   RFC3491, and RFC3492].  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 [RFC3454] and [RFC3491], 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 that 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 database
-   or file 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
-
-
-
-Eastlake 3rd                Standards Track                     [Page 6]
-
-RFC 4343          DNS Case Insensitivity Clarification      January 2006
-
-
-   ASCII type labels; that is, always mapping the ASCII letter value
-   octets in ASCII labels to some specific pre-chosen case, either
-   uppercase or lower case.  An example of a canonical form for domain
-   names (and also a canonical ordering for them) appears in Section 6
-   of [RFC4034].  See also [RFC3597].
-
-   Finally, a non-DNS name may be stored into DNS with the false
-   expectation that case will always be preserved.  For example,
-   although this would be quite rare, on a system with case sensitive
-   email address local parts, an attempt to store two Responsible Person
-   (RP) [RFC1183] 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.
-
-7.  Acknowledgements
-
-   The contributions to this document by Rob Austein, Olafur
-   Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana,
-   Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman
-   are gratefully acknowledged.
-
-Normative References
-
-   [ASCII]      ANSI, "USA Standard Code for Information Interchange",
-                X3.4, American National Standards Institute: New York,
-                1968.
-
-   [RFC1995]    Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
-                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.
-
-   [RFC3007]    Wellington, B., "Secure Domain Name System (DNS) Dynamic
-                Update", RFC 3007, November 2000.
-
-
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 7]
-
-RFC 4343          DNS Case Insensitivity Clarification      January 2006
-
-
-   [RFC3597]    Gustafsson, A., "Handling of Unknown DNS Resource Record
-                (RR) Types", RFC 3597, September 2003.
-
-   [RFC4034]    Arends, R., Austein, R., Larson, M., Massey, D., and S.
-                Rose, "Resource Records for the DNS Security
-                Extensions", RFC 4034, March 2005.
-
-   [STD13]      Mockapetris, P., "Domain names - concepts and
-                facilities", STD 13, RFC 1034, November 1987.
-
-                Mockapetris, P., "Domain names - implementation and
-                specification", STD 13, RFC 1035, November 1987.
-
-Informative References
-
-   [ISO-8859-1] International Standards Organization, Standard for
-                Character Encodings, Latin-1.
-
-   [ISO-8859-2] International Standards Organization, Standard for
-                Character Encodings, Latin-2.
-
-   [RFC1183]    Everhart, C., Mamakos, L., Ullmann, R., and P.
-                Mockapetris, "New DNS RR Definitions", RFC 1183, October
-                1990.
-
-   [RFC1591]    Postel, J., "Domain Name System Structure and
-                Delegation", RFC 1591, March 1994.
-
-   [RFC2606]    Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
-                Names", BCP 32, RFC 2606, June 1999.
-
-   [RFC2929]    Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
-                "Domain Name System (DNS) IANA Considerations", BCP 42,
-                RFC 2929, September 2000.
-
-   [RFC2671]    Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
-                2671, August 1999.
-
-   [RFC2673]    Crawford, M., "Binary Labels in the Domain Name System",
-                RFC 2673, August 1999.
-
-   [RFC3092]    Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology
-                of "Foo"", RFC 3092, 1 April 2001.
-
-   [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.
-
-
-
-Eastlake 3rd                Standards Track                     [Page 8]
-
-RFC 4343          DNS Case Insensitivity Clarification      January 2006
-
-
-   [RFC3454]    Hoffman, P. and M. Blanchet, "Preparation of
-                Internationalized Strings ("stringprep")", RFC 3454,
-                December 2002.
-
-   [RFC3490]    Faltstrom, P., Hoffman, P., and A. Costello,
-                "Internationalizing Domain Names in Applications
-                (IDNA)", RFC 3490, March 2003.
-
-   [RFC3491]    Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
-                Profile for Internationalized Domain Names (IDN)", RFC
-                3491, March 2003.
-
-   [RFC3492]    Costello, A., "Punycode: A Bootstring encoding of
-                Unicode for Internationalized Domain Names in
-                Applications (IDNA)", RFC 3492, March 2003.
-
-   [UNICODE]    The Unicode Consortium, "The Unicode Standard",
-                <http://www.unicode.org/unicode/standard/standard.html>.
-
-Author's Address
-
-   Donald E. Eastlake 3rd
-   Motorola Laboratories
-   155 Beaver Street
-   Milford, MA 01757 USA
-
-   Phone: +1 508-786-7554 (w)
-   EMail: Donald.Eastlake@motorola.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd                Standards Track                     [Page 9]
-
-RFC 4343          DNS Case Insensitivity Clarification      January 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   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.
-
-Intellectual Property
-
-   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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Eastlake 3rd                Standards Track                    [Page 10]
-
diff --git a/contrib/bind9/doc/rfc/rfc4367.txt b/contrib/bind9/doc/rfc/rfc4367.txt
deleted file mode 100644
index f066b64..0000000
--- a/contrib/bind9/doc/rfc/rfc4367.txt
+++ /dev/null
@@ -1,955 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                  J. Rosenberg, Ed.
-Request for Comments: 4367                                           IAB
-Category: Informational                                    February 2006
-
-
-          What's in a Name: False Assumptions about DNS Names
-
-Status of This Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   The Domain Name System (DNS) provides an essential service on the
-   Internet, mapping structured names to a variety of data, usually IP
-   addresses.  These names appear in email addresses, Uniform Resource
-   Identifiers (URIs), and other application-layer identifiers that are
-   often rendered to human users.  Because of this, there has been a
-   strong demand to acquire names that have significance to people,
-   through equivalence to registered trademarks, company names, types of
-   services, and so on.  There is a danger in this trend; the humans and
-   automata that consume and use such names will associate specific
-   semantics with some names and thereby make assumptions about the
-   services that are, or should be, provided by the hosts associated
-   with the names.  Those assumptions can often be false, resulting in a
-   variety of failure conditions.  This document discusses this problem
-   in more detail and makes recommendations on how it can be avoided.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rosenberg                    Informational                      [Page 1]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. Target Audience .................................................4
-   3. Modeling Usage of the DNS .......................................4
-   4. Possible Assumptions ............................................5
-      4.1. By the User ................................................5
-      4.2. By the Client ..............................................6
-      4.3. By the Server ..............................................7
-   5. Consequences of False Assumptions ...............................8
-   6. Reasons Why the Assumptions Can Be False ........................9
-      6.1. Evolution ..................................................9
-      6.2. Leakage ...................................................10
-      6.3. Sub-Delegation ............................................10
-      6.4. Mobility ..................................................12
-      6.5. Human Error ...............................................12
-   7. Recommendations ................................................12
-   8. A Note on RFC 2219 and RFC 2782 ................................13
-   9. Security Considerations ........................................14
-   10. Acknowledgements ..............................................14
-   11. IAB Members ...................................................14
-   12. Informative References ........................................15
-
-1.  Introduction
-
-   The Domain Name System (DNS) [1] provides an essential service on the
-   Internet, mapping structured names to a variety of different types of
-   data.  Most often it is used to obtain the IP address of a host
-   associated with that name [2] [1] [3].  However, it can be used to
-   obtain other information, and proposals have been made for nearly
-   everything, including geographic information [4].
-
-   Domain names are most often used in identifiers used by application
-   protocols.  The most well known include email addresses and URIs,
-   such as the HTTP URL [5], Real Time Streaming Protocol (RTSP) URL
-   [6], and SIP URI [7].  These identifiers are ubiquitous, appearing on
-   business cards, web pages, street signs, and so on.  Because of this,
-   there has been a strong demand to acquire domain names that have
-   significance to people through equivalence to registered trademarks,
-   company names, types of services, and so on.  Such identifiers serve
-   many business purposes, including extension of brand, advertising,
-   and so on.
-
-   People often make assumptions about the type of service that is or
-   should be provided by a host associated with that name, based on
-   their expectations and understanding of what the name implies.  This,
-   in turn, triggers attempts by organizations to register domain names
-   based on that presumed user expectation.  Examples of this are the
-
-
-
-Rosenberg                    Informational                      [Page 2]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-   various proposals for a Top-Level Domain (TLD) that could be
-   associated with adult content [8], the requests for creation of TLDs
-   associated with mobile devices and services, and even phishing
-   attacks.
-
-   When these assumptions are codified into the behavior of an
-   automaton, such as an application client or server, as a result of
-   implementor choice, management directive, or domain owner policy, the
-   overall system can fail in various ways.  This document describes a
-   number of typical ways in which these assumptions can be codified,
-   how they can be wrong, the consequences of those mistakes, and the
-   recommended ways in which they can be avoided.
-
-   Section 4 describes some of the possible assumptions that clients,
-   servers, and people can make about a domain name.  In this context,
-   an "assumption" is defined as any behavior that is expected when
-   accessing a service at a domain name, even though the behavior is not
-   explicitly codified in protocol specifications.  Frequently, these
-   assumptions involve ignoring parts of a specification based on an
-   assumption that the client or server is deployed in an environment
-   that is more rigid than the specification allows.  Section 5
-   overviews some of the consequences of these false assumptions.
-   Generally speaking, these consequences can include a variety of
-   different interoperability failures, user experience failures, and
-   system failures.  Section 6 discusses why these assumptions can be
-   false from the very beginning or become false at some point in the
-   future.  Most commonly, they become false because the environment
-   changes in unexpected ways over time, and what was a valid assumption
-   before, no longer is.  Other times, the assumptions prove wrong
-   because they were based on the belief that a specific community of
-   clients and servers was participating, and an element outside of that
-   community began participating.
-
-   Section 7 then provides some recommendations.  These recommendations
-   encapsulate some of the engineering mantras that have been at the
-   root of Internet protocol design for decades.  These include:
-
-      Follow the specifications.
-
-      Use the capability negotiation techniques provided in the
-      protocols.
-
-      Be liberal in what you accept, and conservative in what you send.
-      [18]
-
-   Overall, automata should not change their behavior within a protocol
-   based on the domain name, or some component of the domain name, of
-   the host they are communicating with.
-
-
-
-Rosenberg                    Informational                      [Page 3]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-2.  Target Audience
-
-   This document has several audiences.  Firstly, it is aimed at
-   implementors who ultimately develop the software that make the false
-   assumptions that are the subject of this document.  The
-   recommendations described here are meant to reinforce the engineering
-   guidelines that are often understood by implementors, but frequently
-   forgotten as deadlines near and pressures mount.
-
-   The document is also aimed at technology managers, who often develop
-   the requirements that lead to these false assumptions.  For them,
-   this document serves as a vehicle for emphasizing the importance of
-   not taking shortcuts in the scope of applicability of a project.
-
-   Finally, this document is aimed at domain name policy makers and
-   administrators.  For them, it points out the perils in establishing
-   domain policies that get codified into the operation of applications
-   running within that domain.
-
-3.  Modeling Usage of the DNS
-
-
-                       +--------+
-                       |        |
-                       |        |
-                       |  DNS   |
-                       |Service |
-                       |        |
-                       +--------+
-                         ^   |
-                         |   |
-                         |   |
-                         |   |
-          /--\           |   |
-         |    |          |   V
-         |    |        +--------+                     +--------+
-          \--/         |        |                     |        |
-            |          |        |                     |        |
-         ---+---       | Client |-------------------->| Server |
-            |          |        |                     |        |
-            |          |        |                     |        |
-           /\          +--------+                     +--------+
-          /  \
-         /    \
-
-         User
-                                 Figure 1
-
-
-
-
-Rosenberg                    Informational                      [Page 4]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-   Figure 1 shows a simple conceptual model of how the DNS is used by
-   applications.  A user of the application obtains an identifier for
-   particular content or service it wishes to obtain.  This identifier
-   is often a URL or URI that contains a domain name.  The user enters
-   this identifier into its client application (for example, by typing
-   in the URL in a web browser window).  The client is the automaton (a
-   software and/or hardware system) that contacts a server for that
-   application in order to provide service to the user.  To do that, it
-   contacts a DNS server to resolve the domain name in the identifier to
-   an IP address.  It then contacts the server at that IP address.  This
-   simple model applies to application protocols such as HTTP [5], SIP
-   [7], RTSP [6], and SMTP [9].
-
-   >From this model, it is clear that three entities in the system can
-   potentially make false assumptions about the service provided by the
-   server.  The human user may form expectations relating to the content
-   of the service based on a parsing of the host name from which the
-   content originated.  The server might assume that the client
-   connecting to it supports protocols that it does not, can process
-   content that it cannot, or has capabilities that it does not.
-   Similarly, the client might assume that the server supports
-   protocols, content, or capabilities that it does not.  Furthermore,
-   applications can potentially contain a multiplicity of humans,
-   clients, and servers, all of which can independently make these false
-   assumptions.
-
-4.  Possible Assumptions
-
-   For each of the three elements, there are many types of false
-   assumptions that can be made.
-
-4.1.  By the User
-
-   The set of possible assumptions here is nearly boundless.  Users
-   might assume that an HTTP URL that looks like a company name maps to
-   a server run by that company.  They might assume that an email from a
-   email address in the .gov TLD is actually from a government employee.
-   They might assume that the content obtained from a web server within
-   a TLD labeled as containing adult materials (for example, .sex)
-   actually contains adult content [8].  These assumptions are
-   unavoidable, may all be false, and are not the focus of this
-   document.
-
-
-
-
-
-
-
-
-
-Rosenberg                    Informational                      [Page 5]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-4.2.  By the Client
-
-   Even though the client is an automaton, it can make some of the same
-   assumptions that a human user might make.  For example, many clients
-   assume that any host with a hostname that begins with "www" is a web
-   server, even though this assumption may be false.
-
-   In addition, the client concerns itself with the protocols needed to
-   communicate with the server.  As a result, it might make assumptions
-   about the operation of the protocols for communicating with the
-   server.  These assumptions manifest themselves in an implementation
-   when a standardized protocol negotiation technique defined by the
-   protocol is ignored, and instead, some kind of rule is coded into the
-   software that comes to its own conclusion about what the negotiation
-   would have determined.  The result is often a loss of
-   interoperability, degradation in reliability, and worsening of user
-   experience.
-
-   Authentication Algorithm: Though a protocol might support a
-      multiplicity of authentication techniques, a client might assume
-      that a server always supports one that is only optional according
-      to the protocol.  For example, a SIP client contacting a SIP
-      server in a domain that is apparently used to identify mobile
-      devices (for example, www.example.cellular) might assume that the
-      server supports the optional Authentication and Key Agreement
-      (AKA) digest technique [10], just because of the domain name that
-      was used to access the server.  As another example, a web client
-      might assume that a server with the name https.example.com
-      supports HTTP over Transport Layer Security (TLS) [16].
-
-   Data Formats: Though a protocol might allow a multiplicity of data
-      formats to be sent from the server to the client, the client might
-      assume a specific one, rather than using the content labeling and
-      negotiation capabilities of the underlying protocol.  For example,
-      an RTSP client might assume that all audio content delivered to it
-      from media.example.cellular uses a low-bandwidth codec.  As
-      another example, a mail client might assume that the contents of
-      messages it retrieves from a mail server at mail.example.cellular
-      are always text, instead of checking the MIME headers [11] in the
-      message in order to determine the actual content type.
-
-   Protocol Extensions: A client may attempt an operation on the server
-      that requires the server to support an optional protocol
-      extension.  However, rather than implementing the necessary
-      fallback logic, the client may falsely assume that the extension
-      is supported.  As an example, a SIP client that requires reliable
-      provisional responses to its request (RFC 3262 [17]) might assume
-      that this extension is supported on servers in the domain
-
-
-
-Rosenberg                    Informational                      [Page 6]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-      sip.example.telecom.  Furthermore, the client would not implement
-      the fallback behavior defined in RFC 3262, since it would assume
-      that all servers it will communicate with are in this domain and
-      that all therefore support this extension.  However, if the
-      assumptions prove wrong, the client is unable to make any phone
-      calls.
-
-   Languages: A client may support facilities for processing text
-      content differently depending on the language of the text.  Rather
-      than determining the language from markers in the message from the
-      server, the client might assume a language based on the domain
-      name.  This assumption can easily be wrong.  For example, a client
-      might assume that any text in a web page retrieved from a server
-      within the .de country code TLD (ccTLD) is in German, and attempt
-      a translation to Finnish.  This would fail dramatically if the
-      text was actually in French.  Unfortunately, this client behavior
-      is sometimes exhibited because the server has not properly labeled
-      the language of the content in the first place, often because the
-      server assumed such a labeling was not needed.  This is an example
-      of how these false assumptions can create vicious cycles.
-
-4.3.  By the Server
-
-   The server, like the client, is an automaton.  Let us consider one
-   servicing a particular domain -- www.company.cellular, for example.
-   It might assume that all clients connecting to this domain support
-   particular capabilities, rather than using the underlying protocol to
-   make this determination.  Some examples include:
-
-   Authentication Algorithm: The server can assume that a client
-      supports a particular, optional, authentication technique, and it
-      therefore does not support the mandatory one.
-
-   Language: The server can serve content in a particular language,
-      based on an assumption that clients accessing the domain speak a
-      particular language, or based on an assumption that clients coming
-      from a particular IP address speak a certain language.
-
-   Data Formats: The server can assume that the client supports a
-      particular set of MIME types and is only capable of sending ones
-      within that set.  When it generates content in a protocol
-      response, it ignores any content negotiation headers that were
-      present in the request.  For example, a web server might ignore
-      the Accept HTTP header field and send a specific image format.
-
-
-
-
-
-
-
-Rosenberg                    Informational                      [Page 7]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-   Protocol Extensions: The server might assume that the client supports
-      a particular optional protocol extension, and so it does not
-      support the fallback behavior necessary in the case where the
-      client does not.
-
-   Client Characteristics: The server might assume certain things about
-      the physical characteristics of its clients, such as memory
-      footprint, processing power, screen sizes, screen colors, pointing
-      devices, and so on.  Based on these assumptions, it might choose
-      specific behaviors when processing a request.  For example, a web
-      server might always assume that clients connect through cell
-      phones, and therefore return content that lacks images and is
-      tuned for such devices.
-
-5.  Consequences of False Assumptions
-
-   There are numerous negative outcomes that can arise from the various
-   false assumptions that users, servers, and clients can make.  These
-   include:
-
-   Interoperability Failure: In these cases, the client or server
-      assumed some kind of protocol operation, and this assumption was
-      wrong.  The result is that the two are unable to communicate, and
-      the user receives some kind of an error.  This represents a total
-      interoperability failure, manifesting itself as a lack of service
-      to users of the system.  Unfortunately, this kind of failure
-      persists.  Repeated attempts over time by the client to access the
-      service will fail.  Only a change in the server or client software
-      can fix this problem.
-
-   System Failure: In these cases, the client or server misinterpreted a
-      protocol operation, and this misinterpretation was serious enough
-      to uncover a bug in the implementation.  The bug causes a system
-      crash or some kind of outage, either transient or permanent (until
-      user reset).  If this failure occurs in a server, not only will
-      the connecting client lose service, but other clients attempting
-      to connect will not get service.  As an example, if a web server
-      assumes that content passed to it from a client (created, for
-      example, by a digital camera) is of a particular content type, and
-      it always passes image content to a codec for decompression prior
-      to storage, the codec might crash when it unexpectedly receives an
-      image compressed in a different format.  Of course, it might crash
-      even if the Content-Type was correct, but the compressed bitstream
-      was invalid.  False assumptions merely introduce additional
-      failure cases.
-
-
-
-
-
-
-Rosenberg                    Informational                      [Page 8]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-   Poor User Experience: In these cases, the client and server
-      communicate, but the user receives a diminished user experience.
-      For example, if a client on a PC connects to a web site that
-      provides content for mobile devices, the content may be
-      underwhelming when viewed on the PC.  Or, a client accessing a
-      streaming media service may receive content of very low bitrate,
-      even though the client supported better codecs.  Indeed, if a user
-      wishes to access content from both a cellular device and a PC
-      using a shared address book (that is, an address book shared
-      across multiple devices), the user would need two entries in that
-      address book, and would need to use the right one from the right
-      device.  This is a poor user experience.
-
-   Degraded Security: In these cases, a weaker security mechanism is
-      used than the one that ought to have been used.  As an example, a
-      server in a domain might assume that it is only contacted by
-      clients with a limited set of authentication algorithms, even
-      though the clients have been recently upgraded to support a
-      stronger set.
-
-6.  Reasons Why the Assumptions Can Be False
-
-   Assumptions made by clients and servers about the operation of
-   protocols when contacting a particular domain are brittle, and can be
-   wrong for many reasons.  On the server side, many of the assumptions
-   are based on the notion that a domain name will only be given to, or
-   used by, a restricted set of clients.  If the holder of the domain
-   name assumes something about those clients, and can assume that only
-   those clients use the domain name, then it can configure or program
-   the server to operate specifically for those clients.  Both parts of
-   this assumption can be wrong, as discussed in more detail below.
-
-   On the client side, the notion is similar, being based on the
-   assumption that a server within a particular domain will provide a
-   specific type of service.  Sub-delegation and evolution, both
-   discussed below, can make these assumptions wrong.
-
-6.1.  Evolution
-
-   The Internet and the devices that access it are constantly evolving,
-   often at a rapid pace.  Unfortunately, there is a tendency to build
-   for the here and now, and then worry about the future at a later
-   time.  Many of the assumptions above are predicated on
-   characteristics of today's clients and servers.  Support for specific
-   protocols, authentication techniques, or content are based on today's
-   standards and today's devices.  Even though they may, for the most
-   part, be true, they won't always be.  An excellent example is mobile
-   devices.  A server servicing a domain accessed by mobile devices
-
-
-
-Rosenberg                    Informational                      [Page 9]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-   might try to make assumptions about the protocols, protocol
-   extensions, security mechanisms, screen sizes, or processor power of
-   such devices.  However, all of these characteristics can and will
-   change over time.
-
-   When they do change, the change is usually evolutionary.  The result
-   is that the assumptions remain valid in some cases, but not in
-   others.  It is difficult to fix such systems, since it requires the
-   server to detect what type of client is connecting, and what its
-   capabilities are.  Unless the system is built and deployed with these
-   capability negotiation techniques built in to begin with, such
-   detection can be extremely difficult.  In fact, fixing it will often
-   require the addition of such capability negotiation features that, if
-   they had been in place and used to begin with, would have avoided the
-   problem altogether.
-
-6.2.  Leakage
-
-   Servers also make assumptions because of the belief that they will
-   only be accessed by specific clients, and in particular, those that
-   are configured or provisioned to use the domain name.  In essence,
-   there is an assumption of community -- that a specific community
-   knows and uses the domain name, while others outside of the community
-   do not.
-
-   The problem is that this notion of community is a false one.  The
-   Internet is global.  The DNS is global.  There is no technical
-   barrier that separates those inside of the community from those
-   outside.  The ease with which information propagates across the
-   Internet makes it extremely likely that such domain names will
-   eventually find their way into clients outside of the presumed
-   community.  The ubiquitous presence of domain names in various URI
-   formats, coupled with the ease of conveyance of URIs, makes such
-   leakage merely a matter of time.  Furthermore, since the DNS is
-   global, and since it can only have one root [12], it becomes possible
-   for clients outside of the community to search and find and use such
-   "special" domain names.
-
-   Indeed, this leakage is a strength of the Internet architecture, not
-   a weakness.  It enables global access to services from any client
-   with a connection to the Internet.  That, in turn, allows for rapid
-   growth in the number of customers for any particular service.
-
-6.3.  Sub-Delegation
-
-   Clients and users make assumptions about domains because of the
-   notion that there is some kind of centralized control that can
-   enforce those assumptions.  However, the DNS is not centralized; it
-
-
-
-Rosenberg                    Informational                     [Page 10]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-   is distributed.  If a domain doesn't delegate its sub-domains and has
-   its records within a single zone, it is possible to maintain a
-   centralized policy about operation of its domain.  However, once a
-   domain gets sufficiently large that the domain administrators begin
-   to delegate sub-domains to other authorities, it becomes increasingly
-   difficult to maintain any kind of central control on the nature of
-   the service provided in each sub-domain.
-
-   Similarly, the usage of domain names with human semantic connotation
-   tends to lead to a registration of multiple domains in which a
-   particular service is to run.  As an example, a service provider with
-   the name "example" might register and set up its services in
-   "example.com", "example.net", and generally example.foo for each foo
-   that is a valid TLD.  This, like sub-delegation, results in a growth
-   in the number of domains over which it is difficult to maintain
-   centralized control.
-
-   Not that it is not possible, since there are many examples of
-   successful administration of policies across sub-domains many levels
-   deep.  However, it takes an increasing amount of effort to ensure
-   this result, as it requires human intervention and the creation of
-   process and procedure.  Automated validation of adherence to policies
-   is very difficult to do, as there is no way to automatically verify
-   many policies that might be put into place.
-
-   A less costly process for providing centralized management of
-   policies is to just hope that any centralized policies are being
-   followed, and then wait for complaints or perform random audits.
-   Those approaches have many problems.
-
-   The invalidation of assumptions due to sub-delegation is discussed in
-   further detail in Section 4.1.3 of [8] and in Section 3.3 of [20].
-
-   As a result of the fragility of policy continuity across sub-
-   delegations, if a client or user assumes some kind of property
-   associated with a TLD (such as ".wifi"), it becomes increasingly more
-   likely with the number of sub-domains that this property will not
-   exist in a server identified by a particular name.  For example, in
-   "store.chain.company.provider.wifi", there may be four levels of
-   delegation from ".wifi", making it quite likely that, unless the
-   holder of ".wifi" is working diligently, the properties that the
-   holder of ".wifi" wishes to enforce are not present.  These
-   properties may not be present due to human error or due to a willful
-   decision not to adhere to them.
-
-
-
-
-
-
-
-Rosenberg                    Informational                     [Page 11]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-6.4.  Mobility
-
-   One of the primary value propositions of a hostname as an identifier
-   is its persistence.  A client can change IP addresses, yet still
-   retain a persistent identifier used by other hosts to reach it.
-   Because their value derives from their persistence, hostnames tend to
-   move with a host not just as it changes IP addresses, but as it
-   changes access network providers and technologies.  For this reason,
-   assumptions made about a host based on the presumed access network
-   corresponding to that hostname tend to be wrong over time.  As an
-   example, a PC might normally be connected to its broadband provider,
-   and through dynamic DNS have a hostname within the domain of that
-   provider.  However, one cannot assume that any host within that
-   network has access over a broadband link; the user could connect
-   their PC over a low-bandwidth wireless access network and still
-   retain its domain name.
-
-6.5.  Human Error
-
-   Of course, human error can be the source of errors in any system, and
-   the same is true here.  There are many examples relevant to the
-   problem under discussion.
-
-   A client implementation may make the assumption that, just because a
-   DNS SRV record exists for a particular protocol in a particular
-   domain, indicating that the service is available on some port, that
-   the service is, in fact, running there.  This assumption could be
-   wrong because the SRV records haven't been updated by the system
-   administrators to reflect the services currently running.  As another
-   example, a client might assume that a particular domain policy
-   applies to all sub-domains.  However, a system administrator might
-   have omitted to apply the policy to servers running in one of those
-   sub-domains.
-
-7.  Recommendations
-
-   Based on these problems, the clear conclusion is that clients,
-   servers, and users should not make assumptions on the nature of the
-   service provided to, or by, a domain.  More specifically, however,
-   the following can be said:
-
-   Follow the specifications: When specifications define mandatory
-      baseline procedures and formats, those should be implemented and
-      supported, even if the expectation is that optional procedures
-      will most often be used.  For example, if a specification mandates
-      a particular baseline authentication technique, but allows others
-      to be negotiated and used, implementations need to implement the
-      baseline authentication algorithm even if the other ones are used
-
-
-
-Rosenberg                    Informational                     [Page 12]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-      most of the time.  Put more simply, the behavior of the protocol
-      machinery should never change based on the domain name of the
-      host.
-
-   Use capability negotiation: Many protocols are engineered with
-      capability negotiation mechanisms.  For example, a content
-      negotiation framework has been defined for protocols using MIME
-      content [13] [14] [15].  SIP allows for clients to negotiate the
-      media types used in the multimedia session, as well as protocol
-      parameters.  HTTP allows for clients to negotiate the media types
-      returned in requests for content.  When such features are
-      available in a protocol, client and servers should make use of
-      them rather than making assumptions about supported capabilities.
-      A corollary is that protocol designers should include such
-      mechanisms when evolution is expected in the usage of the
-      protocol.
-
-   "Be liberal in what you accept, and conservative in what you send"
-      [18]:  This axiom of Internet protocol design is applicable here
-      as well.  Implementations should be prepared for the full breadth
-      of what a protocol allows another entity to send, rather than be
-      limiting in what it is willing to receive.
-
-   To summarize -- there is never a need to make assumptions.  Rather
-   than doing so, utilize the specifications and the negotiation
-   capabilities they provide, and the overall system will be robust and
-   interoperable.
-
-8.  A Note on RFC 2219 and RFC 2782
-
-   Based on the definition of an assumption given here, the behavior
-   hinted at by records in the DNS also represents an assumption.  RFC
-   2219 [19] defines well-known aliases that can be used to construct
-   domain names for reaching various well-known services in a domain.
-   This approach was later followed by the definition of a new resource
-   record, the SRV record [2], which specifies that a particular service
-   is running on a server in a domain.  Although both of these
-   mechanisms are useful as a hint that a particular service is running
-   in a domain, both of them represent assumptions that may be false.
-   However, they differ in the set of reasons why those assumptions
-   might be false.
-
-   A client that assumes that "ftp.example.com" is an FTP server may be
-   wrong because the presumed naming convention in RFC 2219 was not
-   known by, or not followed by, the owner of domain.com.  With RFC
-   2782, an SRV record for a particular service would be present only by
-   explicit choice of the domain administrator, and thus a client that
-
-
-
-
-Rosenberg                    Informational                     [Page 13]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-   assumes that the corresponding host provides this service would be
-   wrong only because of human error in configuration.  In this case,
-   the assumption is less likely to be wrong, but it certainly can be.
-
-   The only way to determine with certainty that a service is running on
-   a host is to initiate a connection to the port for that service, and
-   check.  Implementations need to be careful not to codify any
-   behaviors that cause failures should the information provided in the
-   record actually be false.  This borders on common sense for robust
-   implementations, but it is valuable to raise this point explicitly.
-
-9.  Security Considerations
-
-   One of the assumptions that can be made by clients or servers is the
-   availability and usage (or lack thereof) of certain security
-   protocols and algorithms.  For example, a client accessing a service
-   in a particular domain might assume a specific authentication
-   algorithm or hash function in the application protocol.  It is
-   possible that, over time, weaknesses are found in such a technique,
-   requiring usage of a different mechanism.  Similarly, a system might
-   start with an insecure mechanism, and then decide later on to use a
-   secure one.  In either case, assumptions made on security properties
-   can result in interoperability failures, or worse yet, providing
-   service in an insecure way, even though the client asked for, and
-   thought it would get, secure service.  These kinds of assumptions are
-   fundamentally unsound even if the records themselves are secured with
-   DNSSEC.
-
-10.  Acknowledgements
-
-   The IAB would like to thank John Klensin, Keith Moore and Peter Koch
-   for their comments.
-
-11.  IAB Members
-
-   Internet Architecture Board members at the time of writing of this
-   document are:
-
-      Bernard Aboba
-
-      Loa Andersson
-
-      Brian Carpenter
-
-      Leslie Daigle
-
-      Patrik Faltstrom
-
-
-
-
-Rosenberg                    Informational                     [Page 14]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-      Bob Hinden
-
-      Kurtis Lindqvist
-
-      David Meyer
-
-      Pekka Nikander
-
-      Eric Rescorla
-
-      Pete Resnick
-
-      Jonathan Rosenberg
-
-12.  Informative References
-
-   [1]   Mockapetris, P., "Domain names - concepts and facilities",
-         STD 13, RFC 1034, November 1987.
-
-   [2]   Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
-         specifying the location of services (DNS SRV)", RFC 2782,
-         February 2000.
-
-   [3]   Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
-         Three: The Domain Name System (DNS) Database", RFC 3403,
-         October 2002.
-
-   [4]   Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A Means
-         for Expressing Location Information in the Domain Name System",
-         RFC 1876, January 1996.
-
-   [5]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
-         Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
-         HTTP/1.1", RFC 2616, June 1999.
-
-   [6]   Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
-         Protocol (RTSP)", RFC 2326, April 1998.
-
-   [7]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
-         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
-         Session Initiation Protocol", RFC 3261, June 2002.
-
-   [8]   Eastlake, D., ".sex Considered Dangerous", RFC 3675,
-         February 2004.
-
-   [9]   Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
-         April 2001.
-
-
-
-
-Rosenberg                    Informational                     [Page 15]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-   [10]  Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer
-         Protocol (HTTP) Digest Authentication Using Authentication and
-         Key Agreement (AKA)", RFC 3310, September 2002.
-
-   [11]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
-         Extensions (MIME) Part One: Format of Internet Message Bodies",
-         RFC 2045, November 1996.
-
-   [12]  Internet Architecture Board, "IAB Technical Comment on the
-         Unique DNS Root", RFC 2826, May 2000.
-
-   [13]  Klyne, G., "Indicating Media Features for MIME Content",
-         RFC 2912, September 2000.
-
-   [14]  Klyne, G., "A Syntax for Describing Media Feature Sets",
-         RFC 2533, March 1999.
-
-   [15]  Klyne, G., "Protocol-independent Content Negotiation
-         Framework", RFC 2703, September 1999.
-
-   [16]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
-
-   [17]  Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
-         Responses in Session Initiation Protocol (SIP)", RFC 3262,
-         June 2002.
-
-   [18]  Braden, R., "Requirements for Internet Hosts - Communication
-         Layers", STD 3, RFC 1122, October 1989.
-
-   [19]  Hamilton, M. and R. Wright, "Use of DNS Aliases for Network
-         Services", BCP 17, RFC 2219, October 1997.
-
-   [20]  Faltstrom, P., "Design Choices When Expanding DNS", Work in
-         Progress, June 2005.
-
-Author's Address
-
-   Jonathan Rosenberg, Editor
-   IAB
-   600 Lanidex Plaza
-   Parsippany, NJ  07054
-   US
-
-   Phone: +1 973 952-5000
-   EMail: jdrosen@cisco.com
-   URI:   http://www.jdrosen.net
-
-
-
-
-
-Rosenberg                    Informational                     [Page 16]
-
-RFC 4367                    Name Assumptions               February 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   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.
-
-Intellectual Property
-
-   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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Rosenberg                    Informational                     [Page 17]
-
diff --git a/contrib/bind9/doc/rfc/rfc4398.txt b/contrib/bind9/doc/rfc/rfc4398.txt
deleted file mode 100644
index 6437436..0000000
--- a/contrib/bind9/doc/rfc/rfc4398.txt
+++ /dev/null
@@ -1,955 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       S. Josefsson
-Request for Comments: 4398                                    March 2006
-Obsoletes: 2538
-Category: Standards Track
-
-
-          Storing Certificates in the Domain Name System (DNS)
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   Cryptographic public keys are frequently published, and their
-   authenticity is demonstrated by certificates.  A CERT resource record
-   (RR) is defined so that such certificates and related certificate
-   revocation lists can be stored in the Domain Name System (DNS).
-
-   This document obsoletes RFC 2538.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 1]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-Table of Contents
-
-   1. Introduction ....................................................3
-   2. The CERT Resource Record ........................................3
-      2.1. Certificate Type Values ....................................4
-      2.2. Text Representation of CERT RRs ............................6
-      2.3. X.509 OIDs .................................................6
-   3. Appropriate Owner Names for CERT RRs ............................7
-      3.1. Content-Based X.509 CERT RR Names ..........................8
-      3.2. Purpose-Based X.509 CERT RR Names ..........................9
-      3.3. Content-Based OpenPGP CERT RR Names ........................9
-      3.4. Purpose-Based OpenPGP CERT RR Names .......................10
-      3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX ...........10
-   4. Performance Considerations .....................................11
-   5. Contributors ...................................................11
-   6. Acknowledgements ...............................................11
-   7. Security Considerations ........................................12
-   8. IANA Considerations ............................................12
-   9. Changes since RFC 2538 .........................................13
-   10. References ....................................................14
-      10.1. Normative References .....................................14
-      10.2. Informative References ...................................15
-   Appendix A.  Copying Conditions ...................................16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 2]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-1.  Introduction
-
-   Public keys are frequently published in the form of a certificate,
-   and their authenticity is commonly demonstrated by certificates and
-   related certificate revocation lists (CRLs).  A certificate is a
-   binding, through a cryptographic digital signature, of a public key,
-   a validity interval and/or conditions, and identity, authorization,
-   or other information.  A certificate revocation list is a list of
-   certificates that are revoked, and of incidental information, all
-   signed by the signer (issuer) of the revoked certificates.  Examples
-   are X.509 certificates/CRLs in the X.500 directory system or OpenPGP
-   certificates/revocations used by OpenPGP software.
-
-   Section 2 specifies a CERT resource record (RR) for the storage of
-   certificates in the Domain Name System [1] [2].
-
-   Section 3 discusses appropriate owner names for CERT RRs.
-
-   Sections 4, 7, and 8 cover performance, security, and IANA
-   considerations, respectively.
-
-   Section 9 explains the changes in this document compared to RFC 2538.
-
-   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 [3].
-
-2.  The CERT Resource Record
-
-   The CERT resource record (RR) has the structure given below.  Its RR
-   type code is 37.
-
-                       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              |             key tag           |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |   algorithm   |                                               /
-   +---------------+            certificate or CRL                 /
-   /                                                               /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
-
-   The type field is the certificate type as defined in Section 2.1
-   below.
-
-   The key tag field is the 16-bit value computed for the key embedded
-   in the certificate, using the RRSIG Key Tag algorithm described in
-   Appendix B of [12].  This field is used as an efficiency measure to
-
-
-
-Josefsson                   Standards Track                     [Page 3]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-   pick which CERT RRs may be applicable to a particular key.  The key
-   tag can be calculated for the key in question, and then only CERT RRs
-   with the same key tag need to be examined.  Note that two different
-   keys can have the same key tag.  However, the key MUST be transformed
-   to the format it would have as the public key portion of a DNSKEY RR
-   before the key tag is computed.  This is only possible if the key is
-   applicable to an algorithm and complies to limits (such as key size)
-   defined for DNS security.  If it is not, the algorithm field MUST be
-   zero and the tag field is meaningless and SHOULD be zero.
-
-   The algorithm field has the same meaning as the algorithm field in
-   DNSKEY and RRSIG RRs [12], except that a zero algorithm field
-   indicates that the algorithm is unknown to a secure DNS, which may
-   simply be the result of the algorithm not having been standardized
-   for DNSSEC [11].
-
-2.1.  Certificate Type Values
-
-   The following values are defined or reserved:
-
-         Value  Mnemonic  Certificate Type
-         -----  --------  ----------------
-             0            Reserved
-             1  PKIX      X.509 as per PKIX
-             2  SPKI      SPKI certificate
-             3  PGP       OpenPGP packet
-             4  IPKIX     The URL of an X.509 data object
-             5  ISPKI     The URL of an SPKI certificate
-             6  IPGP      The fingerprint and URL of an OpenPGP packet
-             7  ACPKIX    Attribute Certificate
-             8  IACPKIX   The URL of an Attribute Certificate
-         9-252            Available for IANA assignment
-           253  URI       URI private
-           254  OID       OID private
-           255            Reserved
-     256-65279            Available for IANA assignment
-   65280-65534            Experimental
-         65535            Reserved
-
-   These values represent the initial content of the IANA registry; see
-   Section 8.
-
-   The PKIX type is reserved to indicate an X.509 certificate conforming
-   to the profile defined by the IETF PKIX working group [8].  The
-   certificate section will start with a one-octet unsigned OID length
-   and then an X.500 OID indicating the nature of the remainder of the
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 4]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-   certificate section (see Section 2.3, below).  (NOTE: X.509
-   certificates do not include their X.500 directory-type-designating
-   OID as a prefix.)
-
-   The SPKI and ISPKI types are reserved to indicate the SPKI
-   certificate format [15], for use when the SPKI documents are moved
-   from experimental status.  The format for these two CERT RR types
-   will need to be specified later.
-
-   The PGP type indicates an OpenPGP packet as described in [5] and its
-   extensions and successors.  This is used to transfer public key
-   material and revocation signatures.  The data is binary and MUST NOT
-   be encoded into an ASCII armor.  An implementation SHOULD process
-   transferable public keys as described in Section 10.1 of [5], but it
-   MAY handle additional OpenPGP packets.
-
-   The ACPKIX type indicates an Attribute Certificate format [9].
-
-   The IPKIX and IACPKIX types indicate a URL that will serve the
-   content that would have been in the "certificate, CRL, or URL" field
-   of the corresponding type (PKIX or ACPKIX, respectively).
-
-   The IPGP type contains both an OpenPGP fingerprint for the key in
-   question, as well as a URL.  The certificate portion of the IPGP CERT
-   RR is defined as a one-octet fingerprint length, followed by the
-   OpenPGP fingerprint, followed by the URL.  The OpenPGP fingerprint is
-   calculated as defined in RFC 2440 [5].  A zero-length fingerprint or
-   a zero-length URL are legal, and indicate URL-only IPGP data or
-   fingerprint-only IPGP data, respectively.  A zero-length fingerprint
-   and a zero-length URL are meaningless and invalid.
-
-   The IPKIX, ISPKI, IPGP, and IACPKIX types are known as "indirect".
-   These types MUST be used when the content is too large to fit in the
-   CERT RR and MAY be used at the implementer's discretion.  They SHOULD
-   NOT be used where the DNS message is 512 octets or smaller and could
-   thus be expected to fit a UDP packet.
-
-   The URI private type indicates a certificate format defined by an
-   absolute URI.  The certificate portion of the CERT RR MUST begin with
-   a null-terminated URI [10], and the data after the null is the
-   private format certificate itself.  The URI SHOULD be such that a
-   retrieval from it will lead to documentation on the format of the
-   certificate.  Recognition of private certificate types need not be
-   based on URI equality but can use various forms of pattern matching
-   so that, for example, subtype or version information can also be
-   encoded into the URI.
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 5]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-   The OID private type indicates a private format certificate specified
-   by an ISO OID prefix.  The certificate section will start with a
-   one-octet unsigned OID length and then a BER-encoded OID indicating
-   the nature of the remainder of the certificate section.  This can be
-   an X.509 certificate format or some other format.  X.509 certificates
-   that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
-   type, not the OID private type.  Recognition of private certificate
-   types need not be based on OID equality but can use various forms of
-   pattern matching such as OID prefix.
-
-2.2.  Text Representation of CERT RRs
-
-   The RDATA portion of a CERT RR has the type field as an unsigned
-   decimal integer or as a mnemonic symbol as listed in Section 2.1,
-   above.
-
-   The key tag field is represented as an unsigned decimal integer.
-
-   The algorithm field is represented as an unsigned decimal integer or
-   a mnemonic symbol as listed in [12].
-
-   The certificate/CRL portion is represented in base 64 [16] and may be
-   divided into any number of white-space-separated substrings, down to
-   single base-64 digits, which are concatenated to obtain the full
-   signature.  These substrings can span lines using the standard
-   parenthesis.
-
-   Note that the certificate/CRL portion may have internal sub-fields,
-   but these do not appear in the master file representation.  For
-   example, with type 254, there will be an OID size, an OID, and then
-   the certificate/CRL proper.  However, only a single logical base-64
-   string will appear in the text representation.
-
-2.3.  X.509 OIDs
-
-   OIDs have been defined in connection with the X.500 directory for
-   user certificates, certification authority certificates, revocations
-   of certification authority, and revocations of user certificates.
-   The following table lists the OIDs, their BER encoding, and their
-   length-prefixed hex format for use in CERT RRs:
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 6]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-       id-at-userCertificate
-           = { joint-iso-ccitt(2) ds(5) at(4) 36 }
-              == 0x 03 55 04 24
-       id-at-cACertificate
-           = { joint-iso-ccitt(2) ds(5) at(4) 37 }
-              == 0x 03 55 04 25
-       id-at-authorityRevocationList
-           = { joint-iso-ccitt(2) ds(5) at(4) 38 }
-              == 0x 03 55 04 26
-       id-at-certificateRevocationList
-           = { joint-iso-ccitt(2) ds(5) at(4) 39 }
-              == 0x 03 55 04 27
-
-3.  Appropriate Owner Names for CERT RRs
-
-   It is recommended that certificate CERT RRs be stored under a domain
-   name related to their subject, i.e., the name of the entity intended
-   to control the private key corresponding to the public key being
-   certified.  It is recommended that certificate revocation list CERT
-   RRs be stored under a domain name related to their issuer.
-
-   Following some of the guidelines below may result in DNS names with
-   characters that require DNS quoting as per Section 5.1 of RFC 1035
-   [2].
-
-   The choice of name under which CERT RRs are stored is important to
-   clients that perform CERT queries.  In some situations, the clients
-   may not know all information about the CERT RR object it wishes to
-   retrieve.  For example, a client may not know the subject name of an
-   X.509 certificate, or the email address of the owner of an OpenPGP
-   key.  Further, the client might only know the hostname of a service
-   that uses X.509 certificates or the Key ID of an OpenPGP key.
-
-   Therefore, two owner name guidelines are defined: content-based owner
-   names and purpose-based owner names.  A content-based owner name is
-   derived from the content of the CERT RR data; for example, the
-   Subject field in an X.509 certificate or the User ID field in OpenPGP
-   keys.  A purpose-based owner name is a name that a client retrieving
-   CERT RRs ought to know already; for example, the host name of an
-   X.509 protected service or the Key ID of an OpenPGP key.  The
-   content-based and purpose-based owner name may be the same; for
-   example, when a client looks up a key based on the From: address of
-   an incoming email.
-
-   Implementations SHOULD use the purpose-based owner name guidelines
-   described in this document and MAY use CNAME RRs at content-based
-   owner names (or other names), pointing to the purpose-based owner
-   name.
-
-
-
-Josefsson                   Standards Track                     [Page 7]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-   Note that this section describes an application-based mapping from
-   the name space used in a certificate to the name space used by DNS.
-   The DNS does not infer any relationship amongst CERT resource records
-   based on similarities or differences of the DNS owner name(s) of CERT
-   resource records.  For example, if multiple labels are used when
-   mapping from a CERT identifier to a domain name, then care must be
-   taken in understanding wildcard record synthesis.
-
-3.1.  Content-Based X.509 CERT RR Names
-
-   Some X.509 versions, such as the PKIX profile of X.509 [8], permit
-   multiple names to be associated with subjects and issuers under
-   "Subject Alternative Name" and "Issuer Alternative Name".  For
-   example, the PKIX profile has such Alternate Names with an ASN.1
-   specification as follows:
-
-      GeneralName ::= CHOICE {
-           otherName                       [0]     OtherName,
-           rfc822Name                      [1]     IA5String,
-           dNSName                         [2]     IA5String,
-           x400Address                     [3]     ORAddress,
-           directoryName                   [4]     Name,
-           ediPartyName                    [5]     EDIPartyName,
-           uniformResourceIdentifier       [6]     IA5String,
-           iPAddress                       [7]     OCTET STRING,
-           registeredID                    [8]     OBJECT IDENTIFIER }
-
-   The recommended locations of CERT storage are as follows, in priority
-   order:
-
-   1.  If a domain name is included in the identification in the
-       certificate or CRL, that ought to be used.
-   2.  If a domain name is not included but an IP address is included,
-       then the translation of that IP address into the appropriate
-       inverse domain name ought to be used.
-   3.  If neither of the above is used, but a URI containing a domain
-       name is present, that domain name ought to be used.
-   4.  If none of the above is included but a character string name is
-       included, then it ought to be treated as described below for
-       OpenPGP names.
-   5.  If none of the above apply, then the distinguished name (DN)
-       ought to be mapped into a domain name as specified in [4].
-
-   Example 1: An X.509v3 certificate is issued to /CN=John Doe /DC=Doe/
-   DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Names of (a)
-   string "John (the Man) Doe", (b) domain name john-doe.com, and (c)
-   URI <https://www.secure.john-doe.com:8080/>.  The storage locations
-   recommended, in priority order, would be
-
-
-
-Josefsson                   Standards Track                     [Page 8]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-   1.  john-doe.com,
-   2.  www.secure.john-doe.com, and
-   3.  Doe.com.xy.
-
-   Example 2: An X.509v3 certificate is issued to /CN=James Hacker/
-   L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a)
-   domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and
-   (c) string "James Hacker <hacker@mail.widget.foo.example>".  The
-   storage locations recommended, in priority order, would be
-
-   1.  widget.foo.example,
-   2.  201.13.251.10.in-addr.arpa, and
-   3.  hacker.mail.widget.foo.example.
-
-3.2.  Purpose-Based X.509 CERT RR Names
-
-   Due to the difficulty for clients that do not already possess a
-   certificate to reconstruct the content-based owner name,
-   purpose-based owner names are recommended in this section.
-   Recommendations for purpose-based owner names vary per scenario.  The
-   following table summarizes the purpose-based X.509 CERT RR owner name
-   guidelines for use with S/MIME [17], SSL/TLS [13], and IPsec [14]:
-
-    Scenario             Owner name
-    ------------------   ----------------------------------------------
-    S/MIME Certificate   Standard translation of an RFC 2822 email
-                         address.  Example: An S/MIME certificate for
-                         "postmaster@example.org" will use a standard
-                         hostname translation of the owner name,
-                         "postmaster.example.org".
-
-    TLS Certificate      Hostname of the TLS server.
-
-    IPsec Certificate    Hostname of the IPsec machine and/or, for IPv4
-                         or IPv6 addresses, the fully qualified domain
-                         name in the appropriate reverse domain.
-
-   An alternate approach for IPsec is to store raw public keys [18].
-
-3.3.  Content-Based OpenPGP CERT RR Names
-
-   OpenPGP signed keys (certificates) use a general character string
-   User ID [5].  However, it is recommended by OpenPGP that such names
-   include the RFC 2822 [7] email address of the party, as in "Leslie
-   Example <Leslie@host.example>".  If such a format is used, the CERT
-   ought to be under the standard translation of the email address into
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 9]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-   a domain name, which would be leslie.host.example in this case.  If
-   no RFC 2822 name can be extracted from the string name, no specific
-   domain name is recommended.
-
-   If a user has more than one email address, the CNAME type can be used
-   to reduce the amount of data stored in the DNS.  For example:
-
-      $ORIGIN example.org.
-      smith        IN CERT PGP 0 0 <OpenPGP binary>
-      john.smith   IN CNAME smith
-      js           IN CNAME smith
-
-3.4.  Purpose-Based OpenPGP CERT RR Names
-
-   Applications that receive an OpenPGP packet containing encrypted or
-   signed data but do not know the email address of the sender will have
-   difficulties constructing the correct owner name and cannot use the
-   content-based owner name guidelines.  However, these clients commonly
-   know the key fingerprint or the Key ID.  The key ID is found in
-   OpenPGP packets, and the key fingerprint is commonly found in
-   auxiliary data that may be available.  In this case, use of an owner
-   name identical to the key fingerprint and the key ID expressed in
-   hexadecimal [16] is recommended.  For example:
-
-      $ORIGIN example.org.
-      0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ...
-      F835EDA21E94B565716F                     IN CERT PGP ...
-      B565716F                                 IN CERT PGP ...
-
-   If the same key material is stored for several owner names, the use
-   of CNAME may help avoid data duplication.  Note that CNAME is not
-   always applicable, because it maps one owner name to the other for
-   all purposes, which may be sub-optimal when two keys with the same
-   Key ID are stored.
-
-3.5.  Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX
-
-   These types are stored under the same owner names, both purpose- and
-   content-based, as the PKIX, SPKI, PGP, and ACPKIX types.
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 10]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-4.  Performance Considerations
-
-   The Domain Name System (DNS) protocol was designed for small
-   transfers, typically below 512 octets.  While larger transfers will
-   perform correctly and work is underway to make larger transfers more
-   efficient, it is still advisable at this time that every reasonable
-   effort be made to minimize the size of certificates stored within the
-   DNS.  Steps that can be taken may include using the fewest possible
-   optional or extension fields and using short field values for
-   necessary variable-length fields.
-
-   The RDATA field in the DNS protocol may only hold data of size 65535
-   octets (64kb) or less.  This means that each CERT RR MUST NOT contain
-   more than 64kb of payload, even if the corresponding certificate or
-   certificate revocation list is larger.  This document addresses this
-   by defining "indirect" data types for each normal type.
-
-   Deploying CERT RRs to support digitally signed email changes the
-   access patterns of DNS lookups from per-domain to per-user.  If
-   digitally signed email and a key/certificate lookup based on CERT RRs
-   are deployed on a wide scale, this may lead to an increased DNS load,
-   with potential performance and cache effectiveness consequences.
-   Whether or not this load increase will be noticeable is not known.
-
-5.  Contributors
-
-   The majority of this document is copied verbatim from RFC 2538, by
-   Donald Eastlake 3rd and Olafur Gudmundsson.
-
-6.  Acknowledgements
-
-   Thanks to David Shaw and Michael Graff for their contributions to
-   earlier works that motivated, and served as inspiration for, this
-   document.
-
-   This document was improved by suggestions and comments from Olivier
-   Dubuisson, Scott Hollenbeck, Russ Housley, Peter Koch, Olaf M.
-   Kolkman, Ben Laurie, Edward Lewis, John Loughney, Allison Mankin,
-   Douglas Otis, Marcos Sanz, Pekka Savola, Jason Sloderbeck, Samuel
-   Weiler, and Florian Weimer.  No doubt the list is incomplete.  We
-   apologize to anyone we left out.
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 11]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-7.  Security Considerations
-
-   By definition, certificates contain their own authenticating
-   signatures.  Thus, it is reasonable to store certificates in
-   non-secure DNS zones or to retrieve certificates from DNS with DNS
-   security checking not implemented or deferred for efficiency.  The
-   results may be trusted if the certificate chain is verified back to a
-   known trusted key and this conforms with the user's security policy.
-
-   Alternatively, if certificates are retrieved from a secure DNS zone
-   with DNS security checking enabled and are verified by DNS security,
-   the key within the retrieved certificate may be trusted without
-   verifying the certificate chain if this conforms with the user's
-   security policy.
-
-   If an organization chooses to issue certificates for its employees,
-   placing CERT RRs in the DNS by owner name, and if DNSSEC (with NSEC)
-   is in use, it is possible for someone to enumerate all employees of
-   the organization.  This is usually not considered desirable, for the
-   same reason that enterprise phone listings are not often publicly
-   published and are even marked confidential.
-
-   Using the URI type introduces another level of indirection that may
-   open a new vulnerability.  One method of securing that indirection is
-   to include a hash of the certificate in the URI itself.
-
-   If DNSSEC is used, then the non-existence of a CERT RR and,
-   consequently, certificates or revocation lists can be securely
-   asserted.  Without DNSSEC, this is not possible.
-
-8.  IANA Considerations
-
-   The IANA has created a new registry for CERT RR: certificate types.
-   The initial contents of this registry is:
-
-       Decimal   Type     Meaning                           Reference
-       -------   ----     -------                           ---------
-             0            Reserved                          RFC 4398
-             1   PKIX     X.509 as per PKIX                 RFC 4398
-             2   SPKI     SPKI certificate                  RFC 4398
-             3   PGP      OpenPGP packet                    RFC 4398
-             4   IPKIX    The URL of an X.509 data object   RFC 4398
-             5   ISPKI    The URL of an SPKI certificate    RFC 4398
-             6   IPGP     The fingerprint and URL           RFC 4398
-                          of an OpenPGP packet
-             7   ACPKIX   Attribute Certificate             RFC 4398
-             8   IACPKIX  The URL of an Attribute           RFC 4398
-                             Certificate
-
-
-
-Josefsson                   Standards Track                    [Page 12]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-         9-252            Available for IANA assignment
-                             by IETF Standards action
-           253   URI      URI private                       RFC 4398
-           254   OID      OID private                       RFC 4398
-           255            Reserved                          RFC 4398
-     256-65279            Available for IANA assignment
-                          by IETF Consensus
-   65280-65534            Experimental                      RFC 4398
-         65535            Reserved                          RFC 4398
-
-   Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
-   only be assigned by an IETF standards action [6].  This document
-   assigns 0x0001 through 0x0008 and 0x00FD and 0x00FE.  Certificate
-   types 0x0100 through 0xFEFF are assigned through IETF Consensus [6]
-   based on RFC documentation of the certificate type.  The availability
-   of private types under 0x00FD and 0x00FE ought to satisfy most
-   requirements for proprietary or private types.
-
-   The CERT RR reuses the DNS Security Algorithm Numbers registry.  In
-   particular, the CERT RR requires that algorithm number 0 remain
-   reserved, as described in Section 2.  The IANA will reference the
-   CERT RR as a user of this registry and value 0, in particular.
-
-9.  Changes since RFC 2538
-
-   1.   Editorial changes to conform with new document requirements,
-        including splitting reference section into two parts and
-        updating the references to point at latest versions, and to add
-        some additional references.
-   2.   Improve terminology.  For example replace "PGP" with "OpenPGP",
-        to align with RFC 2440.
-   3.   In Section 2.1, clarify that OpenPGP public key data are binary,
-        not the ASCII armored format, and reference 10.1 in RFC 2440 on
-        how to deal with OpenPGP keys, and acknowledge that
-        implementations may handle additional packet types.
-   4.   Clarify that integers in the representation format are decimal.
-   5.   Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis
-        terminology.  Improve reference for Key Tag Algorithm
-        calculations.
-   6.   Add examples that suggest use of CNAME to reduce bandwidth.
-   7.   In Section 3, appended the last paragraphs that discuss
-        "content-based" vs "purpose-based" owner names.  Add Section 3.2
-        for purpose-based X.509 CERT owner names, and Section 3.4 for
-        purpose-based OpenPGP CERT owner names.
-   8.   Added size considerations.
-   9.   The SPKI types has been reserved, until RFC 2692/2693 is moved
-        from the experimental status.
-   10.  Added indirect types IPKIX, ISPKI, IPGP, and IACPKIX.
-
-
-
-Josefsson                   Standards Track                    [Page 13]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-   11.  An IANA registry of CERT type values was created.
-
-10.  References
-
-10.1.  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., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-   [4]   Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri,
-         "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
-         January 1998.
-
-   [5]   Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
-         "OpenPGP Message Format", RFC 2440, November 1998.
-
-   [6]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-         Considerations Section in RFCs", BCP 26, RFC 2434,
-         October 1998.
-
-   [7]   Resnick, P., "Internet Message Format", RFC 2822, April 2001.
-
-   [8]   Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
-         Public Key Infrastructure Certificate and Certificate
-         Revocation List (CRL) Profile", RFC 3280, April 2002.
-
-   [9]   Farrell, S. and R. Housley, "An Internet Attribute Certificate
-         Profile for Authorization", RFC 3281, April 2002.
-
-   [10]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
-         Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
-         January 2005.
-
-   [11]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "DNS Security Introduction and Requirements", RFC 4033,
-         March 2005.
-
-   [12]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Resource Records for the DNS Security Extensions", RFC 4034,
-         March 2005.
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 14]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-10.2.  Informative References
-
-   [13]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
-         RFC 2246, January 1999.
-
-   [14]  Kent, S. and K. Seo, "Security Architecture for the Internet
-         Protocol", RFC 4301, December 2005.
-
-   [15]  Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,
-         and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
-         September 1999.
-
-   [16]  Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
-         RFC 3548, July 2003.
-
-   [17]  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
-         (S/MIME) Version 3.1 Message Specification", RFC 3851,
-         July 2004.
-
-   [18]  Richardson, M., "A Method for Storing IPsec Keying Material in
-         DNS", RFC 4025, March 2005.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 15]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-Appendix A.  Copying Conditions
-
-   Regarding the portion of this document that was written by Simon
-   Josefsson ("the author", for the remainder of this section), the
-   author makes no guarantees and is not responsible for any damage
-   resulting from its use.  The author grants irrevocable permission to
-   anyone to use, modify, and distribute it in any way that does not
-   diminish the rights of anyone else to use, modify, and distribute it,
-   provided that redistributed derivative works do not contain
-   misleading author or version information.  Derivative works need not
-   be licensed under similar terms.
-
-Author's Address
-
-   Simon Josefsson
-
-   EMail: simon@josefsson.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 16]
-
-RFC 4398            Storing Certificates in the DNS        February 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   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.
-
-Intellectual Property
-
-   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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 17]
-
diff --git a/contrib/bind9/doc/rfc/rfc4408.txt b/contrib/bind9/doc/rfc/rfc4408.txt
deleted file mode 100644
index bc1b3f5..0000000
--- a/contrib/bind9/doc/rfc/rfc4408.txt
+++ /dev/null
@@ -1,2691 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                            M. Wong
-Request for Comments: 4408                                    W. Schlitt
-Category: Experimental                                        April 2006
-
-
-                   Sender Policy Framework (SPF) for
-            Authorizing Use of Domains in E-Mail, Version 1
-
-Status of This Memo
-
-   This memo defines an Experimental Protocol for the Internet
-   community.  It does not specify an Internet standard of any kind.
-   Discussion and suggestions for improvement are requested.
-   Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-IESG Note
-
-   The following documents  (RFC 4405, RFC 4406, RFC 4407, and RFC 4408)
-   are published simultaneously as Experimental RFCs, although there is
-   no general technical consensus and efforts to reconcile the two
-   approaches have failed.  As such, these documents have not received
-   full IETF review and are published "AS-IS" to document the different
-   approaches as they were considered in the MARID working group.
-
-   The IESG takes no position about which approach is to be preferred
-   and cautions the reader that there are serious open issues for each
-   approach and concerns about using them in tandem.  The IESG believes
-   that documenting the different approaches does less harm than not
-   documenting them.
-
-   Note that the Sender ID experiment may use DNS records that may have
-   been created for the current SPF experiment or earlier versions in
-   this set of experiments.  Depending on the content of the record,
-   this may mean that Sender-ID heuristics would be applied incorrectly
-   to a message.  Depending on the actions associated by the recipient
-   with those heuristics, the message may not be delivered or may be
-   discarded on receipt.
-
-   Participants relying on Sender ID experiment DNS records are warned
-   that they may lose valid messages in this set of circumstances.
-   aParticipants publishing SPF experiment DNS records should consider
-   the advice given in section 3.4 of RFC 4406 and may wish to publish
-   both v=spf1 and spf2.0 records to avoid the conflict.
-
-
-
-
-Wong & Schlitt                Experimental                      [Page 1]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   Participants in the Sender-ID experiment need to be aware that the
-   way Resent-* header fields are used will result in failure to receive
-   legitimate email when interacting with standards-compliant systems
-   (specifically automatic forwarders which comply with the standards by
-   not adding Resent-* headers, and systems which comply with RFC 822
-   but have not yet implemented RFC 2822 Resent-* semantics).  It would
-   be inappropriate to advance Sender-ID on the standards track without
-   resolving this interoperability problem.
-
-   The community is invited to observe the success or failure of the two
-   approaches during the two years following publication, in order that
-   a community consensus can be reached in the future.
-
-Abstract
-
-   E-mail on the Internet can be forged in a number of ways.  In
-   particular, existing protocols place no restriction on what a sending
-   host can use as the reverse-path of a message or the domain given on
-   the SMTP HELO/EHLO commands.  This document describes version 1 of
-   the Sender Policy Framework (SPF) protocol, whereby a domain may
-   explicitly authorize the hosts that are allowed to use its domain
-   name, and a receiving host may check such authorization.
-
-Table of Contents
-
-   1. Introduction ....................................................4
-      1.1. Protocol Status ............................................4
-      1.2. Terminology ................................................5
-   2. Operation .......................................................5
-      2.1. The HELO Identity ..........................................5
-      2.2. The MAIL FROM Identity .....................................5
-      2.3. Publishing Authorization ...................................6
-      2.4. Checking Authorization .....................................6
-      2.5. Interpreting the Result ....................................7
-           2.5.1. None ................................................8
-           2.5.2. Neutral .............................................8
-           2.5.3. Pass ................................................8
-           2.5.4. Fail ................................................8
-           2.5.5. SoftFail ............................................9
-           2.5.6. TempError ...........................................9
-           2.5.7. PermError ...........................................9
-   3. SPF Records .....................................................9
-      3.1. Publishing ................................................10
-           3.1.1. DNS Resource Record Types ..........................10
-           3.1.2. Multiple DNS Records ...............................11
-           3.1.3. Multiple Strings in a Single DNS record ............11
-           3.1.4. Record Size ........................................11
-           3.1.5. Wildcard Records ...................................11
-
-
-
-Wong & Schlitt                Experimental                      [Page 2]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   4. The check_host() Function ......................................12
-      4.1. Arguments .................................................12
-      4.2. Results ...................................................13
-      4.3. Initial Processing ........................................13
-      4.4. Record Lookup .............................................13
-      4.5. Selecting Records .........................................13
-      4.6. Record Evaluation .........................................14
-           4.6.1. Term Evaluation ....................................14
-           4.6.2. Mechanisms .........................................15
-           4.6.3. Modifiers ..........................................15
-      4.7. Default Result ............................................16
-      4.8. Domain Specification ......................................16
-   5. Mechanism Definitions ..........................................16
-      5.1. "all" .....................................................17
-      5.2. "include" .................................................18
-      5.3. "a" .......................................................19
-      5.4. "mx" ......................................................20
-      5.5. "ptr" .....................................................20
-      5.6. "ip4" and "ip6" ...........................................21
-      5.7. "exists" ..................................................22
-   6. Modifier Definitions ...........................................22
-      6.1. redirect: Redirected Query ................................23
-      6.2. exp: Explanation ..........................................23
-   7. The Received-SPF Header Field ..................................25
-   8. Macros .........................................................27
-      8.1. Macro Definitions .........................................27
-      8.2. Expansion Examples ........................................30
-   9. Implications ...................................................31
-      9.1. Sending Domains ...........................................31
-      9.2. Mailing Lists .............................................32
-      9.3. Forwarding Services and Aliases ...........................32
-      9.4. Mail Services .............................................34
-      9.5. MTA Relays ................................................34
-   10. Security Considerations .......................................35
-      10.1. Processing Limits ........................................35
-      10.2. SPF-Authorized E-Mail May Contain Other False
-            Identities ...............................................37
-      10.3. Spoofed DNS and IP Data ..................................37
-      10.4. Cross-User Forgery .......................................37
-      10.5. Untrusted Information Sources ............................38
-      10.6. Privacy Exposure .........................................38
-   11. Contributors and Acknowledgements .............................38
-   12. IANA Considerations ...........................................39
-      12.1. The SPF DNS Record Type ..................................39
-      12.2. The Received-SPF Mail Header Field .......................39
-   13. References ....................................................39
-      13.1. Normative References .....................................39
-      13.2. Informative References ...................................40
-
-
-
-Wong & Schlitt                Experimental                      [Page 3]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   Appendix A.  Collected ABNF .......................................42
-   Appendix B.  Extended Examples ....................................44
-      B.1.  Simple Examples ..........................................44
-      B.2.  Multiple Domain Example ..................................45
-      B.3.  DNSBL Style Example ......................................46
-      B.4.  Multiple Requirements Example ............................46
-
-1.  Introduction
-
-   The current E-Mail infrastructure has the property that any host
-   injecting mail into the mail system can identify itself as any domain
-   name it wants.  Hosts can do this at a variety of levels: in
-   particular, the session, the envelope, and the mail headers.
-   Although this feature is desirable in some circumstances, it is a
-   major obstacle to reducing Unsolicited Bulk E-Mail (UBE, aka spam).
-   Furthermore, many domain name holders are understandably concerned
-   about the ease with which other entities may make use of their domain
-   names, often with malicious intent.
-
-   This document defines a protocol by which domain owners may authorize
-   hosts to use their domain name in the "MAIL FROM" or "HELO" identity.
-   Compliant domain holders publish Sender Policy Framework (SPF)
-   records specifying which hosts are permitted to use their names, and
-   compliant mail receivers use the published SPF records to test the
-   authorization of sending Mail Transfer Agents (MTAs) using a given
-   "HELO" or "MAIL FROM" identity during a mail transaction.
-
-   An additional benefit to mail receivers is that after the use of an
-   identity is verified, local policy decisions about the mail can be
-   made based on the sender's domain, rather than the host's IP address.
-   This is advantageous because reputation of domain names is likely to
-   be more accurate than reputation of host IP addresses.  Furthermore,
-   if a claimed identity fails verification, local policy can take
-   stronger action against such E-Mail, such as rejecting it.
-
-1.1.  Protocol Status
-
-   SPF has been in development since the summer of 2003 and has seen
-   deployment beyond the developers beginning in December 2003.  The
-   design of SPF slowly evolved until the spring of 2004 and has since
-   stabilized.  There have been quite a number of forms of SPF, some
-   written up as documents, some submitted as Internet Drafts, and many
-   discussed and debated in development forums.
-
-   The goal of this document is to clearly document the protocol defined
-   by earlier draft specifications of SPF as used in existing
-   implementations.  This conception of SPF is sometimes called "SPF
-   Classic".  It is understood that particular implementations and
-
-
-
-Wong & Schlitt                Experimental                      [Page 4]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   deployments may differ from, and build upon, this work.  It is hoped
-   that we have nonetheless captured the common understanding of SPF
-   version 1.
-
-1.2.  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 [RFC2119].
-
-   This document is concerned with the portion of a mail message
-   commonly called "envelope sender", "return path", "reverse path",
-   "bounce address", "2821 FROM", or "MAIL FROM".  Since these terms are
-   either not well defined or often used casually, this document defines
-   the "MAIL FROM" identity in Section 2.2.  Note that other terms that
-   may superficially look like the common terms, such as "reverse-path",
-   are used only with the defined meanings from normative documents.
-
-2.  Operation
-
-2.1.  The HELO Identity
-
-   The "HELO" identity derives from either the SMTP HELO or EHLO command
-   (see [RFC2821]).  These commands supply the SMTP client (sending
-   host) for the SMTP session.  Note that requirements for the domain
-   presented in the EHLO or HELO command are not always clear to the
-   sending party, and SPF clients must be prepared for the "HELO"
-   identity to be malformed or an IP address literal.  At the time of
-   this writing, many legitimate E-Mails are delivered with invalid HELO
-   domains.
-
-   It is RECOMMENDED that SPF clients not only check the "MAIL FROM"
-   identity, but also separately check the "HELO" identity by applying
-   the check_host() function (Section 4) to the "HELO" identity as the
-   <sender>.
-
-2.2.  The MAIL FROM Identity
-
-   The "MAIL FROM" identity derives from the SMTP MAIL command (see
-   [RFC2821]).  This command supplies the "reverse-path" for a message,
-   which generally consists of the sender mailbox, and is the mailbox to
-   which notification messages are to be sent if there are problems
-   delivering the message.
-
-   [RFC2821] allows the reverse-path to be null (see Section 4.5.5 in
-   RFC 2821).  In this case, there is no explicit sender mailbox, and
-   such a message can be assumed to be a notification message from the
-   mail system itself.  When the reverse-path is null, this document
-
-
-
-Wong & Schlitt                Experimental                      [Page 5]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   defines the "MAIL FROM" identity to be the mailbox composed of the
-   localpart "postmaster" and the "HELO" identity (which may or may not
-   have been checked separately before).
-
-   SPF clients MUST check the "MAIL FROM" identity.  SPF clients check
-   the "MAIL FROM" identity by applying the check_host() function to the
-   "MAIL FROM" identity as the <sender>.
-
-2.3.  Publishing Authorization
-
-   An SPF-compliant domain MUST publish a valid SPF record as described
-   in Section 3.  This record authorizes the use of the domain name in
-   the "HELO" and "MAIL FROM" identities by the MTAs it specifies.
-
-   If domain owners choose to publish SPF records, it is RECOMMENDED
-   that they end in "-all", or redirect to other records that do, so
-   that a definitive determination of authorization can be made.
-
-   Domain holders may publish SPF records that explicitly authorize no
-   hosts if mail should never originate using that domain.
-
-   When changing SPF records, care must be taken to ensure that there is
-   a transition period so that the old policy remains valid until all
-   legitimate E-Mail has been checked.
-
-2.4.  Checking Authorization
-
-   A mail receiver can perform a set of SPF checks for each mail message
-   it receives.  An SPF check tests the authorization of a client host
-   to emit mail with a given identity.  Typically, such checks are done
-   by a receiving MTA, but can be performed elsewhere in the mail
-   processing chain so long as the required information is available and
-   reliable.  At least the "MAIL FROM" identity MUST be checked, but it
-   is RECOMMENDED that the "HELO" identity also be checked beforehand.
-
-   Without explicit approval of the domain owner, checking other
-   identities against SPF version 1 records is NOT RECOMMENDED because
-   there are cases that are known to give incorrect results.  For
-   example, almost all mailing lists rewrite the "MAIL FROM" identity
-   (see Section 9.2), but some do not change any other identities in the
-   message.  The scenario described in Section 9.3, sub-section 1.2, is
-   another example.  Documents that define other identities should
-   define the method for explicit approval.
-
-   It is possible that mail receivers will use the SPF check as part of
-   a larger set of tests on incoming mail.  The results of other tests
-   may influence whether or not a particular SPF check is performed.
-   For example, finding the sending host's IP address on a local white
-
-
-
-Wong & Schlitt                Experimental                      [Page 6]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   list may cause all other tests to be skipped and all mail from that
-   host to be accepted.
-
-   When a mail receiver decides to perform an SPF check, it MUST use a
-   correctly-implemented check_host() function (Section 4) evaluated
-   with the correct parameters.  Although the test as a whole is
-   optional, once it has been decided to perform a test it must be
-   performed as specified so that the correct semantics are preserved
-   between publisher and receiver.
-
-   To make the test, the mail receiver MUST evaluate the check_host()
-   function with the arguments set as follows:
-
-   <ip>     - the IP address of the SMTP client that is emitting the
-              mail, either IPv4 or IPv6.
-
-   <domain> - the domain portion of the "MAIL FROM" or "HELO" identity.
-
-   <sender> - the "MAIL FROM" or "HELO" identity.
-
-   Note that the <domain> argument may not be a well-formed domain name.
-   For example, if the reverse-path was null, then the EHLO/HELO domain
-   is used, with its associated problems (see Section 2.1).  In these
-   cases, check_host() is defined in Section 4.3 to return a "None"
-   result.
-
-   Although invalid, malformed, or non-existent domains cause SPF checks
-   to return "None" because no SPF record can be found, it has long been
-   the policy of many MTAs to reject E-Mail from such domains,
-   especially in the case of invalid "MAIL FROM".  In order to prevent
-   the circumvention of SPF records, rejecting E-Mail from invalid
-   domains should be considered.
-
-   Implementations must take care to correctly extract the <domain> from
-   the data given with the SMTP MAIL FROM command as many MTAs will
-   still accept such things as source routes (see [RFC2821], Appendix
-   C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]).
-   These archaic features have been maliciously used to bypass security
-   systems.
-
-2.5.  Interpreting the Result
-
-   This section describes how software that performs the authorization
-   should interpret the results of the check_host() function.  The
-   authorization check SHOULD be performed during the processing of the
-   SMTP transaction that sends the mail.  This allows errors to be
-   returned directly to the sending MTA by way of SMTP replies.
-
-
-
-
-Wong & Schlitt                Experimental                      [Page 7]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   Performing the authorization after the SMTP transaction has finished
-   may cause problems, such as the following: (1) It may be difficult to
-   accurately extract the required information from potentially
-   deceptive headers; (2) legitimate E-Mail may fail because the
-   sender's policy may have since changed.
-
-   Generating non-delivery notifications to forged identities that have
-   failed the authorization check is generally abusive and against the
-   explicit wishes of the identity owner.
-
-2.5.1.  None
-
-   A result of "None" means that no records were published by the domain
-   or that no checkable sender domain could be determined from the given
-   identity.  The checking software cannot ascertain whether or not the
-   client host is authorized.
-
-2.5.2.  Neutral
-
-   The domain owner has explicitly stated that he cannot or does not
-   want to assert whether or not the IP address is authorized.  A
-   "Neutral" result MUST be treated exactly like the "None" result; the
-   distinction exists only for informational purposes.  Treating
-   "Neutral" more harshly than "None" would discourage domain owners
-   from testing the use of SPF records (see Section 9.1).
-
-2.5.3.  Pass
-
-   A "Pass" result means that the client is authorized to inject mail
-   with the given identity.  The domain can now, in the sense of
-   reputation, be considered responsible for sending the message.
-   Further policy checks can now proceed with confidence in the
-   legitimate use of the identity.
-
-2.5.4.  Fail
-
-   A "Fail" result is an explicit statement that the client is not
-   authorized to use the domain in the given identity.  The checking
-   software can choose to mark the mail based on this or to reject the
-   mail outright.
-
-   If the checking software chooses to reject the mail during the SMTP
-   transaction, then it SHOULD use an SMTP reply code of 550 (see
-   [RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification
-   (DSN) code (see [RFC3464]), in addition to an appropriate reply text.
-   The check_host() function may return either a default explanation
-   string or one from the domain that published the SPF records (see
-   Section 6.2).  If the information does not originate with the
-
-
-
-Wong & Schlitt                Experimental                      [Page 8]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   checking software, it should be made clear that the text is provided
-   by the sender's domain.  For example:
-
-       550-5.7.1 SPF MAIL FROM check failed:
-       550-5.7.1 The domain example.com explains:
-       550 5.7.1 Please see http://www.example.com/mailpolicy.html
-
-2.5.5.  SoftFail
-
-   A "SoftFail" result should be treated as somewhere between a "Fail"
-   and a "Neutral".  The domain believes the host is not authorized but
-   is not willing to make that strong of a statement.  Receiving
-   software SHOULD NOT reject the message based solely on this result,
-   but MAY subject the message to closer scrutiny than normal.
-
-   The domain owner wants to discourage the use of this host and thus
-   desires limited feedback when a "SoftFail" result occurs.  For
-   example, the recipient's Mail User Agent (MUA) could highlight the
-   "SoftFail" status, or the receiving MTA could give the sender a
-   message using a technique called "greylisting" whereby the MTA can
-   issue an SMTP reply code of 451 (4.3.0 DSN code) with a note the
-   first time the message is received, but accept it the second time.
-
-2.5.6.  TempError
-
-   A "TempError" result means that the SPF client encountered a
-   transient error while performing the check.  Checking software can
-   choose to accept or temporarily reject the message.  If the message
-   is rejected during the SMTP transaction for this reason, the software
-   SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 DSN
-   code.
-
-2.5.7.  PermError
-
-   A "PermError" result means that the domain's published records could
-   not be correctly interpreted.  This signals an error condition that
-   requires manual intervention to be resolved, as opposed to the
-   TempError result.  Be aware that if the domain owner uses macros
-   (Section 8), it is possible that this result is due to the checked
-   identities having an unexpected format.
-
-3.  SPF Records
-
-   An SPF record is a DNS Resource Record (RR) that declares which hosts
-   are, and are not, authorized to use a domain name for the "HELO" and
-   "MAIL FROM" identities.  Loosely, the record partitions all hosts
-   into permitted and not-permitted sets (though some hosts might fall
-   into neither category).
-
-
-
-Wong & Schlitt                Experimental                      [Page 9]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   The SPF record is a single string of text.  An example record is the
-   following:
-
-      v=spf1 +mx a:colo.example.com/28 -all
-
-   This record has a version of "spf1" and three directives: "+mx",
-   "a:colo.example.com/28" (the + is implied), and "-all".
-
-3.1.  Publishing
-
-   Domain owners wishing to be SPF compliant must publish SPF records
-   for the hosts that are used in the "MAIL FROM" and "HELO" identities.
-   The SPF records are placed in the DNS tree at the host name it
-   pertains to, not a subdomain under it, such as is done with SRV
-   records.  This is the same whether the TXT or SPF RR type (see
-   Section 3.1.1) is used.
-
-   The example above in Section 3 might be published via these lines in
-   a domain zone file:
-
-      example.com.          TXT "v=spf1 +mx a:colo.example.com/28 -all"
-      smtp-out.example.com. TXT "v=spf1 a -all"
-
-   When publishing via TXT records, beware of other TXT records
-   published there for other purposes.  They may cause problems with
-   size limits (see Section 3.1.4).
-
-3.1.1.  DNS Resource Record Types
-
-   This document defines a new DNS RR of type SPF, code 99.  The format
-   of this type is identical to the TXT RR [RFC1035].  For either type,
-   the character content of the record is encoded as [US-ASCII].
-
-   It is recognized that the current practice (using a TXT record) is
-   not optimal, but it is necessary because there are a number of DNS
-   server and resolver implementations in common use that cannot handle
-   the new RR type.  The two-record-type scheme provides a forward path
-   to the better solution of using an RR type reserved for this purpose.
-
-   An SPF-compliant domain name SHOULD have SPF records of both RR
-   types.  A compliant domain name MUST have a record of at least one
-   type.  If a domain has records of both types, they MUST have
-   identical content.  For example, instead of publishing just one
-   record as in Section 3.1 above, it is better to publish:
-
-      example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all"
-      example.com. IN SPF "v=spf1 +mx a:colo.example.com/28 -all"
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 10]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   Example RRs in this document are shown with the TXT record type;
-   however, they could be published with the SPF type or with both
-   types.
-
-3.1.2.  Multiple DNS Records
-
-   A domain name MUST NOT have multiple records that would cause an
-   authorization check to select more than one record.  See Section 4.5
-   for the selection rules.
-
-3.1.3.  Multiple Strings in a Single DNS record
-
-   As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS
-   record (either TXT or SPF RR types) can be composed of more than one
-   string.  If a published record contains multiple strings, then the
-   record MUST be treated as if those strings are concatenated together
-   without adding spaces.  For example:
-
-      IN TXT "v=spf1 .... first" "second string..."
-
-   MUST be treated as equivalent to
-
-      IN TXT "v=spf1 .... firstsecond string..."
-
-   SPF or TXT records containing multiple strings are useful in
-   constructing records that would exceed the 255-byte maximum length of
-   a string within a single TXT or SPF RR record.
-
-3.1.4.  Record Size
-
-   The published SPF record for a given domain name SHOULD remain small
-   enough that the results of a query for it will fit within 512 octets.
-   This will keep even older DNS implementations from falling over to
-   TCP.  Since the answer size is dependent on many things outside the
-   scope of this document, it is only possible to give this guideline:
-   If the combined length of the DNS name and the text of all the
-   records of a given type (TXT or SPF) is under 450 characters, then
-   DNS answers should fit in UDP packets.  Note that when computing the
-   sizes for queries of the TXT format, one must take into account any
-   other TXT records published at the domain name.  Records that are too
-   long to fit in a single UDP packet MAY be silently ignored by SPF
-   clients.
-
-3.1.5.  Wildcard Records
-
-   Use of wildcard records for publishing is not recommended.  Care must
-   be taken if wildcard records are used.  If a domain publishes
-   wildcard MX records, it may want to publish wildcard declarations,
-
-
-
-Wong & Schlitt                Experimental                     [Page 11]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   subject to the same requirements and problems.  In particular, the
-   declaration must be repeated for any host that has any RR records at
-   all, and for subdomains thereof.  For example, the example given in
-   [RFC1034], Section 4.3.3, could be extended with the following:
-
-       X.COM.          MX      10      A.X.COM
-       X.COM.          TXT     "v=spf1 a:A.X.COM -all"
-
-       *.X.COM.        MX      10      A.X.COM
-       *.X.COM.        TXT     "v=spf1 a:A.X.COM -all"
-
-       A.X.COM.        A       1.2.3.4
-       A.X.COM.        MX      10      A.X.COM
-       A.X.COM.        TXT     "v=spf1 a:A.X.COM -all"
-
-       *.A.X.COM.      MX      10      A.X.COM
-       *.A.X.COM.      TXT     "v=spf1 a:A.X.COM -all"
-
-   Notice that SPF records must be repeated twice for every name within
-   the domain: once for the name, and once with a wildcard to cover the
-   tree under the name.
-
-   Use of wildcards is discouraged in general as they cause every name
-   under the domain to exist and queries against arbitrary names will
-   never return RCODE 3 (Name Error).
-
-4.  The check_host() Function
-
-   The check_host() function fetches SPF records, parses them, and
-   interprets them to determine whether a particular host is or is not
-   permitted to send mail with a given identity.  Mail receivers that
-   perform this check MUST correctly evaluate the check_host() function
-   as described here.
-
-   Implementations MAY use a different algorithm than the canonical
-   algorithm defined here, so long as the results are the same in all
-   cases.
-
-4.1.  Arguments
-
-   The check_host() function takes these arguments:
-
-   <ip>     - the IP address of the SMTP client that is emitting the
-              mail, either IPv4 or IPv6.
-
-   <domain> - the domain that provides the sought-after authorization
-              information; initially, the domain portion of the "MAIL
-              FROM" or "HELO" identity.
-
-
-
-Wong & Schlitt                Experimental                     [Page 12]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   <sender> - the "MAIL FROM" or "HELO" identity.
-
-   The domain portion of <sender> will usually be the same as the
-   <domain> argument when check_host() is initially evaluated.  However,
-   this will generally not be true for recursive evaluations (see
-   Section 5.2 below).
-
-   Actual implementations of the check_host() function may need
-   additional arguments.
-
-4.2.  Results
-
-   The function check_host() can return one of several results described
-   in Section 2.5.  Based on the result, the action to be taken is
-   determined by the local policies of the receiver.
-
-4.3.  Initial Processing
-
-   If the <domain> is malformed (label longer than 63 characters, zero-
-   length label not at the end, etc.) or is not a fully qualified domain
-   name, or if the DNS lookup returns "domain does not exist" (RCODE 3),
-   check_host() immediately returns the result "None".
-
-   If the <sender> has no localpart, substitute the string "postmaster"
-   for the localpart.
-
-4.4.  Record Lookup
-
-   In accordance with how the records are published (see Section 3.1
-   above), a DNS query needs to be made for the <domain> name, querying
-   for either RR type TXT, SPF, or both.  If both SPF and TXT RRs are
-   looked up, the queries MAY be done in parallel.
-
-   If all DNS lookups that are made return a server failure (RCODE 2),
-   or other error (RCODE other than 0 or 3), or time out, then
-   check_host() exits immediately with the result "TempError".
-
-4.5.  Selecting Records
-
-   Records begin with a version section:
-
-   record           = version terms *SP
-   version          = "v=spf1"
-
-   Starting with the set of records that were returned by the lookup,
-   record selection proceeds in two steps:
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 13]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   1. Records that do not begin with a version section of exactly
-      "v=spf1" are discarded.  Note that the version section is
-      terminated either by an SP character or the end of the record.  A
-      record with a version section of "v=spf10" does not match and must
-      be discarded.
-
-   2. If any records of type SPF are in the set, then all records of
-      type TXT are discarded.
-
-   After the above steps, there should be exactly one record remaining
-   and evaluation can proceed.  If there are two or more records
-   remaining, then check_host() exits immediately with the result of
-   "PermError".
-
-   If no matching records are returned, an SPF client MUST assume that
-   the domain makes no SPF declarations.  SPF processing MUST stop and
-   return "None".
-
-4.6.  Record Evaluation
-
-   After one SPF record has been selected, the check_host() function
-   parses and interprets it to find a result for the current test.  If
-   there are any syntax errors, check_host() returns immediately with
-   the result "PermError".
-
-   Implementations MAY choose to parse the entire record first and
-   return "PermError" if the record is not syntactically well formed.
-   However, in all cases, any syntax errors anywhere in the record MUST
-   be detected.
-
-4.6.1.  Term Evaluation
-
-   There are two types of terms: mechanisms and modifiers.  A record
-   contains an ordered list of these as specified in the following
-   Augmented Backus-Naur Form (ABNF).
-
-   terms            = *( 1*SP ( directive / modifier ) )
-
-   directive        = [ qualifier ] mechanism
-   qualifier        = "+" / "-" / "?" / "~"
-   mechanism        = ( all / include
-                      / A / MX / PTR / IP4 / IP6 / exists )
-   modifier         = redirect / explanation / unknown-modifier
-   unknown-modifier = name "=" macro-string
-
-   name             = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
-
-   Most mechanisms allow a ":" or "/" character after the name.
-
-
-
-Wong & Schlitt                Experimental                     [Page 14]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   Modifiers always contain an equals ('=') character immediately after
-   the name, and before any ":" or "/" characters that may be part of
-   the macro-string.
-
-   Terms that do not contain any of "=", ":", or "/" are mechanisms, as
-   defined in Section 5.
-
-   As per the definition of the ABNF notation in [RFC4234], mechanism
-   and modifier names are case-insensitive.
-
-4.6.2.  Mechanisms
-
-   Each mechanism is considered in turn from left to right.  If there
-   are no more mechanisms, the result is specified in Section 4.7.
-
-   When a mechanism is evaluated, one of three things can happen: it can
-   match, not match, or throw an exception.
-
-   If it matches, processing ends and the qualifier value is returned as
-   the result of that record.  If it does not match, processing
-   continues with the next mechanism.  If it throws an exception,
-   mechanism processing ends and the exception value is returned.
-
-   The possible qualifiers, and the results they return are as follows:
-
-      "+" Pass
-      "-" Fail
-      "~" SoftFail
-      "?" Neutral
-
-   The qualifier is optional and defaults to "+".
-
-   When a mechanism matches and the qualifier is "-", then a "Fail"
-   result is returned and the explanation string is computed as
-   described in Section 6.2.
-
-   The specific mechanisms are described in Section 5.
-
-4.6.3.  Modifiers
-
-   Modifiers are not mechanisms: they do not return match or not-match.
-   Instead they provide additional information.  Although modifiers do
-   not directly affect the evaluation of the record, the "redirect"
-   modifier has an effect after all the mechanisms have been evaluated.
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 15]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-4.7.  Default Result
-
-   If none of the mechanisms match and there is no "redirect" modifier,
-   then the check_host() returns a result of "Neutral", just as if
-   "?all" were specified as the last directive.  If there is a
-   "redirect" modifier, check_host() proceeds as defined in Section 6.1.
-
-   Note that records SHOULD always use either a "redirect" modifier or
-   an "all" mechanism to explicitly terminate processing.
-
-   For example:
-
-      v=spf1 +mx -all
-   or
-      v=spf1 +mx redirect=_spf.example.com
-
-4.8.  Domain Specification
-
-   Several of these mechanisms and modifiers have a <domain-spec>
-   section.  The <domain-spec> string is macro expanded (see Section 8).
-   The resulting string is the common presentation form of a fully-
-   qualified DNS name: a series of labels separated by periods.  This
-   domain is called the <target-name> in the rest of this document.
-
-   Note: The result of the macro expansion is not subject to any further
-   escaping.  Hence, this facility cannot produce all characters that
-   are legal in a DNS label (e.g., the control characters).  However,
-   this facility is powerful enough to express legal host names and
-   common utility labels (such as "_spf") that are used in DNS.
-
-   For several mechanisms, the <domain-spec> is optional.  If it is not
-   provided, the <domain> is used as the <target-name>.
-
-5.  Mechanism Definitions
-
-   This section defines two types of mechanisms.
-
-   Basic mechanisms contribute to the language framework.  They do not
-   specify a particular type of authorization scheme.
-
-      all
-      include
-
-   Designated sender mechanisms are used to designate a set of <ip>
-   addresses as being permitted or not permitted to use the <domain> for
-   sending mail.
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 16]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-      a
-      mx
-      ptr
-      ip4
-      ip6
-      exists
-
-   The following conventions apply to all mechanisms that perform a
-   comparison between <ip> and an IP address at any point:
-
-   If no CIDR-length is given in the directive, then <ip> and the IP
-   address are compared for equality. (Here, CIDR is Classless Inter-
-   Domain Routing.)
-
-   If a CIDR-length is specified, then only the specified number of
-   high-order bits of <ip> and the IP address are compared for equality.
-
-   When any mechanism fetches host addresses to compare with <ip>, when
-   <ip> is an IPv4 address, A records are fetched, when <ip> is an IPv6
-   address, AAAA records are fetched.  Even if the SMTP connection is
-   via IPv6, an IPv4-mapped IPv6 IP address (see [RFC3513], Section
-   2.5.5) MUST still be considered an IPv4 address.
-
-   Several mechanisms rely on information fetched from DNS.  For these
-   DNS queries, except where noted, if the DNS server returns an error
-   (RCODE other than 0 or 3) or the query times out, the mechanism
-   throws the exception "TempError".  If the server returns "domain does
-   not exist" (RCODE 3), then evaluation of the mechanism continues as
-   if the server returned no error (RCODE 0) and zero answer records.
-
-5.1.  "all"
-
-   all              = "all"
-
-   The "all" mechanism is a test that always matches.  It is used as the
-   rightmost mechanism in a record to provide an explicit default.
-
-   For example:
-
-      v=spf1 a mx -all
-
-   Mechanisms after "all" will never be tested.  Any "redirect" modifier
-   (Section 6.1) has no effect when there is an "all" mechanism.
-
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 17]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-5.2.  "include"
-
-      include          = "include"  ":" domain-spec
-
-   The "include" mechanism triggers a recursive evaluation of
-   check_host().  The domain-spec is expanded as per Section 8.  Then
-   check_host() is evaluated with the resulting string as the <domain>.
-   The <ip> and <sender> arguments remain the same as in the current
-   evaluation of check_host().
-
-   In hindsight, the name "include" was poorly chosen.  Only the
-   evaluated result of the referenced SPF record is used, rather than
-   acting as if the referenced SPF record was literally included in the
-   first.  For example, evaluating a "-all" directive in the referenced
-   record does not terminate the overall processing and does not
-   necessarily result in an overall "Fail".  (Better names for this
-   mechanism would have been "if-pass", "on-pass", etc.)
-
-   The "include" mechanism makes it possible for one domain to designate
-   multiple administratively-independent domains.  For example, a vanity
-   domain "example.net" might send mail using the servers of
-   administratively-independent domains example.com and example.org.
-
-   Example.net could say
-
-      IN TXT "v=spf1 include:example.com include:example.org -all"
-
-   This would direct check_host() to, in effect, check the records of
-   example.com and example.org for a "Pass" result.  Only if the host
-   were not permitted for either of those domains would the result be
-   "Fail".
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 18]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   Whether this mechanism matches, does not match, or throws an
-   exception depends on the result of the recursive evaluation of
-   check_host():
-
-   +---------------------------------+---------------------------------+
-   | A recursive check_host() result | Causes the "include" mechanism  |
-   | of:                             | to:                             |
-   +---------------------------------+---------------------------------+
-   | Pass                            | match                           |
-   |                                 |                                 |
-   | Fail                            | not match                       |
-   |                                 |                                 |
-   | SoftFail                        | not match                       |
-   |                                 |                                 |
-   | Neutral                         | not match                       |
-   |                                 |                                 |
-   | TempError                       | throw TempError                 |
-   |                                 |                                 |
-   | PermError                       | throw PermError                 |
-   |                                 |                                 |
-   | None                            | throw PermError                 |
-   +---------------------------------+---------------------------------+
-
-   The "include" mechanism is intended for crossing administrative
-   boundaries.  Although it is possible to use includes to consolidate
-   multiple domains that share the same set of designated hosts, domains
-   are encouraged to use redirects where possible, and to minimize the
-   number of includes within a single administrative domain.  For
-   example, if example.com and example.org were managed by the same
-   entity, and if the permitted set of hosts for both domains was
-   "mx:example.com", it would be possible for example.org to specify
-   "include:example.com", but it would be preferable to specify
-   "redirect=example.com" or even "mx:example.com".
-
-5.3.  "a"
-
-   This mechanism matches if <ip> is one of the <target-name>'s IP
-   addresses.
-
-   A                = "a"      [ ":" domain-spec ] [ dual-cidr-length ]
-
-   An address lookup is done on the <target-name>.  The <ip> is compared
-   to the returned address(es).  If any address matches, the mechanism
-   matches.
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 19]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-5.4.  "mx"
-
-   This mechanism matches if <ip> is one of the MX hosts for a domain
-   name.
-
-   MX               = "mx"     [ ":" domain-spec ] [ dual-cidr-length ]
-
-   check_host() first performs an MX lookup on the <target-name>.  Then
-   it performs an address lookup on each MX name returned.  The <ip> is
-   compared to each returned IP address.  To prevent Denial of Service
-   (DoS) attacks, more than 10 MX names MUST NOT be looked up during the
-   evaluation of an "mx" mechanism (see Section 10).  If any address
-   matches, the mechanism matches.
-
-   Note regarding implicit MXs: If the <target-name> has no MX records,
-   check_host() MUST NOT pretend the target is its single MX, and MUST
-   NOT default to an A lookup on the <target-name> directly.  This
-   behavior breaks with the legacy "implicit MX" rule.  See [RFC2821],
-   Section 5.  If such behavior is desired, the publisher should specify
-   an "a" directive.
-
-5.5.  "ptr"
-
-   This mechanism tests whether the DNS reverse-mapping for <ip> exists
-   and correctly points to a domain name within a particular domain.
-
-   PTR              = "ptr"    [ ":" domain-spec ]
-
-   First, the <ip>'s name is looked up using this procedure: perform a
-   DNS reverse-mapping for <ip>, looking up the corresponding PTR record
-   in "in-addr.arpa." if the address is an IPv4 one and in "ip6.arpa."
-   if it is an IPv6 address.  For each record returned, validate the
-   domain name by looking up its IP address.  To prevent DoS attacks,
-   more than 10 PTR names MUST NOT be looked up during the evaluation of
-   a "ptr" mechanism (see Section 10).  If <ip> is among the returned IP
-   addresses, then that domain name is validated.  In pseudocode:
-
-   sending-domain_names := ptr_lookup(sending-host_IP); if more than 10
-   sending-domain_names are found, use at most 10.  for each name in
-   (sending-domain_names) {
-     IP_addresses := a_lookup(name);
-     if the sending-domain_IP is one of the IP_addresses {
-       validated-sending-domain_names += name;
-     } }
-
-   Check all validated domain names to see if they end in the
-   <target-name> domain.  If any do, this mechanism matches.  If no
-   validated domain name can be found, or if none of the validated
-
-
-
-Wong & Schlitt                Experimental                     [Page 20]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   domain names end in the <target-name>, this mechanism fails to match.
-   If a DNS error occurs while doing the PTR RR lookup, then this
-   mechanism fails to match.  If a DNS error occurs while doing an A RR
-   lookup, then that domain name is skipped and the search continues.
-
-   Pseudocode:
-
-   for each name in (validated-sending-domain_names) {
-     if name ends in <domain-spec>, return match.
-     if name is <domain-spec>, return match.
-   }
-   return no-match.
-
-   This mechanism matches if the <target-name> is either an ancestor of
-   a validated domain name or if the <target-name> and a validated
-   domain name are the same.  For example: "mail.example.com" is within
-   the domain "example.com", but "mail.bad-example.com" is not.
-
-   Note: Use of this mechanism is discouraged because it is slow, it is
-   not as reliable as other mechanisms in cases of DNS errors, and it
-   places a large burden on the arpa name servers.  If used, proper PTR
-   records must be in place for the domain's hosts and the "ptr"
-   mechanism should be one of the last mechanisms checked.
-
-5.6.  "ip4" and "ip6"
-
-   These mechanisms test whether <ip> is contained within a given IP
-   network.
-
-   IP4              = "ip4"      ":" ip4-network   [ ip4-cidr-length ]
-   IP6              = "ip6"      ":" ip6-network   [ ip6-cidr-length ]
-
-   ip4-cidr-length  = "/" 1*DIGIT
-   ip6-cidr-length  = "/" 1*DIGIT
-   dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
-
-   ip4-network      = qnum "." qnum "." qnum "." qnum
-   qnum             = DIGIT                 ; 0-9
-                      / %x31-39 DIGIT       ; 10-99
-                      / "1" 2DIGIT          ; 100-199
-                      / "2" %x30-34 DIGIT   ; 200-249
-                      / "25" %x30-35        ; 250-255
-            ; as per conventional dotted quad notation.  e.g., 192.0.2.0
-   ip6-network      = <as per [RFC 3513], section 2.2>
-            ; e.g., 2001:DB8::CD30
-
-   The <ip> is compared to the given network.  If CIDR-length high-order
-   bits match, the mechanism matches.
-
-
-
-Wong & Schlitt                Experimental                     [Page 21]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   If ip4-cidr-length is omitted, it is taken to be "/32".  If
-   ip6-cidr-length is omitted, it is taken to be "/128".  It is not
-   permitted to omit parts of the IP address instead of using CIDR
-   notations.  That is, use 192.0.2.0/24 instead of 192.0.2.
-
-5.7.  "exists"
-
-   This mechanism is used to construct an arbitrary domain name that is
-   used for a DNS A record query.  It allows for complicated schemes
-   involving arbitrary parts of the mail envelope to determine what is
-   permitted.
-
-   exists           = "exists"   ":" domain-spec
-
-   The domain-spec is expanded as per Section 8.  The resulting domain
-   name is used for a DNS A RR lookup.  If any A record is returned,
-   this mechanism matches.  The lookup type is A even when the
-   connection type is IPv6.
-
-   Domains can use this mechanism to specify arbitrarily complex
-   queries.  For example, suppose example.com publishes the record:
-
-      v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all
-
-   The <target-name> might expand to
-   "1.2.0.192.someuser._spf.example.com".  This makes fine-grained
-   decisions possible at the level of the user and client IP address.
-
-   This mechanism enables queries that mimic the style of tests that
-   existing anti-spam DNS blacklists (DNSBL) use.
-
-6.  Modifier Definitions
-
-   Modifiers are name/value pairs that provide additional information.
-   Modifiers always have an "=" separating the name and the value.
-
-   The modifiers defined in this document ("redirect" and "exp") MAY
-   appear anywhere in the record, but SHOULD appear at the end, after
-   all mechanisms.  Ordering of these two modifiers does not matter.
-   These two modifiers MUST NOT appear in a record more than once each.
-   If they do, then check_host() exits with a result of "PermError".
-
-   Unrecognized modifiers MUST be ignored no matter where in a record,
-   or how often.  This allows implementations of this document to
-   gracefully handle records with modifiers that are defined in other
-   specifications.
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 22]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-6.1.  redirect: Redirected Query
-
-   If all mechanisms fail to match, and a "redirect" modifier is
-   present, then processing proceeds as follows:
-
-   redirect         = "redirect" "=" domain-spec
-
-   The domain-spec portion of the redirect section is expanded as per
-   the macro rules in Section 8.  Then check_host() is evaluated with
-   the resulting string as the <domain>.  The <ip> and <sender>
-   arguments remain the same as current evaluation of check_host().
-
-   The result of this new evaluation of check_host() is then considered
-   the result of the current evaluation with the exception that if no
-   SPF record is found, or if the target-name is malformed, the result
-   is a "PermError" rather than "None".
-
-   Note that the newly-queried domain may itself specify redirect
-   processing.
-
-   This facility is intended for use by organizations that wish to apply
-   the same record to multiple domains.  For example:
-
-     la.example.com. TXT "v=spf1 redirect=_spf.example.com"
-     ny.example.com. TXT "v=spf1 redirect=_spf.example.com"
-     sf.example.com. TXT "v=spf1 redirect=_spf.example.com"
-   _spf.example.com. TXT "v=spf1 mx:example.com -all"
-
-   In this example, mail from any of the three domains is described by
-   the same record.  This can be an administrative advantage.
-
-   Note: In general, the domain "A" cannot reliably use a redirect to
-   another domain "B" not under the same administrative control.  Since
-   the <sender> stays the same, there is no guarantee that the record at
-   domain "B" will correctly work for mailboxes in domain "A",
-   especially if domain "B" uses mechanisms involving localparts.  An
-   "include" directive may be more appropriate.
-
-   For clarity, it is RECOMMENDED that any "redirect" modifier appear as
-   the very last term in a record.
-
-6.2.  exp: Explanation
-
-   explanation      = "exp" "=" domain-spec
-
-   If check_host() results in a "Fail" due to a mechanism match (such as
-   "-all"), and the "exp" modifier is present, then the explanation
-   string returned is computed as described below.  If no "exp" modifier
-
-
-
-Wong & Schlitt                Experimental                     [Page 23]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   is present, then either a default explanation string or an empty
-   explanation string may be returned.
-
-   The <domain-spec> is macro expanded (see Section 8) and becomes the
-   <target-name>.  The DNS TXT record for the <target-name> is fetched.
-
-   If <domain-spec> is empty, or there are any DNS processing errors
-   (any RCODE other than 0), or if no records are returned, or if more
-   than one record is returned, or if there are syntax errors in the
-   explanation string, then proceed as if no exp modifier was given.
-
-   The fetched TXT record's strings are concatenated with no spaces, and
-   then treated as an <explain-string>, which is macro-expanded.  This
-   final result is the explanation string.  Implementations MAY limit
-   the length of the resulting explanation string to allow for other
-   protocol constraints and/or reasonable processing limits.  Since the
-   explanation string is intended for an SMTP response and [RFC2821]
-   Section 2.4 says that responses are in [US-ASCII], the explanation
-   string is also limited to US-ASCII.
-
-   Software evaluating check_host() can use this string to communicate
-   information from the publishing domain in the form of a short message
-   or URL.  Software SHOULD make it clear that the explanation string
-   comes from a third party.  For example, it can prepend the macro
-   string "%{o} explains: " to the explanation, such as shown in Section
-   2.5.4.
-
-   Suppose example.com has this record:
-
-      v=spf1 mx -all exp=explain._spf.%{d}
-
-   Here are some examples of possible explanation TXT records at
-   explain._spf.example.com:
-
-      "Mail from example.com should only be sent by its own servers."
-         -- a simple, constant message
-
-      "%{i} is not one of %{d}'s designated mail servers."
-         -- a message with a little more information, including the IP
-            address that failed the check
-
-      "See http://%{d}/why.html?s=%{S}&i=%{I}"
-         -- a complicated example that constructs a URL with the
-            arguments to check_host() so that a web page can be
-            generated with detailed, custom instructions
-
-   Note: During recursion into an "include" mechanism, an exp= modifier
-   from the <target-name> MUST NOT be used.  In contrast, when executing
-
-
-
-Wong & Schlitt                Experimental                     [Page 24]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   a "redirect" modifier, an exp= modifier from the original domain MUST
-   NOT be used.
-
-7.  The Received-SPF Header Field
-
-   It is RECOMMENDED that SMTP receivers record the result of SPF
-   processing in the message header.  If an SMTP receiver chooses to do
-   so, it SHOULD use the "Received-SPF" header field defined here for
-   each identity that was checked.  This information is intended for the
-   recipient.  (Information intended for the sender is described in
-   Section 6.2, Explanation.)
-
-   The Received-SPF header field is a trace field (see [RFC2822] Section
-   3.6.7) and SHOULD be prepended to the existing header, above the
-   Received: field that is generated by the SMTP receiver.  It MUST
-   appear above all other Received-SPF fields in the message.  The
-   header field has the following format:
-
-   header-field     = "Received-SPF:" [CFWS] result FWS [comment FWS]
-                      [ key-value-list ] CRLF
-
-   result           = "Pass" / "Fail" / "SoftFail" / "Neutral" /
-                      "None" / "TempError" / "PermError"
-
-   key-value-list   = key-value-pair *( ";" [CFWS] key-value-pair )
-                      [";"]
-
-   key-value-pair   = key [CFWS] "=" ( dot-atom / quoted-string )
-
-   key              = "client-ip" / "envelope-from" / "helo" /
-                      "problem" / "receiver" / "identity" /
-                       mechanism / "x-" name / name
-
-   identity         = "mailfrom"   ; for the "MAIL FROM" identity
-                      / "helo"     ; for the "HELO" identity
-                      / name       ; other identities
-
-   dot-atom         = <unquoted word as per [RFC2822]>
-   quoted-string    = <quoted string as per [RFC2822]>
-   comment          = <comment string as per [RFC2822]>
-   CFWS             = <comment or folding white space as per [RFC2822]>
-   FWS              = <folding white space as per [RFC2822]>
-   CRLF             = <standard end-of-line token as per [RFC2822]>
-
-   The header field SHOULD include a "(...)" style <comment> after the
-   result, conveying supporting information for the result, such as
-   <ip>, <sender>, and <domain>.
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 25]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   The following key-value pairs are designed for later machine parsing.
-   SPF clients SHOULD give enough information so that the SPF results
-   can be verified.  That is, at least "client-ip", "helo", and, if the
-   "MAIL FROM" identity was checked, "envelope-from".
-
-   client-ip      the IP address of the SMTP client
-
-   envelope-from  the envelope sender mailbox
-
-   helo           the host name given in the HELO or EHLO command
-
-   mechanism      the mechanism that matched (if no mechanisms matched,
-                  substitute the word "default")
-
-   problem        if an error was returned, details about the error
-
-   receiver       the host name of the SPF client
-
-   identity       the identity that was checked; see the <identity> ABNF
-                  rule
-
-   Other keys may be defined by SPF clients.  Until a new key name
-   becomes widely accepted, new key names should start with "x-".
-
-   SPF clients MUST make sure that the Received-SPF header field does
-   not contain invalid characters, is not excessively long, and does not
-   contain malicious data that has been provided by the sender.
-
-   Examples of various header styles that could be generated are the
-   following:
-
-   Received-SPF: Pass (mybox.example.org: domain of
-    myname@example.com designates 192.0.2.1 as permitted sender)
-       receiver=mybox.example.org; client-ip=192.0.2.1;
-       envelope-from=<myname@example.com>; helo=foo.example.com;
-
-   Received-SPF: Fail (mybox.example.org: domain of
-                     myname@example.com does not designate
-                     192.0.2.1 as permitted sender)
-                     identity=mailfrom; client-ip=192.0.2.1;
-                     envelope-from=<myname@example.com>;
-
-
-
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 26]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-8.  Macros
-
-8.1.  Macro Definitions
-
-   Many mechanisms and modifiers perform macro expansion on part of the
-   term.
-
-   domain-spec      = macro-string domain-end
-   domain-end       = ( "." toplabel [ "." ] ) / macro-expand
-
-   toplabel         = ( *alphanum ALPHA *alphanum ) /
-                      ( 1*alphanum "-" *( alphanum / "-" ) alphanum )
-                      ; LDH rule plus additional TLD restrictions
-                      ; (see [RFC3696], Section 2)
-   alphanum         = ALPHA / DIGIT
-
-   explain-string   = *( macro-string / SP )
-
-   macro-string     = *( macro-expand / macro-literal )
-   macro-expand     = ( "%{" macro-letter transformers *delimiter "}" )
-                      / "%%" / "%_" / "%-"
-   macro-literal    = %x21-24 / %x26-7E
-                      ; visible characters except "%"
-   macro-letter     = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
-                      "c" / "r" / "t"
-   transformers     = *DIGIT [ "r" ]
-   delimiter        = "." / "-" / "+" / "," / "/" / "_" / "="
-
-   A literal "%" is expressed by "%%".
-
-      "%_" expands to a single " " space.
-      "%-" expands to a URL-encoded space, viz., "%20".
-
-   The following macro letters are expanded in term arguments:
-
-      s = <sender>
-      l = local-part of <sender>
-      o = domain of <sender>
-      d = <domain>
-      i = <ip>
-      p = the validated domain name of <ip>
-      v = the string "in-addr" if <ip> is ipv4, or "ip6" if <ip> is ipv6
-      h = HELO/EHLO domain
-
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 27]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   The following macro letters are allowed only in "exp" text:
-
-      c = SMTP client IP (easily readable format)
-      r = domain name of host performing the check
-      t = current timestamp
-
-   A '%' character not followed by a '{', '%', '-', or '_' character is
-   a syntax error.  So
-
-      -exists:%(ir).sbl.spamhaus.example.org
-
-   is incorrect and will cause check_host() to return a "PermError".
-   Instead, say
-
-      -exists:%{ir}.sbl.spamhaus.example.org
-
-   Optional transformers are the following:
-
-      *DIGIT = zero or more digits
-      'r'    = reverse value, splitting on dots by default
-
-   If transformers or delimiters are provided, the replacement value for
-   a macro letter is split into parts.  After performing any reversal
-   operation and/or removal of left-hand parts, the parts are rejoined
-   using "." and not the original splitting characters.
-
-   By default, strings are split on "." (dots).  Note that no special
-   treatment is given to leading, trailing, or consecutive delimiters,
-   and so the list of parts may contain empty strings.  Older
-   implementations of SPF prohibit trailing dots in domain names, so
-   trailing dots should not be published by domain owners, although they
-   must be accepted by implementations conforming to this document.
-   Macros may specify delimiter characters that are used instead of ".".
-
-   The 'r' transformer indicates a reversal operation: if the client IP
-   address were 192.0.2.1, the macro %{i} would expand to "192.0.2.1"
-   and the macro %{ir} would expand to "1.2.0.192".
-
-   The DIGIT transformer indicates the number of right-hand parts to
-   use, after optional reversal.  If a DIGIT is specified, the value
-   MUST be nonzero.  If no DIGITs are specified, or if the value
-   specifies more parts than are available, all the available parts are
-   used.  If the DIGIT was 5, and only 3 parts were available, the macro
-   interpreter would pretend the DIGIT was 3.  Implementations MUST
-   support at least a value of 128, as that is the maximum number of
-   labels in a domain name.
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 28]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   The "s" macro expands to the <sender> argument.  It is an E-Mail
-   address with a localpart, an "@" character, and a domain.  The "l"
-   macro expands to just the localpart.  The "o" macro expands to just
-   the domain part.  Note that these values remain the same during
-   recursive and chained evaluations due to "include" and/or "redirect".
-   Note also that if the original <sender> had no localpart, the
-   localpart was set to "postmaster" in initial processing (see Section
-   4.3).
-
-   For IPv4 addresses, both the "i" and "c" macros expand to the
-   standard dotted-quad format.
-
-   For IPv6 addresses, the "i" macro expands to a dot-format address; it
-   is intended for use in %{ir}.  The "c" macro may expand to any of the
-   hexadecimal colon-format addresses specified in [RFC3513], Section
-   2.2.  It is intended for humans to read.
-
-   The "p" macro expands to the validated domain name of <ip>.  The
-   procedure for finding the validated domain name is defined in Section
-   5.5.  If the <domain> is present in the list of validated domains, it
-   SHOULD be used.  Otherwise, if a subdomain of the <domain> is
-   present, it SHOULD be used.  Otherwise, any name from the list may be
-   used.  If there are no validated domain names or if a DNS error
-   occurs, the string "unknown" is used.
-
-   The "r" macro expands to the name of the receiving MTA.  This SHOULD
-   be a fully qualified domain name, but if one does not exist (as when
-   the checking is done by a MUA) or if policy restrictions dictate
-   otherwise, the word "unknown" SHOULD be substituted.  The domain name
-   may be different from the name found in the MX record that the client
-   MTA used to locate the receiving MTA.
-
-   The "t" macro expands to the decimal representation of the
-   approximate number of seconds since the Epoch (Midnight, January 1,
-   1970, UTC).  This is the same value as is returned by the POSIX
-   time() function in most standards-compliant libraries.
-
-   When the result of macro expansion is used in a domain name query, if
-   the expanded domain name exceeds 253 characters (the maximum length
-   of a domain name), the left side is truncated to fit, by removing
-   successive domain labels until the total length does not exceed 253
-   characters.
-
-   Uppercased macros expand exactly as their lowercased equivalents, and
-   are then URL escaped.  URL escaping must be performed for characters
-   not in the "uric" set, which is defined in [RFC3986].
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 29]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   Note: Care must be taken so that macro expansion for legitimate
-   E-Mail does not exceed the 63-character limit on DNS labels.  The
-   localpart of E-Mail addresses, in particular, can have more than 63
-   characters between dots.
-
-   Note: Domains should avoid using the "s", "l", "o", or "h" macros in
-   conjunction with any mechanism directive.  Although these macros are
-   powerful and allow per-user records to be published, they severely
-   limit the ability of implementations to cache results of check_host()
-   and they reduce the effectiveness of DNS caches.
-
-   Implementations should be aware that if no directive processed during
-   the evaluation of check_host() contains an "s", "l", "o", or "h"
-   macro, then the results of the evaluation can be cached on the basis
-   of <domain> and <ip> alone for as long as the shortest Time To Live
-   (TTL) of all the DNS records involved.
-
-8.2.  Expansion Examples
-
-      The <sender> is strong-bad@email.example.com.
-      The IPv4 SMTP client IP is 192.0.2.3.
-      The IPv6 SMTP client IP is 2001:DB8::CB01.
-      The PTR domain name of the client IP is mx.example.org.
-
-   macro                       expansion
-   -------  ----------------------------
-   %{s}     strong-bad@email.example.com
-   %{o}                email.example.com
-   %{d}                email.example.com
-   %{d4}               email.example.com
-   %{d3}               email.example.com
-   %{d2}                     example.com
-   %{d1}                             com
-   %{dr}               com.example.email
-   %{d2r}                  example.email
-   %{l}                       strong-bad
-   %{l-}                      strong.bad
-   %{lr}                      strong-bad
-   %{lr-}                     bad.strong
-   %{l1r-}                        strong
-
-
-
-
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 30]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   macro-string                                               expansion
-   --------------------------------------------------------------------
-   %{ir}.%{v}._spf.%{d2}             3.2.0.192.in-addr._spf.example.com
-   %{lr-}.lp._spf.%{d2}                  bad.strong.lp._spf.example.com
-
-   %{lr-}.lp.%{ir}.%{v}._spf.%{d2}
-                       bad.strong.lp.3.2.0.192.in-addr._spf.example.com
-
-   %{ir}.%{v}.%{l1r-}.lp._spf.%{d2}
-                           3.2.0.192.in-addr.strong.lp._spf.example.com
-
-   %{d2}.trusted-domains.example.net
-                                example.com.trusted-domains.example.net
-
-   IPv6:
-   %{ir}.%{v}._spf.%{d2}                               1.0.B.C.0.0.0.0.
-   0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com
-
-9.  Implications
-
-   This section outlines the major implications that adoption of this
-   document will have on various entities involved in Internet E-Mail.
-   It is intended to make clear to the reader where this document
-   knowingly affects the operation of such entities.  This section is
-   not a "how-to" manual, or a "best practices" document, and it is not
-   a comprehensive list of what such entities should do in light of this
-   document.
-
-   This section is non-normative.
-
-9.1.  Sending Domains
-
-   Domains that wish to be compliant with this specification will need
-   to determine the list of hosts that they allow to use their domain
-   name in the "HELO" and "MAIL FROM" identities.  It is recognized that
-   forming such a list is not just a simple technical exercise, but
-   involves policy decisions with both technical and administrative
-   considerations.
-
-   It can be helpful to publish records that include a "tracking
-   exists:" mechanism.  By looking at the name server logs, a rough list
-   may then be generated.  For example:
-
-      v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 31]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-9.2.  Mailing Lists
-
-   Mailing lists must be aware of how they re-inject mail that is sent
-   to the list.  Mailing lists MUST comply with the requirements in
-   [RFC2821], Section 3.10, and [RFC1123], Section 5.3.6, that say that
-   the reverse-path MUST be changed to be the mailbox of a person or
-   other entity who administers the list.  Whereas the reasons for
-   changing the reverse-path are many and long-standing, SPF adds
-   enforcement to this requirement.
-
-   In practice, almost all mailing list software in use already complies
-   with this requirement.  Mailing lists that do not comply may or may
-   not encounter problems depending on how access to the list is
-   restricted.  Such lists that are entirely internal to a domain (only
-   people in the domain can send to or receive from the list) are not
-   affected.
-
-9.3.  Forwarding Services and Aliases
-
-   Forwarding services take mail that is received at a mailbox and
-   direct it to some external mailbox.  At the time of this writing, the
-   near-universal practice of such services is to use the original "MAIL
-   FROM" of a message when re-injecting it for delivery to the external
-   mailbox.  [RFC1123] and [RFC2821] describe this action as an "alias"
-   rather than a "mail list".  This means that the external mailbox's
-   MTA sees all such mail in a connection from a host of the forwarding
-   service, and so the "MAIL FROM" identity will not, in general, pass
-   authorization.
-
-   There are three places that techniques can be used to ameliorate this
-   problem.
-
-   1. The beginning, when E-Mail is first sent.
-
-       1. "Neutral" results could be given for IP addresses that may be
-          forwarders, instead of "Fail" results.  For example:
-
-             "v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.org ?all"
-
-          This would cause a lookup on an anti-spam DNS blacklist
-          (DNSBL) and cause a result of "Fail" only for E-Mail coming
-          from listed sources.  All other E-Mail, including E-Mail sent
-          through forwarders, would receive a "Neutral" result.  By
-          checking the DNSBL after the known good sources, problems with
-          incorrect listing on the DNSBL are greatly reduced.
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 32]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-       2. The "MAIL FROM" identity could have additional information in
-          the localpart that cryptographically identifies the mail as
-          coming from an authorized source.  In this case, such an SPF
-          record could be used:
-
-             "v=spf1 mx exists:%{l}._spf_verify.%{d} -all"
-
-          Then, a specialized DNS server can be set up to serve the
-          _spf_verify subdomain that validates the localpart.  Although
-          this requires an extra DNS lookup, this happens only when the
-          E-Mail would otherwise be rejected as not coming from a known
-          good source.
-
-          Note that due to the 63-character limit for domain labels,
-          this approach only works reliably if the localpart signature
-          scheme is guaranteed either to only produce localparts with a
-          maximum of 63 characters or to gracefully handle truncated
-          localparts.
-
-       3. Similarly, a specialized DNS server could be set up that will
-          rate-limit the E-Mail coming from unexpected IP addresses.
-
-             "v=spf1 mx exists:%{ir}._spf_rate.%{d} -all"
-
-       4. SPF allows the creation of per-user policies for special
-          cases.  For example, the following SPF record and appropriate
-          wildcard DNS records can be used:
-
-                 "v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}"
-
-   2.  The middle, when E-Mail is forwarded.
-
-       1. Forwarding services can solve the problem by rewriting the
-          "MAIL FROM" to be in their own domain.  This means that mail
-          bounced from the external mailbox will have to be re-bounced
-          by the forwarding service.  Various schemes to do this exist
-          though they vary widely in complexity and resource
-          requirements on the part of the forwarding service.
-
-       2. Several popular MTAs can be forced from "alias" semantics to
-          "mailing list" semantics by configuring an additional alias
-          with "owner-" prepended to the original alias name (e.g., an
-          alias of "friends: george@example.com, fred@example.org" would
-          need another alias of the form "owner-friends:  localowner").
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 33]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   3. The end, when E-Mail is received.
-
-       1. If the owner of the external mailbox wishes to trust the
-          forwarding service, he can direct the external mailbox's MTA
-          to skip SPF tests when the client host belongs to the
-          forwarding service.
-
-       2. Tests against other identities, such as the "HELO" identity,
-          may be used to override a failed test against the "MAIL FROM"
-          identity.
-
-       3. For larger domains, it may not be possible to have a complete
-          or accurate list of forwarding services used by the owners of
-          the domain's mailboxes.  In such cases, whitelists of
-          generally-recognized forwarding services could be employed.
-
-9.4.  Mail Services
-
-   Service providers that offer mail services to third-party domains,
-   such as sending of bulk mail, may want to adjust their setup in light
-   of the authorization check described in this document.  If the "MAIL
-   FROM" identity used for such E-Mail uses the domain of the service
-   provider, then the provider needs only to ensure that its sending
-   host is authorized by its own SPF record, if any.
-
-   If the "MAIL FROM" identity does not use the mail service provider's
-   domain, then extra care must be taken.  The SPF record format has
-   several options for the third-party domain to authorize the service
-   provider's MTAs to send mail on its behalf.  For mail service
-   providers, such as ISPs, that have a wide variety of customers using
-   the same MTA, steps should be taken to prevent cross-customer forgery
-   (see Section 10.4).
-
-9.5.  MTA Relays
-
-   The authorization check generally precludes the use of arbitrary MTA
-   relays between sender and receiver of an E-Mail message.
-
-   Within an organization, MTA relays can be effectively deployed.
-   However, for purposes of this document, such relays are effectively
-   transparent.  The SPF authorization check is a check between border
-   MTAs of different domains.
-
-   For mail senders, this means that published SPF records must
-   authorize any MTAs that actually send across the Internet.  Usually,
-   these are just the border MTAs as internal MTAs simply forward mail
-   to these MTAs for delivery.
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 34]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   Mail receivers will generally want to perform the authorization check
-   at the border MTAs, specifically including all secondary MXs.  This
-   allows mail that fails to be rejected during the SMTP session rather
-   than bounced.  Internal MTAs then do not perform the authorization
-   test.  To perform the authorization test other than at the border,
-   the host that first transferred the message to the organization must
-   be determined, which can be difficult to extract from the message
-   header.  Testing other than at the border is not recommended.
-
-10.  Security Considerations
-
-10.1.  Processing Limits
-
-   As with most aspects of E-Mail, there are a number of ways that
-   malicious parties could use the protocol as an avenue for a
-   Denial-of-Service (DoS) attack.  The processing limits outlined here
-   are designed to prevent attacks such as the following:
-
-   o  A malicious party could create an SPF record with many references
-      to a victim's domain and send many E-Mails to different SPF
-      clients; those SPF clients would then create a DoS attack.  In
-      effect, the SPF clients are being used to amplify the attacker's
-      bandwidth by using fewer bytes in the SMTP session than are used
-      by the DNS queries.  Using SPF clients also allows the attacker to
-      hide the true source of the attack.
-
-   o  Whereas implementations of check_host() are supposed to limit the
-      number of DNS lookups, malicious domains could publish records
-      that exceed these limits in an attempt to waste computation effort
-      at their targets when they send them mail.  Malicious domains
-      could also design SPF records that cause particular
-      implementations to use excessive memory or CPU usage, or to
-      trigger bugs.
-
-   o  Malicious parties could send a large volume of mail purporting to
-      come from the intended target to a wide variety of legitimate mail
-      hosts.  These legitimate machines would then present a DNS load on
-      the target as they fetched the relevant records.
-
-   Of these, the case of a third party referenced in the SPF record is
-   the easiest for a DoS attack to effectively exploit.  As a result,
-   limits that may seem reasonable for an individual mail server can
-   still allow an unreasonable amount of bandwidth amplification.
-   Therefore, the processing limits need to be quite low.
-
-   SPF implementations MUST limit the number of mechanisms and modifiers
-   that do DNS lookups to at most 10 per SPF check, including any
-   lookups caused by the use of the "include" mechanism or the
-
-
-
-Wong & Schlitt                Experimental                     [Page 35]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   "redirect" modifier.  If this number is exceeded during a check, a
-   PermError MUST be returned.  The "include", "a", "mx", "ptr", and
-   "exists" mechanisms as well as the "redirect" modifier do count
-   against this limit.  The "all", "ip4", and "ip6" mechanisms do not
-   require DNS lookups and therefore do not count against this limit.
-   The "exp" modifier does not count against this limit because the DNS
-   lookup to fetch the explanation string occurs after the SPF record
-   has been evaluated.
-
-   When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro,
-   there MUST be a limit of no more than 10 MX or PTR RRs looked up and
-   checked.
-
-   SPF implementations SHOULD limit the total amount of data obtained
-   from the DNS queries.  For example, when DNS over TCP or EDNS0 are
-   available, there may need to be an explicit limit to how much data
-   will be accepted to prevent excessive bandwidth usage or memory usage
-   and DoS attacks.
-
-   MTAs or other processors MAY also impose a limit on the maximum
-   amount of elapsed time to evaluate check_host().  Such a limit SHOULD
-   allow at least 20 seconds.  If such a limit is exceeded, the result
-   of authorization SHOULD be "TempError".
-
-   Domains publishing records SHOULD try to keep the number of "include"
-   mechanisms and chained "redirect" modifiers to a minimum.  Domains
-   SHOULD also try to minimize the amount of other DNS information
-   needed to evaluate a record.  This can be done by choosing directives
-   that require less DNS information and placing lower-cost mechanisms
-   earlier in the SPF record.
-
-   For example, consider a domain set up as follows:
-
-   example.com.      IN MX   10 mx.example.com.
-   mx.example.com.   IN A    192.0.2.1
-   a.example.com.    IN TXT  "v=spf1 mx:example.com -all"
-   b.example.com.    IN TXT  "v=spf1 a:mx.example.com -all"
-   c.example.com.    IN TXT  "v=spf1 ip4:192.0.2.1 -all"
-
-   Evaluating check_host() for the domain "a.example.com" requires the
-   MX records for "example.com", and then the A records for the listed
-   hosts.  Evaluating for "b.example.com" requires only the A records.
-   Evaluating for "c.example.com" requires none.
-
-   However, there may be administrative considerations: using "a" over
-   "ip4" allows hosts to be renumbered easily.  Using "mx" over "a"
-   allows the set of mail hosts to be changed easily.
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 36]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-10.2.  SPF-Authorized E-Mail May Contain Other False Identities
-
-   The "MAIL FROM" and "HELO" identity authorizations must not be
-   construed to provide more assurance than they do.  It is entirely
-   possible for a malicious sender to inject a message using his own
-   domain in the identities used by SPF, to have that domain's SPF
-   record authorize the sending host, and yet the message can easily
-   list other identities in its header.  Unless the user or the MUA
-   takes care to note that the authorized identity does not match the
-   other more commonly-presented identities (such as the From:  header
-   field), the user may be lulled into a false sense of security.
-
-10.3.  Spoofed DNS and IP Data
-
-   There are two aspects of this protocol that malicious parties could
-   exploit to undermine the validity of the check_host() function:
-
-   o  The evaluation of check_host() relies heavily on DNS.  A malicious
-      attacker could attack the DNS infrastructure and cause
-      check_host() to see spoofed DNS data, and then return incorrect
-      results.  This could include returning "Pass" for an <ip> value
-      where the actual domain's record would evaluate to "Fail".  See
-      [RFC3833] for a description of DNS weaknesses.
-
-   o  The client IP address, <ip>, is assumed to be correct.  A
-      malicious attacker could spoof TCP sequence numbers to make mail
-      appear to come from a permitted host for a domain that the
-      attacker is impersonating.
-
-10.4.  Cross-User Forgery
-
-   By definition, SPF policies just map domain names to sets of
-   authorized MTAs, not whole E-Mail addresses to sets of authorized
-   users.  Although the "l" macro (Section 8) provides a limited way to
-   define individual sets of authorized MTAs for specific E-Mail
-   addresses, it is generally impossible to verify, through SPF, the use
-   of specific E-Mail addresses by individual users of the same MTA.
-
-   It is up to mail services and their MTAs to directly prevent
-   cross-user forgery: based on SMTP AUTH ([RFC2554]), users should be
-   restricted to using only those E-Mail addresses that are actually
-   under their control (see [RFC4409], Section 6.1).  Another means to
-   verify the identity of individual users is message cryptography such
-   as PGP ([RFC2440]) or S/MIME ([RFC3851]).
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 37]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-10.5.  Untrusted Information Sources
-
-   SPF uses information supplied by third parties, such as the "HELO"
-   domain name, the "MAIL FROM" address, and SPF records.  This
-   information is then passed to the receiver in the Received-SPF: trace
-   fields and possibly returned to the client MTA in the form of an SMTP
-   rejection message.  This information must be checked for invalid
-   characters and excessively long lines.
-
-   When the authorization check fails, an explanation string may be
-   included in the reject response.  Both the sender and the rejecting
-   receiver need to be aware that the explanation was determined by the
-   publisher of the SPF record checked and, in general, not the
-   receiver.  The explanation may contain malicious URLs, or it may be
-   offensive or misleading.
-
-   This is probably less of a concern than it may initially seem since
-   such messages are returned to the sender, and the explanation strings
-   come from the sender policy published by the domain in the identity
-   claimed by that very sender.  As long as the DSN is not redirected to
-   someone other than the actual sender, the only people who see
-   malicious explanation strings are people whose messages claim to be
-   from domains that publish such strings in their SPF records.  In
-   practice, DSNs can be misdirected, such as when an MTA accepts an
-   E-Mail and then later generates a DSN to a forged address, or when an
-   E-Mail forwarder does not direct the DSN back to the original sender.
-
-10.6.  Privacy Exposure
-
-   Checking SPF records causes DNS queries to be sent to the domain
-   owner.  These DNS queries, especially if they are caused by the
-   "exists" mechanism, can contain information about who is sending
-   E-Mail and likely to which MTA the E-Mail is being sent.  This can
-   introduce some privacy concerns, which may be more or less of an
-   issue depending on local laws and the relationship between the domain
-   owner and the person sending the E-Mail.
-
-11.  Contributors and Acknowledgements
-
-   This document is largely based on the work of Meng Weng Wong and Mark
-   Lentczner.  Although, as this section acknowledges, many people have
-   contributed to this document, a very large portion of the writing and
-   editing are due to Meng and Mark.
-
-   This design owes a debt of parentage to [RMX] by Hadmut Danisch and
-   to [DMP] by Gordon Fecyk.  The idea of using a DNS record to check
-   the legitimacy of an E-Mail address traces its ancestry further back
-   through messages on the namedroppers mailing list by Paul Vixie
-
-
-
-Wong & Schlitt                Experimental                     [Page 38]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   [Vixie] (based on suggestion by Jim Miller) and by David Green
-   [Green].
-
-   Philip Gladstone contributed the concept of macros to the
-   specification, multiplying the expressiveness of the language and
-   making per-user and per-IP lookups possible.
-
-   The authors would also like to thank the literally hundreds of
-   individuals who have participated in the development of this design.
-   They are far too numerous to name, but they include the following:
-
-      The folks on the spf-discuss mailing list.
-      The folks on the SPAM-L mailing list.
-      The folks on the IRTF ASRG mailing list.
-      The folks on the IETF MARID mailing list.
-      The folks on #perl.
-
-12.  IANA Considerations
-
-12.1.  The SPF DNS Record Type
-
-   The IANA has assigned a new Resource Record Type and Qtype from the
-   DNS Parameters Registry for the SPF RR type with code 99.
-
-12.2.  The Received-SPF Mail Header Field
-
-   Per [RFC3864], the "Received-SPF:" header field is added to the IANA
-   Permanent Message Header Field Registry.  The following is the
-   registration template:
-
-      Header field name: Received-SPF
-      Applicable protocol: mail ([RFC2822])
-      Status: Experimental
-      Author/Change controller: IETF
-      Specification document(s): RFC 4408
-      Related information:
-      Requesting SPF Council review of any proposed changes and
-      additions to this field are recommended.  For information about
-      the SPF Council see http://www.openspf.org/Council
-
-13.  References
-
-13.1.  Normative References
-
-   [RFC1035]  Mockapetris, P., "Domain names - implementation and
-              specification", STD 13, RFC 1035, November 1987.
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 39]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
-              and Support", STD 3, RFC 1123, October 1989.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
-              April 2001.
-
-   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822, April
-              2001.
-
-   [RFC3464]  Moore, K. and G. Vaudreuil, "An Extensible Message Format
-              for Delivery Status Notifications", RFC 3464, January
-              2003.
-
-   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
-              (IPv6) Addressing Architecture", RFC 3513, April 2003.
-
-   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
-              Procedures for Message Header Fields", BCP 90, RFC 3864,
-              September 2004.
-
-   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
-              Resource Identifier (URI): Generic Syntax", STD 66, RFC
-              3986, January 2005.
-
-   [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
-              Specifications: ABNF", RFC 4234, October 2005.
-
-   [US-ASCII] American National Standards Institute (formerly United
-              States of America Standards Institute), "USA Code for
-              Information Interchange, X3.4", 1968.
-
-   ANSI X3.4-1968 has been replaced by newer versions with slight
-              modifications, but the 1968 version remains definitive for
-              the Internet.
-
-13.2  Informative References
-
-   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
-              STD 13, RFC 1034, November 1987.
-
-   [RFC1983]  Malkin, G., "Internet Users' Glossary", RFC 1983, August
-              1996.
-
-   [RFC2440]  Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
-              "OpenPGP Message Format", RFC 2440, November 1998.
-
-
-
-Wong & Schlitt                Experimental                     [Page 40]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   [RFC2554]  Myers, J., "SMTP Service Extension for Authentication",
-              RFC 2554, March 1999.
-
-   [RFC3696]  Klensin, J., "Application Techniques for Checking and
-              Transformation of Names", RFC 3696, February 2004.
-
-   [RFC3833]  Atkins, D. and R. Austein, "Threat Analysis of the Domain
-              Name System (DNS)", RFC 3833, August 2004.
-
-   [RFC3851]  Ramsdell, B., "Secure/Multipurpose Internet Mail
-              Extensions (S/MIME) Version 3.1 Message Specification",
-              RFC 3851, July 2004.
-
-   [RFC4409]  Gellens, R. and J. Klensin, "Message Submission for Mail",
-              RFC 4409, April 2006.
-
-   [RMX]      Danish, H., "The RMX DNS RR Type for light weight sender
-              authentication", Work In Progress
-
-   [DMP]      Fecyk, G., "Designated Mailers Protocol", Work In Progress
-
-   [Vixie]    Vixie, P., "Repudiating MAIL FROM", 2002.
-
-   [Green]    Green, D., "Domain-Authorized SMTP Mail", 2002.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 41]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-Appendix A.  Collected ABNF
-
-   This section is normative and any discrepancies with the ABNF
-   fragments in the preceding text are to be resolved in favor of this
-   grammar.
-
-   See [RFC4234] for ABNF notation.  Please note that as per this ABNF
-   definition, literal text strings (those in quotes) are case-
-   insensitive.  Hence, "mx" matches "mx", "MX", "mX", and "Mx".
-
-   record           = version terms *SP
-   version          = "v=spf1"
-
-   terms            = *( 1*SP ( directive / modifier ) )
-
-   directive        = [ qualifier ] mechanism
-   qualifier        = "+" / "-" / "?" / "~"
-   mechanism        = ( all / include
-                      / A / MX / PTR / IP4 / IP6 / exists )
-
-   all              = "all"
-   include          = "include"  ":" domain-spec
-   A                = "a"      [ ":" domain-spec ] [ dual-cidr-length ]
-   MX               = "mx"     [ ":" domain-spec ] [ dual-cidr-length ]
-   PTR              = "ptr"    [ ":" domain-spec ]
-   IP4              = "ip4"      ":" ip4-network   [ ip4-cidr-length ]
-   IP6              = "ip6"      ":" ip6-network   [ ip6-cidr-length ]
-   exists           = "exists"   ":" domain-spec
-
-   modifier         = redirect / explanation / unknown-modifier
-   redirect         = "redirect" "=" domain-spec
-   explanation      = "exp" "=" domain-spec
-   unknown-modifier = name "=" macro-string
-
-   ip4-cidr-length  = "/" 1*DIGIT
-   ip6-cidr-length  = "/" 1*DIGIT
-   dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
-
-   ip4-network      = qnum "." qnum "." qnum "." qnum
-   qnum             = DIGIT                 ; 0-9
-                      / %x31-39 DIGIT       ; 10-99
-                      / "1" 2DIGIT          ; 100-199
-                      / "2" %x30-34 DIGIT   ; 200-249
-                      / "25" %x30-35        ; 250-255
-             ; conventional dotted quad notation.  e.g., 192.0.2.0
-   ip6-network      = <as per [RFC 3513], section 2.2>
-             ; e.g., 2001:DB8::CD30
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 42]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   domain-spec      = macro-string domain-end
-   domain-end       = ( "." toplabel [ "." ] ) / macro-expand
-   toplabel         = ( *alphanum ALPHA *alphanum ) /
-                      ( 1*alphanum "-" *( alphanum / "-" ) alphanum )
-                      ; LDH rule plus additional TLD restrictions
-                      ; (see [RFC3696], Section 2)
-
-   alphanum         = ALPHA / DIGIT
-
-   explain-string   = *( macro-string / SP )
-
-   macro-string     = *( macro-expand / macro-literal )
-   macro-expand     = ( "%{" macro-letter transformers *delimiter "}" )
-                      / "%%" / "%_" / "%-"
-   macro-literal    = %x21-24 / %x26-7E
-                      ; visible characters except "%"
-   macro-letter     = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
-                      "c" / "r" / "t"
-   transformers     = *DIGIT [ "r" ]
-   delimiter        = "." / "-" / "+" / "," / "/" / "_" / "="
-
-   name             = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
-
-   header-field     = "Received-SPF:" [CFWS] result FWS [comment FWS]
-                      [ key-value-list ] CRLF
-
-   result           = "Pass" / "Fail" / "SoftFail" / "Neutral" /
-                      "None" / "TempError" / "PermError"
-
-   key-value-list   = key-value-pair *( ";" [CFWS] key-value-pair )
-                      [";"]
-
-   key-value-pair   = key [CFWS] "=" ( dot-atom / quoted-string )
-
-   key              = "client-ip" / "envelope-from" / "helo" /
-                      "problem" / "receiver" / "identity" /
-                       mechanism / "x-" name / name
-
-   identity         = "mailfrom"   ; for the "MAIL FROM" identity
-                      / "helo"     ; for the "HELO" identity
-                      / name       ; other identities
-
-   dot-atom         = <unquoted word as per [RFC2822]>
-   quoted-string    = <quoted string as per [RFC2822]>
-   comment          = <comment string as per [RFC2822]>
-   CFWS             = <comment or folding white space as per [RFC2822]>
-   FWS              = <folding white space as per [RFC2822]>
-   CRLF             = <standard end-of-line token as per [RFC2822]>
-
-
-
-Wong & Schlitt                Experimental                     [Page 43]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-Appendix B.  Extended Examples
-
-   These examples are based on the following DNS setup:
-
-   ; A domain with two mail servers, two hosts
-   ; and two servers at the domain name
-   $ORIGIN example.com.
-   @           MX  10 mail-a
-               MX  20 mail-b
-               A   192.0.2.10
-               A   192.0.2.11
-   amy         A   192.0.2.65
-   bob         A   192.0.2.66
-   mail-a      A   192.0.2.129
-   mail-b      A   192.0.2.130
-   www         CNAME example.com.
-
-   ; A related domain
-   $ORIGIN example.org.
-   @           MX  10 mail-c
-   mail-c      A   192.0.2.140
-
-   ; The reverse IP for those addresses
-   $ORIGIN 2.0.192.in-addr.arpa.
-   10          PTR example.com.
-   11          PTR example.com.
-   65          PTR amy.example.com.
-   66          PTR bob.example.com.
-   129         PTR mail-a.example.com.
-   130         PTR mail-b.example.com.
-   140         PTR mail-c.example.org.
-
-   ; A rogue reverse IP domain that claims to be
-   ; something it's not
-   $ORIGIN 0.0.10.in-addr.arpa.
-   4           PTR bob.example.com.
-
-B.1.  Simple Examples
-
-   These examples show various possible published records for
-   example.com and which values if <ip> would cause check_host() to
-   return "Pass".  Note that <domain> is "example.com".
-
-   v=spf1 +all
-      -- any <ip> passes
-
-   v=spf1 a -all
-      -- hosts 192.0.2.10 and 192.0.2.11 pass
-
-
-
-Wong & Schlitt                Experimental                     [Page 44]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-   v=spf1 a:example.org -all
-      -- no sending hosts pass since example.org has no A records
-
-   v=spf1 mx -all
-      -- sending hosts 192.0.2.129 and 192.0.2.130 pass
-
-   v=spf1 mx:example.org -all
-      -- sending host 192.0.2.140 passes
-
-   v=spf1 mx mx:example.org -all
-      -- sending hosts 192.0.2.129, 192.0.2.130, and 192.0.2.140 pass
-
-   v=spf1 mx/30 mx:example.org/30 -all
-      -- any sending host in 192.0.2.128/30 or 192.0.2.140/30 passes
-
-   v=spf1 ptr -all
-      -- sending host 192.0.2.65 passes (reverse DNS is valid and is in
-         example.com)
-      -- sending host 192.0.2.140 fails (reverse DNS is valid, but not
-         in example.com)
-      -- sending host 10.0.0.4 fails (reverse IP is not valid)
-
-   v=spf1 ip4:192.0.2.128/28 -all
-      -- sending host 192.0.2.65 fails
-      -- sending host 192.0.2.129 passes
-
-B.2.  Multiple Domain Example
-
-   These examples show the effect of related records:
-
-      example.org: "v=spf1 include:example.com include:example.net -all"
-
-   This record would be used if mail from example.org actually came
-   through servers at example.com and example.net.  Example.org's
-   designated servers are the union of example.com's and example.net's
-   designated servers.
-
-      la.example.org: "v=spf1 redirect=example.org"
-      ny.example.org: "v=spf1 redirect=example.org"
-      sf.example.org: "v=spf1 redirect=example.org"
-
-   These records allow a set of domains that all use the same mail
-   system to make use of that mail system's record.  In this way, only
-   the mail system's record needs to be updated when the mail setup
-   changes.  These domains' records never have to change.
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 45]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-B.3.  DNSBL Style Example
-
-   Imagine that, in addition to the domain records listed above, there
-   are these:
-
-   $ORIGIN _spf.example.com.  mary.mobile-users                   A
-   127.0.0.2 fred.mobile-users                   A 127.0.0.2
-   15.15.168.192.joel.remote-users     A 127.0.0.2
-   16.15.168.192.joel.remote-users     A 127.0.0.2
-
-   The following records describe users at example.com who mail from
-   arbitrary servers, or who mail from personal servers.
-
-   example.com:
-
-   v=spf1 mx
-          include:mobile-users._spf.%{d}
-          include:remote-users._spf.%{d}
-          -all
-
-   mobile-users._spf.example.com:
-
-   v=spf1 exists:%{l1r+}.%{d}
-
-   remote-users._spf.example.com:
-
-   v=spf1 exists:%{ir}.%{l1r+}.%{d}
-
-B.4.  Multiple Requirements Example
-
-   Say that your sender policy requires both that the IP address is
-   within a certain range and that the reverse DNS for the IP matches.
-   This can be done several ways, including the following:
-
-   example.com.           SPF  ( "v=spf1 "
-                                 "-include:ip4._spf.%{d} "
-                                 "-include:ptr._spf.%{d} "
-                                 "+all" )
-   ip4._spf.example.com.  SPF  "v=spf1 -ip4:192.0.2.0/24 +all"
-   ptr._spf.example.com.  SPF  "v=spf1 -ptr +all"
-
-   This example shows how the "-include" mechanism can be useful, how an
-   SPF record that ends in "+all" can be very restrictive, and the use
-   of De Morgan's Law.
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 46]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-Authors' Addresses
-
-   Meng Weng Wong
-   Singapore
-
-   EMail: mengwong+spf@pobox.com
-
-
-   Wayne Schlitt
-   4615 Meredeth #9
-   Lincoln Nebraska, NE  68506
-   United States of America
-
-   EMail: wayne@schlitt.net
-   URI:   http://www.schlitt.net/spf/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 47]
-
-RFC 4408             Sender Policy Framework (SPF)            April 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   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.
-
-Intellectual Property
-
-   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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Wong & Schlitt                Experimental                     [Page 48]
-
diff --git a/contrib/bind9/doc/rfc/rfc4431.txt b/contrib/bind9/doc/rfc/rfc4431.txt
deleted file mode 100644
index 8b38872..0000000
--- a/contrib/bind9/doc/rfc/rfc4431.txt
+++ /dev/null
@@ -1,227 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         M. Andrews
-Request for Comments: 4431                   Internet Systems Consortium
-Category: Informational                                        S. Weiler
-                                                            SPARTA, Inc.
-                                                           February 2006
-
-
-       The DNSSEC Lookaside Validation (DLV) DNS Resource Record
-
-Status of This Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document defines a new DNS resource record, called the DNSSEC
-   Lookaside Validation (DLV) RR, for publishing DNSSEC trust anchors
-   outside of the DNS delegation chain.
-
-1.  Introduction
-
-   DNSSEC [1] [2] [3] authenticates DNS data by building public-key
-   signature chains along the DNS delegation chain from a trust anchor,
-   ideally a trust anchor for the DNS root.
-
-   This document defines a new resource record for publishing such trust
-   anchors outside of the DNS's normal delegation chain.  Use of these
-   records by DNSSEC validators is outside the scope of this document,
-   but it is expected that these records will help resolvers validate
-   DNSSEC-signed data from zones whose ancestors either aren't signed or
-   refuse to publish delegation signer (DS) records for their children.
-
-2.  DLV Resource Record
-
-   The DLV resource record has exactly the same wire and presentation
-   formats as the DS resource record, defined in RFC 4034, Section 5.
-   It uses the same IANA-assigned values in the algorithm and digest
-   type fields as the DS record.  (Those IANA registries are known as
-   the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm
-   Numbers" registries.)
-
-
-
-
-
-Andrews & Weiler             Informational                      [Page 1]
-
-RFC 4431                  DLV Resource Record              February 2006
-
-
-   The DLV record is a normal DNS record type without any special
-   processing requirements.  In particular, the DLV record does not
-   inherit any of the special processing or handling requirements of the
-   DS record type (described in Section 3.1.4.1 of RFC 4035).  Unlike
-   the DS record, the DLV record may not appear on the parent's side of
-   a zone cut.  A DLV record may, however, appear at the apex of a zone.
-
-3.  Security Considerations
-
-   For authoritative servers and resolvers that do not attempt to use
-   DLV RRs as part of DNSSEC validation, there are no particular
-   security concerns -- DLV RRs are just like any other DNS data.
-
-   Software using DLV RRs as part of DNSSEC validation will almost
-   certainly want to impose constraints on their use, but those
-   constraints are best left to be described by the documents that more
-   fully describe the particulars of how the records are used.  At a
-   minimum, it would be unwise to use the records without some sort of
-   cryptographic authentication.  More likely than not, DNSSEC itself
-   will be used to authenticate the DLV RRs.  Depending on how a DLV RR
-   is used, failure to properly authenticate it could lead to
-   significant additional security problems including failure to detect
-   spoofed DNS data.
-
-   RFC 4034, Section 8, describes security considerations specific to
-   the DS RR.  Those considerations are equally applicable to DLV RRs.
-   Of particular note, the key tag field is used to help select DNSKEY
-   RRs efficiently, but it does not uniquely identify a single DNSKEY
-   RR.  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 that uses only the key tag to select a DNSKEY RR might
-   select the wrong public key in some circumstances.
-
-   For further discussion of the security implications of DNSSEC, see
-   RFC 4033, RFC 4034, and RFC 4035.
-
-4.  IANA Considerations
-
-   IANA has assigned DNS type code 32769 to the DLV resource record from
-   the Specification Required portion of the DNS Resource Record Type
-   registry, as defined in [4].
-
-   The DLV resource record reuses the same algorithm and digest type
-   registries already used for the DS resource record, currently known
-   as the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm
-   Numbers" registries.
-
-
-
-
-
-Andrews & Weiler             Informational                      [Page 2]
-
-RFC 4431                  DLV Resource Record              February 2006
-
-
-5.  Normative References
-
-   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033,
-        March 2005.
-
-   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Resource Records for the DNS Security Extensions", RFC 4034,
-        March 2005.
-
-   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions",
-        RFC 4035, March 2005.
-
-   [4]  Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain Name
-        System (DNS) IANA Considerations", BCP 42, RFC 2929,
-        September 2000.
-
-Authors' Addresses
-
-   Mark Andrews
-   Internet Systems Consortium
-   950 Charter St.
-   Redwood City, CA  94063
-   US
-
-   EMail: Mark_Andrews@isc.org
-
-
-   Samuel Weiler
-   SPARTA, Inc.
-   7075 Samuel Morse Drive
-   Columbia, Maryland  21046
-   US
-
-   EMail: weiler@tislabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Andrews & Weiler             Informational                      [Page 3]
-
-RFC 4431                  DLV Resource Record              February 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   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.
-
-Intellectual Property
-
-   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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Andrews & Weiler             Informational                      [Page 4]
-
diff --git a/contrib/bind9/doc/rfc/rfc4470.txt b/contrib/bind9/doc/rfc/rfc4470.txt
deleted file mode 100644
index ac12d65..0000000
--- a/contrib/bind9/doc/rfc/rfc4470.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          S. Weiler
-Request for Comments: 4470                                  SPARTA, Inc.
-Updates: 4035, 4034                                             J. Ihren
-Category: Standards Track                                  Autonomica AB
-                                                              April 2006
-
-
-       Minimally Covering NSEC Records and DNSSEC On-line Signing
-
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes how to construct DNSSEC NSEC resource records
-   that cover a smaller range of names than called for by RFC 4034.  By
-   generating and signing these records on demand, authoritative name
-   servers can effectively stop the disclosure of zone contents
-   otherwise made possible by walking the chain of NSEC records in a
-   signed zone.
-
-Table of Contents
-
-   1. Introduction ....................................................1
-   2. Applicability of This Technique .................................2
-   3. Minimally Covering NSEC Records .................................2
-   4. Better Epsilon Functions ........................................4
-   5. Security Considerations .........................................5
-   6. Acknowledgements ................................................6
-   7. Normative References ............................................6
-
-1.  Introduction
-
-   With DNSSEC [1], an NSEC record lists the next instantiated name in
-   its zone, proving that no names exist in the "span" between the
-   NSEC's owner name and the name in the "next name" field.  In this
-   document, an NSEC record is said to "cover" the names between its
-   owner name and next name.
-
-
-
-Weiler & Ihren              Standards Track                     [Page 1]
-
-RFC 4470                      NSEC Epsilon                    April 2006
-
-
-   Through repeated queries that return NSEC records, it is possible to
-   retrieve all of the names in the zone, a process commonly called
-   "walking" the zone.  Some zone owners have policies forbidding zone
-   transfers by arbitrary clients; this side effect of the NSEC
-   architecture subverts those policies.
-
-   This document presents a way to prevent zone walking by constructing
-   NSEC records that cover fewer names.  These records can make zone
-   walking take approximately as many queries as simply asking for all
-   possible names in a zone, making zone walking impractical.  Some of
-   these records must be created and signed on demand, which requires
-   on-line private keys.  Anyone contemplating use of this technique is
-   strongly encouraged to review the discussion of the risks of on-line
-   signing in Section 5.
-
-1.2.  Keywords
-
-   The keywords "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 [4].
-
-2.  Applicability of This Technique
-
-   The technique presented here may be useful to a zone owner that wants
-   to use DNSSEC, is concerned about exposure of its zone contents via
-   zone walking, and is willing to bear the costs of on-line signing.
-
-   As discussed in Section 5, on-line signing has several security
-   risks, including an increased likelihood of private keys being
-   disclosed and an increased risk of denial of service attack.  Anyone
-   contemplating use of this technique is strongly encouraged to review
-   the discussion of the risks of on-line signing in Section 5.
-
-   Furthermore, at the time this document was published, the DNSEXT
-   working group was actively working on a mechanism to prevent zone
-   walking that does not require on-line signing (tentatively called
-   NSEC3).  The new mechanism is likely to expose slightly more
-   information about the zone than this technique (e.g., the number of
-   instantiated names), but it may be preferable to this technique.
-
-3.  Minimally Covering NSEC Records
-
-   This mechanism involves changes to NSEC records for instantiated
-   names, which can still be generated and signed in advance, as well as
-   the on-demand generation and signing of new NSEC records whenever a
-   name must be proven not to exist.
-
-
-
-
-
-Weiler & Ihren              Standards Track                     [Page 2]
-
-RFC 4470                      NSEC Epsilon                    April 2006
-
-
-   In the "next name" field of instantiated names' NSEC records, rather
-   than list the next instantiated name in the zone, list any name that
-   falls lexically after the NSEC's owner name and before the next
-   instantiated name in the zone, according to the ordering function in
-   RFC 4034 [2] Section 6.1.  This relaxes the requirement in Section
-   4.1.1 of RFC 4034 that the "next name" field contains the next owner
-   name in the zone.  This change is expected to be fully compatible
-   with all existing DNSSEC validators.  These NSEC records are returned
-   whenever proving something specifically about the owner name (e.g.,
-   that no resource records of a given type appear at that name).
-
-   Whenever an NSEC record is needed to prove the non-existence of a
-   name, a new NSEC record is dynamically produced and signed.  The new
-   NSEC record has an owner name lexically before the QNAME but
-   lexically following any existing name and a "next name" lexically
-   following the QNAME but before any existing name.
-
-   The generated NSEC record's type bitmap MUST have the RRSIG and NSEC
-   bits set and SHOULD NOT have any other bits set.  This relaxes the
-   requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at
-   names that did not exist before the zone was signed.
-
-   The functions to generate the lexically following and proceeding
-   names need not be perfect or consistent, but the generated NSEC
-   records must not cover any existing names.  Furthermore, this
-   technique works best when the generated NSEC records cover as few
-   names as possible.  In this document, the functions that generate the
-   nearby names are called "epsilon" functions, a reference to the
-   mathematical convention of using the greek letter epsilon to
-   represent small deviations.
-
-   An NSEC record denying the existence of a wildcard may be generated
-   in the same way.  Since the NSEC record covering a non-existent
-   wildcard is likely to be used in response to many queries,
-   authoritative name servers using the techniques described here may
-   want to pregenerate or cache that record and its corresponding RRSIG.
-
-   For example, a query for an A record at the non-instantiated name
-   example.com might produce the following two NSEC records, the first
-   denying the existence of the name example.com and the second denying
-   the existence of a wildcard:
-
-          exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC )
-
-          \).com 3600 IN NSEC +.com ( RRSIG NSEC )
-
-
-
-
-
-
-Weiler & Ihren              Standards Track                     [Page 3]
-
-RFC 4470                      NSEC Epsilon                    April 2006
-
-
-   Before answering a query with these records, an authoritative server
-   must test for the existence of names between these endpoints.  If the
-   generated NSEC would cover existing names (e.g., exampldd.com or
-   *bizarre.example.com), a better epsilon function may be used or the
-   covered name closest to the QNAME could be used as the NSEC owner
-   name or next name, as appropriate.  If an existing name is used as
-   the NSEC owner name, that name's real NSEC record MUST be returned.
-   Using the same example, assuming an exampldd.com delegation exists,
-   this record might be returned from the parent:
-
-          exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC )
-
-   Like every authoritative record in the zone, each generated NSEC
-   record MUST have corresponding RRSIGs generated using each algorithm
-   (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as
-   described in RFC 4035 [3] Section 2.2.  To minimize the number of
-   signatures that must be generated, a zone may wish to limit the
-   number of algorithms in its DNSKEY RRset.
-
-4.  Better Epsilon Functions
-
-   Section 6.1 of RFC 4034 defines a strict ordering of DNS names.
-   Working backward from that definition, it should be possible to
-   define epsilon functions that generate the immediately following and
-   preceding names, respectively.  This document does not define such
-   functions.  Instead, this section presents functions that come
-   reasonably close to the perfect ones.  As described above, an
-   authoritative server should still ensure than no generated NSEC
-   covers any existing name.
-
-   To increment a name, add a leading label with a single null (zero-
-   value) octet.
-
-   To decrement a name, decrement the last character of the leftmost
-   label, then fill that label to a length of 63 octets with octets of
-   value 255.  To decrement a null (zero-value) octet, remove the octet
-   -- if an empty label is left, remove the label.  Defining this
-   function numerically: fill the leftmost label to its maximum length
-   with zeros (numeric, not ASCII zeros) and subtract one.
-
-   In response to a query for the non-existent name foo.example.com,
-   these functions produce NSEC records of the following:
-
-
-
-
-
-
-
-
-
-Weiler & Ihren              Standards Track                     [Page 4]
-
-RFC 4470                      NSEC Epsilon                    April 2006
-
-
-     fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG )
-
-     \)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
-     \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )
-
-   The first of these NSEC RRs proves that no exact match for
-   foo.example.com exists, and the second proves that there is no
-   wildcard in example.com.
-
-   Both of these functions are imperfect: they do not take into account
-   constraints on number of labels in a name nor total length of a name.
-   As noted in the previous section, though, this technique does not
-   depend on the use of perfect epsilon functions: it is sufficient to
-   test whether any instantiated names fall into the span covered by the
-   generated NSEC and, if so, substitute those instantiated owner names
-   for the NSEC owner name or next name, as appropriate.
-
-5.  Security Considerations
-
-   This approach requires on-demand generation of RRSIG records.  This
-   creates several new vulnerabilities.
-
-   First, on-demand signing requires that a zone's authoritative servers
-   have access to its private keys.  Storing private keys on well-known
-   Internet-accessible servers may make them more vulnerable to
-   unintended disclosure.
-
-   Second, since generation of digital signatures tends to be
-   computationally demanding, the requirement for on-demand signing
-   makes authoritative servers vulnerable to a denial of service attack.
-
-   Last, if the epsilon functions are predictable, on-demand signing may
-   enable a chosen-plaintext attack on a zone's private keys.  Zones
-   using this approach should attempt to use cryptographic algorithms
-   that are resistant to chosen-plaintext attacks.  It is worth noting
-   that although DNSSEC has a "mandatory to implement" algorithm, that
-   is a requirement on resolvers and validators -- there is no
-   requirement that a zone be signed with any given algorithm.
-
-   The success of using minimally covering NSEC records to prevent zone
-   walking depends greatly on the quality of the epsilon functions
-
-
-
-Weiler & Ihren              Standards Track                     [Page 5]
-
-RFC 4470                      NSEC Epsilon                    April 2006
-
-
-   chosen.  An increment function that chooses a name obviously derived
-   from the next instantiated name may be easily reverse engineered,
-   destroying the value of this technique.  An increment function that
-   always returns a name close to the next instantiated name is likewise
-   a poor choice.  Good choices of epsilon functions are the ones that
-   produce the immediately following and preceding names, respectively,
-   though zone administrators may wish to use less perfect functions
-   that return more human-friendly names than the functions described in
-   Section 4 above.
-
-   Another obvious but misguided concern is the danger from synthesized
-   NSEC records being replayed.  It is possible for an attacker to
-   replay an old but still validly signed NSEC record after a new name
-   has been added in the span covered by that NSEC, incorrectly proving
-   that there is no record at that name.  This danger exists with DNSSEC
-   as defined in [3].  The techniques described here actually decrease
-   the danger, since the span covered by any NSEC record is smaller than
-   before.  Choosing better epsilon functions will further reduce this
-   danger.
-
-6.  Acknowledgements
-
-   Many individuals contributed to this design.  They include, in
-   addition to the authors of this document, Olaf Kolkman, Ed Lewis,
-   Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
-   Jakob Schlyter, Bill Manning, and Joao Damas.
-
-   In addition, the editors would like to thank Ed Lewis, Scott Rose,
-   and David Blacka for their careful review of the document.
-
-7.  Normative References
-
-   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "DNS Security Introduction and Requirements", RFC 4033, March
-        2005.
-
-   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Resource Records for the DNS Security Extensions", RFC 4034,
-        March 2005.
-
-   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-        "Protocol Modifications for the DNS Security Extensions", RFC
-        4035, March 2005.
-
-   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-
-Weiler & Ihren              Standards Track                     [Page 6]
-
-RFC 4470                      NSEC Epsilon                    April 2006
-
-
-Authors' Addresses
-
-   Samuel Weiler
-   SPARTA, Inc.
-   7075 Samuel Morse Drive
-   Columbia, Maryland  21046
-   US
-
-   EMail: weiler@tislabs.com
-
-
-   Johan Ihren
-   Autonomica AB
-   Bellmansgatan 30
-   Stockholm  SE-118 47
-   Sweden
-
-   EMail: johani@autonomica.se
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weiler & Ihren              Standards Track                     [Page 7]
-
-RFC 4470                      NSEC Epsilon                    April 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   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.
-
-Intellectual Property
-
-   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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Weiler & Ihren              Standards Track                     [Page 8]
-
diff --git a/contrib/bind9/doc/rfc/rfc4634.txt b/contrib/bind9/doc/rfc/rfc4634.txt
deleted file mode 100644
index b672df8..0000000
--- a/contrib/bind9/doc/rfc/rfc4634.txt
+++ /dev/null
@@ -1,6051 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                    D. Eastlake 3rd
-Request for Comments: 4634                                 Motorola Labs
-Updates: 3174                                                  T. Hansen
-Category: Informational                                        AT&T Labs
-                                                               July 2006
-
-
-              US Secure Hash Algorithms (SHA and HMAC-SHA)
-
-Status of This Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   The United States of America has adopted a suite of Secure Hash
-   Algorithms (SHAs), including four beyond SHA-1, as part of a Federal
-   Information Processing Standard (FIPS), specifically SHA-224 (RFC
-   3874), SHA-256, SHA-384, and SHA-512.  The purpose of this document
-   is to make source code performing these hash functions conveniently
-   available to the Internet community.  The sample code supports input
-   strings of arbitrary bit length.  SHA-1's sample code from RFC 3174
-   has also been updated to handle input strings of arbitrary bit
-   length.  Most of the text herein was adapted by the authors from FIPS
-   180-2.
-
-   Code to perform SHA-based HMACs, with arbitrary bit length text, is
-   also included.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                      [Page 1]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-Table of Contents
-
-   1. Overview of Contents ............................................3
-      1.1. License ....................................................4
-   2. Notation for Bit Strings and Integers ...........................4
-   3. Operations on Words .............................................5
-   4. Message Padding and Parsing .....................................6
-      4.1. SHA-224 and SHA-256 ........................................7
-      4.2. SHA-384 and SHA-512 ........................................8
-   5. Functions and Constants Used ....................................9
-      5.1. SHA-224 and SHA-256 ........................................9
-      5.2. SHA-384 and SHA-512 .......................................10
-   6. Computing the Message Digest ...................................11
-      6.1. SHA-224 and SHA-256 Initialization ........................11
-      6.2. SHA-224 and SHA-256 Processing ............................11
-      6.3. SHA-384 and SHA-512 Initialization ........................13
-      6.4. SHA-384 and SHA-512 Processing ............................14
-   7. SHA-Based HMACs ................................................15
-   8. C Code for SHAs ................................................15
-      8.1. The .h File ...............................................18
-      8.2. The SHA Code ..............................................24
-           8.2.1. sha1.c .............................................24
-           8.2.2. sha224-256.c .......................................33
-           8.2.3. sha384-512.c .......................................45
-           8.2.4. usha.c .............................................67
-           8.2.5. sha-private.h ......................................72
-      8.3. The HMAC Code .............................................73
-      8.4. The Test Driver ...........................................78
-   9. Security Considerations .......................................106
-   10. Normative References .........................................106
-   11. Informative References .......................................106
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                      [Page 2]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-1.  Overview of Contents
-
-   NOTE: Much of the text below is taken from [FIPS180-2] and assertions
-   therein of the security of the algorithms described are made by the
-   US Government, the author of [FIPS180-2], and not by the authors of
-   this document.
-
-   The text below specifies Secure Hash Algorithms, SHA-224 [RFC3874],
-   SHA-256, SHA-384, and SHA-512, for computing a condensed
-   representation of a message or a data file. (SHA-1 is specified in
-   [RFC3174].)  When a message of any length < 2^64 bits (for SHA-224
-   and SHA-256) or < 2^128 bits (for SHA-384 and SHA-512) is input to
-   one of these algorithms, the result is an output called a message
-   digest.  The message digests range in length from 224 to 512 bits,
-   depending on the algorithm.  Secure hash algorithms are typically
-   used with other cryptographic algorithms, such as digital signature
-   algorithms and keyed hash authentication codes, or in the generation
-   of random numbers [RFC4086].
-
-   The four algorithms specified in this document are called secure
-   because it is computationally infeasible to (1) find a message that
-   corresponds to a given message digest, or (2) find two different
-   messages that produce the same message digest.  Any change to a
-   message in transit will, with very high probability, result in a
-   different message digest.  This will result in a verification failure
-   when the secure hash algorithm is used with a digital signature
-   algorithm or a keyed-hash message authentication algorithm.
-
-   The code provided herein supports input strings of arbitrary bit
-   length.  SHA-1's sample code from [RFC3174] has also been updated to
-   handle input strings of arbitrary bit length.  See Section 1.1 for
-   license information for this code.
-
-   Section 2 below defines the terminology and functions used as
-   building blocks to form these algorithms.  Section 3 describes the
-   fundamental operations on words from which these algorithms are
-   built.  Section 4 describes how messages are padded up to an integral
-   multiple of the required block size and then parsed into blocks.
-   Section 5 defines the constants and the composite functions used to
-   specify these algorithms.  Section 6 gives the actual specification
-   for the SHA-224, SHA-256, SHA-384, and SHA-512 functions.  Section 7
-   provides pointers to the specification of HMAC keyed message
-   authentication codes based on the SHA algorithms.  Section 8 gives
-   sample code for the SHA algorithms and Section 9 code for SHA-based
-   HMACs.  The SHA-based HMACs will accept arbitrary bit length text.
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                      [Page 3]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-1.1.  License
-
-   Permission is granted for all uses, commercial and non-commercial, of
-   the sample code found in Section 8.  Royalty free license to use,
-   copy, modify and distribute the software found in Section 8 is
-   granted, provided that this document is identified in all material
-   mentioning or referencing this software, and provided that
-   redistributed derivative works do not contain misleading author or
-   version information.
-
-   The authors make no representations concerning either the
-   merchantability of this software or the suitability of this software
-   for any particular purpose.  It is provided "as is" without express
-   or implied warranty of any kind.
-
-2.  Notation for Bit Strings and Integers
-
-   The following terminology related to bit strings and integers will be
-   used:
-
-    a.  A hex digit is an element of the set {0, 1, ... , 9, A, ... ,
-        F}.  A hex digit is the representation of a 4-bit string.
-        Examples: 7 = 0111, A = 1010.
-
-    b.  A word equals a 32-bit or 64-bit string, which may be
-        represented as a sequence of 8 or 16 hex digits, respectively.
-        To convert a word to hex digits, each 4-bit string is converted
-        to its hex equivalent as described in (a) above.  Example:
-
-        1010 0001 0000 0011 1111 1110 0010 0011 = A103FE23.
-
-        Throughout this document, the "big-endian" convention is used
-        when expressing both 32-bit and 64-bit words, so that within
-        each word the most significant bit is shown in the left-most bit
-        position.
-
-    c.  An integer may be represented as a word or pair of words.
-
-        An integer between 0 and 2^32 - 1 inclusive may be represented
-        as a 32-bit word.  The least significant four bits of the
-        integer are represented by the right-most hex digit of the word
-        representation.  Example: the integer 291 = 2^8+2^5+2^1+2^0 =
-        256+32+2+1 is represented by the hex word 00000123.
-
-        The same holds true for an integer between 0 and 2^64-1
-        inclusive, which may be represented as a 64-bit word.
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                      [Page 4]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-        If Z is an integer, 0 <= z < 2^64, then z = (2^32)x + y where 0
-        <= x < 2^32 and 0 <= y < 2^32.  Since x and y can be represented
-        as words X and Y, respectively, z can be represented as the pair
-        of words (X,Y).
-
-    d.  block = 512-bit or 1024-bit string.  A block (e.g., B) may be
-        represented as a sequence of 32-bit or 64-bit words.
-
-3.  Operations on Words
-
-   The following logical operators will be applied to words in all four
-   hash operations specified herein.  SHA-224 and SHA-256 operate on
-   32-bit words, while SHA-384 and SHA-512 operate on 64-bit words.
-
-   In the operations below, x<<n is obtained as follows: discard the
-   left-most n bits of x and then pad the result with n zeroed bits on
-   the right (the result will still be the same number of bits).
-
-    a.  Bitwise logical word operations
-
-        X AND Y  =  bitwise logical "and" of  X and Y.
-
-        X OR Y   =  bitwise logical "inclusive-or" of X and Y.
-
-        X XOR Y  =  bitwise logical "exclusive-or" of X and Y.
-
-        NOT X    =  bitwise logical "complement" of X.
-
-        Example:
-                 01101100101110011101001001111011
-           XOR   01100101110000010110100110110111
-                 --------------------------------
-             =   00001001011110001011101111001100
-
-    b.  The operation X + Y is defined as follows: words X and Y
-        represent w-bit integers x and y, where 0 <= x < 2^w and
-        0 <= y < 2^w.  For positive integers n and m, let
-
-             n mod m
-
-        be the remainder upon dividing n by m.  Compute
-
-             z  =  (x + y) mod 2^w.
-
-        Then 0 <= z < 2^w.  Convert z to a word, Z, and define Z = X +
-        Y.
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                      [Page 5]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-    c.  The right shift operation SHR^n(x), where x is a w-bit word and
-        n is an integer with 0 <= n < w, is defined by
-
-             SHR^n(x) = x>>n
-
-    d.  The rotate right (circular right shift) operation ROTR^n(x),
-        where x is a w-bit word and n is an integer with 0 <= n < w, is
-        defined by
-
-             ROTR^n(x) = (x>>n) OR (x<<(w-n))
-
-    e.  The rotate left (circular left shift) operation ROTL^n(x), where
-        x is a w-bit word and n is an integer with 0 <= n < w, is
-        defined by
-
-             ROTL^n(X)  =  (x<<n) OR (x>>w-n)
-
-        Note the following equivalence relationships, where w is fixed
-        in each relationship:
-
-             ROTL^n(x) = ROTR^(w-x)(x)
-
-             ROTR^n(x) = ROTL^(w-n)(x)
-
-4.  Message Padding and Parsing
-
-   The hash functions specified herein are used to compute a message
-   digest for a message or data file that is provided as input.  The
-   message or data file should be considered to be a bit string.  The
-   length of the message is the number of bits in the message (the empty
-   message has length 0).  If the number of bits in a message is a
-   multiple of 8, for compactness we can represent the message in hex.
-   The purpose of message padding is to make the total length of a
-   padded message a multiple of 512 for SHA-224 and SHA-256 or a
-   multiple of 1024 for SHA-384 and SHA-512.
-
-   The following specifies how this padding shall be performed.  As a
-   summary, a "1" followed by a number of "0"s followed by a 64-bit or
-   128-bit integer are appended to the end of the message to produce a
-   padded message of length 512*n or 1024*n.  The minimum number of "0"s
-   necessary to meet this criterion is used.  The appended integer is
-   the length of the original message.  The padded message is then
-   processed by the hash function as n 512-bit or 1024-bit blocks.
-
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                      [Page 6]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-4.1.  SHA-224 and SHA-256
-
-   Suppose a message has length L < 2^64.  Before it is input to the
-   hash function, the message is padded on the right as follows:
-
-    a.  "1" is appended.  Example: if the original message is
-        "01010000", this is padded to "010100001".
-
-    b.  K "0"s are appended where K is the smallest, non-negative
-        solution to the equation
-
-             L + 1 + K = 448 (mod 512)
-
-    c.  Then append the 64-bit block that is L in binary representation.
-        After appending this block, the length of the message will be a
-        multiple of 512 bits.
-
-        Example:  Suppose the original message is the bit string
-
-             01100001 01100010 01100011 01100100 01100101
-
-        After step (a), this gives
-
-             01100001 01100010 01100011 01100100 01100101 1
-
-        Since L = 40, the number of bits in the above is 41 and K = 407
-        "0"s are appended, making the total now 448.  This gives the
-        following in hex:
-
-             61626364 65800000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000
-
-        The 64-bit representation of L = 40 is hex 00000000 00000028.
-        Hence the final padded message is the following hex:
-
-             61626364 65800000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000028
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                      [Page 7]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-4.2.  SHA-384 and SHA-512
-
-   Suppose a message has length L < 2^128.  Before it is input to the
-   hash function, the message is padded on the right as follows:
-
-    a.  "1" is appended.  Example: if the original message is
-        "01010000", this is padded to "010100001".
-
-    b.  K "0"s are appended where K is the smallest, non-negative
-        solution to the equation
-
-             L + 1 + K = 896 (mod 1024)
-
-    c.  Then append the 128-bit block that is L in binary
-        representation.  After appending this block, the length of the
-        message will be a multiple of 1024 bits.
-
-        Example:  Suppose the original message is the bit string
-
-             01100001 01100010 01100011 01100100 01100101
-
-        After step (a) this gives
-
-             01100001 01100010 01100011 01100100 01100101 1
-
-        Since L = 40, the number of bits in the above is 41 and K = 855
-        "0"s are appended, making the total now 896.  This gives the
-        following in hex:
-
-             61626364 65800000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-
-        The 128-bit representation of L = 40 is hex 00000000 00000000
-        00000000 00000028.  Hence the final padded message is the
-        following hex:
-
-             61626364 65800000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                      [Page 8]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000000
-             00000000 00000000 00000000 00000028
-
-5.  Functions and Constants Used
-
-   The following subsections give the six logical functions and the
-   table of constants used in each of the hash functions.
-
-5.1.  SHA-224 and SHA-256
-
-   SHA-224 and SHA-256 use six logical functions, where each function
-   operates on 32-bit words, which are represented as x, y, and z.  The
-   result of each function is a new 32-bit word.
-
-        CH( x, y, z) = (x AND y) XOR ( (NOT x) AND z)
-
-        MAJ( x, y, z) = (x AND y) XOR (x AND z) XOR (y AND z)
-
-        BSIG0(x) = ROTR^2(x) XOR ROTR^13(x) XOR ROTR^22(x)
-
-        BSIG1(x) = ROTR^6(x) XOR ROTR^11(x) XOR ROTR^25(x)
-
-        SSIG0(x) = ROTR^7(x) XOR ROTR^18(x) XOR SHR^3(x)
-
-        SSIG1(x) = ROTR^17(x) XOR ROTR^19(x) XOR SHR^10(x)
-
-   SHA-224 and SHA-256 use the same sequence of sixty-four constant
-   32-bit words, K0, K1, ..., K63.  These words represent the first
-   thirty-two bits of the fractional parts of the cube roots of the
-   first sixty-four prime numbers.  In hex, these constant words are as
-   follows (from left to right):
-
-        428a2f98 71374491 b5c0fbcf e9b5dba5
-        3956c25b 59f111f1 923f82a4 ab1c5ed5
-        d807aa98 12835b01 243185be 550c7dc3
-        72be5d74 80deb1fe 9bdc06a7 c19bf174
-        e49b69c1 efbe4786 0fc19dc6 240ca1cc
-        2de92c6f 4a7484aa 5cb0a9dc 76f988da
-        983e5152 a831c66d b00327c8 bf597fc7
-        c6e00bf3 d5a79147 06ca6351 14292967
-        27b70a85 2e1b2138 4d2c6dfc 53380d13
-        650a7354 766a0abb 81c2c92e 92722c85
-        a2bfe8a1 a81a664b c24b8b70 c76c51a3
-        d192e819 d6990624 f40e3585 106aa070
-        19a4c116 1e376c08 2748774c 34b0bcb5
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                      [Page 9]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-        391c0cb3 4ed8aa4a 5b9cca4f 682e6ff3
-        748f82ee 78a5636f 84c87814 8cc70208
-        90befffa a4506ceb bef9a3f7 c67178f2
-
-5.2.  SHA-384 and SHA-512
-
-   SHA-384 and SHA-512 each use six logical functions, where each
-   function operates on 64-bit words, which are represented as x, y, and
-   z.  The result of each function is a new 64-bit word.
-
-        CH( x, y, z) = (x AND y) XOR ( (NOT x) AND z)
-
-        MAJ( x, y, z) = (x AND y) XOR (x AND z) XOR (y AND z)
-
-        BSIG0(x) = ROTR^28(x) XOR ROTR^34(x) XOR ROTR^39(x)
-
-        BSIG1(x) = ROTR^14(x) XOR ROTR^18(x) XOR ROTR^41(x)
-
-        SSIG0(x) = ROTR^1(x) XOR ROTR^8(x) XOR SHR^7(x)
-
-        SSIG1(x) = ROTR^19(x) XOR ROTR^61(x) XOR SHR^6(x)
-
-   SHA-384 and SHA-512 use the same sequence of eighty constant 64-bit
-   words, K0, K1, ... K79.  These words represent the first sixty-four
-   bits of the fractional parts of the cube roots of the first eighty
-   prime numbers.  In hex, these constant words are as follows (from
-   left to right):
-
-   428a2f98d728ae22 7137449123ef65cd b5c0fbcfec4d3b2f e9b5dba58189dbbc
-   3956c25bf348b538 59f111f1b605d019 923f82a4af194f9b ab1c5ed5da6d8118
-   d807aa98a3030242 12835b0145706fbe 243185be4ee4b28c 550c7dc3d5ffb4e2
-   72be5d74f27b896f 80deb1fe3b1696b1 9bdc06a725c71235 c19bf174cf692694
-   e49b69c19ef14ad2 efbe4786384f25e3 0fc19dc68b8cd5b5 240ca1cc77ac9c65
-   2de92c6f592b0275 4a7484aa6ea6e483 5cb0a9dcbd41fbd4 76f988da831153b5
-   983e5152ee66dfab a831c66d2db43210 b00327c898fb213f bf597fc7beef0ee4
-   c6e00bf33da88fc2 d5a79147930aa725 06ca6351e003826f 142929670a0e6e70
-   27b70a8546d22ffc 2e1b21385c26c926 4d2c6dfc5ac42aed 53380d139d95b3df
-   650a73548baf63de 766a0abb3c77b2a8 81c2c92e47edaee6 92722c851482353b
-   a2bfe8a14cf10364 a81a664bbc423001 c24b8b70d0f89791 c76c51a30654be30
-   d192e819d6ef5218 d69906245565a910 f40e35855771202a 106aa07032bbd1b8
-   19a4c116b8d2d0c8 1e376c085141ab53 2748774cdf8eeb99 34b0bcb5e19b48a8
-   391c0cb3c5c95a63 4ed8aa4ae3418acb 5b9cca4f7763e373 682e6ff3d6b2b8a3
-   748f82ee5defb2fc 78a5636f43172f60 84c87814a1f0ab72 8cc702081a6439ec
-   90befffa23631e28 a4506cebde82bde9 bef9a3f7b2c67915 c67178f2e372532b
-   ca273eceea26619c d186b8c721c0c207 eada7dd6cde0eb1e f57d4f7fee6ed178
-   06f067aa72176fba 0a637dc5a2c898a6 113f9804bef90dae 1b710b35131c471b
-   28db77f523047d84 32caab7b40c72493 3c9ebe0a15c9bebc 431d67c49c100d4c
-   4cc5d4becb3e42b6 597f299cfc657e2a 5fcb6fab3ad6faec 6c44198c4a475817
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 10]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-6.  Computing the Message Digest
-
-   The output of each of the secure hash functions, after being applied
-   to a message of N blocks, is the hash quantity H(N).  For SHA-224 and
-   SHA-256, H(i) can be considered to be eight 32-bit words, H(i)0,
-   H(i)1, ... H(i)7.  For SHA-384 and SHA-512, it can be considered to
-   be eight 64-bit words, H(i)0, H(i)1, ..., H(i)7.
-
-   As described below, the hash words are initialized, modified as each
-   message block is processed, and finally concatenated after processing
-   the last block to yield the output.  For SHA-256 and SHA-512, all of
-   the H(N) variables are concatenated while the SHA-224 and SHA-384
-   hashes are produced by omitting some from the final concatenation.
-
-6.1.  SHA-224 and SHA-256 Initialization
-
-   For SHA-224, the initial hash value, H(0), consists of the following
-   32-bit words in hex:
-
-        H(0)0 = c1059ed8
-        H(0)1 = 367cd507
-        H(0)2 = 3070dd17
-        H(0)3 = f70e5939
-        H(0)4 = ffc00b31
-        H(0)5 = 68581511
-        H(0)6 = 64f98fa7
-        H(0)7 = befa4fa4
-
-   For SHA-256, the initial hash value, H(0), consists of the following
-   eight 32-bit words, in hex.  These words were obtained by taking the
-   first thirty-two bits of the fractional parts of the square roots of
-   the first eight prime numbers.
-
-        H(0)0 = 6a09e667
-        H(0)1 = bb67ae85
-        H(0)2 = 3c6ef372
-        H(0)3 = a54ff53a
-        H(0)4 = 510e527f
-        H(0)5 = 9b05688c
-        H(0)6 = 1f83d9ab
-        H(0)7 = 5be0cd19
-
-6.2.  SHA-224 and SHA-256 Processing
-
-   SHA-224 and SHA-256 perform identical processing on messages blocks
-   and differ only in how H(0) is initialized and how they produce their
-   final output.  They may be used to hash a message, M, having a length
-   of L bits, where 0 <= L < 2^64.  The algorithm uses (1) a message
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 11]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-   schedule of sixty-four 32-bit words, (2) eight working variables of
-   32 bits each, and (3) a hash value of eight 32-bit words.
-
-   The words of the message schedule are labeled W0, W1, ..., W63.  The
-   eight working variables are labeled a, b, c, d, e, f, g, and h.  The
-   words of the hash value are labeled H(i)0, H(i)1, ..., H(i)7, which
-   will hold the initial hash value, H(0), replaced by each successive
-   intermediate hash value (after each message block is processed),
-   H(i), and ending with the final hash value, H(N), after all N blocks
-   are processed.  They also use two temporary words, T1 and T2.
-
-   The input message is padded as described in Section 4.1 above then
-   parsed into 512-bit blocks, which are considered to be composed of 16
-   32-bit words M(i)0, M(i)1, ..., M(i)15.  The following computations
-   are then performed for each of the N message blocks.  All addition is
-   performed modulo 2^32.
-
-   For i = 1 to N
-
-      1. Prepare the message schedule W:
-         For t = 0 to 15
-            Wt = M(i)t
-         For t = 16 to 63
-            Wt = SSIG1(W(t-2)) + W(t-7) + SSIG0(t-15) + W(t-16)
-
-      2. Initialize the working variables:
-         a = H(i-1)0
-         b = H(i-1)1
-         c = H(i-1)2
-         d = H(i-1)3
-         e = H(i-1)4
-         f = H(i-1)5
-         g = H(i-1)6
-         h = H(i-1)7
-
-      3. Perform the main hash computation:
-         For t = 0 to 63
-            T1 = h + BSIG1(e) + CH(e,f,g) + Kt + Wt
-            T2 = BSIG0(a) + MAJ(a,b,c)
-            h = g
-            g = f
-            f = e
-            e = d + T1
-            d = c
-            c = b
-            b = a
-            a = T1 + T2
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 12]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      4. Compute the intermediate hash value H(i):
-         H(i)0 = a + H(i-1)0
-         H(i)1 = b + H(i-1)1
-         H(i)2 = c + H(i-1)2
-         H(i)3 = d + H(i-1)3
-         H(i)4 = e + H(i-1)4
-         H(i)5 = f + H(i-1)5
-         H(i)6 = g + H(i-1)6
-         H(i)7 = h + H(i-1)7
-
-   After the above computations have been sequentially performed for all
-   of the blocks in the message, the final output is calculated.  For
-   SHA-256, this is the concatenation of all of H(N)0, H(N)1, through
-   H(N)7.  For SHA-224, this is the concatenation of H(N)0, H(N)1,
-   through H(N)6.
-
-6.3.  SHA-384 and SHA-512 Initialization
-
-   For SHA-384, the initial hash value, H(0), consists of the following
-   eight 64-bit words, in hex.  These words were obtained by taking the
-   first sixty-four bits of the fractional parts of the square roots of
-   the ninth through sixteenth prime numbers.
-
-        H(0)0 = cbbb9d5dc1059ed8
-        H(0)1 = 629a292a367cd507
-        H(0)2 = 9159015a3070dd17
-        H(0)3 = 152fecd8f70e5939
-        H(0)4 = 67332667ffc00b31
-        H(0)5 = 8eb44a8768581511
-        H(0)6 = db0c2e0d64f98fa7
-        H(0)7 = 47b5481dbefa4fa4
-
-   For SHA-512, the initial hash value, H(0), consists of the following
-   eight 64-bit words, in hex.  These words were obtained by taking the
-   first sixty-four bits of the fractional parts of the square roots of
-   the first eight prime numbers.
-
-        H(0)0 = 6a09e667f3bcc908
-        H(0)1 = bb67ae8584caa73b
-        H(0)2 = 3c6ef372fe94f82b
-        H(0)3 = a54ff53a5f1d36f1
-        H(0)4 = 510e527fade682d1
-        H(0)5 = 9b05688c2b3e6c1f
-        H(0)6 = 1f83d9abfb41bd6b
-        H(0)7 = 5be0cd19137e2179
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 13]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-6.4.  SHA-384 and SHA-512 Processing
-
-   SHA-384 and SHA-512 perform identical processing on message blocks
-   and differ only in how H(0) is initialized and how they produce their
-   final output.  They may be used to hash a message, M, having a length
-   of L bits, where 0 <= L < 2^128.  The algorithm uses (1) a message
-   schedule of eighty 64-bit words, (2) eight working variables of 64
-   bits each, and (3) a hash value of eight 64-bit words.
-
-   The words of the message schedule are labeled W0, W1, ..., W79.  The
-   eight working variables are labeled a, b, c, d, e, f, g, and h.  The
-   words of the hash value are labeled H(i)0, H(i)1, ..., H(i)7, which
-   will hold the initial hash value, H(0), replaced by each successive
-   intermediate hash value (after each message block is processed),
-   H(i), and ending with the final hash value, H(N) after all N blocks
-   are processed.
-
-   The input message is padded as described in Section 4.2 above, then
-   parsed into 1024-bit blocks, which are considered to be composed of
-   16 64-bit words M(i)0, M(i)1, ..., M(i)15.  The following
-   computations are then performed for each of the N message blocks.
-   All addition is performed modulo 2^64.
-
-   For i = 1 to N
-
-      1. Prepare the message schedule W:
-         For t = 0 to 15
-            Wt = M(i)t
-         For t = 16 to 79
-            Wt = SSIG1(W(t-2)) + W(t-7) + SSIG0(t-15) + W(t-16)
-
-      2. Initialize the working variables:
-         a = H(i-1)0
-         b = H(i-1)1
-         c = H(i-1)2
-         d = H(i-1)3
-         e = H(i-1)4
-         f = H(i-1)5
-         g = H(i-1)6
-         h = H(i-1)7
-
-      3. Perform the main hash computation:
-         For t = 0 to 79
-            T1 = h + BSIG1(e) + CH(e,f,g) + Kt + Wt
-            T2 = BSIG0(a) + MAJ(a,b,c)
-            h = g
-            g = f
-            f = e
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 14]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-            e = d + T1
-            d = c
-            c = b
-            b = a
-            a = T1 + T2
-
-      4. Compute the intermediate hash value H(i):
-         H(i)0 = a + H(i-1)0
-         H(i)1 = b + H(i-1)1
-         H(i)2 = c + H(i-1)2
-         H(i)3 = d + H(i-1)3
-         H(i)4 = e + H(i-1)4
-         H(i)5 = f + H(i-1)5
-         H(i)6 = g + H(i-1)6
-         H(i)7 = h + H(i-1)7
-
-   After the above computations have been sequentially performed for all
-   of the blocks in the message, the final output is calculated.  For
-   SHA-512, this is the concatenation of all of H(N)0, H(N)1, through
-   H(N)7.  For SHA-384, this is the concatenation of H(N)0, H(N)1,
-   through H(N)5.
-
-7.  SHA-Based HMACs
-
-   HMAC is a method for computing a keyed MAC (message authentication
-   code) using a hash function as described in [RFC2104].  It uses a key
-   to mix in with the input text to produce the final hash.
-
-   Sample code is also provided, in Section 8.3 below, to perform HMAC
-   based on any of the SHA algorithms described herein.  The sample code
-   found in [RFC2104] was written in terms of a specified text size.
-   Since SHA is defined in terms of an arbitrary number of bits, the
-   sample HMAC code has been written to allow the text input to HMAC to
-   have an arbitrary number of octets and bits.  A fixed-length
-   interface is also provided.
-
-8.  C Code for SHAs
-
-   Below is a demonstration implementation of these secure hash
-   functions in C.  Section 8.1 contains the header file sha.h, which
-   declares all constants, structures, and functions used by the sha and
-   hmac functions.  Section 8.2 contains the C code for sha1.c,
-   sha224-256.c, sha384-512.c, and usha.c along with sha-private.h,
-   which provides some declarations common to all the sha functions.
-   Section 8.3 contains the C code for the hmac functions.  Section 8.4
-   contains a test driver to exercise the code.
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 15]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-   For each of the digest length $$$, there is the following set of
-   constants, a structure, and functions:
-
-   Constants:
-      SHA$$$HashSize      number of octets in the hash
-      SHA$$$HashSizeBits  number of bits in the hash
-      SHA$$$_Message_Block_Size
-                          number of octets used in the intermediate
-                          message blocks
-      shaSuccess = 0      constant returned by each function on success
-      shaNull = 1         constant returned by each function when
-                          presented with a null pointer parameter
-      shaInputTooLong = 2  constant returned by each function when the
-                          input data is too long
-      shaStateError       constant returned by each function when
-                          SHA$$$Input is called after SHA$$$FinalBits or
-                          SHA$$$Result.
-
-   Structure:
-      typedef SHA$$$Context
-                          an opaque structure holding the complete state
-                          for producing the hash
-
-   Functions:
-                  int SHA$$$Reset(SHA$$$Context *);
-            Reset the hash context state
-      int SHA$$$Input(SHA$$$Context *, const uint8_t *octets,
-                  unsigned int bytecount);
-            Incorporate bytecount octets into the hash.
-      int SHA$$$FinalBits(SHA$$$Context *, const uint8_t octet,
-                  unsigned int bitcount);
-            Incorporate bitcount bits into the hash.  The bits are in
-            the upper portion of the octet.  SHA$$$Input() cannot be
-            called after this.
-      int SHA$$$Result(SHA$$$Context *,
-                  uint8_t Message_Digest[SHA$$$HashSize]);
-            Do the final calculations on the hash and copy the value
-            into Message_Digest.
-
-   In addition, functions with the prefix USHA are provided that take a
-   SHAversion value (SHA$$$) to select the SHA function suite.  They add
-   the following constants, structure, and functions:
-
-   Constants:
-      shaBadParam         constant returned by USHA functions when
-                          presented with a bad SHAversion (SHA$$$)
-                          parameter
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 16]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      SHA$$$              SHAversion enumeration values, used by usha
-                          and hmac functions to select the SHA function
-                          suite
-
-   Structure:
-      typedef USHAContext
-                          an opaque structure holding the complete state
-                          for producing the hash
-
-   Functions:
-      int USHAReset(USHAContext *, SHAversion whichSha);
-            Reset the hash context state.
-      int USHAInput(USHAContext *,
-                  const uint8_t *bytes, unsigned int bytecount);
-            Incorporate bytecount octets into the hash.
-      int USHAFinalBits(USHAContext *,
-                  const uint8_t bits, unsigned int bitcount);
-                  Incorporate bitcount bits into the hash.
-      int USHAResult(USHAContext *,
-                  uint8_t Message_Digest[USHAMaxHashSize]);
-            Do the final calculations on the hash and copy the value
-            into Message_Digest.  Octets in Message_Digest beyond
-      USHAHashSize(whichSha) are left untouched.
-                  int USHAHashSize(enum SHAversion whichSha);
-            The number of octets in the given hash.
-      int USHAHashSizeBits(enum SHAversion whichSha);
-            The number of bits in the given hash.
-      int USHABlockSize(enum SHAversion whichSha);
-            The internal block size for the given hash.
-
-   The hmac functions follow the same pattern to allow any length of
-   text input to be used.
-
-   Structure:
-      typedef HMACContext an opaque structure holding the complete state
-                          for producing the hash
-
-   Functions:
-      int hmacReset(HMACContext *ctx, enum SHAversion whichSha,
-                  const unsigned char *key, int key_len);
-            Reset the hash context state.
-      int hmacInput(HMACContext *ctx, const unsigned char *text,
-                  int text_len);
-            Incorporate text_len octets into the hash.
-      int hmacFinalBits(HMACContext *ctx, const uint8_t bits,
-                  unsigned int bitcount);
-            Incorporate bitcount bits into the hash.
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 17]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      int hmacResult(HMACContext *ctx,
-                  uint8_t Message_Digest[USHAMaxHashSize]);
-            Do the final calculations on the hash and copy the value
-            into Message_Digest.  Octets in Message_Digest beyond
-            USHAHashSize(whichSha) are left untouched.
-
-   In addition, a combined interface is provided, similar to that shown
-   in RFC 2104, that allows a fixed-length text input to be used.
-
-      int hmac(SHAversion whichSha,
-                  const unsigned char *text, int text_len,
-                  const unsigned char *key, int key_len,
-                  uint8_t Message_Digest[USHAMaxHashSize]);
-            Calculate the given digest for the given text and key, and
-            return the resulting hash.  Octets in Message_Digest beyond
-            USHAHashSize(whichSha) are left untouched.
-
-8.1.  The .h File
-
-/**************************** sha.h ****************************/
-/******************* See RFC 4634 for details ******************/
-#ifndef _SHA_H_
-#define _SHA_H_
-
-/*
- *  Description:
- *      This file implements the Secure Hash Signature Standard
- *      algorithms as defined in the National Institute of Standards
- *      and Technology Federal Information Processing Standards
- *      Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2
- *      published on August 1, 2002, and the FIPS PUB 180-2 Change
- *      Notice published on February 28, 2004.
- *
- *      A combined document showing all algorithms is available at
- *              http://csrc.nist.gov/publications/fips/
- *              fips180-2/fips180-2withchangenotice.pdf
- *
- *      The five hashes are defined in these sizes:
- *              SHA-1           20 byte / 160 bit
- *              SHA-224         28 byte / 224 bit
- *              SHA-256         32 byte / 256 bit
- *              SHA-384         48 byte / 384 bit
- *              SHA-512         64 byte / 512 bit
- */
-
-#include <stdint.h>
-/*
- * If you do not have the ISO standard stdint.h header file, then you
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 18]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- * must typedef the following:
- *    name              meaning
- *  uint64_t         unsigned 64 bit integer
- *  uint32_t         unsigned 32 bit integer
- *  uint8_t          unsigned 8 bit integer (i.e., unsigned char)
- *  int_least16_t    integer of >= 16 bits
- *
- */
-
-#ifndef _SHA_enum_
-#define _SHA_enum_
-/*
- *  All SHA functions return one of these values.
- */
-enum {
-    shaSuccess = 0,
-    shaNull,            /* Null pointer parameter */
-    shaInputTooLong,    /* input data too long */
-    shaStateError,      /* called Input after FinalBits or Result */
-    shaBadParam         /* passed a bad parameter */
-};
-#endif /* _SHA_enum_ */
-
-/*
- *  These constants hold size information for each of the SHA
- *  hashing operations
- */
-enum {
-    SHA1_Message_Block_Size = 64, SHA224_Message_Block_Size = 64,
-    SHA256_Message_Block_Size = 64, SHA384_Message_Block_Size = 128,
-    SHA512_Message_Block_Size = 128,
-    USHA_Max_Message_Block_Size = SHA512_Message_Block_Size,
-
-    SHA1HashSize = 20, SHA224HashSize = 28, SHA256HashSize = 32,
-    SHA384HashSize = 48, SHA512HashSize = 64,
-    USHAMaxHashSize = SHA512HashSize,
-
-    SHA1HashSizeBits = 160, SHA224HashSizeBits = 224,
-    SHA256HashSizeBits = 256, SHA384HashSizeBits = 384,
-    SHA512HashSizeBits = 512, USHAMaxHashSizeBits = SHA512HashSizeBits
-};
-
-/*
- *  These constants are used in the USHA (unified sha) functions.
- */
-typedef enum SHAversion {
-    SHA1, SHA224, SHA256, SHA384, SHA512
-} SHAversion;
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 19]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-/*
- *  This structure will hold context information for the SHA-1
- *  hashing operation.
- */
-typedef struct SHA1Context {
-    uint32_t Intermediate_Hash[SHA1HashSize/4]; /* Message Digest */
-
-    uint32_t Length_Low;                /* Message length in bits */
-    uint32_t Length_High;               /* Message length in bits */
-
-    int_least16_t Message_Block_Index;  /* Message_Block array index */
-                                        /* 512-bit message blocks */
-    uint8_t Message_Block[SHA1_Message_Block_Size];
-
-    int Computed;                       /* Is the digest computed? */
-    int Corrupted;                      /* Is the digest corrupted? */
-} SHA1Context;
-
-/*
- *  This structure will hold context information for the SHA-256
- *  hashing operation.
- */
-typedef struct SHA256Context {
-    uint32_t Intermediate_Hash[SHA256HashSize/4]; /* Message Digest */
-
-    uint32_t Length_Low;                /* Message length in bits */
-    uint32_t Length_High;               /* Message length in bits */
-
-    int_least16_t Message_Block_Index;  /* Message_Block array index */
-                                        /* 512-bit message blocks */
-    uint8_t Message_Block[SHA256_Message_Block_Size];
-
-    int Computed;                       /* Is the digest computed? */
-    int Corrupted;                      /* Is the digest corrupted? */
-} SHA256Context;
-
-/*
- *  This structure will hold context information for the SHA-512
- *  hashing operation.
- */
-typedef struct SHA512Context {
-#ifdef USE_32BIT_ONLY
-    uint32_t Intermediate_Hash[SHA512HashSize/4]; /* Message Digest  */
-    uint32_t Length[4];                 /* Message length in bits */
-#else /* !USE_32BIT_ONLY */
-    uint64_t Intermediate_Hash[SHA512HashSize/8]; /* Message Digest */
-    uint64_t Length_Low, Length_High;   /* Message length in bits */
-#endif /* USE_32BIT_ONLY */
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 20]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-    int_least16_t Message_Block_Index;  /* Message_Block array index */
-                                        /* 1024-bit message blocks */
-    uint8_t Message_Block[SHA512_Message_Block_Size];
-
-    int Computed;                       /* Is the digest computed?*/
-    int Corrupted;                      /* Is the digest corrupted? */
-} SHA512Context;
-
-/*
- *  This structure will hold context information for the SHA-224
- *  hashing operation. It uses the SHA-256 structure for computation.
- */
-typedef struct SHA256Context SHA224Context;
-
-/*
- *  This structure will hold context information for the SHA-384
- *  hashing operation. It uses the SHA-512 structure for computation.
- */
-typedef struct SHA512Context SHA384Context;
-
-/*
- *  This structure holds context information for all SHA
- *  hashing operations.
- */
-typedef struct USHAContext {
-    int whichSha;               /* which SHA is being used */
-    union {
-      SHA1Context sha1Context;
-      SHA224Context sha224Context; SHA256Context sha256Context;
-      SHA384Context sha384Context; SHA512Context sha512Context;
-    } ctx;
-} USHAContext;
-
-/*
- *  This structure will hold context information for the HMAC
- *  keyed hashing operation.
- */
-typedef struct HMACContext {
-    int whichSha;               /* which SHA is being used */
-    int hashSize;               /* hash size of SHA being used */
-    int blockSize;              /* block size of SHA being used */
-    USHAContext shaContext;     /* SHA context */
-    unsigned char k_opad[USHA_Max_Message_Block_Size];
-                        /* outer padding - key XORd with opad */
-} HMACContext;
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 21]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-/*
- *  Function Prototypes
- */
-
-/* SHA-1 */
-extern int SHA1Reset(SHA1Context *);
-extern int SHA1Input(SHA1Context *, const uint8_t *bytes,
-                     unsigned int bytecount);
-extern int SHA1FinalBits(SHA1Context *, const uint8_t bits,
-                         unsigned int bitcount);
-extern int SHA1Result(SHA1Context *,
-                      uint8_t Message_Digest[SHA1HashSize]);
-
-/* SHA-224 */
-extern int SHA224Reset(SHA224Context *);
-extern int SHA224Input(SHA224Context *, const uint8_t *bytes,
-                       unsigned int bytecount);
-extern int SHA224FinalBits(SHA224Context *, const uint8_t bits,
-                           unsigned int bitcount);
-extern int SHA224Result(SHA224Context *,
-                        uint8_t Message_Digest[SHA224HashSize]);
-
-/* SHA-256 */
-extern int SHA256Reset(SHA256Context *);
-extern int SHA256Input(SHA256Context *, const uint8_t *bytes,
-                       unsigned int bytecount);
-extern int SHA256FinalBits(SHA256Context *, const uint8_t bits,
-                           unsigned int bitcount);
-extern int SHA256Result(SHA256Context *,
-                        uint8_t Message_Digest[SHA256HashSize]);
-
-/* SHA-384 */
-extern int SHA384Reset(SHA384Context *);
-extern int SHA384Input(SHA384Context *, const uint8_t *bytes,
-                       unsigned int bytecount);
-extern int SHA384FinalBits(SHA384Context *, const uint8_t bits,
-                           unsigned int bitcount);
-extern int SHA384Result(SHA384Context *,
-                        uint8_t Message_Digest[SHA384HashSize]);
-
-/* SHA-512 */
-extern int SHA512Reset(SHA512Context *);
-extern int SHA512Input(SHA512Context *, const uint8_t *bytes,
-                       unsigned int bytecount);
-extern int SHA512FinalBits(SHA512Context *, const uint8_t bits,
-                           unsigned int bitcount);
-extern int SHA512Result(SHA512Context *,
-                        uint8_t Message_Digest[SHA512HashSize]);
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 22]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-/* Unified SHA functions, chosen by whichSha */
-extern int USHAReset(USHAContext *, SHAversion whichSha);
-extern int USHAInput(USHAContext *,
-                     const uint8_t *bytes, unsigned int bytecount);
-extern int USHAFinalBits(USHAContext *,
-                         const uint8_t bits, unsigned int bitcount);
-extern int USHAResult(USHAContext *,
-                      uint8_t Message_Digest[USHAMaxHashSize]);
-extern int USHABlockSize(enum SHAversion whichSha);
-extern int USHAHashSize(enum SHAversion whichSha);
-extern int USHAHashSizeBits(enum SHAversion whichSha);
-
-/*
- * HMAC Keyed-Hashing for Message Authentication, RFC2104,
- * for all SHAs.
- * This interface allows a fixed-length text input to be used.
- */
-extern int hmac(SHAversion whichSha, /* which SHA algorithm to use */
-    const unsigned char *text,     /* pointer to data stream */
-    int text_len,                  /* length of data stream */
-    const unsigned char *key,      /* pointer to authentication key */
-    int key_len,                   /* length of authentication key */
-    uint8_t digest[USHAMaxHashSize]); /* caller digest to fill in */
-
-/*
- * HMAC Keyed-Hashing for Message Authentication, RFC2104,
- * for all SHAs.
- * This interface allows any length of text input to be used.
- */
-extern int hmacReset(HMACContext *ctx, enum SHAversion whichSha,
-                     const unsigned char *key, int key_len);
-extern int hmacInput(HMACContext *ctx, const unsigned char *text,
-                     int text_len);
-
-extern int hmacFinalBits(HMACContext *ctx, const uint8_t bits,
-                         unsigned int bitcount);
-extern int hmacResult(HMACContext *ctx,
-                      uint8_t digest[USHAMaxHashSize]);
-
-#endif /* _SHA_H_ */
-
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 23]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-8.2.  The SHA Code
-
-   This code is primarily intended as expository and could be optimized
-   further.  For example, the assignment rotations through the variables
-   a, b, ..., h could be treated as a cycle and the loop unrolled,
-   rather than doing the explicit copying.
-
-   Note that there are alternative representations of the Ch() and Maj()
-   functions controlled by an ifdef.
-
-8.2.1.  sha1.c
-
-/**************************** sha1.c ****************************/
-/******************** See RFC 4634 for details ******************/
-/*
- *  Description:
- *      This file implements the Secure Hash Signature Standard
- *      algorithms as defined in the National Institute of Standards
- *      and Technology Federal Information Processing Standards
- *      Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2
- *      published on August 1, 2002, and the FIPS PUB 180-2 Change
- *      Notice published on February 28, 2004.
- *
- *      A combined document showing all algorithms is available at
- *              http://csrc.nist.gov/publications/fips/
- *              fips180-2/fips180-2withchangenotice.pdf
- *
- *      The SHA-1 algorithm produces a 160-bit message digest for a
- *      given data stream.  It should take about 2**n steps to find a
- *      message with the same digest as a given message and
- *      2**(n/2) to find any two messages with the same digest,
- *      when n is the digest size in bits.  Therefore, this
- *      algorithm can serve as a means of providing a
- *      "fingerprint" for a message.
- *
- *  Portability Issues:
- *      SHA-1 is defined in terms of 32-bit "words".  This code
- *      uses <stdint.h> (included via "sha.h") to define 32 and 8
- *      bit unsigned integer types.  If your C compiler does not
- *      support 32 bit unsigned integers, this code is not
- *      appropriate.
- *
- *  Caveats:
- *      SHA-1 is designed to work with messages less than 2^64 bits
- *      long. This implementation uses SHA1Input() to hash the bits
- *      that are a multiple of the size of an 8-bit character, and then
- *      uses SHA1FinalBits() to hash the final few bits of the input.
- */
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 24]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-#include "sha.h"
-#include "sha-private.h"
-
-/*
- *  Define the SHA1 circular left shift macro
- */
-#define SHA1_ROTL(bits,word) \
-                (((word) << (bits)) | ((word) >> (32-(bits))))
-
-/*
- * add "length" to the length
- */
-static uint32_t addTemp;
-#define SHA1AddLength(context, length)                     \
-    (addTemp = (context)->Length_Low,                      \
-     (context)->Corrupted =                                \
-        (((context)->Length_Low += (length)) < addTemp) && \
-        (++(context)->Length_High == 0) ? 1 : 0)
-
-/* Local Function Prototypes */
-static void SHA1Finalize(SHA1Context *context, uint8_t Pad_Byte);
-static void SHA1PadMessage(SHA1Context *, uint8_t Pad_Byte);
-static void SHA1ProcessMessageBlock(SHA1Context *);
-
-/*
- *  SHA1Reset
- *
- *  Description:
- *      This function will initialize the SHA1Context in preparation
- *      for computing a new SHA1 message digest.
- *
- *  Parameters:
- *      context: [in/out]
- *          The context to reset.
- *
- *  Returns:
- *      sha Error Code.
- *
- */
-int SHA1Reset(SHA1Context *context)
-{
-    if (!context)
-        return shaNull;
-
-    context->Length_Low             = 0;
-    context->Length_High            = 0;
-    context->Message_Block_Index    = 0;
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 25]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-    /* Initial Hash Values: FIPS-180-2 section 5.3.1 */
-    context->Intermediate_Hash[0]   = 0x67452301;
-    context->Intermediate_Hash[1]   = 0xEFCDAB89;
-    context->Intermediate_Hash[2]   = 0x98BADCFE;
-    context->Intermediate_Hash[3]   = 0x10325476;
-    context->Intermediate_Hash[4]   = 0xC3D2E1F0;
-
-    context->Computed   = 0;
-    context->Corrupted  = 0;
-
-    return shaSuccess;
-}
-
-/*
- *  SHA1Input
- *
- *  Description:
- *      This function accepts an array of octets as the next portion
- *      of the message.
- *
- *  Parameters:
- *      context: [in/out]
- *          The SHA context to update
- *      message_array: [in]
- *          An array of characters representing the next portion of
- *          the message.
- *      length: [in]
- *          The length of the message in message_array
- *
- *  Returns:
- *      sha Error Code.
- *
- */
-int SHA1Input(SHA1Context *context,
-    const uint8_t *message_array, unsigned length)
-{
-  if (!length)
-    return shaSuccess;
-
-  if (!context || !message_array)
-    return shaNull;
-
-  if (context->Computed) {
-    context->Corrupted = shaStateError;
-    return shaStateError;
-  }
-
-  if (context->Corrupted)
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 26]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-     return context->Corrupted;
-
-  while (length-- && !context->Corrupted) {
-    context->Message_Block[context->Message_Block_Index++] =
-      (*message_array & 0xFF);
-
-    if (!SHA1AddLength(context, 8) &&
-      (context->Message_Block_Index == SHA1_Message_Block_Size))
-      SHA1ProcessMessageBlock(context);
-
-    message_array++;
-  }
-
-  return shaSuccess;
-}
-
-/*
- * SHA1FinalBits
- *
- * Description:
- *   This function will add in any final bits of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_bits: [in]
- *     The final bits of the message, in the upper portion of the
- *     byte. (Use 0b###00000 instead of 0b00000### to input the
- *     three bits ###.)
- *   length: [in]
- *     The number of bits in message_bits, between 1 and 7.
- *
- * Returns:
- *   sha Error Code.
- */
-int SHA1FinalBits(SHA1Context *context, const uint8_t message_bits,
-    unsigned int length)
-{
-  uint8_t masks[8] = {
-      /* 0 0b00000000 */ 0x00, /* 1 0b10000000 */ 0x80,
-      /* 2 0b11000000 */ 0xC0, /* 3 0b11100000 */ 0xE0,
-      /* 4 0b11110000 */ 0xF0, /* 5 0b11111000 */ 0xF8,
-      /* 6 0b11111100 */ 0xFC, /* 7 0b11111110 */ 0xFE
-  };
-  uint8_t markbit[8] = {
-      /* 0 0b10000000 */ 0x80, /* 1 0b01000000 */ 0x40,
-      /* 2 0b00100000 */ 0x20, /* 3 0b00010000 */ 0x10,
-      /* 4 0b00001000 */ 0x08, /* 5 0b00000100 */ 0x04,
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 27]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      /* 6 0b00000010 */ 0x02, /* 7 0b00000001 */ 0x01
-  };
-
-  if (!length)
-    return shaSuccess;
-
-  if (!context)
-    return shaNull;
-
-  if (context->Computed || (length >= 8) || (length == 0)) {
-    context->Corrupted = shaStateError;
-    return shaStateError;
-  }
-
-  if (context->Corrupted)
-     return context->Corrupted;
-
-  SHA1AddLength(context, length);
-  SHA1Finalize(context,
-    (uint8_t) ((message_bits & masks[length]) | markbit[length]));
-
-  return shaSuccess;
-}
-
-/*
- * SHA1Result
- *
- * Description:
- *   This function will return the 160-bit message digest into the
- *   Message_Digest array provided by the caller.
- *   NOTE: The first octet of hash is stored in the 0th element,
- *      the last octet of hash in the 19th element.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to use to calculate the SHA-1 hash.
- *   Message_Digest: [out]
- *     Where the digest is returned.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-int SHA1Result(SHA1Context *context,
-    uint8_t Message_Digest[SHA1HashSize])
-{
-  int i;
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 28]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  if (!context || !Message_Digest)
-    return shaNull;
-
-  if (context->Corrupted)
-    return context->Corrupted;
-
-  if (!context->Computed)
-    SHA1Finalize(context, 0x80);
-
-  for (i = 0; i < SHA1HashSize; ++i)
-    Message_Digest[i] = (uint8_t) (context->Intermediate_Hash[i>>2]
-              >> 8 * ( 3 - ( i & 0x03 ) ));
-
-  return shaSuccess;
-}
-
-/*
- * SHA1Finalize
- *
- * Description:
- *   This helper function finishes off the digest calculations.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   Pad_Byte: [in]
- *     The last byte to add to the digest before the 0-padding
- *     and length. This will contain the last bits of the message
- *     followed by another single bit. If the message was an
- *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-static void SHA1Finalize(SHA1Context *context, uint8_t Pad_Byte)
-{
-  int i;
-  SHA1PadMessage(context, Pad_Byte);
-  /* message may be sensitive, clear it out */
-  for (i = 0; i < SHA1_Message_Block_Size; ++i)
-    context->Message_Block[i] = 0;
-  context->Length_Low = 0;  /* and clear length */
-  context->Length_High = 0;
-  context->Computed = 1;
-}
-
-/*
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 29]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- * SHA1PadMessage
- *
- * Description:
- *   According to the standard, the message must be padded to an
- *   even 512 bits. The first padding bit must be a '1'. The last
- *   64 bits represent the length of the original message. All bits
- *   in between should be 0. This helper function will pad the
- *   message according to those rules by filling the Message_Block
- *   array accordingly. When it returns, it can be assumed that the
- *   message digest has been computed.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to pad
- *   Pad_Byte: [in]
- *     The last byte to add to the digest before the 0-padding
- *     and length. This will contain the last bits of the message
- *     followed by another single bit. If the message was an
- *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
- *
- * Returns:
- *   Nothing.
- */
-static void SHA1PadMessage(SHA1Context *context, uint8_t Pad_Byte)
-{
-  /*
-   * Check to see if the current message block is too small to hold
-   * the initial padding bits and length. If so, we will pad the
-   * block, process it, and then continue padding into a second
-   * block.
-   */
-  if (context->Message_Block_Index >= (SHA1_Message_Block_Size - 8)) {
-    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
-    while (context->Message_Block_Index < SHA1_Message_Block_Size)
-      context->Message_Block[context->Message_Block_Index++] = 0;
-
-    SHA1ProcessMessageBlock(context);
-  } else
-    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
-
-  while (context->Message_Block_Index < (SHA1_Message_Block_Size - 8))
-    context->Message_Block[context->Message_Block_Index++] = 0;
-
-  /*
-   * Store the message length as the last 8 octets
-   */
-  context->Message_Block[56] = (uint8_t) (context->Length_High >> 24);
-  context->Message_Block[57] = (uint8_t) (context->Length_High >> 16);
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 30]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  context->Message_Block[58] = (uint8_t) (context->Length_High >> 8);
-  context->Message_Block[59] = (uint8_t) (context->Length_High);
-  context->Message_Block[60] = (uint8_t) (context->Length_Low >> 24);
-  context->Message_Block[61] = (uint8_t) (context->Length_Low >> 16);
-  context->Message_Block[62] = (uint8_t) (context->Length_Low >> 8);
-  context->Message_Block[63] = (uint8_t) (context->Length_Low);
-
-  SHA1ProcessMessageBlock(context);
-}
-
-/*
- * SHA1ProcessMessageBlock
- *
- * Description:
- *   This helper function will process the next 512 bits of the
- *   message stored in the Message_Block array.
- *
- * Parameters:
- *   None.
- *
- * Returns:
- *   Nothing.
- *
- * Comments:
- *   Many of the variable names in this code, especially the
- *   single character names, were used because those were the
- *   names used in the publication.
- */
-static void SHA1ProcessMessageBlock(SHA1Context *context)
-{
-  /* Constants defined in FIPS-180-2, section 4.2.1 */
-  const uint32_t K[4] = {
-      0x5A827999, 0x6ED9EBA1, 0x8F1BBCDC, 0xCA62C1D6
-  };
-  int        t;               /* Loop counter */
-  uint32_t   temp;            /* Temporary word value */
-  uint32_t   W[80];           /* Word sequence */
-  uint32_t   A, B, C, D, E;   /* Word buffers */
-
-  /*
-   * Initialize the first 16 words in the array W
-   */
-  for (t = 0; t < 16; t++) {
-    W[t]  = ((uint32_t)context->Message_Block[t * 4]) << 24;
-    W[t] |= ((uint32_t)context->Message_Block[t * 4 + 1]) << 16;
-    W[t] |= ((uint32_t)context->Message_Block[t * 4 + 2]) << 8;
-    W[t] |= ((uint32_t)context->Message_Block[t * 4 + 3]);
-  }
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 31]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  for (t = 16; t < 80; t++)
-    W[t] = SHA1_ROTL(1, W[t-3] ^ W[t-8] ^ W[t-14] ^ W[t-16]);
-
-  A = context->Intermediate_Hash[0];
-  B = context->Intermediate_Hash[1];
-  C = context->Intermediate_Hash[2];
-  D = context->Intermediate_Hash[3];
-  E = context->Intermediate_Hash[4];
-
-  for (t = 0; t < 20; t++) {
-    temp = SHA1_ROTL(5,A) + SHA_Ch(B, C, D) + E + W[t] + K[0];
-    E = D;
-    D = C;
-    C = SHA1_ROTL(30,B);
-    B = A;
-    A = temp;
-  }
-
-  for (t = 20; t < 40; t++) {
-    temp = SHA1_ROTL(5,A) + SHA_Parity(B, C, D) + E + W[t] + K[1];
-    E = D;
-    D = C;
-    C = SHA1_ROTL(30,B);
-    B = A;
-    A = temp;
-  }
-
-  for (t = 40; t < 60; t++) {
-    temp = SHA1_ROTL(5,A) + SHA_Maj(B, C, D) + E + W[t] + K[2];
-    E = D;
-    D = C;
-    C = SHA1_ROTL(30,B);
-    B = A;
-    A = temp;
-  }
-
-  for (t = 60; t < 80; t++) {
-    temp = SHA1_ROTL(5,A) + SHA_Parity(B, C, D) + E + W[t] + K[3];
-    E = D;
-    D = C;
-    C = SHA1_ROTL(30,B);
-    B = A;
-    A = temp;
-  }
-
-  context->Intermediate_Hash[0] += A;
-  context->Intermediate_Hash[1] += B;
-  context->Intermediate_Hash[2] += C;
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 32]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  context->Intermediate_Hash[3] += D;
-  context->Intermediate_Hash[4] += E;
-
-  context->Message_Block_Index = 0;
-}
-
-8.2.2.  sha224-256.c
-
-/*************************** sha224-256.c ***************************/
-/********************* See RFC 4634 for details *********************/
-/*
- * Description:
- *   This file implements the Secure Hash Signature Standard
- *   algorithms as defined in the National Institute of Standards
- *   and Technology Federal Information Processing Standards
- *   Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2
- *   published on August 1, 2002, and the FIPS PUB 180-2 Change
- *   Notice published on February 28, 2004.
- *
- *   A combined document showing all algorithms is available at
- *       http://csrc.nist.gov/publications/fips/
- *       fips180-2/fips180-2withchangenotice.pdf
- *
- *   The SHA-224 and SHA-256 algorithms produce 224-bit and 256-bit
- *   message digests for a given data stream. It should take about
- *   2**n steps to find a message with the same digest as a given
- *   message and 2**(n/2) to find any two messages with the same
- *   digest, when n is the digest size in bits. Therefore, this
- *   algorithm can serve as a means of providing a
- *   "fingerprint" for a message.
- *
- * Portability Issues:
- *   SHA-224 and SHA-256 are defined in terms of 32-bit "words".
- *   This code uses <stdint.h> (included via "sha.h") to define 32
- *   and 8 bit unsigned integer types. If your C compiler does not
- *   support 32 bit unsigned integers, this code is not
- *   appropriate.
- *
- * Caveats:
- *   SHA-224 and SHA-256 are designed to work with messages less
- *   than 2^64 bits long. This implementation uses SHA224/256Input()
- *   to hash the bits that are a multiple of the size of an 8-bit
- *   character, and then uses SHA224/256FinalBits() to hash the
- *   final few bits of the input.
- */
-
-#include "sha.h"
-#include "sha-private.h"
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 33]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-/* Define the SHA shift, rotate left and rotate right macro */
-#define SHA256_SHR(bits,word)      ((word) >> (bits))
-#define SHA256_ROTL(bits,word)                         \
-  (((word) << (bits)) | ((word) >> (32-(bits))))
-#define SHA256_ROTR(bits,word)                         \
-  (((word) >> (bits)) | ((word) << (32-(bits))))
-
-/* Define the SHA SIGMA and sigma macros */
-#define SHA256_SIGMA0(word)   \
-  (SHA256_ROTR( 2,word) ^ SHA256_ROTR(13,word) ^ SHA256_ROTR(22,word))
-#define SHA256_SIGMA1(word)   \
-  (SHA256_ROTR( 6,word) ^ SHA256_ROTR(11,word) ^ SHA256_ROTR(25,word))
-#define SHA256_sigma0(word)   \
-  (SHA256_ROTR( 7,word) ^ SHA256_ROTR(18,word) ^ SHA256_SHR( 3,word))
-#define SHA256_sigma1(word)   \
-  (SHA256_ROTR(17,word) ^ SHA256_ROTR(19,word) ^ SHA256_SHR(10,word))
-
-/*
- * add "length" to the length
- */
-static uint32_t addTemp;
-#define SHA224_256AddLength(context, length)               \
-  (addTemp = (context)->Length_Low, (context)->Corrupted = \
-    (((context)->Length_Low += (length)) < addTemp) &&     \
-    (++(context)->Length_High == 0) ? 1 : 0)
-
-/* Local Function Prototypes */
-static void SHA224_256Finalize(SHA256Context *context,
-  uint8_t Pad_Byte);
-static void SHA224_256PadMessage(SHA256Context *context,
-  uint8_t Pad_Byte);
-static void SHA224_256ProcessMessageBlock(SHA256Context *context);
-static int SHA224_256Reset(SHA256Context *context, uint32_t *H0);
-static int SHA224_256ResultN(SHA256Context *context,
-  uint8_t Message_Digest[], int HashSize);
-
-/* Initial Hash Values: FIPS-180-2 Change Notice 1 */
-static uint32_t SHA224_H0[SHA256HashSize/4] = {
-    0xC1059ED8, 0x367CD507, 0x3070DD17, 0xF70E5939,
-    0xFFC00B31, 0x68581511, 0x64F98FA7, 0xBEFA4FA4
-};
-
-/* Initial Hash Values: FIPS-180-2 section 5.3.2 */
-static uint32_t SHA256_H0[SHA256HashSize/4] = {
-  0x6A09E667, 0xBB67AE85, 0x3C6EF372, 0xA54FF53A,
-  0x510E527F, 0x9B05688C, 0x1F83D9AB, 0x5BE0CD19
-};
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 34]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-/*
- * SHA224Reset
- *
- * Description:
- *   This function will initialize the SHA384Context in preparation
- *   for computing a new SHA224 message digest.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to reset.
- *
- * Returns:
- *   sha Error Code.
- */
-int SHA224Reset(SHA224Context *context)
-{
-  return SHA224_256Reset(context, SHA224_H0);
-}
-
-/*
- * SHA224Input
- *
- * Description:
- *   This function accepts an array of octets as the next portion
- *   of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_array: [in]
- *     An array of characters representing the next portion of
- *     the message.
- *   length: [in]
- *     The length of the message in message_array
- *
- * Returns:
- *   sha Error Code.
- *
- */
-int SHA224Input(SHA224Context *context, const uint8_t *message_array,
-    unsigned int length)
-{
-  return SHA256Input(context, message_array, length);
-}
-
-/*
- * SHA224FinalBits
- *
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 35]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- * Description:
- *   This function will add in any final bits of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_bits: [in]
- *     The final bits of the message, in the upper portion of the
- *     byte. (Use 0b###00000 instead of 0b00000### to input the
- *     three bits ###.)
- *   length: [in]
- *     The number of bits in message_bits, between 1 and 7.
- *
- * Returns:
- *   sha Error Code.
- */
-int SHA224FinalBits( SHA224Context *context,
-    const uint8_t message_bits, unsigned int length)
-{
-  return SHA256FinalBits(context, message_bits, length);
-}
-
-/*
- * SHA224Result
- *
- * Description:
- *   This function will return the 224-bit message
- *   digest into the Message_Digest array provided by the caller.
- *   NOTE: The first octet of hash is stored in the 0th element,
- *      the last octet of hash in the 28th element.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to use to calculate the SHA hash.
- *   Message_Digest: [out]
- *     Where the digest is returned.
- *
- * Returns:
- *   sha Error Code.
- */
-int SHA224Result(SHA224Context *context,
-    uint8_t Message_Digest[SHA224HashSize])
-{
-  return SHA224_256ResultN(context, Message_Digest, SHA224HashSize);
-}
-
-/*
- * SHA256Reset
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 36]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *
- * Description:
- *   This function will initialize the SHA256Context in preparation
- *   for computing a new SHA256 message digest.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to reset.
- *
- * Returns:
- *   sha Error Code.
- */
-int SHA256Reset(SHA256Context *context)
-{
-  return SHA224_256Reset(context, SHA256_H0);
-}
-
-/*
- * SHA256Input
- *
- * Description:
- *   This function accepts an array of octets as the next portion
- *   of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_array: [in]
- *     An array of characters representing the next portion of
- *     the message.
- *   length: [in]
- *     The length of the message in message_array
- *
- * Returns:
- *   sha Error Code.
- */
-int SHA256Input(SHA256Context *context, const uint8_t *message_array,
-    unsigned int length)
-{
-  if (!length)
-    return shaSuccess;
-
-  if (!context || !message_array)
-    return shaNull;
-
-  if (context->Computed) {
-    context->Corrupted = shaStateError;
-    return shaStateError;
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 37]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  }
-
-  if (context->Corrupted)
-     return context->Corrupted;
-
-  while (length-- && !context->Corrupted) {
-    context->Message_Block[context->Message_Block_Index++] =
-            (*message_array & 0xFF);
-
-    if (!SHA224_256AddLength(context, 8) &&
-      (context->Message_Block_Index == SHA256_Message_Block_Size))
-      SHA224_256ProcessMessageBlock(context);
-
-    message_array++;
-  }
-
-  return shaSuccess;
-
-}
-
-/*
- * SHA256FinalBits
- *
- * Description:
- *   This function will add in any final bits of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_bits: [in]
- *     The final bits of the message, in the upper portion of the
- *     byte. (Use 0b###00000 instead of 0b00000### to input the
- *     three bits ###.)
- *   length: [in]
- *     The number of bits in message_bits, between 1 and 7.
- *
- * Returns:
- *   sha Error Code.
- */
-int SHA256FinalBits(SHA256Context *context,
-    const uint8_t message_bits, unsigned int length)
-{
-  uint8_t masks[8] = {
-      /* 0 0b00000000 */ 0x00, /* 1 0b10000000 */ 0x80,
-      /* 2 0b11000000 */ 0xC0, /* 3 0b11100000 */ 0xE0,
-      /* 4 0b11110000 */ 0xF0, /* 5 0b11111000 */ 0xF8,
-      /* 6 0b11111100 */ 0xFC, /* 7 0b11111110 */ 0xFE
-  };
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 38]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  uint8_t markbit[8] = {
-      /* 0 0b10000000 */ 0x80, /* 1 0b01000000 */ 0x40,
-      /* 2 0b00100000 */ 0x20, /* 3 0b00010000 */ 0x10,
-      /* 4 0b00001000 */ 0x08, /* 5 0b00000100 */ 0x04,
-      /* 6 0b00000010 */ 0x02, /* 7 0b00000001 */ 0x01
-  };
-
-  if (!length)
-    return shaSuccess;
-
-  if (!context)
-    return shaNull;
-
-  if ((context->Computed) || (length >= 8) || (length == 0)) {
-    context->Corrupted = shaStateError;
-    return shaStateError;
-  }
-
-  if (context->Corrupted)
-    return context->Corrupted;
-
-  SHA224_256AddLength(context, length);
-  SHA224_256Finalize(context, (uint8_t)
-    ((message_bits & masks[length]) | markbit[length]));
-
-  return shaSuccess;
-}
-
-/*
- * SHA256Result
- *
- * Description:
- *   This function will return the 256-bit message
- *   digest into the Message_Digest array provided by the caller.
- *   NOTE: The first octet of hash is stored in the 0th element,
- *      the last octet of hash in the 32nd element.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to use to calculate the SHA hash.
- *   Message_Digest: [out]
- *     Where the digest is returned.
- *
- * Returns:
- *   sha Error Code.
- */
-int SHA256Result(SHA256Context *context, uint8_t Message_Digest[])
-{
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 39]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  return SHA224_256ResultN(context, Message_Digest, SHA256HashSize);
-}
-
-/*
- * SHA224_256Finalize
- *
- * Description:
- *   This helper function finishes off the digest calculations.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   Pad_Byte: [in]
- *     The last byte to add to the digest before the 0-padding
- *     and length. This will contain the last bits of the message
- *     followed by another single bit. If the message was an
- *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
- *
- * Returns:
- *   sha Error Code.
- */
-static void SHA224_256Finalize(SHA256Context *context,
-    uint8_t Pad_Byte)
-{
-  int i;
-  SHA224_256PadMessage(context, Pad_Byte);
-  /* message may be sensitive, so clear it out */
-  for (i = 0; i < SHA256_Message_Block_Size; ++i)
-    context->Message_Block[i] = 0;
-  context->Length_Low = 0;  /* and clear length */
-  context->Length_High = 0;
-  context->Computed = 1;
-}
-
-/*
- * SHA224_256PadMessage
- *
- * Description:
- *   According to the standard, the message must be padded to an
- *   even 512 bits. The first padding bit must be a '1'. The
- *   last 64 bits represent the length of the original message.
- *   All bits in between should be 0. This helper function will pad
- *   the message according to those rules by filling the
- *   Message_Block array accordingly. When it returns, it can be
- *   assumed that the message digest has been computed.
- *
- * Parameters:
- *   context: [in/out]
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 40]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *     The context to pad
- *   Pad_Byte: [in]
- *     The last byte to add to the digest before the 0-padding
- *     and length. This will contain the last bits of the message
- *     followed by another single bit. If the message was an
- *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
- *
- * Returns:
- *   Nothing.
- */
-static void SHA224_256PadMessage(SHA256Context *context,
-    uint8_t Pad_Byte)
-{
-  /*
-   * Check to see if the current message block is too small to hold
-   * the initial padding bits and length. If so, we will pad the
-   * block, process it, and then continue padding into a second
-   * block.
-   */
-  if (context->Message_Block_Index >= (SHA256_Message_Block_Size-8)) {
-    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
-    while (context->Message_Block_Index < SHA256_Message_Block_Size)
-      context->Message_Block[context->Message_Block_Index++] = 0;
-    SHA224_256ProcessMessageBlock(context);
-  } else
-    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
-
-  while (context->Message_Block_Index < (SHA256_Message_Block_Size-8))
-    context->Message_Block[context->Message_Block_Index++] = 0;
-
-  /*
-   * Store the message length as the last 8 octets
-   */
-  context->Message_Block[56] = (uint8_t)(context->Length_High >> 24);
-  context->Message_Block[57] = (uint8_t)(context->Length_High >> 16);
-  context->Message_Block[58] = (uint8_t)(context->Length_High >> 8);
-  context->Message_Block[59] = (uint8_t)(context->Length_High);
-  context->Message_Block[60] = (uint8_t)(context->Length_Low >> 24);
-  context->Message_Block[61] = (uint8_t)(context->Length_Low >> 16);
-  context->Message_Block[62] = (uint8_t)(context->Length_Low >> 8);
-  context->Message_Block[63] = (uint8_t)(context->Length_Low);
-
-  SHA224_256ProcessMessageBlock(context);
-}
-
-/*
- * SHA224_256ProcessMessageBlock
- *
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 41]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- * Description:
- *   This function will process the next 512 bits of the message
- *   stored in the Message_Block array.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *
- * Returns:
- *   Nothing.
- *
- * Comments:
- *   Many of the variable names in this code, especially the
- *   single character names, were used because those were the
- *   names used in the publication.
- */
-static void SHA224_256ProcessMessageBlock(SHA256Context *context)
-{
-  /* Constants defined in FIPS-180-2, section 4.2.2 */
-  static const uint32_t K[64] = {
-      0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5, 0x3956c25b,
-      0x59f111f1, 0x923f82a4, 0xab1c5ed5, 0xd807aa98, 0x12835b01,
-      0x243185be, 0x550c7dc3, 0x72be5d74, 0x80deb1fe, 0x9bdc06a7,
-      0xc19bf174, 0xe49b69c1, 0xefbe4786, 0x0fc19dc6, 0x240ca1cc,
-      0x2de92c6f, 0x4a7484aa, 0x5cb0a9dc, 0x76f988da, 0x983e5152,
-      0xa831c66d, 0xb00327c8, 0xbf597fc7, 0xc6e00bf3, 0xd5a79147,
-      0x06ca6351, 0x14292967, 0x27b70a85, 0x2e1b2138, 0x4d2c6dfc,
-      0x53380d13, 0x650a7354, 0x766a0abb, 0x81c2c92e, 0x92722c85,
-      0xa2bfe8a1, 0xa81a664b, 0xc24b8b70, 0xc76c51a3, 0xd192e819,
-      0xd6990624, 0xf40e3585, 0x106aa070, 0x19a4c116, 0x1e376c08,
-      0x2748774c, 0x34b0bcb5, 0x391c0cb3, 0x4ed8aa4a, 0x5b9cca4f,
-      0x682e6ff3, 0x748f82ee, 0x78a5636f, 0x84c87814, 0x8cc70208,
-      0x90befffa, 0xa4506ceb, 0xbef9a3f7, 0xc67178f2
-  };
-  int        t, t4;                   /* Loop counter */
-  uint32_t   temp1, temp2;            /* Temporary word value */
-  uint32_t   W[64];                   /* Word sequence */
-  uint32_t   A, B, C, D, E, F, G, H;  /* Word buffers */
-
-  /*
-   * Initialize the first 16 words in the array W
-   */
-  for (t = t4 = 0; t < 16; t++, t4 += 4)
-    W[t] = (((uint32_t)context->Message_Block[t4]) << 24) |
-           (((uint32_t)context->Message_Block[t4 + 1]) << 16) |
-           (((uint32_t)context->Message_Block[t4 + 2]) << 8) |
-           (((uint32_t)context->Message_Block[t4 + 3]));
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 42]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  for (t = 16; t < 64; t++)
-    W[t] = SHA256_sigma1(W[t-2]) + W[t-7] +
-        SHA256_sigma0(W[t-15]) + W[t-16];
-
-  A = context->Intermediate_Hash[0];
-  B = context->Intermediate_Hash[1];
-  C = context->Intermediate_Hash[2];
-  D = context->Intermediate_Hash[3];
-  E = context->Intermediate_Hash[4];
-  F = context->Intermediate_Hash[5];
-  G = context->Intermediate_Hash[6];
-  H = context->Intermediate_Hash[7];
-
-  for (t = 0; t < 64; t++) {
-    temp1 = H + SHA256_SIGMA1(E) + SHA_Ch(E,F,G) + K[t] + W[t];
-    temp2 = SHA256_SIGMA0(A) + SHA_Maj(A,B,C);
-    H = G;
-    G = F;
-    F = E;
-    E = D + temp1;
-    D = C;
-    C = B;
-    B = A;
-    A = temp1 + temp2;
-  }
-
-  context->Intermediate_Hash[0] += A;
-  context->Intermediate_Hash[1] += B;
-  context->Intermediate_Hash[2] += C;
-  context->Intermediate_Hash[3] += D;
-  context->Intermediate_Hash[4] += E;
-  context->Intermediate_Hash[5] += F;
-  context->Intermediate_Hash[6] += G;
-  context->Intermediate_Hash[7] += H;
-
-  context->Message_Block_Index = 0;
-}
-
-/*
- * SHA224_256Reset
- *
- * Description:
- *   This helper function will initialize the SHA256Context in
- *   preparation for computing a new SHA256 message digest.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to reset.
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 43]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *   H0
- *     The initial hash value to use.
- *
- * Returns:
- *   sha Error Code.
- */
-static int SHA224_256Reset(SHA256Context *context, uint32_t *H0)
-{
-  if (!context)
-    return shaNull;
-
-  context->Length_Low           = 0;
-  context->Length_High          = 0;
-  context->Message_Block_Index  = 0;
-
-  context->Intermediate_Hash[0] = H0[0];
-  context->Intermediate_Hash[1] = H0[1];
-  context->Intermediate_Hash[2] = H0[2];
-  context->Intermediate_Hash[3] = H0[3];
-  context->Intermediate_Hash[4] = H0[4];
-  context->Intermediate_Hash[5] = H0[5];
-  context->Intermediate_Hash[6] = H0[6];
-  context->Intermediate_Hash[7] = H0[7];
-
-  context->Computed  = 0;
-  context->Corrupted = 0;
-
-  return shaSuccess;
-}
-
-/*
- * SHA224_256ResultN
- *
- * Description:
- *   This helper function will return the 224-bit or 256-bit message
- *   digest into the Message_Digest array provided by the caller.
- *   NOTE: The first octet of hash is stored in the 0th element,
- *      the last octet of hash in the 28th/32nd element.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to use to calculate the SHA hash.
- *   Message_Digest: [out]
- *     Where the digest is returned.
- *   HashSize: [in]
- *     The size of the hash, either 28 or 32.
- *
- * Returns:
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 44]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *   sha Error Code.
- */
-static int SHA224_256ResultN(SHA256Context *context,
-    uint8_t Message_Digest[], int HashSize)
-{
-  int i;
-
-  if (!context || !Message_Digest)
-    return shaNull;
-
-  if (context->Corrupted)
-    return context->Corrupted;
-
-  if (!context->Computed)
-    SHA224_256Finalize(context, 0x80);
-
-  for (i = 0; i < HashSize; ++i)
-    Message_Digest[i] = (uint8_t)
-      (context->Intermediate_Hash[i>>2] >> 8 * ( 3 - ( i & 0x03 ) ));
-
-  return shaSuccess;
-}
-
-8.2.3.  sha384-512.c
-
-/*************************** sha384-512.c ***************************/
-/********************* See RFC 4634 for details *********************/
-/*
- * Description:
- *   This file implements the Secure Hash Signature Standard
- *   algorithms as defined in the National Institute of Standards
- *   and Technology Federal Information Processing Standards
- *   Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2
- *   published on August 1, 2002, and the FIPS PUB 180-2 Change
- *   Notice published on February 28, 2004.
- *
- *   A combined document showing all algorithms is available at
- *       http://csrc.nist.gov/publications/fips/
- *       fips180-2/fips180-2withchangenotice.pdf
- *
- *   The SHA-384 and SHA-512 algorithms produce 384-bit and 512-bit
- *   message digests for a given data stream. It should take about
- *   2**n steps to find a message with the same digest as a given
- *   message and 2**(n/2) to find any two messages with the same
- *   digest, when n is the digest size in bits. Therefore, this
- *   algorithm can serve as a means of providing a
- *   "fingerprint" for a message.
- *
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 45]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- * Portability Issues:
- *   SHA-384 and SHA-512 are defined in terms of 64-bit "words",
- *   but if USE_32BIT_ONLY is #defined, this code is implemented in
- *   terms of 32-bit "words". This code uses <stdint.h> (included
- *   via "sha.h") to define the 64, 32 and 8 bit unsigned integer
- *   types. If your C compiler does not support 64 bit unsigned
- *   integers, and you do not #define USE_32BIT_ONLY, this code is
- *   not appropriate.
- *
- * Caveats:
- *   SHA-384 and SHA-512 are designed to work with messages less
- *   than 2^128 bits long. This implementation uses
- *   SHA384/512Input() to hash the bits that are a multiple of the
- *   size of an 8-bit character, and then uses SHA384/256FinalBits()
- *   to hash the final few bits of the input.
- *
- */
-
-#include "sha.h"
-#include "sha-private.h"
-
-#ifdef USE_32BIT_ONLY
-/*
- * Define 64-bit arithmetic in terms of 32-bit arithmetic.
- * Each 64-bit number is represented in a 2-word array.
- * All macros are defined such that the result is the last parameter.
- */
-
-/*
- * Define shift, rotate left and rotate right functions
- */
-#define SHA512_SHR(bits, word, ret) (                          \
-    /* (((uint64_t)((word))) >> (bits)) */                     \
-    (ret)[0] = (((bits) < 32) && ((bits) >= 0)) ?              \
-      ((word)[0] >> (bits)) : 0,                               \
-    (ret)[1] = ((bits) > 32) ? ((word)[0] >> ((bits) - 32)) :  \
-      ((bits) == 32) ? (word)[0] :                             \
-      ((bits) >= 0) ?                                          \
-        (((word)[0] << (32 - (bits))) |                        \
-        ((word)[1] >> (bits))) : 0 )
-
-#define SHA512_SHL(bits, word, ret) (                          \
-    /* (((uint64_t)(word)) << (bits)) */                       \
-    (ret)[0] = ((bits) > 32) ? ((word)[1] << ((bits) - 32)) :  \
-         ((bits) == 32) ? (word)[1] :                          \
-         ((bits) >= 0) ?                                       \
-           (((word)[0] << (bits)) |                            \
-           ((word)[1] >> (32 - (bits)))) :                     \
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 46]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-         0,                                                    \
-    (ret)[1] = (((bits) < 32) && ((bits) >= 0)) ?              \
-        ((word)[1] << (bits)) : 0 )
-
-/*
- * Define 64-bit OR
- */
-#define SHA512_OR(word1, word2, ret) (                         \
-    (ret)[0] = (word1)[0] | (word2)[0],                        \
-    (ret)[1] = (word1)[1] | (word2)[1] )
-
-/*
- * Define 64-bit XOR
- */
-#define SHA512_XOR(word1, word2, ret) (                        \
-    (ret)[0] = (word1)[0] ^ (word2)[0],                        \
-    (ret)[1] = (word1)[1] ^ (word2)[1] )
-
-/*
- * Define 64-bit AND
- */
-#define SHA512_AND(word1, word2, ret) (                        \
-    (ret)[0] = (word1)[0] & (word2)[0],                        \
-    (ret)[1] = (word1)[1] & (word2)[1] )
-
-/*
- * Define 64-bit TILDA
- */
-#define SHA512_TILDA(word, ret)                                \
-  ( (ret)[0] = ~(word)[0], (ret)[1] = ~(word)[1] )
-
-/*
- * Define 64-bit ADD
- */
-#define SHA512_ADD(word1, word2, ret) (                        \
-    (ret)[1] = (word1)[1], (ret)[1] += (word2)[1],             \
-    (ret)[0] = (word1)[0] + (word2)[0] + ((ret)[1] < (word1)[1]) )
-
-/*
- * Add the 4word value in word2 to word1.
- */
-static uint32_t ADDTO4_temp, ADDTO4_temp2;
-#define SHA512_ADDTO4(word1, word2) (                          \
-    ADDTO4_temp = (word1)[3],                                  \
-    (word1)[3] += (word2)[3],                                  \
-    ADDTO4_temp2 = (word1)[2],                                 \
-    (word1)[2] += (word2)[2] + ((word1)[3] < ADDTO4_temp),     \
-    ADDTO4_temp = (word1)[1],                                  \
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 47]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-    (word1)[1] += (word2)[1] + ((word1)[2] < ADDTO4_temp2),    \
-    (word1)[0] += (word2)[0] + ((word1)[1] < ADDTO4_temp) )
-
-/*
- * Add the 2word value in word2 to word1.
- */
-static uint32_t ADDTO2_temp;
-#define SHA512_ADDTO2(word1, word2) (                          \
-    ADDTO2_temp = (word1)[1],                                  \
-    (word1)[1] += (word2)[1],                                  \
-    (word1)[0] += (word2)[0] + ((word1)[1] < ADDTO2_temp) )
-
-/*
- * SHA rotate   ((word >> bits) | (word << (64-bits)))
- */
-static uint32_t ROTR_temp1[2], ROTR_temp2[2];
-#define SHA512_ROTR(bits, word, ret) (                         \
-    SHA512_SHR((bits), (word), ROTR_temp1),                    \
-    SHA512_SHL(64-(bits), (word), ROTR_temp2),                 \
-    SHA512_OR(ROTR_temp1, ROTR_temp2, (ret)) )
-
-/*
- * Define the SHA SIGMA and sigma macros
- *  SHA512_ROTR(28,word) ^ SHA512_ROTR(34,word) ^ SHA512_ROTR(39,word)
- */
-static uint32_t SIGMA0_temp1[2], SIGMA0_temp2[2],
-  SIGMA0_temp3[2], SIGMA0_temp4[2];
-#define SHA512_SIGMA0(word, ret) (                             \
-    SHA512_ROTR(28, (word), SIGMA0_temp1),                     \
-    SHA512_ROTR(34, (word), SIGMA0_temp2),                     \
-    SHA512_ROTR(39, (word), SIGMA0_temp3),                     \
-    SHA512_XOR(SIGMA0_temp2, SIGMA0_temp3, SIGMA0_temp4),      \
-    SHA512_XOR(SIGMA0_temp1, SIGMA0_temp4, (ret)) )
-
-/*
- * SHA512_ROTR(14,word) ^ SHA512_ROTR(18,word) ^ SHA512_ROTR(41,word)
- */
-static uint32_t SIGMA1_temp1[2], SIGMA1_temp2[2],
-  SIGMA1_temp3[2], SIGMA1_temp4[2];
-#define SHA512_SIGMA1(word, ret) (                             \
-    SHA512_ROTR(14, (word), SIGMA1_temp1),                     \
-    SHA512_ROTR(18, (word), SIGMA1_temp2),                     \
-    SHA512_ROTR(41, (word), SIGMA1_temp3),                     \
-    SHA512_XOR(SIGMA1_temp2, SIGMA1_temp3, SIGMA1_temp4),      \
-    SHA512_XOR(SIGMA1_temp1, SIGMA1_temp4, (ret)) )
-
-/*
- * (SHA512_ROTR( 1,word) ^ SHA512_ROTR( 8,word) ^ SHA512_SHR( 7,word))
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 48]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- */
-static uint32_t sigma0_temp1[2], sigma0_temp2[2],
-  sigma0_temp3[2], sigma0_temp4[2];
-#define SHA512_sigma0(word, ret) (                             \
-    SHA512_ROTR( 1, (word), sigma0_temp1),                     \
-    SHA512_ROTR( 8, (word), sigma0_temp2),                     \
-    SHA512_SHR( 7, (word), sigma0_temp3),                      \
-    SHA512_XOR(sigma0_temp2, sigma0_temp3, sigma0_temp4),      \
-    SHA512_XOR(sigma0_temp1, sigma0_temp4, (ret)) )
-
-/*
- * (SHA512_ROTR(19,word) ^ SHA512_ROTR(61,word) ^ SHA512_SHR( 6,word))
- */
-static uint32_t sigma1_temp1[2], sigma1_temp2[2],
-  sigma1_temp3[2], sigma1_temp4[2];
-#define SHA512_sigma1(word, ret) (                             \
-    SHA512_ROTR(19, (word), sigma1_temp1),                     \
-    SHA512_ROTR(61, (word), sigma1_temp2),                     \
-    SHA512_SHR( 6, (word), sigma1_temp3),                      \
-    SHA512_XOR(sigma1_temp2, sigma1_temp3, sigma1_temp4),      \
-    SHA512_XOR(sigma1_temp1, sigma1_temp4, (ret)) )
-
-#undef SHA_Ch
-#undef SHA_Maj
-
-#ifndef USE_MODIFIED_MACROS
-/*
- * These definitions are the ones used in FIPS-180-2, section 4.1.3
- *  Ch(x,y,z)   ((x & y) ^ (~x & z))
- */
-static uint32_t Ch_temp1[2], Ch_temp2[2], Ch_temp3[2];
-#define SHA_Ch(x, y, z, ret) (                                 \
-    SHA512_AND(x, y, Ch_temp1),                                \
-    SHA512_TILDA(x, Ch_temp2),                                 \
-    SHA512_AND(Ch_temp2, z, Ch_temp3),                         \
-    SHA512_XOR(Ch_temp1, Ch_temp3, (ret)) )
-/*
- *  Maj(x,y,z)  (((x)&(y)) ^ ((x)&(z)) ^ ((y)&(z)))
- */
-static uint32_t Maj_temp1[2], Maj_temp2[2],
-  Maj_temp3[2], Maj_temp4[2];
-#define SHA_Maj(x, y, z, ret) (                                \
-    SHA512_AND(x, y, Maj_temp1),                               \
-    SHA512_AND(x, z, Maj_temp2),                               \
-    SHA512_AND(y, z, Maj_temp3),                               \
-    SHA512_XOR(Maj_temp2, Maj_temp3, Maj_temp4),               \
-    SHA512_XOR(Maj_temp1, Maj_temp4, (ret)) )
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 49]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-#else /* !USE_32BIT_ONLY */
-/*
- * These definitions are potentially faster equivalents for the ones
- * used in FIPS-180-2, section 4.1.3.
- *   ((x & y) ^ (~x & z)) becomes
- *   ((x & (y ^ z)) ^ z)
- */
-#define SHA_Ch(x, y, z, ret) (                                 \
-   (ret)[0] = (((x)[0] & ((y)[0] ^ (z)[0])) ^ (z)[0]),         \
-   (ret)[1] = (((x)[1] & ((y)[1] ^ (z)[1])) ^ (z)[1]) )
-
-/*
- *   ((x & y) ^ (x & z) ^ (y & z)) becomes
- *   ((x & (y | z)) | (y & z))
- */
-#define SHA_Maj(x, y, z, ret) (                                 \
-   ret[0] = (((x)[0] & ((y)[0] | (z)[0])) | ((y)[0] & (z)[0])), \
-   ret[1] = (((x)[1] & ((y)[1] | (z)[1])) | ((y)[1] & (z)[1])) )
-#endif /* USE_MODIFIED_MACROS */
-
-/*
- * add "length" to the length
- */
-static uint32_t addTemp[4] = { 0, 0, 0, 0 };
-#define SHA384_512AddLength(context, length) (                        \
-    addTemp[3] = (length), SHA512_ADDTO4((context)->Length, addTemp), \
-    (context)->Corrupted = (((context)->Length[3] == 0) &&            \
-       ((context)->Length[2] == 0) && ((context)->Length[1] == 0) &&  \
-       ((context)->Length[0] < 8)) ? 1 : 0 )
-
-/* Local Function Prototypes */
-static void SHA384_512Finalize(SHA512Context *context,
-  uint8_t Pad_Byte);
-static void SHA384_512PadMessage(SHA512Context *context,
-  uint8_t Pad_Byte);
-static void SHA384_512ProcessMessageBlock(SHA512Context *context);
-static int SHA384_512Reset(SHA512Context *context, uint32_t H0[]);
-static int SHA384_512ResultN( SHA512Context *context,
-  uint8_t Message_Digest[], int HashSize);
-
-/* Initial Hash Values: FIPS-180-2 sections 5.3.3 and 5.3.4 */
-static uint32_t SHA384_H0[SHA512HashSize/4] = {
-    0xCBBB9D5D, 0xC1059ED8, 0x629A292A, 0x367CD507, 0x9159015A,
-    0x3070DD17, 0x152FECD8, 0xF70E5939, 0x67332667, 0xFFC00B31,
-    0x8EB44A87, 0x68581511, 0xDB0C2E0D, 0x64F98FA7, 0x47B5481D,
-    0xBEFA4FA4
-};
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 50]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-static uint32_t SHA512_H0[SHA512HashSize/4] = {
-    0x6A09E667, 0xF3BCC908, 0xBB67AE85, 0x84CAA73B, 0x3C6EF372,
-    0xFE94F82B, 0xA54FF53A, 0x5F1D36F1, 0x510E527F, 0xADE682D1,
-    0x9B05688C, 0x2B3E6C1F, 0x1F83D9AB, 0xFB41BD6B, 0x5BE0CD19,
-    0x137E2179
-};
-
-#else /* !USE_32BIT_ONLY */
-
-/* Define the SHA shift, rotate left and rotate right macro */
-#define SHA512_SHR(bits,word)  (((uint64_t)(word)) >> (bits))
-#define SHA512_ROTR(bits,word) ((((uint64_t)(word)) >> (bits)) | \
-                                (((uint64_t)(word)) << (64-(bits))))
-
-/* Define the SHA SIGMA and sigma macros */
-#define SHA512_SIGMA0(word)   \
- (SHA512_ROTR(28,word) ^ SHA512_ROTR(34,word) ^ SHA512_ROTR(39,word))
-#define SHA512_SIGMA1(word)   \
- (SHA512_ROTR(14,word) ^ SHA512_ROTR(18,word) ^ SHA512_ROTR(41,word))
-#define SHA512_sigma0(word)   \
- (SHA512_ROTR( 1,word) ^ SHA512_ROTR( 8,word) ^ SHA512_SHR( 7,word))
-#define SHA512_sigma1(word)   \
- (SHA512_ROTR(19,word) ^ SHA512_ROTR(61,word) ^ SHA512_SHR( 6,word))
-
-/*
- * add "length" to the length
- */
-static uint64_t addTemp;
-#define SHA384_512AddLength(context, length)                   \
-   (addTemp = context->Length_Low, context->Corrupted =        \
-    ((context->Length_Low += length) < addTemp) &&             \
-    (++context->Length_High == 0) ? 1 : 0)
-
-/* Local Function Prototypes */
-static void SHA384_512Finalize(SHA512Context *context,
-  uint8_t Pad_Byte);
-static void SHA384_512PadMessage(SHA512Context *context,
-  uint8_t Pad_Byte);
-static void SHA384_512ProcessMessageBlock(SHA512Context *context);
-static int SHA384_512Reset(SHA512Context *context, uint64_t H0[]);
-static int SHA384_512ResultN(SHA512Context *context,
-  uint8_t Message_Digest[], int HashSize);
-
-/* Initial Hash Values: FIPS-180-2 sections 5.3.3 and 5.3.4 */
-static uint64_t SHA384_H0[] = {
-    0xCBBB9D5DC1059ED8ll, 0x629A292A367CD507ll, 0x9159015A3070DD17ll,
-    0x152FECD8F70E5939ll, 0x67332667FFC00B31ll, 0x8EB44A8768581511ll,
-    0xDB0C2E0D64F98FA7ll, 0x47B5481DBEFA4FA4ll
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 51]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-};
-static uint64_t SHA512_H0[] = {
-    0x6A09E667F3BCC908ll, 0xBB67AE8584CAA73Bll, 0x3C6EF372FE94F82Bll,
-    0xA54FF53A5F1D36F1ll, 0x510E527FADE682D1ll, 0x9B05688C2B3E6C1Fll,
-    0x1F83D9ABFB41BD6Bll, 0x5BE0CD19137E2179ll
-};
-
-#endif /* USE_32BIT_ONLY */
-
-/*
- * SHA384Reset
- *
- * Description:
- *   This function will initialize the SHA384Context in preparation
- *   for computing a new SHA384 message digest.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to reset.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-int SHA384Reset(SHA384Context *context)
-{
-  return SHA384_512Reset(context, SHA384_H0);
-}
-
-/*
- * SHA384Input
- *
- * Description:
- *   This function accepts an array of octets as the next portion
- *   of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_array: [in]
- *     An array of characters representing the next portion of
- *     the message.
- *   length: [in]
- *     The length of the message in message_array
- *
- * Returns:
- *   sha Error Code.
- *
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 52]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- */
-int SHA384Input(SHA384Context *context,
-    const uint8_t *message_array, unsigned int length)
-{
-  return SHA512Input(context, message_array, length);
-}
-
-/*
- * SHA384FinalBits
- *
- * Description:
- *   This function will add in any final bits of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_bits: [in]
- *     The final bits of the message, in the upper portion of the
- *     byte. (Use 0b###00000 instead of 0b00000### to input the
- *     three bits ###.)
- *   length: [in]
- *     The number of bits in message_bits, between 1 and 7.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-int SHA384FinalBits(SHA384Context *context,
-    const uint8_t message_bits, unsigned int length)
-{
-  return SHA512FinalBits(context, message_bits, length);
-}
-
-/*
- * SHA384Result
- *
- * Description:
- *   This function will return the 384-bit message
- *   digest into the Message_Digest array provided by the caller.
- *   NOTE: The first octet of hash is stored in the 0th element,
- *      the last octet of hash in the 48th element.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to use to calculate the SHA hash.
- *   Message_Digest: [out]
- *     Where the digest is returned.
- *
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 53]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- * Returns:
- *   sha Error Code.
- *
- */
-int SHA384Result(SHA384Context *context,
-    uint8_t Message_Digest[SHA384HashSize])
-{
-  return SHA384_512ResultN(context, Message_Digest, SHA384HashSize);
-}
-
-/*
- * SHA512Reset
- *
- * Description:
- *   This function will initialize the SHA512Context in preparation
- *   for computing a new SHA512 message digest.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to reset.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-int SHA512Reset(SHA512Context *context)
-{
-  return SHA384_512Reset(context, SHA512_H0);
-}
-
-/*
- * SHA512Input
- *
- * Description:
- *   This function accepts an array of octets as the next portion
- *   of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_array: [in]
- *     An array of characters representing the next portion of
- *     the message.
- *   length: [in]
- *     The length of the message in message_array
- *
- * Returns:
- *   sha Error Code.
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 54]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *
- */
-int SHA512Input(SHA512Context *context,
-        const uint8_t *message_array,
-        unsigned int length)
-{
-  if (!length)
-    return shaSuccess;
-
-  if (!context || !message_array)
-    return shaNull;
-
-  if (context->Computed) {
-    context->Corrupted = shaStateError;
-    return shaStateError;
-  }
-
-  if (context->Corrupted)
-     return context->Corrupted;
-
-  while (length-- && !context->Corrupted) {
-    context->Message_Block[context->Message_Block_Index++] =
-            (*message_array & 0xFF);
-
-    if (!SHA384_512AddLength(context, 8) &&
-      (context->Message_Block_Index == SHA512_Message_Block_Size))
-      SHA384_512ProcessMessageBlock(context);
-
-    message_array++;
-  }
-
-  return shaSuccess;
-}
-
-/*
- * SHA512FinalBits
- *
- * Description:
- *   This function will add in any final bits of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_bits: [in]
- *     The final bits of the message, in the upper portion of the
- *     byte. (Use 0b###00000 instead of 0b00000### to input the
- *     three bits ###.)
- *   length: [in]
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 55]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *     The number of bits in message_bits, between 1 and 7.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-int SHA512FinalBits(SHA512Context *context,
-    const uint8_t message_bits, unsigned int length)
-{
-  uint8_t masks[8] = {
-      /* 0 0b00000000 */ 0x00, /* 1 0b10000000 */ 0x80,
-      /* 2 0b11000000 */ 0xC0, /* 3 0b11100000 */ 0xE0,
-      /* 4 0b11110000 */ 0xF0, /* 5 0b11111000 */ 0xF8,
-      /* 6 0b11111100 */ 0xFC, /* 7 0b11111110 */ 0xFE
-  };
-  uint8_t markbit[8] = {
-      /* 0 0b10000000 */ 0x80, /* 1 0b01000000 */ 0x40,
-      /* 2 0b00100000 */ 0x20, /* 3 0b00010000 */ 0x10,
-      /* 4 0b00001000 */ 0x08, /* 5 0b00000100 */ 0x04,
-      /* 6 0b00000010 */ 0x02, /* 7 0b00000001 */ 0x01
-  };
-
-  if (!length)
-    return shaSuccess;
-
-  if (!context)
-    return shaNull;
-
-  if ((context->Computed) || (length >= 8) || (length == 0)) {
-    context->Corrupted = shaStateError;
-    return shaStateError;
-  }
-
-  if (context->Corrupted)
-     return context->Corrupted;
-
-  SHA384_512AddLength(context, length);
-  SHA384_512Finalize(context, (uint8_t)
-    ((message_bits & masks[length]) | markbit[length]));
-
-  return shaSuccess;
-}
-
-/*
- * SHA384_512Finalize
- *
- * Description:
- *   This helper function finishes off the digest calculations.
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 56]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   Pad_Byte: [in]
- *     The last byte to add to the digest before the 0-padding
- *     and length. This will contain the last bits of the message
- *     followed by another single bit. If the message was an
- *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-static void SHA384_512Finalize(SHA512Context *context,
-    uint8_t Pad_Byte)
-{
-  int_least16_t i;
-  SHA384_512PadMessage(context, Pad_Byte);
-  /* message may be sensitive, clear it out */
-  for (i = 0; i < SHA512_Message_Block_Size; ++i)
-    context->Message_Block[i] = 0;
-#ifdef USE_32BIT_ONLY    /* and clear length */
-  context->Length[0] = context->Length[1] = 0;
-  context->Length[2] = context->Length[3] = 0;
-#else /* !USE_32BIT_ONLY */
-  context->Length_Low = 0;
-  context->Length_High = 0;
-#endif /* USE_32BIT_ONLY */
-  context->Computed = 1;
-}
-
-/*
- * SHA512Result
- *
- * Description:
- *   This function will return the 512-bit message
- *   digest into the Message_Digest array provided by the caller.
- *   NOTE: The first octet of hash is stored in the 0th element,
- *      the last octet of hash in the 64th element.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to use to calculate the SHA hash.
- *   Message_Digest: [out]
- *     Where the digest is returned.
- *
- * Returns:
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 57]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *   sha Error Code.
- *
- */
-int SHA512Result(SHA512Context *context,
-    uint8_t Message_Digest[SHA512HashSize])
-{
-  return SHA384_512ResultN(context, Message_Digest, SHA512HashSize);
-}
-
-/*
- * SHA384_512PadMessage
- *
- * Description:
- *   According to the standard, the message must be padded to an
- *   even 1024 bits. The first padding bit must be a '1'. The
- *   last 128 bits represent the length of the original message.
- *   All bits in between should be 0. This helper function will
- *   pad the message according to those rules by filling the
- *   Message_Block array accordingly. When it returns, it can be
- *   assumed that the message digest has been computed.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to pad
- *   Pad_Byte: [in]
- *     The last byte to add to the digest before the 0-padding
- *     and length. This will contain the last bits of the message
- *     followed by another single bit. If the message was an
- *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
- *
- * Returns:
- *   Nothing.
- *
- */
-static void SHA384_512PadMessage(SHA512Context *context,
-    uint8_t Pad_Byte)
-{
-  /*
-   * Check to see if the current message block is too small to hold
-   * the initial padding bits and length. If so, we will pad the
-   * block, process it, and then continue padding into a second
-   * block.
-   */
-  if (context->Message_Block_Index >= (SHA512_Message_Block_Size-16)) {
-    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
-    while (context->Message_Block_Index < SHA512_Message_Block_Size)
-      context->Message_Block[context->Message_Block_Index++] = 0;
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 58]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-    SHA384_512ProcessMessageBlock(context);
-  } else
-    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
-
-  while (context->Message_Block_Index < (SHA512_Message_Block_Size-16))
-    context->Message_Block[context->Message_Block_Index++] = 0;
-
-  /*
-   * Store the message length as the last 16 octets
-   */
-#ifdef USE_32BIT_ONLY
-  context->Message_Block[112] = (uint8_t)(context->Length[0] >> 24);
-  context->Message_Block[113] = (uint8_t)(context->Length[0] >> 16);
-  context->Message_Block[114] = (uint8_t)(context->Length[0] >> 8);
-  context->Message_Block[115] = (uint8_t)(context->Length[0]);
-  context->Message_Block[116] = (uint8_t)(context->Length[1] >> 24);
-  context->Message_Block[117] = (uint8_t)(context->Length[1] >> 16);
-  context->Message_Block[118] = (uint8_t)(context->Length[1] >> 8);
-  context->Message_Block[119] = (uint8_t)(context->Length[1]);
-
-  context->Message_Block[120] = (uint8_t)(context->Length[2] >> 24);
-  context->Message_Block[121] = (uint8_t)(context->Length[2] >> 16);
-  context->Message_Block[122] = (uint8_t)(context->Length[2] >> 8);
-  context->Message_Block[123] = (uint8_t)(context->Length[2]);
-  context->Message_Block[124] = (uint8_t)(context->Length[3] >> 24);
-  context->Message_Block[125] = (uint8_t)(context->Length[3] >> 16);
-  context->Message_Block[126] = (uint8_t)(context->Length[3] >> 8);
-  context->Message_Block[127] = (uint8_t)(context->Length[3]);
-#else /* !USE_32BIT_ONLY */
-  context->Message_Block[112] = (uint8_t)(context->Length_High >> 56);
-  context->Message_Block[113] = (uint8_t)(context->Length_High >> 48);
-  context->Message_Block[114] = (uint8_t)(context->Length_High >> 40);
-  context->Message_Block[115] = (uint8_t)(context->Length_High >> 32);
-  context->Message_Block[116] = (uint8_t)(context->Length_High >> 24);
-  context->Message_Block[117] = (uint8_t)(context->Length_High >> 16);
-  context->Message_Block[118] = (uint8_t)(context->Length_High >> 8);
-  context->Message_Block[119] = (uint8_t)(context->Length_High);
-
-  context->Message_Block[120] = (uint8_t)(context->Length_Low >> 56);
-  context->Message_Block[121] = (uint8_t)(context->Length_Low >> 48);
-  context->Message_Block[122] = (uint8_t)(context->Length_Low >> 40);
-  context->Message_Block[123] = (uint8_t)(context->Length_Low >> 32);
-  context->Message_Block[124] = (uint8_t)(context->Length_Low >> 24);
-  context->Message_Block[125] = (uint8_t)(context->Length_Low >> 16);
-  context->Message_Block[126] = (uint8_t)(context->Length_Low >> 8);
-  context->Message_Block[127] = (uint8_t)(context->Length_Low);
-#endif /* USE_32BIT_ONLY */
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 59]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  SHA384_512ProcessMessageBlock(context);
-}
-
-/*
- * SHA384_512ProcessMessageBlock
- *
- * Description:
- *   This helper function will process the next 1024 bits of the
- *   message stored in the Message_Block array.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *
- * Returns:
- *   Nothing.
- *
- * Comments:
- *   Many of the variable names in this code, especially the
- *   single character names, were used because those were the
- *   names used in the publication.
- *
- *
- */
-static void SHA384_512ProcessMessageBlock(SHA512Context *context)
-{
-  /* Constants defined in FIPS-180-2, section 4.2.3 */
-#ifdef USE_32BIT_ONLY
-  static const uint32_t K[80*2] = {
-      0x428A2F98, 0xD728AE22, 0x71374491, 0x23EF65CD, 0xB5C0FBCF,
-      0xEC4D3B2F, 0xE9B5DBA5, 0x8189DBBC, 0x3956C25B, 0xF348B538,
-      0x59F111F1, 0xB605D019, 0x923F82A4, 0xAF194F9B, 0xAB1C5ED5,
-      0xDA6D8118, 0xD807AA98, 0xA3030242, 0x12835B01, 0x45706FBE,
-      0x243185BE, 0x4EE4B28C, 0x550C7DC3, 0xD5FFB4E2, 0x72BE5D74,
-      0xF27B896F, 0x80DEB1FE, 0x3B1696B1, 0x9BDC06A7, 0x25C71235,
-      0xC19BF174, 0xCF692694, 0xE49B69C1, 0x9EF14AD2, 0xEFBE4786,
-      0x384F25E3, 0x0FC19DC6, 0x8B8CD5B5, 0x240CA1CC, 0x77AC9C65,
-      0x2DE92C6F, 0x592B0275, 0x4A7484AA, 0x6EA6E483, 0x5CB0A9DC,
-      0xBD41FBD4, 0x76F988DA, 0x831153B5, 0x983E5152, 0xEE66DFAB,
-      0xA831C66D, 0x2DB43210, 0xB00327C8, 0x98FB213F, 0xBF597FC7,
-      0xBEEF0EE4, 0xC6E00BF3, 0x3DA88FC2, 0xD5A79147, 0x930AA725,
-      0x06CA6351, 0xE003826F, 0x14292967, 0x0A0E6E70, 0x27B70A85,
-      0x46D22FFC, 0x2E1B2138, 0x5C26C926, 0x4D2C6DFC, 0x5AC42AED,
-      0x53380D13, 0x9D95B3DF, 0x650A7354, 0x8BAF63DE, 0x766A0ABB,
-      0x3C77B2A8, 0x81C2C92E, 0x47EDAEE6, 0x92722C85, 0x1482353B,
-      0xA2BFE8A1, 0x4CF10364, 0xA81A664B, 0xBC423001, 0xC24B8B70,
-      0xD0F89791, 0xC76C51A3, 0x0654BE30, 0xD192E819, 0xD6EF5218,
-      0xD6990624, 0x5565A910, 0xF40E3585, 0x5771202A, 0x106AA070,
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 60]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      0x32BBD1B8, 0x19A4C116, 0xB8D2D0C8, 0x1E376C08, 0x5141AB53,
-      0x2748774C, 0xDF8EEB99, 0x34B0BCB5, 0xE19B48A8, 0x391C0CB3,
-      0xC5C95A63, 0x4ED8AA4A, 0xE3418ACB, 0x5B9CCA4F, 0x7763E373,
-      0x682E6FF3, 0xD6B2B8A3, 0x748F82EE, 0x5DEFB2FC, 0x78A5636F,
-      0x43172F60, 0x84C87814, 0xA1F0AB72, 0x8CC70208, 0x1A6439EC,
-      0x90BEFFFA, 0x23631E28, 0xA4506CEB, 0xDE82BDE9, 0xBEF9A3F7,
-      0xB2C67915, 0xC67178F2, 0xE372532B, 0xCA273ECE, 0xEA26619C,
-      0xD186B8C7, 0x21C0C207, 0xEADA7DD6, 0xCDE0EB1E, 0xF57D4F7F,
-      0xEE6ED178, 0x06F067AA, 0x72176FBA, 0x0A637DC5, 0xA2C898A6,
-      0x113F9804, 0xBEF90DAE, 0x1B710B35, 0x131C471B, 0x28DB77F5,
-      0x23047D84, 0x32CAAB7B, 0x40C72493, 0x3C9EBE0A, 0x15C9BEBC,
-      0x431D67C4, 0x9C100D4C, 0x4CC5D4BE, 0xCB3E42B6, 0x597F299C,
-      0xFC657E2A, 0x5FCB6FAB, 0x3AD6FAEC, 0x6C44198C, 0x4A475817
-  };
-  int     t, t2, t8;                  /* Loop counter */
-  uint32_t  temp1[2], temp2[2],       /* Temporary word values */
-        temp3[2], temp4[2], temp5[2];
-  uint32_t  W[2*80];                  /* Word sequence */
-  uint32_t  A[2], B[2], C[2], D[2],   /* Word buffers */
-        E[2], F[2], G[2], H[2];
-
-  /* Initialize the first 16 words in the array W */
-  for (t = t2 = t8 = 0; t < 16; t++, t8 += 8) {
-    W[t2++] = ((((uint32_t)context->Message_Block[t8    ])) << 24) |
-              ((((uint32_t)context->Message_Block[t8 + 1])) << 16) |
-              ((((uint32_t)context->Message_Block[t8 + 2])) << 8) |
-              ((((uint32_t)context->Message_Block[t8 + 3])));
-    W[t2++] = ((((uint32_t)context->Message_Block[t8 + 4])) << 24) |
-              ((((uint32_t)context->Message_Block[t8 + 5])) << 16) |
-              ((((uint32_t)context->Message_Block[t8 + 6])) << 8) |
-              ((((uint32_t)context->Message_Block[t8 + 7])));
-  }
-
-  for (t = 16; t < 80; t++, t2 += 2) {
-    /* W[t] = SHA512_sigma1(W[t-2]) + W[t-7] +
-      SHA512_sigma0(W[t-15]) + W[t-16]; */
-    uint32_t *Wt2 = &W[t2-2*2];
-    uint32_t *Wt7 = &W[t2-7*2];
-    uint32_t *Wt15 = &W[t2-15*2];
-    uint32_t *Wt16 = &W[t2-16*2];
-    SHA512_sigma1(Wt2, temp1);
-    SHA512_ADD(temp1, Wt7, temp2);
-    SHA512_sigma0(Wt15, temp1);
-    SHA512_ADD(temp1, Wt16, temp3);
-    SHA512_ADD(temp2, temp3, &W[t2]);
-  }
-
-  A[0] = context->Intermediate_Hash[0];
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 61]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  A[1] = context->Intermediate_Hash[1];
-  B[0] = context->Intermediate_Hash[2];
-  B[1] = context->Intermediate_Hash[3];
-  C[0] = context->Intermediate_Hash[4];
-  C[1] = context->Intermediate_Hash[5];
-  D[0] = context->Intermediate_Hash[6];
-  D[1] = context->Intermediate_Hash[7];
-  E[0] = context->Intermediate_Hash[8];
-  E[1] = context->Intermediate_Hash[9];
-  F[0] = context->Intermediate_Hash[10];
-  F[1] = context->Intermediate_Hash[11];
-  G[0] = context->Intermediate_Hash[12];
-  G[1] = context->Intermediate_Hash[13];
-  H[0] = context->Intermediate_Hash[14];
-  H[1] = context->Intermediate_Hash[15];
-
-  for (t = t2 = 0; t < 80; t++, t2 += 2) {
-    /*
-     * temp1 = H + SHA512_SIGMA1(E) + SHA_Ch(E,F,G) + K[t] + W[t];
-     */
-    SHA512_SIGMA1(E,temp1);
-    SHA512_ADD(H, temp1, temp2);
-    SHA_Ch(E,F,G,temp3);
-    SHA512_ADD(temp2, temp3, temp4);
-    SHA512_ADD(&K[t2], &W[t2], temp5);
-    SHA512_ADD(temp4, temp5, temp1);
-    /*
-     * temp2 = SHA512_SIGMA0(A) + SHA_Maj(A,B,C);
-     */
-    SHA512_SIGMA0(A,temp3);
-    SHA_Maj(A,B,C,temp4);
-    SHA512_ADD(temp3, temp4, temp2);
-    H[0] = G[0]; H[1] = G[1];
-    G[0] = F[0]; G[1] = F[1];
-    F[0] = E[0]; F[1] = E[1];
-    SHA512_ADD(D, temp1, E);
-    D[0] = C[0]; D[1] = C[1];
-    C[0] = B[0]; C[1] = B[1];
-    B[0] = A[0]; B[1] = A[1];
-    SHA512_ADD(temp1, temp2, A);
-  }
-
-  SHA512_ADDTO2(&context->Intermediate_Hash[0], A);
-  SHA512_ADDTO2(&context->Intermediate_Hash[2], B);
-  SHA512_ADDTO2(&context->Intermediate_Hash[4], C);
-  SHA512_ADDTO2(&context->Intermediate_Hash[6], D);
-  SHA512_ADDTO2(&context->Intermediate_Hash[8], E);
-  SHA512_ADDTO2(&context->Intermediate_Hash[10], F);
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 62]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  SHA512_ADDTO2(&context->Intermediate_Hash[12], G);
-  SHA512_ADDTO2(&context->Intermediate_Hash[14], H);
-
-#else /* !USE_32BIT_ONLY */
-  static const uint64_t K[80] = {
-      0x428A2F98D728AE22ll, 0x7137449123EF65CDll, 0xB5C0FBCFEC4D3B2Fll,
-      0xE9B5DBA58189DBBCll, 0x3956C25BF348B538ll, 0x59F111F1B605D019ll,
-      0x923F82A4AF194F9Bll, 0xAB1C5ED5DA6D8118ll, 0xD807AA98A3030242ll,
-      0x12835B0145706FBEll, 0x243185BE4EE4B28Cll, 0x550C7DC3D5FFB4E2ll,
-      0x72BE5D74F27B896Fll, 0x80DEB1FE3B1696B1ll, 0x9BDC06A725C71235ll,
-      0xC19BF174CF692694ll, 0xE49B69C19EF14AD2ll, 0xEFBE4786384F25E3ll,
-      0x0FC19DC68B8CD5B5ll, 0x240CA1CC77AC9C65ll, 0x2DE92C6F592B0275ll,
-      0x4A7484AA6EA6E483ll, 0x5CB0A9DCBD41FBD4ll, 0x76F988DA831153B5ll,
-      0x983E5152EE66DFABll, 0xA831C66D2DB43210ll, 0xB00327C898FB213Fll,
-      0xBF597FC7BEEF0EE4ll, 0xC6E00BF33DA88FC2ll, 0xD5A79147930AA725ll,
-      0x06CA6351E003826Fll, 0x142929670A0E6E70ll, 0x27B70A8546D22FFCll,
-      0x2E1B21385C26C926ll, 0x4D2C6DFC5AC42AEDll, 0x53380D139D95B3DFll,
-      0x650A73548BAF63DEll, 0x766A0ABB3C77B2A8ll, 0x81C2C92E47EDAEE6ll,
-      0x92722C851482353Bll, 0xA2BFE8A14CF10364ll, 0xA81A664BBC423001ll,
-      0xC24B8B70D0F89791ll, 0xC76C51A30654BE30ll, 0xD192E819D6EF5218ll,
-      0xD69906245565A910ll, 0xF40E35855771202All, 0x106AA07032BBD1B8ll,
-      0x19A4C116B8D2D0C8ll, 0x1E376C085141AB53ll, 0x2748774CDF8EEB99ll,
-      0x34B0BCB5E19B48A8ll, 0x391C0CB3C5C95A63ll, 0x4ED8AA4AE3418ACBll,
-      0x5B9CCA4F7763E373ll, 0x682E6FF3D6B2B8A3ll, 0x748F82EE5DEFB2FCll,
-      0x78A5636F43172F60ll, 0x84C87814A1F0AB72ll, 0x8CC702081A6439ECll,
-      0x90BEFFFA23631E28ll, 0xA4506CEBDE82BDE9ll, 0xBEF9A3F7B2C67915ll,
-      0xC67178F2E372532Bll, 0xCA273ECEEA26619Cll, 0xD186B8C721C0C207ll,
-      0xEADA7DD6CDE0EB1Ell, 0xF57D4F7FEE6ED178ll, 0x06F067AA72176FBAll,
-      0x0A637DC5A2C898A6ll, 0x113F9804BEF90DAEll, 0x1B710B35131C471Bll,
-      0x28DB77F523047D84ll, 0x32CAAB7B40C72493ll, 0x3C9EBE0A15C9BEBCll,
-      0x431D67C49C100D4Cll, 0x4CC5D4BECB3E42B6ll, 0x597F299CFC657E2All,
-      0x5FCB6FAB3AD6FAECll, 0x6C44198C4A475817ll
-  };
-  int        t, t8;                   /* Loop counter */
-  uint64_t   temp1, temp2;            /* Temporary word value */
-  uint64_t   W[80];                   /* Word sequence */
-  uint64_t   A, B, C, D, E, F, G, H;  /* Word buffers */
-
-  /*
-   * Initialize the first 16 words in the array W
-   */
-  for (t = t8 = 0; t < 16; t++, t8 += 8)
-    W[t] = ((uint64_t)(context->Message_Block[t8  ]) << 56) |
-           ((uint64_t)(context->Message_Block[t8 + 1]) << 48) |
-           ((uint64_t)(context->Message_Block[t8 + 2]) << 40) |
-           ((uint64_t)(context->Message_Block[t8 + 3]) << 32) |
-           ((uint64_t)(context->Message_Block[t8 + 4]) << 24) |
-           ((uint64_t)(context->Message_Block[t8 + 5]) << 16) |
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 63]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-           ((uint64_t)(context->Message_Block[t8 + 6]) << 8) |
-           ((uint64_t)(context->Message_Block[t8 + 7]));
-
-  for (t = 16; t < 80; t++)
-    W[t] = SHA512_sigma1(W[t-2]) + W[t-7] +
-        SHA512_sigma0(W[t-15]) + W[t-16];
-
-  A = context->Intermediate_Hash[0];
-  B = context->Intermediate_Hash[1];
-  C = context->Intermediate_Hash[2];
-  D = context->Intermediate_Hash[3];
-  E = context->Intermediate_Hash[4];
-  F = context->Intermediate_Hash[5];
-  G = context->Intermediate_Hash[6];
-  H = context->Intermediate_Hash[7];
-
-  for (t = 0; t < 80; t++) {
-    temp1 = H + SHA512_SIGMA1(E) + SHA_Ch(E,F,G) + K[t] + W[t];
-    temp2 = SHA512_SIGMA0(A) + SHA_Maj(A,B,C);
-    H = G;
-    G = F;
-    F = E;
-    E = D + temp1;
-    D = C;
-    C = B;
-    B = A;
-    A = temp1 + temp2;
-  }
-
-  context->Intermediate_Hash[0] += A;
-  context->Intermediate_Hash[1] += B;
-  context->Intermediate_Hash[2] += C;
-  context->Intermediate_Hash[3] += D;
-  context->Intermediate_Hash[4] += E;
-  context->Intermediate_Hash[5] += F;
-  context->Intermediate_Hash[6] += G;
-  context->Intermediate_Hash[7] += H;
-#endif /* USE_32BIT_ONLY */
-
-  context->Message_Block_Index = 0;
-}
-
-/*
- * SHA384_512Reset
- *
- * Description:
- *   This helper function will initialize the SHA512Context in
- *   preparation for computing a new SHA384 or SHA512 message
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 64]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *   digest.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to reset.
- *   H0
- *     The initial hash value to use.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-#ifdef USE_32BIT_ONLY
-static int SHA384_512Reset(SHA512Context *context, uint32_t H0[])
-#else /* !USE_32BIT_ONLY */
-static int SHA384_512Reset(SHA512Context *context, uint64_t H0[])
-#endif /* USE_32BIT_ONLY */
-{
-  int i;
-  if (!context)
-    return shaNull;
-
-  context->Message_Block_Index = 0;
-
-#ifdef USE_32BIT_ONLY
-  context->Length[0] = context->Length[1] = 0;
-  context->Length[2] = context->Length[3] = 0;
-
-  for (i = 0; i < SHA512HashSize/4; i++)
-    context->Intermediate_Hash[i] = H0[i];
-#else /* !USE_32BIT_ONLY */
-  context->Length_High = context->Length_Low = 0;
-
-  for (i = 0; i < SHA512HashSize/8; i++)
-    context->Intermediate_Hash[i] = H0[i];
-#endif /* USE_32BIT_ONLY */
-
-  context->Computed = 0;
-  context->Corrupted = 0;
-
-  return shaSuccess;
-}
-
-/*
- * SHA384_512ResultN
- *
- * Description:
- *   This helper function will return the 384-bit or 512-bit message
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 65]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *   digest into the Message_Digest array provided by the caller.
- *   NOTE: The first octet of hash is stored in the 0th element,
- *      the last octet of hash in the 48th/64th element.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to use to calculate the SHA hash.
- *   Message_Digest: [out]
- *     Where the digest is returned.
- *   HashSize: [in]
- *     The size of the hash, either 48 or 64.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-static int SHA384_512ResultN(SHA512Context *context,
-    uint8_t Message_Digest[], int HashSize)
-{
-  int i;
-
-#ifdef USE_32BIT_ONLY
-  int i2;
-#endif /* USE_32BIT_ONLY */
-
-  if (!context || !Message_Digest)
-    return shaNull;
-
-  if (context->Corrupted)
-    return context->Corrupted;
-
-  if (!context->Computed)
-    SHA384_512Finalize(context, 0x80);
-
-#ifdef USE_32BIT_ONLY
-  for (i = i2 = 0; i < HashSize; ) {
-    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>24);
-    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>16);
-    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>8);
-    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2++]);
-    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>24);
-    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>16);
-    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>8);
-    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2++]);
-  }
-#else /* !USE_32BIT_ONLY */
-  for (i = 0; i < HashSize; ++i)
-    Message_Digest[i] = (uint8_t)
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 66]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      (context->Intermediate_Hash[i>>3] >> 8 * ( 7 - ( i % 8 ) ));
-#endif /* USE_32BIT_ONLY */
-
-  return shaSuccess;
-}
-
-8.2.4.  usha.c
-
-/**************************** usha.c ****************************/
-/******************** See RFC 4634 for details ******************/
-/*
- *  Description:
- *     This file implements a unified interface to the SHA algorithms.
- */
-
-#include "sha.h"
-
-/*
- *  USHAReset
- *
- *  Description:
- *      This function will initialize the SHA Context in preparation
- *      for computing a new SHA message digest.
- *
- *  Parameters:
- *      context: [in/out]
- *          The context to reset.
- *      whichSha: [in]
- *          Selects which SHA reset to call
- *
- *  Returns:
- *      sha Error Code.
- *
- */
-int USHAReset(USHAContext *ctx, enum SHAversion whichSha)
-{
-  if (ctx) {
-    ctx->whichSha = whichSha;
-    switch (whichSha) {
-      case SHA1:   return SHA1Reset((SHA1Context*)&ctx->ctx);
-      case SHA224: return SHA224Reset((SHA224Context*)&ctx->ctx);
-      case SHA256: return SHA256Reset((SHA256Context*)&ctx->ctx);
-      case SHA384: return SHA384Reset((SHA384Context*)&ctx->ctx);
-      case SHA512: return SHA512Reset((SHA512Context*)&ctx->ctx);
-      default: return shaBadParam;
-    }
-  } else {
-    return shaNull;
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 67]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  }
-}
-
-/*
- *  USHAInput
- *
- *  Description:
- *      This function accepts an array of octets as the next portion
- *      of the message.
- *
- *  Parameters:
- *      context: [in/out]
- *          The SHA context to update
- *      message_array: [in]
- *          An array of characters representing the next portion of
- *          the message.
- *      length: [in]
- *          The length of the message in message_array
- *
- *  Returns:
- *      sha Error Code.
- *
- */
-int USHAInput(USHAContext *ctx,
-              const uint8_t *bytes, unsigned int bytecount)
-{
-  if (ctx) {
-    switch (ctx->whichSha) {
-      case SHA1:
-        return SHA1Input((SHA1Context*)&ctx->ctx, bytes, bytecount);
-      case SHA224:
-        return SHA224Input((SHA224Context*)&ctx->ctx, bytes,
-            bytecount);
-      case SHA256:
-        return SHA256Input((SHA256Context*)&ctx->ctx, bytes,
-            bytecount);
-      case SHA384:
-        return SHA384Input((SHA384Context*)&ctx->ctx, bytes,
-            bytecount);
-      case SHA512:
-        return SHA512Input((SHA512Context*)&ctx->ctx, bytes,
-            bytecount);
-      default: return shaBadParam;
-    }
-  } else {
-    return shaNull;
-  }
-}
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 68]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-/*
- * USHAFinalBits
- *
- * Description:
- *   This function will add in any final bits of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The SHA context to update
- *   message_bits: [in]
- *     The final bits of the message, in the upper portion of the
- *     byte. (Use 0b###00000 instead of 0b00000### to input the
- *     three bits ###.)
- *   length: [in]
- *     The number of bits in message_bits, between 1 and 7.
- *
- * Returns:
- *   sha Error Code.
- */
-int USHAFinalBits(USHAContext *ctx,
-                  const uint8_t bits, unsigned int bitcount)
-{
-  if (ctx) {
-    switch (ctx->whichSha) {
-      case SHA1:
-        return SHA1FinalBits((SHA1Context*)&ctx->ctx, bits, bitcount);
-      case SHA224:
-        return SHA224FinalBits((SHA224Context*)&ctx->ctx, bits,
-            bitcount);
-      case SHA256:
-        return SHA256FinalBits((SHA256Context*)&ctx->ctx, bits,
-            bitcount);
-      case SHA384:
-        return SHA384FinalBits((SHA384Context*)&ctx->ctx, bits,
-            bitcount);
-      case SHA512:
-        return SHA512FinalBits((SHA512Context*)&ctx->ctx, bits,
-            bitcount);
-      default: return shaBadParam;
-    }
-  } else {
-    return shaNull;
-  }
-}
-
-/*
- * USHAResult
- *
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 69]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- * Description:
- *   This function will return the 160-bit message digest into the
- *   Message_Digest array provided by the caller.
- *   NOTE: The first octet of hash is stored in the 0th element,
- *      the last octet of hash in the 19th element.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to use to calculate the SHA-1 hash.
- *   Message_Digest: [out]
- *     Where the digest is returned.
- *
- * Returns:
- *   sha Error Code.
- *
- */
-int USHAResult(USHAContext *ctx,
-               uint8_t Message_Digest[USHAMaxHashSize])
-{
-  if (ctx) {
-    switch (ctx->whichSha) {
-      case SHA1:
-        return SHA1Result((SHA1Context*)&ctx->ctx, Message_Digest);
-      case SHA224:
-        return SHA224Result((SHA224Context*)&ctx->ctx, Message_Digest);
-      case SHA256:
-        return SHA256Result((SHA256Context*)&ctx->ctx, Message_Digest);
-      case SHA384:
-        return SHA384Result((SHA384Context*)&ctx->ctx, Message_Digest);
-      case SHA512:
-        return SHA512Result((SHA512Context*)&ctx->ctx, Message_Digest);
-      default: return shaBadParam;
-    }
-  } else {
-    return shaNull;
-  }
-}
-
-/*
- * USHABlockSize
- *
- * Description:
- *   This function will return the blocksize for the given SHA
- *   algorithm.
- *
- * Parameters:
- *   whichSha:
- *     which SHA algorithm to query
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 70]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *
- * Returns:
- *   block size
- *
- */
-int USHABlockSize(enum SHAversion whichSha)
-{
-  switch (whichSha) {
-    case SHA1:   return SHA1_Message_Block_Size;
-    case SHA224: return SHA224_Message_Block_Size;
-    case SHA256: return SHA256_Message_Block_Size;
-    case SHA384: return SHA384_Message_Block_Size;
-    default:
-    case SHA512: return SHA512_Message_Block_Size;
-  }
-}
-
-/*
- * USHAHashSize
- *
- * Description:
- *   This function will return the hashsize for the given SHA
- *   algorithm.
- *
- * Parameters:
- *   whichSha:
- *     which SHA algorithm to query
- *
- * Returns:
- *   hash size
- *
- */
-int USHAHashSize(enum SHAversion whichSha)
-{
-  switch (whichSha) {
-    case SHA1:   return SHA1HashSize;
-    case SHA224: return SHA224HashSize;
-    case SHA256: return SHA256HashSize;
-    case SHA384: return SHA384HashSize;
-    default:
-    case SHA512: return SHA512HashSize;
-  }
-}
-
-/*
- * USHAHashSizeBits
- *
- * Description:
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 71]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *   This function will return the hashsize for the given SHA
- *   algorithm, expressed in bits.
- *
- * Parameters:
- *   whichSha:
- *     which SHA algorithm to query
- *
- * Returns:
- *   hash size in bits
- *
- */
-int USHAHashSizeBits(enum SHAversion whichSha)
-{
-  switch (whichSha) {
-    case SHA1:   return SHA1HashSizeBits;
-    case SHA224: return SHA224HashSizeBits;
-    case SHA256: return SHA256HashSizeBits;
-    case SHA384: return SHA384HashSizeBits;
-    default:
-    case SHA512: return SHA512HashSizeBits;
-  }
-}
-
-8.2.5.  sha-private.h
-
-/*************************** sha-private.h ***************************/
-/********************** See RFC 4634 for details *********************/
-#ifndef _SHA_PRIVATE__H
-#define _SHA_PRIVATE__H
-/*
- * These definitions are defined in FIPS-180-2, section 4.1.
- * Ch() and Maj() are defined identically in sections 4.1.1,
- * 4.1.2 and 4.1.3.
- *
- * The definitions used in FIPS-180-2 are as follows:
- */
-
-#ifndef USE_MODIFIED_MACROS
-#define SHA_Ch(x,y,z)        (((x) & (y)) ^ ((~(x)) & (z)))
-#define SHA_Maj(x,y,z)       (((x) & (y)) ^ ((x) & (z)) ^ ((y) & (z)))
-
-#else /* USE_MODIFIED_MACROS */
-/*
- * The following definitions are equivalent and potentially faster.
- */
-
-#define SHA_Ch(x, y, z)      (((x) & ((y) ^ (z))) ^ (z))
-#define SHA_Maj(x, y, z)     (((x) & ((y) | (z))) | ((y) & (z)))
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 72]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-#endif /* USE_MODIFIED_MACROS */
-
-#define SHA_Parity(x, y, z)  ((x) ^ (y) ^ (z))
-
-#endif /* _SHA_PRIVATE__H */
-
-8.3 The HMAC Code
-
-/**************************** hmac.c ****************************/
-/******************** See RFC 4634 for details ******************/
-/*
- *  Description:
- *      This file implements the HMAC algorithm (Keyed-Hashing for
- *      Message Authentication, RFC2104), expressed in terms of the
- *      various SHA algorithms.
- */
-
-#include "sha.h"
-
-/*
- *  hmac
- *
- *  Description:
- *      This function will compute an HMAC message digest.
- *
- *  Parameters:
- *      whichSha: [in]
- *          One of SHA1, SHA224, SHA256, SHA384, SHA512
- *      key: [in]
- *          The secret shared key.
- *      key_len: [in]
- *          The length of the secret shared key.
- *      message_array: [in]
- *          An array of characters representing the message.
- *      length: [in]
- *          The length of the message in message_array
- *      digest: [out]
- *          Where the digest is returned.
- *          NOTE: The length of the digest is determined by
- *              the value of whichSha.
- *
- *  Returns:
- *      sha Error Code.
- *
- */
-int hmac(SHAversion whichSha, const unsigned char *text, int text_len,
-    const unsigned char *key, int key_len,
-    uint8_t digest[USHAMaxHashSize])
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 73]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-{
-  HMACContext ctx;
-  return hmacReset(&ctx, whichSha, key, key_len) ||
-         hmacInput(&ctx, text, text_len) ||
-         hmacResult(&ctx, digest);
-}
-
-/*
- *  hmacReset
- *
- *  Description:
- *      This function will initialize the hmacContext in preparation
- *      for computing a new HMAC message digest.
- *
- *  Parameters:
- *      context: [in/out]
- *          The context to reset.
- *      whichSha: [in]
- *          One of SHA1, SHA224, SHA256, SHA384, SHA512
- *      key: [in]
- *          The secret shared key.
- *      key_len: [in]
- *          The length of the secret shared key.
- *
- *  Returns:
- *      sha Error Code.
- *
- */
-int hmacReset(HMACContext *ctx, enum SHAversion whichSha,
-    const unsigned char *key, int key_len)
-{
-  int i, blocksize, hashsize;
-
-  /* inner padding - key XORd with ipad */
-  unsigned char k_ipad[USHA_Max_Message_Block_Size];
-
-  /* temporary buffer when keylen > blocksize */
-  unsigned char tempkey[USHAMaxHashSize];
-
-  if (!ctx) return shaNull;
-
-  blocksize = ctx->blockSize = USHABlockSize(whichSha);
-  hashsize = ctx->hashSize = USHAHashSize(whichSha);
-
-  ctx->whichSha = whichSha;
-
-  /*
-   * If key is longer than the hash blocksize,
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 74]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-   * reset it to key = HASH(key).
-   */
-  if (key_len > blocksize) {
-    USHAContext tctx;
-    int err = USHAReset(&tctx, whichSha) ||
-              USHAInput(&tctx, key, key_len) ||
-              USHAResult(&tctx, tempkey);
-    if (err != shaSuccess) return err;
-
-    key = tempkey;
-    key_len = hashsize;
-  }
-
-  /*
-   * The HMAC transform looks like:
-   *
-   * SHA(K XOR opad, SHA(K XOR ipad, text))
-   *
-   * where K is an n byte key.
-   * ipad is the byte 0x36 repeated blocksize times
-   * opad is the byte 0x5c repeated blocksize times
-   * and text is the data being protected.
-   */
-
-  /* store key into the pads, XOR'd with ipad and opad values */
-  for (i = 0; i < key_len; i++) {
-    k_ipad[i] = key[i] ^ 0x36;
-    ctx->k_opad[i] = key[i] ^ 0x5c;
-  }
-  /* remaining pad bytes are '\0' XOR'd with ipad and opad values */
-  for ( ; i < blocksize; i++) {
-    k_ipad[i] = 0x36;
-    ctx->k_opad[i] = 0x5c;
-  }
-
-  /* perform inner hash */
-  /* init context for 1st pass */
-  return USHAReset(&ctx->shaContext, whichSha) ||
-         /* and start with inner pad */
-         USHAInput(&ctx->shaContext, k_ipad, blocksize);
-}
-
-/*
- *  hmacInput
- *
- *  Description:
- *      This function accepts an array of octets as the next portion
- *      of the message.
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 75]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *
- *  Parameters:
- *      context: [in/out]
- *          The HMAC context to update
- *      message_array: [in]
- *          An array of characters representing the next portion of
- *          the message.
- *      length: [in]
- *          The length of the message in message_array
- *
- *  Returns:
- *      sha Error Code.
- *
- */
-int hmacInput(HMACContext *ctx, const unsigned char *text,
-    int text_len)
-{
-  if (!ctx) return shaNull;
-  /* then text of datagram */
-  return USHAInput(&ctx->shaContext, text, text_len);
-}
-
-/*
- * HMACFinalBits
- *
- * Description:
- *   This function will add in any final bits of the message.
- *
- * Parameters:
- *   context: [in/out]
- *     The HMAC context to update
- *   message_bits: [in]
- *     The final bits of the message, in the upper portion of the
- *     byte. (Use 0b###00000 instead of 0b00000### to input the
- *     three bits ###.)
- *   length: [in]
- *     The number of bits in message_bits, between 1 and 7.
- *
- * Returns:
- *   sha Error Code.
- */
-int hmacFinalBits(HMACContext *ctx,
-    const uint8_t bits,
-    unsigned int bitcount)
-{
-  if (!ctx) return shaNull;
-  /* then final bits of datagram */
-  return USHAFinalBits(&ctx->shaContext, bits, bitcount);
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 76]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-}
-
-/*
- * HMACResult
- *
- * Description:
- *   This function will return the N-byte message digest into the
- *   Message_Digest array provided by the caller.
- *   NOTE: The first octet of hash is stored in the 0th element,
- *      the last octet of hash in the Nth element.
- *
- * Parameters:
- *   context: [in/out]
- *     The context to use to calculate the HMAC hash.
- *   digest: [out]
- *     Where the digest is returned.
- *   NOTE 2: The length of the hash is determined by the value of
- *      whichSha that was passed to hmacReset().
- *
- * Returns:
- *   sha Error Code.
- *
- */
-int hmacResult(HMACContext *ctx, uint8_t *digest)
-{
-  if (!ctx) return shaNull;
-
-  /* finish up 1st pass */
-  /* (Use digest here as a temporary buffer.) */
-  return USHAResult(&ctx->shaContext, digest) ||
-
-         /* perform outer SHA */
-         /* init context for 2nd pass */
-         USHAReset(&ctx->shaContext, ctx->whichSha) ||
-
-         /* start with outer pad */
-         USHAInput(&ctx->shaContext, ctx->k_opad, ctx->blockSize) ||
-
-         /* then results of 1st hash */
-         USHAInput(&ctx->shaContext, digest, ctx->hashSize) ||
-
-         /* finish up 2nd pass */
-         USHAResult(&ctx->shaContext, digest);
-}
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 77]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-8.4.  The Test Driver
-
-   The following code is a main program test driver to exercise the code
-   in sha1.c, sha224-256.c, and sha384-512.c.  The test driver can also
-   be used as a stand-alone program for generating the hashes.
-
-   See also [RFC2202], [RFC4231], and [SHAVS].
-
-/**************************** shatest.c ****************************/
-/********************* See RFC 4634 for details ********************/
-/*
- *  Description:
- *    This file will exercise the SHA code performing
- *      the three tests documented in FIPS PUB 180-2
- *        (http://csrc.nist.gov/publications/fips/
- *         fips180-2/fips180-2withchangenotice.pdf)
- *      one that calls SHAInput with an exact multiple of 512 bits
- *      the seven tests documented for each algorithm in
- *        "The Secure Hash Algorithm Validation System (SHAVS)",
- *        three of which are bit-level tests
- *        (http://csrc.nist.gov/cryptval/shs/SHAVS.pdf)
- *
- *    This file will exercise the HMAC SHA1 code performing
- *      the seven tests documented in RFCs 2202 and 4231.
- *
- *    To run the tests and just see PASSED/FAILED, use the -p option.
- *
- *    Other options exercise:
- *      hashing an arbitrary string
- *      hashing a file's contents
- *      a few error test checks
- *      printing the results in raw format
- *
- *  Portability Issues:
- *    None.
- *
- */
-
-#include <stdint.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <ctype.h>
-#include "sha.h"
-
-static int xgetopt(int argc, char **argv, const char *optstring);
-extern char *xoptarg;
-static int scasecmp(const char *s1, const char *s2);
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 78]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-/*
- *  Define patterns for testing
- */
-#define TEST1    "abc"
-#define TEST2_1  \
-        "abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq"
-#define TEST2_2a \
-        "abcdefghbcdefghicdefghijdefghijkefghijklfghijklmghijklmn"
-#define TEST2_2b \
-        "hijklmnoijklmnopjklmnopqklmnopqrlmnopqrsmnopqrstnopqrstu"
-#define TEST2_2  TEST2_2a TEST2_2b
-#define TEST3    "a"                            /* times 1000000 */
-#define TEST4a   "01234567012345670123456701234567"
-#define TEST4b   "01234567012345670123456701234567"
-    /* an exact multiple of 512 bits */
-#define TEST4   TEST4a TEST4b                   /* times 10 */
-
-#define TEST7_1 \
-  "\x49\xb2\xae\xc2\x59\x4b\xbe\x3a\x3b\x11\x75\x42\xd9\x4a\xc8"
-#define TEST8_1 \
-  "\x9a\x7d\xfd\xf1\xec\xea\xd0\x6e\xd6\x46\xaa\x55\xfe\x75\x71\x46"
-#define TEST9_1 \
-  "\x65\xf9\x32\x99\x5b\xa4\xce\x2c\xb1\xb4\xa2\xe7\x1a\xe7\x02\x20" \
-  "\xaa\xce\xc8\x96\x2d\xd4\x49\x9c\xbd\x7c\x88\x7a\x94\xea\xaa\x10" \
-  "\x1e\xa5\xaa\xbc\x52\x9b\x4e\x7e\x43\x66\x5a\x5a\xf2\xcd\x03\xfe" \
-  "\x67\x8e\xa6\xa5\x00\x5b\xba\x3b\x08\x22\x04\xc2\x8b\x91\x09\xf4" \
-  "\x69\xda\xc9\x2a\xaa\xb3\xaa\x7c\x11\xa1\xb3\x2a"
-#define TEST10_1 \
-  "\xf7\x8f\x92\x14\x1b\xcd\x17\x0a\xe8\x9b\x4f\xba\x15\xa1\xd5\x9f" \
-  "\x3f\xd8\x4d\x22\x3c\x92\x51\xbd\xac\xbb\xae\x61\xd0\x5e\xd1\x15" \
-  "\xa0\x6a\x7c\xe1\x17\xb7\xbe\xea\xd2\x44\x21\xde\xd9\xc3\x25\x92" \
-  "\xbd\x57\xed\xea\xe3\x9c\x39\xfa\x1f\xe8\x94\x6a\x84\xd0\xcf\x1f" \
-  "\x7b\xee\xad\x17\x13\xe2\xe0\x95\x98\x97\x34\x7f\x67\xc8\x0b\x04" \
-  "\x00\xc2\x09\x81\x5d\x6b\x10\xa6\x83\x83\x6f\xd5\x56\x2a\x56\xca" \
-  "\xb1\xa2\x8e\x81\xb6\x57\x66\x54\x63\x1c\xf1\x65\x66\xb8\x6e\x3b" \
-  "\x33\xa1\x08\xb0\x53\x07\xc0\x0a\xff\x14\xa7\x68\xed\x73\x50\x60" \
-  "\x6a\x0f\x85\xe6\xa9\x1d\x39\x6f\x5b\x5c\xbe\x57\x7f\x9b\x38\x80" \
-  "\x7c\x7d\x52\x3d\x6d\x79\x2f\x6e\xbc\x24\xa4\xec\xf2\xb3\xa4\x27" \
-  "\xcd\xbb\xfb"
-#define TEST7_224 \
-  "\xf0\x70\x06\xf2\x5a\x0b\xea\x68\xcd\x76\xa2\x95\x87\xc2\x8d"
-#define TEST8_224 \
-  "\x18\x80\x40\x05\xdd\x4f\xbd\x15\x56\x29\x9d\x6f\x9d\x93\xdf\x62"
-#define TEST9_224 \
-  "\xa2\xbe\x6e\x46\x32\x81\x09\x02\x94\xd9\xce\x94\x82\x65\x69\x42" \
-  "\x3a\x3a\x30\x5e\xd5\xe2\x11\x6c\xd4\xa4\xc9\x87\xfc\x06\x57\x00" \
-  "\x64\x91\xb1\x49\xcc\xd4\xb5\x11\x30\xac\x62\xb1\x9d\xc2\x48\xc7" \
-  "\x44\x54\x3d\x20\xcd\x39\x52\xdc\xed\x1f\x06\xcc\x3b\x18\xb9\x1f" \
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 79]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  "\x3f\x55\x63\x3e\xcc\x30\x85\xf4\x90\x70\x60\xd2"
-#define TEST10_224 \
-  "\x55\xb2\x10\x07\x9c\x61\xb5\x3a\xdd\x52\x06\x22\xd1\xac\x97\xd5" \
-  "\xcd\xbe\x8c\xb3\x3a\xa0\xae\x34\x45\x17\xbe\xe4\xd7\xba\x09\xab" \
-  "\xc8\x53\x3c\x52\x50\x88\x7a\x43\xbe\xbb\xac\x90\x6c\x2e\x18\x37" \
-  "\xf2\x6b\x36\xa5\x9a\xe3\xbe\x78\x14\xd5\x06\x89\x6b\x71\x8b\x2a" \
-  "\x38\x3e\xcd\xac\x16\xb9\x61\x25\x55\x3f\x41\x6f\xf3\x2c\x66\x74" \
-  "\xc7\x45\x99\xa9\x00\x53\x86\xd9\xce\x11\x12\x24\x5f\x48\xee\x47" \
-  "\x0d\x39\x6c\x1e\xd6\x3b\x92\x67\x0c\xa5\x6e\xc8\x4d\xee\xa8\x14" \
-  "\xb6\x13\x5e\xca\x54\x39\x2b\xde\xdb\x94\x89\xbc\x9b\x87\x5a\x8b" \
-  "\xaf\x0d\xc1\xae\x78\x57\x36\x91\x4a\xb7\xda\xa2\x64\xbc\x07\x9d" \
-  "\x26\x9f\x2c\x0d\x7e\xdd\xd8\x10\xa4\x26\x14\x5a\x07\x76\xf6\x7c" \
-  "\x87\x82\x73"
-#define TEST7_256 \
-  "\xbe\x27\x46\xc6\xdb\x52\x76\x5f\xdb\x2f\x88\x70\x0f\x9a\x73"
-#define TEST8_256 \
-  "\xe3\xd7\x25\x70\xdc\xdd\x78\x7c\xe3\x88\x7a\xb2\xcd\x68\x46\x52"
-#define TEST9_256 \
-  "\x3e\x74\x03\x71\xc8\x10\xc2\xb9\x9f\xc0\x4e\x80\x49\x07\xef\x7c" \
-  "\xf2\x6b\xe2\x8b\x57\xcb\x58\xa3\xe2\xf3\xc0\x07\x16\x6e\x49\xc1" \
-  "\x2e\x9b\xa3\x4c\x01\x04\x06\x91\x29\xea\x76\x15\x64\x25\x45\x70" \
-  "\x3a\x2b\xd9\x01\xe1\x6e\xb0\xe0\x5d\xeb\xa0\x14\xeb\xff\x64\x06" \
-  "\xa0\x7d\x54\x36\x4e\xff\x74\x2d\xa7\x79\xb0\xb3"
-#define TEST10_256 \
-  "\x83\x26\x75\x4e\x22\x77\x37\x2f\x4f\xc1\x2b\x20\x52\x7a\xfe\xf0" \
-  "\x4d\x8a\x05\x69\x71\xb1\x1a\xd5\x71\x23\xa7\xc1\x37\x76\x00\x00" \
-  "\xd7\xbe\xf6\xf3\xc1\xf7\xa9\x08\x3a\xa3\x9d\x81\x0d\xb3\x10\x77" \
-  "\x7d\xab\x8b\x1e\x7f\x02\xb8\x4a\x26\xc7\x73\x32\x5f\x8b\x23\x74" \
-  "\xde\x7a\x4b\x5a\x58\xcb\x5c\x5c\xf3\x5b\xce\xe6\xfb\x94\x6e\x5b" \
-  "\xd6\x94\xfa\x59\x3a\x8b\xeb\x3f\x9d\x65\x92\xec\xed\xaa\x66\xca" \
-  "\x82\xa2\x9d\x0c\x51\xbc\xf9\x33\x62\x30\xe5\xd7\x84\xe4\xc0\xa4" \
-  "\x3f\x8d\x79\xa3\x0a\x16\x5c\xba\xbe\x45\x2b\x77\x4b\x9c\x71\x09" \
-  "\xa9\x7d\x13\x8f\x12\x92\x28\x96\x6f\x6c\x0a\xdc\x10\x6a\xad\x5a" \
-  "\x9f\xdd\x30\x82\x57\x69\xb2\xc6\x71\xaf\x67\x59\xdf\x28\xeb\x39" \
-  "\x3d\x54\xd6"
-#define TEST7_384 \
-  "\x8b\xc5\x00\xc7\x7c\xee\xd9\x87\x9d\xa9\x89\x10\x7c\xe0\xaa"
-#define TEST8_384 \
-  "\xa4\x1c\x49\x77\x79\xc0\x37\x5f\xf1\x0a\x7f\x4e\x08\x59\x17\x39"
-#define TEST9_384 \
-  "\x68\xf5\x01\x79\x2d\xea\x97\x96\x76\x70\x22\xd9\x3d\xa7\x16\x79" \
-  "\x30\x99\x20\xfa\x10\x12\xae\xa3\x57\xb2\xb1\x33\x1d\x40\xa1\xd0" \
-  "\x3c\x41\xc2\x40\xb3\xc9\xa7\x5b\x48\x92\xf4\xc0\x72\x4b\x68\xc8" \
-  "\x75\x32\x1a\xb8\xcf\xe5\x02\x3b\xd3\x75\xbc\x0f\x94\xbd\x89\xfe" \
-  "\x04\xf2\x97\x10\x5d\x7b\x82\xff\xc0\x02\x1a\xeb\x1c\xcb\x67\x4f" \
-  "\x52\x44\xea\x34\x97\xde\x26\xa4\x19\x1c\x5f\x62\xe5\xe9\xa2\xd8" \
-  "\x08\x2f\x05\x51\xf4\xa5\x30\x68\x26\xe9\x1c\xc0\x06\xce\x1b\xf6" \
-  "\x0f\xf7\x19\xd4\x2f\xa5\x21\xc8\x71\xcd\x23\x94\xd9\x6e\xf4\x46" \
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 80]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  "\x8f\x21\x96\x6b\x41\xf2\xba\x80\xc2\x6e\x83\xa9"
-#define TEST10_384 \
-  "\x39\x96\x69\xe2\x8f\x6b\x9c\x6d\xbc\xbb\x69\x12\xec\x10\xff\xcf" \
-  "\x74\x79\x03\x49\xb7\xdc\x8f\xbe\x4a\x8e\x7b\x3b\x56\x21\xdb\x0f" \
-  "\x3e\x7d\xc8\x7f\x82\x32\x64\xbb\xe4\x0d\x18\x11\xc9\xea\x20\x61" \
-  "\xe1\xc8\x4a\xd1\x0a\x23\xfa\xc1\x72\x7e\x72\x02\xfc\x3f\x50\x42" \
-  "\xe6\xbf\x58\xcb\xa8\xa2\x74\x6e\x1f\x64\xf9\xb9\xea\x35\x2c\x71" \
-  "\x15\x07\x05\x3c\xf4\xe5\x33\x9d\x52\x86\x5f\x25\xcc\x22\xb5\xe8" \
-  "\x77\x84\xa1\x2f\xc9\x61\xd6\x6c\xb6\xe8\x95\x73\x19\x9a\x2c\xe6" \
-  "\x56\x5c\xbd\xf1\x3d\xca\x40\x38\x32\xcf\xcb\x0e\x8b\x72\x11\xe8" \
-  "\x3a\xf3\x2a\x11\xac\x17\x92\x9f\xf1\xc0\x73\xa5\x1c\xc0\x27\xaa" \
-  "\xed\xef\xf8\x5a\xad\x7c\x2b\x7c\x5a\x80\x3e\x24\x04\xd9\x6d\x2a" \
-  "\x77\x35\x7b\xda\x1a\x6d\xae\xed\x17\x15\x1c\xb9\xbc\x51\x25\xa4" \
-  "\x22\xe9\x41\xde\x0c\xa0\xfc\x50\x11\xc2\x3e\xcf\xfe\xfd\xd0\x96" \
-  "\x76\x71\x1c\xf3\xdb\x0a\x34\x40\x72\x0e\x16\x15\xc1\xf2\x2f\xbc" \
-  "\x3c\x72\x1d\xe5\x21\xe1\xb9\x9b\xa1\xbd\x55\x77\x40\x86\x42\x14" \
-  "\x7e\xd0\x96"
-#define TEST7_512 \
-  "\x08\xec\xb5\x2e\xba\xe1\xf7\x42\x2d\xb6\x2b\xcd\x54\x26\x70"
-#define TEST8_512 \
-  "\x8d\x4e\x3c\x0e\x38\x89\x19\x14\x91\x81\x6e\x9d\x98\xbf\xf0\xa0"
-#define TEST9_512 \
-  "\x3a\xdd\xec\x85\x59\x32\x16\xd1\x61\x9a\xa0\x2d\x97\x56\x97\x0b" \
-  "\xfc\x70\xac\xe2\x74\x4f\x7c\x6b\x27\x88\x15\x10\x28\xf7\xb6\xa2" \
-  "\x55\x0f\xd7\x4a\x7e\x6e\x69\xc2\xc9\xb4\x5f\xc4\x54\x96\x6d\xc3" \
-  "\x1d\x2e\x10\xda\x1f\x95\xce\x02\xbe\xb4\xbf\x87\x65\x57\x4c\xbd" \
-  "\x6e\x83\x37\xef\x42\x0a\xdc\x98\xc1\x5c\xb6\xd5\xe4\xa0\x24\x1b" \
-  "\xa0\x04\x6d\x25\x0e\x51\x02\x31\xca\xc2\x04\x6c\x99\x16\x06\xab" \
-  "\x4e\xe4\x14\x5b\xee\x2f\xf4\xbb\x12\x3a\xab\x49\x8d\x9d\x44\x79" \
-  "\x4f\x99\xcc\xad\x89\xa9\xa1\x62\x12\x59\xed\xa7\x0a\x5b\x6d\xd4" \
-  "\xbd\xd8\x77\x78\xc9\x04\x3b\x93\x84\xf5\x49\x06"
-#define TEST10_512 \
-  "\xa5\x5f\x20\xc4\x11\xaa\xd1\x32\x80\x7a\x50\x2d\x65\x82\x4e\x31" \
-  "\xa2\x30\x54\x32\xaa\x3d\x06\xd3\xe2\x82\xa8\xd8\x4e\x0d\xe1\xde" \
-  "\x69\x74\xbf\x49\x54\x69\xfc\x7f\x33\x8f\x80\x54\xd5\x8c\x26\xc4" \
-  "\x93\x60\xc3\xe8\x7a\xf5\x65\x23\xac\xf6\xd8\x9d\x03\xe5\x6f\xf2" \
-  "\xf8\x68\x00\x2b\xc3\xe4\x31\xed\xc4\x4d\xf2\xf0\x22\x3d\x4b\xb3" \
-  "\xb2\x43\x58\x6e\x1a\x7d\x92\x49\x36\x69\x4f\xcb\xba\xf8\x8d\x95" \
-  "\x19\xe4\xeb\x50\xa6\x44\xf8\xe4\xf9\x5e\xb0\xea\x95\xbc\x44\x65" \
-  "\xc8\x82\x1a\xac\xd2\xfe\x15\xab\x49\x81\x16\x4b\xbb\x6d\xc3\x2f" \
-  "\x96\x90\x87\xa1\x45\xb0\xd9\xcc\x9c\x67\xc2\x2b\x76\x32\x99\x41" \
-  "\x9c\xc4\x12\x8b\xe9\xa0\x77\xb3\xac\xe6\x34\x06\x4e\x6d\x99\x28" \
-  "\x35\x13\xdc\x06\xe7\x51\x5d\x0d\x73\x13\x2e\x9a\x0d\xc6\xd3\xb1" \
-  "\xf8\xb2\x46\xf1\xa9\x8a\x3f\xc7\x29\x41\xb1\xe3\xbb\x20\x98\xe8" \
-  "\xbf\x16\xf2\x68\xd6\x4f\x0b\x0f\x47\x07\xfe\x1e\xa1\xa1\x79\x1b" \
-  "\xa2\xf3\xc0\xc7\x58\xe5\xf5\x51\x86\x3a\x96\xc9\x49\xad\x47\xd7" \
-  "\xfb\x40\xd2"
-#define SHA1_SEED "\xd0\x56\x9c\xb3\x66\x5a\x8a\x43\xeb\x6e\xa2\x3d" \
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 81]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  "\x75\xa3\xc4\xd2\x05\x4a\x0d\x7d"
-#define SHA224_SEED "\xd0\x56\x9c\xb3\x66\x5a\x8a\x43\xeb\x6e\xa2" \
-  "\x3d\x75\xa3\xc4\xd2\x05\x4a\x0d\x7d\x66\xa9\xca\x99\xc9\xce\xb0" \
-  "\x27"
-#define SHA256_SEED "\xf4\x1e\xce\x26\x13\xe4\x57\x39\x15\x69\x6b" \
-  "\x5a\xdc\xd5\x1c\xa3\x28\xbe\x3b\xf5\x66\xa9\xca\x99\xc9\xce\xb0" \
-  "\x27\x9c\x1c\xb0\xa7"
-#define SHA384_SEED "\x82\x40\xbc\x51\xe4\xec\x7e\xf7\x6d\x18\xe3" \
-  "\x52\x04\xa1\x9f\x51\xa5\x21\x3a\x73\xa8\x1d\x6f\x94\x46\x80\xd3" \
-  "\x07\x59\x48\xb7\xe4\x63\x80\x4e\xa3\xd2\x6e\x13\xea\x82\x0d\x65" \
-  "\xa4\x84\xbe\x74\x53"
-#define SHA512_SEED "\x47\x3f\xf1\xb9\xb3\xff\xdf\xa1\x26\x69\x9a" \
-  "\xc7\xef\x9e\x8e\x78\x77\x73\x09\x58\x24\xc6\x42\x55\x7c\x13\x99" \
-  "\xd9\x8e\x42\x20\x44\x8d\xc3\x5b\x99\xbf\xdd\x44\x77\x95\x43\x92" \
-  "\x4c\x1c\xe9\x3b\xc5\x94\x15\x38\x89\x5d\xb9\x88\x26\x1b\x00\x77" \
-  "\x4b\x12\x27\x20\x39"
-
-#define TESTCOUNT 10
-#define HASHCOUNT 5
-#define RANDOMCOUNT 4
-#define HMACTESTCOUNT 7
-
-#define PRINTNONE 0
-#define PRINTTEXT 1
-#define PRINTRAW 2
-#define PRINTHEX 3
-#define PRINTBASE64 4
-
-#define PRINTPASSFAIL 1
-#define PRINTFAIL 2
-
-#define length(x) (sizeof(x)-1)
-
-/* Test arrays for hashes. */
-struct hash {
-    const char *name;
-    SHAversion whichSha;
-    int hashsize;
-    struct {
-        const char *testarray;
-        int length;
-        long repeatcount;
-        int extrabits;
-        int numberExtrabits;
-        const char *resultarray;
-    } tests[TESTCOUNT];
-    const char *randomtest;
-    const char *randomresults[RANDOMCOUNT];
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 82]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-} hashes[HASHCOUNT] = {
-  { "SHA1", SHA1, SHA1HashSize,
-    {
-      /* 1 */ { TEST1, length(TEST1), 1, 0, 0,
-        "A9993E364706816ABA3E25717850C26C9CD0D89D" },
-      /* 2 */ { TEST2_1, length(TEST2_1), 1, 0, 0,
-        "84983E441C3BD26EBAAE4AA1F95129E5E54670F1" },
-      /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0,
-        "34AA973CD4C4DAA4F61EEB2BDBAD27316534016F" },
-      /* 4 */ { TEST4, length(TEST4), 10, 0, 0,
-        "DEA356A2CDDD90C7A7ECEDC5EBB563934F460452" },
-      /* 5 */ { "", 0, 0, 0x98, 5,
-        "29826B003B906E660EFF4027CE98AF3531AC75BA" },
-      /* 6 */ { "\x5e", 1, 1, 0, 0,
-        "5E6F80A34A9798CAFC6A5DB96CC57BA4C4DB59C2" },
-      /* 7 */ { TEST7_1, length(TEST7_1), 1, 0x80, 3,
-        "6239781E03729919C01955B3FFA8ACB60B988340" },
-      /* 8 */ { TEST8_1, length(TEST8_1), 1, 0, 0,
-        "82ABFF6605DBE1C17DEF12A394FA22A82B544A35" },
-      /* 9 */ { TEST9_1, length(TEST9_1), 1, 0xE0, 3,
-        "8C5B2A5DDAE5A97FC7F9D85661C672ADBF7933D4" },
-      /* 10 */ { TEST10_1, length(TEST10_1), 1, 0, 0,
-        "CB0082C8F197D260991BA6A460E76E202BAD27B3" }
-    }, SHA1_SEED, { "E216836819477C7F78E0D843FE4FF1B6D6C14CD4",
-        "A2DBC7A5B1C6C0A8BCB7AAA41252A6A7D0690DBC",
-        "DB1F9050BB863DFEF4CE37186044E2EEB17EE013",
-        "127FDEDF43D372A51D5747C48FBFFE38EF6CDF7B"
-     } },
-  { "SHA224", SHA224, SHA224HashSize,
-    {
-      /* 1 */ { TEST1, length(TEST1), 1, 0, 0,
-        "23097D223405D8228642A477BDA255B32AADBCE4BDA0B3F7E36C9DA7" },
-      /* 2 */ { TEST2_1, length(TEST2_1), 1, 0, 0,
-        "75388B16512776CC5DBA5DA1FD890150B0C6455CB4F58B1952522525" },
-      /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0,
-        "20794655980C91D8BBB4C1EA97618A4BF03F42581948B2EE4EE7AD67" },
-      /* 4 */ { TEST4, length(TEST4), 10, 0, 0,
-        "567F69F168CD7844E65259CE658FE7AADFA25216E68ECA0EB7AB8262" },
-      /* 5 */ { "", 0, 0, 0x68, 5,
-        "E3B048552C3C387BCAB37F6EB06BB79B96A4AEE5FF27F51531A9551C" },
-      /* 6 */ { "\x07", 1, 1, 0, 0,
-        "00ECD5F138422B8AD74C9799FD826C531BAD2FCABC7450BEE2AA8C2A" },
-      /* 7 */ { TEST7_224, length(TEST7_224), 1, 0xA0, 3,
-        "1B01DB6CB4A9E43DED1516BEB3DB0B87B6D1EA43187462C608137150" },
-      /* 8 */ { TEST8_224, length(TEST8_224), 1, 0, 0,
-        "DF90D78AA78821C99B40BA4C966921ACCD8FFB1E98AC388E56191DB1" },
-      /* 9 */ { TEST9_224, length(TEST9_224), 1, 0xE0, 3,
-        "54BEA6EAB8195A2EB0A7906A4B4A876666300EEFBD1F3B8474F9CD57" },
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 83]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      /* 10 */ { TEST10_224, length(TEST10_224), 1, 0, 0,
-        "0B31894EC8937AD9B91BDFBCBA294D9ADEFAA18E09305E9F20D5C3A4" }
-    }, SHA224_SEED, { "100966A5B4FDE0B42E2A6C5953D4D7F41BA7CF79FD"
-        "2DF431416734BE", "1DCA396B0C417715DEFAAE9641E10A2E99D55A"
-        "BCB8A00061EB3BE8BD", "1864E627BDB2319973CD5ED7D68DA71D8B"
-        "F0F983D8D9AB32C34ADB34", "A2406481FC1BCAF24DD08E6752E844"
-        "709563FB916227FED598EB621F"
-     } },
-  { "SHA256", SHA256, SHA256HashSize,
-  {
-      /* 1 */ { TEST1, length(TEST1), 1, 0, 0, "BA7816BF8F01CFEA4141"
-        "40DE5DAE2223B00361A396177A9CB410FF61F20015AD" },
-      /* 2 */ { TEST2_1, length(TEST2_1), 1, 0, 0, "248D6A61D20638B8"
-        "E5C026930C3E6039A33CE45964FF2167F6ECEDD419DB06C1" },
-      /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0, "CDC76E5C9914FB92"
-        "81A1C7E284D73E67F1809A48A497200E046D39CCC7112CD0" },
-      /* 4 */ { TEST4, length(TEST4), 10, 0, 0, "594847328451BDFA"
-        "85056225462CC1D867D877FB388DF0CE35F25AB5562BFBB5" },
-      /* 5 */ { "", 0, 0, 0x68, 5, "D6D3E02A31A84A8CAA9718ED6C2057BE"
-        "09DB45E7823EB5079CE7A573A3760F95" },
-      /* 6 */ { "\x19", 1, 1, 0, 0, "68AA2E2EE5DFF96E3355E6C7EE373E3D"
-        "6A4E17F75F9518D843709C0C9BC3E3D4" },
-      /* 7 */ { TEST7_256, length(TEST7_256), 1, 0x60, 3, "77EC1DC8"
-        "9C821FF2A1279089FA091B35B8CD960BCAF7DE01C6A7680756BEB972" },
-      /* 8 */ { TEST8_256, length(TEST8_256), 1, 0, 0, "175EE69B02BA"
-        "9B58E2B0A5FD13819CEA573F3940A94F825128CF4209BEABB4E8" },
-      /* 9 */ { TEST9_256, length(TEST9_256), 1, 0xA0, 3, "3E9AD646"
-        "8BBBAD2AC3C2CDC292E018BA5FD70B960CF1679777FCE708FDB066E9" },
-      /* 10 */ { TEST10_256, length(TEST10_256), 1, 0, 0, "97DBCA7D"
-        "F46D62C8A422C941DD7E835B8AD3361763F7E9B2D95F4F0DA6E1CCBC" },
-    }, SHA256_SEED, { "83D28614D49C3ADC1D6FC05DB5F48037C056F8D2A4CE44"
-        "EC6457DEA5DD797CD1", "99DBE3127EF2E93DD9322D6A07909EB33B6399"
-        "5E529B3F954B8581621BB74D39", "8D4BE295BB64661CA3C7EFD129A2F7"
-        "25B33072DBDDE32385B9A87B9AF88EA76F", "40AF5D3F9716B040DF9408"
-        "E31536B70FF906EC51B00447CA97D7DD97C12411F4"
-    } },
-  { "SHA384", SHA384, SHA384HashSize,
-    {
-      /* 1 */ { TEST1, length(TEST1), 1, 0, 0,
-        "CB00753F45A35E8BB5A03D699AC65007272C32AB0EDED163"
-        "1A8B605A43FF5BED8086072BA1E7CC2358BAECA134C825A7" },
-      /* 2 */ { TEST2_2, length(TEST2_2), 1, 0, 0,
-        "09330C33F71147E83D192FC782CD1B4753111B173B3B05D2"
-        "2FA08086E3B0F712FCC7C71A557E2DB966C3E9FA91746039" },
-      /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0,
-        "9D0E1809716474CB086E834E310A4A1CED149E9C00F24852"
-        "7972CEC5704C2A5B07B8B3DC38ECC4EBAE97DDD87F3D8985" },
-      /* 4 */ { TEST4, length(TEST4), 10, 0, 0,
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 84]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-        "2FC64A4F500DDB6828F6A3430B8DD72A368EB7F3A8322A70"
-        "BC84275B9C0B3AB00D27A5CC3C2D224AA6B61A0D79FB4596" },
-      /* 5 */ { "", 0, 0, 0x10, 5,
-        "8D17BE79E32B6718E07D8A603EB84BA0478F7FCFD1BB9399"
-        "5F7D1149E09143AC1FFCFC56820E469F3878D957A15A3FE4" },
-      /* 6 */ { "\xb9", 1, 1, 0, 0,
-        "BC8089A19007C0B14195F4ECC74094FEC64F01F90929282C"
-        "2FB392881578208AD466828B1C6C283D2722CF0AD1AB6938" },
-      /* 7 */ { TEST7_384, length(TEST7_384), 1, 0xA0, 3,
-        "D8C43B38E12E7C42A7C9B810299FD6A770BEF30920F17532"
-        "A898DE62C7A07E4293449C0B5FA70109F0783211CFC4BCE3" },
-      /* 8 */ { TEST8_384, length(TEST8_384), 1, 0, 0,
-        "C9A68443A005812256B8EC76B00516F0DBB74FAB26D66591"
-        "3F194B6FFB0E91EA9967566B58109CBC675CC208E4C823F7" },
-      /* 9 */ { TEST9_384, length(TEST9_384), 1, 0xE0, 3,
-        "5860E8DE91C21578BB4174D227898A98E0B45C4C760F0095"
-        "49495614DAEDC0775D92D11D9F8CE9B064EEAC8DAFC3A297" },
-      /* 10 */ { TEST10_384, length(TEST10_384), 1, 0, 0,
-        "4F440DB1E6EDD2899FA335F09515AA025EE177A79F4B4AAF"
-        "38E42B5C4DE660F5DE8FB2A5B2FBD2A3CBFFD20CFF1288C0" }
-    }, SHA384_SEED, { "CE44D7D63AE0C91482998CF662A51EC80BF6FC68661A3C"
-        "57F87566112BD635A743EA904DEB7D7A42AC808CABE697F38F", "F9C6D2"
-        "61881FEE41ACD39E67AA8D0BAD507C7363EB67E2B81F45759F9C0FD7B503"
-        "DF1A0B9E80BDE7BC333D75B804197D", "D96512D8C9F4A7A4967A366C01"
-        "C6FD97384225B58343A88264847C18E4EF8AB7AEE4765FFBC3E30BD485D3"
-        "638A01418F", "0CA76BD0813AF1509E170907A96005938BC985628290B2"
-        "5FEF73CF6FAD68DDBA0AC8920C94E0541607B0915A7B4457F7"
-    } },
-  { "SHA512", SHA512, SHA512HashSize,
-    {
-      /* 1 */ { TEST1, length(TEST1), 1, 0, 0,
-        "DDAF35A193617ABACC417349AE20413112E6FA4E89A97EA2"
-        "0A9EEEE64B55D39A2192992A274FC1A836BA3C23A3FEEBBD"
-        "454D4423643CE80E2A9AC94FA54CA49F" },
-      /* 2 */ { TEST2_2, length(TEST2_2), 1, 0, 0,
-        "8E959B75DAE313DA8CF4F72814FC143F8F7779C6EB9F7FA1"
-        "7299AEADB6889018501D289E4900F7E4331B99DEC4B5433A"
-        "C7D329EEB6DD26545E96E55B874BE909" },
-       /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0,
-        "E718483D0CE769644E2E42C7BC15B4638E1F98B13B204428"
-        "5632A803AFA973EBDE0FF244877EA60A4CB0432CE577C31B"
-        "EB009C5C2C49AA2E4EADB217AD8CC09B" },
-      /* 4 */ { TEST4, length(TEST4), 10, 0, 0,
-        "89D05BA632C699C31231DED4FFC127D5A894DAD412C0E024"
-        "DB872D1ABD2BA8141A0F85072A9BE1E2AA04CF33C765CB51"
-        "0813A39CD5A84C4ACAA64D3F3FB7BAE9" },
-      /* 5 */ { "", 0, 0, 0xB0, 5,
-        "D4EE29A9E90985446B913CF1D1376C836F4BE2C1CF3CADA0"
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 85]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-        "720A6BF4857D886A7ECB3C4E4C0FA8C7F95214E41DC1B0D2"
-        "1B22A84CC03BF8CE4845F34DD5BDBAD4" },
-      /* 6 */ { "\xD0", 1, 1, 0, 0,
-        "9992202938E882E73E20F6B69E68A0A7149090423D93C81B"
-        "AB3F21678D4ACEEEE50E4E8CAFADA4C85A54EA8306826C4A"
-        "D6E74CECE9631BFA8A549B4AB3FBBA15" },
-      /* 7 */ { TEST7_512, length(TEST7_512), 1, 0x80, 3,
-        "ED8DC78E8B01B69750053DBB7A0A9EDA0FB9E9D292B1ED71"
-        "5E80A7FE290A4E16664FD913E85854400C5AF05E6DAD316B"
-        "7359B43E64F8BEC3C1F237119986BBB6" },
-      /* 8 */ { TEST8_512, length(TEST8_512), 1, 0, 0,
-        "CB0B67A4B8712CD73C9AABC0B199E9269B20844AFB75ACBD"
-        "D1C153C9828924C3DDEDAAFE669C5FDD0BC66F630F677398"
-        "8213EB1B16F517AD0DE4B2F0C95C90F8" },
-      /* 9 */ { TEST9_512, length(TEST9_512), 1, 0x80, 3,
-        "32BA76FC30EAA0208AEB50FFB5AF1864FDBF17902A4DC0A6"
-        "82C61FCEA6D92B783267B21080301837F59DE79C6B337DB2"
-        "526F8A0A510E5E53CAFED4355FE7C2F1" },
-      /* 10 */ { TEST10_512, length(TEST10_512), 1, 0, 0,
-        "C665BEFB36DA189D78822D10528CBF3B12B3EEF726039909"
-        "C1A16A270D48719377966B957A878E720584779A62825C18"
-        "DA26415E49A7176A894E7510FD1451F5" }
-    }, SHA512_SEED, { "2FBB1E7E00F746BA514FBC8C421F36792EC0E11FF5EFC3"
-        "78E1AB0C079AA5F0F66A1E3EDBAEB4F9984BE14437123038A452004A5576"
-        "8C1FD8EED49E4A21BEDCD0", "25CBE5A4F2C7B1D7EF07011705D50C62C5"
-        "000594243EAFD1241FC9F3D22B58184AE2FEE38E171CF8129E29459C9BC2"
-        "EF461AF5708887315F15419D8D17FE7949", "5B8B1F2687555CE2D7182B"
-        "92E5C3F6C36547DA1C13DBB9EA4F73EA4CBBAF89411527906D35B1B06C1B"
-        "6A8007D05EC66DF0A406066829EAB618BDE3976515AAFC", "46E36B007D"
-        "19876CDB0B29AD074FE3C08CDD174D42169D6ABE5A1414B6E79707DF5877"
-        "6A98091CF431854147BB6D3C66D43BFBC108FD715BDE6AA127C2B0E79F"
-    }
-  }
-};
-
-/* Test arrays for HMAC. */
-struct hmachash {
-    const char *keyarray[5];
-    int keylength[5];
-    const char *dataarray[5];
-    int datalength[5];
-    const char *resultarray[5];
-    int resultlength[5];
-} hmachashes[HMACTESTCOUNT] = {
-  { /* 1 */ {
-      "\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b"
-      "\x0b\x0b\x0b\x0b\x0b"
-    }, { 20 }, {
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 86]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      "\x48\x69\x20\x54\x68\x65\x72\x65" /* "Hi There" */
-    }, { 8 }, {
-      /* HMAC-SHA-1 */
-      "B617318655057264E28BC0B6FB378C8EF146BE00",
-      /* HMAC-SHA-224 */
-      "896FB1128ABBDF196832107CD49DF33F47B4B1169912BA4F53684B22",
-      /* HMAC-SHA-256 */
-      "B0344C61D8DB38535CA8AFCEAF0BF12B881DC200C9833DA726E9376C2E32"
-      "CFF7",
-      /* HMAC-SHA-384 */
-      "AFD03944D84895626B0825F4AB46907F15F9DADBE4101EC682AA034C7CEB"
-      "C59CFAEA9EA9076EDE7F4AF152E8B2FA9CB6",
-      /* HMAC-SHA-512 */
-      "87AA7CDEA5EF619D4FF0B4241A1D6CB02379F4E2CE4EC2787AD0B30545E1"
-      "7CDEDAA833B7D6B8A702038B274EAEA3F4E4BE9D914EEB61F1702E696C20"
-      "3A126854"
-    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
-      SHA384HashSize, SHA512HashSize }
-  },
-  { /* 2 */ {
-      "\x4a\x65\x66\x65" /* "Jefe" */
-    }, { 4 }, {
-      "\x77\x68\x61\x74\x20\x64\x6f\x20\x79\x61\x20\x77\x61\x6e\x74"
-      "\x20\x66\x6f\x72\x20\x6e\x6f\x74\x68\x69\x6e\x67\x3f"
-      /* "what do ya want for nothing?" */
-    }, { 28 }, {
-      /* HMAC-SHA-1 */
-      "EFFCDF6AE5EB2FA2D27416D5F184DF9C259A7C79",
-      /* HMAC-SHA-224 */
-      "A30E01098BC6DBBF45690F3A7E9E6D0F8BBEA2A39E6148008FD05E44",
-      /* HMAC-SHA-256 */
-      "5BDCC146BF60754E6A042426089575C75A003F089D2739839DEC58B964EC"
-      "3843",
-      /* HMAC-SHA-384 */
-      "AF45D2E376484031617F78D2B58A6B1B9C7EF464F5A01B47E42EC3736322"
-      "445E8E2240CA5E69E2C78B3239ECFAB21649",
-      /* HMAC-SHA-512 */
-      "164B7A7BFCF819E2E395FBE73B56E0A387BD64222E831FD610270CD7EA25"
-      "05549758BF75C05A994A6D034F65F8F0E6FDCAEAB1A34D4A6B4B636E070A"
-      "38BCE737"
-    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
-      SHA384HashSize, SHA512HashSize }
-  },
-  { /* 3 */
-    {
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa"
-    }, { 20 }, {
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 87]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      "\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd"
-      "\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd"
-      "\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd"
-      "\xdd\xdd\xdd\xdd\xdd"
-    }, { 50 }, {
-      /* HMAC-SHA-1 */
-      "125D7342B9AC11CD91A39AF48AA17B4F63F175D3",
-      /* HMAC-SHA-224 */
-      "7FB3CB3588C6C1F6FFA9694D7D6AD2649365B0C1F65D69D1EC8333EA",
-      /* HMAC-SHA-256 */
-      "773EA91E36800E46854DB8EBD09181A72959098B3EF8C122D9635514CED5"
-      "65FE",
-      /* HMAC-SHA-384 */
-      "88062608D3E6AD8A0AA2ACE014C8A86F0AA635D947AC9FEBE83EF4E55966"
-      "144B2A5AB39DC13814B94E3AB6E101A34F27",
-      /* HMAC-SHA-512 */
-      "FA73B0089D56A284EFB0F0756C890BE9B1B5DBDD8EE81A3655F83E33B227"
-      "9D39BF3E848279A722C806B485A47E67C807B946A337BEE8942674278859"
-      "E13292FB"
-    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
-      SHA384HashSize, SHA512HashSize }
-  },
-  { /* 4 */ {
-      "\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f"
-      "\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19"
-    }, { 25 }, {
-      "\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd"
-      "\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd"
-      "\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd"
-      "\xcd\xcd\xcd\xcd\xcd"
-    }, { 50 }, {
-      /* HMAC-SHA-1 */
-      "4C9007F4026250C6BC8414F9BF50C86C2D7235DA",
-      /* HMAC-SHA-224 */
-      "6C11506874013CAC6A2ABC1BB382627CEC6A90D86EFC012DE7AFEC5A",
-      /* HMAC-SHA-256 */
-      "82558A389A443C0EA4CC819899F2083A85F0FAA3E578F8077A2E3FF46729"
-      "665B",
-      /* HMAC-SHA-384 */
-      "3E8A69B7783C25851933AB6290AF6CA77A9981480850009CC5577C6E1F57"
-      "3B4E6801DD23C4A7D679CCF8A386C674CFFB",
-      /* HMAC-SHA-512 */
-      "B0BA465637458C6990E5A8C5F61D4AF7E576D97FF94B872DE76F8050361E"
-      "E3DBA91CA5C11AA25EB4D679275CC5788063A5F19741120C4F2DE2ADEBEB"
-      "10A298DD"
-    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
-      SHA384HashSize, SHA512HashSize }
-  },
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 88]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  { /* 5 */ {
-      "\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c"
-      "\x0c\x0c\x0c\x0c\x0c"
-    }, { 20 }, {
-      "Test With Truncation"
-    }, { 20 }, {
-      /* HMAC-SHA-1 */
-      "4C1A03424B55E07FE7F27BE1",
-      /* HMAC-SHA-224 */
-      "0E2AEA68A90C8D37C988BCDB9FCA6FA8",
-      /* HMAC-SHA-256 */
-      "A3B6167473100EE06E0C796C2955552B",
-      /* HMAC-SHA-384 */
-      "3ABF34C3503B2A23A46EFC619BAEF897",
-      /* HMAC-SHA-512 */
-      "415FAD6271580A531D4179BC891D87A6"
-    }, { 12, 16, 16, 16, 16 }
-  },
-  { /* 6 */ {
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-    }, { 80, 131 }, {
-      "Test Using Larger Than Block-Size Key - Hash Key First"
-    }, { 54 }, {
-      /* HMAC-SHA-1 */
-      "AA4AE5E15272D00E95705637CE8A3B55ED402112",
-      /* HMAC-SHA-224 */
-      "95E9A0DB962095ADAEBE9B2D6F0DBCE2D499F112F2D2B7273FA6870E",
-      /* HMAC-SHA-256 */
-      "60E431591EE0B67F0D8A26AACBF5B77F8E0BC6213728C5140546040F0EE3"
-      "7F54",
-      /* HMAC-SHA-384 */
-      "4ECE084485813E9088D2C63A041BC5B44F9EF1012A2B588F3CD11F05033A"
-      "C4C60C2EF6AB4030FE8296248DF163F44952",
-      /* HMAC-SHA-512 */
-      "80B24263C7C1A3EBB71493C1DD7BE8B49B46D1F41B4AEEC1121B013783F8"
-      "F3526B56D037E05F2598BD0FD2215D6A1E5295E64F73F63F0AEC8B915A98"
-      "5D786598"
-    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
-      SHA384HashSize, SHA512HashSize }
-  },
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 89]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  { /* 7 */ {
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
-    }, { 80, 131 }, {
-      "Test Using Larger Than Block-Size Key and "
-      "Larger Than One Block-Size Data",
-      "\x54\x68\x69\x73\x20\x69\x73\x20\x61\x20\x74\x65\x73\x74\x20"
-      "\x75\x73\x69\x6e\x67\x20\x61\x20\x6c\x61\x72\x67\x65\x72\x20"
-      "\x74\x68\x61\x6e\x20\x62\x6c\x6f\x63\x6b\x2d\x73\x69\x7a\x65"
-      "\x20\x6b\x65\x79\x20\x61\x6e\x64\x20\x61\x20\x6c\x61\x72\x67"
-      "\x65\x72\x20\x74\x68\x61\x6e\x20\x62\x6c\x6f\x63\x6b\x2d\x73"
-      "\x69\x7a\x65\x20\x64\x61\x74\x61\x2e\x20\x54\x68\x65\x20\x6b"
-      "\x65\x79\x20\x6e\x65\x65\x64\x73\x20\x74\x6f\x20\x62\x65\x20"
-      "\x68\x61\x73\x68\x65\x64\x20\x62\x65\x66\x6f\x72\x65\x20\x62"
-      "\x65\x69\x6e\x67\x20\x75\x73\x65\x64\x20\x62\x79\x20\x74\x68"
-      "\x65\x20\x48\x4d\x41\x43\x20\x61\x6c\x67\x6f\x72\x69\x74\x68"
-      "\x6d\x2e"
-      /* "This is a test using a larger than block-size key and a "
-          "larger than block-size data. The key needs to be hashed "
-          "before being used by the HMAC algorithm." */
-    }, { 73, 152 }, {
-      /* HMAC-SHA-1 */
-      "E8E99D0F45237D786D6BBAA7965C7808BBFF1A91",
-      /* HMAC-SHA-224 */
-      "3A854166AC5D9F023F54D517D0B39DBD946770DB9C2B95C9F6F565D1",
-      /* HMAC-SHA-256 */
-      "9B09FFA71B942FCB27635FBCD5B0E944BFDC63644F0713938A7F51535C3A"
-      "35E2",
-      /* HMAC-SHA-384 */
-      "6617178E941F020D351E2F254E8FD32C602420FEB0B8FB9ADCCEBB82461E"
-      "99C5A678CC31E799176D3860E6110C46523E",
-      /* HMAC-SHA-512 */
-      "E37B6A775DC87DBAA4DFA9F96E5E3FFDDEBD71F8867289865DF5A32D20CD"
-      "C944B6022CAC3C4982B10D5EEB55C3E4DE15134676FB6DE0446065C97440"
-      "FA8C6A58"
-    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
-      SHA384HashSize, SHA512HashSize }
-  }
-};
-
-/*
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 90]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- * Check the hash value against the expected string, expressed in hex
- */
-static const char hexdigits[] = "0123456789ABCDEF";
-int checkmatch(const unsigned char *hashvalue,
-  const char *hexstr, int hashsize)
-{
-  int i;
-  for (i = 0; i < hashsize; ++i) {
-    if (*hexstr++ != hexdigits[(hashvalue[i] >> 4) & 0xF])
-      return 0;
-    if (*hexstr++ != hexdigits[hashvalue[i] & 0xF]) return 0;
-  }
-  return 1;
-}
-
-/*
- * Print the string, converting non-printable characters to "."
- */
-void printstr(const char *str, int len)
-{
-  for ( ; len-- > 0; str++)
-    putchar(isprint((unsigned char)*str) ? *str : '.');
-}
-
-/*
- * Print the string, converting non-printable characters to hex "## ".
- */
-void printxstr(const char *str, int len)
-{
-  for ( ; len-- > 0; str++)
-    printf("%c%c ", hexdigits[(*str >> 4) & 0xF],
-      hexdigits[*str & 0xF]);
-}
-
-/*
- * Print a usage message.
- */
-void usage(const char *argv0)
-{
-  fprintf(stderr,
-    "Usage:\n"
-    "Common options: [-h hash] [-w|-x] [-H]\n"
-    "Standard tests:\n"
-      "\t%s [-m] [-l loopcount] [-t test#] [-e]\n"
-      "\t\t[-r randomseed] [-R randomloop-count] "
-        "[-p] [-P|-X]\n"
-    "Hash a string:\n"
-      "\t%s [-S expectedresult] -s hashstr [-k key]\n"
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 91]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-    "Hash a file:\n"
-      "\t%s [-S expectedresult] -f file [-k key]\n"
-    "Hash a file, ignoring whitespace:\n"
-      "\t%s [-S expectedresult] -F file [-k key]\n"
-    "Additional bits to add in: [-B bitcount -b bits]\n"
-    "-h\thash to test: "
-      "0|SHA1, 1|SHA224, 2|SHA256, 3|SHA384, 4|SHA512\n"
-    "-m\tperform hmac test\n"
-    "-k\tkey for hmac test\n"
-    "-t\ttest case to run, 1-10\n"
-    "-l\thow many times to run the test\n"
-    "-e\ttest error returns\n"
-    "-p\tdo not print results\n"
-    "-P\tdo not print PASSED/FAILED\n"
-    "-X\tprint FAILED, but not PASSED\n"
-    "-r\tseed for random test\n"
-    "-R\thow many times to run random test\n"
-    "-s\tstring to hash\n"
-    "-S\texpected result of hashed string, in hex\n"
-    "-w\toutput hash in raw format\n"
-    "-x\toutput hash in hex format\n"
-    "-B\t# extra bits to add in after string or file input\n"
-    "-b\textra bits to add (high order bits of #, 0# or 0x#)\n"
-    "-H\tinput hashstr or randomseed is in hex\n"
-    , argv0, argv0, argv0, argv0);
-  exit(1);
-}
-
-/*
- * Print the results and PASS/FAIL.
- */
-void printResult(uint8_t *Message_Digest, int hashsize,
-    const char *hashname, const char *testtype, const char *testname,
-    const char *resultarray, int printResults, int printPassFail)
-{
-  int i, k;
-  if (printResults == PRINTTEXT) {
-    putchar('\t');
-    for (i = 0; i < hashsize ; ++i) {
-      putchar(hexdigits[(Message_Digest[i] >> 4) & 0xF]);
-      putchar(hexdigits[Message_Digest[i] & 0xF]);
-      putchar(' ');
-    }
-    putchar('\n');
-  } else if (printResults == PRINTRAW) {
-    fwrite(Message_Digest, 1, hashsize, stdout);
-  } else if (printResults == PRINTHEX) {
-    for (i = 0; i < hashsize ; ++i) {
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 92]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      putchar(hexdigits[(Message_Digest[i] >> 4) & 0xF]);
-      putchar(hexdigits[Message_Digest[i] & 0xF]);
-    }
-    putchar('\n');
-  }
-
-  if (printResults && resultarray) {
-    printf("    Should match:\n\t");
-    for (i = 0, k = 0; i < hashsize; i++, k += 2) {
-      putchar(resultarray[k]);
-      putchar(resultarray[k+1]);
-      putchar(' ');
-    }
-    putchar('\n');
-  }
-
-  if (printPassFail && resultarray) {
-    int ret = checkmatch(Message_Digest, resultarray, hashsize);
-    if ((printPassFail == PRINTPASSFAIL) || !ret)
-      printf("%s %s %s: %s\n", hashname, testtype, testname,
-        ret ? "PASSED" : "FAILED");
-  }
-}
-
-/*
- * Exercise a hash series of functions. The input is the testarray,
- * repeated repeatcount times, followed by the extrabits. If the
- * result is known, it is in resultarray in uppercase hex.
- */
-int hash(int testno, int loopno, int hashno,
-  const char *testarray, int length, long repeatcount,
-  int numberExtrabits, int extrabits, const unsigned char *keyarray,
-  int keylen, const char *resultarray, int hashsize, int printResults,
-  int printPassFail)
-{
-  USHAContext sha;
-  HMACContext hmac;
-  int err, i;
-  uint8_t Message_Digest[USHAMaxHashSize];
-  char buf[20];
-
-  if (printResults == PRINTTEXT) {
-    printf("\nTest %d: Iteration %d, Repeat %ld\n\t'", testno+1,
-      loopno, repeatcount);
-    printstr(testarray, length);
-    printf("'\n\t'");
-    printxstr(testarray, length);
-    printf("'\n");
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 93]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-    printf("    Length=%d bytes (%d bits), ", length, length * 8);
-    printf("ExtraBits %d: %2.2x\n", numberExtrabits, extrabits);
-  }
-
-  memset(&sha, '\343', sizeof(sha)); /* force bad data into struct */
-  memset(&hmac, '\343', sizeof(hmac));
-  err = keyarray ? hmacReset(&hmac, hashes[hashno].whichSha,
-                             keyarray, keylen) :
-                   USHAReset(&sha, hashes[hashno].whichSha);
-  if (err != shaSuccess) {
-    fprintf(stderr, "hash(): %sReset Error %d.\n",
-            keyarray ? "hmac" : "sha", err);
-    return err;
-  }
-
-  for (i = 0; i < repeatcount; ++i) {
-    err = keyarray ? hmacInput(&hmac, (const uint8_t *) testarray,
-                               length) :
-                     USHAInput(&sha, (const uint8_t *) testarray,
-                               length);
-    if (err != shaSuccess) {
-      fprintf(stderr, "hash(): %sInput Error %d.\n",
-              keyarray ? "hmac" : "sha", err);
-      return err;
-    }
-  }
-
-  if (numberExtrabits > 0) {
-    err = keyarray ? hmacFinalBits(&hmac, (uint8_t) extrabits,
-                                   numberExtrabits) :
-                     USHAFinalBits(&sha, (uint8_t) extrabits,
-                                   numberExtrabits);
-    if (err != shaSuccess) {
-      fprintf(stderr, "hash(): %sFinalBits Error %d.\n",
-              keyarray ? "hmac" : "sha", err);
-      return err;
-    }
-  }
-
-  err = keyarray ? hmacResult(&hmac, Message_Digest) :
-                   USHAResult(&sha, Message_Digest);
-  if (err != shaSuccess) {
-    fprintf(stderr, "hash(): %s Result Error %d, could not "
-      "compute message digest.\n", keyarray ? "hmac" : "sha", err);
-    return err;
-  }
-
-  sprintf(buf, "%d", testno+1);
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 94]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  printResult(Message_Digest, hashsize, hashes[hashno].name,
-    keyarray ? "hmac standard test" : "sha standard test", buf,
-    resultarray, printResults, printPassFail);
-
-  return err;
-}
-
-/*
- * Exercise a hash series of functions. The input is a filename.
- * If the result is known, it is in resultarray in uppercase hex.
- */
-int hashfile(int hashno, const char *hashfilename, int bits,
-  int bitcount, int skipSpaces, const unsigned char *keyarray,
-  int keylen, const char *resultarray, int hashsize,
-  int printResults, int printPassFail)
-{
-  USHAContext sha;
-  HMACContext hmac;
-  int err, nread, c;
-  unsigned char buf[4096];
-  uint8_t Message_Digest[USHAMaxHashSize];
-  unsigned char cc;
-  FILE *hashfp = (strcmp(hashfilename, "-") == 0) ? stdin :
-    fopen(hashfilename, "r");
-
-  if (!hashfp) {
-    fprintf(stderr, "cannot open file '%s'\n", hashfilename);
-    return shaStateError;
-  }
-
-  memset(&sha, '\343', sizeof(sha)); /* force bad data into struct */
-  memset(&hmac, '\343', sizeof(hmac));
-  err = keyarray ? hmacReset(&hmac, hashes[hashno].whichSha,
-                             keyarray, keylen) :
-                   USHAReset(&sha, hashes[hashno].whichSha);
-
-  if (err != shaSuccess) {
-    fprintf(stderr, "hashfile(): %sReset Error %d.\n",
-            keyarray ? "hmac" : "sha", err);
-    return err;
-  }
-
-  if (skipSpaces)
-    while ((c = getc(hashfp)) != EOF) {
-      if (!isspace(c)) {
-        cc = (unsigned char)c;
-        err = keyarray ? hmacInput(&hmac, &cc, 1) :
-                         USHAInput(&sha, &cc, 1);
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 95]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-        if (err != shaSuccess) {
-          fprintf(stderr, "hashfile(): %sInput Error %d.\n",
-                  keyarray ? "hmac" : "sha", err);
-          if (hashfp != stdin) fclose(hashfp);
-          return err;
-        }
-      }
-    }
-  else
-    while ((nread = fread(buf, 1, sizeof(buf), hashfp)) > 0) {
-      err = keyarray ? hmacInput(&hmac, buf, nread) :
-                       USHAInput(&sha, buf, nread);
-      if (err != shaSuccess) {
-        fprintf(stderr, "hashfile(): %s Error %d.\n",
-                keyarray ? "hmacInput" : "shaInput", err);
-        if (hashfp != stdin) fclose(hashfp);
-        return err;
-      }
-    }
-
-  if (bitcount > 0)
-    err = keyarray ? hmacFinalBits(&hmac, bits, bitcount) :
-                   USHAFinalBits(&sha, bits, bitcount);
-  if (err != shaSuccess) {
-    fprintf(stderr, "hashfile(): %s Error %d.\n",
-            keyarray ? "hmacResult" : "shaResult", err);
-    if (hashfp != stdin) fclose(hashfp);
-    return err;
-  }
-
-  err = keyarray ? hmacResult(&hmac, Message_Digest) :
-                   USHAResult(&sha, Message_Digest);
-  if (err != shaSuccess) {
-    fprintf(stderr, "hashfile(): %s Error %d.\n",
-            keyarray ? "hmacResult" : "shaResult", err);
-    if (hashfp != stdin) fclose(hashfp);
-    return err;
-  }
-
-  printResult(Message_Digest, hashsize, hashes[hashno].name, "file",
-    hashfilename, resultarray, printResults, printPassFail);
-
-  if (hashfp != stdin) fclose(hashfp);
-  return err;
-}
-
-/*
- * Exercise a hash series of functions through multiple permutations.
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 96]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- * The input is an initial seed. That seed is replicated 3 times.
- * For 1000 rounds, the previous three results are used as the input.
- * This result is then checked, and used to seed the next cycle.
- * If the result is known, it is in resultarrays in uppercase hex.
- */
-void randomtest(int hashno, const char *seed, int hashsize,
-    const char **resultarrays, int randomcount,
-    int printResults, int printPassFail)
-{
-  int i, j; char buf[20];
-  unsigned char SEED[USHAMaxHashSize], MD[1003][USHAMaxHashSize];
-
-  /* INPUT: Seed - A random seed n bits long */
-  memcpy(SEED, seed, hashsize);
-  if (printResults == PRINTTEXT) {
-    printf("%s random test seed= '", hashes[hashno].name);
-    printxstr(seed, hashsize);
-    printf("'\n");
-  }
-
-  for (j = 0; j < randomcount; j++) {
-    /* MD0 = MD1 = MD2 = Seed; */
-    memcpy(MD[0], SEED, hashsize);
-    memcpy(MD[1], SEED, hashsize);
-    memcpy(MD[2], SEED, hashsize);
-    for (i=3; i<1003; i++) {
-      /* Mi = MDi-3 || MDi-2 || MDi-1; */
-      USHAContext Mi;
-      memset(&Mi, '\343', sizeof(Mi)); /* force bad data into struct */
-      USHAReset(&Mi, hashes[hashno].whichSha);
-      USHAInput(&Mi, MD[i-3], hashsize);
-      USHAInput(&Mi, MD[i-2], hashsize);
-      USHAInput(&Mi, MD[i-1], hashsize);
-      /* MDi = SHA(Mi); */
-      USHAResult(&Mi, MD[i]);
-    }
-
-    /* MDj = Seed = MDi; */
-    memcpy(SEED, MD[i-1], hashsize);
-
-    /* OUTPUT: MDj */
-    sprintf(buf, "%d", j);
-    printResult(SEED, hashsize, hashes[hashno].name, "random test",
-      buf, resultarrays ? resultarrays[j] : 0, printResults,
-      (j < RANDOMCOUNT) ? printPassFail : 0);
-  }
-}
-
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 97]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-/*
- * Look up a hash name.
- */
-int findhash(const char *argv0, const char *opt)
-{
-  int i;
-  const char *names[HASHCOUNT][2] = {
-    { "0", "sha1" }, { "1", "sha224" }, { "2", "sha256" },
-    { "3", "sha384" }, { "4", "sha512" }
-  };
-
-  for (i = 0; i < HASHCOUNT; i++)
-    if ((strcmp(opt, names[i][0]) == 0) ||
-        (scasecmp(opt, names[i][1]) == 0))
-      return i;
-
-  fprintf(stderr, "%s: Unknown hash name: '%s'\n", argv0, opt);
-  usage(argv0);
-  return 0;
-}
-
-/*
- * Run some tests that should invoke errors.
- */
-void testErrors(int hashnolow, int hashnohigh, int printResults,
-    int printPassFail)
-{
-  USHAContext usha;
-  uint8_t Message_Digest[USHAMaxHashSize];
-  int hashno, err;
-
-  for (hashno = hashnolow; hashno <= hashnohigh; hashno++) {
-    memset(&usha, '\343', sizeof(usha)); /* force bad data */
-    USHAReset(&usha, hashno);
-    USHAResult(&usha, Message_Digest);
-    err = USHAInput(&usha, (const unsigned char *)"foo", 3);
-    if (printResults == PRINTTEXT)
-      printf ("\nError %d. Should be %d.\n", err, shaStateError);
-    if ((printPassFail == PRINTPASSFAIL) ||
-        ((printPassFail == PRINTFAIL) && (err != shaStateError)))
-      printf("%s se: %s\n", hashes[hashno].name,
-        (err == shaStateError) ? "PASSED" : "FAILED");
-
-    err = USHAFinalBits(&usha, 0x80, 3);
-    if (printResults == PRINTTEXT)
-      printf ("\nError %d. Should be %d.\n", err, shaStateError);
-    if ((printPassFail == PRINTPASSFAIL) ||
-        ((printPassFail == PRINTFAIL) && (err != shaStateError)))
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 98]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      printf("%s se: %s\n", hashes[hashno].name,
-        (err == shaStateError) ? "PASSED" : "FAILED");
-
-    err = USHAReset(0, hashes[hashno].whichSha);
-    if (printResults == PRINTTEXT)
-       printf("\nError %d. Should be %d.\n", err, shaNull);
-    if ((printPassFail == PRINTPASSFAIL) ||
-        ((printPassFail == PRINTFAIL) && (err != shaNull)))
-       printf("%s usha null: %s\n", hashes[hashno].name,
-        (err == shaNull) ? "PASSED" : "FAILED");
-
-    switch (hashno) {
-      case SHA1: err = SHA1Reset(0); break;
-      case SHA224: err = SHA224Reset(0); break;
-      case SHA256: err = SHA256Reset(0); break;
-      case SHA384: err = SHA384Reset(0); break;
-      case SHA512: err = SHA512Reset(0); break;
-    }
-    if (printResults == PRINTTEXT)
-       printf("\nError %d. Should be %d.\n", err, shaNull);
-    if ((printPassFail == PRINTPASSFAIL) ||
-        ((printPassFail == PRINTFAIL) && (err != shaNull)))
-       printf("%s sha null: %s\n", hashes[hashno].name,
-        (err == shaNull) ? "PASSED" : "FAILED");
-  }
-}
-
-/* replace a hex string in place with its value */
-int unhexStr(char *hexstr)
-{
-  char *o = hexstr;
-  int len = 0, nibble1 = 0, nibble2 = 0;
-  if (!hexstr) return 0;
-  for ( ; *hexstr; hexstr++) {
-    if (isalpha((int)(unsigned char)(*hexstr))) {
-      nibble1 = tolower(*hexstr) - 'a' + 10;
-    } else if (isdigit((int)(unsigned char)(*hexstr))) {
-      nibble1 = *hexstr - '0';
-    } else {
-      printf("\nError: bad hex character '%c'\n", *hexstr);
-    }
-    if (!*++hexstr) break;
-    if (isalpha((int)(unsigned char)(*hexstr))) {
-      nibble2 = tolower(*hexstr) - 'a' + 10;
-    } else if (isdigit((int)(unsigned char)(*hexstr))) {
-      nibble2 = *hexstr - '0';
-    } else {
-      printf("\nError: bad hex character '%c'\n", *hexstr);
-
-
-
-Eastlake 3rd & Hansen        Informational                     [Page 99]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-    }
-    *o++ = (char)((nibble1 << 4) | nibble2);
-    len++;
-  }
-  return len;
-}
-
-int main(int argc, char **argv)
-{
-  int i, err;
-  int loopno, loopnohigh = 1;
-  int hashno, hashnolow = 0, hashnohigh = HASHCOUNT - 1;
-  int testno, testnolow = 0, testnohigh;
-  int ntestnohigh = 0;
-  int printResults = PRINTTEXT;
-  int printPassFail = 1;
-  int checkErrors = 0;
-  char *hashstr = 0;
-  int hashlen = 0;
-  const char *resultstr = 0;
-  char *randomseedstr = 0;
-  int runHmacTests = 0;
-  char *hmacKey = 0;
-  int hmaclen = 0;
-  int randomcount = RANDOMCOUNT;
-  const char *hashfilename = 0;
-  const char *hashFilename = 0;
-  int extrabits = 0, numberExtrabits = 0;
-  int strIsHex = 0;
-
-  while ((i = xgetopt(argc, argv, "b:B:ef:F:h:Hk:l:mpPr:R:s:S:t:wxX"))
-         != -1)
-    switch (i) {
-      case 'b': extrabits = strtol(xoptarg, 0, 0); break;
-      case 'B': numberExtrabits = atoi(xoptarg); break;
-      case 'e': checkErrors = 1; break;
-      case 'f': hashfilename = xoptarg; break;
-      case 'F': hashFilename = xoptarg; break;
-      case 'h': hashnolow = hashnohigh = findhash(argv[0], xoptarg);
-        break;
-      case 'H': strIsHex = 1; break;
-      case 'k': hmacKey = xoptarg; hmaclen = strlen(xoptarg); break;
-      case 'l': loopnohigh = atoi(xoptarg); break;
-      case 'm': runHmacTests = 1; break;
-      case 'P': printPassFail = 0; break;
-      case 'p': printResults = PRINTNONE; break;
-      case 'R': randomcount = atoi(xoptarg); break;
-      case 'r': randomseedstr = xoptarg; break;
-
-
-
-Eastlake 3rd & Hansen        Informational                    [Page 100]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-      case 's': hashstr = xoptarg; hashlen = strlen(hashstr); break;
-      case 'S': resultstr = xoptarg; break;
-      case 't': testnolow = ntestnohigh = atoi(xoptarg) - 1; break;
-      case 'w': printResults = PRINTRAW; break;
-      case 'x': printResults = PRINTHEX; break;
-      case 'X': printPassFail = 2; break;
-      default: usage(argv[0]);
-      }
-
-  if (strIsHex) {
-    hashlen = unhexStr(hashstr);
-    unhexStr(randomseedstr);
-    hmaclen = unhexStr(hmacKey);
-  }
-  testnohigh = (ntestnohigh != 0) ? ntestnohigh:
-               runHmacTests ? (HMACTESTCOUNT-1) : (TESTCOUNT-1);
-  if ((testnolow < 0) ||
-      (testnohigh >= (runHmacTests ? HMACTESTCOUNT : TESTCOUNT)) ||
-      (hashnolow < 0) || (hashnohigh >= HASHCOUNT) ||
-      (hashstr && (testnolow == testnohigh)) ||
-      (randomcount < 0) ||
-      (resultstr && (!hashstr && !hashfilename && !hashFilename)) ||
-      ((runHmacTests || hmacKey) && randomseedstr) ||
-      (hashfilename && hashFilename))
-    usage(argv[0]);
-
-  /*
-   *  Perform SHA/HMAC tests
-   */
-  for (hashno = hashnolow; hashno <= hashnohigh; ++hashno) {
-    if (printResults == PRINTTEXT)
-      printf("Hash %s\n", hashes[hashno].name);
-    err = shaSuccess;
-
-    for (loopno = 1; (loopno <= loopnohigh) && (err == shaSuccess);
-         ++loopno) {
-      if (hashstr)
-        err = hash(0, loopno, hashno, hashstr, hashlen, 1,
-          numberExtrabits, extrabits, (const unsigned char *)hmacKey,
-          hmaclen, resultstr, hashes[hashno].hashsize, printResults,
-          printPassFail);
-
-      else if (randomseedstr)
-        randomtest(hashno, randomseedstr, hashes[hashno].hashsize, 0,
-          randomcount, printResults, printPassFail);
-
-      else if (hashfilename)
-        err = hashfile(hashno, hashfilename, extrabits,
-
-
-
-Eastlake 3rd & Hansen        Informational                    [Page 101]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-                       numberExtrabits, 0,
-                       (const unsigned char *)hmacKey, hmaclen,
-                       resultstr, hashes[hashno].hashsize,
-                       printResults, printPassFail);
-
-      else if (hashFilename)
-        err = hashfile(hashno, hashFilename, extrabits,
-                       numberExtrabits, 1,
-                       (const unsigned char *)hmacKey, hmaclen,
-                       resultstr, hashes[hashno].hashsize,
-                       printResults, printPassFail);
-
-      else /* standard tests */ {
-        for (testno = testnolow;
-             (testno <= testnohigh) && (err == shaSuccess); ++testno) {
-          if (runHmacTests) {
-            err = hash(testno, loopno, hashno,
-                       hmachashes[testno].dataarray[hashno] ?
-                       hmachashes[testno].dataarray[hashno] :
-                       hmachashes[testno].dataarray[1] ?
-                       hmachashes[testno].dataarray[1] :
-                       hmachashes[testno].dataarray[0],
-                       hmachashes[testno].datalength[hashno] ?
-                       hmachashes[testno].datalength[hashno] :
-                       hmachashes[testno].datalength[1] ?
-                       hmachashes[testno].datalength[1] :
-                       hmachashes[testno].datalength[0],
-                       1, 0, 0,
-                       (const unsigned char *)(
-                        hmachashes[testno].keyarray[hashno] ?
-                        hmachashes[testno].keyarray[hashno] :
-                        hmachashes[testno].keyarray[1] ?
-                        hmachashes[testno].keyarray[1] :
-                        hmachashes[testno].keyarray[0]),
-                       hmachashes[testno].keylength[hashno] ?
-                       hmachashes[testno].keylength[hashno] :
-                       hmachashes[testno].keylength[1] ?
-                       hmachashes[testno].keylength[1] :
-                       hmachashes[testno].keylength[0],
-                       hmachashes[testno].resultarray[hashno],
-                       hmachashes[testno].resultlength[hashno],
-                       printResults, printPassFail);
-          } else {
-            err = hash(testno, loopno, hashno,
-                       hashes[hashno].tests[testno].testarray,
-                       hashes[hashno].tests[testno].length,
-                       hashes[hashno].tests[testno].repeatcount,
-                       hashes[hashno].tests[testno].numberExtrabits,
-
-
-
-Eastlake 3rd & Hansen        Informational                    [Page 102]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-                       hashes[hashno].tests[testno].extrabits, 0, 0,
-                       hashes[hashno].tests[testno].resultarray,
-                       hashes[hashno].hashsize,
-                       printResults, printPassFail);
-          }
-        }
-
-        if (!runHmacTests) {
-          randomtest(hashno, hashes[hashno].randomtest,
-            hashes[hashno].hashsize, hashes[hashno].randomresults,
-            RANDOMCOUNT, printResults, printPassFail);
-        }
-      }
-    }
-  }
-
-  /* Test some error returns */
-  if (checkErrors) {
-    testErrors(hashnolow, hashnohigh, printResults, printPassFail);
-  }
-
-  return 0;
-}
-
-/*
- * Compare two strings, case independently.
- * Equivalent to strcasecmp() found on some systems.
- */
-int scasecmp(const char *s1, const char *s2)
-{
-  for (;;) {
-    char u1 = tolower(*s1++);
-    char u2 = tolower(*s2++);
-    if (u1 != u2)
-      return u1 - u2;
-    if (u1 == '\0')
-      return 0;
-   }
-}
-
-/*
- * This is a copy of getopt provided for those systems that do not
- * have it. The name was changed to xgetopt to not conflict on those
- * systems that do have it. Similarly, optarg, optind and opterr
- * were renamed to xoptarg, xoptind and xopterr.
- *
- * Copyright 1990, 1991, 1992 by the Massachusetts Institute of
- * Technology and UniSoft Group Limited.
-
-
-
-Eastlake 3rd & Hansen        Informational                    [Page 103]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
- *
- * Permission to use, copy, modify, distribute, and sell this software
- * and its documentation for any purpose is hereby granted without fee,
- * provided that the above copyright notice appear in all copies and
- * that both that copyright notice and this permission notice appear in
- * supporting documentation, and that the names of MIT and UniSoft not
- * be used in advertising or publicity pertaining to distribution of
- * the software without specific, written prior permission.  MIT and
- * UniSoft make no representations about the suitability of this
- * software for any purpose.  It is provided "as is" without express
- * or implied warranty.
- *
- * $XConsortium: getopt.c,v 1.2 92/07/01 11:59:04 rws Exp $
- * NB: Reformatted to match above style.
- */
-
-char    *xoptarg;
-int     xoptind = 1;
-int     xopterr = 1;
-
-static int xgetopt(int argc, char **argv, const char *optstring)
-{
-  static int avplace;
-  char    *ap;
-  char    *cp;
-  int     c;
-
-  if (xoptind >= argc)
-    return EOF;
-
-  ap = argv[xoptind] + avplace;
-
-  /* At beginning of arg but not an option */
-  if (avplace == 0) {
-    if (ap[0] != '-')
-      return EOF;
-    else if (ap[1] == '-') {
-      /* Special end of options option */
-      xoptind++;
-      return EOF;
-    } else if (ap[1] == '\0')
-      return EOF;  /* single '-' is not allowed */
-  }
-
-  /* Get next letter */
-  avplace++;
-  c = *++ap;
-
-
-
-
-Eastlake 3rd & Hansen        Informational                    [Page 104]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-  cp = strchr(optstring, c);
-  if (cp == NULL || c == ':') {
-    if (xopterr)
-      fprintf(stderr, "Unrecognised option -- %c\n", c);
-    return '?';
-  }
-
-  if (cp[1] == ':') {
-    /* There should be an option arg */
-    avplace = 0;
-    if (ap[1] == '\0') {
-      /* It is a separate arg */
-      if (++xoptind >= argc) {
-        if (xopterr)
-          fprintf(stderr, "Option requires an argument\n");
-        return '?';
-      }
-      xoptarg = argv[xoptind++];
-    } else {
-      /* is attached to option letter */
-      xoptarg = ap + 1;
-      ++xoptind;
-    }
-  } else {
-    /* If we are out of letters then go to next arg */
-    if (ap[1] == '\0') {
-      ++xoptind;
-      avplace = 0;
-    }
-
-    xoptarg = NULL;
-  }
-  return c;
-}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                    [Page 105]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-9.  Security Considerations
-
-   This document is intended to provides the Internet community
-   convenient access to source code that implements the United States of
-   America Federal Information Processing Standard Secure Hash
-   Algorithms (SHAs) [FIPS180-2] and HMACs based upon these one-way hash
-   functions.  See license in Section 1.1.  No independent assertion of
-   the security of this hash function by the authors for any particular
-   use is intended.
-
-10.  Normative References
-
-   [FIPS180-2] "Secure Hash Standard", United States of America,
-               National Institute of Standards and Technology, Federal
-               Information Processing Standard (FIPS) 180-2,
-               http://csrc.nist.gov/publications/fips/fips180-2/
-               fips180-2withchangenotice.pdf.
-
-   [RFC2104]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
-               Hashing for Message Authentication", RFC 2104, February
-               1997.
-
-11.  Informative References
-
-   [RFC2202]   Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and
-               HMAC-SHA-1", RFC 2202, September 1997.
-
-   [RFC3174]   Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
-               1 (SHA1)", RFC 3174, September 2001.
-
-   [RFC3874]   Housley, R., "A 224-bit One-way Hash Function: SHA-224",
-               RFC 3874, September 2004.
-
-   [RFC4086]   Eastlake, D., 3rd, Schiller, J., and S. Crocker,
-               "Randomness Requirements for Security", BCP 106, RFC
-               4086, June 2005.
-
-   [RFC4231]   Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-
-               224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC
-               4231, December 2005.
-
-   [SHAVS]     "The Secure Hash Algorithm Validation System (SHAVS)",
-               http://csrc.nist.gov/cryptval/shs/SHAVS.pdf.
-
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                    [Page 106]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-Authors' Addresses
-
-   Donald E. Eastlake, 3rd
-   Motorola Laboratories
-   155 Beaver Street
-   Milford, MA 01757 USA
-
-   Phone: +1-508-786-7554 (w)
-   EMail: donald.eastlake@motorola.com
-
-
-   Tony Hansen
-   AT&T Laboratories
-   200 Laurel Ave.
-   Middletown, NJ 07748 USA
-
-   Phone: +1-732-420-8934 (w)
-   EMail: tony+shs@maillennium.att.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                    [Page 107]
-
-RFC 4634                   SHAs and HMAC-SHAs                  July 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   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.
-
-Intellectual Property
-
-   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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Eastlake 3rd & Hansen        Informational                    [Page 108]
-
diff --git a/contrib/bind9/doc/rfc/rfc4641.txt b/contrib/bind9/doc/rfc/rfc4641.txt
deleted file mode 100644
index 0a013bc..0000000
--- a/contrib/bind9/doc/rfc/rfc4641.txt
+++ /dev/null
@@ -1,1963 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         O. Kolkman
-Request for Comments: 4641                                     R. Gieben
-Obsoletes: 2541                                               NLnet Labs
-Category: Informational                                   September 2006
-
-
-                      DNSSEC Operational Practices
-
-Status of This Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes a set of practices for operating the DNS with
-   security extensions (DNSSEC).  The target audience is zone
-   administrators deploying DNSSEC.
-
-   The document discusses operational aspects of using keys and
-   signatures in the DNS.  It discusses issues of key generation, key
-   storage, signature generation, key rollover, and related policies.
-
-   This document obsoletes RFC 2541, as it covers more operational
-   ground and gives more up-to-date requirements with respect to key
-   sizes and the new DNSSEC specification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                      [Page 1]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-Table of Contents
-
-   1. Introduction ....................................................3
-      1.1. The Use of the Term 'key' ..................................4
-      1.2. Time Definitions ...........................................4
-   2. Keeping the Chain of Trust Intact ...............................5
-   3. Keys Generation and Storage .....................................6
-      3.1. Zone and Key Signing Keys ..................................6
-           3.1.1. Motivations for the KSK and ZSK Separation ..........6
-           3.1.2. KSKs for High-Level Zones ...........................7
-      3.2. Key Generation .............................................8
-      3.3. Key Effectivity Period .....................................8
-      3.4. Key Algorithm ..............................................9
-      3.5. Key Sizes ..................................................9
-      3.6. Private Key Storage .......................................11
-   4. Signature Generation, Key Rollover, and Related Policies .......12
-      4.1. Time in DNSSEC ............................................12
-           4.1.1. Time Considerations ................................12
-      4.2. Key Rollovers .............................................14
-           4.2.1. Zone Signing Key Rollovers .........................14
-                  4.2.1.1. Pre-Publish Key Rollover ..................15
-                  4.2.1.2. Double Signature Zone Signing Key
-                           Rollover ..................................17
-                  4.2.1.3. Pros and Cons of the Schemes ..............18
-           4.2.2. Key Signing Key Rollovers ..........................18
-           4.2.3. Difference Between ZSK and KSK Rollovers ...........20
-           4.2.4. Automated Key Rollovers ............................21
-      4.3. Planning for Emergency Key Rollover .......................21
-           4.3.1. KSK Compromise .....................................22
-                  4.3.1.1. Keeping the Chain of Trust Intact .........22
-                  4.3.1.2. Breaking the Chain of Trust ...............23
-           4.3.2. ZSK Compromise .....................................23
-           4.3.3. Compromises of Keys Anchored in Resolvers ..........24
-      4.4. Parental Policies .........................................24
-           4.4.1. Initial Key Exchanges and Parental Policies
-                  Considerations .....................................24
-           4.4.2. Storing Keys or Hashes? ............................25
-           4.4.3. Security Lameness ..................................25
-           4.4.4. DS Signature Validity Period .......................26
-   5. Security Considerations ........................................26
-   6. Acknowledgments ................................................26
-   7. References .....................................................27
-      7.1. Normative References ......................................27
-      7.2. Informative References ....................................28
-   Appendix A. Terminology ...........................................30
-   Appendix B. Zone Signing Key Rollover How-To ......................31
-   Appendix C. Typographic Conventions ...............................32
-
-
-
-
-Kolkman & Gieben             Informational                      [Page 2]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-1.  Introduction
-
-   This document describes how to run a DNS Security (DNSSEC)-enabled
-   environment.  It is intended for operators who have knowledge of the
-   DNS (see RFC 1034 [1] and RFC 1035 [2]) and want to deploy DNSSEC.
-   See RFC 4033 [4] for an introduction to DNSSEC, RFC 4034 [5] for the
-   newly introduced Resource Records (RRs), and RFC 4035 [6] for the
-   protocol changes.
-
-   During workshops and early operational deployment tests, operators
-   and system administrators have gained experience about operating the
-   DNS with security extensions (DNSSEC).  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 representing '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 re-signing or key
-   rollovers be transparent to any verifying clients on the Internet.
-
-   The structure of this document is as follows.  In Section 2, we
-   discuss the importance of keeping the "chain of trust" intact.
-   Aspects of key generation and storage of private keys are discussed
-   in Section 3; the focus in this section is mainly on the private part
-   of the key(s).  Section 4 describes considerations concerning the
-   public part of the keys.  Since these public keys appear in the DNS
-   one has to take into account all kinds of timing issues, which are
-   discussed in Section 4.1.  Section 4.2 and Section 4.3 deal with the
-   rollover, or supercession, of keys.  Finally, Section 4.4 discusses
-   considerations on how parents deal with their children's public keys
-   in order to maintain chains of trust.
-
-   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 RFC 2119 [7] language does not apply.
-
-   This document obsoletes RFC 2541 [12] to reflect the evolution of the
-   underlying DNSSEC protocol since then.  Changes in the choice of
-   cryptographic algorithms, DNS record types and type names, and the
-   parent-child key and signature exchange demanded a major rewrite and
-   additional information and explanation.
-
-
-
-
-
-
-Kolkman & Gieben             Informational                      [Page 3]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-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
-   [17]).  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 the public part that is
-   used in key exchanges.
-
-1.2.  Time Definitions
-
-   In this document, we will be using a number of time-related terms.
-   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.
-
-   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.  After one stops
-      publishing an RRSIG in a zone, it may take a while before the
-      RRSIG has expired from caches and has actually been removed from
-      the DNS.
-
-   o  "Key effectivity period" The period during which a key pair is
-      expected to be effective.  This period is defined as the time
-      between the first inception time stamp and the last expiration
-      date of any signature made with this key, regardless of any
-      discontinuity in the use of the key.  The key effectivity period
-      can span multiple signature validity periods.
-
-   o  "Maximum/Minimum Zone Time to Live (TTL)" The maximum or minimum
-      value of the TTLs from the complete set of RRs in a zone.  Note
-      that the minimum TTL is not the same as the MINIMUM field in the
-      SOA RR.  See [11] for more information.
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                      [Page 4]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-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 (as defined in [4]
-   Section 5), which may cause entire (sub)domains to become invisible
-   to verifying clients.  The administrators of secured zones have to
-   realize that their zone is, to verifying clients, part of a chain of
-   trust.
-
-   As mentioned in the introduction, the procedures herein are intended
-   to ensure that maintenance of zones, such as re-signing or key
-   rollovers, will 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
-   transferred to other secondary authoritative nameservers and clients
-   may be fetching data from caching non-authoritative servers.  In this
-   light, note that the time for a zone transfer from master to slave is
-   negligible when using NOTIFY [9] and incremental transfer (IXFR) [8].
-   It increases when full zone transfers (AXFR) are used in combination
-   with NOTIFY.  It increases even more if you rely on full zone
-   transfers based on only the SOA timing parameters for refresh.
-
-   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 ensure 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 replacing the compromised keys
-   as soon as possible must be made.  Then zone administrators will have
-   to make a trade-off, between keeping the chain of trust intact --
-   thereby allowing for attacks with the compromised key -- or
-   deliberately breaking the chain of trust and making secured
-   subdomains invisible to security-aware resolvers.  Also see Section
-   4.3.
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                      [Page 5]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-3.  Keys Generation and Storage
-
-   This section describes a number of considerations with respect to the
-   security of keys.  It deals with the generation, effectivity period,
-   size, and storage of private keys.
-
-3.1.  Zone and Key Signing Keys
-
-   The DNSSEC validation protocol does not distinguish between different
-   types of DNSKEYs.  All DNSKEYs can be used during the validation.  In
-   practice, operators use Key Signing and Zone Signing Keys and use the
-   so-called Secure Entry Point (SEP) [3] flag to distinguish between
-   them during operations.  The dynamics and considerations are
-   discussed below.
-
-   To make zone re-signing and key rollover procedures easier to
-   implement, it is possible to use one or more keys as Key Signing Keys
-   (KSKs).  These keys will only sign the apex DNSKEY RRSet in a zone.
-   Other keys can be used to sign all the RRSets in a zone and are
-   referred to as Zone Signing Keys (ZSKs).  In this document, we assume
-   that KSKs are the subset of keys that are used for key exchanges with
-   the parent and potentially for configuration as trusted anchors --
-   the SEP keys.  In this document, we assume a one-to-one mapping
-   between KSK and SEP keys and we assume the SEP flag to be set on all
-   KSKs.
-
-3.1.1.  Motivations for the KSK and ZSK Separation
-
-   Differentiating between the KSK and ZSK functions has several
-   advantages:
-
-   o  No parent/child interaction is required when ZSKs are updated.
-
-   o  The KSK can be made stronger (i.e., using more bits in the key
-      material).  This has little operational impact since it is only
-      used to sign a small fraction of the zone data.  Also, the KSK is
-      only used to verify the zone's key set, not for other RRSets in
-      the zone.
-
-   o  As the KSK is only used to sign a key set, which is most probably
-      updated less frequently than other data in the zone, it can be
-      stored separately from and in a safer location than the ZSK.
-
-   o  A KSK can have a longer key effectivity period.
-
-   For almost any method of key management and zone signing, the KSK is
-   used less frequently than the ZSK.  Once a key set is signed with the
-   KSK, all the keys in the key set can be used as ZSKs.  If a ZSK is
-
-
-
-Kolkman & Gieben             Informational                      [Page 6]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   compromised, it can be simply dropped from the key set.  The new key
-   set is then re-signed 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.
-
-   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 signature
-   validity periods on the order of days.
-
-   The Key Signing Key is only to be used to sign the DNSKEY RRs in a
-   zone.  If a Key Signing Key is to be rolled over, there will be
-   interactions with parties other than the zone administrator.  These
-   can include the registry of the parent zone or administrators of
-   verifying resolvers that have the particular key configured as secure
-   entry points.  Hence, the key effectivity period of these keys can
-   and should be made much longer.  Although, given a long enough key,
-   the key effectivity period can be on the order of years, we suggest
-   planning for a key effectivity on the order of a few months so that a
-   key rollover remains an operational routine.
-
-3.1.2.  KSKs for High-Level Zones
-
-   Higher-level zones are generally more sensitive than lower-level
-   zones.  Anyone controlling or breaking the security of a zone thereby
-   obtains authority over all of its subdomains (except in the case of
-   resolvers that have locally configured the public key of a subdomain,
-   in which case this, and only this, subdomain wouldn't be affected by
-   the compromise of the parent zone).  Therefore, extra care should be
-   taken with high-level zones, and strong keys should be used.
-
-   The root zone is the most critical of all zones.  Someone controlling
-   or compromising the security of the root zone would control the
-   entire DNS namespace of all resolvers using that root zone (except in
-   the case of resolvers that have locally configured the public key of
-   a subdomain).  Therefore, the utmost care must be taken in the
-   securing of the root zone.  The strongest and most carefully handled
-   keys should be used.  The root zone private key should always be kept
-   off-line.
-
-   Many resolvers will start at a root server for their access to and
-   authentication of DNS data.  Securely updating the trust anchors in
-   an enormous population of resolvers around the world will be
-   extremely difficult.
-
-
-
-
-Kolkman & Gieben             Informational                      [Page 7]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-3.2.  Key Generation
-
-   Careful generation of all keys is a sometimes overlooked but
-   absolutely essential element in any cryptographically secure system.
-   The strongest algorithms used with the longest keys are still of no
-   use if an adversary can guess enough to lower the size of the likely
-   key space so that it can be exhaustively searched.  Technical
-   suggestions for the generation of random keys will be found in RFC
-   4086 [14].  One should carefully assess if the random number
-   generator used during key generation adheres to these suggestions.
-
-   Keys with a long effectivity period are particularly sensitive as
-   they will represent a more valuable target and be subject to attack
-   for a longer time than short-period keys.  It is strongly recommended
-   that long-term key generation occur off-line in a manner isolated
-   from the network via an air gap or, at a minimum, high-level secure
-   hardware.
-
-3.3.  Key Effectivity Period
-
-   For various reasons, keys in DNSSEC need to be changed once in a
-   while.  The longer a key is in use, the greater the probability that
-   it will have been compromised through carelessness, accident,
-   espionage, or cryptanalysis.  Furthermore, when key rollovers are too
-   rare an event, they will not become part of the operational habit and
-   there is risk that nobody on-site will remember the procedure for
-   rollover when the need is there.
-
-   From a purely operational perspective, a reasonable key effectivity
-   period for Key Signing Keys is 13 months, with the intent to replace
-   them after 12 months.  An intended key effectivity period of a month
-   is reasonable for Zone Signing Keys.
-
-   For key sizes that match these effectivity periods, see Section 3.5.
-
-   As argued in Section 3.1.2, securely updating trust anchors will be
-   extremely difficult.  On the other hand, the "operational habit"
-   argument does also apply to trust anchor reconfiguration.  If a short
-   key effectivity period is used and the trust anchor configuration has
-   to be revisited on a regular basis, the odds that the configuration
-   tends to be forgotten is smaller.  The trade-off is against a system
-   that is so dynamic that administrators of the validating clients will
-   not be able to follow the modifications.
-
-   Key effectivity periods can be made very short, as in a few minutes.
-   But when replacing keys one has to take the considerations from
-   Section 4.1 and Section 4.2 into account.
-
-
-
-
-Kolkman & Gieben             Informational                      [Page 8]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-3.4.  Key Algorithm
-
-   There are currently three different types of algorithms that can be
-   used in DNSSEC: RSA, DSA, and elliptic curve cryptography.  The
-   latter is fairly new and has yet to be standardized for usage in
-   DNSSEC.
-
-   RSA has been developed in an open and transparent manner.  As the
-   patent on RSA expired in 2000, its use is now also free.
-
-   DSA has been developed by the National Institute of Standards and
-   Technology (NIST).  The creation of signatures takes roughly the same
-   time as with RSA, but is 10 to 40 times as slow for verification
-   [17].
-
-   We suggest the use of RSA/SHA-1 as the preferred algorithm for the
-   key.  The current known attacks on RSA can be defeated by making your
-   key longer.  As the MD5 hashing algorithm is showing cracks, we
-   recommend the usage of SHA-1.
-
-   At the time of publication, it is known that the SHA-1 hash has
-   cryptanalysis issues.  There is work in progress on addressing these
-   issues.  We recommend the use of public key algorithms based on
-   hashes stronger than SHA-1 (e.g., SHA-256), as soon as these
-   algorithms are available in protocol specifications (see [19] and
-   [20]) and implementations.
-
-3.5.  Key Sizes
-
-   When choosing key sizes, zone administrators will need to take into
-   account how long a key will be used, how much data will be signed
-   during the key publication period (see Section 8.10 of [17]), and,
-   optionally, how large the key size of the parent is.  As the chain of
-   trust really is "a chain", there is not much sense in making one of
-   the keys in the chain several times larger then the others.  As
-   always, it's the weakest link that defines the strength of the entire
-   chain.  Also see Section 3.1.1 for a discussion of how keys serving
-   different roles (ZSK vs. KSK) may need different key sizes.
-
-   Generating a key of the correct size is a difficult problem; RFC 3766
-   [13] tries to deal with that problem.  The first part of the
-   selection procedure in Section 1 of the RFC states:
-
-      1. Determine the attack resistance necessary to satisfy the
-         security requirements of the application.  Do this by
-         estimating the minimum number of computer operations that the
-         attacker will be forced to do in order to compromise the
-
-
-
-
-Kolkman & Gieben             Informational                      [Page 9]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-         security of the system and then take the logarithm base two of
-         that number.  Call that logarithm value "n".
-
-         A 1996 report recommended 90 bits as a good all-around choice
-         for system security.  The 90 bit number should be increased by
-         about 2/3 bit/year, or about 96 bits in 2005.
-
-   [13] goes on to explain how this number "n" can be used to calculate
-   the key sizes in public key cryptography.  This culminated in the
-   table given below (slightly modified for our purpose):
-
-      +-------------+-----------+--------------+
-      | System      |           |              |
-      | requirement | Symmetric | RSA or DSA   |
-      | for attack  | key size  | modulus size |
-      | resistance  | (bits)    | (bits)       |
-      | (bits)      |           |              |
-      +-------------+-----------+--------------+
-      |     70      |     70    |      947     |
-      |     80      |     80    |     1228     |
-      |     90      |     90    |     1553     |
-      |    100      |    100    |     1926     |
-      |    150      |    150    |     4575     |
-      |    200      |    200    |     8719     |
-      |    250      |    250    |    14596     |
-      +-------------+-----------+--------------+
-
-   The key sizes given are rather large.  This is because these keys are
-   resilient against a trillionaire attacker.  Assuming this rich
-   attacker will not attack your key and that the key is rolled over
-   once a year, we come to the following recommendations about KSK
-   sizes: 1024 bits for low-value domains, 1300 bits for medium-value
-   domains, and 2048 bits for high-value domains.
-
-   Whether a domain is of low, medium, or high value depends solely on
-   the views of the zone owner.  One could, for instance, view leaf
-   nodes in the DNS as of low value, and top-level domains (TLDs) or the
-   root zone of high value.  The suggested key sizes should be safe for
-   the next 5 years.
-
-   As ZSKs can be rolled over more easily (and thus more often), the key
-   sizes can be made smaller.  But as said in the introduction of this
-   paragraph, making the ZSKs' key sizes too small (in relation to the
-   KSKs' sizes) doesn't make much sense.  Try to limit the difference in
-   size to about 100 bits.
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 10]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   Note that nobody can see into the future and that these key sizes are
-   only provided here as a guide.  Further information can be found in
-   [16] and Section 7.5 of [17].  It should be noted though that [16] is
-   already considered overly optimistic about what key sizes are
-   considered safe.
-
-   One final note concerning key sizes.  Larger keys will increase the
-   sizes of the RRSIG and DNSKEY records and will therefore increase the
-   chance of DNS UDP packet overflow.  Also, the time it takes to
-   validate and create RRSIGs increases with larger keys, so don't
-   needlessly double your key sizes.
-
-3.6.  Private Key Storage
-
-   It is recommended that, where possible, zone private keys and the
-   zone file master copy that is to be signed be kept and used in off-
-   line, non-network-connected, physically secure machines only.
-   Periodically, an application can be run to add authentication to a
-   zone by adding RRSIG and NSEC RRs.  Then the augmented file can be
-   transferred.
-
-   When relying on dynamic update to manage a signed zone [10], be aware
-   that at least one private key of the zone will have to reside on the
-   master server.  This key is only as secure as the amount of exposure
-   the server receives to unknown clients and the security of the host.
-   Although not mandatory, one could administer the DNS in the following
-   way.  The master that processes the dynamic updates is unavailable
-   from generic hosts on the Internet, it is not listed in the NS RR
-   set, although its name appears in the SOA RRs MNAME field.  The
-   nameservers in the NS RRSet are able to receive zone updates through
-   NOTIFY, IXFR, AXFR, or an out-of-band distribution mechanism.  This
-   approach is known as the "hidden master" setup.
-
-   The ideal situation is to have a one-way information flow to the
-   network to avoid the possibility of tampering from the network.
-   Keeping the zone master file on-line on the network and simply
-   cycling it through an off-line signer does not do this.  The on-line
-   version could still be tampered with if the host it resides on is
-   compromised.  For maximum security, the master copy of the zone file
-   should be off-net and should not be updated based on an unsecured
-   network mediated communication.
-
-   In general, keeping a zone file off-line will not be practical and
-   the machines on which zone files are maintained will be connected to
-   a network.  Operators are advised to take security measures to shield
-   unauthorized access to the master copy.
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 11]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   For dynamically updated secured zones [10], both the master copy and
-   the private key that is used to update signatures on updated RRs will
-   need to be on-line.
-
-4.  Signature Generation, Key Rollover, and Related Policies
-
-4.1.  Time in DNSSEC
-
-   Without DNSSEC, all times in the DNS are relative.  The SOA fields
-   REFRESH, RETRY, and EXPIRATION are timers used to determine the time
-   elapsed after a slave server synchronized with a master server.  The
-   Time to Live (TTL) value and the SOA RR minimum TTL parameter [11]
-   are used to determine how long a forwarder should cache data after it
-   has been fetched from an authoritative server.  By using a signature
-   validity period, 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.
-
-4.1.1.  Time Considerations
-
-   Because of the expiration of signatures, one should consider the
-   following:
-
-   o  We suggest the Maximum Zone TTL of your zone data to 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.  Section
-         7.1 of [4] suggests that "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".  As a result,
-         query load on authoritative servers would peak at signature
-         expiration time, as this is also the time at which records
-         simultaneously expire from caches.
-
-         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  We suggest the signature publication period to end at least one
-      Maximum Zone TTL duration before the end of the signature validity
-      period.
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 12]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-         Re-signing 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  We suggest the Minimum Zone TTL to be long enough to both fetch
-      and verify all the RRs in the trust chain.  In workshop
-      environments, it has been demonstrated [18] that a low TTL (under
-      5 to 10 minutes) caused disruptions because of the following two
-      problems:
-
-         1.  During validation, some data may expire before the
-             validation is complete.  The validator should be able to
-             keep all data until it is completed.  This applies to all
-             RRs needed to complete the chain of trust: DSes, DNSKEYs,
-             RRSIGs, and the final answers, i.e., the RRSet that is
-             returned for the initial query.
-
-         2.  Frequent verification causes load on recursive nameservers.
-             Data at delegation points, DSes, DNSKEYs, and RRSIGs
-             benefit from caching.  The TTL on those should be
-             relatively long.
-
-   o  Slave servers will need to be able to fetch newly signed zones
-      well before the RRSIGs in the zone served by the slave server pass
-      their signature expiration time.
-
-         When a slave server is out of sync with its master and data in
-         a zone is signed by expired signatures, it may be better for
-         the slave server not to give out any answer.
-
-         Normally, a slave server that is not able to contact a master
-         server for an extended period will expire a zone.  When that
-         happens, the server will respond differently to queries for
-         that zone.  Some servers issue SERVFAIL, whereas others turn
-         off the 'AA' bit in the answers.  The time of expiration is set
-         in the SOA record and is relative to the last successful
-         refresh between the master and the slave servers.  There exists
-         no coupling between the signature expiration of RRSIGs in the
-         zone and the expire parameter in the SOA.
-
-         If the server serves a DNSSEC zone, then 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 to or shorter than the signature validity period.  The
-         consequence of an authoritative server not being able to update
-
-
-
-Kolkman & Gieben             Informational                     [Page 13]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-         a zone, whilst that zone includes expired signatures, is that
-         non-secure resolvers will continue to be able to resolve data
-         served by the particular slave servers while security-aware
-         resolvers will experience problems because of answers being
-         marked as Bogus.
-
-         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 times out.  We also suggest
-         that operators of nameservers that supply secondary services
-         develop 'watch dogs' to spot upcoming signature expirations in
-         zones they slave, 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 secondaries expire the zone? How quickly can I reach an
-         administrator of secondary servers to load a valid zone?  These
-         questions are not DNSSEC specific but may influence the choice
-         of your signature validity intervals.
-
-4.2.  Key Rollovers
-
-   A DNSSEC key cannot be used forever (see Section 3.3).  So key
-   rollovers -- or supercessions, as they are sometimes called -- are a
-   fact of life when using DNSSEC.  Zone administrators who are in the
-   process of rolling their keys have to 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 occurs when zone material signed
-   with an old key is being validated by a resolver that 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 that is
-   signed with a new key against an old key that lives in a local cache,
-   also resulting in data being marked "Bogus".
-
-4.2.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 key sets or newly generated signatures can be verified with the
-   keys still in caches.  One schema, described in Section 4.2.1.2, uses
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 14]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   double signatures; the other uses key pre-publication (Section
-   4.2.1.1).  The pros, cons, and recommendations are described in
-   Section 4.2.1.3.
-
-4.2.1.1.  Pre-Publish Key Rollover
-
-   This section shows how to perform a ZSK rollover without the need to
-   sign all the data in a zone twice -- the "pre-publish key rollover".
-   This method has advantages in the case of a 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 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 "how-to" for this
-   kind of rollover can be found in Appendix B.
-
-   Pre-publish key rollover involves four stages as follows:
-
-      ----------------------------------------------------------------
-      initial         new DNSKEY       new RRSIGs      DNSKEY removal
-      ----------------------------------------------------------------
-      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)
-      ----------------------------------------------------------------
-
-                         Pre-Publish Key Rollover
-
-   initial: Initial version 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.
-
-   new DNSKEY: DNSKEY 11 is introduced into the key set.  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
-      key set.
-
-   new RRSIGs: At the "new RRSIGs" stage (SOA serial 2), 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 key set.  This way data that was loaded
-
-
-
-Kolkman & Gieben             Informational                     [Page 15]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-      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 key set 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.
-
-   DNSKEY removal: DNSKEY 10 is removed from the zone.  The key set, now
-      only containing DNSKEY 1 and DNSKEY 11, is re-signed 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 "new DNSKEY"
-   as DNSKEY 12 and again a newer one, numbered 13, in "new DNSKEY
-   (II)":
-
-      ----------------------------------------------------------------
-      initial             new RRSIGs          new DNSKEY
-      ----------------------------------------------------------------
-      SOA0                SOA1                SOA2
-      RRSIG10(SOA0)       RRSIG11(SOA1)       RRSIG11(SOA2)
-
-      DNSKEY1             DNSKEY1             DNSKEY1
-      DNSKEY10            DNSKEY10            DNSKEY11
-      DNSKEY11            DNSKEY11            DNSKEY12
-      RRSIG1(DNSKEY)      RRSIG1 (DNSKEY)     RRSIG1(DNSKEY)
-      RRSIG10(DNSKEY)     RRSIG11(DNSKEY)     RRSIG11(DNSKEY)
-      ----------------------------------------------------------------
-
-      ----------------------------------------------------------------
-      new RRSIGs (II)     new DNSKEY (II)
-      ----------------------------------------------------------------
-      SOA3                SOA4
-      RRSIG12(SOA3)       RRSIG12(SOA4)
-
-      DNSKEY1             DNSKEY1
-      DNSKEY11            DNSKEY12
-      DNSKEY12            DNSKEY13
-      RRSIG1(DNSKEY)      RRSIG1(DNSKEY)
-      RRSIG12(DNSKEY)     RRSIG12(DNSKEY)
-      ----------------------------------------------------------------
-
-              Pre-Publish Key Rollover, Showing Two Rollovers
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 16]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   Note that the key introduced in the "new DNSKEY" phase 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.
-
-4.2.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 signature rollover".
-
-   During the "new DNSKEY" 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, requiring at least
-   the Maximum Zone TTL.
-
-   Double signature ZSK rollover involves three stages as follows:
-
-      ----------------------------------------------------------------
-      initial             new DNSKEY         DNSKEY removal
-      ----------------------------------------------------------------
-      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)
-      ----------------------------------------------------------------
-
-                Double Signature Zone Signing Key Rollover
-
-   initial: Initial Version 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.
-
-   new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is
-      introduced into the key set and all the data in the zone is signed
-      with DNSKEY 10 and DNSKEY 11.  The rollover period will need to
-      continue 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.
-
-   DNSKEY removal: DNSKEY 10 is removed from the zone.  All the
-      signatures from DNSKEY 10 are removed from the zone.  The key set,
-      now only containing DNSKEY 11, is re-signed with DNSKEY 1.
-
-
-
-Kolkman & Gieben             Informational                     [Page 17]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   At every instance, RRSIGs from the previous version of the zone can
-   be verified with the DNSKEY RRSet from the current version and the
-   other way around.  The data from the current version can be verified
-   with the data from the previous version of the zone.  The duration of
-   the "new DNSKEY" phase and the period between rollovers should be at
-   least the Maximum Zone TTL.
-
-   Making sure that the "new DNSKEY" phase lasts until the signature
-   expiration time of the data in initial version of the zone is
-   recommended.  This way all caches are cleared of the old signatures.
-   However, this duration 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.
-
-4.2.1.3.  Pros and Cons of the Schemes
-
-   Pre-publish key rollover: This rollover does not involve signing the
-      zone data twice.  Instead, before the actual rollover, the new key
-      is published in the key set and thus is available for
-      cryptanalysis attacks.  A small disadvantage is that this process
-      requires four steps.  Also the pre-publish scheme involves more
-      parental work when used for KSK rollovers as explained in Section
-      4.2.3.
-
-   Double signature ZSK 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.
-
-4.2.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 key
-   set) in caches can be verified with a new key set and vice versa.
-   Since only the key set is signed with a KSK, zone size considerations
-   do not apply.
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 18]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   --------------------------------------------------------------------
-       initial        new DNSKEY        DS change       DNSKEY removal
-   --------------------------------------------------------------------
-     Parent:
-       SOA0           -------->         SOA1            -------->
-       RRSIGpar(SOA0) -------->         RRSIGpar(SOA1)  -------->
-       DS1            -------->         DS2             -------->
-       RRSIGpar(DS)   -------->         RRSIGpar(DS)    -------->
-
-
-     Child:
-       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)
-   --------------------------------------------------------------------
-
-   Stages of Deployment for a Double Signature Key Signing Key Rollover
-
-   initial: Initial version 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.
-
-   new DNSKEY: During the "new DNSKEY" 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 parent's zone, the
-      zone administrator has to wait at least TTL_DS to make sure that
-      the old DS RR has expired from caches.
-
-   DS change: The parent replaces DS1 with DS2.
-
-   DNSKEY removal: 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 premise that
-   the parent only has one DS RR (per algorithm) per zone.  An
-   alternative mechanism has been considered.  Using an established
-   trust relation, the interaction can be performed in-band, and the
-   removal of the keys by the child can possibly be signaled by the
-   parent.  In this mechanism, there are periods where there are two DS
-
-
-
-Kolkman & Gieben             Informational                     [Page 19]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   RRs at the parent.  Since at the moment of writing the protocol for
-   this interaction has not been developed, further discussion is out of
-   scope for this document.
-
-4.2.3.  Difference Between ZSK and KSK Rollovers
-
-   Note that KSK rollovers and ZSK rollovers are different in the sense
-   that a KSK rollover requires interaction with the parent (and
-   possibly replacing of trust anchors) and the ensuing delay while
-   waiting for it.
-
-   A zone key rollover can be handled in two different ways: pre-publish
-   (Section 4.2.1.1) and double signature (Section 4.2.1.2).
-
-   As the KSK is used to validate the key set and because the KSK is not
-   changed during a ZSK rollover, a cache is able to validate the new
-   key set of the zone.  The pre-publish method would also work for a
-   KSK rollover.  The records that are to be pre-published are the
-   parental DS RRs.  The pre-publish method has some drawbacks for KSKs.
-   We first describe the rollover scheme and then indicate these
-   drawbacks.
-
-   --------------------------------------------------------------------
-     initial         new DS           new DNSKEY      DS/DNSKEY removal
-   --------------------------------------------------------------------
-   Parent:
-     SOA0            SOA1             -------->       SOA2
-     RRSIGpar(SOA0)  RRSIGpar(SOA1)   -------->       RRSIGpar(SOA2)
-     DS1             DS1              -------->       DS2
-                     DS2              -------->
-     RRSIGpar(DS)    RRSIGpar(DS)     -------->       RRSIGpar(DS)
-
-
-   Child:
-     SOA0            -------->        SOA1            SOA1
-     RRSIG10(SOA0)   -------->        RRSIG10(SOA1)   RRSIG10(SOA1)
-                     -------->
-     DNSKEY1         -------->        DNSKEY2         DNSKEY2
-                     -------->
-     DNSKEY10        -------->        DNSKEY10        DNSKEY10
-     RRSIG1 (DNSKEY) -------->        RRSIG2(DNSKEY)  RRSIG2 (DNSKEY)
-     RRSIG10(DNSKEY) -------->        RRSIG10(DNSKEY) RRSIG10(DNSKEY)
-   --------------------------------------------------------------------
-
-      Stages of Deployment for a Pre-Publish Key Signing Key Rollover
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 20]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   When the child zone wants to roll, it notifies the parent during the
-   "new DS" phase and submits the new key (or the corresponding DS) to
-   the parent.  The parent publishes DS1 and DS2, pointing to DNSKEY1
-   and DNSKEY2, respectively.  During the rollover ("new DNSKEY" phase),
-   which can take place as soon as the new DS set propagated through the
-   DNS, the child replaces DNSKEY1 with DNSKEY2.  Immediately after that
-   ("DS/DNSKEY removal" phase), it can notify the parent that the old DS
-   record can be deleted.
-
-   The drawbacks of this scheme are that during the "new DS" phase the
-   parent cannot verify the match between the DS2 RR and DNSKEY2 using
-   the DNS -- as DNSKEY2 is not yet published.  Besides, we introduce a
-   "security lame" key (see Section 4.4.3).  Finally, the child-parent
-   interaction consists of two steps.  The "double signature" method
-   only needs one interaction.
-
-4.2.4.  Automated Key Rollovers
-
-   As keys must be renewed periodically, there is some motivation to
-   automate the rollover process.  Consider the following:
-
-   o  ZSK rollovers are easy to automate as only the child zone is
-      involved.
-
-   o  A KSK rollover needs interaction between parent and child.  Data
-      exchange is needed to provide the new keys to the parent;
-      consequently, this data must be authenticated and integrity must
-      be guaranteed in order to avoid attacks on the rollover.
-
-4.3.  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.
-
-   When the private material of one of your keys is compromised it can
-   be used for as long as a valid trust chain exists.  A trust chain
-   remains intact for
-
-   o  as long as a signature over the compromised key in the trust 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 generally the hardest to
-      update).
-
-
-
-Kolkman & Gieben             Informational                     [Page 21]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   While a trust chain to your compromised key exists, your namespace is
-   vulnerable to abuse by anyone who has obtained illegitimate
-   possession of the 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
-   trust 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 rollover, the malicious key holder can
-   spoof data so that it appears to be valid.
-
-4.3.1.  KSK Compromise
-
-   A zone containing a DNSKEY RRSet with a compromised KSK is vulnerable
-   as long as the compromised KSK is configured as trust anchor or a
-   parental DS points to it.
-
-   A compromised KSK can be used to sign the key set of an attacker's
-   zone.  That zone could be used to poison the DNS.
-
-   Therefore, when the KSK has been compromised, the trust anchor or the
-   parental DS should be replaced as soon as possible.  It is local
-   policy whether to break the trust chain during the emergency
-   rollover.  The trust chain would be broken when the compromised KSK
-   is removed from the child's zone while the parent still has a DS
-   pointing to the compromised KSK (the assumption is that there is only
-   one DS at the parent.  If there are multiple DSes this does not apply
-   -- however the chain of trust of this particular key is broken).
-
-   Note that an attacker's zone still uses the compromised KSK and the
-   presence of a parental DS would cause the data in this zone to appear
-   as valid.  Removing the compromised key would cause the attacker's
-   zone to appear as valid and the child's zone as Bogus.  Therefore, we
-   advise not to remove the KSK before the parent has a DS to a new KSK
-   in place.
-
-4.3.1.1.  Keeping the Chain of Trust Intact
-
-   If we follow this advice, the timing of the replacement of the KSK is
-   somewhat critical.  The goal is to remove the compromised KSK as soon
-   as the new DS RR is available at the parent.  And also make sure that
-   the signature made with a new KSK over the key set with the
-   compromised KSK in it expires just after the new DS appears at the
-   parent, thus removing the old cruft in one swoop.
-
-   The procedure is as follows:
-
-   1.  Introduce a new KSK into the key set, keep the compromised KSK in
-       the key set.
-
-
-
-Kolkman & Gieben             Informational                     [Page 22]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   2.  Sign the key set, with a short validity period.  The validity
-       period should expire shortly after the DS is expected to appear
-       in the parent and the old DSes have expired from caches.
-
-   3.  Upload the DS for this new key to the parent.
-
-   4.  Follow the procedure of the regular KSK rollover: Wait for the DS
-       to appear in the authoritative servers and then wait as long as
-       the TTL of the old DS RRs.  If necessary re-sign the DNSKEY RRSet
-       and modify/extend the expiration time.
-
-   5.  Remove the compromised DNSKEY RR from the zone and re-sign the
-       key set using your "normal" validity interval.
-
-   An additional danger of a key compromise is that the compromised key
-   could be used to facilitate a legitimate DNSKEY/DS rollover and/or
-   nameserver changes at the parent.  When that happens, the domain may
-   be in dispute.  An authenticated out-of-band and secure notify
-   mechanism to contact a parent is needed in this case.
-
-   Note that this is only a problem when the DNSKEY and or DS records
-   are used for authentication at the parent.
-
-4.3.1.2.  Breaking the Chain of Trust
-
-   There are two methods to break the chain of trust.  The first method
-   causes the child zone to appear 'Bogus' to validating resolvers.  The
-   other causes the child zone to appear 'insecure'.  These are
-   described below.
-
-   In the method that causes the child zone to appear 'Bogus' to
-   validating resolvers, the child zone replaces the current KSK with a
-   new one and re-signs the key set.  Next it sends the DS of the new
-   key to the parent.  Only after the parent has placed the new DS in
-   the zone is the child's chain of trust repaired.
-
-   An alternative method of breaking the chain of trust is by removing
-   the DS RRs from the parent zone altogether.  As a result, the child
-   zone would become insecure.
-
-4.3.2.  ZSK Compromise
-
-   Primarily because there is no parental interaction required when a
-   ZSK is compromised, the situation is less severe than with a KSK
-   compromise.  The zone must still be re-signed 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
-
-
-
-Kolkman & Gieben             Informational                     [Page 23]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   with a normal rollover the immediate disappearance of the old
-   compromised key may lead to verification problems.  Also note that as
-   long as the RRSIG over the compromised ZSK is not expired the zone
-   may be still at risk.
-
-4.3.3.  Compromises of Keys Anchored in Resolvers
-
-   A key can also be pre-configured in resolvers.  For instance, if
-   DNSSEC is successfully deployed the root key may be pre-configured in
-   most security aware resolvers.
-
-   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.
-
-   End-users faced with the task of updating an anchored key should
-   always validate the new key.  New keys should be authenticated out-
-   of-band, for example, through the use of an announcement website that
-   is secured using secure sockets (TLS) [21].
-
-4.4.  Parental Policies
-
-4.4.1.  Initial Key Exchanges and Parental Policies Considerations
-
-   The initial key exchange is always subject to the policies set by the
-   parent.  When designing a key exchange policy one should take into
-   account that the authentication and authorization mechanisms used
-   during a key exchange should be as strong as the authentication and
-   authorization mechanisms used for the exchange of delegation
-   information between parent and child.  That is, there is no implicit
-   need in DNSSEC to make the authentication process stronger than it
-   was in DNS.
-
-   Using the DNS itself as the source for the actual DNSKEY material,
-   with an out-of-band check on the validity of the DNSKEY, has the
-   benefit that it reduces the chances of user error.  A DNSKEY query
-   tool can make use of the SEP bit [3] to select the proper key from a
-   DNSSEC key set, 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 chain of trust remains intact
-   once the parent publishes the DS RR indicating the child is secure.
-
-   Note: the out-of-band verification is still needed when the key
-   material is fetched via the DNS.  The parent can never be sure
-   whether or not the DNSKEY RRs have been spoofed.
-
-
-
-Kolkman & Gieben             Informational                     [Page 24]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-4.4.2.  Storing Keys or Hashes?
-
-   When designing a registry system one should consider which of the
-   DNSKEYs and/or the corresponding DSes to store.  Since a child zone
-   might wish to have a DS published using a message digest algorithm
-   not yet understood by the registry, the registry can't count on being
-   able to generate the DS record from a raw DNSKEY.  Thus, we recommend
-   that registry systems at least support storing DS records.
-
-   It may also be useful to store DNSKEYs, since having them may help
-   during troubleshooting and, as long as the child's chosen message
-   digest is supported, the overhead of generating DS records from them
-   is minimal.  Having an out-of-band mechanism, such as a registry
-   directory (e.g., Whois), to find out which keys are used to generate
-   DS Resource Records for specific owners and/or zones may also help
-   with troubleshooting.
-
-   The storage considerations also relate to the design of the customer
-   interface and the method by which data is transferred between
-   registrant and registry; Will the child zone administrator be able to
-   upload DS RRs with unknown hash algorithms or does the interface only
-   allow DNSKEYs?  In the registry-registrar model, one can use the
-   DNSSEC extensions to the Extensible Provisioning Protocol (EPP) [15],
-   which allows transfer of DS RRs and optionally DNSKEY RRs.
-
-4.4.3.  Security Lameness
-
-   Security lameness is defined as what happens when a parent has a DS
-   RR pointing to a non-existing DNSKEY RR.  When this happens, the
-   child's zone may be marked "Bogus" by verifying DNS clients.
-
-   As part of a comprehensive delegation check, the parent could, at key
-   exchange time, verify that the child's key is actually configured in
-   the DNS.  However, if a parent does not understand the hashing
-   algorithm used by child, the parental checks are limited to only
-   comparing the key id.
-
-   Child zones should be very careful in removing DNSKEY material,
-   specifically SEP keys, for which a DS RR exists.
-
-   Once a zone is "security lame", a fix (e.g., removing a DS RR) will
-   take time to propagate through the DNS.
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 25]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-4.4.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 minimizes 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
-   validity periods longer than 2 days.  We recommend an absolute
-   minimum for a DS signature validity period of a few days.
-
-   The maximum signature validity period of the DS record depends on how
-   long child zones are willing to be vulnerable after a key compromise.
-   On the other hand, shortening the DS signature validity interval
-   increases the operational risk for the parent.  Therefore, the parent
-   may have policy to use a signature validity interval that is
-   considerably longer than the child would hope for.
-
-   A compromise between the operational constraints of the parent and
-   minimizing damage for the child may result in a DS signature validity
-   period somewhere between a week and months.
-
-   In addition to the signature validity period, which sets a lower
-   bound on the number of times the zone owner will need to sign the
-   zone data and which sets an upper bound to the time a child is
-   vulnerable after key compromise, there is the TTL value on the DS
-   RRs.  Shortening the TTL means that the authoritative servers will
-   see more queries.  But on the other hand, a short TTL lowers the
-   persistence of DS RRSets in caches thereby increasing the speed with
-   which updated DS RRSets propagate through the DNS.
-
-5.  Security Considerations
-
-   DNSSEC adds data integrity to the DNS.  This document tries to assess
-   the operational considerations to maintain 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.
-
-6.  Acknowledgments
-
-   Most of the ideas in this document were the result of collective
-   efforts during workshops, discussions, and tryouts.
-
-   At the risk of forgetting individuals who were the original
-   contributors of the ideas, we would like to acknowledge people who
-
-
-
-Kolkman & Gieben             Informational                     [Page 26]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   were actively involved in the compilation of this document.  In
-   random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael
-   Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette
-   Olivier Courtay, Sam Weiler, Jelte Jansen, Niall O'Reilly, Holger
-   Zuleger, Ed Lewis, Hilarie Orman, Marcos Sanz, and Peter Koch.
-
-   Some material in this document has been copied from RFC 2541 [12].
-
-   Mike StJohns designed the key exchange between parent and child
-   mentioned in the last paragraph of Section 4.2.2
-
-   Section 4.2.4 was supplied by G. Guette and O. Courtay.
-
-   Emma Bretherick, Adrian Bedford, and Lindy Foster corrected many of
-   the spelling and style issues.
-
-   Kolkman and Gieben take the blame for introducing all miscakes (sic).
-
-   While working on this document, Kolkman was employed by the RIPE NCC
-   and Gieben was employed by NLnet Labs.
-
-7.  References
-
-7.1.  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]   Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System
-         KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP)
-         Flag", RFC 3757, May 2004.
-
-   [4]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "DNS Security Introduction and Requirements", RFC 4033, March
-         2005.
-
-   [5]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Resource Records for the DNS Security Extensions", RFC 4034,
-         March 2005.
-
-   [6]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Protocol Modifications for the DNS Security Extensions", RFC
-         4035, March 2005.
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 27]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-7.2.  Informative References
-
-   [7]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-   [8]   Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August
-         1996.
-
-   [9]   Vixie, P., "A Mechanism for Prompt Notification of Zone Changes
-         (DNS NOTIFY)", RFC 1996, August 1996.
-
-   [10]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
-         Update", RFC 3007, November 2000.
-
-   [11]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
-         RFC 2308, March 1998.
-
-   [12]  Eastlake, D., "DNS Security Operational Considerations", RFC
-         2541, March 1999.
-
-   [13]  Orman, H. and P. Hoffman, "Determining Strengths For Public
-         Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766,
-         April 2004.
-
-   [14]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
-         Requirements for Security", BCP 106, RFC 4086, June 2005.
-
-   [15]  Hollenbeck, S., "Domain Name System (DNS) Security Extensions
-         Mapping for the Extensible Provisioning Protocol (EPP)", RFC
-         4310, December 2005.
-
-   [16]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
-         Sizes", The Journal of Cryptology 14 (255-293), 2001.
-
-   [17]  Schneier, B., "Applied Cryptography: Protocols, Algorithms, and
-         Source Code in C", ISBN (hardcover) 0-471-12845-7, ISBN
-         (paperback) 0-471-59756-2, Published by John Wiley & Sons Inc.,
-         1996.
-
-   [18]  Rose, S., "NIST DNSSEC workshop notes", June 2001.
-
-   [19]  Jansen, J., "Use of RSA/SHA-256 DNSKEY and RRSIG Resource
-         Records in DNSSEC", Work in Progress, January 2006.
-
-   [20]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
-         Resource Records (RRs)", RFC 4509, May 2006.
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 28]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   [21]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
-         T. Wright, "Transport Layer Security (TLS) Extensions", RFC
-         4366, April 2006.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 29]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-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 have given a more elaborate
-   explanation of the meaning.  Note that these explanations should not
-   be seen as authoritative.
-
-   Anchored key: A DNSKEY configured in resolvers around the globe.
-      This key is hard to update, hence the term anchored.
-
-   Bogus: Also see Section 5 of [4].  An RRSet in DNSSEC is marked
-      "Bogus" when a signature of an RRSet does not validate against a
-      DNSKEY.
-
-   Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is used
-      exclusively for signing the apex key set.  The fact that a key is
-      a KSK is only relevant to the signing tool.
-
-   Key size: The term 'key size' can be substituted by 'modulus size'
-      throughout the document.  It is mathematically more correct to use
-      modulus size, but as this is a document directed at operators we
-      feel more at ease with the term key size.
-
-   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 (mathematically related) 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.
-
-   Key rollover: A key rollover (also called key supercession in some
-      environments) is the act of replacing one key pair with another at
-      the end of a key effectivity period.
-
-   Secure Entry Point (SEP) key: A KSK that has a parental DS record
-      pointing to it or is configured as a trust anchor.  Although not
-      required by the protocol, we recommend that the SEP flag [3] is
-      set on these keys.
-
-   Self-signature: This only applies to signatures over DNSKEYs; a
-      signature made with DNSKEY x, over DNSKEY x is called a self-
-      signature.  Note: without further information, self-signatures
-      convey no trust.  They are useful to check the authenticity of the
-      DNSKEY, i.e., they can be used as a hash.
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 30]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-   Singing the zone file: The term used for the event where an
-      administrator joyfully signs its zone file while producing melodic
-      sound patterns.
-
-   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.
-
-   Zone Signing Key (ZSK): 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.
-
-   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 How-To
-
-   Using the pre-published signature scheme and the most conservative
-   method to assure oneself that data does not live in caches, here
-   follows the "how-to".
-
-   Step 0: The preparation: Create two keys and publish both in your key
-      set.  Mark one of the keys "active" and the other "published".
-      Use the "active" key for signing your zone data.  Store the
-      private part of the "published" key, preferably off-line.  The
-      protocol does not provide for attributes to mark a key as active
-      or published.  This is something you have to do on your own,
-      through the use of a notebook or key management tool.
-
-   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 "published" to sign
-      your data (i.e., mark it "active").  Stop using the key that was
-      marked "active"; mark it "rolled".
-
-   Step 3: It is safe to engage in a new rollover (Step 1) after at
-      least one signature validity period.
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 31]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-Appendix C.  Typographic Conventions
-
-   The following typographic conventions are used in this document:
-
-   Key notation: A key is denoted by DNSKEYx, where x is a number or an
-   identifier, 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.0.2.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".
-
-   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: SOAs are represented as SOAx, where x is the
-   serial number.
-
-   Using this notation the following signed zone:
-
-   example.net.      86400  IN SOA  ns.example.net. bert.example.net. (
-                            2006022100   ; serial
-                            86400        ; refresh (  24 hours)
-                            7200         ; retry   (   2 hours)
-                            3600000      ; expire  (1000 hours)
-                            28800 )      ; minimum (   8 hours)
-                     86400  RRSIG   SOA 5 2 86400 20130522213204 (
-                                  20130422213204 14 example.net.
-                                  cmL62SI6iAX46xGNQAdQ... )
-                     86400  NS      a.iana-servers.net.
-                     86400  NS      b.iana-servers.net.
-                     86400  RRSIG   NS 5 2 86400 20130507213204 (
-                                  20130407213204 14 example.net.
-                                  SO5epiJei19AjXoUpFnQ ... )
-                     86400  DNSKEY  256 3 5 (
-                                  EtRB9MP5/AvOuVO0I8XDxy0... ) ; id = 14
-                     86400  DNSKEY  257 3 5 (
-                                  gsPW/Yy19GzYIY+Gnr8HABU... ) ; id = 15
-                     86400  RRSIG   DNSKEY 5 2 86400 20130522213204 (
-                                  20130422213204 14 example.net.
-                                  J4zCe8QX4tXVGjV4e1r9... )
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 32]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-                     86400  RRSIG   DNSKEY 5 2 86400 20130522213204 (
-                                  20130422213204 15 example.net.
-                                  keVDCOpsSeDReyV6O... )
-                     86400  RRSIG   NSEC 5 2 86400 20130507213204 (
-                                  20130407213204 14 example.net.
-                                  obj3HEp1GjnmhRjX... )
-   a.example.net.    86400  IN TXT  "A label"
-                     86400  RRSIG   TXT 5 3 86400 20130507213204 (
-                                  20130407213204 14 example.net.
-                                  IkDMlRdYLmXH7QJnuF3v... )
-                     86400  NSEC    b.example.com. TXT RRSIG NSEC
-                     86400  RRSIG   NSEC 5 3 86400 20130507213204 (
-                                  20130407213204 14 example.net.
-                                  bZMjoZ3bHjnEz0nIsPMM... )
-                     ...
-
-   is reduced to the following representation:
-
-       SOA2006022100
-       RRSIG14(SOA2006022100)
-       DNSKEY14
-       DNSKEY15
-
-       RRSIG14(KEY)
-       RRSIG15(KEY)
-
-   The rest of the zone data has the same signature as the SOA record,
-   i.e., an RRSIG created with DNSKEY 14.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 33]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-Authors' Addresses
-
-   Olaf M. Kolkman
-   NLnet Labs
-   Kruislaan 419
-   Amsterdam  1098 VA
-   The Netherlands
-
-   EMail: olaf@nlnetlabs.nl
-   URI:   http://www.nlnetlabs.nl
-
-
-   R. (Miek) Gieben
-
-   EMail: miek@miek.nl
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 34]
-
-RFC 4641              DNSSEC Operational Practices        September 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   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.
-
-Intellectual Property
-
-   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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Kolkman & Gieben             Informational                     [Page 35]
-
diff --git a/contrib/bind9/doc/rfc/rfc4648.txt b/contrib/bind9/doc/rfc/rfc4648.txt
deleted file mode 100644
index c7599b4..0000000
--- a/contrib/bind9/doc/rfc/rfc4648.txt
+++ /dev/null
@@ -1,1011 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       S. Josefsson
-Request for Comments: 4648                                           SJD
-Obsoletes: 3548                                             October 2006
-Category: Standards Track
-
-
-             The Base16, Base32, and Base64 Data Encodings
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   This document describes the commonly used base 64, base 32, and base
-   16 encoding schemes.  It also discusses the use of line-feeds in
-   encoded data, use of padding in encoded data, use of non-alphabet
-   characters in encoded data, use of different encoding alphabets, and
-   canonical encodings.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 1]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-Table of Contents
-
-   1. Introduction ....................................................3
-   2. Conventions Used in This Document ...............................3
-   3. Implementation Discrepancies ....................................3
-      3.1. Line Feeds in Encoded Data .................................3
-      3.2. Padding of Encoded Data ....................................4
-      3.3. Interpretation of Non-Alphabet Characters in Encoded Data ..4
-      3.4. Choosing the Alphabet ......................................4
-      3.5. Canonical Encoding .........................................5
-   4. Base 64 Encoding ................................................5
-   5. Base 64 Encoding with URL and Filename Safe Alphabet ............7
-   6. Base 32 Encoding ................................................8
-   7. Base 32 Encoding with Extended Hex Alphabet ....................10
-   8. Base 16 Encoding ...............................................10
-   9. Illustrations and Examples .....................................11
-   10. Test Vectors ..................................................12
-   11. ISO C99 Implementation of Base64 ..............................14
-   12. Security Considerations .......................................14
-   13. Changes Since RFC 3548 ........................................15
-   14. Acknowledgements ..............................................15
-   15. Copying Conditions ............................................15
-   16. References ....................................................16
-      16.1. Normative References .....................................16
-      16.2. Informative References ...................................16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 2]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-1.  Introduction
-
-   Base encoding of data is used in many situations to store or transfer
-   data in environments that, perhaps for legacy reasons, are restricted
-   to US-ASCII [1] data.  Base encoding can also be used in new
-   applications that do not have legacy restrictions, simply because it
-   makes it possible to manipulate objects with text editors.
-
-   In the past, different applications have had different requirements
-   and thus sometimes implemented base encodings in slightly different
-   ways.  Today, protocol specifications sometimes use base encodings in
-   general, and "base64" in particular, without a precise description or
-   reference.  Multipurpose Internet Mail Extensions (MIME) [4] is often
-   used as a reference for base64 without considering the consequences
-   for line-wrapping or non-alphabet characters.  The purpose of this
-   specification is to establish common alphabet and encoding
-   considerations.  This will hopefully reduce ambiguity in other
-   documents, leading to better interoperability.
-
-2.  Conventions Used in This Document
-
-   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 [2].
-
-3.  Implementation Discrepancies
-
-   Here we discuss the discrepancies between base encoding
-   implementations in the past and, where appropriate, mandate a
-   specific recommended behavior for the future.
-
-3.1.  Line Feeds in Encoded Data
-
-   MIME [4] is often used as a reference for base 64 encoding.  However,
-   MIME does not define "base 64" per se, but rather a "base 64 Content-
-   Transfer-Encoding" for use within MIME.  As such, MIME enforces a
-   limit on line length of base 64-encoded data to 76 characters.  MIME
-   inherits the encoding from Privacy Enhanced Mail (PEM) [3], stating
-   that it is "virtually identical"; however, PEM uses a line length of
-   64 characters.  The MIME and PEM limits are both due to limits within
-   SMTP.
-
-   Implementations MUST NOT add line feeds to base-encoded data unless
-   the specification referring to this document explicitly directs base
-   encoders to add line feeds after a specific number of characters.
-
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 3]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-3.2.  Padding of Encoded Data
-
-   In some circumstances, the use of padding ("=") in base-encoded data
-   is not required or used.  In the general case, when assumptions about
-   the size of transported data cannot be made, padding is required to
-   yield correct decoded data.
-
-   Implementations MUST include appropriate pad characters at the end of
-   encoded data unless the specification referring to this document
-   explicitly states otherwise.
-
-   The base64 and base32 alphabets use padding, as described below in
-   sections 4 and 6, but the base16 alphabet does not need it; see
-   section 8.
-
-3.3.  Interpretation of Non-Alphabet Characters in Encoded Data
-
-   Base encodings use a specific, reduced alphabet to encode binary
-   data.  Non-alphabet characters could exist within base-encoded data,
-   caused by data corruption or by design.  Non-alphabet characters may
-   be exploited as a "covert channel", where non-protocol data can be
-   sent for nefarious purposes.  Non-alphabet characters might also be
-   sent in order to exploit implementation errors leading to, e.g.,
-   buffer overflow attacks.
-
-   Implementations MUST reject the encoded data if it contains
-   characters outside the base alphabet when interpreting base-encoded
-   data, unless the specification referring to this document explicitly
-   states otherwise.  Such specifications may instead state, as MIME
-   does, that characters outside the base encoding alphabet should
-   simply be ignored when interpreting data ("be liberal in what you
-   accept").  Note that this means that any adjacent carriage return/
-   line feed (CRLF) characters constitute "non-alphabet characters" and
-   are ignored.  Furthermore, such specifications MAY ignore the pad
-   character, "=", treating it as non-alphabet data, if it is present
-   before the end of the encoded data.  If more than the allowed number
-   of pad characters is found at the end of the string (e.g., a base 64
-   string terminated with "==="), the excess pad characters MAY also be
-   ignored.
-
-3.4.  Choosing the Alphabet
-
-   Different applications have different requirements on the characters
-   in the alphabet.  Here are a few requirements that determine which
-   alphabet should be used:
-
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 4]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-   o  Handled by humans.  The characters "0" and "O" are easily
-      confused, as are "1", "l", and "I".  In the base32 alphabet below,
-      where 0 (zero) and 1 (one) are not present, a decoder may
-      interpret 0 as O, and 1 as I or L depending on case.  (However, by
-      default it should not; see previous section.)
-
-   o  Encoded into structures that mandate other requirements.  For base
-      16 and base 32, this determines the use of upper- or lowercase
-      alphabets.  For base 64, the non-alphanumeric characters (in
-      particular, "/") may be problematic in file names and URLs.
-
-   o  Used as identifiers.  Certain characters, notably "+" and "/" in
-      the base 64 alphabet, are treated as word-breaks by legacy text
-      search/index tools.
-
-   There is no universally accepted alphabet that fulfills all the
-   requirements.  For an example of a highly specialized variant, see
-   IMAP [8].  In this document, we document and name some currently used
-   alphabets.
-
-3.5.  Canonical Encoding
-
-   The padding step in base 64 and base 32 encoding can, if improperly
-   implemented, lead to non-significant alterations of the encoded data.
-   For example, if the input is only one octet for a base 64 encoding,
-   then all six bits of the first symbol are used, but only the first
-   two bits of the next symbol are used.  These pad bits MUST be set to
-   zero by conforming encoders, which is described in the descriptions
-   on padding below.  If this property do not hold, there is no
-   canonical representation of base-encoded data, and multiple base-
-   encoded strings can be decoded to the same binary data.  If this
-   property (and others discussed in this document) holds, a canonical
-   encoding is guaranteed.
-
-   In some environments, the alteration is critical and therefore
-   decoders MAY chose to reject an encoding if the pad bits have not
-   been set to zero.  The specification referring to this may mandate a
-   specific behaviour.
-
-4.  Base 64 Encoding
-
-   The following description of base 64 is derived from [3], [4], [5],
-   and [6].  This encoding may be referred to as "base64".
-
-   The Base 64 encoding is designed to represent arbitrary sequences of
-   octets in a form that allows the use of both upper- and lowercase
-   letters but that need not be human readable.
-
-
-
-
-Josefsson                   Standards Track                     [Page 5]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-   A 65-character subset of US-ASCII is used, enabling 6 bits to be
-   represented per printable character.  (The extra 65th character, "=",
-   is used to signify a special processing function.)
-
-   The encoding process represents 24-bit groups of input bits as output
-   strings of 4 encoded characters.  Proceeding from left to right, a
-   24-bit input group is formed by concatenating 3 8-bit input groups.
-   These 24 bits are then treated as 4 concatenated 6-bit groups, each
-   of which is translated into a single character in the base 64
-   alphabet.
-
-   Each 6-bit group is used as an index into an array of 64 printable
-   characters.  The character referenced by the index is placed in the
-   output string.
-
-                      Table 1: The Base 64 Alphabet
-
-     Value Encoding  Value Encoding  Value Encoding  Value Encoding
-         0 A            17 R            34 i            51 z
-         1 B            18 S            35 j            52 0
-         2 C            19 T            36 k            53 1
-         3 D            20 U            37 l            54 2
-         4 E            21 V            38 m            55 3
-         5 F            22 W            39 n            56 4
-         6 G            23 X            40 o            57 5
-         7 H            24 Y            41 p            58 6
-         8 I            25 Z            42 q            59 7
-         9 J            26 a            43 r            60 8
-        10 K            27 b            44 s            61 9
-        11 L            28 c            45 t            62 +
-        12 M            29 d            46 u            63 /
-        13 N            30 e            47 v
-        14 O            31 f            48 w         (pad) =
-        15 P            32 g            49 x
-        16 Q            33 h            50 y
-
-   Special processing is performed if fewer than 24 bits are available
-   at the end of the data being encoded.  A full encoding quantum is
-   always completed at the end of a quantity.  When fewer than 24 input
-   bits are available in an input group, bits with value zero are added
-   (on the right) to form an integral number of 6-bit groups.  Padding
-   at the end of the data is performed using the '=' character.  Since
-   all base 64 input is an integral number of octets, only the following
-   cases can arise:
-
-   (1) The final quantum of encoding input is an integral multiple of 24
-       bits; here, the final unit of encoded output will be an integral
-       multiple of 4 characters with no "=" padding.
-
-
-
-Josefsson                   Standards Track                     [Page 6]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-   (2) The final quantum of encoding input is exactly 8 bits; here, the
-       final unit of encoded output will be two characters followed by
-       two "=" padding characters.
-
-   (3) The final quantum of encoding input is exactly 16 bits; here, the
-       final unit of encoded output will be three characters followed by
-       one "=" padding character.
-
-5.  Base 64 Encoding with URL and Filename Safe Alphabet
-
-   The Base 64 encoding with an URL and filename safe alphabet has been
-   used in [12].
-
-   An alternative alphabet has been suggested that would use "~" as the
-   63rd character.  Since the "~" character has special meaning in some
-   file system environments, the encoding described in this section is
-   recommended instead.  The remaining unreserved URI character is ".",
-   but some file system environments do not permit multiple "." in a
-   filename, thus making the "." character unattractive as well.
-
-   The pad character "=" is typically percent-encoded when used in an
-   URI [9], but if the data length is known implicitly, this can be
-   avoided by skipping the padding; see section 3.2.
-
-   This encoding may be referred to as "base64url".  This encoding
-   should not be regarded as the same as the "base64" encoding and
-   should not be referred to as only "base64".  Unless clarified
-   otherwise, "base64" refers to the base 64 in the previous section.
-
-   This encoding is technically identical to the previous one, except
-   for the 62:nd and 63:rd alphabet character, as indicated in Table 2.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 7]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-         Table 2: The "URL and Filename safe" Base 64 Alphabet
-
-     Value Encoding  Value Encoding  Value Encoding  Value Encoding
-         0 A            17 R            34 i            51 z
-         1 B            18 S            35 j            52 0
-         2 C            19 T            36 k            53 1
-         3 D            20 U            37 l            54 2
-         4 E            21 V            38 m            55 3
-         5 F            22 W            39 n            56 4
-         6 G            23 X            40 o            57 5
-         7 H            24 Y            41 p            58 6
-         8 I            25 Z            42 q            59 7
-         9 J            26 a            43 r            60 8
-        10 K            27 b            44 s            61 9
-        11 L            28 c            45 t            62 - (minus)
-        12 M            29 d            46 u            63 _
-        13 N            30 e            47 v           (underline)
-        14 O            31 f            48 w
-        15 P            32 g            49 x
-        16 Q            33 h            50 y         (pad) =
-
-6.  Base 32 Encoding
-
-   The following description of base 32 is derived from [11] (with
-   corrections).  This encoding may be referred to as "base32".
-
-   The Base 32 encoding is designed to represent arbitrary sequences of
-   octets in a form that needs to be case insensitive but that need not
-   be human readable.
-
-   A 33-character subset of US-ASCII is used, enabling 5 bits to be
-   represented per printable character.  (The extra 33rd character, "=",
-   is used to signify a special processing function.)
-
-   The encoding process represents 40-bit groups of input bits as output
-   strings of 8 encoded characters.  Proceeding from left to right, a
-   40-bit input group is formed by concatenating 5 8bit input groups.
-   These 40 bits are then treated as 8 concatenated 5-bit groups, each
-   of which is translated into a single character in the base 32
-   alphabet.  When a bit stream is encoded via the base 32 encoding, the
-   bit stream must be presumed to be ordered with the most-significant-
-   bit first.  That is, the first bit in the stream will be the high-
-   order bit in the first 8bit byte, the eighth bit will be the low-
-   order bit in the first 8bit byte, and so on.
-
-
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 8]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-   Each 5-bit group is used as an index into an array of 32 printable
-   characters.  The character referenced by the index is placed in the
-   output string.  These characters, identified in Table 3, below, are
-   selected from US-ASCII digits and uppercase letters.
-
-                     Table 3: The Base 32 Alphabet
-
-     Value Encoding  Value Encoding  Value Encoding  Value Encoding
-         0 A             9 J            18 S            27 3
-         1 B            10 K            19 T            28 4
-         2 C            11 L            20 U            29 5
-         3 D            12 M            21 V            30 6
-         4 E            13 N            22 W            31 7
-         5 F            14 O            23 X
-         6 G            15 P            24 Y         (pad) =
-         7 H            16 Q            25 Z
-         8 I            17 R            26 2
-
-   Special processing is performed if fewer than 40 bits are available
-   at the end of the data being encoded.  A full encoding quantum is
-   always completed at the end of a body.  When fewer than 40 input bits
-   are available in an input group, bits with value zero are added (on
-   the right) to form an integral number of 5-bit groups.  Padding at
-   the end of the data is performed using the "=" character.  Since all
-   base 32 input is an integral number of octets, only the following
-   cases can arise:
-
-   (1) The final quantum of encoding input is an integral multiple of 40
-       bits; here, the final unit of encoded output will be an integral
-       multiple of 8 characters with no "=" padding.
-
-   (2) The final quantum of encoding input is exactly 8 bits; here, the
-       final unit of encoded output will be two characters followed by
-       six "=" padding characters.
-
-   (3) The final quantum of encoding input is exactly 16 bits; here, the
-       final unit of encoded output will be four characters followed by
-       four "=" padding characters.
-
-   (4) The final quantum of encoding input is exactly 24 bits; here, the
-       final unit of encoded output will be five characters followed by
-       three "=" padding characters.
-
-   (5) The final quantum of encoding input is exactly 32 bits; here, the
-       final unit of encoded output will be seven characters followed by
-       one "=" padding character.
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 9]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-7.  Base 32 Encoding with Extended Hex Alphabet
-
-   The following description of base 32 is derived from [7].  This
-   encoding may be referred to as "base32hex".  This encoding should not
-   be regarded as the same as the "base32" encoding and should not be
-   referred to as only "base32".  This encoding is used by, e.g.,
-   NextSECure3 (NSEC3) [10].
-
-   One property with this alphabet, which the base64 and base32
-   alphabets lack, is that encoded data maintains its sort order when
-   the encoded data is compared bit-wise.
-
-   This encoding is identical to the previous one, except for the
-   alphabet.  The new alphabet is found in Table 4.
-
-                 Table 4: The "Extended Hex" Base 32 Alphabet
-
-         Value Encoding  Value Encoding  Value Encoding  Value Encoding
-             0 0             9 9            18 I            27 R
-             1 1            10 A            19 J            28 S
-             2 2            11 B            20 K            29 T
-             3 3            12 C            21 L            30 U
-             4 4            13 D            22 M            31 V
-             5 5            14 E            23 N
-             6 6            15 F            24 O         (pad) =
-             7 7            16 G            25 P
-             8 8            17 H            26 Q
-
-8.  Base 16 Encoding
-
-   The following description is original but analogous to previous
-   descriptions.  Essentially, Base 16 encoding is the standard case-
-   insensitive hex encoding and may be referred to as "base16" or "hex".
-
-   A 16-character subset of US-ASCII is used, enabling 4 bits to be
-   represented per printable character.
-
-   The encoding process represents 8-bit groups (octets) of input bits
-   as output strings of 2 encoded characters.  Proceeding from left to
-   right, an 8-bit input is taken from the input data.  These 8 bits are
-   then treated as 2 concatenated 4-bit groups, each of which is
-   translated into a single character in the base 16 alphabet.
-
-   Each 4-bit group is used as an index into an array of 16 printable
-   characters.  The character referenced by the index is placed in the
-   output string.
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 10]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-                         Table 5: The Base 16 Alphabet
-
-         Value Encoding  Value Encoding  Value Encoding  Value Encoding
-             0 0             4 4             8 8            12 C
-             1 1             5 5             9 9            13 D
-             2 2             6 6            10 A            14 E
-             3 3             7 7            11 B            15 F
-
-   Unlike base 32 and base 64, no special padding is necessary since a
-   full code word is always available.
-
-9.  Illustrations and Examples
-
-   To translate between binary and a base encoding, the input is stored
-   in a structure, and the output is extracted.  The case for base 64 is
-   displayed in the following figure, borrowed from [5].
-
-            +--first octet--+-second octet--+--third octet--+
-            |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
-            +-----------+---+-------+-------+---+-----------+
-            |5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|
-            +--1.index--+--2.index--+--3.index--+--4.index--+
-
-   The case for base 32 is shown in the following figure, borrowed from
-   [7].  Each successive character in a base-32 value represents 5
-   successive bits of the underlying octet sequence.  Thus, each group
-   of 8 characters represents a sequence of 5 octets (40 bits).
-
-                        1          2          3
-             01234567 89012345 67890123 45678901 23456789
-            +--------+--------+--------+--------+--------+
-            |< 1 >< 2| >< 3 ><|.4 >< 5.|>< 6 ><.|7 >< 8 >|
-            +--------+--------+--------+--------+--------+
-                                                    <===> 8th character
-                                              <====> 7th character
-                                         <===> 6th character
-                                   <====> 5th character
-                             <====> 4th character
-                        <===> 3rd character
-                  <====> 2nd character
-             <===> 1st character
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 11]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-   The following example of Base64 data is from [5], with corrections.
-
-      Input data:  0x14fb9c03d97e
-      Hex:     1   4    f   b    9   c     | 0   3    d   9    7   e
-      8-bit:   00010100 11111011 10011100  | 00000011 11011001 01111110
-      6-bit:   000101 001111 101110 011100 | 000000 111101 100101 111110
-      Decimal: 5      15     46     28       0      61     37     62
-      Output:  F      P      u      c        A      9      l      +
-
-      Input data:  0x14fb9c03d9
-      Hex:     1   4    f   b    9   c     | 0   3    d   9
-      8-bit:   00010100 11111011 10011100  | 00000011 11011001
-                                                      pad with 00
-      6-bit:   000101 001111 101110 011100 | 000000 111101 100100
-      Decimal: 5      15     46     28       0      61     36
-                                                         pad with =
-      Output:  F      P      u      c        A      9      k      =
-
-      Input data:  0x14fb9c03
-      Hex:     1   4    f   b    9   c     | 0   3
-      8-bit:   00010100 11111011 10011100  | 00000011
-                                             pad with 0000
-      6-bit:   000101 001111 101110 011100 | 000000 110000
-      Decimal: 5      15     46     28       0      48
-                                                  pad with =      =
-      Output:  F      P      u      c        A      w      =      =
-
-10.  Test Vectors
-
-   BASE64("") = ""
-
-   BASE64("f") = "Zg=="
-
-   BASE64("fo") = "Zm8="
-
-   BASE64("foo") = "Zm9v"
-
-   BASE64("foob") = "Zm9vYg=="
-
-   BASE64("fooba") = "Zm9vYmE="
-
-   BASE64("foobar") = "Zm9vYmFy"
-
-   BASE32("") = ""
-
-   BASE32("f") = "MY======"
-
-   BASE32("fo") = "MZXQ===="
-
-
-
-Josefsson                   Standards Track                    [Page 12]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-   BASE32("foo") = "MZXW6==="
-
-   BASE32("foob") = "MZXW6YQ="
-
-   BASE32("fooba") = "MZXW6YTB"
-
-   BASE32("foobar") = "MZXW6YTBOI======"
-
-   BASE32-HEX("") = ""
-
-   BASE32-HEX("f") = "CO======"
-
-   BASE32-HEX("fo") = "CPNG===="
-
-   BASE32-HEX("foo") = "CPNMU==="
-
-   BASE32-HEX("foob") = "CPNMUOG="
-
-   BASE32-HEX("fooba") = "CPNMUOJ1"
-
-   BASE32-HEX("foobar") = "CPNMUOJ1E8======"
-
-   BASE16("") = ""
-
-   BASE16("f") = "66"
-
-   BASE16("fo") = "666F"
-
-   BASE16("foo") = "666F6F"
-
-   BASE16("foob") = "666F6F62"
-
-   BASE16("fooba") = "666F6F6261"
-
-   BASE16("foobar") = "666F6F626172"
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 13]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-11.  ISO C99 Implementation of Base64
-
-   An ISO C99 implementation of Base64 encoding and decoding that is
-   believed to follow all recommendations in this RFC is available from:
-
-      http://josefsson.org/base-encoding/
-
-   This code is not normative.
-
-   The code could not be included in this RFC for procedural reasons
-   (RFC 3978 section 5.4).
-
-12.  Security Considerations
-
-   When base encoding and decoding is implemented, care should be taken
-   not to introduce vulnerabilities to buffer overflow attacks, or other
-   attacks on the implementation.  A decoder should not break on invalid
-   input including, e.g., embedded NUL characters (ASCII 0).
-
-   If non-alphabet characters are ignored, instead of causing rejection
-   of the entire encoding (as recommended), a covert channel that can be
-   used to "leak" information is made possible.  The ignored characters
-   could also be used for other nefarious purposes, such as to avoid a
-   string equality comparison or to trigger implementation bugs.  The
-   implications of ignoring non-alphabet characters should be understood
-   in applications that do not follow the recommended practice.
-   Similarly, when the base 16 and base 32 alphabets are handled case
-   insensitively, alteration of case can be used to leak information or
-   make string equality comparisons fail.
-
-   When padding is used, there are some non-significant bits that
-   warrant security concerns, as they may be abused to leak information
-   or used to bypass string equality comparisons or to trigger
-   implementation problems.
-
-   Base encoding visually hides otherwise easily recognized information,
-   such as passwords, but does not provide any computational
-   confidentiality.  This has been known to cause security incidents
-   when, e.g., a user reports details of a network protocol exchange
-   (perhaps to illustrate some other problem) and accidentally reveals
-   the password because she is unaware that the base encoding does not
-   protect the password.
-
-   Base encoding adds no entropy to the plaintext, but it does increase
-   the amount of plaintext available and provide a signature for
-   cryptanalysis in the form of a characteristic probability
-   distribution.
-
-
-
-
-Josefsson                   Standards Track                    [Page 14]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-13.  Changes Since RFC 3548
-
-   Added the "base32 extended hex alphabet", needed to preserve sort
-   order of encoded data.
-
-   Referenced IMAP for the special Base64 encoding used there.
-
-   Fixed the example copied from RFC 2440.
-
-   Added security consideration about providing a signature for
-   cryptoanalysis.
-
-   Added test vectors.
-
-   Fixed typos.
-
-14.  Acknowledgements
-
-   Several people offered comments and/or suggestions, including John E.
-   Hadstate, Tony Hansen, Gordon Mohr, John Myers, Chris Newman, and
-   Andrew Sieber.  Text used in this document are based on earlier RFCs
-   describing specific uses of various base encodings.  The author
-   acknowledges the RSA Laboratories for supporting the work that led to
-   this document.
-
-   This revised version is based in parts on comments and/or suggestions
-   made by Roy Arends, Eric Blake, Brian E Carpenter, Elwyn Davies, Bill
-   Fenner, Sam Hartman, Ted Hardie, Per Hygum, Jelte Jansen, Clement
-   Kent, Tero Kivinen, Paul Kwiatkowski, and Ben Laurie.
-
-15.  Copying Conditions
-
-   Copyright (c) 2000-2006 Simon Josefsson
-
-   Regarding the abstract and sections 1, 3, 8, 10, 12, 13, and 14 of
-   this document, that were written by Simon Josefsson ("the author",
-   for the remainder of this section), the author makes no guarantees
-   and is not responsible for any damage resulting from its use.  The
-   author grants irrevocable permission to anyone to use, modify, and
-   distribute it in any way that does not diminish the rights of anyone
-   else to use, modify, and distribute it, provided that redistributed
-   derivative works do not contain misleading author or version
-   information and do not falsely purport to be IETF RFC documents.
-   Derivative works need not be licensed under similar terms.
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 15]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-16.  References
-
-16.1.  Normative References
-
-   [1]   Cerf, V., "ASCII format for network interchange", RFC 20,
-         October 1969.
-
-   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-16.2.  Informative References
-
-   [3]   Linn, J., "Privacy Enhancement for Internet Electronic Mail:
-         Part I: Message Encryption and Authentication Procedures", RFC
-         1421, February 1993.
-
-   [4]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
-         Extensions (MIME) Part One: Format of Internet Message Bodies",
-         RFC 2045, November 1996.
-
-   [5]   Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
-         "OpenPGP Message Format", RFC 2440, November 1998.
-
-   [6]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "DNS Security Introduction and Requirements", RFC 4033, March
-         2005.
-
-   [7]   Klyne, G. and L. Masinter, "Identifying Composite Media
-         Features", RFC 2938, September 2000.
-
-   [8]   Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
-         4rev1", RFC 3501, March 2003.
-
-   [9]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
-         Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
-         January 2005.
-
-   [10]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNSSEC Hash
-         Authenticated Denial of Existence", Work in Progress, June
-         2006.
-
-   [11]  Myers, J., "SASL GSSAPI mechanisms", Work in Progress, May
-         2000.
-
-   [12]  Wilcox-O'Hearn, B., "Post to P2P-hackers mailing list",
-         http://zgp.org/pipermail/p2p-hackers/2001-September/
-         000315.html, September 2001.
-
-
-
-
-Josefsson                   Standards Track                    [Page 16]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-Author's Address
-
-   Simon Josefsson
-   SJD
-   EMail: simon@josefsson.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 17]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   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.
-
-Intellectual Property
-
-   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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 18]
-
diff --git a/contrib/bind9/doc/rfc/rfc4701.txt b/contrib/bind9/doc/rfc/rfc4701.txt
deleted file mode 100644
index 03e3c54..0000000
--- a/contrib/bind9/doc/rfc/rfc4701.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           M. Stapp
-Request for Comments: 4701                           Cisco Systems, Inc.
-Category: Standards Track                                       T. Lemon
-                                                           Nominum, Inc.
-                                                           A. Gustafsson
-                                          Araneus Information Systems Oy
-                                                            October 2006
-
-
-                A DNS Resource Record (RR) for Encoding
-   Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (2006).
-
-Abstract
-
-   It is possible for Dynamic Host Configuration Protocol (DHCP) clients
-   to attempt to update the same DNS Fully Qualified Domain Name (FQDN)
-   or to update a DNS FQDN that has been added to the DNS for another
-   purpose as they obtain DHCP leases.  Whether the DHCP server or the
-   clients themselves perform the DNS updates, conflicts can arise.  To
-   resolve such conflicts, RFC 4703 proposes storing client identifiers
-   in the DNS to unambiguously associate domain names with the DHCP
-   clients to which they refer.  This memo defines a distinct Resource
-   Record (RR) type for this purpose for use by DHCP clients and
-   servers:  the "DHCID" RR.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al.               Standards Track                     [Page 1]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-Table of Contents
-
-   1. Introduction ....................................................3
-   2. Terminology .....................................................3
-   3. The DHCID RR ....................................................3
-      3.1. DHCID RDATA Format .........................................3
-      3.2. DHCID Presentation Format ..................................4
-      3.3. The DHCID RR Identifier Type Codes .........................4
-      3.4. The DHCID RR Digest Type Code ..............................4
-      3.5. Computation of the RDATA ...................................5
-           3.5.1. Using the Client's DUID .............................5
-           3.5.2. Using the Client Identifier Option ..................6
-           3.5.3. Using the Client's htype and chaddr .................6
-      3.6. Examples ...................................................6
-           3.6.1. Example 1 ...........................................6
-           3.6.2. Example 2 ...........................................7
-           3.6.3. Example 3 ...........................................7
-   4. Use of the DHCID RR .............................................8
-   5. Updater Behavior ................................................8
-   6. Security Considerations .........................................8
-   7. IANA Considerations .............................................9
-   8. Acknowledgements ................................................9
-   9. References ......................................................9
-      9.1. Normative References .......................................9
-      9.2. Informative References ....................................10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al.               Standards Track                     [Page 2]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-1.  Introduction
-
-   A set of procedures to allow DHCP [7] [11] clients and servers to
-   automatically update the DNS ([3], [4]) is proposed in [1].
-
-   Conflicts can arise if multiple DHCP clients wish to use the same DNS
-   name or a DHCP client attempts to use a name added for another
-   purpose.  To resolve such 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 obscure potentially sensitive client identifying
-   information, the data stored is the result of a one-way SHA-256 hash
-   computation.  The hash includes information from the DHCP client's
-   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.
-
-2.  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 [2].
-
-3.  The DHCID RR
-
-   The DHCID RR is defined with mnemonic DHCID and type code 49.  The
-   DHCID RR is only defined in the IN class.  DHCID RRs cause no
-   additional section processing.
-
-3.1.  DHCID RDATA Format
-
-   The RDATA section of a DHCID RR in transmission contains RDLENGTH
-   octets 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 2-octet identifier type, in network byte order,
-
-
-
-Stapp, et al.               Standards Track                     [Page 3]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-   followed by a 1-octet digest type, followed by one or more octets
-   representing the actual identifier:
-
-           < 2 octets >    Identifier type code
-           < 1 octet >     Digest type code
-           < n octets >    Digest (length depends on digest type)
-
-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 [8], Section 3.  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 Identifier Type Codes
-
-   The DHCID RR Identifier Type Code specifies what data from the DHCP
-   client's request was used as input into the hash function.  The
-   identifier type codes are defined in a registry maintained by IANA,
-   as specified in Section 7.  The initial list of assigned values for
-   the identifier type code and that type's identifier is:
-
-
-   +------------------+------------------------------------------------+
-   |  Identifier Type | Identifier                                     |
-   |       Code       |                                                |
-   +------------------+------------------------------------------------+
-   |      0x0000      | The 1-octet 'htype' followed by 'hlen' octets  |
-   |                  | of 'chaddr' from a DHCPv4 client's DHCPREQUEST |
-   |                  | [7].                                           |
-   |      0x0001      | The data octets (i.e., the Type and            |
-   |                  | Client-Identifier fields) from a DHCPv4        |
-   |                  | client's Client Identifier option [10].        |
-   |      0x0002      | The client's DUID (i.e., the data octets of a  |
-   |                  | DHCPv6 client's Client Identifier option [11]  |
-   |                  | or the DUID field from a DHCPv4 client's       |
-   |                  | Client Identifier option [6]).                 |
-   |  0x0003 - 0xfffe | Undefined; available to be assigned by IANA.   |
-   |      0xffff      | Undefined; RESERVED.                           |
-   +------------------+------------------------------------------------+
-
-3.4.  The DHCID RR Digest Type Code
-
-   The DHCID RR Digest Type Code is an identifier for the digest
-   algorithm used.  The digest is calculated over an identifier and the
-   canonical FQDN as described in the next section.
-
-
-
-Stapp, et al.               Standards Track                     [Page 4]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-   The digest type codes are defined in a registry maintained by IANA,
-   as specified in Section 7.  The initial list of assigned values for
-   the digest type codes is: value 0 is reserved, and value 1 is
-   SHA-256.  Reserving other types requires IETF standards action.
-   Defining new values will also require IETF standards action to
-   document how DNS updaters are to deal with multiple digest types.
-
-3.5.  Computation of the RDATA
-
-   The DHCID RDATA is formed by concatenating the 2-octet identifier
-   type code with variable-length data.
-
-   The RDATA for all type codes other than 0xffff, which is reserved for
-   future expansion, is formed by concatenating the 2-octet identifier
-   type code, the 1-octet digest type code, and the digest value (32
-   octets for SHA-256).
-
-       < identifier-type > < digest-type > < digest >
-
-   The input to the digest hash function is defined to be:
-
-       digest = SHA-256(< identifier > < FQDN >)
-
-   The FQDN is represented in the buffer in the canonical wire format as
-   described in [9], Section 6.2.  The identifier type code and the
-   identifier are related as specified in Section 3.3: the identifier
-   type code describes the source of the identifier.
-
-   A DHCPv4 updater uses the 0x0002 type code if a Client Identifier
-   option is present in the DHCPv4 messages and it is encoded as
-   specified in [6].  Otherwise, the updater uses 0x0001 if a Client
-   Identifier option is present, and 0x0000 if not.
-
-   A DHCPv6 updater always uses the 0x0002 type code.
-
-3.5.1.  Using the Client's DUID
-
-   When the updater is using the Client's DUID (either from a DHCPv6
-   Client Identifier option or from a portion of the DHCPv4 Client
-   Identifier option encoded as specified in [6]), the first two octets
-   of the DHCID RR MUST be 0x0002, in network byte order.  The third
-   octet is the digest type code (1 for SHA-256).  The rest of the DHCID
-   RR MUST contain the results of computing the SHA-256 hash across the
-   octets of the DUID followed by the FQDN.
-
-
-
-
-
-
-
-Stapp, et al.               Standards Track                     [Page 5]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-3.5.2.  Using the Client Identifier Option
-
-   When the updater is using the DHCPv4 Client Identifier option sent by
-   the client in its DHCPREQUEST message, the first two octets of the
-   DHCID RR MUST be 0x0001, in network byte order.  The third octet is
-   the digest type code (1 for SHA-256).  The rest of the DHCID RR MUST
-   contain the results of computing the SHA-256 hash across the data
-   octets (i.e., the Type and Client-Identifier fields) of the option,
-   followed by the FQDN.
-
-3.5.3.  Using the Client's htype and chaddr
-
-   When the updater is using the client's link-layer address as the
-   identifier, the first two octets of the DHCID RDATA MUST be zero.
-   The third octet is the digest type code (1 for SHA-256).  To generate
-   the rest of the resource record, the updater computes a one-way hash
-   using the SHA-256 algorithm across a buffer containing the client's
-   network hardware type, link-layer address, and the FQDN data.
-   Specifically, the first octet 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 octets of the
-   'chaddr' field in the client's DHCPREQUEST message follow, in the
-   same order in which the octets appear in the DHCPREQUEST message.
-   The number of significant octets in the 'chaddr' field is specified
-   in the 'hlen' field of the DHCPREQUEST message.  The FQDN data, as
-   specified above, follows.
-
-3.6.  Examples
-
-3.6.1.  Example 1
-
-   A DHCP server allocates the IPv6 address 2001:DB8::1234:5678 to a
-   client that included the DHCPv6 client-identifier option data 00:01:
-   00:06:41:2d:f1:66:01:02:03:04:05:06 in its DHCPv6 request.  The
-   server updates the name "chi6.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 octets
-   to the value 0x0002, the 1-octet digest type to 1 for SHA-256, and
-   performing a SHA-256 hash computation across a buffer containing the
-   14 octets from the client-id option and the FQDN (represented as
-   specified in Section 3.5).
-
-     chi6.example.com.     AAAA    2001:DB8::1234:5678
-     chi6.example.com.     DHCID   ( AAIBY2/AuCccgoJbsaxcQc9TUapptP69l
-                                     OjxfNuVAA2kjEA= )
-
-   If the DHCID RR type is not supported, the RDATA would be encoded
-   [13] as:
-
-
-
-Stapp, et al.               Standards Track                     [Page 6]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-     \# 35 ( 000201636fc0b8271c82825bb1ac5c41cf5351aa69b4febd94e8f17cd
-             b95000da48c40 )
-
-3.6.2.  Example 2
-
-   A DHCP server allocates the IPv4 address 192.0.2.2 to a client that
-   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 octets to the value 0x0001, the 1-octet digest
-   type to 1 for SHA-256, and performing a SHA-256 hash computation
-   across a buffer containing the seven octets from the client-id option
-   and the FQDN (represented as specified in Section 3.5).
-
-     chi.example.com.      A       192.0.2.2
-     chi.example.com.      DHCID   ( AAEBOSD+XR3Os/0LozeXVqcNc7FwCfQdW
-                                     L3b/NaiUDlW2No= )
-
-   If the DHCID RR type is not supported, the RDATA would be encoded
-   [13] as:
-
-     \# 35 ( 0001013920fe5d1dceb3fd0ba3379756a70d73b17009f41d58bddbfcd
-             6a2503956d8da )
-
-3.6.3.  Example 3
-
-   A DHCP server allocating the IPv4 address 192.0.2.3 to a client with
-   the 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
-   octets to zero, the 1-octet digest type to 1 for SHA-256, and
-   performing an SHA-256 hash computation across a buffer containing the
-   1-octet 'htype' value for Ethernet, 0x01, followed by the six octets
-   of the Ethernet MAC address, and the domain name (represented as
-   specified in Section 3.5).
-
-     client.example.com.   A       192.0.2.3
-     client.example.com.   DHCID   ( AAABxLmlskllE0MVjd57zHcWmEH3pCQ6V
-                                     ytcKD//7es/deY= )
-
-   If the DHCID RR type is not supported, the RDATA would be encoded
-   [13] as:
-
-     \# 35 ( 000001c4b9a5b249651343158dde7bcc77169841f7a4243a572b5c283
-             fffedeb3f75e6 )
-
-
-
-
-
-Stapp, et al.               Standards Track                     [Page 7]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-4.  Use of the DHCID RR
-
-   This RR MUST NOT be used for any purpose other than that detailed in
-   [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
-   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 obscure the client's identity information,
-   a one-way hash is used.  Further, 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.
-
-   However, it should be noted that an attacker that has some knowledge,
-   such as of MAC addresses commonly used in DHCP client identification
-   data, may be able to discover the client's DHCP identify by using a
-   brute-force attack.  Even without any additional knowledge, the
-   number of unknown bits used in computing the hash is typically only
-   48 to 80.
-
-   Administrators should be wary of permitting unsecured DNS updates to
-   zones, whether or not they are exposed to the global Internet.  Both
-   DHCP clients and servers SHOULD use some form of update
-   authentication (e.g., [12]) when performing DNS updates.
-
-
-
-Stapp, et al.               Standards Track                     [Page 8]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-7.  IANA Considerations
-
-   IANA has allocated a DNS RR type number for the DHCID record type.
-
-   This specification defines a new number-space for the 2-octet
-   identifier type codes associated with the DHCID RR.  IANA has
-   established 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 identifier type codes are
-   assigned through Standards Action, as defined in [5].
-
-   This specification defines a new number-space for the 1-octet digest
-   type codes associated with the DHCID RR.  IANA has established a
-   registry of the values for this number-space.  Two initial values are
-   assigned in Section 3.4.  New DHCID RR digest type codes are assigned
-   through Standards Action, as defined in [5].
-
-8.  Acknowledgements
-
-   Many thanks to Harald Alvestrand, Ralph Droms, Olafur Gudmundsson,
-   Sam Hartman, Josh Littlefield, Pekka Savola, and especially Bernie
-   Volz for their review and suggestions.
-
-9.  References
-
-9.1.  Normative References
-
-   [1]  Stapp, M. and B. Volz, "Resolution of Fully Qualified Domain
-        Name (FQDN) Conflicts among Dynamic Host Configuration Protocol
-        (DHCP) Clients", RFC 4703, October 2006.
-
-   [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]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
-        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
-
-   [6]  Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers
-        for Dynamic Host Configuration Protocol Version Four (DHCPv4)",
-        RFC 4361, February 2006.
-
-
-
-
-
-Stapp, et al.               Standards Track                     [Page 9]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-9.2.  Informative References
-
-   [7]   Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
-         March 1997.
-
-   [8]   Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
-         RFC 3548, July 2003.
-
-   [9]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Resource Records for the DNS Security Extensions", RFC 4034,
-         March 2005.
-
-   [10]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
-         Extensions", RFC 2132, March 1997.
-
-   [11]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
-         Carney, "Dynamic Host Configuration Protocol for IPv6
-         (DHCPv6)", RFC 3315, July 2003.
-
-   [12]  Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington,
-         "Secret Key Transaction Authentication for DNS (TSIG)",
-         RFC 2845, May 2000.
-
-   [13]  Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
-         Types", RFC 3597, September 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al.               Standards Track                    [Page 10]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-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
-   Araneus Information Systems Oy
-   Ulappakatu 1
-   02320 Espoo
-   Finland
-
-   EMail: gson@araneus.fi
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al.               Standards Track                    [Page 11]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2006).
-
-   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.
-
-Intellectual Property
-
-   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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Stapp, et al.               Standards Track                    [Page 12]
-
diff --git a/contrib/bind9/doc/rfc/rfc5155.txt b/contrib/bind9/doc/rfc/rfc5155.txt
deleted file mode 100644
index d4b7297..0000000
--- a/contrib/bind9/doc/rfc/rfc5155.txt
+++ /dev/null
@@ -1,2915 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          B. Laurie
-Request for Comments: 5155                                     G. Sisson
-Category: Standards Track                                      R. Arends
-                                                                 Nominet
-                                                               D. Blacka
-                                                          VeriSign, Inc.
-                                                              March 2008
-
-
-     DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
-
-Status of This Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Abstract
-
-   The Domain Name System Security (DNSSEC) Extensions introduced the
-   NSEC resource record (RR) for authenticated denial of existence.
-   This document introduces an alternative resource record, NSEC3, which
-   similarly provides authenticated denial of existence.  However, it
-   also provides measures against zone enumeration and permits gradual
-   expansion of delegation-centric zones.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.1.  Rationale  . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.2.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
-   2.  Backwards Compatibility  . . . . . . . . . . . . . . . . . . .  6
-   3.  The NSEC3 Resource Record  . . . . . . . . . . . . . . . . . .  7
-     3.1.  RDATA Fields . . . . . . . . . . . . . . . . . . . . . . .  8
-       3.1.1.  Hash Algorithm . . . . . . . . . . . . . . . . . . . .  8
-       3.1.2.  Flags  . . . . . . . . . . . . . . . . . . . . . . . .  8
-       3.1.3.  Iterations . . . . . . . . . . . . . . . . . . . . . .  8
-       3.1.4.  Salt Length  . . . . . . . . . . . . . . . . . . . . .  8
-       3.1.5.  Salt . . . . . . . . . . . . . . . . . . . . . . . . .  8
-       3.1.6.  Hash Length  . . . . . . . . . . . . . . . . . . . . .  9
-       3.1.7.  Next Hashed Owner Name . . . . . . . . . . . . . . . .  9
-       3.1.8.  Type Bit Maps  . . . . . . . . . . . . . . . . . . . .  9
-     3.2.  NSEC3 RDATA Wire Format  . . . . . . . . . . . . . . . . .  9
-       3.2.1.  Type Bit Maps Encoding . . . . . . . . . . . . . . . . 10
-     3.3.  Presentation Format  . . . . . . . . . . . . . . . . . . . 11
-
-
-
-Laurie, et al.              Standards Track                     [Page 1]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   4.  The NSEC3PARAM Resource Record . . . . . . . . . . . . . . . . 12
-     4.1.  RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 12
-       4.1.1.  Hash Algorithm . . . . . . . . . . . . . . . . . . . . 12
-       4.1.2.  Flag Fields  . . . . . . . . . . . . . . . . . . . . . 12
-       4.1.3.  Iterations . . . . . . . . . . . . . . . . . . . . . . 13
-       4.1.4.  Salt Length  . . . . . . . . . . . . . . . . . . . . . 13
-       4.1.5.  Salt . . . . . . . . . . . . . . . . . . . . . . . . . 13
-     4.2.  NSEC3PARAM RDATA Wire Format . . . . . . . . . . . . . . . 13
-     4.3.  Presentation Format  . . . . . . . . . . . . . . . . . . . 14
-   5.  Calculation of the Hash  . . . . . . . . . . . . . . . . . . . 14
-   6.  Opt-Out  . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
-   7.  Authoritative Server Considerations  . . . . . . . . . . . . . 16
-     7.1.  Zone Signing . . . . . . . . . . . . . . . . . . . . . . . 16
-     7.2.  Zone Serving . . . . . . . . . . . . . . . . . . . . . . . 17
-       7.2.1.  Closest Encloser Proof . . . . . . . . . . . . . . . . 18
-       7.2.2.  Name Error Responses . . . . . . . . . . . . . . . . . 19
-       7.2.3.  No Data Responses, QTYPE is not DS . . . . . . . . . . 19
-       7.2.4.  No Data Responses, QTYPE is DS . . . . . . . . . . . . 19
-       7.2.5.  Wildcard No Data Responses . . . . . . . . . . . . . . 19
-       7.2.6.  Wildcard Answer Responses  . . . . . . . . . . . . . . 20
-       7.2.7.  Referrals to Unsigned Subzones . . . . . . . . . . . . 20
-       7.2.8.  Responding to Queries for NSEC3 Owner Names  . . . . . 20
-       7.2.9.  Server Response to a Run-Time Collision  . . . . . . . 21
-     7.3.  Secondary Servers  . . . . . . . . . . . . . . . . . . . . 21
-     7.4.  Zones Using Unknown Hash Algorithms  . . . . . . . . . . . 21
-     7.5.  Dynamic Update . . . . . . . . . . . . . . . . . . . . . . 21
-   8.  Validator Considerations . . . . . . . . . . . . . . . . . . . 23
-     8.1.  Responses with Unknown Hash Types  . . . . . . . . . . . . 23
-     8.2.  Verifying NSEC3 RRs  . . . . . . . . . . . . . . . . . . . 23
-     8.3.  Closest Encloser Proof . . . . . . . . . . . . . . . . . . 23
-     8.4.  Validating Name Error Responses  . . . . . . . . . . . . . 24
-     8.5.  Validating No Data Responses, QTYPE is not DS  . . . . . . 24
-     8.6.  Validating No Data Responses, QTYPE is DS  . . . . . . . . 24
-     8.7.  Validating Wildcard No Data Responses  . . . . . . . . . . 25
-     8.8.  Validating Wildcard Answer Responses . . . . . . . . . . . 25
-     8.9.  Validating Referrals to Unsigned Subzones  . . . . . . . . 25
-   9.  Resolver Considerations  . . . . . . . . . . . . . . . . . . . 26
-     9.1.  NSEC3 Resource Record Caching  . . . . . . . . . . . . . . 26
-     9.2.  Use of the AD Bit  . . . . . . . . . . . . . . . . . . . . 26
-   10. Special Considerations . . . . . . . . . . . . . . . . . . . . 26
-     10.1. Domain Name Length Restrictions  . . . . . . . . . . . . . 26
-     10.2. DNAME at the Zone Apex . . . . . . . . . . . . . . . . . . 27
-     10.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . . 27
-     10.4. Transitioning a Signed Zone from NSEC to NSEC3 . . . . . . 28
-     10.5. Transitioning a Signed Zone from NSEC3 to NSEC . . . . . . 28
-   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 29
-   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 30
-     12.1. Hashing Considerations . . . . . . . . . . . . . . . . . . 30
-
-
-
-Laurie, et al.              Standards Track                     [Page 2]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-       12.1.1. Dictionary Attacks . . . . . . . . . . . . . . . . . . 30
-       12.1.2. Collisions . . . . . . . . . . . . . . . . . . . . . . 31
-       12.1.3. Transitioning to a New Hash Algorithm  . . . . . . . . 31
-       12.1.4. Using High Iteration Values  . . . . . . . . . . . . . 31
-     12.2. Opt-Out Considerations . . . . . . . . . . . . . . . . . . 32
-     12.3. Other Considerations . . . . . . . . . . . . . . . . . . . 33
-   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
-     13.1. Normative References . . . . . . . . . . . . . . . . . . . 33
-     13.2. Informative References . . . . . . . . . . . . . . . . . . 34
-   Appendix A.  Example Zone  . . . . . . . . . . . . . . . . . . . . 35
-   Appendix B.  Example Responses . . . . . . . . . . . . . . . . . . 40
-     B.1.  Name Error . . . . . . . . . . . . . . . . . . . . . . . . 40
-     B.2.  No Data Error  . . . . . . . . . . . . . . . . . . . . . . 42
-       B.2.1.  No Data Error, Empty Non-Terminal  . . . . . . . . . . 43
-     B.3.  Referral to an Opt-Out Unsigned Zone . . . . . . . . . . . 44
-     B.4.  Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 45
-     B.5.  Wildcard No Data Error . . . . . . . . . . . . . . . . . . 46
-     B.6.  DS Child Zone No Data Error  . . . . . . . . . . . . . . . 48
-   Appendix C.  Special Considerations  . . . . . . . . . . . . . . . 48
-     C.1.  Salting  . . . . . . . . . . . . . . . . . . . . . . . . . 49
-     C.2.  Hash Collision . . . . . . . . . . . . . . . . . . . . . . 49
-       C.2.1.  Avoiding Hash Collisions During Generation . . . . . . 50
-       C.2.2.  Second Preimage Requirement Analysis . . . . . . . . . 50
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                     [Page 3]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-1.  Introduction
-
-1.1.  Rationale
-
-   The DNS Security Extensions included the NSEC RR to provide
-   authenticated denial of existence.  Though the NSEC RR meets the
-   requirements for authenticated denial of existence, it introduces a
-   side-effect in that the contents of a zone can be enumerated.  This
-   property introduces undesired policy issues.
-
-   The enumeration is enabled by the set of NSEC records that exists
-   inside a signed zone.  An NSEC record lists two names that are
-   ordered canonically, in order to show that nothing exists between the
-   two names.  The complete set of NSEC records lists all the names in a
-   zone.  It is trivial to enumerate the content of a zone by querying
-   for names that do not exist.
-
-   An enumerated zone can be used, for example, as a source of probable
-   e-mail addresses for spam, or as a key for multiple WHOIS queries to
-   reveal registrant data that many registries may have legal
-   obligations to protect.  Many registries therefore prohibit the
-   copying of their zone data; however, the use of NSEC RRs renders
-   these policies unenforceable.
-
-   A second problem is that the cost to cryptographically secure
-   delegations to unsigned zones is high, relative to the perceived
-   security benefit, in two cases: large, delegation-centric zones, and
-   zones where insecure delegations will be updated rapidly.  In these
-   cases, the costs of maintaining the NSEC RR chain may be extremely
-   high and use of the "Opt-Out" convention may be more appropriate (for
-   these unsecured zones).
-
-   This document presents the NSEC3 Resource Record which can be used as
-   an alternative to NSEC to mitigate these issues.
-
-   Earlier work to address these issues include [DNSEXT-NO], [RFC4956],
-   and [DNSEXT-NSEC2v2].
-
-1.2.  Requirements
-
-   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].
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                     [Page 4]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-1.3.  Terminology
-
-   The reader is assumed to be familiar with the basic DNS and DNSSEC
-   concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034],
-   [RFC4035], and subsequent RFCs that update them: [RFC2136],
-   [RFC2181], and [RFC2308].
-
-   The following terminology is used throughout this document:
-
-   Zone enumeration:  the practice of discovering the full content of a
-      zone via successive queries.  Zone enumeration was non-trivial
-      prior to the introduction of DNSSEC.
-
-   Original owner name:  the owner name corresponding to a hashed owner
-      name.
-
-   Hashed owner name:  the owner name created after applying the hash
-      function to an owner name.
-
-   Hash order:  the order in which hashed owner names are arranged
-      according to their numerical value, treating the leftmost (lowest
-      numbered) octet as the most significant octet.  Note that this
-      order is the same as the canonical DNS name order specified in
-      [RFC4034], when the hashed owner names are in base32, encoded with
-      an Extended Hex Alphabet [RFC4648].
-
-   Empty non-terminal:  a domain name that owns no resource records, but
-      has one or more subdomains that do.
-
-   Delegation:  an NS RRSet with a name different from the current zone
-      apex (non-zone-apex), signifying a delegation to a child zone.
-
-   Secure delegation:  a name containing a delegation (NS RRSet) and a
-      signed DS RRSet, signifying a delegation to a signed child zone.
-
-   Insecure delegation:  a name containing a delegation (NS RRSet), but
-      lacking a DS RRSet, signifying a delegation to an unsigned child
-      zone.
-
-   Opt-Out NSEC3 resource record:  an NSEC3 resource record that has the
-      Opt-Out flag set to 1.
-
-   Opt-Out zone:  a zone with at least one Opt-Out NSEC3 RR.
-
-   Closest encloser:  the longest existing ancestor of a name.  See also
-      Section 3.3.1 of [RFC4592].
-
-
-
-
-
-Laurie, et al.              Standards Track                     [Page 5]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   Closest provable encloser:  the longest ancestor of a name that can
-      be proven to exist.  Note that this is only different from the
-      closest encloser in an Opt-Out zone.
-
-   Next closer name:  the name one label longer than the closest
-      provable encloser of a name.
-
-   Base32:  the "Base 32 Encoding with Extended Hex Alphabet" as
-      specified in [RFC4648].  Note that trailing padding characters
-      ("=") are not used in the NSEC3 specification.
-
-   To cover:  An NSEC3 RR is said to "cover" a name if the hash of the
-      name or "next closer" name falls between the owner name and the
-      next hashed owner name of the NSEC3.  In other words, if it proves
-      the nonexistence of the name, either directly or by proving the
-      nonexistence of an ancestor of the name.
-
-   To match:  An NSEC3 RR is said to "match" a name if the owner name of
-      the NSEC3 RR is the same as the hashed owner name of that name.
-
-2.  Backwards Compatibility
-
-   This specification describes a protocol change that is not generally
-   backwards compatible with [RFC4033], [RFC4034], and [RFC4035].  In
-   particular, security-aware resolvers that are unaware of this
-   specification (NSEC3-unaware resolvers) may fail to validate the
-   responses introduced by this document.
-
-   In order to aid deployment, this specification uses a signaling
-   technique to prevent NSEC3-unaware resolvers from attempting to
-   validate responses from NSEC3-signed zones.
-
-   This specification allocates two new DNSKEY algorithm identifiers for
-   this purpose.  Algorithm 6, DSA-NSEC3-SHA1 is an alias for algorithm
-   3, DSA.  Algorithm 7, RSASHA1-NSEC3-SHA1 is an alias for algorithm 5,
-   RSASHA1.  These are not new algorithms, they are additional
-   identifiers for the existing algorithms.
-
-   Zones signed according to this specification MUST only use these
-   algorithm identifiers for their DNSKEY RRs.  Because these new
-   identifiers will be unknown algorithms to existing, NSEC3-unaware
-   resolvers, those resolvers will then treat responses from the NSEC3
-   signed zone as insecure, as detailed in Section 5.2 of [RFC4035].
-
-   These algorithm identifiers are used with the NSEC3 hash algorithm
-   SHA1.  Using other NSEC3 hash algorithms requires allocation of a new
-   alias (see Section 12.1.3).
-
-
-
-
-Laurie, et al.              Standards Track                     [Page 6]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   Security aware resolvers that are aware of this specification MUST
-   recognize the new algorithm identifiers and treat them as equivalent
-   to the algorithms that they alias.
-
-   A methodology for transitioning from a DNSSEC signed zone to a zone
-   signed using NSEC3 is discussed in Section 10.4.
-
-3.  The NSEC3 Resource Record
-
-   The NSEC3 Resource Record (RR) provides authenticated denial of
-   existence for DNS Resource Record Sets.
-
-   The NSEC3 RR lists RR types present at the original owner name of the
-   NSEC3 RR.  It includes the next hashed owner name in the hash order
-   of the zone.  The complete set of NSEC3 RRs in a zone indicates which
-   RRSets exist for the original owner name of the RR and form a chain
-   of hashed owner names in the zone.  This information is used to
-   provide authenticated denial of existence for DNS data.  To provide
-   protection against zone enumeration, the owner names used in the
-   NSEC3 RR are cryptographic hashes of the original owner name
-   prepended as a single label to the name of the zone.  The NSEC3 RR
-   indicates which hash function is used to construct the hash, which
-   salt is used, and how many iterations of the hash function are
-   performed over the original owner name.  The hashing technique is
-   described fully in Section 5.
-
-   Hashed owner names of unsigned delegations may be excluded from the
-   chain.  An NSEC3 RR whose span covers the hash of an owner name or
-   "next closer" name of an unsigned delegation is referred to as an
-   Opt-Out NSEC3 RR and is indicated by the presence of a flag.
-
-   The owner name for the NSEC3 RR is the base32 encoding of the hashed
-   owner name prepended as a single label to the name of the zone.
-
-   The type value for the NSEC3 RR is 50.
-
-   The NSEC3 RR RDATA format is class independent and is described
-   below.
-
-   The class MUST be the same as the class of the original owner name.
-
-   The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL
-   field.  This is in the spirit of negative caching [RFC2308].
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                     [Page 7]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-3.1.  RDATA Fields
-
-3.1.1.  Hash Algorithm
-
-   The Hash Algorithm field identifies the cryptographic hash algorithm
-   used to construct the hash-value.
-
-   The values for this field are defined in the NSEC3 hash algorithm
-   registry defined in Section 11.
-
-3.1.2.  Flags
-
-   The Flags field contains 8 one-bit flags that can be used to indicate
-   different processing.  All undefined flags must be zero.  The only
-   flag defined by this specification is the Opt-Out flag.
-
-3.1.2.1.  Opt-Out Flag
-
-   If the Opt-Out flag is set, the NSEC3 record covers zero or more
-   unsigned delegations.
-
-   If the Opt-Out flag is clear, the NSEC3 record covers zero unsigned
-   delegations.
-
-   The Opt-Out Flag indicates whether this NSEC3 RR may cover unsigned
-   delegations.  It is the least significant bit in the Flags field.
-   See Section 6 for details about the use of this flag.
-
-3.1.3.  Iterations
-
-   The Iterations field defines the number of additional times the hash
-   function has been performed.  More iterations result in greater
-   resiliency of the hash value against dictionary attacks, but at a
-   higher computational cost for both the server and resolver.  See
-   Section 5 for details of the use of this field, and Section 10.3 for
-   limitations on the value.
-
-3.1.4.  Salt Length
-
-   The Salt Length field defines the length of the Salt field in octets,
-   ranging in value from 0 to 255.
-
-3.1.5.  Salt
-
-   The Salt field is appended to the original owner name before hashing
-   in order to defend against pre-calculated dictionary attacks.  See
-   Section 5 for details on how the salt is used.
-
-
-
-
-Laurie, et al.              Standards Track                     [Page 8]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-3.1.6.  Hash Length
-
-   The Hash Length field defines the length of the Next Hashed Owner
-   Name field, ranging in value from 1 to 255 octets.
-
-3.1.7.  Next Hashed Owner Name
-
-   The Next Hashed Owner Name field contains the next hashed owner name
-   in hash order.  This value is in binary format.  Given the ordered
-   set of all hashed owner names, the Next Hashed Owner Name field
-   contains the hash of an owner name that immediately follows the owner
-   name of the given NSEC3 RR.  The value of the Next Hashed Owner Name
-   field in the last NSEC3 RR in the zone is the same as the hashed
-   owner name of the first NSEC3 RR in the zone in hash order.  Note
-   that, unlike the owner name of the NSEC3 RR, the value of this field
-   does not contain the appended zone name.
-
-3.1.8.  Type Bit Maps
-
-   The Type Bit Maps field identifies the RRSet types that exist at the
-   original owner name of the NSEC3 RR.
-
-3.2.  NSEC3 RDATA Wire Format
-
-   The RDATA of the NSEC3 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
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |   Hash Alg.   |     Flags     |          Iterations           |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |  Salt Length  |                     Salt                      /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |  Hash Length  |             Next Hashed Owner Name            /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   /                         Type Bit Maps                         /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   Hash Algorithm is a single octet.
-
-   Flags field is a single octet, the Opt-Out flag is the least
-   significant bit, as shown below:
-
-    0 1 2 3 4 5 6 7
-   +-+-+-+-+-+-+-+-+
-   |             |O|
-   +-+-+-+-+-+-+-+-+
-
-
-
-
-Laurie, et al.              Standards Track                     [Page 9]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   Iterations is represented as a 16-bit unsigned integer, with the most
-   significant bit first.
-
-   Salt Length is represented as an unsigned octet.  Salt Length
-   represents the length of the Salt field in octets.  If the value is
-   zero, the following Salt field is omitted.
-
-   Salt, if present, is encoded as a sequence of binary octets.  The
-   length of this field is determined by the preceding Salt Length
-   field.
-
-   Hash Length is represented as an unsigned octet.  Hash Length
-   represents the length of the Next Hashed Owner Name field in octets.
-
-   The next hashed owner name is not base32 encoded, unlike the owner
-   name of the NSEC3 RR.  It is the unmodified binary hash value.  It
-   does not include the name of the containing zone.  The length of this
-   field is determined by the preceding Hash Length field.
-
-3.2.1.  Type Bit Maps Encoding
-
-   The encoding of the Type Bit Maps field is the same as that used by
-   the NSEC RR, described in [RFC4034].  It is explained and clarified
-   here for clarity.
-
-   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 bitmap of the
-   window block, and up to 32 octets (256 bits) of bitmap.
-
-   Blocks are present in the NSEC3 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 to
-   1, it indicates that an RRSet of that type is present for the
-   original owner name of the NSEC3 RR.  If a bit is set to 0, it
-   indicates that no RRSet of that type is present for the original
-   owner name of the NSEC3 RR.
-
-
-
-Laurie, et al.              Standards Track                    [Page 10]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   Since bit 0 in window block 0 refers to the non-existing RR type 0,
-   it MUST be set to 0.  After verification, the validator MUST ignore
-   the value of bit 0 in window block 0.
-
-   Bits representing Meta-TYPEs or QTYPEs as specified in Section 3.1 of
-   [RFC2929] or within the range reserved for assignment only to QTYPEs
-   and Meta-TYPEs MUST be set to 0, 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 the bitmap of
-   each block is determined by the type code with the largest numerical
-   value, within that block, among the set of RR types present at the
-   original owner name of the NSEC3 RR.  Trailing octets not specified
-   MUST be interpreted as zero octets.
-
-3.3.  Presentation Format
-
-   The presentation format of the RDATA portion is as follows:
-
-   o  The Hash Algorithm field is represented as an unsigned decimal
-      integer.  The value has a maximum of 255.
-
-   o  The Flags field is represented as an unsigned decimal integer.
-      The value has a maximum of 255.
-
-   o  The Iterations field is represented as an unsigned decimal
-      integer.  The value is between 0 and 65535, inclusive.
-
-   o  The Salt Length field is not represented.
-
-   o  The Salt field is represented as a sequence of case-insensitive
-      hexadecimal digits.  Whitespace is not allowed within the
-      sequence.  The Salt field is represented as "-" (without the
-      quotes) when the Salt Length field has a value of 0.
-
-   o  The Hash Length field is not represented.
-
-   o  The Next Hashed Owner Name field is represented as an unpadded
-      sequence of case-insensitive base32 digits, without whitespace.
-
-   o  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 Section 5 of [RFC3597] MUST be
-      used.
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 11]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-4.  The NSEC3PARAM Resource Record
-
-   The NSEC3PARAM RR contains the NSEC3 parameters (hash algorithm,
-   flags, iterations, and salt) needed by authoritative servers to
-   calculate hashed owner names.  The presence of an NSEC3PARAM RR at a
-   zone apex indicates that the specified parameters may be used by
-   authoritative servers to choose an appropriate set of NSEC3 RRs for
-   negative responses.  The NSEC3PARAM RR is not used by validators or
-   resolvers.
-
-   If an NSEC3PARAM RR is present at the apex of a zone with a Flags
-   field value of zero, then there MUST be an NSEC3 RR using the same
-   hash algorithm, iterations, and salt parameters present at every
-   hashed owner name in the zone.  That is, the zone MUST contain a
-   complete set of NSEC3 RRs with the same hash algorithm, iterations,
-   and salt parameters.
-
-   The owner name for the NSEC3PARAM RR is the name of the zone apex.
-
-   The type value for the NSEC3PARAM RR is 51.
-
-   The NSEC3PARAM RR RDATA format is class independent and is described
-   below.
-
-   The class MUST be the same as the NSEC3 RRs to which this RR refers.
-
-4.1.  RDATA Fields
-
-   The RDATA for this RR mirrors the first four fields in the NSEC3 RR.
-
-4.1.1.  Hash Algorithm
-
-   The Hash Algorithm field identifies the cryptographic hash algorithm
-   used to construct the hash-value.
-
-   The acceptable values are the same as the corresponding field in the
-   NSEC3 RR.
-
-4.1.2.  Flag Fields
-
-   The Opt-Out flag is not used and is set to zero.
-
-   All other flags are reserved for future use, and must be zero.
-
-   NSEC3PARAM RRs with a Flags field value other than zero MUST be
-   ignored.
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 12]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-4.1.3.  Iterations
-
-   The Iterations field defines the number of additional times the hash
-   is performed.
-
-   Its acceptable values are the same as the corresponding field in the
-   NSEC3 RR.
-
-4.1.4.  Salt Length
-
-   The Salt Length field defines the length of the salt in octets,
-   ranging in value from 0 to 255.
-
-4.1.5.  Salt
-
-   The Salt field is appended to the original owner name before hashing.
-
-4.2.  NSEC3PARAM RDATA Wire Format
-
-   The RDATA of the NSEC3PARAM 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
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |   Hash Alg.   |     Flags     |          Iterations           |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |  Salt Length  |                     Salt                      /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   Hash Algorithm is a single octet.
-
-   Flags field is a single octet.
-
-   Iterations is represented as a 16-bit unsigned integer, with the most
-   significant bit first.
-
-   Salt Length is represented as an unsigned octet.  Salt Length
-   represents the length of the following Salt field in octets.  If the
-   value is zero, the Salt field is omitted.
-
-   Salt, if present, is encoded as a sequence of binary octets.  The
-   length of this field is determined by the preceding Salt Length
-   field.
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 13]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-4.3.  Presentation Format
-
-   The presentation format of the RDATA portion is as follows:
-
-   o  The Hash Algorithm field is represented as an unsigned decimal
-      integer.  The value has a maximum of 255.
-
-   o  The Flags field is represented as an unsigned decimal integer.
-      The value has a maximum value of 255.
-
-   o  The Iterations field is represented as an unsigned decimal
-      integer.  The value is between 0 and 65535, inclusive.
-
-   o  The Salt Length field is not represented.
-
-   o  The Salt field is represented as a sequence of case-insensitive
-      hexadecimal digits.  Whitespace is not allowed within the
-      sequence.  This field is represented as "-" (without the quotes)
-      when the Salt Length field is zero.
-
-5.  Calculation of the Hash
-
-   The hash calculation uses three of the NSEC3 RDATA fields: Hash
-   Algorithm, Salt, and Iterations.
-
-   Define H(x) to be the hash of x using the Hash Algorithm selected by
-   the NSEC3 RR, k to be the number of Iterations, and || to indicate
-   concatenation.  Then define:
-
-      IH(salt, x, 0) = H(x || salt), and
-
-      IH(salt, x, k) = H(IH(salt, x, k-1) || salt), if k > 0
-
-   Then the calculated hash of an owner name is
-
-      IH(salt, owner name, iterations),
-
-   where the owner name is in the canonical form, defined as:
-
-   The wire format of the owner name where:
-
-   1.  The owner name is fully expanded (no DNS name compression) and
-       fully qualified;
-
-   2.  All uppercase US-ASCII letters are replaced by the corresponding
-       lowercase US-ASCII letters;
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 14]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   3.  If the owner name is a wildcard name, the owner name is in its
-       original unexpanded form, including the "*" label (no wildcard
-       substitution);
-
-   This form is as defined in Section 6.2 of [RFC4034].
-
-   The method to calculate the Hash is based on [RFC2898].
-
-6.  Opt-Out
-
-   In this specification, as in [RFC4033], [RFC4034] and [RFC4035], NS
-   RRSets at delegation points are not signed and may be accompanied by
-   a DS RRSet.  With the Opt-Out bit clear, the security status of the
-   child zone is determined by the presence or absence of this DS RRSet,
-   cryptographically proven by the signed NSEC3 RR at the hashed owner
-   name of the delegation.  Setting the Opt-Out flag modifies this by
-   allowing insecure delegations to exist within the signed zone without
-   a corresponding NSEC3 RR at the hashed owner name of the delegation.
-
-   An Opt-Out NSEC3 RR is said to cover a delegation if the hash of the
-   owner name or "next closer" name of the delegation is between the
-   owner name of the NSEC3 RR and the next hashed owner name.
-
-   An Opt-Out NSEC3 RR does not assert the existence or non-existence of
-   the insecure delegations that it may cover.  This allows for the
-   addition or removal of these delegations without recalculating or re-
-   signing RRs in the NSEC3 RR chain.  However, Opt-Out NSEC3 RRs do
-   assert the (non)existence of other, authoritative RRSets.
-
-   An Opt-Out NSEC3 RR MAY have the same original owner name as an
-   insecure delegation.  In this case, the delegation is proven insecure
-   by the lack of a DS bit in the type map and the signed NSEC3 RR does
-   assert the existence of the delegation.
-
-   Zones using Opt-Out MAY contain a mixture of Opt-Out NSEC3 RRs and
-   non-Opt-Out NSEC3 RRs.  If an NSEC3 RR is not Opt-Out, there MUST NOT
-   be any hashed owner names of insecure delegations (nor any other RRs)
-   between it and the name indicated by the next hashed owner name in
-   the NSEC3 RDATA.  If it is Opt-Out, it MUST only cover hashed owner
-   names or hashed "next closer" names of insecure delegations.
-
-   The effects of the Opt-Out flag on signing, serving, and validating
-   responses are covered in following sections.
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 15]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-7.  Authoritative Server Considerations
-
-7.1.  Zone Signing
-
-   Zones using NSEC3 must satisfy the following properties:
-
-   o  Each owner name within the zone that owns authoritative RRSets
-      MUST have a corresponding NSEC3 RR.  Owner names that correspond
-      to unsigned delegations MAY have a corresponding NSEC3 RR.
-      However, if there is not a corresponding NSEC3 RR, there MUST be
-      an Opt-Out NSEC3 RR that covers the "next closer" name to the
-      delegation.  Other non-authoritative RRs are not represented by
-      NSEC3 RRs.
-
-   o  Each empty non-terminal MUST have a corresponding NSEC3 RR, unless
-      the empty non-terminal is only derived from an insecure delegation
-      covered by an Opt-Out NSEC3 RR.
-
-   o  The TTL value for any NSEC3 RR SHOULD be the same as the minimum
-      TTL value field in the zone SOA RR.
-
-   o  The Type Bit Maps field of every NSEC3 RR in a signed zone MUST
-      indicate the presence of all types present at the original owner
-      name, except for the types solely contributed by an NSEC3 RR
-      itself.  Note that this means that the NSEC3 type itself will
-      never be present in the Type Bit Maps.
-
-   The following steps describe a method of proper construction of NSEC3
-   RRs.  This is not the only such possible method.
-
-   1.  Select the hash algorithm and the values for salt and iterations.
-
-   2.  For each unique original owner name in the zone add an NSEC3 RR.
-
-       *  If Opt-Out is being used, owner names of unsigned delegations
-          MAY be excluded.
-
-       *  The owner name of the NSEC3 RR is the hash of the original
-          owner name, prepended as a single label to the zone name.
-
-       *  The Next Hashed Owner Name field is left blank for the moment.
-
-       *  If Opt-Out is being used, set the Opt-Out bit to one.
-
-       *  For collision detection purposes, optionally keep track of the
-          original owner name with the NSEC3 RR.
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 16]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-       *  Additionally, for collision detection purposes, optionally
-          create an additional NSEC3 RR corresponding to the original
-          owner name with the asterisk label prepended (i.e., as if a
-          wildcard existed as a child of this owner name) and keep track
-          of this original owner name.  Mark this NSEC3 RR as temporary.
-
-   3.  For each RRSet at the original owner name, set the corresponding
-       bit in the Type Bit Maps field.
-
-   4.  If the difference in number of labels between the apex and the
-       original owner name is greater than 1, additional NSEC3 RRs need
-       to be added for every empty non-terminal between the apex and the
-       original owner name.  This process may generate NSEC3 RRs with
-       duplicate hashed owner names.  Optionally, for collision
-       detection, track the original owner names of these NSEC3 RRs and
-       create temporary NSEC3 RRs for wildcard collisions in a similar
-       fashion to step 1.
-
-   5.  Sort the set of NSEC3 RRs into hash order.
-
-   6.  Combine NSEC3 RRs with identical hashed owner names by replacing
-       them with a single NSEC3 RR with the Type Bit Maps field
-       consisting of the union of the types represented by the set of
-       NSEC3 RRs.  If the original owner name was tracked, then
-       collisions may be detected when combining, as all of the matching
-       NSEC3 RRs should have the same original owner name.  Discard any
-       possible temporary NSEC3 RRs.
-
-   7.  In each NSEC3 RR, insert the next hashed owner name by using the
-       value of the next NSEC3 RR in hash order.  The next hashed owner
-       name of the last NSEC3 RR in the zone contains the value of the
-       hashed owner name of the first NSEC3 RR in the hash order.
-
-   8.  Finally, add an NSEC3PARAM RR with the same Hash Algorithm,
-       Iterations, and Salt fields to the zone apex.
-
-   If a hash collision is detected, then a new salt has to be chosen,
-   and the signing process restarted.
-
-7.2.  Zone Serving
-
-   This specification modifies DNSSEC-enabled DNS responses generated by
-   authoritative servers.  In particular, it replaces the use of NSEC
-   RRs in such responses with NSEC3 RRs.
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 17]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   In the following response cases, the NSEC RRs dictated by DNSSEC
-   [RFC4035] are replaced with NSEC3 RRs that prove the same facts.
-   Responses that would not contain NSEC RRs are unchanged by this
-   specification.
-
-   When returning responses containing multiple NSEC3 RRs, all of the
-   NSEC3 RRs MUST use the same hash algorithm, iteration, and salt
-   values.  The Flags field value MUST be either zero or one.
-
-7.2.1.  Closest Encloser Proof
-
-   For many NSEC3 responses a proof of the closest encloser is required.
-   This is a proof that some ancestor of the QNAME is the closest
-   encloser of QNAME.
-
-   This proof consists of (up to) two different NSEC3 RRs:
-
-   o  An NSEC3 RR that matches the closest (provable) encloser.
-
-   o  An NSEC3 RR that covers the "next closer" name to the closest
-      encloser.
-
-   The first NSEC3 RR essentially proposes a possible closest encloser,
-   and proves that the particular encloser does, in fact, exist.  The
-   second NSEC3 RR proves that the possible closest encloser is the
-   closest, and proves that the QNAME (and any ancestors between QNAME
-   and the closest encloser) does not exist.
-
-   These NSEC3 RRs are collectively referred to as the "closest encloser
-   proof" in the subsequent descriptions.
-
-   For example, the closest encloser proof for the nonexistent
-   "alpha.beta.gamma.example." owner name might prove that
-   "gamma.example." is the closest encloser.  This response would
-   contain the NSEC3 RR that matches "gamma.example.", and would also
-   contain the NSEC3 RR that covers "beta.gamma.example." (which is the
-   "next closer" name).
-
-   It is possible, when using Opt-Out (Section 6), to not be able to
-   prove the actual closest encloser because it is, or is part of an
-   insecure delegation covered by an Opt-Out span.  In this case,
-   instead of proving the actual closest encloser, the closest provable
-   encloser is used.  That is, the closest enclosing authoritative name
-   is used instead.  In this case, the set of NSEC3 RRs used for this
-   proof is referred to as the "closest provable encloser proof".
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 18]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-7.2.2.  Name Error Responses
-
-   To prove the nonexistence of QNAME, a closest encloser proof and an
-   NSEC3 RR covering the (nonexistent) wildcard RR at the closest
-   encloser MUST be included in the response.  This collection of (up
-   to) three NSEC3 RRs proves both that QNAME does not exist and that a
-   wildcard that could have matched QNAME also does not exist.
-
-   For example, if "gamma.example." is the closest provable encloser to
-   QNAME, then an NSEC3 RR covering "*.gamma.example." is included in
-   the authority section of the response.
-
-7.2.3.  No Data Responses, QTYPE is not DS
-
-   The server MUST include the NSEC3 RR that matches QNAME.  This NSEC3
-   RR MUST NOT have the bits corresponding to either the QTYPE or CNAME
-   set in its Type Bit Maps field.
-
-7.2.4.  No Data Responses, QTYPE is DS
-
-   If there is an NSEC3 RR that matches QNAME, the server MUST return it
-   in the response.  The bits corresponding with DS and CNAME MUST NOT
-   be set in the Type Bit Maps field of this NSEC3 RR.
-
-   If no NSEC3 RR matches QNAME, the server MUST return a closest
-   provable encloser proof for QNAME.  The NSEC3 RR that covers the
-   "next closer" name MUST have the Opt-Out bit set (note that this is
-   true by definition -- if the Opt-Out bit is not set, something has
-   gone wrong).
-
-   If a server is authoritative for both sides of a zone cut at QNAME,
-   the server MUST return the proof from the parent side of the zone
-   cut.
-
-7.2.5.  Wildcard No Data Responses
-
-   If there is a wildcard match for QNAME, but QTYPE is not present at
-   that name, the response MUST include a closest encloser proof for
-   QNAME and MUST include the NSEC3 RR that matches the wildcard.  This
-   combination proves both that QNAME itself does not exist and that a
-   wildcard that matches QNAME does exist.  Note that the closest
-   encloser to QNAME MUST be the immediate ancestor of the wildcard RR
-   (if this is not the case, then something has gone wrong).
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 19]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-7.2.6.  Wildcard Answer Responses
-
-   If there is a wildcard match for QNAME and QTYPE, then, in addition
-   to the expanded wildcard RRSet returned in the answer section of the
-   response, proof that the wildcard match was valid must be returned.
-
-   This proof is accomplished by proving that both QNAME does not exist
-   and that the closest encloser of the QNAME and the immediate ancestor
-   of the wildcard are the same (i.e., the correct wildcard matched).
-
-   To this end, the NSEC3 RR that covers the "next closer" name of the
-   immediate ancestor of the wildcard MUST be returned.  It is not
-   necessary to return an NSEC3 RR that matches the closest encloser, as
-   the existence of this closest encloser is proven by the presence of
-   the expanded wildcard in the response.
-
-7.2.7.  Referrals to Unsigned Subzones
-
-   If there is an NSEC3 RR that matches the delegation name, then that
-   NSEC3 RR MUST be included in the response.  The DS bit in the type
-   bit maps of the NSEC3 RR MUST NOT be set.
-
-   If the zone is Opt-Out, then there may not be an NSEC3 RR
-   corresponding to the delegation.  In this case, the closest provable
-   encloser proof MUST be included in the response.  The included NSEC3
-   RR that covers the "next closer" name for the delegation MUST have
-   the Opt-Out flag set to one.  (Note that this will be the case unless
-   something has gone wrong).
-
-7.2.8.  Responding to Queries for NSEC3 Owner Names
-
-   The owner names of NSEC3 RRs are not represented in the NSEC3 RR
-   chain like other owner names.  As a result, each NSEC3 owner name is
-   covered by another NSEC3 RR, effectively negating the existence of
-   the NSEC3 RR.  This is a paradox, since the existence of an NSEC3 RR
-   can be proven by its RRSIG RRSet.
-
-   If the following conditions are all true:
-
-   o  the QNAME equals the owner name of an existing NSEC3 RR, and
-
-   o  no RR types exist at the QNAME, nor at any descendant of QNAME,
-
-   then the response MUST be constructed as a Name Error response
-   (Section 7.2.2).  Or, in other words, the authoritative name server
-   will act as if the owner name of the NSEC3 RR did not exist.
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 20]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   Note that NSEC3 RRs are returned as a result of an AXFR or IXFR
-   query.
-
-7.2.9.  Server Response to a Run-Time Collision
-
-   If the hash of a non-existing QNAME collides with the owner name of
-   an existing NSEC3 RR, then the server will be unable to return a
-   response that proves that QNAME does not exist.  In this case, the
-   server MUST return a response with an RCODE of 2 (server failure).
-
-   Note that with the hash algorithm specified in this document, SHA-1,
-   such collisions are highly unlikely.
-
-7.3.  Secondary Servers
-
-   Secondary servers (and perhaps other entities) need to reliably
-   determine which NSEC3 parameters (i.e., hash, salt, and iterations)
-   are present at every hashed owner name, in order to be able to choose
-   an appropriate set of NSEC3 RRs for negative responses.  This is
-   indicated by an NSEC3PARAM RR present at the zone apex.
-
-   If there are multiple NSEC3PARAM RRs present, there are multiple
-   valid NSEC3 chains present.  The server must choose one of them, but
-   may use any criteria to do so.
-
-7.4.  Zones Using Unknown Hash Algorithms
-
-   Zones that are signed according to this specification, but are using
-   an unrecognized NSEC3 hash algorithm value, cannot be effectively
-   served.  Such zones SHOULD be rejected when loading.  Servers SHOULD
-   respond with RCODE=2 (server failure) responses when handling queries
-   that would fall under such zones.
-
-7.5.  Dynamic Update
-
-   A zone signed using NSEC3 may accept dynamic updates [RFC2136].
-   However, NSEC3 introduces some special considerations for dynamic
-   updates.
-
-   Adding and removing names in a zone MUST account for the creation or
-   removal of empty non-terminals.
-
-   o  When removing a name with a corresponding NSEC3 RR, any NSEC3 RRs
-      corresponding to empty non-terminals created by that name MUST be
-      removed.  Note that more than one name may be asserting the
-      existence of a particular empty non-terminal.
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 21]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   o  When adding a name that requires adding an NSEC3 RR, NSEC3 RRs
-      MUST also be added for any empty non-terminals that are created.
-      That is, if there is not an existing NSEC3 RR matching an empty
-      non-terminal, it must be created and added.
-
-   The presence of Opt-Out in a zone means that some additions or
-   delegations of names will not require changes to the NSEC3 RRs in a
-   zone.
-
-   o  When removing a delegation RRSet, if that delegation does not have
-      a matching NSEC3 RR, then it was opted out.  In this case, nothing
-      further needs to be done.
-
-   o  When adding a delegation RRSet, if the "next closer" name of the
-      delegation is covered by an existing Opt-Out NSEC3 RR, then the
-      delegation MAY be added without modifying the NSEC3 RRs in the
-      zone.
-
-   The presence of Opt-Out in a zone means that when adding or removing
-   NSEC3 RRs, the value of the Opt-Out flag that should be set in new or
-   modified NSEC3 RRs is ambiguous.  Servers SHOULD follow this set of
-   basic rules to resolve the ambiguity.
-
-   The central concept to these rules is that the state of the Opt-Out
-   flag of the covering NSEC3 RR is preserved.
-
-   o  When removing an NSEC3 RR, the value of the Opt-Out flag for the
-      previous NSEC3 RR (the one whose next hashed owner name is
-      modified) should not be changed.
-
-   o  When adding an NSEC3 RR, the value of the Opt-Out flag is set to
-      the value of the Opt-Out flag of the NSEC3 RR that previously
-      covered the owner name of the NSEC3 RR.  That is, the now previous
-      NSEC3 RR.
-
-   If the zone in question is consistent with its use of the Opt-Out
-   flag (that is, all NSEC3 RRs in the zone have the same value for the
-   flag) then these rules will retain that consistency.  If the zone is
-   not consistent in the use of the flag (i.e., a partially Opt-Out
-   zone), then these rules will not retain the same pattern of use of
-   the Opt-Out flag.
-
-   For zones that partially use the Opt-Out flag, if there is a logical
-   pattern for that use, the pattern could be maintained by using a
-   local policy on the server.
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 22]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-8.  Validator Considerations
-
-8.1.  Responses with Unknown Hash Types
-
-   A validator MUST ignore NSEC3 RRs with unknown hash types.  The
-   practical result of this is that responses containing only such NSEC3
-   RRs will generally be considered bogus.
-
-8.2.  Verifying NSEC3 RRs
-
-   A validator MUST ignore NSEC3 RRs with a Flag fields value other than
-   zero or one.
-
-   A validator MAY treat a response as bogus if the response contains
-   NSEC3 RRs that contain different values for hash algorithm,
-   iterations, or salt from each other for that zone.
-
-8.3.  Closest Encloser Proof
-
-   In order to verify a closest encloser proof, the validator MUST find
-   the longest name, X, such that
-
-   o  X is an ancestor of QNAME that is matched by an NSEC3 RR present
-      in the response.  This is a candidate for the closest encloser,
-      and
-
-   o  The name one label longer than X (but still an ancestor of -- or
-      equal to -- QNAME) is covered by an NSEC3 RR present in the
-      response.
-
-   One possible algorithm for verifying this proof is as follows:
-
-   1.  Set SNAME=QNAME.  Clear the flag.
-
-   2.  Check whether SNAME exists:
-
-       *  If there is no NSEC3 RR in the response that matches SNAME
-          (i.e., an NSEC3 RR whose owner name is the same as the hash of
-          SNAME, prepended as a single label to the zone name), clear
-          the flag.
-
-       *  If there is an NSEC3 RR in the response that covers SNAME, set
-          the flag.
-
-       *  If there is a matching NSEC3 RR in the response and the flag
-          was set, then the proof is complete, and SNAME is the closest
-          encloser.
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 23]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-       *  If there is a matching NSEC3 RR in the response, but the flag
-          is not set, then the response is bogus.
-
-   3.  Truncate SNAME by one label from the left, go to step 2.
-
-   Once the closest encloser has been discovered, the validator MUST
-   check that the NSEC3 RR that has the closest encloser as the original
-   owner name is from the proper zone.  The DNAME type bit must not be
-   set and the NS type bit may only be set if the SOA type bit is set.
-   If this is not the case, it would be an indication that an attacker
-   is using them to falsely deny the existence of RRs for which the
-   server is not authoritative.
-
-   In the following descriptions, the phrase "a closest (provable)
-   encloser proof for X" means that the algorithm above (or an
-   equivalent algorithm) proves that X does not exist by proving that an
-   ancestor of X is its closest encloser.
-
-8.4.  Validating Name Error Responses
-
-   A validator MUST verify that there is a closest encloser proof for
-   QNAME present in the response and that there is an NSEC3 RR that
-   covers the wildcard at the closest encloser (i.e., the name formed by
-   prepending the asterisk label to the closest encloser).
-
-8.5.  Validating No Data Responses, QTYPE is not DS
-
-   The validator MUST verify that an NSEC3 RR that matches QNAME is
-   present and that both the QTYPE and the CNAME type are not set in its
-   Type Bit Maps field.
-
-   Note that this test also covers the case where the NSEC3 RR exists
-   because it corresponds to an empty non-terminal, in which case the
-   NSEC3 RR will have an empty Type Bit Maps field.
-
-8.6.  Validating No Data Responses, QTYPE is DS
-
-   If there is an NSEC3 RR that matches QNAME present in the response,
-   then that NSEC3 RR MUST NOT have the bits corresponding to DS and
-   CNAME set in its Type Bit Maps field.
-
-   If there is no such NSEC3 RR, then the validator MUST verify that a
-   closest provable encloser proof for QNAME is present in the response,
-   and that the NSEC3 RR that covers the "next closer" name has the Opt-
-   Out bit set.
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 24]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-8.7.  Validating Wildcard No Data Responses
-
-   The validator MUST verify a closest encloser proof for QNAME and MUST
-   find an NSEC3 RR present in the response that matches the wildcard
-   name generated by prepending the asterisk label to the closest
-   encloser.  Furthermore, the bits corresponding to both QTYPE and
-   CNAME MUST NOT be set in the wildcard matching NSEC3 RR.
-
-8.8.  Validating Wildcard Answer Responses
-
-   The verified wildcard answer RRSet in the response provides the
-   validator with a (candidate) closest encloser for QNAME.  This
-   closest encloser is the immediate ancestor to the generating
-   wildcard.
-
-   Validators MUST verify that there is an NSEC3 RR that covers the
-   "next closer" name to QNAME present in the response.  This proves
-   that QNAME itself did not exist and that the correct wildcard was
-   used to generate the response.
-
-8.9.  Validating Referrals to Unsigned Subzones
-
-   The delegation name in a referral is the owner name of the NS RRSet
-   present in the authority section of the referral response.
-
-   If there is an NSEC3 RR present in the response that matches the
-   delegation name, then the validator MUST ensure that the NS bit is
-   set and that the DS bit is not set in the Type Bit Maps field of the
-   NSEC3 RR.  The validator MUST also ensure that the NSEC3 RR is from
-   the correct (i.e., parent) zone.  This is done by ensuring that the
-   SOA bit is not set in the Type Bit Maps field of this NSEC3 RR.
-
-   Note that the presence of an NS bit implies the absence of a DNAME
-   bit, so there is no need to check for the DNAME bit in the Type Bit
-   Maps field of the NSEC3 RR.
-
-   If there is no NSEC3 RR present that matches the delegation name,
-   then the validator MUST verify a closest provable encloser proof for
-   the delegation name.  The validator MUST verify that the Opt-Out bit
-   is set in the NSEC3 RR that covers the "next closer" name to the
-   delegation name.
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 25]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-9.  Resolver Considerations
-
-9.1.  NSEC3 Resource Record Caching
-
-   Caching resolvers MUST be able to retrieve the appropriate NSEC3 RRs
-   when returning responses that contain them.  In DNSSEC [RFC4035], in
-   many cases it is possible to find the correct NSEC RR to return in a
-   response by name (e.g., when returning a referral, the NSEC RR will
-   always have the same owner name as the delegation).  With this
-   specification, that will not be true, nor will a cache be able to
-   calculate the name(s) of the appropriate NSEC3 RR(s).
-   Implementations may need to use new methods for caching and
-   retrieving NSEC3 RRs.
-
-9.2.  Use of the AD Bit
-
-   The AD bit, as defined by [RFC4035], MUST NOT be set when returning a
-   response containing a closest (provable) encloser proof in which the
-   NSEC3 RR that covers the "next closer" name has the Opt-Out bit set.
-
-   This rule is based on what this closest encloser proof actually
-   proves: names that would be covered by the Opt-Out NSEC3 RR may or
-   may not exist as insecure delegations.  As such, not all the data in
-   responses containing such closest encloser proofs will have been
-   cryptographically verified, so the AD bit cannot be set.
-
-10.  Special Considerations
-
-10.1.  Domain Name Length Restrictions
-
-   Zones signed using this specification have additional domain name
-   length restrictions imposed upon them.  In particular, zones with
-   names that, when converted into hashed owner names exceed the 255
-   octet length limit imposed by [RFC1035], cannot use this
-   specification.
-
-   The actual maximum length of a domain name in a particular zone
-   depends on both the length of the zone name (versus the whole domain
-   name) and the particular hash function used.
-
-   As an example, SHA-1 produces a hash of 160 bits.  The base-32
-   encoding of 160 bits results in 32 characters.  The 32 characters are
-   prepended to the name of the zone as a single label, which includes a
-   length field of a single octet.  The maximum length of the zone name,
-   when using SHA-1, is 222 octets (255 - 33).
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 26]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-10.2.  DNAME at the Zone Apex
-
-   The DNAME specification in Section 3 of [RFC2672] has a 'no-
-   descendants' limitation.  If a DNAME RR is present at node N, there
-   MUST be no data at any descendant of N.
-
-   If N is the apex of the zone, there will be NSEC3 and RRSIG types
-   present at descendants of N.  This specification updates the DNAME
-   specification to allow NSEC3 and RRSIG types at descendants of the
-   apex regardless of the existence of DNAME at the apex.
-
-10.3.  Iterations
-
-   Setting the number of iterations used allows the zone owner to choose
-   the cost of computing a hash, and therefore the cost of generating a
-   dictionary.  Note that this is distinct from the effect of salt,
-   which prevents the use of a single precomputed dictionary for all
-   time.
-
-   Obviously the number of iterations also affects the zone owner's cost
-   of signing and serving the zone as well as the validator's cost of
-   verifying responses from the zone.  We therefore impose an upper
-   limit on the number of iterations.  We base this on the number of
-   iterations that approximates the cost of verifying an RRSet.
-
-   The limits, therefore, are based on the size of the smallest zone
-   signing key, rounded up to the nearest table value (or rounded down
-   if the key is larger than the largest table value).
-
-   A zone owner MUST NOT use a value higher than shown in the table
-   below for iterations for the given key size.  A resolver MAY treat a
-   response with a higher value as insecure, after the validator has
-   verified that the signature over the NSEC3 RR is correct.
-
-                         +----------+------------+
-                         | Key Size | Iterations |
-                         +----------+------------+
-                         | 1024     | 150        |
-                         | 2048     | 500        |
-                         | 4096     | 2,500      |
-                         +----------+------------+
-
-   This table is based on an approximation of the ratio between the cost
-   of an SHA-1 calculation and the cost of an RSA verification for keys
-   of size 1024 bits (150 to 1), 2048 bits (500 to 1), and 4096 bits
-   (2500 to 1).
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 27]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   The ratio between SHA-1 calculation and DSA verification is higher
-   (1500 to 1 for keys of size 1024).  A higher iteration count degrades
-   performance, while DSA verification is already more expensive than
-   RSA for the same key size.  Therefore the values in the table MUST be
-   used independent of the key algorithm.
-
-10.4.  Transitioning a Signed Zone from NSEC to NSEC3
-
-   When transitioning an already signed and trusted zone to this
-   specification, care must be taken to prevent client validation
-   failures during the process.
-
-   The basic procedure is as follows:
-
-   1.  Transition all DNSKEYs to DNSKEYs using the algorithm aliases
-       described in Section 2.  The actual method for safely and
-       securely changing the DNSKEY RRSet of the zone is outside the
-       scope of this specification.  However, the end result MUST be
-       that all DS RRs in the parent use the specified algorithm
-       aliases.
-
-       After this transition is complete, all NSEC3-unaware clients will
-       treat the zone as insecure.  At this point, the authoritative
-       server still returns negative and wildcard responses that contain
-       NSEC RRs.
-
-   2.  Add signed NSEC3 RRs to the zone, either incrementally or all at
-       once.  If adding incrementally, then the last RRSet added MUST be
-       the NSEC3PARAM RRSet.
-
-   3.  Upon the addition of the NSEC3PARAM RRSet, the server switches to
-       serving negative and wildcard responses with NSEC3 RRs according
-       to this specification.
-
-   4.  Remove the NSEC RRs either incrementally or all at once.
-
-10.5.  Transitioning a Signed Zone from NSEC3 to NSEC
-
-   To safely transition back to a DNSSEC [RFC4035] signed zone, simply
-   reverse the procedure above:
-
-   1.  Add NSEC RRs incrementally or all at once.
-
-   2.  Remove the NSEC3PARAM RRSet.  This will signal the server to use
-       the NSEC RRs for negative and wildcard responses.
-
-   3.  Remove the NSEC3 RRs either incrementally or all at once.
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 28]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   4.  Transition all of the DNSKEYs to DNSSEC algorithm identifiers.
-       After this transition is complete, all NSEC3-unaware clients will
-       treat the zone as secure.
-
-11.  IANA Considerations
-
-   Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm
-   parameter, this document does not define a particular mechanism for
-   safely transitioning from one NSEC3 hash algorithm to another.  When
-   specifying a new hash algorithm for use with NSEC3, a transition
-   mechanism MUST also be defined.
-
-   This document updates the IANA registry "DOMAIN NAME SYSTEM
-   PARAMETERS" (http://www.iana.org/assignments/dns-parameters) in sub-
-   registry "TYPES", by defining two new types.  Section 3 defines the
-   NSEC3 RR type 50.  Section 4 defines the NSEC3PARAM RR type 51.
-
-   This document updates the IANA registry "DNS SECURITY ALGORITHM
-   NUMBERS -- per [RFC4035]"
-   (http://www.iana.org/assignments/dns-sec-alg-numbers).  Section 2
-   defines the aliases DSA-NSEC3-SHA1 (6) and RSASHA1-NSEC3-SHA1 (7) for
-   respectively existing registrations DSA and RSASHA1 in combination
-   with NSEC3 hash algorithm SHA1.
-
-   Since these algorithm numbers are aliases for existing DNSKEY
-   algorithm numbers, the flags that exist for the original algorithm
-   are valid for the alias algorithm.
-
-   This document creates a new IANA registry for NSEC3 flags.  This
-   registry is named "DNSSEC NSEC3 Flags".  The initial contents of this
-   registry are:
-
-     0   1   2   3   4   5   6   7
-   +---+---+---+---+---+---+---+---+
-   |   |   |   |   |   |   |   |Opt|
-   |   |   |   |   |   |   |   |Out|
-   +---+---+---+---+---+---+---+---+
-
-      bit 7 is the Opt-Out flag.
-
-      bits 0 - 6 are available for assignment.
-
-   Assignment of additional NSEC3 Flags in this registry requires IETF
-   Standards Action [RFC2434].
-
-   This document creates a new IANA registry for NSEC3PARAM flags.  This
-   registry is named "DNSSEC NSEC3PARAM Flags".  The initial contents of
-   this registry are:
-
-
-
-Laurie, et al.              Standards Track                    [Page 29]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-     0   1   2   3   4   5   6   7
-   +---+---+---+---+---+---+---+---+
-   |   |   |   |   |   |   |   | 0 |
-   +---+---+---+---+---+---+---+---+
-
-      bit 7 is reserved and must be 0.
-
-      bits 0 - 6 are available for assignment.
-
-   Assignment of additional NSEC3PARAM Flags in this registry requires
-   IETF Standards Action [RFC2434].
-
-   Finally, this document creates a new IANA registry for NSEC3 hash
-   algorithms.  This registry is named "DNSSEC NSEC3 Hash Algorithms".
-   The initial contents of this registry are:
-
-      0 is Reserved.
-
-      1 is SHA-1.
-
-      2-255 Available for assignment.
-
-   Assignment of additional NSEC3 hash algorithms in this registry
-   requires IETF Standards Action [RFC2434].
-
-12.  Security Considerations
-
-12.1.  Hashing Considerations
-
-12.1.1.  Dictionary Attacks
-
-   The NSEC3 RRs are still susceptible to dictionary attacks (i.e., the
-   attacker retrieves all the NSEC3 RRs, then calculates the hashes of
-   all likely domain names, comparing against the hashes found in the
-   NSEC3 RRs, and thus enumerating the zone).  These are substantially
-   more expensive than enumerating the original NSEC RRs would have
-   been, and in any case, such an attack could also be used directly
-   against the name server itself by performing queries for all likely
-   names, though this would obviously be more detectable.  The expense
-   of this off-line attack can be chosen by setting the number of
-   iterations in the NSEC3 RR.
-
-   Zones are also susceptible to a pre-calculated dictionary attack --
-   that is, a list of hashes for all likely names is computed once, then
-   NSEC3 RR is scanned periodically and compared against the precomputed
-   hashes.  This attack is prevented by changing the salt on a regular
-   basis.
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 30]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   The salt SHOULD be at least 64 bits long and unpredictable, so that
-   an attacker cannot anticipate the value of the salt and compute the
-   next set of dictionaries before the zone is published.
-
-12.1.2.  Collisions
-
-   Hash collisions between QNAME and the owner name of an NSEC3 RR may
-   occur.  When they do, it will be impossible to prove the non-
-   existence of the colliding QNAME.  However, with SHA-1, this is
-   highly unlikely (on the order of 1 in 2^160).  Note that DNSSEC
-   already relies on the presumption that a cryptographic hash function
-   is second pre-image resistant, since these hash functions are used
-   for generating and validating signatures and DS RRs.
-
-12.1.3.  Transitioning to a New Hash Algorithm
-
-   Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm
-   parameter, this document does not define a particular mechanism for
-   safely transitioning from one NSEC3 hash algorithm to another.  When
-   specifying a new hash algorithm for use with NSEC3, a transition
-   mechanism MUST also be defined.  It is possible that the only
-   practical and palatable transition mechanisms may require an
-   intermediate transition to an insecure state, or to a state that uses
-   NSEC records instead of NSEC3.
-
-12.1.4.  Using High Iteration Values
-
-   Since validators should treat responses containing NSEC3 RRs with
-   high iteration values as insecure, presence of just one signed NSEC3
-   RR with a high iteration value in a zone provides attackers with a
-   possible downgrade attack.
-
-   The attack is simply to remove any existing NSEC3 RRs from a
-   response, and replace or add a single (or multiple) NSEC3 RR that
-   uses a high iterations value to the response.  Validators will then
-   be forced to treat the response as insecure.  This attack would be
-   effective only when all of following conditions are met:
-
-   o  There is at least one signed NSEC3 RR that uses a high iterations
-      value present in the zone.
-
-   o  The attacker has access to one or more of these NSEC3 RRs.  This
-      is trivially true when the NSEC3 RRs with high iteration values
-      are being returned in typical responses, but may also be true if
-      the attacker can access the zone via AXFR or IXFR queries, or any
-      other methodology.
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 31]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   Using a high number of iterations also introduces an additional
-   denial-of-service opportunity against servers, since servers must
-   calculate several hashes per negative or wildcard response.
-
-12.2.  Opt-Out Considerations
-
-   The Opt-Out Flag (O) allows for unsigned names, in the form of
-   delegations to unsigned zones, to exist within an otherwise signed
-   zone.  All unsigned names are, by definition, insecure, and their
-   validity or existence cannot be cryptographically proven.
-
-   In general:
-
-   o  Resource records with unsigned names (whether existing or not)
-      suffer from the same vulnerabilities as RRs in an unsigned zone.
-      These vulnerabilities are described in more detail in [RFC3833]
-      (note in particular Section 2.3, "Name Chaining" and Section 2.6,
-      "Authenticated Denial of Domain Names").
-
-   o  Resource records with signed names have the same security whether
-      or not Opt-Out is used.
-
-   Note that with or without Opt-Out, an insecure delegation may be
-   undetectably altered by an attacker.  Because of this, the primary
-   difference in security when using Opt-Out is the loss of the ability
-   to prove the existence or nonexistence of an insecure delegation
-   within the span of an Opt-Out NSEC3 RR.
-
-   In particular, this means that a malicious entity may be able to
-   insert or delete RRs with unsigned names.  These RRs are normally NS
-   RRs, but this also includes signed wildcard expansions (while the
-   wildcard RR itself is signed, its expanded name is an unsigned name).
-
-   Note that being able to add a delegation is functionally equivalent
-   to being able to add any RR type: an attacker merely has to forge a
-   delegation to name server under his/her control and place whatever
-   RRs needed at the subzone apex.
-
-   While in particular cases, this issue may not present a significant
-   security problem, in general it should not be lightly dismissed.
-   Therefore, it is strongly RECOMMENDED that Opt-Out be used sparingly.
-   In particular, zone signing tools SHOULD NOT default to using Opt-
-   Out, and MAY choose to not support Opt-Out at all.
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 32]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-12.3.  Other Considerations
-
-   Walking the NSEC3 RRs will reveal the total number of RRs in the zone
-   (plus empty non-terminals), and also what types there are.  This
-   could be mitigated by adding dummy entries, but certainly an upper
-   limit can always be found.
-
-13.  References
-
-13.1.  Normative References
-
-   [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.
-
-   [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.
-
-   [RFC2434]         Narten, T. and H. Alvestrand, "Guidelines for
-                     Writing an IANA Considerations Section in RFCs",
-                     BCP 26, RFC 2434, October 1998.
-
-   [RFC2929]         Eastlake, D., Brunner-Williams, E., and B. Manning,
-                     "Domain Name System (DNS) IANA Considerations",
-                     BCP 42, RFC 2929, September 2000.
-
-   [RFC3597]         Gustafsson, A., "Handling of Unknown DNS Resource
-                     Record (RR) Types", RFC 3597, September 2003.
-
-   [RFC4033]         Arends, R., Austein, R., Larson, M., Massey, D.,
-                     and S. Rose, "DNS Security Introduction and
-                     Requirements", RFC 4033, March 2005.
-
-   [RFC4034]         Arends, R., Austein, R., Larson, M., Massey, D.,
-                     and S. Rose, "Resource Records for the DNS Security
-                     Extensions", RFC 4034, March 2005.
-
-
-
-Laurie, et al.              Standards Track                    [Page 33]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   [RFC4035]         Arends, R., Austein, R., Larson, M., Massey, D.,
-                     and S. Rose, "Protocol Modifications for the DNS
-                     Security Extensions", RFC 4035, March 2005.
-
-   [RFC4648]         Josefsson, S., "The Base16, Base32, and Base64 Data
-                     Encodings", RFC 4648, October 2006.
-
-13.2.  Informative References
-
-   [DNSEXT-NO]       Josefsson, S., "Authenticating Denial of Existence
-                     in DNS with Minimum Disclosure", Work in Progress,
-                     July 2000.
-
-   [DNSEXT-NSEC2v2]  Laurie, B., "DNSSEC NSEC2 Owner and RDATA Format",
-                     Work in Progress, December 2004.
-
-   [RFC2672]         Crawford, M., "Non-Terminal DNS Name Redirection",
-                     RFC 2672, August 1999.
-
-   [RFC2898]         Kaliski, B., "PKCS #5: Password-Based Cryptography
-                     Specification Version 2.0", RFC 2898,
-                     September 2000.
-
-   [RFC3833]         Atkins, D. and R. Austein, "Threat Analysis of the
-                     Domain Name System (DNS)", RFC 3833, August 2004.
-
-   [RFC4592]         Lewis, E., "The Role of Wildcards in the Domain
-                     Name System", RFC 4592, July 2006.
-
-   [RFC4956]         Arends, R., Kosters, M., and D. Blacka, "DNS
-                     Security (DNSSEC) Opt-In", RFC 4956, July 2007.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 34]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-Appendix A.  Example Zone
-
-   This is a zone showing its NSEC3 RRs.  They can also be used as test
-   vectors for the hash algorithm.
-
-   The overall TTL and class are specified in the SOA RR, and are
-   subsequently omitted for clarity.
-
-   The zone is preceded by a list that contains the hashes of the
-   original ownernames.
-
-   ; H(example)       = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom
-   ; H(a.example)     = 35mthgpgcu1qg68fab165klnsnk3dpvl
-   ; H(ai.example)    = gjeqe526plbf1g8mklp59enfd789njgi
-   ; H(ns1.example)   = 2t7b4g4vsa5smi47k61mv5bv1a22bojr
-   ; H(ns2.example)   = q04jkcevqvmu85r014c7dkba38o0ji5r
-   ; H(w.example)     = k8udemvp1j2f7eg6jebps17vp3n8i58h
-   ; H(*.w.example)   = r53bq7cc2uvmubfu5ocmm6pers9tk9en
-   ; H(x.w.example)   = b4um86eghhds6nea196smvmlo4ors995
-   ; H(y.w.example)   = ji6neoaepv8b5o6k4ev33abha8ht9fgc
-   ; H(x.y.w.example) = 2vptu5timamqttgl4luu9kg21e0aor3s
-   ; H(xx.example)    = t644ebqk9bibcna874givr6joj62mlhv
-   ; H(2t7b4g4vsa5smi47k61mv5bv1a22bojr.example)
-   ;                  = kohar7mbb8dc2ce8a9qvl8hon4k53uhi
-   example. 3600  IN SOA  ns1.example. bugs.x.w.example. 1 3600 300 (
-                          3600000 3600 )
-                  RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
-                          q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
-                          VI2LmKusbZsT0Q== )
-                  NS      ns1.example.
-                  NS      ns2.example.
-                  RRSIG   NS 7 1 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          PVOgtMK1HHeSTau+HwDWC8Ts+6C8qtqd4pQJ
-                          qOtdEVgg+MA+ai4fWDEhu3qHJyLcQ9tbD2vv
-                          CnMXjtz6SyObxA== )
-                  MX      1 xx.example.
-                  RRSIG   MX 7 1 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          GgQ1A9xs47k42VPvpL/a1BWUz/6XsnHkjotw
-                          9So8MQtZtl2wJBsnOQsaoHrRCrRbyriEl/GZ
-                          n9Mto/Kx+wBo+w== )
-                  DNSKEY  256 3 7 AwEAAaetidLzsKWUt4swWR8yu0wPHPiUi8LU (
-                          sAD0QPWU+wzt89epO6tHzkMBVDkC7qphQO2h
-                          TY4hHn9npWFRw5BYubE= )
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 35]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-                  DNSKEY  257 3 7 AwEAAcUlFV1vhmqx6NSOUOq2R/dsR7Xm3upJ (
-                          j7IommWSpJABVfW8Q0rOvXdM6kzt+TAu92L9
-                          AbsUdblMFin8CVF3n4s= )
-                  RRSIG   DNSKEY 7 1 3600 20150420235959 (
-                          20051021000000 12708 example.
-                          AuU4juU9RaxescSmStrQks3Gh9FblGBlVU31
-                          uzMZ/U/FpsUb8aC6QZS+sTsJXnLnz7flGOsm
-                          MGQZf3bH+QsCtg== )
-                  NSEC3PARAM 1 0 12 aabbccdd
-                  RRSIG   NSEC3PARAM 7 1 3600 20150420235959 (
-                          20051021000000 40430 example.
-                          C1Gl8tPZNtnjlrYWDeeUV/sGLCyy/IHie2re
-                          rN05XSA3Pq0U3+4VvGWYWdUMfflOdxqnXHwJ
-                          TLQsjlkynhG6Cg== )
-   0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
-                          2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
-                          SOA NSEC3PARAM RRSIG )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
-                          IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
-                          BOCXJZMnpuwhpA== )
-   2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. A 192.0.2.127
-                  RRSIG   A 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          h6c++bzhRuWWt2bykN6mjaTNBcXNq5UuL5Ed
-                          K+iDP4eY8I0kSiKaCjg3tC1SQkeloMeub2GW
-                          k8p6xHMPZumXlw== )
-                  NSEC3   1 1 12 aabbccdd (
-                          2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          OmBvJ1Vgg1hCKMXHFiNeIYHK9XVW0iLDLwJN
-                          4TFoNxZuP03gAXEI634YwOc4YBNITrj413iq
-                          NI6mRk/r1dOSUw== )
-   2vptu5timamqttgl4luu9kg21e0aor3s.example. NSEC3 1 1 12 aabbccdd (
-                          35mthgpgcu1qg68fab165klnsnk3dpvl MX RRSIG )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          KL1V2oFYghNV0Hm7Tf2vpJjM6l+0g1JCcVYG
-                          VfI0lKrhPmTsOA96cLEACgo1x8I7kApJX+ob
-                          TuktZ+sdsZPY1w== )
-   35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
-                          b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 36]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ
-                          Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ
-                          XtAIR3chwgW+SA== )
-   a.example.     NS      ns1.a.example.
-                  NS      ns2.a.example.
-                  DS      58470 5 1 (
-                          3079F1593EBAD6DC121E202A8B766A6A4837206C )
-                  RRSIG   DS 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          XacFcQVHLVzdoc45EJhN616zQ4mEXtE8FzUh
-                          M2KWjfy1VfRKD9r1MeVGwwoukOKgJxBPFsWo
-                          o722vZ4UZ2dIdA== )
-   ns1.a.example. A       192.0.2.5
-   ns2.a.example. A       192.0.2.6
-   ai.example.    A       192.0.2.9
-                  RRSIG   A 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          hVe+wKYMlObTRPhX0NL67GxeZfdxqr/QeR6F
-                          tfdAj5+FgYxyzPEjIzvKWy00hWIl6wD3Vws+
-                          rznEn8sQ64UdqA== )
-                  HINFO   "KLH-10" "ITS"
-                  RRSIG   HINFO 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          Yi42uOq43eyO6qXHNvwwfFnIustWgV5urFcx
-                          enkLvs6pKRh00VBjODmf3Z4nMO7IOl6nHSQ1
-                          v0wLHpEZG7Xj2w== )
-                  AAAA    2001:db8:0:0:0:0:f00:baa9
-                  RRSIG   AAAA 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          LcdxKaCB5bGZwPDg+3JJ4O02zoMBrjxqlf6W
-                          uaHQZZfTUpb9Nf2nxFGe2XRPfR5tpJT6GdRG
-                          cHueLuXkMjBArQ== )
-   b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd (
-                          gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          ZkPG3M32lmoHM6pa3D6gZFGB/rhL//Bs3Omh
-                          5u4m/CUiwtblEVOaAKKZd7S959OeiX43aLX3
-                          pOv0TSTyiTxIZg== )
-   c.example.     NS      ns1.c.example.
-                  NS      ns2.c.example.
-   ns1.c.example. A       192.0.2.7
-   ns2.c.example. A       192.0.2.8
-   gjeqe526plbf1g8mklp59enfd789njgi.example. NSEC3 1 1 12 aabbccdd (
-                          ji6neoaepv8b5o6k4ev33abha8ht9fgc HINFO A AAAA
-                          RRSIG )
-
-
-
-Laurie, et al.              Standards Track                    [Page 37]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          IVnezTJ9iqblFF97vPSmfXZ5Zozngx3KX3by
-                          LTZC4QBH2dFWhf6scrGFZB980AfCxoD9qbbK
-                          Dy+rdGIeRSVNyw== )
-   ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd (
-                          k8udemvp1j2f7eg6jebps17vp3n8i58h )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          gPkFp1s2QDQ6wQzcg1uSebZ61W33rUBDcTj7
-                          2F3kQ490fEdp7k1BUIfbcZtPbX3YCpE+sIt0
-                          MpzVSKfTwx4uYA== )
-   k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd (
-                          kohar7mbb8dc2ce8a9qvl8hon4k53uhi )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          FtXGbvF0+wf8iWkyo73enAuVx03klN+pILBK
-                          S6qCcftVtfH4yVzsEZquJ27NHR7ruxJWDNMt
-                          Otx7w9WfcIg62A== )
-   kohar7mbb8dc2ce8a9qvl8hon4k53uhi.example. NSEC3 1 1 12 aabbccdd (
-                          q04jkcevqvmu85r014c7dkba38o0ji5r A RRSIG )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          VrDXs2uVW21N08SyQIz88zml+y4ZCInTwgDr
-                          6zz43yAg+LFERjOrj3Ojct51ac7Dp4eZbf9F
-                          QJazmASFKGxGXg== )
-   ns1.example.   A       192.0.2.1
-                  RRSIG   A 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          bu6kx73n6XEunoVGuRfAgY7EF/AJqHy7hj0j
-                          kiqJjB0dOrx3wuz9SaBeGfqWIdn/uta3SavN
-                          4FRvZR9SCFHF5Q== )
-   ns2.example.   A       192.0.2.2
-                  RRSIG   A 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          ktQ3TqE0CfRfki0Rb/Ip5BM0VnxelbuejCC4
-                          zpLbFKA/7eD7UNAwxMgxJPtbdST+syjYSJaj
-                          4IHfeX6n8vfoGA== )
-   q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
-                          r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3
-                          ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN
-                          NlkxWcLsIlMmUg== )
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 38]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd (
-                          t644ebqk9bibcna874givr6joj62mlhv MX RRSIG )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          aupviViruXs4bDg9rCbezzBMf9h1ZlDvbW/C
-                          ZFKulIGXXLj8B/fsDJarXVDA9bnUoRhEbKp+
-                          HF1FWKW7RIJdtQ== )
-   t644ebqk9bibcna874givr6joj62mlhv.example. NSEC3 1 1 12 aabbccdd (
-                          0p9mhaveqvm6t7vbl5lop2u3t2rp3tom HINFO A AAAA
-                          RRSIG )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          RAjGECB8P7O+F4Pa4Dx3tC0M+Z3KmlLKImca
-                          fb9XWwx+NWUNz7NBEDBQHivIyKPVDkChcePI
-                          X1xPl1ATNa+8Dw== )
-   *.w.example.   MX      1 ai.example.
-                  RRSIG   MX 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          CikebjQwGQPwijVcxgcZcSJKtfynugtlBiKb
-                          9FcBTrmOoyQ4InoWVudhCWsh/URX3lc4WRUM
-                          ivEBP6+4KS3ldA== )
-   x.w.example.   MX      1 xx.example.
-                  RRSIG   MX 7 3 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          IrK3tq/tHFIBF0scHiE/1IwMAvckS/55hAVv
-                          QyxTFbkAdDloP3NbZzu+yoSsr3b3OX6qbBpY
-                          7WCtwwekLKRAwQ== )
-   x.y.w.example. MX      1 xx.example.
-                  RRSIG   MX 7 4 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          MqSt5HqJIN8+SLlzTOImrh5h9Xa6gDvAW/Gn
-                          nbdPc6Z7nXvCpLPJj/5lCwx3VuzVOjkbvXze
-                          8/8Ccl2Zn2hbug== )
-   xx.example.    A       192.0.2.10
-                  RRSIG   A 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          T35hBWEZ017VC5u2c4OriKyVn/pu+fVK4AlX
-                          YOxJ6iQylfV2HQIKjv6b7DzINB3aF/wjJqgX
-                          pQvhq+Ac6+ZiFg== )
-                  HINFO   "KLH-10" "TOPS-20"
-                  RRSIG   HINFO 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          KimG+rDd+7VA1zRsu0ITNAQUTRlpnsmqWrih
-                          FRnU+bRa93v2e5oFNFYCs3Rqgv62K93N7AhW
-                          6Jfqj/8NzWjvKg== )
-                  AAAA    2001:db8:0:0:0:0:f00:baaa
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 39]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-                  RRSIG   AAAA 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          IXBcXORITNwd8h3gNwyxtYFvAupS/CYWufVe
-                          uBUX0O25ivBCULjZjpDxFSxfohb/KA7YRdxE
-                          NzYfMItpILl/Xw== )
-
-Appendix B.  Example Responses
-
-   The examples in this section show response messages using the signed
-   zone example in Appendix A.
-
-B.1.  Name Error
-
-   An authoritative name error.  The NSEC3 RRs prove that the name does
-   not exist and that there is no wildcard RR that should have been
-   expanded.
-
-;; Header: QR AA DO RCODE=3
-;;
-;; Question
-a.c.x.w.example.         IN A
-
-;; Answer
-;; (empty)
-
-;; Authority
-
-example.       SOA     ns1.example. bugs.x.w.example. 1 3600 300 (
-                       3600000 3600 )
-example.       RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
-                       40430 example.
-                       Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
-                       q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
-                       VI2LmKusbZsT0Q== )
-
-;; NSEC3 RR that covers the "next closer" name (c.x.w.example)
-;; H(c.x.w.example) = 0va5bpr2ou0vk0lbqeeljri88laipsfh
-
-0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
-                       2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
-                       SOA NSEC3PARAM RRSIG )
-0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600 (
-                       20150420235959 20051021000000 40430 example.
-                       OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
-                       IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
-                       BOCXJZMnpuwhpA== )
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 40]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-;; NSEC3 RR that matches the closest encloser (x.w.example)
-;; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995
-
-b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd (
-                       gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG )
-b4um86eghhds6nea196smvmlo4ors995.example. RRSIG NSEC3 7 2 3600 (
-                       20150420235959 20051021000000 40430 example.
-                       ZkPG3M32lmoHM6pa3D6gZFGB/rhL//Bs3Omh
-                       5u4m/CUiwtblEVOaAKKZd7S959OeiX43aLX3
-                       pOv0TSTyiTxIZg== )
-
-;; NSEC3 RR that covers wildcard at the closest encloser (*.x.w.example)
-;; H(*.x.w.example) = 92pqneegtaue7pjatc3l3qnk738c6v5m
-
-35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
-                       b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
-35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 7 2 3600 (
-                       20150420235959 20051021000000 40430 example.
-                       g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ
-                       Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ
-                       XtAIR3chwgW+SA== )
-
-;; Additional
-;; (empty)
-
-   The query returned three NSEC3 RRs that prove that the requested data
-   does not exist and that no wildcard expansion applies.  The negative
-   response is authenticated by verifying the NSEC3 RRs.  The
-   corresponding RRSIGs indicate that the NSEC3 RRs are signed by an
-   "example" DNSKEY of algorithm 7 and with key tag 40430.  The resolver
-   needs the corresponding DNSKEY RR in order to authenticate this
-   answer.
-
-   One of the owner names of the NSEC3 RRs matches the closest encloser.
-   One of the NSEC3 RRs prove that there exists no longer name.  One of
-   the NSEC3 RRs prove that there exists no wildcard RRSets that should
-   have been expanded.  The closest encloser can be found by applying
-   the algorithm in Section 8.3.
-
-   In the above example, the name 'x.w.example' hashes to
-   'b4um86eghhds6nea196smvmlo4ors995'.  This indicates that this might
-   be the closest encloser.  To prove that 'c.x.w.example' and
-   '*.x.w.example' do not exist, these names are hashed to,
-   respectively, '0va5bpr2ou0vk0lbqeeljri88laipsfh' and
-   '92pqneegtaue7pjatc3l3qnk738c6v5m'.  The first and last NSEC3 RRs
-   prove that these hashed owner names do not exist.
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 41]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-B.2.  No Data Error
-
-   A "no data" response.  The NSEC3 RR proves that the name exists and
-   that the requested RR type does not.
-
-;; Header: QR AA DO RCODE=0
-;;
-;; Question
-ns1.example.        IN MX
-
-;; Answer
-;; (empty)
-
-;; Authority
-example.       SOA     ns1.example. bugs.x.w.example. 1 3600 300 (
-                       3600000 3600 )
-example.       RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
-                       40430 example.
-                       Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
-                       q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
-                       VI2LmKusbZsT0Q== )
-
-;; NSEC3 RR matches the QNAME and shows that the MX type bit is not set.
-
-2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. NSEC3 1 1 12 aabbccdd (
-                       2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG )
-2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. RRSIG NSEC3 7 2 3600 (
-                       20150420235959 20051021000000 40430 example.
-                       OmBvJ1Vgg1hCKMXHFiNeIYHK9XVW0iLDLwJN
-                       4TFoNxZuP03gAXEI634YwOc4YBNITrj413iq
-                       NI6mRk/r1dOSUw== )
-;; Additional
-;; (empty)
-
-   The query returned an NSEC3 RR that proves that the requested name
-   exists ("ns1.example." hashes to "2t7b4g4vsa5smi47k61mv5bv1a22bojr"),
-   but the requested RR type does not exist (type MX is absent in the
-   type code list of the NSEC3 RR), and was not a CNAME (type CNAME is
-   also absent in the type code list of the NSEC3 RR).
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 42]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-B.2.1.  No Data Error, Empty Non-Terminal
-
-   A "no data" response because of an empty non-terminal.  The NSEC3 RR
-   proves that the name exists and that the requested RR type does not.
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- y.w.example.        IN A
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example.       SOA     ns1.example. bugs.x.w.example. 1 3600 300 (
-                        3600000 3600 )
- example.       RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
-                        40430 example.
-                        Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
-                        q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
-                        VI2LmKusbZsT0Q== )
-
- ;; NSEC3 RR matches the QNAME and shows that the A type bit is not set.
-
- ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd (
-                        k8udemvp1j2f7eg6jebps17vp3n8i58h )
- ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. RRSIG NSEC3 7 2 3600 (
-                        20150420235959 20051021000000 40430 example.
-                        gPkFp1s2QDQ6wQzcg1uSebZ61W33rUBDcTj7
-                        2F3kQ490fEdp7k1BUIfbcZtPbX3YCpE+sIt0
-                        MpzVSKfTwx4uYA== )
-
- ;; Additional
- ;; (empty)
-
-   The query returned an NSEC3 RR that proves that the requested name
-   exists ("y.w.example." hashes to "ji6neoaepv8b5o6k4ev33abha8ht9fgc"),
-   but the requested RR type does not exist (Type A is absent in the
-   Type Bit Maps field of the NSEC3 RR).  Note that, unlike an empty
-   non-terminal proof using NSECs, this is identical to a No Data Error.
-   This example is solely mentioned to be complete.
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 43]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-B.3.  Referral to an Opt-Out Unsigned Zone
-
-   The NSEC3 RRs prove that nothing for this delegation was signed.
-   There is no proof that the unsigned delegation exists.
-
-   ;; Header: QR DO RCODE=0
-   ;;
-   ;; Question
-   mc.c.example.       IN MX
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   c.example.     NS      ns1.c.example.
-                  NS      ns2.c.example.
-
-   ;; NSEC3 RR that covers the "next closer" name (c.example)
-   ;; H(c.example) = 4g6p9u5gvfshp30pqecj98b3maqbn1ck
-
-   35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
-                          b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
-   35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 7 2 3600 (
-                          20150420235959 20051021000000 40430 example.
-                          g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ
-                          Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ
-                          XtAIR3chwgW+SA== )
-
-   ;; NSEC3 RR that matches the closest encloser (example)
-   ;; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom
-
-   0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
-                          2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
-                          SOA NSEC3PARAM RRSIG )
-   0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600 (
-                          20150420235959 20051021000000 40430 example.
-                          OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
-                          IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
-                          BOCXJZMnpuwhpA== )
-
-   ;; Additional
-   ns1.c.example. A       192.0.2.7
-   ns2.c.example. A       192.0.2.8
-
-   The query returned a referral to the unsigned "c.example." zone.  The
-   response contains the closest provable encloser of "c.example" to be
-   "example", since the hash of "c.example"
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 44]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   ("4g6p9u5gvfshp30pqecj98b3maqbn1ck") is covered by the first NSEC3 RR
-   and its Opt-Out bit is set.
-
-B.4.  Wildcard Expansion
-
-   A query that was answered with a response containing a wildcard
-   expansion.  The label count in the RRSIG RRSet in the answer section
-   indicates that a wildcard RRSet was expanded to produce this
-   response, and the NSEC3 RR proves that no "next closer" name exists
-   in the zone.
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   a.z.w.example. IN MX
-
-   ;; Answer
-   a.z.w.example. MX      1 ai.example.
-   a.z.w.example. RRSIG   MX 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          CikebjQwGQPwijVcxgcZcSJKtfynugtlBiKb
-                          9FcBTrmOoyQ4InoWVudhCWsh/URX3lc4WRUM
-                          ivEBP6+4KS3ldA== )
-
-   ;; Authority
-   example.       NS      ns1.example.
-   example.       NS      ns2.example.
-   example.       RRSIG   NS 7 1 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          PVOgtMK1HHeSTau+HwDWC8Ts+6C8qtqd4pQJ
-                          qOtdEVgg+MA+ai4fWDEhu3qHJyLcQ9tbD2vv
-                          CnMXjtz6SyObxA== )
-
-   ;; NSEC3 RR that covers the "next closer" name (z.w.example)
-   ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03
-
-   q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
-                          r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
-   q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 7 2 3600 (
-                          20150420235959 20051021000000 40430 example.
-                          hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3
-                          ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN
-                          NlkxWcLsIlMmUg== )
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 45]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   ;; Additional
-   ai.example.    A       192.0.2.9
-   ai.example.    RRSIG   A 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          hVe+wKYMlObTRPhX0NL67GxeZfdxqr/QeR6F
-                          tfdAj5+FgYxyzPEjIzvKWy00hWIl6wD3Vws+
-                          rznEn8sQ64UdqA== )
-   ai.example.    AAAA    2001:db8:0:0:0:0:f00:baa9
-   ai.example.    RRSIG   AAAA 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          LcdxKaCB5bGZwPDg+3JJ4O02zoMBrjxqlf6W
-                          uaHQZZfTUpb9Nf2nxFGe2XRPfR5tpJT6GdRG
-                          cHueLuXkMjBArQ== )
-
-   The query returned an answer that was produced as a result of a
-   wildcard expansion.  The answer section contains a wildcard RRSet
-   expanded as it would be in a traditional DNS response.  The RRSIG
-   Labels field value of 2 indicates that the answer is the result of a
-   wildcard expansion, as the "a.z.w.example" name contains 4 labels.
-   This also shows that "w.example" exists, so there is no need for an
-   NSEC3 RR that matches the closest encloser.
-
-   The NSEC3 RR proves that no closer match could have been used to
-   answer this query.
-
-B.5.  Wildcard No Data Error
-
-   A "no data" response for a name covered by a wildcard.  The NSEC3 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
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       SOA     ns1.example. bugs.x.w.example. 1 3600 300 (
-                          3600000 3600 )
-   example.       RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
-                          q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
-                          VI2LmKusbZsT0Q== )
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 46]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   ;; NSEC3 RR that matches the closest encloser (w.example)
-   ;; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h
-
-   k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd (
-                          kohar7mbb8dc2ce8a9qvl8hon4k53uhi )
-   k8udemvp1j2f7eg6jebps17vp3n8i58h.example. RRSIG NSEC3 7 2 3600 (
-                          20150420235959 20051021000000 40430 example.
-                          FtXGbvF0+wf8iWkyo73enAuVx03klN+pILBK
-                          S6qCcftVtfH4yVzsEZquJ27NHR7ruxJWDNMt
-                          Otx7w9WfcIg62A== )
-
-   ;; NSEC3 RR that covers the "next closer" name (z.w.example)
-   ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03
-
-   q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
-                          r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
-   q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 7 2 3600 (
-                          20150420235959 20051021000000 40430 example.
-                          hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3
-                          ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN
-                          NlkxWcLsIlMmUg== )
-
-   ;; NSEC3 RR that matches a wildcard at the closest encloser.
-   ;; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en
-
-   r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd (
-                          t644ebqk9bibcna874givr6joj62mlhv MX RRSIG )
-   r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. RRSIG NSEC3 7 2 3600 (
-                          20150420235959 20051021000000 40430 example.
-                          aupviViruXs4bDg9rCbezzBMf9h1ZlDvbW/C
-                          ZFKulIGXXLj8B/fsDJarXVDA9bnUoRhEbKp+
-                          HF1FWKW7RIJdtQ== )
-
-   ;; Additional
-   ;; (empty)
-
-   The query returned the NSEC3 RRs that prove that the requested data
-   does not exist and no wildcard RR applies.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 47]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-B.6.  DS Child Zone No Data Error
-
-   A "no data" response for a QTYPE=DS query that was mistakenly sent to
-   a name server for the child zone.
-
-;; Header: QR AA DO RCODE=0
-;;
-;; Question
-example.            IN DS
-
-;; Answer
-;; (empty)
-
-;; Authority
-example.       SOA     ns1.example. bugs.x.w.example. 1 3600 300 (
-                       3600000 3600 )
-example.       RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
-                       40430 example.
-                       Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
-                       q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
-                       VI2LmKusbZsT0Q== )
-
-;; NSEC3 RR matches the QNAME and shows that the DS type bit is not set.
-
-0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
-                       2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
-                       SOA NSEC3PARAM RRSIG )
-0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600
-                       20150420235959 20051021000000 40430 example.
-                       OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
-                       IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
-                       BOCXJZMnpuwhpA== )
-
-;; Additional
-;; (empty)
-
-   The query returned an NSEC3 RR showing that the requested was
-   answered by the server authoritative for the zone "example".  The
-   NSEC3 RR indicates the presence of an SOA RR, showing that this NSEC3
-   RR is from the apex of the child, not from the zone cut of the
-   parent.  Queries for the "example" DS RRSet should be sent to the
-   parent servers (which are in this case the root servers).
-
-Appendix C.  Special Considerations
-
-   The following paragraphs clarify specific behavior and explain
-   special considerations for implementations.
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 48]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-C.1.  Salting
-
-   Augmenting original owner names with salt before hashing increases
-   the cost of a dictionary of pre-generated hash-values.  For every bit
-   of salt, the cost of a precomputed dictionary doubles (because there
-   must be an entry for each word combined with each possible salt
-   value).  The NSEC3 RR can use a maximum of 2040 bits (255 octets) of
-   salt, multiplying the cost by 2^2040.  This means that an attacker
-   must, in practice, recompute the dictionary each time the salt is
-   changed.
-
-   Including a salt, regardless of size, does not affect the cost of
-   constructing NSEC3 RRs.  It does increase the size of the NSEC3 RR.
-
-   There MUST be at least one complete set of NSEC3 RRs for the zone
-   using the same salt value.
-
-   The salt SHOULD be changed periodically to prevent pre-computation
-   using a single salt.  It is RECOMMENDED that the salt be changed for
-   every re-signing.
-
-   Note that this could cause a resolver to see RRs with different salt
-   values for the same zone.  This is harmless, since each RR stands
-   alone (that is, it denies the set of owner names whose hashes, using
-   the salt in the NSEC3 RR, fall between the two hashes in the NSEC3
-   RR) -- it is only the server that needs a complete set of NSEC3 RRs
-   with the same salt in order to be able to answer every possible
-   query.
-
-   There is no prohibition with having NSEC3 RRs with different salts
-   within the same zone.  However, in order for authoritative servers to
-   be able to consistently find covering NSEC3 RRs, the authoritative
-   server MUST choose a single set of parameters (algorithm, salt, and
-   iterations) to use when selecting NSEC3 RRs.
-
-C.2.  Hash Collision
-
-   Hash collisions occur when different messages have the same hash
-   value.  The expected number of domain names needed to give a 1 in 2
-   chance of a single collision is about 2^(n/2) for a hash of length n
-   bits (i.e., 2^80 for SHA-1).  Though this probability is extremely
-   low, the following paragraphs deal with avoiding collisions and
-   assessing possible damage in the event of an attack using hash
-   collisions.
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 49]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-C.2.1.  Avoiding Hash Collisions During Generation
-
-   During generation of NSEC3 RRs, hash values are supposedly unique.
-   In the (academic) case of a collision occurring, an alternative salt
-   MUST be chosen and all hash values MUST be regenerated.
-
-C.2.2.  Second Preimage Requirement Analysis
-
-   A cryptographic hash function has a second-preimage resistance
-   property.  The second-preimage resistance property means that it is
-   computationally infeasible to find another message with the same hash
-   value as a given message, i.e., given preimage X, to find a second
-   preimage X' != X such that hash(X) = hash(X').  The work factor for
-   finding a second preimage is of the order of 2^160 for SHA-1.  To
-   mount an attack using an existing NSEC3 RR, an adversary needs to
-   find a second preimage.
-
-   Assuming an adversary is capable of mounting such an extreme attack,
-   the actual damage is that a response message can be generated that
-   claims that a certain QNAME (i.e., the second pre-image) does exist,
-   while in reality QNAME does not exist (a false positive), which will
-   either cause a security-aware resolver to re-query for the non-
-   existent name, or to fail the initial query.  Note that the adversary
-   can't mount this attack on an existing name, but only on a name that
-   the adversary can't choose and that does not yet exist.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 50]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-Authors' Addresses
-
-   Ben Laurie
-   Nominet
-   17 Perryn Road
-   London  W3 7LR
-   England
-
-   Phone: +44 20 8735 0686
-   EMail: ben@links.org
-
-
-   Geoffrey Sisson
-   Nominet
-   Minerva House
-   Edmund Halley Road
-   Oxford Science Park
-   Oxford  OX4 4DQ
-   UNITED KINGDOM
-
-   Phone: +44 1865 332211
-   EMail: geoff-s@panix.com
-
-
-   Roy Arends
-   Nominet
-   Minerva House
-   Edmund Halley Road
-   Oxford Science Park
-   Oxford  OX4 4DQ
-   UNITED KINGDOM
-
-   Phone: +44 1865 332211
-   EMail: roy@nominet.org.uk
-
-
-   David Blacka
-   VeriSign, Inc.
-   21355 Ridgetop Circle
-   Dulles, VA  20166
-   US
-
-   Phone: +1 703 948 3200
-   EMail: davidb@verisign.com
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 51]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   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, THE IETF TRUST 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.
-
-Intellectual Property
-
-   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.
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 52]
-
diff --git a/contrib/bind9/doc/rfc/rfc952.txt b/contrib/bind9/doc/rfc/rfc952.txt
deleted file mode 100644
index 7df339a..0000000
--- a/contrib/bind9/doc/rfc/rfc952.txt
+++ /dev/null
@@ -1,340 +0,0 @@
-Network Working Group                               K. Harrenstien (SRI)
-Request for Comments: 952                                 M. Stahl (SRI)
-                                                        E. Feinler (SRI)
-Obsoletes:  RFC 810, 608                                    October 1985
-
-                 DOD INTERNET HOST TABLE SPECIFICATION
-
-
-STATUS OF THIS MEMO
-
-   This RFC is the official specification of the format of the Internet
-   Host Table.  This edition of the specification includes minor
-   revisions to RFC-810 which brings it up to date. Distribution of this
-   memo is unlimited.
-
-INTRODUCTION
-
-   The DoD Host Table is utilized by the DoD Hostname Server maintained
-   by the DDN Network Information Center (NIC) on behalf of the Defense
-   Communications Agency (DCA) [See RFC-953].
-
-LOCATION OF THE STANDARD DOD ONLINE HOST TABLE
-
-   A machine-translatable ASCII text version of the DoD Host Table is
-   online in the file NETINFO:HOSTS.TXT on the SRI-NIC host.  It can be
-   obtained via FTP from your local host by connecting to host
-   SRI-NIC.ARPA (26.0.0.73 or 10.0.0.51), logging in as user =
-   ANONYMOUS, password = GUEST, and retrieving the file
-   "NETINFO:HOSTS.TXT".  The same table may also be obtained via the NIC
-   Hostname Server, as described in RFC-953.  The latter method is
-   faster and easier, but requires a user program to make the necessary
-   connection to the Name Server.
-
-ASSUMPTIONS
-
-   1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
-   to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
-   sign (-), and period (.).  Note that periods are only allowed when
-   they serve to delimit components of "domain style names". (See
-   RFC-921, "Domain Name System Implementation Schedule", for
-   background).  No blank or space characters are permitted as part of a
-   name. No distinction is made between upper and lower case.  The first
-   character must be an alpha character.  The last character must not be
-   a minus sign or period.  A host which serves as a GATEWAY should have
-   "-GATEWAY" or "-GW" as part of its name.  Hosts which do not serve as
-   Internet gateways should not use "-GATEWAY" and "-GW" as part of
-   their names. A host which is a TAC should have "-TAC" as the last
-   part of its host name, if it is a DoD host.  Single character names
-   or nicknames are not allowed.
-
-   2. Internet Addresses are 32-bit addresses [See RFC-796].  In the
-
-
-Harrenstien & Stahl & Feinler                                   [Page 1]
-
-
-
-RFC 952                                                     October 1985
-DOD INTERNET HOST TABLE SPECIFICATION
-
-
-   host table described herein each address is represented by four
-   decimal numbers separated by a period.  Each decimal number
-   represents 1 octet.
-
-   3. If the first bit of the first octet of the address is 0 (zero),
-   then the next 7 bits of the first octet indicate the network number
-   (Class A Address).  If the first two bits are 1,0 (one,zero), then
-   the next 14 bits define the net number (Class B Address).  If the
-   first 3 bits are 1,1,0 (one,one,zero), then the next 21 bits define
-   the net number (Class C Address) [See RFC-943].
-
-      This is depicted in the following diagram:
-
-      +-+------------+--------------+--------------+--------------+
-      |0|  NET <-7-> |         LOCAL ADDRESS <-24->               |
-      +-+------------+--------------+--------------+--------------+
-
-      +---+----------+--------------+--------------+--------------+
-      |1 0|      NET  <-14->        |  LOCAL ADDRESS <-16->       |
-      +---+----------+--------------+--------------+--------------+
-
-      +-----+--------+--------------+--------------+--------------+
-      |1 1 0|            NET  <-21->               | LOCAL ADDRESS|
-      +-----+--------+--------------+--------------+--------------+
-
-   4. The LOCAL ADDRESS portion of the internet address identifies a
-   host within the network specified by the NET portion of the address.
-
-   5. The ARPANET and MILNET are both Class A networks.  The NET portion
-   is 10 decimal for ARPANET, 26 decimal for MILNET, and the LOCAL
-   ADDRESS maps as follows: the second octet identifies the physical
-   host, the third octet identifies the logical host, and the fourth
-   identifies the Packet Switching Node (PSN), formerly known as an
-   Interface Message Processor (IMP).
-
-      +-+------------+--------------+--------------+--------------+
-      |0|  10 or 26  |    HOST      | LOGICAL HOST |   PSN (IMP)  |
-      +-+------------+--------------+--------------+--------------+
-
-      (NOTE:  RFC-796 also describes the local address mappings for
-      several other networks.)
-
-   6. It is the responsibility of the users of this host table to
-   translate it into whatever format is needed for their purposes.
-
-   7. Names and addresses for DoD hosts and gateways will be negotiated
-   and registered with the DDN PMO, and subsequently with the NIC,
-
-
-Harrenstien & Stahl & Feinler                                   [Page 2]
-
-
-
-RFC 952                                                     October 1985
-DOD INTERNET HOST TABLE SPECIFICATION
-
-
-   before being used and before traffic is passed by a DoD host.  Names
-   and addresses for domains and networks are to be registered with the
-   DDN Network Information Center (HOSTMASTER@SRI-NIC.ARPA) or
-   800-235-3155.
-
-   The NIC will attempt to keep similar information for non-DoD networks
-   and hosts, if this information is provided, and as long as it is
-   needed, i.e., until intercommunicating network name servers are in
-   place.
-
-EXAMPLE OF HOST TABLE FORMAT
-
-   NET : 10.0.0.0 : ARPANET :
-   NET : 128.10.0.0 : PURDUE-CS-NET :
-   GATEWAY : 10.0.0.77, 18.10.0.4 : MIT-GW.ARPA,MIT-GATEWAY : PDP-11 :
-             MOS : IP/GW,EGP :
-   HOST : 26.0.0.73, 10.0.0.51 : SRI-NIC.ARPA,SRI-NIC,NIC : DEC-2060 :
-          TOPS20 :TCP/TELNET,TCP/SMTP,TCP/TIME,TCP/FTP,TCP/ECHO,ICMP :
-   HOST : 10.2.0.11 : SU-TAC.ARPA,SU-TAC : C/30 : TAC : TCP :
-
-SYNTAX AND CONVENTIONS
-
-   ; (semicolon)   is used to denote the beginning of a comment.
-                   Any text on a given line following a ';' is a
-                   comment, and not part of the host table.
-
-   NET             keyword introducing a network entry
-
-   GATEWAY         keyword introducing a gateway entry
-
-   HOST            keyword introducing a host entry
-
-   DOMAIN          keyword introducing a domain entry
-
-   :(colon)        is used as a field delimiter
-
-   ::(2 colons)    indicates a null field
-
-   ,(comma)        is used as a data element delimiter
-
-   XXX/YYY         indicates protocol information of the type
-                   TRANSPORT/SERVICE.
-
-      where TRANSPORT/SERVICE options are specified as
-
-         "FOO/BAR"       both transport and service known
-
-
-
-Harrenstien & Stahl & Feinler                                   [Page 3]
-
-
-
-RFC 952                                                     October 1985
-DOD INTERNET HOST TABLE SPECIFICATION
-
-
-         "FOO"           transport known; services not known
-
-         "BAR"           service is known, transport not known
-
-         NOTE:  See "Assigned Numbers" for specific options and acronyms
-         for machine types, operating systems, and protocol/services.
-
-   Each host table entry is an ASCII text string comprised of 6 fields,
-   where
-
-      Field 1         KEYWORD indicating whether this entry pertains to
-                      a NET, GATEWAY, HOST, or DOMAIN.  NET entries are
-                      assigned and cannot have alternate addresses or
-                      nicknames.  DOMAIN entries do not use fields 4, 5,
-                      or 6.
-
-      Field 2         Internet Address of Network, Gateway, or Host
-                      followed by alternate addresses.  Addresses for a
-                      Domain are those where a Domain Name Server exists
-                      for that domain.
-
-      Field 3         Official Name of Network, Gateway, Host, or Domain
-                      (with optional nicknames, where permitted).
-
-      Field 4         Machine Type
-
-      Field 5         Operating System
-
-      Field 6         Protocol List
-
-   Fields 4, 5 and 6 are optional.  For a Domain they are not used.
-
-   Fields 3-6, if included, pertain to the first address in Field 2.
-
-   'Blanks' (spaces and tabs) are ignored between data elements or
-   fields, but are disallowed within a data element.
-
-   Each entry ends with a colon.
-
-   The entries in the table are grouped by types in the order Domain,
-   Net, Gateway, and Host.  Within each type the ordering is
-   unspecified.
-
-   Note that although optional nicknames are allowed for hosts, they are
-   discouraged, except in the case where host names have been changed
-
-
-
-
-Harrenstien & Stahl & Feinler                                   [Page 4]
-
-
-
-RFC 952                                                     October 1985
-DOD INTERNET HOST TABLE SPECIFICATION
-
-
-   and both the new and the old names are maintained for a suitable
-   period of time to effect a smooth transition.  Nicknames are not
-   permitted for NET names.
-
-GRAMMATICAL HOST TABLE SPECIFICATION
-
-   A. Parsing grammar
-
-      <entry> ::= <keyword> ":" <addresses> ":" <names> [":" [<cputype>]
-         [":" [<opsys>]  [":" [<protocol list>] ]]] ":"
-      <addresses> ::= <address> *["," <address>]
-      <address> ::= <octet> "." <octet> "." <octet> "." <octet>
-      <octet> ::= <0 to 255 decimal>
-      <names> ::= <netname> | <gatename> | <domainname> *[","
-         <nicknames>]
-         | <official hostname> *["," <nicknames>]
-      <netname>  ::= <name>
-      <gatename> ::= <hname>
-      <domainname> ::= <hname>
-      <official hostname> ::= <hname>
-      <nickname> ::= <hname>
-      <protocol list> ::= <protocol spec> *["," <protocol spec>]
-      <protocol spec> ::= <transport name> "/" <service name>
-         | <raw protocol name>
-
-   B. Lexical grammar
-
-      <entry-field> ::= <entry-text> [<cr><lf> <blank> <entry-field>]
-      <entry-text>  ::= <print-char> *<text>
-      <blank> ::= <space-or-tab> [<blank>]
-      <keyword> ::= NET | GATEWAY | HOST | DOMAIN
-      <hname> ::= <name>*["."<name>]
-      <name>  ::= <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>]
-      <cputype> ::= PDP-11/70 | DEC-1080 | C/30 | CDC-6400...etc.
-      <opsys>   ::= ITS | MULTICS | TOPS20 | UNIX...etc.
-      <transport name> ::= TCP | NCP | UDP | IP...etc.
-      <service name> ::= TELNET | FTP | SMTP | MTP...etc.
-      <raw protocol name> ::= <name>
-      <comment> ::= ";" <text><cr><lf>
-      <text>    ::= *[<print-char> | <blank>]
-      <print-char>  ::= <any printing char (not space or tab)>
-
-   Notes:
-
-      1. Zero or more 'blanks' between separators " , : " are allowed.
-      'Blanks' are spaces and tabs.
-
-
-
-Harrenstien & Stahl & Feinler                                   [Page 5]
-
-
-
-RFC 952                                                     October 1985
-DOD INTERNET HOST TABLE SPECIFICATION
-
-
-      2. Continuation lines are lines that begin with at least one
-      blank.  They may be used anywhere 'blanks' are legal to split an
-      entry across lines.
-
-BIBLIOGRAPHY
-
-   1. Feinler, E., Harrenstien, K., Su, Z. and White, V., "Official DoD
-      Internet Host Table Specification", RFC-810, Network Information
-      Center, SRI International, March 1982.
-
-   2. Harrenstien, K., Stahl, M., and Feinler, E., "Hostname Server",
-      RFC-953, Network Information Center, SRI International, October
-      1985.
-
-   3. Kudlick, M. "Host Names Online", RFC-608, Network Information
-      Center, SRI International, January 1973.
-
-   4. Postel, J., "Internet Protocol", RFC-791, Information Sciences
-      Institute, University of Southern California, Marina del Rey,
-      September 1981.
-
-   5. Postel, J., "Address Mappings", RFC-796, Information Sciences
-      Institute, University of Southern California, Marina del Rey,
-      September 1981.
-
-   6. Postel, J., "Domain Name System Implementation Schedule", RFC-921,
-      Information Sciences Institute, University of Southern California,
-      Marina del Rey, October 1984.
-
-   7. Reynolds, J. and Postel, J., "Assigned Numbers", RFC-943,
-      Information Sciences Institute, University of Southern California,
-      Marina del Rey, April 1985.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Harrenstien & Stahl & Feinler                                   [Page 6]
-
diff --git a/contrib/bind9/isc-config.sh.in b/contrib/bind9/isc-config.sh.in
deleted file mode 100644
index 45aab66..0000000
--- a/contrib/bind9/isc-config.sh.in
+++ /dev/null
@@ -1,149 +0,0 @@
-#!/bin/sh
-#
-# 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: isc-config.sh.in,v 1.15 2004/03/05 04:56:57 marka Exp $
-
-prefix=@prefix@
-exec_prefix=@exec_prefix@
-exec_prefix_set=
-
-usage()
-{
-	cat << EOF
-Usage: isc-config [OPTIONS] [LIBRARIES]
-Options:
-	[--prefix[=DIR]]
-	[--exec-prefix[=DIR]]
-	[--version]
-	[--libs]
-	[--cflags]
-Libraries:
-	isc
-	isccc
-	isccfg
-	dns
-	lwres
-	bind9
-EOF
-	exit $1
-}
-
-if test $# -eq 0; then
-	usage 1 1>&2
-fi
-
-while test $# -gt 0; do
-	case "$1" in
-	-*=*) optarg=`echo "$1" | sed 's/[-_a-zA-Z0-9]*=//'` ;;
-	*) optarg= ;;
-	esac
-
-	case "$1" in
-	--prefix=*)
-		prefix=$optarg
-		if test "x$exec_prefix_set" = x ; then
-			exec_prefix=$prefix
-		fi
-		;;
-	--prefix)
-		echo_prefix=true
-		;;
-	--exec-prefix=*)
-		exec_prefix=$optarg
-		;;
-	--exec-prefix)
-		echo_exec_prefix=true
-		;;
-	--version)
-		echo @BIND9_VERSION@
-		exit 0
-		;;
-	--cflags)
-		echo_cflags=true
-		;;
-	--libs)
-		echo_libs=true;
-		;;
-	isc)
-		libisc=true;
-		;;
-	isccc)
-		libisccc=true;
-		libisc=true;
-		;;
-	isccfg)
-		libisccfg=true;
-		libisc=true;
-		;;
-	dns)
-		libdns=true;
-		libisc=true;
-		;;
-	lwres)
-		liblwres=true;
-		;;
-	bind9)
-		libdns=true;
-		libisc=true;
-		libisccfg=true;
-		libbind9=true;
-		;;
-	*)
-		usage 1 1>&2
-	esac
-	shift
-done
-
-if test x"$echo_prefix" = x"true" ; then
-	echo $prefix
-fi
-if test x"$echo_exec_prefix" = x"true" ; then
-	echo $exec_prefix
-fi
-if test x"$echo_cflags" = x"true"; then
-	includes="-I${exec_prefix}/include"
-	if test x"$libisc" = x"true"; then
-		includes="$includes @ALWAYS_DEFINES@ @STD_CINCLUDES@ @STD_CDEFINES@ @CCOPT@"
-	fi
-	echo $includes
-fi
-if test x"$echo_libs" = x"true"; then
-	libs=-L${exec_prefix}/lib
-	if test x"$liblwres" = x"true" ; then
-		libs="$libs -llwres"
-	fi
-	if test x"$libbind9" = x"true" ; then
-		libs="$libs -lbind9"
-	fi
-	if test x"$libdns" = x"true" ; then
-		libs="$libs -ldns @DNS_CRYPTO_LIBS@"
-	fi
-	if test x"$libisccfg" = x"true" ; then
-		libs="$libs -lisccfg"
-	fi
-	if test x"$libisccc" = x"true" ; then
-		libs="$libs -lisccc"
-	fi
-	if test x"$libisc" = x"true" ; then
-		libs="$libs -lisc"
-		needothers=true
-	fi
-	if test x"$needothers" = x"true" ; then
-		libs="$libs @CCOPT@ @LIBS@"
-	fi
-	echo $libs
-fi
diff --git a/contrib/bind9/lib/Makefile.in b/contrib/bind9/lib/Makefile.in
index e8be294..e46aef2 100644
--- a/contrib/bind9/lib/Makefile.in
+++ b/contrib/bind9/lib/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1998-2001, 2003  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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 2004/03/05 05:05:00 marka Exp $
+# $Id: Makefile.in,v 1.21 2007/06/19 23:47:13 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/bind/Makefile.in b/contrib/bind9/lib/bind/Makefile.in
deleted file mode 100644
index fd9a16f..0000000
--- a/contrib/bind9/lib/bind/Makefile.in
+++ /dev/null
@@ -1,133 +0,0 @@
-# Copyright (C) 2004-2006  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: Makefile.in,v 1.22.18.7 2006/06/24 00:25:39 marka Exp $
-
-srcdir =        @srcdir@
-VPATH =         @srcdir@
-top_srcdir =    @top_srcdir@
-
-
-@LIBBIND_API@
-
-LIBS =		@LIBS@
-
-DAEMON_OBJS=bsd/daemon.@O@
-STRSEP_OBJS=bsd/strsep.@O@
-
-BSDOBJS= @DAEMON_OBJS@ @STRSEP_OBJS@ bsd/ftruncate.@O@ bsd/gettimeofday.@O@ \
-        bsd/mktemp.@O@ bsd/putenv.@O@ bsd/readv.@O@ bsd/setenv.@O@ \
-	bsd/setitimer.@O@ bsd/strcasecmp.@O@ bsd/strdup.@O@ \
-        bsd/strerror.@O@ bsd/strpbrk.@O@ bsd/strtoul.@O@ bsd/utimes.@O@ \
-        bsd/writev.@O@
-
-DSTOBJS= dst/dst_api.@O@ dst/hmac_link.@O@ dst/md5_dgst.@O@ dst/support.@O@
-
-INETOBJS= inet/inet_addr.@O@ inet/inet_cidr_ntop.@O@ inet/inet_cidr_pton.@O@ \
-	inet/inet_data.@O@ inet/inet_lnaof.@O@ inet/inet_makeaddr.@O@ \
-	inet/inet_net_ntop.@O@ inet/inet_net_pton.@O@ inet/inet_neta.@O@ \
-	inet/inet_netof.@O@ inet/inet_network.@O@ inet/inet_ntoa.@O@ \
-	inet/inet_ntop.@O@ inet/inet_pton.@O@ inet/nsap_addr.@O@
-
-WANT_IRS_THREADS_OBJS=	irs/gethostent_r.@O@ irs/getnetent_r.@O@ \
-	irs/getnetgrent_r.@O@ irs/getprotoent_r.@O@ irs/getservent_r.@O@
-
-WANT_IRS_NISGR_OBJS= irs/nis_gr.@O@ 
-WANT_IRS_GR_OBJS= irs/dns_gr.@O@ irs/irp_gr.@O@ irs/lcl_gr.@O@ irs/gen_gr.@O@ \
-	irs/getgrent.@O@ @WANT_IRS_NISGR_OBJS@ @WANT_IRS_THREADSGR_OBJS@
-
-WANT_IRS_THREADSPW_OBJS=irs/getpwent_r.@O@
-WANT_IRS_NISPW_OBJS= irs/nis_pw.@O@
-WANT_IRS_DBPW_OBJS=irs/irp_pw.@O@ irs/lcl_pw.@O@
-WANT_IRS_PW_OBJS= irs/dns_pw.@O@ irs/gen_pw.@O@ irs/getpwent.@O@ \
-	@WANT_IRS_DBPW_OBJS@ @WANT_IRS_NISPW_OBJS@ @WANT_IRS_THREADSPW_OBJS@
-
-WANT_IRS_NIS_OBJS= irs/nis_ho.@O@ irs/nis_ng.@O@ irs/nis_nw.@O@ \
-	irs/nis_pr.@O@ irs/nis_sv.@O@
-
-IRSOBJS= @WANT_IRS_GR_OBJS@ @WANT_IRS_NIS_OBJS@ @WANT_IRS_THREADS_OBJS@ \
-	@WANT_IRS_PW_OBJS@ \
-	irs/dns.@O@ irs/dns_ho.@O@ irs/dns_nw.@O@ irs/dns_pr.@O@ \
-	irs/dns_sv.@O@ irs/gai_strerror.@O@ irs/gen.@O@ irs/gen_ho.@O@ \
-	irs/gen_ng.@O@ irs/gen_nw.@O@ irs/gen_pr.@O@ irs/gen_sv.@O@ \
-	irs/getaddrinfo.@O@ irs/gethostent.@O@  irs/getnameinfo.@O@ \
-	irs/getnetent.@O@ irs/getnetgrent.@O@ \
-	irs/getprotoent.@O@ irs/getservent.@O@ irs/hesiod.@O@ \
-	irs/irp.@O@ irs/irp_ho.@O@ irs/irp_ng.@O@ irs/irp_nw.@O@ \
-	irs/irp_pr.@O@ irs/irp_sv.@O@ irs/irpmarshall.@O@ irs/irs_data.@O@ \
-	irs/lcl.@O@ irs/lcl_ho.@O@ irs/lcl_ng.@O@ irs/lcl_nw.@O@ \
-	irs/lcl_pr.@O@ irs/lcl_sv.@O@ irs/nis.@O@ irs/nul_ng.@O@ irs/util.@O@
-
-WANT_IRS_THREADSGR_OBJS=irs/getgrent_r.@O@
-
-ISCOBJS= isc/assertions.@O@ isc/base64.@O@ isc/bitncmp.@O@ isc/ctl_clnt.@O@ \
-	isc/ctl_p.@O@ isc/ctl_srvr.@O@ isc/ev_connects.@O@ isc/ev_files.@O@ \
-	isc/ev_streams.@O@ isc/ev_timers.@O@ isc/ev_waits.@O@ \
-	isc/eventlib.@O@ isc/heap.@O@ isc/hex.@O@ isc/logging.@O@ \
-	isc/memcluster.@O@ isc/movefile.@O@ isc/tree.@O@
-
-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/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@
-
-TARGETS= timestamp
-OBJS=	${BSDOBJS} ${DSTOBJS} ${INETOBJS} ${IRSOBJS} ${ISCOBJS} \
-	${NAMESEROBJS} ${RESOLVOBJS}
-
-@BIND9_MAKE_RULES@
-
-# Attempt to disable parallel processing.
-.NOTPARALLEL:
-.NO_PARALLEL:
-
-libbind.@SA@: ${OBJS}
-	${AR} ${ARFLAGS} $@ ${OBJS}
-	${RANLIB} $@
-
-libbind.la: ${OBJS}
-	${LIBTOOL_MODE_LINK} \
-	${CC} ${ALL_CFLAGS} ${LDFLAGS} -o libbind.la -rpath ${libdir} \
-		-version-info ${LIBINTERFACE}:${LIBREVISION}:${LIBAGE} \
-		${OBJS} ${LIBS}
-
-timestamp: libbind.@A@
-	touch timestamp
-
-installdirs:
-	$(SHELL) ${top_srcdir}/mkinstalldirs ${DESTDIR}${libdir}
-
-install:: timestamp installdirs
-	${LIBTOOL_MODE_INSTALL} ${INSTALL_DATA} libbind.@A@ ${DESTDIR}${libdir}
-
-clean distclean::
-	rm -f libbind.@SA@ libbind.la
-
-distclean::
-	rm -f make/rules make/includes make/mkdep
-
-distclean::
-	rm -f config.cache config.h config.log config.status libtool
-	rm -f port_before.h port_after.h configure.lineno
-	rm -f port/Makefile @PORT_DIR@/Makefile
-
-man:
diff --git a/contrib/bind9/lib/bind/README b/contrib/bind9/lib/bind/README
deleted file mode 100644
index b89cff7..0000000
--- a/contrib/bind9/lib/bind/README
+++ /dev/null
@@ -1,4 +0,0 @@
---with-irs-gr=yes #define WANT_IRS_GR
---with-irs-nis=yes #define WANT_IRS_NIS
---with-irs-pw=yes #define WANT_IRS_PW
-
diff --git a/contrib/bind9/lib/bind/aclocal.m4 b/contrib/bind9/lib/bind/aclocal.m4
deleted file mode 100644
index 110ed87..0000000
--- a/contrib/bind9/lib/bind/aclocal.m4
+++ /dev/null
@@ -1,2 +0,0 @@
-sinclude(../../libtool.m4)dnl
-
diff --git a/contrib/bind9/lib/bind/api b/contrib/bind9/lib/bind/api
deleted file mode 100644
index 7ffeba8..0000000
--- a/contrib/bind9/lib/bind/api
+++ /dev/null
@@ -1,3 +0,0 @@
-LIBINTERFACE = 5
-LIBREVISION = 2
-LIBAGE = 1
diff --git a/contrib/bind9/lib/bind/bsd/Makefile.in b/contrib/bind9/lib/bind/bsd/Makefile.in
deleted file mode 100644
index 72a52f6..0000000
--- a/contrib/bind9/lib/bind/bsd/Makefile.in
+++ /dev/null
@@ -1,39 +0,0 @@
-# Copyright (C) 2004, 2008  Internet Systems Consortium, Inc. ("ISC")
-# Copyright (C) 2001  Internet Software Consortium.
-#
-# Permission to use, copy, modify, and/or 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: Makefile.in,v 1.7.18.2 2008/03/20 23:46:01 tbox Exp $
-
-srcdir=         @srcdir@
-VPATH =         @srcdir@
-
-DAEMON_OBJS=daemon.@O@
-STRSEP_OBJS=strsep.@O@
-
-OBJS=	@DAEMON_OBJS@ @STRSEP_OBJS@ ftruncate.@O@ gettimeofday.@O@ \
-	mktemp.@O@ putenv.@O@ \
-	readv.@O@ setenv.@O@ setitimer.@O@ strcasecmp.@O@ strdup.@O@ \
-	strerror.@O@ strpbrk.@O@ strtoul.@O@ utimes.@O@ \
-	writev.@O@
-
-SRCS=	daemon.c ftruncate.c gettimeofday.c mktemp.c putenv.c \
-	readv.c setenv.c setitimer.c strcasecmp.c strdup.c \
-	strerror.c strpbrk.c strsep.c strtoul.c utimes.c \
-	writev.c
-
-TARGETS= ${OBJS}
-
-CINCLUDES= -I.. -I../include -I${srcdir}/../include
-
-@BIND9_MAKE_RULES@
diff --git a/contrib/bind9/lib/bind/bsd/daemon.c b/contrib/bind9/lib/bind/bsd/daemon.c
deleted file mode 100644
index a7d2ded..0000000
--- a/contrib/bind9/lib/bind/bsd/daemon.c
+++ /dev/null
@@ -1,81 +0,0 @@
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char sccsid[] = "@(#)daemon.c	8.1 (Berkeley) 6/4/93";
-static const char rcsid[] = "$Id: daemon.c,v 1.1.352.1 2005/04/27 05:00:42 sra Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-/*
- * Copyright (c) 1990, 1993
- *	The Regents of the University of California.  All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- *	This product includes software developed by the University of
- *	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-#include "port_before.h"
-
-#include <fcntl.h>
-#include <paths.h>
-#include <unistd.h>
-
-#include "port_after.h"
-
-#ifndef NEED_DAEMON
-int __bind_daemon__;
-#else
-
-int
-daemon(int nochdir, int noclose) {
-	int fd;
-
-	switch (fork()) {
-	case -1:
-		return (-1);
-	case 0:
-		break;
-	default:
-		_exit(0);
-	}
-
-	if (setsid() == -1)
-		return (-1);
-
-	if (!nochdir)
-		(void)chdir("/");
-
-	if (!noclose && (fd = open(_PATH_DEVNULL, O_RDWR, 0)) != -1) {
-		(void)dup2(fd, STDIN_FILENO);
-		(void)dup2(fd, STDOUT_FILENO);
-		(void)dup2(fd, STDERR_FILENO);
-		if (fd > 2)
-			(void)close (fd);
-	}
-	return (0);
-}
-#endif
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/bsd/ftruncate.c b/contrib/bind9/lib/bind/bsd/ftruncate.c
deleted file mode 100644
index b222c8b..0000000
--- a/contrib/bind9/lib/bind/bsd/ftruncate.c
+++ /dev/null
@@ -1,64 +0,0 @@
-#ifndef LINT
-static const char rcsid[] = "$Id: ftruncate.c,v 1.1.352.3 2005/06/22 22:05:45 marka Exp $";
-#endif
-
-/*! \file
- * \brief
- * ftruncate - set file size, BSD Style
- *
- * shortens or enlarges the file as neeeded
- * uses some undocumented locking call. It is known to work on SCO unix,
- * other vendors should try.
- * The #error directive prevents unsupported OSes
- */
-
-#include "port_before.h"
-
-#if defined(M_UNIX)
-#define OWN_FTRUNCATE
-#include <stdio.h>
-#ifdef _XOPEN_SOURCE
-#undef _XOPEN_SOURCE
-#endif
-#ifdef _POSIX_SOURCE
-#undef _POSIX_SOURCE
-#endif
-
-#include <fcntl.h>
-
-#include "port_after.h"
-
-int
-__ftruncate(int fd, long wantsize) {
-	long cursize;
-
-	/* determine current file size */
-	if ((cursize = lseek(fd, 0L, 2)) == -1)
-		return (-1);
-
-	/* maybe lengthen... */
-	if (cursize < wantsize) {
-		if (lseek(fd, wantsize - 1, 0) == -1 ||
-		    write(fd, "", 1) == -1) {
-			return (-1);
-		}
-		return (0);
-	}
-
-	/* maybe shorten... */
-	if (wantsize < cursize) {
-		struct flock fl;
-
-		fl.l_whence = 0;
-		fl.l_len = 0;
-		fl.l_start = wantsize;
-		fl.l_type = F_WRLCK;
-		return (fcntl(fd, F_FREESP, &fl));
-	}
-	return (0);
-}
-#endif
-
-#ifndef OWN_FTRUNCATE
-int __bindcompat_ftruncate;
-#endif
diff --git a/contrib/bind9/lib/bind/bsd/gettimeofday.c b/contrib/bind9/lib/bind/bsd/gettimeofday.c
deleted file mode 100644
index 0c88e00..0000000
--- a/contrib/bind9/lib/bind/bsd/gettimeofday.c
+++ /dev/null
@@ -1,64 +0,0 @@
-#ifndef LINT
-static const char rcsid[] = "$Id: gettimeofday.c,v 1.3.332.1 2005/04/27 05:00:43 sra Exp $";
-#endif
-
-#include "port_before.h"
-#include <stdio.h>
-#include <syslog.h>
-#include <sys/time.h>
-#include "port_after.h"
-
-#if !defined(NEED_GETTIMEOFDAY)
-/*%
- * gettimeofday() occasionally returns invalid tv_usec on some platforms.
- */
-#define MILLION 1000000
-#undef gettimeofday
-
-int
-isc__gettimeofday(struct timeval *tp, struct timezone *tzp) {
-	int res;
-
-	res = gettimeofday(tp, tzp);
-	if (res < 0)
-		return (res);
-	if (tp == NULL)
-		return (res);
-	if (tp->tv_usec < 0) {
-		do {
-			tp->tv_usec += MILLION;
-			tp->tv_sec--;
-		} while (tp->tv_usec < 0);
-		goto log;
-	} else if (tp->tv_usec > MILLION) {
-		do {
-			tp->tv_usec -= MILLION;
-			tp->tv_sec++;
-		} while (tp->tv_usec > MILLION);
-		goto log;
-	}
-	return (res);
- log:
-	syslog(LOG_ERR, "gettimeofday: tv_usec out of range\n");
-	return (res);
-}
-#else
-int
-gettimeofday(struct timeval *tvp, struct _TIMEZONE *tzp) {
-	time_t clock, time(time_t *);
-
-	if (time(&clock) == (time_t) -1)
-		return (-1);
-	if (tvp) {
-		tvp->tv_sec = clock;
-		tvp->tv_usec = 0;
-	}
-	if (tzp) {
-		tzp->tz_minuteswest = 0;
-		tzp->tz_dsttime = 0;
-	}
-	return (0);
-}
-#endif /*NEED_GETTIMEOFDAY*/
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/bsd/mktemp.c b/contrib/bind9/lib/bind/bsd/mktemp.c
deleted file mode 100644
index f201c2d..0000000
--- a/contrib/bind9/lib/bind/bsd/mktemp.c
+++ /dev/null
@@ -1,156 +0,0 @@
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char sccsid[] = "@(#)mktemp.c	8.1 (Berkeley) 6/4/93";
-static const char rcsid[] = "$Id: mktemp.c,v 1.1.352.1 2005/04/27 05:00:43 sra Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-/*
- * Copyright (c) 1987, 1993
- *    The Regents of the University of California.  All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- * 	This product includes software developed by the University of
- * 	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-/*
- * Portions Copyright (c) 1993 by Digital Equipment Corporation.
- * 
- * 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, and that
- * the name of Digital Equipment Corporation not be used in advertising or
- * publicity pertaining to distribution of the document or software without
- * specific, written prior permission.
- * 
- * THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
- * WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
- * OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
- * CORPORATION 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.
- */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/stat.h>
-
-#include <ctype.h>
-#include <errno.h>
-#include <fcntl.h>
-#include <stdio.h>
-
-#include "port_after.h"
-
-#if (!defined(NEED_MKTEMP)) && (!defined(NEED_MKSTEMP))
-int __mktemp_unneeded__;
-#else
-
-static int gettemp(char *path, int *doopen);
-
-#ifdef NEED_MKSTEMP
-mkstemp(char *path) {
-	int fd;
-
-	return (gettemp(path, &fd) ? fd : -1);
-}
-#endif
-
-#ifdef NEED_MKTEMP
-char *
-mktemp(char *path) {
-	return(gettemp(path, (int *)NULL) ? path : (char *)NULL);
-}
-#endif
-
-static int
-gettemp(char *path, int *doopen) {
-	char *start, *trv;
-	struct stat sbuf;
-	u_int pid;
-
-	pid = getpid();
-	for (trv = path; *trv; ++trv);		/*%< extra X's get set to 0's */
-	while (*--trv == 'X') {
-		*trv = (pid % 10) + '0';
-		pid /= 10;
-	}
-
-	/*
-	 * check the target directory; if you have six X's and it
-	 * doesn't exist this runs for a *very* long time.
-	 */
-	for (start = trv + 1;; --trv) {
-		if (trv <= path)
-			break;
-		if (*trv == '/') {
-			*trv = '\0';
-			if (stat(path, &sbuf))
-				return(0);
-			if (!S_ISDIR(sbuf.st_mode)) {
-				errno = ENOTDIR;
-				return(0);
-			}
-			*trv = '/';
-			break;
-		}
-	}
-
-	for (;;) {
-		if (doopen) {
-			if ((*doopen =
-			    open(path, O_CREAT|O_EXCL|O_RDWR, 0600)) >= 0)
-				return(1);
-			if (errno != EEXIST)
-				return(0);
-		}
-		else if (stat(path, &sbuf))
-			return(errno == ENOENT ? 1 : 0);
-
-		/* tricky little algorithm for backward compatibility */
-		for (trv = start;;) {
-			if (!*trv)
-				return(0);
-			if (*trv == 'z')
-				*trv++ = 'a';
-			else {
-				if (isdigit(*trv))
-					*trv = 'a';
-				else
-					++*trv;
-				break;
-			}
-		}
-	}
-	/*NOTREACHED*/
-}
-
-#endif /*NEED_MKTEMP*/
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/bsd/putenv.c b/contrib/bind9/lib/bind/bsd/putenv.c
deleted file mode 100644
index dca02c10..0000000
--- a/contrib/bind9/lib/bind/bsd/putenv.c
+++ /dev/null
@@ -1,27 +0,0 @@
-#ifndef LINT
-static const char rcsid[] = "$Id: putenv.c,v 1.1.352.1 2005/04/27 05:00:43 sra Exp $";
-#endif
-
-#include "port_before.h"
-#include "port_after.h"
-
-/*%
- * To give a little credit to Sun, SGI,
- * and many vendors in the SysV world.
- */
-
-#if !defined(NEED_PUTENV)
-int __bindcompat_putenv;
-#else
-int
-putenv(char *str) {
-	char *tmp;
-
-	for (tmp = str; *tmp && (*tmp != '='); tmp++)
-		;
-
-	return (setenv(str, tmp, 1));
-}
-#endif
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/bsd/readv.c b/contrib/bind9/lib/bind/bsd/readv.c
deleted file mode 100644
index eb13bcc..0000000
--- a/contrib/bind9/lib/bind/bsd/readv.c
+++ /dev/null
@@ -1,39 +0,0 @@
-#ifndef LINT
-static const char rcsid[] = "$Id: readv.c,v 1.1.352.1 2005/04/27 05:00:43 sra Exp $";
-#endif
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/uio.h>
-#include <sys/stat.h>
-#include <sys/socket.h>
-
-#include "port_after.h"
-
-#ifndef NEED_READV
-int __bindcompat_readv;
-#else
-
-int
-__readv(fd, vp, vpcount)
-	int fd;
-	const struct iovec *vp;
-	int vpcount;
-{
-	int count = 0;
-
-	while (vpcount-- > 0) {
-		int bytes = read(fd, vp->iov_base, vp->iov_len);
-
-		if (bytes < 0)
-			return (-1);
-		count += bytes;
-		if (bytes != vp->iov_len)
-			break;
-		vp++;
-	}
-	return (count);
-}
-#endif /* NEED_READV */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/bsd/setenv.c b/contrib/bind9/lib/bind/bsd/setenv.c
deleted file mode 100644
index ce2f063..0000000
--- a/contrib/bind9/lib/bind/bsd/setenv.c
+++ /dev/null
@@ -1,151 +0,0 @@
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char sccsid[] = "@(#)setenv.c	8.1 (Berkeley) 6/4/93";
-static const char rcsid[] = "$Id: setenv.c,v 1.1.352.1 2005/04/27 05:00:44 sra Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-/*
- * Copyright (c) 1987, 1993
- *	The Regents of the University of California.  All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- *	This product includes software developed by the University of
- *	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-#include "port_before.h"
-
-#include <stddef.h>
-#include <stdlib.h>
-#include <string.h>
-
-#include "port_after.h"
-
-#if !defined(NEED_SETENV)
-int __bindcompat_setenv;
-#else
-
-extern char **environ;
-
-static char *findenv(const char *name, int *offset);
-
-/*%
- * setenv --
- *	Set the value of the environmental variable "name" to be
- *	"value".  If rewrite is set, replace any current value.
- */
-setenv(const char *name, const char *value, int rewrite) {
-	extern char **environ;
-	static int alloced;			/*%< if allocated space before */
-	char *c;
-	int l_value, offset;
-
-	if (*value == '=')			/*%< no `=' in value */
-		++value;
-	l_value = strlen(value);
-	if ((c = findenv(name, &offset))) {	/*%< find if already exists */
-		if (!rewrite)
-			return (0);
-		if (strlen(c) >= l_value) {	/*%< old larger; copy over */
-			while (*c++ = *value++);
-			return (0);
-		}
-	} else {					/*%< create new slot */
-		int cnt;
-		char **p;
-
-		for (p = environ, cnt = 0; *p; ++p, ++cnt);
-		if (alloced) {			/*%< just increase size */
-			environ = (char **)realloc((char *)environ,
-			    (size_t)(sizeof(char *) * (cnt + 2)));
-			if (!environ)
-				return (-1);
-		}
-		else {				/*%< get new space */
-			alloced = 1;		/*%< copy old entries into it */
-			p = malloc((size_t)(sizeof(char *) * (cnt + 2)));
-			if (!p)
-				return (-1);
-			memcpy(p, environ, cnt * sizeof(char *));
-			environ = p;
-		}
-		environ[cnt + 1] = NULL;
-		offset = cnt;
-	}
-	for (c = (char *)name; *c && *c != '='; ++c);	/*%< no `=' in name */
-	if (!(environ[offset] =			/*%< name + `=' + value */
-	    malloc((size_t)((int)(c - name) + l_value + 2))))
-		return (-1);
-	for (c = environ[offset]; (*c = *name++) && *c != '='; ++c);
-	for (*c++ = '='; *c++ = *value++;);
-	return (0);
-}
-
-/*%
- * unsetenv(name) --
- *	Delete environmental variable "name".
- */
-void
-unsetenv(const char *name) {
-	char **p;
-	int offset;
-
-	while (findenv(name, &offset))	/*%< if set multiple times */
-		for (p = &environ[offset];; ++p)
-			if (!(*p = *(p + 1)))
-				break;
-}
-
-/*%
- * findenv --
- *	Returns pointer to value associated with name, if any, else NULL.
- *	Sets offset to be the offset of the name/value combination in the
- *	environmental array, for use by setenv(3) and unsetenv(3).
- *	Explicitly removes '=' in argument name.
- *
- *	This routine *should* be a static; don't use it.
- */
-static char *
-findenv(const char *name, int *offset) {
-	const char *np;
-	char **p, *c;
-	int len;
-
-	if (name == NULL || environ == NULL)
-		return (NULL);
-	for (np = name; *np && *np != '='; ++np)
-		continue;
-	len = np - name;
-	for (p = environ; (c = *p) != NULL; ++p)
-		if (strncmp(c, name, len) == 0 && c[len] == '=') {
-			*offset = p - environ;
-			return (c + len + 1);
-		}
-	return (NULL);
-}
-#endif
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/bsd/setitimer.c b/contrib/bind9/lib/bind/bsd/setitimer.c
deleted file mode 100644
index 2d5a4e4..0000000
--- a/contrib/bind9/lib/bind/bsd/setitimer.c
+++ /dev/null
@@ -1,29 +0,0 @@
-#ifndef LINT
-static const char rcsid[] = "$Id: setitimer.c,v 1.1.352.1 2005/04/27 05:00:44 sra Exp $";
-#endif
-
-#include "port_before.h"
-
-#include <sys/time.h>
-
-#include "port_after.h"
-
-/*%
- * Setitimer emulation routine.
- */
-#ifndef NEED_SETITIMER
-int __bindcompat_setitimer;
-#else
-
-int
-__setitimer(int which, const struct itimerval *value,
-	    struct itimerval *ovalue)
-{
-	if (alarm(value->it_value.tv_sec) >= 0)
-		return (0);
-	else
-		return (-1);
-}
-#endif
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/bsd/strcasecmp.c b/contrib/bind9/lib/bind/bsd/strcasecmp.c
deleted file mode 100644
index fd76837..0000000
--- a/contrib/bind9/lib/bind/bsd/strcasecmp.c
+++ /dev/null
@@ -1,124 +0,0 @@
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char sccsid[] = "@(#)strcasecmp.c	8.1 (Berkeley) 6/4/93";
-static const char rcsid[] = "$Id: strcasecmp.c,v 1.1.352.1 2005/04/27 05:00:45 sra Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-/*
- * Copyright (c) 1987, 1993
- *    The Regents of the University of California.  All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- * 	This product includes software developed by the University of
- * 	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-#include "port_before.h"
-
-#include <sys/param.h>
-#include <sys/types.h>
-#include <sys/cdefs.h>
-
-#include <string.h>
-
-#include "port_after.h"
-
-#ifndef NEED_STRCASECMP
-int __strcasecmp_unneeded__;
-#else
-
-/*%
- * This array is designed for mapping upper and lower case letter
- * together for a case independent comparison.  The mappings are
- * based upon ascii character sequences.
- */
-static const u_char charmap[] = {
-	0000, 0001, 0002, 0003, 0004, 0005, 0006, 0007,
-	0010, 0011, 0012, 0013, 0014, 0015, 0016, 0017,
-	0020, 0021, 0022, 0023, 0024, 0025, 0026, 0027,
-	0030, 0031, 0032, 0033, 0034, 0035, 0036, 0037,
-	0040, 0041, 0042, 0043, 0044, 0045, 0046, 0047,
-	0050, 0051, 0052, 0053, 0054, 0055, 0056, 0057,
-	0060, 0061, 0062, 0063, 0064, 0065, 0066, 0067,
-	0070, 0071, 0072, 0073, 0074, 0075, 0076, 0077,
-	0100, 0141, 0142, 0143, 0144, 0145, 0146, 0147,
-	0150, 0151, 0152, 0153, 0154, 0155, 0156, 0157,
-	0160, 0161, 0162, 0163, 0164, 0165, 0166, 0167,
-	0170, 0171, 0172, 0133, 0134, 0135, 0136, 0137,
-	0140, 0141, 0142, 0143, 0144, 0145, 0146, 0147,
-	0150, 0151, 0152, 0153, 0154, 0155, 0156, 0157,
-	0160, 0161, 0162, 0163, 0164, 0165, 0166, 0167,
-	0170, 0171, 0172, 0173, 0174, 0175, 0176, 0177,
-	0200, 0201, 0202, 0203, 0204, 0205, 0206, 0207,
-	0210, 0211, 0212, 0213, 0214, 0215, 0216, 0217,
-	0220, 0221, 0222, 0223, 0224, 0225, 0226, 0227,
-	0230, 0231, 0232, 0233, 0234, 0235, 0236, 0237,
-	0240, 0241, 0242, 0243, 0244, 0245, 0246, 0247,
-	0250, 0251, 0252, 0253, 0254, 0255, 0256, 0257,
-	0260, 0261, 0262, 0263, 0264, 0265, 0266, 0267,
-	0270, 0271, 0272, 0273, 0274, 0275, 0276, 0277,
-	0300, 0301, 0302, 0303, 0304, 0305, 0306, 0307,
-	0310, 0311, 0312, 0313, 0314, 0315, 0316, 0317,
-	0320, 0321, 0322, 0323, 0324, 0325, 0326, 0327,
-	0330, 0331, 0332, 0333, 0334, 0335, 0336, 0337,
-	0340, 0341, 0342, 0343, 0344, 0345, 0346, 0347,
-	0350, 0351, 0352, 0353, 0354, 0355, 0356, 0357,
-	0360, 0361, 0362, 0363, 0364, 0365, 0366, 0367,
-	0370, 0371, 0372, 0373, 0374, 0375, 0376, 0377
-};
-
-int
-strcasecmp(const char *s1, const char *s2) {
-	const u_char *cm = charmap,
-		     *us1 = (const u_char *)s1,
-		     *us2 = (const u_char *)s2;
-
-	while (cm[*us1] == cm[*us2++])
-		if (*us1++ == '\0')
-			return (0);
-	return (cm[*us1] - cm[*--us2]);
-}
-
-int
-strncasecmp(const char *s1, const char *s2, size_t n) {
-	if (n != 0) {
-		const u_char *cm = charmap,
-			     *us1 = (const u_char *)s1,
-			     *us2 = (const u_char *)s2;
-
-		do {
-			if (cm[*us1] != cm[*us2++])
-				return (cm[*us1] - cm[*--us2]);
-			if (*us1++ == '\0')
-				break;
-		} while (--n != 0);
-	}
-	return (0);
-}
-
-#endif /*NEED_STRCASECMP*/
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/bsd/strdup.c b/contrib/bind9/lib/bind/bsd/strdup.c
deleted file mode 100644
index a8d31e9..0000000
--- a/contrib/bind9/lib/bind/bsd/strdup.c
+++ /dev/null
@@ -1,20 +0,0 @@
-#include "port_before.h"
-
-#include <stdlib.h>
-
-#include "port_after.h"
-
-#ifndef NEED_STRDUP
-int __bind_strdup_unneeded;
-#else
-char *
-strdup(const char *src) {
-	char *dst = malloc(strlen(src) + 1);
-
-	if (dst)
-		strcpy(dst, src);
-	return (dst);
-}
-#endif
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/bsd/strerror.c b/contrib/bind9/lib/bind/bsd/strerror.c
deleted file mode 100644
index 325cd52..0000000
--- a/contrib/bind9/lib/bind/bsd/strerror.c
+++ /dev/null
@@ -1,94 +0,0 @@
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char sccsid[] = "@(#)strerror.c	8.1 (Berkeley) 6/4/93";
-static const char rcsid[] = "$Id: strerror.c,v 1.4.332.2 2008/02/18 04:04:06 marka Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-/*
- * Copyright (c) 1988, 1993
- *    The Regents of the University of California.  All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- * 	This product includes software developed by the University of
- * 	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-#include "port_before.h"
-
-#include <sys/param.h>
-#include <sys/types.h>
-
-#include <string.h>
-
-#include "port_after.h"
-
-#ifndef NEED_STRERROR
-int __strerror_unneeded__;
-#else
-
-#ifdef USE_SYSERROR_LIST
-extern int sys_nerr;
-extern char *sys_errlist[];
-#endif
-
-const char *
-isc_strerror(int num) {
-#define	UPREFIX	"Unknown error: "
-	static char ebuf[40] = UPREFIX;		/*%< 64-bit number + slop */
-	u_int errnum;
-	char *p, *t;
-#ifndef USE_SYSERROR_LIST
-	const char *ret;
-#endif
-	char tmp[40];
-
-	errnum = num;				/*%< convert to unsigned */
-#ifdef USE_SYSERROR_LIST
-	if (errnum < (u_int)sys_nerr)
-		return (sys_errlist[errnum]);
-#else
-#undef strerror
-	ret = strerror(num);			/*%< call strerror() in libc */
-	if (ret != NULL)
-		return(ret);
-#endif
-
-	/* Do this by hand, so we don't include stdio(3). */
-	t = tmp;
-	do {
-		*t++ = "0123456789"[errnum % 10];
-	} while (errnum /= 10);
-	for (p = ebuf + sizeof(UPREFIX) - 1;;) {
-		*p++ = *--t;
-		if (t <= tmp)
-			break;
-	}
-	return (ebuf);
-}
-
-#endif /*NEED_STRERROR*/
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/bsd/strpbrk.c b/contrib/bind9/lib/bind/bsd/strpbrk.c
deleted file mode 100644
index 4502572..0000000
--- a/contrib/bind9/lib/bind/bsd/strpbrk.c
+++ /dev/null
@@ -1,70 +0,0 @@
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char sccsid[] = "@(#)strpbrk.c	8.1 (Berkeley) 6/4/93";
-static const char rcsid[] = "$Id: strpbrk.c,v 1.1.352.1 2005/04/27 05:00:46 sra Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-/*
- * Copyright (c) 1985, 1993
- *    The Regents of the University of California.  All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- * 	This product includes software developed by the University of
- * 	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-#include "port_before.h"
-
-#include <sys/param.h>
-#include <sys/cdefs.h>
-
-#include <string.h>
-
-#include "port_after.h"
-
-#ifndef NEED_STRPBRK
-int __strpbrk_unneeded__;
-#else
-
-/*%
- * Find the first occurrence in s1 of a character in s2 (excluding NUL).
- */
-char *
-strpbrk(const char *s1, const char *s2) {
-	const char *scanp;
-	int c, sc;
-
-	while ((c = *s1++) != 0) {
-		for (scanp = s2; (sc = *scanp++) != 0;)
-			if (sc == c)
-				return ((char *)(s1 - 1));
-	}
-	return (NULL);
-}
-
-#endif /*NEED_STRPBRK*/
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/bsd/strsep.c b/contrib/bind9/lib/bind/bsd/strsep.c
deleted file mode 100644
index 1214f80..0000000
--- a/contrib/bind9/lib/bind/bsd/strsep.c
+++ /dev/null
@@ -1,88 +0,0 @@
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char sccsid[] = "strsep.c	8.1 (Berkeley) 6/4/93";
-static const char rcsid[] = "$Id: strsep.c,v 1.1.352.1 2005/04/27 05:00:47 sra Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-/*
- * Copyright (c) 1990, 1993
- *	The Regents of the University of California.  All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- *	This product includes software developed by the University of
- *	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-#include "port_before.h"
-#include <sys/cdefs.h>
-#include <string.h>
-#include <stdio.h>
-#include "port_after.h"
-
-#ifndef NEED_STRSEP
-int __strsep_unneeded__;
-#else
-
-/*%
- * Get next token from string *stringp, where tokens are possibly-empty
- * strings separated by characters from delim.  
- *
- * Writes NULs into the string at *stringp to end tokens.
- * delim need not remain constant from call to call.
- * On return, *stringp points past the last NUL written (if there might
- * be further tokens), or is NULL (if there are definitely no more tokens).
- *
- * If *stringp is NULL, strsep returns NULL.
- */
-char *
-strsep(char **stringp, const char *delim) {
-	char *s;
-	const char *spanp;
-	int c, sc;
-	char *tok;
-
-	if ((s = *stringp) == NULL)
-		return (NULL);
-	for (tok = s;;) {
-		c = *s++;
-		spanp = delim;
-		do {
-			if ((sc = *spanp++) == c) {
-				if (c == 0)
-					s = NULL;
-				else
-					s[-1] = 0;
-				*stringp = s;
-				return (tok);
-			}
-		} while (sc != 0);
-	}
-	/* NOTREACHED */
-}
-
-#endif /*NEED_STRSEP*/
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/bsd/strtoul.c b/contrib/bind9/lib/bind/bsd/strtoul.c
deleted file mode 100644
index c2efeda..0000000
--- a/contrib/bind9/lib/bind/bsd/strtoul.c
+++ /dev/null
@@ -1,119 +0,0 @@
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char sccsid[] = "@(#)strtoul.c	8.1 (Berkeley) 6/4/93";
-static const char rcsid[] = "$Id: strtoul.c,v 1.2.164.2 2008/02/18 04:04:06 marka Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-/*
- * Copyright (c) 1990, 1993
- *    The Regents of the University of California.  All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- * 	This product includes software developed by the University of
- * 	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/param.h>
-
-#include <ctype.h>
-#include <errno.h>
-#include <limits.h>
-#include <stdlib.h>
-
-#include "port_after.h"
-
-#ifndef NEED_STRTOUL
-int __strtoul_unneeded__;
-#else
-
-/*%
- * Convert a string to an unsigned long integer.
- *
- * Ignores `locale' stuff.  Assumes that the upper and lower case
- * alphabets and digits are each contiguous.
- */
-u_long
-strtoul(const char *nptr, char **endptr, int base) {
-	const char *s = nptr;
-	u_long acc, cutoff;
-	int neg, c, any, cutlim;
-
-	neg = 0;
-
-	/*
-	 * See strtol for comments as to the logic used.
-	 */
-	do {
-		c = *(const unsigned char *)s++;
-	} while (isspace(c));
-	if (c == '-') {
-		neg = 1;
-		c = *s++;
-	} else if (c == '+')
-		c = *s++;
-	if ((base == 0 || base == 16) &&
-	    c == '0' && (*s == 'x' || *s == 'X')) {
-		c = s[1];
-		s += 2;
-		base = 16;
-	}
-	if (base == 0)
-		base = c == '0' ? 8 : 10;
-	cutoff = (u_long)ULONG_MAX / (u_long)base;
-	cutlim = (u_long)ULONG_MAX % (u_long)base;
-	for (acc = 0, any = 0;; c = *(const unsigned char*)s++) {
-		if (isdigit(c))
-			c -= '0';
-		else if (isalpha(c))
-			c -= isupper(c) ? 'A' - 10 : 'a' - 10;
-		else
-			break;
-		if (c >= base)
-			break;
-		if (any < 0 || acc > cutoff || (acc == cutoff && c > cutlim))
-			any = -1;
-		else {
-			any = 1;
-			acc *= base;
-			acc += c;
-		}
-	}
-	if (any < 0) {
-		acc = ULONG_MAX;
-		errno = ERANGE;
-	} else if (neg)
-		acc = -acc;
-	if (endptr != 0)
-		DE_CONST((any ? s - 1 : nptr), *endptr);
-	return (acc);
-}
-
-#endif /*NEED_STRTOUL*/
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/bsd/utimes.c b/contrib/bind9/lib/bind/bsd/utimes.c
deleted file mode 100644
index 2f65cff..0000000
--- a/contrib/bind9/lib/bind/bsd/utimes.c
+++ /dev/null
@@ -1,40 +0,0 @@
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/time.h>
-#include <utime.h>
-
-#include "port_after.h"
-
-#ifndef NEED_UTIMES
-int __bind_utimes_unneeded;
-#else
-
-int
-__utimes(char *filename, struct timeval *tvp) {
-	struct utimbuf utb;
-
-	utb.actime = (time_t)tvp[0].tv_sec;
-	utb.modtime = (time_t)tvp[1].tv_sec;
-	return (utime(filename, &utb));
-}
-
-#endif /* NEED_UTIMES */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/bsd/writev.c b/contrib/bind9/lib/bind/bsd/writev.c
deleted file mode 100644
index 0e81c26..0000000
--- a/contrib/bind9/lib/bind/bsd/writev.c
+++ /dev/null
@@ -1,89 +0,0 @@
-#ifndef LINT
-static const char rcsid[] = "$Id: writev.c,v 1.2.164.1 2005/04/27 05:00:47 sra Exp $";
-#endif
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/uio.h>
-#include <sys/stat.h>
-#include <sys/socket.h>
-
-#include "port_after.h"
-
-#ifndef NEED_WRITEV
-int __bindcompat_writev;
-#else
-
-#ifdef _CRAY
-#define OWN_WRITEV
-int
-__writev(int fd, struct iovec *iov, int iovlen)
-{
-	struct stat statbuf;
-
-	if (fstat(fd, &statbuf) < 0)
-		return (-1);
-
-	/*
-	 * Allow for atomic writes to network.
-	 */
-	if (statbuf.st_mode & S_IFSOCK) {
-		struct msghdr   mesg;		
-
-		memset(&mesg, 0, sizeof(mesg));
-		mesg.msg_name = 0;
-		mesg.msg_namelen = 0;
-		mesg.msg_iov = iov;
-		mesg.msg_iovlen = iovlen;
-		mesg.msg_accrights = 0;
-		mesg.msg_accrightslen = 0;
-		return (sendmsg(fd, &mesg, 0));
-	} else {
-		struct iovec *tv;
-		int i, rcode = 0, count = 0;
-
-		for (i = 0, tv = iov; i <= iovlen; tv++) {
-			rcode = write(fd, tv->iov_base, tv->iov_len);
-
-			if (rcode < 0)
-				break;
-
-			count += rcode;
-		}
-
-		if (count == 0)
-			return (rcode);
-		else
-			return (count);
-	}
-}
-
-#else /*_CRAY*/
-
-int
-__writev(fd, vp, vpcount)
-	int fd;
-	const struct iovec *vp;
-	int vpcount;
-{
-	int count = 0;
-
-	while (vpcount-- > 0) {
-		int written = write(fd, vp->iov_base, vp->iov_len);
-
-		if (written < 0)
-			return (-1);
-		count += written;
-		if (written != vp->iov_len)
-			break;
-		vp++;
-	}
-	return (count);
-}
-
-#endif /*_CRAY*/
-
-#endif /*NEED_WRITEV*/
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/config.h.in b/contrib/bind9/lib/bind/config.h.in
deleted file mode 100644
index 5e2a83d..0000000
--- a/contrib/bind9/lib/bind/config.h.in
+++ /dev/null
@@ -1,68 +0,0 @@
-#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 HAVE_SYS_SELECT_H
-#undef HAVE_MEMORY_H
-#undef SYS_CDEFS_H
-#undef _POSIX_PTHREAD_SEMANTICS
-#undef POSIX_GETPWUID_R
-#undef POSIX_GETPWNAM_R
-#undef POSIX_GETGRGID_R
-#undef POSIX_GETGRNAM_R
-#undef HAVE_MEMMOVE
-#undef HAVE_MEMCHR
-#undef SPRINTF_CHAR
-#undef VSPRINTF_CHAR
-#undef USE_SYSERROR_LIST
-#undef NEED_STRTOUL
-#undef NEED_SUN4PROTOS
-#undef REENABLE_SEND
-
-#undef NEED_SETGROUPENT
-#undef NEED_GETGROUPLIST
-
-/* define if prototype for getgrnam_r() is required */
-#undef NEED_GETGRNAM_R 
-#undef NEED_GETGRGID_R 
-#undef NEED_GETGRENT_R 
-#undef NEED_SETGRENT_R 
-#undef NEED_ENDGRENT_R 
-
-#undef NEED_INNETGR_R
-#undef NEED_SETNETGRENT_R
-#undef NEED_ENDNETGRENT_R
-
-#undef NEED_GETPWNAM_R
-#undef NEED_GETPWUID_R
-#undef NEED_SETPWENT_R
-#undef NEED_SETPASSENT_R
-#undef NEED_SETPWENT_R
-#undef NEED_GETPWENT_R
-#undef NEED_ENDPWENT_R
-
-#undef NEED_SETPASSENT
-
-#undef HAS_PW_CLASS
-
-#undef ssize_t
-#undef uintptr_t
-
-/* Shut up warnings about sputaux in stdio.h on BSD/OS pre-4.1 */ 
-#undef SHUTUP_SPUTAUX
-#ifdef SHUTUP_SPUTAUX
-struct __sFILE;
-extern __inline int __sputaux(int _c, struct __sFILE *_p);
-#endif
-#undef BROKEN_IN6ADDR_INIT_MACROS
-#undef HAVE_STRLCAT
-/* Shut up warnings about missing braces */
-#undef SHUTUP_MUTEX_INITIALIZER
-#ifdef SHUTUP_MUTEX_INITIALIZER
-#define LIBBIND_MUTEX_INITIALIZER { PTHREAD_MUTEX_INITIALIZER }
-#else
-#define LIBBIND_MUTEX_INITIALIZER PTHREAD_MUTEX_INITIALIZER
-#endif
-
diff --git a/contrib/bind9/lib/bind/configure.in b/contrib/bind9/lib/bind/configure.in
deleted file mode 100644
index 9b9b53b..0000000
--- a/contrib/bind9/lib/bind/configure.in
+++ /dev/null
@@ -1,2872 +0,0 @@
-# Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
-# Copyright (C) 2001, 2003  Internet Software Consortium.
-#
-# Permission to use, copy, modify, and/or 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.
-
-AC_REVISION($Revision: 1.90.18.43 $)
-
-AC_INIT(resolv/herror.c)
-AC_PREREQ(2.13)
-
-AC_CONFIG_HEADER(config.h)
-
-AC_CANONICAL_HOST
-
-AC_PROG_MAKE_SET
-AC_PROG_RANLIB
-AC_PROG_INSTALL
-
-AC_SUBST(STD_CINCLUDES)
-AC_SUBST(STD_CDEFINES)
-AC_SUBST(STD_CWARNINGS)
-AC_SUBST(CCOPT)
-
-AC_PATH_PROG(AR, ar)
-ARFLAGS="cruv"
-AC_SUBST(AR)
-AC_SUBST(ARFLAGS)
-
-# The POSIX ln(1) program.  Non-POSIX systems may substitute
-# "copy" or something.
-LN=ln
-AC_SUBST(LN)
-
-case "$AR" in
-	"")
-		AC_MSG_ERROR([
-ar program not found.  Please fix your PATH to include the directory in
-which ar resides, or set AR in the environment with the full path to ar.
-])
-
-		;;
-esac
-
-#
-# Etags.
-#
-AC_PATH_PROGS(ETAGS, etags emacs-etags)
-
-#
-# Some systems, e.g. RH7, have the Exuberant Ctags etags instead of
-# GNU emacs etags, and it requires the -L flag.
-#
-if test "X$ETAGS" != "X"; then
-	AC_MSG_CHECKING(for Exuberant Ctags etags)
-	if $ETAGS --version 2>&1 | grep 'Exuberant Ctags' >/dev/null 2>&1; then
-		AC_MSG_RESULT(yes)
-		ETAGS="$ETAGS -L"
-	else
-		AC_MSG_RESULT(no)
-	fi
-fi
-AC_SUBST(ETAGS)
-
-#
-# Perl is optional; it is used only by some of the system test scripts.
-#
-AC_PATH_PROGS(PERL, perl5 perl)
-AC_SUBST(PERL)
-
-#
-# isc/list.h and others clash with the rest of BIND 9
-#
-case "$includedir" in
-	'${prefix}/include')
-		includedir='${prefix}/bind/include'
-		;;
-esac
-case "$libdir" in
-	'${prefix}/lib')
-		libdir='${prefix}/bind/lib'
-		;;
-esac
-
-#
-# Make sure INSTALL uses an absolute path, else it will be wrong in all
-# Makefiles, since they use make/rules.in and INSTALL will be adjusted by
-# configure based on the location of the file where it is substituted.
-# Since in BIND9 INSTALL is only substituted into make/rules.in, an immediate
-# subdirectory of install-sh, This relative path will be wrong for all
-# directories more than one level down from install-sh.
-#
-case "$INSTALL" in
-	/*)
-                ;;
-        *)
-                #
-                # Not all systems have dirname.
-                #
-                changequote({, })
-                ac_dir="`echo $INSTALL | sed 's%/[^/]*$%%'`"
-                changequote([, ])
-
-                ac_prog="`echo $INSTALL | sed 's%.*/%%'`"
-                test "$ac_dir" = "$ac_prog" && ac_dir=.
-                test -d "$ac_dir" && ac_dir="`(cd \"$ac_dir\" && pwd)`"
-                INSTALL="$ac_dir/$ac_prog"
-                ;;
-esac
-
-#
-# On these hosts, we really want to use cc, not gcc, even if it is
-# found.  The gcc that these systems have will not correctly handle
-# pthreads.
-#
-# However, if the user sets $CC to be something, let that override
-# our change.
-#
-if test "X$CC" = "X" ; then
-	case "$host" in
-		*-dec-osf*)
-			CC="cc"
-			;;
-		*-solaris*)
-                        # Use Sun's cc if it is available, but watch
-                        # out for /usr/ucb/cc; it will never be the right
-                        # compiler to use.
-                        #
-                        # If setting CC here fails, the AC_PROG_CC done
-                        # below might still find gcc.
-			IFS="${IFS=	}"; ac_save_ifs="$IFS"; IFS=":"
-			for ac_dir in $PATH; do
-				test -z "$ac_dir" && ac_dir=.
-				case "$ac_dir" in
-				/usr/ucb)
-					# exclude
-					;;
-				*)
-					if test -f "$ac_dir/cc"; then
-						CC="$ac_dir/cc"
-						break
-					fi
-					;;
-				esac
-			done
-			IFS="$ac_save_ifs"
-			;;
-		*-hp-hpux*)
-			CC="cc"
-			;;
-		mips-sgi-irix*)
-			CC="cc"
-			;;
-	esac
-fi
-
-
-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 stropts.h memory.h)
-
-AC_C_CONST
-AC_C_INLINE
-AC_TYPE_SIZE_T
-AC_CHECK_TYPE(ssize_t,signed)
-AC_CHECK_TYPE(uintptr_t,unsigned long)
-AC_HEADER_TIME
-#
-# check if we need to #include sys/select.h explicitly
-#
-case $ac_cv_header_unistd_h in
-yes)
-AC_MSG_CHECKING(if unistd.h defines fd_set)
-AC_TRY_COMPILE([
-#include <unistd.h>],
-[fd_set read_set; return (0);],
-	[AC_MSG_RESULT(yes)
-	 ISC_PLATFORM_NEEDSYSSELECTH="#undef ISC_PLATFORM_NEEDSYSSELECTH"
-	 ],
-	[AC_MSG_RESULT(no)
-	case ac_cv_header_sys_select_h in
-	yes)
-         ISC_PLATFORM_NEEDSYSSELECTH="#define ISC_PLATFORM_NEEDSYSSELECTH 1"
-		;;
-	no)
-		AC_MSG_ERROR([need either working unistd.h or sys/select.h])
-		;;
-	esac
-	])
-	;;
-no)
-	case ac_cv_header_sys_select_h in
-	yes)
-             ISC_PLATFORM_NEEDSYSSELECTH="#define ISC_PLATFORM_NEEDSYSSELECTH 1"
-		;;
-	no)
-		AC_MSG_ERROR([need either unistd.h or sys/select.h])
-		;;
-	esac
-	;;
-esac
-AC_SUBST(ISC_PLATFORM_NEEDSYSSELECTH)
-
-#
-# Find the machine's endian flavor.
-#
-AC_C_BIGENDIAN
-
-AC_ARG_WITH(irs-gr,[ --with-irs-gr		Build ....],
-want_irs_gr="$withval", want_irs_gr="no")
-case "$want_irs_gr" in
-yes) WANT_IRS_GR="#define WANT_IRS_GR 1"
-     WANT_IRS_GR_OBJS="\${WANT_IRS_GR_OBJS}"
-	;;
-*) WANT_IRS_GR="#undef WANT_IRS_GR" WANT_IRS_GR_OBJS="";;
-esac
-AC_SUBST(WANT_IRS_GR)
-AC_SUBST(WANT_IRS_GR_OBJS)
-
-AC_ARG_WITH(irs-pw,[ --with-irs-pw		Build ....],
-want_irs_pw="$withval", want_irs_pw="no")
-case "$want_irs_pw" in
-yes) WANT_IRS_PW="#define WANT_IRS_PW 1"
-     WANT_IRS_PW_OBJS="\${WANT_IRS_PW_OBJS}";;
-*) WANT_IRS_PW="#undef WANT_IRS_PW" WANT_IRS_PW_OBJS="";;
-esac
-AC_SUBST(WANT_IRS_PW)
-AC_SUBST(WANT_IRS_PW_OBJS)
-
-AC_ARG_WITH(irs-nis,[ --with-irs-nis		Build ....],
-want_irs_nis="$withval", want_irs_nis="no")
-case "$want_irs_nis" in
-yes)
-	WANT_IRS_NIS="#define WANT_IRS_NIS 1"
-	WANT_IRS_NIS_OBJS="\${WANT_IRS_NIS_OBJS}"
-	case "$want_irs_gr" in
-	yes)
-		WANT_IRS_NISGR_OBJS="\${WANT_IRS_NISGR_OBJS}";;
-	*)
-		WANT_IRS_NISGR_OBJS="";;
-	esac
-	case "$want_irs_pw" in
-	yes)
-		WANT_IRS_NISPW_OBJS="\${WANT_IRS_NISPW_OBJS}";;
-	*)
-		WANT_IRS_NISPW_OBJS="";;
-	esac
-	;;
-*)
-	WANT_IRS_NIS="#undef WANT_IRS_NIS"
-	WANT_IRS_NIS_OBJS=""
-	WANT_IRS_NISGR_OBJS=""
-	WANT_IRS_NISPW_OBJS="";;
-esac
-AC_SUBST(WANT_IRS_NIS)
-AC_SUBST(WANT_IRS_NIS_OBJS)
-AC_SUBST(WANT_IRS_NISGR_OBJS)
-AC_SUBST(WANT_IRS_NISPW_OBJS)
-AC_TRY_RUN([
-#ifdef HAVE_DB_H
-int have_db_h = 1;
-#else
-int have_db_h = 0;
-#endif
-main() { return(!have_db_h); }
-],
-WANT_IRS_DBPW_OBJS="\${WANT_IRS_DBPW_OBJS}"
-,
-WANT_IRS_DBPW_OBJS=""
-,
-WANT_IRS_DBPW_OBJS=""
-)
-AC_SUBST(WANT_IRS_DBPW_OBJS)
-
-#
-# was --with-randomdev specified?
-#
-AC_MSG_CHECKING(for random device)
-AC_ARG_WITH(randomdev,
-[  --with-randomdev=PATH Specify path for random device],
-    use_randomdev="$withval", use_randomdev="unspec")
-
-case "$use_randomdev" in
-	unspec)
-		case "$host" in
-			*-openbsd*)
-				devrandom=/dev/srandom
-				;;
-			*)
-				devrandom=/dev/random
-				;;
-		esac
-		AC_MSG_RESULT($devrandom)
-		AC_CHECK_FILE($devrandom,
-			      AC_DEFINE_UNQUOTED(PATH_RANDOMDEV,
-						 "$devrandom"),)
-		;;
-	yes)
-		AC_MSG_ERROR([--with-randomdev must specify a path])
-		;;
-	*)
-		AC_DEFINE_UNQUOTED(PATH_RANDOMDEV, "$use_randomdev")
-		AC_MSG_RESULT(using "$use_randomdev")
-		;;
-esac
-
-sinclude(../../config.threads.in)dnl
-
-if $use_threads
-then
-	if test "X$GCC" = "Xyes"; then
-		case "$host" in
-		*-freebsd*)
-			CC="$CC -pthread"
-			CCOPT="$CCOPT -pthread"
-			STD_CDEFINES="$STD_CDEFINES -D_THREAD_SAFE"
-			;;
-		*-openbsd*)
-			CC="$CC -pthread"
-			CCOPT="$CCOPT -pthread"
-			;;
-		*-solaris*)
-			LIBS="$LIBS -lthread"
-			;;
-		*-ibm-aix*)
-			STD_CDEFINES="$STD_CDEFINES -D_THREAD_SAFE"
-			;;
-		esac
-	else
-		case $host in
-		*-dec-osf*)
-			CC="$CC -pthread"
-			CCOPT="$CCOPT -pthread"
-			;;
-		*-solaris*)
-			CC="$CC -mt"
-			CCOPT="$CCOPT -mt"
-			;;
-		*-ibm-aix*)
-			STD_CDEFINES="$STD_CDEFINES -D_THREAD_SAFE"
-			;;
-		*-UnixWare*)
-			CC="$CC -Kthread"
-			CCOPT="$CCOPT -Kthread"
-			;;
-		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}"
-	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
-
-	#
-	# We'd like to use sigwait() too
-	#
-	AC_CHECK_FUNC(sigwait,
-		      AC_DEFINE(HAVE_SIGWAIT),
-		      AC_CHECK_LIB(c, sigwait,
-		      AC_DEFINE(HAVE_SIGWAIT),
-		      AC_CHECK_LIB(pthread, sigwait,
-				   AC_DEFINE(HAVE_SIGWAIT),
-				   AC_CHECK_LIB(pthread, _Psigwait,
-					        AC_DEFINE(HAVE_SIGWAIT),))))
-
-	AC_CHECK_FUNC(pthread_attr_getstacksize,
-		      AC_DEFINE(HAVE_PTHREAD_ATTR_GETSTACKSIZE),)
-
-	#
-	# Additional OS-specific issues related to pthreads and sigwait.
-	#
-	case "$host" in
-		#
-		# One more place to look for sigwait.
-		#
-		*-freebsd*)
-			AC_CHECK_LIB(c_r, sigwait, AC_DEFINE(HAVE_SIGWAIT),)
-			;;
-		#
-		# BSDI 3.0 through 4.0.1 needs pthread_init() to be
-		# called before certain pthreads calls.	 This is deprecated
-		# in BSD/OS 4.1.
-		#
-		*-bsdi3.*|*-bsdi4.0*)
-			AC_DEFINE(NEED_PTHREAD_INIT)
-			;;
-		#
-		# LinuxThreads requires some changes to the way we
-		# deal with signals.
-		#
-		*-linux*)
-			AC_DEFINE(HAVE_LINUXTHREADS)
-			;;
-		#
-		# Ensure the right sigwait() semantics on Solaris and make
-		# sure we call pthread_setconcurrency.
-		#
-		*-solaris*)
-			AC_DEFINE(_POSIX_PTHREAD_SEMANTICS)
-			AC_CHECK_FUNC(pthread_setconcurrency,
-				      AC_DEFINE(CALL_PTHREAD_SETCONCURRENCY))
-			AC_DEFINE(POSIX_GETPWUID_R)
-			AC_DEFINE(POSIX_GETPWNAM_R)
-			AC_DEFINE(POSIX_GETGRGID_R)
-			AC_DEFINE(POSIX_GETGRNAM_R)
-			;;
-		*hpux11*)
-			AC_DEFINE(NEED_ENDNETGRENT_R)
-			AC_DEFINE(_PTHREADS_DRAFT4)
-			;;
-		#
-		# UnixWare does things its own way.
-		#
-		*-UnixWare*)
-			AC_DEFINE(HAVE_UNIXWARE_SIGWAIT)
-			;;
-	esac
-
-	#
-	# Look for sysconf to allow detection of the number of processors.
-	#
-	AC_CHECK_FUNC(sysconf, AC_DEFINE(HAVE_SYSCONF),)
-
-else
-	ALWAYS_DEFINES=""
-	DO_PTHREADS="#undef DO_PTHREADS"
-	WANT_IRS_THREADSGR_OBJS=""
-	WANT_IRS_THREADSPW_OBJS=""
-	WANT_IRS_THREADS_OBJS=""
-	WANT_THREADS_OBJS=""
-	thread_dir=nothreads
-fi
-
-AC_SUBST(ALWAYS_DEFINES)
-AC_SUBST(DO_PTHREADS)
-AC_SUBST(WANT_IRS_THREADSGR_OBJS)
-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(memmove, AC_DEFINE(HAVE_MEMMOVE))
-AC_CHECK_FUNC(memchr, AC_DEFINE(HAVE_MEMCHR))
-AC_CHECK_FUNC(strtoul, , AC_DEFINE(NEED_STRTOUL))
-
-AC_CHECK_FUNC(if_nametoindex,
-	[USE_IFNAMELINKID="#define USE_IFNAMELINKID 1"],
-	[USE_IFNAMELINKID="#undef USE_IFNAMELINKID"])
-AC_SUBST(USE_IFNAMELINKID)
-
-ISC_THREAD_DIR=$thread_dir
-AC_SUBST(ISC_THREAD_DIR)
-
-AC_CHECK_FUNC(daemon,
-[DAEMON_OBJS="" NEED_DAEMON="#undef NEED_DAEMON"]
-,
-[DAEMON_OBJS="\${DAEMON_OBJS}" NEED_DAEMON="#define NEED_DAEMON 1"]
-)
-AC_SUBST(DAEMON_OBJS)
-AC_SUBST(NEED_DAEMON)
-
-AC_CHECK_FUNC(strsep,
-[STRSEP_OBJS="" NEED_STRSEP="#undef NEED_STRSEP"]
-,
-[STRSEP_OBJS="\${STRSEP_OBJS}" NEED_STRSEP="#define NEED_STRSEP 1"]
-)
-AC_SUBST(STRSEP_OBJS)
-AC_SUBST(NEED_STRSEP)
-
-AC_CHECK_FUNC(strerror, [NEED_STRERROR="#undef NEED_STRERROR"],
-[NEED_STRERROR="#define NEED_STRERROR 1"])
-AC_SUBST(NEED_STRERROR)
-
-if test -n "$NEED_STRERROR"
-then
-	AC_MSG_CHECKING([for extern char * sys_errlist[]])
-	AC_TRY_LINK([ extern int sys_nerr; extern char *sys_errlist[]; ],
-		    [ const char *p = sys_errlist[0]; ],
-		    AC_MSG_RESULT(yes)
-		    AC_DEFINE(USE_SYSERROR_LIST),
-		    AC_MSG_RESULT(no))
-fi
-
-#
-# flockfile is usually provided by pthreads, but we may want to use it
-# even if compiled with --disable-threads.
-#
-AC_CHECK_FUNC(flockfile, AC_DEFINE(HAVE_FLOCKFILE),)
-
-# 
-# Indicate what the final decision was regarding threads.
-#
-AC_MSG_CHECKING(whether to build with threads)
-if $use_threads; then
-	AC_MSG_RESULT(yes)
-else
-	AC_MSG_RESULT(no)
-fi
-
-# 
-# End of pthreads stuff.
-#
-
-#
-# Additional compiler settings.
-#
-MKDEPCC="$CC"
-MKDEPCFLAGS="-M"
-IRIX_DNSSEC_WARNINGS_HACK=""
-
-if test "X$GCC" = "Xyes"; then
-        AC_MSG_CHECKING(if "$CC" supports -fno-strict-aliasing)
-        SAVE_CFLAGS=$CFLAGS
-        CFLAGS=-fno-strict-aliasing
-        AC_TRY_COMPILE(,, [FNOSTRICTALIASING=yes],[FNOSTRICTALIASING=no])
-        CFLAGS=$SAVE_CFLAGS
-        if test "$FNOSTRICTALIASING" = "yes"; then
-                AC_MSG_RESULT(yes)
-		STD_CWARNINGS="$STD_CWARNINGS -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing"
-        else
-                AC_MSG_RESULT(no)
-		STD_CWARNINGS="$STD_CWARNINGS -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith"
-        fi
-else
-	case $host in
-	*-dec-osf*)
-		CC="$CC -std"
-		CCOPT="$CCOPT -std"
-		MKDEPCC="$CC"
-		;;
-	*-hp-hpux*)
-		CC="$CC -Ae -z"
-		# The version of the C compiler that constantly warns about
-                # 'const' as well as alignment issues is unfortunately not
-                # able to be discerned via the version of the operating
-                # system, nor does cc have a version flag.
-		case "`$CC +W 123 2>&1`" in
-		*Unknown?option*)
-			STD_CWARNINGS="+w1"
-			;;
-		*)
-			# Turn off the pointlessly noisy warnings.
-			STD_CWARNINGS="+w1 +W 474,530,2193,2236"
-			;;
-		esac
-		CCOPT="$CCOPT -Ae -z"
-		LIBS="-Wl,+vnocompatwarnings $LIBS"
-MKDEPPROG='cc -Ae -E -Wp,-M >/dev/null 2>&1 | awk '"'"'BEGIN {colon=0; rec="";} { for (i = 0 ; i < NF; i++) { if (colon && a[$i]) continue; if ($i == "\\") continue; if (!colon) { rec =  $i continue; } if ($i == ":") { rec = rec " :" colon = 1 continue; } if (length(rec $i) > 76) { print rec " \\"; rec = "\t" $i; a[$i] = 1; } else { rec = rec " " $i a[$i] = 1; } } } END {print rec}'"'"' >>$TMP'
-		MKDEPPROG='cc -Ae -E -Wp,-M >/dev/null 2>>$TMP'
-		;;
-	*-sgi-irix*)
-		STD_CWARNINGS="-fullwarn -woff 1209"
-		#
-		# Silence more than 250 instances of
-		#   "prototyped function redeclared without prototype"
-		# and 11 instances of
-		#   "variable ... was set but never used"
-		# from lib/dns/sec/openssl.
-		#
-		IRIX_DNSSEC_WARNINGS_HACK="-woff 1692,1552"
-		;;
-	*-solaris*)
-		MKDEPCFLAGS="-xM"
-		;;
-	*-UnixWare*)
-		CC="$CC -w"
-		;;
-	esac
-fi
-
-#
-# _GNU_SOURCE is needed to access the fd_bits field of struct fd_set, which
-# is supposed to be opaque.
-#
-case $host in
-	*linux*)
-		STD_CDEFINES="$STD_CDEFINES -D_GNU_SOURCE"
-		;;
-esac
-
-AC_SUBST(MKDEPCC)
-AC_SUBST(MKDEPCFLAGS)
-AC_SUBST(MKDEPPROG)
-AC_SUBST(IRIX_DNSSEC_WARNINGS_HACK)
-
-#
-# NLS
-#
-AC_CHECK_FUNC(catgets, AC_DEFINE(HAVE_CATGETS),)
-
-#
-# -lxnet buys us one big porting headache...  standards, gotta love 'em.
-#
-# AC_CHECK_LIB(xnet, socket, ,
-#    AC_CHECK_LIB(socket, socket)
-#    AC_CHECK_LIB(nsl, inet_ntoa)
-# )
-#
-# Use this for now, instead:
-#
-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)
-		AC_CHECK_LIB(nsl, inet_ntoa)
-		;;
-esac
-
-#
-# Purify support
-#
-AC_MSG_CHECKING(whether to use purify)
-AC_ARG_WITH(purify,
-	[  --with-purify[=PATH]	use Rational purify],
-	use_purify="$withval", use_purify="no")
-
-case "$use_purify" in
-	no)
-		;;
-	yes)
-		AC_PATH_PROG(purify_path, purify, purify)
-		;;
-	*)
-		purify_path="$use_purify"
-		;;
-esac
-
-case "$use_purify" in
-	no)
-		AC_MSG_RESULT(no)
-		PURIFY=""
-		;;
-	*)
-		if test -f $purify_path || test $purify_path = purify; then
-			AC_MSG_RESULT($purify_path)
-			PURIFYFLAGS="`echo $PURIFYOPTIONS`"
-			PURIFY="$purify_path $PURIFYFLAGS"
-		else
-			AC_MSG_ERROR([$purify_path not found.
-
-Please choose the proper path with the following command:
-
-    configure --with-purify=PATH
-])
-		fi
-		;;
-esac
-
-AC_SUBST(PURIFY)
-
-#
-# GNU libtool support
-#
-case $host in
-sunos*)
-    # Just set the maximum command line length for sunos as it otherwise
-    # takes a exceptionally long time to work it out. Required for libtool.
-    lt_cv_sys_max_cmd_len=4096;
-    ;;
-esac
-
-AC_ARG_WITH(libtool,
-	    [  --with-libtool	use GNU libtool (following indented options supported)],
-	    use_libtool="$withval", use_libtool="no")
-
-case $use_libtool in
-	yes)
-		AM_PROG_LIBTOOL
-		O=lo
-		A=la
-		LIBTOOL_MKDEP_SED='s;\.o;\.lo;'
-		LIBTOOL_MODE_COMPILE='--mode=compile'
-		LIBTOOL_MODE_INSTALL='--mode=install'
-		LIBTOOL_MODE_LINK='--mode=link'
-		;;
-	*)
-		O=o
-		A=a
-		LIBTOOL=
-		AC_SUBST(LIBTOOL)
-		LIBTOOL_MKDEP_SED=
-		LIBTOOL_MODE_COMPILE=
-		LIBTOOL_MODE_INSTALL=
-		LIBTOOL_MODE_LINK=
-		;;
-esac
-
-#
-# File name extension for static archive files, for those few places
-# where they are treated differently from dynamic ones.
-#
-SA=a
-
-AC_SUBST(O)
-AC_SUBST(A)
-AC_SUBST(SA)
-AC_SUBST(LIBTOOL_MKDEP_SED)
-AC_SUBST(LIBTOOL_MODE_COMPILE)
-AC_SUBST(LIBTOOL_MODE_INSTALL)
-AC_SUBST(LIBTOOL_MODE_LINK)
-
-#
-# Here begins a very long section to determine the system's networking
-# capabilities.  The order of the tests is signficant.
-#
-
-#
-# IPv6
-#
-AC_ARG_ENABLE(ipv6,
-	[  --enable-ipv6		use IPv6 [default=autodetect]])
-
-case "$enable_ipv6" in
-	yes|''|autodetect)
-		AC_DEFINE(WANT_IPV6)
-		;;
-	no)
-		;;
-esac
-
-#
-# We do the IPv6 compilation checking after libtool so that we can put
-# the right suffix on the files.
-#
-AC_MSG_CHECKING(for IPv6 structures)
-AC_TRY_COMPILE([
-#include <sys/types.h>
-#include <sys/socket.h>
-#include <netinet/in.h>],
-[struct sockaddr_in6 sin6; return (0);],
-	[AC_MSG_RESULT(yes)
-	 found_ipv6=yes],
-	[AC_MSG_RESULT(no)
-	 found_ipv6=no])
-
-#
-# See whether IPv6 support is provided via a Kame add-on.
-# This is done before other IPv6 linking tests to LIBS is properly set.
-#
-AC_MSG_CHECKING(for Kame IPv6 support)
-AC_ARG_WITH(kame,
-	[  --with-kame[=PATH]	use Kame IPv6 [default path /usr/local/v6]],
-	use_kame="$withval", use_kame="no")
-
-case "$use_kame" in
-	no)
-		;;
-	yes)
-		kame_path=/usr/local/v6
-		;;
-	*)
-		kame_path="$use_kame"
-		;;
-esac
-
-case "$use_kame" in
-	no)
-		AC_MSG_RESULT(no)
-		;;
-	*)
-		if test -f $kame_path/lib/libinet6.a; then
-			AC_MSG_RESULT($kame_path/lib/libinet6.a)
-			LIBS="-L$kame_path/lib -linet6 $LIBS"
-		else
-			AC_MSG_ERROR([$kame_path/lib/libinet6.a not found.
-
-Please choose the proper path with the following command:
-
-    configure --with-kame=PATH
-])
-		fi
-		;;
-esac
-
-#
-# Whether netinet6/in6.h is needed has to be defined in isc/platform.h.
-# Including it on Kame-using platforms is very bad, though, because
-# Kame uses #error against direct inclusion.   So include it on only
-# the platform that is otherwise broken without it -- BSD/OS 4.0 through 4.1.
-# This is done before the in6_pktinfo check because that's what
-# netinet6/in6.h is needed for.
-#
-changequote({, })
-case "$host" in
-*-bsdi4.[01]*)
-	ISC_PLATFORM_NEEDNETINET6IN6H="#define ISC_PLATFORM_NEEDNETINET6IN6H 1"
-	isc_netinet6in6_hack="#include <netinet6/in6.h>"
-	;;
-*)
-	ISC_PLATFORM_NEEDNETINET6IN6H="#undef ISC_PLATFORM_NEEDNETINET6IN6H"
-	isc_netinet6in6_hack=""
-	;;
-esac
-changequote([, ])
-
-#
-# This is similar to the netinet6/in6.h issue.
-#
-case "$host" in
-*-UnixWare*)
-	ISC_PLATFORM_NEEDNETINETIN6H="#define ISC_PLATFORM_NEEDNETINETIN6H 1"
-        ISC_PLATFORM_FIXIN6ISADDR="#define ISC_PLATFORM_FIXIN6ISADDR 1"
-	isc_netinetin6_hack="#include <netinet/in6.h>"
-	;;
-*)
-	ISC_PLATFORM_NEEDNETINETIN6H="#undef ISC_PLATFORM_NEEDNETINETIN6H"
-        ISC_PLATFORM_FIXIN6ISADDR="#undef ISC_PLATFORM_FIXIN6ISADDR"
-	isc_netinetin6_hack=""
-	;;
-esac
-
-#
-# Now delve deeper into the suitability of the IPv6 support.
-#
-case "$found_ipv6" in
-	yes)
-		HAS_INET6_STRUCTS="#define HAS_INET6_STRUCTS 1"
-
-		AC_MSG_CHECKING(for in6_addr)
-		AC_TRY_COMPILE([
-#include <sys/types.h>
-#include <sys/socket.h>
-#include <netinet/in.h>
-$isc_netinetin6_hack
-$isc_netinet6in6_hack
-],
-[struct in6_addr in6; return (0);],
-		[AC_MSG_RESULT(yes)
-		 HAS_IN_ADDR6="#undef HAS_IN_ADDR6"
-		 isc_in_addr6_hack=""],
-		[AC_MSG_RESULT(no)
-		 HAS_IN_ADDR6="#define HAS_IN_ADDR6 1"
-		 isc_in_addr6_hack="#define in6_addr in_addr6"])
-
-		AC_MSG_CHECKING(for in6addr_any)
-		AC_TRY_LINK([
-#include <sys/types.h>
-#include <sys/socket.h>
-#include <netinet/in.h>
-$isc_netinetin6_hack
-$isc_netinet6in6_hack
-$isc_in_addr6_hack
-],
-		[struct in6_addr in6; in6 = in6addr_any; return (0);],
-			[AC_MSG_RESULT(yes)
-			 NEED_IN6ADDR_ANY="#undef NEED_IN6ADDR_ANY"],
-			[AC_MSG_RESULT(no)
-			 NEED_IN6ADDR_ANY="#define NEED_IN6ADDR_ANY 1"])
-
-		AC_MSG_CHECKING(for sin6_scope_id in struct sockaddr_in6)
-		AC_TRY_COMPILE([
-#include <sys/types.h>
-#include <sys/socket.h>
-#include <netinet/in.h>
-$isc_netinetin6_hack
-$isc_netinet6in6_hack
-],
-		[struct sockaddr_in6 xyzzy; xyzzy.sin6_scope_id = 0; return (0);],
-			[AC_MSG_RESULT(yes)
-			 result="#define HAVE_SIN6_SCOPE_ID 1"],
-			[AC_MSG_RESULT(no)
-			 result="#undef HAVE_SIN6_SCOPE_ID"])
-		HAVE_SIN6_SCOPE_ID="$result"
-
-		AC_MSG_CHECKING(for in6_pktinfo)
-		AC_TRY_COMPILE([
-#include <sys/types.h>
-#include <sys/socket.h>
-#include <netinet/in.h>
-$isc_netinetin6_hack
-$isc_netinet6in6_hack
-],
-		[struct in6_pktinfo xyzzy; return (0);],
-			[AC_MSG_RESULT(yes)
-			 ISC_PLATFORM_HAVEIN6PKTINFO="#define ISC_PLATFORM_HAVEIN6PKTINFO 1"],
-			[AC_MSG_RESULT(no -- disabling runtime ipv6 support)
-			 ISC_PLATFORM_HAVEIN6PKTINFO="#undef ISC_PLATFORM_HAVEIN6PKTINFO"])
-		;;
-	no)
-		HAS_INET6_STRUCTS="#undef HAS_INET6_STRUCTS"
-		NEED_IN6ADDR_ANY="#undef NEED_IN6ADDR_ANY"
-		ISC_PLATFORM_HAVEIN6PKTINFO="#undef ISC_PLATFORM_HAVEIN6PKTINFO"
-		HAVE_SIN6_SCOPE_ID="#define HAVE_SIN6_SCOPE_ID 1"
-		ISC_IPV6_H="ipv6.h"
-		ISC_IPV6_O="ipv6.$O"
-		ISC_ISCIPV6_O="unix/ipv6.$O"
-		ISC_IPV6_C="ipv6.c"
-		;;
-esac
-
-AC_MSG_CHECKING(for sockaddr_storage)
-AC_TRY_COMPILE([
-#include <sys/types.h>
-#include <sys/socket.h>
-#include <netinet/in.h>
-],
-[struct sockaddr_storage xyzzy; return (0);],
-	[AC_MSG_RESULT(yes)
-	 HAVE_SOCKADDR_STORAGE="#define HAVE_SOCKADDR_STORAGE 1"],
-	[AC_MSG_RESULT(no)
-	 HAVE_SOCKADDR_STORAGE="#undef HAVE_SOCKADDR_STORAGE"])
-
-AC_SUBST(HAS_INET6_STRUCTS)
-AC_SUBST(ISC_PLATFORM_NEEDNETINETIN6H)
-AC_SUBST(ISC_PLATFORM_NEEDNETINET6IN6H)
-AC_SUBST(HAS_IN_ADDR6)
-AC_SUBST(NEED_IN6ADDR_ANY)
-AC_SUBST(ISC_PLATFORM_HAVEIN6PKTINFO)
-AC_SUBST(ISC_PLATFORM_FIXIN6ISADDR)
-AC_SUBST(ISC_IPV6_H)
-AC_SUBST(ISC_IPV6_O)
-AC_SUBST(ISC_ISCIPV6_O)
-AC_SUBST(ISC_IPV6_C)
-AC_SUBST(HAVE_SIN6_SCOPE_ID)
-AC_SUBST(HAVE_SOCKADDR_STORAGE)
-
-#
-# Check for network functions that are often missing.  We do this
-# after the libtool checking, so we can put the right suffix on
-# the files.  It also needs to come after checking for a Kame add-on,
-# which provides some (all?) of the desired functions.
-#
-AC_MSG_CHECKING([for inet_ntop])
-AC_TRY_LINK([
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <arpa/inet.h>],
-        [inet_ntop(0, 0, 0, 0); return (0);],
-        [AC_MSG_RESULT(yes)
-        ISC_PLATFORM_NEEDNTOP="#undef ISC_PLATFORM_NEEDNTOP"],
-
-        [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_CHECKING([for inet_pton])
-AC_TRY_LINK([
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <arpa/inet.h>],
-        [inet_pton(0, 0, 0); return (0);],
-        [AC_MSG_RESULT(yes)
-        ISC_PLATFORM_NEEDPTON="#undef ISC_PLATFORM_NEEDPTON"],
-
-        [AC_MSG_RESULT(no)
-        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_CHECKING([for inet_aton])
-AC_TRY_LINK([
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <arpa/inet.h>],
-        [struct in_addr in; inet_aton(0, &in); return (0);],
-        [AC_MSG_RESULT(yes)
-        ISC_PLATFORM_NEEDATON="#undef ISC_PLATFORM_NEEDATON"],
-
-        [AC_MSG_RESULT(no)
-        ISC_EXTRA_OBJS="$ISC_EXTRA_OBJS inet_aton.$O"
-        ISC_EXTRA_SRCS="$ISC_EXTRA_SRCS inet_aton.c"
-        ISC_PLATFORM_NEEDATON="#define ISC_PLATFORM_NEEDATON 1"])
-
-AC_SUBST(ISC_PLATFORM_NEEDNTOP)
-AC_SUBST(ISC_PLATFORM_NEEDPTON)
-AC_SUBST(ISC_PLATFORM_NEEDATON)
-
-#
-# Look for a 4.4BSD-style sa_len member in struct sockaddr.
-#
-case "$host" in
-	*-dec-osf*)
-		# Tru64 broke send() by defining it to send_OBSOLETE
-		AC_DEFINE(REENABLE_SEND)
-		# Turn on 4.4BSD style sa_len support.
-		AC_DEFINE(_SOCKADDR_LEN)
-		;;
-esac
-
-AC_MSG_CHECKING(for sa_len in struct sockaddr)
-AC_TRY_COMPILE([
-#include <sys/types.h>
-#include <sys/socket.h>],
-[struct sockaddr sa; sa.sa_len = 0; return (0);],
-	[AC_MSG_RESULT(yes)
-	HAVE_SA_LEN="#define HAVE_SA_LEN 1"],
-	[AC_MSG_RESULT(no)
-	HAVE_SA_LEN="#undef HAVE_SA_LEN"])
-AC_SUBST(HAVE_SA_LEN)
-
-# HAVE_MINIMUM_IFREQ
-
-case "$host" in
-	*-bsdi[2345]*)	have_minimum_ifreq=yes;;
-	*-darwin*)	have_minimum_ifreq=yes;;
-	*-freebsd*)	have_minimum_ifreq=yes;;
-	*-lynxos*)	have_minimum_ifreq=yes;;
-	*-netbsd*)	have_minimum_ifreq=yes;;
-	*-next*)	have_minimum_ifreq=yes;;
-	*-openbsd*)	have_minimum_ifreq=yes;;
-	*-rhapsody*)	have_minimum_ifreq=yes;;
-esac
-
-case "$have_minimum_ifreq" in
-	yes)
-		HAVE_MINIMUM_IFREQ="#define HAVE_MINIMUM_IFREQ 1";;
-	no)
-		HAVE_MINIMUM_IFREQ="#undef HAVE_MINIMUM_IFREQ";;
-	*)
-		HAVE_MINIMUM_IFREQ="#undef HAVE_MINIMUM_IFREQ";;
-esac
-AC_SUBST(HAVE_MINIMUM_IFREQ)
-
-# PORT_DIR
-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";;
-	*aix5*)		PORT_DIR="port/aix5";;
-	*aux3*)		PORT_DIR="port/aux3";;
-	*-bsdi2*)	PORT_DIR="port/bsdos2";;
-	*-bsdi*)	PORT_DIR="port/bsdos";;
-	*-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";;
-	*-hpux9*)	PORT_DIR="port/hpux9";;
-	*-hpux10*)	PORT_DIR="port/hpux10";;
-	*-hpux11*)	PORT_DIR="port/hpux";;
-	*-irix*)	PORT_DIR="port/irix";;
-	*-linux*)	PORT_DIR="port/linux";;
-	*-lynxos*)	PORT_DIR="port/lynxos";;
-	*-mpe*)		PORT_DIR="port/mpe";;
-	*-netbsd*)	PORT_DIR="port/netbsd";;
-	*-next*)	PORT_DIR="port/next";;
-	*-openbsd*)	PORT_DIR="port/openbsd";;
-	*-qnx*)		PORT_DIR="port/qnx";;
-	*-rhapsody*)	PORT_DIR="port/rhapsody";;
-	*-sunos4*)
-			AC_DEFINE(NEED_SUN4PROTOS)
-			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)
-			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
-#
-AC_MSG_CHECKING(for struct msghdr flavor)
-AC_TRY_COMPILE([
-#include <sys/types.h>
-#include <sys/socket.h>],
-[struct msghdr msg; msg.msg_flags = 0; return (0);],
-	[AC_MSG_RESULT(4.4BSD)
-	ISC_PLATFORM_MSGHDRFLAVOR="#define ISC_NET_BSD44MSGHDR 1"],
-	[AC_MSG_RESULT(4.3BSD)
-	ISC_PLATFORM_MSGHDRFLAVOR="#define ISC_NET_BSD43MSGHDR 1"])
-AC_SUBST(ISC_PLATFORM_MSGHDRFLAVOR)
-
-#
-# Look for in_port_t.
-#
-AC_MSG_CHECKING(for type in_port_t)
-AC_TRY_COMPILE([
-#include <sys/types.h>
-#include <netinet/in.h>],
-[in_port_t port = 25; return (0);],
-	[AC_MSG_RESULT(yes)
-	ISC_PLATFORM_NEEDPORTT="#undef ISC_PLATFORM_NEEDPORTT"],
-        [AC_MSG_RESULT(no)
-	ISC_PLATFORM_NEEDPORTT="#define ISC_PLATFORM_NEEDPORTT 1"])
-AC_SUBST(ISC_PLATFORM_NEEDPORTT)
-
-AC_MSG_CHECKING(for struct timespec)
-AC_TRY_COMPILE([
-#include <sys/types.h>
-#include <time.h>],
-[struct timespec ts = { 0, 0 }; return (0);],
-	[AC_MSG_RESULT(yes)
-	ISC_PLATFORM_NEEDTIMESPEC="#undef ISC_PLATFORM_NEEDTIMESPEC"],
-        [AC_MSG_RESULT(no)
-	ISC_PLATFORM_NEEDTIMESPEC="#define ISC_PLATFORM_NEEDTIMESPEC 1"])
-AC_SUBST(ISC_PLATFORM_NEEDTIMESPEC)
-
-#
-# Check for addrinfo
-#
-AC_MSG_CHECKING(for struct addrinfo)
-AC_TRY_COMPILE([
-#include <netdb.h>],
-[struct addrinfo a; return (0);],
-	[AC_MSG_RESULT(yes)
-	AC_DEFINE(HAVE_ADDRINFO)],
-	[AC_MSG_RESULT(no)])
-
-AC_MSG_CHECKING(for int sethostent)
-AC_TRY_COMPILE([
-#include <netdb.h>],
-[int i = sethostent(0); return(0);],
-	[AC_MSG_RESULT(yes)],
-	[AC_MSG_RESULT(no)])
-
-AC_MSG_CHECKING(for int endhostent)
-AC_TRY_COMPILE([
-#include <netdb.h>],
-[int i = endhostent(); return(0);],
-	[AC_MSG_RESULT(yes)
-	ISC_LWRES_ENDHOSTENTINT="#define ISC_LWRES_ENDHOSTENTINT 1"],
-	[AC_MSG_RESULT(no)
-	ISC_LWRES_ENDHOSTENTINT="#undef ISC_LWRES_ENDHOSTENTINT"])
-AC_SUBST(ISC_LWRES_ENDHOSTENTINT)
-
-AC_MSG_CHECKING(for int setnetent)
-AC_TRY_COMPILE([
-#include <netdb.h>],
-[int i = setnetent(0); return(0);],
-	[AC_MSG_RESULT(yes)
-	ISC_LWRES_SETNETENTINT="#define ISC_LWRES_SETNETENTINT 1"],
-	[AC_MSG_RESULT(no)
-	ISC_LWRES_SETNETENTINT="#undef ISC_LWRES_SETNETENTINT"])
-AC_SUBST(ISC_LWRES_SETNETENTINT)
-
-AC_MSG_CHECKING(for int endnetent)
-AC_TRY_COMPILE([
-#include <netdb.h>],
-[int i = endnetent(); return(0);],
-	[AC_MSG_RESULT(yes)
-	ISC_LWRES_ENDNETENTINT="#define ISC_LWRES_ENDNETENTINT 1"],
-	[AC_MSG_RESULT(no)
-	ISC_LWRES_ENDNETENTINT="#undef ISC_LWRES_ENDNETENTINT"])
-AC_SUBST(ISC_LWRES_ENDNETENTINT)
-
-AC_MSG_CHECKING(for gethostbyaddr(const void *, size_t, ...))
-AC_TRY_COMPILE([
-#include <netdb.h>
-struct hostent *gethostbyaddr(const void *, size_t, int);],
-[return(0);],
-	[AC_MSG_RESULT(yes)
-	ISC_LWRES_GETHOSTBYADDRVOID="#define ISC_LWRES_GETHOSTBYADDRVOID 1"],
-	[AC_MSG_RESULT(no)
-	ISC_LWRES_GETHOSTBYADDRVOID="#undef ISC_LWRES_GETHOSTBYADDRVOID"])
-AC_SUBST(ISC_LWRES_GETHOSTBYADDRVOID)
-
-AC_MSG_CHECKING(for h_errno in netdb.h)
-AC_TRY_COMPILE([
-#include <netdb.h>],
-[h_errno = 1; return(0);],
-	[AC_MSG_RESULT(yes)
-	ISC_LWRES_NEEDHERRNO="#undef ISC_LWRES_NEEDHERRNO"],
-	[AC_MSG_RESULT(no)
-	ISC_LWRES_NEEDHERRNO="#define ISC_LWRES_NEEDHERRNO 1"])
-AC_SUBST(ISC_LWRES_NEEDHERRNO)
-
-AC_CHECK_FUNC(getipnodebyname,
-        [ISC_LWRES_GETIPNODEPROTO="#undef ISC_LWRES_GETIPNODEPROTO"],
-        [ISC_LWRES_GETIPNODEPROTO="#define ISC_LWRES_GETIPNODEPROTO 1"])
-AC_CHECK_FUNC(getnameinfo,
-        [ISC_LWRES_GETNAMEINFOPROTO="#undef ISC_LWRES_GETNAMEINFOPROTO"],
-        [ISC_LWRES_GETNAMEINFOPROTO="#define ISC_LWRES_GETNAMEINFOPROTO 1"])
-AC_CHECK_FUNC(getaddrinfo,
-        [ISC_LWRES_GETADDRINFOPROTO="#undef ISC_LWRES_GETADDRINFOPROTO"
-	AC_DEFINE(HAVE_GETADDRINFO)],
-        [ISC_LWRES_GETADDRINFOPROTO="#define ISC_LWRES_GETADDRINFOPROTO 1"])
-AC_CHECK_FUNC(gai_strerror, AC_DEFINE(HAVE_GAISTRERROR))
-AC_SUBST(ISC_LWRES_GETIPNODEPROTO)
-AC_SUBST(ISC_LWRES_GETADDRINFOPROTO)
-AC_SUBST(ISC_LWRES_GETNAMEINFOPROTO)
-AC_CHECK_FUNC(pselect,
-	      [NEED_PSELECT="#undef NEED_PSELECT"],
-	      [NEED_PSELECT="#define NEED_PSELECT"])
-AC_SUBST(NEED_PSELECT)
-AC_CHECK_FUNC(gettimeofday,
-	      [NEED_GETTIMEOFDAY="#undef NEED_GETTIMEOFDAY"],
-	      [NEED_GETTIMEOFDAY="#define NEED_GETTIMEOFDAY 1"])
-AC_SUBST(NEED_GETTIMEOFDAY)
-AC_CHECK_FUNC(strndup,
-	      [HAVE_STRNDUP="#define HAVE_STRNDUP 1"],
-	      [HAVE_STRNDUP="#undef HAVE_STRNDUP"])
-AC_SUBST(HAVE_STRNDUP)
-
-#
-# Look for a sysctl call to get the list of network interfaces.
-#
-AC_MSG_CHECKING(for interface list sysctl)
-AC_EGREP_CPP(found_rt_iflist, [
-#include <sys/param.h>
-#include <sys/sysctl.h>
-#include <sys/socket.h>
-#ifdef NET_RT_IFLIST
-found_rt_iflist
-#endif
-],
-	[AC_MSG_RESULT(yes)
-	 AC_DEFINE(HAVE_IFLIST_SYSCTL)],
-	[AC_MSG_RESULT(no)])
-
-#
-# Check for some other useful functions that are not ever-present.
-#
-AC_CHECK_FUNC(strsep,
-	[ISC_PLATFORM_NEEDSTRSEP="#undef ISC_PLATFORM_NEEDSTRSEP"],
-	[ISC_PLATFORM_NEEDSTRSEP="#define ISC_PLATFORM_NEEDSTRSEP 1"])
-
-
-AC_MSG_CHECKING(for char *sprintf)
-AC_TRY_COMPILE([
-#include <stdio.h>
-],
-[ char buf[2]; return(*sprintf(buf,"x"));],
-AC_DEFINE(SPRINTF_CHAR)
-AC_MSG_RESULT(yes)
-,
-AC_MSG_RESULT(no)
-)
-
-AC_MSG_CHECKING(for char *vsprintf)
-case $host in
-*sunos4*) # not decared in any header file.
-AC_DEFINE(VSPRINTF_CHAR)
-AC_MSG_RESULT(yes)
-;;
-*)
-AC_TRY_COMPILE([
-#include <stdio.h>
-],
-[ char buf[2]; return(*vsprintf(buf,"x"));],
-AC_DEFINE(VSPRINTF_CHAR)
-AC_MSG_RESULT(yes)
-,
-AC_MSG_RESULT(no)
-)
-;;
-esac
-
-AC_CHECK_FUNC(vsnprintf,
-	[ISC_PLATFORM_NEEDVSNPRINTF="#undef ISC_PLATFORM_NEEDVSNPRINTF"],
-	[ISC_EXTRA_OBJS="$ISC_EXTRA_OBJS print.$O"
-	 ISC_EXTRA_SRCS="$ISC_EXTRA_SRCS print.c"
-	 ISC_PLATFORM_NEEDVSNPRINTF="#define ISC_PLATFORM_NEEDVSNPRINTF 1"])
-AC_SUBST(ISC_PLATFORM_NEEDSTRSEP)
-AC_SUBST(ISC_PLATFORM_NEEDVSNPRINTF)
-
-AC_SUBST(ISC_EXTRA_OBJS)
-AC_SUBST(ISC_EXTRA_SRCS)
-
-# Determine the printf format characters to use when printing
-# values of type isc_int64_t.  We make the assumption that platforms
-# where a "long long" is the same size as a "long" (e.g., Alpha/OSF1)
-# want "%ld" and everyone else can use "%lld".  Win32 uses "%I64d",
-# but that's defined elsewhere since we don't use configure on Win32.
-#
-AC_MSG_CHECKING(printf format modifier for 64-bit integers)
-AC_TRY_RUN([main() { exit(!(sizeof(long long int) == sizeof(long int))); }],
-	[AC_MSG_RESULT(l)
-	ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "l"'],
-	[AC_MSG_RESULT(ll)
-	ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "ll"'],
-	[AC_MSG_RESULT(default ll)
-	ISC_PLATFORM_QUADFORMAT='#define ISC_PLATFORM_QUADFORMAT "ll"'])
-AC_SUBST(ISC_PLATFORM_QUADFORMAT)
-
-#
-# Security Stuff
-#
-AC_CHECK_FUNC(chroot, AC_DEFINE(HAVE_CHROOT))
-
-#
-# for accept, recvfrom, getpeername etc.
-#
-AC_MSG_CHECKING(for socket length type)
-AC_TRY_COMPILE([
-#include <sys/types.h>
-#include <sys/socket.h>
-int accept(int, struct sockaddr *, socklen_t *);
-],[],
-[ISC_SOCKLEN_T="#define ISC_SOCKLEN_T socklen_t"
-AC_MSG_RESULT(socklen_t)]
-,
-AC_TRY_COMPILE([
-#include <sys/types.h>
-#include <sys/socket.h>
-int accept(int, struct sockaddr *, unsigned int *);
-],[],
-[ISC_SOCKLEN_T="#define ISC_SOCKLEN_T unsigned int"
-AC_MSG_RESULT(unsigned int)]
-,
-AC_TRY_COMPILE([
-#include <sys/types.h>
-#include <sys/socket.h>
-int accept(int, struct sockaddr *, unsigned long *);
-],[],
-[ISC_SOCKLEN_T="#define ISC_SOCKLEN_T unsigned long"
-AC_MSG_RESULT(unsigned long)]
-,
-AC_TRY_COMPILE([
-#include <sys/types.h>
-#include <sys/socket.h>
-int accept(int, struct sockaddr *, long *);
-],[],
-[ISC_SOCKLEN_T="#define ISC_SOCKLEN_T long"
-AC_MSG_RESULT(long)]
-,
-ISC_SOCKLEN_T="#define ISC_SOCKLEN_T int"
-AC_MSG_RESULT(int)
-))))
-AC_SUBST(ISC_SOCKLEN_T)
-
-AC_CHECK_FUNC(getgrouplist,
-AC_TRY_COMPILE(
-[#include <unistd.h>
-int
-getgrouplist(const char *name, int basegid, int *groups, int *ngroups) {
-}
-],
-[return (0);],
-GETGROUPLIST_ARGS="#define GETGROUPLIST_ARGS const char *name, int basegid, int *groups, int *ngroups"
-,
-GETGROUPLIST_ARGS="#define GETGROUPLIST_ARGS const char *name, gid_t basegid, gid_t *groups, int *ngroups"
-),
-GETGROUPLIST_ARGS="#define GETGROUPLIST_ARGS const char *name, gid_t basegid, gid_t *groups, int *ngroups"
-AC_DEFINE(NEED_GETGROUPLIST)
-)
-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(
-[
-#undef _REENTRANT
-#define _REENTRANT
-#define _OSF_SOURCE
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-struct netent *
-getnetbyaddr_r(long net, int type, struct netent *result, char *buffer,
-int buflen) {}
-],
-[return (0)],
-[
-NET_R_ARGS="#define NET_R_ARGS char *buf, int buflen"
-NET_R_BAD="#define NET_R_BAD NULL"
-NET_R_COPY="#define NET_R_COPY buf, buflen"
-NET_R_COPY_ARGS="#define NET_R_COPY_ARGS NET_R_ARGS"
-NET_R_OK="#define NET_R_OK nptr"
-NET_R_SETANSWER="#undef NET_R_SETANSWER"
-NET_R_RETURN="#define NET_R_RETURN struct netent *"
-GETNETBYADDR_ADDR_T="#define GETNETBYADDR_ADDR_T long"
-NETENT_DATA="#undef NETENT_DATA"
-],
-AC_TRY_COMPILE(
-[
-#undef _REENTRANT
-#define _REENTRANT
-#define _OSF_SOURCE
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-int getnetbyaddr_r (unsigned long int, 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"
-],
-AC_TRY_COMPILE(
-[
-#undef _REENTRANT
-#define _REENTRANT
-#define _OSF_SOURCE
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-extern int getnetbyaddr_r(int, int, struct netent *, struct netent_data *);
-],
-[return (0)],
-[
-NET_R_ARGS="#define NET_R_ARGS struct netent_data *ndptr"
-NET_R_BAD="#define NET_R_BAD (-1)"
-NET_R_COPY="#define NET_R_COPY ndptr"
-NET_R_COPY_ARGS="#define NET_R_COPY_ARGS struct netent_data *ndptr"
-NET_R_OK="#define NET_R_OK 0"
-NET_R_SETANSWER="#undef NET_R_SETANSWER"
-NET_R_RETURN="#define NET_R_RETURN int"
-GETNETBYADDR_ADDR_T="#define GETNETBYADDR_ADDR_T int"
-NETENT_DATA="#define NETENT_DATA 1"
-],
-AC_TRY_COMPILE(
-#undef __USE_MISC
-#define __USE_MISC
-[#include <netdb.h>
-int getnetbyaddr_r (in_addr_t, int, struct netent *, struct netent_data *);
-],
-[return (0)],
-[
-NET_R_ARGS="#define NET_R_ARGS struct netent_data *ndptr"
-NET_R_BAD="#define NET_R_BAD (-1)"
-NET_R_COPY="#define NET_R_COPY ndptr"
-NET_R_COPY_ARGS="#define NET_R_COPY_ARGS struct netent_data *ndptr"
-NET_R_OK="#define NET_R_OK 0"
-NET_R_SETANSWER="#undef NET_R_SETANSWER"
-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 (long, int, struct netent *, struct netent_data *);
-],
-[return (0)],
-[
-NET_R_ARGS="#define NET_R_ARGS struct netent_data *ndptr"
-NET_R_BAD="#define NET_R_BAD (-1)"
-NET_R_COPY="#define NET_R_COPY ndptr"
-NET_R_COPY_ARGS="#define NET_R_COPY_ARGS struct netent_data *ndptr"
-NET_R_OK="#define NET_R_OK 0"
-NET_R_SETANSWER="#undef NET_R_SETANSWER"
-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"
-],
-)
-)
-)
-)
-)
-)
-,
-NET_R_ARGS="#define NET_R_ARGS char *buf, int buflen"
-NET_R_BAD="#define NET_R_BAD NULL"
-NET_R_COPY="#define NET_R_COPY buf, buflen"
-NET_R_COPY_ARGS="#define NET_R_COPY_ARGS NET_R_ARGS"
-NET_R_OK="#define NET_R_OK nptr"
-NET_R_SETANSWER="#undef NET_R_SETANSWER"
-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
-AC_SUBST(NET_R_ARGS)
-AC_SUBST(NET_R_BAD)
-AC_SUBST(NET_R_COPY)
-AC_SUBST(NET_R_COPY_ARGS)
-AC_SUBST(NET_R_OK)
-AC_SUBST(NET_R_SETANSWER)
-AC_SUBST(NET_R_RETURN)
-AC_SUBST(GETNETBYADDR_ADDR_T)
-AC_SUBST(NETENT_DATA)
-
-AC_CHECK_FUNC(setnetent_r,
-AC_TRY_COMPILE(
-[
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-void  setnetent_r (int);
-] ,[return (0);],[
-NET_R_ENT_ARGS="#undef NET_R_ENT_ARGS /*empty*/"
-NET_R_SET_RESULT="#undef NET_R_SET_RESULT /*empty*/"
-NET_R_SET_RETURN="#define NET_R_SET_RETURN void"
-],
-AC_TRY_COMPILE(
-[
-#define _REENTRANT
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-extern int setnetent_r(int, struct netent_data *);
-] ,[return (0);],[
-NET_R_ENT_ARGS="#define NET_R_ENT_ARGS struct netent_data *ndptr"
-NET_R_SET_RESULT="#define NET_R_SET_RESULT NET_R_OK"
-NET_R_SET_RETURN="#define NET_R_SET_RETURN int"
-],
-)
-)
-,
-NET_R_ENT_ARGS="#undef NET_R_ENT_ARGS /*empty*/"
-NET_R_SET_RESULT="#undef NET_R_SET_RESULT /*empty*/"
-NET_R_SET_RETURN="#define NET_R_SET_RETURN void"
-)
-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(
-[
-#undef _REENTRANT
-#define _REENTRANT
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-void  endnetent_r (void);
-] ,[return (0);],[
-NET_R_END_RESULT="#define NET_R_END_RESULT(x) /*empty*/"
-NET_R_END_RETURN="#define NET_R_END_RETURN void"
-],
-AC_TRY_COMPILE(
-[
-#undef _REENTRANT
-#define _REENTRANT
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-extern int endnetent_r(struct netent_data *);
-] ,[return (0);],[
-NET_R_END_RESULT="#define NET_R_END_RESULT(x) return (x)"
-NET_R_END_RETURN="#define NET_R_END_RETURN int"
-],
-AC_TRY_COMPILE(
-[
-#undef _REENTRANT
-#define _REENTRANT
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-extern void endnetent_r(struct netent_data *);
-] ,[return (0);],[
-NET_R_END_RESULT="#define NET_R_END_RESULT(x) /*empty*/"
-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)
-
-AC_CHECK_FUNC(getgrnam_r,,AC_DEFINE(NEED_GETGRNAM_R))
-AC_CHECK_FUNC(getgrgid_r,,AC_DEFINE(NEED_GETGRGID_R))
-
-AC_CHECK_FUNC(getgrent_r,
-AC_TRY_COMPILE(
-[
-#include <grp.h>
-struct group *getgrent_r(struct group *grp, char *buffer,
-           int buflen) {}
-] ,[return (0);],[
-GROUP_R_ARGS="#define GROUP_R_ARGS char *buf, int buflen"
-GROUP_R_BAD="#define GROUP_R_BAD NULL"
-GROUP_R_OK="#define GROUP_R_OK gptr"
-GROUP_R_RETURN="#define GROUP_R_RETURN struct group *"
-],
-)
-,
-GROUP_R_ARGS="#define GROUP_R_ARGS char *buf, int buflen"
-GROUP_R_BAD="#define GROUP_R_BAD NULL"
-GROUP_R_OK="#define GROUP_R_OK gptr"
-GROUP_R_RETURN="#define GROUP_R_RETURN struct group *"
-AC_DEFINE(NEED_GETGRENT_R)
-)
-AC_SUBST(GROUP_R_ARGS)
-AC_SUBST(GROUP_R_BAD)
-AC_SUBST(GROUP_R_OK)
-AC_SUBST(GROUP_R_RETURN)
-
-AC_CHECK_FUNC(endgrent_r,
-,
-GROUP_R_END_RESULT="#define GROUP_R_END_RESULT(x) /*empty*/"
-GROUP_R_END_RETURN="#define GROUP_R_END_RETURN void"
-GROUP_R_ENT_ARGS="#define GROUP_R_ENT_ARGS void"
-AC_DEFINE(NEED_ENDGRENT_R)
-)
-AC_SUBST(GROUP_R_END_RESULT)
-AC_SUBST(GROUP_R_END_RETURN)
-AC_SUBST(GROUP_R_ENT_ARGS)
-
-AC_CHECK_FUNC(setgrent_r,
-,
-GROUP_R_SET_RESULT="#undef GROUP_R_SET_RESULT /*empty*/"
-GROUP_R_SET_RETURN="#define GROUP_R_SET_RETURN void"
-AC_DEFINE(NEED_SETGRENT_R)
-)
-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(
-[
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-struct hostent  *gethostbyname_r
-(const char *name, struct hostent *hp, char *buf, int len, int *h_errnop) {}
-],
-[return (0);],
-[
-HOST_R_ARGS="#define HOST_R_ARGS char *buf, int buflen, int *h_errnop"
-HOST_R_BAD="#define HOST_R_BAD NULL"
-HOST_R_COPY="#define HOST_R_COPY buf, buflen"
-HOST_R_COPY_ARGS="#define HOST_R_COPY_ARGS char *buf, int buflen"
-HOST_R_ERRNO="#define HOST_R_ERRNO *h_errnop = h_errno"
-HOST_R_OK="#define HOST_R_OK hptr"
-HOST_R_RETURN="#define HOST_R_RETURN struct hostent *"
-HOST_R_SETANSWER="#undef HOST_R_SETANSWER"
-HOSTENT_DATA="#undef HOSTENT_DATA"
-]
-,
-AC_TRY_COMPILE([
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-int gethostbyname_r(const char *name,
-                          struct hostent *result,
-                          struct hostent_data *hdptr);
-],,[
-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="#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"
-HOSTENT_DATA="#define HOSTENT_DATA 1"
-],
-AC_TRY_COMPILE([
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-extern int gethostbyname_r (const char *,
-                                 struct hostent *,
-                                 char *, size_t,
-                                 struct hostent **,
-                                 int *);
-],,[
-HOST_R_ARGS="#define HOST_R_ARGS char *buf, size_t buflen, struct hostent **answerp, int *h_errnop"
-HOST_R_BAD="#define HOST_R_BAD ERANGE"
-HOST_R_COPY="#define HOST_R_COPY buf, buflen"
-HOST_R_COPY_ARGS="#define HOST_R_COPY_ARGS char *buf, int buflen"
-HOST_R_ERRNO="#define HOST_R_ERRNO *h_errnop = h_errno"
-HOST_R_OK="#define HOST_R_OK 0"
-HOST_R_RETURN="#define HOST_R_RETURN int"
-HOST_R_SETANSWER="#define HOST_R_SETANSWER 1"
-HOSTENT_DATA="#undef HOSTENT_DATA"
-],
-)))
-,
-HOST_R_ARGS="#define HOST_R_ARGS char *buf, int buflen, int *h_errnop"
-HOST_R_BAD="#define HOST_R_BAD NULL"
-HOST_R_COPY="#define HOST_R_COPY buf, buflen"
-HOST_R_COPY_ARGS="#define HOST_R_COPY_ARGS char *buf, int buflen"
-HOST_R_ERRNO="#define HOST_R_ERRNO *h_errnop = h_errno"
-HOST_R_OK="#define HOST_R_OK hptr"
-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)
-AC_SUBST(HOST_R_COPY_ARGS)
-AC_SUBST(HOST_R_ERRNO)
-AC_SUBST(HOST_R_OK)
-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
-#define _REENTRANT
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-int endhostent_r(struct hostent_data *buffer);
-], ,
-HOST_R_END_RESULT="#define HOST_R_END_RESULT(x) return (x)"
-HOST_R_END_RETURN="#define HOST_R_END_RETURN int"
-HOST_R_ENT_ARGS="#define HOST_R_ENT_ARGS struct hostent_data *hdptr"
-,
-AC_TRY_COMPILE([
-#undef _REENTRANT
-#define _REENTRANT
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-extern void endhostent_r(struct hostent_data *ht_data);
-],[],[
-HOST_R_END_RESULT="#define HOST_R_END_RESULT(x)"
-HOST_R_END_RETURN="#define HOST_R_END_RETURN void"
-HOST_R_ENT_ARGS="#define HOST_R_ENT_ARGS struct hostent_data *hdptr"
-],
-AC_TRY_COMPILE([
-#undef _REENTRANT
-#define _REENTRANT
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-extern void endhostent_r(void);
-],[],[
-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*/"
-],
-)
-)
-)
-,
-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
-#define _REENTRANT
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-extern void sethostent_r(int flag, struct hostent_data *ht_data);],[],
-[HOST_R_SET_RESULT="#undef HOST_R_SET_RESULT /*empty*/"
-HOST_R_SET_RETURN="#define HOST_R_SET_RETURN void"],
-AC_TRY_COMPILE([
-#undef _REENTRANT
-#define _REENTRANT
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-extern int sethostent_r(int flag, struct hostent_data *ht_data);],[],
-[HOST_R_SET_RESULT="#define HOST_R_SET_RESULT 0"
-HOST_R_SET_RETURN="#define HOST_R_SET_RETURN int"],
-AC_TRY_COMPILE([
-#undef _REENTRANT
-#define _REENTRANT
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-void            sethostent_r (int);],[],
-[HOST_R_SET_RESULT="#undef HOST_R_SET_RESULT"
-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)
-
-
-AC_MSG_CHECKING(struct passwd element pw_class)
-AC_TRY_COMPILE([
-#include <sys/types.h>
-#include <pwd.h>
-],[struct passwd *pw; pw->pw_class = "";],
-AC_MSG_RESULT(yes)
-AC_DEFINE(HAS_PW_CLASS)
-,
-		AC_MSG_RESULT(no)
-)
-
-AC_TRY_COMPILE([
-#include <sys/types.h>
-#include <pwd.h>
-void
-setpwent(void) {}
-],
-[return (0);],
-SETPWENT_VOID="#define SETPWENT_VOID 1"
-,
-SETPWENT_VOID="#undef SETPWENT_VOID"
-)
-AC_SUBST(SETPWENT_VOID)
-
-AC_TRY_COMPILE([
-#include <sys/types.h>
-#include <grp.h>
-void
-setgrent(void) {}
-],
-[return (0);],
-SETGRENT_VOID="#define SETGRENT_VOID 1"
-,
-SETGRENT_VOID="#undef SETGRENT_VOID"
-)
-AC_SUBST(SETGRENT_VOID)
-
-case $host in
-ia64-hp-hpux11.*)
-NGR_R_CONST="#define NGR_R_CONST"
-;;
-*-hp-hpux11.*)
-#
-# HPUX doesn't have a prototype for getnetgrent_r().
-#
-NGR_R_CONST="#define NGR_R_CONST"
-NGR_R_ARGS="#define NGR_R_ARGS char *buf, int buflen"
-NGR_R_BAD="#define NGR_R_BAD (0)"
-NGR_R_COPY="#define NGR_R_COPY buf, buflen"
-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"
-;;
-
-*)
-AC_CHECK_FUNC(getnetgrent_r,
-AC_TRY_COMPILE(
-[
-#undef __USE_MISC
-#define __USE_MISC
-#undef _REEENTRANT
-#define _REEENTRANT
-#include <netdb.h>
-#include <unistd.h>
-int getnetgrent_r(char **m, char **u, char **d, char *b, int l) {}
-]
-,
-[return (0);],
-[
-NGR_R_CONST="#define NGR_R_CONST"
-NGR_R_ARGS="#define NGR_R_ARGS char *buf, int buflen"
-NGR_R_BAD="#define NGR_R_BAD (0)"
-NGR_R_COPY="#define NGR_R_COPY buf, buflen"
-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"
-]
-,
-AC_TRY_COMPILE(
-[
-#undef __USE_MISC
-#define __USE_MISC
-#undef _REEENTRANT
-#define _REEENTRANT
-#include <netdb.h>
-#include <unistd.h>
-int getnetgrent_r(char **m, char **u, char **d, char *b, size_t l) {}
-]
-,
-[return (0);],
-[
-NGR_R_CONST="#define NGR_R_CONST"
-NGR_R_ARGS="#define NGR_R_ARGS char *buf, size_t buflen"
-NGR_R_BAD="#define NGR_R_BAD (0)"
-NGR_R_COPY="#define NGR_R_COPY buf, buflen"
-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"
-]
-,
-AC_TRY_COMPILE(
-[
-#undef __USE_MISC
-#define __USE_MISC
-#undef _REEENTRANT
-#define _REEENTRANT
-#include <netdb.h>
-#include <unistd.h>
-extern int getnetgrent_r(char **, char **, char **, void **);
-]
-,
-[return (0);],
-[
-NGR_R_CONST="#define NGR_R_CONST"
-NGR_R_ARGS="#define NGR_R_ARGS void **buf"
-NGR_R_BAD="#define NGR_R_BAD (0)"
-NGR_R_COPY="#define NGR_R_COPY buf"
-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"
-NGR_R_PRIVATE="#define NGR_R_PRIVATE 1"
-]
-,
-AC_TRY_COMPILE(
-[
-#undef __USE_MISC
-#define __USE_MISC
-#undef _REEENTRANT
-#define _REEENTRANT
-#include <netdb.h>
-#include <unistd.h>
-extern int getnetgrent_r(const char **, const char **, const char **, void *);
-]
-,
-[return (0);],
-[
-NGR_R_CONST="#define NGR_R_CONST const"
-NGR_R_ARGS="#define NGR_R_ARGS void *buf"
-NGR_R_BAD="#define NGR_R_BAD (0)"
-NGR_R_COPY="#define NGR_R_COPY buf"
-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"
-NGR_R_PRIVATE="#define NGR_R_PRIVATE 2"
-]
-,
-)
-)
-)
-)
-,
-NGR_R_CONST="#define NGR_R_CONST"
-NGR_R_ARGS="#define NGR_R_ARGS char *buf, int buflen"
-NGR_R_BAD="#define NGR_R_BAD (0)"
-NGR_R_COPY="#define NGR_R_COPY buf, buflen"
-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_CONST)
-AC_SUBST(NGR_R_ARGS)
-AC_SUBST(NGR_R_BAD)
-AC_SUBST(NGR_R_COPY)
-AC_SUBST(NGR_R_COPY_ARGS)
-AC_SUBST(NGR_R_OK)
-AC_SUBST(NGR_R_RETURN)
-AC_SUBST(NGR_R_PRIVATE)
-
-AC_CHECK_FUNC(endnetgrent_r,
-AC_TRY_COMPILE(
-[
-#undef __USE_MISC
-#define __USE_MISC
-#undef _REEENTRANT
-#define _REEENTRANT
-#include <netdb.h>
-#include <unistd.h>
-void endnetgrent_r(void **ptr);
-]
-,
-[return (0);]
-,
-[
-NGR_R_END_RESULT="#define NGR_R_END_RESULT(x)  /* empty */"
-NGR_R_END_RETURN="#define NGR_R_END_RETURN void"
-NGR_R_END_ARGS="#define NGR_R_END_ARGS NGR_R_ARGS"
-]
-,
-AC_TRY_COMPILE(
-[
-#undef __USE_MISC
-#define __USE_MISC
-#undef _REEENTRANT
-#define _REEENTRANT
-#include <netdb.h>
-#include <unistd.h>
-void endnetgrent_r(void *ptr);
-]
-,
-[return (0);]
-,
-[
-NGR_R_END_RESULT="#define NGR_R_END_RESULT(x)  /* empty */"
-NGR_R_END_RETURN="#define NGR_R_END_RETURN void"
-NGR_R_END_ARGS="#define NGR_R_END_ARGS void *buf"
-]
-,
-[
-NGR_R_END_RESULT="#define NGR_R_END_RESULT(x)  return (x)"
-NGR_R_END_RETURN="#define NGR_R_END_RETURN int"
-NGR_R_END_ARGS="#define NGR_R_END_ARGS NGR_R_ARGS"
-]
-)
-)
-,
-NGR_R_END_RESULT="#define NGR_R_END_RESULT(x)  /*empty*/"
-NGR_R_END_RETURN="#define NGR_R_END_RETURN void"
-NGR_R_END_ARGS="#undef NGR_R_END_ARGS /*empty*/"
-AC_DEFINE(NEED_ENDNETGRENT_R)
-)
-AC_SUBST(NGR_R_END_RESULT)
-AC_SUBST(NGR_R_END_RETURN)
-AC_SUBST(NGR_R_END_ARGS)
-
-AC_CHECK_FUNC(setnetgrent_r,
-[
-case "$host" in
-*bsdi*)
-	#
-	# No prototype
-	#
-	NGR_R_SET_RESULT="#undef NGR_R_SET_RESULT /*empty*/"
-	NGR_R_SET_RETURN="#define NGR_R_SET_RETURN void"
-	NGR_R_SET_ARGS="#define NGR_R_SET_ARGS NGR_R_ARGS"
-	NGR_R_SET_CONST="#define NGR_R_SET_CONST"
-	;;
-*hpux*)
-	#
-	# No prototype
-	#
-	NGR_R_SET_RESULT="#define NGR_R_SET_RESULT NGR_R_OK"
-	NGR_R_SET_RETURN="#define NGR_R_SET_RETURN int"
-	NGR_R_SET_ARGS="#undef NGR_R_SET_ARGS /* empty */"
-	NGR_R_SET_CONST="#define NGR_R_SET_CONST"
-	;;
-*)
-AC_TRY_COMPILE(
-[
-#undef __USE_MISC
-#define __USE_MISC
-#undef _REEENTRANT
-#define _REEENTRANT
-#include <netdb.h>
-#include <unistd.h>
-void setnetgrent_r(void **ptr);
-]
-,
-[return (0);]
-,
-[
-NGR_R_SET_RESULT="#undef NGR_R_SET_RESULT /* empty */"
-NGR_R_SET_RETURN="#define NGR_R_SET_RETURN void"
-NGR_R_SET_ARGS="#define NGR_R_SET_ARGS void **buf"
-NGR_R_SET_CONST="#define NGR_R_SET_CONST"
-]
-,
-AC_TRY_COMPILE(
-[
-#undef __USE_MISC
-#define __USE_MISC
-#undef _REEENTRANT
-#define _REEENTRANT
-#include <netdb.h>
-#include <unistd.h>
-extern int setnetgrent_r(char *, void **);
-]
-,
-[return (0);]
-,
-[
-NGR_R_SET_RESULT="#define NGR_R_SET_RESULT NGR_R_OK"
-NGR_R_SET_RETURN="#define NGR_R_SET_RETURN int"
-NGR_R_SET_ARGS="#define NGR_R_SET_ARGS void **buf"
-NGR_R_SET_CONST="#define NGR_R_SET_CONST"
-]
-,
-[
-NGR_R_SET_RESULT="#define NGR_R_SET_RESULT NGR_R_OK"
-NGR_R_SET_RETURN="#define NGR_R_SET_RETURN int"
-NGR_R_SET_ARGS="#undef NGR_R_SET_ARGS"
-NGR_R_SET_CONST="#define NGR_R_SET_CONST const"
-]
-))
-;;
-esac
-]
-,
-NGR_R_SET_RESULT="#undef NGR_R_SET_RESULT /*empty*/"
-NGR_R_SET_RETURN="#define NGR_R_SET_RETURN void"
-NGR_R_SET_ARGS="#undef NGR_R_SET_ARGS"
-NGR_R_SET_CONST="#define NGR_R_SET_CONST const"
-)
-
-AC_SUBST(NGR_R_SET_RESULT)
-AC_SUBST(NGR_R_SET_RETURN)
-AC_SUBST(NGR_R_SET_ARGS)
-AC_SUBST(NGR_R_SET_CONST)
-
-AC_CHECK_FUNC(innetgr_r,,AC_DEFINE(NEED_INNETGR_R))
-
-case $host in
-ia64-hp-hpux11.*)
-;;
-*)
-AC_CHECK_FUNC(getprotoent_r,
-AC_TRY_COMPILE(
-[
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-struct protoent *getprotoent_r(struct protoent *result,
-		 char *buffer, int buflen) {}
-]
-,
-[return (0);]
-,
-[
-PROTO_R_ARGS="#define PROTO_R_ARGS char *buf, int buflen"
-PROTO_R_BAD="#define PROTO_R_BAD NULL"
-PROTO_R_COPY="#define PROTO_R_COPY buf, buflen"
-PROTO_R_COPY_ARGS="#define PROTO_R_COPY_ARGS PROTO_R_ARGS"
-PROTO_R_OK="#define PROTO_R_OK pptr"
-PROTO_R_SETANSWER="#undef PROTO_R_SETANSWER"
-PROTO_R_RETURN="#define PROTO_R_RETURN struct protoent *"
-PROTOENT_DATA="#undef PROTOENT_DATA"
-]
-,
-AC_TRY_COMPILE(
-[
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-int getprotoent_r (struct protoent *, char *, size_t, struct protoent **);
-
-]
-,
-[return (0);]
-,
-[
-PROTO_R_ARGS="#define PROTO_R_ARGS char *buf, size_t buflen, struct protoent **answerp"
-PROTO_R_BAD="#define PROTO_R_BAD ERANGE"
-PROTO_R_COPY="#define PROTO_R_COPY buf, buflen"
-PROTO_R_COPY_ARGS="#define PROTO_R_COPY_ARGS char *buf, size_t buflen"
-PROTO_R_OK="#define PROTO_R_OK 0"
-PROTO_R_SETANSWER="#define PROTO_R_SETANSWER 1"
-PROTO_R_RETURN="#define PROTO_R_RETURN int"
-PROTOENT_DATA="#undef PROTOENT_DATA"
-]
-,
-AC_TRY_COMPILE(
-[
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-int getprotoent_r (struct protoent *, struct protoent_data *prot_data);
-
-]
-,
-[return (0);]
-,
-[
-PROTO_R_ARGS="#define PROTO_R_ARGS struct protoent_data *prot_data"
-PROTO_R_BAD="#define PROTO_R_BAD (-1)"
-PROTO_R_COPY="#define PROTO_R_COPY prot_data"
-PROTO_R_COPY_ARGS="#define PROTO_R_COPY_ARGS struct protoent_data *pdptr"
-PROTO_R_OK="#define PROTO_R_OK 0"
-PROTO_R_SETANSWER="#undef PROTO_R_SETANSWER"
-PROTO_R_RETURN="#define PROTO_R_RETURN int"
-PROTOENT_DATA="#define PROTOENT_DATA 1"
-]
-,
-)
-)
-)
-,
-PROTO_R_ARGS="#define PROTO_R_ARGS char *buf, int buflen"
-PROTO_R_BAD="#define PROTO_R_BAD NULL"
-PROTO_R_COPY="#define PROTO_R_COPY buf, buflen"
-PROTO_R_COPY_ARGS="#define PROTO_R_COPY_ARGS PROTO_R_ARGS"
-PROTO_R_OK="#define PROTO_R_OK pptr"
-PROTO_R_SETANSWER="#undef PROTO_R_SETANSWER"
-PROTO_R_RETURN="#define PROTO_R_RETURN struct protoent *"
-PROTOENT_DATA="#undef PROTOENT_DATA"
-)
-;;
-esac
-AC_SUBST(PROTO_R_ARGS)
-AC_SUBST(PROTO_R_BAD)
-AC_SUBST(PROTO_R_COPY)
-AC_SUBST(PROTO_R_COPY_ARGS)
-AC_SUBST(PROTO_R_OK)
-AC_SUBST(PROTO_R_SETANSWER)
-AC_SUBST(PROTO_R_RETURN)
-AC_SUBST(PROTOENT_DATA)
-
-case $host in
-ia64-hp-hpux11.*)
-;;
-*)
-AC_CHECK_FUNC(endprotoent_r,
-AC_TRY_COMPILE(
-[
-#undef _REENTRANT
-#define _REENTRANT
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-void endprotoent_r(void);
-]
-,,
-[
-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"
-PROTO_R_ENT_UNUSED="#undef PROTO_R_ENT_UNUSED"
-]
-,
-AC_TRY_COMPILE(
-[
-#undef _REENTRANT
-#define _REENTRANT
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-void endprotoent_r(struct protoent_data *);
-]
-,,
-[
-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="#define PROTO_R_ENT_ARGS struct protoent_data *proto_data"
-PROTO_R_ENT_UNUSED="#define PROTO_R_ENT_UNUSED UNUSED(proto_data)"
-]
-,
-AC_TRY_COMPILE(
-[
-#undef _REENTRANT
-#define _REENTRANT
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-int endprotoent_r(struct protoent_data *);
-]
-,,
-[
-PROTO_R_END_RESULT="#define PROTO_R_END_RESULT(x) return(0)"
-PROTO_R_END_RETURN="#define PROTO_R_END_RETURN int"
-PROTO_R_ENT_ARGS="#define PROTO_R_ENT_ARGS struct protoent_data *proto_data"
-PROTO_R_ENT_UNUSED="#define PROTO_R_ENT_UNUSED UNUSED(proto_data)"
-]
-,
-)
-)
-)
-,
-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*/"
-PROTO_R_ENT_UNUSED="#undef PROTO_R_ENT_UNUSED"
-)
-esac
-AC_SUBST(PROTO_R_END_RESULT)
-AC_SUBST(PROTO_R_END_RETURN)
-AC_SUBST(PROTO_R_ENT_ARGS)
-AC_SUBST(PROTO_R_ENT_UNUSED)
-
-case $host in
-ia64-hp-hpux11.*)
-;;
-*)
-AC_CHECK_FUNC(setprotoent_r,
-AC_TRY_COMPILE(
-[
-#undef _REENTRANT
-#define _REENTRANT
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-void               setprotoent_r __P((int));
-],[],
-PROTO_R_SET_RESULT="#undef PROTO_R_SET_RESULT"
-PROTO_R_SET_RETURN="#define PROTO_R_SET_RETURN void"
-,
-AC_TRY_COMPILE(
-[
-#undef _REENTRANT
-#define _REENTRANT
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-int setprotoent_r (int, struct protoent_data *);
-],[],
-PROTO_R_SET_RESULT="#define PROTO_R_SET_RESULT (0)"
-PROTO_R_SET_RETURN="#define PROTO_R_SET_RETURN int"
-,
-)
-)
-,
-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)
-
-AC_CHECK_FUNC(getpwent_r,
-AC_TRY_COMPILE(
-[
-#include <sys/types.h>
-#include <pwd.h>
-struct passwd *
-getpwent_r(struct passwd *pwptr, char *buf, int buflen) {}
-]
-,
-[]
-,
-PASS_R_ARGS="#define PASS_R_ARGS char *buf, int buflen"
-PASS_R_BAD="#define PASS_R_BAD NULL"
-PASS_R_COPY="#define PASS_R_COPY buf, buflen"
-PASS_R_COPY_ARGS="#define PASS_R_COPY_ARGS PASS_R_ARGS"
-PASS_R_OK="#define PASS_R_OK pwptr"
-PASS_R_RETURN="#define PASS_R_RETURN struct passwd *"
-,
-)
-,
-PASS_R_ARGS="#define PASS_R_ARGS char *buf, int buflen"
-PASS_R_BAD="#define PASS_R_BAD NULL"
-PASS_R_COPY="#define PASS_R_COPY buf, buflen"
-PASS_R_COPY_ARGS="#define PASS_R_COPY_ARGS PASS_R_ARGS"
-PASS_R_OK="#define PASS_R_OK pwptr"
-PASS_R_RETURN="#define PASS_R_RETURN struct passwd *"
-AC_DEFINE(NEED_GETPWENT_R)
-)
-AC_SUBST(PASS_R_ARGS)
-AC_SUBST(PASS_R_BAD)
-AC_SUBST(PASS_R_COPY)
-AC_SUBST(PASS_R_COPY_ARGS)
-AC_SUBST(PASS_R_OK)
-AC_SUBST(PASS_R_RETURN)
-
-AC_CHECK_FUNC(endpwent_r,
-AC_TRY_COMPILE(
-[
-#include <pwd.h>
-void endpwent_r(FILE **pwfp);
-], ,
-PASS_R_END_RESULT="#define PASS_R_END_RESULT(x) /*empty*/"
-PASS_R_END_RETURN="#define PASS_R_END_RETURN void"
-PASS_R_ENT_ARGS="#define PASS_R_ENT_ARGS FILE **pwptr"
-,
-)
-,
-PASS_R_END_RESULT="#define PASS_R_END_RESULT(x) /*empty*/"
-PASS_R_END_RETURN="#define PASS_R_END_RETURN void"
-PASS_R_ENT_ARGS="#undef PASS_R_ENT_ARGS"
-AC_DEFINE(NEED_ENDPWENT_R)
-)
-AC_SUBST(PASS_R_END_RESULT)
-AC_SUBST(PASS_R_END_RETURN)
-AC_SUBST(PASS_R_ENT_ARGS)
-AC_CHECK_FUNC(setpassent_r,,AC_DEFINE(NEED_SETPASSENT_R))
-AC_CHECK_FUNC(setpassent,,AC_DEFINE(NEED_SETPASSENT))
-
-AC_CHECK_FUNC(setpwent_r,
-AC_TRY_COMPILE([
-#include <pwd.h>
-void setpwent_r(FILE **pwfp);
-], ,
-PASS_R_SET_RESULT="#undef PASS_R_SET_RESULT /* empty */"
-PASS_R_SET_RETURN="#define PASS_R_SET_RETURN int"
-,
-AC_TRY_COMPILE([
-#include <pwd.h>
-int setpwent_r(FILE **pwfp);
-], ,
-PASS_R_SET_RESULT="#define PASS_R_SET_RESULT 0"
-PASS_R_SET_RETURN="#define PASS_R_SET_RETURN int"
-,
-)
-)
-,
-PASS_R_SET_RESULT="#undef PASS_R_SET_RESULT /*empty*/"
-PASS_R_SET_RETURN="#define PASS_R_SET_RETURN void"
-AC_DEFINE(NEED_SETPWENT_R)
-)
-AC_SUBST(PASS_R_SET_RESULT)
-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
-#define __USE_MISC
-#include <netdb.h>
-struct servent *
-getservent_r(struct servent *result, char *buffer, int buflen) {}
-],[return (0);],
-[
-SERV_R_ARGS="#define SERV_R_ARGS char *buf, int buflen"
-SERV_R_BAD="#define SERV_R_BAD NULL"
-SERV_R_COPY="#define SERV_R_COPY buf, buflen"
-SERV_R_COPY_ARGS="#define SERV_R_COPY_ARGS SERV_R_ARGS"
-SERV_R_OK="#define SERV_R_OK sptr"
-SERV_R_SETANSWER="#undef SERV_R_SETANSWER"
-SERV_R_RETURN="#define SERV_R_RETURN struct servent *"
-]
-,
-AC_TRY_COMPILE([
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-int
-getservent_r (struct servent *, char *, size_t, struct servent **);
-],[return (0);],
-[
-SERV_R_ARGS="#define SERV_R_ARGS char *buf, size_t buflen, struct servent **answerp"
-SERV_R_BAD="#define SERV_R_BAD ERANGE"
-SERV_R_COPY="#define SERV_R_COPY buf, buflen"
-SERV_R_COPY_ARGS="#define SERV_R_COPY_ARGS char *buf, size_t buflen"
-SERV_R_OK="#define SERV_R_OK (0)"
-SERV_R_SETANSWER="#define SERV_R_SETANSWER 1"
-SERV_R_RETURN="#define SERV_R_RETURN int"
-]
-,
-AC_TRY_COMPILE([
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-int
-getservent_r (struct servent *, struct servent_data *serv_data);
-],[return (0);],
-[
-SERV_R_ARGS="#define SERV_R_ARGS struct servent_data *serv_data"
-SERV_R_BAD="#define SERV_R_BAD (-1)"
-SERV_R_COPY="#define SERV_R_COPY serv_data"
-SERV_R_COPY_ARGS="#define SERV_R_COPY_ARGS struct servent_data *sdptr"
-SERV_R_OK="#define SERV_R_OK (0)"
-SERV_R_SETANSWER="#undef SERV_R_SETANSWER"
-SERV_R_RETURN="#define SERV_R_RETURN int"
-SERVENT_DATA="#define SERVENT_DATA 1"
-]
-,
-)
-)
-)
-,
-SERV_R_ARGS="#define SERV_R_ARGS char *buf, int buflen"
-SERV_R_BAD="#define SERV_R_BAD NULL"
-SERV_R_COPY="#define SERV_R_COPY buf, buflen"
-SERV_R_COPY_ARGS="#define SERV_R_COPY_ARGS SERV_R_ARGS"
-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)
-AC_SUBST(SERV_R_COPY_ARGS)
-AC_SUBST(SERV_R_OK)
-AC_SUBST(SERV_R_SETANSWER)
-AC_SUBST(SERV_R_RETURN)
-AC_SUBST(SERVENT_DATA)
-
-case $host in
-ia64-hp-hpux11.*)
-;;
-*)
-AC_CHECK_FUNC(endservent_r,
-AC_TRY_COMPILE(
-[
-#undef _REENTRANT
-#define _REENTRANT
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-void endservent_r(void);
-]
-,
-,
-[
-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*/"
-SERV_R_ENT_UNUSED="#undef SERV_R_ENT_UNUSED /*empty*/"
-]
-,
-AC_TRY_COMPILE(
-[
-#undef _REENTRANT
-#define _REENTRANT
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-void endservent_r(struct servent_data *serv_data);
-]
-,
-,
-[
-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="#define SERV_R_ENT_ARGS struct servent_data *serv_data"
-SERV_R_ENT_UNUSED="#define SERV_R_ENT_UNUSED UNUSED(serv_data)"
-]
-,
-AC_TRY_COMPILE(
-[
-#undef _REENTRANT
-#define _REENTRANT
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-int endservent_r(struct servent_data *serv_data);
-]
-,
-,
-[
-SERV_R_END_RESULT="#define SERV_R_END_RESULT(x) return(x)"
-SERV_R_END_RETURN="#define SERV_R_END_RETURN int "
-SERV_R_ENT_ARGS="#define SERV_R_ENT_ARGS struct servent_data *serv_data"
-SERV_R_ENT_UNUSED="#define SERV_R_ENT_UNUSED UNUSED(serv_data)"
-]
-,
-)
-)
-)
-,
-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*/"
-SERV_R_ENT_UNUSED="#undef SERV_R_ENT_UNUSED /*empty*/"
-)
-esac
-AC_SUBST(SERV_R_END_RESULT)
-AC_SUBST(SERV_R_END_RETURN)
-AC_SUBST(SERV_R_ENT_ARGS)
-AC_SUBST(SERV_R_ENT_UNUSED)
-
-case $host in
-ia64-hp-hpux11.*)
-;;
-*)
-AC_CHECK_FUNC(setservent_r,
-AC_TRY_COMPILE(
-[
-#undef _REENTRANT
-#define _REENTRANT
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-void setservent_r(int);
-]
-,,
-[
-SERV_R_SET_RESULT="#undef SERV_R_SET_RESULT"
-SERV_R_SET_RETURN="#define SERV_R_SET_RETURN void"
-]
-,
-AC_TRY_COMPILE(
-[
-#undef _REENTRANT
-#define _REENTRANT
-#undef __USE_MISC
-#define __USE_MISC
-#include <netdb.h>
-int setservent_r(int, struct servent_data *);
-]
-,,
-[
-SERV_R_SET_RESULT="#define SERV_R_SET_RESULT (0)"
-SERV_R_SET_RETURN="#define SERV_R_SET_RETURN int"
-]
-,
-)
-)
-,
-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)
-
-AC_TRY_COMPILE(
-[
-#undef _REENTRANT
-#define _REENTRANT
-#undef __USE_MISC
-#define __USE_MISC
-#include <unistd.h>
-#include <netdb.h>
-int innetgr(const char *netgroup, const char *host, const char *user, const char *domain);
-]
-,,
-[
-INNETGR_ARGS="#undef INNETGR_ARGS"
-]
-,
-AC_TRY_COMPILE(
-[
-#undef _REENTRANT
-#define _REENTRANT
-#undef __USE_MISC
-#define __USE_MISC
-#include <unistd.h>
-#include <netdb.h>
-int innetgr(char *netgroup, char *host, char *user, char *domain);
-]
-,,
-[
-INNETGR_ARGS="#define INNETGR_ARGS char *netgroup, char *host, char *user, char *domain"
-]
-,
-))
-
-AC_TRY_COMPILE(
-[
-#undef _REENTRANT
-#define _REENTRANT
-#undef __USE_MISC
-#define __USE_MISC
-#include <unistd.h>
-#include <netdb.h>
-void setnetgrent(const char *);
-]
-,,
-[
-SETNETGRENT_ARGS="#undef SETNETGRENT_ARGS"
-]
-,
-AC_TRY_COMPILE(
-[
-#undef _REENTRANT
-#define _REENTRANT
-#undef __USE_MISC
-#define __USE_MISC
-#include <unistd.h>
-#include <netdb.h>
-void setnetgrent(char *);
-]
-,,
-[
-SETNETGRENT_ARGS="#define SETNETGRENT_ARGS char *netgroup"
-]
-,
-))
-AC_SUBST(SETNETGRENT_ARGS)
-AC_SUBST(INNETGR_ARGS)
-
-#
-# Random remaining OS-specific issues involving compiler warnings.
-# XXXDCL print messages to indicate some compensation is being done?
-#
-BROKEN_IN6ADDR_INIT_MACROS="#undef BROKEN_IN6ADDR_INIT_MACROS"
-
-case "$host" in
-	*-aix5.1.*)
-		hack_shutup_pthreadmutexinit=yes
-		hack_shutup_in6addr_init_macros=yes
-		;;
-	*-aix5.[[23]].*)
-		hack_shutup_in6addr_init_macros=yes
-		;;
-	*-bsdi3.1*)
-		hack_shutup_sputaux=yes
-		;;
-	*-bsdi4.0*)
-		hack_shutup_sigwait=yes
-		hack_shutup_sputaux=yes
-		hack_shutup_in6addr_init_macros=yes
-		;;
-	*-bsdi4.1*)
-		hack_shutup_stdargcast=yes
-		;;
-	*-hpux11.11)
-		hack_shutup_in6addr_init_macros=yes
-		;;
-	*-osf5.1|*-osf5.1b)
-		hack_shutup_in6addr_init_macros=yes
-		;;
-	*-solaris2.8)
-		hack_shutup_in6addr_init_macros=yes
-		;;
-	*-solaris2.9)
-		hack_shutup_in6addr_init_macros=yes
-		;;
-	*-solaris2.1[[0-9]])
-		hack_shutup_in6addr_init_macros=yes
-		;;
-esac
-
-case "$hack_shutup_pthreadmutexinit" in
-	yes)
-		#
-		# Shut up PTHREAD_MUTEX_INITIALIZER unbraced
-		# initializer warnings.
-		#
-		AC_DEFINE(SHUTUP_MUTEX_INITIALIZER)
-		;;
-esac
-
-case "$hack_shutup_sigwait" in
-	yes)
-		#
-		# Shut up a -Wmissing-prototypes warning for sigwait().
-		#
-		AC_DEFINE(SHUTUP_SIGWAIT)
-		;;
-esac
-
-case "$hack_shutup_sputaux" in
-	yes)
-		#
-		# Shut up a -Wmissing-prototypes warning from <stdio.h>.
-		#
-		AC_DEFINE(SHUTUP_SPUTAUX)
-		;;
-esac
-
-case "$hack_shutup_stdargcast" in
-	yes)
-		#
-		# Shut up a -Wcast-qual warning from va_start().
-		#
-		AC_DEFINE(SHUTUP_STDARG_CAST)
-		;;
-esac
-
-case "$hack_shutup_in6addr_init_macros" in
-	yes)
-		AC_DEFINE(BROKEN_IN6ADDR_INIT_MACROS, 1, [Defined if IN6ADDR_ANY_INIT and IN6ADDR_LOOPBACK_INIT need to be redefined.] )
-		;;
-esac
-
-#
-# Substitutions
-#
-AC_SUBST(BIND9_TOP_BUILDDIR)
-BIND9_TOP_BUILDDIR=`pwd`
-
-AC_SUBST_FILE(BIND9_INCLUDES)
-BIND9_INCLUDES=$BIND9_TOP_BUILDDIR/make/includes
-
-AC_SUBST_FILE(BIND9_MAKE_RULES)
-BIND9_MAKE_RULES=$BIND9_TOP_BUILDDIR/make/rules
-
-. $srcdir/../../version
-BIND9_VERSION="VERSION=${MAJORVER}.${MINORVER}.${PATCHVER}${RELEASETYPE}${RELEASEVER}"
-AC_SUBST(BIND9_VERSION)
-
-AC_SUBST_FILE(LIBBIND_API)
-LIBBIND_API=$srcdir/api
-
-AC_OUTPUT(
-	make/rules
-	make/mkdep
-	make/includes
-	Makefile
-	bsd/Makefile
-	dst/Makefile
-	include/Makefile
-	inet/Makefile
-	irs/Makefile
-	isc/Makefile
-	nameser/Makefile
-	port_after.h
-	port_before.h
-	resolv/Makefile
-	port/Makefile
-	${PORT_DIR}/Makefile
-	${PORT_INCLUDE}/Makefile
-	include/isc/platform.h
-)
-
-# Tell Emacs to edit this file in shell mode.
-# Local Variables:
-# mode: sh
-# End:
diff --git a/contrib/bind9/lib/bind/dst/Makefile.in b/contrib/bind9/lib/bind/dst/Makefile.in
deleted file mode 100644
index a841d49..0000000
--- a/contrib/bind9/lib/bind/dst/Makefile.in
+++ /dev/null
@@ -1,32 +0,0 @@
-# Copyright (C) 2004, 2008  Internet Systems Consortium, Inc. ("ISC")
-# Copyright (C) 2001  Internet Software Consortium.
-#
-# Permission to use, copy, modify, and/or 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: Makefile.in,v 1.6.18.2 2008/03/20 23:46:01 tbox Exp $
- 
-srcdir=		@srcdir@
-VPATH =         @srcdir@
-
-OBJS=	dst_api.@O@ hmac_link.@O@ md5_dgst.@O@ support.@O@
-
-SRCS=	dst_api.c hmac_link.c md5_dgst.c support.c
-
-TARGETS= ${OBJS}
-
-CRYPTFLAGS=     -DCYLINK_DSS -DHMAC_MD5 -DUSE_MD5 -DDNSSAFE
-
-CINCLUDES= -I.. -I../include -I${srcdir}/../include ${CRYPTINCL}
-CDEFINES= ${CRYPTFLAGS}
-
-@BIND9_MAKE_RULES@
diff --git a/contrib/bind9/lib/bind/dst/dst_api.c b/contrib/bind9/lib/bind/dst/dst_api.c
deleted file mode 100644
index 5bcd80a..0000000
--- a/contrib/bind9/lib/bind/dst/dst_api.c
+++ /dev/null
@@ -1,1048 +0,0 @@
-#ifndef LINT
-static const char rcsid[] = "$Header: /proj/cvs/prod/bind9/lib/bind/dst/Attic/dst_api.c,v 1.10.332.7 2007/09/26 04:41:47 each Exp $";
-#endif
-
-/*
- * Portions Copyright (c) 1995-1998 by Trusted Information Systems, 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 TRUSTED INFORMATION SYSTEMS
- * DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS.  IN NO EVENT SHALL
- * TRUSTED INFORMATION SYSTEMS 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 THE SOFTWARE.
- */
-/*
- * This file contains the interface between the DST API and the crypto API.
- * This is the only file that needs to be changed if the crypto system is
- * changed.  Exported functions are:
- * void dst_init()	 Initialize the toolkit
- * int  dst_check_algorithm()   Function to determines if alg is suppored.
- * int  dst_compare_keys()      Function to compare two keys for equality.
- * int  dst_sign_data()         Incremental signing routine.
- * int  dst_verify_data()       Incremental verify routine.
- * int  dst_generate_key()      Function to generate new KEY
- * DST_KEY *dst_read_key()      Function to retrieve private/public KEY.
- * void dst_write_key()         Function to write out a key.
- * DST_KEY *dst_dnskey_to_key() Function to convert DNS KEY RR to a DST
- *				KEY structure.
- * int dst_key_to_dnskey() 	Function to return a public key in DNS 
- *				format binary
- * DST_KEY *dst_buffer_to_key() Converst a data in buffer to KEY
- * int *dst_key_to_buffer()	Writes out DST_KEY key matterial in buffer
- * void dst_free_key()       	Releases all memory referenced by key structure
- */
-
-#include "port_before.h"
-#include <stdio.h>
-#include <errno.h>
-#include <fcntl.h>
-#include <stdlib.h>
-#include <unistd.h>
-#include <string.h>
-#include <memory.h>
-#include <ctype.h>
-#include <time.h>
-#include <sys/param.h>
-#include <sys/stat.h>
-#include <sys/socket.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <resolv.h>
-
-#include "dst_internal.h"
-#include "port_after.h"
-
-/* static variables */
-static int done_init = 0;
-dst_func *dst_t_func[DST_MAX_ALGS];
-const char *key_file_fmt_str = "Private-key-format: v%s\nAlgorithm: %d (%s)\n";
-const char *dst_path = "";
-
-/* internal I/O functions */
-static DST_KEY *dst_s_read_public_key(const char *in_name, 
-				      const u_int16_t in_id, int in_alg);
-static int dst_s_read_private_key_file(char *name, DST_KEY *pk_key,
-				       u_int16_t in_id, int in_alg);
-static int dst_s_write_public_key(const DST_KEY *key);
-static int dst_s_write_private_key(const DST_KEY *key);
-
-/* internal function to set up data structure */
-static DST_KEY *dst_s_get_key_struct(const char *name, const int alg,
-				     const int flags, const int protocol,
-				     const int bits);
-
-/*%
- *  dst_init
- *	This function initializes the Digital Signature Toolkit.
- *	Right now, it just checks the DSTKEYPATH environment variable.
- *  Parameters
- *	none
- *  Returns
- *	none
- */
-void
-dst_init()
-{
-	char *s;
-	int len;
-
-	if (done_init != 0)
-		return;
-	done_init = 1;
-
-	s = getenv("DSTKEYPATH");
-	len = 0;
-	if (s) {
-		struct stat statbuf;
-
-		len = strlen(s);
-		if (len > PATH_MAX) {
-			EREPORT(("%s is longer than %d characters, ignoring\n",
-				 s, PATH_MAX));
-		} else if (stat(s, &statbuf) != 0 || !S_ISDIR(statbuf.st_mode)) {
-			EREPORT(("%s is not a valid directory\n", s));
-		} else {
-			char *tmp;
-			tmp = (char *) malloc(len + 2);
-			memcpy(tmp, s, len + 1);
-			if (tmp[strlen(tmp) - 1] != '/') {
-				tmp[strlen(tmp) + 1] = 0;
-				tmp[strlen(tmp)] = '/';
-			}
-			dst_path = tmp;
-		}
-	}
-	memset(dst_t_func, 0, sizeof(dst_t_func));
-	/* first one is selected */
-	dst_hmac_md5_init();
-}
-
-/*%
- *  dst_check_algorithm
- *	This function determines if the crypto system for the specified
- *	algorithm is present.
- *  Parameters
- *	alg     1       KEY_RSA
- *		3       KEY_DSA
- *	      157     KEY_HMAC_MD5
- *		      future algorithms TBD and registered with IANA.
- *  Returns
- *	1 - The algorithm is available.
- *	0 - The algorithm is not available.
- */
-int
-dst_check_algorithm(const int alg)
-{
-	return (dst_t_func[alg] != NULL);
-}
-
-/*%
- * dst_s_get_key_struct 
- *	This function allocates key structure and fills in some of the 
- *	fields of the structure. 
- * Parameters: 
- *	name:     the name of the key 
- *	alg:      the algorithm number 
- *	flags:    the dns flags of the key
- *	protocol: the dns protocol of the key
- *	bits:     the size of the key
- * Returns:
- *       NULL if error
- *       valid pointer otherwise
- */
-static DST_KEY *
-dst_s_get_key_struct(const char *name, const int alg, const int flags,
-		     const int protocol, const int bits)
-{
-	DST_KEY *new_key = NULL; 
-
-	if (dst_check_algorithm(alg)) /*%< make sure alg is available */
-		new_key = (DST_KEY *) malloc(sizeof(*new_key));
-	if (new_key == NULL)
-		return (NULL);
-
-	memset(new_key, 0, sizeof(*new_key));
-	new_key->dk_key_name = strdup(name);
-	if (new_key->dk_key_name == NULL) {
-		free(new_key);
-		return (NULL);
-	}
-	new_key->dk_alg = alg;
-	new_key->dk_flags = flags;
-	new_key->dk_proto = protocol;
-	new_key->dk_KEY_struct = NULL;
-	new_key->dk_key_size = bits;
-	new_key->dk_func = dst_t_func[alg];
-	return (new_key);
-}
-
-/*%
- *  dst_compare_keys
- *	Compares two keys for equality.
- *  Parameters
- *	key1, key2      Two keys to be compared.
- *  Returns
- *	0	       The keys are equal.
- *	non-zero	The keys are not equal.
- */
-
-int
-dst_compare_keys(const DST_KEY *key1, const DST_KEY *key2)
-{
-	if (key1 == key2)
-		return (0);
-	if (key1 == NULL || key2 == NULL)
-		return (4);
-	if (key1->dk_alg != key2->dk_alg)
-		return (1);
-	if (key1->dk_key_size != key2->dk_key_size)
-		return (2);
-	if (key1->dk_id != key2->dk_id)
-		return (3);
-	return (key1->dk_func->compare(key1, key2));
-}
-
-/*%
- * dst_sign_data
- *	An incremental signing function.  Data is signed in steps.
- *	First the context must be initialized (SIG_MODE_INIT).
- *	Then data is hashed (SIG_MODE_UPDATE).  Finally the signature
- *	itself is created (SIG_MODE_FINAL).  This function can be called
- *	once with INIT, UPDATE and FINAL modes all set, or it can be
- *	called separately with a different mode set for each step.  The
- *	UPDATE step can be repeated.
- * Parameters
- *	mode    A bit mask used to specify operation(s) to be performed.
- *		  SIG_MODE_INIT	   1   Initialize digest
- *		  SIG_MODE_UPDATE	 2   Add data to digest
- *		  SIG_MODE_FINAL	  4   Generate signature
- *					      from signature
- *		  SIG_MODE_ALL (SIG_MODE_INIT,SIG_MODE_UPDATE,SIG_MODE_FINAL
- *	data    Data to be signed.
- *	len     The length in bytes of data to be signed.
- *	in_key  Contains a private key to sign with.
- *		  KEY structures should be handled (created, converted,
- *		  compared, stored, freed) by the DST.
- *	signature
- *	      The location to which the signature will be written.
- *	sig_len Length of the signature field in bytes.
- * Return
- *	 0      Successfull INIT or Update operation
- *	&gt;0      success FINAL (sign) operation
- *	&lt;0      failure
- */
-
-int
-dst_sign_data(const int mode, DST_KEY *in_key, void **context, 
-	      const u_char *data, const int len,
-	      u_char *signature, const int sig_len)
-{
-	DUMP(data, mode, len, "dst_sign_data()");
-
-	if (mode & SIG_MODE_FINAL &&
-	    (in_key->dk_KEY_struct == NULL || signature == NULL))
-		return (MISSING_KEY_OR_SIGNATURE);
-
-	if (in_key->dk_func && in_key->dk_func->sign)
-		return (in_key->dk_func->sign(mode, in_key, context, data, len,
-					      signature, sig_len));
-	return (UNKNOWN_KEYALG);
-}
-
-/*%
- *  dst_verify_data
- *	An incremental verify function.  Data is verified in steps.
- *	First the context must be initialized (SIG_MODE_INIT).
- *	Then data is hashed (SIG_MODE_UPDATE).  Finally the signature
- *	is verified (SIG_MODE_FINAL).  This function can be called
- *	once with INIT, UPDATE and FINAL modes all set, or it can be
- *	called separately with a different mode set for each step.  The
- *	UPDATE step can be repeated.
- *  Parameters
- *	mode	Operations to perform this time.
- *		      SIG_MODE_INIT       1   Initialize digest
- *		      SIG_MODE_UPDATE     2   add data to digest
- *		      SIG_MODE_FINAL      4   verify signature
- *		      SIG_MODE_ALL
- *			  (SIG_MODE_INIT,SIG_MODE_UPDATE,SIG_MODE_FINAL)
- *	data	Data to pass through the hash function.
- *	len	 Length of the data in bytes.
- *	in_key      Key for verification.
- *	signature   Location of signature.
- *	sig_len     Length of the signature in bytes.
- *  Returns
- *	0	   Verify success
- *	Non-Zero    Verify Failure
- */
-
-int
-dst_verify_data(const int mode, DST_KEY *in_key, void **context, 
-		const u_char *data, const int len,
-		const u_char *signature, const int sig_len)
-{
-	DUMP(data, mode, len, "dst_verify_data()");
-	if (mode & SIG_MODE_FINAL &&
-	    (in_key->dk_KEY_struct == NULL || signature == NULL))
-		return (MISSING_KEY_OR_SIGNATURE);
-
-	if (in_key->dk_func == NULL || in_key->dk_func->verify == NULL)
-		return (UNSUPPORTED_KEYALG);
-	return (in_key->dk_func->verify(mode, in_key, context, data, len,
-					signature, sig_len));
-}
-
-/*%
- *  dst_read_private_key
- *	Access a private key.  First the list of private keys that have
- *	already been read in is searched, then the key accessed on disk.
- *	If the private key can be found, it is returned.  If the key cannot
- *	be found, a null pointer is returned.  The options specify required
- *	key characteristics.  If the private key requested does not have
- *	these characteristics, it will not be read.
- *  Parameters
- *	in_keyname  The private key name.
- *	in_id	    The id of the private key.
- *	options     DST_FORCE_READ  Read from disk - don't use a previously
- *				      read key.
- *		  DST_CAN_SIGN    The key must be useable for signing.
- *		  DST_NO_AUTHEN   The key must be useable for authentication.
- *		  DST_STANDARD    Return any key 
- *  Returns
- *	NULL	If there is no key found in the current directory or
- *		      this key has not been loaded before.
- *	!NULL       Success - KEY structure returned.
- */
-
-DST_KEY *
-dst_read_key(const char *in_keyname, const u_int16_t in_id, 
-	     const int in_alg, const int type)
-{
-	char keyname[PATH_MAX];
-	DST_KEY *dg_key = NULL, *pubkey = NULL;
-
-	if (!dst_check_algorithm(in_alg)) { /*%< make sure alg is available */
-		EREPORT(("dst_read_private_key(): Algorithm %d not suppored\n",
-			 in_alg));
-		return (NULL);
-	}
-	if ((type & (DST_PUBLIC | DST_PRIVATE)) == 0) 
-		return (NULL);
-	if (in_keyname == NULL) {
-		EREPORT(("dst_read_private_key(): Null key name passed in\n"));
-		return (NULL);
-	} 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 */
-	if ((pubkey = dst_s_read_public_key(keyname, in_id, in_alg)) == NULL)
-		return (NULL);
-
-	if (type == DST_PUBLIC) 
-		return pubkey; 
-
-	if (!(dg_key = dst_s_get_key_struct(keyname, pubkey->dk_alg,
-					    pubkey->dk_flags, pubkey->dk_proto,
-					    0)))
-		return (dg_key);
-	/* Fill in private key and some fields in the general key structure */
-	if (dst_s_read_private_key_file(keyname, dg_key, pubkey->dk_id,
-					pubkey->dk_alg) == 0)
-		dg_key = dst_free_key(dg_key);
-
-	(void)dst_free_key(pubkey);
-	return (dg_key);
-}
-
-int 
-dst_write_key(const DST_KEY *key, const int type)
-{
-	int pub = 0, priv = 0;
-
-	if (key == NULL) 
-		return (0);
-	if (!dst_check_algorithm(key->dk_alg)) { /*%< make sure alg is available */
-		EREPORT(("dst_write_key(): Algorithm %d not suppored\n", 
-			 key->dk_alg));
-		return (UNSUPPORTED_KEYALG);
-	}
-	if ((type & (DST_PRIVATE|DST_PUBLIC)) == 0)
-		return (0);
-
-	if (type & DST_PUBLIC) 
-		if ((pub = dst_s_write_public_key(key)) < 0)
-			return (pub);
-	if (type & DST_PRIVATE)
-		if ((priv = dst_s_write_private_key(key)) < 0)
-			return (priv);
-	return (priv+pub);
-}
-
-/*%
- *  dst_write_private_key
- *	Write a private key to disk.  The filename will be of the form:
- *	K&lt;key-&gt;dk_name&gt;+&lt;key-&gt;dk_alg+&gt;&lt;key-d&gt;k_id.&gt;&lt;private key suffix&gt;.
- *	If there is already a file with this name, an error is returned.
- *
- *  Parameters
- *	key     A DST managed key structure that contains
- *	      all information needed about a key.
- *  Return
- *	&gt;= 0    Correct behavior.  Returns length of encoded key value
- *		  written to disk.
- *	&lt;  0    error.
- */
-
-static int
-dst_s_write_private_key(const DST_KEY *key)
-{
-	u_char encoded_block[RAW_KEY_SIZE];
-	char file[PATH_MAX];
-	int len;
-	FILE *fp;
-
-	/* First encode the key into the portable key format */
-	if (key == NULL)
-		return (-1);
-	if (key->dk_KEY_struct == NULL)
-		return (0);	/*%< null key has no private key */
-	if (key->dk_func == NULL || key->dk_func->to_file_fmt == NULL) {
-		EREPORT(("dst_write_private_key(): Unsupported operation %d\n",
-			 key->dk_alg));
-		return (-5);
-	} else if ((len = key->dk_func->to_file_fmt(key, (char *)encoded_block,
-					     sizeof(encoded_block))) <= 0) {
-		EREPORT(("dst_write_private_key(): Failed encoding private RSA bsafe key %d\n", len));
-		return (-8);
-	}
-	/* Now I can create the file I want to use */
-	dst_s_build_filename(file, key->dk_key_name, key->dk_id, key->dk_alg,
-			     PRIVATE_KEY, PATH_MAX);
-
-	/* Do not overwrite an existing file */
-	if ((fp = dst_s_fopen(file, "w", 0600)) != NULL) {
-		int nn;
-		if ((nn = fwrite(encoded_block, 1, len, fp)) != len) {
-			EREPORT(("dst_write_private_key(): Write failure on %s %d != %d errno=%d\n",
-				 file, len, nn, errno));
-			fclose(fp);
-			return (-5);
-		}
-		fclose(fp);
-	} else {
-		EREPORT(("dst_write_private_key(): Can not create file %s\n"
-			 ,file));
-		return (-6);
-	}
-	memset(encoded_block, 0, len);
-	return (len);
-}
-
-/*%
-*
- *  dst_read_public_key
- *	Read a public key from disk and store in a DST key structure.
- *  Parameters
- *	in_name	 K&lt;in_name&gt;&lt;in_id&gt;.&lt;public key suffix&gt; is the
- *		      filename of the key file to be read.
- *  Returns
- *	NULL	    If the key does not exist or no name is supplied.
- *	NON-NULL	Initialized key structure if the key exists.
- */
-
-static DST_KEY *
-dst_s_read_public_key(const char *in_name, const u_int16_t in_id, int in_alg)
-{
-	int flags, proto, alg, len, dlen;
-	int c;
-	char name[PATH_MAX], enckey[RAW_KEY_SIZE], *notspace;
-	u_char deckey[RAW_KEY_SIZE];
-	FILE *fp;
-
-	if (in_name == NULL) {
-		EREPORT(("dst_read_public_key(): No key name given\n"));
-		return (NULL);
-	}
-	if (dst_s_build_filename(name, in_name, in_id, in_alg, PUBLIC_KEY,
-				 PATH_MAX) == -1) {
-		EREPORT(("dst_read_public_key(): Cannot make filename from %s, %d, and %s\n",
-			 in_name, in_id, PUBLIC_KEY));
-		return (NULL);
-	}
-	/*
-	 * Open the file and read it's formatted contents up to key
-	 * File format:
-	 *    domain.name [ttl] [IN] KEY  &lt;flags&gt; &lt;protocol&gt; &lt;algorithm&gt; &lt;key&gt;
-	 * flags, proto, alg stored as decimal (or hex numbers FIXME).
-	 * (FIXME: handle parentheses for line continuation.)
-	 */
-	if ((fp = dst_s_fopen(name, "r", 0)) == NULL) {
-		EREPORT(("dst_read_public_key(): Public Key not found %s\n",
-			 name));
-		return (NULL);
-	}
-	/* Skip domain name, which ends at first blank */
-	while ((c = getc(fp)) != EOF)
-		if (isspace(c))
-			break;
-	/* Skip blank to get to next field */
-	while ((c = getc(fp)) != EOF)
-		if (!isspace(c))
-			break;
-
-	/* Skip optional TTL -- if initial digit, skip whole word. */
-	if (isdigit(c)) {
-		while ((c = getc(fp)) != EOF)
-			if (isspace(c))
-				break;
-		while ((c = getc(fp)) != EOF)
-			if (!isspace(c))
-				break;
-	}
-	/* Skip optional "IN" */
-	if (c == 'I' || c == 'i') {
-		while ((c = getc(fp)) != EOF)
-			if (isspace(c))
-				break;
-		while ((c = getc(fp)) != EOF)
-			if (!isspace(c))
-				break;
-	}
-	/* Locate and skip "KEY" */
-	if (c != 'K' && c != 'k') {
-		EREPORT(("\"KEY\" doesn't appear in file: %s", name));
-		return NULL;
-	}
-	while ((c = getc(fp)) != EOF)
-		if (isspace(c))
-			break;
-	while ((c = getc(fp)) != EOF)
-		if (!isspace(c))
-			break;
-	ungetc(c, fp);		/*%< return the charcter to the input field */
-	/* Handle hex!! FIXME.  */
-
-	if (fscanf(fp, "%d %d %d", &flags, &proto, &alg) != 3) {
-		EREPORT(("dst_read_public_key(): Can not read flag/proto/alg field from %s\n"
-			 ,name));
-		return (NULL);
-	}
-	/* read in the key string */
-	fgets(enckey, sizeof(enckey), fp);
-
-	/* If we aren't at end-of-file, something is wrong.  */
-	while ((c = getc(fp)) != EOF)
-		if (!isspace(c))
-			break;
-	if (!feof(fp)) {
-		EREPORT(("Key too long in file: %s", name));
-		return NULL;
-	}
-	fclose(fp);
-
-	if ((len = strlen(enckey)) <= 0)
-		return (NULL);
-
-	/* discard \n */
-	enckey[--len] = '\0';
-
-	/* remove leading spaces */
-	for (notspace = (char *) enckey; isspace((*notspace)&0xff); len--)
-		notspace++;
-
-	dlen = b64_pton(notspace, deckey, sizeof(deckey));
-	if (dlen < 0) {
-		EREPORT(("dst_read_public_key: bad return from b64_pton = %d",
-			 dlen));
-		return (NULL);
-	}
-	/* store key and info in a key structure that is returned */
-/*	return dst_store_public_key(in_name, alg, proto, 666, flags, deckey,
-				    dlen);*/
-	return dst_buffer_to_key(in_name, alg, flags, proto, deckey, dlen);
-}
-
-/*%
- *  dst_write_public_key
- *	Write a key to disk in DNS format.
- *  Parameters
- *	key     Pointer to a DST key structure.
- *  Returns
- *	0       Failure
- *	1       Success
- */
-
-static int
-dst_s_write_public_key(const DST_KEY *key)
-{
-	FILE *fp;
-	char filename[PATH_MAX];
-	u_char out_key[RAW_KEY_SIZE];
-	char enc_key[RAW_KEY_SIZE];
-	int len = 0;
-	int mode;
-
-	memset(out_key, 0, sizeof(out_key));
-	if (key == NULL) {
-		EREPORT(("dst_write_public_key(): No key specified \n"));
-		return (0);
-	} else if ((len = dst_key_to_dnskey(key, out_key, sizeof(out_key)))< 0)
-		return (0);
-
-	/* Make the filename */
-	if (dst_s_build_filename(filename, key->dk_key_name, key->dk_id,
-				 key->dk_alg, PUBLIC_KEY, PATH_MAX) == -1) {
-		EREPORT(("dst_write_public_key(): Cannot make filename from %s, %d, and %s\n",
-			 key->dk_key_name, key->dk_id, PUBLIC_KEY));
-		return (0);
-	}
-	/* XXX in general this should be a check for symmetric keys */
-	mode = (key->dk_alg == KEY_HMAC_MD5) ? 0600 : 0644;
-	/* create public key file */
-	if ((fp = dst_s_fopen(filename, "w+", mode)) == NULL) {
-		EREPORT(("DST_write_public_key: open of file:%s failed (errno=%d)\n",
-			 filename, errno));
-		return (0);
-	}
-	/*write out key first base64 the key data */
-	if (key->dk_flags & DST_EXTEND_FLAG)
-		b64_ntop(&out_key[6], len - 6, enc_key, sizeof(enc_key));
-	else
-		b64_ntop(&out_key[4], len - 4, enc_key, sizeof(enc_key));
-	fprintf(fp, "%s IN KEY %d %d %d %s\n",
-		key->dk_key_name,
-		key->dk_flags, key->dk_proto, key->dk_alg, enc_key);
-	fclose(fp);
-	return (1);
-}
-
-/*%
- *  dst_dnskey_to_public_key
- *	This function converts the contents of a DNS KEY RR into a DST
- *	key structure.
- *  Paramters
- *	len	 Length of the RDATA of the KEY RR RDATA
- *	rdata	 A pointer to the the KEY RR RDATA.
- *	in_name     Key name to be stored in key structure.
- *  Returns
- *	NULL	    Failure
- *	NON-NULL	Success.  Pointer to key structure.
- *			Caller's responsibility to free() it.
- */
-
-DST_KEY *
-dst_dnskey_to_key(const char *in_name, const u_char *rdata, const int len)
-{
-	DST_KEY *key_st;
-	int alg ;
-	int start = DST_KEY_START;
-
-	if (rdata == NULL || len <= DST_KEY_ALG) /*%< no data */
-		return (NULL);
-	alg = (u_int8_t) rdata[DST_KEY_ALG];
-	if (!dst_check_algorithm(alg)) { /*%< make sure alg is available */
-		EREPORT(("dst_dnskey_to_key(): Algorithm %d not suppored\n",
-			 alg));
-		return (NULL);
-	}
-
-	if (in_name == NULL)
-		return (NULL);
-
-	if ((key_st = dst_s_get_key_struct(in_name, alg, 0, 0, 0)) == NULL)
-		return (NULL);
-
-	key_st->dk_id = dst_s_dns_key_id(rdata, len);
-	key_st->dk_flags = dst_s_get_int16(rdata);
-	key_st->dk_proto = (u_int16_t) rdata[DST_KEY_PROT];
-	if (key_st->dk_flags & DST_EXTEND_FLAG) {
-		u_int32_t ext_flags;
-		ext_flags = (u_int32_t) dst_s_get_int16(&rdata[DST_EXT_FLAG]);
-		key_st->dk_flags = key_st->dk_flags | (ext_flags << 16);
-		start += 2;
-	}
-	/*
-	 * now point to the begining of the data representing the encoding
-	 * of the key
-	 */
-	if (key_st->dk_func && key_st->dk_func->from_dns_key) {
-		if (key_st->dk_func->from_dns_key(key_st, &rdata[start],
-						  len - start) > 0)
-			return (key_st);
-	} else
-		EREPORT(("dst_dnskey_to_public_key(): unsuppored alg %d\n",
-			 alg));
-
-	SAFE_FREE(key_st);
-	return (key_st);
-}
-
-/*%
- *  dst_public_key_to_dnskey
- *	Function to encode a public key into DNS KEY wire format 
- *  Parameters
- *	key	     Key structure to encode.
- *	out_storage     Location to write the encoded key to.
- *	out_len	 Size of the output array.
- *  Returns
- *	<0      Failure
- *	>=0     Number of bytes written to out_storage
- */
-
-int
-dst_key_to_dnskey(const DST_KEY *key, u_char *out_storage,
-			 const int out_len)
-{
-	u_int16_t val;
-	int loc = 0;
-	int enc_len = 0;
-	if (key == NULL)
-		return (-1);
-
-	if (!dst_check_algorithm(key->dk_alg)) { /*%< make sure alg is available */
-		EREPORT(("dst_key_to_dnskey(): Algorithm %d not suppored\n",
-			 key->dk_alg));
-		return (UNSUPPORTED_KEYALG);
-	}
-	memset(out_storage, 0, out_len);
-	val = (u_int16_t)(key->dk_flags & 0xffff);
-	dst_s_put_int16(out_storage, val);
-	loc += 2;
-
-	out_storage[loc++] = (u_char) key->dk_proto;
-	out_storage[loc++] = (u_char) key->dk_alg;
-
-	if (key->dk_flags > 0xffff) {	/*%< Extended flags */
-		val = (u_int16_t)((key->dk_flags >> 16) & 0xffff);
-		dst_s_put_int16(&out_storage[loc], val);
-		loc += 2;
-	}
-	if (key->dk_KEY_struct == NULL)
-		return (loc);
-	if (key->dk_func && key->dk_func->to_dns_key) {
-		enc_len = key->dk_func->to_dns_key(key,
-						 (u_char *) &out_storage[loc],
-						   out_len - loc);
-		if (enc_len > 0)
-			return (enc_len + loc);
-		else
-			return (-1);
-	} else
-		EREPORT(("dst_key_to_dnskey(): Unsupported ALG %d\n",
-			 key->dk_alg));
-	return (-1);
-}
-
-/*%
- *  dst_buffer_to_key
- *	Function to encode a string of raw data into a DST key
- *  Parameters
- *	alg		The algorithm (HMAC only)
- *	key		A pointer to the data
- *	keylen		The length of the data
- *  Returns
- *	NULL	    an error occurred
- *	NON-NULL	the DST key
- */
-DST_KEY *
-dst_buffer_to_key(const char *key_name,		/*!< name of the key  */
-		  const int alg,		/*!< algorithm  */
-		  const int flags,		/*!< dns flags  */
-		  const int protocol,		/*!< dns protocol  */
-		  const u_char *key_buf,	/*!< key in dns wire fmt  */
-		  const int key_len)		/*!< size of key  */
-{
-	
-	DST_KEY *dkey = NULL; 
-	int dnslen;
-	u_char dns[2048];
-
-	if (!dst_check_algorithm(alg)) { /*%< make sure alg is available */
-		EREPORT(("dst_buffer_to_key(): Algorithm %d not suppored\n", alg));
-		return (NULL);
-	}
-
-	dkey = dst_s_get_key_struct(key_name, alg, flags, protocol, -1);
-
-	if (dkey == NULL || dkey->dk_func == NULL ||
-	    dkey->dk_func->from_dns_key == NULL) 
-		return (dst_free_key(dkey));
-
-	if (dkey->dk_func->from_dns_key(dkey, key_buf, key_len) < 0) {
-		EREPORT(("dst_buffer_to_key(): dst_buffer_to_hmac failed\n"));
-		return (dst_free_key(dkey));
-	}
-
-	dnslen = dst_key_to_dnskey(dkey, dns, sizeof(dns));
-	dkey->dk_id = dst_s_dns_key_id(dns, dnslen);
-	return (dkey);
-}
-
-int 
-dst_key_to_buffer(DST_KEY *key, u_char *out_buff, int buf_len)
-{
-	int len;
-  /* this function will extrac the secret of HMAC into a buffer */
-	if (key == NULL) 
-		return (0);
-	if (key->dk_func != NULL && key->dk_func->to_dns_key != NULL) {
-		len = key->dk_func->to_dns_key(key, out_buff, buf_len);
-		if (len < 0)
-			return (0);
-		return (len);
-	}
-	return (0);
-}
-
-/*%
- * dst_s_read_private_key_file
- *     Function reads in private key from a file.
- *     Fills out the KEY structure.
- * Parameters
- *     name    Name of the key to be read.
- *     pk_key  Structure that the key is returned in.
- *     in_id   Key identifier (tag)
- * Return
- *     1 if everthing works
- *     0 if there is any problem
- */
-
-static int
-dst_s_read_private_key_file(char *name, DST_KEY *pk_key, u_int16_t in_id,
-			    int in_alg)
-{
-	int cnt, alg, len, major, minor, file_major, file_minor;
-	int ret, id;
-	char filename[PATH_MAX];
-	u_char in_buff[RAW_KEY_SIZE], *p;
-	FILE *fp;
-	int dnslen;
-	u_char dns[2048];
-
-	if (name == NULL || pk_key == NULL) {
-		EREPORT(("dst_read_private_key_file(): No key name given\n"));
-		return (0);
-	}
-	/* Make the filename */
-	if (dst_s_build_filename(filename, name, in_id, in_alg, PRIVATE_KEY,
-				 PATH_MAX) == -1) {
-		EREPORT(("dst_read_private_key(): Cannot make filename from %s, %d, and %s\n",
-			 name, in_id, PRIVATE_KEY));
-		return (0);
-	}
-	/* first check if we can find the key file */
-	if ((fp = dst_s_fopen(filename, "r", 0)) == NULL) {
-		EREPORT(("dst_s_read_private_key_file: Could not open file %s in directory %s\n",
-			 filename, dst_path[0] ? dst_path :
-			 (char *) getcwd(NULL, PATH_MAX - 1)));
-		return (0);
-	}
-	/* now read the header info from the file */
-	if ((cnt = fread(in_buff, 1, sizeof(in_buff), fp)) < 5) {
-		fclose(fp);
-		EREPORT(("dst_s_read_private_key_file: error reading file %s (empty file)\n",
-			 filename));
-		return (0);
-	}
-	/* decrypt key */
-	fclose(fp);
-	if (memcmp(in_buff, "Private-key-format: v", 20) != 0)
-		goto fail;
-	len = cnt;
-	p = in_buff;
-
-	if (!dst_s_verify_str((const char **) (void *)&p,
-			       "Private-key-format: v")) {
-		EREPORT(("dst_s_read_private_key_file(): Not a Key file/Decrypt failed %s\n", name));
-		goto fail;
-	}
-	/* read in file format */
-	sscanf((char *)p, "%d.%d", &file_major, &file_minor);
-	sscanf(KEY_FILE_FORMAT, "%d.%d", &major, &minor);
-	if (file_major < 1) {
-		EREPORT(("dst_s_read_private_key_file(): Unknown keyfile %d.%d version for %s\n",
-			 file_major, file_minor, name));
-		goto fail;
-	} else if (file_major > major || file_minor > minor)
-		EREPORT((
-				"dst_s_read_private_key_file(): Keyfile %s version higher than mine %d.%d MAY FAIL\n",
-				name, file_major, file_minor));
-
-	while (*p++ != '\n') ;	/*%< skip to end of line */
-
-	if (!dst_s_verify_str((const char **) (void *)&p, "Algorithm: "))
-		goto fail;
-
-	if (sscanf((char *)p, "%d", &alg) != 1)
-		goto fail;
-	while (*p++ != '\n') ;	/*%< skip to end of line */
-
-	if (pk_key->dk_key_name && !strcmp(pk_key->dk_key_name, name))
-		SAFE_FREE2(pk_key->dk_key_name, strlen(pk_key->dk_key_name));
-	pk_key->dk_key_name = (char *) strdup(name);
-
-	/* allocate and fill in key structure */
-	if (pk_key->dk_func == NULL || pk_key->dk_func->from_file_fmt == NULL)
-		goto fail;
-
-	ret = pk_key->dk_func->from_file_fmt(pk_key, (char *)p, &in_buff[len] - p);
-	if (ret < 0)
-		goto fail;
-
-	dnslen = dst_key_to_dnskey(pk_key, dns, sizeof(dns));
-	id = dst_s_dns_key_id(dns, dnslen);
-
-	/* Make sure the actual key tag matches the input tag used in the filename
-	 */
-	if (id != in_id) {
-		EREPORT(("dst_s_read_private_key_file(): actual tag of key read %d != input tag used to build filename %d.\n", id, in_id));
-		goto fail;
-	}
-	pk_key->dk_id = (u_int16_t) id;
-	pk_key->dk_alg = alg;
-	memset(in_buff, 0, cnt);
-	return (1);
-
- fail:
-	memset(in_buff, 0, cnt);
-	return (0);
-}
-
-/*%
- *	Generate and store a public/private keypair.
- *	Keys will be stored in formatted files.
- *
- *  Parameters
- &
- *\par	name    Name of the new key.  Used to create key files
- *\li		  K&lt;name&gt;+&lt;alg&gt;+&lt;id&gt;.public and K&lt;name&gt;+&lt;alg&gt;+&lt;id&gt;.private.
- *\par	bits    Size of the new key in bits.
- *\par	exp     What exponent to use:
- *\li		  0	   use exponent 3
- *\li		  non-zero    use Fermant4
- *\par	flags   The default value of the DNS Key flags.
- *\li		  The DNS Key RR Flag field is defined in RFC2065,
- *		  section 3.3.  The field has 16 bits.
- *\par	protocol
- *\li	      Default value of the DNS Key protocol field.
- *\li		  The DNS Key protocol field is defined in RFC2065,
- *		  section 3.4.  The field has 8 bits.
- *\par	alg     What algorithm to use.  Currently defined:
- *\li		  KEY_RSA       1
- *\li		  KEY_DSA       3
- *\li		  KEY_HMAC    157
- *\par	out_id The key tag is returned.
- *
- *  Return
- *\li	NULL		Failure
- *\li	non-NULL 	the generated key pair
- *			Caller frees the result, and its dk_name pointer.
- */
-DST_KEY *
-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 dnslen;
-	u_char dns[2048];
-
-	if (name == NULL)
-		return (NULL);
-
-	if (!dst_check_algorithm(alg)) { /*%< make sure alg is available */
-		EREPORT(("dst_generate_key(): Algorithm %d not suppored\n", alg));
-		return (NULL);
-	}
-
-	new_key = dst_s_get_key_struct(name, alg, flags, protocol, bits);
-	if (new_key == NULL)
-		return (NULL);
-	if (bits == 0) /*%< null key we are done */
-		return (new_key);
-	if (new_key->dk_func == NULL || new_key->dk_func->generate == NULL) {
-		EREPORT(("dst_generate_key_pair():Unsupported algorithm %d\n",
-			 alg));
-		return (dst_free_key(new_key));
-	}
-	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));
-		return (dst_free_key(new_key));
-	}
-
-	dnslen = dst_key_to_dnskey(new_key, dns, sizeof(dns));
-	if (dnslen != UNSUPPORTED_KEYALG)
-		new_key->dk_id = dst_s_dns_key_id(dns, dnslen);
-	else
-		new_key->dk_id = 0;
-
-	return (new_key);
-}
-
-/*%
- *	Release all data structures pointed to by a key structure.
- *
- *  Parameters
- *\li	f_key   Key structure to be freed.
- */
-
-DST_KEY *
-dst_free_key(DST_KEY *f_key)
-{
-
-	if (f_key == NULL)
-		return (f_key);
-	if (f_key->dk_func && f_key->dk_func->destroy)
-		f_key->dk_KEY_struct =
-			f_key->dk_func->destroy(f_key->dk_KEY_struct);
-	else {
-		EREPORT(("dst_free_key(): Unknown key alg %d\n",
-			 f_key->dk_alg));
-	}
-	if (f_key->dk_KEY_struct) {
-		free(f_key->dk_KEY_struct);
-		f_key->dk_KEY_struct = NULL;
-	}
-	if (f_key->dk_key_name)
-		SAFE_FREE(f_key->dk_key_name);
-	SAFE_FREE(f_key);
-	return (NULL);
-}
-
-/*%
- *	Return the maximim size of signature from the key specified in bytes
- *
- * Parameters
- *\li      key 
- *
- * Returns
- *  \li   bytes
- */
-int
-dst_sig_size(DST_KEY *key) {
-	switch (key->dk_alg) {
-	    case KEY_HMAC_MD5:
-		return (16);
-	    case KEY_HMAC_SHA1:
-		return (20);
-	    case KEY_RSA:
-		return (key->dk_key_size + 7) / 8;
-	    case KEY_DSA:
-		return (40);
-	    default:
-		EREPORT(("dst_sig_size(): Unknown key alg %d\n", key->dk_alg));
-		return -1;
-	}
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/dst/dst_internal.h b/contrib/bind9/lib/bind/dst/dst_internal.h
deleted file mode 100644
index e9bc6fc..0000000
--- a/contrib/bind9/lib/bind/dst/dst_internal.h
+++ /dev/null
@@ -1,155 +0,0 @@
-#ifndef DST_INTERNAL_H
-#define DST_INTERNAL_H
-
-/*
- * Portions Copyright (c) 1995-1998 by Trusted Information Systems, 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 TRUSTED INFORMATION SYSTEMS
- * DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS.  IN NO EVENT SHALL
- * TRUSTED INFORMATION SYSTEMS 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 THE SOFTWARE.
- */
-#include <limits.h>
-#include <sys/param.h>
-#if (!defined(BSD)) || (BSD < 199306)
-# include <sys/bitypes.h>
-#else
-# include <sys/types.h>
-#endif
-
-#ifndef PATH_MAX
-# ifdef POSIX_PATH_MAX
-#  define PATH_MAX POSIX_PATH_MAX
-# else
-#  define PATH_MAX 255 /*%< this is the value of POSIX_PATH_MAX */
-# endif
-#endif 
-
-typedef struct dst_key {
-	char	*dk_key_name;   /*%< name of the key */
-	int	dk_key_size;    /*%< this is the size of the key in bits */
-	int	dk_proto;       /*%< what protocols this key can be used for */
-	int	dk_alg;         /*%< algorithm number from key record */
-	u_int32_t dk_flags;     /*%< and the flags of the public key */
-	u_int16_t dk_id;        /*%< identifier of the key */
-	void	*dk_KEY_struct; /*%< pointer to key in crypto pkg fmt */
-	struct dst_func *dk_func; /*%< point to cryptto pgk specific function table */
-} DST_KEY;
-#define HAS_DST_KEY 
-
-#include <isc/dst.h>
-/* 
- * define what crypto systems are supported for RSA, 
- * BSAFE is prefered over RSAREF; only one can be set at any time
- */
-#if defined(BSAFE) && defined(RSAREF)
-# error "Cannot have both BSAFE and RSAREF defined"
-#endif
-
-/* Declare dst_lib specific constants */
-#define KEY_FILE_FORMAT "1.2"
-
-/* suffixes for key file names */
-#define PRIVATE_KEY		"private"
-#define PUBLIC_KEY		"key"
-
-/* error handling */
-#ifdef REPORT_ERRORS
-#define EREPORT(str)		printf str
-#else
-#define EREPORT(str)		(void)0
-#endif
-
-/* use our own special macro to FRRE memory */
-
-#ifndef SAFE_FREE
-#define SAFE_FREE(a) \
-do{if(a != NULL){memset(a,0, sizeof(*a)); free(a); a=NULL;}} while (0)
-#define SAFE_FREE2(a,s) if (a != NULL && (long)s > 0){memset(a,0, s);free(a); a=NULL;}
-#endif
-
-typedef struct dst_func {
-	int (*sign)(const int mode, DST_KEY *key, void **context,
-		     const u_int8_t *data, const int len,
-		     u_int8_t *signature, const int sig_len);
-	int (*verify)(const int mode, DST_KEY *key, void **context,
-		       const u_int8_t *data, const int len,
-		       const u_int8_t *signature, const int sig_len);
-	int (*compare)(const DST_KEY *key1, const DST_KEY *key2);
-	int (*generate)(DST_KEY *key, int parms);
-	void *(*destroy)(void *key);
-	/* conversion functions */
-	int (*to_dns_key)(const DST_KEY *key, u_int8_t *out,
-			   const int out_len);
-	int (*from_dns_key)(DST_KEY *key, const u_int8_t *str,
-			     const int str_len);
-	int (*to_file_fmt)(const DST_KEY *key, char *out,
-			    const int out_len);
-	int (*from_file_fmt)(DST_KEY *key, const char *out,
-			      const int out_len);
-
-} dst_func;
-
-extern dst_func *dst_t_func[DST_MAX_ALGS];
-extern const char *key_file_fmt_str;
-extern const char *dst_path;
-
-#ifndef DST_HASH_SIZE
-#define DST_HASH_SIZE 20	/*%< RIPEMD160 and SHA-1 are 20 bytes MD5 is 16 */
-#endif
-
-int dst_bsafe_init(void);
-
-int dst_rsaref_init(void);
-
-int dst_hmac_md5_init(void);
-
-int dst_cylink_init(void);
-
-int dst_eay_dss_init(void);
-
-/* from higher level support routines */
-int       dst_s_calculate_bits( const u_int8_t *str, const int max_bits); 
-int       dst_s_verify_str( const char **buf, const char *str);
-
-
-/* conversion between dns names and key file names */
-size_t    dst_s_filename_length( const char *name, const char *suffix); 
-int       dst_s_build_filename(  char *filename, const char *name, 
-			         u_int16_t id, int alg, const char *suffix, 
-			         size_t filename_length);
-
-FILE      *dst_s_fopen (const char *filename, const char *mode, int perm);
-
-/*%
- * read and write network byte order into u_int?_t  
- *  all of these should be retired
- */
-u_int16_t dst_s_get_int16( const u_int8_t *buf);
-void      dst_s_put_int16( u_int8_t *buf, const u_int16_t val);
-
-u_int32_t dst_s_get_int32( const u_int8_t *buf);
-void      dst_s_put_int32( u_int8_t *buf, const u_int32_t val);
-
-#ifdef DUMP
-# undef DUMP
-# define DUMP(a,b,c,d) dst_s_dump(a,b,c,d)
-#else
-# define DUMP(a,b,c,d)
-#endif
-void
-dst_s_dump(const int mode, const u_char *data, const int size,
-            const char *msg);
-
-
-
-#endif /* DST_INTERNAL_H */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/dst/hmac_link.c b/contrib/bind9/lib/bind/dst/hmac_link.c
deleted file mode 100644
index cbd68f4..0000000
--- a/contrib/bind9/lib/bind/dst/hmac_link.c
+++ /dev/null
@@ -1,489 +0,0 @@
-#ifdef HMAC_MD5
-#ifndef LINT
-static const char rcsid[] = "$Header: /proj/cvs/prod/bind9/lib/bind/dst/Attic/hmac_link.c,v 1.3.164.5 2007/09/26 04:41:47 each Exp $";
-#endif
-/*
- * Portions Copyright (c) 1995-1998 by Trusted Information Systems, 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 TRUSTED INFORMATION SYSTEMS
- * DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS.  IN NO EVENT SHALL
- * TRUSTED INFORMATION SYSTEMS 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 THE SOFTWARE.
- */
-
-/*%
- * This file contains an implementation of the HMAC-MD5 algorithm.
- */
-#include "port_before.h"
-
-#include <stdio.h>
-#include <unistd.h>
-#include <stdlib.h>
-#include <string.h>
-#include <memory.h>
-#include <sys/param.h>
-#include <sys/time.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <resolv.h>
-
-#include "dst_internal.h"
-
-#ifdef USE_MD5
-# 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
-#endif
-
-#include "port_after.h"
-
-
-#define HMAC_LEN	64
-#define HMAC_IPAD	0x36
-#define HMAC_OPAD	0x5c
-#define MD5_LEN		16
-
-
-typedef struct hmackey {
-	u_char hk_ipad[64], hk_opad[64];
-} HMAC_Key;
-
-
-/************************************************************************** 
- * dst_hmac_md5_sign
- *     Call HMAC signing functions to sign a block of data.
- *     There are three steps to signing, INIT (initialize structures), 
- *     UPDATE (hash (more) data), FINAL (generate a signature).  This
- *     routine performs one or more of these steps.
- * Parameters
- *     mode	SIG_MODE_INIT, SIG_MODE_UPDATE and/or SIG_MODE_FINAL.
- *     priv_key    key to use for signing.
- *     context   the context to be used in this digest
- *     data	data to be signed.
- *     len	 length in bytes of data.
- *     signature   location to store signature.
- *     sig_len     size of the signature location
- * returns 
- *	N  Success on SIG_MODE_FINAL = returns signature length in bytes
- *	0  Success on SIG_MODE_INIT  and UPDATE
- *	 <0  Failure
- */
-
-static int
-dst_hmac_md5_sign(const int mode, DST_KEY *d_key, void **context, 
-		  const u_char *data, const int len, 
-		  u_char *signature, const int sig_len)
-{
-	HMAC_Key *key;
-	int sign_len = 0;
-	MD5_CTX *ctx = NULL;
-
-	if (d_key == NULL || d_key->dk_KEY_struct == NULL)
-		return (-1);
-
-	if (mode & SIG_MODE_INIT) 
-		ctx = (MD5_CTX *) malloc(sizeof(*ctx));
-	else if (context)
-		ctx = (MD5_CTX *) *context;
-	if (ctx == NULL) 
-		return (-1);
-
-	key = (HMAC_Key *) d_key->dk_KEY_struct;
-
-	if (mode & SIG_MODE_INIT) {
-		MD5Init(ctx);
-		MD5Update(ctx, key->hk_ipad, HMAC_LEN);
-	}
-
-	if ((mode & SIG_MODE_UPDATE) && (data && len > 0))
-		MD5Update(ctx, data, len);
-
-	if (mode & SIG_MODE_FINAL) {
-		if (signature == NULL || sig_len < MD5_LEN)
-			return (SIGN_FINAL_FAILURE);
-		MD5Final(signature, ctx);
-
-		/* perform outer MD5 */
-		MD5Init(ctx);
-		MD5Update(ctx, key->hk_opad, HMAC_LEN);
-		MD5Update(ctx, signature, MD5_LEN);
-		MD5Final(signature, ctx);
-		sign_len = MD5_LEN;
-		SAFE_FREE(ctx);
-	}
-	else { 
-		if (context == NULL) 
-			return (-1);
-		*context = (void *) ctx;
-	}		
-	return (sign_len);
-}
-
-
-/************************************************************************** 
- * dst_hmac_md5_verify() 
- *     Calls HMAC verification routines.  There are three steps to 
- *     verification, INIT (initialize structures), UPDATE (hash (more) data), 
- *     FINAL (generate a signature).  This routine performs one or more of 
- *     these steps.
- * Parameters
- *     mode	SIG_MODE_INIT, SIG_MODE_UPDATE and/or SIG_MODE_FINAL.
- *     dkey	key to use for verify.
- *     data	data signed.
- *     len	 length in bytes of data.
- *     signature   signature.
- *     sig_len     length in bytes of signature.
- * returns 
- *     0  Success 
- *    <0  Failure
- */
-
-static int
-dst_hmac_md5_verify(const int mode, DST_KEY *d_key, void **context,
-		const u_char *data, const int len,
-		const u_char *signature, const int sig_len)
-{
-	HMAC_Key *key;
-	MD5_CTX *ctx = NULL;
-
-	if (d_key == NULL || d_key->dk_KEY_struct == NULL)
-		return (-1);
-
-	if (mode & SIG_MODE_INIT) 
-		ctx = (MD5_CTX *) malloc(sizeof(*ctx));
-	else if (context)
-		ctx = (MD5_CTX *) *context;
-	if (ctx == NULL) 
-		return (-1);
-
-	key = (HMAC_Key *) d_key->dk_KEY_struct;
-	if (mode & SIG_MODE_INIT) {
-		MD5Init(ctx);
-		MD5Update(ctx, key->hk_ipad, HMAC_LEN);
-	}
-	if ((mode & SIG_MODE_UPDATE) && (data && len > 0))
-		MD5Update(ctx, data, len);
-
-	if (mode & SIG_MODE_FINAL) {
-		u_char digest[MD5_LEN];
-		if (signature == NULL || key == NULL || sig_len != MD5_LEN)
-			return (VERIFY_FINAL_FAILURE);
-		MD5Final(digest, ctx);
-
-		/* perform outer MD5 */
-		MD5Init(ctx);
-		MD5Update(ctx, key->hk_opad, HMAC_LEN);
-		MD5Update(ctx, digest, MD5_LEN);
-		MD5Final(digest, ctx);
-
-		SAFE_FREE(ctx);
-		if (memcmp(digest, signature, MD5_LEN) != 0)
-			return (VERIFY_FINAL_FAILURE);
-	}
-	else { 
-		if (context == NULL) 
-			return (-1);
-		*context = (void *) ctx;
-	}		
-	return (0);
-}
-
-
-/************************************************************************** 
- * dst_buffer_to_hmac_md5
- *     Converts key from raw data to an HMAC Key
- *     This function gets in a pointer to the data
- * Parameters
- *     hkey	the HMAC key to be filled in
- *     key	the key in raw format
- *     keylen	the length of the key
- * Return
- *	0	Success
- *	<0	Failure
- */
-static int
-dst_buffer_to_hmac_md5(DST_KEY *dkey, const u_char *key, const int keylen)
-{
-	int i;
-	HMAC_Key *hkey = NULL;
-	MD5_CTX ctx;
-	int local_keylen = keylen;
-	u_char tk[MD5_LEN];
-
-	if (dkey == NULL || key == NULL || keylen < 0)
-		return (-1);
-
-	if ((hkey = (HMAC_Key *) malloc(sizeof(HMAC_Key))) == NULL)
-		  return (-2);
-
-	memset(hkey->hk_ipad, 0, sizeof(hkey->hk_ipad));
-	memset(hkey->hk_opad, 0, sizeof(hkey->hk_opad));
-
-	/* if key is longer than HMAC_LEN bytes reset it to key=MD5(key) */
-	if (keylen > HMAC_LEN) {
-		MD5Init(&ctx);
-		MD5Update(&ctx, key, keylen);
-		MD5Final(tk, &ctx);
-		memset((void *) &ctx, 0, sizeof(ctx));
-		key = tk;
-		local_keylen = MD5_LEN;
-	}
-	/* start out by storing key in pads */
-	memcpy(hkey->hk_ipad, key, local_keylen);
-	memcpy(hkey->hk_opad, key, local_keylen);
-
-	/* XOR key with hk_ipad and opad values */
-	for (i = 0; i < HMAC_LEN; i++) {
-		hkey->hk_ipad[i] ^= HMAC_IPAD;
-		hkey->hk_opad[i] ^= HMAC_OPAD;
-	}
-	dkey->dk_key_size = local_keylen;
-	dkey->dk_KEY_struct = (void *) hkey;
-	return (1);
-}
-
-
-/************************************************************************** 
- *  dst_hmac_md5_key_to_file_format
- *	Encodes an HMAC Key into the portable file format.
- *  Parameters 
- *	hkey      HMAC KEY structure 
- *	buff      output buffer
- *	buff_len  size of output buffer 
- *  Return
- *	0  Failure - null input hkey
- *     -1  Failure - not enough space in output area
- *	N  Success - Length of data returned in buff
- */
-
-static int
-dst_hmac_md5_key_to_file_format(const DST_KEY *dkey, char *buff,
-			        const int buff_len)
-{
-	char *bp;
-	int len, i, key_len;
-	u_char key[HMAC_LEN];
-	HMAC_Key *hkey;
-
-	if (dkey == NULL || dkey->dk_KEY_struct == NULL) 
-		return (0);
-	/*
-	 * Using snprintf() would be so much simpler here.
-	 */
-	if (buff == NULL ||
-	    buff_len <= (int)(strlen(key_file_fmt_str) +
-			      strlen(KEY_FILE_FORMAT) + 4))
-		return (-1);	/*%< no OR not enough space in output area */
-	hkey = (HMAC_Key *) dkey->dk_KEY_struct;
-	memset(buff, 0, buff_len);	/*%< just in case */
-	/* write file header */
-	sprintf(buff, key_file_fmt_str, KEY_FILE_FORMAT, KEY_HMAC_MD5, "HMAC");
-
-	bp = buff + strlen(buff);
-
-	memset(key, 0, HMAC_LEN);
-	for (i = 0; i < HMAC_LEN; i++)
-		key[i] = hkey->hk_ipad[i] ^ HMAC_IPAD;
-	for (i = HMAC_LEN - 1; i >= 0; i--)
-		if (key[i] != 0)
-			break;
-	key_len = i + 1;
-
-	if (buff_len - (bp - buff) < 6)
-		return (-1);
-	strcat(bp, "Key: ");
-	bp += strlen("Key: ");
-
-	len = b64_ntop(key, key_len, bp, buff_len - (bp - buff));
-	if (len < 0) 
-		return (-1);
-	bp += len;
-	if (buff_len - (bp - buff) < 2)
-		return (-1);
-	*(bp++) = '\n';
-	*bp = '\0';
-
-	return (bp - buff);
-}
-
-
-/************************************************************************** 
- * dst_hmac_md5_key_from_file_format
- *     Converts contents of a key file into an HMAC key. 
- * Parameters 
- *     hkey    structure to put key into 
- *     buff       buffer containing the encoded key 
- *     buff_len   the length of the buffer
- * Return
- *     n >= 0 Foot print of the key converted 
- *     n <  0 Error in conversion 
- */
-
-static int
-dst_hmac_md5_key_from_file_format(DST_KEY *dkey, const char *buff,
-			      const int buff_len)
-{
-	const char *p = buff, *eol;
-	u_char key[HMAC_LEN+1];	/* b64_pton needs more than 64 bytes do decode
-				 * it should probably be fixed rather than doing
-				 * this
-				 */
-	u_char *tmp;
-	int key_len, len;
-
-	if (dkey == NULL)
-		return (-2);
-	if (buff == NULL || buff_len < 0)
-		return (-1);
-
-	memset(key, 0, sizeof(key));
-
-	if (!dst_s_verify_str(&p, "Key: "))
-		return (-3);
-
-	eol = strchr(p, '\n');
-	if (eol == NULL)
-		return (-4);
-	len = eol - p;
-	tmp = malloc(len + 2);
-	if (tmp == NULL)
-		return (-5);
-	memcpy(tmp, p, len);
-	*(tmp + len) = 0x0;
-	key_len = b64_pton((char *)tmp, key, HMAC_LEN+1);	/*%< see above */
-	SAFE_FREE2(tmp, len + 2);
-
-	if (dst_buffer_to_hmac_md5(dkey, key, key_len) < 0) {
-		return (-6);
-	}
-	return (0);
-}
-
-/*%
- * dst_hmac_md5_to_dns_key() 
- *         function to extract hmac key from DST_KEY structure 
- * intput: 
- *      in_key:  HMAC-MD5 key 
- * output: 
- *	out_str: buffer to write ot
- *      out_len: size of output buffer 
- * returns:
- *      number of bytes written to output buffer 
- */
-static int
-dst_hmac_md5_to_dns_key(const DST_KEY *in_key, u_char *out_str,
-			const int out_len)
-{
-
-	HMAC_Key *hkey;
-	int i;
-	
-	if (in_key == NULL || in_key->dk_KEY_struct == NULL ||
-	    out_len <= in_key->dk_key_size || out_str == NULL)
-		return (-1);
-
-	hkey = (HMAC_Key *) in_key->dk_KEY_struct;
-	for (i = 0; i < in_key->dk_key_size; i++)
-		out_str[i] = hkey->hk_ipad[i] ^ HMAC_IPAD;
-	return (i);
-}
-
-/************************************************************************** 
- *  dst_hmac_md5_compare_keys
- *	Compare two keys for equality.
- *  Return
- *	0	  The keys are equal
- *	NON-ZERO   The keys are not equal
- */
-
-static int
-dst_hmac_md5_compare_keys(const DST_KEY *key1, const DST_KEY *key2)
-{
-	HMAC_Key *hkey1 = (HMAC_Key *) key1->dk_KEY_struct;
-	HMAC_Key *hkey2 = (HMAC_Key *) key2->dk_KEY_struct;
-	return memcmp(hkey1->hk_ipad, hkey2->hk_ipad, HMAC_LEN);
-}
-
-/************************************************************************** 
- * dst_hmac_md5_free_key_structure
- *     Frees all (none) dynamically allocated structures in hkey
- */
-
-static void *
-dst_hmac_md5_free_key_structure(void *key)
-{
-	HMAC_Key *hkey = key;
-	SAFE_FREE(hkey);
-	return (NULL);
-}
-
-
-/*************************************************************************** 
- * dst_hmac_md5_generate_key
- *     Creates a HMAC key of size size with a maximum size of 63 bytes
- *     generating a HMAC key larger than 63 bytes makes no sense as that key 
- *     is digested before use. 
- */
-
-static int
-dst_hmac_md5_generate_key(DST_KEY *key, const int nothing)
-{
-	(void)key;
-	(void)nothing;
-	return (-1);
-}
-
-/*%
- * dst_hmac_md5_init()  Function to answer set up function pointers for HMAC
- *	   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);
-	dst_t_func[KEY_HMAC_MD5] = malloc(sizeof(struct dst_func));
-	if (dst_t_func[KEY_HMAC_MD5] == NULL)
-		return (0);
-	memset(dst_t_func[KEY_HMAC_MD5], 0, sizeof(struct dst_func));
-	dst_t_func[KEY_HMAC_MD5]->sign = dst_hmac_md5_sign;
-	dst_t_func[KEY_HMAC_MD5]->verify = dst_hmac_md5_verify;
-	dst_t_func[KEY_HMAC_MD5]->compare = dst_hmac_md5_compare_keys;
-	dst_t_func[KEY_HMAC_MD5]->generate = dst_hmac_md5_generate_key;
-	dst_t_func[KEY_HMAC_MD5]->destroy = dst_hmac_md5_free_key_structure;
-	dst_t_func[KEY_HMAC_MD5]->to_dns_key = dst_hmac_md5_to_dns_key;
-	dst_t_func[KEY_HMAC_MD5]->from_dns_key = dst_buffer_to_hmac_md5;
-	dst_t_func[KEY_HMAC_MD5]->to_file_fmt = dst_hmac_md5_key_to_file_format;
-	dst_t_func[KEY_HMAC_MD5]->from_file_fmt = dst_hmac_md5_key_from_file_format;
-	return (1);
-}
-
-#else 
-#define	dst_hmac_md5_init	__dst_hmac_md5_init
-
-int
-dst_hmac_md5_init(){
-	return (0);
-}
-#endif
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/dst/md5.h b/contrib/bind9/lib/bind/dst/md5.h
deleted file mode 100644
index b1ed9e1..0000000
--- a/contrib/bind9/lib/bind/dst/md5.h
+++ /dev/null
@@ -1,108 +0,0 @@
-/* crypto/md/md5.h */
-/* Copyright (C) 1995-1997 Eric Young (eay@cryptsoft.com)
- * All rights reserved.
- *
- * This package is an SSL implementation written
- * by Eric Young (eay@cryptsoft.com).
- * The implementation was written so as to conform with Netscapes SSL.
- * 
- * This library is free for commercial and non-commercial use as long as
- * the following conditions are aheared to.  The following conditions
- * apply to all code found in this distribution, be it the RC4, RSA,
- * lhash, DES, etc., code; not just the SSL code.  The SSL documentation
- * included with this distribution is covered by the same copyright terms
- * except that the holder is Tim Hudson (tjh@cryptsoft.com).
- * 
- * Copyright remains Eric Young's, and as such any Copyright notices in
- * the code are not to be removed.
- * If this package is used in a product, Eric Young should be given attribution
- * as the author of the parts of the library used.
- * This can be in the form of a textual message at program startup or
- * in documentation (online or textual) provided with the package.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- *    "This product includes cryptographic software written by
- *     Eric Young (eay@cryptsoft.com)"
- *    The word 'cryptographic' can be left out if the rouines from the library
- *    being used are not cryptographic related :-).
- * 4. If you include any Windows specific code (or a derivative thereof) from 
- *    the apps directory (application code) you must include an acknowledgement:
- *    "This product includes software written by Tim Hudson (tjh@cryptsoft.com)"
- * 
- * THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- * 
- * The licence and distribution terms for any publically available version or
- * derivative of this code cannot be changed.  i.e. this code cannot simply be
- * copied and put under another distribution licence
- * [including the GNU Public Licence.]
- */
-
-#ifndef HEADER_MD5_H
-#define HEADER_MD5_H
-
-#ifndef	HAVE_MD5
-
-#ifdef  __cplusplus
-extern "C" {
-#endif
-
-#define MD5_CBLOCK	64
-#define MD5_LBLOCK	16
-#define MD5_BLOCK	16
-#define MD5_LAST_BLOCK  56
-#define MD5_LENGTH_BLOCK 8
-#define MD5_DIGEST_LENGTH 16
-
-typedef struct MD5state_st
-	{
-	unsigned long A,B,C,D;
-	unsigned long Nl,Nh;
-	unsigned long data[MD5_LBLOCK];
-	int num;
-	} MD5_CTX;
-
-#ifndef NOPROTO
-void MD5_Init(MD5_CTX *c);
-void MD5_Update(MD5_CTX *c, const unsigned char *data, unsigned long len);
-void MD5_Final(unsigned char *md, MD5_CTX *c);
-unsigned char *MD5(unsigned char *d, unsigned long n, unsigned char *md);
-#else
-void MD5_Init();
-void MD5_Update();
-void MD5_Final();
-unsigned char *MD5();
-#endif
-
-/* to provide backward compatabilty to RSAREF calls ogud@tis.com 1997/11/14 */
-#define MD5Init(c)             MD5_Init(c)
-#define MD5Update(c,data, len) MD5_Update(c,data,len)
-#define MD5Final(md, c)        MD5_Final(md, c) 
-#ifdef  __cplusplus
-}
-#endif
-
-#endif
-#else 
-#include <sys/md5.h>
-#endif /* HAVE_MD5 */
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/dst/md5_dgst.c b/contrib/bind9/lib/bind/dst/md5_dgst.c
deleted file mode 100644
index 76b0505..0000000
--- a/contrib/bind9/lib/bind/dst/md5_dgst.c
+++ /dev/null
@@ -1,374 +0,0 @@
-/* crypto/md/md5_dgst.c */
-/* Copyright (C) 1995-1997 Eric Young (eay@cryptsoft.com)
- * All rights reserved.
- *
- * This package is an SSL implementation written
- * by Eric Young (eay@cryptsoft.com).
- * The implementation was written so as to conform with Netscapes SSL.
- * 
- * This library is free for commercial and non-commercial use as long as
- * the following conditions are aheared to.  The following conditions
- * apply to all code found in this distribution, be it the RC4, RSA,
- * lhash, DES, etc., code; not just the SSL code.  The SSL documentation
- * included with this distribution is covered by the same copyright terms
- * except that the holder is Tim Hudson (tjh@cryptsoft.com).
- * 
- * Copyright remains Eric Young's, and as such any Copyright notices in
- * the code are not to be removed.
- * If this package is used in a product, Eric Young should be given attribution
- * as the author of the parts of the library used.
- * This can be in the form of a textual message at program startup or
- * in documentation (online or textual) provided with the package.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- *    "This product includes cryptographic software written by
- *     Eric Young (eay@cryptsoft.com)"
- *    The word 'cryptographic' can be left out if the rouines from the library
- *    being used are not cryptographic related :-).
- * 4. If you include any Windows specific code (or a derivative thereof) from 
- *    the apps directory (application code) you must include an acknowledgement:
- *    "This product includes software written by Tim Hudson (tjh@cryptsoft.com)"
- * 
- * THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- * 
- * The licence and distribution terms for any publically available version or
- * derivative of this code cannot be changed.  i.e. this code cannot simply be
- * copied and put under another distribution licence
- * [including the GNU Public Licence.]
- */
-
-#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>
-
-const char *MD5_version="MD5 part of SSLeay 0.8.1 19-Jul-1997";
-
-/*! \file
- * \brief
- *  Implemented from RFC1321 The MD5 Message-Digest Algorithm
- */
-
-#define INIT_DATA_A (unsigned long)0x67452301L
-#define INIT_DATA_B (unsigned long)0xefcdab89L
-#define INIT_DATA_C (unsigned long)0x98badcfeL
-#define INIT_DATA_D (unsigned long)0x10325476L
-
-#ifndef NOPROTO
-static void md5_block(MD5_CTX *c, unsigned long *p);
-#else
-static void md5_block();
-#endif
-
-void MD5_Init(c)
-MD5_CTX *c;
-	{
-	c->A=INIT_DATA_A;
-	c->B=INIT_DATA_B;
-	c->C=INIT_DATA_C;
-	c->D=INIT_DATA_D;
-	c->Nl=0;
-	c->Nh=0;
-	c->num=0;
-	}
-
-void MD5_Update(c, data, len)
-MD5_CTX *c;
-register const unsigned char *data;
-unsigned long len;
-	{
-	register ULONG *p;
-	int sw,sc;
-	ULONG l;
-
-	if (len == 0U) return;
-
-	l=(c->Nl+(len<<3))&0xffffffffL;
-	/* 95-05-24 eay Fixed a bug with the overflow handling, thanks to
-	 * Wei Dai <weidai@eskimo.com> for pointing it out. */
-	if (l < c->Nl) /*%< overflow */
-		c->Nh++;
-	c->Nh+=(len>>29);
-	c->Nl=l;
-
-	if (c->num != 0)
-		{
-		p=c->data;
-		sw=c->num>>2;
-		sc=c->num&0x03;
-
-		if ((c->num+len) >= (size_t)MD5_CBLOCK)
-			{
-			l= p[sw];
-			p_c2l(data,l,sc);
-			p[sw++]=l;
-			for (; sw<MD5_LBLOCK; sw++)
-				{
-				c2l(data,l);
-				p[sw]=l;
-				}
-			len-=(MD5_CBLOCK-c->num);
-
-			md5_block(c,p);
-			c->num=0;
-			/* drop through and do the rest */
-			}
-		else
-			{
-			int ew,ec;
-
-			c->num+=(int)len;
-			if ((sc+len) < 4U) /*%< ugly, add char's to a word */
-				{
-				l= p[sw];
-				p_c2l_p(data,l,sc,len);
-				p[sw]=l;
-				}
-			else
-				{
-				ew=(c->num>>2);
-				ec=(c->num&0x03);
-				l= p[sw];
-				p_c2l(data,l,sc);
-				p[sw++]=l;
-				for (; sw < ew; sw++)
-					{ c2l(data,l); p[sw]=l; }
-				if (ec)
-					{
-					c2l_p(data,l,ec);
-					p[sw]=l;
-					}
-				}
-			return;
-			}
-		}
-	/* we now can process the input data in blocks of MD5_CBLOCK
-	 * chars and save the leftovers to c->data. */
-	p=c->data;
-	while (len >= (size_t)MD5_CBLOCK)
-		{
-#if defined(L_ENDIAN) || defined(B_ENDIAN)
-		memcpy(p,data,MD5_CBLOCK);
-		data+=MD5_CBLOCK;
-#ifdef B_ENDIAN
-		for (sw=(MD5_LBLOCK/4); sw; sw--)
-			{
-			Endian_Reverse32(p[0]);
-			Endian_Reverse32(p[1]);
-			Endian_Reverse32(p[2]);
-			Endian_Reverse32(p[3]);
-			p+=4;
-			}
-#endif
-#else
-		for (sw=(MD5_LBLOCK/4); sw; sw--)
-			{
-			c2l(data,l); *(p++)=l;
-			c2l(data,l); *(p++)=l;
-			c2l(data,l); *(p++)=l;
-			c2l(data,l); *(p++)=l; 
-			} 
-#endif
-		p=c->data;
-		md5_block(c,p);
-		len-=MD5_CBLOCK;
-		}
-	sc=(int)len;
-	c->num=sc;
-	if (sc)
-		{
-		sw=sc>>2;	/*%< words to copy */
-#ifdef L_ENDIAN
-		p[sw]=0;
-		memcpy(p,data,sc);
-#else
-		sc&=0x03;
-		for ( ; sw; sw--)
-			{ c2l(data,l); *(p++)=l; }
-		c2l_p(data,l,sc);
-		*p=l;
-#endif
-		}
-	}
-
-static void md5_block(c, X)
-MD5_CTX *c;
-register ULONG *X;
-	{
-	register ULONG A,B,C,D;
-
-	A=c->A;
-	B=c->B;
-	C=c->C;
-	D=c->D;
-
-	/* Round 0 */
-	R0(A,B,C,D,X[ 0], 7,0xd76aa478L);
-	R0(D,A,B,C,X[ 1],12,0xe8c7b756L);
-	R0(C,D,A,B,X[ 2],17,0x242070dbL);
-	R0(B,C,D,A,X[ 3],22,0xc1bdceeeL);
-	R0(A,B,C,D,X[ 4], 7,0xf57c0fafL);
-	R0(D,A,B,C,X[ 5],12,0x4787c62aL);
-	R0(C,D,A,B,X[ 6],17,0xa8304613L);
-	R0(B,C,D,A,X[ 7],22,0xfd469501L);
-	R0(A,B,C,D,X[ 8], 7,0x698098d8L);
-	R0(D,A,B,C,X[ 9],12,0x8b44f7afL);
-	R0(C,D,A,B,X[10],17,0xffff5bb1L);
-	R0(B,C,D,A,X[11],22,0x895cd7beL);
-	R0(A,B,C,D,X[12], 7,0x6b901122L);
-	R0(D,A,B,C,X[13],12,0xfd987193L);
-	R0(C,D,A,B,X[14],17,0xa679438eL);
-	R0(B,C,D,A,X[15],22,0x49b40821L);
-	/* Round 1 */
-	R1(A,B,C,D,X[ 1], 5,0xf61e2562L);
-	R1(D,A,B,C,X[ 6], 9,0xc040b340L);
-	R1(C,D,A,B,X[11],14,0x265e5a51L);
-	R1(B,C,D,A,X[ 0],20,0xe9b6c7aaL);
-	R1(A,B,C,D,X[ 5], 5,0xd62f105dL);
-	R1(D,A,B,C,X[10], 9,0x02441453L);
-	R1(C,D,A,B,X[15],14,0xd8a1e681L);
-	R1(B,C,D,A,X[ 4],20,0xe7d3fbc8L);
-	R1(A,B,C,D,X[ 9], 5,0x21e1cde6L);
-	R1(D,A,B,C,X[14], 9,0xc33707d6L);
-	R1(C,D,A,B,X[ 3],14,0xf4d50d87L);
-	R1(B,C,D,A,X[ 8],20,0x455a14edL);
-	R1(A,B,C,D,X[13], 5,0xa9e3e905L);
-	R1(D,A,B,C,X[ 2], 9,0xfcefa3f8L);
-	R1(C,D,A,B,X[ 7],14,0x676f02d9L);
-	R1(B,C,D,A,X[12],20,0x8d2a4c8aL);
-	/* Round 2 */
-	R2(A,B,C,D,X[ 5], 4,0xfffa3942L);
-	R2(D,A,B,C,X[ 8],11,0x8771f681L);
-	R2(C,D,A,B,X[11],16,0x6d9d6122L);
-	R2(B,C,D,A,X[14],23,0xfde5380cL);
-	R2(A,B,C,D,X[ 1], 4,0xa4beea44L);
-	R2(D,A,B,C,X[ 4],11,0x4bdecfa9L);
-	R2(C,D,A,B,X[ 7],16,0xf6bb4b60L);
-	R2(B,C,D,A,X[10],23,0xbebfbc70L);
-	R2(A,B,C,D,X[13], 4,0x289b7ec6L);
-	R2(D,A,B,C,X[ 0],11,0xeaa127faL);
-	R2(C,D,A,B,X[ 3],16,0xd4ef3085L);
-	R2(B,C,D,A,X[ 6],23,0x04881d05L);
-	R2(A,B,C,D,X[ 9], 4,0xd9d4d039L);
-	R2(D,A,B,C,X[12],11,0xe6db99e5L);
-	R2(C,D,A,B,X[15],16,0x1fa27cf8L);
-	R2(B,C,D,A,X[ 2],23,0xc4ac5665L);
-	/* Round 3 */
-	R3(A,B,C,D,X[ 0], 6,0xf4292244L);
-	R3(D,A,B,C,X[ 7],10,0x432aff97L);
-	R3(C,D,A,B,X[14],15,0xab9423a7L);
-	R3(B,C,D,A,X[ 5],21,0xfc93a039L);
-	R3(A,B,C,D,X[12], 6,0x655b59c3L);
-	R3(D,A,B,C,X[ 3],10,0x8f0ccc92L);
-	R3(C,D,A,B,X[10],15,0xffeff47dL);
-	R3(B,C,D,A,X[ 1],21,0x85845dd1L);
-	R3(A,B,C,D,X[ 8], 6,0x6fa87e4fL);
-	R3(D,A,B,C,X[15],10,0xfe2ce6e0L);
-	R3(C,D,A,B,X[ 6],15,0xa3014314L);
-	R3(B,C,D,A,X[13],21,0x4e0811a1L);
-	R3(A,B,C,D,X[ 4], 6,0xf7537e82L);
-	R3(D,A,B,C,X[11],10,0xbd3af235L);
-	R3(C,D,A,B,X[ 2],15,0x2ad7d2bbL);
-	R3(B,C,D,A,X[ 9],21,0xeb86d391L);
-
-	c->A+=A&0xffffffffL;
-	c->B+=B&0xffffffffL;
-	c->C+=C&0xffffffffL;
-	c->D+=D&0xffffffffL;
-	}
-
-void MD5_Final(md, c)
-unsigned char *md;
-MD5_CTX *c;
-	{
-	register int i,j;
-	register ULONG l;
-	register ULONG *p;
-	static unsigned char end[4]={0x80,0x00,0x00,0x00};
-	unsigned char *cp=end;
-
-	/* c->num should definitly have room for at least one more byte. */
-	p=c->data;
-	j=c->num;
-	i=j>>2;
-
-	/* purify often complains about the following line as an
-	 * Uninitialized Memory Read.  While this can be true, the
-	 * following p_c2l macro will reset l when that case is true.
-	 * This is because j&0x03 contains the number of 'valid' bytes
-	 * already in p[i].  If and only if j&0x03 == 0, the UMR will
-	 * occur but this is also the only time p_c2l will do
-	 * l= *(cp++) instead of l|= *(cp++)
-	 * Many thanks to Alex Tang <altitude@cic.net> for pickup this
-	 * 'potential bug' */
-#ifdef PURIFY
-	if ((j&0x03) == 0) p[i]=0;
-#endif
-	l=p[i];
-	p_c2l(cp,l,j&0x03);
-	p[i]=l;
-	i++;
-	/* i is the next 'undefined word' */
-	if (c->num >= MD5_LAST_BLOCK)
-		{
-		for (; i<MD5_LBLOCK; i++)
-			p[i]=0;
-		md5_block(c,p);
-		i=0;
-		}
-	for (; i<(MD5_LBLOCK-2); i++)
-		p[i]=0;
-	p[MD5_LBLOCK-2]=c->Nl;
-	p[MD5_LBLOCK-1]=c->Nh;
-	md5_block(c,p);
-	cp=md;
-	l=c->A; l2c(l,cp);
-	l=c->B; l2c(l,cp);
-	l=c->C; l2c(l,cp);
-	l=c->D; l2c(l,cp);
-
-	/* clear stuff, md5_block may be leaving some stuff on the stack
-	 * but I'm not worried :-) */
-	c->num=0;
-/*	memset((char *)&c,0,sizeof(c));*/
-	}
-
-#ifdef undef
-int printit(l)
-unsigned long *l;
-	{
-	int i,ii;
-
-	for (i=0; i<2; i++)
-		{
-		for (ii=0; ii<8; ii++)
-			{
-			fprintf(stderr,"%08lx ",l[i*8+ii]);
-			}
-		fprintf(stderr,"\n");
-		}
-	}
-#endif
-#endif /* HAVE_MD5 */
-#endif /* USE_MD5 */
diff --git a/contrib/bind9/lib/bind/dst/md5_locl.h b/contrib/bind9/lib/bind/dst/md5_locl.h
deleted file mode 100644
index 657fe8c..0000000
--- a/contrib/bind9/lib/bind/dst/md5_locl.h
+++ /dev/null
@@ -1,193 +0,0 @@
-/* crypto/md/md5_locl.h */
-/* Copyright (C) 1995-1997 Eric Young (eay@cryptsoft.com)
- * All rights reserved.
- *
- * This package is an SSL implementation written
- * by Eric Young (eay@cryptsoft.com).
- * The implementation was written so as to conform with Netscapes SSL.
- * 
- * This library is free for commercial and non-commercial use as long as
- * the following conditions are aheared to.  The following conditions
- * apply to all code found in this distribution, be it the RC4, RSA,
- * lhash, DES, etc., code; not just the SSL code.  The SSL documentation
- * included with this distribution is covered by the same copyright terms
- * except that the holder is Tim Hudson (tjh@cryptsoft.com).
- * 
- * Copyright remains Eric Young's, and as such any Copyright notices in
- * the code are not to be removed.
- * If this package is used in a product, Eric Young should be given attribution
- * as the author of the parts of the library used.
- * This can be in the form of a textual message at program startup or
- * in documentation (online or textual) provided with the package.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- *    "This product includes cryptographic software written by
- *     Eric Young (eay@cryptsoft.com)"
- *    The word 'cryptographic' can be left out if the rouines from the library
- *    being used are not cryptographic related :-).
- * 4. If you include any Windows specific code (or a derivative thereof) from 
- *    the apps directory (application code) you must include an acknowledgement:
- *    "This product includes software written by Tim Hudson (tjh@cryptsoft.com)"
- * 
- * THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- * 
- * The licence and distribution terms for any publically available version or
- * derivative of this code cannot be changed.  i.e. this code cannot simply be
- * copied and put under another distribution licence
- * [including the GNU Public Licence.]
- */
-
-#include <stdlib.h>
-#include <string.h>
-#include "md5.h"
-
-#define ULONG	unsigned long
-#define UCHAR	unsigned char
-#define UINT	unsigned int
-
-#if defined(NOCONST)
-#define const
-#endif
-
-#undef c2l
-#define c2l(c,l)	(l = ((unsigned long)(*((c)++)))     , \
-			 l|=(((unsigned long)(*((c)++)))<< 8), \
-			 l|=(((unsigned long)(*((c)++)))<<16), \
-			 l|=(((unsigned long)(*((c)++)))<<24))
-
-#undef p_c2l
-#define p_c2l(c,l,n)	{ \
-			switch (n) { \
-			case 0: l =((unsigned long)(*((c)++))); \
-			case 1: l|=((unsigned long)(*((c)++)))<< 8; \
-			case 2: l|=((unsigned long)(*((c)++)))<<16; \
-			case 3: l|=((unsigned long)(*((c)++)))<<24; \
-				} \
-			}
-
-/* NOTE the pointer is not incremented at the end of this */
-#undef c2l_p
-#define c2l_p(c,l,n)	{ \
-			l=0; \
-			(c)+=n; \
-			switch (n) { \
-			case 3: l =((unsigned long)(*(--(c))))<<16; \
-			case 2: l|=((unsigned long)(*(--(c))))<< 8; \
-			case 1: l|=((unsigned long)(*(--(c))))    ; \
-				} \
-			}
-
-#undef p_c2l_p
-#define p_c2l_p(c,l,sc,len) { \
-			switch (sc) \
-				{ \
-			case 0: l =((unsigned long)(*((c)++))); \
-				if (--len == 0U) break; \
-			case 1: l|=((unsigned long)(*((c)++)))<< 8; \
-				if (--len == 0U) break; \
-			case 2: l|=((unsigned long)(*((c)++)))<<16; \
-				} \
-			}
-
-#undef l2c
-#define l2c(l,c)	(*((c)++)=(unsigned char)(((l)    )&0xff), \
-			 *((c)++)=(unsigned char)(((l)>> 8)&0xff), \
-			 *((c)++)=(unsigned char)(((l)>>16)&0xff), \
-			 *((c)++)=(unsigned char)(((l)>>24)&0xff))
-
-/* NOTE - c is not incremented as per l2c */
-#undef l2cn
-#define l2cn(l1,l2,c,n)	{ \
-			c+=n; \
-			switch (n) { \
-			case 8: *(--(c))=(unsigned char)(((l2)>>24)&0xff); \
-			case 7: *(--(c))=(unsigned char)(((l2)>>16)&0xff); \
-			case 6: *(--(c))=(unsigned char)(((l2)>> 8)&0xff); \
-			case 5: *(--(c))=(unsigned char)(((l2)    )&0xff); \
-			case 4: *(--(c))=(unsigned char)(((l1)>>24)&0xff); \
-			case 3: *(--(c))=(unsigned char)(((l1)>>16)&0xff); \
-			case 2: *(--(c))=(unsigned char)(((l1)>> 8)&0xff); \
-			case 1: *(--(c))=(unsigned char)(((l1)    )&0xff); \
-				} \
-			}
-
-/* A nice byte order reversal from Wei Dai <weidai@eskimo.com> */
-#if defined(WIN32)
-/* 5 instructions with rotate instruction, else 9 */
-#define Endian_Reverse32(a) \
-	{ \
-	unsigned long l=(a); \
-	(a)=((ROTATE(l,8)&0x00FF00FF)|(ROTATE(l,24)&0xFF00FF00)); \
-	}
-#else
-/* 6 instructions with rotate instruction, else 8 */
-#define Endian_Reverse32(a) \
-	{ \
-	unsigned long l=(a); \
-	l=(((l&0xFF00FF00)>>8L)|((l&0x00FF00FF)<<8L)); \
-	(a)=ROTATE(l,16L); \
-	}
-#endif
-
-/*%
-#define	F(x,y,z)	(((x) & (y))  |  ((~(x)) & (z)))
-#define	G(x,y,z)	(((x) & (z))  |  ((y) & (~(z))))
-*/
-
-/* As pointed out by Wei Dai <weidai@eskimo.com>, the above can be
- * simplified to the code below.  Wei attributes these optimisations
- * to Peter Gutmann's SHS code, and he attributes it to Rich Schroeppel.
- */
-#define	F(x,y,z)	((((y) ^ (z)) & (x)) ^ (z))
-#define	G(x,y,z)	((((x) ^ (y)) & (z)) ^ (y))
-#define	H(x,y,z)	((x) ^ (y) ^ (z))
-#define	I(x,y,z)	(((x) | (~(z))) ^ (y))
-
-#undef ROTATE
-#if defined(WIN32)
-#define ROTATE(a,n)     _lrotl(a,n)
-#else
-#define ROTATE(a,n)     (((a)<<(n))|(((a)&0xffffffff)>>(32-(n))))
-#endif
-
-
-#define R0(a,b,c,d,k,s,t) { \
-	a+=((k)+(t)+F((b),(c),(d))); \
-	a=ROTATE(a,s); \
-	a+=b; };\
-
-#define R1(a,b,c,d,k,s,t) { \
-	a+=((k)+(t)+G((b),(c),(d))); \
-	a=ROTATE(a,s); \
-	a+=b; };
-
-#define R2(a,b,c,d,k,s,t) { \
-	a+=((k)+(t)+H((b),(c),(d))); \
-	a=ROTATE(a,s); \
-	a+=b; };
-
-#define R3(a,b,c,d,k,s,t) { \
-	a+=((k)+(t)+I((b),(c),(d))); \
-	a=ROTATE(a,s); \
-	a+=b; };
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/dst/support.c b/contrib/bind9/lib/bind/dst/support.c
deleted file mode 100644
index 263f957..0000000
--- a/contrib/bind9/lib/bind/dst/support.c
+++ /dev/null
@@ -1,342 +0,0 @@
-static const char rcsid[] = "$Header: /proj/cvs/prod/bind9/lib/bind/dst/Attic/support.c,v 1.3.332.3 2005/10/11 00:25:09 marka Exp $";
-
-
-/*
- * Portions Copyright (c) 1995-1998 by Trusted Information Systems, 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 TRUSTED INFORMATION SYSTEMS
- * DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS.  IN NO EVENT SHALL
- * TRUSTED INFORMATION SYSTEMS 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 THE SOFTWARE.
- */
-
-#include "port_before.h"
-
-#include <stdio.h>
-#include <unistd.h>
-#include <memory.h>
-#include <string.h>
-#include <errno.h>
-#include <sys/stat.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <resolv.h>
-
-#include "dst_internal.h"
-
-#include "port_after.h"
-
-/*%
- * dst_s_verify_str()
- *     Validate that the input string(*str) is at the head of the input
- *     buffer(**buf).  If so, move the buffer head pointer (*buf) to
- *     the first byte of data following the string(*str).
- * Parameters
- *     buf     Input buffer.
- *     str     Input string.
- * Return
- *	0       *str is not the head of **buff
- *	1       *str is the head of **buff, *buf is is advanced to
- *	the tail of **buf.
- */
-
-int
-dst_s_verify_str(const char **buf, const char *str)
-{
-	int b, s;
-	if (*buf == NULL)	/*%< error checks */
-		return (0);
-	if (str == NULL || *str == '\0')
-		return (1);
-
-	b = strlen(*buf);	/*%< get length of strings */
-	s = strlen(str);
-	if (s > b || strncmp(*buf, str, s))	/*%< check if same */
-		return (0);	/*%< not a match */
-	(*buf) += s;		/*%< advance pointer */
-	return (1);
-}
-
-/*%
- * dst_s_calculate_bits
- *     Given a binary number represented in a u_char[], determine
- *     the number of significant bits used.
- * Parameters
- *     str       An input character string containing a binary number.
- *     max_bits The maximum possible significant bits.
- * Return
- *     N       The number of significant bits in str.
- */
-
-int
-dst_s_calculate_bits(const u_char *str, const int max_bits)
-{
-	const u_char *p = str;
-	u_char i, j = 0x80;
-	int bits;
-	for (bits = max_bits; *p == 0x00 && bits > 0; p++)
-		bits -= 8;
-	for (i = *p; (i & j) != j; j >>= 1)
-		bits--;
-	return (bits);
-}
-
-/*%
- * calculates a checksum used in dst for an id.
- * takes an array of bytes and a length.
- * returns a 16  bit checksum.
- */
-u_int16_t
-dst_s_id_calc(const u_char *key, const int keysize)
-{
-	u_int32_t ac;
-	const u_char *kp = key;
-	int size = keysize;
-
-	if (!key || (keysize <= 0))
-		return (0xffffU);
- 
-	for (ac = 0; size > 1; size -= 2, kp += 2)
-		ac += ((*kp) << 8) + *(kp + 1);
-
-	if (size > 0)
-		ac += ((*kp) << 8);
-	ac += (ac >> 16) & 0xffff;
-
-	return (ac & 0xffff);
-}
-
-/*%
- * dst_s_dns_key_id() Function to calculate DNSSEC footprint from KEY record
- *   rdata
- * Input:
- *	dns_key_rdata: the raw data in wire format 
- *      rdata_len: the size of the input data 
- * Output:
- *      the key footprint/id calculated from the key data 
- */ 
-u_int16_t
-dst_s_dns_key_id(const u_char *dns_key_rdata, const int rdata_len)
-{
-	if (!dns_key_rdata)
-		return 0;
-
-	/* compute id */
-	if (dns_key_rdata[3] == KEY_RSA)	/*%< Algorithm RSA */
-		return dst_s_get_int16((const u_char *)
-				       &dns_key_rdata[rdata_len - 3]);
-	else if (dns_key_rdata[3] == KEY_HMAC_MD5)
-		/* compatibility */
-		return 0;
-	else
-		/* compute a checksum on the key part of the key rr */
-		return dst_s_id_calc(dns_key_rdata, rdata_len);
-}
-
-/*%
- * dst_s_get_int16
- *     This routine extracts a 16 bit integer from a two byte character
- *     string.  The character string is assumed to be in network byte
- *     order and may be unaligned.  The number returned is in host order.
- * Parameter
- *     buf     A two byte character string.
- * Return
- *     The converted integer value.
- */
-
-u_int16_t
-dst_s_get_int16(const u_char *buf)
-{
-	register u_int16_t a = 0;
-	a = ((u_int16_t)(buf[0] << 8)) | ((u_int16_t)(buf[1]));
-	return (a);
-}
-
-/*%
- * dst_s_get_int32
- *     This routine extracts a 32 bit integer from a four byte character
- *     string.  The character string is assumed to be in network byte
- *     order and may be unaligned.  The number returned is in host order.
- * Parameter
- *     buf     A four byte character string.
- * Return
- *     The converted integer value.
- */
-
-u_int32_t
-dst_s_get_int32(const u_char *buf)
-{
-	register u_int32_t a = 0;
-	a = ((u_int32_t)(buf[0] << 24)) | ((u_int32_t)(buf[1] << 16)) |
-		((u_int32_t)(buf[2] << 8)) | ((u_int32_t)(buf[3]));
-	return (a);
-}
-
-/*%
- * dst_s_put_int16
- *     Take a 16 bit integer and store the value in a two byte
- *     character string.  The integer is assumed to be in network
- *     order and the string is returned in host order.
- *
- * Parameters
- *     buf     Storage for a two byte character string.
- *     val     16 bit integer.
- */
-
-void
-dst_s_put_int16(u_int8_t *buf, const u_int16_t val)
-{
-	buf[0] = (u_int8_t)(val >> 8);
-	buf[1] = (u_int8_t)(val);
-}
-
-/*%
- * dst_s_put_int32
- *     Take a 32 bit integer and store the value in a four byte
- *     character string.  The integer is assumed to be in network
- *     order and the string is returned in host order.
- *
- * Parameters
- *     buf     Storage for a four byte character string.
- *     val     32 bit integer.
- */
-
-void
-dst_s_put_int32(u_int8_t *buf, const u_int32_t val)
-{
-	buf[0] = (u_int8_t)(val >> 24);
-	buf[1] = (u_int8_t)(val >> 16);
-	buf[2] = (u_int8_t)(val >> 8);
-	buf[3] = (u_int8_t)(val);
-}
-
-/*%
- *  dst_s_filename_length
- *
- *	This function returns the number of bytes needed to hold the
- *	filename for a key file.  '/', '\' and ':' are not allowed.
- *	form:  K&lt;keyname&gt;+&lt;alg&gt;+&lt;id&gt;.&lt;suffix&gt;
- *
- *	Returns 0 if the filename would contain either '\', '/' or ':'
- */
-size_t
-dst_s_filename_length(const char *name, const char *suffix)
-{
-	if (name == NULL)
-		return (0);
-	if (strrchr(name, '\\'))
-		return (0);
-	if (strrchr(name, '/'))
-		return (0);
-	if (strrchr(name, ':'))
-		return (0);
-	if (suffix == NULL)
-		return (0);
-	if (strrchr(suffix, '\\'))
-		return (0);
-	if (strrchr(suffix, '/'))
-		return (0);
-	if (strrchr(suffix, ':'))
-		return (0);
-	return (1 + strlen(name) + 6 + strlen(suffix));
-}
-
-/*%
- *  dst_s_build_filename ()
- *	Builds a key filename from the key name, it's id, and a
- *	suffix.  '\', '/' and ':' are not allowed. fA filename is of the
- *	form:  K&lt;keyname&gt;&lt;id&gt;.&lt;suffix&gt;
- *	form: K&lt;keyname&gt;+&lt;alg&gt;+&lt;id&gt;.&lt;suffix&gt;
- *
- *	Returns -1 if the conversion fails:
- *	  if the filename would be too long for space allotted
- *	  if the filename would contain a '\', '/' or ':'
- *	Returns 0 on success
- */
-
-int
-dst_s_build_filename(char *filename, const char *name, u_int16_t id,
-		     int alg, const char *suffix, size_t filename_length)
-{
-	u_int32_t my_id;
-	if (filename == NULL)
-		return (-1);
-	memset(filename, 0, filename_length);
-	if (name == NULL)
-		return (-1);
-	if (suffix == NULL)
-		return (-1);
-	if (filename_length < 1 + strlen(name) + 4 + 6 + 1 + strlen(suffix))
-		return (-1);
-	my_id = id;
-	sprintf(filename, "K%s+%03d+%05d.%s", name, alg, my_id,
-		(const char *) suffix);
-	if (strrchr(filename, '/'))
-		return (-1);
-	if (strrchr(filename, '\\'))
-		return (-1);
-	if (strrchr(filename, ':'))
-		return (-1);
-	return (0);
-}
-
-/*%
- *  dst_s_fopen ()
- *     Open a file in the dst_path directory.  If perm is specified, the
- *     file is checked for existence first, and not opened if it exists.
- *  Parameters
- *     filename  File to open
- *     mode       Mode to open the file (passed directly to fopen)
- *     perm       File permission, if creating a new file.
- *  Returns
- *     NULL       Failure
- *     NON-NULL  (FILE *) of opened file.
- */
-FILE *
-dst_s_fopen(const char *filename, const char *mode, int perm)
-{
-	FILE *fp;
-	char pathname[PATH_MAX];
-
-	if (strlen(filename) + strlen(dst_path) >= sizeof(pathname))
-		return (NULL);
-
-	if (*dst_path != '\0') {
-		strcpy(pathname, dst_path);
-		strcat(pathname, filename);
-	} else
-		strcpy(pathname, filename);
-	
-	fp = fopen(pathname, mode);
-	if (perm)
-		chmod(pathname, perm);
-	return (fp);
-}
-
-void
-dst_s_dump(const int mode, const u_char *data, const int size, 
-	    const char *msg)
-{
-	UNUSED(data);
-
-	if (size > 0) {
-#ifdef LONG_TEST
-		static u_char scratch[1000];
-		int n ;
-		n = b64_ntop(data, scratch, size, sizeof(scratch));
-		printf("%s: %x %d %s\n", msg, mode, n, scratch);
-#else
-		printf("%s,%x %d\n", msg, mode, size);
-#endif
-	}
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/include/Makefile.in b/contrib/bind9/lib/bind/include/Makefile.in
deleted file mode 100644
index 17a69bf..0000000
--- a/contrib/bind9/lib/bind/include/Makefile.in
+++ /dev/null
@@ -1,47 +0,0 @@
-# Copyright (C) 2004, 2008  Internet Systems Consortium, Inc. ("ISC")
-# Copyright (C) 2001  Internet Software Consortium.
-#
-# Permission to use, copy, modify, and/or 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: Makefile.in,v 1.4.18.2 2008/01/23 02:15:02 tbox Exp $
-
-srcdir =        @srcdir@
-VPATH =         @srcdir@
-top_srcdir =    @top_srcdir@
-
-HEADERS=fd_setsize.h hesiod.h irp.h irs.h netdb.h netgroup.h res_update.h \
-	resolv.h
-AHEADERS= arpa/inet.h arpa/nameser.h arpa/nameser_compat.h
-IHEADERS= isc/assertions.h isc/ctl.h isc/dst.h isc/eventlib.h isc/heap.h \
-	isc/irpmarshall.h isc/list.h isc/logging.h isc/memcluster.h \
-	isc/misc.h isc/tree.h isc/platform.h.in
-
-all:
-
-@BIND9_MAKE_RULES@
-
-installdirs:
-	$(SHELL) ${top_srcdir}/mkinstalldirs ${DESTDIR}${includedir} \
-	${DESTDIR}${includedir}/arpa ${DESTDIR}${includedir}/isc
-
-install:: installdirs
-	for i in ${HEADERS}; do \
-		${INSTALL_DATA} ${srcdir}/$$i ${DESTDIR}${includedir}; \
-	done
-	for i in ${IHEADERS}; do \
-		${INSTALL_DATA} ${srcdir}/$$i ${DESTDIR}${includedir}/isc; \
-	done
-	for i in ${AHEADERS}; do \
-		${INSTALL_DATA} ${srcdir}/$$i ${DESTDIR}${includedir}/arpa; \
-	done
-
diff --git a/contrib/bind9/lib/bind/include/arpa/inet.h b/contrib/bind9/lib/bind/include/arpa/inet.h
deleted file mode 100644
index d84987b..0000000
--- a/contrib/bind9/lib/bind/include/arpa/inet.h
+++ /dev/null
@@ -1,126 +0,0 @@
-/*
- * ++Copyright++ 1983, 1993
- * -
- * Copyright (c) 1983, 1993
- *    The Regents of the University of California.  All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- * 	This product includes software developed by the University of
- * 	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- * -
- * Portions Copyright (c) 1993 by Digital Equipment Corporation.
- * 
- * 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, and that
- * the name of Digital Equipment Corporation not be used in advertising or
- * publicity pertaining to distribution of the document or software without
- * specific, written prior permission.
- * 
- * THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
- * WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
- * OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
- * CORPORATION 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.
- * -
- * --Copyright--
- */
-
-/*%
- *	@(#)inet.h	8.1 (Berkeley) 6/2/93
- *	$Id: inet.h,v 1.2.18.1 2005/04/27 05:00:50 sra Exp $
- */
-
-#ifndef _INET_H_
-#define	_INET_H_
-
-/* External definitions for functions in inet(3) */
-
-#include <sys/param.h>
-#if (!defined(BSD)) || (BSD < 199306)
-# include <sys/bitypes.h>
-#else
-# include <sys/types.h>
-#endif
-#include <sys/cdefs.h>
-
-#define	inet_addr		__inet_addr
-#define	inet_aton		__inet_aton
-#define	inet_lnaof		__inet_lnaof
-#define	inet_makeaddr		__inet_makeaddr
-#define	inet_neta		__inet_neta
-#define	inet_netof		__inet_netof
-#define	inet_network		__inet_network
-#define	inet_net_ntop		__inet_net_ntop
-#define	inet_net_pton		__inet_net_pton
-#define	inet_cidr_ntop		__inet_cidr_ntop
-#define	inet_cidr_pton		__inet_cidr_pton
-#define	inet_ntoa		__inet_ntoa
-#define	inet_pton		__inet_pton
-#define	inet_ntop		__inet_ntop
-#define	inet_nsap_addr		__inet_nsap_addr
-#define	inet_nsap_ntoa		__inet_nsap_ntoa
-
-__BEGIN_DECLS
-unsigned long	 inet_addr __P((const char *));
-int		 inet_aton __P((const char *, struct in_addr *));
-unsigned long	 inet_lnaof __P((struct in_addr));
-struct in_addr	 inet_makeaddr __P((u_long , u_long));
-char *		 inet_neta __P((u_long, char *, size_t));
-unsigned long	 inet_netof __P((struct in_addr));
-unsigned long	 inet_network __P((const char *));
-char		*inet_net_ntop __P((int, const void *, int, char *, size_t));
-int		 inet_net_pton __P((int, const char *, void *, size_t));
-char		*inet_cidr_ntop __P((int, const void *, int, char *, size_t));
-int		 inet_cidr_pton __P((int, const char *, void *, int *));
-/*const*/ char	*inet_ntoa __P((struct in_addr));
-int		 inet_pton __P((int, const char *, void *));
-const char	*inet_ntop __P((int, const void *, char *, size_t));
-u_int		 inet_nsap_addr __P((const char *, u_char *, int));
-char		*inet_nsap_ntoa __P((int, const u_char *, char *));
-__END_DECLS
-
-#if defined(__hpux) && defined(_XOPEN_SOURCE_EXTENDED)
-/*
- * Macros for number representation conversion.
- *
- *    netinet/in.h is another location for these macros
- */
-#ifndef ntohl
-#define ntohl(x)	(x)
-#define ntohs(x)	(x)
-#define htonl(x)	(x)
-#define htons(x)	(x)
-#endif
-#endif
-
-#endif /* !_INET_H_ */
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/include/arpa/nameser.h b/contrib/bind9/lib/bind/include/arpa/nameser.h
deleted file mode 100644
index 8f8d8a7..0000000
--- a/contrib/bind9/lib/bind/include/arpa/nameser.h
+++ /dev/null
@@ -1,575 +0,0 @@
-/*
- * Copyright (c) 1983, 1989, 1993
- *    The Regents of the University of California.  All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- * 	This product includes software developed by the University of
- * 	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996-1999 by 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: nameser.h,v 1.7.18.2 2008/04/03 23:15:15 marka Exp $
- */
-
-#ifndef _ARPA_NAMESER_H_
-#define _ARPA_NAMESER_H_
-
-/*! \file */
-
-#define BIND_4_COMPAT
-
-#include <sys/param.h>
-#if (!defined(BSD)) || (BSD < 199306)
-# include <sys/bitypes.h>
-#else
-# include <sys/types.h>
-#endif
-#include <sys/cdefs.h>
-
-/*%
- * Revision information.  This is the release date in YYYYMMDD format.
- * It can change every day so the right thing to do with it is use it
- * in preprocessor commands such as "#if (__NAMESER > 19931104)".  Do not
- * compare for equality; rather, use it to determine whether your libbind.a
- * contains a new enough lib/nameser/ to support the feature you need.
- */
-
-#define __NAMESER	19991006	/*%< New interface version stamp. */
-/*
- * Define constants based on RFC0883, RFC1034, RFC 1035
- */
-#define NS_PACKETSZ	512	/*%< default UDP packet size */
-#define NS_MAXDNAME	1025	/*%< maximum domain name */
-#define NS_MAXMSG	65535	/*%< maximum message size */
-#define NS_MAXCDNAME	255	/*%< maximum compressed domain name */
-#define NS_MAXLABEL	63	/*%< maximum length of domain label */
-#define NS_HFIXEDSZ	12	/*%< #/bytes of fixed data in header */
-#define NS_QFIXEDSZ	4	/*%< #/bytes of fixed data in query */
-#define NS_RRFIXEDSZ	10	/*%< #/bytes of fixed data in r record */
-#define NS_INT32SZ	4	/*%< #/bytes of data in a u_int32_t */
-#define NS_INT16SZ	2	/*%< #/bytes of data in a u_int16_t */
-#define NS_INT8SZ	1	/*%< #/bytes of data in a u_int8_t */
-#define NS_INADDRSZ	4	/*%< IPv4 T_A */
-#define NS_IN6ADDRSZ	16	/*%< IPv6 T_AAAA */
-#define NS_CMPRSFLGS	0xc0	/*%< Flag bits indicating name compression. */
-#define NS_DEFAULTPORT	53	/*%< For both TCP and UDP. */
-/*
- * These can be expanded with synonyms, just keep ns_parse.c:ns_parserecord()
- * in synch with it.
- */
-typedef enum __ns_sect {
-	ns_s_qd = 0,		/*%< Query: Question. */
-	ns_s_zn = 0,		/*%< Update: Zone. */
-	ns_s_an = 1,		/*%< Query: Answer. */
-	ns_s_pr = 1,		/*%< Update: Prerequisites. */
-	ns_s_ns = 2,		/*%< Query: Name servers. */
-	ns_s_ud = 2,		/*%< Update: Update. */
-	ns_s_ar = 3,		/*%< Query|Update: Additional records. */
-	ns_s_max = 4
-} ns_sect;
-
-/*%
- * This is a message handle.  It is caller allocated and has no dynamic data.
- * This structure is intended to be opaque to all but ns_parse.c, thus the
- * leading _'s on the member names.  Use the accessor functions, not the _'s.
- */
-typedef struct __ns_msg {
-	const u_char	*_msg, *_eom;
-	u_int16_t	_id, _flags, _counts[ns_s_max];
-	const u_char	*_sections[ns_s_max];
-	ns_sect		_sect;
-	int		_rrnum;
-	const u_char	*_msg_ptr;
-} ns_msg;
-
-/* Private data structure - do not use from outside library. */
-struct _ns_flagdata {  int mask, shift;  };
-extern struct _ns_flagdata _ns_flagdata[];
-
-/* Accessor macros - this is part of the public interface. */
-
-#define ns_msg_id(handle) ((handle)._id + 0)
-#define ns_msg_base(handle) ((handle)._msg + 0)
-#define ns_msg_end(handle) ((handle)._eom + 0)
-#define ns_msg_size(handle) ((handle)._eom - (handle)._msg)
-#define ns_msg_count(handle, section) ((handle)._counts[section] + 0)
-
-/*%
- * This is a parsed record.  It is caller allocated and has no dynamic data.
- */
-typedef	struct __ns_rr {
-	char		name[NS_MAXDNAME];
-	u_int16_t	type;
-	u_int16_t	rr_class;
-	u_int32_t	ttl;
-	u_int16_t	rdlength;
-	const u_char *	rdata;
-} ns_rr;
-
-/* Accessor macros - this is part of the public interface. */
-#define ns_rr_name(rr)	(((rr).name[0] != '\0') ? (rr).name : ".")
-#define ns_rr_type(rr)	((ns_type)((rr).type + 0))
-#define ns_rr_class(rr)	((ns_class)((rr).rr_class + 0))
-#define ns_rr_ttl(rr)	((rr).ttl + 0)
-#define ns_rr_rdlen(rr)	((rr).rdlength + 0)
-#define ns_rr_rdata(rr)	((rr).rdata + 0)
-
-/*%
- * These don't have to be in the same order as in the packet flags word,
- * and they can even overlap in some cases, but they will need to be kept
- * in synch with ns_parse.c:ns_flagdata[].
- */
-typedef enum __ns_flag {
-	ns_f_qr,		/*%< Question/Response. */
-	ns_f_opcode,		/*%< Operation code. */
-	ns_f_aa,		/*%< Authoritative Answer. */
-	ns_f_tc,		/*%< Truncation occurred. */
-	ns_f_rd,		/*%< Recursion Desired. */
-	ns_f_ra,		/*%< Recursion Available. */
-	ns_f_z,			/*%< MBZ. */
-	ns_f_ad,		/*%< Authentic Data (DNSSEC). */
-	ns_f_cd,		/*%< Checking Disabled (DNSSEC). */
-	ns_f_rcode,		/*%< Response code. */
-	ns_f_max
-} ns_flag;
-
-/*%
- * Currently defined opcodes.
- */
-typedef enum __ns_opcode {
-	ns_o_query = 0,		/*%< Standard query. */
-	ns_o_iquery = 1,	/*%< Inverse query (deprecated/unsupported). */
-	ns_o_status = 2,	/*%< Name server status query (unsupported). */
-				/* Opcode 3 is undefined/reserved. */
-	ns_o_notify = 4,	/*%< Zone change notification. */
-	ns_o_update = 5,	/*%< Zone update message. */
-	ns_o_max = 6
-} ns_opcode;
-
-/*%
- * Currently defined response codes.
- */
-typedef	enum __ns_rcode {
-	ns_r_noerror = 0,	/*%< No error occurred. */
-	ns_r_formerr = 1,	/*%< Format error. */
-	ns_r_servfail = 2,	/*%< Server failure. */
-	ns_r_nxdomain = 3,	/*%< Name error. */
-	ns_r_notimpl = 4,	/*%< Unimplemented. */
-	ns_r_refused = 5,	/*%< Operation refused. */
-	/* these are for BIND_UPDATE */
-	ns_r_yxdomain = 6,	/*%< Name exists */
-	ns_r_yxrrset = 7,	/*%< RRset exists */
-	ns_r_nxrrset = 8,	/*%< RRset does not exist */
-	ns_r_notauth = 9,	/*%< Not authoritative for zone */
-	ns_r_notzone = 10,	/*%< Zone of record different from zone section */
-	ns_r_max = 11,
-	/* The following are EDNS extended rcodes */
-	ns_r_badvers = 16,
-	/* The following are TSIG errors */
-	ns_r_badsig = 16,
-	ns_r_badkey = 17,
-	ns_r_badtime = 18
-} ns_rcode;
-
-/* BIND_UPDATE */
-typedef enum __ns_update_operation {
-	ns_uop_delete = 0,
-	ns_uop_add = 1,
-	ns_uop_max = 2
-} ns_update_operation;
-
-/*%
- * This structure is used for TSIG authenticated messages
- */
-struct ns_tsig_key {
-        char name[NS_MAXDNAME], alg[NS_MAXDNAME];
-        unsigned char *data;
-        int len;
-};
-typedef struct ns_tsig_key ns_tsig_key;
-
-/*%
- * This structure is used for TSIG authenticated TCP messages
- */
-struct ns_tcp_tsig_state {
-	int counter;
-	struct dst_key *key;
-	void *ctx;
-	unsigned char sig[NS_PACKETSZ];
-	int siglen;
-};
-typedef struct ns_tcp_tsig_state ns_tcp_tsig_state;
-
-#define NS_TSIG_FUDGE 300
-#define NS_TSIG_TCP_COUNT 100
-#define NS_TSIG_ALG_HMAC_MD5 "HMAC-MD5.SIG-ALG.REG.INT"
-
-#define NS_TSIG_ERROR_NO_TSIG -10
-#define NS_TSIG_ERROR_NO_SPACE -11
-#define NS_TSIG_ERROR_FORMERR -12
-
-/*%
- * Currently defined type values for resources and queries.
- */
-typedef enum __ns_type {
-	ns_t_invalid = 0,	/*%< Cookie. */
-	ns_t_a = 1,		/*%< Host address. */
-	ns_t_ns = 2,		/*%< Authoritative server. */
-	ns_t_md = 3,		/*%< Mail destination. */
-	ns_t_mf = 4,		/*%< Mail forwarder. */
-	ns_t_cname = 5,		/*%< Canonical name. */
-	ns_t_soa = 6,		/*%< Start of authority zone. */
-	ns_t_mb = 7,		/*%< Mailbox domain name. */
-	ns_t_mg = 8,		/*%< Mail group member. */
-	ns_t_mr = 9,		/*%< Mail rename name. */
-	ns_t_null = 10,		/*%< Null resource record. */
-	ns_t_wks = 11,		/*%< Well known service. */
-	ns_t_ptr = 12,		/*%< Domain name pointer. */
-	ns_t_hinfo = 13,	/*%< Host information. */
-	ns_t_minfo = 14,	/*%< Mailbox information. */
-	ns_t_mx = 15,		/*%< Mail routing information. */
-	ns_t_txt = 16,		/*%< Text strings. */
-	ns_t_rp = 17,		/*%< Responsible person. */
-	ns_t_afsdb = 18,	/*%< AFS cell database. */
-	ns_t_x25 = 19,		/*%< X_25 calling address. */
-	ns_t_isdn = 20,		/*%< ISDN calling address. */
-	ns_t_rt = 21,		/*%< Router. */
-	ns_t_nsap = 22,		/*%< NSAP address. */
-	ns_t_nsap_ptr = 23,	/*%< Reverse NSAP lookup (deprecated). */
-	ns_t_sig = 24,		/*%< Security signature. */
-	ns_t_key = 25,		/*%< Security key. */
-	ns_t_px = 26,		/*%< X.400 mail mapping. */
-	ns_t_gpos = 27,		/*%< Geographical position (withdrawn). */
-	ns_t_aaaa = 28,		/*%< Ip6 Address. */
-	ns_t_loc = 29,		/*%< Location Information. */
-	ns_t_nxt = 30,		/*%< Next domain (security). */
-	ns_t_eid = 31,		/*%< Endpoint identifier. */
-	ns_t_nimloc = 32,	/*%< Nimrod Locator. */
-	ns_t_srv = 33,		/*%< Server Selection. */
-	ns_t_atma = 34,		/*%< ATM Address */
-	ns_t_naptr = 35,	/*%< Naming Authority PoinTeR */
-	ns_t_kx = 36,		/*%< Key Exchange */
-	ns_t_cert = 37,		/*%< Certification record */
-	ns_t_a6 = 38,		/*%< IPv6 address (deprecates AAAA) */
-	ns_t_dname = 39,	/*%< Non-terminal DNAME (for IPv6) */
-	ns_t_sink = 40,		/*%< Kitchen sink (experimentatl) */
-	ns_t_opt = 41,		/*%< EDNS0 option (meta-RR) */
-	ns_t_apl = 42,		/*%< Address prefix list (RFC3123) */
-	ns_t_tkey = 249,	/*%< Transaction key */
-	ns_t_tsig = 250,	/*%< Transaction signature. */
-	ns_t_ixfr = 251,	/*%< Incremental zone transfer. */
-	ns_t_axfr = 252,	/*%< Transfer zone of authority. */
-	ns_t_mailb = 253,	/*%< Transfer mailbox records. */
-	ns_t_maila = 254,	/*%< Transfer mail agent records. */
-	ns_t_any = 255,		/*%< Wildcard match. */
-	ns_t_zxfr = 256,	/*%< BIND-specific, nonstandard. */
-	ns_t_max = 65536
-} ns_type;
-
-/* Exclusively a QTYPE? (not also an RTYPE) */
-#define	ns_t_qt_p(t) (ns_t_xfr_p(t) || (t) == ns_t_any || \
-		      (t) == ns_t_mailb || (t) == ns_t_maila)
-/* Some kind of meta-RR? (not a QTYPE, but also not an RTYPE) */
-#define	ns_t_mrr_p(t) ((t) == ns_t_tsig || (t) == ns_t_opt)
-/* Exclusively an RTYPE? (not also a QTYPE or a meta-RR) */
-#define ns_t_rr_p(t) (!ns_t_qt_p(t) && !ns_t_mrr_p(t))
-#define ns_t_udp_p(t) ((t) != ns_t_axfr && (t) != ns_t_zxfr)
-#define ns_t_xfr_p(t) ((t) == ns_t_axfr || (t) == ns_t_ixfr || \
-		       (t) == ns_t_zxfr)
-
-/*%
- * Values for class field
- */
-typedef enum __ns_class {
-	ns_c_invalid = 0,	/*%< Cookie. */
-	ns_c_in = 1,		/*%< Internet. */
-	ns_c_2 = 2,		/*%< unallocated/unsupported. */
-	ns_c_chaos = 3,		/*%< MIT Chaos-net. */
-	ns_c_hs = 4,		/*%< MIT Hesiod. */
-	/* Query class values which do not appear in resource records */
-	ns_c_none = 254,	/*%< for prereq. sections in update requests */
-	ns_c_any = 255,		/*%< Wildcard match. */
-	ns_c_max = 65536
-} ns_class;
-
-/* DNSSEC constants. */
-
-typedef enum __ns_key_types {
-	ns_kt_rsa = 1,		/*%< key type RSA/MD5 */
-	ns_kt_dh  = 2,		/*%< Diffie Hellman */
-	ns_kt_dsa = 3,		/*%< Digital Signature Standard (MANDATORY) */
-	ns_kt_private = 254	/*%< Private key type starts with OID */
-} ns_key_types;
-
-typedef enum __ns_cert_types {
-	cert_t_pkix = 1,	/*%< PKIX (X.509v3) */
-	cert_t_spki = 2,	/*%< SPKI */
-	cert_t_pgp  = 3,	/*%< PGP */
-	cert_t_url  = 253,	/*%< URL private type */
-	cert_t_oid  = 254	/*%< OID private type */
-} ns_cert_types;
-
-/* Flags field of the KEY RR rdata. */
-#define	NS_KEY_TYPEMASK		0xC000	/*%< Mask for "type" bits */
-#define	NS_KEY_TYPE_AUTH_CONF	0x0000	/*%< Key usable for both */
-#define	NS_KEY_TYPE_CONF_ONLY	0x8000	/*%< Key usable for confidentiality */
-#define	NS_KEY_TYPE_AUTH_ONLY	0x4000	/*%< Key usable for authentication */
-#define	NS_KEY_TYPE_NO_KEY	0xC000	/*%< No key usable for either; no key */
-/* The type bits can also be interpreted independently, as single bits: */
-#define	NS_KEY_NO_AUTH		0x8000	/*%< Key unusable for authentication */
-#define	NS_KEY_NO_CONF		0x4000	/*%< Key unusable for confidentiality */
-#define	NS_KEY_RESERVED2	0x2000	/* Security is *mandatory* if bit=0 */
-#define	NS_KEY_EXTENDED_FLAGS	0x1000	/*%< reserved - must be zero */
-#define	NS_KEY_RESERVED4	0x0800  /*%< reserved - must be zero */
-#define	NS_KEY_RESERVED5	0x0400  /*%< reserved - must be zero */
-#define	NS_KEY_NAME_TYPE	0x0300	/*%< these bits determine the type */
-#define	NS_KEY_NAME_USER	0x0000	/*%< key is assoc. with user */
-#define	NS_KEY_NAME_ENTITY	0x0200	/*%< key is assoc. with entity eg host */
-#define	NS_KEY_NAME_ZONE	0x0100	/*%< key is zone key */
-#define	NS_KEY_NAME_RESERVED	0x0300	/*%< reserved meaning */
-#define	NS_KEY_RESERVED8	0x0080  /*%< reserved - must be zero */
-#define	NS_KEY_RESERVED9	0x0040  /*%< reserved - must be zero */
-#define	NS_KEY_RESERVED10	0x0020  /*%< reserved - must be zero */
-#define	NS_KEY_RESERVED11	0x0010  /*%< reserved - must be zero */
-#define	NS_KEY_SIGNATORYMASK	0x000F	/*%< key can sign RR's of same name */
-#define	NS_KEY_RESERVED_BITMASK ( NS_KEY_RESERVED2 | \
-				  NS_KEY_RESERVED4 | \
-				  NS_KEY_RESERVED5 | \
-				  NS_KEY_RESERVED8 | \
-				  NS_KEY_RESERVED9 | \
-				  NS_KEY_RESERVED10 | \
-				  NS_KEY_RESERVED11 )
-#define NS_KEY_RESERVED_BITMASK2 0xFFFF /*%< no bits defined here */
-/* The Algorithm field of the KEY and SIG RR's is an integer, {1..254} */
-#define	NS_ALG_MD5RSA		1	/*%< MD5 with RSA */
-#define	NS_ALG_DH               2	/*%< Diffie Hellman KEY */
-#define	NS_ALG_DSA              3	/*%< DSA KEY */
-#define	NS_ALG_DSS              NS_ALG_DSA
-#define	NS_ALG_EXPIRE_ONLY	253	/*%< No alg, no security */
-#define	NS_ALG_PRIVATE_OID	254	/*%< Key begins with OID giving alg */
-/* Protocol values  */
-/* value 0 is reserved */
-#define NS_KEY_PROT_TLS         1
-#define NS_KEY_PROT_EMAIL       2
-#define NS_KEY_PROT_DNSSEC      3
-#define NS_KEY_PROT_IPSEC       4
-#define NS_KEY_PROT_ANY		255
-
-/* Signatures */
-#define	NS_MD5RSA_MIN_BITS	 512	/*%< Size of a mod or exp in bits */
-#define	NS_MD5RSA_MAX_BITS	4096
-	/* Total of binary mod and exp */
-#define	NS_MD5RSA_MAX_BYTES	((NS_MD5RSA_MAX_BITS+7/8)*2+3)
-	/* Max length of text sig block */
-#define	NS_MD5RSA_MAX_BASE64	(((NS_MD5RSA_MAX_BYTES+2)/3)*4)
-#define NS_MD5RSA_MIN_SIZE	((NS_MD5RSA_MIN_BITS+7)/8)
-#define NS_MD5RSA_MAX_SIZE	((NS_MD5RSA_MAX_BITS+7)/8)
-
-#define NS_DSA_SIG_SIZE         41
-#define NS_DSA_MIN_SIZE         213
-#define NS_DSA_MAX_BYTES        405
-
-/* Offsets into SIG record rdata to find various values */
-#define	NS_SIG_TYPE	0	/*%< Type flags */
-#define	NS_SIG_ALG	2	/*%< Algorithm */
-#define	NS_SIG_LABELS	3	/*%< How many labels in name */
-#define	NS_SIG_OTTL	4	/*%< Original TTL */
-#define	NS_SIG_EXPIR	8	/*%< Expiration time */
-#define	NS_SIG_SIGNED	12	/*%< Signature time */
-#define	NS_SIG_FOOT	16	/*%< Key footprint */
-#define	NS_SIG_SIGNER	18	/*%< Domain name of who signed it */
-/* How RR types are represented as bit-flags in NXT records */
-#define	NS_NXT_BITS 8
-#define	NS_NXT_BIT_SET(  n,p) (p[(n)/NS_NXT_BITS] |=  (0x80>>((n)%NS_NXT_BITS)))
-#define	NS_NXT_BIT_CLEAR(n,p) (p[(n)/NS_NXT_BITS] &= ~(0x80>>((n)%NS_NXT_BITS)))
-#define	NS_NXT_BIT_ISSET(n,p) (p[(n)/NS_NXT_BITS] &   (0x80>>((n)%NS_NXT_BITS)))
-#define NS_NXT_MAX 127
-
-/*%
- * EDNS0 extended flags and option codes, host order.
- */
-#define NS_OPT_DNSSEC_OK	0x8000U
-#define NS_OPT_NSID             3
-
-/*%
- * Inline versions of get/put short/long.  Pointer is advanced.
- */
-#define NS_GET16(s, cp) do { \
-	register const u_char *t_cp = (const u_char *)(cp); \
-	(s) = ((u_int16_t)t_cp[0] << 8) \
-	    | ((u_int16_t)t_cp[1]) \
-	    ; \
-	(cp) += NS_INT16SZ; \
-} while (0)
-
-#define NS_GET32(l, cp) do { \
-	register const u_char *t_cp = (const u_char *)(cp); \
-	(l) = ((u_int32_t)t_cp[0] << 24) \
-	    | ((u_int32_t)t_cp[1] << 16) \
-	    | ((u_int32_t)t_cp[2] << 8) \
-	    | ((u_int32_t)t_cp[3]) \
-	    ; \
-	(cp) += NS_INT32SZ; \
-} while (0)
-
-#define NS_PUT16(s, cp) do { \
-	register u_int16_t t_s = (u_int16_t)(s); \
-	register u_char *t_cp = (u_char *)(cp); \
-	*t_cp++ = t_s >> 8; \
-	*t_cp   = t_s; \
-	(cp) += NS_INT16SZ; \
-} while (0)
-
-#define NS_PUT32(l, cp) do { \
-	register u_int32_t t_l = (u_int32_t)(l); \
-	register u_char *t_cp = (u_char *)(cp); \
-	*t_cp++ = t_l >> 24; \
-	*t_cp++ = t_l >> 16; \
-	*t_cp++ = t_l >> 8; \
-	*t_cp   = t_l; \
-	(cp) += NS_INT32SZ; \
-} while (0)
-
-/*%
- * ANSI C identifier hiding for bind's lib/nameser.
- */
-#define	ns_msg_getflag		__ns_msg_getflag
-#define ns_get16		__ns_get16
-#define ns_get32		__ns_get32
-#define ns_put16		__ns_put16
-#define ns_put32		__ns_put32
-#define ns_initparse		__ns_initparse
-#define ns_skiprr		__ns_skiprr
-#define ns_parserr		__ns_parserr
-#define	ns_sprintrr		__ns_sprintrr
-#define	ns_sprintrrf		__ns_sprintrrf
-#define	ns_format_ttl		__ns_format_ttl
-#define	ns_parse_ttl		__ns_parse_ttl
-#define ns_datetosecs		__ns_datetosecs
-#define	ns_name_ntol		__ns_name_ntol
-#define	ns_name_ntop		__ns_name_ntop
-#define	ns_name_pton		__ns_name_pton
-#define	ns_name_unpack		__ns_name_unpack
-#define	ns_name_pack		__ns_name_pack
-#define	ns_name_compress	__ns_name_compress
-#define	ns_name_uncompress	__ns_name_uncompress
-#define	ns_name_skip		__ns_name_skip
-#define	ns_name_rollback	__ns_name_rollback
-#define	ns_sign			__ns_sign
-#define	ns_sign2		__ns_sign2
-#define	ns_sign_tcp		__ns_sign_tcp
-#define	ns_sign_tcp2		__ns_sign_tcp2
-#define	ns_sign_tcp_init	__ns_sign_tcp_init
-#define ns_find_tsig		__ns_find_tsig
-#define	ns_verify		__ns_verify
-#define	ns_verify_tcp		__ns_verify_tcp
-#define	ns_verify_tcp_init	__ns_verify_tcp_init
-#define	ns_samedomain		__ns_samedomain
-#define	ns_subdomain		__ns_subdomain
-#define	ns_makecanon		__ns_makecanon
-#define	ns_samename		__ns_samename
-
-__BEGIN_DECLS
-int		ns_msg_getflag __P((ns_msg, int));
-u_int		ns_get16 __P((const u_char *));
-u_long		ns_get32 __P((const u_char *));
-void		ns_put16 __P((u_int, u_char *));
-void		ns_put32 __P((u_long, u_char *));
-int		ns_initparse __P((const u_char *, int, ns_msg *));
-int		ns_skiprr __P((const u_char *, const u_char *, ns_sect, int));
-int		ns_parserr __P((ns_msg *, ns_sect, int, ns_rr *));
-int		ns_sprintrr __P((const ns_msg *, const ns_rr *,
-				 const char *, const char *, char *, size_t));
-int		ns_sprintrrf __P((const u_char *, size_t, const char *,
-				  ns_class, ns_type, u_long, const u_char *,
-				  size_t, const char *, const char *,
-				  char *, size_t));
-int		ns_format_ttl __P((u_long, char *, size_t));
-int		ns_parse_ttl __P((const char *, u_long *));
-u_int32_t	ns_datetosecs __P((const char *cp, int *errp));
-int		ns_name_ntol __P((const u_char *, u_char *, size_t));
-int		ns_name_ntop __P((const u_char *, char *, size_t));
-int		ns_name_pton __P((const char *, u_char *, size_t));
-int		ns_name_unpack __P((const u_char *, const u_char *,
-				    const u_char *, u_char *, size_t));
-int		ns_name_pack __P((const u_char *, u_char *, int,
-				  const u_char **, const u_char **));
-int		ns_name_uncompress __P((const u_char *, const u_char *,
-					const u_char *, char *, size_t));
-int		ns_name_compress __P((const char *, u_char *, size_t,
-				      const u_char **, const u_char **));
-int		ns_name_skip __P((const u_char **, const u_char *));
-void		ns_name_rollback __P((const u_char *, const u_char **,
-				      const u_char **));
-int		ns_sign __P((u_char *, int *, int, int, void *,
-			     const u_char *, int, u_char *, int *, time_t));
-int		ns_sign2 __P((u_char *, int *, int, int, void *,
-			      const u_char *, int, u_char *, int *, time_t,
-			      u_char **, u_char **));
-int		ns_sign_tcp __P((u_char *, int *, int, int,
-				 ns_tcp_tsig_state *, int));
-int		ns_sign_tcp2 __P((u_char *, int *, int, int,
-				  ns_tcp_tsig_state *, int,
-				  u_char **, u_char **));
-int		ns_sign_tcp_init __P((void *, const u_char *, int,
-					ns_tcp_tsig_state *));
-u_char		*ns_find_tsig __P((u_char *, u_char *));
-int		ns_verify __P((u_char *, int *, void *,
-			       const u_char *, int, u_char *, int *,
-			       time_t *, int));
-int		ns_verify_tcp __P((u_char *, int *, ns_tcp_tsig_state *, int));
-int		ns_verify_tcp_init __P((void *, const u_char *, int,
-					ns_tcp_tsig_state *));
-int		ns_samedomain __P((const char *, const char *));
-int		ns_subdomain __P((const char *, const char *));
-int		ns_makecanon __P((const char *, char *, size_t));
-int		ns_samename __P((const char *, const char *));
-__END_DECLS
-
-#ifdef BIND_4_COMPAT
-#include <arpa/nameser_compat.h>
-#endif
-
-#endif /* !_ARPA_NAMESER_H_ */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/include/arpa/nameser_compat.h b/contrib/bind9/lib/bind/include/arpa/nameser_compat.h
deleted file mode 100644
index 3713293..0000000
--- a/contrib/bind9/lib/bind/include/arpa/nameser_compat.h
+++ /dev/null
@@ -1,232 +0,0 @@
-/* Copyright (c) 1983, 1989
- *    The Regents of the University of California.  All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- * 	This product includes software developed by the University of
- * 	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-/*%
- *      from nameser.h	8.1 (Berkeley) 6/2/93
- *	$Id: nameser_compat.h,v 1.5.18.3 2006/05/19 02:36:00 marka Exp $
- */
-
-#ifndef _ARPA_NAMESER_COMPAT_
-#define	_ARPA_NAMESER_COMPAT_
-
-#define	__BIND		19950621	/*%< (DEAD) interface version stamp. */
-#ifndef BYTE_ORDER
-#if (BSD >= 199103)
-# include <machine/endian.h>
-#else
-#ifdef __linux
-# include <endian.h>
-#else
-#define	LITTLE_ENDIAN	1234	/*%< least-significant byte first (vax, pc) */
-#define	BIG_ENDIAN	4321	/*%< most-significant byte first (IBM, net) */
-#define	PDP_ENDIAN	3412	/*%< LSB first in word, MSW first in long (pdp) */
-#if defined(vax) || defined(ns32000) || defined(sun386) || defined(i386) || \
-    defined(__i386__) || defined(__i386) || defined(__amd64__) || \
-    defined(__x86_64__) || defined(MIPSEL) || defined(_MIPSEL) || \
-    defined(BIT_ZERO_ON_RIGHT) || defined(__alpha__) || defined(__alpha) || \
-    (defined(__Lynx__) && defined(__x86__))
-#define BYTE_ORDER	LITTLE_ENDIAN
-#endif
-
-#if defined(sel) || defined(pyr) || defined(mc68000) || defined(sparc) || \
-    defined(is68k) || defined(tahoe) || defined(ibm032) || defined(ibm370) || \
-    defined(MIPSEB) || defined(_MIPSEB) || defined(_IBMR2) || defined(DGUX) ||\
-    defined(apollo) || defined(__convex__) || defined(_CRAY) || \
-    defined(__hppa) || defined(__hp9000) || \
-    defined(__hp9000s300) || defined(__hp9000s700) || \
-    defined(__hp3000s900) || defined(__hpux) || defined(MPE) || \
-    defined (BIT_ZERO_ON_LEFT) || defined(m68k) || defined(__sparc) ||  \
-    (defined(__Lynx__) && \
-     (defined(__68k__) || defined(__sparc__) || defined(__powerpc__)))
-#define BYTE_ORDER	BIG_ENDIAN
-#endif
-#endif /* __linux */
-#endif /* BSD */
-#endif /* BYTE_ORDER */
-
-#if !defined(BYTE_ORDER) || \
-    (BYTE_ORDER != BIG_ENDIAN && BYTE_ORDER != LITTLE_ENDIAN && \
-    BYTE_ORDER != PDP_ENDIAN)
-	/* you must determine what the correct bit order is for
-	 * your compiler - the next line is an intentional error
-	 * which will force your compiles to bomb until you fix
-	 * the above macros.
-	 */
-  error "Undefined or invalid BYTE_ORDER";
-#endif
-
-/*%
- * Structure for query header.  The order of the fields is machine- and
- * compiler-dependent, depending on the byte/bit order and the layout
- * of bit fields.  We use bit fields only in int variables, as this
- * is all ANSI requires.  This requires a somewhat confusing rearrangement.
- */
-
-typedef struct {
-	unsigned	id :16;		/*%< query identification number */
-#if BYTE_ORDER == BIG_ENDIAN
-			/* fields in third byte */
-	unsigned	qr: 1;		/*%< response flag */
-	unsigned	opcode: 4;	/*%< purpose of message */
-	unsigned	aa: 1;		/*%< authoritive answer */
-	unsigned	tc: 1;		/*%< truncated message */
-	unsigned	rd: 1;		/*%< recursion desired */
-			/* fields in fourth byte */
-	unsigned	ra: 1;		/*%< recursion available */
-	unsigned	unused :1;	/*%< unused bits (MBZ as of 4.9.3a3) */
-	unsigned	ad: 1;		/*%< authentic data from named */
-	unsigned	cd: 1;		/*%< checking disabled by resolver */
-	unsigned	rcode :4;	/*%< response code */
-#endif
-#if BYTE_ORDER == LITTLE_ENDIAN || BYTE_ORDER == PDP_ENDIAN
-			/* fields in third byte */
-	unsigned	rd :1;		/*%< recursion desired */
-	unsigned	tc :1;		/*%< truncated message */
-	unsigned	aa :1;		/*%< authoritive answer */
-	unsigned	opcode :4;	/*%< purpose of message */
-	unsigned	qr :1;		/*%< response flag */
-			/* fields in fourth byte */
-	unsigned	rcode :4;	/*%< response code */
-	unsigned	cd: 1;		/*%< checking disabled by resolver */
-	unsigned	ad: 1;		/*%< authentic data from named */
-	unsigned	unused :1;	/*%< unused bits (MBZ as of 4.9.3a3) */
-	unsigned	ra :1;		/*%< recursion available */
-#endif
-			/* remaining bytes */
-	unsigned	qdcount :16;	/*%< number of question entries */
-	unsigned	ancount :16;	/*%< number of answer entries */
-	unsigned	nscount :16;	/*%< number of authority entries */
-	unsigned	arcount :16;	/*%< number of resource entries */
-} HEADER;
-
-#define PACKETSZ	NS_PACKETSZ
-#define MAXDNAME	NS_MAXDNAME
-#define MAXCDNAME	NS_MAXCDNAME
-#define MAXLABEL	NS_MAXLABEL
-#define	HFIXEDSZ	NS_HFIXEDSZ
-#define QFIXEDSZ	NS_QFIXEDSZ
-#define RRFIXEDSZ	NS_RRFIXEDSZ
-#define	INT32SZ		NS_INT32SZ
-#define	INT16SZ		NS_INT16SZ
-#define	INT8SZ		NS_INT8SZ
-#define	INADDRSZ	NS_INADDRSZ
-#define	IN6ADDRSZ	NS_IN6ADDRSZ
-#define	INDIR_MASK	NS_CMPRSFLGS
-#define NAMESERVER_PORT	NS_DEFAULTPORT
-
-#define S_ZONE		ns_s_zn
-#define S_PREREQ	ns_s_pr
-#define S_UPDATE	ns_s_ud
-#define S_ADDT		ns_s_ar
-
-#define QUERY		ns_o_query
-#define IQUERY		ns_o_iquery
-#define STATUS		ns_o_status
-#define	NS_NOTIFY_OP	ns_o_notify
-#define	NS_UPDATE_OP	ns_o_update
-
-#define NOERROR		ns_r_noerror
-#define FORMERR		ns_r_formerr
-#define SERVFAIL	ns_r_servfail
-#define NXDOMAIN	ns_r_nxdomain
-#define NOTIMP		ns_r_notimpl
-#define REFUSED		ns_r_refused
-#define YXDOMAIN	ns_r_yxdomain
-#define YXRRSET		ns_r_yxrrset
-#define NXRRSET		ns_r_nxrrset
-#define NOTAUTH		ns_r_notauth
-#define NOTZONE		ns_r_notzone
-/*#define BADSIG		ns_r_badsig*/
-/*#define BADKEY		ns_r_badkey*/
-/*#define BADTIME		ns_r_badtime*/
-
-
-#define DELETE		ns_uop_delete
-#define ADD		ns_uop_add
-
-#define T_A		ns_t_a
-#define T_NS		ns_t_ns
-#define T_MD		ns_t_md
-#define T_MF		ns_t_mf
-#define T_CNAME		ns_t_cname
-#define T_SOA		ns_t_soa
-#define T_MB		ns_t_mb
-#define T_MG		ns_t_mg
-#define T_MR		ns_t_mr
-#define T_NULL		ns_t_null
-#define T_WKS		ns_t_wks
-#define T_PTR		ns_t_ptr
-#define T_HINFO		ns_t_hinfo
-#define T_MINFO		ns_t_minfo
-#define T_MX		ns_t_mx
-#define T_TXT		ns_t_txt
-#define	T_RP		ns_t_rp
-#define T_AFSDB		ns_t_afsdb
-#define T_X25		ns_t_x25
-#define T_ISDN		ns_t_isdn
-#define T_RT		ns_t_rt
-#define T_NSAP		ns_t_nsap
-#define T_NSAP_PTR	ns_t_nsap_ptr
-#define	T_SIG		ns_t_sig
-#define	T_KEY		ns_t_key
-#define	T_PX		ns_t_px
-#define	T_GPOS		ns_t_gpos
-#define	T_AAAA		ns_t_aaaa
-#define	T_LOC		ns_t_loc
-#define	T_NXT		ns_t_nxt
-#define	T_EID		ns_t_eid
-#define	T_NIMLOC	ns_t_nimloc
-#define	T_SRV		ns_t_srv
-#define T_ATMA		ns_t_atma
-#define T_NAPTR		ns_t_naptr
-#define T_A6		ns_t_a6
-#define	T_TSIG		ns_t_tsig
-#define	T_IXFR		ns_t_ixfr
-#define T_AXFR		ns_t_axfr
-#define T_MAILB		ns_t_mailb
-#define T_MAILA		ns_t_maila
-#define T_ANY		ns_t_any
-
-#define C_IN		ns_c_in
-#define C_CHAOS		ns_c_chaos
-#define C_HS		ns_c_hs
-/* BIND_UPDATE */
-#define C_NONE		ns_c_none
-#define C_ANY		ns_c_any
-
-#define	GETSHORT		NS_GET16
-#define	GETLONG			NS_GET32
-#define	PUTSHORT		NS_PUT16
-#define	PUTLONG			NS_PUT32
-
-#endif /* _ARPA_NAMESER_COMPAT_ */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/include/fd_setsize.h b/contrib/bind9/lib/bind/include/fd_setsize.h
deleted file mode 100644
index 0e21049..0000000
--- a/contrib/bind9/lib/bind/include/fd_setsize.h
+++ /dev/null
@@ -1,10 +0,0 @@
-#ifndef _FD_SETSIZE_H
-#define _FD_SETSIZE_H
-
-/*%
- * If you need a bigger FD_SETSIZE, this is NOT the place to set it.
- * This file is a fallback for BIND ports which don't specify their own.
- */
-
-#endif /* _FD_SETSIZE_H */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/include/hesiod.h b/contrib/bind9/lib/bind/include/hesiod.h
deleted file mode 100644
index 30c08d0..0000000
--- a/contrib/bind9/lib/bind/include/hesiod.h
+++ /dev/null
@@ -1,39 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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 
- * \brief
- * This file is primarily maintained by <tytso@mit.edu> and <ghudson@mit.edu>.
- */
-
-/*
- * $Id: hesiod.h,v 1.3.18.1 2005/04/27 05:00:49 sra Exp $
- */
-
-#ifndef _HESIOD_H_INCLUDED
-#define _HESIOD_H_INCLUDED
-
-int		hesiod_init __P((void **));
-void		hesiod_end __P((void *));
-char *		hesiod_to_bind __P((void *, const char *, const char *));
-char **		hesiod_resolve __P((void *, const char *, const char *));
-void		hesiod_free_list __P((void *, char **));
-struct __res_state * __hesiod_res_get __P((void *));
-void		__hesiod_res_set __P((void *, struct __res_state *,
-				      void (*)(void *)));
-
-#endif /*_HESIOD_H_INCLUDED*/
diff --git a/contrib/bind9/lib/bind/include/irp.h b/contrib/bind9/lib/bind/include/irp.h
deleted file mode 100644
index 21d8f48..0000000
--- a/contrib/bind9/lib/bind/include/irp.h
+++ /dev/null
@@ -1,107 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1999 by 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: irp.h,v 1.3.18.1 2005/04/27 05:00:49 sra Exp $
- */
-
-#ifndef _IRP_H_INCLUDED
-#define _IRP_H_INCLUDED
-
-/*! \file */
-
-#define IRPD_TIMEOUT 30			/*%< seconds */
-#define IRPD_MAXSESS 50			/*%< number of simultaneous sessions. */
-#define IRPD_PORT 6660			/*%< 10 times the number of the beast. */
-#define IRPD_PATH "/var/run/irpd"	/*%< af_unix socket path */
-
-/* If sets the environment variable IRPDSERVER to an IP address
-   (e.g. "192.5.5.1"), then that's the host the client expects irpd to be
-   running on. */
-#define IRPD_HOST_ENV "IRPDSERVER"
-
-/* Protocol response codes.  */
-#define IRPD_WELCOME_CODE 200
-#define IRPD_NOT_WELCOME_CODE 500
-
-#define IRPD_GETHOST_ERROR 510
-#define IRPD_GETHOST_NONE 210
-#define IRPD_GETHOST_OK 211
-#define IRPD_GETHOST_SETOK 212
-
-#define IRPD_GETNET_ERROR 520
-#define IRPD_GETNET_NONE 220
-#define IRPD_GETNET_OK 221
-#define IRPD_GETNET_SETOK 222
-
-#define IRPD_GETUSER_ERROR 530
-#define IRPD_GETUSER_NONE 230
-#define IRPD_GETUSER_OK 231
-#define IRPD_GETUSER_SETOK 232
-
-#define IRPD_GETGROUP_ERROR 540
-#define IRPD_GETGROUP_NONE 240
-#define IRPD_GETGROUP_OK 241
-#define IRPD_GETGROUP_SETOK 242
-
-#define IRPD_GETSERVICE_ERROR 550
-#define IRPD_GETSERVICE_NONE 250
-#define IRPD_GETSERVICE_OK 251
-#define IRPD_GETSERVICE_SETOK 252
-
-#define IRPD_GETPROTO_ERROR 560
-#define IRPD_GETPROTO_NONE 260
-#define IRPD_GETPROTO_OK 261
-#define IRPD_GETPROTO_SETOK 262
-
-#define IRPD_GETNETGR_ERROR 570
-#define IRPD_GETNETGR_NONE 270
-#define IRPD_GETNETGR_OK 271
-#define IRPD_GETNETGR_NOMORE 272
-#define IRPD_GETNETGR_MATCHES 273
-#define IRPD_GETNETGR_NOMATCH 274
-#define IRPD_GETNETGR_SETOK 275
-#define IRPD_GETNETGR_SETERR 276
-
-#define	irs_irp_read_body __irs_irp_read_body
-#define irs_irp_read_response __irs_irp_read_response
-#define irs_irp_disconnect __irs_irp_disconnect
-#define irs_irp_connect __irs_irp_connect
-#define irs_irp_connection_setup __irs_irp_connection_setup
-#define irs_irp_send_command __irs_irp_send_command
-
-struct irp_p;
-
-char   *irs_irp_read_body(struct irp_p *, size_t *);
-int	irs_irp_read_response(struct irp_p *, char *, size_t);
-void	irs_irp_disconnect(struct irp_p *);
-int	irs_irp_connect(struct irp_p *);
-int	irs_irp_is_connected(struct irp_p *);
-int	irs_irp_connection_setup(struct irp_p *, int *);
-#ifdef __GNUC__
-int	irs_irp_send_command(struct irp_p *, const char *, ...)
-			     __attribute__((__format__(__printf__, 2, 3)));
-#else
-int	irs_irp_send_command(struct irp_p *, const char *, ...);
-#endif
-int	irs_irp_get_full_response(struct irp_p *, int *, char *, size_t,
-				  char **, size_t *);
-int	irs_irp_read_line(struct irp_p *, char *, int);
-
-#endif
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/include/irs.h b/contrib/bind9/lib/bind/include/irs.h
deleted file mode 100644
index 582ba5b..0000000
--- a/contrib/bind9/lib/bind/include/irs.h
+++ /dev/null
@@ -1,348 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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: irs.h,v 1.4.18.1 2005/04/27 05:00:49 sra Exp $
- */
-
-#ifndef _IRS_H_INCLUDED
-#define _IRS_H_INCLUDED
-
-/*! \file */
-
-#include <sys/types.h>
-
-#include <arpa/nameser.h>
-
-#include <grp.h>
-#include <netdb.h>
-#include <resolv.h>
-#include <pwd.h>
-
-/*%
- * This is the group map class.
- */
-struct irs_gr {
-	void *		private;
-	void		(*close) __P((struct irs_gr *));
-	struct group *	(*next) __P((struct irs_gr *));
-	struct group *	(*byname) __P((struct irs_gr *, const char *));
-	struct group *	(*bygid) __P((struct irs_gr *, gid_t));
-	int		(*list) __P((struct irs_gr *, const char *,
-				     gid_t, gid_t *, int *));
-	void		(*rewind) __P((struct irs_gr *));
-	void		(*minimize) __P((struct irs_gr *));
-	struct __res_state * (*res_get) __P((struct irs_gr *));
-	void		(*res_set) __P((struct irs_gr *, res_state,
-					void (*)(void *)));
-};
-
-/*%
- * This is the password map class.
- */
-struct irs_pw {
-	void *		private;
-	void		(*close) __P((struct irs_pw *));
-	struct passwd *	(*next) __P((struct irs_pw *));
-	struct passwd *	(*byname) __P((struct irs_pw *, const char *));
-	struct passwd *	(*byuid) __P((struct irs_pw *, uid_t));
-	void		(*rewind) __P((struct irs_pw *));
-	void		(*minimize) __P((struct irs_pw *));
-	struct __res_state * (*res_get) __P((struct irs_pw *));
-	void		(*res_set) __P((struct irs_pw *, res_state,
-					void (*)(void *)));
-};
-
-/*%
- * This is the service map class.
- */
-struct irs_sv {
-	void *		private;
-	void		(*close) __P((struct irs_sv *));
-	struct servent *(*byname) __P((struct irs_sv *,
-				       const char *, const char *));
-	struct servent *(*byport) __P((struct irs_sv *, int, const char *));
-	struct servent *(*next) __P((struct irs_sv *));
-	void		(*rewind) __P((struct irs_sv *));
-	void		(*minimize) __P((struct irs_sv *));
-	struct __res_state * (*res_get) __P((struct irs_sv *));
-	void		(*res_set) __P((struct irs_sv *, res_state,
-					void (*)(void *)));
-};
-
-/*%
- * This is the protocols map class.
- */
-struct irs_pr {
-	void *		private;
-	void		(*close) __P((struct irs_pr *));
-	struct protoent	*(*byname) __P((struct irs_pr *, const char *));
-	struct protoent	*(*bynumber) __P((struct irs_pr *, int));
-	struct protoent	*(*next) __P((struct irs_pr *));
-	void		(*rewind) __P((struct irs_pr *));
-	void		(*minimize) __P((struct irs_pr *));
-	struct __res_state * (*res_get) __P((struct irs_pr *));
-	void		(*res_set) __P((struct irs_pr *, res_state,
-					void (*)(void *)));
-};
-
-/*%
- * This is the hosts map class.
- */
-struct irs_ho {
-	void *		private;
-	void		(*close) __P((struct irs_ho *));
-	struct hostent *(*byname) __P((struct irs_ho *, const char *));
-	struct hostent *(*byname2) __P((struct irs_ho *, const char *, int));
-	struct hostent *(*byaddr) __P((struct irs_ho *,
-				       const void *, int, int));
-	struct hostent *(*next) __P((struct irs_ho *));
-	void		(*rewind) __P((struct irs_ho *));
-	void		(*minimize) __P((struct irs_ho *));
-	struct __res_state * (*res_get) __P((struct irs_ho *));
-	void		(*res_set) __P((struct irs_ho *, res_state,
-					void (*)(void *)));
-	struct addrinfo *(*addrinfo) __P((struct irs_ho *, const char *,
-					  const struct addrinfo *));
-};
-
-/*%
- * This is the networks map class.
- */
-struct irs_nw {
-	void *		private;
-	void		(*close) __P((struct irs_nw *));
-	struct nwent *	(*byname) __P((struct irs_nw *, const char *, int));
-	struct nwent *	(*byaddr) __P((struct irs_nw *, void *, int, int));
-	struct nwent *	(*next) __P((struct irs_nw *));
-	void		(*rewind) __P((struct irs_nw *));
-	void		(*minimize) __P((struct irs_nw *));
-	struct __res_state * (*res_get) __P((struct irs_nw *));
-	void		(*res_set) __P((struct irs_nw *, res_state,
-					void (*)(void *)));
-};
-
-/*%
- * This is the netgroups map class.
- */
-struct irs_ng {
-	void *		private;
-	void		(*close) __P((struct irs_ng *));
-	int		(*next) __P((struct irs_ng *, const char **,
-				     const char **, const char **));
-	int		(*test) __P((struct irs_ng *, const char *,
-				     const char *, const char *,
-				     const char *));
-	void		(*rewind) __P((struct irs_ng *, const char *));
-	void		(*minimize) __P((struct irs_ng *));
-};
-
-/*%
- * This is the generic map class, which copies the front of all others.
- */
-struct irs_map {
-	void *		private;
-	void		(*close) __P((void *));
-};
-
-/*%
- * This is the accessor class.  It contains pointers to all of the
- * initializers for the map classes for a particular accessor.
- */
-struct irs_acc {
-	void *		private;
-	void		(*close) __P((struct irs_acc *));
-	struct irs_gr *	(*gr_map) __P((struct irs_acc *));
-	struct irs_pw *	(*pw_map) __P((struct irs_acc *));
-	struct irs_sv *	(*sv_map) __P((struct irs_acc *));
-	struct irs_pr *	(*pr_map) __P((struct irs_acc *));
-	struct irs_ho *	(*ho_map) __P((struct irs_acc *));
-	struct irs_nw *	(*nw_map) __P((struct irs_acc *));
-	struct irs_ng *	(*ng_map) __P((struct irs_acc *));
-	struct __res_state * (*res_get) __P((struct irs_acc *));
-	void		(*res_set) __P((struct irs_acc *, res_state,
-					void (*)(void *)));
-};
-
-/*%
- * This is because the official definition of "struct netent" has no
- * concept of CIDR even though it allows variant address families (on
- * output but not input).  The compatibility stubs convert the structs
- * below into "struct netent"'s.
- */
-struct nwent {
-	char		*n_name;	/*%< official name of net */
-	char		**n_aliases;	/*%< alias list */
-	int		n_addrtype;	/*%< net address type */
-	void		*n_addr;	/*%< network address */
-	int		n_length;	/*%< address length, in bits */
-};
-
-/*%
- * Hide external function names from POSIX.
- */
-#define	irs_gen_acc	__irs_gen_acc
-#define	irs_lcl_acc	__irs_lcl_acc
-#define	irs_dns_acc	__irs_dns_acc
-#define	irs_nis_acc	__irs_nis_acc
-#define	irs_irp_acc	__irs_irp_acc
-#define	irs_destroy	__irs_destroy
-#define	irs_dns_gr	__irs_dns_gr
-#define	irs_dns_ho	__irs_dns_ho
-#define	irs_dns_nw	__irs_dns_nw
-#define	irs_dns_pr	__irs_dns_pr
-#define	irs_dns_pw	__irs_dns_pw
-#define	irs_dns_sv	__irs_dns_sv
-#define	irs_gen_gr	__irs_gen_gr
-#define	irs_gen_ho	__irs_gen_ho
-#define	irs_gen_ng	__irs_gen_ng
-#define	irs_gen_nw	__irs_gen_nw
-#define	irs_gen_pr	__irs_gen_pr
-#define	irs_gen_pw	__irs_gen_pw
-#define	irs_gen_sv	__irs_gen_sv
-#define	irs_irp_get_full_response	__irs_irp_get_full_response
-#define	irs_irp_gr	__irs_irp_gr
-#define	irs_irp_ho	__irs_irp_ho
-#define	irs_irp_is_connected	__irs_irp_is_connected
-#define	irs_irp_ng	__irs_irp_ng
-#define	irs_irp_nw	__irs_irp_nw
-#define	irs_irp_pr	__irs_irp_pr
-#define	irs_irp_pw	__irs_irp_pw
-#define	irs_irp_read_line	__irs_irp_read_line
-#define	irs_irp_sv	__irs_irp_sv
-#define	irs_lcl_gr	__irs_lcl_gr
-#define	irs_lcl_ho	__irs_lcl_ho
-#define	irs_lcl_ng	__irs_lcl_ng
-#define	irs_lcl_nw	__irs_lcl_nw
-#define	irs_lcl_pr	__irs_lcl_pr
-#define	irs_lcl_pw	__irs_lcl_pw
-#define	irs_lcl_sv	__irs_lcl_sv
-#define	irs_nis_gr	__irs_nis_gr
-#define	irs_nis_ho	__irs_nis_ho
-#define	irs_nis_ng	__irs_nis_ng
-#define	irs_nis_nw	__irs_nis_nw
-#define	irs_nis_pr	__irs_nis_pr
-#define	irs_nis_pw	__irs_nis_pw
-#define	irs_nis_sv	__irs_nis_sv
-#define	net_data_create	__net_data_create
-#define	net_data_destroy	__net_data_destroy
-#define	net_data_minimize	__net_data_minimize
-
-/*%
- * Externs.
- */
-extern struct irs_acc *	irs_gen_acc __P((const char *, const char *));
-extern struct irs_acc *	irs_lcl_acc __P((const char *));
-extern struct irs_acc *	irs_dns_acc __P((const char *));
-extern struct irs_acc *	irs_nis_acc __P((const char *));
-extern struct irs_acc *	irs_irp_acc __P((const char *));
-
-extern void		irs_destroy __P((void));
-
-/*%
- * These forward declarations are for the semi-private functions in
- * the get*.c files. Each of these funcs implements the real get*
- * functionality and the standard versions are just wrappers that
- * call these. Apart from the wrappers, only irpd is expected to
- * call these directly, hence these decls are put here and not in
- * the /usr/include replacements.
- */
-
-struct net_data;			/*%< forward */
-/*
- * net_data_create gets a singleton net_data object.  net_data_init
- * creates as many net_data objects as times it is called.  Clients using
- * the default interface will use net_data_create by default.  Servers will
- * probably want net_data_init (one call per client)
- */
-struct net_data *net_data_create __P((const char *));
-struct net_data *net_data_init __P((const char *));
-void		net_data_destroy __P((void *));
-	
-extern struct group    *getgrent_p __P((struct net_data *));
-extern struct group    *getgrnam_p __P((const char *, struct net_data *));
-extern struct group    *getgrgid_p __P((gid_t, struct net_data *));
-extern int 		setgroupent_p __P((int, struct net_data *));
-extern void 		endgrent_p __P((struct net_data *));
-extern int		getgrouplist_p __P((const char *, gid_t, gid_t *, int *,
-					    struct net_data *));
-
-#ifdef SETGRENT_VOID
-extern void 		setgrent_p __P((struct net_data *));
-#else
-extern int 		setgrent_p __P((struct net_data *));
-#endif
-
-extern struct hostent 	*gethostbyname_p __P((const char *,
-					      struct net_data *));
-extern struct hostent 	*gethostbyname2_p __P((const char *, int,
-					       struct net_data *));
-extern struct hostent 	*gethostbyaddr_p __P((const char *, int, int,
-					      struct net_data *));
-extern struct hostent 	*gethostent_p __P((struct net_data *));
-extern void 		sethostent_p __P((int, struct net_data *));
-extern void 		endhostent_p __P((struct net_data *));
-extern struct hostent 	*getipnodebyname_p __P((const char *, int, int, int *,
-					       struct net_data *));
-extern struct hostent 	*getipnodebyaddr_p __P((const void *, size_t,
-					      int, int *, struct net_data *));
-
-extern struct netent 	*getnetent_p __P((struct net_data *));
-extern struct netent 	*getnetbyname_p __P((const char *, struct net_data *));
-extern struct netent 	*getnetbyaddr_p __P((unsigned long, int,
-					     struct net_data *));
-extern void		setnetent_p __P((int, struct net_data *));
-extern void		endnetent_p __P((struct net_data *));
-
-extern void		setnetgrent_p __P((const char *, struct net_data *));
-extern void		endnetgrent_p __P((struct net_data *));
-extern int		innetgr_p __P((const char *, const char *, const char *,
-				       const char *, struct net_data *));
-extern int		getnetgrent_p __P((const char **, const char **,
-					   const char **, struct net_data *));
-
-extern struct protoent  *getprotoent_p __P((struct net_data *));
-extern struct protoent  *getprotobyname_p __P((const char *,
-					       struct net_data *));
-extern struct protoent	*getprotobynumber_p __P((int, struct net_data *));
-extern void		setprotoent_p __P((int, struct net_data *));
-extern void		endprotoent_p __P((struct net_data *));
-
-
-extern struct passwd 	*getpwent_p __P((struct net_data *));
-extern struct passwd 	*getpwnam_p __P((const char *, struct net_data *));
-extern struct passwd 	*getpwuid_p __P((uid_t, struct net_data *));
-extern int		setpassent_p __P((int, struct net_data *));
-extern void		endpwent_p __P((struct net_data *));
-
-#ifdef SETPWENT_VOID
-extern void		setpwent_p __P((struct net_data *));
-#else
-extern int		setpwent_p __P((struct net_data *));
-#endif
-
-extern struct servent 	*getservent_p __P((struct net_data *));
-extern struct servent 	*getservbyname_p __P((const char *, const char *,
-					      struct net_data *));
-extern struct servent 	*getservbyport_p __P((int, const char *,
-					      struct net_data *));
-extern void		setservent_p __P((int, struct net_data *));
-extern void		endservent_p __P((struct net_data *));
-
-#endif /*_IRS_H_INCLUDED*/
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/include/isc/assertions.h b/contrib/bind9/lib/bind/include/isc/assertions.h
deleted file mode 100644
index 100e586..0000000
--- a/contrib/bind9/lib/bind/include/isc/assertions.h
+++ /dev/null
@@ -1,123 +0,0 @@
-/*
- * Copyright (c) 2004 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
- * 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: assertions.h,v 1.2.18.2 2008/10/15 03:57:21 marka Exp $
- */
-
-#ifndef ASSERTIONS_H
-#define ASSERTIONS_H		1
-
-typedef enum {
-	assert_require, assert_ensure, assert_insist, assert_invariant
-} assertion_type;
-
-typedef void (*assertion_failure_callback)(const char *, int, assertion_type,
-					   const char *, int);
-
-/* coverity[+kill] */
-extern assertion_failure_callback __assertion_failed;
-void set_assertion_failure_callback(assertion_failure_callback f);
-const char *assertion_type_to_text(assertion_type type);
-
-#if defined(CHECK_ALL) || defined(__COVERITY__)
-#define CHECK_REQUIRE		1
-#define CHECK_ENSURE		1
-#define CHECK_INSIST		1
-#define CHECK_INVARIANT		1
-#endif
-
-#if defined(CHECK_NONE) && !defined(__COVERITY__)
-#define CHECK_REQUIRE		0
-#define CHECK_ENSURE		0
-#define CHECK_INSIST		0
-#define CHECK_INVARIANT		0
-#endif
-
-#ifndef CHECK_REQUIRE
-#define CHECK_REQUIRE		1
-#endif
-
-#ifndef CHECK_ENSURE
-#define CHECK_ENSURE		1
-#endif
-
-#ifndef CHECK_INSIST
-#define CHECK_INSIST		1
-#endif
-
-#ifndef CHECK_INVARIANT
-#define CHECK_INVARIANT		1
-#endif
-
-#if CHECK_REQUIRE != 0
-#define REQUIRE(cond) \
-	((void) ((cond) || \
-		 ((__assertion_failed)(__FILE__, __LINE__, assert_require, \
-				       #cond, 0), 0)))
-#define REQUIRE_ERR(cond) \
-	((void) ((cond) || \
-		 ((__assertion_failed)(__FILE__, __LINE__, assert_require, \
-				       #cond, 1), 0)))
-#else
-#define REQUIRE(cond)		((void) (cond))
-#define REQUIRE_ERR(cond)	((void) (cond))
-#endif /* CHECK_REQUIRE */
-
-#if CHECK_ENSURE != 0
-#define ENSURE(cond) \
-	((void) ((cond) || \
-		 ((__assertion_failed)(__FILE__, __LINE__, assert_ensure, \
-				       #cond, 0), 0)))
-#define ENSURE_ERR(cond) \
-	((void) ((cond) || \
-		 ((__assertion_failed)(__FILE__, __LINE__, assert_ensure, \
-				       #cond, 1), 0)))
-#else
-#define ENSURE(cond)		((void) (cond))
-#define ENSURE_ERR(cond)	((void) (cond))
-#endif /* CHECK_ENSURE */
-
-#if CHECK_INSIST != 0
-#define INSIST(cond) \
-	((void) ((cond) || \
-		 ((__assertion_failed)(__FILE__, __LINE__, assert_insist, \
-				       #cond, 0), 0)))
-#define INSIST_ERR(cond) \
-	((void) ((cond) || \
-		 ((__assertion_failed)(__FILE__, __LINE__, assert_insist, \
-				       #cond, 1), 0)))
-#else
-#define INSIST(cond)		((void) (cond))
-#define INSIST_ERR(cond)	((void) (cond))
-#endif /* CHECK_INSIST */
-
-#if CHECK_INVARIANT != 0
-#define INVARIANT(cond) \
-	((void) ((cond) || \
-		 ((__assertion_failed)(__FILE__, __LINE__, assert_invariant, \
-				       #cond, 0), 0)))
-#define INVARIANT_ERR(cond) \
-	((void) ((cond) || \
-		 ((__assertion_failed)(__FILE__, __LINE__, assert_invariant, \
-				       #cond, 1), 0)))
-#else
-#define INVARIANT(cond)		((void) (cond))
-#define INVARIANT_ERR(cond)	((void) (cond))
-#endif /* CHECK_INVARIANT */
-#endif /* ASSERTIONS_H */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/include/isc/ctl.h b/contrib/bind9/lib/bind/include/isc/ctl.h
deleted file mode 100644
index 0f6fe94..0000000
--- a/contrib/bind9/lib/bind/include/isc/ctl.h
+++ /dev/null
@@ -1,112 +0,0 @@
-#ifndef ISC_CTL_H
-#define ISC_CTL_H
-
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1998,1999 by 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: ctl.h,v 1.4.18.1 2005/04/27 05:00:51 sra Exp $
- */
-
-/*! \file */
-
-#include <sys/types.h>
-#include <sys/socket.h>
-
-#include <isc/eventlib.h>
-
-/* Macros. */
-
-#define	CTL_MORE	0x0001	/*%< More will be / should be sent. */
-#define	CTL_EXIT	0x0002	/*%< Close connection after this. */
-#define	CTL_DATA	0x0004	/*%< Go into / this is DATA mode. */
-/* Types. */
-
-struct ctl_cctx;
-struct ctl_sctx;
-struct ctl_sess;
-struct ctl_verb;
-
-enum ctl_severity { ctl_debug, ctl_warning, ctl_error };
-
-typedef void (*ctl_logfunc)(enum ctl_severity, const char *, ...);
-
-typedef void (*ctl_verbfunc)(struct ctl_sctx *, struct ctl_sess *,
-			     const struct ctl_verb *, const char *,
-			     u_int, const void *, void *);
-
-typedef void (*ctl_srvrdone)(struct ctl_sctx *, struct ctl_sess *, void *);
-
-typedef void (*ctl_clntdone)(struct ctl_cctx *, void *, const char *, u_int);
-
-struct ctl_verb {
-	const char *	name;
-	ctl_verbfunc	func;
-	const char *	help;
-};
-
-/* General symbols. */
-
-#define	ctl_logger	__ctl_logger
-
-#ifdef __GNUC__
-void			ctl_logger(enum ctl_severity, const char *, ...)
-				__attribute__((__format__(__printf__, 2, 3)));
-#else
-void			ctl_logger(enum ctl_severity, const char *, ...);
-#endif
-
-/* Client symbols. */
-
-#define	ctl_client	__ctl_client
-#define	ctl_endclient	__ctl_endclient
-#define	ctl_command	__ctl_command
-
-struct ctl_cctx *	ctl_client(evContext, const struct sockaddr *, size_t,
-				   const struct sockaddr *, size_t,
-				   ctl_clntdone, void *,
-				   u_int, ctl_logfunc);
-void			ctl_endclient(struct ctl_cctx *);
-int			ctl_command(struct ctl_cctx *, const char *, size_t,
-				    ctl_clntdone, void *);
-
-/* Server symbols. */
-
-#define	ctl_server	__ctl_server
-#define	ctl_endserver	__ctl_endserver
-#define	ctl_response	__ctl_response
-#define	ctl_sendhelp	__ctl_sendhelp
-#define ctl_getcsctx	__ctl_getcsctx
-#define ctl_setcsctx	__ctl_setcsctx
-
-struct ctl_sctx *	ctl_server(evContext, const struct sockaddr *, size_t,
-				   const struct ctl_verb *,
-				   u_int, u_int,
-				   u_int, int, int,
-				   ctl_logfunc, void *);
-void			ctl_endserver(struct ctl_sctx *);
-void			ctl_response(struct ctl_sess *, u_int,
-				     const char *, u_int, const void *,
-				     ctl_srvrdone, void *,
-				     const char *, size_t);
-void			ctl_sendhelp(struct ctl_sess *, u_int);
-void *			ctl_getcsctx(struct ctl_sess *);
-void *			ctl_setcsctx(struct ctl_sess *, void *);
-
-#endif /*ISC_CTL_H*/
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/include/isc/dst.h b/contrib/bind9/lib/bind/include/isc/dst.h
deleted file mode 100644
index 90a9e67..0000000
--- a/contrib/bind9/lib/bind/include/isc/dst.h
+++ /dev/null
@@ -1,168 +0,0 @@
-#ifndef DST_H
-#define DST_H
-
-#ifndef HAS_DST_KEY
-typedef struct dst_key {
-	char	*dk_key_name;   /*%< name of the key */
-	int	dk_key_size;    /*%< this is the size of the key in bits */
-	int	dk_proto;       /*%< what protocols this key can be used for */
-	int	dk_alg;         /*%< algorithm number from key record */
-	u_int32_t dk_flags;     /*%< and the flags of the public key */
-	u_int16_t dk_id;        /*%< identifier of the key */
-} DST_KEY;
-#endif /* HAS_DST_KEY */
-/*
- * do not taint namespace
- */
-#define	dst_bsafe_init		__dst_bsafe_init
-#define	dst_buffer_to_key	__dst_buffer_to_key
-#define	dst_check_algorithm	__dst_check_algorithm
-#define	dst_compare_keys	__dst_compare_keys
-#define	dst_cylink_init		__dst_cylink_init
-#define	dst_dnskey_to_key	__dst_dnskey_to_key
-#define	dst_eay_dss_init	__dst_eay_dss_init
-#define	dst_free_key		__dst_free_key
-#define	dst_generate_key	__dst_generate_key
-#define	dst_hmac_md5_init	__dst_hmac_md5_init
-#define	dst_init		__dst_init
-#define	dst_key_to_buffer	__dst_key_to_buffer
-#define	dst_key_to_dnskey	__dst_key_to_dnskey
-#define	dst_read_key		__dst_read_key
-#define	dst_rsaref_init		__dst_rsaref_init
-#define	dst_s_build_filename	__dst_s_build_filename
-#define	dst_s_calculate_bits	__dst_s_calculate_bits
-#define	dst_s_conv_bignum_b64_to_u8	__dst_s_conv_bignum_b64_to_u8
-#define	dst_s_conv_bignum_u8_to_b64	__dst_s_conv_bignum_u8_to_b64
-#define	dst_s_dns_key_id	__dst_s_dns_key_id
-#define	dst_s_dump		__dst_s_dump
-#define	dst_s_filename_length	__dst_s_filename_length
-#define	dst_s_fopen		__dst_s_fopen
-#define	dst_s_get_int16		__dst_s_get_int16
-#define	dst_s_get_int32		__dst_s_get_int32
-#define	dst_s_id_calc		__dst_s_id_calc
-#define	dst_s_put_int16		__dst_s_put_int16
-#define	dst_s_put_int32		__dst_s_put_int32
-#define	dst_s_quick_random	__dst_s_quick_random
-#define	dst_s_quick_random_set	__dst_s_quick_random_set
-#define	dst_s_random		__dst_s_random
-#define	dst_s_semi_random	__dst_s_semi_random
-#define	dst_s_verify_str	__dst_s_verify_str
-#define	dst_sig_size		__dst_sig_size
-#define	dst_sign_data		__dst_sign_data
-#define	dst_verify_data		__dst_verify_data
-#define	dst_write_key		__dst_write_key
-
-/* 
- * DST Crypto API defintions 
- */
-void     dst_init(void);
-int      dst_check_algorithm(const int);
-
-
-int dst_sign_data(const int,	 	/*!<   specifies INIT/UPDATE/FINAL/ALL  */
-		  DST_KEY *,	 	/*!<   the key to use  */
-		  void **,	 	/*!<   pointer to state structure  */
-		  const u_char *,	/*!<   data to be signed  */
-		  const int,	 	/*!<   length of input data  */
-		  u_char *,	 	/*!<   buffer to write signature to  */
-		  const int);	 	/*!<   size of output buffer  */
-int dst_verify_data(const int,	 	/*!<   specifies INIT/UPDATE/FINAL/ALL  */
-		    DST_KEY *,	 	/*!<   the key to use  */
-		    void **,	 	/*!<   pointer to state structure  */
-		    const u_char *,	/*!<   data to be verified  */
-		    const int,	 	/*!<   length of input data  */
-		    const u_char *,	/*!<   buffer containing signature  */
-		    const int);	 	/*!<   length of signature  */
-DST_KEY *dst_read_key(const char *,	/*!<   name of key  */
-		      const u_int16_t,	/*!<   key tag identifier  */
-		      const int,	/*!<   key algorithm  */
-		      const int);	/*!<   Private/PublicKey wanted */
-int      dst_write_key(const DST_KEY *,	/*!<   key to write out  */
-		       const int); 	/*!<   Public/Private  */
-DST_KEY *dst_dnskey_to_key(const char *,	/*!<   KEY record name  */
-			   const u_char *,	/*!<   KEY RDATA  */
-			   const int);		/*!<   size of input buffer */
-int      dst_key_to_dnskey(const DST_KEY *,	/*!<   key to translate  */
-			   u_char *,		/*!<   output buffer  */
-			   const int);		/*!<   size of out_storage */
-DST_KEY *dst_buffer_to_key(const char *,  	/*!<   name of the key  */
-			   const int,	  	/*!<   algorithm  */
-			   const int,	  	/*!<   dns flags  */
-			   const int,	  	/*!<   dns protocol  */
-			   const u_char *, 	/*!<   key in dns wire fmt  */
-			   const int);	  	/*!<   size of key  */
-int     dst_key_to_buffer(DST_KEY *, u_char *, int);
-
-DST_KEY *dst_generate_key(const char *,    	/*!<   name of new key  */
-			  const int,       	/*!<   key algorithm to generate  */
-			  const int,      	/*!<   size of new key  */
-			  const int,       	/*!<   alg dependent parameter */
-			  const int,     	/*!<   key DNS flags  */
-			  const int);		/*!<   key DNS protocol  */
-DST_KEY *dst_free_key(DST_KEY *);
-int      dst_compare_keys(const DST_KEY *, const DST_KEY *);
-
-int	dst_sig_size(DST_KEY *);
-
-
-/* support for dns key tags/ids */
-u_int16_t dst_s_dns_key_id(const u_char *, const int);
-u_int16_t dst_s_id_calc(const u_char *, const int);
-
-/* Used by callers as well as by the library.  */
-#define RAW_KEY_SIZE    8192        /*%< large enough to store any key */
-/* DST_API control flags */
-/* These are used used in functions dst_sign_data and dst_verify_data */
-#define SIG_MODE_INIT		1  /*%< initialize digest */
-#define SIG_MODE_UPDATE		2  /*%< add data to digest */
-#define SIG_MODE_FINAL		4  /*%< generate/verify signature */
-#define SIG_MODE_ALL		(SIG_MODE_INIT|SIG_MODE_UPDATE|SIG_MODE_FINAL)
-
-/* Flags for dst_read_private_key()  */
-#define DST_FORCE_READ		0x1000000
-#define DST_CAN_SIGN		0x010F
-#define DST_NO_AUTHEN		0x8000
-#define DST_EXTEND_FLAG         0x1000
-#define DST_STANDARD		0
-#define DST_PRIVATE             0x2000000
-#define DST_PUBLIC              0x4000000
-#define DST_RAND_SEMI           1
-#define DST_RAND_STD            2
-#define DST_RAND_KEY            3
-#define DST_RAND_DSS            4
-
-
-/* DST algorithm codes */
-#define KEY_RSA			1
-#define KEY_DH			2
-#define KEY_DSA			3
-#define KEY_PRIVATE		254
-#define KEY_EXPAND		255
-#define KEY_HMAC_MD5		157
-#define KEY_HMAC_SHA1		158
-#define UNKNOWN_KEYALG		0
-#define DST_MAX_ALGS            KEY_HMAC_SHA1
-
-/* DST constants to locations in KEY record  changes in new KEY record */
-#define DST_FLAGS_SIZE		2
-#define DST_KEY_PROT		2
-#define DST_KEY_ALG		3
-#define DST_EXT_FLAG            4
-#define DST_KEY_START		4
-
-#ifndef SIGN_F_NOKEY 
-#define SIGN_F_NOKEY		0xC000
-#endif
-
-/* error codes from dst routines */
-#define SIGN_INIT_FAILURE	(-23)
-#define SIGN_UPDATE_FAILURE	(-24)
-#define SIGN_FINAL_FAILURE	(-25)
-#define VERIFY_INIT_FAILURE	(-26)
-#define VERIFY_UPDATE_FAILURE	(-27)
-#define VERIFY_FINAL_FAILURE	(-28)
-#define MISSING_KEY_OR_SIGNATURE (-30)
-#define UNSUPPORTED_KEYALG	(-31)
-
-#endif /* DST_H */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/include/isc/eventlib.h b/contrib/bind9/lib/bind/include/isc/eventlib.h
deleted file mode 100644
index 5003823..0000000
--- a/contrib/bind9/lib/bind/include/isc/eventlib.h
+++ /dev/null
@@ -1,206 +0,0 @@
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-/* eventlib.h - exported interfaces for eventlib
- * vix 09sep95 [initial]
- *
- * $Id: eventlib.h,v 1.3.18.3 2008/01/23 02:12:01 marka Exp $
- */
-
-#ifndef _EVENTLIB_H
-#define _EVENTLIB_H
-
-#include <sys/types.h>
-#include <sys/uio.h>
-#include <sys/time.h>
-#include <stdio.h>
-
-#include <isc/platform.h>
-
-#ifndef __P
-# define __EVENTLIB_P_DEFINED
-# ifdef __STDC__
-#  define __P(x) x
-# else
-#  define __P(x) ()
-# endif
-#endif
-
-/* In the absence of branded types... */
-typedef struct { void *opaque; } evConnID;
-typedef struct { void *opaque; } evFileID;
-typedef struct { void *opaque; } evStreamID;
-typedef struct { void *opaque; } evTimerID;
-typedef struct { void *opaque; } evWaitID;
-typedef struct { void *opaque; } evContext;
-typedef struct { void *opaque; } evEvent;
-
-#define	evInitID(id) ((id)->opaque = NULL)
-#define	evTestID(id) ((id).opaque != NULL)
-
-typedef void (*evConnFunc)__P((evContext, void *, int, const void *, int,
-			       const void *, int));
-typedef void (*evFileFunc)__P((evContext, void *, int, int));
-typedef	void (*evStreamFunc)__P((evContext, void *, int, int));
-typedef void (*evTimerFunc)__P((evContext, void *,
-				struct timespec, struct timespec));
-typedef	void (*evWaitFunc)__P((evContext, void *, const void *));
-
-typedef	struct { unsigned char mask[256/8]; } evByteMask;
-#define	EV_BYTEMASK_BYTE(b) ((b) / 8)
-#define	EV_BYTEMASK_MASK(b) (1 << ((b) % 8))
-#define	EV_BYTEMASK_SET(bm, b) \
-	((bm).mask[EV_BYTEMASK_BYTE(b)] |= EV_BYTEMASK_MASK(b))
-#define	EV_BYTEMASK_CLR(bm, b) \
-	((bm).mask[EV_BYTEMASK_BYTE(b)] &= ~EV_BYTEMASK_MASK(b))
-#define	EV_BYTEMASK_TST(bm, b) \
-	((bm).mask[EV_BYTEMASK_BYTE(b)] & EV_BYTEMASK_MASK(b))
-
-#define	EV_POLL		1
-#define	EV_WAIT		2
-#define	EV_NULL		4
-
-#define	EV_READ		1
-#define	EV_WRITE	2
-#define	EV_EXCEPT	4
-
-#define EV_WASNONBLOCKING 8	/* Internal library use. */
-
-/* eventlib.c */
-#define evCreate	__evCreate
-#define evSetDebug	__evSetDebug
-#define evDestroy	__evDestroy
-#define evGetNext	__evGetNext
-#define evDispatch	__evDispatch
-#define evDrop		__evDrop
-#define evMainLoop	__evMainLoop
-#define evHighestFD	__evHighestFD
-#define evGetOption	__evGetOption
-#define evSetOption	__evSetOption
-
-int  evCreate __P((evContext *));
-void evSetDebug __P((evContext, int, FILE *));
-int  evDestroy __P((evContext));
-int  evGetNext __P((evContext, evEvent *, int));
-int  evDispatch __P((evContext, evEvent));
-void evDrop __P((evContext, evEvent));
-int  evMainLoop __P((evContext));
-int  evHighestFD __P((evContext));
-int  evGetOption __P((evContext *, const char *, int *));
-int  evSetOption __P((evContext *, const char *, int));
-
-/* ev_connects.c */
-#define evListen	__evListen
-#define evConnect	__evConnect
-#define evCancelConn	__evCancelConn
-#define evHold		__evHold
-#define evUnhold	__evUnhold
-#define evTryAccept	__evTryAccept
-
-int evListen __P((evContext, int, int, evConnFunc, void *, evConnID *));
-int evConnect __P((evContext, int, const void *, int,
-		   evConnFunc, void *, evConnID *));
-int evCancelConn __P((evContext, evConnID));
-int evHold __P((evContext, evConnID));
-int evUnhold __P((evContext, evConnID));
-int evTryAccept __P((evContext, evConnID, int *));
-
-/* ev_files.c */
-#define evSelectFD	__evSelectFD
-#define evDeselectFD	__evDeselectFD
-
-int evSelectFD __P((evContext, int, int, evFileFunc, void *, evFileID *));
-int evDeselectFD __P((evContext, evFileID));
-
-/* ev_streams.c */
-#define evConsIovec	__evConsIovec
-#define evWrite		__evWrite
-#define evRead		__evRead
-#define evTimeRW	__evTimeRW
-#define evUntimeRW	__evUntimeRW
-#define	evCancelRW	__evCancelRW
-
-struct iovec evConsIovec __P((void *, size_t));
-int evWrite __P((evContext, int, const struct iovec *, int,
-		 evStreamFunc func, void *, evStreamID *));
-int evRead __P((evContext, int, const struct iovec *, int,
-		evStreamFunc func, void *, evStreamID *));
-int evTimeRW __P((evContext, evStreamID, evTimerID timer));
-int evUntimeRW __P((evContext, evStreamID));
-int evCancelRW __P((evContext, evStreamID));
-
-/* ev_timers.c */
-#define evConsTime	__evConsTime
-#define evAddTime	__evAddTime
-#define evSubTime	__evSubTime
-#define evCmpTime	__evCmpTime
-#define	evTimeSpec	__evTimeSpec
-#define	evTimeVal	__evTimeVal
-
-#define evNowTime		__evNowTime
-#define evUTCTime		__evUTCTime
-#define evLastEventTime		__evLastEventTime
-#define evSetTimer		__evSetTimer
-#define evClearTimer		__evClearTimer
-#define evConfigTimer		__evConfigTimer
-#define evResetTimer		__evResetTimer
-#define evSetIdleTimer		__evSetIdleTimer
-#define evClearIdleTimer	__evClearIdleTimer
-#define evResetIdleTimer	__evResetIdleTimer
-#define evTouchIdleTimer	__evTouchIdleTimer
-
-struct timespec evConsTime __P((time_t sec, long nsec));
-struct timespec evAddTime __P((struct timespec, struct timespec));
-struct timespec evSubTime __P((struct timespec, struct timespec));
-struct timespec evNowTime __P((void));
-struct timespec evUTCTime __P((void));
-struct timespec evLastEventTime __P((evContext));
-struct timespec evTimeSpec __P((struct timeval));
-struct timeval evTimeVal __P((struct timespec));
-int evCmpTime __P((struct timespec, struct timespec));
-int evSetTimer __P((evContext, evTimerFunc, void *, struct timespec,
-		    struct timespec, evTimerID *));
-int evClearTimer __P((evContext, evTimerID));
-int evConfigTimer __P((evContext, evTimerID, const char *param,
-		      int value));
-int evResetTimer __P((evContext, evTimerID, evTimerFunc, void *,
-		      struct timespec, struct timespec));
-int evSetIdleTimer __P((evContext, evTimerFunc, void *, struct timespec,
-			evTimerID *));
-int evClearIdleTimer __P((evContext, evTimerID));
-int evResetIdleTimer __P((evContext, evTimerID, evTimerFunc, void *,
-			  struct timespec));
-int evTouchIdleTimer __P((evContext, evTimerID));
-
-/* ev_waits.c */
-#define evWaitFor	__evWaitFor
-#define evDo		__evDo
-#define evUnwait	__evUnwait
-#define evDefer		__evDefer
-
-int evWaitFor __P((evContext, const void *, evWaitFunc, void *, evWaitID *));
-int evDo __P((evContext, const void *));
-int evUnwait __P((evContext, evWaitID));
-int evDefer __P((evContext, evWaitFunc, void *));
-
-#ifdef __EVENTLIB_P_DEFINED
-# undef __P
-#endif
-
-#endif /*_EVENTLIB_H*/
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/include/isc/heap.h b/contrib/bind9/lib/bind/include/isc/heap.h
deleted file mode 100644
index 384d507..0000000
--- a/contrib/bind9/lib/bind/include/isc/heap.h
+++ /dev/null
@@ -1,49 +0,0 @@
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-typedef int (*heap_higher_priority_func)(void *, void *);
-typedef void (*heap_index_func)(void *, int);
-typedef void (*heap_for_each_func)(void *, void *);
-
-typedef struct heap_context {
-	int array_size;
-	int array_size_increment;
-	int heap_size;
-	void **heap;
-	heap_higher_priority_func higher_priority;
-	heap_index_func index;
-} *heap_context;
-
-#define heap_new	__heap_new
-#define heap_free	__heap_free
-#define heap_insert	__heap_insert
-#define heap_delete	__heap_delete
-#define heap_increased	__heap_increased
-#define heap_decreased	__heap_decreased
-#define heap_element	__heap_element
-#define heap_for_each	__heap_for_each
-
-heap_context	heap_new(heap_higher_priority_func, heap_index_func, int);
-int		heap_free(heap_context);
-int		heap_insert(heap_context, void *);
-int		heap_delete(heap_context, int);
-int		heap_increased(heap_context, int);
-int		heap_decreased(heap_context, int);
-void *		heap_element(heap_context, int);
-int		heap_for_each(heap_context, heap_for_each_func, void *);
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/include/isc/irpmarshall.h b/contrib/bind9/lib/bind/include/isc/irpmarshall.h
deleted file mode 100644
index ef57701..0000000
--- a/contrib/bind9/lib/bind/include/isc/irpmarshall.h
+++ /dev/null
@@ -1,112 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1999 by 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: irpmarshall.h,v 1.3.18.1 2005/04/27 05:00:51 sra Exp $
- */
-
-#ifndef _IRPMARSHALL_H_INCLUDED
-#define _IRPMARSHALL_H_INCLUDED
-
-/* Hide function names */
-#define irp_marshall_gr __irp_marshall_gr
-#define irp_marshall_ho __irp_marshall_ho
-#define irp_marshall_ne __irp_marshall_ne
-#define irp_marshall_ng __irp_marshall_ng
-#define irp_marshall_nw __irp_marshall_nw
-#define irp_marshall_pr __irp_marshall_pr
-#define irp_marshall_pw __irp_marshall_pw
-#define irp_marshall_sv __irp_marshall_sv
-#define irp_unmarshall_gr __irp_unmarshall_gr
-#define irp_unmarshall_ho __irp_unmarshall_ho
-#define irp_unmarshall_ne __irp_unmarshall_ne
-#define irp_unmarshall_ng __irp_unmarshall_ng
-#define irp_unmarshall_nw __irp_unmarshall_nw
-#define irp_unmarshall_pr __irp_unmarshall_pr
-#define irp_unmarshall_pw __irp_unmarshall_pw
-#define irp_unmarshall_sv __irp_unmarshall_sv
-
-#define MAXPADDRSIZE (sizeof "255.255.255.255" + 1)
-#define ADDR_T_STR(x) (x == AF_INET ? "AF_INET" :\
-		       (x == AF_INET6 ? "AF_INET6" : "UNKNOWN"))
-
-/* See comment below on usage */
-int irp_marshall_pw(const struct passwd *, char **, size_t *);
-int irp_unmarshall_pw(struct passwd *, char *);
-int irp_marshall_gr(const struct group *, char **, size_t *);
-int irp_unmarshall_gr(struct group *, char *);
-int irp_marshall_sv(const struct servent *, char **, size_t *);
-int irp_unmarshall_sv(struct servent *, char *);
-int irp_marshall_pr(struct protoent *, char **, size_t *);
-int irp_unmarshall_pr(struct protoent *, char *);
-int irp_marshall_ho(struct hostent *, char **, size_t *);
-int irp_unmarshall_ho(struct hostent *, char *);
-int irp_marshall_ng(const char *, const char *, const char *,
-		    char **, size_t *);
-int irp_unmarshall_ng(const char **, const char **, const char **, char *);
-int irp_marshall_nw(struct nwent *, char **, size_t *);
-int irp_unmarshall_nw(struct nwent *, char *);
-int irp_marshall_ne(struct netent *, char **, size_t *);
-int irp_unmarshall_ne(struct netent *, char *);
-
-/*! \file
- * \brief
- * Functions to marshall and unmarshall various system data structures. We
- * use a printable ascii format that is as close to various system config
- * files as reasonable (e.g. /etc/passwd format).
- *
- * We are not forgiving with unmarhsalling misformatted buffers. In
- * particular whitespace in fields is not ignored. So a formatted password
- * entry "brister  :1364:100:...." will yield a username of "brister   "
- *
- * We potentially do a lot of mallocs to fill fields that are of type
- * (char **) like a hostent h_addr field. Building (for example) the
- * h_addr field and its associated addresses all in one buffer is
- * certainly possible, but not done here.
- *
- * The following description is true for all the marshalling functions:
- *
- * int irp_marshall_XX(struct yyyy *XX, char **buffer, size_t *len);
- *
- * The argument XX (of type struct passwd for example) is marshalled in the
- * buffer pointed at by *BUFFER, which is of length *LEN. Returns 0
- * on success and -1 on failure. Failure will occur if *LEN is
- * smaller than needed.
- *
- * If BUFFER is NULL, then *LEN is set to the size of the buffer
- * needed to marshall the data and no marshalling is actually done.
- *
- * If *BUFFER is NULL, then a buffer large enough will be allocated
- * with memget() and the size allocated will be stored in *LEN. An extra 2
- * bytes will be allocated for the client to append CRLF if wanted. The
- * value of *LEN will include these two bytes.
- *
- * All the marshalling functions produce a buffer with the fields
- * separated by colons (except for the hostent marshalling, which uses '@'
- * to separate fields). Fields that have multiple subfields (like the
- * gr_mem field in struct group) have their subparts separated by
- * commas.
- *
- * int irp_unmarshall_XX(struct YYYYY *XX, char *buffer);
- *
- * The unmashalling functions break apart the buffer and store the
- * values in the struct pointed to by XX. All pointer values inside
- * XX are allocated with malloc. All arrays of pointers have a NULL
- * as the last element.
- */
-
-#endif
diff --git a/contrib/bind9/lib/bind/include/isc/list.h b/contrib/bind9/lib/bind/include/isc/list.h
deleted file mode 100644
index c85c667..0000000
--- a/contrib/bind9/lib/bind/include/isc/list.h
+++ /dev/null
@@ -1,117 +0,0 @@
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-#ifndef LIST_H
-#define LIST_H 1
-#include <isc/assertions.h>
-
-#define LIST(type) struct { type *head, *tail; }
-#define INIT_LIST(list) \
-	do { (list).head = NULL; (list).tail = NULL; } while (0)
-
-#define LINK(type) struct { type *prev, *next; }
-#define INIT_LINK_TYPE(elt, link, type) \
-	do { \
-		(elt)->link.prev = (type *)(-1); \
-		(elt)->link.next = (type *)(-1); \
-	} while (0)
-#define INIT_LINK(elt, link) \
-	INIT_LINK_TYPE(elt, link, void)
-#define LINKED(elt, link) ((void *)((elt)->link.prev) != (void *)(-1))
-
-#define HEAD(list) ((list).head)
-#define TAIL(list) ((list).tail)
-#define EMPTY(list) ((list).head == NULL)
-
-#define PREPEND(list, elt, link) \
-	do { \
-		INSIST(!LINKED(elt, link));\
-		if ((list).head != NULL) \
-			(list).head->link.prev = (elt); \
-		else \
-			(list).tail = (elt); \
-		(elt)->link.prev = NULL; \
-		(elt)->link.next = (list).head; \
-		(list).head = (elt); \
-	} while (0)
-
-#define APPEND(list, elt, link) \
-	do { \
-		INSIST(!LINKED(elt, link));\
-		if ((list).tail != NULL) \
-			(list).tail->link.next = (elt); \
-		else \
-			(list).head = (elt); \
-		(elt)->link.prev = (list).tail; \
-		(elt)->link.next = NULL; \
-		(list).tail = (elt); \
-	} while (0)
-
-#define UNLINK_TYPE(list, elt, link, type) \
-	do { \
-		INSIST(LINKED(elt, link));\
-		if ((elt)->link.next != NULL) \
-			(elt)->link.next->link.prev = (elt)->link.prev; \
-		else { \
-			INSIST((list).tail == (elt)); \
-			(list).tail = (elt)->link.prev; \
-		} \
-		if ((elt)->link.prev != NULL) \
-			(elt)->link.prev->link.next = (elt)->link.next; \
-		else { \
-			INSIST((list).head == (elt)); \
-			(list).head = (elt)->link.next; \
-		} \
-		INIT_LINK_TYPE(elt, link, type); \
-	} while (0)
-#define UNLINK(list, elt, link) \
-	UNLINK_TYPE(list, elt, link, void)
-
-#define PREV(elt, link) ((elt)->link.prev)
-#define NEXT(elt, link) ((elt)->link.next)
-
-#define INSERT_BEFORE(list, before, elt, link) \
-	do { \
-		INSIST(!LINKED(elt, link));\
-		if ((before)->link.prev == NULL) \
-			PREPEND(list, elt, link); \
-		else { \
-			(elt)->link.prev = (before)->link.prev; \
-			(before)->link.prev = (elt); \
-			(elt)->link.prev->link.next = (elt); \
-			(elt)->link.next = (before); \
-		} \
-	} while (0)
-
-#define INSERT_AFTER(list, after, elt, link) \
-	do { \
-		INSIST(!LINKED(elt, link));\
-		if ((after)->link.next == NULL) \
-			APPEND(list, elt, link); \
-		else { \
-			(elt)->link.next = (after)->link.next; \
-			(after)->link.next = (elt); \
-			(elt)->link.next->link.prev = (elt); \
-			(elt)->link.prev = (after); \
-		} \
-	} while (0)
-
-#define ENQUEUE(list, elt, link) APPEND(list, elt, link)
-#define DEQUEUE(list, elt, link) UNLINK(list, elt, link)
-
-#endif /* LIST_H */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/include/isc/logging.h b/contrib/bind9/lib/bind/include/isc/logging.h
deleted file mode 100644
index c539443..0000000
--- a/contrib/bind9/lib/bind/include/isc/logging.h
+++ /dev/null
@@ -1,113 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996-1999 by 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.
- */
-
-#ifndef LOGGING_H
-#define LOGGING_H
-
-#include <sys/types.h>
-#include <stdio.h>
-#include <stdarg.h>
-#include <unistd.h>
-
-#define log_critical		(-5)
-#define log_error   		(-4)
-#define log_warning 		(-3)
-#define log_notice  		(-2)
-#define log_info  		(-1)
-#define log_debug(level)	(level)
-
-typedef enum { log_syslog, log_file, log_null } log_channel_type;
-
-#define LOG_MAX_VERSIONS 99
-
-#define LOG_CLOSE_STREAM		0x0001
-#define LOG_TIMESTAMP			0x0002
-#define LOG_TRUNCATE			0x0004
-#define LOG_USE_CONTEXT_LEVEL		0x0008
-#define LOG_PRINT_LEVEL			0x0010
-#define LOG_REQUIRE_DEBUG		0x0020
-#define LOG_CHANNEL_BROKEN		0x0040
-#define LOG_PRINT_CATEGORY		0x0080
-#define LOG_CHANNEL_OFF			0x0100
-
-typedef struct log_context *log_context;
-typedef struct log_channel *log_channel;
-
-#define LOG_OPTION_DEBUG		0x01
-#define LOG_OPTION_LEVEL		0x02
-
-#define log_open_stream		__log_open_stream
-#define log_close_stream	__log_close_stream
-#define log_get_stream		__log_get_stream
-#define log_get_filename	__log_get_filename
-#define log_check_channel	__log_check_channel
-#define log_check		__log_check
-#define log_vwrite		__log_vwrite
-#define log_write		__log_write
-#define log_new_context		__log_new_context
-#define log_free_context	__log_free_context
-#define log_add_channel		__log_add_channel
-#define log_remove_channel	__log_remove_channel
-#define log_option		__log_option
-#define log_category_is_active	__log_category_is_active
-#define log_new_syslog_channel	__log_new_syslog_channel
-#define log_new_file_channel	__log_new_file_channel
-#define log_set_file_owner	__log_set_file_owner
-#define log_new_null_channel	__log_new_null_channel
-#define log_inc_references	__log_inc_references
-#define log_dec_references	__log_dec_references
-#define log_get_channel_type	__log_get_channel_type
-#define log_free_channel	__log_free_channel
-#define log_close_debug_channels	__log_close_debug_channels
-
-FILE *			log_open_stream(log_channel);
-int			log_close_stream(log_channel);
-FILE *			log_get_stream(log_channel);
-char *			log_get_filename(log_channel);
-int			log_check_channel(log_context, int, log_channel);
-int			log_check(log_context, int, int);
-#ifdef __GNUC__
-void			log_vwrite(log_context, int, int, const char *, 
-				   va_list args)
-				__attribute__((__format__(__printf__, 4, 0)));
-void			log_write(log_context, int, int, const char *, ...)
-				__attribute__((__format__(__printf__, 4, 5)));
-#else
-void			log_vwrite(log_context, int, int, const char *, 
-				   va_list args);
-void			log_write(log_context, int, int, const char *, ...);
-#endif
-int			log_new_context(int, char **, log_context *);
-void			log_free_context(log_context);
-int			log_add_channel(log_context, int, log_channel);
-int			log_remove_channel(log_context, int, log_channel);
-int			log_option(log_context, int, int);
-int			log_category_is_active(log_context, int);
-log_channel		log_new_syslog_channel(unsigned int, int, int);
-log_channel		log_new_file_channel(unsigned int, int, const char *,
-					     FILE *, unsigned int,
-					     unsigned long);
-int			log_set_file_owner(log_channel, uid_t, gid_t);
-log_channel		log_new_null_channel(void);
-int			log_inc_references(log_channel);
-int			log_dec_references(log_channel);
-log_channel_type	log_get_channel_type(log_channel);
-int			log_free_channel(log_channel);
-void			log_close_debug_channels(log_context);
-
-#endif /* !LOGGING_H */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/include/isc/memcluster.h b/contrib/bind9/lib/bind/include/isc/memcluster.h
deleted file mode 100644
index 0923deb..0000000
--- a/contrib/bind9/lib/bind/include/isc/memcluster.h
+++ /dev/null
@@ -1,50 +0,0 @@
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-#ifndef MEMCLUSTER_H
-#define MEMCLUSTER_H
-
-#include <stdio.h>
-
-#define meminit		__meminit
-#ifdef MEMCLUSTER_DEBUG
-#define memget(s)	__memget_debug(s, __FILE__, __LINE__)
-#define memput(p, s)	__memput_debug(p, s, __FILE__, __LINE__)
-#else /*MEMCLUSTER_DEBUG*/
-#ifdef MEMCLUSTER_RECORD
-#define memget(s)	__memget_record(s, __FILE__, __LINE__)
-#define memput(p, s)	__memput_record(p, s, __FILE__, __LINE__)
-#else /*MEMCLUSTER_RECORD*/
-#define memget		__memget
-#define memput		__memput
-#endif /*MEMCLUSTER_RECORD*/
-#endif /*MEMCLUSTER_DEBUG*/
-#define memstats	__memstats
-#define memactive	__memactive
-
-int	meminit(size_t, size_t);
-void *	__memget(size_t);
-void 	__memput(void *, size_t);
-void *	__memget_debug(size_t, const char *, int);
-void 	__memput_debug(void *, size_t, const char *, int);
-void *	__memget_record(size_t, const char *, int);
-void 	__memput_record(void *, size_t, const char *, int);
-void 	memstats(FILE *);
-int	memactive(void);
-
-#endif /* MEMCLUSTER_H */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/include/isc/misc.h b/contrib/bind9/lib/bind/include/isc/misc.h
deleted file mode 100644
index 0cd1487..0000000
--- a/contrib/bind9/lib/bind/include/isc/misc.h
+++ /dev/null
@@ -1,44 +0,0 @@
-/*
- * Copyright (c) 2004 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
- * 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: misc.h,v 1.4.18.2 2008/02/18 04:04:06 marka Exp $
- */
-
-#ifndef _ISC_MISC_H
-#define _ISC_MISC_H
-
-/*! \file */
-
-#include <stdio.h>
-#include <sys/types.h>
-
-#define	bitncmp		__bitncmp
-/*#define isc_movefile	__isc_movefile */
-
-extern int		bitncmp(const void *, const void *, int);
-extern int		isc_movefile(const char *, const char *);
-
-extern int		isc_gethexstring(unsigned char *, size_t, int, FILE *,
-					 int *);
-extern void		isc_puthexstring(FILE *, const unsigned char *, size_t,
-					 size_t, size_t, const char *);
-extern void		isc_tohex(const unsigned char *, size_t, char *);
-
-#endif /*_ISC_MISC_H*/
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/include/isc/tree.h b/contrib/bind9/lib/bind/include/isc/tree.h
deleted file mode 100644
index 8096a8d..0000000
--- a/contrib/bind9/lib/bind/include/isc/tree.h
+++ /dev/null
@@ -1,59 +0,0 @@
-/* tree.h - declare structures used by tree library
- *
- * vix 22jan93 [revisited; uses RCS, ANSI, POSIX; has bug fixes]
- * vix 27jun86 [broken out of tree.c]
- *
- * $Id: tree.h,v 1.2.164.1 2005/04/27 05:00:52 sra Exp $
- */
-
-
-#ifndef	_TREE_H_INCLUDED
-#define	_TREE_H_INCLUDED
-
-
-#ifndef __P
-# if defined(__STDC__) || defined(__GNUC__)
-#  define __P(x) x
-# else
-#  define __P(x) ()
-# endif
-#endif
-
-/*%
- * tree_t is our package-specific anonymous pointer.
- */
-#if defined(__STDC__) || defined(__GNUC__)
-typedef	void *tree_t;
-#else
-typedef	char *tree_t;
-#endif
-
-/*%
- * Do not taint namespace
- */
-#define	tree_add	__tree_add
-#define	tree_delete	__tree_delete
-#define	tree_init	__tree_init
-#define	tree_mung	__tree_mung
-#define	tree_srch	__tree_srch
-#define	tree_trav	__tree_trav
-
-
-typedef	struct tree_s {
-		tree_t		data;
-		struct tree_s	*left, *right;
-		short		bal;
-	}
-	tree;
-
-
-void	tree_init	__P((tree **));
-tree_t	tree_srch	__P((tree **, int (*)(), tree_t));
-tree_t	tree_add	__P((tree **, int (*)(), tree_t, void (*)()));
-int	tree_delete	__P((tree **, int (*)(), tree_t, void (*)()));
-int	tree_trav	__P((tree **, int (*)()));
-void	tree_mung	__P((tree **, void (*)()));
-
-
-#endif	/* _TREE_H_INCLUDED */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/include/netdb.h b/contrib/bind9/lib/bind/include/netdb.h
deleted file mode 100644
index b74c646..0000000
--- a/contrib/bind9/lib/bind/include/netdb.h
+++ /dev/null
@@ -1,582 +0,0 @@
-/*
- * ++Copyright++ 1980, 1983, 1988, 1993
- * -
- * Copyright (c) 1980, 1983, 1988, 1993
- *	The Regents of the University of California.  All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- *	This product includes software developed by the University of
- *	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- * -
- * Portions Copyright (c) 1993 by Digital Equipment Corporation.
- *
- * 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, and that
- * the name of Digital Equipment Corporation not be used in advertising or
- * publicity pertaining to distribution of the document or software without
- * specific, written prior permission.
- *
- * THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
- * WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
- * OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
- * CORPORATION 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.
- * -
- * Portions Copyright (C) 1995, 1996, 1997, and 1998 WIDE Project.
- * All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- *    This product includes software developed by WIDE Project and
- *    its contributors.
- * 4. Neither the name of the project nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- * -
- * --Copyright--
- */
-
-/*
- *      @(#)netdb.h	8.1 (Berkeley) 6/2/93
- *	$Id: netdb.h,v 1.15.18.7 2008/02/28 05:49:37 marka Exp $
- */
-
-#ifndef _NETDB_H_
-#define _NETDB_H_
-
-#include <sys/param.h>
-#include <sys/types.h>
-#if (!defined(BSD)) || (BSD < 199306)
-# include <sys/bitypes.h>
-#endif
-#include <sys/cdefs.h>
-#include <sys/socket.h>
-#include <netinet/in.h>
-#include <stdio.h>
-
-#ifndef _PATH_HEQUIV
-#define _PATH_HEQUIV	"/etc/hosts.equiv"
-#endif
-#ifndef _PATH_HOSTS
-#define	_PATH_HOSTS	"/etc/hosts"
-#endif
-#ifndef _PATH_NETWORKS
-#define	_PATH_NETWORKS	"/etc/networks"
-#endif
-#ifndef _PATH_PROTOCOLS
-#define	_PATH_PROTOCOLS	"/etc/protocols"
-#endif
-#ifndef _PATH_SERVICES
-#define	_PATH_SERVICES	"/etc/services"
-#endif
-
-#if (__GLIBC__ > 2 || __GLIBC__ == 2 &&  __GLIBC_MINOR__ >= 3)
-#define __h_errno __h_errno_location
-#endif
-__BEGIN_DECLS
-extern int * __h_errno __P((void));
-__END_DECLS
-#if defined(_REENTRANT) || \
-    (__GLIBC__ > 2 || __GLIBC__ == 2 &&  __GLIBC_MINOR__ >= 3)
-#define	h_errno (*__h_errno())
-#else
-extern int h_errno;
-#endif
-
-/*%
- * Structures returned by network data base library.  All addresses are
- * supplied in host order, and returned in network order (suitable for
- * use in system calls).
- */
-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 compatiblity */
-};
-
-/*%
- * Assumption here is that a network number
- * fits in an unsigned long -- probably a poor one.
- */
-struct	netent {
-	char		*n_name;	/*%< official name of net */
-	char		**n_aliases;	/*%< alias list */
-	int		n_addrtype;	/*%< net address type */
-	unsigned long	n_net;		/*%< network # */
-};
-
-struct	servent {
-	char	*s_name;	/*%< official service name */
-	char	**s_aliases;	/*%< alias list */
-	int	s_port;		/*%< port # */
-	char	*s_proto;	/*%< protocol to use */
-};
-
-struct	protoent {
-	char	*p_name;	/*%< official protocol name */
-	char	**p_aliases;	/*%< alias list */
-	int	p_proto;	/*%< protocol # */
-};
-
-struct	addrinfo {
-	int		ai_flags;	/*%< AI_PASSIVE, AI_CANONNAME */
-	int		ai_family;	/*%< PF_xxx */
-	int		ai_socktype;	/*%< SOCK_xxx */
-	int		ai_protocol;	/*%< 0 or IPPROTO_xxx for IPv4 and IPv6 */
-#if defined(sun) && defined(_SOCKLEN_T)
-#ifdef __sparcv9
-	int		_ai_pad;
-#endif
-	socklen_t	ai_addrlen;
-#else
-	size_t		ai_addrlen;	/*%< length of ai_addr */
-#endif
-#ifdef __linux
-	struct sockaddr	*ai_addr; 	/*%< binary address */
-	char		*ai_canonname;	/*%< canonical name for hostname */
-#else
-	char		*ai_canonname;	/*%< canonical name for hostname */
-	struct sockaddr	*ai_addr; 	/*%< binary address */
-#endif
-	struct addrinfo	*ai_next; 	/*%< next structure in linked list */
-};
-
-/*%
- * Error return codes from gethostbyname() and gethostbyaddr()
- * (left in extern int h_errno).
- */
-
-#define	NETDB_INTERNAL	-1	/*%< see errno */
-#define	NETDB_SUCCESS	0	/*%< no problem */
-#define	HOST_NOT_FOUND	1 /*%< Authoritative Answer Host not found */
-#define	TRY_AGAIN	2 /*%< Non-Authoritive Host not found, or SERVERFAIL */
-#define	NO_RECOVERY	3 /*%< Non recoverable errors, FORMERR, REFUSED, NOTIMP */
-#define	NO_DATA		4 /*%< Valid name, no data record of requested type */
-#define	NO_ADDRESS	NO_DATA		/*%< no address, look for MX record */
-/*
- * Error return codes from getaddrinfo()
- */
-#define	EAI_ADDRFAMILY	 1	/*%< address family for hostname not supported */
-#define	EAI_AGAIN	 2	/*%< temporary failure in name resolution */
-#define	EAI_BADFLAGS	 3	/*%< invalid value for ai_flags */
-#define	EAI_FAIL	 4	/*%< non-recoverable failure in name resolution */
-#define	EAI_FAMILY	 5	/*%< ai_family not supported */
-#define	EAI_MEMORY	 6	/*%< memory allocation failure */
-#define	EAI_NODATA	 7	/*%< no address associated with hostname */
-#define	EAI_NONAME	 8	/*%< hostname nor servname provided, or not known */
-#define	EAI_SERVICE	 9	/*%< servname not supported for ai_socktype */
-#define	EAI_SOCKTYPE	10	/*%< ai_socktype not supported */
-#define	EAI_SYSTEM	11	/*%< system error returned in errno */
-#define EAI_BADHINTS	12
-#define EAI_PROTOCOL	13
-#define EAI_MAX		14
-
-/*%
- * Flag values for getaddrinfo()
- */
-#define	AI_PASSIVE	0x00000001
-#define	AI_CANONNAME	0x00000002
-#define AI_NUMERICHOST	0x00000004
-#define	AI_MASK		0x00000007
-
-/*%
- * Flag values for getipnodebyname()
- */
-#define AI_V4MAPPED	0x00000008
-#define AI_ALL		0x00000010
-#define AI_ADDRCONFIG	0x00000020
-#define AI_DEFAULT	(AI_V4MAPPED|AI_ADDRCONFIG)
-
-/*%
- * Constants for getnameinfo()
- */
-#define	NI_MAXHOST	1025
-#define	NI_MAXSERV	32
-
-/*%
- * Flag values for getnameinfo()
- */
-#define	NI_NOFQDN	0x00000001
-#define	NI_NUMERICHOST	0x00000002
-#define	NI_NAMEREQD	0x00000004
-#define	NI_NUMERICSERV	0x00000008
-#define	NI_DGRAM	0x00000010
-#define	NI_WITHSCOPEID	0x00000020
-#define NI_NUMERICSCOPE	0x00000040
-
-/*%
- * Scope delimit character
- */
-#define SCOPE_DELIMITER	'%'
-
-
-#ifdef _REENTRANT
-#if defined (__hpux) || defined(__osf__) || defined(_AIX)
-#define	_MAXALIASES	35
-#define	_MAXLINELEN	1024
-#define	_MAXADDRS	35
-#define	_HOSTBUFSIZE	(BUFSIZ + 1)
-
-struct hostent_data {
-	struct in_addr	host_addr;
-	char		*h_addr_ptrs[_MAXADDRS + 1];
-	char		hostaddr[_MAXADDRS];
-	char		hostbuf[_HOSTBUFSIZE];
-	char		*host_aliases[_MAXALIASES];
-	char		*host_addrs[2];
-	FILE		*hostf;
-#ifdef __osf__
-	int		svc_gethostflag;
-	int		svc_gethostbind;
-#endif
-#ifdef __hpux
-	short		_nsw_src;
-	short		_flags;
-	char		*current;
-	int		currentlen;
-#endif
-};
-
-struct  netent_data {
-	FILE	*net_fp;
-#if defined(__osf__) || defined(_AIX)
-	char	line[_MAXLINELEN];
-#endif
-#ifdef __hpux
-	char	line[_MAXLINELEN+1];
-#endif
-	char	*net_aliases[_MAXALIASES];
-#ifdef __osf__
-	int	_net_stayopen;
-	int	svc_getnetflag;
-#endif
-#ifdef __hpux
-	short	_nsw_src;
-	short	_flags;
-	char	*current;
-	int	currentlen;
-#endif
-#ifdef _AIX
-        int     _net_stayopen;
-        char    *current;
-        int     currentlen;
-        void    *_net_reserv1;          /* reserved for future use */
-        void    *_net_reserv2;          /* reserved for future use */
-#endif
-};
-
-struct	protoent_data {
-	FILE	*proto_fp;
-#ifdef _AIX
-	int     _proto_stayopen;
-	char	line[_MAXLINELEN];
-#endif
-#ifdef __osf__
-	char	line[1024];
-#endif
-#ifdef __hpux
-	char	line[_MAXLINELEN+1];
-#endif
-	char	*proto_aliases[_MAXALIASES];
-#ifdef __osf__
-	int	_proto_stayopen;
-	int	svc_getprotoflag;
-#endif
-#ifdef __hpux
-	short	_nsw_src;
-	short	_flags;
-	char	*current;
-	int	currentlen;
-#endif
-#ifdef _AIX
-        int     currentlen;
-        char    *current;
-        void    *_proto_reserv1;        /* reserved for future use */
-        void    *_proto_reserv2;        /* reserved for future use */
-#endif
-};
-
-struct	servent_data {
-	FILE	*serv_fp;
-#if defined(__osf__) || defined(_AIX)
-	char	line[_MAXLINELEN];
-#endif
-#ifdef __hpux
-	char	line[_MAXLINELEN+1];
-#endif
-	char	*serv_aliases[_MAXALIASES];
-#ifdef __osf__
-	int	_serv_stayopen;
-	int	svc_getservflag;
-#endif
-#ifdef __hpux
-	short	_nsw_src;
-	short	_flags;
-	char	*current;
-	int	currentlen;
-#endif
-#ifdef _AIX
-	int     _serv_stayopen;
-	char     *current;
-	int     currentlen;
-	void    *_serv_reserv1;         /* reserved for future use */
-	void    *_serv_reserv2;         /* reserved for future use */
-#endif
-};
-#endif
-#endif
-__BEGIN_DECLS
-void		endhostent __P((void));
-void		endnetent __P((void));
-void		endprotoent __P((void));
-void		endservent __P((void));
-void		freehostent __P((struct hostent *));
-struct hostent	*gethostbyaddr __P((const char *, int, int));
-struct hostent	*gethostbyname __P((const char *));
-struct hostent	*gethostbyname2 __P((const char *, int));
-struct hostent	*gethostent __P((void));
-struct hostent	*getipnodebyaddr __P((const void *, size_t, int, int *));
-struct hostent	*getipnodebyname __P((const char *, int, int, int *));
-struct netent	*getnetbyaddr __P((unsigned long, int));
-struct netent	*getnetbyname __P((const char *));
-struct netent	*getnetent __P((void));
-struct protoent	*getprotobyname __P((const char *));
-struct protoent	*getprotobynumber __P((int));
-struct protoent	*getprotoent __P((void));
-struct servent	*getservbyname __P((const char *, const char *));
-struct servent	*getservbyport __P((int, const char *));
-struct servent	*getservent __P((void));
-void		herror __P((const char *));
-const char	*hstrerror __P((int));
-void		sethostent __P((int));
-/* void		sethostfile __P((const char *)); */
-void		setnetent __P((int));
-void		setprotoent __P((int));
-void		setservent __P((int));
-int		getaddrinfo __P((const char *, const char *,
-				 const struct addrinfo *, struct addrinfo **));
-int		getnameinfo __P((const struct sockaddr *, size_t, char *,
-				 size_t, char *, size_t, int));
-void		freeaddrinfo __P((struct addrinfo *));
-const char	*gai_strerror __P((int));
-struct hostent  *getipnodebyname __P((const char *, int, int, int *));
-struct hostent	*getipnodebyaddr __P((const void *, size_t, int, int *));
-void		freehostent __P((struct hostent *));
-#ifdef __GLIBC__
-int		getnetgrent __P((/* const */ char **, /* const */ char **,
-				 /* const */ char **));
-void		setnetgrent __P((const char *));
-void		endnetgrent __P((void));
-int		innetgr __P((const char *, const char *, const char *,
-			     const char *));
-#endif
-
-#ifdef _REENTRANT
-#if defined(__hpux) || defined(__osf__) || defined(_AIX)
-int		gethostbyaddr_r __P((const char *, int, int, struct hostent *,
-					struct hostent_data *));
-int		gethostbyname_r __P((const char *, struct hostent *, 
-					struct hostent_data *));
-int		gethostent_r __P((struct hostent *, struct hostent_data *));
-#if defined(_AIX)
-void		sethostent_r __P((int, struct hostent_data *));
-#else
-int		sethostent_r __P((int, struct hostent_data *));
-#endif 
-#if defined(__hpux)
-int		endhostent_r __P((struct hostent_data *));
-#else
-void		endhostent_r __P((struct hostent_data *));
-#endif
-
-#if defined(__hpux) || defined(__osf__)
-int		getnetbyaddr_r __P((int, int,
-				struct netent *, struct netent_data *));
-#else
-int		getnetbyaddr_r __P((long, int,
-				struct netent *, struct netent_data *));
-#endif
-int		getnetbyname_r __P((const char *,
-				struct netent *, struct netent_data *));
-int		getnetent_r __P((struct netent *, struct netent_data *));
-int		setnetent_r __P((int, struct netent_data *));
-#ifdef __hpux
-int		endnetent_r __P((struct netent_data *buffer));
-#else
-void		endnetent_r __P((struct netent_data *buffer));
-#endif
-
-int		getprotobyname_r __P((const char *,
-				struct protoent *, struct protoent_data *));
-int		getprotobynumber_r __P((int,
-				struct protoent *, struct protoent_data *));
-int		getprotoent_r __P((struct protoent *, struct protoent_data *));
-int		setprotoent_r __P((int, struct protoent_data *));
-#ifdef __hpux
-int		endprotoent_r __P((struct protoent_data *));
-#else
-void		endprotoent_r __P((struct protoent_data *));
-#endif
-
-int		getservbyname_r __P((const char *, const char *,
-				struct servent *, struct servent_data *));
-int		getservbyport_r __P((int, const char *,
-				struct servent *, struct servent_data *));
-int		getservent_r __P((struct servent *, struct servent_data *));
-int		setservent_r __P((int, struct servent_data *));
-#ifdef __hpux
-int		endservent_r __P((struct servent_data *));
-#else
-void		endservent_r __P((struct servent_data *));
-#endif
-#ifdef _AIX
-int		setnetgrent_r __P((char *, void **));
-void		endnetgrent_r __P((void **));
-/*
- * Note: AIX's netdb.h declares innetgr_r() as: 
- *	int innetgr_r(char *, char *, char *, char *, struct innetgr_data *);
- */
-int		innetgr_r __P((const char *, const char *, const char *,
-			       const char *));
-#endif
-#else
- /* defined(sun) || defined(bsdi) */
-#if defined(__GLIBC__) || defined(__FreeBSD__) && (__FreeBSD_version + 0 >= 601103)
-int gethostbyaddr_r __P((const char *, int, int, struct hostent *,
-		         char *, size_t, struct hostent **, int *));
-int gethostbyname_r __P((const char *, struct hostent *,
-		        char *, size_t, struct hostent **, int *));
-int gethostent_r __P((struct hostent *, char *, size_t,
-			 struct hostent **, int *));
-#else
-struct hostent	*gethostbyaddr_r __P((const char *, int, int, struct hostent *,
-					char *, int, int *));
-struct hostent	*gethostbyname_r __P((const char *, struct hostent *,
-					char *, int, int *));
-struct hostent	*gethostent_r __P((struct hostent *, char *, int, int *));
-#endif
-void		sethostent_r __P((int));
-void		endhostent_r __P((void));
-
-#if defined(__GLIBC__) || defined(__FreeBSD__) && (__FreeBSD_version + 0 >= 601103)
-int getnetbyname_r __P((const char *, struct netent *,
-			char *, size_t, struct netent **, int*));
-int getnetbyaddr_r __P((unsigned long int, int, struct netent *,
-			char *, size_t, struct netent **, int*));
-int getnetent_r __P((struct netent *, char *, size_t, struct netent **, int*));
-#else
-struct netent	*getnetbyname_r __P((const char *, struct netent *,
-					char *, int));
-struct netent	*getnetbyaddr_r __P((long, int, struct netent *,
-					char *, int));
-struct netent	*getnetent_r __P((struct netent *, char *, int));
-#endif
-void		setnetent_r __P((int));
-void		endnetent_r __P((void));
-
-#if defined(__GLIBC__) || defined(__FreeBSD__) && (__FreeBSD_version + 0 >= 601103)
-int getprotobyname_r __P((const char *, struct protoent *, char *,
-			  size_t, struct protoent **));
-int getprotobynumber_r __P((int, struct protoent *, char *, size_t,
-			    struct protoent **));
-int getprotoent_r __P((struct protoent *, char *, size_t, struct protoent **));
-#else
-struct protoent	*getprotobyname_r __P((const char *,
-				struct protoent *, char *, int));
-struct protoent	*getprotobynumber_r __P((int,
-				struct protoent *, char *, int));
-struct protoent	*getprotoent_r __P((struct protoent *, char *, int));
-#endif
-void		setprotoent_r __P((int));
-void		endprotoent_r __P((void));
-
-#if defined(__GLIBC__) || defined(__FreeBSD__) && (__FreeBSD_version + 0 >= 601103)
-int getservbyname_r __P((const char *name, const char *,
-			 struct servent *, char *, size_t, struct servent **));
-int getservbyport_r __P((int port, const char *,
-			 struct servent *, char *, size_t, struct servent **));
-int getservent_r __P((struct servent *, char *, size_t, struct servent **));
-#else
-struct servent	*getservbyname_r __P((const char *name, const char *,
-					struct servent *, char *, int));
-struct servent	*getservbyport_r __P((int port, const char *,
-					struct servent *, char *, int));
-struct servent	*getservent_r __P((struct servent *, char *, int));
-#endif
-void		setservent_r __P((int));
-void		endservent_r __P((void));
-
-#ifdef __GLIBC__
-int		getnetgrent_r __P((char **, char **, char **, char *, size_t));
-#endif
-
-#endif
-#endif
-__END_DECLS
-
-/* This is nec'y to make this include file properly replace the sun version. */
-#ifdef sun
-#ifdef __GNU_LIBRARY__
-#include <rpc/netdb.h>
-#else
-struct rpcent {
-	char	*r_name;	/*%< name of server for this rpc program */
-	char	**r_aliases;	/*%< alias list */
-	int	r_number;	/*%< rpc program number */
-};
-struct rpcent	*getrpcbyname(), *getrpcbynumber(), *getrpcent();
-#endif /* __GNU_LIBRARY__ */
-#endif /* sun */
-#endif /* !_NETDB_H_ */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/include/netgroup.h b/contrib/bind9/lib/bind/include/netgroup.h
deleted file mode 100644
index e4be459..0000000
--- a/contrib/bind9/lib/bind/include/netgroup.h
+++ /dev/null
@@ -1,26 +0,0 @@
-#ifndef netgroup_h
-#define netgroup_h
-#ifndef __GLIBC__
-
-/*
- * The standard is crazy.  These values "belong" to getnetgrent() and
- * shouldn't be altered by the caller.
- */
-int getnetgrent __P((/* const */ char **, /* const */ char **,
-		     /* const */ char **));
-
-int getnetgrent_r __P((char **, char **, char **, char *, int));
-
-void endnetgrent __P((void));
-
-#ifdef __osf__
-int innetgr __P((char *, char *, char *, char *));
-void setnetgrent __P((char *));
-#else
-void setnetgrent __P((const char *));
-int innetgr __P((const char *, const char *, const char *, const char *));
-#endif
-#endif
-#endif
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/include/res_update.h b/contrib/bind9/lib/bind/include/res_update.h
deleted file mode 100644
index 2e6f171..0000000
--- a/contrib/bind9/lib/bind/include/res_update.h
+++ /dev/null
@@ -1,69 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1999 by Internet Software Consortium, 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 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: res_update.h,v 1.2.18.1 2005/04/27 05:00:49 sra Exp $
- */
-
-#ifndef __RES_UPDATE_H
-#define __RES_UPDATE_H
-
-/*! \file */
-
-#include <sys/types.h>
-#include <arpa/nameser.h>
-#include <isc/list.h>
-#include <resolv.h>
-
-/*%
- * This RR-like structure is particular to UPDATE.
- */
-struct ns_updrec {
-	LINK(struct ns_updrec) r_link, r_glink;
-	ns_sect		r_section;	/*%< ZONE/PREREQUISITE/UPDATE */
-	char *		r_dname;	/*%< owner of the RR */
-	ns_class	r_class;	/*%< class number */
-	ns_type		r_type;		/*%< type number */
-	u_int32_t	r_ttl;		/*%< time to live */
-	u_char *	r_data;		/*%< rdata fields as text string */
-	u_int		r_size;		/*%< size of r_data field */
-	int		r_opcode;	/*%< type of operation */
-	/* following fields for private use by the resolver/server routines */
-	struct databuf *r_dp;		/*%< databuf to process */
-	struct databuf *r_deldp;	/*%< databuf's deleted/overwritten */
-	u_int		r_zone;		/*%< zone number on server */
-};
-typedef struct ns_updrec ns_updrec;
-typedef	LIST(ns_updrec)	ns_updque;
-
-#define res_mkupdate		__res_mkupdate
-#define res_update		__res_update
-#define res_mkupdrec		__res_mkupdrec
-#define res_freeupdrec		__res_freeupdrec
-#define res_nmkupdate		__res_nmkupdate
-#define res_nupdate		__res_nupdate
-
-int		res_mkupdate __P((ns_updrec *, u_char *, int));
-int		res_update __P((ns_updrec *));
-ns_updrec *	res_mkupdrec __P((int, const char *, u_int, u_int, u_long));
-void		res_freeupdrec __P((ns_updrec *));
-int		res_nmkupdate __P((res_state, ns_updrec *, u_char *, int));
-int		res_nupdate __P((res_state, ns_updrec *, ns_tsig_key *));
-
-#endif /*__RES_UPDATE_H*/
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/include/resolv.h b/contrib/bind9/lib/bind/include/resolv.h
deleted file mode 100644
index eebc62e..0000000
--- a/contrib/bind9/lib/bind/include/resolv.h
+++ /dev/null
@@ -1,509 +0,0 @@
-/*
- * Copyright (c) 1983, 1987, 1989
- *    The Regents of the University of California.  All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- * 	This product includes software developed by the University of
- * 	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-/*%
- *	@(#)resolv.h	8.1 (Berkeley) 6/2/93
- *	$Id: resolv.h,v 1.19.18.4 2008/04/03 23:15:15 marka Exp $
- */
-
-#ifndef _RESOLV_H_
-#define	_RESOLV_H_
-
-#include <sys/param.h>
-#if (!defined(BSD)) || (BSD < 199306)
-# include <sys/bitypes.h>
-#else
-# include <sys/types.h>
-#endif
-#include <sys/cdefs.h>
-#include <sys/socket.h>
-#include <stdio.h>
-#include <arpa/nameser.h>
-
-/*%
- * Revision information.  This is the release date in YYYYMMDD format.
- * It can change every day so the right thing to do with it is use it
- * in preprocessor commands such as "#if (__RES > 19931104)".  Do not
- * compare for equality; rather, use it to determine whether your resolver
- * is new enough to contain a certain feature.
- */
-
-#define	__RES	20030124
-
-/*%
- * This used to be defined in res_query.c, now it's in herror.c.
- * [XXX no it's not.  It's in irs/irs_data.c]
- * It was
- * never extern'd by any *.h file before it was placed here.  For thread
- * aware programs, the last h_errno value set is stored in res->h_errno.
- *
- * XXX:	There doesn't seem to be a good reason for exposing RES_SET_H_ERRNO
- *	(and __h_errno_set) to the public via <resolv.h>.
- * XXX:	__h_errno_set is really part of IRS, not part of the resolver.
- *	If somebody wants to build and use a resolver that doesn't use IRS,
- *	what do they do?  Perhaps something like
- *		#ifdef WANT_IRS
- *		# define RES_SET_H_ERRNO(r,x) __h_errno_set(r,x)
- *		#else
- *		# define RES_SET_H_ERRNO(r,x) (h_errno = (r)->res_h_errno = (x))
- *		#endif
- */
-
-#define RES_SET_H_ERRNO(r,x) __h_errno_set(r,x)
-struct __res_state; /*%< forward */
-__BEGIN_DECLS
-void __h_errno_set(struct __res_state *res, int err);
-__END_DECLS
-
-/*%
- * Resolver configuration file.
- * Normally not present, but may contain the address of the
- * initial name server(s) to query and the domain search list.
- */
-
-#ifndef _PATH_RESCONF
-#define _PATH_RESCONF        "/etc/resolv.conf"
-#endif
-
-typedef enum { res_goahead, res_nextns, res_modified, res_done, res_error }
-	res_sendhookact;
-
-#ifndef __PMT
-#if defined(__STDC__) || defined(__cplusplus)
-#define __PMT(args) args
-#else
-#define __PMT(args) ()
-#endif
-#endif
-
-typedef res_sendhookact (*res_send_qhook)__PMT((struct sockaddr * const *,
-						const u_char **, int *,
-						u_char *, int, int *));
-
-typedef res_sendhookact (*res_send_rhook)__PMT((const struct sockaddr *,
-						const u_char *, int, u_char *,
-						int, int *));
-
-struct res_sym {
-	int		number;	   /*%< Identifying number, like T_MX */
-	const char *	name;	   /*%< Its symbolic name, like "MX" */
-	const char *	humanname; /*%< Its fun name, like "mail exchanger" */
-};
-
-/*%
- * Global defines and variables for resolver stub.
- */
-#define	MAXNS			3	/*%< max # name servers we'll track */
-#define	MAXDFLSRCH		3	/*%< # default domain levels to try */
-#define	MAXDNSRCH		6	/*%< max # domains in search path */
-#define	LOCALDOMAINPARTS	2	/*%< min levels in name that is "local" */
-#define	RES_TIMEOUT		5	/*%< min. seconds between retries */
-#define	MAXRESOLVSORT		10	/*%< number of net to sort on */
-#define	RES_MAXNDOTS		15	/*%< should reflect bit field size */
-#define	RES_MAXRETRANS		30	/*%< only for resolv.conf/RES_OPTIONS */
-#define	RES_MAXRETRY		5	/*%< only for resolv.conf/RES_OPTIONS */
-#define	RES_DFLRETRY		2	/*%< Default #/tries. */
-#define	RES_MAXTIME		65535	/*%< Infinity, in milliseconds. */
-struct __res_state_ext;
-
-struct __res_state {
-	int	retrans;	 	/*%< retransmission time interval */
-	int	retry;			/*%< number of times to retransmit */
-#ifdef sun
-	u_int	options;		/*%< option flags - see below. */
-#else
-	u_long	options;		/*%< option flags - see below. */
-#endif
-	int	nscount;		/*%< number of name servers */
-	struct sockaddr_in
-		nsaddr_list[MAXNS];	/*%< address of name server */
-#define	nsaddr	nsaddr_list[0]		/*%< for backward compatibility */
-	u_short	id;			/*%< current message id */
-	char	*dnsrch[MAXDNSRCH+1];	/*%< components of domain to search */
-	char	defdname[256];		/*%< default domain (deprecated) */
-#ifdef sun
-	u_int	pfcode;			/*%< RES_PRF_ flags - see below. */
-#else
-	u_long	pfcode;			/*%< RES_PRF_ flags - see below. */
-#endif
-	unsigned ndots:4;		/*%< threshold for initial abs. query */
-	unsigned nsort:4;		/*%< number of elements in sort_list[] */
-	char	unused[3];
-	struct {
-		struct in_addr	addr;
-		u_int32_t	mask;
-	} sort_list[MAXRESOLVSORT];
-	res_send_qhook qhook;		/*%< query hook */
-	res_send_rhook rhook;		/*%< response hook */
-	int	res_h_errno;		/*%< last one set for this context */
-	int	_vcsock;		/*%< PRIVATE: for res_send VC i/o */
-	u_int	_flags;			/*%< PRIVATE: see below */
-	u_int	_pad;			/*%< make _u 64 bit aligned */
-	union {
-		/* On an 32-bit arch this means 512b total. */
-		char	pad[72 - 4*sizeof (int) - 2*sizeof (void *)];
-		struct {
-			u_int16_t		nscount;
-			u_int16_t		nstimes[MAXNS];	/*%< ms. */
-			int			nssocks[MAXNS];
-			struct __res_state_ext *ext;	/*%< extention for IPv6 */
-		} _ext;
-	} _u;
-};
-
-typedef struct __res_state *res_state;
-
-union res_sockaddr_union {
-	struct sockaddr_in	sin;
-#ifdef IN6ADDR_ANY_INIT
-	struct sockaddr_in6	sin6;
-#endif
-#ifdef ISC_ALIGN64
-	int64_t			__align64;	/*%< 64bit alignment */
-#else
-	int32_t			__align32;	/*%< 32bit alignment */
-#endif
-	char			__space[128];   /*%< max size */
-};
-
-/*%
- * Resolver flags (used to be discrete per-module statics ints).
- */
-#define	RES_F_VC	0x00000001	/*%< socket is TCP */
-#define	RES_F_CONN	0x00000002	/*%< socket is connected */
-#define	RES_F_EDNS0ERR	0x00000004	/*%< EDNS0 caused errors */
-#define	RES_F__UNUSED	0x00000008	/*%< (unused) */
-#define	RES_F_LASTMASK	0x000000F0	/*%< ordinal server of last res_nsend */
-#define	RES_F_LASTSHIFT	4		/*%< bit position of LASTMASK "flag" */
-#define	RES_GETLAST(res) (((res)._flags & RES_F_LASTMASK) >> RES_F_LASTSHIFT)
-
-/* res_findzonecut2() options */
-#define	RES_EXHAUSTIVE	0x00000001	/*%< always do all queries */
-#define	RES_IPV4ONLY	0x00000002	/*%< IPv4 only */
-#define	RES_IPV6ONLY	0x00000004	/*%< IPv6 only */
-
-/*%
- * Resolver options (keep these in synch with res_debug.c, please)
- */
-#define RES_INIT	0x00000001	/*%< address initialized */
-#define RES_DEBUG	0x00000002	/*%< print debug messages */
-#define RES_AAONLY	0x00000004	/*%< authoritative answers only (!IMPL)*/
-#define RES_USEVC	0x00000008	/*%< use virtual circuit */
-#define RES_PRIMARY	0x00000010	/*%< query primary server only (!IMPL) */
-#define RES_IGNTC	0x00000020	/*%< ignore trucation errors */
-#define RES_RECURSE	0x00000040	/*%< recursion desired */
-#define RES_DEFNAMES	0x00000080	/*%< use default domain name */
-#define RES_STAYOPEN	0x00000100	/*%< Keep TCP socket open */
-#define RES_DNSRCH	0x00000200	/*%< search up local domain tree */
-#define	RES_INSECURE1	0x00000400	/*%< type 1 security disabled */
-#define	RES_INSECURE2	0x00000800	/*%< type 2 security disabled */
-#define	RES_NOALIASES	0x00001000	/*%< shuts off HOSTALIASES feature */
-#define	RES_USE_INET6	0x00002000	/*%< use/map IPv6 in gethostbyname() */
-#define RES_ROTATE	0x00004000	/*%< rotate ns list after each query */
-#define	RES_NOCHECKNAME	0x00008000	/*%< do not check names for sanity. */
-#define	RES_KEEPTSIG	0x00010000	/*%< do not strip TSIG records */
-#define	RES_BLAST	0x00020000	/*%< blast all recursive servers */
-#define RES_NSID	0x00040000      /*%< request name server ID */
-#define RES_NOTLDQUERY	0x00100000	/*%< don't unqualified name as a tld */
-#define RES_USE_DNSSEC	0x00200000	/*%< use DNSSEC using OK bit in OPT */
-/* #define RES_DEBUG2	0x00400000 */	/* nslookup internal */
-/* KAME extensions: use higher bit to avoid conflict with ISC use */
-#define RES_USE_DNAME	0x10000000	/*%< use DNAME */
-#define RES_USE_EDNS0	0x40000000	/*%< use EDNS0 if configured */
-#define RES_NO_NIBBLE2	0x80000000	/*%< disable alternate nibble lookup */
-
-#define RES_DEFAULT	(RES_RECURSE | RES_DEFNAMES | \
-			 RES_DNSRCH | RES_NO_NIBBLE2)
-
-/*%
- * Resolver "pfcode" values.  Used by dig.
- */
-#define RES_PRF_STATS	0x00000001
-#define RES_PRF_UPDATE	0x00000002
-#define RES_PRF_CLASS   0x00000004
-#define RES_PRF_CMD	0x00000008
-#define RES_PRF_QUES	0x00000010
-#define RES_PRF_ANS	0x00000020
-#define RES_PRF_AUTH	0x00000040
-#define RES_PRF_ADD	0x00000080
-#define RES_PRF_HEAD1	0x00000100
-#define RES_PRF_HEAD2	0x00000200
-#define RES_PRF_TTLID	0x00000400
-#define RES_PRF_HEADX	0x00000800
-#define RES_PRF_QUERY	0x00001000
-#define RES_PRF_REPLY	0x00002000
-#define RES_PRF_INIT	0x00004000
-#define RES_PRF_TRUNC	0x00008000
-/*			0x00010000	*/
-
-/* Things involving an internal (static) resolver context. */
-#ifdef _REENTRANT
-__BEGIN_DECLS
-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
-#endif
-
-#ifndef __BIND_NOSTATIC
-#define fp_nquery		__fp_nquery
-#define fp_query		__fp_query
-#define hostalias		__hostalias
-#define p_query			__p_query
-#define res_close		__res_close
-#define res_init		__res_init
-#define res_isourserver		__res_isourserver
-#define res_mkquery		__res_mkquery
-#define res_query		__res_query
-#define res_querydomain		__res_querydomain
-#define res_search		__res_search
-#define res_send		__res_send
-#define res_sendsigned		__res_sendsigned
-
-__BEGIN_DECLS
-void		fp_nquery __P((const u_char *, int, FILE *));
-void		fp_query __P((const u_char *, FILE *));
-const char *	hostalias __P((const char *));
-void		p_query __P((const u_char *));
-void		res_close __P((void));
-int		res_init __P((void));
-int		res_isourserver __P((const struct sockaddr_in *));
-int		res_mkquery __P((int, const char *, int, int, const u_char *,
-				 int, const u_char *, u_char *, int));
-int		res_query __P((const char *, int, int, u_char *, int));
-int		res_querydomain __P((const char *, const char *, int, int,
-				     u_char *, int));
-int		res_search __P((const char *, int, int, u_char *, int));
-int		res_send __P((const u_char *, int, u_char *, int));
-int		res_sendsigned __P((const u_char *, int, ns_tsig_key *,
-				    u_char *, int));
-__END_DECLS
-#endif
-
-#if !defined(SHARED_LIBBIND) || defined(LIB)
-/*
- * If libbind is a shared object (well, DLL anyway)
- * these externs break the linker when resolv.h is 
- * included by a lib client (like named)
- * Make them go away if a client is including this
- *
- */
-extern const struct res_sym __p_key_syms[];
-extern const struct res_sym __p_cert_syms[];
-extern const struct res_sym __p_class_syms[];
-extern const struct res_sym __p_type_syms[];
-extern const struct res_sym __p_rcode_syms[];
-#endif /* SHARED_LIBBIND */
-
-#define b64_ntop		__b64_ntop
-#define b64_pton		__b64_pton
-#define dn_comp			__dn_comp
-#define dn_count_labels		__dn_count_labels
-#define dn_expand		__dn_expand
-#define dn_skipname		__dn_skipname
-#define fp_resstat		__fp_resstat
-#define loc_aton		__loc_aton
-#define loc_ntoa		__loc_ntoa
-#define p_cdname		__p_cdname
-#define p_cdnname		__p_cdnname
-#define p_class			__p_class
-#define p_fqname		__p_fqname
-#define p_fqnname		__p_fqnname
-#define p_option		__p_option
-#define p_secstodate		__p_secstodate
-#define p_section		__p_section
-#define p_time			__p_time
-#define p_type			__p_type
-#define p_rcode			__p_rcode
-#define p_sockun		__p_sockun
-#define putlong			__putlong
-#define putshort		__putshort
-#define res_dnok		__res_dnok
-#define res_findzonecut		__res_findzonecut
-#define res_findzonecut2	__res_findzonecut2
-#define res_hnok		__res_hnok
-#define res_hostalias		__res_hostalias
-#define res_mailok		__res_mailok
-#define res_nameinquery		__res_nameinquery
-#define res_nclose		__res_nclose
-#define res_ninit		__res_ninit
-#define res_nmkquery		__res_nmkquery
-#define res_pquery		__res_pquery
-#define res_nquery		__res_nquery
-#define res_nquerydomain	__res_nquerydomain
-#define res_nsearch		__res_nsearch
-#define res_nsend		__res_nsend
-#define res_nsendsigned		__res_nsendsigned
-#define res_nisourserver	__res_nisourserver
-#define res_ownok		__res_ownok
-#define res_queriesmatch	__res_queriesmatch
-#define res_randomid		__res_randomid
-#define sym_ntop		__sym_ntop
-#define sym_ntos		__sym_ntos
-#define sym_ston		__sym_ston
-#define res_nopt		__res_nopt
-#define res_nopt_rdata       	__res_nopt_rdata
-#define res_ndestroy		__res_ndestroy
-#define	res_nametoclass		__res_nametoclass
-#define	res_nametotype		__res_nametotype
-#define	res_setservers		__res_setservers
-#define	res_getservers		__res_getservers
-#define	res_buildprotolist	__res_buildprotolist
-#define	res_destroyprotolist	__res_destroyprotolist
-#define	res_destroyservicelist	__res_destroyservicelist
-#define	res_get_nibblesuffix	__res_get_nibblesuffix
-#define	res_get_nibblesuffix2	__res_get_nibblesuffix2
-#define	res_ourserver_p		__res_ourserver_p
-#define	res_protocolname	__res_protocolname
-#define	res_protocolnumber	__res_protocolnumber
-#define	res_send_setqhook	__res_send_setqhook
-#define	res_send_setrhook	__res_send_setrhook
-#define	res_servicename		__res_servicename
-#define	res_servicenumber	__res_servicenumber
-__BEGIN_DECLS
-int		res_hnok __P((const char *));
-int		res_ownok __P((const char *));
-int		res_mailok __P((const char *));
-int		res_dnok __P((const char *));
-int		sym_ston __P((const struct res_sym *, const char *, int *));
-const char *	sym_ntos __P((const struct res_sym *, int, int *));
-const char *	sym_ntop __P((const struct res_sym *, int, int *));
-int		b64_ntop __P((u_char const *, size_t, char *, size_t));
-int		b64_pton __P((char const *, u_char *, size_t));
-int		loc_aton __P((const char *, u_char *));
-const char *	loc_ntoa __P((const u_char *, char *));
-int		dn_skipname __P((const u_char *, const u_char *));
-void		putlong __P((u_int32_t, u_char *));
-void		putshort __P((u_int16_t, u_char *));
-#ifndef __ultrix__
-u_int16_t	_getshort __P((const u_char *));
-u_int32_t	_getlong __P((const u_char *));
-#endif
-const char *	p_class __P((int));
-const char *	p_time __P((u_int32_t));
-const char *	p_type __P((int));
-const char *	p_rcode __P((int));
-const char *	p_sockun __P((union res_sockaddr_union, char *, size_t));
-const u_char *	p_cdnname __P((const u_char *, const u_char *, int, FILE *));
-const u_char *	p_cdname __P((const u_char *, const u_char *, FILE *));
-const u_char *	p_fqnname __P((const u_char *, const u_char *,
-			       int, char *, int));
-const u_char *	p_fqname __P((const u_char *, const u_char *, FILE *));
-const char *	p_option __P((u_long));
-char *		p_secstodate __P((u_long));
-int		dn_count_labels __P((const char *));
-int		dn_comp __P((const char *, u_char *, int,
-			     u_char **, u_char **));
-int		dn_expand __P((const u_char *, const u_char *, const u_char *,
-			       char *, int));
-u_int		res_randomid __P((void));
-int		res_nameinquery __P((const char *, int, int, const u_char *,
-				     const u_char *));
-int		res_queriesmatch __P((const u_char *, const u_char *,
-				      const u_char *, const u_char *));
-const char *	p_section __P((int, int));
-/* Things involving a resolver context. */
-int		res_ninit __P((res_state));
-int		res_nisourserver __P((const res_state,
-				      const struct sockaddr_in *));
-void		fp_resstat __P((const res_state, FILE *));
-void		res_pquery __P((const res_state, const u_char *, int, FILE *));
-const char *	res_hostalias __P((const res_state, const char *,
-				   char *, size_t));
-int		res_nquery __P((res_state, const char *, int, int,
-				u_char *, int));
-int		res_nsearch __P((res_state, const char *, int, int, u_char *,
-				 int));
-int		res_nquerydomain __P((res_state, const char *, const char *,
-				      int, int, u_char *, int));
-int		res_nmkquery __P((res_state, int, const char *, int, int,
-				  const u_char *, int, const u_char *,
-				  u_char *, int));
-int		res_nsend __P((res_state, const u_char *, int, u_char *, int));
-int		res_nsendsigned __P((res_state, const u_char *, int,
-				     ns_tsig_key *, u_char *, int));
-int		res_findzonecut __P((res_state, const char *, ns_class, int,
-				     char *, size_t, struct in_addr *, int));
-int		res_findzonecut2 __P((res_state, const char *, ns_class, int,
-				      char *, size_t,
-				      union res_sockaddr_union *, int));
-void		res_nclose __P((res_state));
-int		res_nopt __P((res_state, int, u_char *, int, int));
-int		res_nopt_rdata __P((res_state, int, u_char *, int, u_char *,
-				    u_short, u_short, u_char *));
-void		res_send_setqhook __P((res_send_qhook));
-void		res_send_setrhook __P((res_send_rhook));
-int		__res_vinit __P((res_state, int));
-void		res_destroyservicelist __P((void));
-const char *	res_servicename __P((u_int16_t, const char *));
-const char *	res_protocolname __P((int));
-void		res_destroyprotolist __P((void));
-void		res_buildprotolist __P((void));
-const char *	res_get_nibblesuffix __P((res_state));
-const char *	res_get_nibblesuffix2 __P((res_state));
-void		res_ndestroy __P((res_state));
-u_int16_t	res_nametoclass __P((const char *, int *));
-u_int16_t	res_nametotype __P((const char *, int *));
-void		res_setservers __P((res_state,
-				    const union res_sockaddr_union *, int));
-int		res_getservers __P((res_state,
-				    union res_sockaddr_union *, int));
-__END_DECLS
-
-#endif /* !_RESOLV_H_ */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/include/resolv_mt.h b/contrib/bind9/lib/bind/include/resolv_mt.h
deleted file mode 100644
index 27963a1..0000000
--- a/contrib/bind9/lib/bind/include/resolv_mt.h
+++ /dev/null
@@ -1,47 +0,0 @@
-#ifndef _RESOLV_MT_H
-#define _RESOLV_MT_H
-
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <resolv.h>
-
-/* Access functions for the libresolv private interface */
-
-int	__res_enable_mt(void);
-int	__res_disable_mt(void);
-
-/* Per-thread context */
-
-typedef struct {
-int	no_hosts_fallback_private;
-int	retry_save;
-int	retry_private;
-char	inet_nsap_ntoa_tmpbuf[255*3];
-char	sym_ntos_unname[20];
-char	sym_ntop_unname[20];
-char	p_option_nbuf[40];
-char	p_time_nbuf[40];
-char	precsize_ntoa_retbuf[sizeof "90000000.00"];
-char	loc_ntoa_tmpbuf[sizeof
-"1000 60 60.000 N 1000 60 60.000 W -12345678.00m 90000000.00m 90000000.00m 90000000.00m"];
-char	p_secstodate_output[15];
-} mtctxres_t;
-
-/* Thread-specific data (TSD) */
-
-mtctxres_t	*___mtctxres(void);
-#define mtctxres	(___mtctxres())
-
-/* Various static data that should be TSD */
-
-#define sym_ntos_unname		(mtctxres->sym_ntos_unname)
-#define sym_ntop_unname		(mtctxres->sym_ntop_unname)
-#define inet_nsap_ntoa_tmpbuf	(mtctxres->inet_nsap_ntoa_tmpbuf)
-#define p_option_nbuf		(mtctxres->p_option_nbuf)
-#define p_time_nbuf		(mtctxres->p_time_nbuf)
-#define precsize_ntoa_retbuf	(mtctxres->precsize_ntoa_retbuf)
-#define loc_ntoa_tmpbuf		(mtctxres->loc_ntoa_tmpbuf)
-#define p_secstodate_output	(mtctxres->p_secstodate_output)
-
-#endif /* _RESOLV_MT_H */
diff --git a/contrib/bind9/lib/bind/inet/Makefile.in b/contrib/bind9/lib/bind/inet/Makefile.in
deleted file mode 100644
index 7b84896..0000000
--- a/contrib/bind9/lib/bind/inet/Makefile.in
+++ /dev/null
@@ -1,35 +0,0 @@
-# Copyright (C) 2004, 2008  Internet Systems Consortium, Inc. ("ISC")
-# Copyright (C) 2001  Internet Software Consortium.
-#
-# Permission to use, copy, modify, and/or 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: Makefile.in,v 1.5.18.2 2008/03/20 23:46:01 tbox Exp $
-
-srcdir=		@srcdir@
-VPATH =         @srcdir@
-
-OBJS=	inet_addr.@O@ inet_cidr_ntop.@O@ inet_cidr_pton.@O@ inet_data.@O@ \
-	inet_lnaof.@O@ inet_makeaddr.@O@ inet_net_ntop.@O@ inet_net_pton.@O@ \
-	inet_neta.@O@ inet_netof.@O@ inet_network.@O@ inet_ntoa.@O@ \
-	inet_ntop.@O@ inet_pton.@O@ nsap_addr.@O@
-
-SRCS=	inet_addr.c inet_cidr_ntop.c inet_cidr_pton.c inet_data.c \
-	inet_lnaof.c inet_makeaddr.c inet_net_ntop.c inet_net_pton.c \
-	inet_neta.c inet_netof.c inet_network.c inet_ntoa.c \
-	inet_ntop.c inet_pton.c nsap_addr.c
-
-TARGETS= ${OBJS}
-
-CINCLUDES= -I.. -I../include -I${srcdir}/../include
-
-@BIND9_MAKE_RULES@
diff --git a/contrib/bind9/lib/bind/inet/inet_addr.c b/contrib/bind9/lib/bind/inet/inet_addr.c
deleted file mode 100644
index c95622d..0000000
--- a/contrib/bind9/lib/bind/inet/inet_addr.c
+++ /dev/null
@@ -1,208 +0,0 @@
-/*
- * Copyright (c) 1983, 1990, 1993
- *    The Regents of the University of California.  All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- * 	This product includes software developed by the University of
- * 	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-/*
- * Portions Copyright (c) 1993 by Digital Equipment Corporation.
- * 
- * 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, and that
- * the name of Digital Equipment Corporation not be used in advertising or
- * publicity pertaining to distribution of the document or software without
- * specific, written prior permission.
- * 
- * THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
- * WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
- * OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
- * CORPORATION 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.
- */
-
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char sccsid[] = "@(#)inet_addr.c	8.1 (Berkeley) 6/17/93";
-static const char rcsid[] = "$Id: inet_addr.c,v 1.4.18.1 2005/04/27 05:00:52 sra Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/param.h>
-
-#include <netinet/in.h>
-#include <arpa/inet.h>
-
-#include <ctype.h>
-
-#include "port_after.h"
-
-/*%
- * Ascii internet address interpretation routine.
- * The value returned is in network order.
- */
-u_long
-inet_addr(const char *cp) {
-	struct in_addr val;
-
-	if (inet_aton(cp, &val))
-		return (val.s_addr);
-	return (INADDR_NONE);
-}
-
-/*%
- * Check whether "cp" is a valid ascii representation
- * of an Internet address and convert to a binary address.
- * Returns 1 if the address is valid, 0 if not.
- * This replaces inet_addr, the return value from which
- * cannot distinguish between failure and a local broadcast address.
- */
-int
-inet_aton(const char *cp, struct in_addr *addr) {
-	u_long val;
-	int base, n;
-	char c;
-	u_int8_t parts[4];
-	u_int8_t *pp = parts;
-	int digit;
-
-	c = *cp;
-	for (;;) {
-		/*
-		 * Collect number up to ``.''.
-		 * Values are specified as for C:
-		 * 0x=hex, 0=octal, isdigit=decimal.
-		 */
-		if (!isdigit((unsigned char)c))
-			return (0);
-		val = 0; base = 10; digit = 0;
-		if (c == '0') {
-			c = *++cp;
-			if (c == 'x' || c == 'X')
-				base = 16, c = *++cp;
-			else {
-				base = 8;
-				digit = 1 ;
-			}
-		}
-		for (;;) {
-			if (isascii(c) && isdigit((unsigned char)c)) {
-				if (base == 8 && (c == '8' || c == '9'))
-					return (0);
-				val = (val * base) + (c - '0');
-				c = *++cp;
-				digit = 1;
-			} else if (base == 16 && isascii(c) && 
-				   isxdigit((unsigned char)c)) {
-				val = (val << 4) |
-					(c + 10 - (islower((unsigned char)c) ? 'a' : 'A'));
-				c = *++cp;
-				digit = 1;
-			} else
-				break;
-		}
-		if (c == '.') {
-			/*
-			 * Internet format:
-			 *	a.b.c.d
-			 *	a.b.c	(with c treated as 16 bits)
-			 *	a.b	(with b treated as 24 bits)
-			 */
-			if (pp >= parts + 3 || val > 0xffU)
-				return (0);
-			*pp++ = val;
-			c = *++cp;
-		} else
-			break;
-	}
-	/*
-	 * Check for trailing characters.
-	 */
-	if (c != '\0' && (!isascii(c) || !isspace((unsigned char)c)))
-		return (0);
-	/*
-	 * Did we get a valid digit?
-	 */
-	if (!digit)
-		return (0);
-	/*
-	 * Concoct the address according to
-	 * the number of parts specified.
-	 */
-	n = pp - parts + 1;
-	switch (n) {
-	case 1:				/*%< a -- 32 bits */
-		break;
-
-	case 2:				/*%< a.b -- 8.24 bits */
-		if (val > 0xffffffU)
-			return (0);
-		val |= parts[0] << 24;
-		break;
-
-	case 3:				/*%< a.b.c -- 8.8.16 bits */
-		if (val > 0xffffU)
-			return (0);
-		val |= (parts[0] << 24) | (parts[1] << 16);
-		break;
-
-	case 4:				/*%< a.b.c.d -- 8.8.8.8 bits */
-		if (val > 0xffU)
-			return (0);
-		val |= (parts[0] << 24) | (parts[1] << 16) | (parts[2] << 8);
-		break;
-	}
-	if (addr != NULL)
-		addr->s_addr = htonl(val);
-	return (1);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/inet/inet_cidr_ntop.c b/contrib/bind9/lib/bind/inet/inet_cidr_ntop.c
deleted file mode 100644
index 645b3cd..0000000
--- a/contrib/bind9/lib/bind/inet/inet_cidr_ntop.c
+++ /dev/null
@@ -1,263 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1998,1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: inet_cidr_ntop.c,v 1.4.18.3 2006/10/11 02:32:47 marka Exp $";
-#endif
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/socket.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <arpa/inet.h>
-
-#include <errno.h>
-#include <stdio.h>
-#include <string.h>
-#include <stdlib.h>
-
-#include "port_after.h"
-
-#ifdef SPRINTF_CHAR
-# define SPRINTF(x) strlen(sprintf/**/x)
-#else
-# define SPRINTF(x) ((size_t)sprintf x)
-#endif
-
-static char *
-inet_cidr_ntop_ipv4(const u_char *src, int bits, char *dst, size_t size);
-static char *
-inet_cidr_ntop_ipv6(const u_char *src, int bits, char *dst, size_t size);
-
-/*%
- * char *
- * inet_cidr_ntop(af, src, bits, dst, size)
- *	convert network address from network to presentation format.
- *	"src"'s size is determined from its "af".
- * return:
- *	pointer to dst, or NULL if an error occurred (check errno).
- * note:
- *	192.5.5.1/28 has a nonzero host part, which means it isn't a network
- *	as called for by inet_net_ntop() but it can be a host address with
- *	an included netmask.
- * author:
- *	Paul Vixie (ISC), October 1998
- */
-char *
-inet_cidr_ntop(int af, const void *src, int bits, char *dst, size_t size) {
-	switch (af) {
-	case AF_INET:
-		return (inet_cidr_ntop_ipv4(src, bits, dst, size));
-	case AF_INET6:
-		return (inet_cidr_ntop_ipv6(src, bits, dst, size));
-	default:
-		errno = EAFNOSUPPORT;
-		return (NULL);
-	}
-}
-
-static int
-decoct(const u_char *src, int bytes, char *dst, size_t size) {
-	char *odst = dst;
-	char *t;
-	int b;
-
-	for (b = 1; b <= bytes; b++) {
-		if (size < sizeof "255.")
-			return (0);
-		t = dst;
-		dst += SPRINTF((dst, "%u", *src++));
-		if (b != bytes) {
-			*dst++ = '.';
-			*dst = '\0';
-		}
-		size -= (size_t)(dst - t);
-	}
-	return (dst - odst);
-}
-
-/*%
- * static char *
- * inet_cidr_ntop_ipv4(src, bits, dst, size)
- *	convert IPv4 network address from network to presentation format.
- *	"src"'s size is determined from its "af".
- * return:
- *	pointer to dst, or NULL if an error occurred (check errno).
- * note:
- *	network byte order assumed.  this means 192.5.5.240/28 has
- *	0b11110000 in its fourth octet.
- * author:
- *	Paul Vixie (ISC), October 1998
- */
-static char *
-inet_cidr_ntop_ipv4(const u_char *src, int bits, char *dst, size_t size) {
-	char *odst = dst;
-	size_t len = 4;
-	size_t b;
-	size_t bytes;
-
-	if ((bits < -1) || (bits > 32)) {
-		errno = EINVAL;
-		return (NULL);
-	}
-
-	/* Find number of significant bytes in address. */
-	if (bits == -1)
-		len = 4;
-	else
-		for (len = 1, b = 1 ; b < 4U; b++)
-			if (*(src + b))
-				len = b + 1;
-
-	/* Format whole octets plus nonzero trailing octets. */
-	bytes = (((bits <= 0) ? 1 : bits) + 7) / 8;
-	if (len > bytes)
-		bytes = len;
-	b = decoct(src, bytes, dst, size);
-	if (b == 0U)
-		goto emsgsize;
-	dst += b;
-	size -= b;
-
-	if (bits != -1) {
-		/* Format CIDR /width. */
-		if (size < sizeof "/32")
-			goto emsgsize;
-		dst += SPRINTF((dst, "/%u", bits));
-	}
-
-	return (odst);
-
- emsgsize:
-	errno = EMSGSIZE;
-	return (NULL);
-}
- 
-static char *
-inet_cidr_ntop_ipv6(const u_char *src, int bits, char *dst, size_t size) {
-	/*
-	 * Note that int32_t and int16_t need only be "at least" large enough
-	 * to contain a value of the specified size.  On some systems, like
-	 * Crays, there is no such thing as an integer variable with 16 bits.
-	 * Keep this in mind if you think this function should have been coded
-	 * to use pointer overlays.  All the world's not a VAX.
-	 */
-	char tmp[sizeof "ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255/128"];
-	char *tp;
-	struct { int base, len; } best, cur;
-	u_int words[NS_IN6ADDRSZ / NS_INT16SZ];
-	int i;
-
-	if ((bits < -1) || (bits > 128)) {
-		errno = EINVAL;
-		return (NULL);
-	}
-
-	/*
-	 * Preprocess:
-	 *	Copy the input (bytewise) array into a wordwise array.
-	 *	Find the longest run of 0x00's in src[] for :: shorthanding.
-	 */
-	memset(words, '\0', sizeof words);
-	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)
-				cur.base = i, cur.len = 1;
-			else
-				cur.len++;
-		} else {
-			if (cur.base != -1) {
-				if (best.base == -1 || cur.len > best.len)
-					best = cur;
-				cur.base = -1;
-			}
-		}
-	}
-	if (cur.base != -1) {
-		if (best.base == -1 || cur.len > best.len)
-			best = cur;
-	}
-	if (best.base != -1 && best.len < 2)
-		best.base = -1;
-
-	/*
-	 * Format the result.
-	 */
-	tp = tmp;
-	for (i = 0; i < (NS_IN6ADDRSZ / NS_INT16SZ); i++) {
-		/* Are we inside the best run of 0x00's? */
-		if (best.base != -1 && i >= best.base &&
-		    i < (best.base + best.len)) {
-			if (i == best.base)
-				*tp++ = ':';
-			continue;
-		}
-		/* Are we following an initial run of 0x00s or any real hex? */
-		if (i != 0)
-			*tp++ = ':';
-		/* Is this address an encapsulated IPv4? */
-		if (i == 6 && best.base == 0 && (best.len == 6 ||
-		    (best.len == 7 && words[7] != 0x0001) ||
-		    (best.len == 5 && words[5] == 0xffff))) {
-			int n;
-
-			if (src[15] || bits == -1 || bits > 120)
-				n = 4;
-			else if (src[14] || bits > 112)
-				n = 3;
-			else
-				n = 2;
-			n = decoct(src+12, n, tp, sizeof tmp - (tp - tmp));
-			if (n == 0) {
-				errno = EMSGSIZE;
-				return (NULL);
-			}
-			tp += strlen(tp);
-			break;
-		}
-		tp += SPRINTF((tp, "%x", words[i]));
-	}
-
-	/* Was it a trailing run of 0x00's? */
-	if (best.base != -1 && (best.base + best.len) == 
-	    (NS_IN6ADDRSZ / NS_INT16SZ))
-		*tp++ = ':';
-	*tp = '\0';
-
-	if (bits != -1)
-		tp += SPRINTF((tp, "/%u", bits));
-
-	/*
-	 * Check for overflow, copy, and we're done.
-	 */
-	if ((size_t)(tp - tmp) > size) {
-		errno = EMSGSIZE;
-		return (NULL);
-	}
-	strcpy(dst, tmp);
-	return (dst);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/inet/inet_cidr_pton.c b/contrib/bind9/lib/bind/inet/inet_cidr_pton.c
deleted file mode 100644
index b55e3ea..0000000
--- a/contrib/bind9/lib/bind/inet/inet_cidr_pton.c
+++ /dev/null
@@ -1,277 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1998,1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: inet_cidr_pton.c,v 1.5.18.1 2005/04/27 05:00:53 sra Exp $";
-#endif
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/socket.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <arpa/inet.h>
-
-#include <isc/assertions.h>
-#include <ctype.h>
-#include <errno.h>
-#include <stdio.h>
-#include <string.h>
-#include <stdlib.h>
-
-#include "port_after.h"
-
-#ifdef SPRINTF_CHAR
-# define SPRINTF(x) strlen(sprintf/**/x)
-#else
-# define SPRINTF(x) ((size_t)sprintf x)
-#endif
-
-static int	inet_cidr_pton_ipv4 __P((const char *src, u_char *dst,
-					 int *bits, int ipv6));
-static int	inet_cidr_pton_ipv6 __P((const char *src, u_char *dst,
-					 int *bits));
-
-static int	getbits(const char *, int ipv6);
-
-/*%
- * int
- * inet_cidr_pton(af, src, dst, *bits)
- *	convert network address from presentation to network format.
- *	accepts inet_pton()'s input for this "af" plus trailing "/CIDR".
- *	"dst" is assumed large enough for its "af".  "bits" is set to the
- *	/CIDR prefix length, which can have defaults (like /32 for IPv4).
- * return:
- *	-1 if an error occurred (inspect errno; ENOENT means bad format).
- *	0 if successful conversion occurred.
- * note:
- *	192.5.5.1/28 has a nonzero host part, which means it isn't a network
- *	as called for by inet_net_pton() but it can be a host address with
- *	an included netmask.
- * author:
- *	Paul Vixie (ISC), October 1998
- */
-int
-inet_cidr_pton(int af, const char *src, void *dst, int *bits) {
-	switch (af) {
-	case AF_INET:
-		return (inet_cidr_pton_ipv4(src, dst, bits, 0));
-	case AF_INET6:
-		return (inet_cidr_pton_ipv6(src, dst, bits));
-	default:
-		errno = EAFNOSUPPORT;
-		return (-1);
-	}
-}
-
-static const char digits[] = "0123456789";
-
-static int
-inet_cidr_pton_ipv4(const char *src, u_char *dst, int *pbits, int ipv6) {
-	const u_char *odst = dst;
-	int n, ch, tmp, bits;
-	size_t size = 4;
-
-	/* Get the mantissa. */
-	while (ch = *src++, (isascii(ch) && isdigit(ch))) {
-		tmp = 0;
-		do {
-			n = strchr(digits, ch) - digits;
-			INSIST(n >= 0 && n <= 9);
-			tmp *= 10;
-			tmp += n;
-			if (tmp > 255)
-				goto enoent;
-		} while ((ch = *src++) != '\0' && isascii(ch) && isdigit(ch));
-		if (size-- == 0U)
-			goto emsgsize;
-		*dst++ = (u_char) tmp;
-		if (ch == '\0' || ch == '/')
-			break;
-		if (ch != '.')
-			goto enoent;
-	}
-
-	/* Get the prefix length if any. */
-	bits = -1;
-	if (ch == '/' && dst > odst) {
-		bits = getbits(src, ipv6);
-		if (bits == -2)
-			goto enoent;
-	} else if (ch != '\0')
-		goto enoent;
-
-	/* Prefix length can default to /32 only if all four octets spec'd. */
-	if (bits == -1) {
-		if (dst - odst == 4)
-			bits = ipv6 ? 128 : 32;
-		else
-			goto enoent;
-	}
-
-	/* If nothing was written to the destination, we found no address. */
-	if (dst == odst)
-		goto enoent;
-
-	/* If prefix length overspecifies mantissa, life is bad. */
-	if (((bits - (ipv6 ? 96 : 0)) / 8) > (dst - odst))
-		goto enoent;
-
-	/* Extend address to four octets. */
-	while (size-- > 0U)
-		*dst++ = 0;
-
-	*pbits = bits;
-	return (0);
-
- enoent:
-	errno = ENOENT;
-	return (-1);
-
- emsgsize:
-	errno = EMSGSIZE;
-	return (-1);
-}
-
-static int
-inet_cidr_pton_ipv6(const char *src, u_char *dst, int *pbits) {
-	static const char xdigits_l[] = "0123456789abcdef",
-			  xdigits_u[] = "0123456789ABCDEF";
-	u_char tmp[NS_IN6ADDRSZ], *tp, *endp, *colonp;
-	const char *xdigits, *curtok;
-	int ch, saw_xdigit;
-	u_int val;
-	int bits;
-
-	memset((tp = tmp), '\0', NS_IN6ADDRSZ);
-	endp = tp + NS_IN6ADDRSZ;
-	colonp = NULL;
-	/* Leading :: requires some special handling. */
-	if (*src == ':')
-		if (*++src != ':')
-			return (0);
-	curtok = src;
-	saw_xdigit = 0;
-	val = 0;
-	bits = -1;
-	while ((ch = *src++) != '\0') {
-		const char *pch;
-
-		if ((pch = strchr((xdigits = xdigits_l), ch)) == NULL)
-			pch = strchr((xdigits = xdigits_u), ch);
-		if (pch != NULL) {
-			val <<= 4;
-			val |= (pch - xdigits);
-			if (val > 0xffff)
-				return (0);
-			saw_xdigit = 1;
-			continue;
-		}
-		if (ch == ':') {
-			curtok = src;
-			if (!saw_xdigit) {
-				if (colonp)
-					return (0);
-				colonp = tp;
-				continue;
-			} else if (*src == '\0') {
-				return (0);
-			}
-			if (tp + NS_INT16SZ > endp)
-				return (0);
-			*tp++ = (u_char) (val >> 8) & 0xff;
-			*tp++ = (u_char) val & 0xff;
-			saw_xdigit = 0;
-			val = 0;
-			continue;
-		}
-		if (ch == '.' && ((tp + NS_INADDRSZ) <= endp) &&
-		    inet_cidr_pton_ipv4(curtok, tp, &bits, 1) == 0) {
-			tp += NS_INADDRSZ;
-			saw_xdigit = 0;
-			break;	/*%< '\\0' was seen by inet_pton4(). */
-		}
-		if (ch == '/') {
-			bits = getbits(src, 1);
-			if (bits == -2)
-				goto enoent;
-			break;
-		}
-		goto enoent;
-	}
-	if (saw_xdigit) {
-		if (tp + NS_INT16SZ > endp)
-			goto emsgsize;
-		*tp++ = (u_char) (val >> 8) & 0xff;
-		*tp++ = (u_char) val & 0xff;
-	}
-	if (colonp != NULL) {
-		/*
-		 * Since some memmove()'s erroneously fail to handle
-		 * overlapping regions, we'll do the shift by hand.
-		 */
-		const int n = tp - colonp;
-		int i;
-
-		if (tp == endp)
-			goto enoent;
-		for (i = 1; i <= n; i++) {
-			endp[- i] = colonp[n - i];
-			colonp[n - i] = 0;
-		}
-		tp = endp;
-	}
-
-	memcpy(dst, tmp, NS_IN6ADDRSZ);
-
-	*pbits = bits;
-	return (0);
-
- enoent:
-	errno = ENOENT;
-	return (-1);
-
- emsgsize:
-	errno = EMSGSIZE;
-	return (-1);
-}
-
-static int
-getbits(const char *src, int ipv6) {
-	int bits = 0;
-	char *cp, ch;
-	
-	if (*src == '\0')			/*%< syntax */
-		return (-2);
-	do {
-		ch = *src++;
-		cp = strchr(digits, ch);
-		if (cp == NULL)			/*%< syntax */
-			return (-2);
-		bits *= 10;
-		bits += cp - digits;
-		if (bits == 0 && *src != '\0')	/*%< no leading zeros */
-			return (-2);
-		if (bits > (ipv6 ? 128 : 32))	/*%< range error */
-			return (-2);
-	} while (*src != '\0');
-
-	return (bits);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/inet/inet_data.c b/contrib/bind9/lib/bind/inet/inet_data.c
deleted file mode 100644
index f3fa25b..0000000
--- a/contrib/bind9/lib/bind/inet/inet_data.c
+++ /dev/null
@@ -1,46 +0,0 @@
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static char rcsid[] = "$Id: inet_data.c,v 1.3.18.1 2005/04/27 05:00:53 sra Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/param.h>
-#include <sys/socket.h>
-#include <sys/time.h>
-
-#include <netinet/in.h>
-#include <arpa/inet.h>
-#include <arpa/nameser.h>
-
-#include <ctype.h>
-#include <netdb.h>
-#include <resolv.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <unistd.h>
-
-#include "port_after.h"
-
-const struct in6_addr isc_in6addr_any = IN6ADDR_ANY_INIT;
-const struct in6_addr isc_in6addr_loopback = IN6ADDR_LOOPBACK_INIT;
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/inet/inet_lnaof.c b/contrib/bind9/lib/bind/inet/inet_lnaof.c
deleted file mode 100644
index 70ac409..0000000
--- a/contrib/bind9/lib/bind/inet/inet_lnaof.c
+++ /dev/null
@@ -1,65 +0,0 @@
-/*
- * Copyright (c) 1983, 1993
- *	The Regents of the University of California.  All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- *	This product includes software developed by the University of
- *	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char sccsid[] = "@(#)inet_lnaof.c	8.1 (Berkeley) 6/4/93";
-#endif /* LIBC_SCCS and not lint */
-
-#include "port_before.h"
-
-#include <sys/param.h>
-#include <netinet/in.h>
-#include <arpa/inet.h>
-
-#include "port_after.h"
-
-/*%
- * Return the local network address portion of an
- * internet address; handles class a/b/c network
- * number formats.
- */
-u_long
-inet_lnaof(in)
-	struct in_addr in;
-{
-	register u_long i = ntohl(in.s_addr);
-
-	if (IN_CLASSA(i))
-		return ((i)&IN_CLASSA_HOST);
-	else if (IN_CLASSB(i))
-		return ((i)&IN_CLASSB_HOST);
-	else
-		return ((i)&IN_CLASSC_HOST);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/inet/inet_makeaddr.c b/contrib/bind9/lib/bind/inet/inet_makeaddr.c
deleted file mode 100644
index c56cb3e..0000000
--- a/contrib/bind9/lib/bind/inet/inet_makeaddr.c
+++ /dev/null
@@ -1,68 +0,0 @@
-/*
- * Copyright (c) 1983, 1993
- *	The Regents of the University of California.  All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- *	This product includes software developed by the University of
- *	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char sccsid[] = "@(#)inet_makeaddr.c	8.1 (Berkeley) 6/4/93";
-#endif /* LIBC_SCCS and not lint */
-
-#include "port_before.h"
-
-#include <sys/param.h>
-#include <netinet/in.h>
-#include <arpa/inet.h>
-
-#include "port_after.h"
-
-/*%
- * Formulate an Internet address from network + host.  Used in
- * building addresses stored in the ifnet structure.
- */
-struct in_addr
-inet_makeaddr(net, host)
-	u_long net, host;
-{
-	struct in_addr a;
-
-	if (net < 128U)
-		a.s_addr = (net << IN_CLASSA_NSHIFT) | (host & IN_CLASSA_HOST);
-	else if (net < 65536U)
-		a.s_addr = (net << IN_CLASSB_NSHIFT) | (host & IN_CLASSB_HOST);
-	else if (net < 16777216L)
-		a.s_addr = (net << IN_CLASSC_NSHIFT) | (host & IN_CLASSC_HOST);
-	else
-		a.s_addr = net | host;
-	a.s_addr = htonl(a.s_addr);
-	return (a);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/inet/inet_net_ntop.c b/contrib/bind9/lib/bind/inet/inet_net_ntop.c
deleted file mode 100644
index a1ac243..0000000
--- a/contrib/bind9/lib/bind/inet/inet_net_ntop.c
+++ /dev/null
@@ -1,279 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: inet_net_ntop.c,v 1.3.18.2 2006/06/20 02:51:32 marka Exp $";
-#endif
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/socket.h>
-#include <netinet/in.h>
-#include <arpa/inet.h>
-
-#include <errno.h>
-#include <stdio.h>
-#include <string.h>
-#include <stdlib.h>
-
-#include "port_after.h"
-
-#ifdef SPRINTF_CHAR
-# define SPRINTF(x) strlen(sprintf/**/x)
-#else
-# define SPRINTF(x) ((size_t)sprintf x)
-#endif
-
-static char *	inet_net_ntop_ipv4 __P((const u_char *src, int bits,
-					char *dst, size_t size));
-static char *	inet_net_ntop_ipv6 __P((const u_char *src, int bits,
-					char *dst, size_t size));
-
-/*%
- * char *
- * inet_net_ntop(af, src, bits, dst, size)
- *	convert network number from network to presentation format.
- *	generates CIDR style result always.
- * return:
- *	pointer to dst, or NULL if an error occurred (check errno).
- * author:
- *	Paul Vixie (ISC), July 1996
- */
-char *
-inet_net_ntop(af, src, bits, dst, size)
-	int af;
-	const void *src;
-	int bits;
-	char *dst;
-	size_t size;
-{
-	switch (af) {
-	case AF_INET:
-		return (inet_net_ntop_ipv4(src, bits, dst, size));
-	case AF_INET6:
-		return (inet_net_ntop_ipv6(src, bits, dst, size));
-	default:
-		errno = EAFNOSUPPORT;
-		return (NULL);
-	}
-}
-
-/*%
- * static char *
- * inet_net_ntop_ipv4(src, bits, dst, size)
- *	convert IPv4 network number from network to presentation format.
- *	generates CIDR style result always.
- * return:
- *	pointer to dst, or NULL if an error occurred (check errno).
- * note:
- *	network byte order assumed.  this means 192.5.5.240/28 has
- *	0b11110000 in its fourth octet.
- * author:
- *	Paul Vixie (ISC), July 1996
- */
-static char *
-inet_net_ntop_ipv4(src, bits, dst, size)
-	const u_char *src;
-	int bits;
-	char *dst;
-	size_t size;
-{
-	char *odst = dst;
-	char *t;
-	u_int m;
-	int b;
-
-	if (bits < 0 || bits > 32) {
-		errno = EINVAL;
-		return (NULL);
-	}
-
-	if (bits == 0) {
-		if (size < sizeof "0")
-			goto emsgsize;
-		*dst++ = '0';
-		size--;
-		*dst = '\0';
-	}
-
-	/* Format whole octets. */
-	for (b = bits / 8; b > 0; b--) {
-		if (size <= sizeof "255.")
-			goto emsgsize;
-		t = dst;
-		dst += SPRINTF((dst, "%u", *src++));
-		if (b > 1) {
-			*dst++ = '.';
-			*dst = '\0';
-		}
-		size -= (size_t)(dst - t);
-	}
-
-	/* Format partial octet. */
-	b = bits % 8;
-	if (b > 0) {
-		if (size <= sizeof ".255")
-			goto emsgsize;
-		t = dst;
-		if (dst != odst)
-			*dst++ = '.';
-		m = ((1 << b) - 1) << (8 - b);
-		dst += SPRINTF((dst, "%u", *src & m));
-		size -= (size_t)(dst - t);
-	}
-
-	/* Format CIDR /width. */
-	if (size <= sizeof "/32")
-		goto emsgsize;
-	dst += SPRINTF((dst, "/%u", bits));
-	return (odst);
-
- emsgsize:
-	errno = EMSGSIZE;
-	return (NULL);
-}
-
-/*%
- * static char *
- * inet_net_ntop_ipv6(src, bits, fakebits, dst, size)
- *	convert IPv6 network number from network to presentation format.
- *	generates CIDR style result always. Picks the shortest representation
- *	unless the IP is really IPv4.
- *	always prints specified number of bits (bits).
- * return:
- *	pointer to dst, or NULL if an error occurred (check errno).
- * note:
- *	network byte order assumed.  this means 192.5.5.240/28 has
- *	0x11110000 in its fourth octet.
- * author:
- *	Vadim Kogan (UCB), June 2001
- *  Original version (IPv4) by Paul Vixie (ISC), July 1996
- */
-
-static char *
-inet_net_ntop_ipv6(const u_char *src, int bits, char *dst, size_t size) {
-	u_int	m;
-	int	b;
-	int	p;
-	int	zero_s, zero_l, tmp_zero_s, tmp_zero_l;
-	int	i;
-	int	is_ipv4 = 0;
-	unsigned char inbuf[16];
-	char outbuf[sizeof("xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:255.255.255.255/128")];
-	char	*cp;
-	int	words;
-	u_char	*s;
-
-	if (bits < 0 || bits > 128) {
-		errno = EINVAL;
-		return (NULL);
-	}
-
-	cp = outbuf;
-
-	if (bits == 0) {
-		*cp++ = ':';
-		*cp++ = ':';
-		*cp = '\0';
-	} else {
-		/* Copy src to private buffer.  Zero host part. */	
-		p = (bits + 7) / 8;
-		memcpy(inbuf, src, p);
-		memset(inbuf + p, 0, 16 - p);
-		b = bits % 8;
-		if (b != 0) {
-			m = ~0 << (8 - b);
-			inbuf[p-1] &= m;
-		}
-
-		s = inbuf;
-
-		/* how many words need to be displayed in output */
-		words = (bits + 15) / 16;
-		if (words == 1)
-			words = 2;
-		
-		/* Find the longest substring of zero's */
-		zero_s = zero_l = tmp_zero_s = tmp_zero_l = 0;
-		for (i = 0; i < (words * 2); i += 2) {
-			if ((s[i] | s[i+1]) == 0) {
-				if (tmp_zero_l == 0)
-					tmp_zero_s = i / 2;
-				tmp_zero_l++;
-			} else {
-				if (tmp_zero_l && zero_l < tmp_zero_l) {
-					zero_s = tmp_zero_s;
-					zero_l = tmp_zero_l;
-					tmp_zero_l = 0;
-				}
-			}
-		}
-
-		if (tmp_zero_l && zero_l < tmp_zero_l) {
-			zero_s = tmp_zero_s;
-			zero_l = tmp_zero_l;
-		}
-
-		if (zero_l != words && zero_s == 0 && ((zero_l == 6) ||
-		    ((zero_l == 5 && s[10] == 0xff && s[11] == 0xff) ||
-		    ((zero_l == 7 && s[14] != 0 && s[15] != 1)))))
-			is_ipv4 = 1;
-
-		/* Format whole words. */
-		for (p = 0; p < words; p++) {
-			if (zero_l != 0 && p >= zero_s && p < zero_s + zero_l) {
-				/* Time to skip some zeros */
-				if (p == zero_s)
-					*cp++ = ':';
-				if (p == words - 1)
-					*cp++ = ':';
-				s++;
-				s++;
-				continue;
-			}
-
-			if (is_ipv4 && p > 5 ) {
-				*cp++ = (p == 6) ? ':' : '.';
-				cp += SPRINTF((cp, "%u", *s++));
-				/* we can potentially drop the last octet */
-				if (p != 7 || bits > 120) {
-					*cp++ = '.';
-					cp += SPRINTF((cp, "%u", *s++));
-				}
-			} else {
-				if (cp != outbuf)
-					*cp++ = ':';
-				cp += SPRINTF((cp, "%x", *s * 256 + s[1]));
-				s += 2;
-			}
-		}
-	}
-	/* Format CIDR /width. */
-	sprintf(cp, "/%u", bits);
-	if (strlen(outbuf) + 1 > size)
-		goto emsgsize;
-	strcpy(dst, outbuf);
-	
-	return (dst);
-
-emsgsize:
-	errno = EMSGSIZE;
-	return (NULL);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/inet/inet_net_pton.c b/contrib/bind9/lib/bind/inet/inet_net_pton.c
deleted file mode 100644
index 71a8715..0000000
--- a/contrib/bind9/lib/bind/inet/inet_net_pton.c
+++ /dev/null
@@ -1,407 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: inet_net_pton.c,v 1.7.18.2 2008/08/26 04:42:43 marka Exp $";
-#endif
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/socket.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <arpa/inet.h>
-
-#include <isc/assertions.h>
-#include <ctype.h>
-#include <errno.h>
-#include <stdio.h>
-#include <string.h>
-#include <stdlib.h>
-
-#include "port_after.h"
-
-#ifdef SPRINTF_CHAR
-# define SPRINTF(x) strlen(sprintf/**/x)
-#else
-# define SPRINTF(x) ((size_t)sprintf x)
-#endif
-
-/*%
- * static int
- * inet_net_pton_ipv4(src, dst, size)
- *	convert IPv4 network number from presentation to network format.
- *	accepts hex octets, hex strings, decimal octets, and /CIDR.
- *	"size" is in bytes and describes "dst".
- * return:
- *	number of bits, either imputed classfully or specified with /CIDR,
- *	or -1 if some failure occurred (check errno).  ENOENT means it was
- *	not an IPv4 network specification.
- * note:
- *	network byte order assumed.  this means 192.5.5.240/28 has
- *	0b11110000 in its fourth octet.
- * author:
- *	Paul Vixie (ISC), June 1996
- */
-static int
-inet_net_pton_ipv4(const char *src, u_char *dst, size_t size) {
-	static const char xdigits[] = "0123456789abcdef";
-	static const char digits[] = "0123456789";
-	int n, ch, tmp = 0, dirty, bits;
-	const u_char *odst = dst;
-
-	ch = *src++;
-	if (ch == '0' && (src[0] == 'x' || src[0] == 'X')
-	    && isascii((unsigned char)(src[1]))
-	    && isxdigit((unsigned char)(src[1]))) {
-		/* Hexadecimal: Eat nybble string. */
-		if (size <= 0U)
-			goto emsgsize;
-		dirty = 0;
-		src++;	/*%< skip x or X. */
-		while ((ch = *src++) != '\0' && isascii(ch) && isxdigit(ch)) {
-			if (isupper(ch))
-				ch = tolower(ch);
-			n = strchr(xdigits, ch) - xdigits;
-			INSIST(n >= 0 && n <= 15);
-			if (dirty == 0)
-				tmp = n;
-			else
-				tmp = (tmp << 4) | n;
-			if (++dirty == 2) {
-				if (size-- <= 0U)
-					goto emsgsize;
-				*dst++ = (u_char) tmp;
-				dirty = 0;
-			}
-		}
-		if (dirty) {  /*%< Odd trailing nybble? */
-			if (size-- <= 0U)
-				goto emsgsize;
-			*dst++ = (u_char) (tmp << 4);
-		}
-	} else if (isascii(ch) && isdigit(ch)) {
-		/* Decimal: eat dotted digit string. */
-		for (;;) {
-			tmp = 0;
-			do {
-				n = strchr(digits, ch) - digits;
-				INSIST(n >= 0 && n <= 9);
-				tmp *= 10;
-				tmp += n;
-				if (tmp > 255)
-					goto enoent;
-			} while ((ch = *src++) != '\0' &&
-				 isascii(ch) && isdigit(ch));
-			if (size-- <= 0U)
-				goto emsgsize;
-			*dst++ = (u_char) tmp;
-			if (ch == '\0' || ch == '/')
-				break;
-			if (ch != '.')
-				goto enoent;
-			ch = *src++;
-			if (!isascii(ch) || !isdigit(ch))
-				goto enoent;
-		}
-	} else
-		goto enoent;
-
-	bits = -1;
-	if (ch == '/' && isascii((unsigned char)(src[0])) &&
-	    isdigit((unsigned char)(src[0])) && dst > odst) {
-		/* CIDR width specifier.  Nothing can follow it. */
-		ch = *src++;	/*%< Skip over the /. */
-		bits = 0;
-		do {
-			n = strchr(digits, ch) - digits;
-			INSIST(n >= 0 && n <= 9);
-			bits *= 10;
-			bits += n;
-			if (bits > 32)
-				goto enoent;
-		} while ((ch = *src++) != '\0' && isascii(ch) && isdigit(ch));
-		if (ch != '\0')
-			goto enoent;
-	}
-
-	/* Firey death and destruction unless we prefetched EOS. */
-	if (ch != '\0')
-		goto enoent;
-
-	/* If nothing was written to the destination, we found no address. */
-	if (dst == odst)
-		goto enoent;
-	/* If no CIDR spec was given, infer width from net class. */
-	if (bits == -1) {
-		if (*odst >= 240)	/*%< Class E */
-			bits = 32;
-		else if (*odst >= 224)	/*%< Class D */
-			bits = 8;
-		else if (*odst >= 192)	/*%< Class C */
-			bits = 24;
-		else if (*odst >= 128)	/*%< Class B */
-			bits = 16;
-		else			/*%< Class A */
-			bits = 8;
-		/* If imputed mask is narrower than specified octets, widen. */
-		if (bits < ((dst - odst) * 8))
-			bits = (dst - odst) * 8;
-		/*
-		 * If there are no additional bits specified for a class D
-		 * address adjust bits to 4.
-		 */
-		if (bits == 8 && *odst == 224)
-			bits = 4;
-	}
-	/* Extend network to cover the actual mask. */
-	while (bits > ((dst - odst) * 8)) {
-		if (size-- <= 0U)
-			goto emsgsize;
-		*dst++ = '\0';
-	}
-	return (bits);
-
- enoent:
-	errno = ENOENT;
-	return (-1);
-
- emsgsize:
-	errno = EMSGSIZE;
-	return (-1);
-}
-
-static int
-getbits(const char *src, int *bitsp) {
-	static const char digits[] = "0123456789";
-	int n;
-	int val;
-	char ch;
-
-	val = 0;
-	n = 0;
-	while ((ch = *src++) != '\0') {
-		const char *pch;
-
-		pch = strchr(digits, ch);
-		if (pch != NULL) {
-			if (n++ != 0 && val == 0)	/*%< no leading zeros */
-				return (0);
-			val *= 10;
-			val += (pch - digits);
-			if (val > 128)			/*%< range */
-				return (0);
-			continue;
-		}
-		return (0);
-	}
-	if (n == 0)
-		return (0);
-	*bitsp = val;
-	return (1);
-}
-
-static int
-getv4(const char *src, u_char *dst, int *bitsp) {
-	static const char digits[] = "0123456789";
-	u_char *odst = dst;
-	int n;
-	u_int val;
-	char ch;
-
-	val = 0;
-	n = 0;
-	while ((ch = *src++) != '\0') {
-		const char *pch;
-
-		pch = strchr(digits, ch);
-		if (pch != NULL) {
-			if (n++ != 0 && val == 0)	/*%< no leading zeros */
-				return (0);
-			val *= 10;
-			val += (pch - digits);
-			if (val > 255)			/*%< range */
-				return (0);
-			continue;
-		}
-		if (ch == '.' || ch == '/') {
-			if (dst - odst > 3)		/*%< too many octets? */
-				return (0);
-			*dst++ = val;
-			if (ch == '/')
-				return (getbits(src, bitsp));
-			val = 0;
-			n = 0;
-			continue;
-		}
-		return (0);
-	}
-	if (n == 0)
-		return (0);
-	if (dst - odst > 3)		/*%< too many octets? */
-		return (0);
-	*dst++ = val;
-	return (1);
-}
-
-static int
-inet_net_pton_ipv6(const char *src, u_char *dst, size_t size) {
-	static const char xdigits_l[] = "0123456789abcdef",
-			  xdigits_u[] = "0123456789ABCDEF";
-	u_char tmp[NS_IN6ADDRSZ], *tp, *endp, *colonp;
-	const char *xdigits, *curtok;
-	int ch, saw_xdigit;
-	u_int val;
-	int digits;
-	int bits;
-	size_t bytes;
-	int words;
-	int ipv4;
-
-	memset((tp = tmp), '\0', NS_IN6ADDRSZ);
-	endp = tp + NS_IN6ADDRSZ;
-	colonp = NULL;
-	/* Leading :: requires some special handling. */
-	if (*src == ':')
-		if (*++src != ':')
-			goto enoent;
-	curtok = src;
-	saw_xdigit = 0;
-	val = 0;
-	digits = 0;
-	bits = -1;
-	ipv4 = 0;
-	while ((ch = *src++) != '\0') {
-		const char *pch;
-
-		if ((pch = strchr((xdigits = xdigits_l), ch)) == NULL)
-			pch = strchr((xdigits = xdigits_u), ch);
-		if (pch != NULL) {
-			val <<= 4;
-			val |= (pch - xdigits);
-			if (++digits > 4)
-				goto enoent;
-			saw_xdigit = 1;
-			continue;
-		}
-		if (ch == ':') {
-			curtok = src;
-			if (!saw_xdigit) {
-				if (colonp)
-					goto enoent;
-				colonp = tp;
-				continue;
-			} else if (*src == '\0')
-				goto enoent;
-			if (tp + NS_INT16SZ > endp)
-				return (0);
-			*tp++ = (u_char) (val >> 8) & 0xff;
-			*tp++ = (u_char) val & 0xff;
-			saw_xdigit = 0;
-			digits = 0;
-			val = 0;
-			continue;
-		}
-		if (ch == '.' && ((tp + NS_INADDRSZ) <= endp) &&
-		     getv4(curtok, tp, &bits) > 0) {
-			tp += NS_INADDRSZ;
-			saw_xdigit = 0;
-			ipv4 = 1;
-			break;	/*%< '\\0' was seen by inet_pton4(). */
-		}
-		if (ch == '/' && getbits(src, &bits) > 0)
-			break;
-		goto enoent;
-	}
-	if (saw_xdigit) {
-		if (tp + NS_INT16SZ > endp)
-			goto enoent;
-		*tp++ = (u_char) (val >> 8) & 0xff;
-		*tp++ = (u_char) val & 0xff;
-	}
-	if (bits == -1)
-		bits = 128;
-
-	words = (bits + 15) / 16;
-	if (words < 2)
-		words = 2;
-	if (ipv4)
-		words = 8;
-	endp =  tmp + 2 * words;
-
-	if (colonp != NULL) {
-		/*
-		 * Since some memmove()'s erroneously fail to handle
-		 * overlapping regions, we'll do the shift by hand.
-		 */
-		const int n = tp - colonp;
-		int i;
-
-		if (tp == endp)
-			goto enoent;
-		for (i = 1; i <= n; i++) {
-			endp[- i] = colonp[n - i];
-			colonp[n - i] = 0;
-		}
-		tp = endp;
-	}
-	if (tp != endp)
-		goto enoent;
-
-	bytes = (bits + 7) / 8;
-	if (bytes > size)
-		goto emsgsize;
-	memcpy(dst, tmp, bytes);
-	return (bits);
-
- enoent:
-	errno = ENOENT;
-	return (-1);
-
- emsgsize:
-	errno = EMSGSIZE;
-	return (-1);
-}
-
-/*%
- * int
- * inet_net_pton(af, src, dst, size)
- *	convert network number from presentation to network format.
- *	accepts hex octets, hex strings, decimal octets, and /CIDR.
- *	"size" is in bytes and describes "dst".
- * return:
- *	number of bits, either imputed classfully or specified with /CIDR,
- *	or -1 if some failure occurred (check errno).  ENOENT means it was
- *	not a valid network specification.
- * author:
- *	Paul Vixie (ISC), June 1996
- */
-int
-inet_net_pton(int af, const char *src, void *dst, size_t size) {
-	switch (af) {
-	case AF_INET:
-		return (inet_net_pton_ipv4(src, dst, size));
-	case AF_INET6:
-		return (inet_net_pton_ipv6(src, dst, size));
-	default:
-		errno = EAFNOSUPPORT;
-		return (-1);
-	}
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/inet/inet_neta.c b/contrib/bind9/lib/bind/inet/inet_neta.c
deleted file mode 100644
index bc3b601..0000000
--- a/contrib/bind9/lib/bind/inet/inet_neta.c
+++ /dev/null
@@ -1,89 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: inet_neta.c,v 1.2.18.1 2005/04/27 05:00:53 sra Exp $";
-#endif
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/socket.h>
-#include <netinet/in.h>
-#include <arpa/inet.h>
-
-#include <errno.h>
-#include <stdio.h>
-#include <string.h>
-
-#include "port_after.h"
-
-#ifdef SPRINTF_CHAR
-# define SPRINTF(x) strlen(sprintf/**/x)
-#else
-# define SPRINTF(x) ((size_t)sprintf x)
-#endif
-
-/*%
- * char *
- * inet_neta(src, dst, size)
- *	format a u_long network number into presentation format.
- * return:
- *	pointer to dst, or NULL if an error occurred (check errno).
- * note:
- *	format of ``src'' is as for inet_network().
- * author:
- *	Paul Vixie (ISC), July 1996
- */
-char *
-inet_neta(src, dst, size)
-	u_long src;
-	char *dst;
-	size_t size;
-{
-	char *odst = dst;
-	char *tp;
-
-	while (src & 0xffffffff) {
-		u_char b = (src & 0xff000000) >> 24;
-
-		src <<= 8;
-		if (b) {
-			if (size < sizeof "255.")
-				goto emsgsize;
-			tp = dst;
-			dst += SPRINTF((dst, "%u", b));
-			if (src != 0L) {
-				*dst++ = '.';
-				*dst = '\0';
-			}
-			size -= (size_t)(dst - tp);
-		}
-	}
-	if (dst == odst) {
-		if (size < sizeof "0.0.0.0")
-			goto emsgsize;
-		strcpy(dst, "0.0.0.0");
-	}
-	return (odst);
-
- emsgsize:
-	errno = EMSGSIZE;
-	return (NULL);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/inet/inet_netof.c b/contrib/bind9/lib/bind/inet/inet_netof.c
deleted file mode 100644
index c228e3d..0000000
--- a/contrib/bind9/lib/bind/inet/inet_netof.c
+++ /dev/null
@@ -1,64 +0,0 @@
-/*
- * Copyright (c) 1983, 1993
- *	The Regents of the University of California.  All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- *	This product includes software developed by the University of
- *	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char sccsid[] = "@(#)inet_netof.c	8.1 (Berkeley) 6/4/93";
-#endif /* LIBC_SCCS and not lint */
-
-#include "port_before.h"
-
-#include <sys/param.h>
-#include <netinet/in.h>
-#include <arpa/inet.h>
-
-#include "port_after.h"
-
-/*%
- * Return the network number from an internet
- * address; handles class a/b/c network #'s.
- */
-u_long
-inet_netof(in)
-	struct in_addr in;
-{
-	register u_long i = ntohl(in.s_addr);
-
-	if (IN_CLASSA(i))
-		return (((i)&IN_CLASSA_NET) >> IN_CLASSA_NSHIFT);
-	else if (IN_CLASSB(i))
-		return (((i)&IN_CLASSB_NET) >> IN_CLASSB_NSHIFT);
-	else
-		return (((i)&IN_CLASSC_NET) >> IN_CLASSC_NSHIFT);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/inet/inet_network.c b/contrib/bind9/lib/bind/inet/inet_network.c
deleted file mode 100644
index 47976cf..0000000
--- a/contrib/bind9/lib/bind/inet/inet_network.c
+++ /dev/null
@@ -1,106 +0,0 @@
-/*
- * Copyright (c) 1983, 1993
- *	The Regents of the University of California.  All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- *	This product includes software developed by the University of
- *	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char sccsid[] = "@(#)inet_network.c	8.1 (Berkeley) 6/4/93";
-#endif /* LIBC_SCCS and not lint */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <arpa/inet.h>
-#include <ctype.h>
-
-#include "port_after.h"
-
-/*%
- * Internet network address interpretation routine.
- * The library routines call this routine to interpret
- * network numbers.
- */
-u_long
-inet_network(cp)
-	register const char *cp;
-{
-	register u_long val, base, n, i;
-	register char c;
-	u_long parts[4], *pp = parts;
-	int digit;
-
-again:
-	val = 0; base = 10; digit = 0;
-	if (*cp == '0')
-		digit = 1, base = 8, cp++;
-	if (*cp == 'x' || *cp == 'X')
-		base = 16, cp++;
-	while ((c = *cp) != 0) {
-		if (isdigit((unsigned char)c)) {
-			if (base == 8U && (c == '8' || c == '9'))
-				return (INADDR_NONE);
-			val = (val * base) + (c - '0');
-			cp++;
-			digit = 1;
-			continue;
-		}
-		if (base == 16U && isxdigit((unsigned char)c)) {
-			val = (val << 4) +
-			      (c + 10 - (islower((unsigned char)c) ? 'a' : 'A'));
-			cp++;
-			digit = 1;
-			continue;
-		}
-		break;
-	}
-	if (!digit)
-		return (INADDR_NONE);
-	if (pp >= parts + 4 || val > 0xffU)
-		return (INADDR_NONE);
-	if (*cp == '.') {
-		*pp++ = val, cp++;
-		goto again;
-	}
-	if (*cp && !isspace(*cp&0xff))
-		return (INADDR_NONE);
-	*pp++ = val;
-	n = pp - parts;
-	if (n > 4U)
-		return (INADDR_NONE);
-	for (val = 0, i = 0; i < n; i++) {
-		val <<= 8;
-		val |= parts[i] & 0xff;
-	}
-	return (val);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/inet/inet_ntoa.c b/contrib/bind9/lib/bind/inet/inet_ntoa.c
deleted file mode 100644
index 1d566be..0000000
--- a/contrib/bind9/lib/bind/inet/inet_ntoa.c
+++ /dev/null
@@ -1,64 +0,0 @@
-/*
- * Copyright (c) 1983, 1993
- *	The Regents of the University of California.  All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- *	This product includes software developed by the University of
- *	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char sccsid[] = "@(#)inet_ntoa.c	8.1 (Berkeley) 6/4/93";
-static const char rcsid[] = "$Id: inet_ntoa.c,v 1.1.352.1 2005/04/27 05:00:54 sra Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/socket.h>
-#include <netinet/in.h>
-#include <arpa/inet.h>
-
-#include <stdio.h>
-#include <string.h>
-
-#include "port_after.h"
-
-/*%
- * Convert network-format internet address
- * to base 256 d.d.d.d representation.
- */
-/*const*/ char *
-inet_ntoa(struct in_addr in) {
-	static char ret[18];
-
-	strcpy(ret, "[inet_ntoa error]");
-	(void) inet_ntop(AF_INET, &in, ret, sizeof ret);
-	return (ret);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/inet/inet_ntop.c b/contrib/bind9/lib/bind/inet/inet_ntop.c
deleted file mode 100644
index 9ab38bc..0000000
--- a/contrib/bind9/lib/bind/inet/inet_ntop.c
+++ /dev/null
@@ -1,207 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996-1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: inet_ntop.c,v 1.3.18.2 2005/11/03 23:02:22 marka Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-#include "port_before.h"
-
-#include <sys/param.h>
-#include <sys/types.h>
-#include <sys/socket.h>
-
-#include <netinet/in.h>
-#include <arpa/inet.h>
-#include <arpa/nameser.h>
-
-#include <errno.h>
-#include <stdio.h>
-#include <string.h>
-
-#include "port_after.h"
-
-#ifdef SPRINTF_CHAR
-# define SPRINTF(x) strlen(sprintf/**/x)
-#else
-# define SPRINTF(x) ((size_t)sprintf x)
-#endif
-
-/*%
- * WARNING: Don't even consider trying to compile this on a system where
- * sizeof(int) < 4.  sizeof(int) > 4 is fine; all the world's not a VAX.
- */
-
-static const char *inet_ntop4 __P((const u_char *src, char *dst, size_t size));
-static const char *inet_ntop6 __P((const u_char *src, char *dst, size_t size));
-
-/* char *
- * inet_ntop(af, src, dst, size)
- *	convert a network format address to presentation format.
- * return:
- *	pointer to presentation format address (`dst'), or NULL (see errno).
- * author:
- *	Paul Vixie, 1996.
- */
-const char *
-inet_ntop(af, src, dst, size)
-	int af;
-	const void *src;
-	char *dst;
-	size_t size;
-{
-	switch (af) {
-	case AF_INET:
-		return (inet_ntop4(src, dst, size));
-	case AF_INET6:
-		return (inet_ntop6(src, dst, size));
-	default:
-		errno = EAFNOSUPPORT;
-		return (NULL);
-	}
-	/* NOTREACHED */
-}
-
-/* const char *
- * inet_ntop4(src, dst, size)
- *	format an IPv4 address
- * return:
- *	`dst' (as a const)
- * notes:
- *	(1) uses no statics
- *	(2) takes a u_char* not an in_addr as input
- * author:
- *	Paul Vixie, 1996.
- */
-static const char *
-inet_ntop4(src, dst, size)
-	const u_char *src;
-	char *dst;
-	size_t size;
-{
-	static const char fmt[] = "%u.%u.%u.%u";
-	char tmp[sizeof "255.255.255.255"];
-
-	if (SPRINTF((tmp, fmt, src[0], src[1], src[2], src[3])) >= size) {
-		errno = ENOSPC;
-		return (NULL);
-	}
-	strcpy(dst, tmp);
-	return (dst);
-}
-
-/* const char *
- * inet_ntop6(src, dst, size)
- *	convert IPv6 binary address into presentation (printable) format
- * author:
- *	Paul Vixie, 1996.
- */
-static const char *
-inet_ntop6(src, dst, size)
-	const u_char *src;
-	char *dst;
-	size_t size;
-{
-	/*
-	 * Note that int32_t and int16_t need only be "at least" large enough
-	 * to contain a value of the specified size.  On some systems, like
-	 * Crays, there is no such thing as an integer variable with 16 bits.
-	 * Keep this in mind if you think this function should have been coded
-	 * to use pointer overlays.  All the world's not a VAX.
-	 */
-	char tmp[sizeof "ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255"], *tp;
-	struct { int base, len; } best, cur;
-	u_int words[NS_IN6ADDRSZ / NS_INT16SZ];
-	int i;
-
-	/*
-	 * Preprocess:
-	 *	Copy the input (bytewise) array into a wordwise array.
-	 *	Find the longest run of 0x00's in src[] for :: shorthanding.
-	 */
-	memset(words, '\0', sizeof words);
-	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)
-				cur.base = i, cur.len = 1;
-			else
-				cur.len++;
-		} else {
-			if (cur.base != -1) {
-				if (best.base == -1 || cur.len > best.len)
-					best = cur;
-				cur.base = -1;
-			}
-		}
-	}
-	if (cur.base != -1) {
-		if (best.base == -1 || cur.len > best.len)
-			best = cur;
-	}
-	if (best.base != -1 && best.len < 2)
-		best.base = -1;
-
-	/*
-	 * Format the result.
-	 */
-	tp = tmp;
-	for (i = 0; i < (NS_IN6ADDRSZ / NS_INT16SZ); i++) {
-		/* Are we inside the best run of 0x00's? */
-		if (best.base != -1 && i >= best.base &&
-		    i < (best.base + best.len)) {
-			if (i == best.base)
-				*tp++ = ':';
-			continue;
-		}
-		/* Are we following an initial run of 0x00s or any real hex? */
-		if (i != 0)
-			*tp++ = ':';
-		/* Is this address an encapsulated IPv4? */
-		if (i == 6 && best.base == 0 && (best.len == 6 ||
-		    (best.len == 7 && words[7] != 0x0001) ||
-		    (best.len == 5 && words[5] == 0xffff))) {
-			if (!inet_ntop4(src+12, tp, sizeof tmp - (tp - tmp)))
-				return (NULL);
-			tp += strlen(tp);
-			break;
-		}
-		tp += SPRINTF((tp, "%x", words[i]));
-	}
-	/* Was it a trailing run of 0x00's? */
-	if (best.base != -1 && (best.base + best.len) == 
-	    (NS_IN6ADDRSZ / NS_INT16SZ))
-		*tp++ = ':';
-	*tp++ = '\0';
-
-	/*
-	 * Check for overflow, copy, and we're done.
-	 */
-	if ((size_t)(tp - tmp) > size) {
-		errno = ENOSPC;
-		return (NULL);
-	}
-	strcpy(dst, tmp);
-	return (dst);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/inet/inet_pton.c b/contrib/bind9/lib/bind/inet/inet_pton.c
deleted file mode 100644
index 66b4c6a..0000000
--- a/contrib/bind9/lib/bind/inet/inet_pton.c
+++ /dev/null
@@ -1,223 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: inet_pton.c,v 1.3.18.2 2005/07/28 07:38:07 marka Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-#include "port_before.h"
-#include <sys/param.h>
-#include <sys/types.h>
-#include <sys/socket.h>
-#include <netinet/in.h>
-#include <arpa/inet.h>
-#include <arpa/nameser.h>
-#include <string.h>
-#include <errno.h>
-#include "port_after.h"
-
-/*%
- * WARNING: Don't even consider trying to compile this on a system where
- * sizeof(int) < 4.  sizeof(int) > 4 is fine; all the world's not a VAX.
- */
-
-static int	inet_pton4 __P((const char *src, u_char *dst));
-static int	inet_pton6 __P((const char *src, u_char *dst));
-
-/* int
- * inet_pton(af, src, dst)
- *	convert from presentation format (which usually means ASCII printable)
- *	to network format (which is usually some kind of binary format).
- * return:
- *	1 if the address was valid for the specified address family
- *	0 if the address wasn't valid (`dst' is untouched in this case)
- *	-1 if some other error occurred (`dst' is untouched in this case, too)
- * author:
- *	Paul Vixie, 1996.
- */
-int
-inet_pton(af, src, dst)
-	int af;
-	const char *src;
-	void *dst;
-{
-	switch (af) {
-	case AF_INET:
-		return (inet_pton4(src, dst));
-	case AF_INET6:
-		return (inet_pton6(src, dst));
-	default:
-		errno = EAFNOSUPPORT;
-		return (-1);
-	}
-	/* NOTREACHED */
-}
-
-/* int
- * inet_pton4(src, dst)
- *	like inet_aton() but without all the hexadecimal and shorthand.
- * return:
- *	1 if `src' is a valid dotted quad, else 0.
- * notice:
- *	does not touch `dst' unless it's returning 1.
- * author:
- *	Paul Vixie, 1996.
- */
-static int
-inet_pton4(src, dst)
-	const char *src;
-	u_char *dst;
-{
-	static const char digits[] = "0123456789";
-	int saw_digit, octets, ch;
-	u_char tmp[NS_INADDRSZ], *tp;
-
-	saw_digit = 0;
-	octets = 0;
-	*(tp = tmp) = 0;
-	while ((ch = *src++) != '\0') {
-		const char *pch;
-
-		if ((pch = strchr(digits, ch)) != NULL) {
-			u_int new = *tp * 10 + (pch - digits);
-
-			if (saw_digit && *tp == 0)
-				return (0);
-			if (new > 255)
-				return (0);
-			*tp = new;
-			if (!saw_digit) {
-				if (++octets > 4)
-					return (0);
-				saw_digit = 1;
-			}
-		} else if (ch == '.' && saw_digit) {
-			if (octets == 4)
-				return (0);
-			*++tp = 0;
-			saw_digit = 0;
-		} else
-			return (0);
-	}
-	if (octets < 4)
-		return (0);
-	memcpy(dst, tmp, NS_INADDRSZ);
-	return (1);
-}
-
-/* int
- * inet_pton6(src, dst)
- *	convert presentation level address to network order binary form.
- * return:
- *	1 if `src' is a valid [RFC1884 2.2] address, else 0.
- * notice:
- *	(1) does not touch `dst' unless it's returning 1.
- *	(2) :: in a full address is silently ignored.
- * credit:
- *	inspired by Mark Andrews.
- * author:
- *	Paul Vixie, 1996.
- */
-static int
-inet_pton6(src, dst)
-	const char *src;
-	u_char *dst;
-{
-	static const char xdigits_l[] = "0123456789abcdef",
-			  xdigits_u[] = "0123456789ABCDEF";
-	u_char tmp[NS_IN6ADDRSZ], *tp, *endp, *colonp;
-	const char *xdigits, *curtok;
-	int ch, seen_xdigits;
-	u_int val;
-
-	memset((tp = tmp), '\0', NS_IN6ADDRSZ);
-	endp = tp + NS_IN6ADDRSZ;
-	colonp = NULL;
-	/* Leading :: requires some special handling. */
-	if (*src == ':')
-		if (*++src != ':')
-			return (0);
-	curtok = src;
-	seen_xdigits = 0;
-	val = 0;
-	while ((ch = *src++) != '\0') {
-		const char *pch;
-
-		if ((pch = strchr((xdigits = xdigits_l), ch)) == NULL)
-			pch = strchr((xdigits = xdigits_u), ch);
-		if (pch != NULL) {
-			val <<= 4;
-			val |= (pch - xdigits);
-			if (++seen_xdigits > 4)
-				return (0);
-			continue;
-		}
-		if (ch == ':') {
-			curtok = src;
-			if (!seen_xdigits) {
-				if (colonp)
-					return (0);
-				colonp = tp;
-				continue;
-			} else if (*src == '\0') {
-				return (0);
-			}
-			if (tp + NS_INT16SZ > endp)
-				return (0);
-			*tp++ = (u_char) (val >> 8) & 0xff;
-			*tp++ = (u_char) val & 0xff;
-			seen_xdigits = 0;
-			val = 0;
-			continue;
-		}
-		if (ch == '.' && ((tp + NS_INADDRSZ) <= endp) &&
-		    inet_pton4(curtok, tp) > 0) {
-			tp += NS_INADDRSZ;
-			seen_xdigits = 0;
-			break;	/*%< '\\0' was seen by inet_pton4(). */
-		}
-		return (0);
-	}
-	if (seen_xdigits) {
-		if (tp + NS_INT16SZ > endp)
-			return (0);
-		*tp++ = (u_char) (val >> 8) & 0xff;
-		*tp++ = (u_char) val & 0xff;
-	}
-	if (colonp != NULL) {
-		/*
-		 * Since some memmove()'s erroneously fail to handle
-		 * overlapping regions, we'll do the shift by hand.
-		 */
-		const int n = tp - colonp;
-		int i;
-
-		if (tp == endp)
-			return (0);
-		for (i = 1; i <= n; i++) {
-			endp[- i] = colonp[n - i];
-			colonp[n - i] = 0;
-		}
-		tp = endp;
-	}
-	if (tp != endp)
-		return (0);
-	memcpy(dst, tmp, NS_IN6ADDRSZ);
-	return (1);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/inet/nsap_addr.c b/contrib/bind9/lib/bind/inet/nsap_addr.c
deleted file mode 100644
index d8fe87c..0000000
--- a/contrib/bind9/lib/bind/inet/nsap_addr.c
+++ /dev/null
@@ -1,111 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996-1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: nsap_addr.c,v 1.3.18.2 2005/07/28 07:38:08 marka Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/param.h>
-#include <sys/socket.h>
-
-#include <netinet/in.h>
-#include <arpa/inet.h>
-#include <arpa/nameser.h>
-
-#include <ctype.h>
-#include <resolv.h>
-#include <resolv_mt.h>
-
-#include "port_after.h"
-
-static char
-xtob(int c) {
-	return (c - (((c >= '0') && (c <= '9')) ? '0' : '7'));
-}
-
-u_int
-inet_nsap_addr(const char *ascii, u_char *binary, int maxlen) {
-	u_char c, nib;
-	u_int len = 0;
-
-	if (ascii[0] != '0' || (ascii[1] != 'x' && ascii[1] != 'X'))
-		return (0);
-	ascii += 2;
-
-	while ((c = *ascii++) != '\0' && len < (u_int)maxlen) {
-		if (c == '.' || c == '+' || c == '/')
-			continue;
-		if (!isascii(c))
-			return (0);
-		if (islower(c))
-			c = toupper(c);
-		if (isxdigit(c)) {
-			nib = xtob(c);
-			c = *ascii++;
-			if (c != '\0') {
-				c = toupper(c);
-				if (isxdigit(c)) {
-					*binary++ = (nib << 4) | xtob(c);
-					len++;
-				} else
-					return (0);
-			}
-			else
-				return (0);
-		}
-		else
-			return (0);
-	}
-	return (len);
-}
-
-char *
-inet_nsap_ntoa(int binlen, const u_char *binary, char *ascii) {
-	int nib;
-	int i;
-	char *tmpbuf = inet_nsap_ntoa_tmpbuf;
-	char *start;
-
-	if (ascii)
-		start = ascii;
-	else {
-		ascii = tmpbuf;
-		start = tmpbuf;
-	}
-
-	*ascii++ = '0';
-	*ascii++ = 'x';
-
-	if (binlen > 255)
-		binlen = 255;
-
-	for (i = 0; i < binlen; i++) {
-		nib = *binary >> 4;
-		*ascii++ = nib + (nib < 10 ? '0' : '7');
-		nib = *binary++ & 0x0f;
-		*ascii++ = nib + (nib < 10 ? '0' : '7');
-		if (((i % 2) == 0 && (i + 1) < binlen))
-			*ascii++ = '.';
-	}
-	*ascii = '\0';
-	return (start);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/Makefile.in b/contrib/bind9/lib/bind/irs/Makefile.in
deleted file mode 100644
index e4f38f7..0000000
--- a/contrib/bind9/lib/bind/irs/Makefile.in
+++ /dev/null
@@ -1,70 +0,0 @@
-# Copyright (C) 2004, 2008  Internet Systems Consortium, Inc. ("ISC")
-# Copyright (C) 2001  Internet Software Consortium.
-#
-# Permission to use, copy, modify, and/or 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: Makefile.in,v 1.8.18.4 2008/03/20 23:46:01 tbox Exp $
-
-srcdir=		@srcdir@
-VPATH =         @srcdir@
-
-WANT_IRS_THREADS_OBJS=	gethostent_r.@O@ getnetent_r.@O@ getnetgrent_r.@O@ \
-	getprotoent_r.@O@ getservent_r.@O@
-
-WANT_IRS_NISGR_OBJS= nis_gr.@O@ 
-WANT_IRS_GR_OBJS= dns_gr.@O@ irp_gr.@O@ lcl_gr.@O@ gen_gr.@O@ getgrent.@O@ \
-	@WANT_IRS_NISGR_OBJS@ @WANT_IRS_THREADSGR_OBJS@
-
-WANT_IRS_THREADSPW_OBJS=getpwent_r.@O@
-WANT_IRS_NISPW_OBJS= nis_pw.@O@
-WANT_IRS_DBPW_OBJS=irp_pw.@O@ lcl_pw.@O@
-WANT_IRS_PW_OBJS= dns_pw.@O@ gen_pw.@O@ getpwent.@O@ \
-	@WANT_IRS_DBPW_OBJS@ @WANT_IRS_NISPW_OBJS@ @WANT_IRS_THREADSPW_OBJS@
-
-WANT_IRS_NIS_OBJS= \
-	nis_ho.@O@ nis_ng.@O@ nis_nw.@O@ nis_pr.@O@ nis_sv.@O@
-
-OBJS=	@WANT_IRS_GR_OBJS@ @WANT_IRS_NIS_OBJS@ @WANT_IRS_THREADS_OBJS@ \
-	@WANT_IRS_PW_OBJS@ \
-	dns.@O@ dns_ho.@O@ dns_nw.@O@ dns_pr.@O@ \
-	dns_sv.@O@ gai_strerror.@O@ gen.@O@ gen_ho.@O@ \
-	gen_ng.@O@ gen_nw.@O@ gen_pr.@O@ gen_sv.@O@ \
-	getaddrinfo.@O@ gethostent.@O@ \
-	getnameinfo.@O@ getnetent.@O@ \
-	getnetgrent.@O@ getprotoent.@O@ getservent.@O@ \
-	hesiod.@O@ irp.@O@ irp_ho.@O@ irp_ng.@O@ irp_nw.@O@ \
-	irp_pr.@O@ irp_sv.@O@ irpmarshall.@O@ irs_data.@O@ \
-	lcl.@O@ lcl_ho.@O@ lcl_ng.@O@ lcl_nw.@O@ lcl_pr.@O@ \
-	lcl_sv.@O@ nis.@O@ nul_ng.@O@ util.@O@
-
-SRCS=	dns.c dns_gr.c dns_ho.c dns_nw.c dns_pr.c dns_pw.c \
-	dns_sv.c gai_strerror.c gen.c gen_gr.c gen_ho.c \
-	gen_ng.c gen_nw.c gen_pr.c gen_pw.c gen_sv.c \
-	getaddrinfo.c getgrent.c gethostent.c \
-	getnameinfo.c getnetent.c getnetent_r.c \
-	getnetgrent.c getprotoent.c getpwent.c getservent.c \
-	hesiod.c irp.c irp_gr.c irp_ho.c irp_ng.c irp_nw.c \
-	irp_pr.c irp_pw.c irp_sv.c irpmarshall.c irs_data.c \
-	lcl.c lcl_gr.c lcl_ho.c lcl_ng.c lcl_nw.c lcl_pr.c \
-	lcl_pw.c lcl_sv.c nis.c nis_gr.c nis_ho.c nis_ng.c \
-	nis_nw.c nis_pr.c nis_pw.c nis_sv.c nul_ng.c \
-	util.c getgrent_r.c gethostent_r.c getnetgrent_r.c getprotoent_r.c \
-	getpwent_r.c getservent_r.c
-
-WANT_IRS_THREADSGR_OBJS=getgrent_r.@O@
-
-TARGETS= ${OBJS}
-
-CINCLUDES= -I.. -I../include -I${srcdir}/../include
-
-@BIND9_MAKE_RULES@
diff --git a/contrib/bind9/lib/bind/irs/dns.c b/contrib/bind9/lib/bind/irs/dns.c
deleted file mode 100644
index b78a1d6..0000000
--- a/contrib/bind9/lib/bind/irs/dns.c
+++ /dev/null
@@ -1,154 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996-1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: dns.c,v 1.3.18.2 2006/03/10 00:20:08 marka Exp $";
-#endif
-
-/*! \file
- * \brief
- * dns.c --- this is the top-level accessor function for the dns
- */
-
-#include "port_before.h"
-
-#include <stdlib.h>
-#include <string.h>
-#include <errno.h>
-
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <resolv.h>
-
-#include <resolv.h>
-
-#include <isc/memcluster.h>
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "hesiod.h"
-#include "dns_p.h"
-
-/* forward */
-
-static void		dns_close(struct irs_acc *);
-static struct __res_state *	dns_res_get(struct irs_acc *);
-static void		dns_res_set(struct irs_acc *, struct __res_state *,
-				void (*)(void *));
-
-/* public */
-
-struct irs_acc *
-irs_dns_acc(const char *options) {
-	struct irs_acc *acc;
-	struct dns_p *dns;
-
-	UNUSED(options);
-
-	if (!(acc = memget(sizeof *acc))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(acc, 0x5e, sizeof *acc);
-	if (!(dns = memget(sizeof *dns))) {
-		errno = ENOMEM;
-		memput(acc, sizeof *acc);
-		return (NULL);
-	}
-	memset(dns, 0x5e, sizeof *dns);
-	dns->res = NULL;
-	dns->free_res = NULL;
-	if (hesiod_init(&dns->hes_ctx) < 0) {
-		/*
-		 * We allow the dns accessor class to initialize
-		 * despite hesiod failing to initialize correctly,
-		 * since dns host queries don't depend on hesiod.
-		 */
-		dns->hes_ctx = NULL;
-	}
-	acc->private = dns;
-#ifdef WANT_IRS_GR
-	acc->gr_map = irs_dns_gr;
-#else
-	acc->gr_map = NULL;
-#endif
-#ifdef WANT_IRS_PW
-	acc->pw_map = irs_dns_pw;
-#else
-	acc->pw_map = NULL;
-#endif
-	acc->sv_map = irs_dns_sv;
-	acc->pr_map = irs_dns_pr;
-	acc->ho_map = irs_dns_ho;
-	acc->nw_map = irs_dns_nw;
-	acc->ng_map = irs_nul_ng;
-	acc->res_get = dns_res_get;
-	acc->res_set = dns_res_set;
-	acc->close = dns_close;
-	return (acc);
-}
-
-/* methods */
-static struct __res_state *
-dns_res_get(struct irs_acc *this) {
-	struct dns_p *dns = (struct dns_p *)this->private;
-
-	if (dns->res == NULL) {
-		struct __res_state *res;
-		res = (struct __res_state *)malloc(sizeof *res);
-		if (res == NULL)
-			return (NULL);
-		memset(res, 0, sizeof *res);
-		dns_res_set(this, res, free);
-	}
-
-	if ((dns->res->options & RES_INIT) == 0U &&
-	    res_ninit(dns->res) < 0)
-		return (NULL);
-
-	return (dns->res);
-}
-
-static void
-dns_res_set(struct irs_acc *this, struct __res_state *res,
-	    void (*free_res)(void *)) {
-	struct dns_p *dns = (struct dns_p *)this->private;
-
-	if (dns->res && dns->free_res) {
-		res_nclose(dns->res);
-		(*dns->free_res)(dns->res);
-	}
-	dns->res = res;
-	dns->free_res = free_res;
-}
-
-static void
-dns_close(struct irs_acc *this) {
-	struct dns_p *dns;
-
-	dns = (struct dns_p *)this->private;
-	if (dns->res && dns->free_res)
-		(*dns->free_res)(dns->res);
-	if (dns->hes_ctx)
-		hesiod_end(dns->hes_ctx);
-	memput(dns, sizeof *dns);
-	memput(this, sizeof *this);
-}
-
diff --git a/contrib/bind9/lib/bind/irs/dns_gr.c b/contrib/bind9/lib/bind/irs/dns_gr.c
deleted file mode 100644
index 358e5a7..0000000
--- a/contrib/bind9/lib/bind/irs/dns_gr.c
+++ /dev/null
@@ -1,294 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996-1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: dns_gr.c,v 1.3.18.1 2005/04/27 05:00:54 sra Exp $";
-#endif
-
-/*! \file
- * \brief
- * dns_gr.c --- this file contains the functions for accessing
- * 	group information from Hesiod.
- */
-
-#include "port_before.h"
-
-#ifndef WANT_IRS_GR
-static int __bind_irs_gr_unneeded;
-#else
-
-#include <sys/param.h>
-#include <sys/types.h>
-
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <errno.h>
-#include <unistd.h>
-
-#include <sys/types.h>
-#include <netinet/in.h> 
-#include <arpa/nameser.h>
-#include <resolv.h>
-
-#include <isc/memcluster.h>
-
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "hesiod.h"
-#include "dns_p.h"
-
-/* Types. */
-
-struct pvt {
-	/*
-	 * This is our private accessor data.  It has a shared hesiod context.
-	 */
-	struct dns_p *	dns;
-	/*
-	 * Need space to store the entries read from the group file.
-	 * The members list also needs space per member, and the
-	 * strings making up the user names must be allocated
-	 * somewhere.  Rather than doing lots of small allocations,
-	 * we keep one buffer and resize it as needed.
-	 */
-	struct group	group;
-	size_t		nmemb;		/*%< Malloc'd max index of gr_mem[]. */
-	char *		membuf;
-	size_t		membufsize;
-};
-
-/* Forward. */
-
-static struct group *	gr_next(struct irs_gr *);
-static struct group *	gr_byname(struct irs_gr *, const char *);
-static struct group *	gr_bygid(struct irs_gr *, gid_t);
-static void		gr_rewind(struct irs_gr *);
-static void		gr_close(struct irs_gr *);
-static int		gr_list(struct irs_gr *, const char *,
-				gid_t, gid_t *, int *);
-static void		gr_minimize(struct irs_gr *);
-static struct __res_state * gr_res_get(struct irs_gr *);
-static void		gr_res_set(struct irs_gr *,
-				   struct __res_state *,
-				   void (*)(void *));
-
-static struct group *	get_hes_group(struct irs_gr *this,
-				      const char *name,
-				      const char *type);
-
-/* Public. */
-
-struct irs_gr *
-irs_dns_gr(struct irs_acc *this) {
-	struct dns_p *dns = (struct dns_p *)this->private;
-	struct irs_gr *gr;
-	struct pvt *pvt;
-
-	if (!dns || !dns->hes_ctx) {
-		errno = ENODEV;
-		return (NULL);
-	}
-	if (!(pvt = memget(sizeof *pvt))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	pvt->dns = dns;
-	if (!(gr = memget(sizeof *gr))) {
-		memput(pvt, sizeof *pvt);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(gr, 0x5e, sizeof *gr);
-	gr->private = pvt;
-	gr->next = gr_next;
-	gr->byname = gr_byname;
-	gr->bygid = gr_bygid;
-	gr->rewind = gr_rewind;
-	gr->close = gr_close;
-	gr->list = gr_list;
-	gr->minimize = gr_minimize;
-	gr->res_get = gr_res_get;
-	gr->res_set = gr_res_set;
-	return (gr);
-}
-
-/* methods */
-
-static void
-gr_close(struct irs_gr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (pvt->group.gr_mem)
-		free(pvt->group.gr_mem);
-	if (pvt->membuf)
-		free(pvt->membuf);
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-static struct group *
-gr_next(struct irs_gr *this) {
-
-	UNUSED(this);
-
-	return (NULL);
-}
-
-static struct group *
-gr_byname(struct irs_gr *this, const char *name) {
-	return (get_hes_group(this, name, "group"));
-}
-
-static struct group *
-gr_bygid(struct irs_gr *this, gid_t gid) {
-	char name[32];
-
-	sprintf(name, "%ld", (long)gid);
-	return (get_hes_group(this, name, "gid"));
-}
-
-static void
-gr_rewind(struct irs_gr *this) {
-
-	UNUSED(this);
-
-	/* NOOP */
-}
-
-static int
-gr_list(struct irs_gr *this, const char *name,
-	gid_t basegid, gid_t *groups, int *ngroups)
-{
-	UNUSED(this);
-	UNUSED(name);
-	UNUSED(basegid);
-	UNUSED(groups);
-
-	*ngroups = 0;
-	/* There's some way to do this in Hesiod. */
-	return (-1);
-}
-
-static void
-gr_minimize(struct irs_gr *this) {
-
-	UNUSED(this);
-	/* NOOP */
-}
-
-/* Private. */
-
-static struct group *
-get_hes_group(struct irs_gr *this, const char *name, const char *type) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	char **hes_list, *cp, **new;
-	size_t num_members = 0;
-	u_long t;
-
-	hes_list = hesiod_resolve(pvt->dns->hes_ctx, name, type);
-	if (!hes_list)
-		return (NULL);
-
-	/*
-	 * Copy the returned hesiod string into storage space.
-	 */
-	if (pvt->membuf)
-		free(pvt->membuf);
-	pvt->membuf = strdup(*hes_list);
-	hesiod_free_list(pvt->dns->hes_ctx, hes_list);
-
-	cp = pvt->membuf;
-	pvt->group.gr_name = cp;
-	if (!(cp = strchr(cp, ':')))
-		goto cleanup;
-	*cp++ = '\0';
-	
-	pvt->group.gr_passwd = cp;
-	if (!(cp = strchr(cp, ':')))
-		goto cleanup;
-	*cp++ = '\0';
-
-	errno = 0;
-	t = strtoul(cp, NULL, 10);
-	if (errno == ERANGE)
-		goto cleanup;
-	pvt->group.gr_gid = (gid_t) t;
-	if (!(cp = strchr(cp, ':')))
-		goto cleanup;
-	cp++;
-
-	/*
-	 * Parse the members out.
-	 */
-	while (*cp) {
-		if (num_members+1 >= pvt->nmemb || pvt->group.gr_mem == NULL) {
-			pvt->nmemb += 10;
-			new = realloc(pvt->group.gr_mem,
-				      pvt->nmemb * sizeof(char *));
-			if (new == NULL)
-				goto cleanup;
-			pvt->group.gr_mem = new;
-		}
-		pvt->group.gr_mem[num_members++] = cp;
-		if (!(cp = strchr(cp, ',')))
-			break;
-		*cp++ = '\0';
-	}
-	if (!pvt->group.gr_mem) {
-		pvt->group.gr_mem = malloc(sizeof(char*));
-		if (!pvt->group.gr_mem)
-			goto cleanup;
-	}
-	pvt->group.gr_mem[num_members] = NULL;
-	
-	return (&pvt->group);
-	
- cleanup:	
-	if (pvt->group.gr_mem) {
-		free(pvt->group.gr_mem);
-		pvt->group.gr_mem = NULL;
-	}
-	if (pvt->membuf) {
-		free(pvt->membuf);
-		pvt->membuf = NULL;
-	}
-	return (NULL);
-}
-
-static struct __res_state *
-gr_res_get(struct irs_gr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct dns_p *dns = pvt->dns;
-
-	return (__hesiod_res_get(dns->hes_ctx));
-}
-
-static void
-gr_res_set(struct irs_gr *this, struct __res_state * res,
-	   void (*free_res)(void *)) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct dns_p *dns = pvt->dns;
-
-	__hesiod_res_set(dns->hes_ctx, res, free_res);
-}
-
-#endif /* WANT_IRS_GR */
diff --git a/contrib/bind9/lib/bind/irs/dns_ho.c b/contrib/bind9/lib/bind/irs/dns_ho.c
deleted file mode 100644
index db7ff02..0000000
--- a/contrib/bind9/lib/bind/irs/dns_ho.c
+++ /dev/null
@@ -1,1143 +0,0 @@
-/*
- * Copyright (c) 1985, 1988, 1993
- *    The Regents of the University of California.  All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- * 	This product includes software developed by the University of
- * 	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-/* from gethostnamadr.c	8.1 (Berkeley) 6/4/93 */
-/* 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.14.18.8 2008/09/24 05:59:50 marka Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-/* Imports. */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/param.h>
-#include <sys/socket.h>
-
-#include <netinet/in.h>
-#include <arpa/inet.h>
-#include <arpa/nameser.h>
-
-#include <ctype.h>
-#include <errno.h>
-#include <stdlib.h>
-#include <netdb.h>
-#include <resolv.h>
-#include <stdio.h>
-#include <string.h>
-#include <syslog.h>
-
-#include <isc/memcluster.h>
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "dns_p.h"
-
-#ifdef SPRINTF_CHAR
-# define SPRINTF(x) strlen(sprintf/**/x)
-#else
-# define SPRINTF(x) sprintf x
-#endif
-
-/* Definitions. */
-
-#define	MAXALIASES	35
-#define	MAXADDRS	35
-
-#define MAXPACKET (65535)	/*%< Maximum TCP message size */
-#define BOUNDS_CHECK(ptr, count) \
-	if ((ptr) + (count) > eom) { \
-		had_error++; \
-		continue; \
-	} else (void)0
-
-typedef union {
-	HEADER hdr;
-	u_char buf[MAXPACKET];
-} querybuf;
-
-struct dns_res_target {
-	struct dns_res_target *next;
-	querybuf qbuf;		/*%< query buffer */
-	u_char *answer;		/*%< buffer to put answer */
-	int anslen;		/*%< size of answer buffer */
-	int qclass, qtype;	/*%< class and type of query */
-	int action;		/*%< condition whether query is really issued */
-	char qname[MAXDNAME +1]; /*%< domain name */
-#if 0
-	int n;			/*%< result length */
-#endif
-};
-enum {RESTGT_DOALWAYS, RESTGT_AFTERFAILURE, RESTGT_IGNORE};
-enum {RESQRY_SUCCESS, RESQRY_FAIL};
-
-struct pvt {
-	struct hostent	host;
-	char *		h_addr_ptrs[MAXADDRS + 1];
-	char *		host_aliases[MAXALIASES];
-	char		hostbuf[8*1024];
-	u_char		host_addr[16];	/*%< IPv4 or IPv6 */
-	struct __res_state  *res;
-	void		(*free_res)(void *);
-};
-
-typedef union {
-	int32_t al;
-	char ac;
-} align;
-
-static const u_char mapped[] = { 0,0, 0,0, 0,0, 0,0, 0,0, 0xff,0xff };
-static const u_char tunnelled[] = { 0,0, 0,0, 0,0, 0,0, 0,0, 0,0 };
-/* Note: the IPv6 loopback address is in the "tunnel" space */
-static const u_char v6local[] = { 0,0, 0,1 }; /*%< last 4 bytes of IPv6 addr */
-/* Forwards. */
-
-static void		ho_close(struct irs_ho *this);
-static struct hostent *	ho_byname(struct irs_ho *this, const char *name);
-static struct hostent *	ho_byname2(struct irs_ho *this, const char *name,
-				   int af);
-static struct hostent *	ho_byaddr(struct irs_ho *this, const void *addr,
-				  int len, int af);
-static struct hostent *	ho_next(struct irs_ho *this);
-static void		ho_rewind(struct irs_ho *this);
-static void		ho_minimize(struct irs_ho *this);
-static struct __res_state * ho_res_get(struct irs_ho *this);
-static void		ho_res_set(struct irs_ho *this,
-				   struct __res_state *res,
-				   void (*free_res)(void *));
-static struct addrinfo * ho_addrinfo(struct irs_ho *this, const char *name,
-				     const struct addrinfo *pai);
-
-static void		map_v4v6_hostent(struct hostent *hp, char **bp,
-					 char *ep);
-static void		addrsort(res_state, char **, int);
-static struct hostent *	gethostans(struct irs_ho *this,
-				   const u_char *ansbuf, int anslen,
-				   const char *qname, int qtype,
-				   int af, int size,
-				   struct addrinfo **ret_aip,
-				   const struct addrinfo *pai);
-static int add_hostent(struct pvt *pvt, char *bp, char **hap,
-		       struct addrinfo *ai);
-static int		init(struct irs_ho *this);
-
-/* Exports. */
-
-struct irs_ho *
-irs_dns_ho(struct irs_acc *this) {
-	struct irs_ho *ho;
-	struct pvt *pvt;
-
-	UNUSED(this);
-
-	if (!(pvt = memget(sizeof *pvt))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-
-	if (!(ho = memget(sizeof *ho))) {
-		memput(pvt, sizeof *pvt);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(ho, 0x5e, sizeof *ho);
-	ho->private = pvt;
-	ho->close = ho_close;
-	ho->byname = ho_byname;
-	ho->byname2 = ho_byname2;
-	ho->byaddr = ho_byaddr;
-	ho->next = ho_next;
-	ho->rewind = ho_rewind;
-	ho->minimize = ho_minimize;
-	ho->res_get = ho_res_get;
-	ho->res_set = ho_res_set;
-	ho->addrinfo = ho_addrinfo;
-	return (ho);
-}
-
-/* Methods. */
-
-static void
-ho_close(struct irs_ho *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	ho_minimize(this);
-	if (pvt->res && pvt->free_res)
-		(*pvt->free_res)(pvt->res);
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-static struct hostent *
-ho_byname(struct irs_ho *this, const char *name) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct hostent *hp;
-
-	if (init(this) == -1)
-		return (NULL);
-
-	if (pvt->res->options & RES_USE_INET6) {
-		hp = ho_byname2(this, name, AF_INET6);
-		if (hp)
-			return (hp);
-	}
-	return (ho_byname2(this, name, AF_INET));
-}
-
-static struct hostent *
-ho_byname2(struct irs_ho *this, const char *name, int af)
-{
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct hostent *hp = NULL;
-	int n, size;
-	char tmp[NS_MAXDNAME];
-	const char *cp;
-	struct addrinfo ai;
-	struct dns_res_target *q, *p;
-	int querystate = RESQRY_FAIL;
-
-	if (init(this) == -1)
-		return (NULL);
-
-	q = memget(sizeof(*q));
-	if (q == NULL) {
-		RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL);
-		errno = ENOMEM;
-		goto cleanup;
-	}
-	memset(q, 0, sizeof(*q));
-
-	switch (af) {
-	case AF_INET:
-		size = INADDRSZ;
-		q->qclass = C_IN;
-		q->qtype = T_A;
-		q->answer = q->qbuf.buf;
-		q->anslen = sizeof(q->qbuf);
-		q->action = RESTGT_DOALWAYS;
-		break;
-	case AF_INET6:
-		size = IN6ADDRSZ;
-		q->qclass = C_IN;
-		q->qtype = T_AAAA;
-		q->answer = q->qbuf.buf;
-		q->anslen = sizeof(q->qbuf);
-		q->action = RESTGT_DOALWAYS;
-		break;
-	default:
-		RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL);
-		errno = EAFNOSUPPORT;
-		hp = NULL;
-		goto cleanup;
-	}
-
-	/*
-	 * if there aren't any dots, it could be a user-level alias.
-	 * this is also done in res_nquery() since we are not the only
-	 * function that looks up host names.
-	 */
-	if (!strchr(name, '.') && (cp = res_hostalias(pvt->res, name,
-						      tmp, sizeof tmp)))
-		name = cp;
-
-	for (p = q; p; p = p->next) {
-		switch(p->action) {
-		case RESTGT_DOALWAYS:
-			break;
-		case RESTGT_AFTERFAILURE:
-			if (querystate == RESQRY_SUCCESS)
-				continue;
-			break;
-		case RESTGT_IGNORE:
-			continue;
-		}
-
-		if ((n = res_nsearch(pvt->res, name, p->qclass, p->qtype,
-				     p->answer, p->anslen)) < 0) {
-			querystate = RESQRY_FAIL;
-			continue;
-		}
-
-		memset(&ai, 0, sizeof(ai));
-		ai.ai_family = af;
-		if ((hp = gethostans(this, p->answer, n, name, p->qtype,
-				     af, size, NULL,
-				     (const struct addrinfo *)&ai)) != NULL)
-			goto cleanup;	/*%< no more loop is necessary */
-		querystate = RESQRY_FAIL;
-		continue;
-	}
-
- cleanup:
-	if (q != NULL)
-		memput(q, sizeof(*q));
-	return(hp);
-}
-
-static struct hostent *
-ho_byaddr(struct irs_ho *this, const void *addr, int len, int af)
-{
-	struct pvt *pvt = (struct pvt *)this->private;
-	const u_char *uaddr = addr;
-	char *qp;
-	struct hostent *hp = NULL;
-	struct addrinfo ai;
-	struct dns_res_target *q, *q2, *p;
-	int n, size, i;
-	int querystate = RESQRY_FAIL;
-	
-	if (init(this) == -1)
-		return (NULL);
-
-	q = memget(sizeof(*q));
-	q2 = memget(sizeof(*q2));
-	if (q == NULL || q2 == NULL) {
-		RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL);
-		errno = ENOMEM;
-		goto cleanup;
-	}
-	memset(q, 0, sizeof(*q));
-	memset(q2, 0, sizeof(*q2));
-
-	if (af == AF_INET6 && len == IN6ADDRSZ &&
-	    (!memcmp(uaddr, mapped, sizeof mapped) ||
-           (!memcmp(uaddr, tunnelled, sizeof tunnelled) &&
-            memcmp(&uaddr[sizeof tunnelled], v6local, sizeof(v6local))))) {
-		/* Unmap. */
-		addr = (const char *)addr + sizeof mapped;
-		uaddr += sizeof mapped;
-		af = AF_INET;
-		len = INADDRSZ;
-	}
-	switch (af) {
-	case AF_INET:
-		size = INADDRSZ;
-		q->qclass = C_IN;
-		q->qtype = T_PTR;
-		q->answer = q->qbuf.buf;
-		q->anslen = sizeof(q->qbuf);
-		q->action = RESTGT_DOALWAYS;
-		break;
-	case AF_INET6:
-		size = IN6ADDRSZ;
-		q->qclass = C_IN;
-		q->qtype = T_PTR;
-		q->answer = q->qbuf.buf;
-		q->anslen = sizeof(q->qbuf);
-		q->next = q2;
-		q->action = RESTGT_DOALWAYS;
-		q2->qclass = C_IN;
-		q2->qtype = T_PTR;
-		q2->answer = q2->qbuf.buf;
-		q2->anslen = sizeof(q2->qbuf);
-		if ((pvt->res->options & RES_NO_NIBBLE2) != 0U)
-			q2->action = RESTGT_IGNORE;
-		else
-			q2->action = RESTGT_AFTERFAILURE;
-		break;
-	default:
-		errno = EAFNOSUPPORT;
-		RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL);
-		hp = NULL;
-		goto cleanup;
-	}
-	if (size > len) {
-		errno = EINVAL;
-		RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL);
-		hp = NULL;
-		goto cleanup;
-	}
-	switch (af) {
-	case AF_INET:
-		qp = q->qname;
-		(void) sprintf(qp, "%u.%u.%u.%u.in-addr.arpa",
-			       (uaddr[3] & 0xff),
-			       (uaddr[2] & 0xff),
-			       (uaddr[1] & 0xff),
-			       (uaddr[0] & 0xff));
-		break;
-	case AF_INET6:
-		if (q->action != RESTGT_IGNORE) {
-			const char *nibsuff = res_get_nibblesuffix(pvt->res);
-			qp = q->qname;
-			for (n = IN6ADDRSZ - 1; n >= 0; n--) {
-				i = SPRINTF((qp, "%x.%x.",
-					       uaddr[n] & 0xf,
-					       (uaddr[n] >> 4) & 0xf));
-				if (i != 4)
-					abort();
-				qp += i;
-			}
-			if (strlen(q->qname) + strlen(nibsuff) + 1 >
-			    sizeof q->qname) {
-				errno = ENAMETOOLONG;
-				RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL);
-				hp = NULL;
-				goto cleanup;
-			}
-			strcpy(qp, nibsuff);	/* (checked) */
-		}
-		if (q2->action != RESTGT_IGNORE) {
-			const char *nibsuff2 = res_get_nibblesuffix2(pvt->res);
-			qp = q2->qname;
-			for (n = IN6ADDRSZ - 1; n >= 0; n--) {
-				i = SPRINTF((qp, "%x.%x.",
-					       uaddr[n] & 0xf,
-					       (uaddr[n] >> 4) & 0xf));
-				if (i != 4)
-					abort();
-				qp += i;
-			}
-			if (strlen(q2->qname) + strlen(nibsuff2) + 1 >
-			    sizeof q2->qname) {
-				errno = ENAMETOOLONG;
-				RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL);
-				hp = NULL;
-				goto cleanup;
-			}
-			strcpy(qp, nibsuff2);	/* (checked) */
-		}
-		break;
-	default:
-		abort();
-	}
-
-	for (p = q; p; p = p->next) {
-		switch(p->action) {
-		case RESTGT_DOALWAYS:
-			break;
-		case RESTGT_AFTERFAILURE:
-			if (querystate == RESQRY_SUCCESS)
-				continue;
-			break;
-		case RESTGT_IGNORE:
-			continue;
-		}
-
-		if ((n = res_nquery(pvt->res, p->qname, p->qclass, p->qtype,
-				    p->answer, p->anslen)) < 0) {
-			querystate = RESQRY_FAIL;
-			continue;
-		}
-
-		memset(&ai, 0, sizeof(ai));
-		ai.ai_family = af;
-		hp = gethostans(this, p->answer, n, p->qname, T_PTR, af, size,
-				NULL, (const struct addrinfo *)&ai);
-		if (!hp) {
-			querystate = RESQRY_FAIL;
-			continue;
-		}
-			
-		memcpy(pvt->host_addr, addr, len);
-		pvt->h_addr_ptrs[0] = (char *)pvt->host_addr;
-		pvt->h_addr_ptrs[1] = NULL;
-		if (af == AF_INET && (pvt->res->options & RES_USE_INET6)) {
-			map_v4v6_address((char*)pvt->host_addr,
-					 (char*)pvt->host_addr);
-			pvt->host.h_addrtype = AF_INET6;
-			pvt->host.h_length = IN6ADDRSZ;
-		}
-
-		RES_SET_H_ERRNO(pvt->res, NETDB_SUCCESS);
-		goto cleanup;	/*%< no more loop is necessary. */
-	}
-	hp = NULL; /*%< H_ERRNO was set by subroutines */
- cleanup:
-	if (q != NULL)
-		memput(q, sizeof(*q));
-	if (q2 != NULL)
-		memput(q2, sizeof(*q2));
-	return(hp);
-}
-
-static struct hostent *
-ho_next(struct irs_ho *this) {
-
-	UNUSED(this);
-
-	return (NULL);
-}
-
-static void
-ho_rewind(struct irs_ho *this) {
-
-	UNUSED(this);
-
-	/* NOOP */
-}
-
-static void
-ho_minimize(struct irs_ho *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (pvt->res)
-		res_nclose(pvt->res);
-}
-
-static struct __res_state *
-ho_res_get(struct irs_ho *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (!pvt->res) {
-		struct __res_state *res;
-		res = (struct __res_state *)malloc(sizeof *res);
-		if (!res) {
-			errno = ENOMEM;
-			return (NULL);
-		}
-		memset(res, 0, sizeof *res);
-		ho_res_set(this, res, free);
-	}
-
-	return (pvt->res);
-}
-
-/* XXX */
-extern struct addrinfo *addr2addrinfo __P((const struct addrinfo *,
-					   const char *));
-
-static struct addrinfo *
-ho_addrinfo(struct irs_ho *this, const char *name, const struct addrinfo *pai)
-{
-	struct pvt *pvt = (struct pvt *)this->private;
-	int n;
-	char tmp[NS_MAXDNAME];
-	const char *cp;
-	struct dns_res_target *q, *q2, *p;
-	struct addrinfo sentinel, *cur;
-	int querystate = RESQRY_FAIL;
-
-	if (init(this) == -1)
-		return (NULL);
-
-	memset(&sentinel, 0, sizeof(sentinel));
-	cur = &sentinel;
-
-	q = memget(sizeof(*q));
-	q2 = memget(sizeof(*q2));
-	if (q == NULL || q2 == NULL) {
-		RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL);
-		errno = ENOMEM;
-		goto cleanup;
-	}
-	memset(q, 0, sizeof(*q2));
-	memset(q2, 0, sizeof(*q2));
-
-	switch (pai->ai_family) {
-	case AF_UNSPEC:
-		/* prefer IPv6 */
-		q->qclass = C_IN;
-		q->qtype = T_AAAA;
-		q->answer = q->qbuf.buf;
-		q->anslen = sizeof(q->qbuf);
-		q->next = q2;
-		q->action = RESTGT_DOALWAYS;
-		q2->qclass = C_IN;
-		q2->qtype = T_A;
-		q2->answer = q2->qbuf.buf;
-		q2->anslen = sizeof(q2->qbuf);
-		q2->action = RESTGT_DOALWAYS;
-		break;
-	case AF_INET:
-		q->qclass = C_IN;
-		q->qtype = T_A;
-		q->answer = q->qbuf.buf;
-		q->anslen = sizeof(q->qbuf);
-		q->action = RESTGT_DOALWAYS;
-		break;
-	case AF_INET6:
-		q->qclass = C_IN;
-		q->qtype = T_AAAA;
-		q->answer = q->qbuf.buf;
-		q->anslen = sizeof(q->qbuf);
-		q->action = RESTGT_DOALWAYS;
-		break;
-	default:
-		RES_SET_H_ERRNO(pvt->res, NO_RECOVERY); /*%< better error? */
-		goto cleanup;
-	}
-
-	/*
-	 * if there aren't any dots, it could be a user-level alias.
-	 * this is also done in res_nquery() since we are not the only
-	 * function that looks up host names.
-	 */
-	if (!strchr(name, '.') && (cp = res_hostalias(pvt->res, name,
-						      tmp, sizeof tmp)))
-		name = cp;
-
-	for (p = q; p; p = p->next) {
-		struct addrinfo *ai;
-
-		switch(p->action) {
-		case RESTGT_DOALWAYS:
-			break;
-		case RESTGT_AFTERFAILURE:
-			if (querystate == RESQRY_SUCCESS)
-				continue;
-			break;
-		case RESTGT_IGNORE:
-			continue;
-		}
-
-		if ((n = res_nsearch(pvt->res, name, p->qclass, p->qtype,
-				     p->answer, p->anslen)) < 0) {
-			querystate = RESQRY_FAIL;
-			continue;
-		}
-		(void)gethostans(this, p->answer, n, name, p->qtype,
-				 pai->ai_family, /*%< XXX: meaningless */
-				 0, &ai, pai);
-		if (ai) {
-			querystate = RESQRY_SUCCESS;
-			cur->ai_next = ai;
-			while (cur->ai_next)
-				cur = cur->ai_next;
-		} else
-			querystate = RESQRY_FAIL;
-	}
-
- cleanup:
-	if (q != NULL)
-		memput(q, sizeof(*q));
-	if (q2 != NULL)
-		memput(q2, sizeof(*q2));
-	return(sentinel.ai_next);
-}
-
-static void
-ho_res_set(struct irs_ho *this, struct __res_state *res,
-		void (*free_res)(void *)) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (pvt->res && pvt->free_res) {
-		res_nclose(pvt->res);
-		(*pvt->free_res)(pvt->res);
-	}
-
-	pvt->res = res;
-	pvt->free_res = free_res;
-}
-
-/* Private. */
-
-static struct hostent *
-gethostans(struct irs_ho *this,
-	   const u_char *ansbuf, int anslen, const char *qname, int qtype,
-	   int af, int size,	/*!< meaningless for addrinfo cases  */
-	   struct addrinfo **ret_aip, const struct addrinfo *pai)
-{
-	struct pvt *pvt = (struct pvt *)this->private;
-	int type, class, ancount, qdcount, n, haveanswer, had_error;
-	int error = NETDB_SUCCESS;
-	int (*name_ok)(const char *);
-	const HEADER *hp;
-	const u_char *eom;
-	const u_char *eor;
-	const u_char *cp;
-	const char *tname;
-	const char *hname;
-	char *bp, *ep, **ap, **hap;
-	char tbuf[MAXDNAME+1];
-	struct addrinfo sentinel, *cur, ai;
-
-	if (pai == NULL) abort();
-	if (ret_aip != NULL)
-		*ret_aip = NULL;
-	memset(&sentinel, 0, sizeof(sentinel));
-	cur = &sentinel;
-
-	tname = qname;
-	eom = ansbuf + anslen;
-	switch (qtype) {
-	case T_A:
-	case T_AAAA:
-	case T_ANY:	/*%< use T_ANY only for T_A/T_AAAA lookup */
-		name_ok = res_hnok;
-		break;
-	case T_PTR:
-		name_ok = res_dnok;
-		break;
-	default:
-		abort();
-	}
-
-	pvt->host.h_addrtype = af;
-	pvt->host.h_length = size;
-	hname = pvt->host.h_name = NULL;
-
-	/*
-	 * Find first satisfactory answer.
-	 */
-	if (ansbuf + HFIXEDSZ > eom) {
-		RES_SET_H_ERRNO(pvt->res, NO_RECOVERY);
-		return (NULL);
-	}
-	hp = (const HEADER *)ansbuf;
-	ancount = ntohs(hp->ancount);
-	qdcount = ntohs(hp->qdcount);
-	bp = pvt->hostbuf;
-	ep = pvt->hostbuf + sizeof(pvt->hostbuf);
-	cp = ansbuf + HFIXEDSZ;
-	if (qdcount != 1) {
-		RES_SET_H_ERRNO(pvt->res, NO_RECOVERY);
-		return (NULL);
-	}
-	n = dn_expand(ansbuf, eom, cp, bp, ep - bp);
-	if (n < 0 || !maybe_ok(pvt->res, bp, name_ok)) {
-		RES_SET_H_ERRNO(pvt->res, NO_RECOVERY);
-		return (NULL);
-	}
-	cp += n + QFIXEDSZ;
-	if (cp > eom) {
-		RES_SET_H_ERRNO(pvt->res, NO_RECOVERY);
-		return (NULL);
-	}
-	if (qtype == T_A || qtype == T_AAAA || qtype == T_ANY) {
-		/* res_nsend() has already verified that the query name is the
-		 * same as the one we sent; this just gets the expanded name
-		 * (i.e., with the succeeding search-domain tacked on).
-		 */
-		n = strlen(bp) + 1;		/*%< for the \\0 */
-		if (n > MAXHOSTNAMELEN) {
-			RES_SET_H_ERRNO(pvt->res, NO_RECOVERY);
-			return (NULL);
-		}
-		pvt->host.h_name = bp;
-		hname = bp;
-		bp += n;
-		/* The qname can be abbreviated, but hname is now absolute. */
-		qname = pvt->host.h_name;
-	}
-	ap = pvt->host_aliases;
-	*ap = NULL;
-	pvt->host.h_aliases = pvt->host_aliases;
-	hap = pvt->h_addr_ptrs;
-	*hap = NULL;
-	pvt->host.h_addr_list = pvt->h_addr_ptrs;
-	haveanswer = 0;
-	had_error = 0;
-	while (ancount-- > 0 && cp < eom && !had_error) {
-		n = dn_expand(ansbuf, eom, cp, bp, ep - bp);
-		if (n < 0 || !maybe_ok(pvt->res, bp, name_ok)) {
-			had_error++;
-			continue;
-		}
-		cp += n;			/*%< name */
-		BOUNDS_CHECK(cp, 3 * INT16SZ + INT32SZ);
-		type = ns_get16(cp);
- 		cp += INT16SZ;			/*%< type */
-		class = ns_get16(cp);
- 		cp += INT16SZ + INT32SZ;	/*%< class, TTL */
-		n = ns_get16(cp);
-		cp += INT16SZ;			/*%< len */
-		BOUNDS_CHECK(cp, n);
-		if (class != C_IN) {
-			cp += n;
-			continue;
-		}
-		eor = cp + n;
-		if ((qtype == T_A || qtype == T_AAAA || qtype == T_ANY) &&
-		    type == T_CNAME) {
-			if (haveanswer) {
-				int level = LOG_CRIT;
-#ifdef LOG_SECURITY
-				level |= LOG_SECURITY;
-#endif
-				syslog(level,
- "gethostans: possible attempt to exploit buffer overflow while looking up %s",
-					*qname ? qname : ".");
-			}
-			n = dn_expand(ansbuf, eor, cp, tbuf, sizeof tbuf);
-			if (n < 0 || !maybe_ok(pvt->res, tbuf, name_ok)) {
-				had_error++;
-				continue;
-			}
-			cp += n;
-			/* Store alias. */
-			if (ap >= &pvt->host_aliases[MAXALIASES-1])
-				continue;
-			*ap++ = bp;
-			n = strlen(bp) + 1;	/*%< for the \\0 */
-			bp += n;
-			/* Get canonical name. */
-			n = strlen(tbuf) + 1;	/*%< for the \\0 */
-			if (n > (ep - bp) || n > MAXHOSTNAMELEN) {
-				had_error++;
-				continue;
-			}
-			strcpy(bp, tbuf);	/* (checked) */
-			pvt->host.h_name = bp;
-			hname = bp;
-			bp += n;
-			continue;
-		}
-		if (qtype == T_PTR && type == T_CNAME) {
-			n = dn_expand(ansbuf, eor, cp, tbuf, sizeof tbuf);
-			if (n < 0 || !maybe_dnok(pvt->res, tbuf)) {
-				had_error++;
-				continue;
-			}
-			cp += n;
-#ifdef RES_USE_DNAME
-			if ((pvt->res->options & RES_USE_DNAME) != 0U)
-#endif
-			{
-				/*
-				 * We may be able to check this regardless
-				 * of the USE_DNAME bit, but we add the check
-				 * for now since the DNAME support is
-				 * experimental.
-				 */
-				if (ns_samename(tname, bp) != 1)
-					continue;
-			}
-			/* Get canonical name. */
-			n = strlen(tbuf) + 1;	/*%< for the \\0 */
-			if (n > (ep - bp)) {
-				had_error++;
-				continue;
-			}
-			strcpy(bp, tbuf);	/* (checked) */
-			tname = bp;
-			bp += n;
-			continue;
-		}
-		if (qtype == T_ANY) {
-			if (!(type == T_A || type == T_AAAA)) {
-				cp += n;
-				continue;
-			}
-		} else if (type != qtype) {
-			cp += n;
-			continue;
-		}
-		switch (type) {
-		case T_PTR:
-			if (ret_aip != NULL) {
-				/* addrinfo never needs T_PTR */
-				cp += n;
-				continue;
-			}
-			if (ns_samename(tname, bp) != 1) {
-				cp += n;
-				continue;
-			}
-			n = dn_expand(ansbuf, eor, cp, bp, ep - bp);
-			if (n < 0 || !maybe_hnok(pvt->res, bp) ||
-			    n >= MAXHOSTNAMELEN) {
-				had_error++;
-				break;
-			}
-			cp += n;
-			if (!haveanswer) {
-				pvt->host.h_name = bp;
-				hname = bp;
-			}
-			else if (ap < &pvt->host_aliases[MAXALIASES-1])
-				*ap++ = bp;
-			else
-				n = -1;
-			if (n != -1) {
-				n = strlen(bp) + 1;	/*%< for the \\0 */
-				bp += n;
-			}
-			break;
-		case T_A:
-		case T_AAAA:
-			if (ns_samename(hname, bp) != 1) {
-				cp += n;
-				continue;
-			}
-			if (type == T_A && n != INADDRSZ) {
-				cp += n;
-				continue;
-			}
-			if (type == T_AAAA && n != IN6ADDRSZ) {
-				cp += n;
-				continue;
-			}
-
-			/* make addrinfo. don't overwrite constant PAI */
-			ai = *pai;
-			ai.ai_family = (type == T_AAAA) ? AF_INET6 : AF_INET;
-			cur->ai_next = addr2addrinfo(
-					(const struct addrinfo *)&ai,
-					(const char *)cp);
-			if (cur->ai_next == NULL)
-				had_error++;
-
-			if (!haveanswer) {
-				int nn;
-
-				nn = strlen(bp) + 1;	/*%< for the \\0 */
-				if (nn >= MAXHOSTNAMELEN) {
-					cp += n;
-					had_error++;
-					continue;
-				}
-				pvt->host.h_name = bp;
-				hname = bp;
-				bp += nn;
-			}
-			/* Ensure alignment. */
-			bp = (char *)(((u_long)bp + (sizeof(align) - 1)) &
-				      ~(sizeof(align) - 1));
-			/* Avoid overflows. */
-			if (bp + n > &pvt->hostbuf[sizeof(pvt->hostbuf) - 1]) {
-				had_error++;
-				continue;
-			}
-			if (ret_aip) { /*%< need addrinfo. keep it. */
-				while (cur->ai_next)
-					cur = cur->ai_next;
-			} else if (cur->ai_next) { /*%< need hostent */
-				struct addrinfo *aip = cur->ai_next;
-
-				for (aip = cur->ai_next; aip;
-				     aip = aip->ai_next) {
-					int m;
-
-					m = add_hostent(pvt, bp, hap, aip);
-					if (m < 0) {
-						had_error++;
-						break;
-					}
-					if (m == 0)
-						continue;
-					if (hap < &pvt->h_addr_ptrs[MAXADDRS])
-						hap++;
-					*hap = NULL;
-					bp += m;
-				}
-
-				freeaddrinfo(cur->ai_next);
-				cur->ai_next = NULL;
-			}
-			cp += n;
-			break;
-		default:
-			abort();
-		}
-		if (!had_error)
-			haveanswer++;
-	}
-	if (haveanswer) {
-		if (ret_aip == NULL) {
-			*ap = NULL;
-			*hap = NULL;
-
-			if (pvt->res->nsort && hap != pvt->h_addr_ptrs &&
-			    qtype == T_A)
-				addrsort(pvt->res, pvt->h_addr_ptrs,
-					 hap - pvt->h_addr_ptrs);
-			if (pvt->host.h_name == NULL) {
-				n = strlen(qname) + 1;	/*%< for the \\0 */
-				if (n > (ep - bp) || n >= MAXHOSTNAMELEN)
-					goto no_recovery;
-				strcpy(bp, qname);	/* (checked) */
-				pvt->host.h_name = bp;
-				bp += n;
-			}
-			if (pvt->res->options & RES_USE_INET6)
-				map_v4v6_hostent(&pvt->host, &bp, ep);
-			RES_SET_H_ERRNO(pvt->res, NETDB_SUCCESS);
-			return (&pvt->host);
-		} else {
-			if ((pai->ai_flags & AI_CANONNAME) != 0) {
-				if (pvt->host.h_name == NULL) {
-					sentinel.ai_next->ai_canonname =
-						strdup(qname);
-				}
-				else {
-					sentinel.ai_next->ai_canonname =
-						strdup(pvt->host.h_name);
-				}
-			}
-			*ret_aip = sentinel.ai_next;
-			return(NULL);
-		}
-	}
- no_recovery:
-	if (sentinel.ai_next) {
-		/* this should be impossible, but check it for safety */
-		freeaddrinfo(sentinel.ai_next);
-	}
-	if (error == NETDB_SUCCESS)
-		RES_SET_H_ERRNO(pvt->res, NO_RECOVERY);
-	else
-		RES_SET_H_ERRNO(pvt->res, error);
-	return(NULL);
-}
-
-static int
-add_hostent(struct pvt *pvt, char *bp, char **hap, struct addrinfo *ai)
-{
-	int addrlen;
-	char *addrp;
-	const char **tap;
-	char *obp = bp;
-
-	switch(ai->ai_addr->sa_family) {
-	case AF_INET6:
-		addrlen = IN6ADDRSZ;
-		addrp = (char *)&((struct sockaddr_in6 *)ai->ai_addr)->sin6_addr;
-		break;
-	case AF_INET:
-		addrlen = INADDRSZ;
-		addrp = (char *)&((struct sockaddr_in *)ai->ai_addr)->sin_addr;
-		break;
-	default:
-		return(-1);	/*%< abort? */
-	}
-
-	/* Ensure alignment. */
-	bp = (char *)(((u_long)bp + (sizeof(align) - 1)) &
-		      ~(sizeof(align) - 1));
-	/* Avoid overflows. */
-	if (bp + addrlen > &pvt->hostbuf[sizeof(pvt->hostbuf) - 1])
-		return(-1);
-	if (hap >= &pvt->h_addr_ptrs[MAXADDRS])
-		return(0); /*%< fail, but not treat it as an error. */
-	/* Suppress duplicates. */
-	for (tap = (const char **)pvt->h_addr_ptrs;
-	     *tap != NULL;
-	     tap++)
-		if (memcmp(*tap, addrp, addrlen) == 0)
-			break;
-	if (*tap != NULL)
-		return (0);
-
-	memcpy(*hap = bp, addrp, addrlen);
-	return((bp + addrlen) - obp);
-}
-
-static void
-map_v4v6_hostent(struct hostent *hp, char **bpp, char *ep) {
-	char **ap;
-
-	if (hp->h_addrtype != AF_INET || hp->h_length != INADDRSZ)
-		return;
-	hp->h_addrtype = AF_INET6;
-	hp->h_length = IN6ADDRSZ;
-	for (ap = hp->h_addr_list; *ap; ap++) {
-		int i = (u_long)*bpp % sizeof(align);
-
-		if (i != 0)
-			i = sizeof(align) - i;
-
-		if ((ep - *bpp) < (i + IN6ADDRSZ)) {
-			/* Out of memory.  Truncate address list here. */
-			*ap = NULL;
-			return;
-		}
-		*bpp += i;
-		map_v4v6_address(*ap, *bpp);
-		*ap = *bpp;
-		*bpp += IN6ADDRSZ;
-	}
-}
-
-static void
-addrsort(res_state statp, char **ap, int num) {
-	int i, j, needsort = 0, aval[MAXADDRS];
-	char **p;
-
-	p = ap;
-	for (i = 0; i < num; i++, p++) {
-		for (j = 0 ; (unsigned)j < statp->nsort; j++)
-			if (statp->sort_list[j].addr.s_addr == 
-			    (((struct in_addr *)(*p))->s_addr &
-			     statp->sort_list[j].mask))
-				break;
-		aval[i] = j;
-		if (needsort == 0 && i > 0 && j < aval[i-1])
-			needsort = i;
-	}
-	if (!needsort)
-		return;
-
-	while (needsort < num) {
-		for (j = needsort - 1; j >= 0; j--) {
-			if (aval[j] > aval[j+1]) {
-				char *hp;
-
-				i = aval[j];
-				aval[j] = aval[j+1];
-				aval[j+1] = i;
-
-				hp = ap[j];
-				ap[j] = ap[j+1];
-				ap[j+1] = hp;
-
-			} else
-				break;
-		}
-		needsort++;
-	}
-}
-
-static int
-init(struct irs_ho *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	
-	if (!pvt->res && !ho_res_get(this))
-		return (-1);
-	if (((pvt->res->options & RES_INIT) == 0U) &&
-	    res_ninit(pvt->res) == -1)
-		return (-1);
-	return (0);
-}
diff --git a/contrib/bind9/lib/bind/irs/dns_nw.c b/contrib/bind9/lib/bind/irs/dns_nw.c
deleted file mode 100644
index 1d03a52..0000000
--- a/contrib/bind9/lib/bind/irs/dns_nw.c
+++ /dev/null
@@ -1,591 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996-1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: dns_nw.c,v 1.9.18.3 2005/04/27 05:00:55 sra Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-/* Imports. */
-
-#include "port_before.h"
-
-#include <sys/param.h>
-#include <sys/socket.h>
-
-#include <netinet/in.h>
-#include <arpa/inet.h>
-#include <arpa/nameser.h>
-
-#include <ctype.h>
-#include <errno.h>
-#include <netdb.h>
-#include <resolv.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-
-#include <isc/memcluster.h>
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "dns_p.h"
-
-#ifdef SPRINTF_CHAR
-# define SPRINTF(x) strlen(sprintf/**/x)
-#else
-# define SPRINTF(x) sprintf x
-#endif
-
-/* Definitions. */
-
-#define	MAXALIASES	35
-
-#define	MAXPACKET	(64*1024)
-
-struct pvt {
-	struct nwent	net;
-	char *		ali[MAXALIASES];
-	char		buf[BUFSIZ+1];
-	struct __res_state * res;
-	void		(*free_res)(void *);
-};
-
-typedef union {
-	long	al;
-	char	ac;
-} align;
-
-enum by_what { by_addr, by_name };
-
-/* Forwards. */
-
-static void		nw_close(struct irs_nw *);
-static struct nwent *	nw_byname(struct irs_nw *, const char *, int);
-static struct nwent *	nw_byaddr(struct irs_nw *, void *, int, int);
-static struct nwent *	nw_next(struct irs_nw *);
-static void		nw_rewind(struct irs_nw *);
-static void		nw_minimize(struct irs_nw *);
-static struct __res_state * nw_res_get(struct irs_nw *this);
-static void		nw_res_set(struct irs_nw *this,
-				   struct __res_state *res,
-				   void (*free_res)(void *));
-
-static struct nwent *	get1101byaddr(struct irs_nw *, u_char *, int);
-static struct nwent *	get1101byname(struct irs_nw *, const char *);
-static struct nwent *	get1101answer(struct irs_nw *,
-				      u_char *ansbuf, int anslen,
-				      enum by_what by_what,
-				      int af, const char *name,
-				      const u_char *addr, int addrlen);
-static struct nwent *	get1101mask(struct irs_nw *this, struct nwent *);
-static int		make1101inaddr(const u_char *, int, char *, int);
-static void		normalize_name(char *name);
-static int		init(struct irs_nw *this);
-
-/* Exports. */
-
-struct irs_nw *
-irs_dns_nw(struct irs_acc *this) {
-	struct irs_nw *nw;
-	struct pvt *pvt;
-
-	UNUSED(this);
-
-	if (!(pvt = memget(sizeof *pvt))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	if (!(nw = memget(sizeof *nw))) {
-		memput(pvt, sizeof *pvt);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(nw, 0x5e, sizeof *nw);
-	nw->private = pvt;
-	nw->close = nw_close;
-	nw->byname = nw_byname;
-	nw->byaddr = nw_byaddr;
-	nw->next = nw_next;
-	nw->rewind = nw_rewind;
-	nw->minimize = nw_minimize;
-	nw->res_get = nw_res_get;
-	nw->res_set = nw_res_set;
-	return (nw);
-}
-
-/* Methods. */
-
-static void
-nw_close(struct irs_nw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	nw_minimize(this);
-
-	if (pvt->res && pvt->free_res)
-		(*pvt->free_res)(pvt->res);
-
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-static struct nwent *
-nw_byname(struct irs_nw *this, const char *name, int af) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (init(this) == -1)
-		return (NULL);
-
-	switch (af) {
-	case AF_INET:
-		return (get1101byname(this, name));
-	default:
-		(void)NULL;
-	}
-	RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL);
-	errno = EAFNOSUPPORT;
-	return (NULL);
-}
-
-static struct nwent *
-nw_byaddr(struct irs_nw *this, void *net, int len, int af) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (init(this) == -1)
-		return (NULL);
-
-	switch (af) {
-	case AF_INET:
-		return (get1101byaddr(this, net, len));
-	default:
-		(void)NULL;
-	}
-	RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL);
-	errno = EAFNOSUPPORT;
-	return (NULL);
-}
-
-static struct nwent *
-nw_next(struct irs_nw *this) {
-
-	UNUSED(this);
-
-	return (NULL);
-}
-
-static void
-nw_rewind(struct irs_nw *this) {
-	UNUSED(this);
-	/* NOOP */
-}
-
-static void
-nw_minimize(struct irs_nw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (pvt->res)
-		res_nclose(pvt->res);
-}
-
-static struct __res_state *
-nw_res_get(struct irs_nw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (!pvt->res) {
-		struct __res_state *res;
-		res = (struct __res_state *)malloc(sizeof *res);
-		if (!res) {
-			errno = ENOMEM;
-			return (NULL);
-		}
-		memset(res, 0, sizeof *res);
-		nw_res_set(this, res, free);
-	}
-
-	return (pvt->res);
-}
-
-static void
-nw_res_set(struct irs_nw *this, struct __res_state *res,
-		void (*free_res)(void *)) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (pvt->res && pvt->free_res) {
-		res_nclose(pvt->res);
-		(*pvt->free_res)(pvt->res);
-	}
-
-	pvt->res = res;
-	pvt->free_res = free_res;
-}
-
-/* Private. */
-
-static struct nwent *
-get1101byname(struct irs_nw *this, const char *name) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	u_char *ansbuf;
-	int anslen;
-	struct nwent *result;
-
-	ansbuf = memget(MAXPACKET);
-	if (ansbuf == NULL) {
-		errno = ENOMEM;
-		RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL);
-		return (NULL);
-	}
-	anslen = res_nsearch(pvt->res, name, C_IN, T_PTR, ansbuf, MAXPACKET);
-	if (anslen < 0) {
-		memput(ansbuf, MAXPACKET);
-		return (NULL);
-	}
-	result = get1101mask(this, get1101answer(this, ansbuf, anslen, by_name,
-						 AF_INET, name, NULL, 0));
-	memput(ansbuf, MAXPACKET);
-	return (result);
-}
-
-static struct nwent *
-get1101byaddr(struct irs_nw *this, u_char *net, int len) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	char qbuf[sizeof "255.255.255.255.in-addr.arpa"];
-	struct nwent *result;
-	u_char *ansbuf;
-	int anslen;
-
-	if (len < 1 || len > 32) {
-		errno = EINVAL;
-		RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL);
-		return (NULL);
-	}
-	if (make1101inaddr(net, len, qbuf, sizeof qbuf) < 0)
-		return (NULL);
-	ansbuf = memget(MAXPACKET);
-	if (ansbuf == NULL) {
-		errno = ENOMEM;
-		RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL);
-		return (NULL);
-	}
-	anslen = res_nquery(pvt->res, qbuf, C_IN, T_PTR, ansbuf, MAXPACKET);
-	if (anslen < 0) {
-		memput(ansbuf, MAXPACKET);
-		return (NULL);
-	}
-	result = get1101mask(this, get1101answer(this, ansbuf, anslen, by_addr,
-						 AF_INET, NULL, net, len));
-	memput(ansbuf, MAXPACKET);
-	return (result);
-}
-
-static struct nwent *
-get1101answer(struct irs_nw *this,
-	      u_char *ansbuf, int anslen, enum by_what by_what,
-	      int af, const char *name, const u_char *addr, int addrlen)
-{
-	struct pvt *pvt = (struct pvt *)this->private;
-	int type, class, ancount, qdcount, haveanswer;
-	char *bp, *ep, **ap;
-	u_char *cp, *eom;
-	HEADER *hp;
-
-	/* Initialize, and parse header. */
-	eom = ansbuf + anslen;
-	if (ansbuf + HFIXEDSZ > eom) {
-		RES_SET_H_ERRNO(pvt->res, NO_RECOVERY);
-		return (NULL);
-	}
-	hp = (HEADER *)ansbuf;
-	cp = ansbuf + HFIXEDSZ;
-	qdcount = ntohs(hp->qdcount);
-	while (qdcount-- > 0) {
-		int n = dn_skipname(cp, eom);
-		cp += n + QFIXEDSZ;
-		if (n < 0 || cp > eom) {
-			RES_SET_H_ERRNO(pvt->res, NO_RECOVERY);
-			return (NULL);
-		}
-	}
-	ancount = ntohs(hp->ancount);
-	if (!ancount) {
-		if (hp->aa)
-			RES_SET_H_ERRNO(pvt->res, HOST_NOT_FOUND);
-		else
-			RES_SET_H_ERRNO(pvt->res, TRY_AGAIN);
-		return (NULL);
-	}
-
-	/* Prepare a return structure. */
-	bp = pvt->buf;
-	ep = pvt->buf + sizeof(pvt->buf);
-	pvt->net.n_name = NULL;
-	pvt->net.n_aliases = pvt->ali;
-	pvt->net.n_addrtype = af;
-	pvt->net.n_addr = NULL;
-	pvt->net.n_length = addrlen;
-
-	/* Save input key if given. */
-	switch (by_what) {
-	case by_name:
-		if (name != NULL) {
-			int n = strlen(name) + 1;
-
-			if (n > (ep - bp)) {
-				RES_SET_H_ERRNO(pvt->res, NO_RECOVERY);
-				return (NULL);
-			}
-			pvt->net.n_name = strcpy(bp, name);	/* (checked) */
-			bp += n;
-		}
-		break;
-	case by_addr:
-		if (addr != NULL && addrlen != 0) {
-			int n = addrlen / 8 + ((addrlen % 8) != 0);
-
-			if (INADDRSZ > (ep - bp)) {
-				RES_SET_H_ERRNO(pvt->res, NO_RECOVERY);
-				return (NULL);
-			}
-			memset(bp, 0, INADDRSZ);
-			memcpy(bp, addr, n);
-			pvt->net.n_addr = bp;
-			bp += INADDRSZ;
-		}
-		break;
-	default:
-		abort();
-	}
-
-	/* Parse the answer, collect aliases. */
-	ap = pvt->ali;
-	haveanswer = 0;
-	while (--ancount >= 0 && cp < eom) {
-		int n = dn_expand(ansbuf, eom, cp, bp, ep - bp);
-
-		cp += n;		/*%< Owner */
-		if (n < 0 || !maybe_dnok(pvt->res, bp) ||
-		    cp + 3 * INT16SZ + INT32SZ > eom) {
-			RES_SET_H_ERRNO(pvt->res, NO_RECOVERY);
-			return (NULL);
-		}
-		GETSHORT(type, cp);	/*%< Type */
-		GETSHORT(class, cp);	/*%< Class */
-		cp += INT32SZ;		/*%< TTL */
-		GETSHORT(n, cp);	/*%< RDLENGTH */
-		if (class == C_IN && type == T_PTR) {
-			int nn;
-
-			nn = dn_expand(ansbuf, eom, cp, bp, ep - bp);
-			if (nn < 0 || !maybe_hnok(pvt->res, bp) || nn != n) {
-				RES_SET_H_ERRNO(pvt->res, NO_RECOVERY);
-				return (NULL);
-			}
-			normalize_name(bp);
-			switch (by_what) {
-			case by_addr: {
-				if (pvt->net.n_name == NULL)
-					pvt->net.n_name = bp;
-				else if (ns_samename(pvt->net.n_name, bp) == 1)
-					break;
-				else
-					*ap++ = bp;
-				nn = strlen(bp) + 1;
-				bp += nn;
-				haveanswer++;
-				break;
-			    }
-			case by_name: {
-				u_int b1, b2, b3, b4;
-
-				if (pvt->net.n_addr != NULL ||
-				    sscanf(bp, "%u.%u.%u.%u.in-addr.arpa",
-					   &b1, &b2, &b3, &b4) != 4)
-					break;
-				if ((ep - bp) < INADDRSZ) {
-					RES_SET_H_ERRNO(pvt->res, NO_RECOVERY);
-					return (NULL);
-				}
-				pvt->net.n_addr = bp;
-				*bp++ = b4;
-				*bp++ = b3;
-				*bp++ = b2;
-				*bp++ = b1;
-				pvt->net.n_length = INADDRSZ * 8;
-				haveanswer++;
-			    }
-			}
-		}
-		cp += n;		/*%< RDATA */
-	}
-	if (!haveanswer) {
-		RES_SET_H_ERRNO(pvt->res, TRY_AGAIN);
-		return (NULL);
-	}
-	*ap = NULL;
-
-	return (&pvt->net);
-}
-
-static struct nwent *
-get1101mask(struct irs_nw *this, struct nwent *nwent) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	char qbuf[sizeof "255.255.255.255.in-addr.arpa"], owner[MAXDNAME];
-	int anslen, type, class, ancount, qdcount;
-	u_char *ansbuf, *cp, *eom;
-	HEADER *hp;
-
-	if (!nwent)
-		return (NULL);
-	if (make1101inaddr(nwent->n_addr, nwent->n_length, qbuf, sizeof qbuf)
-	    < 0) {
-		/* "First, do no harm." */
-		return (nwent);
-	}
-
-	ansbuf = memget(MAXPACKET);
-	if (ansbuf == NULL) {
-		errno = ENOMEM;
-		RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL);
-		return (NULL);
-	}
-	/* Query for the A RR that would hold this network's mask. */
-	anslen = res_nquery(pvt->res, qbuf, C_IN, T_A, ansbuf, MAXPACKET);
-	if (anslen < HFIXEDSZ) {
-		memput(ansbuf, MAXPACKET);
-		return (nwent);
-	}
-
-	/* Initialize, and parse header. */
-	hp = (HEADER *)ansbuf;
-	cp = ansbuf + HFIXEDSZ;
-	eom = ansbuf + anslen;
-	qdcount = ntohs(hp->qdcount);
-	while (qdcount-- > 0) {
-		int n = dn_skipname(cp, eom);
-		cp += n + QFIXEDSZ;
-		if (n < 0 || cp > eom) {
-			memput(ansbuf, MAXPACKET);
-			return (nwent);
-		}
-	}
-	ancount = ntohs(hp->ancount);
-
-	/* Parse the answer, collect aliases. */
-	while (--ancount >= 0 && cp < eom) {
-		int n = dn_expand(ansbuf, eom, cp, owner, sizeof owner);
-
-		if (n < 0 || !maybe_dnok(pvt->res, owner))
-			break;
-		cp += n;		/*%< Owner */
-		if (cp + 3 * INT16SZ + INT32SZ > eom)
-			break;
-		GETSHORT(type, cp);	/*%< Type */
-		GETSHORT(class, cp);	/*%< Class */
-		cp += INT32SZ;		/*%< TTL */
-		GETSHORT(n, cp);	/*%< RDLENGTH */
-		if (cp + n > eom)
-			break;
-		if (n == INADDRSZ && class == C_IN && type == T_A &&
-		    ns_samename(qbuf, owner) == 1) {
-			/* This A RR indicates the actual netmask. */
-			int nn, mm;
-
-			nwent->n_length = 0;
-			for (nn = 0; nn < INADDRSZ; nn++)
-				for (mm = 7; mm >= 0; mm--)
-					if (cp[nn] & (1 << mm))
-						nwent->n_length++;
-					else
-						break;
-		}
-		cp += n;		/*%< RDATA */
-	}
-	memput(ansbuf, MAXPACKET);
-	return (nwent);
-}
-
-static int
-make1101inaddr(const u_char *net, int bits, char *name, int size) {
-	int n, m;
-	char *ep;
-
-	ep = name + size;
-
-	/* Zero fill any whole bytes left out of the prefix. */
-	for (n = (32 - bits) / 8; n > 0; n--) {
-		if (ep - name < (int)(sizeof "0."))
-			goto emsgsize;
-		m = SPRINTF((name, "0."));
-		name += m;
-	}
-
-	/* Format the partial byte, if any, within the prefix. */
-	if ((n = bits % 8) != 0) {
-		if (ep - name < (int)(sizeof "255."))
-			goto emsgsize;
-		m = SPRINTF((name, "%u.",
-			     net[bits / 8] & ~((1 << (8 - n)) - 1)));
-		name += m;
-	}
-
-	/* Format the whole bytes within the prefix. */
-	for (n = bits / 8; n > 0; n--) {
-		if (ep - name < (int)(sizeof "255."))
-			goto emsgsize;
-		m = SPRINTF((name, "%u.", net[n - 1]));
-		name += m;
-	}
-
-	/* Add the static text. */
-	if (ep - name < (int)(sizeof "in-addr.arpa"))
-		goto emsgsize;
-	(void) SPRINTF((name, "in-addr.arpa"));
-	return (0);
-
- emsgsize:
-	errno = EMSGSIZE;
-	return (-1);
-}
-
-static void
-normalize_name(char *name) {
-	char *t;
-
-	/* Make lower case. */
-	for (t = name; *t; t++)
-		if (isascii((unsigned char)*t) && isupper((unsigned char)*t))
-			*t = tolower((*t)&0xff);
-
-	/* Remove trailing dots. */
-	while (t > name && t[-1] == '.')
-		*--t = '\0';
-}
-
-static int
-init(struct irs_nw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	
-	if (!pvt->res && !nw_res_get(this))
-		return (-1);
-	if (((pvt->res->options & RES_INIT) == 0U) &&
-	    res_ninit(pvt->res) == -1)
-		return (-1);
-	return (0);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/dns_p.h b/contrib/bind9/lib/bind/irs/dns_p.h
deleted file mode 100644
index a19ff2d..0000000
--- a/contrib/bind9/lib/bind/irs/dns_p.h
+++ /dev/null
@@ -1,52 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996-1999 by 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: dns_p.h,v 1.3.18.1 2005/04/27 05:00:55 sra Exp $
- */
-
-#ifndef _DNS_P_H_INCLUDED
-#define	_DNS_P_H_INCLUDED
-
-#define	maybe_ok(res, nm, ok) (((res)->options & RES_NOCHECKNAME) != 0U || \
-			       (ok)(nm) != 0)
-#define maybe_hnok(res, hn) maybe_ok((res), (hn), res_hnok)
-#define maybe_dnok(res, dn) maybe_ok((res), (dn), res_dnok)
-
-/*%
- * Object state.
- */
-struct dns_p {
-	void			*hes_ctx;
-	struct __res_state	*res;
-	void                    (*free_res) __P((void *));
-};
-
-/*
- * Methods.
- */
-
-extern struct irs_gr *	irs_dns_gr __P((struct irs_acc *));
-extern struct irs_pw *	irs_dns_pw __P((struct irs_acc *));
-extern struct irs_sv *	irs_dns_sv __P((struct irs_acc *));
-extern struct irs_pr *	irs_dns_pr __P((struct irs_acc *));
-extern struct irs_ho *	irs_dns_ho __P((struct irs_acc *));
-extern struct irs_nw *	irs_dns_nw __P((struct irs_acc *));
-
-#endif /*_DNS_P_H_INCLUDED*/
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/dns_pr.c b/contrib/bind9/lib/bind/irs/dns_pr.c
deleted file mode 100644
index 7582f85..0000000
--- a/contrib/bind9/lib/bind/irs/dns_pr.c
+++ /dev/null
@@ -1,268 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: dns_pr.c,v 1.4.18.1 2005/04/27 05:00:55 sra Exp $";
-#endif
-
-/* Imports */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <resolv.h>
-
-#include <stdio.h>
-#include <string.h>
-#include <netdb.h>
-#include <ctype.h>
-#include <stdlib.h>
-#include <errno.h>
-
-#include <isc/memcluster.h>
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "hesiod.h"
-#include "dns_p.h"
-
-/* Types. */
-
-struct pvt {
-	struct dns_p *		dns;
-	struct protoent		proto;
-	char *			prbuf;
-};
-
-/* Forward. */
-
-static void 			pr_close(struct irs_pr *);
-static struct protoent *	pr_byname(struct irs_pr *, const char *);
-static struct protoent *	pr_bynumber(struct irs_pr *, int);
-static struct protoent *	pr_next(struct irs_pr *);
-static void			pr_rewind(struct irs_pr *);
-static void			pr_minimize(struct irs_pr *);
-static struct __res_state *	pr_res_get(struct irs_pr *);
-static void			pr_res_set(struct irs_pr *,
-					   struct __res_state *,
-					   void (*)(void *));
-
-static struct protoent *	parse_hes_list(struct irs_pr *, char **);
-
-/* Public. */
-
-struct irs_pr *
-irs_dns_pr(struct irs_acc *this) {
-	struct dns_p *dns = (struct dns_p *)this->private;
-	struct pvt *pvt;
-	struct irs_pr *pr;
-
-	if (!dns->hes_ctx) {
-		errno = ENODEV;
-		return (NULL);
-	}
-	if (!(pvt = memget(sizeof *pvt))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	if (!(pr = memget(sizeof *pr))) {
-		memput(pvt, sizeof *pvt);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pr, 0x5e, sizeof *pr);
-	pvt->dns = dns;
-	pr->private = pvt;
-	pr->byname = pr_byname;
-	pr->bynumber = pr_bynumber;
-	pr->next = pr_next;
-	pr->rewind = pr_rewind;
-	pr->close = pr_close;
-	pr->minimize = pr_minimize;
-	pr->res_get = pr_res_get;
-	pr->res_set = pr_res_set;
-	return (pr);
-}
-
-/* Methods. */
-
-static void
-pr_close(struct irs_pr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (pvt->proto.p_aliases)
-		free(pvt->proto.p_aliases);
-	if (pvt->prbuf)
-		free(pvt->prbuf);
-
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-static struct protoent *
-pr_byname(struct irs_pr *this, const char *name) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct dns_p *dns = pvt->dns;
-	struct protoent *proto;
-	char **hes_list;
-
-	if (!(hes_list = hesiod_resolve(dns->hes_ctx, name, "protocol")))
-		return (NULL);
-
-	proto = parse_hes_list(this, hes_list);
-	hesiod_free_list(dns->hes_ctx, hes_list);
-	return (proto);
-}
-
-static struct protoent *
-pr_bynumber(struct irs_pr *this, int num) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct dns_p *dns = pvt->dns;
-	struct protoent *proto;
-	char numstr[16];
-	char **hes_list;
-
-	sprintf(numstr, "%d", num);
-	if (!(hes_list = hesiod_resolve(dns->hes_ctx, numstr, "protonum")))
-		return (NULL);
-	
-	proto = parse_hes_list(this, hes_list);
-	hesiod_free_list(dns->hes_ctx, hes_list);
-	return (proto);
-}
-
-static struct protoent *
-pr_next(struct irs_pr *this) {
-	UNUSED(this);
-	errno = ENODEV;
-	return (NULL);
-}
-
-static void
-pr_rewind(struct irs_pr *this) {
-	UNUSED(this);
-	/* NOOP */
-}
-
-static void
-pr_minimize(struct irs_pr *this) {
-	UNUSED(this);
-	/* NOOP */
-}
-
-static struct __res_state *
-pr_res_get(struct irs_pr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct dns_p *dns = pvt->dns;
-
-	return (__hesiod_res_get(dns->hes_ctx));
-}
-
-static void
-pr_res_set(struct irs_pr *this, struct __res_state * res,
-	   void (*free_res)(void *)) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct dns_p *dns = pvt->dns;
-
-	__hesiod_res_set(dns->hes_ctx, res, free_res);
-}
-
-/* Private. */
-
-static struct protoent *
-parse_hes_list(struct irs_pr *this, char **hes_list) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	char *p, *cp, **cpp, **new;
-	int num = 0;
-	int max = 0;
-	
-	for (cpp = hes_list; *cpp; cpp++) {
-		cp = *cpp;
-
-		/* Strip away comments, if any. */
-		if ((p = strchr(cp, '#')))
-			*p = 0;
-
-		/* Skip blank lines. */
-		p = cp;
-		while (*p && !isspace((unsigned char)*p))
-			p++;
-		if (!*p)
-			continue;
-
-		/* OK, we've got a live one.  Let's parse it for real. */
-		if (pvt->prbuf)
-			free(pvt->prbuf);
-		pvt->prbuf = strdup(cp);
-
-		p = pvt->prbuf;
-		pvt->proto.p_name = p;
-		while (*p && !isspace((unsigned char)*p))
-			p++;
-		if (!*p)
-			continue;
-		*p++ = '\0';
-
-		pvt->proto.p_proto = atoi(p);
-		while (*p && !isspace((unsigned char)*p))
-			p++;
-		if (*p)
-			*p++ = '\0';
-
-		while (*p) {
-			if ((num + 1) >= max || !pvt->proto.p_aliases) {
-				max += 10;
-				new = realloc(pvt->proto.p_aliases,
-					      max * sizeof(char *));
-				if (!new) {
-					errno = ENOMEM;
-					goto cleanup;
-				}
-				pvt->proto.p_aliases = new;
-			}
-			pvt->proto.p_aliases[num++] = p;
-			while (*p && !isspace((unsigned char)*p))
-				p++;
-			if (*p)
-				*p++ = '\0';
-		}
-		if (!pvt->proto.p_aliases)
-			pvt->proto.p_aliases = malloc(sizeof(char *));
-		if (!pvt->proto.p_aliases)
-			goto cleanup;
-		pvt->proto.p_aliases[num] = NULL;
-		return (&pvt->proto);
-	}
-	
- cleanup:
-	if (pvt->proto.p_aliases) {
-		free(pvt->proto.p_aliases);
-		pvt->proto.p_aliases = NULL;
-	}
-	if (pvt->prbuf) {
-		free(pvt->prbuf);
-		pvt->prbuf = NULL;
-	}
-	return (NULL);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/dns_pw.c b/contrib/bind9/lib/bind/irs/dns_pw.c
deleted file mode 100644
index 62c61d5..0000000
--- a/contrib/bind9/lib/bind/irs/dns_pw.c
+++ /dev/null
@@ -1,232 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: dns_pw.c,v 1.2.18.1 2005/04/27 05:00:55 sra Exp $";
-#endif
-
-#include "port_before.h"
-
-#ifndef WANT_IRS_PW
-static int __bind_irs_pw_unneeded;
-#else
-
-#include <stdio.h>
-#include <stdlib.h>
-#include <errno.h>
-#include <string.h>
-
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <resolv.h>
-
-#include <isc/memcluster.h>
-
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "hesiod.h"
-#include "dns_p.h"
-
-/* Types. */
-
-struct pvt {
-	struct dns_p *	dns;
-	struct passwd	passwd;
-	char *		pwbuf;
-};
-
-/* Forward. */
-
-static void 			pw_close(struct irs_pw *);
-static struct passwd *		pw_byname(struct irs_pw *, const char *);
-static struct passwd *		pw_byuid(struct irs_pw *, uid_t);
-static struct passwd *		pw_next(struct irs_pw *);
-static void 			pw_rewind(struct irs_pw *);
-static void			pw_minimize(struct irs_pw *);
-static struct __res_state *	pw_res_get(struct irs_pw *);
-static void			pw_res_set(struct irs_pw *,
-					   struct __res_state *,
-					   void (*)(void *));
-
-static struct passwd *		getpwcommon(struct irs_pw *, const char *,
-					    const char *);
-
-/* Public. */
-
-struct irs_pw *
-irs_dns_pw(struct irs_acc *this) {
-	struct dns_p *dns = (struct dns_p *)this->private;
-	struct irs_pw *pw;
-	struct pvt *pvt;
-
-	if (!dns || !dns->hes_ctx) {
-		errno = ENODEV;
-		return (NULL);
-	}
-	if (!(pvt = memget(sizeof *pvt))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	pvt->dns = dns;
-	if (!(pw = memget(sizeof *pw))) {
-		memput(pvt, sizeof *pvt);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pw, 0x5e, sizeof *pw);
-	pw->private = pvt;
-	pw->close = pw_close;
-	pw->byname = pw_byname;
-	pw->byuid = pw_byuid;
-	pw->next = pw_next;
-	pw->rewind = pw_rewind;
-	pw->minimize = pw_minimize;
-	pw->res_get = pw_res_get;
-	pw->res_set = pw_res_set;
-	return (pw);
-}
-
-/* Methods. */
-
-static void
-pw_close(struct irs_pw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (pvt->pwbuf)
-		free(pvt->pwbuf);
-
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-static struct passwd *
-pw_byname(struct irs_pw *this, const char *nam) {
-	return (getpwcommon(this, nam, "passwd"));
-}
-
-static struct passwd *
-pw_byuid(struct irs_pw *this, uid_t uid) {
-	char uidstr[16];
-
-	sprintf(uidstr, "%lu", (u_long)uid);
-	return (getpwcommon(this, uidstr, "uid"));
-}
-
-static struct passwd *
-pw_next(struct irs_pw *this) {
-	UNUSED(this);
-	errno = ENODEV;
-	return (NULL);
-}
-
-static void
-pw_rewind(struct irs_pw *this) {
-	UNUSED(this);
-	/* NOOP */
-}
-
-static void
-pw_minimize(struct irs_pw *this) {
-	UNUSED(this);
-	/* NOOP */
-}
-
-static struct __res_state *
-pw_res_get(struct irs_pw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct dns_p *dns = pvt->dns;
-
-	return (__hesiod_res_get(dns->hes_ctx));
-}
-
-static void
-pw_res_set(struct irs_pw *this, struct __res_state * res,
-	   void (*free_res)(void *)) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct dns_p *dns = pvt->dns;
-
-	__hesiod_res_set(dns->hes_ctx, res, free_res);
-}
-
-/* Private. */
-
-static struct passwd *
-getpwcommon(struct irs_pw *this, const char *arg, const char *type) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	char **hes_list, *cp;
-
-	if (!(hes_list = hesiod_resolve(pvt->dns->hes_ctx, arg, type)))
-		return (NULL);
-	if (!*hes_list) {
-		hesiod_free_list(pvt->dns->hes_ctx, hes_list);
-		errno = ENOENT;
-		return (NULL);
-	}
-
-	memset(&pvt->passwd, 0, sizeof pvt->passwd);
-	if (pvt->pwbuf)
-		free(pvt->pwbuf);
-	pvt->pwbuf = strdup(*hes_list);
-	hesiod_free_list(pvt->dns->hes_ctx, hes_list);
-
-	cp = pvt->pwbuf;
-	pvt->passwd.pw_name = cp;
-	if (!(cp = strchr(cp, ':')))
-		goto cleanup;
-	*cp++ = '\0';
-
-	pvt->passwd.pw_passwd = cp;
-	if (!(cp = strchr(cp, ':')))
-		goto cleanup;
-	*cp++ = '\0';
-	
-	pvt->passwd.pw_uid = atoi(cp);
-	if (!(cp = strchr(cp, ':')))
-		goto cleanup;
-	*cp++ = '\0';
-
-	pvt->passwd.pw_gid = atoi(cp);
-	if (!(cp = strchr(cp, ':')))
-		goto cleanup;
-	*cp++ = '\0';
-
-	pvt->passwd.pw_gecos = cp;
-	if (!(cp = strchr(cp, ':')))
-		goto cleanup;
-	*cp++ = '\0';
-
-	pvt->passwd.pw_dir = cp;
-	if (!(cp = strchr(cp, ':')))
-		goto cleanup;
-	*cp++ = '\0';
-
-	pvt->passwd.pw_shell = cp;
-	return (&pvt->passwd);
-	
- cleanup:
-	free(pvt->pwbuf);
-	pvt->pwbuf = NULL;
-	return (NULL);
-}
-
-#endif /* WANT_IRS_PW */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/dns_sv.c b/contrib/bind9/lib/bind/irs/dns_sv.c
deleted file mode 100644
index fcb25ac..0000000
--- a/contrib/bind9/lib/bind/irs/dns_sv.c
+++ /dev/null
@@ -1,300 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: dns_sv.c,v 1.4.18.1 2005/04/27 05:00:55 sra Exp $";
-#endif
-
-/* Imports */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <netinet/in.h>
-
-#include <stdio.h>
-#include <string.h>
-#include <netdb.h>
-#include <ctype.h>
-#include <stdlib.h>
-#include <errno.h>
-
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <resolv.h>
-
-#include <isc/memcluster.h>
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "hesiod.h"
-#include "dns_p.h"
-
-/* Definitions */
-
-struct pvt {
-	struct dns_p *		dns;
-	struct servent		serv;
-	char *			svbuf;
-	struct __res_state *	res;
-	void			(*free_res)(void *);
-};
-
-/* Forward. */
-
-static void 			sv_close(struct irs_sv *);
-static struct servent *		sv_byname(struct irs_sv *,
-					  const char *, const char *);
-static struct servent *		sv_byport(struct irs_sv *, int, const char *);
-static struct servent *		sv_next(struct irs_sv *);
-static void			sv_rewind(struct irs_sv *);
-static void			sv_minimize(struct irs_sv *);
-#ifdef SV_RES_SETGET
-static struct __res_state *	sv_res_get(struct irs_sv *);
-static void			sv_res_set(struct irs_sv *,
-					   struct __res_state *,
-					   void (*)(void *));
-#endif
-
-static struct servent *		parse_hes_list(struct irs_sv *,
-					       char **, const char *);
-
-/* Public */
-
-struct irs_sv *
-irs_dns_sv(struct irs_acc *this) {
-	struct dns_p *dns = (struct dns_p *)this->private;
-	struct irs_sv *sv;
-	struct pvt *pvt;
-
-	if (!dns || !dns->hes_ctx) {
-		errno = ENODEV;
-		return (NULL);
-	}
-	if (!(pvt = memget(sizeof *pvt))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	pvt->dns = dns;
-	if (!(sv = memget(sizeof *sv))) {
-		memput(pvt, sizeof *pvt);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(sv, 0x5e, sizeof *sv);
-	sv->private = pvt;
-	sv->byname = sv_byname;
-	sv->byport = sv_byport;
-	sv->next = sv_next;
-	sv->rewind = sv_rewind;
-	sv->close = sv_close;
-	sv->minimize = sv_minimize;
-#ifdef SV_RES_SETGET
-	sv->res_get = sv_res_get;
-	sv->res_set = sv_res_set;
-#else
-	sv->res_get = NULL; /*%< sv_res_get; */
-	sv->res_set = NULL; /*%< sv_res_set; */
-#endif
-	return (sv);
-}
-
-/* Methods */
-
-static void
-sv_close(struct irs_sv *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (pvt->serv.s_aliases)
-		free(pvt->serv.s_aliases);
-	if (pvt->svbuf)
-		free(pvt->svbuf);
-
-	if (pvt->res && pvt->free_res)
-		(*pvt->free_res)(pvt->res);
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-static struct servent *
-sv_byname(struct irs_sv *this, const char *name, const char *proto) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct dns_p *dns = pvt->dns;
-	struct servent *s;
-	char **hes_list;
-
-	if (!(hes_list = hesiod_resolve(dns->hes_ctx, name, "service")))
-		return (NULL);
-
-	s = parse_hes_list(this, hes_list, proto);
-	hesiod_free_list(dns->hes_ctx, hes_list);
-	return (s);
-}
-
-static struct servent *
-sv_byport(struct irs_sv *this, int port, const char *proto) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct dns_p *dns = pvt->dns;
-	struct servent *s;
-	char portstr[16];
-	char **hes_list;
-
-	sprintf(portstr, "%d", ntohs(port));
-	if (!(hes_list = hesiod_resolve(dns->hes_ctx, portstr, "port")))
-		return (NULL);
-	
-	s = parse_hes_list(this, hes_list, proto);
-	hesiod_free_list(dns->hes_ctx, hes_list);
-	return (s);
-}
-
-static struct servent *
-sv_next(struct irs_sv *this) {
-	UNUSED(this);
-	errno = ENODEV;
-	return (NULL);
-}
-
-static void
-sv_rewind(struct irs_sv *this) {
-	UNUSED(this);
-	/* NOOP */
-}
-
-/* Private */
-
-static struct servent *
-parse_hes_list(struct irs_sv *this, char **hes_list, const char *proto) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	char *p, *cp, **cpp, **new;
-	int proto_len;
-	int num = 0;
-	int max = 0;
-	
-	for (cpp = hes_list; *cpp; cpp++) {
-		cp = *cpp;
-
-		/* Strip away comments, if any. */
-		if ((p = strchr(cp, '#')))
-			*p = 0;
-
-		/* Check to make sure the protocol matches. */
-		p = cp;
-		while (*p && !isspace((unsigned char)*p))
-			p++;
-		if (!*p)
-			continue;
-		if (proto) {
-		     proto_len = strlen(proto);
-		     if (strncasecmp(++p, proto, proto_len) != 0)
-			  continue;
-		     if (p[proto_len] && !isspace(p[proto_len]&0xff))
-			  continue;
-		}
-		/* OK, we've got a live one.  Let's parse it for real. */
-		if (pvt->svbuf)
-			free(pvt->svbuf);
-		pvt->svbuf = strdup(cp);
-
-		p = pvt->svbuf;
-		pvt->serv.s_name = p;
-		while (*p && !isspace(*p&0xff))
-			p++;
-		if (!*p)
-			continue;
-		*p++ = '\0';
-
-		pvt->serv.s_proto = p;
-		while (*p && !isspace(*p&0xff))
-			p++;
-		if (!*p)
-			continue;
-		*p++ = '\0';
-
-		pvt->serv.s_port = htons((u_short) atoi(p));
-		while (*p && !isspace(*p&0xff))
-			p++;
-		if (*p)
-			*p++ = '\0';
-
-		while (*p) {
-			if ((num + 1) >= max || !pvt->serv.s_aliases) {
-				max += 10;
-				new = realloc(pvt->serv.s_aliases,
-					      max * sizeof(char *));
-				if (!new) {
-					errno = ENOMEM;
-					goto cleanup;
-				}
-				pvt->serv.s_aliases = new;
-			}
-			pvt->serv.s_aliases[num++] = p;
-			while (*p && !isspace(*p&0xff))
-				p++;
-			if (*p)
-				*p++ = '\0';
-		}
-		if (!pvt->serv.s_aliases)
-			pvt->serv.s_aliases = malloc(sizeof(char *));
-		if (!pvt->serv.s_aliases)
-			goto cleanup;
-		pvt->serv.s_aliases[num] = NULL;
-		return (&pvt->serv);
-	}
-	
- cleanup:
-	if (pvt->serv.s_aliases) {
-		free(pvt->serv.s_aliases);
-		pvt->serv.s_aliases = NULL;
-	}
-	if (pvt->svbuf) {
-		free(pvt->svbuf);
-		pvt->svbuf = NULL;
-	}
-	return (NULL);
-}
-
-static void
-sv_minimize(struct irs_sv *this) {
-	UNUSED(this);
-	/* NOOP */
-}
-
-#ifdef SV_RES_SETGET
-static struct __res_state *
-sv_res_get(struct irs_sv *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct dns_p *dns = pvt->dns;
-
-	return (__hesiod_res_get(dns->hes_ctx));
-}
-
-static void
-sv_res_set(struct irs_sv *this, struct __res_state * res,
-	   void (*free_res)(void *)) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct dns_p *dns = pvt->dns;
-
-	__hesiod_res_set(dns->hes_ctx, res, free_res);
-}
-#endif
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/gai_strerror.c b/contrib/bind9/lib/bind/irs/gai_strerror.c
deleted file mode 100644
index 9ca1c4b..0000000
--- a/contrib/bind9/lib/bind/irs/gai_strerror.c
+++ /dev/null
@@ -1,105 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 2001 by 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.
- */
-
-#include <port_before.h>
-#include <netdb.h>
-#include <port_after.h>
-
-#ifdef DO_PTHREADS
-#include <pthread.h>
-#include <stdlib.h>
-#endif
-
-static const char *gai_errlist[] = {
-	"no error",
-	"address family not supported for name",/*%< EAI_ADDRFAMILY */
-	"temporary failure",			/*%< EAI_AGAIN */
-	"invalid flags",			/*%< EAI_BADFLAGS */
-	"permanent failure",			/*%< EAI_FAIL */
-	"address family not supported",		/*%< EAI_FAMILY */
-	"memory failure",			/*%< EAI_MEMORY */
-	"no address",				/*%< EAI_NODATA */
-	"unknown name or service",		/*%< EAI_NONAME */
-	"service not supported for socktype",	/*%< EAI_SERVICE */
-	"socktype not supported",		/*%< EAI_SOCKTYPE */
-	"system failure",			/*%< EAI_SYSTEM */
-	"bad hints",				/*%< EAI_BADHINTS */
-	"bad protocol",				/*%< EAI_PROTOCOL */
-	"unknown error"				/*%< Must be last. */
-};
-
-static const int gai_nerr = (sizeof(gai_errlist)/sizeof(*gai_errlist));
-
-#define EAI_BUFSIZE 128
-
-const char *
-gai_strerror(int ecode) {
-#ifndef DO_PTHREADS
-	static char buf[EAI_BUFSIZE];
-#else	/* DO_PTHREADS */
-#ifndef LIBBIND_MUTEX_INITIALIZER
-#define LIBBIND_MUTEX_INITIALIZER PTHREAD_MUTEX_INITIALIZER
-#endif
-	static pthread_mutex_t lock = LIBBIND_MUTEX_INITIALIZER;
-	static pthread_key_t key;
-	static int once = 0;
-	char *buf;
-#endif
-
-	if (ecode >= 0 && ecode < (gai_nerr - 1))
-		return (gai_errlist[ecode]);
-
-#ifdef DO_PTHREADS
-        if (!once) {
-                if (pthread_mutex_lock(&lock) != 0)
-			goto unknown;
-                if (!once) {
-                        if (pthread_key_create(&key, free) != 0) {
-				(void)pthread_mutex_unlock(&lock);
-				goto unknown;
-			}
-			once = 1;
-		}
-                if (pthread_mutex_unlock(&lock) != 0)
-			goto unknown;
-        }
-
-	buf = pthread_getspecific(key);
-        if (buf == NULL) {
-		buf = malloc(EAI_BUFSIZE);
-                if (buf == NULL)
-                        goto unknown;
-                if (pthread_setspecific(key, buf) != 0) {
-			free(buf);
-			goto unknown;
-		}
-        }
-#endif
-	/* 
-	 * XXX This really should be snprintf(buf, EAI_BUFSIZE, ...).
-	 * It is safe until message catalogs are used.
-	 */
-	sprintf(buf, "%s: %d", gai_errlist[gai_nerr - 1], ecode);
-	return (buf);
-
-#ifdef DO_PTHREADS
- unknown:
-	return ("unknown error");
-#endif
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/gen.c b/contrib/bind9/lib/bind/irs/gen.c
deleted file mode 100644
index 8e9146e..0000000
--- a/contrib/bind9/lib/bind/irs/gen.c
+++ /dev/null
@@ -1,433 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996-1999 by 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.
- */
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: gen.c,v 1.5.18.2 2005/04/27 05:00:56 sra Exp $";
-#endif
-
-/*! \file
- * \brief
- * this is the top level dispatcher
- *
- * The dispatcher is implemented as an accessor class; it is an
- * accessor class that calls other accessor classes, as controlled by a
- * configuration file.
- * 
- * A big difference between this accessor class and others is that the
- * map class initializers are NULL, and the map classes are already
- * filled in with method functions that will do the right thing.
- */
-
-/* Imports */
-
-#include "port_before.h"
-
-#include <isc/assertions.h>
-#include <ctype.h>
-#include <errno.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-
-#include <sys/types.h>
-#include <netinet/in.h> 
-#include <arpa/nameser.h>
-#include <resolv.h>
-
-#include <isc/memcluster.h>
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "gen_p.h"
-
-/* Definitions */
-
-struct nameval {
-	const char *	name;
-	int		val;
-};
-
-static const struct nameval acc_names[irs_nacc+1] = {
-	{ "local", irs_lcl },
-	{ "dns", irs_dns },
-	{ "nis", irs_nis },
-	{ "irp", irs_irp },
-	{ NULL, irs_nacc }
-};
-
-typedef struct irs_acc *(*accinit) __P((const char *options));
-
-static const accinit accs[irs_nacc+1] = {
-	irs_lcl_acc,
-	irs_dns_acc,
-#ifdef WANT_IRS_NIS
-	irs_nis_acc,
-#else
-	NULL,
-#endif
-	irs_irp_acc,
-	NULL
-};
-
-static const struct nameval map_names[irs_nmap+1] = {
-	{ "group", irs_gr },
-	{ "passwd", irs_pw },
-	{ "services", irs_sv },
-	{ "protocols", irs_pr },
-	{ "hosts", irs_ho },
-	{ "networks", irs_nw },
-	{ "netgroup", irs_ng },
-	{ NULL, irs_nmap }
-};
-
-static const struct nameval option_names[] = {
-	{ "merge", IRS_MERGE },
-	{ "continue", IRS_CONTINUE },
-	{ NULL, 0 }
-};
-
-/* Forward */
-
-static void		gen_close(struct irs_acc *);
-static struct __res_state * gen_res_get(struct irs_acc *);
-static void		gen_res_set(struct irs_acc *, struct __res_state *,
-				    void (*)(void *));
-static int		find_name(const char *, const struct nameval nv[]);
-static void 		init_map_rules(struct gen_p *, const char *conf_file);
-static struct irs_rule *release_rule(struct irs_rule *);
-static int		add_rule(struct gen_p *,
-				 enum irs_map_id, enum irs_acc_id,
-				 const char *);
-
-/* Public */
-
-struct irs_acc *
-irs_gen_acc(const char *options, const char *conf_file) {
-	struct irs_acc *acc;
-	struct gen_p *irs;
-		
-	if (!(acc = memget(sizeof *acc))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(acc, 0x5e, sizeof *acc);
-	if (!(irs = memget(sizeof *irs))) {
-		errno = ENOMEM;
-		memput(acc, sizeof *acc);
-		return (NULL);
-	}
-	memset(irs, 0x5e, sizeof *irs);
-	irs->options = strdup(options);
-	irs->res = NULL;
-	irs->free_res = NULL;
-	memset(irs->accessors, 0, sizeof irs->accessors);
-	memset(irs->map_rules, 0, sizeof irs->map_rules);
-	init_map_rules(irs, conf_file);
-	acc->private = irs;
-#ifdef WANT_IRS_GR
-	acc->gr_map = irs_gen_gr;
-#else
-	acc->gr_map = NULL;
-#endif
-#ifdef WANT_IRS_PW
-	acc->pw_map = irs_gen_pw;
-#else
-	acc->pw_map = NULL;
-#endif
-	acc->sv_map = irs_gen_sv;
-	acc->pr_map = irs_gen_pr;
-	acc->ho_map = irs_gen_ho;
-	acc->nw_map = irs_gen_nw;
-	acc->ng_map = irs_gen_ng;
-	acc->res_get = gen_res_get;
-	acc->res_set = gen_res_set;
-	acc->close = gen_close;
-	return (acc);
-}
-
-/* Methods */
-
-static struct __res_state *
-gen_res_get(struct irs_acc *this) {
-	struct gen_p *irs = (struct gen_p *)this->private;
-
-	if (irs->res == NULL) {
-		struct __res_state *res;
-		res = (struct __res_state *)malloc(sizeof *res);
-		if (res == NULL)
-			return (NULL);
-		memset(res, 0, sizeof *res);
-		gen_res_set(this, res, free);
-	}
-
-	if (((irs->res->options & RES_INIT) == 0U) && res_ninit(irs->res) < 0)
-		return (NULL);
-
-	return (irs->res);
-}
-
-static void
-gen_res_set(struct irs_acc *this, struct __res_state *res,
-	    void (*free_res)(void *)) {
-	struct gen_p *irs = (struct gen_p *)this->private;
-#if 0
-	struct irs_rule *rule;
-	struct irs_ho *ho;
-	struct irs_nw *nw;
-#endif
-
-	if (irs->res && irs->free_res) {
-		res_nclose(irs->res);
-		(*irs->free_res)(irs->res);
-	}
-
-	irs->res = res;
-	irs->free_res = free_res;
-
-#if 0
-	for (rule = irs->map_rules[irs_ho]; rule; rule = rule->next) {
-                ho = rule->inst->ho;
-
-                (*ho->res_set)(ho, res, NULL);
-	}
-	for (rule = irs->map_rules[irs_nw]; rule; rule = rule->next) {
-                nw = rule->inst->nw;
-
-                (*nw->res_set)(nw, res, NULL);
-	}
-#endif
-}
-
-static void
-gen_close(struct irs_acc *this) {
-	struct gen_p *irs = (struct gen_p *)this->private;
-	int n;
-	
-	/* Search rules. */
-	for (n = 0; n < irs_nmap; n++)
-		while (irs->map_rules[n] != NULL)
-			irs->map_rules[n] = release_rule(irs->map_rules[n]);
-
-	/* Access methods. */
-	for (n = 0; n < irs_nacc; n++) {
-		/* Map objects. */
-		if (irs->accessors[n].gr != NULL)
-			(*irs->accessors[n].gr->close)(irs->accessors[n].gr);
-		if (irs->accessors[n].pw != NULL)
-			(*irs->accessors[n].pw->close)(irs->accessors[n].pw);
-		if (irs->accessors[n].sv != NULL)
-			(*irs->accessors[n].sv->close)(irs->accessors[n].sv);
-		if (irs->accessors[n].pr != NULL)
-			(*irs->accessors[n].pr->close)(irs->accessors[n].pr);
-		if (irs->accessors[n].ho != NULL)
-			(*irs->accessors[n].ho->close)(irs->accessors[n].ho);
-		if (irs->accessors[n].nw != NULL)
-			(*irs->accessors[n].nw->close)(irs->accessors[n].nw);
-		if (irs->accessors[n].ng != NULL)
-			(*irs->accessors[n].ng->close)(irs->accessors[n].ng);
-		/* Enclosing accessor. */
-		if (irs->accessors[n].acc != NULL)
-			(*irs->accessors[n].acc->close)(irs->accessors[n].acc);
-	}
-
-	/* The options string was strdup'd. */
-	free((void*)irs->options);
-
-	if (irs->res && irs->free_res)
-		(*irs->free_res)(irs->res);
-
-	/* The private data container. */
-	memput(irs, sizeof *irs);
-
-	/* The object. */
-	memput(this, sizeof *this);
-}
-
-/* Private */
-
-static int
-find_name(const char *name, const struct nameval names[]) {
-	int n;
-
-	for (n = 0; names[n].name != NULL; n++)
-		if (strcmp(name, names[n].name) == 0)
-			return (names[n].val);
-	return (-1);
-}
-
-static struct irs_rule *
-release_rule(struct irs_rule *rule) {
-	struct irs_rule *next = rule->next;
-
-	memput(rule, sizeof *rule);
-	return (next);
-}
-
-static int
-add_rule(struct gen_p *irs,
-	 enum irs_map_id map, enum irs_acc_id acc,
-	 const char *options)
-{
-	struct irs_rule **rules, *last, *tmp, *new;
-	struct irs_inst *inst;
-	const char *cp;
-	int n;
-
-#ifndef WANT_IRS_GR
-	if (map == irs_gr)
-		return (-1);
-#endif
-#ifndef WANT_IRS_PW
-	if (map == irs_pw)
-		return (-1);
-#endif
-#ifndef WANT_IRS_NIS
-	if (acc == irs_nis)
-		return (-1);
-#endif
-	new = memget(sizeof *new);
-	if (new == NULL)
-		return (-1);
-	memset(new, 0x5e, sizeof *new);
-	new->next = NULL;
-
-	new->inst = &irs->accessors[acc];
-
-	new->flags = 0;
-	cp = options;
-	while (cp && *cp) {
-		char option[50], *next;
-
-		next = strchr(cp, ',');
-		if (next)
-			n = next++ - cp;
-		else
-			n = strlen(cp);
-		if ((size_t)n > sizeof option - 1)
-			n = sizeof option - 1;
-		strncpy(option, cp, n);
-		option[n] = '\0';
-
-		n = find_name(option, option_names);
-		if (n >= 0)
-			new->flags |= n;
-
-		cp = next;
-	}
-
-	rules = &irs->map_rules[map];
-	for (last = NULL, tmp = *rules;
-	     tmp != NULL;
-	     last = tmp, tmp = tmp->next)
-		(void)NULL;
-	if (last == NULL)
-		*rules = new;
-	else
-		last->next = new;
-
-	/* Try to instantiate map accessors for this if necessary & approp. */
-	inst = &irs->accessors[acc];
-	if (inst->acc == NULL && accs[acc] != NULL)
-		inst->acc = (*accs[acc])(irs->options);
-	if (inst->acc != NULL) {
-		if (inst->gr == NULL && inst->acc->gr_map != NULL)
-			inst->gr = (*inst->acc->gr_map)(inst->acc);
-		if (inst->pw == NULL && inst->acc->pw_map != NULL)
-			inst->pw = (*inst->acc->pw_map)(inst->acc);
-		if (inst->sv == NULL && inst->acc->sv_map != NULL)
-			inst->sv = (*inst->acc->sv_map)(inst->acc);
-		if (inst->pr == NULL && inst->acc->pr_map != NULL)
-			inst->pr = (*inst->acc->pr_map)(inst->acc);
-		if (inst->ho == NULL && inst->acc->ho_map != NULL)
-			inst->ho = (*inst->acc->ho_map)(inst->acc);
-		if (inst->nw == NULL && inst->acc->nw_map != NULL)
-			inst->nw = (*inst->acc->nw_map)(inst->acc);
-		if (inst->ng == NULL && inst->acc->ng_map != NULL)
-			inst->ng = (*inst->acc->ng_map)(inst->acc);
-	}
-
-	return (0);
-}
-
-static void
-default_map_rules(struct gen_p *irs) {
-	/* Install time honoured and proved BSD style rules as default. */
-	add_rule(irs, irs_gr, irs_lcl, "");
-	add_rule(irs, irs_pw, irs_lcl, "");
-	add_rule(irs, irs_sv, irs_lcl, "");
-	add_rule(irs, irs_pr, irs_lcl, "");
-	add_rule(irs, irs_ho, irs_dns, "continue");
-	add_rule(irs, irs_ho, irs_lcl, "");
-	add_rule(irs, irs_nw, irs_dns, "continue");
-	add_rule(irs, irs_nw, irs_lcl, "");
-	add_rule(irs, irs_ng, irs_lcl, "");
-}
-
-static void
-init_map_rules(struct gen_p *irs, const char *conf_file) {
-	char line[1024], pattern[40], mapname[20], accname[20], options[100];
-	FILE *conf;
-
-	if (conf_file == NULL) 
-		conf_file = _PATH_IRS_CONF ;
-
-	/* A conf file of "" means compiled in defaults. Irpd wants this */
-	if (conf_file[0] == '\0' || (conf = fopen(conf_file, "r")) == NULL) {
-		default_map_rules(irs);
-		return;
-	}
-	(void) sprintf(pattern, "%%%lus %%%lus %%%lus\n",
-		       (unsigned long)sizeof mapname,
-		       (unsigned long)sizeof accname,
-		       (unsigned long)sizeof options);
-	while (fgets(line, sizeof line, conf)) {
-		enum irs_map_id map;
-		enum irs_acc_id acc;
-		char *tmp;
-		int n;
-
-		for (tmp = line;
-		     isascii((unsigned char)*tmp) &&
-		     isspace((unsigned char)*tmp);
-		     tmp++)
-			(void)NULL;
-		if (*tmp == '#' || *tmp == '\n' || *tmp == '\0')
-			continue;
-		n = sscanf(tmp, pattern, mapname, accname, options);
-		if (n < 2)
-			continue;
-		if (n < 3)
-			options[0] = '\0';
-
-		n = find_name(mapname, map_names);
-		INSIST(n < irs_nmap);
-		if (n < 0)
-			continue;
-		map = (enum irs_map_id) n;
-
-		n = find_name(accname, acc_names);
-		INSIST(n < irs_nacc);
-		if (n < 0)
-			continue;
-		acc = (enum irs_acc_id) n;
-
-		add_rule(irs, map, acc, options);
-	}
-	fclose(conf);
-}
diff --git a/contrib/bind9/lib/bind/irs/gen_gr.c b/contrib/bind9/lib/bind/irs/gen_gr.c
deleted file mode 100644
index 0829ed8..0000000
--- a/contrib/bind9/lib/bind/irs/gen_gr.c
+++ /dev/null
@@ -1,493 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996-1999 by 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.
- */
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: gen_gr.c,v 1.6.18.2 2005/04/27 05:00:56 sra Exp $";
-#endif
-
-/* Imports */
-
-#include "port_before.h"
-
-#ifndef WANT_IRS_GR
-static int __bind_irs_gr_unneeded;
-#else
-
-#include <sys/types.h>
-
-#include <isc/assertions.h>
-#include <errno.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <resolv.h>
-
-#include <isc/memcluster.h>
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "gen_p.h"
-
-/* Definitions */
-
-struct pvt {
-	struct irs_rule *	rules;
-	struct irs_rule *	rule;
-	struct irs_gr *		gr;
-	/*
-	 * Need space to store the entries read from the group file.
-	 * The members list also needs space per member, and the
-	 * strings making up the user names must be allocated
-	 * somewhere.  Rather than doing lots of small allocations,
-	 * we keep one buffer and resize it as needed.
-	 */
-	struct group		group;
-	size_t			nmemb;    /*%< Malloc'd max index of gr_mem[]. */
-	char *			membuf;
-	size_t			membufsize;
-	struct __res_state *	res;
-	void			(*free_res)(void *);
-};
-
-/* Forward */
-
-static void		gr_close(struct irs_gr *);
-static struct group *	gr_next(struct irs_gr *);
-static struct group *	gr_byname(struct irs_gr *, const char *);
-static struct group *	gr_bygid(struct irs_gr *, gid_t);
-static void		gr_rewind(struct irs_gr *);
-static int		gr_list(struct irs_gr *, const char *,
-				gid_t, gid_t *, int *);
-static void		gr_minimize(struct irs_gr *);
-static struct __res_state * gr_res_get(struct irs_gr *);
-static void		gr_res_set(struct irs_gr *,
-				      struct __res_state *,
-				      void (*)(void *));
-
-static int		grmerge(struct irs_gr *gr, const struct group *src,
-				int preserve);
-
-static int		countvec(char **vec);
-static int		isnew(char **old, char *new);
-static int		countnew(char **old, char **new);
-static size_t		sizenew(char **old, char **new);
-static int		newgid(int, gid_t *, gid_t);
-
-/* Macros */
-
-#define FREE_IF(x) do { if ((x) != NULL) { free(x); (x) = NULL; } } while (0)
-
-/* Public */
-
-struct irs_gr *
-irs_gen_gr(struct irs_acc *this) {
-	struct gen_p *accpvt = (struct gen_p *)this->private;
-	struct irs_gr *gr;
-	struct pvt *pvt;
-
-	if (!(gr = memget(sizeof *gr))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(gr, 0x5e, sizeof *gr);
-	if (!(pvt = memget(sizeof *pvt))) {
-		memput(gr, sizeof *gr);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	pvt->rules = accpvt->map_rules[irs_gr];
-	pvt->rule = pvt->rules;
-	gr->private = pvt;
-	gr->close = gr_close;
-	gr->next = gr_next;
-	gr->byname = gr_byname;
-	gr->bygid = gr_bygid;
-	gr->rewind = gr_rewind;
-	gr->list = gr_list;
-	gr->minimize = gr_minimize;
-	gr->res_get = gr_res_get;
-	gr->res_set = gr_res_set;
-	return (gr);
-}
-
-/* Methods. */
-
-static void
-gr_close(struct irs_gr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-static struct group *
-gr_next(struct irs_gr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct group *rval;
-	struct irs_gr *gr;
-
-	while (pvt->rule) {
-		gr = pvt->rule->inst->gr;
-		rval = (*gr->next)(gr);
-		if (rval)
-			return (rval);
-		if (!(pvt->rule->flags & IRS_CONTINUE))
-			break;
-		pvt->rule = pvt->rule->next;
-		if (pvt->rule) {
-			gr = pvt->rule->inst->gr;
-			(*gr->rewind)(gr);
-		}
-	}
-	return (NULL);
-}
-
-static struct group *
-gr_byname(struct irs_gr *this, const char *name) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-	struct group *tval;
-	struct irs_gr *gr;
-	int dirty;
-
-	dirty = 0;
-	for (rule = pvt->rules; rule; rule = rule->next) {
-		gr = rule->inst->gr;
-		tval = (*gr->byname)(gr, name);
-		if (tval) {
-			if (!grmerge(this, tval, dirty++))
-				return (NULL);
-			if (!(rule->flags & IRS_MERGE))
-				break;
-		} else {
-			if (!(rule->flags & IRS_CONTINUE))
-				break;
-		}
-	}
-	if (dirty)
-		return (&pvt->group);
-	return (NULL);
-}
-
-static struct group *
-gr_bygid(struct irs_gr *this, gid_t gid) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-	struct group *tval;
-	struct irs_gr *gr;
-	int dirty;
-
-	dirty = 0;
-	for (rule = pvt->rules; rule; rule = rule->next) {
-		gr = rule->inst->gr;
-		tval = (*gr->bygid)(gr, gid);
-		if (tval) {
-			if (!grmerge(this, tval, dirty++))
-				return (NULL);
-			if (!(rule->flags & IRS_MERGE))
-				break;
-		} else {
-			if (!(rule->flags & IRS_CONTINUE))
-				break;
-		}
-	}
-	if (dirty)
-		return (&pvt->group);
-	return (NULL);
-}
-
-static void
-gr_rewind(struct irs_gr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_gr *gr;
-
-	pvt->rule = pvt->rules;
-	if (pvt->rule) {
-		gr = pvt->rule->inst->gr;
-		(*gr->rewind)(gr);
-	}
-}
-
-static int
-gr_list(struct irs_gr *this, const char *name,
-	gid_t basegid, gid_t *groups, int *ngroups)
-{
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-	struct irs_gr *gr;
-	int t_ngroups, maxgroups;
-	gid_t *t_groups;
-	int n, t, rval = 0;
-
-	maxgroups = *ngroups;
-	*ngroups = 0;
-	t_groups = (gid_t *)malloc(maxgroups * sizeof(gid_t));
-	if (!t_groups) {
-		errno = ENOMEM;
-		return (-1);
-	}
-
-	for (rule = pvt->rules; rule; rule = rule->next) {
-		t_ngroups = maxgroups;
-		gr = rule->inst->gr;
-		t = (*gr->list)(gr, name, basegid, t_groups, &t_ngroups);
-		for (n = 0; n < t_ngroups; n++) {
-			if (newgid(*ngroups, groups, t_groups[n])) {
-				if (*ngroups == maxgroups) {
-					rval = -1;
-					goto done;
-				}
-				groups[(*ngroups)++] = t_groups[n];
-			}
-		}
-		if (t == 0) {
-			if (!(rule->flags & IRS_MERGE))
-				break;
-		} else {
-			if (!(rule->flags & IRS_CONTINUE))
-				break;
-		}
-	}
- done:
-	free(t_groups);
-	return (rval);
-}
-
-static void
-gr_minimize(struct irs_gr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-
-	for (rule = pvt->rules; rule != NULL; rule = rule->next) {
-		struct irs_gr *gr = rule->inst->gr;
-
-		(*gr->minimize)(gr);
-	}
-}
-
-static struct __res_state *
-gr_res_get(struct irs_gr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (!pvt->res) {
-		struct __res_state *res;
-		res = (struct __res_state *)malloc(sizeof *res);
-		if (!res) {
-			errno = ENOMEM;
-			return (NULL);
-		}
-		memset(res, 0, sizeof *res);
-		gr_res_set(this, res, free);
-	}
-
-	return (pvt->res);
-}
-
-static void
-gr_res_set(struct irs_gr *this, struct __res_state *res,
-		void (*free_res)(void *)) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-
-	if (pvt->res && pvt->free_res) {
-		res_nclose(pvt->res);
-		(*pvt->free_res)(pvt->res);
-	}
-
-	pvt->res = res;
-	pvt->free_res = free_res;
-
-	for (rule = pvt->rules; rule != NULL; rule = rule->next) {
-		struct irs_gr *gr = rule->inst->gr;
-
-		if (gr->res_set)
-			(*gr->res_set)(gr, pvt->res, NULL);
-	}
-}
-
-/* Private. */
-
-static int
-grmerge(struct irs_gr *this, const struct group *src, int preserve) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	char *cp, **m, **p, *oldmembuf, *ep;
-	int n, ndst, nnew;
-	size_t used;
-
-	if (!preserve) {
-		pvt->group.gr_gid = src->gr_gid;
-		if (pvt->nmemb < 1) {
-			m = malloc(sizeof *m);
-			if (m == NULL) {
-				/* No harm done, no work done. */
-				return (0);
-			}
-			pvt->group.gr_mem = m;
-			pvt->nmemb = 1;
-		}
-		pvt->group.gr_mem[0] = NULL;
-	}
-	ndst = countvec(pvt->group.gr_mem);
-	nnew = countnew(pvt->group.gr_mem, src->gr_mem);
-
-	/*
-	 * Make sure destination member array is large enough.
-	 * p points to new portion.
-	 */
-	n = ndst + nnew + 1;
-	if ((size_t)n > pvt->nmemb) {
-		m = realloc(pvt->group.gr_mem, n * sizeof *m);
-		if (m == NULL) {
-			/* No harm done, no work done. */
-			return (0);
-		}
-		pvt->group.gr_mem = m;
-		pvt->nmemb = n;
-	}
-	p = pvt->group.gr_mem + ndst;
-
-	/*
-	 * Enlarge destination membuf; cp points at new portion.
-	 */
-	n = sizenew(pvt->group.gr_mem, src->gr_mem);
-	INSIST((nnew == 0) == (n == 0));
-	if (!preserve) {
-		n += strlen(src->gr_name) + 1;
-		n += strlen(src->gr_passwd) + 1;
-	}
-	if (n == 0) {
-		/* No work to do. */
-		return (1);
-	}
-	used = preserve ? pvt->membufsize : 0;
-	cp = malloc(used + n);
-	if (cp == NULL) {
-		/* No harm done, no work done. */
-		return (0);
-	}
-	ep = cp + used + n;
-	if (used != 0)
-		memcpy(cp, pvt->membuf, used);
-	oldmembuf = pvt->membuf;
-	pvt->membuf = cp;
-	pvt->membufsize = used + n;
-	cp += used;
-
-	/*
-	 * Adjust group.gr_mem.
-	 */
-	if (pvt->membuf != oldmembuf)
-		for (m = pvt->group.gr_mem; *m; m++)
-			*m = pvt->membuf + (*m - oldmembuf);
-
-	/*
-	 * Add new elements.
-	 */
-	for (m = src->gr_mem; *m; m++)
-		if (isnew(pvt->group.gr_mem, *m)) {
-			*p++ = cp;
-			*p = NULL;
-			n = strlen(*m) + 1;
-			if (n > ep - cp) {
-				FREE_IF(oldmembuf);
-				return (0);
-			}
-			strcpy(cp, *m);		/* (checked) */
-			cp += n;
-		}
-	if (preserve) {
-		pvt->group.gr_name = pvt->membuf + 
-				     (pvt->group.gr_name - oldmembuf);
-		pvt->group.gr_passwd = pvt->membuf + 
-				       (pvt->group.gr_passwd - oldmembuf);
-	} else {
-		pvt->group.gr_name = cp;
-		n = strlen(src->gr_name) + 1;
-		if (n > ep - cp) {
-			FREE_IF(oldmembuf);
-			return (0);
-		}
-		strcpy(cp, src->gr_name);	/* (checked) */
-		cp += n;
-
-		pvt->group.gr_passwd = cp;
-		n = strlen(src->gr_passwd) + 1;
-		if (n > ep - cp) {
-			FREE_IF(oldmembuf);
-			return (0);
-		}
-		strcpy(cp, src->gr_passwd);	/* (checked) */
-		cp += n;
-	}
-	FREE_IF(oldmembuf);
-	INSIST(cp >= pvt->membuf && cp <= &pvt->membuf[pvt->membufsize]);
-	return (1);
-}
-
-static int
-countvec(char **vec) {
-	int n = 0;
-
-	while (*vec++)
-		n++;
-	return (n);
-}
-
-static int
-isnew(char **old, char *new) {
-	for (; *old; old++)
-		if (strcmp(*old, new) == 0)
-			return (0);
-	return (1);
-}
-
-static int
-countnew(char **old, char **new) {
-	int n = 0;
-
-	for (; *new; new++)
-		n += isnew(old, *new);
-	return (n);
-}
-
-static size_t
-sizenew(char **old, char **new) {
-	size_t n = 0;
-
-	for (; *new; new++)
-		if (isnew(old, *new))
-			n += strlen(*new) + 1;
-	return (n);
-}
-
-static int
-newgid(int ngroups, gid_t *groups, gid_t group) {
-	ngroups--, groups++;
-	for (; ngroups-- > 0; groups++)
-		if (*groups == group)
-			return (0);
-	return (1);
-}
-
-#endif /* WANT_IRS_GR */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/gen_ho.c b/contrib/bind9/lib/bind/irs/gen_ho.c
deleted file mode 100644
index c5e09da..0000000
--- a/contrib/bind9/lib/bind/irs/gen_ho.c
+++ /dev/null
@@ -1,391 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: gen_ho.c,v 1.3.18.2 2006/03/10 00:20:08 marka Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-/* Imports */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-
-#include <errno.h>
-#include <stdlib.h>
-#include <netdb.h>
-#include <resolv.h>
-#include <stdio.h>
-#include <string.h>
-
-#include <isc/memcluster.h>
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "gen_p.h"
-
-/* Definitions */
-
-struct pvt {
-	struct irs_rule *	rules;
-	struct irs_rule *	rule;
-	struct irs_ho *		ho;
-	struct __res_state *	res;
-	void			(*free_res)(void *);
-};
-
-/* Forwards */
-
-static void		ho_close(struct irs_ho *this);
-static struct hostent *	ho_byname(struct irs_ho *this, const char *name);
-static struct hostent *	ho_byname2(struct irs_ho *this, const char *name,
-				   int af);
-static struct hostent *	ho_byaddr(struct irs_ho *this, const void *addr,
-				  int len, int af);
-static struct hostent *	ho_next(struct irs_ho *this);
-static void		ho_rewind(struct irs_ho *this);
-static void		ho_minimize(struct irs_ho *this);
-static struct __res_state * ho_res_get(struct irs_ho *this);
-static void		ho_res_set(struct irs_ho *this,
-				   struct __res_state *res,
-				   void (*free_res)(void *));
-static struct addrinfo * ho_addrinfo(struct irs_ho *this, const char *name,
-				     const struct addrinfo *pai);
-
-static int		init(struct irs_ho *this);
-
-/* Exports */
-
-struct irs_ho *
-irs_gen_ho(struct irs_acc *this) {
-	struct gen_p *accpvt = (struct gen_p *)this->private;
-	struct irs_ho *ho;
-	struct pvt *pvt;
-
-	if (!(pvt = memget(sizeof *pvt))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	if (!(ho = memget(sizeof *ho))) {
-		memput(pvt, sizeof *pvt);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(ho, 0x5e, sizeof *ho);
-	pvt->rules = accpvt->map_rules[irs_ho];
-	pvt->rule = pvt->rules;
-	ho->private = pvt;
-	ho->close = ho_close;
-	ho->byname = ho_byname;
-	ho->byname2 = ho_byname2;
-	ho->byaddr = ho_byaddr;
-	ho->next = ho_next;
-	ho->rewind = ho_rewind;
-	ho->minimize = ho_minimize;
-	ho->res_get = ho_res_get;
-	ho->res_set = ho_res_set;
-	ho->addrinfo = ho_addrinfo;
-	return (ho);
-}
-
-/* Methods. */
-
-static void
-ho_close(struct irs_ho *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	ho_minimize(this);
-	if (pvt->res && pvt->free_res)
-		(*pvt->free_res)(pvt->res);
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-static struct hostent *
-ho_byname(struct irs_ho *this, const char *name) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-	struct hostent *rval;
-	struct irs_ho *ho;
-	int therrno = NETDB_INTERNAL;
-	int softerror = 0;
-
-	if (init(this) == -1)
-		return (NULL);
-
-	for (rule = pvt->rules; rule; rule = rule->next) {
-		ho = rule->inst->ho;
-		RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL);
-		errno = 0;
-		rval = (*ho->byname)(ho, name);
-		if (rval != NULL)
-			return (rval);
-		if (softerror == 0 &&
-		    pvt->res->res_h_errno != HOST_NOT_FOUND &&
-		    pvt->res->res_h_errno != NETDB_INTERNAL) {
-			softerror = 1;
-			therrno = pvt->res->res_h_errno;
-		}
-		if (rule->flags & IRS_CONTINUE)
-			continue;
-		/*
-		 * The value TRY_AGAIN can mean that the service
-		 * is not available, or just that this particular name
-		 * cannot be resolved now.  We use the errno ECONNREFUSED
-		 * to distinguish.  If a lookup sets that errno when
-		 * H_ERRNO is TRY_AGAIN, we continue to try other lookup
-		 * functions, otherwise we return the TRY_AGAIN error.
-		 */
-		if (pvt->res->res_h_errno != TRY_AGAIN || errno != ECONNREFUSED)
-			break;
-	}
-	if (softerror != 0 && pvt->res->res_h_errno == HOST_NOT_FOUND)
-		RES_SET_H_ERRNO(pvt->res, therrno);
-	return (NULL);
-}
-
-static struct hostent *
-ho_byname2(struct irs_ho *this, const char *name, int af) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-	struct hostent *rval;
-	struct irs_ho *ho;
-	int therrno = NETDB_INTERNAL;
-	int softerror = 0;
-
-	if (init(this) == -1)
-		return (NULL);
-
-	for (rule = pvt->rules; rule; rule = rule->next) {
-		ho = rule->inst->ho;
-		RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL);
-		errno = 0;
-		rval = (*ho->byname2)(ho, name, af);
-		if (rval != NULL)
-			return (rval);
-		if (softerror == 0 &&
-		    pvt->res->res_h_errno != HOST_NOT_FOUND &&
-		    pvt->res->res_h_errno != NETDB_INTERNAL) {
-			softerror = 1;
-			therrno = pvt->res->res_h_errno;
-		}
-		if (rule->flags & IRS_CONTINUE)
-			continue;
-		/*
-		 * See the comments in ho_byname() explaining
-		 * the interpretation of TRY_AGAIN and ECONNREFUSED.
-		 */
-		if (pvt->res->res_h_errno != TRY_AGAIN || errno != ECONNREFUSED)
-			break;
-	}
-	if (softerror != 0 && pvt->res->res_h_errno == HOST_NOT_FOUND)
-		RES_SET_H_ERRNO(pvt->res, therrno);
-	return (NULL);
-}
-
-static struct hostent *
-ho_byaddr(struct irs_ho *this, const void *addr, int len, int af) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-	struct hostent *rval;
-	struct irs_ho *ho;
-	int therrno = NETDB_INTERNAL;
-	int softerror = 0;
-
-
-	if (init(this) == -1)
-		return (NULL);
-
-	for (rule = pvt->rules; rule; rule = rule->next) {
-		ho = rule->inst->ho;
-		RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL);
-		errno = 0;
-		rval = (*ho->byaddr)(ho, addr, len, af);
-		if (rval != NULL)
-			return (rval);
-		if (softerror == 0 &&
-		    pvt->res->res_h_errno != HOST_NOT_FOUND &&
-		    pvt->res->res_h_errno != NETDB_INTERNAL) {
-			softerror = 1;
-			therrno = pvt->res->res_h_errno;
-		}
-
-		if (rule->flags & IRS_CONTINUE)
-			continue;
-		/*
-		 * See the comments in ho_byname() explaining
-		 * the interpretation of TRY_AGAIN and ECONNREFUSED.
-		 */
-		if (pvt->res->res_h_errno != TRY_AGAIN || errno != ECONNREFUSED)
-			break;
-	}
-	if (softerror != 0 && pvt->res->res_h_errno == HOST_NOT_FOUND)
-		RES_SET_H_ERRNO(pvt->res, therrno);
-	return (NULL);
-}
-
-static struct hostent *
-ho_next(struct irs_ho *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct hostent *rval;
-	struct irs_ho *ho;
-
-	while (pvt->rule) {
-		ho = pvt->rule->inst->ho;
-		rval = (*ho->next)(ho);
-		if (rval)
-			return (rval);
-		if (!(pvt->rule->flags & IRS_CONTINUE))
-			break;
-		pvt->rule = pvt->rule->next;
-		if (pvt->rule) {
-			ho = pvt->rule->inst->ho;
-			(*ho->rewind)(ho);
-		}
-	}
-	return (NULL);
-}
-
-static void
-ho_rewind(struct irs_ho *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_ho *ho;
-
-	pvt->rule = pvt->rules;
-	if (pvt->rule) {
-		ho = pvt->rule->inst->ho;
-		(*ho->rewind)(ho);
-	}
-}
-
-static void
-ho_minimize(struct irs_ho *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-
-	if (pvt->res)
-		res_nclose(pvt->res);
-	for (rule = pvt->rules; rule != NULL; rule = rule->next) {
-		struct irs_ho *ho = rule->inst->ho;
-
-		(*ho->minimize)(ho);
-	}
-}
-
-static struct __res_state *
-ho_res_get(struct irs_ho *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (!pvt->res) {
-		struct __res_state *res;
-		res = (struct __res_state *)malloc(sizeof *res);
-		if (!res) {
-			errno = ENOMEM;
-			return (NULL);
-		}
-		memset(res, 0, sizeof *res);
-		ho_res_set(this, res, free);
-	}
-
-	return (pvt->res);
-}
-
-static void
-ho_res_set(struct irs_ho *this, struct __res_state *res,
-		void (*free_res)(void *)) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-
-	if (pvt->res && pvt->free_res) {
-		res_nclose(pvt->res);
-		(*pvt->free_res)(pvt->res);
-	}
-
-	pvt->res = res;
-	pvt->free_res = free_res;
-
-	for (rule = pvt->rules; rule != NULL; rule = rule->next) {
-		struct irs_ho *ho = rule->inst->ho;
-
-		(*ho->res_set)(ho, pvt->res, NULL);
-	}
-}
-
-static struct addrinfo *
-ho_addrinfo(struct irs_ho *this, const char *name, const struct addrinfo *pai)
-{
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-	struct addrinfo *rval = NULL;
-	struct irs_ho *ho;
-	int therrno = NETDB_INTERNAL;
-	int softerror = 0;
-
-	if (init(this) == -1)
-		return (NULL);
-
-	for (rule = pvt->rules; rule; rule = rule->next) {
-		ho = rule->inst->ho;
-		RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL);
-		errno = 0;
-		if (ho->addrinfo == NULL) /*%< for safety */
-			continue;
-		rval = (*ho->addrinfo)(ho, name, pai);
-		if (rval != NULL)
-			return (rval);
-		if (softerror == 0 &&
-		    pvt->res->res_h_errno != HOST_NOT_FOUND &&
-		    pvt->res->res_h_errno != NETDB_INTERNAL) {
-			softerror = 1;
-			therrno = pvt->res->res_h_errno;
-		}
-		if (rule->flags & IRS_CONTINUE)
-			continue;
-		/*
-		 * See the comments in ho_byname() explaining
-		 * the interpretation of TRY_AGAIN and ECONNREFUSED.
-		 */
-		if (pvt->res->res_h_errno != TRY_AGAIN ||
-		    errno != ECONNREFUSED)
-			break;
-	}
-	if (softerror != 0 && pvt->res->res_h_errno == HOST_NOT_FOUND)
-		RES_SET_H_ERRNO(pvt->res, therrno);
-	return (NULL);
-}
-
-static int
-init(struct irs_ho *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-        if (!pvt->res && !ho_res_get(this))
-                return (-1);
-
-        if (((pvt->res->options & RES_INIT) == 0U) &&
-            (res_ninit(pvt->res) == -1))
-                return (-1);
-
-        return (0);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/gen_ng.c b/contrib/bind9/lib/bind/irs/gen_ng.c
deleted file mode 100644
index 67f4edd..0000000
--- a/contrib/bind9/lib/bind/irs/gen_ng.c
+++ /dev/null
@@ -1,174 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: gen_ng.c,v 1.2.18.1 2005/04/27 05:00:56 sra Exp $";
-#endif
-
-/* Imports */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <resolv.h>
-
-#include <errno.h>
-#include <stdlib.h>
-#include <string.h>
-
-#include <isc/memcluster.h>
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "gen_p.h"
-
-/* Types */
-
-struct pvt {
-	struct irs_rule *	rules;
-	struct irs_rule *	rule;
-	char *			curgroup;
-};
-
-/* Forward */
-
-static void		ng_close(struct irs_ng *);
-static int		ng_next(struct irs_ng *, const char **,
-				const char **, const char **);
-static int 		ng_test(struct irs_ng *, const char *,
-				const char *, const char *,
-				const char *);
-static void 		ng_rewind(struct irs_ng *, const char *);
-static void		ng_minimize(struct irs_ng *);
-
-/* Public */
-
-struct irs_ng *
-irs_gen_ng(struct irs_acc *this) {
-	struct gen_p *accpvt = (struct gen_p *)this->private;
-	struct irs_ng *ng;
-	struct pvt *pvt;
-	
-	if (!(ng = memget(sizeof *ng))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(ng, 0x5e, sizeof *ng);
-	if (!(pvt = memget(sizeof *pvt))) {
-		memput(ng, sizeof *ng);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	pvt->rules = accpvt->map_rules[irs_ng];
-	pvt->rule = pvt->rules;
-	ng->private = pvt;
-	ng->close = ng_close;
-	ng->next = ng_next;
-	ng->test = ng_test;
-	ng->rewind = ng_rewind;
-	ng->minimize = ng_minimize;
-	return (ng);
-}
-
-/* Methods */
-
-static void 
-ng_close(struct irs_ng *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	
-	ng_minimize(this);
-	if (pvt->curgroup)
-		free(pvt->curgroup);
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-static int
-ng_next(struct irs_ng *this, const char **host, const char **user,
-	const char **domain)
-{
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_ng *ng;
-	
-	while (pvt->rule) {
-		ng = pvt->rule->inst->ng;
-		if ((*ng->next)(ng, host, user, domain) == 1)
-			return (1);
-		if (!(pvt->rule->flags & IRS_CONTINUE))
-			break;
-		pvt->rule = pvt->rule->next;
-		if (pvt->rule) {
-			ng = pvt->rule->inst->ng;
-			(*ng->rewind)(ng, pvt->curgroup);
-		}
-	}
-	return (0);
-}
-
-static int
-ng_test(struct irs_ng *this, const char *name,
-	const char *user, const char *host, const char *domain)
-{
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-	struct irs_ng *ng;
-	int rval;
-	
-	rval = 0;
-	for (rule = pvt->rules; rule; rule = rule->next) {
-		ng = rule->inst->ng;
-		rval = (*ng->test)(ng, name, user, host, domain);
-		if (rval || !(rule->flags & IRS_CONTINUE))
-			break;
-	}
-	return (rval);
-}
-
-static void
-ng_rewind(struct irs_ng *this, const char *group) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_ng *ng;
-	
-	pvt->rule = pvt->rules;
-	if (pvt->rule) {
-		if (pvt->curgroup)
-			free(pvt->curgroup);
-		pvt->curgroup = strdup(group);
-		ng = pvt->rule->inst->ng;
-		(*ng->rewind)(ng, pvt->curgroup);
-	}
-}
-
-static void
-ng_minimize(struct irs_ng *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-
-	for (rule = pvt->rules; rule != NULL; rule = rule->next) {
-		struct irs_ng *ng = rule->inst->ng;
-
-		(*ng->minimize)(ng);
-	}
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/gen_nw.c b/contrib/bind9/lib/bind/irs/gen_nw.c
deleted file mode 100644
index 8452f3f..0000000
--- a/contrib/bind9/lib/bind/irs/gen_nw.c
+++ /dev/null
@@ -1,264 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: gen_nw.c,v 1.3.18.1 2005/04/27 05:00:56 sra Exp $";
-#endif
-
-/* Imports */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-
-#include <errno.h>
-#include <resolv.h>
-#include <stdlib.h>
-#include <string.h>
-
-#include <isc/memcluster.h>
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "gen_p.h"
-
-/* Types */
-
-struct pvt {
-	struct irs_rule *	rules;
-	struct irs_rule *	rule;
-	struct __res_state *	res;
-	void 			(*free_res)(void *);
-};
-
-/* Forward */
-
-static void		nw_close(struct irs_nw*);
-static struct nwent *	nw_next(struct irs_nw *);
-static struct nwent *	nw_byname(struct irs_nw *, const char *, int);
-static struct nwent *	nw_byaddr(struct irs_nw *, void *, int, int);
-static void    		nw_rewind(struct irs_nw *);
-static void		nw_minimize(struct irs_nw *);
-static struct __res_state * nw_res_get(struct irs_nw *this);
-static void		nw_res_set(struct irs_nw *this,
-				   struct __res_state *res,
-				   void (*free_res)(void *));
-
-static int		init(struct irs_nw *this);
-
-/* Public */
-
-struct irs_nw *
-irs_gen_nw(struct irs_acc *this) {
-	struct gen_p *accpvt = (struct gen_p *)this->private;
-	struct irs_nw *nw;
-	struct pvt *pvt;
-
-	if (!(pvt = memget(sizeof *pvt))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	if (!(nw = memget(sizeof *nw))) {
-		memput(pvt, sizeof *pvt);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(nw, 0x5e, sizeof *nw);
-	pvt->rules = accpvt->map_rules[irs_nw];
-	pvt->rule = pvt->rules;
-	nw->private = pvt;
-	nw->close = nw_close;
-	nw->next = nw_next;
-	nw->byname = nw_byname;
-	nw->byaddr = nw_byaddr;
-	nw->rewind = nw_rewind;
-	nw->minimize = nw_minimize;
-	nw->res_get = nw_res_get;
-	nw->res_set = nw_res_set;
-	return (nw);
-}
-
-/* Methods */
-
-static void
-nw_close(struct irs_nw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	nw_minimize(this);
-
-	if (pvt->res && pvt->free_res)
-		(*pvt->free_res)(pvt->res);
-
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-static struct nwent *
-nw_next(struct irs_nw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct nwent *rval;
-	struct irs_nw *nw;
-
-	if (init(this) == -1)
-		return(NULL);
-
-	while (pvt->rule) {
-		nw = pvt->rule->inst->nw;
-		rval = (*nw->next)(nw);
-		if (rval)
-			return (rval);
-		if (!(pvt->rules->flags & IRS_CONTINUE))
-			break;
-		pvt->rule = pvt->rule->next;
-		if (pvt->rule) {
-			nw = pvt->rule->inst->nw;
-			(*nw->rewind)(nw);
-		}
-	}
-	return (NULL);
-}
-
-static struct nwent *
-nw_byname(struct irs_nw *this, const char *name, int type) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-	struct nwent *rval;
-	struct irs_nw *nw;
-	
-	if (init(this) == -1)
-		return(NULL);
-
-	for (rule = pvt->rules; rule; rule = rule->next) {
-		nw = rule->inst->nw;
-		RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL);
-		rval = (*nw->byname)(nw, name, type);
-		if (rval != NULL)
-			return (rval);
-		if (pvt->res->res_h_errno != TRY_AGAIN &&
-		    !(rule->flags & IRS_CONTINUE))
-			break;
-	}
-	return (NULL);
-}
-
-static struct nwent *
-nw_byaddr(struct irs_nw *this, void *net, int length, int type) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-	struct nwent *rval;
-	struct irs_nw *nw;
-	
-	if (init(this) == -1)
-		return(NULL);
-
-	for (rule = pvt->rules; rule; rule = rule->next) {
-		nw = rule->inst->nw;
-		RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL);
-		rval = (*nw->byaddr)(nw, net, length, type);
-		if (rval != NULL)
-			return (rval);
-		if (pvt->res->res_h_errno != TRY_AGAIN &&
-		    !(rule->flags & IRS_CONTINUE))
-			break;
-	}
-	return (NULL);
-}
-
-static void
-nw_rewind(struct irs_nw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_nw *nw;
-
-	pvt->rule = pvt->rules;
-	if (pvt->rule) {
-		nw = pvt->rule->inst->nw;
-		(*nw->rewind)(nw);
-	}
-}
-
-static void
-nw_minimize(struct irs_nw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-
-	if (pvt->res)
-		res_nclose(pvt->res);
-	for (rule = pvt->rules; rule != NULL; rule = rule->next) {
-		struct irs_nw *nw = rule->inst->nw;
-
-		(*nw->minimize)(nw);
-	}
-}
-
-static struct __res_state *
-nw_res_get(struct irs_nw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (!pvt->res) {
-		struct __res_state *res;
-		res = (struct __res_state *)malloc(sizeof *res);
-		if (!res) {
-			errno = ENOMEM;
-			return (NULL);
-		}
-		memset(res, 0, sizeof *res);
-		nw_res_set(this, res, free);
-	}
-
-	return (pvt->res);
-}
-
-static void
-nw_res_set(struct irs_nw *this, struct __res_state *res,
-		void (*free_res)(void *)) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-
-	if (pvt->res && pvt->free_res) {
-		res_nclose(pvt->res);
-		(*pvt->free_res)(pvt->res);
-	}
-
-	pvt->res = res;
-	pvt->free_res = free_res;
-
-	for (rule = pvt->rules; rule != NULL; rule = rule->next) {
-		struct irs_nw *nw = rule->inst->nw;
-
-		(*nw->res_set)(nw, pvt->res, NULL);
-	}
-}
-
-static int
-init(struct irs_nw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	
-	if (!pvt->res && !nw_res_get(this))
-		return (-1);
-	if (((pvt->res->options & RES_INIT) == 0U) &&
-	    res_ninit(pvt->res) == -1)
-		return (-1);
-	return (0);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/gen_p.h b/contrib/bind9/lib/bind/irs/gen_p.h
deleted file mode 100644
index a0a312d..0000000
--- a/contrib/bind9/lib/bind/irs/gen_p.h
+++ /dev/null
@@ -1,113 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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: gen_p.h,v 1.2.18.1 2005/04/27 05:00:56 sra Exp $
- */
-
-/*! \file
- *  Notes:
- *	We hope to create a complete set of thread-safe entry points someday,
- *	which will mean a set of getXbyY() functions that take as an argument
- *	a pointer to the map class, which will have a pointer to the private
- *	data, which will be used preferentially to the static variables that
- *	are necessary to support the "classic" interface.  This "classic"
- *	interface will then be reimplemented as stubs on top of the thread
- *	safe modules, and will keep the map class pointers as their only
- *	static data.  HOWEVER, we are not there yet.  So while we will call
- *	the just-barely-converted map class methods with map class pointers,
- *	right now they probably all still use statics.  We're not fooling
- *	anybody, and we're not trying to (yet).
- */
-
-#ifndef _GEN_P_H_INCLUDED
-#define _GEN_P_H_INCLUDED
-
-/*%
- * These are the access methods.
- */
-enum irs_acc_id {
-	irs_lcl,	/*%< Local. */
-	irs_dns,	/*%< DNS or Hesiod. */
-	irs_nis,	/*%< Sun NIS ("YP"). */
-	irs_irp,	/*%< IR protocol. */
-	irs_nacc
-};
-
-/*%
- * These are the map types.
- */
-enum irs_map_id {
-	irs_gr,		/*%< "group" */
-	irs_pw,		/*%< "passwd" */
-	irs_sv,		/*%< "services" */
-	irs_pr,		/*%< "protocols" */
-	irs_ho,		/*%< "hosts" */
-	irs_nw,		/*%< "networks" */
-	irs_ng,		/*%< "netgroup" */
-	irs_nmap
-};
-
-/*%
- * This is an accessor instance.
- */
-struct irs_inst {
-	struct irs_acc *acc;
-	struct irs_gr *	gr;
-	struct irs_pw *	pw;
-	struct irs_sv *	sv;
-	struct irs_pr *	pr;
-	struct irs_ho *	ho;
-	struct irs_nw *	nw;
-	struct irs_ng *	ng;
-};
-
-/*%
- * This is a search rule for some map type.
- */
-struct irs_rule {
-	struct irs_rule *	next;
-	struct irs_inst *	inst;
-	int			flags;
-};
-#define IRS_MERGE		0x0001	/*%< Don't stop if acc. has data? */
-#define	IRS_CONTINUE		0x0002	/*%< Don't stop if acc. has no data? */
-/*
- * This is the private data for a search access class.
- */
-struct gen_p {
-	char *			options;
-	struct irs_rule *	map_rules[(int)irs_nmap];
-	struct irs_inst		accessors[(int)irs_nacc];
-	struct __res_state *	res;
-	void			(*free_res) __P((void *));
-};
-
-/*
- * Externs.
- */
-
-extern struct irs_acc *	irs_gen_acc __P((const char *, const char *conf_file));
-extern struct irs_gr *	irs_gen_gr __P((struct irs_acc *));
-extern struct irs_pw *	irs_gen_pw __P((struct irs_acc *));
-extern struct irs_sv *	irs_gen_sv __P((struct irs_acc *));
-extern struct irs_pr *	irs_gen_pr __P((struct irs_acc *));
-extern struct irs_ho *	irs_gen_ho __P((struct irs_acc *));
-extern struct irs_nw *	irs_gen_nw __P((struct irs_acc *));
-extern struct irs_ng *	irs_gen_ng __P((struct irs_acc *));
-
-#endif /*_IRS_P_H_INCLUDED*/
diff --git a/contrib/bind9/lib/bind/irs/gen_pr.c b/contrib/bind9/lib/bind/irs/gen_pr.c
deleted file mode 100644
index 5c9d69c..0000000
--- a/contrib/bind9/lib/bind/irs/gen_pr.c
+++ /dev/null
@@ -1,228 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: gen_pr.c,v 1.2.18.1 2005/04/27 05:00:56 sra Exp $";
-#endif
-
-/* Imports */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-
-#include <errno.h>
-#include <resolv.h>
-#include <stdlib.h>
-#include <string.h>
-
-#include <isc/memcluster.h>
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "gen_p.h"
-
-/* Types */
-
-struct pvt {
-	struct irs_rule *	rules;
-	struct irs_rule *	rule;
-	struct __res_state *	res;
-	void			(*free_res)(void *);
-};
-
-/* Forward */
-
-static void			pr_close(struct irs_pr*);
-static struct protoent *	pr_next(struct irs_pr *);
-static struct protoent *	pr_byname(struct irs_pr *, const char *);
-static struct protoent * 	pr_bynumber(struct irs_pr *, int);
-static void 			pr_rewind(struct irs_pr *);
-static void			pr_minimize(struct irs_pr *);
-static struct __res_state *	pr_res_get(struct irs_pr *);
-static void			pr_res_set(struct irs_pr *,
-					   struct __res_state *,
-					   void (*)(void *));
-
-/* Public */
-
-struct irs_pr *
-irs_gen_pr(struct irs_acc *this) {
-	struct gen_p *accpvt = (struct gen_p *)this->private;
-	struct irs_pr *pr;
-	struct pvt *pvt;
-
-	if (!(pr = memget(sizeof *pr))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pr, 0x5e, sizeof *pr);
-	if (!(pvt = memget(sizeof *pvt))) {
-		memput(pr, sizeof *pr);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	pvt->rules = accpvt->map_rules[irs_pr];
-	pvt->rule = pvt->rules;
-	pr->private = pvt;
-	pr->close = pr_close;
-	pr->next = pr_next;
-	pr->byname = pr_byname;
-	pr->bynumber = pr_bynumber;
-	pr->rewind = pr_rewind;
-	pr->minimize = pr_minimize;
-	pr->res_get = pr_res_get;
-	pr->res_set = pr_res_set;
-	return (pr);
-}
-
-/* Methods */
-
-static void
-pr_close(struct irs_pr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-static struct protoent *
-pr_next(struct irs_pr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct protoent *rval;
-	struct irs_pr *pr;
-
-	while (pvt->rule) {
-		pr = pvt->rule->inst->pr;
-		rval = (*pr->next)(pr);
-		if (rval)
-			return (rval);
-		if (!(pvt->rules->flags & IRS_CONTINUE))
-			break;
-		pvt->rule = pvt->rule->next;
-		if (pvt->rule) {
-			pr = pvt->rule->inst->pr;
-			(*pr->rewind)(pr);
-		}
-	}
-	return (NULL);
-}
-
-static struct protoent *
-pr_byname(struct irs_pr *this, const char *name) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-	struct protoent *rval;
-	struct irs_pr *pr;
-	
-	rval = NULL;
-	for (rule = pvt->rules; rule; rule = rule->next) {
-		pr = rule->inst->pr;
-		rval = (*pr->byname)(pr, name);
-		if (rval || !(rule->flags & IRS_CONTINUE))
-			break;
-	}
-	return (rval);
-}
-
-static struct protoent *
-pr_bynumber(struct irs_pr *this, int proto) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-	struct protoent *rval;
-	struct irs_pr *pr;
-	
-	rval = NULL;
-	for (rule = pvt->rules; rule; rule = rule->next) {
-		pr = rule->inst->pr;
-		rval = (*pr->bynumber)(pr, proto);
-		if (rval || !(rule->flags & IRS_CONTINUE))
-			break;
-	}
-	return (rval);
-}
-
-static void
-pr_rewind(struct irs_pr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_pr *pr;
-
-	pvt->rule = pvt->rules;
-	if (pvt->rule) {
-		pr = pvt->rule->inst->pr;
-		(*pr->rewind)(pr);
-	}
-}
-
-static void
-pr_minimize(struct irs_pr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-
-	for (rule = pvt->rules; rule != NULL; rule = rule->next) {
-		struct irs_pr *pr = rule->inst->pr;
-
-		(*pr->minimize)(pr);
-	}
-}
-
-static struct __res_state *
-pr_res_get(struct irs_pr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (!pvt->res) {
-		struct __res_state *res;
-		res = (struct __res_state *)malloc(sizeof *res);
-		if (!res) {
-			errno = ENOMEM;
-			return (NULL);
-		}
-		memset(res, 0, sizeof *res);
-		pr_res_set(this, res, free);
-	}
-
-	return (pvt->res);
-}
-
-static void
-pr_res_set(struct irs_pr *this, struct __res_state *res,
-		void (*free_res)(void *)) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-
-	if (pvt->res && pvt->free_res) {
-		res_nclose(pvt->res);
-		(*pvt->free_res)(pvt->res);
-	}
-
-	pvt->res = res;
-	pvt->free_res = free_res;
-
-	for (rule = pvt->rules; rule != NULL; rule = rule->next) {
-		struct irs_pr *pr = rule->inst->pr;
-
-		if (pr->res_set)
-			(*pr->res_set)(pr, pvt->res, NULL);
-	}
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/gen_pw.c b/contrib/bind9/lib/bind/irs/gen_pw.c
deleted file mode 100644
index 80d9b5d..0000000
--- a/contrib/bind9/lib/bind/irs/gen_pw.c
+++ /dev/null
@@ -1,234 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: gen_pw.c,v 1.2.18.1 2005/04/27 05:00:57 sra Exp $";
-#endif
-
-/* Imports */
-
-#include "port_before.h"
-
-#ifndef WANT_IRS_PW
-static int __bind_irs_pw_unneeded;
-#else
-
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <resolv.h>
-
-#include <errno.h>
-#include <pwd.h>
-#include <stdlib.h>
-#include <string.h>
-
-#include <isc/memcluster.h>
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "gen_p.h"
-
-/* Types */
-
-struct pvt {
-	struct irs_rule *	rules;
-	struct irs_rule *	rule;
-	struct __res_state *	res;
-	void			(*free_res)(void *);
-};
-
-/* Forward */
-
-static void			pw_close(struct irs_pw *);
-static struct passwd *		pw_next(struct irs_pw *);
-static struct passwd *		pw_byname(struct irs_pw *, const char *);
-static struct passwd *		pw_byuid(struct irs_pw *, uid_t);
-static void			pw_rewind(struct irs_pw *);
-static void			pw_minimize(struct irs_pw *);
-static struct __res_state *	pw_res_get(struct irs_pw *);
-static void			pw_res_set(struct irs_pw *,
-					   struct __res_state *,
-					   void (*)(void *));
-
-/* Public */
-
-struct irs_pw *
-irs_gen_pw(struct irs_acc *this) {
-	struct gen_p *accpvt = (struct gen_p *)this->private;
-	struct irs_pw *pw;
-	struct pvt *pvt;
-
-	if (!(pw = memget(sizeof *pw))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pw, 0x5e, sizeof *pw);
-	if (!(pvt = memget(sizeof *pvt))) {
-		memput(pw, sizeof *pvt);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	pvt->rules = accpvt->map_rules[irs_pw];
-	pvt->rule = pvt->rules;
-	pw->private = pvt;
-	pw->close = pw_close;
-	pw->next = pw_next;
-	pw->byname = pw_byname;
-	pw->byuid = pw_byuid;
-	pw->rewind = pw_rewind;
-	pw->minimize = pw_minimize;
-	pw->res_get = pw_res_get;
-	pw->res_set = pw_res_set;
-	return (pw);
-}
-
-/* Methods */
-
-static void
-pw_close(struct irs_pw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-static struct passwd *
-pw_next(struct irs_pw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct passwd *rval;
-	struct irs_pw *pw;
-	
-	while (pvt->rule) {
-		pw = pvt->rule->inst->pw;
-		rval = (*pw->next)(pw);
-		if (rval)
-			return (rval);
-		if (!(pvt->rule->flags & IRS_CONTINUE))
-			break;
-		pvt->rule = pvt->rule->next;
-		if (pvt->rule) {
-			pw = pvt->rule->inst->pw;
-			(*pw->rewind)(pw);
-		}
-	}
-	return (NULL);
-}
-
-static void
-pw_rewind(struct irs_pw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_pw *pw;
-	
-	pvt->rule = pvt->rules;
-	if (pvt->rule) {
-		pw = pvt->rule->inst->pw;
-		(*pw->rewind)(pw);
-	}
-}
-
-static struct passwd *
-pw_byname(struct irs_pw *this, const char *name) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-	struct passwd *rval;
-	struct irs_pw *pw;
-	
-	rval = NULL;
-	for (rule = pvt->rules; rule; rule = rule->next) {
-		pw = rule->inst->pw;
-		rval = (*pw->byname)(pw, name);
-		if (rval || !(rule->flags & IRS_CONTINUE))
-			break;
-	}
-	return (rval);
-}
-
-static struct passwd *
-pw_byuid(struct irs_pw *this, uid_t uid) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-	struct passwd *rval;
-	struct irs_pw *pw;
-	
-	rval = NULL;
-	for (rule = pvt->rules; rule; rule = rule->next) {
-		pw = rule->inst->pw;
-		rval = (*pw->byuid)(pw, uid);
-		if (rval || !(rule->flags & IRS_CONTINUE))
-			break;
-	}
-	return (rval);
-}	
-
-static void
-pw_minimize(struct irs_pw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-
-	for (rule = pvt->rules; rule != NULL; rule = rule->next) {
-		struct irs_pw *pw = rule->inst->pw;
-
-		(*pw->minimize)(pw);
-	}
-}
-
-static struct __res_state *
-pw_res_get(struct irs_pw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (!pvt->res) {
-		struct __res_state *res;
-		res = (struct __res_state *)malloc(sizeof *res);
-		if (!res) {
-			errno = ENOMEM;
-			return (NULL);
-		}
-		memset(res, 0, sizeof *res);
-		pw_res_set(this, res, free);
-	}
-
-	return (pvt->res);
-}
-
-static void
-pw_res_set(struct irs_pw *this, struct __res_state *res,
-		void (*free_res)(void *)) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-
-	if (pvt->res && pvt->free_res) {
-		res_nclose(pvt->res);
-		(*pvt->free_res)(pvt->res);
-	}
-
-	pvt->res = res;
-	pvt->free_res = free_res;
-
-	for (rule = pvt->rules; rule != NULL; rule = rule->next) {
-		struct irs_pw *pw = rule->inst->pw;
-
-		if (pw->res_set)
-			(*pw->res_set)(pw, pvt->res, NULL);
-	}
-}
-
-#endif /* WANT_IRS_PW */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/gen_sv.c b/contrib/bind9/lib/bind/irs/gen_sv.c
deleted file mode 100644
index 66f0ab7..0000000
--- a/contrib/bind9/lib/bind/irs/gen_sv.c
+++ /dev/null
@@ -1,229 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: gen_sv.c,v 1.2.18.1 2005/04/27 05:00:57 sra Exp $";
-#endif
-
-/* Imports */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <resolv.h>
-
-#include <errno.h>
-#include <stdlib.h>
-#include <string.h>
-
-#include <isc/memcluster.h>
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "gen_p.h"
-
-/* Types */
-
-struct pvt {
-	struct irs_rule *	rules;
-	struct irs_rule *	rule;
-	struct __res_state *	res;
-	void			(*free_res)(void *);
-};
-
-/* Forward */
-
-static void			sv_close(struct irs_sv*);
-static struct servent *		sv_next(struct irs_sv *);
-static struct servent *		sv_byname(struct irs_sv *, const char *,
-					  const char *);
-static struct servent *		sv_byport(struct irs_sv *, int, const char *);
-static void			sv_rewind(struct irs_sv *);
-static void			sv_minimize(struct irs_sv *);
-static struct __res_state *	sv_res_get(struct irs_sv *);
-static void			sv_res_set(struct irs_sv *,
-					      struct __res_state *,
-					      void (*)(void *));
-
-/* Public */
-
-struct irs_sv *
-irs_gen_sv(struct irs_acc *this) {
-	struct gen_p *accpvt = (struct gen_p *)this->private;
-	struct irs_sv *sv;
-	struct pvt *pvt;
-
-	if (!(sv = memget(sizeof *sv))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(sv, 0x5e, sizeof *sv);
-	if (!(pvt = memget(sizeof *pvt))) {
-		memput(sv, sizeof *sv);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	pvt->rules = accpvt->map_rules[irs_sv];
-	pvt->rule = pvt->rules;
-	sv->private = pvt;
-	sv->close = sv_close;
-	sv->next = sv_next;
-	sv->byname = sv_byname;
-	sv->byport = sv_byport;
-	sv->rewind = sv_rewind;
-	sv->minimize = sv_minimize;
-	sv->res_get = sv_res_get;
-	sv->res_set = sv_res_set;
-	return (sv);
-}
-
-/* Methods */
-
-static void
-sv_close(struct irs_sv *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-static struct servent *
-sv_next(struct irs_sv *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct servent *rval;
-	struct irs_sv *sv;
-	
-	while (pvt->rule) {
-		sv = pvt->rule->inst->sv;
-		rval = (*sv->next)(sv);
-		if (rval)
-			return (rval);
-		if (!(pvt->rule->flags & IRS_CONTINUE))
-			break;
-		pvt->rule = pvt->rule->next;
-		if (pvt->rule) {
-			sv = pvt->rule->inst->sv;
-			(*sv->rewind)(sv);
-		}
-	}
-	return (NULL);
-}
-
-static struct servent *
-sv_byname(struct irs_sv *this, const char *name, const char *proto) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-	struct servent *rval;
-	struct irs_sv *sv;
-	
-	rval = NULL;
-	for (rule = pvt->rules; rule; rule = rule->next) {
-		sv = rule->inst->sv;
-		rval = (*sv->byname)(sv, name, proto);
-		if (rval || !(rule->flags & IRS_CONTINUE))
-			break;
-	}
-	return (rval);
-}
-
-static struct servent *
-sv_byport(struct irs_sv *this, int port, const char *proto) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-	struct servent *rval;
-	struct irs_sv *sv;
-	
-	rval = NULL;
-	for (rule = pvt->rules; rule; rule = rule->next) {
-		sv = rule->inst->sv;
-		rval = (*sv->byport)(sv, port, proto);
-		if (rval || !(rule->flags & IRS_CONTINUE))
-			break;
-	}
-	return (rval);
-}
-
-static void
-sv_rewind(struct irs_sv *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_sv *sv;
-
-	pvt->rule = pvt->rules;
-	if (pvt->rule) {
-		sv = pvt->rule->inst->sv;
-		(*sv->rewind)(sv);
-	}
-}
-
-static void
-sv_minimize(struct irs_sv *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-
-	for (rule = pvt->rules; rule != NULL; rule = rule->next) {
-		struct irs_sv *sv = rule->inst->sv;
-
-		(*sv->minimize)(sv);
-	}
-}
-
-static struct __res_state *
-sv_res_get(struct irs_sv *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (!pvt->res) {
-		struct __res_state *res;
-		res = (struct __res_state *)malloc(sizeof *res);
-		if (!res) {
-			errno = ENOMEM;
-			return (NULL);
-		}
-		memset(res, 0, sizeof *res);
-		sv_res_set(this, res, free);
-	}
-
-	return (pvt->res);
-}
-
-static void
-sv_res_set(struct irs_sv *this, struct __res_state *res,
-		void (*free_res)(void *)) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct irs_rule *rule;
-
-	if (pvt->res && pvt->free_res) {
-		res_nclose(pvt->res);
-		(*pvt->free_res)(pvt->res);
-	}
-
-	pvt->res = res;
-	pvt->free_res = free_res;
-
-	for (rule = pvt->rules; rule != NULL; rule = rule->next) {
-		struct irs_sv *sv = rule->inst->sv;
-
-		if (sv->res_set)
-			(*sv->res_set)(sv, pvt->res, NULL);
-	}
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/getaddrinfo.c b/contrib/bind9/lib/bind/irs/getaddrinfo.c
deleted file mode 100644
index 1839ba4..0000000
--- a/contrib/bind9/lib/bind/irs/getaddrinfo.c
+++ /dev/null
@@ -1,1253 +0,0 @@
-/*	$KAME: getaddrinfo.c,v 1.14 2001/01/06 09:41:15 jinmei Exp $	*/
-
-/*
- * Copyright (C) 1995, 1996, 1997, and 1998 WIDE Project.
- * All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. Neither the name of the project nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-/*! \file
- * Issues to be discussed:
- *\li  Thread safe-ness must be checked.
- *\li  Return values.  There are nonstandard return values defined and used
- *   in the source code.  This is because RFC2553 is silent about which error
- *   code must be returned for which situation.
- *\li  IPv4 classful (shortened) form.  RFC2553 is silent about it.  XNET 5.2
- *   says to use inet_aton() to convert IPv4 numeric to binary (allows
- *   classful form as a result).
- *   current code - disallow classful form for IPv4 (due to use of inet_pton).
- *\li  freeaddrinfo(NULL).  RFC2553 is silent about it.  XNET 5.2 says it is
- *   invalid.
- *   current code - SEGV on freeaddrinfo(NULL)
- * Note:
- *\li  We use getipnodebyname() just for thread-safeness.  There's no intent
- *   to let it do PF_UNSPEC (actually we never pass PF_UNSPEC to
- *   getipnodebyname().
- *\li  The code filters out AFs that are not supported by the kernel,
- *   when globbing NULL hostname (to loopback, or wildcard).  Is it the right
- *   thing to do?  What is the relationship with post-RFC2553 AI_ADDRCONFIG
- *   in ai_flags?
- *\li  (post-2553) semantics of AI_ADDRCONFIG itself is too vague.
- *   (1) what should we do against numeric hostname (2) what should we do
- *   against NULL hostname (3) what is AI_ADDRCONFIG itself.  AF not ready?
- *   non-loopback address configured?  global address configured?
- * \par Additional Issue:
- *  To avoid search order issue, we have a big amount of code duplicate
- *   from gethnamaddr.c and some other places.  The issues that there's no
- *   lower layer function to lookup "IPv4 or IPv6" record.  Calling
- *   gethostbyname2 from getaddrinfo will end up in wrong search order, as
- *   follows:
- *	\li The code makes use of following calls when asked to resolver with
- *	  ai_family  = PF_UNSPEC:
- *\code		getipnodebyname(host, AF_INET6);
- *		getipnodebyname(host, AF_INET);
- *\endcode
- *	\li  This will result in the following queries if the node is configure to
- *	  prefer /etc/hosts than DNS:
- *\code
- *		lookup /etc/hosts for IPv6 address
- *		lookup DNS for IPv6 address
- *		lookup /etc/hosts for IPv4 address
- *		lookup DNS for IPv4 address
- *\endcode
- *	  which may not meet people's requirement.
- *	 \li The right thing to happen is to have underlying layer which does
- *	  PF_UNSPEC lookup (lookup both) and return chain of addrinfos.
- *	  This would result in a bit of code duplicate with _dns_ghbyname() and
- *	  friends.
- */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/param.h>
-#include <sys/socket.h>
-
-#include <net/if.h>
-#include <netinet/in.h>
-
-#include <arpa/inet.h>
-#include <arpa/nameser.h>
-
-#include <netdb.h>
-#include <resolv.h>
-#include <string.h>
-#include <stdlib.h>
-#include <stddef.h>
-#include <ctype.h>
-#include <unistd.h>
-#include <stdio.h>
-#include <errno.h>
-
-#include <stdarg.h>
-
-#include <irs.h>
-#include <isc/assertions.h>
-
-#include "port_after.h"
-
-#include "irs_data.h"
-
-#define SUCCESS 0
-#define ANY 0
-#define YES 1
-#define NO  0
-
-static const char in_addrany[] = { 0, 0, 0, 0 };
-static const char in6_addrany[] = {
-	0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
-};
-static const char in_loopback[] = { 127, 0, 0, 1 };
-static const char in6_loopback[] = {
-	0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1
-};
-
-static const struct afd {
-	int a_af;
-	int a_addrlen;
-	int a_socklen;
-	int a_off;
-	const char *a_addrany;
-	const char *a_loopback;
-	int a_scoped;
-} afdl [] = {
-	{PF_INET6, sizeof(struct in6_addr),
-	 sizeof(struct sockaddr_in6),
-	 offsetof(struct sockaddr_in6, sin6_addr),
-	 in6_addrany, in6_loopback, 1},
-	{PF_INET, sizeof(struct in_addr),
-	 sizeof(struct sockaddr_in),
-	 offsetof(struct sockaddr_in, sin_addr),
-	 in_addrany, in_loopback, 0},
-	{0, 0, 0, 0, NULL, NULL, 0},
-};
-
-struct explore {
-	int e_af;
-	int e_socktype;
-	int e_protocol;
-	const char *e_protostr;
-	int e_wild;
-#define WILD_AF(ex)		((ex)->e_wild & 0x01)
-#define WILD_SOCKTYPE(ex)	((ex)->e_wild & 0x02)
-#define WILD_PROTOCOL(ex)	((ex)->e_wild & 0x04)
-};
-
-static const struct explore explore[] = {
-#if 0
-	{ PF_LOCAL, 0, ANY, ANY, NULL, 0x01 },
-#endif
-	{ PF_INET6, SOCK_DGRAM, IPPROTO_UDP, "udp", 0x07 },
-	{ PF_INET6, SOCK_STREAM, IPPROTO_TCP, "tcp", 0x07 },
-	{ PF_INET6, SOCK_RAW, ANY, NULL, 0x05 },
-	{ PF_INET, SOCK_DGRAM, IPPROTO_UDP, "udp", 0x07 },
-	{ PF_INET, SOCK_STREAM, IPPROTO_TCP, "tcp", 0x07 },
-	{ PF_INET, SOCK_RAW, ANY, NULL, 0x05 },
-	{ -1, 0, 0, NULL, 0 },
-};
-
-#define PTON_MAX	16
-
-static int str_isnumber __P((const char *));
-static int explore_fqdn __P((const struct addrinfo *, const char *,
-	const char *, struct addrinfo **));
-static int explore_copy __P((const struct addrinfo *, const struct addrinfo *,
-	struct addrinfo **));
-static int explore_null __P((const struct addrinfo *,
-	const char *, struct addrinfo **));
-static int explore_numeric __P((const struct addrinfo *, const char *,
-	const char *, struct addrinfo **));
-static int explore_numeric_scope __P((const struct addrinfo *, const char *,
-	const char *, struct addrinfo **));
-static int get_canonname __P((const struct addrinfo *,
-	struct addrinfo *, const char *));
-static struct addrinfo *get_ai __P((const struct addrinfo *,
-	const struct afd *, const char *));
-static struct addrinfo *copy_ai __P((const struct addrinfo *));
-static int get_portmatch __P((const struct addrinfo *, const char *));
-static int get_port __P((const struct addrinfo *, const char *, int));
-static const struct afd *find_afd __P((int));
-static int addrconfig __P((int));
-static int ip6_str2scopeid __P((char *, struct sockaddr_in6 *,
-				u_int32_t *scopeidp));
-static struct net_data *init __P((void));
-
-struct addrinfo *hostent2addrinfo __P((struct hostent *,
-				       const struct addrinfo *));
-struct addrinfo *addr2addrinfo __P((const struct addrinfo *,
-				    const char *));
-
-#if 0
-static const char *ai_errlist[] = {
-	"Success",
-	"Address family for hostname not supported",	/*%< EAI_ADDRFAMILY */
-	"Temporary failure in name resolution",		/*%< EAI_AGAIN */
-	"Invalid value for ai_flags",		       	/*%< EAI_BADFLAGS */
-	"Non-recoverable failure in name resolution", 	/*%< EAI_FAIL */
-	"ai_family not supported",			/*%< EAI_FAMILY */
-	"Memory allocation failure", 			/*%< EAI_MEMORY */
-	"No address associated with hostname", 		/*%< EAI_NODATA */
-	"hostname nor servname provided, or not known",	/*%< EAI_NONAME */
-	"servname not supported for ai_socktype",	/*%< EAI_SERVICE */
-	"ai_socktype not supported", 			/*%< EAI_SOCKTYPE */
-	"System error returned in errno", 		/*%< EAI_SYSTEM */
-	"Invalid value for hints",			/*%< EAI_BADHINTS */
-	"Resolved protocol is unknown",			/*%< EAI_PROTOCOL */
-	"Unknown error", 				/*%< EAI_MAX */
-};
-#endif
-
-/* XXX macros that make external reference is BAD. */
-
-#define GET_AI(ai, afd, addr) \
-do { \
-	/* external reference: pai, error, and label free */ \
-	(ai) = get_ai(pai, (afd), (addr)); \
-	if ((ai) == NULL) { \
-		error = EAI_MEMORY; \
-		goto free; \
-	} \
-} while (/*CONSTCOND*/0)
-
-#define GET_PORT(ai, serv) \
-do { \
-	/* external reference: error and label free */ \
-	error = get_port((ai), (serv), 0); \
-	if (error != 0) \
-		goto free; \
-} while (/*CONSTCOND*/0)
-
-#define GET_CANONNAME(ai, str) \
-do { \
-	/* external reference: pai, error and label free */ \
-	error = get_canonname(pai, (ai), (str)); \
-	if (error != 0) \
-		goto free; \
-} while (/*CONSTCOND*/0)
-
-#ifndef SOLARIS2
-#define SETERROR(err) \
-do { \
-	/* external reference: error, and label bad */ \
-	error = (err); \
-	goto bad; \
-	/*NOTREACHED*/ \
-} while (/*CONSTCOND*/0)
-#else
-#define SETERROR(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)))
-#define MATCH(x, y, w) \
-	((x) == (y) || (/*CONSTCOND*/(w) && ((x) == ANY || (y) == ANY)))
-
-#if 0				/*%< bind8 has its own version */
-char *
-gai_strerror(ecode)
-	int ecode;
-{
-	if (ecode < 0 || ecode > EAI_MAX)
-		ecode = EAI_MAX;
-	return ai_errlist[ecode];
-}
-#endif
-
-void
-freeaddrinfo(ai)
-	struct addrinfo *ai;
-{
-	struct addrinfo *next;
-
-	do {
-		next = ai->ai_next;
-		if (ai->ai_canonname)
-			free(ai->ai_canonname);
-		/* no need to free(ai->ai_addr) */
-		free(ai);
-		ai = next;
-	} while (ai);
-}
-
-static int
-str_isnumber(p)
-	const char *p;
-{
-	char *ep;
-
-	if (*p == '\0')
-		return NO;
-	ep = NULL;
-	errno = 0;
-	(void)strtoul(p, &ep, 10);
-	if (errno == 0 && ep && *ep == '\0')
-		return YES;
-	else
-		return NO;
-}
-
-int
-getaddrinfo(hostname, servname, hints, res)
-	const char *hostname, *servname;
-	const struct addrinfo *hints;
-	struct addrinfo **res;
-{
-	struct addrinfo sentinel;
-	struct addrinfo *cur;
-	int error = 0;
-	struct addrinfo ai, ai0, *afai = NULL;
-	struct addrinfo *pai;
-	const struct explore *ex;
-
-	memset(&sentinel, 0, sizeof(sentinel));
-	cur = &sentinel;
-	pai = &ai;
-	pai->ai_flags = 0;
-	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;
-	pai->ai_next = NULL;
-
-	if (hostname == NULL && servname == NULL)
-		return EAI_NONAME;
-	if (hints) {
-		/* error check for hints */
-		if (hints->ai_addrlen || hints->ai_canonname ||
-		    hints->ai_addr || hints->ai_next)
-			SETERROR(EAI_BADHINTS); /*%< xxx */
-		if (hints->ai_flags & ~AI_MASK)
-			SETERROR(EAI_BADFLAGS);
-		switch (hints->ai_family) {
-		case PF_UNSPEC:
-		case PF_INET:
-		case PF_INET6:
-			break;
-		default:
-			SETERROR(EAI_FAMILY);
-		}
-		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.
-		 */
-		if (pai->ai_socktype != ANY && pai->ai_protocol != ANY) {
-			for (ex = explore; ex->e_af >= 0; ex++) {
-				if (pai->ai_family != ex->e_af)
-					continue;
-				if (ex->e_socktype == ANY)
-					continue;
-				if (ex->e_protocol == ANY)
-					continue;
-				if (pai->ai_socktype == ex->e_socktype &&
-				    pai->ai_protocol != ex->e_protocol) {
-					SETERROR(EAI_BADHINTS);
-				}
-			}
-		}
-	}
-
-	/*
-	 * post-2553: AI_ALL and AI_V4MAPPED are effective only against
-	 * AF_INET6 query.  They needs to be ignored if specified in other
-	 * occassions.
-	 */
-	switch (pai->ai_flags & (AI_ALL | AI_V4MAPPED)) {
-	case AI_V4MAPPED:
-	case AI_ALL | AI_V4MAPPED:
-		if (pai->ai_family != AF_INET6)
-			pai->ai_flags &= ~(AI_ALL | AI_V4MAPPED);
-		break;
-	case AI_ALL:
-#if 1
-		/* illegal */
-		SETERROR(EAI_BADFLAGS);
-#else
-		pai->ai_flags &= ~(AI_ALL | AI_V4MAPPED);
-		break;
-#endif
-	}
-
-	/*
-	 * check for special cases.  (1) numeric servname is disallowed if
-	 * socktype/protocol are left unspecified. (2) servname is disallowed
-	 * for raw and other inet{,6} sockets.
-	 */
-	if (MATCH_FAMILY(pai->ai_family, PF_INET, 1)
-#ifdef PF_INET6
-	 || MATCH_FAMILY(pai->ai_family, PF_INET6, 1)
-#endif
-	    ) {
-		ai0 = *pai;	/* backup *pai */
-
-		if (pai->ai_family == PF_UNSPEC) {
-#ifdef PF_INET6
-			pai->ai_family = PF_INET6;
-#else
-			pai->ai_family = PF_INET;
-#endif
-		}
-		error = get_portmatch(pai, servname);
-		if (error)
-			SETERROR(error);
-
-		*pai = ai0;
-	}
-
-	ai0 = *pai;
-
-	/* NULL hostname, or numeric hostname */
-	for (ex = explore; ex->e_af >= 0; ex++) {
-		*pai = ai0;
-
-		if (!MATCH_FAMILY(pai->ai_family, ex->e_af, WILD_AF(ex)))
-			continue;
-		if (!MATCH(pai->ai_socktype, ex->e_socktype, WILD_SOCKTYPE(ex)))
-			continue;
-		if (!MATCH(pai->ai_protocol, ex->e_protocol, WILD_PROTOCOL(ex)))
-			continue;
-
-		if (pai->ai_family == PF_UNSPEC)
-			pai->ai_family = ex->e_af;
-		if (pai->ai_socktype == ANY && ex->e_socktype != ANY)
-			pai->ai_socktype = ex->e_socktype;
-		if (pai->ai_protocol == ANY && ex->e_protocol != ANY)
-			pai->ai_protocol = ex->e_protocol;
-
-		/*
-		 * if the servname does not match socktype/protocol, ignore it.
-		 */
-		if (get_portmatch(pai, servname) != 0)
-			continue;
-
-		if (hostname == NULL) {
-			/*
-			 * filter out AFs that are not supported by the kernel
-			 * XXX errno?
-			 */
-			if (!addrconfig(pai->ai_family))
-				continue;
-			error = explore_null(pai, servname, &cur->ai_next);
-		} else
-			error = explore_numeric_scope(pai, hostname, servname,
-			    &cur->ai_next);
-
-		if (error)
-			goto free;
-
-		while (cur && cur->ai_next)
-			cur = cur->ai_next;
-	}
-
-	/*
-	 * XXX
-	 * If numreic representation of AF1 can be interpreted as FQDN
-	 * representation of AF2, we need to think again about the code below.
-	 */
-	if (sentinel.ai_next)
-		goto good;
-
-	if (pai->ai_flags & AI_NUMERICHOST)
-		SETERROR(EAI_NONAME);
-	if (hostname == NULL)
-		SETERROR(EAI_NONAME);
-
-	/*
-	 * hostname as alphabetical name.
-	 * We'll make sure that
-	 * - if returning addrinfo list is empty, return non-zero error
-	 *   value (already known one or EAI_NONAME).
-	 * - otherwise, 
-	 *   + if we haven't had any errors, return 0 (i.e. success).
-	 *   + if we've had an error, free the list and return the error.
-	 * without any assumption on the behavior of explore_fqdn().
-	 */
-
-	/* first, try to query DNS for all possible address families. */
-	*pai = ai0;
-	error = explore_fqdn(pai, hostname, servname, &afai);
-	if (error) {
-		if (afai != NULL)
-			freeaddrinfo(afai);
-		goto free;
-	}
-	if (afai == NULL) {
-		error = EAI_NONAME; /*%< we've had no errors. */
-		goto free;
-	}
-
-	/*
-	 * we would like to prefer AF_INET6 than AF_INET, so we'll make an
-	 * outer loop by AFs.
-	 */
-	for (ex = explore; ex->e_af >= 0; ex++) {
-		*pai = ai0;
-
-		if (pai->ai_family == PF_UNSPEC)
-			pai->ai_family = ex->e_af;
-
-		if (!MATCH_FAMILY(pai->ai_family, ex->e_af, WILD_AF(ex)))
-			continue;
-		if (!MATCH(pai->ai_socktype, ex->e_socktype,
-			   WILD_SOCKTYPE(ex))) {
-			continue;
-		}
-		if (!MATCH(pai->ai_protocol, ex->e_protocol,
-			   WILD_PROTOCOL(ex))) {
-			continue;
-		}
-
-#ifdef AI_ADDRCONFIG
-		/*
-		 * If AI_ADDRCONFIG is specified, check if we are
-		 * expected to return the address family or not.
-		 */
-		if ((pai->ai_flags & AI_ADDRCONFIG) != 0 &&
-		    !addrconfig(pai->ai_family))
-			continue;
-#endif
-
-		if (pai->ai_family == PF_UNSPEC)
-			pai->ai_family = ex->e_af;
-		if (pai->ai_socktype == ANY && ex->e_socktype != ANY)
-			pai->ai_socktype = ex->e_socktype;
-		if (pai->ai_protocol == ANY && ex->e_protocol != ANY)
-			pai->ai_protocol = ex->e_protocol;
-
-		/*
-		 * if the servname does not match socktype/protocol, ignore it.
-		 */
-		if (get_portmatch(pai, servname) != 0)
-			continue;
-
-		if ((error = explore_copy(pai, afai, &cur->ai_next)) != 0) {
-			freeaddrinfo(afai);
-			goto free;
-		}
-
-		while (cur && cur->ai_next)
-			cur = cur->ai_next;
-	}
-
-	freeaddrinfo(afai);	/*%< afai must not be NULL at this point. */
-
-	if (sentinel.ai_next) {
-good:
-		*res = sentinel.ai_next;
-		return(SUCCESS);
-	} else {
-		/*
-		 * All the process succeeded, but we've had an empty list. 
-		 * This can happen if the given hints do not match our
-		 * candidates.
-		 */
-		error = EAI_NONAME;
-	}
-
-free:
-bad:
-	if (sentinel.ai_next)
-		freeaddrinfo(sentinel.ai_next);
-	*res = NULL;
-	return(error);
-}
-
-/*%
- * FQDN hostname, DNS lookup
- */
-static int
-explore_fqdn(pai, hostname, servname, res)
-	const struct addrinfo *pai;
-	const char *hostname;
-	const char *servname;
-	struct addrinfo **res;
-{
-	struct addrinfo *result;
-	struct addrinfo *cur;
-	struct net_data *net_data = init();
-	struct irs_ho *ho;
-	int error = 0;
-	char tmp[NS_MAXDNAME];
-	const char *cp;
-
-	INSIST(res != NULL && *res == NULL);
-
-	/*
-	 * if the servname does not match socktype/protocol, ignore it.
-	 */
-	if (get_portmatch(pai, servname) != 0)
-		return(0);
-
-	if (!net_data || !(ho = net_data->ho))
-		return(0);
-#if 0				/*%< XXX (notyet) */
-	if (net_data->ho_stayopen && net_data->ho_last &&
-	    net_data->ho_last->h_addrtype == af) {
-		if (ns_samename(name, net_data->ho_last->h_name) == 1)
-			return (net_data->ho_last);
-		for (hap = net_data->ho_last->h_aliases; hap && *hap; hap++)
-			if (ns_samename(name, *hap) == 1)
-				return (net_data->ho_last);
-	}
-#endif
-	if (!strchr(hostname, '.') &&
-	    (cp = res_hostalias(net_data->res, hostname,
-				tmp, sizeof(tmp))))
-		hostname = cp;
-	result = (*ho->addrinfo)(ho, hostname, pai);
-	if (!net_data->ho_stayopen) {
-		(*ho->minimize)(ho);
-	}
-	if (result == NULL) {
-		int e = h_errno;
-
-		switch(e) {
-		case NETDB_INTERNAL:
-			error = EAI_SYSTEM;
-			break;
-		case TRY_AGAIN:
-			error = EAI_AGAIN;
-			break;
-		case NO_RECOVERY:
-			error = EAI_FAIL;
-			break;
-		case HOST_NOT_FOUND:
-		case NO_DATA:
-			error = EAI_NONAME;
-			break;
-		default:
-		case NETDB_SUCCESS: /*%< should be impossible... */
-			error = EAI_NONAME;
-			break;
-		}
-		goto free;
-	}
-
-	for (cur = result; cur; cur = cur->ai_next) {
-		GET_PORT(cur, servname); /*%< XXX: redundant lookups... */
-		/* canonname should already be filled. */
-	}
-
-	*res = result;
-
-	return(0);
-
-free:
-	if (result)
-		freeaddrinfo(result);
-	return error;
-}
-
-static int
-explore_copy(pai, src0, res)
-	const struct addrinfo *pai;	/*%< seed */
-	const struct addrinfo *src0;	/*%< source */
-	struct addrinfo **res;
-{
-	int error;
-	struct addrinfo sentinel, *cur;
-	const struct addrinfo *src;
-
-	error = 0;
-	sentinel.ai_next = NULL;
-	cur = &sentinel;
-
-	for (src = src0; src != NULL; src = src->ai_next) {
-		if (src->ai_family != pai->ai_family)
-			continue;
-
-		cur->ai_next = copy_ai(src);
-		if (!cur->ai_next) {
-			error = EAI_MEMORY;
-			goto fail;
-		}
-
-		cur->ai_next->ai_socktype = pai->ai_socktype;
-		cur->ai_next->ai_protocol = pai->ai_protocol;
-		cur = cur->ai_next;
-	}
-
-	*res = sentinel.ai_next;
-	return 0;
-
-fail:
-	freeaddrinfo(sentinel.ai_next);
-	return error;
-}
-
-/*%
- * hostname == NULL.
- * passive socket -> anyaddr (0.0.0.0 or ::)
- * non-passive socket -> localhost (127.0.0.1 or ::1)
- */
-static int
-explore_null(pai, servname, res)
-	const struct addrinfo *pai;
-	const char *servname;
-	struct addrinfo **res;
-{
-	const struct afd *afd;
-	struct addrinfo *cur;
-	struct addrinfo sentinel;
-	int error;
-
-	*res = NULL;
-	sentinel.ai_next = NULL;
-	cur = &sentinel;
-
-	afd = find_afd(pai->ai_family);
-	if (afd == NULL)
-		return 0;
-
-	if (pai->ai_flags & AI_PASSIVE) {
-		GET_AI(cur->ai_next, afd, afd->a_addrany);
-		/* xxx meaningless?
-		 * GET_CANONNAME(cur->ai_next, "anyaddr");
-		 */
-		GET_PORT(cur->ai_next, servname);
-	} else {
-		GET_AI(cur->ai_next, afd, afd->a_loopback);
-		/* xxx meaningless?
-		 * GET_CANONNAME(cur->ai_next, "localhost");
-		 */
-		GET_PORT(cur->ai_next, servname);
-	}
-	cur = cur->ai_next;
-
-	*res = sentinel.ai_next;
-	return 0;
-
-free:
-	if (sentinel.ai_next)
-		freeaddrinfo(sentinel.ai_next);
-	return error;
-}
-
-/*%
- * numeric hostname
- */
-static int
-explore_numeric(pai, hostname, servname, res)
-	const struct addrinfo *pai;
-	const char *hostname;
-	const char *servname;
-	struct addrinfo **res;
-{
-	const struct afd *afd;
-	struct addrinfo *cur;
-	struct addrinfo sentinel;
-	int error;
-	char pton[PTON_MAX];
-
-	*res = NULL;
-	sentinel.ai_next = NULL;
-	cur = &sentinel;
-
-	afd = find_afd(pai->ai_family);
-	if (afd == NULL)
-		return 0;
-
-	switch (afd->a_af) {
-#if 0 /*X/Open spec*/
-	case AF_INET:
-		if (inet_aton(hostname, (struct in_addr *)pton) == 1) {
-			if (pai->ai_family == afd->a_af ||
-			    pai->ai_family == PF_UNSPEC /*?*/) {
-				GET_AI(cur->ai_next, afd, pton);
-				GET_PORT(cur->ai_next, servname);
-				while (cur->ai_next)
-					cur = cur->ai_next;
-			} else
-				SETERROR(EAI_FAMILY);	/*xxx*/
-		}
-		break;
-#endif
-	default:
-		if (inet_pton(afd->a_af, hostname, pton) == 1) {
-			if (pai->ai_family == afd->a_af ||
-			    pai->ai_family == PF_UNSPEC /*?*/) {
-				GET_AI(cur->ai_next, afd, pton);
-				GET_PORT(cur->ai_next, servname);
-				while (cur->ai_next)
-					cur = cur->ai_next;
-			} else
-				SETERROR(EAI_FAMILY);	/*xxx*/
-		}
-		break;
-	}
-
-	*res = sentinel.ai_next;
-	return 0;
-
-free:
-bad:
-	if (sentinel.ai_next)
-		freeaddrinfo(sentinel.ai_next);
-	return error;
-}
-
-/*%
- * numeric hostname with scope
- */
-static int
-explore_numeric_scope(pai, hostname, servname, res)
-	const struct addrinfo *pai;
-	const char *hostname;
-	const char *servname;
-	struct addrinfo **res;
-{
-#ifndef SCOPE_DELIMITER
-	return explore_numeric(pai, hostname, servname, res);
-#else
-	const struct afd *afd;
-	struct addrinfo *cur;
-	int error;
-	char *cp, *hostname2 = NULL, *scope, *addr;
-	struct sockaddr_in6 *sin6;
-
-	afd = find_afd(pai->ai_family);
-	if (afd == NULL)
-		return 0;
-
-	if (!afd->a_scoped)
-		return explore_numeric(pai, hostname, servname, res);
-
-	cp = strchr(hostname, SCOPE_DELIMITER);
-	if (cp == NULL)
-		return explore_numeric(pai, hostname, servname, res);
-
-	/*
-	 * Handle special case of <scoped_address><delimiter><scope id>
-	 */
-	hostname2 = strdup(hostname);
-	if (hostname2 == NULL)
-		return EAI_MEMORY;
-	/* terminate at the delimiter */
-	hostname2[cp - hostname] = '\0';
-	addr = hostname2;
-	scope = cp + 1;
-
-	error = explore_numeric(pai, addr, servname, res);
-	if (error == 0) {
-		u_int32_t scopeid = 0;
-
-		for (cur = *res; cur; cur = cur->ai_next) {
-			if (cur->ai_family != AF_INET6)
-				continue;
-			sin6 = (struct sockaddr_in6 *)(void *)cur->ai_addr;
-			if (!ip6_str2scopeid(scope, sin6, &scopeid)) {
-				free(hostname2);
-				return(EAI_NONAME); /*%< XXX: is return OK? */
-			}
-#ifdef HAVE_SIN6_SCOPE_ID
-			sin6->sin6_scope_id = scopeid;
-#endif
-		}
-	}
-
-	free(hostname2);
-
-	return error;
-#endif
-}
-
-static int
-get_canonname(pai, ai, str)
-	const struct addrinfo *pai;
-	struct addrinfo *ai;
-	const char *str;
-{
-	if ((pai->ai_flags & AI_CANONNAME) != 0) {
-		ai->ai_canonname = (char *)malloc(strlen(str) + 1);
-		if (ai->ai_canonname == NULL)
-			return EAI_MEMORY;
-		strcpy(ai->ai_canonname, str);
-	}
-	return 0;
-}
-
-static struct addrinfo *
-get_ai(pai, afd, addr)
-	const struct addrinfo *pai;
-	const struct afd *afd;
-	const char *addr;
-{
-	char *p;
-	struct addrinfo *ai;
-
-	ai = (struct addrinfo *)malloc(sizeof(struct addrinfo)
-		+ (afd->a_socklen));
-	if (ai == NULL)
-		return NULL;
-
-	memcpy(ai, pai, sizeof(struct addrinfo));
-	ai->ai_addr = (struct sockaddr *)(void *)(ai + 1);
-	memset(ai->ai_addr, 0, (size_t)afd->a_socklen);
-#ifdef HAVE_SA_LEN
-	ai->ai_addr->sa_len = afd->a_socklen;
-#endif
-	ai->ai_addrlen = afd->a_socklen;
-	ai->ai_addr->sa_family = ai->ai_family = afd->a_af;
-	p = (char *)(void *)(ai->ai_addr);
-	memcpy(p + afd->a_off, addr, (size_t)afd->a_addrlen);
-	return ai;
-}
-
-/* XXX need to malloc() the same way we do from other functions! */
-static struct addrinfo *
-copy_ai(pai)
-	const struct addrinfo *pai;
-{
-	struct addrinfo *ai;
-	size_t l;
-
-	l = sizeof(*ai) + pai->ai_addrlen;
-	if ((ai = (struct addrinfo *)malloc(l)) == NULL)
-		return NULL;
-	memset(ai, 0, l);
-	memcpy(ai, pai, sizeof(*ai));
-	ai->ai_addr = (struct sockaddr *)(void *)(ai + 1);
-	memcpy(ai->ai_addr, pai->ai_addr, pai->ai_addrlen);
-
-	if (pai->ai_canonname) {
-		l = strlen(pai->ai_canonname) + 1;
-		if ((ai->ai_canonname = malloc(l)) == NULL) {
-			free(ai);
-			return NULL;
-		}
-		strcpy(ai->ai_canonname, pai->ai_canonname);	/* (checked) */
-	} else {
-		/* just to make sure */
-		ai->ai_canonname = NULL;
-	}
-
-	ai->ai_next = NULL;
-
-	return ai;
-}
-
-static int
-get_portmatch(const struct addrinfo *ai, const char *servname) {
-
-	/* get_port does not touch first argument. when matchonly == 1. */
-	/* LINTED const cast */
-	return get_port((const struct addrinfo *)ai, servname, 1);
-}
-
-static int
-get_port(const struct addrinfo *ai, const char *servname, int matchonly) {
-	const char *proto;
-	struct servent *sp;
-	int port;
-	int allownumeric;
-
-	if (servname == NULL)
-		return 0;
-	switch (ai->ai_family) {
-	case AF_INET:
-#ifdef AF_INET6
-	case AF_INET6:
-#endif
-		break;
-	default:
-		return 0;
-	}
-
-	switch (ai->ai_socktype) {
-	case SOCK_RAW:
-		return EAI_SERVICE;
-	case SOCK_DGRAM:
-	case SOCK_STREAM:
-		allownumeric = 1;
-		break;
-	case ANY:
-		switch (ai->ai_family) {
-		case AF_INET:
-#ifdef AF_INET6
-		case AF_INET6:
-#endif
-			allownumeric = 1;
-			break;
-		default:
-			allownumeric = 0;
-			break;
-		}
-		break;
-	default:
-		return EAI_SOCKTYPE;
-	}
-
-	if (str_isnumber(servname)) {
-		if (!allownumeric)
-			return EAI_SERVICE;
-		port = atoi(servname);
-		if (port < 0 || port > 65535)
-			return EAI_SERVICE;
-		port = htons(port);
-	} else {
-		switch (ai->ai_socktype) {
-		case SOCK_DGRAM:
-			proto = "udp";
-			break;
-		case SOCK_STREAM:
-			proto = "tcp";
-			break;
-		default:
-			proto = NULL;
-			break;
-		}
-
-		if ((sp = getservbyname(servname, proto)) == NULL)
-			return EAI_SERVICE;
-		port = sp->s_port;
-	}
-
-	if (!matchonly) {
-		switch (ai->ai_family) {
-		case AF_INET:
-			((struct sockaddr_in *)(void *)
-			    ai->ai_addr)->sin_port = port;
-			break;
-		case AF_INET6:
-			((struct sockaddr_in6 *)(void *)
-			    ai->ai_addr)->sin6_port = port;
-			break;
-		}
-	}
-
-	return 0;
-}
-
-static const struct afd *
-find_afd(af)
-	int af;
-{
-	const struct afd *afd;
-
-	if (af == PF_UNSPEC)
-		return NULL;
-	for (afd = afdl; afd->a_af; afd++) {
-		if (afd->a_af == af)
-			return afd;
-	}
-	return NULL;
-}
-
-/*%
- * post-2553: AI_ADDRCONFIG check.  if we use getipnodeby* as backend, backend
- * will take care of it.
- * the semantics of AI_ADDRCONFIG is not defined well.  we are not sure
- * if the code is right or not.
- */
-static int
-addrconfig(af)
-	int af;
-{
-	int s;
-
-	/* XXX errno */
-	s = socket(af, SOCK_DGRAM, 0);
-	if (s < 0) {
-		if (errno != EMFILE)
-			return 0;
-	} else
-		close(s);
-	return 1;
-}
-
-/* convert a string to a scope identifier. XXX: IPv6 specific */
-static int
-ip6_str2scopeid(char *scope, struct sockaddr_in6 *sin6,
-		u_int32_t *scopeidp)
-{
-	u_int32_t scopeid;
-	u_long lscopeid;
-	struct in6_addr *a6 = &sin6->sin6_addr;
-	char *ep;
-	
-	/* empty scopeid portion is invalid */
-	if (*scope == '\0')
-		return (0);
-
-#ifdef USE_IFNAMELINKID
-	if (IN6_IS_ADDR_LINKLOCAL(a6) || IN6_IS_ADDR_MC_LINKLOCAL(a6) ||
-	    IN6_IS_ADDR_MC_NODELOCAL(a6)) {
-		/*
-		 * Using interface names as link indices can be allowed
-		 * only when we can assume a one-to-one mappings between
-		 * links and interfaces.  See comments in getnameinfo.c.
-		 */
-		scopeid = if_nametoindex(scope);
-		if (scopeid == 0)
-			goto trynumeric;
-		*scopeidp = scopeid;
-		return (1);
-	}
-#endif
-
-	/* still unclear about literal, allow numeric only - placeholder */
-	if (IN6_IS_ADDR_SITELOCAL(a6) || IN6_IS_ADDR_MC_SITELOCAL(a6))
-		goto trynumeric;
-	if (IN6_IS_ADDR_MC_ORGLOCAL(a6))
-		goto trynumeric;
-	else
-		goto trynumeric;	/*%< global */
-	/* try to convert to a numeric id as a last resort */
-trynumeric:
-	errno = 0;
-	lscopeid = strtoul(scope, &ep, 10);
-	scopeid = lscopeid & 0xffffffff;
-	if (errno == 0 && ep && *ep == '\0' && scopeid == lscopeid) {
-		*scopeidp = scopeid;
-		return (1);
-	} else
-		return (0);
-}
-
-struct addrinfo *
-hostent2addrinfo(hp, pai)
-	struct hostent *hp;
-	const struct addrinfo *pai;
-{
-	int i, af, error = 0;
-	char **aplist = NULL, *ap;
-	struct addrinfo sentinel, *cur;
-	const struct afd *afd;
-
-	af = hp->h_addrtype;
-	if (pai->ai_family != AF_UNSPEC && af != pai->ai_family)
-		return(NULL);
-
-	afd = find_afd(af);
-	if (afd == NULL)
-		return(NULL);
-
-	aplist = hp->h_addr_list;
-
-	memset(&sentinel, 0, sizeof(sentinel));
-	cur = &sentinel;
-
-	for (i = 0; (ap = aplist[i]) != NULL; i++) {
-#if 0				/*%< the trick seems too much */
-		af = hp->h_addr_list;
-		if (af == AF_INET6 &&
-		    IN6_IS_ADDR_V4MAPPED((struct in6_addr *)ap)) {
-			af = AF_INET;
-			ap = ap + sizeof(struct in6_addr)
-				- sizeof(struct in_addr);
-		}
-		afd = find_afd(af);
-		if (afd == NULL)
-			continue;
-#endif /* 0 */
-
-		GET_AI(cur->ai_next, afd, ap);
-
-		/* GET_PORT(cur->ai_next, servname); */
-		if ((pai->ai_flags & AI_CANONNAME) != 0) {
-			/*
-			 * RFC2553 says that ai_canonname will be set only for
-			 * the first element.  we do it for all the elements,
-			 * just for convenience.
-			 */
-			GET_CANONNAME(cur->ai_next, hp->h_name);
-		}
-		while (cur->ai_next) /*%< no need to loop, actually. */
-			cur = cur->ai_next;
-		continue;
-
-	free:
-		if (cur->ai_next)
-			freeaddrinfo(cur->ai_next);
-		cur->ai_next = NULL;
-		/* continue, without tht pointer CUR advanced. */
-	}
-
-	return(sentinel.ai_next);
-}
-
-struct addrinfo *
-addr2addrinfo(pai, cp)
-	const struct addrinfo *pai;
-	const char *cp;
-{
-	const struct afd *afd;
-
-	afd = find_afd(pai->ai_family);
-	if (afd == NULL)
-		return(NULL);
-
-	return(get_ai(pai, afd, cp));
-}
-
-static struct net_data *
-init()
-{
-	struct net_data *net_data;
-
-	if (!(net_data = net_data_init(NULL)))
-		goto error;
-	if (!net_data->ho) {
-		net_data->ho = (*net_data->irs->ho_map)(net_data->irs);
-		if (!net_data->ho || !net_data->res) {
-error:
-			errno = EIO;
-			if (net_data && net_data->res)
-				RES_SET_H_ERRNO(net_data->res, NETDB_INTERNAL);
-			return (NULL);
-		}
-
-		(*net_data->ho->res_set)(net_data->ho, net_data->res, NULL);
-	}
-
-	return (net_data);
-}
diff --git a/contrib/bind9/lib/bind/irs/getgrent.c b/contrib/bind9/lib/bind/irs/getgrent.c
deleted file mode 100644
index fe91ab3..0000000
--- a/contrib/bind9/lib/bind/irs/getgrent.c
+++ /dev/null
@@ -1,224 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996-1999 by 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.
- */
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: getgrent.c,v 1.4.18.1 2005/04/27 05:00:57 sra Exp $";
-#endif
-
-/* Imports */
-
-#include "port_before.h"
-
-#if !defined(WANT_IRS_GR) || defined(__BIND_NOSTATIC)
-static int __bind_irs_gr_unneeded;
-#else
-
-#include <sys/types.h>
-
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-
-#include <errno.h>
-#include <grp.h>
-#include <resolv.h>
-#include <stdio.h>
-#include <string.h>
-#include <unistd.h>
-
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_data.h"
-
-/* Forward */
-
-static struct net_data *init(void);
-void			endgrent(void);
-
-/* Public */
-
-struct group *
-getgrent() {
-	struct net_data *net_data = init();
-
-	return (getgrent_p(net_data));
-}
-
-struct group *
-getgrnam(const char *name) {
-	struct net_data *net_data = init();
-
-	return (getgrnam_p(name, net_data));
-}
-
-struct group *
-getgrgid(gid_t gid) {
-	struct net_data *net_data = init();
-
-	return (getgrgid_p(gid, net_data));
-}
-
-int
-setgroupent(int stayopen) {
-	struct net_data *net_data = init();
-
-	return (setgroupent_p(stayopen, net_data));
-}
-
-#ifdef SETGRENT_VOID
-void
-setgrent(void) {
-	struct net_data *net_data = init();
-
-	setgrent_p(net_data);
-}
-#else
-int
-setgrent(void) {
-	struct net_data *net_data = init();
-
-	return (setgrent_p(net_data));
-}
-#endif /* SETGRENT_VOID */
-
-void
-endgrent() {
-	struct net_data *net_data = init();
-
-	endgrent_p(net_data);
-}
-
-int
-getgrouplist(GETGROUPLIST_ARGS) {
-	struct net_data *net_data = init();
-
-	return (getgrouplist_p(name, basegid, groups, ngroups, net_data));
-}
-
-/* Shared private. */
-
-struct group *
-getgrent_p(struct net_data *net_data) {
-	struct irs_gr *gr;
-
-	if (!net_data || !(gr = net_data->gr))
-		return (NULL);
-	net_data->gr_last = (*gr->next)(gr);
-	return (net_data->gr_last);
-}
-
-struct group *
-getgrnam_p(const char *name, struct net_data *net_data) {
-	struct irs_gr *gr;
-
-	if (!net_data || !(gr = net_data->gr))
-		return (NULL);
-	if (net_data->gr_stayopen && net_data->gr_last &&
-	    !strcmp(net_data->gr_last->gr_name, name))
-		return (net_data->gr_last);
-	net_data->gr_last = (*gr->byname)(gr, name);
-	if (!net_data->gr_stayopen)
-		endgrent();
-	return (net_data->gr_last);
-}
-
-struct group *
-getgrgid_p(gid_t gid, struct net_data *net_data) {
-	struct irs_gr *gr;
-
-	if (!net_data || !(gr = net_data->gr))
-		return (NULL);
-	if (net_data->gr_stayopen && net_data->gr_last &&
-	    (gid_t)net_data->gr_last->gr_gid == gid)
-		return (net_data->gr_last);
-	net_data->gr_last = (*gr->bygid)(gr, gid);
-	if (!net_data->gr_stayopen)
-		endgrent();
-	return (net_data->gr_last);
-}
-
-int
-setgroupent_p(int stayopen, struct net_data *net_data) {
-	struct irs_gr *gr;
-
-	if (!net_data || !(gr = net_data->gr))
-		return (0);
-	(*gr->rewind)(gr);
-	net_data->gr_stayopen = (stayopen != 0);
-	if (stayopen == 0)
-		net_data_minimize(net_data);
-	return (1);
-}
-
-#ifdef SETGRENT_VOID
-void
-setgrent_p(struct net_data *net_data) {
-	(void)setgroupent_p(0, net_data);
-}
-#else
-int
-setgrent_p(struct net_data *net_data) {
-	return (setgroupent_p(0, net_data));
-}
-#endif /* SETGRENT_VOID */
-
-void
-endgrent_p(struct net_data *net_data) {
-	struct irs_gr *gr;
-
-	if ((net_data != NULL) && ((gr = net_data->gr) != NULL))
-		(*gr->minimize)(gr);
-}
-
-int
-getgrouplist_p(const char *name, gid_t basegid, gid_t *groups, int *ngroups,
-	       struct net_data *net_data) {
-	struct irs_gr *gr;
-
-	if (!net_data || !(gr = net_data->gr)) {
-		*ngroups = 0;
-		return (-1);
-	}
-	return ((*gr->list)(gr, name, basegid, groups, ngroups));
-}
-
-/* Private */
-
-static struct net_data *
-init() {
-	struct net_data *net_data;
-
-	if (!(net_data = net_data_init(NULL)))
-		goto error;
-	if (!net_data->gr) {
-		net_data->gr = (*net_data->irs->gr_map)(net_data->irs);
-
-		if (!net_data->gr || !net_data->res) {
- error: 
-			errno = EIO;
-			return (NULL);
-		}
-		(*net_data->gr->res_set)(net_data->gr, net_data->res,
-					 NULL);
-	}
-	
-	return (net_data);
-}
-
-#endif /* WANT_IRS_GR */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/getgrent_r.c b/contrib/bind9/lib/bind/irs/getgrent_r.c
deleted file mode 100644
index 1f7d94d..0000000
--- a/contrib/bind9/lib/bind/irs/getgrent_r.c
+++ /dev/null
@@ -1,230 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1998-1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: getgrent_r.c,v 1.6.18.1 2005/04/27 05:00:57 sra Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-#include <port_before.h>
-#if !defined(_REENTRANT) || !defined(DO_PTHREADS) || !defined(WANT_IRS_PW)
-	static int getgrent_r_not_required = 0;
-#else
-#include <errno.h>
-#include <string.h>
-#include <stdio.h>
-#include <sys/types.h>
-#if (defined(POSIX_GETGRNAM_R) || defined(POSIX_GETGRGID_R)) && \
-    defined(_POSIX_PTHREAD_SEMANTICS)
-	/* turn off solaris remapping in <grp.h> */
-#define _UNIX95
-#undef _POSIX_PTHREAD_SEMANTICS
-#include <grp.h>
-#define _POSIX_PTHREAD_SEMANTICS 1
-#else
-#include <grp.h>
-#endif
-#include <sys/param.h>
-#include <port_after.h>
-
-#ifdef GROUP_R_RETURN
-
-static int
-copy_group(struct group *, struct group *, char *buf, int buflen);
-
-/* POSIX 1003.1c */
-#ifdef POSIX_GETGRNAM_R
-int
-__posix_getgrnam_r(const char *name,  struct group *gptr,
-		char *buf, int buflen, struct group **result) {
-#else
-int
-getgrnam_r(const char *name,  struct group *gptr,
-		char *buf, size_t buflen, struct group **result) {
-#endif
-	struct group *ge = getgrnam(name);
-	int res;
-
-	if (ge == NULL) {
-		*result = NULL;
-		return (0);
-	}
-
-	res = copy_group(ge, gptr, buf, buflen);
-	*result = res ? NULL : gptr;
-	return (res);
-}
-
-#ifdef POSIX_GETGRNAM_R
-struct group *
-getgrnam_r(const char *name,  struct group *gptr,
-		char *buf, int buflen) {
-	struct group *ge = getgrnam(name);
-	int res;
-
-	if (ge == NULL)
-		return (NULL);
-	res = copy_group(ge, gptr, buf, buflen);
-	return (res ? NULL : gptr);
-}
-#endif /* POSIX_GETGRNAM_R */
-
-/* POSIX 1003.1c */
-#ifdef POSIX_GETGRGID_R
-int
-__posix_getgrgid_r(gid_t gid, struct group *gptr,
-		char *buf, int buflen, struct group **result) {
-#else /* POSIX_GETGRGID_R */
-int
-getgrgid_r(gid_t gid, struct group *gptr,
-		char *buf, size_t buflen, struct group **result) {
-#endif /* POSIX_GETGRGID_R */
-	struct group *ge = getgrgid(gid);
-	int res;
-
-	if (ge == NULL) {
-		*result = NULL;
-		return (0);
-	}
-
-	res = copy_group(ge, gptr, buf, buflen);
-	*result = res ? NULL : gptr;
-	return (res);
-}
-
-#ifdef POSIX_GETGRGID_R
-struct group *
-getgrgid_r(gid_t gid, struct group *gptr,
-		char *buf, int buflen) {
-	struct group *ge = getgrgid(gid);
-	int res;
-
-	if (ge == NULL)
-		return (NULL);
-
-	res = copy_group(ge, gptr, buf, buflen);
-	return (res ? NULL : gptr);
-}
-#endif
-
-/*%
- *	These assume a single context is in operation per thread.
- *	If this is not the case we will need to call irs directly
- *	rather than through the base functions.
- */
-
-GROUP_R_RETURN
-getgrent_r(struct group *gptr, GROUP_R_ARGS) {
-	struct group *ge = getgrent();
-	int res;
-
-	if (ge == NULL) {
-		return (GROUP_R_BAD);
-	}
-
-	res = copy_group(ge, gptr, buf, buflen);
-	return (res ? GROUP_R_BAD : GROUP_R_OK);
-}
-
-GROUP_R_SET_RETURN
-setgrent_r(GROUP_R_ENT_ARGS) {
-
-	setgrent();
-#ifdef GROUP_R_SET_RESULT
-	return (GROUP_R_SET_RESULT);
-#endif
-}
-
-GROUP_R_END_RETURN
-endgrent_r(GROUP_R_ENT_ARGS) {
-
-	endgrent();
-	GROUP_R_END_RESULT(GROUP_R_OK);
-}
-
-
-#if 0
-	/* XXX irs does not have a fgetgrent() */
-GROUP_R_RETURN
-fgetgrent_r(FILE *f, struct group *gptr, GROUP_R_ARGS) {
-	struct group *ge = fgetgrent(f);
-	int res;
-
-	if (ge == NULL)
-		return (GROUP_R_BAD);
-
-	res = copy_group(ge, gptr, buf, buflen);
-	return (res ? GROUP_R_BAD : GROUP_R_OK);
-}
-#endif
-
-/* Private */
-
-static int
-copy_group(struct group *ge, struct group *gptr, char *buf, int buflen) {
-	char *cp;
-	int i, n;
-	int numptr, len;
-
-	/* Find out the amount of space required to store the answer. */
-	numptr = 1; /*%< NULL ptr */
-	len = (char *)ALIGN(buf) - buf;
-	for (i = 0; ge->gr_mem[i]; i++, numptr++) {
-		len += strlen(ge->gr_mem[i]) + 1;
-	}
-	len += strlen(ge->gr_name) + 1;
-	len += strlen(ge->gr_passwd) + 1;
-	len += numptr * sizeof(char*);
-	
-	if (len > buflen) {
-		errno = ERANGE;
-		return (ERANGE);
-	}
-
-	/* copy group id */
-	gptr->gr_gid = ge->gr_gid;
-
-	cp = (char *)ALIGN(buf) + numptr * sizeof(char *);
-
-	/* copy official name */
-	n = strlen(ge->gr_name) + 1;
-	strcpy(cp, ge->gr_name);
-	gptr->gr_name = cp;
-	cp += n;
-
-	/* copy member list */
-	gptr->gr_mem = (char **)ALIGN(buf);
-	for (i = 0 ; ge->gr_mem[i]; i++) {
-		n = strlen(ge->gr_mem[i]) + 1;
-		strcpy(cp, ge->gr_mem[i]);
-		gptr->gr_mem[i] = cp;
-		cp += n;
-	}
-	gptr->gr_mem[i] = NULL;
-
-	/* copy password */
-	n = strlen(ge->gr_passwd) + 1;
-	strcpy(cp, ge->gr_passwd);
-	gptr->gr_passwd = cp;
-	cp += n;
-
-	return (0);
-}
-#else /* GROUP_R_RETURN */
-	static int getgrent_r_unknown_system = 0;
-#endif /* GROUP_R_RETURN */
-#endif /* !def(_REENTRANT) || !def(DO_PTHREADS) || !def(WANT_IRS_PW) */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/gethostent.c b/contrib/bind9/lib/bind/irs/gethostent.c
deleted file mode 100644
index 23aaa30..0000000
--- a/contrib/bind9/lib/bind/irs/gethostent.c
+++ /dev/null
@@ -1,1070 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996-1999 by 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.
- */
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: gethostent.c,v 1.6.18.2 2006/01/10 05:09:08 marka Exp $";
-#endif
-
-/* Imports */
-
-#include "port_before.h"
-
-#if !defined(__BIND_NOSTATIC)
-
-#include <sys/types.h>
-#include <sys/param.h>
-#include <sys/socket.h>
-#include <sys/ioctl.h>
-#include <netinet/in.h>
-#include <net/if.h>
-#include <arpa/inet.h>
-#include <arpa/nameser.h>
-
-#include <ctype.h>
-#include <errno.h>
-#include <stdlib.h>
-#include <netdb.h>
-#include <resolv.h>
-#include <stdio.h>
-#include <string.h>
-#include <unistd.h>
-
-#include <irs.h>
-#include <isc/memcluster.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "irs_data.h"
-
-/* Definitions */
-
-struct pvt {
-	char *		aliases[1];
-	char *		addrs[2];
-	char		addr[NS_IN6ADDRSZ];
-	char		name[NS_MAXDNAME + 1];
-	struct hostent	host;
-};
-
-/* Forward */
-
-static struct net_data *init(void);
-static void		freepvt(struct net_data *);
-static struct hostent  *fakeaddr(const char *, int, struct net_data *);
-
-
-/* Public */
-
-struct hostent *
-gethostbyname(const char *name) {
-	struct net_data *net_data = init();
-
-	return (gethostbyname_p(name, net_data));
-}
-
-struct hostent *
-gethostbyname2(const char *name, int af) {
-	struct net_data *net_data = init();
-
-	return (gethostbyname2_p(name, af, net_data));
-}
-
-struct hostent *
-gethostbyaddr(const char *addr, int len, int af) {
-	struct net_data *net_data = init();
-
-	return (gethostbyaddr_p(addr, len, af, net_data));
-}
-
-struct hostent *
-gethostent() {
-	struct net_data *net_data = init();
-
-	return (gethostent_p(net_data));
-}
-
-void
-sethostent(int stayopen) {
-	struct net_data *net_data = init();
-	sethostent_p(stayopen, net_data);
-}
-
-
-void
-endhostent() {
-	struct net_data *net_data = init();
-	endhostent_p(net_data);
-}
-
-/* Shared private. */
-
-struct hostent *
-gethostbyname_p(const char *name, struct net_data *net_data) {
-	struct hostent *hp;
-
-	if (!net_data)
-		return (NULL);
-
-	if (net_data->res->options & RES_USE_INET6) {
-		hp = gethostbyname2_p(name, AF_INET6, net_data);
-		if (hp)
-			return (hp);
-	}
-	return (gethostbyname2_p(name, AF_INET, net_data));
-}
-
-struct hostent *
-gethostbyname2_p(const char *name, int af, struct net_data *net_data) {
-	struct irs_ho *ho;
-	char tmp[NS_MAXDNAME];
-	struct hostent *hp;
-	const char *cp;
-	char **hap;
-
-	if (!net_data || !(ho = net_data->ho))
-		return (NULL);
-	if (net_data->ho_stayopen && net_data->ho_last &&
-	    net_data->ho_last->h_addrtype == af) {
-		if (ns_samename(name, net_data->ho_last->h_name) == 1)
-			return (net_data->ho_last);
-		for (hap = net_data->ho_last->h_aliases; hap && *hap; hap++)
-			if (ns_samename(name, *hap) == 1)
-				return (net_data->ho_last);
-	}
-	if (!strchr(name, '.') && (cp = res_hostalias(net_data->res, name,
-						      tmp, sizeof tmp)))
-		name = cp;
-	if ((hp = fakeaddr(name, af, net_data)) != NULL)
-		return (hp);
-	net_data->ho_last = (*ho->byname2)(ho, name, af);
-	if (!net_data->ho_stayopen)
-		endhostent();
-	return (net_data->ho_last);
-}
-
-struct hostent *
-gethostbyaddr_p(const char *addr, int len, int af, struct net_data *net_data) {
-	struct irs_ho *ho;
-	char **hap;
-
-	if (!net_data || !(ho = net_data->ho))
-		return (NULL);
-	if (net_data->ho_stayopen && net_data->ho_last &&
-	    net_data->ho_last->h_length == len)
-		for (hap = net_data->ho_last->h_addr_list;
-		     hap && *hap;
-		     hap++)
-			if (!memcmp(addr, *hap, len))
-				return (net_data->ho_last);
-	net_data->ho_last = (*ho->byaddr)(ho, addr, len, af);
-	if (!net_data->ho_stayopen)
-		endhostent();
-	return (net_data->ho_last);
-}
-
-
-struct hostent *
-gethostent_p(struct net_data *net_data) {
-	struct irs_ho *ho;
-	struct hostent *hp;
-
-	if (!net_data || !(ho = net_data->ho))
-		return (NULL);
-	while ((hp = (*ho->next)(ho)) != NULL &&
-	       hp->h_addrtype == AF_INET6 &&
-	       (net_data->res->options & RES_USE_INET6) == 0U)
-		continue;
-	net_data->ho_last = hp;
-	return (net_data->ho_last);
-}
-
-
-void
-sethostent_p(int stayopen, struct net_data *net_data) {
-	struct irs_ho *ho;
-
-	if (!net_data || !(ho = net_data->ho))
-		return;
-	freepvt(net_data);
-	(*ho->rewind)(ho);
-	net_data->ho_stayopen = (stayopen != 0);
-	if (stayopen == 0)
-		net_data_minimize(net_data);
-}
-
-void
-endhostent_p(struct net_data *net_data) {
-	struct irs_ho *ho;
-
-	if ((net_data != NULL) && ((ho = net_data->ho) != NULL))
-		(*ho->minimize)(ho);
-}
-
-#ifndef IN6_IS_ADDR_V4COMPAT
-static const unsigned char in6addr_compat[12] = {
-	0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
-#define IN6_IS_ADDR_V4COMPAT(x) (!memcmp((x)->s6_addr, in6addr_compat, 12) && \
-				 ((x)->s6_addr[12] != 0 || \
-				  (x)->s6_addr[13] != 0 || \
-				  (x)->s6_addr[14] != 0 || \
-				   ((x)->s6_addr[15] != 0 && \
-				    (x)->s6_addr[15] != 1)))
-#endif
-#ifndef IN6_IS_ADDR_V4MAPPED
-#define IN6_IS_ADDR_V4MAPPED(x) (!memcmp((x)->s6_addr, in6addr_mapped, 12))
-#endif
-
-static const unsigned char in6addr_mapped[12] = {
-	0, 0, 0, 0,  0, 0, 0, 0,  0, 0, 0xff, 0xff };
-
-static int scan_interfaces(int *, int *);
-static struct hostent *copyandmerge(struct hostent *, struct hostent *, int, int *);
-
-/*%
- *	Public functions
- */
-
-/*%
- *	AI_V4MAPPED + AF_INET6
- *	If no IPv6 address then a query for IPv4 and map returned values.
- *
- *	AI_ALL + AI_V4MAPPED + AF_INET6
- *	Return IPv6 and IPv4 mapped.
- *
- *	AI_ADDRCONFIG
- *	Only return IPv6 / IPv4 address if there is an interface of that
- *	type active.
- */
-
-struct hostent *
-getipnodebyname(const char *name, int af, int flags, int *error_num) {
-	int have_v4 = 1, have_v6 = 1;
-	struct in_addr in4;
-	struct in6_addr in6;
-	struct hostent he, *he1 = NULL, *he2 = NULL, *he3;
-	int v4 = 0, v6 = 0;
-	struct net_data *net_data = init();
-	u_long options;
-	int tmp_err;
-
-	if (net_data == NULL) {
-		*error_num = NO_RECOVERY;
-		return (NULL);
-	}
-
-	/* If we care about active interfaces then check. */
-	if ((flags & AI_ADDRCONFIG) != 0)
-		if (scan_interfaces(&have_v4, &have_v6) == -1) {
-			*error_num = NO_RECOVERY;
-			return (NULL);
-		}
-
-	/* Check for literal address. */
-	if ((v4 = inet_pton(AF_INET, name, &in4)) != 1)
-		v6 = inet_pton(AF_INET6, name, &in6);
-
-	/* Impossible combination? */
-	 
-	if ((af == AF_INET6 && (flags & AI_V4MAPPED) == 0 && v4 == 1) ||
-	    (af == AF_INET && v6 == 1) ||
-	    (have_v4 == 0 && v4 == 1) ||
-	    (have_v6 == 0 && v6 == 1) ||
-	    (have_v4 == 0 && af == AF_INET) ||
-	    (have_v6 == 0 && af == AF_INET6)) {
-		*error_num = HOST_NOT_FOUND;
-		return (NULL);
-	}
-
-	/* Literal address? */
-	if (v4 == 1 || v6 == 1) {
-		char *addr_list[2];
-		char *aliases[1];
-
-		DE_CONST(name, he.h_name);
-		he.h_addr_list = addr_list;
-		he.h_addr_list[0] = (v4 == 1) ? (char *)&in4 : (char *)&in6;
-		he.h_addr_list[1] = NULL;
-		he.h_aliases = aliases;
-		he.h_aliases[0] = NULL;
-		he.h_length = (v4 == 1) ? INADDRSZ : IN6ADDRSZ;
-		he.h_addrtype = (v4 == 1) ? AF_INET : AF_INET6;
-		return (copyandmerge(&he, NULL, af, error_num));
-	}
-
-	options = net_data->res->options;
-	net_data->res->options &= ~RES_USE_INET6;
-
-	tmp_err = NO_RECOVERY;
-	if (have_v6 && af == AF_INET6) {
-		he2 = gethostbyname2_p(name, AF_INET6, net_data);
-		if (he2 != NULL) {
-			he1 = copyandmerge(he2, NULL, af, error_num);
-			if (he1 == NULL)
-				return (NULL);
-			he2 = NULL;
-		} else {
-			tmp_err = net_data->res->res_h_errno;
-		}
-	}
-
-	if (have_v4 &&
-	    ((af == AF_INET) ||
-	     (af == AF_INET6 && (flags & AI_V4MAPPED) != 0 &&
-	      (he1 == NULL || (flags & AI_ALL) != 0)))) {
-		he2 = gethostbyname2_p(name, AF_INET, net_data);
-		if (he1 == NULL && he2 == NULL) {
-			*error_num = net_data->res->res_h_errno;
-			return (NULL);
-		} 
-	} else
-		*error_num = tmp_err;
-
-	net_data->res->options = options;
-
-	he3 = copyandmerge(he1, he2, af, error_num);
-
-	if (he1 != NULL)
-		freehostent(he1);
-	return (he3);
-}
-
-struct hostent *
-getipnodebyaddr(const void *src, size_t len, int af, int *error_num) {
-	struct hostent *he1, *he2;
-	struct net_data *net_data = init();
-
-	/* Sanity Checks. */
-	if (src == NULL) {
-		*error_num = NO_RECOVERY;
-		return (NULL);
-	}
-		
-	switch (af) {
-	case AF_INET:
-		if (len != (size_t)INADDRSZ) {
-			*error_num = NO_RECOVERY;
-			return (NULL);
-		}
-		break;
-	case AF_INET6:
-		if (len != (size_t)IN6ADDRSZ) {
-			*error_num = NO_RECOVERY;
-			return (NULL);
-		}
-		break;
-	default:
-		*error_num = NO_RECOVERY;
-		return (NULL);
-	}
-
-	/*
-	 * Lookup IPv4 and IPv4 mapped/compatible addresses
-	 */
-	if ((af == AF_INET6 &&
-	     IN6_IS_ADDR_V4COMPAT((const struct in6_addr *)src)) ||
-	    (af == AF_INET6 &&
-	     IN6_IS_ADDR_V4MAPPED((const struct in6_addr *)src)) ||
-	    (af == AF_INET)) {
-		const char *cp = src;
-
-		if (af == AF_INET6)
-			cp += 12;
-		he1 = gethostbyaddr_p(cp, 4, AF_INET, net_data);
-		if (he1 == NULL) {
-			*error_num = net_data->res->res_h_errno;
-			return (NULL);
-		}
-		he2 = copyandmerge(he1, NULL, af, error_num);
-		if (he2 == NULL)
-			return (NULL);
-		/*
-		 * Restore original address if mapped/compatible.
-		 */
-		if (af == AF_INET6)
-			memcpy(he1->h_addr, src, len);
-		return (he2);
-	}
-
-	/*
-	 * Lookup IPv6 address.
-	 */
-	if (memcmp((const struct in6_addr *)src, &in6addr_any, 16) == 0) {
-		*error_num = HOST_NOT_FOUND;
-		return (NULL);
-	}
-
-	he1 = gethostbyaddr_p(src, 16, AF_INET6, net_data);
-	if (he1 == NULL) {
-		*error_num = net_data->res->res_h_errno;
-		return (NULL);
-	}
-	return (copyandmerge(he1, NULL, af, error_num));
-}
-
-void
-freehostent(struct hostent *he) {
-	char **cpp;
-	int names = 1;
-	int addresses = 1;
-
-	memput(he->h_name, strlen(he->h_name) + 1);
-
-	cpp = he->h_addr_list;
-	while (*cpp != NULL) {
-		memput(*cpp, (he->h_addrtype == AF_INET) ?
-			     INADDRSZ : IN6ADDRSZ);
-		*cpp = NULL;
-		cpp++;
-		addresses++;
-	}
-
-	cpp = he->h_aliases;
-	while (*cpp != NULL) {
-		memput(*cpp, strlen(*cpp) + 1);
-		cpp++;
-		names++;
-	}
-
-	memput(he->h_aliases, sizeof(char *) * (names));
-	memput(he->h_addr_list, sizeof(char *) * (addresses));
-	memput(he, sizeof *he);
-}
-
-/*%
- * Private
- */
-
-/*%
- * Scan the interface table and set have_v4 and have_v6 depending
- * upon whether there are IPv4 and IPv6 interface addresses.
- *
- * Returns:
- *	0 on success
- *	-1 on failure.
- */
-
-#if defined(SIOCGLIFCONF) && defined(SIOCGLIFADDR) && \
-    !defined(IRIX_EMUL_IOCTL_SIOCGIFCONF) 
-
-#ifdef __hpux
-#define lifc_len iflc_len
-#define lifc_buf iflc_buf
-#define lifc_req iflc_req
-#define LIFCONF if_laddrconf
-#else
-#define SETFAMILYFLAGS
-#define LIFCONF lifconf
-#endif
- 
-#ifdef __hpux
-#define lifr_addr iflr_addr
-#define lifr_name iflr_name
-#define lifr_dstaddr iflr_dstaddr
-#define lifr_flags iflr_flags
-#define ss_family sa_family
-#define LIFREQ if_laddrreq
-#else
-#define LIFREQ lifreq
-#endif
-
-static void
-scan_interfaces6(int *have_v4, int *have_v6) {
-	struct LIFCONF lifc;
-	struct LIFREQ lifreq;
-	struct in_addr in4;
-	struct in6_addr in6;
-	char *buf = NULL, *cp, *cplim;
-	static unsigned int bufsiz = 4095;
-	int s, cpsize, n;
-
-	/* Get interface list from system. */
-	if ((s = socket(AF_INET6, SOCK_DGRAM, 0)) == -1)
-		goto cleanup;
-
-	/*
-	 * Grow buffer until large enough to contain all interface
-	 * descriptions.
-	 */
-	for (;;) {
-		buf = memget(bufsiz);
-		if (buf == NULL)
-			goto cleanup;
-#ifdef SETFAMILYFLAGS
-		lifc.lifc_family = AF_UNSPEC;	/*%< request all families */
-		lifc.lifc_flags = 0;
-#endif
-		lifc.lifc_len = bufsiz;
-		lifc.lifc_buf = buf;
-		if ((n = ioctl(s, SIOCGLIFCONF, (char *)&lifc)) != -1) {
-			/*
-			 * Some OS's just return what will fit rather
-			 * than set EINVAL if the buffer is too small
-			 * to fit all the interfaces in.  If 
-			 * lifc.lifc_len is too near to the end of the
-			 * buffer we will grow it just in case and
-			 * retry.
-			 */
-			if (lifc.lifc_len + 2 * sizeof(lifreq) < bufsiz)
-				break;
-		}
-		if ((n == -1) && errno != EINVAL)
-			goto cleanup;
-
-		if (bufsiz > 1000000)
-			goto cleanup;
-
-		memput(buf, bufsiz);
-		bufsiz += 4096;
-	}
-
-	/* Parse system's interface list. */
-	cplim = buf + lifc.lifc_len;    /*%< skip over if's with big ifr_addr's */
-	for (cp = buf;
-	     (*have_v4 == 0 || *have_v6 == 0) && cp < cplim;
-	     cp += cpsize) {
-		memcpy(&lifreq, cp, sizeof lifreq);
-#ifdef HAVE_SA_LEN
-#ifdef FIX_ZERO_SA_LEN
-		if (lifreq.lifr_addr.sa_len == 0)
-			lifreq.lifr_addr.sa_len = 16;
-#endif
-#ifdef HAVE_MINIMUM_IFREQ
-		cpsize = sizeof lifreq;
-		if (lifreq.lifr_addr.sa_len > sizeof (struct sockaddr))
-			cpsize += (int)lifreq.lifr_addr.sa_len -
-				(int)(sizeof (struct sockaddr));
-#else
-		cpsize = sizeof lifreq.lifr_name + lifreq.lifr_addr.sa_len;
-#endif /* HAVE_MINIMUM_IFREQ */
-#elif defined SIOCGIFCONF_ADDR
-		cpsize = sizeof lifreq;
-#else
-		cpsize = sizeof lifreq.lifr_name;
-		/* XXX maybe this should be a hard error? */
-		if (ioctl(s, SIOCGLIFADDR, (char *)&lifreq) < 0)
-			continue;
-#endif
-		switch (lifreq.lifr_addr.ss_family) {
-		case AF_INET:
-			if (*have_v4 == 0) {
-				memcpy(&in4,
-				       &((struct sockaddr_in *)
-				       &lifreq.lifr_addr)->sin_addr,
-				       sizeof in4);
-				if (in4.s_addr == INADDR_ANY)
-					break;
-				n = ioctl(s, SIOCGLIFFLAGS, (char *)&lifreq);
-				if (n < 0)
-					break;
-				if ((lifreq.lifr_flags & IFF_UP) == 0)
-					break;
-				*have_v4 = 1;
-			} 
-			break;
-		case AF_INET6:
-			if (*have_v6 == 0) {
-				memcpy(&in6,
-				       &((struct sockaddr_in6 *)
-				       &lifreq.lifr_addr)->sin6_addr, sizeof in6);
-				if (memcmp(&in6, &in6addr_any, sizeof in6) == 0)
-					break;
-				n = ioctl(s, SIOCGLIFFLAGS, (char *)&lifreq);
-				if (n < 0)
-					break;
-				if ((lifreq.lifr_flags & IFF_UP) == 0)
-					break;
-				*have_v6 = 1;
-			}
-			break;
-		}
-	}
-	if (buf != NULL)
-		memput(buf, bufsiz);
-	close(s);
-	/* printf("scan interface -> 4=%d 6=%d\n", *have_v4, *have_v6); */
-	return;
- cleanup:
-	if (buf != NULL)
-		memput(buf, bufsiz);
-	if (s != -1)
-		close(s);
-	/* printf("scan interface -> 4=%d 6=%d\n", *have_v4, *have_v6); */
-	return;
-}
-#endif
-
-#if ( defined(__linux__) || defined(__linux) || defined(LINUX) )
-#ifndef IF_NAMESIZE
-# ifdef IFNAMSIZ
-#  define IF_NAMESIZE  IFNAMSIZ
-# else
-#  define IF_NAMESIZE 16
-# endif
-#endif
-static void
-scan_linux6(int *have_v6) {
-	FILE *proc = NULL;
-	char address[33];
-	char name[IF_NAMESIZE+1];
-	int ifindex, prefix, flag3, flag4;
-	
-	proc = fopen("/proc/net/if_inet6", "r");
-	if (proc == NULL)
-		return;
-
-	if (fscanf(proc, "%32[a-f0-9] %x %x %x %x %16s\n",
-		   address, &ifindex, &prefix, &flag3, &flag4, name) == 6)
-		*have_v6 = 1;
-	fclose(proc);
-	return;
-}
-#endif
-
-static int
-scan_interfaces(int *have_v4, int *have_v6) {
-	struct ifconf ifc;
-	union {
-		char _pad[256];		/*%< leave space for IPv6 addresses */
-		struct ifreq ifreq;
-	} u;
-	struct in_addr in4;
-	struct in6_addr in6;
-	char *buf = NULL, *cp, *cplim;
-	static unsigned int bufsiz = 4095;
-	int s, n;
-	size_t cpsize;
-
-	/* Set to zero.  Used as loop terminators below. */
-	*have_v4 = *have_v6 = 0;
-
-#if defined(SIOCGLIFCONF) && defined(SIOCGLIFADDR) && \
-    !defined(IRIX_EMUL_IOCTL_SIOCGIFCONF) 
-	/*
-	 * Try to scan the interfaces using IPv6 ioctls().
-	 */
-	scan_interfaces6(have_v4, have_v6);
-	if (*have_v4 != 0 && *have_v6 != 0)
-		return (0);
-#endif
-#ifdef __linux
-	scan_linux6(have_v6);
-#endif
-
-	/* Get interface list from system. */
-	if ((s = socket(AF_INET, SOCK_DGRAM, 0)) == -1)
-		goto err_ret;
-
-	/*
-	 * Grow buffer until large enough to contain all interface
-	 * descriptions.
-	 */
-	for (;;) {
-		buf = memget(bufsiz);
-		if (buf == NULL)
-			goto err_ret;
-		ifc.ifc_len = bufsiz;
-		ifc.ifc_buf = buf;
-#ifdef IRIX_EMUL_IOCTL_SIOCGIFCONF
-		/*
-		 * This is a fix for IRIX OS in which the call to ioctl with
-		 * the flag SIOCGIFCONF may not return an entry for all the
-		 * interfaces like most flavors of Unix.
-		 */
-		if (emul_ioctl(&ifc) >= 0)
-			break;
-#else
-		if ((n = ioctl(s, SIOCGIFCONF, (char *)&ifc)) != -1) {
-			/*
-			 * Some OS's just return what will fit rather
-			 * than set EINVAL if the buffer is too small
-			 * to fit all the interfaces in.  If 
-			 * ifc.ifc_len is too near to the end of the
-			 * buffer we will grow it just in case and
-			 * retry.
-			 */
-			if (ifc.ifc_len + 2 * sizeof(u.ifreq) < bufsiz)
-				break;
-		}
-#endif
-		if ((n == -1) && errno != EINVAL)
-			goto err_ret;
-
-		if (bufsiz > 1000000)
-			goto err_ret;
-
-		memput(buf, bufsiz);
-		bufsiz += 4096;
-	}
-
-	/* Parse system's interface list. */
-	cplim = buf + ifc.ifc_len;    /*%< skip over if's with big ifr_addr's */
-	for (cp = buf;
-	     (*have_v4 == 0 || *have_v6 == 0) && cp < cplim;
-	     cp += cpsize) {
-		memcpy(&u.ifreq, cp, sizeof u.ifreq);
-#ifdef HAVE_SA_LEN
-#ifdef FIX_ZERO_SA_LEN
-		if (u.ifreq.ifr_addr.sa_len == 0)
-			u.ifreq.ifr_addr.sa_len = 16;
-#endif
-#ifdef HAVE_MINIMUM_IFREQ
-		cpsize = sizeof u.ifreq;
-		if (u.ifreq.ifr_addr.sa_len > sizeof (struct sockaddr))
-			cpsize += (int)u.ifreq.ifr_addr.sa_len -
-				(int)(sizeof (struct sockaddr));
-#else
-		cpsize = sizeof u.ifreq.ifr_name + u.ifreq.ifr_addr.sa_len;
-#endif /* HAVE_MINIMUM_IFREQ */
-		if (cpsize > sizeof u.ifreq && cpsize <= sizeof u)
-			memcpy(&u.ifreq, cp, cpsize);
-#elif defined SIOCGIFCONF_ADDR
-		cpsize = sizeof u.ifreq;
-#else
-		cpsize = sizeof u.ifreq.ifr_name;
-		/* XXX maybe this should be a hard error? */
-		if (ioctl(s, SIOCGIFADDR, (char *)&u.ifreq) < 0)
-			continue;
-#endif
-		switch (u.ifreq.ifr_addr.sa_family) {
-		case AF_INET:
-			if (*have_v4 == 0) {
-				memcpy(&in4,
-				       &((struct sockaddr_in *)
-				       &u.ifreq.ifr_addr)->sin_addr,
-				       sizeof in4);
-				if (in4.s_addr == INADDR_ANY)
-					break;
-				n = ioctl(s, SIOCGIFFLAGS, (char *)&u.ifreq);
-				if (n < 0)
-					break;
-				if ((u.ifreq.ifr_flags & IFF_UP) == 0)
-					break;
-				*have_v4 = 1;
-			} 
-			break;
-		case AF_INET6:
-			if (*have_v6 == 0) {
-				memcpy(&in6,
-				       &((struct sockaddr_in6 *)
-				       &u.ifreq.ifr_addr)->sin6_addr,
-				       sizeof in6);
-				if (memcmp(&in6, &in6addr_any, sizeof in6) == 0)
-					break;
-				n = ioctl(s, SIOCGIFFLAGS, (char *)&u.ifreq);
-				if (n < 0)
-					break;
-				if ((u.ifreq.ifr_flags & IFF_UP) == 0)
-					break;
-				*have_v6 = 1;
-			}
-			break;
-		}
-	}
-	if (buf != NULL)
-		memput(buf, bufsiz);
-	close(s);
-	/* printf("scan interface -> 4=%d 6=%d\n", *have_v4, *have_v6); */
-	return (0);
- err_ret:
-	if (buf != NULL)
-		memput(buf, bufsiz);
-	if (s != -1)
-		close(s);
-	/* printf("scan interface -> 4=%d 6=%d\n", *have_v4, *have_v6); */
-	return (-1);
-}
-
-static struct hostent *
-copyandmerge(struct hostent *he1, struct hostent *he2, int af, int *error_num) {
-	struct hostent *he = NULL;
-	int addresses = 1;	/*%< NULL terminator */
-	int names = 1;		/*%< NULL terminator */
-	int len = 0;
-	char **cpp, **npp;
-
-	/*
-	 * Work out array sizes;
-	 */
-	if (he1 != NULL) {
-		cpp = he1->h_addr_list;
-		while (*cpp != NULL) {
-			addresses++;
-			cpp++;
-		}
-		cpp = he1->h_aliases;
-		while (*cpp != NULL) {
-			names++;
-			cpp++;
-		}
-	}
-
-	if (he2 != NULL) {
-		cpp = he2->h_addr_list;
-		while (*cpp != NULL) {
-			addresses++;
-			cpp++;
-		}
-		if (he1 == NULL) {
-			cpp = he2->h_aliases;
-			while (*cpp != NULL) {
-				names++;
-				cpp++;
-			}
-		}
-	}
-
-	if (addresses == 1) {
-		*error_num = NO_ADDRESS;
-		return (NULL);
-	}
-
-	he = memget(sizeof *he);
-	if (he == NULL)
-		goto no_recovery;
-
-	he->h_addr_list = memget(sizeof(char *) * (addresses));
-	if (he->h_addr_list == NULL)
-		goto cleanup0;
-	memset(he->h_addr_list, 0, sizeof(char *) * (addresses));
-
-	/* copy addresses */
-	npp = he->h_addr_list;
-	if (he1 != NULL) {
-		cpp = he1->h_addr_list;
-		while (*cpp != NULL) {
-			*npp = memget((af == AF_INET) ? INADDRSZ : IN6ADDRSZ);
-			if (*npp == NULL)
-				goto cleanup1;
-			/* convert to mapped if required */
-			if (af == AF_INET6 && he1->h_addrtype == AF_INET) {
-				memcpy(*npp, in6addr_mapped,
-				       sizeof in6addr_mapped);
-				memcpy(*npp + sizeof in6addr_mapped, *cpp,
-				       INADDRSZ);
-			} else {
-				memcpy(*npp, *cpp,
-				       (af == AF_INET) ? INADDRSZ : IN6ADDRSZ);
-			}
-			cpp++;
-			npp++;
-		}
-	}
-
-	if (he2 != NULL) {
-		cpp = he2->h_addr_list;
-		while (*cpp != NULL) {
-			*npp = memget((af == AF_INET) ? INADDRSZ : IN6ADDRSZ);
-			if (*npp == NULL)
-				goto cleanup1;
-			/* convert to mapped if required */
-			if (af == AF_INET6 && he2->h_addrtype == AF_INET) {
-				memcpy(*npp, in6addr_mapped,
-				       sizeof in6addr_mapped);
-				memcpy(*npp + sizeof in6addr_mapped, *cpp,
-				       INADDRSZ);
-			} else {
-				memcpy(*npp, *cpp,
-				       (af == AF_INET) ? INADDRSZ : IN6ADDRSZ);
-			}
-			cpp++;
-			npp++;
-		}
-	}
-
-	he->h_aliases = memget(sizeof(char *) * (names));
-	if (he->h_aliases == NULL)
-		goto cleanup1;
-	memset(he->h_aliases, 0, sizeof(char *) * (names));
-
-	/* copy aliases */
-	npp = he->h_aliases;
-	cpp = (he1 != NULL) ? he1->h_aliases : he2->h_aliases;
-	while (*cpp != NULL) {
-		len = strlen (*cpp) + 1;
-		*npp = memget(len);
-		if (*npp == NULL)
-			goto cleanup2;
-		strcpy(*npp, *cpp);
-		npp++;
-		cpp++;
-	}
-
-	/* copy hostname */
-	he->h_name = memget(strlen((he1 != NULL) ?
-			    he1->h_name : he2->h_name) + 1);
-	if (he->h_name == NULL)
-		goto cleanup2;
-	strcpy(he->h_name, (he1 != NULL) ? he1->h_name : he2->h_name);
-
-	/* set address type and length */
-	he->h_addrtype = af;
-	he->h_length = (af == AF_INET) ? INADDRSZ : IN6ADDRSZ;
-	return(he);
-
- cleanup2:
-	cpp = he->h_aliases;
-	while (*cpp != NULL) {
-		memput(*cpp, strlen(*cpp) + 1);
-		cpp++;
-	}
-	memput(he->h_aliases, sizeof(char *) * (names));
-
- cleanup1:
-	cpp = he->h_addr_list;
-	while (*cpp != NULL) {
-		memput(*cpp, (af == AF_INET) ? INADDRSZ : IN6ADDRSZ);
-		*cpp = NULL;
-		cpp++;
-	}
-	memput(he->h_addr_list, sizeof(char *) * (addresses));
-
- cleanup0:
-	memput(he, sizeof *he);
-
- no_recovery:
-	*error_num = NO_RECOVERY;
-	return (NULL);
-}
-
-static struct net_data *
-init() {
-	struct net_data *net_data;
-
-	if (!(net_data = net_data_init(NULL)))
-		goto error;
-	if (!net_data->ho) {
-		net_data->ho = (*net_data->irs->ho_map)(net_data->irs);
-		if (!net_data->ho || !net_data->res) {
-  error:
-			errno = EIO;
-			if (net_data && net_data->res)
-				RES_SET_H_ERRNO(net_data->res, NETDB_INTERNAL);
-			return (NULL);
-		}
-	
-		(*net_data->ho->res_set)(net_data->ho, net_data->res, NULL);
-	}
-	
-	return (net_data);
-}
-
-static void
-freepvt(struct net_data *net_data) {
-	if (net_data->ho_data) {
-		free(net_data->ho_data);
-		net_data->ho_data = NULL;
-	}
-}
-
-static struct hostent *
-fakeaddr(const char *name, int af, struct net_data *net_data) {
-	struct pvt *pvt;
-
-	freepvt(net_data);
-	net_data->ho_data = malloc(sizeof (struct pvt));
-	if (!net_data->ho_data) {
-		errno = ENOMEM;
-		RES_SET_H_ERRNO(net_data->res, NETDB_INTERNAL);
-		return (NULL);
-	}
-	pvt = net_data->ho_data;
-#ifndef __bsdi__
-	/*
-	 * Unlike its forebear(inet_aton), our friendly inet_pton() is strict
-	 * in its interpretation of its input, and it will only return "1" if
-	 * the input string is a formally valid(and thus unambiguous with
-	 * respect to host names) internet address specification for this AF.
-	 *
-	 * This means "telnet 0xdeadbeef" and "telnet 127.1" are dead now.
-	 */
-	if (inet_pton(af, name, pvt->addr) != 1) {
-#else
-	/* BSDI XXX
-	 * We put this back to inet_aton -- we really want the old behavior
-	 * Long live 127.1...
-	 */
-	if ((af != AF_INET ||
-	    inet_aton(name, (struct in_addr *)pvt->addr) != 1) &&
-	    inet_pton(af, name, pvt->addr) != 1) {
-#endif
-		RES_SET_H_ERRNO(net_data->res, HOST_NOT_FOUND);
-		return (NULL);
-	}
-	strncpy(pvt->name, name, NS_MAXDNAME);
-	pvt->name[NS_MAXDNAME] = '\0';
-	if (af == AF_INET && (net_data->res->options & RES_USE_INET6) != 0U) {
-		map_v4v6_address(pvt->addr, pvt->addr);
-		af = AF_INET6;
-	}
-	pvt->host.h_addrtype = af;
-	switch(af) {
-	case AF_INET:
-		pvt->host.h_length = NS_INADDRSZ;
-		break;
-	case AF_INET6:
-		pvt->host.h_length = NS_IN6ADDRSZ;
-		break;
-	default:
-		errno = EAFNOSUPPORT;
-		RES_SET_H_ERRNO(net_data->res, NETDB_INTERNAL);
-		return (NULL);
-	}
-	pvt->host.h_name = pvt->name;
-	pvt->host.h_aliases = pvt->aliases;
-	pvt->aliases[0] = NULL;
-	pvt->addrs[0] = (char *)pvt->addr;
-	pvt->addrs[1] = NULL;
-	pvt->host.h_addr_list = pvt->addrs;
-	RES_SET_H_ERRNO(net_data->res, NETDB_SUCCESS);
-	return (&pvt->host);
-}
-
-#ifdef grot	/*%< for future use in gethostbyaddr(), for "SUNSECURITY" */
-	struct hostent *rhp;
-	char **haddr;
-	u_long old_options;
-	char hname2[MAXDNAME+1];
-
-	if (af == AF_INET) {
-	    /*
-	     * turn off search as the name should be absolute,
-	     * 'localhost' should be matched by defnames
-	     */
-	    strncpy(hname2, hp->h_name, MAXDNAME);
-	    hname2[MAXDNAME] = '\0';
-	    old_options = net_data->res->options;
-	    net_data->res->options &= ~RES_DNSRCH;
-	    net_data->res->options |= RES_DEFNAMES;
-	    if (!(rhp = gethostbyname(hname2))) {
-		net_data->res->options = old_options;
-		RES_SET_H_ERRNO(net_data->res, HOST_NOT_FOUND);
-		return (NULL);
-	    }
-	    net_data->res->options = old_options;
-	    for (haddr = rhp->h_addr_list; *haddr; haddr++)
-		if (!memcmp(*haddr, addr, INADDRSZ))
-			break;
-	    if (!*haddr) {
-		RES_SET_H_ERRNO(net_data->res, HOST_NOT_FOUND);
-		return (NULL);
-	    }
-	}
-#endif /* grot */
-#endif /*__BIND_NOSTATIC*/
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/gethostent_r.c b/contrib/bind9/lib/bind/irs/gethostent_r.c
deleted file mode 100644
index 96d2a57..0000000
--- a/contrib/bind9/lib/bind/irs/gethostent_r.c
+++ /dev/null
@@ -1,275 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1998-1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: gethostent_r.c,v 1.5.18.4 2005/09/03 12:45:14 marka Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-#include <port_before.h>
-#if !defined(_REENTRANT) || !defined(DO_PTHREADS)
-	static int gethostent_r_not_required = 0;
-#else
-#include <errno.h>
-#include <string.h>
-#include <stdio.h>
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <netdb.h>
-#include <sys/param.h>
-#include <port_after.h>
-
-#ifdef HOST_R_RETURN
-
-static HOST_R_RETURN 
-copy_hostent(struct hostent *, struct hostent *, HOST_R_COPY_ARGS);
-
-HOST_R_RETURN
-gethostbyname_r(const char *name,  struct hostent *hptr, HOST_R_ARGS) {
-	struct hostent *he = gethostbyname(name);
-#ifdef HOST_R_SETANSWER
-	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)
-		*answerp = NULL;
-	else
-		*answerp = hptr;
-	
-	return (n);
-#else
-	if (he == NULL)
-		return (HOST_R_BAD);
-
-	return (copy_hostent(he, hptr, HOST_R_COPY));
-#endif
-}
-
-HOST_R_RETURN
-gethostbyaddr_r(const char *addr, int len, int type,
-		struct hostent *hptr, HOST_R_ARGS) {
-	struct hostent *he = gethostbyaddr(addr, len, type);
-#ifdef HOST_R_SETANSWER
-	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)
-		*answerp = NULL;
-	else
-		*answerp = hptr;
-	
-	return (n);
-#else
-	if (he == NULL)
-		return (HOST_R_BAD);
-
-	return (copy_hostent(he, hptr, HOST_R_COPY));
-#endif
-}
-
-/*%
- *	These assume a single context is in operation per thread.
- *	If this is not the case we will need to call irs directly
- *	rather than through the base functions.
- */
-
-HOST_R_RETURN
-gethostent_r(struct hostent *hptr, HOST_R_ARGS) {
-	struct hostent *he = gethostent();
-#ifdef HOST_R_SETANSWER
-	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)
-		*answerp = NULL;
-	else
-		*answerp = hptr;
-	
-	return (n);
-#else
-	if (he == NULL)
-		return (HOST_R_BAD);
-
-	return (copy_hostent(he, hptr, HOST_R_COPY));
-#endif
-}
-
-HOST_R_SET_RETURN
-#ifdef HOST_R_ENT_ARGS
-sethostent_r(int stay_open, HOST_R_ENT_ARGS)
-#else
-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);
-#endif
-}
-
-HOST_R_END_RETURN
-#ifdef HOST_R_ENT_ARGS
-endhostent_r(HOST_R_ENT_ARGS)
-#else
-endhostent_r(void)
-#endif
-{
-#ifdef HOST_R_ENT_ARGS
-	UNUSED(hdptr);
-#endif
-	endhostent();
-	HOST_R_END_RESULT(HOST_R_OK);
-}
-
-/* Private */
-
-#ifndef HOSTENT_DATA
-static HOST_R_RETURN
-copy_hostent(struct hostent *he, struct hostent *hptr, HOST_R_COPY_ARGS) {
-	char *cp;
-	char **ptr;
-	int i, n;
-	int nptr, len;
-
-	/* Find out the amount of space required to store the answer. */
-	nptr = 2; /*%< NULL ptrs */
-	len = (char *)ALIGN(buf) - buf;
-	for (i = 0; he->h_addr_list[i]; i++, nptr++) {
-		len += he->h_length;
-	}
-	for (i = 0; he->h_aliases[i]; i++, nptr++) {
-		len += strlen(he->h_aliases[i]) + 1;
-	}
-	len += strlen(he->h_name) + 1;
-	len += nptr * sizeof(char*);
-	
-	if (len > buflen) {
-		errno = ERANGE;
-		return (HOST_R_BAD);
-	}
-
-	/* copy address size and type */
-	hptr->h_addrtype = he->h_addrtype;
-	n = hptr->h_length = he->h_length;
-
-	ptr = (char **)ALIGN(buf);
-	cp = (char *)ALIGN(buf) + nptr * sizeof(char *);
-
-	/* copy address list */
-	hptr->h_addr_list = ptr;
-	for (i = 0; he->h_addr_list[i]; i++ , ptr++) {
-		memcpy(cp, he->h_addr_list[i], n);
-		hptr->h_addr_list[i] = cp;
-		cp += n;
-	}
-	hptr->h_addr_list[i] = NULL;
-	ptr++;
-
-	/* copy official name */
-	n = strlen(he->h_name) + 1;
-	strcpy(cp, he->h_name);
-	hptr->h_name = cp;
-	cp += n;
-
-	/* copy aliases */
-	hptr->h_aliases = ptr;
-	for (i = 0 ; he->h_aliases[i]; i++) {
-		n = strlen(he->h_aliases[i]) + 1;
-		strcpy(cp, he->h_aliases[i]);
-		hptr->h_aliases[i] = cp;
-		cp += n;
-	}
-	hptr->h_aliases[i] = NULL;
-
-	return (HOST_R_OK);
-}
-#else /* !HOSTENT_DATA */
-static int
-copy_hostent(struct hostent *he, struct hostent *hptr, HOST_R_COPY_ARGS) {
-	char *cp, *eob;
-	int i, n;
-
-	/* copy address size and type */
-	hptr->h_addrtype = he->h_addrtype;
-	n = hptr->h_length = he->h_length;
-
-	/* copy up to first 35 addresses */
-	i = 0;
-	cp = hdptr->hostbuf;
-	eob = hdptr->hostbuf + sizeof(hdptr->hostbuf);
-	hptr->h_addr_list = hdptr->h_addr_ptrs;
-	while (he->h_addr_list[i] && i < (_MAXADDRS)) {
-		if (n < (eob - cp)) {
-			memcpy(cp, he->h_addr_list[i], n);
-			hptr->h_addr_list[i] = cp;
-			cp += n;
-		} else {
-			break;
-		}
-		i++;
-	}
-	hptr->h_addr_list[i] = NULL;
-
-	/* copy official name */
-	if ((n = strlen(he->h_name) + 1) < (eob - cp)) {
-		strcpy(cp, he->h_name);
-		hptr->h_name = cp;
-		cp += n;
-	} else {
-		return (-1);
-	}
-
-	/* copy aliases */
-	i = 0;
-	hptr->h_aliases = hdptr->host_aliases;
-	while (he->h_aliases[i] && i < (_MAXALIASES-1)) {
-		if ((n = strlen(he->h_aliases[i]) + 1) < (eob - cp)) {
-			strcpy(cp, he->h_aliases[i]);
-			hptr->h_aliases[i] = cp;
-			cp += n;
-		} else {
-			break;
-		}
-		i++;
-	}
-	hptr->h_aliases[i] = NULL;
-
-	return (HOST_R_OK);
-}
-#endif /* !HOSTENT_DATA */
-#else /* HOST_R_RETURN */
-	static int gethostent_r_unknown_system = 0;
-#endif /* HOST_R_RETURN */
-#endif /* !defined(_REENTRANT) || !defined(DO_PTHREADS) */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/getnameinfo.c b/contrib/bind9/lib/bind/irs/getnameinfo.c
deleted file mode 100644
index 89c8230..0000000
--- a/contrib/bind9/lib/bind/irs/getnameinfo.c
+++ /dev/null
@@ -1,334 +0,0 @@
-/*
- * Issues to be discussed:
- * - Thread safe-ness must be checked
- */
-
-#if ( defined(__linux__) || defined(__linux) || defined(LINUX) )
-#ifndef IF_NAMESIZE
-# ifdef IFNAMSIZ
-#  define IF_NAMESIZE  IFNAMSIZ
-# else
-#  define IF_NAMESIZE 16
-# endif
-#endif
-#endif
-
-/*
- * Copyright (C) 1995, 1996, 1997, and 1998 WIDE Project.
- * All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- *    This product includes software developed by WIDE Project and
- *    its contributors.
- * 4. Neither the name of the project nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-#include <port_before.h>
-
-#include <sys/types.h>
-#include <sys/socket.h>
-
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <arpa/inet.h>
-#include <net/if.h>
-
-#include <netdb.h>
-#include <resolv.h>
-#include <string.h>
-#include <stddef.h>
-
-#include <port_after.h>
-
-/*%
- * Note that a_off will be dynamically adjusted so that to be consistent
- * with the definition of sockaddr_in{,6}.
- * The value presented below is just a guess.
- */
-static struct afd {
-	int a_af;
-	int a_addrlen;
-	size_t a_socklen;
-	int a_off;
-} afdl [] = {
-	/* first entry is linked last... */
-	{PF_INET, sizeof(struct in_addr), sizeof(struct sockaddr_in),
-	 offsetof(struct sockaddr_in, sin_addr)},
-	{PF_INET6, sizeof(struct in6_addr), sizeof(struct sockaddr_in6),
-	 offsetof(struct sockaddr_in6, sin6_addr)},
-	{0, 0, 0, 0},
-};
-
-struct sockinet {
-#ifdef HAVE_SA_LEN
-	u_char	si_len;
-#endif
-	u_char	si_family;
-	u_short	si_port;
-};
-
-static int ip6_parsenumeric __P((const struct sockaddr *, const char *, char *,
-				 size_t, int));
-#ifdef HAVE_SIN6_SCOPE_ID
-static int ip6_sa2str __P((const struct sockaddr_in6 *, char *, size_t, int));
-#endif
-
-int
-getnameinfo(sa, salen, host, hostlen, serv, servlen, flags)
-	const struct sockaddr *sa;
-	size_t salen;
-	char *host;
-	size_t hostlen;
-	char *serv;
-	size_t servlen;
-	int flags;
-{
-	struct afd *afd;
-	struct servent *sp;
-	struct hostent *hp;
-	u_short port;
-#ifdef HAVE_SA_LEN
-	size_t len;
-#endif
-	int family, i;
-	const char *addr;
-	char *p;
-	char numserv[512];
-	char numaddr[512];
-	const struct sockaddr_in6 *sin6;
-
-	if (sa == NULL)
-		return EAI_FAIL;
-
-#ifdef HAVE_SA_LEN
-	len = sa->sa_len;
-	if (len != salen) return EAI_FAIL;
-#endif
-
-	family = sa->sa_family;
-	for (i = 0; afdl[i].a_af; i++)
-		if (afdl[i].a_af == family) {
-			afd = &afdl[i];
-			goto found;
-		}
-	return EAI_FAMILY;
-
- found:
-	if (salen != afd->a_socklen) return EAI_FAIL;
-
-	port = ((const struct sockinet *)sa)->si_port; /*%< network byte order */
-	addr = (const char *)sa + afd->a_off;
-
-	if (serv == NULL || servlen == 0U) {
-		/*
-		 * rfc2553bis says that serv == NULL or servlen == 0 means that
-		 * the caller does not want the result.
-		 */
-	} else if (flags & NI_NUMERICSERV) {
-		sprintf(numserv, "%d", ntohs(port));
-		if (strlen(numserv) > servlen)
-			return EAI_MEMORY;
-		strcpy(serv, numserv);
-	} else {
-		sp = getservbyport(port, (flags & NI_DGRAM) ? "udp" : "tcp");
-		if (sp) {
-			if (strlen(sp->s_name) + 1 > servlen)
-				return EAI_MEMORY;
-			strcpy(serv, sp->s_name);
-		} else
-			return EAI_NONAME;
-	}
-
-	switch (sa->sa_family) {
-	case AF_INET:
-		if (ntohl(*(const u_int32_t *)addr) >> IN_CLASSA_NSHIFT == 0)
-			flags |= NI_NUMERICHOST;			
-		break;
-	case AF_INET6:
-		sin6 = (const struct sockaddr_in6 *)sa;
-		switch (sin6->sin6_addr.s6_addr[0]) {
-		case 0x00:
-			if (IN6_IS_ADDR_V4MAPPED(&sin6->sin6_addr))
-				;
-			else if (IN6_IS_ADDR_LOOPBACK(&sin6->sin6_addr))
-				;
-			else
-				flags |= NI_NUMERICHOST;
-			break;
-		default:
-			if (IN6_IS_ADDR_LINKLOCAL(&sin6->sin6_addr))
-				flags |= NI_NUMERICHOST;
-			else if (IN6_IS_ADDR_MULTICAST(&sin6->sin6_addr))
-				flags |= NI_NUMERICHOST;
-			break;
-		}
-		break;
-	}
-	if (host == NULL || hostlen == 0U) {
-		/*
-		 * rfc2553bis says that host == NULL or hostlen == 0 means that
-		 * the caller does not want the result.
-		 */
-	} else if (flags & NI_NUMERICHOST) {
-		goto numeric;
-	} else {
-		hp = gethostbyaddr(addr, afd->a_addrlen, afd->a_af);
-
-		if (hp) {
-			if (flags & NI_NOFQDN) {
-				p = strchr(hp->h_name, '.');
-				if (p) *p = '\0';
-			}
-			if (strlen(hp->h_name) + 1 > hostlen)
-				return EAI_MEMORY;
-			strcpy(host, hp->h_name);
-		} else {
-			if (flags & NI_NAMEREQD)
-				return EAI_NONAME;
-		  numeric:
-			switch(afd->a_af) {
-			case AF_INET6:
-			{
-				int error;
-
-				if ((error = ip6_parsenumeric(sa, addr, host,
-							      hostlen,
-							      flags)) != 0)
-					return(error);
-				break;
-			}
-
-			default:
-				if (inet_ntop(afd->a_af, addr, numaddr,
-					      sizeof(numaddr)) == NULL)
-					return EAI_NONAME;
-				if (strlen(numaddr) + 1 > hostlen)
-					return EAI_MEMORY;
-				strcpy(host, numaddr);
-			}
-		}
-	}
-	return(0);
-}
-
-static int
-ip6_parsenumeric(const struct sockaddr *sa, const char *addr, char *host,
-		 size_t hostlen, int flags)
-{
-	size_t numaddrlen;
-	char numaddr[512];
-
-#ifndef HAVE_SIN6_SCOPE_ID
-	UNUSED(sa);
-	UNUSED(flags);
-#endif
-
-	if (inet_ntop(AF_INET6, addr, numaddr, sizeof(numaddr))
-	    == NULL)
-		return EAI_SYSTEM;
-
-	numaddrlen = strlen(numaddr);
-	if (numaddrlen + 1 > hostlen) /*%< don't forget terminator */
-		return EAI_MEMORY;
-	strcpy(host, numaddr);
-
-#ifdef HAVE_SIN6_SCOPE_ID
-	if (((const struct sockaddr_in6 *)sa)->sin6_scope_id) {
-		char scopebuf[MAXHOSTNAMELEN]; /*%< XXX */
-		int scopelen;
-
-		/* ip6_sa2str never fails */
-		scopelen = ip6_sa2str((const struct sockaddr_in6 *)sa,
-				      scopebuf, sizeof(scopebuf), flags);
-
-		if (scopelen + 1 + numaddrlen + 1 > hostlen)
-			return EAI_MEMORY;
-
-		/* construct <numeric-addr><delim><scopeid> */
-		memcpy(host + numaddrlen + 1, scopebuf,
-		       scopelen);
-		host[numaddrlen] = SCOPE_DELIMITER;
-		host[numaddrlen + 1 + scopelen] = '\0';
-	}
-#endif
-
-	return 0;
-}
-
-#ifdef HAVE_SIN6_SCOPE_ID
-/* ARGSUSED */
-static int
-ip6_sa2str(const struct sockaddr_in6 *sa6, char *buf,
-	   size_t bufsiz, int flags)
-{
-#ifdef USE_IFNAMELINKID
-	unsigned int ifindex = (unsigned int)sa6->sin6_scope_id;
-	const struct in6_addr *a6 = &sa6->sin6_addr;
-#endif
-	char tmp[64];
-
-#ifdef NI_NUMERICSCOPE
-	if (flags & NI_NUMERICSCOPE) {
-		sprintf(tmp, "%u", sa6->sin6_scope_id);
-		if (bufsiz != 0U) {
-			strncpy(buf, tmp, bufsiz - 1);
-			buf[bufsiz - 1] = '\0';
-		}
-		return(strlen(tmp));
-	}
-#endif
-
-#ifdef USE_IFNAMELINKID
-	/*
-	 * For a link-local address, convert the index to an interface
-	 * name, assuming a one-to-one mapping between links and interfaces.
-	 * Note, however, that this assumption is stronger than the
-	 * specification of the scoped address architecture;  the
-	 * specficication says that more than one interfaces can belong to
-	 * a single link.
-	 */
-
-	/* if_indextoname() does not take buffer size.  not a good api... */
-	if ((IN6_IS_ADDR_LINKLOCAL(a6) || IN6_IS_ADDR_MC_LINKLOCAL(a6)) &&
-	    bufsiz >= IF_NAMESIZE) {
-		char *p = if_indextoname(ifindex, buf);
-		if (p) {
-			return(strlen(p));
-		}
-	}
-#endif
-
-	/* last resort */
-	sprintf(tmp, "%u", sa6->sin6_scope_id);
-	if (bufsiz != 0U) {
-		strncpy(buf, tmp, bufsiz - 1);
-		buf[bufsiz - 1] = '\0';
-	}
-	return(strlen(tmp));
-}
-#endif
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/getnetent.c b/contrib/bind9/lib/bind/irs/getnetent.c
deleted file mode 100644
index 5f7d233..0000000
--- a/contrib/bind9/lib/bind/irs/getnetent.c
+++ /dev/null
@@ -1,345 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: getnetent.c,v 1.6.18.1 2005/04/27 05:00:58 sra Exp $";
-#endif
-
-/* Imports */
-
-#include "port_before.h"
-
-#if !defined(__BIND_NOSTATIC)
-
-#include <sys/types.h>
-#include <sys/socket.h>
-
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <arpa/inet.h>
-
-#include <ctype.h>
-#include <errno.h>
-#include <netdb.h>
-#include <resolv.h>
-#include <stdlib.h>
-#include <string.h>
-
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "irs_data.h"
-
-/* Definitions */
-
-struct pvt {
-	struct netent	netent;
-	char *		aliases[1];
-	char		name[MAXDNAME + 1];
-};
-
-/* Forward */
-
-static struct net_data *init(void);
-static struct netent   *nw_to_net(struct nwent *, struct net_data *);
-static void		freepvt(struct net_data *);
-static struct netent   *fakeaddr(const char *, int af, struct net_data *);
-
-/* Portability */
-
-#ifndef INADDR_NONE
-# define INADDR_NONE 0xffffffff
-#endif
-
-/* Public */
-
-struct netent *
-getnetent() {
-	struct net_data *net_data = init();
-
-	return (getnetent_p(net_data));
-}
-
-struct netent *
-getnetbyname(const char *name) {
-	struct net_data *net_data = init();
-
-	return (getnetbyname_p(name, net_data));
-}
-
-struct netent *
-getnetbyaddr(unsigned long net, int type) {
-	struct net_data *net_data = init();
-
-	return (getnetbyaddr_p(net, type, net_data));
-}
-
-void
-setnetent(int stayopen) {
-	struct net_data *net_data = init();
-
-	setnetent_p(stayopen, net_data);
-}
-
-
-void
-endnetent() {
-	struct net_data *net_data = init();
-
-	endnetent_p(net_data);
-}
-
-/* Shared private. */
-
-struct netent *
-getnetent_p(struct net_data *net_data) {
-	struct irs_nw *nw;
-
-	if (!net_data || !(nw = net_data->nw))
-		return (NULL);
-	net_data->nww_last = (*nw->next)(nw);
-	net_data->nw_last = nw_to_net(net_data->nww_last, net_data);
-	return (net_data->nw_last);
-}
-
-struct netent *
-getnetbyname_p(const char *name, struct net_data *net_data) {
-	struct irs_nw *nw;
-	struct netent *np;
-	char **nap;
-
-	if (!net_data || !(nw = net_data->nw))
-		return (NULL);
-	if (net_data->nw_stayopen && net_data->nw_last) {
-		if (!strcmp(net_data->nw_last->n_name, name))
-			return (net_data->nw_last);
-		for (nap = net_data->nw_last->n_aliases; nap && *nap; nap++)
-			if (!strcmp(name, *nap))
-				return (net_data->nw_last);
-	}
-	if ((np = fakeaddr(name, AF_INET, net_data)) != NULL)
-		return (np);
-	net_data->nww_last = (*nw->byname)(nw, name, AF_INET);
-	net_data->nw_last = nw_to_net(net_data->nww_last, net_data);
-	if (!net_data->nw_stayopen)
-		endnetent();
-	return (net_data->nw_last);
-}
-
-struct netent *
-getnetbyaddr_p(unsigned long net, int type, struct net_data *net_data) {
-	struct irs_nw *nw;
-	u_char addr[4];
-	int bits;
-
-	if (!net_data || !(nw = net_data->nw))
-		return (NULL);
-	if (net_data->nw_stayopen && net_data->nw_last)
-		if (type == net_data->nw_last->n_addrtype &&
-		    net == net_data->nw_last->n_net)
-			return (net_data->nw_last);
-
-	/* cannonize net(host order) */
-	if (net < 256UL) {
-		net <<= 24;
-		bits = 8;
-	} else if (net < 65536UL) {
-		net <<= 16;
-		bits = 16;
-	} else if (net < 16777216UL) {
-		net <<= 8;
-		bits = 24;
-	} else
-		bits = 32;
-
-	/* convert to net order */
-	addr[0] = (0xFF000000 & net) >> 24;
-	addr[1] = (0x00FF0000 & net) >> 16;
-	addr[2] = (0x0000FF00 & net) >> 8;
-	addr[3] = (0x000000FF & net);
-
-	/* reduce bits to as close to natural number as possible */
-	if ((bits == 32) && (addr[0] < 224) && (addr[3] == 0)) {
-		if ((addr[0] < 192) && (addr[2] == 0)) {
-			if ((addr[0] < 128) && (addr[1] == 0))
-				bits = 8;
-			else
-				bits = 16;
-		} else {
-			bits = 24;
-		}
-	}
-
-	net_data->nww_last = (*nw->byaddr)(nw, addr, bits, AF_INET);
-	net_data->nw_last = nw_to_net(net_data->nww_last, net_data);
-	if (!net_data->nw_stayopen)
-		endnetent();
-	return (net_data->nw_last);
-}
-
-
-
-
-void
-setnetent_p(int stayopen, struct net_data *net_data) {
-	struct irs_nw *nw;
-
-	if (!net_data || !(nw = net_data->nw))
-		return;
-	freepvt(net_data);
-	(*nw->rewind)(nw);
-	net_data->nw_stayopen = (stayopen != 0);
-	if (stayopen == 0)
-		net_data_minimize(net_data);
-}
-
-void
-endnetent_p(struct net_data *net_data) {
-	struct irs_nw *nw;
-
-	if ((net_data != NULL) && ((nw	= net_data->nw) != NULL))
-		(*nw->minimize)(nw);
-}
-
-/* Private */
-
-static struct net_data *
-init() {
-	struct net_data *net_data;
-
-	if (!(net_data = net_data_init(NULL)))
-		goto error;
-	if (!net_data->nw) {
-		net_data->nw = (*net_data->irs->nw_map)(net_data->irs);
-
-		if (!net_data->nw || !net_data->res) {
- error:		
-			errno = EIO;
-			return (NULL);
-		}
-		(*net_data->nw->res_set)(net_data->nw, net_data->res, NULL);
-	}
-	
-	return (net_data);
-}
-
-static void
-freepvt(struct net_data *net_data) {
-	if (net_data->nw_data) {
-		free(net_data->nw_data);
-		net_data->nw_data = NULL;
-	}
-}
-
-static struct netent *
-fakeaddr(const char *name, int af, struct net_data *net_data) {
-	struct pvt *pvt;
-	const char *cp;
-	u_long tmp;
-
-	if (af != AF_INET) {
-		/* XXX should support IPv6 some day */
-		errno = EAFNOSUPPORT;
-		RES_SET_H_ERRNO(net_data->res, NETDB_INTERNAL);
-		return (NULL);
-	}
-	if (!isascii((unsigned char)(name[0])) ||
-	    !isdigit((unsigned char)(name[0])))
-		return (NULL);
-	for (cp = name; *cp; ++cp)
-		if (!isascii(*cp) || (!isdigit((unsigned char)*cp) && *cp != '.'))
-			return (NULL);
-	if (*--cp == '.')
-		return (NULL);
-
-	/* All-numeric, no dot at the end. */
-
-	tmp = inet_network(name);
-	if (tmp == INADDR_NONE) {
-		RES_SET_H_ERRNO(net_data->res, HOST_NOT_FOUND);
-		return (NULL);
-	}
-
-	/* Valid network number specified.
-	 * Fake up a netent as if we'd actually
-	 * done a lookup.
-	 */
-	freepvt(net_data);
-	net_data->nw_data = malloc(sizeof (struct pvt));
-	if (!net_data->nw_data) {
-		errno = ENOMEM;
-		RES_SET_H_ERRNO(net_data->res, NETDB_INTERNAL);
-		return (NULL);
-	}
-	pvt = net_data->nw_data;
-
-	strncpy(pvt->name, name, MAXDNAME);
-	pvt->name[MAXDNAME] = '\0';
-	pvt->netent.n_name = pvt->name;
-	pvt->netent.n_addrtype = AF_INET;
-	pvt->netent.n_aliases = pvt->aliases;
-	pvt->aliases[0] = NULL;
-	pvt->netent.n_net = tmp;
-
-	return (&pvt->netent);
-}
-
-static struct netent *
-nw_to_net(struct nwent *nwent, struct net_data *net_data) {
-	struct pvt *pvt;
-	u_long addr = 0;
-	int i;
-	int msbyte;
-
-	if (!nwent || nwent->n_addrtype != AF_INET)
-		return (NULL);
-	freepvt(net_data);
-	net_data->nw_data = malloc(sizeof (struct pvt));
-	if (!net_data->nw_data) {
-		errno = ENOMEM;
-		RES_SET_H_ERRNO(net_data->res, NETDB_INTERNAL);
-		return (NULL);
-	}
-	pvt = net_data->nw_data;
-	pvt->netent.n_name = nwent->n_name;
-	pvt->netent.n_aliases = nwent->n_aliases;
-	pvt->netent.n_addrtype = nwent->n_addrtype;
-
-/*%
- * What this code does: Converts net addresses from network to host form.
- *
- * msbyte: the index of the most significant byte in the n_addr array.
- *
- * Shift bytes in significant order into addr. When all signicant
- * bytes are in, zero out bits in the LSB that are not part of the network.
- */
-	msbyte = nwent->n_length / 8 +
-		((nwent->n_length % 8) != 0 ? 1 : 0) - 1;
-	for (i = 0; i <= msbyte; i++)
-		addr = (addr << 8) | ((unsigned char *)nwent->n_addr)[i];
-	i = (32 - nwent->n_length) % 8;
-	if (i != 0)
-		addr &= ~((1 << (i + 1)) - 1);
-	pvt->netent.n_net = addr;
-	return (&pvt->netent);
-}
-
-#endif /*__BIND_NOSTATIC*/
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/getnetent_r.c b/contrib/bind9/lib/bind/irs/getnetent_r.c
deleted file mode 100644
index 7e56ddc..0000000
--- a/contrib/bind9/lib/bind/irs/getnetent_r.c
+++ /dev/null
@@ -1,234 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1998-1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: getnetent_r.c,v 1.4.18.2 2005/09/03 12:45:14 marka Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-#include <port_before.h>
-#if !defined(_REENTRANT) || !defined(DO_PTHREADS)
-	static int getnetent_r_not_required = 0;
-#else
-#include <errno.h>
-#include <string.h>
-#include <stdio.h>
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <netdb.h>
-#include <sys/param.h>
-#include <port_after.h>
-
-#ifdef NET_R_RETURN
-
-static NET_R_RETURN 
-copy_netent(struct netent *, struct netent *, NET_R_COPY_ARGS);
-
-NET_R_RETURN
-getnetbyname_r(const char *name,  struct netent *nptr, NET_R_ARGS) {
-	struct netent *ne = getnetbyname(name);
-#ifdef NET_R_SETANSWER
-	int n = 0;
-
-	if (ne == NULL || (n = copy_netent(ne, nptr, NET_R_COPY)) != 0)
-		*answerp = NULL;
-	else
-		*answerp = ne;
-	if (ne == NULL)
-		*h_errnop = h_errno;
-	return (n);
-#else
-	if (ne == NULL)
-		return (NET_R_BAD);
-
-	return (copy_netent(ne, nptr, NET_R_COPY));
-#endif
-}
-
-#ifndef GETNETBYADDR_ADDR_T
-#define GETNETBYADDR_ADDR_T long
-#endif
-NET_R_RETURN
-getnetbyaddr_r(GETNETBYADDR_ADDR_T addr, int type, struct netent *nptr, NET_R_ARGS) {
-	struct netent *ne = getnetbyaddr(addr, type);
-#ifdef NET_R_SETANSWER
-	int n = 0;
-
-	if (ne == NULL || (n = copy_netent(ne, nptr, NET_R_COPY)) != 0)
-		*answerp = NULL;
-	else
-		*answerp = ne;
-	if (ne == NULL)
-		*h_errnop = h_errno;
-	return (n);
-#else
-
-	if (ne == NULL)
-		return (NET_R_BAD);
-
-	return (copy_netent(ne, nptr, NET_R_COPY));
-#endif
-}
-
-/*%
- *	These assume a single context is in operation per thread.
- *	If this is not the case we will need to call irs directly
- *	rather than through the base functions.
- */
-
-NET_R_RETURN
-getnetent_r(struct netent *nptr, NET_R_ARGS) {
-	struct netent *ne = getnetent();
-#ifdef NET_R_SETANSWER
-	int n = 0;
-
-	if (ne == NULL || (n = copy_netent(ne, nptr, NET_R_COPY)) != 0)
-		*answerp = NULL;
-	else
-		*answerp = ne;
-	if (ne == NULL)
-		*h_errnop = h_errno;
-	return (n);
-#else
-
-	if (ne == NULL)
-		return (NET_R_BAD);
-
-	return (copy_netent(ne, nptr, NET_R_COPY));
-#endif
-}
-
-NET_R_SET_RETURN
-#ifdef NET_R_ENT_ARGS
-setnetent_r(int stay_open, NET_R_ENT_ARGS)
-#else
-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);
-#endif
-}
-
-NET_R_END_RETURN
-#ifdef NET_R_ENT_ARGS
-endnetent_r(NET_R_ENT_ARGS)
-#else
-endnetent_r()
-#endif
-{
-#ifdef NET_R_ENT_ARGS
-	UNUSED(ndptr);
-#endif
-	endnetent();
-	NET_R_END_RESULT(NET_R_OK);
-}
-
-/* Private */
-
-#ifndef NETENT_DATA
-static NET_R_RETURN
-copy_netent(struct netent *ne, struct netent *nptr, NET_R_COPY_ARGS) {
-	char *cp;
-	int i, n;
-	int numptr, len;
-
-	/* Find out the amount of space required to store the answer. */
-	numptr = 1; /*%< NULL ptr */
-	len = (char *)ALIGN(buf) - buf;
-	for (i = 0; ne->n_aliases[i]; i++, numptr++) {
-		len += strlen(ne->n_aliases[i]) + 1;
-	}
-	len += strlen(ne->n_name) + 1;
-	len += numptr * sizeof(char*);
-	
-	if (len > (int)buflen) {
-		errno = ERANGE;
-		return (NET_R_BAD);
-	}
-
-	/* copy net value and type */
-	nptr->n_addrtype = ne->n_addrtype;
-	nptr->n_net = ne->n_net;
-
-	cp = (char *)ALIGN(buf) + numptr * sizeof(char *);
-
-	/* copy official name */
-	n = strlen(ne->n_name) + 1;
-	strcpy(cp, ne->n_name);
-	nptr->n_name = cp;
-	cp += n;
-
-	/* copy aliases */
-	nptr->n_aliases = (char **)ALIGN(buf);
-	for (i = 0 ; ne->n_aliases[i]; i++) {
-		n = strlen(ne->n_aliases[i]) + 1;
-		strcpy(cp, ne->n_aliases[i]);
-		nptr->n_aliases[i] = cp;
-		cp += n;
-	}
-	nptr->n_aliases[i] = NULL;
-
-	return (NET_R_OK);
-}
-#else /* !NETENT_DATA */
-static int
-copy_netent(struct netent *ne, struct netent *nptr, NET_R_COPY_ARGS) {
-	char *cp, *eob;
-	int i, n;
-
-	/* copy net value and type */
-	nptr->n_addrtype = ne->n_addrtype;
-	nptr->n_net = ne->n_net;
-
-	/* copy official name */
-	cp = ndptr->line;
-	eob = ndptr->line + sizeof(ndptr->line);
-	if ((n = strlen(ne->n_name) + 1) < (eob - cp)) {
-		strcpy(cp, ne->n_name);
-		nptr->n_name = cp;
-		cp += n;
-	} else {
-		return (-1);
-	}
-
-	/* copy aliases */
-	i = 0;
-	nptr->n_aliases = ndptr->net_aliases;
-	while (ne->n_aliases[i] && i < (_MAXALIASES-1)) {
-		if ((n = strlen(ne->n_aliases[i]) + 1) < (eob - cp)) {
-			strcpy(cp, ne->n_aliases[i]);
-			nptr->n_aliases[i] = cp;
-			cp += n;
-		} else {
-			break;
-		}
-		i++;
-	}
-	nptr->n_aliases[i] = NULL;
-
-	return (NET_R_OK);
-}
-#endif /* !NETENT_DATA */
-#else /* NET_R_RETURN */
-	static int getnetent_r_unknown_system = 0;
-#endif /* NET_R_RETURN */
-#endif /* !defined(_REENTRANT) || !defined(DO_PTHREADS) */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/getnetgrent.c b/contrib/bind9/lib/bind/irs/getnetgrent.c
deleted file mode 100644
index 1e6ff9b..0000000
--- a/contrib/bind9/lib/bind/irs/getnetgrent.c
+++ /dev/null
@@ -1,160 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: getnetgrent.c,v 1.3.18.2 2008/02/27 00:08:30 marka Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-/* Imports */
-
-#include "port_before.h"
-
-#if !defined(__BIND_NOSTATIC)
-
-#include <sys/types.h>
-
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-
-#include <errno.h>
-#include <resolv.h>
-#include <stdio.h>
-
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_data.h"
-
-/* Forward */
-
-static struct net_data *init(void);
-
-
-/* Public */
-
-#ifndef SETNETGRENT_ARGS
-#define SETNETGRENT_ARGS const char *netgroup
-#endif
-void
-setnetgrent(SETNETGRENT_ARGS) {
-	struct net_data *net_data = init();
-
-	setnetgrent_p(netgroup, net_data);
-}
-
-void
-endnetgrent(void) {
-	struct net_data *net_data = init();
-
-	endnetgrent_p(net_data);
-}
-
-#ifndef INNETGR_ARGS
-#define INNETGR_ARGS const char *netgroup, const char *host, \
-		     const char *user, const char *domain
-#endif
-int
-innetgr(INNETGR_ARGS) {
-	struct net_data *net_data = init();
-
-	return (innetgr_p(netgroup, host, user, domain, net_data));
-}
-
-int
-getnetgrent(NGR_R_CONST char **host, NGR_R_CONST char **user,
-	    NGR_R_CONST char **domain)
-{
-	struct net_data *net_data = init();
-	const char *ch, *cu, *cd;
-	int ret;
-
-	ret = getnetgrent_p(&ch, &cu, &cd, net_data);
-	if (ret != 1)
-		return (ret);
-
-	DE_CONST(ch, *host);
-	DE_CONST(cu, *user);
-	DE_CONST(cd, *domain);
-	return (ret);
-}
-
-/* Shared private. */
-
-void
-setnetgrent_p(const char *netgroup, struct net_data *net_data) {
-	struct irs_ng *ng;
-
-	if ((net_data != NULL) && ((ng = net_data->ng) != NULL))
-		(*ng->rewind)(ng, netgroup);
-}
-
-void
-endnetgrent_p(struct net_data *net_data) {
-	struct irs_ng *ng;
-
-	if (!net_data)
-		return;
-	if ((ng = net_data->ng) != NULL)
-		(*ng->close)(ng);
-	net_data->ng = NULL;
-}
-
-int
-innetgr_p(const char *netgroup, const char *host,
-	  const char *user, const char *domain,
-	  struct net_data *net_data) {
-	struct irs_ng *ng;
-
-	if (!net_data || !(ng = net_data->ng))
-		return (0);
-	return ((*ng->test)(ng, netgroup, host, user, domain));
-}
-
-int
-getnetgrent_p(const char **host, const char **user, const char **domain,
-	      struct net_data *net_data ) {
-	struct irs_ng *ng;
-
-	if (!net_data || !(ng = net_data->ng))
-		return (0);
-	return ((*ng->next)(ng, host, user, domain));
-}
-
-/* Private */
-
-static struct net_data *
-init(void) {
-	struct net_data *net_data;
-
-	if (!(net_data = net_data_init(NULL)))
-		goto error;
-	if (!net_data->ng) {
-		net_data->ng = (*net_data->irs->ng_map)(net_data->irs);
-		if (!net_data->ng) {
-  error:
-			errno = EIO;
-			return (NULL);
-		}
-	}
-	
-	return (net_data);
-}
-
-#endif /*__BIND_NOSTATIC*/
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/getnetgrent_r.c b/contrib/bind9/lib/bind/irs/getnetgrent_r.c
deleted file mode 100644
index 3ff5542..0000000
--- a/contrib/bind9/lib/bind/irs/getnetgrent_r.c
+++ /dev/null
@@ -1,219 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1998-1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: getnetgrent_r.c,v 1.7.18.6 2008/02/28 05:49:37 marka Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-#include <port_before.h>
-#if !defined(_REENTRANT) || !defined(DO_PTHREADS)
-	static int getnetgrent_r_not_required = 0;
-#else
-#include <errno.h>
-#include <string.h>
-#include <stdio.h>
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <netdb.h>
-#include <stdlib.h>
-#include <port_after.h>
-
-#ifdef NGR_R_RETURN
-#ifndef NGR_R_PRIVATE
-#define NGR_R_PRIVATE 0
-#endif
-
-static NGR_R_RETURN 
-copy_protoent(NGR_R_CONST char **, NGR_R_CONST char **, NGR_R_CONST char **,
-	      const char *, const char *, const char *, NGR_R_COPY_ARGS);
-
-NGR_R_RETURN
-innetgr_r(const char *netgroup, const char *host, const char *user,
-	  const char *domain) {
-	char *ng, *ho, *us, *dom;
-
-	DE_CONST(netgroup, ng);
-	DE_CONST(host, ho);
-	DE_CONST(user, us);
-	DE_CONST(domain, dom);
-
-	return (innetgr(ng, ho, us, dom));
-}
-
-/*%
- *	These assume a single context is in operation per thread.
- *	If this is not the case we will need to call irs directly
- *	rather than through the base functions.
- */
-
-NGR_R_RETURN
-getnetgrent_r(NGR_R_CONST char **machinep, NGR_R_CONST char **userp,
-	      NGR_R_CONST char **domainp, NGR_R_ARGS)
-{
-	NGR_R_CONST char *mp, *up, *dp;
-	int res = getnetgrent(&mp, &up, &dp);
-
-	if (res != 1) 
-		return (res);
-
-	return (copy_protoent(machinep, userp, domainp,
-				mp, up, dp, NGR_R_COPY));
-}
-
-#if NGR_R_PRIVATE == 2
-struct private {
-	char *buf;
-};
-
-#endif
-NGR_R_SET_RETURN
-#ifdef NGR_R_SET_ARGS
-setnetgrent_r(NGR_R_SET_CONST char *netgroup, NGR_R_SET_ARGS)
-#else
-setnetgrent_r(NGR_R_SET_CONST char *netgroup)
-#endif
-{
-#if NGR_R_PRIVATE == 2
-	struct private *p;
-#endif
-	char *tmp;
-#if defined(NGR_R_SET_ARGS) && NGR_R_PRIVATE == 0
-	UNUSED(buf);
-	UNUSED(buflen);
-#endif
-
-	DE_CONST(netgroup, tmp);
-	setnetgrent(tmp);
-
-#if NGR_R_PRIVATE == 1
-	*buf = NULL;
-#elif NGR_R_PRIVATE == 2
-	*buf = p = malloc(sizeof(struct private));
-	if (p == NULL)
-#ifdef NGR_R_SET_RESULT
-		return (NGR_R_BAD);
-#else
-		return;
-#endif
-	p->buf = NULL;
-#endif
-#ifdef NGR_R_SET_RESULT
-	return (NGR_R_SET_RESULT);
-#endif
-}
-
-NGR_R_END_RETURN
-#ifdef NGR_R_END_ARGS
-endnetgrent_r(NGR_R_END_ARGS)
-#else
-endnetgrent_r(void)
-#endif
-{
-#if NGR_R_PRIVATE == 2
-	struct private *p = buf;
-#endif
-#if defined(NGR_R_SET_ARGS) && NGR_R_PRIVATE == 0
-	UNUSED(buf);
-	UNUSED(buflen);
-#endif
-
-	endnetgrent();
-#if NGR_R_PRIVATE == 1
-	if (*buf != NULL)
-		free(*buf);
-	*buf = NULL;
-#elif NGR_R_PRIVATE == 2
-	if (p->buf != NULL)
-		free(p->buf);
-	free(p);
-#endif
-	NGR_R_END_RESULT(NGR_R_OK);
-}
-
-/* Private */
-
-static int
-copy_protoent(NGR_R_CONST char **machinep, NGR_R_CONST char **userp,
-	      NGR_R_CONST char **domainp, const char *mp, const char *up,
-	      const char *dp, NGR_R_COPY_ARGS)
-{
-#if NGR_R_PRIVATE == 2
-	struct private *p = buf;
-#endif
-	char *cp;
-	int n;
-	int len;
-
-	/* Find out the amount of space required to store the answer. */
-	len = 0;
-	if (mp != NULL) len += strlen(mp) + 1;
-	if (up != NULL) len += strlen(up) + 1;
-	if (dp != NULL) len += strlen(dp) + 1;
-	
-#if NGR_R_PRIVATE == 1
-	if (*buf != NULL)
-		free(*buf);
-	*buf = malloc(len);
-	if (*buf == NULL)
-		return(NGR_R_BAD);
-	cp = *buf;
-#elif NGR_R_PRIVATE == 2
-	if (p->buf)
-		free(p->buf);
-	p->buf = malloc(len);
-	if (p->buf == NULL)
-		return(NGR_R_BAD);
-	cp = p->buf;
-#else
-	if (len > (int)buflen) {
-		errno = ERANGE;
-		return (NGR_R_BAD);
-	}
-	cp = buf;
-#endif
-
-	if (mp != NULL) {
-		n = strlen(mp) + 1;
-		strcpy(cp, mp);
-		*machinep = cp;
-		cp += n;
-	} else
-		*machinep = NULL;
-
-	if (up != NULL) {
-		n = strlen(up) + 1;
-		strcpy(cp, up);
-		*userp = cp;
-		cp += n;
-	} else
-		*userp = NULL;
-
-	if (dp != NULL) {
-		n = strlen(dp) + 1;
-		strcpy(cp, dp);
-		*domainp = cp;
-		cp += n;
-	} else
-		*domainp = NULL;
-
-	return (NGR_R_OK);
-}
-#else /* NGR_R_RETURN */
-	static int getnetgrent_r_unknown_system = 0;
-#endif /* NGR_R_RETURN */
-#endif /* !defined(_REENTRANT) || !defined(DO_PTHREADS) */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/getprotoent.c b/contrib/bind9/lib/bind/irs/getprotoent.c
deleted file mode 100644
index 9e3d775..0000000
--- a/contrib/bind9/lib/bind/irs/getprotoent.c
+++ /dev/null
@@ -1,176 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: getprotoent.c,v 1.3.18.1 2005/04/27 05:00:58 sra Exp $";
-#endif
-
-/* Imports */
-
-#include "port_before.h"
-
-#if !defined(__BIND_NOSTATIC)
-
-#include <sys/types.h>
-
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-
-#include <errno.h>
-#include <resolv.h>
-#include <stdio.h>
-#include <string.h>
-
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_data.h"
-
-/* Forward */
-
-static struct net_data *init(void);
-
-/* Public */
-
-struct protoent *
-getprotoent() {
-	struct net_data *net_data = init();
-
-	return (getprotoent_p(net_data));
-}
-
-struct protoent *
-getprotobyname(const char *name) {
-	struct net_data *net_data = init();
-
-	return (getprotobyname_p(name, net_data));
-}
-
-struct protoent *
-getprotobynumber(int proto) {
-	struct net_data *net_data = init();
-
-	return (getprotobynumber_p(proto, net_data));
-}
-
-void
-setprotoent(int stayopen) {
-	struct net_data *net_data = init();
-
-	setprotoent_p(stayopen, net_data);
-}
-
-void
-endprotoent() {
-	struct net_data *net_data = init();
-
-	endprotoent_p(net_data);
-}
-
-/* Shared private. */
-
-struct protoent *
-getprotoent_p(struct net_data *net_data) {
-	struct irs_pr *pr;
-
-	if (!net_data || !(pr = net_data->pr))
-		return (NULL);
-	net_data->pr_last = (*pr->next)(pr);
-	return (net_data->pr_last);
-}
-
-struct protoent *
-getprotobyname_p(const char *name, struct net_data *net_data) {
-	struct irs_pr *pr;
-	char **pap;
-
-	if (!net_data || !(pr = net_data->pr))
-		return (NULL);
-	if (net_data->pr_stayopen && net_data->pr_last) {
-		if (!strcmp(net_data->pr_last->p_name, name))
-			return (net_data->pr_last);
-		for (pap = net_data->pr_last->p_aliases; pap && *pap; pap++)
-			if (!strcmp(name, *pap))
-				return (net_data->pr_last);
-	}
-	net_data->pr_last = (*pr->byname)(pr, name);
-	if (!net_data->pr_stayopen)
-		endprotoent();
-	return (net_data->pr_last);
-}
-
-struct protoent *
-getprotobynumber_p(int proto, struct net_data *net_data) {
-	struct irs_pr *pr;
-
-	if (!net_data || !(pr = net_data->pr))
-		return (NULL);
-	if (net_data->pr_stayopen && net_data->pr_last)
-		if (net_data->pr_last->p_proto == proto)
-			return (net_data->pr_last);
-	net_data->pr_last = (*pr->bynumber)(pr, proto);
-	if (!net_data->pr_stayopen)
-		endprotoent();
-	return (net_data->pr_last);
-}
-
-void
-setprotoent_p(int stayopen, struct net_data *net_data) {
-	struct irs_pr *pr;
-
-	if (!net_data || !(pr = net_data->pr))
-		return;
-	(*pr->rewind)(pr);
-	net_data->pr_stayopen = (stayopen != 0);
-	if (stayopen == 0)
-		net_data_minimize(net_data);
-}
-
-void
-endprotoent_p(struct net_data *net_data) {
-	struct irs_pr *pr;
-
-	if ((net_data != NULL) && ((pr = net_data->pr) != NULL))
-		(*pr->minimize)(pr);
-}
-
-/* Private */
-
-static struct net_data *
-init() {
-	struct net_data *net_data;
-
-	if (!(net_data = net_data_init(NULL)))
-		goto error;
-	if (!net_data->pr) {
-		net_data->pr = (*net_data->irs->pr_map)(net_data->irs);
-
-		if (!net_data->pr || !net_data->res) {
- error:		
-			errno = EIO;
-			return (NULL);
-		}
-		(*net_data->pr->res_set)(net_data->pr, net_data->res, NULL);
-	}
-	
-	return (net_data);
-}
-
-#endif /*__BIND_NOSTATIC*/
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/getprotoent_r.c b/contrib/bind9/lib/bind/irs/getprotoent_r.c
deleted file mode 100644
index 00b1572..0000000
--- a/contrib/bind9/lib/bind/irs/getprotoent_r.c
+++ /dev/null
@@ -1,223 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1998-1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: getprotoent_r.c,v 1.4.18.2 2006/08/01 01:19:12 marka Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-#include <port_before.h>
-#if !defined(_REENTRANT) || !defined(DO_PTHREADS)
-	static int getprotoent_r_not_required = 0;
-#else
-#include <errno.h>
-#include <string.h>
-#include <stdio.h>
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <netdb.h>
-#include <port_after.h>
-
-#ifdef PROTO_R_RETURN
-
-static PROTO_R_RETURN 
-copy_protoent(struct protoent *, struct protoent *, PROTO_R_COPY_ARGS);
-
-PROTO_R_RETURN
-getprotobyname_r(const char *name, struct protoent *pptr, PROTO_R_ARGS) {
-	struct protoent *pe = getprotobyname(name);
-#ifdef PROTO_R_SETANSWER
-	int n = 0;
-
-	if (pe == NULL || (n = copy_protoent(pe, pptr, PROTO_R_COPY)) != 0)
-		*answerp = NULL;
-	else
-		*answerp = pptr;
-	
-	return (n);
-#else
-	if (pe == NULL)
-		return (PROTO_R_BAD);
-
-	return (copy_protoent(pe, pptr, PROTO_R_COPY));
-#endif
-}
-
-PROTO_R_RETURN
-getprotobynumber_r(int proto, struct protoent *pptr, PROTO_R_ARGS) {
-	struct protoent *pe = getprotobynumber(proto);
-#ifdef PROTO_R_SETANSWER
-	int n = 0;
-
-	if (pe == NULL || (n = copy_protoent(pe, pptr, PROTO_R_COPY)) != 0)
-		*answerp = NULL;
-	else
-		*answerp = pptr;
-	
-	return (n);
-#else
-	if (pe == NULL)
-		return (PROTO_R_BAD);
-
-	return (copy_protoent(pe, pptr, PROTO_R_COPY));
-#endif
-}
-
-/*%
- *	These assume a single context is in operation per thread.
- *	If this is not the case we will need to call irs directly
- *	rather than through the base functions.
- */
-
-PROTO_R_RETURN
-getprotoent_r(struct protoent *pptr, PROTO_R_ARGS) {
-	struct protoent *pe = getprotoent();
-#ifdef PROTO_R_SETANSWER
-	int n = 0;
-
-	if (pe == NULL || (n = copy_protoent(pe, pptr, PROTO_R_COPY)) != 0)
-		*answerp = NULL;
-	else
-		*answerp = pptr;
-	
-	return (n);
-#else
-	if (pe == NULL)
-		return (PROTO_R_BAD);
-
-	return (copy_protoent(pe, pptr, PROTO_R_COPY));
-#endif
-}
-
-PROTO_R_SET_RETURN
-#ifdef PROTO_R_ENT_ARGS
-setprotoent_r(int stay_open, PROTO_R_ENT_ARGS)
-#else
-setprotoent_r(int stay_open)
-#endif
-{
-#ifdef PROTO_R_ENT_UNUSED
-        PROTO_R_ENT_UNUSED;
-#endif
-	setprotoent(stay_open);
-#ifdef PROTO_R_SET_RESULT
-	return (PROTO_R_SET_RESULT);
-#endif
-}
-
-PROTO_R_END_RETURN
-#ifdef PROTO_R_ENT_ARGS
-endprotoent_r(PROTO_R_ENT_ARGS)
-#else
-endprotoent_r()
-#endif
-{
-#ifdef PROTO_R_ENT_UNUSED
-        PROTO_R_ENT_UNUSED;
-#endif
-	endprotoent();
-	PROTO_R_END_RESULT(PROTO_R_OK);
-}
-
-/* Private */
-
-#ifndef PROTOENT_DATA
-static PROTO_R_RETURN
-copy_protoent(struct protoent *pe, struct protoent *pptr, PROTO_R_COPY_ARGS) {
-	char *cp;
-	int i, n;
-	int numptr, len;
-
-	/* Find out the amount of space required to store the answer. */
-	numptr = 1; /*%< NULL ptr */
-	len = (char *)ALIGN(buf) - buf;
-	for (i = 0; pe->p_aliases[i]; i++, numptr++) {
-		len += strlen(pe->p_aliases[i]) + 1;
-	}
-	len += strlen(pe->p_name) + 1;
-	len += numptr * sizeof(char*);
-	
-	if (len > (int)buflen) {
-		errno = ERANGE;
-		return (PROTO_R_BAD);
-	}
-
-	/* copy protocol value*/
-	pptr->p_proto = pe->p_proto;
-
-	cp = (char *)ALIGN(buf) + numptr * sizeof(char *);
-
-	/* copy official name */
-	n = strlen(pe->p_name) + 1;
-	strcpy(cp, pe->p_name);
-	pptr->p_name = cp;
-	cp += n;
-
-	/* copy aliases */
-	pptr->p_aliases = (char **)ALIGN(buf);
-	for (i = 0 ; pe->p_aliases[i]; i++) {
-		n = strlen(pe->p_aliases[i]) + 1;
-		strcpy(cp, pe->p_aliases[i]);
-		pptr->p_aliases[i] = cp;
-		cp += n;
-	}
-	pptr->p_aliases[i] = NULL;
-
-	return (PROTO_R_OK);
-}
-#else /* !PROTOENT_DATA */
-static int
-copy_protoent(struct protoent *pe, struct protoent *pptr, PROTO_R_COPY_ARGS) {
-	char *cp, *eob;
-	int i, n;
-
-	/* copy protocol value */
-	pptr->p_proto = pe->p_proto;
-
-	/* copy official name */
-	cp = pdptr->line;
-	eob = pdptr->line + sizeof(pdptr->line);
-	if ((n = strlen(pe->p_name) + 1) < (eob - cp)) {
-		strcpy(cp, pe->p_name);
-		pptr->p_name = cp;
-		cp += n;
-	} else {
-		return (-1);
-	}
-
-	/* copy aliases */
-	i = 0;
-	pptr->p_aliases = pdptr->proto_aliases;
-	while (pe->p_aliases[i] && i < (_MAXALIASES-1)) {
-		if ((n = strlen(pe->p_aliases[i]) + 1) < (eob - cp)) {
-			strcpy(cp, pe->p_aliases[i]);
-			pptr->p_aliases[i] = cp;
-			cp += n;
-		} else {
-			break;
-		}
-		i++;
-	}
-	pptr->p_aliases[i] = NULL;
-
-	return (PROTO_R_OK);
-}
-#endif /* PROTOENT_DATA */
-#else /* PROTO_R_RETURN */
-	static int getprotoent_r_unknown_system = 0;
-#endif /* PROTO_R_RETURN */
-#endif /* !defined(_REENTRANT) || !defined(DO_PTHREADS) */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/getpwent.c b/contrib/bind9/lib/bind/irs/getpwent.c
deleted file mode 100644
index 86f1d03..0000000
--- a/contrib/bind9/lib/bind/irs/getpwent.c
+++ /dev/null
@@ -1,201 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: getpwent.c,v 1.2.18.1 2005/04/27 05:00:59 sra Exp $";
-#endif
-
-/* Imports */
-
-#include "port_before.h"
-
-#if !defined(WANT_IRS_PW) || defined(__BIND_NOSTATIC)
-static int __bind_irs_pw_unneeded;
-#else
-
-#include <sys/types.h>
-
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-
-#include <errno.h>
-#include <pwd.h>
-#include <resolv.h>
-#include <stdio.h>
-#include <string.h>
-
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_data.h"
-
-/* Forward */
-
-static struct net_data * init(void);
-
-/* Public */
-
-struct passwd *
-getpwent(void) {
-	struct net_data *net_data = init();
-
-	return (getpwent_p(net_data));
-}
-
-struct passwd *
-getpwnam(const char *name) {
-	struct net_data *net_data = init();
-
-	return (getpwnam_p(name, net_data));
-}
-
-struct passwd *
-getpwuid(uid_t uid) {
-	struct net_data *net_data = init();
-
-	return (getpwuid_p(uid, net_data));
-}
-
-int
-setpassent(int stayopen) {
-	struct net_data *net_data = init();
-
-	return (setpassent_p(stayopen, net_data));
-}
-
-#ifdef SETPWENT_VOID
-void
-setpwent() {
-	struct net_data *net_data = init();
-
-	setpwent_p(net_data);
-}
-#else
-int
-setpwent() {
-	struct net_data *net_data = init();
-
-	return (setpwent_p(net_data));
-}
-#endif
-
-void
-endpwent() {
-	struct net_data *net_data = init();
-
-	endpwent_p(net_data);
-}
-
-/* Shared private. */
-
-struct passwd *
-getpwent_p(struct net_data *net_data) {
-	struct irs_pw *pw;
-
-	if (!net_data || !(pw = net_data->pw))
-		return (NULL);
-	net_data->pw_last = (*pw->next)(pw);
-	return (net_data->pw_last);
-}
-
-struct passwd *
-getpwnam_p(const char *name, struct net_data *net_data) {
-	struct irs_pw *pw;
-
-	if (!net_data || !(pw = net_data->pw))
-		return (NULL);
-	if (net_data->pw_stayopen && net_data->pw_last &&
-	    !strcmp(net_data->pw_last->pw_name, name))
-		return (net_data->pw_last);
-	net_data->pw_last = (*pw->byname)(pw, name);
-	if (!net_data->pw_stayopen)
-		endpwent();
-	return (net_data->pw_last);
-}
-
-struct passwd *
-getpwuid_p(uid_t uid, struct net_data *net_data) {
-	struct irs_pw *pw;
-
-	if (!net_data || !(pw = net_data->pw))
-		return (NULL);
-	if (net_data->pw_stayopen && net_data->pw_last &&
-	    net_data->pw_last->pw_uid == uid)
-		return (net_data->pw_last);
-	net_data->pw_last = (*pw->byuid)(pw, uid);
-	if (!net_data->pw_stayopen)
-		endpwent();
-	return (net_data->pw_last);
-}
-
-int
-setpassent_p(int stayopen, struct net_data *net_data) {
-	struct irs_pw *pw;
-
-	if (!net_data || !(pw = net_data->pw))
-		return (0);
-	(*pw->rewind)(pw);
-	net_data->pw_stayopen = (stayopen != 0);
-	if (stayopen == 0)
-		net_data_minimize(net_data);
-	return (1);
-}
-
-#ifdef SETPWENT_VOID
-void
-setpwent_p(struct net_data *net_data) {
-	(void) setpassent_p(0, net_data);
-}
-#else
-int
-setpwent_p(struct net_data *net_data) {
-	return (setpassent_p(0, net_data));
-}
-#endif
-
-void
-endpwent_p(struct net_data *net_data) {
-	struct irs_pw *pw;
-
-	if ((net_data != NULL) && ((pw = net_data->pw) != NULL))
-		(*pw->minimize)(pw);
-}
-
-/* Private */
-
-static struct net_data *
-init() {
-	struct net_data *net_data;
-	if (!(net_data = net_data_init(NULL)))
-		goto error;
-	if (!net_data->pw) {
-		net_data->pw = (*net_data->irs->pw_map)(net_data->irs);
-
-		if (!net_data->pw || !net_data->res) {
- error: 
-			errno = EIO;
-			return (NULL);
-		}
-		(*net_data->pw->res_set)(net_data->pw, net_data->res, NULL);
-	}
-	
-	return (net_data);
-}
-
-#endif /* WANT_IRS_PW */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/getpwent_r.c b/contrib/bind9/lib/bind/irs/getpwent_r.c
deleted file mode 100644
index 212d016..0000000
--- a/contrib/bind9/lib/bind/irs/getpwent_r.c
+++ /dev/null
@@ -1,276 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1998-1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: getpwent_r.c,v 1.6.18.2 2005/04/27 05:00:59 sra Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-#include <port_before.h>
-#if !defined(_REENTRANT) || !defined(DO_PTHREADS) || !defined(WANT_IRS_PW)
-	static int getpwent_r_not_required = 0;
-#else
-#include <errno.h>
-#include <string.h>
-#include <stdio.h>
-#include <sys/types.h>
-#if (defined(POSIX_GETPWNAM_R) || defined(POSIX_GETPWUID_R))
-#if defined(_POSIX_PTHREAD_SEMANTICS)
-	/* turn off solaris remapping in <grp.h> */
-#undef _POSIX_PTHREAD_SEMANTICS
-#include <pwd.h>
-#define _POSIX_PTHREAD_SEMANTICS 1
-#else
-#define _UNIX95 1
-#include <pwd.h>
-#endif
-#else
-#include <pwd.h>
-#endif
-#include <port_after.h>
-
-#ifdef PASS_R_RETURN
-
-static int 
-copy_passwd(struct passwd *, struct passwd *, char *buf, int buflen);
-
-/* POSIX 1003.1c */
-#ifdef POSIX_GETPWNAM_R
-int
-__posix_getpwnam_r(const char *login,  struct passwd *pwptr,
-		char *buf, size_t buflen, struct passwd **result) {
-#else
-int
-getpwnam_r(const char *login,  struct passwd *pwptr,
-		char *buf, size_t buflen, struct passwd **result) {
-#endif
-	struct passwd *pw = getpwnam(login);
-	int res;
-
-	if (pw == NULL) {
-		*result = NULL;
-		return (0);
-	}
-
-	res = copy_passwd(pw, pwptr, buf, buflen);
-	*result = res ? NULL : pwptr;
-	return (res);
-}
-
-#ifdef POSIX_GETPWNAM_R
-struct passwd *
-getpwnam_r(const char *login,  struct passwd *pwptr, char *buf, int buflen) {
-	struct passwd *pw = getpwnam(login);
-	int res;
-
-	if (pw == NULL)
-		return (NULL);
-
-	res = copy_passwd(pw, pwptr, buf, buflen);
-	return (res ? NULL : pwptr);
-}
-#endif
-
-/* POSIX 1003.1c */
-#ifdef POSIX_GETPWUID_R
-int
-__posix_getpwuid_r(uid_t uid, struct passwd *pwptr,
-		char *buf, int buflen, struct passwd **result) {
-#else
-int
-getpwuid_r(uid_t uid, struct passwd *pwptr,
-		char *buf, size_t buflen, struct passwd **result) {
-#endif
-	struct passwd *pw = getpwuid(uid);
-	int res;
-
-	if (pw == NULL) {
-		*result = NULL;
-		return (0);
-	}
-
-	res = copy_passwd(pw, pwptr, buf, buflen);
-	*result = res ? NULL : pwptr;
-	return (res);
-}
-
-#ifdef POSIX_GETPWUID_R
-struct passwd *
-getpwuid_r(uid_t uid,  struct passwd *pwptr, char *buf, int buflen) {
-	struct passwd *pw = getpwuid(uid);
-	int res;
-
-	if (pw == NULL)
-		return (NULL);
-
-	res = copy_passwd(pw, pwptr, buf, buflen);
-	return (res ? NULL : pwptr);
-}
-#endif
-
-/*%
- *	These assume a single context is in operation per thread.
- *	If this is not the case we will need to call irs directly
- *	rather than through the base functions.
- */
-
-PASS_R_RETURN
-getpwent_r(struct passwd *pwptr, PASS_R_ARGS) {
-	struct passwd *pw = getpwent();
-	int res = 0;
-
-	if (pw == NULL)
-		return (PASS_R_BAD);
-
-	res = copy_passwd(pw, pwptr, buf, buflen);
-	return (res ? PASS_R_BAD : PASS_R_OK);
-}
-
-PASS_R_SET_RETURN
-#ifdef PASS_R_ENT_ARGS
-setpassent_r(int stayopen, PASS_R_ENT_ARGS)
-#else
-setpassent_r(int stayopen)
-#endif
-{
-
-	setpassent(stayopen);
-#ifdef PASS_R_SET_RESULT
-	return (PASS_R_SET_RESULT);
-#endif
-}
-
-PASS_R_SET_RETURN
-#ifdef PASS_R_ENT_ARGS
-setpwent_r(PASS_R_ENT_ARGS)
-#else
-setpwent_r(void)
-#endif
-{
-
-	setpwent();
-#ifdef PASS_R_SET_RESULT
-	return (PASS_R_SET_RESULT);
-#endif
-}
-
-PASS_R_END_RETURN
-#ifdef PASS_R_ENT_ARGS
-endpwent_r(PASS_R_ENT_ARGS)
-#else
-endpwent_r(void)
-#endif
-{
-
-	endpwent();
-	PASS_R_END_RESULT(PASS_R_OK);
-}
-
-
-#ifdef HAS_FGETPWENT
-PASS_R_RETURN
-fgetpwent_r(FILE *f, struct passwd *pwptr, PASS_R_COPY_ARGS) {
-	struct passwd *pw = fgetpwent(f);
-	int res = 0;
-
-	if (pw == NULL)
-		return (PASS_R_BAD);
-
-	res = copy_passwd(pw, pwptr, PASS_R_COPY);
-	return (res ? PASS_R_BAD : PASS_R_OK );
-}
-#endif
-
-/* Private */
-
-static int
-copy_passwd(struct passwd *pw, struct passwd *pwptr, char *buf, int buflen) {
-	char *cp;
-	int n;
-	int len;
-
-	/* Find out the amount of space required to store the answer. */
-	len = strlen(pw->pw_name) + 1;
-	len += strlen(pw->pw_passwd) + 1;
-#ifdef HAVE_PW_CLASS
-	len += strlen(pw->pw_class) + 1;
-#endif
-	len += strlen(pw->pw_gecos) + 1;
-	len += strlen(pw->pw_dir) + 1;
-	len += strlen(pw->pw_shell) + 1;
-	
-	if (len > buflen) {
-		errno = ERANGE;
-		return (ERANGE);
-	}
-
-	/* copy fixed atomic values*/
-	pwptr->pw_uid = pw->pw_uid;
-	pwptr->pw_gid = pw->pw_gid;
-#ifdef HAVE_PW_CHANGE
-	pwptr->pw_change = pw->pw_change;
-#endif
-#ifdef HAVE_PW_EXPIRE
-	pwptr->pw_expire = pw->pw_expire;
-#endif
-
-	cp = buf;
-
-	/* copy official name */
-	n = strlen(pw->pw_name) + 1;
-	strcpy(cp, pw->pw_name);
-	pwptr->pw_name = cp;
-	cp += n;
-
-	/* copy password */
-	n = strlen(pw->pw_passwd) + 1;
-	strcpy(cp, pw->pw_passwd);
-	pwptr->pw_passwd = cp;
-	cp += n;
-
-#ifdef HAVE_PW_CLASS
-	/* copy class */
-	n = strlen(pw->pw_class) + 1;
-	strcpy(cp, pw->pw_class);
-	pwptr->pw_class = cp;
-	cp += n;
-#endif
-
-	/* copy gecos */
-	n = strlen(pw->pw_gecos) + 1;
-	strcpy(cp, pw->pw_gecos);
-	pwptr->pw_gecos = cp;
-	cp += n;
-
-	/* copy directory */
-	n = strlen(pw->pw_dir) + 1;
-	strcpy(cp, pw->pw_dir);
-	pwptr->pw_dir = cp;
-	cp += n;
-
-	/* copy login shell */
-	n = strlen(pw->pw_shell) + 1;
-	strcpy(cp, pw->pw_shell);
-	pwptr->pw_shell = cp;
-	cp += n;
-
-	return (0);
-}
-#else /* PASS_R_RETURN */
-	static int getpwent_r_unknown_system = 0;
-#endif /* PASS_R_RETURN */
-#endif /* !def(_REENTRANT) || !def(DO_PTHREADS) || !def(WANT_IRS_PW) */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/getservent.c b/contrib/bind9/lib/bind/irs/getservent.c
deleted file mode 100644
index 92ed18b..0000000
--- a/contrib/bind9/lib/bind/irs/getservent.c
+++ /dev/null
@@ -1,179 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: getservent.c,v 1.3.18.1 2005/04/27 05:00:59 sra Exp $";
-#endif
-
-/* Imports */
-
-#include "port_before.h"
-
-#if !defined(__BIND_NOSTATIC)
-
-#include <sys/types.h>
-
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-
-#include <errno.h>
-#include <resolv.h>
-#include <stdio.h>
-#include <string.h>
-
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_data.h"
-
-/* Forward */
-
-static struct net_data *init(void);
-
-/* Public */
-
-struct servent *
-getservent(void) {
-	struct net_data *net_data = init();
-
-	return (getservent_p(net_data));
-}
-
-struct servent *
-getservbyname(const char *name, const char *proto) {
-	struct net_data *net_data = init();
-
-	return (getservbyname_p(name, proto, net_data));
-}
-
-struct servent *
-getservbyport(int port, const char *proto) {
-	struct net_data *net_data = init();
-
-	return (getservbyport_p(port, proto, net_data));
-}
-
-void
-setservent(int stayopen) {
-	struct net_data *net_data = init();
-
-	setservent_p(stayopen, net_data);
-}
-
-void
-endservent() {
-	struct net_data *net_data = init();
-
-	endservent_p(net_data);
-}
-
-/* Shared private. */
-
-struct servent *
-getservent_p(struct net_data *net_data) {
-	struct irs_sv *sv;
-
-	if (!net_data || !(sv = net_data->sv))
-		return (NULL);
-	net_data->sv_last = (*sv->next)(sv);
-	return (net_data->sv_last);
-}
-
-struct servent *
-getservbyname_p(const char *name, const char *proto,
-		struct net_data *net_data) {
-	struct irs_sv *sv;
-	char **sap;
-
-	if (!net_data || !(sv = net_data->sv))
-		return (NULL);
-	if (net_data->sv_stayopen && net_data->sv_last)
-		if (!proto || !strcmp(net_data->sv_last->s_proto, proto)) {
-			if (!strcmp(net_data->sv_last->s_name, name))
-				return (net_data->sv_last);
-			for (sap = net_data->sv_last->s_aliases;
-			     sap && *sap; sap++)
-				if (!strcmp(name, *sap))
-					return (net_data->sv_last);
-		}
-	net_data->sv_last = (*sv->byname)(sv, name, proto);
-	if (!net_data->sv_stayopen)
-		endservent();
-	return (net_data->sv_last);
-}
-
-struct servent *
-getservbyport_p(int port, const char *proto, struct net_data *net_data) {
-	struct irs_sv *sv;
-
-	if (!net_data || !(sv = net_data->sv))
-		return (NULL);
-	if (net_data->sv_stayopen && net_data->sv_last)
-		if (port == net_data->sv_last->s_port &&
-		    ( !proto ||
-		     !strcmp(net_data->sv_last->s_proto, proto)))
-			return (net_data->sv_last);
-	net_data->sv_last = (*sv->byport)(sv, port, proto);
-	return (net_data->sv_last);
-}
-
-void
-setservent_p(int stayopen, struct net_data *net_data) {
-	struct irs_sv *sv;
-
-	if (!net_data || !(sv = net_data->sv))
-		return;
-	(*sv->rewind)(sv);
-	net_data->sv_stayopen = (stayopen != 0);
-	if (stayopen == 0)
-		net_data_minimize(net_data);
-}
-
-void
-endservent_p(struct net_data *net_data) {
-	struct irs_sv *sv;
-
-	if ((net_data != NULL) && ((sv = net_data->sv) != NULL))
-		(*sv->minimize)(sv);
-}
-
-/* Private */
-
-static struct net_data *
-init() {
-	struct net_data *net_data;
-
-	if (!(net_data = net_data_init(NULL)))
-		goto error;
-	if (!net_data->sv) {
-		net_data->sv = (*net_data->irs->sv_map)(net_data->irs);
-
-		if (!net_data->sv || !net_data->res) {
- error:		
-			errno = EIO;
-			return (NULL);
-		}
-		(*net_data->sv->res_set)(net_data->sv, net_data->res, NULL);
-	}
-	
-	return (net_data);
-}
-
-#endif /*__BIND_NOSTATIC*/
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/getservent_r.c b/contrib/bind9/lib/bind/irs/getservent_r.c
deleted file mode 100644
index 12c2b9b..0000000
--- a/contrib/bind9/lib/bind/irs/getservent_r.c
+++ /dev/null
@@ -1,242 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1998-1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: getservent_r.c,v 1.4.18.2 2006/08/01 01:19:12 marka Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-#include <port_before.h>
-#if !defined(_REENTRANT) || !defined(DO_PTHREADS)
-	static int getservent_r_not_required = 0;
-#else
-#include <errno.h>
-#include <string.h>
-#include <stdio.h>
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <netdb.h>
-#include <sys/param.h>
-#include <port_after.h>
-
-#ifdef SERV_R_RETURN
-
-static SERV_R_RETURN 
-copy_servent(struct servent *, struct servent *, SERV_R_COPY_ARGS);
-
-SERV_R_RETURN
-getservbyname_r(const char *name, const char *proto,
-		struct servent *sptr, SERV_R_ARGS) {
-	struct servent *se = getservbyname(name, proto);
-#ifdef SERV_R_SETANSWER
-	int n = 0;
-	
-	if (se == NULL || (n = copy_servent(se, sptr, SERV_R_COPY)) != 0)
-		*answerp = NULL;
-	else
-		*answerp = sptr;
-
-	return (n);
-#else
-	if (se == NULL)
-		return (SERV_R_BAD);
-
-	return (copy_servent(se, sptr, SERV_R_COPY));
-#endif
-}
-
-SERV_R_RETURN
-getservbyport_r(int port, const char *proto,
-		struct servent *sptr, SERV_R_ARGS) {
-	struct servent *se = getservbyport(port, proto);
-#ifdef SERV_R_SETANSWER
-	int n = 0;
-	
-	if (se == NULL || (n = copy_servent(se, sptr, SERV_R_COPY)) != 0)
-		*answerp = NULL;
-	else
-		*answerp = sptr;
-
-	return (n);
-#else
-	if (se == NULL)
-		return (SERV_R_BAD);
-
-	return (copy_servent(se, sptr, SERV_R_COPY));
-#endif
-}
-
-/*%
- *	These assume a single context is in operation per thread.
- *	If this is not the case we will need to call irs directly
- *	rather than through the base functions.
- */
-
-SERV_R_RETURN
-getservent_r(struct servent *sptr, SERV_R_ARGS) {
-	struct servent *se = getservent();
-#ifdef SERV_R_SETANSWER
-	int n = 0;
-	
-	if (se == NULL || (n = copy_servent(se, sptr, SERV_R_COPY)) != 0)
-		*answerp = NULL;
-	else
-		*answerp = sptr;
-
-	return (n);
-#else
-	if (se == NULL)
-		return (SERV_R_BAD);
-
-	return (copy_servent(se, sptr, SERV_R_COPY));
-#endif
-}
-
-SERV_R_SET_RETURN
-#ifdef SERV_R_ENT_ARGS
-setservent_r(int stay_open, SERV_R_ENT_ARGS)
-#else
-setservent_r(int stay_open)
-#endif
-{
-#ifdef SERV_R_ENT_UNUSED
-	SERV_R_ENT_UNUSED;
-#endif
-	setservent(stay_open);
-#ifdef SERV_R_SET_RESULT
-	return (SERV_R_SET_RESULT);
-#endif
-}
-
-SERV_R_END_RETURN
-#ifdef SERV_R_ENT_ARGS
-endservent_r(SERV_R_ENT_ARGS)
-#else
-endservent_r()
-#endif
-{
-#ifdef SERV_R_ENT_UNUSED
-	SERV_R_ENT_UNUSED;
-#endif
-	endservent();
-	SERV_R_END_RESULT(SERV_R_OK);
-}
-
-/* Private */
-
-#ifndef SERVENT_DATA
-static SERV_R_RETURN
-copy_servent(struct servent *se, struct servent *sptr, SERV_R_COPY_ARGS) {
-	char *cp;
-	int i, n;
-	int numptr, len;
-
-	/* Find out the amount of space required to store the answer. */
-	numptr = 1; /*%< NULL ptr */
-	len = (char *)ALIGN(buf) - buf;
-	for (i = 0; se->s_aliases[i]; i++, numptr++) {
-		len += strlen(se->s_aliases[i]) + 1;
-	}
-	len += strlen(se->s_name) + 1;
-	len += strlen(se->s_proto) + 1;
-	len += numptr * sizeof(char*);
-	
-	if (len > (int)buflen) {
-		errno = ERANGE;
-		return (SERV_R_BAD);
-	}
-
-	/* copy port value */
-	sptr->s_port = se->s_port;
-
-	cp = (char *)ALIGN(buf) + numptr * sizeof(char *);
-
-	/* copy official name */
-	n = strlen(se->s_name) + 1;
-	strcpy(cp, se->s_name);
-	sptr->s_name = cp;
-	cp += n;
-
-	/* copy aliases */
-	sptr->s_aliases = (char **)ALIGN(buf);
-	for (i = 0 ; se->s_aliases[i]; i++) {
-		n = strlen(se->s_aliases[i]) + 1;
-		strcpy(cp, se->s_aliases[i]);
-		sptr->s_aliases[i] = cp;
-		cp += n;
-	}
-	sptr->s_aliases[i] = NULL;
-
-	/* copy proto */
-	n = strlen(se->s_proto) + 1;
-	strcpy(cp, se->s_proto);
-	sptr->s_proto = cp;
-	cp += n;
-
-	return (SERV_R_OK);
-}
-#else /* !SERVENT_DATA */
-static int
-copy_servent(struct servent *se, struct servent *sptr, SERV_R_COPY_ARGS) {
-	char *cp, *eob;
-	int i, n;
-
-	/* copy port value */
-	sptr->s_port = se->s_port;
-
-	/* copy official name */
-	cp = sdptr->line;
-	eob = sdptr->line + sizeof(sdptr->line);
-	if ((n = strlen(se->s_name) + 1) < (eob - cp)) {
-		strcpy(cp, se->s_name);
-		sptr->s_name = cp;
-		cp += n;
-	} else {
-		return (-1);
-	}
-
-	/* copy aliases */
-	i = 0;
-	sptr->s_aliases = sdptr->serv_aliases;
-	while (se->s_aliases[i] && i < (_MAXALIASES-1)) {
-		if ((n = strlen(se->s_aliases[i]) + 1) < (eob - cp)) {
-			strcpy(cp, se->s_aliases[i]);
-			sptr->s_aliases[i] = cp;
-			cp += n;
-		} else {
-			break;
-		}
-		i++;
-	}
-	sptr->s_aliases[i] = NULL;
-
-	/* copy proto */
-	if ((n = strlen(se->s_proto) + 1) < (eob - cp)) {
-		strcpy(cp, se->s_proto);
-		sptr->s_proto = cp;
-		cp += n;
-	} else {
-		return (-1);
-	}
-
-	return (SERV_R_OK);
-}
-#endif /* !SERVENT_DATA */
-#else /*SERV_R_RETURN */
-	static int getservent_r_unknown_system = 0;
-#endif /*SERV_R_RETURN */
-#endif /* !defined(_REENTRANT) || !defined(DO_PTHREADS) */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/hesiod.c b/contrib/bind9/lib/bind/irs/hesiod.c
deleted file mode 100644
index 5abb57c..0000000
--- a/contrib/bind9/lib/bind/irs/hesiod.c
+++ /dev/null
@@ -1,505 +0,0 @@
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: hesiod.c,v 1.4.18.3 2005/07/28 07:38:08 marka Exp $";
-#endif
-
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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
- * \brief
- * hesiod.c --- the core portion of the hesiod resolver.
- *
- * This file is derived from the hesiod library from Project Athena;
- * It has been extensively rewritten by Theodore Ts'o to have a more
- * thread-safe interface.
- * \author
- * This file is primarily maintained by &lt;tytso@mit.edu&gt; and &lt;ghudson@mit.edu&gt;.
- */
-
-/* Imports */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-
-#include <errno.h>
-#include <netdb.h>
-#include <resolv.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-
-#include "port_after.h"
-
-#include "pathnames.h"
-#include "hesiod.h"
-#include "hesiod_p.h"
-
-/* Forward */
-
-int		hesiod_init(void **context);
-void		hesiod_end(void *context);
-char *		hesiod_to_bind(void *context, const char *name,
-			       const char *type);
-char **		hesiod_resolve(void *context, const char *name,
-			       const char *type);
-void		hesiod_free_list(void *context, char **list);
-
-static int	parse_config_file(struct hesiod_p *ctx, const char *filename);
-static char **	get_txt_records(struct hesiod_p *ctx, int class,
-				const char *name);
-static int	init(struct hesiod_p *ctx);
-
-/* Public */
-
-/*%
- * This function is called to initialize a hesiod_p.
- */
-int
-hesiod_init(void **context) {
-	struct hesiod_p *ctx;
-	char *cp;
-
-	ctx = malloc(sizeof(struct hesiod_p));
-	if (ctx == 0) {
-		errno = ENOMEM;
-		return (-1);
-	}
-
-	memset(ctx, 0, sizeof (*ctx));
-
-	if (parse_config_file(ctx, _PATH_HESIOD_CONF) < 0) {
-#ifdef DEF_RHS
-		/*
-		 * Use compiled in defaults.
-		 */
-		ctx->LHS = malloc(strlen(DEF_LHS) + 1);
-		ctx->RHS = malloc(strlen(DEF_RHS) + 1);
-		if (ctx->LHS == NULL || ctx->RHS == NULL) {
-			errno = ENOMEM;
-			goto cleanup;
-		}
-		strcpy(ctx->LHS, DEF_LHS);	/* (checked) */
-		strcpy(ctx->RHS, DEF_RHS);	/* (checked) */
-#else
-		goto cleanup;
-#endif
-	}
-	/*
-	 * The default RHS can be overridden by an environment
-	 * variable.
-	 */
-	if ((cp = getenv("HES_DOMAIN")) != NULL) {
-		size_t RHSlen = strlen(cp) + 2;
-		if (ctx->RHS)
-			free(ctx->RHS);
-		ctx->RHS = malloc(RHSlen);
-		if (!ctx->RHS) {
-			errno = ENOMEM;
-			goto cleanup;
-		}
-		if (cp[0] == '.') {
-			strcpy(ctx->RHS, cp);	/* (checked) */
-		} else {
-			strcpy(ctx->RHS, ".");	/* (checked) */
-			strcat(ctx->RHS, cp);	/* (checked) */
-		}
-	}
-
-	/*
-	 * If there is no default hesiod realm set, we return an
-	 * error.
-	 */
-	if (!ctx->RHS) {
-		errno = ENOEXEC;
-		goto cleanup;
-	}
-	
-#if 0
-	if (res_ninit(ctx->res) < 0)
-		goto cleanup;
-#endif
-
-	*context = ctx;
-	return (0);
-
- cleanup:
-	hesiod_end(ctx);
-	return (-1);
-}
-
-/*%
- * This function deallocates the hesiod_p
- */
-void
-hesiod_end(void *context) {
-	struct hesiod_p *ctx = (struct hesiod_p *) context;
-	int save_errno = errno;
-
-	if (ctx->res)
-		res_nclose(ctx->res);
-	if (ctx->RHS)
-		free(ctx->RHS);
-	if (ctx->LHS)
-		free(ctx->LHS);
-	if (ctx->res && ctx->free_res)
-		(*ctx->free_res)(ctx->res);
-	free(ctx);
-	errno = save_errno;
-}
-
-/*%
- * This function takes a hesiod (name, type) and returns a DNS
- * name which is to be resolved.
- */
-char *
-hesiod_to_bind(void *context, const char *name, const char *type) {
-	struct hesiod_p *ctx = (struct hesiod_p *) context;
-	char *bindname;
-	char **rhs_list = NULL;
-	const char *RHS, *cp;
-
-	/* Decide what our RHS is, and set cp to the end of the actual name. */
-	if ((cp = strchr(name, '@')) != NULL) {
-		if (strchr(cp + 1, '.'))
-			RHS = cp + 1;
-		else if ((rhs_list = hesiod_resolve(context, cp + 1,
-		    "rhs-extension")) != NULL)
-			RHS = *rhs_list;
-		else {
-			errno = ENOENT;
-			return (NULL);
-		}
-	} else {
-		RHS = ctx->RHS;
-		cp = name + strlen(name);
-	}
-
-	/*
-	 * Allocate the space we need, including up to three periods and
-	 * the terminating NUL.
-	 */
-	if ((bindname = malloc((cp - name) + strlen(type) + strlen(RHS) +
-	    (ctx->LHS ? strlen(ctx->LHS) : 0) + 4)) == NULL) {
-		errno = ENOMEM;
-		if (rhs_list)
-			hesiod_free_list(context, rhs_list);
-		return NULL;
-	}
-
-	/* Now put together the DNS name. */
-	memcpy(bindname, name, cp - name);
-	bindname[cp - name] = '\0';
-	strcat(bindname, ".");
-	strcat(bindname, type);
-	if (ctx->LHS) {
-		if (ctx->LHS[0] != '.')
-			strcat(bindname, ".");
-		strcat(bindname, ctx->LHS);
-	}
-	if (RHS[0] != '.')
-		strcat(bindname, ".");
-	strcat(bindname, RHS);
-
-	if (rhs_list)
-		hesiod_free_list(context, rhs_list);
-
-	return (bindname);
-}
-
-/*%
- * This is the core function.  Given a hesiod (name, type), it
- * returns an array of strings returned by the resolver.
- */
-char **
-hesiod_resolve(void *context, const char *name, const char *type) {
-	struct hesiod_p *ctx = (struct hesiod_p *) context;
-	char *bindname = hesiod_to_bind(context, name, type);
-	char **retvec;
-
-	if (bindname == NULL)
-		return (NULL);
-	if (init(ctx) == -1) {
-		free(bindname);
-		return (NULL);
-	}
-
-	if ((retvec = get_txt_records(ctx, C_IN, bindname))) {
-		free(bindname);
-		return (retvec);
-	}
-	
-	if (errno != ENOENT)
-		return (NULL);
-
-	retvec = get_txt_records(ctx, C_HS, bindname);
-	free(bindname);
-	return (retvec);
-}
-
-void
-hesiod_free_list(void *context, char **list) {
-	char **p;
-
-	UNUSED(context);
-
-	for (p = list; *p; p++)
-		free(*p);
-	free(list);
-}
-
-/*%
- * This function parses the /etc/hesiod.conf file
- */
-static int
-parse_config_file(struct hesiod_p *ctx, const char *filename) {
-	char *key, *data, *cp, **cpp;
-	char buf[MAXDNAME+7];
-	FILE *fp;
-
-	/*
-	 * Clear the existing configuration variable, just in case
-	 * they're set.
-	 */
-	if (ctx->RHS)
-		free(ctx->RHS);
-	if (ctx->LHS)
-		free(ctx->LHS);
-	ctx->RHS = ctx->LHS = 0;
-
-	/*
-	 * Now open and parse the file...
-	 */
-	if (!(fp = fopen(filename, "r")))
-		return (-1);
-	
-	while (fgets(buf, sizeof(buf), fp) != NULL) {
-		cp = buf;
-		if (*cp == '#' || *cp == '\n' || *cp == '\r')
-			continue;
-		while(*cp == ' ' || *cp == '\t')
-			cp++;
-		key = cp;
-		while(*cp != ' ' && *cp != '\t' && *cp != '=')
-			cp++;
-		*cp++ = '\0';
-		
-		while(*cp == ' ' || *cp == '\t' || *cp == '=')
-			cp++;
-		data = cp;
-		while(*cp != ' ' && *cp != '\n' && *cp != '\r')
-			cp++;
-		*cp++ = '\0';
-
-		if (strcmp(key, "lhs") == 0)
-			cpp = &ctx->LHS;
-		else if (strcmp(key, "rhs") == 0)
-			cpp = &ctx->RHS;
-		else
-			continue;
-
-		*cpp = malloc(strlen(data) + 1);
-		if (!*cpp) {
-			errno = ENOMEM;
-			goto cleanup;
-		}
-		strcpy(*cpp, data);
-	}
-	fclose(fp);
-	return (0);
-	
- cleanup:
-	fclose(fp);
-	if (ctx->RHS)
-		free(ctx->RHS);
-	if (ctx->LHS)
-		free(ctx->LHS);
-	ctx->RHS = ctx->LHS = 0;
-	return (-1);
-}
-
-/*%
- * Given a DNS class and a DNS name, do a lookup for TXT records, and
- * return a list of them.
- */
-static char **
-get_txt_records(struct hesiod_p *ctx, int class, const char *name) {
-	struct {
-		int type;		/*%< RR type */
-		int class;		/*%< RR class */
-		int dlen;		/*%< len of data section */
-		u_char *data;		/*%< pointer to data */
-	} rr;
-	HEADER *hp;
-	u_char qbuf[MAX_HESRESP], abuf[MAX_HESRESP];
-	u_char *cp, *erdata, *eom;
-	char *dst, *edst, **list;
-	int ancount, qdcount;
-	int i, j, n, skip;
-
-	/*
-	 * Construct the query and send it.
-	 */
-	n = res_nmkquery(ctx->res, QUERY, name, class, T_TXT, NULL, 0,
-			 NULL, qbuf, MAX_HESRESP);
-	if (n < 0) {
-		errno = EMSGSIZE;
-		return (NULL);
-	}
-	n = res_nsend(ctx->res, qbuf, n, abuf, MAX_HESRESP);
-	if (n < 0) {
-		errno = ECONNREFUSED;
-		return (NULL);
-	}
-	if (n < HFIXEDSZ) {
-		errno = EMSGSIZE;
-		return (NULL);
-	}
-
-	/*
-	 * OK, parse the result.
-	 */
-	hp = (HEADER *) abuf;
-	ancount = ntohs(hp->ancount);
-	qdcount = ntohs(hp->qdcount);
-	cp = abuf + sizeof(HEADER);
-	eom = abuf + n;
-
-	/* Skip query, trying to get to the answer section which follows. */
-	for (i = 0; i < qdcount; i++) {
-		skip = dn_skipname(cp, eom);
-		if (skip < 0 || cp + skip + QFIXEDSZ > eom) {
-			errno = EMSGSIZE;
-			return (NULL);
-		}
-		cp += skip + QFIXEDSZ;
-	}
-
-	list = malloc((ancount + 1) * sizeof(char *));
-	if (!list) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	j = 0;
-	for (i = 0; i < ancount; i++) {
-		skip = dn_skipname(cp, eom);
-		if (skip < 0) {
-			errno = EMSGSIZE;
-			goto cleanup;
-		}
-		cp += skip;
-		if (cp + 3 * INT16SZ + INT32SZ > eom) {
-			errno = EMSGSIZE;
-			goto cleanup;
-		}
-		rr.type = ns_get16(cp);
-		cp += INT16SZ;
-		rr.class = ns_get16(cp);
-		cp += INT16SZ + INT32SZ;	/*%< skip the ttl, too */
-		rr.dlen = ns_get16(cp);
-		cp += INT16SZ;
-		if (cp + rr.dlen > eom) {
-			errno = EMSGSIZE;
-			goto cleanup;
-		}
-		rr.data = cp;
-		cp += rr.dlen;
-		if (rr.class != class || rr.type != T_TXT)
-			continue;
-		if (!(list[j] = malloc(rr.dlen)))
-			goto cleanup;
-		dst = list[j++];
-		edst = dst + rr.dlen;
-		erdata = rr.data + rr.dlen;
-		cp = rr.data;
-		while (cp < erdata) {
-			n = (unsigned char) *cp++;
-			if (cp + n > eom || dst + n > edst) {
-				errno = EMSGSIZE;
-				goto cleanup;
-			}
-			memcpy(dst, cp, n);
-			cp += n;
-			dst += n;
-		}
-		if (cp != erdata) {
-			errno = EMSGSIZE;
-			goto cleanup;
-		}
-		*dst = '\0';
-	}
-	list[j] = NULL;
-	if (j == 0) {
-		errno = ENOENT;
-		goto cleanup;
-	}
-	return (list);
-
- cleanup:
-	for (i = 0; i < j; i++)
-		free(list[i]);
-	free(list);
-	return (NULL);
-}
-
-struct __res_state *
-__hesiod_res_get(void *context) {
-	struct hesiod_p *ctx = context;
-
-	if (!ctx->res) {
-		struct __res_state *res;
-		res = (struct __res_state *)malloc(sizeof *res);
-		if (res == NULL) {
-			errno = ENOMEM;
-			return (NULL);
-		}
-		memset(res, 0, sizeof *res);
-		__hesiod_res_set(ctx, res, free);
-	}
-
-	return (ctx->res);
-}
-
-void
-__hesiod_res_set(void *context, struct __res_state *res,
-	         void (*free_res)(void *)) {
-	struct hesiod_p *ctx = context;
-
-	if (ctx->res && ctx->free_res) {
-		res_nclose(ctx->res);
-		(*ctx->free_res)(ctx->res);
-	}
-
-	ctx->res = res;
-	ctx->free_res = free_res;
-}
-
-static int
-init(struct hesiod_p *ctx) {
-	
-	if (!ctx->res && !__hesiod_res_get(ctx))
-		return (-1);
-
-	if (((ctx->res->options & RES_INIT) == 0U) &&
-	    (res_ninit(ctx->res) == -1))
-		return (-1);
-
-	return (0);
-}
diff --git a/contrib/bind9/lib/bind/irs/hesiod_p.h b/contrib/bind9/lib/bind/irs/hesiod_p.h
deleted file mode 100644
index f42f84a..0000000
--- a/contrib/bind9/lib/bind/irs/hesiod_p.h
+++ /dev/null
@@ -1,48 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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: hesiod_p.h,v 1.2.18.1 2005/04/27 05:00:59 sra Exp $
- */
-
-#ifndef _HESIOD_P_H_INCLUDED
-#define _HESIOD_P_H_INCLUDED
-
-/** \file
- * \brief
- * hesiod_p.h -- private definitions for the hesiod library.
- *
- * \author
- * This file is primarily maintained by tytso@mit.edu and ghudson@mit.edu.
- */
-
-#define DEF_RHS		".Athena.MIT.EDU"	/*%< Defaults if HESIOD_CONF */
-#define DEF_LHS		".ns"			/*%<    file is not */
-						/*%<    present. */
-struct hesiod_p {
-	char *		LHS;		/*%< normally ".ns" */
-	char *		RHS;		/*%< AKA the default hesiod domain */
-	struct __res_state * res;	/*%< resolver context */
-	void		(*free_res)(void *);
-	void		(*res_set)(struct hesiod_p *, struct __res_state *,
-				   void (*)(void *));
-	struct __res_state * (*res_get)(struct hesiod_p *);
-};
-
-#define MAX_HESRESP	1024
-
-#endif /*_HESIOD_P_H_INCLUDED*/
diff --git a/contrib/bind9/lib/bind/irs/irp.c b/contrib/bind9/lib/bind/irs/irp.c
deleted file mode 100644
index aae4e7b..0000000
--- a/contrib/bind9/lib/bind/irs/irp.c
+++ /dev/null
@@ -1,583 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996, 1998 by 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.
- */
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: irp.c,v 1.6.18.5 2008/02/28 05:49:37 marka Exp $";
-#endif
-
-/* Imports */
-
-#include "port_before.h"
-
-#include <syslog.h>
-#include <sys/types.h>
-#include <sys/socket.h>
-#include <sys/un.h>
-#include <netinet/in.h>
-#include <arpa/inet.h>
-#include <stdlib.h>
-#include <errno.h>
-#include <string.h>
-#include <stdarg.h>
-#include <fcntl.h>
-#include <syslog.h>
-#include <ctype.h>
-#include <unistd.h>
-
-#include <isc/memcluster.h>
-
-#include <irs.h>
-#include <irp.h>
-
-#include "irs_p.h"
-#include "irp_p.h"
-
-#include "port_after.h"
-
-/* Forward. */
-
-static void		irp_close(struct irs_acc *);
-
-#define LINEINCR 128
-
-#if !defined(SUN_LEN)
-#define SUN_LEN(su) \
-	(sizeof (*(su)) - sizeof ((su)->sun_path) + strlen((su)->sun_path))
-#endif
-
-
-/* Public */
-
-
-/* send errors to syslog if true. */
-int irp_log_errors = 1;
-
-/*%
- * This module handles the irp module connection to irpd.
- *
- * The client expects a synchronous interface to functions like
- * getpwnam(3), so we can't use the ctl_* i/o library on this end of
- * the wire (it's used in the server).
- */
-
-/*%
- * irs_acc *irs_irp_acc(const char *options);
- *
- *	Initialize the irp module.
- */
-struct irs_acc *
-irs_irp_acc(const char *options) {
-	struct irs_acc *acc;
-	struct irp_p *irp;
-
-	UNUSED(options);
-
-	if (!(acc = memget(sizeof *acc))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(acc, 0x5e, sizeof *acc);
-	if (!(irp = memget(sizeof *irp))) {
-		errno = ENOMEM;
-		free(acc);
-		return (NULL);
-	}
-	irp->inlast = 0;
-	irp->incurr = 0;
-	irp->fdCxn = -1;
-	acc->private = irp;
-
-#ifdef WANT_IRS_GR
-	acc->gr_map = irs_irp_gr;
-#else
-	acc->gr_map = NULL;
-#endif
-#ifdef WANT_IRS_PW
-	acc->pw_map = irs_irp_pw;
-#else
-	acc->pw_map = NULL;
-#endif
-	acc->sv_map = irs_irp_sv;
-	acc->pr_map = irs_irp_pr;
-	acc->ho_map = irs_irp_ho;
-	acc->nw_map = irs_irp_nw;
-	acc->ng_map = irs_irp_ng;
-	acc->close = irp_close;
-	return (acc);
-}
-
-
-int
-irs_irp_connection_setup(struct irp_p *cxndata, int *warned) {
-	if (irs_irp_is_connected(cxndata)) {
-		return (0);
-	} else if (irs_irp_connect(cxndata) != 0) {
-		if (warned != NULL && !*warned) {
-			syslog(LOG_ERR, "irpd connection failed: %m\n");
-			(*warned)++;
-		}
-
-		return (-1);
-	}
-
-	return (0);
-}
-
-/*%
- * int irs_irp_connect(void);
- *
- *	Sets up the connection to the remote irpd server.
- *
- * Returns:
- *
- *	0 on success, -1 on failure.
- *
- */
-int
-irs_irp_connect(struct irp_p *pvt) {
-	int flags;
-	struct sockaddr *addr;
-	struct sockaddr_in iaddr;
-#ifndef NO_SOCKADDR_UN
-	struct sockaddr_un uaddr;
-#endif
-	long ipaddr;
-	const char *irphost;
-	int code;
-	char text[256];
-	int socklen = 0;
-
-	if (pvt->fdCxn != -1) {
-		perror("fd != 1");
-		return (-1);
-	}
-
-#ifndef NO_SOCKADDR_UN
-	memset(&uaddr, 0, sizeof uaddr);
-#endif
-	memset(&iaddr, 0, sizeof iaddr);
-
-	irphost = getenv(IRPD_HOST_ENV);
-	if (irphost == NULL) {
-		irphost = "127.0.0.1";
-	}
-
-#ifndef NO_SOCKADDR_UN
-	if (irphost[0] == '/') {
-		addr = (struct sockaddr *)&uaddr;
-		strncpy(uaddr.sun_path, irphost, sizeof uaddr.sun_path);
-		uaddr.sun_family = AF_UNIX;
-		socklen = SUN_LEN(&uaddr);
-#ifdef HAVE_SA_LEN
-		uaddr.sun_len = socklen;
-#endif
-	} else
-#endif
-	{
-		if (inet_pton(AF_INET, irphost, &ipaddr) != 1) {
-			errno = EADDRNOTAVAIL;
-			perror("inet_pton");
-			return (-1);
-		}
-
-		addr = (struct sockaddr *)&iaddr;
-		socklen = sizeof iaddr;
-#ifdef HAVE_SA_LEN
-		iaddr.sin_len = socklen;
-#endif
-		iaddr.sin_family = AF_INET;
-		iaddr.sin_port = htons(IRPD_PORT);
-		iaddr.sin_addr.s_addr = ipaddr;
-	}
-
-
-	pvt->fdCxn = socket(addr->sa_family, SOCK_STREAM, PF_UNSPEC);
-	if (pvt->fdCxn < 0) {
-		perror("socket");
-		return (-1);
-	}
-
-	if (connect(pvt->fdCxn, addr, socklen) != 0) {
-		perror("connect");
-		return (-1);
-	}
-
-	flags = fcntl(pvt->fdCxn, F_GETFL, 0);
-	if (flags < 0) {
-		close(pvt->fdCxn);
-		perror("close");
-		return (-1);
-	}
-
-#if 0
-	flags |= O_NONBLOCK;
-	if (fcntl(pvt->fdCxn, F_SETFL, flags) < 0) {
-		close(pvt->fdCxn);
-		perror("fcntl");
-		return (-1);
-	}
-#endif
-
-	code = irs_irp_read_response(pvt, text, sizeof text);
-	if (code != IRPD_WELCOME_CODE) {
-		if (irp_log_errors) {
-			syslog(LOG_WARNING, "Connection failed: %s", text);
-		}
-		irs_irp_disconnect(pvt);
-		return (-1);
-	}
-
-	return (0);
-}
-
-/*%
- * int	irs_irp_is_connected(struct irp_p *pvt);
- *
- * Returns:
- *
- *	Non-zero if streams are setup to remote.
- *
- */
-
-int
-irs_irp_is_connected(struct irp_p *pvt) {
-	return (pvt->fdCxn >= 0);
-}
-
-/*%
- * void
- * irs_irp_disconnect(struct irp_p *pvt);
- *
- *	Closes streams to remote.
- */
-
-void
-irs_irp_disconnect(struct irp_p *pvt) {
-	if (pvt->fdCxn != -1) {
-		close(pvt->fdCxn);
-		pvt->fdCxn = -1;
-	}
-}
-
-
-
-int
-irs_irp_read_line(struct irp_p *pvt, char *buffer, int len) {
-	char *realstart = &pvt->inbuffer[0];
-	char *p, *start, *end;
-	int spare;
-	int i;
-	int buffpos = 0;
-	int left = len - 1;
-
-	while (left > 0) {
-		start = p = &pvt->inbuffer[pvt->incurr];
-		end = &pvt->inbuffer[pvt->inlast];
-
-		while (p != end && *p != '\n')
-			p++;
-
-		if (p == end) {
-			/* Found no newline so shift data down if necessary
-			 * and append new data to buffer
-			 */
-			if (start > realstart) {
-				memmove(realstart, start, end - start);
-				pvt->inlast = end - start;
-				start = realstart;
-				pvt->incurr = 0;
-				end = &pvt->inbuffer[pvt->inlast];
-			}
-
-			spare = sizeof (pvt->inbuffer) - pvt->inlast;
-
-			p = end;
-			i = read(pvt->fdCxn, end, spare);
-			if (i < 0) {
-				close(pvt->fdCxn);
-				pvt->fdCxn = -1;
-				return (buffpos > 0 ? buffpos : -1);
-			} else if (i == 0) {
-				return (buffpos);
-			}
-
-			end += i;
-			pvt->inlast += i;
-
-			while (p != end && *p != '\n')
-				p++;
-		}
-
-		if (p == end) {
-			/* full buffer and still no newline */
-			i = sizeof pvt->inbuffer;
-		} else {
-			/* include newline */
-			i = p - start + 1;
-		}
-
-		if (i > left)
-			i = left;
-		memcpy(buffer + buffpos, start, i);
-		pvt->incurr += i;
-		buffpos += i;
-		buffer[buffpos] = '\0';
-
-		if (p != end) {
-			left = 0;
-		} else {
-			left -= i;
-		}
-	}
-
-#if 0
-	fprintf(stderr, "read line: %s\n", buffer);
-#endif
-	return (buffpos);
-}
-
-/*%
- * int irp_read_response(struct irp_p *pvt);
- *
- * Returns:
- *
- *	The number found at the beginning of the line read from
- *	FP. 0 on failure(0 is not a legal response code). The
- *	rest of the line is discarded.
- *
- */
-
-int
-irs_irp_read_response(struct irp_p *pvt, char *text, size_t textlen) {
-	char line[1024];
-	int code;
-	char *p;
-
-	if (irs_irp_read_line(pvt, line, sizeof line) <= 0) {
-		return (0);
-	}
-
-	p = strchr(line, '\n');
-	if (p == NULL) {
-		return (0);
-	}
-
-	if (sscanf(line, "%d", &code) != 1) {
-		code = 0;
-	} else if (text != NULL && textlen > 0U) {
-		p = line;
-		while (isspace((unsigned char)*p)) p++;
-		while (isdigit((unsigned char)*p)) p++;
-		while (isspace((unsigned char)*p)) p++;
-		strncpy(text, p, textlen - 1);
-		p[textlen - 1] = '\0';
-	}
-
-	return (code);
-}
-
-/*%
- * char *irp_read_body(struct irp_p *pvt, size_t *size);
- *
- *	Read in the body of a response. Terminated by a line with
- *	just a dot on it. Lines should be terminated with a CR-LF
- *	sequence, but we're nt piccky if the CR is missing.
- *	No leading dot escaping is done as the protcol doesn't
- *	use leading dots anywhere.
- *
- * Returns:
- *
- *	Pointer to null-terminated buffer allocated by memget.
- *	*SIZE is set to the length of the buffer.
- *
- */
-
-char *
-irs_irp_read_body(struct irp_p *pvt, size_t *size) {
-	char line[1024];
-	u_int linelen;
-	size_t len = LINEINCR;
-	char *buffer = memget(len);
-	int idx = 0;
-
-	if (buffer == NULL)
-		return (NULL);
-
-	for (;;) {
-		if (irs_irp_read_line(pvt, line, sizeof line) <= 0 ||
-		    strchr(line, '\n') == NULL)
-			goto death;
-
-		linelen = strlen(line);
-
-		if (line[linelen - 1] != '\n')
-			goto death;
-
-		/* We're not strict about missing \r. Should we be??  */
-		if (linelen > 2 && line[linelen - 2] == '\r') {
-			line[linelen - 2] = '\n';
-			line[linelen - 1] = '\0';
-			linelen--;
-		}
-
-		if (linelen == 2 && line[0] == '.') {
-			*size = len;
-			buffer[idx] = '\0';
-
-			return (buffer);
-		}
-
-		if (linelen > (len - (idx + 1))) {
-			char *p = memget(len + LINEINCR);
-
-			if (p == NULL)
-				goto death;
-			memcpy(p, buffer, len);
-			memput(buffer, len);
-			buffer = p;
-			len += LINEINCR;
-		}
-
-		memcpy(buffer + idx, line, linelen);
-		idx += linelen;
-	}
- death:
-	memput(buffer, len);
-	return (NULL);
-}
-
-/*%
- * int irs_irp_get_full_response(struct irp_p *pvt, int *code,
- *			char **body, size_t *bodylen);
- *
- *	Gets the response to a command. If the response indicates
- *	there's a body to follow(code % 10 == 1), then the
- *	body buffer is allcoated with memget and stored in
- *	*BODY. The length of the allocated body buffer is stored
- *	in *BODY. The caller must give the body buffer back to
- *	memput when done. The results code is stored in *CODE.
- *
- * Returns:
- *
- *	0 if a result was read. -1 on some sort of failure.
- *
- */
-
-int
-irs_irp_get_full_response(struct irp_p *pvt, int *code, char *text,
-			  size_t textlen, char **body, size_t *bodylen) {
-	int result = irs_irp_read_response(pvt, text, textlen);
-
-	*body = NULL;
-
-	if (result == 0) {
-		return (-1);
-	}
-
-	*code = result;
-
-	/* Code that matches 2xx is a good result code.
-	 * Code that matches xx1 means there's a response body coming.
-	 */
-	if ((result / 100) == 2 && (result % 10) == 1) {
-		*body = irs_irp_read_body(pvt, bodylen);
-		if (*body == NULL) {
-			return (-1);
-		}
-	}
-
-	return (0);
-}
-
-/*%
- * int irs_irp_send_command(struct irp_p *pvt, const char *fmt, ...);
- *
- *	Sends command to remote connected via the PVT
- *	structure. FMT and args after it are fprintf-like
- *	arguments for formatting.
- *
- * Returns:
- *
- *	0 on success, -1 on failure.
- */
-
-int
-irs_irp_send_command(struct irp_p *pvt, const char *fmt, ...) {
-	va_list ap;
-	char buffer[1024];
-	int pos = 0;
-	int i, todo;
-
-
-	if (pvt->fdCxn < 0) {
-		return (-1);
-	}
-
-	va_start(ap, fmt);
-	(void) vsprintf(buffer, fmt, ap);
-	todo = strlen(buffer);
-	va_end(ap);
-	if (todo > (int)sizeof(buffer) - 3) {
-		syslog(LOG_CRIT, "memory overrun in irs_irp_send_command()");
-		exit(1);
-	}
-	strcat(buffer, "\r\n");
-	todo = strlen(buffer);
-
-	while (todo > 0) {
-		i = write(pvt->fdCxn, buffer + pos, todo);
-#if 0
-		/* XXX brister */
-		fprintf(stderr, "Wrote: \"");
-		fwrite(buffer + pos, sizeof (char), todo, stderr);
-		fprintf(stderr, "\"\n");
-#endif
-		if (i < 0) {
-			close(pvt->fdCxn);
-			pvt->fdCxn = -1;
-			return (-1);
-		}
-		todo -= i;
-	}
-
-	return (0);
-}
-
-
-/* Methods */
-
-/*%
- * void irp_close(struct irs_acc *this)
- *
- */
-
-static void
-irp_close(struct irs_acc *this) {
-	struct irp_p *irp = (struct irp_p *)this->private;
-
-	if (irp != NULL) {
-		irs_irp_disconnect(irp);
-		memput(irp, sizeof *irp);
-	}
-
-	memput(this, sizeof *this);
-}
-
-
-
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/irp_gr.c b/contrib/bind9/lib/bind/irs/irp_gr.c
deleted file mode 100644
index bdab3da..0000000
--- a/contrib/bind9/lib/bind/irs/irp_gr.c
+++ /dev/null
@@ -1,357 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Portions Copyright(c) 1996, 1998 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: irp_gr.c,v 1.3.18.1 2005/04/27 05:01:00 sra Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-/* extern */
-
-#include "port_before.h"
-
-#ifndef WANT_IRS_PW
-static int __bind_irs_gr_unneeded;
-#else
-
-#include <syslog.h>
-#include <sys/param.h>
-#include <sys/types.h>
-
-#include <errno.h>
-#include <fcntl.h>
-#include <grp.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <unistd.h>
-#include <syslog.h>
-
-#include <irs.h>
-#include <irp.h>
-#include <isc/memcluster.h>
-#include <isc/irpmarshall.h>
-
-#include "irs_p.h"
-#include "lcl_p.h"
-#include "irp_p.h"
-
-#include "port_after.h"
-
-
-/* Types. */
-
-/*! \file 
- * \brief
- * Module for the getnetgrent(3) family to use when connected to a
- * remote irp daemon.
- * \brief
- * See irpd.c for justification of caching done here.
- *
- */
-
-struct pvt {
-	struct irp_p   *girpdata;	/*%< global IRP data */
-	int		warned;
-	struct group	group;
-};
-
-/* Forward. */
-
-static void		gr_close(struct irs_gr *);
-static struct group *	gr_next(struct irs_gr *);
-static struct group *	gr_byname(struct irs_gr *, const char *);
-static struct group *	gr_bygid(struct irs_gr *, gid_t);
-static void		gr_rewind(struct irs_gr *);
-static void		gr_minimize(struct irs_gr *);
-
-/* Private */
-static void		free_group(struct group *gr);
-
-
-/* Public. */
-
-/*%
- *	Initialize the group sub-module.
- *
- */
-
-struct irs_gr *
-irs_irp_gr(struct irs_acc *this) {
-	struct irs_gr *gr;
-	struct pvt *pvt;
-
-	if (!(gr = memget(sizeof *gr))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(gr, 0x0, sizeof *gr);
-
-	if (!(pvt = memget(sizeof *pvt))) {
-		memput(gr, sizeof *gr);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0x0, sizeof *pvt);
-	pvt->girpdata = this->private;
-
-	gr->private = pvt;
-	gr->close = gr_close;
-	gr->next = gr_next;
-	gr->byname = gr_byname;
-	gr->bygid = gr_bygid;
-	gr->rewind = gr_rewind;
-	gr->list = make_group_list;
-	gr->minimize = gr_minimize;
-	return (gr);
-}
-
-/* Methods. */
-
-/*%
- *	Close the sub-module.
- *
- */
-
-static void
-gr_close(struct irs_gr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	gr_minimize(this);
-
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-/*%
- *	Gets the next group out of the cached data and returns it.
- *
- */
-
-static struct group *
-gr_next(struct irs_gr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct group *gr = &pvt->group;
-	char *body;
-	size_t bodylen;
-	int code;
-	char text[256];
-
-	if (irs_irp_connection_setup(pvt->girpdata, &pvt->warned) != 0) {
-		return (NULL);
-	}
-
-	if (irs_irp_send_command(pvt->girpdata, "getgrent") != 0) {
-		return (NULL);
-	}
-
-	if (irs_irp_get_full_response(pvt->girpdata, &code,
-				      text, sizeof text,
-				      &body, &bodylen) != 0) {
-		if (irp_log_errors) {
-			syslog(LOG_WARNING, "getgrent failed: %s", text);
-		}
-		return (NULL);
-	}
-
-	if (code == IRPD_GETGROUP_OK) {
-		free_group(gr);
-		if (irp_unmarshall_gr(gr, body) != 0) {
-			gr = NULL;
-		}
-	} else {
-		gr = NULL;
-	}
-
-	if (body != NULL) {
-		memput(body, bodylen);
-	}
-
-	return (gr);
-}
-
-/*%
- *	Gets a group by name from irpd and returns it.
- *
- */
-
-static struct group *
-gr_byname(struct irs_gr *this, const char *name) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct group *gr = &pvt->group;
-	char *body;
-	size_t bodylen;
-	int code;
-	char text[256];
-
-
-	if (gr->gr_name != NULL && strcmp(name, gr->gr_name) == 0) {
-		return (gr);
-	}
-
-	if (irs_irp_connection_setup(pvt->girpdata, &pvt->warned) != 0) {
-		return (NULL);
-	}
-
-	if (irs_irp_send_command(pvt->girpdata, "getgrnam %s", name) != 0)
-		return (NULL);
-
-	if (irs_irp_get_full_response(pvt->girpdata, &code,
-				      text, sizeof text,
-				      &body, &bodylen) != 0) {
-		return (NULL);
-	}
-
-	if (code == IRPD_GETGROUP_OK) {
-		free_group(gr);
-		if (irp_unmarshall_gr(gr, body) != 0) {
-			gr = NULL;
-		}
-	} else {
-		gr = NULL;
-	}
-
-	if (body != NULL) {
-		memput(body, bodylen);
-	}
-
-	return (gr);
-}
-
-/*%
- *	Gets a group by gid from irpd and returns it.
- *
- */
-
-static struct group *
-gr_bygid(struct irs_gr *this, gid_t gid) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct group *gr = &pvt->group;
-	char *body;
-	size_t bodylen;
-	int code;
-	char text[256];
-
-	if (gr->gr_name != NULL && (gid_t)gr->gr_gid == gid) {
-		return (gr);
-	}
-
-	if (irs_irp_connection_setup(pvt->girpdata, &pvt->warned) != 0) {
-		return (NULL);
-	}
-
-	if (irs_irp_send_command(pvt->girpdata, "getgrgid %d", gid) != 0)
-		return (NULL);
-
-	if (irs_irp_get_full_response(pvt->girpdata, &code,
-				      text, sizeof text,
-				      &body, &bodylen) != 0) {
-		return (NULL);
-	}
-
-	if (code == IRPD_GETGROUP_OK) {
-		free_group(gr);
-		if (irp_unmarshall_gr(gr, body) != 0) {
-			gr = NULL;
-		}
-	} else {
-		gr = NULL;
-	}
-
-	if (body != NULL) {
-		memput(body, bodylen);
-	}
-
-	return (gr);
-}
-
-/*%
- * void gr_rewind(struct irs_gr *this)
- *
- */
-
-static void
-gr_rewind(struct irs_gr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	char text[256];
-	int code;
-
-	if (irs_irp_connection_setup(pvt->girpdata, &pvt->warned) != 0) {
-		return;
-	}
-
-	if (irs_irp_send_command(pvt->girpdata, "setgrent") != 0) {
-		return;
-	}
-
-	code = irs_irp_read_response(pvt->girpdata, text, sizeof text);
-	if (code != IRPD_GETGROUP_SETOK) {
-		if (irp_log_errors) {
-			syslog(LOG_WARNING, "setgrent failed: %s", text);
-		}
-	}
-
-	return;
-}
-
-/*%
- *	Frees up cached data and disconnects(if necessary) from the remote.
- *
- */
-
-static void
-gr_minimize(struct irs_gr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	free_group(&pvt->group);
-	irs_irp_disconnect(pvt->girpdata);
-}
-
-/* Private. */
-
-/*%
- * static void free_group(struct group *gr);
- *
- *	Deallocate all the memory irp_unmarshall_gr allocated.
- *
- */
-
-static void
-free_group(struct group *gr) {
-	char **p;
-
-	if (gr == NULL)
-		return;
-
-	if (gr->gr_name != NULL)
-		free(gr->gr_name);
-
-	if (gr->gr_passwd != NULL)
-		free(gr->gr_passwd);
-
-	for (p = gr->gr_mem ; p != NULL && *p != NULL ; p++)
-		free(*p);
-
-	if (gr->gr_mem)
-		free(gr->gr_mem);
-
-	if (p != NULL)
-		free(p);
-}
-
-
-#endif /* WANT_IRS_GR */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/irp_ho.c b/contrib/bind9/lib/bind/irs/irp_ho.c
deleted file mode 100644
index d71285e..0000000
--- a/contrib/bind9/lib/bind/irs/irp_ho.c
+++ /dev/null
@@ -1,405 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Portions Copyright (c) 1996,1998 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: irp_ho.c,v 1.2.18.1 2005/04/27 05:01:00 sra Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-/* Imports. */
-
-#include "port_before.h"
-
-#include <syslog.h>
-#include <sys/types.h>
-#include <sys/param.h>
-#include <sys/socket.h>
-
-#include <netinet/in.h>
-#include <arpa/inet.h>
-#include <arpa/nameser.h>
-
-#include <ctype.h>
-#include <errno.h>
-#include <fcntl.h>
-#include <netdb.h>
-#include <resolv.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <syslog.h>
-
-#include <irs.h>
-#include <irp.h>
-#include <isc/irpmarshall.h>
-#include <isc/memcluster.h>
-
-#include "irs_p.h"
-#include "dns_p.h"
-#include "irp_p.h"
-
-#include "port_after.h"
-
-/* Definitions. */
-
-#define	MAXALIASES	35
-#define	MAXADDRS	35
-#define	Max(a,b)	((a) > (b) ? (a) : (b))
-
-
-struct pvt {
-	struct irp_p	       *girpdata;
-	int			warned;
-	struct hostent		host;
-};
-
-/* Forward. */
-
-static void		ho_close(struct irs_ho *this);
-static struct hostent *	ho_byname(struct irs_ho *this, const char *name);
-static struct hostent *	ho_byname2(struct irs_ho *this, const char *name,
-				   int af);
-static struct hostent *	ho_byaddr(struct irs_ho *this, const void *addr,
-				  int len, int af);
-static struct hostent *	ho_next(struct irs_ho *this);
-static void		ho_rewind(struct irs_ho *this);
-static void		ho_minimize(struct irs_ho *this);
-
-static void		free_host(struct hostent *ho);
-static struct addrinfo * ho_addrinfo(struct irs_ho *this, const char *name,
-				     const struct addrinfo *pai);
-
-/* Public. */
-
-/*%
- * struct irs_ho * irs_irp_ho(struct irs_acc *this)
- *
- * Notes:
- *
- *	Initializes the irp_ho module.
- *
- */
-
-struct irs_ho *
-irs_irp_ho(struct irs_acc *this) {
-	struct irs_ho *ho;
-	struct pvt *pvt;
-
-	if (!(ho = memget(sizeof *ho))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(ho, 0x0, sizeof *ho);
-
-	if (!(pvt = memget(sizeof *pvt))) {
-		memput(ho, sizeof *ho);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	pvt->girpdata = this->private;
-
-	ho->private = pvt;
-	ho->close = ho_close;
-	ho->byname = ho_byname;
-	ho->byname2 = ho_byname2;
-	ho->byaddr = ho_byaddr;
-	ho->next = ho_next;
-	ho->rewind = ho_rewind;
-	ho->minimize = ho_minimize;
-	ho->addrinfo = ho_addrinfo;
-
-	return (ho);
-}
-
-/* Methods. */
-
-/*%
- *	Closes down the module.
- *
- */
-
-static void
-ho_close(struct irs_ho *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	ho_minimize(this);
-
-	free_host(&pvt->host);
-
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-
-
-/*
- * struct hostent * ho_byname(struct irs_ho *this, const char *name)
- *
- */
-
-static struct hostent *
-ho_byname(struct irs_ho *this, const char *name) {
-	return (ho_byname2(this, name, AF_INET));
-}
-
-
-
-
-
-/*
- * struct hostent * ho_byname2(struct irs_ho *this, const char *name, int af)
- *
- */
-
-static struct hostent *
-ho_byname2(struct irs_ho *this, const char *name, int af) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct hostent *ho = &pvt->host;
-	char *body = NULL;
-	size_t bodylen;
-	int code;
-	char text[256];
-
-	if (ho->h_name != NULL &&
-	    strcmp(name, ho->h_name) == 0 &&
-	    af == ho->h_addrtype) {
-		return (ho);
-	}
-
-	if (irs_irp_connection_setup(pvt->girpdata, &pvt->warned) != 0) {
-		return (NULL);
-	}
-
-	if (irs_irp_send_command(pvt->girpdata, "gethostbyname2 %s %s",
-				 name, ADDR_T_STR(af)) != 0)
-		return (NULL);
-
-	if (irs_irp_get_full_response(pvt->girpdata, &code,
-				      text, sizeof text,
-				      &body, &bodylen) != 0) {
-		return (NULL);
-	}
-
-	if (code == IRPD_GETHOST_OK) {
-		free_host(ho);
-		if (irp_unmarshall_ho(ho, body) != 0) {
-			ho = NULL;
-		}
-	} else {
-		ho = NULL;
-	}
-
-	if (body != NULL) {
-		memput(body, bodylen);
-	}
-
-	return (ho);
-}
-
-
-
-/*
- * struct hostent * ho_byaddr(struct irs_ho *this, const void *addr,
- *			   int len, int af)
- *
- */
-
-static struct hostent *
-ho_byaddr(struct irs_ho *this, const void *addr, int len, int af) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct hostent *ho = &pvt->host;
-	char *body = NULL;
-	size_t bodylen;
-	int code;
-	char **p;
-	char paddr[MAXPADDRSIZE];
-	char text[256];
-
-	if (ho->h_name != NULL &&
-	    af == ho->h_addrtype &&
-	    len == ho->h_length) {
-		for (p = ho->h_addr_list ; *p != NULL ; p++) {
-			if (memcmp(*p, addr, len) == 0)
-				return (ho);
-		}
-	}
-
-	if (irs_irp_connection_setup(pvt->girpdata, &pvt->warned) != 0) {
-		return (NULL);
-	}
-
-	if (inet_ntop(af, addr, paddr, sizeof paddr) == NULL) {
-		return (NULL);
-	}
-
-	if (irs_irp_send_command(pvt->girpdata, "gethostbyaddr %s %s",
-				 paddr, ADDR_T_STR(af)) != 0) {
-		return (NULL);
-	}
-
-	if (irs_irp_get_full_response(pvt->girpdata, &code,
-				      text, sizeof text,
-				      &body, &bodylen) != 0) {
-		return (NULL);
-	}
-
-	if (code == IRPD_GETHOST_OK) {
-		free_host(ho);
-		if (irp_unmarshall_ho(ho, body) != 0) {
-			ho = NULL;
-		}
-	} else {
-		ho = NULL;
-	}
-
-	if (body != NULL) {
-		memput(body, bodylen);
-	}
-
-	return (ho);
-}
-
-/*%
- *	The implementation for gethostent(3). The first time it's
- *	called all the data is pulled from the remote(i.e. what
- *	the maximum number of gethostent(3) calls would return)
- *	and that data is cached.
- *
- */
-
-static struct hostent *
-ho_next(struct irs_ho *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct hostent *ho = &pvt->host;
-	char *body;
-	size_t bodylen;
-	int code;
-	char text[256];
-
-	if (irs_irp_connection_setup(pvt->girpdata, &pvt->warned) != 0) {
-		return (NULL);
-	}
-
-	if (irs_irp_send_command(pvt->girpdata, "gethostent") != 0) {
-		return (NULL);
-	}
-
-	if (irs_irp_get_full_response(pvt->girpdata, &code,
-				      text, sizeof text,
-				      &body, &bodylen) != 0) {
-		return (NULL);
-	}
-
-	if (code == IRPD_GETHOST_OK) {
-		free_host(ho);
-		if (irp_unmarshall_ho(ho, body) != 0) {
-			ho = NULL;
-		}
-	} else {
-		ho = NULL;
-	}
-
-	if (body != NULL) {
-		memput(body, bodylen);
-	}
-
-	return (ho);
-}
-
-/*%
- * void ho_rewind(struct irs_ho *this)
- *
- */
-
-static void
-ho_rewind(struct irs_ho *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	char text[256];
-	int code;
-
-	if (irs_irp_connection_setup(pvt->girpdata, &pvt->warned) != 0) {
-		return;
-	}
-
-	if (irs_irp_send_command(pvt->girpdata, "sethostent") != 0) {
-		return;
-	}
-
-	code = irs_irp_read_response(pvt->girpdata, text, sizeof text);
-	if (code != IRPD_GETHOST_SETOK) {
-		if (irp_log_errors) {
-			syslog(LOG_WARNING, "sethostent failed: %s", text);
-		}
-	}
-
-	return;
-}
-
-/*%
- * void ho_minimize(struct irs_ho *this)
- *
- */
-
-static void
-ho_minimize(struct irs_ho *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	free_host(&pvt->host);
-
-	irs_irp_disconnect(pvt->girpdata);
-}
-
-/*%
- * void free_host(struct hostent *ho)
- *
- */
-
-static void
-free_host(struct hostent *ho) {
-	char **p;
-
-	if (ho == NULL) {
-		return;
-	}
-
-	if (ho->h_name != NULL)
-		free(ho->h_name);
-
-	if (ho->h_aliases != NULL) {
-		for (p = ho->h_aliases ; *p != NULL ; p++)
-			free(*p);
-		free(ho->h_aliases);
-	}
-
-	if (ho->h_addr_list != NULL) {
-		for (p = ho->h_addr_list ; *p != NULL ; p++)
-			free(*p);
-		free(ho->h_addr_list);
-	}
-}
-
-/* dummy */
-static struct addrinfo *
-ho_addrinfo(struct irs_ho *this, const char *name, const struct addrinfo *pai)
-{
-	UNUSED(this);
-	UNUSED(name);
-	UNUSED(pai);
-	return(NULL);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/irp_ng.c b/contrib/bind9/lib/bind/irs/irp_ng.c
deleted file mode 100644
index e0aa468..0000000
--- a/contrib/bind9/lib/bind/irs/irp_ng.c
+++ /dev/null
@@ -1,253 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996, 1998 by 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.
- */
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: irp_ng.c,v 1.2.18.2 2006/12/07 04:53:02 marka Exp $";
-#endif
-
-/* Imports */
-
-#include "port_before.h"
-
-#include <errno.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <unistd.h>
-#include <syslog.h>
-
-#include <irs.h>
-#include <irp.h>
-#include <isc/memcluster.h>
-#include <isc/irpmarshall.h>
-
-#include "irs_p.h"
-#include "irp_p.h"
-
-#include "port_after.h"
-
-/* Definitions */
-
-struct pvt {
-	struct irp_p	       *girpdata;
-	int			warned;
-};
-
-
-/* Forward */
-
-static void		ng_rewind(struct irs_ng *, const char*);
-static void		ng_close(struct irs_ng *);
-static int		ng_next(struct irs_ng *, const char **, const char **,
-				const char **);
-static int		ng_test(struct irs_ng *, const char *,
-				const char *, const char *,
-				const char *);
-static void		ng_minimize(struct irs_ng *);
-
-
-/* Public */
-
-/*%
- *	Intialize the irp netgroup module.
- *
- */
-
-struct irs_ng *
-irs_irp_ng(struct irs_acc *this) {
-	struct irs_ng *ng;
-	struct pvt *pvt;
-
-	if (!(ng = memget(sizeof *ng))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(ng, 0x5e, sizeof *ng);
-
-	if (!(pvt = memget(sizeof *pvt))) {
-		memput(ng, sizeof *ng);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	pvt->girpdata = this->private;
-
-	ng->private = pvt;
-	ng->close = ng_close;
-	ng->next = ng_next;
-	ng->test = ng_test;
-	ng->rewind = ng_rewind;
-	ng->minimize = ng_minimize;
-	return (ng);
-}
-
-/* Methods */
-
-
-
-/*
- * void ng_close(struct irs_ng *this)
- *
- */
-
-static void
-ng_close(struct irs_ng *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	ng_minimize(this);
-
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-
-
-
-/*
- * void ng_rewind(struct irs_ng *this, const char *group)
- *
- *
- */
-
-static void
-ng_rewind(struct irs_ng *this, const char *group) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	char text[256];
-	int code;
-
-	if (irs_irp_connection_setup(pvt->girpdata, &pvt->warned) != 0) {
-		return;
-	}
-
-	if (irs_irp_send_command(pvt->girpdata,
-				 "setnetgrent %s", group) != 0) {
-		return;
-	}
-
-	code = irs_irp_read_response(pvt->girpdata, text, sizeof text);
-	if (code != IRPD_GETNETGR_SETOK) {
-		if (irp_log_errors) {
-			syslog(LOG_WARNING, "setnetgrent(%s) failed: %s",
-			       group, text);
-		}
-	}
-
-	return;
-}
-
-/*
- *	Get the next netgroup item from the cache.
- *
- */
-
-static int
-ng_next(struct irs_ng *this, const char **host, const char **user,
-        const char **domain)
-{
-	struct pvt *pvt = (struct pvt *)this->private;
-	int code;
-	char *body = NULL;
-	size_t bodylen;
-	int rval = 0;
-	char text[256];
-
-	if (irs_irp_connection_setup(pvt->girpdata, &pvt->warned) != 0) {
-		return (0);
-	}
-
-	if (irs_irp_send_command(pvt->girpdata, "getnetgrent") != 0)
-		return (0);
-
-	if (irs_irp_get_full_response(pvt->girpdata, &code,
-				      text, sizeof text,
-				      &body, &bodylen) != 0) {
-		return (0);
-	}
-
-	if (code == IRPD_GETNETGR_OK) {
-		if (irp_unmarshall_ng(host, user, domain, body) == 0) {
-			rval = 1;
-		}
-	}
-
-	if (body != NULL) {
-		memput(body, bodylen);
-	}
-
-	return (rval);
-}
-
-/*
- *	Search for a match in a netgroup.
- *
- */
-
-static int
-ng_test(struct irs_ng *this, const char *name,
-	const char *host, const char *user, const char *domain)
-{
-	struct pvt *pvt = (struct pvt *)this->private;
-	char *body = NULL;
-	size_t bodylen = 0;
-	int code;
-	char text[256];
-	int rval = 0;
-
-	UNUSED(name);
-
-	if (irs_irp_connection_setup(pvt->girpdata, &pvt->warned) != 0) {
-		return (0);
-	}
-
-	if (irp_marshall_ng(host, user, domain, &body, &bodylen) != 0) {
-		return (0);
-	}
-
-	if (irs_irp_send_command(pvt->girpdata, "innetgr %s", body) == 0) {
-		code = irs_irp_read_response(pvt->girpdata, text, sizeof text);
-		if (code == IRPD_GETNETGR_MATCHES) {
-			rval = 1;
-		}
-	}
-
-	memput(body, bodylen);
-
-	return (rval);
-}
-
-
-
-
-/*
- * void ng_minimize(struct irs_ng *this)
- *
- */
-
-static void
-ng_minimize(struct irs_ng *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	irs_irp_disconnect(pvt->girpdata);
-}
-
-
-
-
-/* Private */
-
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/irp_nw.c b/contrib/bind9/lib/bind/irs/irp_nw.c
deleted file mode 100644
index b285120..0000000
--- a/contrib/bind9/lib/bind/irs/irp_nw.c
+++ /dev/null
@@ -1,348 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Portions Copyright (c) 1996,1998 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: irp_nw.c,v 1.2.18.2 2006/03/10 00:20:08 marka Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-#if 0
-
-#endif
-
-/* Imports */
-
-#include "port_before.h"
-
-#include <syslog.h>
-#include <sys/types.h>
-#include <sys/socket.h>
-
-#include <netinet/in.h>
-#include <arpa/inet.h>
-#include <arpa/nameser.h>
-
-#include <errno.h>
-#include <fcntl.h>
-#include <resolv.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <syslog.h>
-
-#include <irs.h>
-#include <irp.h>
-#include <isc/irpmarshall.h>
-
-#include <isc/memcluster.h>
-#include <isc/misc.h>
-
-#include "irs_p.h"
-#include "lcl_p.h"
-#include "irp_p.h"
-
-#include "port_after.h"
-
-#define MAXALIASES 35
-#define MAXADDRSIZE 4
-
-struct pvt {
-	struct irp_p	       *girpdata;
-	int			warned;
-	struct nwent		net;
-};
-
-/* Forward */
-
-static void		nw_close(struct irs_nw *);
-static struct nwent *	nw_byname(struct irs_nw *, const char *, int);
-static struct nwent *	nw_byaddr(struct irs_nw *, void *, int, int);
-static struct nwent *	nw_next(struct irs_nw *);
-static void		nw_rewind(struct irs_nw *);
-static void		nw_minimize(struct irs_nw *);
-
-static void		free_nw(struct nwent *nw);
-
-
-/* Public */
-
-/*%
- * struct irs_nw * irs_irp_nw(struct irs_acc *this) 
- *
- */
-
-struct irs_nw *
-irs_irp_nw(struct irs_acc *this) {
-	struct irs_nw *nw;
-	struct pvt *pvt;
-
-	if (!(pvt = memget(sizeof *pvt))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-
-	if (!(nw = memget(sizeof *nw))) {
-		memput(pvt, sizeof *pvt);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(nw, 0x0, sizeof *nw);
-	pvt->girpdata = this->private;
-
-	nw->private = pvt;
-	nw->close = nw_close;
-	nw->byname = nw_byname;
-	nw->byaddr = nw_byaddr;
-	nw->next = nw_next;
-	nw->rewind = nw_rewind;
-	nw->minimize = nw_minimize;
-	return (nw);
-}
-
-/* Methods */
-
-/*%
- * void nw_close(struct irs_nw *this) 
- *
- */
-
-static void
-nw_close(struct irs_nw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	nw_minimize(this);
-
-	free_nw(&pvt->net);
-
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-/*%
- * struct nwent * nw_byaddr(struct irs_nw *this, void *net, 
- * 				int length, int type) 
- *
- */
-
-static struct nwent *
-nw_byaddr(struct irs_nw *this, void *net, int length, int type) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct nwent *nw = &pvt->net;
-	char *body = NULL;
-	size_t bodylen;
-	int code;
-	char paddr[24];			/*%< bigenough for ip4 w/ cidr spec. */
-	char text[256];
-
-	if (inet_net_ntop(type, net, length, paddr, sizeof paddr) == NULL) {
-		return (NULL);
-	}
-
-	if (irs_irp_connection_setup(pvt->girpdata, &pvt->warned) != 0) {
-		return (NULL);
-	}
-
-	if (irs_irp_send_command(pvt->girpdata, "getnetbyaddr %s %s",
-				 paddr, ADDR_T_STR(type)) != 0)
-		return (NULL);
-
-	if (irs_irp_get_full_response(pvt->girpdata, &code,
-				      text, sizeof text,
-				      &body, &bodylen) != 0) {
-		return (NULL);
-	}
-
-	if (code == IRPD_GETNET_OK) {
-		free_nw(nw);
-		if (irp_unmarshall_nw(nw, body) != 0) {
-			nw = NULL;
-		}
-	} else {
-		nw = NULL;
-	}
-		
-	if (body != NULL) {
-		memput(body, bodylen);
-	}
-	
-	return (nw);
-}
-
-/*%
- * struct nwent * nw_byname(struct irs_nw *this, const char *name, int type) 
- *
- */
-
-static struct nwent *
-nw_byname(struct irs_nw *this, const char *name, int type) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct nwent *nw = &pvt->net;
-	char *body = NULL;
-	size_t bodylen;
-	int code;
-	char text[256];
-
-	if (nw->n_name != NULL &&
-	    strcmp(name, nw->n_name) == 0 &&
-	    nw->n_addrtype == type) {
-		return (nw);
-	}
-
-	if (irs_irp_connection_setup(pvt->girpdata, &pvt->warned) != 0) {
-		return (NULL);
-	}
-
-	if (irs_irp_send_command(pvt->girpdata, "getnetbyname %s", name) != 0)
-		return (NULL);
-
-	if (irs_irp_get_full_response(pvt->girpdata, &code,
-				      text, sizeof text,
-				      &body, &bodylen) != 0) {
-		return (NULL);
-	}
-
-	if (code == IRPD_GETNET_OK) {
-		free_nw(nw);
-		if (irp_unmarshall_nw(nw, body) != 0) {
-			nw = NULL;
-		}
-	} else {
-		nw = NULL;
-	}
-	
-	if (body != NULL) {
-		memput(body, bodylen);
-	}
-	
-	return (nw);
-}
-
-/*%
- * void nw_rewind(struct irs_nw *this) 
- *
- */
-
-static void
-nw_rewind(struct irs_nw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	char text[256];
-	int code;
-
-	if (irs_irp_connection_setup(pvt->girpdata, &pvt->warned) != 0) {
-		return;
-	}
-
-	if (irs_irp_send_command(pvt->girpdata, "setnetent") != 0) {
-		return;
-	}
-
-	code = irs_irp_read_response(pvt->girpdata, text, sizeof text);
-	if (code != IRPD_GETNET_SETOK) {
-		if (irp_log_errors) {
-			syslog(LOG_WARNING, "setnetent failed: %s", text);
-		}
-	}
-	
-	return;
-}
-
-/*%
- * 	Prepares the cache if necessary and returns the first, or 
- * 	next item from it.
- */
-
-static struct nwent *
-nw_next(struct irs_nw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct nwent *nw = &pvt->net;
-	char *body;
-	size_t bodylen;
-	int code;
-	char text[256];
-
-	if (irs_irp_connection_setup(pvt->girpdata, &pvt->warned) != 0) {
-		return (NULL);
-	}
-
-	if (irs_irp_send_command(pvt->girpdata, "getnetent") != 0) {
-		return (NULL);
-	}
-
-	if (irs_irp_get_full_response(pvt->girpdata, &code,
-				      text, sizeof text,
-				      &body, &bodylen) != 0) {
-		return (NULL);
-	}
-
-	if (code == IRPD_GETNET_OK) {
-		free_nw(nw);
-		if (irp_unmarshall_nw(nw, body) != 0) {
-			nw = NULL;
-		}
-	} else {
-		nw = NULL;
-	}
-
-	if (body != NULL)
-		memput(body, bodylen);
-	return (nw);
-}
-
-/*%
- * void nw_minimize(struct irs_nw *this) 
- *
- */
-
-static void
-nw_minimize(struct irs_nw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	irs_irp_disconnect(pvt->girpdata);
-}
-
-
-
-
-/* private. */
-
-/*%
- *	deallocate all the memory irp_unmarshall_pw allocated.
- *
- */
-
-static void
-free_nw(struct nwent *nw) {
-	char **p;
-
-	if (nw == NULL)
-		return;
-
-	if (nw->n_name != NULL)
-		free(nw->n_name);
-
-	if (nw->n_aliases != NULL) {
-		for (p = nw->n_aliases ; *p != NULL ; p++) {
-			free(*p);
-		}
-		free(nw->n_aliases);
-	}
-
-	if (nw->n_addr != NULL)
-		free(nw->n_addr);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/irp_p.h b/contrib/bind9/lib/bind/irs/irp_p.h
deleted file mode 100644
index 21d31cc..0000000
--- a/contrib/bind9/lib/bind/irs/irp_p.h
+++ /dev/null
@@ -1,60 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996 by 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: irp_p.h,v 1.4.18.1 2005/04/27 05:01:00 sra Exp $
- */
-
-#ifndef _IRP_P_H_INCLUDED
-#define _IRP_P_H_INCLUDED
-
-#include <stdio.h>
-
-struct irp_p {
-	char inbuffer[1024];
-	int inlast; /*%< index of one past the last char in buffer */
-	int incurr; /*%< index of the next char to be read from buffer */
-	int fdCxn;
-};
-
-/*
- * Externs.
- */
-
-extern struct irs_acc *	irs_irp_acc __P((const char *));
-extern struct irs_gr *	irs_irp_gr __P((struct irs_acc *));
-extern struct irs_pw *	irs_irp_pw __P((struct irs_acc *));
-extern struct irs_sv *	irs_irp_sv __P((struct irs_acc *));
-extern struct irs_pr *	irs_irp_pr __P((struct irs_acc *));
-extern struct irs_ho *	irs_irp_ho __P((struct irs_acc *));
-extern struct irs_nw *	irs_irp_nw __P((struct irs_acc *));
-extern struct irs_ng *	irs_irp_ng __P((struct irs_acc *));
-
-int irs_irp_connect(struct irp_p *pvt);
-int irs_irp_is_connected(struct irp_p *pvt);
-void irs_irp_disconnect(struct irp_p *pvt);
-int irs_irp_read_response(struct irp_p *pvt, char *text, size_t textlen);
-char *irs_irp_read_body(struct irp_p *pvt, size_t *size);
-int irs_irp_get_full_response(struct irp_p *pvt, int *code,
-			      char *text, size_t textlen,
-			      char **body, size_t *bodylen);
-
-extern int irp_log_errors;
-
-#endif
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/irp_pr.c b/contrib/bind9/lib/bind/irs/irp_pr.c
deleted file mode 100644
index 00e69ab..0000000
--- a/contrib/bind9/lib/bind/irs/irp_pr.c
+++ /dev/null
@@ -1,327 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Portions Copyright (c) 1996 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: irp_pr.c,v 1.2.18.1 2005/04/27 05:01:01 sra Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-/* extern */
-
-#include "port_before.h"
-
-#include <syslog.h>
-#include <sys/types.h>
-
-#include <errno.h>
-#include <fcntl.h>
-#include <string.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <netdb.h>
-#include <syslog.h>
-
-#include <irs.h>
-#include <irp.h>
-#include <isc/memcluster.h>
-#include <isc/irpmarshall.h>
-
-#include "irs_p.h"
-#include "lcl_p.h"
-#include "irp_p.h"
-
-#include "port_after.h"
-
-
-#define MAXALIASES	35
-
-/* Types */
-
-struct pvt {
-	struct irp_p	       *girpdata;
-	int			warned;
-	struct protoent		proto;
-};
-
-/* Forward */
-
-static void			pr_close(struct irs_pr *);
-static struct protoent *	pr_next(struct irs_pr *);
-static struct protoent *	pr_byname(struct irs_pr *, const char *);
-static struct protoent *	pr_bynumber(struct irs_pr *, int);
-static void			pr_rewind(struct irs_pr *);
-static void			pr_minimize(struct irs_pr *);
-
-static void			free_proto(struct protoent *pr);
-
-/* Public */
-
-/*%
- * struct irs_pr * irs_irp_pr(struct irs_acc *this)
- *
- */
-
-struct irs_pr *
-irs_irp_pr(struct irs_acc *this) {
-	struct irs_pr *pr;
-	struct pvt *pvt;
-
-	if (!(pr = memget(sizeof *pr))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pr, 0x0, sizeof *pr);
-
-	if (!(pvt = memget(sizeof *pvt))) {
-		memput(pr, sizeof *pr);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	pvt->girpdata = this->private;
-
-	pr->private = pvt;
-	pr->close = pr_close;
-	pr->byname = pr_byname;
-	pr->bynumber = pr_bynumber;
-	pr->next = pr_next;
-	pr->rewind = pr_rewind;
-	pr->minimize = pr_minimize;
-	return (pr);
-}
-
-/* Methods */
-
-/*%
- * void pr_close(struct irs_pr *this)
- *
- */
-
-static void
-pr_close(struct irs_pr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	pr_minimize(this);
-
-	free_proto(&pvt->proto);
-
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-/*%
- * struct protoent * pr_byname(struct irs_pr *this, const char *name)
- *
- */
-
-static struct protoent *
-pr_byname(struct irs_pr *this, const char *name) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct protoent *pr = &pvt->proto;
-	char *body = NULL;
-	size_t bodylen;
-	int code;
-	int i;
-	char text[256];
-
-	if (pr->p_name != NULL && strcmp(name, pr->p_name) == 0) {
-		return (pr);
-	}
-
-	if (irs_irp_connection_setup(pvt->girpdata, &pvt->warned) != 0) {
-		return (NULL);
-	}
-
-	i = irs_irp_send_command(pvt->girpdata, "getprotobyname %s", name);
-	if (i != 0)
-		return (NULL);
-
-	if (irs_irp_get_full_response(pvt->girpdata, &code,
-				      text, sizeof text,
-				      &body, &bodylen) != 0) {
-		return (NULL);
-	}
-
-	if (code == IRPD_GETPROTO_OK) {
-		free_proto(pr);
-		if (irp_unmarshall_pr(pr, body) != 0) {
-			pr = NULL;
-		}
-	} else {
-		pr = NULL;
-	}
-
-	if (body != NULL) {
-		memput(body, bodylen);
-	}
-
-	return (pr);
-}
-
-/*%
- * struct protoent * pr_bynumber(struct irs_pr *this, int proto)
- *
- */
-
-static struct protoent *
-pr_bynumber(struct irs_pr *this, int proto) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct protoent *pr = &pvt->proto;
-	char *body = NULL;
-	size_t bodylen;
-	int code;
-	int i;
-	char text[256];
-
-	if (pr->p_name != NULL && proto == pr->p_proto) {
-		return (pr);
-	}
-
-	if (irs_irp_connection_setup(pvt->girpdata, &pvt->warned) != 0) {
-		return (NULL);
-	}
-
-	i = irs_irp_send_command(pvt->girpdata, "getprotobynumber %d", proto);
-	if (i != 0)
-		return (NULL);
-
-	if (irs_irp_get_full_response(pvt->girpdata, &code,
-				      text, sizeof text,
-				      &body, &bodylen) != 0) {
-		return (NULL);
-	}
-
-	if (code == IRPD_GETPROTO_OK) {
-		free_proto(pr);
-		if (irp_unmarshall_pr(pr, body) != 0) {
-			pr = NULL;
-		}
-	} else {
-		pr = NULL;
-	}
-
-	if (body != NULL) {
-		memput(body, bodylen);
-	}
-
-	return (pr);
-}
-
-/*%
- * void pr_rewind(struct irs_pr *this)
- *
- */
-
-static void
-pr_rewind(struct irs_pr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	char text[256];
-	int code;
-
-	if (irs_irp_connection_setup(pvt->girpdata, &pvt->warned) != 0) {
-		return;
-	}
-
-	if (irs_irp_send_command(pvt->girpdata, "setprotoent") != 0) {
-		return;
-	}
-
-	code = irs_irp_read_response(pvt->girpdata, text, sizeof text);
-	if (code != IRPD_GETPROTO_SETOK) {
-		if (irp_log_errors) {
-			syslog(LOG_WARNING, "setprotoent failed: %s", text);
-		}
-	}
-
-	return;
-}
-
-/*%
- *	Prepares the cache if necessary and returns the next item in it.
- *
- */
-
-static struct protoent *
-pr_next(struct irs_pr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct protoent *pr = &pvt->proto;
-	char *body;
-	size_t bodylen;
-	int code;
-	char text[256];
-
-	if (irs_irp_connection_setup(pvt->girpdata, &pvt->warned) != 0) {
-		return (NULL);
-	}
-
-	if (irs_irp_send_command(pvt->girpdata, "getprotoent") != 0) {
-		return (NULL);
-	}
-
-	if (irs_irp_get_full_response(pvt->girpdata, &code,
-				      text, sizeof text,
-				      &body, &bodylen) != 0) {
-		return (NULL);
-	}
-
-	if (code == IRPD_GETPROTO_OK) {
-		free_proto(pr);
-		if (irp_unmarshall_pr(pr, body) != 0) {
-			pr = NULL;
-		}
-	} else {
-		pr = NULL;
-	}
-
-	if (body != NULL) {
-		memput(body, bodylen);
-	}
-
-	return (pr);
-}
-
-/*%
- * void pr_minimize(struct irs_pr *this)
- *
- */
-
-static void
-pr_minimize(struct irs_pr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	irs_irp_disconnect(pvt->girpdata);
-}
-
-/*%
- *	Deallocate all the memory irp_unmarshall_pr allocated.
- *
- */
-
-static void
-free_proto(struct protoent *pr) {
-	char **p;
-
-	if (pr == NULL)
-		return;
-
-	if (pr->p_name != NULL)
-		free(pr->p_name);
-
-	for (p = pr->p_aliases ; p != NULL && *p != NULL ; p++)
-		free(*p);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/irp_pw.c b/contrib/bind9/lib/bind/irs/irp_pw.c
deleted file mode 100644
index a326375..0000000
--- a/contrib/bind9/lib/bind/irs/irp_pw.c
+++ /dev/null
@@ -1,340 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Portions Copyright (c) 1996 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: irp_pw.c,v 1.3.18.1 2005/04/27 05:01:01 sra Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-/* Extern */
-
-#include "port_before.h"
-
-#ifndef WANT_IRS_PW
-static int __bind_irs_pw_unneeded;
-#else
-
-#include <syslog.h>
-#include <sys/param.h>
-
-#include <db.h>
-#include <errno.h>
-#include <fcntl.h>
-#include <limits.h>
-#include <pwd.h>
-#include <stdlib.h>
-#include <string.h>
-#include <syslog.h>
-#include <utmp.h>
-#include <unistd.h>
-
-#include <irs.h>
-#include <irp.h>
-#include <isc/memcluster.h>
-#include <isc/irpmarshall.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "irp_p.h"
-
-
-/* Types */
-
-struct	pvt {
-	struct irp_p   *girpdata; /*%< global IRP data */
-	int		warned;
-	struct passwd	passwd;		/*%< password structure */
-};
-
-/* Forward */
-
-static void			pw_close(struct irs_pw *);
-static struct passwd *		pw_next(struct irs_pw *);
-static struct passwd *		pw_byname(struct irs_pw *, const char *);
-static struct passwd *		pw_byuid(struct irs_pw *, uid_t);
-static void			pw_rewind(struct irs_pw *);
-static void			pw_minimize(struct irs_pw *);
-
-static void			free_passwd(struct passwd *pw);
-
-/* Public */
-struct irs_pw *
-irs_irp_pw(struct irs_acc *this) {
-	struct irs_pw *pw;
-	struct pvt *pvt;
-
-	if (!(pw = memget(sizeof *pw))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pw, 0, sizeof *pw);
-
-	if (!(pvt = memget(sizeof *pvt))) {
-		memput(pw, sizeof *pw);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	pvt->girpdata = this->private;
-
-	pw->private = pvt;
-	pw->close = pw_close;
-	pw->next = pw_next;
-	pw->byname = pw_byname;
-	pw->byuid = pw_byuid;
-	pw->rewind = pw_rewind;
-	pw->minimize = pw_minimize;
-
-	return (pw);
-}
-
-/* Methods */
-
-/*%
- * void pw_close(struct irs_pw *this)
- *
- */
-
-static void
-pw_close(struct irs_pw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	pw_minimize(this);
-
-	free_passwd(&pvt->passwd);
-
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-/*%
- * struct passwd * pw_next(struct irs_pw *this)
- *
- */
-
-static struct passwd *
-pw_next(struct irs_pw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct passwd *pw = &pvt->passwd;
-	char *body;
-	size_t bodylen;
-	int code;
-	char text[256];
-
-	if (irs_irp_connection_setup(pvt->girpdata, &pvt->warned) != 0) {
-		return (NULL);
-	}
-
-	if (irs_irp_send_command(pvt->girpdata, "getpwent") != 0) {
-		return (NULL);
-	}
-
-	if (irs_irp_get_full_response(pvt->girpdata, &code,
-				      text, sizeof text,
-				      &body, &bodylen) != 0) {
-		return (NULL);
-	}
-
-	if (code == IRPD_GETUSER_OK) {
-		free_passwd(pw);
-		if (irp_unmarshall_pw(pw, body) != 0) {
-			pw = NULL;
-		}
-	} else {
-		pw = NULL;
-	}
-
-	if (body != NULL) {
-		memput(body, bodylen);
-	}
-
-	return (pw);
-}
-
-/*%
- * struct passwd * pw_byname(struct irs_pw *this, const char *name)
- *
- */
-
-static struct passwd *
-pw_byname(struct irs_pw *this, const char *name) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct passwd *pw = &pvt->passwd;
-	char *body = NULL;
-	char text[256];
-	size_t bodylen;
-	int code;
-
-	if (pw->pw_name != NULL && strcmp(name, pw->pw_name) == 0) {
-		return (pw);
-	}
-
-	if (irs_irp_connection_setup(pvt->girpdata, &pvt->warned) != 0) {
-		return (NULL);
-	}
-
-	if (irs_irp_send_command(pvt->girpdata, "getpwnam %s", name) != 0) {
-		return (NULL);
-	}
-
-	if (irs_irp_get_full_response(pvt->girpdata, &code,
-				      text, sizeof text,
-				      &body, &bodylen) != 0) {
-		return (NULL);
-	}
-
-	if (code == IRPD_GETUSER_OK) {
-		free_passwd(pw);
-		if (irp_unmarshall_pw(pw, body) != 0) {
-			pw = NULL;
-		}
-	} else {
-		pw = NULL;
-	}
-
-	if (body != NULL) {
-		memput(body, bodylen);
-	}
-
-	return (pw);
-}
-
-/*%
- * struct passwd * pw_byuid(struct irs_pw *this, uid_t uid)
- *
- */
-
-static struct passwd *
-pw_byuid(struct irs_pw *this, uid_t uid) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	char *body;
-	char text[256];
-	size_t bodylen;
-	int code;
-	struct passwd *pw = &pvt->passwd;
-
-	if (pw->pw_name != NULL && pw->pw_uid == uid) {
-		return (pw);
-	}
-
-	if (irs_irp_connection_setup(pvt->girpdata, &pvt->warned) != 0) {
-		return (NULL);
-	}
-
-	if (irs_irp_send_command(pvt->girpdata, "getpwuid %d", uid) != 0) {
-		return (NULL);
-	}
-
-	if (irs_irp_get_full_response(pvt->girpdata, &code,
-				      text, sizeof text,
-				      &body, &bodylen) != 0) {
-		return (NULL);
-	}
-
-	if (code == IRPD_GETUSER_OK) {
-		free_passwd(pw);
-		if (irp_unmarshall_pw(pw, body) != 0) {
-			pw = NULL;
-		}
-	} else {
-		pw = NULL;
-	}
-
-	if (body != NULL) {
-		memput(body, bodylen);
-	}
-
-	return (pw);
-}
-
-/*%
- * void pw_rewind(struct irs_pw *this)
- *
- */
-
-static void
-pw_rewind(struct irs_pw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	char text[256];
-	int code;
-
-	if (irs_irp_connection_setup(pvt->girpdata, &pvt->warned) != 0) {
-		return;
-	}
-
-	if (irs_irp_send_command(pvt->girpdata, "setpwent") != 0) {
-		return;
-	}
-
-	code = irs_irp_read_response(pvt->girpdata, text, sizeof text);
-	if (code != IRPD_GETUSER_SETOK) {
-		if (irp_log_errors) {
-			syslog(LOG_WARNING, "setpwent failed: %s", text);
-		}
-	}
-
-	return;
-}
-
-/*%
- * void pw_minimize(struct irs_pw *this)
- *
- */
-
-static void
-pw_minimize(struct irs_pw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	irs_irp_disconnect(pvt->girpdata);
-}
-
-
-/* Private. */
-
-/*%
- *	Deallocate all the memory irp_unmarshall_pw allocated.
- *
- */
-
-static void
-free_passwd(struct passwd *pw) {
-	if (pw == NULL)
-		return;
-
-	if (pw->pw_name != NULL)
-		free(pw->pw_name);
-
-	if (pw->pw_passwd != NULL)
-		free(pw->pw_passwd);
-
-#ifdef HAVE_PW_CLASS
-	if (pw->pw_class != NULL)
-		free(pw->pw_class);
-#endif
-
-	if (pw->pw_gecos != NULL)
-		free(pw->pw_gecos);
-
-	if (pw->pw_dir != NULL)
-		free(pw->pw_dir);
-
-	if (pw->pw_shell != NULL)
-		free(pw->pw_shell);
-}
-
-#endif /* WANT_IRS_PW */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/irp_sv.c b/contrib/bind9/lib/bind/irs/irp_sv.c
deleted file mode 100644
index 22ea980..0000000
--- a/contrib/bind9/lib/bind/irs/irp_sv.c
+++ /dev/null
@@ -1,346 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Portions Copyright (c) 1996,1998 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: irp_sv.c,v 1.2.18.1 2005/04/27 05:01:01 sra Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-/* extern */
-
-#include "port_before.h"
-
-#include <syslog.h>
-#include <sys/types.h>
-#include <sys/socket.h>
-
-#ifdef IRS_LCL_SV_DB
-#include <db.h>
-#endif
-#include <errno.h>
-#include <fcntl.h>
-#include <limits.h>
-#include <stdio.h>
-#include <string.h>
-#include <stdlib.h>
-#include <syslog.h>
-
-#include <irs.h>
-#include <irp.h>
-#include <isc/irpmarshall.h>
-#include <isc/memcluster.h>
-
-#include "irs_p.h"
-#include "lcl_p.h"
-#include "irp_p.h"
-
-#include "port_after.h"
-
-/* Types */
-
-struct pvt {
-	struct irp_p	       *girpdata;
-	int			warned;
-	struct servent		service;
-};
-
-/* Forward */
-
-static void			sv_close(struct irs_sv*);
-static struct servent *		sv_next(struct irs_sv *);
-static struct servent *		sv_byname(struct irs_sv *, const char *,
-					  const char *);
-static struct servent *		sv_byport(struct irs_sv *, int, const char *);
-static void			sv_rewind(struct irs_sv *);
-static void			sv_minimize(struct irs_sv *);
-
-static void			free_service(struct servent *sv);
-
-
-
-/* Public */
-
-/*%
- * struct irs_sv * irs_irp_sv(struct irs_acc *this)
- *
- */
-
-struct irs_sv *
-irs_irp_sv(struct irs_acc *this) {
-	struct irs_sv *sv;
-	struct pvt *pvt;
-
-	if ((sv = memget(sizeof *sv)) == NULL) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(sv, 0x0, sizeof *sv);
-
-	if ((pvt = memget(sizeof *pvt)) == NULL) {
-		memput(sv, sizeof *sv);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	pvt->girpdata = this->private;
-
-	sv->private = pvt;
-	sv->close = sv_close;
-	sv->next = sv_next;
-	sv->byname = sv_byname;
-	sv->byport = sv_byport;
-	sv->rewind = sv_rewind;
-	sv->minimize = sv_minimize;
-
-	return (sv);
-}
-
-/* Methods */
-
-/*%
- * void sv_close(struct irs_sv *this)
- *
- */
-
-static void
-sv_close(struct irs_sv *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	sv_minimize(this);
-
-	free_service(&pvt->service);
-
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-/*%
- *	Fills the cache if necessary and returns the next item from it.
- *
- */
-
-static struct servent *
-sv_next(struct irs_sv *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct servent *sv = &pvt->service;
-	char *body;
-	size_t bodylen;
-	int code;
-	char text[256];
-
-	if (irs_irp_connection_setup(pvt->girpdata, &pvt->warned) != 0) {
-		return (NULL);
-	}
-
-	if (irs_irp_send_command(pvt->girpdata, "getservent") != 0) {
-		return (NULL);
-	}
-
-	if (irs_irp_get_full_response(pvt->girpdata, &code,
-				      text, sizeof text,
-				      &body, &bodylen) != 0) {
-		return (NULL);
-	}
-
-	if (code == IRPD_GETSERVICE_OK) {
-		free_service(sv);
-		if (irp_unmarshall_sv(sv, body) != 0) {
-			sv = NULL;
-		}
-	} else {
-		sv = NULL;
-	}
-
-	if (body != NULL) {
-		memput(body, bodylen);
-	}
-
-	return (sv);
-}
-
-/*%
- * struct servent * sv_byname(struct irs_sv *this, const char *name,
- *				const char *proto)
- *
- */
-
-static struct servent *
-sv_byname(struct irs_sv *this, const char *name, const char *proto) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct servent *sv = &pvt->service;
-	char *body;
-	char text[256];
-	size_t bodylen;
-	int code;
-
-	if (sv->s_name != NULL &&
-	    strcmp(name, sv->s_name) == 0 &&
-	    strcasecmp(proto, sv->s_proto) == 0) {
-		return (sv);
-	}
-
-	if (irs_irp_connection_setup(pvt->girpdata, &pvt->warned) != 0) {
-		return (NULL);
-	}
-
-	if (irs_irp_send_command(pvt->girpdata, "getservbyname %s %s",
-				 name, proto) != 0)
-		return (NULL);
-
-	if (irs_irp_get_full_response(pvt->girpdata, &code,
-				      text, sizeof text,
-				      &body, &bodylen) != 0) {
-		return (NULL);
-	}
-
-	if (code == IRPD_GETSERVICE_OK) {
-		free_service(sv);
-		if (irp_unmarshall_sv(sv, body) != 0) {
-			sv = NULL;
-		}
-	} else {
-		sv = NULL;
-	}
-
-	if (body != NULL) {
-		memput(body, bodylen);
-	}
-
-	return (sv);
-}
-
-/*%
- * struct servent * sv_byport(struct irs_sv *this, int port,
- *				const char *proto)
- *
- */
-
-static struct servent *
-sv_byport(struct irs_sv *this, int port, const char *proto) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct servent *sv = &pvt->service;
-	char *body;
-	size_t bodylen;
-	char text[256];
-	int code;
-
-	if (sv->s_name != NULL &&
-	    port == sv->s_port &&
-	    strcasecmp(proto, sv->s_proto) == 0) {
-		return (sv);
-	}
-
-	if (irs_irp_connection_setup(pvt->girpdata, &pvt->warned) != 0) {
-		return (NULL);
-	}
-
-	if (irs_irp_send_command(pvt->girpdata, "getservbyport %d %s",
-				 ntohs((short)port), proto) != 0) {
-		return (NULL);
-	}
-
-	if (irs_irp_get_full_response(pvt->girpdata, &code,
-				      text, sizeof text,
-				      &body, &bodylen) != 0) {
-		return (NULL);
-	}
-
-	if (code == IRPD_GETSERVICE_OK) {
-		free_service(sv);
-		if (irp_unmarshall_sv(sv, body) != 0) {
-			sv = NULL;
-		}
-	} else {
-		sv = NULL;
-	}
-
-	if (body != NULL) {
-		memput(body, bodylen);
-	}
-
-	return (sv);
-}
-
-/*%
- * void sv_rewind(struct irs_sv *this)
- *
- */
-
-static void
-sv_rewind(struct irs_sv *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	char text[256];
-	int code;
-
-	if (irs_irp_connection_setup(pvt->girpdata, &pvt->warned) != 0) {
-		return;
-	}
-
-	if (irs_irp_send_command(pvt->girpdata, "setservent") != 0) {
-		return;
-	}
-
-	code = irs_irp_read_response(pvt->girpdata, text, sizeof text);
-	if (code != IRPD_GETSERVICE_SETOK) {
-		if (irp_log_errors) {
-			syslog(LOG_WARNING, "setservent failed: %s", text);
-		}
-	}
-
-	return;
-}
-
-/*%
- * void sv_minimize(struct irs_sv *this)
- *
- */
-
-static void
-sv_minimize(struct irs_sv *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	irs_irp_disconnect(pvt->girpdata);
-}
-
-
-
-
-
-
-static void
-free_service(struct servent *sv) {
-	char **p;
-
-	if (sv == NULL) {
-		return;
-	}
-
-	if (sv->s_name != NULL) {
-		free(sv->s_name);
-	}
-
-	for (p = sv->s_aliases ; p != NULL && *p != NULL ; p++) {
-		free(*p);
-	}
-
-	if (sv->s_proto != NULL) {
-		free(sv->s_proto);
-	}
-}
-
-
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/irpmarshall.c b/contrib/bind9/lib/bind/irs/irpmarshall.c
deleted file mode 100644
index 8c34fa2..0000000
--- a/contrib/bind9/lib/bind/irs/irpmarshall.c
+++ /dev/null
@@ -1,2301 +0,0 @@
-/*
- * Copyright(c) 1989, 1993, 1995
- *	The Regents of the University of California.  All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- *	This product includes software developed by the University of
- *	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Portions Copyright (c) 1996 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: irpmarshall.c,v 1.5.18.2 2006/03/10 00:20:08 marka Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-#if 0
-
-Check values are in approrpriate endian order.
-
-Double check memory allocations on unmarhsalling
-
-#endif
-
-
-/* Extern */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/socket.h>
-
-#include <netinet/in.h>
-#include <arpa/inet.h>
-#include <arpa/nameser.h>
-
-#include <stdio.h>
-#include <ctype.h>
-#include <pwd.h>
-#include <stdlib.h>
-#include <string.h>
-#include <syslog.h>
-#include <utmp.h>
-#include <unistd.h>
-#include <assert.h>
-#include <errno.h>
-
-#include <irs.h>
-#include <isc/memcluster.h>
-#include <isc/irpmarshall.h>
-
-#include "port_after.h"
-
-
-#ifndef HAVE_STRNDUP
-static char    *strndup(const char *str, size_t len);
-#endif
-
-static char   **splitarray(const char *buffer, const char *buffend, char delim);
-static int	joinarray(char * const * argv, char *buffer, char delim);
-static char    *getfield(char **res, size_t reslen, char **buffer, char delim);
-static size_t	joinlength(char * const *argv);
-static void	free_array(char **argv, size_t entries);
-
-#define ADDR_T_STR(x) (x == AF_INET ? "AF_INET" :\
-		       (x == AF_INET6 ? "AF_INET6" : "UNKNOWN"))
-
-#define MAXPADDRSIZE (sizeof "255.255.255.255" + 1)
-
-static char COMMA = ',';
-
-static const char *COMMASTR = ",";
-static const char *COLONSTR = ":";
-
-
-
-/* See big comment at bottom of irpmarshall.h for description. */
-
-
-#ifdef WANT_IRS_PW
-/* +++++++++++++++++++++++++ struct passwd +++++++++++++++++++++++++ */
-
-/*%
- * int irp_marshall_pw(const struct passwd *pw, char **buffer, size_t *len)
- *
- * notes: \li
- *
- *	See irpmarshall.h
- *
- * return: \li
- *
- *	0 on sucess, -1 on failure.
- *
- */
-
-int
-irp_marshall_pw(const struct passwd *pw, char **buffer, size_t *len) {
-	size_t need = 1 ;		/*%< for null byte */
-	char pwUid[24];
-	char pwGid[24];
-	char pwChange[24];
-	char pwExpire[24];
-	const char *pwClass;
-	const char *fieldsep = COLONSTR;
-
-	if (pw == NULL || len == NULL) {
-		errno = EINVAL;
-		return (-1);
-	}
-
-	sprintf(pwUid, "%ld", (long)pw->pw_uid);
-	sprintf(pwGid, "%ld", (long)pw->pw_gid);
-
-#ifdef HAVE_PW_CHANGE
-	sprintf(pwChange, "%ld", (long)pw->pw_change);
-#else
-	pwChange[0] = '0';
-	pwChange[1] = '\0';
-#endif
-
-#ifdef HAVE_PW_EXPIRE
-	sprintf(pwExpire, "%ld", (long)pw->pw_expire);
-#else
-	pwExpire[0] = '0';
-	pwExpire[1] = '\0';
-#endif
-
-#ifdef HAVE_PW_CLASS
-	pwClass = pw->pw_class;
-#else
-	pwClass = "";
-#endif
-
-	need += strlen(pw->pw_name)	+ 1; /*%< one for fieldsep */
-	need += strlen(pw->pw_passwd)	+ 1;
-	need += strlen(pwUid)		+ 1;
-	need += strlen(pwGid)		+ 1;
-	need += strlen(pwClass)		+ 1;
-	need += strlen(pwChange)	+ 1;
-	need += strlen(pwExpire)	+ 1;
-	need += strlen(pw->pw_gecos)	+ 1;
-	need += strlen(pw->pw_dir)	+ 1;
-	need += strlen(pw->pw_shell)	+ 1;
-
-	if (buffer == NULL) {
-		*len = need;
-		return (0);
-	}
-
-	if (*buffer != NULL && need > *len) {
-		errno = EINVAL;
-		return (-1);
-	}
-
-	if (*buffer == NULL) {
-		need += 2;		/*%< for CRLF */
-		*buffer = memget(need);
-		if (*buffer == NULL) {
-			errno = ENOMEM;
-			return (-1);
-		}
-
-		*len = need;
-	}
-
-	strcpy(*buffer, pw->pw_name);		strcat(*buffer, fieldsep);
-	strcat(*buffer, pw->pw_passwd);		strcat(*buffer, fieldsep);
-	strcat(*buffer, pwUid);			strcat(*buffer, fieldsep);
-	strcat(*buffer, pwGid);			strcat(*buffer, fieldsep);
-	strcat(*buffer, pwClass);		strcat(*buffer, fieldsep);
-	strcat(*buffer, pwChange);		strcat(*buffer, fieldsep);
-	strcat(*buffer, pwExpire);		strcat(*buffer, fieldsep);
-	strcat(*buffer, pw->pw_gecos);		strcat(*buffer, fieldsep);
-	strcat(*buffer, pw->pw_dir);		strcat(*buffer, fieldsep);
-	strcat(*buffer, pw->pw_shell);		strcat(*buffer, fieldsep);
-
-	return (0);
-}
-
-/*%
- * int irp_unmarshall_pw(struct passwd *pw, char *buffer)
- *
- * notes: \li
- *
- *	See irpmarshall.h
- *
- * return: \li
- *
- *	0 on success, -1 on failure
- *
- */
-
-int
-irp_unmarshall_pw(struct passwd *pw, char *buffer) {
-	char *name, *pass, *class, *gecos, *dir, *shell;
-	uid_t pwuid;
-	gid_t pwgid;
-	time_t pwchange;
-	time_t pwexpire;
-	char *p;
-	long t;
-	char tmpbuf[24];
-	char *tb = &tmpbuf[0];
-	char fieldsep = ':';
-	int myerrno = EINVAL;
-
-	name = pass = class = gecos = dir = shell = NULL;
-	p = buffer;
-
-	/* pw_name field */
-	name = NULL;
-	if (getfield(&name, 0, &p, fieldsep) == NULL || strlen(name) == 0) {
-		goto error;
-	}
-
-	/* pw_passwd field */
-	pass = NULL;
-	if (getfield(&pass, 0, &p, fieldsep) == NULL) { /*%< field can be empty */
-		goto error;
-	}
-
-
-	/* pw_uid field */
-	tb = tmpbuf;
-	if (getfield(&tb, sizeof tmpbuf, &p, fieldsep) == NULL ||
-	    strlen(tb) == 0) {
-		goto error;
-	}
-	t = strtol(tmpbuf, &tb, 10);
-	if (*tb) {
-		goto error;	/*%< junk in value */
-	}
-	pwuid = (uid_t)t;
-	if ((long) pwuid != t) {	/*%< value must have been too big. */
-		goto error;
-	}
-
-
-
-	/* pw_gid field */
-	tb = tmpbuf;
-	if (getfield(&tb, sizeof tmpbuf, &p, fieldsep) == NULL ||
-	    strlen(tb) == 0) {
-		goto error;
-	}
-	t = strtol(tmpbuf, &tb, 10);
-	if (*tb) {
-		goto error;	/*%< junk in value */
-	}
-	pwgid = (gid_t)t;
-	if ((long)pwgid != t) {	/*%< value must have been too big. */
-		goto error;
-	}
-
-
-
-	/* pw_class field */
-	class = NULL;
-	if (getfield(&class, 0, &p, fieldsep) == NULL) {
-		goto error;
-	}
-
-
-
-	/* pw_change field */
-	tb = tmpbuf;
-	if (getfield(&tb, sizeof tmpbuf, &p, fieldsep) == NULL ||
-	    strlen(tb) == 0) {
-		goto error;
-	}
-	t = strtol(tmpbuf, &tb, 10);
-	if (*tb) {
-		goto error;	/*%< junk in value */
-	}
-	pwchange = (time_t)t;
-	if ((long)pwchange != t) {	/*%< value must have been too big. */
-		goto error;
-	}
-
-
-
-	/* pw_expire field */
-	tb = tmpbuf;
-	if (getfield(&tb, sizeof tmpbuf, &p, fieldsep) == NULL ||
-	    strlen(tb) == 0) {
-		goto error;
-	}
-	t = strtol(tmpbuf, &tb, 10);
-	if (*tb) {
-		goto error;	/*%< junk in value */
-	}
-	pwexpire = (time_t)t;
-	if ((long) pwexpire != t) {	/*%< value must have been too big. */
-		goto error;
-	}
-
-
-
-	/* pw_gecos field */
-	gecos = NULL;
-	if (getfield(&gecos, 0, &p, fieldsep) == NULL) {
-		goto error;
-	}
-
-
-
-	/* pw_dir field */
-	dir = NULL;
-	if (getfield(&dir, 0, &p, fieldsep) == NULL) {
-		goto error;
-	}
-
-
-
-	/* pw_shell field */
-	shell = NULL;
-	if (getfield(&shell, 0, &p, fieldsep) == NULL) {
-		goto error;
-	}
-
-
-
-	pw->pw_name = name;
-	pw->pw_passwd = pass;
-	pw->pw_uid = pwuid;
-	pw->pw_gid = pwgid;
-	pw->pw_gecos = gecos;
-	pw->pw_dir = dir;
-	pw->pw_shell = shell;
-
-#ifdef HAVE_PW_CHANGE
-	pw->pw_change = pwchange;
-#endif
-#ifdef HAVE_PW_CLASS
-	pw->pw_class = class;
-#endif
-#ifdef HAVE_PW_EXPIRE
-	pw->pw_expire = pwexpire;
-#endif
-
-	return (0);
-
- error:
-	errno = myerrno;
-
-	if (name != NULL) free(name);
-	if (pass != NULL) free(pass);
-	if (gecos != NULL) free(gecos);
-	if (dir != NULL) free(dir);
-	if (shell != NULL) free(shell);
-
-	return (-1);
-}
-
-/* ------------------------- struct passwd ------------------------- */
-#endif /* WANT_IRS_PW */
-/* +++++++++++++++++++++++++ struct group +++++++++++++++++++++++++ */
-
-/*%
- * int irp_marshall_gr(const struct group *gr, char **buffer, size_t *len)
- *
- * notes: \li
- *
- *	See irpmarshall.h.
- *
- * return: \li
- *
- *	0 on success, -1 on failure
- */
-
-int
-irp_marshall_gr(const struct group *gr, char **buffer, size_t *len) {
-	size_t need = 1;	/*%< for null byte */
-	char grGid[24];
-	const char *fieldsep = COLONSTR;
-
-	if (gr == NULL || len == NULL) {
-		errno = EINVAL;
-		return (-1);
-	}
-
-	sprintf(grGid, "%ld", (long)gr->gr_gid);
-
-	need += strlen(gr->gr_name) + 1;
-#ifndef MISSING_GR_PASSWD
-	need += strlen(gr->gr_passwd) + 1;
-#else
-	need++;
-#endif
-	need += strlen(grGid) + 1;
-	need += joinlength(gr->gr_mem) + 1;
-
-	if (buffer == NULL) {
-		*len = need;
-		return (0);
-	}
-
-	if (*buffer != NULL && need > *len) {
-		errno = EINVAL;
-		return (-1);
-	}
-
-	if (*buffer == NULL) {
-		need += 2;		/*%< for CRLF */
-		*buffer = memget(need);
-		if (*buffer == NULL) {
-			errno = ENOMEM;
-			return (-1);
-		}
-
-		*len = need;
-	}
-
-	strcpy(*buffer, gr->gr_name);		strcat(*buffer, fieldsep);
-#ifndef MISSING_GR_PASSWD
-	strcat(*buffer, gr->gr_passwd);
-#endif
-	strcat(*buffer, fieldsep);
-	strcat(*buffer, grGid);			strcat(*buffer, fieldsep);
-	joinarray(gr->gr_mem, *buffer, COMMA) ;	strcat(*buffer, fieldsep);
-
-	return (0);
-}
-
-/*%
- * int irp_unmarshall_gr(struct group *gr, char *buffer)
- *
- * notes: \li
- *
- *	See irpmarshall.h
- *
- * return: \li
- *
- *	0 on success and -1 on failure.
- *
- */
-
-int
-irp_unmarshall_gr(struct group *gr, char *buffer) {
-	char *p, *q;
-	gid_t grgid;
-	long t;
-	char *name = NULL;
-	char *pass = NULL;
-	char **members = NULL;
-	char tmpbuf[24];
-	char *tb;
-	char fieldsep = ':';
-	int myerrno = EINVAL;
-
-	if (gr == NULL || buffer == NULL) {
-		errno = EINVAL;
-		return (-1);
-	}
-
-	p = buffer;
-
-	/* gr_name field */
-	name = NULL;
-	if (getfield(&name, 0, &p, fieldsep) == NULL || strlen(name) == 0U) {
-		goto error;
-	}
-
-
-	/* gr_passwd field */
-	pass = NULL;
-	if (getfield(&pass, 0, &p, fieldsep) == NULL) {
-		goto error;
-	}
-
-
-	/* gr_gid field */
-	tb = tmpbuf;
-	if (getfield(&tb, sizeof tmpbuf, &p, fieldsep) == NULL ||
-	    strlen(tb) == 0U) {
-		goto error;
-	}
-	t = strtol(tmpbuf, &tb, 10);
-	if (*tb) {
-		goto error;	/*%< junk in value */
-	}
-	grgid = (gid_t)t;
-	if ((long) grgid != t) {	/*%< value must have been too big. */
-		goto error;
-	}
-
-
-	/* gr_mem field. Member names are separated by commas */
-	q = strchr(p, fieldsep);
-	if (q == NULL) {
-		goto error;
-	}
-	members = splitarray(p, q, COMMA);
-	if (members == NULL) {
-		myerrno = errno;
-		goto error;
-	}
-	p = q + 1;
-
-
-	gr->gr_name = name;
-#ifndef MISSING_GR_PASSWD
-	gr->gr_passwd = pass;
-#endif
-	gr->gr_gid = grgid;
-	gr->gr_mem = members;
-
-	return (0);
-
- error:
-	errno = myerrno;
-
-	if (name != NULL) free(name);
-	if (pass != NULL) free(pass);
-
-	return (-1);
-}
-
-
-/* ------------------------- struct group ------------------------- */
-
-
-
-
-/* +++++++++++++++++++++++++ struct servent +++++++++++++++++++++++++ */
-
-/*%
- * int irp_marshall_sv(const struct servent *sv, char **buffer, size_t *len)
- *
- * notes: \li
- *
- *	See irpmarshall.h
- *
- * return: \li
- *
- *	0 on success, -1 on failure.
- *
- */
-
-int
-irp_marshall_sv(const struct servent *sv, char **buffer, size_t *len) {
-	size_t need = 1;	/*%< for null byte */
-	char svPort[24];
-	const char *fieldsep = COLONSTR;
-	short realport;
-
-	if (sv == NULL || len == NULL) {
-		errno = EINVAL;
-		return (-1);
-	}
-
-	/* the int s_port field is actually a short in network order. We
-	   want host order to make the marshalled data look correct */
-	realport = ntohs((short)sv->s_port);
-	sprintf(svPort, "%d", realport);
-
-	need += strlen(sv->s_name) + 1;
-	need += joinlength(sv->s_aliases) + 1;
-	need += strlen(svPort) + 1;
-	need += strlen(sv->s_proto) + 1;
-
-	if (buffer == NULL) {
-		*len = need;
-		return (0);
-	}
-
-	if (*buffer != NULL && need > *len) {
-		errno = EINVAL;
-		return (-1);
-	}
-
-	if (*buffer == NULL) {
-		need += 2;		/*%< for CRLF */
-		*buffer = memget(need);
-		if (*buffer == NULL) {
-			errno = ENOMEM;
-			return (-1);
-		}
-
-		*len = need;
-	}
-
-	strcpy(*buffer, sv->s_name);		strcat(*buffer, fieldsep);
-	joinarray(sv->s_aliases, *buffer, COMMA); strcat(*buffer, fieldsep);
-	strcat(*buffer, svPort);		strcat(*buffer, fieldsep);
-	strcat(*buffer, sv->s_proto);		strcat(*buffer, fieldsep);
-
-	return (0);
-}
-
-/*%
- * int irp_unmarshall_sv(struct servent *sv, char *buffer)
- *
- * notes: \li
- *
- *	See irpmarshall.h
- *
- * return: \li
- *
- *	0 on success, -1 on failure.
- *
- */
-
-int
-irp_unmarshall_sv(struct servent *sv, char *buffer) {
-	char *p, *q;
-	short svport;
-	long t;
-	char *name = NULL;
-	char *proto = NULL;
-	char **aliases = NULL;
-	char tmpbuf[24];
-	char *tb;
-	char fieldsep = ':';
-	int myerrno = EINVAL;
-
-	if (sv == NULL || buffer == NULL)
-		return (-1);
-
-	p = buffer;
-
-
-	/* s_name field */
-	name = NULL;
-	if (getfield(&name, 0, &p, fieldsep) == NULL || strlen(name) == 0U) {
-		goto error;
-	}
-
-
-	/* s_aliases field */
-	q = strchr(p, fieldsep);
-	if (q == NULL) {
-		goto error;
-	}
-	aliases = splitarray(p, q, COMMA);
-	if (aliases == NULL) {
-		myerrno = errno;
-		goto error;
-	}
-	p = q + 1;
-
-
-	/* s_port field */
-	tb = tmpbuf;
-	if (getfield(&tb, sizeof tmpbuf, &p, fieldsep) == NULL ||
-	    strlen(tb) == 0U) {
-		goto error;
-	}
-	t = strtol(tmpbuf, &tb, 10);
-	if (*tb) {
-		goto error;	/*%< junk in value */
-	}
-	svport = (short)t;
-	if ((long) svport != t) {	/*%< value must have been too big. */
-		goto error;
-	}
-	svport = htons(svport);
-
-	/* s_proto field */
-	proto = NULL;
-	if (getfield(&proto, 0, &p, fieldsep) == NULL) {
-		goto error;
-	}
-
-	sv->s_name = name;
-	sv->s_aliases = aliases;
-	sv->s_port = svport;
-	sv->s_proto = proto;
-
-	return (0);
-
- error:
-	errno = myerrno;
-
-	if (name != NULL) free(name);
-	if (proto != NULL) free(proto);
-	free_array(aliases, 0);
-
-	return (-1);
-}
-
-
-/* ------------------------- struct servent ------------------------- */
-
-/* +++++++++++++++++++++++++ struct protoent +++++++++++++++++++++++++ */
-
-/*%
- * int irp_marshall_pr(struct protoent *pr, char **buffer, size_t *len)
- *
- * notes: \li
- *
- *	See irpmarshall.h
- *
- * return: \li
- *
- *	0 on success and -1 on failure.
- *
- */
-
-int
-irp_marshall_pr(struct protoent *pr, char **buffer, size_t *len) {
-	size_t need = 1;	/*%< for null byte */
-	char prProto[24];
-	const char *fieldsep = COLONSTR;
-
-	if (pr == NULL || len == NULL) {
-		errno = EINVAL;
-		return (-1);
-	}
-
-	sprintf(prProto, "%d", (int)pr->p_proto);
-
-	need += strlen(pr->p_name) + 1;
-	need += joinlength(pr->p_aliases) + 1;
-	need += strlen(prProto) + 1;
-
-	if (buffer == NULL) {
-		*len = need;
-		return (0);
-	}
-
-	if (*buffer != NULL && need > *len) {
-		errno = EINVAL;
-		return (-1);
-	}
-
-	if (*buffer == NULL) {
-		need += 2;		/*%< for CRLF */
-		*buffer = memget(need);
-		if (*buffer == NULL) {
-			errno = ENOMEM;
-			return (-1);
-		}
-
-		*len = need;
-	}
-
-	strcpy(*buffer, pr->p_name);		strcat(*buffer, fieldsep);
-	joinarray(pr->p_aliases, *buffer, COMMA); strcat(*buffer, fieldsep);
-	strcat(*buffer, prProto);		strcat(*buffer, fieldsep);
-
-	return (0);
-
-}
-
-/*%
- * int irp_unmarshall_pr(struct protoent *pr, char *buffer)
- *
- * notes: \li
- *
- *	See irpmarshall.h
- *
- * return: \li
- *
- *	0 on success, -1 on failure
- *
- */
-
-int irp_unmarshall_pr(struct protoent *pr, char *buffer) {
-	char *p, *q;
-	int prproto;
-	long t;
-	char *name = NULL;
-	char **aliases = NULL;
-	char tmpbuf[24];
-	char *tb;
-	char fieldsep = ':';
-	int myerrno = EINVAL;
-
-	if (pr == NULL || buffer == NULL) {
-		errno = EINVAL;
-		return (-1);
-	}
-
-	p = buffer;
-
-	/* p_name field */
-	name = NULL;
-	if (getfield(&name, 0, &p, fieldsep) == NULL || strlen(name) == 0U) {
-		goto error;
-	}
-
-
-	/* p_aliases field */
-	q = strchr(p, fieldsep);
-	if (q == NULL) {
-		goto error;
-	}
-	aliases = splitarray(p, q, COMMA);
-	if (aliases == NULL) {
-		myerrno = errno;
-		goto error;
-	}
-	p = q + 1;
-
-
-	/* p_proto field */
-	tb = tmpbuf;
-	if (getfield(&tb, sizeof tmpbuf, &p, fieldsep) == NULL ||
-	    strlen(tb) == 0U) {
-		goto error;
-	}
-	t = strtol(tmpbuf, &tb, 10);
-	if (*tb) {
-		goto error;	/*%< junk in value */
-	}
-	prproto = (int)t;
-	if ((long) prproto != t) {	/*%< value must have been too big. */
-		goto error;
-	}
-
-	pr->p_name = name;
-	pr->p_aliases = aliases;
-	pr->p_proto = prproto;
-
-	return (0);
-
- error:
-	errno = myerrno;
-
-	if (name != NULL) free(name);
-	free_array(aliases, 0);
-
-	return (-1);
-}
-
-/* ------------------------- struct protoent ------------------------- */
-
-
-
-/* +++++++++++++++++++++++++ struct hostent +++++++++++++++++++++++++ */
-
-/*%
- * int irp_marshall_ho(struct hostent *ho, char **buffer, size_t *len)
- *
- * notes: \li
- *
- *	See irpmarshall.h.
- *
- * return: \li
- *
- *	0 on success, -1 on failure.
- *
- */
-
-int
-irp_marshall_ho(struct hostent *ho, char **buffer, size_t *len) {
-	size_t need = 1;	/*%< for null byte */
-	char hoaddrtype[24];
-	char holength[24];
-	char **av;
-	char *p;
-	int addrlen;
-	int malloced = 0;
-	size_t remlen;
-	const char *fieldsep = "@";
-
-	if (ho == NULL || len == NULL) {
-		errno = EINVAL;
-		return (-1);
-	}
-
-	switch(ho->h_addrtype) {
-	case AF_INET:
-		strcpy(hoaddrtype, "AF_INET");
-		break;
-
-	case AF_INET6:
-		strcpy(hoaddrtype, "AF_INET6");
-		break;
-
-	default:
-		errno = EINVAL;
-		return (-1);
-	}
-
-	sprintf(holength, "%d", ho->h_length);
-
-	need += strlen(ho->h_name) + 1;
-	need += joinlength(ho->h_aliases) + 1;
-	need += strlen(hoaddrtype) + 1;
-	need += strlen(holength) + 1;
-
-	/* we determine an upper bound on the string length needed, not an
-	   exact length. */
-	addrlen = (ho->h_addrtype == AF_INET ? 16 : 46) ; /*%< XX other AF's?? */
-	for (av = ho->h_addr_list; av != NULL && *av != NULL ; av++)
-		need += addrlen;
-
-	if (buffer == NULL) {
-		*len = need;
-		return (0);
-	}
-
-	if (*buffer != NULL && need > *len) {
-		errno = EINVAL;
-		return (-1);
-	}
-
-	if (*buffer == NULL) {
-		need += 2;		/*%< for CRLF */
-		*buffer = memget(need);
-		if (*buffer == NULL) {
-			errno = ENOMEM;
-			return (-1);
-		}
-
-		*len = need;
-		malloced = 1;
-	}
-
-	strcpy(*buffer, ho->h_name);		strcat(*buffer, fieldsep);
-	joinarray(ho->h_aliases, *buffer, COMMA); strcat(*buffer, fieldsep);
-	strcat(*buffer, hoaddrtype);		strcat(*buffer, fieldsep);
-	strcat(*buffer, holength);		strcat(*buffer, fieldsep);
-
-	p = *buffer + strlen(*buffer);
-	remlen = need - strlen(*buffer);
-	for (av = ho->h_addr_list ; av != NULL && *av != NULL ; av++) {
-		if (inet_ntop(ho->h_addrtype, *av, p, remlen) == NULL) {
-			goto error;
-		}
-		if (*(av + 1) != NULL)
-			strcat(p, COMMASTR);
-		remlen -= strlen(p);
-		p += strlen(p);
-	}
-	strcat(*buffer, fieldsep);
-
-	return (0);
-
- error:
-	if (malloced) {
-		memput(*buffer, need);
-	}
-
-	return (-1);
-}
-
-/*%
- * int irp_unmarshall_ho(struct hostent *ho, char *buffer)
- *
- * notes: \li
- *
- *	See irpmarshall.h.
- *
- * return: \li
- *
- *	0 on success, -1 on failure.
- *
- */
-
-int
-irp_unmarshall_ho(struct hostent *ho, char *buffer) {
-	char *p, *q, *r;
-	int hoaddrtype;
-	int holength;
-	long t;
-	char *name;
-	char **aliases = NULL;
-	char **hohaddrlist = NULL;
-	size_t hoaddrsize;
-	char tmpbuf[24];
-	char *tb;
-	char **alist;
-	int addrcount;
-	char fieldsep = '@';
-	int myerrno = EINVAL;
-
-	if (ho == NULL || buffer == NULL) {
-		errno = EINVAL;
-		return (-1);
-	}
-
-	p = buffer;
-
-	/* h_name field */
-	name = NULL;
-	if (getfield(&name, 0, &p, fieldsep) == NULL || strlen(name) == 0U) {
-		goto error;
-	}
-
-
-	/* h_aliases field */
-	q = strchr(p, fieldsep);
-	if (q == NULL) {
-		goto error;
-	}
-	aliases = splitarray(p, q, COMMA);
-	if (aliases == NULL) {
-		myerrno = errno;
-		goto error;
-	}
-	p = q + 1;
-
-
-	/* h_addrtype field */
-	tb = tmpbuf;
-	if (getfield(&tb, sizeof tmpbuf, &p, fieldsep) == NULL ||
-	    strlen(tb) == 0U) {
-		goto error;
-	}
-	if (strcmp(tmpbuf, "AF_INET") == 0)
-		hoaddrtype = AF_INET;
-	else if (strcmp(tmpbuf, "AF_INET6") == 0)
-		hoaddrtype = AF_INET6;
-	else
-		goto error;
-
-
-	/* h_length field */
-	tb = tmpbuf;
-	if (getfield(&tb, sizeof tmpbuf, &p, fieldsep) == NULL ||
-	    strlen(tb) == 0U) {
-		goto error;
-	}
-	t = strtol(tmpbuf, &tb, 10);
-	if (*tb) {
-		goto error;	/*%< junk in value */
-	}
-	holength = (int)t;
-	if ((long) holength != t) {	/*%< value must have been too big. */
-		goto error;
-	}
-
-
-	/* h_addr_list field */
-	q = strchr(p, fieldsep);
-	if (q == NULL)
-		goto error;
-
-	/* count how many addresss are in there */
-	if (q > p + 1) {
-		for (addrcount = 1, r = p ; r != q ; r++) {
-			if (*r == COMMA)
-				addrcount++;
-		}
-	} else {
-		addrcount = 0;
-	}
-
-	hoaddrsize = (addrcount + 1) * sizeof (char *);
-	hohaddrlist = malloc(hoaddrsize);
-	if (hohaddrlist == NULL) {
-		myerrno = ENOMEM;
-		goto error;
-	}
-
-	memset(hohaddrlist, 0x0, hoaddrsize);
-
-	alist = hohaddrlist;
-	for (t = 0, r = p ; r != q ; p = r + 1, t++) {
-		char saved;
-		while (r != q && *r != COMMA) r++;
-		saved = *r;
-		*r = 0x0;
-
-		alist[t] = malloc(hoaddrtype == AF_INET ? 4 : 16);
-		if (alist[t] == NULL) {
-			myerrno = ENOMEM;
-			goto error;
-		}
-
-		if (inet_pton(hoaddrtype, p, alist[t]) == -1)
-			goto error;
-		*r = saved;
-	}
-	alist[t] = NULL;
-
-	ho->h_name = name;
-	ho->h_aliases = aliases;
-	ho->h_addrtype = hoaddrtype;
-	ho->h_length = holength;
-	ho->h_addr_list = hohaddrlist;
-
-	return (0);
-
- error:
-	errno = myerrno;
-
-	if (name != NULL) free(name);
-	free_array(hohaddrlist, 0);
-	free_array(aliases, 0);
-
-	return (-1);
-}
-
-/* ------------------------- struct hostent------------------------- */
-
-
-
-/* +++++++++++++++++++++++++ struct netgrp +++++++++++++++++++++++++ */
-
-/*%
- * int irp_marshall_ng(const char *host, const char *user,
- *		       const char *domain, char *buffer, size_t *len)
- *
- * notes: \li
- *
- *	See note for irp_marshall_ng_start
- *
- * return: \li
- *
- *	0 on success, 0 on failure.
- *
- */
-
-int
-irp_marshall_ng(const char *host, const char *user, const char *domain,
-		char **buffer, size_t *len) {
-	size_t need = 1; /*%< for nul byte */
-	const char *fieldsep = ",";
-
-	if (len == NULL) {
-		errno = EINVAL;
-		return (-1);
-	}
-
-	need += 4;		       /*%< two parens and two commas */
-	need += (host == NULL ? 0 : strlen(host));
-	need += (user == NULL ? 0 : strlen(user));
-	need += (domain == NULL ? 0 : strlen(domain));
-
-	if (buffer == NULL) {
-		*len = need;
-		return (0);
-	} else if (*buffer != NULL && need > *len) {
-		errno = EINVAL;
-		return (-1);
-	}
-
-	if (*buffer == NULL) {
-		need += 2;		/*%< for CRLF */
-		*buffer = memget(need);
-		if (*buffer == NULL) {
-			errno = ENOMEM;
-			return (-1);
-		}
-
-		*len = need;
-	}
-
-	(*buffer)[0] = '(';
-	(*buffer)[1] = '\0';
-
-	if (host != NULL)
-		strcat(*buffer, host);
-	strcat(*buffer, fieldsep);
-
-	if (user != NULL)
-		strcat(*buffer, user);
-	strcat(*buffer, fieldsep);
-
-	if (domain != NULL)
-		strcat(*buffer, domain);
-	strcat(*buffer, ")");
-
-	return (0);
-}
-
-
-
-/* ---------- */
-
-/*%
- * int irp_unmarshall_ng(const char **host, const char **user,
- *			 const char **domain, char *buffer)
- *
- * notes: \li
- *
- *	Unpacks the BUFFER into 3 character arrays it allocates and assigns
- *	to *HOST, *USER and *DOMAIN. If any field of the value is empty,
- *	then the corresponding paramater value will be set to NULL.
- *
- * return: \li
- *
- *	0 on success and -1 on failure.
- */
-
-int
-irp_unmarshall_ng(const char **hostp, const char **userp, const char **domainp,
-		  char *buffer)
-{
-	char *p, *q;
-	char fieldsep = ',';
-	int myerrno = EINVAL;
-	char *host, *user, *domain;
-
-	if (userp == NULL || hostp == NULL ||
-	    domainp == NULL || buffer == NULL) {
-		errno = EINVAL;
-		return (-1);
-	}
-
-	host = user = domain = NULL;
-
-	p = buffer;
-	while (isspace((unsigned char)*p)) {
-		p++;
-	}
-	if (*p != '(') {
-		goto error;
-	}
-
-	q = p + 1;
-	while (*q && *q != fieldsep)
-		q++;
-	if (!*q) {
-		goto error;
-	} else if (q > p + 1) {
-		host = strndup(p, q - p);
-	}
-
-	p = q + 1;
-	if (!*p) {
-		goto error;
-	} else if (*p != fieldsep) {
-		q = p + 1;
-		while (*q && *q != fieldsep)
-			q++;
-		if (!*q) {
-			goto error;
-		}
-		user = strndup(p, q - p);
-	} else {
-		p++;
-	}
-
-	if (!*p) {
-		goto error;
-	} else if (*p != ')') {
-		q = p + 1;
-		while (*q && *q != ')')
-			q++;
-		if (!*q) {
-			goto error;
-		}
-		domain = strndup(p, q - p);
-	}
-	*hostp = host;
-	*userp = user;
-	*domainp = domain;
-
-	return (0);
-
- error:
-	errno = myerrno;
-
-	if (host != NULL) free(host);
-	if (user != NULL) free(user);
-
-	return (-1);
-}
-
-/* ------------------------- struct netgrp ------------------------- */
-
-
-
-
-/* +++++++++++++++++++++++++ struct nwent +++++++++++++++++++++++++ */
-
-/*%
- * int irp_marshall_nw(struct nwent *ne, char **buffer, size_t *len)
- *
- * notes: \li
- *
- *	See at top.
- *
- * return: \li
- *
- *	0 on success and -1 on failure.
- *
- */
-
-int
-irp_marshall_nw(struct nwent *ne, char **buffer, size_t *len) {
-	size_t need = 1;	/*%< for null byte */
-	char nAddrType[24];
-	char nNet[MAXPADDRSIZE];
-	const char *fieldsep = COLONSTR;
-
-	if (ne == NULL || len == NULL) {
-		return (-1);
-	}
-
-	strcpy(nAddrType, ADDR_T_STR(ne->n_addrtype));
-
-	if (inet_net_ntop(ne->n_addrtype, ne->n_addr, ne->n_length,
-			  nNet, sizeof nNet) == NULL) {
-		return (-1);
-	}
-
-
-	need += strlen(ne->n_name) + 1;
-	need += joinlength(ne->n_aliases) + 1;
-	need += strlen(nAddrType) + 1;
-	need += strlen(nNet) + 1;
-
-	if (buffer == NULL) {
-		*len = need;
-		return (0);
-	}
-
-	if (*buffer != NULL && need > *len) {
-		errno = EINVAL;
-		return (-1);
-	}
-
-	if (*buffer == NULL) {
-		need += 2;		/*%< for CRLF */
-		*buffer = memget(need);
-		if (*buffer == NULL) {
-			errno = ENOMEM;
-			return (-1);
-		}
-
-		*len = need;
-	}
-
-	strcpy(*buffer, ne->n_name);		strcat(*buffer, fieldsep);
-	joinarray(ne->n_aliases, *buffer, COMMA) ; strcat(*buffer, fieldsep);
-	strcat(*buffer, nAddrType);		strcat(*buffer, fieldsep);
-	strcat(*buffer, nNet);			strcat(*buffer, fieldsep);
-
-	return (0);
-}
-
-/*%
- * int irp_unmarshall_nw(struct nwent *ne, char *buffer)
- *
- * notes: \li
- *
- *	See note up top.
- *
- * return: \li
- *
- *	0 on success and -1 on failure.
- *
- */
-
-int
-irp_unmarshall_nw(struct nwent *ne, char *buffer) {
-	char *p, *q;
-	int naddrtype;
-	long nnet;
-	int bits;
-	char *name = NULL;
-	char **aliases = NULL;
-	char tmpbuf[24];
-	char *tb;
-	char fieldsep = ':';
-	int myerrno = EINVAL;
-
-	if (ne == NULL || buffer == NULL) {
-		goto error;
-	}
-
-	p = buffer;
-
-	/* n_name field */
-	name = NULL;
-	if (getfield(&name, 0, &p, fieldsep) == NULL || strlen(name) == 0U) {
-		goto error;
-	}
-
-
-	/* n_aliases field. Aliases are separated by commas */
-	q = strchr(p, fieldsep);
-	if (q == NULL) {
-		goto error;
-	}
-	aliases = splitarray(p, q, COMMA);
-	if (aliases == NULL) {
-		myerrno = errno;
-		goto error;
-	}
-	p = q + 1;
-
-
-	/* h_addrtype field */
-	tb = tmpbuf;
-	if (getfield(&tb, sizeof tmpbuf, &p, fieldsep) == NULL ||
-	    strlen(tb) == 0U) {
-		goto error;
-	}
-	if (strcmp(tmpbuf, "AF_INET") == 0)
-		naddrtype = AF_INET;
-	else if (strcmp(tmpbuf, "AF_INET6") == 0)
-		naddrtype = AF_INET6;
-	else
-		goto error;
-
-
-	/* n_net field */
-	tb = tmpbuf;
-	if (getfield(&tb, sizeof tmpbuf, &p, fieldsep) == NULL ||
-	    strlen(tb) == 0U) {
-		goto error;
-	}
-	nnet = 0;
-	bits = inet_net_pton(naddrtype, tmpbuf, &nnet, sizeof nnet);
-	if (bits < 0) {
-		goto error;
-	}
-
-	/* nnet = ntohl(nnet); */ /* keep in network order for nwent */
-
-	ne->n_name = name;
-	ne->n_aliases = aliases;
-	ne->n_addrtype = naddrtype;
-	ne->n_length = bits;
-	ne->n_addr = malloc(sizeof nnet);
-	if (ne->n_addr == NULL) {
-		goto error;
-	}
-
-	memcpy(ne->n_addr, &nnet, sizeof nnet);
-
-	return (0);
-
- error:
-	errno = myerrno;
-
-	if (name != NULL) free(name);
-	free_array(aliases, 0);
-
-	return (-1);
-}
-
-
-/* ------------------------- struct nwent ------------------------- */
-
-
-/* +++++++++++++++++++++++++ struct netent +++++++++++++++++++++++++ */
-
-/*%
- * int irp_marshall_ne(struct netent *ne, char **buffer, size_t *len)
- *
- * notes: \li
- *
- *	See at top.
- *
- * return: \li
- *
- *	0 on success and -1 on failure.
- *
- */
-
-int
-irp_marshall_ne(struct netent *ne, char **buffer, size_t *len) {
-	size_t need = 1;	/*%< for null byte */
-	char nAddrType[24];
-	char nNet[MAXPADDRSIZE];
-	const char *fieldsep = COLONSTR;
-	long nval;
-
-	if (ne == NULL || len == NULL) {
-		return (-1);
-	}
-
-	strcpy(nAddrType, ADDR_T_STR(ne->n_addrtype));
-
-	nval = htonl(ne->n_net);
-	if (inet_ntop(ne->n_addrtype, &nval, nNet, sizeof nNet) == NULL) {
-		return (-1);
-	}
-
-	need += strlen(ne->n_name) + 1;
-	need += joinlength(ne->n_aliases) + 1;
-	need += strlen(nAddrType) + 1;
-	need += strlen(nNet) + 1;
-
-	if (buffer == NULL) {
-		*len = need;
-		return (0);
-	}
-
-	if (*buffer != NULL && need > *len) {
-		errno = EINVAL;
-		return (-1);
-	}
-
-	if (*buffer == NULL) {
-		need += 2;		/*%< for CRLF */
-		*buffer = memget(need);
-		if (*buffer == NULL) {
-			errno = ENOMEM;
-			return (-1);
-		}
-
-		*len = need;
-	}
-
-	strcpy(*buffer, ne->n_name);		strcat(*buffer, fieldsep);
-	joinarray(ne->n_aliases, *buffer, COMMA) ; strcat(*buffer, fieldsep);
-	strcat(*buffer, nAddrType);		strcat(*buffer, fieldsep);
-	strcat(*buffer, nNet);			strcat(*buffer, fieldsep);
-
-	return (0);
-}
-
-/*%
- * int irp_unmarshall_ne(struct netent *ne, char *buffer)
- *
- * notes: \li
- *
- *	See note up top.
- *
- * return: \li
- *
- *	0 on success and -1 on failure.
- *
- */
-
-int
-irp_unmarshall_ne(struct netent *ne, char *buffer) {
-	char *p, *q;
-	int naddrtype;
-	long nnet;
-	int bits;
-	char *name = NULL;
-	char **aliases = NULL;
-	char tmpbuf[24];
-	char *tb;
-	char fieldsep = ':';
-	int myerrno = EINVAL;
-
-	if (ne == NULL || buffer == NULL) {
-		goto error;
-	}
-
-	p = buffer;
-
-	/* n_name field */
-	name = NULL;
-	if (getfield(&name, 0, &p, fieldsep) == NULL || strlen(name) == 0U) {
-		goto error;
-	}
-
-
-	/* n_aliases field. Aliases are separated by commas */
-	q = strchr(p, fieldsep);
-	if (q == NULL) {
-		goto error;
-	}
-	aliases = splitarray(p, q, COMMA);
-	if (aliases == NULL) {
-		myerrno = errno;
-		goto error;
-	}
-	p = q + 1;
-
-
-	/* h_addrtype field */
-	tb = tmpbuf;
-	if (getfield(&tb, sizeof tmpbuf, &p, fieldsep) == NULL ||
-	    strlen(tb) == 0U) {
-		goto error;
-	}
-	if (strcmp(tmpbuf, "AF_INET") == 0)
-		naddrtype = AF_INET;
-	else if (strcmp(tmpbuf, "AF_INET6") == 0)
-		naddrtype = AF_INET6;
-	else
-		goto error;
-
-
-	/* n_net field */
-	tb = tmpbuf;
-	if (getfield(&tb, sizeof tmpbuf, &p, fieldsep) == NULL ||
-	    strlen(tb) == 0U) {
-		goto error;
-	}
-	bits = inet_net_pton(naddrtype, tmpbuf, &nnet, sizeof nnet);
-	if (bits < 0) {
-		goto error;
-	}
-	nnet = ntohl(nnet);
-
-	ne->n_name = name;
-	ne->n_aliases = aliases;
-	ne->n_addrtype = naddrtype;
-	ne->n_net = nnet;
-
-	return (0);
-
- error:
-	errno = myerrno;
-
-	if (name != NULL) free(name);
-	free_array(aliases, 0);
-
-	return (-1);
-}
-
-
-/* ------------------------- struct netent ------------------------- */
-
-
-/* =========================================================================== */
-
-/*%
- * static char ** splitarray(const char *buffer, const char *buffend, char delim)
- *
- * notes: \li
- *
- *	Split a delim separated astring. Not allowed
- *	to have two delims next to each other. BUFFER points to begining of
- *	string, BUFFEND points to one past the end of the string
- *	(i.e. points at where the null byte would be if null
- *	terminated).
- *
- * return: \li
- *
- *	Returns a malloced array of pointers, each pointer pointing to a
- *	malloced string. If BUFEER is an empty string, then return values is
- *	array of 1 pointer that is NULL. Returns NULL on failure.
- *
- */
-
-static char **
-splitarray(const char *buffer, const char *buffend, char delim) {
-	const char *p, *q;
-	int count = 0;
-	char **arr = NULL;
-	char **aptr;
-
-	if (buffend < buffer)
-		return (NULL);
-	else if (buffend > buffer && *buffer == delim)
-		return (NULL);
-	else if (buffend > buffer && *(buffend - 1) == delim)
-		return (NULL);
-
-	/* count the number of field and make sure none are empty */
-	if (buffend > buffer + 1) {
-		for (count = 1, q = buffer ; q != buffend ; q++) {
-			if (*q == delim) {
-				if (q > buffer && (*(q - 1) == delim)) {
-					errno = EINVAL;
-					return (NULL);
-				}
-				count++;
-			}
-		}
-	}
-
-	if (count > 0) {
-		count++ ;		/*%< for NULL at end */
-		aptr = arr = malloc(count * sizeof (char *));
-		if (aptr == NULL) {
-			 errno = ENOMEM;
-			 return (NULL);
-		 }
-
-		memset(arr, 0x0, count * sizeof (char *));
-		for (p = buffer ; p < buffend ; p++) {
-			for (q = p ; *q != delim && q != buffend ; q++)
-				/* nothing */;
-			*aptr = strndup(p, q - p);
-
-			p = q;
-			aptr++;
-		}
-		*aptr = NULL;
-	} else {
-		arr = malloc(sizeof (char *));
-		if (arr == NULL) {
-			errno = ENOMEM;
-			return (NULL);
-		}
-
-		*arr = NULL;
-	}
-
-	return (arr);
-}
-
-/*%
- * static size_t joinlength(char * const *argv)
- *
- * return: \li
- *
- *	the number of bytes in all the arrays pointed at
- *	by argv, including their null bytes(which will usually be turned
- *	into commas).
- *
- *
- */
-
-static size_t
-joinlength(char * const *argv) {
-	int len = 0;
-
-	while (argv && *argv) {
-		len += (strlen(*argv) + 1);
-		argv++;
-	}
-
-	return (len);
-}
-
-/*%
- * int joinarray(char * const *argv, char *buffer, char delim)
- *
- * notes: \li
- *
- *	Copy all the ARGV strings into the end of BUFFER
- *	separating them with DELIM.  BUFFER is assumed to have
- *	enough space to hold everything and to be already null-terminated.
- *
- * return: \li
- *
- *	0 unless argv or buffer is NULL.
- *
- *
- */
-
-static int
-joinarray(char * const *argv, char *buffer, char delim) {
-	char * const *p;
-	char sep[2];
-
-	if (argv == NULL || buffer == NULL) {
-		errno = EINVAL;
-		return (-1);
-	}
-
-	sep[0] = delim;
-	sep[1] = 0x0;
-
-	for (p = argv ; *p != NULL ; p++) {
-		strcat(buffer, *p);
-		if (*(p + 1) != NULL) {
-			strcat(buffer, sep);
-		}
-	}
-
-	return (0);
-}
-
-/*%
- * static char * getfield(char **res, size_t reslen, char **ptr, char delim)
- *
- * notes: \li
- *
- *	Stores in *RES, which is a buffer of length RESLEN, a
- *	copy of the bytes from *PTR up to and including the first
- *	instance of DELIM. If *RES is NULL, then it will be
- *	assigned a malloced buffer to hold the copy. *PTR is
- *	modified to point at the found delimiter.
- *
- * return: \li
- *
- *	If there was no delimiter, then NULL is returned,
- *	otherewise *RES is returned.
- *
- */
-
-static char *
-getfield(char **res, size_t reslen, char **ptr, char delim) {
-	char *q;
-
-	if (res == NULL || ptr == NULL || *ptr == NULL) {
-		errno = EINVAL;
-		return (NULL);
-	}
-
-	q = strchr(*ptr, delim);
-
-	if (q == NULL) {
-		errno = EINVAL;
-		return (NULL);
-	} else {
-		if (*res == NULL) {
-			*res = strndup(*ptr, q - *ptr);
-		} else {
-			if ((size_t)(q - *ptr + 1) > reslen) { /*%< to big for res */
-				errno = EINVAL;
-				return (NULL);
-			} else {
-				strncpy(*res, *ptr, q - *ptr);
-				(*res)[q - *ptr] = 0x0;
-			}
-		}
-		*ptr = q + 1;
-	}
-
-	return (*res);
-}
-
-
-
-
-
-#ifndef HAVE_STRNDUP
-/*
- * static char * strndup(const char *str, size_t len)
- *
- * notes: \li
- *
- *	like strdup, except do len bytes instead of the whole string. Always
- *	null-terminates.
- *
- * return: \li
- *
- *	The newly malloced string.
- *
- */
-
-static char *
-strndup(const char *str, size_t len) {
-	char *p = malloc(len + 1);
-
-	if (p == NULL)
-		return (NULL);
-	strncpy(p, str, len);
-	p[len] = 0x0;
-	return (p);
-}
-#endif
-
-#if WANT_MAIN
-
-/*%
- * static int strcmp_nws(const char *a, const char *b)
- *
- * notes: \li
- *
- *	do a strcmp, except uneven lengths of whitespace compare the same
- *
- * return: \li
- *
- */
-
-static int
-strcmp_nws(const char *a, const char *b) {
-	while (*a && *b) {
-		if (isspace(*a) && isspace(*b)) {
-			do {
-				a++;
-			} while (isspace(*a));
-			do {
-				b++;
-			} while (isspace(*b));
-		}
-		if (*a < *b)
-			return (-1);
-		else if (*a > *b)
-			return (1);
-
-		a++;
-		b++;;
-	}
-
-	if (*a == *b)
-		return (0);
-	else if (*a > *b)
-		return (1);
-	else
-		return (-1);
-}
-
-#endif
-
-/*%
- * static void free_array(char **argv, size_t entries)
- *
- * notes: \li
- *
- *	Free argv and each of the pointers inside it. The end of
- *	the array is when a NULL pointer is found inside. If
- *	entries is > 0, then NULL pointers inside the array do
- *	not indicate the end of the array.
- *
- */
-
-static void
-free_array(char **argv, size_t entries) {
-	char **p = argv;
-	int useEntries = (entries > 0U);
-
-	if (argv == NULL)
-		return;
-
-	while ((useEntries && entries > 0U) || *p) {
-		if (*p)
-			free(*p);
-		p++;
-		if (useEntries)
-			entries--;
-	}
-	free(argv);
-}
-
-
-
-
-
-/* ************************************************** */
-
-#if WANT_MAIN
-
-/*% takes an option to indicate what sort of marshalling(read the code) and
-   an argument. If the argument looks like a marshalled buffer(has a ':'
-   embedded) then it's unmarshalled and the remarshalled and the new string
-   is compared to the old one.
-*/
-
-int
-main(int argc, char **argv) {
-	char buffer[1024];
-	char *b = &buffer[0];
-	size_t len = sizeof buffer;
-	char option;
-
-	if (argc < 2 || argv[1][0] != '-')
-		exit(1);
-
-	option = argv[1][1];
-	argv++;
-	argc--;
-
-
-#if 0
-	{
-		char buff[10];
-		char *p = argv[1], *q = &buff[0];
-
-		while (getfield(&q, sizeof buff, &p, ':') != NULL) {
-			printf("field: \"%s\"\n", q);
-			p++;
-		}
-		printf("p is now \"%s\"\n", p);
-	}
-#endif
-
-#if 0
-	{
-		char **x = splitarray(argv[1], argv[1] + strlen(argv[1]),
-				      argv[2][0]);
-		char **p;
-
-		if (x == NULL)
-			printf("split failed\n");
-
-		for (p = x ; p != NULL && *p != NULL ; p++) {
-			printf("\"%s\"\n", *p);
-		}
-	}
-#endif
-
-#if 1
-	switch(option) {
-	case 'n': {
-		struct nwent ne;
-		int i;
-
-		if (strchr(argv[1], ':') != NULL) {
-			if (irp_unmarshall_nw(&ne, argv[1]) != 0) {
-				printf("Unmarhsalling failed\n");
-				exit(1);
-			}
-
-			printf("Name: \"%s\"\n", ne.n_name);
-			printf("Aliases:");
-			for (i = 0 ; ne.n_aliases[i] != NULL ; i++)
-				printf("\n\t\"%s\"", ne.n_aliases[i]);
-			printf("\nAddrtype: %s\n", ADDR_T_STR(ne.n_addrtype));
-			inet_net_ntop(ne.n_addrtype, ne.n_addr, ne.n_length,
-				      buffer, sizeof buffer);
-			printf("Net: \"%s\"\n", buffer);
-			*((long*)ne.n_addr) = htonl(*((long*)ne.n_addr));
-			inet_net_ntop(ne.n_addrtype, ne.n_addr, ne.n_length,
-				      buffer, sizeof buffer);
-			printf("Corrected Net: \"%s\"\n", buffer);
-		} else {
-			struct netent *np1 = getnetbyname(argv[1]);
-			ne.n_name = np1->n_name;
-			ne.n_aliases = np1->n_aliases;
-			ne.n_addrtype = np1->n_addrtype;
-			ne.n_addr = &np1->n_net;
-			ne.n_length = (IN_CLASSA(np1->n_net) ?
-				       8 :
-				       (IN_CLASSB(np1->n_net) ?
-					16 :
-					(IN_CLASSC(np1->n_net) ?
-					 24 : -1)));
-			np1->n_net = htonl(np1->n_net);
-			if (irp_marshall_nw(&ne, &b, &len) != 0) {
-				printf("Marshalling failed\n");
-			}
-			printf("%s\n", b);
-		}
-		break;
-	}
-
-
-	case 'r': {
-		char **hosts, **users, **domains;
-		size_t entries;
-		int i;
-		char *buff;
-		size_t size;
-		char *ngname;
-
-		if (strchr(argv[1], '(') != NULL) {
-			if (irp_unmarshall_ng(&ngname, &entries,
-					      &hosts, &users, &domains,
-					      argv[1]) != 0) {
-				printf("unmarshall failed\n");
-				exit(1);
-			}
-
-#define STRVAL(x) (x == NULL ? "*" : x)
-
-			printf("%s {\n", ngname);
-			for (i = 0 ; i < entries ; i++)
-				printf("\t\"%s\" : \"%s\" : \"%s\"\n",
-				       STRVAL(hosts[i]),
-				       STRVAL(users[i]),
-				       STRVAL(domains[i]));
-			printf("}\n\n\n");
-
-
-			irp_marshall_ng_start(ngname, NULL, &size);
-			for (i = 0 ; i < entries ; i++)
-				irp_marshall_ng_next(hosts[i], users[i],
-						     domains[i], NULL, &size);
-			irp_marshall_ng_end(NULL, &size);
-
-			buff = malloc(size);
-
-			irp_marshall_ng_start(ngname, buff, &size);
-			for (i = 0 ; i < entries ; i++) {
-				if (irp_marshall_ng_next(hosts[i], users[i],
-							 domains[i], buff,
-							 &size) != 0)
-					printf("next marshalling failed.\n");
-			}
-			irp_marshall_ng_end(buff, &size);
-
-			if (strcmp_nws(argv[1], buff) != 0) {
-				printf("compare failed:\n\t%s\n\t%s\n",
-				       buffer, argv[1]);
-			} else {
-				printf("compare ok\n");
-			}
-		} else {
-			char *h, *u, *d, *buff;
-			size_t size;
-
-			/* run through two times. First to figure out how
-			   much of a buffer we need. Second to do the
-			   actual marshalling */
-
-			setnetgrent(argv[1]);
-			irp_marshall_ng_start(argv[1], NULL, &size);
-			while (getnetgrent(&h, &u, &d) == 1)
-				irp_marshall_ng_next(h, u, d, NULL, &size);
-			irp_marshall_ng_end(NULL, &size);
-			endnetgrent(argv[1]);
-
-			buff = malloc(size);
-
-			setnetgrent(argv[1]);
-			if (irp_marshall_ng_start(argv[1], buff, &size) != 0)
-				printf("Marshalling start failed\n");
-
-			while (getnetgrent(&h, &u, &d) == 1) {
-				if (irp_marshall_ng_next(h, u, d, buff, &size)
-				    != 0) {
-					printf("Marshalling failed\n");
-				}
-			}
-
-			irp_marshall_ng_end(buff, &size);
-			endnetgrent();
-
-			printf("success: %s\n", buff);
-		}
-		break;
-	}
-
-
-
-	case 'h': {
-		struct hostent he, *hp;
-		int i;
-
-
-		if (strchr(argv[1], '@') != NULL) {
-			if (irp_unmarshall_ho(&he, argv[1]) != 0) {
-				printf("unmarshall failed\n");
-				exit(1);
-			}
-
-			printf("Host: \"%s\"\nAliases:", he.h_name);
-			for (i = 0 ; he.h_aliases[i] != NULL ; i++)
-				printf("\n\t\t\"%s\"", he.h_aliases[i]);
-			printf("\nAddr Type: \"%s\"\n",
-			       ADDR_T_STR(he.h_addrtype));
-			printf("Length: %d\nAddresses:", he.h_length);
-			for (i = 0 ; he.h_addr_list[i] != 0 ; i++) {
-				inet_ntop(he.h_addrtype, he.h_addr_list[i],
-					  buffer, sizeof buffer);
-				printf("\n\t\"%s\"\n", buffer);
-			}
-			printf("\n\n");
-
-			irp_marshall_ho(&he, &b, &len);
-			if (strcmp(argv[1], buffer) != 0) {
-				printf("compare failed:\n\t\"%s\"\n\t\"%s\"\n",
-				       buffer, argv[1]);
-			} else {
-				printf("compare ok\n");
-			}
-		} else {
-			if ((hp = gethostbyname(argv[1])) == NULL) {
-				perror("gethostbyname");
-				printf("\"%s\"\n", argv[1]);
-				exit(1);
-			}
-
-			if (irp_marshall_ho(hp, &b, &len) != 0) {
-				printf("irp_marshall_ho failed\n");
-				exit(1);
-			}
-
-			printf("success: \"%s\"\n", buffer);
-		}
-		break;
-	}
-
-
-	case 's': {
-		struct servent *sv;
-		struct servent sv1;
-
-		if (strchr(argv[1], ':') != NULL) {
-			sv = &sv1;
-			memset(sv, 0xef, sizeof (struct servent));
-			if (irp_unmarshall_sv(sv, argv[1]) != 0) {
-				printf("unmarshall failed\n");
-
-			}
-
-			irp_marshall_sv(sv, &b, &len);
-			if (strcmp(argv[1], buffer) != 0) {
-				printf("compare failed:\n\t\"%s\"\n\t\"%s\"\n",
-				       buffer, argv[1]);
-			} else {
-				printf("compare ok\n");
-			}
-		} else {
-			if ((sv = getservbyname(argv[1], argv[2])) == NULL) {
-				perror("getservent");
-				exit(1);
-			}
-
-			if (irp_marshall_sv(sv, &b, &len) != 0) {
-				printf("irp_marshall_sv failed\n");
-				exit(1);
-			}
-
-			printf("success: \"%s\"\n", buffer);
-		}
-		break;
-	}
-
-	case 'g': {
-		struct group *gr;
-		struct group gr1;
-
-		if (strchr(argv[1], ':') != NULL) {
-			gr = &gr1;
-			memset(gr, 0xef, sizeof (struct group));
-			if (irp_unmarshall_gr(gr, argv[1]) != 0) {
-				printf("unmarshall failed\n");
-
-			}
-
-			irp_marshall_gr(gr, &b, &len);
-			if (strcmp(argv[1], buffer) != 0) {
-				printf("compare failed:\n\t\"%s\"\n\t\"%s\"\n",
-				       buffer, argv[1]);
-			} else {
-				printf("compare ok\n");
-			}
-		} else {
-			if ((gr = getgrnam(argv[1])) == NULL) {
-				perror("getgrnam");
-				exit(1);
-			}
-
-			if (irp_marshall_gr(gr, &b, &len) != 0) {
-				printf("irp_marshall_gr failed\n");
-				exit(1);
-			}
-
-			printf("success: \"%s\"\n", buffer);
-		}
-		break;
-	}
-
-
-	case 'p': {
-		struct passwd *pw;
-		struct passwd pw1;
-
-		if (strchr(argv[1], ':') != NULL) {
-			pw = &pw1;
-			memset(pw, 0xef, sizeof (*pw));
-			if (irp_unmarshall_pw(pw, argv[1]) != 0) {
-				printf("unmarshall failed\n");
-				exit(1);
-			}
-
-			printf("User: \"%s\"\nPasswd: \"%s\"\nUid: %ld\nGid: %ld\n",
-			       pw->pw_name, pw->pw_passwd, (long)pw->pw_uid,
-			       (long)pw->pw_gid);
-			printf("Class: \"%s\"\nChange: %ld\nGecos: \"%s\"\n",
-			       pw->pw_class, (long)pw->pw_change, pw->pw_gecos);
-			printf("Shell: \"%s\"\nDirectory: \"%s\"\n",
-			       pw->pw_shell, pw->pw_dir);
-
-			pw = getpwnam(pw->pw_name);
-			irp_marshall_pw(pw, &b, &len);
-			if (strcmp(argv[1], buffer) != 0) {
-				printf("compare failed:\n\t\"%s\"\n\t\"%s\"\n",
-				       buffer, argv[1]);
-			} else {
-				printf("compare ok\n");
-			}
-		} else {
-			if ((pw = getpwnam(argv[1])) == NULL) {
-				perror("getpwnam");
-				exit(1);
-			}
-
-			if (irp_marshall_pw(pw, &b, &len) != 0) {
-				printf("irp_marshall_pw failed\n");
-				exit(1);
-			}
-
-			printf("success: \"%s\"\n", buffer);
-		}
-		break;
-	}
-
-	default:
-		printf("Wrong option: %c\n", option);
-		break;
-	}
-
-#endif
-
-	return (0);
-}
-
-#endif
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/irs_data.c b/contrib/bind9/lib/bind/irs/irs_data.c
deleted file mode 100644
index ed94614..0000000
--- a/contrib/bind9/lib/bind/irs/irs_data.c
+++ /dev/null
@@ -1,246 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: irs_data.c,v 1.7.18.5 2007/08/27 03:34:24 marka Exp $";
-#endif
-
-#include "port_before.h"
-
-#ifndef __BIND_NOSTATIC
-
-#include <sys/types.h>
-
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-
-#include <resolv.h>
-#include <stdio.h>
-#include <string.h>
-#include <isc/memcluster.h>
-
-#ifdef DO_PTHREADS
-#include <pthread.h>
-#endif
-
-#include <irs.h>
-#include <stdlib.h>
-
-#include "port_after.h"
-
-#include "irs_data.h"
-#undef _res
-#if !(__GLIBC__ > 2 || __GLIBC__ == 2 &&  __GLIBC_MINOR__ >= 3)
-#undef h_errno
-extern int h_errno;
-#endif
-
-extern struct __res_state _res;
-
-#ifdef	DO_PTHREADS
-static pthread_key_t	key;
-static int		once = 0;
-#else
-static struct net_data	*net_data;
-#endif
-
-void
-irs_destroy(void) {
-#ifndef DO_PTHREADS
-	if (net_data != NULL)
-		net_data_destroy(net_data);
-	net_data = NULL;
-#endif
-}
-
-void
-net_data_destroy(void *p) {
-	struct net_data *net_data = p;
-
-	res_ndestroy(net_data->res);
-	if (net_data->gr != NULL) {
-		(*net_data->gr->close)(net_data->gr);
-		net_data->gr = NULL;
-	}
-	if (net_data->pw != NULL) {
-		(*net_data->pw->close)(net_data->pw);
-		net_data->pw = NULL;
-	}
-	if (net_data->sv != NULL) {
-		(*net_data->sv->close)(net_data->sv);
-		net_data->sv = NULL;
-	}
-	if (net_data->pr != NULL) {
-		(*net_data->pr->close)(net_data->pr);
-		net_data->pr = NULL;
-	}
-	if (net_data->ho != NULL) {
-		(*net_data->ho->close)(net_data->ho);
-		net_data->ho = NULL;
-	}
-	if (net_data->nw != NULL) {
-		(*net_data->nw->close)(net_data->nw);
-		net_data->nw = NULL;
-	}
-	if (net_data->ng != NULL) {
-		(*net_data->ng->close)(net_data->ng);
-		net_data->ng = NULL;
-	}
-	if (net_data->ho_data != NULL) {
-		free(net_data->ho_data);
-		net_data->ho_data = NULL;
-	}
-	if (net_data->nw_data != NULL) {
-		free(net_data->nw_data);
-		net_data->nw_data = NULL;
-	}
-
-	(*net_data->irs->close)(net_data->irs);
-	memput(net_data, sizeof *net_data);
-}
-
-/*%
- *  applications that need a specific config file other than
- * _PATH_IRS_CONF should call net_data_init directly rather than letting
- *   the various wrapper functions make the first call. - brister
- */
-
-struct net_data *
-net_data_init(const char *conf_file) {
-#ifdef	DO_PTHREADS
-#ifndef LIBBIND_MUTEX_INITIALIZER
-#define LIBBIND_MUTEX_INITIALIZER PTHREAD_MUTEX_INITIALIZER
-#endif
-	static pthread_mutex_t keylock = LIBBIND_MUTEX_INITIALIZER;
-	struct net_data *net_data;
-
-	if (!once) {
-		if (pthread_mutex_lock(&keylock) != 0)
-			return (NULL);
-		if (!once) {
-			if (pthread_key_create(&key, net_data_destroy) != 0) {
-				(void)pthread_mutex_unlock(&keylock);
-				return (NULL);
-			}
-			once = 1;
-		}
-		if (pthread_mutex_unlock(&keylock) != 0)
-			return (NULL);
-	}
-	net_data = pthread_getspecific(key);
-#endif
-
-	if (net_data == NULL) {
-		net_data = net_data_create(conf_file);
-		if (net_data == NULL)
-			return (NULL);
-#ifdef	DO_PTHREADS
-		if (pthread_setspecific(key, net_data) != 0) {
-			net_data_destroy(net_data);
-			return (NULL);
-		}
-#endif
-	}
-
-	return (net_data);
-}
-
-struct net_data *
-net_data_create(const char *conf_file) {
-	struct net_data *net_data;
-
-	net_data = memget(sizeof (struct net_data));
-	if (net_data == NULL)
-		return (NULL);
-	memset(net_data, 0, sizeof (struct net_data));
-
-	if ((net_data->irs = irs_gen_acc("", conf_file)) == NULL) {
-		memput(net_data, sizeof (struct net_data));
-		return (NULL);
-	}
-#ifndef DO_PTHREADS
-	(*net_data->irs->res_set)(net_data->irs, &_res, NULL);
-#endif
-
-	net_data->res = (*net_data->irs->res_get)(net_data->irs);
-	if (net_data->res == NULL) {
-		(*net_data->irs->close)(net_data->irs);
-		memput(net_data, sizeof (struct net_data));
-		return (NULL);
-	}
-
-	if ((net_data->res->options & RES_INIT) == 0U &&
-	    res_ninit(net_data->res) == -1) {
-		(*net_data->irs->close)(net_data->irs);
-		memput(net_data, sizeof (struct net_data));
-		return (NULL);
-	}
-
-	return (net_data);
-}
-
-void
-net_data_minimize(struct net_data *net_data) {
-	res_nclose(net_data->res);
-}
-
-#ifdef _REENTRANT
-struct __res_state *
-__res_state(void) {
-	/* NULL param here means use the default config file. */
-	struct net_data *net_data = net_data_init(NULL);
-	if (net_data && net_data->res)
-		return (net_data->res);
-
-	return (&_res);
-}
-#else
-#ifdef __linux
-struct __res_state *
-__res_state(void) {
-	return (&_res);
-}
-#endif
-#endif
-
-int *
-__h_errno(void) {
-	/* NULL param here means use the default config file. */
-	struct net_data *net_data = net_data_init(NULL);
-	if (net_data && net_data->res)
-		return (&net_data->res->res_h_errno);
-#if !(__GLIBC__ > 2 || __GLIBC__ == 2 &&  __GLIBC_MINOR__ >= 3)
-	return(&_res.res_h_errno);
-#else
-	return (&h_errno);
-#endif
-}
-
-void
-__h_errno_set(struct __res_state *res, int err) {
-
-
-#if (__GLIBC__ > 2 || __GLIBC__ == 2 &&  __GLIBC_MINOR__ >= 3)
-	res->res_h_errno = err;
-#else
-	h_errno = res->res_h_errno = err;
-#endif
-}
-
-#endif /*__BIND_NOSTATIC*/
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/irs_data.h b/contrib/bind9/lib/bind/irs/irs_data.h
deleted file mode 100644
index c1ee3dd..0000000
--- a/contrib/bind9/lib/bind/irs/irs_data.h
+++ /dev/null
@@ -1,63 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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: irs_data.h,v 1.2.18.1 2005/04/27 05:01:01 sra Exp $
- */
-
-#ifndef __BIND_NOSTATIC
-
-#define	net_data_init		__net_data_init
-
-struct net_data {
-	struct irs_acc *	irs;
-
-	struct irs_gr *		gr;
-	struct irs_pw *		pw;
-	struct irs_sv *		sv;
-	struct irs_pr *		pr;
-	struct irs_ho *		ho;
-	struct irs_nw *		nw;
-	struct irs_ng *		ng;
-
-	struct group *		gr_last;
-	struct passwd *		pw_last;
-	struct servent *	sv_last;
-	struct protoent *	pr_last;
-	struct netent *		nw_last; /*%< should have been ne_last */
-	struct nwent *		nww_last;
-	struct hostent *	ho_last;
-
-	unsigned int		gr_stayopen :1;
-	unsigned int		pw_stayopen :1;
-	unsigned int		sv_stayopen :1;
-	unsigned int		pr_stayopen :1;
-	unsigned int		ho_stayopen :1;
-	unsigned int		nw_stayopen :1;
-
-	void *			nw_data;
-	void *			ho_data;
-
-	struct __res_state *	res;	/*%< for gethostent.c */
-};
-
-extern struct net_data *	net_data_init(const char *conf_file);
-extern void			net_data_minimize(struct net_data *);
-
-#endif /*__BIND_NOSTATIC*/
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/irs_p.h b/contrib/bind9/lib/bind/irs/irs_p.h
deleted file mode 100644
index bc1817b..0000000
--- a/contrib/bind9/lib/bind/irs/irs_p.h
+++ /dev/null
@@ -1,51 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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: irs_p.h,v 1.2.18.1 2005/04/27 05:01:01 sra Exp $
- */
-
-#ifndef _IRS_P_H_INCLUDED
-#define _IRS_P_H_INCLUDED
-
-#include <stdio.h>
-
-#include "pathnames.h"
-
-#define IRS_SV_MAXALIASES	35
-
-struct lcl_sv {
-	FILE *		fp;
-	char		line[BUFSIZ+1];
-	struct servent	serv;
-	char *		serv_aliases[IRS_SV_MAXALIASES];
-};
-
-#define	irs_nul_ng	__irs_nul_ng
-#define	map_v4v6_address __map_v4v6_address
-#define	make_group_list	__make_group_list
-#define	irs_lclsv_fnxt	__irs_lclsv_fnxt
-
-extern void		map_v4v6_address(const char *src, char *dst);
-extern int		make_group_list(struct irs_gr *, const char *,
-					gid_t, gid_t *, int *);
-extern struct irs_ng *	irs_nul_ng(struct irs_acc *);
-extern struct servent * irs_lclsv_fnxt(struct lcl_sv *);
-
-#endif
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/lcl.c b/contrib/bind9/lib/bind/irs/lcl.c
deleted file mode 100644
index 930c87e..0000000
--- a/contrib/bind9/lib/bind/irs/lcl.c
+++ /dev/null
@@ -1,142 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996-1999 by 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.
- */
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: lcl.c,v 1.3.18.1 2005/04/27 05:01:02 sra Exp $";
-#endif
-
-/* Imports */
-
-#include "port_before.h"
-
-#include <stdlib.h>
-#include <errno.h>
-#include <string.h>
-
-#include <sys/types.h>
-#include <netinet/in.h> 
-#include <arpa/nameser.h>
-#include <resolv.h>
-
-#include <isc/memcluster.h>
-
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "lcl_p.h"
-
-/* Forward. */
-
-static void		lcl_close(struct irs_acc *);
-static struct __res_state *	lcl_res_get(struct irs_acc *);
-static void		lcl_res_set(struct irs_acc *, struct __res_state *,
-				void (*)(void *));
-
-/* Public */
-
-struct irs_acc *
-irs_lcl_acc(const char *options) {
-	struct irs_acc *acc;
-	struct lcl_p *lcl;
-
-	UNUSED(options);
-
-	if (!(acc = memget(sizeof *acc))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(acc, 0x5e, sizeof *acc);
-	if (!(lcl = memget(sizeof *lcl))) {
-		errno = ENOMEM;
-		free(acc);
-		return (NULL);
-	}
-	memset(lcl, 0x5e, sizeof *lcl);
-	lcl->res = NULL;
-	lcl->free_res = NULL;
-	acc->private = lcl;
-#ifdef WANT_IRS_GR
-	acc->gr_map = irs_lcl_gr;
-#else
-	acc->gr_map = NULL;
-#endif
-#ifdef WANT_IRS_PW
-	acc->pw_map = irs_lcl_pw;
-#else
-	acc->pw_map = NULL;
-#endif
-	acc->sv_map = irs_lcl_sv;
-	acc->pr_map = irs_lcl_pr;
-	acc->ho_map = irs_lcl_ho;
-	acc->nw_map = irs_lcl_nw;
-	acc->ng_map = irs_lcl_ng;
-	acc->res_get = lcl_res_get;
-	acc->res_set = lcl_res_set;
-	acc->close = lcl_close;
-	return (acc);
-}
-
-/* Methods */
-static struct __res_state *
-lcl_res_get(struct irs_acc *this) {
-	struct lcl_p *lcl = (struct lcl_p *)this->private;
-
-	if (lcl->res == NULL) {
-		struct __res_state *res;
-		res = (struct __res_state *)malloc(sizeof *res);
-		if (res == NULL)
-			return (NULL);
-		memset(res, 0, sizeof *res);
-		lcl_res_set(this, res, free);
-	}
-
-	if ((lcl->res->options & RES_INIT) == 0U &&
-	    res_ninit(lcl->res) < 0)
-		return (NULL);
-
-	return (lcl->res);
-}
-
-static void
-lcl_res_set(struct irs_acc *this, struct __res_state *res,
-		void (*free_res)(void *)) {
-	struct lcl_p *lcl = (struct lcl_p *)this->private;
-
-	if (lcl->res && lcl->free_res) {
-		res_nclose(lcl->res);
-		(*lcl->free_res)(lcl->res);
-	}
-
-	lcl->res = res;
-	lcl->free_res = free_res;
-}
-
-static void
-lcl_close(struct irs_acc *this) {
-	struct lcl_p *lcl = (struct lcl_p *)this->private;
-
-	if (lcl) {
-		if (lcl->free_res)
-			(*lcl->free_res)(lcl->res);
-		memput(lcl, sizeof *lcl);
-	}
-	memput(this, sizeof *this);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/lcl_gr.c b/contrib/bind9/lib/bind/irs/lcl_gr.c
deleted file mode 100644
index f17410c..0000000
--- a/contrib/bind9/lib/bind/irs/lcl_gr.c
+++ /dev/null
@@ -1,354 +0,0 @@
-/*
- * Copyright (c) 1989, 1993, 1995
- *	The Regents of the University of California.  All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- *	This product includes software developed by the University of
- *	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: lcl_gr.c,v 1.2.18.1 2005/04/27 05:01:02 sra Exp $";
-/* from getgrent.c 8.2 (Berkeley) 3/21/94"; */
-/* from BSDI Id: getgrent.c,v 2.8 1996/05/28 18:15:14 bostic Exp $	*/
-#endif /* LIBC_SCCS and not lint */
-
-/* extern */
-
-#include "port_before.h"
-
-#ifndef WANT_IRS_PW
-static int __bind_irs_gr_unneeded;
-#else
-
-#include <sys/param.h>
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <resolv.h>
-
-#include <errno.h>
-#include <fcntl.h>
-#include <grp.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <unistd.h>
-
-#include <irs.h>
-#include <isc/memcluster.h>
-
-#include "irs_p.h"
-#include "lcl_p.h"
-#include "irp_p.h"
-
-#include "port_after.h"
-
-
-/* Types. */
-
-struct pvt {
-	FILE *		fp;
-	/*%<
-	 * Need space to store the entries read from the group file.
-	 * The members list also needs space per member, and the
-	 * strings making up the user names must be allocated
-	 * somewhere.  Rather than doing lots of small allocations,
-	 * we keep one buffer and resize it as needed.
-	 */
-	struct group	group;
-	size_t		nmemb;		/*%< Malloc'd max index of gr_mem[]. */
-	char *		membuf;
-	size_t		membufsize;
-};
-
-/* Forward. */
-
-static void		gr_close(struct irs_gr *);
-static struct group *	gr_next(struct irs_gr *);
-static struct group *	gr_byname(struct irs_gr *, const char *);
-static struct group *	gr_bygid(struct irs_gr *, gid_t);
-static void		gr_rewind(struct irs_gr *);
-static void		gr_minimize(struct irs_gr *);
-
-static int		grstart(struct pvt *);
-static char *		grnext(struct pvt *);
-static struct group *	grscan(struct irs_gr *, int, gid_t, const char *);
-
-/* Portability. */
-
-#ifndef SEEK_SET
-# define SEEK_SET 0
-#endif
-
-/* Public. */
-
-struct irs_gr *
-irs_lcl_gr(struct irs_acc *this) {
-	struct irs_gr *gr;
-	struct pvt *pvt;
-
-	UNUSED(this);
-
-	if (!(gr = memget(sizeof *gr))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(gr, 0x5e, sizeof *gr);
-	if (!(pvt = memget(sizeof *pvt))) {
-		memput(gr, sizeof *gr);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	gr->private = pvt;
-	gr->close = gr_close;
-	gr->next = gr_next;
-	gr->byname = gr_byname;
-	gr->bygid = gr_bygid;
-	gr->rewind = gr_rewind;
-	gr->list = make_group_list;
-	gr->minimize = gr_minimize;
-	gr->res_get = NULL;
-	gr->res_set = NULL;
-	return (gr);
-}
-
-/* Methods. */
-
-static void
-gr_close(struct irs_gr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (pvt->fp)
-		(void)fclose(pvt->fp);
-	if (pvt->group.gr_mem)
-		free(pvt->group.gr_mem);
-	if (pvt->membuf)
-		free(pvt->membuf);
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-static struct group *
-gr_next(struct irs_gr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (!pvt->fp && !grstart(pvt))
-		return (NULL);
-	return (grscan(this, 0, 0, NULL));
-}
-
-static struct group *
-gr_byname(struct irs_gr *this, const char *name) {
-	if (!grstart((struct pvt *)this->private))
-		return (NULL);
-	return (grscan(this, 1, 0, name));
-}
-
-static struct group *
-gr_bygid(struct irs_gr *this, gid_t gid) {
-	if (!grstart((struct pvt *)this->private))
-		return (NULL);
-	return (grscan(this, 1, gid, NULL));
-}
-
-static void
-gr_rewind(struct irs_gr *this) {
-	(void) grstart((struct pvt *)this->private);
-}
-
-static void
-gr_minimize(struct irs_gr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (pvt->fp != NULL) {
-		(void)fclose(pvt->fp);
-		pvt->fp = NULL;
-	}
-}
-
-/* Private. */
-
-static int
-grstart(struct pvt *pvt) {
-	if (pvt->fp) {
-		if (fseek(pvt->fp, 0L, SEEK_SET) == 0)
-			return (1);
-		(void)fclose(pvt->fp);
-	}
-	if (!(pvt->fp = fopen(_PATH_GROUP, "r")))
-		return (0);
-	if (fcntl(fileno(pvt->fp), F_SETFD, 1) < 0) {
-		fclose(pvt->fp);
-		return (0);
-	}
-	return (1);
-}
-
-#define	INITIAL_NMEMB	30			/*%< about 120 bytes */
-#define	INITIAL_BUFSIZ	(INITIAL_NMEMB * 8)	/*%< about 240 bytes */
-static char *
-grnext(struct pvt *pvt) {
-	char *w, *e;
-	int ch;
-
-	/* Make sure we have a buffer. */
-	if (pvt->membuf == NULL) {
-		pvt->membuf = malloc(INITIAL_BUFSIZ);
-		if (pvt->membuf == NULL) {
- enomem:
-			errno = ENOMEM;
-			return (NULL);
-		}
-		pvt->membufsize = INITIAL_BUFSIZ;
-	}
-
-	/* Read until EOF or EOL. */
-	w = pvt->membuf;
-	e = pvt->membuf + pvt->membufsize;
-	while ((ch = fgetc(pvt->fp)) != EOF && ch != '\n') {
-		/* Make sure we have room for this character and a \0. */
-		if (w + 1 == e) {
-			size_t o = w - pvt->membuf;
-			size_t n = pvt->membufsize * 2;
-			char *t = realloc(pvt->membuf, n);
-
-			if (t == NULL)
-				goto enomem;
-			pvt->membuf = t;
-			pvt->membufsize = n;
-			w = pvt->membuf + o;
-			e = pvt->membuf + pvt->membufsize;
-		}
-		/* Store it. */
-		*w++ = (char)ch;
-	}
-
-	/* Hitting EOF on the first character really does mean EOF. */
-	if (w == pvt->membuf && ch == EOF) {
-		errno = ENOENT;
-		return (NULL);
-	}
-
-	/* Last line of /etc/group need not end with \n; we don't care. */
-	*w = '\0';
-	return (pvt->membuf);
-}
-
-static struct group *
-grscan(struct irs_gr *this, int search, gid_t gid, const char *name) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	size_t n;
-	char *bp, **m, *p;
-
-	/* Read lines until we find one that matches our search criteria. */
-	for (;;) {
-		if ((bp = grnext(pvt)) == NULL)
-			return (NULL);
-
-		/* Optimize the usual case of searching for a name. */
-		pvt->group.gr_name = strsep(&bp, ":");
-		if (search && name != NULL &&
-		    strcmp(pvt->group.gr_name, name) != 0)
-			continue;
-		if (bp == NULL || *bp == '\0')
-			goto corrupt;
-
-		/* Skip past the password field. */
-		pvt->group.gr_passwd = strsep(&bp, ":");
-		if (bp == NULL || *bp == '\0')
-			goto corrupt;
-
-		/* Checking for a gid. */
-		if ((p = strsep(&bp, ":")) == NULL)
-			continue;
-		/*
-		 * Unlike the tests above, the test below is supposed to be
-		 * testing 'p' and not 'bp', in case you think it's a typo.
-		 */
-		if (p == NULL || *p == '\0') {
- corrupt:
-			/* warning: corrupted %s file!", _PATH_GROUP */
-			continue;
-		}
-		pvt->group.gr_gid = atoi(p);
-		if (search && name == NULL && (gid_t)pvt->group.gr_gid != gid)
-			continue;
-
-		/* We want this record. */
-		break;
-	}
-
-	/*
-	 * Count commas to find out how many members there might be.
-	 * Note that commas separate, so if there is one comma there
-	 * can be two members (group:*:id:user1,user2).  Add another
-	 * to account for the NULL terminator.  As above, allocate
-	 * largest of INITIAL_NMEMB, or 2*n.
-	 */
-	n = 1;
-	if (bp != NULL)
-		for (n = 2, p = bp; (p = strpbrk(p, ", ")) != NULL; ++n)
-			p += strspn(p, ", ");
-	if (n > pvt->nmemb || pvt->group.gr_mem == NULL) {
-		if ((n *= 2) < INITIAL_NMEMB)
-			n = INITIAL_NMEMB;
-		if ((m = realloc(pvt->group.gr_mem, n * sizeof *m)) == NULL)
-			return (NULL);
-		pvt->group.gr_mem = m;
-		pvt->nmemb = n;
-	}
-
-	/* Set the name pointers. */
-	for (m = pvt->group.gr_mem; (p = strsep(&bp, ", ")) != NULL;)
-		if (p[0] != '\0')
-			*m++ = p;
-	*m = NULL;
-
-	return (&pvt->group);
-}
-
-#endif /* WANT_IRS_GR */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/lcl_ho.c b/contrib/bind9/lib/bind/irs/lcl_ho.c
deleted file mode 100644
index 9534ee6..0000000
--- a/contrib/bind9/lib/bind/irs/lcl_ho.c
+++ /dev/null
@@ -1,578 +0,0 @@
-/*
- * Copyright (c) 1985, 1988, 1993
- *    The Regents of the University of California.  All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- * 	This product includes software developed by the University of
- * 	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-/* from gethostnamadr.c	8.1 (Berkeley) 6/4/93 */
-/* 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: lcl_ho.c,v 1.3.18.2 2006/03/10 00:20:08 marka Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-/* Imports. */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/param.h>
-#include <sys/socket.h>
-
-#include <netinet/in.h>
-#include <arpa/inet.h>
-#include <arpa/nameser.h>
-
-#include <ctype.h>
-#include <errno.h>
-#include <fcntl.h>
-#include <netdb.h>
-#include <resolv.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-
-#include <irs.h>
-#include <isc/memcluster.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "dns_p.h"
-#include "lcl_p.h"
-
-#ifdef SPRINTF_CHAR
-# define SPRINTF(x) strlen(sprintf/**/x)
-#else
-# define SPRINTF(x) sprintf x
-#endif
-
-/* Definitions. */
-
-#define	MAXALIASES	35
-#define	MAXADDRS	35
-#define	Max(a,b)	((a) > (b) ? (a) : (b))
-
-#if PACKETSZ > 1024
-#define	MAXPACKET	PACKETSZ
-#else
-#define	MAXPACKET	1024
-#endif
-
-struct pvt {
-	FILE *		fp;
-	struct hostent	host;
-	char *		h_addr_ptrs[MAXADDRS + 1];
-	char *		host_aliases[MAXALIASES];
-	char		hostbuf[8*1024];
-	u_char		host_addr[16];	/*%< IPv4 or IPv6 */
-	struct __res_state  *res;
-	void		(*free_res)(void *);
-};
-
-typedef union {
-	int32_t al;
-	char ac;
-} align;
-
-static const u_char mapped[] = { 0,0, 0,0, 0,0, 0,0, 0,0, 0xff,0xff };
-static const u_char tunnelled[] = { 0,0, 0,0, 0,0, 0,0, 0,0, 0,0 };
-
-/* Forward. */
-
-static void		ho_close(struct irs_ho *this);
-static struct hostent *	ho_byname(struct irs_ho *this, const char *name);
-static struct hostent *	ho_byname2(struct irs_ho *this, const char *name,
-				   int af);
-static struct hostent *	ho_byaddr(struct irs_ho *this, const void *addr,
-				  int len, int af);
-static struct hostent *	ho_next(struct irs_ho *this);
-static void		ho_rewind(struct irs_ho *this);
-static void		ho_minimize(struct irs_ho *this);
-static struct __res_state * ho_res_get(struct irs_ho *this);
-static void		ho_res_set(struct irs_ho *this,
-				   struct __res_state *res,
-				   void (*free_res)(void *));
-static struct addrinfo * ho_addrinfo(struct irs_ho *this, const char *name,
-				     const struct addrinfo *pai);
-
-static size_t		ns_namelen(const char *);
-static int		init(struct irs_ho *this);
-
-/* Portability. */
-
-#ifndef SEEK_SET
-# define SEEK_SET 0
-#endif
-
-/* Public. */
-
-struct irs_ho *
-irs_lcl_ho(struct irs_acc *this) {
-	struct irs_ho *ho;
-	struct pvt *pvt;
-
-	UNUSED(this);
-
-	if (!(pvt = memget(sizeof *pvt))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	if (!(ho = memget(sizeof *ho))) {
-		memput(pvt, sizeof *pvt);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(ho, 0x5e, sizeof *ho);
-	ho->private = pvt;
-	ho->close = ho_close;
-	ho->byname = ho_byname;
-	ho->byname2 = ho_byname2;
-	ho->byaddr = ho_byaddr;
-	ho->next = ho_next;
-	ho->rewind = ho_rewind;
-	ho->minimize = ho_minimize;
-	ho->res_get = ho_res_get;
-	ho->res_set = ho_res_set;
-	ho->addrinfo = ho_addrinfo;
-	return (ho);
-}
-
-/* Methods. */
-
-static void
-ho_close(struct irs_ho *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	ho_minimize(this);
-	if (pvt->fp)
-		(void) fclose(pvt->fp);
-	if (pvt->res && pvt->free_res)
-		(*pvt->free_res)(pvt->res);
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-static struct hostent *
-ho_byname(struct irs_ho *this, const char *name) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct hostent *hp;
-
-	if (init(this) == -1)
-		return (NULL);
-
-	if (pvt->res->options & RES_USE_INET6) {
-		hp = ho_byname2(this, name, AF_INET6);
-		if (hp)
-			return (hp);
-	}
-	return (ho_byname2(this, name, AF_INET));
-}
-
-static struct hostent *
-ho_byname2(struct irs_ho *this, const char *name, int af) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct hostent *hp;
-	char **hap;
-	size_t n;
-	
-	if (init(this) == -1)
-		return (NULL);
-
-	ho_rewind(this);
-	n = ns_namelen(name);
-	while ((hp = ho_next(this)) != NULL) {
-		size_t nn;
-
-		if (hp->h_addrtype != af)
-			continue;
-		nn = ns_namelen(hp->h_name);
-		if (strncasecmp(hp->h_name, name, Max(n, nn)) == 0)
-			goto found;
-		for (hap = hp->h_aliases; *hap; hap++) {
-			nn = ns_namelen(*hap);
-			if (strncasecmp(*hap, name, Max(n, nn)) == 0)
-				goto found;
-		}
-	}
- found:
-	if (!hp) {
-		RES_SET_H_ERRNO(pvt->res, HOST_NOT_FOUND);
-		return (NULL);
-	}
-	RES_SET_H_ERRNO(pvt->res, NETDB_SUCCESS);
-	return (hp);
-}
-
-static struct hostent *
-ho_byaddr(struct irs_ho *this, const void *addr, int len, int af) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	const u_char *uaddr = addr;
-	struct hostent *hp;
-	int size;
-	
-	if (init(this) == -1)
-		return (NULL);
-
-	if (af == AF_INET6 && len == IN6ADDRSZ &&
-	    (!memcmp(uaddr, mapped, sizeof mapped) ||
-	     !memcmp(uaddr, tunnelled, sizeof tunnelled))) {
-		/* Unmap. */
-		addr = (const u_char *)addr + sizeof mapped;
-		uaddr += sizeof mapped;
-		af = AF_INET;
-		len = INADDRSZ;
-	}
-	switch (af) {
-	case AF_INET:
-		size = INADDRSZ;
-		break;
-	case AF_INET6:
-		size = IN6ADDRSZ;
-		break;
-	default:
-		errno = EAFNOSUPPORT;
-		RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL);
-		return (NULL);
-	}
-	if (size > len) {
-		errno = EINVAL;
-		RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL);
-		return (NULL);
-	}
-
-	/*
-	 * Do the search.
-	 */
-	ho_rewind(this);
-	while ((hp = ho_next(this)) != NULL) {
-		char **hap;
-
-		for (hap = hp->h_addr_list; *hap; hap++) {
-			const u_char *taddr = (const u_char *)*hap;
-			int taf = hp->h_addrtype;
-			int tlen = hp->h_length;
-
-			if (taf == AF_INET6 && tlen == IN6ADDRSZ &&
-			    (!memcmp(taddr, mapped, sizeof mapped) ||
-			     !memcmp(taddr, tunnelled, sizeof tunnelled))) {
-				/* Unmap. */
-				taddr += sizeof mapped;
-				taf = AF_INET;
-				tlen = INADDRSZ;
-			}
-			if (taf == af && tlen == len &&
-			    !memcmp(taddr, uaddr, tlen))
-				goto found;
-		}
-	}
- found:
-	if (!hp) {
-		RES_SET_H_ERRNO(pvt->res, HOST_NOT_FOUND);
-		return (NULL);
-	}
-	RES_SET_H_ERRNO(pvt->res, NETDB_SUCCESS);
-	return (hp);
-}
-
-static struct hostent *
-ho_next(struct irs_ho *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	char *cp, **q, *p;
-	char *bufp, *ndbuf, *dbuf = NULL;
-	int c, af, len, bufsiz, offset;
-
-	if (init(this) == -1)
-		return (NULL);
-
-	if (!pvt->fp)
-		ho_rewind(this);
-	if (!pvt->fp) {
-		RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL);
-		return (NULL);
-	}
-	bufp = pvt->hostbuf;
-	bufsiz = sizeof pvt->hostbuf;
-	offset = 0;
- again:
-	if (!(p = fgets(bufp + offset, bufsiz - offset, pvt->fp))) {
-		RES_SET_H_ERRNO(pvt->res, HOST_NOT_FOUND);
-		if (dbuf)
-			free(dbuf);
-		return (NULL);
-	}
-	if (!strchr(p, '\n') && !feof(pvt->fp)) {
-#define GROWBUF 1024
-		/* allocate space for longer line */
-		if (dbuf == NULL) {
-			if ((ndbuf = malloc(bufsiz + GROWBUF)) != NULL)
-				strcpy(ndbuf, bufp);
-		} else
-			ndbuf = realloc(dbuf, bufsiz + GROWBUF);
-		if (ndbuf) {
-			dbuf = ndbuf;
-			bufp = dbuf;
-			bufsiz += GROWBUF;
-			offset = strlen(dbuf);
-		} else {
-			/* allocation failed; skip this long line */
-			while ((c = getc(pvt->fp)) != EOF)
-				if (c == '\n')
-					break;
-			if (c != EOF)
-				ungetc(c, pvt->fp);
-		}
-		goto again;
-	}
-
-	p -= offset;
-	offset = 0;
-
-	if (*p == '#')
-		goto again;
-	if ((cp = strpbrk(p, "#\n")) != NULL)
-		*cp = '\0';
-	if (!(cp = strpbrk(p, " \t")))
-		goto again;
-	*cp++ = '\0';
-	if (inet_pton(AF_INET6, p, pvt->host_addr) > 0) {
-		af = AF_INET6;
-		len = IN6ADDRSZ;
-	} else if (inet_aton(p, (struct in_addr *)pvt->host_addr) > 0) {
-		if (pvt->res->options & RES_USE_INET6) {
-			map_v4v6_address((char*)pvt->host_addr,
-					 (char*)pvt->host_addr);
-			af = AF_INET6;
-			len = IN6ADDRSZ;
-		} else {
-			af = AF_INET;
-			len = INADDRSZ;
-		}
-	} else {
-		goto again;
-	}
-	pvt->h_addr_ptrs[0] = (char *)pvt->host_addr;
-	pvt->h_addr_ptrs[1] = NULL;
-	pvt->host.h_addr_list = pvt->h_addr_ptrs;
-	pvt->host.h_length = len;
-	pvt->host.h_addrtype = af;
-	while (*cp == ' ' || *cp == '\t')
-		cp++;
-	pvt->host.h_name = cp;
-	q = pvt->host.h_aliases = pvt->host_aliases;
-	if ((cp = strpbrk(cp, " \t")) != NULL)
-		*cp++ = '\0';
-	while (cp && *cp) {
-		if (*cp == ' ' || *cp == '\t') {
-			cp++;
-			continue;
-		}
-		if (q < &pvt->host_aliases[MAXALIASES - 1])
-			*q++ = cp;
-		if ((cp = strpbrk(cp, " \t")) != NULL)
-			*cp++ = '\0';
-	}
-	*q = NULL;
-	if (dbuf)
-		free(dbuf);
-	RES_SET_H_ERRNO(pvt->res, NETDB_SUCCESS);
-	return (&pvt->host);
-}
-
-static void
-ho_rewind(struct irs_ho *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (pvt->fp) {
-		if (fseek(pvt->fp, 0L, SEEK_SET) == 0)
-			return;
-		(void)fclose(pvt->fp);
-	}
-	if (!(pvt->fp = fopen(_PATH_HOSTS, "r")))
-		return;
-	if (fcntl(fileno(pvt->fp), F_SETFD, 1) < 0) {
-		(void)fclose(pvt->fp);
-		pvt->fp = NULL;
-	}
-}
-
-static void
-ho_minimize(struct irs_ho *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (pvt->fp != NULL) {
-		(void)fclose(pvt->fp);
-		pvt->fp = NULL;
-	}
-	if (pvt->res)
-		res_nclose(pvt->res);
-} 
-
-static struct __res_state *
-ho_res_get(struct irs_ho *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (!pvt->res) {
-		struct __res_state *res;
-		res = (struct __res_state *)malloc(sizeof *res);
-		if (!res) {
-			errno = ENOMEM;
-			return (NULL);
-		}
-		memset(res, 0, sizeof *res);
-		ho_res_set(this, res, free);
-	}
-
-	return (pvt->res);
-}
-
-static void
-ho_res_set(struct irs_ho *this, struct __res_state *res,
-		void (*free_res)(void *)) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (pvt->res && pvt->free_res) {
-		res_nclose(pvt->res);
-		(*pvt->free_res)(pvt->res);
-	}
-
-	pvt->res = res;
-	pvt->free_res = free_res;
-}
-
-struct lcl_res_target {
-	struct lcl_res_target *next;
-	int family;
-};
-
-/* XXX */
-extern struct addrinfo *hostent2addrinfo __P((struct hostent *,
-					      const struct addrinfo *pai));
-
-static struct addrinfo *
-ho_addrinfo(struct irs_ho *this, const char *name, const struct addrinfo *pai)
-{
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct hostent *hp;
-	struct lcl_res_target q, q2, *p;
-	struct addrinfo sentinel, *cur;
-
-	memset(&q, 0, sizeof(q2));
-	memset(&q2, 0, sizeof(q2));
-	memset(&sentinel, 0, sizeof(sentinel));
-	cur = &sentinel;
-
-	switch(pai->ai_family) {
-	case AF_UNSPEC:		/*%< INET6 then INET4 */
-		q.family = AF_INET6;
-		q.next = &q2;
-		q2.family = AF_INET;
-		break;
-	case AF_INET6:
-		q.family = AF_INET6;
-		break;
-	case AF_INET:
-		q.family = AF_INET;
-		break;
-	default:
-		RES_SET_H_ERRNO(pvt->res, NO_RECOVERY); /*%< ??? */
-		return(NULL);
-	}
-
-	for (p = &q; p; p = p->next) {
-		struct addrinfo *ai;
-
-		hp = (*this->byname2)(this, name, p->family);
-		if (hp == NULL) {
-			/* byname2 should've set an appropriate error */
-			continue;
-		}
-		if ((hp->h_name == NULL) || (hp->h_name[0] == 0) ||
-		    (hp->h_addr_list[0] == NULL)) {
-			RES_SET_H_ERRNO(pvt->res, NO_RECOVERY);
-			continue;
-		}
-
-		ai = hostent2addrinfo(hp, pai);
-		if (ai) {
-			cur->ai_next = ai;
-			while (cur->ai_next)
-				cur = cur->ai_next;
-		}
-	}
-
-	if (sentinel.ai_next == NULL)
-		RES_SET_H_ERRNO(pvt->res, HOST_NOT_FOUND);
-
-	return(sentinel.ai_next);
-}
-
-/* Private. */
-
-static size_t
-ns_namelen(const char *s) {
-	int i;
-
-	for (i = strlen(s); i > 0 && s[i-1] == '.'; i--)
-		(void)NULL;
-	return ((size_t) i);
-}
-
-static int
-init(struct irs_ho *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	
-	if (!pvt->res && !ho_res_get(this))
-		return (-1);
-	if (((pvt->res->options & RES_INIT) == 0U) &&
-	    res_ninit(pvt->res) == -1)
-		return (-1);
-	return (0);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/lcl_ng.c b/contrib/bind9/lib/bind/irs/lcl_ng.c
deleted file mode 100644
index 3a9f3fa..0000000
--- a/contrib/bind9/lib/bind/irs/lcl_ng.c
+++ /dev/null
@@ -1,446 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996-1999 by 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.
- */
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: lcl_ng.c,v 1.2.18.1 2005/04/27 05:01:02 sra Exp $";
-#endif
-
-/* Imports */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <resolv.h>
-#include <errno.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <unistd.h>
-
-#include <irs.h>
-#include <isc/memcluster.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "lcl_p.h"
-
-/* Definitions */
-
-#define NG_HOST         0       /*%< Host name */
-#define NG_USER         1       /*%< User name */
-#define NG_DOM          2       /*%< and Domain name */
-#define LINSIZ		1024    /*%< Length of netgroup file line */
-/*
- * XXX Warning XXX
- * This code is a hack-and-slash special.  It realy needs to be
- * rewritten with things like strdup, and realloc in mind.
- * More reasonable data structures would not be a bad thing.
- */
-
-/*%
- * Static Variables and functions used by setnetgrent(), getnetgrent() and
- * endnetgrent().
- *
- * There are two linked lists:
- * \li linelist is just used by setnetgrent() to parse the net group file via.
- *   parse_netgrp()
- * \li netgrp is the list of entries for the current netgroup
- */
-struct linelist {
-	struct linelist *l_next;	/*%< Chain ptr. */
-	int		l_parsed;	/*%< Flag for cycles */
-	char *		l_groupname;	/*%< Name of netgroup */
-	char *		l_line;		/*%< Netgroup entrie(s) to be parsed */
-};
-
-struct ng_old_struct {
-	struct ng_old_struct *ng_next;	/*%< Chain ptr */
-	char *		ng_str[3];	/*%< Field pointers, see below */
-};
-
-struct pvt {
-	FILE			*fp;
-	struct linelist		*linehead;
-	struct ng_old_struct    *nextgrp;
-	struct {
-		struct ng_old_struct	*gr;
-		char			*grname;
-	} grouphead;
-};
-
-/* Forward */
-
-static void 		ng_rewind(struct irs_ng *, const char*);
-static void 		ng_close(struct irs_ng *);
-static int		ng_next(struct irs_ng *, const char **,
-				const char **, const char **);
-static int 		ng_test(struct irs_ng *, const char *,
-				const char *, const char *,
-				const char *);
-static void		ng_minimize(struct irs_ng *);
-
-static int 		parse_netgrp(struct irs_ng *, const char*);
-static struct linelist *read_for_group(struct irs_ng *, const char *);
-static void		freelists(struct irs_ng *);
-
-/* Public */
-
-struct irs_ng *
-irs_lcl_ng(struct irs_acc *this) {
-	struct irs_ng *ng;
-	struct pvt *pvt;
-
-	UNUSED(this);
-	
-	if (!(ng = memget(sizeof *ng))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(ng, 0x5e, sizeof *ng);
-	if (!(pvt = memget(sizeof *pvt))) {
-		memput(ng, sizeof *ng);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	ng->private = pvt;
-	ng->close = ng_close;
-	ng->next = ng_next;
-	ng->test = ng_test;
-	ng->rewind = ng_rewind;
-	ng->minimize = ng_minimize;
-	return (ng);
-}
-
-/* Methods */
-
-static void
-ng_close(struct irs_ng *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	
-	if (pvt->fp != NULL)
-		fclose(pvt->fp);
-	freelists(this);
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-	
-/*%
- * Parse the netgroup file looking for the netgroup and build the list
- * of netgrp structures. Let parse_netgrp() and read_for_group() do
- * most of the work.
- */
-static void
-ng_rewind(struct irs_ng *this, const char *group) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	
-	if (pvt->fp != NULL && fseek(pvt->fp, SEEK_CUR, 0L) == -1) {
-		fclose(pvt->fp);
-		pvt->fp = NULL;
-	}
-
-	if (pvt->fp == NULL || pvt->grouphead.gr == NULL || 
-	    strcmp(group, pvt->grouphead.grname)) {
-		freelists(this);
-		if (pvt->fp != NULL)
-			fclose(pvt->fp);
-		pvt->fp = fopen(_PATH_NETGROUP, "r");
-		if (pvt->fp != NULL) {
-			if (parse_netgrp(this, group))
-				freelists(this);
-			if (!(pvt->grouphead.grname = strdup(group)))
-				freelists(this);
-			fclose(pvt->fp);
-			pvt->fp = NULL;
-		}
-	}
-	pvt->nextgrp = pvt->grouphead.gr;
-}
-
-/*%
- * Get the next netgroup off the list.
- */
-static int
-ng_next(struct irs_ng *this, const char **host, const char **user,
-	const char **domain)
-{
-	struct pvt *pvt = (struct pvt *)this->private;
-	
-	if (pvt->nextgrp) {
-		*host = pvt->nextgrp->ng_str[NG_HOST];
-		*user = pvt->nextgrp->ng_str[NG_USER];
-		*domain = pvt->nextgrp->ng_str[NG_DOM];
-		pvt->nextgrp = pvt->nextgrp->ng_next;
-		return (1);
-	}
-	return (0);
-}
-
-/*%
- * Search for a match in a netgroup.
- */
-static int
-ng_test(struct irs_ng *this, const char *name,
-	const char *host, const char *user, const char *domain)
-{
-	const char *ng_host, *ng_user, *ng_domain;
-
-	ng_rewind(this, name);
-	while (ng_next(this, &ng_host, &ng_user, &ng_domain))
-		if ((host == NULL || ng_host == NULL || 
-		     !strcmp(host, ng_host)) &&
-		    (user ==  NULL || ng_user == NULL || 
-		     !strcmp(user, ng_user)) &&
-		    (domain == NULL || ng_domain == NULL ||
-		     !strcmp(domain, ng_domain))) {
-			freelists(this);
-			return (1);
-		}
-	freelists(this);
-	return (0);
-}
-
-static void
-ng_minimize(struct irs_ng *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (pvt->fp != NULL) {
-		(void)fclose(pvt->fp);
-		pvt->fp = NULL;
-	}
-}
-
-/* Private */
-
-/*%
- * endnetgrent() - cleanup
- */
-static void
-freelists(struct irs_ng *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct linelist *lp, *olp;
-	struct ng_old_struct *gp, *ogp;
-
-	lp = pvt->linehead;
-	while (lp) {
-		olp = lp;
-		lp = lp->l_next;
-		free(olp->l_groupname);
-		free(olp->l_line);
-		free((char *)olp);
-	}
-	pvt->linehead = NULL;
-	if (pvt->grouphead.grname) {
-		free(pvt->grouphead.grname);
-		pvt->grouphead.grname = NULL;
-	}
-	gp = pvt->grouphead.gr;
-	while (gp) {
-		ogp = gp;
-		gp = gp->ng_next;
-		if (ogp->ng_str[NG_HOST])
-			free(ogp->ng_str[NG_HOST]);
-		if (ogp->ng_str[NG_USER])
-			free(ogp->ng_str[NG_USER]);
-		if (ogp->ng_str[NG_DOM])
-			free(ogp->ng_str[NG_DOM]);
-		free((char *)ogp);
-	}
-	pvt->grouphead.gr = NULL;
-}
-
-/*%
- * Parse the netgroup file setting up the linked lists.
- */
-static int
-parse_netgrp(struct irs_ng *this, const char *group) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	char *spos, *epos;
-	int len, strpos;
-	char *pos, *gpos;
-	struct ng_old_struct *grp;
-	struct linelist *lp = pvt->linehead;
-
-        /*
-         * First, see if the line has already been read in.
-         */
-	while (lp) {
-		if (!strcmp(group, lp->l_groupname))
-			break;
-		lp = lp->l_next;
-	}
-	if (lp == NULL &&
-	    (lp = read_for_group(this, group)) == NULL)
-		return (1);
-	if (lp->l_parsed) {
-		/*fprintf(stderr, "Cycle in netgroup %s\n", lp->l_groupname);*/
-		return (1);
-	} else
-		lp->l_parsed = 1;
-	pos = lp->l_line;
-	while (*pos != '\0') {
-		if (*pos == '(') {
-			if (!(grp = malloc(sizeof (struct ng_old_struct)))) {
-				freelists(this);
-				errno = ENOMEM;
-				return (1);
-			}
-			memset(grp, 0, sizeof (struct ng_old_struct));
-			grp->ng_next = pvt->grouphead.gr;
-			pvt->grouphead.gr = grp;
-			pos++;
-			gpos = strsep(&pos, ")");
-			for (strpos = 0; strpos < 3; strpos++) {
-				if ((spos = strsep(&gpos, ","))) {
-					while (*spos == ' ' || *spos == '\t')
-						spos++;
-					if ((epos = strpbrk(spos, " \t"))) {
-						*epos = '\0';
-						len = epos - spos;
-					} else
-						len = strlen(spos);
-					if (len > 0) {
-						if(!(grp->ng_str[strpos] 
-						   =  (char *)
-						   malloc(len + 1))) {
-							freelists(this);
-							return (1);
-						}
-						memcpy(grp->ng_str[strpos],
-						       spos,
-						       len + 1);
-					}
-				} else
-					goto errout;
-			}
-		} else {
-			spos = strsep(&pos, ", \t");
-			if (spos != NULL && parse_netgrp(this, spos)) {
-				freelists(this);
-				return (1);
-			}
-		}
-		if (pos == NULL)
-			break;
-		while (*pos == ' ' || *pos == ',' || *pos == '\t')
-			pos++;
-	}
-	return (0);
- errout:
-	/*fprintf(stderr, "Bad netgroup %s at ..%s\n", lp->l_groupname,
-		  spos);*/
-	return (1);
-}
-
-/*%
- * Read the netgroup file and save lines until the line for the netgroup
- * is found. Return 1 if eof is encountered.
- */
-static struct linelist *
-read_for_group(struct irs_ng *this, const char *group) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	char *pos, *spos, *linep = NULL, *olinep;
-	int len, olen, cont;
-	struct linelist *lp;
-	char line[LINSIZ + 1];
-	
-	while (fgets(line, LINSIZ, pvt->fp) != NULL) {
-		pos = line;
-		if (*pos == '#')
-			continue;
-		while (*pos == ' ' || *pos == '\t')
-			pos++;
-		spos = pos;
-		while (*pos != ' ' && *pos != '\t' && *pos != '\n' &&
-			*pos != '\0')
-			pos++;
-		len = pos - spos;
-		while (*pos == ' ' || *pos == '\t')
-			pos++;
-		if (*pos != '\n' && *pos != '\0') {
-			if (!(lp = malloc(sizeof (*lp)))) {
-				freelists(this);
-				return (NULL);
-			}
-			lp->l_parsed = 0;
-			if (!(lp->l_groupname = malloc(len + 1))) {
-				free(lp);
-				freelists(this);
-				return (NULL);
-			}
-			memcpy(lp->l_groupname, spos,  len);
-			*(lp->l_groupname + len) = '\0';
-			len = strlen(pos);
-			olen = 0;
-			olinep = NULL;
-
-			/*
-			 * Loop around handling line continuations.
-			 */
-			do {
-				if (*(pos + len - 1) == '\n')
-					len--;
-				if (*(pos + len - 1) == '\\') {
-					len--;
-					cont = 1;
-				} else
-					cont = 0;
-				if (len > 0) {
-					if (!(linep = malloc(olen + len + 1))){
-						if (olen > 0)
-							free(olinep);
-						free(lp->l_groupname);
-						free(lp);
-						freelists(this);
-						errno = ENOMEM;
-						return (NULL);
-					}
-					if (olen > 0) {
-						memcpy(linep, olinep, olen);
-						free(olinep);
-					}
-					memcpy(linep + olen, pos, len);
-					olen += len;
-					*(linep + olen) = '\0';
-					olinep = linep;
-				}
-				if (cont) {
-					if (fgets(line, LINSIZ, pvt->fp)) {
-						pos = line;
-						len = strlen(pos);
-					} else
-						cont = 0;
-				}
-			} while (cont);
-			lp->l_line = linep;
-			lp->l_next = pvt->linehead;
-			pvt->linehead = lp;
-			
-			/*
-			 * If this is the one we wanted, we are done.
-			 */
-			if (!strcmp(lp->l_groupname, group))
-				return (lp);
-		}
-	}
-	return (NULL);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/lcl_nw.c b/contrib/bind9/lib/bind/irs/lcl_nw.c
deleted file mode 100644
index 2804946..0000000
--- a/contrib/bind9/lib/bind/irs/lcl_nw.c
+++ /dev/null
@@ -1,373 +0,0 @@
-/*
- * Copyright (c) 1989, 1993, 1995
- *	The Regents of the University of California.  All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- *	This product includes software developed by the University of
- *	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: lcl_nw.c,v 1.3.18.1 2005/04/27 05:01:02 sra Exp $";
-/* from getgrent.c 8.2 (Berkeley) 3/21/94"; */
-/* from BSDI Id: getgrent.c,v 2.8 1996/05/28 18:15:14 bostic Exp $	*/
-#endif /* LIBC_SCCS and not lint */
-
-/* Imports */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/socket.h>
-
-#include <netinet/in.h>
-#include <arpa/inet.h>
-#include <arpa/nameser.h>
-
-#include <errno.h>
-#include <fcntl.h>
-#include <resolv.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-
-#include <irs.h>
-#include <isc/memcluster.h>
-
-#include "port_after.h"
-
-#include <isc/misc.h>
-#include "irs_p.h"
-#include "lcl_p.h"
-
-#define MAXALIASES 35
-#define MAXADDRSIZE 4
-
-struct pvt {
-	FILE *		fp;
-	char 		line[BUFSIZ+1];
-	struct nwent 	net;
-	char *		aliases[MAXALIASES];
-	char		addr[MAXADDRSIZE];
-	struct __res_state *  res;
-	void		(*free_res)(void *);
-};
-
-/* Forward */
-
-static void 		nw_close(struct irs_nw *);
-static struct nwent *	nw_byname(struct irs_nw *, const char *, int);
-static struct nwent *	nw_byaddr(struct irs_nw *, void *, int, int);
-static struct nwent *	nw_next(struct irs_nw *);
-static void		nw_rewind(struct irs_nw *);
-static void		nw_minimize(struct irs_nw *);
-static struct __res_state * nw_res_get(struct irs_nw *this);
-static void		nw_res_set(struct irs_nw *this,
-				   struct __res_state *res,
-				   void (*free_res)(void *));
-
-static int		init(struct irs_nw *this);
-
-/* Portability. */
-
-#ifndef SEEK_SET
-# define SEEK_SET 0
-#endif
-
-/* Public */
-
-struct irs_nw *
-irs_lcl_nw(struct irs_acc *this) {
-	struct irs_nw *nw;
-	struct pvt *pvt;
-
-	UNUSED(this);
-
-	if (!(pvt = memget(sizeof *pvt))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	if (!(nw = memget(sizeof *nw))) {
-		memput(pvt, sizeof *pvt);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(nw, 0x5e, sizeof *nw);
-	nw->private = pvt;
-	nw->close = nw_close;
-	nw->byname = nw_byname;
-	nw->byaddr = nw_byaddr;
-	nw->next = nw_next;
-	nw->rewind = nw_rewind;
-	nw->minimize = nw_minimize;
-	nw->res_get = nw_res_get;
-	nw->res_set = nw_res_set;
-	return (nw);
-}
-
-/* Methods */
-
-static void
-nw_close(struct irs_nw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	
-	nw_minimize(this);
-	if (pvt->res && pvt->free_res)
-		(*pvt->free_res)(pvt->res);
-	if (pvt->fp)
-		(void)fclose(pvt->fp);
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-static struct nwent *
-nw_byaddr(struct irs_nw *this, void *net, int length, int type) {
-	struct nwent *p;
-	
-	if (init(this) == -1)
-		return(NULL);
-
-	nw_rewind(this);
-	while ((p = nw_next(this)) != NULL)
-		if (p->n_addrtype == type && p->n_length == length)
-			if (bitncmp(p->n_addr, net, length) == 0)
-				break;
-	return (p);
-}
-
-static struct nwent *
-nw_byname(struct irs_nw *this, const char *name, int type) {
-	struct nwent *p;
-	char **ap;
-	
-	if (init(this) == -1)
-		return(NULL);
-
-	nw_rewind(this);
-	while ((p = nw_next(this)) != NULL) {
-		if (ns_samename(p->n_name, name) == 1 &&
-		    p->n_addrtype == type)
-			break;
-		for (ap = p->n_aliases; *ap; ap++)
-			if ((ns_samename(*ap, name) == 1) &&
-			    (p->n_addrtype == type))
-				goto found;
-	}
- found:
-	return (p);
-}
-
-static void
-nw_rewind(struct irs_nw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	
-	if (pvt->fp) {
-		if (fseek(pvt->fp, 0L, SEEK_SET) == 0)
-			return;
-		(void)fclose(pvt->fp);
-	}
-	if (!(pvt->fp = fopen(_PATH_NETWORKS, "r")))
-		return;
-	if (fcntl(fileno(pvt->fp), F_SETFD, 1) < 0) {
-		(void)fclose(pvt->fp);
-		pvt->fp = NULL;
-	}
-}
-
-static struct nwent *
-nw_next(struct irs_nw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct nwent *ret = NULL;
-	char *p, *cp, **q;
-	char *bufp, *ndbuf, *dbuf = NULL;
-	int c, bufsiz, offset = 0;
-
-	if (init(this) == -1)
-		return(NULL);
-
-	if (pvt->fp == NULL)
-		nw_rewind(this);
-	if (pvt->fp == NULL) {
-		RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL);
-		return (NULL);
-	}
-	bufp = pvt->line;
-	bufsiz = sizeof(pvt->line);
-
- again:
-	p = fgets(bufp + offset, bufsiz - offset, pvt->fp);
-	if (p == NULL)
-		goto cleanup;
-	if (!strchr(p, '\n') && !feof(pvt->fp)) {
-#define GROWBUF 1024
-		/* allocate space for longer line */
-	  	if (dbuf == NULL) {
-			if ((ndbuf = malloc(bufsiz + GROWBUF)) != NULL)
-				strcpy(ndbuf, bufp);
-		} else
-			ndbuf = realloc(dbuf, bufsiz + GROWBUF);
-		if (ndbuf) {
-			dbuf = ndbuf;
-			bufp = dbuf;
-			bufsiz += GROWBUF;
-			offset = strlen(dbuf);
-		} else {
-			/* allocation failed; skip this long line */
-			while ((c = getc(pvt->fp)) != EOF)
-				if (c == '\n')
-					break;
-			if (c != EOF)
-				ungetc(c, pvt->fp);
-		}
-		goto again;
-	}
-
-	p -= offset;
-	offset = 0;
-
-	if (*p == '#')
-		goto again;
-
-	cp = strpbrk(p, "#\n");
-	if (cp != NULL)
-		*cp = '\0';
-	pvt->net.n_name = p;
-	cp = strpbrk(p, " \t");
-	if (cp == NULL)
-		goto again;
-	*cp++ = '\0';
-	while (*cp == ' ' || *cp == '\t')
-		cp++;
-	p = strpbrk(cp, " \t");
-	if (p != NULL)
-		*p++ = '\0';
-	pvt->net.n_length = inet_net_pton(AF_INET, cp, pvt->addr,
-					  sizeof pvt->addr);
-	if (pvt->net.n_length < 0)
-		goto again;
-	pvt->net.n_addrtype = AF_INET;
-	pvt->net.n_addr = pvt->addr;
-	q = pvt->net.n_aliases = pvt->aliases;
-	if (p != NULL) {
-		cp = p;
-		while (cp && *cp) {
-			if (*cp == ' ' || *cp == '\t') {
-				cp++;
-				continue;
-			}
-			if (q < &pvt->aliases[MAXALIASES - 1])
-				*q++ = cp;
-			cp = strpbrk(cp, " \t");
-			if (cp != NULL)
-				*cp++ = '\0';
-		}
-	}
-	*q = NULL;
-	ret = &pvt->net;
-
- cleanup:
-	if (dbuf)
-		free(dbuf);
-
-	return (ret);
-}
-
-static void
-nw_minimize(struct irs_nw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (pvt->res)
-		res_nclose(pvt->res);
-	if (pvt->fp != NULL) {
-		(void)fclose(pvt->fp);
-		pvt->fp = NULL;
-	}
-}
-
-static struct __res_state *
-nw_res_get(struct irs_nw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (!pvt->res) {
-		struct __res_state *res;
-		res = (struct __res_state *)malloc(sizeof *res);
-		if (!res) {
-			errno = ENOMEM;
-			return (NULL);
-		}
-		memset(res, 0, sizeof *res);
-		nw_res_set(this, res, free);
-	}
-
-	return (pvt->res);
-}
-
-static void
-nw_res_set(struct irs_nw *this, struct __res_state *res,
-		void (*free_res)(void *)) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (pvt->res && pvt->free_res) {
-		res_nclose(pvt->res);
-		(*pvt->free_res)(pvt->res);
-	}
-
-	pvt->res = res;
-	pvt->free_res = free_res;
-}
-
-static int
-init(struct irs_nw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	
-	if (!pvt->res && !nw_res_get(this))
-		return (-1);
-	if (((pvt->res->options & RES_INIT) == 0U) &&
-	    res_ninit(pvt->res) == -1)
-		return (-1);
-	return (0);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/lcl_p.h b/contrib/bind9/lib/bind/irs/lcl_p.h
deleted file mode 100644
index 4e6bdc3..0000000
--- a/contrib/bind9/lib/bind/irs/lcl_p.h
+++ /dev/null
@@ -1,51 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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: lcl_p.h,v 1.2.18.1 2005/04/27 05:01:02 sra Exp $
- */
-
-/*! \file
- * \brief
- * lcl_p.h - private include file for the local accessor functions.
- */
-
-#ifndef _LCL_P_H_INCLUDED
-#define _LCL_P_H_INCLUDED
-
-/*%
- * Object state.
- */
-struct lcl_p {
-	struct __res_state *	res;
-	void                    (*free_res) __P((void *));
-};
-
-/*
- * Externs.
- */
-
-extern struct irs_acc *	irs_lcl_acc __P((const char *));
-extern struct irs_gr *	irs_lcl_gr __P((struct irs_acc *));
-extern struct irs_pw *	irs_lcl_pw __P((struct irs_acc *));
-extern struct irs_sv *	irs_lcl_sv __P((struct irs_acc *));
-extern struct irs_pr *	irs_lcl_pr __P((struct irs_acc *));
-extern struct irs_ho *	irs_lcl_ho __P((struct irs_acc *));
-extern struct irs_nw *	irs_lcl_nw __P((struct irs_acc *));
-extern struct irs_ng *	irs_lcl_ng __P((struct irs_acc *));
-
-#endif /*_LCL_P_H_INCLUDED*/
diff --git a/contrib/bind9/lib/bind/irs/lcl_pr.c b/contrib/bind9/lib/bind/irs/lcl_pr.c
deleted file mode 100644
index 08c6da9..0000000
--- a/contrib/bind9/lib/bind/irs/lcl_pr.c
+++ /dev/null
@@ -1,294 +0,0 @@
-/*
- * Copyright (c) 1989, 1993, 1995
- *	The Regents of the University of California.  All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- *	This product includes software developed by the University of
- *	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: lcl_pr.c,v 1.2.18.2 2006/03/10 00:20:08 marka Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-/* extern */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <resolv.h>
-
-#include <errno.h>
-#include <fcntl.h>
-#include <string.h>
-#include <stdio.h>
-#include <stdlib.h>
-
-#include <irs.h>
-#include <isc/memcluster.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "lcl_p.h"
-
-#ifndef _PATH_PROTOCOLS
-#define _PATH_PROTOCOLS "/etc/protocols"
-#endif
-#define MAXALIASES      35
-
-/* Types */
-
-struct pvt {
-	FILE *		fp;
-	char		line[BUFSIZ+1];
-	char *		dbuf;
-	struct protoent	proto;
-	char *		proto_aliases[MAXALIASES];
-};
-
-/* Forward */
-
-static void			pr_close(struct irs_pr *);
-static struct protoent *	pr_next(struct irs_pr *);
-static struct protoent *	pr_byname(struct irs_pr *, const char *);
-static struct protoent *	pr_bynumber(struct irs_pr *, int);
-static void			pr_rewind(struct irs_pr *);
-static void			pr_minimize(struct irs_pr *);
-
-/* Portability. */
-
-#ifndef SEEK_SET
-# define SEEK_SET 0
-#endif
-
-/* Public */
-
-struct irs_pr *
-irs_lcl_pr(struct irs_acc *this) {
-	struct irs_pr *pr;
-	struct pvt *pvt;
-	
-	if (!(pr = memget(sizeof *pr))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	if (!(pvt = memget(sizeof *pvt))) {
-		memput(pr, sizeof *this);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	pr->private = pvt;
-	pr->close = pr_close;
-	pr->byname = pr_byname;
-	pr->bynumber = pr_bynumber;
-	pr->next = pr_next;
-	pr->rewind = pr_rewind;
-	pr->minimize = pr_minimize;
-	pr->res_get = NULL;
-	pr->res_set = NULL;
-	return (pr);
-}
-
-/* Methods */
-
-static void
-pr_close(struct irs_pr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (pvt->fp)
-		(void) fclose(pvt->fp);
-	if (pvt->dbuf)
-		free(pvt->dbuf);
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-static struct protoent *
-pr_byname(struct irs_pr *this, const char *name) {
-		
-	struct protoent *p;
-	char **cp;
-
-	pr_rewind(this);
-	while ((p = pr_next(this))) {
-		if (!strcmp(p->p_name, name))
-			goto found;
-		for (cp = p->p_aliases; *cp; cp++)
-			if (!strcmp(*cp, name))
-				goto found;
-	}
- found:
-	return (p);
-}
-
-static struct protoent *
-pr_bynumber(struct irs_pr *this, int proto) {
-	struct protoent *p;
-
-	pr_rewind(this);
-	while ((p = pr_next(this)))
-		if (p->p_proto == proto)
-			break;
-	return (p);
-}
-
-static void
-pr_rewind(struct irs_pr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	
-	if (pvt->fp) {
-		if (fseek(pvt->fp, 0L, SEEK_SET) == 0)
-			return;
-		(void)fclose(pvt->fp);
-	}
-	if (!(pvt->fp = fopen(_PATH_PROTOCOLS, "r" )))
-		return;
-	if (fcntl(fileno(pvt->fp), F_SETFD, 1) < 0) {
-		(void)fclose(pvt->fp);
-		pvt->fp = NULL;
-	}
-}
-
-static struct protoent *
-pr_next(struct irs_pr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	char *p, *cp, **q;
-	char *bufp, *ndbuf, *dbuf = NULL;
-	int c, bufsiz, offset;
-
-	if (!pvt->fp)
-		pr_rewind(this);
-	if (!pvt->fp)
-		return (NULL);
-	if (pvt->dbuf) {
-		free(pvt->dbuf);
-		pvt->dbuf = NULL;
-	}
-	bufp = pvt->line;
-	bufsiz = BUFSIZ;
-	offset = 0;
- again:
-	if ((p = fgets(bufp + offset, bufsiz - offset, pvt->fp)) == NULL) {
-		if (dbuf)
-			free(dbuf);
-		return (NULL);
-	}
-	if (!strchr(p, '\n') && !feof(pvt->fp)) {
-#define GROWBUF 1024
-		/* allocate space for longer line */
-		if (dbuf == NULL) {
-			if ((ndbuf = malloc(bufsiz + GROWBUF)) != NULL)
-				strcpy(ndbuf, bufp);
-		} else
-			ndbuf = realloc(dbuf, bufsiz + GROWBUF);
-		if (ndbuf) {
-			dbuf = ndbuf;
-			bufp = dbuf;
-			bufsiz += GROWBUF;
-			offset = strlen(dbuf);
-		} else {
-			/* allocation failed; skip this long line */
-			while ((c = getc(pvt->fp)) != EOF)
-				if (c == '\n')
-					break;
-			if (c != EOF)
-				ungetc(c, pvt->fp);
-		}
-		goto again;
-	}
-
-	p -= offset;
-	offset = 0;
-
-	if (*p == '#')
-		goto again;
-	cp = strpbrk(p, "#\n");
-	if (cp != NULL)
-		*cp = '\0';
-	pvt->proto.p_name = p;
-	cp = strpbrk(p, " \t");
-	if (cp == NULL)
-		goto again;
-	*cp++ = '\0';
-	while (*cp == ' ' || *cp == '\t')
-		cp++;
-	p = strpbrk(cp, " \t");
-	if (p != NULL)
-		*p++ = '\0';
-	pvt->proto.p_proto = atoi(cp);
-	q = pvt->proto.p_aliases = pvt->proto_aliases;
-	if (p != NULL) {
-		cp = p;
-		while (cp && *cp) {
-			if (*cp == ' ' || *cp == '\t') {
-				cp++;
-				continue;
-			}
-			if (q < &pvt->proto_aliases[MAXALIASES - 1])
-				*q++ = cp;
-			cp = strpbrk(cp, " \t");
-			if (cp != NULL)
-				*cp++ = '\0';
-		}
-	}
-	*q = NULL;
-	pvt->dbuf = dbuf;
-	return (&pvt->proto);
-}
-
-static void
-pr_minimize(struct irs_pr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (pvt->fp != NULL) {
-		(void)fclose(pvt->fp);
-		pvt->fp = NULL;
-	}
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/lcl_pw.c b/contrib/bind9/lib/bind/irs/lcl_pw.c
deleted file mode 100644
index 316057b..0000000
--- a/contrib/bind9/lib/bind/irs/lcl_pw.c
+++ /dev/null
@@ -1,309 +0,0 @@
-/*
- * Copyright (c) 1989, 1993, 1995
- *	The Regents of the University of California.  All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- *	This product includes software developed by the University of
- *	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: lcl_pw.c,v 1.2.18.1 2005/04/27 05:01:03 sra Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-/* Extern */
-
-#include "port_before.h"
-
-#ifndef WANT_IRS_PW
-static int __bind_irs_pw_unneeded;
-#else
-
-#include <sys/param.h>
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <resolv.h>
-
-#include <db.h>
-#include <errno.h>
-#include <fcntl.h>
-#include <limits.h>
-#include <pwd.h>
-#include <stdlib.h>
-#include <string.h>
-#include <syslog.h>
-#include <utmp.h>
-#include <unistd.h>
-
-#include <isc/memcluster.h>
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "lcl_p.h"
-
-/*! \file
- * \brief
- * The lookup techniques and data extraction code here must be kept
- * in sync with that in `pwd_mkdb'.
- */
- 
-
-/* Types */
-
-struct  pvt {
-	struct passwd	passwd;		/*%< password structure */
-	DB 		*pw_db;		/*%< password database */
-	int		pw_keynum;	/*%< key counter */
-	int		warned;
-	u_int		max;
-	char *		line;
-};
-
-/* Forward */
-
-static void			pw_close(struct irs_pw *);
-static struct passwd *		pw_next(struct irs_pw *);
-static struct passwd *		pw_byname(struct irs_pw *, const char *);
-static struct passwd *		pw_byuid(struct irs_pw *, uid_t);
-static void			pw_rewind(struct irs_pw *);
-static void			pw_minimize(struct irs_pw *);
-
-static int			initdb(struct pvt *);
-static int			hashpw(struct irs_pw *, DBT *);
-
-/* Public */
-struct irs_pw *
-irs_lcl_pw(struct irs_acc *this) {
-	struct irs_pw *pw;
-	struct pvt *pvt;
-
-	UNUSED(this);
-		 
-        if (!(pw = memget(sizeof *pw))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pw, 0x5e, sizeof *pw);
-	if (!(pvt = memget(sizeof *pvt))) {
-		free(pw);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	pw->private = pvt;
-	pw->close = pw_close;
-	pw->next = pw_next;
-	pw->byname = pw_byname;
-	pw->byuid = pw_byuid;
-	pw->rewind = pw_rewind;
-	pw->minimize = pw_minimize;
-	pw->res_get = NULL;
-	pw->res_set = NULL;
-	return (pw);
-}
-
-/* Methods */
-
-static void
-pw_close(struct irs_pw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	
-	if (pvt->pw_db) {
-		(void)(pvt->pw_db->close)(pvt->pw_db);
-		pvt->pw_db = NULL;
-	}
-	if (pvt->line)
-		memput(pvt->line, pvt->max);
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-static struct passwd *
-pw_next(struct irs_pw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	
-	DBT key;
-	char bf[sizeof(pvt->pw_keynum) + 1];
- 
-	if (!initdb(pvt))
-		return (NULL);
- 
-	++pvt->pw_keynum;
-	bf[0] = _PW_KEYBYNUM;
-	memcpy(bf + 1, (char *)&pvt->pw_keynum, sizeof(pvt->pw_keynum));
-	key.data = (u_char *)bf;
-	key.size = sizeof(pvt->pw_keynum) + 1;
-	return (hashpw(this, &key) ? &pvt->passwd : NULL);
-}
- 
-static struct passwd *
-pw_byname(struct irs_pw *this, const char *name) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	DBT key;
-	int len, rval;
-	char bf[UT_NAMESIZE + 1];
- 
-	if (!initdb(pvt))
-		return (NULL);
- 
-	bf[0] = _PW_KEYBYNAME;
-	len = strlen(name);
-	memcpy(bf + 1, name, MIN(len, UT_NAMESIZE));
-	key.data = (u_char *)bf;
-	key.size = len + 1;
-	rval = hashpw(this, &key);
- 
-	return (rval ? &pvt->passwd : NULL);
-}
- 
-
-static struct passwd *
-pw_byuid(struct irs_pw *this, uid_t uid) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	DBT key;
-	int keyuid, rval;
-	char bf[sizeof(keyuid) + 1];
- 
-	if (!initdb(pvt))
-		return (NULL);
- 
-	bf[0] = _PW_KEYBYUID;
-	keyuid = uid;
-	memcpy(bf + 1, &keyuid, sizeof(keyuid));
-	key.data = (u_char *)bf;
-	key.size = sizeof(keyuid) + 1;
-	rval = hashpw(this, &key);
- 
-	return (rval ? &pvt->passwd : NULL);
-}
-
-static void
-pw_rewind(struct irs_pw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	pvt->pw_keynum = 0;
-}
-
-static void
-pw_minimize(struct irs_pw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (pvt->pw_db != NULL) {
-		(void) (*pvt->pw_db->close)(pvt->pw_db);
-		pvt->pw_db = NULL;
-	}
-}
-
-/* Private. */
-
-static int
-initdb(struct pvt *pvt) {
-	const char *p;
-
-	if (pvt->pw_db) {
-		if (lseek((*pvt->pw_db->fd)(pvt->pw_db), 0L, SEEK_CUR) >= 0L)
-			return (1);
-		else
-			(void) (*pvt->pw_db->close)(pvt->pw_db);
-	}
-	pvt->pw_db = dbopen((p = _PATH_SMP_DB), O_RDONLY, 0, DB_HASH, NULL);
-	if (!pvt->pw_db)
-		pvt->pw_db = dbopen((p =_PATH_MP_DB), O_RDONLY,
-				    0, DB_HASH, NULL);
-	if (pvt->pw_db)
-		return (1);
-	if (!pvt->warned) {
-		syslog(LOG_ERR, "%s: %m", p);
-		pvt->warned++;
-	}
-	return (0);
-}
-
-static int
-hashpw(struct irs_pw *this, DBT *key) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	char *p, *t, *l;
-	DBT data;
- 
-	if ((pvt->pw_db->get)(pvt->pw_db, key, &data, 0))
-		return (0);
-	p = (char *)data.data;
-	if (data.size > pvt->max) {
-		size_t newlen = pvt->max + 1024;
-		char *p = memget(newlen);
-		if (p == NULL) {
-			return (0);
-		}
-		if (pvt->line != NULL) {
-			memcpy(p, pvt->line, pvt->max);
-			memput(pvt->line, pvt->max);
-		}
-		pvt->max = newlen;
-		pvt->line = p;
-	}
-
-	/* THIS CODE MUST MATCH THAT IN pwd_mkdb. */
-	t = pvt->line;
-	l = pvt->line + pvt->max;
-#define EXPAND(e) if ((e = t) == NULL) return (0); else \
-		  do if (t >= l) return (0); while ((*t++ = *p++) != '\0')
-#define SCALAR(v) if (t + sizeof v >= l) return (0); else \
-		  (memmove(&(v), p, sizeof v), p += sizeof v)
-	EXPAND(pvt->passwd.pw_name);
-	EXPAND(pvt->passwd.pw_passwd);
-	SCALAR(pvt->passwd.pw_uid);
-	SCALAR(pvt->passwd.pw_gid);
-	SCALAR(pvt->passwd.pw_change);
-	EXPAND(pvt->passwd.pw_class);
-	EXPAND(pvt->passwd.pw_gecos);
-	EXPAND(pvt->passwd.pw_dir);
-	EXPAND(pvt->passwd.pw_shell);
-	SCALAR(pvt->passwd.pw_expire);
-	return (1);
-}
-
-#endif /* WANT_IRS_PW */
diff --git a/contrib/bind9/lib/bind/irs/lcl_sv.c b/contrib/bind9/lib/bind/irs/lcl_sv.c
deleted file mode 100644
index 7675834..0000000
--- a/contrib/bind9/lib/bind/irs/lcl_sv.c
+++ /dev/null
@@ -1,432 +0,0 @@
-/*
- * Copyright (c) 1989, 1993, 1995
- *	The Regents of the University of California.  All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- *	This product includes software developed by the University of
- *	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: lcl_sv.c,v 1.3.18.1 2005/04/27 05:01:03 sra Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-/* extern */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/socket.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <resolv.h>
-
-#ifdef IRS_LCL_SV_DB
-#include <db.h>
-#endif
-#include <errno.h>
-#include <fcntl.h>
-#include <limits.h>
-#include <stdio.h>
-#include <string.h>
-#include <stdlib.h>
-
-#include <irs.h>
-#include <isc/memcluster.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "lcl_p.h"
-
-#ifdef SPRINTF_CHAR
-# define SPRINTF(x) strlen(sprintf/**/x)
-#else
-# define SPRINTF(x) ((size_t)sprintf x)
-#endif
-
-/* Types */
-
-struct pvt {
-#ifdef IRS_LCL_SV_DB
-	DB *		dbh;
-	int		dbf;
-#endif
-	struct lcl_sv	sv;
-};
-
-/* Forward */
-
-static void			sv_close(struct irs_sv*);
-static struct servent *		sv_next(struct irs_sv *);
-static struct servent *		sv_byname(struct irs_sv *, const char *,
-					  const char *);
-static struct servent *		sv_byport(struct irs_sv *, int, const char *);
-static void			sv_rewind(struct irs_sv *);
-static void			sv_minimize(struct irs_sv *);
-/*global*/ struct servent *	irs_lclsv_fnxt(struct lcl_sv *);
-#ifdef IRS_LCL_SV_DB
-static struct servent *		sv_db_rec(struct lcl_sv *, DBT *, DBT *);
-#endif
-
-/* Portability */
-
-#ifndef SEEK_SET
-# define SEEK_SET 0
-#endif
-
-/* Public */
-
-struct irs_sv *
-irs_lcl_sv(struct irs_acc *this) {
-	struct irs_sv *sv;
-	struct pvt *pvt;
-
-	UNUSED(this);
-	
-	if ((sv = memget(sizeof *sv)) == NULL) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(sv, 0x5e, sizeof *sv);
-	if ((pvt = memget(sizeof *pvt)) == NULL) {
-		memput(sv, sizeof *sv);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	sv->private = pvt;
-	sv->close = sv_close;
-	sv->next = sv_next;
-	sv->byname = sv_byname;
-	sv->byport = sv_byport;
-	sv->rewind = sv_rewind;
-	sv->minimize = sv_minimize;
-	sv->res_get = NULL;
-	sv->res_set = NULL;
-#ifdef IRS_LCL_SV_DB
-	pvt->dbf = R_FIRST;
-#endif
-	return (sv);
-}
-
-/* Methods */
-
-static void
-sv_close(struct irs_sv *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	
-#ifdef IRS_LCL_SV_DB
-	if (pvt->dbh != NULL)
-		(*pvt->dbh->close)(pvt->dbh);
-#endif
-	if (pvt->sv.fp)
-		fclose(pvt->sv.fp);
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-static struct servent *
-sv_byname(struct irs_sv *this, const char *name, const char *proto) {
-#ifdef IRS_LCL_SV_DB
-	struct pvt *pvt = (struct pvt *)this->private;
-#endif
-	struct servent *p;
-	char **cp;
-
-	sv_rewind(this);
-#ifdef IRS_LCL_SV_DB
-	if (pvt->dbh != NULL) {
-		DBT key, data;
-
-		/* Note that (sizeof "/") == 2. */
-		if ((strlen(name) + sizeof "/" + proto ? strlen(proto) : 0)
-		    > sizeof pvt->sv.line)
-			goto try_local;
-		key.data = pvt->sv.line;
-		key.size = SPRINTF((pvt->sv.line, "%s/%s", name,
-				    proto ? proto : "")) + 1;
-		if (proto != NULL) {
-			if ((*pvt->dbh->get)(pvt->dbh, &key, &data, 0) != 0)
-				return (NULL);
-		} else if ((*pvt->dbh->seq)(pvt->dbh, &key, &data, R_CURSOR)
-			   != 0)
-			return (NULL);
-		return (sv_db_rec(&pvt->sv, &key, &data));
-	}
- try_local:
-#endif
-
-	while ((p = sv_next(this))) {
-		if (strcmp(name, p->s_name) == 0)
-			goto gotname;
-		for (cp = p->s_aliases; *cp; cp++)
-			if (strcmp(name, *cp) == 0)
-				goto gotname;
-		continue;
- gotname:
-		if (proto == NULL || strcmp(p->s_proto, proto) == 0)
-			break;
-	}
-	return (p);
-}
-
-static struct servent *
-sv_byport(struct irs_sv *this, int port, const char *proto) {
-#ifdef IRS_LCL_SV_DB
-	struct pvt *pvt = (struct pvt *)this->private;
-#endif
-	struct servent *p;
-
-	sv_rewind(this);
-#ifdef IRS_LCL_SV_DB
-	if (pvt->dbh != NULL) {
-		DBT key, data;
-		u_short *ports;
-
-		ports = (u_short *)pvt->sv.line;
-		ports[0] = 0;
-		ports[1] = port;
-		key.data = ports;
-		key.size = sizeof(u_short) * 2;
-		if (proto && *proto) {
-			strncpy((char *)ports + key.size, proto,
-				BUFSIZ - key.size);
-			key.size += strlen((char *)ports + key.size) + 1;
-			if ((*pvt->dbh->get)(pvt->dbh, &key, &data, 0) != 0)
-				return (NULL);
-		} else {
-			if ((*pvt->dbh->seq)(pvt->dbh, &key, &data, R_CURSOR)
-			    != 0)
-				return (NULL);
-		}
-		return (sv_db_rec(&pvt->sv, &key, &data));
-	}
-#endif
-	while ((p = sv_next(this))) {
-		if (p->s_port != port)
-			continue;
-		if (proto == NULL || strcmp(p->s_proto, proto) == 0)
-			break;
-	}
-	return (p);
-}
-
-static void
-sv_rewind(struct irs_sv *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (pvt->sv.fp) {
-		if (fseek(pvt->sv.fp, 0L, SEEK_SET) == 0)
-			return;
-		(void)fclose(pvt->sv.fp);
-		pvt->sv.fp = NULL;
-	}
-#ifdef IRS_LCL_SV_DB
-	pvt->dbf = R_FIRST;
-	if (pvt->dbh != NULL)
-		return;
-	pvt->dbh = dbopen(_PATH_SERVICES_DB, O_RDONLY,O_RDONLY,DB_BTREE, NULL);
-	if (pvt->dbh != NULL) {
-		if (fcntl((*pvt->dbh->fd)(pvt->dbh), F_SETFD, 1) < 0) {
-			(*pvt->dbh->close)(pvt->dbh);
-			pvt->dbh = NULL;
-		}
-		return;
-	}
-#endif
-	if ((pvt->sv.fp = fopen(_PATH_SERVICES, "r")) == NULL)
-		return;
-	if (fcntl(fileno(pvt->sv.fp), F_SETFD, 1) < 0) {
-		(void)fclose(pvt->sv.fp);
-		pvt->sv.fp = NULL;
-	}
-}
-
-static struct servent *
-sv_next(struct irs_sv *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-#ifdef IRS_LCL_SV_DB
-	if (pvt->dbh == NULL && pvt->sv.fp == NULL)
-#else
-	if (pvt->sv.fp == NULL)
-#endif
-		sv_rewind(this);
-
-#ifdef IRS_LCL_SV_DB
-	if (pvt->dbh != NULL) {
-		DBT key, data;
-
-		while ((*pvt->dbh->seq)(pvt->dbh, &key, &data, pvt->dbf) == 0){
-			pvt->dbf = R_NEXT;
-			if (((char *)key.data)[0])
-				continue;
-			return (sv_db_rec(&pvt->sv, &key, &data));
-		}
-	}
-#endif
-
-	if (pvt->sv.fp == NULL)
-		return (NULL);
-	return (irs_lclsv_fnxt(&pvt->sv));
-}
-
-static void
-sv_minimize(struct irs_sv *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-#ifdef IRS_LCL_SV_DB
-	if (pvt->dbh != NULL) {
-		(*pvt->dbh->close)(pvt->dbh);
-		pvt->dbh = NULL;
-	}
-#endif
-	if (pvt->sv.fp != NULL) {
-		(void)fclose(pvt->sv.fp);
-		pvt->sv.fp = NULL;
-	}
-}
-
-/* Quasipublic. */
-
-struct servent *
-irs_lclsv_fnxt(struct lcl_sv *sv) {
-	char *p, *cp, **q;
-
- again:
-	if ((p = fgets(sv->line, BUFSIZ, sv->fp)) == NULL)
-		return (NULL);
-	if (*p == '#')
-		goto again;
-	sv->serv.s_name = p;
-	while (*p && *p != '\n' && *p != ' ' && *p != '\t' && *p != '#')
-		++p;
-	if (*p == '\0' || *p == '#' || *p == '\n')
-		goto again;
-	*p++ = '\0';
-	while (*p == ' ' || *p == '\t')
-		p++;
-	if (*p == '\0' || *p == '#' || *p == '\n')
-		goto again;
-	sv->serv.s_port = htons((u_short)strtol(p, &cp, 10));
-	if (cp == p || (*cp != '/' && *cp != ','))
-		goto again;
-	p = cp + 1;
-	sv->serv.s_proto = p;
-
-	q = sv->serv.s_aliases = sv->serv_aliases;
-
-	while (*p && *p != '\n' && *p != ' ' && *p != '\t' && *p != '#')
-		++p;
-
-	while (*p == ' ' || *p == '\t') {
-		*p++ = '\0';
-		while (*p == ' ' || *p == '\t')
-			++p;
-		if (*p == '\0' || *p == '#' || *p == '\n')
-			break;
-		if (q < &sv->serv_aliases[IRS_SV_MAXALIASES - 1])
-			*q++ = p;
-		while (*p && *p != '\n' && *p != ' ' && *p != '\t' && *p != '#')
-			++p;
-	}
-		
-	*p = '\0';
-	*q = NULL;
-	return (&sv->serv);
-}
-
-/* Private. */
-
-#ifdef IRS_LCL_SV_DB
-static struct servent *
-sv_db_rec(struct lcl_sv *sv, DBT *key, DBT *data) {
-	char *p, **q;
-	int n;
-
-	p = data->data;
-	p[data->size - 1] = '\0';	/*%< should be, but we depend on it */
-	if (((char *)key->data)[0] == '\0') {
-		if (key->size < sizeof(u_short)*2 || data->size < 2)
-			return (NULL);
-		sv->serv.s_port = ((u_short *)key->data)[1];
-		n = strlen(p) + 1;
-		if ((size_t)n > sizeof(sv->line)) {
-			n = sizeof(sv->line);
-		}
-		memcpy(sv->line, p, n);
-		sv->serv.s_name = sv->line;
-		if ((sv->serv.s_proto = strchr(sv->line, '/')) != NULL)
-			*(sv->serv.s_proto)++ = '\0';
-		p += n;
-		data->size -= n;
-	} else {
-		if (data->size < sizeof(u_short) + 1)
-			return (NULL);
-		if (key->size > sizeof(sv->line))
-			key->size = sizeof(sv->line);
-		((char *)key->data)[key->size - 1] = '\0';
-		memcpy(sv->line, key->data, key->size);
-		sv->serv.s_name = sv->line;
-		if ((sv->serv.s_proto = strchr(sv->line, '/')) != NULL)
-			*(sv->serv.s_proto)++ = '\0';
-		sv->serv.s_port = *(u_short *)data->data;
-		p += sizeof(u_short);
-		data->size -= sizeof(u_short);
-	}
-	q = sv->serv.s_aliases = sv->serv_aliases;
-	while (data->size > 0 && q < &sv->serv_aliases[IRS_SV_MAXALIASES - 1]) {
-
-		*q++ = p;
-		n = strlen(p) + 1;
-		data->size -= n;
-		p += n;
-	}
-	*q = NULL;
-	return (&sv->serv);
-}
-#endif
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/nis.c b/contrib/bind9/lib/bind/irs/nis.c
deleted file mode 100644
index 62cc267..0000000
--- a/contrib/bind9/lib/bind/irs/nis.c
+++ /dev/null
@@ -1,156 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996-1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: nis.c,v 1.2.18.1 2005/04/27 05:01:03 sra Exp $";
-#endif
-
-/* Imports */
-
-#include "port_before.h"
-
-#ifdef WANT_IRS_NIS
-
-#include <rpc/rpc.h>
-#include <rpc/xdr.h>
-#include <rpcsvc/yp_prot.h>
-#include <rpcsvc/ypclnt.h>
-
-#include <stdlib.h>
-#include <string.h>
-#include <errno.h>
-
-#include <sys/types.h>
-#include <netinet/in.h> 
-#ifdef T_NULL
-#undef T_NULL			/* Silence re-definition warning of T_NULL. */
-#endif
-#include <arpa/nameser.h>
-#include <resolv.h>
-
-#include <isc/memcluster.h>
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "hesiod.h"
-#include "nis_p.h"
-
-/* Forward */
-
-static void		nis_close(struct irs_acc *);
-static struct __res_state * nis_res_get(struct irs_acc *);
-static void		nis_res_set(struct irs_acc *, struct __res_state *,
-				void (*)(void *));
-
-/* Public */
-
-struct irs_acc *
-irs_nis_acc(const char *options) {
-	struct nis_p *nis;
-	struct irs_acc *acc;
-	char *domain;
-
-	UNUSED(options);
-
-	if (yp_get_default_domain(&domain) != 0)
-		return (NULL);
-	if (!(nis = memget(sizeof *nis))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(nis, 0, sizeof *nis);
-	if (!(acc = memget(sizeof *acc))) {
-		memput(nis, sizeof *nis);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(acc, 0x5e, sizeof *acc);
-	acc->private = nis;
-	nis->domain = strdup(domain);
-#ifdef WANT_IRS_GR
-	acc->gr_map = irs_nis_gr;
-#else
-	acc->gr_map = NULL;
-#endif
-#ifdef WANT_IRS_PW
-	acc->pw_map = irs_nis_pw;
-#else
-	acc->pw_map = NULL;
-#endif
-	acc->sv_map = irs_nis_sv;
-	acc->pr_map = irs_nis_pr;
-	acc->ho_map = irs_nis_ho;
-	acc->nw_map = irs_nis_nw;
-	acc->ng_map = irs_nis_ng;
-	acc->res_get = nis_res_get;
-	acc->res_set = nis_res_set;
-	acc->close = nis_close;
-	return (acc);
-}
-
-/* Methods */
-
-static struct __res_state *
-nis_res_get(struct irs_acc *this) {
-	struct nis_p *nis = (struct nis_p *)this->private;
-
-	if (nis->res == NULL) {
-		struct __res_state *res;
-		res = (struct __res_state *)malloc(sizeof *res);
-		if (res == NULL)
-			return (NULL);
-		memset(res, 0, sizeof *res);
-		nis_res_set(this, res, free);
-	}
-
-	if ((nis->res->options & RES_INIT) == 0 &&
-	    res_ninit(nis->res) < 0)
-		return (NULL);
-
-	return (nis->res);
-}
-
-static void
-nis_res_set(struct irs_acc *this, struct __res_state *res,
-		void (*free_res)(void *)) {
-	struct nis_p *nis = (struct nis_p *)this->private;
-
-	if (nis->res && nis->free_res) {
-		res_nclose(nis->res);
-		(*nis->free_res)(nis->res);
-	}
-
-	nis->res = res;
-	nis->free_res = free_res;
-}
-
-static void
-nis_close(struct irs_acc *this) {
-	struct nis_p *nis = (struct nis_p *)this->private;
-
-	if (nis->res && nis->free_res)
-		(*nis->free_res)(nis->res);
-	free(nis->domain);
-	memput(nis, sizeof *nis);
-	memput(this, sizeof *this);
-}
-
-#endif /*WANT_IRS_NIS*/
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/nis_gr.c b/contrib/bind9/lib/bind/irs/nis_gr.c
deleted file mode 100644
index 9d4f15d..0000000
--- a/contrib/bind9/lib/bind/irs/nis_gr.c
+++ /dev/null
@@ -1,354 +0,0 @@
-/*
- * Copyright (c) 1989, 1993, 1995
- *	The Regents of the University of California.  All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- *	This product includes software developed by the University of
- *	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- *
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: nis_gr.c,v 1.3.18.1 2005/04/27 05:01:03 sra Exp $";
-/* from getgrent.c 8.2 (Berkeley) 3/21/94"; */
-/* from BSDI Id: getgrent.c,v 2.8 1996/05/28 18:15:14 bostic Exp $	*/
-#endif /* LIBC_SCCS and not lint */
-
-/* Imports */
-
-#include "port_before.h"
-
-#if !defined(WANT_IRS_GR) || !defined(WANT_IRS_NIS)
-static int __bind_irs_gr_unneeded;
-#else
-
-#include <sys/param.h>
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <resolv.h>
-#include <isc/memcluster.h>
-
-#include <rpc/rpc.h>
-#include <rpc/xdr.h>
-#include <rpcsvc/yp_prot.h>
-#include <rpcsvc/ypclnt.h>
-
-#include <errno.h>
-#include <grp.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <unistd.h>
-
-#include <isc/memcluster.h>
-
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "nis_p.h"
-
-/* Definitions */
-
-struct pvt {
-	int		needrewind;
-	char *		nis_domain;
-	char *		curkey_data;
-	int		curkey_len;
-	char *		curval_data;
-	int		curval_len;
-	/*%<
-	 * Need space to store the entries read from the group file.
-	 * The members list also needs space per member, and the
-	 * strings making up the user names must be allocated
-	 * somewhere.  Rather than doing lots of small allocations,
-	 * we keep one buffer and resize it as needed.
-	 */
-	struct group	group;
-	size_t		nmemb;		/*%< Malloc'd max index of gr_mem[]. */
-	char *		membuf;
-	size_t		membufsize;
-};
-
-enum do_what { do_none = 0x0, do_key = 0x1, do_val = 0x2, do_all = 0x3 };
-
-static /*const*/ char group_bygid[] =	"group.bygid";
-static /*const*/ char group_byname[] =	"group.byname";
-
-/* Forward */
-
-static void		gr_close(struct irs_gr *);
-static struct group *	gr_next(struct irs_gr *);
-static struct group *	gr_byname(struct irs_gr *, const char *);
-static struct group *	gr_bygid(struct irs_gr *, gid_t);
-static void		gr_rewind(struct irs_gr *);
-static void		gr_minimize(struct irs_gr *);
-
-static struct group *	makegroupent(struct irs_gr *);
-static void		nisfree(struct pvt *, enum do_what);
-
-/* Public */
-
-struct irs_gr *
-irs_nis_gr(struct irs_acc *this) {
-	struct irs_gr *gr;
-	struct pvt *pvt;
-
-	if (!(gr = memget(sizeof *gr))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(gr, 0x5e, sizeof *gr);
-	if (!(pvt = memget(sizeof *pvt))) {
-		memput(gr, sizeof *gr);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	pvt->needrewind = 1;
-	pvt->nis_domain = ((struct nis_p *)this->private)->domain;
-	gr->private = pvt;
-	gr->close = gr_close;
-	gr->next = gr_next;
-	gr->byname = gr_byname;
-	gr->bygid = gr_bygid;
-	gr->rewind = gr_rewind;
-	gr->list = make_group_list;
-	gr->minimize = gr_minimize;
-	gr->res_get = NULL;
-	gr->res_set = NULL;
-	return (gr);
-}
-
-/* Methods */
-
-static void
-gr_close(struct irs_gr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (pvt->group.gr_mem)
-		free(pvt->group.gr_mem);
-	if (pvt->membuf)
-		free(pvt->membuf);
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-static struct group *
-gr_next(struct irs_gr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct group *rval;
-	int r;
-
-	do {
-		if (pvt->needrewind) {
-			nisfree(pvt, do_all);
-			r = yp_first(pvt->nis_domain, group_byname,
-				     &pvt->curkey_data, &pvt->curkey_len,
-				     &pvt->curval_data, &pvt->curval_len);
-			pvt->needrewind = 0;
-		} else {
-			char *newkey_data;
-			int newkey_len;
-
-			nisfree(pvt, do_val);
-			r = yp_next(pvt->nis_domain, group_byname,
-				    pvt->curkey_data, pvt->curkey_len,
-				    &newkey_data, &newkey_len,
-				    &pvt->curval_data, &pvt->curval_len);
-			nisfree(pvt, do_key);
-			pvt->curkey_data = newkey_data;
-			pvt->curkey_len = newkey_len;
-		}
-		if (r != 0) {
-			errno = ENOENT;
-			return (NULL);
-		}
-		rval = makegroupent(this);
-	} while (rval == NULL);
-	return (rval);
-}
-
-static struct group *
-gr_byname(struct irs_gr *this, const char *name) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	int r;
-
-	nisfree(pvt, do_val);
-	r = yp_match(pvt->nis_domain, group_byname, name, strlen(name),
-		     &pvt->curval_data, &pvt->curval_len);
-	if (r != 0) {
-		errno = ENOENT;
-		return (NULL);
-	}
-	return (makegroupent(this));
-}
-
-static struct group *
-gr_bygid(struct irs_gr *this, gid_t gid) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	char tmp[sizeof "4294967295"];
-	int r;
-
-	nisfree(pvt, do_val);
-	(void) sprintf(tmp, "%u", (unsigned int)gid);
-	r = yp_match(pvt->nis_domain, group_bygid, tmp, strlen(tmp),
-		     &pvt->curval_data, &pvt->curval_len);
-	if (r != 0) {
-		errno = ENOENT;
-		return (NULL);
-	}
-	return (makegroupent(this));
-}
-
-static void
-gr_rewind(struct irs_gr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	pvt->needrewind = 1;
-}
-
-static void
-gr_minimize(struct irs_gr *this) {
-	UNUSED(this);
-	/* NOOP */
-}
-
-/* Private */
-
-static struct group *
-makegroupent(struct irs_gr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	unsigned int num_members = 0;
-	char *cp, **new;
-	u_long t;
-
-	if (pvt->group.gr_mem) {
-		free(pvt->group.gr_mem);
-		pvt->group.gr_mem = NULL;
-		pvt->nmemb = 0;
-	}
-	if (pvt->membuf)
-		free(pvt->membuf);
-	pvt->membuf = pvt->curval_data;
-	pvt->curval_data = NULL;
-
-	cp = pvt->membuf;
-	pvt->group.gr_name = cp;
-	if (!(cp = strchr(cp, ':')))
-		goto cleanup;
-	*cp++ = '\0';
-	
-	pvt->group.gr_passwd = cp;
-	if (!(cp = strchr(cp, ':')))
-		goto cleanup;
-	*cp++ = '\0';
-
-	errno = 0;
-	t = strtoul(cp, NULL, 10);
-	if (errno == ERANGE)
-		goto cleanup;
-	pvt->group.gr_gid = (gid_t) t;
-	if (!(cp = strchr(cp, ':')))
-		goto cleanup;
-	cp++;
-
-        if (*cp && cp[strlen(cp)-1] == '\n')
-          cp[strlen(cp)-1] = '\0';
-
-	/*
-	 * Parse the members out.
-	 */
-	while (*cp) {
-		if (num_members+1 >= pvt->nmemb || pvt->group.gr_mem == NULL) {
-			pvt->nmemb += 10;
-			new = realloc(pvt->group.gr_mem,
-				      pvt->nmemb * sizeof(char *));
-			if (new == NULL)
-				goto cleanup;
-			pvt->group.gr_mem = new;
-		}
-		pvt->group.gr_mem[num_members++] = cp;
-		if (!(cp = strchr(cp, ',')))
-			break;
-		*cp++ = '\0';
-	}
-	if (pvt->group.gr_mem == NULL) {
-		pvt->group.gr_mem = malloc(sizeof(char*));
-		if (!pvt->group.gr_mem)
-			goto cleanup;
-		pvt->nmemb = 1;
-	}
-	pvt->group.gr_mem[num_members] = NULL;
-	
-	return (&pvt->group);
-	
- cleanup:	
-	if (pvt->group.gr_mem) {
-		free(pvt->group.gr_mem);
-		pvt->group.gr_mem = NULL;
-		pvt->nmemb = 0;
-	}
-	if (pvt->membuf) {
-		free(pvt->membuf);
-		pvt->membuf = NULL;
-	}
-	return (NULL);
-}
-
-static void
-nisfree(struct pvt *pvt, enum do_what do_what) {
-	if ((do_what & do_key) && pvt->curkey_data) {
-		free(pvt->curkey_data);
-		pvt->curkey_data = NULL;
-	}
-	if ((do_what & do_val) && pvt->curval_data) {
-		free(pvt->curval_data);
-		pvt->curval_data = NULL;
-	}
-}
-
-#endif /* WANT_IRS_GR && WANT_IRS_NIS */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/nis_ho.c b/contrib/bind9/lib/bind/irs/nis_ho.c
deleted file mode 100644
index 7524279..0000000
--- a/contrib/bind9/lib/bind/irs/nis_ho.c
+++ /dev/null
@@ -1,535 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: nis_ho.c,v 1.4.18.1 2005/04/27 05:01:03 sra Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-/* Imports */
-
-#include "port_before.h"
-
-#ifndef WANT_IRS_NIS
-static int __bind_irs_nis_unneeded;
-#else
-
-#include <sys/types.h>
-#include <sys/param.h>
-#include <sys/socket.h>
-#include <netinet/in.h>
-#include <arpa/inet.h>
-#include <arpa/nameser.h>
-#ifdef T_NULL
-#undef T_NULL			/* Silence re-definition warning of T_NULL. */
-#endif
-#include <rpc/rpc.h>
-#include <rpc/xdr.h>
-#include <rpcsvc/yp_prot.h>
-#include <rpcsvc/ypclnt.h>
-
-#include <ctype.h>
-#include <errno.h>
-#include <stdlib.h>
-#include <netdb.h>
-#include <resolv.h>
-#include <stdio.h>
-#include <string.h>
-
-#include <isc/memcluster.h>
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "nis_p.h"
-
-/* Definitions */
-
-#define	MAXALIASES	35
-#define	MAXADDRS	35
-
-#if PACKETSZ > 1024
-#define	MAXPACKET	PACKETSZ
-#else
-#define	MAXPACKET	1024
-#endif
-
-struct pvt {
-	int		needrewind;
-	char *		nis_domain;
-	char *		curkey_data;
-	int		curkey_len;
-	char *		curval_data;
-	int		curval_len;
-	struct hostent	host;
-	char *		h_addr_ptrs[MAXADDRS + 1];
-	char *		host_aliases[MAXALIASES + 1];
-	char		hostbuf[8*1024];
-	u_char		host_addr[16];	/*%< IPv4 or IPv6 */
-	struct __res_state  *res;
-	void		(*free_res)(void *);
-};
-
-enum do_what { do_none = 0x0, do_key = 0x1, do_val = 0x2, do_all = 0x3 };
-
-static const u_char mapped[] = { 0,0, 0,0, 0,0, 0,0, 0,0, 0xff,0xff };
-static const u_char tunnelled[] = { 0,0, 0,0, 0,0, 0,0, 0,0, 0,0 };
-static /*const*/ char hosts_byname[] = "hosts.byname";
-static /*const*/ char hosts_byaddr[] = "hosts.byaddr";
-static /*const*/ char ipnode_byname[] = "ipnode.byname";
-static /*const*/ char ipnode_byaddr[] = "ipnode.byaddr";
-static /*const*/ char yp_multi[] = "YP_MULTI_";
-
-/* Forwards */
-
-static void		ho_close(struct irs_ho *this);
-static struct hostent *	ho_byname(struct irs_ho *this, const char *name);
-static struct hostent *	ho_byname2(struct irs_ho *this, const char *name,
-					int af);
-static struct hostent *	ho_byaddr(struct irs_ho *this, const void *addr,
-				       int len, int af);
-static struct hostent *	ho_next(struct irs_ho *this);
-static void		ho_rewind(struct irs_ho *this);
-static void		ho_minimize(struct irs_ho *this);
-static struct __res_state * ho_res_get(struct irs_ho *this);
-static void		ho_res_set(struct irs_ho *this,
-				   struct __res_state *res,
-				   void (*free_res)(void *));
-static struct addrinfo * ho_addrinfo(struct irs_ho *this, const char *name,
-				     const struct addrinfo *pai);
-
-static struct hostent *	makehostent(struct irs_ho *this);
-static void		nisfree(struct pvt *, enum do_what);
-static int		init(struct irs_ho *this);
-
-/* Public */
-
-struct irs_ho *
-irs_nis_ho(struct irs_acc *this) {
-	struct irs_ho *ho;
-	struct pvt *pvt;
-
-	if (!(pvt = memget(sizeof *pvt))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	if (!(ho = memget(sizeof *ho))) {
-		memput(pvt, sizeof *pvt);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(ho, 0x5e, sizeof *ho);
-	pvt->needrewind = 1;
-	pvt->nis_domain = ((struct nis_p *)this->private)->domain;
-	ho->private = pvt;
-	ho->close = ho_close;
-	ho->byname = ho_byname;
-	ho->byname2 = ho_byname2;
-	ho->byaddr = ho_byaddr;
-	ho->next = ho_next;
-	ho->rewind = ho_rewind;
-	ho->minimize = ho_minimize;
-	ho->res_set = ho_res_set;
-	ho->res_get = ho_res_get;
-	ho->addrinfo = ho_addrinfo;
-	return (ho);
-}
-
-/* Methods */
-
-static void
-ho_close(struct irs_ho *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	ho_minimize(this);
-	nisfree(pvt, do_all);
-	if (pvt->res && pvt->free_res)
-		(*pvt->free_res)(pvt->res);
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-static struct hostent *
-ho_byname(struct irs_ho *this, const char *name) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct hostent *hp;
-
-	if (init(this) == -1)
-		return (NULL);
-
-	if (pvt->res->options & RES_USE_INET6) {
-		hp = ho_byname2(this, name, AF_INET6);
-		if (hp)
-			return (hp);
-	}
-	return (ho_byname2(this, name, AF_INET));
-}
-
-static struct hostent *
-ho_byname2(struct irs_ho *this, const char *name, int af) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	int r;
-	char *tmp;
-
-	UNUSED(af);
-	
-	if (init(this) == -1)
-		return (NULL);
-
-	nisfree(pvt, do_val);
-
-	strcpy(pvt->hostbuf, yp_multi);
-	strncat(pvt->hostbuf, name, sizeof(pvt->hostbuf) - sizeof(yp_multi));
-	pvt->hostbuf[sizeof(pvt->hostbuf) - 1] = '\0';
-	for (r = sizeof(yp_multi) - 1; pvt->hostbuf[r] != '\0'; r++)
-		if (isupper((unsigned char)pvt->hostbuf[r]))
-			tolower(pvt->hostbuf[r]);
-
-	tmp = pvt->hostbuf;
-	r = yp_match(pvt->nis_domain, ipnode_byname, tmp,
-		     strlen(tmp), &pvt->curval_data, &pvt->curval_len);
-	if (r != 0) {
-		tmp = pvt->hostbuf + sizeof(yp_multi) - 1;
-		r = yp_match(pvt->nis_domain, ipnode_byname, tmp,
-			     strlen(tmp), &pvt->curval_data, &pvt->curval_len);
-	}
-	if (r != 0) {
-		tmp = pvt->hostbuf;
-		r = yp_match(pvt->nis_domain, hosts_byname, tmp,
-			     strlen(tmp), &pvt->curval_data, &pvt->curval_len);
-	}
-	if (r != 0) {
-		tmp = pvt->hostbuf + sizeof(yp_multi) - 1;
-		r = yp_match(pvt->nis_domain, hosts_byname, tmp,
-			     strlen(tmp), &pvt->curval_data, &pvt->curval_len);
-	}
-	if (r != 0) {
-		RES_SET_H_ERRNO(pvt->res, HOST_NOT_FOUND);
-		return (NULL);
-	}
-	return (makehostent(this));
-}
-
-static struct hostent *
-ho_byaddr(struct irs_ho *this, const void *addr, int len, int af) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	char tmp[sizeof "ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255"];
-	const u_char *uaddr = addr;
-	int r;
-	
-	if (init(this) == -1)
-		return (NULL);
-
-	if (af == AF_INET6 && len == IN6ADDRSZ &&
-	    (!memcmp(uaddr, mapped, sizeof mapped) ||
-	     !memcmp(uaddr, tunnelled, sizeof tunnelled))) {
-		/* Unmap. */
-		addr = (const u_char *)addr + sizeof mapped;
-		uaddr += sizeof mapped;
-		af = AF_INET;
-		len = INADDRSZ;
-	}
-	if (inet_ntop(af, uaddr, tmp, sizeof tmp) == NULL) {
-		RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL);
-		return (NULL);
-	}
-	nisfree(pvt, do_val);
-	r = yp_match(pvt->nis_domain, ipnode_byaddr, tmp, strlen(tmp),
-		     &pvt->curval_data, &pvt->curval_len);
-	if (r != 0)
-		r = yp_match(pvt->nis_domain, hosts_byaddr, tmp, strlen(tmp),
-			     &pvt->curval_data, &pvt->curval_len);
-	if (r != 0) {
-		RES_SET_H_ERRNO(pvt->res, HOST_NOT_FOUND);
-		return (NULL);
-	}
-	return (makehostent(this));
-}
-
-static struct hostent *
-ho_next(struct irs_ho *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct hostent *rval;
-	int r;
-
-	if (init(this) == -1)
-		return (NULL);
-
-	do {
-		if (pvt->needrewind) {
-			nisfree(pvt, do_all);
-			r = yp_first(pvt->nis_domain, hosts_byaddr,
-				     &pvt->curkey_data, &pvt->curkey_len,
-				     &pvt->curval_data, &pvt->curval_len);
-			pvt->needrewind = 0;
-		} else {
-			char *newkey_data;
-			int newkey_len;
-
-			nisfree(pvt, do_val);
-			r = yp_next(pvt->nis_domain, hosts_byaddr,
-				    pvt->curkey_data, pvt->curkey_len,
-				    &newkey_data, &newkey_len,
-				    &pvt->curval_data, &pvt->curval_len);
-			nisfree(pvt, do_key);
-			pvt->curkey_data = newkey_data;
-			pvt->curkey_len = newkey_len;
-		}
-		if (r != 0) {
-			RES_SET_H_ERRNO(pvt->res, HOST_NOT_FOUND);
-			return (NULL);
-		}
-		rval = makehostent(this);
-	} while (rval == NULL);
-	return (rval);
-}
-
-static void
-ho_rewind(struct irs_ho *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	pvt->needrewind = 1;
-}
-
-static void
-ho_minimize(struct irs_ho *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (pvt->res)
-		res_nclose(pvt->res);
-}
-
-static struct __res_state *
-ho_res_get(struct irs_ho *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (!pvt->res) {
-		struct __res_state *res;
-		res = (struct __res_state *)malloc(sizeof *res);
-		if (!res) {
-			errno = ENOMEM;
-			return (NULL);
-		}
-		memset(res, 0, sizeof *res);
-		ho_res_set(this, res, free);
-	}
-
-	return (pvt->res);
-}
-
-static void
-ho_res_set(struct irs_ho *this, struct __res_state *res,
-		void (*free_res)(void *)) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (pvt->res && pvt->free_res) {
-		res_nclose(pvt->res);
-		(*pvt->free_res)(pvt->res);
-	}
-
-	pvt->res = res;
-	pvt->free_res = free_res;
-}
-
-struct nis_res_target {
-	struct nis_res_target *next;
-	int family;
-};
-
-/* XXX */
-extern struct addrinfo *hostent2addrinfo __P((struct hostent *,
-					      const struct addrinfo *pai));
-
-static struct addrinfo *
-ho_addrinfo(struct irs_ho *this, const char *name, const struct addrinfo *pai)
-{
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct hostent *hp;
-	struct nis_res_target q, q2, *p;
-	struct addrinfo sentinel, *cur;
-
-	memset(&q, 0, sizeof(q2));
-	memset(&q2, 0, sizeof(q2));
-	memset(&sentinel, 0, sizeof(sentinel));
-	cur = &sentinel;
-
-	switch(pai->ai_family) {
-	case AF_UNSPEC:		/*%< INET6 then INET4 */
-		q.family = AF_INET6;
-		q.next = &q2;
-		q2.family = AF_INET;
-		break;
-	case AF_INET6:
-		q.family = AF_INET6;
-		break;
-	case AF_INET:
-		q.family = AF_INET;
-		break;
-	default:
-		RES_SET_H_ERRNO(pvt->res, NO_RECOVERY); /*%< ??? */
-		return(NULL);
-	}
-
-	for (p = &q; p; p = p->next) {
-		struct addrinfo *ai;
-
-		hp = (*this->byname2)(this, name, p->family);
-		if (hp == NULL) {
-			/* byname2 should've set an appropriate error */
-			continue;
-		}
-		if ((hp->h_name == NULL) || (hp->h_name[0] == 0) ||
-		    (hp->h_addr_list[0] == NULL)) {
-			RES_SET_H_ERRNO(pvt->res, NO_RECOVERY);
-			continue;
-		}
-		ai = hostent2addrinfo(hp, pai);
-		if (ai) {
-			cur->ai_next = ai;
-			while (cur && cur->ai_next)
-				cur = cur->ai_next;
-		}
-	}
-
-	if (sentinel.ai_next == NULL)
-		RES_SET_H_ERRNO(pvt->res, HOST_NOT_FOUND);
-
-	return(sentinel.ai_next);
-}
-
-/* Private */
-
-/*%
-ipnodes:
-::1             localhost
-127.0.0.1       localhost
-1.2.3.4         FOO bar
-1.2.6.4         FOO bar
-1.2.6.5         host
-
-ipnodes.byname:
-YP_MULTI_localhost ::1,127.0.0.1        localhost
-YP_MULTI_foo 1.2.3.4,1.2.6.4    FOO bar
-YP_MULTI_bar 1.2.3.4,1.2.6.4    FOO bar
-host 1.2.6.5    host
-
-hosts.byname:
-localhost 127.0.0.1     localhost
-host 1.2.6.5    host
-YP_MULTI_foo 1.2.3.4,1.2.6.4    FOO bar
-YP_MULTI_bar 1.2.3.4,1.2.6.4    FOO bar
-*/
-
-static struct hostent *
-makehostent(struct irs_ho *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	static const char spaces[] = " \t";
-	char *cp, **q, *p, *comma, *ap;
-	int af = 0, len = 0;
-	int multi = 0;
-	int addr = 0;
-
-	p = pvt->curval_data;
-	if ((cp = strpbrk(p, "#\n")) != NULL)
-		*cp = '\0';
-	if (!(cp = strpbrk(p, spaces)))
-		return (NULL);
-	*cp++ = '\0';
-	ap = pvt->hostbuf;
-	do {
-		if ((comma = strchr(p, ',')) != NULL) {
-			*comma++ = '\0';
-			multi = 1;
-		}
-		if ((ap + IN6ADDRSZ) > (pvt->hostbuf + sizeof(pvt->hostbuf)))
-			break;
-		if ((pvt->res->options & RES_USE_INET6) &&
-		    inet_pton(AF_INET6, p, ap) > 0) {
-			af = AF_INET6;
-			len = IN6ADDRSZ;
-		} else if (inet_pton(AF_INET, p, pvt->host_addr) > 0) {
-			if (pvt->res->options & RES_USE_INET6) {
-				map_v4v6_address((char*)pvt->host_addr, ap);
-				af = AF_INET6;
-				len = IN6ADDRSZ;
-			} else {
-				af = AF_INET;
-				len = INADDRSZ;
-			}
-		} else {
-			if (!multi)
-				return (NULL);
-			continue;
-		}
-		if (addr < MAXADDRS) {
-			pvt->h_addr_ptrs[addr++] = ap;
-			pvt->h_addr_ptrs[addr] = NULL;
-			ap += len;
-		}
-	} while ((p = comma) != NULL);
-	if (ap == pvt->hostbuf)
-		return (NULL);
-	pvt->host.h_addr_list = pvt->h_addr_ptrs;
-	pvt->host.h_length = len;
-	pvt->host.h_addrtype = af;
-	cp += strspn(cp, spaces);
-	pvt->host.h_name = cp;
-	q = pvt->host.h_aliases = pvt->host_aliases;
-	if ((cp = strpbrk(cp, spaces)) != NULL)
-		*cp++ = '\0';
-	while (cp && *cp) {
-		if (*cp == ' ' || *cp == '\t') {
-			cp++;
-			continue;
-		}
-		if (q < &pvt->host_aliases[MAXALIASES])
-			*q++ = cp;
-		if ((cp = strpbrk(cp, spaces)) != NULL)
-			*cp++ = '\0';
-	}
-	*q = NULL;
-	RES_SET_H_ERRNO(pvt->res, NETDB_SUCCESS);
-	return (&pvt->host);
-}
-
-static void
-nisfree(struct pvt *pvt, enum do_what do_what) {
-	if ((do_what & do_key) && pvt->curkey_data) {
-		free(pvt->curkey_data);
-		pvt->curkey_data = NULL;
-	}
-	if ((do_what & do_val) && pvt->curval_data) {
-		free(pvt->curval_data);
-		pvt->curval_data = NULL;
-	}
-}
-
-static int
-init(struct irs_ho *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	
-	if (!pvt->res && !ho_res_get(this))
-		return (-1);
-	if (((pvt->res->options & RES_INIT) == 0) &&
-	    res_ninit(pvt->res) == -1)
-		return (-1);
-	return (0);
-}
-#endif /*WANT_IRS_NIS*/
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/nis_ng.c b/contrib/bind9/lib/bind/irs/nis_ng.c
deleted file mode 100644
index f2298b2..0000000
--- a/contrib/bind9/lib/bind/irs/nis_ng.c
+++ /dev/null
@@ -1,304 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: nis_ng.c,v 1.3.18.1 2005/04/27 05:01:03 sra Exp $";
-#endif
-
-/* Imports */
-
-#include "port_before.h"
-
-#ifndef WANT_IRS_NIS
-static int __bind_irs_nis_unneeded;
-#else
-
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <rpc/rpc.h>
-#include <rpc/xdr.h>
-#include <rpcsvc/yp_prot.h>
-#include <rpcsvc/ypclnt.h>
-
-#include <isc/assertions.h>
-#include <ctype.h>
-#include <errno.h>
-#include <netdb.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-
-#include <netinet/in.h>
-#ifdef T_NULL
-#undef T_NULL			/* Silence re-definition warning of T_NULL. */
-#endif
-#include <arpa/nameser.h>
-#include <resolv.h>
-
-#include <isc/memcluster.h>
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "nis_p.h"
-
-/* Definitions */
-
-struct tmpgrp {
-	const char *	name;
-	const char *	host;
-	const char *	user;
-	const char *	domain;
-	struct tmpgrp *	next;
-};
-
-struct pvt {
-	char *		nis_domain;
-	struct tmpgrp *	tmp;
-	struct tmpgrp *	cur;
-	char *		tmpgroup;
-};
-
-enum do_what { do_none = 0x0, do_key = 0x1, do_val = 0x2, do_all = 0x3 };
-
-static /*const*/ char netgroup_map[]	= "netgroup";
-
-/* Forward */
-
-static void 		ng_close(struct irs_ng *);
-static int		ng_next(struct irs_ng *, const char **,
-				const char **, const char **);
-static int		ng_test(struct irs_ng *,
- 				const char *, const char *,
-				const char *, const char *);
-static void		ng_rewind(struct irs_ng *, const char *);
-static void		ng_minimize(struct irs_ng *);
-
-static void		add_group_to_list(struct pvt *, const char *, int);
-static void		add_tuple_to_list(struct pvt *, const char *, char *);
-static void		tmpfree(struct pvt *);
-
-/* Public */
-
-struct irs_ng *
-irs_nis_ng(struct irs_acc *this) {
-	struct irs_ng *ng;
-	struct pvt *pvt;
-
-	if (!(ng = memget(sizeof *ng))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(ng, 0x5e, sizeof *ng);
-	if (!(pvt = memget(sizeof *pvt))) {
-		memput(ng, sizeof *ng);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	pvt->nis_domain = ((struct nis_p *)this->private)->domain;
-	ng->private = pvt;
-	ng->close = ng_close;
-	ng->next = ng_next;
-	ng->test = ng_test;
-	ng->rewind = ng_rewind;
-	ng->minimize = ng_minimize;
-	return (ng);
-}
-
-/* Methods */
-
-static void
-ng_close(struct irs_ng *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	tmpfree(pvt);
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-static int
-ng_next(struct irs_ng *this, const char **host, const char **user, const char **domain) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (!pvt->cur)
-		return (0);
-	*host = pvt->cur->host;
-	*user = pvt->cur->user;
-	*domain = pvt->cur->domain;
-	pvt->cur = pvt->cur->next;
-	return (1);
-}
-
-static int
-ng_test(struct irs_ng *this, const char *name,
-	const char *host, const char *user, const char *domain)
-{
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct tmpgrp *cur;
-
-	tmpfree(pvt);
-	add_group_to_list(pvt, name, strlen(name));
-	for (cur = pvt->tmp; cur; cur = cur->next) {
-		if ((!host || !cur->host || !strcmp(host, cur->host)) &&
-		    (!user || !cur->user || !strcmp(user, cur->user)) &&
-		    (!domain || !cur->domain || !strcmp(domain, cur->domain)))
-			break;
-	}
-	tmpfree(pvt);
-	return ((cur == NULL) ? 0 : 1);
-}
-
-static void
-ng_rewind(struct irs_ng *this, const char *name) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	/* Either hand back or free the existing list. */
-	if (pvt->tmpgroup) {
-		if (pvt->tmp && !strcmp(pvt->tmpgroup, name))
-			goto reset;
-		tmpfree(pvt);
-	}
-	pvt->tmpgroup = strdup(name);
-	add_group_to_list(pvt, name, strlen(name));
- reset:
-	pvt->cur = pvt->tmp;
-}
-
-static void
-ng_minimize(struct irs_ng *this) {
-	UNUSED(this);
-	/* NOOP */
-}
-
-/* Private */
-
-static void
-add_group_to_list(struct pvt *pvt, const char *name, int len) {
-	char *vdata, *cp, *np;
-	struct tmpgrp *tmp;
-	int vlen, r;
-	char *nametmp;
-
-	/* Don't add the same group to the list more than once. */
-	for (tmp = pvt->tmp; tmp; tmp = tmp->next)
-		if (!strcmp(tmp->name, name))
-			return;
-
-	DE_CONST(name, nametmp);
-	r = yp_match(pvt->nis_domain, netgroup_map, nametmp, len,
-		     &vdata, &vlen);
-	if (r == 0) {
-		cp = vdata;
-		if (*cp && cp[strlen(cp)-1] == '\n')
-                  cp[strlen(cp)-1] = '\0';
-		for ( ; cp; cp = np) {
-			np = strchr(cp, ' ');
-			if (np)
-				*np++ = '\0';
-			if (*cp == '(')
-				add_tuple_to_list(pvt, name, cp);
-			else
-				add_group_to_list(pvt, cp, strlen(cp));
-		}
-		free(vdata);
-	}
-}
-
-static void
-add_tuple_to_list(struct pvt *pvt, const char *name, char *cp) {
-	struct tmpgrp *tmp;
-	char *tp, *np;
-
-	INSIST(*cp++ == '(');
-
-	tmp = malloc(sizeof *tmp + strlen(name) + sizeof '\0' +
-		     strlen(cp) - sizeof ')');
-	if (!tmp)
-		return;
-	memset(tmp, 0, sizeof *tmp);
-	tp = ((char *)tmp) + sizeof *tmp;
-
-	/* Name */
-	strcpy(tp, name);
-	tmp->name = tp;
-	tp += strlen(tp) + 1;
-
-	/* Host */
-	if (!(np = strchr(cp, ',')))
-		goto cleanup;
-	*np++ = '\0';
-	strcpy(tp, cp);
-	tmp->host = tp;
-	tp += strlen(tp) + 1;
-	cp = np;
-
-	/* User */
-	if (!(np = strchr(cp, ',')))
-		goto cleanup;
-	*np++ = '\0';
-	strcpy(tp, cp);
-	tmp->user = tp;
-	tp += strlen(tp) + 1;
-	cp = np;
-
-	/* Domain */
-	if (!(np = strchr(cp, ')')))
-		goto cleanup;
-	*np++ = '\0';
-	strcpy(tp, cp);
-	tmp->domain = tp;
-
-	/*
-	 * Empty string in file means wildcard, but
-	 * NULL string in return value means wildcard.
-	 */
-	if (!*tmp->host)
-		tmp->host = NULL;
-	if (!*tmp->user)
-		tmp->user = NULL;
-	if (!*tmp->domain)
-		tmp->domain = NULL;
-
-	/* Add to list (LIFO). */
-	tmp->next = pvt->tmp;
-	pvt->tmp = tmp;
-	return;
-
- cleanup:
-	free(tmp);
-}
-
-static void
-tmpfree(struct pvt *pvt) {
-	struct tmpgrp *cur, *next;
-
-	if (pvt->tmpgroup) {
-		free(pvt->tmpgroup);
-		pvt->tmpgroup = NULL;
-	}
-	for (cur = pvt->tmp; cur; cur = next) {
-		next = cur->next;
-		free(cur);
-	}
-	pvt->tmp = NULL;
-}
-
-#endif /*WANT_IRS_NIS*/
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/nis_nw.c b/contrib/bind9/lib/bind/irs/nis_nw.c
deleted file mode 100644
index 2fb50dc..0000000
--- a/contrib/bind9/lib/bind/irs/nis_nw.c
+++ /dev/null
@@ -1,385 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: nis_nw.c,v 1.3.18.1 2005/04/27 05:01:03 sra Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-/* Imports */
-
-#include "port_before.h"
-
-#ifndef WANT_IRS_NIS
-static int __bind_irs_nis_unneeded;
-#else
-
-#include <sys/types.h>
-#include <sys/socket.h>
-
-#include <netinet/in.h>
-#include <arpa/inet.h>
-#include <arpa/nameser.h>
-#ifdef T_NULL
-#undef T_NULL		/* Silence re-definition warning of T_NULL. */
-#endif
-#include <rpc/rpc.h>
-#include <rpc/xdr.h>
-#include <rpcsvc/yp_prot.h>
-#include <rpcsvc/ypclnt.h>
-
-#include <errno.h>
-#include <resolv.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-
-#include <isc/memcluster.h>
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "nis_p.h"
-
-/* Definitions */
-
-#define MAXALIASES 35
-#define MAXADDRSIZE 4
-
-struct pvt {
-	int		needrewind;
-	char *		nis_domain;
-	char *		curkey_data;
-	int		curkey_len;
-	char *		curval_data;
-	int		curval_len;
-
-	struct nwent 	nwent;
-	char *		nwbuf;
-
-	char *		aliases[MAXALIASES + 1];
-	u_char		addr[MAXADDRSIZE];
-
-	struct __res_state *  res;
-	void		(*free_res)(void *);
-};
-
-enum do_what { do_none = 0x0, do_key = 0x1, do_val = 0x2, do_all = 0x3 };
-
-static /*const*/ char networks_byname[] = "networks.byname";
-static /*const*/ char networks_byaddr[] = "networks.byaddr";
-
-/* Forward */
-
-static void 		nw_close(struct irs_nw *);
-static struct nwent *	nw_byname(struct irs_nw *, const char *, int);
-static struct nwent *	nw_byaddr(struct irs_nw *, void *, int, int);
-static struct nwent *	nw_next(struct irs_nw *);
-static void		nw_rewind(struct irs_nw *);
-static void		nw_minimize(struct irs_nw *);
-static struct __res_state * nw_res_get(struct irs_nw *this);
-static void		nw_res_set(struct irs_nw *this,
-				   struct __res_state *res,
-				   void (*free_res)(void *));
-
-static struct nwent *	makenwent(struct irs_nw *this);
-static void		nisfree(struct pvt *, enum do_what);
-static int		init(struct irs_nw *this);
-
-/* Public */
-
-struct irs_nw *
-irs_nis_nw(struct irs_acc *this) {
-	struct irs_nw *nw;
-	struct pvt *pvt;
-
-	if (!(pvt = memget(sizeof *pvt))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	if (!(nw = memget(sizeof *nw))) {
-		memput(pvt, sizeof *pvt);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(nw, 0x5e, sizeof *nw);
-	pvt->needrewind = 1;
-	pvt->nis_domain = ((struct nis_p *)this->private)->domain;
-	nw->private = pvt;
-	nw->close = nw_close;
-	nw->byname = nw_byname;
-	nw->byaddr = nw_byaddr;
-	nw->next = nw_next;
-	nw->rewind = nw_rewind;
-	nw->minimize = nw_minimize;
-	nw->res_get = nw_res_get;
-	nw->res_set = nw_res_set;
-	return (nw);
-}
-
-/* Methods */
-
-static void
-nw_close(struct irs_nw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;	
-
-	nw_minimize(this);
-	if (pvt->res && pvt->free_res)
-		(*pvt->free_res)(pvt->res);
-	if (pvt->nwbuf)
-		free(pvt->nwbuf);
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-static struct nwent *
-nw_byaddr(struct irs_nw *this, void *net, int length, int af) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	char tmp[sizeof "255.255.255.255/32"], *t;
-	int r;
-
-	if (init(this) == -1)
-		return (NULL);
-
-	if (af != AF_INET) {
-		RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL);
-		errno = EAFNOSUPPORT;
-		return (NULL);
-	}
-	nisfree(pvt, do_val);
-	/* Try it with /CIDR first. */
-	if (inet_net_ntop(AF_INET, net, length, tmp, sizeof tmp) == NULL) {
-		RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL);
-		return (NULL);
-	}
-	r = yp_match(pvt->nis_domain, networks_byaddr, tmp, strlen(tmp),
-		     &pvt->curval_data, &pvt->curval_len);
-	if (r != 0) {
-		/* Give it a shot without the /CIDR. */
-		if ((t = strchr(tmp, '/')) != NULL) {
-			*t = '\0';
-			r = yp_match(pvt->nis_domain, networks_byaddr,
-				     tmp, strlen(tmp),
-				     &pvt->curval_data, &pvt->curval_len);
-		}
-		if (r != 0) {
-			RES_SET_H_ERRNO(pvt->res, HOST_NOT_FOUND);
-			return (NULL);
-		}
-	}
-	return (makenwent(this));
-}
-
-static struct nwent *
-nw_byname(struct irs_nw *this, const char *name, int af) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	int r;
-	char *tmp;
-	
-	if (init(this) == -1)
-		return (NULL);
-
-	if (af != AF_INET) {
-		RES_SET_H_ERRNO(pvt->res, NETDB_INTERNAL);
-		errno = EAFNOSUPPORT;
-		return (NULL);
-	}
-	nisfree(pvt, do_val);
-	DE_CONST(name, tmp);
-	r = yp_match(pvt->nis_domain, networks_byname, tmp,
-		     strlen(tmp), &pvt->curval_data, &pvt->curval_len);
-	if (r != 0) {
-		RES_SET_H_ERRNO(pvt->res, HOST_NOT_FOUND);
-		return (NULL);
-	}
-	return (makenwent(this));
-}
-
-static void
-nw_rewind(struct irs_nw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	pvt->needrewind = 1;
-}
-
-static struct nwent *
-nw_next(struct irs_nw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct nwent *rval;
-	int r;
-
-	if (init(this) == -1)
-		return (NULL);
-
-	do {
-		if (pvt->needrewind) {
-			nisfree(pvt, do_all);
-			r = yp_first(pvt->nis_domain, networks_byaddr,
-				     &pvt->curkey_data, &pvt->curkey_len,
-				     &pvt->curval_data, &pvt->curval_len);
-			pvt->needrewind = 0;
-		} else {
-			char *newkey_data;
-			int newkey_len;
-
-			nisfree(pvt, do_val);
-			r = yp_next(pvt->nis_domain, networks_byaddr,
-				    pvt->curkey_data, pvt->curkey_len,
-				    &newkey_data, &newkey_len,
-				    &pvt->curval_data, &pvt->curval_len);
-			nisfree(pvt, do_key);
-			pvt->curkey_data = newkey_data;
-			pvt->curkey_len = newkey_len;
-		}
-		if (r != 0) {
-			RES_SET_H_ERRNO(pvt->res, HOST_NOT_FOUND);
-			return (NULL);
-		}
-		rval = makenwent(this);
-	} while (rval == NULL);
-	return (rval);
-}
-
-static void
-nw_minimize(struct irs_nw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (pvt->res)
-		res_nclose(pvt->res);
-}
-
-static struct __res_state *
-nw_res_get(struct irs_nw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (!pvt->res) {
-		struct __res_state *res;
-		res = (struct __res_state *)malloc(sizeof *res);
-		if (!res) {
-			errno = ENOMEM;
-			return (NULL);
-		}
-		memset(res, 0, sizeof *res);
-		nw_res_set(this, res, free);
-	}
-
-	return (pvt->res);
-}
-
-static void
-nw_res_set(struct irs_nw *this, struct __res_state *res,
-		void (*free_res)(void *)) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	if (pvt->res && pvt->free_res) {
-		res_nclose(pvt->res);
-		(*pvt->free_res)(pvt->res);
-	}
-
-	pvt->res = res;
-	pvt->free_res = free_res;
-}
-
-/* Private */
-
-static struct nwent *
-makenwent(struct irs_nw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	static const char spaces[] = " \t";
-	char *t, *cp, **ap;
-
-	if (pvt->nwbuf)
-		free(pvt->nwbuf);
-	pvt->nwbuf = pvt->curval_data;
-	pvt->curval_data = NULL;
-
-	if ((cp = strpbrk(pvt->nwbuf, "#\n")) != NULL)
-		*cp = '\0';
-	cp = pvt->nwbuf;
-
-	/* Name */
-	pvt->nwent.n_name = cp;
-	cp += strcspn(cp, spaces);
-	if (!*cp)
-		goto cleanup;
-	*cp++ = '\0';
-	cp += strspn(cp, spaces);
-
-	/* Network */
-	pvt->nwent.n_addrtype = AF_INET;
-	t = cp + strcspn(cp, spaces);
-	if (*t)
-		*t++ = '\0';
-	pvt->nwent.n_length = inet_net_pton(AF_INET, cp,
-					    pvt->addr, sizeof pvt->addr);
-	if (pvt->nwent.n_length < 0)
-		goto cleanup;
-	pvt->nwent.n_addr = pvt->addr;
-	cp = t;
-
-	/* Aliases */
-	ap = pvt->nwent.n_aliases = pvt->aliases;
-	while (*cp) {
-		if (ap >= &pvt->aliases[MAXALIASES])
-			break;
-		*ap++ = cp;
-		cp += strcspn(cp, spaces);
-		if (!*cp)
-			break;
-		*cp++ = '\0';
-		cp += strspn(cp, spaces);
-	}
-	*ap = NULL;
-
-	return (&pvt->nwent);
-
- cleanup:
-	if (pvt->nwbuf) {
-		free(pvt->nwbuf);
-		pvt->nwbuf = NULL;
-	}
-	return (NULL);
-}
-
-static void
-nisfree(struct pvt *pvt, enum do_what do_what) {
-	if ((do_what & do_key) && pvt->curkey_data) {
-		free(pvt->curkey_data);
-		pvt->curkey_data = NULL;
-	}
-	if ((do_what & do_val) && pvt->curval_data) {
-		free(pvt->curval_data);
-		pvt->curval_data = NULL;
-	}
-}
-
-static int
-init(struct irs_nw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	
-	if (!pvt->res && !nw_res_get(this))
-		return (-1);
-	if (((pvt->res->options & RES_INIT) == 0) &&
-	    res_ninit(pvt->res) == -1)
-		return (-1);
-	return (0);
-}
-
-#endif /*WANT_IRS_NIS*/
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/nis_p.h b/contrib/bind9/lib/bind/irs/nis_p.h
deleted file mode 100644
index 9e7f26c..0000000
--- a/contrib/bind9/lib/bind/irs/nis_p.h
+++ /dev/null
@@ -1,47 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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: nis_p.h,v 1.2.18.1 2005/04/27 05:01:04 sra Exp $
- */
-
-/*! \file
- * \brief
- * nis_p.h - private include file for the NIS functions.
- */
-
-/*%
- * Object state.
- */
-struct nis_p {
-	char *			domain;
-	struct __res_state *	res;
-	void                    (*free_res) __P((void *));
-};
-
-
-/*
- * Methods.
- */
-
-extern struct irs_gr *	irs_nis_gr __P((struct irs_acc *));
-extern struct irs_pw *	irs_nis_pw __P((struct irs_acc *));
-extern struct irs_sv *	irs_nis_sv __P((struct irs_acc *));
-extern struct irs_pr *	irs_nis_pr __P((struct irs_acc *));
-extern struct irs_ho *	irs_nis_ho __P((struct irs_acc *));
-extern struct irs_nw *	irs_nis_nw __P((struct irs_acc *));
-extern struct irs_ng *	irs_nis_ng __P((struct irs_acc *));
diff --git a/contrib/bind9/lib/bind/irs/nis_pr.c b/contrib/bind9/lib/bind/irs/nis_pr.c
deleted file mode 100644
index 58ff84d..0000000
--- a/contrib/bind9/lib/bind/irs/nis_pr.c
+++ /dev/null
@@ -1,302 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: nis_pr.c,v 1.3.18.1 2005/04/27 05:01:04 sra Exp $";
-#endif
-
-/* Imports */
-
-#include "port_before.h"
-
-#ifndef WANT_IRS_NIS
-static int __bind_irs_nis_unneeded;
-#else
-
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <resolv.h>
-#ifdef T_NULL
-#undef T_NULL			/* Silence re-definition warning of T_NULL. */
-#endif
-#include <rpc/rpc.h>
-#include <rpc/xdr.h>
-#include <rpcsvc/yp_prot.h>
-#include <rpcsvc/ypclnt.h>
-
-#include <stdio.h>
-#include <string.h>
-#include <netdb.h>
-#include <ctype.h>
-#include <stdlib.h>
-#include <errno.h>
-
-#include <isc/memcluster.h>
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "nis_p.h"
-
-/* Definitions */
-
-struct pvt {
-	int		needrewind;
-	char *		nis_domain;
-	char *		curkey_data;
-	int		curkey_len;
-	char *		curval_data;
-	int		curval_len;
-	struct protoent	proto;
-	char *		prbuf;
-};
-
-enum do_what { do_none = 0x0, do_key = 0x1, do_val = 0x2, do_all = 0x3 };
-
-static /*const*/ char protocols_byname[] =	"protocols.byname";
-static /*const*/ char protocols_bynumber[] =	"protocols.bynumber";
-
-/* Forward */
-
-static void 			pr_close(struct irs_pr *);
-static struct protoent *	pr_byname(struct irs_pr *, const char *);
-static struct protoent *	pr_bynumber(struct irs_pr *, int);
-static struct protoent *	pr_next(struct irs_pr *);
-static void			pr_rewind(struct irs_pr *);
-static void			pr_minimize(struct irs_pr *);
-
-static struct protoent *	makeprotoent(struct irs_pr *this);
-static void			nisfree(struct pvt *, enum do_what);
-
-/* Public */
-
-struct irs_pr *
-irs_nis_pr(struct irs_acc *this) {
-	struct irs_pr *pr;
-	struct pvt *pvt;
-
-	if (!(pr = memget(sizeof *pr))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pr, 0x5e, sizeof *pr);
-	if (!(pvt = memget(sizeof *pvt))) {
-		memput(pr, sizeof *pr);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	pvt->needrewind = 1;
-	pvt->nis_domain = ((struct nis_p *)this->private)->domain;
-	pr->private = pvt;
-	pr->byname = pr_byname;
-	pr->bynumber = pr_bynumber;
-	pr->next = pr_next;
-	pr->rewind = pr_rewind;
-	pr->close = pr_close;
-	pr->minimize = pr_minimize;
-	pr->res_get = NULL;
-	pr->res_set = NULL;
-	return (pr);
-}
-
-/* Methods. */
-
-static void
-pr_close(struct irs_pr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	nisfree(pvt, do_all);
-	if (pvt->proto.p_aliases)
-		free(pvt->proto.p_aliases);
-	if (pvt->prbuf)
-		free(pvt->prbuf);
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-static struct protoent *
-pr_byname(struct irs_pr *this, const char *name) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	int r;
-	char *tmp;
-	
-	nisfree(pvt, do_val);
-	DE_CONST(name, tmp);
-	r = yp_match(pvt->nis_domain, protocols_byname, tmp,
-		     strlen(tmp), &pvt->curval_data, &pvt->curval_len);
-	if (r != 0) {
-		errno = ENOENT;
-		return (NULL);
-	}
-	return (makeprotoent(this));
-}
-
-static struct protoent *
-pr_bynumber(struct irs_pr *this, int num) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	char tmp[sizeof "-4294967295"];
-	int r;
-	
-	nisfree(pvt, do_val);
-	(void) sprintf(tmp, "%d", num);
-	r = yp_match(pvt->nis_domain, protocols_bynumber, tmp, strlen(tmp),
-		     &pvt->curval_data, &pvt->curval_len);
-	if (r != 0) {
-		errno = ENOENT;
-		return (NULL);
-	}
-	return (makeprotoent(this));
-}
-
-static struct protoent *
-pr_next(struct irs_pr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct protoent *rval;
-	int r;
-
-	do {
-		if (pvt->needrewind) {
-			nisfree(pvt, do_all);
-			r = yp_first(pvt->nis_domain, protocols_bynumber,
-				     &pvt->curkey_data, &pvt->curkey_len,
-				     &pvt->curval_data, &pvt->curval_len);
-			pvt->needrewind = 0;
-		} else {
-			char *newkey_data;
-			int newkey_len;
-
-			nisfree(pvt, do_val);
-			r = yp_next(pvt->nis_domain, protocols_bynumber,
-				    pvt->curkey_data, pvt->curkey_len,
-				    &newkey_data, &newkey_len,
-				    &pvt->curval_data, &pvt->curval_len);
-			nisfree(pvt, do_key);
-			pvt->curkey_data = newkey_data;
-			pvt->curkey_len = newkey_len;
-		}
-		if (r != 0) {
-			errno = ENOENT;
-			return (NULL);
-		}
-		rval = makeprotoent(this);
-	} while (rval == NULL);
-	return (rval);
-}
-
-static void
-pr_rewind(struct irs_pr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	pvt->needrewind = 1;
-}
-
-static void
-pr_minimize(struct irs_pr *this) {
-	UNUSED(this);
-	/* NOOP */
-}
-
-/* Private */
-
-static struct protoent *
-makeprotoent(struct irs_pr *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	char *p, **t;
-	int n, m;
-
-	if (pvt->prbuf)
-		free(pvt->prbuf);
-	pvt->prbuf = pvt->curval_data;
-	pvt->curval_data = NULL;
-
-	for (p = pvt->prbuf; *p && *p != '#';)
-		p++;
-	while (p > pvt->prbuf && isspace((unsigned char)(p[-1])))
-		p--;
-	*p = '\0';
-
-	p = pvt->prbuf;
-	n = m = 0;
-
-	pvt->proto.p_name = p;
-	while (*p && !isspace((unsigned char)*p))
-		p++;
-	if (!*p)
-		return (NULL);
-	*p++ = '\0';
-
-	while (*p && isspace((unsigned char)*p))
-		p++;
-	pvt->proto.p_proto = atoi(p);
-	while (*p && !isspace((unsigned char)*p))
-		p++;
-	*p++ = '\0';
-
-	while (*p) {
-		if ((n + 1) >= m || !pvt->proto.p_aliases) {
-			m += 10;
-			t = realloc(pvt->proto.p_aliases,
-				      m * sizeof(char *));
-			if (!t) {
-				errno = ENOMEM;
-				goto cleanup;
-			}
-			pvt->proto.p_aliases = t;
-		}
-		pvt->proto.p_aliases[n++] = p;
-		while (*p && !isspace((unsigned char)*p))
-			p++;
-		if (*p)
-			*p++ = '\0';
-	}
-	if (!pvt->proto.p_aliases)
-		pvt->proto.p_aliases = malloc(sizeof(char *));
-	if (!pvt->proto.p_aliases)
-		goto cleanup;
-	pvt->proto.p_aliases[n] = NULL;
-	return (&pvt->proto);
-	
- cleanup:
-	if (pvt->proto.p_aliases) {
-		free(pvt->proto.p_aliases);
-		pvt->proto.p_aliases = NULL;
-	}
-	if (pvt->prbuf) {
-		free(pvt->prbuf);
-		pvt->prbuf = NULL;
-	}
-	return (NULL);
-}
-
-static void
-nisfree(struct pvt *pvt, enum do_what do_what) {
-	if ((do_what & do_key) && pvt->curkey_data) {
-		free(pvt->curkey_data);
-		pvt->curkey_data = NULL;
-	}
-	if ((do_what & do_val) && pvt->curval_data) {
-		free(pvt->curval_data);
-		pvt->curval_data = NULL;
-	}
-}
-
-#endif /*WANT_IRS_NIS*/
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/nis_pw.c b/contrib/bind9/lib/bind/irs/nis_pw.c
deleted file mode 100644
index 02c6b42..0000000
--- a/contrib/bind9/lib/bind/irs/nis_pw.c
+++ /dev/null
@@ -1,288 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: nis_pw.c,v 1.3.18.1 2005/04/27 05:01:04 sra Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-/* Imports */
-
-#include "port_before.h"
-
-#if !defined(WANT_IRS_PW) || !defined(WANT_IRS_NIS)
-static int __bind_irs_pw_unneeded;
-#else
-
-#include <sys/param.h>
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <resolv.h>
-#include <isc/memcluster.h>
-#include <rpc/rpc.h>
-#include <rpc/xdr.h>
-#include <rpcsvc/yp_prot.h>
-#include <rpcsvc/ypclnt.h>
-
-#include <errno.h>
-#include <fcntl.h>
-#include <pwd.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <unistd.h>
-
-#include <isc/memcluster.h>
-
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "nis_p.h"
-
-/* Definitions */
-
-struct pvt {
-	int		needrewind;
-	char *		nis_domain;
-	char *		curkey_data;
-	int		curkey_len;
-	char *		curval_data;
-	int		curval_len;
-	struct passwd 	passwd;
-	char *		pwbuf;
-};
-
-enum do_what { do_none = 0x0, do_key = 0x1, do_val = 0x2, do_all = 0x3 };
-
-static /*const*/ char passwd_byname[] =	"passwd.byname";
-static /*const*/ char passwd_byuid[] =	"passwd.byuid";
-
-/* Forward */
-
-static void			pw_close(struct irs_pw *);
-static struct passwd *		pw_next(struct irs_pw *);
-static struct passwd *		pw_byname(struct irs_pw *, const char *);
-static struct passwd *		pw_byuid(struct irs_pw *, uid_t);
-static void			pw_rewind(struct irs_pw *);
-static void			pw_minimize(struct irs_pw *);
-
-static struct passwd *		makepasswdent(struct irs_pw *);
-static void			nisfree(struct pvt *, enum do_what);
-
-/* Public */
-
-struct irs_pw *
-irs_nis_pw(struct irs_acc *this) {
-	struct irs_pw *pw;
-	struct pvt *pvt;
-		 
-        if (!(pw = memget(sizeof *pw))) {
-                errno = ENOMEM;
-                return (NULL);
-        }
-        memset(pw, 0x5e, sizeof *pw);
-        if (!(pvt = memget(sizeof *pvt))) {
-                memput(pw, sizeof *pw);
-                errno = ENOMEM;
-                return (NULL);
-        }
-        memset(pvt, 0, sizeof *pvt);
-	pvt->needrewind = 1;
-	pvt->nis_domain = ((struct nis_p *)this->private)->domain;
-	pw->private = pvt;
-	pw->close = pw_close;
-	pw->next = pw_next;
-	pw->byname = pw_byname;
-	pw->byuid = pw_byuid;
-	pw->rewind = pw_rewind;
-	pw->minimize = pw_minimize;
-	pw->res_get = NULL;
-	pw->res_set = NULL;
-	return (pw);
-}
-
-/* Methods */
-
-static void
-pw_close(struct irs_pw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	
-	if (pvt->pwbuf)
-		free(pvt->pwbuf);
-	nisfree(pvt, do_all);
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-static struct passwd *
-pw_next(struct irs_pw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct passwd *rval;
-	int r;
-
-	do {
-		if (pvt->needrewind) {
-			nisfree(pvt, do_all);
-			r = yp_first(pvt->nis_domain, passwd_byname,
-				     &pvt->curkey_data, &pvt->curkey_len,
-				     &pvt->curval_data, &pvt->curval_len);
-			pvt->needrewind = 0;
-		} else {
-			char *newkey_data;
-			int newkey_len;
-
-			nisfree(pvt, do_val);
-			r = yp_next(pvt->nis_domain, passwd_byname,
-				    pvt->curkey_data, pvt->curkey_len,
-				    &newkey_data, &newkey_len,
-				    &pvt->curval_data, &pvt->curval_len);
-			nisfree(pvt, do_key);
-			pvt->curkey_data = newkey_data;
-			pvt->curkey_len = newkey_len;
-		}
-		if (r != 0) {
-			errno = ENOENT;
-			return (NULL);
-		}
-		rval = makepasswdent(this);
-	} while (rval == NULL);
-	return (rval);
-}
-
-static struct passwd *
-pw_byname(struct irs_pw *this, const char *name) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	int r;
-	char *tmp;
-
-	nisfree(pvt, do_val);
-	DE_CONST(name, tmp);
-	r = yp_match(pvt->nis_domain, passwd_byname, tmp, strlen(tmp),
-		     &pvt->curval_data, &pvt->curval_len);
-	if (r != 0) {
-		errno = ENOENT;
-		return (NULL);
-	}
-	return (makepasswdent(this));
-}
-
-static struct passwd *
-pw_byuid(struct irs_pw *this, uid_t uid) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	char tmp[sizeof "4294967295"];
-	int r;
-
-	nisfree(pvt, do_val);
-	(void) sprintf(tmp, "%u", (unsigned int)uid);
-	r = yp_match(pvt->nis_domain, passwd_byuid, tmp, strlen(tmp),
-		     &pvt->curval_data, &pvt->curval_len);
-	if (r != 0) {
-		errno = ENOENT;
-		return (NULL);
-	}
-	return (makepasswdent(this));
-}
-
-static void
-pw_rewind(struct irs_pw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	pvt->needrewind = 1;
-}
-
-static void
-pw_minimize(struct irs_pw *this) {
-	UNUSED(this);
-	/* NOOP */
-}
-
-/* Private */
-
-static struct passwd *
-makepasswdent(struct irs_pw *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	char *cp;
-
-	memset(&pvt->passwd, 0, sizeof pvt->passwd);
-	if (pvt->pwbuf)
-		free(pvt->pwbuf);
-	pvt->pwbuf = pvt->curval_data;
-	pvt->curval_data = NULL;
-
-	cp = pvt->pwbuf;
-	pvt->passwd.pw_name = cp;
-	if (!(cp = strchr(cp, ':')))
-		goto cleanup;
-#ifdef HAS_PW_CLASS
-	pvt->passwd.pw_class = cp;	/*%< Needs to point at a \0. */
-#endif
-	*cp++ = '\0';
-
-	pvt->passwd.pw_passwd = cp;
-	if (!(cp = strchr(cp, ':')))
-		goto cleanup;
-	*cp++ = '\0';
-	
-	pvt->passwd.pw_uid = atoi(cp);
-	if (!(cp = strchr(cp, ':')))
-		goto cleanup;
-	*cp++ = '\0';
-
-	pvt->passwd.pw_gid = atoi(cp);
-	if (!(cp = strchr(cp, ':')))
-		goto cleanup;
-	*cp++ = '\0';
-
-	pvt->passwd.pw_gecos = cp;
-	if (!(cp = strchr(cp, ':')))
-		goto cleanup;
-	*cp++ = '\0';
-
-	pvt->passwd.pw_dir = cp;
-	if (!(cp = strchr(cp, ':')))
-		goto cleanup;
-	*cp++ = '\0';
-
-	pvt->passwd.pw_shell = cp;
-
-	if ((cp = strchr(cp, '\n')) != NULL)
-		*cp = '\0';
-
-	return (&pvt->passwd);
-	
- cleanup:
-	free(pvt->pwbuf);
-	pvt->pwbuf = NULL;
-	return (NULL);
-}
-
-static void
-nisfree(struct pvt *pvt, enum do_what do_what) {
-	if ((do_what & do_key) && pvt->curkey_data) {
-		free(pvt->curkey_data);
-		pvt->curkey_data = NULL;
-	}
-	if ((do_what & do_val) && pvt->curval_data) {
-		free(pvt->curval_data);
-		pvt->curval_data = NULL;
-	}
-}
-
-#endif /* WANT_IRS_PW && WANT_IRS_NIS */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/nis_sv.c b/contrib/bind9/lib/bind/irs/nis_sv.c
deleted file mode 100644
index dd307f0..0000000
--- a/contrib/bind9/lib/bind/irs/nis_sv.c
+++ /dev/null
@@ -1,310 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: nis_sv.c,v 1.3.18.1 2005/04/27 05:01:04 sra Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-/* Imports */
-
-#include "port_before.h"
-
-#ifndef WANT_IRS_NIS
-static int __bind_irs_nis_unneeded;
-#else
-
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <resolv.h>
-#include <sys/socket.h>
-#ifdef T_NULL
-#undef T_NULL			/* Silence re-definition warning of T_NULL. */
-#endif
-#include <rpc/rpc.h>
-#include <rpc/xdr.h>
-#include <rpcsvc/yp_prot.h>
-#include <rpcsvc/ypclnt.h>
-
-#include <ctype.h>
-#include <errno.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-
-#include <isc/memcluster.h>
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "nis_p.h"
-
-/* Definitions */
-
-struct pvt {
-	int		needrewind;
-	char *		nis_domain;
-	char *		curkey_data;
-	int		curkey_len;
-	char *		curval_data;
-	int		curval_len;
-	char		line[BUFSIZ+1];
-	struct servent	serv;
-	char *		svbuf;
-};
-
-enum do_what { do_none = 0x0, do_key = 0x1, do_val = 0x2, do_all = 0x3 };
-
-static /*const*/ char services_byname[] = "services.byname";
-
-/* Forward */
-
-static void			sv_close(struct irs_sv*);
-static struct servent *		sv_next(struct irs_sv *);
-static struct servent *		sv_byname(struct irs_sv *, const char *,
-					  const char *);
-static struct servent *		sv_byport(struct irs_sv *, int, const char *);
-static void			sv_rewind(struct irs_sv *);
-static void			sv_minimize(struct irs_sv *);
-
-static struct servent *		makeservent(struct irs_sv *this);
-static void			nisfree(struct pvt *, enum do_what);
-
-/* Public */
-
-struct irs_sv *
-irs_nis_sv(struct irs_acc *this) {
-	struct irs_sv *sv;
-	struct pvt *pvt;
-	
-	if (!(sv = memget(sizeof *sv))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(sv, 0x5e, sizeof *sv);
-	if (!(pvt = memget(sizeof *pvt))) {
-		memput(sv, sizeof *sv);
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(pvt, 0, sizeof *pvt);
-	pvt->needrewind = 1;
-	pvt->nis_domain = ((struct nis_p *)this->private)->domain;
-	sv->private = pvt;
-	sv->close = sv_close;
-	sv->next = sv_next;
-	sv->byname = sv_byname;
-	sv->byport = sv_byport;
-	sv->rewind = sv_rewind;
-	sv->minimize = sv_minimize;
-	sv->res_get = NULL;
-	sv->res_set = NULL;
-	return (sv);
-}
-
-/* Methods */
-
-static void
-sv_close(struct irs_sv *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	
-	nisfree(pvt, do_all);
-	if (pvt->serv.s_aliases)
-		free(pvt->serv.s_aliases);
-	if (pvt->svbuf)
-		free(pvt->svbuf);
-	memput(pvt, sizeof *pvt);
-	memput(this, sizeof *this);
-}
-
-static struct servent *
-sv_byname(struct irs_sv *this, const char *name, const char *proto) {
-	struct servent *serv;
-	char **sap;
-
-	sv_rewind(this);
-	while ((serv = sv_next(this)) != NULL) {
-		if (proto != NULL && strcmp(proto, serv->s_proto))
-			continue;
-		if (!strcmp(name, serv->s_name))
-			break;
-		for (sap = serv->s_aliases; sap && *sap; sap++)
-			if (!strcmp(name, *sap))
-				break;
-	}
-	return (serv);
-}
-
-static struct servent *
-sv_byport(struct irs_sv *this, int port, const char *proto) {
-	struct servent *serv;
-
-	sv_rewind(this);
-	while ((serv = sv_next(this)) != NULL) {
-		if (proto != NULL && strcmp(proto, serv->s_proto))
-			continue;
-		if (serv->s_port == port)
-			break;
-	}
-	return (serv);
-}
-
-static void
-sv_rewind(struct irs_sv *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-
-	pvt->needrewind = 1;
-}
-
-static struct servent *
-sv_next(struct irs_sv *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	struct servent *rval;
-	int r;
-
-	do {
-		if (pvt->needrewind) {
-			nisfree(pvt, do_all);
-			r = yp_first(pvt->nis_domain, services_byname,
-				     &pvt->curkey_data, &pvt->curkey_len,
-				     &pvt->curval_data, &pvt->curval_len);
-			pvt->needrewind = 0;
-		} else {
-			char *newkey_data;
-			int newkey_len;
-
-			nisfree(pvt, do_val);
-			r = yp_next(pvt->nis_domain, services_byname,
-				    pvt->curkey_data, pvt->curkey_len,
-				    &newkey_data, &newkey_len,
-				    &pvt->curval_data, &pvt->curval_len);
-			nisfree(pvt, do_key);
-			pvt->curkey_data = newkey_data;
-			pvt->curkey_len = newkey_len;
-		}
-		if (r != 0) {
-			errno = ENOENT;
-			return (NULL);
-		}
-		rval = makeservent(this);
-	} while (rval == NULL);
-	return (rval);
-}
-
-static void
-sv_minimize(struct irs_sv *this) {
-	UNUSED(this);
-	/* NOOP */
-}
-
-/* Private */
-
-static struct servent *
-makeservent(struct irs_sv *this) {
-	struct pvt *pvt = (struct pvt *)this->private;
-	static const char spaces[] = " \t";
-	char *p, **t;
-	int n, m;
-
-	if (pvt->svbuf)
-		free(pvt->svbuf);
-	pvt->svbuf = pvt->curval_data;
-	pvt->curval_data = NULL;
-
-	if (pvt->serv.s_aliases) {
-		free(pvt->serv.s_aliases);
-		pvt->serv.s_aliases = NULL;
-	}
-
-	if ((p = strpbrk(pvt->svbuf, "#\n")))
-		*p = '\0';
-
-	p = pvt->svbuf;
-
-	pvt->serv.s_name = p;
-	p += strcspn(p, spaces);
-	if (!*p)
-		goto cleanup;
-	*p++ = '\0';
-	p += strspn(p, spaces);
-
-	pvt->serv.s_port = htons((u_short) atoi(p));
-	pvt->serv.s_proto = NULL;
-	
-	while (*p && !isspace((unsigned char)*p))
-		if (*p++ == '/')
-			pvt->serv.s_proto = p;
-	if (!pvt->serv.s_proto)
-		goto cleanup;
-	if (*p) {
-		*p++ = '\0';
-		p += strspn(p, spaces);
-	}
-
-	n = m = 0;
-	while (*p) {
-		if ((n + 1) >= m || !pvt->serv.s_aliases) {
-			m += 10;
-			t = realloc(pvt->serv.s_aliases, m * sizeof(char *));
-			if (!t) {
-				errno = ENOMEM;
-				goto cleanup;
-			}
-			pvt->serv.s_aliases = t;
-		}
-		pvt->serv.s_aliases[n++] = p;
-		p += strcspn(p, spaces);
-		if (!*p)
-			break;
-		*p++ = '\0';
-		p += strspn(p, spaces);
-	}
-	if (!pvt->serv.s_aliases)
-		pvt->serv.s_aliases = malloc(sizeof(char *));
-	if (!pvt->serv.s_aliases)
-		goto cleanup;
-	pvt->serv.s_aliases[n] = NULL;
-	return (&pvt->serv);
-	
- cleanup:
-	if (pvt->serv.s_aliases) {
-		free(pvt->serv.s_aliases);
-		pvt->serv.s_aliases = NULL;
-	}
-	if (pvt->svbuf) {
-		free(pvt->svbuf);
-		pvt->svbuf = NULL;
-	}
-	return (NULL);
-}
-
-static void
-nisfree(struct pvt *pvt, enum do_what do_what) {
-	if ((do_what & do_key) && pvt->curkey_data) {
-		free(pvt->curkey_data);
-		pvt->curkey_data = NULL;
-	}
-	if ((do_what & do_val) && pvt->curval_data) {
-		free(pvt->curval_data);
-		pvt->curval_data = NULL;
-	}
-}
-
-#endif /*WANT_IRS_NIS*/
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/nul_ng.c b/contrib/bind9/lib/bind/irs/nul_ng.c
deleted file mode 100644
index fa9ec46..0000000
--- a/contrib/bind9/lib/bind/irs/nul_ng.c
+++ /dev/null
@@ -1,127 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: nul_ng.c,v 1.2.18.1 2005/04/27 05:01:04 sra Exp $";
-#endif
-
-/*! \file
- * \brief
- * nul_ng.c - the netgroup accessor null map
- */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <resolv.h>
-
-#include <stdio.h>
-#include <string.h>
-#include <netdb.h>
-#include <ctype.h>
-#include <stdlib.h>
-#include <errno.h>
-
-#include <irs.h>
-#include <isc/memcluster.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-#include "hesiod.h"
-#include "dns_p.h"
-
-/* Forward. */
-
-static void 		ng_close(struct irs_ng *);
-static int		ng_next(struct irs_ng *, const char **,
-				const char **, const char **);
-static int		ng_test(struct irs_ng *,
- 				const char *, const char *,
-				const char *, const char *);
-static void		ng_rewind(struct irs_ng *, const char *);
-static void		ng_minimize(struct irs_ng *);
-
-/* Public. */
-
-struct irs_ng *
-irs_nul_ng(struct irs_acc *this) {
-	struct irs_ng *ng;
-
-	UNUSED(this);
-
-	if (!(ng = memget(sizeof *ng))) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	memset(ng, 0x5e, sizeof *ng);
-	ng->private = NULL;
-	ng->close = ng_close;
-	ng->next = ng_next;
-	ng->test = ng_test;
-	ng->rewind = ng_rewind;
-	ng->minimize = ng_minimize;
-	return (ng);
-}
-
-/* Methods. */
-
-static void
-ng_close(struct irs_ng *this) {
-	memput(this, sizeof *this);
-}
-
-/* ARGSUSED */
-static int
-ng_next(struct irs_ng *this, const char **host, const char **user,
-	const char **domain)
-{
-	UNUSED(this);
-	UNUSED(host);
-	UNUSED(user);
-	UNUSED(domain);
-	errno = ENOENT;
-	return (-1);
-}
-
-static int
-ng_test(struct irs_ng *this, const char *name,
-	const char *user, const char *host, const char *domain)
-{
-	UNUSED(this);
-	UNUSED(name);
-	UNUSED(user);
-	UNUSED(host);
-	UNUSED(domain);
-	errno = ENODEV;
-	return (-1);
-}
-
-static void
-ng_rewind(struct irs_ng *this, const char *netgroup) {
-	UNUSED(this);
-	UNUSED(netgroup);
-	/* NOOP */
-}
-
-static void
-ng_minimize(struct irs_ng *this) {
-	UNUSED(this);
-	/* NOOP */
-}
diff --git a/contrib/bind9/lib/bind/irs/pathnames.h b/contrib/bind9/lib/bind/irs/pathnames.h
deleted file mode 100644
index c775de2..0000000
--- a/contrib/bind9/lib/bind/irs/pathnames.h
+++ /dev/null
@@ -1,52 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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: pathnames.h,v 1.2.18.1 2005/04/27 05:01:04 sra Exp $
- */
-
-#ifndef _PATH_IRS_CONF
-#define	_PATH_IRS_CONF "/etc/irs.conf"
-#endif
-
-#ifndef _PATH_NETWORKS 
-#define _PATH_NETWORKS  "/etc/networks"
-#endif
-
-#ifndef _PATH_GROUP
-#define _PATH_GROUP "/etc/group"
-#endif
-
-#ifndef _PATH_NETGROUP
-#define _PATH_NETGROUP "/etc/netgroup"
-#endif
-
-#ifndef _PATH_SERVICES 
-#define _PATH_SERVICES "/etc/services"
-#endif
-
-#ifdef IRS_LCL_SV_DB
-#ifndef _PATH_SERVICES_DB
-#define	_PATH_SERVICES_DB _PATH_SERVICES ".db"
-#endif
-#endif
-
-#ifndef _PATH_HESIOD_CONF
-#define _PATH_HESIOD_CONF "/etc/hesiod.conf"
-#endif
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/irs/util.c b/contrib/bind9/lib/bind/irs/util.c
deleted file mode 100644
index 5c4cc28..0000000
--- a/contrib/bind9/lib/bind/irs/util.c
+++ /dev/null
@@ -1,109 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: util.c,v 1.2.18.1 2005/04/27 05:01:05 sra Exp $";
-#endif
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/socket.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <resolv.h>
-
-#include <ctype.h>
-#include <errno.h>
-#include <stdio.h>
-#include <string.h>
-#include <stdlib.h>
-
-#include <irs.h>
-
-#include "port_after.h"
-
-#include "irs_p.h"
-
-#ifdef SPRINTF_CHAR
-# define SPRINTF(x) strlen(sprintf/**/x)
-#else
-# define SPRINTF(x) sprintf x
-#endif
-
-void
-map_v4v6_address(const char *src, char *dst) {
-	u_char *p = (u_char *)dst;
-	char tmp[NS_INADDRSZ];
-	int i;
-
-	/* Stash a temporary copy so our caller can update in place. */
-	memcpy(tmp, src, NS_INADDRSZ);
-	/* Mark this ipv6 addr as a mapped ipv4. */
-	for (i = 0; i < 10; i++)
-		*p++ = 0x00;
-	*p++ = 0xff;
-	*p++ = 0xff;
-	/* Retrieve the saved copy and we're done. */
-	memcpy((void*)p, tmp, NS_INADDRSZ);
-}
-
-int
-make_group_list(struct irs_gr *this, const char *name,
-	gid_t basegid, gid_t *groups, int *ngroups)
-{
-	struct group *grp;
-	int i, ng;
-	int ret, maxgroups;
-
-	ret = -1;
-	ng = 0;
-	maxgroups = *ngroups;
-	/*
-	 * When installing primary group, duplicate it;
-	 * the first element of groups is the effective gid
-	 * and will be overwritten when a setgid file is executed.
-	 */
-	if (ng >= maxgroups)
-		goto done;
-	groups[ng++] = basegid;
-	if (ng >= maxgroups)
-		goto done;
-	groups[ng++] = basegid;
-	/*
-	 * Scan the group file to find additional groups.
-	 */
-	(*this->rewind)(this);
-	while ((grp = (*this->next)(this)) != NULL) {
-		if ((gid_t)grp->gr_gid == basegid)
-			continue;
-		for (i = 0; grp->gr_mem[i]; i++) {
-			if (!strcmp(grp->gr_mem[i], name)) {
-				if (ng >= maxgroups)
-					goto done;
-				groups[ng++] = grp->gr_gid;
-				break;
-			}
-		}
-	}
-	ret = 0;
- done:
-	*ngroups = ng;
-	return (ret);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/isc/Makefile.in b/contrib/bind9/lib/bind/isc/Makefile.in
deleted file mode 100644
index 70b0548..0000000
--- a/contrib/bind9/lib/bind/isc/Makefile.in
+++ /dev/null
@@ -1,35 +0,0 @@
-# Copyright (C) 2004, 2008  Internet Systems Consortium, Inc. ("ISC")
-# Copyright (C) 2001  Internet Software Consortium.
-#
-# Permission to use, copy, modify, and/or 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: Makefile.in,v 1.7.18.2 2008/03/20 23:46:01 tbox Exp $
-
-srcdir=		@srcdir@
-VPATH =         @srcdir@
-
-OBJS=	assertions.@O@ base64.@O@ bitncmp.@O@ ctl_clnt.@O@ ctl_p.@O@ \
-	ctl_srvr.@O@ ev_connects.@O@ ev_files.@O@ ev_streams.@O@ \
-	ev_timers.@O@ ev_waits.@O@ eventlib.@O@ heap.@O@ hex.@O@ \
-	logging.@O@ memcluster.@O@ movefile.@O@ tree.@O@
-
-SRCS=	assertions.c base64.c bitncmp.c ctl_clnt.c ctl_p.c \
-	ctl_srvr.c ev_connects.c ev_files.c ev_streams.c \
-	ev_timers.c ev_waits.c eventlib.c heap.c hex.c logging.c \
-	memcluster.c movefile.c tree.c
-
-TARGETS= ${OBJS}
-
-CINCLUDES= -I.. -I../include -I${srcdir}/../include
-
-@BIND9_MAKE_RULES@
diff --git a/contrib/bind9/lib/bind/isc/assertions.c b/contrib/bind9/lib/bind/isc/assertions.c
deleted file mode 100644
index e4bd42a..0000000
--- a/contrib/bind9/lib/bind/isc/assertions.c
+++ /dev/null
@@ -1,94 +0,0 @@
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: assertions.c,v 1.2.18.2 2008/10/15 03:57:21 marka Exp $";
-#endif
-
-#include "port_before.h"
-
-#include <errno.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-
-#include <isc/assertions.h>
-
-#include "port_after.h"
-
-/*
- * Forward.
- */
-
-static void default_assertion_failed(const char *, int, assertion_type,
-				     const char *, int);
-
-/*
- * Public.
- */
-
-assertion_failure_callback __assertion_failed = default_assertion_failed;
-
-void
-set_assertion_failure_callback(assertion_failure_callback f) {
-	if (f == NULL)
-		__assertion_failed = default_assertion_failed;
-	else
-		__assertion_failed = f;
-}
-
-const char *
-assertion_type_to_text(assertion_type type) {
-	const char *result;
-
-	switch (type) {
-	case assert_require:
-		result = "REQUIRE";
-		break;
-	case assert_ensure:
-		result = "ENSURE";
-		break;
-	case assert_insist:
-		result = "INSIST";
-		break;
-	case assert_invariant:
-		result = "INVARIANT";
-		break;
-	default:
-		result = NULL;
-	}
-	return (result);
-}
-
-/*
- * Private.
- */
-
-/* coverity[+kill] */
-static void
-default_assertion_failed(const char *file, int line, assertion_type type,
-			 const char *cond, int print_errno)
-{
-	fprintf(stderr, "%s:%d: %s(%s)%s%s failed.\n",
-		file, line, assertion_type_to_text(type), cond,
-		(print_errno) ? ": " : "",
-		(print_errno) ? strerror(errno) : "");
-	abort();
-	/* NOTREACHED */
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/isc/assertions.mdoc b/contrib/bind9/lib/bind/isc/assertions.mdoc
deleted file mode 100644
index 4b77e56..0000000
--- a/contrib/bind9/lib/bind/isc/assertions.mdoc
+++ /dev/null
@@ -1,138 +0,0 @@
-.\" $Id: assertions.mdoc,v 1.3 2004/03/09 06:30:06 marka Exp $
-.\"
-.\" Copyright (c) 2004 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
-.\" 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.
-.\"
-.Dd November 17, 1997
-.Dt ASSERTIONS 3
-.Os ISC
-.Sh NAME
-.Nm REQUIRE ,
-.Nm REQUIRE_ERR ,
-.Nm ENSURE ,
-.Nm ENSURE_ERR ,
-.Nm INSIST ,
-.Nm INSIST_ERR ,
-.Nm INVARIANT ,
-.Nm INVARIANT_ERR ,
-.Nm set_assertion_failure_callback
-.Nd assertion system
-.Sh SYNOPSIS
-.Fd #include <isc/assertions.h>
-.Fo "typedef void (*assertion_failure_callback)"
-.Fa "char *filename"
-.Fa "int line"
-.Fa "assertion_type type"
-.Fa "char *condition"
-.Fa "int print_errno"
-.Fc
-.Fn REQUIRE "int boolean_expression"
-.Fn REQUIRE_ERR "int boolean_expression"
-.Fn ENSURE "int boolean_expression"
-.Fn ENSURE_ERR "int boolean_expression"
-.Fn INSIST "int boolean_expression"
-.Fn INSIST_ERR "int boolean_expression"
-.Fn INVARIANT "int boolean_expression"
-.Fn INVARIANT_ERR "int boolean_expression"
-.Ft void
-.Fn set_assertion_failure_callback "assertion_failure_callback callback"
-.Ft char *
-.Fn assertion_type_to_text "assertion_type type"
-.Sh DESCRIPTION
-The
-.Fn REQUIRE ,
-.Fn ENSURE ,
-.Fn INSIST ,
-and
-.Fn INVARIANT
-macros evaluate a boolean expression, and if it is false, they invoke the
-current assertion failure callback.  The default callback will print a message
-to 
-.Li stderr
-describing the failure, and then cause the program to dump core.
-If the
-.Dq Fn _ERR
-variant of the assertion is used, the callback will include
-.Fn strerror "errno"
-in its message.
-.Pp
-Each assertion type has an associated
-.Li CHECK
-macro.  If this macro's value is
-.Dq 0
-when
-.Dq "<isc/assertions.h>"
-is included, then assertions of that type will not be checked.  E.g.
-.Pp
-.Dl #define CHECK_ENSURE 0
-.Pp
-will disable checking of
-.Fn ENSURE
-and
-.Fn ENSURE_ERR .
-The macros
-.Li CHECK_ALL
-and
-.Li CHECK_NONE
-may also be used, respectively specifying that either all or none of the
-assertion types should be checked.
-.Pp
-.Fn set_assertion_failure_callback
-specifies the function to call when an assertion fails.
-.Pp
-When an
-.Fn assertion_failure_callback
-is called, the 
-.Fa filename
-and
-.Fa line
-arguments specify the filename and line number of the failing assertion.
-The
-.Fa type
-is one of:
-.Bd -literal -offset indent
-assert_require
-assert_ensure
-assert_insist
-assert_invariant
-.Ed
-.Pp
-and may be used by the callback to determine the type of the failing
-assertion.
-.Fa condition
-is the literal text of the assertion that failed. 
-.Fa print_errno
-will be non-zero if the callback should print
-.Fa strerror "errno"
-as part of its output.
-.Pp
-.Fn assertion_type_to_text
-returns a textual representation of
-.Fa type .
-For example,
-.Fn assertion_type_to_text "assert_require"
-returns the string
-.Dq REQUIRE .
-.Sh SEE ALSO
-.Rs
-.%A Bertrand Meyer
-.%B Object-Oriented Software Construction, 2nd edition
-.%Q Prentice\-Hall
-.%D 1997
-.%O ISBN 0\-13\-629155\-4
-.%P chapter 11
-.Re
-.Sh AUTHOR
-Bob Halley (ISC).
diff --git a/contrib/bind9/lib/bind/isc/base64.c b/contrib/bind9/lib/bind/isc/base64.c
deleted file mode 100644
index d4bc2ea..0000000
--- a/contrib/bind9/lib/bind/isc/base64.c
+++ /dev/null
@@ -1,322 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996-1999 by 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.
- */
-
-/*
- * Portions Copyright (c) 1995 by International Business Machines, Inc.
- *
- * International Business Machines, Inc. (hereinafter called IBM) grants
- * permission under its copyrights to use, copy, modify, and distribute this
- * Software with or without fee, provided that the above copyright notice and
- * all paragraphs of this notice appear in all copies, and that the name of IBM
- * not be used in connection with the marketing of any product incorporating
- * the Software or modifications thereof, without specific, written prior
- * permission.
- *
- * To the extent it has a right to do so, IBM grants an immunity from suit
- * under its patents, if any, for the use, sale or manufacture of products to
- * the extent that such products are used for performing Domain Name System
- * dynamic updates in TCP/IP networks by means of the Software.  No immunity is
- * granted for any product per se or for any other function of any product.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", AND IBM DISCLAIMS ALL WARRANTIES,
- * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
- * PARTICULAR PURPOSE.  IN NO EVENT SHALL IBM BE LIABLE FOR ANY SPECIAL,
- * DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER ARISING
- * OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE, EVEN
- * IF IBM IS APPRISED OF THE POSSIBILITY OF SUCH DAMAGES.
- */
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: base64.c,v 1.3.18.1 2005/04/27 05:01:05 sra Exp $";
-#endif /* not lint */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/param.h>
-#include <sys/socket.h>
-
-#include <netinet/in.h>
-#include <arpa/inet.h>
-#include <arpa/nameser.h>
-
-#include <ctype.h>
-#include <resolv.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-
-#include "port_after.h"
-
-#define Assert(Cond) if (!(Cond)) abort()
-
-static const char Base64[] =
-	"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";
-static const char Pad64 = '=';
-
-/* (From RFC1521 and draft-ietf-dnssec-secext-03.txt)
-   The following encoding technique is taken from RFC1521 by Borenstein
-   and Freed.  It is reproduced here in a slightly edited form for
-   convenience.
-
-   A 65-character subset of US-ASCII is used, enabling 6 bits to be
-   represented per printable character. (The extra 65th character, "=",
-   is used to signify a special processing function.)
-
-   The encoding process represents 24-bit groups of input bits as output
-   strings of 4 encoded characters. Proceeding from left to right, a
-   24-bit input group is formed by concatenating 3 8-bit input groups.
-   These 24 bits are then treated as 4 concatenated 6-bit groups, each
-   of which is translated into a single digit in the base64 alphabet.
-
-   Each 6-bit group is used as an index into an array of 64 printable
-   characters. The character referenced by the index is placed in the
-   output string.
-
-                         Table 1: The Base64 Alphabet
-
-      Value Encoding  Value Encoding  Value Encoding  Value Encoding
-          0 A            17 R            34 i            51 z
-          1 B            18 S            35 j            52 0
-          2 C            19 T            36 k            53 1
-          3 D            20 U            37 l            54 2
-          4 E            21 V            38 m            55 3
-          5 F            22 W            39 n            56 4
-          6 G            23 X            40 o            57 5
-          7 H            24 Y            41 p            58 6
-          8 I            25 Z            42 q            59 7
-          9 J            26 a            43 r            60 8
-         10 K            27 b            44 s            61 9
-         11 L            28 c            45 t            62 +
-         12 M            29 d            46 u            63 /
-         13 N            30 e            47 v
-         14 O            31 f            48 w         (pad) =
-         15 P            32 g            49 x
-         16 Q            33 h            50 y
-
-   Special processing is performed if fewer than 24 bits are available
-   at the end of the data being encoded.  A full encoding quantum is
-   always completed at the end of a quantity.  When fewer than 24 input
-   bits are available in an input group, zero bits are added (on the
-   right) to form an integral number of 6-bit groups.  Padding at the
-   end of the data is performed using the '=' character.
-
-   Since all base64 input is an integral number of octets, only the
-         -------------------------------------------------                       
-   following cases can arise:
-   
-       (1) the final quantum of encoding input is an integral
-           multiple of 24 bits; here, the final unit of encoded
-	   output will be an integral multiple of 4 characters
-	   with no "=" padding,
-       (2) the final quantum of encoding input is exactly 8 bits;
-           here, the final unit of encoded output will be two
-	   characters followed by two "=" padding characters, or
-       (3) the final quantum of encoding input is exactly 16 bits;
-           here, the final unit of encoded output will be three
-	   characters followed by one "=" padding character.
-   */
-
-int
-b64_ntop(u_char const *src, size_t srclength, char *target, size_t targsize) {
-	size_t datalength = 0;
-	u_char input[3];
-	u_char output[4];
-	size_t i;
-
-	while (2U < srclength) {
-		input[0] = *src++;
-		input[1] = *src++;
-		input[2] = *src++;
-		srclength -= 3;
-
-		output[0] = input[0] >> 2;
-		output[1] = ((input[0] & 0x03) << 4) + (input[1] >> 4);
-		output[2] = ((input[1] & 0x0f) << 2) + (input[2] >> 6);
-		output[3] = input[2] & 0x3f;
-		Assert(output[0] < 64);
-		Assert(output[1] < 64);
-		Assert(output[2] < 64);
-		Assert(output[3] < 64);
-
-		if (datalength + 4 > targsize)
-			return (-1);
-		target[datalength++] = Base64[output[0]];
-		target[datalength++] = Base64[output[1]];
-		target[datalength++] = Base64[output[2]];
-		target[datalength++] = Base64[output[3]];
-	}
-    
-	/* Now we worry about padding. */
-	if (0U != srclength) {
-		/* Get what's left. */
-		input[0] = input[1] = input[2] = '\0';
-		for (i = 0; i < srclength; i++)
-			input[i] = *src++;
-	
-		output[0] = input[0] >> 2;
-		output[1] = ((input[0] & 0x03) << 4) + (input[1] >> 4);
-		output[2] = ((input[1] & 0x0f) << 2) + (input[2] >> 6);
-		Assert(output[0] < 64);
-		Assert(output[1] < 64);
-		Assert(output[2] < 64);
-
-		if (datalength + 4 > targsize)
-			return (-1);
-		target[datalength++] = Base64[output[0]];
-		target[datalength++] = Base64[output[1]];
-		if (srclength == 1U)
-			target[datalength++] = Pad64;
-		else
-			target[datalength++] = Base64[output[2]];
-		target[datalength++] = Pad64;
-	}
-	if (datalength >= targsize)
-		return (-1);
-	target[datalength] = '\0';	/*%< Returned value doesn't count \\0. */
-	return (datalength);
-}
-
-/* skips all whitespace anywhere.
-   converts characters, four at a time, starting at (or after)
-   src from base - 64 numbers into three 8 bit bytes in the target area.
-   it returns the number of data bytes stored at the target, or -1 on error.
- */
-
-int
-b64_pton(src, target, targsize)
-	char const *src;
-	u_char *target;
-	size_t targsize;
-{
-	int tarindex, state, ch;
-	char *pos;
-
-	state = 0;
-	tarindex = 0;
-
-	while ((ch = *src++) != '\0') {
-		if (isspace(ch))	/*%< Skip whitespace anywhere. */
-			continue;
-
-		if (ch == Pad64)
-			break;
-
-		pos = strchr(Base64, ch);
-		if (pos == 0) 		/*%< A non-base64 character. */
-			return (-1);
-
-		switch (state) {
-		case 0:
-			if (target) {
-				if ((size_t)tarindex >= targsize)
-					return (-1);
-				target[tarindex] = (pos - Base64) << 2;
-			}
-			state = 1;
-			break;
-		case 1:
-			if (target) {
-				if ((size_t)tarindex + 1 >= targsize)
-					return (-1);
-				target[tarindex]   |=  (pos - Base64) >> 4;
-				target[tarindex+1]  = ((pos - Base64) & 0x0f)
-							<< 4 ;
-			}
-			tarindex++;
-			state = 2;
-			break;
-		case 2:
-			if (target) {
-				if ((size_t)tarindex + 1 >= targsize)
-					return (-1);
-				target[tarindex]   |=  (pos - Base64) >> 2;
-				target[tarindex+1]  = ((pos - Base64) & 0x03)
-							<< 6;
-			}
-			tarindex++;
-			state = 3;
-			break;
-		case 3:
-			if (target) {
-				if ((size_t)tarindex >= targsize)
-					return (-1);
-				target[tarindex] |= (pos - Base64);
-			}
-			tarindex++;
-			state = 0;
-			break;
-		default:
-			abort();
-		}
-	}
-
-	/*
-	 * We are done decoding Base-64 chars.  Let's see if we ended
-	 * on a byte boundary, and/or with erroneous trailing characters.
-	 */
-
-	if (ch == Pad64) {		/*%< We got a pad char. */
-		ch = *src++;		/*%< Skip it, get next. */
-		switch (state) {
-		case 0:		/*%< Invalid = in first position */
-		case 1:		/*%< Invalid = in second position */
-			return (-1);
-
-		case 2:		/*%< Valid, means one byte of info */
-			/* Skip any number of spaces. */
-			for ((void)NULL; ch != '\0'; ch = *src++)
-				if (!isspace(ch))
-					break;
-			/* Make sure there is another trailing = sign. */
-			if (ch != Pad64)
-				return (-1);
-			ch = *src++;		/*%< Skip the = */
-			/* Fall through to "single trailing =" case. */
-			/* FALLTHROUGH */
-
-		case 3:		/*%< Valid, means two bytes of info */
-			/*
-			 * We know this char is an =.  Is there anything but
-			 * whitespace after it?
-			 */
-			for ((void)NULL; ch != '\0'; ch = *src++)
-				if (!isspace(ch))
-					return (-1);
-
-			/*
-			 * Now make sure for cases 2 and 3 that the "extra"
-			 * bits that slopped past the last full byte were
-			 * zeros.  If we don't check them, they become a
-			 * subliminal channel.
-			 */
-			if (target && target[tarindex] != 0)
-				return (-1);
-		}
-	} else {
-		/*
-		 * We ended by seeing the end of the string.  Make sure we
-		 * have no partial bytes lying around.
-		 */
-		if (state != 0)
-			return (-1);
-	}
-
-	return (tarindex);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/isc/bitncmp.c b/contrib/bind9/lib/bind/isc/bitncmp.c
deleted file mode 100644
index 9bbbd24..0000000
--- a/contrib/bind9/lib/bind/isc/bitncmp.c
+++ /dev/null
@@ -1,68 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: bitncmp.c,v 1.2.18.2 2008/05/12 00:21:22 marka Exp $";
-#endif
-
-#include "port_before.h"
-
-#include <sys/types.h>
-
-#include <string.h>
-
-#include "port_after.h"
-
-#include <isc/misc.h>
-
-/*%
- * int
- * bitncmp(l, r, n)
- *	compare bit masks l and r, for n bits.
- * return:
- *	-1, 1, or 0 in the libc tradition.
- * note:
- *	network byte order assumed.  this means 192.5.5.240/28 has
- *	0x11110000 in its fourth octet.
- * author:
- *	Paul Vixie (ISC), June 1996
- */
-int
-bitncmp(const void *l, const void *r, int n) {
-	u_int lb, rb;
-	int x, b;
-
-	b = n / 8;
-	x = memcmp(l, r, b);
-	if (x || (n % 8) == 0)
-		return (x);
-
-	lb = ((const u_char *)l)[b];
-	rb = ((const u_char *)r)[b];
-	for (b = n % 8; b > 0; b--) {
-		if ((lb & 0x80) != (rb & 0x80)) {
-			if (lb & 0x80)
-				return (1);
-			return (-1);
-		}
-		lb <<= 1;
-		rb <<= 1;
-	}
-	return (0);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/isc/bitncmp.mdoc b/contrib/bind9/lib/bind/isc/bitncmp.mdoc
deleted file mode 100644
index 7d4646c..0000000
--- a/contrib/bind9/lib/bind/isc/bitncmp.mdoc
+++ /dev/null
@@ -1,82 +0,0 @@
-.\" $Id: bitncmp.mdoc,v 1.3 2004/03/09 06:30:07 marka Exp $
-.\"
-.\" Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
-.\" Copyright (c) 1996,1999 by 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.
-.\"
-.Dd June 1, 1996
-.Dt BITNCMP 3
-.Os BSD 4
-.Sh NAME
-.Nm bitncmp 
-.Nd compare bit masks
-.Sh SYNOPSIS
-.Ft int
-.Fn bitncmp "const void *l" "const void *r" "int n"
-.Sh DESCRIPTION
-The function
-.Fn bitncmp
-compares the
-.Dq Fa n
-most-significant bits of the two masks pointed to by
-.Dq Fa l
-and
-.Dq Fa r ,
-and returns an integer less than, equal to, or greater than 0, according to
-whether or not
-.Dq Fa l
-is lexicographically less than, equal to, or greater than
-.Dq Fa r
-when taken to be unsigned characters (this behaviour is just like that of
-.Xr memcmp 3 ) .
-.Pp
-.Sy NOTE :
-.Fn Bitncmp 
-assumes 
-.Sy network byte order ;
-this means that the fourth octet of 
-.Li 192.5.5.240/28 
-.Li 0x11110000 .
-.Sh RETURN VALUES
-.Fn Bitncmp
-returns values in the manner of
-.Xr memcmp 3 :
-.Bd -ragged -offset indent
-+1 if 
-.Dq Fa 1
-is greater than 
-.Dq Fa r ;
-.Pp
--1 if 
-.Dq Fa l
-is less than 
-.Dq Fa r ; 
-and
-.Pp
-0 if 
-.Dq Fa l
-is equal to
-.Dq Fa r ,
-.Ed
-.Pp
-where 
-.Dq Fa l
-and 
-.Dq Fa r
-are both interpreted as strings of unsigned characters (through bit 
-.Dq Fa n . )
-.Sh SEE ALSO
-.Xr memcmp 3 .
-.Sh AUTHOR
-Paul Vixie (ISC). 
diff --git a/contrib/bind9/lib/bind/isc/ctl_clnt.c b/contrib/bind9/lib/bind/isc/ctl_clnt.c
deleted file mode 100644
index 7627200..0000000
--- a/contrib/bind9/lib/bind/isc/ctl_clnt.c
+++ /dev/null
@@ -1,620 +0,0 @@
-#if !defined(lint) && !defined(SABER)
-static const char rcsid[] = "$Id: ctl_clnt.c,v 1.7.18.3 2008/02/18 04:04:06 marka Exp $";
-#endif /* not lint */
-
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1998,1999 by 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.
- */
-
-/* Extern. */
-
-#include "port_before.h"
-
-#include <sys/param.h>
-#include <sys/file.h>
-#include <sys/socket.h>
-
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <arpa/inet.h>
-
-#include <ctype.h>
-#include <errno.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <time.h>
-#include <unistd.h>
-#ifdef HAVE_MEMORY_H
-#include <memory.h>
-#endif
-
-#include <isc/assertions.h>
-#include <isc/ctl.h>
-#include <isc/eventlib.h>
-#include <isc/list.h>
-#include <isc/memcluster.h>
-
-#include "ctl_p.h"
-
-#include "port_after.h"
-
-/* Constants. */
-
-
-/* Macros. */
-
-#define donefunc_p(ctx) ((ctx).donefunc != NULL)
-#define arpacode_p(line) (isdigit((unsigned char)(line[0])) && \
-			  isdigit((unsigned char)(line[1])) && \
-			  isdigit((unsigned char)(line[2])))
-#define arpacont_p(line) (line[3] == '-')
-#define arpadone_p(line) (line[3] == ' ' || line[3] == '\t' || \
-			  line[3] == '\r' || line[3] == '\0')
-
-/* Types. */
-
-enum state {
-	initializing = 0, connecting, connected, destroyed
-};
-
-struct ctl_tran {
-	LINK(struct ctl_tran)	link;
-	LINK(struct ctl_tran)	wlink;
-	struct ctl_cctx *	ctx;
-	struct ctl_buf		outbuf;
-	ctl_clntdone		donefunc;
-	void *			uap;
-};
-
-struct ctl_cctx {
-	enum state		state;
-	evContext		ev;
-	int			sock;
-	ctl_logfunc		logger;
-	ctl_clntdone		donefunc;
-	void *			uap;
-	evConnID		coID;
-	evTimerID		tiID;
-	evFileID		rdID;
-	evStreamID		wrID;
-	struct ctl_buf		inbuf;
-	struct timespec		timeout;
-	LIST(struct ctl_tran)	tran;
-	LIST(struct ctl_tran)	wtran;
-};
-
-/* Forward. */
-
-static struct ctl_tran *new_tran(struct ctl_cctx *, ctl_clntdone, void *, int);
-static void		start_write(struct ctl_cctx *);
-static void		destroy(struct ctl_cctx *, int);
-static void		error(struct ctl_cctx *);
-static void		new_state(struct ctl_cctx *, enum state);
-static void		conn_done(evContext, void *, int,
-				  const void *, int,
-				  const void *, int);
-static void		write_done(evContext, void *, int, int);
-static void		start_read(struct ctl_cctx *);
-static void		stop_read(struct ctl_cctx *);
-static void		readable(evContext, void *, int, int);
-static void		start_timer(struct ctl_cctx *);
-static void		stop_timer(struct ctl_cctx *);
-static void		touch_timer(struct ctl_cctx *);
-static void		timer(evContext, void *,
-			      struct timespec, struct timespec);
-
-#ifndef HAVE_MEMCHR
-static void *
-memchr(const void *b, int c, size_t len) {
-	const unsigned char *p = b;
-	size_t i;
-
-	for (i = 0; i < len; i++, p++)
-		if (*p == (unsigned char)c)
-			return ((void *)p); 
-	return (NULL);
-}
-#endif
-
-/* Private data. */
-
-static const char * const state_names[] = {
-	"initializing", "connecting", "connected", "destroyed"
-};
-
-/* Public. */
-
-/*%
- * void
- * ctl_client()
- *	create, condition, and connect to a listener on the control port.
- */
-struct ctl_cctx *
-ctl_client(evContext lev, const struct sockaddr *cap, size_t cap_len,
-	   const struct sockaddr *sap, size_t sap_len,
-	   ctl_clntdone donefunc, void *uap,
-	   u_int timeout, ctl_logfunc logger)
-{
-	static const char me[] = "ctl_client";
-	static const int on = 1;
-	struct ctl_cctx *ctx;
-	struct sockaddr *captmp;
-
-	if (logger == NULL)
-		logger = ctl_logger;
-	ctx = memget(sizeof *ctx);
-	if (ctx == NULL) {
-		(*logger)(ctl_error, "%s: getmem: %s", me, strerror(errno));
-		goto fatal;
-	}
-	ctx->state = initializing;
-	ctx->ev = lev;
-	ctx->logger = logger;
-	ctx->timeout = evConsTime(timeout, 0);
-	ctx->donefunc = donefunc;
-	ctx->uap = uap;
-	ctx->coID.opaque = NULL;
-	ctx->tiID.opaque = NULL;
-	ctx->rdID.opaque = NULL;
-	ctx->wrID.opaque = NULL;
-	buffer_init(ctx->inbuf);
-	INIT_LIST(ctx->tran);
-	INIT_LIST(ctx->wtran);
-	ctx->sock = socket(sap->sa_family, SOCK_STREAM, PF_UNSPEC);
-	if (ctx->sock > evHighestFD(ctx->ev)) {
-		ctx->sock = -1;
-		errno = ENOTSOCK;
-	}
-	if (ctx->sock < 0) {
-		(*ctx->logger)(ctl_error, "%s: socket: %s",
-			       me, strerror(errno));
-		goto fatal;
-	}
-	if (cap != NULL) {
-		if (setsockopt(ctx->sock, SOL_SOCKET, SO_REUSEADDR,
-			       (const char *)&on, sizeof on) != 0) {
-			(*ctx->logger)(ctl_warning,
-				       "%s: setsockopt(REUSEADDR): %s",
-				       me, strerror(errno));
-		}
-		DE_CONST(cap, captmp);
-		if (bind(ctx->sock, captmp, cap_len) < 0) {
-			(*ctx->logger)(ctl_error, "%s: bind: %s", me,
-				       strerror(errno));
-			goto fatal;
-		}
-	}
-	if (evConnect(lev, ctx->sock, (const struct sockaddr *)sap, sap_len,
-		      conn_done, ctx, &ctx->coID) < 0) {
-		(*ctx->logger)(ctl_error, "%s: evConnect(fd %d): %s",
-			       me, ctx->sock, strerror(errno));
- fatal:
-		if (ctx != NULL) {
-			if (ctx->sock >= 0)
-				close(ctx->sock);
-			memput(ctx, sizeof *ctx);
-		}
-		return (NULL);
-	}
-	new_state(ctx, connecting);
-	return (ctx);
-}
-
-/*%
- * void
- * ctl_endclient(ctx)
- *	close a client and release all of its resources.
- */
-void
-ctl_endclient(struct ctl_cctx *ctx) {
-	if (ctx->state != destroyed)
-		destroy(ctx, 0);
-	memput(ctx, sizeof *ctx);
-}
-
-/*%
- * int
- * ctl_command(ctx, cmd, len, donefunc, uap)
- *	Queue a transaction, which will begin with sending cmd
- *	and complete by calling donefunc with the answer.
- */
-int
-ctl_command(struct ctl_cctx *ctx, const char *cmd, size_t len,
-	    ctl_clntdone donefunc, void *uap)
-{
-	struct ctl_tran *tran;
-	char *pc;
-	unsigned int n;
-
-	switch (ctx->state) {
-	case destroyed:
-		errno = ENOTCONN;
-		return (-1);
-	case connecting:
-	case connected:
-		break;
-	default:
-		abort();
-	}
-	if (len >= (size_t)MAX_LINELEN) {
-		errno = EMSGSIZE;
-		return (-1);
-	}
-	tran = new_tran(ctx, donefunc, uap, 1);
-	if (tran == NULL)
-		return (-1);
-	if (ctl_bufget(&tran->outbuf, ctx->logger) < 0)
-		return (-1);
-	memcpy(tran->outbuf.text, cmd, len);
-	tran->outbuf.used = len;
-	for (pc = tran->outbuf.text, n = 0; n < tran->outbuf.used; pc++, n++)
-		if (!isascii((unsigned char)*pc) ||
-		    !isprint((unsigned char)*pc))
-			*pc = '\040';
-	start_write(ctx);
-	return (0);
-}
-
-/* Private. */
-
-static struct ctl_tran *
-new_tran(struct ctl_cctx *ctx, ctl_clntdone donefunc, void *uap, int w) {
-	struct ctl_tran *new = memget(sizeof *new);
-
-	if (new == NULL)
-		return (NULL);
-	new->ctx = ctx;
-	buffer_init(new->outbuf);
-	new->donefunc = donefunc;
-	new->uap = uap;
-	INIT_LINK(new, link);
-	INIT_LINK(new, wlink);
-	APPEND(ctx->tran, new, link);
-	if (w)
-		APPEND(ctx->wtran, new, wlink);
-	return (new);
-}
-
-static void
-start_write(struct ctl_cctx *ctx) {
-	static const char me[] = "isc/ctl_clnt::start_write";
-	struct ctl_tran *tran;
-	struct iovec iov[2], *iovp = iov;
-	char * tmp;
-
-	REQUIRE(ctx->state == connecting || ctx->state == connected);
-	/* If there is a write in progress, don't try to write more yet. */
-	if (ctx->wrID.opaque != NULL)
-		return;
-	/* If there are no trans, make sure timer is off, and we're done. */
-	if (EMPTY(ctx->wtran)) {
-		if (ctx->tiID.opaque != NULL)
-			stop_timer(ctx);
-		return;
-	}
-	/* Pull it off the head of the write queue. */
-	tran = HEAD(ctx->wtran);
-	UNLINK(ctx->wtran, tran, wlink);
-	/* Since there are some trans, make sure timer is successfully "on". */
-	if (ctx->tiID.opaque != NULL)
-		touch_timer(ctx);
-	else
-		start_timer(ctx);
-	if (ctx->state == destroyed)
-		return;
-	/* Marshall a newline-terminated message and clock it out. */
-	*iovp++ = evConsIovec(tran->outbuf.text, tran->outbuf.used);
-	DE_CONST("\r\n", tmp);
-	*iovp++ = evConsIovec(tmp, 2);
-	if (evWrite(ctx->ev, ctx->sock, iov, iovp - iov,
-		    write_done, tran, &ctx->wrID) < 0) {
-		(*ctx->logger)(ctl_error, "%s: evWrite: %s", me,
-			       strerror(errno));
-		error(ctx);
-		return;
-	}
-	if (evTimeRW(ctx->ev, ctx->wrID, ctx->tiID) < 0) {
-		(*ctx->logger)(ctl_error, "%s: evTimeRW: %s", me,
-			       strerror(errno));
-		error(ctx);
-		return;
-	}
-}
-
-static void
-destroy(struct ctl_cctx *ctx, int notify) {
-	struct ctl_tran *this, *next;
-
-	if (ctx->sock != -1) {
-		(void) close(ctx->sock);
-		ctx->sock = -1;
-	}
-	switch (ctx->state) {
-	case connecting:
-		REQUIRE(ctx->wrID.opaque == NULL);
-		REQUIRE(EMPTY(ctx->tran));
-		/*
-		 * This test is nec'y since destroy() can be called from
-		 * start_read() while the state is still "connecting".
-		 */
-		if (ctx->coID.opaque != NULL) {
-			(void)evCancelConn(ctx->ev, ctx->coID);
-			ctx->coID.opaque = NULL;
-		}
-		break;
-	case connected:
-		REQUIRE(ctx->coID.opaque == NULL);
-		if (ctx->wrID.opaque != NULL) {
-			(void)evCancelRW(ctx->ev, ctx->wrID);
-			ctx->wrID.opaque = NULL;
-		}
-		if (ctx->rdID.opaque != NULL)
-			stop_read(ctx);
-		break;
-	case destroyed:
-		break;
-	default:
-		abort();
-	}
-	if (allocated_p(ctx->inbuf))
-		ctl_bufput(&ctx->inbuf);
-	for (this = HEAD(ctx->tran); this != NULL; this = next) {
-		next = NEXT(this, link);
-		if (allocated_p(this->outbuf))
-			ctl_bufput(&this->outbuf);
-		if (notify && this->donefunc != NULL)
-			(*this->donefunc)(ctx, this->uap, NULL, 0);
-		memput(this, sizeof *this);
-	}
-	if (ctx->tiID.opaque != NULL)
-		stop_timer(ctx);
-	new_state(ctx, destroyed);
-}
-
-static void
-error(struct ctl_cctx *ctx) {
-	REQUIRE(ctx->state != destroyed);
-	destroy(ctx, 1);
-}
-
-static void
-new_state(struct ctl_cctx *ctx, enum state new_state) {
-	static const char me[] = "isc/ctl_clnt::new_state";
-
-	(*ctx->logger)(ctl_debug, "%s: %s -> %s", me,
-		       state_names[ctx->state], state_names[new_state]);
-	ctx->state = new_state;
-}
-
-static void
-conn_done(evContext ev, void *uap, int fd,
-	  const void *la, int lalen,
-	  const void *ra, int ralen)
-{
-	static const char me[] = "isc/ctl_clnt::conn_done";
-	struct ctl_cctx *ctx = uap;
-	struct ctl_tran *tran;
-
-	UNUSED(ev);
-	UNUSED(la);
-	UNUSED(lalen);
-	UNUSED(ra);
-	UNUSED(ralen);
-
-	ctx->coID.opaque = NULL;
-	if (fd < 0) {
-		(*ctx->logger)(ctl_error, "%s: evConnect: %s", me,
-			       strerror(errno));
-		error(ctx);
-		return;
-	}
-	new_state(ctx, connected);
-	tran = new_tran(ctx, ctx->donefunc, ctx->uap, 0);
-	if (tran == NULL) {
-		(*ctx->logger)(ctl_error, "%s: new_tran failed: %s", me,
-			       strerror(errno));
-		error(ctx);
-		return;
-	}
-	start_read(ctx);
-	if (ctx->state == destroyed) {
-		(*ctx->logger)(ctl_error, "%s: start_read failed: %s",
-			       me, strerror(errno));
-		error(ctx);
-		return;
-	}
-}
-
-static void
-write_done(evContext lev, void *uap, int fd, int bytes) {
-	struct ctl_tran *tran = (struct ctl_tran *)uap;
-	struct ctl_cctx *ctx = tran->ctx;
-
-	UNUSED(lev);
-	UNUSED(fd);
-
-	ctx->wrID.opaque = NULL;
-	if (ctx->tiID.opaque != NULL)
-		touch_timer(ctx);
-	ctl_bufput(&tran->outbuf);
-	start_write(ctx);
-	if (bytes < 0)
-		destroy(ctx, 1);
-	else
-		start_read(ctx);
-}
-
-static void
-start_read(struct ctl_cctx *ctx) {
-	static const char me[] = "isc/ctl_clnt::start_read";
-
-	REQUIRE(ctx->state == connecting || ctx->state == connected);
-	REQUIRE(ctx->rdID.opaque == NULL);
-	if (evSelectFD(ctx->ev, ctx->sock, EV_READ, readable, ctx,
-		       &ctx->rdID) < 0)
-	{
-		(*ctx->logger)(ctl_error, "%s: evSelect(fd %d): %s", me,
-			       ctx->sock, strerror(errno));
-		error(ctx);
-		return;
-	}
-}
-
-static void
-stop_read(struct ctl_cctx *ctx) {
-	REQUIRE(ctx->coID.opaque == NULL);
-	REQUIRE(ctx->rdID.opaque != NULL);
-	(void)evDeselectFD(ctx->ev, ctx->rdID);
-	ctx->rdID.opaque = NULL;
-}
-
-static void
-readable(evContext ev, void *uap, int fd, int evmask) {
-	static const char me[] = "isc/ctl_clnt::readable";
-	struct ctl_cctx *ctx = uap;
-	struct ctl_tran *tran;
-	ssize_t n;
-	char *eos;
-
-	UNUSED(ev);
-
-	REQUIRE(ctx != NULL);
-	REQUIRE(fd >= 0);
-	REQUIRE(evmask == EV_READ);
-	REQUIRE(ctx->state == connected);
-	REQUIRE(!EMPTY(ctx->tran));
-	tran = HEAD(ctx->tran);
-	if (!allocated_p(ctx->inbuf) &&
-	    ctl_bufget(&ctx->inbuf, ctx->logger) < 0) {
-		(*ctx->logger)(ctl_error, "%s: can't get an input buffer", me);
-		error(ctx);
-		return;
-	}
-	n = read(ctx->sock, ctx->inbuf.text + ctx->inbuf.used,
-		 MAX_LINELEN - ctx->inbuf.used);
-	if (n <= 0) {
-		(*ctx->logger)(ctl_warning, "%s: read: %s", me,
-			       (n == 0) ? "Unexpected EOF" : strerror(errno));
-		error(ctx);
-		return;
-	}
-	if (ctx->tiID.opaque != NULL)
-		touch_timer(ctx);
-	ctx->inbuf.used += n;
-	(*ctx->logger)(ctl_debug, "%s: read %d, used %d", me,
-		       n, ctx->inbuf.used);
- again:
-	eos = memchr(ctx->inbuf.text, '\n', ctx->inbuf.used);
-	if (eos != NULL && eos != ctx->inbuf.text && eos[-1] == '\r') {
-		int done = 0;
-
-		eos[-1] = '\0';
-		if (!arpacode_p(ctx->inbuf.text)) {
-			/* XXX Doesn't FTP do this sometimes? Is it legal? */
-			(*ctx->logger)(ctl_error, "%s: no arpa code (%s)", me,
-				       ctx->inbuf.text);
-			error(ctx);
-			return;
-		}
-		if (arpadone_p(ctx->inbuf.text))
-			done = 1;
-		else if (arpacont_p(ctx->inbuf.text))
-			done = 0;
-		else {
-			/* XXX Doesn't FTP do this sometimes? Is it legal? */
-			(*ctx->logger)(ctl_error, "%s: no arpa flag (%s)", me,
-				       ctx->inbuf.text);
-			error(ctx);
-			return;
-		}
-		(*tran->donefunc)(ctx, tran->uap, ctx->inbuf.text,
-				  (done ? 0 : CTL_MORE));
-		ctx->inbuf.used -= ((eos - ctx->inbuf.text) + 1);
-		if (ctx->inbuf.used == 0U)
-			ctl_bufput(&ctx->inbuf);
-		else
-			memmove(ctx->inbuf.text, eos + 1, ctx->inbuf.used);
-		if (done) {
-			UNLINK(ctx->tran, tran, link);
-			memput(tran, sizeof *tran);
-			stop_read(ctx);
-			start_write(ctx);
-			return;
-		}
-		if (allocated_p(ctx->inbuf))
-			goto again;
-		return;
-	}
-	if (ctx->inbuf.used == (size_t)MAX_LINELEN) {
-		(*ctx->logger)(ctl_error, "%s: line too long (%-10s...)", me,
-			       ctx->inbuf.text);
-		error(ctx);
-	}
-}
-
-/* Timer related stuff. */
-
-static void
-start_timer(struct ctl_cctx *ctx) {
-	static const char me[] = "isc/ctl_clnt::start_timer";
-
-	REQUIRE(ctx->tiID.opaque == NULL);
-	if (evSetIdleTimer(ctx->ev, timer, ctx, ctx->timeout, &ctx->tiID) < 0){
-		(*ctx->logger)(ctl_error, "%s: evSetIdleTimer: %s", me,
-			       strerror(errno));
-		error(ctx);
-		return;
-	}
-}
-
-static void
-stop_timer(struct ctl_cctx *ctx) {
-	static const char me[] = "isc/ctl_clnt::stop_timer";
-
-	REQUIRE(ctx->tiID.opaque != NULL);
-	if (evClearIdleTimer(ctx->ev, ctx->tiID) < 0) {
-		(*ctx->logger)(ctl_error, "%s: evClearIdleTimer: %s", me,
-			       strerror(errno));
-		error(ctx);
-		return;
-	}
-	ctx->tiID.opaque = NULL;
-}
-
-static void
-touch_timer(struct ctl_cctx *ctx) {
-	REQUIRE(ctx->tiID.opaque != NULL);
-
-	evTouchIdleTimer(ctx->ev, ctx->tiID);
-}
-
-static void
-timer(evContext ev, void *uap, struct timespec due, struct timespec itv) {
-	static const char me[] = "isc/ctl_clnt::timer";
-	struct ctl_cctx *ctx = uap;
-
-	UNUSED(ev);
-	UNUSED(due);
-	UNUSED(itv);
-
-	ctx->tiID.opaque = NULL;
-	(*ctx->logger)(ctl_error, "%s: timeout after %u seconds while %s", me,
-		       ctx->timeout.tv_sec, state_names[ctx->state]);
-	error(ctx);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/isc/ctl_p.c b/contrib/bind9/lib/bind/isc/ctl_p.c
deleted file mode 100644
index 35c2398..0000000
--- a/contrib/bind9/lib/bind/isc/ctl_p.c
+++ /dev/null
@@ -1,188 +0,0 @@
-#if !defined(lint) && !defined(SABER)
-static const char rcsid[] = "$Id: ctl_p.c,v 1.3.18.1 2005/04/27 05:01:05 sra Exp $";
-#endif /* not lint */
-
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1998,1999 by 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.
- */
-
-/* Extern. */
-
-#include "port_before.h"
-
-#include <sys/param.h>
-#include <sys/file.h>
-#include <sys/socket.h>
-#include <sys/un.h>
-
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <arpa/inet.h>
-
-#include <errno.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <time.h>
-
-#include <isc/assertions.h>
-#include <isc/eventlib.h>
-#include <isc/logging.h>
-#include <isc/memcluster.h>
-#include <isc/ctl.h>
-
-#include "ctl_p.h"
-
-#include "port_after.h"
-
-/* Constants. */
-
-const char * const ctl_sevnames[] = {
-	"debug", "warning", "error"
-};
-
-/* Public. */
-
-/*%
- * ctl_logger()
- *	if ctl_startup()'s caller didn't specify a logger, this one
- *	is used.  this pollutes stderr with all kinds of trash so it will
- *	probably never be used in real applications.
- */
-void
-ctl_logger(enum ctl_severity severity, const char *format, ...) {
-	va_list ap;
-	static const char me[] = "ctl_logger";
-
-	fprintf(stderr, "%s(%s): ", me, ctl_sevnames[severity]);
-	va_start(ap, format);
-	vfprintf(stderr, format, ap);
-	va_end(ap);
-	fputc('\n', stderr);
-}
-
-int
-ctl_bufget(struct ctl_buf *buf, ctl_logfunc logger) {
-	static const char me[] = "ctl_bufget";
-
-	REQUIRE(!allocated_p(*buf) && buf->used == 0U);
-	buf->text = memget(MAX_LINELEN);
-	if (!allocated_p(*buf)) {
-		(*logger)(ctl_error, "%s: getmem: %s", me, strerror(errno));
-		return (-1);
-	}
-	buf->used = 0;
-	return (0);
-}
-
-void
-ctl_bufput(struct ctl_buf *buf) {
-
-	REQUIRE(allocated_p(*buf));
-	memput(buf->text, MAX_LINELEN);
-	buf->text = NULL;
-	buf->used = 0;
-}
-
-const char *
-ctl_sa_ntop(const struct sockaddr *sa,
-	    char *buf, size_t size,
-	    ctl_logfunc logger)
-{
-	static const char me[] = "ctl_sa_ntop";
-	static const char punt[] = "[0].-1";
-	char tmp[INET6_ADDRSTRLEN];
-
-	switch (sa->sa_family) {
-	case AF_INET6: {
-		const struct sockaddr_in6 *in6 =
-					(const struct sockaddr_in6 *) sa;
-
-		if (inet_ntop(in6->sin6_family, &in6->sin6_addr, tmp, sizeof tmp)
-		    == NULL) {
-			(*logger)(ctl_error, "%s: inet_ntop(%u %04x): %s",
-				  me, in6->sin6_family,
-				  in6->sin6_port, strerror(errno));
-			return (punt);
-		}
-		if (strlen(tmp) + sizeof "[].65535" > size) {
-			(*logger)(ctl_error, "%s: buffer overflow", me);
-			return (punt);
-		}
-		(void) sprintf(buf, "[%s].%u", tmp, ntohs(in6->sin6_port));
-		return (buf);
-	    }
-	case AF_INET: {
-		const struct sockaddr_in *in =
-					      (const struct sockaddr_in *) sa;
-
-		if (inet_ntop(in->sin_family, &in->sin_addr, tmp, sizeof tmp)
-		    == NULL) {
-			(*logger)(ctl_error, "%s: inet_ntop(%u %04x %08x): %s",
-				  me, in->sin_family,
-				  in->sin_port, in->sin_addr.s_addr,
-				  strerror(errno));
-			return (punt);
-		}
-		if (strlen(tmp) + sizeof "[].65535" > size) {
-			(*logger)(ctl_error, "%s: buffer overflow", me);
-			return (punt);
-		}
-		(void) sprintf(buf, "[%s].%u", tmp, ntohs(in->sin_port));
-		return (buf);
-	    }
-#ifndef NO_SOCKADDR_UN
-	case AF_UNIX: {
-		const struct sockaddr_un *un = 
-					      (const struct sockaddr_un *) sa;
-		unsigned int x = sizeof un->sun_path;
-
-		if (x > size)
-			x = size;
-		strncpy(buf, un->sun_path, x - 1);
-		buf[x - 1] = '\0';
-		return (buf);
-	    }
-#endif
-	default:
-		return (punt);
-	}
-}
-
-void
-ctl_sa_copy(const struct sockaddr *src, struct sockaddr *dst) {
-	switch (src->sa_family) {
-	case AF_INET6:
-		*((struct sockaddr_in6 *)dst) =
-					 *((const struct sockaddr_in6 *)src);
-		break;
-	case AF_INET:
-		*((struct sockaddr_in *)dst) =
-					  *((const struct sockaddr_in *)src);
-		break;
-#ifndef NO_SOCKADDR_UN
-	case AF_UNIX:
-		*((struct sockaddr_un *)dst) =
-					  *((const struct sockaddr_un *)src);
-		break;
-#endif
-	default:
-		*dst = *src;
-		break;
-	}
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/isc/ctl_p.h b/contrib/bind9/lib/bind/isc/ctl_p.h
deleted file mode 100644
index 18a52ae..0000000
--- a/contrib/bind9/lib/bind/isc/ctl_p.h
+++ /dev/null
@@ -1,28 +0,0 @@
-struct ctl_buf {
-	char *			text;
-	size_t			used;
-};
-
-#define	MAX_LINELEN		990	/*%< Like SMTP. */
-#ifndef NO_SOCKADDR_UN
-#define MAX_NTOP			PATH_MAX
-#else
-#define	MAX_NTOP		(sizeof "[255.255.255.255].65535")
-#endif
-
-#define	allocated_p(Buf) ((Buf).text != NULL)
-#define	buffer_init(Buf) ((Buf).text = 0, (Buf.used) = 0)
-
-#define	ctl_bufget	__ctl_bufget
-#define	ctl_bufput	__ctl_bufput
-#define	ctl_sa_ntop	__ctl_sa_ntop
-#define	ctl_sa_copy	__ctl_sa_copy
-
-int			ctl_bufget(struct ctl_buf *, ctl_logfunc);
-void			ctl_bufput(struct ctl_buf *);
-const char *		ctl_sa_ntop(const struct sockaddr *, char *, size_t,
-				    ctl_logfunc);
-void			ctl_sa_copy(const struct sockaddr *,
-				    struct sockaddr *);
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/isc/ctl_srvr.c b/contrib/bind9/lib/bind/isc/ctl_srvr.c
deleted file mode 100644
index 1ab3f8a..0000000
--- a/contrib/bind9/lib/bind/isc/ctl_srvr.c
+++ /dev/null
@@ -1,787 +0,0 @@
-#if !defined(lint) && !defined(SABER)
-static const char rcsid[] = "$Id: ctl_srvr.c,v 1.6.18.3 2008/02/18 04:04:06 marka Exp $";
-#endif /* not lint */
-
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1998,1999 by 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.
- */
-
-/* Extern. */
-
-#include "port_before.h"
-
-#include <sys/param.h>
-#include <sys/file.h>
-#include <sys/socket.h>
-#include <sys/un.h>
-
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <arpa/inet.h>
-
-#include <ctype.h>
-#include <errno.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <time.h>
-#include <unistd.h>
-#include <fcntl.h>
-#ifdef HAVE_MEMORY_H
-#include <memory.h>
-#endif
-
-#include <isc/assertions.h>
-#include <isc/ctl.h>
-#include <isc/eventlib.h>
-#include <isc/list.h>
-#include <isc/logging.h>
-#include <isc/memcluster.h>
-
-#include "ctl_p.h"
-
-#include "port_after.h"
-
-#ifdef SPRINTF_CHAR
-# define SPRINTF(x) strlen(sprintf/**/x)
-#else
-# define SPRINTF(x) ((size_t)sprintf x)
-#endif
-
-/* Macros. */
-
-#define	lastverb_p(verb)	(verb->name == NULL || verb->func == NULL)
-#define	address_expr		ctl_sa_ntop((struct sockaddr *)&sess->sa, \
-					    tmp, sizeof tmp, ctx->logger)
-
-/* Types. */
-
-enum state {
-	available = 0, initializing, writing, reading, reading_data,
-	processing, idling, quitting, closing
-};
-
-union sa_un {
-	struct sockaddr_in in;
-#ifndef NO_SOCKADDR_UN
-	struct sockaddr_un un;
-#endif
-};
-
-struct ctl_sess {
-	LINK(struct ctl_sess)	link;
-	struct ctl_sctx *	ctx;
-	enum state		state;
-	int			sock;
-	union sa_un		sa;
-	evFileID		rdID;
-	evStreamID		wrID;
-	evTimerID		rdtiID;
-	evTimerID		wrtiID;
-	struct ctl_buf		inbuf;
-	struct ctl_buf		outbuf;
-	const struct ctl_verb *	verb;
-	u_int			helpcode;
-	const void *		respctx;
-	u_int			respflags;
-	ctl_srvrdone		donefunc;
-	void *			uap;
-	void *			csctx;
-};
-
-struct ctl_sctx {
-	evContext		ev;
-	void *			uctx;
-	u_int			unkncode;
-	u_int			timeoutcode;
-	const struct ctl_verb *	verbs;
-	const struct ctl_verb *	connverb;
-	int			sock;
-	int			max_sess;
-	int			cur_sess;
-	struct timespec		timeout;
-	ctl_logfunc		logger;
-	evConnID		acID;
-	LIST(struct ctl_sess)	sess;
-};
-
-/* Forward. */
-
-static void			ctl_accept(evContext, void *, int,
-					   const void *, int,
-					   const void *, int);
-static void			ctl_close(struct ctl_sess *);
-static void			ctl_new_state(struct ctl_sess *,
-					      enum state,
-					      const char *);
-static void			ctl_start_read(struct ctl_sess *);
-static void			ctl_stop_read(struct ctl_sess *);
-static void			ctl_readable(evContext, void *, int, int);
-static void			ctl_rdtimeout(evContext, void *,
-					      struct timespec,
-					      struct timespec);
-static void			ctl_wrtimeout(evContext, void *,
-					      struct timespec,
-					      struct timespec);
-static void			ctl_docommand(struct ctl_sess *);
-static void			ctl_writedone(evContext, void *, int, int);
-static void			ctl_morehelp(struct ctl_sctx *,
-					     struct ctl_sess *,
-					     const struct ctl_verb *,
-					     const char *,
-					     u_int, const void *, void *);
-static void			ctl_signal_done(struct ctl_sctx *,
-						struct ctl_sess *);
-
-/* Private data. */
-
-static const char *		state_names[] = {
-	"available", "initializing", "writing", "reading",
-	"reading_data", "processing", "idling", "quitting", "closing"
-};
-
-static const char		space[] = " ";
-
-static const struct ctl_verb	fakehelpverb = {
-	"fakehelp", ctl_morehelp , NULL
-};
-
-/* Public. */
-
-/*%
- * void
- * ctl_server()
- *	create, condition, and start a listener on the control port.
- */
-struct ctl_sctx *
-ctl_server(evContext lev, const struct sockaddr *sap, size_t sap_len,
-	   const struct ctl_verb *verbs,
-	   u_int unkncode, u_int timeoutcode,
-	   u_int timeout, int backlog, int max_sess,
-	   ctl_logfunc logger, void *uctx)
-{
-	static const char me[] = "ctl_server";
-	static const int on = 1;
-	const struct ctl_verb *connverb;
-	struct ctl_sctx *ctx;
-	int save_errno;
-
-	if (logger == NULL)
-		logger = ctl_logger;
-	for (connverb = verbs;
-	     connverb->name != NULL && connverb->func != NULL;
-	     connverb++)
-		if (connverb->name[0] == '\0')
-			break;
-	if (connverb->func == NULL) {
-		(*logger)(ctl_error, "%s: no connection verb found", me);
-		return (NULL);
-	}
-	ctx = memget(sizeof *ctx);
-	if (ctx == NULL) {
-		(*logger)(ctl_error, "%s: getmem: %s", me, strerror(errno));
-		return (NULL);
-	}
-	ctx->ev = lev;
-	ctx->uctx = uctx;
-	ctx->unkncode = unkncode;
-	ctx->timeoutcode = timeoutcode;
-	ctx->verbs = verbs;
-	ctx->timeout = evConsTime(timeout, 0);
-	ctx->logger = logger;
-	ctx->connverb = connverb;
-	ctx->max_sess = max_sess;
-	ctx->cur_sess = 0;
-	INIT_LIST(ctx->sess);
-	ctx->sock = socket(sap->sa_family, SOCK_STREAM, PF_UNSPEC);
-	if (ctx->sock > evHighestFD(ctx->ev)) {
-		ctx->sock = -1;
-		errno = ENOTSOCK;
-	}
-	if (ctx->sock < 0) {
-		save_errno = errno;
-		(*ctx->logger)(ctl_error, "%s: socket: %s",
-			       me, strerror(errno));
-		memput(ctx, sizeof *ctx);
-		errno = save_errno;
-		return (NULL);
-	}
-	if (ctx->sock > evHighestFD(lev)) {
-		close(ctx->sock);
-		(*ctx->logger)(ctl_error, "%s: file descriptor > evHighestFD");
-		errno = ENFILE;
-		memput(ctx, sizeof *ctx);
-		return (NULL);
-	}
-#ifdef NO_UNIX_REUSEADDR
-	if (sap->sa_family != AF_UNIX)
-#endif
-		if (setsockopt(ctx->sock, SOL_SOCKET, SO_REUSEADDR,
-			       (const char *)&on, sizeof on) != 0) {
-			(*ctx->logger)(ctl_warning,
-				       "%s: setsockopt(REUSEADDR): %s",
-				       me, strerror(errno));
-		}
-	if (bind(ctx->sock, sap, sap_len) < 0) {
-		char tmp[MAX_NTOP];
-		save_errno = errno;
-		(*ctx->logger)(ctl_error, "%s: bind: %s: %s",
-			       me, ctl_sa_ntop((const struct sockaddr *)sap,
-			       tmp, sizeof tmp, ctx->logger),
-			       strerror(save_errno));
-		close(ctx->sock);
-		memput(ctx, sizeof *ctx);
-		errno = save_errno;
-		return (NULL);
-	}
-	if (fcntl(ctx->sock, F_SETFD, 1) < 0) {
-		(*ctx->logger)(ctl_warning, "%s: fcntl: %s", me,
-			       strerror(errno));
-	}
-	if (evListen(lev, ctx->sock, backlog, ctl_accept, ctx,
-		     &ctx->acID) < 0) {
-		save_errno = errno;
-		(*ctx->logger)(ctl_error, "%s: evListen(fd %d): %s",
-			       me, ctx->sock, strerror(errno));
-		close(ctx->sock);
-		memput(ctx, sizeof *ctx);
-		errno = save_errno;
-		return (NULL);
-	}
-	(*ctx->logger)(ctl_debug, "%s: new ctx %p, sock %d",
-		       me, ctx, ctx->sock);
-	return (ctx);
-}
-
-/*%
- * void
- * ctl_endserver(ctx)
- *	if the control listener is open, close it.  clean out all eventlib
- *	stuff.  close all active sessions.
- */
-void
-ctl_endserver(struct ctl_sctx *ctx) {
-	static const char me[] = "ctl_endserver";
-	struct ctl_sess *this, *next;
-
-	(*ctx->logger)(ctl_debug, "%s: ctx %p, sock %d, acID %p, sess %p",
-		       me, ctx, ctx->sock, ctx->acID.opaque, ctx->sess);
-	if (ctx->acID.opaque != NULL) {
-		(void)evCancelConn(ctx->ev, ctx->acID);
-		ctx->acID.opaque = NULL;
-	}
-	if (ctx->sock != -1) {
-		(void) close(ctx->sock);
-		ctx->sock = -1;
-	}
-	for (this = HEAD(ctx->sess); this != NULL; this = next) {
-		next = NEXT(this, link);
-		ctl_close(this);
-	}
-	memput(ctx, sizeof *ctx);
-}
-
-/*%
- * If body is non-NULL then it we add a "." line after it.
- * Caller must have  escaped lines with leading ".".
- */
-void
-ctl_response(struct ctl_sess *sess, u_int code, const char *text,
-	     u_int flags, const void *respctx, ctl_srvrdone donefunc,
-	     void *uap, const char *body, size_t bodylen)
-{
-	static const char me[] = "ctl_response";
-	struct iovec iov[3], *iovp = iov;
-	struct ctl_sctx *ctx = sess->ctx;
-	char tmp[MAX_NTOP], *pc;
-	int n;
-
-	REQUIRE(sess->state == initializing ||
-		sess->state == processing ||
-		sess->state == reading_data ||
-		sess->state == writing);
-	REQUIRE(sess->wrtiID.opaque == NULL);
-	REQUIRE(sess->wrID.opaque == NULL);
-	ctl_new_state(sess, writing, me);
-	sess->donefunc = donefunc;
-	sess->uap = uap;
-	if (!allocated_p(sess->outbuf) &&
-	    ctl_bufget(&sess->outbuf, ctx->logger) < 0) {
-		(*ctx->logger)(ctl_error, "%s: %s: cant get an output buffer",
-			       me, address_expr);
-		goto untimely;
-	}
-	if (sizeof "000-\r\n" + strlen(text) > (size_t)MAX_LINELEN) {
-		(*ctx->logger)(ctl_error, "%s: %s: output buffer ovf, closing",
-			       me, address_expr);
-		goto untimely;
-	}
-	sess->outbuf.used = SPRINTF((sess->outbuf.text, "%03d%c%s\r\n",
-				     code, (flags & CTL_MORE) != 0 ? '-' : ' ',
-				     text));
-	for (pc = sess->outbuf.text, n = 0;
-	     n < (int)sess->outbuf.used-2; pc++, n++)
-		if (!isascii((unsigned char)*pc) ||
-		    !isprint((unsigned char)*pc))
-			*pc = '\040';
-	*iovp++ = evConsIovec(sess->outbuf.text, sess->outbuf.used);
-	if (body != NULL) {
-		char *tmp;
-		DE_CONST(body, tmp);
-		*iovp++ = evConsIovec(tmp, bodylen);
-		DE_CONST(".\r\n", tmp);
-		*iovp++ = evConsIovec(tmp, 3);
-	}
-	(*ctx->logger)(ctl_debug, "%s: [%d] %s", me,
-		       sess->outbuf.used, sess->outbuf.text);
-	if (evWrite(ctx->ev, sess->sock, iov, iovp - iov,
-		    ctl_writedone, sess, &sess->wrID) < 0) {
-		(*ctx->logger)(ctl_error, "%s: %s: evWrite: %s", me,
-			       address_expr, strerror(errno));
-		goto untimely;
-	}
-	if (evSetIdleTimer(ctx->ev, ctl_wrtimeout, sess, ctx->timeout,
-			   &sess->wrtiID) < 0)
-	{
-		(*ctx->logger)(ctl_error, "%s: %s: evSetIdleTimer: %s", me,
-			       address_expr, strerror(errno));
-		goto untimely;
-	}
-	if (evTimeRW(ctx->ev, sess->wrID, sess->wrtiID) < 0) {
-		(*ctx->logger)(ctl_error, "%s: %s: evTimeRW: %s", me,
-			       address_expr, strerror(errno));
- untimely:
-		ctl_signal_done(ctx, sess);
-		ctl_close(sess);
-		return;
-	}
-	sess->respctx = respctx;
-	sess->respflags = flags;
-}
-
-void
-ctl_sendhelp(struct ctl_sess *sess, u_int code) {
-	static const char me[] = "ctl_sendhelp";
-	struct ctl_sctx *ctx = sess->ctx;
-
-	sess->helpcode = code;
-	sess->verb = &fakehelpverb;
-	ctl_morehelp(ctx, sess, NULL, me, CTL_MORE,
-		     (const void *)ctx->verbs, NULL);
-}
-
-void *
-ctl_getcsctx(struct ctl_sess *sess) {
-	return (sess->csctx);
-}
-
-void *
-ctl_setcsctx(struct ctl_sess *sess, void *csctx) {
-	void *old = sess->csctx;
-
-	sess->csctx = csctx;
-	return (old);
-}
-
-/* Private functions. */
-
-static void
-ctl_accept(evContext lev, void *uap, int fd,
-	   const void *lav, int lalen,
-	   const void *rav, int ralen)
-{
-	static const char me[] = "ctl_accept";
-	struct ctl_sctx *ctx = uap;
-	struct ctl_sess *sess = NULL;
-	char tmp[MAX_NTOP];
-
-	UNUSED(lev);
-	UNUSED(lalen);
-	UNUSED(ralen);
-
-	if (fd < 0) {
-		(*ctx->logger)(ctl_error, "%s: accept: %s",
-			       me, strerror(errno));
-		return;
-	}
-	if (ctx->cur_sess == ctx->max_sess) {
-		(*ctx->logger)(ctl_error, "%s: %s: too many control sessions",
-			       me, ctl_sa_ntop((const struct sockaddr *)rav,
-					       tmp, sizeof tmp,
-					       ctx->logger));
-		(void) close(fd);
-		return;
-	}
-	sess = memget(sizeof *sess);
-	if (sess == NULL) {
-		(*ctx->logger)(ctl_error, "%s: memget: %s", me,
-			       strerror(errno));
-		(void) close(fd);
-		return;
-	}
-	if (fcntl(fd, F_SETFD, 1) < 0) {
-		(*ctx->logger)(ctl_warning, "%s: fcntl: %s", me,
-			       strerror(errno));
-	}
-	ctx->cur_sess++;
-	INIT_LINK(sess, link);
-	APPEND(ctx->sess, sess, link);
-	sess->ctx = ctx;
-	sess->sock = fd;
-	sess->wrID.opaque = NULL;
-	sess->rdID.opaque = NULL;
-	sess->wrtiID.opaque = NULL;
-	sess->rdtiID.opaque = NULL;
-	sess->respctx = NULL;
-	sess->csctx = NULL;
-	if (((const struct sockaddr *)rav)->sa_family == AF_UNIX)
-		ctl_sa_copy((const struct sockaddr *)lav,
-			    (struct sockaddr *)&sess->sa);
-	else
-		ctl_sa_copy((const struct sockaddr *)rav,
-			    (struct sockaddr *)&sess->sa);
-	sess->donefunc = NULL;
-	buffer_init(sess->inbuf);
-	buffer_init(sess->outbuf);
-	sess->state = available;
-	ctl_new_state(sess, initializing, me);
-	sess->verb = ctx->connverb;
-	(*ctx->logger)(ctl_debug, "%s: %s: accepting (fd %d)",
-		       me, address_expr, sess->sock);
-	(*ctx->connverb->func)(ctx, sess, ctx->connverb, "", 0,
-			       (const struct sockaddr *)rav, ctx->uctx);
-}
-
-static void
-ctl_new_state(struct ctl_sess *sess, enum state new_state, const char *reason)
-{
-	static const char me[] = "ctl_new_state";
-	struct ctl_sctx *ctx = sess->ctx;
-	char tmp[MAX_NTOP];
-
-	(*ctx->logger)(ctl_debug, "%s: %s: %s -> %s (%s)",
-		       me, address_expr,
-		       state_names[sess->state],
-		       state_names[new_state], reason);
-	sess->state = new_state;
-}
-
-static void
-ctl_close(struct ctl_sess *sess) {
-	static const char me[] = "ctl_close";
-	struct ctl_sctx *ctx = sess->ctx;
-	char tmp[MAX_NTOP];
-
-	REQUIRE(sess->state == initializing ||
-		sess->state == writing ||
-		sess->state == reading ||
-		sess->state == processing ||
-		sess->state == reading_data ||
-		sess->state == idling);
-	REQUIRE(sess->sock != -1);
-	if (sess->state == reading || sess->state == reading_data)
-		ctl_stop_read(sess);
-	else if (sess->state == writing) {
-		if (sess->wrID.opaque != NULL) {
-			(void) evCancelRW(ctx->ev, sess->wrID);
-			sess->wrID.opaque = NULL;
-		}
-		if (sess->wrtiID.opaque != NULL) {
-			(void) evClearIdleTimer(ctx->ev, sess->wrtiID);
-			sess->wrtiID.opaque = NULL;
-		}
-	}
-	ctl_new_state(sess, closing, me);
-	(void) close(sess->sock);
-	if (allocated_p(sess->inbuf))
-		ctl_bufput(&sess->inbuf);
-	if (allocated_p(sess->outbuf))
-		ctl_bufput(&sess->outbuf);
-	(*ctx->logger)(ctl_debug, "%s: %s: closed (fd %d)",
-		       me, address_expr, sess->sock);
-	UNLINK(ctx->sess, sess, link);
-	memput(sess, sizeof *sess);
-	ctx->cur_sess--;
-}
-
-static void
-ctl_start_read(struct ctl_sess *sess) {
-	static const char me[] = "ctl_start_read";
-	struct ctl_sctx *ctx = sess->ctx;
-	char tmp[MAX_NTOP];
-
-	REQUIRE(sess->state == initializing ||
-		sess->state == writing ||
-		sess->state == processing ||
-		sess->state == idling);
-	REQUIRE(sess->rdtiID.opaque == NULL);
-	REQUIRE(sess->rdID.opaque == NULL);
-	sess->inbuf.used = 0;
-	if (evSetIdleTimer(ctx->ev, ctl_rdtimeout, sess, ctx->timeout,
-			   &sess->rdtiID) < 0)
-	{
-		(*ctx->logger)(ctl_error, "%s: %s: evSetIdleTimer: %s", me,
-			       address_expr, strerror(errno));
-		ctl_close(sess);
-		return;
-	}
-	if (evSelectFD(ctx->ev, sess->sock, EV_READ,
-		       ctl_readable, sess, &sess->rdID) < 0) {
-		(*ctx->logger)(ctl_error, "%s: %s: evSelectFD: %s", me,
-			       address_expr, strerror(errno));
-		return;
-	}
-	ctl_new_state(sess, reading, me);
-}
-
-static void
-ctl_stop_read(struct ctl_sess *sess) {
-	static const char me[] = "ctl_stop_read";
-	struct ctl_sctx *ctx = sess->ctx;
-
-	REQUIRE(sess->state == reading || sess->state == reading_data);
-	REQUIRE(sess->rdID.opaque != NULL);
-	(void) evDeselectFD(ctx->ev, sess->rdID);
-	sess->rdID.opaque = NULL;
-	if (sess->rdtiID.opaque != NULL) {
-		(void) evClearIdleTimer(ctx->ev, sess->rdtiID);
-		sess->rdtiID.opaque = NULL;
-	}
-	ctl_new_state(sess, idling, me);
-}
-
-static void
-ctl_readable(evContext lev, void *uap, int fd, int evmask) {
-	static const char me[] = "ctl_readable";
-	struct ctl_sess *sess = uap;
-	struct ctl_sctx *ctx;
-	char *eos, tmp[MAX_NTOP];
-	ssize_t n;
-
-	REQUIRE(sess != NULL);
-	REQUIRE(fd >= 0);
-	REQUIRE(evmask == EV_READ);
-	REQUIRE(sess->state == reading || sess->state == reading_data);
-
-	ctx = sess->ctx;
-	evTouchIdleTimer(lev, sess->rdtiID);
-	if (!allocated_p(sess->inbuf) &&
-	    ctl_bufget(&sess->inbuf, ctx->logger) < 0) {
-		(*ctx->logger)(ctl_error, "%s: %s: cant get an input buffer",
-			       me, address_expr);
-		ctl_close(sess);
-		return;
-	}
-	n = read(sess->sock, sess->inbuf.text + sess->inbuf.used,
-		 MAX_LINELEN - sess->inbuf.used);
-	if (n <= 0) {
-		(*ctx->logger)(ctl_debug, "%s: %s: read: %s",
-			       me, address_expr,
-			       (n == 0) ? "Unexpected EOF" : strerror(errno));
-		ctl_close(sess);
-		return;
-	}
-	sess->inbuf.used += n;
-	eos = memchr(sess->inbuf.text, '\n', sess->inbuf.used);
-	if (eos != NULL && eos != sess->inbuf.text && eos[-1] == '\r') {
-		eos[-1] = '\0';
-		if ((sess->respflags & CTL_DATA) != 0) {
-			INSIST(sess->verb != NULL);
-			(*sess->verb->func)(sess->ctx, sess, sess->verb,
-					    sess->inbuf.text,
-					    CTL_DATA, sess->respctx,
-					    sess->ctx->uctx);
-		} else {
-			ctl_stop_read(sess);
-			ctl_docommand(sess);
-		}
-		sess->inbuf.used -= ((eos - sess->inbuf.text) + 1);
-		if (sess->inbuf.used == 0U)
-			ctl_bufput(&sess->inbuf);
-		else
-			memmove(sess->inbuf.text, eos + 1, sess->inbuf.used);
-		return;
-	}
-	if (sess->inbuf.used == (size_t)MAX_LINELEN) {
-		(*ctx->logger)(ctl_error, "%s: %s: line too long, closing",
-			       me, address_expr);
-		ctl_close(sess);
-	}
-}
-
-static void
-ctl_wrtimeout(evContext lev, void *uap,
-	      struct timespec due,
-	      struct timespec itv)
-{
-	static const char me[] = "ctl_wrtimeout";
-	struct ctl_sess *sess = uap;
-	struct ctl_sctx *ctx = sess->ctx;
-	char tmp[MAX_NTOP];
-	
-	UNUSED(lev);
-	UNUSED(due);
-	UNUSED(itv);
-
-	REQUIRE(sess->state == writing);
-	sess->wrtiID.opaque = NULL;
-	(*ctx->logger)(ctl_warning, "%s: %s: write timeout, closing",
-		       me, address_expr);
-	if (sess->wrID.opaque != NULL) {
-		(void) evCancelRW(ctx->ev, sess->wrID);
-		sess->wrID.opaque = NULL;
-	}
-	ctl_signal_done(ctx, sess);
-	ctl_new_state(sess, processing, me);
-	ctl_close(sess);
-}
-
-static void
-ctl_rdtimeout(evContext lev, void *uap,
-	      struct timespec due,
-	      struct timespec itv)
-{
-	static const char me[] = "ctl_rdtimeout";
-	struct ctl_sess *sess = uap;
-	struct ctl_sctx *ctx = sess->ctx;
-	char tmp[MAX_NTOP];
-
-	UNUSED(lev);
-	UNUSED(due);
-	UNUSED(itv);
-
-	REQUIRE(sess->state == reading);
-	sess->rdtiID.opaque = NULL;
-	(*ctx->logger)(ctl_warning, "%s: %s: timeout, closing",
-		       me, address_expr);
-	if (sess->state == reading || sess->state == reading_data)
-		ctl_stop_read(sess);
-	ctl_signal_done(ctx, sess);
-	ctl_new_state(sess, processing, me);
-	ctl_response(sess, ctx->timeoutcode, "Timeout.", CTL_EXIT, NULL,
-		     NULL, NULL, NULL, 0);
-}
-
-static void
-ctl_docommand(struct ctl_sess *sess) {
-	static const char me[] = "ctl_docommand";
-	char *name, *rest, tmp[MAX_NTOP];
-	struct ctl_sctx *ctx = sess->ctx;
-	const struct ctl_verb *verb;
-
-	REQUIRE(allocated_p(sess->inbuf));
-	(*ctx->logger)(ctl_debug, "%s: %s: \"%s\" [%u]",
-		       me, address_expr,
-		       sess->inbuf.text, (u_int)sess->inbuf.used);
-	ctl_new_state(sess, processing, me);
-	name = sess->inbuf.text + strspn(sess->inbuf.text, space);
-	rest = name + strcspn(name, space);
-	if (*rest != '\0') {
-		*rest++ = '\0';
-		rest += strspn(rest, space);
-	}
-	for (verb = ctx->verbs;
-	     verb != NULL && verb->name != NULL && verb->func != NULL;
-	     verb++)
-		if (verb->name[0] != '\0' && strcasecmp(name, verb->name) == 0)
-			break;
-	if (verb != NULL && verb->name != NULL && verb->func != NULL) {
-		sess->verb = verb;
-		(*verb->func)(ctx, sess, verb, rest, 0, NULL, ctx->uctx);
-	} else {
-		char buf[1100];
-
-		if (sizeof "Unrecognized command \"\" (args \"\")" +
-		    strlen(name) + strlen(rest) > sizeof buf)
-			strcpy(buf, "Unrecognized command (buf ovf)");
-		else
-			sprintf(buf,
-				"Unrecognized command \"%s\" (args \"%s\")",
-				name, rest);
-		ctl_response(sess, ctx->unkncode, buf, 0, NULL, NULL, NULL,
-			     NULL, 0);
-	}
-}
-
-static void
-ctl_writedone(evContext lev, void *uap, int fd, int bytes) {
-	static const char me[] = "ctl_writedone";
-	struct ctl_sess *sess = uap;
-	struct ctl_sctx *ctx = sess->ctx;
-	char tmp[MAX_NTOP];
-	int save_errno = errno;
-
-	UNUSED(lev);
-	UNUSED(uap);
-
-	REQUIRE(sess->state == writing);
-	REQUIRE(fd == sess->sock);
-	REQUIRE(sess->wrtiID.opaque != NULL);
-	sess->wrID.opaque = NULL;
-	(void) evClearIdleTimer(ctx->ev, sess->wrtiID);
-	sess->wrtiID.opaque = NULL;
-	if (bytes < 0) {
-		(*ctx->logger)(ctl_error, "%s: %s: %s",
-			       me, address_expr, strerror(save_errno));
-		ctl_close(sess);
-		return;
-	}
-
-	INSIST(allocated_p(sess->outbuf));
-	ctl_bufput(&sess->outbuf);
-	if ((sess->respflags & CTL_EXIT) != 0) {
-		ctl_signal_done(ctx, sess);
-		ctl_close(sess);
-		return;
-	} else if ((sess->respflags & CTL_MORE) != 0) {
-		INSIST(sess->verb != NULL);
-		(*sess->verb->func)(sess->ctx, sess, sess->verb, "",
-				    CTL_MORE, sess->respctx, sess->ctx->uctx);
-	} else {
-		ctl_signal_done(ctx, sess);
-		ctl_start_read(sess);
-	}
-}
-
-static void
-ctl_morehelp(struct ctl_sctx *ctx, struct ctl_sess *sess,
-	     const struct ctl_verb *verb, const char *text,
-	     u_int respflags, const void *respctx, void *uctx)
-{
-	const struct ctl_verb *this = respctx, *next = this + 1;
-
-	UNUSED(ctx);
-	UNUSED(verb);
-	UNUSED(text);
-	UNUSED(uctx);
-
-	REQUIRE(!lastverb_p(this));
-	REQUIRE((respflags & CTL_MORE) != 0);
-	if (lastverb_p(next))
-		respflags &= ~CTL_MORE;
-	ctl_response(sess, sess->helpcode, this->help, respflags, next,
-		     NULL, NULL, NULL, 0);
-}
-
-static void
-ctl_signal_done(struct ctl_sctx *ctx, struct ctl_sess *sess) {
-	if (sess->donefunc != NULL) {
-		(*sess->donefunc)(ctx, sess, sess->uap);
-		sess->donefunc = NULL;
-	}
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/isc/ev_connects.c b/contrib/bind9/lib/bind/isc/ev_connects.c
deleted file mode 100644
index 64e918d..0000000
--- a/contrib/bind9/lib/bind/isc/ev_connects.c
+++ /dev/null
@@ -1,369 +0,0 @@
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-/* ev_connects.c - implement asynch connect/accept for the eventlib
- * vix 16sep96 [initial]
- */
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: ev_connects.c,v 1.5.18.3 2006/03/10 00:20:08 marka Exp $";
-#endif
-
-/* Import. */
-
-#include "port_before.h"
-#include "fd_setsize.h"
-
-#include <sys/types.h>
-#include <sys/socket.h>
-#include <sys/ioctl.h>
-
-#include <unistd.h>
-
-#include <isc/eventlib.h>
-#include <isc/assertions.h>
-#include "eventlib_p.h"
-
-#include "port_after.h"
-
-/* Macros. */
-
-#define GETXXXNAME(f, s, sa, len) ( \
-	(f((s), (&sa), (&len)) >= 0) ? 0 : \
-		(errno != EAFNOSUPPORT && errno != EOPNOTSUPP) ? -1 : ( \
-			memset(&(sa), 0, sizeof (sa)), \
-			(len) = sizeof (sa), \
-			(sa).sa_family = AF_UNIX, \
-			0 \
-		) \
-	)
-
-/* Forward. */
-
-static void	listener(evContext ctx, void *uap, int fd, int evmask);
-static void	connector(evContext ctx, void *uap, int fd, int evmask);
-
-/* Public. */
-
-int
-evListen(evContext opaqueCtx, int fd, int maxconn,
-	 evConnFunc func, void *uap, evConnID *id)
-{
-	evContext_p *ctx = opaqueCtx.opaque;
-	evConn *new;
-	int mode;
-
-	OKNEW(new);
-	new->flags = EV_CONN_LISTEN;
-	OKFREE(mode = fcntl(fd, F_GETFL, NULL), new);	/*%< side effect: validate fd. */
-	/*
-	 * Remember the nonblocking status.  We assume that either evSelectFD
-	 * has not been done to this fd, or that if it has then the caller
-	 * will evCancelConn before they evDeselectFD.  If our assumptions
-	 * are not met, then we might restore the old nonblocking status
-	 * incorrectly.
-	 */
-	if ((mode & PORT_NONBLOCK) == 0) {
-#ifdef USE_FIONBIO_IOCTL
-		int on = 1;
-		OKFREE(ioctl(fd, FIONBIO, (char *)&on), new);
-#else
-		OKFREE(fcntl(fd, F_SETFL, mode | PORT_NONBLOCK), new);
-#endif
-		new->flags |= EV_CONN_BLOCK;
-	}
-	OKFREE(listen(fd, maxconn), new);
-	if (evSelectFD(opaqueCtx, fd, EV_READ, listener, new, &new->file) < 0){
-		int save = errno;
-
-		FREE(new);
-		errno = save;
-		return (-1);
-	}
-	new->flags |= EV_CONN_SELECTED;
-	new->func = func;
-	new->uap = uap;
-	new->fd = fd;
-	if (ctx->conns != NULL)
-		ctx->conns->prev = new;
-	new->prev = NULL;
-	new->next = ctx->conns;
-	ctx->conns = new;
-	if (id)
-		id->opaque = new;
-	return (0);
-}
-
-int
-evConnect(evContext opaqueCtx, int fd, const void *ra, int ralen,
-	  evConnFunc func, void *uap, evConnID *id)
-{
-	evContext_p *ctx = opaqueCtx.opaque;
-	evConn *new;
-
-	OKNEW(new);
-	new->flags = 0;
-	/* Do the select() first to get the socket into nonblocking mode. */
-	if (evSelectFD(opaqueCtx, fd, EV_MASK_ALL,
-		       connector, new, &new->file) < 0) {
-		int save = errno;
-
-		FREE(new);
-		errno = save;
-		return (-1);
-	}
-	new->flags |= EV_CONN_SELECTED;
-	if (connect(fd, ra, ralen) < 0 &&
-	    errno != EWOULDBLOCK &&
-	    errno != EAGAIN &&
-	    errno != EINPROGRESS) {
-		int save = errno;
-
-		(void) evDeselectFD(opaqueCtx, new->file);
-		FREE(new);
-		errno = save;
-		return (-1);
-	}
-	/* No error, or EWOULDBLOCK.  select() tells when it's ready. */
-	new->func = func;
-	new->uap = uap;
-	new->fd = fd;
-	if (ctx->conns != NULL)
-		ctx->conns->prev = new;
-	new->prev = NULL;
-	new->next = ctx->conns;
-	ctx->conns = new;
-	if (id)
-		id->opaque = new;
-	return (0);
-}
-
-int
-evCancelConn(evContext opaqueCtx, evConnID id) {
-	evContext_p *ctx = opaqueCtx.opaque;
-	evConn *this = id.opaque;
-	evAccept *acc, *nxtacc;
-	int mode;
-
-	if ((this->flags & EV_CONN_SELECTED) != 0)
-		(void) evDeselectFD(opaqueCtx, this->file);
-	if ((this->flags & EV_CONN_BLOCK) != 0) {
-		mode = fcntl(this->fd, F_GETFL, NULL);
-		if (mode == -1) {
-			if (errno != EBADF)
-				return (-1);
-		} else {
-#ifdef USE_FIONBIO_IOCTL
-			int off = 0;
-			OK(ioctl(this->fd, FIONBIO, (char *)&off));
-#else
-			OK(fcntl(this->fd, F_SETFL, mode & ~PORT_NONBLOCK));
-#endif
-		}
-	}
-	
-	/* Unlink from ctx->conns. */
-	if (this->prev != NULL)
-		this->prev->next = this->next;
-	else
-		ctx->conns = this->next;
-	if (this->next != NULL)
-		this->next->prev = this->prev;
-
-	/*
-	 * Remove `this' from the ctx->accepts list (zero or more times).
-	 */
-	for (acc = HEAD(ctx->accepts), nxtacc = NULL;
-	     acc != NULL;
-	     acc = nxtacc)
-	{
-		nxtacc = NEXT(acc, link);
-		if (acc->conn == this) {
-			UNLINK(ctx->accepts, acc, link);
-			close(acc->fd);
-			FREE(acc);
-		}
-	}
-
-	/* Wrap up and get out. */
-	FREE(this);
-	return (0);
-}
-
-int evHold(evContext opaqueCtx, evConnID id) {
-	evConn *this = id.opaque;
-
-	if ((this->flags & EV_CONN_LISTEN) == 0) {
-		errno = EINVAL;
-		return (-1);
-	}
-	if ((this->flags & EV_CONN_SELECTED) == 0)
-		return (0);
-	this->flags &= ~EV_CONN_SELECTED;
-	return (evDeselectFD(opaqueCtx, this->file));
-}
-
-int evUnhold(evContext opaqueCtx, evConnID id) {
-	evConn *this = id.opaque;
-	int ret;
-
-	if ((this->flags & EV_CONN_LISTEN) == 0) {
-		errno = EINVAL;
-		return (-1);
-	}
-	if ((this->flags & EV_CONN_SELECTED) != 0)
-		return (0);
-	ret = evSelectFD(opaqueCtx, this->fd, EV_READ, listener, this,
-			 &this->file);
-	if (ret == 0)
-		this->flags |= EV_CONN_SELECTED;
-	return (ret);
-}
-
-int
-evTryAccept(evContext opaqueCtx, evConnID id, int *sys_errno) {
-	evContext_p *ctx = opaqueCtx.opaque;
-	evConn *conn = id.opaque;
-	evAccept *new;
-
-	if ((conn->flags & EV_CONN_LISTEN) == 0) {
-		errno = EINVAL;
-		return (-1);
-	}
-	OKNEW(new);
-	new->conn = conn;
-	new->ralen = sizeof new->ra;
-	new->fd = accept(conn->fd, &new->ra.sa, &new->ralen);
-	if (new->fd > ctx->highestFD) {
-		close(new->fd);
-		new->fd = -1;
-		new->ioErrno = ENOTSOCK;
-	}
-	if (new->fd >= 0) {
-		new->lalen = sizeof new->la;
-		if (GETXXXNAME(getsockname, new->fd, new->la.sa, new->lalen) < 0) {
-			new->ioErrno = errno;
-			(void) close(new->fd);
-			new->fd = -1;
-		} else
-			new->ioErrno = 0;
-	} else {
-		new->ioErrno = errno;
-		if (errno == EAGAIN || errno == EWOULDBLOCK) {
-			FREE(new);
-			return (-1);
-		}
-	}
-	INIT_LINK(new, link);
-	APPEND(ctx->accepts, new, link);
-	*sys_errno = new->ioErrno;
-	return (0);
-}
-
-/* Private. */
-
-static void
-listener(evContext opaqueCtx, void *uap, int fd, int evmask) {
-	evContext_p *ctx = opaqueCtx.opaque;
-	evConn *conn = uap;
-	union {
-		struct sockaddr    sa;
-		struct sockaddr_in in;
-#ifndef NO_SOCKADDR_UN
-		struct sockaddr_un un;
-#endif
-	} la, ra;
-	int new; 
-	ISC_SOCKLEN_T lalen = 0, ralen;
-
-	REQUIRE((evmask & EV_READ) != 0);
-	ralen = sizeof ra;
-	new = accept(fd, &ra.sa, &ralen);
-	if (new > ctx->highestFD) {
-		close(new);
-		new = -1;
-		errno = ENOTSOCK;
-	}
-	if (new >= 0) {
-		lalen = sizeof la;
-		if (GETXXXNAME(getsockname, new, la.sa, lalen) < 0) {
-			int save = errno;
-
-			(void) close(new);
-			errno = save;
-			new = -1;
-		}
-	} else if (errno == EAGAIN || errno == EWOULDBLOCK)
-		return;
-	(*conn->func)(opaqueCtx, conn->uap, new, &la.sa, lalen, &ra.sa, ralen);
-}
-
-static void
-connector(evContext opaqueCtx, void *uap, int fd, int evmask) {
-	evConn *conn = uap;
-	union {
-		struct sockaddr    sa;
-		struct sockaddr_in in;
-#ifndef NO_SOCKADDR_UN
-		struct sockaddr_un un;
-#endif
-	} la, ra;
-	ISC_SOCKLEN_T lalen, ralen;
-#ifndef NETREAD_BROKEN
-	char buf[1];
-#endif
-	void *conn_uap;
-	evConnFunc conn_func;
-	evConnID id;
-	int socket_errno = 0;
-	ISC_SOCKLEN_T optlen;
-
-	UNUSED(evmask);
-
-	lalen = sizeof la;
-	ralen = sizeof ra;
-	conn_uap = conn->uap;
-	conn_func = conn->func;
-	id.opaque = conn;
-#ifdef SO_ERROR
-	optlen = sizeof socket_errno;
-	if (fd < 0 &&
-	    getsockopt(conn->fd, SOL_SOCKET, SO_ERROR, (char *)&socket_errno,
-		       &optlen) < 0)
-		socket_errno = errno;
-	else
-		errno = socket_errno;
-#endif
-	if (evCancelConn(opaqueCtx, id) < 0 ||
-	    socket_errno ||
-#ifdef NETREAD_BROKEN
-	    0 ||
-#else
-	    read(fd, buf, 0) < 0 ||
-#endif
-	    GETXXXNAME(getsockname, fd, la.sa, lalen) < 0 ||
-	    GETXXXNAME(getpeername, fd, ra.sa, ralen) < 0) {
-		int save = errno;
-
-		(void) close(fd);	/*%< XXX closing caller's fd */
-		errno = save;
-		fd = -1;
-	}
-	(*conn_func)(opaqueCtx, conn_uap, fd, &la.sa, lalen, &ra.sa, ralen);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/isc/ev_files.c b/contrib/bind9/lib/bind/isc/ev_files.c
deleted file mode 100644
index 71de091..0000000
--- a/contrib/bind9/lib/bind/isc/ev_files.c
+++ /dev/null
@@ -1,277 +0,0 @@
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-/* ev_files.c - implement asynch file IO for the eventlib
- * vix 11sep95 [initial]
- */
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: ev_files.c,v 1.5.18.3 2005/07/28 07:38:09 marka Exp $";
-#endif
-
-#include "port_before.h"
-#include "fd_setsize.h"
-
-#include <sys/types.h>
-#include <sys/time.h>
-#include <sys/ioctl.h>
-
-#include <errno.h>
-#include <fcntl.h>
-#include <unistd.h>
-
-#include <isc/eventlib.h>
-#include "eventlib_p.h"
-
-#include "port_after.h"
-
-static evFile *FindFD(const evContext_p *ctx, int fd, int eventmask);
-
-int
-evSelectFD(evContext opaqueCtx,
-	   int fd,
-	   int eventmask,
-	   evFileFunc func,
-	   void *uap,
-	   evFileID *opaqueID
-) {
-	evContext_p *ctx = opaqueCtx.opaque;
-	evFile *id;
-	int mode;
-
-	evPrintf(ctx, 1,
-		 "evSelectFD(ctx %p, fd %d, mask 0x%x, func %p, uap %p)\n",
-		 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. */
-	/*
-	 * The first time we touch a file descriptor, we need to check to see
-	 * if the application already had it in O_NONBLOCK mode and if so, all
-	 * 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)
-			FD_SET(fd, &ctx->nonblockBefore);
-		else {
-#ifdef USE_FIONBIO_IOCTL
-			int on = 1;
-			OK(ioctl(fd, FIONBIO, (char *)&on));
-#else
-			OK(fcntl(fd, F_SETFL, mode | PORT_NONBLOCK));
-#endif
-			FD_CLR(fd, &ctx->nonblockBefore);
-		}
-	}
-
-	/*
-	 * If this descriptor is already in use, search for it again to see
-	 * if any of the eventmask bits we want to set are already captured.
-	 * We cannot usefully capture the same fd event more than once in the
-	 * same context.
-	 */
-	if (id != NULL && FindFD(ctx, fd, eventmask) != NULL)
-		EV_ERR(ETOOMANYREFS);
-
-	/* Allocate and fill. */
-	OKNEW(id);
-	id->func = func;
-	id->uap = uap;
-	id->fd = fd;
-	id->eventmask = eventmask;
-
-	/*
-	 * Insert at head.  Order could be important for performance if we
-	 * believe that evGetNext()'s accesses to the fd_sets will be more
-	 * serial and therefore more cache-lucky if the list is ordered by
-	 * ``fd.''  We do not believe these things, so we don't do it.
-	 *
-	 * The interesting sequence is where GetNext() has cached a select()
-	 * result and the caller decides to evSelectFD() on some descriptor.
-	 * Since GetNext() starts at the head, it can miss new entries we add
-	 * at the head.  This is not a serious problem since the event being
-	 * evSelectFD()'d for has to occur before evSelectFD() is called for
-	 * the file event to be considered "missed" -- a real corner case.
-	 * Maintaining a "tail" pointer for ctx->files would fix this, but I'm
-	 * not sure it would be ``more correct.''
-	 */
-	if (ctx->files != NULL)
-		ctx->files->prev = id;
-	id->prev = NULL;
-	id->next = ctx->files;
-	ctx->files = id;
-
-	/* Insert into fd table. */
-	if (ctx->fdTable[fd] != NULL)
-		ctx->fdTable[fd]->fdprev = id;
-	id->fdprev = NULL;
-	id->fdnext = ctx->fdTable[fd];
-	ctx->fdTable[fd] = id;
-
-	/* Turn on the appropriate bits in the {rd,wr,ex}Next fd_set's. */
-	if (eventmask & EV_READ)
-		FD_SET(fd, &ctx->rdNext);
-	if (eventmask & EV_WRITE)
-		FD_SET(fd, &ctx->wrNext);
-	if (eventmask & EV_EXCEPT)
-		FD_SET(fd, &ctx->exNext);
-
-	/* Update fdMax. */
-	if (fd > ctx->fdMax)
-		ctx->fdMax = fd;
-
-	/* Remember the ID if the caller provided us a place for it. */
-	if (opaqueID)
-		opaqueID->opaque = id;
-
-	return (0);
-}
-
-int
-evDeselectFD(evContext opaqueCtx, evFileID opaqueID) {
-	evContext_p *ctx = opaqueCtx.opaque;
-	evFile *del = opaqueID.opaque;
-	evFile *cur;
-	int mode, eventmask;
-
-	if (!del) {
-		evPrintf(ctx, 11, "evDeselectFD(NULL) ignored\n");
-		errno = EINVAL;
-		return (-1);
-	}
-
-	evPrintf(ctx, 1, "evDeselectFD(fd %d, mask 0x%x)\n",
-		 del->fd, del->eventmask);
-
-	/* Get the mode.  Unless the file has been closed, errors are bad. */
-	mode = fcntl(del->fd, F_GETFL, NULL);
-	if (mode == -1 && errno != EBADF)
-		EV_ERR(errno);
-
-	/* Remove from the list of files. */
-	if (del->prev != NULL)
-		del->prev->next = del->next;
-	else
-		ctx->files = del->next;
-	if (del->next != NULL)
-		del->next->prev = del->prev;
-
-	/* Remove from the fd table. */
-	if (del->fdprev != NULL)
-		del->fdprev->fdnext = del->fdnext;
-	else
-		ctx->fdTable[del->fd] = del->fdnext;
-	if (del->fdnext != NULL)
-		del->fdnext->fdprev = del->fdprev;
-
-	/*
-	 * If the file descriptor does not appear in any other select() entry,
-	 * and if !EV_WASNONBLOCK, and if we got no EBADF when we got the mode
-	 * earlier, then: restore the fd to blocking status.
-	 */
-	if (!(cur = FindFD(ctx, del->fd, EV_MASK_ALL)) &&
-	    !FD_ISSET(del->fd, &ctx->nonblockBefore) &&
-	    mode != -1) {
-		/*
-		 * Note that we won't return an error status to the caller if
-		 * this fcntl() fails since (a) we've already done the work
-		 * and (b) the caller didn't ask us anything about O_NONBLOCK.
-		 */
-#ifdef USE_FIONBIO_IOCTL
-		int off = 0;
-		(void) ioctl(del->fd, FIONBIO, (char *)&off);
-#else
-		(void) fcntl(del->fd, F_SETFL, mode & ~PORT_NONBLOCK);
-#endif
-	}
-
-	/*
-	 * Now find all other uses of this descriptor and OR together an event
-	 * mask so that we don't turn off {rd,wr,ex}Next bits that some other
-	 * file event is using.  As an optimization, stop if the event mask
-	 * fills.
-	 */
-	eventmask = 0;
-	for ((void)NULL;
-	     cur != NULL && eventmask != EV_MASK_ALL;
-	     cur = cur->next)
-		if (cur->fd == del->fd)
-			eventmask |= cur->eventmask;
-
-	/* OK, now we know which bits we can clear out. */
-	if (!(eventmask & EV_READ)) {
-		FD_CLR(del->fd, &ctx->rdNext);
-		if (FD_ISSET(del->fd, &ctx->rdLast)) {
-			FD_CLR(del->fd, &ctx->rdLast);
-			ctx->fdCount--;
-		}
-	}
-	if (!(eventmask & EV_WRITE)) {
-		FD_CLR(del->fd, &ctx->wrNext);
-		if (FD_ISSET(del->fd, &ctx->wrLast)) {
-			FD_CLR(del->fd, &ctx->wrLast);
-			ctx->fdCount--;
-		}
-	}
-	if (!(eventmask & EV_EXCEPT)) {
-		FD_CLR(del->fd, &ctx->exNext);
-		if (FD_ISSET(del->fd, &ctx->exLast)) {
-			FD_CLR(del->fd, &ctx->exLast);
-			ctx->fdCount--;
-		}
-	}
-
-	/* If this was the maxFD, find the new one. */
-	if (del->fd == ctx->fdMax) {
-		ctx->fdMax = -1;
-		for (cur = ctx->files; cur; cur = cur->next)
-			if (cur->fd > ctx->fdMax)
-				ctx->fdMax = cur->fd;
-	}
-
-	/* If this was the fdNext, cycle that to the next entry. */
-	if (del == ctx->fdNext)
-		ctx->fdNext = del->next;
-
-	/* Couldn't free it before now since we were using fields out of it. */
-	FREE(del);
-
-	return (0);
-}
-
-static evFile *
-FindFD(const evContext_p *ctx, int fd, int eventmask) {
-	evFile *id;
-
-	for (id = ctx->fdTable[fd]; id != NULL; id = id->fdnext)
-		if (id->fd == fd && (id->eventmask & eventmask) != 0)
-			break;
-	return (id);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/isc/ev_streams.c b/contrib/bind9/lib/bind/isc/ev_streams.c
deleted file mode 100644
index ab61246..0000000
--- a/contrib/bind9/lib/bind/isc/ev_streams.c
+++ /dev/null
@@ -1,308 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996-1999 by 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.
- */
-
-/* ev_streams.c - implement asynch stream file IO for the eventlib
- * vix 04mar96 [initial]
- */
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: ev_streams.c,v 1.4.18.1 2005/04/27 05:01:06 sra Exp $";
-#endif
-
-#include "port_before.h"
-#include "fd_setsize.h"
-
-#include <sys/types.h>
-#include <sys/uio.h>
-
-#include <errno.h>
-
-#include <isc/eventlib.h>
-#include <isc/assertions.h>
-#include "eventlib_p.h"
-
-#include "port_after.h"
-
-static int	copyvec(evStream *str, const struct iovec *iov, int iocnt);
-static void	consume(evStream *str, size_t bytes);
-static void	done(evContext opaqueCtx, evStream *str);
-static void	writable(evContext opaqueCtx, void *uap, int fd, int evmask);
-static void	readable(evContext opaqueCtx, void *uap, int fd, int evmask);
-
-struct iovec
-evConsIovec(void *buf, size_t cnt) {
-	struct iovec ret;
-
-	memset(&ret, 0xf5, sizeof ret);
-	ret.iov_base = buf;
-	ret.iov_len = cnt;
-	return (ret);
-}
-
-int
-evWrite(evContext opaqueCtx, int fd, const struct iovec *iov, int iocnt,
-	evStreamFunc func, void *uap, evStreamID *id)
-{
-	evContext_p *ctx = opaqueCtx.opaque;
-	evStream *new;
-	int save;
-
-	OKNEW(new);
-	new->func = func;
-	new->uap = uap;
-	new->fd = fd;
-	new->flags = 0;
-	if (evSelectFD(opaqueCtx, fd, EV_WRITE, writable, new, &new->file) < 0)
-		goto free;
-	if (copyvec(new, iov, iocnt) < 0)
-		goto free;
-	new->prevDone = NULL;
-	new->nextDone = NULL;
-	if (ctx->streams != NULL)
-		ctx->streams->prev = new;
-	new->prev = NULL;
-	new->next = ctx->streams;
-	ctx->streams = new;
-	if (id != NULL)
-		id->opaque = new;
-	return (0);
- free:
-	save = errno;
-	FREE(new);
-	errno = save;
-	return (-1);
-}
-
-int
-evRead(evContext opaqueCtx, int fd, const struct iovec *iov, int iocnt,
-       evStreamFunc func, void *uap, evStreamID *id)
-{
-	evContext_p *ctx = opaqueCtx.opaque;
-	evStream *new;
-	int save;
-
-	OKNEW(new);
-	new->func = func;
-	new->uap = uap;
-	new->fd = fd;
-	new->flags = 0;
-	if (evSelectFD(opaqueCtx, fd, EV_READ, readable, new, &new->file) < 0)
-		goto free;
-	if (copyvec(new, iov, iocnt) < 0)
-		goto free;
-	new->prevDone = NULL;
-	new->nextDone = NULL;
-	if (ctx->streams != NULL)
-		ctx->streams->prev = new;
-	new->prev = NULL;
-	new->next = ctx->streams;
-	ctx->streams = new;
-	if (id)
-		id->opaque = new;
-	return (0);
- free:
-	save = errno;
-	FREE(new);
-	errno = save;
-	return (-1);
-}
-
-int
-evTimeRW(evContext opaqueCtx, evStreamID id, evTimerID timer) /*ARGSUSED*/ {
-	evStream *str = id.opaque;
-
-	UNUSED(opaqueCtx);
-
-	str->timer = timer;
-	str->flags |= EV_STR_TIMEROK;
-	return (0);
-}
-
-int
-evUntimeRW(evContext opaqueCtx, evStreamID id) /*ARGSUSED*/ {
-	evStream *str = id.opaque;
-
-	UNUSED(opaqueCtx);
-
-	str->flags &= ~EV_STR_TIMEROK;
-	return (0);
-}
-
-int
-evCancelRW(evContext opaqueCtx, evStreamID id) {
-	evContext_p *ctx = opaqueCtx.opaque;
-	evStream *old = id.opaque;
-
-	/*
-	 * The streams list is doubly threaded.  First, there's ctx->streams
-	 * that's used by evDestroy() to find and cancel all streams.  Second,
-	 * there's ctx->strDone (head) and ctx->strLast (tail) which thread
-	 * through the potentially smaller number of "IO completed" streams,
-	 * used in evGetNext() to avoid scanning the entire list.
-	 */
-
-	/* Unlink from ctx->streams. */
-	if (old->prev != NULL)
-		old->prev->next = old->next;
-	else
-		ctx->streams = old->next;
-	if (old->next != NULL)
-		old->next->prev = old->prev;
-
-	/*
-	 * If 'old' is on the ctx->strDone list, remove it.  Update
-	 * ctx->strLast if necessary.
-	 */
-	if (old->prevDone == NULL && old->nextDone == NULL) {
-		/*
-		 * Either 'old' is the only item on the done list, or it's
-		 * not on the done list.  If the former, then we unlink it
-		 * from the list.  If the latter, we leave the list alone.
-		 */
-		if (ctx->strDone == old) {
-			ctx->strDone = NULL;
-			ctx->strLast = NULL;
-		}
-	} else {
-		if (old->prevDone != NULL)
-			old->prevDone->nextDone = old->nextDone;
-		else
-			ctx->strDone = old->nextDone;
-		if (old->nextDone != NULL)
-			old->nextDone->prevDone = old->prevDone;
-		else
-			ctx->strLast = old->prevDone;
-	}
-
-	/* Deallocate the stream. */
-	if (old->file.opaque)
-		evDeselectFD(opaqueCtx, old->file);
-	memput(old->iovOrig, sizeof (struct iovec) * old->iovOrigCount);
-	FREE(old);
-	return (0);
-}
-
-/* Copy a scatter/gather vector and initialize a stream handler's IO. */
-static int
-copyvec(evStream *str, const struct iovec *iov, int iocnt) {
-	int i;
-
-	str->iovOrig = (struct iovec *)memget(sizeof(struct iovec) * iocnt);
-	if (str->iovOrig == NULL) {
-		errno = ENOMEM;
-		return (-1);
-	}
-	str->ioTotal = 0;
-	for (i = 0; i < iocnt; i++) {
-		str->iovOrig[i] = iov[i];
-		str->ioTotal += iov[i].iov_len;
-	}
-	str->iovOrigCount = iocnt;
-	str->iovCur = str->iovOrig;
-	str->iovCurCount = str->iovOrigCount;
-	str->ioDone = 0;
-	return (0);
-}
-
-/* Pull off or truncate lead iovec(s). */
-static void
-consume(evStream *str, size_t bytes) {
-	while (bytes > 0U) {
-		if (bytes < (size_t)str->iovCur->iov_len) {
-			str->iovCur->iov_len -= bytes;
-			str->iovCur->iov_base = (void *)
-				((u_char *)str->iovCur->iov_base + bytes);
-			str->ioDone += bytes;
-			bytes = 0;
-		} else {
-			bytes -= str->iovCur->iov_len;
-			str->ioDone += str->iovCur->iov_len;
-			str->iovCur++;
-			str->iovCurCount--;
-		}
-	}
-}
-
-/* Add a stream to Done list and deselect the FD. */
-static void
-done(evContext opaqueCtx, evStream *str) {
-	evContext_p *ctx = opaqueCtx.opaque;
-
-	if (ctx->strLast != NULL) {
-		str->prevDone = ctx->strLast;
-		ctx->strLast->nextDone = str;
-		ctx->strLast = str;
-	} else {
-		INSIST(ctx->strDone == NULL);
-		ctx->strDone = ctx->strLast = str;
-	}
-	evDeselectFD(opaqueCtx, str->file);
-	str->file.opaque = NULL;
-	/* evDrop() will call evCancelRW() on us. */
-}
-
-/* Dribble out some bytes on the stream.  (Called by evDispatch().) */
-static void
-writable(evContext opaqueCtx, void *uap, int fd, int evmask) {
-	evStream *str = uap;
-	int bytes;
-
-	UNUSED(evmask);
-
-	bytes = writev(fd, str->iovCur, str->iovCurCount);
-	if (bytes > 0) {
-		if ((str->flags & EV_STR_TIMEROK) != 0)
-			evTouchIdleTimer(opaqueCtx, str->timer);
-		consume(str, bytes);
-	} else {
-		if (bytes < 0 && errno != EINTR) {
-			str->ioDone = -1;
-			str->ioErrno = errno;
-		}
-	}
-	if (str->ioDone == -1 || str->ioDone == str->ioTotal)
-		done(opaqueCtx, str);
-}
-
-/* Scoop up some bytes from the stream.  (Called by evDispatch().) */
-static void
-readable(evContext opaqueCtx, void *uap, int fd, int evmask) {
-	evStream *str = uap;
-	int bytes;
-
-	UNUSED(evmask);
-
-	bytes = readv(fd, str->iovCur, str->iovCurCount);
-	if (bytes > 0) {
-		if ((str->flags & EV_STR_TIMEROK) != 0)
-			evTouchIdleTimer(opaqueCtx, str->timer);
-		consume(str, bytes);
-	} else {
-		if (bytes == 0)
-			str->ioDone = 0;
-		else {
-			if (errno != EINTR) {
-				str->ioDone = -1;
-				str->ioErrno = errno;
-			}
-		}
-	}
-	if (str->ioDone <= 0 || str->ioDone == str->ioTotal)
-		done(opaqueCtx, str);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/isc/ev_timers.c b/contrib/bind9/lib/bind/isc/ev_timers.c
deleted file mode 100644
index cead2aa..0000000
--- a/contrib/bind9/lib/bind/isc/ev_timers.c
+++ /dev/null
@@ -1,499 +0,0 @@
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-/* ev_timers.c - implement timers for the eventlib
- * vix 09sep95 [initial]
- */
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: ev_timers.c,v 1.5.18.1 2005/04/27 05:01:06 sra Exp $";
-#endif
-
-/* Import. */
-
-#include "port_before.h"
-#include "fd_setsize.h"
-
-#include <errno.h>
-
-#include <isc/assertions.h>
-#include <isc/eventlib.h>
-#include "eventlib_p.h"
-
-#include "port_after.h"
-
-/* Constants. */
-
-#define	MILLION 1000000
-#define BILLION 1000000000
-
-/* Forward. */
-
-static int due_sooner(void *, void *);
-static void set_index(void *, int);
-static void free_timer(void *, void *);
-static void print_timer(void *, void *);
-static void idle_timeout(evContext, void *, struct timespec, struct timespec);
-
-/* Private type. */
-
-typedef struct {
-	evTimerFunc	func;
-	void *		uap;
-	struct timespec	lastTouched;
-	struct timespec	max_idle;
-	evTimer *	timer;
-} idle_timer;
-
-/* Public. */
-
-struct timespec
-evConsTime(time_t sec, long nsec) {
-	struct timespec x;
-
-	x.tv_sec = sec;
-	x.tv_nsec = nsec;
-	return (x);
-}
-
-struct timespec
-evAddTime(struct timespec addend1, struct timespec addend2) {
-	struct timespec x;
-
-	x.tv_sec = addend1.tv_sec + addend2.tv_sec;
-	x.tv_nsec = addend1.tv_nsec + addend2.tv_nsec;
-	if (x.tv_nsec >= BILLION) {
-		x.tv_sec++;
-		x.tv_nsec -= BILLION;
-	}
-	return (x);
-}
-
-struct timespec
-evSubTime(struct timespec minuend, struct timespec subtrahend) {
-	struct timespec x;
-
-	x.tv_sec = minuend.tv_sec - subtrahend.tv_sec;
-	if (minuend.tv_nsec >= subtrahend.tv_nsec)
-		x.tv_nsec = minuend.tv_nsec - subtrahend.tv_nsec;
-	else {
-		x.tv_nsec = BILLION - subtrahend.tv_nsec + minuend.tv_nsec;
-		x.tv_sec--;
-	}
-	return (x);
-}
-
-int
-evCmpTime(struct timespec a, struct timespec b) {
-	long x = a.tv_sec - b.tv_sec;
-
-	if (x == 0L)
-		x = a.tv_nsec - b.tv_nsec;
-	return (x < 0L ? (-1) : x > 0L ? (1) : (0));
-}
-
-struct timespec
-evNowTime() {
-	struct timeval now;
-#ifdef CLOCK_REALTIME
-	struct timespec tsnow;
-	int m = CLOCK_REALTIME;
-
-#ifdef CLOCK_MONOTONIC
-	if (__evOptMonoTime)
-		m = CLOCK_MONOTONIC;
-#endif
-	if (clock_gettime(m, &tsnow) == 0)
-		return (tsnow);
-#endif
-	if (gettimeofday(&now, NULL) < 0)
-		return (evConsTime(0, 0));
-	return (evTimeSpec(now));
-}
-
-struct timespec
-evUTCTime() {
-	struct timeval now;
-#ifdef CLOCK_REALTIME
-	struct timespec tsnow;
-	if (clock_gettime(CLOCK_REALTIME, &tsnow) == 0)
-		return (tsnow);
-#endif
-	if (gettimeofday(&now, NULL) < 0)
-		return (evConsTime(0, 0));
-	return (evTimeSpec(now));
-}
-
-struct timespec
-evLastEventTime(evContext opaqueCtx) {
-	evContext_p *ctx = opaqueCtx.opaque;
-
-	return (ctx->lastEventTime);
-}
-
-struct timespec
-evTimeSpec(struct timeval tv) {
-	struct timespec ts;
-
-	ts.tv_sec = tv.tv_sec;
-	ts.tv_nsec = tv.tv_usec * 1000;
-	return (ts);
-}
-
-struct timeval
-evTimeVal(struct timespec ts) {
-	struct timeval tv;
-
-	tv.tv_sec = ts.tv_sec;
-	tv.tv_usec = ts.tv_nsec / 1000;
-	return (tv);
-}
-
-int
-evSetTimer(evContext opaqueCtx,
-	   evTimerFunc func,
-	   void *uap,
-	   struct timespec due,
-	   struct timespec inter,
-	   evTimerID *opaqueID
-) {
-	evContext_p *ctx = opaqueCtx.opaque;
-	evTimer *id;
-
-	evPrintf(ctx, 1,
-"evSetTimer(ctx %p, func %p, uap %p, due %ld.%09ld, inter %ld.%09ld)\n",
-		 ctx, func, uap,
-		 (long)due.tv_sec, due.tv_nsec,
-		 (long)inter.tv_sec, inter.tv_nsec);
-
-#ifdef __hpux
-	/*
-	 * tv_sec and tv_nsec are unsigned.
-	 */
-	if (due.tv_nsec >= BILLION)
-		EV_ERR(EINVAL);
-
-	if (inter.tv_nsec >= BILLION)
-		EV_ERR(EINVAL);
-#else
-	if (due.tv_sec < 0 || due.tv_nsec < 0 || due.tv_nsec >= BILLION)
-		EV_ERR(EINVAL);
-
-	if (inter.tv_sec < 0 || inter.tv_nsec < 0 || inter.tv_nsec >= BILLION)
-		EV_ERR(EINVAL);
-#endif
-
-	/* due={0,0} is a magic cookie meaning "now." */
-	if (due.tv_sec == (time_t)0 && due.tv_nsec == 0L)
-		due = evNowTime();
-
-	/* Allocate and fill. */
-	OKNEW(id);
-	id->func = func;
-	id->uap = uap;
-	id->due = due;
-	id->inter = inter;
-
-	if (heap_insert(ctx->timers, id) < 0)
-		return (-1);
-
-	/* Remember the ID if the caller provided us a place for it. */
-	if (opaqueID)
-		opaqueID->opaque = id;
-
-	if (ctx->debug > 7) {
-		evPrintf(ctx, 7, "timers after evSetTimer:\n");
-		(void) heap_for_each(ctx->timers, print_timer, (void *)ctx);
-	}
-
-	return (0);
-}
-
-int
-evClearTimer(evContext opaqueCtx, evTimerID id) {
-	evContext_p *ctx = opaqueCtx.opaque;
-	evTimer *del = id.opaque;
-
-	if (ctx->cur != NULL &&
-	    ctx->cur->type == Timer &&
-	    ctx->cur->u.timer.this == del) {
-		evPrintf(ctx, 8, "deferring delete of timer (executing)\n");
-		/*
-		 * Setting the interval to zero ensures that evDrop() will
-		 * clean up the timer.
-		 */
-		del->inter = evConsTime(0, 0);
-		return (0);
-	}
-
-	if (heap_element(ctx->timers, del->index) != del)
-		EV_ERR(ENOENT);
-
-	if (heap_delete(ctx->timers, del->index) < 0)
-		return (-1);
-	FREE(del);
-
-	if (ctx->debug > 7) {
-		evPrintf(ctx, 7, "timers after evClearTimer:\n");
-		(void) heap_for_each(ctx->timers, print_timer, (void *)ctx);
-	}
-
-	return (0);
-}
-
-int
-evConfigTimer(evContext opaqueCtx,
-	     evTimerID id,
-	     const char *param,
-	     int value
-) {
-	evContext_p *ctx = opaqueCtx.opaque;
-	evTimer *timer = id.opaque;
-	int result=0;
-
-	UNUSED(value);
-
-	if (heap_element(ctx->timers, timer->index) != timer)
-		EV_ERR(ENOENT);
-
-	if (strcmp(param, "rate") == 0)
-		timer->mode |= EV_TMR_RATE;
-	else if (strcmp(param, "interval") == 0)
-		timer->mode &= ~EV_TMR_RATE;
-	else
-		EV_ERR(EINVAL);
-
-	return (result);
-}
-
-int
-evResetTimer(evContext opaqueCtx,
-	     evTimerID id,
-	     evTimerFunc func,
-	     void *uap,
-	     struct timespec due,
-	     struct timespec inter
-) {
-	evContext_p *ctx = opaqueCtx.opaque;
-	evTimer *timer = id.opaque;
-	struct timespec old_due;
-	int result=0;
-
-	if (heap_element(ctx->timers, timer->index) != timer)
-		EV_ERR(ENOENT);
-
-#ifdef __hpux
-	/*
-	 * tv_sec and tv_nsec are unsigned.
-	 */
-	if (due.tv_nsec >= BILLION)
-		EV_ERR(EINVAL);
-
-	if (inter.tv_nsec >= BILLION)
-		EV_ERR(EINVAL);
-#else
-	if (due.tv_sec < 0 || due.tv_nsec < 0 || due.tv_nsec >= BILLION)
-		EV_ERR(EINVAL);
-
-	if (inter.tv_sec < 0 || inter.tv_nsec < 0 || inter.tv_nsec >= BILLION)
-		EV_ERR(EINVAL);
-#endif
-
-	old_due = timer->due;
-
-	timer->func = func;
-	timer->uap = uap;
-	timer->due = due;
-	timer->inter = inter;
-
-	switch (evCmpTime(due, old_due)) {
-	case -1:
-		result = heap_increased(ctx->timers, timer->index);
-		break;
-	case 0:
-		result = 0;
-		break;
-	case 1:
-		result = heap_decreased(ctx->timers, timer->index);
-		break;
-	}
-
-	if (ctx->debug > 7) {
-		evPrintf(ctx, 7, "timers after evResetTimer:\n");
-		(void) heap_for_each(ctx->timers, print_timer, (void *)ctx);
-	}
-
-	return (result);
-}
-
-int
-evSetIdleTimer(evContext opaqueCtx,
-		evTimerFunc func,
-		void *uap,
-		struct timespec max_idle,
-		evTimerID *opaqueID
-) {
-	evContext_p *ctx = opaqueCtx.opaque;
-	idle_timer *tt;
-
-	/* Allocate and fill. */
-	OKNEW(tt);
-	tt->func = func;
-	tt->uap = uap;
-	tt->lastTouched = ctx->lastEventTime;
-	tt->max_idle = max_idle;
-
-	if (evSetTimer(opaqueCtx, idle_timeout, tt,
-		       evAddTime(ctx->lastEventTime, max_idle),
-		       max_idle, opaqueID) < 0) {
-		FREE(tt);
-		return (-1);
-	}
-
-	tt->timer = opaqueID->opaque;
-
-	return (0);
-}
-
-int
-evClearIdleTimer(evContext opaqueCtx, evTimerID id) {
-	evTimer *del = id.opaque;
-	idle_timer *tt = del->uap;
-
-	FREE(tt);
-	return (evClearTimer(opaqueCtx, id));
-}
-
-int
-evResetIdleTimer(evContext opaqueCtx,
-		 evTimerID opaqueID,
-		 evTimerFunc func,
-		 void *uap,
-		 struct timespec max_idle
-) {
-	evContext_p *ctx = opaqueCtx.opaque;
-	evTimer *timer = opaqueID.opaque;
-	idle_timer *tt = timer->uap;
-
-	tt->func = func;
-	tt->uap = uap;
-	tt->lastTouched = ctx->lastEventTime;
-	tt->max_idle = max_idle;
-
-	return (evResetTimer(opaqueCtx, opaqueID, idle_timeout, tt,
-			     evAddTime(ctx->lastEventTime, max_idle),
-			     max_idle));
-}
-
-int
-evTouchIdleTimer(evContext opaqueCtx, evTimerID id) {
-	evContext_p *ctx = opaqueCtx.opaque;
-	evTimer *t = id.opaque;
-	idle_timer *tt = t->uap;
-
-	tt->lastTouched = ctx->lastEventTime;
-
-	return (0);
-}
-
-/* Public to the rest of eventlib. */
-
-heap_context
-evCreateTimers(const evContext_p *ctx) {
-
-	UNUSED(ctx);
-
-	return (heap_new(due_sooner, set_index, 2048));
-}
-
-void
-evDestroyTimers(const evContext_p *ctx) {
-	(void) heap_for_each(ctx->timers, free_timer, NULL);
-	(void) heap_free(ctx->timers);
-}
-
-/* Private. */
-
-static int
-due_sooner(void *a, void *b) {
-	evTimer *a_timer, *b_timer;
-
-	a_timer = a;
-	b_timer = b;
-	return (evCmpTime(a_timer->due, b_timer->due) < 0);
-}
-
-static void
-set_index(void *what, int index) {
-	evTimer *timer;
-
-	timer = what;
-	timer->index = index;
-}
-
-static void
-free_timer(void *what, void *uap) {
-	evTimer *t = what;
-
-	UNUSED(uap);
-
-	FREE(t);
-}
-
-static void
-print_timer(void *what, void *uap) {
-	evTimer *cur = what;
-	evContext_p *ctx = uap;
-
-	cur = what;
-	evPrintf(ctx, 7,
-	    "  func %p, uap %p, due %ld.%09ld, inter %ld.%09ld\n",
-		 cur->func, cur->uap,
-		 (long)cur->due.tv_sec, cur->due.tv_nsec,
-		 (long)cur->inter.tv_sec, cur->inter.tv_nsec);
-}
-
-static void
-idle_timeout(evContext opaqueCtx,
-	     void *uap,
-	     struct timespec due,
-	     struct timespec inter
-) {
-	evContext_p *ctx = opaqueCtx.opaque;
-	idle_timer *this = uap;
-	struct timespec idle;
-
-	UNUSED(due);
-	UNUSED(inter);
-	
-	idle = evSubTime(ctx->lastEventTime, this->lastTouched);
-	if (evCmpTime(idle, this->max_idle) >= 0) {
-		(this->func)(opaqueCtx, this->uap, this->timer->due,
-			     this->max_idle);
-		/*
-		 * Setting the interval to zero will cause the timer to
-		 * be cleaned up in evDrop().
-		 */
-		this->timer->inter = evConsTime(0, 0);
-		FREE(this);
-	} else {
-		/* evDrop() will reschedule the timer. */
-		this->timer->inter = evSubTime(this->max_idle, idle);
-	}
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/isc/ev_waits.c b/contrib/bind9/lib/bind/isc/ev_waits.c
deleted file mode 100644
index d33b061..0000000
--- a/contrib/bind9/lib/bind/isc/ev_waits.c
+++ /dev/null
@@ -1,247 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996-1999 by 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.
- */
-
-/* ev_waits.c - implement deferred function calls for the eventlib
- * vix 05dec95 [initial]
- */
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: ev_waits.c,v 1.3.18.1 2005/04/27 05:01:06 sra Exp $";
-#endif
-
-#include "port_before.h"
-#include "fd_setsize.h"
-
-#include <errno.h>
-
-#include <isc/eventlib.h>
-#include <isc/assertions.h>
-#include "eventlib_p.h"
-
-#include "port_after.h"
-
-/* Forward. */
-
-static void		print_waits(evContext_p *ctx);
-static evWaitList *	evNewWaitList(evContext_p *);
-static void		evFreeWaitList(evContext_p *, evWaitList *);
-static evWaitList *	evGetWaitList(evContext_p *, const void *, int);
-
-
-/* Public. */
-
-/*%
- * Enter a new wait function on the queue.
- */
-int
-evWaitFor(evContext opaqueCtx, const void *tag,
-	  evWaitFunc func, void *uap, evWaitID *id)
-{
-	evContext_p *ctx = opaqueCtx.opaque;
-	evWait *new;
-	evWaitList *wl = evGetWaitList(ctx, tag, 1);
-
-	OKNEW(new);
-	new->func = func;
-	new->uap = uap;
-	new->tag = tag;
-	new->next = NULL;
-	if (wl->last != NULL)
-		wl->last->next = new;
-	else
-		wl->first = new;
-	wl->last = new;
-	if (id != NULL)
-		id->opaque = new;
-	if (ctx->debug >= 9)
-		print_waits(ctx);
-	return (0);
-}
-
-/*%
- * Mark runnable all waiting functions having a certain tag.
- */
-int
-evDo(evContext opaqueCtx, const void *tag) {
-	evContext_p *ctx = opaqueCtx.opaque;
-	evWaitList *wl = evGetWaitList(ctx, tag, 0);
-	evWait *first;
-
-	if (!wl) {
-		errno = ENOENT;
-		return (-1);
-	}
-
-	first = wl->first;
-	INSIST(first != NULL);
-
-	if (ctx->waitDone.last != NULL)
-		ctx->waitDone.last->next = first;
-	else
-		ctx->waitDone.first = first;
-	ctx->waitDone.last = wl->last;
-	evFreeWaitList(ctx, wl);
-
-	return (0);
-}
-
-/*%
- * Remove a waiting (or ready to run) function from the queue.
- */
-int
-evUnwait(evContext opaqueCtx, evWaitID id) {
-	evContext_p *ctx = opaqueCtx.opaque;
-	evWait *this, *prev;
-	evWaitList *wl;
-	int found = 0;
-
-	this = id.opaque;
-	INSIST(this != NULL);
-	wl = evGetWaitList(ctx, this->tag, 0);
-	if (wl != NULL) {
-		for (prev = NULL, this = wl->first;
-		     this != NULL;
-		     prev = this, this = this->next)
-			if (this == (evWait *)id.opaque) {
-				found = 1;
-				if (prev != NULL)
-					prev->next = this->next;
-				else
-					wl->first = this->next;
-				if (wl->last == this)
-					wl->last = prev;
-				if (wl->first == NULL)
-					evFreeWaitList(ctx, wl);
-				break;
-			}
-	}
-
-	if (!found) {
-		/* Maybe it's done */
-		for (prev = NULL, this = ctx->waitDone.first;
-		     this != NULL;
-		     prev = this, this = this->next)
-			if (this == (evWait *)id.opaque) {
-				found = 1;
-				if (prev != NULL)
-					prev->next = this->next;
-				else
-					ctx->waitDone.first = this->next;
-				if (ctx->waitDone.last == this)
-					ctx->waitDone.last = prev;
-				break;
-			}
-	}
-
-	if (!found) {
-		errno = ENOENT;
-		return (-1);
-	}
-
-	FREE(this);
-
-	if (ctx->debug >= 9)
-		print_waits(ctx);
-
-	return (0);
-}
-
-int
-evDefer(evContext opaqueCtx, evWaitFunc func, void *uap) {
-	evContext_p *ctx = opaqueCtx.opaque;
-	evWait *new;
-
-	OKNEW(new);
-	new->func = func;
-	new->uap = uap;
-	new->tag = NULL;
-	new->next = NULL;
-	if (ctx->waitDone.last != NULL)
-		ctx->waitDone.last->next = new;
-	else
-		ctx->waitDone.first = new;
-	ctx->waitDone.last = new;
-	if (ctx->debug >= 9)
-		print_waits(ctx);
-	return (0);
-}
-
-/* Private. */
-
-static void
-print_waits(evContext_p *ctx) {
-	evWaitList *wl;
-	evWait *this;
-
-	evPrintf(ctx, 9, "wait waiting:\n");
-	for (wl = ctx->waitLists; wl != NULL; wl = wl->next) {
-		INSIST(wl->first != NULL);
-		evPrintf(ctx, 9, "  tag %p:", wl->first->tag);
-		for (this = wl->first; this != NULL; this = this->next)
-			evPrintf(ctx, 9, " %p", this);
-		evPrintf(ctx, 9, "\n");
-	}
-	evPrintf(ctx, 9, "wait done:");
-	for (this = ctx->waitDone.first; this != NULL; this = this->next)
-		evPrintf(ctx, 9, " %p", this);
-	evPrintf(ctx, 9, "\n");
-}
-
-static evWaitList *
-evNewWaitList(evContext_p *ctx) {
-	evWaitList *new;
-
-	NEW(new);
-	if (new == NULL)
-		return (NULL);
-	new->first = new->last = NULL;
-	new->prev = NULL;
-	new->next = ctx->waitLists;
-	if (new->next != NULL)
-		new->next->prev = new;
-	ctx->waitLists = new;
-	return (new);
-}
-
-static void
-evFreeWaitList(evContext_p *ctx, evWaitList *this) {
-
-	INSIST(this != NULL);
-
-	if (this->prev != NULL)
-		this->prev->next = this->next;
-	else
-		ctx->waitLists = this->next;
-	if (this->next != NULL)
-		this->next->prev = this->prev;
-	FREE(this);
-}
-
-static evWaitList *
-evGetWaitList(evContext_p *ctx, const void *tag, int should_create) {
-	evWaitList *this;
-
-	for (this = ctx->waitLists; this != NULL; this = this->next) {
-		if (this->first != NULL && this->first->tag == tag)
-			break;
-	}
-	if (this == NULL && should_create)
-		this = evNewWaitList(ctx);
-	return (this);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/isc/eventlib.c b/contrib/bind9/lib/bind/isc/eventlib.c
deleted file mode 100644
index 20624d0..0000000
--- a/contrib/bind9/lib/bind/isc/eventlib.c
+++ /dev/null
@@ -1,933 +0,0 @@
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-/* eventlib.c - implement glue for the eventlib
- * vix 09sep95 [initial]
- */
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: eventlib.c,v 1.5.18.5 2006/03/10 00:20:08 marka Exp $";
-#endif
-
-#include "port_before.h"
-#include "fd_setsize.h"
-
-#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>
-#include <stdarg.h>
-#include <stdlib.h>
-#include <unistd.h>
-
-#include <isc/eventlib.h>
-#include <isc/assertions.h>
-#include "eventlib_p.h"
-
-#include "port_after.h"
-
-int      __evOptMonoTime;
-
-#ifdef USE_POLL
-#define	pselect Pselect
-#endif /* USE_POLL */
-
-/* Forward. */
-
-#if defined(NEED_PSELECT) || defined(USE_POLL)
-static int		pselect(int, void *, void *, void *,
-				struct timespec *,
-				const sigset_t *);
-#endif
-
-int    __evOptMonoTime;
-
-/* Public. */
-
-int
-evCreate(evContext *opaqueCtx) {
-	evContext_p *ctx;
-
-	/* Make sure the memory heap is initialized. */
-	if (meminit(0, 0) < 0 && errno != EEXIST)
-		return (-1);
-
-	OKNEW(ctx);
-
-	/* Global. */
-	ctx->cur = NULL;
-
-	/* Debugging. */
-	ctx->debug = 0;
-	ctx->output = NULL;
-
-	/* Connections. */
-	ctx->conns = NULL;
-	INIT_LIST(ctx->accepts);
-
-	/* Files. */
-	ctx->files = NULL;
-#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 */
-	FD_ZERO(&ctx->rdNext);
-	FD_ZERO(&ctx->wrNext);
-	FD_ZERO(&ctx->exNext);
-	FD_ZERO(&ctx->nonblockBefore);
-	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 /* USE_POLL */
-#ifdef EVENTLIB_TIME_CHECKS
-	ctx->lastFdCount = 0;
-#endif
-
-	/* Streams. */
-	ctx->streams = NULL;
-	ctx->strDone = NULL;
-	ctx->strLast = NULL;
-
-	/* Timers. */
-	ctx->lastEventTime = evNowTime();
-#ifdef EVENTLIB_TIME_CHECKS
-	ctx->lastSelectTime = ctx->lastEventTime;
-#endif
-	ctx->timers = evCreateTimers(ctx);
-	if (ctx->timers == NULL)
-		return (-1);
-
-	/* Waits. */
-	ctx->waitLists = NULL;
-	ctx->waitDone.first = ctx->waitDone.last = NULL;
-	ctx->waitDone.prev = ctx->waitDone.next = NULL;
-
-	opaqueCtx->opaque = ctx;
-	return (0);
-}
-
-void
-evSetDebug(evContext opaqueCtx, int level, FILE *output) {
-	evContext_p *ctx = opaqueCtx.opaque;
-
-	ctx->debug = level;
-	ctx->output = output;
-}
-
-int
-evDestroy(evContext opaqueCtx) {
-	evContext_p *ctx = opaqueCtx.opaque;
-	int revs = 424242;	/*%< Doug Adams. */
-	evWaitList *this_wl, *next_wl;
-	evWait *this_wait, *next_wait;
-
-	/* Connections. */
-	while (revs-- > 0 && ctx->conns != NULL) {
-		evConnID id;
-
-		id.opaque = ctx->conns;
-		(void) evCancelConn(opaqueCtx, id);
-	}
-	INSIST(revs >= 0);
-
-	/* Streams. */
-	while (revs-- > 0 && ctx->streams != NULL) {
-		evStreamID id;
-
-		id.opaque = ctx->streams;
-		(void) evCancelRW(opaqueCtx, id);
-	}
-
-	/* Files. */
-	while (revs-- > 0 && ctx->files != NULL) {
-		evFileID id;
-
-		id.opaque = ctx->files;
-		(void) evDeselectFD(opaqueCtx, id);
-	}
-	INSIST(revs >= 0);
-
-	/* Timers. */
-	evDestroyTimers(ctx);
-
-	/* Waits. */
-	for (this_wl = ctx->waitLists;
-	     revs-- > 0 && this_wl != NULL;
-	     this_wl = next_wl) {
-		next_wl = this_wl->next;
-		for (this_wait = this_wl->first;
-		     revs-- > 0 && this_wait != NULL;
-		     this_wait = next_wait) {
-			next_wait = this_wait->next;
-			FREE(this_wait);
-		}
-		FREE(this_wl);
-	}
-	for (this_wait = ctx->waitDone.first;
-	     revs-- > 0 && this_wait != NULL;
-	     this_wait = next_wait) {
-		next_wait = this_wait->next;
-		FREE(this_wait);
-	}
-
-	FREE(ctx);
-	return (0);
-}
-
-int
-evGetNext(evContext opaqueCtx, evEvent *opaqueEv, int options) {
-	evContext_p *ctx = opaqueCtx.opaque;
-	struct timespec nextTime;
-	evTimer *nextTimer;
-	evEvent_p *new;
-	int x, pselect_errno, timerPast;
-#ifdef EVENTLIB_TIME_CHECKS
-	struct timespec interval;
-#endif
-
-	/* Ensure that exactly one of EV_POLL or EV_WAIT was specified. */
-	x = ((options & EV_POLL) != 0) + ((options & EV_WAIT) != 0);
-	if (x != 1)
-		EV_ERR(EINVAL);
-
-	/* Get the time of day.  We'll do this again after select() blocks. */
-	ctx->lastEventTime = evNowTime();
-
- again:
-	/* Finished accept()'s do not require a select(). */
-	if (!EMPTY(ctx->accepts)) {
-		OKNEW(new);
-		new->type = Accept;
-		new->u.accept.this = HEAD(ctx->accepts);
-		UNLINK(ctx->accepts, HEAD(ctx->accepts), link);
-		opaqueEv->opaque = new;
-		return (0);
-	}
-
-	/* Stream IO does not require a select(). */
-	if (ctx->strDone != NULL) {
-		OKNEW(new);
-		new->type = Stream;
-		new->u.stream.this = ctx->strDone;
-		ctx->strDone = ctx->strDone->nextDone;
-		if (ctx->strDone == NULL)
-			ctx->strLast = NULL;
-		opaqueEv->opaque = new;
-		return (0);
-	}
-
-	/* Waits do not require a select(). */
-	if (ctx->waitDone.first != NULL) {
-		OKNEW(new);
-		new->type = Wait;
-		new->u.wait.this = ctx->waitDone.first;
-		ctx->waitDone.first = ctx->waitDone.first->next;
-		if (ctx->waitDone.first == NULL)
-			ctx->waitDone.last = NULL;
-		opaqueEv->opaque = new;
-		return (0);
-	}
-
-	/* Get the status and content of the next timer. */
-	if ((nextTimer = heap_element(ctx->timers, 1)) != NULL) {
-		nextTime = nextTimer->due;
-		timerPast = (evCmpTime(nextTime, ctx->lastEventTime) <= 0);
-	} else
-		timerPast = 0;	/*%< Make gcc happy. */
-	evPrintf(ctx, 9, "evGetNext: fdCount %d\n", ctx->fdCount);
-	if (ctx->fdCount == 0) {
-		static const struct timespec NoTime = {0, 0L};
-		enum { JustPoll, Block, Timer } m;
-		struct timespec t, *tp;
-
-		/* Are there any events at all? */
-		if ((options & EV_WAIT) != 0 && !nextTimer && ctx->fdMax == -1)
-			EV_ERR(ENOENT);
-
-		/* Figure out what select()'s timeout parameter should be. */
-		if ((options & EV_POLL) != 0) {
-			m = JustPoll;
-			t = NoTime;
-			tp = &t;
-		} else if (nextTimer == NULL) {
-			m = Block;
-			/* ``t'' unused. */
-			tp = NULL;
-		} else if (timerPast) {
-			m = JustPoll;
-			t = NoTime;
-			tp = &t;
-		} else {
-			m = Timer;
-			/* ``t'' filled in later. */
-			tp = &t;
-		}
-#ifdef EVENTLIB_TIME_CHECKS
-		if (ctx->debug > 0) {
-			interval = evSubTime(ctx->lastEventTime,
-					     ctx->lastSelectTime);
-			if (interval.tv_sec > 0 || interval.tv_nsec > 0)
-				evPrintf(ctx, 1,
-				   "time between pselect() %u.%09u count %d\n",
-					 interval.tv_sec, interval.tv_nsec,
-					 ctx->lastFdCount);
-		}
-#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);
-			}
-
-			/* 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();
-
-			/* Select() likes to finish about 10ms early. */
-		} while (x == 0 && m == Timer &&
-			 evCmpTime(ctx->lastEventTime, nextTime) < 0);
-#ifdef EVENTLIB_TIME_CHECKS
-		ctx->lastSelectTime = ctx->lastEventTime;
-#endif
-		if (x < 0) {
-			if (pselect_errno == EINTR) {
-				if ((options & EV_NULL) != 0)
-					goto again;
-				OKNEW(new);
-				new->type = Null;
-				/* No data. */
-				opaqueEv->opaque = new;
-				return (0);
-			}
-			if (pselect_errno == EBADF) {
-				for (x = 0; x <= ctx->fdMax; x++) {
-					struct stat sb;
-
-					if (FD_ISSET(x, &ctx->rdNext) == 0 &&
-					    FD_ISSET(x, &ctx->wrNext) == 0 &&
-					    FD_ISSET(x, &ctx->exNext) == 0)
-						continue;
-					if (fstat(x, &sb) == -1 &&
-					    errno == EBADF)
-						evPrintf(ctx, 1, "EBADF: %d\n",
-							 x);
-				}
-				abort();
-			}
-			EV_ERR(pselect_errno);
-		}
-		if (x == 0 && (nextTimer == NULL || !timerPast) &&
-		    (options & EV_POLL))
-			EV_ERR(EWOULDBLOCK);
-		ctx->fdCount = x;
-#ifdef EVENTLIB_TIME_CHECKS
-		ctx->lastFdCount = x;
-#endif
-	}
-	INSIST(nextTimer || ctx->fdCount);
-
-	/* Timers go first since we'd like them to be accurate. */
-	if (nextTimer && !timerPast) {
-		/* Has anything happened since we blocked? */
-		timerPast = (evCmpTime(nextTime, ctx->lastEventTime) <= 0);
-	}
-	if (nextTimer && timerPast) {
-		OKNEW(new);
-		new->type = Timer;
-		new->u.timer.this = nextTimer;
-		opaqueEv->opaque = new;
-		return (0);
-	}
-
-	/* No timers, so there should be a ready file descriptor. */
-	x = 0;
-	while (ctx->fdCount > 0) {
-		evFile *fid;
-		int fd, eventmask;
-
-		if (ctx->fdNext == NULL) {
-			if (++x == 2) {
-				/*
-				 * Hitting the end twice means that the last
-				 * select() found some FD's which have since
-				 * been deselected.
-				 *
-				 * On some systems, the count returned by
-				 * selects is the total number of bits in
-				 * all masks that are set, and on others it's
-				 * the number of fd's that have some bit set,
-				 * and on others, it's just broken.  We 
-				 * always assume that it's the number of
-				 * bits set in all masks, because that's what
-				 * the man page says it should do, and
-				 * the worst that can happen is we do an
-				 * extra select().
-				 */
-				ctx->fdCount = 0;
-				break;
-			}
-			ctx->fdNext = ctx->files;
-		}
-		fid = ctx->fdNext;
-		ctx->fdNext = fid->next;
-
-		fd = fid->fd;
-		eventmask = 0;
-		if (FD_ISSET(fd, &ctx->rdLast))
-			eventmask |= EV_READ;
-		if (FD_ISSET(fd, &ctx->wrLast))
-			eventmask |= EV_WRITE;
-		if (FD_ISSET(fd, &ctx->exLast))
-			eventmask |= EV_EXCEPT;
-		eventmask &= fid->eventmask;
-		if (eventmask != 0) {
-			if ((eventmask & EV_READ) != 0) {
-				FD_CLR(fd, &ctx->rdLast);
-				ctx->fdCount--;
-			}
-			if ((eventmask & EV_WRITE) != 0) {
-				FD_CLR(fd, &ctx->wrLast);
-				ctx->fdCount--;
-			}
-			if ((eventmask & EV_EXCEPT) != 0) {
-				FD_CLR(fd, &ctx->exLast);
-				ctx->fdCount--;
-			}
-			OKNEW(new);
-			new->type = File;
-			new->u.file.this = fid;
-			new->u.file.eventmask = eventmask;
-			opaqueEv->opaque = new;
-			return (0);
-		}
-	}
-	if (ctx->fdCount < 0) {
-		/*
-		 * select()'s count is off on a number of systems, and
-		 * can result in fdCount < 0.
-		 */
-		evPrintf(ctx, 4, "fdCount < 0 (%d)\n", ctx->fdCount);
-		ctx->fdCount = 0;
-	}
-
-	/* We get here if the caller deselect()'s an FD. Gag me with a goto. */
-	goto again;
-}
-
-int
-evDispatch(evContext opaqueCtx, evEvent opaqueEv) {
-	evContext_p *ctx = opaqueCtx.opaque;
-	evEvent_p *ev = opaqueEv.opaque;
-#ifdef EVENTLIB_TIME_CHECKS
-	void *func;
-	struct timespec start_time;
-	struct timespec interval;
-#endif
-
-#ifdef EVENTLIB_TIME_CHECKS
-	if (ctx->debug > 0)
-		start_time = evNowTime();
-#endif
-	ctx->cur = ev;
-	switch (ev->type) {
-	    case Accept: {
-		evAccept *this = ev->u.accept.this;
-
-		evPrintf(ctx, 5,
-			"Dispatch.Accept: fd %d -> %d, func %p, uap %p\n",
-			 this->conn->fd, this->fd,
-			 this->conn->func, this->conn->uap);
-		errno = this->ioErrno;
-		(this->conn->func)(opaqueCtx, this->conn->uap, this->fd,
-				   &this->la, this->lalen,
-				   &this->ra, this->ralen);
-#ifdef EVENTLIB_TIME_CHECKS
-		func = this->conn->func;
-#endif
-		break;
-	    }
-	    case File: {
-		evFile *this = ev->u.file.this;
-		int eventmask = ev->u.file.eventmask;
-
-		evPrintf(ctx, 5,
-			"Dispatch.File: fd %d, mask 0x%x, func %p, uap %p\n",
-			 this->fd, this->eventmask, this->func, this->uap);
-		(this->func)(opaqueCtx, this->uap, this->fd, eventmask);
-#ifdef EVENTLIB_TIME_CHECKS
-		func = this->func;
-#endif
-		break;
-	    }
-	    case Stream: {
-		evStream *this = ev->u.stream.this;
-
-		evPrintf(ctx, 5,
-			 "Dispatch.Stream: fd %d, func %p, uap %p\n",
-			 this->fd, this->func, this->uap);
-		errno = this->ioErrno;
-		(this->func)(opaqueCtx, this->uap, this->fd, this->ioDone);
-#ifdef EVENTLIB_TIME_CHECKS
-		func = this->func;
-#endif
-		break;
-	    }
-	    case Timer: {
-		evTimer *this = ev->u.timer.this;
-
-		evPrintf(ctx, 5, "Dispatch.Timer: func %p, uap %p\n",
-			 this->func, this->uap);
-		(this->func)(opaqueCtx, this->uap, this->due, this->inter);
-#ifdef EVENTLIB_TIME_CHECKS
-		func = this->func;
-#endif
-		break;
-	    }
-	    case Wait: {
-		evWait *this = ev->u.wait.this;
-
-		evPrintf(ctx, 5,
-			 "Dispatch.Wait: tag %p, func %p, uap %p\n",
-			 this->tag, this->func, this->uap);
-		(this->func)(opaqueCtx, this->uap, this->tag);
-#ifdef EVENTLIB_TIME_CHECKS
-		func = this->func;
-#endif
-		break;
-	    }
-	    case Null: {
-		/* No work. */
-#ifdef EVENTLIB_TIME_CHECKS
-		func = NULL;
-#endif
-		break;
-	    }
-	    default: {
-		abort();
-	    }
-	}
-#ifdef EVENTLIB_TIME_CHECKS
-	if (ctx->debug > 0) {
-		interval = evSubTime(evNowTime(), start_time);
-		/* 
-		 * Complain if it took longer than 50 milliseconds.
-		 *
-		 * We call getuid() to make an easy to find mark in a kernel
-		 * trace.
-		 */
-		if (interval.tv_sec > 0 || interval.tv_nsec > 50000000)
-			evPrintf(ctx, 1,
-			 "dispatch interval %u.%09u uid %d type %d func %p\n",
-				 interval.tv_sec, interval.tv_nsec,
-				 getuid(), ev->type, func);
-	}
-#endif
-	ctx->cur = NULL;
-	evDrop(opaqueCtx, opaqueEv);
-	return (0);
-}
-
-void
-evDrop(evContext opaqueCtx, evEvent opaqueEv) {
-	evContext_p *ctx = opaqueCtx.opaque;
-	evEvent_p *ev = opaqueEv.opaque;
-
-	switch (ev->type) {
-	    case Accept: {
-		FREE(ev->u.accept.this);
-		break;
-	    }
-	    case File: {
-		/* No work. */
-		break;
-	    }
-	    case Stream: {
-		evStreamID id;
-
-		id.opaque = ev->u.stream.this;
-		(void) evCancelRW(opaqueCtx, id);
-		break;
-	    }
-	    case Timer: {
-		evTimer *this = ev->u.timer.this;
-		evTimerID opaque;
-
-		/* Check to see whether the user func cleared the timer. */
-		if (heap_element(ctx->timers, this->index) != this) {
-			evPrintf(ctx, 5, "Dispatch.Timer: timer rm'd?\n");
-			break;
-		}
-		/*
-		 * Timer is still there.  Delete it if it has expired,
-		 * otherwise set it according to its next interval.
-		 */
-		if (this->inter.tv_sec == (time_t)0 &&
-		    this->inter.tv_nsec == 0L) {
-			opaque.opaque = this;			
-			(void) evClearTimer(opaqueCtx, opaque);
-		} else {
-			opaque.opaque = this;
-			(void) evResetTimer(opaqueCtx, opaque, this->func,
-					    this->uap,
-					    evAddTime((this->mode & EV_TMR_RATE) ?
-						      this->due :
-						      ctx->lastEventTime,
-						      this->inter),
-					    this->inter);
-		}
-		break;
-	    }
-	    case Wait: {
-		FREE(ev->u.wait.this);
-		break;
-	    }
-	    case Null: {
-		/* No work. */
-		break;
-	    }
-	    default: {
-		abort();
-	    }
-	}
-	FREE(ev);
-}
-
-int
-evMainLoop(evContext opaqueCtx) {
-	evEvent event;
-	int x;
-
-	while ((x = evGetNext(opaqueCtx, &event, EV_WAIT)) == 0)
-		if ((x = evDispatch(opaqueCtx, event)) < 0)
-			break;
-	return (x);
-}
-
-int
-evHighestFD(evContext opaqueCtx) {
-	evContext_p *ctx = opaqueCtx.opaque;
-
-	return (ctx->highestFD);
-}
-
-void
-evPrintf(const evContext_p *ctx, int level, const char *fmt, ...) {
-	va_list ap;
-
-	va_start(ap, fmt);
-	if (ctx->output != NULL && ctx->debug >= level) {
-		vfprintf(ctx->output, fmt, ap);
-		fflush(ctx->output);
-	}
-	va_end(ap);
-}
-
-int
-evSetOption(evContext *opaqueCtx, const char *option, int value) {
-	/* evContext_p *ctx = opaqueCtx->opaque; */
-
-	UNUSED(opaqueCtx);
-	UNUSED(value);
-#ifndef CLOCK_MONOTONIC
-	UNUSED(option);
-#endif 
-
-#ifdef CLOCK_MONOTONIC
-	if (strcmp(option, "monotime") == 0) {
-		if (opaqueCtx  != NULL)
-			errno = EINVAL;
-		if (value == 0 || value == 1) {
-			__evOptMonoTime = value;
-			return (0);
-		} else {
-			errno = EINVAL;
-			return (-1);
-		}
-	} 
-#endif
-	errno = ENOENT;
-	return (-1);
-}
-
-int
-evGetOption(evContext *opaqueCtx, const char *option, int *value) {
-	/* evContext_p *ctx = opaqueCtx->opaque; */
-
-	UNUSED(opaqueCtx);
-#ifndef CLOCK_MONOTONIC
-	UNUSED(value);
-	UNUSED(option);
-#endif 
-
-#ifdef CLOCK_MONOTONIC
-	if (strcmp(option, "monotime") == 0) {
-		if (opaqueCtx  != NULL)
-			errno = EINVAL;
-		*value = __evOptMonoTime;
-		return (0);
-	}
-#endif
-	errno = ENOENT;
-	return (-1);
-}
-
-#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,
-	struct timespec *tsp,
-	const sigset_t *sigmask)
-{
-	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);
-	if (n > 0) {
-		int     i, e;
-
-		INSIST(ctx != NULL);
-		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)
-		*tsp = evTimeSpec(tv);
-	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.mdoc b/contrib/bind9/lib/bind/isc/eventlib.mdoc
deleted file mode 100644
index 5e9cd85..0000000
--- a/contrib/bind9/lib/bind/isc/eventlib.mdoc
+++ /dev/null
@@ -1,918 +0,0 @@
-.\" $Id: eventlib.mdoc,v 1.3 2004/03/09 06:30:08 marka Exp $
-.\"
-.\" Copyright (c) 2004 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
-.\" 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.
-.\"
-.Dd March 6, 1996
-.Dt EVENTLIB 3
-.Os BSD 4
-.Sh NAME
-.Nm evConnFunc ,
-.Nm evFileFunc ,
-.Nm evStreamFunc ,
-.Nm evTimerFunc ,
-.Nm evWaitFunc ,
-.Nm evCreate ,
-.Nm evDestroy ,
-.Nm evGetNext ,
-.Nm evDispatch ,
-.Nm evDrop ,
-.Nm evMainLoop ,
-.Nm evConsTime ,
-.Nm evTimeSpec ,
-.Nm evTimeVal ,
-.Nm evAddTime ,
-.Nm evSubTime ,
-.Nm evCmpTime ,
-.Nm evNowTime ,
-.Nm evUTCTime ,
-.Nm evLastEventTime ,
-.Nm evSetTimer ,
-.Nm evResetTimer ,
-.Nm evConfigTimer ,
-.Nm evClearTimer ,
-.Nm evSetIdleTimer ,
-.Nm evTouchIdleTimer ,
-.Nm evClearIdleTimer ,
-.Nm evWaitFor ,
-.Nm evDo ,
-.Nm evUnwait ,
-.Nm evDefer ,
-.Nm evSelectFD ,
-.Nm evDeselectFD ,
-.Nm evWrite ,
-.Nm evRead ,
-.Nm evCancelRW ,
-.Nm evTimeRW ,
-.Nm evUntimeRW ,
-.Nm evListen ,
-.Nm evConnect ,
-.Nm evCancelConn ,
-.Nm evHold ,
-.Nm evUnhold ,
-.Nm evTryAccept ,
-.Nm evConsIovec ,
-.Nm evSetDebug ,
-.Nm evPrintf ,
-.Nm evInitID ,
-.Nm evTestID ,
-.Nm evGetOption ,
-.Nm evSetOption
-.Nd event handling library
-.Sh SYNOPSIS
-.Fd #include <isc/eventlib.h>
-.Ft typedef void
-.Fn \*(lp*evConnFunc\*(rp "evContext ctx" "void *uap" "int fd" \
-"const void *la" "int lalen" "const void *ra" "int ralen"
-.Ft typedef void
-.Fn \*(lp*evTimerFunc\*(rp "evContext ctx" "void *uap" \
-"struct timespec due" "struct timespec inter"
-.Ft typedef void
-.Fn \*(lp*evFileFunc\*(rp "evContext ctx" "void *uap" "int fd" "int eventmask"
-.Ft typedef void
-.Fn \*(lp*evStreamFunc\*(rp "evContext ctx" "void *uap" "int fd" "int bytes"
-.Ft typedef void
-.Fn \*(lp*evWaitFunc\*(rp "evContext ctx" "void *uap" "const void *tag"
-.Ft int
-.Fn evCreate "evContext *ctx"
-.Ft int
-.Fn evDestroy "evContext ctx"
-.Ft int
-.Fn evGetNext "evContext ctx" "evEvent *ev" "int options"
-.Ft int
-.Fn evDispatch "evContext ctx" "evEvent ev"
-.Ft void
-.Fn evDrop "evContext ctx" "evEvent ev"
-.Ft int
-.Fn evMainLoop "evContext ctx"
-.Ft struct timespec
-.Fn evConsTime "int sec" "int usec"
-.Ft struct timespec
-.Fn evTimeSpec "struct timeval tv"
-.Ft struct timeval
-.Fn evTimeVal "struct timespec ts"
-.Ft struct timespec
-.Fn evAddTime "struct timespec addend1" "struct timespec addend2"
-.Ft struct timespec
-.Fn evSubTime "struct timespec minuend" "struct timespec subtrahend"
-.Ft struct timespec
-.Fn evCmpTime "struct timespec a" "struct timespec b"
-.Ft struct timespec
-.Fn evNowTime "void"
-.Ft struct timespec
-.Fn evUTCTime "void"
-.Ft struct timespec
-.Fn evLastEventTime "evContext opaqueCtx"
-.Ft int
-.Fn evSetTimer "evContext ctx" "evTimerFunc func" "void *uap" \
-"struct timespec due" "struct timespec inter" "evTimerID *id"
-.Ft int
-.Fn evResetTimer "evContext ctx" "evTimerID id" "evTimerFunc func" \
-"void *uap" "struct timespec due" "struct timespec inter"
-.Ft int
-.Fn evConfigTimer "evContext ctx" "evTimerID id" "const char *param" \
-"int value"
-.Ft int
-.Fn evClearTimer "evContext ctx" "evTimerID id"
-.Ft int
-.Fn evSetIdleTimer "evContext opaqueCtx" "evTimerFunc func" "void *uap" \
-"struct timespec max_idle" "evTimerID *opaqueID"
-.Ft int 
-.Fn evTouchIdleTimer "evContext opaqueCtx" "evTimerID id"
-.Ft int 
-.Fn evResetIdleTimer "evContext opaqueCtx" "evTimerID id" "evTimerFunc func" \
-"void *uap" "struct timespec max_idle"
-.Ft int
-.Fn evClearIdleTimer "evContext opaqueCtx" "evTimerID id"
-.Ft int
-.Fn evWaitFor "evContext opaqueCtx" "const void *tag" \
-"evWaitFunc func" "void *uap" "evWaitID *id"
-.Ft int
-.Fn evDo "evContext opaqueCtx" "const void *tag"
-.Ft int
-.Fn evUnwait "evContext opaqueCtx" "evWaitID id"
-.Ft int
-.Fn evDefer "evContext opaqueCtx" "evWaitFunc func" "void *uap"
-.Ft int
-.Fn evSelectFD "evContext ctx" "int fd" "int eventmask" \
-"evFileFunc func" "void *uap" "evFileID *id"
-.Ft int
-.Fn evDeselectFD "evContext ctx" "evFileID id"
-.Ft struct iovec
-.Fn evConsIovec "void *buf" "size_t cnt"
-.Ft int
-.Fn evWrite "evContext ctx" "int fd" "const struct iovec *iov" "int cnt" \
-"evStreamFunc func" "void *uap" "evStreamID *id"
-.Ft int
-.Fn evRead "evContext ctx" "int fd" "const struct iovec *iov" "int cnt" \
-"evStreamFunc func" "void *uap" "evStreamID *id"
-.Ft int
-.Fn evCancelRW "evContext ctx" "evStreamID id"
-.Ft int
-.Fn evTimeRW "evContext opaqueCtx" "evStreamID id" "evTimerID timer"
-.Ft int
-.Fn evUntimeRW "evContext opaqueCtx" "evStreamID id"
-.Ft int
-.Fn evListen "evContext ctx" "int fd" "int maxconn" \
-"evConnFunc func" "void *uap" "evConnID *id"
-.Ft int
-.Fn evConnect "evContext ctx" "int fd" "void *ra" "int ralen" \
-"evConnFunc func" "void *uap" "evConnID *id"
-.Ft int
-.Fn evCancelConn "evContext ctx" "evConnID id"
-.Ft int
-.Fn evHold "evContext ctx" "evConnID id"
-.Ft int
-.Fn evUnhold "evContext ctx" "evConnID id"
-.Ft int
-.Fn evTryAccept "evContext ctx" "evConnID id" "int *sys_errno"
-.Ft void
-.Fn evSetDebug "evContext ctx" "int level" "FILE *output"
-.Ft void
-.Fn evPrintf "const evContext_p *ctx" "int level" "const char *fmt" "..."
-.Ft void
-.Fn evInitID "*\s-1ID\s+1"
-.Ft int
-.Fn evTestID "\s-1ID\s+1"
-.Ft int
-.Fn evGetOption "evContext *ctx" "const char *option" "int *ret"
-.Ft int
-.Fn evSetOption "evContext *ctx" "const char *option" "int val"
-.Sh DESCRIPTION
-This library provides multiple outstanding asynchronous timers and I/O
-to a cooperating application.  The model is similar to that of the X
-Toolkit, in that events are registered with the library and the application
-spends most of its time in the
-.Fn evMainLoop
-function.  If an application already has a main loop, it can safely register
-events with this library as long as it periodically calls the
-.Fn evGetNext
-and
-.Fn evDispatch
-functions.  (Note that
-.Fn evGetNext
-has both polling and blocking modes.)
-.Pp
-The function
-.Fn evCreate
-creates an event context which is needed by all the other functions in this
-library.  All information used internally by this library is bound to this
-context, rather than to static storage.  This makes the library 
-.Dq thread safe ,
-and permits other library functions to use events without
-disrupting the application's use of events.
-.Pp
-The function
-.Fn evDestroy
-destroys a context that has been created by
-.Fn evCreate .
-All dynamic memory bound to this context will be freed.  An implicit
-.Fn evTimerClear
-will be done on all timers set in this event context.  An implicit
-.Fn evDeselectFD
-will be done on all file descriptors selected in this event context.
-.Pp
-The function
-.Fn evGetNext
-potentially waits for and then retrieves the next asynchronous event,
-placing it in the object of the
-.Fa ev
-pointer argument.  The following
-.Fa options
-are available:
-.Fa EV_POLL ,
-meaning that
-.Fn evGetNext
-should not block, but rather return
-.Dq Fa -1
-with
-.Fa errno
-set to
-.Fa EWOULDBLOCK
-if no events have occurred;
-.Fa EV_WAIT ,
-which tells
-.Fn evGetNext
-to block internally until the next event occurs; and
-.Fa EV_NULL ,
-which tells
-.Fn evGetNext
-that it should return a special 
-.Dq no-op 
-event, which is ignored by
-.Fn evDispatch
-but handled correctly by
-.Fn evDrop .
-.Fa EV_NULL
-can be necessary to the correct functioning of a caller\-written equivilent to
-.Fn evMainLoop ,
-wherein perterbations caused by external system events must be polled for, and
-the default behaviour of internally ignoring such events is undesirable.
-Note that
-.Fa EV_POLL
-and
-.Fa EV_WAIT
-are mutually exclusive.
-.Pp
-The function
-.Fn evDispatch
-dispatches an event retrieved by
-.Fn evGetNext .
-This usually involves calling the function that was associated with the event
-when the event was registered with
-.Fn evSetTimer ,
-.Fn evResetTimer ,
-or
-.Fn evSelectFD .
-All events retrieved by
-.Fn evGetNext
-must be given over to
-.Fn evDispatch
-at some point, since there is some dynamic memory associated with each event.
-.Pp
-The function
-.Fn evDrop
-deallocates dynamic memory that has been allocated by
-.Fn evGetNext .
-Calling
-.Fn evDispatch
-has the side effect of calling
-.Fn evDrop ,
-but if you are going to drop the event rather than dispatch it, you will have
-to call
-.Fn evDrop
-directly.
-.Pp
-The function
-.Fn evMainLoop
-is just:
-.Bd -literal -offset indent
-while ((x = evGetNext(opaqueCtx, &event, EV_WAIT)) == 0)
-	if ((x = evDispatch(opaqueCtx, event)) < 0)
-		break;
-return (x);
-.Ed
-.Pp
-In other words, get events and dispatch them until an error occurs.  One such
-error would be that all the events under this context become unregistered; in
-that event, there will be nothing to wait for and
-.Fn evGetNext
-becomes an undefined operation.
-.Pp
-The function
-.Fn evConsTime
-is a constructor for
-.Dq Fa struct timespec
-which allows these structures to be created and then passed as arguments to
-other functions without the use of temporary variables.  (If C had inline
-constructors, there would be no need for this function.)
-.Pp
-The functions
-.Fn evTimeSpec
-and
-.Fn evTimeVal 
-are utilities which allow the caller to convert a
-.Dq Fa struct timeval
-to a 
-.Dq Fa struct timespec
-(the function of
-.Fn evTimeSpec )
-or vice versa (the function of
-.Fn evTimeVal ) .
-Note that the name of the function indicates the type of the return value.
-.Pp
-The function
-.Fn evAddTime
-adds two
-.Dq Fa struct timespec
-values and returns the result as a
-.Dq Fa struct timespec .
-.Pp
-The function
-.Fn evSubTime
-subtracts its second
-.Dq Fa struct timespec
-argument from its first
-.Dq Fa struct timespec
-argument and returns the result as a
-.Dq Fa struct timespec .
-.Pp
-The function
-.Fn evCmpTime
-compares its two
-.Dq Fa struct timespec
-arguments and returns an
-.Dq Fa int
-that is less than zero if the first argument specifies an earlier time than
-the second, or more than zero if the first argument specifies a later time
-than the second, or equal to zero if both arguments specify the same time.
-.Pp
-The function
-.Fn evNowTime
-returns a
-.Dq Fa struct timespec
-which either describes the current time
-(using
-.Xr clock_gettime 2 or
-.Xr gettimeofday 2 ) ,
-if successful, or has its fields set to zero, if there is an error.
-(In the latter case, the caller can check
-.Va errno ,
-since it will be set by
-.Xr gettimeofday 2 . )
-The timestamp returned may not be UTC time if
-the "monotime" option has been enabled with
-.Fn evSetOption .
-.Pp
-The function 
-.Fn evUTCTime
-is like 
-.Fn evNowTime
-except the result is always on the UTC timescale.
-.Pp
-The function
-.Fn evLastEventTime 
-returns the
-.Dq Fa struct timespec
-which describes the last time that certain events happened to the 
-event context indicated by 
-.Fa opaqueCtx .
-This value is updated by
-.Fn evCreate 
-and
-.Fn evGetNext 
-(upon entry and after
-.Xr select 2
-returns); it is routinely compared with other times in the internal handling
-of, e.g., timers.
-.Pp
-The function
-.Fn evSetTimer
-registers a timer event, which will be delivered as a function call to the
-function specified by the
-.Fa func
-argument.  The event will be delivered at absolute time
-.Fa due ,
-and then if time
-.Fa inter
-is not equal to
-.Dq Fn evConsTime 0 0 ,
-subsequently at intervals equal to time
-.Fa inter .
-As a special case, specifying a
-.Fa due
-argument equal to
-.Dq Fn evConsTime 0 0
-means 
-.Dq due immediately .
-The
-.Fa opaqueID
-argument, if specified as a value other than
-.Fa NULL ,
-will be used to store the resulting 
-.Dq timer \s-1ID\s+1 , 
-useful as an argument to
-.Fn evClearTimer .
-Note that in a 
-.Dq one\-shot 
-timer (which has an
-.Fa inter
-argument equal to
-.Dq Fa evConsTime(0,0) )
-the user function
-.Fa func
-should deallocate any dynamic memory that is uniquely bound to the
-.Fa uap ,
-since no handles to this memory will exist within the event library
-after a one\-shot timer has been delivered.
-.Pp
-The function
-.Fn evResetTimer
-resets the values of the timer specified by
-.Fa id
-to the given arguments.  The arguments are the same as in the description of
-.Fn evSetTimer
-above.
-.Pp
-The function
-.Fn evClearTimer
-will unregister the timer event specified by
-.Fa id .
-Note that if the
-.Fa uap
-specified in the corresponding
-.Fn evSetTimer
-call is uniquely bound to any dynamic memory, then that dynamic memory should
-be freed by the caller before the handle is lost.  After a call to
-.Fn evClearTimer ,
-no handles to this
-.Fa uap
-will exist within the event library.
-.Pp
-The function
-.Fn evConfigTimer
-can be used to manipulate other aspects of a timer.
-Currently two modes are defined "rate" and "interval" which affect the
-way recurrent timers are scheduled.
-The default mode is "interval" where the event gets scheduled
-.Fa inter
-after last time it was run.
-If mode "rate" is selected the event gets scheduled
-.Fa inter
-after last time it was scheduled.
-For both "rate" and "interval" the numerical argument
-.Fa value
-is ignored.
-.Pp
-The function
-.Fn evSetIdleTimer 
-is similar to (and built on)
-.Fn evSetTimer ;
-it registers an idle timer event which provides for the function call to
-.Fa func
-to occur.  However, for an
-.Em idle
-timer, the call will occur after at least
-.Dq Fa max_idle
-time has passed since the time the idle timer was
-.Dq last touched ;
-originally, this is set to the time returned by
-.Fn evLastEventTime 
-(described above) for the event context specified by 
-.Fa opaqueCtx .  
-This is a 
-.Dq one\-shot 
-timer, but the time at which the
-.Fa func
-is actually called can be changed by recourse to
-.Fn evTouchIdleTimer
-(described below).  The pointer to the underlying 
-.Dq timer \s-1ID\s+1 
-is returned in
-.Fa opaqueID ,
-if it is
-.No non- Ns Dv NULL .
-.Pp
-The
-.Fn evTouchIdleTimer 
-function updates the idle timer associated with
-.Fa id ,
-setting its idea of the time it was last accessed to the value returned by
-.Fn evLastEventTime
-(described above) for the event context specified by
-.Fa opaqueCtx .
-This means that the idle timer will expire after at least
-.Fa max_idle
-time has passed since this (possibly new) time, providing a caller mechanism
-for resetting the call to the
-.Fa func
-associated with the idle timer.  (See the description of
-.Fn evSetIdleTimer ,
-above, for information about
-.Fa func
-and
-.Fa max_idle . )
-.Pp
-The
-.Fn evResetIdleTimer
-function reschedules a timer and resets the callback function and its argument.
-Note that resetting a timer also ``touches'' it.
-.Pp
-The
-.Fn evClearIdleTimer
-function unregisters the idle timer associated with
-.Fa id .
-See the discussion under
-.Fn evClearTimer , 
-above, for information regarding caller handling of the
-.Fa uap
-associated with the corresponding
-.Fn evSetIdleTimer
-call.
-.Pp
-The function
-.Fn evWaitFor
-places the function
-.Fa func
-on the given event context's wait queue with the associated (possibly
-.Dv NULL )
-.Dq Fa tag ;
-if 
-.Fa id
-is 
-.No non- Ns Dv NULL ,
-then it will contain the 
-.Dq wait \s-1ID\s+1 
-associated with the created queue element.
-.Pp
-The function
-.Fn evDo 
-marks 
-.Em all
-of the 
-.Dq waiting 
-functions in the given event context's wait queue with the associated (possibly
-.Dv NULL )
-.Dq Fa tag
-as runnable.  This places these functions in a
-.Dq done
-queue which will be read by
-.Fn evGetNext .
-.Pp
-The function
-.Fn evUnwait 
-will search for the
-.Dq wait \s-1ID\s+1 
-.Fa id
-in the wait queue of the given event context; if an element with the given
-.Fa id 
-is not found, then the
-.Dq done
-queue of that context is searched.  If found, the queue element is removed
-from the appropriate list.
-.Pp
-The function
-.Fn evDefer
-causes a function (specified as
-.Fa func ,
-with argument
-.Fa uap )
-to be dispatched at some later time.  Note that the
-.Fa tag
-argument to
-.Fa func
-will always be
-.Fa NULL
-when dispatched.
-.Pp
-The function
-.Fn evSelectFD
-registers a file I/O event for the file descriptor specified by
-.Fa fd .
-Bits in the
-.Fa eventmask
-argument are named
-.Fa EV_READ ,
-.Fa EV_WRITE ,
-and
-.Fa EV_EXCEPT .
-At least one of these bits must be specified.  If the
-.Fa id
-argument is not equal to
-.Fa NULL ,
-it will be used to store a unique ``file event \s-1ID\s+1'' for this event,
-which is useful in subsequent calls to
-.Fn evDeselectFD .
-A file descriptor will be made nonblocking using the
-.Fa O_NONBLOCK
-flag with
-.Xr fcntl 2
-on its first concurrent registration via
-.Fn evSelectFD .
-An
-.Fn evSelectFD
-remains in effect until cancelled via
-.Fn evDeselectFD .
-.Pp
-The function
-.Fn evDeselectFD
-unregisters the ``file event'' specified by the
-.Fa id
-argument.  If the corresponding
-.Fa uap
-uniquely points to dynamic memory, that memory should be freed before its
-handle is lost, since after a call to
-.Fn evDeselectFD ,
-no handles to this event's
-.Fa uap
-will remain within the event library.  A file descriptor will be taken out of
-nonblocking mode (see
-.Fa O_NONBLOCK
-and
-.Xr fcntl 2 )
-when its last event registration is removed via
-.Fn evDeselectFD ,
-if it was in blocking mode before the first registration via
-.Fn evSelectFD .
-.Pp
-The function
-.Fn evConsIovec
-is a constructor for a single
-.Ft struct iovec
-structure, which is useful for
-.Fn evWrite
-and
-.Fn evRead .
-.Pp
-The functions
-.Fn evWrite
-and
-.Fn evRead
-start asynchronous stream I/O operations on file descriptor
-.Fa fd .
-The data to be written or read is in the scatter/gather descriptor specified by
-.Fa iov
-and
-.Fa cnt .
-The supplied function
-.Fa func
-will be called with argument
-.Fa uap
-when the I/O operation is complete.  If
-.Fa id
-is not
-.Fa NULL ,
-it will be filled a with the stream event identifier suitable for use with
-.Fn evCancelRW .
-.Pp
-The function
-.Fn evCancelRW
-extinguishes an outstanding
-.Fn evWrite
-or
-.Fn evRead
-call.  System I/O calls cannot always be cancelled, but you are guaranteed
-that the
-.Fa func
-function supplied to
-.Fn evWrite
-or
-.Fn evRead
-will not be called after a call to
-.Fn evCancelRW .
-Care should be taken not to deallocate or otherwise reuse the space pointed
-to by the segment descriptors in
-.Fa iov
-unless the underlying file descriptor is closed first.
-.Pp
-The function
-.Fn evTimeRW
-sets the stream associated with the given stream \s-1ID\s+1 
-.Dq Fa id
-to have the idle timer associated with the timer \s-1ID\s+1 
-.Dq Fa timer .
-.Pp
-The function
-.Fn evUntimeRW
-says that the stream associated with the given stream \s-1ID\s+1
-.Dq Fa id
-should ignore its idle timer, if present.
-.Pp
-The functions
-.Fn evListen ,
-.Fn evConnect ,
-and
-.Fn evCancelConn
-can be used to manage asynchronous incoming and outgoing socket connections.
-Sockets to be used with these functions should first be created with
-.Xr socket 2
-and given a local name with
-.Xr bind 2 .
-It is extremely unlikely that the same socket will ever be
-useful for both incoming and outgoing connections.  The
-.Fa id
-argument to
-.Fn evListen
-and
-.Fn evConnect
-is either
-.Fa NULL
-or the address of a
-.Ft evFileID
-variable which can then be used in a subsequent call to
-.Fn evCancelConn .
-.Pp
-After a call to
-.Fn evListen ,
-each incoming connection arriving on
-.Fa fd
-will cause
-.Fa func
-to be called with
-.Fa uap
-as one of its arguments.
-.Fn evConnect
-initiates an outgoing connection on
-.Fa fd
-to destination address
-.Fa ra
-(whose length is
-.Fa ralen ) .
-When the connection is complete,
-.Fa func
-will be called with
-.Fa uap
-as one of its arguments.  The argument
-.Fa fd
-to
-.Fn \*(lp*func\*(rp
-will be
-.Fa -1
-if an error occurred that prevented this connection from completing 
-successfully.  In this case
-.Fn errno
-will have been set and the socket described by
-.Fa fd
-will have been closed.  The
-.Fn evCancelConn
-function will prevent delivery of all pending and subsequent
-events for the outstanding connection.  The
-.Fn evHold
-function will suspend the acceptance of new connections on the listener
-specified by
-.Fa id .
-Connections will be queued by the protocol stack up to the system's limit.  The
-.Fn evUnhold
-function will reverse the effects of
-.Fn evHold ,
-allowing incoming connections to be delivered for listener
-.Fa id .
-The
-.Fn evTryAccept
-function will poll the listener specified by
-.Fa id ,
-accepting a new connection if one is available, and queuing a connection event
-for later retrieval by
-.Fn evGetNext .
-If the connection event queued is an accept error(), sys_errno will contain
-the error code; otherwise it will be zero.  All connection events queued by
-.Fn evTryAccept
-will be delivered by
-.Fn evGetNext
-before a new select is done on the listener.
-.Pp
-The function
-.Fn evSetDebug
-sets the debugging
-.Fa level
-and diagnostic
-.Fa output
-file handle for an event context.  Greater numeric levels will
-result in more verbose output being sent to the output FILE during program
-execution.
-.Pp
-The function
-.Fn evPrintf
-prints a message with the format
-.Dq Fa fmt
-and the following arguments (if any), on the output stream associated
-with the event context pointed to by
-.Fa ctx .
-The message is output if the event context's debug level is greater than
-or equal to the indicated
-.Fa level .
-.Pp
-The function
-.Fn evInitID
-will initialize an opaque 
-.Dq evConn \s-1ID\s+1 , 
-.Dq evFile \s-1ID\s+1 , 
-.Dq evStream \s-1ID\s+1 , 
-.Dq evTimer \s-1ID\s+1 , 
-.Dq evWait \s-1ID\s+1 , 
-.Dq evContext , 
-or
-.Dq evEvent ,
-which is passed by reference to a state which
-.Fn evTestID
-will recognize.
-This is useful to make a handle as "not in use".
-.Pp
-The function
-.Fn evTestID
-will examine an opaque \s-1ID\s+1 and return
-.Dq TRUE
-only if it is not in its initialized state.
-.Pp
-The functions
-.Fn evGetOption
-and 
-.Fn evSetOption
-can be used to inspect and modify options.
-Currently there is only one option,  "monotime" and it is global for all 
-instances of eventlib so the ctx argument must be passed as NULL.
-.Pp
-The default value for the "monotime" option is zero which selects
-the UTC timescale.
-When set to a value of one, eventlib will use the
-CLOCK_MONOTONIC timescale from
-.Xr clock_gettime
-instead.
-The CLOCK_MONOTONIC timescale is never stepped and should
-run at a rate as close to TAI as possible, so it is unaffected
-when the system clock is set.
-If timerevents should run at a predictable rate, set the value
-to one, of they should run at a predictable time of day, leave
-it at zero.
-If the CLOCK_MONOTONIC timescale is not available on the system,
-attempts to set/get this option will fail.
-.Sh RETURN VALUES
-All the functions whose return type is
-.Dq Fa int
-use the standard convention of returning zero (0) to indicate success, or
-returning
-.Dq Fa -1
-and setting
-.Fa errno
-to indicate failure.
-.Sh FILE
-.Pa heap.h ,
-which is in the 
-.Pa src/lib/isc
-directory of the current 
-.Sy BIND
-distribution.
-.Sh ERRORS
-The possible values for
-.Fa errno
-when one of the
-.Dq Fa int
-functions in this library returns
-.Dq Fa -1
-include those of the Standard C Library and also:
-.Bl -tag -width EWOULDBLOCKAA
-.It Bq Er EINVAL
-Some function argument has an unreasonable value.
-.It Bq Er EINVAL
-The specified file descriptor has an integer value greater than the default
-.Fa FD_SETSIZE ,
-meaning that the application's limit is higher than the library's.
-.It Bq Er ENOENT
-The specified 
-.Dq event \s-1ID\s+1 
-does not exist.
-.It Bq Er EWOULDBLOCK
-No events have occurred and the
-.Fa EV_POLL
-option was specified.
-.It Bq Er EBADF
-The specified signal was unblocked outside the library.
-.El
-.Sh SEE ALSO
-.Xr gettimeofday 2 ,
-.Xr select 2 ,
-.Xr fcntl 3 ,
-.Xr malloc 3 ,
-.Xr @INDOT@named @SYS_OPS_EXT@ ,
-.Xr readv 3 ,
-.Xr writev 3 .
-.Sh BUGS
-This huge man page needs to be broken up into a handful of smaller ones.
-.Sh HISTORY
-The
-.Nm eventlib
-library was designed by Paul Vixie with excellent advice from his friends
-and with tips 'o the cap to the X Consortium and the implementors of DEC SRC
-Modula-3.
diff --git a/contrib/bind9/lib/bind/isc/eventlib_p.h b/contrib/bind9/lib/bind/isc/eventlib_p.h
deleted file mode 100644
index 5896553..0000000
--- a/contrib/bind9/lib/bind/isc/eventlib_p.h
+++ /dev/null
@@ -1,281 +0,0 @@
-/*
- * 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
- * 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 
- * \brief private interfaces for eventlib
- * \author vix 09sep95 [initial]
- *
- * $Id: eventlib_p.h,v 1.5.18.4 2006/03/10 00:20:08 marka Exp $
- */
-
-#ifndef _EVENTLIB_P_H
-#define _EVENTLIB_P_H
-
-#include <sys/param.h>
-#include <sys/types.h>
-#include <sys/socket.h>
-#include <netinet/in.h>
-#include <sys/un.h>
-
-#define EVENTLIB_DEBUG 1
-
-#include <errno.h>
-#include <fcntl.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-
-#include <isc/heap.h>
-#include <isc/list.h>
-#include <isc/memcluster.h>
-
-#define	EV_MASK_ALL	(EV_READ | EV_WRITE | EV_EXCEPT)
-#define EV_ERR(e)		return (errno = (e), -1)
-#define OK(x)		if ((x) < 0) EV_ERR(errno); else (void)NULL
-#define OKFREE(x, y)	if ((x) < 0) { FREE((y)); EV_ERR(errno); } \
-			else (void)NULL
-
-#define	NEW(p)		if (((p) = memget(sizeof *(p))) != NULL) \
-				FILL(p); \
-			else \
-				(void)NULL;
-#define OKNEW(p)	if (!((p) = memget(sizeof *(p)))) { \
-				errno = ENOMEM; \
-				return (-1); \
-			} else \
-				FILL(p)
-#define FREE(p)		memput((p), sizeof *(p))
-
-#if EVENTLIB_DEBUG
-#define FILL(p)		memset((p), 0xF5, sizeof *(p))
-#else
-#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;
-	int		fd;
-	int		flags;
-#define EV_CONN_LISTEN		0x0001		/*%< Connection is a listener. */
-#define EV_CONN_SELECTED	0x0002		/*%< evSelectFD(conn->file). */
-#define EV_CONN_BLOCK		0x0004		/*%< Listener fd was blocking. */
-	evFileID	file;
-	struct evConn *	prev;
-	struct evConn *	next;
-} evConn;
-
-typedef struct evAccept {
-	int		fd;
-	union {
-		struct sockaddr		sa;
-		struct sockaddr_in	in;
-#ifndef NO_SOCKADDR_UN
-		struct sockaddr_un	un;
-#endif
-	}		la;
-	ISC_SOCKLEN_T	lalen;
-	union {
-		struct sockaddr		sa;
-		struct sockaddr_in	in;
-#ifndef NO_SOCKADDR_UN
-		struct sockaddr_un	un;
-#endif
-	}		ra;
-	ISC_SOCKLEN_T	ralen;
-	int		ioErrno;
-	evConn *	conn;
-	LINK(struct evAccept) link;
-} evAccept;
-
-typedef struct evFile {
-	evFileFunc	func;
-	void *		uap;
-	int		fd;
-	int		eventmask;
-	int		preemptive;
-	struct evFile *	prev;
-	struct evFile *	next;
-	struct evFile *	fdprev;
-	struct evFile *	fdnext;
-} evFile;
-
-typedef struct evStream {
-	evStreamFunc	func;
-	void *		uap;
-	evFileID	file;
-	evTimerID	timer;
-	int		flags;
-#define EV_STR_TIMEROK	0x0001	/*%< IFF timer valid. */
-	int		fd;
-	struct iovec *	iovOrig;
-	int		iovOrigCount;
-	struct iovec *	iovCur;
-	int		iovCurCount;
-	int		ioTotal;
-	int		ioDone;
-	int		ioErrno;
-	struct evStream	*prevDone, *nextDone;
-	struct evStream	*prev, *next;
-} evStream;
-
-typedef struct evTimer {
-	evTimerFunc	func;
-	void *		uap;
-	struct timespec	due, inter;
-	int		index;
-	int		mode;
-#define EV_TMR_RATE	1
-} evTimer;
-
-typedef struct evWait {
-	evWaitFunc	func;
-	void *		uap;
-	const void *	tag;
-	struct evWait *	next;
-} evWait;
-
-typedef struct evWaitList {
-	evWait *		first;
-	evWait *		last;
-	struct evWaitList *	prev;
-	struct evWaitList *	next;
-} evWaitList;
-
-typedef struct evEvent_p {
-	enum {  Accept, File, Stream, Timer, Wait, Free, Null  } type;
-	union {
-		struct {  evAccept *this;  }			accept;
-		struct {  evFile *this; int eventmask;  }	file;
-		struct {  evStream *this;  }			stream;
-		struct {  evTimer *this;  }			timer;
-		struct {  evWait *this;  }			wait;
-		struct {  struct evEvent_p *next;  }		free;
-		struct {  const void *placeholder;  }		null;
-	} 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;
-	/* Debugging. */
-	int		debug;
-	FILE		*output;
-	/* Connections. */
-	evConn		*conns;
-	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;
-#endif
-	/* Streams. */
-	evStream	*streams;
-	evStream	*strDone, *strLast;
-	/* Timers. */
-	struct timespec	lastEventTime;
-	heap_context	timers;
-	/* Waits. */
-	evWaitList	*waitLists;
-	evWaitList	waitDone;
-} evContext_p;
-
-/* eventlib.c */
-#define evPrintf __evPrintf
-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 *);
-#define evDestroyTimers __evDestroyTimers
-void evDestroyTimers(const evContext_p *);
-
-/* ev_waits.c */
-#define evFreeWait __evFreeWait
-evWait *evFreeWait(evContext_p *ctx, evWait *old);
-
-/* Global options */
-extern int	__evOptMonoTime;
-
-#endif /*_EVENTLIB_P_H*/
diff --git a/contrib/bind9/lib/bind/isc/heap.c b/contrib/bind9/lib/bind/isc/heap.c
deleted file mode 100644
index bea7678..0000000
--- a/contrib/bind9/lib/bind/isc/heap.c
+++ /dev/null
@@ -1,236 +0,0 @@
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-/*%
- * Heap implementation of priority queues adapted from the following:
- *
- *	_Introduction to Algorithms_, Cormen, Leiserson, and Rivest,
- *	MIT Press / McGraw Hill, 1990, ISBN 0-262-03141-8, chapter 7.
- *
- *	_Algorithms_, Second Edition, Sedgewick, Addison-Wesley, 1988,
- *	ISBN 0-201-06673-4, chapter 11.
- */
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: heap.c,v 1.2.18.2 2006/03/10 00:20:08 marka Exp $";
-#endif /* not lint */
-
-#include "port_before.h"
-
-#include <stddef.h>
-#include <stdlib.h>
-#include <errno.h>
-
-#include "port_after.h"
-
-#include <isc/heap.h>
-
-/*%
- * Note: to make heap_parent and heap_left easy to compute, the first
- * element of the heap array is not used; i.e. heap subscripts are 1-based,
- * not 0-based.
- */
-#define heap_parent(i) ((i) >> 1)
-#define heap_left(i) ((i) << 1)
-
-#define ARRAY_SIZE_INCREMENT 512
-
-heap_context
-heap_new(heap_higher_priority_func higher_priority, heap_index_func index,
-	 int array_size_increment) {
-	heap_context ctx;
-
-	if (higher_priority == NULL)
-		return (NULL);
-
-	ctx = (heap_context)malloc(sizeof (struct heap_context));
-	if (ctx == NULL)
-		return (NULL);
-
-	ctx->array_size = 0;
-	if (array_size_increment == 0)
-		ctx->array_size_increment = ARRAY_SIZE_INCREMENT;
-	else
-		ctx->array_size_increment = array_size_increment;
-	ctx->heap_size = 0;
-	ctx->heap = NULL;
-	ctx->higher_priority = higher_priority;
-	ctx->index = index;
-	return (ctx);
-}
-
-int
-heap_free(heap_context ctx) {
-	if (ctx == NULL) {
-		errno = EINVAL;
-		return (-1);
-	}
-
-	if (ctx->heap != NULL)
-		free(ctx->heap);
-	free(ctx);
-
-	return (0);
-}
-
-static int
-heap_resize(heap_context ctx) {
-	void **new_heap;
-
-	ctx->array_size += ctx->array_size_increment;
-	new_heap = (void **)realloc(ctx->heap,
-				    (ctx->array_size) * (sizeof (void *)));
-	if (new_heap == NULL) {
-		errno = ENOMEM;
-		return (-1);
-	}
-	ctx->heap = new_heap;
-	return (0);
-}
-
-static void
-float_up(heap_context ctx, int i, void *elt) {
-	int p;
-
-	for ( p = heap_parent(i); 
-	      i > 1 && ctx->higher_priority(elt, ctx->heap[p]);
-	      i = p, p = heap_parent(i) ) {
-		ctx->heap[i] = ctx->heap[p];
-		if (ctx->index != NULL)
-			(ctx->index)(ctx->heap[i], i);
-	}
-	ctx->heap[i] = elt;
-	if (ctx->index != NULL)
-		(ctx->index)(ctx->heap[i], i);
-}
-
-static void
-sink_down(heap_context ctx, int i, void *elt) {
-	int j, size, half_size;
-
-	size = ctx->heap_size;
-	half_size = size / 2;
-	while (i <= half_size) {
-		/* find smallest of the (at most) two children */
-		j = heap_left(i);
-		if (j < size && ctx->higher_priority(ctx->heap[j+1],
-						     ctx->heap[j]))
-			j++;
-		if (ctx->higher_priority(elt, ctx->heap[j]))
-			break;
-		ctx->heap[i] = ctx->heap[j];
-		if (ctx->index != NULL)
-			(ctx->index)(ctx->heap[i], i);
-		i = j;
-	}
-	ctx->heap[i] = elt;
-	if (ctx->index != NULL)
-		(ctx->index)(ctx->heap[i], i);
-}
-
-int
-heap_insert(heap_context ctx, void *elt) {
-	int i;
-
-	if (ctx == NULL || elt == NULL) {
-		errno = EINVAL;
-		return (-1);
-	}
-
-	i = ++ctx->heap_size;
-	if (ctx->heap_size >= ctx->array_size && heap_resize(ctx) < 0)
-		return (-1);
-	
-	float_up(ctx, i, elt);
-
-	return (0);
-}
-
-int
-heap_delete(heap_context ctx, int i) {
-	void *elt;
-	int less;
-
-	if (ctx == NULL || i < 1 || i > ctx->heap_size) {
-		errno = EINVAL;
-		return (-1);
-	}
-
-	if (i == ctx->heap_size) {
-		ctx->heap_size--;
-	} else {
-		elt = ctx->heap[ctx->heap_size--];
-		less = ctx->higher_priority(elt, ctx->heap[i]);
-		ctx->heap[i] = elt;
-		if (less)
-			float_up(ctx, i, ctx->heap[i]);
-		else
-			sink_down(ctx, i, ctx->heap[i]);
-	}
-
-	return (0);
-}
-
-int
-heap_increased(heap_context ctx, int i) {
-     	if (ctx == NULL || i < 1 || i > ctx->heap_size) {
-		errno = EINVAL;
-		return (-1);
-	}
-	
-	float_up(ctx, i, ctx->heap[i]);
-
-	return (0);
-}
-
-int
-heap_decreased(heap_context ctx, int i) {
-     	if (ctx == NULL || i < 1 || i > ctx->heap_size) {
-		errno = EINVAL;
-		return (-1);
-	}
-	
-	sink_down(ctx, i, ctx->heap[i]);
-
-	return (0);
-}
-
-void *
-heap_element(heap_context ctx, int i) {
-	if (ctx == NULL || i < 1 || i > ctx->heap_size) {
-		errno = EINVAL;
-		return (NULL);
-	}
-
-	return (ctx->heap[i]);
-}
-
-int
-heap_for_each(heap_context ctx, heap_for_each_func action, void *uap) {
-	int i;
-
-	if (ctx == NULL || action == NULL) {
-		errno = EINVAL;
-		return (-1);
-	}
-
-	for (i = 1; i <= ctx->heap_size; i++)
-		(action)(ctx->heap[i], uap);
-	return (0);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/isc/heap.mdoc b/contrib/bind9/lib/bind/isc/heap.mdoc
deleted file mode 100644
index 332a6ec..0000000
--- a/contrib/bind9/lib/bind/isc/heap.mdoc
+++ /dev/null
@@ -1,378 +0,0 @@
-.\" $Id: heap.mdoc,v 1.3 2004/03/09 06:30:08 marka Exp $
-.\"
-.\" Copyright (c) 2004 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
-.\" 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.
-.\"
-.Dd January 1, 1997
-.\"Os OPERATING_SYSTEM [version/release]
-.Os BSD 4
-.Dt HEAP @SYSCALL_EXT@
-.Sh NAME
-.Nm heap_new ,
-.Nm heap_free ,
-.Nm heap_insert ,
-.Nm heap_delete ,
-.Nm heap_increased ,
-.Nm heap_decreased ,
-.Nm heap_element ,
-.Nm heap_for_each 
-.Nd heap implementation of priority queues
-.Sh SYNOPSIS
-.Fd #include \&"heap.h\&"
-.Ft heap_context    
-.Fn heap_new "heap_higher_priority_func higher_priority" \
-"heap_index_func index" "int array_size_increment"
-.Ft int
-.Fn heap_free "heap_context ctx"
-.Ft int
-.Fn heap_insert "heap_context ctx" "void *elt"
-.Ft int
-.Fn heap_delete "heap_context ctx" "int i"
-.Ft int
-.Fn heap_increased "heap_context ctx" "int i"
-.Ft int
-.Fn heap_decreased "heap_context ctx" "int i"
-.Ft void *
-.Fn heap_element "heap_context ctx" "int i"
-.Ft int 
-.Fn heap_for_each "heap_context ctx" "heap_for_each_func action" "void *uap"
-.Sh DESCRIPTION
-These functions implement heap\-based priority queues.  The user defines a
-priority scheme, and provides a function for comparison of the priority
-of heap elements
-(see the description of the
-.Ft heap_higher_priority_func
-function pointer, below).
-.Pp
-Each of the functions depends upon the
-.Ft heap_context
-type, which is a pointer to a
-.Ft struct heap_context 
-.Pq see Pa heap.h No for more information .
-.Pp
-The
-.Pa heap.h
-header file also defines the following set of function
-function pointers:
-.Bd -literal -offset indent
-typedef int (*heap_higher_priority_func)(void *, void *);
-typedef void (*heap_index_func)(void *, int);
-typedef void (*heap_for_each_func)(void *, void *);
-.Ed
-.Pp
-These are pointers to user-defined functions.
-The 
-.Ft heap_higher_priority_func
-type is a pointer to a function which compares two
-different heap (queue) elements and returns an
-.Ft int
-which answers the question, "Does the first queue element 
-have a higher priority than the second?"  In other words, 
-a function pointer of this type 
-.Em must 
-return a number greater than zero
-if the element indicated by the first argument is of a higher priority than 
-that indicated by the second element, and zero otherwise.  
-.Pp
-The other two function pointers are documented in the descriptions
-of 
-.Fn heap_new
-.Pq Va heap_index_func
-and
-.Fn heap_for_each
-.Pq Va heap_for_each_func ,
-below.
-.Pp
-The function
-.Fn heap_new
-initializes a 
-.Ft struct heap_context
-and returns a pointer to it.  The
-.Fa higher_priority
-function pointer 
-.Em must 
-be 
-.No non\- Ns Dv NULL .
-As explained above, this refers to a 
-function supplied by the user which compares the priority of two different
-queue or heap elements; see above for more information. 
-The second argument, 
-.Fa index ,
-is a pointer to a user-defined function whose arguments are
-a heap element and its index in the heap.
-.Fa Index 
-is intended to provide the user a means of knowing the internal index
-of an element in the heap while maintaining the opacity of the implementation;
-since the user has to know the actual indexes of heap elements in order to use,
-e.g., 
-.Fn heap_delete
-or
-.Fn heap_element ,
-the user 
-.Fa index
-function could store the index in the heap element, itself.  If 
-.Fa index
-is 
-.No non\- Ns Dv NULL ,
-then it is called 
-.Em whenever 
-the index of an element changes, allowing the user to stay up\-to\-date
-with index changes.
-The last argument, 
-.Fa array_size_increment
-will be used, as its name suggests, by
-.Xr malloc 3
-or
-.Xr realloc 3
-to increment the array which implements the heap; if zero, a default value 
-will be used.
-.Pp
-The
-.Fn heap_free
-function frees the given
-.Ft heap_context
-argument 
-.Pq Fa ctx ,
-which also frees the entire
-.Nm heap ,
-if it is
-.No non\- Ns Dv NULL .
-The argument
-.Fa ctx
-should be
-.No non\- Ns Dv NULL .
-.Pp
-The 
-.Fn heap_insert
-function is used to insert the new heap element
-.Fa elt
-into the appropriate place (priority\-wise) in the
-.Ft heap
-indicated by 
-.Fa ctx
-(a pointer to a
-.Ft heap_context ) .
-If 
-.No non\- Ns Dv NULL ,
-the user-defined
-.Ft higher_priority
-function pointer associated with the indicated 
-.Nm heap
-is used to determine that
-.Dq appropriate place ;
-the highest\-priority elements are at the front of the queue (top of
-the heap).
-(See the description of 
-.Fn heap_new , 
-above, for more information.)
-.Pp
-The function
-.Fn heap_delete
-is used to delete the 
-.Fa i\- Ns th
-element of the queue (heap), and fixing up the queue (heap) from that
-element onward via the priority as determined by the user function
-pointed to by
-.Ft higher_priority 
-function pointer
-(see description of
-.Fn heap_new ,
-above).
-.Pp
-.Fn heap_increased
-.Pp
-.Fn heap_decreased
-.Pp
-The 
-.Fn heap_element
-function returns the
-.Fa i\- Ns th
-element of the queue/heap indicated by
-.Fa ctx ,
-if possible.
-.Pp
-The
-.Fn heap_for_each
-function provides a mechanism for the user to increment through the entire
-queue (heap) and perform some
-.Fa action 
-upon each of the queue elements.  This
-.Fa action 
-is pointer to a user\-defined function with two arguments, the first of
-which should be interpreted by the user's function as a heap element.  The 
-second value passed to the user function is just the
-.Fa uap
-argument to 
-.Fn heap_for_each ;
-this allows the user to specify additional arguments, if necessary, to
-the function pointed to by 
-.Fa action .
-.\" The following requests should be uncommented and
-.\" used where appropriate.  This next request is
-.\" for sections 2 and 3 function return values only.
-.Sh RETURN VALUES
-.Bl -tag -width "heap_decreased()"
-.It Fn heap_new
-.Dv NULL
-if unable to 
-.Xr malloc 3
-a 
-.Ft struct heap_context
-or if the
-.Fa higher_priority
-function pointer is 
-.Dv NULL ;
-otherwise, a valid
-.Ft heap_context 
-.Ns .
-.It Fn heap_free
--1 if 
-.Fa ctx
-is 
-.Dv NULL 
-(with 
-.Va errno
-set to
-.Dv EINVAL ) ;
-otherwise, 0.
-.It Fn heap_insert
--1 
-if either
-.Fa ctx
-or 
-.Fa elt
-is 
-.Dv NULL ,
-or if an attempt to 
-.Xr malloc 3
-or 
-.Xr realloc 3
-the heap array fails (with
-.Va errno
-set to 
-.Dv EINVAL
-or 
-.Dv ENOMEM ,
-respectively).
-Otherwise, 0.
-.It Fn heap_delete
--1 if 
-.Fa ctx
-is 
-.Dv NULL
-or 
-.Fa i 
-is out\-of\-range (with
-.Va errno
-set to
-.Dv EINVAL ) ;
-0 otherwise.
-.It Fn heap_increased
-As for
-.Fn heap_delete .
-.It Fn heap_decreased
-As for
-.Fn heap_delete .
-.It Fn heap_element
-NULL if 
-.Fa ctx 
-is 
-.Dv NULL
-or
-.Fa i
-out\-of-bounds (with
-.Va errno
-set to
-.Dv EINVAL ) ;
-otherwise, a pointer to the
-.Fa i\- Ns th
-queue element.
-.It Fn heap_for_each
--1 if either
-.Fa ctx
-or 
-.Fa action
-is 
-.Dv NULL
-(with 
-.Va errno
-set to
-.Dv EINVAL ) ;
-0 otherwise.
-.El
-.\" This next request is for sections 1, 6, 7 & 8 only
-.\" .Sh ENVIRONMENT
-.Sh FILES
-.Bl -tag -width "heap.h000"
-.It Pa heap.h
- heap library header file
-.El
-.\" .Sh EXAMPLES
-.\" This next request is for sections 1, 6, 7 & 8 only
-.\"     (command return values (to shell) and
-.\"    fprintf/stderr type diagnostics)
-.Sh DIAGNOSTICS
-Please refer to
-.Sx RETURN VALUES .
-.\" The next request is for sections 2 and 3 error
-.\" and signal handling only.
-.Sh ERRORS
-The variable
-.Va errno
-is set by
-.Fn heap_free , 
-.Fn heap_insert , 
-.Fn heap_delete , 
-.Fn heap_increased , 
-and
-.Fn heap_decreased 
-under the conditions of invalid input
-.Pq Dv EINVAL
-or lack of memory
-.Pq Dv ENOMEM ;
-please refer to
-.Sx RETURN VALUES .
-.Sh SEE ALSO
-.Xr malloc 3 ,
-.Xr realloc 3 .
-.Rs
-.%A Cormen
-.%A Leiserson
-.%A Rivest
-.%B Introduction to Algorithms
-.%Q "MIT Press / McGraw Hill"
-.%D 1990
-.%O ISBN 0\-262\-03141\-8
-.%P chapter 7
-.Re
-.Rs
-.%A Sedgewick
-.%B Algorithms, 2nd ed'n
-.%Q Addison\-Wesley
-.%D 1988
-.%O ISBN 0\-201\-06673\-4
-.%P chapter 11
-.Re
-.\" .Sh STANDARDS
-.\" .Sh HISTORY
-.Sh AUTHORS
-The
-.Nm heap
-library was implemented by Bob Halley (halley@vix.com) of Vixie Enterprises, 
-Inc., for the Internet Software consortium, and was adapted from
-the two books listed in the 
-.Sx SEE ALSO
-section, above.
-.\" .Sh BUGS
diff --git a/contrib/bind9/lib/bind/isc/hex.c b/contrib/bind9/lib/bind/isc/hex.c
deleted file mode 100644
index e43be4f..0000000
--- a/contrib/bind9/lib/bind/isc/hex.c
+++ /dev/null
@@ -1,119 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 2001 by 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.
- */
-
-#include <port_before.h>
-#include <ctype.h>
-#include <stdio.h>
-#include <string.h>
-#include <isc/misc.h>
-#include <port_after.h>
-
-static const char hex[17] = "0123456789abcdef";
-
-int
-isc_gethexstring(unsigned char *buf, size_t len, int count, FILE *fp,
-		 int *multiline)
-{
-	int c, n;
-	unsigned char x;
-	char *s;
-	int result = count;
-	
-	x = 0; /*%< silence compiler */
-	n = 0;
-	while (count > 0) {
-		c = fgetc(fp);
-
-		if ((c == EOF) ||
-		    (c == '\n' && !*multiline) ||
-		    (c == '(' && *multiline) ||
-		    (c == ')' && !*multiline))
-			goto formerr;
-		/* comment */
-		if (c == ';') {
-			do {
-				c = fgetc(fp);
-			} while (c != EOF && c != '\n');
-			if (c == '\n' && *multiline)
-				continue;
-			goto formerr;
-		}
-		/* white space */
-		if (c == ' ' || c == '\t' || c == '\n' || c == '\r')
-			continue;
-		/* multiline */
-		if ('(' == c || c == ')') {
-			*multiline = (c == '(' /*)*/);
-			continue;
-		}
-		if ((s = strchr(hex, tolower(c))) == NULL)
-			goto formerr;
-		x = (x<<4) | (s - hex);
-		if (++n == 2) {
-			if (len > 0U) {
-				*buf++ = x;
-				len--;
-			} else
-				result = -1;
-			count--;
-			n = 0;
-		}
-	}
-	return (result);
-
- formerr:
-	if (c == '\n')
-		ungetc(c, fp);
-	return (-1);
-}
-
-void
-isc_puthexstring(FILE *fp, const unsigned char *buf, size_t buflen,
-		 size_t len1, size_t len2, const char *sep)
-{
-	size_t i = 0;
-
-	if (len1 < 4U)
-		len1 = 4;
-	if (len2 < 4U)
-		len2 = 4;
-	while (buflen > 0U) {
-		fputc(hex[(buf[0]>>4)&0xf], fp);
-		fputc(hex[buf[0]&0xf], fp);
-		i += 2;
-		buflen--;
-		buf++;
-		if (i >= len1 && sep != NULL) {
-			fputs(sep, fp);
-			i = 0;
-			len1 = len2;
-		}
-	}
-}
-
-void
-isc_tohex(const unsigned char *buf, size_t buflen, char *t) {
-	while (buflen > 0U) {
-		*t++ = hex[(buf[0]>>4)&0xf];
-		*t++ = hex[buf[0]&0xf];
-		buf++;
-		buflen--;
-	}
-	*t = '\0';
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/isc/logging.c b/contrib/bind9/lib/bind/isc/logging.c
deleted file mode 100644
index 0cabc4d..0000000
--- a/contrib/bind9/lib/bind/isc/logging.c
+++ /dev/null
@@ -1,716 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996-1999 by 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.
- */
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: logging.c,v 1.6.18.2 2008/02/28 05:49:37 marka Exp $";
-#endif /* not lint */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/time.h>
-#include <sys/stat.h>
-
-#include <fcntl.h>
-#include <limits.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <stdarg.h>
-#include <syslog.h>
-#include <errno.h>
-#include <time.h>
-#include <unistd.h>
-
-#include <isc/assertions.h>
-#include <isc/logging.h>
-#include <isc/memcluster.h>
-#include <isc/misc.h>
-
-#include "port_after.h"
-
-#include "logging_p.h"
-
-static const int syslog_priority[] = { LOG_DEBUG, LOG_INFO, LOG_NOTICE,
-				       LOG_WARNING, LOG_ERR, LOG_CRIT };
-
-static const char *months[] = { "Jan", "Feb", "Mar", "Apr", "May", "Jun",
-				"Jul", "Aug", "Sep", "Oct", "Nov", "Dec" };
-
-static const char *level_text[] = {
-	"info: ", "notice: ", "warning: ", "error: ", "critical: "
-};
-
-static void
-version_rename(log_channel chan) {
-	unsigned int ver;
-	char old_name[PATH_MAX+1];
-	char new_name[PATH_MAX+1];
-	
-	ver = chan->out.file.versions;
-	if (ver < 1)
-		return;
-	if (ver > LOG_MAX_VERSIONS)
-		ver = LOG_MAX_VERSIONS;
-	/*
-	 * Need to have room for '.nn' (XXX assumes LOG_MAX_VERSIONS < 100)
-	 */
-	if (strlen(chan->out.file.name) > (size_t)(PATH_MAX-3))
-		return;
-	for (ver--; ver > 0; ver--) {
-		sprintf(old_name, "%s.%d", chan->out.file.name, ver-1);
-		sprintf(new_name, "%s.%d", chan->out.file.name, ver);
-		(void)isc_movefile(old_name, new_name);
-	}
-	sprintf(new_name, "%s.0", chan->out.file.name);
-	(void)isc_movefile(chan->out.file.name, new_name);
-}
-
-FILE *
-log_open_stream(log_channel chan) {
-	FILE *stream;
-	int fd, flags;
-	struct stat sb;
-	int regular;
-
-	if (chan == NULL || chan->type != log_file) {
-		errno = EINVAL;
-		return (NULL);
-	}
-	
-	/*
-	 * Don't open already open streams
-	 */
-	if (chan->out.file.stream != NULL)
-		return (chan->out.file.stream);
-
-	if (stat(chan->out.file.name, &sb) < 0) {
-		if (errno != ENOENT) {
-			syslog(LOG_ERR,
-			       "log_open_stream: stat of %s failed: %s",
-			       chan->out.file.name, strerror(errno));
-			chan->flags |= LOG_CHANNEL_BROKEN;
-			return (NULL);
-		}
-		regular = 1;
-	} else
-		regular = (sb.st_mode & S_IFREG);
-
-	if (chan->out.file.versions) {
-		if (!regular) {
-			syslog(LOG_ERR,
-       "log_open_stream: want versions but %s isn't a regular file",
-			       chan->out.file.name);
-			chan->flags |= LOG_CHANNEL_BROKEN;
-			errno = EINVAL;
-			return (NULL);
-		}
-	}
-
-	flags = O_WRONLY|O_CREAT|O_APPEND;
-
-	if ((chan->flags & LOG_TRUNCATE) != 0) {
-		if (regular) {
-			(void)unlink(chan->out.file.name);
-			flags |= O_EXCL;
-		} else {
-			syslog(LOG_ERR,
-       "log_open_stream: want truncation but %s isn't a regular file",
-			       chan->out.file.name);
-			chan->flags |= LOG_CHANNEL_BROKEN;
-			errno = EINVAL;
-			return (NULL);
-		}
-	}
-
-	fd = open(chan->out.file.name, flags,
-		  S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH);
-	if (fd < 0) {
-		syslog(LOG_ERR, "log_open_stream: open(%s) failed: %s",
-		       chan->out.file.name, strerror(errno));
-		chan->flags |= LOG_CHANNEL_BROKEN;
-		return (NULL);
-	}
-	stream = fdopen(fd, "a");
-	if (stream == NULL) {
-		syslog(LOG_ERR, "log_open_stream: fdopen() failed");
-		chan->flags |= LOG_CHANNEL_BROKEN;
-		return (NULL);
-	}
-	(void) fchown(fd, chan->out.file.owner, chan->out.file.group);
-
-	chan->out.file.stream = stream;
-	return (stream);
-}
-
-int
-log_close_stream(log_channel chan) {
-	FILE *stream;
-
-	if (chan == NULL || chan->type != log_file) {
-		errno = EINVAL;
-		return (0);
-	}
-	stream = chan->out.file.stream;
-	chan->out.file.stream = NULL;
-	if (stream != NULL && fclose(stream) == EOF)
-		return (-1);
-	return (0);
-}
-
-void
-log_close_debug_channels(log_context lc) {
-	log_channel_list lcl;
-	int i;
-
-	for (i = 0; i < lc->num_categories; i++)
-		for (lcl = lc->categories[i]; lcl != NULL; lcl = lcl->next)
-			if (lcl->channel->type == log_file &&
-			    lcl->channel->out.file.stream != NULL &&
-			    lcl->channel->flags & LOG_REQUIRE_DEBUG)
-				(void)log_close_stream(lcl->channel);
-}
-
-FILE *
-log_get_stream(log_channel chan) {
-	if (chan == NULL || chan->type != log_file) {
-		errno = EINVAL;
-		return (NULL);
-	}
-	return (chan->out.file.stream);
-}
-
-char *
-log_get_filename(log_channel chan) {
-	if (chan == NULL || chan->type != log_file) {
-		errno = EINVAL;
-		return (NULL);
-	}
-	return (chan->out.file.name);
-}
-
-int
-log_check_channel(log_context lc, int level, log_channel chan) {
-	int debugging, chan_level;
-
-	REQUIRE(lc != NULL);
-
-	debugging = ((lc->flags & LOG_OPTION_DEBUG) != 0);
-
-	/*
-	 * If not debugging, short circuit debugging messages very early.
-	 */
-	if (level > 0 && !debugging)
-		return (0);
-
-	if ((chan->flags & (LOG_CHANNEL_BROKEN|LOG_CHANNEL_OFF)) != 0)
-		return (0);
-
-	/* Some channels only log when debugging is on. */
-	if ((chan->flags & LOG_REQUIRE_DEBUG) && !debugging)
-		return (0);
-
-	/* Some channels use the global level. */
-	if ((chan->flags & LOG_USE_CONTEXT_LEVEL) != 0) {
-		chan_level = lc->level;
-	} else
-		chan_level = chan->level;
-
-	if (level > chan_level)
-		return (0);
-
-	return (1);
-}
-
-int 
-log_check(log_context lc, int category, int level) {
-	log_channel_list lcl;
-	int debugging;
-
-	REQUIRE(lc != NULL);
-
-	debugging = ((lc->flags & LOG_OPTION_DEBUG) != 0);
-
-	/*
-	 * If not debugging, short circuit debugging messages very early.
-	 */
-	if (level > 0 && !debugging)
-		return (0);
-
-	if (category < 0 || category > lc->num_categories)
-		category = 0;		/*%< use default */
-	lcl = lc->categories[category];
-	if (lcl == NULL) {
-		category = 0;
-		lcl = lc->categories[0];
-	}
-
-	for ( /* nothing */; lcl != NULL; lcl = lcl->next) {
-		if (log_check_channel(lc, level, lcl->channel))
-			return (1);
-	}
-	return (0);
-}
-
-void
-log_vwrite(log_context lc, int category, int level, const char *format, 
-	   va_list args) {
-	log_channel_list lcl;
-	int pri, debugging, did_vsprintf = 0;
-	int original_category;
-	FILE *stream;
-	log_channel chan;
-	struct timeval tv;
-	struct tm *local_tm;
-#ifdef HAVE_TIME_R
-	struct tm tm_tmp;
-#endif
-	time_t tt;
-	const char *category_name;
-	const char *level_str;
-	char time_buf[256];
-	char level_buf[256];
-
-	REQUIRE(lc != NULL);
-
-	debugging = (lc->flags & LOG_OPTION_DEBUG);
-
-	/*
-	 * If not debugging, short circuit debugging messages very early.
-	 */
-	if (level > 0 && !debugging)
-		return;
-
-	if (category < 0 || category > lc->num_categories)
-		category = 0;		/*%< use default */
-	original_category = category;
-	lcl = lc->categories[category];
-	if (lcl == NULL) {
-		category = 0;
-		lcl = lc->categories[0];
-	}
-
-	/*
-	 * Get the current time and format it.
-	 */
-	time_buf[0]='\0';
-	if (gettimeofday(&tv, NULL) < 0) {
-		syslog(LOG_INFO, "gettimeofday failed in log_vwrite()");
-	} else {
-		tt = tv.tv_sec;
-#ifdef HAVE_TIME_R
-		local_tm = localtime_r(&tt, &tm_tmp);
-#else
-		local_tm = localtime(&tt);
-#endif
-		if (local_tm != NULL) {
-			sprintf(time_buf, "%02d-%s-%4d %02d:%02d:%02d.%03ld ",
-				local_tm->tm_mday, months[local_tm->tm_mon],
-				local_tm->tm_year+1900, local_tm->tm_hour,
-				local_tm->tm_min, local_tm->tm_sec,
-				(long)tv.tv_usec/1000);
-		}
-	}
-
-	/*
-	 * Make a string representation of the current category and level
-	 */
-
-	if (lc->category_names != NULL &&
-	    lc->category_names[original_category] != NULL)
-		category_name = lc->category_names[original_category];
-	else
-		category_name = "";
-
-	if (level >= log_critical) {
-		if (level >= 0) {
-			sprintf(level_buf, "debug %d: ", level);
-			level_str = level_buf;
-		} else
-			level_str = level_text[-level-1];
-	} else {
-		sprintf(level_buf, "level %d: ", level);
-		level_str = level_buf;
-	}
-
-	/*
-	 * Write the message to channels.
-	 */
-	for ( /* nothing */; lcl != NULL; lcl = lcl->next) {
-		chan = lcl->channel;
-
-		if (!log_check_channel(lc, level, chan))
-			continue;
-
-		if (!did_vsprintf) {
-			(void)vsprintf(lc->buffer, format, args);
-			if (strlen(lc->buffer) > (size_t)LOG_BUFFER_SIZE) {
-				syslog(LOG_CRIT,
-				       "memory overrun in log_vwrite()");
-				exit(1);
-			}
-			did_vsprintf = 1;
-		}
-
-		switch (chan->type) {
-		case log_syslog:
-			if (level >= log_critical)
-				pri = (level >= 0) ? 0 : -level;
-			else
-				pri = -log_critical;
-			syslog(chan->out.facility|syslog_priority[pri],
-			       "%s%s%s%s",
-			       (chan->flags & LOG_TIMESTAMP) ?	time_buf : "",
-			       (chan->flags & LOG_PRINT_CATEGORY) ?
-			       category_name : "",
-			       (chan->flags & LOG_PRINT_LEVEL) ?
-			       level_str : "",
-			       lc->buffer);
-			break;
-		case log_file:
-			stream = chan->out.file.stream;
-			if (stream == NULL) {
-				stream = log_open_stream(chan);
-				if (stream == NULL)
-					break;
-			}
-			if (chan->out.file.max_size != ULONG_MAX) {
-				long pos;
-				
-				pos = ftell(stream);
-				if (pos >= 0 &&
-				    (unsigned long)pos >
-				    chan->out.file.max_size) {
-					/*
-					 * try to roll over the log files,
-					 * ignoring all all return codes
-					 * except the open (we don't want
-					 * to write any more anyway)
-					 */
-					log_close_stream(chan);
-					version_rename(chan);
-					stream = log_open_stream(chan);
-					if (stream == NULL)
-						break;
-				}
-			}
-			fprintf(stream, "%s%s%s%s\n", 
-				(chan->flags & LOG_TIMESTAMP) ?	time_buf : "",
-				(chan->flags & LOG_PRINT_CATEGORY) ?
-				category_name : "",
-				(chan->flags & LOG_PRINT_LEVEL) ?
-				level_str : "",
-				lc->buffer);
-			fflush(stream);
-			break;
-		case log_null:
-			break;
-		default:
-			syslog(LOG_ERR,
-			       "unknown channel type in log_vwrite()");
-		}
-	}
-}
-
-void
-log_write(log_context lc, int category, int level, const char *format, ...) {
-	va_list args;
-
-	va_start(args, format);
-	log_vwrite(lc, category, level, format, args);
-	va_end(args);
-}
-
-/*%
- * Functions to create, set, or destroy contexts
- */
-
-int
-log_new_context(int num_categories, char **category_names, log_context *lc) {
-	log_context nlc;
-
-	nlc = memget(sizeof (struct log_context));
-	if (nlc == NULL) {
-		errno = ENOMEM;
-		return (-1);
-	}
-	nlc->num_categories = num_categories;
-	nlc->category_names = category_names;
-	nlc->categories = memget(num_categories * sizeof (log_channel_list));
-	if (nlc->categories == NULL) {
-		memput(nlc, sizeof (struct log_context));
-		errno = ENOMEM;
-		return (-1);
-	}
-	memset(nlc->categories, '\0',
-	       num_categories * sizeof (log_channel_list));
-	nlc->flags = 0U;
-	nlc->level = 0;
-	*lc = nlc;
-	return (0);
-}
-
-void
-log_free_context(log_context lc) {
-	log_channel_list lcl, lcl_next;
-	log_channel chan;
-	int i;
-
-	REQUIRE(lc != NULL);
-
-	for (i = 0; i < lc->num_categories; i++)
-		for (lcl = lc->categories[i]; lcl != NULL; lcl = lcl_next) {
-			lcl_next = lcl->next;
-			chan = lcl->channel;
-			(void)log_free_channel(chan);
-			memput(lcl, sizeof (struct log_channel_list));
-		}
-	memput(lc->categories,
-	       lc->num_categories * sizeof (log_channel_list));
-	memput(lc, sizeof (struct log_context));
-}
-
-int
-log_add_channel(log_context lc, int category, log_channel chan) {
-	log_channel_list lcl;
-
-	if (lc == NULL || category < 0 || category >= lc->num_categories) {
-		errno = EINVAL;
-		return (-1);
-	}
-
-	lcl = memget(sizeof (struct log_channel_list));
-	if (lcl == NULL) {
-		errno = ENOMEM;
-		return(-1);
-	}
-	lcl->channel = chan;
-	lcl->next = lc->categories[category];
-	lc->categories[category] = lcl;
-	chan->references++;
-	return (0);
-}
-
-int
-log_remove_channel(log_context lc, int category, log_channel chan) {
-	log_channel_list lcl, prev_lcl, next_lcl;
-	int found = 0;
-
-	if (lc == NULL || category < 0 || category >= lc->num_categories) {
-		errno = EINVAL;
-		return (-1);
-	}
-
-	for (prev_lcl = NULL, lcl = lc->categories[category];
-	     lcl != NULL;
-	     lcl = next_lcl) {
-		next_lcl = lcl->next;
-		if (lcl->channel == chan) {
-			log_free_channel(chan);
-			if (prev_lcl != NULL)
-				prev_lcl->next = next_lcl;
-			else
-				lc->categories[category] = next_lcl;
-			memput(lcl, sizeof (struct log_channel_list));
-			/*
-			 * We just set found instead of returning because
-			 * the channel might be on the list more than once.
-			 */
-			found = 1;
-		} else
-			prev_lcl = lcl;
-	}
-	if (!found) {
-		errno = ENOENT;
-		return (-1);
-	}
-	return (0);
-}
-
-int
-log_option(log_context lc, int option, int value) {
-	if (lc == NULL) {
-		errno = EINVAL;
-		return (-1);
-	}
-	switch (option) {
-	case LOG_OPTION_DEBUG:
-		if (value)
-			lc->flags |= option;
-		else
-			lc->flags &= ~option;
-		break;
-	case LOG_OPTION_LEVEL:
-		lc->level = value;
-		break;
-	default:
-		errno = EINVAL;
-		return (-1);
-	}
-	return (0);
-}
-
-int
-log_category_is_active(log_context lc, int category) {
-	if (lc == NULL) {
-		errno = EINVAL;
-		return (-1);
-	}
-	if (category >= 0 && category < lc->num_categories &&
-	    lc->categories[category] != NULL)
-		return (1);
-	return (0);
-}
-
-log_channel
-log_new_syslog_channel(unsigned int flags, int level, int facility) {
-	log_channel chan;
-
-	chan = memget(sizeof (struct log_channel));
-	if (chan == NULL) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	chan->type = log_syslog;
-	chan->flags = flags;
-	chan->level = level;
-	chan->out.facility = facility;
-	chan->references = 0;
-	return (chan);
-}
-
-log_channel
-log_new_file_channel(unsigned int flags, int level,
-		     const char *name, FILE *stream, unsigned int versions,
-		     unsigned long max_size) {
-	log_channel chan;
-
-	chan = memget(sizeof (struct log_channel));
-	if (chan == NULL) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	chan->type = log_file;
-	chan->flags = flags;
-	chan->level = level;
-	if (name != NULL) {
-		size_t len;
-		
-		len = strlen(name);
-		/* 
-		 * Quantize length to a multiple of 256.  There's space for the
-		 * NUL, since if len is a multiple of 256, the size chosen will
-		 * be the next multiple.
-		 */
-		chan->out.file.name_size = ((len / 256) + 1) * 256;
-		chan->out.file.name = memget(chan->out.file.name_size);
-		if (chan->out.file.name == NULL) {
-			memput(chan, sizeof (struct log_channel));
-			errno = ENOMEM;
-			return (NULL);
-		}
-		/* This is safe. */
-		strcpy(chan->out.file.name, name);
-	} else {
-		chan->out.file.name_size = 0;
-		chan->out.file.name = NULL;
-	}
-	chan->out.file.stream = stream;
-	chan->out.file.versions = versions;
-	chan->out.file.max_size = max_size;
-	chan->out.file.owner = getuid();
-	chan->out.file.group = getgid();
-	chan->references = 0;
-	return (chan);
-}
-
-int
-log_set_file_owner(log_channel chan, uid_t owner, gid_t group) {
-	if (chan->type != log_file) {
-		errno = EBADF;
-		return (-1);
-	}
-	chan->out.file.owner = owner;
-	chan->out.file.group = group;
-	return (0);
-}
-
-log_channel
-log_new_null_channel() {
-	log_channel chan;
-
-	chan = memget(sizeof (struct log_channel));
-	if (chan == NULL) {
-		errno = ENOMEM;
-		return (NULL);
-	}
-	chan->type = log_null;
-	chan->flags = LOG_CHANNEL_OFF;
-	chan->level = log_info;
-	chan->references = 0;
-	return (chan);
-}
-
-int
-log_inc_references(log_channel chan) {
-	if (chan == NULL) {
-		errno = EINVAL;
-		return (-1);
-	}
-	chan->references++;
-	return (0);
-}
-
-int
-log_dec_references(log_channel chan) {
-	if (chan == NULL || chan->references <= 0) {
-		errno = EINVAL;
-		return (-1);
-	}
-	chan->references--;
-	return (0);
-}
-
-log_channel_type
-log_get_channel_type(log_channel chan) {
-	REQUIRE(chan != NULL);
-	
-	return (chan->type);
-}
-
-int
-log_free_channel(log_channel chan) {
-	if (chan == NULL || chan->references <= 0) {
-		errno = EINVAL;
-		return (-1);
-	}
-	chan->references--;
-	if (chan->references == 0) {
-		if (chan->type == log_file) {
-			if ((chan->flags & LOG_CLOSE_STREAM) &&
-			    chan->out.file.stream != NULL)
-				(void)fclose(chan->out.file.stream);
-			if (chan->out.file.name != NULL)
-				memput(chan->out.file.name,
-				       chan->out.file.name_size);
-		}
-		memput(chan, sizeof (struct log_channel));
-	}
-	return (0);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/isc/logging.mdoc b/contrib/bind9/lib/bind/isc/logging.mdoc
deleted file mode 100644
index 98b2aed..0000000
--- a/contrib/bind9/lib/bind/isc/logging.mdoc
+++ /dev/null
@@ -1,1056 +0,0 @@
-.\" $Id: logging.mdoc,v 1.3 2004/03/09 06:30:08 marka Exp $
-.\"
-.\" Copyright (c) 2004 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
-.\" 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.
-.\"
-.\" The following six UNCOMMENTED lines are required.
-.Dd January 1, 1996
-.\"Os OPERATING_SYSTEM [version/release]
-.Os BSD 4
-.\"Dt DOCUMENT_TITLE [section number] [volume]
-.Dt LOGGING @SYSCALL_EXT@
-.Sh NAME
-.Nm log_open_stream ,
-.Nm log_close_stream ,
-.Nm log_get_stream ,
-.Nm log_get_filename ,
-.Nm log_vwrite ,
-.Nm log_write ,
-.Nm log_new_context ,
-.Nm log_free_context ,
-.Nm log_add_channel ,
-.Nm log_remove_channel ,
-.Nm log_option ,
-.Nm log_category_is_active ,
-.Nm log_new_syslog_channel ,
-.Nm log_new_file_channel ,
-.Nm log_set_file_owner ,
-.Nm log_new_null_channel ,
-.Nm log_inc_references ,
-.Nm log_dec_references ,
-.Nm log_free_channel
-.Nd logging system
-.Sh SYNOPSIS
-.Fd #include <isc/logging.h>
-.Ft FILE *
-.Fn log_open_stream "log_channel chan"
-.Ft int
-.Fn log_close_stream "log_channel chan"
-.Ft FILE * 
-.Fn log_get_stream "log_channel chan"
-.Ft char * 
-.Fn log_get_filename "log_channel chan"
-.Ft void 
-.Fn log_vwrite "log_context lc" "int category" "int level" \
-    "const char *format" va_list args"
-.Ft void 
-.Fn log_write "log_context lc" "int category" "int level" \
-    "const char *format" "..."
-.Ft int
-.Fn log_check_channel "log_context lc" "int level" "log_channel chan"
-.Ft int
-.Fn log_check "log_context lc" "int category" "int level"
-.Ft int 
-.Fn log_new_context "int num_categories" "char **category_names" \
-    "log_context *lc"
-.Ft void 
-.Fn log_free_context "log_context lc"
-.Ft int 
-.Fn log_add_channel "log_context lc" "int category" "log_channel chan"
-.Ft int 
-.Fn log_remove_channel "log_context lc" "int category" "log_channel chan"
-.Ft int 
-.Fn log_option "log_context lc" "int option" "int value"
-.Ft int 
-.Fn log_category_is_active "log_context lc" "int category"
-.Ft log_channel 
-.Fn log_new_syslog_channel "unsigned int flags" "int level" "int facility"
-.Ft log_channel 
-.Fn log_new_file_channel "unsigned int flags" "int level" \
-    "char *name" "FILE *stream" "unsigned int versions" \
-    "unsigned long max_size"
-.Ft int
-.Fn log_set_file_owner "log_channel chan" "uid_t owner" "gid_t group"
-.Ft log_channel 
-.Fn log_new_null_channel "void"
-.Ft int 
-.Fn log_inc_references "log_channel chan"
-.Ft int 
-.Fn log_dec_references "log_channel chan"
-.Ft int 
-.Fn log_free_channel "log_channel chan"
-.Sh DESCRIPTION
-The
-.Sy ISC
-.Nm logging library
-is flexible logging system which is based upon a set of concepts:
-.Nm logging channels ,
-.Nm categories ,
-and 
-.Nm logging contexts .
-.Pp
-The basic building block is the
-.Dq Nm logging channel , 
-which includes a 
-.Nm priority 
-(logging level), which type of logging is to occur, and other
-flags and information associated with technical aspects of the logging.  
-The set of priorities which are supported is shown below, in the section
-.Sx Message Priorities .
-A priority sets a threshold for message logging; a logging channel will
-.Em only
-log those messages which are 
-.Em at least as important
-as its priority indicates.  (The fact that 
-.Dq more important
-means 
-.Dq more negative ,
-under the current scheme, is an implementation detail; if a channel has
-a priority of
-.Dv log_error ,
-then it will
-.Em not
-log messages with the
-.Dv log_warning
-priority, but it
-.Em will
-log messages with the
-.Dv log_error
-or 
-.Dv log_critical
-priority.)
-.Pp
-The
-.Nm logging channel
-also has an indication of the type of logging performed.  Currently, 
-the supported
-.Nm logging types 
-include (see also 
-.Sx Logging Types ,
-below):
-.Bl -tag -width "log_syslog" -compact -offset indent
-.It Dv log_syslog
-for 
-.Xr syslog 3 Ns -style
-logging
-.It Dv log_file
-for use of a file
-.It Dv log_null
-for 
-.Em no
-logging
-.El
-A new logging channel is created by calling either
-.Fn log_new_syslog_channel ,
-.Fn log_new_file_channel ,
-or
-.Fn log_new_null_channel ,
-respectively.  
-When a channel is no longer to be used, it can be freed using
-.Fn log_free_channel .
-.Pp
-Both 
-.Dv log_syslog
-and
-.Dv log_file
-channel types can include more information; for instance, a
-.Dv log_syslog Ns -type 
-channel allows the specification of a 
-.Xr syslog 3 Ns -style
-.Dq facility , 
-and a
-.Dv log_file Ns -type
-channels allows the caller to set a maximum file size and number
-of versions.  (See 
-.Fn log_new_syslog_channel
-or
-.Fn log_new_file_channel ,
-below.)
-Additionally, once a logging channel of type
-.Dv log_file
-is defined, the functions
-.Fn log_open_stream
-and 
-.Fn log_close_stream
-can open or close the stream associated with the logging channel's logging
-filename.  The
-.Fn log_get_stream
-and
-.Fn log_get_filename
-functions return the stream or filename, respectively, of such a logging 
-channel.  Also unique to logging channels of type
-.Dv log_file
-is the
-.Fn log_set_file_owner
-function, which tells the logging system what user and group ought to own
-newly created files (which is only effective if the caller is privileged.)
-.Pp
-Callers provide
-.Dq Nm categories ,
-determining both the number of such categories and any (optional) names.
-Categories are like array indexes in C; if the caller declares 
-.Dq Va n
-categories, then they are considered to run from 0 to
-.Va n-1 ;
-with this scheme, a category number would be invalid if it were negative or 
-greater than/equal to 
-.Va n .
-Each category can have its own list of 
-.Nm logging channels 
-associated with it; we say that such a channel is 
-.Dq in 
-the particular category.
-.Sy NOTE :
-Individual logging channels can appear in more than one category.
-.Pp
-A
-.Dq Nm logging context
-is the set of all 
-.Nm logging channels 
-associated with the context's
-.Nm categories ;
-thus, a particular 
-.Nm category 
-scheme is associated with a particular
-.Nm logging context .
-.Sy NOTE :
-A logging channel may appear in more than one logging context, and in 
-multiple categories within each logging context.
-.Pp
-Use 
-.Fn log_add_channel
-and
-.Fn log_remove_channel
-to add or remove a logging channel to some category in a logging context.
-To see if a given category in a logging context is being used, use the
-Boolean test
-.Fn log_category_is_active .
-.Pp
-A 
-.Nm logging context
-can also have a 
-.Nm priority
-(logging level)
-and various flags associated with the whole context; in order to alter the
-flags or change the priority of a context, use
-.Fn log_option .
-.Ss Message Priorities
-Currently, five 
-.Nm priorities
-(logging levels) are supported (they can also be found in the header file):
-.Bd -literal -offset indent
-#define log_critical            (-5)
-#define log_error               (-4)
-#define log_warning             (-3)
-#define log_notice              (-2)
-#define log_info                (-1)
-.Ed
-.Pp
-In the current implementation, logging messages which have a level greater
-than 0 are considered to be debugging messages.
-.Ss Logging Types
-The three different
-.Nm logging types 
-currently supported are different values of the enumerated type
-.Ft log_output_type 
-(these are also listed in the header file): 
-.Bd -literal -offset indent
-typedef enum { log_syslog, log_file, log_null } log_output_type;
-.Ed
-.Ss Logging Channel Flags 
-There are several flags which can be set on a logging channel; the flags 
-and their meanings are as follows (they are also found in the header file):
-.Bl -tag -width "LOG_USE_CONTEXT_LEVEL  " -offset indent
-.It Dv LOG_CHANNEL_BROKEN
-This is set only when some portion of 
-.Fn log_open_stream
-fails:
-.Xr open 2 
-or
-.Xr fdopen 3  
-fail;
-.Xr stat 2
-fails in a
-.Dq bad
-way; versioning or truncation is requested on a non-normal file.
-.It Dv LOG_CHANNEL_OFF
-This is set for channels opened by 
-.Fn log_new_null_channel .
-.It Dv LOG_CLOSE_STREAM
-If this flag is set, then 
-.Fn log_free_channel
-will free a 
-.No non- Dv NULL
-stream of a logging channel which is being
-.Xr free 3 Ns -d 
-(if the logging channel is of type
-.Dv log_file ,
-of course).
-.It Dv LOG_PRINT_CATEGORY
-If set, 
-.Fn log_vwrite
-will insert the category name, if available, into logging messages which are 
-logged to channels of type
-.Dv log_syslog
-or 
-.Dv log_file .
-.It Dv LOG_PRINT_LEVEL
-If set, 
-.Fn log_vwrite
-will insert a string identifying the message priority level into the 
-information logged to channels of type
-.Dv log_syslog
-or 
-.Dv log_file .
-.It Dv LOG_REQUIRE_DEBUG
-Only log debugging messages (i.e., those with a priority greater than zero).
-.It Dv LOG_TIMESTAMP
-If set, 
-.Fn log_vwrite
-will insert a timestamp into logging messages which are logged to channels of
-type
-.Dv log_syslog
-or 
-.Dv log_file .
-.It Dv LOG_TRUNCATE
-Truncate logging file when re-opened
-.Fn ( log_open_stream 
-will
-.Xr unlink 2
-the file and then 
-.Xr open 2
-a new file of the same name with the
-.Dv O_EXCL
-bit set).
-.It Dv LOG_USE_CONTEXT_LEVEL
-Use the logging context's priority or logging level, rather than the logging 
-channel's own priority.  This can be useful for those channels which are 
-included in multiple logging contexts.
-.El
-.Ss FUNCTION DESCRIPTIONS
-The function
-.Fn log_open_stream 
-is for use with channels which log to a file; i.e., logging channels with a
-.Va type 
-field set to
-.Dq Dv log_file .
-If the logging channel pointed to by 
-.Dq Fa chan
-is valid, it attempts to open (and return) the stream associated with that
-channel.  If the stream is already opened, then it is returned; otherwise,
-.Xr stat 2
-is used to test the filename for the stream.
-.Pp
-At this point, if the logging file is supposed to have different
-.Va versions 
-(i.e., incremented version numbers; higher numbers indicate older versions
-of the logging file).  If so, then any existing versions are
-.Xr rename 2 Ns -d
-to have one version-number higher than previously, and the
-.Dq current
-filename for the stream is set to the
-.Dq \&.0
-form of the name.  Next, if the logging file is supposed to be truncated
-(i.e., the
-.Dv LOG_TRUNCATE
-bit of the
-.Va flags
-field of the logging channel structure is set), then any file with the
-.Dq current
-filename for the stream is
-.Xr unlink 2 Ns -d .
-.Sy NOTE :
-If the logging file is 
-.Em not 
-a regular file, and either of the above operations (version numbering
-or truncation) is supposed to take place, a
-.Dv NULL
-file pointer is returned.
-.Pp
-Finally, the filename associated with the logging channel is
-.Xr open 2 Ns -d
-using the appropriate flags and a mode which sets the read/write permissions
-for the user, group, and others.  The file descriptor returned by 
-.Xr open 2
-is then passed to
-.Xr fopen 3 ,
-with the append mode set, and the stream returned by this call is stored
-in the 
-.Fa chan
-structure and returned.
-.Pp
-If 
-.Fn log_open_stream
-fails at any point, then the 
-.Dv LOG_CHANNEL_BROKEN 
-bit of the
-.Va flags 
-field of the logging channel pointed to by
-.Fa chan
-is set, a 
-.Dv NULL
-is returned, and 
-.Va errno
-contains pertinent information.
-.Pp
-The
-.Fn log_close_stream
-function closes the stream associated with the logging channel pointed to by
-.Dq Fa chan 
-(if
-.Fa chan 
-is valid and the stream exists and can be closed properly by
-.Xr fclose 3 ) .  
-The stream is set to 
-.Dv NULL
-even if the call to 
-.Xr fclose 3
-fails.
-.Pp
-The function
-.Fn log_get_stream
-returns the stream associated with the logging channel pointed to by
-.Dq Fa chan ,
-if it is 
-.No non- Ns Dv NULL
-and specifies a logging channel which has a 
-.Dv FILE *
-or stream associated with it.
-.Pp
-The
-.Fn log_get_filename
-function returns the name of the file associated with the logging channel 
-pointed to by
-.Dq Fa chan ,
-if it is 
-.No non- Ns Dv NULL
-and specifies a logging channel which has a file associated with it.
-.Pp
-The
-.Fn log_vwrite 
-function performs the actual logging of a message to the various logging
-channels of a logging context
-.Fa lc .
-The message consists of an
-.Xr fprint 3 Ns -style
-.Fa format 
-and its associated
-.Fa args 
-(if any); it will be written to all logging channels in the given
-.Fa category
-which have a priority set to
-.Fa level
-or any 
-.Em less important
-priority value.  If the
-.Fa category
-is not valid or has no logging channels, then the category defaults to 0.
-.Pp
-There are a number of conditions under which a call to 
-.Fn log_vwrite
-will not result in actually logging the message: if there is no logging channel 
-at even the default category (0), or if a given channel is either 
-.Dq broken
-or
-.Dq off
-(i.e., its flags have 
-.Dv LOG_CHANNEL_BROKEN
-or
-.Dv LOG_CHANNEL_OFF
-set, respectively), or if the logging channel channel is of type
-.Dv log_null .
-Additionally, if the logging channel's flag has
-.Dv LOG_REQUIRE_DEBUG
-set and the message is not a debugging message (i.e., has a level greater
-than 0), then it will not be logged.
-Finally, if the message's priority is less important than the
-channel's logging level (the priority threshold), will not be logged.
-.Sy NOTE :
-If a logging channel's flag has
-.Dv LOG_USE_CONTEXT_LEVEL
-set, it will use the logging context's priority, rather than its own.
-.Pp
-If all of these hurdles are passed, then only
-.Dv log_syslog
-and
-.Dv log_file
-channels actually can have logging.  For channels which use
-.Xr syslog 3 ,
-the channel's 
-.Xr syslog 3
-facility is used in conjunction with a potentially modified form of the
-message's priority level, since 
-.Xr syslog 3
-has its own system of priorities
-.Pq Pa /usr/include/syslog.h . 
-All debug messages (priority >= 0) are mapped to 
-.Xr syslog 3 Ns 's
-.Dv LOG_DEBUG
-priority, all messages 
-.Dq more important
-than
-.Dv log_critical
-are mapped to
-.Dv LOG_CRIT ,
-and the priorities corresponding to the ones listed in the section
-.Sx Message Priorities
-are given the obvious corresponding 
-.Xr syslog 3
-priority.
-.Pp
-For 
-.Dv log_file
-type logging channels, if the file size is greater than the maximum file 
-size, then no logging occurs.  (The same thing happens if a 
-.Dv NULL
-stream is encountered and
-.Fn log_open_stream
-fails to open the channel's stream.)
-.Pp
-For both logging to normal files and logging via
-.Xr syslog 3 ,
-the value of the flags
-.Dv LOG_TIMESTAMP ,
-.Dv LOG_PRINT_CATEGORY , 
-and
-.Dv LOG_PRINT_LEVEL 
-are used in determining whether or not these items are included in the logged 
-information.
-.Pp
-The 
-.Fn log_write 
-function is merely a front-end to a call to 
-.Fn log_vwrite ;
-see the description of that function, above, for more information.
-.Pp
-.Fn log_check
-and
-.Fn log_check_channel
-are used to see if a contemplated logging call will actually generate any
-output, which is useful when creating a log message involves non-trivial
-work.
-.Fn log_check
-will return non-zero if a call to
-.Fn log_vwrite
-with the given 
-.Fa category
-and
-.Fa level
-would generate output on any channels, and zero otherwise.
-.Fn log_check_channel
-will return non-zero if writing to the
-.Fa chan
-at the given
-.Fa level
-would generate output.
-.Pp
-The function
-.Fn log_new_context 
-creates a new 
-.Nm logging context ,
-and stores this in the
-.Dq Va opaque
-field of the argument
-.Dq Fa lc , 
-and opaque structure used internally.  This new 
-.Nm context 
-will include the
-.Dq Fa num_categories
-and
-.Dq Fa category_names
-which are supplied; the latter can be
-.Dv NULL .
-.Sy NOTE :
-Since 
-.Dq Fa category_names
-is used directly, it 
-.Em must not 
-be freed by the caller, if it is 
-.No non- Ns Dv NULL .
-The initial logging flags and priority are both set to zero.
-.Pp
-The
-.Fn log_free_context 
-function is used to free the opaque structure 
-.Dq Va lc.opaque
-and its components.
-.Sy NOTE :
-The
-.Dq Va opaque
-field of 
-.Dq Fa lc
-.Em must 
-be
-.No non- Ns Dv NULL .
-For each of the various
-.Dq categories
-(indicated by the
-.Dq Va num_categories
-which were in the corresponding call to
-.Fn log_new_context ) 
-associated with the given 
-.Nm logging context ,
-.Em all 
-of the 
-.Nm logging channels
-are 
-.Xr free 3 Ns -d .
-The opaque structure itself is then
-.Xr free 3 Ns -d ,
-and 
-.Dq Va lc.opaque
-is set to
-.Dv NULL .
-.Pp
-.Sy NOTE :
-The function 
-.Fn log_free_context 
-does
-.Em not
-free the memory associated with 
-.Fa category_names ,
-since the logging library did not allocate the memory for it, originally;
-it was supplied in the call to
-.Fn log_new_context .
-.Pp
-The function
-.Fn log_add_channel 
-adds the 
-.Nm logging channel
-.Dq Fa chan
-to the list of logging channels in the given 
-.Fa category
-of the 
-.Nm logging context
-.Dq Fa lc .
-No checking is performed to see whether or not
-.Fa chan
-is already present in the given
-.Fa category ,
-so multiple instances in a single 
-.Fa category 
-can occur (but see
-.Fn log_remove_channel ,
-below).
-.Pp
-The
-.Fn log_remove_channel 
-function
-removes 
-.Em all
-occurrences of the
-.Nm logging channel
-.Dq Fa chan
-from the list of logging channels in the given 
-.Fa category
-of the 
-.Nm logging context
-.Dq Fa lc .
-It also attempts to free the channel by calling
-.Fn log_free_channel 
-(see its description, below).
-.Pp
-The
-.Fn log_option 
-function is used to change the
-.Fa option 
-of the indicated logging context
-.Fa lc
-to the given
-.Fa value .
-The 
-.Fa option
-can be either
-.Dv LOG_OPTION_LEVEL
-or
-.Dv LOG_OPTION_DEBUG ;
-in the first case, the log context's debugging level is reset to the
-indicated level.  If the
-.Fa option 
-is 
-.Dv LOG_OPTION_DEBUG , 
-then a non-zero
-.Fa value
-results in setting the debug flag of the logging context, while a zero
-.Fa value
-means that the debug flag is reset.
-.Pp
-The
-.Fn log_category_is_active 
-test returns a 1 if the given
-.Fa category
-of the indicated logging context
-.Fa lc
-has at least one logging channel, and 0, otherwise.
-.Pp
-The functions
-.Fn log_new_syslog_channel ,
-.Fn log_new_file_channel ,
-and 
-.Fn log_new_null_channel
-create a new channel of the type specified (thus, the difference in arguments);
-the 
-.Dq Va type
-field of the new
-.Do
-.Ft struct log_channel
-.Dc
-is always set to the appropriate value.
-.Pp
-The 
-.Fn log_new_syslog_channel
-function 
-.Xr malloc 3 Ns -s
-a new
-.Ft struct log_channel
-of
-.Va type
-.Dv log_syslog ,
-i.e., a logging channel which will use
-.Xr syslog 3 .
-The new structure is filled out with the 
-.Dq Fa flags ,
-.Dq Fa level , 
-and 
-.Dq Fa facility 
-which are given; the 
-.Va references
-field is initialized to zero.
-See 
-.Sx Logging Channel Flags
-and
-.Sx Message Priorities ,
-above, or the header file for information about acceptable values for
-.Dq Fa flags ,
-and 
-.Dq Fa level .
-The
-.Dq Fa facility .
-can be any valid
-.Xr syslog 3
-facility; see the appropriate system header file or manpage for more 
-information.
-.Pp
-.Ft log_channel 
-.Fn log_new_file_channel "unsigned int flags" "int level" \
-    "char *name" "FILE *stream" "unsigned int versions" \
-    "unsigned long max_size"
-.Pp
-.Fn log_new_null_channel 
-.Pp
-The functions
-.Fn log_inc_references 
-and
-.Fn log_dec_references 
-increment or decrements, respectively, the
-.Va references 
-field of the logging channel pointed to by
-.Dq Fa chan ,
-if it is a valid channel (and if the 
-.Va references
-field is strictly positive, in the case of
-.Fn log_dec_references ) .
-These functions are meant to track changes in the number of different clients
-which refer to the given logging channel.
-.Pp
-The 
-.Fn log_free_channel
-function frees the 
-field of the logging channel pointed to by
-.Dq Fa chan 
-if there are no more outstanding references to it.  If the channel uses a file, 
-the stream is 
-.Xr fclose 3 Ns -d 
-(if the
-.Dv LOG_CLOSE_STREAM
-flag is set), and the filename, if 
-.No non- Ns Dv NULL ,
-is 
-.Xr free 3 Ns -d 
-before 
-.Dq Fa chan
-is 
-.Xr free 3 Ns -d .
-.Pp
-.\" The following requests should be uncommented and
-.\" used where appropriate.  This next request is
-.\" for sections 2 and 3 function return values only.
-.Sh RETURN VALUES
-.\" This next request is for sections 1, 6, 7 & 8 only
-.Bl -tag -width "log_category_is_active()"
-.It Fn log_open_stream
-.Dv NULL 
-is returned under any of several error conditions:
-a) if 
-.Dq Fa chan
-is either
-.Dv NULL
-or a 
-.No non- Ns Dv log_file
-channel
-.Pq Va errno No is set to Dv EINVAL ;
-b) if either versioning or truncation is requested for a non-normal file
-.Pq Va errno No is set to Dv EINVAL ;
-c) if any of
-.Xr stat 2 , 
-.Xr open 2 , 
-or
-.Xr fdopen 3
-fails
-.Po
-.Va errno 
-is set by the call which failed 
-.Pc .
-If some value other than
-.Dv NULL
-is returned, then it is a valid logging stream (either newly-opened or 
-already-open).
-.It Fn log_close_stream
--1 if the stream associated with
-.Dq Fa chan
-is 
-.No non- Ns Dv NULL
-and the call to
-.Xr fclose 3
-fails.
-0 if successful or the logging channel pointed to by
-.Dq Fa chan
-is invalid (i.e.,
-.Dv NULL
-or not a logging channel which has uses a file); in the latter case, 
-.Va errno
-is set to 
-.Dv EINVAL .  
-.It Fn log_get_stream
-.Dv NULL 
-under the same conditions as those under which
-.Fn log_close_stream ,
-above, returns 0 (including the setting of 
-.Va errno ) .
-Otherwise, the stream associated with the logging channel is returned.
-.It Fn log_get_filename
-.Dv NULL 
-under the same conditions as those under which
-.Fn log_close_stream ,
-above, returns 0 (including the setting of 
-.Va errno ) .
-Otherwise, the name of the file associated with the logging channel is 
-returned.
-.It Fn log_new_context
--1 if 
-.Xr malloc 3
-fails
-.Pq with Va errno No set to Dv ENOMEM .
-Otherwise, 0, with 
-.Dq Va lc->opaque
-containing the new structures and information.
-.It Fn log_add_channel
--1 if
-a) either
-.Dq Va lc.opaque
-is
-.Dv NULL 
-or 
-.Fa category
-is invalid (negative or greater than or equal to 
-.Va lcp->num_categories ) ,
-with
-.Va errno 
-set to 
-.Dv EINVAL ;
-b) 
-.Xr malloc 3
-fails
-.Pq with Va errno No set to Dv ENOMEM .
-Otherwise, 0.
-.It Fn log_remove_channel
--1 if
-a) either
-.Dq Va lc.opaque
-is 
-.Dv NULL
-or 
-.Fa category
-is invalid, as under failure condition a) for
-.Fn log_add_channel ,
-above, including the setting of
-.Va errno ;
-b) no channel numbered
-.Fa chan
-is found in the logging context indicated by
-.Fa lc 
-.Pq with Va errno No set to Dv ENOENT .
-Otherwise, 0.
-.It Fn log_option
--1 if
-a) 
-.Dq Va lc.opaque
-is
-.Dv NULL , 
-b)
-.Fa option
-specifies an unknown logging option;
-in either case, 
-.Va errno 
-is set to 
-.Dv EINVAL .
-Otherwise, 0.
-.It Fn log_category_is_active
--1 if
-.Dq Va lc.opaque
-is
-.Dv NULL 
-.Pq with Va errno No set to Dv EINVAL ;
-1 if the
-.Fa category
-number is valid and there are logging channels in this 
-.Fa category
-within the indicated logging context; 0 if the
-.Fa category
-number is invalid or there are no logging channels in this
-.Fa category
-within the indicated logging context.
-.It Fn log_new_syslog_channel
-.Dv NULL
-if
-.Xr malloc 3
-fails
-.Pq with Va errno No set to ENOMEM ;
-otherwise, a valid 
-.Dv log_syslog Ns -type
-.Ft log_channel .
-.It Fn log_new_file_channel
-.Dv NULL
-if
-.Xr malloc 3
-fails
-.Pq with Va errno No set to ENOMEM ;
-otherwise, a valid
-.Dv log_file Ns -type
-.Ft log_channel .
-.It Fn log_new_null_channel
-.Dv NULL
-if
-.Xr malloc 3
-fails
-.Pq with Va errno No set to ENOMEM ;
-otherwise, a valid 
-.Dv log_null Ns -type
-.Ft log_channel .
-.It Fn log_inc_references
--1 if 
-.Dq Fa chan
-is 
-.Dv NULL 
-.Pq with Va errno set to Dv EINVAL .
-Otherwise, 0.
-.It Fn log_dec_references
--1 if 
-.Dq Fa chan
-is 
-.Dv NULL 
-or its
-.Va references
-field is already <= 0
-.Pq with Va errno set to Dv EINVAL .
-Otherwise, 0.
-.It Fn log_free_channel
--1 under the same conditions as
-.Fn log_dec_references ,
-above, including the setting of 
-.Va errno ;
-0 otherwise.
-.El
-.\" .Sh ENVIRONMENT
-.Sh FILES
-.Bl -tag -width "isc/logging.h"
-.It Pa isc/logging.h
-include file for logging library
-.It Pa syslog.h
-.Xr syslog 3 Ns -style
-priorities
-.El
-.\" .Sh EXAMPLES
-.\" This next request is for sections 1, 6, 7 & 8 only
-.\"     (command return values (to shell) and
-.\"    fprintf/stderr type diagnostics)
-.\" .Sh DIAGNOSTICS
-.\" The next request is for sections 2 and 3 error
-.\" and signal handling only.
-.Sh ERRORS
-This table shows which functions can return the indicated error in the
-.Va errno
-variable; see the
-.Sx RETURN VALUES
-section, above, for more information.
-.Bl -tag -width "(any0other0value)0"
-.It Dv EINVAL
-.Fn log_open_stream ,
-.Fn log_close_stream ,
-.Fn log_get_stream ,
-.Fn log_get_filename ,
-.Fn log_add_channel ,
-.Fn log_remove_channel ,
-.Fn log_option ,
-.Fn log_category_is_active ,
-.Fn log_inc_references ,
-.Fn log_dec_references ,
-.Fn log_free_channel .
-.It Dv ENOENT
-.Fn log_remove_channel .
-.It Dv ENOMEM
-.Fn log_new_context ,
-.Fn log_add_channel ,
-.Fn log_new_syslog_channel ,
-.Fn log_new_file_channel ,
-.Fn log_new_null_channel .
-.It (any other value)
-returned via a pass-through of an error code from
-.Xr stat 2 , 
-.Xr open 2 , 
-or
-.Xr fdopen 3 ,
-which can occur in 
-.Fn log_open_stream
-and functions which call it
-.Pq currently, only Fn log_vwrite .
-.El
-.Pp
-Additionally, 
-.Fn log_vwrite
-and
-.Fn log_free_context
-will fail via 
-.Fn assert
-if 
-.Dq Va lc.opaque
-is
-.Dv NULL .
-The function
-.Fn log_vwrite
-can also exit with a critical error logged via
-.Xr syslog 3
-indicating a memory overrun
-.Sh SEE ALSO
-.Xr @INDOT@named @SYS_OPS_EXT@ ,
-.Xr syslog 3 .
-The HTML documentation includes a file,
-.Pa logging.html ,
-which has more information about this logging system.
-.\" .Sh STANDARDS
-.\" .Sh HISTORY
-.Sh AUTHORS
-Bob Halley...TODO
-.\" .Sh BUGS
diff --git a/contrib/bind9/lib/bind/isc/logging_p.h b/contrib/bind9/lib/bind/isc/logging_p.h
deleted file mode 100644
index 5e6314f..0000000
--- a/contrib/bind9/lib/bind/isc/logging_p.h
+++ /dev/null
@@ -1,61 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996-1999 by 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.
- */
-
-#ifndef LOGGING_P_H
-#define LOGGING_P_H
-
-typedef struct log_file_desc {
-	char *name;
-	size_t name_size;
-	FILE *stream;
-	unsigned int versions;
-	unsigned long max_size;
-	uid_t owner;
-	gid_t group;
-} log_file_desc;
-
-typedef union log_output {
-	int facility;
-	log_file_desc file;
-} log_output;
-
-struct log_channel {
-	int level;			/*%< don't log messages > level */
-	log_channel_type type;
-	log_output out;
-	unsigned int flags;
-	int references;
-};
-
-typedef struct log_channel_list {
-	log_channel channel;
-	struct log_channel_list *next;
-} *log_channel_list;
-
-#define LOG_BUFFER_SIZE 20480
-
-struct log_context {
-	int num_categories;
-	char **category_names;
-	log_channel_list *categories;
-	int flags;
-	int level;
-	char buffer[LOG_BUFFER_SIZE];
-};
-
-#endif /* !LOGGING_P_H */
-/*! \file */
diff --git a/contrib/bind9/lib/bind/isc/memcluster.c b/contrib/bind9/lib/bind/isc/memcluster.c
deleted file mode 100644
index a58a2fe..0000000
--- a/contrib/bind9/lib/bind/isc/memcluster.c
+++ /dev/null
@@ -1,588 +0,0 @@
-/*
- * 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
- * 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.
- */
-
-
-/* When this symbol is defined allocations via memget are made slightly 
-   bigger and some debugging info stuck before and after the region given 
-   back to the caller. */
-/* #define DEBUGGING_MEMCLUSTER */
-#define MEMCLUSTER_ATEND
-
-
-#if !defined(LINT) && !defined(CODECENTER)
-static const char rcsid[] = "$Id: memcluster.c,v 1.5.18.6 2006/08/30 23:30:35 marka Exp $";
-#endif /* not lint */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/uio.h>
-#include <sys/param.h>
-#include <sys/stat.h>
-
-#include <netinet/in.h>
-#include <arpa/inet.h>
-#include <arpa/nameser.h>
-
-#include <errno.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <time.h>
-
-#include <isc/memcluster.h>
-#include <isc/assertions.h>
-
-#include "port_after.h"
-
-#ifdef MEMCLUSTER_RECORD
-#ifndef DEBUGGING_MEMCLUSTER
-#define DEBUGGING_MEMCLUSTER
-#endif
-#endif
-
-#define DEF_MAX_SIZE		1100
-#define DEF_MEM_TARGET		4096
-
-typedef u_int32_t fence_t;
-
-typedef struct {
-	void *			next;
-#if defined(DEBUGGING_MEMCLUSTER)
-#if defined(MEMCLUSTER_RECORD)
-	const char *		file;
-	int			line;
-#endif
-	size_t			size;
-	fence_t			fencepost;
-#endif
-} memcluster_element;
-
-#define SMALL_SIZE_LIMIT sizeof(memcluster_element)
-#define P_SIZE sizeof(void *)
-#define FRONT_FENCEPOST 0xfebafeba
-#define BACK_FENCEPOST 0xabefabef
-#define FENCEPOST_SIZE 4
-
-#ifndef MEMCLUSTER_LITTLE_MALLOC
-#define MEMCLUSTER_BIG_MALLOC 1
-#define NUM_BASIC_BLOCKS 64
-#endif
-
-struct stats {
-	u_long			gets;
-	u_long			totalgets;
-	u_long			blocks;
-	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;
-#endif
-#ifdef MEMCLUSTER_BIG_MALLOC
-static memcluster_element *	basic_blocks;
-#endif
-static struct stats *		stats;
-
-/* Forward. */
-
-static size_t			quantize(size_t);
-#if defined(DEBUGGING_MEMCLUSTER)
-static void			check(unsigned char *, int, size_t);
-#endif
-
-/* Public. */
-
-int
-meminit(size_t init_max_size, size_t target_size) {
-
-#if defined(DEBUGGING_MEMCLUSTER)
-	INSIST(sizeof(fence_t) == FENCEPOST_SIZE);
-#endif
-	if (freelists != NULL) {
-		errno = EEXIST;
-		return (-1);
-	}
-	if (init_max_size == 0U)
-		max_size = DEF_MAX_SIZE;
-	else
-		max_size = init_max_size;
-	if (target_size == 0U)
-		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) {
-		errno = ENOMEM;
-		return (-1);
-	}
-	memset(freelists, 0,
-	       max_size * sizeof (memcluster_element *));
-	memset(stats, 0, (max_size + 1) * sizeof (struct stats));
-#ifdef MEMCLUSTER_RECORD
-	activelists = malloc((max_size + 1) * sizeof (memcluster_element *));
-	if (activelists == NULL) {
-		errno = ENOMEM;
-		return (-1);
-	}
-	memset(activelists, 0,
-	       (max_size + 1) * sizeof (memcluster_element *));
-#endif
-#ifdef MEMCLUSTER_BIG_MALLOC
-	basic_blocks = NULL;
-#endif
-	return (0);
-}
-
-void *
-__memget(size_t size) {
-	return (__memget_record(size, NULL, 0));
-}
-
-void *
-__memget_record(size_t size, const char *file, int line) {
-	size_t new_size = quantize(size);
-#if defined(DEBUGGING_MEMCLUSTER)
-	memcluster_element *e;
-	char *p;
-	fence_t fp = BACK_FENCEPOST;
-#endif
-	void *ret;
-
-	MEMLOCK;
-
-#if !defined(MEMCLUSTER_RECORD)
-	UNUSED(file);
-	UNUSED(line);
-#endif
-	if (freelists == NULL) {
-		if (meminit(0, 0) == -1) {
-			MEMUNLOCK;
-			return (NULL);
-		}
-	}
-	if (size == 0U) {
-		MEMUNLOCK;
-		errno = EINVAL;
-		return (NULL);
-	}
-	if (size >= max_size || new_size >= max_size) {
-		/* memget() was called on something beyond our upper limit. */
-		stats[max_size].gets++;
-		stats[max_size].totalgets++;
-#if defined(DEBUGGING_MEMCLUSTER)
-		e = malloc(new_size);
-		if (e == NULL) {
-			MEMUNLOCK;
-			errno = ENOMEM;
-			return (NULL);
-		}
-		e->next = NULL;
-		e->size = size;
-#ifdef MEMCLUSTER_RECORD
-		e->file = file;
-		e->line = 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
-	}
-
-	/* 
-	 * If there are no blocks in the free list for this size, get a chunk
-	 * of memory and then break it up into "new_size"-sized blocks, adding
-	 * them to the free list.
-	 */
-	if (freelists[new_size] == NULL) {
-		int i, frags;
-		size_t total_size;
-		void *new;
-		char *curr, *next;
-
-#ifdef MEMCLUSTER_BIG_MALLOC
-		if (basic_blocks == NULL) {
-			new = malloc(NUM_BASIC_BLOCKS * mem_target);
-			if (new == NULL) {
-				MEMUNLOCK;
-				errno = ENOMEM;
-				return (NULL);
-			}
-			curr = new;
-			next = curr + mem_target;
-			for (i = 0; i < (NUM_BASIC_BLOCKS - 1); i++) {
-				((memcluster_element *)curr)->next = next;
-				curr = next;
-				next += mem_target;
-			}
-			/*
-			 * curr is now pointing at the last block in the
-			 * array.
-			 */
-			((memcluster_element *)curr)->next = NULL;
-			basic_blocks = new;
-		}
-		total_size = mem_target;
-		new = basic_blocks;
-		basic_blocks = basic_blocks->next;
-#else
-		if (new_size > mem_target_half)
-			total_size = mem_target_fudge;
-		else
-			total_size = mem_target;
-		new = malloc(total_size);
-		if (new == NULL) {
-			MEMUNLOCK;
-			errno = ENOMEM;
-			return (NULL);
-		}
-#endif
-		frags = total_size / new_size;
-		stats[new_size].blocks++;
-		stats[new_size].freefrags += frags;
-		/* Set up a linked-list of blocks of size "new_size". */
-		curr = new;
-		next = curr + new_size;
-		for (i = 0; i < (frags - 1); i++) {
-#if defined (DEBUGGING_MEMCLUSTER)
-			memset(curr, 0xa5, new_size);
-#endif
-			((memcluster_element *)curr)->next = next;
-			curr = next;
-			next += new_size;
-		}
-		/* curr is now pointing at the last block in the array. */
-#if defined (DEBUGGING_MEMCLUSTER)
-		memset(curr, 0xa5, new_size);
-#endif
-		((memcluster_element *)curr)->next = freelists[new_size];
-		freelists[new_size] = new;
-	}
-
-	/* The free list uses the "rounded-up" size "new_size". */
-#if defined (DEBUGGING_MEMCLUSTER)
-	e = freelists[new_size];
-	ret = (char *)e + sizeof *e;
-	/*
-	 * Check to see if this buffer has been written to while on free list.
-	 */
-	check(ret, 0xa5, new_size - sizeof *e);
-	/*
-	 * Mark memory we are returning.
-	 */
-	memset(ret, 0xe5, size);
-#else
-	ret = freelists[new_size];
-#endif
-	freelists[new_size] = freelists[new_size]->next;
-#if defined(DEBUGGING_MEMCLUSTER)
-	e->next = NULL;
-	e->size = size;
-	e->fencepost = FRONT_FENCEPOST;
-#ifdef MEMCLUSTER_RECORD
-	e->file = file;
-	e->line = line;
-	e->next = activelists[size];
-	activelists[size] = e;
-#endif
-	p = (char *)e + sizeof *e + size;
-	memcpy(p, &fp, sizeof fp);
-#endif
-
-	/* 
-	 * The stats[] uses the _actual_ "size" requested by the
-	 * caller, with the caveat (in the code above) that "size" >= the
-	 * max. size (max_size) ends up getting recorded as a call to
-	 * max_size.
-	 */
-	stats[size].gets++;
-	stats[size].totalgets++;
-	stats[new_size].freefrags--;
-	MEMUNLOCK;
-#if defined(DEBUGGING_MEMCLUSTER)
-	return ((char *)e + sizeof *e);
-#else
-	return (ret);
-#endif
-}
-
-/*%
- * This is a call from an external caller, 
- * so we want to count this as a user "put". 
- */
-void
-__memput(void *mem, size_t size) {
-	__memput_record(mem, size, NULL, 0);
-}
-
-void
-__memput_record(void *mem, size_t size, const char *file, int line) {
-	size_t new_size = quantize(size);
-#if defined (DEBUGGING_MEMCLUSTER)
-	memcluster_element *e;
-	memcluster_element *el;
-#ifdef MEMCLUSTER_RECORD
-	memcluster_element *prev;
-#endif
-	fence_t fp;
-	char *p;
-#endif
-
-	MEMLOCK;
-
-#if !defined (MEMCLUSTER_RECORD)
-	UNUSED(file);
-	UNUSED(line);
-#endif
-
-	REQUIRE(freelists != NULL);
-
-	if (size == 0U) {
-		MEMUNLOCK;
-		errno = EINVAL;
-		return;
-	}
-
-#if defined (DEBUGGING_MEMCLUSTER)
-	e = (memcluster_element *) ((char *)mem - sizeof *e);
-	INSIST(e->fencepost == FRONT_FENCEPOST);
-	INSIST(e->size == size);
-	p = (char *)e + sizeof *e + size;
-	memcpy(&fp, p, sizeof fp);
-	INSIST(fp == BACK_FENCEPOST);
-	INSIST(((u_long)mem % 4) == 0);
-#ifdef MEMCLUSTER_RECORD
-	prev = NULL;
-	if (size == max_size || new_size >= max_size)
-		el = activelists[max_size];
-	else
-		el = activelists[size];
-	while (el != NULL && el != e) {
-		prev = el;
-		el = el->next;
-	}
-	INSIST(el != NULL);	/*%< double free */
-	if (prev == NULL) {
-		if (size == max_size || new_size >= max_size)
-			activelists[max_size] = el->next;
-		else
-			activelists[size] = el->next;
-	} else
-		prev->next = el->next;
-#endif
-#endif
-
-	if (size == max_size || new_size >= max_size) {
-		/* memput() called on something beyond our upper limit */
-#if defined(DEBUGGING_MEMCLUSTER)
-		free(e);
-#else
-		free(mem);
-#endif
-
-		INSIST(stats[max_size].gets != 0U);
-		stats[max_size].gets--;
-		MEMUNLOCK;
-		return;
-	}
-
-	/* The free list uses the "rounded-up" size "new_size": */
-#if defined(DEBUGGING_MEMCLUSTER)
-	memset(mem, 0xa5, new_size - sizeof *e); /*%< catch write after free */
-	e->size = 0;	/*%< catch double memput() */
-#ifdef MEMCLUSTER_RECORD
-	e->file = file;
-	e->line = line;
-#endif
-#ifdef MEMCLUSTER_ATEND
-	e->next = NULL;
-	el = freelists[new_size];
-	while (el != NULL && el->next != NULL)
-		el = el->next;
-	if (el)
-		el->next = e;
-	else
-		freelists[new_size] = e;
-#else
-	e->next = freelists[new_size];
-	freelists[new_size] = (void *)e;
-#endif
-#else
-	((memcluster_element *)mem)->next = freelists[new_size];
-	freelists[new_size] = (memcluster_element *)mem;
-#endif
-
-	/* 
-	 * The stats[] uses the _actual_ "size" requested by the
-	 * caller, with the caveat (in the code above) that "size" >= the
-	 * max. size (max_size) ends up getting recorded as a call to
-	 * max_size.
-	 */
-	INSIST(stats[size].gets != 0U);
-	stats[size].gets--;
-	stats[new_size].freefrags++;
-	MEMUNLOCK;
-}
-
-void *
-__memget_debug(size_t size, const char *file, int line) {
-	void *ptr;
-	ptr = __memget_record(size, file, line);
-	fprintf(stderr, "%s:%d: memget(%lu) -> %p\n", file, line,
-		(u_long)size, ptr);
-	return (ptr);
-}
-
-void
-__memput_debug(void *ptr, size_t size, const char *file, int line) {
-	fprintf(stderr, "%s:%d: memput(%p, %lu)\n", file, line, ptr,
-		(u_long)size);
-	__memput_record(ptr, size, file, line);
-}
-
-/*%
- * Print the stats[] on the stream "out" with suitable formatting.
- */
-void
-memstats(FILE *out) {
-	size_t i;
-#ifdef MEMCLUSTER_RECORD
-	memcluster_element *e;
-#endif
-
-	MEMLOCK;
-
-	if (freelists == NULL) {
-		MEMUNLOCK;
-		return;
-	}
-	for (i = 1; i <= max_size; i++) {
-		const struct stats *s = &stats[i];
-
-		if (s->totalgets == 0U && s->gets == 0U)
-			continue;
-		fprintf(out, "%s%5lu: %11lu gets, %11lu rem",
-			(i == max_size) ? ">=" : "  ",
-			(unsigned long)i, s->totalgets, s->gets);
-		if (s->blocks != 0U)
-			fprintf(out, " (%lu bl, %lu ff)",
-				s->blocks, s->freefrags);
-		fputc('\n', out);
-	}
-#ifdef MEMCLUSTER_RECORD
-	fprintf(out, "Active Memory:\n");
-	for (i = 1; i <= max_size; i++) {
-		if ((e = activelists[i]) != NULL)
-			while (e != NULL) {
-				fprintf(out, "%s:%d %p:%lu\n",
-				        e->file != NULL ? e->file :
-						"<UNKNOWN>", e->line,
-					(char *)e + sizeof *e,
-					(u_long)e->size);
-				e = e->next;
-			}
-	}
-#endif
-	MEMUNLOCK;
-}
-
-int
-memactive(void) {
-	size_t i;
-
-	if (stats == NULL)
-		return (0);
-	for (i = 1; i <= max_size; i++)
-		if (stats[i].gets != 0U)
-			return (1);
-	return (0);
-}
-
-/* Private. */
-
-/*%
- * Round up size to a multiple of sizeof(void *).  This guarantees that a
- * block is at least sizeof void *, and that we won't violate alignment
- * restrictions, both of which are needed to make lists of blocks.
- */
-static size_t
-quantize(size_t size) {
-	int remainder;
-	/*
-	 * If there is no remainder for the integer division of 
-	 *
-	 *	(rightsize/P_SIZE)
-	 *
-	 * then we already have a good size; if not, then we need
-	 * to round up the result in order to get a size big
-	 * enough to satisfy the request _and_ aligned on P_SIZE boundaries.
-	 */
-	remainder = size % P_SIZE;
-	if (remainder != 0)
-		size += P_SIZE - remainder;
-#if defined(DEBUGGING_MEMCLUSTER)
-	return (size + SMALL_SIZE_LIMIT + sizeof (int));
-#else
-	return (size);
-#endif
-}
-
-#if defined(DEBUGGING_MEMCLUSTER)
-static void
-check(unsigned char *a, int value, size_t len) {
-	size_t i;
-	for (i = 0; i < len; i++)
-		INSIST(a[i] == value);
-}
-#endif
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/isc/memcluster.mdoc b/contrib/bind9/lib/bind/isc/memcluster.mdoc
deleted file mode 100644
index 20b39d0..0000000
--- a/contrib/bind9/lib/bind/isc/memcluster.mdoc
+++ /dev/null
@@ -1,376 +0,0 @@
-.\" $Id: memcluster.mdoc,v 1.3 2004/03/09 06:30:08 marka Exp $
-.\"
-.\" Copyright (c) 2004 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
-.\" 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.
-.\"
-.\" The following six UNCOMMENTED lines are required.
-.Dd Month day, year
-.\"Os OPERATING_SYSTEM [version/release]
-.Os BSD 4
-.\"Dt DOCUMENT_TITLE [section number] [volume]
-.Dt MEMCLUSTER 3
-.Sh NAME
-.Nm meminit ,
-.Nm memget ,
-.Nm memput ,
-.Nm memstats 
-.Nd memory allocation/deallocation system
-.Sh SYNOPSIS
-.Fd #include \&<isc/memcluster.h\&>
-.Ft void * 
-.Fn memget "size_t size"
-.Ft void 
-.Fn memput "void *mem" "size_t size"
-.Ft void 
-.Fn memstats "FILE *out"
-.Sh DESCRIPTION
-These functions access a memory management system which allows callers to not 
-fragment memory to the extent which can ordinarily occur through many random 
-calls to
-.Xr malloc 3 .
-Instead, 
-.Fn memget
-gets a large contiguous chunk of blocks of the requested 
-.Fa size 
-and parcels out these blocks as requested.  The symmetric call is
-.Fn memput ,
-which callers use to return a piece of memory obtained from
-.Fn memget .
-Statistics about memory usage are returned by
-.Fn memstats , 
-which prints a report on the stream
-.Fa out .
-.Ss INTERNALS
-Internally, linked lists of free memory blocks are stored in an array.
-The size of this array is determined by the value
-.Dv MEM_FREECOUNT ,
-currently set to 1100.  In general, for any requested blocksize
-.Dq Fa size ,
-any free blocks will be stored on the linked list at that index.
-No free lists are managed for blocks greater than or equal to
-.Dv MEM_FREECOUNT
-bytes; instead, calls to
-.Xr malloc 3
-or
-.Xr free 3
-are made, directly.
-.Pp
-Since the blocks are actually stored as linked lists, they must at least
-be large enough to hold a pointer to the next block.  This size, which is
-.Dv SMALL_SIZE_LIMIT ,
-is currently defined as
-.Bd -literal -offset indent
-#define SMALL_SIZE_LIMIT sizeof(struct { void *next; })
-.Ed
-.Pp
-Both 
-.Fn memget
-and
-.Fn memput
-enforce this limit; for example, any call to 
-.Fn memget 
-requesting a block smaller than
-.Dv SMALL_SIZE_LIMIT
-bytes will actually be considered to be of size
-.Dv SMALL_SIZE_LIMIT 
-internally.  (Such a caller request will be logged for 
-.Fn memstats
-purposes using the caller-requested
-.Fa size ;
-see the discussion of
-.Fn memstats ,
-below, for more information.)
-.Pp
-Additionally, the requested
-.Fa size
-will be adjusted so that when a large 
-.Xr malloc 3 Ns No -d
-chunk of memory is broken up into a linked list, the blocks will all fall on
-the correct memory alignment boundaries.  Thus, one can conceptualize a call
-which mentions
-.Fa size
-as resulting in a
-.Fa new_size
-which is used internally.
-.Pp
-In order to more efficiently allocate memory, there is a 
-.Dq target
-size for calls to 
-.Xr malloc 3 .
-It is given by the pre-defined value
-.Dv MEM_TARGET , 
-which is currently 4096 bytes.
-For any requested block
-.Fa size ,
-enough memory is 
-.Xr malloc 3 Ns No -d
-in order to fill up a block of about
-.Dv MEM_TARGET
-bytes.  
-.No [ Ns Sy NOTE :
-For allocations larger than
-.Dv MEM_TARGET Ns No /2
-bytes, there is a 
-.Dq fudge factor
-introduced which boosts the target size by 25% of
-.Dv MEM_TARGET .
-This means that enough memory for two blocks
-will actually be allocated for any 
-.Fa size
-such that
-.Pq Dv MEM_TARGET Ns No / 3 
-.No < Fa size No < 
-.Pq Dv MEM_TARGET Ns No *5/8 ,
-provided that the value of
-.Dv MEM_FREECOUNT 
-is at least as large as the upper limit shown above.]
-.Pp
-.Ss FUNCTION DESCRIPTIONS
-.Pp
-The function
-.Fn memget
-returns a pointer to a block of memory of at least the requested
-.Fa size .
-After adjusting
-.Fa size
-to the value
-.Va new_size
-as mentioned above in the 
-.Sx INTERNALS
-subsection, the internal array of free lists is checked.
-If there is no block of the needed
-.Va new_size ,
-then
-.Fn memget 
-will 
-.Xr malloc 3
-a chunk of memory which is as many times as 
-.Va new_size
-will fit into the target size.  This memory is then turned into a linked list 
-of 
-.Va new_size Ns No -sized
-blocks which are given out as requested; the last such block is the first one 
-returned by 
-.Fn memget .
-If the requested
-.Fa size
-is zero or negative, then 
-.Dv NULL
-is returned and
-.Va errno
-is set to
-.Dv EINVAL ;
-if 
-.Fa size
-is larger than or equal to the pre-defined maximum size
-.Dv MEM_FREECOUNT ,
-then only a single block of exactly 
-.Fa size
-will be
-.Xr malloc 3 Ns No -d
-and returned.
-.Pp
-The
-.Fn memput
-call is used to return memory once the caller is finished with it.
-After adjusting
-.Fa size
-the the value
-.Va new_size
-as mentioned in the 
-.Sx INTERNALS 
-subsection, above, the block is placed at the head of the free list of 
-.Va new_size Ns -sized
-blocks.
-If the given
-.Fa size
-is zero or negative, then 
-.Va errno
-is set to
-.Dv EINVAL ,
-as for
-.Fn memget .
-If 
-.Fa size
-is larger than or equal to the pre-defined maximum size
-.Dv MEM_FREECOUNT ,
-then the block is immediately
-.Xr free 3 Ns No -d .
-.Pp
-.Sy NOTE :
-It is important that callers give 
-.Fn memput
-.Em only
-blocks of memory which were previously obtained from
-.Fn memget 
-if the block is 
-.Em actually 
-less than
-.Dv SMALL_SIZE_LIMIT
-bytes in size.  Since all blocks will be added to a free list, any block 
-which is not at least
-.Dv SMALL_SIZE_LIMIT
-bytes long will not be able to hold a pointer to the next block in the
-free list.
-.Pp
-The
-.Fn memstats
-function will summarize the number of calls to 
-.Fn memget
-and
-.Fn memput
-for any block size from 1 byte up to
-.Pq Dv MEM_FREECOUNT No - 1  
-bytes, followed by a single line for any calls using a 
-.Fa size
-greater than or equal to 
-.Dv MEM_FREECOUNT ; 
-a brief header with shell-style comment lines prefaces the report and
-explains the information.  The 
-.Dv FILE 
-pointer
-.Fa out
-identifies the stream which is used for this report.  Currently, 
-.Fn memstat
-reports the number of calls to 
-.Fn memget
-and
-.Fn memput
-using the caller-supplied value 
-.Fa size ; 
-the percentage of outstanding blocks of a given size (i.e., the percentage
-by which calls to
-.Fn memget
-exceed 
-.Fn memput )
-are also reported on the line for blocks of the given
-.Fa size .
-However, the percent of blocks used is computed using the number of 
-blocks allocated according to the internal parameter
-.Va new_size ;
-it is the percentage of blocks used to those available at a given
-.Va new_size ,
-and is computed using the
-.Em total
-number of caller 
-.Dq gets
-for any caller
-.Fa size Ns No -s
-which map to the internally-computed
-.Va new_size .
-Keep in mind that
-.Va new_size
-is generally 
-.Em not
-equal to
-.Fa size , 
-which has these implications:
-.Bl -enum -offset indent
-.It
-For
-.Fa size
-smaller than
-.Dv SMALL_SIZE_LIMIT ,
-.Fn memstat
-.Em will 
-show statistics for caller requests under
-.Fa size , 
-but "percent used" information about such blocks will be reported under
-.Dv SMALL_SIZE_LIMIT Ns No -sized
-blocks.  
-.It
-As a general case of point 1, internal statistics are reported on the the
-line corresponding to
-.Va new_size ,
-so that, for a given caller-supplied
-.Fa size ,
-the associated internal information will appear on that line or on the next
-line which shows "percent used" information.
-.El
-.Pp
-.Sy NOTE :
-If the caller returns blocks of a given
-.Fa size
-and requests others of 
-.Fa size Ns No -s 
-which map to the same internal
-.Va new_size ,
-it is possible for
-.Fn memstats
-to report usage of greater than 100% for blocks of size
-.Va new_size .
-This should be viewed as A Good Thing.
-.Sh RETURN VALUES
-The function
-.Fn memget
-returns a 
-.No non- Ns Dv NULL
-pointer to a block of memory of the requested
-.Fa size .
-It returns
-.Dv NULL
-if either the
-.Fa size
-is invalid (less than or equal to zero) or a 
-.Xr malloc 3
-of a new block of memory fails.  In the former case, 
-.Va errno
-is set to 
-.Dv EINVAL ; 
-in the latter, it is set to
-.Dv ENOMEM .
-.Pp
-Neither
-.Fn memput
-nor
-.Fn memstats
-return a value.
-.\" This next request is for sections 1, 6, 7 & 8 only
-.\" .Sh ENVIRONMENT
-.\" .Sh FILES
-.\" .Sh EXAMPLES
-.\" This next request is for sections 1, 6, 7 & 8 only
-.\"     (command return values (to shell) and
-.\"    fprintf/stderr type diagnostics)
-.\" .Sh DIAGNOSTICS
-.\" The next request is for sections 2 and 3 error
-.\" and signal handling only.
-.Sh ERRORS
-.Va errno
-is set as follows:
-.Bl -tag -width "ENOMEM  " -offset indent
-.It Dv EINVAL
-set by both
-.Fn memget
-and
-.Fn memput
-if the 
-.Fa size
-is zero or negative
-.It Dv ENOMEM
-set by 
-.Fn memget
-if a call to
-.Xr malloc 3
-fails
-.El
-.Sh SEE ALSO
-.Xr free 3 ,
-.Xr malloc 3 .
-.\" .Sh STANDARDS
-.\" .Sh HISTORY
-.Sh AUTHORS
-Steven J. Richardson and Paul Vixie, Vixie Enterprises.
-.\" .Sh BUGS
diff --git a/contrib/bind9/lib/bind/isc/movefile.c b/contrib/bind9/lib/bind/isc/movefile.c
deleted file mode 100644
index 191c46e..0000000
--- a/contrib/bind9/lib/bind/isc/movefile.c
+++ /dev/null
@@ -1,37 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 2000 by Internet Software Consortium, 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 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.
- */
-
-
-#include <port_before.h>
-#include <stdio.h>
-#include <isc/misc.h>
-#include <port_after.h>
-#ifndef HAVE_MOVEFILE
-/*
- * rename() is lame (can't overwrite an existing file) on some systems.
- * use movefile() instead, and let lame OS ports do what they need to.
- */
-
-int
-isc_movefile(const char *oldname, const char *newname) {
-	return (rename(oldname, newname));
-}
-#else
-	static int os_port_has_isc_movefile = 1;
-#endif
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/isc/tree.c b/contrib/bind9/lib/bind/isc/tree.c
deleted file mode 100644
index 5553636..0000000
--- a/contrib/bind9/lib/bind/isc/tree.c
+++ /dev/null
@@ -1,534 +0,0 @@
-#ifndef LINT
-static const char rcsid[] = "$Id: tree.c,v 1.3.18.1 2005/04/27 05:01:08 sra Exp $";
-#endif
-
-/*%
- * tree - balanced binary tree library
- *
- * vix 05apr94 [removed vixie.h dependencies; cleaned up formatting, names]
- * vix 22jan93 [revisited; uses RCS, ANSI, POSIX; has bug fixes]
- * vix 23jun86 [added delete uar to add for replaced nodes]
- * vix 20jun86 [added tree_delete per wirth a+ds (mod2 v.) p. 224]
- * vix 06feb86 [added tree_mung()]
- * vix 02feb86 [added tree balancing from wirth "a+ds=p" p. 220-221]
- * vix 14dec85 [written]
- */
-
-/*%
- * This program text was created by Paul Vixie using examples from the book:
- * "Algorithms & Data Structures," Niklaus Wirth, Prentice-Hall, 1986, ISBN
- * 0-13-022005-1.  Any errors in the conversion from Modula-2 to C are Paul
- * Vixie's.
- */
-
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-/*#define		DEBUG	"tree"*/
-
-#include "port_before.h"
-
-#include <stdio.h>
-#include <stdlib.h>
-
-#include "port_after.h"
-
-#include <isc/memcluster.h>
-#include <isc/tree.h>
-
-#ifdef DEBUG
-static int	debugDepth = 0;
-static char	*debugFuncs[256];
-# define ENTER(proc) { \
-			debugFuncs[debugDepth] = proc; \
-			fprintf(stderr, "ENTER(%d:%s.%s)\n", \
-				debugDepth, DEBUG, \
-				debugFuncs[debugDepth]); \
-			debugDepth++; \
-		}
-# define RET(value) { \
-			debugDepth--; \
-			fprintf(stderr, "RET(%d:%s.%s)\n", \
-				debugDepth, DEBUG, \
-				debugFuncs[debugDepth]); \
-			return (value); \
-		}
-# define RETV { \
-			debugDepth--; \
-			fprintf(stderr, "RETV(%d:%s.%s)\n", \
-				debugDepth, DEBUG, \
-				debugFuncs[debugDepth]); \
-			return; \
-		}
-# define MSG(msg)	fprintf(stderr, "MSG(%s)\n", msg);
-#else
-# define ENTER(proc)	;
-# define RET(value)	return (value);
-# define RETV		return;
-# define MSG(msg)	;
-#endif
-
-#ifndef TRUE
-# define TRUE		1
-# define FALSE		0
-#endif
-
-static tree *	sprout(tree **, tree_t, int *, int (*)(), void (*)());
-static int	delete(tree **, int (*)(), tree_t, void (*)(), int *, int *);
-static void	del(tree **, int *, tree **, void (*)(), int *);
-static void	bal_L(tree **, int *);
-static void	bal_R(tree **, int *);
-
-void
-tree_init(tree **ppr_tree) {
-	ENTER("tree_init")
-	*ppr_tree = NULL;
-	RETV
-}
-	
-tree_t
-tree_srch(tree **ppr_tree, int (*pfi_compare)(tree_t, tree_t), tree_t	p_user) {
-	ENTER("tree_srch")
-
-	if (*ppr_tree) {
-		int i_comp = (*pfi_compare)(p_user, (**ppr_tree).data);
-
-		if (i_comp > 0)
-			RET(tree_srch(&(**ppr_tree).right,
-				      pfi_compare,
-				      p_user))
-
-		if (i_comp < 0)
-			RET(tree_srch(&(**ppr_tree).left,
-				      pfi_compare,
-				      p_user))
-
-		/* not higher, not lower... this must be the one.
-		 */
-		RET((**ppr_tree).data)
-	}
-
-	/* grounded. NOT found.
-	 */
-	RET(NULL)
-}
-
-tree_t
-tree_add(tree **ppr_tree, int (*pfi_compare)(tree_t, tree_t),
-	 tree_t p_user, void (*pfv_uar)())
-{
-	int i_balance = FALSE;
-
-	ENTER("tree_add")
-	if (!sprout(ppr_tree, p_user, &i_balance, pfi_compare, pfv_uar))
-		RET(NULL)
-	RET(p_user)
-}
-
-int
-tree_delete(tree **ppr_p, int (*pfi_compare)(tree_t, tree_t),
-	    tree_t p_user, void	(*pfv_uar)())
-{
-	int i_balance = FALSE, i_uar_called = FALSE;
-
-	ENTER("tree_delete");
-	RET(delete(ppr_p, pfi_compare, p_user, pfv_uar,
-		   &i_balance, &i_uar_called))
-}
-
-int
-tree_trav(tree **ppr_tree, int (*pfi_uar)(tree_t)) {
-	ENTER("tree_trav")
-
-	if (!*ppr_tree)
-		RET(TRUE)
-
-	if (!tree_trav(&(**ppr_tree).left, pfi_uar))
-		RET(FALSE)
-	if (!(*pfi_uar)((**ppr_tree).data))
-		RET(FALSE)
-	if (!tree_trav(&(**ppr_tree).right, pfi_uar))
-		RET(FALSE)
-	RET(TRUE)
-}
-
-void
-tree_mung(tree **ppr_tree, void	(*pfv_uar)(tree_t)) {
-	ENTER("tree_mung")
-	if (*ppr_tree) {
-		tree_mung(&(**ppr_tree).left, pfv_uar);
-		tree_mung(&(**ppr_tree).right, pfv_uar);
-		if (pfv_uar)
-			(*pfv_uar)((**ppr_tree).data);
-		memput(*ppr_tree, sizeof(tree));
-		*ppr_tree = NULL;
-	}
-	RETV
-}
-
-static tree *
-sprout(tree **ppr, tree_t p_data, int *pi_balance,
-       int (*pfi_compare)(tree_t, tree_t), void (*pfv_delete)(tree_t))
-{
-	tree *p1, *p2, *sub;
-	int cmp;
-
-	ENTER("sprout")
-
-	/* are we grounded?  if so, add the node "here" and set the rebalance
-	 * flag, then exit.
-	 */
-	if (!*ppr) {
-		MSG("grounded. adding new node, setting h=true")
-		*ppr = (tree *) memget(sizeof(tree));
-		if (*ppr) {
-			(*ppr)->left = NULL;
-			(*ppr)->right = NULL;
-			(*ppr)->bal = 0;
-			(*ppr)->data = p_data;
-			*pi_balance = TRUE;
-		}
-		RET(*ppr);
-	}
-
-	/* compare the data using routine passed by caller.
-	 */
-	cmp = (*pfi_compare)(p_data, (*ppr)->data);
-
-	/* if LESS, prepare to move to the left.
-	 */
-	if (cmp < 0) {
-		MSG("LESS. sprouting left.")
-		sub = sprout(&(*ppr)->left, p_data, pi_balance,
-			     pfi_compare, pfv_delete);
-		if (sub && *pi_balance) {	/*%< left branch has grown */
-			MSG("LESS: left branch has grown")
-			switch ((*ppr)->bal) {
-			case 1:
-				/* right branch WAS longer; bal is ok now */
-				MSG("LESS: case 1.. bal restored implicitly")
-				(*ppr)->bal = 0;
-				*pi_balance = FALSE;
-				break;
-			case 0:
-				/* balance WAS okay; now left branch longer */
-				MSG("LESS: case 0.. balnce bad but still ok")
-				(*ppr)->bal = -1;
-				break;
-			case -1:
-				/* left branch was already too long. rebal */
-				MSG("LESS: case -1: rebalancing")
-				p1 = (*ppr)->left;
-				if (p1->bal == -1) {		/*%< LL */
-					MSG("LESS: single LL")
-					(*ppr)->left = p1->right;
-					p1->right = *ppr;
-					(*ppr)->bal = 0;
-					*ppr = p1;
-				} else {			/*%< double LR */
-					MSG("LESS: double LR")
-
-					p2 = p1->right;
-					p1->right = p2->left;
-					p2->left = p1;
-
-					(*ppr)->left = p2->right;
-					p2->right = *ppr;
-
-					if (p2->bal == -1)
-						(*ppr)->bal = 1;
-					else
-						(*ppr)->bal = 0;
-
-					if (p2->bal == 1)
-						p1->bal = -1;
-					else
-						p1->bal = 0;
-					*ppr = p2;
-				} /*else*/
-				(*ppr)->bal = 0;
-				*pi_balance = FALSE;
-			} /*switch*/
-		} /*if*/
-		RET(sub)
-	} /*if*/
-
-	/* if MORE, prepare to move to the right.
-	 */
-	if (cmp > 0) {
-		MSG("MORE: sprouting to the right")
-		sub = sprout(&(*ppr)->right, p_data, pi_balance,
-			     pfi_compare, pfv_delete);
-		if (sub && *pi_balance) {
-			MSG("MORE: right branch has grown")
-
-			switch ((*ppr)->bal) {
-			case -1:
-				MSG("MORE: balance was off, fixed implicitly")
-				(*ppr)->bal = 0;
-				*pi_balance = FALSE;
-				break;
-			case 0:
-				MSG("MORE: balance was okay, now off but ok")
-				(*ppr)->bal = 1;
-				break;
-			case 1:
-				MSG("MORE: balance was off, need to rebalance")
-				p1 = (*ppr)->right;
-				if (p1->bal == 1) {		/*%< RR */
-					MSG("MORE: single RR")
-					(*ppr)->right = p1->left;
-					p1->left = *ppr;
-					(*ppr)->bal = 0;
-					*ppr = p1;
-				} else {			/*%< double RL */
-					MSG("MORE: double RL")
-
-					p2 = p1->left;
-					p1->left = p2->right;
-					p2->right = p1;
-
-					(*ppr)->right = p2->left;
-					p2->left = *ppr;
-
-					if (p2->bal == 1)
-						(*ppr)->bal = -1;
-					else
-						(*ppr)->bal = 0;
-
-					if (p2->bal == -1)
-						p1->bal = 1;
-					else
-						p1->bal = 0;
-
-					*ppr = p2;
-				} /*else*/
-				(*ppr)->bal = 0;
-				*pi_balance = FALSE;
-			} /*switch*/
-		} /*if*/
-		RET(sub)
-	} /*if*/
-
-	/* not less, not more: this is the same key!  replace...
-	 */
-	MSG("FOUND: Replacing data value")
-	*pi_balance = FALSE;
-	if (pfv_delete)
-		(*pfv_delete)((*ppr)->data);
-	(*ppr)->data = p_data;
-	RET(*ppr)
-}
-
-static int
-delete(tree **ppr_p, int (*pfi_compare)(tree_t, tree_t), tree_t p_user,
-       void (*pfv_uar)(tree_t), int *pi_balance, int *pi_uar_called)
-{
-	tree *pr_q;
-	int i_comp, i_ret;
-
-	ENTER("delete")
-
-	if (*ppr_p == NULL) {
-		MSG("key not in tree")
-		RET(FALSE)
-	}
-
-	i_comp = (*pfi_compare)((*ppr_p)->data, p_user);
-	if (i_comp > 0) {
-		MSG("too high - scan left")
-		i_ret = delete(&(*ppr_p)->left, pfi_compare, p_user, pfv_uar,
-			       pi_balance, pi_uar_called);
-		if (*pi_balance)
-			bal_L(ppr_p, pi_balance);
-	} else if (i_comp < 0) {
-		MSG("too low - scan right")
-		i_ret = delete(&(*ppr_p)->right, pfi_compare, p_user, pfv_uar,
-			       pi_balance, pi_uar_called);
-		if (*pi_balance)
-			bal_R(ppr_p, pi_balance);
-	} else {
-		MSG("equal")
-		pr_q = *ppr_p;
-		if (pr_q->right == NULL) {
-			MSG("right subtree null")
-			*ppr_p = pr_q->left;
-			*pi_balance = TRUE;
-		} else if (pr_q->left == NULL) {
-			MSG("right subtree non-null, left subtree null")
-			*ppr_p = pr_q->right;
-			*pi_balance = TRUE;
-		} else {
-			MSG("neither subtree null")
-			del(&pr_q->left, pi_balance, &pr_q,
-			    pfv_uar, pi_uar_called);
-			if (*pi_balance)
-				bal_L(ppr_p, pi_balance);
-		}
-		if (!*pi_uar_called && pfv_uar)
-			(*pfv_uar)(pr_q->data);
-		/* Thanks to wuth@castrov.cuc.ab.ca for the following stmt. */
-		memput(pr_q, sizeof(tree));
-		i_ret = TRUE;
-	}
-	RET(i_ret)
-}
-
-static void
-del(tree **ppr_r, int *pi_balance, tree **ppr_q,
-    void (*pfv_uar)(tree_t), int *pi_uar_called)
-{
-	ENTER("del")
-
-	if ((*ppr_r)->right != NULL) {
-		del(&(*ppr_r)->right, pi_balance, ppr_q,
-		    pfv_uar, pi_uar_called);
-		if (*pi_balance)
-			bal_R(ppr_r, pi_balance);
-	} else {
-		if (pfv_uar)
-			(*pfv_uar)((*ppr_q)->data);
-		*pi_uar_called = TRUE;
-		(*ppr_q)->data = (*ppr_r)->data;
-		*ppr_q = *ppr_r;
-		*ppr_r = (*ppr_r)->left;
-		*pi_balance = TRUE;
-	}
-
-	RETV
-}
-
-static void
-bal_L(tree **ppr_p, int *pi_balance) {
-	tree *p1, *p2;
-	int b1, b2;
-
-	ENTER("bal_L")
-	MSG("left branch has shrunk")
-
-	switch ((*ppr_p)->bal) {
-	case -1:
-		MSG("was imbalanced, fixed implicitly")
-		(*ppr_p)->bal = 0;
-		break;
-	case 0:
-		MSG("was okay, is now one off")
-		(*ppr_p)->bal = 1;
-		*pi_balance = FALSE;
-		break;
-	case 1:
-		MSG("was already off, this is too much")
-		p1 = (*ppr_p)->right;
-		b1 = p1->bal;
-		if (b1 >= 0) {
-			MSG("single RR")
-			(*ppr_p)->right = p1->left;
-			p1->left = *ppr_p;
-			if (b1 == 0) {
-				MSG("b1 == 0")
-				(*ppr_p)->bal = 1;
-				p1->bal = -1;
-				*pi_balance = FALSE;
-			} else {
-				MSG("b1 != 0")
-				(*ppr_p)->bal = 0;
-				p1->bal = 0;
-			}
-			*ppr_p = p1;
-		} else {
-			MSG("double RL")
-			p2 = p1->left;
-			b2 = p2->bal;
-			p1->left = p2->right;
-			p2->right = p1;
-			(*ppr_p)->right = p2->left;
-			p2->left = *ppr_p;
-			if (b2 == 1)
-				(*ppr_p)->bal = -1;
-			else
-				(*ppr_p)->bal = 0;
-			if (b2 == -1)
-				p1->bal = 1;
-			else
-				p1->bal = 0;
-			*ppr_p = p2;
-			p2->bal = 0;
-		}
-	}
-	RETV
-}
-
-static void
-bal_R(tree **ppr_p, int *pi_balance) {
-	tree *p1, *p2;
-	int b1, b2;
-
-	ENTER("bal_R")
-	MSG("right branch has shrunk")
-	switch ((*ppr_p)->bal) {
-	case 1:
-		MSG("was imbalanced, fixed implicitly")
-		(*ppr_p)->bal = 0;
-		break;
-	case 0:
-		MSG("was okay, is now one off")
-		(*ppr_p)->bal = -1;
-		*pi_balance = FALSE;
-		break;
-	case -1:
-		MSG("was already off, this is too much")
-		p1 = (*ppr_p)->left;
-		b1 = p1->bal;
-		if (b1 <= 0) {
-			MSG("single LL")
-			(*ppr_p)->left = p1->right;
-			p1->right = *ppr_p;
-			if (b1 == 0) {
-				MSG("b1 == 0")
-				(*ppr_p)->bal = -1;
-				p1->bal = 1;
-				*pi_balance = FALSE;
-			} else {
-				MSG("b1 != 0")
-				(*ppr_p)->bal = 0;
-				p1->bal = 0;
-			}
-			*ppr_p = p1;
-		} else {
-			MSG("double LR")
-			p2 = p1->right;
-			b2 = p2->bal;
-			p1->right = p2->left;
-			p2->left = p1;
-			(*ppr_p)->left = p2->right;
-			p2->right = *ppr_p;
-			if (b2 == -1)
-				(*ppr_p)->bal = 1;
-			else
-				(*ppr_p)->bal = 0;
-			if (b2 == 1)
-				p1->bal = -1;
-			else
-				p1->bal = 0;
-			*ppr_p = p2;
-			p2->bal = 0;
-		}
-	}
-	RETV
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/isc/tree.mdoc b/contrib/bind9/lib/bind/isc/tree.mdoc
deleted file mode 100644
index 2c24e1f..0000000
--- a/contrib/bind9/lib/bind/isc/tree.mdoc
+++ /dev/null
@@ -1,154 +0,0 @@
-.\" $Id: tree.mdoc,v 1.3 2004/03/09 06:30:09 marka Exp $
-.\"
-.\" Copyright (c) 2004 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
-.\" 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.
-.\"
-.Dd April 5, 1994
-.Dt TREE 3
-.Os BSD 4
-.Sh NAME
-.Nm tree_init ,
-.Nm tree_mung ,
-.Nm tree_srch ,
-.Nm tree_add ,
-.Nm tree_delete ,
-.Nm tree_trav
-.Nd balanced binary tree routines
-.Sh SYNOPSIS
-.Ft void
-.Fn tree_init "void **tree"
-.Ft void *
-.Fn tree_srch "void **tree" "int (*compare)()" "void *data"
-.Ft void
-.Fn tree_add "void **tree" "int (*compare)()" \
-"void *data" "void (*del_uar)()"
-.Ft int
-.Fn tree_delete "void **tree" "int (*compare)()" \
-"void *data" "void (*del_uar)()"
-.Ft int
-.Fn tree_trav "void **tree" "int (*trav_uar)()"
-.Ft void
-.Fn tree_mung "void **tree" "void (*del_uar)()"
-.Sh DESCRIPTION
-These functions create and manipulate a balanced binary (AVL) tree.  Each node
-of the tree contains the expected left & right subtree pointers, a short int
-balance indicator, and a pointer to the user data.  On a 32 bit system, this
-means an overhead of 4+4+2+4 bytes per node (or, on a RISC or otherwise
-alignment constrained system with implied padding, 4+4+4+4 bytes per node).
-There is no key data type enforced by this package; a caller supplied
-compare routine is used to compare user data blocks.
-.Pp
-Balanced binary trees are very fast on searches and replacements, but have a
-moderately high cost for additions and deletions.  If your application does a
-lot more searches and replacements than it does additions and deletions, the
-balanced (AVL) binary tree is a good choice for a data structure.
-.Pp
-.Fn Tree_init
-creates an empty tree and binds it to
-.Dq Fa tree
-(which for this and all other routines in this package should be declared as
-a pointer to void or int, and passed by reference), which can then be used by
-other routines in this package.  Note that more than one
-.Dq Fa tree
-variable can exist at once; thus multiple trees can be manipulated
-simultaneously.
-.Pp
-.Fn Tree_srch
-searches a tree for a specific node and returns either
-.Fa NULL
-if no node was found, or the value of the user data pointer if the node
-was found.
-.Fn compare
-is the address of a function to compare two user data blocks.  This routine
-should work much the way 
-.Xr strcmp 3
-does; in fact,
-.Xr strcmp
-could be used if the user data was a \s-2NUL\s+2 terminated string.
-.Dq Fa Data
-is the address of a user data block to be used by
-.Fn compare
-as the search criteria.  The tree is searched for a node where
-.Fn compare
-returns 0.
-.Pp
-.Fn Tree_add
-inserts or replaces a node in the specified tree.  The tree specified by
-.Dq Fa tree
-is searched as in
-.Fn tree_srch ,
-and if a node is found to match
-.Dq Fa data ,
-then the
-.Fn del_uar
-function, if non\-\s-2NULL\s+2, is called with the address of the user data
-block for the node (this routine should deallocate any dynamic memory which
-is referenced exclusively by the node); the user data pointer for the node
-is then replaced by the value of
-.Dq Fa data .
-If no node is found to match, a new node is added (which may or may not
-cause a transparent rebalance operation), with a user data pointer equal to
-.Dq Fa data .
-A rebalance may or may not occur, depending on where the node is added
-and what the rest of the tree looks like.
-.Fn Tree_add
-will return the
-.Dq Fa data
-pointer unless catastrophe occurs in which case it will return \s-2NULL\s+2.
-.Pp
-.Fn Tree_delete
-deletes a node from
-.Dq Fa tree .
-A rebalance may or may not occur, depending on where the node is removed from
-and what the rest of the tree looks like.
-.Fn Tree_delete
-returns TRUE if a node was deleted, FALSE otherwise.
-.Pp
-.Fn Tree_trav
-traverses all of
-.Dq Fa tree ,
-calling
-.Fn trav_uar
-with the address of each user data block.  If
-.Fn trav_uar
-returns FALSE at any time,
-.Fn tree_trav
-will immediately return FALSE to its caller.  Otherwise all nodes will be 
-reached and
-.Fn tree_trav
-will return TRUE.
-.Pp
-.Fn Tree_mung
-deletes every node in
-.Dq Fa tree ,
-calling
-.Fn del_uar
-(if it is not \s-2NULL\s+2) with the user data address from each node (see
-.Fn tree_add
-and
-.Fn tree_delete
-above).  The tree is left in the same state that
-.Fn tree_init
-leaves it in \- i.e., empty.
-.Sh BUGS
-Should have a way for the caller to specify application-specific
-.Xr malloc
-and
-.Xr free
-functions to be used internally when allocating meta data.
-.Sh AUTHOR
-Paul Vixie, converted and augumented from Modula\-2 examples in
-.Dq Algorithms & Data Structures ,
-Niklaus Wirth, Prentice\-Hall, ISBN 0\-13\-022005\-1.
diff --git a/contrib/bind9/lib/bind/make/includes.in b/contrib/bind9/lib/bind/make/includes.in
deleted file mode 100644
index d7e21cb..0000000
--- a/contrib/bind9/lib/bind/make/includes.in
+++ /dev/null
@@ -1,44 +0,0 @@
-# Copyright (C) 2004  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,
-# 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: includes.in,v 1.2 2004/03/16 05:22:19 marka Exp $
-
-# Search for machine-generated header files in the build tree,
-# and for normal headers in the source tree (${top_srcdir}).
-# We only need to look in OS-specific subdirectories for the
-# latter case, because there are no machine-generated OS-specific
-# headers.
-
-ISC_INCLUDES = @BIND9_ISC_BUILDINCLUDE@ \
-	-I${top_srcdir}/lib/isc \
-	-I${top_srcdir}/lib/isc/include \
-	-I${top_srcdir}/lib/isc/unix/include \
-	-I${top_srcdir}/lib/isc/@ISC_THREAD_DIR@/include
-
-ISCCFG_INCLUDES = @BIND9_ISCCFG_BUILDINCLUDE@ \
-       -I${top_srcdir}/lib/isccfg/include
-
-DNS_INCLUDES = @BIND9_DNS_BUILDINCLUDE@ \
-	-I${top_srcdir}/lib/dns/include \
-	-I${top_srcdir}/lib/dns/sec/dst/include
-
-OMAPI_INCLUDES = @BIND9_OMAPI_BUILDINCLUDE@ \
-	-I${top_srcdir}/lib/omapi/include
-
-LWRES_INCLUDES = @BIND9_LWRES_BUILDINCLUDE@ \
-	-I${top_srcdir}/lib/lwres/include
-
-TEST_INCLUDES = \
-	-I${top_srcdir}/lib/tests/include
diff --git a/contrib/bind9/lib/bind/make/mkdep.in b/contrib/bind9/lib/bind/make/mkdep.in
deleted file mode 100644
index 60aea6f..0000000
--- a/contrib/bind9/lib/bind/make/mkdep.in
+++ /dev/null
@@ -1,147 +0,0 @@
-#!/bin/sh -
-
-## ++Copyright++ 1987
-## -
-## Copyright (c) 1987 Regents of the University of California.
-## All rights reserved.
-##
-## Redistribution and use in source and binary forms, with or without
-## modification, are permitted provided that the following conditions
-## are met:
-## 1. Redistributions of source code must retain the above copyright
-##    notice, this list of conditions and the following disclaimer.
-## 2. Redistributions in binary form must reproduce the above copyright
-##    notice, this list of conditions and the following disclaimer in the
-##    documentation and/or other materials provided with the distribution.
-## 3. All advertising materials mentioning features or use of this software
-##    must display the following acknowledgement:
-## This product includes software developed by the University of
-## California, Berkeley and its contributors.
-## 4. Neither the name of the University nor the names of its contributors
-##    may be used to endorse or promote products derived from this software
-##    without specific prior written permission.
-## THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
-## ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-## IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-## ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
-## FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-## DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-## OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-## HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-## LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-## OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-## SUCH DAMAGE.
-## -
-## Portions Copyright (c) 1993 by Digital Equipment Corporation.
-##
-## 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, and that
-## the name of Digital Equipment Corporation not be used in advertising or
-## publicity pertaining to distribution of the document or software without
-## specific, written prior permission.
-##
-## THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
-## WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
-## OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
-## CORPORATION 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.
-## -
-## --Copyright--
-
-#
-#	@(#)mkdep.sh	5.12 (Berkeley) 6/30/88
-#
-
-MAKE=Makefile			# default makefile name is "Makefile"
-
-while :
-	do case "$1" in
-		# -f allows you to select a makefile name
-		-f)
-			MAKE=$2
-			shift; shift ;;
-
-		# the -p flag produces "program: program.c" style dependencies
-		# so .o's don't get produced
-		-p)
-			SED='s;\.o;;'
-			shift ;;
-		*)
-			break ;;
-	esac
-done
-
-if [ $# = 0 ] ; then
-	echo 'usage: mkdep [-p] [-f makefile] [flags] file ...'
-	exit 1
-fi
-
-if [ ! -w $MAKE ]; then
-	echo "mkdep: no writeable file \"$MAKE\""
-	exit 1
-fi
-
-TMP=mkdep$$
-
-trap 'rm -f $TMP ; exit 1' 1 2 3 13 15
-
-cp $MAKE ${MAKE}.bak
-
-sed -e '/DO NOT DELETE THIS LINE/,$d' < $MAKE > $TMP
-
-cat << _EOF_ >> $TMP
-# DO NOT DELETE THIS LINE -- mkdep uses it.
-# DO NOT PUT ANYTHING AFTER THIS LINE, IT WILL GO AWAY.
-
-_EOF_
-
-# If your compiler doesn't have -M, add it.  If you can't, the next two
-# lines will try and replace the "cc -M".  The real problem is that this
-# hack can't deal with anything that requires a search path, and doesn't
-# even try for anything using bracket (<>) syntax.
-#
-# egrep '^#include[ 	]*".*"' /dev/null $* |
-# sed -e 's/:[^"]*"\([^"]*\)".*/: \1/' -e 's/\.c/.o/' |
-
-MKDEPPROG="@MKDEPPROG@"
-if [ X"${MKDEPPROG}" != X ]; then
-    @SHELL@ -c "${MKDEPPROG} $*"
-else
-    @MKDEPCC@ @MKDEPCFLAGS@ $* |
-    sed "
-	s; \./; ;g
-	$SED" |
-    awk '{
-	if ($1 != prev) {
-		if (rec != "")
-			print rec;
-		rec = $0;
-		prev = $1;
-	}
-	else {
-		if (length(rec $2) > 78) {
-			print rec;
-			rec = $0;
-		}
-		else
-			rec = rec " " $2
-	}
-    }
-    END {
-	print rec
-    }' >> $TMP
-fi
-
-cat << _EOF_ >> $TMP
-
-# IF YOU PUT ANYTHING HERE IT WILL GO AWAY
-_EOF_
-
-# copy to preserve permissions
-cp $TMP $MAKE
-rm -f ${MAKE}.bak $TMP
-exit 0
diff --git a/contrib/bind9/lib/bind/make/rules.in b/contrib/bind9/lib/bind/make/rules.in
deleted file mode 100644
index 5033b15..0000000
--- a/contrib/bind9/lib/bind/make/rules.in
+++ /dev/null
@@ -1,177 +0,0 @@
-# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
-# Copyright (C) 2001, 2002  Internet Software Consortium.
-#
-# Permission to use, copy, modify, and/or 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: rules.in,v 1.9.18.4 2007/08/28 07:20:04 tbox Exp $
-
-###
-### Common Makefile rules for BIND 9.
-###
-
-###
-### Paths
-###
-### Note: paths that vary by Makefile MUST NOT be listed
-### here, or they won't get expanded correctly.
-
-prefix =	@prefix@
-exec_prefix =	@exec_prefix@
-bindir =	@bindir@
-sbindir =	@sbindir@
-includedir =	@includedir@
-libdir =	@libdir@
-sysconfdir =	@sysconfdir@
-localstatedir =	@localstatedir@
-mandir =	@mandir@
-
-DESTDIR =
-MAKEDEFS= 'DESTDIR=${DESTDIR}'
-
-@SET_MAKE@
-
-top_builddir =	@BIND9_TOP_BUILDDIR@
-abs_top_srcdir = @abs_top_srcdir@
-
-###
-### All
-###
-### Makefile may define:
-###	TARGETS
-
-all: subdirs ${TARGETS}
-
-###
-### Subdirectories
-###
-### Makefile may define:
-###	SUBDIRS
-
-ALL_SUBDIRS = ${SUBDIRS} nulldir
-
-#
-# We use a single-colon rule so that additional dependencies of
-# subdirectories can be specified after the inclusion of this file.
-# The "depend" target is treated the same way.
-#
-subdirs:
-	@for i in ${ALL_SUBDIRS}; do \
-		if [ "$$i" != "nulldir" -a -d $$i ]; then \
-			echo "making all in `pwd`/$$i"; \
-			(cd $$i; ${MAKE} ${MAKEDEFS} all) || exit 1; \
-		fi; \
-	done
-
-install clean distclean docclean manclean::
-	@for i in ${ALL_SUBDIRS}; do \
-		if [ "$$i" != "nulldir" -a -d $$i ]; then \
-			echo "making $@ in `pwd`/$$i"; \
-			(cd $$i; ${MAKE} ${MAKEDEFS} $@) || exit 1; \
-		fi \
-	done
-
-###
-### C Programs
-###
-### Makefile must define
-###	CC
-### Makefile may define
-###	CFLAGS
-###	CINCLUDES
-###	CDEFINES
-###	CWARNINGS
-### User may define externally
-###     EXT_CFLAGS
-
-CC = 		@CC@
-CFLAGS =	@CFLAGS@
-STD_CINCLUDES =	@STD_CINCLUDES@
-STD_CDEFINES =	@STD_CDEFINES@
-STD_CWARNINGS =	@STD_CWARNINGS@
-
-.SUFFIXES:
-.SUFFIXES: .c .@O@
-
-ALWAYS_INCLUDES = -I${top_builddir} -I${abs_top_srcdir}/@PORT_INCLUDE@
-ALWAYS_DEFINES = @ALWAYS_DEFINES@
-ALWAYS_WARNINGS =
-
-ALL_CPPFLAGS = \
-	${ALWAYS_INCLUDES} ${CINCLUDES} ${STD_CINCLUDES} \
-	${ALWAYS_DEFINES} ${CDEFINES} ${STD_CDEFINES}
-
-ALL_CFLAGS = ${EXT_CFLAGS} ${CFLAGS} \
-	${ALL_CPPFLAGS} \
-	${ALWAYS_WARNINGS} ${STD_CWARNINGS} ${CWARNINGS}
-
-.c.@O@:
-	${LIBTOOL_MODE_COMPILE} ${CC} ${ALL_CFLAGS} -c $<
-
-SHELL = @SHELL@
-LIBTOOL = @LIBTOOL@
-LIBTOOL_MODE_COMPILE = ${LIBTOOL} @LIBTOOL_MODE_COMPILE@
-LIBTOOL_MODE_INSTALL = ${LIBTOOL} @LIBTOOL_MODE_INSTALL@
-LIBTOOL_MODE_LINK = ${LIBTOOL} @LIBTOOL_MODE_LINK@
-PURIFY = @PURIFY@
-
-MKDEP = ${SHELL} ${top_builddir}/make/mkdep
-
-cleandir: distclean
-
-clean distclean::
-	rm -f *.@O@ *.lo *.la core *.core .depend
-	rm -rf .libs
-
-distclean::
-	rm -f Makefile
-
-depend:
-	@for i in ${ALL_SUBDIRS}; do \
-		if [ "$$i" != "nulldir" -a -d $$i ]; then \
-			echo "making depend in `pwd`/$$i"; \
-			(cd $$i; ${MAKE} ${MAKEDEFS} $@) || exit 1; \
-		fi \
-	done
-	@if [ X"${SRCS}" != X -a X"${PSRCS}" != X ] ; then \
-		echo ${MKDEP} ${ALL_CPPFLAGS} ${SRCS}; \
-		${MKDEP} ${ALL_CPPFLAGS} ${SRCS}; \
-		echo ${MKDEP} -ap ${ALL_CPPFLAGS} ${PSRCS}; \
-		${MKDEP} -ap ${ALL_CPPFLAGS} ${PSRCS}; \
-		${DEPENDEXTRA} \
-	elif [ X"${SRCS}" != X ] ; then \
-		echo ${MKDEP} ${ALL_CPPFLAGS} ${SRCS}; \
-		${MKDEP} ${ALL_CPPFLAGS} ${SRCS}; \
-		${DEPENDEXTRA} \
-	elif [ X"${PSRCS}" != X ] ; then \
-		echo ${MKDEP} ${ALL_CPPFLAGS} ${PSRCS}; \
-		${MKDEP} -p ${ALL_CPPFLAGS} ${PSRCS}; \
-		${DEPENDEXTRA} \
-	fi
-
-FORCE:
-
-###
-### Libraries
-###
-
-AR =		@AR@
-ARFLAGS =	@ARFLAGS@
-RANLIB =	@RANLIB@
-
-###
-### Installation
-###
-
-INSTALL =		@INSTALL@
-INSTALL_PROGRAM =	@INSTALL_PROGRAM@
-INSTALL_DATA =		@INSTALL_DATA@
diff --git a/contrib/bind9/lib/bind/mkinstalldirs b/contrib/bind9/lib/bind/mkinstalldirs
deleted file mode 100755
index 74a611a..0000000
--- a/contrib/bind9/lib/bind/mkinstalldirs
+++ /dev/null
@@ -1,40 +0,0 @@
-#! /bin/sh
-# mkinstalldirs --- make directory hierarchy
-# Author: Noah Friedman <friedman@prep.ai.mit.edu>
-# Created: 1993-05-16
-# Public domain
-
-# $Id: mkinstalldirs,v 1.1 2001/07/06 22:23:42 gson Exp $
-
-errstatus=0
-
-for file
-do
-   set fnord `echo ":$file" | sed -ne 's/^:\//#/;s/^://;s/\// /g;s/^#/\//;p'`
-   shift
-
-   pathcomp=
-   for d
-   do
-     pathcomp="$pathcomp$d"
-     case "$pathcomp" in
-       -* ) pathcomp=./$pathcomp ;;
-     esac
-
-     if test ! -d "$pathcomp"; then
-        echo "mkdir $pathcomp" 1>&2
-
-        mkdir "$pathcomp" || lasterr=$?
-
-        if test ! -d "$pathcomp"; then
-  	  errstatus=$lasterr
-        fi
-     fi
-
-     pathcomp="$pathcomp/"
-   done
-done
-
-exit $errstatus
-
-# mkinstalldirs ends here
diff --git a/contrib/bind9/lib/bind/nameser/Makefile.in b/contrib/bind9/lib/bind/nameser/Makefile.in
deleted file mode 100644
index fcb7ed7..0000000
--- a/contrib/bind9/lib/bind/nameser/Makefile.in
+++ /dev/null
@@ -1,31 +0,0 @@
-# Copyright (C) 2004, 2008  Internet Systems Consortium, Inc. ("ISC")
-# Copyright (C) 2001  Internet Software Consortium.
-#
-# Permission to use, copy, modify, and/or 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: Makefile.in,v 1.5.18.2 2008/03/20 23:46:01 tbox Exp $
-
-srcdir=		@srcdir@
-VPATH =         @srcdir@
-
-OBJS=	ns_date.@O@ ns_name.@O@ ns_netint.@O@ ns_parse.@O@ ns_print.@O@ \
-	ns_samedomain.@O@ ns_sign.@O@ ns_ttl.@O@ ns_verify.@O@
-
-SRCS=	ns_date.c ns_name.c ns_netint.c ns_parse.c ns_print.c \
-	ns_samedomain.c ns_sign.c ns_ttl.c ns_verify.c
-
-TARGETS= ${OBJS}
-
-CINCLUDES= -I.. -I../include -I${srcdir}/../include
-
-@BIND9_MAKE_RULES@
diff --git a/contrib/bind9/lib/bind/nameser/ns_date.c b/contrib/bind9/lib/bind/nameser/ns_date.c
deleted file mode 100644
index af1455c..0000000
--- a/contrib/bind9/lib/bind/nameser/ns_date.c
+++ /dev/null
@@ -1,129 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1999 by 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.
- */
-
-#ifndef lint
-static const char rcsid[] = "$Id: ns_date.c,v 1.5.18.1 2005/04/27 05:01:08 sra Exp $";
-#endif
-
-/* Import. */
-
-#include "port_before.h"
-
-#include <arpa/nameser.h>
-
-#include <ctype.h>
-#include <errno.h>
-#include <stdio.h>
-#include <string.h>
-#include <time.h>
-
-#include "port_after.h"
-
-#ifdef SPRINTF_CHAR
-# define SPRINTF(x) strlen(sprintf/**/x)
-#else
-# define SPRINTF(x) ((size_t)sprintf x)
-#endif
-
-/* Forward. */
-
-static int	datepart(const char *, int, int, int, int *);
-
-/* Public. */
-
-/*%
- * Convert a date in ASCII into the number of seconds since
- * 1 January 1970 (GMT assumed).  Format is yyyymmddhhmmss, all
- * digits required, no spaces allowed.
- */
-
-u_int32_t
-ns_datetosecs(const char *cp, int *errp) {
-	struct tm time;
-	u_int32_t result;
-	int mdays, i;
-	static const int days_per_month[12] =
-		{31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31};
-
-	if (strlen(cp) != 14U) {
-		*errp = 1;
-		return (0);
-	}
-	*errp = 0;
-
-	memset(&time, 0, sizeof time);
-	time.tm_year  = datepart(cp +  0, 4, 1990, 9999, errp) - 1900;
-	time.tm_mon   = datepart(cp +  4, 2,   01,   12, errp) - 1;
-	time.tm_mday  = datepart(cp +  6, 2,   01,   31, errp);
-	time.tm_hour  = datepart(cp +  8, 2,   00,   23, errp);
-	time.tm_min   = datepart(cp + 10, 2,   00,   59, errp);
-	time.tm_sec   = datepart(cp + 12, 2,   00,   59, errp);
-	if (*errp)		/*%< Any parse errors? */
-		return (0);
-
-	/* 
-	 * OK, now because timegm() is not available in all environments,
-	 * we will do it by hand.  Roll up sleeves, curse the gods, begin!
-	 */
-
-#define SECS_PER_DAY    ((u_int32_t)24*60*60)
-#define isleap(y) ((((y) % 4) == 0 && ((y) % 100) != 0) || ((y) % 400) == 0)
-
-	result  = time.tm_sec;				/*%< Seconds */
-	result += time.tm_min * 60;			/*%< Minutes */
-	result += time.tm_hour * (60*60);		/*%< Hours */
-	result += (time.tm_mday - 1) * SECS_PER_DAY;	/*%< Days */
-	/* Months are trickier.  Look without leaping, then leap */
-	mdays = 0;
-	for (i = 0; i < time.tm_mon; i++)
-		mdays += days_per_month[i];
-	result += mdays * SECS_PER_DAY;			/*%< Months */
-	if (time.tm_mon > 1 && isleap(1900+time.tm_year))
-		result += SECS_PER_DAY;		/*%< Add leapday for this year */
-	/* First figure years without leapdays, then add them in.  */
-	/* The loop is slow, FIXME, but simple and accurate.  */
-	result += (time.tm_year - 70) * (SECS_PER_DAY*365); /*%< Years */
-	for (i = 70; i < time.tm_year; i++)
-		if (isleap(1900+i))
-			result += SECS_PER_DAY; /*%< Add leapday for prev year */
-	return (result);
-}
-
-/* Private. */
-
-/*%
- * Parse part of a date.  Set error flag if any error.
- * Don't reset the flag if there is no error.
- */
-static int
-datepart(const char *buf, int size, int min, int max, int *errp) {
-	int result = 0;
-	int i;
-
-	for (i = 0; i < size; i++) {
-		if (!isdigit((unsigned char)(buf[i])))
-			*errp = 1;
-		result = (result * 10) + buf[i] - '0';
-	}
-	if (result < min)
-		*errp = 1;
-	if (result > max)
-		*errp = 1;
-	return (result);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/nameser/ns_name.c b/contrib/bind9/lib/bind/nameser/ns_name.c
deleted file mode 100644
index 31dee36..0000000
--- a/contrib/bind9/lib/bind/nameser/ns_name.c
+++ /dev/null
@@ -1,973 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#ifndef lint
-static const char rcsid[] = "$Id: ns_name.c,v 1.8.18.2 2005/04/27 05:01:08 sra Exp $";
-#endif
-
-#include "port_before.h"
-
-#include <sys/types.h>
-
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-
-#include <errno.h>
-#include <resolv.h>
-#include <string.h>
-#include <ctype.h>
-#include <stdlib.h>
-#include <limits.h>
-
-#include "port_after.h"
-
-#ifdef SPRINTF_CHAR
-# define SPRINTF(x) strlen(sprintf/**/x)
-#else
-# define SPRINTF(x) ((size_t)sprintf x)
-#endif
-
-#define NS_TYPE_ELT			0x40 /*%< EDNS0 extended label type */
-#define DNS_LABELTYPE_BITSTRING		0x41
-
-/* Data. */
-
-static const char	digits[] = "0123456789";
-
-static const char digitvalue[256] = {
-	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,	/*16*/
-	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, /*32*/
-	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, /*48*/
-	 0,  1,  2,  3,  4,  5,  6,  7,  8,  9, -1, -1, -1, -1, -1, -1, /*64*/
-	-1, 10, 11, 12, 13, 14, 15, -1, -1, -1, -1, -1, -1, -1, -1, -1, /*80*/
-	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, /*96*/
-	-1, 10, 11, 12, 13, 14, 15, -1, -1, -1, -1, -1, -1, -1, -1, -1, /*112*/
-	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, /*128*/
-	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-	-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, /*256*/
-};
-
-/* Forward. */
-
-static int		special(int);
-static int		printable(int);
-static int		dn_find(const u_char *, const u_char *,
-				const u_char * const *,
-				const u_char * const *);
-static int		encode_bitsring(const char **, const char *,
-					unsigned char **, unsigned char **,
-					unsigned const char *);
-static int		labellen(const u_char *);
-static int		decode_bitstring(const unsigned char **,
-					 char *, const char *);
-
-/* Public. */
-
-/*%
- *	Convert an encoded domain name to printable ascii as per RFC1035.
-
- * return:
- *\li	Number of bytes written to buffer, or -1 (with errno set)
- *
- * notes:
- *\li	The root is returned as "."
- *\li	All other domains are returned in non absolute form
- */
-int
-ns_name_ntop(const u_char *src, char *dst, size_t dstsiz)
-{
-	const u_char *cp;
-	char *dn, *eom;
-	u_char c;
-	u_int n;
-	int l;
-
-	cp = src;
-	dn = dst;
-	eom = dst + dstsiz;
-
-	while ((n = *cp++) != 0) {
-		if ((n & NS_CMPRSFLGS) == NS_CMPRSFLGS) {
-			/* Some kind of compression pointer. */
-			errno = EMSGSIZE;
-			return (-1);
-		}
-		if (dn != dst) {
-			if (dn >= eom) {
-				errno = EMSGSIZE;
-				return (-1);
-			}
-			*dn++ = '.';
-		}
-		if ((l = labellen(cp - 1)) < 0) {
-			errno = EMSGSIZE; /*%< XXX */
-			return(-1);
-		}
-		if (dn + l >= eom) {
-			errno = EMSGSIZE;
-			return (-1);
-		}
-		if ((n & NS_CMPRSFLGS) == NS_TYPE_ELT) {
-			int m;
-
-			if (n != DNS_LABELTYPE_BITSTRING) {
-				/* XXX: labellen should reject this case */
-				errno = EINVAL;
-				return(-1);
-			}
-			if ((m = decode_bitstring(&cp, dn, eom)) < 0)
-			{
-				errno = EMSGSIZE;
-				return(-1);
-			}
-			dn += m; 
-			continue;
-		}
-		for ((void)NULL; l > 0; l--) {
-			c = *cp++;
-			if (special(c)) {
-				if (dn + 1 >= eom) {
-					errno = EMSGSIZE;
-					return (-1);
-				}
-				*dn++ = '\\';
-				*dn++ = (char)c;
-			} else if (!printable(c)) {
-				if (dn + 3 >= eom) {
-					errno = EMSGSIZE;
-					return (-1);
-				}
-				*dn++ = '\\';
-				*dn++ = digits[c / 100];
-				*dn++ = digits[(c % 100) / 10];
-				*dn++ = digits[c % 10];
-			} else {
-				if (dn >= eom) {
-					errno = EMSGSIZE;
-					return (-1);
-				}
-				*dn++ = (char)c;
-			}
-		}
-	}
-	if (dn == dst) {
-		if (dn >= eom) {
-			errno = EMSGSIZE;
-			return (-1);
-		}
-		*dn++ = '.';
-	}
-	if (dn >= eom) {
-		errno = EMSGSIZE;
-		return (-1);
-	}
-	*dn++ = '\0';
-	return (dn - dst);
-}
-
-/*%
- *	Convert a ascii string into an encoded domain name as per RFC1035.
- *
- * return:
- *
- *\li	-1 if it fails
- *\li	1 if string was fully qualified
- *\li	0 is string was not fully qualified
- *
- * notes:
- *\li	Enforces label and domain length limits.
- */
-
-int
-ns_name_pton(const char *src, u_char *dst, size_t dstsiz)
-{
-	u_char *label, *bp, *eom;
-	int c, n, escaped, e = 0;
-	char *cp;
-
-	escaped = 0;
-	bp = dst;
-	eom = dst + dstsiz;
-	label = bp++;
-
-	while ((c = *src++) != 0) {
-		if (escaped) {
-			if (c == '[') { /*%< start a bit string label */
-				if ((cp = strchr(src, ']')) == NULL) {
-					errno = EINVAL; /*%< ??? */
-					return(-1);
-				}
-				if ((e = encode_bitsring(&src, cp + 2,
-							 &label, &bp, eom))
-				    != 0) {
-					errno = e;
-					return(-1);
-				}
-				escaped = 0;
-				label = bp++;
-				if ((c = *src++) == 0)
-					goto done;
-				else if (c != '.') {
-					errno = EINVAL;
-					return(-1);
-				}
-				continue;
-			}
-			else if ((cp = strchr(digits, c)) != NULL) {
-				n = (cp - digits) * 100;
-				if ((c = *src++) == 0 ||
-				    (cp = strchr(digits, c)) == NULL) {
-					errno = EMSGSIZE;
-					return (-1);
-				}
-				n += (cp - digits) * 10;
-				if ((c = *src++) == 0 ||
-				    (cp = strchr(digits, c)) == NULL) {
-					errno = EMSGSIZE;
-					return (-1);
-				}
-				n += (cp - digits);
-				if (n > 255) {
-					errno = EMSGSIZE;
-					return (-1);
-				}
-				c = n;
-			}
-			escaped = 0;
-		} else if (c == '\\') {
-			escaped = 1;
-			continue;
-		} else if (c == '.') {
-			c = (bp - label - 1);
-			if ((c & NS_CMPRSFLGS) != 0) {	/*%< Label too big. */
-				errno = EMSGSIZE;
-				return (-1);
-			}
-			if (label >= eom) {
-				errno = EMSGSIZE;
-				return (-1);
-			}
-			*label = c;
-			/* Fully qualified ? */
-			if (*src == '\0') {
-				if (c != 0) {
-					if (bp >= eom) {
-						errno = EMSGSIZE;
-						return (-1);
-					}
-					*bp++ = '\0';
-				}
-				if ((bp - dst) > MAXCDNAME) {
-					errno = EMSGSIZE;
-					return (-1);
-				}
-				return (1);
-			}
-			if (c == 0 || *src == '.') {
-				errno = EMSGSIZE;
-				return (-1);
-			}
-			label = bp++;
-			continue;
-		}
-		if (bp >= eom) {
-			errno = EMSGSIZE;
-			return (-1);
-		}
-		*bp++ = (u_char)c;
-	}
-	c = (bp - label - 1);
-	if ((c & NS_CMPRSFLGS) != 0) {		/*%< Label too big. */
-		errno = EMSGSIZE;
-		return (-1);
-	}
-  done:
-	if (label >= eom) {
-		errno = EMSGSIZE;
-		return (-1);
-	}
-	*label = c;
-	if (c != 0) {
-		if (bp >= eom) {
-			errno = EMSGSIZE;
-			return (-1);
-		}
-		*bp++ = 0;
-	}
-	if ((bp - dst) > MAXCDNAME) {	/*%< src too big */
-		errno = EMSGSIZE;
-		return (-1);
-	}
-	return (0);
-}
-
-/*%
- *	Convert a network strings labels into all lowercase.
- *
- * return:
- *\li	Number of bytes written to buffer, or -1 (with errno set)
- *
- * notes:
- *\li	Enforces label and domain length limits.
- */
-
-int
-ns_name_ntol(const u_char *src, u_char *dst, size_t dstsiz)
-{
-	const u_char *cp;
-	u_char *dn, *eom;
-	u_char c;
-	u_int n;
-	int l;
-
-	cp = src;
-	dn = dst;
-	eom = dst + dstsiz;
-
-	if (dn >= eom) {
-		errno = EMSGSIZE;
-		return (-1);
-	}
-	while ((n = *cp++) != 0) {
-		if ((n & NS_CMPRSFLGS) == NS_CMPRSFLGS) {
-			/* Some kind of compression pointer. */
-			errno = EMSGSIZE;
-			return (-1);
-		}
-		*dn++ = n;
-		if ((l = labellen(cp - 1)) < 0) {
-			errno = EMSGSIZE;
-			return (-1);
-		}
-		if (dn + l >= eom) {
-			errno = EMSGSIZE;
-			return (-1);
-		}
-		for ((void)NULL; l > 0; l--) {
-			c = *cp++;
-			if (isupper(c))
-				*dn++ = tolower(c);
-			else
-				*dn++ = c;
-		}
-	}
-	*dn++ = '\0';
-	return (dn - dst);
-}
-
-/*%
- *	Unpack a domain name from a message, source may be compressed.
- *
- * return:
- *\li	-1 if it fails, or consumed octets if it succeeds.
- */
-int
-ns_name_unpack(const u_char *msg, const u_char *eom, const u_char *src,
-	       u_char *dst, size_t dstsiz)
-{
-	const u_char *srcp, *dstlim;
-	u_char *dstp;
-	int n, len, checked, l;
-
-	len = -1;
-	checked = 0;
-	dstp = dst;
-	srcp = src;
-	dstlim = dst + dstsiz;
-	if (srcp < msg || srcp >= eom) {
-		errno = EMSGSIZE;
-		return (-1);
-	}
-	/* Fetch next label in domain name. */
-	while ((n = *srcp++) != 0) {
-		/* Check for indirection. */
-		switch (n & NS_CMPRSFLGS) {
-		case 0:
-		case NS_TYPE_ELT:
-			/* Limit checks. */
-			if ((l = labellen(srcp - 1)) < 0) {
-				errno = EMSGSIZE;
-				return(-1);
-			}
-			if (dstp + l + 1 >= dstlim || srcp + l >= eom) {
-				errno = EMSGSIZE;
-				return (-1);
-			}
-			checked += l + 1;
-			*dstp++ = n;
-			memcpy(dstp, srcp, l);
-			dstp += l;
-			srcp += l;
-			break;
-
-		case NS_CMPRSFLGS:
-			if (srcp >= eom) {
-				errno = EMSGSIZE;
-				return (-1);
-			}
-			if (len < 0)
-				len = srcp - src + 1;
-			srcp = msg + (((n & 0x3f) << 8) | (*srcp & 0xff));
-			if (srcp < msg || srcp >= eom) {  /*%< Out of range. */
-				errno = EMSGSIZE;
-				return (-1);
-			}
-			checked += 2;
-			/*
-			 * Check for loops in the compressed name;
-			 * if we've looked at the whole message,
-			 * there must be a loop.
-			 */
-			if (checked >= eom - msg) {
-				errno = EMSGSIZE;
-				return (-1);
-			}
-			break;
-
-		default:
-			errno = EMSGSIZE;
-			return (-1);			/*%< flag error */
-		}
-	}
-	*dstp = '\0';
-	if (len < 0)
-		len = srcp - src;
-	return (len);
-}
-
-/*%
- *	Pack domain name 'domain' into 'comp_dn'.
- *
- * return:
- *\li	Size of the compressed name, or -1.
- *
- * notes:
- *\li	'dnptrs' is an array of pointers to previous compressed names.
- *\li	dnptrs[0] is a pointer to the beginning of the message. The array
- *	ends with NULL.
- *\li	'lastdnptr' is a pointer to the end of the array pointed to
- *	by 'dnptrs'.
- *
- * Side effects:
- *\li	The list of pointers in dnptrs is updated for labels inserted into
- *	the message as we compress the name.  If 'dnptr' is NULL, we don't
- *	try to compress names. If 'lastdnptr' is NULL, we don't update the
- *	list.
- */
-int
-ns_name_pack(const u_char *src, u_char *dst, int dstsiz,
-	     const u_char **dnptrs, const u_char **lastdnptr)
-{
-	u_char *dstp;
-	const u_char **cpp, **lpp, *eob, *msg;
-	const u_char *srcp;
-	int n, l, first = 1;
-
-	srcp = src;
-	dstp = dst;
-	eob = dstp + dstsiz;
-	lpp = cpp = NULL;
-	if (dnptrs != NULL) {
-		if ((msg = *dnptrs++) != NULL) {
-			for (cpp = dnptrs; *cpp != NULL; cpp++)
-				(void)NULL;
-			lpp = cpp;	/*%< end of list to search */
-		}
-	} else
-		msg = NULL;
-
-	/* make sure the domain we are about to add is legal */
-	l = 0;
-	do {
-		int l0;
-
-		n = *srcp;
-		if ((n & NS_CMPRSFLGS) == NS_CMPRSFLGS) {
-			errno = EMSGSIZE;
-			return (-1);
-		}
-		if ((l0 = labellen(srcp)) < 0) {
-			errno = EINVAL;
-			return(-1);
-		}
-		l += l0 + 1;
-		if (l > MAXCDNAME) {
-			errno = EMSGSIZE;
-			return (-1);
-		}
-		srcp += l0 + 1;
-	} while (n != 0);
-
-	/* from here on we need to reset compression pointer array on error */
-	srcp = src;
-	do {
-		/* Look to see if we can use pointers. */
-		n = *srcp;
-		if (n != 0 && msg != NULL) {
-			l = dn_find(srcp, msg, (const u_char * const *)dnptrs,
-				    (const u_char * const *)lpp);
-			if (l >= 0) {
-				if (dstp + 1 >= eob) {
-					goto cleanup;
-				}
-				*dstp++ = (l >> 8) | NS_CMPRSFLGS;
-				*dstp++ = l % 256;
-				return (dstp - dst);
-			}
-			/* Not found, save it. */
-			if (lastdnptr != NULL && cpp < lastdnptr - 1 &&
-			    (dstp - msg) < 0x4000 && first) {
-				*cpp++ = dstp;
-				*cpp = NULL;
-				first = 0;
-			}
-		}
-		/* copy label to buffer */
-		if ((n & NS_CMPRSFLGS) == NS_CMPRSFLGS) {
-			/* Should not happen. */
-			goto cleanup;
-		}
-		n = labellen(srcp);
-		if (dstp + 1 + n >= eob) {
-			goto cleanup;
-		}
-		memcpy(dstp, srcp, n + 1);
-		srcp += n + 1;
-		dstp += n + 1;
-	} while (n != 0);
-
-	if (dstp > eob) {
-cleanup:
-		if (msg != NULL)
-			*lpp = NULL;
-		errno = EMSGSIZE;
-		return (-1);
-	} 
-	return (dstp - dst);
-}
-
-/*%
- *	Expand compressed domain name to presentation format.
- *
- * return:
- *\li	Number of bytes read out of `src', or -1 (with errno set).
- *
- * note:
- *\li	Root domain returns as "." not "".
- */
-int
-ns_name_uncompress(const u_char *msg, const u_char *eom, const u_char *src,
-		   char *dst, size_t dstsiz)
-{
-	u_char tmp[NS_MAXCDNAME];
-	int n;
-	
-	if ((n = ns_name_unpack(msg, eom, src, tmp, sizeof tmp)) == -1)
-		return (-1);
-	if (ns_name_ntop(tmp, dst, dstsiz) == -1)
-		return (-1);
-	return (n);
-}
-
-/*%
- *	Compress a domain name into wire format, using compression pointers.
- *
- * return:
- *\li	Number of bytes consumed in `dst' or -1 (with errno set).
- *
- * notes:
- *\li	'dnptrs' is an array of pointers to previous compressed names.
- *\li	dnptrs[0] is a pointer to the beginning of the message.
- *\li	The list ends with NULL.  'lastdnptr' is a pointer to the end of the
- *	array pointed to by 'dnptrs'. Side effect is to update the list of
- *	pointers for labels inserted into the message as we compress the name.
- *\li	If 'dnptr' is NULL, we don't try to compress names. If 'lastdnptr'
- *	is NULL, we don't update the list.
- */
-int
-ns_name_compress(const char *src, u_char *dst, size_t dstsiz,
-		 const u_char **dnptrs, const u_char **lastdnptr)
-{
-	u_char tmp[NS_MAXCDNAME];
-
-	if (ns_name_pton(src, tmp, sizeof tmp) == -1)
-		return (-1);
-	return (ns_name_pack(tmp, dst, dstsiz, dnptrs, lastdnptr));
-}
-
-/*%
- * Reset dnptrs so that there are no active references to pointers at or
- * after src.
- */
-void
-ns_name_rollback(const u_char *src, const u_char **dnptrs,
-		 const u_char **lastdnptr)
-{
-	while (dnptrs < lastdnptr && *dnptrs != NULL) {
-		if (*dnptrs >= src) {
-			*dnptrs = NULL;
-			break;
-		}
-		dnptrs++;
-	}
-}
-
-/*%
- *	Advance *ptrptr to skip over the compressed name it points at.
- *
- * return:
- *\li	0 on success, -1 (with errno set) on failure.
- */
-int
-ns_name_skip(const u_char **ptrptr, const u_char *eom)
-{
-	const u_char *cp;
-	u_int n;
-	int l;
-
-	cp = *ptrptr;
-	while (cp < eom && (n = *cp++) != 0) {
-		/* Check for indirection. */
-		switch (n & NS_CMPRSFLGS) {
-		case 0:			/*%< normal case, n == len */
-			cp += n;
-			continue;
-		case NS_TYPE_ELT: /*%< EDNS0 extended label */
-			if ((l = labellen(cp - 1)) < 0) {
-				errno = EMSGSIZE; /*%< XXX */
-				return(-1);
-			}
-			cp += l;
-			continue;
-		case NS_CMPRSFLGS:	/*%< indirection */
-			cp++;
-			break;
-		default:		/*%< illegal type */
-			errno = EMSGSIZE;
-			return (-1);
-		}
-		break;
-	}
-	if (cp > eom) {
-		errno = EMSGSIZE;
-		return (-1);
-	}
-	*ptrptr = cp;
-	return (0);
-}
-
-/* Private. */
-
-/*%
- *	Thinking in noninternationalized USASCII (per the DNS spec),
- *	is this characted special ("in need of quoting") ?
- *
- * return:
- *\li	boolean.
- */
-static int
-special(int ch) {
-	switch (ch) {
-	case 0x22: /*%< '"' */
-	case 0x2E: /*%< '.' */
-	case 0x3B: /*%< ';' */
-	case 0x5C: /*%< '\\' */
-	case 0x28: /*%< '(' */
-	case 0x29: /*%< ')' */
-	/* Special modifiers in zone files. */
-	case 0x40: /*%< '@' */
-	case 0x24: /*%< '$' */
-		return (1);
-	default:
-		return (0);
-	}
-}
-
-/*%
- *	Thinking in noninternationalized USASCII (per the DNS spec),
- *	is this character visible and not a space when printed ?
- *
- * return:
- *\li	boolean.
- */
-static int
-printable(int ch) {
-	return (ch > 0x20 && ch < 0x7f);
-}
-
-/*%
- *	Thinking in noninternationalized USASCII (per the DNS spec),
- *	convert this character to lower case if it's upper case.
- */
-static int
-mklower(int ch) {
-	if (ch >= 0x41 && ch <= 0x5A)
-		return (ch + 0x20);
-	return (ch);
-}
-
-/*%
- *	Search for the counted-label name in an array of compressed names.
- *
- * return:
- *\li	offset from msg if found, or -1.
- *
- * notes:
- *\li	dnptrs is the pointer to the first name on the list,
- *\li	not the pointer to the start of the message.
- */
-static int
-dn_find(const u_char *domain, const u_char *msg,
-	const u_char * const *dnptrs,
-	const u_char * const *lastdnptr)
-{
-	const u_char *dn, *cp, *sp;
-	const u_char * const *cpp;
-	u_int n;
-
-	for (cpp = dnptrs; cpp < lastdnptr; cpp++) {
-		sp = *cpp;
-		/*
-		 * terminate search on:
-		 * root label
-		 * compression pointer
-		 * unusable offset
-		 */
-		while (*sp != 0 && (*sp & NS_CMPRSFLGS) == 0 &&
-		       (sp - msg) < 0x4000) {
-			dn = domain;
-			cp = sp;
-			while ((n = *cp++) != 0) {
-				/*
-				 * check for indirection
-				 */
-				switch (n & NS_CMPRSFLGS) {
-				case 0:		/*%< normal case, n == len */
-					n = labellen(cp - 1); /*%< XXX */
-					if (n != *dn++)
-						goto next;
-
-					for ((void)NULL; n > 0; n--)
-						if (mklower(*dn++) !=
-						    mklower(*cp++))
-							goto next;
-					/* Is next root for both ? */
-					if (*dn == '\0' && *cp == '\0')
-						return (sp - msg);
-					if (*dn)
-						continue;
-					goto next;
-				case NS_CMPRSFLGS:	/*%< indirection */
-					cp = msg + (((n & 0x3f) << 8) | *cp);
-					break;
-
-				default:	/*%< illegal type */
-					errno = EMSGSIZE;
-					return (-1);
-				}
-			}
- next: ;
-			sp += *sp + 1;
-		}
-	}
-	errno = ENOENT;
-	return (-1);
-}
-
-static int
-decode_bitstring(const unsigned char **cpp, char *dn, const char *eom)
-{
-	const unsigned char *cp = *cpp;
-	char *beg = dn, tc;
-	int b, blen, plen, i;
-
-	if ((blen = (*cp & 0xff)) == 0)
-		blen = 256;
-	plen = (blen + 3) / 4;
-	plen += sizeof("\\[x/]") + (blen > 99 ? 3 : (blen > 9) ? 2 : 1);
-	if (dn + plen >= eom)
-		return(-1);
-
-	cp++;
-	i = SPRINTF((dn, "\\[x"));
-	if (i < 0)
-		return (-1);
-	dn += i;
-	for (b = blen; b > 7; b -= 8, cp++) {
-		i = SPRINTF((dn, "%02x", *cp & 0xff));
-		if (i < 0)
-			return (-1);
-		dn += i;
-	}
-	if (b > 4) {
-		tc = *cp++;
-		i = SPRINTF((dn, "%02x", tc & (0xff << (8 - b))));
-		if (i < 0)
-			return (-1);
-		dn += i;
-	} else if (b > 0) {
-		tc = *cp++;
-		i = SPRINTF((dn, "%1x",
-			       ((tc >> 4) & 0x0f) & (0x0f << (4 - b)))); 
-		if (i < 0)
-			return (-1);
-		dn += i;
-	}
-	i = SPRINTF((dn, "/%d]", blen));
-	if (i < 0)
-		return (-1);
-	dn += i;
-
-	*cpp = cp;
-	return(dn - beg);
-}
-
-static int
-encode_bitsring(const char **bp, const char *end, unsigned char **labelp,
-	        unsigned char ** dst, unsigned const char *eom)
-{
-	int afterslash = 0;
-	const char *cp = *bp;
-	unsigned char *tp;
-	char c;
-	const char *beg_blen;
-	char *end_blen = NULL;
-	int value = 0, count = 0, tbcount = 0, blen = 0;
-
-	beg_blen = end_blen = NULL;
-
-	/* a bitstring must contain at least 2 characters */
-	if (end - cp < 2)
-		return(EINVAL);
-
-	/* XXX: currently, only hex strings are supported */
-	if (*cp++ != 'x')
-		return(EINVAL);
-	if (!isxdigit((*cp) & 0xff)) /*%< reject '\[x/BLEN]' */
-		return(EINVAL);
-
-	for (tp = *dst + 1; cp < end && tp < eom; cp++) {
-		switch((c = *cp)) {
-		case ']':	/*%< end of the bitstring */
-			if (afterslash) {
-				if (beg_blen == NULL)
-					return(EINVAL);
-				blen = (int)strtol(beg_blen, &end_blen, 10);
-				if (*end_blen != ']')
-					return(EINVAL);
-			}
-			if (count)
-				*tp++ = ((value << 4) & 0xff);
-			cp++;	/*%< skip ']' */
-			goto done;
-		case '/':
-			afterslash = 1;
-			break;
-		default:
-			if (afterslash) {
-				if (!isdigit(c&0xff))
-					return(EINVAL);
-				if (beg_blen == NULL) {
-					
-					if (c == '0') {
-						/* blen never begings with 0 */
-						return(EINVAL);
-					}
-					beg_blen = cp;
-				}
-			} else {
-				if (!isxdigit(c&0xff))
-					return(EINVAL);
-				value <<= 4;
-				value += digitvalue[(int)c];
-				count += 4;
-				tbcount += 4;
-				if (tbcount > 256)
-					return(EINVAL);
-				if (count == 8) {
-					*tp++ = value;
-					count = 0;
-				}
-			}
-			break;
-		}
-	}
-  done:
-	if (cp >= end || tp >= eom)
-		return(EMSGSIZE);
-
-	/*
-	 * bit length validation:
-	 * If a <length> is present, the number of digits in the <bit-data>
-	 * MUST be just sufficient to contain the number of bits specified
-	 * by the <length>. If there are insignificant bits in a final
-	 * hexadecimal or octal digit, they MUST be zero.
-	 * RFC2673, Section 3.2.
-	 */
-	if (blen > 0) {
-		int traillen;
-
-		if (((blen + 3) & ~3) != tbcount)
-			return(EINVAL);
-		traillen = tbcount - blen; /*%< between 0 and 3 */
-		if (((value << (8 - traillen)) & 0xff) != 0)
-			return(EINVAL);
-	}
-	else
-		blen = tbcount;
-	if (blen == 256)
-		blen = 0;
-
-	/* encode the type and the significant bit fields */
-	**labelp = DNS_LABELTYPE_BITSTRING;
-	**dst = blen;
-
-	*bp = cp;
-	*dst = tp;
-
-	return(0);
-}
-
-static int
-labellen(const u_char *lp)
-{
-	int bitlen;
-	u_char l = *lp;
-
-	if ((l & NS_CMPRSFLGS) == NS_CMPRSFLGS) {
-		/* should be avoided by the caller */
-		return(-1);
-	}
-
-	if ((l & NS_CMPRSFLGS) == NS_TYPE_ELT) {
-		if (l == DNS_LABELTYPE_BITSTRING) {
-			if ((bitlen = *(lp + 1)) == 0)
-				bitlen = 256;
-			return((bitlen + 7 ) / 8 + 1);
-		}
-		return(-1);	/*%< unknwon ELT */
-	}
-	return(l);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/nameser/ns_netint.c b/contrib/bind9/lib/bind/nameser/ns_netint.c
deleted file mode 100644
index b08c58b..0000000
--- a/contrib/bind9/lib/bind/nameser/ns_netint.c
+++ /dev/null
@@ -1,58 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#ifndef lint
-static const char rcsid[] = "$Id: ns_netint.c,v 1.2.18.1 2005/04/27 05:01:08 sra Exp $";
-#endif
-
-/* Import. */
-
-#include "port_before.h"
-
-#include <arpa/nameser.h>
-
-#include "port_after.h"
-
-/* Public. */
-
-u_int
-ns_get16(const u_char *src) {
-	u_int dst;
-
-	NS_GET16(dst, src);
-	return (dst);
-}
-
-u_long
-ns_get32(const u_char *src) {
-	u_long dst;
-
-	NS_GET32(dst, src);
-	return (dst);
-}
-
-void
-ns_put16(u_int src, u_char *dst) {
-	NS_PUT16(src, dst);
-}
-
-void
-ns_put32(u_long src, u_char *dst) {
-	NS_PUT32(src, dst);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/nameser/ns_parse.c b/contrib/bind9/lib/bind/nameser/ns_parse.c
deleted file mode 100644
index c4658d8..0000000
--- a/contrib/bind9/lib/bind/nameser/ns_parse.c
+++ /dev/null
@@ -1,211 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#ifndef lint
-static const char rcsid[] = "$Id: ns_parse.c,v 1.5.18.4 2007/08/27 03:34:24 marka Exp $";
-#endif
-
-/* Import. */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-
-#include <errno.h>
-#include <resolv.h>
-#include <string.h>
-
-#include "port_after.h"
-
-/* Forward. */
-
-static void	setsection(ns_msg *msg, ns_sect sect);
-
-/* Macros. */
-
-#if !defined(SOLARIS2) || defined(__COVERITY__)
-#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. */
-
-/* These need to be in the same order as the nres.h:ns_flag enum. */
-struct _ns_flagdata _ns_flagdata[16] = {
-	{ 0x8000, 15 },		/*%< qr. */
-	{ 0x7800, 11 },		/*%< opcode. */
-	{ 0x0400, 10 },		/*%< aa. */
-	{ 0x0200, 9 },		/*%< tc. */
-	{ 0x0100, 8 },		/*%< rd. */
-	{ 0x0080, 7 },		/*%< ra. */
-	{ 0x0040, 6 },		/*%< z. */
-	{ 0x0020, 5 },		/*%< ad. */
-	{ 0x0010, 4 },		/*%< cd. */
-	{ 0x000f, 0 },		/*%< rcode. */
-	{ 0x0000, 0 },		/*%< expansion (1/6). */
-	{ 0x0000, 0 },		/*%< expansion (2/6). */
-	{ 0x0000, 0 },		/*%< expansion (3/6). */
-	{ 0x0000, 0 },		/*%< expansion (4/6). */
-	{ 0x0000, 0 },		/*%< expansion (5/6). */
-	{ 0x0000, 0 },		/*%< expansion (6/6). */
-};
-
-int ns_msg_getflag(ns_msg handle, int flag) {
-	return(((handle)._flags & _ns_flagdata[flag].mask) >> _ns_flagdata[flag].shift);
-}
-
-int
-ns_skiprr(const u_char *ptr, const u_char *eom, ns_sect section, int count) {
-	const u_char *optr = ptr;
-
-	for ((void)NULL; count > 0; count--) {
-		int b, rdlength;
-
-		b = dn_skipname(ptr, eom);
-		if (b < 0)
-			RETERR(EMSGSIZE);
-		ptr += b/*Name*/ + NS_INT16SZ/*Type*/ + NS_INT16SZ/*Class*/;
-		if (section != ns_s_qd) {
-			if (ptr + NS_INT32SZ + NS_INT16SZ > eom)
-				RETERR(EMSGSIZE);
-			ptr += NS_INT32SZ/*TTL*/;
-			NS_GET16(rdlength, ptr);
-			ptr += rdlength/*RData*/;
-		}
-	}
-	if (ptr > eom)
-		RETERR(EMSGSIZE);
-	return (ptr - optr);
-}
-
-int
-ns_initparse(const u_char *msg, int msglen, ns_msg *handle) {
-	const u_char *eom = msg + msglen;
-	int i;
-
-	memset(handle, 0x5e, sizeof *handle);
-	handle->_msg = msg;
-	handle->_eom = eom;
-	if (msg + NS_INT16SZ > eom)
-		RETERR(EMSGSIZE);
-	NS_GET16(handle->_id, msg);
-	if (msg + NS_INT16SZ > eom)
-		RETERR(EMSGSIZE);
-	NS_GET16(handle->_flags, msg);
-	for (i = 0; i < ns_s_max; i++) {
-		if (msg + NS_INT16SZ > eom)
-			RETERR(EMSGSIZE);
-		NS_GET16(handle->_counts[i], msg);
-	}
-	for (i = 0; i < ns_s_max; i++)
-		if (handle->_counts[i] == 0)
-			handle->_sections[i] = NULL;
-		else {
-			int b = ns_skiprr(msg, eom, (ns_sect)i,
-					  handle->_counts[i]);
-
-			if (b < 0)
-				return (-1);
-			handle->_sections[i] = msg;
-			msg += b;
-		}
-	if (msg != eom)
-		RETERR(EMSGSIZE);
-	setsection(handle, ns_s_max);
-	return (0);
-}
-
-int
-ns_parserr(ns_msg *handle, ns_sect section, int rrnum, ns_rr *rr) {
-	int b;
-	int tmp;
-
-	/* Make section right. */
-	tmp = section;
-	if (tmp < 0 || section >= ns_s_max)
-		RETERR(ENODEV);
-	if (section != handle->_sect)
-		setsection(handle, section);
-
-	/* Make rrnum right. */
-	if (rrnum == -1)
-		rrnum = handle->_rrnum;
-	if (rrnum < 0 || rrnum >= handle->_counts[(int)section])
-		RETERR(ENODEV);
-	if (rrnum < handle->_rrnum)
-		setsection(handle, section);
-	if (rrnum > handle->_rrnum) {
-		b = ns_skiprr(handle->_msg_ptr, handle->_eom, section,
-			      rrnum - handle->_rrnum);
-
-		if (b < 0)
-			return (-1);
-		handle->_msg_ptr += b;
-		handle->_rrnum = rrnum;
-	}
-
-	/* Do the parse. */
-	b = dn_expand(handle->_msg, handle->_eom,
-		      handle->_msg_ptr, rr->name, NS_MAXDNAME);
-	if (b < 0)
-		return (-1);
-	handle->_msg_ptr += b;
-	if (handle->_msg_ptr + NS_INT16SZ + NS_INT16SZ > handle->_eom)
-		RETERR(EMSGSIZE);
-	NS_GET16(rr->type, handle->_msg_ptr);
-	NS_GET16(rr->rr_class, handle->_msg_ptr);
-	if (section == ns_s_qd) {
-		rr->ttl = 0;
-		rr->rdlength = 0;
-		rr->rdata = NULL;
-	} else {
-		if (handle->_msg_ptr + NS_INT32SZ + NS_INT16SZ > handle->_eom)
-			RETERR(EMSGSIZE);
-		NS_GET32(rr->ttl, handle->_msg_ptr);
-		NS_GET16(rr->rdlength, handle->_msg_ptr);
-		if (handle->_msg_ptr + rr->rdlength > handle->_eom)
-			RETERR(EMSGSIZE);
-		rr->rdata = handle->_msg_ptr;
-		handle->_msg_ptr += rr->rdlength;
-	}
-	if (++handle->_rrnum > handle->_counts[(int)section])
-		setsection(handle, (ns_sect)((int)section + 1));
-
-	/* All done. */
-	return (0);
-}
-
-/* Private. */
-
-static void
-setsection(ns_msg *msg, ns_sect sect) {
-	msg->_sect = sect;
-	if (sect == ns_s_max) {
-		msg->_rrnum = -1;
-		msg->_msg_ptr = NULL;
-	} else {
-		msg->_rrnum = 0;
-		msg->_msg_ptr = msg->_sections[(int)sect];
-	}
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/nameser/ns_print.c b/contrib/bind9/lib/bind/nameser/ns_print.c
deleted file mode 100644
index 0679ba4..0000000
--- a/contrib/bind9/lib/bind/nameser/ns_print.c
+++ /dev/null
@@ -1,897 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996-1999 by 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.
- */
-
-#ifndef lint
-static const char rcsid[] = "$Id: ns_print.c,v 1.6.18.4 2005/04/27 05:01:09 sra Exp $";
-#endif
-
-/* Import. */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/socket.h>
-
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <arpa/inet.h>
-
-#include <isc/assertions.h>
-#include <isc/dst.h>
-#include <errno.h>
-#include <resolv.h>
-#include <string.h>
-#include <ctype.h>
-
-#include "port_after.h"
-
-#ifdef SPRINTF_CHAR
-# define SPRINTF(x) strlen(sprintf/**/x)
-#else
-# define SPRINTF(x) ((size_t)sprintf x)
-#endif
-
-/* Forward. */
-
-static size_t	prune_origin(const char *name, const char *origin);
-static int	charstr(const u_char *rdata, const u_char *edata,
-			char **buf, size_t *buflen);
-static int	addname(const u_char *msg, size_t msglen,
-			const u_char **p, const char *origin,
-			char **buf, size_t *buflen);
-static void	addlen(size_t len, char **buf, size_t *buflen);
-static int	addstr(const char *src, size_t len,
-		       char **buf, size_t *buflen);
-static int	addtab(size_t len, size_t target, int spaced,
-		       char **buf, size_t *buflen);
-
-/* Macros. */
-
-#define	T(x) \
-	do { \
-		if ((x) < 0) \
-			return (-1); \
-	} while (0)
-
-/* Public. */
-
-/*%
- *	Convert an RR to presentation format.
- *
- * return:
- *\li	Number of characters written to buf, or -1 (check errno).
- */
-int
-ns_sprintrr(const ns_msg *handle, const ns_rr *rr,
-	    const char *name_ctx, const char *origin,
-	    char *buf, size_t buflen)
-{
-	int n;
-
-	n = ns_sprintrrf(ns_msg_base(*handle), ns_msg_size(*handle),
-			 ns_rr_name(*rr), ns_rr_class(*rr), ns_rr_type(*rr),
-			 ns_rr_ttl(*rr), ns_rr_rdata(*rr), ns_rr_rdlen(*rr),
-			 name_ctx, origin, buf, buflen);
-	return (n);
-}
-
-/*%
- *	Convert the fields of an RR into presentation format.
- *
- * return:
- *\li	Number of characters written to buf, or -1 (check errno).
- */
-int
-ns_sprintrrf(const u_char *msg, size_t msglen,
-	    const char *name, ns_class class, ns_type type,
-	    u_long ttl, const u_char *rdata, size_t rdlen,
-	    const char *name_ctx, const char *origin,
-	    char *buf, size_t buflen)
-{
-	const char *obuf = buf;
-	const u_char *edata = rdata + rdlen;
-	int spaced = 0;
-
-	const char *comment;
-	char tmp[100];
-	int len, x;
-
-	/*
-	 * Owner.
-	 */
-	if (name_ctx != NULL && ns_samename(name_ctx, name) == 1) {
-		T(addstr("\t\t\t", 3, &buf, &buflen));
-	} else {
-		len = prune_origin(name, origin);
-		if (*name == '\0') {
-			goto root;
-		} else if (len == 0) {
-			T(addstr("@\t\t\t", 4, &buf, &buflen));
-		} else {
-			T(addstr(name, len, &buf, &buflen));
-			/* Origin not used or not root, and no trailing dot? */
-			if (((origin == NULL || origin[0] == '\0') ||
-			    (origin[0] != '.' && origin[1] != '\0' &&
-			    name[len] == '\0')) && name[len - 1] != '.') {
- root:
-				T(addstr(".", 1, &buf, &buflen));
-				len++;
-			}
-			T(spaced = addtab(len, 24, spaced, &buf, &buflen));
-		}
-	}
-
-	/*
-	 * TTL, Class, Type.
-	 */
-	T(x = ns_format_ttl(ttl, buf, buflen));
-	addlen(x, &buf, &buflen);
-	len = SPRINTF((tmp, " %s %s", p_class(class), p_type(type)));
-	T(addstr(tmp, len, &buf, &buflen));
-	T(spaced = addtab(x + len, 16, spaced, &buf, &buflen));
-
-	/*
-	 * RData.
-	 */
-	switch (type) {
-	case ns_t_a:
-		if (rdlen != (size_t)NS_INADDRSZ)
-			goto formerr;
-		(void) inet_ntop(AF_INET, rdata, buf, buflen);
-		addlen(strlen(buf), &buf, &buflen);
-		break;
-
-	case ns_t_cname:
-	case ns_t_mb:
-	case ns_t_mg:
-	case ns_t_mr:
-	case ns_t_ns:
-	case ns_t_ptr:
-	case ns_t_dname:
-		T(addname(msg, msglen, &rdata, origin, &buf, &buflen));
-		break;
-
-	case ns_t_hinfo:
-	case ns_t_isdn:
-		/* First word. */
-		T(len = charstr(rdata, edata, &buf, &buflen));
-		if (len == 0)
-			goto formerr;
-		rdata += len;
-		T(addstr(" ", 1, &buf, &buflen));
-
-		    
-		/* Second word, optional in ISDN records. */
-		if (type == ns_t_isdn && rdata == edata)
-			break;
-		    
-		T(len = charstr(rdata, edata, &buf, &buflen));
-		if (len == 0)
-			goto formerr;
-		rdata += len;
-		break;
-
-	case ns_t_soa: {
-		u_long t;
-
-		/* Server name. */
-		T(addname(msg, msglen, &rdata, origin, &buf, &buflen));
-		T(addstr(" ", 1, &buf, &buflen));
-
-		/* Administrator name. */
-		T(addname(msg, msglen, &rdata, origin, &buf, &buflen));
-		T(addstr(" (\n", 3, &buf, &buflen));
-		spaced = 0;
-
-		if ((edata - rdata) != 5*NS_INT32SZ)
-			goto formerr;
-
-		/* Serial number. */
-		t = ns_get32(rdata);  rdata += NS_INT32SZ;
-		T(addstr("\t\t\t\t\t", 5, &buf, &buflen));
-		len = SPRINTF((tmp, "%lu", t));
-		T(addstr(tmp, len, &buf, &buflen));
-		T(spaced = addtab(len, 16, spaced, &buf, &buflen));
-		T(addstr("; serial\n", 9, &buf, &buflen));
-		spaced = 0;
-
-		/* Refresh interval. */
-		t = ns_get32(rdata);  rdata += NS_INT32SZ;
-		T(addstr("\t\t\t\t\t", 5, &buf, &buflen));
-		T(len = ns_format_ttl(t, buf, buflen));
-		addlen(len, &buf, &buflen);
-		T(spaced = addtab(len, 16, spaced, &buf, &buflen));
-		T(addstr("; refresh\n", 10, &buf, &buflen));
-		spaced = 0;
-
-		/* Retry interval. */
-		t = ns_get32(rdata);  rdata += NS_INT32SZ;
-		T(addstr("\t\t\t\t\t", 5, &buf, &buflen));
-		T(len = ns_format_ttl(t, buf, buflen));
-		addlen(len, &buf, &buflen);
-		T(spaced = addtab(len, 16, spaced, &buf, &buflen));
-		T(addstr("; retry\n", 8, &buf, &buflen));
-		spaced = 0;
-
-		/* Expiry. */
-		t = ns_get32(rdata);  rdata += NS_INT32SZ;
-		T(addstr("\t\t\t\t\t", 5, &buf, &buflen));
-		T(len = ns_format_ttl(t, buf, buflen));
-		addlen(len, &buf, &buflen);
-		T(spaced = addtab(len, 16, spaced, &buf, &buflen));
-		T(addstr("; expiry\n", 9, &buf, &buflen));
-		spaced = 0;
-
-		/* Minimum TTL. */
-		t = ns_get32(rdata);  rdata += NS_INT32SZ;
-		T(addstr("\t\t\t\t\t", 5, &buf, &buflen));
-		T(len = ns_format_ttl(t, buf, buflen));
-		addlen(len, &buf, &buflen);
-		T(addstr(" )", 2, &buf, &buflen));
-		T(spaced = addtab(len, 16, spaced, &buf, &buflen));
-		T(addstr("; minimum\n", 10, &buf, &buflen));
-
-		break;
-	    }
-
-	case ns_t_mx:
-	case ns_t_afsdb:
-	case ns_t_rt: {
-		u_int t;
-
-		if (rdlen < (size_t)NS_INT16SZ)
-			goto formerr;
-
-		/* Priority. */
-		t = ns_get16(rdata);
-		rdata += NS_INT16SZ;
-		len = SPRINTF((tmp, "%u ", t));
-		T(addstr(tmp, len, &buf, &buflen));
-
-		/* Target. */
-		T(addname(msg, msglen, &rdata, origin, &buf, &buflen));
-
-		break;
-	    }
-
-	case ns_t_px: {
-		u_int t;
-
-		if (rdlen < (size_t)NS_INT16SZ)
-			goto formerr;
-
-		/* Priority. */
-		t = ns_get16(rdata);
-		rdata += NS_INT16SZ;
-		len = SPRINTF((tmp, "%u ", t));
-		T(addstr(tmp, len, &buf, &buflen));
-
-		/* Name1. */
-		T(addname(msg, msglen, &rdata, origin, &buf, &buflen));
-		T(addstr(" ", 1, &buf, &buflen));
-
-		/* Name2. */
-		T(addname(msg, msglen, &rdata, origin, &buf, &buflen));
-
-		break;
-	    }
-
-	case ns_t_x25:
-		T(len = charstr(rdata, edata, &buf, &buflen));
-		if (len == 0)
-			goto formerr;
-		rdata += len;
-		break;
-
-	case ns_t_txt:
-		while (rdata < edata) {
-			T(len = charstr(rdata, edata, &buf, &buflen));
-			if (len == 0)
-				goto formerr;
-			rdata += len;
-			if (rdata < edata)
-				T(addstr(" ", 1, &buf, &buflen));
-		}
-		break;
-
-	case ns_t_nsap: {
-		char t[2+255*3];
-
-		(void) inet_nsap_ntoa(rdlen, rdata, t);
-		T(addstr(t, strlen(t), &buf, &buflen));
-		break;
-	    }
-
-	case ns_t_aaaa:
-		if (rdlen != (size_t)NS_IN6ADDRSZ)
-			goto formerr;
-		(void) inet_ntop(AF_INET6, rdata, buf, buflen);
-		addlen(strlen(buf), &buf, &buflen);
-		break;
-
-	case ns_t_loc: {
-		char t[255];
-
-		/* XXX protocol format checking? */
-		(void) loc_ntoa(rdata, t);
-		T(addstr(t, strlen(t), &buf, &buflen));
-		break;
-	    }
-
-	case ns_t_naptr: {
-		u_int order, preference;
-		char t[50];
-
-		if (rdlen < 2U*NS_INT16SZ)
-			goto formerr;
-
-		/* Order, Precedence. */
-		order = ns_get16(rdata);	rdata += NS_INT16SZ;
-		preference = ns_get16(rdata);	rdata += NS_INT16SZ;
-		len = SPRINTF((t, "%u %u ", order, preference));
-		T(addstr(t, len, &buf, &buflen));
-
-		/* Flags. */
-		T(len = charstr(rdata, edata, &buf, &buflen));
-		if (len == 0)
-			goto formerr;
-		rdata += len;
-		T(addstr(" ", 1, &buf, &buflen));
-
-		/* Service. */
-		T(len = charstr(rdata, edata, &buf, &buflen));
-		if (len == 0)
-			goto formerr;
-		rdata += len;
-		T(addstr(" ", 1, &buf, &buflen));
-
-		/* Regexp. */
-		T(len = charstr(rdata, edata, &buf, &buflen));
-		if (len < 0)
-			return (-1);
-		if (len == 0)
-			goto formerr;
-		rdata += len;
-		T(addstr(" ", 1, &buf, &buflen));
-
-		/* Server. */
-		T(addname(msg, msglen, &rdata, origin, &buf, &buflen));
-		break;
-	    }
-
-	case ns_t_srv: {
-		u_int priority, weight, port;
-		char t[50];
-
-		if (rdlen < 3U*NS_INT16SZ)
-			goto formerr;
-
-		/* Priority, Weight, Port. */
-		priority = ns_get16(rdata);  rdata += NS_INT16SZ;
-		weight   = ns_get16(rdata);  rdata += NS_INT16SZ;
-		port     = ns_get16(rdata);  rdata += NS_INT16SZ;
-		len = SPRINTF((t, "%u %u %u ", priority, weight, port));
-		T(addstr(t, len, &buf, &buflen));
-
-		/* Server. */
-		T(addname(msg, msglen, &rdata, origin, &buf, &buflen));
-		break;
-	    }
-
-	case ns_t_minfo:
-	case ns_t_rp:
-		/* Name1. */
-		T(addname(msg, msglen, &rdata, origin, &buf, &buflen));
-		T(addstr(" ", 1, &buf, &buflen));
-
-		/* Name2. */
-		T(addname(msg, msglen, &rdata, origin, &buf, &buflen));
-
-		break;
-
-	case ns_t_wks: {
-		int n, lcnt;
-
-		if (rdlen < 1U + NS_INT32SZ)
-			goto formerr;
-
-		/* Address. */
-		(void) inet_ntop(AF_INET, rdata, buf, buflen);
-		addlen(strlen(buf), &buf, &buflen);
-		rdata += NS_INADDRSZ;
-
-		/* Protocol. */
-		len = SPRINTF((tmp, " %u ( ", *rdata));
-		T(addstr(tmp, len, &buf, &buflen));
-		rdata += NS_INT8SZ;
-
-		/* Bit map. */
-		n = 0;
-		lcnt = 0;
-		while (rdata < edata) {
-			u_int c = *rdata++;
-			do {
-				if (c & 0200) {
-					if (lcnt == 0) {
-						T(addstr("\n\t\t\t\t", 5,
-							 &buf, &buflen));
-						lcnt = 10;
-						spaced = 0;
-					}
-					len = SPRINTF((tmp, "%d ", n));
-					T(addstr(tmp, len, &buf, &buflen));
-					lcnt--;
-				}
-				c <<= 1;
-			} while (++n & 07);
-		}
-		T(addstr(")", 1, &buf, &buflen));
-
-		break;
-	    }
-
-	case ns_t_key: {
-		char base64_key[NS_MD5RSA_MAX_BASE64];
-		u_int keyflags, protocol, algorithm, key_id;
-		const char *leader;
-		int n;
-
-		if (rdlen < 0U + NS_INT16SZ + NS_INT8SZ + NS_INT8SZ)
-			goto formerr;
-
-		/* Key flags, Protocol, Algorithm. */
-		key_id = dst_s_dns_key_id(rdata, edata-rdata);
-		keyflags = ns_get16(rdata);  rdata += NS_INT16SZ;
-		protocol = *rdata++;
-		algorithm = *rdata++;
-		len = SPRINTF((tmp, "0x%04x %u %u",
-			       keyflags, protocol, algorithm));
-		T(addstr(tmp, len, &buf, &buflen));
-
-		/* Public key data. */
-		len = b64_ntop(rdata, edata - rdata,
-			       base64_key, sizeof base64_key);
-		if (len < 0)
-			goto formerr;
-		if (len > 15) {
-			T(addstr(" (", 2, &buf, &buflen));
-			leader = "\n\t\t";
-			spaced = 0;
-		} else
-			leader = " ";
-		for (n = 0; n < len; n += 48) {
-			T(addstr(leader, strlen(leader), &buf, &buflen));
-			T(addstr(base64_key + n, MIN(len - n, 48),
-				 &buf, &buflen));
-		}
-		if (len > 15)
-			T(addstr(" )", 2, &buf, &buflen));
-		n = SPRINTF((tmp, " ; key_tag= %u", key_id));
-		T(addstr(tmp, n, &buf, &buflen));
-
-		break;
-	    }
-
-	case ns_t_sig: {
-		char base64_key[NS_MD5RSA_MAX_BASE64];
-		u_int type, algorithm, labels, footprint;
-		const char *leader;
-		u_long t;
-		int n;
-
-		if (rdlen < 22U)
-			goto formerr;
-
-		/* Type covered, Algorithm, Label count, Original TTL. */
-	        type = ns_get16(rdata);  rdata += NS_INT16SZ;
-		algorithm = *rdata++;
-		labels = *rdata++;
-		t = ns_get32(rdata);  rdata += NS_INT32SZ;
-		len = SPRINTF((tmp, "%s %d %d %lu ",
-			       p_type(type), algorithm, labels, t));
-		T(addstr(tmp, len, &buf, &buflen));
-		if (labels > (u_int)dn_count_labels(name))
-			goto formerr;
-
-		/* Signature expiry. */
-		t = ns_get32(rdata);  rdata += NS_INT32SZ;
-		len = SPRINTF((tmp, "%s ", p_secstodate(t)));
-		T(addstr(tmp, len, &buf, &buflen));
-
-		/* Time signed. */
-		t = ns_get32(rdata);  rdata += NS_INT32SZ;
-		len = SPRINTF((tmp, "%s ", p_secstodate(t)));
-		T(addstr(tmp, len, &buf, &buflen));
-
-		/* Signature Footprint. */
-		footprint = ns_get16(rdata);  rdata += NS_INT16SZ;
-		len = SPRINTF((tmp, "%u ", footprint));
-		T(addstr(tmp, len, &buf, &buflen));
-
-		/* Signer's name. */
-		T(addname(msg, msglen, &rdata, origin, &buf, &buflen));
-
-		/* Signature. */
-		len = b64_ntop(rdata, edata - rdata,
-			       base64_key, sizeof base64_key);
-		if (len > 15) {
-			T(addstr(" (", 2, &buf, &buflen));
-			leader = "\n\t\t";
-			spaced = 0;
-		} else
-			leader = " ";
-		if (len < 0)
-			goto formerr;
-		for (n = 0; n < len; n += 48) {
-			T(addstr(leader, strlen(leader), &buf, &buflen));
-			T(addstr(base64_key + n, MIN(len - n, 48),
-				 &buf, &buflen));
-		}
-		if (len > 15)
-			T(addstr(" )", 2, &buf, &buflen));
-		break;
-	    }
-
-	case ns_t_nxt: {
-		int n, c;
-
-		/* Next domain name. */
-		T(addname(msg, msglen, &rdata, origin, &buf, &buflen));
-
-		/* Type bit map. */
-		n = edata - rdata;
-		for (c = 0; c < n*8; c++)
-			if (NS_NXT_BIT_ISSET(c, rdata)) {
-				len = SPRINTF((tmp, " %s", p_type(c)));
-				T(addstr(tmp, len, &buf, &buflen));
-			}
-		break;
-	    }
-
-	case ns_t_cert: {
-		u_int c_type, key_tag, alg;
-		int n;
-		unsigned int siz;
-		char base64_cert[8192], tmp[40];
-		const char *leader;
-
-		c_type  = ns_get16(rdata); rdata += NS_INT16SZ;
-		key_tag = ns_get16(rdata); rdata += NS_INT16SZ;
-		alg = (u_int) *rdata++;
-
-		len = SPRINTF((tmp, "%d %d %d ", c_type, key_tag, alg));
-		T(addstr(tmp, len, &buf, &buflen));
-		siz = (edata-rdata)*4/3 + 4; /* "+4" accounts for trailing \0 */
-		if (siz > sizeof(base64_cert) * 3/4) {
-			const char *str = "record too long to print";
-			T(addstr(str, strlen(str), &buf, &buflen));
-		}
-		else {
-			len = b64_ntop(rdata, edata-rdata, base64_cert, siz);
-
-			if (len < 0)
-				goto formerr;
-			else if (len > 15) {
-				T(addstr(" (", 2, &buf, &buflen));
-				leader = "\n\t\t";
-				spaced = 0;
-			}
-			else
-				leader = " ";
-	
-			for (n = 0; n < len; n += 48) {
-				T(addstr(leader, strlen(leader),
-					 &buf, &buflen));
-				T(addstr(base64_cert + n, MIN(len - n, 48),
-					 &buf, &buflen));
-			}
-			if (len > 15)
-				T(addstr(" )", 2, &buf, &buflen));
-		}
-		break;
-	    }
-
-	case ns_t_tkey: {
-		/* KJD - need to complete this */
-		u_long t;
-		int mode, err, keysize;
-
-		/* Algorithm name. */
-		T(addname(msg, msglen, &rdata, origin, &buf, &buflen));
-		T(addstr(" ", 1, &buf, &buflen));
-
-		/* Inception. */
-		t = ns_get32(rdata);  rdata += NS_INT32SZ;
-		len = SPRINTF((tmp, "%s ", p_secstodate(t)));
-		T(addstr(tmp, len, &buf, &buflen));
-
-		/* Experation. */
-		t = ns_get32(rdata);  rdata += NS_INT32SZ;
-		len = SPRINTF((tmp, "%s ", p_secstodate(t)));
-		T(addstr(tmp, len, &buf, &buflen));
-
-		/* Mode , Error, Key Size. */
-		/* Priority, Weight, Port. */
-		mode = ns_get16(rdata);  rdata += NS_INT16SZ;
-		err  = ns_get16(rdata);  rdata += NS_INT16SZ;
-		keysize  = ns_get16(rdata);  rdata += NS_INT16SZ;
-		len = SPRINTF((tmp, "%u %u %u ", mode, err, keysize));
-		T(addstr(tmp, len, &buf, &buflen));
-
-		/* XXX need to dump key, print otherdata length & other data */
-		break;
-	    }
-
-	case ns_t_tsig: {
-		/* BEW - need to complete this */
-		int n;
-
-		T(len = addname(msg, msglen, &rdata, origin, &buf, &buflen));
-		T(addstr(" ", 1, &buf, &buflen));
-		rdata += 8; /*%< time */
-		n = ns_get16(rdata); rdata += INT16SZ;
-		rdata += n; /*%< sig */
-		n = ns_get16(rdata); rdata += INT16SZ; /*%< original id */
-		sprintf(buf, "%d", ns_get16(rdata));
-		rdata += INT16SZ;
-		addlen(strlen(buf), &buf, &buflen);
-		break;
-	    }
-
-	case ns_t_a6: {
-		struct in6_addr a;
-		int pbyte, pbit;
-
-		/* prefix length */
-		if (rdlen == 0U) goto formerr;
-		len = SPRINTF((tmp, "%d ", *rdata));
-		T(addstr(tmp, len, &buf, &buflen));
-		pbit = *rdata;
-		if (pbit > 128) goto formerr;
-		pbyte = (pbit & ~7) / 8;
-		rdata++;
-
-		/* address suffix: provided only when prefix len != 128 */
-		if (pbit < 128) {
-			if (rdata + pbyte >= edata) goto formerr;
-			memset(&a, 0, sizeof(a));
-			memcpy(&a.s6_addr[pbyte], rdata, sizeof(a) - pbyte);
-			(void) inet_ntop(AF_INET6, &a, buf, buflen);
-			addlen(strlen(buf), &buf, &buflen);
-			rdata += sizeof(a) - pbyte;
-		}
-
-		/* prefix name: provided only when prefix len > 0 */
-		if (pbit == 0)
-			break;
-		if (rdata >= edata) goto formerr;
-		T(addstr(" ", 1, &buf, &buflen));
-		T(addname(msg, msglen, &rdata, origin, &buf, &buflen));
-		
-		break;
-	    }
-
-	case ns_t_opt: {
-		len = SPRINTF((tmp, "%u bytes", class));
-		T(addstr(tmp, len, &buf, &buflen));
-		break;
-	    }
-
-	default:
-		comment = "unknown RR type";
-		goto hexify;
-	}
-	return (buf - obuf);
- formerr:
-	comment = "RR format error";
- hexify: {
-	int n, m;
-	char *p;
-
-	len = SPRINTF((tmp, "\\# %u%s\t; %s", (unsigned)(edata - rdata),
-		       rdlen != 0U ? " (" : "", comment));
-	T(addstr(tmp, len, &buf, &buflen));
-	while (rdata < edata) {
-		p = tmp;
-		p += SPRINTF((p, "\n\t"));
-		spaced = 0;
-		n = MIN(16, edata - rdata);
-		for (m = 0; m < n; m++)
-			p += SPRINTF((p, "%02x ", rdata[m]));
-		T(addstr(tmp, p - tmp, &buf, &buflen));
-		if (n < 16) {
-			T(addstr(")", 1, &buf, &buflen));
-			T(addtab(p - tmp + 1, 48, spaced, &buf, &buflen));
-		}
-		p = tmp;
-		p += SPRINTF((p, "; "));
-		for (m = 0; m < n; m++)
-			*p++ = (isascii(rdata[m]) && isprint(rdata[m]))
-				? rdata[m]
-				: '.';
-		T(addstr(tmp, p - tmp, &buf, &buflen));
-		rdata += n;
-	}
-	return (buf - obuf);
-    }
-}
-
-/* Private. */
-
-/*%
- * size_t
- * prune_origin(name, origin)
- *	Find out if the name is at or under the current origin.
- * return:
- *	Number of characters in name before start of origin,
- *	or length of name if origin does not match.
- * notes:
- *	This function should share code with samedomain().
- */
-static size_t
-prune_origin(const char *name, const char *origin) {
-	const char *oname = name;
-
-	while (*name != '\0') {
-		if (origin != NULL && ns_samename(name, origin) == 1)
-			return (name - oname - (name > oname));
-		while (*name != '\0') {
-			if (*name == '\\') {
-				name++;
-				/* XXX need to handle \nnn form. */
-				if (*name == '\0')
-					break;
-			} else if (*name == '.') {
-				name++;
-				break;
-			}
-			name++;
-		}
-	}
-	return (name - oname);
-}
-
-/*%
- * int
- * charstr(rdata, edata, buf, buflen)
- *	Format a <character-string> into the presentation buffer.
- * return:
- *	Number of rdata octets consumed
- *	0 for protocol format error
- *	-1 for output buffer error
- * side effects:
- *	buffer is advanced on success.
- */
-static int
-charstr(const u_char *rdata, const u_char *edata, char **buf, size_t *buflen) {
-	const u_char *odata = rdata;
-	size_t save_buflen = *buflen;
-	char *save_buf = *buf;
-
-	if (addstr("\"", 1, buf, buflen) < 0)
-		goto enospc;
-	if (rdata < edata) {
-		int n = *rdata;
-
-		if (rdata + 1 + n <= edata) {
-			rdata++;
-			while (n-- > 0) {
-				if (strchr("\n\"\\", *rdata) != NULL)
-					if (addstr("\\", 1, buf, buflen) < 0)
-						goto enospc;
-				if (addstr((const char *)rdata, 1,
-					   buf, buflen) < 0)
-					goto enospc;
-				rdata++;
-			}
-		}
-	}
-	if (addstr("\"", 1, buf, buflen) < 0)
-		goto enospc;
-	return (rdata - odata);
- enospc:
-	errno = ENOSPC;
-	*buf = save_buf;
-	*buflen = save_buflen;
-	return (-1);
-}
-
-static int
-addname(const u_char *msg, size_t msglen,
-	const u_char **pp, const char *origin,
-	char **buf, size_t *buflen)
-{
-	size_t newlen, save_buflen = *buflen;
-	char *save_buf = *buf;
-	int n;
-
-	n = dn_expand(msg, msg + msglen, *pp, *buf, *buflen);
-	if (n < 0)
-		goto enospc;	/*%< Guess. */
-	newlen = prune_origin(*buf, origin);
-	if (**buf == '\0') {
-		goto root;
-	} else if (newlen == 0U) {
-		/* Use "@" instead of name. */
-		if (newlen + 2 > *buflen)
-			goto enospc;        /* No room for "@\0". */
-		(*buf)[newlen++] = '@';
-		(*buf)[newlen] = '\0';
-	} else {
-		if (((origin == NULL || origin[0] == '\0') ||
-		    (origin[0] != '.' && origin[1] != '\0' &&
-		    (*buf)[newlen] == '\0')) && (*buf)[newlen - 1] != '.') {
-			/* No trailing dot. */
- root:
-			if (newlen + 2 > *buflen)
-				goto enospc;	/* No room for ".\0". */
-			(*buf)[newlen++] = '.';
-			(*buf)[newlen] = '\0';
-		}
-	}
-	*pp += n;
-	addlen(newlen, buf, buflen);
-	**buf = '\0';
-	return (newlen);
- enospc:
-	errno = ENOSPC;
-	*buf = save_buf;
-	*buflen = save_buflen;
-	return (-1);
-}
-
-static void
-addlen(size_t len, char **buf, size_t *buflen) {
-	INSIST(len <= *buflen);
-	*buf += len;
-	*buflen -= len;
-}
-
-static int
-addstr(const char *src, size_t len, char **buf, size_t *buflen) {
-	if (len >= *buflen) {
-		errno = ENOSPC;
-		return (-1);
-	}
-	memcpy(*buf, src, len);
-	addlen(len, buf, buflen);
-	**buf = '\0';
-	return (0);
-}
-
-static int
-addtab(size_t len, size_t target, int spaced, char **buf, size_t *buflen) {
-	size_t save_buflen = *buflen;
-	char *save_buf = *buf;
-	int t;
-
-	if (spaced || len >= target - 1) {
-		T(addstr("  ", 2, buf, buflen));
-		spaced = 1;
-	} else {
-		for (t = (target - len - 1) / 8; t >= 0; t--)
-			if (addstr("\t", 1, buf, buflen) < 0) {
-				*buflen = save_buflen;
-				*buf = save_buf;
-				return (-1);
-			}
-		spaced = 0;
-	}
-	return (spaced);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/nameser/ns_samedomain.c b/contrib/bind9/lib/bind/nameser/ns_samedomain.c
deleted file mode 100644
index a720f6a..0000000
--- a/contrib/bind9/lib/bind/nameser/ns_samedomain.c
+++ /dev/null
@@ -1,207 +0,0 @@
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-#ifndef lint
-static const char rcsid[] = "$Id: ns_samedomain.c,v 1.5.18.1 2005/04/27 05:01:09 sra Exp $";
-#endif
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <arpa/nameser.h>
-#include <errno.h>
-#include <string.h>
-
-#include "port_after.h"
-
-/*%
- *	Check whether a name belongs to a domain.
- *
- * Inputs:
- *\li	a - the domain whose ancestory is being verified
- *\li	b - the potential ancestor we're checking against
- *
- * Return:
- *\li	boolean - is a at or below b?
- *
- * Notes:
- *\li	Trailing dots are first removed from name and domain.
- *	Always compare complete subdomains, not only whether the
- *	domain name is the trailing string of the given name.
- *
- *\li	"host.foobar.top" lies in "foobar.top" and in "top" and in ""
- *	but NOT in "bar.top"
- */
-
-int
-ns_samedomain(const char *a, const char *b) {
-	size_t la, lb;
-	int diff, i, escaped;
-	const char *cp;
-
-	la = strlen(a);
-	lb = strlen(b);
-
-	/* Ignore a trailing label separator (i.e. an unescaped dot) in 'a'. */
-	if (la != 0U && a[la - 1] == '.') {
-		escaped = 0;
-		/* Note this loop doesn't get executed if la==1. */
-		for (i = la - 2; i >= 0; i--)
-			if (a[i] == '\\') {
-				if (escaped)
-					escaped = 0;
-				else
-					escaped = 1;
-			} else
-				break;
-		if (!escaped)
-			la--;
-	}
-
-	/* Ignore a trailing label separator (i.e. an unescaped dot) in 'b'. */
-	if (lb != 0U && b[lb - 1] == '.') {
-		escaped = 0;
-		/* note this loop doesn't get executed if lb==1 */
-		for (i = lb - 2; i >= 0; i--)
-			if (b[i] == '\\') {
-				if (escaped)
-					escaped = 0;
-				else
-					escaped = 1;
-			} else
-				break;
-		if (!escaped)
-			lb--;
-	}
-
-	/* lb == 0 means 'b' is the root domain, so 'a' must be in 'b'. */
-	if (lb == 0U)
-		return (1);
-
-	/* 'b' longer than 'a' means 'a' can't be in 'b'. */
-	if (lb > la)
-		return (0);
-
-	/* 'a' and 'b' being equal at this point indicates sameness. */
-	if (lb == la)
-		return (strncasecmp(a, b, lb) == 0);
-
-	/* Ok, we know la > lb. */
-
-	diff = la - lb;
-
-	/*
-	 * If 'a' is only 1 character longer than 'b', then it can't be
-	 * a subdomain of 'b' (because of the need for the '.' label
-	 * separator).
-	 */
-	if (diff < 2)
-		return (0);
-
-	/*
-	 * If the character before the last 'lb' characters of 'b'
-	 * isn't '.', then it can't be a match (this lets us avoid
-	 * having "foobar.com" match "bar.com").
-	 */
-	if (a[diff - 1] != '.')
-		return (0);
-
-	/*
-	 * We're not sure about that '.', however.  It could be escaped
-         * and thus not a really a label separator.
-	 */
-	escaped = 0;
-	for (i = diff - 2; i >= 0; i--)
-		if (a[i] == '\\') {
-			if (escaped)
-				escaped = 0;
-			else
-				escaped = 1;
-		} else
-			break;
-	if (escaped)
-		return (0);
-	  
-	/* Now compare aligned trailing substring. */
-	cp = a + diff;
-	return (strncasecmp(cp, b, lb) == 0);
-}
-
-/*%
- *	is "a" a subdomain of "b"?
- */
-int
-ns_subdomain(const char *a, const char *b) {
-	return (ns_samename(a, b) != 1 && ns_samedomain(a, b));
-}
-
-/*%
- *	make a canonical copy of domain name "src"
- *
- * notes:
- * \code
- *	foo -> foo.
- *	foo. -> foo.
- *	foo.. -> foo.
- *	foo\. -> foo\..
- *	foo\\. -> foo\\.
- * \endcode
- */
-
-int
-ns_makecanon(const char *src, char *dst, size_t dstsize) {
-	size_t n = strlen(src);
-
-	if (n + sizeof "." > dstsize) {			/*%< Note: sizeof == 2 */
-		errno = EMSGSIZE;
-		return (-1);
-	}
-	strcpy(dst, src);
-	while (n >= 1U && dst[n - 1] == '.')		/*%< Ends in "." */
-		if (n >= 2U && dst[n - 2] == '\\' &&	/*%< Ends in "\." */
-		    (n < 3U || dst[n - 3] != '\\'))	/*%< But not "\\." */
-			break;
-		else
-			dst[--n] = '\0';
-	dst[n++] = '.';
-	dst[n] = '\0';
-	return (0);
-}
-
-/*%
- *	determine whether domain name "a" is the same as domain name "b"
- *
- * return:
- *\li	-1 on error
- *\li	0 if names differ
- *\li	1 if names are the same
- */
-
-int
-ns_samename(const char *a, const char *b) {
-	char ta[NS_MAXDNAME], tb[NS_MAXDNAME];
-
-	if (ns_makecanon(a, ta, sizeof ta) < 0 ||
-	    ns_makecanon(b, tb, sizeof tb) < 0)
-		return (-1);
-	if (strcasecmp(ta, tb) == 0)
-		return (1);
-	else
-		return (0);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/nameser/ns_sign.c b/contrib/bind9/lib/bind/nameser/ns_sign.c
deleted file mode 100644
index ab4b0ef..0000000
--- a/contrib/bind9/lib/bind/nameser/ns_sign.c
+++ /dev/null
@@ -1,387 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1999 by Internet Software Consortium, 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 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.
- */
-
-#ifndef lint
-static const char rcsid[] = "$Id: ns_sign.c,v 1.4.18.2 2006/03/10 00:20:08 marka Exp $";
-#endif
-
-/* Import. */
-
-#include "port_before.h"
-#include "fd_setsize.h"
-
-#include <sys/types.h>
-#include <sys/param.h>
-
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <arpa/inet.h>
-
-#include <errno.h>
-#include <netdb.h>
-#include <resolv.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <time.h>
-#include <unistd.h>
-
-#include <isc/dst.h>
-#include <isc/assertions.h>
-
-#include "port_after.h"
-
-#define BOUNDS_CHECK(ptr, count) \
-	do { \
-		if ((ptr) + (count) > eob) { \
-			errno = EMSGSIZE; \
-			return(NS_TSIG_ERROR_NO_SPACE); \
-		} \
-	} while (0)
-
-/*%
- *  ns_sign
- *
- * Parameters:
- *\li	msg		message to be sent
- *\li	msglen		input - length of message
- *			output - length of signed message
- *\li	msgsize		length of buffer containing message
- *\li	error		value to put in the error field
- *\li	key		tsig key used for signing
- *\li	querysig	(response), the signature in the query
- *\li	querysiglen	(response), the length of the signature in the query
- *\li	sig		a buffer to hold the generated signature
- *\li	siglen		input - length of signature buffer
- *			output - length of signature
- *
- * Errors:
- *\li	- bad input data (-1)
- *\li	- bad key / sign failed (-BADKEY)
- *\li	- not enough space (NS_TSIG_ERROR_NO_SPACE)
- */
-int
-ns_sign(u_char *msg, int *msglen, int msgsize, int error, void *k,
-	const u_char *querysig, int querysiglen, u_char *sig, int *siglen,
-	time_t in_timesigned)
-{
-	return(ns_sign2(msg, msglen, msgsize, error, k,
-			querysig, querysiglen, sig, siglen,
-			in_timesigned, NULL, NULL));
-}
-
-int
-ns_sign2(u_char *msg, int *msglen, int msgsize, int error, void *k,
-	 const u_char *querysig, int querysiglen, u_char *sig, int *siglen,
-	 time_t in_timesigned, u_char **dnptrs, u_char **lastdnptr)
-{
-	HEADER *hp = (HEADER *)msg;
-	DST_KEY *key = (DST_KEY *)k;
-	u_char *cp, *eob;
-	u_char *lenp;
-	u_char *alg;
-	int n;
-	time_t timesigned;
-        u_char name[NS_MAXCDNAME];
-
-	dst_init();
-	if (msg == NULL || msglen == NULL || sig == NULL || siglen == NULL)
-		return (-1);
-
-	cp = msg + *msglen;
-	eob = msg + msgsize;
-
-	/* Name. */
-	if (key != NULL && error != ns_r_badsig && error != ns_r_badkey) {
-		n = ns_name_pton(key->dk_key_name, name, sizeof name);
-		if (n != -1)
-			n = ns_name_pack(name, cp, eob - cp,
-					 (const u_char **)dnptrs,
-					 (const u_char **)lastdnptr);
-
-	} else {
-		n = ns_name_pton("", name, sizeof name);
-		if (n != -1)
-			n = ns_name_pack(name, cp, eob - cp, NULL, NULL);
-	}
-	if (n < 0)
-		return (NS_TSIG_ERROR_NO_SPACE);
-	cp += n;
-
-	/* Type, class, ttl, length (not filled in yet). */
-	BOUNDS_CHECK(cp, INT16SZ + INT16SZ + INT32SZ + INT16SZ);
-	PUTSHORT(ns_t_tsig, cp);
-	PUTSHORT(ns_c_any, cp);
-	PUTLONG(0, cp);		/*%< TTL */
-	lenp = cp;
-	cp += 2;
-
-	/* Alg. */
-	if (key != NULL && error != ns_r_badsig && error != ns_r_badkey) {
-		if (key->dk_alg != KEY_HMAC_MD5)
-			return (-ns_r_badkey);
-		n = dn_comp(NS_TSIG_ALG_HMAC_MD5, cp, eob - cp, NULL, NULL);
-	}
-	else
-		n = dn_comp("", cp, eob - cp, NULL, NULL);
-	if (n < 0)
-		return (NS_TSIG_ERROR_NO_SPACE);
-	alg = cp;
-	cp += n;
-	
-	/* Time. */
-	BOUNDS_CHECK(cp, INT16SZ + INT32SZ + INT16SZ);
-	PUTSHORT(0, cp);
-	timesigned = time(NULL);
-	if (error != ns_r_badtime)
-		PUTLONG(timesigned, cp);
-	else
-		PUTLONG(in_timesigned, cp);
-	PUTSHORT(NS_TSIG_FUDGE, cp);
-
-	/* Compute the signature. */
-	if (key != NULL && error != ns_r_badsig && error != ns_r_badkey) {
-		void *ctx;
-		u_char buf[NS_MAXCDNAME], *cp2;
-		int n;
-
-		dst_sign_data(SIG_MODE_INIT, key, &ctx, NULL, 0, NULL, 0);
-
-		/* Digest the query signature, if this is a response. */
-		if (querysiglen > 0 && querysig != NULL) {
-			u_int16_t len_n = htons(querysiglen);
-			dst_sign_data(SIG_MODE_UPDATE, key, &ctx,
-				      (u_char *)&len_n, INT16SZ, NULL, 0);
-			dst_sign_data(SIG_MODE_UPDATE, key, &ctx,
-				      querysig, querysiglen, NULL, 0);
-		}
-
-		/* Digest the message. */
-		dst_sign_data(SIG_MODE_UPDATE, key, &ctx, msg, *msglen,
-			      NULL, 0);
-
-		/* Digest the key name. */
-		n = ns_name_ntol(name, buf, sizeof(buf));
-		INSIST(n > 0);
-		dst_sign_data(SIG_MODE_UPDATE, key, &ctx, buf, n, NULL, 0);
-
-		/* Digest the class and TTL. */
-		cp2 = buf;
-		PUTSHORT(ns_c_any, cp2);
-		PUTLONG(0, cp2);
-		dst_sign_data(SIG_MODE_UPDATE, key, &ctx, buf, cp2-buf,
-			      NULL, 0);
-
-		/* Digest the algorithm. */
-		n = ns_name_ntol(alg, buf, sizeof(buf));
-		INSIST(n > 0);
-		dst_sign_data(SIG_MODE_UPDATE, key, &ctx, buf, n, NULL, 0);
-
-		/* Digest the time signed, fudge, error, and other data */
-		cp2 = buf;
-		PUTSHORT(0, cp2);	/*%< Top 16 bits of time */
-		if (error != ns_r_badtime)
-			PUTLONG(timesigned, cp2);
-		else
-			PUTLONG(in_timesigned, cp2);
-		PUTSHORT(NS_TSIG_FUDGE, cp2);
-		PUTSHORT(error, cp2);	/*%< Error */
-		if (error != ns_r_badtime)
-			PUTSHORT(0, cp2);	/*%< Other data length */
-		else {
-			PUTSHORT(INT16SZ+INT32SZ, cp2);	/*%< Other data length */
-			PUTSHORT(0, cp2);	/*%< Top 16 bits of time */
-			PUTLONG(timesigned, cp2);
-		}
-		dst_sign_data(SIG_MODE_UPDATE, key, &ctx, buf, cp2-buf,
-			      NULL, 0);
-
-		n = dst_sign_data(SIG_MODE_FINAL, key, &ctx, NULL, 0,
-				  sig, *siglen);
-		if (n < 0)
-			return (-ns_r_badkey);
-		*siglen = n;
-	} else
-		*siglen = 0;
-
-	/* Add the signature. */
-	BOUNDS_CHECK(cp, INT16SZ + (*siglen));
-	PUTSHORT(*siglen, cp);
-	memcpy(cp, sig, *siglen);
-	cp += (*siglen);
-
-	/* The original message ID & error. */
-	BOUNDS_CHECK(cp, INT16SZ + INT16SZ);
-	PUTSHORT(ntohs(hp->id), cp);	/*%< already in network order */
-	PUTSHORT(error, cp);
-
-	/* Other data. */
-	BOUNDS_CHECK(cp, INT16SZ);
-	if (error != ns_r_badtime)
-		PUTSHORT(0, cp);	/*%< Other data length */
-	else {
-		PUTSHORT(INT16SZ+INT32SZ, cp);	/*%< Other data length */
-		BOUNDS_CHECK(cp, INT32SZ+INT16SZ);
-		PUTSHORT(0, cp);	/*%< Top 16 bits of time */
-		PUTLONG(timesigned, cp);
-	}
-
-	/* Go back and fill in the length. */
-	PUTSHORT(cp - lenp - INT16SZ, lenp);
-
-	hp->arcount = htons(ntohs(hp->arcount) + 1);
-	*msglen = (cp - msg);
-	return (0);
-}
-
-int
-ns_sign_tcp_init(void *k, const u_char *querysig, int querysiglen,
-		 ns_tcp_tsig_state *state)
-{
-	dst_init();
-	if (state == NULL || k == NULL || querysig == NULL || querysiglen < 0)
-		return (-1);
-	state->counter = -1;
-	state->key = k;
-	if (state->key->dk_alg != KEY_HMAC_MD5)
-		return (-ns_r_badkey);
-	if (querysiglen > (int)sizeof(state->sig))
-		return (-1);
-	memcpy(state->sig, querysig, querysiglen);
-	state->siglen = querysiglen;
-	return (0);
-}
-
-int
-ns_sign_tcp(u_char *msg, int *msglen, int msgsize, int error,
-	    ns_tcp_tsig_state *state, int done)
-{
-	return (ns_sign_tcp2(msg, msglen, msgsize, error, state,
-			     done, NULL, NULL));
-}
-
-int
-ns_sign_tcp2(u_char *msg, int *msglen, int msgsize, int error,
-	     ns_tcp_tsig_state *state, int done,
-	     u_char **dnptrs, u_char **lastdnptr)
-{
-	u_char *cp, *eob, *lenp;
-	u_char buf[MAXDNAME], *cp2;
-	HEADER *hp = (HEADER *)msg;
-	time_t timesigned;
-	int n;
-
-	if (msg == NULL || msglen == NULL || state == NULL)
-		return (-1);
-
-	state->counter++;
-	if (state->counter == 0)
-		return (ns_sign2(msg, msglen, msgsize, error, state->key,
-				 state->sig, state->siglen,
-				 state->sig, &state->siglen, 0,
-				 dnptrs, lastdnptr));
-
-	if (state->siglen > 0) {
-		u_int16_t siglen_n = htons(state->siglen);
-		dst_sign_data(SIG_MODE_INIT, state->key, &state->ctx,
-			      NULL, 0, NULL, 0);
-		dst_sign_data(SIG_MODE_UPDATE, state->key, &state->ctx,
-			      (u_char *)&siglen_n, INT16SZ, NULL, 0);
-		dst_sign_data(SIG_MODE_UPDATE, state->key, &state->ctx,
-			      state->sig, state->siglen, NULL, 0);
-		state->siglen = 0;
-	}
-
-	dst_sign_data(SIG_MODE_UPDATE, state->key, &state->ctx, msg, *msglen,
-		      NULL, 0);
-
-	if (done == 0 && (state->counter % 100 != 0))
-		return (0);
-
-	cp = msg + *msglen;
-	eob = msg + msgsize;
-
-	/* Name. */
-	n = dn_comp(state->key->dk_key_name, cp, eob - cp, dnptrs, lastdnptr);
-	if (n < 0)
-		return (NS_TSIG_ERROR_NO_SPACE);
-	cp += n;
-
-	/* Type, class, ttl, length (not filled in yet). */
-	BOUNDS_CHECK(cp, INT16SZ + INT16SZ + INT32SZ + INT16SZ);
-	PUTSHORT(ns_t_tsig, cp);
-	PUTSHORT(ns_c_any, cp);
-	PUTLONG(0, cp);		/*%< TTL */
-	lenp = cp;
-	cp += 2;
-
-	/* Alg. */
-	n = dn_comp(NS_TSIG_ALG_HMAC_MD5, cp, eob - cp, NULL, NULL);
-	if (n < 0)
-		return (NS_TSIG_ERROR_NO_SPACE);
-	cp += n;
-	
-	/* Time. */
-	BOUNDS_CHECK(cp, INT16SZ + INT32SZ + INT16SZ);
-	PUTSHORT(0, cp);
-	timesigned = time(NULL);
-	PUTLONG(timesigned, cp);
-	PUTSHORT(NS_TSIG_FUDGE, cp);
-
-	/*
-	 * Compute the signature.
-	 */
-
-	/* Digest the time signed and fudge. */
-	cp2 = buf;
-	PUTSHORT(0, cp2);	/*%< Top 16 bits of time */
-	PUTLONG(timesigned, cp2);
-	PUTSHORT(NS_TSIG_FUDGE, cp2);
-
-	dst_sign_data(SIG_MODE_UPDATE, state->key, &state->ctx,
-		      buf, cp2 - buf, NULL, 0);
-
-	n = dst_sign_data(SIG_MODE_FINAL, state->key, &state->ctx, NULL, 0,
-			  state->sig, sizeof(state->sig));
-	if (n < 0)
-		return (-ns_r_badkey);
-	state->siglen = n;
-
-	/* Add the signature. */
-	BOUNDS_CHECK(cp, INT16SZ + state->siglen);
-	PUTSHORT(state->siglen, cp);
-	memcpy(cp, state->sig, state->siglen);
-	cp += state->siglen;
-
-	/* The original message ID & error. */
-	BOUNDS_CHECK(cp, INT16SZ + INT16SZ);
-	PUTSHORT(ntohs(hp->id), cp);	/*%< already in network order */
-	PUTSHORT(error, cp);
-
-	/* Other data. */
-	BOUNDS_CHECK(cp, INT16SZ);
-	PUTSHORT(0, cp);
-
-	/* Go back and fill in the length. */
-	PUTSHORT(cp - lenp - INT16SZ, lenp);
-
-	hp->arcount = htons(ntohs(hp->arcount) + 1);
-	*msglen = (cp - msg);
-	return (0);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/nameser/ns_ttl.c b/contrib/bind9/lib/bind/nameser/ns_ttl.c
deleted file mode 100644
index 627ddf1..0000000
--- a/contrib/bind9/lib/bind/nameser/ns_ttl.c
+++ /dev/null
@@ -1,162 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#ifndef lint
-static const char rcsid[] = "$Id: ns_ttl.c,v 1.2.18.2 2005/07/28 07:38:10 marka Exp $";
-#endif
-
-/* Import. */
-
-#include "port_before.h"
-
-#include <arpa/nameser.h>
-
-#include <ctype.h>
-#include <errno.h>
-#include <stdio.h>
-#include <string.h>
-
-#include "port_after.h"
-
-#ifdef SPRINTF_CHAR
-# define SPRINTF(x) strlen(sprintf/**/x)
-#else
-# define SPRINTF(x) ((size_t)sprintf x)
-#endif
-
-/* Forward. */
-
-static int	fmt1(int t, char s, char **buf, size_t *buflen);
-
-/* Macros. */
-
-#define T(x) if ((x) < 0) return (-1); else (void)NULL
-
-/* Public. */
-
-int
-ns_format_ttl(u_long src, char *dst, size_t dstlen) {
-	char *odst = dst;
-	int secs, mins, hours, days, weeks, x;
-	char *p;
-
-	secs = src % 60;   src /= 60;
-	mins = src % 60;   src /= 60;
-	hours = src % 24;  src /= 24;
-	days = src % 7;    src /= 7;
-	weeks = src;       src = 0;
-
-	x = 0;
-	if (weeks) {
-		T(fmt1(weeks, 'W', &dst, &dstlen));
-		x++;
-	}
-	if (days) {
-		T(fmt1(days, 'D', &dst, &dstlen));
-		x++;
-	}
-	if (hours) {
-		T(fmt1(hours, 'H', &dst, &dstlen));
-		x++;
-	}
-	if (mins) {
-		T(fmt1(mins, 'M', &dst, &dstlen));
-		x++;
-	}
-	if (secs || !(weeks || days || hours || mins)) {
-		T(fmt1(secs, 'S', &dst, &dstlen));
-		x++;
-	}
-
-	if (x > 1) {
-		int ch;
-
-		for (p = odst; (ch = *p) != '\0'; p++)
-			if (isascii(ch) && isupper(ch))
-				*p = tolower(ch);
-	}
-
-	return (dst - odst);
-}
-
-int
-ns_parse_ttl(const char *src, u_long *dst) {
-	u_long ttl, tmp;
-	int ch, digits, dirty;
-
-	ttl = 0;
-	tmp = 0;
-	digits = 0;
-	dirty = 0;
-	while ((ch = *src++) != '\0') {
-		if (!isascii(ch) || !isprint(ch))
-			goto einval;
-		if (isdigit(ch)) {
-			tmp *= 10;
-			tmp += (ch - '0');
-			digits++;
-			continue;
-		}
-		if (digits == 0)
-			goto einval;
-		if (islower(ch))
-			ch = toupper(ch);
-		switch (ch) {
-		case 'W':  tmp *= 7;
-		case 'D':  tmp *= 24;
-		case 'H':  tmp *= 60;
-		case 'M':  tmp *= 60;
-		case 'S':  break;
-		default:   goto einval;
-		}
-		ttl += tmp;
-		tmp = 0;
-		digits = 0;
-		dirty = 1;
-	}
-	if (digits > 0) {
-		if (dirty)
-			goto einval;
-		else
-			ttl += tmp;
-	} else if (!dirty)
-		goto einval;
-	*dst = ttl;
-	return (0);
-
- einval:
-	errno = EINVAL;
-	return (-1);
-}
-
-/* Private. */
-
-static int
-fmt1(int t, char s, char **buf, size_t *buflen) {
-	char tmp[50];
-	size_t len;
-
-	len = SPRINTF((tmp, "%d%c", t, s));
-	if (len + 1 > *buflen)
-		return (-1);
-	strcpy(*buf, tmp);
-	*buf += len;
-	*buflen -= len;
-	return (0);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/nameser/ns_verify.c b/contrib/bind9/lib/bind/nameser/ns_verify.c
deleted file mode 100644
index b80b588..0000000
--- a/contrib/bind9/lib/bind/nameser/ns_verify.c
+++ /dev/null
@@ -1,484 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1999 by Internet Software Consortium, 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 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.
- */
-
-#ifndef lint
-static const char rcsid[] = "$Id: ns_verify.c,v 1.2.18.3 2006/03/10 00:20:08 marka Exp $";
-#endif
-
-/* Import. */
-
-#include "port_before.h"
-#include "fd_setsize.h"
-
-#include <sys/types.h>
-#include <sys/param.h>
-
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <arpa/inet.h>
-
-#include <errno.h>
-#include <netdb.h>
-#include <resolv.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <time.h>
-#include <unistd.h>
-
-#include <isc/dst.h>
-
-#include "port_after.h"
-
-/* Private. */
-
-#define BOUNDS_CHECK(ptr, count) \
-	do { \
-		if ((ptr) + (count) > eom) { \
-			return (NS_TSIG_ERROR_FORMERR); \
-		} \
-	} while (0)
-
-/* Public. */
-
-u_char *
-ns_find_tsig(u_char *msg, u_char *eom) {
-	HEADER *hp = (HEADER *)msg;
-	int n, type;
-	u_char *cp = msg, *start;
-
-	if (msg == NULL || eom == NULL || msg > eom)
-		return (NULL);
-
-	if (cp + HFIXEDSZ >= eom)
-		return (NULL);
-
-	if (hp->arcount == 0)
-		return (NULL);
-
-	cp += HFIXEDSZ;
-
-	n = ns_skiprr(cp, eom, ns_s_qd, ntohs(hp->qdcount));
-	if (n < 0)
-		return (NULL);
-	cp += n;
-
-	n = ns_skiprr(cp, eom, ns_s_an, ntohs(hp->ancount));
-	if (n < 0)
-		return (NULL);
-	cp += n;
-
-	n = ns_skiprr(cp, eom, ns_s_ns, ntohs(hp->nscount));
-	if (n < 0)
-		return (NULL);
-	cp += n;
-
-	n = ns_skiprr(cp, eom, ns_s_ar, ntohs(hp->arcount) - 1);
-	if (n < 0)
-		return (NULL);
-	cp += n;
-
-	start = cp;
-	n = dn_skipname(cp, eom);
-	if (n < 0)
-		return (NULL);
-	cp += n;
-	if (cp + INT16SZ >= eom)
-		return (NULL);
-
-	GETSHORT(type, cp);
-	if (type != ns_t_tsig)
-		return (NULL);
-	return (start);
-}
-
-/* ns_verify
- *
- * Parameters:
- *\li	statp		res stuff
- *\li	msg		received message
- *\li	msglen		length of message
- *\li	key		tsig key used for verifying.
- *\li	querysig	(response), the signature in the query
- *\li	querysiglen	(response), the length of the signature in the query
- *\li	sig		(query), a buffer to hold the signature
- *\li	siglen		(query), input - length of signature buffer
- *				 output - length of signature
- *
- * Errors:
- *\li	- bad input (-1)
- *\li	- invalid dns message (NS_TSIG_ERROR_FORMERR)
- *\li	- TSIG is not present (NS_TSIG_ERROR_NO_TSIG)
- *\li	- key doesn't match (-ns_r_badkey)
- *\li	- TSIG verification fails with BADKEY (-ns_r_badkey)
- *\li	- TSIG verification fails with BADSIG (-ns_r_badsig)
- *\li	- TSIG verification fails with BADTIME (-ns_r_badtime)
- *\li	- TSIG verification succeeds, error set to BAKEY (ns_r_badkey)
- *\li	- TSIG verification succeeds, error set to BADSIG (ns_r_badsig)
- *\li	- TSIG verification succeeds, error set to BADTIME (ns_r_badtime)
- */
-int
-ns_verify(u_char *msg, int *msglen, void *k,
-	  const u_char *querysig, int querysiglen, u_char *sig, int *siglen,
-	  time_t *timesigned, int nostrip)
-{
-	HEADER *hp = (HEADER *)msg;
-	DST_KEY *key = (DST_KEY *)k;
-	u_char *cp = msg, *eom;
-	char name[MAXDNAME], alg[MAXDNAME];
-	u_char *recstart, *rdatastart;
-	u_char *sigstart, *otherstart;
-	int n;
-	int error;
-	u_int16_t type, length;
-	u_int16_t fudge, sigfieldlen, otherfieldlen;
-
-	dst_init();
-	if (msg == NULL || msglen == NULL || *msglen < 0)
-		return (-1);
-
-	eom = msg + *msglen;
-
-	recstart = ns_find_tsig(msg, eom);
-	if (recstart == NULL)
-		return (NS_TSIG_ERROR_NO_TSIG);
-
-	cp = recstart;
-
-	/* Read the key name. */
-	n = dn_expand(msg, eom, cp, name, MAXDNAME);
-	if (n < 0)
-		return (NS_TSIG_ERROR_FORMERR);
-	cp += n;
-
-	/* Read the type. */
-	BOUNDS_CHECK(cp, 2*INT16SZ + INT32SZ + INT16SZ);
-	GETSHORT(type, cp);
-	if (type != ns_t_tsig)
-		return (NS_TSIG_ERROR_NO_TSIG);
-
-	/* Skip the class and TTL, save the length. */
-	cp += INT16SZ + INT32SZ;
-	GETSHORT(length, cp);
-	if (eom - cp != length)
-		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);
-	if (ns_samename(alg, NS_TSIG_ALG_HMAC_MD5) != 1)
-		return (-ns_r_badkey);
-	cp += n;
-
-	/* Read the time signed and fudge. */
-	BOUNDS_CHECK(cp, INT16SZ + INT32SZ + INT16SZ);
-	cp += INT16SZ;
-	GETLONG((*timesigned), cp);
-	GETSHORT(fudge, cp);
-
-	/* Read the signature. */
-	BOUNDS_CHECK(cp, INT16SZ);
-	GETSHORT(sigfieldlen, cp);
-	BOUNDS_CHECK(cp, sigfieldlen);
-	sigstart = cp;
-	cp += sigfieldlen;
-
-	/* Skip id and read error. */
-	BOUNDS_CHECK(cp, 2*INT16SZ);
-	cp += INT16SZ;
-	GETSHORT(error, cp);
-
-	/* Parse the other data. */
-	BOUNDS_CHECK(cp, INT16SZ);
-	GETSHORT(otherfieldlen, cp);
-	BOUNDS_CHECK(cp, otherfieldlen);
-	otherstart = cp;
-	cp += otherfieldlen;
-
-	if (cp != eom)
-		return (NS_TSIG_ERROR_FORMERR);
-
-	/* Verify that the key used is OK. */
-	if (key != NULL) {
-		if (key->dk_alg != KEY_HMAC_MD5)
-			return (-ns_r_badkey);
-		if (error != ns_r_badsig && error != ns_r_badkey) {
-			if (ns_samename(key->dk_key_name, name) != 1)
-				return (-ns_r_badkey);
-		}
-	}
-
-	hp->arcount = htons(ntohs(hp->arcount) - 1);
-
-	/*
-	 * Do the verification.
-	 */
-
-	if (key != NULL && error != ns_r_badsig && error != ns_r_badkey) {
-		void *ctx;
-		u_char buf[MAXDNAME];
-		u_char buf2[MAXDNAME];
-
-		/* Digest the query signature, if this is a response. */
-		dst_verify_data(SIG_MODE_INIT, key, &ctx, NULL, 0, NULL, 0);
-		if (querysiglen > 0 && querysig != NULL) {
-			u_int16_t len_n = htons(querysiglen);
-			dst_verify_data(SIG_MODE_UPDATE, key, &ctx,
-					(u_char *)&len_n, INT16SZ, NULL, 0);
-			dst_verify_data(SIG_MODE_UPDATE, key, &ctx,
-					querysig, querysiglen, NULL, 0);
-		}
-		
- 		/* Digest the message. */
-		dst_verify_data(SIG_MODE_UPDATE, key, &ctx, msg, recstart - msg,
-				NULL, 0);
-
-		/* Digest the key name. */
-		n = ns_name_pton(name, buf2, sizeof(buf2));
-		if (n < 0)
-			return (-1);
-		n = ns_name_ntol(buf2, buf, sizeof(buf));
-		if (n < 0)
-			return (-1);
-		dst_verify_data(SIG_MODE_UPDATE, key, &ctx, buf, n, NULL, 0);
-
-		/* Digest the class and TTL. */
-		dst_verify_data(SIG_MODE_UPDATE, key, &ctx,
-				recstart + dn_skipname(recstart, eom) + INT16SZ,
-				INT16SZ + INT32SZ, NULL, 0);
-
-		/* Digest the algorithm. */
-		n = ns_name_pton(alg, buf2, sizeof(buf2));
-		if (n < 0)
-			return (-1);
-		n = ns_name_ntol(buf2, buf, sizeof(buf));
-		if (n < 0)
-			return (-1);
-		dst_verify_data(SIG_MODE_UPDATE, key, &ctx, buf, n, NULL, 0);
-
-		/* Digest the time signed and fudge. */
-		dst_verify_data(SIG_MODE_UPDATE, key, &ctx,
-				rdatastart + dn_skipname(rdatastart, eom),
-				INT16SZ + INT32SZ + INT16SZ, NULL, 0);
-
-		/* Digest the error and other data. */
-		dst_verify_data(SIG_MODE_UPDATE, key, &ctx,
-				otherstart - INT16SZ - INT16SZ,
-				otherfieldlen + INT16SZ + INT16SZ, NULL, 0);
-
-		n = dst_verify_data(SIG_MODE_FINAL, key, &ctx, NULL, 0,
-				    sigstart, sigfieldlen);
-
-		if (n < 0)
-			return (-ns_r_badsig);
-
-		if (sig != NULL && siglen != NULL) {
-			if (*siglen < sigfieldlen)
-				return (NS_TSIG_ERROR_NO_SPACE);
-			memcpy(sig, sigstart, sigfieldlen);
-			*siglen = sigfieldlen;
-		}
-	} else {
-		if (sigfieldlen > 0)
-			return (NS_TSIG_ERROR_FORMERR);
-		if (sig != NULL && siglen != NULL)
-			*siglen = 0;
-	}
-
-	/* Reset the counter, since we still need to check for badtime. */
-	hp->arcount = htons(ntohs(hp->arcount) + 1);
-
-	/* Verify the time. */
-	if (abs((*timesigned) - time(NULL)) > fudge)
-		return (-ns_r_badtime);
-
-	if (nostrip == 0) {
-		*msglen = recstart - msg;
-		hp->arcount = htons(ntohs(hp->arcount) - 1);
-	}
-
-	if (error != NOERROR)
-		return (error);
-
-	return (0);
-}
-
-int
-ns_verify_tcp_init(void *k, const u_char *querysig, int querysiglen,
-		   ns_tcp_tsig_state *state)
-{
-	dst_init();
-	if (state == NULL || k == NULL || querysig == NULL || querysiglen < 0)
-		return (-1);
-	state->counter = -1;
-	state->key = k;
-	if (state->key->dk_alg != KEY_HMAC_MD5)
-		return (-ns_r_badkey);
-	if (querysiglen > (int)sizeof(state->sig))
-		return (-1);
-	memcpy(state->sig, querysig, querysiglen);
-	state->siglen = querysiglen;
-	return (0);
-}
-
-int
-ns_verify_tcp(u_char *msg, int *msglen, ns_tcp_tsig_state *state,
-	      int required)
-{
-	HEADER *hp = (HEADER *)msg;
-	u_char *recstart, *sigstart;
-	unsigned int sigfieldlen, otherfieldlen;
-	u_char *cp, *eom, *cp2;
-	char name[MAXDNAME], alg[MAXDNAME];
-	u_char buf[MAXDNAME];
-	int n, type, length, fudge, error;
-	time_t timesigned;
-
-	if (msg == NULL || msglen == NULL || state == NULL)
-		return (-1);
-
-	eom = msg + *msglen;
-
-	state->counter++;
-	if (state->counter == 0)
-		return (ns_verify(msg, msglen, state->key,
-				  state->sig, state->siglen,
-				  state->sig, &state->siglen, &timesigned, 0));
-
-	if (state->siglen > 0) {
-		u_int16_t siglen_n = htons(state->siglen);
-
-		dst_verify_data(SIG_MODE_INIT, state->key, &state->ctx,
-				NULL, 0, NULL, 0);
-		dst_verify_data(SIG_MODE_UPDATE, state->key, &state->ctx,
-				(u_char *)&siglen_n, INT16SZ, NULL, 0);
-		dst_verify_data(SIG_MODE_UPDATE, state->key, &state->ctx,
-				state->sig, state->siglen, NULL, 0);
-		state->siglen = 0;
-	}
-
-	cp = recstart = ns_find_tsig(msg, eom);
-
-	if (recstart == NULL) {
-		if (required)
-			return (NS_TSIG_ERROR_NO_TSIG);
-		dst_verify_data(SIG_MODE_UPDATE, state->key, &state->ctx,
-				msg, *msglen, NULL, 0);
-		return (0);
-	}
-
-	hp->arcount = htons(ntohs(hp->arcount) - 1);
-	dst_verify_data(SIG_MODE_UPDATE, state->key, &state->ctx,
-			msg, recstart - msg, NULL, 0);
-	
-	/* Read the key name. */
-	n = dn_expand(msg, eom, cp, name, MAXDNAME);
-	if (n < 0)
-		return (NS_TSIG_ERROR_FORMERR);
-	cp += n;
-
-	/* Read the type. */
-	BOUNDS_CHECK(cp, 2*INT16SZ + INT32SZ + INT16SZ);
-	GETSHORT(type, cp);
-	if (type != ns_t_tsig)
-		return (NS_TSIG_ERROR_NO_TSIG);
-
-	/* Skip the class and TTL, save the length. */
-	cp += INT16SZ + INT32SZ;
-	GETSHORT(length, cp);
-	if (eom - cp != length)
-		return (NS_TSIG_ERROR_FORMERR);
-
-	/* Read the algorithm name. */
-	n = dn_expand(msg, eom, cp, alg, MAXDNAME);
-	if (n < 0)
-		return (NS_TSIG_ERROR_FORMERR);
-	if (ns_samename(alg, NS_TSIG_ALG_HMAC_MD5) != 1)
-		return (-ns_r_badkey);
-	cp += n;
-
-	/* Verify that the key used is OK. */
-	if ((ns_samename(state->key->dk_key_name, name) != 1 ||
-	     state->key->dk_alg != KEY_HMAC_MD5))
-		return (-ns_r_badkey);
-
-	/* Read the time signed and fudge. */
-	BOUNDS_CHECK(cp, INT16SZ + INT32SZ + INT16SZ);
-	cp += INT16SZ;
-	GETLONG(timesigned, cp);
-	GETSHORT(fudge, cp);
-
-	/* Read the signature. */
-	BOUNDS_CHECK(cp, INT16SZ);
-	GETSHORT(sigfieldlen, cp);
-	BOUNDS_CHECK(cp, sigfieldlen);
-	sigstart = cp;
-	cp += sigfieldlen;
-
-	/* Skip id and read error. */
-	BOUNDS_CHECK(cp, 2*INT16SZ);
-	cp += INT16SZ;
-	GETSHORT(error, cp);
-
-	/* Parse the other data. */
-	BOUNDS_CHECK(cp, INT16SZ);
-	GETSHORT(otherfieldlen, cp);
-	BOUNDS_CHECK(cp, otherfieldlen);
-	cp += otherfieldlen;
-
-	if (cp != eom)
-		return (NS_TSIG_ERROR_FORMERR);
-
-	/*
-	 * Do the verification.
-	 */
-
-	/* Digest the time signed and fudge. */
-	cp2 = buf;
-	PUTSHORT(0, cp2);       /*%< Top 16 bits of time. */
-	PUTLONG(timesigned, cp2);
-	PUTSHORT(NS_TSIG_FUDGE, cp2);
-
-	dst_verify_data(SIG_MODE_UPDATE, state->key, &state->ctx,
-			buf, cp2 - buf, NULL, 0);
-
-	n = dst_verify_data(SIG_MODE_FINAL, state->key, &state->ctx, NULL, 0,
-			    sigstart, sigfieldlen);
-	if (n < 0)
-		return (-ns_r_badsig);
-
-	if (sigfieldlen > sizeof(state->sig))
-		return (NS_TSIG_ERROR_NO_SPACE);
-
-	memcpy(state->sig, sigstart, sigfieldlen);
-	state->siglen = sigfieldlen;
-
-	/* Verify the time. */
-	if (abs(timesigned - time(NULL)) > fudge)
-		return (-ns_r_badtime);
-
-	*msglen = recstart - msg;
-
-	if (error != NOERROR)
-		return (error);
-
-	return (0);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/port/Makefile.in b/contrib/bind9/lib/bind/port/Makefile.in
deleted file mode 100644
index 99e5985..0000000
--- a/contrib/bind9/lib/bind/port/Makefile.in
+++ /dev/null
@@ -1,14 +0,0 @@
-# Copyright (C) 2004  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,
-# 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.
diff --git a/contrib/bind9/lib/bind/port/freebsd/Makefile.in b/contrib/bind9/lib/bind/port/freebsd/Makefile.in
deleted file mode 100644
index 99e5985..0000000
--- a/contrib/bind9/lib/bind/port/freebsd/Makefile.in
+++ /dev/null
@@ -1,14 +0,0 @@
-# Copyright (C) 2004  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,
-# 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.
diff --git a/contrib/bind9/lib/bind/port/freebsd/include/Makefile.in b/contrib/bind9/lib/bind/port/freebsd/include/Makefile.in
deleted file mode 100644
index 68bef09..0000000
--- a/contrib/bind9/lib/bind/port/freebsd/include/Makefile.in
+++ /dev/null
@@ -1,34 +0,0 @@
-# Copyright (C) 2004  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,
-# 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: Makefile.in,v 1.2 2004/03/16 05:22:22 marka Exp $
-
-srcdir =        @srcdir@
-VPATH =         @srcdir@
-top_srcdir =    @top_srcdir@
-
-HEADERS= sys/bitypes.h
-
-all:
-
-@BIND9_MAKE_RULES@
-
-installdirs:
-	$(SHELL) ${top_srcdir}/mkinstalldirs ${DESTDIR}${includedir}/sys 
-
-install:: installdirs
-	for i in ${HEADERS}; do \
-		${INSTALL_DATA} ${srcdir}/$$i ${DESTDIR}${includedir}/sys; \
-	done
diff --git a/contrib/bind9/lib/bind/port/freebsd/include/sys/bitypes.h b/contrib/bind9/lib/bind/port/freebsd/include/sys/bitypes.h
deleted file mode 100644
index ef3a6d4..0000000
--- a/contrib/bind9/lib/bind/port/freebsd/include/sys/bitypes.h
+++ /dev/null
@@ -1,37 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996,1999 by 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.
- */
-
-#ifndef __BIT_TYPES_DEFINED__
-#define __BIT_TYPES_DEFINED__
-
-	/*
-	 * Basic integral types.  Omit the typedef if
-	 * not possible for a machine/compiler combination.
-	 */
-	typedef /*signed*/ char            int8_t;
-	typedef unsigned char            u_int8_t;
-	typedef short                     int16_t;
-	typedef unsigned short          u_int16_t;
-	typedef int                       int32_t;
-	typedef unsigned int            u_int32_t;
-
-# if 0	/* don't fight with these unless you need them */
-	typedef long long                 int64_t;
-	typedef unsigned long long      u_int64_t;
-# endif
-
-#endif	/* __BIT_TYPES_DEFINED__ */
diff --git a/contrib/bind9/lib/bind/port_after.h.in b/contrib/bind9/lib/bind/port_after.h.in
deleted file mode 100644
index daddae6..0000000
--- a/contrib/bind9/lib/bind/port_after.h.in
+++ /dev/null
@@ -1,507 +0,0 @@
-#ifndef port_after_h
-#define port_after_h
-
-#include <stdio.h>
-#include <sys/types.h>
-#include <sys/socket.h>
-#include <sys/param.h>
-#include <sys/time.h>
-#if (!defined(BSD)) || (BSD < 199306)
-#include <sys/bitypes.h>
-#endif
-#ifdef HAVE_INTTYPES_H
-#include <inttypes.h>
-#endif
-#ifdef HAVE_SYS_SELECT_H
-#include <sys/select.h>
-#endif /* HAVE_SYS_SELECT_H */
-
-#ifdef REENABLE_SEND
-#undef send
-#endif
-
-@NEED_PSELECT@
-@HAVE_SA_LEN@
-@HAVE_MINIMUM_IFREQ@
-@NEED_DAEMON@
-@NEED_STRSEP@
-@NEED_STRERROR@
-#ifdef NEED_STRERROR
-const char *isc_strerror(int);
-#define strerror isc_strerror
-#endif
-@HAS_INET6_STRUCTS@
-@HAVE_SIN6_SCOPE_ID@
-@NEED_IN6ADDR_ANY@
-@HAS_IN_ADDR6@
-@HAVE_SOCKADDR_STORAGE@
-@NEED_GETTIMEOFDAY@
-@HAVE_STRNDUP@
-@USE_FIONBIO_IOCTL@
-@INNETGR_ARGS@
-@SETNETGRENT_ARGS@
-@USE_IFNAMELINKID@
-@PORT_NONBLOCK@
-
-#ifndef _POSIX_PATH_MAX
-#define _POSIX_PATH_MAX 255
-#endif
-#ifndef PATH_MAX
-#define PATH_MAX _POSIX_PATH_MAX
-#endif
-
-/*
- * We need to know the IPv6 address family number even on IPv4-only systems.
- * Note that this is NOT a protocol constant, and that if the system has its
- * own AF_INET6, different from ours below, all of BIND's libraries and
- * executables will need to be recompiled after the system <sys/socket.h>
- * has had this type added.  The type number below is correct on most BSD-
- * derived systems for which AF_INET6 is defined.
- */
-#ifndef AF_INET6
-#define AF_INET6        24
-#endif
-
-#ifndef PF_INET6
-#define PF_INET6        AF_INET6
-#endif
-
-#ifdef HAS_IN_ADDR6
-/* Map to pre-RFC structure. */
-#define in6_addr in_addr6
-#endif
-
-#ifndef HAS_INET6_STRUCTS
-/* Replace with structure from later rev of O/S if known. */
-struct in6_addr {
-        u_int8_t        s6_addr[16];
-};
-
-#define IN6ADDR_ANY_INIT \
-	{{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
-	   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }}
-
-#define IN6ADDR_LOOPBACK_INIT \
-	{{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
-	   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01 }}
-
-/* Replace with structure from later rev of O/S if known. */
-struct sockaddr_in6 {
-#ifdef  HAVE_SA_LEN
-        u_int8_t        sin6_len;       /* length of this struct */
-        u_int8_t        sin6_family;    /* AF_INET6 */
-#else
-        u_int16_t       sin6_family;    /* AF_INET6 */
-#endif
-        u_int16_t       sin6_port;      /* transport layer port # */
-        u_int32_t       sin6_flowinfo;  /* IPv6 flow information */
-        struct in6_addr sin6_addr;      /* IPv6 address */
-        u_int32_t       sin6_scope_id;  /* set of interfaces for a scope */
-};
-#endif  /* HAS_INET6_STRUCTS */
-
-#ifdef BROKEN_IN6ADDR_INIT_MACROS
-#undef IN6ADDR_ANY_INIT
-#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 \
-	{{{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
-	    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }}}
-#else
-#define IN6ADDR_ANY_INIT \
-	{{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
-	   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }}
-#endif
-
-#endif
-#ifndef IN6ADDR_LOOPBACK_INIT
-#ifdef s6_addr
-#define IN6ADDR_LOOPBACK_INIT \
-	{{{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
-	    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01 }}}
-#else
-#define IN6ADDR_LOOPBACK_INIT \
-	{{ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, \
-	   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01 }}
-#endif
-#endif
-
-#ifndef HAVE_SOCKADDR_STORAGE
-#define __SS_MAXSIZE 128 
-#define __SS_ALLIGSIZE (sizeof (long)) 
-
-struct sockaddr_storage {
-#ifdef  HAVE_SA_LEN
-        u_int8_t        ss_len;       /* address length */
-        u_int8_t        ss_family;    /* address family */
-        char            __ss_pad1[__SS_ALLIGSIZE - 2 * sizeof(u_int8_t)];
-        long            __ss_align;
-        char            __ss_pad2[__SS_MAXSIZE - 2 * __SS_ALLIGSIZE];
-#else   
-        u_int16_t       ss_family;    /* address family */
-        char            __ss_pad1[__SS_ALLIGSIZE - sizeof(u_int16_t)];
-        long            __ss_align;
-        char            __ss_pad2[__SS_MAXSIZE - 2 * __SS_ALLIGSIZE];
-#endif
-};
-#endif
-
-
-#if !defined(HAS_INET6_STRUCTS) || defined(NEED_IN6ADDR_ANY)
-#define in6addr_any isc_in6addr_any
-extern const struct in6_addr in6addr_any;
-#endif
-
-/*
- * IN6_ARE_ADDR_EQUAL, IN6_IS_ADDR_UNSPECIFIED, IN6_IS_ADDR_V4COMPAT and
- * IN6_IS_ADDR_V4MAPPED are broken in glibc 2.1.
- */
-#ifdef __GLIBC__
-#if __GLIBC__ < 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ < 2)
-#undef IN6_ARE_ADDR_EQUAL
-#undef IN6_IS_ADDR_UNSPECIFIED
-#undef IN6_IS_ADDR_V4COMPAT
-#undef IN6_IS_ADDR_V4MAPPED
-#endif
-#endif
-
-#ifndef IN6_ARE_ADDR_EQUAL
-#define IN6_ARE_ADDR_EQUAL(a,b) \
-   (memcmp(&(a)->s6_addr[0], &(b)->s6_addr[0], sizeof(struct in6_addr)) == 0)
-#endif
-
-#ifndef IN6_IS_ADDR_UNSPECIFIED
-#define IN6_IS_ADDR_UNSPECIFIED(a)      \
-	IN6_ARE_ADDR_EQUAL(a, &in6addr_any)
-#endif
-
-#ifndef IN6_IS_ADDR_LOOPBACK
-extern const struct in6_addr isc_in6addr_loopback;
-#define IN6_IS_ADDR_LOOPBACK(a) \
-	IN6_ARE_ADDR_EQUAL(a, &isc_in6addr_loopback)
-#endif
-
-#ifndef IN6_IS_ADDR_V4MAPPED
-#define IN6_IS_ADDR_V4MAPPED(a)	\
-	((a)->s6_addr[0] == 0x00 && (a)->s6_addr[1] == 0x00 && \
-	(a)->s6_addr[2] == 0x00 && (a)->s6_addr[3] == 0x00 && \
-	(a)->s6_addr[4] == 0x00 && (a)->s6_addr[5] == 0x00 && \
-	(a)->s6_addr[6] == 0x00 && (a)->s6_addr[9] == 0x00 && \
-	(a)->s6_addr[8] == 0x00 && (a)->s6_addr[9] == 0x00 && \
-	(a)->s6_addr[10] == 0xff && (a)->s6_addr[11] == 0xff)
-#endif
-
-#ifndef IN6_IS_ADDR_SITELOCAL
-#define IN6_IS_ADDR_SITELOCAL(a)        \
-	(((a)->s6_addr[0] == 0xfe) && (((a)->s6_addr[1] & 0xc0) == 0xc0))
-#endif
-
-#ifndef IN6_IS_ADDR_LINKLOCAL
-#define IN6_IS_ADDR_LINKLOCAL(a)        \
-	(((a)->s6_addr[0] == 0xfe) && (((a)->s6_addr[1] & 0xc0) == 0x80))
-#endif
-
-#ifndef IN6_IS_ADDR_MULTICAST
-#define IN6_IS_ADDR_MULTICAST(a)        ((a)->s6_addr[0] == 0xff)
-#endif
-
-#ifndef __IPV6_ADDR_MC_SCOPE
-#define __IPV6_ADDR_MC_SCOPE(a)         ((a)->s6_addr[1] & 0x0f)
-#endif
-
-#ifndef __IPV6_ADDR_SCOPE_SITELOCAL
-#define __IPV6_ADDR_SCOPE_SITELOCAL 0x05
-#endif
-#ifndef __IPV6_ADDR_SCOPE_ORGLOCAL
-#define __IPV6_ADDR_SCOPE_ORGLOCAL  0x08
-#endif
-
-#ifndef IN6_IS_ADDR_MC_SITELOCAL
-#define IN6_IS_ADDR_MC_SITELOCAL(a)     \
-	(IN6_IS_ADDR_MULTICAST(a) &&    \
-	 (__IPV6_ADDR_MC_SCOPE(a) == __IPV6_ADDR_SCOPE_SITELOCAL))
-#endif
-
-#ifndef IN6_IS_ADDR_MC_ORGLOCAL
-#define IN6_IS_ADDR_MC_ORGLOCAL(a)      \
-	(IN6_IS_ADDR_MULTICAST(a) &&    \
-	 (__IPV6_ADDR_MC_SCOPE(a) == __IPV6_ADDR_SCOPE_ORGLOCAL))
-#endif
-
-#ifndef INADDR_NONE
-#define INADDR_NONE 0xffffffff
-#endif
-
-#ifndef MAXHOSTNAMELEN
-#define MAXHOSTNAMELEN 256
-#endif
-
-#ifndef INET6_ADDRSTRLEN
-/* sizeof("aaaa:bbbb:cccc:dddd:eeee:ffff:123.123.123.123") */
-#define INET6_ADDRSTRLEN 46
-#endif
-
-#ifndef MIN
-#define MIN(x,y) (((x) <= (y)) ? (x) : (y))
-#endif
-
-#ifndef MAX
-#define MAX(x,y) (((x) >= (y)) ? (x) : (y))
-#endif
-
-#ifdef NEED_DAEMON
-int daemon(int nochdir, int noclose);
-#endif
-  
-#ifdef NEED_STRSEP
-char * strsep(char **stringp, const char *delim);
-#endif
-
-#ifndef ALIGN
-#define ALIGN(p) (((uintptr_t)(p) + (sizeof(long) - 1)) & ~(sizeof(long) - 1))
-#endif
-
-#ifdef NEED_SETGROUPENT
-int setgroupent(int stayopen);
-#endif
-
-#ifdef NEED_GETGROUPLIST
-int getgrouplist(GETGROUPLIST_ARGS);
-#endif
-
-#ifdef POSIX_GETGRNAM_R
-int
-__posix_getgrnam_r(const char *, struct group *, char *, int, struct group **);
-#endif
-
-#ifdef NEED_GETGRNAM_R
-int
-getgrnam_r(const char *,  struct group *, char *, size_t, struct group **);
-#endif
-
-#ifdef POSIX_GETGRGID_R
-int
-__posix_getgrgid_r(gid_t, struct group *, char *, int, struct group **) ;
-#endif
-
-#ifdef NEED_GETGRGID_R
-int
-getgrgid_r(gid_t, struct group *, char *, size_t, struct group **);
-#endif
-
-#ifdef NEED_GETGRENT_R
-GROUP_R_RETURN getgrent_r(struct group *gptr, GROUP_R_ARGS);
-#endif
-
-#ifdef NEED_SETGRENT_R
-GROUP_R_SET_RETURN setgrent_r(GROUP_R_ENT_ARGS);
-#endif
-
-#ifdef NEED_ENDGRENT_R
-GROUP_R_END_RETURN endgrent_r(GROUP_R_ENT_ARGS);
-#endif
-
-#if defined(NEED_INNETGR_R) && defined(NGR_R_RETURN)
-NGR_R_RETURN
-innetgr_r(const char *, const char *, const char *, const char *);
-#endif
-
-#ifdef NEED_SETNETGRENT_R
-#ifdef NGR_R_SET_ARGS
-NGR_R_SET_RETURN setnetgrent_r(NGR_R_SET_CONST char *netgroup, NGR_R_SET_ARGS);
-#else
-NGR_R_SET_RETURN setnetgrent_r(NGR_R_SET_CONST char *netgroup);
-#endif
-#endif
-
-#ifdef NEED_ENDNETGRENT_R
-#ifdef NGR_R_END_ARGS
-NGR_R_END_RETURN endnetgrent_r(NGR_R_END_ARGS);
-#else
-NGR_R_END_RETURN endnetgrent_r(void);
-#endif
-#endif
-
-#ifdef POSIX_GETPWNAM_R
-int
-__posix_getpwnam_r(const char *login,  struct passwd *pwptr,
-                char *buf, size_t buflen, struct passwd **result);
-#endif
-
-#ifdef NEED_GETPWNAM_R
-int
-getpwnam_r(const char *login,  struct passwd *pwptr,
-                char *buf, size_t buflen, struct passwd **result);
-#endif
-
-#ifdef POSIX_GETPWUID_R
-int
-__posix_getpwuid_r(uid_t uid, struct passwd *pwptr,
-                char *buf, int buflen, struct passwd **result);
-#endif
-
-#ifdef NEED_GETPWUID_R
-int
-getpwuid_r(uid_t uid, struct passwd *pwptr,
-                char *buf, size_t buflen, struct passwd **result);
-#endif
-
-#ifdef NEED_SETPWENT_R
-#ifdef PASS_R_ENT_ARGS
-PASS_R_SET_RETURN setpwent_r(PASS_R_ENT_ARGS);
-#else
-PASS_R_SET_RETURN setpwent_r(void);
-#endif
-
-#endif
-
-#ifdef NEED_SETPASSENT_R
-#ifdef PASS_R_ENT_ARGS
-PASS_R_SET_RETURN setpassent_r(int stayopen, PASS_R_ENT_ARGS);
-#else
-PASS_R_SET_RETURN setpassent_r(int stayopen);
-#endif
-#endif
-
-#ifdef NEED_GETPWENT_R
-PASS_R_RETURN getpwent_r(struct passwd *pwptr, PASS_R_ARGS);
-#endif
-
-#ifdef NEED_ENDPWENT_R
-void endpwent_r(void);
-#endif
-
-#ifdef NEED_SETPASSENT
-int setpassent(int stayopen);
-#endif
-
-#define gettimeofday isc__gettimeofday
-#ifdef NEED_GETTIMEOFDAY
-int isc__gettimeofday(struct timeval *tvp, struct _TIMEZONE *tzp);
-#else
-int isc__gettimeofday(struct timeval *tp, struct timezone *tzp);
-#endif
-
-int getnetgrent(NGR_R_CONST char **machinep, NGR_R_CONST char **userp,
-	        NGR_R_CONST char **domainp);
-
-#ifdef NGR_R_ARGS
-int getnetgrent_r(NGR_R_CONST char **machinep, NGR_R_CONST char **userp, 
-		  NGR_R_CONST char **domainp, NGR_R_ARGS);
-#endif
-
-#ifdef SETNETGRENT_ARGS
-void setnetgrent(SETNETGRENT_ARGS);
-#else
-void setnetgrent(const char *netgroup);
-#endif
-
-void endnetgrent(void);
-
-#ifdef INNETGR_ARGS
-int innetgr(INNETGR_ARGS);
-#else
-int innetgr(const char *netgroup, const char *machine,
-	    const char *user, const char *domain);
-#endif
-
-#ifdef NGR_R_SET_ARGS
-NGR_R_SET_RETURN
-setnetgrent_r(NGR_R_SET_CONST char *netgroup, NGR_R_SET_ARGS);
-#else
-NGR_R_SET_RETURN
-setnetgrent_r(NGR_R_SET_CONST char *netgroup);
-#endif
-
-#ifdef NEED_STRTOUL
-unsigned long strtoul(const char *, char **, int);
-#endif
-
-#ifdef NEED_SUN4PROTOS
-#include <stdarg.h>
-#ifndef __SIZE_TYPE__
-#define __SIZE_TYPE__ int
-#endif
-struct sockaddr;
-struct iovec;
-struct timeval;
-struct timezone;
-int fprintf(FILE *, const char *, ...);
-int getsockname(int, struct sockaddr *, int *);
-int getpeername(int, struct sockaddr *, int *);
-int socket(int, int, int);
-int connect(int, const struct sockaddr *, int);
-int writev(int, struct iovec *, int);
-int readv(int, struct iovec *, int);
-int send(int, const char *, int, int);
-void bzero(char *, int);
-int recvfrom(int, char *, int, int, struct sockaddr *, int *);
-int syslog(int, const char *, ... );
-int printf(const char *, ...);
-__SIZE_TYPE__ fread(void *, __SIZE_TYPE__, __SIZE_TYPE__, FILE *);
-__SIZE_TYPE__ fwrite(const void *, __SIZE_TYPE__, __SIZE_TYPE__, FILE *);
-int fclose(FILE *);
-int ungetc(int, FILE *);
-int scanf(const char *, ...);
-int sscanf(const char *, const char *, ... );
-int tolower(int);
-int toupper(int);
-int strcasecmp(const char *, const char *);
-int strncasecmp(const char *, const char *, int);
-int select(int, fd_set *, fd_set *, fd_set *, struct timeval *);
-#ifdef gettimeofday
-#undef gettimeofday
-int gettimeofday(struct timeval *, struct timezone *);
-#define gettimeofday isc__gettimeofday
-#else
-int gettimeofday(struct timeval *, struct timezone *);
-#endif
-long strtol(const char*, char **, int);
-int fseek(FILE *, long, int);
-int setsockopt(int, int, int, const char *, int);
-int bind(int, const struct sockaddr *, int);
-void bcopy(char *, char *, int);
-int fputc(char, FILE *);
-int listen(int, int);
-int accept(int, struct sockaddr *, int *);
-int getsockopt(int, int, int, char *, int *);
-int vfprintf(FILE *, const char *, va_list);
-int fflush(FILE *);
-int fgetc(FILE *);
-int fputs(const char *, FILE *);
-int fchown(int, int, int);
-void setbuf(FILE *, char *);
-int gethostname(char *, int);
-int rename(const char *, const char *);
-time_t time(time_t *);
-int fscanf(FILE *, const char *, ...);
-int sscanf(const char *, const char *, ...);
-int ioctl(int, int, caddr_t);
-void perror(const char *);
-
-#if !defined(__USE_FIXED_PROTOTYPES__) && !defined(__cplusplus) && !defined(__STRICT_ANSI__)
-/*
- * 'gcc -ansi' changes the prototype for vsprintf().
- * Use this prototype when 'gcc -ansi' is not in effect.
- */
-char *vsprintf(char *, const char *, va_list);
-#endif
-#endif 
-
-#endif
diff --git a/contrib/bind9/lib/bind/port_before.h.in b/contrib/bind9/lib/bind/port_before.h.in
deleted file mode 100644
index eb0c3fc..0000000
--- a/contrib/bind9/lib/bind/port_before.h.in
+++ /dev/null
@@ -1,173 +0,0 @@
-#ifndef port_before_h
-#define port_before_h
-#include <config.h>
-
-#ifdef NEED_SUN4PROTOS
-#define _PARAMS(x) x
-#endif
-
-struct group;           /* silence warning */
-struct passwd;          /* silence warning */
-struct timeval;         /* silence warning */
-struct timezone;        /* silence warning */
-
-#ifdef HAVE_SYS_TIMERS_H
-#include <sys/timers.h>
-#endif
-#include <limits.h>
-
-#ifdef ISC_PLATFORM_NEEDTIMESPEC
-#include <time.h>		/* For time_t */
-struct timespec {
-        time_t  tv_sec;         /* seconds */
-        long    tv_nsec;        /* nanoseconds */
-};
-#endif
-#ifndef HAVE_MEMMOVE
-#define memmove(a,b,c) bcopy(b,a,c)
-#endif
-
-@WANT_IRS_GR@
-@WANT_IRS_NIS@
-@WANT_IRS_PW@
-
-@BSD_COMP@
-@USE_POLL@
-@HAVE_MD5@
-@SOLARIS2@
-
-@DO_PTHREADS@
-@GETGROUPLIST_ARGS@
-@GETNETBYADDR_ADDR_T@
-@SETPWENT_VOID@
-@SETGRENT_VOID@
-
-@NET_R_ARGS@
-@NET_R_BAD@
-@NET_R_COPY@
-@NET_R_COPY_ARGS@
-@NET_R_END_RESULT@
-@NET_R_END_RETURN@
-@NET_R_ENT_ARGS@
-@NET_R_OK@
-@NET_R_RETURN@
-@NET_R_SET_RESULT@
-@NET_R_SETANSWER@
-@NET_R_SET_RETURN@
-@NETENT_DATA@
-
-@GROUP_R_RETURN@
-@GROUP_R_SET_RETURN@
-@GROUP_R_SET_RESULT@
-@GROUP_R_END_RETURN@
-@GROUP_R_END_RESULT@
-@GROUP_R_ARGS@
-@GROUP_R_ENT_ARGS@
-@GROUP_R_OK@
-@GROUP_R_BAD@
-
-@HOST_R_ARGS@
-@HOST_R_BAD@
-@HOST_R_COPY@
-@HOST_R_COPY_ARGS@
-@HOST_R_END_RESULT@
-@HOST_R_END_RETURN@
-@HOST_R_ENT_ARGS@
-@HOST_R_ERRNO@
-@HOST_R_OK@
-@HOST_R_RETURN@
-@HOST_R_SETANSWER@
-@HOST_R_SET_RESULT@
-@HOST_R_SET_RETURN@
-@HOSTENT_DATA@
-
-@NGR_R_ARGS@
-@NGR_R_BAD@
-@NGR_R_COPY@
-@NGR_R_COPY_ARGS@
-@NGR_R_CONST@
-@NGR_R_END_RESULT@
-@NGR_R_END_RETURN@
-@NGR_R_END_ARGS@
-@NGR_R_OK@
-@NGR_R_RETURN@
-@NGR_R_SET_CONST@
-@NGR_R_SET_RESULT@
-@NGR_R_SET_RETURN@
-@NGR_R_SET_ARGS@
-@NGR_R_PRIVATE@
-
-#if !defined(NGR_R_SET_ARGS) && defined(NGR_R_END_ARGS)
-#define NGR_R_SET_ARGS NGR_R_END_ARGS
-#endif
-
-@PROTO_R_ARGS@
-@PROTO_R_BAD@
-@PROTO_R_COPY@
-@PROTO_R_COPY_ARGS@
-@PROTO_R_END_RESULT@
-@PROTO_R_END_RETURN@
-@PROTO_R_ENT_ARGS@
-@PROTO_R_ENT_UNUSED@
-@PROTO_R_OK@
-@PROTO_R_SETANSWER@
-@PROTO_R_RETURN@
-@PROTO_R_SET_RESULT@
-@PROTO_R_SET_RETURN@
-@PROTOENT_DATA@
-
-@PASS_R_ARGS@
-@PASS_R_BAD@
-@PASS_R_COPY@
-@PASS_R_COPY_ARGS@
-@PASS_R_END_RESULT@
-@PASS_R_END_RETURN@
-@PASS_R_ENT_ARGS@
-@PASS_R_OK@
-@PASS_R_RETURN@
-@PASS_R_SET_RESULT@
-@PASS_R_SET_RETURN@
-
-@SERV_R_ARGS@
-@SERV_R_BAD@
-@SERV_R_COPY@
-@SERV_R_COPY_ARGS@
-@SERV_R_END_RESULT@
-@SERV_R_END_RETURN@
-@SERV_R_ENT_ARGS@
-@SERV_R_ENT_UNUSED@
-@SERV_R_OK@
-@SERV_R_SETANSWER@
-@SERV_R_RETURN@
-@SERV_R_SET_RESULT@
-@SERV_R_SET_RETURN@
-@SERVENT_DATA@
-
-
-#define DE_CONST(konst, var) \
-        do { \
-                union { const void *k; void *v; } _u; \
-                _u.k = konst; \
-                var = _u.v; \
-        } while (0)
-
-#define UNUSED(x) (x) = (x)
-
-@SOLARIS_BITTYPES@
-@ISC_SOCKLEN_T@
-
-#ifdef __GNUC__
-#define ISC_FORMAT_PRINTF(fmt, args) \
-	__attribute__((__format__(__printf__, fmt, args)))
-#else
-#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
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/resolv/Makefile.in b/contrib/bind9/lib/bind/resolv/Makefile.in
deleted file mode 100644
index 557f020..0000000
--- a/contrib/bind9/lib/bind/resolv/Makefile.in
+++ /dev/null
@@ -1,34 +0,0 @@
-# Copyright (C) 2004, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
-# Copyright (C) 2001  Internet Software Consortium.
-#
-# Permission to use, copy, modify, and/or 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: Makefile.in,v 1.4.18.4 2008/03/20 23:46:01 tbox Exp $
-
-srcdir=		@srcdir@
-VPATH =         @srcdir@
-
-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 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
-
-TARGETS= ${OBJS}
-
-CINCLUDES= -I.. -I../include -I${srcdir}/../include
-CWARNINGS=
-
-@BIND9_MAKE_RULES@
diff --git a/contrib/bind9/lib/bind/resolv/herror.c b/contrib/bind9/lib/bind/resolv/herror.c
deleted file mode 100644
index 9232426..0000000
--- a/contrib/bind9/lib/bind/resolv/herror.c
+++ /dev/null
@@ -1,129 +0,0 @@
-/*
- * Copyright (c) 1987, 1993
- *    The Regents of the University of California.  All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- * 	This product includes software developed by the University of
- * 	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char sccsid[] = "@(#)herror.c	8.1 (Berkeley) 6/4/93";
-static const char rcsid[] = "$Id: herror.c,v 1.3.18.1 2005/04/27 05:01:09 sra Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/param.h>
-#include <sys/uio.h>
-
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-
-#include <netdb.h>
-#include <resolv.h>
-#include <string.h>
-#include <unistd.h>
-#include <irs.h>
-
-#include "port_after.h"
-
-const char *h_errlist[] = {
-	"Resolver Error 0 (no error)",
-	"Unknown host",				/*%< 1 HOST_NOT_FOUND */
-	"Host name lookup failure",		/*%< 2 TRY_AGAIN */
-	"Unknown server error",			/*%< 3 NO_RECOVERY */
-	"No address associated with name",	/*%< 4 NO_ADDRESS */
-};
-int	h_nerr = { sizeof h_errlist / sizeof h_errlist[0] };
-
-#if !(__GLIBC__ > 2 || __GLIBC__ == 2 &&  __GLIBC_MINOR__ >= 3)
-#undef	h_errno
-int	h_errno;
-#endif
-
-/*%
- * herror --
- *	print the error indicated by the h_errno value.
- */
-void
-herror(const char *s) {
-	struct iovec iov[4], *v = iov;
-	char *t;
-
-	if (s != NULL && *s != '\0') {
-		DE_CONST(s, t);
-		v->iov_base = t;
-		v->iov_len = strlen(t);
-		v++;
-		DE_CONST(": ", t);
-		v->iov_base = t;
-		v->iov_len = 2;
-		v++;
-	}
-	DE_CONST(hstrerror(*__h_errno()), t);
-	v->iov_base = t;
-	v->iov_len = strlen(v->iov_base);
-	v++;
-	DE_CONST("\n", t);
-	v->iov_base = t;
-	v->iov_len = 1;
-	writev(STDERR_FILENO, iov, (v - iov) + 1);
-}
-
-/*%
- * hstrerror --
- *	return the string associated with a given "host" errno value.
- */
-const char *
-hstrerror(int err) {
-	if (err < 0)
-		return ("Resolver internal error");
-	else if (err < h_nerr)
-		return (h_errlist[err]);
-	return ("Unknown resolver error");
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/resolv/mtctxres.c b/contrib/bind9/lib/bind/resolv/mtctxres.c
deleted file mode 100644
index 635bbd4..0000000
--- a/contrib/bind9/lib/bind/resolv/mtctxres.c
+++ /dev/null
@@ -1,129 +0,0 @@
-#include <port_before.h>
-#ifdef DO_PTHREADS
-#include <pthread.h>
-#endif
-#include <errno.h>
-#include <netdb.h>
-#include <stdlib.h>
-#include <string.h>
-#include <resolv_mt.h>
-#include <irs.h>
-#include <port_after.h>
-
-#ifdef DO_PTHREADS
-static pthread_key_t	key;
-static int		mt_key_initialized = 0;
-
-static int		__res_init_ctx(void);
-static void		__res_destroy_ctx(void *);
-
-#if defined(sun) && !defined(__GNUC__)
-#pragma init	(_mtctxres_init)
-#endif
-#endif
-
-static mtctxres_t	sharedctx;
-
-#ifdef DO_PTHREADS
-/*
- * Initialize the TSD key. By doing this at library load time, we're
- * implicitly running without interference from other threads, so there's
- * no need for locking.
- */
-static void
-_mtctxres_init(void) {
-	int pthread_keycreate_ret;
-
-	pthread_keycreate_ret = pthread_key_create(&key, __res_destroy_ctx);
-	if (pthread_keycreate_ret == 0)
-		mt_key_initialized = 1;
-}
-#endif
-
-/*
- * To support binaries that used the private MT-safe interface in
- * Solaris 8, we still need to provide the __res_enable_mt()
- * and __res_disable_mt() entry points. They're do-nothing routines.
- */
-int
-__res_enable_mt(void) {
-	return (-1);
-}
-
-int
-__res_disable_mt(void) {
-	return (0);
-}
-
-#ifdef DO_PTHREADS
-static int
-__res_init_ctx(void) {
-
-	mtctxres_t	*mt;
-	int		ret;
-
-
-	if (pthread_getspecific(key) != 0) {
-		/* Already exists */
-		return (0);
-	}
-
-	if ((mt = malloc(sizeof (mtctxres_t))) == 0) {
-		errno = ENOMEM;
-		return (-1);
-	}
-
-	memset(mt, 0, sizeof (mtctxres_t));
-
-	if ((ret = pthread_setspecific(key, mt)) != 0) {
-		free(mt);
-		errno = ret;
-		return (-1);
-	}
-
-	return (0);
-}
-
-static void
-__res_destroy_ctx(void *value) {
-
-	mtctxres_t	*mt = (mtctxres_t *)value;
-
-	if (mt != 0)
-		free(mt);
-}
-#endif
-
-mtctxres_t *
-___mtctxres(void) {
-#ifdef DO_PTHREADS
-	mtctxres_t	*mt;
-
-	/*
-	 * This if clause should only be executed if we are linking
-	 * statically.  When linked dynamically _mtctxres_init() should
-	 * be called at binding time due the #pragma above.
-	 */
-	if (!mt_key_initialized) {
-		static pthread_mutex_t keylock = PTHREAD_MUTEX_INITIALIZER;
-                if (pthread_mutex_lock(&keylock) == 0) {
-			_mtctxres_init();
-			(void) pthread_mutex_unlock(&keylock);
-		}
-	}
-
-	/*
-	 * If we have already been called in this thread return the existing
-	 * context.  Otherwise recreat a new context and return it.  If
-	 * that fails return a global context.
-	 */
-	if (mt_key_initialized) {
-		if (((mt = pthread_getspecific(key)) != 0) ||
-		    (__res_init_ctx() == 0 &&
-		     (mt = pthread_getspecific(key)) != 0)) {
-			return (mt);
-		}
-	}
-#endif
-	return (&sharedctx);
-}
diff --git a/contrib/bind9/lib/bind/resolv/res_comp.c b/contrib/bind9/lib/bind/resolv/res_comp.c
deleted file mode 100644
index 4dc3c2a..0000000
--- a/contrib/bind9/lib/bind/resolv/res_comp.c
+++ /dev/null
@@ -1,265 +0,0 @@
-/*
- * Copyright (c) 1985, 1993
- *    The Regents of the University of California.  All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- * 	This product includes software developed by the University of
- * 	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-/*
- * Portions Copyright (c) 1993 by Digital Equipment Corporation.
- * 
- * 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, and that
- * the name of Digital Equipment Corporation not be used in advertising or
- * publicity pertaining to distribution of the document or software without
- * specific, written prior permission.
- * 
- * THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
- * WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
- * OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
- * CORPORATION 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.
- */
-
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-#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.3.18.2 2005/07/28 07:38:11 marka Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-#include "port_before.h"
-#include <sys/types.h>
-#include <sys/param.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <ctype.h>
-#include <resolv.h>
-#include <stdio.h>
-#include <string.h>
-#include <unistd.h>
-#include "port_after.h"
-
-/*%
- * Expand compressed domain name 'src' to full domain name.
- *
- * \li 'msg' is a pointer to the begining of the message,
- * \li 'eom' points to the first location after the message,
- * \li 'dst' is a pointer to a buffer of size 'dstsiz' for the result.
- * \li Return size of compressed name or -1 if there was an error.
- */
-int
-dn_expand(const u_char *msg, const u_char *eom, const u_char *src,
-	  char *dst, int dstsiz)
-{
-	int n = ns_name_uncompress(msg, eom, src, dst, (size_t)dstsiz);
-
-	if (n > 0 && dst[0] == '.')
-		dst[0] = '\0';
-	return (n);
-}
-
-/*%
- * Pack domain name 'exp_dn' in presentation form into 'comp_dn'.
- *
- * \li Return the size of the compressed name or -1.
- * \li 'length' is the size of the array pointed to by 'comp_dn'.
- */
-int
-dn_comp(const char *src, u_char *dst, int dstsiz,
-	u_char **dnptrs, u_char **lastdnptr)
-{
-	return (ns_name_compress(src, dst, (size_t)dstsiz,
-				 (const u_char **)dnptrs,
-				 (const u_char **)lastdnptr));
-}
-
-/*%
- * Skip over a compressed domain name. Return the size or -1.
- */
-int
-dn_skipname(const u_char *ptr, const u_char *eom) {
-	const u_char *saveptr = ptr;
-
-	if (ns_name_skip(&ptr, eom) == -1)
-		return (-1);
-	return (ptr - saveptr);
-}
-
-/*%
- * Verify that a domain name uses an acceptable character set.
- *
- * Note the conspicuous absence of ctype macros in these definitions.  On
- * non-ASCII hosts, we can't depend on string literals or ctype macros to
- * tell us anything about network-format data.  The rest of the BIND system
- * is not careful about this, but for some reason, we're doing it right here.
- */
-#define PERIOD 0x2e
-#define	hyphenchar(c) ((c) == 0x2d)
-#define bslashchar(c) ((c) == 0x5c)
-#define periodchar(c) ((c) == PERIOD)
-#define asterchar(c) ((c) == 0x2a)
-#define alphachar(c) (((c) >= 0x41 && (c) <= 0x5a) \
-		   || ((c) >= 0x61 && (c) <= 0x7a))
-#define digitchar(c) ((c) >= 0x30 && (c) <= 0x39)
-
-#define borderchar(c) (alphachar(c) || digitchar(c))
-#define middlechar(c) (borderchar(c) || hyphenchar(c))
-#define	domainchar(c) ((c) > 0x20 && (c) < 0x7f)
-
-int
-res_hnok(const char *dn) {
-	int pch = PERIOD, ch = *dn++;
-
-	while (ch != '\0') {
-		int nch = *dn++;
-
-		if (periodchar(ch)) {
-			(void)NULL;
-		} else if (periodchar(pch)) {
-			if (!borderchar(ch))
-				return (0);
-		} else if (periodchar(nch) || nch == '\0') {
-			if (!borderchar(ch))
-				return (0);
-		} else {
-			if (!middlechar(ch))
-				return (0);
-		}
-		pch = ch, ch = nch;
-	}
-	return (1);
-}
-
-/*%
- * hostname-like (A, MX, WKS) owners can have "*" as their first label
- * but must otherwise be as a host name.
- */
-int
-res_ownok(const char *dn) {
-	if (asterchar(dn[0])) {
-		if (periodchar(dn[1]))
-			return (res_hnok(dn+2));
-		if (dn[1] == '\0')
-			return (1);
-	}
-	return (res_hnok(dn));
-}
-
-/*%
- * SOA RNAMEs and RP RNAMEs can have any printable character in their first
- * label, but the rest of the name has to look like a host name.
- */
-int
-res_mailok(const char *dn) {
-	int ch, escaped = 0;
-
-	/* "." is a valid missing representation */
-	if (*dn == '\0')
-		return (1);
-
-	/* otherwise <label>.<hostname> */
-	while ((ch = *dn++) != '\0') {
-		if (!domainchar(ch))
-			return (0);
-		if (!escaped && periodchar(ch))
-			break;
-		if (escaped)
-			escaped = 0;
-		else if (bslashchar(ch))
-			escaped = 1;
-	}
-	if (periodchar(ch))
-		return (res_hnok(dn));
-	return (0);
-}
-
-/*%
- * This function is quite liberal, since RFC1034's character sets are only
- * recommendations.
- */
-int
-res_dnok(const char *dn) {
-	int ch;
-
-	while ((ch = *dn++) != '\0')
-		if (!domainchar(ch))
-			return (0);
-	return (1);
-}
-
-#ifdef BIND_4_COMPAT
-/*%
- * This module must export the following externally-visible symbols:
- *	___putlong
- *	___putshort
- *	__getlong
- *	__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__
-u_int32_t _getlong(const u_char *src) { return (ns_get32(src)); }
-u_int16_t _getshort(const u_char *src) { return (ns_get16(src)); }
-#endif /*__ultrix__*/
-#endif /*BIND_4_COMPAT*/
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/resolv/res_data.c b/contrib/bind9/lib/bind/resolv/res_data.c
deleted file mode 100644
index 736315c..0000000
--- a/contrib/bind9/lib/bind/resolv/res_data.c
+++ /dev/null
@@ -1,297 +0,0 @@
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char rcsid[] = "$Id: res_data.c,v 1.3.18.2 2007/09/14 05:35:47 marka Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/param.h>
-#include <sys/socket.h>
-#include <sys/time.h>
-
-#include <netinet/in.h>
-#include <arpa/inet.h>
-#include <arpa/nameser.h>
-
-#include <ctype.h>
-#include <netdb.h>
-#include <resolv.h>
-#include <res_update.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <unistd.h>
-
-#include "port_after.h"
-
-const char *_res_opcodes[] = {
-	"QUERY",
-	"IQUERY",
-	"CQUERYM",
-	"CQUERYU",	/*%< experimental */
-	"NOTIFY",	/*%< experimental */
-	"UPDATE",
-	"6",
-	"7",
-	"8",
-	"9",
-	"10",
-	"11",
-	"12",
-	"13",
-	"ZONEINIT",
-	"ZONEREF",
-};
-
-#ifdef BIND_UPDATE
-const char *_res_sectioncodes[] = {
-	"ZONE",
-	"PREREQUISITES",
-	"UPDATE",
-	"ADDITIONAL",
-};
-#endif
-
-#undef _res
-#ifndef __BIND_NOSTATIC
-struct __res_state _res
-# if defined(__BIND_RES_TEXT)
-	= { RES_TIMEOUT, }	/*%< Motorola, et al. */
-# endif
-        ;
-
-#if defined(DO_PTHREADS) || defined(__linux)
-#define _res (*__res_state())
-#endif
-
-/* Proto. */
-
-int  res_ourserver_p(const res_state, const struct sockaddr_in *);
-
-int
-res_init(void) {
-	extern int __res_vinit(res_state, int);
-
-	/*
-	 * These three fields used to be statically initialized.  This made
-	 * it hard to use this code in a shared library.  It is necessary,
-	 * now that we're doing dynamic initialization here, that we preserve
-	 * the old semantics: if an application modifies one of these three
-	 * fields of _res before res_init() is called, res_init() will not
-	 * alter them.  Of course, if an application is setting them to
-	 * _zero_ before calling res_init(), hoping to override what used
-	 * to be the static default, we can't detect it and unexpected results
-	 * will follow.  Zero for any of these fields would make no sense,
-	 * so one can safely assume that the applications were already getting
-	 * unexpected results.
-	 *
-	 * _res.options is tricky since some apps were known to diddle the bits
-	 * before res_init() was first called. We can't replicate that semantic
-	 * with dynamic initialization (they may have turned bits off that are
-	 * set in RES_DEFAULT).  Our solution is to declare such applications
-	 * "broken".  They could fool us by setting RES_INIT but none do (yet).
-	 */
-	if (!_res.retrans)
-		_res.retrans = RES_TIMEOUT;
-	if (!_res.retry)
-		_res.retry = 4;
-	if (!(_res.options & RES_INIT))
-		_res.options = RES_DEFAULT;
-
-	/*
-	 * This one used to initialize implicitly to zero, so unless the app
-	 * has set it to something in particular, we can randomize it now.
-	 */
-	if (!_res.id)
-		_res.id = res_randomid();
-
-	return (__res_vinit(&_res, 1));
-}
-
-void
-p_query(const u_char *msg) {
-	fp_query(msg, stdout);
-}
-
-void
-fp_query(const u_char *msg, FILE *file) {
-	fp_nquery(msg, PACKETSZ, file);
-}
-
-void
-fp_nquery(const u_char *msg, int len, FILE *file) {
-	if ((_res.options & RES_INIT) == 0U && res_init() == -1)
-		return;
-
-	res_pquery(&_res, msg, len, file);
-}
-
-int
-res_mkquery(int op,			/*!< opcode of query  */
-	    const char *dname,		/*!< domain name  */
-	    int class, int type,	/*!< class and type of query  */
-	    const u_char *data,		/*!< resource record data  */
-	    int datalen,		/*!< length of data  */
-	    const u_char *newrr_in,	/*!< new rr for modify or append  */
-	    u_char *buf,		/*!< buffer to put query  */
-	    int buflen)			/*!< size of buffer  */
-{
-	if ((_res.options & RES_INIT) == 0U && res_init() == -1) {
-		RES_SET_H_ERRNO(&_res, NETDB_INTERNAL);
-		return (-1);
-	}
-	return (res_nmkquery(&_res, op, dname, class, type,
-			     data, datalen,
-			     newrr_in, buf, buflen));
-}
-
-int
-res_mkupdate(ns_updrec *rrecp_in, u_char *buf, int buflen) {
-	if ((_res.options & RES_INIT) == 0U && res_init() == -1) {
-		RES_SET_H_ERRNO(&_res, NETDB_INTERNAL);
-		return (-1);
-	}
-
-	return (res_nmkupdate(&_res, rrecp_in, buf, buflen));
-}
-
-int
-res_query(const char *name,	/*!< domain name  */
-	  int class, int type,	/*!< class and type of query  */
-	  u_char *answer,	/*!< buffer to put answer  */
-	  int anslen)		/*!< size of answer buffer  */
-{
-	if ((_res.options & RES_INIT) == 0U && res_init() == -1) {
-		RES_SET_H_ERRNO(&_res, NETDB_INTERNAL);
-		return (-1);
-	}
-	return (res_nquery(&_res, name, class, type, answer, anslen));
-}
-
-void
-res_send_setqhook(res_send_qhook hook) {
-	_res.qhook = hook;
-}
-
-void
-res_send_setrhook(res_send_rhook hook) {
-	_res.rhook = hook;
-}
-
-int
-res_isourserver(const struct sockaddr_in *inp) {
-	return (res_ourserver_p(&_res, inp));
-}
-
-int
-res_send(const u_char *buf, int buflen, u_char *ans, int anssiz) {
-	if ((_res.options & RES_INIT) == 0U && res_init() == -1) {
-		/* errno should have been set by res_init() in this case. */
-		return (-1);
-	}
-
-	return (res_nsend(&_res, buf, buflen, ans, anssiz));
-}
-
-int
-res_sendsigned(const u_char *buf, int buflen, ns_tsig_key *key,
-	       u_char *ans, int anssiz)
-{
-	if ((_res.options & RES_INIT) == 0U && res_init() == -1) {
-		/* errno should have been set by res_init() in this case. */
-		return (-1);
-	}
-
-	return (res_nsendsigned(&_res, buf, buflen, key, ans, anssiz));
-}
-
-void
-res_close(void) {
-	res_nclose(&_res);
-}
-
-int
-res_update(ns_updrec *rrecp_in) {
-	if ((_res.options & RES_INIT) == 0U && res_init() == -1) {
-		RES_SET_H_ERRNO(&_res, NETDB_INTERNAL);
-		return (-1);
-	}
-
-	return (res_nupdate(&_res, rrecp_in, NULL));
-}
-
-int
-res_search(const char *name,	/*!< domain name  */
-	   int class, int type,	/*!< class and type of query  */
-	   u_char *answer,	/*!< buffer to put answer  */
-	   int anslen)		/*!< size of answer  */
-{
-	if ((_res.options & RES_INIT) == 0U && res_init() == -1) {
-		RES_SET_H_ERRNO(&_res, NETDB_INTERNAL);
-		return (-1);
-	}
-
-	return (res_nsearch(&_res, name, class, type, answer, anslen));
-}
-
-int
-res_querydomain(const char *name,
-		const char *domain,
-		int class, int type,	/*!< class and type of query  */
-		u_char *answer,		/*!< buffer to put answer  */
-		int anslen)		/*!< size of answer  */
-{
-	if ((_res.options & RES_INIT) == 0U && res_init() == -1) {
-		RES_SET_H_ERRNO(&_res, NETDB_INTERNAL);
-		return (-1);
-	}
-
-	return (res_nquerydomain(&_res, name, domain,
-				 class, type,
-				 answer, anslen));
-}
-
-const char *
-hostalias(const char *name) {
-	static char abuf[MAXDNAME];
-
-	return (res_hostalias(&_res, name, abuf, sizeof abuf));
-}
-
-#ifdef ultrix
-int
-local_hostname_length(const char *hostname) {
-	int len_host, len_domain;
-
-	if (!*_res.defdname)
-		res_init();
-	len_host = strlen(hostname);
-	len_domain = strlen(_res.defdname);
-	if (len_host > len_domain &&
-	    !strcasecmp(hostname + len_host - len_domain, _res.defdname) &&
-	    hostname[len_host - len_domain - 1] == '.')
-		return (len_host - len_domain - 1);
-	return (0);
-}
-#endif /*ultrix*/
-
-#endif
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/resolv/res_debug.c b/contrib/bind9/lib/bind/resolv/res_debug.c
deleted file mode 100644
index 71dc676..0000000
--- a/contrib/bind9/lib/bind/resolv/res_debug.c
+++ /dev/null
@@ -1,1212 +0,0 @@
-/*
- * Copyright (c) 1985
- *    The Regents of the University of California.  All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- * 	This product includes software developed by the University of
- * 	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-/*
- * Portions Copyright (c) 1993 by Digital Equipment Corporation.
- * 
- * 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, and that
- * the name of Digital Equipment Corporation not be used in advertising or
- * publicity pertaining to distribution of the document or software without
- * specific, written prior permission.
- * 
- * THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
- * WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
- * OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
- * CORPORATION 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.
- */
-
-/*
- * Portions Copyright (c) 1995 by International Business Machines, Inc.
- *
- * International Business Machines, Inc. (hereinafter called IBM) grants
- * permission under its copyrights to use, copy, modify, and distribute this
- * Software with or without fee, provided that the above copyright notice and
- * all paragraphs of this notice appear in all copies, and that the name of IBM
- * not be used in connection with the marketing of any product incorporating
- * the Software or modifications thereof, without specific, written prior
- * permission.
- *
- * To the extent it has a right to do so, IBM grants an immunity from suit
- * under its patents, if any, for the use, sale or manufacture of products to
- * the extent that such products are used for performing Domain Name System
- * dynamic updates in TCP/IP networks by means of the Software.  No immunity is
- * granted for any product per se or for any other function of any product.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", AND IBM DISCLAIMS ALL WARRANTIES,
- * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
- * PARTICULAR PURPOSE.  IN NO EVENT SHALL IBM BE LIABLE FOR ANY SPECIAL,
- * DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER ARISING
- * OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE, EVEN
- * IF IBM IS APPRISED OF THE POSSIBILITY OF SUCH DAMAGES.
- */
-
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-#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.10.18.6 2008/04/03 23:15:15 marka Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/param.h>
-#include <sys/socket.h>
-
-#include <netinet/in.h>
-#include <arpa/inet.h>
-#include <arpa/nameser.h>
-
-#include <ctype.h>
-#include <errno.h>
-#include <math.h>
-#include <netdb.h>
-#include <resolv.h>
-#include <resolv_mt.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <time.h>
-
-#include "port_after.h"
-
-#ifdef SPRINTF_CHAR
-# define SPRINTF(x) strlen(sprintf/**/x)
-#else
-# define SPRINTF(x) sprintf x
-#endif
-
-extern const char *_res_opcodes[];
-extern const char *_res_sectioncodes[];
-
-/*%
- * Print the current options.
- */
-void
-fp_resstat(const res_state statp, FILE *file) {
-	u_long mask;
-
-	fprintf(file, ";; res options:");
-	for (mask = 1;  mask != 0U;  mask <<= 1)
-		if (statp->options & mask)
-			fprintf(file, " %s", p_option(mask));
-	putc('\n', file);
-}
-
-static void
-do_section(const res_state statp,
-	   ns_msg *handle, ns_sect section,
-	   int pflag, FILE *file)
-{
-	int n, sflag, rrnum;
-	static int buflen = 2048;
-	char *buf;
-	ns_opcode opcode;
-	ns_rr rr;
-
-	/*
-	 * Print answer records.
-	 */
-	sflag = (statp->pfcode & pflag);
-	if (statp->pfcode && !sflag)
-		return;
-
-	buf = malloc(buflen);
-	if (buf == NULL) {
-		fprintf(file, ";; memory allocation failure\n");
-		return;
-	}
-
-	opcode = (ns_opcode) ns_msg_getflag(*handle, ns_f_opcode);
-	rrnum = 0;
-	for (;;) {
-		if (ns_parserr(handle, section, rrnum, &rr)) {
-			if (errno != ENODEV)
-				fprintf(file, ";; ns_parserr: %s\n",
-					strerror(errno));
-			else if (rrnum > 0 && sflag != 0 &&
-				 (statp->pfcode & RES_PRF_HEAD1))
-				putc('\n', file);
-			goto cleanup;
-		}
-		if (rrnum == 0 && sflag != 0 && (statp->pfcode & RES_PRF_HEAD1))
-			fprintf(file, ";; %s SECTION:\n",
-				p_section(section, opcode));
-		if (section == ns_s_qd)
-			fprintf(file, ";;\t%s, type = %s, class = %s\n",
-				ns_rr_name(rr),
-				p_type(ns_rr_type(rr)),
-				p_class(ns_rr_class(rr)));
-		else if (section == ns_s_ar && ns_rr_type(rr) == ns_t_opt) {
-			u_int16_t optcode, optlen, rdatalen = ns_rr_rdlen(rr);
-			u_int32_t ttl = ns_rr_ttl(rr);
-
-			fprintf(file,
-				"; EDNS: version: %u, udp=%u, flags=%04x\n",
-				(ttl>>16)&0xff, ns_rr_class(rr), ttl&0xffff);
-
-			while (rdatalen >= 4) {
-				const u_char *cp = ns_rr_rdata(rr);
-				int i;
-
-				GETSHORT(optcode, cp);
-				GETSHORT(optlen, cp);
-
-				if (optcode == NS_OPT_NSID) {
-					fputs("; NSID: ", file);
-					if (optlen == 0) {
-						fputs("; NSID\n", file);
-					} else {
-						fputs("; NSID: ", file);
-						for (i = 0; i < optlen; i++)
-							fprintf(file, "%02x ",
-								cp[i]);
-						fputs(" (",file);
-						for (i = 0; i < optlen; i++)
-							fprintf(file, "%c",
-								isprint(cp[i])?
-								cp[i] : '.');
-						fputs(")\n", file);
-					}
-				} else {
-					if (optlen == 0) {
-						fprintf(file, "; OPT=%u\n",
-							optcode);
-					} else {
-						fprintf(file, "; OPT=%u: ",
-							optcode);
-						for (i = 0; i < optlen; i++)
-							fprintf(file, "%02x ",
-								cp[i]);
-						fputs(" (",file);
-						for (i = 0; i < optlen; i++)
-							fprintf(file, "%c",
-								isprint(cp[i]) ?
-									cp[i] : '.');
-						fputs(")\n", file);
-					}
-				}
-				rdatalen -= 4 + optlen;
-			}
-		} else {
-			n = ns_sprintrr(handle, &rr, NULL, NULL,
-					buf, buflen);
-			if (n < 0) {
-				if (errno == ENOSPC) {
-					free(buf);
-					buf = NULL;
-					if (buflen < 131072)
-						buf = malloc(buflen += 1024);
-					if (buf == NULL) {
-						fprintf(file,
-					      ";; memory allocation failure\n");
-					      return;
-					}
-					continue;
-				}
-				fprintf(file, ";; ns_sprintrr: %s\n",
-					strerror(errno));
-				goto cleanup;
-			}
-			fputs(buf, file);
-			fputc('\n', file);
-		}
-		rrnum++;
-	}
- cleanup:
-	if (buf != NULL)
-		free(buf);
-}
-
-/*%
- * Print the contents of a query.
- * This is intended to be primarily a debugging routine.
- */
-void
-res_pquery(const res_state statp, const u_char *msg, int len, FILE *file) {
-	ns_msg handle;
-	int qdcount, ancount, nscount, arcount;
-	u_int opcode, rcode, id;
-
-	if (ns_initparse(msg, len, &handle) < 0) {
-		fprintf(file, ";; ns_initparse: %s\n", strerror(errno));
-		return;
-	}
-	opcode = ns_msg_getflag(handle, ns_f_opcode);
-	rcode = ns_msg_getflag(handle, ns_f_rcode);
-	id = ns_msg_id(handle);
-	qdcount = ns_msg_count(handle, ns_s_qd);
-	ancount = ns_msg_count(handle, ns_s_an);
-	nscount = ns_msg_count(handle, ns_s_ns);
-	arcount = ns_msg_count(handle, ns_s_ar);
-
-	/*
-	 * Print header fields.
-	 */
-	if ((!statp->pfcode) || (statp->pfcode & RES_PRF_HEADX) || rcode)
-		fprintf(file,
-			";; ->>HEADER<<- opcode: %s, status: %s, id: %d\n",
-			_res_opcodes[opcode], p_rcode(rcode), id);
-	if ((!statp->pfcode) || (statp->pfcode & RES_PRF_HEADX))
-		putc(';', file);
-	if ((!statp->pfcode) || (statp->pfcode & RES_PRF_HEAD2)) {
-		fprintf(file, "; flags:");
-		if (ns_msg_getflag(handle, ns_f_qr))
-			fprintf(file, " qr");
-		if (ns_msg_getflag(handle, ns_f_aa))
-			fprintf(file, " aa");
-		if (ns_msg_getflag(handle, ns_f_tc))
-			fprintf(file, " tc");
-		if (ns_msg_getflag(handle, ns_f_rd))
-			fprintf(file, " rd");
-		if (ns_msg_getflag(handle, ns_f_ra))
-			fprintf(file, " ra");
-		if (ns_msg_getflag(handle, ns_f_z))
-			fprintf(file, " ??");
-		if (ns_msg_getflag(handle, ns_f_ad))
-			fprintf(file, " ad");
-		if (ns_msg_getflag(handle, ns_f_cd))
-			fprintf(file, " cd");
-	}
-	if ((!statp->pfcode) || (statp->pfcode & RES_PRF_HEAD1)) {
-		fprintf(file, "; %s: %d",
-			p_section(ns_s_qd, opcode), qdcount);
-		fprintf(file, ", %s: %d",
-			p_section(ns_s_an, opcode), ancount);
-		fprintf(file, ", %s: %d",
-			p_section(ns_s_ns, opcode), nscount);
-		fprintf(file, ", %s: %d",
-			p_section(ns_s_ar, opcode), arcount);
-	}
-	if ((!statp->pfcode) || (statp->pfcode & 
-		(RES_PRF_HEADX | RES_PRF_HEAD2 | RES_PRF_HEAD1))) {
-		putc('\n',file);
-	}
-	/*
-	 * Print the various sections.
-	 */
-	do_section(statp, &handle, ns_s_qd, RES_PRF_QUES, file);
-	do_section(statp, &handle, ns_s_an, RES_PRF_ANS, file);
-	do_section(statp, &handle, ns_s_ns, RES_PRF_AUTH, file);
-	do_section(statp, &handle, ns_s_ar, RES_PRF_ADD, file);
-	if (qdcount == 0 && ancount == 0 &&
-	    nscount == 0 && arcount == 0)
-		putc('\n', file);
-}
-
-const u_char *
-p_cdnname(const u_char *cp, const u_char *msg, int len, FILE *file) {
-	char name[MAXDNAME];
-	int n;
-
-	if ((n = dn_expand(msg, msg + len, cp, name, sizeof name)) < 0)
-		return (NULL);
-	if (name[0] == '\0')
-		putc('.', file);
-	else
-		fputs(name, file);
-	return (cp + n);
-}
-
-const u_char *
-p_cdname(const u_char *cp, const u_char *msg, FILE *file) {
-	return (p_cdnname(cp, msg, PACKETSZ, file));
-}
-
-/*%
- * Return a fully-qualified domain name from a compressed name (with
-   length supplied).  */
-
-const u_char *
-p_fqnname(cp, msg, msglen, name, namelen)
-	const u_char *cp, *msg;
-	int msglen;
-	char *name;
-	int namelen;
-{
-	int n, newlen;
-
-	if ((n = dn_expand(msg, cp + msglen, cp, name, namelen)) < 0)
-		return (NULL);
-	newlen = strlen(name);
-	if (newlen == 0 || name[newlen - 1] != '.') {
-		if (newlen + 1 >= namelen)	/*%< Lack space for final dot */
-			return (NULL);
-		else
-			strcpy(name + newlen, ".");
-	}
-	return (cp + n);
-}
-
-/* XXX:	the rest of these functions need to become length-limited, too. */
-
-const u_char *
-p_fqname(const u_char *cp, const u_char *msg, FILE *file) {
-	char name[MAXDNAME];
-	const u_char *n;
-
-	n = p_fqnname(cp, msg, MAXCDNAME, name, sizeof name);
-	if (n == NULL)
-		return (NULL);
-	fputs(name, file);
-	return (n);
-}
-
-/*%
- * Names of RR classes and qclasses.  Classes and qclasses are the same, except
- * that C_ANY is a qclass but not a class.  (You can ask for records of class
- * C_ANY, but you can't have any records of that class in the database.)
- */
-const struct res_sym __p_class_syms[] = {
-	{C_IN,		"IN",		(char *)0},
-	{C_CHAOS,	"CH",		(char *)0},
-	{C_CHAOS,	"CHAOS",	(char *)0},
-	{C_HS,		"HS",		(char *)0},
-	{C_HS,		"HESIOD",	(char *)0},
-	{C_ANY,		"ANY",		(char *)0},
-	{C_NONE,	"NONE",		(char *)0},
-	{C_IN, 		(char *)0,	(char *)0}
-};
-
-/*%
- * Names of message sections.
- */
-const struct res_sym __p_default_section_syms[] = {
-	{ns_s_qd,	"QUERY",	(char *)0},
-	{ns_s_an,	"ANSWER",	(char *)0},
-	{ns_s_ns,	"AUTHORITY",	(char *)0},
-	{ns_s_ar,	"ADDITIONAL",	(char *)0},
-	{0,		(char *)0,	(char *)0}
-};
-
-const struct res_sym __p_update_section_syms[] = {
-	{S_ZONE,	"ZONE",		(char *)0},
-	{S_PREREQ,	"PREREQUISITE",	(char *)0},
-	{S_UPDATE,	"UPDATE",	(char *)0},
-	{S_ADDT,	"ADDITIONAL",	(char *)0},
-	{0,		(char *)0,	(char *)0}
-};
-
-const struct res_sym __p_key_syms[] = {
-	{NS_ALG_MD5RSA,		"RSA",		"RSA KEY with MD5 hash"},
-	{NS_ALG_DH,		"DH",		"Diffie Hellman"},
-	{NS_ALG_DSA,		"DSA",		"Digital Signature Algorithm"},
-	{NS_ALG_EXPIRE_ONLY,	"EXPIREONLY",	"No algorithm"},
-	{NS_ALG_PRIVATE_OID,	"PRIVATE",	"Algorithm obtained from OID"},
-	{0,			NULL,		NULL}
-};
-
-const struct res_sym __p_cert_syms[] = {
-	{cert_t_pkix,	"PKIX",		"PKIX (X.509v3) Certificate"},
-	{cert_t_spki,	"SPKI",		"SPKI certificate"},
-	{cert_t_pgp,	"PGP",		"PGP certificate"},
-	{cert_t_url,	"URL",		"URL Private"},
-	{cert_t_oid,	"OID",		"OID Private"},
-	{0,		NULL,		NULL}
-};
-
-/*%
- * Names of RR types and qtypes.  Types and qtypes are the same, except
- * that T_ANY is a qtype but not a type.  (You can ask for records of type
- * T_ANY, but you can't have any records of that type in the database.)
- */
-const struct res_sym __p_type_syms[] = {
-	{ns_t_a,	"A",		"address"},
-	{ns_t_ns,	"NS",		"name server"},
-	{ns_t_md,	"MD",		"mail destination (deprecated)"},
-	{ns_t_mf,	"MF",		"mail forwarder (deprecated)"},
-	{ns_t_cname,	"CNAME",	"canonical name"},
-	{ns_t_soa,	"SOA",		"start of authority"},
-	{ns_t_mb,	"MB",		"mailbox"},
-	{ns_t_mg,	"MG",		"mail group member"},
-	{ns_t_mr,	"MR",		"mail rename"},
-	{ns_t_null,	"NULL",		"null"},
-	{ns_t_wks,	"WKS",		"well-known service (deprecated)"},
-	{ns_t_ptr,	"PTR",		"domain name pointer"},
-	{ns_t_hinfo,	"HINFO",	"host information"},
-	{ns_t_minfo,	"MINFO",	"mailbox information"},
-	{ns_t_mx,	"MX",		"mail exchanger"},
-	{ns_t_txt,	"TXT",		"text"},
-	{ns_t_rp,	"RP",		"responsible person"},
-	{ns_t_afsdb,	"AFSDB",	"DCE or AFS server"},
-	{ns_t_x25,	"X25",		"X25 address"},
-	{ns_t_isdn,	"ISDN",		"ISDN address"},
-	{ns_t_rt,	"RT",		"router"},
-	{ns_t_nsap,	"NSAP",		"nsap address"},
-	{ns_t_nsap_ptr,	"NSAP_PTR",	"domain name pointer"},
-	{ns_t_sig,	"SIG",		"signature"},
-	{ns_t_key,	"KEY",		"key"},
-	{ns_t_px,	"PX",		"mapping information"},
-	{ns_t_gpos,	"GPOS",		"geographical position (withdrawn)"},
-	{ns_t_aaaa,	"AAAA",		"IPv6 address"},
-	{ns_t_loc,	"LOC",		"location"},
-	{ns_t_nxt,	"NXT",		"next valid name (unimplemented)"},
-	{ns_t_eid,	"EID",		"endpoint identifier (unimplemented)"},
-	{ns_t_nimloc,	"NIMLOC",	"NIMROD locator (unimplemented)"},
-	{ns_t_srv,	"SRV",		"server selection"},
-	{ns_t_atma,	"ATMA",		"ATM address (unimplemented)"},
-	{ns_t_tkey,	"TKEY",		"tkey"},
-	{ns_t_tsig,	"TSIG",		"transaction signature"},
-	{ns_t_ixfr,	"IXFR",		"incremental zone transfer"},
-	{ns_t_axfr,	"AXFR",		"zone transfer"},
-	{ns_t_zxfr,	"ZXFR",		"compressed zone transfer"},
-	{ns_t_mailb,	"MAILB",	"mailbox-related data (deprecated)"},
-	{ns_t_maila,	"MAILA",	"mail agent (deprecated)"},
-	{ns_t_naptr,	"NAPTR",	"URN Naming Authority"},
-	{ns_t_kx,	"KX",		"Key Exchange"},
-	{ns_t_cert,	"CERT",		"Certificate"},
-	{ns_t_a6,	"A6",		"IPv6 Address"},
-	{ns_t_dname,	"DNAME",	"dname"},
-	{ns_t_sink,	"SINK",		"Kitchen Sink (experimental)"},
-	{ns_t_opt,	"OPT",		"EDNS Options"},
-	{ns_t_any,	"ANY",		"\"any\""},
-	{0, 		NULL,		NULL}
-};
-
-/*%
- * Names of DNS rcodes.
- */
-const struct res_sym __p_rcode_syms[] = {
-	{ns_r_noerror,	"NOERROR",		"no error"},
-	{ns_r_formerr,	"FORMERR",		"format error"},
-	{ns_r_servfail,	"SERVFAIL",		"server failed"},
-	{ns_r_nxdomain,	"NXDOMAIN",		"no such domain name"},
-	{ns_r_notimpl,	"NOTIMP",		"not implemented"},
-	{ns_r_refused,	"REFUSED",		"refused"},
-	{ns_r_yxdomain,	"YXDOMAIN",		"domain name exists"},
-	{ns_r_yxrrset,	"YXRRSET",		"rrset exists"},
-	{ns_r_nxrrset,	"NXRRSET",		"rrset doesn't exist"},
-	{ns_r_notauth,	"NOTAUTH",		"not authoritative"},
-	{ns_r_notzone,	"NOTZONE",		"Not in zone"},
-	{ns_r_max,	"",			""},
-	{ns_r_badsig,	"BADSIG",		"bad signature"},
-	{ns_r_badkey,	"BADKEY",		"bad key"},
-	{ns_r_badtime,	"BADTIME",		"bad time"},
-	{0, 		NULL,			NULL}
-};
-
-int
-sym_ston(const struct res_sym *syms, const char *name, int *success) {
-	for ((void)NULL; syms->name != 0; syms++) {
-		if (strcasecmp (name, syms->name) == 0) {
-			if (success)
-				*success = 1;
-			return (syms->number);
-		}
-	}
-	if (success)
-		*success = 0;
-	return (syms->number);		/*%< The default value. */
-}
-
-const char *
-sym_ntos(const struct res_sym *syms, int number, int *success) {
-	char *unname = sym_ntos_unname;
-
-	for ((void)NULL; syms->name != 0; syms++) {
-		if (number == syms->number) {
-			if (success)
-				*success = 1;
-			return (syms->name);
-		}
-	}
-
-	sprintf(unname, "%d", number);		/*%< XXX nonreentrant */
-	if (success)
-		*success = 0;
-	return (unname);
-}
-
-const char *
-sym_ntop(const struct res_sym *syms, int number, int *success) {
-	char *unname = sym_ntop_unname;
-
-	for ((void)NULL; syms->name != 0; syms++) {
-		if (number == syms->number) {
-			if (success)
-				*success = 1;
-			return (syms->humanname);
-		}
-	}
-	sprintf(unname, "%d", number);		/*%< XXX nonreentrant */
-	if (success)
-		*success = 0;
-	return (unname);
-}
-
-/*%
- * Return a string for the type.
- */
-const char *
-p_type(int type) {
-	int success;
-	const char *result;
-	static char typebuf[20];
-
-	result = sym_ntos(__p_type_syms, type, &success);
-	if (success)
-		return (result);
-	if (type < 0 || type > 0xffff)
-		return ("BADTYPE");
-	sprintf(typebuf, "TYPE%d", type);
-	return (typebuf);
-}
-
-/*%
- * Return a string for the type.
- */
-const char *
-p_section(int section, int opcode) {
-	const struct res_sym *symbols;
-
-	switch (opcode) {
-	case ns_o_update:
-		symbols = __p_update_section_syms;
-		break;
-	default:
-		symbols = __p_default_section_syms;
-		break;
-	}
-	return (sym_ntos(symbols, section, (int *)0));
-}
-
-/*%
- * Return a mnemonic for class.
- */
-const char *
-p_class(int class) {
-	int success;
-	const char *result;
-	static char classbuf[20];
-
-	result = sym_ntos(__p_class_syms, class, &success);
-	if (success)
-		return (result);
-	if (class < 0 || class > 0xffff)
-		return ("BADCLASS");
-	sprintf(classbuf, "CLASS%d", class);
-	return (classbuf);
-}
-
-/*%
- * Return a mnemonic for an option
- */
-const char *
-p_option(u_long option) {
-	char *nbuf = p_option_nbuf;
-
-	switch (option) {
-	case RES_INIT:		return "init";
-	case RES_DEBUG:		return "debug";
-	case RES_AAONLY:	return "aaonly(unimpl)";
-	case RES_USEVC:		return "usevc";
-	case RES_PRIMARY:	return "primry(unimpl)";
-	case RES_IGNTC:		return "igntc";
-	case RES_RECURSE:	return "recurs";
-	case RES_DEFNAMES:	return "defnam";
-	case RES_STAYOPEN:	return "styopn";
-	case RES_DNSRCH:	return "dnsrch";
-	case RES_INSECURE1:	return "insecure1";
-	case RES_INSECURE2:	return "insecure2";
-	case RES_NOALIASES:	return "noaliases";
-	case RES_USE_INET6:	return "inet6";
-#ifdef RES_USE_EDNS0	/*%< KAME extension */
-	case RES_USE_EDNS0:	return "edns0";
-	case RES_NSID:		return "nsid";
-#endif
-#ifdef RES_USE_DNAME
-	case RES_USE_DNAME:	return "dname";
-#endif
-#ifdef RES_USE_DNSSEC
-	case RES_USE_DNSSEC:	return "dnssec";
-#endif
-#ifdef RES_NOTLDQUERY
-	case RES_NOTLDQUERY:	return "no-tld-query";
-#endif
-#ifdef RES_NO_NIBBLE2
-	case RES_NO_NIBBLE2:	return "no-nibble2";
-#endif
-				/* XXX nonreentrant */
-	default:		sprintf(nbuf, "?0x%lx?", (u_long)option);
-				return (nbuf);
-	}
-}
-
-/*%
- * Return a mnemonic for a time to live.
- */
-const char *
-p_time(u_int32_t value) {
-	char *nbuf = p_time_nbuf;
-
-	if (ns_format_ttl(value, nbuf, sizeof nbuf) < 0)
-		sprintf(nbuf, "%u", value);
-	return (nbuf);
-}
-
-/*%
- * Return a string for the rcode.
- */
-const char *
-p_rcode(int rcode) {
-	return (sym_ntos(__p_rcode_syms, rcode, (int *)0));
-}
-
-/*%
- * Return a string for a res_sockaddr_union.
- */
-const char *
-p_sockun(union res_sockaddr_union u, char *buf, size_t size) {
-	char ret[sizeof "ffff:ffff:ffff:ffff:ffff:ffff:123.123.123.123"];
-
-	switch (u.sin.sin_family) {
-	case AF_INET:
-		inet_ntop(AF_INET, &u.sin.sin_addr, ret, sizeof ret);
-		break;
-#ifdef HAS_INET6_STRUCTS
-	case AF_INET6:
-		inet_ntop(AF_INET6, &u.sin6.sin6_addr, ret, sizeof ret);
-		break;
-#endif
-	default:
-		sprintf(ret, "[af%d]", u.sin.sin_family);
-		break;
-	}
-	if (size > 0U) {
-		strncpy(buf, ret, size - 1);
-		buf[size - 1] = '0';
-	}
-	return (buf);
-}
-
-/*%
- * routines to convert between on-the-wire RR format and zone file format.
- * Does not contain conversion to/from decimal degrees; divide or multiply
- * by 60*60*1000 for that.
- */
-
-static unsigned int poweroften[10] = {1, 10, 100, 1000, 10000, 100000,
-				      1000000,10000000,100000000,1000000000};
-
-/*% takes an XeY precision/size value, returns a string representation. */
-static const char *
-precsize_ntoa(prec)
-	u_int8_t prec;
-{
-	char *retbuf = precsize_ntoa_retbuf;
-	unsigned long val;
-	int mantissa, exponent;
-
-	mantissa = (int)((prec >> 4) & 0x0f) % 10;
-	exponent = (int)((prec >> 0) & 0x0f) % 10;
-
-	val = mantissa * poweroften[exponent];
-
-	(void) sprintf(retbuf, "%lu.%.2lu", val/100, val%100);
-	return (retbuf);
-}
-
-/*% converts ascii size/precision X * 10**Y(cm) to 0xXY.  moves pointer.  */
-static u_int8_t
-precsize_aton(const char **strptr) {
-	unsigned int mval = 0, cmval = 0;
-	u_int8_t retval = 0;
-	const char *cp;
-	int exponent;
-	int mantissa;
-
-	cp = *strptr;
-
-	while (isdigit((unsigned char)*cp))
-		mval = mval * 10 + (*cp++ - '0');
-
-	if (*cp == '.') {		/*%< centimeters */
-		cp++;
-		if (isdigit((unsigned char)*cp)) {
-			cmval = (*cp++ - '0') * 10;
-			if (isdigit((unsigned char)*cp)) {
-				cmval += (*cp++ - '0');
-			}
-		}
-	}
-	cmval = (mval * 100) + cmval;
-
-	for (exponent = 0; exponent < 9; exponent++)
-		if (cmval < poweroften[exponent+1])
-			break;
-
-	mantissa = cmval / poweroften[exponent];
-	if (mantissa > 9)
-		mantissa = 9;
-
-	retval = (mantissa << 4) | exponent;
-
-	*strptr = cp;
-
-	return (retval);
-}
-
-/*% converts ascii lat/lon to unsigned encoded 32-bit number.  moves pointer. */
-static u_int32_t
-latlon2ul(const char **latlonstrptr, int *which) {
-	const char *cp;
-	u_int32_t retval;
-	int deg = 0, min = 0, secs = 0, secsfrac = 0;
-
-	cp = *latlonstrptr;
-
-	while (isdigit((unsigned char)*cp))
-		deg = deg * 10 + (*cp++ - '0');
-
-	while (isspace((unsigned char)*cp))
-		cp++;
-
-	if (!(isdigit((unsigned char)*cp)))
-		goto fndhemi;
-
-	while (isdigit((unsigned char)*cp))
-		min = min * 10 + (*cp++ - '0');
-
-	while (isspace((unsigned char)*cp))
-		cp++;
-
-	if (!(isdigit((unsigned char)*cp)))
-		goto fndhemi;
-
-	while (isdigit((unsigned char)*cp))
-		secs = secs * 10 + (*cp++ - '0');
-
-	if (*cp == '.') {		/*%< decimal seconds */
-		cp++;
-		if (isdigit((unsigned char)*cp)) {
-			secsfrac = (*cp++ - '0') * 100;
-			if (isdigit((unsigned char)*cp)) {
-				secsfrac += (*cp++ - '0') * 10;
-				if (isdigit((unsigned char)*cp)) {
-					secsfrac += (*cp++ - '0');
-				}
-			}
-		}
-	}
-
-	while (!isspace((unsigned char)*cp))	/*%< if any trailing garbage */
-		cp++;
-
-	while (isspace((unsigned char)*cp))
-		cp++;
-
- fndhemi:
-	switch (*cp) {
-	case 'N': case 'n':
-	case 'E': case 'e':
-		retval = ((unsigned)1<<31)
-			+ (((((deg * 60) + min) * 60) + secs) * 1000)
-			+ secsfrac;
-		break;
-	case 'S': case 's':
-	case 'W': case 'w':
-		retval = ((unsigned)1<<31)
-			- (((((deg * 60) + min) * 60) + secs) * 1000)
-			- secsfrac;
-		break;
-	default:
-		retval = 0;	/*%< invalid value -- indicates error */
-		break;
-	}
-
-	switch (*cp) {
-	case 'N': case 'n':
-	case 'S': case 's':
-		*which = 1;	/*%< latitude */
-		break;
-	case 'E': case 'e':
-	case 'W': case 'w':
-		*which = 2;	/*%< longitude */
-		break;
-	default:
-		*which = 0;	/*%< error */
-		break;
-	}
-
-	cp++;			/*%< skip the hemisphere */
-	while (!isspace((unsigned char)*cp))	/*%< if any trailing garbage */
-		cp++;
-
-	while (isspace((unsigned char)*cp))	/*%< move to next field */
-		cp++;
-
-	*latlonstrptr = cp;
-
-	return (retval);
-}
-
-/*%
- * converts a zone file representation in a string to an RDATA on-the-wire
- * representation. */
-int
-loc_aton(ascii, binary)
-	const char *ascii;
-	u_char *binary;
-{
-	const char *cp, *maxcp;
-	u_char *bcp;
-
-	u_int32_t latit = 0, longit = 0, alt = 0;
-	u_int32_t lltemp1 = 0, lltemp2 = 0;
-	int altmeters = 0, altfrac = 0, altsign = 1;
-	u_int8_t hp = 0x16;	/*%< default = 1e6 cm = 10000.00m = 10km */
-	u_int8_t vp = 0x13;	/*%< default = 1e3 cm = 10.00m */
-	u_int8_t siz = 0x12;	/*%< default = 1e2 cm = 1.00m */
-	int which1 = 0, which2 = 0;
-
-	cp = ascii;
-	maxcp = cp + strlen(ascii);
-
-	lltemp1 = latlon2ul(&cp, &which1);
-
-	lltemp2 = latlon2ul(&cp, &which2);
-
-	switch (which1 + which2) {
-	case 3:			/*%< 1 + 2, the only valid combination */
-		if ((which1 == 1) && (which2 == 2)) { /*%< normal case */
-			latit = lltemp1;
-			longit = lltemp2;
-		} else if ((which1 == 2) && (which2 == 1)) { /*%< reversed */
-			longit = lltemp1;
-			latit = lltemp2;
-		} else {	/*%< some kind of brokenness */
-			return (0);
-		}
-		break;
-	default:		/*%< we didn't get one of each */
-		return (0);
-	}
-
-	/* altitude */
-	if (*cp == '-') {
-		altsign = -1;
-		cp++;
-	}
-    
-	if (*cp == '+')
-		cp++;
-
-	while (isdigit((unsigned char)*cp))
-		altmeters = altmeters * 10 + (*cp++ - '0');
-
-	if (*cp == '.') {		/*%< decimal meters */
-		cp++;
-		if (isdigit((unsigned char)*cp)) {
-			altfrac = (*cp++ - '0') * 10;
-			if (isdigit((unsigned char)*cp)) {
-				altfrac += (*cp++ - '0');
-			}
-		}
-	}
-
-	alt = (10000000 + (altsign * (altmeters * 100 + altfrac)));
-
-	while (!isspace((unsigned char)*cp) && (cp < maxcp)) /*%< if trailing garbage or m */
-		cp++;
-
-	while (isspace((unsigned char)*cp) && (cp < maxcp))
-		cp++;
-
-	if (cp >= maxcp)
-		goto defaults;
-
-	siz = precsize_aton(&cp);
-	
-	while (!isspace((unsigned char)*cp) && (cp < maxcp))	/*%< if trailing garbage or m */
-		cp++;
-
-	while (isspace((unsigned char)*cp) && (cp < maxcp))
-		cp++;
-
-	if (cp >= maxcp)
-		goto defaults;
-
-	hp = precsize_aton(&cp);
-
-	while (!isspace((unsigned char)*cp) && (cp < maxcp))	/*%< if trailing garbage or m */
-		cp++;
-
-	while (isspace((unsigned char)*cp) && (cp < maxcp))
-		cp++;
-
-	if (cp >= maxcp)
-		goto defaults;
-
-	vp = precsize_aton(&cp);
-
- defaults:
-
-	bcp = binary;
-	*bcp++ = (u_int8_t) 0;	/*%< version byte */
-	*bcp++ = siz;
-	*bcp++ = hp;
-	*bcp++ = vp;
-	PUTLONG(latit,bcp);
-	PUTLONG(longit,bcp);
-	PUTLONG(alt,bcp);
-    
-	return (16);		/*%< size of RR in octets */
-}
-
-/*% takes an on-the-wire LOC RR and formats it in a human readable format. */
-const char *
-loc_ntoa(binary, ascii)
-	const u_char *binary;
-	char *ascii;
-{
-	static const char *error = "?";
-	static char tmpbuf[sizeof
-"1000 60 60.000 N 1000 60 60.000 W -12345678.00m 90000000.00m 90000000.00m 90000000.00m"];
-	const u_char *cp = binary;
-
-	int latdeg, latmin, latsec, latsecfrac;
-	int longdeg, longmin, longsec, longsecfrac;
-	char northsouth, eastwest;
-	const char *altsign;
-	int altmeters, altfrac;
-
-	const u_int32_t referencealt = 100000 * 100;
-
-	int32_t latval, longval, altval;
-	u_int32_t templ;
-	u_int8_t sizeval, hpval, vpval, versionval;
-    
-	char *sizestr, *hpstr, *vpstr;
-
-	versionval = *cp++;
-
-	if (ascii == NULL)
-		ascii = tmpbuf;
-
-	if (versionval) {
-		(void) sprintf(ascii, "; error: unknown LOC RR version");
-		return (ascii);
-	}
-
-	sizeval = *cp++;
-
-	hpval = *cp++;
-	vpval = *cp++;
-
-	GETLONG(templ, cp);
-	latval = (templ - ((unsigned)1<<31));
-
-	GETLONG(templ, cp);
-	longval = (templ - ((unsigned)1<<31));
-
-	GETLONG(templ, cp);
-	if (templ < referencealt) { /*%< below WGS 84 spheroid */
-		altval = referencealt - templ;
-		altsign = "-";
-	} else {
-		altval = templ - referencealt;
-		altsign = "";
-	}
-
-	if (latval < 0) {
-		northsouth = 'S';
-		latval = -latval;
-	} else
-		northsouth = 'N';
-
-	latsecfrac = latval % 1000;
-	latval = latval / 1000;
-	latsec = latval % 60;
-	latval = latval / 60;
-	latmin = latval % 60;
-	latval = latval / 60;
-	latdeg = latval;
-
-	if (longval < 0) {
-		eastwest = 'W';
-		longval = -longval;
-	} else
-		eastwest = 'E';
-
-	longsecfrac = longval % 1000;
-	longval = longval / 1000;
-	longsec = longval % 60;
-	longval = longval / 60;
-	longmin = longval % 60;
-	longval = longval / 60;
-	longdeg = longval;
-
-	altfrac = altval % 100;
-	altmeters = (altval / 100);
-
-	sizestr = strdup(precsize_ntoa(sizeval));
-	hpstr = strdup(precsize_ntoa(hpval));
-	vpstr = strdup(precsize_ntoa(vpval));
-
-	sprintf(ascii,
-	    "%d %.2d %.2d.%.3d %c %d %.2d %.2d.%.3d %c %s%d.%.2dm %sm %sm %sm",
-		latdeg, latmin, latsec, latsecfrac, northsouth,
-		longdeg, longmin, longsec, longsecfrac, eastwest,
-		altsign, altmeters, altfrac,
-		(sizestr != NULL) ? sizestr : error,
-		(hpstr != NULL) ? hpstr : error,
-		(vpstr != NULL) ? vpstr : error);
-
-	if (sizestr != NULL)
-		free(sizestr);
-	if (hpstr != NULL)
-		free(hpstr);
-	if (vpstr != NULL)
-		free(vpstr);
-
-	return (ascii);
-}
-
-
-/*% Return the number of DNS hierarchy levels in the name. */
-int
-dn_count_labels(const char *name) {
-	int i, len, count;
-
-	len = strlen(name);
-	for (i = 0, count = 0; i < len; i++) {
-		/* XXX need to check for \. or use named's nlabels(). */
-		if (name[i] == '.')
-			count++;
-	}
-
-	/* don't count initial wildcard */
-	if (name[0] == '*')
-		if (count)
-			count--;
-
-	/* don't count the null label for root. */
-	/* if terminating '.' not found, must adjust */
-	/* count to include last label */
-	if (len > 0 && name[len-1] != '.')
-		count++;
-	return (count);
-}
-
-/*%
- * Make dates expressed in seconds-since-Jan-1-1970 easy to read.  
- * SIG records are required to be printed like this, by the Secure DNS RFC.
- */
-char *
-p_secstodate (u_long secs) {
-	char *output = p_secstodate_output;
-	time_t clock = secs;
-	struct tm *time;
-#ifdef HAVE_TIME_R
-	struct tm res;
-	
-	time = gmtime_r(&clock, &res);
-#else
-	time = gmtime(&clock);
-#endif
-	time->tm_year += 1900;
-	time->tm_mon += 1;
-	sprintf(output, "%04d%02d%02d%02d%02d%02d",
-		time->tm_year, time->tm_mon, time->tm_mday,
-		time->tm_hour, time->tm_min, time->tm_sec);
-	return (output);
-}
-
-u_int16_t
-res_nametoclass(const char *buf, int *successp) {
-	unsigned long result;
-	char *endptr;
-	int success;
-
-	result = sym_ston(__p_class_syms, buf, &success);
-	if (success)
-		goto done;
-
-	if (strncasecmp(buf, "CLASS", 5) != 0 ||
-	    !isdigit((unsigned char)buf[5]))
-		goto done;
-	errno = 0;
-	result = strtoul(buf + 5, &endptr, 10);
-	if (errno == 0 && *endptr == '\0' && result <= 0xffffU)
-		success = 1;
- done:
-	if (successp)
-		*successp = success;
-	return (result);
-}
-
-u_int16_t
-res_nametotype(const char *buf, int *successp) {
-	unsigned long result;
-	char *endptr;
-	int success;
-
-	result = sym_ston(__p_type_syms, buf, &success);
-	if (success)
-		goto done;
-
-	if (strncasecmp(buf, "type", 4) != 0 ||
-	    !isdigit((unsigned char)buf[4]))
-		goto done;
-	errno = 0;
-	result = strtoul(buf + 4, &endptr, 10);
-	if (errno == 0 && *endptr == '\0' && result <= 0xffffU)
-		success = 1;
- done:
-	if (successp)
-		*successp = success;
-	return (result);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/resolv/res_debug.h b/contrib/bind9/lib/bind/resolv/res_debug.h
deleted file mode 100644
index c28171d..0000000
--- a/contrib/bind9/lib/bind/resolv/res_debug.h
+++ /dev/null
@@ -1,35 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1999 by 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.
- */
-
-#ifndef _RES_DEBUG_H_
-#define _RES_DEBUG_H_
-
-#ifndef DEBUG
-#   define Dprint(cond, args) /*empty*/
-#   define DprintQ(cond, args, query, size) /*empty*/
-#   define Aerror(statp, file, string, error, address) /*empty*/
-#   define Perror(statp, file, string, error) /*empty*/
-#else
-#   define Dprint(cond, args) if (cond) {fprintf args;} else {}
-#   define DprintQ(cond, args, query, size) if (cond) {\
-			fprintf args;\
-			res_pquery(statp, query, size, stdout);\
-		} else {}
-#endif
-
-#endif /* _RES_DEBUG_H_ */ 
-/*! \file */
diff --git a/contrib/bind9/lib/bind/resolv/res_findzonecut.c b/contrib/bind9/lib/bind/resolv/res_findzonecut.c
deleted file mode 100644
index 207d66c..0000000
--- a/contrib/bind9/lib/bind/resolv/res_findzonecut.c
+++ /dev/null
@@ -1,722 +0,0 @@
-#if !defined(lint) && !defined(SABER)
-static const char rcsid[] = "$Id: res_findzonecut.c,v 1.7.18.3 2005/10/11 00:25:11 marka Exp $";
-#endif /* not lint */
-
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1999 by 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.
- */
-
-/* Import. */
-
-#include "port_before.h"
-
-#include <sys/param.h>
-#include <sys/socket.h>
-#include <sys/time.h>
-
-#include <netinet/in.h>
-#include <arpa/inet.h>
-#include <arpa/nameser.h>
-
-#include <errno.h>
-#include <limits.h>
-#include <netdb.h>
-#include <stdarg.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-
-#include <isc/list.h>
-
-#include "port_after.h"
-
-#include <resolv.h>
-
-/* Data structures. */
-
-typedef struct rr_a {
-	LINK(struct rr_a)	link;
-	union res_sockaddr_union addr;
-} rr_a;
-typedef LIST(rr_a) rrset_a;
-
-typedef struct rr_ns {
-	LINK(struct rr_ns)	link;
-	const char *		name;
-	unsigned int		flags;
-	rrset_a			addrs;
-} rr_ns;
-typedef LIST(rr_ns) rrset_ns;
-
-#define	RR_NS_HAVE_V4		0x01
-#define	RR_NS_HAVE_V6		0x02
-
-/* Forward. */
-
-static int	satisfy(res_state, const char *, rrset_ns *,
-			union res_sockaddr_union *, int);
-static int	add_addrs(res_state, rr_ns *,
-			  union res_sockaddr_union *, int);
-static int	get_soa(res_state, const char *, ns_class, int,
-			char *, size_t, char *, size_t,
-			rrset_ns *);
-static int	get_ns(res_state, const char *, ns_class, int, rrset_ns *);
-static int	get_glue(res_state, ns_class, int, rrset_ns *);
-static int	save_ns(res_state, ns_msg *, ns_sect,
-			const char *, ns_class, int, rrset_ns *);
-static int	save_a(res_state, ns_msg *, ns_sect,
-		       const char *, ns_class, int, rr_ns *);
-static void	free_nsrrset(rrset_ns *);
-static void	free_nsrr(rrset_ns *, rr_ns *);
-static rr_ns *	find_ns(rrset_ns *, const char *);
-static int	do_query(res_state, const char *, ns_class, ns_type,
-			 u_char *, ns_msg *);
-static void	res_dprintf(const char *, ...) ISC_FORMAT_PRINTF(1, 2);
-
-/* Macros. */
-
-#define DPRINTF(x) do {\
-		int save_errno = errno; \
-		if ((statp->options & RES_DEBUG) != 0U) res_dprintf x; \
-		errno = save_errno; \
-	} while (0)
-
-/* Public. */
-
-/*%
- *	find enclosing zone for a <dname,class>, and some server addresses
- *
- * parameters:
- *\li	res - resolver context to work within (is modified)
- *\li	dname - domain name whose enclosing zone is desired
- *\li	class - class of dname (and its enclosing zone)
- *\li	zname - found zone name
- *\li	zsize - allocated size of zname
- *\li	addrs - found server addresses
- *\li	naddrs - max number of addrs
- *
- * return values:
- *\li	< 0 - an error occurred (check errno)
- *\li	= 0 - zname is now valid, but addrs[] wasn't changed
- *\li	> 0 - zname is now valid, and return value is number of addrs[] found
- *
- * notes:
- *\li	this function calls res_nsend() which means it depends on correctly
- *	functioning recursive nameservers (usually defined in /etc/resolv.conf
- *	or its local equivilent).
- *
- *\li	we start by asking for an SOA<dname,class>.  if we get one as an
- *	answer, that just means <dname,class> is a zone top, which is fine.
- *	more than likely we'll be told to go pound sand, in the form of a
- *	negative answer.
- *
- *\li	note that we are not prepared to deal with referrals since that would
- *	only come from authority servers and our correctly functioning local
- *	recursive server would have followed the referral and got us something
- *	more definite.
- *
- *\li	if the authority section contains an SOA, this SOA should also be the
- *	closest enclosing zone, since any intermediary zone cuts would've been
- *	returned as referrals and dealt with by our correctly functioning local
- *	recursive name server.  but an SOA in the authority section should NOT
- *	match our dname (since that would have been returned in the answer
- *	section).  an authority section SOA has to be "above" our dname.
- *
- *\li	however, since authority section SOA's were once optional, it's
- *	possible that we'll have to go hunting for the enclosing SOA by
- *	ripping labels off the front of our dname -- this is known as "doing
- *	it the hard way."
- *
- *\li	ultimately we want some server addresses, which are ideally the ones
- *	pertaining to the SOA.MNAME, but only if there is a matching NS RR.
- *	so the second phase (after we find an SOA) is to go looking for the
- *	NS RRset for that SOA's zone.
- *
- *\li	no answer section processed by this code is allowed to contain CNAME
- *	or DNAME RR's.  for the SOA query this means we strip a label and
- *	keep going.  for the NS and A queries this means we just give up.
- */
-
-int
-res_findzonecut(res_state statp, const char *dname, ns_class class, int opts,
-		char *zname, size_t zsize, struct in_addr *addrs, int naddrs)
-{
-	int result, i;
-	union res_sockaddr_union *u;
-
-	
-	opts |= RES_IPV4ONLY;
-	opts &= ~RES_IPV6ONLY;
-
-	u = calloc(naddrs, sizeof(*u));
-	if (u == NULL)
-		return(-1);
-
-	result = res_findzonecut2(statp, dname, class, opts, zname, zsize,
-				  u, naddrs);
-
-	for (i = 0; i < result; i++) {
-		addrs[i] = u[i].sin.sin_addr;
-	}
-	free(u);
-	return (result);
-}
-
-int
-res_findzonecut2(res_state statp, const char *dname, ns_class class, int opts,
-		 char *zname, size_t zsize, union res_sockaddr_union *addrs,
-		 int naddrs)
-{
-	char mname[NS_MAXDNAME];
-	u_long save_pfcode;
-	rrset_ns nsrrs;
-	int n;
-
-	DPRINTF(("START dname='%s' class=%s, zsize=%ld, naddrs=%d",
-		 dname, p_class(class), (long)zsize, naddrs));
-	save_pfcode = statp->pfcode;
-	statp->pfcode |= RES_PRF_HEAD2 | RES_PRF_HEAD1 | RES_PRF_HEADX |
-			 RES_PRF_QUES | RES_PRF_ANS |
-			 RES_PRF_AUTH | RES_PRF_ADD;
-	INIT_LIST(nsrrs);
-
-	DPRINTF(("get the soa, and see if it has enough glue"));
-	if ((n = get_soa(statp, dname, class, opts, zname, zsize,
-			 mname, sizeof mname, &nsrrs)) < 0 ||
-	    ((opts & RES_EXHAUSTIVE) == 0 &&
-	     (n = satisfy(statp, mname, &nsrrs, addrs, naddrs)) > 0))
-		goto done;
-
-	DPRINTF(("get the ns rrset and see if it has enough glue"));
-	if ((n = get_ns(statp, zname, class, opts, &nsrrs)) < 0 ||
-	    ((opts & RES_EXHAUSTIVE) == 0 &&
-	     (n = satisfy(statp, mname, &nsrrs, addrs, naddrs)) > 0))
-		goto done;
-
-	DPRINTF(("get the missing glue and see if it's finally enough"));
-	if ((n = get_glue(statp, class, opts, &nsrrs)) >= 0)
-		n = satisfy(statp, mname, &nsrrs, addrs, naddrs);
-
- done:
-	DPRINTF(("FINISH n=%d (%s)", n, (n < 0) ? strerror(errno) : "OK"));
-	free_nsrrset(&nsrrs);
-	statp->pfcode = save_pfcode;
-	return (n);
-}
-
-/* Private. */
-
-static int
-satisfy(res_state statp, const char *mname, rrset_ns *nsrrsp,
-	union res_sockaddr_union *addrs, int naddrs)
-{
-	rr_ns *nsrr;
-	int n, x;
-
-	n = 0;
-	nsrr = find_ns(nsrrsp, mname);
-	if (nsrr != NULL) {
-		x = add_addrs(statp, nsrr, addrs, naddrs);
-		addrs += x;
-		naddrs -= x;
-		n += x;
-	}
-	for (nsrr = HEAD(*nsrrsp);
-	     nsrr != NULL && naddrs > 0;
-	     nsrr = NEXT(nsrr, link))
-		if (ns_samename(nsrr->name, mname) != 1) {
-			x = add_addrs(statp, nsrr, addrs, naddrs);
-			addrs += x;
-			naddrs -= x;
-			n += x;
-		}
-	DPRINTF(("satisfy(%s): %d", mname, n));
-	return (n);
-}
-
-static int
-add_addrs(res_state statp, rr_ns *nsrr,
-	  union res_sockaddr_union *addrs, int naddrs)
-{
-	rr_a *arr;
-	int n = 0;
-
-	for (arr = HEAD(nsrr->addrs); arr != NULL; arr = NEXT(arr, link)) {
-		if (naddrs <= 0)
-			return (0);
-		*addrs++ = arr->addr;
-		naddrs--;
-		n++;
-	}
-	DPRINTF(("add_addrs: %d", n));
-	return (n);
-}
-
-static int
-get_soa(res_state statp, const char *dname, ns_class class, int opts,
-	char *zname, size_t zsize, char *mname, size_t msize,
-	rrset_ns *nsrrsp)
-{
-	char tname[NS_MAXDNAME];
-	u_char *resp = NULL;
-	int n, i, ancount, nscount;
-	ns_sect sect;
-	ns_msg msg;
-	u_int rcode;
-
-	/*
-	 * Find closest enclosing SOA, even if it's for the root zone.
-	 */
-
-	/* First canonicalize dname (exactly one unescaped trailing "."). */
-	if (ns_makecanon(dname, tname, sizeof tname) < 0)
-		goto cleanup;
-	dname = tname;
-
-	resp = malloc(NS_MAXMSG);
-	if (resp == NULL)
-		goto cleanup;
-
-	/* Now grovel the subdomains, hunting for an SOA answer or auth. */
-	for (;;) {
-		/* Leading or inter-label '.' are skipped here. */
-		while (*dname == '.')
-			dname++;
-
-		/* Is there an SOA? */
-		n = do_query(statp, dname, class, ns_t_soa, resp, &msg);
-		if (n < 0) {
-			DPRINTF(("get_soa: do_query('%s', %s) failed (%d)",
-				 dname, p_class(class), n));
-			goto cleanup;
-		}
-		if (n > 0) {
-			DPRINTF(("get_soa: CNAME or DNAME found"));
-			sect = ns_s_max, n = 0;
-		} else {
-			rcode = ns_msg_getflag(msg, ns_f_rcode);
-			ancount = ns_msg_count(msg, ns_s_an);
-			nscount = ns_msg_count(msg, ns_s_ns);
-			if (ancount > 0 && rcode == ns_r_noerror)
-				sect = ns_s_an, n = ancount;
-			else if (nscount > 0)
-				sect = ns_s_ns, n = nscount;
-			else
-				sect = ns_s_max, n = 0;
-		}
-		for (i = 0; i < n; i++) {
-			const char *t;
-			const u_char *rdata;
-			ns_rr rr;
-
-			if (ns_parserr(&msg, sect, i, &rr) < 0) {
-				DPRINTF(("get_soa: ns_parserr(%s, %d) failed",
-					 p_section(sect, ns_o_query), i));
-				goto cleanup;
-			}
-			if (ns_rr_type(rr) == ns_t_cname ||
-			    ns_rr_type(rr) == ns_t_dname)
-				break;
-			if (ns_rr_type(rr) != ns_t_soa ||
-			    ns_rr_class(rr) != class)
-				continue;
-			t = ns_rr_name(rr);
-			switch (sect) {
-			case ns_s_an:
-				if (ns_samedomain(dname, t) == 0) {
-					DPRINTF(
-				    ("get_soa: ns_samedomain('%s', '%s') == 0",
-						dname, t)
-						);
-					errno = EPROTOTYPE;
-					goto cleanup;
-				}
-				break;
-			case ns_s_ns:
-				if (ns_samename(dname, t) == 1 ||
-				    ns_samedomain(dname, t) == 0) {
-					DPRINTF(
-		       ("get_soa: ns_samename() || !ns_samedomain('%s', '%s')",
-						dname, t)
-						);
-					errno = EPROTOTYPE;
-					goto cleanup;
-				}
-				break;
-			default:
-				abort();
-			}
-			if (strlen(t) + 1 > zsize) {
-				DPRINTF(("get_soa: zname(%lu) too small (%lu)",
-					 (unsigned long)zsize,
-					 (unsigned long)strlen(t) + 1));
-				errno = EMSGSIZE;
-				goto cleanup;
-			}
-			strcpy(zname, t);
-			rdata = ns_rr_rdata(rr);
-			if (ns_name_uncompress(resp, ns_msg_end(msg), rdata,
-					       mname, msize) < 0) {
-				DPRINTF(("get_soa: ns_name_uncompress failed")
-					);
-				goto cleanup;
-			}
-			if (save_ns(statp, &msg, ns_s_ns,
-				    zname, class, opts, nsrrsp) < 0) {
-				DPRINTF(("get_soa: save_ns failed"));
-				goto cleanup;
-			}
-			free(resp);
-			return (0);
-		}
-
-		/* If we're out of labels, then not even "." has an SOA! */
-		if (*dname == '\0')
-			break;
-
-		/* Find label-terminating "."; top of loop will skip it. */
-		while (*dname != '.') {
-			if (*dname == '\\')
-				if (*++dname == '\0') {
-					errno = EMSGSIZE;
-					goto cleanup;
-				}
-			dname++;
-		}
-	}
-	DPRINTF(("get_soa: out of labels"));
-	errno = EDESTADDRREQ;
- cleanup:
-	if (resp != NULL)
-		free(resp);
-	return (-1);
-}
-
-static int
-get_ns(res_state statp, const char *zname, ns_class class, int opts,
-      rrset_ns *nsrrsp)
-{
-	u_char *resp;
-	ns_msg msg;
-	int n;
-
-	resp = malloc(NS_MAXMSG);
-	if (resp == NULL)
-		return (-1);
-
-	/* Go and get the NS RRs for this zone. */
-	n = do_query(statp, zname, class, ns_t_ns, resp, &msg);
-	if (n != 0) {
-		DPRINTF(("get_ns: do_query('%s', %s) failed (%d)",
-			 zname, p_class(class), n));
-		free(resp);
-		return (-1);
-	}
-
-	/* Remember the NS RRs and associated A RRs that came back. */
-	if (save_ns(statp, &msg, ns_s_an, zname, class, opts, nsrrsp) < 0) {
-		DPRINTF(("get_ns save_ns('%s', %s) failed",
-			 zname, p_class(class)));
-		free(resp);
-		return (-1);
-	}
-
-	free(resp);
-	return (0);
-}
-
-static int
-get_glue(res_state statp, ns_class class, int opts, rrset_ns *nsrrsp) {
-	rr_ns *nsrr, *nsrr_n;
-	u_char *resp;
-
-	resp = malloc(NS_MAXMSG);
-	if (resp == NULL)
-		return(-1);
-
-	/* Go and get the A RRs for each empty NS RR on our list. */
-	for (nsrr = HEAD(*nsrrsp); nsrr != NULL; nsrr = nsrr_n) {
-		ns_msg msg;
-		int n;
-
-		nsrr_n = NEXT(nsrr, link);
-
-		if ((nsrr->flags & RR_NS_HAVE_V4) == 0) {
-			n = do_query(statp, nsrr->name, class, ns_t_a,
-				     resp, &msg);
-			if (n < 0) {
-				DPRINTF(
-				       ("get_glue: do_query('%s', %s') failed",
-					nsrr->name, p_class(class)));
-				goto cleanup;
-			}
-			if (n > 0) {
-				DPRINTF((
-			"get_glue: do_query('%s', %s') CNAME or DNAME found",
-					 nsrr->name, p_class(class)));
-			}
-			if (save_a(statp, &msg, ns_s_an, nsrr->name, class,
-				   opts, nsrr) < 0) {
-				DPRINTF(("get_glue: save_r('%s', %s) failed",
-					 nsrr->name, p_class(class)));
-				goto cleanup;
-			}
-		}
-
-		if ((nsrr->flags & RR_NS_HAVE_V6) == 0) {
-			n = do_query(statp, nsrr->name, class, ns_t_aaaa,
-				     resp, &msg);
-			if (n < 0) {
-				DPRINTF(
-				       ("get_glue: do_query('%s', %s') failed",
-					nsrr->name, p_class(class)));
-				goto cleanup;
-			}
-			if (n > 0) {
-				DPRINTF((
-			"get_glue: do_query('%s', %s') CNAME or DNAME found",
-					 nsrr->name, p_class(class)));
-			}
-			if (save_a(statp, &msg, ns_s_an, nsrr->name, class,
-				   opts, nsrr) < 0) {
-				DPRINTF(("get_glue: save_r('%s', %s) failed",
-					 nsrr->name, p_class(class)));
-				goto cleanup;
-			}
-		}
-
-		/* If it's still empty, it's just chaff. */
-		if (EMPTY(nsrr->addrs)) {
-			DPRINTF(("get_glue: removing empty '%s' NS",
-				 nsrr->name));
-			free_nsrr(nsrrsp, nsrr);
-		}
-	}
-	free(resp);
-	return (0);
-
- cleanup:
-	free(resp);
-	return (-1);
-}
-
-static int
-save_ns(res_state statp, ns_msg *msg, ns_sect sect,
-	const char *owner, ns_class class, int opts,
-	rrset_ns *nsrrsp)
-{
-	int i;
-
-	for (i = 0; i < ns_msg_count(*msg, sect); i++) {
-		char tname[MAXDNAME];
-		const u_char *rdata;
-		rr_ns *nsrr;
-		ns_rr rr;
-
-		if (ns_parserr(msg, sect, i, &rr) < 0) {
-			DPRINTF(("save_ns: ns_parserr(%s, %d) failed",
-				 p_section(sect, ns_o_query), i));
-			return (-1);
-		}
-		if (ns_rr_type(rr) != ns_t_ns ||
-		    ns_rr_class(rr) != class ||
-		    ns_samename(ns_rr_name(rr), owner) != 1)
-			continue;
-		nsrr = find_ns(nsrrsp, ns_rr_name(rr));
-		if (nsrr == NULL) {
-			nsrr = malloc(sizeof *nsrr);
-			if (nsrr == NULL) {
-				DPRINTF(("save_ns: malloc failed"));
-				return (-1);
-			}
-			rdata = ns_rr_rdata(rr);
-			if (ns_name_uncompress(ns_msg_base(*msg),
-					       ns_msg_end(*msg), rdata,
-					       tname, sizeof tname) < 0) {
-				DPRINTF(("save_ns: ns_name_uncompress failed")
-					);
-				free(nsrr);
-				return (-1);
-			}
-			nsrr->name = strdup(tname);
-			if (nsrr->name == NULL) {
-				DPRINTF(("save_ns: strdup failed"));
-				free(nsrr);
-				return (-1);
-			}
-			INIT_LINK(nsrr, link);
-			INIT_LIST(nsrr->addrs);
-			nsrr->flags = 0;
-			APPEND(*nsrrsp, nsrr, link);
-		}
-		if (save_a(statp, msg, ns_s_ar,
-			   nsrr->name, class, opts, nsrr) < 0) {
-			DPRINTF(("save_ns: save_r('%s', %s) failed",
-				 nsrr->name, p_class(class)));
-			return (-1);
-		}
-	}
-	return (0);
-}
-
-static int
-save_a(res_state statp, ns_msg *msg, ns_sect sect,
-       const char *owner, ns_class class, int opts,
-       rr_ns *nsrr)
-{
-	int i;
-
-	for (i = 0; i < ns_msg_count(*msg, sect); i++) {
-		ns_rr rr;
-		rr_a *arr;
-
-		if (ns_parserr(msg, sect, i, &rr) < 0) {
-			DPRINTF(("save_a: ns_parserr(%s, %d) failed",
-				 p_section(sect, ns_o_query), i));
-			return (-1);
-		}
-		if ((ns_rr_type(rr) != ns_t_a &&
-		     ns_rr_type(rr) != ns_t_aaaa) ||
-		    ns_rr_class(rr) != class ||
-		    ns_samename(ns_rr_name(rr), owner) != 1 ||
-		    ns_rr_rdlen(rr) != NS_INADDRSZ)
-			continue;
-		if ((opts & RES_IPV6ONLY) != 0 && ns_rr_type(rr) != ns_t_aaaa)
-			continue;
-		if ((opts & RES_IPV4ONLY) != 0 && ns_rr_type(rr) != ns_t_a)
-			continue;
-		arr = malloc(sizeof *arr);
-		if (arr == NULL) {
-			DPRINTF(("save_a: malloc failed"));
-			return (-1);
-		}
-		INIT_LINK(arr, link);
-		memset(&arr->addr, 0, sizeof(arr->addr));
-		switch (ns_rr_type(rr)) {
-		case ns_t_a:
-			arr->addr.sin.sin_family = AF_INET;
-#ifdef HAVE_SA_LEN
-			arr->addr.sin.sin_len = sizeof(arr->addr.sin);
-#endif
-			memcpy(&arr->addr.sin.sin_addr, ns_rr_rdata(rr),
-			       NS_INADDRSZ);
-			arr->addr.sin.sin_port = htons(NAMESERVER_PORT);
-			nsrr->flags |= RR_NS_HAVE_V4;
-			break;
-		case ns_t_aaaa:
-			arr->addr.sin6.sin6_family = AF_INET6;
-#ifdef HAVE_SA_LEN
-			arr->addr.sin6.sin6_len = sizeof(arr->addr.sin6);
-#endif
-			memcpy(&arr->addr.sin6.sin6_addr, ns_rr_rdata(rr), 16);
-			arr->addr.sin.sin_port = htons(NAMESERVER_PORT);
-			nsrr->flags |= RR_NS_HAVE_V6;
-			break;
-		default:
-			abort();
-		}
-		APPEND(nsrr->addrs, arr, link);
-	}
-	return (0);
-}
-
-static void
-free_nsrrset(rrset_ns *nsrrsp) {
-	rr_ns *nsrr;
-
-	while ((nsrr = HEAD(*nsrrsp)) != NULL)
-		free_nsrr(nsrrsp, nsrr);
-}
-
-static void
-free_nsrr(rrset_ns *nsrrsp, rr_ns *nsrr) {
-	rr_a *arr;
-	char *tmp;
-
-	while ((arr = HEAD(nsrr->addrs)) != NULL) {
-		UNLINK(nsrr->addrs, arr, link);
-		free(arr);
-	}
-	DE_CONST(nsrr->name, tmp);
-	free(tmp);
-	UNLINK(*nsrrsp, nsrr, link);
-	free(nsrr);
-}
-
-static rr_ns *
-find_ns(rrset_ns *nsrrsp, const char *dname) {
-	rr_ns *nsrr;
-
-	for (nsrr = HEAD(*nsrrsp); nsrr != NULL; nsrr = NEXT(nsrr, link))
-		if (ns_samename(nsrr->name, dname) == 1)
-			return (nsrr);
-	return (NULL);
-}
-
-static int
-do_query(res_state statp, const char *dname, ns_class class, ns_type qtype,
-	 u_char *resp, ns_msg *msg)
-{
-	u_char req[NS_PACKETSZ];
-	int i, n;
-
-	n = res_nmkquery(statp, ns_o_query, dname, class, qtype,
-			 NULL, 0, NULL, req, NS_PACKETSZ);
-	if (n < 0) {
-		DPRINTF(("do_query: res_nmkquery failed"));
-		return (-1);
-	}
-	n = res_nsend(statp, req, n, resp, NS_MAXMSG);
-	if (n < 0) {
-		DPRINTF(("do_query: res_nsend failed"));
-		return (-1);
-	}
-	if (n == 0) {
-		DPRINTF(("do_query: res_nsend returned 0"));
-		errno = EMSGSIZE;
-		return (-1);
-	}
-	if (ns_initparse(resp, n, msg) < 0) {
-		DPRINTF(("do_query: ns_initparse failed"));
-		return (-1);
-	}
-	n = 0;
-	for (i = 0; i < ns_msg_count(*msg, ns_s_an); i++) {
-		ns_rr rr;
-
-		if (ns_parserr(msg, ns_s_an, i, &rr) < 0) {
-			DPRINTF(("do_query: ns_parserr failed"));
-			return (-1);
-		}
-		n += (ns_rr_class(rr) == class &&
-		      (ns_rr_type(rr) == ns_t_cname ||
-		       ns_rr_type(rr) == ns_t_dname));
-	}
-	return (n);
-}
-
-static void
-res_dprintf(const char *fmt, ...) {
-	va_list ap;
-
-	va_start(ap, fmt);
-	fputs(";; res_findzonecut: ", stderr);
-	vfprintf(stderr, fmt, ap);
-	fputc('\n', stderr);
-	va_end(ap);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/resolv/res_init.c b/contrib/bind9/lib/bind/resolv/res_init.c
deleted file mode 100644
index f580b9c..0000000
--- a/contrib/bind9/lib/bind/resolv/res_init.c
+++ /dev/null
@@ -1,801 +0,0 @@
-/*
- * Copyright (c) 1985, 1989, 1993
- *    The Regents of the University of California.  All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- * 	This product includes software developed by the University of
- * 	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-/*
- * Portions Copyright (c) 1993 by Digital Equipment Corporation.
- * 
- * 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, and that
- * the name of Digital Equipment Corporation not be used in advertising or
- * publicity pertaining to distribution of the document or software without
- * specific, written prior permission.
- * 
- * THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
- * WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
- * OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
- * CORPORATION 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.
- */
-
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-#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.16.18.7 2007/07/09 01:52:58 marka Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/param.h>
-#include <sys/socket.h>
-#include <sys/time.h>
-
-#include <netinet/in.h>
-#include <arpa/inet.h>
-#include <arpa/nameser.h>
-
-#include <ctype.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <unistd.h>
-#include <netdb.h>
-
-#include "port_after.h"
-
-/* ensure that sockaddr_in6 and IN6ADDR_ANY_INIT are declared / defined */
-#include <resolv.h>
-
-#include "res_private.h"
-
-/*% Options.  Should all be left alone. */
-#define RESOLVSORT
-#define DEBUG
-
-#ifdef SOLARIS2
-#include <sys/systeminfo.h>
-#endif
-
-static void res_setoptions __P((res_state, const char *, const char *));
-
-#ifdef RESOLVSORT
-static const char sort_mask[] = "/&";
-#define ISSORTMASK(ch) (strchr(sort_mask, ch) != NULL)
-static u_int32_t net_mask __P((struct in_addr));
-#endif
-
-#if !defined(isascii)	/*%< XXX - could be a function */
-# define isascii(c) (!(c & 0200))
-#endif
-
-/*
- * Resolver state default settings.
- */
-
-/*%
- * Set up default settings.  If the configuration file exist, the values
- * there will have precedence.  Otherwise, the server address is set to
- * INADDR_ANY and the default domain name comes from the gethostname().
- *
- * An interrim version of this code (BIND 4.9, pre-4.4BSD) used 127.0.0.1
- * rather than INADDR_ANY ("0.0.0.0") as the default name server address
- * since it was noted that INADDR_ANY actually meant ``the first interface
- * you "ifconfig"'d at boot time'' and if this was a SLIP or PPP interface,
- * it had to be "up" in order for you to reach your own name server.  It
- * was later decided that since the recommended practice is to always 
- * install local static routes through 127.0.0.1 for all your network
- * interfaces, that we could solve this problem without a code change.
- *
- * The configuration file should always be used, since it is the only way
- * to specify a default domain.  If you are running a server on your local
- * machine, you should say "nameserver 0.0.0.0" or "nameserver 127.0.0.1"
- * in the configuration file.
- *
- * Return 0 if completes successfully, -1 on error
- */
-int
-res_ninit(res_state statp) {
-	extern int __res_vinit(res_state, int);
-
-	return (__res_vinit(statp, 0));
-}
-
-/*% This function has to be reachable by res_data.c but not publically. */
-int
-__res_vinit(res_state statp, int preinit) {
-	register FILE *fp;
-	register char *cp, **pp;
-	register int n;
-	char buf[BUFSIZ];
-	int nserv = 0;    /*%< number of nameserver records read from file */
-	int haveenv = 0;
-	int havesearch = 0;
-#ifdef RESOLVSORT
-	int nsort = 0;
-	char *net;
-#endif
-	int dots;
-	union res_sockaddr_union u[2];
-	int maxns = MAXNS;
-
-	RES_SET_H_ERRNO(statp, 0);
-	if (statp->_u._ext.ext != NULL)
-		res_ndestroy(statp);
-
-	if (!preinit) {
-		statp->retrans = RES_TIMEOUT;
-		statp->retry = RES_DFLRETRY;
-		statp->options = RES_DEFAULT;
-		statp->id = res_randomid();
-	}
-
-	memset(u, 0, sizeof(u));
-#ifdef USELOOPBACK
-	u[nserv].sin.sin_addr = inet_makeaddr(IN_LOOPBACKNET, 1);
-#else
-	u[nserv].sin.sin_addr.s_addr = INADDR_ANY;
-#endif
-	u[nserv].sin.sin_family = AF_INET;
-	u[nserv].sin.sin_port = htons(NAMESERVER_PORT);
-#ifdef HAVE_SA_LEN
-	u[nserv].sin.sin_len = sizeof(struct sockaddr_in);
-#endif
-	nserv++;
-#ifdef HAS_INET6_STRUCTS
-#ifdef USELOOPBACK
-	u[nserv].sin6.sin6_addr = in6addr_loopback;
-#else
-	u[nserv].sin6.sin6_addr = in6addr_any;
-#endif
-	u[nserv].sin6.sin6_family = AF_INET6;
-	u[nserv].sin6.sin6_port = htons(NAMESERVER_PORT);
-#ifdef HAVE_SA_LEN
-	u[nserv].sin6.sin6_len = sizeof(struct sockaddr_in6);
-#endif
-	nserv++;
-#endif
-	statp->nscount = 0;
-	statp->ndots = 1;
-	statp->pfcode = 0;
-	statp->_vcsock = -1;
-	statp->_flags = 0;
-	statp->qhook = NULL;
-	statp->rhook = NULL;
-	statp->_u._ext.nscount = 0;
-	statp->_u._ext.ext = malloc(sizeof(*statp->_u._ext.ext));
-	if (statp->_u._ext.ext != NULL) {
-	        memset(statp->_u._ext.ext, 0, sizeof(*statp->_u._ext.ext));
-		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 {
-		/*
-		 * Historically res_init() rarely, if at all, failed.
-		 * Examples and applications exist which do not check
-		 * our return code.  Furthermore several applications
-		 * simply call us to get the systems domainname.  So
-		 * rather then immediately fail here we store the
-		 * failure, which is returned later, in h_errno.  And
-		 * prevent the collection of 'nameserver' information
-		 * by setting maxns to 0.  Thus applications that fail
-		 * to check our return code wont be able to make
-		 * queries anyhow.
-		 */
-		RES_SET_H_ERRNO(statp, NETDB_INTERNAL);
-		maxns = 0;
-	}
-#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, '.');
-			cp = (cp == NULL) ? buf : (cp + 1);
-			strncpy(statp->defdname, cp,
-				sizeof(statp->defdname) - 1);
-			statp->defdname[sizeof(statp->defdname) - 1] = '\0';
-		}
-	}
-#endif	/* SOLARIS2 */
-
-	/* Allow user to override the local domain definition */
-	if ((cp = getenv("LOCALDOMAIN")) != NULL) {
-		(void)strncpy(statp->defdname, cp, sizeof(statp->defdname) - 1);
-		statp->defdname[sizeof(statp->defdname) - 1] = '\0';
-		haveenv++;
-
-		/*
-		 * Set search list to be blank-separated strings
-		 * from rest of env value.  Permits users of LOCALDOMAIN
-		 * to still have a search list, and anyone to set the
-		 * one that they want to use as an individual (even more
-		 * important now that the rfc1535 stuff restricts searches)
-		 */
-		cp = statp->defdname;
-		pp = statp->dnsrch;
-		*pp++ = cp;
-		for (n = 0; *cp && pp < statp->dnsrch + MAXDNSRCH; cp++) {
-			if (*cp == '\n')	/*%< silly backwards compat */
-				break;
-			else if (*cp == ' ' || *cp == '\t') {
-				*cp = 0;
-				n = 1;
-			} else if (n) {
-				*pp++ = cp;
-				n = 0;
-				havesearch = 1;
-			}
-		}
-		/* null terminate last domain if there are excess */
-		while (*cp != '\0' && *cp != ' ' && *cp != '\t' && *cp != '\n')
-			cp++;
-		*cp = '\0';
-		*pp++ = 0;
-	}
-
-#define	MATCH(line, name) \
-	(!strncmp(line, name, sizeof(name) - 1) && \
-	(line[sizeof(name) - 1] == ' ' || \
-	 line[sizeof(name) - 1] == '\t'))
-
-	nserv = 0;
-	if ((fp = fopen(_PATH_RESCONF, "r")) != NULL) {
-	    /* read the config file */
-	    while (fgets(buf, sizeof(buf), fp) != NULL) {
-		/* skip comments */
-		if (*buf == ';' || *buf == '#')
-			continue;
-		/* read default domain name */
-		if (MATCH(buf, "domain")) {
-		    if (haveenv)	/*%< skip if have from environ */
-			    continue;
-		    cp = buf + sizeof("domain") - 1;
-		    while (*cp == ' ' || *cp == '\t')
-			    cp++;
-		    if ((*cp == '\0') || (*cp == '\n'))
-			    continue;
-		    strncpy(statp->defdname, cp, sizeof(statp->defdname) - 1);
-		    statp->defdname[sizeof(statp->defdname) - 1] = '\0';
-		    if ((cp = strpbrk(statp->defdname, " \t\n")) != NULL)
-			    *cp = '\0';
-		    havesearch = 0;
-		    continue;
-		}
-		/* set search list */
-		if (MATCH(buf, "search")) {
-		    if (haveenv)	/*%< skip if have from environ */
-			    continue;
-		    cp = buf + sizeof("search") - 1;
-		    while (*cp == ' ' || *cp == '\t')
-			    cp++;
-		    if ((*cp == '\0') || (*cp == '\n'))
-			    continue;
-		    strncpy(statp->defdname, cp, sizeof(statp->defdname) - 1);
-		    statp->defdname[sizeof(statp->defdname) - 1] = '\0';
-		    if ((cp = strchr(statp->defdname, '\n')) != NULL)
-			    *cp = '\0';
-		    /*
-		     * Set search list to be blank-separated strings
-		     * on rest of line.
-		     */
-		    cp = statp->defdname;
-		    pp = statp->dnsrch;
-		    *pp++ = cp;
-		    for (n = 0; *cp && pp < statp->dnsrch + MAXDNSRCH; cp++) {
-			    if (*cp == ' ' || *cp == '\t') {
-				    *cp = 0;
-				    n = 1;
-			    } else if (n) {
-				    *pp++ = cp;
-				    n = 0;
-			    }
-		    }
-		    /* null terminate last domain if there are excess */
-		    while (*cp != '\0' && *cp != ' ' && *cp != '\t')
-			    cp++;
-		    *cp = '\0';
-		    *pp++ = 0;
-		    havesearch = 1;
-		    continue;
-		}
-		/* read nameservers to query */
-		if (MATCH(buf, "nameserver") && nserv < maxns) {
-		    struct addrinfo hints, *ai;
-		    char sbuf[NI_MAXSERV];
-		    const size_t minsiz =
-		        sizeof(statp->_u._ext.ext->nsaddrs[0]);
-
-		    cp = buf + sizeof("nameserver") - 1;
-		    while (*cp == ' ' || *cp == '\t')
-			cp++;
-		    cp[strcspn(cp, ";# \t\n")] = '\0';
-		    if ((*cp != '\0') && (*cp != '\n')) {
-			memset(&hints, 0, sizeof(hints));
-			hints.ai_family = PF_UNSPEC;
-			hints.ai_socktype = SOCK_DGRAM;	/*dummy*/
-			hints.ai_flags = AI_NUMERICHOST;
-			sprintf(sbuf, "%u", NAMESERVER_PORT);
-			if (getaddrinfo(cp, sbuf, &hints, &ai) == 0 &&
-			    ai->ai_addrlen <= minsiz) {
-			    if (statp->_u._ext.ext != NULL) {
-				memcpy(&statp->_u._ext.ext->nsaddrs[nserv],
-				    ai->ai_addr, ai->ai_addrlen);
-			    }
-			    if (ai->ai_addrlen <=
-			        sizeof(statp->nsaddr_list[nserv])) {
-				memcpy(&statp->nsaddr_list[nserv],
-				    ai->ai_addr, ai->ai_addrlen);
-			    } else
-				statp->nsaddr_list[nserv].sin_family = 0;
-			    freeaddrinfo(ai);
-			    nserv++;
-			}
-		    }
-		    continue;
-		}
-#ifdef RESOLVSORT
-		if (MATCH(buf, "sortlist")) {
-		    struct in_addr a;
-
-		    cp = buf + sizeof("sortlist") - 1;
-		    while (nsort < MAXRESOLVSORT) {
-			while (*cp == ' ' || *cp == '\t')
-			    cp++;
-			if (*cp == '\0' || *cp == '\n' || *cp == ';')
-			    break;
-			net = cp;
-			while (*cp && !ISSORTMASK(*cp) && *cp != ';' &&
-			       isascii(*cp) && !isspace((unsigned char)*cp))
-				cp++;
-			n = *cp;
-			*cp = 0;
-			if (inet_aton(net, &a)) {
-			    statp->sort_list[nsort].addr = a;
-			    if (ISSORTMASK(n)) {
-				*cp++ = n;
-				net = cp;
-				while (*cp && *cp != ';' &&
-					isascii(*cp) &&
-					!isspace((unsigned char)*cp))
-				    cp++;
-				n = *cp;
-				*cp = 0;
-				if (inet_aton(net, &a)) {
-				    statp->sort_list[nsort].mask = a.s_addr;
-				} else {
-				    statp->sort_list[nsort].mask = 
-					net_mask(statp->sort_list[nsort].addr);
-				}
-			    } else {
-				statp->sort_list[nsort].mask = 
-				    net_mask(statp->sort_list[nsort].addr);
-			    }
-			    nsort++;
-			}
-			*cp = n;
-		    }
-		    continue;
-		}
-#endif
-		if (MATCH(buf, "options")) {
-		    res_setoptions(statp, buf + sizeof("options") - 1, "conf");
-		    continue;
-		}
-	    }
-	    if (nserv > 0) 
-		statp->nscount = nserv;
-#ifdef RESOLVSORT
-	    statp->nsort = nsort;
-#endif
-	    (void) fclose(fp);
-	}
-/*
- * Last chance to get a nameserver.  This should not normally
- * be necessary
- */
-#ifdef NO_RESOLV_CONF
-	if(nserv == 0)
-		nserv = get_nameservers(statp);
-#endif
-
-	if (statp->defdname[0] == 0 &&
-	    gethostname(buf, sizeof(statp->defdname) - 1) == 0 &&
-	    (cp = strchr(buf, '.')) != NULL)
-		strcpy(statp->defdname, cp + 1);
-
-	/* find components of local domain that might be searched */
-	if (havesearch == 0) {
-		pp = statp->dnsrch;
-		*pp++ = statp->defdname;
-		*pp = NULL;
-
-		dots = 0;
-		for (cp = statp->defdname; *cp; cp++)
-			dots += (*cp == '.');
-
-		cp = statp->defdname;
-		while (pp < statp->dnsrch + MAXDFLSRCH) {
-			if (dots < LOCALDOMAINPARTS)
-				break;
-			cp = strchr(cp, '.') + 1;    /*%< we know there is one */
-			*pp++ = cp;
-			dots--;
-		}
-		*pp = NULL;
-#ifdef DEBUG
-		if (statp->options & RES_DEBUG) {
-			printf(";; res_init()... default dnsrch list:\n");
-			for (pp = statp->dnsrch; *pp; pp++)
-				printf(";;\t%s\n", *pp);
-			printf(";;\t..END..\n");
-		}
-#endif
-	}
-
-	if ((cp = getenv("RES_OPTIONS")) != NULL)
-		res_setoptions(statp, cp, "env");
-	statp->options |= RES_INIT;
-	return (statp->res_h_errno);
-}
-
-static void
-res_setoptions(res_state statp, const char *options, const char *source)
-{
-	const char *cp = options;
-	int i;
-	struct __res_state_ext *ext = statp->_u._ext.ext;
-
-#ifdef DEBUG
-	if (statp->options & RES_DEBUG)
-		printf(";; res_setoptions(\"%s\", \"%s\")...\n",
-		       options, source);
-#endif
-	while (*cp) {
-		/* skip leading and inner runs of spaces */
-		while (*cp == ' ' || *cp == '\t')
-			cp++;
-		/* search for and process individual options */
-		if (!strncmp(cp, "ndots:", sizeof("ndots:") - 1)) {
-			i = atoi(cp + sizeof("ndots:") - 1);
-			if (i <= RES_MAXNDOTS)
-				statp->ndots = i;
-			else
-				statp->ndots = RES_MAXNDOTS;
-#ifdef DEBUG
-			if (statp->options & RES_DEBUG)
-				printf(";;\tndots=%d\n", statp->ndots);
-#endif
-		} else if (!strncmp(cp, "timeout:", sizeof("timeout:") - 1)) {
-			i = atoi(cp + sizeof("timeout:") - 1);
-			if (i <= RES_MAXRETRANS)
-				statp->retrans = i;
-			else
-				statp->retrans = RES_MAXRETRANS;
-#ifdef DEBUG
-			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)
-				statp->retry = i;
-			else
-				statp->retry = RES_MAXRETRY;
-#ifdef DEBUG
-			if (statp->options & RES_DEBUG)
-				printf(";;\tattempts=%d\n", statp->retry);
-#endif
-		} else if (!strncmp(cp, "debug", sizeof("debug") - 1)) {
-#ifdef DEBUG
-			if (!(statp->options & RES_DEBUG)) {
-				printf(";; res_setoptions(\"%s\", \"%s\")..\n",
-				       options, source);
-				statp->options |= RES_DEBUG;
-			}
-			printf(";;\tdebug\n");
-#endif
-		} else if (!strncmp(cp, "no_tld_query",
-				    sizeof("no_tld_query") - 1) ||
-			   !strncmp(cp, "no-tld-query",
-				    sizeof("no-tld-query") - 1)) {
-			statp->options |= RES_NOTLDQUERY;
-		} else if (!strncmp(cp, "inet6", sizeof("inet6") - 1)) {
-			statp->options |= RES_USE_INET6;
-		} else if (!strncmp(cp, "rotate", sizeof("rotate") - 1)) {
-			statp->options |= RES_ROTATE;
-		} else if (!strncmp(cp, "no-check-names",
-				    sizeof("no-check-names") - 1)) {
-			statp->options |= RES_NOCHECKNAME;
-		}
-#ifdef RES_USE_EDNS0
-		else if (!strncmp(cp, "edns0", sizeof("edns0") - 1)) {
-			statp->options |= RES_USE_EDNS0;
-		}
-#endif
-		else if (!strncmp(cp, "dname", sizeof("dname") - 1)) {
-			statp->options |= RES_USE_DNAME;
-		}
-		else if (!strncmp(cp, "nibble:", sizeof("nibble:") - 1)) {
-			if (ext == NULL)
-				goto skip;
-			cp += sizeof("nibble:") - 1;
-			i = MIN(strcspn(cp, " \t"), sizeof(ext->nsuffix) - 1);
-			strncpy(ext->nsuffix, cp, i);
-			ext->nsuffix[i] = '\0';
-		}
-		else if (!strncmp(cp, "nibble2:", sizeof("nibble2:") - 1)) {
-			if (ext == NULL)
-				goto skip;
-			cp += sizeof("nibble2:") - 1;
-			i = MIN(strcspn(cp, " \t"), sizeof(ext->nsuffix2) - 1);
-			strncpy(ext->nsuffix2, cp, i);
-			ext->nsuffix2[i] = '\0';
-		}
-		else if (!strncmp(cp, "v6revmode:", sizeof("v6revmode:") - 1)) {
-			cp += sizeof("v6revmode:") - 1;
-			/* "nibble" and "bitstring" used to be valid */
-			if (!strncmp(cp, "single", sizeof("single") - 1)) {
-				statp->options |= RES_NO_NIBBLE2;
-			} else if (!strncmp(cp, "both", sizeof("both") - 1)) {
-				statp->options &=
-					 ~RES_NO_NIBBLE2;
-			}
-		}
-		else {
-			/* XXX - print a warning here? */
-		}
-   skip:
-		/* skip to next run of spaces */
-		while (*cp && *cp != ' ' && *cp != '\t')
-			cp++;
-	}
-}
-
-#ifdef RESOLVSORT
-/* XXX - should really support CIDR which means explicit masks always. */
-static u_int32_t
-net_mask(in)		/*!< XXX - should really use system's version of this  */
-	struct in_addr in;
-{
-	register u_int32_t i = ntohl(in.s_addr);
-
-	if (IN_CLASSA(i))
-		return (htonl(IN_CLASSA_NET));
-	else if (IN_CLASSB(i))
-		return (htonl(IN_CLASSB_NET));
-	return (htonl(IN_CLASSC_NET));
-}
-#endif
-
-u_int
-res_randomid(void) {
-	struct timeval now;
-
-	gettimeofday(&now, NULL);
-	return (0xffff & (now.tv_sec ^ now.tv_usec ^ getpid()));
-}
-
-/*%
- * This routine is for closing the socket if a virtual circuit is used and
- * the program wants to close it.  This provides support for endhostent()
- * which expects to close the socket.
- *
- * This routine is not expected to be user visible.
- */
-void
-res_nclose(res_state statp) {
-	int ns;
-
-	if (statp->_vcsock >= 0) { 
-		(void) close(statp->_vcsock);
-		statp->_vcsock = -1;
-		statp->_flags &= ~(RES_F_VC | RES_F_CONN);
-	}
-	for (ns = 0; ns < statp->_u._ext.nscount; ns++) {
-		if (statp->_u._ext.nssocks[ns] != -1) {
-			(void) close(statp->_u._ext.nssocks[ns]);
-			statp->_u._ext.nssocks[ns] = -1;
-		}
-	}
-}
-
-void
-res_ndestroy(res_state statp) {
-	res_nclose(statp);
-	if (statp->_u._ext.ext != NULL)
-		free(statp->_u._ext.ext);
-	statp->options &= ~RES_INIT;
-	statp->_u._ext.ext = NULL;
-}
-
-const char *
-res_get_nibblesuffix(res_state statp) {
-	if (statp->_u._ext.ext)
-		return (statp->_u._ext.ext->nsuffix);
-	return ("ip6.arpa");
-}
-
-const char *
-res_get_nibblesuffix2(res_state statp) {
-	if (statp->_u._ext.ext)
-		return (statp->_u._ext.ext->nsuffix2);
-	return ("ip6.int");
-}
-
-void
-res_setservers(res_state statp, const union res_sockaddr_union *set, int cnt) {
-	int i, nserv;
-	size_t size;
-
-	/* close open servers */
-	res_nclose(statp);
-
-	/* cause rtt times to be forgotten */
-	statp->_u._ext.nscount = 0;
-
-	nserv = 0;
-	for (i = 0; i < cnt && nserv < MAXNS; i++) {
-		switch (set->sin.sin_family) {
-		case AF_INET:
-			size = sizeof(set->sin);
-			if (statp->_u._ext.ext)
-				memcpy(&statp->_u._ext.ext->nsaddrs[nserv],
-					&set->sin, size);
-			if (size <= sizeof(statp->nsaddr_list[nserv]))
-				memcpy(&statp->nsaddr_list[nserv],
-					&set->sin, size);
-			else
-				statp->nsaddr_list[nserv].sin_family = 0;
-			nserv++;
-			break;
-
-#ifdef HAS_INET6_STRUCTS
-		case AF_INET6:
-			size = sizeof(set->sin6);
-			if (statp->_u._ext.ext)
-				memcpy(&statp->_u._ext.ext->nsaddrs[nserv],
-					&set->sin6, size);
-			if (size <= sizeof(statp->nsaddr_list[nserv]))
-				memcpy(&statp->nsaddr_list[nserv],
-					&set->sin6, size);
-			else
-				statp->nsaddr_list[nserv].sin_family = 0;
-			nserv++;
-			break;
-#endif
-
-		default:
-			break;
-		}
-		set++;
-	}
-	statp->nscount = nserv;
-	
-}
-
-int
-res_getservers(res_state statp, union res_sockaddr_union *set, int cnt) {
-	int i;
-	size_t size;
-	u_int16_t family;
-
-	for (i = 0; i < statp->nscount && i < cnt; i++) {
-		if (statp->_u._ext.ext)
-			family = statp->_u._ext.ext->nsaddrs[i].sin.sin_family;
-		else 
-			family = statp->nsaddr_list[i].sin_family;
-
-		switch (family) {
-		case AF_INET:
-			size = sizeof(set->sin);
-			if (statp->_u._ext.ext)
-				memcpy(&set->sin,
-				       &statp->_u._ext.ext->nsaddrs[i],
-				       size);
-			else
-				memcpy(&set->sin, &statp->nsaddr_list[i],
-				       size);
-			break;
-
-#ifdef HAS_INET6_STRUCTS
-		case AF_INET6:
-			size = sizeof(set->sin6);
-			if (statp->_u._ext.ext)
-				memcpy(&set->sin6,
-				       &statp->_u._ext.ext->nsaddrs[i],
-				       size);
-			else
-				memcpy(&set->sin6, &statp->nsaddr_list[i],
-				       size);
-			break;
-#endif
-
-		default:
-			set->sin.sin_family = 0;
-			break;
-		}
-		set++;
-	}
-	return (statp->nscount);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/resolv/res_mkquery.c b/contrib/bind9/lib/bind/resolv/res_mkquery.c
deleted file mode 100644
index 049f6c5..0000000
--- a/contrib/bind9/lib/bind/resolv/res_mkquery.c
+++ /dev/null
@@ -1,303 +0,0 @@
-/*
- * Copyright (c) 1985, 1993
- *    The Regents of the University of California.  All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- * 	This product includes software developed by the University of
- * 	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-/*
- * Portions Copyright (c) 1993 by Digital Equipment Corporation.
- * 
- * 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, and that
- * the name of Digital Equipment Corporation not be used in advertising or
- * publicity pertaining to distribution of the document or software without
- * specific, written prior permission.
- * 
- * THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
- * WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
- * OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
- * CORPORATION 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.
- */
-
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char sccsid[] = "@(#)res_mkquery.c	8.1 (Berkeley) 6/4/93";
-static const char rcsid[] = "$Id: res_mkquery.c,v 1.5.18.2 2008/04/03 23:15:15 marka Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-#include "port_before.h"
-#include <sys/types.h>
-#include <sys/param.h>
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <netdb.h>
-#include <resolv.h>
-#include <stdio.h>
-#include <string.h>
-#include "port_after.h"
-
-/* Options.  Leave them on. */
-#define DEBUG
-
-extern const char *_res_opcodes[];
-
-/*%
- * Form all types of queries.
- * Returns the size of the result or -1.
- */
-int
-res_nmkquery(res_state statp,
-	     int op,			/*!< opcode of query  */
-	     const char *dname,		/*!< domain name  */
-	     int class, int type,	/*!< class and type of query  */
-	     const u_char *data,	/*!< resource record data  */
-	     int datalen,		/*!< length of data  */
-	     const u_char *newrr_in,	/*!< new rr for modify or append  */
-	     u_char *buf,		/*!< buffer to put query  */
-	     int buflen)		/*!< size of buffer  */
-{
-	register HEADER *hp;
-	register u_char *cp, *ep;
-	register int n;
-	u_char *dnptrs[20], **dpp, **lastdnptr;
-
-	UNUSED(newrr_in);
-
-#ifdef DEBUG
-	if (statp->options & RES_DEBUG)
-		printf(";; res_nmkquery(%s, %s, %s, %s)\n",
-		       _res_opcodes[op], dname, p_class(class), p_type(type));
-#endif
-	/*
-	 * Initialize header fields.
-	 */
-	if ((buf == NULL) || (buflen < HFIXEDSZ))
-		return (-1);
-	memset(buf, 0, HFIXEDSZ);
-	hp = (HEADER *) buf;
-	hp->id = htons(++statp->id);
-	hp->opcode = op;
-	hp->rd = (statp->options & RES_RECURSE) != 0U;
-	hp->rcode = NOERROR;
-	cp = buf + HFIXEDSZ;
-	ep = buf + buflen;
-	dpp = dnptrs;
-	*dpp++ = buf;
-	*dpp++ = NULL;
-	lastdnptr = dnptrs + sizeof dnptrs / sizeof dnptrs[0];
-	/*
-	 * perform opcode specific processing
-	 */
-	switch (op) {
-	case QUERY:	/*FALLTHROUGH*/
-	case NS_NOTIFY_OP:
-		if (ep - cp < QFIXEDSZ)
-			return (-1);
-		if ((n = dn_comp(dname, cp, ep - cp - QFIXEDSZ, dnptrs,
-		    lastdnptr)) < 0)
-			return (-1);
-		cp += n;
-		ns_put16(type, cp);
-		cp += INT16SZ;
-		ns_put16(class, cp);
-		cp += INT16SZ;
-		hp->qdcount = htons(1);
-		if (op == QUERY || data == NULL)
-			break;
-		/*
-		 * Make an additional record for completion domain.
-		 */
-		if ((ep - cp) < RRFIXEDSZ)
-			return (-1);
-		n = dn_comp((const char *)data, cp, ep - cp - RRFIXEDSZ,
-			    dnptrs, lastdnptr);
-		if (n < 0)
-			return (-1);
-		cp += n;
-		ns_put16(T_NULL, cp);
-		cp += INT16SZ;
-		ns_put16(class, cp);
-		cp += INT16SZ;
-		ns_put32(0, cp);
-		cp += INT32SZ;
-		ns_put16(0, cp);
-		cp += INT16SZ;
-		hp->arcount = htons(1);
-		break;
-
-	case IQUERY:
-		/*
-		 * Initialize answer section
-		 */
-		if (ep - cp < 1 + RRFIXEDSZ + datalen)
-			return (-1);
-		*cp++ = '\0';	/*%< no domain name */
-		ns_put16(type, cp);
-		cp += INT16SZ;
-		ns_put16(class, cp);
-		cp += INT16SZ;
-		ns_put32(0, cp);
-		cp += INT32SZ;
-		ns_put16(datalen, cp);
-		cp += INT16SZ;
-		if (datalen) {
-			memcpy(cp, data, datalen);
-			cp += datalen;
-		}
-		hp->ancount = htons(1);
-		break;
-
-	default:
-		return (-1);
-	}
-	return (cp - buf);
-}
-
-#ifdef RES_USE_EDNS0
-/* attach OPT pseudo-RR, as documented in RFC2671 (EDNS0). */
-
-int
-res_nopt(res_state statp,
-	 int n0,		/*%< current offset in buffer */
-	 u_char *buf,		/*%< buffer to put query */
-	 int buflen,		/*%< size of buffer */
-	 int anslen)		/*%< UDP answer buffer size */
-{
-	register HEADER *hp;
-	register u_char *cp, *ep;
-	u_int16_t flags = 0;
-
-#ifdef DEBUG
-	if ((statp->options & RES_DEBUG) != 0U)
-		printf(";; res_nopt()\n");
-#endif
-
-	hp = (HEADER *) buf;
-	cp = buf + n0;
-	ep = buf + buflen;
-
-	if ((ep - cp) < 1 + RRFIXEDSZ)
-		return (-1);
-
-	*cp++ = 0;				/*%< "." */
-	ns_put16(ns_t_opt, cp);			/*%< TYPE */
-	cp += INT16SZ;
-	ns_put16(anslen & 0xffff, cp);		/*%< CLASS = UDP payload size */
-	cp += INT16SZ;
-	*cp++ = NOERROR;			/*%< extended RCODE */
-	*cp++ = 0;				/*%< EDNS version */
-
-	if (statp->options & RES_USE_DNSSEC) {
-#ifdef DEBUG
-		if (statp->options & RES_DEBUG)
-			printf(";; res_opt()... ENDS0 DNSSEC\n");
-#endif
-		flags |= NS_OPT_DNSSEC_OK;
-	}
-	ns_put16(flags, cp);
-	cp += INT16SZ;
-
-	ns_put16(0U, cp);			/*%< RDLEN */
-	cp += INT16SZ;
-
-	hp->arcount = htons(ntohs(hp->arcount) + 1);
-
-	return (cp - buf);
-}
-
-/*
- * Construct variable data (RDATA) block for OPT psuedo-RR, append it
- * to the buffer, then update the RDLEN field (previously set to zero by
- * res_nopt()) with the new RDATA length.
- */
-int
-res_nopt_rdata(res_state statp,
-	  int n0,	 	/*%< current offset in buffer */
-	  u_char *buf,	 	/*%< buffer to put query */
-	  int buflen,		/*%< size of buffer */
-	  u_char *rdata,	/*%< ptr to start of opt rdata */
-	  u_short code,		/*%< OPTION-CODE */
-	  u_short len,		/*%< OPTION-LENGTH */
-	  u_char *data)		/*%< OPTION_DATA */
-{
-	register u_char *cp, *ep;
-
-#ifdef DEBUG
-	if ((statp->options & RES_DEBUG) != 0U)
-		printf(";; res_nopt_rdata()\n");
-#endif
-
-	cp = buf + n0;
-	ep = buf + buflen;
-
-	if ((ep - cp) < (4 + len))
-		return (-1);
-
-	if (rdata < (buf + 2) || rdata >= ep)
-		return (-1);
-
-	ns_put16(code, cp);
-	cp += INT16SZ;
-
-	ns_put16(len, cp);
-	cp += INT16SZ;
-
-	memcpy(cp, data, len);
-	cp += len;
-
-	len = cp - rdata;
-	ns_put16(len, rdata - 2);	/* Update RDLEN field */
-
-	return (cp - buf);
-}
-#endif
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/resolv/res_mkupdate.c b/contrib/bind9/lib/bind/resolv/res_mkupdate.c
deleted file mode 100644
index 4299275..0000000
--- a/contrib/bind9/lib/bind/resolv/res_mkupdate.c
+++ /dev/null
@@ -1,1162 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996-1999 by 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
- * \brief
- * Based on the Dynamic DNS reference implementation by Viraj Bais
- * &lt;viraj_bais@ccm.fm.intel.com>
- */
-
-#if !defined(lint) && !defined(SABER)
-static const char rcsid[] = "$Id: res_mkupdate.c,v 1.4.18.4 2005/10/14 05:44:12 marka Exp $";
-#endif /* not lint */
-
-#include "port_before.h"
-
-#include <sys/types.h>
-#include <sys/param.h>
-
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <arpa/inet.h>
-
-#include <errno.h>
-#include <limits.h>
-#include <netdb.h>
-#include <resolv.h>
-#include <res_update.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <unistd.h>
-#include <ctype.h>
-
-#include "port_after.h"
-
-/* Options.  Leave them on. */
-#define DEBUG
-#define MAXPORT 1024
-
-static int getnum_str(u_char **, u_char *);
-static int gethexnum_str(u_char **, u_char *);
-static int getword_str(char *, int, u_char **, u_char *);
-static int getstr_str(char *, int, u_char **, u_char *);
-
-#define ShrinkBuffer(x)  if ((buflen -= x) < 0) return (-2);
-
-/* Forward. */
-
-int res_protocolnumber(const char *);
-int res_servicenumber(const char *);
-
-/*%
- * Form update packets.
- * Returns the size of the resulting packet if no error
- *
- * On error,
- *	returns 
- *\li              -1 if error in reading a word/number in rdata
- *		   portion for update packets
- *\li		-2 if length of buffer passed is insufficient
- *\li		-3 if zone section is not the first section in
- *		   the linked list, or section order has a problem
- *\li		-4 on a number overflow
- *\li		-5 unknown operation or no records
- */
-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, *sp2, *startp, *endp;
-	int n, i, soanum, multiline;
-	ns_updrec *rrecp;
-	struct in_addr ina;
-	struct in6_addr in6a;
-        char buf2[MAXDNAME];
-	u_char buf3[MAXDNAME];
-	int section, numrrs = 0, counts[ns_s_max];
-	u_int16_t rtype, rclass;
-	u_int32_t n1, rttl;
-	u_char *dnptrs[20], **dpp, **lastdnptr;
-	int siglen, keylen, certlen;
-
-	/*
-	 * Initialize header fields.
-	 */
-	if ((buf == NULL) || (buflen < HFIXEDSZ))
-		return (-1);
-	memset(buf, 0, HFIXEDSZ);
-	hp = (HEADER *) buf;
-	hp->id = htons(++statp->id);
-	hp->opcode = ns_o_update;
-	hp->rcode = NOERROR;
-	cp = buf + HFIXEDSZ;
-	buflen -= HFIXEDSZ;
-	dpp = dnptrs;
-	*dpp++ = buf;
-	*dpp++ = NULL;
-	lastdnptr = dnptrs + sizeof dnptrs / sizeof dnptrs[0];
-
-	if (rrecp_start == NULL)
-		return (-5);
-	else if (rrecp_start->r_section != S_ZONE)
-		return (-3);
-
-	memset(counts, 0, sizeof counts);
-	for (rrecp = rrecp_start; rrecp; rrecp = NEXT(rrecp, r_glink)) {
-		numrrs++;
-                section = rrecp->r_section;
-		if (section < 0 || section >= ns_s_max)
-			return (-1);
-		counts[section]++;
-		for (i = section + 1; i < ns_s_max; i++)
-			if (counts[i])
-				return (-3);
-		rtype = rrecp->r_type;
-		rclass = rrecp->r_class;
-		rttl = rrecp->r_ttl;
-		/* overload class and type */
-		if (section == S_PREREQ) {
-			rttl = 0;
-			switch (rrecp->r_opcode) {
-			case YXDOMAIN:
-				rclass = C_ANY;
-				rtype = T_ANY;
-				rrecp->r_size = 0;
-				break;
-			case NXDOMAIN:
-				rclass = C_NONE;
-				rtype = T_ANY;
-				rrecp->r_size = 0;
-				break;
-			case NXRRSET:
-				rclass = C_NONE;
-				rrecp->r_size = 0;
-				break;
-			case YXRRSET:
-				if (rrecp->r_size == 0)
-					rclass = C_ANY;
-				break;
-			default:
-				fprintf(stderr,
-					"res_mkupdate: incorrect opcode: %d\n",
-					rrecp->r_opcode);
-				fflush(stderr);
-				return (-1);
-			}
-		} else if (section == S_UPDATE) {
-			switch (rrecp->r_opcode) {
-			case DELETE:
-				rclass = rrecp->r_size == 0 ? C_ANY : C_NONE;
-				break;
-			case ADD:
-				break;
-			default:
-				fprintf(stderr,
-					"res_mkupdate: incorrect opcode: %d\n",
-					rrecp->r_opcode);
-				fflush(stderr);
-				return (-1);
-			}
-		}
-
-		/*
-		 * XXX	appending default domain to owner name is omitted,
-		 *	fqdn must be provided
-		 */
-		if ((n = dn_comp(rrecp->r_dname, cp, buflen, dnptrs,
-				 lastdnptr)) < 0)
-			return (-1);
-		cp += n;
-		ShrinkBuffer(n + 2*INT16SZ);
-		PUTSHORT(rtype, cp);
-		PUTSHORT(rclass, cp);
-		if (section == S_ZONE) {
-			if (numrrs != 1 || rrecp->r_type != T_SOA)
-				return (-3);
-			continue;
-		}
-		ShrinkBuffer(INT32SZ + INT16SZ);
-		PUTLONG(rttl, cp);
-		sp2 = cp;  /*%< save pointer to length byte */
-		cp += INT16SZ;
-		if (rrecp->r_size == 0) {
-			if (section == S_UPDATE && rclass != C_ANY)
-				return (-1);
-			else {
-				PUTSHORT(0, sp2);
-				continue;
-			}
-		}
-		startp = rrecp->r_data;
-		endp = startp + rrecp->r_size - 1;
-		/* XXX this should be done centrally. */
-		switch (rrecp->r_type) {
-		case T_A:
-			if (!getword_str(buf2, sizeof buf2, &startp, endp))
-				return (-1);
-			if (!inet_aton(buf2, &ina))
-				return (-1);
-			n1 = ntohl(ina.s_addr);
-			ShrinkBuffer(INT32SZ);
-			PUTLONG(n1, cp);
-			break;
-		case T_CNAME:
-		case T_MB:
-		case T_MG:
-		case T_MR:
-		case T_NS:
-		case T_PTR:
-		case ns_t_dname:
-			if (!getword_str(buf2, sizeof buf2, &startp, endp))
-				return (-1);
-			n = dn_comp(buf2, cp, buflen, dnptrs, lastdnptr);
-			if (n < 0)
-				return (-1);
-			cp += n;
-			ShrinkBuffer(n);
-			break;
-		case T_MINFO:
-		case T_SOA:
-		case T_RP:
-			for (i = 0; i < 2; i++) {
-				if (!getword_str(buf2, sizeof buf2, &startp,
-						 endp))
-				return (-1);
-				n = dn_comp(buf2, cp, buflen,
-					    dnptrs, lastdnptr);
-				if (n < 0)
-					return (-1);
-				cp += n;
-				ShrinkBuffer(n);
-			}
-			if (rrecp->r_type == T_SOA) {
-				ShrinkBuffer(5 * INT32SZ);
-				while (isspace(*startp) || !*startp)
-					startp++;
-				if (*startp == '(') {
-					multiline = 1;
-					startp++;
-				} else
-					multiline = 0;
-				/* serial, refresh, retry, expire, minimum */
-				for (i = 0; i < 5; i++) {
-					soanum = getnum_str(&startp, endp);
-					if (soanum < 0)
-						return (-1);
-					PUTLONG(soanum, cp);
-				}
-				if (multiline) {
-					while (isspace(*startp) || !*startp)
-						startp++;
-					if (*startp != ')')
-						return (-1);
-				}
-			}
-			break;
-		case T_MX:
-		case T_AFSDB:
-		case T_RT:
-			n = getnum_str(&startp, endp);
-			if (n < 0)
-				return (-1);
-			ShrinkBuffer(INT16SZ);
-			PUTSHORT(n, cp);
-			if (!getword_str(buf2, sizeof buf2, &startp, endp))
-				return (-1);
-			n = dn_comp(buf2, cp, buflen, dnptrs, lastdnptr);
-			if (n < 0)
-				return (-1);
-			cp += n;
-			ShrinkBuffer(n);
-			break;
-		case T_SRV:
-			n = getnum_str(&startp, endp);
-			if (n < 0)
-				return (-1);
-			ShrinkBuffer(INT16SZ);
-			PUTSHORT(n, cp);
-
-			n = getnum_str(&startp, endp);
-			if (n < 0)
-				return (-1);
-			ShrinkBuffer(INT16SZ);
-			PUTSHORT(n, cp);
-
-			n = getnum_str(&startp, endp);
-			if (n < 0)
-				return (-1);
-			ShrinkBuffer(INT16SZ);
-			PUTSHORT(n, cp);
-
-			if (!getword_str(buf2, sizeof buf2, &startp, endp))
-				return (-1);
-			n = dn_comp(buf2, cp, buflen, NULL, NULL);
-			if (n < 0)
-				return (-1);
-			cp += n;
-			ShrinkBuffer(n);
-			break;
-		case T_PX:
-			n = getnum_str(&startp, endp);
-			if (n < 0)
-				return (-1);
-			PUTSHORT(n, cp);
-			ShrinkBuffer(INT16SZ);
-			for (i = 0; i < 2; i++) {
-				if (!getword_str(buf2, sizeof buf2, &startp,
-						 endp))
-					return (-1);
-				n = dn_comp(buf2, cp, buflen, dnptrs,
-					    lastdnptr);
-				if (n < 0)
-					return (-1);
-				cp += n;
-				ShrinkBuffer(n);
-			}
-			break;
-		case T_WKS: {
-			char bm[MAXPORT/8];
-			unsigned int maxbm = 0;
-
-			if (!getword_str(buf2, sizeof buf2, &startp, endp))
-				return (-1);
-			if (!inet_aton(buf2, &ina))
-				return (-1);
-			n1 = ntohl(ina.s_addr);
-			ShrinkBuffer(INT32SZ);
-			PUTLONG(n1, cp);
-
-			if (!getword_str(buf2, sizeof buf2, &startp, endp))
-				return (-1);
-			if ((i = res_protocolnumber(buf2)) < 0)
-				return (-1);
-			ShrinkBuffer(1);
-			*cp++ = i & 0xff;
-			 
-			for (i = 0; i < MAXPORT/8 ; i++)
-				bm[i] = 0;
-
-			while (getword_str(buf2, sizeof buf2, &startp, endp)) {
-				if ((n = res_servicenumber(buf2)) <= 0)
-					return (-1);
-
-				if (n < MAXPORT) {
-					bm[n/8] |= (0x80>>(n%8));
-					if ((unsigned)n > maxbm)
-						maxbm = n;
-				} else
-					return (-1);
-			}
-			maxbm = maxbm/8 + 1;
-			ShrinkBuffer(maxbm);
-			memcpy(cp, bm, maxbm);
-			cp += maxbm;
-			break;
-		}
-		case T_HINFO:
-			for (i = 0; i < 2; i++) {
-				if ((n = getstr_str(buf2, sizeof buf2,
-						&startp, endp)) < 0)
-					return (-1);
-				if (n > 255)
-					return (-1);
-				ShrinkBuffer(n+1);
-				*cp++ = n;
-				memcpy(cp, buf2, n);
-				cp += n;
-			}
-			break;
-		case T_TXT:
-			for (;;) {
-				if ((n = getstr_str(buf2, sizeof buf2,
-						&startp, endp)) < 0) {
-					if (cp != (sp2 + INT16SZ))
-						break;
-					return (-1);
-				}
-				if (n > 255)
-					return (-1);
-				ShrinkBuffer(n+1);
-				*cp++ = n;
-				memcpy(cp, buf2, n);
-				cp += n;
-			}
-			break;
-		case T_X25:
-			/* RFC1183 */
-			if ((n = getstr_str(buf2, sizeof buf2, &startp,
-					 endp)) < 0)
-				return (-1);
-			if (n > 255)
-				return (-1);
-			ShrinkBuffer(n+1);
-			*cp++ = n;
-			memcpy(cp, buf2, n);
-			cp += n;
-			break;
-		case T_ISDN:
-			/* RFC1183 */
-			if ((n = getstr_str(buf2, sizeof buf2, &startp,
-					 endp)) < 0)
-				return (-1);
-			if ((n > 255) || (n == 0))
-				return (-1);
-			ShrinkBuffer(n+1);
-			*cp++ = n;
-			memcpy(cp, buf2, n);
-			cp += n;
-			if ((n = getstr_str(buf2, sizeof buf2, &startp,
-					 endp)) < 0)
-				n = 0;
-			if (n > 255)
-				return (-1);
-			ShrinkBuffer(n+1);
-			*cp++ = n;
-			memcpy(cp, buf2, n);
-			cp += n;
-			break;
-		case T_NSAP:
-			if ((n = inet_nsap_addr((char *)startp, (u_char *)buf2, sizeof(buf2))) != 0) {
-				ShrinkBuffer(n);
-				memcpy(cp, buf2, n);
-				cp += n;
-			} else {
-				return (-1);
-			}
-			break;
-		case T_LOC:
-			if ((n = loc_aton((char *)startp, (u_char *)buf2)) != 0) {
-				ShrinkBuffer(n);
-				memcpy(cp, buf2, n);
-				cp += n;
-			} else
-				return (-1);
-			break;
-		case ns_t_sig:
-		    {
-			int sig_type, success, dateerror;
-			u_int32_t exptime, timesigned;
-
-			/* type */
-			if ((n = getword_str(buf2, sizeof buf2,
-					     &startp, endp)) < 0)
-				return (-1);
-			sig_type = sym_ston(__p_type_syms, buf2, &success);
-			if (!success || sig_type == ns_t_any)
-				return (-1);
-			ShrinkBuffer(INT16SZ);
-			PUTSHORT(sig_type, cp);
-			/* alg */
-			n = getnum_str(&startp, endp);
-			if (n < 0)
-				return (-1);
-			ShrinkBuffer(1);
-			*cp++ = n;
-			/* labels */
-			n = getnum_str(&startp, endp);
-			if (n <= 0 || n > 255)
-				return (-1);
-			ShrinkBuffer(1);
-			*cp++ = n;
-			/* ottl  & expire */
-			if (!getword_str(buf2, sizeof buf2, &startp, endp))
-				return (-1);
-			exptime = ns_datetosecs(buf2, &dateerror);
-			if (!dateerror) {
-				ShrinkBuffer(INT32SZ);
-				PUTLONG(rttl, cp);
-			}
-			else {
-				char *ulendp;
-				u_int32_t ottl;
-
-				errno = 0;
-				ottl = strtoul(buf2, &ulendp, 10);
-				if (errno != 0 ||
-				    (ulendp != NULL && *ulendp != '\0'))
-					return (-1);
-				ShrinkBuffer(INT32SZ);
-				PUTLONG(ottl, cp);
-				if (!getword_str(buf2, sizeof buf2, &startp,
-						 endp))
-					return (-1);
-				exptime = ns_datetosecs(buf2, &dateerror);
-				if (dateerror)
-					return (-1);
-			}
-			/* expire */
-			ShrinkBuffer(INT32SZ);
-			PUTLONG(exptime, cp);
-			/* timesigned */
-			if (!getword_str(buf2, sizeof buf2, &startp, endp))
-				return (-1);
-			timesigned = ns_datetosecs(buf2, &dateerror);
-			if (!dateerror) {
-				ShrinkBuffer(INT32SZ);
-				PUTLONG(timesigned, cp);
-			}
-			else
-				return (-1);
-			/* footprint */
-			n = getnum_str(&startp, endp);
-			if (n < 0)
-				return (-1);
-			ShrinkBuffer(INT16SZ);
-			PUTSHORT(n, cp);
-			/* signer name */
-			if (!getword_str(buf2, sizeof buf2, &startp, endp))
-				return (-1);
-			n = dn_comp(buf2, cp, buflen, dnptrs, lastdnptr);
-			if (n < 0)
-				return (-1);
-			cp += n;
-			ShrinkBuffer(n);
-			/* sig */
-			if ((n = getword_str(buf2, sizeof buf2,
-					     &startp, endp)) < 0)
-				return (-1);
-			siglen = b64_pton(buf2, buf3, sizeof(buf3));
-			if (siglen < 0)
-				return (-1);
-			ShrinkBuffer(siglen);
-			memcpy(cp, buf3, siglen);
-			cp += siglen;
-			break;
-		    }
-		case ns_t_key:
-			/* flags */
-			n = gethexnum_str(&startp, endp);
-			if (n < 0)
-				return (-1);
-			ShrinkBuffer(INT16SZ);
-			PUTSHORT(n, cp);
-			/* proto */
-			n = getnum_str(&startp, endp);
-			if (n < 0)
-				return (-1);
-			ShrinkBuffer(1);
-			*cp++ = n;
-			/* alg */
-			n = getnum_str(&startp, endp);
-			if (n < 0)
-				return (-1);
-			ShrinkBuffer(1);
-			*cp++ = n;
-			/* key */
-			if ((n = getword_str(buf2, sizeof buf2,
-					     &startp, endp)) < 0)
-				return (-1);
-			keylen = b64_pton(buf2, buf3, sizeof(buf3));
-			if (keylen < 0)
-				return (-1);
-			ShrinkBuffer(keylen);
-			memcpy(cp, buf3, keylen);
-			cp += keylen;
-			break;
-		case ns_t_nxt:
-		    {
-			int success, nxt_type;
-			u_char data[32];
-			int maxtype;
-
-			/* next name */
-			if (!getword_str(buf2, sizeof buf2, &startp, endp))
-				return (-1);
-			n = dn_comp(buf2, cp, buflen, NULL, NULL);
-			if (n < 0)
-				return (-1);
-			cp += n;
-			ShrinkBuffer(n);
-			maxtype = 0;
-			memset(data, 0, sizeof data);
-			for (;;) {
-				if (!getword_str(buf2, sizeof buf2, &startp,
-						 endp))
-					break;
-				nxt_type = sym_ston(__p_type_syms, buf2,
-						    &success);
-				if (!success || !ns_t_rr_p(nxt_type))
-					return (-1);
-				NS_NXT_BIT_SET(nxt_type, data);
-				if (nxt_type > maxtype)
-					maxtype = nxt_type;
-			}
-			n = maxtype/NS_NXT_BITS+1;
-			ShrinkBuffer(n);
-			memcpy(cp, data, n);
-			cp += n;
-			break;
-		    }
-		case ns_t_cert:
-			/* type */
-			n = getnum_str(&startp, endp);
-			if (n < 0)
-				return (-1);
-			ShrinkBuffer(INT16SZ);
-			PUTSHORT(n, cp);
-			/* key tag */
-			n = getnum_str(&startp, endp);
-			if (n < 0)
-				return (-1);
-			ShrinkBuffer(INT16SZ);
-			PUTSHORT(n, cp);
-			/* alg */
-			n = getnum_str(&startp, endp);
-			if (n < 0)
-				return (-1);
-			ShrinkBuffer(1);
-			*cp++ = n;
-			/* cert */
-			if ((n = getword_str(buf2, sizeof buf2,
-					     &startp, endp)) < 0)
-				return (-1);
-			certlen = b64_pton(buf2, buf3, sizeof(buf3));
-			if (certlen < 0)
-				return (-1);
-			ShrinkBuffer(certlen);
-			memcpy(cp, buf3, certlen);
-			cp += certlen;
-			break;
-		case ns_t_aaaa:
-			if (!getword_str(buf2, sizeof buf2, &startp, endp))
-				return (-1);
-			if (inet_pton(AF_INET6, buf2, &in6a) <= 0)
-				return (-1);
-			ShrinkBuffer(NS_IN6ADDRSZ);
-			memcpy(cp, &in6a, NS_IN6ADDRSZ);
-			cp += NS_IN6ADDRSZ;
-			break;
-		case ns_t_naptr:
-			/* Order Preference Flags Service Replacement Regexp */
-			/* Order */
-			n = getnum_str(&startp, endp);
-			if (n < 0 || n > 65535)
-				return (-1);
-			ShrinkBuffer(INT16SZ);
-			PUTSHORT(n, cp);
-			/* Preference */
-			n = getnum_str(&startp, endp);
-			if (n < 0 || n > 65535)
-				return (-1);
-			ShrinkBuffer(INT16SZ);
-			PUTSHORT(n, cp);
-			/* Flags */
-			if ((n = getstr_str(buf2, sizeof buf2,
-					&startp, endp)) < 0) {
-				return (-1);
-			}
-			if (n > 255)
-				return (-1);
-			ShrinkBuffer(n+1);
-			*cp++ = n;
-			memcpy(cp, buf2, n);
-			cp += n;
-			/* Service Classes */
-			if ((n = getstr_str(buf2, sizeof buf2,
-					&startp, endp)) < 0) {
-				return (-1);
-			}
-			if (n > 255)
-				return (-1);
-			ShrinkBuffer(n+1);
-			*cp++ = n;
-			memcpy(cp, buf2, n);
-			cp += n;
-			/* Pattern */
-			if ((n = getstr_str(buf2, sizeof buf2,
-					&startp, endp)) < 0) {
-				return (-1);
-			}
-			if (n > 255)
-				return (-1);
-			ShrinkBuffer(n+1);
-			*cp++ = n;
-			memcpy(cp, buf2, n);
-			cp += n;
-			/* Replacement */
-			if (!getword_str(buf2, sizeof buf2, &startp, endp))
-				return (-1);
-			n = dn_comp(buf2, cp, buflen, NULL, NULL);
-			if (n < 0)
-				return (-1);
-			cp += n;
-			ShrinkBuffer(n);
-			break;
-		default:
-			return (-1);
-		} /*switch*/
-		n = (u_int16_t)((cp - sp2) - INT16SZ);
-		PUTSHORT(n, sp2);
-	} /*for*/
-		
-	hp->qdcount = htons(counts[0]);
-	hp->ancount = htons(counts[1]);
-	hp->nscount = htons(counts[2]);
-	hp->arcount = htons(counts[3]);
-	return (cp - buf);
-}
-
-/*%
- * Get a whitespace delimited word from a string (not file)
- * into buf. modify the start pointer to point after the
- * word in the string.
- */
-static int
-getword_str(char *buf, int size, u_char **startpp, u_char *endp) {
-        char *cp;
-        int c;
- 
-        for (cp = buf; *startpp <= endp; ) {
-                c = **startpp;
-                if (isspace(c) || c == '\0') {
-                        if (cp != buf) /*%< trailing whitespace */
-                                break;
-                        else { /*%< leading whitespace */
-                                (*startpp)++;
-                                continue;
-                        }
-                }
-                (*startpp)++;
-                if (cp >= buf+size-1)
-                        break;
-                *cp++ = (u_char)c;
-        }
-        *cp = '\0';
-        return (cp != buf);
-}
-
-/*%
- * get a white spae delimited string from memory.  Process quoted strings
- * and \\DDD escapes.  Return length or -1 on error.  Returned string may
- * contain nulls.
- */
-static char digits[] = "0123456789";
-static int
-getstr_str(char *buf, int size, u_char **startpp, u_char *endp) {
-        char *cp;
-        int c, c1 = 0;
-	int inquote = 0;
-	int seen_quote = 0;
-	int escape = 0;
-	int dig = 0;
- 
-	for (cp = buf; *startpp <= endp; ) {
-                if ((c = **startpp) == '\0')
-			break;
-		/* leading white space */
-		if ((cp == buf) && !seen_quote && isspace(c)) {
-			(*startpp)++;
-			continue;
-		}
-
-		switch (c) {
-		case '\\':
-			if (!escape)  {
-				escape = 1;
-				dig = 0;
-				c1 = 0;
-				(*startpp)++;
-				continue;
-			} 
-			goto do_escape;
-		case '"':
-			if (!escape) {
-				inquote = !inquote;
-				seen_quote = 1;
-				(*startpp)++;
-				continue;
-			}
-			/* fall through */
-		default:
-		do_escape:
-			if (escape) {
-				switch (c) {
-				case '0':
-				case '1':
-				case '2':
-				case '3':
-				case '4':
-				case '5':
-				case '6':
-				case '7':
-				case '8':
-				case '9':
-					c1 = c1 * 10 + 
-						(strchr(digits, c) - digits);
-
-					if (++dig == 3) {
-						c = c1 &0xff;
-						break;
-					}
-					(*startpp)++;
-					continue;
-				}
-				escape = 0;
-			} else if (!inquote && isspace(c))
-				goto done;
-			if (cp >= buf+size-1)
-				goto done;
-			*cp++ = (u_char)c;
-			(*startpp)++;
-		}
-	}
- done:
-	*cp = '\0';
-	return ((cp == buf)?  (seen_quote? 0: -1): (cp - buf));
-}
-
-/*%
- * Get a whitespace delimited base 16 number from a string (not file) into buf
- * update the start pointer to point after the number in the string.
- */
-static int
-gethexnum_str(u_char **startpp, u_char *endp) {
-        int c, n;
-        int seendigit = 0;
-        int m = 0;
-
-	if (*startpp + 2 >= endp || strncasecmp((char *)*startpp, "0x", 2) != 0)
-		return getnum_str(startpp, endp);
-	(*startpp)+=2;
-        for (n = 0; *startpp <= endp; ) {
-                c = **startpp;
-                if (isspace(c) || c == '\0') {
-                        if (seendigit) /*%< trailing whitespace */
-                                break;
-                        else { /*%< leading whitespace */
-                                (*startpp)++;
-                                continue;
-                        }
-                }
-                if (c == ';') {
-                        while ((*startpp <= endp) &&
-			       ((c = **startpp) != '\n'))
-					(*startpp)++;
-                        if (seendigit)
-                                break;
-                        continue;
-                }
-                if (!isxdigit(c)) {
-                        if (c == ')' && seendigit) {
-                                (*startpp)--;
-                                break;
-                        }
-			return (-1);
-                }        
-                (*startpp)++;
-		if (isdigit(c))
-	                n = n * 16 + (c - '0');
-		else
-			n = n * 16 + (tolower(c) - 'a' + 10);
-                seendigit = 1;
-        }
-        return (n + m);
-}
-
-/*%
- * Get a whitespace delimited base 10 number from a string (not file) into buf
- * update the start pointer to point after the number in the string.
- */
-static int
-getnum_str(u_char **startpp, u_char *endp) {
-        int c, n;
-        int seendigit = 0;
-        int m = 0;
-
-        for (n = 0; *startpp <= endp; ) {
-                c = **startpp;
-                if (isspace(c) || c == '\0') {
-                        if (seendigit) /*%< trailing whitespace */
-                                break;
-                        else { /*%< leading whitespace */
-                                (*startpp)++;
-                                continue;
-                        }
-                }
-                if (c == ';') {
-                        while ((*startpp <= endp) &&
-			       ((c = **startpp) != '\n'))
-					(*startpp)++;
-                        if (seendigit)
-                                break;
-                        continue;
-                }
-                if (!isdigit(c)) {
-                        if (c == ')' && seendigit) {
-                                (*startpp)--;
-                                break;
-                        }
-			return (-1);
-                }        
-                (*startpp)++;
-                n = n * 10 + (c - '0');
-                seendigit = 1;
-        }
-        return (n + m);
-}
-
-/*%
- * Allocate a resource record buffer & save rr info.
- */
-ns_updrec *
-res_mkupdrec(int section, const char *dname,
-	     u_int class, u_int type, u_long ttl) {
-	ns_updrec *rrecp = (ns_updrec *)calloc(1, sizeof(ns_updrec));
-
-	if (!rrecp || !(rrecp->r_dname = strdup(dname))) {
-		if (rrecp)
-			free((char *)rrecp);
-		return (NULL);
-	}
-	INIT_LINK(rrecp, r_link);
-	INIT_LINK(rrecp, r_glink);
- 	rrecp->r_class = (ns_class)class;
-	rrecp->r_type = (ns_type)type;
-	rrecp->r_ttl = ttl;
-	rrecp->r_section = (ns_sect)section;
-	return (rrecp);
-}
-
-/*%
- * Free a resource record buffer created by res_mkupdrec.
- */
-void
-res_freeupdrec(ns_updrec *rrecp) {
-	/* Note: freeing r_dp is the caller's responsibility. */
-	if (rrecp->r_dname != NULL)
-		free(rrecp->r_dname);
-	free(rrecp);
-}
-
-struct valuelist {
-	struct valuelist *	next;
-	struct valuelist *	prev;
-	char *			name;
-	char *			proto;
-	int			port;
-};
-static struct valuelist *servicelist, *protolist;
-
-static void
-res_buildservicelist() {
-	struct servent *sp;
-	struct valuelist *slp;
-
-#ifdef MAYBE_HESIOD
-	setservent(0);
-#else
-	setservent(1);
-#endif
-	while ((sp = getservent()) != NULL) {
-		slp = (struct valuelist *)malloc(sizeof(struct valuelist));
-		if (!slp)
-			break;
-		slp->name = strdup(sp->s_name);
-		slp->proto = strdup(sp->s_proto);
-		if ((slp->name == NULL) || (slp->proto == NULL)) {
-			if (slp->name) free(slp->name);
-			if (slp->proto) free(slp->proto);
-			free(slp);
-			break;
-		}
-		slp->port = ntohs((u_int16_t)sp->s_port);  /*%< host byt order */
-		slp->next = servicelist;
-		slp->prev = NULL;
-		if (servicelist)
-			servicelist->prev = slp;
-		servicelist = slp;
-	}
-	endservent();
-}
-
-void
-res_destroyservicelist() {
-	struct valuelist *slp, *slp_next;
-
-	for (slp = servicelist; slp != NULL; slp = slp_next) {
-		slp_next = slp->next;
-		free(slp->name);
-		free(slp->proto);
-		free(slp);
-	}
-	servicelist = (struct valuelist *)0;
-}
-
-void
-res_buildprotolist(void) {
-	struct protoent *pp;
-	struct valuelist *slp;
-
-#ifdef MAYBE_HESIOD
-	setprotoent(0);
-#else
-	setprotoent(1);
-#endif
-	while ((pp = getprotoent()) != NULL) {
-		slp = (struct valuelist *)malloc(sizeof(struct valuelist));
-		if (!slp)
-			break;
-		slp->name = strdup(pp->p_name);
-		if (slp->name == NULL) {
-			free(slp);
-			break;
-		}
-		slp->port = pp->p_proto;	/*%< host byte order */
-		slp->next = protolist;
-		slp->prev = NULL;
-		if (protolist)
-			protolist->prev = slp;
-		protolist = slp;
-	}
-	endprotoent();
-}
-
-void
-res_destroyprotolist(void) {
-	struct valuelist *plp, *plp_next;
-
-	for (plp = protolist; plp != NULL; plp = plp_next) {
-		plp_next = plp->next;
-		free(plp->name);
-		free(plp);
-	}
-	protolist = (struct valuelist *)0;
-}
-
-static int
-findservice(const char *s, struct valuelist **list) {
-	struct valuelist *lp = *list;
-	int n;
-
-	for (; lp != NULL; lp = lp->next)
-		if (strcasecmp(lp->name, s) == 0) {
-			if (lp != *list) {
-				lp->prev->next = lp->next;
-				if (lp->next)
-					lp->next->prev = lp->prev;
-				(*list)->prev = lp;
-				lp->next = *list;
-				*list = lp;
-			}
-			return (lp->port);	/*%< host byte order */
-		}
-	if (sscanf(s, "%d", &n) != 1 || n <= 0)
-		n = -1;
-	return (n);
-}
-
-/*%
- * Convert service name or (ascii) number to int.
- */
-int
-res_servicenumber(const char *p) {
-	if (servicelist == (struct valuelist *)0)
-		res_buildservicelist();
-	return (findservice(p, &servicelist));
-}
-
-/*%
- * Convert protocol name or (ascii) number to int.
- */
-int
-res_protocolnumber(const char *p) {
-	if (protolist == (struct valuelist *)0)
-		res_buildprotolist();
-	return (findservice(p, &protolist));
-}
-
-static struct servent *
-cgetservbyport(u_int16_t port, const char *proto) {	/*%< Host byte order. */
-	struct valuelist **list = &servicelist;
-	struct valuelist *lp = *list;
-	static struct servent serv;
-
-	port = ntohs(port);
-	for (; lp != NULL; lp = lp->next) {
-		if (port != (u_int16_t)lp->port)	/*%< Host byte order. */
-			continue;
-		if (strcasecmp(lp->proto, proto) == 0) {
-			if (lp != *list) {
-				lp->prev->next = lp->next;
-				if (lp->next)
-					lp->next->prev = lp->prev;
-				(*list)->prev = lp;
-				lp->next = *list;
-				*list = lp;
-			}
-			serv.s_name = lp->name;
-			serv.s_port = htons((u_int16_t)lp->port);
-			serv.s_proto = lp->proto;
-			return (&serv);
-		}
-	}
-	return (0);
-}
-
-static struct protoent *
-cgetprotobynumber(int proto) {				/*%< Host byte order. */
-	struct valuelist **list = &protolist;
-	struct valuelist *lp = *list;
-	static struct protoent prot;
-
-	for (; lp != NULL; lp = lp->next)
-		if (lp->port == proto) {		/*%< Host byte order. */
-			if (lp != *list) {
-				lp->prev->next = lp->next;
-				if (lp->next)
-					lp->next->prev = lp->prev;
-				(*list)->prev = lp;
-				lp->next = *list;
-				*list = lp;
-			}
-			prot.p_name = lp->name;
-			prot.p_proto = lp->port;	/*%< Host byte order. */
-			return (&prot);
-		}
-	return (0);
-}
-
-const char *
-res_protocolname(int num) {
-	static char number[8];
-	struct protoent *pp;
-
-	if (protolist == (struct valuelist *)0)
-		res_buildprotolist();
-	pp = cgetprotobynumber(num);
-	if (pp == 0)  {
-		(void) sprintf(number, "%d", num);
-		return (number);
-	}
-	return (pp->p_name);
-}
-
-const char *
-res_servicename(u_int16_t port, const char *proto) {	/*%< Host byte order. */
-	static char number[8];
-	struct servent *ss;
-
-	if (servicelist == (struct valuelist *)0)
-		res_buildservicelist();
-	ss = cgetservbyport(htons(port), proto);
-	if (ss == 0)  {
-		(void) sprintf(number, "%d", port);
-		return (number);
-	}
-	return (ss->s_name);
-}
diff --git a/contrib/bind9/lib/bind/resolv/res_mkupdate.h b/contrib/bind9/lib/bind/resolv/res_mkupdate.h
deleted file mode 100644
index 96c452d..0000000
--- a/contrib/bind9/lib/bind/resolv/res_mkupdate.h
+++ /dev/null
@@ -1,25 +0,0 @@
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1998,1999 by 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.
- */
-
-#ifndef _RES_MKUPDATE_H_
-#define _RES_MKUPDATE_H_
-
-__BEGIN_DECLS
-__END_DECLS
-
-#endif /* _RES_MKUPDATE_H_ */ 
-/*! \file */
diff --git a/contrib/bind9/lib/bind/resolv/res_private.h b/contrib/bind9/lib/bind/resolv/res_private.h
deleted file mode 100644
index 4e98157..0000000
--- a/contrib/bind9/lib/bind/resolv/res_private.h
+++ /dev/null
@@ -1,22 +0,0 @@
-#ifndef res_private_h
-#define res_private_h
-
-struct __res_state_ext {
-	union res_sockaddr_union nsaddrs[MAXNS];
-	struct sort_list {
-		int     af;
-		union {
-			struct in_addr  ina;
-			struct in6_addr in6a;
-		} addr, mask;
-	} sort_list[MAXRESOLVSORT];
-	char nsuffix[64];
-	char nsuffix2[64];
-};
-
-extern int
-res_ourserver_p(const res_state statp, const struct sockaddr *sa);
-
-#endif
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/resolv/res_query.c b/contrib/bind9/lib/bind/resolv/res_query.c
deleted file mode 100644
index 8c01cb0..0000000
--- a/contrib/bind9/lib/bind/resolv/res_query.c
+++ /dev/null
@@ -1,440 +0,0 @@
-/*
- * Copyright (c) 1988, 1993
- *    The Regents of the University of California.  All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- * 	This product includes software developed by the University of
- * 	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-/*
- * Portions Copyright (c) 1993 by Digital Equipment Corporation.
- * 
- * 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, and that
- * the name of Digital Equipment Corporation not be used in advertising or
- * publicity pertaining to distribution of the document or software without
- * specific, written prior permission.
- * 
- * THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
- * WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
- * OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
- * CORPORATION 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.
- */
-
-/*
- * Copyright (c) 2004 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
- * 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.
- */
-
-#if defined(LIBC_SCCS) && !defined(lint)
-static const char sccsid[] = "@(#)res_query.c	8.1 (Berkeley) 6/4/93";
-static const char rcsid[] = "$Id: res_query.c,v 1.7.18.2 2008/04/03 23:15:15 marka Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-#include "port_before.h"
-#include <sys/types.h>
-#include <sys/param.h>
-#include <netinet/in.h>
-#include <arpa/inet.h>
-#include <arpa/nameser.h>
-#include <ctype.h>
-#include <errno.h>
-#include <netdb.h>
-#include <resolv.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include "port_after.h"
-
-/* Options.  Leave them on. */
-#define DEBUG
-
-#if PACKETSZ > 1024
-#define MAXPACKET	PACKETSZ
-#else
-#define MAXPACKET	1024
-#endif
-
-/*%
- * Formulate a normal query, send, and await answer.
- * Returned answer is placed in supplied buffer "answer".
- * Perform preliminary check of answer, returning success only
- * if no error is indicated and the answer count is nonzero.
- * Return the size of the response on success, -1 on error.
- * Error number is left in H_ERRNO.
- *
- * Caller must parse answer and determine whether it answers the question.
- */
-int
-res_nquery(res_state statp,
-	   const char *name,	/*%< domain name */
-	   int class, int type,	/*%< class and type of query */
-	   u_char *answer,	/*%< buffer to put answer */
-	   int anslen)		/*%< size of answer buffer */
-{
-	u_char buf[MAXPACKET];
-	HEADER *hp = (HEADER *) answer;
-	u_int oflags;
-	u_char *rdata;
-	int n;
-
-	oflags = statp->_flags;
-
-again:
-	hp->rcode = NOERROR;	/*%< default */
-#ifdef DEBUG
-	if (statp->options & RES_DEBUG)
-		printf(";; res_query(%s, %d, %d)\n", name, class, type);
-#endif
-
-	n = res_nmkquery(statp, QUERY, name, class, type, NULL, 0, NULL,
-			 buf, sizeof(buf));
-#ifdef RES_USE_EDNS0
-	if (n > 0 && (statp->_flags & RES_F_EDNS0ERR) == 0 &&
-	    (statp->options & (RES_USE_EDNS0|RES_USE_DNSSEC|RES_NSID))) {
-		n = res_nopt(statp, n, buf, sizeof(buf), anslen);
-		rdata = &buf[n];
-		if (n > 0 && (statp->options & RES_NSID) != 0U) {
-			n = res_nopt_rdata(statp, n, buf, sizeof(buf), rdata,
-					   NS_OPT_NSID, 0, NULL);
-		}
-	}
-#endif
-	if (n <= 0) {
-#ifdef DEBUG
-		if (statp->options & RES_DEBUG)
-			printf(";; res_query: mkquery failed\n");
-#endif
-		RES_SET_H_ERRNO(statp, NO_RECOVERY);
-		return (n);
-	}
-
-	n = res_nsend(statp, buf, n, answer, anslen);
-	if (n < 0) {
-#ifdef RES_USE_EDNS0
-		/* if the query choked with EDNS0, retry without EDNS0 */
-		if ((statp->options & (RES_USE_EDNS0|RES_USE_DNSSEC)) != 0U &&
-		    ((oflags ^ statp->_flags) & RES_F_EDNS0ERR) != 0) {
-			statp->_flags |= RES_F_EDNS0ERR;
-			if (statp->options & RES_DEBUG)
-				printf(";; res_nquery: retry without EDNS0\n");
-			goto again;
-		}
-#endif
-#ifdef DEBUG
-		if (statp->options & RES_DEBUG)
-			printf(";; res_query: send error\n");
-#endif
-		RES_SET_H_ERRNO(statp, TRY_AGAIN);
-		return (n);
-	}
-
-	if (hp->rcode != NOERROR || ntohs(hp->ancount) == 0) {
-#ifdef DEBUG
-		if (statp->options & RES_DEBUG)
-			printf(";; rcode = (%s), counts = an:%d ns:%d ar:%d\n",
-			       p_rcode(hp->rcode),
-			       ntohs(hp->ancount),
-			       ntohs(hp->nscount),
-			       ntohs(hp->arcount));
-#endif
-		switch (hp->rcode) {
-		case NXDOMAIN:
-			RES_SET_H_ERRNO(statp, HOST_NOT_FOUND);
-			break;
-		case SERVFAIL:
-			RES_SET_H_ERRNO(statp, TRY_AGAIN);
-			break;
-		case NOERROR:
-			RES_SET_H_ERRNO(statp, NO_DATA);
-			break;
-		case FORMERR:
-		case NOTIMP:
-		case REFUSED:
-		default:
-			RES_SET_H_ERRNO(statp, NO_RECOVERY);
-			break;
-		}
-		return (-1);
-	}
-	return (n);
-}
-
-/*%
- * Formulate a normal query, send, and retrieve answer in supplied buffer.
- * Return the size of the response on success, -1 on error.
- * If enabled, implement search rules until answer or unrecoverable failure
- * is detected.  Error code, if any, is left in H_ERRNO.
- */
-int
-res_nsearch(res_state statp,
-	    const char *name,	/*%< domain name */
-	    int class, int type,	/*%< class and type of query */
-	    u_char *answer,	/*%< buffer to put answer */
-	    int anslen)		/*%< size of answer */
-{
-	const char *cp, * const *domain;
-	HEADER *hp = (HEADER *) answer;
-	char tmp[NS_MAXDNAME];
-	u_int dots;
-	int trailing_dot, ret, saved_herrno;
-	int got_nodata = 0, got_servfail = 0, root_on_list = 0;
-	int tried_as_is = 0;
-	int searched = 0;
-
-	errno = 0;
-	RES_SET_H_ERRNO(statp, HOST_NOT_FOUND);  /*%< True if we never query. */
-	dots = 0;
-	for (cp = name; *cp != '\0'; cp++)
-		dots += (*cp == '.');
-	trailing_dot = 0;
-	if (cp > name && *--cp == '.')
-		trailing_dot++;
-
-	/* If there aren't any dots, it could be a user-level alias. */
-	if (!dots && (cp = res_hostalias(statp, name, tmp, sizeof tmp))!= NULL)
-		return (res_nquery(statp, cp, class, type, answer, anslen));
-
-	/*
-	 * If there are enough dots in the name, let's just give it a
-	 * try 'as is'. The threshold can be set with the "ndots" option.
-	 * Also, query 'as is', if there is a trailing dot in the name.
-	 */
-	saved_herrno = -1;
-	if (dots >= statp->ndots || trailing_dot) {
-		ret = res_nquerydomain(statp, name, NULL, class, type,
-					 answer, anslen);
-		if (ret > 0 || trailing_dot)
-			return (ret);
-		saved_herrno = statp->res_h_errno;
-		tried_as_is++;
-	}
-
-	/*
-	 * We do at least one level of search if
-	 *	- there is no dot and RES_DEFNAME is set, or
-	 *	- there is at least one dot, there is no trailing dot,
-	 *	  and RES_DNSRCH is set.
-	 */
-	if ((!dots && (statp->options & RES_DEFNAMES) != 0U) ||
-	    (dots && !trailing_dot && (statp->options & RES_DNSRCH) != 0U)) {
-		int done = 0;
-
-		for (domain = (const char * const *)statp->dnsrch;
-		     *domain && !done;
-		     domain++) {
-			searched = 1;
-
-			if (domain[0][0] == '\0' ||
-			    (domain[0][0] == '.' && domain[0][1] == '\0'))
-				root_on_list++;
-
-			ret = res_nquerydomain(statp, name, *domain,
-					       class, type,
-					       answer, anslen);
-			if (ret > 0)
-				return (ret);
-
-			/*
-			 * If no server present, give up.
-			 * If name isn't found in this domain,
-			 * keep trying higher domains in the search list
-			 * (if that's enabled).
-			 * On a NO_DATA error, keep trying, otherwise
-			 * a wildcard entry of another type could keep us
-			 * from finding this entry higher in the domain.
-			 * If we get some other error (negative answer or
-			 * server failure), then stop searching up,
-			 * but try the input name below in case it's
-			 * fully-qualified.
-			 */
-			if (errno == ECONNREFUSED) {
-				RES_SET_H_ERRNO(statp, TRY_AGAIN);
-				return (-1);
-			}
-
-			switch (statp->res_h_errno) {
-			case NO_DATA:
-				got_nodata++;
-				/* FALLTHROUGH */
-			case HOST_NOT_FOUND:
-				/* keep trying */
-				break;
-			case TRY_AGAIN:
-				if (hp->rcode == SERVFAIL) {
-					/* try next search element, if any */
-					got_servfail++;
-					break;
-				}
-				/* FALLTHROUGH */
-			default:
-				/* anything else implies that we're done */
-				done++;
-			}
-
-			/* if we got here for some reason other than DNSRCH,
-			 * we only wanted one iteration of the loop, so stop.
-			 */
-			if ((statp->options & RES_DNSRCH) == 0U)
-				done++;
-		}
-	}
-
-	/*
-	 * If the query has not already been tried as is then try it
-	 * unless RES_NOTLDQUERY is set and there were no dots.
-	 */
-	if ((dots || !searched || (statp->options & RES_NOTLDQUERY) == 0U) &&
-	    !(tried_as_is || root_on_list)) {
-		ret = res_nquerydomain(statp, name, NULL, class, type,
-				       answer, anslen);
-		if (ret > 0)
-			return (ret);
-	}
-
-	/* if we got here, we didn't satisfy the search.
-	 * if we did an initial full query, return that query's H_ERRNO
-	 * (note that we wouldn't be here if that query had succeeded).
-	 * else if we ever got a nodata, send that back as the reason.
-	 * else send back meaningless H_ERRNO, that being the one from
-	 * the last DNSRCH we did.
-	 */
-	if (saved_herrno != -1)
-		RES_SET_H_ERRNO(statp, saved_herrno);
-	else if (got_nodata)
-		RES_SET_H_ERRNO(statp, NO_DATA);
-	else if (got_servfail)
-		RES_SET_H_ERRNO(statp, TRY_AGAIN);
-	return (-1);
-}
-
-/*%
- * Perform a call on res_query on the concatenation of name and domain,
- * removing a trailing dot from name if domain is NULL.
- */
-int
-res_nquerydomain(res_state statp,
-	    const char *name,
-	    const char *domain,
-	    int class, int type,	/*%< class and type of query */
-	    u_char *answer,		/*%< buffer to put answer */
-	    int anslen)		/*%< size of answer */
-{
-	char nbuf[MAXDNAME];
-	const char *longname = nbuf;
-	int n, d;
-
-#ifdef DEBUG
-	if (statp->options & RES_DEBUG)
-		printf(";; res_nquerydomain(%s, %s, %d, %d)\n",
-		       name, domain?domain:"<Nil>", class, type);
-#endif
-	if (domain == NULL) {
-		/*
-		 * Check for trailing '.';
-		 * copy without '.' if present.
-		 */
-		n = strlen(name);
-		if (n >= MAXDNAME) {
-			RES_SET_H_ERRNO(statp, NO_RECOVERY);
-			return (-1);
-		}
-		n--;
-		if (n >= 0 && name[n] == '.') {
-			strncpy(nbuf, name, n);
-			nbuf[n] = '\0';
-		} else
-			longname = name;
-	} else {
-		n = strlen(name);
-		d = strlen(domain);
-		if (n + d + 1 >= MAXDNAME) {
-			RES_SET_H_ERRNO(statp, NO_RECOVERY);
-			return (-1);
-		}
-		sprintf(nbuf, "%s.%s", name, domain);
-	}
-	return (res_nquery(statp, longname, class, type, answer, anslen));
-}
-
-const char *
-res_hostalias(const res_state statp, const char *name, char *dst, size_t siz) {
-	char *file, *cp1, *cp2;
-	char buf[BUFSIZ];
-	FILE *fp;
-
-	if (statp->options & RES_NOALIASES)
-		return (NULL);
-	file = getenv("HOSTALIASES");
-	if (file == NULL || (fp = fopen(file, "r")) == NULL)
-		return (NULL);
-	setbuf(fp, NULL);
-	buf[sizeof(buf) - 1] = '\0';
-	while (fgets(buf, sizeof(buf), fp)) {
-		for (cp1 = buf; *cp1 && !isspace((unsigned char)*cp1); ++cp1)
-			;
-		if (!*cp1)
-			break;
-		*cp1 = '\0';
-		if (ns_samename(buf, name) == 1) {
-			while (isspace((unsigned char)*++cp1))
-				;
-			if (!*cp1)
-				break;
-			for (cp2 = cp1 + 1; *cp2 &&
-			     !isspace((unsigned char)*cp2); ++cp2)
-				;
-			*cp2 = '\0';
-			strncpy(dst, cp1, siz - 1);
-			dst[siz - 1] = '\0';
-			fclose(fp);
-			return (dst);
-		}
-	}
-	fclose(fp);
-	return (NULL);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/resolv/res_send.c b/contrib/bind9/lib/bind/resolv/res_send.c
deleted file mode 100644
index 5154fe2..0000000
--- a/contrib/bind9/lib/bind/resolv/res_send.c
+++ /dev/null
@@ -1,1108 +0,0 @@
-/*
- * Copyright (c) 1985, 1989, 1993
- *    The Regents of the University of California.  All rights reserved.
- * 
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *    notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *    notice, this list of conditions and the following disclaimer in the
- *    documentation and/or other materials provided with the distribution.
- * 3. All advertising materials mentioning features or use of this software
- *    must display the following acknowledgement:
- * 	This product includes software developed by the University of
- * 	California, Berkeley and its contributors.
- * 4. Neither the name of the University nor the names of its contributors
- *    may be used to endorse or promote products derived from this software
- *    without specific prior written permission.
- * 
- * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
- * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
- * SUCH DAMAGE.
- */
-
-/*
- * Portions Copyright (c) 1993 by Digital Equipment Corporation.
- * 
- * 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, and that
- * the name of Digital Equipment Corporation not be used in advertising or
- * publicity pertaining to distribution of the document or software without
- * specific, written prior permission.
- * 
- * THE SOFTWARE IS PROVIDED "AS IS" AND DIGITAL EQUIPMENT CORP. DISCLAIMS ALL
- * WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES
- * OF MERCHANTABILITY AND FITNESS.   IN NO EVENT SHALL DIGITAL EQUIPMENT
- * CORPORATION 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.
- */
-
-/*
- * 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
- * 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.
- */
-
-#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.9.18.10 2008/01/27 02:06:26 marka Exp $";
-#endif /* LIBC_SCCS and not lint */
-
-/*! \file
- * \brief
- * Send query to name server and wait for reply.
- */
-
-#include "port_before.h"
-#include "fd_setsize.h"
-
-#include <sys/types.h>
-#include <sys/param.h>
-#include <sys/time.h>
-#include <sys/socket.h>
-#include <sys/uio.h>
-
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <arpa/inet.h>
-
-#include <errno.h>
-#include <netdb.h>
-#include <resolv.h>
-#include <signal.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <unistd.h>
-
-#include <isc/eventlib.h>
-
-#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"
-#include "res_private.h"
-
-#define EXT(res) ((res)->_u._ext)
-
-#ifndef USE_POLL
-static const int highestFD = FD_SETSIZE - 1;
-#else
-static int highestFD = 0;
-#endif
-
-/* Forward. */
-
-static int		get_salen __P((const struct sockaddr *));
-static struct sockaddr * get_nsaddr __P((res_state, size_t));
-static int		send_vc(res_state, const u_char *, int,
-				u_char *, int, int *, int);
-static int		send_dg(res_state, const u_char *, int,
-				u_char *, int, int *, int, int,
-				int *, int *);
-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 *);
-#if defined(NEED_PSELECT) && !defined(USE_POLL)
-static int		pselect(int, void *, void *, void *,
-				struct timespec *,
-				const sigset_t *);
-#endif
-void res_pquery(const res_state, const u_char *, int, FILE *);
-
-static const int niflags = NI_NUMERICHOST | NI_NUMERICSERV;
-
-/* Public. */
-
-/*%
- *	looks up "ina" in _res.ns_addr_list[]
- *
- * returns:
- *\li	0  : not found
- *\li	>0 : found
- *
- * author:
- *\li	paul vixie, 29may94
- */
-int
-res_ourserver_p(const res_state statp, const struct sockaddr *sa) {
-	const struct sockaddr_in *inp, *srv;
-	const struct sockaddr_in6 *in6p, *srv6;
-	int ns;
-
-	switch (sa->sa_family) {
-	case AF_INET:
-		inp = (const struct sockaddr_in *)sa;
-		for (ns = 0;  ns < statp->nscount;  ns++) {
-			srv = (struct sockaddr_in *)get_nsaddr(statp, ns);
-			if (srv->sin_family == inp->sin_family &&
-			    srv->sin_port == inp->sin_port &&
-			    (srv->sin_addr.s_addr == INADDR_ANY ||
-			     srv->sin_addr.s_addr == inp->sin_addr.s_addr))
-				return (1);
-		}
-		break;
-	case AF_INET6:
-		if (EXT(statp).ext == NULL)
-			break;
-		in6p = (const struct sockaddr_in6 *)sa;
-		for (ns = 0;  ns < statp->nscount;  ns++) {
-			srv6 = (struct sockaddr_in6 *)get_nsaddr(statp, ns);
-			if (srv6->sin6_family == in6p->sin6_family &&
-			    srv6->sin6_port == in6p->sin6_port &&
-#ifdef HAVE_SIN6_SCOPE_ID
-			    (srv6->sin6_scope_id == 0 ||
-			     srv6->sin6_scope_id == in6p->sin6_scope_id) &&
-#endif
-			    (IN6_IS_ADDR_UNSPECIFIED(&srv6->sin6_addr) ||
-			     IN6_ARE_ADDR_EQUAL(&srv6->sin6_addr, &in6p->sin6_addr)))
-				return (1);
-		}
-		break;
-	default:
-		break;
-	}
-	return (0);
-}
-
-/*%
- *	look for (name,type,class) in the query section of packet (buf,eom)
- *
- * requires:
- *\li	buf + HFIXEDSZ <= eom
- *
- * returns:
- *\li	-1 : format error
- *\li	0  : not found
- *\li	>0 : found
- *
- * author:
- *\li	paul vixie, 29may94
- */
-int
-res_nameinquery(const char *name, int type, int class,
-		const u_char *buf, const u_char *eom)
-{
-	const u_char *cp = buf + HFIXEDSZ;
-	int qdcount = ntohs(((const HEADER*)buf)->qdcount);
-
-	while (qdcount-- > 0) {
-		char tname[MAXDNAME+1];
-		int n, ttype, tclass;
-
-		n = dn_expand(buf, eom, cp, tname, sizeof tname);
-		if (n < 0)
-			return (-1);
-		cp += n;
-		if (cp + 2 * INT16SZ > eom)
-			return (-1);
-		ttype = ns_get16(cp); cp += INT16SZ;
-		tclass = ns_get16(cp); cp += INT16SZ;
-		if (ttype == type && tclass == class &&
-		    ns_samename(tname, name) == 1)
-			return (1);
-	}
-	return (0);
-}
-
-/*%
- *	is there a 1:1 mapping of (name,type,class)
- *	in (buf1,eom1) and (buf2,eom2)?
- *
- * returns:
- *\li	-1 : format error
- *\li	0  : not a 1:1 mapping
- *\li	>0 : is a 1:1 mapping
- *
- * author:
- *\li	paul vixie, 29may94
- */
-int
-res_queriesmatch(const u_char *buf1, const u_char *eom1,
-		 const u_char *buf2, const u_char *eom2)
-{
-	const u_char *cp = buf1 + HFIXEDSZ;
-	int qdcount = ntohs(((const HEADER*)buf1)->qdcount);
-
-	if (buf1 + HFIXEDSZ > eom1 || buf2 + HFIXEDSZ > eom2)
-		return (-1);
-
-	/*
-	 * Only header section present in replies to
-	 * dynamic update packets.
-	 */
-	if ((((const HEADER *)buf1)->opcode == ns_o_update) &&
-	    (((const HEADER *)buf2)->opcode == ns_o_update))
-		return (1);
-
-	if (qdcount != ntohs(((const HEADER*)buf2)->qdcount))
-		return (0);
-	while (qdcount-- > 0) {
-		char tname[MAXDNAME+1];
-		int n, ttype, tclass;
-
-		n = dn_expand(buf1, eom1, cp, tname, sizeof tname);
-		if (n < 0)
-			return (-1);
-		cp += n;
-		if (cp + 2 * INT16SZ > eom1)
-			return (-1);
-		ttype = ns_get16(cp);	cp += INT16SZ;
-		tclass = ns_get16(cp); cp += INT16SZ;
-		if (!res_nameinquery(tname, ttype, tclass, buf2, eom2))
-			return (0);
-	}
-	return (1);
-}
-
-int
-res_nsend(res_state statp,
-	  const u_char *buf, int buflen, u_char *ans, int anssiz)
-{
-	int gotsomewhere, terrno, tries, v_circuit, resplen, ns, n;
-	char abuf[NI_MAXHOST];
-
-#ifdef USE_POLL
-	highestFD = sysconf(_SC_OPEN_MAX) - 1;
-#endif
-
-	/* No name servers or res_init() failure */
-	if (statp->nscount == 0 || EXT(statp).ext == NULL) {
-		errno = ESRCH;
-		return (-1);
-	}
-	if (anssiz < HFIXEDSZ) {
-		errno = EINVAL;
-		return (-1);
-	}
-	DprintQ((statp->options & RES_DEBUG) || (statp->pfcode & RES_PRF_QUERY),
-		(stdout, ";; res_send()\n"), buf, buflen);
-	v_circuit = (statp->options & RES_USEVC) || buflen > PACKETSZ;
-	gotsomewhere = 0;
-	terrno = ETIMEDOUT;
-
-	/*
-	 * If the ns_addr_list in the resolver context has changed, then
-	 * invalidate our cached copy and the associated timing data.
-	 */
-	if (EXT(statp).nscount != 0) {
-		int needclose = 0;
-		struct sockaddr_storage peer;
-		ISC_SOCKLEN_T peerlen;
-
-		if (EXT(statp).nscount != statp->nscount)
-			needclose++;
-		else
-			for (ns = 0; ns < statp->nscount; ns++) {
-				if (statp->nsaddr_list[ns].sin_family &&
-				    !sock_eq((struct sockaddr *)&statp->nsaddr_list[ns],
-					     (struct sockaddr *)&EXT(statp).ext->nsaddrs[ns])) {
-					needclose++;
-					break;
-				}
-
-				if (EXT(statp).nssocks[ns] == -1)
-					continue;
-				peerlen = sizeof(peer);
-				if (getsockname(EXT(statp).nssocks[ns],
-				    (struct sockaddr *)&peer, &peerlen) < 0) {
-					needclose++;
-					break;
-				}
-				if (!sock_eq((struct sockaddr *)&peer,
-				    get_nsaddr(statp, ns))) {
-					needclose++;
-					break;
-				}
-			}
-		if (needclose) {
-			res_nclose(statp);
-			EXT(statp).nscount = 0;
-		}
-	}
-
-	/*
-	 * Maybe initialize our private copy of the ns_addr_list.
-	 */
-	if (EXT(statp).nscount == 0) {
-		for (ns = 0; ns < statp->nscount; ns++) {
-			EXT(statp).nstimes[ns] = RES_MAXTIME;
-			EXT(statp).nssocks[ns] = -1;
-			if (!statp->nsaddr_list[ns].sin_family)
-				continue;
-			EXT(statp).ext->nsaddrs[ns].sin =
-				 statp->nsaddr_list[ns];
-		}
-		EXT(statp).nscount = statp->nscount;
-	}
-
-	/*
-	 * Some resolvers want to even out the load on their nameservers.
-	 * Note that RES_BLAST overrides RES_ROTATE.
-	 */
-	if ((statp->options & RES_ROTATE) != 0U &&
-	    (statp->options & RES_BLAST) == 0U) {
-		union res_sockaddr_union inu;
-		struct sockaddr_in ina;
-		int lastns = statp->nscount - 1;
-		int fd;
-		u_int16_t nstime;
-
-		if (EXT(statp).ext != NULL)
-			inu = EXT(statp).ext->nsaddrs[0];
-		ina = statp->nsaddr_list[0];
-		fd = EXT(statp).nssocks[0];
-		nstime = EXT(statp).nstimes[0];
-		for (ns = 0; ns < lastns; ns++) {
-			if (EXT(statp).ext != NULL)
-                                EXT(statp).ext->nsaddrs[ns] = 
-					EXT(statp).ext->nsaddrs[ns + 1];
-			statp->nsaddr_list[ns] = statp->nsaddr_list[ns + 1];
-			EXT(statp).nssocks[ns] = EXT(statp).nssocks[ns + 1];
-			EXT(statp).nstimes[ns] = EXT(statp).nstimes[ns + 1];
-		}
-		if (EXT(statp).ext != NULL)
-			EXT(statp).ext->nsaddrs[lastns] = inu;
-		statp->nsaddr_list[lastns] = ina;
-		EXT(statp).nssocks[lastns] = fd;
-		EXT(statp).nstimes[lastns] = nstime;
-	}
-
-	/*
-	 * Send request, RETRY times, or until successful.
-	 */
-	for (tries = 0; tries < statp->retry; tries++) {
-	    for (ns = 0; ns < statp->nscount; ns++) {
-		struct sockaddr *nsap;
-		int nsaplen;
-		nsap = get_nsaddr(statp, ns);
-		nsaplen = get_salen(nsap);
-		statp->_flags &= ~RES_F_LASTMASK;
-		statp->_flags |= (ns << RES_F_LASTSHIFT);
- same_ns:
-		if (statp->qhook) {
-			int done = 0, loops = 0;
-
-			do {
-				res_sendhookact act;
-
-				act = (*statp->qhook)(&nsap, &buf, &buflen,
-						      ans, anssiz, &resplen);
-				switch (act) {
-				case res_goahead:
-					done = 1;
-					break;
-				case res_nextns:
-					res_nclose(statp);
-					goto next_ns;
-				case res_done:
-					return (resplen);
-				case res_modified:
-					/* give the hook another try */
-					if (++loops < 42) /*doug adams*/
-						break;
-					/*FALLTHROUGH*/
-				case res_error:
-					/*FALLTHROUGH*/
-				default:
-					goto fail;
-				}
-			} while (!done);
-		}
-
-		Dprint(((statp->options & RES_DEBUG) &&
-			getnameinfo(nsap, nsaplen, abuf, sizeof(abuf),
-				    NULL, 0, niflags) == 0),
-		       (stdout, ";; Querying server (# %d) address = %s\n",
-			ns + 1, abuf));
-
-
-		if (v_circuit) {
-			/* Use VC; at most one attempt per server. */
-			tries = statp->retry;
-			n = send_vc(statp, buf, buflen, ans, anssiz, &terrno,
-				    ns);
-			if (n < 0)
-				goto fail;
-			if (n == 0)
-				goto next_ns;
-			resplen = n;
-		} else {
-			/* Use datagrams. */
-			n = send_dg(statp, buf, buflen, ans, anssiz, &terrno,
-				    ns, tries, &v_circuit, &gotsomewhere);
-			if (n < 0)
-				goto fail;
-			if (n == 0)
-				goto next_ns;
-			if (v_circuit)
-				goto same_ns;
-			resplen = n;
-		}
-
-		Dprint((statp->options & RES_DEBUG) ||
-		       ((statp->pfcode & RES_PRF_REPLY) &&
-			(statp->pfcode & RES_PRF_HEAD1)),
-		       (stdout, ";; got answer:\n"));
-
-		DprintQ((statp->options & RES_DEBUG) ||
-			(statp->pfcode & RES_PRF_REPLY),
-			(stdout, "%s", ""),
-			ans, (resplen > anssiz) ? anssiz : resplen);
-
-		/*
-		 * If we have temporarily opened a virtual circuit,
-		 * or if we haven't been asked to keep a socket open,
-		 * close the socket.
-		 */
-		if ((v_circuit && (statp->options & RES_USEVC) == 0U) ||
-		    (statp->options & RES_STAYOPEN) == 0U) {
-			res_nclose(statp);
-		}
-		if (statp->rhook) {
-			int done = 0, loops = 0;
-
-			do {
-				res_sendhookact act;
-
-				act = (*statp->rhook)(nsap, buf, buflen,
-						      ans, anssiz, &resplen);
-				switch (act) {
-				case res_goahead:
-				case res_done:
-					done = 1;
-					break;
-				case res_nextns:
-					res_nclose(statp);
-					goto next_ns;
-				case res_modified:
-					/* give the hook another try */
-					if (++loops < 42) /*doug adams*/
-						break;
-					/*FALLTHROUGH*/
-				case res_error:
-					/*FALLTHROUGH*/
-				default:
-					goto fail;
-				}
-			} while (!done);
-
-		}
-		return (resplen);
- next_ns: ;
-	   } /*foreach ns*/
-	} /*foreach retry*/
-	res_nclose(statp);
-	if (!v_circuit) {
-		if (!gotsomewhere)
-			errno = ECONNREFUSED;	/*%< no nameservers found */
-		else
-			errno = ETIMEDOUT;	/*%< no answer obtained */
-	} else
-		errno = terrno;
-	return (-1);
- fail:
-	res_nclose(statp);
-	return (-1);
-}
-
-/* Private */
-
-static int
-get_salen(sa)
-	const struct sockaddr *sa;
-{
-
-#ifdef HAVE_SA_LEN
-	/* There are people do not set sa_len.  Be forgiving to them. */
-	if (sa->sa_len)
-		return (sa->sa_len);
-#endif
-
-	if (sa->sa_family == AF_INET)
-		return (sizeof(struct sockaddr_in));
-	else if (sa->sa_family == AF_INET6)
-		return (sizeof(struct sockaddr_in6));
-	else
-		return (0);	/*%< unknown, die on connect */
-}
-
-/*%
- * pick appropriate nsaddr_list for use.  see res_init() for initialization.
- */
-static struct sockaddr *
-get_nsaddr(statp, n)
-	res_state statp;
-	size_t n;
-{
-
-	if (!statp->nsaddr_list[n].sin_family && EXT(statp).ext) {
-		/*
-		 * - EXT(statp).ext->nsaddrs[n] holds an address that is larger
-		 *   than struct sockaddr, and
-		 * - user code did not update statp->nsaddr_list[n].
-		 */
-		return (struct sockaddr *)(void *)&EXT(statp).ext->nsaddrs[n];
-	} else {
-		/*
-		 * - user code updated statp->nsaddr_list[n], or
-		 * - statp->nsaddr_list[n] has the same content as
-		 *   EXT(statp).ext->nsaddrs[n].
-		 */
-		return (struct sockaddr *)(void *)&statp->nsaddr_list[n];
-	}
-}
-
-static int
-send_vc(res_state statp,
-	const u_char *buf, int buflen, u_char *ans, int anssiz,
-	int *terrno, int ns)
-{
-	const HEADER *hp = (const HEADER *) buf;
-	HEADER *anhp = (HEADER *) ans;
-	struct sockaddr *nsap;
-	int nsaplen;
-	int truncating, connreset, resplen, n;
-	struct iovec iov[2];
-	u_short len;
-	u_char *cp;
-	void *tmp;
-#ifdef SO_NOSIGPIPE
-	int on = 1;
-#endif
-
-	nsap = get_nsaddr(statp, ns);
-	nsaplen = get_salen(nsap);
-
-	connreset = 0;
- same_ns:
-	truncating = 0;
-
-	/* Are we still talking to whom we want to talk to? */
-	if (statp->_vcsock >= 0 && (statp->_flags & RES_F_VC) != 0) {
-		struct sockaddr_storage peer;
-		ISC_SOCKLEN_T size = sizeof peer;
-
-		if (getpeername(statp->_vcsock,
-				(struct sockaddr *)&peer, &size) < 0 ||
-		    !sock_eq((struct sockaddr *)&peer, nsap)) {
-			res_nclose(statp);
-			statp->_flags &= ~RES_F_VC;
-		}
-	}
-
-	if (statp->_vcsock < 0 || (statp->_flags & RES_F_VC) == 0) {
-		if (statp->_vcsock >= 0)
-			res_nclose(statp);
-
-		statp->_vcsock = socket(nsap->sa_family, SOCK_STREAM, 0);
-		if (statp->_vcsock > highestFD) {
-			res_nclose(statp);
-			errno = ENOTSOCK;
-		}
-		if (statp->_vcsock < 0) {
-			switch (errno) {
-			case EPROTONOSUPPORT:
-#ifdef EPFNOSUPPORT
-			case EPFNOSUPPORT:
-#endif
-			case EAFNOSUPPORT:
-				Perror(statp, stderr, "socket(vc)", errno);
-				return (0);
-			default:
-				*terrno = errno;
-				Perror(statp, stderr, "socket(vc)", errno);
-				return (-1);
-			}
-		}
-#ifdef SO_NOSIGPIPE
-		/*
-		 * Disable generation of SIGPIPE when writing to a closed
-		 * socket.  Write should return -1 and set errno to EPIPE
-		 * instead. 
-		 *
-		 * Push on even if setsockopt(SO_NOSIGPIPE) fails.
-		 */
-		(void)setsockopt(statp->_vcsock, SOL_SOCKET, SO_NOSIGPIPE, &on,
-			         sizeof(on));
-#endif
-		errno = 0;
-		if (connect(statp->_vcsock, nsap, nsaplen) < 0) {
-			*terrno = errno;
-			Aerror(statp, stderr, "connect/vc", errno, nsap,
-			    nsaplen);
-			res_nclose(statp);
-			return (0);
-		}
-		statp->_flags |= RES_F_VC;
-	}
-
-	/*
-	 * Send length & message
-	 */
-	ns_put16((u_short)buflen, (u_char*)&len);
-	iov[0] = evConsIovec(&len, INT16SZ);
-	DE_CONST(buf, tmp);
-	iov[1] = evConsIovec(tmp, buflen);
-	if (writev(statp->_vcsock, iov, 2) != (INT16SZ + buflen)) {
-		*terrno = errno;
-		Perror(statp, stderr, "write failed", errno);
-		res_nclose(statp);
-		return (0);
-	}
-	/*
-	 * Receive length & response
-	 */
- read_len:
-	cp = ans;
-	len = INT16SZ;
-	while ((n = read(statp->_vcsock, (char *)cp, (int)len)) > 0) {
-		cp += n;
-		if ((len -= n) == 0)
-			break;
-	}
-	if (n <= 0) {
-		*terrno = errno;
-		Perror(statp, stderr, "read failed", errno);
-		res_nclose(statp);
-		/*
-		 * A long running process might get its TCP
-		 * connection reset if the remote server was
-		 * restarted.  Requery the server instead of
-		 * trying a new one.  When there is only one
-		 * server, this means that a query might work
-		 * instead of failing.  We only allow one reset
-		 * per query to prevent looping.
-		 */
-		if (*terrno == ECONNRESET && !connreset) {
-			connreset = 1;
-			res_nclose(statp);
-			goto same_ns;
-		}
-		res_nclose(statp);
-		return (0);
-	}
-	resplen = ns_get16(ans);
-	if (resplen > anssiz) {
-		Dprint(statp->options & RES_DEBUG,
-		       (stdout, ";; response truncated\n")
-		       );
-		truncating = 1;
-		len = anssiz;
-	} else
-		len = resplen;
-	if (len < HFIXEDSZ) {
-		/*
-		 * Undersized message.
-		 */
-		Dprint(statp->options & RES_DEBUG,
-		       (stdout, ";; undersized: %d\n", len));
-		*terrno = EMSGSIZE;
-		res_nclose(statp);
-		return (0);
-	}
-	cp = ans;
-	while (len != 0 && (n = read(statp->_vcsock, (char *)cp, (int)len)) > 0){
-		cp += n;
-		len -= n;
-	}
-	if (n <= 0) {
-		*terrno = errno;
-		Perror(statp, stderr, "read(vc)", errno);
-		res_nclose(statp);
-		return (0);
-	}
-	if (truncating) {
-		/*
-		 * Flush rest of answer so connection stays in synch.
-		 */
-		anhp->tc = 1;
-		len = resplen - anssiz;
-		while (len != 0) {
-			char junk[PACKETSZ];
-
-			n = read(statp->_vcsock, junk,
-				 (len > sizeof junk) ? sizeof junk : len);
-			if (n > 0)
-				len -= n;
-			else
-				break;
-		}
-	}
-	/*
-	 * If the calling applicating has bailed out of
-	 * a previous call and failed to arrange to have
-	 * the circuit closed or the server has got
-	 * itself confused, then drop the packet and
-	 * wait for the correct one.
-	 */
-	if (hp->id != anhp->id) {
-		DprintQ((statp->options & RES_DEBUG) ||
-			(statp->pfcode & RES_PRF_REPLY),
-			(stdout, ";; old answer (unexpected):\n"),
-			ans, (resplen > anssiz) ? anssiz: resplen);
-		goto read_len;
-	}
-
-	/*
-	 * All is well, or the error is fatal.  Signal that the
-	 * next nameserver ought not be tried.
-	 */
-	return (resplen);
-}
-
-static int
-send_dg(res_state statp, const u_char *buf, int buflen, u_char *ans,
-	int anssiz, int *terrno, int ns, int tries, int *v_circuit,
-	int *gotsomewhere)
-{
-	const HEADER *hp = (const HEADER *) buf;
-	HEADER *anhp = (HEADER *) ans;
-	const struct sockaddr *nsap;
-	int nsaplen;
-	struct timespec now, timeout, finish;
-	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);
-	if (EXT(statp).nssocks[ns] == -1) {
-		EXT(statp).nssocks[ns] = socket(nsap->sa_family, SOCK_DGRAM, 0);
-		if (EXT(statp).nssocks[ns] > highestFD) {
-			res_nclose(statp);
-			errno = ENOTSOCK;
-		}
-		if (EXT(statp).nssocks[ns] < 0) {
-			switch (errno) {
-			case EPROTONOSUPPORT:
-#ifdef EPFNOSUPPORT
-			case EPFNOSUPPORT:
-#endif
-			case EAFNOSUPPORT:
-				Perror(statp, stderr, "socket(dg)", errno);
-				return (0);
-			default:
-				*terrno = errno;
-				Perror(statp, stderr, "socket(dg)", errno);
-				return (-1);
-			}
-		}
-#ifndef CANNOT_CONNECT_DGRAM
-		/*
-		 * On a 4.3BSD+ machine (client and server,
-		 * actually), sending to a nameserver datagram
-		 * port with no nameserver will cause an
-		 * ICMP port unreachable message to be returned.
-		 * If our datagram socket is "connected" to the
-		 * server, we get an ECONNREFUSED error on the next
-		 * socket operation, and select returns if the
-		 * error message is received.  We can thus detect
-		 * the absence of a nameserver without timing out.
-		 */
-		if (connect(EXT(statp).nssocks[ns], nsap, nsaplen) < 0) {
-			Aerror(statp, stderr, "connect(dg)", errno, nsap,
-			    nsaplen);
-			res_nclose(statp);
-			return (0);
-		}
-#endif /* !CANNOT_CONNECT_DGRAM */
-		Dprint(statp->options & RES_DEBUG,
-		       (stdout, ";; new DG socket\n"))
-	}
-	s = EXT(statp).nssocks[ns];
-#ifndef CANNOT_CONNECT_DGRAM
-	if (send(s, (const char*)buf, buflen, 0) != buflen) {
-		Perror(statp, stderr, "send", errno);
-		res_nclose(statp);
-		return (0);
-	}
-#else /* !CANNOT_CONNECT_DGRAM */
-	if (sendto(s, (const char*)buf, buflen, 0, nsap, nsaplen) != buflen)
-	{
-		Aerror(statp, stderr, "sendto", errno, nsap, nsaplen);
-		res_nclose(statp);
-		return (0);
-	}
-#endif /* !CANNOT_CONNECT_DGRAM */
-
-	/*
-	 * Wait for reply.
-	 */
-	seconds = (statp->retrans << tries);
-	if (ns > 0)
-		seconds /= statp->nscount;
-	if (seconds <= 0)
-		seconds = 1;
-	now = evNowTime();
-	timeout = evConsTime(seconds, 0);
-	finish = evAddTime(now, timeout);
-	goto nonow;
- wait:
-	now = evNowTime();
- nonow:
-#ifndef USE_POLL
-	FD_ZERO(&dsmask);
-	FD_SET(s, &dsmask);
-	if (evCmpTime(finish, now) > 0)
-		timeout = evSubTime(finish, now);
-	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;
-		return (0);
-	}
-	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);
-	}
-	errno = 0;
-	fromlen = sizeof(from);
-	resplen = recvfrom(s, (char*)ans, anssiz,0,
-			   (struct sockaddr *)&from, &fromlen);
-	if (resplen <= 0) {
-		Perror(statp, stderr, "recvfrom", errno);
-		res_nclose(statp);
-		return (0);
-	}
-	*gotsomewhere = 1;
-	if (resplen < HFIXEDSZ) {
-		/*
-		 * Undersized message.
-		 */
-		Dprint(statp->options & RES_DEBUG,
-		       (stdout, ";; undersized: %d\n",
-			resplen));
-		*terrno = EMSGSIZE;
-		res_nclose(statp);
-		return (0);
-	}
-	if (hp->id != anhp->id) {
-		/*
-		 * response from old query, ignore it.
-		 * XXX - potential security hazard could
-		 *	 be detected here.
-		 */
-		DprintQ((statp->options & RES_DEBUG) ||
-			(statp->pfcode & RES_PRF_REPLY),
-			(stdout, ";; old answer:\n"),
-			ans, (resplen > anssiz) ? anssiz : resplen);
-		goto wait;
-	}
-	if (!(statp->options & RES_INSECURE1) &&
-	    !res_ourserver_p(statp, (struct sockaddr *)&from)) {
-		/*
-		 * response from wrong server? ignore it.
-		 * XXX - potential security hazard could
-		 *	 be detected here.
-		 */
-		DprintQ((statp->options & RES_DEBUG) ||
-			(statp->pfcode & RES_PRF_REPLY),
-			(stdout, ";; not our server:\n"),
-			ans, (resplen > anssiz) ? anssiz : resplen);
-		goto wait;
-	}
-#ifdef RES_USE_EDNS0
-	if (anhp->rcode == FORMERR && (statp->options & RES_USE_EDNS0) != 0U) {
-		/*
-		 * Do not retry if the server do not understand EDNS0.
-		 * The case has to be captured here, as FORMERR packet do not
-		 * carry query section, hence res_queriesmatch() returns 0.
-		 */
-		DprintQ(statp->options & RES_DEBUG,
-			(stdout, "server rejected query with EDNS0:\n"),
-			ans, (resplen > anssiz) ? anssiz : resplen);
-		/* record the error */
-		statp->_flags |= RES_F_EDNS0ERR;
-		res_nclose(statp);
-		return (0);
-	}
-#endif
-	if (!(statp->options & RES_INSECURE2) &&
-	    !res_queriesmatch(buf, buf + buflen,
-			      ans, ans + anssiz)) {
-		/*
-		 * response contains wrong query? ignore it.
-		 * XXX - potential security hazard could
-		 *	 be detected here.
-		 */
-		DprintQ((statp->options & RES_DEBUG) ||
-			(statp->pfcode & RES_PRF_REPLY),
-			(stdout, ";; wrong query name:\n"),
-			ans, (resplen > anssiz) ? anssiz : resplen);
-		goto wait;
-	}
-	if (anhp->rcode == SERVFAIL ||
-	    anhp->rcode == NOTIMP ||
-	    anhp->rcode == REFUSED) {
-		DprintQ(statp->options & RES_DEBUG,
-			(stdout, "server rejected query:\n"),
-			ans, (resplen > anssiz) ? anssiz : resplen);
-		res_nclose(statp);
-		/* don't retry if called from dig */
-		if (!statp->pfcode)
-			return (0);
-	}
-	if (!(statp->options & RES_IGNTC) && anhp->tc) {
-		/*
-		 * To get the rest of answer,
-		 * use TCP with same server.
-		 */
-		Dprint(statp->options & RES_DEBUG,
-		       (stdout, ";; truncated answer\n"));
-		*v_circuit = 1;
-		res_nclose(statp);
-		return (1);
-	}
-	/*
-	 * All is well, or the error is fatal.  Signal that the
-	 * next nameserver ought not be tried.
-	 */
-	return (resplen);
-}
-
-static void
-Aerror(const res_state statp, FILE *file, const char *string, int error,
-       const struct sockaddr *address, int alen)
-{
-	int save = errno;
-	char hbuf[NI_MAXHOST];
-	char sbuf[NI_MAXSERV];
-
-	alen = alen;
-
-	if ((statp->options & RES_DEBUG) != 0U) {
-		if (getnameinfo(address, alen, hbuf, sizeof(hbuf),
-		    sbuf, sizeof(sbuf), niflags)) {
-			strncpy(hbuf, "?", sizeof(hbuf) - 1);
-			hbuf[sizeof(hbuf) - 1] = '\0';
-			strncpy(sbuf, "?", sizeof(sbuf) - 1);
-			sbuf[sizeof(sbuf) - 1] = '\0';
-		}
-		fprintf(file, "res_send: %s ([%s].%s): %s\n",
-			string, hbuf, sbuf, strerror(error));
-	}
-	errno = save;
-}
-
-static void
-Perror(const res_state statp, FILE *file, const char *string, int error) {
-	int save = errno;
-
-	if ((statp->options & RES_DEBUG) != 0U)
-		fprintf(file, "res_send: %s: %s\n",
-			string, strerror(error));
-	errno = save;
-}
-
-static int
-sock_eq(struct sockaddr *a, struct sockaddr *b) {
-	struct sockaddr_in *a4, *b4;
-	struct sockaddr_in6 *a6, *b6;
-
-	if (a->sa_family != b->sa_family)
-		return 0;
-	switch (a->sa_family) {
-	case AF_INET:
-		a4 = (struct sockaddr_in *)a;
-		b4 = (struct sockaddr_in *)b;
-		return a4->sin_port == b4->sin_port &&
-		    a4->sin_addr.s_addr == b4->sin_addr.s_addr;
-	case AF_INET6:
-		a6 = (struct sockaddr_in6 *)a;
-		b6 = (struct sockaddr_in6 *)b;
-		return a6->sin6_port == b6->sin6_port &&
-#ifdef HAVE_SIN6_SCOPE_ID
-		    a6->sin6_scope_id == b6->sin6_scope_id &&
-#endif
-		    IN6_ARE_ADDR_EQUAL(&a6->sin6_addr, &b6->sin6_addr);
-	default:
-		return 0;
-	}
-}
-
-#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,
-	struct timespec *tsp, const sigset_t *sigmask)
-{
-	struct timeval tv, *tvp;
-	sigset_t sigs;
-	int n;
-
-	if (tsp) {
-		tvp = &tv;
-		tv = evTimeVal(*tsp);
-	} else
-		tvp = NULL;
-	if (sigmask)
-		sigprocmask(SIG_SETMASK, sigmask, &sigs);
-	n = select(nfds, rfds, wfds, efds, tvp);
-	if (sigmask)
-		sigprocmask(SIG_SETMASK, &sigs, NULL);
-	if (tsp)
-		*tsp = evTimeSpec(tv);
-	return (n);
-}
-#endif
diff --git a/contrib/bind9/lib/bind/resolv/res_sendsigned.c b/contrib/bind9/lib/bind/resolv/res_sendsigned.c
deleted file mode 100644
index 63ae07c..0000000
--- a/contrib/bind9/lib/bind/resolv/res_sendsigned.c
+++ /dev/null
@@ -1,170 +0,0 @@
-#include "port_before.h"
-#include "fd_setsize.h"
-
-#include <sys/types.h>
-#include <sys/param.h>
-
-#include <netinet/in.h>
-#include <arpa/nameser.h>
-#include <arpa/inet.h>
-
-#include <isc/dst.h>
-
-#include <errno.h>
-#include <netdb.h>
-#include <resolv.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-#include <unistd.h>
-
-#include "port_after.h"
-
-#define DEBUG
-#include "res_debug.h"
-
-
-/*% res_nsendsigned */
-int
-res_nsendsigned(res_state statp, const u_char *msg, int msglen,
-		ns_tsig_key *key, u_char *answer, int anslen)
-{
-	res_state nstatp;
-	DST_KEY *dstkey;
-	int usingTCP = 0;
-	u_char *newmsg;
-	int newmsglen, bufsize, siglen;
-	u_char sig[64];
-	HEADER *hp;
-	time_t tsig_time;
-	int ret;
-	int len;
-
-	dst_init();
-
-	nstatp = (res_state) malloc(sizeof(*statp));
-	if (nstatp == NULL) {
-		errno = ENOMEM;
-		return (-1);
-	}
-	memcpy(nstatp, statp, sizeof(*statp));
-
-	bufsize = msglen + 1024;
-	newmsg = (u_char *) malloc(bufsize);
-	if (newmsg == NULL) {
-		free(nstatp);
-		errno = ENOMEM;
-		return (-1);
-	}
-	memcpy(newmsg, msg, msglen);
-	newmsglen = msglen;
-
-	if (ns_samename(key->alg, NS_TSIG_ALG_HMAC_MD5) != 1)
-		dstkey = NULL;
-	else
-		dstkey = dst_buffer_to_key(key->name, KEY_HMAC_MD5,
-					   NS_KEY_TYPE_AUTH_ONLY,
-					   NS_KEY_PROT_ANY,
-					   key->data, key->len);
-	if (dstkey == NULL) {
-		errno = EINVAL;
-		free(nstatp);
-		free(newmsg);
-		return (-1);
-	}
-
-	nstatp->nscount = 1;
-	siglen = sizeof(sig);
-	ret = ns_sign(newmsg, &newmsglen, bufsize, NOERROR, dstkey, NULL, 0,
-		      sig, &siglen, 0);
-	if (ret < 0) {
-		free (nstatp);
-		free (newmsg);
-		dst_free_key(dstkey);
-		if (ret == NS_TSIG_ERROR_NO_SPACE)
-			errno  = EMSGSIZE;
-		else if (ret == -1)
-			errno  = EINVAL;
-		return (ret);
-	}
-
-	if (newmsglen > PACKETSZ || nstatp->options & RES_USEVC)
-		usingTCP = 1;
-	if (usingTCP == 0)
-		nstatp->options |= RES_IGNTC;
-	else
-		nstatp->options |= RES_USEVC;
-	/*
-	 * Stop res_send printing the answer.
-	 */
-	nstatp->options &= ~RES_DEBUG;
-	nstatp->pfcode &= ~RES_PRF_REPLY;
-
-retry:
-
-	len = res_nsend(nstatp, newmsg, newmsglen, answer, anslen);
-	if (len < 0) {
-		free (nstatp);
-		free (newmsg);
-		dst_free_key(dstkey);
-		return (len);
-	}
-
-	ret = ns_verify(answer, &len, dstkey, sig, siglen,
-			NULL, NULL, &tsig_time, nstatp->options & RES_KEEPTSIG);
-	if (ret != 0) {
-		Dprint((statp->options & RES_DEBUG) ||
-		       ((statp->pfcode & RES_PRF_REPLY) &&
-			(statp->pfcode & RES_PRF_HEAD1)),
-		       (stdout, ";; got answer:\n"));
-
-		DprintQ((statp->options & RES_DEBUG) ||
-			(statp->pfcode & RES_PRF_REPLY),
-			(stdout, "%s", ""),
-			answer, (anslen > len) ? len : anslen);
-
-		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);
-		if (ret == -1)
-			errno = EINVAL;
-		else
-			errno = ENOTTY;
-		return (-1);
-	}
-
-	hp = (HEADER *) answer;
-	if (hp->tc && !usingTCP && (statp->options & RES_IGNTC) == 0U) {
-		nstatp->options &= ~RES_IGNTC;
-		usingTCP = 1;
-		goto retry;
-	}
-	Dprint((statp->options & RES_DEBUG) ||
-	       ((statp->pfcode & RES_PRF_REPLY) &&
-		(statp->pfcode & RES_PRF_HEAD1)),
-	       (stdout, ";; got answer:\n"));
-
-	DprintQ((statp->options & RES_DEBUG) ||
-		(statp->pfcode & RES_PRF_REPLY),
-		(stdout, "%s", ""),
-		answer, (anslen > len) ? len : anslen);
-
-	Dprint(statp->pfcode & RES_PRF_REPLY, (stdout, ";; TSIG ok\n"));
-
-	free (nstatp);
-	free (newmsg);
-	dst_free_key(dstkey);
-	return (len);
-}
-
-/*! \file */
diff --git a/contrib/bind9/lib/bind/resolv/res_update.c b/contrib/bind9/lib/bind/resolv/res_update.c
deleted file mode 100644
index 483e19d..0000000
--- a/contrib/bind9/lib/bind/resolv/res_update.c
+++ /dev/null
@@ -1,213 +0,0 @@
-#if !defined(lint) && !defined(SABER)
-static const char rcsid[] = "$Id: res_update.c,v 1.12.18.1 2005/04/27 05:01:12 sra Exp $";
-#endif /* not lint */
-
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1996-1999 by 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
- * \brief
- * Based on the Dynamic DNS reference implementation by Viraj Bais
- * &lt;viraj_bais@ccm.fm.intel.com>
- */
-
-#include "port_before.h"
-
-#include <sys/param.h>
-#include <sys/socket.h>
-#include <sys/time.h>
-
-#include <netinet/in.h>
-#include <arpa/inet.h>
-#include <arpa/nameser.h>
-
-#include <errno.h>
-#include <limits.h>
-#include <netdb.h>
-#include <res_update.h>
-#include <stdarg.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-
-#include <isc/list.h>
-#include <resolv.h>
-
-#include "port_after.h"
-#include "res_private.h"
-
-/*%
- * Separate a linked list of records into groups so that all records
- * in a group will belong to a single zone on the nameserver.
- * Create a dynamic update packet for each zone and send it to the
- * nameservers for that zone, and await answer.
- * Abort if error occurs in updating any zone.
- * Return the number of zones updated on success, < 0 on error.
- *
- * On error, caller must deal with the unsynchronized zones
- * eg. an A record might have been successfully added to the forward
- * zone but the corresponding PTR record would be missing if error
- * was encountered while updating the reverse zone.
- */
-
-struct zonegrp {
-	char			z_origin[MAXDNAME];
-	ns_class		z_class;
-	union res_sockaddr_union z_nsaddrs[MAXNS];
-	int			z_nscount;
-	int			z_flags;
-	LIST(ns_updrec)		z_rrlist;
-	LINK(struct zonegrp)	z_link;
-};
-
-#define ZG_F_ZONESECTADDED	0x0001
-
-/* Forward. */
-
-static void	res_dprintf(const char *, ...) ISC_FORMAT_PRINTF(1, 2);
-
-/* Macros. */
-
-#define DPRINTF(x) do {\
-		int save_errno = errno; \
-		if ((statp->options & RES_DEBUG) != 0U) res_dprintf x; \
-		errno = save_errno; \
-	} while (0)
-
-/* Public. */
-
-int
-res_nupdate(res_state statp, ns_updrec *rrecp_in, ns_tsig_key *key) {
-	ns_updrec *rrecp;
-	u_char answer[PACKETSZ];
-	u_char *packet;
-	struct zonegrp *zptr, tgrp;
-	LIST(struct zonegrp) zgrps;
-	int nzones = 0, nscount = 0, n;
-	union res_sockaddr_union nsaddrs[MAXNS];
-
-	packet = malloc(NS_MAXMSG);
-	if (packet == NULL) {
-		DPRINTF(("malloc failed"));
-		return (0);
-	}
-	/* Thread all of the updates onto a list of groups. */
-	INIT_LIST(zgrps);
-	memset(&tgrp, 0, sizeof (tgrp));
-	for (rrecp = rrecp_in; rrecp;
-	     rrecp = LINKED(rrecp, r_link) ? NEXT(rrecp, r_link) : NULL) {
-		int nscnt;
-		/* Find the origin for it if there is one. */
-		tgrp.z_class = rrecp->r_class;
-		nscnt = res_findzonecut2(statp, rrecp->r_dname, tgrp.z_class,
-					 RES_EXHAUSTIVE, tgrp.z_origin,
-					 sizeof tgrp.z_origin, 
-					 tgrp.z_nsaddrs, MAXNS);
-		if (nscnt <= 0) {
-			DPRINTF(("res_findzonecut failed (%d)", nscnt));
-			goto done;
-		}
-		tgrp.z_nscount = nscnt;
-		/* Find the group for it if there is one. */
-		for (zptr = HEAD(zgrps); zptr != NULL; zptr = NEXT(zptr, z_link))
-			if (ns_samename(tgrp.z_origin, zptr->z_origin) == 1 &&
-			    tgrp.z_class == zptr->z_class)
-				break;
-		/* Make a group for it if there isn't one. */
-		if (zptr == NULL) {
-			zptr = malloc(sizeof *zptr);
-			if (zptr == NULL) {
-				DPRINTF(("malloc failed"));
-				goto done;
-			}
-			*zptr = tgrp;
-			zptr->z_flags = 0;
-			INIT_LINK(zptr, z_link);
-			INIT_LIST(zptr->z_rrlist);
-			APPEND(zgrps, zptr, z_link);
-		}
-		/* Thread this rrecp onto the right group. */
-		APPEND(zptr->z_rrlist, rrecp, r_glink);
-	}
-
-	for (zptr = HEAD(zgrps); zptr != NULL; zptr = NEXT(zptr, z_link)) {
-		/* Construct zone section and prepend it. */
-		rrecp = res_mkupdrec(ns_s_zn, zptr->z_origin,
-				     zptr->z_class, ns_t_soa, 0);
-		if (rrecp == NULL) {
-			DPRINTF(("res_mkupdrec failed"));
-			goto done;
-		}
-		PREPEND(zptr->z_rrlist, rrecp, r_glink);
-		zptr->z_flags |= ZG_F_ZONESECTADDED;
-
-		/* Marshall the update message. */
-		n = res_nmkupdate(statp, HEAD(zptr->z_rrlist),
-				  packet, NS_MAXMSG);
-		DPRINTF(("res_mkupdate -> %d", n));
-		if (n < 0)
-			goto done;
-
-		/* Temporarily replace the resolver's nameserver set. */
-		nscount = res_getservers(statp, nsaddrs, MAXNS);
-		res_setservers(statp, zptr->z_nsaddrs, zptr->z_nscount);
-
-		/* Send the update and remember the result. */
-		if (key != NULL)
-			n = res_nsendsigned(statp, packet, n, key,
-					    answer, sizeof answer);
-		else
-			n = res_nsend(statp, packet, n, answer, sizeof answer);
-		if (n < 0) {
-			DPRINTF(("res_nsend: send error, n=%d (%s)\n",
-				 n, strerror(errno)));
-			goto done;
-		}
-		if (((HEADER *)answer)->rcode == NOERROR)
-			nzones++;
-
-		/* Restore resolver's nameserver set. */
-		res_setservers(statp, nsaddrs, nscount);
-		nscount = 0;
-	}
- done:
-	while (!EMPTY(zgrps)) {
-		zptr = HEAD(zgrps);
-		if ((zptr->z_flags & ZG_F_ZONESECTADDED) != 0)
-			res_freeupdrec(HEAD(zptr->z_rrlist));
-		UNLINK(zgrps, zptr, z_link);
-		free(zptr);
-	}
-	if (nscount != 0)
-		res_setservers(statp, nsaddrs, nscount);
-
-	free(packet);
-	return (nzones);
-}
-
-/* Private. */
-
-static void
-res_dprintf(const char *fmt, ...) {
-	va_list ap;
-
-	va_start(ap, fmt);
-	fputs(";; res_nupdate: ", stderr);
-	vfprintf(stderr, fmt, ap);
-	fputc('\n', stderr);
-	va_end(ap);
-}
diff --git a/contrib/bind9/lib/bind9/Makefile.in b/contrib/bind9/lib/bind9/Makefile.in
index 270e9ae..7c1e5b0 100644
--- a/contrib/bind9/lib/bind9/Makefile.in
+++ b/contrib/bind9/lib/bind9/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.18.5 2004/12/10 00:11:50 marka Exp $
+# $Id: Makefile.in,v 1.11 2007/06/19 23:47:16 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/bind9/api b/contrib/bind9/lib/bind9/api
index 3a74aee..39934b4 100644
--- a/contrib/bind9/lib/bind9/api
+++ b/contrib/bind9/lib/bind9/api
@@ -1,3 +1,3 @@
-LIBINTERFACE = 31
-LIBREVISION = 1
-LIBAGE = 1
+LIBINTERFACE = 50
+LIBREVISION = 2
+LIBAGE = 0
diff --git a/contrib/bind9/lib/bind9/check.c b/contrib/bind9/lib/bind9/check.c
index 2967650..800cbf9 100644
--- a/contrib/bind9/lib/bind9/check.c
+++ b/contrib/bind9/lib/bind9/check.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: check.c,v 1.44.18.41 2008/03/29 23:46:10 tbox Exp $ */
+/* $Id: check.c,v 1.95.12.3 2009/02/17 03:43:07 marka Exp $ */
 
 /*! \file */
 
@@ -46,10 +46,6 @@
 
 #include <bind9/check.h>
 
-#ifndef DNS_RDATASET_FIXED
-#define DNS_RDATASET_FIXED 1
-#endif
-
 static void
 freekey(char *key, unsigned int type, isc_symvalue_t value, void *userarg) {
 	UNUSED(type);
@@ -128,7 +124,8 @@ check_orderent(const cfg_obj_t *ent, isc_log_t *logctx) {
 	} else if (strcasecmp(cfg_obj_asstring(obj), "fixed") == 0) {
 #if !DNS_RDATASET_FIXED
 		cfg_obj_log(obj, logctx, ISC_LOG_WARNING,
-			    "rrset-order: order 'fixed' not fully implemented");
+			    "rrset-order: order 'fixed' was disabled at "
+			    "compilation time");
 #endif
 	} else if (strcasecmp(cfg_obj_asstring(obj), "random") != 0 &&
 		   strcasecmp(cfg_obj_asstring(obj), "cyclic") != 0) {
@@ -390,7 +387,8 @@ checkacl(const char *aclname, cfg_aclconfctx_t *actx, const cfg_obj_t *zconfig,
 	}
 	if (aclobj == NULL)
 		return (ISC_R_SUCCESS);
-	result = cfg_acl_fromconfig(aclobj, config, logctx, actx, mctx, &acl);
+	result = cfg_acl_fromconfig(aclobj, config, logctx,
+				    actx, mctx, 0, &acl);
 	if (acl != NULL)
 		dns_acl_detach(&acl);
 	return (result);
@@ -403,9 +401,10 @@ check_viewacls(cfg_aclconfctx_t *actx, const cfg_obj_t *voptions,
 	isc_result_t result = ISC_R_SUCCESS, tresult;
 	int i = 0;
 
-	static const char *acls[] = { "allow-query", "allow-query-cache",
-		"allow-recursion", "blackhole", "match-clients",
-		"match-destinations", "sortlist", NULL };
+	static const char *acls[] = { "allow-query", "allow-query-on",
+		"allow-query-cache", "allow-query-cache-on",
+		"blackhole", "match-clients", "match-destinations",
+		"sortlist", NULL };
 
 	while (acls[i] != NULL) {
 		tresult = checkacl(acls[i++], actx, NULL, voptions, config,
@@ -416,6 +415,81 @@ check_viewacls(cfg_aclconfctx_t *actx, const cfg_obj_t *voptions,
 	return (result);
 }
 
+/*
+ * Check allow-recursion and allow-recursion-on acls, and also log a
+ * warning if they're inconsistent with the "recursion" option.
+ */
+static isc_result_t
+check_recursionacls(cfg_aclconfctx_t *actx, const cfg_obj_t *voptions,
+		    const char *viewname, const cfg_obj_t *config,
+		    isc_log_t *logctx, isc_mem_t *mctx)
+{
+	const cfg_obj_t *options, *aclobj, *obj = NULL;
+	dns_acl_t *acl = NULL;
+	isc_result_t result = ISC_R_SUCCESS, tresult;
+	isc_boolean_t recursion;
+	const char *forview = " for view ";
+	int i = 0;
+
+	static const char *acls[] = { "allow-recursion", "allow-recursion-on",
+				      NULL };
+
+	if (voptions != NULL)
+		cfg_map_get(voptions, "recursion", &obj);
+	if (obj == NULL && config != NULL) {
+		options = NULL;
+		cfg_map_get(config, "options", &options);
+		if (options != NULL)
+			cfg_map_get(options, "recursion", &obj);
+	}
+	if (obj == NULL)
+		recursion = ISC_TRUE;
+	else
+		recursion = cfg_obj_asboolean(obj);
+
+	if (viewname == NULL) {
+		viewname = "";
+		forview = "";
+	}
+
+	for (i = 0; acls[i] != NULL; i++) {
+		aclobj = options = NULL;
+		acl = NULL;
+
+		if (voptions != NULL)
+			cfg_map_get(voptions, acls[i], &aclobj);
+		if (config != NULL && aclobj == NULL) {
+			options = NULL;
+			cfg_map_get(config, "options", &options);
+			if (options != NULL)
+				cfg_map_get(options, acls[i], &aclobj);
+		}
+		if (aclobj == NULL)
+			continue;
+
+		tresult = cfg_acl_fromconfig(aclobj, config, logctx,
+					    actx, mctx, 0, &acl);
+
+		if (tresult != ISC_R_SUCCESS)
+			result = tresult;
+
+		if (acl == NULL)
+			continue;
+
+		if (recursion == ISC_FALSE && !dns_acl_isnone(acl)) {
+			cfg_obj_log(aclobj, logctx, ISC_LOG_WARNING,
+				    "both \"recursion no;\" and "
+				    "\"%s\" active%s%s",
+				    acls[i], forview, viewname);
+		}
+
+		if (acl != NULL)
+			dns_acl_detach(&acl);
+	}
+
+	return (result);
+}
+
 typedef struct {
 	const char *name;
 	unsigned int scale;
@@ -428,6 +502,7 @@ check_options(const cfg_obj_t *options, isc_log_t *logctx, isc_mem_t *mctx) {
 	isc_result_t tresult;
 	unsigned int i;
 	const cfg_obj_t *obj = NULL;
+	const cfg_obj_t *resignobj = NULL;
 	const cfg_listelt_t *element;
 	isc_symtab_t *symtab = NULL;
 	dns_fixedname_t fixed;
@@ -443,7 +518,6 @@ check_options(const cfg_obj_t *options, isc_log_t *logctx, isc_mem_t *mctx) {
 	{ "max-transfer-idle-out", 60, 28 * 24 * 60 },	/* 28 days */
 	{ "max-transfer-time-in", 60, 28 * 24 * 60 },	/* 28 days */
 	{ "max-transfer-time-out", 60, 28 * 24 * 60 },	/* 28 days */
-	{ "sig-validity-interval", 86400, 10 * 366 },	/* 10 years */
 	{ "statistics-interval", 60, 28 * 24 * 60 },	/* 28 days */
 	};
 
@@ -471,6 +545,43 @@ check_options(const cfg_obj_t *options, isc_log_t *logctx, isc_mem_t *mctx) {
 			result = ISC_R_RANGE;
 		}
 	}
+
+	obj = NULL;
+	cfg_map_get(options, "sig-validity-interval", &obj);
+	if (obj != NULL) {
+		isc_uint32_t validity, resign = 0;
+
+		validity = cfg_obj_asuint32(cfg_tuple_get(obj, "validity"));
+		resignobj = cfg_tuple_get(obj, "re-sign");
+		if (!cfg_obj_isvoid(resignobj))
+			resign = cfg_obj_asuint32(resignobj);
+
+		if (validity > 3660 || validity == 0) { /* 10 years */
+			cfg_obj_log(obj, logctx, ISC_LOG_ERROR,
+				    "%s '%u' is out of range (1..3660)",
+				    "sig-validity-interval", validity);
+			result = ISC_R_RANGE;
+		}
+
+		if (!cfg_obj_isvoid(resignobj)) {
+			if (resign > 3660 || resign == 0) { /* 10 years */
+				cfg_obj_log(obj, logctx, ISC_LOG_ERROR,
+					    "%s '%u' is out of range (1..3660)",
+					    "sig-validity-interval (re-sign)",
+					    validity);
+				result = ISC_R_RANGE;
+			} else if ((validity > 7 && validity < resign) ||
+				   (validity <= 7 && validity * 24 < resign)) {
+				cfg_obj_log(obj, logctx, ISC_LOG_ERROR,
+					    "validity interval (%u days) "
+					    "less than re-signing interval "
+					    "(%u %s)", validity, resign,
+					    (validity > 7) ? "days" : "hours");
+				result = ISC_R_RANGE;
+			}
+		}
+	}
+
 	obj = NULL;
 	(void)cfg_map_get(options, "preferred-glue", &obj);
 	if (obj != NULL) {
@@ -483,6 +594,7 @@ check_options(const cfg_obj_t *options, isc_log_t *logctx, isc_mem_t *mctx) {
 				    "preferred-glue unexpected value '%s'",
 				    str);
 	}
+
 	obj = NULL;
 	(void)cfg_map_get(options, "root-delegation-only", &obj);
 	if (obj != NULL) {
@@ -543,7 +655,7 @@ check_options(const cfg_obj_t *options, isc_log_t *logctx, isc_mem_t *mctx) {
 	(void)cfg_map_get(options, "dnssec-lookaside", &obj);
 	if (obj != NULL) {
 		tresult = isc_symtab_create(mctx, 100, freekey, mctx,
-					    ISC_TRUE, &symtab);
+					    ISC_FALSE, &symtab);
 		if (tresult != ISC_R_SUCCESS)
 			result = tresult;
 		for (element = cfg_list_first(obj);
@@ -680,6 +792,19 @@ check_options(const cfg_obj_t *options, isc_log_t *logctx, isc_mem_t *mctx) {
 		}
 	}
 
+	/*
+	 * Check that server-id is not too long.
+	 * 1024 bytes should be big enough.
+	 */
+	obj = NULL;
+	(void)cfg_map_get(options, "server-id", &obj);
+	if (obj != NULL && cfg_obj_isstring(obj) &&
+	    strlen(cfg_obj_asstring(obj)) > 1024U) {
+		cfg_obj_log(obj, logctx, ISC_LOG_ERROR,
+			    "'server-id' too big (>1024 bytes)");
+		result = ISC_R_FAILURE;
+	}
+
 	return (result);
 }
 
@@ -784,8 +909,11 @@ validate_masters(const cfg_obj_t *obj, const cfg_obj_t *config,
 			if (new == NULL)
 				goto cleanup;
 			if (stackcount != 0) {
+				void *ptr;
+
+				DE_CONST(stack, ptr);
 				memcpy(new, stack, oldsize);
-				isc_mem_put(mctx, stack, oldsize);
+				isc_mem_put(mctx, ptr, oldsize);
 			}
 			stack = new;
 			stackcount = newlen;
@@ -798,8 +926,12 @@ validate_masters(const cfg_obj_t *obj, const cfg_obj_t *config,
 		goto resume;
 	}
  cleanup:
-	if (stack != NULL)
-		isc_mem_put(mctx, stack, stackcount * sizeof(*stack));
+	if (stack != NULL) {
+		void *ptr;
+
+		DE_CONST(stack, ptr);
+		isc_mem_put(mctx, ptr, stackcount * sizeof(*stack));
+	}
 	isc_symtab_destroy(&symtab);
 	*countp = count;
 	return (result);
@@ -936,6 +1068,10 @@ check_zoneconf(const cfg_obj_t *zconfig, const cfg_obj_t *voptions,
 	{ "max-refresh-time", SLAVEZONE | STUBZONE },
 	{ "min-refresh-time", SLAVEZONE | STUBZONE },
 	{ "sig-validity-interval", MASTERZONE },
+	{ "sig-re-signing-interval", MASTERZONE },
+	{ "sig-signing-nodes", MASTERZONE },
+	{ "sig-signing-type", MASTERZONE },
+	{ "sig-signing-signatures", MASTERZONE },
 	{ "zone-statistics", MASTERZONE | SLAVEZONE | STUBZONE },
 	{ "allow-update", MASTERZONE | CHECKACL },
 	{ "allow-update-forwarding", SLAVEZONE | CHECKACL },
@@ -955,6 +1091,7 @@ check_zoneconf(const cfg_obj_t *zconfig, const cfg_obj_t *voptions,
 	{ "check-srv-cname", MASTERZONE },
 	{ "masterfile-format", MASTERZONE | SLAVEZONE | STUBZONE | HINTZONE },
 	{ "update-check-ksk", MASTERZONE },
+	{ "try-tcp-refresh", SLAVEZONE },
 	};
 
 	static optionstable dialups[] = {
@@ -1020,7 +1157,7 @@ check_zoneconf(const cfg_obj_t *zconfig, const cfg_obj_t *voptions,
 
 	/*
 	 * Look for an already existing zone.
-	 * We need to make this cannonical as isc_symtab_define()
+	 * We need to make this canonical as isc_symtab_define()
 	 * deals with strings.
 	 */
 	dns_fixedname_init(&fixedname);
@@ -1125,6 +1262,17 @@ check_zoneconf(const cfg_obj_t *zconfig, const cfg_obj_t *voptions,
 		} else if (res2 == ISC_R_SUCCESS &&
 			   check_update_policy(obj, logctx) != ISC_R_SUCCESS)
 			result = ISC_R_FAILURE;
+		obj = NULL;
+		res1 = cfg_map_get(zoptions, "sig-signing-type", &obj);
+		if (res1 == ISC_R_SUCCESS) {
+			isc_uint32_t type = cfg_obj_asuint32(obj);
+			if (type < 0xff00U || type > 0xffffU)
+				cfg_obj_log(obj, logctx, ISC_LOG_ERROR,
+					    "sig-signing-type: %u out of "
+					    "range [%u..%u]", type,
+					    0xff00U, 0xffffU);
+			result = ISC_R_FAILURE;
+		}
 	}
 
 	/*
@@ -1297,27 +1445,56 @@ bind9_check_key(const cfg_obj_t *key, isc_log_t *logctx) {
 	return (ISC_R_SUCCESS);
 }
 
+/*
+ * Check key list for duplicates key names and that the key names
+ * are valid domain names as these keys are used for TSIG.
+ *
+ * Check the key contents for validity.
+ */
 static isc_result_t
-check_keylist(const cfg_obj_t *keys, isc_symtab_t *symtab, isc_log_t *logctx) {
+check_keylist(const cfg_obj_t *keys, isc_symtab_t *symtab,
+	      isc_mem_t *mctx, isc_log_t *logctx)
+{
+	char namebuf[DNS_NAME_FORMATSIZE];
+	dns_fixedname_t fname;
+	dns_name_t *name;
 	isc_result_t result = ISC_R_SUCCESS;
 	isc_result_t tresult;
 	const cfg_listelt_t *element;
 
+	dns_fixedname_init(&fname);
+	name = dns_fixedname_name(&fname);
 	for (element = cfg_list_first(keys);
 	     element != NULL;
 	     element = cfg_list_next(element))
 	{
 		const cfg_obj_t *key = cfg_listelt_value(element);
-		const char *keyname = cfg_obj_asstring(cfg_map_getname(key));
+		const char *keyid = cfg_obj_asstring(cfg_map_getname(key));
 		isc_symvalue_t symvalue;
+		isc_buffer_t b;
+		char *keyname;
 
+		isc_buffer_init(&b, keyid, strlen(keyid));
+		isc_buffer_add(&b, strlen(keyid));
+		tresult = dns_name_fromtext(name, &b, dns_rootname,
+					    ISC_FALSE, NULL);
+		if (tresult != ISC_R_SUCCESS) {
+			cfg_obj_log(key, logctx, ISC_LOG_ERROR,
+				    "key '%s': bad key name", keyid);
+			result = tresult;
+			continue;
+		}
 		tresult = bind9_check_key(key, logctx);
 		if (tresult != ISC_R_SUCCESS)
 			return (tresult);
 
+		dns_name_format(name, namebuf, sizeof(namebuf));
+		keyname = isc_mem_strdup(mctx, namebuf);
+		if (keyname == NULL)
+			return (ISC_R_NOMEMORY);
 		symvalue.as_cpointer = key;
-		tresult = isc_symtab_define(symtab, keyname, 1,
-					    symvalue, isc_symexists_reject);
+		tresult = isc_symtab_define(symtab, keyname, 1, symvalue,
+					    isc_symexists_reject);
 		if (tresult == ISC_R_EXISTS) {
 			const char *file;
 			unsigned int line;
@@ -1332,10 +1509,13 @@ check_keylist(const cfg_obj_t *keys, isc_symtab_t *symtab, isc_log_t *logctx) {
 			cfg_obj_log(key, logctx, ISC_LOG_ERROR,
 				    "key '%s': already exists "
 				    "previous definition: %s:%u",
-				    keyname, file, line);
+				    keyid, file, line);
+			isc_mem_free(mctx, keyname);
 			result = tresult;
-		} else if (tresult != ISC_R_SUCCESS)
+		} else if (tresult != ISC_R_SUCCESS) {
+			isc_mem_free(mctx, keyname);
 			return (tresult);
+		}
 	}
 	return (result);
 }
@@ -1350,18 +1530,60 @@ static struct {
 	{ NULL, NULL }
 };
 
+/*
+ * RNDC keys are not normalised unlike TSIG keys.
+ *
+ * 	"foo." is different to "foo".
+ */
+static isc_boolean_t
+rndckey_exists(const cfg_obj_t *keylist, const char *keyname) {
+	const cfg_listelt_t *element;
+	const cfg_obj_t *obj;
+	const char *str;
+
+	if (keylist == NULL)
+		return (ISC_FALSE);
+
+	for (element = cfg_list_first(keylist);
+	     element != NULL;
+	     element = cfg_list_next(element))
+	{
+		obj = cfg_listelt_value(element);
+		str = cfg_obj_asstring(cfg_map_getname(obj));
+		if (!strcasecmp(str, keyname))
+			return (ISC_TRUE);
+	}
+	return (ISC_FALSE);
+}
+
 static isc_result_t
-check_servers(const cfg_obj_t *servers, isc_log_t *logctx) {
+check_servers(const cfg_obj_t *config, const cfg_obj_t *voptions,
+	      isc_symtab_t *symtab, isc_log_t *logctx)
+{
+	dns_fixedname_t fname;
 	isc_result_t result = ISC_R_SUCCESS;
 	isc_result_t tresult;
 	const cfg_listelt_t *e1, *e2;
-	const cfg_obj_t *v1, *v2;
+	const cfg_obj_t *v1, *v2, *keys;
+	const cfg_obj_t *servers;
 	isc_netaddr_t n1, n2;
 	unsigned int p1, p2;
 	const cfg_obj_t *obj;
 	char buf[ISC_NETADDR_FORMATSIZE];
+	char namebuf[DNS_NAME_FORMATSIZE];
 	const char *xfr;
+	const char *keyval;
+	isc_buffer_t b;
 	int source;
+	dns_name_t *keyname;
+
+	servers = NULL;
+	if (voptions != NULL)
+		(void)cfg_map_get(voptions, "server", &servers);
+	if (servers == NULL)
+		(void)cfg_map_get(config, "server", &servers);
+	if (servers == NULL)
+		return (ISC_R_SUCCESS);
 
 	for (e1 = cfg_list_first(servers); e1 != NULL; e1 = cfg_list_next(e1)) {
 		v1 = cfg_listelt_value(e1);
@@ -1389,8 +1611,8 @@ check_servers(const cfg_obj_t *servers, isc_log_t *logctx) {
 			if (obj != NULL) {
 				isc_netaddr_format(&n1, buf, sizeof(buf));
 				cfg_obj_log(v1, logctx, ISC_LOG_ERROR,
-					    "server '%s': %s not legal",
-					    buf, xfr);
+					    "server '%s/%u': %s not legal",
+					    buf, p1, xfr);
 				result = ISC_R_FAILURE;
 			}
 		} while (sources[++source].v4 != NULL);
@@ -1413,15 +1635,42 @@ check_servers(const cfg_obj_t *servers, isc_log_t *logctx) {
 				result = ISC_R_FAILURE;
 			}
 		}
+		keys = NULL;
+		cfg_map_get(v1, "keys", &keys);
+		if (keys != NULL) {
+			/*
+			 * Normalize key name.
+			 */
+			keyval = cfg_obj_asstring(keys);
+			dns_fixedname_init(&fname);
+			isc_buffer_init(&b, keyval, strlen(keyval));
+			isc_buffer_add(&b, strlen(keyval));
+			keyname = dns_fixedname_name(&fname);
+			tresult = dns_name_fromtext(keyname, &b, dns_rootname,
+						    ISC_FALSE, NULL);
+			if (tresult != ISC_R_SUCCESS) {
+				cfg_obj_log(keys, logctx, ISC_LOG_ERROR,
+					    "bad key name '%s'", keyval);
+				result = ISC_R_FAILURE;
+				continue;
+			}
+			dns_name_format(keyname, namebuf, sizeof(namebuf));
+			tresult = isc_symtab_lookup(symtab, namebuf, 1, NULL);
+			if (tresult != ISC_R_SUCCESS) {
+				cfg_obj_log(keys, logctx, ISC_LOG_ERROR,
+					    "unknown key '%s'", keyval);
+				result = ISC_R_FAILURE;
+			}
+		}
 	}
 	return (result);
 }
 
 static isc_result_t
 check_viewconf(const cfg_obj_t *config, const cfg_obj_t *voptions,
-	       dns_rdataclass_t vclass, isc_log_t *logctx, isc_mem_t *mctx)
+	       const char *viewname, dns_rdataclass_t vclass,
+	       isc_log_t *logctx, isc_mem_t *mctx)
 {
-	const cfg_obj_t *servers = NULL;
 	const cfg_obj_t *zones = NULL;
 	const cfg_obj_t *keys = NULL;
 	const cfg_listelt_t *element;
@@ -1464,37 +1713,6 @@ check_viewconf(const cfg_obj_t *config, const cfg_obj_t *voptions,
 	isc_symtab_destroy(&symtab);
 
 	/*
-	 * Check that all key statements are syntactically correct and
-	 * there are no duplicate keys.
-	 */
-	tresult = isc_symtab_create(mctx, 100, NULL, NULL, ISC_TRUE, &symtab);
-	if (tresult != ISC_R_SUCCESS)
-		return (ISC_R_NOMEMORY);
-
-	(void)cfg_map_get(config, "key", &keys);
-	tresult = check_keylist(keys, symtab, logctx);
-	if (tresult == ISC_R_EXISTS)
-		result = ISC_R_FAILURE;
-	else if (tresult != ISC_R_SUCCESS) {
-		isc_symtab_destroy(&symtab);
-		return (tresult);
-	}
-
-	if (voptions != NULL) {
-		keys = NULL;
-		(void)cfg_map_get(voptions, "key", &keys);
-		tresult = check_keylist(keys, symtab, logctx);
-		if (tresult == ISC_R_EXISTS)
-			result = ISC_R_FAILURE;
-		else if (tresult != ISC_R_SUCCESS) {
-			isc_symtab_destroy(&symtab);
-			return (tresult);
-		}
-	}
-
-	isc_symtab_destroy(&symtab);
-
-	/*
 	 * Check that forwarding is reasonable.
 	 */
 	if (voptions == NULL) {
@@ -1508,6 +1726,7 @@ check_viewconf(const cfg_obj_t *config, const cfg_obj_t *voptions,
 		if (check_forward(voptions, NULL, logctx) != ISC_R_SUCCESS)
 			result = ISC_R_FAILURE;
 	}
+
 	/*
 	 * Check that dual-stack-servers is reasonable.
 	 */
@@ -1530,14 +1749,45 @@ check_viewconf(const cfg_obj_t *config, const cfg_obj_t *voptions,
 			result = ISC_R_FAILURE;
 	}
 
+	/*
+	 * Check that all key statements are syntactically correct and
+	 * there are no duplicate keys.
+	 */
+	tresult = isc_symtab_create(mctx, 100, freekey, mctx,
+				    ISC_FALSE, &symtab);
+	if (tresult != ISC_R_SUCCESS)
+		return (ISC_R_NOMEMORY);
+
+	(void)cfg_map_get(config, "key", &keys);
+	tresult = check_keylist(keys, symtab, mctx, logctx);
+	if (tresult == ISC_R_EXISTS)
+		result = ISC_R_FAILURE;
+	else if (tresult != ISC_R_SUCCESS) {
+		isc_symtab_destroy(&symtab);
+		return (tresult);
+	}
+
 	if (voptions != NULL) {
-		(void)cfg_map_get(voptions, "server", &servers);
-		if (servers != NULL &&
-		    check_servers(servers, logctx) != ISC_R_SUCCESS)
+		keys = NULL;
+		(void)cfg_map_get(voptions, "key", &keys);
+		tresult = check_keylist(keys, symtab, mctx, logctx);
+		if (tresult == ISC_R_EXISTS)
 			result = ISC_R_FAILURE;
+		else if (tresult != ISC_R_SUCCESS) {
+			isc_symtab_destroy(&symtab);
+			return (tresult);
+		}
 	}
 
 	/*
+	 * Global servers can refer to keys in views.
+	 */
+	if (check_servers(config, voptions, symtab, logctx) != ISC_R_SUCCESS)
+		result = ISC_R_FAILURE;
+
+	isc_symtab_destroy(&symtab);
+
+	/*
 	 * Check that dnssec-enable/dnssec-validation are sensible.
 	 */
 	obj = NULL;
@@ -1575,6 +1825,11 @@ check_viewconf(const cfg_obj_t *config, const cfg_obj_t *voptions,
 	if (tresult != ISC_R_SUCCESS)
 		result = tresult;
 
+	tresult = check_recursionacls(&actx, voptions, viewname,
+				      config, logctx, mctx);
+	if (tresult != ISC_R_SUCCESS)
+		result = tresult;
+
 	cfg_aclconfctx_destroy(&actx);
 
 	return (result);
@@ -1698,33 +1953,14 @@ bind9_check_logging(const cfg_obj_t *config, isc_log_t *logctx,
 }
 
 static isc_result_t
-key_exists(const cfg_obj_t *keylist, const char *keyname) {
-	const cfg_listelt_t *element;
-	const char *str;
-	const cfg_obj_t *obj;
-
-	if (keylist == NULL)
-		return (ISC_R_NOTFOUND);
-	for (element = cfg_list_first(keylist);
-	     element != NULL;
-	     element = cfg_list_next(element))
-	{
-		obj = cfg_listelt_value(element);
-		str = cfg_obj_asstring(cfg_map_getname(obj));
-		if (strcasecmp(str, keyname) == 0)
-			return (ISC_R_SUCCESS);
-	}
-	return (ISC_R_NOTFOUND);
-}
-
-static isc_result_t
 bind9_check_controlskeys(const cfg_obj_t *control, const cfg_obj_t *keylist,
 			 isc_log_t *logctx)
 {
-	isc_result_t result = ISC_R_SUCCESS, tresult;
+	isc_result_t result = ISC_R_SUCCESS;
 	const cfg_obj_t *control_keylist;
 	const cfg_listelt_t *element;
 	const cfg_obj_t *key;
+	const char *keyval;
 
 	control_keylist = cfg_tuple_get(control, "keys");
 	if (cfg_obj_isvoid(control_keylist))
@@ -1735,11 +1971,12 @@ bind9_check_controlskeys(const cfg_obj_t *control, const cfg_obj_t *keylist,
 	     element = cfg_list_next(element))
 	{
 		key = cfg_listelt_value(element);
-		tresult = key_exists(keylist, cfg_obj_asstring(key));
-		if (tresult != ISC_R_SUCCESS) {
+		keyval = cfg_obj_asstring(key);
+
+		if (!rndckey_exists(keylist, keyval)) {
 			cfg_obj_log(key, logctx, ISC_LOG_ERROR,
-				    "unknown key '%s'", cfg_obj_asstring(key));
-			result = tresult;
+				    "unknown key '%s'", keyval);
+			result = ISC_R_NOTFOUND;
 		}
 	}
 	return (result);
@@ -1791,7 +2028,7 @@ bind9_check_controls(const cfg_obj_t *config, isc_log_t *logctx,
 			control = cfg_listelt_value(element2);
 			allow = cfg_tuple_get(control, "allow");
 			tresult = cfg_acl_fromconfig(allow, config, logctx,
-						     &actx, mctx, &acl);
+						     &actx, mctx, 0, &acl);
 			if (acl != NULL)
 				dns_acl_detach(&acl);
 			if (tresult != ISC_R_SUCCESS)
@@ -1847,7 +2084,6 @@ bind9_check_namedconf(const cfg_obj_t *config, isc_log_t *logctx,
 		      isc_mem_t *mctx)
 {
 	const cfg_obj_t *options = NULL;
-	const cfg_obj_t *servers = NULL;
 	const cfg_obj_t *views = NULL;
 	const cfg_obj_t *acls = NULL;
 	const cfg_obj_t *kals = NULL;
@@ -1866,11 +2102,6 @@ bind9_check_namedconf(const cfg_obj_t *config, isc_log_t *logctx,
 	    check_options(options, logctx, mctx) != ISC_R_SUCCESS)
 		result = ISC_R_FAILURE;
 
-	(void)cfg_map_get(config, "server", &servers);
-	if (servers != NULL &&
-	    check_servers(servers, logctx) != ISC_R_SUCCESS)
-		result = ISC_R_FAILURE;
-
 	if (bind9_check_logging(config, logctx, mctx) != ISC_R_SUCCESS)
 		result = ISC_R_FAILURE;
 
@@ -1888,7 +2119,7 @@ bind9_check_namedconf(const cfg_obj_t *config, isc_log_t *logctx,
 			result = ISC_R_FAILURE;
 
 	if (views == NULL) {
-		if (check_viewconf(config, NULL, dns_rdataclass_in,
+		if (check_viewconf(config, NULL, NULL, dns_rdataclass_in,
 				   logctx, mctx) != ISC_R_SUCCESS)
 			result = ISC_R_FAILURE;
 	} else {
@@ -1960,7 +2191,7 @@ bind9_check_namedconf(const cfg_obj_t *config, isc_log_t *logctx,
 			}
 		}
 		if (tresult == ISC_R_SUCCESS)
-			tresult = check_viewconf(config, voptions,
+			tresult = check_viewconf(config, voptions, key,
 						 vclass, logctx, mctx);
 		if (tresult != ISC_R_SUCCESS)
 			result = ISC_R_FAILURE;
@@ -1979,8 +2210,9 @@ bind9_check_namedconf(const cfg_obj_t *config, isc_log_t *logctx,
 		}
 	}
 
-	tresult = cfg_map_get(config, "acl", &acls);
-	if (tresult == ISC_R_SUCCESS) {
+	cfg_map_get(config, "acl", &acls);
+
+	if (acls != NULL) {
 		const cfg_listelt_t *elt;
 		const cfg_listelt_t *elt2;
 		const char *aclname;
@@ -1989,6 +2221,7 @@ bind9_check_namedconf(const cfg_obj_t *config, isc_log_t *logctx,
 		     elt != NULL;
 		     elt = cfg_list_next(elt)) {
 			const cfg_obj_t *acl = cfg_listelt_value(elt);
+			unsigned int line = cfg_obj_line(acl);
 			unsigned int i;
 
 			aclname = cfg_obj_asstring(cfg_tuple_get(acl, "name"));
@@ -2013,7 +2246,6 @@ bind9_check_namedconf(const cfg_obj_t *config, isc_log_t *logctx,
 								      "name"));
 				if (strcasecmp(aclname, name) == 0) {
 					const char *file = cfg_obj_file(acl);
-					unsigned int line = cfg_obj_line(acl);
 
 					if (file == NULL)
 						file = "<unknown file>";
diff --git a/contrib/bind9/lib/bind9/getaddresses.c b/contrib/bind9/lib/bind9/getaddresses.c
index b6edce0..a75e14e 100644
--- a/contrib/bind9/lib/bind9/getaddresses.c
+++ b/contrib/bind9/lib/bind9/getaddresses.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001, 2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: getaddresses.c,v 1.15.18.5 2005/10/14 01:28:24 marka Exp $ */
+/* $Id: getaddresses.c,v 1.22 2007/06/19 23:47:16 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/bind9/include/Makefile.in b/contrib/bind9/lib/bind9/include/Makefile.in
index 6c6611e..65eecb0 100644
--- a/contrib/bind9/lib/bind9/include/Makefile.in
+++ b/contrib/bind9/lib/bind9/include/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.2 2004/03/05 05:09:08 marka Exp $
+# $Id: Makefile.in,v 1.4 2007/06/19 23:47:16 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/bind9/include/bind9/Makefile.in b/contrib/bind9/lib/bind9/include/bind9/Makefile.in
index 8ef5c32..8abfaf6 100644
--- a/contrib/bind9/lib/bind9/include/bind9/Makefile.in
+++ b/contrib/bind9/lib/bind9/include/bind9/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.6 2004/03/05 05:09:10 marka Exp $
+# $Id: Makefile.in,v 1.8 2007/06/19 23:47:16 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/bind9/include/bind9/check.h b/contrib/bind9/lib/bind9/include/bind9/check.h
index 25a8e0c..1647568 100644
--- a/contrib/bind9/lib/bind9/include/bind9/check.h
+++ b/contrib/bind9/lib/bind9/include/bind9/check.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: check.h,v 1.2.18.4 2006/03/02 00:37:21 marka Exp $ */
+/* $Id: check.h,v 1.9 2007/06/19 23:47:16 tbox Exp $ */
 
 #ifndef BIND9_CHECK_H
 #define BIND9_CHECK_H 1
 
-/*! \file */
+/*! \file bind9/check.h */
 
 #include <isc/lang.h>
 #include <isc/types.h>
diff --git a/contrib/bind9/lib/bind9/include/bind9/getaddresses.h b/contrib/bind9/lib/bind9/include/bind9/getaddresses.h
index e6d030d..736feb6 100644
--- a/contrib/bind9/lib/bind9/include/bind9/getaddresses.h
+++ b/contrib/bind9/lib/bind9/include/bind9/getaddresses.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: getaddresses.h,v 1.3.18.2 2005/04/29 00:15:48 marka Exp $ */
+/* $Id: getaddresses.h,v 1.9.332.2 2009/01/18 23:47:35 tbox Exp $ */
 
 #ifndef BIND9_GETADDRESSES_H
 #define BIND9_GETADDRESSES_H 1
 
-/*! \file */
+/*! \file bind9/getaddresses.h */
 
 #include <isc/lang.h>
 #include <isc/types.h>
@@ -40,7 +40,7 @@ bind9_getaddresses(const char *hostname, in_port_t port,
  * first 'addrsize' are returned and the remainder silently truncated.
  *
  * This routine may block.  If called by a program using the isc_app
- * framework, it should be surounded by isc_app_block()/isc_app_unblock().
+ * framework, it should be surrounded by isc_app_block()/isc_app_unblock().
  *
  *  Requires:
  *\li	'hostname' is not NULL.
@@ -48,7 +48,7 @@ bind9_getaddresses(const char *hostname, in_port_t port,
  *\li	'addrsize' > 0
  *\li	'addrcount' is not NULL.
  *
- * 
+ *
  * Returns:
  *\li	#ISC_R_SUCCESS
  *\li	#ISC_R_NOTFOUND
diff --git a/contrib/bind9/lib/bind9/include/bind9/version.h b/contrib/bind9/lib/bind9/include/bind9/version.h
index 154e240d..5b08b7c 100644
--- a/contrib/bind9/lib/bind9/include/bind9/version.h
+++ b/contrib/bind9/lib/bind9/include/bind9/version.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,9 +15,9 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: version.h,v 1.3.18.2 2005/04/29 00:15:48 marka Exp $ */
+/* $Id: version.h,v 1.9 2007/06/19 23:47:16 tbox Exp $ */
 
-/*! \file */
+/*! \file bind9/version.h */
 
 #include <isc/platform.h>
 
diff --git a/contrib/bind9/lib/bind9/version.c b/contrib/bind9/lib/bind9/version.c
index 2cc17da..d5934cc 100644
--- a/contrib/bind9/lib/bind9/version.c
+++ b/contrib/bind9/lib/bind9/version.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: version.c,v 1.4.18.2 2005/04/29 00:15:47 marka Exp $ */
+/* $Id: version.c,v 1.8 2007/06/19 23:47:16 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/dns/Makefile.in b/contrib/bind9/lib/dns/Makefile.in
index 286a5f9..ef5c12a 100644
--- a/contrib/bind9/lib/dns/Makefile.in
+++ b/contrib/bind9/lib/dns/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1998-2003  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.144.18.10 2006/01/06 00:01:43 marka Exp $
+# $Id: Makefile.in,v 1.163 2008/09/24 02:46:22 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -29,10 +29,14 @@ top_srcdir =	@top_srcdir@
 
 @BIND9_MAKE_INCLUDES@
 
+USE_ISC_SPNEGO = @USE_ISC_SPNEGO@
+
 CINCLUDES =	-I. -Iinclude ${DNS_INCLUDES} \
 		${ISC_INCLUDES} @DST_OPENSSL_INC@ @DST_GSSAPI_INC@
 
-CDEFINES =	-DUSE_MD5 @USE_OPENSSL@ @USE_GSSAPI@
+CDEFINES =	-DUSE_MD5 @USE_OPENSSL@ @USE_PKCS11@ @USE_GSSAPI@ \
+		${USE_ISC_SPNEGO}
+
 CWARNINGS =
 
 ISCLIBS =	../../lib/isc/libisc.@A@
@@ -43,7 +47,8 @@ LIBS =		@LIBS@
 
 # Alphabetically
 
-DSTOBJS =	dst_api.@O@ dst_lib.@O@ dst_parse.@O@ dst_result.@O@ \
+DSTOBJS =	@DST_EXTRA_OBJS@ \
+		dst_api.@O@ dst_lib.@O@ dst_parse.@O@ dst_result.@O@ \
 		gssapi_link.@O@ gssapictx.@O@ hmac_link.@O@ key.@O@ \
 		openssl_link.@O@ openssldh_link.@O@ openssldsa_link.@O@ \
 		opensslrsa_link.@O@
@@ -52,10 +57,10 @@ DSTOBJS =	dst_api.@O@ dst_lib.@O@ dst_parse.@O@ dst_result.@O@ \
 DNSOBJS =	acache.@O@ acl.@O@ adb.@O@ byaddr.@O@ \
 		cache.@O@ callbacks.@O@ compress.@O@ \
 		db.@O@ dbiterator.@O@ dbtable.@O@ diff.@O@ dispatch.@O@ \
-		dlz.@O@ dnssec.@O@ ds.@O@ forward.@O@ journal.@O@ keytable.@O@ \
-		lib.@O@ log.@O@ lookup.@O@ \
+		dlz.@O@ dnssec.@O@ ds.@O@ forward.@O@ iptable.@O@ journal.@O@ \
+		keytable.@O@ lib.@O@ log.@O@ lookup.@O@ \
 		master.@O@ masterdump.@O@ message.@O@ \
-		name.@O@ ncache.@O@ nsec.@O@ order.@O@ peer.@O@ portlist.@O@ \
+		name.@O@ ncache.@O@ nsec.@O@ nsec3.@O@ order.@O@ peer.@O@ portlist.@O@ \
 		rbt.@O@ rbtdb.@O@ rbtdb64.@O@ rcode.@O@ rdata.@O@ \
 		rdatalist.@O@ \
 		rdataset.@O@ rdatasetiter.@O@ rdataslab.@O@ request.@O@ \
@@ -68,7 +73,8 @@ DNSOBJS =	acache.@O@ acl.@O@ adb.@O@ byaddr.@O@ \
 OBJS=		${DNSOBJS} ${OTHEROBJS} ${DSTOBJS}
 
 # Alphabetically
-DSTSRCS =	dst_api.c dst_lib.c dst_parse.c \
+DSTSRCS =	@DST_EXTRA_SRCS@ \
+		dst_api.c dst_lib.c dst_parse.c \
 		dst_result.c gssapi_link.c gssapictx.c \
 		hmac_link.c key.c \
 		openssl_link.c openssldh_link.c \
@@ -77,10 +83,10 @@ DSTSRCS =	dst_api.c dst_lib.c dst_parse.c \
 DNSSRCS =	acache.c acl.c adb.c byaddr.c \
 		cache.c callbacks.c compress.c \
 		db.c dbiterator.c dbtable.c diff.c dispatch.c \
-		dlz.c dnssec.c ds.c forward.c journal.c keytable.c \
-		lib.c log.c lookup.c \
+		dlz.c dnssec.c ds.c forward.c iptable.c journal.c \
+		keytable.c lib.c log.c lookup.c \
 		master.c masterdump.c message.c \
-		name.c ncache.c nsec.c order.c peer.c portlist.c \
+		name.c ncache.c nsec.c nsec3.c order.c peer.c portlist.c \
 		rbt.c rbtdb.c rbtdb64.c rcode.c rdata.c \
 		rdatalist.c \
 		rdataset.c rdatasetiter.c rdataslab.c request.c \
@@ -169,3 +175,5 @@ subdirs: include/dns/enumtype.h include/dns/enumclass.h \
 	include/dns/rdatastruct.h code.h
 ${OBJS}: include/dns/enumtype.h include/dns/enumclass.h \
 	include/dns/rdatastruct.h
+
+spnego.@O@: spnego_asn1.c spnego.h
diff --git a/contrib/bind9/lib/dns/acache.c b/contrib/bind9/lib/dns/acache.c
index cd56c3c..2ad4981 100644
--- a/contrib/bind9/lib/dns/acache.c
+++ b/contrib/bind9/lib/dns/acache.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  *
  * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: acache.c,v 1.3.2.18 2008/02/07 23:45:56 tbox Exp $ */
+/* $Id: acache.c,v 1.22 2008/02/07 23:46:54 tbox Exp $ */
 
 #include <config.h>
 
diff --git a/contrib/bind9/lib/dns/acl.c b/contrib/bind9/lib/dns/acl.c
index 844c132..3af8dd3 100644
--- a/contrib/bind9/lib/dns/acl.c
+++ b/contrib/bind9/lib/dns/acl.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,18 +15,25 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: acl.c,v 1.25.18.5 2006/03/02 00:37:21 marka Exp $ */
+/* $Id: acl.c,v 1.50.44.3 2009/01/18 23:47:35 tbox Exp $ */
 
 /*! \file */
 
 #include <config.h>
 
 #include <isc/mem.h>
+#include <isc/once.h>
 #include <isc/string.h>
 #include <isc/util.h>
 
 #include <dns/acl.h>
+#include <dns/iptable.h>
 
+/*
+ * Create a new ACL, including an IP table and an array with room
+ * for 'n' ACL elements.  The elements are uninitialized and the
+ * length is 0.
+ */
 isc_result_t
 dns_acl_create(isc_mem_t *mctx, int n, dns_acl_t **target) {
 	isc_result_t result;
@@ -43,14 +50,23 @@ dns_acl_create(isc_mem_t *mctx, int n, dns_acl_t **target) {
 		return (ISC_R_NOMEMORY);
 	acl->mctx = mctx;
 	acl->name = NULL;
+
 	result = isc_refcount_init(&acl->refcount, 1);
 	if (result != ISC_R_SUCCESS) {
 		isc_mem_put(mctx, acl, sizeof(*acl));
 		return (result);
 	}
+
+	result = dns_iptable_create(mctx, &acl->iptable);
+	if (result != ISC_R_SUCCESS) {
+		isc_mem_put(mctx, acl, sizeof(*acl));
+		return (result);
+	}
+
 	acl->elements = NULL;
 	acl->alloc = 0;
 	acl->length = 0;
+	acl->has_negatives = ISC_FALSE;
 
 	ISC_LINK_INIT(acl, nextincache);
 	/*
@@ -73,111 +89,282 @@ dns_acl_create(isc_mem_t *mctx, int n, dns_acl_t **target) {
 	return (result);
 }
 
-isc_result_t
-dns_acl_appendelement(dns_acl_t *acl, const dns_aclelement_t *elt) {
-	if (acl->length + 1 > acl->alloc) {
-		/*
-		 * Resize the ACL.
-		 */
-		unsigned int newalloc;
-		void *newmem;
-
-		newalloc = acl->alloc * 2;
-		if (newalloc < 4)
-			newalloc = 4;
-		newmem = isc_mem_get(acl->mctx,
-				     newalloc * sizeof(dns_aclelement_t));
-		if (newmem == NULL)
-			return (ISC_R_NOMEMORY);
-		memcpy(newmem, acl->elements,
-		       acl->length * sizeof(dns_aclelement_t));
-		isc_mem_put(acl->mctx, acl->elements,
-			    acl->alloc * sizeof(dns_aclelement_t));
-		acl->elements = newmem;
-		acl->alloc = newalloc;
-	}
-	/*
-	 * Append the new element.
-	 */
-	acl->elements[acl->length++] = *elt;
-
-	return (ISC_R_SUCCESS);
-}
-
+/*
+ * Create a new ACL and initialize it with the value "any" or "none",
+ * depending on the value of the "neg" parameter.
+ * "any" is a positive iptable entry with bit length 0.
+ * "none" is the same as "!any".
+ */
 static isc_result_t
 dns_acl_anyornone(isc_mem_t *mctx, isc_boolean_t neg, dns_acl_t **target) {
 	isc_result_t result;
 	dns_acl_t *acl = NULL;
-	result = dns_acl_create(mctx, 1, &acl);
+	result = dns_acl_create(mctx, 0, &acl);
 	if (result != ISC_R_SUCCESS)
 		return (result);
-	acl->elements[0].negative = neg;
-	acl->elements[0].type = dns_aclelementtype_any;
-	acl->length = 1;
+
+	result = dns_iptable_addprefix(acl->iptable, NULL, 0, ISC_TF(!neg));
+	if (result != ISC_R_SUCCESS) {
+		dns_acl_detach(&acl);
+		return (result);
+	}
+
 	*target = acl;
 	return (result);
 }
 
+/*
+ * Create a new ACL that matches everything.
+ */
 isc_result_t
 dns_acl_any(isc_mem_t *mctx, dns_acl_t **target) {
 	return (dns_acl_anyornone(mctx, ISC_FALSE, target));
 }
 
+/*
+ * Create a new ACL that matches nothing.
+ */
 isc_result_t
 dns_acl_none(isc_mem_t *mctx, dns_acl_t **target) {
 	return (dns_acl_anyornone(mctx, ISC_TRUE, target));
 }
 
+/*
+ * If pos is ISC_TRUE, test whether acl is set to "{ any; }"
+ * If pos is ISC_FALSE, test whether acl is set to "{ none; }"
+ */
+static isc_boolean_t
+dns_acl_isanyornone(dns_acl_t *acl, isc_boolean_t pos)
+{
+	/* Should never happen but let's be safe */
+	if (acl == NULL ||
+	    acl->iptable == NULL ||
+	    acl->iptable->radix == NULL ||
+	    acl->iptable->radix->head == NULL ||
+	    acl->iptable->radix->head->prefix == NULL)
+		return (ISC_FALSE);
+
+	if (acl->length != 0 || acl->node_count != 1)
+		return (ISC_FALSE);
+
+	if (acl->iptable->radix->head->prefix->bitlen == 0 &&
+	    acl->iptable->radix->head->data[0] != NULL &&
+	    acl->iptable->radix->head->data[0] ==
+		    acl->iptable->radix->head->data[1] &&
+	    *(isc_boolean_t *) (acl->iptable->radix->head->data[0]) == pos)
+		return (ISC_TRUE);
+
+	return (ISC_FALSE); /* All others */
+}
+
+/*
+ * Test whether acl is set to "{ any; }"
+ */
+isc_boolean_t
+dns_acl_isany(dns_acl_t *acl)
+{
+	return (dns_acl_isanyornone(acl, ISC_TRUE));
+}
+
+/*
+ * Test whether acl is set to "{ none; }"
+ */
+isc_boolean_t
+dns_acl_isnone(dns_acl_t *acl)
+{
+	return (dns_acl_isanyornone(acl, ISC_FALSE));
+}
+
+/*
+ * Determine whether a given address or signer matches a given ACL.
+ * For a match with a positive ACL element or iptable radix entry,
+ * return with a positive value in match; for a match with a negated ACL
+ * element or radix entry, return with a negative value in match.
+ */
 isc_result_t
 dns_acl_match(const isc_netaddr_t *reqaddr,
 	      const dns_name_t *reqsigner,
 	      const dns_acl_t *acl,
 	      const dns_aclenv_t *env,
 	      int *match,
-	      dns_aclelement_t const**matchelt)
+	      const dns_aclelement_t **matchelt)
 {
+	isc_uint16_t bitlen, family;
+	isc_prefix_t pfx;
+	isc_radix_node_t *node = NULL;
+	const isc_netaddr_t *addr;
+	isc_netaddr_t v4addr;
+	isc_result_t result;
+	int match_num = -1;
 	unsigned int i;
 
 	REQUIRE(reqaddr != NULL);
 	REQUIRE(matchelt == NULL || *matchelt == NULL);
-	
+
+	if (env == NULL || env->match_mapped == ISC_FALSE ||
+	    reqaddr->family != AF_INET6 ||
+	    !IN6_IS_ADDR_V4MAPPED(&reqaddr->type.in6))
+		addr = reqaddr;
+	else {
+		isc_netaddr_fromv4mapped(&v4addr, reqaddr);
+		addr = &v4addr;
+	}
+
+	/* Always match with host addresses. */
+	family = addr->family;
+	bitlen = family == AF_INET6 ? 128 : 32;
+	NETADDR_TO_PREFIX_T(addr, pfx, bitlen);
+
+	/* Assume no match. */
+	*match = 0;
+
+	/* Search radix. */
+	result = isc_radix_search(acl->iptable->radix, &node, &pfx);
+
+	/* Found a match. */
+	if (result == ISC_R_SUCCESS && node != NULL) {
+		match_num = node->node_num[ISC_IS6(family)];
+		if (*(isc_boolean_t *) node->data[ISC_IS6(family)] == ISC_TRUE)
+			*match = match_num;
+		else
+			*match = -match_num;
+	}
+
+	/* Now search non-radix elements for a match with a lower node_num. */
 	for (i = 0; i < acl->length; i++) {
 		dns_aclelement_t *e = &acl->elements[i];
 
+		/* Already found a better match? */
+		if (match_num != -1 && match_num < e->node_num) {
+			isc_refcount_destroy(&pfx.refcount);
+			return (ISC_R_SUCCESS);
+		}
+
 		if (dns_aclelement_match(reqaddr, reqsigner,
 					 e, env, matchelt)) {
-			*match = e->negative ? -((int)i+1) : ((int)i+1);
+			if (match_num == -1 || e->node_num < match_num) {
+				if (e->negative == ISC_TRUE)
+					*match = -e->node_num;
+				else
+					*match = e->node_num;
+			}
+			isc_refcount_destroy(&pfx.refcount);
 			return (ISC_R_SUCCESS);
 		}
 	}
-	/* No match. */
-	*match = 0;
+
+	isc_refcount_destroy(&pfx.refcount);
 	return (ISC_R_SUCCESS);
 }
 
+/*
+ * Merge the contents of one ACL into another.  Call dns_iptable_merge()
+ * for the IP tables, then concatenate the element arrays.
+ *
+ * If pos is set to false, then the nested ACL is to be negated.  This
+ * means reverse the sense of each *positive* element or IP table node,
+ * but leave negatives alone, so as to prevent a double-negative causing
+ * an unexpected positive match in the parent ACL.
+ */
 isc_result_t
-dns_acl_elementmatch(const dns_acl_t *acl,
-		     const dns_aclelement_t *elt,
-		     const dns_aclelement_t **matchelt)
+dns_acl_merge(dns_acl_t *dest, dns_acl_t *source, isc_boolean_t pos)
 {
-	unsigned int i;
+	isc_result_t result;
+	unsigned int newalloc, nelem, i;
+	int max_node = 0, nodes;
 
-	REQUIRE(elt != NULL);
-	REQUIRE(matchelt == NULL || *matchelt == NULL);
-	
-	for (i = 0; i < acl->length; i++) {
-		dns_aclelement_t *e = &acl->elements[i];
+	/* Resize the element array if needed. */
+	if (dest->length + source->length > dest->alloc) {
+		void *newmem;
 
-		if (dns_aclelement_equal(e, elt) == ISC_TRUE) {
-			if (matchelt != NULL)
-				*matchelt = e;
-			return (ISC_R_SUCCESS);
+		newalloc = dest->alloc + source->alloc;
+		if (newalloc < 4)
+			newalloc = 4;
+
+		newmem = isc_mem_get(dest->mctx,
+				     newalloc * sizeof(dns_aclelement_t));
+		if (newmem == NULL)
+			return (ISC_R_NOMEMORY);
+
+		/* Copy in the original elements */
+		memcpy(newmem, dest->elements,
+		       dest->length * sizeof(dns_aclelement_t));
+
+		/* Release the memory for the old elements array */
+		isc_mem_put(dest->mctx, dest->elements,
+			    dest->alloc * sizeof(dns_aclelement_t));
+		dest->elements = newmem;
+		dest->alloc = newalloc;
+	}
+
+	/*
+	 * Now copy in the new elements, increasing their node_num
+	 * values so as to keep the new ACL consistent.  If we're
+	 * negating, then negate positive elements, but keep negative
+	 * elements the same for security reasons.
+	 */
+	nelem = dest->length;
+	dest->length += source->length;
+	for (i = 0; i < source->length; i++) {
+		if (source->elements[i].node_num > max_node)
+			max_node = source->elements[i].node_num;
+
+		/* Copy type. */
+		dest->elements[nelem + i].type = source->elements[i].type;
+
+		/* Adjust node numbering. */
+		dest->elements[nelem + i].node_num =
+			source->elements[i].node_num + dest->node_count;
+
+		/* Duplicate nested acl. */
+		if (source->elements[i].type == dns_aclelementtype_nestedacl &&
+		   source->elements[i].nestedacl != NULL)
+			dns_acl_attach(source->elements[i].nestedacl,
+				       &dest->elements[nelem + i].nestedacl);
+
+		/* Duplicate key name. */
+		if (source->elements[i].type == dns_aclelementtype_keyname) {
+			dns_name_init(&dest->elements[nelem+i].keyname, NULL);
+			result = dns_name_dup(&source->elements[i].keyname,
+					      dest->mctx,
+					      &dest->elements[nelem+i].keyname);
+			if (result != ISC_R_SUCCESS)
+				return result;
+		}
+
+		/* reverse sense of positives if this is a negative acl */
+		if (!pos && source->elements[i].negative == ISC_FALSE) {
+			dest->elements[nelem + i].negative = ISC_TRUE;
+		} else {
+			dest->elements[nelem + i].negative =
+				source->elements[i].negative;
 		}
 	}
 
-	return (ISC_R_NOTFOUND);
+
+	/*
+	 * Merge the iptables.  Make sure the destination ACL's
+	 * node_count value is set correctly afterward.
+	 */
+	nodes = max_node + dest->node_count;
+	result = dns_iptable_merge(dest->iptable, source->iptable, pos);
+	if (result != ISC_R_SUCCESS)
+		return (result);
+	if (nodes > dest->node_count)
+		dest->node_count = nodes;
+
+	return (ISC_R_SUCCESS);
 }
 
+/*
+ * Like dns_acl_match, but matches against the single ACL element 'e'
+ * rather than a complete ACL, and returns ISC_TRUE iff it matched.
+ *
+ * To determine whether the match was positive or negative, the
+ * caller should examine e->negative.  Since the element 'e' may be
+ * a reference to a named ACL or a nested ACL, a matching element
+ * returned through 'matchelt' is not necessarily 'e' itself.
+ */
 isc_boolean_t
 dns_aclelement_match(const isc_netaddr_t *reqaddr,
 		     const dns_name_t *reqsigner,
@@ -186,92 +373,68 @@ dns_aclelement_match(const isc_netaddr_t *reqaddr,
 		     const dns_aclelement_t **matchelt)
 {
 	dns_acl_t *inner = NULL;
-	const isc_netaddr_t *addr;
-	isc_netaddr_t v4addr;
 	int indirectmatch;
 	isc_result_t result;
 
 	switch (e->type) {
-	case dns_aclelementtype_ipprefix:
-		if (env == NULL ||
-		    env->match_mapped == ISC_FALSE ||
-		    reqaddr->family != AF_INET6 ||
-		    !IN6_IS_ADDR_V4MAPPED(&reqaddr->type.in6))
-			addr = reqaddr;
-		else {
-			isc_netaddr_fromv4mapped(&v4addr, reqaddr);
-			addr = &v4addr;
-		}
-
-		if (isc_netaddr_eqprefix(addr,
-					 &e->u.ip_prefix.address, 
-					 e->u.ip_prefix.prefixlen))
-			goto matched;
-		break;
-		
 	case dns_aclelementtype_keyname:
 		if (reqsigner != NULL &&
-		    dns_name_equal(reqsigner, &e->u.keyname))
-			goto matched;
-		break;
-		
+		    dns_name_equal(reqsigner, &e->keyname)) {
+			if (matchelt != NULL)
+				*matchelt = e;
+			return (ISC_TRUE);
+		} else {
+			return (ISC_FALSE);
+		}
+
 	case dns_aclelementtype_nestedacl:
-		inner = e->u.nestedacl;
-	nested:
-		result = dns_acl_match(reqaddr, reqsigner,
-				       inner,
-				       env,
-				       &indirectmatch, matchelt);
-		INSIST(result == ISC_R_SUCCESS);
-
-		/*
-		 * Treat negative matches in indirect ACLs as
-		 * "no match".
-		 * That way, a negated indirect ACL will never become 
-		 * a surprise positive match through double negation.
-		 * XXXDCL this should be documented.
-		 */
-		if (indirectmatch > 0)
-			goto matchelt_set;
-		
-		/*
-		 * A negative indirect match may have set *matchelt,
-		 * but we don't want it set when we return.
-		 */
-		if (matchelt != NULL)
-			*matchelt = NULL;
+		inner = e->nestedacl;
 		break;
-		
-	case dns_aclelementtype_any:
-	matched:
-		if (matchelt != NULL)
-			*matchelt = e;
-	matchelt_set:
-		return (ISC_TRUE);
-			
+
 	case dns_aclelementtype_localhost:
-		if (env != NULL && env->localhost != NULL) {
-			inner = env->localhost;
-			goto nested;
-		} else {
-			break;
-		}
-		
+		if (env == NULL || env->localhost == NULL)
+			return (ISC_FALSE);
+		inner = env->localhost;
+		break;
+
 	case dns_aclelementtype_localnets:
-		if (env != NULL && env->localnets != NULL) {
-			inner = env->localnets;
-			goto nested;
-		} else {
-			break;
-		}
-		
+		if (env == NULL || env->localnets == NULL)
+			return (ISC_FALSE);
+		inner = env->localnets;
+		break;
+
 	default:
+		/* Should be impossible. */
 		INSIST(0);
-		break;
 	}
 
+	result = dns_acl_match(reqaddr, reqsigner, inner, env,
+			       &indirectmatch, matchelt);
+	INSIST(result == ISC_R_SUCCESS);
+
+	/*
+	 * Treat negative matches in indirect ACLs as "no match".
+	 * That way, a negated indirect ACL will never become a
+	 * surprise positive match through double negation.
+	 * XXXDCL this should be documented.
+	 */
+
+	if (indirectmatch > 0) {
+		if (matchelt != NULL)
+			*matchelt = e;
+		return (ISC_TRUE);
+	}
+
+	/*
+	 * A negative indirect match may have set *matchelt, but we don't
+	 * want it set when we return.
+	 */
+
+	if (matchelt != NULL)
+		*matchelt = NULL;
+
 	return (ISC_FALSE);
-}	
+}
 
 void
 dns_acl_attach(dns_acl_t *source, dns_acl_t **target) {
@@ -285,15 +448,10 @@ destroy(dns_acl_t *dacl) {
 	unsigned int i;
 	for (i = 0; i < dacl->length; i++) {
 		dns_aclelement_t *de = &dacl->elements[i];
-		switch (de->type) {
-		case dns_aclelementtype_keyname:
-			dns_name_free(&de->u.keyname, dacl->mctx);
-			break;
-		case dns_aclelementtype_nestedacl:
-			dns_acl_detach(&de->u.nestedacl);
-			break;
-		default:
-			break;
+		if (de->type == dns_aclelementtype_keyname) {
+			dns_name_free(&de->keyname, dacl->mctx);
+		} else if (de->type == dns_aclelementtype_nestedacl) {
+			dns_acl_detach(&de->nestedacl);
 		}
 	}
 	if (dacl->elements != NULL)
@@ -301,6 +459,8 @@ destroy(dns_acl_t *dacl) {
 			    dacl->alloc * sizeof(dns_aclelement_t));
 	if (dacl->name != NULL)
 		isc_mem_free(dacl->mctx, dacl->name);
+	if (dacl->iptable != NULL)
+		dns_iptable_detach(&dacl->iptable);
 	isc_refcount_destroy(&dacl->refcount);
 	dacl->magic = 0;
 	isc_mem_put(dacl->mctx, dacl, sizeof(*dacl));
@@ -317,69 +477,83 @@ dns_acl_detach(dns_acl_t **aclp) {
 	*aclp = NULL;
 }
 
-isc_boolean_t
-dns_aclelement_equal(const dns_aclelement_t *ea, const dns_aclelement_t *eb) {
-	if (ea->type != eb->type)
-		return (ISC_FALSE);
-	switch (ea->type) {
-	case dns_aclelementtype_ipprefix:
-		if (ea->u.ip_prefix.prefixlen !=
-		    eb->u.ip_prefix.prefixlen)
-			return (ISC_FALSE);
-		return (isc_netaddr_eqprefix(&ea->u.ip_prefix.address,
-					     &eb->u.ip_prefix.address,
-					     ea->u.ip_prefix.prefixlen));
-	case dns_aclelementtype_keyname:
-		return (dns_name_equal(&ea->u.keyname, &eb->u.keyname));
-	case dns_aclelementtype_nestedacl:
-		return (dns_acl_equal(ea->u.nestedacl, eb->u.nestedacl));
-	case dns_aclelementtype_localhost:
-	case dns_aclelementtype_localnets:
-	case dns_aclelementtype_any:
-		return (ISC_TRUE);
-	default:
-		INSIST(0);
-		return (ISC_FALSE);
-	}
+
+static isc_once_t	insecure_prefix_once = ISC_ONCE_INIT;
+static isc_mutex_t	insecure_prefix_lock;
+static isc_boolean_t	insecure_prefix_found;
+
+static void
+initialize_action(void) {
+	RUNTIME_CHECK(isc_mutex_init(&insecure_prefix_lock) == ISC_R_SUCCESS);
 }
 
-isc_boolean_t
-dns_acl_equal(const dns_acl_t *a, const dns_acl_t *b) {
-	unsigned int i;
-	if (a == b)
-		return (ISC_TRUE);
-	if (a->length != b->length)
-		return (ISC_FALSE);
-	for (i = 0; i < a->length; i++) {
-		if (! dns_aclelement_equal(&a->elements[i],
-					   &b->elements[i]))
-			return (ISC_FALSE);
+/*
+ * Called via isc_radix_walk() to find IP table nodes that are
+ * insecure.
+ */
+static void
+is_insecure(isc_prefix_t *prefix, void **data) {
+	isc_boolean_t secure;
+	int bitlen, family;
+
+	bitlen = prefix->bitlen;
+	family = prefix->family;
+
+	/* Negated entries are always secure. */
+	secure = * (isc_boolean_t *)data[ISC_IS6(family)];
+	if (!secure) {
+		return;
 	}
-	return (ISC_TRUE);
-}
 
-static isc_boolean_t
-is_loopback(const dns_aclipprefix_t *p) {
-	switch (p->address.family) {
+	/* If loopback prefix found, return */
+	switch (family) {
 	case AF_INET:
-		if (p->prefixlen == 32 &&
-		    htonl(p->address.type.in.s_addr) == INADDR_LOOPBACK)
-			return (ISC_TRUE);
+		if (bitlen == 32 &&
+		    htonl(prefix->add.sin.s_addr) == INADDR_LOOPBACK)
+			return;
 		break;
 	case AF_INET6:
-		if (p->prefixlen == 128 &&
-		    IN6_IS_ADDR_LOOPBACK(&p->address.type.in6))
-			return (ISC_TRUE);
+		if (bitlen == 128 && IN6_IS_ADDR_LOOPBACK(&prefix->add.sin6))
+			return;
 		break;
 	default:
 		break;
 	}
-	return (ISC_FALSE);
+
+	/* Non-negated, non-loopback */
+	insecure_prefix_found = ISC_TRUE;	/* LOCKED */
+	return;
 }
 
+/*
+ * Return ISC_TRUE iff the acl 'a' is considered insecure, that is,
+ * if it contains IP addresses other than those of the local host.
+ * This is intended for applications such as printing warning
+ * messages for suspect ACLs; it is not intended for making access
+ * control decisions.  We make no guarantee that an ACL for which
+ * this function returns ISC_FALSE is safe.
+ */
 isc_boolean_t
 dns_acl_isinsecure(const dns_acl_t *a) {
 	unsigned int i;
+	isc_boolean_t insecure;
+
+	RUNTIME_CHECK(isc_once_do(&insecure_prefix_once,
+				  initialize_action) == ISC_R_SUCCESS);
+
+	/*
+	 * Walk radix tree to find out if there are any non-negated,
+	 * non-loopback prefixes.
+	 */
+	LOCK(&insecure_prefix_lock);
+	insecure_prefix_found = ISC_FALSE;
+	isc_radix_process(a->iptable->radix, is_insecure);
+	insecure = insecure_prefix_found;
+	UNLOCK(&insecure_prefix_lock);
+	if (insecure)
+		return(ISC_TRUE);
+
+	/* Now check non-radix elements */
 	for (i = 0; i < a->length; i++) {
 		dns_aclelement_t *e = &a->elements[i];
 
@@ -388,23 +562,16 @@ dns_acl_isinsecure(const dns_acl_t *a) {
 			continue;
 
 		switch (e->type) {
-		case dns_aclelementtype_ipprefix:
-			/* The loopback address is considered secure. */
-			if (! is_loopback(&e->u.ip_prefix))
-				return (ISC_TRUE);
-			continue;
-			
 		case dns_aclelementtype_keyname:
 		case dns_aclelementtype_localhost:
 			continue;
 
 		case dns_aclelementtype_nestedacl:
-			if (dns_acl_isinsecure(e->u.nestedacl))
+			if (dns_acl_isinsecure(e->nestedacl))
 				return (ISC_TRUE);
 			continue;
-			
+
 		case dns_aclelementtype_localnets:
-		case dns_aclelementtype_any:
 			return (ISC_TRUE);
 
 		default:
@@ -412,10 +579,14 @@ dns_acl_isinsecure(const dns_acl_t *a) {
 			return (ISC_TRUE);
 		}
 	}
+
 	/* No insecure elements were found. */
 	return (ISC_FALSE);
 }
 
+/*
+ * Initialize ACL environment, setting up localhost and localnets ACLs
+ */
 isc_result_t
 dns_aclenv_init(isc_mem_t *mctx, dns_aclenv_t *env) {
 	isc_result_t result;
diff --git a/contrib/bind9/lib/dns/adb.c b/contrib/bind9/lib/dns/adb.c
index ae5dec8..7056215 100644
--- a/contrib/bind9/lib/dns/adb.c
+++ b/contrib/bind9/lib/dns/adb.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: adb.c,v 1.215.18.24 2008/10/17 03:35:14 marka Exp $ */
+/* $Id: adb.c,v 1.243.42.4 2009/02/03 22:34:28 jinmei Exp $ */
 
 /*! \file
  *
@@ -26,13 +26,6 @@
  *
  */
 
-/*%
- * After we have cleaned all buckets, dump the database contents.
- */
-#if 0
-#define DUMP_ADB_AFTER_CLEANING
-#endif
-
 #include <config.h>
 
 #include <limits.h>
@@ -40,9 +33,9 @@
 #include <isc/mutexblock.h>
 #include <isc/netaddr.h>
 #include <isc/random.h>
-#include <isc/string.h>		/* Required for HP/UX (and others?) */
+#include <isc/stats.h>
+#include <isc/string.h>         /* Required for HP/UX (and others?) */
 #include <isc/task.h>
-#include <isc/timer.h>
 #include <isc/util.h>
 
 #include <dns/adb.h>
@@ -55,28 +48,29 @@
 #include <dns/rdatatype.h>
 #include <dns/resolver.h>
 #include <dns/result.h>
+#include <dns/stats.h>
 
-#define DNS_ADB_MAGIC		  ISC_MAGIC('D', 'a', 'd', 'b')
-#define DNS_ADB_VALID(x)	  ISC_MAGIC_VALID(x, DNS_ADB_MAGIC)
-#define DNS_ADBNAME_MAGIC	  ISC_MAGIC('a', 'd', 'b', 'N')
-#define DNS_ADBNAME_VALID(x)	  ISC_MAGIC_VALID(x, DNS_ADBNAME_MAGIC)
-#define DNS_ADBNAMEHOOK_MAGIC	  ISC_MAGIC('a', 'd', 'N', 'H')
+#define DNS_ADB_MAGIC             ISC_MAGIC('D', 'a', 'd', 'b')
+#define DNS_ADB_VALID(x)          ISC_MAGIC_VALID(x, DNS_ADB_MAGIC)
+#define DNS_ADBNAME_MAGIC         ISC_MAGIC('a', 'd', 'b', 'N')
+#define DNS_ADBNAME_VALID(x)      ISC_MAGIC_VALID(x, DNS_ADBNAME_MAGIC)
+#define DNS_ADBNAMEHOOK_MAGIC     ISC_MAGIC('a', 'd', 'N', 'H')
 #define DNS_ADBNAMEHOOK_VALID(x)  ISC_MAGIC_VALID(x, DNS_ADBNAMEHOOK_MAGIC)
-#define DNS_ADBLAMEINFO_MAGIC	  ISC_MAGIC('a', 'd', 'b', 'Z')
+#define DNS_ADBLAMEINFO_MAGIC     ISC_MAGIC('a', 'd', 'b', 'Z')
 #define DNS_ADBLAMEINFO_VALID(x)  ISC_MAGIC_VALID(x, DNS_ADBLAMEINFO_MAGIC)
-#define DNS_ADBENTRY_MAGIC	  ISC_MAGIC('a', 'd', 'b', 'E')
-#define DNS_ADBENTRY_VALID(x)	  ISC_MAGIC_VALID(x, DNS_ADBENTRY_MAGIC)
-#define DNS_ADBFETCH_MAGIC	  ISC_MAGIC('a', 'd', 'F', '4')
-#define DNS_ADBFETCH_VALID(x)	  ISC_MAGIC_VALID(x, DNS_ADBFETCH_MAGIC)
-#define DNS_ADBFETCH6_MAGIC	  ISC_MAGIC('a', 'd', 'F', '6')
-#define DNS_ADBFETCH6_VALID(x)	  ISC_MAGIC_VALID(x, DNS_ADBFETCH6_MAGIC)
+#define DNS_ADBENTRY_MAGIC        ISC_MAGIC('a', 'd', 'b', 'E')
+#define DNS_ADBENTRY_VALID(x)     ISC_MAGIC_VALID(x, DNS_ADBENTRY_MAGIC)
+#define DNS_ADBFETCH_MAGIC        ISC_MAGIC('a', 'd', 'F', '4')
+#define DNS_ADBFETCH_VALID(x)     ISC_MAGIC_VALID(x, DNS_ADBFETCH_MAGIC)
+#define DNS_ADBFETCH6_MAGIC       ISC_MAGIC('a', 'd', 'F', '6')
+#define DNS_ADBFETCH6_VALID(x)    ISC_MAGIC_VALID(x, DNS_ADBFETCH6_MAGIC)
 
 /*!
  * The number of buckets needs to be a prime (for good hashing).
  *
  * XXXRTH  How many buckets do we need?
  */
-#define NBUCKETS	       1009	/*%< how many buckets for names/addrs */
+#define NBUCKETS               1009     /*%< how many buckets for names/addrs */
 
 /*!
  * For type 3 negative cache entries, we will remember that the address is
@@ -84,26 +78,25 @@
  * The intent is to keep us from constantly asking about A/AAAA records
  * if the zone has extremely low TTLs.
  */
-#define ADB_CACHE_MINIMUM	10	/*%< seconds */
-#define ADB_CACHE_MAXIMUM	86400	/*%< seconds (86400 = 24 hours) */
-#define ADB_ENTRY_WINDOW	1800	/*%< seconds */
+#define ADB_CACHE_MINIMUM       10      /*%< seconds */
+#define ADB_CACHE_MAXIMUM       86400   /*%< seconds (86400 = 24 hours) */
+#define ADB_ENTRY_WINDOW        1800    /*%< seconds */
 
 /*%
- * Wake up every CLEAN_SECONDS and clean CLEAN_BUCKETS buckets, so that all
- * buckets are cleaned in CLEAN_PERIOD seconds.
+ * The period in seconds after which an ADB name entry is regarded as stale
+ * and forced to be cleaned up.
+ * TODO: This should probably be configurable at run-time.
  */
-#define CLEAN_PERIOD		3600
-/*% See #CLEAN_PERIOD */
-#define CLEAN_SECONDS		30
-/*% See #CLEAN_PERIOD */
-#define CLEAN_BUCKETS		((NBUCKETS * CLEAN_SECONDS) / CLEAN_PERIOD)
+#ifndef ADB_STALE_MARGIN
+#define ADB_STALE_MARGIN        1800
+#endif
 
-#define FREE_ITEMS		64	/*%< free count for memory pools */
-#define FILL_COUNT		16	/*%< fill count for memory pools */
+#define FREE_ITEMS              64      /*%< free count for memory pools */
+#define FILL_COUNT              16      /*%< fill count for memory pools */
 
-#define DNS_ADB_INVALIDBUCKET (-1)	/*%< invalid bucket address */
+#define DNS_ADB_INVALIDBUCKET (-1)      /*%< invalid bucket address */
 
-#define DNS_ADB_MINADBSIZE	(1024*1024)	/*%< 1 Megabyte */
+#define DNS_ADB_MINADBSIZE      (1024*1024)     /*%< 1 Megabyte */
 
 typedef ISC_LIST(dns_adbname_t) dns_adbnamelist_t;
 typedef struct dns_adbnamehook dns_adbnamehook_t;
@@ -115,61 +108,62 @@ typedef struct dns_adbfetch6 dns_adbfetch6_t;
 
 /*% dns adb structure */
 struct dns_adb {
-	unsigned int			magic;
+	unsigned int                    magic;
 
-	isc_mutex_t			lock;
-	isc_mutex_t			reflock; /*%< Covers irefcnt, erefcnt */
+	isc_mutex_t                     lock;
+	isc_mutex_t                     reflock; /*%< Covers irefcnt, erefcnt */
 	isc_mutex_t                     overmemlock; /*%< Covers overmem */
-	isc_mem_t		       *mctx;
-	dns_view_t		       *view;
-	isc_timermgr_t		       *timermgr;
-	isc_timer_t		       *timer;
-	isc_taskmgr_t		       *taskmgr;
-	isc_task_t		       *task;
-	isc_boolean_t			overmem;
-
-	isc_interval_t			tick_interval;
-	int				next_cleanbucket;
-
-	unsigned int			irefcnt;
-	unsigned int			erefcnt;
-
-	isc_mutex_t			mplock;
-	isc_mempool_t		       *nmp;	/*%< dns_adbname_t */
-	isc_mempool_t		       *nhmp;	/*%< dns_adbnamehook_t */
-	isc_mempool_t		       *limp;	/*%< dns_adblameinfo_t */
-	isc_mempool_t		       *emp;	/*%< dns_adbentry_t */
-	isc_mempool_t		       *ahmp;	/*%< dns_adbfind_t */
-	isc_mempool_t		       *aimp;	/*%< dns_adbaddrinfo_t */
-	isc_mempool_t		       *afmp;	/*%< dns_adbfetch_t */
+	isc_mem_t                      *mctx;
+	dns_view_t                     *view;
+
+	isc_taskmgr_t                  *taskmgr;
+	isc_task_t                     *task;
+	isc_boolean_t                   overmem;
+
+	isc_interval_t                  tick_interval;
+	int                             next_cleanbucket;
+
+	unsigned int                    irefcnt;
+	unsigned int                    erefcnt;
+
+	isc_mutex_t                     mplock;
+	isc_mempool_t                  *nmp;    /*%< dns_adbname_t */
+	isc_mempool_t                  *nhmp;   /*%< dns_adbnamehook_t */
+	isc_mempool_t                  *limp;   /*%< dns_adblameinfo_t */
+	isc_mempool_t                  *emp;    /*%< dns_adbentry_t */
+	isc_mempool_t                  *ahmp;   /*%< dns_adbfind_t */
+	isc_mempool_t                  *aimp;   /*%< dns_adbaddrinfo_t */
+	isc_mempool_t                  *afmp;   /*%< dns_adbfetch_t */
 
 	/*!
 	 * Bucketized locks and lists for names.
 	 *
 	 * XXXRTH  Have a per-bucket structure that contains all of these?
 	 */
-	dns_adbnamelist_t		names[NBUCKETS];
+	dns_adbnamelist_t               names[NBUCKETS];
+	dns_adbnamelist_t               deadnames[NBUCKETS];
 	/*% See dns_adbnamelist_t */
-	isc_mutex_t			namelocks[NBUCKETS];
+	isc_mutex_t                     namelocks[NBUCKETS];
 	/*% See dns_adbnamelist_t */
-	isc_boolean_t			name_sd[NBUCKETS];
+	isc_boolean_t                   name_sd[NBUCKETS];
 	/*% See dns_adbnamelist_t */
-	unsigned int			name_refcnt[NBUCKETS];
+	unsigned int                    name_refcnt[NBUCKETS];
 
 	/*!
 	 * Bucketized locks for entries.
 	 *
 	 * XXXRTH  Have a per-bucket structure that contains all of these?
 	 */
-	dns_adbentrylist_t		entries[NBUCKETS];
-	isc_mutex_t			entrylocks[NBUCKETS];
-	isc_boolean_t			entry_sd[NBUCKETS]; /*%< shutting down */
-	unsigned int			entry_refcnt[NBUCKETS];
-
-	isc_event_t			cevent;
-	isc_boolean_t			cevent_sent;
-	isc_boolean_t			shutting_down;
-	isc_eventlist_t			whenshutdown;
+	dns_adbentrylist_t              entries[NBUCKETS];
+	dns_adbentrylist_t              deadentries[NBUCKETS];
+	isc_mutex_t                     entrylocks[NBUCKETS];
+	isc_boolean_t                   entry_sd[NBUCKETS]; /*%< shutting down */
+	unsigned int                    entry_refcnt[NBUCKETS];
+
+	isc_event_t                     cevent;
+	isc_boolean_t                   cevent_sent;
+	isc_boolean_t                   shutting_down;
+	isc_eventlist_t                 whenshutdown;
 };
 
 /*
@@ -178,34 +172,35 @@ struct dns_adb {
 
 /*% dns_adbname structure */
 struct dns_adbname {
-	unsigned int			magic;
-	dns_name_t			name;
-	dns_adb_t		       *adb;
-	unsigned int			partial_result;
-	unsigned int			flags;
-	int				lock_bucket;
-	dns_name_t			target;
-	isc_stdtime_t			expire_target;
-	isc_stdtime_t			expire_v4;
-	isc_stdtime_t			expire_v6;
-	unsigned int			chains;
-	dns_adbnamehooklist_t		v4;
-	dns_adbnamehooklist_t		v6;
-	dns_adbfetch_t		       *fetch_a;
-	dns_adbfetch_t		       *fetch_aaaa;
-	unsigned int			fetch_err;
-	unsigned int			fetch6_err;
-	dns_adbfindlist_t		finds;
-	ISC_LINK(dns_adbname_t)		plink;
+	unsigned int                    magic;
+	dns_name_t                      name;
+	dns_adb_t                      *adb;
+	unsigned int                    partial_result;
+	unsigned int                    flags;
+	int                             lock_bucket;
+	dns_name_t                      target;
+	isc_stdtime_t                   expire_target;
+	isc_stdtime_t                   expire_v4;
+	isc_stdtime_t                   expire_v6;
+	unsigned int                    chains;
+	dns_adbnamehooklist_t           v4;
+	dns_adbnamehooklist_t           v6;
+	dns_adbfetch_t                 *fetch_a;
+	dns_adbfetch_t                 *fetch_aaaa;
+	unsigned int                    fetch_err;
+	unsigned int                    fetch6_err;
+	dns_adbfindlist_t               finds;
+	/* for LRU-based management */
+	isc_stdtime_t                   last_used;
+
+	ISC_LINK(dns_adbname_t)         plink;
 };
 
 /*% The adbfetch structure */
 struct dns_adbfetch {
-	unsigned int			magic;
-	dns_adbnamehook_t	       *namehook;
-	dns_adbentry_t		       *entry;
-	dns_fetch_t		       *fetch;
-	dns_rdataset_t			rdataset;
+	unsigned int                    magic;
+	dns_fetch_t                    *fetch;
+	dns_rdataset_t                  rdataset;
 };
 
 /*%
@@ -214,9 +209,9 @@ struct dns_adbfetch {
  * namehook that will contain the next address this host has.
  */
 struct dns_adbnamehook {
-	unsigned int			magic;
-	dns_adbentry_t		       *entry;
-	ISC_LINK(dns_adbnamehook_t)	plink;
+	unsigned int                    magic;
+	dns_adbentry_t                 *entry;
+	ISC_LINK(dns_adbnamehook_t)     plink;
 };
 
 /*%
@@ -225,13 +220,13 @@ struct dns_adbnamehook {
  * extended to other types of information about zones.
  */
 struct dns_adblameinfo {
-	unsigned int			magic;
+	unsigned int                    magic;
 
-	dns_name_t			qname;
-	dns_rdatatype_t			qtype;
-	isc_stdtime_t			lame_timer;
+	dns_name_t                      qname;
+	dns_rdatatype_t                 qtype;
+	isc_stdtime_t                   lame_timer;
 
-	ISC_LINK(dns_adblameinfo_t)	plink;
+	ISC_LINK(dns_adblameinfo_t)     plink;
 };
 
 /*%
@@ -240,16 +235,16 @@ struct dns_adblameinfo {
  * the host.
  */
 struct dns_adbentry {
-	unsigned int			magic;
+	unsigned int                    magic;
 
-	int				lock_bucket;
-	unsigned int			refcnt;
+	int                             lock_bucket;
+	unsigned int                    refcnt;
 
-	unsigned int			flags;
-	unsigned int			srtt;
-	isc_sockaddr_t			sockaddr;
+	unsigned int                    flags;
+	unsigned int                    srtt;
+	isc_sockaddr_t                  sockaddr;
 
-	isc_stdtime_t			expires;
+	isc_stdtime_t                   expires;
 	/*%<
 	 * A nonzero 'expires' field indicates that the entry should
 	 * persist until that time.  This allows entries found
@@ -258,8 +253,8 @@ struct dns_adbentry {
 	 * name.
 	 */
 
-	ISC_LIST(dns_adblameinfo_t)	lameinfo;
-	ISC_LINK(dns_adbentry_t)	plink;
+	ISC_LIST(dns_adblameinfo_t)     lameinfo;
+	ISC_LINK(dns_adbentry_t)        plink;
 };
 
 /*
@@ -284,7 +279,8 @@ static inline void free_adbfetch(dns_adb_t *, dns_adbfetch_t **);
 static inline dns_adbname_t *find_name_and_lock(dns_adb_t *, dns_name_t *,
 						unsigned int, int *);
 static inline dns_adbentry_t *find_entry_and_lock(dns_adb_t *,
-						  isc_sockaddr_t *, int *);
+						  isc_sockaddr_t *, int *,
+						  isc_stdtime_t);
 static void dump_adb(dns_adb_t *, FILE *, isc_boolean_t debug, isc_stdtime_t);
 static void print_dns_name(FILE *, dns_name_t *);
 static void print_namehook_list(FILE *, const char *legend,
@@ -305,15 +301,15 @@ static isc_boolean_t clean_namehooks(dns_adb_t *, dns_adbnamehooklist_t *);
 static void clean_target(dns_adb_t *, dns_name_t *);
 static void clean_finds_at_name(dns_adbname_t *, isc_eventtype_t,
 				unsigned int);
-static isc_boolean_t check_expire_namehooks(dns_adbname_t *, isc_stdtime_t,
-					    isc_boolean_t);
+static isc_boolean_t check_expire_namehooks(dns_adbname_t *, isc_stdtime_t);
+static isc_boolean_t check_expire_entry(dns_adb_t *, dns_adbentry_t **,
+					isc_stdtime_t);
 static void cancel_fetches_at_name(dns_adbname_t *);
 static isc_result_t dbfind_name(dns_adbname_t *, isc_stdtime_t,
 				dns_rdatatype_t);
 static isc_result_t fetch_name(dns_adbname_t *, isc_boolean_t,
 			       dns_rdatatype_t);
 static inline void check_exit(dns_adb_t *);
-static void timer_cleanup(isc_task_t *, isc_event_t *);
 static void destroy(dns_adb_t *);
 static isc_boolean_t shutdown_names(dns_adb_t *);
 static isc_boolean_t shutdown_entries(dns_adb_t *);
@@ -328,28 +324,34 @@ static void dump_entry(FILE *, dns_adbentry_t *, isc_boolean_t, isc_stdtime_t);
 /*
  * MUST NOT overlap DNS_ADBFIND_* flags!
  */
-#define FIND_EVENT_SENT		0x40000000
-#define FIND_EVENT_FREED	0x80000000
-#define FIND_EVENTSENT(h)	(((h)->flags & FIND_EVENT_SENT) != 0)
-#define FIND_EVENTFREED(h)	(((h)->flags & FIND_EVENT_FREED) != 0)
-
-#define NAME_NEEDS_POKE		0x80000000
-#define NAME_IS_DEAD		0x40000000
-#define NAME_HINT_OK		DNS_ADBFIND_HINTOK
-#define NAME_GLUE_OK		DNS_ADBFIND_GLUEOK
-#define NAME_STARTATZONE	DNS_ADBFIND_STARTATZONE
-#define NAME_DEAD(n)		(((n)->flags & NAME_IS_DEAD) != 0)
-#define NAME_NEEDSPOKE(n)	(((n)->flags & NAME_NEEDS_POKE) != 0)
-#define NAME_GLUEOK(n)		(((n)->flags & NAME_GLUE_OK) != 0)
-#define NAME_HINTOK(n)		(((n)->flags & NAME_HINT_OK) != 0)
+#define FIND_EVENT_SENT         0x40000000
+#define FIND_EVENT_FREED        0x80000000
+#define FIND_EVENTSENT(h)       (((h)->flags & FIND_EVENT_SENT) != 0)
+#define FIND_EVENTFREED(h)      (((h)->flags & FIND_EVENT_FREED) != 0)
+
+#define NAME_NEEDS_POKE         0x80000000
+#define NAME_IS_DEAD            0x40000000
+#define NAME_HINT_OK            DNS_ADBFIND_HINTOK
+#define NAME_GLUE_OK            DNS_ADBFIND_GLUEOK
+#define NAME_STARTATZONE        DNS_ADBFIND_STARTATZONE
+#define NAME_DEAD(n)            (((n)->flags & NAME_IS_DEAD) != 0)
+#define NAME_NEEDSPOKE(n)       (((n)->flags & NAME_NEEDS_POKE) != 0)
+#define NAME_GLUEOK(n)          (((n)->flags & NAME_GLUE_OK) != 0)
+#define NAME_HINTOK(n)          (((n)->flags & NAME_HINT_OK) != 0)
+
+/*
+ * Private flag(s) for entries.
+ * MUST NOT overlap FCTX_ADDRINFO_xxx and DNS_FETCHOPT_NOEDNS0.
+ */
+#define ENTRY_IS_DEAD		0x80000000
 
 /*
  * To the name, address classes are all that really exist.  If it has a
  * V6 address it doesn't care if it came from a AAAA query.
  */
-#define NAME_HAS_V4(n)		(!ISC_LIST_EMPTY((n)->v4))
-#define NAME_HAS_V6(n)		(!ISC_LIST_EMPTY((n)->v6))
-#define NAME_HAS_ADDRS(n)	(NAME_HAS_V4(n) || NAME_HAS_V6(n))
+#define NAME_HAS_V4(n)          (!ISC_LIST_EMPTY((n)->v4))
+#define NAME_HAS_V6(n)          (!ISC_LIST_EMPTY((n)->v6))
+#define NAME_HAS_ADDRS(n)       (NAME_HAS_V4(n) || NAME_HAS_V6(n))
 
 /*
  * Fetches are broken out into A and AAAA types.  In some cases,
@@ -358,34 +360,34 @@ static void dump_entry(FILE *, dns_adbentry_t *, isc_boolean_t, isc_stdtime_t);
  * Note: since we have removed the support of A6 in adb, FETCH_A and FETCH_AAAA
  * are now equal to FETCH_V4 and FETCH_V6, respectively.
  */
-#define NAME_FETCH_A(n)		((n)->fetch_a != NULL)
-#define NAME_FETCH_AAAA(n)	((n)->fetch_aaaa != NULL)
-#define NAME_FETCH_V4(n)	(NAME_FETCH_A(n))
-#define NAME_FETCH_V6(n)	(NAME_FETCH_AAAA(n))
-#define NAME_FETCH(n)		(NAME_FETCH_V4(n) || NAME_FETCH_V6(n))
+#define NAME_FETCH_A(n)         ((n)->fetch_a != NULL)
+#define NAME_FETCH_AAAA(n)      ((n)->fetch_aaaa != NULL)
+#define NAME_FETCH_V4(n)        (NAME_FETCH_A(n))
+#define NAME_FETCH_V6(n)        (NAME_FETCH_AAAA(n))
+#define NAME_FETCH(n)           (NAME_FETCH_V4(n) || NAME_FETCH_V6(n))
 
 /*
  * Find options and tests to see if there are addresses on the list.
  */
-#define FIND_WANTEVENT(fn)	(((fn)->options & DNS_ADBFIND_WANTEVENT) != 0)
-#define FIND_WANTEMPTYEVENT(fn)	(((fn)->options & DNS_ADBFIND_EMPTYEVENT) != 0)
-#define FIND_AVOIDFETCHES(fn)	(((fn)->options & DNS_ADBFIND_AVOIDFETCHES) \
+#define FIND_WANTEVENT(fn)      (((fn)->options & DNS_ADBFIND_WANTEVENT) != 0)
+#define FIND_WANTEMPTYEVENT(fn) (((fn)->options & DNS_ADBFIND_EMPTYEVENT) != 0)
+#define FIND_AVOIDFETCHES(fn)   (((fn)->options & DNS_ADBFIND_AVOIDFETCHES) \
 				 != 0)
-#define FIND_STARTATZONE(fn)	(((fn)->options & DNS_ADBFIND_STARTATZONE) \
+#define FIND_STARTATZONE(fn)    (((fn)->options & DNS_ADBFIND_STARTATZONE) \
 				 != 0)
-#define FIND_HINTOK(fn)		(((fn)->options & DNS_ADBFIND_HINTOK) != 0)
-#define FIND_GLUEOK(fn)		(((fn)->options & DNS_ADBFIND_GLUEOK) != 0)
-#define FIND_HAS_ADDRS(fn)	(!ISC_LIST_EMPTY((fn)->list))
-#define FIND_RETURNLAME(fn)	(((fn)->options & DNS_ADBFIND_RETURNLAME) != 0)
+#define FIND_HINTOK(fn)         (((fn)->options & DNS_ADBFIND_HINTOK) != 0)
+#define FIND_GLUEOK(fn)         (((fn)->options & DNS_ADBFIND_GLUEOK) != 0)
+#define FIND_HAS_ADDRS(fn)      (!ISC_LIST_EMPTY((fn)->list))
+#define FIND_RETURNLAME(fn)     (((fn)->options & DNS_ADBFIND_RETURNLAME) != 0)
 
 /*
  * These are currently used on simple unsigned ints, so they are
  * not really associated with any particular type.
  */
-#define WANT_INET(x)		(((x) & DNS_ADBFIND_INET) != 0)
-#define WANT_INET6(x)		(((x) & DNS_ADBFIND_INET6) != 0)
+#define WANT_INET(x)            (((x) & DNS_ADBFIND_INET) != 0)
+#define WANT_INET6(x)           (((x) & DNS_ADBFIND_INET6) != 0)
 
-#define EXPIRE_OK(exp, now)	((exp == INT_MAX) || (exp < now))
+#define EXPIRE_OK(exp, now)     ((exp == INT_MAX) || (exp < now))
 
 /*
  * Find out if the flags on a name (nf) indicate if it is a hint or
@@ -398,19 +400,19 @@ static void dump_entry(FILE *, dns_adbentry_t *, isc_boolean_t, isc_stdtime_t);
 #define STARTATZONE_MATCHES(nf, o) (((nf)->flags & NAME_STARTATZONE) == \
 				    ((o) & DNS_ADBFIND_STARTATZONE))
 
-#define ENTER_LEVEL		ISC_LOG_DEBUG(50)
-#define EXIT_LEVEL		ENTER_LEVEL
-#define CLEAN_LEVEL		ISC_LOG_DEBUG(100)
-#define DEF_LEVEL		ISC_LOG_DEBUG(5)
-#define NCACHE_LEVEL		ISC_LOG_DEBUG(20)
+#define ENTER_LEVEL             ISC_LOG_DEBUG(50)
+#define EXIT_LEVEL              ENTER_LEVEL
+#define CLEAN_LEVEL             ISC_LOG_DEBUG(100)
+#define DEF_LEVEL               ISC_LOG_DEBUG(5)
+#define NCACHE_LEVEL            ISC_LOG_DEBUG(20)
 
-#define NCACHE_RESULT(r)	((r) == DNS_R_NCACHENXDOMAIN || \
+#define NCACHE_RESULT(r)        ((r) == DNS_R_NCACHENXDOMAIN || \
 				 (r) == DNS_R_NCACHENXRRSET)
-#define AUTH_NX(r)		((r) == DNS_R_NXDOMAIN || \
+#define AUTH_NX(r)              ((r) == DNS_R_NXDOMAIN || \
 				 (r) == DNS_R_NXRRSET)
-#define NXDOMAIN_RESULT(r)	((r) == DNS_R_NXDOMAIN || \
+#define NXDOMAIN_RESULT(r)      ((r) == DNS_R_NXDOMAIN || \
 				 (r) == DNS_R_NCACHENXDOMAIN)
-#define NXRRSET_RESULT(r)	((r) == DNS_R_NCACHENXRRSET || \
+#define NXRRSET_RESULT(r)       ((r) == DNS_R_NCACHENXRRSET || \
 				 (r) == DNS_R_NXRRSET || \
 				 (r) == DNS_R_HINTNXRRSET)
 
@@ -418,14 +420,14 @@ static void dump_entry(FILE *, dns_adbentry_t *, isc_boolean_t, isc_stdtime_t);
  * Error state rankings.
  */
 
-#define FIND_ERR_SUCCESS		0  /* highest rank */
-#define FIND_ERR_CANCELED		1
-#define FIND_ERR_FAILURE		2
-#define FIND_ERR_NXDOMAIN		3
-#define FIND_ERR_NXRRSET		4
-#define FIND_ERR_UNEXPECTED		5
-#define FIND_ERR_NOTFOUND		6
-#define FIND_ERR_MAX			7
+#define FIND_ERR_SUCCESS                0  /* highest rank */
+#define FIND_ERR_CANCELED               1
+#define FIND_ERR_FAILURE                2
+#define FIND_ERR_NXDOMAIN               3
+#define FIND_ERR_NXRRSET                4
+#define FIND_ERR_UNEXPECTED             5
+#define FIND_ERR_NOTFOUND               6
+#define FIND_ERR_MAX                    7
 
 static const char *errnames[] = {
 	"success",
@@ -437,7 +439,7 @@ static const char *errnames[] = {
 	"not_found"
 };
 
-#define NEWERR(old, new)	(ISC_MIN((old), (new)))
+#define NEWERR(old, new)        (ISC_MIN((old), (new)))
 
 static isc_result_t find_err_map[FIND_ERR_MAX] = {
 	ISC_R_SUCCESS,
@@ -446,7 +448,7 @@ static isc_result_t find_err_map[FIND_ERR_MAX] = {
 	DNS_R_NXDOMAIN,
 	DNS_R_NXRRSET,
 	ISC_R_UNEXPECTED,
-	ISC_R_NOTFOUND		/* not YET found */
+	ISC_R_NOTFOUND          /* not YET found */
 };
 
 static void
@@ -463,6 +465,15 @@ DP(int level, const char *format, ...) {
 	va_end(args);
 }
 
+/*%
+ * Increment resolver-related statistics counters.
+ */
+static inline void
+inc_stats(dns_adb_t *adb, isc_statscounter_t counter) {
+	if (adb->view->resstats != NULL)
+		isc_stats_increment(adb->view->resstats, counter);
+}
+
 static inline dns_ttl_t
 ttlclamp(dns_ttl_t ttl) {
 	if (ttl < ADB_CACHE_MINIMUM)
@@ -536,7 +547,8 @@ import_rdataset(dns_adbname_t *adbname, dns_rdataset_t *rdataset,
 			goto fail;
 		}
 
-		foundentry = find_entry_and_lock(adb, &sockaddr, &addr_bucket);
+		foundentry = find_entry_and_lock(adb, &sockaddr, &addr_bucket,
+						 now);
 		if (foundentry == NULL) {
 			dns_adbentry_t *entry;
 
@@ -617,6 +629,7 @@ kill_name(dns_adbname_t **n, isc_eventtype_t ev) {
 	dns_adbname_t *name;
 	isc_boolean_t result = ISC_FALSE;
 	isc_boolean_t result4, result6;
+	int bucket;
 	dns_adb_t *adb;
 
 	INSIST(n != NULL);
@@ -661,8 +674,13 @@ kill_name(dns_adbname_t **n, isc_eventtype_t ev) {
 		if (result)
 			result = dec_adb_irefcnt(adb);
 	} else {
-		name->flags |= NAME_IS_DEAD;
 		cancel_fetches_at_name(name);
+		if (!NAME_DEAD(name)) {
+			bucket = name->lock_bucket;
+			ISC_LIST_UNLINK(adb->names[bucket], name, plink);
+			ISC_LIST_APPEND(adb->deadnames[bucket], name, plink);
+			name->flags |= NAME_IS_DEAD;
+		}
 	}
 	return (result);
 }
@@ -671,11 +689,8 @@ kill_name(dns_adbname_t **n, isc_eventtype_t ev) {
  * Requires the name's bucket be locked and no entry buckets be locked.
  */
 static isc_boolean_t
-check_expire_namehooks(dns_adbname_t *name, isc_stdtime_t now,
-		       isc_boolean_t overmem)
-{
+check_expire_namehooks(dns_adbname_t *name, isc_stdtime_t now) {
 	dns_adb_t *adb;
-	isc_boolean_t expire;
 	isc_boolean_t result4 = ISC_FALSE;
 	isc_boolean_t result6 = ISC_FALSE;
 
@@ -683,20 +698,10 @@ check_expire_namehooks(dns_adbname_t *name, isc_stdtime_t now,
 	adb = name->adb;
 	INSIST(DNS_ADB_VALID(adb));
 
-	if (overmem) {
-		isc_uint32_t val;
-
-		isc_random_get(&val);
-
-		expire = ISC_TF((val % 4) == 0);
-	} else
-		expire = ISC_FALSE;
-
 	/*
 	 * Check to see if we need to remove the v4 addresses
 	 */
-	if (!NAME_FETCH_V4(name) &&
-	    (expire || EXPIRE_OK(name->expire_v4, now))) {
+	if (!NAME_FETCH_V4(name) && EXPIRE_OK(name->expire_v4, now)) {
 		if (NAME_HAS_V4(name)) {
 			DP(DEF_LEVEL, "expiring v4 for name %p", name);
 			result4 = clean_namehooks(adb, &name->v4);
@@ -709,8 +714,7 @@ check_expire_namehooks(dns_adbname_t *name, isc_stdtime_t now,
 	/*
 	 * Check to see if we need to remove the v6 addresses
 	 */
-	if (!NAME_FETCH_V6(name) &&
-	    (expire || EXPIRE_OK(name->expire_v6, now))) {
+	if (!NAME_FETCH_V6(name) && EXPIRE_OK(name->expire_v6, now)) {
 		if (NAME_HAS_V6(name)) {
 			DP(DEF_LEVEL, "expiring v6 for name %p", name);
 			result6 = clean_namehooks(adb, &name->v6);
@@ -723,7 +727,7 @@ check_expire_namehooks(dns_adbname_t *name, isc_stdtime_t now,
 	/*
 	 * Check to see if we need to remove the alias target.
 	 */
-	if (expire || EXPIRE_OK(name->expire_target, now)) {
+	if (EXPIRE_OK(name->expire_target, now)) {
 		clean_target(adb, &name->target);
 		name->expire_target = INT_MAX;
 	}
@@ -753,7 +757,10 @@ unlink_name(dns_adb_t *adb, dns_adbname_t *name) {
 	bucket = name->lock_bucket;
 	INSIST(bucket != DNS_ADB_INVALIDBUCKET);
 
-	ISC_LIST_UNLINK(adb->names[bucket], name, plink);
+	if (NAME_DEAD(name))
+		ISC_LIST_UNLINK(adb->deadnames[bucket], name, plink);
+	else
+		ISC_LIST_UNLINK(adb->names[bucket], name, plink);
 	name->lock_bucket = DNS_ADB_INVALIDBUCKET;
 	INSIST(adb->name_refcnt[bucket] > 0);
 	adb->name_refcnt[bucket]--;
@@ -767,6 +774,26 @@ unlink_name(dns_adb_t *adb, dns_adbname_t *name) {
  */
 static inline void
 link_entry(dns_adb_t *adb, int bucket, dns_adbentry_t *entry) {
+	int i;
+	dns_adbentry_t *e;
+
+	if (adb->overmem) {
+		for (i = 0; i < 2; i++) {
+			e = ISC_LIST_TAIL(adb->entries[bucket]);
+			if (e == NULL)
+				break;
+			if (e->refcnt == 0) {
+				unlink_entry(adb, e);
+				free_adbentry(adb, &e);
+				continue;
+			}
+			INSIST((e->flags & ENTRY_IS_DEAD) == 0);
+			e->flags |= ENTRY_IS_DEAD;
+			ISC_LIST_UNLINK(adb->entries[bucket], e, plink);
+			ISC_LIST_PREPEND(adb->deadentries[bucket], e, plink);
+		}
+	}
+
 	ISC_LIST_PREPEND(adb->entries[bucket], entry, plink);
 	entry->lock_bucket = bucket;
 	adb->entry_refcnt[bucket]++;
@@ -783,7 +810,10 @@ unlink_entry(dns_adb_t *adb, dns_adbentry_t *entry) {
 	bucket = entry->lock_bucket;
 	INSIST(bucket != DNS_ADB_INVALIDBUCKET);
 
-	ISC_LIST_UNLINK(adb->entries[bucket], entry, plink);
+	if ((entry->flags & ENTRY_IS_DEAD) != 0)
+		ISC_LIST_UNLINK(adb->deadentries[bucket], entry, plink);
+	else
+		ISC_LIST_UNLINK(adb->entries[bucket], entry, plink);
 	entry->lock_bucket = DNS_ADB_INVALIDBUCKET;
 	INSIST(adb->entry_refcnt[bucket] > 0);
 	adb->entry_refcnt[bucket]--;
@@ -862,7 +892,7 @@ shutdown_entries(dns_adb_t *adb) {
 		adb->entry_sd[bucket] = ISC_TRUE;
 
 		entry = ISC_LIST_HEAD(adb->entries[bucket]);
-		if (entry == NULL) {
+		if (adb->entry_refcnt[bucket] == 0) {
 			/*
 			 * This bucket has no entries.  We must decrement the
 			 * irefcnt ourselves, since it will not be
@@ -1140,7 +1170,7 @@ check_exit(dns_adb_t *adb) {
 		 * If there aren't any external references either, we're
 		 * done.  Send the control event to initiate shutdown.
 		 */
-		INSIST(!adb->cevent_sent);	/* Sanity check. */
+		INSIST(!adb->cevent_sent);      /* Sanity check. */
 		event = &adb->cevent;
 		isc_task_send(adb->task, &event);
 		adb->cevent_sent = ISC_TRUE;
@@ -1220,7 +1250,8 @@ dec_entry_refcnt(dns_adb_t *adb, dns_adbentry_t *entry, isc_boolean_t lock) {
 
 	destroy_entry = ISC_FALSE;
 	if (entry->refcnt == 0 &&
-	    (adb->entry_sd[bucket] || entry->expires == 0)) {
+	    (adb->entry_sd[bucket] || entry->expires == 0 || adb->overmem ||
+	     (entry->flags & ENTRY_IS_DEAD) != 0)) {
 		destroy_entry = ISC_TRUE;
 		result = unlink_entry(adb, entry);
 	}
@@ -1235,7 +1266,7 @@ dec_entry_refcnt(dns_adb_t *adb, dns_adbentry_t *entry, isc_boolean_t lock) {
 
 	free_adbentry(adb, &entry);
 	if (result)
-		result =dec_adb_irefcnt(adb);
+		result = dec_adb_irefcnt(adb);
 
 	return (result);
 }
@@ -1463,31 +1494,13 @@ new_adbfetch(dns_adb_t *adb) {
 		return (NULL);
 
 	f->magic = 0;
-	f->namehook = NULL;
-	f->entry = NULL;
 	f->fetch = NULL;
 
-	f->namehook = new_adbnamehook(adb, NULL);
-	if (f->namehook == NULL)
-		goto err;
-
-	f->entry = new_adbentry(adb);
-	if (f->entry == NULL)
-		goto err;
-
 	dns_rdataset_init(&f->rdataset);
 
 	f->magic = DNS_ADBFETCH_MAGIC;
 
 	return (f);
-
- err:
-	if (f->namehook != NULL)
-		free_adbnamehook(adb, &f->namehook);
-	if (f->entry != NULL)
-		free_adbentry(adb, &f->entry);
-	isc_mempool_put(adb->afmp, f);
-	return (NULL);
 }
 
 static inline void
@@ -1500,11 +1513,6 @@ free_adbfetch(dns_adb_t *adb, dns_adbfetch_t **fetch) {
 
 	f->magic = 0;
 
-	if (f->namehook != NULL)
-		free_adbnamehook(adb, &f->namehook);
-	if (f->entry != NULL)
-		free_adbentry(adb, &f->entry);
-
 	if (dns_rdataset_isassociated(&f->rdataset))
 		dns_rdataset_disassociate(&f->rdataset);
 
@@ -1622,8 +1630,10 @@ find_name_and_lock(dns_adb_t *adb, dns_name_t *name,
  * the bucket changes.
  */
 static inline dns_adbentry_t *
-find_entry_and_lock(dns_adb_t *adb, isc_sockaddr_t *addr, int *bucketp) {
-	dns_adbentry_t *entry;
+find_entry_and_lock(dns_adb_t *adb, isc_sockaddr_t *addr, int *bucketp,
+	isc_stdtime_t now)
+{
+	dns_adbentry_t *entry, *entry_next;
 	int bucket;
 
 	bucket = isc_sockaddr_hash(addr, ISC_TRUE) % NBUCKETS;
@@ -1637,11 +1647,18 @@ find_entry_and_lock(dns_adb_t *adb, isc_sockaddr_t *addr, int *bucketp) {
 		*bucketp = bucket;
 	}
 
-	entry = ISC_LIST_HEAD(adb->entries[bucket]);
-	while (entry != NULL) {
-		if (isc_sockaddr_equal(addr, &entry->sockaddr))
+	/* Search the list, while cleaning up expired entries. */
+	for (entry = ISC_LIST_HEAD(adb->entries[bucket]);
+	     entry != NULL;
+	     entry = entry_next) {
+		entry_next = ISC_LIST_NEXT(entry, plink);
+		(void)check_expire_entry(adb, &entry, now);
+		if (entry != NULL &&
+		    isc_sockaddr_equal(addr, &entry->sockaddr)) {
+			ISC_LIST_UNLINK(adb->entries[bucket], entry, plink);
+			ISC_LIST_PREPEND(adb->entries[bucket], entry, plink);
 			return (entry);
-		entry = ISC_LIST_NEXT(entry, plink);
+		}
 	}
 
 	return (NULL);
@@ -1775,19 +1792,12 @@ shutdown_task(isc_task_t *task, isc_event_t *ev) {
 	adb = ev->ev_arg;
 	INSIST(DNS_ADB_VALID(adb));
 
+	isc_event_free(&ev);
 	/*
 	 * Wait for lock around check_exit() call to be released.
 	 */
 	LOCK(&adb->lock);
-	/*
-	 * Kill the timer, and then the ADB itself.  Note that this implies
-	 * that this task was the one scheduled to get timer events.  If
-	 * this is not true (and it is unfortunate there is no way to INSIST()
-	 * this) badness will occur.
-	 */
-	isc_timer_detach(&adb->timer);
 	UNLOCK(&adb->lock);
-	isc_event_free(&ev);
 	destroy(adb);
 }
 
@@ -1826,6 +1836,62 @@ check_expire_name(dns_adbname_t **namep, isc_stdtime_t now) {
 	return (result);
 }
 
+/*%
+ * Examine the tail entry of the LRU list to see if it expires or is stale
+ * (unused for some period); if so, the name entry will be freed.  If the ADB
+ * is in the overmem condition, the tail and the next to tail entries
+ * will be unconditionally removed (unless they have an outstanding fetch).
+ * We don't care about a race on 'overmem' at the risk of causing some
+ * collateral damage or a small delay in starting cleanup, so we don't bother
+ * to lock ADB (if it's not locked).
+ *
+ * Name bucket must be locked; adb may be locked; no other locks held.
+ */
+static void
+check_stale_name(dns_adb_t *adb, int bucket, isc_stdtime_t now) {
+	int victims, max_victims;
+	isc_boolean_t result;
+	dns_adbname_t *victim, *next_victim;
+	isc_boolean_t overmem = adb->overmem;
+	int scans = 0;
+
+	INSIST(bucket != DNS_ADB_INVALIDBUCKET);
+
+	max_victims = overmem ? 2 : 1;
+
+	/*
+	 * We limit the number of scanned entries to 10 (arbitrary choice)
+	 * in order to avoid examining too many entries when there are many
+	 * tail entries that have fetches (this should be rare, but could
+	 * happen).
+	 */
+	victim = ISC_LIST_TAIL(adb->names[bucket]);
+	for (victims = 0;
+	     victim != NULL && victims < max_victims && scans < 10;
+	     victim = next_victim) {
+		INSIST(!NAME_DEAD(victim));
+		scans++;
+		next_victim = ISC_LIST_PREV(victim, plink);
+		result = check_expire_name(&victim, now);
+		if (victim == NULL) {
+			victims++;
+			goto next;
+		}
+
+		if (!NAME_FETCH(victim) &&
+		    (overmem || victim->last_used + ADB_STALE_MARGIN <= now)) {
+			RUNTIME_CHECK(kill_name(&victim,
+						DNS_EVENT_ADBCANCELED) ==
+				      ISC_FALSE);
+			victims++;
+		}
+
+	next:
+		if (!overmem)
+			break;
+	}
+}
+
 /*
  * Entry bucket must be locked; adb may be locked; no other locks held.
  */
@@ -1833,7 +1899,6 @@ static isc_boolean_t
 check_expire_entry(dns_adb_t *adb, dns_adbentry_t **entryp, isc_stdtime_t now)
 {
 	dns_adbentry_t *entry;
-	isc_boolean_t expire;
 	isc_boolean_t result = ISC_FALSE;
 
 	INSIST(entryp != NULL && DNS_ADBENTRY_VALID(*entryp));
@@ -1842,16 +1907,7 @@ check_expire_entry(dns_adb_t *adb, dns_adbentry_t **entryp, isc_stdtime_t now)
 	if (entry->refcnt != 0)
 		return (result);
 
-	if (adb->overmem) {
-		isc_uint32_t val;
-
-		isc_random_get(&val);
-
-		expire = ISC_TF((val % 4) == 0);
-	} else
-		expire = ISC_FALSE;
-
-	if (entry->expires == 0 || (! expire && entry->expires > now))
+	if (entry->expires == 0 || entry->expires > now)
 		return (result);
 
 	/*
@@ -1888,7 +1944,7 @@ cleanup_names(dns_adb_t *adb, int bucket, isc_stdtime_t now) {
 	while (name != NULL) {
 		next_name = ISC_LIST_NEXT(name, plink);
 		INSIST(result == ISC_FALSE);
-		result = check_expire_namehooks(name, now, adb->overmem);
+		result = check_expire_namehooks(name, now);
 		if (!result)
 			result = check_expire_name(&name, now);
 		name = next_name;
@@ -1920,66 +1976,9 @@ cleanup_entries(dns_adb_t *adb, int bucket, isc_stdtime_t now) {
 }
 
 static void
-timer_cleanup(isc_task_t *task, isc_event_t *ev) {
-	dns_adb_t *adb;
-	isc_stdtime_t now;
-	unsigned int i;
-	isc_interval_t interval;
-
-	UNUSED(task);
-
-	adb = ev->ev_arg;
-	INSIST(DNS_ADB_VALID(adb));
-
-	LOCK(&adb->lock);
-
-	isc_stdtime_get(&now);
-
-	for (i = 0; i < CLEAN_BUCKETS; i++) {
-		/*
-		 * Call our cleanup routines.
-		 */
-		RUNTIME_CHECK(cleanup_names(adb, adb->next_cleanbucket, now) ==
-			      ISC_FALSE);
-		RUNTIME_CHECK(cleanup_entries(adb, adb->next_cleanbucket, now)
-			      == ISC_FALSE);
-
-		/*
-		 * Set the next bucket to be cleaned.
-		 */
-		adb->next_cleanbucket++;
-		if (adb->next_cleanbucket >= NBUCKETS) {
-			adb->next_cleanbucket = 0;
-#ifdef DUMP_ADB_AFTER_CLEANING
-			dump_adb(adb, stdout, ISC_TRUE, now);
-#endif
-		}
-	}
-
-	/*
-	 * Reset the timer.
-	 * XXXDCL isc_timer_reset might return ISC_R_UNEXPECTED or
-	 * ISC_R_NOMEMORY, but it isn't clear what could be done here
-	 * if either one of those things happened.
-	 */
-	interval = adb->tick_interval;
-	if (adb->overmem)
-		isc_interval_set(&interval, 0, 1);
-	(void)isc_timer_reset(adb->timer, isc_timertype_once, NULL,
-			      &interval, ISC_FALSE);
-
-	UNLOCK(&adb->lock);
-
-	isc_event_free(&ev);
-}
-
-static void
 destroy(dns_adb_t *adb) {
 	adb->magic = 0;
 
-	/*
-	 * The timer is already dead, from the task's shutdown callback.
-	 */
 	isc_task_detach(&adb->task);
 
 	isc_mempool_destroy(&adb->nmp);
@@ -2016,10 +2015,12 @@ dns_adb_create(isc_mem_t *mem, dns_view_t *view, isc_timermgr_t *timermgr,
 
 	REQUIRE(mem != NULL);
 	REQUIRE(view != NULL);
-	REQUIRE(timermgr != NULL);
+	REQUIRE(timermgr != NULL); /* this is actually unused */
 	REQUIRE(taskmgr != NULL);
 	REQUIRE(newadb != NULL && *newadb == NULL);
 
+	UNUSED(timermgr);
+
 	adb = isc_mem_get(mem, sizeof(dns_adb_t));
 	if (adb == NULL)
 		return (ISC_R_NOMEMORY);
@@ -2039,10 +2040,8 @@ dns_adb_create(isc_mem_t *mem, dns_view_t *view, isc_timermgr_t *timermgr,
 	adb->aimp = NULL;
 	adb->afmp = NULL;
 	adb->task = NULL;
-	adb->timer = NULL;
 	adb->mctx = NULL;
 	adb->view = view;
-	adb->timermgr = timermgr;
 	adb->taskmgr = taskmgr;
 	adb->next_cleanbucket = 0;
 	ISC_EVENT_INIT(&adb->cevent, sizeof(adb->cevent), 0, NULL,
@@ -2080,12 +2079,14 @@ dns_adb_create(isc_mem_t *mem, dns_view_t *view, isc_timermgr_t *timermgr,
 		goto fail1;
 	for (i = 0; i < NBUCKETS; i++) {
 		ISC_LIST_INIT(adb->names[i]);
+		ISC_LIST_INIT(adb->deadnames[i]);
 		adb->name_sd[i] = ISC_FALSE;
 		adb->name_refcnt[i] = 0;
 		adb->irefcnt++;
 	}
 	for (i = 0; i < NBUCKETS; i++) {
 		ISC_LIST_INIT(adb->entries[i]);
+		ISC_LIST_INIT(adb->deadentries[i]);
 		adb->entry_sd[i] = ISC_FALSE;
 		adb->entry_refcnt[i] = 0;
 		adb->irefcnt++;
@@ -2118,25 +2119,12 @@ dns_adb_create(isc_mem_t *mem, dns_view_t *view, isc_timermgr_t *timermgr,
 #undef MPINIT
 
 	/*
-	 * Allocate a timer and a task for our periodic cleanup.
+	 * Allocate an internal task.
 	 */
 	result = isc_task_create(adb->taskmgr, 0, &adb->task);
 	if (result != ISC_R_SUCCESS)
 		goto fail3;
 	isc_task_setname(adb->task, "ADB", adb);
-	/*
-	 * XXXMLG When this is changed to be a config file option,
-	 */
-	isc_interval_set(&adb->tick_interval, CLEAN_SECONDS, 0);
-	result = isc_timer_create(adb->timermgr, isc_timertype_once,
-				  NULL, &adb->tick_interval, adb->task,
-				  timer_cleanup, adb, &adb->timer);
-	if (result != ISC_R_SUCCESS)
-		goto fail3;
-
-	DP(ISC_LOG_DEBUG(5), "cleaning interval for adb: "
-	   "%u buckets every %u seconds, %u buckets in system, %u cl.interval",
-	   CLEAN_BUCKETS, CLEAN_SECONDS, NBUCKETS, CLEAN_PERIOD);
 
 	/*
 	 * Normal return.
@@ -2148,8 +2136,6 @@ dns_adb_create(isc_mem_t *mem, dns_view_t *view, isc_timermgr_t *timermgr,
  fail3:
 	if (adb->task != NULL)
 		isc_task_detach(&adb->task);
-	if (adb->timer != NULL)
-		isc_timer_detach(&adb->timer);
 
 	/* clean up entrylocks */
 	DESTROYMUTEXBLOCK(adb->entrylocks, NBUCKETS);
@@ -2328,18 +2314,18 @@ dns_adb_createfind(dns_adb_t *adb, isc_task_t *task, isc_taskaction_t action,
 	 *
 	 * Possibilities:  Note that these are not always exclusive.
 	 *
-	 *	No name found.  In this case, allocate a new name header and
-	 *	an initial namehook or two.  If any of these allocations
-	 *	fail, clean up and return ISC_R_NOMEMORY.
+	 *      No name found.  In this case, allocate a new name header and
+	 *      an initial namehook or two.  If any of these allocations
+	 *      fail, clean up and return ISC_R_NOMEMORY.
 	 *
-	 *	Name found, valid addresses present.  Allocate one addrinfo
-	 *	structure for each found and append it to the linked list
-	 *	of addresses for this header.
+	 *      Name found, valid addresses present.  Allocate one addrinfo
+	 *      structure for each found and append it to the linked list
+	 *      of addresses for this header.
 	 *
-	 *	Name found, queries pending.  In this case, if a task was
-	 *	passed in, allocate a job id, attach it to the name's job
-	 *	list and remember to tell the caller that there will be
-	 *	more info coming later.
+	 *      Name found, queries pending.  In this case, if a task was
+	 *      passed in, allocate a job id, attach it to the name's job
+	 *      list and remember to tell the caller that there will be
+	 *      more info coming later.
 	 */
 
 	find = new_adbfind(adb);
@@ -2374,6 +2360,12 @@ dns_adb_createfind(dns_adb_t *adb, isc_task_t *task, isc_taskaction_t action,
 	 * Nothing found.  Allocate a new adbname structure for this name.
 	 */
 	if (adbname == NULL) {
+		/*
+		 * See if there is any stale name at the end of list, and purge
+		 * it if so.
+		 */
+		check_stale_name(adb, bucket, now);
+
 		adbname = new_adbname(adb, name);
 		if (adbname == NULL) {
 			RUNTIME_CHECK(free_adbfind(adb, &find) == ISC_FALSE);
@@ -2387,13 +2379,17 @@ dns_adb_createfind(dns_adb_t *adb, isc_task_t *task, isc_taskaction_t action,
 			adbname->flags |= NAME_GLUE_OK;
 		if (FIND_STARTATZONE(find))
 			adbname->flags |= NAME_STARTATZONE;
+	} else {
+		/* Move this name forward in the LRU list */
+		ISC_LIST_UNLINK(adb->names[bucket], adbname, plink);
+		ISC_LIST_PREPEND(adb->names[bucket], adbname, plink);
 	}
+	adbname->last_used = now;
 
 	/*
 	 * Expire old entries, etc.
 	 */
-	RUNTIME_CHECK(check_expire_namehooks(adbname, now, adb->overmem) ==
-		      ISC_FALSE);
+	RUNTIME_CHECK(check_expire_namehooks(adbname, now) == ISC_FALSE);
 
 	/*
 	 * Do we know that the name is an alias?
@@ -2953,8 +2949,8 @@ print_namehook_list(FILE *f, const char *legend, dns_adbnamehooklist_t *list,
 
 static inline void
 print_fetch(FILE *f, dns_adbfetch_t *ft, const char *type) {
-	fprintf(f, "\t\tFetch(%s): %p -> { nh %p, entry %p, fetch %p }\n",
-		type, ft, ft->namehook, ft->entry, ft->fetch);
+	fprintf(f, "\t\tFetch(%s): %p -> { fetch %p }\n",
+		type, ft, ft->fetch);
 }
 
 static void
@@ -2991,7 +2987,7 @@ dbfind_name(dns_adbname_t *adbname, isc_stdtime_t now, dns_rdatatype_t rdtype)
 	INSIST(rdtype == dns_rdatatype_a || rdtype == dns_rdatatype_aaaa);
 
 	dns_fixedname_init(&foundname);
-	fname =	dns_fixedname_name(&foundname);
+	fname = dns_fixedname_name(&foundname);
 	dns_rdataset_init(&rdataset);
 
 	if (rdtype == dns_rdatatype_a)
@@ -3202,6 +3198,7 @@ fetch_callback(isc_task_t *task, isc_event_t *ev) {
 				name->fetch_err = FIND_ERR_NXDOMAIN;
 			else
 				name->fetch_err = FIND_ERR_NXRRSET;
+			inc_stats(adb, dns_resstatscounter_gluefetchv4fail);
 		} else {
 			DP(NCACHE_LEVEL, "adb fetch name %p: "
 			   "caching negative entry for AAAA (ttl %u)",
@@ -3212,6 +3209,7 @@ fetch_callback(isc_task_t *task, isc_event_t *ev) {
 				name->fetch6_err = FIND_ERR_NXDOMAIN;
 			else
 				name->fetch6_err = FIND_ERR_NXRRSET;
+			inc_stats(adb, dns_resstatscounter_gluefetchv6fail);
 		}
 		goto out;
 	}
@@ -3251,9 +3249,11 @@ fetch_callback(isc_task_t *task, isc_event_t *ev) {
 		if (address_type == DNS_ADBFIND_INET) {
 			name->expire_v4 = ISC_MIN(name->expire_v4, now + 300);
 			name->fetch_err = FIND_ERR_FAILURE;
+			inc_stats(adb, dns_resstatscounter_gluefetchv4fail);
 		} else {
 			name->expire_v6 = ISC_MIN(name->expire_v6, now + 300);
 			name->fetch6_err = FIND_ERR_FAILURE;
+			inc_stats(adb, dns_resstatscounter_gluefetchv6fail);
 		}
 		goto out;
 	}
@@ -3338,10 +3338,13 @@ fetch_name(dns_adbname_t *adbname,
 	if (result != ISC_R_SUCCESS)
 		goto cleanup;
 
-	if (type == dns_rdatatype_a)
+	if (type == dns_rdatatype_a) {
 		adbname->fetch_a = fetch;
-	else
+		inc_stats(adb, dns_resstatscounter_gluefetchv4);
+	} else {
 		adbname->fetch_aaaa = fetch;
+		inc_stats(adb, dns_resstatscounter_gluefetchv6);
+	}
 	fetch = NULL;  /* Keep us from cleaning this up below. */
 
  cleanup:
@@ -3464,7 +3467,7 @@ dns_adb_findaddrinfo(dns_adb_t *adb, isc_sockaddr_t *sa,
 
 	result = ISC_R_SUCCESS;
 	bucket = DNS_ADB_INVALIDBUCKET;
-	entry = find_entry_and_lock(adb, sa, &bucket);
+	entry = find_entry_and_lock(adb, sa, &bucket, now);
 	if (adb->entry_sd[bucket]) {
 		result = ISC_R_SHUTTINGDOWN;
 		goto unlock;
@@ -3590,7 +3593,6 @@ static void
 water(void *arg, int mark) {
 	dns_adb_t *adb = arg;
 	isc_boolean_t overmem = ISC_TF(mark == ISC_MEM_HIWATER);
-	isc_interval_t interval;
 
 	REQUIRE(DNS_ADB_VALID(adb));
 
@@ -3604,11 +3606,6 @@ water(void *arg, int mark) {
 	LOCK(&adb->overmemlock);
 	if (adb->overmem != overmem) {
 		adb->overmem = overmem;
-		if (overmem) {
-			isc_interval_set(&interval, 0, 1);
-			(void)isc_timer_reset(adb->timer, isc_timertype_once,
-					      NULL, &interval, ISC_TRUE);
-		}
 		isc_mem_waterack(adb->mctx, mark);
 	}
 	UNLOCK(&adb->overmemlock);
diff --git a/contrib/bind9/lib/dns/api b/contrib/bind9/lib/dns/api
index 0b8a3bc..5ef8dc0 100644
--- a/contrib/bind9/lib/dns/api
+++ b/contrib/bind9/lib/dns/api
@@ -1,3 +1,3 @@
-LIBINTERFACE = 36
-LIBREVISION = 2
-LIBAGE = 0
+LIBINTERFACE = 51
+LIBREVISION = 1
+LIBAGE = 1
diff --git a/contrib/bind9/lib/dns/byaddr.c b/contrib/bind9/lib/dns/byaddr.c
index 38d6e8b..234d6b2 100644
--- a/contrib/bind9/lib/dns/byaddr.c
+++ b/contrib/bind9/lib/dns/byaddr.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: byaddr.c,v 1.34.18.3 2005/04/29 00:15:49 marka Exp $ */
+/* $Id: byaddr.c,v 1.39 2007/06/19 23:47:16 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/dns/cache.c b/contrib/bind9/lib/dns/cache.c
index c9b4a95..aee824e 100644
--- a/contrib/bind9/lib/dns/cache.c
+++ b/contrib/bind9/lib/dns/cache.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,13 +15,14 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: cache.c,v 1.57.18.18 2008/02/07 23:45:56 tbox Exp $ */
+/* $Id: cache.c,v 1.80.50.3 2009/05/06 23:34:30 jinmei Exp $ */
 
 /*! \file */
 
 #include <config.h>
 
 #include <isc/mem.h>
+#include <isc/string.h>
 #include <isc/task.h>
 #include <isc/time.h>
 #include <isc/timer.h>
@@ -47,7 +48,7 @@
  * DNS_CACHE_MINSIZE is how many bytes is the floor for dns_cache_setcachesize().
  * See also DNS_CACHE_CLEANERINCREMENT
  */
-#define DNS_CACHE_MINSIZE 		2097152	/*%< Bytes.  2097152 = 2 MB */
+#define DNS_CACHE_MINSIZE	2097152 /*%< Bytes.  2097152 = 2 MB */
 /*!
  * Control incremental cleaning.
  * CLEANERINCREMENT is how many nodes are examined in one pass.
@@ -60,7 +61,7 @@
  ***/
 
 /*
- * A cache_cleaner_t encapsulsates the state of the periodic
+ * A cache_cleaner_t encapsulates the state of the periodic
  * cache cleaning.
  */
 
@@ -69,7 +70,7 @@ typedef struct cache_cleaner cache_cleaner_t;
 typedef enum {
 	cleaner_s_idle,	/*%< Waiting for cleaning-interval to expire. */
 	cleaner_s_busy,	/*%< Currently cleaning. */
-	cleaner_s_done  /*%< Freed enough memory after being overmem. */
+	cleaner_s_done	/*%< Freed enough memory after being overmem. */
 } cleaner_state_t;
 
 /*
@@ -95,19 +96,19 @@ struct cache_cleaner {
 	 */
 
 	dns_cache_t	*cache;
-	isc_task_t 	*task;
+	isc_task_t	*task;
 	unsigned int	cleaning_interval; /*% The cleaning-interval from
 					      named.conf, in seconds. */
-	isc_timer_t 	*cleaning_timer;
+	isc_timer_t	*cleaning_timer;
 	isc_event_t	*resched_event;	/*% Sent by cleaner task to
 					   itself to reschedule */
 	isc_event_t	*overmem_event;
 
 	dns_dbiterator_t *iterator;
-	unsigned int 	 increment;	/*% Number of names to
+	unsigned int	increment;	/*% Number of names to
 					   clean in one increment */
-	cleaner_state_t  state;		/*% Idle/Busy. */
-	isc_boolean_t	 overmem;	/*% The cache is in an overmem state. */
+	cleaner_state_t	state;		/*% Idle/Busy. */
+	isc_boolean_t	overmem;	/*% The cache is in an overmem state. */
 	isc_boolean_t	 replaceiterator;
 };
 
@@ -133,7 +134,7 @@ struct dns_cache {
 	char			**db_argv;
 
 	/* Locked by 'filelock'. */
-	char *			filename;
+	char			*filename;
 	/* Access to the on-disk cache file is also locked by 'filelock'. */
 };
 
@@ -157,79 +158,6 @@ cleaner_shutdown_action(isc_task_t *task, isc_event_t *event);
 static void
 overmem_cleaning_action(isc_task_t *task, isc_event_t *event);
 
-/*%
- * Work out how many nodes can be cleaned in the time between two
- * requests to the nameserver.  Smooth the resulting number and use
- * it as a estimate for the number of nodes to be cleaned in the next
- * iteration.
- */
-static void
-adjust_increment(cache_cleaner_t *cleaner, unsigned int remaining,
-		 isc_time_t *start)
-{
-	isc_time_t end;
-	isc_uint64_t usecs;
-	isc_uint64_t new;
-	unsigned int pps = dns_pps;
-	unsigned int interval;
-	unsigned int names;
-
-	/*
-	 * Tune for minumum of 100 packets per second (pps).
-	 */
-	if (pps < 100)
-		pps = 100;
-
-	isc_time_now(&end);
-
-	interval = 1000000 / pps; /* Interval between packets in usecs. */
-	if (interval == 0)
-		interval = 1;
-
-	INSIST(cleaner->increment >= remaining);
-	names = cleaner->increment - remaining;
-	usecs = isc_time_microdiff(&end, start);
-
-	isc_log_write(dns_lctx, DNS_LOGCATEGORY_DATABASE, DNS_LOGMODULE_CACHE,
-		      ISC_LOG_DEBUG(1), "adjust_increment interval=%u "
-		      "names=%u usec=%" ISC_PLATFORM_QUADFORMAT "u",
-		      interval, names, usecs);
-
-	if (usecs == 0) {
-		/*
-		 * If we cleaned all the nodes in unmeasurable time
-		 * double the number of nodes to be cleaned next time.
-		 */
-		if (names == cleaner->increment) {
-			cleaner->increment *= 2;
-			if (cleaner->increment > DNS_CACHE_CLEANERINCREMENT)
-				cleaner->increment = DNS_CACHE_CLEANERINCREMENT;
-			isc_log_write(dns_lctx, DNS_LOGCATEGORY_DATABASE,
-				      DNS_LOGMODULE_CACHE, ISC_LOG_DEBUG(1),
-				      "%p:new cleaner->increment = %u\n",
-				      cleaner, cleaner->increment);
-		}
-		return;
-	}
-
-	new = (names * interval);
-	new /= (usecs * 2);
-	if (new == 0)
-		new = 1;
-
-	/* Smooth */
-	new = (new + cleaner->increment * 7) / 8;
-
-	if (new > DNS_CACHE_CLEANERINCREMENT)
-		new = DNS_CACHE_CLEANERINCREMENT;
-
-	cleaner->increment = (unsigned int)new;
-
-	isc_log_write(dns_lctx, DNS_LOGCATEGORY_DATABASE, DNS_LOGMODULE_CACHE,
-		      ISC_LOG_DEBUG(1), "%p:new cleaner->increment = %u\n",
-		      cleaner, cleaner->increment);
-}
-
 static inline isc_result_t
 cache_create_db(dns_cache_t *cache, dns_db_t **db) {
 	return (dns_db_create(cache->mctx, cache->db_type, dns_rootname,
@@ -246,6 +174,7 @@ dns_cache_create(isc_mem_t *mctx, isc_taskmgr_t *taskmgr,
 	isc_result_t result;
 	dns_cache_t *cache;
 	int i;
+	isc_task_t *dbtask;
 
 	REQUIRE(cachep != NULL);
 	REQUIRE(*cachep == NULL);
@@ -301,12 +230,29 @@ dns_cache_create(isc_mem_t *mctx, isc_taskmgr_t *taskmgr,
 	result = cache_create_db(cache, &cache->db);
 	if (result != ISC_R_SUCCESS)
 		goto cleanup_dbargv;
+	if (taskmgr != NULL) {
+		dbtask = NULL;
+		result = isc_task_create(taskmgr, 1, &dbtask);
+		if (result != ISC_R_SUCCESS)
+			goto cleanup_db;
+		dns_db_settask(cache->db, dbtask);
+		isc_task_detach(&dbtask);
+	}
 
 	cache->filename = NULL;
 
 	cache->magic = CACHE_MAGIC;
 
-	result = cache_cleaner_init(cache, taskmgr, timermgr, &cache->cleaner);
+	/*
+	 * RBT-type cache DB has its own mechanism of cache cleaning and doesn't
+	 * need the control of the generic cleaner.
+	 */
+	if (strcmp(db_type, "rbt") == 0)
+		result = cache_cleaner_init(cache, NULL, NULL, &cache->cleaner);
+	else {
+		result = cache_cleaner_init(cache, taskmgr, timermgr,
+					    &cache->cleaner);
+	}
 	if (result != ISC_R_SUCCESS)
 		goto cleanup_db;
 
@@ -603,8 +549,7 @@ cache_cleaner_init(dns_cache_t *cache, isc_taskmgr_t *taskmgr,
 
 		cleaner->cleaning_interval = 0; /* Initially turned off. */
 		result = isc_timer_create(timermgr, isc_timertype_inactive,
-					   NULL, NULL,
-					   cleaner->task,
+					   NULL, NULL, cleaner->task,
 					   cleaning_timer_action, cleaner,
 					   &cleaner->cleaning_timer);
 		if (result != ISC_R_SUCCESS) {
@@ -848,7 +793,6 @@ incremental_cleaning_action(isc_task_t *task, isc_event_t *event) {
 				 "cache cleaner: dns_dbiterator_current() "
 				 "failed: %s", dns_result_totext(result));
 
-			adjust_increment(cleaner, n_names, &start);
 			end_cleaning(cleaner, event);
 			return;
 		}
@@ -892,14 +836,11 @@ incremental_cleaning_action(isc_task_t *task, isc_event_t *event) {
 				}
 			}
 
-			adjust_increment(cleaner, n_names, &start);
 			end_cleaning(cleaner, event);
 			return;
 		}
 	}
 
-	adjust_increment(cleaner, 0U, &start);
-
 	/*
 	 * We have successfully performed a cleaning increment but have
 	 * not gone through the entire cache.  Free the iterator locks
@@ -929,7 +870,7 @@ dns_cache_clean(dns_cache_t *cache, isc_stdtime_t now) {
 
 	REQUIRE(VALID_CACHE(cache));
 
-	result = dns_db_createiterator(cache->db, ISC_FALSE, &iterator);
+	result = dns_db_createiterator(cache->db, 0, &iterator);
 	if (result != ISC_R_SUCCESS)
 		return result;
 
@@ -1002,7 +943,7 @@ dns_cache_setcachesize(dns_cache_t *cache, isc_uint32_t size) {
 	REQUIRE(VALID_CACHE(cache));
 
 	/*
-	 * Impose a minumum cache size; pathological things happen if there
+	 * Impose a minimum cache size; pathological things happen if there
 	 * is too little room.
 	 */
 	if (size != 0 && size < DNS_CACHE_MINSIZE)
diff --git a/contrib/bind9/lib/dns/callbacks.c b/contrib/bind9/lib/dns/callbacks.c
index a487ed0..928f37d 100644
--- a/contrib/bind9/lib/dns/callbacks.c
+++ b/contrib/bind9/lib/dns/callbacks.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: callbacks.c,v 1.13.18.2 2005/04/29 00:15:49 marka Exp $ */
+/* $Id: callbacks.c,v 1.17 2007/06/19 23:47:16 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/dns/compress.c b/contrib/bind9/lib/dns/compress.c
index 2103767..11473ee 100644
--- a/contrib/bind9/lib/dns/compress.c
+++ b/contrib/bind9/lib/dns/compress.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: compress.c,v 1.52.18.5 2006/03/02 00:37:21 marka Exp $ */
+/* $Id: compress.c,v 1.59 2007/06/19 23:47:16 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/dns/db.c b/contrib/bind9/lib/dns/db.c
index 32ff6ae..a4c2864 100644
--- a/contrib/bind9/lib/dns/db.c
+++ b/contrib/bind9/lib/dns/db.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: db.c,v 1.74.18.6 2005/10/13 02:12:24 marka Exp $ */
+/* $Id: db.c,v 1.88 2008/09/24 02:46:22 marka Exp $ */
 
 /*! \file */
 
@@ -95,7 +95,7 @@ static inline dns_dbimplementation_t *
 impfind(const char *name) {
 	dns_dbimplementation_t *imp;
 
-	for (imp = ISC_LIST_HEAD(implementations); 
+	for (imp = ISC_LIST_HEAD(implementations);
 	     imp != NULL;
 	     imp = ISC_LIST_NEXT(imp, link))
 		if (strcasecmp(name, imp->name) == 0)
@@ -229,6 +229,21 @@ dns_db_isstub(dns_db_t *db) {
 }
 
 isc_boolean_t
+dns_db_isdnssec(dns_db_t *db) {
+
+	/*
+	 * Is 'db' secure or partially secure?
+	 */
+
+	REQUIRE(DNS_DB_VALID(db));
+	REQUIRE((db->attributes & DNS_DBATTR_CACHE) == 0);
+
+	if (db->methods->isdnssec != NULL)
+		return ((db->methods->isdnssec)(db));
+	return ((db->methods->issecure)(db));
+}
+
+isc_boolean_t
 dns_db_issecure(dns_db_t *db) {
 
 	/*
@@ -450,6 +465,21 @@ dns_db_findnode(dns_db_t *db, dns_name_t *name,
 }
 
 isc_result_t
+dns_db_findnsec3node(dns_db_t *db, dns_name_t *name,
+		     isc_boolean_t create, dns_dbnode_t **nodep)
+{
+
+	/*
+	 * Find the node with name 'name'.
+	 */
+
+	REQUIRE(DNS_DB_VALID(db));
+	REQUIRE(nodep != NULL && *nodep == NULL);
+
+	return ((db->methods->findnsec3node)(db, name, create, nodep));
+}
+
+isc_result_t
 dns_db_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
 	    dns_rdatatype_t type, unsigned int options, isc_stdtime_t now,
 	    dns_dbnode_t **nodep, dns_name_t *foundname,
@@ -527,6 +557,30 @@ dns_db_detachnode(dns_db_t *db, dns_dbnode_t **nodep) {
 	ENSURE(*nodep == NULL);
 }
 
+void
+dns_db_transfernode(dns_db_t *db, dns_dbnode_t **sourcep,
+		    dns_dbnode_t **targetp)
+{
+	REQUIRE(DNS_DB_VALID(db));
+	REQUIRE(targetp != NULL && *targetp == NULL);
+	/*
+	 * This doesn't check the implementation magic.  If we find that
+	 * we need such checks in future then this will be done in the
+	 * method.
+	 */
+	REQUIRE(sourcep != NULL && *sourcep != NULL);
+
+	UNUSED(db);
+
+	if (db->methods->transfernode == NULL) {
+		*targetp = *sourcep;
+		*sourcep = NULL;
+	} else
+		(db->methods->transfernode)(db, sourcep, targetp);
+
+	ENSURE(*sourcep == NULL);
+}
+
 isc_result_t
 dns_db_expirenode(dns_db_t *db, dns_dbnode_t *node, isc_stdtime_t now) {
 
@@ -559,7 +613,7 @@ dns_db_printnode(dns_db_t *db, dns_dbnode_t *node, FILE *out) {
  ***/
 
 isc_result_t
-dns_db_createiterator(dns_db_t *db, isc_boolean_t relative_names,
+dns_db_createiterator(dns_db_t *db, unsigned int flags,
 		      dns_dbiterator_t **iteratorp)
 {
 	/*
@@ -569,7 +623,7 @@ dns_db_createiterator(dns_db_t *db, isc_boolean_t relative_names,
 	REQUIRE(DNS_DB_VALID(db));
 	REQUIRE(iteratorp != NULL && *iteratorp == NULL);
 
-	return (db->methods->createiterator(db, relative_names, iteratorp));
+	return (db->methods->createiterator(db, flags, iteratorp));
 }
 
 /***
@@ -687,7 +741,7 @@ dns_db_deleterdataset(dns_db_t *db, dns_dbnode_t *node,
 					      type, covers));
 }
 
-void 
+void
 dns_db_overmem(dns_db_t *db, isc_boolean_t overmem) {
 
 	REQUIRE(DNS_DB_VALID(db));
@@ -713,11 +767,11 @@ dns_db_getsoaserial(dns_db_t *db, dns_dbversion_t *ver, isc_uint32_t *serialp)
 	dns_rdataset_init(&rdataset);
 	result = dns_db_findrdataset(db, node, ver, dns_rdatatype_soa, 0,
 				     (isc_stdtime_t)0, &rdataset, NULL);
- 	if (result != ISC_R_SUCCESS)
+	if (result != ISC_R_SUCCESS)
 		goto freenode;
 
 	result = dns_rdataset_first(&rdataset);
- 	if (result != ISC_R_SUCCESS)
+	if (result != ISC_R_SUCCESS)
 		goto freerdataset;
 	dns_rdataset_current(&rdataset, &rdata);
 	result = dns_rdataset_next(&rdataset);
@@ -770,7 +824,7 @@ dns_db_register(const char *name, dns_dbcreatefunc_t create, void *driverarg,
 		RWUNLOCK(&implock, isc_rwlocktype_write);
 		return (ISC_R_EXISTS);
 	}
-	
+
 	imp = isc_mem_get(mctx, sizeof(dns_dbimplementation_t));
 	if (imp == NULL) {
 		RWUNLOCK(&implock, isc_rwlocktype_write);
@@ -819,3 +873,54 @@ dns_db_getoriginnode(dns_db_t *db, dns_dbnode_t **nodep) {
 
 	return (ISC_R_NOTFOUND);
 }
+
+dns_stats_t *
+dns_db_getrrsetstats(dns_db_t *db) {
+	REQUIRE(DNS_DB_VALID(db));
+
+	if (db->methods->getrrsetstats != NULL)
+		return ((db->methods->getrrsetstats)(db));
+
+	return (NULL);
+}
+
+isc_result_t
+dns_db_getnsec3parameters(dns_db_t *db, dns_dbversion_t *version,
+			  dns_hash_t *hash, isc_uint8_t *flags,
+			  isc_uint16_t *iterations,
+			  unsigned char *salt, size_t *salt_length)
+{
+	REQUIRE(DNS_DB_VALID(db));
+	REQUIRE(dns_db_iszone(db) == ISC_TRUE);
+
+	if (db->methods->getnsec3parameters != NULL)
+		return ((db->methods->getnsec3parameters)(db, version, hash,
+							  flags, iterations,
+							  salt, salt_length));
+
+	return (ISC_R_NOTFOUND);
+}
+
+isc_result_t
+dns_db_setsigningtime(dns_db_t *db, dns_rdataset_t *rdataset,
+		      isc_stdtime_t resign)
+{
+	if (db->methods->setsigningtime != NULL)
+		return ((db->methods->setsigningtime)(db, rdataset, resign));
+	return (ISC_R_NOTIMPLEMENTED);
+}
+
+isc_result_t
+dns_db_getsigningtime(dns_db_t *db, dns_rdataset_t *rdataset, dns_name_t *name)
+{
+	if (db->methods->getsigningtime != NULL)
+		return ((db->methods->getsigningtime)(db, rdataset, name));
+	return (ISC_R_NOTFOUND);
+}
+
+void
+dns_db_resigned(dns_db_t *db, dns_rdataset_t *rdataset, dns_dbversion_t *version)
+{
+	if (db->methods->resigned != NULL)
+		(db->methods->resigned)(db, rdataset, version);
+}
diff --git a/contrib/bind9/lib/dns/dbiterator.c b/contrib/bind9/lib/dns/dbiterator.c
index d462ad5..8981e49 100644
--- a/contrib/bind9/lib/dns/dbiterator.c
+++ b/contrib/bind9/lib/dns/dbiterator.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dbiterator.c,v 1.14.18.2 2005/04/29 00:15:50 marka Exp $ */
+/* $Id: dbiterator.c,v 1.18 2007/06/19 23:47:16 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/dns/dbtable.c b/contrib/bind9/lib/dns/dbtable.c
index b091e42..57bbfc1 100644
--- a/contrib/bind9/lib/dns/dbtable.c
+++ b/contrib/bind9/lib/dns/dbtable.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -16,7 +16,7 @@
  */
 
 /*
- * $Id: dbtable.c,v 1.28.18.3 2005/07/12 01:22:19 marka Exp $
+ * $Id: dbtable.c,v 1.33 2007/06/19 23:47:16 tbox Exp $
  */
 
 /*! \file
diff --git a/contrib/bind9/lib/dns/diff.c b/contrib/bind9/lib/dns/diff.c
index 22a3938..9489821 100644
--- a/contrib/bind9/lib/dns/diff.c
+++ b/contrib/bind9/lib/dns/diff.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: diff.c,v 1.9.18.3 2005/04/27 05:01:15 sra Exp $ */
+/* $Id: diff.c,v 1.18.50.2 2009/01/05 23:47:22 tbox Exp $ */
 
 /*! \file */
 
@@ -35,6 +35,7 @@
 #include <dns/rdataclass.h>
 #include <dns/rdatalist.h>
 #include <dns/rdataset.h>
+#include <dns/rdatastruct.h>
 #include <dns/rdatatype.h>
 #include <dns/result.h>
 
@@ -120,6 +121,7 @@ dns_difftuple_copy(dns_difftuple_t *orig, dns_difftuple_t **copyp) {
 void
 dns_diff_init(isc_mem_t *mctx, dns_diff_t *diff) {
 	diff->mctx = mctx;
+	diff->resign = 0;
 	ISC_LIST_INIT(diff->tuples);
 	diff->magic = DNS_DIFF_MAGIC;
 }
@@ -192,6 +194,40 @@ dns_diff_appendminimal(dns_diff_t *diff, dns_difftuple_t **tuplep)
 	ENSURE(*tuplep == NULL);
 }
 
+static isc_stdtime_t
+setresign(dns_rdataset_t *modified, isc_uint32_t delta) {
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	dns_rdata_rrsig_t sig;
+	isc_stdtime_t when;
+	isc_result_t result;
+
+	result = dns_rdataset_first(modified);
+	INSIST(result == ISC_R_SUCCESS);
+	dns_rdataset_current(modified, &rdata);
+	(void)dns_rdata_tostruct(&rdata, &sig, NULL);
+	if ((rdata.flags & DNS_RDATA_OFFLINE) != 0)
+		when = 0;
+	else
+		when = sig.timeexpire - delta;
+	dns_rdata_reset(&rdata);
+
+	result = dns_rdataset_next(modified);
+	while (result == ISC_R_SUCCESS) {
+		dns_rdataset_current(modified, &rdata);
+		(void)dns_rdata_tostruct(&rdata, &sig, NULL);
+		if ((rdata.flags & DNS_RDATA_OFFLINE) != 0) {
+			goto next_rr;
+		}
+		if (when == 0 || sig.timeexpire - delta < when)
+			when = sig.timeexpire - delta;
+ next_rr:
+		dns_rdata_reset(&rdata);
+		result = dns_rdataset_next(modified);
+	}
+	INSIST(result == ISC_R_NOMORE);
+	return (when);
+}
+
 static isc_result_t
 diff_apply(dns_diff_t *diff, dns_db_t *db, dns_dbversion_t *ver,
 	   isc_boolean_t warn)
@@ -220,14 +256,15 @@ diff_apply(dns_diff_t *diff, dns_db_t *db, dns_dbversion_t *ver,
 		 * but such diffs should never be created in the first
 		 * place.
 		 */
-		node = NULL;
-		CHECK(dns_db_findnode(db, name, ISC_TRUE, &node));
 
 		while (t != NULL && dns_name_equal(&t->name, name)) {
 			dns_rdatatype_t type, covers;
 			dns_diffop_t op;
 			dns_rdatalist_t rdl;
 			dns_rdataset_t rds;
+			dns_rdataset_t ardataset;
+			dns_rdataset_t *modified = NULL;
+			isc_boolean_t offline;
 
 			op = t->op;
 			type = t->rdata.type;
@@ -255,6 +292,16 @@ diff_apply(dns_diff_t *diff, dns_db_t *db, dns_dbversion_t *ver,
 			ISC_LIST_INIT(rdl.rdata);
 			ISC_LINK_INIT(&rdl, link);
 
+			node = NULL;
+			if (type != dns_rdatatype_nsec3 &&
+			    covers != dns_rdatatype_nsec3)
+				CHECK(dns_db_findnode(db, name, ISC_TRUE,
+						      &node));
+			else
+				CHECK(dns_db_findnsec3node(db, name, ISC_TRUE,
+							   &node));
+
+			offline = ISC_FALSE;
 			while (t != NULL &&
 			       dns_name_equal(&t->name, name) &&
 			       t->op == op &&
@@ -269,13 +316,15 @@ diff_apply(dns_diff_t *diff, dns_db_t *db, dns_dbversion_t *ver,
 						      sizeof(classbuf));
 				if (t->ttl != rdl.ttl && warn)
 					isc_log_write(DIFF_COMMON_LOGARGS,
-					      	ISC_LOG_WARNING,
+						ISC_LOG_WARNING,
 						"'%s/%s/%s': TTL differs in "
 						"rdataset, adjusting "
 						"%lu -> %lu",
 						namebuf, typebuf, classbuf,
 						(unsigned long) t->ttl,
 						(unsigned long) rdl.ttl);
+				if (t->rdata.flags & DNS_RDATA_OFFLINE)
+					offline = ISC_TRUE;
 				ISC_LIST_APPEND(rdl.rdata, &t->rdata, link);
 				t = ISC_LIST_NEXT(t, link);
 			}
@@ -285,28 +334,52 @@ diff_apply(dns_diff_t *diff, dns_db_t *db, dns_dbversion_t *ver,
 			 */
 			dns_rdataset_init(&rds);
 			CHECK(dns_rdatalist_tordataset(&rdl, &rds));
+			if (rds.type == dns_rdatatype_rrsig)
+				switch (op) {
+				case DNS_DIFFOP_ADDRESIGN:
+				case DNS_DIFFOP_DELRESIGN:
+					modified = &ardataset;
+					dns_rdataset_init(modified);
+					break;
+				default:
+					break;
+				}
 			rds.trust = dns_trust_ultimate;
 
 			/*
 			 * Merge the rdataset into the database.
 			 */
-			if (op == DNS_DIFFOP_ADD) {
+			switch (op) {
+			case DNS_DIFFOP_ADD:
+			case DNS_DIFFOP_ADDRESIGN:
 				result = dns_db_addrdataset(db, node, ver,
 							    0, &rds,
 							    DNS_DBADD_MERGE|
 							    DNS_DBADD_EXACT|
 							    DNS_DBADD_EXACTTTL,
-							    NULL);
-			} else if (op == DNS_DIFFOP_DEL) {
+							    modified);
+				break;
+			case DNS_DIFFOP_DEL:
+			case DNS_DIFFOP_DELRESIGN:
 				result = dns_db_subtractrdataset(db, node, ver,
 							       &rds,
 							       DNS_DBSUB_EXACT,
-							       NULL);
-			} else {
+							       modified);
+				break;
+			default:
 				INSIST(0);
 			}
-			if (result == DNS_R_UNCHANGED) {
-			  	/*
+
+			if (result == ISC_R_SUCCESS) {
+				if (modified != NULL) {
+					isc_stdtime_t resign;
+					resign = setresign(modified,
+							   diff->resign);
+					dns_db_setsigningtime(db, modified,
+							      resign);
+				}
+			} else if (result == DNS_R_UNCHANGED) {
+				/*
 				 * This will not happen when executing a
 				 * dynamic update, because that code will
 				 * generate strictly minimal diffs.
@@ -318,16 +391,21 @@ diff_apply(dns_diff_t *diff, dns_db_t *db, dns_dbversion_t *ver,
 					isc_log_write(DIFF_COMMON_LOGARGS,
 						      ISC_LOG_WARNING,
 						      "update with no effect");
-			} else if (result == ISC_R_SUCCESS ||
-				   result == DNS_R_NXRRSET) {
+			} else if (result == DNS_R_NXRRSET) {
 				/*
 				 * OK.
 				 */
 			} else {
+				if (modified != NULL &&
+				    dns_rdataset_isassociated(modified))
+					dns_rdataset_disassociate(modified);
 				CHECK(result);
 			}
+			dns_db_detachnode(db, &node);
+			if (modified != NULL &&
+			    dns_rdataset_isassociated(modified))
+				dns_rdataset_disassociate(modified);
 		}
-		dns_db_detachnode(db, &node);
 	}
 	return (ISC_R_SUCCESS);
 
@@ -455,7 +533,7 @@ dns_diff_sort(dns_diff_t *diff, dns_diff_compare_func *compare) {
 
 /*
  * Create an rdataset containing the single RR of the given
- * tuple.  The caller must allocate the the rdata, rdataset and
+ * tuple.  The caller must allocate the rdata, rdataset and
  * an rdatalist structure for it to refer to.
  */
 
@@ -485,6 +563,7 @@ dns_diff_print(dns_diff_t *diff, FILE *file) {
 	dns_difftuple_t *t;
 	char *mem = NULL;
 	unsigned int size = 2048;
+	const char *op = NULL;
 
 	REQUIRE(DNS_DIFF_VALID(diff));
 
@@ -536,15 +615,20 @@ dns_diff_print(dns_diff_t *diff, FILE *file) {
 		buf.used--;
 
 		isc_buffer_usedregion(&buf, &r);
+		switch (t->op) {
+		case DNS_DIFFOP_EXISTS: op = "exists"; break;
+		case DNS_DIFFOP_ADD: op = "add"; break;
+		case DNS_DIFFOP_DEL: op = "del"; break;
+		case DNS_DIFFOP_ADDRESIGN: op = "add re-sign"; break;
+		case DNS_DIFFOP_DELRESIGN: op = "del re-sign"; break;
+		}
 		if (file != NULL)
-			fprintf(file, "%s %.*s\n",
-				t->op == DNS_DIFFOP_ADD ?  "add" : "del",
-				(int) r.length, (char *) r.base);
+			fprintf(file, "%s %.*s\n", op, (int) r.length,
+				(char *) r.base);
 		else
 			isc_log_write(DIFF_COMMON_LOGARGS, ISC_LOG_DEBUG(7),
-				      "%s %.*s",
-				      t->op == DNS_DIFFOP_ADD ?  "add" : "del",
-				      (int) r.length, (char *) r.base);
+				      "%s %.*s", op, (int) r.length,
+				      (char *) r.base);
 	}
 	result = ISC_R_SUCCESS;
  cleanup:
diff --git a/contrib/bind9/lib/dns/dispatch.c b/contrib/bind9/lib/dns/dispatch.c
index 794cdb5..9b4e968 100644
--- a/contrib/bind9/lib/dns/dispatch.c
+++ b/contrib/bind9/lib/dns/dispatch.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dispatch.c,v 1.116.18.37 2008/09/04 00:24:41 jinmei Exp $ */
+/* $Id: dispatch.c,v 1.155.12.7 2009/04/28 21:39:45 jinmei Exp $ */
 
 /*! \file */
 
@@ -32,6 +32,7 @@
 #include <isc/portset.h>
 #include <isc/print.h>
 #include <isc/random.h>
+#include <isc/stats.h>
 #include <isc/string.h>
 #include <isc/task.h>
 #include <isc/time.h>
@@ -43,14 +44,18 @@
 #include <dns/log.h>
 #include <dns/message.h>
 #include <dns/portlist.h>
+#include <dns/stats.h>
 #include <dns/tcpmsg.h>
 #include <dns/types.h>
 
 typedef ISC_LIST(dns_dispentry_t)	dns_displist_t;
 
-typedef struct dispsocket dispsocket_t;
+typedef struct dispsocket		dispsocket_t;
 typedef ISC_LIST(dispsocket_t)		dispsocketlist_t;
 
+typedef struct dispportentry		dispportentry_t;
+typedef ISC_LIST(dispportentry_t)	dispportlist_t;
+
 /* ARC4 Random generator state */
 typedef struct arc4ctx {
 	isc_uint8_t	i;
@@ -76,6 +81,7 @@ struct dns_dispatchmgr {
 	isc_mem_t		       *mctx;
 	dns_acl_t		       *blackhole;
 	dns_portlist_t		       *portlist;
+	isc_stats_t		       *stats;
 	isc_entropy_t		       *entropy; /*%< entropy source */
 
 	/* Locked by "lock". */
@@ -170,7 +176,8 @@ struct dispsocket {
 	isc_socket_t			*socket;
 	dns_dispatch_t			*disp;
 	isc_sockaddr_t			host;
-	in_port_t			localport;
+	in_port_t			localport; /* XXX: should be removed later */
+	dispportentry_t			*portentry;
 	dns_dispentry_t			*resp;
 	isc_task_t			*task;
 	ISC_LINK(dispsocket_t)		link;
@@ -178,6 +185,21 @@ struct dispsocket {
 	ISC_LINK(dispsocket_t)		blink;
 };
 
+/*%
+ * A port table entry.  We remember every port we first open in a table with a
+ * reference counter so that we can 'reuse' the same port (with different
+ * destination addresses) using the SO_REUSEADDR socket option.
+ */
+struct dispportentry {
+	in_port_t			port;
+	unsigned int			refs;
+	ISC_LINK(struct dispportentry)	link;
+};
+
+#ifndef DNS_DISPATCH_PORTTABLESIZE
+#define DNS_DISPATCH_PORTTABLESIZE	1024
+#endif
+
 #define INVALID_BUCKET		(0xffffdead)
 
 /*%
@@ -227,6 +249,8 @@ struct dns_dispatch {
 	dns_tcpmsg_t		tcpmsg;		/*%< for tcp streams */
 	dns_qid_t		*qid;
 	arc4ctx_t		arc4ctx;	/*%< for QID/UDP port num */
+	dispportlist_t		*port_table;	/*%< hold ports 'owned' by us */
+	isc_mempool_t		*portpool;	/*%< port table entries  */
 };
 
 #define QID_MAGIC		ISC_MAGIC('Q', 'i', 'd', ' ')
@@ -330,6 +354,12 @@ mgr_log(dns_dispatchmgr_t *mgr, int level, const char *fmt, ...) {
 		      level, "dispatchmgr %p: %s", mgr, msgbuf);
 }
 
+static inline void
+inc_stats(dns_dispatchmgr_t *mgr, isc_statscounter_t counter) {
+	if (mgr->stats != NULL)
+		isc_stats_increment(mgr->stats, counter);
+}
+
 static void
 dispatch_log(dns_dispatch_t *disp, int level, const char *fmt, ...)
      ISC_FORMAT_PRINTF(3, 4);
@@ -677,6 +707,64 @@ destroy_disp(isc_task_t *task, isc_event_t *event) {
 }
 
 /*%
+ * Manipulate port table per dispatch: find an entry for a given port number,
+ * create a new entry, and decrement a given entry with possible clean-up.
+ */
+static dispportentry_t *
+port_search(dns_dispatch_t *disp, in_port_t port) {
+	dispportentry_t *portentry;
+
+	REQUIRE(disp->port_table != NULL);
+
+	portentry = ISC_LIST_HEAD(disp->port_table[port %
+						   DNS_DISPATCH_PORTTABLESIZE]);
+	while (portentry != NULL) {
+		if (portentry->port == port)
+			return (portentry);
+		portentry = ISC_LIST_NEXT(portentry, link);
+	}
+
+	return (NULL);
+}
+
+static dispportentry_t *
+new_portentry(dns_dispatch_t *disp, in_port_t port) {
+	dispportentry_t *portentry;
+
+	REQUIRE(disp->port_table != NULL);
+
+	portentry = isc_mempool_get(disp->portpool);
+	if (portentry == NULL)
+		return (portentry);
+
+	portentry->port = port;
+	portentry->refs = 0;
+	ISC_LINK_INIT(portentry, link);
+	ISC_LIST_APPEND(disp->port_table[port % DNS_DISPATCH_PORTTABLESIZE],
+			portentry, link);
+
+	return (portentry);
+}
+
+static void
+deref_portentry(dns_dispatch_t *disp, dispportentry_t **portentryp) {
+	dispportentry_t *portentry = *portentryp;
+
+	REQUIRE(disp->port_table != NULL);
+	REQUIRE(portentry != NULL && portentry->refs > 0);
+
+	portentry->refs--;
+	if (portentry->refs == 0) {
+		ISC_LIST_UNLINK(disp->port_table[portentry->port %
+						 DNS_DISPATCH_PORTTABLESIZE],
+				portentry, link);
+		isc_mempool_put(disp->portpool, portentry);
+	}
+
+	*portentryp = NULL;
+}
+
+/*%
  * Find a dispsocket for socket address 'dest', and port number 'port'.
  * Return NULL if no such entry exists.
  */
@@ -692,7 +780,7 @@ socket_search(dns_qid_t *qid, isc_sockaddr_t *dest, in_port_t port,
 
 	while (dispsock != NULL) {
 		if (isc_sockaddr_equal(dest, &dispsock->host) &&
-		    dispsock->localport == port)
+		    dispsock->portentry->port == port)
 			return (dispsock);
 		dispsock = ISC_LIST_NEXT(dispsock, blink);
 	}
@@ -720,6 +808,8 @@ get_dispsocket(dns_dispatch_t *disp, isc_sockaddr_t *dest,
 	dispsocket_t *dispsock;
 	unsigned int nports;
 	in_port_t *ports;
+	unsigned int bindoptions;
+	dispportentry_t *portentry = NULL;
 
 	if (isc_sockaddr_pf(&disp->local) == AF_INET) {
 		nports = disp->mgr->nv4ports;
@@ -745,6 +835,7 @@ get_dispsocket(dns_dispatch_t *disp, isc_sockaddr_t *dest,
 		dispsock->socket = NULL;
 		dispsock->disp = disp;
 		dispsock->resp = NULL;
+		dispsock->portentry = NULL;
 		isc_random_get(&r);
 		dispsock->task = NULL;
 		isc_task_attach(disp->task[r % disp->ntasks], &dispsock->task);
@@ -767,16 +858,29 @@ get_dispsocket(dns_dispatch_t *disp, isc_sockaddr_t *dest,
 		bucket = dns_hash(qid, dest, 0, port);
 		if (socket_search(qid, dest, port, bucket) != NULL)
 			continue;
-
-		result = open_socket(sockmgr, &localaddr, 0, &sock);
-		if (result == ISC_R_SUCCESS || result != ISC_R_ADDRINUSE)
+		bindoptions = 0;
+		portentry = port_search(disp, port);
+		if (portentry != NULL)
+			bindoptions |= ISC_SOCKET_REUSEADDRESS;
+		result = open_socket(sockmgr, &localaddr, bindoptions, &sock);
+		if (result == ISC_R_SUCCESS) {
+			if (portentry == NULL) {
+				portentry = new_portentry(disp, port);
+				if (portentry == NULL) {
+					result = ISC_R_NOMEMORY;
+					break;
+				}
+			}
+			portentry->refs++;
+			break;
+		} else if (result != ISC_R_ADDRINUSE)
 			break;
 	}
 
 	if (result == ISC_R_SUCCESS) {
 		dispsock->socket = sock;
 		dispsock->host = *dest;
-		dispsock->localport = port;
+		dispsock->portentry = portentry;
 		dispsock->bucket = bucket;
 		ISC_LIST_APPEND(qid->sock_table[bucket], dispsock, blink);
 		*dispsockp = dispsock;
@@ -813,6 +917,8 @@ destroy_dispsocket(dns_dispatch_t *disp, dispsocket_t **dispsockp) {
 
 	disp->nsockets--;
 	dispsock->magic = 0;
+	if (dispsock->portentry != NULL)
+		deref_portentry(disp, &dispsock->portentry);
 	if (dispsock->socket != NULL)
 		isc_socket_detach(&dispsock->socket);
 	if (ISC_LINK_LINKED(dispsock, blink)) {
@@ -847,6 +953,9 @@ deactivate_dispsocket(dns_dispatch_t *disp, dispsocket_t *dispsock) {
 		dispsock->resp->dispsocket = NULL;
 	}
 
+	INSIST(dispsock->portentry != NULL);
+	deref_portentry(disp, &dispsock->portentry);
+
 	if (disp->nsockets > DNS_DISPATCH_POOLSOCKS)
 		destroy_dispsocket(disp, &dispsock);
 	else {
@@ -1161,6 +1270,7 @@ udp_recv(isc_event_t *ev_in, dns_dispatch_t *disp, dispsocket_t *dispsock) {
 			     bucket, (resp == NULL ? "not found" : "found"));
 
 		if (resp == NULL) {
+			inc_stats(mgr, dns_resstatscounter_mismatch);
 			free_buffer(disp, ev->region.base, ev->region.length);
 			goto unlock;
 		}
@@ -1168,6 +1278,7 @@ udp_recv(isc_event_t *ev_in, dns_dispatch_t *disp, dispsocket_t *dispsock) {
 							 &resp->host)) {
 		dispatch_log(disp, LVL(90),
 			     "response to an exclusive socket doesn't match");
+		inc_stats(mgr, dns_resstatscounter_mismatch);
 		free_buffer(disp, ev->region.base, ev->region.length);
 		goto unlock;
 	}
@@ -1603,6 +1714,9 @@ destroy_mgr(dns_dispatchmgr_t **mgrp) {
 	if (mgr->blackhole != NULL)
 		dns_acl_detach(&mgr->blackhole);
 
+	if (mgr->stats != NULL)
+		isc_stats_detach(&mgr->stats);
+
 	if (mgr->v4ports != NULL) {
 		isc_mem_put(mctx, mgr->v4ports,
 			    mgr->nv4ports * sizeof(in_port_t));
@@ -1628,6 +1742,7 @@ open_socket(isc_socketmgr_t *mgr, isc_sockaddr_t *local,
 					   isc_sockettype_udp, &sock);
 		if (result != ISC_R_SUCCESS)
 			return (result);
+		isc_socket_setname(sock, "dispatcher", NULL);
 	} else {
 		result = isc_socket_open(sock);
 		if (result != ISC_R_SUCCESS)
@@ -1692,6 +1807,7 @@ dns_dispatchmgr_create(isc_mem_t *mctx, isc_entropy_t *entropy,
 	isc_mem_attach(mctx, &mgr->mctx);
 
 	mgr->blackhole = NULL;
+	mgr->stats = NULL;
 
 	result = isc_mutex_init(&mgr->lock);
 	if (result != ISC_R_SUCCESS)
@@ -2001,6 +2117,15 @@ dns_dispatchmgr_destroy(dns_dispatchmgr_t **mgrp) {
 		destroy_mgr(&mgr);
 }
 
+void
+dns_dispatchmgr_setstats(dns_dispatchmgr_t *mgr, isc_stats_t *stats) {
+	REQUIRE(VALID_DISPATCHMGR(mgr));
+	REQUIRE(ISC_LIST_EMPTY(mgr->list));
+	REQUIRE(mgr->stats == NULL);
+
+	isc_stats_attach(stats, &mgr->stats);
+}
+
 static int
 port_cmp(const void *key, const void *ent) {
 	in_port_t p1 = *(const in_port_t *)key;
@@ -2269,6 +2394,8 @@ dispatch_allocate(dns_dispatchmgr_t *mgr, unsigned int maxrequests,
 	ISC_LIST_INIT(disp->inactivesockets);
 	disp->nsockets = 0;
 	dispatch_arc4init(&disp->arc4ctx, mgr->entropy, NULL);
+	disp->port_table = NULL;
+	disp->portpool = NULL;
 
 	result = isc_mutex_init(&disp->lock);
 	if (result != ISC_R_SUCCESS)
@@ -2298,13 +2425,14 @@ dispatch_allocate(dns_dispatchmgr_t *mgr, unsigned int maxrequests,
 
 
 /*
- * MUST be unlocked, and not used by anthing.
+ * MUST be unlocked, and not used by anything.
  */
 static void
 dispatch_free(dns_dispatch_t **dispp)
 {
 	dns_dispatch_t *disp;
 	dns_dispatchmgr_t *mgr;
+	int i;
 
 	REQUIRE(VALID_DISPATCH(*dispp));
 	disp = *dispp;
@@ -2329,6 +2457,18 @@ dispatch_free(dns_dispatch_t **dispp)
 
 	if (disp->qid != NULL)
 		qid_destroy(mgr->mctx, &disp->qid);
+
+	if (disp->port_table != NULL) {
+		for (i = 0; i < DNS_DISPATCH_PORTTABLESIZE; i++)
+			INSIST(ISC_LIST_EMPTY(disp->port_table[i]));
+		isc_mem_put(mgr->mctx, disp->port_table,
+			    sizeof(disp->port_table[0]) *
+			    DNS_DISPATCH_PORTTABLESIZE);
+	}
+
+	if (disp->portpool != NULL)
+		isc_mempool_destroy(&disp->portpool);
+
 	disp->mgr = NULL;
 	DESTROYLOCK(&disp->lock);
 	disp->magic = 0;
@@ -2462,9 +2602,8 @@ dns_dispatch_getudp(dns_dispatchmgr_t *mgr, isc_socketmgr_t *sockmgr,
 	}
 
 	/*
-	 * First, see if we have a dispatcher that matches.
+	 * See if we have a dispatcher that matches.
 	 */
-	disp = NULL;
 	result = dispatch_find(mgr, localaddr, attributes, mask, &disp);
 	if (result == ISC_R_SUCCESS) {
 		disp->refcount++;
@@ -2569,6 +2708,15 @@ get_udpsocket(dns_dispatchmgr_t *mgr, dns_dispatch_t *disp,
 		 * If this fails 1024 times, we then ask the kernel for
 		 * choosing one.
 		 */
+	} else {
+		/* Allow to reuse address for non-random ports. */
+		result = open_socket(sockmgr, localaddr,
+				     ISC_SOCKET_REUSEADDRESS, &sock);
+
+		if (result == ISC_R_SUCCESS)
+			*sockp = sock;
+
+		return (result);
 	}
 
 	memset(held, 0, sizeof(held));
@@ -2650,6 +2798,21 @@ dispatch_createudp(dns_dispatchmgr_t *mgr, isc_socketmgr_t *sockmgr,
 			if (result != ISC_R_SUCCESS)
 				goto deallocate_dispatch;
 		}
+
+		disp->port_table = isc_mem_get(mgr->mctx,
+					       sizeof(disp->port_table[0]) *
+					       DNS_DISPATCH_PORTTABLESIZE);
+		if (disp->port_table == NULL)
+			goto deallocate_dispatch;
+		for (i = 0; i < DNS_DISPATCH_PORTTABLESIZE; i++)
+			ISC_LIST_INIT(disp->port_table[i]);
+
+		result = isc_mempool_create(mgr->mctx, sizeof(dispportentry_t),
+					    &disp->portpool);
+		if (result != ISC_R_SUCCESS)
+			goto deallocate_dispatch;
+		isc_mempool_setname(disp->portpool, "disp_portpool");
+		isc_mempool_setfreemax(disp->portpool, 128);
 	}
 	disp->socktype = isc_sockettype_udp;
 	disp->socket = sock;
@@ -2829,6 +2992,8 @@ dns_dispatch_addresponse2(dns_dispatch_t *disp, isc_sockaddr_t *dest,
 				oldestresp->item_out = ISC_TRUE;
 				isc_task_send(oldestresp->task,
 					      ISC_EVENT_PTR(&rev));
+				inc_stats(disp->mgr,
+					  dns_resstatscounter_dispabort);
 			}
 		}
 
@@ -2852,6 +3017,7 @@ dns_dispatch_addresponse2(dns_dispatch_t *disp, isc_sockaddr_t *dest,
 		if (result != ISC_R_SUCCESS) {
 			UNLOCK(&qid->lock);
 			UNLOCK(&disp->lock);
+			inc_stats(disp->mgr, dns_resstatscounter_dispsockfail);
 			return (result);
 		}
 	} else {
diff --git a/contrib/bind9/lib/dns/dlz.c b/contrib/bind9/lib/dns/dlz.c
index ee6c03b..75486af 100644
--- a/contrib/bind9/lib/dns/dlz.c
+++ b/contrib/bind9/lib/dns/dlz.c
@@ -1,8 +1,8 @@
 /*
- * Portions Copyright (C) 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2005, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -50,7 +50,7 @@
  * USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dlz.c,v 1.2.2.2 2005/09/06 03:47:17 marka Exp $ */
+/* $Id: dlz.c,v 1.5.332.2 2009/01/18 23:47:35 tbox Exp $ */
 
 /*! \file */
 
@@ -126,7 +126,7 @@ dns_dlzallowzonexfr(dns_view_t *view, dns_name_t *name,
 	dlzdatabase = view->dlzdatabase;
 	allowzonexfr = dlzdatabase->implementation->methods->allowzonexfr;
 	result = (*allowzonexfr)(dlzdatabase->implementation->driverarg,
-			         dlzdatabase->dbdata, dlzdatabase->mctx,
+				 dlzdatabase->dbdata, dlzdatabase->mctx,
 				 view->rdclass, name, clientaddr, dbp);
 
 	if (result == ISC_R_NOTIMPLEMENTED)
@@ -275,7 +275,7 @@ dns_dlzfindzone(dns_view_t *view, dns_name_t *name, unsigned int minlabels,
 	 * trying shorter names portions of the name until we find a
 	 * match, have an error, or are below the 'minlabels'
 	 * threshold.  minlabels is 0, if the standard database didn't
-	 * have a zone name match.  Otherwise minlables is the number
+	 * have a zone name match.  Otherwise minlabels is the number
 	 * of labels in that name.  We need to beat that for a
 	 * "better" match for the DLZ database to be authoritative
 	 * instead of the standard database.
diff --git a/contrib/bind9/lib/dns/dnssec.c b/contrib/bind9/lib/dns/dnssec.c
index 75ca440..f06d715 100644
--- a/contrib/bind9/lib/dns/dnssec.c
+++ b/contrib/bind9/lib/dns/dnssec.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -16,7 +16,7 @@
  */
 
 /*
- * $Id: dnssec.c,v 1.81.18.10 2007/09/14 04:35:42 marka Exp $
+ * $Id: dnssec.c,v 1.93 2008/11/14 23:47:33 tbox Exp $
  */
 
 /*! \file */
@@ -366,6 +366,9 @@ dns_dnssec_verify2(dns_name_t *name, dns_rdataset_t *set, dst_key_t *key,
 	if (ret != ISC_R_SUCCESS)
 		return (ret);
 
+	if (set->type != sig.covered)
+		return (DNS_R_SIGINVALID);
+
 	if (isc_serial_lt(sig.timeexpire, sig.timesigned))
 		return (DNS_R_SIGINVALID);
 
@@ -382,6 +385,27 @@ dns_dnssec_verify2(dns_name_t *name, dns_rdataset_t *set, dst_key_t *key,
 	}
 
 	/*
+	 * NS, SOA and DNSSKEY records are signed by their owner.
+	 * DS records are signed by the parent.
+	 */
+	switch (set->type) {
+	case dns_rdatatype_ns:
+	case dns_rdatatype_soa:
+	case dns_rdatatype_dnskey:
+		if (!dns_name_equal(name, &sig.signer))
+			return (DNS_R_SIGINVALID);
+		break;
+	case dns_rdatatype_ds:
+		if (dns_name_equal(name, &sig.signer))
+			return (DNS_R_SIGINVALID);
+		/* FALLTHROUGH */
+	default:
+		if (!dns_name_issubdomain(name, &sig.signer))
+			return (DNS_R_SIGINVALID);
+		break;
+	}
+
+	/*
 	 * Is the key allowed to sign data?
 	 */
 	flags = dst_key_flags(key);
@@ -407,7 +431,7 @@ dns_dnssec_verify2(dns_name_t *name, dns_rdataset_t *set, dst_key_t *key,
 	dns_fixedname_init(&fnewname);
 	labels = dns_name_countlabels(name) - 1;
 	RUNTIME_CHECK(dns_name_downcase(name, dns_fixedname_name(&fnewname),
-				        NULL) == ISC_R_SUCCESS);
+					NULL) == ISC_R_SUCCESS);
 	if (labels - sig.labels > 0)
 		dns_name_split(dns_fixedname_name(&fnewname), sig.labels + 1,
 			       NULL, dns_fixedname_name(&fnewname));
@@ -487,9 +511,9 @@ cleanup_struct:
 	dns_rdata_freestruct(&sig);
 
 	if (ret == ISC_R_SUCCESS && labels - sig.labels > 0) {
-		if (wild != NULL) 
+		if (wild != NULL)
 			RUNTIME_CHECK(dns_name_concatenate(dns_wildcardname,
-					         dns_fixedname_name(&fnewname),
+						 dns_fixedname_name(&fnewname),
 						 wild, NULL) == ISC_R_SUCCESS);
 		ret = DNS_R_FROMWILDCARD;
 	}
@@ -541,6 +565,9 @@ dns_dnssec_findzonekeys2(dns_db_t *db, dns_dbversion_t *ver,
 		if (!is_zone_key(pubkey) ||
 		    (dst_key_flags(pubkey) & DNS_KEYTYPE_NOAUTH) != 0)
 			goto next;
+		/* Corrupted .key file? */
+		if (!dns_name_equal(name, dst_key_name(pubkey)))
+			goto next;
 		keys[count] = NULL;
 		result = dst_key_fromfile(dst_key_name(pubkey),
 					  dst_key_id(pubkey),
@@ -802,7 +829,7 @@ dns_dnssec_verifymessage(isc_buffer_t *source, dns_message_t *msg,
 	RETERR(dst_context_create(key, mctx, &ctx));
 
 	/*
- 	 * Digest the SIG(0) record, except for the signature.
+	 * Digest the SIG(0) record, except for the signature.
 	 */
 	dns_rdata_toregion(&rdata, &r);
 	r.length -= sig.siglen;
diff --git a/contrib/bind9/lib/dns/ds.c b/contrib/bind9/lib/dns/ds.c
index 7cd1609..e994cc5 100644
--- a/contrib/bind9/lib/dns/ds.c
+++ b/contrib/bind9/lib/dns/ds.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2002, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ds.c,v 1.4.20.5 2006/02/22 23:50:09 marka Exp $ */
+/* $Id: ds.c,v 1.11 2007/06/19 23:47:16 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/dns/dst_api.c b/contrib/bind9/lib/dns/dst_api.c
index 7d98e10..144c685 100644
--- a/contrib/bind9/lib/dns/dst_api.c
+++ b/contrib/bind9/lib/dns/dst_api.c
@@ -1,9 +1,22 @@
 /*
- * Portions Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 1999-2003  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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.
+ *
  * Portions Copyright (C) 1995-2000 by Network Associates, Inc.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,7 +31,7 @@
 
 /*
  * Principal Author: Brian Wellington
- * $Id: dst_api.c,v 1.1.6.7 2006/01/27 23:57:44 marka Exp $
+ * $Id: dst_api.c,v 1.16.12.3 2009/03/02 02:00:34 marka Exp $
  */
 
 /*! \file */
@@ -60,6 +73,8 @@ static isc_entropy_t *dst_entropy_pool = NULL;
 static unsigned int dst_entropy_flags = 0;
 static isc_boolean_t dst_initialized = ISC_FALSE;
 
+void gss_log(int level, const char *fmt, ...) ISC_FORMAT_PRINTF(2, 3);
+
 isc_mem_t *dst__memory_pool = NULL;
 
 /*
@@ -110,19 +125,21 @@ static isc_result_t	addsuffix(char *filename, unsigned int len,
 			return (_r);		\
 	} while (0);				\
 
+#ifdef OPENSSL
 static void *
 default_memalloc(void *arg, size_t size) {
-        UNUSED(arg);
-        if (size == 0U)
-                size = 1;
-        return (malloc(size));
+	UNUSED(arg);
+	if (size == 0U)
+		size = 1;
+	return (malloc(size));
 }
 
 static void
 default_memfree(void *arg, void *ptr) {
-        UNUSED(arg);
-        free(ptr);
+	UNUSED(arg);
+	free(ptr);
 }
+#endif
 
 isc_result_t
 dst_lib_init(isc_mem_t *mctx, isc_entropy_t *ectx, unsigned int eflags) {
@@ -147,6 +164,7 @@ dst_lib_init(isc_mem_t *mctx, isc_entropy_t *ectx, unsigned int eflags) {
 				  NULL, &dst__memory_pool, 0);
 	if (result != ISC_R_SUCCESS)
 		return (result);
+	isc_mem_setname(dst__memory_pool, "dst", NULL);
 	isc_mem_setdestroycheck(dst__memory_pool, ISC_FALSE);
 #else
 	isc_mem_attach(mctx, &dst__memory_pool);
@@ -167,8 +185,10 @@ dst_lib_init(isc_mem_t *mctx, isc_entropy_t *ectx, unsigned int eflags) {
 	RETERR(dst__openssl_init());
 	RETERR(dst__opensslrsa_init(&dst_t_func[DST_ALG_RSAMD5]));
 	RETERR(dst__opensslrsa_init(&dst_t_func[DST_ALG_RSASHA1]));
+	RETERR(dst__opensslrsa_init(&dst_t_func[DST_ALG_NSEC3RSASHA1]));
 #ifdef HAVE_OPENSSL_DSA
 	RETERR(dst__openssldsa_init(&dst_t_func[DST_ALG_DSA]));
+	RETERR(dst__openssldsa_init(&dst_t_func[DST_ALG_NSEC3DSA]));
 #endif
 	RETERR(dst__openssldh_init(&dst_t_func[DST_ALG_DH]));
 #endif /* OPENSSL */
@@ -223,7 +243,7 @@ dst_context_create(dst_key_t *key, isc_mem_t *mctx, dst_context_t **dctxp) {
 
 	if (key->func->createctx == NULL)
 		return (DST_R_UNSUPPORTEDALG);
-	if (key->opaque == NULL)
+	if (key->keydata.generic == NULL)
 		return (DST_R_NULLKEY);
 
 	dctx = isc_mem_get(mctx, sizeof(dst_context_t));
@@ -273,8 +293,9 @@ dst_context_sign(dst_context_t *dctx, isc_buffer_t *sig) {
 
 	key = dctx->key;
 	CHECKALG(key->key_alg);
-	if (key->opaque == NULL)
+	if (key->keydata.generic == NULL)
 		return (DST_R_NULLKEY);
+
 	if (key->func->sign == NULL)
 		return (DST_R_NOTPRIVATEKEY);
 	if (key->func->isprivate == NULL ||
@@ -290,7 +311,7 @@ dst_context_verify(dst_context_t *dctx, isc_region_t *sig) {
 	REQUIRE(sig != NULL);
 
 	CHECKALG(dctx->key->key_alg);
-	if (dctx->key->opaque == NULL)
+	if (dctx->key->keydata.generic == NULL)
 		return (DST_R_NULLKEY);
 	if (dctx->key->func->verify == NULL)
 		return (DST_R_NOTPUBLICKEY);
@@ -309,7 +330,7 @@ dst_key_computesecret(const dst_key_t *pub, const dst_key_t *priv,
 	CHECKALG(pub->key_alg);
 	CHECKALG(priv->key_alg);
 
-	if (pub->opaque == NULL || priv->opaque == NULL)
+	if (pub->keydata.generic == NULL || priv->keydata.generic == NULL)
 		return (DST_R_NULLKEY);
 
 	if (pub->key_alg != priv->key_alg ||
@@ -383,10 +404,8 @@ dst_key_fromfile(dns_name_t *name, dns_keytag_t id,
 		return (result);
 	}
 
-	if (!dns_name_equal(name, key->key_name) ||
-	    id != key->key_id ||
-	    alg != key->key_alg)
-	{
+	if (!dns_name_equal(name, key->key_name) || id != key->key_id ||
+	    alg != key->key_alg) {
 		dst_key_free(&key);
 		return (DST_R_INVALIDPRIVATEKEY);
 	}
@@ -427,8 +446,7 @@ dst_key_fromnamedfile(const char *filename, int type, isc_mem_t *mctx,
 		return (result);
 
 	if ((type & (DST_TYPE_PRIVATE | DST_TYPE_PUBLIC)) == DST_TYPE_PUBLIC ||
-	    (pubkey->key_flags & DNS_KEYFLAG_TYPEMASK) == DNS_KEYTYPE_NOKEY)
-	{
+	    (pubkey->key_flags & DNS_KEYFLAG_TYPEMASK) == DNS_KEYTYPE_NOKEY) {
 		result = computeid(pubkey);
 		if (result != ISC_R_SUCCESS) {
 			dst_key_free(&pubkey);
@@ -512,7 +530,7 @@ dst_key_todns(const dst_key_t *key, isc_buffer_t *target) {
 						    & 0xffff));
 	}
 
-	if (key->opaque == NULL) /*%< NULL KEY */
+	if (key->keydata.generic == NULL) /*%< NULL KEY */
 		return (ISC_R_SUCCESS);
 
 	return (key->func->todns(key, target));
@@ -620,20 +638,71 @@ dst_key_privatefrombuffer(dst_key_t *key, isc_buffer_t *buffer) {
 	return (result);
 }
 
+gss_ctx_id_t
+dst_key_getgssctx(const dst_key_t *key)
+{
+	REQUIRE(key != NULL);
+
+	return (key->keydata.gssctx);
+}
+
 isc_result_t
-dst_key_fromgssapi(dns_name_t *name, void *opaque, isc_mem_t *mctx,
+dst_key_fromgssapi(dns_name_t *name, gss_ctx_id_t gssctx, isc_mem_t *mctx,
 		   dst_key_t **keyp)
 {
 	dst_key_t *key;
 
-	REQUIRE(opaque != NULL);
+	REQUIRE(gssctx != NULL);
 	REQUIRE(keyp != NULL && *keyp == NULL);
 
 	key = get_key_struct(name, DST_ALG_GSSAPI, 0, DNS_KEYPROTO_DNSSEC,
 			     0, dns_rdataclass_in, mctx);
 	if (key == NULL)
 		return (ISC_R_NOMEMORY);
-	key->opaque = opaque;
+
+	key->keydata.gssctx = gssctx;
+	*keyp = key;
+	return (ISC_R_SUCCESS);
+}
+
+isc_result_t
+dst_key_fromlabel(dns_name_t *name, int alg, unsigned int flags,
+		  unsigned int protocol, dns_rdataclass_t rdclass,
+		  const char *engine, const char *label, const char *pin,
+		  isc_mem_t *mctx, dst_key_t **keyp)
+{
+	dst_key_t *key;
+	isc_result_t result;
+
+	REQUIRE(dst_initialized == ISC_TRUE);
+	REQUIRE(dns_name_isabsolute(name));
+	REQUIRE(mctx != NULL);
+	REQUIRE(keyp != NULL && *keyp == NULL);
+	REQUIRE(label != NULL);
+
+	CHECKALG(alg);
+
+	key = get_key_struct(name, alg, flags, protocol, 0, rdclass, mctx);
+	if (key == NULL)
+		return (ISC_R_NOMEMORY);
+
+	if (key->func->fromlabel == NULL) {
+		dst_key_free(&key);
+		return (DST_R_UNSUPPORTEDALG);
+	}
+
+	result = key->func->fromlabel(key, engine, label, pin);
+	if (result != ISC_R_SUCCESS) {
+		dst_key_free(&key);
+		return (result);
+	}
+
+	result = computeid(key);
+	if (result != ISC_R_SUCCESS) {
+		dst_key_free(&key);
+		return (result);
+	}
+
 	*keyp = key;
 	return (ISC_R_SUCCESS);
 }
@@ -734,11 +803,14 @@ dst_key_free(dst_key_t **keyp) {
 	key = *keyp;
 	mctx = key->mctx;
 
-	if (key->opaque != NULL) {
+	if (key->keydata.generic != NULL) {
 		INSIST(key->func->destroy != NULL);
 		key->func->destroy(key);
 	}
-
+	if (key->engine != NULL)
+		isc_mem_free(mctx, key->engine);
+	if (key->label != NULL)
+		isc_mem_free(mctx, key->label);
 	dns_name_free(key->key_name, mctx);
 	isc_mem_put(mctx, key->key_name, sizeof(dns_name_t));
 	memset(key, 0, sizeof(dst_key_t));
@@ -775,9 +847,11 @@ dst_key_sigsize(const dst_key_t *key, unsigned int *n) {
 	switch (key->key_alg) {
 	case DST_ALG_RSAMD5:
 	case DST_ALG_RSASHA1:
+	case DST_ALG_NSEC3RSASHA1:
 		*n = (key->key_size + 7) / 8;
 		break;
 	case DST_ALG_DSA:
+	case DST_ALG_NSEC3DSA:
 		*n = DNS_SIG_DSASIGSIZE;
 		break;
 	case DST_ALG_HMACMD5:
@@ -860,7 +934,7 @@ get_key_struct(dns_name_t *name, unsigned int alg,
 	key->key_flags = flags;
 	key->key_proto = protocol;
 	key->mctx = mctx;
-	key->opaque = NULL;
+	key->keydata.generic = NULL;
 	key->key_size = bits;
 	key->key_class = rdclass;
 	key->func = dst_t_func[alg];
@@ -925,6 +999,13 @@ dst_key_read_public(const char *filename, int type,
 	NEXTTOKEN(lex, opt, &token);
 	if (token.type != isc_tokentype_string)
 		BADTOKEN();
+
+	/*
+	 * We don't support "@" in .key files.
+	 */
+	if (!strcmp(DST_AS_STR(token), "@"))
+		BADTOKEN();
+
 	dns_fixedname_init(&name);
 	isc_buffer_init(&b, DST_AS_STR(token), strlen(DST_AS_STR(token)));
 	isc_buffer_add(&b, strlen(DST_AS_STR(token)));
@@ -990,7 +1071,9 @@ issymmetric(const dst_key_t *key) {
 	switch (key->key_alg) {
 	case DST_ALG_RSAMD5:
 	case DST_ALG_RSASHA1:
+	case DST_ALG_NSEC3RSASHA1:
 	case DST_ALG_DSA:
+	case DST_ALG_NSEC3DSA:
 	case DST_ALG_DH:
 		return (ISC_FALSE);
 	case DST_ALG_HMACMD5:
@@ -1080,9 +1163,12 @@ write_public_key(const dst_key_t *key, int type, const char *directory) {
 	fwrite(r.base, 1, r.length, fp);
 
 	fputc('\n', fp);
+	fflush(fp);
+	if (ferror(fp))
+		ret = DST_R_WRITEERROR;
 	fclose(fp);
 
-	return (ISC_R_SUCCESS);
+	return (ret);
 }
 
 static isc_result_t
@@ -1116,8 +1202,10 @@ buildfilename(dns_name_t *name, dns_keytag_t id,
 	len = 1 + 3 + 1 + 5 + strlen(suffix) + 1;
 	if (isc_buffer_availablelength(out) < len)
 		return (ISC_R_NOSPACE);
-	sprintf((char *) isc_buffer_used(out), "+%03d+%05d%s", alg, id, suffix);
+	sprintf((char *) isc_buffer_used(out), "+%03d+%05d%s", alg, id,
+		suffix);
 	isc_buffer_add(out, len);
+
 	return (ISC_R_SUCCESS);
 }
 
@@ -1186,7 +1274,8 @@ algorithm_status(unsigned int alg) {
 #ifndef OPENSSL
 	if (alg == DST_ALG_RSAMD5 || alg == DST_ALG_RSASHA1 ||
 	    alg == DST_ALG_DSA || alg == DST_ALG_DH ||
-	    alg == DST_ALG_HMACMD5)
+	    alg == DST_ALG_HMACMD5 || alg == DST_ALG_NSEC3DSA ||
+	    alg == DST_ALG_NSEC3RSASHA1)
 		return (DST_R_NOCRYPTO);
 #endif
 	return (DST_R_UNSUPPORTEDALG);
@@ -1219,3 +1308,8 @@ dst__entropy_getdata(void *buf, unsigned int len, isc_boolean_t pseudo) {
 		flags &= ~ISC_ENTROPY_GOODONLY;
 	return (isc_entropy_getdata(dst_entropy_pool, buf, len, NULL, flags));
 }
+
+unsigned int
+dst__entropy_status(void) {
+	return (isc_entropy_status(dst_entropy_pool));
+}
diff --git a/contrib/bind9/lib/dns/dst_internal.h b/contrib/bind9/lib/dns/dst_internal.h
index f2deb72..0c1a71c 100644
--- a/contrib/bind9/lib/dns/dst_internal.h
+++ b/contrib/bind9/lib/dns/dst_internal.h
@@ -1,9 +1,22 @@
 /*
- * Portions Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 2000-2002  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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.
+ *
  * Portions Copyright (C) 1995-2000 by Network Associates, Inc.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -16,7 +29,7 @@
  * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dst_internal.h,v 1.1.6.5 2006/01/27 23:57:44 marka Exp $ */
+/* $Id: dst_internal.h,v 1.11 2008/04/01 23:47:10 tbox Exp $ */
 
 #ifndef DST_DST_INTERNAL_H
 #define DST_DST_INTERNAL_H 1
@@ -27,9 +40,22 @@
 #include <isc/magic.h>
 #include <isc/region.h>
 #include <isc/types.h>
+#include <isc/md5.h>
+#include <isc/sha1.h>
+#include <isc/hmacmd5.h>
+#include <isc/hmacsha.h>
 
 #include <dst/dst.h>
 
+#ifdef OPENSSL
+#include <openssl/dh.h>
+#include <openssl/dsa.h>
+#include <openssl/err.h>
+#include <openssl/evp.h>
+#include <openssl/objects.h>
+#include <openssl/rsa.h>
+#endif
+
 ISC_LANG_BEGINDECLS
 
 #define KEY_MAGIC       ISC_MAGIC('D','S','T','K')
@@ -46,6 +72,13 @@ extern isc_mem_t *dst__memory_pool;
 
 typedef struct dst_func dst_func_t;
 
+typedef struct dst_hmacmd5_key    dst_hmacmd5_key_t;
+typedef struct dst_hmacsha1_key   dst_hmacsha1_key_t;
+typedef struct dst_hmacsha224_key dst_hmacsha224_key_t;
+typedef struct dst_hmacsha256_key dst_hmacsha256_key_t;
+typedef struct dst_hmacsha384_key dst_hmacsha384_key_t;
+typedef struct dst_hmacsha512_key dst_hmacsha512_key_t;
+
 /*% DST Key Structure */
 struct dst_key {
 	unsigned int	magic;
@@ -58,7 +91,27 @@ struct dst_key {
 	isc_uint16_t	key_bits;	/*%< hmac digest bits */
 	dns_rdataclass_t key_class;	/*%< class of the key record */
 	isc_mem_t	*mctx;		/*%< memory context */
-	void *		opaque;		/*%< pointer to key in crypto pkg fmt */
+	char		*engine;	/*%< engine name (HSM) */
+	char		*label;		/*%< engine label (HSM) */
+	union {
+		void *generic;
+		gss_ctx_id_t gssctx;
+#ifdef OPENSSL
+#if USE_EVP_RSA
+		RSA *rsa;
+#endif
+		DSA *dsa;
+		DH *dh;
+		EVP_PKEY *pkey;
+#endif
+		dst_hmacmd5_key_t *hmacmd5;
+		dst_hmacsha1_key_t *hmacsha1;
+		dst_hmacsha224_key_t *hmacsha224;
+		dst_hmacsha256_key_t *hmacsha256;
+		dst_hmacsha384_key_t *hmacsha384;
+		dst_hmacsha512_key_t *hmacsha512;
+
+	} keydata;			/*%< pointer to key in crypto pkg fmt */
 	dst_func_t *	func;		/*%< crypto package specific functions */
 };
 
@@ -66,7 +119,21 @@ struct dst_context {
 	unsigned int magic;
 	dst_key_t *key;
 	isc_mem_t *mctx;
-	void *opaque;
+	union {
+		void *generic;
+		dst_gssapi_signverifyctx_t *gssctx;
+		isc_md5_t *md5ctx;
+		isc_sha1_t *sha1ctx;
+		isc_hmacmd5_t *hmacmd5ctx;
+		isc_hmacsha1_t *hmacsha1ctx;
+		isc_hmacsha224_t *hmacsha224ctx;
+		isc_hmacsha256_t *hmacsha256ctx;
+		isc_hmacsha384_t *hmacsha384ctx;
+		isc_hmacsha512_t *hmacsha512ctx;
+#ifdef OPENSSL
+		EVP_MD_CTX *evp_md_ctx;
+#endif
+	} ctxdata;
 };
 
 struct dst_func {
@@ -100,6 +167,9 @@ struct dst_func {
 
 	/* cleanup */
 	void (*cleanup)(void);
+
+	isc_result_t (*fromlabel)(dst_key_t *key, const char *engine,
+				  const char *label, const char *pin);
 };
 
 /*%
@@ -136,6 +206,11 @@ void * dst__mem_realloc(void *ptr, size_t size);
 isc_result_t dst__entropy_getdata(void *buf, unsigned int len,
 				  isc_boolean_t pseudo);
 
+/*
+ * Entropy status hook.
+ */
+unsigned int dst__entropy_status(void);
+
 ISC_LANG_ENDDECLS
 
 #endif /* DST_DST_INTERNAL_H */
diff --git a/contrib/bind9/lib/dns/dst_lib.c b/contrib/bind9/lib/dns/dst_lib.c
index 305051c..f1021d3 100644
--- a/contrib/bind9/lib/dns/dst_lib.c
+++ b/contrib/bind9/lib/dns/dst_lib.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -17,7 +17,7 @@
 
 /*
  * Principal Author: Brian Wellington
- * $Id: dst_lib.c,v 1.1.6.3 2005/04/29 00:15:51 marka Exp $
+ * $Id: dst_lib.c,v 1.5 2007/06/19 23:47:16 tbox Exp $
  */
 
 /*! \file */
diff --git a/contrib/bind9/lib/dns/dst_openssl.h b/contrib/bind9/lib/dns/dst_openssl.h
index 79e10b0..80eef93 100644
--- a/contrib/bind9/lib/dns/dst_openssl.h
+++ b/contrib/bind9/lib/dns/dst_openssl.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dst_openssl.h,v 1.1.4.3 2005/04/29 00:15:52 marka Exp $ */
+/* $Id: dst_openssl.h,v 1.7 2008/04/01 23:47:10 tbox Exp $ */
 
 #ifndef DST_OPENSSL_H
 #define DST_OPENSSL_H 1
@@ -28,6 +28,12 @@ ISC_LANG_BEGINDECLS
 isc_result_t
 dst__openssl_toresult(isc_result_t fallback);
 
+ENGINE *
+dst__openssl_getengine(const char *name);
+
+isc_result_t
+dst__openssl_setdefault(const char *name);
+
 ISC_LANG_ENDDECLS
 
 #endif /* DST_OPENSSL_H */
diff --git a/contrib/bind9/lib/dns/dst_parse.c b/contrib/bind9/lib/dns/dst_parse.c
index ce361ef..2da72ae 100644
--- a/contrib/bind9/lib/dns/dst_parse.c
+++ b/contrib/bind9/lib/dns/dst_parse.c
@@ -1,6 +1,19 @@
 /*
- * Portions Copyright (C) 2004-2006, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 1999-2002  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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.
+ *
  * Portions Copyright (C) 1995-2000 by Network Associates, Inc.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -18,7 +31,7 @@
 
 /*%
  * Principal Author: Brian Wellington
- * $Id: dst_parse.c,v 1.1.6.9 2008/01/22 23:27:05 tbox Exp $
+ * $Id: dst_parse.c,v 1.14.120.2 2009/03/02 23:47:11 tbox Exp $
  */
 
 #include <config.h>
@@ -54,6 +67,9 @@ static struct parse_map map[] = {
 	{TAG_RSA_EXPONENT1, "Exponent1:"},
 	{TAG_RSA_EXPONENT2, "Exponent2:"},
 	{TAG_RSA_COEFFICIENT, "Coefficient:"},
+	{TAG_RSA_ENGINE, "Engine:" },
+	{TAG_RSA_LABEL, "Label:" },
+	{TAG_RSA_PIN, "PIN:" },
 
 	{TAG_DH_PRIME, "Prime(p):"},
 	{TAG_DH_GENERATOR, "Generator(g):"},
@@ -115,16 +131,39 @@ find_tag(const int value) {
 static int
 check_rsa(const dst_private_t *priv) {
 	int i, j;
-	if (priv->nelements != RSA_NTAGS)
-		return (-1);
-	for (i = 0; i < RSA_NTAGS; i++) {
-		for (j = 0; j < priv->nelements; j++)
+	isc_boolean_t have[RSA_NTAGS];
+	isc_boolean_t ok;
+	unsigned int mask;
+
+	for (i = 0; i < RSA_NTAGS; i++)
+		have[i] = ISC_FALSE;
+	for (j = 0; j < priv->nelements; j++) {
+		for (i = 0; i < RSA_NTAGS; i++)
 			if (priv->elements[j].tag == TAG(DST_ALG_RSAMD5, i))
 				break;
-		if (j == priv->nelements)
+		if (i == RSA_NTAGS)
 			return (-1);
+		have[i] = ISC_TRUE;
 	}
-	return (0);
+
+	mask = ~0;
+	mask <<= sizeof(mask) * 8 - TAG_SHIFT;
+	mask >>= sizeof(mask) * 8 - TAG_SHIFT;
+
+	if (have[TAG_RSA_ENGINE & mask])
+		ok = have[TAG_RSA_MODULUS & mask] &&
+		     have[TAG_RSA_PUBLICEXPONENT & mask] &&
+		     have[TAG_RSA_LABEL & mask];
+	else
+		ok = have[TAG_RSA_MODULUS & mask] &&
+		     have[TAG_RSA_PUBLICEXPONENT & mask] &&
+		     have[TAG_RSA_PRIVATEEXPONENT & mask] &&
+		     have[TAG_RSA_PRIME1 & mask] &&
+		     have[TAG_RSA_PRIME2 & mask] &&
+		     have[TAG_RSA_EXPONENT1 & mask] &&
+		     have[TAG_RSA_EXPONENT2 & mask] &&
+		     have[TAG_RSA_COEFFICIENT & mask];
+	return (ok ? 0 : -1 );
 }
 
 static int
@@ -486,8 +525,10 @@ dst__privstruct_writefile(const dst_key_t *key, const dst_private_t *priv,
 		fprintf(fp, "\n");
 	}
 
+	fflush(fp);
+	iret = ferror(fp) ? DST_R_WRITEERROR : ISC_R_SUCCESS;
 	fclose(fp);
-	return (ISC_R_SUCCESS);
+	return (iret);
 }
 
 /*! \file */
diff --git a/contrib/bind9/lib/dns/dst_parse.h b/contrib/bind9/lib/dns/dst_parse.h
index 665fcfc..27c7580 100644
--- a/contrib/bind9/lib/dns/dst_parse.h
+++ b/contrib/bind9/lib/dns/dst_parse.h
@@ -1,6 +1,19 @@
 /*
- * Portions Copyright (C) 2004-2006, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 2000-2002  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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.
+ *
  * Portions Copyright (C) 1995-2000 by Network Associates, Inc.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -16,7 +29,7 @@
  * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dst_parse.h,v 1.1.6.7 2008/05/15 23:46:06 tbox Exp $ */
+/* $Id: dst_parse.h,v 1.11 2008/05/15 00:50:26 each Exp $ */
 
 /*! \file */
 #ifndef DST_DST_PARSE_H
@@ -37,7 +50,7 @@
 #define TAG(alg, off)		(((alg) << TAG_SHIFT) + (off))
 
 /* These are used by both RSA-MD5 and RSA-SHA1 */
-#define RSA_NTAGS		8
+#define RSA_NTAGS		11
 #define TAG_RSA_MODULUS		((DST_ALG_RSAMD5 << TAG_SHIFT) + 0)
 #define TAG_RSA_PUBLICEXPONENT	((DST_ALG_RSAMD5 << TAG_SHIFT) + 1)
 #define TAG_RSA_PRIVATEEXPONENT	((DST_ALG_RSAMD5 << TAG_SHIFT) + 2)
@@ -46,6 +59,9 @@
 #define TAG_RSA_EXPONENT1	((DST_ALG_RSAMD5 << TAG_SHIFT) + 5)
 #define TAG_RSA_EXPONENT2	((DST_ALG_RSAMD5 << TAG_SHIFT) + 6)
 #define TAG_RSA_COEFFICIENT	((DST_ALG_RSAMD5 << TAG_SHIFT) + 7)
+#define TAG_RSA_ENGINE		((DST_ALG_RSAMD5 << TAG_SHIFT) + 8)
+#define TAG_RSA_LABEL		((DST_ALG_RSAMD5 << TAG_SHIFT) + 9)
+#define TAG_RSA_PIN		((DST_ALG_RSAMD5 << TAG_SHIFT) + 10)
 
 #define DH_NTAGS		4
 #define TAG_DH_PRIME		((DST_ALG_DH << TAG_SHIFT) + 0)
diff --git a/contrib/bind9/lib/dns/dst_result.c b/contrib/bind9/lib/dns/dst_result.c
index c9bf073..429dbb2 100644
--- a/contrib/bind9/lib/dns/dst_result.c
+++ b/contrib/bind9/lib/dns/dst_result.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -17,7 +17,7 @@
 
 /*%
  * Principal Author: Brian Wellington
- * $Id: dst_result.c,v 1.1.6.3 2005/04/29 00:15:52 marka Exp $
+ * $Id: dst_result.c,v 1.7 2008/04/01 23:47:10 tbox Exp $
  */
 
 #include <config.h>
@@ -49,7 +49,8 @@ static const char *text[DST_R_NRESULTS] = {
 	"not a key that can compute a secret",	/*%< 17 */
 	"failure computing a shared secret",	/*%< 18 */
 	"no randomness available",		/*%< 19 */
-	"bad key type"				/*%< 20 */
+	"bad key type",				/*%< 20 */
+	"no engine"				/*%< 21 */
 };
 
 #define DST_RESULT_RESULTSET			2
diff --git a/contrib/bind9/lib/dns/forward.c b/contrib/bind9/lib/dns/forward.c
index e80a477..39e2ef5 100644
--- a/contrib/bind9/lib/dns/forward.c
+++ b/contrib/bind9/lib/dns/forward.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: forward.c,v 1.6.18.4 2005/07/12 01:22:20 marka Exp $ */
+/* $Id: forward.c,v 1.12 2007/06/19 23:47:16 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/dns/gen-unix.h b/contrib/bind9/lib/dns/gen-unix.h
index fc2dbf2..4186f63 100644
--- a/contrib/bind9/lib/dns/gen-unix.h
+++ b/contrib/bind9/lib/dns/gen-unix.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: gen-unix.h,v 1.14.18.3 2005/06/08 02:07:54 marka Exp $ */
+/* $Id: gen-unix.h,v 1.19.332.2 2009/01/18 23:47:35 tbox Exp $ */
 
 /*! \file
  * \brief
@@ -23,7 +23,7 @@
  * directly portable between Unix-like systems and Windows NT, option
  * parsing and directory scanning.  It is here because it was decided
  * that the "gen" build utility was not to depend on libisc.a, so
- * the functions delcared in isc/commandline.h and isc/dir.h could not
+ * the functions declared in isc/commandline.h and isc/dir.h could not
  * be used.
  *
  * The commandline stuff is really just a wrapper around getopt().
diff --git a/contrib/bind9/lib/dns/gen.c b/contrib/bind9/lib/dns/gen.c
index 1e6212a..ede8bc0 100644
--- a/contrib/bind9/lib/dns/gen.c
+++ b/contrib/bind9/lib/dns/gen.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: gen.c,v 1.73.18.6 2006/10/02 06:36:43 marka Exp $ */
+/* $Id: gen.c,v 1.83 2008/09/25 04:02:38 tbox Exp $ */
 
 /*! \file */
 
@@ -41,6 +41,8 @@
 #include "gen-unix.h"
 #endif
 
+#define TYPECLASSLEN 21
+
 #define FROMTEXTARGS "rdclass, type, lexer, origin, options, target, callbacks"
 #define FROMTEXTCLASS "rdclass"
 #define FROMTEXTTYPE "type"
@@ -134,21 +136,21 @@ const char copyright[] =
 struct cc {
 	struct cc *next;
 	int rdclass;
-	char classname[11];
+	char classname[TYPECLASSLEN];
 } *classes;
 
 struct tt {
 	struct tt *next;
 	int rdclass;
 	int type;
-	char classname[11];
-	char typename[11];
+	char classname[TYPECLASSLEN];
+	char typename[TYPECLASSLEN];
 	char dirname[256];		/* XXX Should be max path length */
 } *types;
 
 struct ttnam {
-	char typename[11];
-	char macroname[11];
+	char typename[TYPECLASSLEN];
+	char macroname[TYPECLASSLEN];
 	char attr[256];
 	unsigned int sorted;
 	int type;
@@ -215,7 +217,7 @@ doswitch(const char *name, const char *function, const char *args,
 	int first = 1;
 	int lasttype = 0;
 	int subswitch = 0;
-	char buf1[11], buf2[11];
+	char buf1[TYPECLASSLEN], buf2[TYPECLASSLEN];
 	const char *result = " result =";
 
 	if (res == NULL)
@@ -281,7 +283,7 @@ doswitch(const char *name, const char *function, const char *args,
 void
 dodecl(char *type, char *function, char *args) {
 	struct tt *tt;
-	char buf1[11], buf2[11];
+	char buf1[TYPECLASSLEN], buf2[TYPECLASSLEN];
 
 	fputs("\n", stdout);
 	for (tt = types; tt; tt = tt->next)
@@ -332,7 +334,7 @@ insert_into_typenames(int type, const char *typename, const char *attr) {
 		fprintf(stderr, "Error: typenames array too small\n");
 		exit(1);
 	}
-	
+
 	if (strlen(typename) > sizeof(ttn->typename) - 1) {
 		fprintf(stderr, "Error:  type name %s is too long\n",
 			typename);
@@ -392,6 +394,8 @@ add(int rdclass, const char *classname, int type, const char *typename,
 	newtt->type = type;
 	strcpy(newtt->classname, classname);
 	strcpy(newtt->typename, typename);
+	if (strncmp(dirname, "./", 2) == 0)
+		dirname += 2;
 	strcpy(newtt->dirname, dirname);
 
 	tt = types;
@@ -449,16 +453,16 @@ add(int rdclass, const char *classname, int type, const char *typename,
 
 void
 sd(int rdclass, const char *classname, const char *dirname, char filetype) {
-	char buf[sizeof("0123456789_65535.h")];
-	char fmt[sizeof("%10[-0-9a-z]_%d.h")];
+	char buf[sizeof("01234567890123456789_65535.h")];
+	char fmt[sizeof("%20[-0-9a-z]_%d.h")];
 	int type;
-	char typename[11];
+	char typename[TYPECLASSLEN];
 	isc_dir_t dir;
 
 	if (!start_directory(dirname, &dir))
 		return;
 
-	sprintf(fmt,"%s%c", "%10[-0-9a-z]_%d.", filetype);
+	sprintf(fmt,"%s%c", "%20[-0-9a-z]_%d.", filetype);
 	while (next_file(&dir)) {
 		if (sscanf(dir.filename, fmt, typename, &type) != 2)
 			continue;
@@ -495,7 +499,7 @@ main(int argc, char **argv) {
 	char buf[256];			/* XXX Should be max path length */
 	char srcdir[256];		/* XXX Should be max path length */
 	int rdclass;
-	char classname[11];
+	char classname[TYPECLASSLEN];
 	struct tt *tt;
 	struct cc *cc;
 	struct ttnam *ttn, *ttn2;
@@ -510,7 +514,7 @@ main(int argc, char **argv) {
 	int structs = 0;
 	int depend = 0;
 	int c, i, j;
-	char buf1[11];
+	char buf1[TYPECLASSLEN];
 	char filetype = 'c';
 	FILE *fd;
 	char *prefix = NULL;
@@ -594,7 +598,7 @@ main(int argc, char **argv) {
 	sd(0, "", buf, filetype);
 
 	if (time(&now) != -1) {
-		if ((tm = localtime(&now)) != NULL && tm->tm_year > 104) 
+		if ((tm = localtime(&now)) != NULL && tm->tm_year > 104)
 			sprintf(year, "-%d", tm->tm_year + 1900);
 		else
 			year[0] = 0;
@@ -692,7 +696,7 @@ main(int argc, char **argv) {
 				"\t\t    strncasecmp(_s,(_tn),"
 				"(sizeof(_s) - 1)) == 0) { \\\n");
 		fprintf(stdout, "\t\t\tif ((dns_rdatatype_attributes(_d) & "
-		       		  "DNS_RDATATYPEATTR_RESERVED) != 0) \\\n");
+				  "DNS_RDATATYPEATTR_RESERVED) != 0) \\\n");
 		fprintf(stdout, "\t\t\t\treturn (ISC_R_NOTIMPLEMENTED); \\\n");
 		fprintf(stdout, "\t\t\t*(_tp) = _d; \\\n");
 		fprintf(stdout, "\t\t\treturn (ISC_R_SUCCESS); \\\n");
@@ -743,7 +747,7 @@ main(int argc, char **argv) {
 			if (ttn == NULL)
 				continue;
 			fprintf(stdout, "\tcase %u: return (%s); \\\n",
-			        i, upper(ttn->attr));
+				i, upper(ttn->attr));
 		}
 		fprintf(stdout, "\t}\n");
 
@@ -755,7 +759,7 @@ main(int argc, char **argv) {
 				continue;
 			fprintf(stdout, "\tcase %u: return "
 				"(str_totext(\"%s\", target)); \\\n",
-			        i, upper(ttn->typename));
+				i, upper(ttn->typename));
 		}
 		fprintf(stdout, "\t}\n");
 
diff --git a/contrib/bind9/lib/dns/gssapi_link.c b/contrib/bind9/lib/dns/gssapi_link.c
index a6a367a..0dd27bb 100644
--- a/contrib/bind9/lib/dns/gssapi_link.c
+++ b/contrib/bind9/lib/dns/gssapi_link.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -16,13 +16,13 @@
  */
 
 /*
- * $Id: gssapi_link.c,v 1.1.6.3 2005/04/29 00:15:53 marka Exp $
+ * $Id: gssapi_link.c,v 1.12 2008/11/11 03:55:01 marka Exp $
  */
 
-#ifdef GSSAPI
-
 #include <config.h>
 
+#ifdef GSSAPI
+
 #include <isc/buffer.h>
 #include <isc/mem.h>
 #include <isc/string.h>
@@ -33,60 +33,73 @@
 #include "dst_internal.h"
 #include "dst_parse.h"
 
-#include <gssapi/gssapi.h>
+#include <dst/gssapi.h>
 
 #define INITIAL_BUFFER_SIZE 1024
 #define BUFFER_EXTRA 1024
 
 #define REGION_TO_GBUFFER(r, gb) \
 	do { \
-		(gb).length = (r).length;	\
-		(gb).value = (r).base;	\
+		(gb).length = (r).length; \
+		(gb).value = (r).base; \
 	} while (0)
 
-typedef struct gssapi_ctx {
-	isc_buffer_t *buffer;
-	gss_ctx_id_t *context_id;
-} gssapi_ctx_t;
 
+struct dst_gssapi_signverifyctx {
+	isc_buffer_t *buffer;
+};
 
+/*%
+ * Allocate a temporary "context" for use in gathering data for signing
+ * or verifying.
+ */
 static isc_result_t
-gssapi_createctx(dst_key_t *key, dst_context_t *dctx) {
-	gssapi_ctx_t *ctx;
+gssapi_create_signverify_ctx(dst_key_t *key, dst_context_t *dctx) {
+	dst_gssapi_signverifyctx_t *ctx;
 	isc_result_t result;
 
 	UNUSED(key);
 
-	ctx = isc_mem_get(dctx->mctx, sizeof(gssapi_ctx_t));
+	ctx = isc_mem_get(dctx->mctx, sizeof(dst_gssapi_signverifyctx_t));
 	if (ctx == NULL)
 		return (ISC_R_NOMEMORY);
 	ctx->buffer = NULL;
 	result = isc_buffer_allocate(dctx->mctx, &ctx->buffer,
 				     INITIAL_BUFFER_SIZE);
 	if (result != ISC_R_SUCCESS) {
-		isc_mem_put(dctx->mctx, ctx, sizeof(gssapi_ctx_t));
+		isc_mem_put(dctx->mctx, ctx, sizeof(dst_gssapi_signverifyctx_t));
 		return (result);
 	}
-	ctx->context_id = key->opaque;
-	dctx->opaque = ctx;
+
+	dctx->ctxdata.gssctx = ctx;
+
 	return (ISC_R_SUCCESS);
 }
 
+/*%
+ * Destroy the temporary sign/verify context.
+ */
 static void
-gssapi_destroyctx(dst_context_t *dctx) {
-	gssapi_ctx_t *ctx = dctx->opaque;
+gssapi_destroy_signverify_ctx(dst_context_t *dctx) {
+	dst_gssapi_signverifyctx_t *ctx = dctx->ctxdata.gssctx;
 
 	if (ctx != NULL) {
 		if (ctx->buffer != NULL)
 			isc_buffer_free(&ctx->buffer);
-		isc_mem_put(dctx->mctx, ctx, sizeof(gssapi_ctx_t));
-		dctx->opaque = NULL;
+		isc_mem_put(dctx->mctx, ctx, sizeof(dst_gssapi_signverifyctx_t));
+		dctx->ctxdata.gssctx = NULL;
 	}
 }
 
+/*%
+ * Add data to our running buffer of data we will be signing or verifying.
+ * This code will see if the new data will fit in our existing buffer, and
+ * copy it in if it will.  If not, it will attempt to allocate a larger
+ * buffer and copy old+new into it, and free the old buffer.
+ */
 static isc_result_t
 gssapi_adddata(dst_context_t *dctx, const isc_region_t *data) {
-	gssapi_ctx_t *ctx = dctx->opaque;
+	dst_gssapi_signverifyctx_t *ctx = dctx->ctxdata.gssctx;
 	isc_buffer_t *newbuffer = NULL;
 	isc_region_t r;
 	unsigned int length;
@@ -103,8 +116,8 @@ gssapi_adddata(dst_context_t *dctx, const isc_region_t *data) {
 		return (result);
 
 	isc_buffer_usedregion(ctx->buffer, &r);
-	(void) isc_buffer_copyregion(newbuffer, &r);
-	(void) isc_buffer_copyregion(newbuffer, data);
+	(void)isc_buffer_copyregion(newbuffer, &r);
+	(void)isc_buffer_copyregion(newbuffer, data);
 
 	isc_buffer_free(&ctx->buffer);
 	ctx->buffer = newbuffer;
@@ -112,56 +125,129 @@ gssapi_adddata(dst_context_t *dctx, const isc_region_t *data) {
 	return (ISC_R_SUCCESS);
 }
 
+/*%
+ * Sign.
+ */
 static isc_result_t
 gssapi_sign(dst_context_t *dctx, isc_buffer_t *sig) {
-	gssapi_ctx_t *ctx = dctx->opaque;
+	dst_gssapi_signverifyctx_t *ctx = dctx->ctxdata.gssctx;
 	isc_region_t message;
 	gss_buffer_desc gmessage, gsig;
 	OM_uint32 minor, gret;
+	gss_ctx_id_t gssctx = dctx->key->keydata.gssctx;
+	char buf[1024];
 
+	/*
+	 * Convert the data we wish to sign into a structure gssapi can
+	 * understand.
+	 */
 	isc_buffer_usedregion(ctx->buffer, &message);
 	REGION_TO_GBUFFER(message, gmessage);
 
-	gret = gss_get_mic(&minor, ctx->context_id,
-			   GSS_C_QOP_DEFAULT, &gmessage, &gsig);
-	if (gret != 0)
+	/*
+	 * Generate the signature.
+	 */
+	gret = gss_get_mic(&minor, gssctx, GSS_C_QOP_DEFAULT, &gmessage,
+			   &gsig);
+
+	/*
+	 * If it did not complete, we log the result and return a generic
+	 * failure code.
+	 */
+	if (gret != GSS_S_COMPLETE) {
+		gss_log(3, "GSS sign error: %s",
+			gss_error_tostring(gret, minor, buf, sizeof(buf)));
 		return (ISC_R_FAILURE);
+	}
 
+	/*
+	 * If it will not fit in our allocated buffer, return that we need
+	 * more space.
+	 */
 	if (gsig.length > isc_buffer_availablelength(sig)) {
 		gss_release_buffer(&minor, &gsig);
 		return (ISC_R_NOSPACE);
 	}
 
+	/*
+	 * Copy the output into our buffer space, and release the gssapi
+	 * allocated space.
+	 */
 	isc_buffer_putmem(sig, gsig.value, gsig.length);
-
-	gss_release_buffer(&minor, &gsig);
+	if (gsig.length != 0)
+		gss_release_buffer(&minor, &gsig);
 
 	return (ISC_R_SUCCESS);
 }
 
+/*%
+ * Verify.
+ */
 static isc_result_t
 gssapi_verify(dst_context_t *dctx, const isc_region_t *sig) {
-	gssapi_ctx_t *ctx = dctx->opaque;
-	isc_region_t message;
+	dst_gssapi_signverifyctx_t *ctx = dctx->ctxdata.gssctx;
+	isc_region_t message, r;
 	gss_buffer_desc gmessage, gsig;
 	OM_uint32 minor, gret;
-
+	gss_ctx_id_t gssctx = dctx->key->keydata.gssctx;
+	unsigned char *buf;
+	char err[1024];
+
+	/*
+	 * Convert the data we wish to sign into a structure gssapi can
+	 * understand.
+	 */
 	isc_buffer_usedregion(ctx->buffer, &message);
 	REGION_TO_GBUFFER(message, gmessage);
 
-	REGION_TO_GBUFFER(*sig, gsig);
-
-	gret = gss_verify_mic(&minor, ctx->context_id, &gmessage, &gsig, NULL);
-	if (gret != 0)
+	/*
+	 * XXXMLG
+	 * It seem that gss_verify_mic() modifies the signature buffer,
+	 * at least on Heimdal's implementation.  Copy it here to an allocated
+	 * buffer.
+	 */
+	buf = isc_mem_allocate(dst__memory_pool, sig->length);
+	if (buf == NULL)
 		return (ISC_R_FAILURE);
+	memcpy(buf, sig->base, sig->length);
+	r.base = buf;
+	r.length = sig->length;
+	REGION_TO_GBUFFER(r, gsig);
+
+	/*
+	 * Verify the data.
+	 */
+	gret = gss_verify_mic(&minor, gssctx, &gmessage, &gsig, NULL);
+
+	isc_mem_free(dst__memory_pool, buf);
+
+	/*
+	 * Convert return codes into something useful to us.
+	 */
+	if (gret != GSS_S_COMPLETE) {
+		gss_log(3, "GSS verify error: %s",
+			gss_error_tostring(gret, minor, err, sizeof(err)));
+		if (gret == GSS_S_DEFECTIVE_TOKEN ||
+		    gret == GSS_S_BAD_SIG ||
+		    gret == GSS_S_DUPLICATE_TOKEN ||
+		    gret == GSS_S_OLD_TOKEN ||
+		    gret == GSS_S_UNSEQ_TOKEN ||
+		    gret == GSS_S_GAP_TOKEN ||
+		    gret == GSS_S_CONTEXT_EXPIRED ||
+		    gret == GSS_S_NO_CONTEXT ||
+		    gret == GSS_S_FAILURE)
+			return(DST_R_VERIFYFAILURE);
+		else
+			return (ISC_R_FAILURE);
+	}
 
 	return (ISC_R_SUCCESS);
 }
 
 static isc_boolean_t
 gssapi_compare(const dst_key_t *key1, const dst_key_t *key2) {
-	gss_ctx_id_t gsskey1 = key1->opaque;
-	gss_ctx_id_t gsskey2 = key2->opaque;
+	gss_ctx_id_t gsskey1 = key1->keydata.gssctx;
+	gss_ctx_id_t gsskey2 = key2->keydata.gssctx;
 
 	/* No idea */
 	return (ISC_TF(gsskey1 == gsskey2));
@@ -179,18 +265,19 @@ gssapi_generate(dst_key_t *key, int unused) {
 static isc_boolean_t
 gssapi_isprivate(const dst_key_t *key) {
 	UNUSED(key);
-        return (ISC_TRUE);
+	return (ISC_TRUE);
 }
 
 static void
 gssapi_destroy(dst_key_t *key) {
-	UNUSED(key);
-	/* No idea */
+	REQUIRE(key != NULL);
+	dst_gssapi_deletectx(key->mctx, &key->keydata.gssctx);
+	key->keydata.gssctx = NULL;
 }
 
 static dst_func_t gssapi_functions = {
-	gssapi_createctx,
-	gssapi_destroyctx,
+	gssapi_create_signverify_ctx,
+	gssapi_destroy_signverify_ctx,
 	gssapi_adddata,
 	gssapi_sign,
 	gssapi_verify,
@@ -205,6 +292,7 @@ static dst_func_t gssapi_functions = {
 	NULL, /*%< tofile */
 	NULL, /*%< parse */
 	NULL, /*%< cleanup */
+	NULL  /*%< fromlabel */
 };
 
 isc_result_t
diff --git a/contrib/bind9/lib/dns/gssapictx.c b/contrib/bind9/lib/dns/gssapictx.c
index ce5d6fa..11eadb9 100644
--- a/contrib/bind9/lib/dns/gssapictx.c
+++ b/contrib/bind9/lib/dns/gssapictx.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,11 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: gssapictx.c,v 1.1.6.3 2005/04/29 00:15:54 marka Exp $ */
+/* $Id: gssapictx.c,v 1.12 2008/04/03 06:09:04 tbox Exp $ */
 
 #include <config.h>
 
 #include <stdlib.h>
+#include <string.h>
 
 #include <isc/buffer.h>
 #include <isc/dir.h>
@@ -27,6 +28,7 @@
 #include <isc/lex.h>
 #include <isc/mem.h>
 #include <isc/once.h>
+#include <isc/print.h>
 #include <isc/random.h>
 #include <isc/string.h>
 #include <isc/time.h>
@@ -39,34 +41,76 @@
 #include <dns/result.h>
 #include <dns/types.h>
 #include <dns/keyvalues.h>
+#include <dns/log.h>
 
 #include <dst/gssapi.h>
 #include <dst/result.h>
 
 #include "dst_internal.h"
 
-#ifdef GSSAPI
+/*
+ * If we're using our own SPNEGO implementation (see configure.in),
+ * pull it in now.  Otherwise, we just use whatever GSSAPI supplies.
+ */
+#if defined(GSSAPI) && defined(USE_ISC_SPNEGO)
+#include "spnego.h"
+#define	gss_accept_sec_context	gss_accept_sec_context_spnego
+#define	gss_init_sec_context	gss_init_sec_context_spnego
+#endif
 
-#include <gssapi/gssapi.h>
+/*
+ * Solaris8 apparently needs an explicit OID set, and Solaris10 needs
+ * one for anything but Kerberos.  Supplying an explicit OID set
+ * doesn't appear to hurt anything in other implementations, so we
+ * always use one.  If we're not using our own SPNEGO implementation,
+ * we include SPNEGO's OID.
+ */
+#if defined(GSSAPI)
 
-#define RETERR(x) do { \
-	result = (x); \
-	if (result != ISC_R_SUCCESS) \
-		goto out; \
+static unsigned char krb5_mech_oid_bytes[] = {
+	0x2a, 0x86, 0x48, 0x86, 0xf7, 0x12, 0x01, 0x02, 0x02
+};
+
+#ifndef USE_ISC_SPNEGO
+static unsigned char spnego_mech_oid_bytes[] = {
+	0x2b, 0x06, 0x01, 0x05, 0x05, 0x02
+};
+#endif
+
+static gss_OID_desc mech_oid_set_array[] = {
+	{ sizeof(krb5_mech_oid_bytes), krb5_mech_oid_bytes },
+#ifndef USE_ISC_SPNEGO
+	{ sizeof(spnego_mech_oid_bytes), spnego_mech_oid_bytes },
+#endif
+};
+
+static gss_OID_set_desc mech_oid_set = {
+	sizeof(mech_oid_set_array) / sizeof(*mech_oid_set_array),
+	mech_oid_set_array
+};
+
+#endif
+
+#define REGION_TO_GBUFFER(r, gb) \
+	do { \
+		(gb).length = (r).length; \
+		(gb).value = (r).base; \
 	} while (0)
 
-#define REGION_TO_GBUFFER(r, gb)		\
-	do {					\
-		(gb).length = (r).length;	\
-		(gb).value = (r).base;		\
+#define GBUFFER_TO_REGION(gb, r) \
+	do { \
+		(r).length = (gb).length; \
+		(r).base = (gb).value; \
 	} while (0)
 
-#define GBUFFER_TO_REGION(gb, r)		\
-	do {					\
-		(r).length = (gb).length;	\
-		(r).base = (gb).value;		\
+
+#define RETERR(x) do { \
+	result = (x); \
+	if (result != ISC_R_SUCCESS) \
+		goto out; \
 	} while (0)
 
+#ifdef GSSAPI
 static inline void
 name_to_gbuffer(dns_name_t *name, isc_buffer_t *buffer,
 		gss_buffer_desc *gbuffer)
@@ -77,22 +121,81 @@ name_to_gbuffer(dns_name_t *name, isc_buffer_t *buffer,
 
 	if (!dns_name_isabsolute(name))
 		namep = name;
-	else {
+	else
+	{
 		unsigned int labels;
 		dns_name_init(&tname, NULL);
 		labels = dns_name_countlabels(name);
 		dns_name_getlabelsequence(name, 0, labels - 1, &tname);
 		namep = &tname;
 	}
-					
+
 	result = dns_name_totext(namep, ISC_FALSE, buffer);
 	isc_buffer_putuint8(buffer, 0);
 	isc_buffer_usedregion(buffer, &r);
 	REGION_TO_GBUFFER(r, *gbuffer);
 }
 
+static void
+log_cred(const gss_cred_id_t cred) {
+	OM_uint32 gret, minor, lifetime;
+	gss_name_t gname;
+	gss_buffer_desc gbuffer;
+	gss_cred_usage_t usage;
+	const char *usage_text;
+	char buf[1024];
+
+	gret = gss_inquire_cred(&minor, cred, &gname, &lifetime, &usage, NULL);
+	if (gret != GSS_S_COMPLETE) {
+		gss_log(3, "failed gss_inquire_cred: %s",
+			gss_error_tostring(gret, minor, buf, sizeof(buf)));
+		return;
+	}
+
+	gret = gss_display_name(&minor, gname, &gbuffer, NULL);
+	if (gret != GSS_S_COMPLETE)
+		gss_log(3, "failed gss_display_name: %s",
+			gss_error_tostring(gret, minor, buf, sizeof(buf)));
+	else {
+		switch (usage) {
+		case GSS_C_BOTH:
+			usage_text = "GSS_C_BOTH";
+			break;
+		case GSS_C_INITIATE:
+			usage_text = "GSS_C_INITIATE";
+			break;
+		case GSS_C_ACCEPT:
+			usage_text = "GSS_C_ACCEPT";
+			break;
+		default:
+			usage_text = "???";
+		}
+		gss_log(3, "gss cred: \"%s\", %s, %lu", (char *)gbuffer.value,
+			usage_text, (unsigned long)lifetime);
+	}
+
+	if (gret == GSS_S_COMPLETE) {
+		if (gbuffer.length != 0) {
+			gret = gss_release_buffer(&minor, &gbuffer);
+			if (gret != GSS_S_COMPLETE)
+				gss_log(3, "failed gss_release_buffer: %s",
+					gss_error_tostring(gret, minor, buf,
+							   sizeof(buf)));
+		}
+	}
+
+	gret = gss_release_name(&minor, &gname);
+	if (gret != GSS_S_COMPLETE)
+		gss_log(3, "failed gss_release_name: %s",
+			gss_error_tostring(gret, minor, buf, sizeof(buf)));
+}
+#endif
+
 isc_result_t
-dst_gssapi_acquirecred(dns_name_t *name, isc_boolean_t initiate, void **cred) {
+dst_gssapi_acquirecred(dns_name_t *name, isc_boolean_t initiate,
+		       gss_cred_id_t *cred)
+{
+#ifdef GSSAPI
 	isc_buffer_t namebuf;
 	gss_name_t gname;
 	gss_buffer_desc gnamebuf;
@@ -101,164 +204,535 @@ dst_gssapi_acquirecred(dns_name_t *name, isc_boolean_t initiate, void **cred) {
 	gss_OID_set mechs;
 	OM_uint32 lifetime;
 	gss_cred_usage_t usage;
+	char buf[1024];
 
 	REQUIRE(cred != NULL && *cred == NULL);
 
+	/*
+	 * XXXSRA In theory we could use GSS_C_NT_HOSTBASED_SERVICE
+	 * here when we're in the acceptor role, which would let us
+	 * default the hostname and use a compiled in default service
+	 * name of "DNS", giving one less thing to configure in
+	 * named.conf.  Unfortunately, this creates a circular
+	 * dependency due to DNS-based realm lookup in at least one
+	 * GSSAPI implementation (Heimdal).  Oh well.
+	 */
 	if (name != NULL) {
 		isc_buffer_init(&namebuf, array, sizeof(array));
 		name_to_gbuffer(name, &namebuf, &gnamebuf);
-		gret = gss_import_name(&minor, &gnamebuf, GSS_C_NO_OID,
-				       &gname);
-		if (gret != GSS_S_COMPLETE)
+		gret = gss_import_name(&minor, &gnamebuf,
+				       GSS_C_NO_OID, &gname);
+		if (gret != GSS_S_COMPLETE) {
+			gss_log(3, "failed gss_import_name: %s",
+				gss_error_tostring(gret, minor, buf,
+						   sizeof(buf)));
 			return (ISC_R_FAILURE);
+		}
 	} else
 		gname = NULL;
 
+	/* Get the credentials. */
+	if (gname != NULL)
+		gss_log(3, "acquiring credentials for %s",
+			(char *)gnamebuf.value);
+	else {
+		/* XXXDCL does this even make any sense? */
+		gss_log(3, "acquiring credentials for ?");
+	}
+
 	if (initiate)
 		usage = GSS_C_INITIATE;
 	else
 		usage = GSS_C_ACCEPT;
 
 	gret = gss_acquire_cred(&minor, gname, GSS_C_INDEFINITE,
-				GSS_C_NO_OID_SET, usage,
-				cred, &mechs, &lifetime);
-	if (gret != GSS_S_COMPLETE)
+				&mech_oid_set,
+				usage, cred, &mechs, &lifetime);
+
+	if (gret != GSS_S_COMPLETE) {
+		gss_log(3, "failed to acquire %s credentials for %s: %s",
+			initiate ? "initiate" : "accept",
+			(char *)gnamebuf.value,
+			gss_error_tostring(gret, minor, buf, sizeof(buf)));
 		return (ISC_R_FAILURE);
+	}
+
+	gss_log(4, "acquired %s credentials for %s",
+		initiate ? "initiate" : "accept",
+		(char *)gnamebuf.value);
+
+	log_cred(*cred);
+
 	return (ISC_R_SUCCESS);
+#else
+	UNUSED(name);
+	UNUSED(initiate);
+	UNUSED(cred);
+
+	return (ISC_R_NOTIMPLEMENTED);
+#endif
+}
+
+isc_boolean_t
+dst_gssapi_identitymatchesrealmkrb5(dns_name_t *signer, dns_name_t *name,
+				    dns_name_t *realm)
+{
+#ifdef GSSAPI
+	char sbuf[DNS_NAME_FORMATSIZE];
+	char nbuf[DNS_NAME_FORMATSIZE];
+	char rbuf[DNS_NAME_FORMATSIZE];
+	char *sname;
+	char *rname;
+
+	/*
+	 * It is far, far easier to write the names we are looking at into
+	 * a string, and do string operations on them.
+	 */
+	dns_name_format(signer, sbuf, sizeof(sbuf));
+	if (name != NULL)
+		dns_name_format(name, nbuf, sizeof(nbuf));
+	dns_name_format(realm, rbuf, sizeof(rbuf));
+
+	/*
+	 * Find the realm portion.  This is the part after the @.  If it
+	 * does not exist, we don't have something we like, so we fail our
+	 * compare.
+	 */
+	rname = strstr(sbuf, "\\@");
+	if (rname == NULL)
+		return (isc_boolean_false);
+	*rname = '\0';
+	rname += 2;
+
+	/*
+	 * Find the host portion of the signer's name.  We do this by
+	 * searching for the first / character.  We then check to make
+	 * certain the instance name is "host"
+	 *
+	 * This will work for
+	 *    host/example.com@EXAMPLE.COM
+	 */
+	sname = strchr(sbuf, '/');
+	if (sname == NULL)
+		return (isc_boolean_false);
+	*sname = '\0';
+	sname++;
+	if (strcmp(sbuf, "host") != 0)
+		return (isc_boolean_false);
+
+	/*
+	 * Now, we do a simple comparison between the name and the realm.
+	 */
+	if (name != NULL) {
+		if ((strcasecmp(sname, nbuf) == 0)
+		    && (strcmp(rname, rbuf) == 0))
+			return (isc_boolean_true);
+	} else {
+		if (strcmp(rname, rbuf) == 0)
+			return (isc_boolean_true);
+	}
+
+	return (isc_boolean_false);
+#else
+	UNUSED(signer);
+	UNUSED(name);
+	UNUSED(realm);
+	return (isc_boolean_false);
+#endif
+}
+
+isc_boolean_t
+dst_gssapi_identitymatchesrealmms(dns_name_t *signer, dns_name_t *name,
+				  dns_name_t *realm)
+{
+#ifdef GSSAPI
+	char sbuf[DNS_NAME_FORMATSIZE];
+	char nbuf[DNS_NAME_FORMATSIZE];
+	char rbuf[DNS_NAME_FORMATSIZE];
+	char *sname;
+	char *nname;
+	char *rname;
+
+	/*
+	 * It is far, far easier to write the names we are looking at into
+	 * a string, and do string operations on them.
+	 */
+	dns_name_format(signer, sbuf, sizeof(sbuf));
+	if (name != NULL)
+		dns_name_format(name, nbuf, sizeof(nbuf));
+	dns_name_format(realm, rbuf, sizeof(rbuf));
+
+	/*
+	 * Find the realm portion.  This is the part after the @.  If it
+	 * does not exist, we don't have something we like, so we fail our
+	 * compare.
+	 */
+	rname = strstr(sbuf, "\\@");
+	if (rname == NULL)
+		return (isc_boolean_false);
+	sname = strstr(sbuf, "\\$");
+	if (sname == NULL)
+		return (isc_boolean_false);
+
+	/*
+	 * Verify that the $ and @ follow one another.
+	 */
+	if (rname - sname != 2)
+		return (isc_boolean_false);
+
+	/*
+	 * Find the host portion of the signer's name.  Zero out the $ so
+	 * it terminates the signer's name, and skip past the @ for
+	 * the realm.
+	 *
+	 * All service principals in Microsoft format seem to be in
+	 *    machinename$@EXAMPLE.COM
+	 * format.
+	 */
+	*rname = '\0';
+	rname += 2;
+	*sname = '\0';
+	sname = sbuf;
+
+	/*
+	 * Find the first . in the target name, and make it the end of
+	 * the string.   The rest of the name has to match the realm.
+	 */
+	if (name != NULL) {
+		nname = strchr(nbuf, '.');
+		if (nname == NULL)
+			return (isc_boolean_false);
+		*nname++ = '\0';
+	}
+
+	/*
+	 * Now, we do a simple comparison between the name and the realm.
+	 */
+	if (name != NULL) {
+		if ((strcasecmp(sname, nbuf) == 0)
+		    && (strcmp(rname, rbuf) == 0)
+		    && (strcasecmp(nname, rbuf) == 0))
+			return (isc_boolean_true);
+	} else {
+		if (strcmp(rname, rbuf) == 0)
+			return (isc_boolean_true);
+	}
+
+
+	return (isc_boolean_false);
+#else
+	UNUSED(signer);
+	UNUSED(name);
+	UNUSED(realm);
+	return (isc_boolean_false);
+#endif
 }
 
 isc_result_t
-dst_gssapi_initctx(dns_name_t *name, void *cred,
-		   isc_region_t *intoken, isc_buffer_t *outtoken,
-		   void **context)
+dst_gssapi_releasecred(gss_cred_id_t *cred) {
+#ifdef GSSAPI
+	OM_uint32 gret, minor;
+	char buf[1024];
+
+	REQUIRE(cred != NULL && *cred != NULL);
+
+	gret = gss_release_cred(&minor, cred);
+	if (gret != GSS_S_COMPLETE) {
+		/* Log the error, but still free the credential's memory */
+		gss_log(3, "failed releasing credential: %s",
+			gss_error_tostring(gret, minor, buf, sizeof(buf)));
+	}
+	*cred = NULL;
+
+	return(ISC_R_SUCCESS);
+#else
+	UNUSED(cred);
+
+	return (ISC_R_NOTIMPLEMENTED);
+#endif
+}
+
+isc_result_t
+dst_gssapi_initctx(dns_name_t *name, isc_buffer_t *intoken,
+		   isc_buffer_t *outtoken, gss_ctx_id_t *gssctx)
 {
+#ifdef GSSAPI
 	isc_region_t r;
 	isc_buffer_t namebuf;
-	gss_buffer_desc gnamebuf, gintoken, *gintokenp, gouttoken;
-	OM_uint32 gret, minor, flags, ret_flags;
-	gss_OID mech_type, ret_mech_type;
-	OM_uint32 lifetime;
 	gss_name_t gname;
+	OM_uint32 gret, minor, ret_flags, flags;
+	gss_buffer_desc gintoken, *gintokenp, gouttoken = GSS_C_EMPTY_BUFFER;
 	isc_result_t result;
+	gss_buffer_desc gnamebuf;
 	unsigned char array[DNS_NAME_MAXTEXT + 1];
+	char buf[1024];
+
+	/* Client must pass us a valid gss_ctx_id_t here */
+	REQUIRE(gssctx != NULL);
 
 	isc_buffer_init(&namebuf, array, sizeof(array));
 	name_to_gbuffer(name, &namebuf, &gnamebuf);
+
+	/* Get the name as a GSS name */
 	gret = gss_import_name(&minor, &gnamebuf, GSS_C_NO_OID, &gname);
-	if (gret != GSS_S_COMPLETE)
-		return (ISC_R_FAILURE);
+	if (gret != GSS_S_COMPLETE) {
+		result = ISC_R_FAILURE;
+		goto out;
+	}
 
 	if (intoken != NULL) {
+		/* Don't call gss_release_buffer for gintoken! */
 		REGION_TO_GBUFFER(*intoken, gintoken);
 		gintokenp = &gintoken;
-	} else
+	} else {
 		gintokenp = NULL;
+	}
 
-	if (*context == NULL)
-		*context = GSS_C_NO_CONTEXT;
 	flags = GSS_C_REPLAY_FLAG | GSS_C_MUTUAL_FLAG | GSS_C_DELEG_FLAG |
-		GSS_C_SEQUENCE_FLAG | GSS_C_CONF_FLAG | GSS_C_INTEG_FLAG;
-	mech_type = GSS_C_NO_OID;
-
-	gret = gss_init_sec_context(&minor, cred, context, gname,
-				    mech_type, flags, 0,
-				    GSS_C_NO_CHANNEL_BINDINGS, gintokenp,
-				    &ret_mech_type, &gouttoken, &ret_flags,
-				    &lifetime);
-	if (gret != GSS_S_COMPLETE && gret != GSS_S_CONTINUE_NEEDED)
-		return (ISC_R_FAILURE);
+		GSS_C_SEQUENCE_FLAG | GSS_C_INTEG_FLAG;
+
+	gret = gss_init_sec_context(&minor, GSS_C_NO_CREDENTIAL, gssctx,
+				    gname, GSS_SPNEGO_MECHANISM, flags,
+				    0, NULL, gintokenp,
+				    NULL, &gouttoken, &ret_flags, NULL);
+
+	if (gret != GSS_S_COMPLETE && gret != GSS_S_CONTINUE_NEEDED) {
+		gss_log(3, "Failure initiating security context");
+		gss_log(3, "%s", gss_error_tostring(gret, minor,
+						    buf, sizeof(buf)));
+		result = ISC_R_FAILURE;
+		goto out;
+	}
 
-	GBUFFER_TO_REGION(gouttoken, r);
-	RETERR(isc_buffer_copyregion(outtoken, &r));
+	/*
+	 * XXXSRA Not handled yet: RFC 3645 3.1.1: check ret_flags
+	 * MUTUAL and INTEG flags, fail if either not set.
+	 */
+
+	/*
+	 * RFC 2744 states the a valid output token has a non-zero length.
+	 */
+	if (gouttoken.length != 0) {
+		GBUFFER_TO_REGION(gouttoken, r);
+		RETERR(isc_buffer_copyregion(outtoken, &r));
+		(void)gss_release_buffer(&minor, &gouttoken);
+	}
+	(void)gss_release_name(&minor, &gname);
 
 	if (gret == GSS_S_COMPLETE)
-		return (ISC_R_SUCCESS);
+		result = ISC_R_SUCCESS;
 	else
-		return (DNS_R_CONTINUE);
+		result = DNS_R_CONTINUE;
 
  out:
- 	return (result);
+	return (result);
+#else
+	UNUSED(name);
+	UNUSED(intoken);
+	UNUSED(outtoken);
+	UNUSED(gssctx);
+
+	return (ISC_R_NOTIMPLEMENTED);
+#endif
 }
 
 isc_result_t
-dst_gssapi_acceptctx(dns_name_t *name, void *cred,
-		     isc_region_t *intoken, isc_buffer_t *outtoken,
-		     void **context)
+dst_gssapi_acceptctx(gss_cred_id_t cred,
+		     isc_region_t *intoken, isc_buffer_t **outtoken,
+		     gss_ctx_id_t *ctxout, dns_name_t *principal,
+		     isc_mem_t *mctx)
 {
+#ifdef GSSAPI
 	isc_region_t r;
 	isc_buffer_t namebuf;
-	gss_buffer_desc gnamebuf, gintoken, gouttoken;
-	OM_uint32 gret, minor, flags;
-	gss_OID mech_type;
-	OM_uint32 lifetime;
-	gss_cred_id_t delegated_cred;
-	gss_name_t gname;
+	gss_buffer_desc gnamebuf = GSS_C_EMPTY_BUFFER, gintoken,
+			gouttoken = GSS_C_EMPTY_BUFFER;
+	OM_uint32 gret, minor;
+	gss_ctx_id_t context = GSS_C_NO_CONTEXT;
+	gss_name_t gname = NULL;
 	isc_result_t result;
-	unsigned char array[DNS_NAME_MAXTEXT + 1];
+	char buf[1024];
 
-	isc_buffer_init(&namebuf, array, sizeof(array));
-	name_to_gbuffer(name, &namebuf, &gnamebuf);
-	gret = gss_import_name(&minor, &gnamebuf, GSS_C_NO_OID, &gname);
-	if (gret != GSS_S_COMPLETE)
-		return (ISC_R_FAILURE);
+	REQUIRE(outtoken != NULL && *outtoken == NULL);
+
+	log_cred(cred);
 
 	REGION_TO_GBUFFER(*intoken, gintoken);
 
-	if (*context == NULL)
-		*context = GSS_C_NO_CONTEXT;
+	if (*ctxout == NULL)
+		context = GSS_C_NO_CONTEXT;
+	else
+		context = *ctxout;
+
+	gret = gss_accept_sec_context(&minor, &context, cred, &gintoken,
+				      GSS_C_NO_CHANNEL_BINDINGS, &gname,
+				      NULL, &gouttoken, NULL, NULL, NULL);
+
+	result = ISC_R_FAILURE;
+
+	switch (gret) {
+	case GSS_S_COMPLETE:
+		result = ISC_R_SUCCESS;
+		break;
+	case GSS_S_CONTINUE_NEEDED:
+		result = DNS_R_CONTINUE;
+		break;
+	case GSS_S_DEFECTIVE_TOKEN:
+	case GSS_S_DEFECTIVE_CREDENTIAL:
+	case GSS_S_BAD_SIG:
+	case GSS_S_DUPLICATE_TOKEN:
+	case GSS_S_OLD_TOKEN:
+	case GSS_S_NO_CRED:
+	case GSS_S_CREDENTIALS_EXPIRED:
+	case GSS_S_BAD_BINDINGS:
+	case GSS_S_NO_CONTEXT:
+	case GSS_S_BAD_MECH:
+	case GSS_S_FAILURE:
+		result = DNS_R_INVALIDTKEY;
+		/* fall through */
+	default:
+		gss_log(3, "failed gss_accept_sec_context: %s",
+			gss_error_tostring(gret, minor, buf, sizeof(buf)));
+		return (result);
+	}
 
-	gret = gss_accept_sec_context(&minor, context, cred, &gintoken,
-				      GSS_C_NO_CHANNEL_BINDINGS, gname,
-				      &mech_type, &gouttoken, &flags,
-				      &lifetime, &delegated_cred);
-	if (gret != GSS_S_COMPLETE)
-		return (ISC_R_FAILURE);
+	if (gouttoken.length > 0) {
+		RETERR(isc_buffer_allocate(mctx, outtoken, gouttoken.length));
+		GBUFFER_TO_REGION(gouttoken, r);
+		RETERR(isc_buffer_copyregion(*outtoken, &r));
+		(void)gss_release_buffer(&minor, &gouttoken);
+	}
 
-	GBUFFER_TO_REGION(gouttoken, r);
-	RETERR(isc_buffer_copyregion(outtoken, &r));
+	if (gret == GSS_S_COMPLETE) {
+		gret = gss_display_name(&minor, gname, &gnamebuf, NULL);
+		if (gret != GSS_S_COMPLETE) {
+			gss_log(3, "failed gss_display_name: %s",
+				gss_error_tostring(gret, minor,
+						   buf, sizeof(buf)));
+			RETERR(ISC_R_FAILURE);
+		}
+
+		/*
+		 * Compensate for a bug in Solaris8's implementation
+		 * of gss_display_name().  Should be harmless in any
+		 * case, since principal names really should not
+		 * contain null characters.
+		 */
+		if (gnamebuf.length > 0 &&
+		    ((char *)gnamebuf.value)[gnamebuf.length - 1] == '\0')
+			gnamebuf.length--;
+
+		gss_log(3, "gss-api source name (accept) is %.*s",
+			(int)gnamebuf.length, (char *)gnamebuf.value);
+
+		GBUFFER_TO_REGION(gnamebuf, r);
+		isc_buffer_init(&namebuf, r.base, r.length);
+		isc_buffer_add(&namebuf, r.length);
+
+		RETERR(dns_name_fromtext(principal, &namebuf, dns_rootname,
+					 ISC_FALSE, NULL));
+
+		if (gnamebuf.length != 0) {
+			gret = gss_release_buffer(&minor, &gnamebuf);
+			if (gret != GSS_S_COMPLETE)
+				gss_log(3, "failed gss_release_buffer: %s",
+					gss_error_tostring(gret, minor, buf,
+							   sizeof(buf)));
+		}
+	}
 
-	return (ISC_R_SUCCESS);
+	*ctxout = context;
 
  out:
-	return (result);
-}
+	if (gname != NULL) {
+		gret = gss_release_name(&minor, &gname);
+		if (gret != GSS_S_COMPLETE)
+			gss_log(3, "failed gss_release_name: %s",
+				gss_error_tostring(gret, minor, buf,
+						   sizeof(buf)));
+	}
 
+	return (result);
 #else
-
-isc_result_t
-dst_gssapi_acquirecred(dns_name_t *name, isc_boolean_t initiate, void **cred) {
-	UNUSED(name);
-	UNUSED(initiate);
-	UNUSED(cred);
-	return (ISC_R_NOTIMPLEMENTED);
-}
-
-isc_result_t
-dst_gssapi_initctx(dns_name_t *name, void *cred,
-		   isc_region_t *intoken, isc_buffer_t *outtoken,
-		   void **context)
-{
-	UNUSED(name);
 	UNUSED(cred);
 	UNUSED(intoken);
 	UNUSED(outtoken);
-	UNUSED(context);
+	UNUSED(ctxout);
+	UNUSED(principal);
+	UNUSED(mctx);
+
 	return (ISC_R_NOTIMPLEMENTED);
+#endif
 }
 
 isc_result_t
-dst_gssapi_acceptctx(dns_name_t *name, void *cred,
-		     isc_region_t *intoken, isc_buffer_t *outtoken,
-		     void **context)
+dst_gssapi_deletectx(isc_mem_t *mctx, gss_ctx_id_t *gssctx)
 {
-	UNUSED(name);
-	UNUSED(cred);
-	UNUSED(intoken);
-	UNUSED(outtoken);
-	UNUSED(context);
+#ifdef GSSAPI
+	OM_uint32 gret, minor;
+	char buf[1024];
+
+	UNUSED(mctx);
+
+	REQUIRE(gssctx != NULL && *gssctx != NULL);
+
+	/* Delete the context from the GSS provider */
+	gret = gss_delete_sec_context(&minor, gssctx, GSS_C_NO_BUFFER);
+	if (gret != GSS_S_COMPLETE) {
+		/* Log the error, but still free the context's memory */
+		gss_log(3, "Failure deleting security context %s",
+			gss_error_tostring(gret, minor, buf, sizeof(buf)));
+	}
+	return(ISC_R_SUCCESS);
+#else
+	UNUSED(mctx);
+	UNUSED(gssctx);
 	return (ISC_R_NOTIMPLEMENTED);
+#endif
 }
 
+char *
+gss_error_tostring(isc_uint32_t major, isc_uint32_t minor,
+		   char *buf, size_t buflen) {
+#ifdef GSSAPI
+	gss_buffer_desc msg_minor = GSS_C_EMPTY_BUFFER,
+			msg_major = GSS_C_EMPTY_BUFFER;
+	OM_uint32 msg_ctx, minor_stat;
+
+	/* Handle major status */
+	msg_ctx = 0;
+	(void)gss_display_status(&minor_stat, major, GSS_C_GSS_CODE,
+				 GSS_C_NULL_OID, &msg_ctx, &msg_major);
+
+	/* Handle minor status */
+	msg_ctx = 0;
+	(void)gss_display_status(&minor_stat, minor, GSS_C_MECH_CODE,
+				 GSS_C_NULL_OID, &msg_ctx, &msg_minor);
+
+	snprintf(buf, buflen, "GSSAPI error: Major = %s, Minor = %s.",
+		(char *)msg_major.value, (char *)msg_minor.value);
+
+	if (msg_major.length != 0)
+		(void)gss_release_buffer(&minor_stat, &msg_major);
+	if (msg_minor.length != 0)
+		(void)gss_release_buffer(&minor_stat, &msg_minor);
+	return(buf);
+#else
+	snprintf(buf, buflen, "GSSAPI error: Major = %u, Minor = %u.",
+		 major, minor);
+
+	return (buf);
 #endif
+}
+
+void
+gss_log(int level, const char *fmt, ...) {
+	va_list ap;
+
+	va_start(ap, fmt);
+	isc_log_vwrite(dns_lctx, DNS_LOGCATEGORY_GENERAL,
+		       DNS_LOGMODULE_TKEY, ISC_LOG_DEBUG(level), fmt, ap);
+	va_end(ap);
+}
 
 /*! \file */
diff --git a/contrib/bind9/lib/dns/hmac_link.c b/contrib/bind9/lib/dns/hmac_link.c
index 9655c89..fce98d7 100644
--- a/contrib/bind9/lib/dns/hmac_link.c
+++ b/contrib/bind9/lib/dns/hmac_link.c
@@ -1,9 +1,22 @@
 /*
- * Portions Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 1999-2002  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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.
+ *
  * Portions Copyright (C) 1995-2000 by Network Associates, Inc.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,7 +31,7 @@
 
 /*
  * Principal Author: Brian Wellington
- * $Id: hmac_link.c,v 1.1.6.5 2006/01/27 23:57:44 marka Exp $
+ * $Id: hmac_link.c,v 1.11 2008/04/01 23:47:10 tbox Exp $
  */
 
 #include <config.h>
@@ -43,9 +56,9 @@
 
 static isc_result_t hmacmd5_fromdns(dst_key_t *key, isc_buffer_t *data);
 
-typedef struct hmackey {
+struct dst_hmacmd5_key {
 	unsigned char key[HMAC_LEN];
-} HMAC_Key;
+};
 
 static isc_result_t
 getkeybits(dst_key_t *key, struct dst_private_element *element) {
@@ -61,30 +74,30 @@ getkeybits(dst_key_t *key, struct dst_private_element *element) {
 static isc_result_t
 hmacmd5_createctx(dst_key_t *key, dst_context_t *dctx) {
 	isc_hmacmd5_t *hmacmd5ctx;
-	HMAC_Key *hkey = key->opaque;
+	dst_hmacmd5_key_t *hkey = key->keydata.hmacmd5;
 
 	hmacmd5ctx = isc_mem_get(dctx->mctx, sizeof(isc_hmacmd5_t));
 	if (hmacmd5ctx == NULL)
 		return (ISC_R_NOMEMORY);
 	isc_hmacmd5_init(hmacmd5ctx, hkey->key, HMAC_LEN);
-	dctx->opaque = hmacmd5ctx;
+	dctx->ctxdata.hmacmd5ctx = hmacmd5ctx;
 	return (ISC_R_SUCCESS);
 }
 
 static void
 hmacmd5_destroyctx(dst_context_t *dctx) {
-	isc_hmacmd5_t *hmacmd5ctx = dctx->opaque;
+	isc_hmacmd5_t *hmacmd5ctx = dctx->ctxdata.hmacmd5ctx;
 
 	if (hmacmd5ctx != NULL) {
 		isc_hmacmd5_invalidate(hmacmd5ctx);
 		isc_mem_put(dctx->mctx, hmacmd5ctx, sizeof(isc_hmacmd5_t));
-		dctx->opaque = NULL;
+		dctx->ctxdata.hmacmd5ctx = NULL;
 	}
 }
 
 static isc_result_t
 hmacmd5_adddata(dst_context_t *dctx, const isc_region_t *data) {
-	isc_hmacmd5_t *hmacmd5ctx = dctx->opaque;
+	isc_hmacmd5_t *hmacmd5ctx = dctx->ctxdata.hmacmd5ctx;
 
 	isc_hmacmd5_update(hmacmd5ctx, data->base, data->length);
 	return (ISC_R_SUCCESS);
@@ -92,7 +105,7 @@ hmacmd5_adddata(dst_context_t *dctx, const isc_region_t *data) {
 
 static isc_result_t
 hmacmd5_sign(dst_context_t *dctx, isc_buffer_t *sig) {
-	isc_hmacmd5_t *hmacmd5ctx = dctx->opaque;
+	isc_hmacmd5_t *hmacmd5ctx = dctx->ctxdata.hmacmd5ctx;
 	unsigned char *digest;
 
 	if (isc_buffer_availablelength(sig) < ISC_MD5_DIGESTLENGTH)
@@ -106,7 +119,7 @@ hmacmd5_sign(dst_context_t *dctx, isc_buffer_t *sig) {
 
 static isc_result_t
 hmacmd5_verify(dst_context_t *dctx, const isc_region_t *sig) {
-	isc_hmacmd5_t *hmacmd5ctx = dctx->opaque;
+	isc_hmacmd5_t *hmacmd5ctx = dctx->ctxdata.hmacmd5ctx;
 
 	if (sig->length > ISC_MD5_DIGESTLENGTH)
 		return (DST_R_VERIFYFAILURE);
@@ -119,10 +132,10 @@ hmacmd5_verify(dst_context_t *dctx, const isc_region_t *sig) {
 
 static isc_boolean_t
 hmacmd5_compare(const dst_key_t *key1, const dst_key_t *key2) {
-	HMAC_Key *hkey1, *hkey2;
+	dst_hmacmd5_key_t *hkey1, *hkey2;
 
-	hkey1 = (HMAC_Key *)key1->opaque;
-	hkey2 = (HMAC_Key *)key2->opaque;
+	hkey1 = key1->keydata.hmacmd5;
+	hkey2 = key2->keydata.hmacmd5;
 
 	if (hkey1 == NULL && hkey2 == NULL)
 		return (ISC_TRUE);
@@ -170,20 +183,20 @@ hmacmd5_isprivate(const dst_key_t *key) {
 
 static void
 hmacmd5_destroy(dst_key_t *key) {
-	HMAC_Key *hkey = key->opaque;
-	memset(hkey, 0, sizeof(HMAC_Key));
-	isc_mem_put(key->mctx, hkey, sizeof(HMAC_Key));
-	key->opaque = NULL;
+	dst_hmacmd5_key_t *hkey = key->keydata.hmacmd5;
+	memset(hkey, 0, sizeof(dst_hmacmd5_key_t));
+	isc_mem_put(key->mctx, hkey, sizeof(dst_hmacmd5_key_t));
+	key->keydata.hmacmd5 = NULL;
 }
 
 static isc_result_t
 hmacmd5_todns(const dst_key_t *key, isc_buffer_t *data) {
-	HMAC_Key *hkey;
+	dst_hmacmd5_key_t *hkey;
 	unsigned int bytes;
 
-	REQUIRE(key->opaque != NULL);
+	REQUIRE(key->keydata.hmacmd5 != NULL);
 
-	hkey = (HMAC_Key *) key->opaque;
+	hkey = key->keydata.hmacmd5;
 
 	bytes = (key->key_size + 7) / 8;
 	if (isc_buffer_availablelength(data) < bytes)
@@ -195,7 +208,7 @@ hmacmd5_todns(const dst_key_t *key, isc_buffer_t *data) {
 
 static isc_result_t
 hmacmd5_fromdns(dst_key_t *key, isc_buffer_t *data) {
-	HMAC_Key *hkey;
+	dst_hmacmd5_key_t *hkey;
 	int keylen;
 	isc_region_t r;
 	isc_md5_t md5ctx;
@@ -204,7 +217,7 @@ hmacmd5_fromdns(dst_key_t *key, isc_buffer_t *data) {
 	if (r.length == 0)
 		return (ISC_R_SUCCESS);
 
-	hkey = (HMAC_Key *) isc_mem_get(key->mctx, sizeof(HMAC_Key));
+	hkey = isc_mem_get(key->mctx, sizeof(dst_hmacmd5_key_t));
 	if (hkey == NULL)
 		return (ISC_R_NOMEMORY);
 
@@ -222,7 +235,7 @@ hmacmd5_fromdns(dst_key_t *key, isc_buffer_t *data) {
 	}
 
 	key->key_size = keylen * 8;
-	key->opaque = hkey;
+	key->keydata.hmacmd5 = hkey;
 
 	return (ISC_R_SUCCESS);
 }
@@ -230,15 +243,15 @@ hmacmd5_fromdns(dst_key_t *key, isc_buffer_t *data) {
 static isc_result_t
 hmacmd5_tofile(const dst_key_t *key, const char *directory) {
 	int cnt = 0;
-	HMAC_Key *hkey;
+	dst_hmacmd5_key_t *hkey;
 	dst_private_t priv;
 	int bytes = (key->key_size + 7) / 8;
 	unsigned char buf[2];
 
-	if (key->opaque == NULL)
+	if (key->keydata.hmacmd5 == NULL)
 		return (DST_R_NULLKEY);
 
-	hkey = (HMAC_Key *) key->opaque;
+	hkey = key->keydata.hmacmd5;
 
 	priv.elements[cnt].tag = TAG_HMACMD5_KEY;
 	priv.elements[cnt].length = bytes;
@@ -272,7 +285,7 @@ hmacmd5_parse(dst_key_t *key, isc_lex_t *lexer) {
 		switch (priv.elements[i].tag) {
 		case TAG_HMACMD5_KEY:
 			isc_buffer_init(&b, priv.elements[i].data,
-				        priv.elements[i].length);
+					priv.elements[i].length);
 			isc_buffer_add(&b, priv.elements[i].length);
 			tresult = hmacmd5_fromdns(key, &b);
 			if (tresult != ISC_R_SUCCESS)
@@ -310,6 +323,7 @@ static dst_func_t hmacmd5_functions = {
 	hmacmd5_tofile,
 	hmacmd5_parse,
 	NULL, /*%< cleanup */
+	NULL, /*%< fromlabel */
 };
 
 isc_result_t
@@ -322,37 +336,37 @@ dst__hmacmd5_init(dst_func_t **funcp) {
 
 static isc_result_t hmacsha1_fromdns(dst_key_t *key, isc_buffer_t *data);
 
-typedef struct {
+struct dst_hmacsha1_key {
 	unsigned char key[ISC_SHA1_DIGESTLENGTH];
-} HMACSHA1_Key;
+};
 
 static isc_result_t
 hmacsha1_createctx(dst_key_t *key, dst_context_t *dctx) {
 	isc_hmacsha1_t *hmacsha1ctx;
-	HMACSHA1_Key *hkey = key->opaque;
+	dst_hmacsha1_key_t *hkey = key->keydata.hmacsha1;
 
 	hmacsha1ctx = isc_mem_get(dctx->mctx, sizeof(isc_hmacsha1_t));
 	if (hmacsha1ctx == NULL)
 		return (ISC_R_NOMEMORY);
 	isc_hmacsha1_init(hmacsha1ctx, hkey->key, ISC_SHA1_DIGESTLENGTH);
-	dctx->opaque = hmacsha1ctx;
+	dctx->ctxdata.hmacsha1ctx = hmacsha1ctx;
 	return (ISC_R_SUCCESS);
 }
 
 static void
 hmacsha1_destroyctx(dst_context_t *dctx) {
-	isc_hmacsha1_t *hmacsha1ctx = dctx->opaque;
+	isc_hmacsha1_t *hmacsha1ctx = dctx->ctxdata.hmacsha1ctx;
 
 	if (hmacsha1ctx != NULL) {
 		isc_hmacsha1_invalidate(hmacsha1ctx);
 		isc_mem_put(dctx->mctx, hmacsha1ctx, sizeof(isc_hmacsha1_t));
-		dctx->opaque = NULL;
+		dctx->ctxdata.hmacsha1ctx = NULL;
 	}
 }
 
 static isc_result_t
 hmacsha1_adddata(dst_context_t *dctx, const isc_region_t *data) {
-	isc_hmacsha1_t *hmacsha1ctx = dctx->opaque;
+	isc_hmacsha1_t *hmacsha1ctx = dctx->ctxdata.hmacsha1ctx;
 
 	isc_hmacsha1_update(hmacsha1ctx, data->base, data->length);
 	return (ISC_R_SUCCESS);
@@ -360,7 +374,7 @@ hmacsha1_adddata(dst_context_t *dctx, const isc_region_t *data) {
 
 static isc_result_t
 hmacsha1_sign(dst_context_t *dctx, isc_buffer_t *sig) {
-	isc_hmacsha1_t *hmacsha1ctx = dctx->opaque;
+	isc_hmacsha1_t *hmacsha1ctx = dctx->ctxdata.hmacsha1ctx;
 	unsigned char *digest;
 
 	if (isc_buffer_availablelength(sig) < ISC_SHA1_DIGESTLENGTH)
@@ -374,7 +388,7 @@ hmacsha1_sign(dst_context_t *dctx, isc_buffer_t *sig) {
 
 static isc_result_t
 hmacsha1_verify(dst_context_t *dctx, const isc_region_t *sig) {
-	isc_hmacsha1_t *hmacsha1ctx = dctx->opaque;
+	isc_hmacsha1_t *hmacsha1ctx = dctx->ctxdata.hmacsha1ctx;
 
 	if (sig->length > ISC_SHA1_DIGESTLENGTH || sig->length == 0)
 		return (DST_R_VERIFYFAILURE);
@@ -387,10 +401,10 @@ hmacsha1_verify(dst_context_t *dctx, const isc_region_t *sig) {
 
 static isc_boolean_t
 hmacsha1_compare(const dst_key_t *key1, const dst_key_t *key2) {
-	HMACSHA1_Key *hkey1, *hkey2;
+	dst_hmacsha1_key_t *hkey1, *hkey2;
 
-	hkey1 = (HMACSHA1_Key *)key1->opaque;
-	hkey2 = (HMACSHA1_Key *)key2->opaque;
+	hkey1 = key1->keydata.hmacsha1;
+	hkey2 = key2->keydata.hmacsha1;
 
 	if (hkey1 == NULL && hkey2 == NULL)
 		return (ISC_TRUE);
@@ -438,20 +452,20 @@ hmacsha1_isprivate(const dst_key_t *key) {
 
 static void
 hmacsha1_destroy(dst_key_t *key) {
-	HMACSHA1_Key *hkey = key->opaque;
-	memset(hkey, 0, sizeof(HMACSHA1_Key));
-	isc_mem_put(key->mctx, hkey, sizeof(HMACSHA1_Key));
-	key->opaque = NULL;
+	dst_hmacsha1_key_t *hkey = key->keydata.hmacsha1;
+	memset(hkey, 0, sizeof(dst_hmacsha1_key_t));
+	isc_mem_put(key->mctx, hkey, sizeof(dst_hmacsha1_key_t));
+	key->keydata.hmacsha1 = NULL;
 }
 
 static isc_result_t
 hmacsha1_todns(const dst_key_t *key, isc_buffer_t *data) {
-	HMACSHA1_Key *hkey;
+	dst_hmacsha1_key_t *hkey;
 	unsigned int bytes;
 
-	REQUIRE(key->opaque != NULL);
+	REQUIRE(key->keydata.hmacsha1 != NULL);
 
-	hkey = (HMACSHA1_Key *) key->opaque;
+	hkey = key->keydata.hmacsha1;
 
 	bytes = (key->key_size + 7) / 8;
 	if (isc_buffer_availablelength(data) < bytes)
@@ -463,7 +477,7 @@ hmacsha1_todns(const dst_key_t *key, isc_buffer_t *data) {
 
 static isc_result_t
 hmacsha1_fromdns(dst_key_t *key, isc_buffer_t *data) {
-	HMACSHA1_Key *hkey;
+	dst_hmacsha1_key_t *hkey;
 	int keylen;
 	isc_region_t r;
 	isc_sha1_t sha1ctx;
@@ -472,7 +486,7 @@ hmacsha1_fromdns(dst_key_t *key, isc_buffer_t *data) {
 	if (r.length == 0)
 		return (ISC_R_SUCCESS);
 
-	hkey = (HMACSHA1_Key *) isc_mem_get(key->mctx, sizeof(HMACSHA1_Key));
+	hkey = isc_mem_get(key->mctx, sizeof(dst_hmacsha1_key_t));
 	if (hkey == NULL)
 		return (ISC_R_NOMEMORY);
 
@@ -490,7 +504,7 @@ hmacsha1_fromdns(dst_key_t *key, isc_buffer_t *data) {
 	}
 
 	key->key_size = keylen * 8;
-	key->opaque = hkey;
+	key->keydata.hmacsha1 = hkey;
 
 	return (ISC_R_SUCCESS);
 }
@@ -498,15 +512,15 @@ hmacsha1_fromdns(dst_key_t *key, isc_buffer_t *data) {
 static isc_result_t
 hmacsha1_tofile(const dst_key_t *key, const char *directory) {
 	int cnt = 0;
-	HMACSHA1_Key *hkey;
+	dst_hmacsha1_key_t *hkey;
 	dst_private_t priv;
 	int bytes = (key->key_size + 7) / 8;
 	unsigned char buf[2];
 
-	if (key->opaque == NULL)
+	if (key->keydata.hmacsha1 == NULL)
 		return (DST_R_NULLKEY);
 
-	hkey = (HMACSHA1_Key *) key->opaque;
+	hkey = key->keydata.hmacsha1;
 
 	priv.elements[cnt].tag = TAG_HMACSHA1_KEY;
 	priv.elements[cnt].length = bytes;
@@ -541,7 +555,7 @@ hmacsha1_parse(dst_key_t *key, isc_lex_t *lexer) {
 		switch (priv.elements[i].tag) {
 		case TAG_HMACSHA1_KEY:
 			isc_buffer_init(&b, priv.elements[i].data,
-				        priv.elements[i].length);
+					priv.elements[i].length);
 			isc_buffer_add(&b, priv.elements[i].length);
 			tresult = hmacsha1_fromdns(key, &b);
 			if (tresult != ISC_R_SUCCESS)
@@ -579,6 +593,7 @@ static dst_func_t hmacsha1_functions = {
 	hmacsha1_tofile,
 	hmacsha1_parse,
 	NULL, /* cleanup */
+	NULL, /* fromlabel */
 };
 
 isc_result_t
@@ -591,37 +606,37 @@ dst__hmacsha1_init(dst_func_t **funcp) {
 
 static isc_result_t hmacsha224_fromdns(dst_key_t *key, isc_buffer_t *data);
 
-typedef struct {
+struct dst_hmacsha224_key {
 	unsigned char key[ISC_SHA224_DIGESTLENGTH];
-} HMACSHA224_Key;
+};
 
 static isc_result_t
 hmacsha224_createctx(dst_key_t *key, dst_context_t *dctx) {
 	isc_hmacsha224_t *hmacsha224ctx;
-	HMACSHA224_Key *hkey = key->opaque;
+	dst_hmacsha224_key_t *hkey = key->keydata.hmacsha224;
 
 	hmacsha224ctx = isc_mem_get(dctx->mctx, sizeof(isc_hmacsha224_t));
 	if (hmacsha224ctx == NULL)
 		return (ISC_R_NOMEMORY);
 	isc_hmacsha224_init(hmacsha224ctx, hkey->key, ISC_SHA224_DIGESTLENGTH);
-	dctx->opaque = hmacsha224ctx;
+	dctx->ctxdata.hmacsha224ctx = hmacsha224ctx;
 	return (ISC_R_SUCCESS);
 }
 
 static void
 hmacsha224_destroyctx(dst_context_t *dctx) {
-	isc_hmacsha224_t *hmacsha224ctx = dctx->opaque;
+	isc_hmacsha224_t *hmacsha224ctx = dctx->ctxdata.hmacsha224ctx;
 
 	if (hmacsha224ctx != NULL) {
 		isc_hmacsha224_invalidate(hmacsha224ctx);
 		isc_mem_put(dctx->mctx, hmacsha224ctx, sizeof(isc_hmacsha224_t));
-		dctx->opaque = NULL;
+		dctx->ctxdata.hmacsha224ctx = NULL;
 	}
 }
 
 static isc_result_t
 hmacsha224_adddata(dst_context_t *dctx, const isc_region_t *data) {
-	isc_hmacsha224_t *hmacsha224ctx = dctx->opaque;
+	isc_hmacsha224_t *hmacsha224ctx = dctx->ctxdata.hmacsha224ctx;
 
 	isc_hmacsha224_update(hmacsha224ctx, data->base, data->length);
 	return (ISC_R_SUCCESS);
@@ -629,7 +644,7 @@ hmacsha224_adddata(dst_context_t *dctx, const isc_region_t *data) {
 
 static isc_result_t
 hmacsha224_sign(dst_context_t *dctx, isc_buffer_t *sig) {
-	isc_hmacsha224_t *hmacsha224ctx = dctx->opaque;
+	isc_hmacsha224_t *hmacsha224ctx = dctx->ctxdata.hmacsha224ctx;
 	unsigned char *digest;
 
 	if (isc_buffer_availablelength(sig) < ISC_SHA224_DIGESTLENGTH)
@@ -643,7 +658,7 @@ hmacsha224_sign(dst_context_t *dctx, isc_buffer_t *sig) {
 
 static isc_result_t
 hmacsha224_verify(dst_context_t *dctx, const isc_region_t *sig) {
-	isc_hmacsha224_t *hmacsha224ctx = dctx->opaque;
+	isc_hmacsha224_t *hmacsha224ctx = dctx->ctxdata.hmacsha224ctx;
 
 	if (sig->length > ISC_SHA224_DIGESTLENGTH || sig->length == 0)
 		return (DST_R_VERIFYFAILURE);
@@ -656,10 +671,10 @@ hmacsha224_verify(dst_context_t *dctx, const isc_region_t *sig) {
 
 static isc_boolean_t
 hmacsha224_compare(const dst_key_t *key1, const dst_key_t *key2) {
-	HMACSHA224_Key *hkey1, *hkey2;
+	dst_hmacsha224_key_t *hkey1, *hkey2;
 
-	hkey1 = (HMACSHA224_Key *)key1->opaque;
-	hkey2 = (HMACSHA224_Key *)key2->opaque;
+	hkey1 = key1->keydata.hmacsha224;
+	hkey2 = key2->keydata.hmacsha224;
 
 	if (hkey1 == NULL && hkey2 == NULL)
 		return (ISC_TRUE);
@@ -707,20 +722,20 @@ hmacsha224_isprivate(const dst_key_t *key) {
 
 static void
 hmacsha224_destroy(dst_key_t *key) {
-	HMACSHA224_Key *hkey = key->opaque;
-	memset(hkey, 0, sizeof(HMACSHA224_Key));
-	isc_mem_put(key->mctx, hkey, sizeof(HMACSHA224_Key));
-	key->opaque = NULL;
+	dst_hmacsha224_key_t *hkey = key->keydata.hmacsha224;
+	memset(hkey, 0, sizeof(dst_hmacsha224_key_t));
+	isc_mem_put(key->mctx, hkey, sizeof(dst_hmacsha224_key_t));
+	key->keydata.hmacsha224 = NULL;
 }
 
 static isc_result_t
 hmacsha224_todns(const dst_key_t *key, isc_buffer_t *data) {
-	HMACSHA224_Key *hkey;
+	dst_hmacsha224_key_t *hkey;
 	unsigned int bytes;
 
-	REQUIRE(key->opaque != NULL);
+	REQUIRE(key->keydata.hmacsha224 != NULL);
 
-	hkey = (HMACSHA224_Key *) key->opaque;
+	hkey = key->keydata.hmacsha224;
 
 	bytes = (key->key_size + 7) / 8;
 	if (isc_buffer_availablelength(data) < bytes)
@@ -732,7 +747,7 @@ hmacsha224_todns(const dst_key_t *key, isc_buffer_t *data) {
 
 static isc_result_t
 hmacsha224_fromdns(dst_key_t *key, isc_buffer_t *data) {
-	HMACSHA224_Key *hkey;
+	dst_hmacsha224_key_t *hkey;
 	int keylen;
 	isc_region_t r;
 	isc_sha224_t sha224ctx;
@@ -741,7 +756,7 @@ hmacsha224_fromdns(dst_key_t *key, isc_buffer_t *data) {
 	if (r.length == 0)
 		return (ISC_R_SUCCESS);
 
-	hkey = (HMACSHA224_Key *) isc_mem_get(key->mctx, sizeof(HMACSHA224_Key));
+	hkey = isc_mem_get(key->mctx, sizeof(dst_hmacsha224_key_t));
 	if (hkey == NULL)
 		return (ISC_R_NOMEMORY);
 
@@ -759,7 +774,7 @@ hmacsha224_fromdns(dst_key_t *key, isc_buffer_t *data) {
 	}
 
 	key->key_size = keylen * 8;
-	key->opaque = hkey;
+	key->keydata.hmacsha224 = hkey;
 
 	return (ISC_R_SUCCESS);
 }
@@ -767,15 +782,15 @@ hmacsha224_fromdns(dst_key_t *key, isc_buffer_t *data) {
 static isc_result_t
 hmacsha224_tofile(const dst_key_t *key, const char *directory) {
 	int cnt = 0;
-	HMACSHA224_Key *hkey;
+	dst_hmacsha224_key_t *hkey;
 	dst_private_t priv;
 	int bytes = (key->key_size + 7) / 8;
 	unsigned char buf[2];
 
-	if (key->opaque == NULL)
+	if (key->keydata.hmacsha224 == NULL)
 		return (DST_R_NULLKEY);
 
-	hkey = (HMACSHA224_Key *) key->opaque;
+	hkey = key->keydata.hmacsha224;
 
 	priv.elements[cnt].tag = TAG_HMACSHA224_KEY;
 	priv.elements[cnt].length = bytes;
@@ -810,7 +825,7 @@ hmacsha224_parse(dst_key_t *key, isc_lex_t *lexer) {
 		switch (priv.elements[i].tag) {
 		case TAG_HMACSHA224_KEY:
 			isc_buffer_init(&b, priv.elements[i].data,
-				        priv.elements[i].length);
+					priv.elements[i].length);
 			isc_buffer_add(&b, priv.elements[i].length);
 			tresult = hmacsha224_fromdns(key, &b);
 			if (tresult != ISC_R_SUCCESS)
@@ -848,6 +863,7 @@ static dst_func_t hmacsha224_functions = {
 	hmacsha224_tofile,
 	hmacsha224_parse,
 	NULL, /* cleanup */
+	NULL, /* fromlabel */
 };
 
 isc_result_t
@@ -860,37 +876,37 @@ dst__hmacsha224_init(dst_func_t **funcp) {
 
 static isc_result_t hmacsha256_fromdns(dst_key_t *key, isc_buffer_t *data);
 
-typedef struct {
+struct dst_hmacsha256_key {
 	unsigned char key[ISC_SHA256_DIGESTLENGTH];
-} HMACSHA256_Key;
+};
 
 static isc_result_t
 hmacsha256_createctx(dst_key_t *key, dst_context_t *dctx) {
 	isc_hmacsha256_t *hmacsha256ctx;
-	HMACSHA256_Key *hkey = key->opaque;
+	dst_hmacsha256_key_t *hkey = key->keydata.hmacsha256;
 
 	hmacsha256ctx = isc_mem_get(dctx->mctx, sizeof(isc_hmacsha256_t));
 	if (hmacsha256ctx == NULL)
 		return (ISC_R_NOMEMORY);
 	isc_hmacsha256_init(hmacsha256ctx, hkey->key, ISC_SHA256_DIGESTLENGTH);
-	dctx->opaque = hmacsha256ctx;
+	dctx->ctxdata.hmacsha256ctx = hmacsha256ctx;
 	return (ISC_R_SUCCESS);
 }
 
 static void
 hmacsha256_destroyctx(dst_context_t *dctx) {
-	isc_hmacsha256_t *hmacsha256ctx = dctx->opaque;
+	isc_hmacsha256_t *hmacsha256ctx = dctx->ctxdata.hmacsha256ctx;
 
 	if (hmacsha256ctx != NULL) {
 		isc_hmacsha256_invalidate(hmacsha256ctx);
 		isc_mem_put(dctx->mctx, hmacsha256ctx, sizeof(isc_hmacsha256_t));
-		dctx->opaque = NULL;
+		dctx->ctxdata.hmacsha256ctx = NULL;
 	}
 }
 
 static isc_result_t
 hmacsha256_adddata(dst_context_t *dctx, const isc_region_t *data) {
-	isc_hmacsha256_t *hmacsha256ctx = dctx->opaque;
+	isc_hmacsha256_t *hmacsha256ctx = dctx->ctxdata.hmacsha256ctx;
 
 	isc_hmacsha256_update(hmacsha256ctx, data->base, data->length);
 	return (ISC_R_SUCCESS);
@@ -898,7 +914,7 @@ hmacsha256_adddata(dst_context_t *dctx, const isc_region_t *data) {
 
 static isc_result_t
 hmacsha256_sign(dst_context_t *dctx, isc_buffer_t *sig) {
-	isc_hmacsha256_t *hmacsha256ctx = dctx->opaque;
+	isc_hmacsha256_t *hmacsha256ctx = dctx->ctxdata.hmacsha256ctx;
 	unsigned char *digest;
 
 	if (isc_buffer_availablelength(sig) < ISC_SHA256_DIGESTLENGTH)
@@ -912,7 +928,7 @@ hmacsha256_sign(dst_context_t *dctx, isc_buffer_t *sig) {
 
 static isc_result_t
 hmacsha256_verify(dst_context_t *dctx, const isc_region_t *sig) {
-	isc_hmacsha256_t *hmacsha256ctx = dctx->opaque;
+	isc_hmacsha256_t *hmacsha256ctx = dctx->ctxdata.hmacsha256ctx;
 
 	if (sig->length > ISC_SHA256_DIGESTLENGTH || sig->length == 0)
 		return (DST_R_VERIFYFAILURE);
@@ -925,10 +941,10 @@ hmacsha256_verify(dst_context_t *dctx, const isc_region_t *sig) {
 
 static isc_boolean_t
 hmacsha256_compare(const dst_key_t *key1, const dst_key_t *key2) {
-	HMACSHA256_Key *hkey1, *hkey2;
+	dst_hmacsha256_key_t *hkey1, *hkey2;
 
-	hkey1 = (HMACSHA256_Key *)key1->opaque;
-	hkey2 = (HMACSHA256_Key *)key2->opaque;
+	hkey1 = key1->keydata.hmacsha256;
+	hkey2 = key2->keydata.hmacsha256;
 
 	if (hkey1 == NULL && hkey2 == NULL)
 		return (ISC_TRUE);
@@ -976,20 +992,20 @@ hmacsha256_isprivate(const dst_key_t *key) {
 
 static void
 hmacsha256_destroy(dst_key_t *key) {
-	HMACSHA256_Key *hkey = key->opaque;
-	memset(hkey, 0, sizeof(HMACSHA256_Key));
-	isc_mem_put(key->mctx, hkey, sizeof(HMACSHA256_Key));
-	key->opaque = NULL;
+	dst_hmacsha256_key_t *hkey = key->keydata.hmacsha256;
+	memset(hkey, 0, sizeof(dst_hmacsha256_key_t));
+	isc_mem_put(key->mctx, hkey, sizeof(dst_hmacsha256_key_t));
+	key->keydata.hmacsha256 = NULL;
 }
 
 static isc_result_t
 hmacsha256_todns(const dst_key_t *key, isc_buffer_t *data) {
-	HMACSHA256_Key *hkey;
+	dst_hmacsha256_key_t *hkey;
 	unsigned int bytes;
 
-	REQUIRE(key->opaque != NULL);
+	REQUIRE(key->keydata.hmacsha256 != NULL);
 
-	hkey = (HMACSHA256_Key *) key->opaque;
+	hkey = key->keydata.hmacsha256;
 
 	bytes = (key->key_size + 7) / 8;
 	if (isc_buffer_availablelength(data) < bytes)
@@ -1001,7 +1017,7 @@ hmacsha256_todns(const dst_key_t *key, isc_buffer_t *data) {
 
 static isc_result_t
 hmacsha256_fromdns(dst_key_t *key, isc_buffer_t *data) {
-	HMACSHA256_Key *hkey;
+	dst_hmacsha256_key_t *hkey;
 	int keylen;
 	isc_region_t r;
 	isc_sha256_t sha256ctx;
@@ -1010,7 +1026,7 @@ hmacsha256_fromdns(dst_key_t *key, isc_buffer_t *data) {
 	if (r.length == 0)
 		return (ISC_R_SUCCESS);
 
-	hkey = (HMACSHA256_Key *) isc_mem_get(key->mctx, sizeof(HMACSHA256_Key));
+	hkey = isc_mem_get(key->mctx, sizeof(dst_hmacsha256_key_t));
 	if (hkey == NULL)
 		return (ISC_R_NOMEMORY);
 
@@ -1028,7 +1044,7 @@ hmacsha256_fromdns(dst_key_t *key, isc_buffer_t *data) {
 	}
 
 	key->key_size = keylen * 8;
-	key->opaque = hkey;
+	key->keydata.hmacsha256 = hkey;
 
 	return (ISC_R_SUCCESS);
 }
@@ -1036,15 +1052,15 @@ hmacsha256_fromdns(dst_key_t *key, isc_buffer_t *data) {
 static isc_result_t
 hmacsha256_tofile(const dst_key_t *key, const char *directory) {
 	int cnt = 0;
-	HMACSHA256_Key *hkey;
+	dst_hmacsha256_key_t *hkey;
 	dst_private_t priv;
 	int bytes = (key->key_size + 7) / 8;
 	unsigned char buf[2];
 
-	if (key->opaque == NULL)
+	if (key->keydata.hmacsha256 == NULL)
 		return (DST_R_NULLKEY);
 
-	hkey = (HMACSHA256_Key *) key->opaque;
+	hkey = key->keydata.hmacsha256;
 
 	priv.elements[cnt].tag = TAG_HMACSHA256_KEY;
 	priv.elements[cnt].length = bytes;
@@ -1079,7 +1095,7 @@ hmacsha256_parse(dst_key_t *key, isc_lex_t *lexer) {
 		switch (priv.elements[i].tag) {
 		case TAG_HMACSHA256_KEY:
 			isc_buffer_init(&b, priv.elements[i].data,
-				        priv.elements[i].length);
+					priv.elements[i].length);
 			isc_buffer_add(&b, priv.elements[i].length);
 			tresult = hmacsha256_fromdns(key, &b);
 			if (tresult != ISC_R_SUCCESS)
@@ -1117,6 +1133,7 @@ static dst_func_t hmacsha256_functions = {
 	hmacsha256_tofile,
 	hmacsha256_parse,
 	NULL, /* cleanup */
+	NULL, /* fromlabel */
 };
 
 isc_result_t
@@ -1129,37 +1146,37 @@ dst__hmacsha256_init(dst_func_t **funcp) {
 
 static isc_result_t hmacsha384_fromdns(dst_key_t *key, isc_buffer_t *data);
 
-typedef struct {
+struct dst_hmacsha384_key {
 	unsigned char key[ISC_SHA384_DIGESTLENGTH];
-} HMACSHA384_Key;
+};
 
 static isc_result_t
 hmacsha384_createctx(dst_key_t *key, dst_context_t *dctx) {
 	isc_hmacsha384_t *hmacsha384ctx;
-	HMACSHA384_Key *hkey = key->opaque;
+	dst_hmacsha384_key_t *hkey = key->keydata.hmacsha384;
 
 	hmacsha384ctx = isc_mem_get(dctx->mctx, sizeof(isc_hmacsha384_t));
 	if (hmacsha384ctx == NULL)
 		return (ISC_R_NOMEMORY);
 	isc_hmacsha384_init(hmacsha384ctx, hkey->key, ISC_SHA384_DIGESTLENGTH);
-	dctx->opaque = hmacsha384ctx;
+	dctx->ctxdata.hmacsha384ctx = hmacsha384ctx;
 	return (ISC_R_SUCCESS);
 }
 
 static void
 hmacsha384_destroyctx(dst_context_t *dctx) {
-	isc_hmacsha384_t *hmacsha384ctx = dctx->opaque;
+	isc_hmacsha384_t *hmacsha384ctx = dctx->ctxdata.hmacsha384ctx;
 
 	if (hmacsha384ctx != NULL) {
 		isc_hmacsha384_invalidate(hmacsha384ctx);
 		isc_mem_put(dctx->mctx, hmacsha384ctx, sizeof(isc_hmacsha384_t));
-		dctx->opaque = NULL;
+		dctx->ctxdata.hmacsha384ctx = NULL;
 	}
 }
 
 static isc_result_t
 hmacsha384_adddata(dst_context_t *dctx, const isc_region_t *data) {
-	isc_hmacsha384_t *hmacsha384ctx = dctx->opaque;
+	isc_hmacsha384_t *hmacsha384ctx = dctx->ctxdata.hmacsha384ctx;
 
 	isc_hmacsha384_update(hmacsha384ctx, data->base, data->length);
 	return (ISC_R_SUCCESS);
@@ -1167,7 +1184,7 @@ hmacsha384_adddata(dst_context_t *dctx, const isc_region_t *data) {
 
 static isc_result_t
 hmacsha384_sign(dst_context_t *dctx, isc_buffer_t *sig) {
-	isc_hmacsha384_t *hmacsha384ctx = dctx->opaque;
+	isc_hmacsha384_t *hmacsha384ctx = dctx->ctxdata.hmacsha384ctx;
 	unsigned char *digest;
 
 	if (isc_buffer_availablelength(sig) < ISC_SHA384_DIGESTLENGTH)
@@ -1181,7 +1198,7 @@ hmacsha384_sign(dst_context_t *dctx, isc_buffer_t *sig) {
 
 static isc_result_t
 hmacsha384_verify(dst_context_t *dctx, const isc_region_t *sig) {
-	isc_hmacsha384_t *hmacsha384ctx = dctx->opaque;
+	isc_hmacsha384_t *hmacsha384ctx = dctx->ctxdata.hmacsha384ctx;
 
 	if (sig->length > ISC_SHA384_DIGESTLENGTH || sig->length == 0)
 		return (DST_R_VERIFYFAILURE);
@@ -1194,10 +1211,10 @@ hmacsha384_verify(dst_context_t *dctx, const isc_region_t *sig) {
 
 static isc_boolean_t
 hmacsha384_compare(const dst_key_t *key1, const dst_key_t *key2) {
-	HMACSHA384_Key *hkey1, *hkey2;
+	dst_hmacsha384_key_t *hkey1, *hkey2;
 
-	hkey1 = (HMACSHA384_Key *)key1->opaque;
-	hkey2 = (HMACSHA384_Key *)key2->opaque;
+	hkey1 = key1->keydata.hmacsha384;
+	hkey2 = key2->keydata.hmacsha384;
 
 	if (hkey1 == NULL && hkey2 == NULL)
 		return (ISC_TRUE);
@@ -1245,20 +1262,20 @@ hmacsha384_isprivate(const dst_key_t *key) {
 
 static void
 hmacsha384_destroy(dst_key_t *key) {
-	HMACSHA384_Key *hkey = key->opaque;
-	memset(hkey, 0, sizeof(HMACSHA384_Key));
-	isc_mem_put(key->mctx, hkey, sizeof(HMACSHA384_Key));
-	key->opaque = NULL;
+	dst_hmacsha384_key_t *hkey = key->keydata.hmacsha384;
+	memset(hkey, 0, sizeof(dst_hmacsha384_key_t));
+	isc_mem_put(key->mctx, hkey, sizeof(dst_hmacsha384_key_t));
+	key->keydata.hmacsha384 = NULL;
 }
 
 static isc_result_t
 hmacsha384_todns(const dst_key_t *key, isc_buffer_t *data) {
-	HMACSHA384_Key *hkey;
+	dst_hmacsha384_key_t *hkey;
 	unsigned int bytes;
 
-	REQUIRE(key->opaque != NULL);
+	REQUIRE(key->keydata.hmacsha384 != NULL);
 
-	hkey = (HMACSHA384_Key *) key->opaque;
+	hkey = key->keydata.hmacsha384;
 
 	bytes = (key->key_size + 7) / 8;
 	if (isc_buffer_availablelength(data) < bytes)
@@ -1270,7 +1287,7 @@ hmacsha384_todns(const dst_key_t *key, isc_buffer_t *data) {
 
 static isc_result_t
 hmacsha384_fromdns(dst_key_t *key, isc_buffer_t *data) {
-	HMACSHA384_Key *hkey;
+	dst_hmacsha384_key_t *hkey;
 	int keylen;
 	isc_region_t r;
 	isc_sha384_t sha384ctx;
@@ -1279,7 +1296,7 @@ hmacsha384_fromdns(dst_key_t *key, isc_buffer_t *data) {
 	if (r.length == 0)
 		return (ISC_R_SUCCESS);
 
-	hkey = (HMACSHA384_Key *) isc_mem_get(key->mctx, sizeof(HMACSHA384_Key));
+	hkey = isc_mem_get(key->mctx, sizeof(dst_hmacsha384_key_t));
 	if (hkey == NULL)
 		return (ISC_R_NOMEMORY);
 
@@ -1297,7 +1314,7 @@ hmacsha384_fromdns(dst_key_t *key, isc_buffer_t *data) {
 	}
 
 	key->key_size = keylen * 8;
-	key->opaque = hkey;
+	key->keydata.hmacsha384 = hkey;
 
 	return (ISC_R_SUCCESS);
 }
@@ -1305,15 +1322,15 @@ hmacsha384_fromdns(dst_key_t *key, isc_buffer_t *data) {
 static isc_result_t
 hmacsha384_tofile(const dst_key_t *key, const char *directory) {
 	int cnt = 0;
-	HMACSHA384_Key *hkey;
+	dst_hmacsha384_key_t *hkey;
 	dst_private_t priv;
 	int bytes = (key->key_size + 7) / 8;
 	unsigned char buf[2];
 
-	if (key->opaque == NULL)
+	if (key->keydata.hmacsha384 == NULL)
 		return (DST_R_NULLKEY);
 
-	hkey = (HMACSHA384_Key *) key->opaque;
+	hkey = key->keydata.hmacsha384;
 
 	priv.elements[cnt].tag = TAG_HMACSHA384_KEY;
 	priv.elements[cnt].length = bytes;
@@ -1348,7 +1365,7 @@ hmacsha384_parse(dst_key_t *key, isc_lex_t *lexer) {
 		switch (priv.elements[i].tag) {
 		case TAG_HMACSHA384_KEY:
 			isc_buffer_init(&b, priv.elements[i].data,
-				        priv.elements[i].length);
+					priv.elements[i].length);
 			isc_buffer_add(&b, priv.elements[i].length);
 			tresult = hmacsha384_fromdns(key, &b);
 			if (tresult != ISC_R_SUCCESS)
@@ -1386,6 +1403,7 @@ static dst_func_t hmacsha384_functions = {
 	hmacsha384_tofile,
 	hmacsha384_parse,
 	NULL, /* cleanup */
+	NULL, /* fromlabel */
 };
 
 isc_result_t
@@ -1398,37 +1416,37 @@ dst__hmacsha384_init(dst_func_t **funcp) {
 
 static isc_result_t hmacsha512_fromdns(dst_key_t *key, isc_buffer_t *data);
 
-typedef struct {
+struct dst_hmacsha512_key {
 	unsigned char key[ISC_SHA512_DIGESTLENGTH];
-} HMACSHA512_Key;
+};
 
 static isc_result_t
 hmacsha512_createctx(dst_key_t *key, dst_context_t *dctx) {
 	isc_hmacsha512_t *hmacsha512ctx;
-	HMACSHA512_Key *hkey = key->opaque;
+	dst_hmacsha512_key_t *hkey = key->keydata.hmacsha512;
 
 	hmacsha512ctx = isc_mem_get(dctx->mctx, sizeof(isc_hmacsha512_t));
 	if (hmacsha512ctx == NULL)
 		return (ISC_R_NOMEMORY);
 	isc_hmacsha512_init(hmacsha512ctx, hkey->key, ISC_SHA512_DIGESTLENGTH);
-	dctx->opaque = hmacsha512ctx;
+	dctx->ctxdata.hmacsha512ctx = hmacsha512ctx;
 	return (ISC_R_SUCCESS);
 }
 
 static void
 hmacsha512_destroyctx(dst_context_t *dctx) {
-	isc_hmacsha512_t *hmacsha512ctx = dctx->opaque;
+	isc_hmacsha512_t *hmacsha512ctx = dctx->ctxdata.hmacsha512ctx;
 
 	if (hmacsha512ctx != NULL) {
 		isc_hmacsha512_invalidate(hmacsha512ctx);
 		isc_mem_put(dctx->mctx, hmacsha512ctx, sizeof(isc_hmacsha512_t));
-		dctx->opaque = NULL;
+		dctx->ctxdata.hmacsha512ctx = NULL;
 	}
 }
 
 static isc_result_t
 hmacsha512_adddata(dst_context_t *dctx, const isc_region_t *data) {
-	isc_hmacsha512_t *hmacsha512ctx = dctx->opaque;
+	isc_hmacsha512_t *hmacsha512ctx = dctx->ctxdata.hmacsha512ctx;
 
 	isc_hmacsha512_update(hmacsha512ctx, data->base, data->length);
 	return (ISC_R_SUCCESS);
@@ -1436,7 +1454,7 @@ hmacsha512_adddata(dst_context_t *dctx, const isc_region_t *data) {
 
 static isc_result_t
 hmacsha512_sign(dst_context_t *dctx, isc_buffer_t *sig) {
-	isc_hmacsha512_t *hmacsha512ctx = dctx->opaque;
+	isc_hmacsha512_t *hmacsha512ctx = dctx->ctxdata.hmacsha512ctx;
 	unsigned char *digest;
 
 	if (isc_buffer_availablelength(sig) < ISC_SHA512_DIGESTLENGTH)
@@ -1450,7 +1468,7 @@ hmacsha512_sign(dst_context_t *dctx, isc_buffer_t *sig) {
 
 static isc_result_t
 hmacsha512_verify(dst_context_t *dctx, const isc_region_t *sig) {
-	isc_hmacsha512_t *hmacsha512ctx = dctx->opaque;
+	isc_hmacsha512_t *hmacsha512ctx = dctx->ctxdata.hmacsha512ctx;
 
 	if (sig->length > ISC_SHA512_DIGESTLENGTH || sig->length == 0)
 		return (DST_R_VERIFYFAILURE);
@@ -1463,10 +1481,10 @@ hmacsha512_verify(dst_context_t *dctx, const isc_region_t *sig) {
 
 static isc_boolean_t
 hmacsha512_compare(const dst_key_t *key1, const dst_key_t *key2) {
-	HMACSHA512_Key *hkey1, *hkey2;
+	dst_hmacsha512_key_t *hkey1, *hkey2;
 
-	hkey1 = (HMACSHA512_Key *)key1->opaque;
-	hkey2 = (HMACSHA512_Key *)key2->opaque;
+	hkey1 = key1->keydata.hmacsha512;
+	hkey2 = key2->keydata.hmacsha512;
 
 	if (hkey1 == NULL && hkey2 == NULL)
 		return (ISC_TRUE);
@@ -1514,20 +1532,20 @@ hmacsha512_isprivate(const dst_key_t *key) {
 
 static void
 hmacsha512_destroy(dst_key_t *key) {
-	HMACSHA512_Key *hkey = key->opaque;
-	memset(hkey, 0, sizeof(HMACSHA512_Key));
-	isc_mem_put(key->mctx, hkey, sizeof(HMACSHA512_Key));
-	key->opaque = NULL;
+	dst_hmacsha512_key_t *hkey = key->keydata.hmacsha512;
+	memset(hkey, 0, sizeof(dst_hmacsha512_key_t));
+	isc_mem_put(key->mctx, hkey, sizeof(dst_hmacsha512_key_t));
+	key->keydata.hmacsha512 = NULL;
 }
 
 static isc_result_t
 hmacsha512_todns(const dst_key_t *key, isc_buffer_t *data) {
-	HMACSHA512_Key *hkey;
+	dst_hmacsha512_key_t *hkey;
 	unsigned int bytes;
 
-	REQUIRE(key->opaque != NULL);
+	REQUIRE(key->keydata.hmacsha512 != NULL);
 
-	hkey = (HMACSHA512_Key *) key->opaque;
+	hkey = key->keydata.hmacsha512;
 
 	bytes = (key->key_size + 7) / 8;
 	if (isc_buffer_availablelength(data) < bytes)
@@ -1539,7 +1557,7 @@ hmacsha512_todns(const dst_key_t *key, isc_buffer_t *data) {
 
 static isc_result_t
 hmacsha512_fromdns(dst_key_t *key, isc_buffer_t *data) {
-	HMACSHA512_Key *hkey;
+	dst_hmacsha512_key_t *hkey;
 	int keylen;
 	isc_region_t r;
 	isc_sha512_t sha512ctx;
@@ -1548,7 +1566,7 @@ hmacsha512_fromdns(dst_key_t *key, isc_buffer_t *data) {
 	if (r.length == 0)
 		return (ISC_R_SUCCESS);
 
-	hkey = (HMACSHA512_Key *) isc_mem_get(key->mctx, sizeof(HMACSHA512_Key));
+	hkey = isc_mem_get(key->mctx, sizeof(dst_hmacsha512_key_t));
 	if (hkey == NULL)
 		return (ISC_R_NOMEMORY);
 
@@ -1566,7 +1584,7 @@ hmacsha512_fromdns(dst_key_t *key, isc_buffer_t *data) {
 	}
 
 	key->key_size = keylen * 8;
-	key->opaque = hkey;
+	key->keydata.hmacsha512 = hkey;
 
 	return (ISC_R_SUCCESS);
 }
@@ -1574,15 +1592,15 @@ hmacsha512_fromdns(dst_key_t *key, isc_buffer_t *data) {
 static isc_result_t
 hmacsha512_tofile(const dst_key_t *key, const char *directory) {
 	int cnt = 0;
-	HMACSHA512_Key *hkey;
+	dst_hmacsha512_key_t *hkey;
 	dst_private_t priv;
 	int bytes = (key->key_size + 7) / 8;
 	unsigned char buf[2];
 
-	if (key->opaque == NULL)
+	if (key->keydata.hmacsha512 == NULL)
 		return (DST_R_NULLKEY);
 
-	hkey = (HMACSHA512_Key *) key->opaque;
+	hkey = key->keydata.hmacsha512;
 
 	priv.elements[cnt].tag = TAG_HMACSHA512_KEY;
 	priv.elements[cnt].length = bytes;
@@ -1617,7 +1635,7 @@ hmacsha512_parse(dst_key_t *key, isc_lex_t *lexer) {
 		switch (priv.elements[i].tag) {
 		case TAG_HMACSHA512_KEY:
 			isc_buffer_init(&b, priv.elements[i].data,
-				        priv.elements[i].length);
+					priv.elements[i].length);
 			isc_buffer_add(&b, priv.elements[i].length);
 			tresult = hmacsha512_fromdns(key, &b);
 			if (tresult != ISC_R_SUCCESS)
@@ -1655,6 +1673,7 @@ static dst_func_t hmacsha512_functions = {
 	hmacsha512_tofile,
 	hmacsha512_parse,
 	NULL, /* cleanup */
+	NULL, /* fromlabel */
 };
 
 isc_result_t
diff --git a/contrib/bind9/lib/dns/include/Makefile.in b/contrib/bind9/lib/dns/include/Makefile.in
index 593ad5a..b52cb98 100644
--- a/contrib/bind9/lib/dns/include/Makefile.in
+++ b/contrib/bind9/lib/dns/include/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1998-2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.18.1 2004/12/09 04:41:46 marka Exp $
+# $Id: Makefile.in,v 1.15 2007/06/19 23:47:16 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/dns/include/dns/Makefile.in b/contrib/bind9/lib/dns/include/dns/Makefile.in
index 3f367bc..e9e049e 100644
--- a/contrib/bind9/lib/dns/include/dns/Makefile.in
+++ b/contrib/bind9/lib/dns/include/dns/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1998-2003  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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 2004/03/05 05:09:40 marka Exp $
+# $Id: Makefile.in,v 1.55 2008/11/14 23:47:33 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -23,14 +23,14 @@ top_srcdir =	@top_srcdir@
 
 HEADERS =	acl.h adb.h byaddr.h cache.h callbacks.h \
 		cert.h compress.h \
-		db.h dbiterator.h dbtable.h diff.h dispatch.h \
-		dnssec.h ds.h events.h fixedname.h journal.h keyflags.h \
+		db.h dbiterator.h dbtable.h diff.h dispatch.h dlz.h \
+		dnssec.h ds.h events.h fixedname.h iptable.h journal.h keyflags.h \
 		keytable.h keyvalues.h lib.h log.h master.h masterdump.h \
 		message.h name.h ncache.h \
 		nsec.h peer.h portlist.h rbt.h rcode.h \
 		rdata.h rdataclass.h rdatalist.h rdataset.h rdatasetiter.h \
 		rdataslab.h rdatatype.h request.h resolver.h result.h \
-		rootns.h sdb.h secalg.h secproto.h soa.h ssu.h \
+		rootns.h sdb.h sdlz.h secalg.h secproto.h soa.h ssu.h \
 		tcpmsg.h time.h tkey.h \
 		tsig.h ttl.h types.h validator.h version.h view.h xfrin.h \
 		zone.h zonekey.h zt.h
diff --git a/contrib/bind9/lib/dns/include/dns/acache.h b/contrib/bind9/lib/dns/include/dns/acache.h
index 50d7fc1..28990c2 100644
--- a/contrib/bind9/lib/dns/include/dns/acache.h
+++ b/contrib/bind9/lib/dns/include/dns/acache.h
@@ -1,7 +1,7 @@
 /*
- * Copyright (C) 2004, 2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2006, 2007  Internet Systems Consortium, Inc. ("ISC")
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: acache.h,v 1.3.2.4 2006/05/03 00:07:49 marka Exp $ */
+/* $Id: acache.h,v 1.8 2007/06/19 23:47:16 tbox Exp $ */
 
 #ifndef DNS_ACACHE_H
 #define DNS_ACACHE_H 1
diff --git a/contrib/bind9/lib/dns/include/dns/acl.h b/contrib/bind9/lib/dns/include/dns/acl.h
index 34e394f..721fe51 100644
--- a/contrib/bind9/lib/dns/include/dns/acl.h
+++ b/contrib/bind9/lib/dns/include/dns/acl.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: acl.h,v 1.22.18.4 2006/03/02 00:37:21 marka Exp $ */
+/* $Id: acl.h,v 1.31.206.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef DNS_ACL_H
 #define DNS_ACL_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file dns/acl.h
  * \brief
  * Address match list handling.
  */
@@ -40,6 +40,7 @@
 
 #include <dns/name.h>
 #include <dns/types.h>
+#include <dns/iptable.h>
 
 /***
  *** Types
@@ -62,20 +63,21 @@ struct dns_aclipprefix {
 };
 
 struct dns_aclelement {
-	dns_aclelemettype_t type;
-	isc_boolean_t negative;
-	union {
-		dns_aclipprefix_t ip_prefix;
-		dns_name_t 	  keyname;
-		dns_acl_t 	  *nestedacl;
-	} u;
+	dns_aclelemettype_t	type;
+	isc_boolean_t		negative;
+	dns_name_t		keyname;
+	dns_acl_t		*nestedacl;
+	int			node_num;
 };
 
 struct dns_acl {
 	unsigned int		magic;
 	isc_mem_t		*mctx;
 	isc_refcount_t		refcount;
+	dns_iptable_t		*iptable;
+#define node_count		iptable->radix->num_added_node
 	dns_aclelement_t	*elements;
+	isc_boolean_t 		has_negatives;
 	unsigned int 		alloc;		/*%< Elements allocated */
 	unsigned int 		length;		/*%< Elements initialized */
 	char 			*name;		/*%< Temporary use only */
@@ -100,14 +102,9 @@ ISC_LANG_BEGINDECLS
 isc_result_t
 dns_acl_create(isc_mem_t *mctx, int n, dns_acl_t **target);
 /*%<
- * Create a new ACL with room for 'n' elements.
- * The elements are uninitialized and the length is 0.
- */
-
-isc_result_t
-dns_acl_appendelement(dns_acl_t *acl, const dns_aclelement_t *elt);
-/*%<
- * Append an element to an existing ACL.
+ * Create a new ACL, including an IP table and an array with room
+ * for 'n' ACL elements.  The elements are uninitialized and the
+ * length is 0.
  */
 
 isc_result_t
@@ -122,6 +119,30 @@ dns_acl_none(isc_mem_t *mctx, dns_acl_t **target);
  * Create a new ACL that matches nothing.
  */
 
+isc_boolean_t
+dns_acl_isany(dns_acl_t *acl);
+/*%<
+ * Test whether ACL is set to "{ any; }"
+ */
+
+isc_boolean_t
+dns_acl_isnone(dns_acl_t *acl);
+/*%<
+ * Test whether ACL is set to "{ none; }"
+ */
+
+isc_result_t
+dns_acl_merge(dns_acl_t *dest, dns_acl_t *source, isc_boolean_t pos);
+/*%<
+ * Merge the contents of one ACL into another.  Call dns_iptable_merge()
+ * for the IP tables, then concatenate the element arrays.
+ *
+ * If pos is set to false, then the nested ACL is to be negated.  This
+ * means reverse the sense of each *positive* element or IP table node,
+ * but leave negatives alone, so as to prevent a double-negative causing
+ * an unexpected positive match in the parent ACL.
+ */
+
 void
 dns_acl_attach(dns_acl_t *source, dns_acl_t **target);
 
@@ -129,17 +150,11 @@ void
 dns_acl_detach(dns_acl_t **aclp);
 
 isc_boolean_t
-dns_aclelement_equal(const dns_aclelement_t *ea, const dns_aclelement_t *eb);
-
-isc_boolean_t
-dns_acl_equal(const dns_acl_t *a, const dns_acl_t *b);
-
-isc_boolean_t
 dns_acl_isinsecure(const dns_acl_t *a);
 /*%<
  * Return #ISC_TRUE iff the acl 'a' is considered insecure, that is,
  * if it contains IP addresses other than those of the local host.
- * This is intended for applications such as printing warning 
+ * This is intended for applications such as printing warning
  * messages for suspect ACLs; it is not intended for making access
  * control decisions.  We make no guarantee that an ACL for which
  * this function returns #ISC_FALSE is safe.
@@ -147,6 +162,9 @@ dns_acl_isinsecure(const dns_acl_t *a);
 
 isc_result_t
 dns_aclenv_init(isc_mem_t *mctx, dns_aclenv_t *env);
+/*%<
+ * Initialize ACL environment, setting up localhost and localnets ACLs
+ */
 
 void
 dns_aclenv_copy(dns_aclenv_t *t, dns_aclenv_t *s);
@@ -168,19 +186,17 @@ dns_acl_match(const isc_netaddr_t *reqaddr,
  * Match the address 'reqaddr', and optionally the key name 'reqsigner',
  * against 'acl'.  'reqsigner' may be NULL.
  *
- * If there is a positive match, '*match' will be set to a positive value
- * indicating the distance from the beginning of the list.
- *
- * If there is a negative match, '*match' will be set to a negative value
- * whose absolute value indicates the distance from the beginning of
- * the list.
- *
- * If there is a match (either positive or negative) and 'matchelt' is
- * non-NULL, *matchelt will be attached to the primitive
- * (non-indirect) address match list element that matched.
+ * If there is a match, '*match' will be set to an integer whose absolute
+ * value corresponds to the order in which the matching value was inserted
+ * into the ACL.  For a positive match, this value will be positive; for a
+ * negative match, it will be negative.
  *
  * If there is no match, *match will be set to zero.
  *
+ * If there is a match in the element list (either positive or negative)
+ * and 'matchelt' is non-NULL, *matchelt will be pointed to the matching
+ * element.
+ *
  * Returns:
  *\li	#ISC_R_SUCCESS		Always succeeds.
  */
@@ -189,34 +205,18 @@ isc_boolean_t
 dns_aclelement_match(const isc_netaddr_t *reqaddr,
 		     const dns_name_t *reqsigner,
 		     const dns_aclelement_t *e,
-		     const dns_aclenv_t *env,		     
+		     const dns_aclenv_t *env,
 		     const dns_aclelement_t **matchelt);
 /*%<
  * Like dns_acl_match, but matches against the single ACL element 'e'
- * rather than a complete list and returns ISC_TRUE iff it matched.
- * To determine whether the match was prositive or negative, the 
+ * rather than a complete ACL, and returns ISC_TRUE iff it matched.
+ *
+ * To determine whether the match was positive or negative, the
  * caller should examine e->negative.  Since the element 'e' may be
- * a reference to a named ACL or a nested ACL, the matching element
+ * a reference to a named ACL or a nested ACL, a matching element
  * returned through 'matchelt' is not necessarily 'e' itself.
  */
 
-isc_result_t
-dns_acl_elementmatch(const dns_acl_t *acl,
-		     const dns_aclelement_t *elt,
-		     const dns_aclelement_t **matchelt);
-/*%<
- * Search for an ACL element in 'acl' which is exactly the same as 'elt'.
- * If there is one, and 'matchelt' is non NULL, then '*matchelt' will point
- * to the entry.
- *
- * This function is intended to be used for avoiding duplicated ACL entries
- * before adding an entry.
- *
- * Returns:
- *\li	#ISC_R_SUCCESS		Match succeeds.
- *\li	#ISC_R_NOTFOUND		Match fails.
- */
-
 ISC_LANG_ENDDECLS
 
 #endif /* DNS_ACL_H */
diff --git a/contrib/bind9/lib/dns/include/dns/adb.h b/contrib/bind9/lib/dns/include/dns/adb.h
index 1e3cd61..d4ac40c 100644
--- a/contrib/bind9/lib/dns/include/dns/adb.h
+++ b/contrib/bind9/lib/dns/include/dns/adb.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: adb.h,v 1.76.18.3 2005/06/23 04:23:16 marka Exp $ */
+/* $Id: adb.h,v 1.85 2008/04/03 06:09:04 tbox Exp $ */
 
 #ifndef DNS_ADB_H
 #define DNS_ADB_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file dns/adb.h
  *\brief
  * DNS Address Database
  *
@@ -99,7 +99,7 @@ ISC_LANG_BEGINDECLS
 
 typedef struct dns_adbname		dns_adbname_t;
 
-/*! 
+/*!
  *\brief
  * Represents a lookup for a single name.
  *
@@ -220,7 +220,7 @@ struct dns_adbaddrinfo {
 	ISC_LINK(dns_adbaddrinfo_t)	publink;
 };
 
-/*!< 
+/*!<
  * The event sent to the caller task is just a plain old isc_event_t.  It
  * contains no data other than a simple status, passed in the "type" field
  * to indicate that another address resolved, or all partially resolved
@@ -345,7 +345,7 @@ dns_adb_createfind(dns_adb_t *adb, isc_task_t *task, isc_taskaction_t action,
  *
  * If no events will be generated, the *find->result_v4 and/or result_v6
  * members may be examined for address lookup status.  The usual #ISC_R_SUCCESS,
- * #ISC_R_FAILURE, and #DNS_R_NX{DOMAIN,RRSET} are returned, along with
+ * #ISC_R_FAILURE, #DNS_R_NXDOMAIN, and #DNS_R_NXRRSET are returned, along with
  * #ISC_R_NOTFOUND meaning the ADB has not _yet_ found the values.  In this
  * latter case, retrying may produce more addresses.
  *
@@ -520,7 +520,7 @@ void
 dns_adb_adjustsrtt(dns_adb_t *adb, dns_adbaddrinfo_t *addr,
 		   unsigned int rtt, unsigned int factor);
 /*%<
- * Mix the round trip time into the existing smoothed rtt.  
+ * Mix the round trip time into the existing smoothed rtt.
 
  * The formula used
  * (where srtt is the existing rtt value, and rtt and factor are arguments to
@@ -623,13 +623,12 @@ void
 dns_adb_flushname(dns_adb_t *adb, dns_name_t *name);
 /*%<
  * Flush 'name' from the adb cache.
- * 
+ *
  * Requires:
  *\li	'adb' is valid.
  *\li	'name' is valid.
  */
 
-
 ISC_LANG_ENDDECLS
 
 #endif /* DNS_ADB_H */
diff --git a/contrib/bind9/lib/dns/include/dns/bit.h b/contrib/bind9/lib/dns/include/dns/bit.h
index 770f294..28c733d 100644
--- a/contrib/bind9/lib/dns/include/dns/bit.h
+++ b/contrib/bind9/lib/dns/include/dns/bit.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: bit.h,v 1.8.18.2 2005/04/29 00:16:09 marka Exp $ */
+/* $Id: bit.h,v 1.14 2007/06/19 23:47:16 tbox Exp $ */
 
 #ifndef DNS_BIT_H
 #define DNS_BIT_H 1
 
-/*! \file */
+/*! \file dns/bit.h */
 
 #include <isc/int.h>
 #include <isc/boolean.h>
diff --git a/contrib/bind9/lib/dns/include/dns/byaddr.h b/contrib/bind9/lib/dns/include/dns/byaddr.h
index 1f1e88c..edf8430 100644
--- a/contrib/bind9/lib/dns/include/dns/byaddr.h
+++ b/contrib/bind9/lib/dns/include/dns/byaddr.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: byaddr.h,v 1.16.18.2 2005/04/29 00:16:09 marka Exp $ */
+/* $Id: byaddr.h,v 1.22 2007/06/19 23:47:16 tbox Exp $ */
 
 #ifndef DNS_BYADDR_H
 #define DNS_BYADDR_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file dns/byaddr.h
  * \brief
  * The byaddr module provides reverse lookup services for IPv4 and IPv6
  * addresses.
@@ -121,8 +121,8 @@ dns_byaddr_cancel(dns_byaddr_t *byaddr);
  *
  * Notes:
  *
- *\li	If 'byaddr' has not completed, post its #BYADDRDONE event with a
- *	result code of #ISC_R_CANCELED.
+ *\li	If 'byaddr' has not completed, post its #DNS_EVENT_BYADDRDONE
+ *	event with a result code of #ISC_R_CANCELED.
  *
  * Requires:
  *
@@ -138,8 +138,8 @@ dns_byaddr_destroy(dns_byaddr_t **byaddrp);
  *
  *\li	'*byaddrp' is a valid byaddr.
  *
- *\li	The caller has received the BYADDRDONE event (either because the
- *	byaddr completed or because dns_byaddr_cancel() was called).
+ *\li	The caller has received the #DNS_EVENT_BYADDRDONE event (either because
+ *	the byaddr completed or because dns_byaddr_cancel() was called).
  *
  * Ensures:
  *
diff --git a/contrib/bind9/lib/dns/include/dns/cache.h b/contrib/bind9/lib/dns/include/dns/cache.h
index fc4f78e..7b37235 100644
--- a/contrib/bind9/lib/dns/include/dns/cache.h
+++ b/contrib/bind9/lib/dns/include/dns/cache.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: cache.h,v 1.19.18.3 2005/08/23 02:31:38 marka Exp $ */
+/* $Id: cache.h,v 1.26 2007/06/19 23:47:16 tbox Exp $ */
 
 #ifndef DNS_CACHE_H
 #define DNS_CACHE_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file dns/cache.h
  * \brief
  * Defines dns_cache_t, the cache object.
  *
diff --git a/contrib/bind9/lib/dns/include/dns/callbacks.h b/contrib/bind9/lib/dns/include/dns/callbacks.h
index 6aee70b..8a8385a 100644
--- a/contrib/bind9/lib/dns/include/dns/callbacks.h
+++ b/contrib/bind9/lib/dns/include/dns/callbacks.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: callbacks.h,v 1.18.18.2 2005/04/29 00:16:10 marka Exp $ */
+/* $Id: callbacks.h,v 1.24 2007/06/19 23:47:16 tbox Exp $ */
 
 #ifndef DNS_CALLBACKS_H
 #define DNS_CALLBACKS_H 1
 
-/*! \file */
+/*! \file dns/callbacks.h */
 
 /***
  ***	Imports
diff --git a/contrib/bind9/lib/dns/include/dns/cert.h b/contrib/bind9/lib/dns/include/dns/cert.h
index 4de1aec..1cda848 100644
--- a/contrib/bind9/lib/dns/include/dns/cert.h
+++ b/contrib/bind9/lib/dns/include/dns/cert.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: cert.h,v 1.13.18.2 2005/04/29 00:16:10 marka Exp $ */
+/* $Id: cert.h,v 1.19 2007/06/19 23:47:16 tbox Exp $ */
 
 #ifndef DNS_CERT_H
 #define DNS_CERT_H 1
 
-/*! \file */
+/*! \file dns/cert.h */
 
 #include <isc/lang.h>
 
diff --git a/contrib/bind9/lib/dns/include/dns/compress.h b/contrib/bind9/lib/dns/include/dns/compress.h
index 4d9c011..4632aff 100644
--- a/contrib/bind9/lib/dns/include/dns/compress.h
+++ b/contrib/bind9/lib/dns/include/dns/compress.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: compress.h,v 1.32.18.6 2006/03/02 00:37:21 marka Exp $ */
+/* $Id: compress.h,v 1.40.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef DNS_COMPRESS_H
 #define DNS_COMPRESS_H 1
@@ -32,7 +32,7 @@ ISC_LANG_BEGINDECLS
 #define DNS_COMPRESS_ALL		0x01	/*%< all compression. */
 #define DNS_COMPRESS_CASESENSITIVE	0x02	/*%< case sensitive compression. */
 
-/*! \file
+/*! \file dns/compress.h
  *	Direct manipulation of the structures is strongly discouraged.
  */
 
@@ -77,7 +77,7 @@ struct dns_decompress {
 isc_result_t
 dns_compress_init(dns_compress_t *cctx, int edns, isc_mem_t *mctx);
 /*%<
- *	Inialise the compression context structure pointed to by 'cctx'.
+ *	Initialise the compression context structure pointed to by 'cctx'.
  *
  *	Requires:
  *	\li	'cctx' is a valid dns_compress_t structure.
@@ -136,7 +136,7 @@ dns_compress_setsensitive(dns_compress_t *cctx, isc_boolean_t sensitive);
 isc_boolean_t
 dns_compress_getsensitive(dns_compress_t *cctx);
 /*
- *	Return whether case is to be preservered when compressing
+ *	Return whether case is to be preserved when compressing
  *	domain names.
  *
  *	Requires:
diff --git a/contrib/bind9/lib/dns/include/dns/db.h b/contrib/bind9/lib/dns/include/dns/db.h
index b03ae57..3b78208 100644
--- a/contrib/bind9/lib/dns/include/dns/db.h
+++ b/contrib/bind9/lib/dns/include/dns/db.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: db.h,v 1.76.18.10 2007/08/28 07:20:05 tbox Exp $ */
+/* $Id: db.h,v 1.93.50.3 2009/01/18 23:25:17 marka Exp $ */
 
 #ifndef DNS_DB_H
 #define DNS_DB_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file dns/db.h
  * \brief
  * The DNS DB interface allows named rdatasets to be stored and retrieved.
  *
@@ -111,8 +111,7 @@ typedef struct dns_dbmethods {
 				      isc_stdtime_t now);
 	void		(*printnode)(dns_db_t *db, dns_dbnode_t *node,
 				     FILE *out);
-	isc_result_t 	(*createiterator)(dns_db_t *db,
-					  isc_boolean_t relative_names,
+	isc_result_t 	(*createiterator)(dns_db_t *db, unsigned int options,
 					  dns_dbiterator_t **iteratorp);
 	isc_result_t	(*findrdataset)(dns_db_t *db, dns_dbnode_t *node,
 					dns_dbversion_t *version,
@@ -146,6 +145,28 @@ typedef struct dns_dbmethods {
 	void		(*overmem)(dns_db_t *db, isc_boolean_t overmem);
 	void		(*settask)(dns_db_t *db, isc_task_t *);
 	isc_result_t	(*getoriginnode)(dns_db_t *db, dns_dbnode_t **nodep);
+	void		(*transfernode)(dns_db_t *db, dns_dbnode_t **sourcep,
+					dns_dbnode_t **targetp);
+	isc_result_t    (*getnsec3parameters)(dns_db_t *db,
+					      dns_dbversion_t *version,
+					      dns_hash_t *hash,
+					      isc_uint8_t *flags,
+					      isc_uint16_t *iterations,
+					      unsigned char *salt,
+					      size_t *salt_len);
+	isc_result_t    (*findnsec3node)(dns_db_t *db, dns_name_t *name,
+					 isc_boolean_t create,
+					 dns_dbnode_t **nodep);
+	isc_result_t	(*setsigningtime)(dns_db_t *db,
+					  dns_rdataset_t *rdataset,
+					  isc_stdtime_t resign);
+	isc_result_t	(*getsigningtime)(dns_db_t *db,
+					  dns_rdataset_t *rdataset,
+					  dns_name_t *name);
+	void		(*resigned)(dns_db_t *db, dns_rdataset_t *rdataset,
+					   dns_dbversion_t *version);
+	isc_boolean_t	(*isdnssec)(dns_db_t *db);
+	dns_stats_t	*(*getrrsetstats)(dns_db_t *db);
 } dns_dbmethods_t;
 
 typedef isc_result_t
@@ -153,7 +174,7 @@ typedef isc_result_t
 		      dns_dbtype_t type, dns_rdataclass_t rdclass,
 		      unsigned int argc, char *argv[], void *driverarg,
 		      dns_db_t **dbp);
-					
+
 #define DNS_DB_MAGIC		ISC_MAGIC('D','N','S','D')
 #define DNS_DB_VALID(db)	ISC_MAGIC_VALID(db, DNS_DB_MAGIC)
 
@@ -191,6 +212,7 @@ struct dns_db {
 #define DNS_DBFIND_NOEXACT		0x10
 #define DNS_DBFIND_FORCENSEC		0x20
 #define DNS_DBFIND_COVERINGNSEC		0x40
+#define DNS_DBFIND_FORCENSEC3		0x80
 /*@}*/
 
 /*@{*/
@@ -208,6 +230,15 @@ struct dns_db {
  */
 #define DNS_DBSUB_EXACT			0x01
 
+/*@{*/
+/*%
+ * Iterator options
+ */
+#define DNS_DB_RELATIVENAMES	0x1
+#define DNS_DB_NSEC3ONLY	0x2
+#define DNS_DB_NONSEC3		0x4
+/*@}*/
+
 /*****
  ***** Methods
  *****/
@@ -355,6 +386,20 @@ dns_db_issecure(dns_db_t *db);
  * \li	#ISC_FALSE	'db' is not secure.
  */
 
+isc_boolean_t
+dns_db_isdnssec(dns_db_t *db);
+/*%<
+ * Is 'db' secure or partially secure?
+ *
+ * Requires:
+ *
+ * \li	'db' is a valid database with zone semantics.
+ *
+ * Returns:
+ * \li	#ISC_TRUE	'db' is secure or is partially.
+ * \li	#ISC_FALSE	'db' is not secure.
+ */
+
 dns_name_t *
 dns_db_origin(dns_db_t *db);
 /*%<
@@ -626,7 +671,7 @@ dns_db_findnode(dns_db_t *db, dns_name_t *name, isc_boolean_t create,
  *
  * \li	#ISC_R_SUCCESS
  * \li	#ISC_R_NOTFOUND			If !create and name not found.
- * \li	#ISC_R_NOMEMORY		        Can only happen if create is ISC_TRUE.
+ * \li	#ISC_R_NOMEMORY			Can only happen if create is ISC_TRUE.
  *
  * \li	Other results are possible, depending upon the database
  *	implementation used.
@@ -785,8 +830,8 @@ dns_db_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
  *						name, and 'rdataset' contains
  *						the negative caching proof.
  *
- *	\li	#DNS_R_EMPTYNAME			The name exists but there is
- *						no data at the name. 
+ *	\li	#DNS_R_EMPTYNAME		The name exists but there is
+ *						no data at the name.
  *
  *	\li	#DNS_R_COVERINGNSEC		The returned data is a NSEC
  *						that potentially covers 'name'.
@@ -883,6 +928,27 @@ dns_db_detachnode(dns_db_t *db, dns_dbnode_t **nodep);
  * \li	*nodep is NULL.
  */
 
+void
+dns_db_transfernode(dns_db_t *db, dns_dbnode_t **sourcep,
+		    dns_dbnode_t **targetp);
+/*%<
+ * Transfer a node between pointer.
+ *
+ * This is equivalent to calling dns_db_attachnode() then dns_db_detachnode().
+ *
+ * Requires:
+ *
+ * \li	'db' is a valid database.
+ *
+ * \li	'*sourcep' is a valid node.
+ *
+ * \li	'targetp' points to a NULL dns_dbnode_t *.
+ *
+ * Ensures:
+ *
+ * \li	'*sourcep' is NULL.
+ */
+
 isc_result_t
 dns_db_expirenode(dns_db_t *db, dns_dbnode_t *node, isc_stdtime_t now);
 /*%<
@@ -917,16 +983,17 @@ dns_db_printnode(dns_db_t *db, dns_dbnode_t *node, FILE *out);
  ***/
 
 isc_result_t
-dns_db_createiterator(dns_db_t *db, isc_boolean_t relative_names,
+dns_db_createiterator(dns_db_t *db, unsigned int options,
 		      dns_dbiterator_t **iteratorp);
 /*%<
  * Create an iterator for version 'version' of 'db'.
  *
  * Notes:
  *
- * \li	If 'relative_names' is ISC_TRUE, then node names returned by the
- *	iterator will be relative to the iterator's current origin.  If
- *	#ISC_FALSE, then the node names will be absolute.
+ * \li	One or more of the following options can be set.
+ *	#DNS_DB_RELATIVENAMES
+ *	#DNS_DB_NSEC3ONLY
+ *	#DNS_DB_NONSEC3
  *
  * Requires:
  *
@@ -1005,7 +1072,7 @@ isc_result_t
 dns_db_allrdatasets(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version,
 		    isc_stdtime_t now, dns_rdatasetiter_t **iteratorp);
 /*%<
- * Make '*iteratorp' an rdataset iteratator for all rdatasets at 'node' in
+ * Make '*iteratorp' an rdataset iterator for all rdatasets at 'node' in
  * version 'version' of 'db'.
  *
  * Notes:
@@ -1192,7 +1259,7 @@ dns_db_getsoaserial(dns_db_t *db, dns_dbversion_t *ver, isc_uint32_t *serialp);
 void
 dns_db_overmem(dns_db_t *db, isc_boolean_t overmem);
 /*%<
- * Enable / disable agressive cache cleaning.
+ * Enable / disable aggressive cache cleaning.
  */
 
 unsigned int
@@ -1262,7 +1329,7 @@ dns_db_register(const char *name, dns_dbcreatefunc_t create, void *driverarg,
 void
 dns_db_unregister(dns_dbimplementation_t **dbimp);
 /*%<
- * Remove a database implementation from the the list of supported
+ * Remove a database implementation from the list of supported
  * implementations.  No databases of this type can be active when this
  * is called.
  *
@@ -1294,6 +1361,117 @@ dns_db_getoriginnode(dns_db_t *db, dns_dbnode_t **nodep);
  * \li	#ISC_R_NOTFOUND - the DB implementation does not support this feature.
  */
 
+isc_result_t
+dns_db_getnsec3parameters(dns_db_t *db, dns_dbversion_t *version,
+			  dns_hash_t *hash, isc_uint8_t *flags,
+			  isc_uint16_t *interations,
+			  unsigned char *salt, size_t *salt_length);
+/*%<
+ * Get the NSEC3 parameters that are associated with this zone.
+ *
+ * Requires:
+ * \li	'db' is a valid zone database.
+ *
+ * Returns:
+ * \li	#ISC_R_SUCCESS
+ * \li	#ISC_R_NOTFOUND - the DB implementation does not support this feature
+ *			  or this zone does not have NSEC3 records.
+ */
+
+isc_result_t
+dns_db_findnsec3node(dns_db_t *db, dns_name_t *name,
+		     isc_boolean_t create, dns_dbnode_t **nodep);
+/*%<
+ * Find the NSEC3 node with name 'name'.
+ *
+ * Notes:
+ * \li	If 'create' is ISC_TRUE and no node with name 'name' exists, then
+ *	such a node will be created.
+ *
+ * Requires:
+ *
+ * \li	'db' is a valid database.
+ *
+ * \li	'name' is a valid, non-empty, absolute name.
+ *
+ * \li	nodep != NULL && *nodep == NULL
+ *
+ * Ensures:
+ *
+ * \li	On success, *nodep is attached to the node with name 'name'.
+ *
+ * Returns:
+ *
+ * \li	#ISC_R_SUCCESS
+ * \li	#ISC_R_NOTFOUND			If !create and name not found.
+ * \li	#ISC_R_NOMEMORY			Can only happen if create is ISC_TRUE.
+ *
+ * \li	Other results are possible, depending upon the database
+ *	implementation used.
+ */
+
+isc_result_t
+dns_db_setsigningtime(dns_db_t *db, dns_rdataset_t *rdataset,
+		      isc_stdtime_t resign);
+/*%<
+ * Sets the re-signing time associated with 'rdataset' to 'resign'.
+ *
+ * Requires:
+ * \li	'db' is a valid zone database.
+ * \li	'rdataset' to be associated with 'db'.
+ *
+ * Returns:
+ * \li	#ISC_R_SUCCESS
+ * \li	#ISC_R_NOMEMORY
+ * \li	#ISC_R_NOTIMPLEMENTED - Not supported by this DB implementation.
+ */
+
+isc_result_t
+dns_db_getsigningtime(dns_db_t *db, dns_rdataset_t *rdataset, dns_name_t *name);
+/*%<
+ * Return the rdataset with the earliest signing time in the zone.
+ * Note: the rdataset is version agnostic.
+ *
+ * Requires:
+ * \li	'db' is a valid zone database.
+ * \li	'rdataset' to be initialized but not associated.
+ * \li	'name' to be NULL or have a buffer associated with it.
+ *
+ * Returns:
+ * \li	#ISC_R_SUCCESS
+ * \li	#ISC_R_NOTFOUND - No dataset exists.
+ */
+
+void
+dns_db_resigned(dns_db_t *db, dns_rdataset_t *rdataset,
+		dns_dbversion_t *version);
+/*%<
+ * Mark 'rdataset' as not being available to be returned by
+ * dns_db_getsigningtime().  If the changes associated with 'version'
+ * are committed this will be permanent.  If the version is not committed
+ * this change will be rolled back when the version is closed.
+ *
+ * Requires:
+ * \li	'db' is a valid zone database.
+ * \li	'rdataset' to be associated with 'db'.
+ * \li	'version' to be open for writing.
+ */
+
+dns_stats_t *
+dns_db_getrrsetstats(dns_db_t *db);
+/*%<
+ * Get statistics information counting RRsets stored in the DB, when available.
+ * The statistics may not be available depending on the DB implementation.
+ *
+ * Requires:
+ *
+ * \li	'db' is a valid database (zone or cache).
+ *
+ * Returns:
+ * \li	when available, a pointer to a statistics object created by
+ *	dns_rdatasetstats_create(); otherwise NULL.
+ */
+
 ISC_LANG_ENDDECLS
 
 #endif /* DNS_DB_H */
diff --git a/contrib/bind9/lib/dns/include/dns/dbiterator.h b/contrib/bind9/lib/dns/include/dns/dbiterator.h
index 47ce082..366d676 100644
--- a/contrib/bind9/lib/dns/include/dns/dbiterator.h
+++ b/contrib/bind9/lib/dns/include/dns/dbiterator.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dbiterator.h,v 1.19.18.2 2005/04/29 00:16:11 marka Exp $ */
+/* $Id: dbiterator.h,v 1.25 2007/06/19 23:47:16 tbox Exp $ */
 
 #ifndef DNS_DBITERATOR_H
 #define DNS_DBITERATOR_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file dns/dbiterator.h
  * \brief
  * The DNS DB Iterator interface allows iteration of all of the nodes in a
  * database.
diff --git a/contrib/bind9/lib/dns/include/dns/dbtable.h b/contrib/bind9/lib/dns/include/dns/dbtable.h
index 18d3e50..503de95 100644
--- a/contrib/bind9/lib/dns/include/dns/dbtable.h
+++ b/contrib/bind9/lib/dns/include/dns/dbtable.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dbtable.h,v 1.17.18.2 2005/04/29 00:16:11 marka Exp $ */
+/* $Id: dbtable.h,v 1.23 2007/06/19 23:47:16 tbox Exp $ */
 
 #ifndef DNS_DBTABLE_H
 #define DNS_DBTABLE_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file dns/dbtable.h
  * \brief
  * DNS DB Tables
  *
diff --git a/contrib/bind9/lib/dns/include/dns/diff.h b/contrib/bind9/lib/dns/include/dns/diff.h
index cd96a0b..a13b678 100644
--- a/contrib/bind9/lib/dns/include/dns/diff.h
+++ b/contrib/bind9/lib/dns/include/dns/diff.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: diff.h,v 1.6.18.2 2005/04/29 00:16:12 marka Exp $ */
+/* $Id: diff.h,v 1.15.120.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef DNS_DIFF_H
 #define DNS_DIFF_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file dns/diff.h
  * \brief
  * A diff is a convenience type representing a list of changes to be
  * made to a database.
@@ -59,12 +59,18 @@
  * individual RRs of a "RRset exists (value dependent)"
  * prerequisite set.  In this case, op==DNS_DIFFOP_EXISTS,
  * and the TTL is ignored.
+ *
+ * DNS_DIFFOP_*RESIGN will cause the 'resign' attribute of the resulting
+ * RRset to be recomputed to be 'resign' seconds before the earliest RRSIG
+ * timeexpire.
  */
 
 typedef enum {
-	DNS_DIFFOP_ADD,	        /*%< Add an RR. */
-	DNS_DIFFOP_DEL,		/*%< Delete an RR. */
-	DNS_DIFFOP_EXISTS	/*%< Assert RR existence. */
+	DNS_DIFFOP_ADD = 0,		/*%< Add an RR. */
+	DNS_DIFFOP_DEL = 1,		/*%< Delete an RR. */
+	DNS_DIFFOP_EXISTS = 2,		/*%< Assert RR existence. */
+	DNS_DIFFOP_ADDRESIGN = 4,	/*%< ADD + RESIGN. */
+	DNS_DIFFOP_DELRESIGN = 5,	/*%< DEL + RESIGN. */
 } dns_diffop_t;
 
 typedef struct dns_difftuple dns_difftuple_t;
@@ -73,7 +79,7 @@ typedef struct dns_difftuple dns_difftuple_t;
 #define DNS_DIFFTUPLE_VALID(t)	ISC_MAGIC_VALID(t, DNS_DIFFTUPLE_MAGIC)
 
 struct dns_difftuple {
-        unsigned int			magic;
+	unsigned int			magic;
 	isc_mem_t			*mctx;
 	dns_diffop_t			op;
 	dns_name_t			name;
@@ -96,10 +102,15 @@ typedef struct dns_diff dns_diff_t;
 struct dns_diff {
 	unsigned int			magic;
 	isc_mem_t *			mctx;
+	/*
+	 * Set the 'resign' attribute to this many second before the
+	 * earliest RRSIG timeexpire.
+	 */
+	isc_uint32_t			resign;
 	ISC_LIST(dns_difftuple_t)	tuples;
 };
 
-/* Type of comparision function for sorting diffs. */
+/* Type of comparison function for sorting diffs. */
 typedef int dns_diff_compare_func(const void *, const void *);
 
 /***
@@ -110,7 +121,7 @@ ISC_LANG_BEGINDECLS
 
 /**************************************************************************/
 /*
- * Maniuplation of diffs and tuples.
+ * Manipulation of diffs and tuples.
  */
 
 isc_result_t
diff --git a/contrib/bind9/lib/dns/include/dns/dispatch.h b/contrib/bind9/lib/dns/include/dns/dispatch.h
index 8c14320..96a44fe 100644
--- a/contrib/bind9/lib/dns/include/dns/dispatch.h
+++ b/contrib/bind9/lib/dns/include/dns/dispatch.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dispatch.h,v 1.48.18.9 2008/06/24 23:45:55 tbox Exp $ */
+/* $Id: dispatch.h,v 1.60.82.2 2009/01/29 23:47:44 tbox Exp $ */
 
 #ifndef DNS_DISPATCH_H
 #define DNS_DISPATCH_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file dns/dispatch.h
  * \brief
  * DNS Dispatch Management
  * 	Shared UDP and single-use TCP dispatches for queries and responses.
@@ -55,7 +55,7 @@
 #include <isc/buffer.h>
 #include <isc/lang.h>
 #include <isc/socket.h>
-#include <dns/types.h>
+#include <isc/types.h>
 
 #include <dns/types.h>
 
@@ -222,6 +222,21 @@ dns_dispatchmgr_setavailports(dns_dispatchmgr_t *mgr, isc_portset_t *v4portset,
  *\li	v6portset is NULL or a valid port set
  */
 
+void
+dns_dispatchmgr_setstats(dns_dispatchmgr_t *mgr, isc_stats_t *stats);
+/*%<
+ * Sets statistics counter for the dispatchmgr.  This function is expected to
+ * be called only on zone creation (when necessary).
+ * Once installed, it cannot be removed or replaced.  Also, there is no
+ * interface to get the installed stats from the zone; the caller must keep the
+ * stats to reference (e.g. dump) it later.
+ *
+ * Requires:
+ *\li	mgr is a valid dispatchmgr with no managed dispatch.
+ *\li	stats is a valid statistics supporting resolver statistics counters
+ *	(see dns/stats.h).
+ */
+
 isc_result_t
 dns_dispatch_getudp(dns_dispatchmgr_t *mgr, isc_socketmgr_t *sockmgr,
 		    isc_taskmgr_t *taskmgr, isc_sockaddr_t *localaddr,
diff --git a/contrib/bind9/lib/dns/include/dns/dlz.h b/contrib/bind9/lib/dns/include/dns/dlz.h
index 4c61c91..75ba99f 100644
--- a/contrib/bind9/lib/dns/include/dns/dlz.h
+++ b/contrib/bind9/lib/dns/include/dns/dlz.h
@@ -1,8 +1,8 @@
 /*
- * Portions Copyright (C) 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2005-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -50,9 +50,9 @@
  * USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dlz.h,v 1.2.2.2 2005/09/06 03:47:18 marka Exp $ */
+/* $Id: dlz.h,v 1.7.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
-/*! \file */
+/*! \file dns/dlz.h */
 
 #ifndef DLZ_H
 #define DLZ_H 1
@@ -133,7 +133,7 @@ typedef void
 /*%<
  * Method prototype.  Drivers implementing the DLZ interface MUST
  * supply a destroy method.  This method is called when the DNS server
- * is shuting down and no longer needs the driver.
+ * is shutting down and no longer needs the driver.
  */
 
 typedef isc_result_t
@@ -157,7 +157,7 @@ typedef isc_result_t
  * \li	3) we run out of domain name labels. I.E. we have tried the
  *	   shortest domain name
  * \li	4) the number of labels in the domain name is less than
- *	   min_lables for dns_dlzfindzone
+ *	   min_labels for dns_dlzfindzone
  *
  * The driver's find zone method should return ISC_R_SUCCESS and a
  * database pointer to the name server if the zone is supported by the
@@ -202,7 +202,7 @@ dns_dlzallowzonexfr(dns_view_t *view, dns_name_t *name,
 
 /*%<
  * This method is called when the DNS server is performing a zone
- * transfer query.  It will call the DLZ driver's allow zone tranfer
+ * transfer query.  It will call the DLZ driver's allow zone transfer
  * method.
  */
 
@@ -223,7 +223,7 @@ void
 dns_dlzdestroy(dns_dlzdb_t **dbp);
 
 /*%<
- * This method is called when the DNS server is shuting down and no
+ * This method is called when the DNS server is shutting down and no
  * longer needs the driver.  If the DLZ driver supplies a destroy
  * methods, this function will call it.
  */
diff --git a/contrib/bind9/lib/dns/include/dns/dnssec.h b/contrib/bind9/lib/dns/include/dns/dnssec.h
index 2804e03..f8a59d0 100644
--- a/contrib/bind9/lib/dns/include/dns/dnssec.h
+++ b/contrib/bind9/lib/dns/include/dns/dnssec.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dnssec.h,v 1.26.18.2 2005/04/29 00:16:12 marka Exp $ */
+/* $Id: dnssec.h,v 1.32 2007/06/19 23:47:16 tbox Exp $ */
 
 #ifndef DNS_DNSSEC_H
 #define DNS_DNSSEC_H 1
 
-/*! \file */
+/*! \file dns/dnssec.h */
 
 #include <isc/lang.h>
 #include <isc/stdtime.h>
diff --git a/contrib/bind9/lib/dns/include/dns/ds.h b/contrib/bind9/lib/dns/include/dns/ds.h
index 5e4cc40..b59fb83 100644
--- a/contrib/bind9/lib/dns/include/dns/ds.h
+++ b/contrib/bind9/lib/dns/include/dns/ds.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ds.h,v 1.3.20.5 2006/02/22 23:50:09 marka Exp $ */
+/* $Id: ds.h,v 1.10 2007/06/19 23:47:16 tbox Exp $ */
 
 #ifndef DNS_DS_H
 #define DNS_DS_H 1
diff --git a/contrib/bind9/lib/dns/include/dns/events.h b/contrib/bind9/lib/dns/include/dns/events.h
index d1ebef3..bb61b9d 100644
--- a/contrib/bind9/lib/dns/include/dns/events.h
+++ b/contrib/bind9/lib/dns/include/dns/events.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,14 +15,14 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: events.h,v 1.42.18.3 2005/04/29 00:16:13 marka Exp $ */
+/* $Id: events.h,v 1.49.332.2 2009/05/07 23:47:12 tbox Exp $ */
 
 #ifndef DNS_EVENTS_H
 #define DNS_EVENTS_H 1
 
 #include <isc/eventclass.h>
 
-/*! \file 
+/*! \file dns/events.h
  * \brief
  * Registry of DNS event numbers.
  */
@@ -68,6 +68,7 @@
 #define DNS_EVENT_ACACHECONTROL			(ISC_EVENTCLASS_DNS + 38)
 #define DNS_EVENT_ACACHECLEAN			(ISC_EVENTCLASS_DNS + 39)
 #define DNS_EVENT_ACACHEOVERMEM			(ISC_EVENTCLASS_DNS + 40)
+#define DNS_EVENT_RBTPRUNE			(ISC_EVENTCLASS_DNS + 41)
 
 #define DNS_EVENT_FIRSTEVENT			(ISC_EVENTCLASS_DNS + 0)
 #define DNS_EVENT_LASTEVENT			(ISC_EVENTCLASS_DNS + 65535)
diff --git a/contrib/bind9/lib/dns/include/dns/fixedname.h b/contrib/bind9/lib/dns/include/dns/fixedname.h
index 8380de6..5a2aaf3 100644
--- a/contrib/bind9/lib/dns/include/dns/fixedname.h
+++ b/contrib/bind9/lib/dns/include/dns/fixedname.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: fixedname.h,v 1.13.18.2 2005/04/29 00:16:13 marka Exp $ */
+/* $Id: fixedname.h,v 1.19 2007/06/19 23:47:16 tbox Exp $ */
 
 #ifndef DNS_FIXEDNAME_H
 #define DNS_FIXEDNAME_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file dns/fixedname.h
  * \brief
  * Fixed-size Names
  *
diff --git a/contrib/bind9/lib/dns/include/dns/forward.h b/contrib/bind9/lib/dns/include/dns/forward.h
index ddf6d7f..512c5e3 100644
--- a/contrib/bind9/lib/dns/include/dns/forward.h
+++ b/contrib/bind9/lib/dns/include/dns/forward.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: forward.h,v 1.3.18.3 2005/04/27 05:01:33 sra Exp $ */
+/* $Id: forward.h,v 1.11 2007/06/19 23:47:16 tbox Exp $ */
 
 #ifndef DNS_FORWARD_H
 #define DNS_FORWARD_H 1
 
-/*! \file */
+/*! \file dns/forward.h */
 
 #include <isc/lang.h>
 #include <isc/result.h>
diff --git a/contrib/bind9/lib/dns/include/dns/iptable.h b/contrib/bind9/lib/dns/include/dns/iptable.h
new file mode 100644
index 0000000..d7eb140
--- /dev/null
+++ b/contrib/bind9/lib/dns/include/dns/iptable.h
@@ -0,0 +1,70 @@
+/*
+ * Copyright (C) 2007  Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or 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: iptable.h,v 1.4 2007/09/14 01:46:05 marka Exp $ */
+
+#ifndef DNS_IPTABLE_H
+#define DNS_IPTABLE_H 1
+
+#include <isc/lang.h>
+#include <isc/magic.h>
+#include <isc/radix.h>
+
+struct dns_iptable {
+	unsigned int		magic;
+	isc_mem_t		*mctx;
+	isc_refcount_t		refcount;
+	isc_radix_tree_t	*radix;
+	ISC_LINK(dns_iptable_t)	nextincache;
+};
+
+#define DNS_IPTABLE_MAGIC	ISC_MAGIC('T','a','b','l')
+#define DNS_IPTABLE_VALID(a)	ISC_MAGIC_VALID(a, DNS_IPTABLE_MAGIC)
+
+/***
+ *** Functions
+ ***/
+
+ISC_LANG_BEGINDECLS
+
+isc_result_t
+dns_iptable_create(isc_mem_t *mctx, dns_iptable_t **target);
+/*
+ * Create a new IP table and the underlying radix structure
+ */
+
+isc_result_t
+dns_iptable_addprefix(dns_iptable_t *tab, isc_netaddr_t *addr,
+		      isc_uint16_t bitlen, isc_boolean_t pos);
+/*
+ * Add an IP prefix to an existing IP table
+ */
+
+isc_result_t
+dns_iptable_merge(dns_iptable_t *tab, dns_iptable_t *source, isc_boolean_t pos);
+/*
+ * Merge one IP table into another one.
+ */
+
+void
+dns_iptable_attach(dns_iptable_t *source, dns_iptable_t **target);
+
+void
+dns_iptable_detach(dns_iptable_t **tabp);
+
+ISC_LANG_ENDDECLS
+
+#endif /* DNS_IPTABLE_H */
diff --git a/contrib/bind9/lib/dns/include/dns/journal.h b/contrib/bind9/lib/dns/include/dns/journal.h
index b776a30..3917d8d 100644
--- a/contrib/bind9/lib/dns/include/dns/journal.h
+++ b/contrib/bind9/lib/dns/include/dns/journal.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: journal.h,v 1.25.18.2 2005/04/29 00:16:13 marka Exp $ */
+/* $Id: journal.h,v 1.33.120.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef DNS_JOURNAL_H
 #define DNS_JOURNAL_H 1
@@ -24,9 +24,9 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file dns/journal.h
  * \brief
- * Database journalling.
+ * Database journaling.
  */
 
 /***
@@ -42,6 +42,11 @@
 #include <dns/types.h>
 
 /***
+ *** Defines.
+ ***/
+#define DNS_JOURNALOPT_RESIGN	0x00000001
+
+/***
  *** Types
  ***/
 
@@ -188,7 +193,7 @@ dns_journal_iter_init(dns_journal_t *j,
  * Returns:
  *\li	ISC_R_SUCCESS
  *\li	ISC_R_RANGE	begin_serial is outside the addressable range.
- *\li	ISC_R_NOTFOUND	begin_serial is within the range of adressable
+ *\li	ISC_R_NOTFOUND	begin_serial is within the range of addressable
  *			serial numbers covered by the journal, but
  *			this particular serial number does not exist.
  */
@@ -225,17 +230,18 @@ dns_journal_current_rr(dns_journal_t *j, dns_name_t **name, isc_uint32_t *ttl,
  */
 
 isc_result_t
-dns_journal_rollforward(isc_mem_t *mctx, dns_db_t *db, const char *filename);
+dns_journal_rollforward(isc_mem_t *mctx, dns_db_t *db, unsigned int options,
+			const char *filename);
 /*%<
  * Roll forward (play back) the journal file "filename" into the
  * database "db".  This should be called when the server starts
  * after a shutdown or crash.
  *
  * Requires:
- *\li      'mctx' is a valid memory context.
+ *\li   'mctx' is a valid memory context.
  *\li	'db' is a valid database which does not have a version
  *           open for writing.
- *  \li    'filename' is the name of the journal file belonging to 'db'.
+ *\li   'filename' is the name of the journal file belonging to 'db'.
  *
  * Returns:
  *\li	DNS_R_NOJOURNAL when journal does not exist.
@@ -264,7 +270,7 @@ dns_db_diff(isc_mem_t *mctx,
 
 isc_result_t
 dns_journal_compact(isc_mem_t *mctx, char *filename, isc_uint32_t serial,
-                    isc_uint32_t target_size);
+		    isc_uint32_t target_size);
 /*%<
  * Attempt to compact the journal if it is greater that 'target_size'.
  * Changes from 'serial' onwards will be preserved.  If the journal
diff --git a/contrib/bind9/lib/dns/include/dns/keyflags.h b/contrib/bind9/lib/dns/include/dns/keyflags.h
index 665b517..74a1740 100644
--- a/contrib/bind9/lib/dns/include/dns/keyflags.h
+++ b/contrib/bind9/lib/dns/include/dns/keyflags.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: keyflags.h,v 1.10.18.2 2005/04/29 00:16:13 marka Exp $ */
+/* $Id: keyflags.h,v 1.16 2007/06/19 23:47:16 tbox Exp $ */
 
 #ifndef DNS_KEYFLAGS_H
 #define DNS_KEYFLAGS_H 1
 
-/*! \file */
+/*! \file dns/keyflags.h */
 
 #include <isc/lang.h>
 
diff --git a/contrib/bind9/lib/dns/include/dns/keytable.h b/contrib/bind9/lib/dns/include/dns/keytable.h
index b8bfcc1..553aa99 100644
--- a/contrib/bind9/lib/dns/include/dns/keytable.h
+++ b/contrib/bind9/lib/dns/include/dns/keytable.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: keytable.h,v 1.11.18.3 2005/12/05 00:00:03 marka Exp $ */
+/* $Id: keytable.h,v 1.16 2007/06/19 23:47:16 tbox Exp $ */
 
 #ifndef DNS_KEYTABLE_H
 #define DNS_KEYTABLE_H 1
diff --git a/contrib/bind9/lib/dns/include/dns/keyvalues.h b/contrib/bind9/lib/dns/include/dns/keyvalues.h
index df17ace..7040389 100644
--- a/contrib/bind9/lib/dns/include/dns/keyvalues.h
+++ b/contrib/bind9/lib/dns/include/dns/keyvalues.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: keyvalues.h,v 1.15.18.2 2005/04/29 00:16:14 marka Exp $ */
+/* $Id: keyvalues.h,v 1.23 2008/09/25 04:02:39 tbox Exp $ */
 
 #ifndef DNS_KEYVALUES_H
 #define DNS_KEYVALUES_H 1
 
-/*! \file */
+/*! \file dns/keyvalues.h */
 
 /*
  * Flags field of the KEY RR rdata
@@ -64,9 +64,11 @@
 #define DNS_KEYALG_RSA		DNS_KEYALG_RSAMD5
 #define DNS_KEYALG_DH		2       /*%< Diffie Hellman KEY */
 #define DNS_KEYALG_DSA		3       /*%< DSA KEY */
-#define DNS_KEYALG_DSS		NS_ALG_DSA
+#define DNS_KEYALG_NSEC3DSA	6
+#define DNS_KEYALG_DSS		DNS_ALG_DSA
 #define DNS_KEYALG_ECC		4
 #define DNS_KEYALG_RSASHA1	5
+#define DNS_KEYALG_NSEC3RSASHA1	7
 #define DNS_KEYALG_INDIRECT	252
 #define DNS_KEYALG_PRIVATEDNS	253
 #define DNS_KEYALG_PRIVATEOID	254     /*%< Key begins with OID giving alg */
diff --git a/contrib/bind9/lib/dns/include/dns/lib.h b/contrib/bind9/lib/dns/include/dns/lib.h
index d59dde3..fd3325b 100644
--- a/contrib/bind9/lib/dns/include/dns/lib.h
+++ b/contrib/bind9/lib/dns/include/dns/lib.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lib.h,v 1.8.18.4 2005/09/20 04:33:48 marka Exp $ */
+/* $Id: lib.h,v 1.16 2007/06/19 23:47:17 tbox Exp $ */
 
 #ifndef DNS_LIB_H
 #define DNS_LIB_H 1
 
-/*! \file */
+/*! \file dns/lib.h */
 
 #include <isc/types.h>
 #include <isc/lang.h>
diff --git a/contrib/bind9/lib/dns/include/dns/log.h b/contrib/bind9/lib/dns/include/dns/log.h
index 7bee174..b7aed42 100644
--- a/contrib/bind9/lib/dns/include/dns/log.h
+++ b/contrib/bind9/lib/dns/include/dns/log.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,9 +15,9 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: log.h,v 1.33.18.4 2005/09/05 00:18:27 marka Exp $ */
+/* $Id: log.h,v 1.42.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
-/*! \file
+/*! \file dns/log.h
  * \author  Principal Authors: DCL */
 
 #ifndef DNS_LOG_H
@@ -41,6 +41,7 @@ LIBDNS_EXTERNAL_DATA extern isc_logmodule_t dns_modules[];
 #define DNS_LOGCATEGORY_DISPATCH	(&dns_categories[8])
 #define DNS_LOGCATEGORY_LAME_SERVERS	(&dns_categories[9])
 #define DNS_LOGCATEGORY_DELEGATION_ONLY	(&dns_categories[10])
+#define DNS_LOGCATEGORY_EDNS_DISABLED	(&dns_categories[11])
 
 /* Backwards compatibility. */
 #define DNS_LOGCATEGORY_GENERAL		ISC_LOGCATEGORY_GENERAL
@@ -87,7 +88,7 @@ dns_log_init(isc_log_t *lctx);
  *\li	dns_log_init() is called only once.
  *
  * Ensures:
- * \li	The catgories and modules defined above are available for
+ * \li	The categories and modules defined above are available for
  * 	use by isc_log_usechannnel() and isc_log_write().
  */
 
diff --git a/contrib/bind9/lib/dns/include/dns/lookup.h b/contrib/bind9/lib/dns/include/dns/lookup.h
index aea6f84..0e9a327 100644
--- a/contrib/bind9/lib/dns/include/dns/lookup.h
+++ b/contrib/bind9/lib/dns/include/dns/lookup.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lookup.h,v 1.6.18.2 2005/04/29 00:16:15 marka Exp $ */
+/* $Id: lookup.h,v 1.12.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef DNS_LOOKUP_H
 #define DNS_LOOKUP_H 1
@@ -24,11 +24,11 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file dns/lookup.h
  * \brief
  * The lookup module performs simple DNS lookups.  It implements
- * the full resolver algorithm, both looking for local data and 
- * resoving external names as necessary.
+ * the full resolver algorithm, both looking for local data and
+ * resolving external names as necessary.
  *
  * MP:
  *\li	The module ensures appropriate synchronization of data structures it
diff --git a/contrib/bind9/lib/dns/include/dns/master.h b/contrib/bind9/lib/dns/include/dns/master.h
index 1f94c8c..93a782d 100644
--- a/contrib/bind9/lib/dns/include/dns/master.h
+++ b/contrib/bind9/lib/dns/include/dns/master.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: master.h,v 1.38.18.6 2005/06/20 01:19:43 marka Exp $ */
+/* $Id: master.h,v 1.51 2008/04/02 02:37:42 marka Exp $ */
 
 #ifndef DNS_MASTER_H
 #define DNS_MASTER_H 1
 
-/*! \file */
+/*! \file dns/master.h */
 
 /***
  ***	Imports
@@ -42,7 +42,7 @@
 #define DNS_MASTER_HINT 	0x00000010	/*%< Loading a hint master file. */
 #define DNS_MASTER_SLAVE 	0x00000020	/*%< Loading a slave master file. */
 #define DNS_MASTER_CHECKNS 	0x00000040	/*%<
-						 * Check NS records to see 
+						 * Check NS records to see
 						 * if they are an address
 						 */
 #define DNS_MASTER_FATALNS 	0x00000080	/*%<
@@ -55,6 +55,8 @@
 #define DNS_MASTER_CHECKMX	0x00000800
 #define DNS_MASTER_CHECKMXFAIL	0x00001000
 
+#define DNS_MASTER_RESIGN	0x00002000
+
 ISC_LANG_BEGINDECLS
 
 /*
@@ -113,6 +115,17 @@ dns_master_loadfile2(const char *master_file,
 		     dns_masterformat_t format);
 
 isc_result_t
+dns_master_loadfile3(const char *master_file,
+		     dns_name_t *top,
+		     dns_name_t *origin,
+		     dns_rdataclass_t zclass,
+		     unsigned int options,
+		     isc_uint32_t resign,
+		     dns_rdatacallbacks_t *callbacks,
+		     isc_mem_t *mctx,
+		     dns_masterformat_t format);
+
+isc_result_t
 dns_master_loadstream(FILE *stream,
 		      dns_name_t *top,
 		      dns_name_t *origin,
@@ -163,6 +176,19 @@ dns_master_loadfileinc2(const char *master_file,
 			dns_masterformat_t format);
 
 isc_result_t
+dns_master_loadfileinc3(const char *master_file,
+			dns_name_t *top,
+			dns_name_t *origin,
+			dns_rdataclass_t zclass,
+			unsigned int options,
+			isc_uint32_t resign,
+			dns_rdatacallbacks_t *callbacks,
+			isc_task_t *task,
+			dns_loaddonefunc_t done, void *done_arg,
+			dns_loadctx_t **ctxp, isc_mem_t *mctx,
+			dns_masterformat_t format);
+
+isc_result_t
 dns_master_loadstreaminc(FILE *stream,
 			 dns_name_t *top,
 			 dns_name_t *origin,
@@ -212,6 +238,9 @@ dns_master_loadlexerinc(isc_lex_t *lex,
  * is completed or has failed.  If the initial setup fails 'done' is
  * not called.
  *
+ * 'resign' the number of seconds before a RRSIG expires that it should
+ * be re-signed.  0 is used if not provided.
+ *
  * Requires:
  *\li	'master_file' points to a valid string.
  *\li	'lexer' points to a valid lexer.
diff --git a/contrib/bind9/lib/dns/include/dns/masterdump.h b/contrib/bind9/lib/dns/include/dns/masterdump.h
index 8cf5c13..42521b3 100644
--- a/contrib/bind9/lib/dns/include/dns/masterdump.h
+++ b/contrib/bind9/lib/dns/include/dns/masterdump.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: masterdump.h,v 1.31.14.4 2005/09/01 03:04:28 marka Exp $ */
+/* $Id: masterdump.h,v 1.42 2008/09/24 02:46:23 marka Exp $ */
 
 #ifndef DNS_MASTERDUMP_H
 #define DNS_MASTERDUMP_H 1
 
-/*! \file */
+/*! \file dns/masterdump.h */
 
 /***
  ***	Imports
@@ -91,11 +91,14 @@ typedef struct dns_master_style dns_master_style_t;
 /*% Print negative caching entries. */
 #define	DNS_STYLEFLAG_NCACHE		0x00800000U
 
-/*% Never print the TTL */
+/*% Never print the TTL. */
 #define	DNS_STYLEFLAG_NO_TTL		0x01000000U
-                    
-/*% Never print the CLASS */
-#define	DNS_STYLEFLAG_NO_CLASS		0x02000000U 
+
+/*% Never print the CLASS. */
+#define	DNS_STYLEFLAG_NO_CLASS		0x02000000U
+
+/*% Report re-signing time. */
+#define	DNS_STYLEFLAG_RESIGN		0x04000000U
 
 ISC_LANG_BEGINDECLS
 
@@ -119,8 +122,8 @@ LIBDNS_EXTERNAL_DATA extern const dns_master_style_t dns_master_style_default;
 LIBDNS_EXTERNAL_DATA extern const dns_master_style_t dns_master_style_full;
 
 /*%
- * A master file style that prints explicit TTL values on each 
- * record line, never using $TTL statements.  The TTL has a tab 
+ * A master file style that prints explicit TTL values on each
+ * record line, never using $TTL statements.  The TTL has a tab
  * stop of its own, but the class and type share one.
  */
 LIBDNS_EXTERNAL_DATA extern const dns_master_style_t
@@ -133,9 +136,9 @@ LIBDNS_EXTERNAL_DATA extern const dns_master_style_t
 LIBDNS_EXTERNAL_DATA extern const dns_master_style_t dns_master_style_cache;
 
 /*%
- * A master style that prints name, ttl, class, type, and value on 
- * every line.  Similar to explicitttl above, but more verbose.  
- * Intended for generating master files which can be easily parsed 
+ * A master style that prints name, ttl, class, type, and value on
+ * every line.  Similar to explicitttl above, but more verbose.
+ * Intended for generating master files which can be easily parsed
  * by perl scripts and similar applications.
  */
 LIBDNS_EXTERNAL_DATA extern const dns_master_style_t dns_master_style_simple;
@@ -231,7 +234,7 @@ dns_master_dumptostream2(isc_mem_t *mctx, dns_db_t *db,
  *\li	'task' to be valid.
  *\li	'done' to be non NULL.
  *\li	'dctxp' to be non NULL && '*dctxp' to be NULL.
- * 
+ *
  * Returns:
  *\li	ISC_R_SUCCESS
  *\li	ISC_R_CONTINUE	dns_master_dumptostreaminc() only.
@@ -329,6 +332,9 @@ dns_master_stylecreate(dns_master_style_t **style, unsigned int flags,
 void
 dns_master_styledestroy(dns_master_style_t **style, isc_mem_t *mctx);
 
+const char *
+dns_trust_totext(dns_trust_t trust);
+
 ISC_LANG_ENDDECLS
 
 #endif /* DNS_MASTERDUMP_H */
diff --git a/contrib/bind9/lib/dns/include/dns/message.h b/contrib/bind9/lib/dns/include/dns/message.h
index 9002b83..f880095 100644
--- a/contrib/bind9/lib/dns/include/dns/message.h
+++ b/contrib/bind9/lib/dns/include/dns/message.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: message.h,v 1.114.18.6 2006/03/02 23:19:20 marka Exp $ */
+/* $Id: message.h,v 1.125.118.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef DNS_MESSAGE_H
 #define DNS_MESSAGE_H 1
@@ -33,7 +33,7 @@
 
 #include <dst/dst.h>
 
-/*! \file 
+/*! \file dns/message.h
  * \brief Message Handling Module
  *
  * How this beast works:
@@ -101,8 +101,12 @@
 #define DNS_MESSAGEFLAG_AD		0x0020U
 #define DNS_MESSAGEFLAG_CD		0x0010U
 
+/*%< EDNS0 extended message flags */
 #define DNS_MESSAGEEXTFLAG_DO		0x8000U
 
+/*%< EDNS0 extended OPT codes */
+#define DNS_OPT_NSID		0x0003		/*%< NSID opt code */
+
 #define DNS_MESSAGE_REPLYPRESERVE	(DNS_MESSAGEFLAG_RD|DNS_MESSAGEFLAG_CD)
 #define DNS_MESSAGEEXTFLAG_REPLYPRESERVE (DNS_MESSAGEEXTFLAG_DO)
 
@@ -157,7 +161,7 @@ typedef int dns_messagetextflag_t;
 						   occurs */
 #define DNS_MESSAGEPARSE_CLONEBUFFER	0x0004	/*%< save a copy of the
 						   source buffer */
-#define DNS_MESSAGEPARSE_IGNORETRUNCATION 0x0008 /*%< trucation errors are
+#define DNS_MESSAGEPARSE_IGNORETRUNCATION 0x0008 /*%< truncation errors are
 						  * not fatal. */
 
 /*
@@ -771,7 +775,7 @@ dns_message_addname(dns_message_t *msg, dns_name_t *name,
 
 void
 dns_message_removename(dns_message_t *msg, dns_name_t *name,
-                       dns_section_t section);
+		       dns_section_t section);
 /*%<
  * Remove a existing name from a given section.
  *
@@ -1031,7 +1035,7 @@ dns_message_setopt(dns_message_t *msg, dns_rdataset_t *opt);
  *\li	The OPT record has either been freed or ownership of it has
  *	been transferred to the message.
  *
- *\li	If ISC_R_SUCCESS was returned, the OPT record will be rendered 
+ *\li	If ISC_R_SUCCESS was returned, the OPT record will be rendered
  *	when dns_message_renderend() is called.
  *
  * Returns:
@@ -1195,7 +1199,7 @@ dns_message_takebuffer(dns_message_t *msg, isc_buffer_t **buffer);
  *\li	msg be a valid message.
  *
  *\li	buffer != NULL && *buffer is a valid isc_buffer_t, which was
- *	dynamincally allocated via isc_buffer_allocate().
+ *	dynamically allocated via isc_buffer_allocate().
  */
 
 isc_result_t
@@ -1315,7 +1319,7 @@ dns_message_setsortorder(dns_message_t *msg, dns_rdatasetorderfunc_t order,
  *\li	order_arg is NULL if and only if order is NULL.
  */
 
-void 
+void
 dns_message_settimeadjust(dns_message_t *msg, int timeadjust);
 /*%<
  * Adjust the time used to sign/verify a message by timeadjust.
@@ -1325,7 +1329,7 @@ dns_message_settimeadjust(dns_message_t *msg, int timeadjust);
  *\li	msg be a valid message.
  */
 
-int 
+int
 dns_message_gettimeadjust(dns_message_t *msg);
 /*%<
  * Return the current time adjustment.
diff --git a/contrib/bind9/lib/dns/include/dns/name.h b/contrib/bind9/lib/dns/include/dns/name.h
index 038ae05..0149301 100644
--- a/contrib/bind9/lib/dns/include/dns/name.h
+++ b/contrib/bind9/lib/dns/include/dns/name.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: name.h,v 1.107.18.15 2006/03/02 00:37:21 marka Exp $ */
+/* $Id: name.h,v 1.126.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef DNS_NAME_H
 #define DNS_NAME_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file dns/name.h
  * \brief
  * Provides facilities for manipulating DNS names and labels, including
  * conversions to and from wire format and text format.
@@ -131,6 +131,7 @@ struct dns_name {
 #define DNS_NAMEATTR_READONLY		0x0002
 #define DNS_NAMEATTR_DYNAMIC		0x0004
 #define DNS_NAMEATTR_DYNOFFSETS		0x0008
+#define DNS_NAMEATTR_NOCOMPRESS		0x0010
 /*
  * Attributes below 0x0100 reserved for name.c usage.
  */
@@ -242,7 +243,7 @@ dns_name_setbuffer(dns_name_t *name, isc_buffer_t *buffer);
  *
  * Notes:
  * \li	Specification of a target buffer in dns_name_fromwire(),
- *	dns_name_fromtext(), and dns_name_concatentate() is optional if
+ *	dns_name_fromtext(), and dns_name_concatenate() is optional if
  *	'name' has a dedicated buffer.
  *
  * \li	The caller must not write to buffer until the name has been
@@ -721,7 +722,7 @@ dns_name_fromwire(dns_name_t *name, isc_buffer_t *source,
 
 isc_result_t
 dns_name_towire(const dns_name_t *name, dns_compress_t *cctx,
-	        isc_buffer_t *target);
+		isc_buffer_t *target);
 /*%<
  * Convert 'name' into wire format, compressing it as specified by the
  * compression context 'cctx', and storing the result in 'target'.
@@ -840,7 +841,7 @@ dns_name_totext(dns_name_t *name, isc_boolean_t omit_final_dot,
  * name as generated by dns_name_totext().  This does not
  * include space for a terminating NULL.
  *
- * This definition is conservative - the actual maximum 
+ * This definition is conservative - the actual maximum
  * is 1004, derived as follows:
  *
  *   A backslash-decimal escaped character takes 4 bytes.
@@ -952,7 +953,7 @@ dns_name_split(dns_name_t *name, unsigned int suffixlabels,
  *
  * Notes:
  * \li     'name' is split such that 'suffix' holds the most significant
- *      'suffixlabels' labels.  All other labels are stored in 'prefix'. 
+ *      'suffixlabels' labels.  All other labels are stored in 'prefix'.
  *
  *\li	Copying name data is avoided as much as possible, so 'prefix'
  *	and 'suffix' will end up pointing at the data for 'name'.
@@ -1082,7 +1083,7 @@ dns_name_dynamic(dns_name_t *name);
  *
  * Returns:
  *
- *\li	'ISC_TRUE' if the name is dynamic othewise 'ISC_FALSE'.
+ *\li	'ISC_TRUE' if the name is dynamic otherwise 'ISC_FALSE'.
  */
 
 isc_result_t
@@ -1185,7 +1186,7 @@ dns_name_ishostname(const dns_name_t *name, isc_boolean_t wildcard);
  * Requires:
  *	'name' to be valid.
  */
- 
+
 
 isc_boolean_t
 dns_name_ismailbox(const dns_name_t *name);
@@ -1220,7 +1221,7 @@ dns_name_destroy(void);
 ISC_LANG_ENDDECLS
 
 /*
- *** High Peformance Macros
+ *** High Performance Macros
  ***/
 
 /*
diff --git a/contrib/bind9/lib/dns/include/dns/ncache.h b/contrib/bind9/lib/dns/include/dns/ncache.h
index 459effb..a818fe6 100644
--- a/contrib/bind9/lib/dns/include/dns/ncache.h
+++ b/contrib/bind9/lib/dns/include/dns/ncache.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ncache.h,v 1.17.18.2 2005/04/29 00:16:16 marka Exp $ */
+/* $Id: ncache.h,v 1.25 2008/09/25 04:02:39 tbox Exp $ */
 
 #ifndef DNS_NCACHE_H
 #define DNS_NCACHE_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file dns/ncache.h
  *\brief
  * DNS Ncache
  *
@@ -63,6 +63,11 @@ isc_result_t
 dns_ncache_add(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
 	       dns_rdatatype_t covers, isc_stdtime_t now, dns_ttl_t maxttl,
 	       dns_rdataset_t *addedrdataset);
+isc_result_t
+dns_ncache_addoptout(dns_message_t *message, dns_db_t *cache,
+		     dns_dbnode_t *node, dns_rdatatype_t covers,
+		     isc_stdtime_t now, dns_ttl_t maxttl,
+		     isc_boolean_t optout, dns_rdataset_t *addedrdataset);
 /*%<
  * Convert the authority data from 'message' into a negative cache
  * rdataset, and store it in 'cache' at 'node' with a TTL limited to
@@ -71,6 +76,8 @@ dns_ncache_add(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
  * The 'covers' argument is the RR type whose nonexistence we are caching,
  * or dns_rdatatype_any when caching a NXDOMAIN response.
  *
+ * 'optout' indicates a DNS_RATASETATTR_OPTOUT should be set.
+ *
  * Note:
  *\li	If 'addedrdataset' is not NULL, then it will be attached to the added
  *	rdataset.  See dns_db_addrdataset() for more details.
@@ -154,6 +161,19 @@ dns_ncache_getrdataset(dns_rdataset_t *ncacherdataset, dns_name_t *name,
  *
  */
 
+void
+dns_ncache_current(dns_rdataset_t *ncacherdataset, dns_name_t *found,
+		   dns_rdataset_t *rdataset);
+
+/*%<
+ * Extract the current rdataset and name from a ncache entry.
+ *
+ * Requires:
+ * \li	'ncacherdataset' to be valid and to be a negative cache entry
+ * \li	'found' to be valid.
+ * \li	'rdataset' to be unassociated.
+ */
+
 ISC_LANG_ENDDECLS
 
 #endif /* DNS_NCACHE_H */
diff --git a/contrib/bind9/lib/dns/include/dns/nsec.h b/contrib/bind9/lib/dns/include/dns/nsec.h
index 46b75fa..335a463 100644
--- a/contrib/bind9/lib/dns/include/dns/nsec.h
+++ b/contrib/bind9/lib/dns/include/dns/nsec.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: nsec.h,v 1.4.20.2 2005/04/29 00:16:16 marka Exp $ */
+/* $Id: nsec.h,v 1.12 2008/09/25 04:02:39 tbox Exp $ */
 
 #ifndef DNS_NSEC_H
 #define DNS_NSEC_H 1
 
-/*! \file */
+/*! \file dns/nsec.h */
 
 #include <isc/lang.h>
 
@@ -64,6 +64,17 @@ dns_nsec_typepresent(dns_rdata_t *nsec, dns_rdatatype_t type);
  *\li	'nsec' points to a valid rdataset of type NSEC
  */
 
+isc_result_t
+dns_nsec_nseconly(dns_db_t *db, dns_dbversion_t *version,
+		  isc_boolean_t *answer);
+/*
+ * Report whether the DNSKEY RRset has a NSEC only algorithm.  Unknown
+ * algorithms are assumed to support NSEC3.
+ *
+ * Requires:
+ * 	'answer' to be non NULL.
+ */
+
 ISC_LANG_ENDDECLS
 
 #endif /* DNS_NSEC_H */
diff --git a/contrib/bind9/lib/dns/include/dns/nsec3.h b/contrib/bind9/lib/dns/include/dns/nsec3.h
new file mode 100644
index 0000000..2d6a8dd
--- /dev/null
+++ b/contrib/bind9/lib/dns/include/dns/nsec3.h
@@ -0,0 +1,194 @@
+/*
+ * Copyright (C) 2008, 2009  Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or 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: nsec3.h,v 1.5.48.2 2009/01/18 23:47:41 tbox Exp $ */
+
+#ifndef DNS_NSEC3_H
+#define DNS_NSEC3_H 1
+
+#include <isc/lang.h>
+#include <isc/iterated_hash.h>
+
+#include <dns/db.h>
+#include <dns/diff.h>
+#include <dns/name.h>
+#include <dns/rdatastruct.h>
+#include <dns/types.h>
+
+/*
+ * hash = 1, flags =1, iterations = 2, salt length = 1, salt = 255 (max)
+ * hash length = 1, hash = 255 (max), bitmap = 8192 + 512 (max)
+ */
+#define DNS_NSEC3_BUFFERSIZE (6 + 255 + 255 + 8192 + 512)
+/*
+ * hash = 1, flags = 1, iterations = 2, salt length = 1, salt = 255 (max)
+ */
+#define DNS_NSEC3PARAM_BUFFERSIZE (5 + 255)
+
+/*
+ * Test "unknown" algorithm.  Is mapped to dns_hash_sha1.
+ */
+#define DNS_NSEC3_UNKNOWNALG 245U
+
+ISC_LANG_BEGINDECLS
+
+isc_result_t
+dns_nsec3_buildrdata(dns_db_t *db, dns_dbversion_t *version,
+		     dns_dbnode_t *node, unsigned int hashalg,
+		     unsigned int optin, unsigned int iterations,
+		     const unsigned char *salt, size_t salt_length,
+		     const unsigned char *nexthash, size_t hash_length,
+		     unsigned char *buffer, dns_rdata_t *rdata);
+/*%<
+ * Build the rdata of a NSEC3 record for the data at 'node'.
+ * Note: 'node' is not the node where the NSEC3 record will be stored.
+ *
+ * Requires:
+ *	buffer	Points to a temporary buffer of at least
+ * 		DNS_NSEC_BUFFERSIZE bytes.
+ *	rdata	Points to an initialized dns_rdata_t.
+ *
+ * Ensures:
+ *      *rdata	Contains a valid NSEC3 rdata.  The 'data' member refers
+ *		to 'buffer'.
+ */
+
+isc_boolean_t
+dns_nsec3_typepresent(dns_rdata_t *nsec, dns_rdatatype_t type);
+/*%<
+ * Determine if a type is marked as present in an NSEC3 record.
+ *
+ * Requires:
+ *	'nsec' points to a valid rdataset of type NSEC3
+ */
+
+isc_result_t
+dns_nsec3_hashname(dns_fixedname_t *result,
+		   unsigned char rethash[NSEC3_MAX_HASH_LENGTH],
+		   size_t *hash_length, dns_name_t *name, dns_name_t *origin,
+		   dns_hash_t hashalg, unsigned int iterations,
+		   const unsigned char *salt, size_t saltlength);
+/*%<
+ * Make a hashed domain name from an unhashed one. If rethash is not NULL
+ * the raw hash is stored there.
+ */
+
+unsigned int
+dns_nsec3_hashlength(dns_hash_t hash);
+/*%<
+ * Return the length of the hash produced by the specified algorithm
+ * or zero when unknown.
+ */
+
+isc_boolean_t
+dns_nsec3_supportedhash(dns_hash_t hash);
+/*%<
+ * Return whether we support this hash algorithm or not.
+ */
+
+isc_result_t
+dns_nsec3_addnsec3(dns_db_t *db, dns_dbversion_t *version,
+		   dns_name_t *name, const dns_rdata_nsec3param_t *nsec3param,
+		   dns_ttl_t nsecttl, isc_boolean_t unsecure, dns_diff_t *diff);
+
+isc_result_t
+dns_nsec3_addnsec3s(dns_db_t *db, dns_dbversion_t *version,
+		    dns_name_t *name, dns_ttl_t nsecttl,
+		    isc_boolean_t unsecure, dns_diff_t *diff);
+/*%<
+ * Add NSEC3 records for 'name', recording the change in 'diff'.
+ * Adjust previous NSEC3 records, if any, to reflect the addition.
+ * The existing NSEC3 records are removed.
+ *
+ * dns_nsec3_addnsec3() will only add records to the chain identified by
+ * 'nsec3param'.
+ *
+ * 'unsecure' should be set to reflect if this is a potentially
+ * unsecure delegation (no DS record).
+ *
+ * dns_nsec3_addnsec3s() will examine the NSEC3PARAM RRset to determine which
+ * chains to be updated.  NSEC3PARAM records with the DNS_NSEC3FLAG_CREATE
+ * will be preferentially chosen over NSEC3PARAM records without
+ * DNS_NSEC3FLAG_CREATE set.  NSEC3PARAM records with DNS_NSEC3FLAG_REMOVE
+ * set will be ignored by dns_nsec3_addnsec3s().  If DNS_NSEC3FLAG_CREATE
+ * is set then the new NSEC3 will have OPTOUT set to match the that in the
+ * NSEC3PARAM record otherwise OPTOUT will be inherited from the previous
+ * record in the chain.
+ *
+ * Requires:
+ *	'db' to be valid.
+ *	'version' to be valid or NULL.
+ *	'name' to be valid.
+ *	'nsec3param' to be valid.
+ *	'diff' to be valid.
+ */
+
+isc_result_t
+dns_nsec3_delnsec3(dns_db_t *db, dns_dbversion_t *version, dns_name_t *name,
+		   const dns_rdata_nsec3param_t *nsec3param, dns_diff_t *diff);
+
+isc_result_t
+dns_nsec3_delnsec3s(dns_db_t *db, dns_dbversion_t *version, dns_name_t *name,
+		    dns_diff_t *diff);
+/*%<
+ * Remove NSEC3 records for 'name', recording the change in 'diff'.
+ * Adjust previous NSEC3 records, if any, to reflect the removal.
+ *
+ * dns_nsec3_delnsec3() performs the above for the chain identified by
+ * 'nsec3param'.
+ *
+ * dns_nsec3_delnsec3s() examines the NSEC3PARAM RRset in a similar manner
+ * to dns_nsec3_addnsec3s().  Unlike dns_nsec3_addnsec3s() updated NSEC3
+ * records have the OPTOUT flag preserved.
+ *
+ * Requires:
+ *	'db' to be valid.
+ *	'version' to be valid or NULL.
+ *	'name' to be valid.
+ *	'nsec3param' to be valid.
+ *	'diff' to be valid.
+ */
+
+isc_result_t
+dns_nsec3_active(dns_db_t *db, dns_dbversion_t *version,
+		 isc_boolean_t complete, isc_boolean_t *answer);
+/*%<
+ * Check if there are any complete/to be built NSEC3 chains.
+ * If 'complete' is ISC_TRUE only complete chains will be recognized.
+ *
+ * Requires:
+ *	'db' to be valid.
+ *	'version' to be valid or NULL.
+ *	'answer' to be non NULL.
+ */
+
+isc_result_t
+dns_nsec3_maxiterations(dns_db_t *db, dns_dbversion_t *version,
+			isc_mem_t *mctx, unsigned int *iterationsp);
+/*%<
+ * Find the maximum permissible number of iterations allowed based on
+ * the key strength.
+ *
+ * Requires:
+ *	'db' to be valid.
+ *	'version' to be valid or NULL.
+ *	'mctx' to be valid.
+ *	'iterationsp' to be non NULL.
+ */
+
+ISC_LANG_ENDDECLS
+
+#endif /* DNS_NSEC3_H */
diff --git a/contrib/bind9/lib/dns/include/dns/opcode.h b/contrib/bind9/lib/dns/include/dns/opcode.h
index 4796dba..368b2b2 100644
--- a/contrib/bind9/lib/dns/include/dns/opcode.h
+++ b/contrib/bind9/lib/dns/include/dns/opcode.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: opcode.h,v 1.2.18.2 2005/04/29 00:16:16 marka Exp $ */
+/* $Id: opcode.h,v 1.8 2007/06/19 23:47:17 tbox Exp $ */
 
 #ifndef DNS_OPCODE_H
 #define DNS_OPCODE_H 1
 
-/*! \file */
+/*! \file dns/opcode.h */
 
 #include <isc/lang.h>
 
diff --git a/contrib/bind9/lib/dns/include/dns/order.h b/contrib/bind9/lib/dns/include/dns/order.h
index 6458db0..85663c3 100644
--- a/contrib/bind9/lib/dns/include/dns/order.h
+++ b/contrib/bind9/lib/dns/include/dns/order.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: order.h,v 1.3.18.2 2005/04/29 00:16:17 marka Exp $ */
+/* $Id: order.h,v 1.9 2007/06/19 23:47:17 tbox Exp $ */
 
 #ifndef DNS_ORDER_H
 #define DNS_ORDER_H 1
 
-/*! \file */
+/*! \file dns/order.h */
 
 #include <isc/lang.h>
 #include <isc/types.h>
diff --git a/contrib/bind9/lib/dns/include/dns/peer.h b/contrib/bind9/lib/dns/include/dns/peer.h
index be5a8c3..9e7a188 100644
--- a/contrib/bind9/lib/dns/include/dns/peer.h
+++ b/contrib/bind9/lib/dns/include/dns/peer.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: peer.h,v 1.20.18.8 2006/02/28 03:10:48 marka Exp $ */
+/* $Id: peer.h,v 1.33.118.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef DNS_PEER_H
 #define DNS_PEER_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file dns/peer.h
  * \brief
  * Data structures for peers (e.g. a 'server' config file statement)
  */
@@ -73,11 +73,12 @@ struct dns_peer {
 	isc_boolean_t		provide_ixfr;
 	isc_boolean_t		request_ixfr;
 	isc_boolean_t		support_edns;
+	isc_boolean_t		request_nsid;
 	dns_name_t	       *key;
 	isc_sockaddr_t	       *transfer_source;
-	isc_sockaddr_t	       *notify_source;  
-	isc_sockaddr_t	       *query_source;  
-	isc_uint16_t		udpsize;		/* recieve size */
+	isc_sockaddr_t	       *notify_source;
+	isc_sockaddr_t	       *query_source;
+	isc_uint16_t		udpsize;		/* receive size */
 	isc_uint16_t		maxudp;			/* transmit size */
 
 	isc_uint32_t		bitflags;
@@ -150,6 +151,12 @@ isc_result_t
 dns_peer_getprovideixfr(dns_peer_t *peer, isc_boolean_t *retval);
 
 isc_result_t
+dns_peer_setrequestnsid(dns_peer_t *peer, isc_boolean_t newval);
+
+isc_result_t
+dns_peer_getrequestnsid(dns_peer_t *peer, isc_boolean_t *retval);
+
+isc_result_t
 dns_peer_setsupportedns(dns_peer_t *peer, isc_boolean_t newval);
 
 isc_result_t
diff --git a/contrib/bind9/lib/dns/include/dns/portlist.h b/contrib/bind9/lib/dns/include/dns/portlist.h
index 2d400d4..f76731a 100644
--- a/contrib/bind9/lib/dns/include/dns/portlist.h
+++ b/contrib/bind9/lib/dns/include/dns/portlist.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,9 +15,9 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: portlist.h,v 1.3.18.2 2005/04/29 00:16:17 marka Exp $ */
+/* $Id: portlist.h,v 1.9 2007/06/19 23:47:17 tbox Exp $ */
 
-/*! \file */
+/*! \file dns/portlist.h */
 
 #include <isc/lang.h>
 #include <isc/net.h>
diff --git a/contrib/bind9/lib/dns/include/dns/rbt.h b/contrib/bind9/lib/dns/include/dns/rbt.h
index a1edf0c..6eea787 100644
--- a/contrib/bind9/lib/dns/include/dns/rbt.h
+++ b/contrib/bind9/lib/dns/include/dns/rbt.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rbt.h,v 1.59.18.5 2005/10/13 01:26:07 marka Exp $ */
+/* $Id: rbt.h,v 1.71.48.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef DNS_RBT_H
 #define DNS_RBT_H 1
 
-/*! \file */
+/*! \file dns/rbt.h */
 
 #include <isc/lang.h>
 #include <isc/magic.h>
@@ -37,10 +37,10 @@ ISC_LANG_BEGINDECLS
  * Option values for dns_rbt_findnode() and dns_rbt_findname().
  * These are used to form a bitmask.
  */
-#define DNS_RBTFIND_NOOPTIONS			0x00
-#define DNS_RBTFIND_EMPTYDATA			0x01
-#define DNS_RBTFIND_NOEXACT			0x02
-#define DNS_RBTFIND_NOPREDECESSOR		0x04
+#define DNS_RBTFIND_NOOPTIONS                   0x00
+#define DNS_RBTFIND_EMPTYDATA                   0x01
+#define DNS_RBTFIND_NOEXACT                     0x02
+#define DNS_RBTFIND_NOPREDECESSOR               0x04
 /*@}*/
 
 #ifndef DNS_RBT_USEISCREFCOUNT
@@ -52,14 +52,14 @@ ISC_LANG_BEGINDECLS
 /*
  * These should add up to 30.
  */
-#define DNS_RBT_LOCKLENGTH			10
-#define DNS_RBT_REFLENGTH			20
+#define DNS_RBT_LOCKLENGTH                      10
+#define DNS_RBT_REFLENGTH                       20
 
-#define DNS_RBTNODE_MAGIC		ISC_MAGIC('R','B','N','O')
+#define DNS_RBTNODE_MAGIC               ISC_MAGIC('R','B','N','O')
 #if DNS_RBT_USEMAGIC
-#define DNS_RBTNODE_VALID(n)		ISC_MAGIC_VALID(n, DNS_RBTNODE_MAGIC)
+#define DNS_RBTNODE_VALID(n)            ISC_MAGIC_VALID(n, DNS_RBTNODE_MAGIC)
 #else
-#define DNS_RBTNODE_VALID(n)		ISC_TRUE
+#define DNS_RBTNODE_VALID(n)            ISC_TRUE
 #endif
 
 /*%
@@ -69,22 +69,31 @@ ISC_LANG_BEGINDECLS
  * appended to this structure.  Allocating a contiguous block of memory for
  * multiple dns_rbtnode structures will not work.
  */
-typedef struct dns_rbtnode {
+typedef struct dns_rbtnode dns_rbtnode_t;
+struct dns_rbtnode {
 #if DNS_RBT_USEMAGIC
 	unsigned int magic;
 #endif
-	struct dns_rbtnode *parent;
-	struct dns_rbtnode *left;
-	struct dns_rbtnode *right;
-	struct dns_rbtnode *down;
+	dns_rbtnode_t *parent;
+	dns_rbtnode_t *left;
+	dns_rbtnode_t *right;
+	dns_rbtnode_t *down;
 #ifdef DNS_RBT_USEHASH
-	struct dns_rbtnode *hashnext;
+	dns_rbtnode_t *hashnext;
 #endif
+
+	/*%
+	 * Used for LRU cache.  This linked list is used to mark nodes which
+	 * have no data any longer, but we cannot unlink at that exact moment
+	 * because we did not or could not obtain a write lock on the tree.
+	 */
+	ISC_LINK(dns_rbtnode_t) deadlink;
+
 	/*@{*/
 	/*!
 	 * The following bitfields add up to a total bitwidth of 32.
 	 * The range of values necessary for each item is indicated,
-	 * but in the case of "attributes" the field is wider to accomodate
+	 * but in the case of "attributes" the field is wider to accommodate
 	 * possible future expansion.  "offsetlen" could be one bit
 	 * narrower by always adjusting its value by 1 to find the real
 	 * offsetlen, but doing so does not gain anything (except perhaps
@@ -93,13 +102,14 @@ typedef struct dns_rbtnode {
 	 * In each case below the "range" indicated is what's _necessary_ for
 	 * the bitfield to hold, not what it actually _can_ hold.
 	 */
-	unsigned int is_root : 1;	/*%< range is 0..1 */
-	unsigned int color : 1;		/*%< range is 0..1 */
-	unsigned int find_callback : 1;	/*%< range is 0..1 */
-	unsigned int attributes : 4;	/*%< range is 0..2 */
-	unsigned int namelen : 8;	/*%< range is 1..255 */
-	unsigned int offsetlen : 8;	/*%< range is 1..128 */
-	unsigned int padbytes : 9;	/*%< range is 0..380 */
+	unsigned int is_root : 1;       /*%< range is 0..1 */
+	unsigned int color : 1;         /*%< range is 0..1 */
+	unsigned int find_callback : 1; /*%< range is 0..1 */
+	unsigned int attributes : 3;    /*%< range is 0..2 */
+	unsigned int nsec3 : 1;    	/*%< range is 0..1 */
+	unsigned int namelen : 8;       /*%< range is 1..255 */
+	unsigned int offsetlen : 8;     /*%< range is 1..128 */
+	unsigned int padbytes : 9;      /*%< range is 0..380 */
 	/*@}*/
 
 #ifdef DNS_RBT_USEHASH
@@ -121,14 +131,14 @@ typedef struct dns_rbtnode {
 	isc_refcount_t references; /* note that this is not in the bitfield */
 #endif
 	/*@}*/
-} dns_rbtnode_t;
+};
 
 typedef isc_result_t (*dns_rbtfindcallback_t)(dns_rbtnode_t *node,
 					      dns_name_t *name,
 					      void *callback_arg);
 
 /*****
- *****	Chain Info
+ *****  Chain Info
  *****/
 
 /*!
@@ -145,7 +155,7 @@ typedef isc_result_t (*dns_rbtfindcallback_t)(dns_rbtnode_t *node,
  * tree when a node is added).  The obvious implication of this is that for a
  * chain to remain valid, the tree has to be locked down against writes for the
  * duration of the useful life of the chain, because additions or removals can
- * change the path from the root to the node the chain has targetted.
+ * change the path from the root to the node the chain has targeted.
  *
  * The dns_rbtnodechain_ functions _first, _last, _prev and _next all take
  * dns_name_t parameters for the name and the origin, which can be NULL.  If
@@ -182,15 +192,15 @@ typedef isc_result_t (*dns_rbtfindcallback_t)(dns_rbtnode_t *node,
 #define DNS_RBT_LEVELBLOCK 254
 
 typedef struct dns_rbtnodechain {
-	unsigned int		magic;
-	isc_mem_t *		mctx;
+	unsigned int            magic;
+	isc_mem_t *             mctx;
 	/*%
 	 * The terminal node of the chain.  It is not in levels[].
 	 * This is ostensibly private ... but in a pinch it could be
 	 * used tell that the chain points nowhere without needing to
 	 * call dns_rbtnodechain_current().
 	 */
-	dns_rbtnode_t *		end;
+	dns_rbtnode_t *         end;
 	/*%
 	 * The maximum number of labels in a name is 128; bitstrings mean
 	 * a conceptually very large number (which I have not bothered to
@@ -199,7 +209,7 @@ typedef struct dns_rbtnodechain {
 	 * labels in a name to 255, meaning only 254 pointers are needed
 	 * in the worst case.
 	 */
-	dns_rbtnode_t *		levels[DNS_RBT_LEVELBLOCK];
+	dns_rbtnode_t *         levels[DNS_RBT_LEVELBLOCK];
 	/*%
 	 * level_count indicates how deep the chain points into the
 	 * tree of trees, and is the index into the levels[] array.
@@ -208,7 +218,7 @@ typedef struct dns_rbtnodechain {
 	 * a level_count of 0, the first level has a level_count of 1, and
 	 * so on.
 	 */
-	unsigned int		level_count;
+	unsigned int            level_count;
 	/*%
 	 * level_matches tells how many levels matched above the node
 	 * returned by dns_rbt_findnode().  A match (partial or exact) found
@@ -216,7 +226,7 @@ typedef struct dns_rbtnodechain {
 	 * This is used by the rbtdb to set the start point for a recursive
 	 * search of superdomains until the RR it is looking for is found.
 	 */
-	unsigned int		level_matches;
+	unsigned int            level_matches;
 } dns_rbtnodechain_t;
 
 /*****
@@ -229,27 +239,27 @@ dns_rbt_create(isc_mem_t *mctx, void (*deleter)(void *, void *),
  * Initialize a red-black tree of trees.
  *
  * Notes:
- *\li	The deleter argument, if non-null, points to a function that is
- *	responsible for cleaning up any memory associated with the data
- *	pointer of a node when the node is deleted.  It is passed the
- *	deleted node's data pointer as its first argument and deleter_arg
- *	as its second argument.
+ *\li   The deleter argument, if non-null, points to a function that is
+ *      responsible for cleaning up any memory associated with the data
+ *      pointer of a node when the node is deleted.  It is passed the
+ *      deleted node's data pointer as its first argument and deleter_arg
+ *      as its second argument.
  *
  * Requires:
- * \li	mctx is a pointer to a valid memory context.
- *\li	rbtp != NULL && *rbtp == NULL
- *\li	arg == NULL iff deleter == NULL
+ * \li  mctx is a pointer to a valid memory context.
+ *\li   rbtp != NULL && *rbtp == NULL
+ *\li   arg == NULL iff deleter == NULL
  *
  * Ensures:
- *\li	If result is ISC_R_SUCCESS:
- *		*rbtp points to a valid red-black tree manager
+ *\li   If result is ISC_R_SUCCESS:
+ *              *rbtp points to a valid red-black tree manager
  *
- *\li	If result is failure:
- *		*rbtp does not point to a valid red-black tree manager.
+ *\li   If result is failure:
+ *              *rbtp does not point to a valid red-black tree manager.
  *
  * Returns:
- *\li	#ISC_R_SUCCESS	Success
- *\li	#ISC_R_NOMEMORY	Resource limit: Out of Memory
+ *\li   #ISC_R_SUCCESS  Success
+ *\li   #ISC_R_NOMEMORY Resource limit: Out of Memory
  */
 
 isc_result_t
@@ -258,38 +268,38 @@ dns_rbt_addname(dns_rbt_t *rbt, dns_name_t *name, void *data);
  * Add 'name' to the tree of trees, associated with 'data'.
  *
  * Notes:
- *\li	'data' is never required to be non-NULL, but specifying it
- *	when the name is added is faster than searching for 'name'
- *	again and then setting the data pointer.  The lack of a data pointer
- *	for a node also has other ramifications regarding whether
- *	dns_rbt_findname considers a node to exist, or dns_rbt_deletename
- *	joins nodes.
+ *\li   'data' is never required to be non-NULL, but specifying it
+ *      when the name is added is faster than searching for 'name'
+ *      again and then setting the data pointer.  The lack of a data pointer
+ *      for a node also has other ramifications regarding whether
+ *      dns_rbt_findname considers a node to exist, or dns_rbt_deletename
+ *      joins nodes.
  *
  * Requires:
- *\li	rbt is a valid rbt manager.
- *\li	dns_name_isabsolute(name) == TRUE
+ *\li   rbt is a valid rbt manager.
+ *\li   dns_name_isabsolute(name) == TRUE
  *
  * Ensures:
- *\li	'name' is not altered in any way.
+ *\li   'name' is not altered in any way.
  *
- *\li	Any external references to nodes in the tree are unaffected by
- *	node splits that are necessary to insert the new name.
+ *\li   Any external references to nodes in the tree are unaffected by
+ *      node splits that are necessary to insert the new name.
  *
- *\li	If result is #ISC_R_SUCCESS:
- *		'name' is findable in the red/black tree of trees in O(log N).
- *		The data pointer of the node for 'name' is set to 'data'.
+ *\li   If result is #ISC_R_SUCCESS:
+ *              'name' is findable in the red/black tree of trees in O(log N).
+ *              The data pointer of the node for 'name' is set to 'data'.
  *
- *\li	If result is #ISC_R_EXISTS or #ISC_R_NOSPACE:
- *		The tree of trees is unaltered.
+ *\li   If result is #ISC_R_EXISTS or #ISC_R_NOSPACE:
+ *              The tree of trees is unaltered.
  *
- *\li	If result is #ISC_R_NOMEMORY:
- *		No guarantees.
+ *\li   If result is #ISC_R_NOMEMORY:
+ *              No guarantees.
  *
  * Returns:
- *\li	#ISC_R_SUCCESS	Success
- *\li	#ISC_R_EXISTS	The name already exists with associated data.
- *\li	#ISC_R_NOSPACE 	The name had more logical labels than are allowed.
- *\li	#ISC_R_NOMEMORY	Resource Limit: Out of Memory
+ *\li   #ISC_R_SUCCESS  Success
+ *\li   #ISC_R_EXISTS   The name already exists with associated data.
+ *\li   #ISC_R_NOSPACE  The name had more logical labels than are allowed.
+ *\li   #ISC_R_NOMEMORY Resource Limit: Out of Memory
  */
 
 isc_result_t
@@ -299,31 +309,31 @@ dns_rbt_addnode(dns_rbt_t *rbt, dns_name_t *name, dns_rbtnode_t **nodep);
  * Just like dns_rbt_addname, but returns the address of the node.
  *
  * Requires:
- *\li	rbt is a valid rbt structure.
- *\li	dns_name_isabsolute(name) == TRUE
- *\li	nodep != NULL && *nodep == NULL
+ *\li   rbt is a valid rbt structure.
+ *\li   dns_name_isabsolute(name) == TRUE
+ *\li   nodep != NULL && *nodep == NULL
  *
  * Ensures:
- *\li	'name' is not altered in any way.
+ *\li   'name' is not altered in any way.
  *
- *\li	Any external references to nodes in the tree are unaffected by
- *	node splits that are necessary to insert the new name.
+ *\li   Any external references to nodes in the tree are unaffected by
+ *      node splits that are necessary to insert the new name.
  *
- *\li	If result is ISC_R_SUCCESS:
- *		'name' is findable in the red/black tree of trees in O(log N).
- *		*nodep is the node that was added for 'name'.
+ *\li   If result is ISC_R_SUCCESS:
+ *              'name' is findable in the red/black tree of trees in O(log N).
+ *              *nodep is the node that was added for 'name'.
  *
- *\li	If result is ISC_R_EXISTS:
- *		The tree of trees is unaltered.
- *		*nodep is the existing node for 'name'.
+ *\li   If result is ISC_R_EXISTS:
+ *              The tree of trees is unaltered.
+ *              *nodep is the existing node for 'name'.
  *
- *\li	If result is ISC_R_NOMEMORY:
- *		No guarantees.
+ *\li   If result is ISC_R_NOMEMORY:
+ *              No guarantees.
  *
  * Returns:
- *\li	#ISC_R_SUCCESS	Success
- *\li	#ISC_R_EXISTS	The name already exists, possibly without data.
- *\li	#ISC_R_NOMEMORY	Resource Limit: Out of Memory
+ *\li   #ISC_R_SUCCESS  Success
+ *\li   #ISC_R_EXISTS   The name already exists, possibly without data.
+ *\li   #ISC_R_NOMEMORY Resource Limit: Out of Memory
  */
 
 isc_result_t
@@ -333,36 +343,36 @@ dns_rbt_findname(dns_rbt_t *rbt, dns_name_t *name, unsigned int options,
  * Get the data pointer associated with 'name'.
  *
  * Notes:
- *\li	When #DNS_RBTFIND_NOEXACT is set, the closest matching superdomain is
+ *\li   When #DNS_RBTFIND_NOEXACT is set, the closest matching superdomain is
  *      returned (also subject to #DNS_RBTFIND_EMPTYDATA), even when there is
- *	an exact match in the tree.
+ *      an exact match in the tree.
  *
  *\li   A node that has no data is considered not to exist for this function,
  *      unless the #DNS_RBTFIND_EMPTYDATA option is set.
  *
  * Requires:
- *\li	rbt is a valid rbt manager.
- *\li	dns_name_isabsolute(name) == TRUE
- *\li	data != NULL && *data == NULL
+ *\li   rbt is a valid rbt manager.
+ *\li   dns_name_isabsolute(name) == TRUE
+ *\li   data != NULL && *data == NULL
  *
  * Ensures:
- *\li	'name' and the tree are not altered in any way.
+ *\li   'name' and the tree are not altered in any way.
  *
- *\li	If result is ISC_R_SUCCESS:
- *		*data is the data associated with 'name'.
+ *\li   If result is ISC_R_SUCCESS:
+ *              *data is the data associated with 'name'.
  *
- *\li	If result is DNS_R_PARTIALMATCH:
- *		*data is the data associated with the deepest superdomain
- * 		of 'name' which has data.
+ *\li   If result is DNS_R_PARTIALMATCH:
+ *              *data is the data associated with the deepest superdomain
+ *              of 'name' which has data.
  *
- *\li	If result is ISC_R_NOTFOUND:
- *		Neither the name nor a superdomain was found with data.
+ *\li   If result is ISC_R_NOTFOUND:
+ *              Neither the name nor a superdomain was found with data.
  *
  * Returns:
- *\li	#ISC_R_SUCCESS		Success
- *\li	#DNS_R_PARTIALMATCH	Superdomain found with data
- *\li	#ISC_R_NOTFOUND		No match
- *\li	#ISC_R_NOSPACE		Concatenating nodes to form foundname failed
+ *\li   #ISC_R_SUCCESS          Success
+ *\li   #DNS_R_PARTIALMATCH     Superdomain found with data
+ *\li   #ISC_R_NOTFOUND         No match
+ *\li   #ISC_R_NOSPACE          Concatenating nodes to form foundname failed
  */
 
 isc_result_t
@@ -374,100 +384,100 @@ dns_rbt_findnode(dns_rbt_t *rbt, dns_name_t *name, dns_name_t *foundname,
  * Find the node for 'name'.
  *
  * Notes:
- *\li	A node that has no data is considered not to exist for this function,
- *	unless the DNS_RBTFIND_EMPTYDATA option is set.  This applies to both
- *	exact matches and partial matches.
- *
- *\li	If the chain parameter is non-NULL, then the path through the tree
- *	to the DNSSEC predecessor of the searched for name is maintained,
- *	unless the DNS_RBTFIND_NOPREDECESSOR or DNS_RBTFIND_NOEXACT option
- *	is used. (For more details on those options, see below.)
- *
- *\li	If there is no predecessor, then the chain will point to nowhere, as
- *	indicated by chain->end being NULL or dns_rbtnodechain_current
- *	returning ISC_R_NOTFOUND.  Note that in a normal Internet DNS RBT
- *	there will always be a predecessor for all names except the root
- *	name, because '.' will exist and '.' is the predecessor of
- *	everything.  But you can certainly construct a trivial tree and a
- *	search for it that has no predecessor.
- *
- *\li	Within the chain structure, the 'levels' member of the structure holds
- *	the root node of each level except the first.
- *
- *\li	The 'level_count' of the chain indicates how deep the chain to the
- *	predecessor name is, as an index into the 'levels[]' array.  It does
- *	not count name elements, per se, but only levels of the tree of trees,
- *	the distinction arrising because multiple labels from a name can be
- *	stored on only one level.  It is also does not include the level
- *	that has the node, since that level is not stored in levels[].
- *
- *\li	The chain's 'level_matches' is not directly related to the predecessor.
- *	It is the number of levels above the level of the found 'node',
- *	regardless of whether it was a partial match or exact match.  When
- *	the node is found in the top level tree, or no node is found at all,
- *	level_matches is 0.
- *
- *\li	When DNS_RBTFIND_NOEXACT is set, the closest matching superdomain is
+ *\li   A node that has no data is considered not to exist for this function,
+ *      unless the DNS_RBTFIND_EMPTYDATA option is set.  This applies to both
+ *      exact matches and partial matches.
+ *
+ *\li   If the chain parameter is non-NULL, then the path through the tree
+ *      to the DNSSEC predecessor of the searched for name is maintained,
+ *      unless the DNS_RBTFIND_NOPREDECESSOR or DNS_RBTFIND_NOEXACT option
+ *      is used. (For more details on those options, see below.)
+ *
+ *\li   If there is no predecessor, then the chain will point to nowhere, as
+ *      indicated by chain->end being NULL or dns_rbtnodechain_current
+ *      returning ISC_R_NOTFOUND.  Note that in a normal Internet DNS RBT
+ *      there will always be a predecessor for all names except the root
+ *      name, because '.' will exist and '.' is the predecessor of
+ *      everything.  But you can certainly construct a trivial tree and a
+ *      search for it that has no predecessor.
+ *
+ *\li   Within the chain structure, the 'levels' member of the structure holds
+ *      the root node of each level except the first.
+ *
+ *\li   The 'level_count' of the chain indicates how deep the chain to the
+ *      predecessor name is, as an index into the 'levels[]' array.  It does
+ *      not count name elements, per se, but only levels of the tree of trees,
+ *      the distinction arising because multiple labels from a name can be
+ *      stored on only one level.  It is also does not include the level
+ *      that has the node, since that level is not stored in levels[].
+ *
+ *\li   The chain's 'level_matches' is not directly related to the predecessor.
+ *      It is the number of levels above the level of the found 'node',
+ *      regardless of whether it was a partial match or exact match.  When
+ *      the node is found in the top level tree, or no node is found at all,
+ *      level_matches is 0.
+ *
+ *\li   When DNS_RBTFIND_NOEXACT is set, the closest matching superdomain is
  *      returned (also subject to DNS_RBTFIND_EMPTYDATA), even when
  *      there is an exact match in the tree.  In this case, the chain
- *	will not point to the DNSSEC predecessor, but will instead point
- *	to the exact match, if there was any.  Thus the preceding paragraphs
- *	should have "exact match" substituted for "predecessor" to describe
- *	how the various elements of the chain are set.  This was done to
- * 	ensure that the chain's state was sane, and to prevent problems that
- *	occurred when running the predecessor location code under conditions
- *	it was not designed for.  It is not clear *where* the chain should
- *	point when DNS_RBTFIND_NOEXACT is set, so if you end up using a chain
- *	with this option because you want a particular node, let us know
- *	where you want the chain pointed, so this can be made more firm.
+ *      will not point to the DNSSEC predecessor, but will instead point
+ *      to the exact match, if there was any.  Thus the preceding paragraphs
+ *      should have "exact match" substituted for "predecessor" to describe
+ *      how the various elements of the chain are set.  This was done to
+ *      ensure that the chain's state was sane, and to prevent problems that
+ *      occurred when running the predecessor location code under conditions
+ *      it was not designed for.  It is not clear *where* the chain should
+ *      point when DNS_RBTFIND_NOEXACT is set, so if you end up using a chain
+ *      with this option because you want a particular node, let us know
+ *      where you want the chain pointed, so this can be made more firm.
  *
  * Requires:
- *\li	rbt is a valid rbt manager.
- *\li	dns_name_isabsolute(name) == TRUE.
- *\li	node != NULL && *node == NULL.
- *\li	#DNS_RBTFIND_NOEXACT and DNS_RBTFIND_NOPREDECESSOR are mutally
- *		exclusive.
+ *\li   rbt is a valid rbt manager.
+ *\li   dns_name_isabsolute(name) == TRUE.
+ *\li   node != NULL && *node == NULL.
+ *\li   #DNS_RBTFIND_NOEXACT and DNS_RBTFIND_NOPREDECESSOR are mutually
+ *              exclusive.
  *
  * Ensures:
- *\li	'name' and the tree are not altered in any way.
+ *\li   'name' and the tree are not altered in any way.
  *
- *\li	If result is ISC_R_SUCCESS:
+ *\li   If result is ISC_R_SUCCESS:
  *\verbatim
- *		*node is the terminal node for 'name'.
+ *              *node is the terminal node for 'name'.
 
- *		'foundname' and 'name' represent the same name (though not
- *		the same memory).
+ *              'foundname' and 'name' represent the same name (though not
+ *              the same memory).
 
- *		'chain' points to the DNSSEC predecessor, if any, of 'name'.
+ *              'chain' points to the DNSSEC predecessor, if any, of 'name'.
  *
- *		chain->level_matches and chain->level_count are equal.
+ *              chain->level_matches and chain->level_count are equal.
  *\endverbatim
  *
- * 	If result is DNS_R_PARTIALMATCH:
+ *      If result is DNS_R_PARTIALMATCH:
  *\verbatim
- *		*node is the data associated with the deepest superdomain
- * 		of 'name' which has data.
+ *              *node is the data associated with the deepest superdomain
+ *              of 'name' which has data.
  *
- *		'foundname' is the name of deepest superdomain (which has
- *		data, unless the DNS_RBTFIND_EMPTYDATA option is set).
+ *              'foundname' is the name of deepest superdomain (which has
+ *              data, unless the DNS_RBTFIND_EMPTYDATA option is set).
  *
- *		'chain' points to the DNSSEC predecessor, if any, of 'name'.
+ *              'chain' points to the DNSSEC predecessor, if any, of 'name'.
  *\endverbatim
  *
- *\li	If result is ISC_R_NOTFOUND:
+ *\li   If result is ISC_R_NOTFOUND:
  *\verbatim
- *		Neither the name nor a superdomain was found.  *node is NULL.
+ *              Neither the name nor a superdomain was found.  *node is NULL.
  *
- *		'chain' points to the DNSSEC predecessor, if any, of 'name'.
+ *              'chain' points to the DNSSEC predecessor, if any, of 'name'.
  *
- *		chain->level_matches is 0.
+ *              chain->level_matches is 0.
  *\endverbatim
  *
  * Returns:
- *\li	#ISC_R_SUCCESS		Success
- *\li	#DNS_R_PARTIALMATCH	Superdomain found with data
- *\li	#ISC_R_NOTFOUND		No match, or superdomain with no data
- *\li	#ISC_R_NOSPACE Concatenating nodes to form foundname failed
+ *\li   #ISC_R_SUCCESS          Success
+ *\li   #DNS_R_PARTIALMATCH     Superdomain found with data
+ *\li   #ISC_R_NOTFOUND         No match, or superdomain with no data
+ *\li   #ISC_R_NOSPACE Concatenating nodes to form foundname failed
  */
 
 isc_result_t
@@ -476,41 +486,41 @@ dns_rbt_deletename(dns_rbt_t *rbt, dns_name_t *name, isc_boolean_t recurse);
  * Delete 'name' from the tree of trees.
  *
  * Notes:
- *\li	When 'name' is removed, if recurse is ISC_TRUE then all of its
+ *\li   When 'name' is removed, if recurse is ISC_TRUE then all of its
  *      subnames are removed too.
  *
  * Requires:
- *\li	rbt is a valid rbt manager.
- *\li	dns_name_isabsolute(name) == TRUE
+ *\li   rbt is a valid rbt manager.
+ *\li   dns_name_isabsolute(name) == TRUE
  *
  * Ensures:
- *\li	'name' is not altered in any way.
+ *\li   'name' is not altered in any way.
  *
- *\li	Does NOT ensure that any external references to nodes in the tree
- *	are unaffected by node joins.
+ *\li   Does NOT ensure that any external references to nodes in the tree
+ *      are unaffected by node joins.
  *
- *\li	If result is ISC_R_SUCCESS:
- *		'name' does not appear in the tree with data; however,
- *		the node for the name might still exist which can be
- *		found with dns_rbt_findnode (but not dns_rbt_findname).
+ *\li   If result is ISC_R_SUCCESS:
+ *              'name' does not appear in the tree with data; however,
+ *              the node for the name might still exist which can be
+ *              found with dns_rbt_findnode (but not dns_rbt_findname).
  *
- *\li	If result is ISC_R_NOTFOUND:
- *		'name' does not appear in the tree with data, because
- *		it did not appear in the tree before the function was called.
+ *\li   If result is ISC_R_NOTFOUND:
+ *              'name' does not appear in the tree with data, because
+ *              it did not appear in the tree before the function was called.
  *
- *\li	If result is something else:
- *		See result codes for dns_rbt_findnode (if it fails, the
- *		node is not deleted) or dns_rbt_deletenode (if it fails,
- *		the node is deleted, but the tree is not optimized when
- *		it could have been).
+ *\li   If result is something else:
+ *              See result codes for dns_rbt_findnode (if it fails, the
+ *              node is not deleted) or dns_rbt_deletenode (if it fails,
+ *              the node is deleted, but the tree is not optimized when
+ *              it could have been).
  *
  * Returns:
- *\li	#ISC_R_SUCCESS	Success
- *\li	#ISC_R_NOTFOUND	No match
- *\li	something_else	Any return code from dns_rbt_findnode except
- *			DNS_R_PARTIALMATCH (which causes ISC_R_NOTFOUND
- *			to be returned instead), and any code from
- *			dns_rbt_deletenode.
+ *\li   #ISC_R_SUCCESS  Success
+ *\li   #ISC_R_NOTFOUND No match
+ *\li   something_else  Any return code from dns_rbt_findnode except
+ *                      DNS_R_PARTIALMATCH (which causes ISC_R_NOTFOUND
+ *                      to be returned instead), and any code from
+ *                      dns_rbt_deletenode.
  */
 
 isc_result_t
@@ -519,32 +529,32 @@ dns_rbt_deletenode(dns_rbt_t *rbt, dns_rbtnode_t *node, isc_boolean_t recurse);
  * Delete 'node' from the tree of trees.
  *
  * Notes:
- *\li	When 'node' is removed, if recurse is ISC_TRUE then all nodes
- *	in levels down from it are removed too.
+ *\li   When 'node' is removed, if recurse is ISC_TRUE then all nodes
+ *      in levels down from it are removed too.
  *
  * Requires:
- *\li	rbt is a valid rbt manager.
- *\li	node != NULL.
+ *\li   rbt is a valid rbt manager.
+ *\li   node != NULL.
  *
  * Ensures:
- *\li	Does NOT ensure that any external references to nodes in the tree
- *	are unaffected by node joins.
+ *\li   Does NOT ensure that any external references to nodes in the tree
+ *      are unaffected by node joins.
  *
- *\li	If result is ISC_R_SUCCESS:
- *		'node' does not appear in the tree with data; however,
- *		the node might still exist if it serves as a pointer to
- *		a lower tree level as long as 'recurse' was false, hence
- *		the node could can be found with dns_rbt_findnode whem
- *		that function's empty_data_ok parameter is true.
+ *\li   If result is ISC_R_SUCCESS:
+ *              'node' does not appear in the tree with data; however,
+ *              the node might still exist if it serves as a pointer to
+ *              a lower tree level as long as 'recurse' was false, hence
+ *              the node could can be found with dns_rbt_findnode when
+ *              that function's empty_data_ok parameter is true.
  *
- *\li	If result is ISC_R_NOMEMORY or ISC_R_NOSPACE:
- *		The node was deleted, but the tree structure was not
- *		optimized.
+ *\li   If result is ISC_R_NOMEMORY or ISC_R_NOSPACE:
+ *              The node was deleted, but the tree structure was not
+ *              optimized.
  *
  * Returns:
- *\li	#ISC_R_SUCCESS	Success
- *\li	#ISC_R_NOMEMORY	Resource Limit: Out of Memory when joining nodes.
- *\li	#ISC_R_NOSPACE	dns_name_concatenate failed when joining nodes.
+ *\li   #ISC_R_SUCCESS  Success
+ *\li   #ISC_R_NOMEMORY Resource Limit: Out of Memory when joining nodes.
+ *\li   #ISC_R_NOSPACE  dns_name_concatenate failed when joining nodes.
  */
 
 void
@@ -553,24 +563,24 @@ dns_rbt_namefromnode(dns_rbtnode_t *node, dns_name_t *name);
  * Convert the sequence of labels stored at 'node' into a 'name'.
  *
  * Notes:
- *\li	This function does not return the full name, from the root, but
- *	just the labels at the indicated node.
+ *\li   This function does not return the full name, from the root, but
+ *      just the labels at the indicated node.
  *
- *\li	The name data pointed to by 'name' is the information stored
- *	in the node, not a copy.  Altering the data at this pointer
- *	will likely cause grief.
+ *\li   The name data pointed to by 'name' is the information stored
+ *      in the node, not a copy.  Altering the data at this pointer
+ *      will likely cause grief.
  *
  * Requires:
- * \li	name->offsets == NULL
+ * \li  name->offsets == NULL
  *
  * Ensures:
- * \li	'name' is DNS_NAMEATTR_READONLY.
+ * \li  'name' is DNS_NAMEATTR_READONLY.
  *
- * \li	'name' will point directly to the labels stored after the
- *	dns_rbtnode_t struct.
+ * \li  'name' will point directly to the labels stored after the
+ *      dns_rbtnode_t struct.
  *
- * \li	'name' will have offsets that also point to the information stored
- *	as part of the node.
+ * \li  'name' will have offsets that also point to the information stored
+ *      as part of the node.
  */
 
 isc_result_t
@@ -579,18 +589,18 @@ dns_rbt_fullnamefromnode(dns_rbtnode_t *node, dns_name_t *name);
  * Like dns_rbt_namefromnode, but returns the full name from the root.
  *
  * Notes:
- * \li	Unlike dns_rbt_namefromnode, the name will not point directly
- *	to node data.  Rather, dns_name_concatenate will be used to copy
- *	the name data from each node into the 'name' argument.
+ * \li  Unlike dns_rbt_namefromnode, the name will not point directly
+ *      to node data.  Rather, dns_name_concatenate will be used to copy
+ *      the name data from each node into the 'name' argument.
  *
  * Requires:
- * \li	name != NULL
- * \li	name has a dedicated buffer.
+ * \li  name != NULL
+ * \li  name has a dedicated buffer.
  *
  * Returns:
- * \li	ISC_R_SUCCESS
- * \li	ISC_R_NOSPACE		(possible via dns_name_concatenate)
- * \li	DNS_R_NAMETOOLONG	(possible via dns_name_concatenate)
+ * \li  ISC_R_SUCCESS
+ * \li  ISC_R_NOSPACE           (possible via dns_name_concatenate)
+ * \li  DNS_R_NAMETOOLONG       (possible via dns_name_concatenate)
  */
 
 char *
@@ -600,14 +610,14 @@ dns_rbt_formatnodename(dns_rbtnode_t *node, char *printname,
  * Format the full name of a node for printing, using dns_name_format().
  *
  * Notes:
- * \li	'size' is the length of the printname buffer.  This should be
- *	DNS_NAME_FORMATSIZE or larger.
+ * \li  'size' is the length of the printname buffer.  This should be
+ *      DNS_NAME_FORMATSIZE or larger.
  *
  * Requires:
- * \li	node and printname are not NULL.
+ * \li  node and printname are not NULL.
  *
  * Returns:
- * \li	The 'printname' pointer.
+ * \li  The 'printname' pointer.
  */
 
 unsigned int
@@ -616,7 +626,7 @@ dns_rbt_nodecount(dns_rbt_t *rbt);
  * Obtain the number of nodes in the tree of trees.
  *
  * Requires:
- * \li	rbt is a valid rbt manager.
+ * \li  rbt is a valid rbt manager.
  */
 
 void
@@ -624,25 +634,25 @@ dns_rbt_destroy(dns_rbt_t **rbtp);
 isc_result_t
 dns_rbt_destroy2(dns_rbt_t **rbtp, unsigned int quantum);
 /*%<
- * Stop working with a red-black tree of trees. 
+ * Stop working with a red-black tree of trees.
  * If 'quantum' is zero then the entire tree will be destroyed.
  * If 'quantum' is non zero then up to 'quantum' nodes will be destroyed
  * allowing the rbt to be incrementally destroyed by repeated calls to
  * dns_rbt_destroy2().  Once dns_rbt_destroy2() has been called no other
  * operations than dns_rbt_destroy()/dns_rbt_destroy2() should be
  * performed on the tree of trees.
- * 
+ *
  * Requires:
- * \li	*rbt is a valid rbt manager.
+ * \li  *rbt is a valid rbt manager.
  *
  * Ensures on ISC_R_SUCCESS:
- * \li	All space allocated by the RBT library has been returned.
+ * \li  All space allocated by the RBT library has been returned.
  *
- * \li	*rbt is invalidated as an rbt manager.
+ * \li  *rbt is invalidated as an rbt manager.
  *
  * Returns:
- * \li	ISC_R_SUCCESS
- * \li	ISC_R_QUOTA if 'quantum' nodes have been destroyed.
+ * \li  ISC_R_SUCCESS
+ * \li  ISC_R_QUOTA if 'quantum' nodes have been destroyed.
  */
 
 void
@@ -652,10 +662,10 @@ dns_rbt_printall(dns_rbt_t *rbt);
  * tree of trees.
  *
  * Notes:
- * \li	The name stored at each node, along with the node's color, is printed.
- *	Then the down pointer, left and right pointers are displayed
- *	recursively in turn.  NULL down pointers are silently omitted;
- *	NULL left and right pointers are printed.
+ * \li  The name stored at each node, along with the node's color, is printed.
+ *      Then the down pointer, left and right pointers are displayed
+ *      recursively in turn.  NULL down pointers are silently omitted;
+ *      NULL left and right pointers are printed.
  */
 
 /*****
@@ -668,12 +678,12 @@ dns_rbtnodechain_init(dns_rbtnodechain_t *chain, isc_mem_t *mctx);
  * Initialize 'chain'.
  *
  * Requires:
- *\li	'chain' is a valid pointer.
+ *\li   'chain' is a valid pointer.
  *
- *\li	'mctx' is a valid memory context.
+ *\li   'mctx' is a valid memory context.
  *
  * Ensures:
- *\li	'chain' is suitable for use.
+ *\li   'chain' is suitable for use.
  */
 
 void
@@ -683,10 +693,10 @@ dns_rbtnodechain_reset(dns_rbtnodechain_t *chain);
  * 'chain'.
  *
  * Requires:
- *\li	'chain' is a valid pointer.
+ *\li   'chain' is a valid pointer.
  *
  * Ensures:
- *\li	'chain' is suitable for use, and uses no dynamic storage.
+ *\li   'chain' is suitable for use, and uses no dynamic storage.
  */
 
 void
@@ -695,15 +705,15 @@ dns_rbtnodechain_invalidate(dns_rbtnodechain_t *chain);
  * Free any dynamic storage associated with 'chain', and then invalidates it.
  *
  * Notes:
- *\li 	Future calls to any dns_rbtnodechain_ function will need to call
- * 	dns_rbtnodechain_init on the chain first (except, of course,
- *	dns_rbtnodechain_init itself).
+ *\li   Future calls to any dns_rbtnodechain_ function will need to call
+ *      dns_rbtnodechain_init on the chain first (except, of course,
+ *      dns_rbtnodechain_init itself).
  *
  * Requires:
- *\li	'chain' is a valid chain.
+ *\li   'chain' is a valid chain.
  *
  * Ensures:
- *\li	'chain' is no longer suitable for use, and uses no dynamic storage.
+ *\li   'chain' is no longer suitable for use, and uses no dynamic storage.
  */
 
 isc_result_t
@@ -713,37 +723,37 @@ dns_rbtnodechain_current(dns_rbtnodechain_t *chain, dns_name_t *name,
  * Provide the name, origin and node to which the chain is currently pointed.
  *
  * Notes:
- *\li	The tree need not have be locked against additions for the chain
- *	to remain valid, however there are no guarantees if any deletion
- *	has been made since the chain was established.
+ *\li   The tree need not have be locked against additions for the chain
+ *      to remain valid, however there are no guarantees if any deletion
+ *      has been made since the chain was established.
  *
  * Requires:
- *\li	'chain' is a valid chain.
+ *\li   'chain' is a valid chain.
  *
  * Ensures:
- *\li	'node', if non-NULL, is the node to which the chain was pointed
- *	by dns_rbt_findnode, dns_rbtnodechain_first or dns_rbtnodechain_last.
- *	If none were called for the chain since it was initialized or reset,
- *	or if the was no predecessor to the name searched for with
- *	dns_rbt_findnode, then '*node' is NULL and ISC_R_NOTFOUND is returned.
+ *\li   'node', if non-NULL, is the node to which the chain was pointed
+ *      by dns_rbt_findnode, dns_rbtnodechain_first or dns_rbtnodechain_last.
+ *      If none were called for the chain since it was initialized or reset,
+ *      or if the was no predecessor to the name searched for with
+ *      dns_rbt_findnode, then '*node' is NULL and ISC_R_NOTFOUND is returned.
  *
- *\li	'name', if non-NULL, is the name stored at the terminal level of
- *	the chain.  This is typically a single label, like the "www" of
- *	"www.isc.org", but need not be so.  At the root of the tree of trees,
- *	if the node is "." then 'name' is ".", otherwise it is relative to ".".
- *	(Minimalist and atypical case:  if the tree has just the name
- *	"isc.org." then the root node's stored name is "isc.org." but 'name'
- *	will be "isc.org".)
+ *\li   'name', if non-NULL, is the name stored at the terminal level of
+ *      the chain.  This is typically a single label, like the "www" of
+ *      "www.isc.org", but need not be so.  At the root of the tree of trees,
+ *      if the node is "." then 'name' is ".", otherwise it is relative to ".".
+ *      (Minimalist and atypical case:  if the tree has just the name
+ *      "isc.org." then the root node's stored name is "isc.org." but 'name'
+ *      will be "isc.org".)
  *
- *\li	'origin', if non-NULL, is the sequence of labels in the levels
- *	above the terminal level, such as "isc.org." in the above example.
- *	'origin' is always "." for the root node.
+ *\li   'origin', if non-NULL, is the sequence of labels in the levels
+ *      above the terminal level, such as "isc.org." in the above example.
+ *      'origin' is always "." for the root node.
  *
  *
  * Returns:
- *\li	#ISC_R_SUCCESS		name, origin & node were successfully set.
- *\li	#ISC_R_NOTFOUND		The chain does not point to any node.
- *\li	&lt;something_else>	Any error return from dns_name_concatenate.
+ *\li   #ISC_R_SUCCESS          name, origin & node were successfully set.
+ *\li   #ISC_R_NOTFOUND         The chain does not point to any node.
+ *\li   &lt;something_else>     Any error return from dns_name_concatenate.
  */
 
 isc_result_t
@@ -753,23 +763,23 @@ dns_rbtnodechain_first(dns_rbtnodechain_t *chain, dns_rbt_t *rbt,
  * Set the chain to the lexically first node in the tree of trees.
  *
  * Notes:
- *\li	By the definition of ordering for DNS names, the root of the tree of
- *	trees is the very first node, since everything else in the megatree
- *	uses it as a common suffix.
+ *\li   By the definition of ordering for DNS names, the root of the tree of
+ *      trees is the very first node, since everything else in the megatree
+ *      uses it as a common suffix.
  *
  * Requires:
- *\li	'chain' is a valid chain.
- *\li	'rbt' is a valid rbt manager.
+ *\li   'chain' is a valid chain.
+ *\li   'rbt' is a valid rbt manager.
  *
  * Ensures:
- *\li	The chain points to the very first node of the tree.
+ *\li   The chain points to the very first node of the tree.
  *
- *\li	'name' and 'origin', if non-NULL, are set as described for
- *	dns_rbtnodechain_current.  Thus 'origin' will always be ".".
+ *\li   'name' and 'origin', if non-NULL, are set as described for
+ *      dns_rbtnodechain_current.  Thus 'origin' will always be ".".
  *
  * Returns:
- *\li	#DNS_R_NEWORIGIN		The name & origin were successfully set.
- *\li	&lt;something_else>	Any error result from dns_rbtnodechain_current.
+ *\li   #DNS_R_NEWORIGIN                The name & origin were successfully set.
+ *\li   &lt;something_else>     Any error result from dns_rbtnodechain_current.
  */
 
 isc_result_t
@@ -779,19 +789,19 @@ dns_rbtnodechain_last(dns_rbtnodechain_t *chain, dns_rbt_t *rbt,
  * Set the chain to the lexically last node in the tree of trees.
  *
  * Requires:
- *\li	'chain' is a valid chain.
- *\li	'rbt' is a valid rbt manager.
+ *\li   'chain' is a valid chain.
+ *\li   'rbt' is a valid rbt manager.
  *
  * Ensures:
- *\li	The chain points to the very last node of the tree.
+ *\li   The chain points to the very last node of the tree.
  *
- *\li	'name' and 'origin', if non-NULL, are set as described for
- *	dns_rbtnodechain_current.
+ *\li   'name' and 'origin', if non-NULL, are set as described for
+ *      dns_rbtnodechain_current.
  *
  * Returns:
- *\li	#DNS_R_NEWORIGIN		The name & origin were successfully set.
- *\li	#ISC_R_NOMEMORY		Resource Limit: Out of Memory building chain.
- *\li	&lt;something_else>	Any error result from dns_name_concatenate.
+ *\li   #DNS_R_NEWORIGIN                The name & origin were successfully set.
+ *\li   #ISC_R_NOMEMORY         Resource Limit: Out of Memory building chain.
+ *\li   &lt;something_else>     Any error result from dns_name_concatenate.
  */
 
 isc_result_t
@@ -802,26 +812,26 @@ dns_rbtnodechain_prev(dns_rbtnodechain_t *chain, dns_name_t *name,
  * is currently pointed.
  *
  * Requires:
- *\li	'chain' is a valid chain.
- *\li	'chain' has been pointed somewhere in the tree with dns_rbt_findnode,
- *	dns_rbtnodechain_first or dns_rbtnodechain_last -- and remember that
- *	dns_rbt_findnode is not guaranteed to point the chain somewhere,
- *	since there may have been no predecessor to the searched for name.
+ *\li   'chain' is a valid chain.
+ *\li   'chain' has been pointed somewhere in the tree with dns_rbt_findnode,
+ *      dns_rbtnodechain_first or dns_rbtnodechain_last -- and remember that
+ *      dns_rbt_findnode is not guaranteed to point the chain somewhere,
+ *      since there may have been no predecessor to the searched for name.
  *
  * Ensures:
- *\li	The chain is pointed to the predecessor of its current target.
+ *\li   The chain is pointed to the predecessor of its current target.
  *
- *\li	'name' and 'origin', if non-NULL, are set as described for
- *	dns_rbtnodechain_current.
+ *\li   'name' and 'origin', if non-NULL, are set as described for
+ *      dns_rbtnodechain_current.
  *
- *\li	'origin' is only if a new origin was found.
+ *\li   'origin' is only if a new origin was found.
  *
  * Returns:
- *\li	#ISC_R_SUCCESS		The predecessor was found and 'name' was set.
- *\li	#DNS_R_NEWORIGIN		The predecessor was found with a different
- *				origin and 'name' and 'origin' were set.
- *\li	#ISC_R_NOMORE		There was no predecessor.
- *\li	&lt;something_else>	Any error result from dns_rbtnodechain_current.
+ *\li   #ISC_R_SUCCESS          The predecessor was found and 'name' was set.
+ *\li   #DNS_R_NEWORIGIN                The predecessor was found with a different
+ *                              origin and 'name' and 'origin' were set.
+ *\li   #ISC_R_NOMORE           There was no predecessor.
+ *\li   &lt;something_else>     Any error result from dns_rbtnodechain_current.
  */
 
 isc_result_t
@@ -832,26 +842,39 @@ dns_rbtnodechain_next(dns_rbtnodechain_t *chain, dns_name_t *name,
  * is currently pointed.
  *
  * Requires:
- *\li	'chain' is a valid chain.
- *\li	'chain' has been pointed somewhere in the tree with dns_rbt_findnode,
- *	dns_rbtnodechain_first or dns_rbtnodechain_last -- and remember that
- *	dns_rbt_findnode is not guaranteed to point the chain somewhere,
- *	since there may have been no predecessor to the searched for name.
+ *\li   'chain' is a valid chain.
+ *\li   'chain' has been pointed somewhere in the tree with dns_rbt_findnode,
+ *      dns_rbtnodechain_first or dns_rbtnodechain_last -- and remember that
+ *      dns_rbt_findnode is not guaranteed to point the chain somewhere,
+ *      since there may have been no predecessor to the searched for name.
  *
  * Ensures:
- *\li	The chain is pointed to the successor of its current target.
+ *\li   The chain is pointed to the successor of its current target.
  *
- *\li	'name' and 'origin', if non-NULL, are set as described for
- *	dns_rbtnodechain_current.
+ *\li   'name' and 'origin', if non-NULL, are set as described for
+ *      dns_rbtnodechain_current.
  *
- *\li	'origin' is only if a new origin was found.
+ *\li   'origin' is only if a new origin was found.
  *
  * Returns:
- *\li	#ISC_R_SUCCESS		The successor was found and 'name' was set.
- *\li	#DNS_R_NEWORIGIN		The successor was found with a different
- *				origin and 'name' and 'origin' were set.
- *\li	#ISC_R_NOMORE		There was no successor.
- *\li	&lt;something_else>	Any error result from dns_name_concatenate.
+ *\li   #ISC_R_SUCCESS          The successor was found and 'name' was set.
+ *\li   #DNS_R_NEWORIGIN                The successor was found with a different
+ *                              origin and 'name' and 'origin' were set.
+ *\li   #ISC_R_NOMORE           There was no successor.
+ *\li   &lt;something_else>     Any error result from dns_name_concatenate.
+ */
+
+isc_result_t
+dns_rbtnodechain_down(dns_rbtnodechain_t *chain, dns_name_t *name,
+		      dns_name_t *origin);
+/*%<
+ * Descend down if possible.
+ */
+
+isc_result_t
+dns_rbtnodechain_nextflat(dns_rbtnodechain_t *chain, dns_name_t *name);
+/*%<
+ * Find the next node at the current depth in DNSSEC order.
  */
 
 /*
@@ -862,53 +885,53 @@ dns_rbtnodechain_next(dns_rbtnodechain_t *chain, dns_name_t *name,
  *   hiding the back-end.  The usage is the same as that of isc_refcount_xxx().
  */
 #ifdef DNS_RBT_USEISCREFCOUNT
-#define dns_rbtnode_refinit(node, n)				\
-	do {							\
- 		isc_refcount_init(&(node)->references, (n));	\
-	} while (0) 
-#define dns_rbtnode_refdestroy(node)				\
-	do {							\
-		isc_refcount_destroy(&(node)->references);	\
-	} while (0) 
-#define dns_rbtnode_refcurrent(node)				\
+#define dns_rbtnode_refinit(node, n)                            \
+	do {                                                    \
+		isc_refcount_init(&(node)->references, (n));    \
+	} while (0)
+#define dns_rbtnode_refdestroy(node)                            \
+	do {                                                    \
+		isc_refcount_destroy(&(node)->references);      \
+	} while (0)
+#define dns_rbtnode_refcurrent(node)                            \
 	isc_refcount_current(&(node)->references)
-#define dns_rbtnode_refincrement0(node, refs)			\
-	do {							\
+#define dns_rbtnode_refincrement0(node, refs)                   \
+	do {                                                    \
 		isc_refcount_increment0(&(node)->references, (refs)); \
-	} while (0) 
-#define dns_rbtnode_refincrement(node, refs)			\
-	do {							\
+	} while (0)
+#define dns_rbtnode_refincrement(node, refs)                    \
+	do {                                                    \
 		isc_refcount_increment(&(node)->references, (refs)); \
-	} while (0) 
-#define dns_rbtnode_refdecrement(node, refs)			\
-	do {							\
+	} while (0)
+#define dns_rbtnode_refdecrement(node, refs)                    \
+	do {                                                    \
 		isc_refcount_decrement(&(node)->references, (refs)); \
-	} while (0) 
+	} while (0)
 #else  /* DNS_RBT_USEISCREFCOUNT */
-#define dns_rbtnode_refinit(node, n)	((node)->references = (n))
-#define dns_rbtnode_refdestroy(node)	(REQUIRE((node)->references == 0))
-#define dns_rbtnode_refcurrent(node)	((node)->references)
-#define dns_rbtnode_refincrement0(node, refs)			\
-	do {							\
-		unsigned int *_tmp = (unsigned int *)(refs);	\
-		(node)->references++;				\
-		if ((_tmp) != NULL)				\
-			(*_tmp) = (node)->references;		\
-	} while (0) 
-#define dns_rbtnode_refincrement(node, refs)			\
-	do {							\
-		REQUIRE((node)->references > 0);		\
-		(node)->references++;				\
-		if ((refs) != NULL)				\
-			(*refs) = (node)->references;		\
-	} while (0) 
-#define dns_rbtnode_refdecrement(node, refs)			\
-	do {							\
-		REQUIRE((node)->references > 0);		\
-		(node)->references--;				\
-		if ((refs) != NULL)				\
-			(*refs) = (node)->references;		\
-	} while (0) 
+#define dns_rbtnode_refinit(node, n)    ((node)->references = (n))
+#define dns_rbtnode_refdestroy(node)    (REQUIRE((node)->references == 0))
+#define dns_rbtnode_refcurrent(node)    ((node)->references)
+#define dns_rbtnode_refincrement0(node, refs)                   \
+	do {                                                    \
+		unsigned int *_tmp = (unsigned int *)(refs);    \
+		(node)->references++;                           \
+		if ((_tmp) != NULL)                             \
+			(*_tmp) = (node)->references;           \
+	} while (0)
+#define dns_rbtnode_refincrement(node, refs)                    \
+	do {                                                    \
+		REQUIRE((node)->references > 0);                \
+		(node)->references++;                           \
+		if ((refs) != NULL)                             \
+			(*refs) = (node)->references;           \
+	} while (0)
+#define dns_rbtnode_refdecrement(node, refs)                    \
+	do {                                                    \
+		REQUIRE((node)->references > 0);                \
+		(node)->references--;                           \
+		if ((refs) != NULL)                             \
+			(*refs) = (node)->references;           \
+	} while (0)
 #endif /* DNS_RBT_USEISCREFCOUNT */
 
 ISC_LANG_ENDDECLS
diff --git a/contrib/bind9/lib/dns/include/dns/rcode.h b/contrib/bind9/lib/dns/include/dns/rcode.h
index 03c145b..94e831b 100644
--- a/contrib/bind9/lib/dns/include/dns/rcode.h
+++ b/contrib/bind9/lib/dns/include/dns/rcode.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rcode.h,v 1.13.18.2 2005/04/29 00:16:18 marka Exp $ */
+/* $Id: rcode.h,v 1.21 2008/09/25 04:02:39 tbox Exp $ */
 
 #ifndef DNS_RCODE_H
 #define DNS_RCODE_H 1
 
-/*! \file */
+/*! \file dns/rcode.h */
 
 #include <isc/lang.h>
 
@@ -93,6 +93,21 @@ isc_result_t dns_tsigrcode_totext(dns_rcode_t rcode, isc_buffer_t *target);
  *\li	#ISC_R_NOSPACE			target buffer is too small
  */
 
+isc_result_t
+dns_hashalg_fromtext(unsigned char *hashalg, isc_textregion_t *source);
+/*%<
+ * Convert the text 'source' refers to into a has algorithm value.
+ *
+ * Requires:
+ *\li	'hashalg' is a valid pointer.
+ *
+ *\li	'source' is a valid text region.
+ *
+ * Returns:
+ *\li	#ISC_R_SUCCESS			on success
+ *\li	#DNS_R_UNKNOWN			type is unknown
+ */
+
 ISC_LANG_ENDDECLS
 
 #endif /* DNS_RCODE_H */
diff --git a/contrib/bind9/lib/dns/include/dns/rdata.h b/contrib/bind9/lib/dns/include/dns/rdata.h
index a14bde7..126bc96 100644
--- a/contrib/bind9/lib/dns/include/dns/rdata.h
+++ b/contrib/bind9/lib/dns/include/dns/rdata.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdata.h,v 1.60.18.3 2005/05/19 04:59:56 marka Exp $ */
+/* $Id: rdata.h,v 1.70.120.3 2009/02/16 00:29:27 marka Exp $ */
 
 #ifndef DNS_RDATA_H
 #define DNS_RDATA_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file dns/rdata.h
  * \brief
  * Provides facilities for manipulating DNS rdata, including conversions to
  * and from wire format and text format.
@@ -49,7 +49,7 @@
  *	build process from a set of source files, one per rdata type.  For
  *	portability, it's probably best that the building be done by a C
  *	program.  Adding a new rdata type will be a simple matter of adding
- *	a file to a directory and rebuilding the server.  *All* knowlege of
+ *	a file to a directory and rebuilding the server.  *All* knowledge of
  *	the format of a particular rdata type is in this file.
  *
  * MP:
@@ -124,7 +124,8 @@ struct dns_rdata {
 
 #define DNS_RDATA_INIT { NULL, 0, 0, 0, 0, {(void*)(-1), (void *)(-1)}}
 
-#define DNS_RDATA_UPDATE	0x0001		/*%< update pseudo record */
+#define DNS_RDATA_UPDATE	0x0001		/*%< update pseudo record. */
+#define DNS_RDATA_OFFLINE	0x0002		/*%< RRSIG has a offline key. */
 
 /*
  * Flags affecting rdata formatting style.  Flags 0xFFFF0000
@@ -327,11 +328,11 @@ dns_rdata_fromtext(dns_rdata_t *rdata, dns_rdataclass_t rdclass,
  *\li	'target' is a valid region.
  *
  *\li	'origin' if non NULL it must be absolute.
- *	
+ *
  *\li	'callbacks' to be NULL or callbacks->warn and callbacks->error be
  *	initialized.
  *
- * Ensures, 
+ * Ensures,
  *	if result is success:
  *\li	 	If 'rdata' is not NULL, it is attached to the target.
 
@@ -384,7 +385,8 @@ dns_rdata_totext(dns_rdata_t *rdata, dns_name_t *origin, isc_buffer_t *target);
 
 isc_result_t
 dns_rdata_tofmttext(dns_rdata_t *rdata, dns_name_t *origin, unsigned int flags,
-		    unsigned int width, char *linebreak, isc_buffer_t *target);
+		    unsigned int width, const char *linebreak,
+		    isc_buffer_t *target);
 /*%<
  * Like dns_rdata_totext, but do formatted output suitable for
  * database dumps.  This is intended for use by dns_db_dump();
diff --git a/contrib/bind9/lib/dns/include/dns/rdataclass.h b/contrib/bind9/lib/dns/include/dns/rdataclass.h
index fc622bf..786eb6a 100644
--- a/contrib/bind9/lib/dns/include/dns/rdataclass.h
+++ b/contrib/bind9/lib/dns/include/dns/rdataclass.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdataclass.h,v 1.18.18.2 2005/04/29 00:16:18 marka Exp $ */
+/* $Id: rdataclass.h,v 1.24 2007/06/19 23:47:17 tbox Exp $ */
 
 #ifndef DNS_RDATACLASS_H
 #define DNS_RDATACLASS_H 1
 
-/*! \file */
+/*! \file dns/rdataclass.h */
 
 #include <isc/lang.h>
 
diff --git a/contrib/bind9/lib/dns/include/dns/rdatalist.h b/contrib/bind9/lib/dns/include/dns/rdatalist.h
index 697386f..57debc3 100644
--- a/contrib/bind9/lib/dns/include/dns/rdatalist.h
+++ b/contrib/bind9/lib/dns/include/dns/rdatalist.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdatalist.h,v 1.14.18.2 2005/04/29 00:16:19 marka Exp $ */
+/* $Id: rdatalist.h,v 1.22 2008/04/03 06:09:05 tbox Exp $ */
 
 #ifndef DNS_RDATALIST_H
 #define DNS_RDATALIST_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file dns/rdatalist.h
  * \brief
  * A DNS rdatalist is a list of rdata of a common type and class.
  *
@@ -98,6 +98,27 @@ dns_rdatalist_tordataset(dns_rdatalist_t *rdatalist,
  *\li	#ISC_R_SUCCESS
  */
 
+isc_result_t
+dns_rdatalist_fromrdataset(dns_rdataset_t *rdataset,
+			   dns_rdatalist_t **rdatalist);
+/*%<
+ * Point 'rdatalist' to the rdatalist in 'rdataset'.
+ *
+ * Requires:
+ *
+ *\li	'rdatalist' is a pointer to a NULL dns_rdatalist_t pointer.
+ *
+ *\li	'rdataset' is a valid rdataset associated with an rdatalist.
+ *
+ * Ensures,
+ *	on success,
+ *
+ *\li		'rdatalist' is pointed to the rdatalist in rdataset.
+ *
+ * Returns:
+ *\li	#ISC_R_SUCCESS
+ */
+
 ISC_LANG_ENDDECLS
 
 #endif /* DNS_RDATALIST_H */
diff --git a/contrib/bind9/lib/dns/include/dns/rdataset.h b/contrib/bind9/lib/dns/include/dns/rdataset.h
index 5597591..baff146 100644
--- a/contrib/bind9/lib/dns/include/dns/rdataset.h
+++ b/contrib/bind9/lib/dns/include/dns/rdataset.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdataset.h,v 1.51.18.7 2006/03/03 00:56:53 marka Exp $ */
+/* $Id: rdataset.h,v 1.65.50.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef DNS_RDATASET_H
 #define DNS_RDATASET_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file dns/rdataset.h
  * \brief
  * A DNS rdataset is a handle that can be associated with a collection of
  * rdata all having a common owner name, class, and type.
@@ -78,8 +78,14 @@ typedef struct dns_rdatasetmethods {
 					      dns_name_t *name);
 	isc_result_t		(*getnoqname)(dns_rdataset_t *rdataset,
 					      dns_name_t *name,
-					      dns_rdataset_t *nsec,
-					      dns_rdataset_t *nsecsig);
+					      dns_rdataset_t *neg,
+					      dns_rdataset_t *negsig);
+	isc_result_t		(*addclosest)(dns_rdataset_t *rdataset,
+					      dns_name_t *name);
+	isc_result_t		(*getclosest)(dns_rdataset_t *rdataset,
+					      dns_name_t *name,
+					      dns_rdataset_t *neg,
+					      dns_rdataset_t *negsig);
 	isc_result_t		(*getadditional)(dns_rdataset_t *rdataset,
 						 dns_rdatasetadditional_t type,
 						 dns_rdatatype_t qtype,
@@ -140,6 +146,11 @@ struct dns_rdataset {
 	 * increment the counter.
 	 */
 	isc_uint32_t			count;
+	/*
+	 * This RRSIG RRset should be re-generated around this time.
+	 * Only valid if DNS_RDATASETATTR_RESIGN is set in attributes.
+	 */
+	isc_stdtime_t			resign;
 	/*@{*/
 	/*%
 	 * These are for use by the rdataset implementation, and MUST NOT
@@ -151,7 +162,9 @@ struct dns_rdataset {
 	unsigned int			privateuint4;
 	void *				private5;
 	void *				private6;
+	void *				private7;
 	/*@}*/
+
 };
 
 /*!
@@ -184,6 +197,9 @@ struct dns_rdataset {
 #define DNS_RDATASETATTR_CHECKNAMES	0x00008000	/*%< Used by resolver. */
 #define DNS_RDATASETATTR_REQUIREDGLUE	0x00010000
 #define DNS_RDATASETATTR_LOADORDER	0x00020000
+#define DNS_RDATASETATTR_RESIGN		0x00040000
+#define DNS_RDATASETATTR_CLOSEST	0x00080000
+#define DNS_RDATASETATTR_OPTOUT		0x00100000	/*%< OPTOUT proof */
 
 /*%
  * _OMITDNSSEC:
@@ -348,8 +364,8 @@ dns_rdataset_totext(dns_rdataset_t *rdataset,
  * Notes:
  *\li	The rdata cursor position will be changed.
  *
- *\li	The 'question' flag should normally be #ISC_FALSE.  If it is 
- *	#ISC_TRUE, the TTL and rdata fields are not printed.  This is 
+ *\li	The 'question' flag should normally be #ISC_FALSE.  If it is
+ *	#ISC_TRUE, the TTL and rdata fields are not printed.  This is
  *	for use when printing an rdata representing a question section.
  *
  *\li	This interface is deprecated; use dns_master_rdatasettottext()
@@ -411,7 +427,7 @@ dns_rdataset_towiresorted(dns_rdataset_t *rdataset,
 			  unsigned int *countp);
 /*%<
  * Like dns_rdataset_towire(), but sorting the rdatasets according to
- * the integer value returned by 'order' when called witih the rdataset
+ * the integer value returned by 'order' when called with the rdataset
  * and 'order_arg' as arguments.
  *
  * Requires:
@@ -477,14 +493,14 @@ dns_rdataset_additionaldata(dns_rdataset_t *rdataset,
 
 isc_result_t
 dns_rdataset_getnoqname(dns_rdataset_t *rdataset, dns_name_t *name,
-			dns_rdataset_t *nsec, dns_rdataset_t *nsecsig);
+			dns_rdataset_t *neg, dns_rdataset_t *negsig);
 /*%<
  * Return the noqname proof for this record.
  *
  * Requires:
  *\li	'rdataset' to be valid and #DNS_RDATASETATTR_NOQNAME to be set.
  *\li	'name' to be valid.
- *\li	'nsec' and 'nsecsig' to be valid and not associated.
+ *\li	'neg' and 'negsig' to be valid and not associated.
  */
 
 isc_result_t
@@ -493,11 +509,37 @@ dns_rdataset_addnoqname(dns_rdataset_t *rdataset, dns_name_t *name);
  * Associate a noqname proof with this record.
  * Sets #DNS_RDATASETATTR_NOQNAME if successful.
  * Adjusts the 'rdataset->ttl' to minimum of the 'rdataset->ttl' and
- * the 'nsec' and 'rrsig(nsec)' ttl.
+ * the 'nsec'/'nsec3' and 'rrsig(nsec)'/'rrsig(nsec3)' ttl.
  *
  * Requires:
  *\li	'rdataset' to be valid and #DNS_RDATASETATTR_NOQNAME to be set.
- *\li	'name' to be valid and have NSEC and RRSIG(NSEC) rdatasets.
+ *\li	'name' to be valid and have NSEC or NSEC3 and associated RRSIG
+ *	 rdatasets.
+ */
+
+isc_result_t
+dns_rdataset_getclosest(dns_rdataset_t *rdataset, dns_name_t *name,
+			dns_rdataset_t *nsec, dns_rdataset_t *nsecsig);
+/*%<
+ * Return the closest encloser for this record.
+ *
+ * Requires:
+ *\li	'rdataset' to be valid and #DNS_RDATASETATTR_CLOSEST to be set.
+ *\li	'name' to be valid.
+ *\li	'nsec' and 'nsecsig' to be valid and not associated.
+ */
+
+isc_result_t
+dns_rdataset_addclosest(dns_rdataset_t *rdataset, dns_name_t *name);
+/*%<
+ * Associate a closest encloset proof with this record.
+ * Sets #DNS_RDATASETATTR_CLOSEST if successful.
+ * Adjusts the 'rdataset->ttl' to minimum of the 'rdataset->ttl' and
+ * the 'nsec' and 'rrsig(nsec)' ttl.
+ *
+ * Requires:
+ *\li	'rdataset' to be valid and #DNS_RDATASETATTR_CLOSEST to be set.
+ *\li	'name' to be valid and have NSEC3 and RRSIG(NSEC3) rdatasets.
  */
 
 isc_result_t
diff --git a/contrib/bind9/lib/dns/include/dns/rdatasetiter.h b/contrib/bind9/lib/dns/include/dns/rdatasetiter.h
index b2e13f8..dcde367 100644
--- a/contrib/bind9/lib/dns/include/dns/rdatasetiter.h
+++ b/contrib/bind9/lib/dns/include/dns/rdatasetiter.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdatasetiter.h,v 1.15.18.2 2005/04/29 00:16:19 marka Exp $ */
+/* $Id: rdatasetiter.h,v 1.21 2007/06/19 23:47:17 tbox Exp $ */
 
 #ifndef DNS_RDATASETITER_H
 #define DNS_RDATASETITER_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file dns/rdatasetiter.h
  * \brief
  * The DNS Rdataset Iterator interface allows iteration of all of the
  * rdatasets at a node.
diff --git a/contrib/bind9/lib/dns/include/dns/rdataslab.h b/contrib/bind9/lib/dns/include/dns/rdataslab.h
index b693a71..3ac44b8 100644
--- a/contrib/bind9/lib/dns/include/dns/rdataslab.h
+++ b/contrib/bind9/lib/dns/include/dns/rdataslab.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdataslab.h,v 1.25.18.2 2005/04/29 00:16:19 marka Exp $ */
+/* $Id: rdataslab.h,v 1.33 2008/04/01 23:47:10 tbox Exp $ */
 
 #ifndef DNS_RDATASLAB_H
 #define DNS_RDATASLAB_H 1
 
-/*! \file
+/*! \file dns/rdataslab.h
  * \brief
  * Implements storage of rdatasets into slabs of memory.
  *
@@ -57,6 +57,13 @@ ISC_LANG_BEGINDECLS
 #define DNS_RDATASLAB_FORCE 0x1
 #define DNS_RDATASLAB_EXACT 0x2
 
+#define DNS_RDATASLAB_OFFLINE 0x01 	/* RRSIG is for offline DNSKEY */
+#define DNS_RDATASLAB_WARNMASK 0x0E	/*%< RRSIG(DNSKEY) expired
+					 * warnings number mask. */
+#define DNS_RDATASLAB_WARNSHIFT 1	/*%< How many bits to shift to find
+					 * remaining expired warning number. */
+
+
 /***
  *** Functions
  ***/
@@ -146,10 +153,10 @@ dns_rdataslab_equal(unsigned char *slab1, unsigned char *slab2,
  */
 isc_boolean_t
 dns_rdataslab_equalx(unsigned char *slab1, unsigned char *slab2,
-		     unsigned int reservelen, dns_rdataclass_t rdclass, 
+		     unsigned int reservelen, dns_rdataclass_t rdclass,
 		     dns_rdatatype_t type);
 /*%<
- * Compare two rdataslabs for DNSSEC equality. 
+ * Compare two rdataslabs for DNSSEC equality.
  *
  * Requires:
  *\li	'slab1' and 'slab2' point to slabs.
diff --git a/contrib/bind9/lib/dns/include/dns/rdatatype.h b/contrib/bind9/lib/dns/include/dns/rdatatype.h
index 40a884d..ba9a92c 100644
--- a/contrib/bind9/lib/dns/include/dns/rdatatype.h
+++ b/contrib/bind9/lib/dns/include/dns/rdatatype.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdatatype.h,v 1.18.18.2 2005/04/29 00:16:20 marka Exp $ */
+/* $Id: rdatatype.h,v 1.26 2008/09/25 04:02:39 tbox Exp $ */
 
 #ifndef DNS_RDATATYPE_H
 #define DNS_RDATATYPE_H 1
 
-/*! \file */
+/*! \file dns/rdatatype.h */
 
 #include <isc/lang.h>
 
@@ -71,7 +71,8 @@ dns_rdatatype_format(dns_rdatatype_t rdtype,
  * The resulting string is guaranteed to be null-terminated.
  */
 
-#define DNS_RDATATYPE_FORMATSIZE sizeof("TYPE65535")
+#define DNS_RDATATYPE_FORMATSIZE sizeof("NSEC3PARAM")
+
 /*%<
  * Minimum size of array to pass to dns_rdatatype_format().
  * May need to be adjusted if a new RR type with a very long
diff --git a/contrib/bind9/lib/dns/include/dns/request.h b/contrib/bind9/lib/dns/include/dns/request.h
index b858a9e..62a83ca 100644
--- a/contrib/bind9/lib/dns/include/dns/request.h
+++ b/contrib/bind9/lib/dns/include/dns/request.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: request.h,v 1.21.18.2 2005/04/29 00:16:20 marka Exp $ */
+/* $Id: request.h,v 1.27.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef DNS_REQUEST_H
 #define DNS_REQUEST_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file dns/request.h
  *
  * \brief
  * The request module provides simple request/response services useful for
@@ -49,7 +49,7 @@
 #define DNS_REQUESTOPT_TCP 0x00000001U
 
 typedef struct dns_requestevent {
-        ISC_EVENT_COMMON(struct dns_requestevent);
+	ISC_EVENT_COMMON(struct dns_requestevent);
 	isc_result_t result;
 	dns_request_t *request;
 } dns_requestevent_t;
@@ -217,7 +217,7 @@ dns_request_createvia3(dns_requestmgr_t *requestmgr, dns_message_t *message,
 		       unsigned int udpretries, isc_task_t *task,
 		       isc_taskaction_t action, void *arg,
 		       dns_request_t **requestp);
-/*%< 
+/*%<
  * Create and send a request.
  *
  * Notes:
@@ -271,7 +271,7 @@ dns_request_createraw3(dns_requestmgr_t *requestmgr, isc_buffer_t *msgbuf,
 		       unsigned int udptimeout, unsigned int udpretries,
 		       isc_task_t *task, isc_taskaction_t action, void *arg,
 		       dns_request_t **requestp);
-/*!< 
+/*!<
  * \brief Create and send a request.
  *
  * Notes:
@@ -280,7 +280,7 @@ dns_request_createraw3(dns_requestmgr_t *requestmgr, isc_buffer_t *msgbuf,
  *	#DNS_REQUESTOPT_TCP option is set, TCP will be used.  The request
  *	will timeout after 'timeout' seconds.   UDP requests will be resent
  *	at 'udptimeout' intervals if non-zero or if 'udpretries' is not zero.
- *	
+ *
  *\li	When the request completes, successfully, due to a timeout, or
  *	because it was canceled, a completion event will be sent to 'task'.
  *
@@ -344,7 +344,7 @@ dns_request_usedtcp(dns_request_t *request);
 /*%<
  * Return whether this query used TCP or not.  Setting #DNS_REQUESTOPT_TCP
  * in the call to dns_request_create() will cause the function to return
- * #ISC_TRUE, othewise the result is based on the query message size.
+ * #ISC_TRUE, otherwise the result is based on the query message size.
  *
  * Requires:
  *\li	'request' is a valid request.
diff --git a/contrib/bind9/lib/dns/include/dns/resolver.h b/contrib/bind9/lib/dns/include/dns/resolver.h
index 4e0e6a0..fa837c1 100644
--- a/contrib/bind9/lib/dns/include/dns/resolver.h
+++ b/contrib/bind9/lib/dns/include/dns/resolver.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: resolver.h,v 1.40.18.11 2006/02/01 22:39:17 marka Exp $ */
+/* $Id: resolver.h,v 1.60.56.3 2009/01/29 22:40:35 jinmei Exp $ */
 
 #ifndef DNS_RESOLVER_H
 #define DNS_RESOLVER_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file dns/resolver.h
  *
  * \brief
  * This is the BIND 9 resolver, the module responsible for resolving DNS
@@ -93,13 +93,29 @@ typedef struct dns_fetchevent {
 #define DNS_FETCHOPT_FORWARDONLY	0x10	     /*%< Only use forwarders. */
 #define DNS_FETCHOPT_NOVALIDATE		0x20	     /*%< Disable validation. */
 #define DNS_FETCHOPT_EDNS512		0x40	     /*%< Advertise a 512 byte
-						          UDP buffer. */
+							  UDP buffer. */
+#define DNS_FETCHOPT_WANTNSID           0x80         /*%< Request NSID */
 
 #define	DNS_FETCHOPT_EDNSVERSIONSET	0x00800000
 #define	DNS_FETCHOPT_EDNSVERSIONMASK	0xff000000
 #define	DNS_FETCHOPT_EDNSVERSIONSHIFT	24
 
 /*
+ * Upper bounds of class of query RTT (ms).  Corresponds to
+ * dns_resstatscounter_queryrttX statistics counters.
+ */
+#define DNS_RESOLVER_QRYRTTCLASS0	10
+#define DNS_RESOLVER_QRYRTTCLASS0STR	"10"
+#define DNS_RESOLVER_QRYRTTCLASS1	100
+#define DNS_RESOLVER_QRYRTTCLASS1STR	"100"
+#define DNS_RESOLVER_QRYRTTCLASS2	500
+#define DNS_RESOLVER_QRYRTTCLASS2STR	"500"
+#define DNS_RESOLVER_QRYRTTCLASS3	800
+#define DNS_RESOLVER_QRYRTTCLASS3STR	"800"
+#define DNS_RESOLVER_QRYRTTCLASS4	1600
+#define DNS_RESOLVER_QRYRTTCLASS4STR	"1600"
+
+/*
  * XXXRTH  Should this API be made semi-private?  (I.e.
  * _dns_resolver_create()).
  */
@@ -126,8 +142,6 @@ dns_resolver_create(dns_view_t *view,
  *\li	Generally, applications should not create a resolver directly, but
  *	should instead call dns_view_createresolver().
  *
- *\li	No options are currently defined.
- *
  * Requires:
  *
  *\li	'view' is a valid view.
@@ -348,6 +362,23 @@ dns_resolver_destroyfetch(dns_fetch_t **fetchp);
  *\li	*fetchp == NULL.
  */
 
+void
+dns_resolver_logfetch(dns_fetch_t *fetch, isc_log_t *lctx,
+		      isc_logcategory_t *category, isc_logmodule_t *module,
+		      int level, isc_boolean_t duplicateok);
+/*%<
+ * Dump a log message on internal state at the completion of given 'fetch'.
+ * 'lctx', 'category', 'module', and 'level' are used to write the log message.
+ * By default, only one log message is written even if the corresponding fetch
+ * context serves multiple clients; if 'duplicateok' is true the suppression
+ * is disabled and the message can be written every time this function is
+ * called.
+ *
+ * Requires:
+ *
+ *\li	'fetch' is a valid fetch, and has completed.
+ */
+
 dns_dispatchmgr_t *
 dns_resolver_dispatchmgr(dns_resolver_t *resolver);
 
@@ -470,10 +501,13 @@ dns_resolver_getclientsperquery(dns_resolver_t *resolver, isc_uint32_t *cur,
 
 isc_boolean_t
 dns_resolver_getzeronosoattl(dns_resolver_t *resolver);
- 
+
 void
 dns_resolver_setzeronosoattl(dns_resolver_t *resolver, isc_boolean_t state);
 
+unsigned int
+dns_resolver_getoptions(dns_resolver_t *resolver);
+
 ISC_LANG_ENDDECLS
 
 #endif /* DNS_RESOLVER_H */
diff --git a/contrib/bind9/lib/dns/include/dns/result.h b/contrib/bind9/lib/dns/include/dns/result.h
index db5481b..ed29bcd 100644
--- a/contrib/bind9/lib/dns/include/dns/result.h
+++ b/contrib/bind9/lib/dns/include/dns/result.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: result.h,v 1.104.10.6 2005/06/17 02:04:32 marka Exp $ */
+/* $Id: result.h,v 1.116 2008/09/25 04:02:39 tbox Exp $ */
 
 #ifndef DNS_RESULT_H
 #define DNS_RESULT_H 1
 
-/*! \file */
+/*! \file dns/result.h */
 
 #include <isc/lang.h>
 #include <isc/resultclass.h>
@@ -147,8 +147,9 @@
 #define DNS_R_COVERINGNSEC		(ISC_RESULTCLASS_DNS + 101)
 #define DNS_R_MXISADDRESS		(ISC_RESULTCLASS_DNS + 102)
 #define DNS_R_DUPLICATE			(ISC_RESULTCLASS_DNS + 103)
+#define DNS_R_INVALIDNSEC3		(ISC_RESULTCLASS_DNS + 104)
 
-#define DNS_R_NRESULTS			104	/*%< Number of results */
+#define DNS_R_NRESULTS			105	/*%< Number of results */
 
 /*
  * DNS wire format rcodes.
diff --git a/contrib/bind9/lib/dns/include/dns/rootns.h b/contrib/bind9/lib/dns/include/dns/rootns.h
index a3ddc48..6da3f79 100644
--- a/contrib/bind9/lib/dns/include/dns/rootns.h
+++ b/contrib/bind9/lib/dns/include/dns/rootns.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rootns.h,v 1.9.18.3 2005/04/27 05:01:38 sra Exp $ */
+/* $Id: rootns.h,v 1.16 2007/06/19 23:47:17 tbox Exp $ */
 
 #ifndef DNS_ROOTNS_H
 #define DNS_ROOTNS_H 1
 
-/*! \file */
+/*! \file dns/rootns.h */
 
 #include <isc/lang.h>
 
diff --git a/contrib/bind9/lib/dns/include/dns/sdb.h b/contrib/bind9/lib/dns/include/dns/sdb.h
index de849f9..c850028 100644
--- a/contrib/bind9/lib/dns/include/dns/sdb.h
+++ b/contrib/bind9/lib/dns/include/dns/sdb.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: sdb.h,v 1.15.18.2 2005/04/29 00:16:21 marka Exp $ */
+/* $Id: sdb.h,v 1.21.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef DNS_SDB_H
 #define DNS_SDB_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file dns/sdb.h
  * \brief
  * Simple database API.
  */
@@ -127,12 +127,12 @@ dns_sdb_register(const char *drivername, const dns_sdbmethods_t *methods,
  * The allnodes function, if non-NULL, fills in an opaque structure to be
  * used by a database iterator.  This allows the zone to be transferred.
  * This may use a considerable amount of memory for large zones, and the
- * zone transfer may not be fully RFC1035 compliant if the zone is 
+ * zone transfer may not be fully RFC1035 compliant if the zone is
  * frequently changed.
  *
  * The create function will be called for each zone configured
  * into the name server using this database type.  It can be used
- * to create a "database object" containg zone specific data,
+ * to create a "database object" containing zone specific data,
  * which can make use of the database arguments specified in the
  * name server configuration.
  *
diff --git a/contrib/bind9/lib/dns/include/dns/sdlz.h b/contrib/bind9/lib/dns/include/dns/sdlz.h
index 13ba14a..acb0437 100644
--- a/contrib/bind9/lib/dns/include/dns/sdlz.h
+++ b/contrib/bind9/lib/dns/include/dns/sdlz.h
@@ -1,8 +1,8 @@
 /*
- * Portions Copyright (C) 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2005-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -50,9 +50,9 @@
  * USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: sdlz.h,v 1.2.2.2 2005/09/06 03:47:19 marka Exp $ */
+/* $Id: sdlz.h,v 1.7.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
-/*! \file */
+/*! \file dns/sdlz.h */
 
 #ifndef SDLZ_H
 #define SDLZ_H 1
@@ -148,7 +148,7 @@ typedef void
 /*%<
  * Method prototype.  Drivers implementing the SDLZ interface may
  * supply a destroy method.  This method is called when the DNS server
- * is shuting down and no longer needs the driver.  A SDLZ driver does
+ * is shutting down and no longer needs the driver.  A SDLZ driver does
  * not have to implement a destroy method.
  */
 
@@ -173,7 +173,7 @@ typedef isc_result_t
  * \li	3) we run out of domain name labels. I.E. we have tried the
  *	   shortest domain name
  *
- * \li	4) the number of labels in the domain name is less than min_lables
+ * \li	4) the number of labels in the domain name is less than min_labels
  *	   for dns_dlzfindzone
  *
  * The driver's find zone method should return ISC_R_SUCCESS if the
diff --git a/contrib/bind9/lib/dns/include/dns/secalg.h b/contrib/bind9/lib/dns/include/dns/secalg.h
index 0466d91..2e4fe3e 100644
--- a/contrib/bind9/lib/dns/include/dns/secalg.h
+++ b/contrib/bind9/lib/dns/include/dns/secalg.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: secalg.h,v 1.13.18.2 2005/04/29 00:16:21 marka Exp $ */
+/* $Id: secalg.h,v 1.19 2007/06/19 23:47:17 tbox Exp $ */
 
 #ifndef DNS_SECALG_H
 #define DNS_SECALG_H 1
 
-/*! \file */
+/*! \file dns/secalg.h */
 
 #include <isc/lang.h>
 
diff --git a/contrib/bind9/lib/dns/include/dns/secproto.h b/contrib/bind9/lib/dns/include/dns/secproto.h
index a6cfd5c..b9179c0 100644
--- a/contrib/bind9/lib/dns/include/dns/secproto.h
+++ b/contrib/bind9/lib/dns/include/dns/secproto.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: secproto.h,v 1.10.18.2 2005/04/29 00:16:21 marka Exp $ */
+/* $Id: secproto.h,v 1.16 2007/06/19 23:47:17 tbox Exp $ */
 
 #ifndef DNS_SECPROTO_H
 #define DNS_SECPROTO_H 1
 
-/*! \file */
+/*! \file dns/secproto.h */
 
 #include <isc/lang.h>
 
diff --git a/contrib/bind9/lib/dns/include/dns/soa.h b/contrib/bind9/lib/dns/include/dns/soa.h
index 70c6725..bb56365 100644
--- a/contrib/bind9/lib/dns/include/dns/soa.h
+++ b/contrib/bind9/lib/dns/include/dns/soa.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: soa.h,v 1.3.18.2 2005/04/29 00:16:22 marka Exp $ */
+/* $Id: soa.h,v 1.9 2007/06/19 23:47:17 tbox Exp $ */
 
 #ifndef DNS_SOA_H
 #define DNS_SOA_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file dns/soa.h
  * \brief
  * SOA utilities.
  */
diff --git a/contrib/bind9/lib/dns/include/dns/ssu.h b/contrib/bind9/lib/dns/include/dns/ssu.h
index b709030..f013bd0 100644
--- a/contrib/bind9/lib/dns/include/dns/ssu.h
+++ b/contrib/bind9/lib/dns/include/dns/ssu.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ssu.h,v 1.13.18.4 2006/02/16 23:51:32 marka Exp $ */
+/* $Id: ssu.h,v 1.24 2008/01/18 23:46:58 tbox Exp $ */
 
 #ifndef DNS_SSU_H
 #define DNS_SSU_H 1
 
-/*! \file */
+/*! \file dns/ssu.h */
 
 #include <isc/lang.h>
 
@@ -28,14 +28,19 @@
 
 ISC_LANG_BEGINDECLS
 
-#define DNS_SSUMATCHTYPE_NAME 0
-#define DNS_SSUMATCHTYPE_SUBDOMAIN 1
-#define DNS_SSUMATCHTYPE_WILDCARD 2
-#define DNS_SSUMATCHTYPE_SELF 3
-#define DNS_SSUMATCHTYPE_SELFSUB 4
-#define DNS_SSUMATCHTYPE_SELFWILD 5
-#define DNS_SSUMATCHTYPE_MAX 5		/* maximum defined value */
-
+#define DNS_SSUMATCHTYPE_NAME		0
+#define DNS_SSUMATCHTYPE_SUBDOMAIN	1
+#define DNS_SSUMATCHTYPE_WILDCARD	2
+#define DNS_SSUMATCHTYPE_SELF		3
+#define DNS_SSUMATCHTYPE_SELFSUB	4
+#define DNS_SSUMATCHTYPE_SELFWILD	5
+#define DNS_SSUMATCHTYPE_SELFKRB5	6
+#define DNS_SSUMATCHTYPE_SELFMS		7
+#define DNS_SSUMATCHTYPE_SUBDOMAINMS	8
+#define DNS_SSUMATCHTYPE_SUBDOMAINKRB5	9
+#define DNS_SSUMATCHTYPE_TCPSELF	10
+#define DNS_SSUMATCHTYPE_6TO4SELF	11
+#define DNS_SSUMATCHTYPE_MAX 		11  /* max value */
 
 isc_result_t
 dns_ssutable_create(isc_mem_t *mctx, dns_ssutable_t **table);
@@ -91,8 +96,8 @@ dns_ssutable_addrule(dns_ssutable_t *table, isc_boolean_t grant,
  *	at that name.
  *
  *	Notes:
- *\li		If 'matchtype' is SELF, this rule only matches if the name
- *		to be updated matches the signing identity.
+ *\li		If 'matchtype' is of SELF type, this rule only matches if the
+ *              name to be updated matches the signing identity.
  *
  *\li		If 'ntypes' is 0, this rule applies to all types except
  *		NS, SOA, RRSIG, and NSEC.
@@ -114,16 +119,35 @@ dns_ssutable_addrule(dns_ssutable_t *table, isc_boolean_t grant,
 
 isc_boolean_t
 dns_ssutable_checkrules(dns_ssutable_t *table, dns_name_t *signer,
-			dns_name_t *name, dns_rdatatype_t type);
+			dns_name_t *name, isc_netaddr_t *tcpaddr,
+			dns_rdatatype_t type);
 /*%<
  *	Checks that the attempted update of (name, type) is allowed according
  *	to the rules specified in the simple-secure-update rule table.  If
- *	no rules are matched, access is denied.  If signer is NULL, access
- *	is denied.
+ *	no rules are matched, access is denied.
+ *
+ *	Notes:
+ *		'tcpaddr' should only be set if the request received
+ *		via TCP.  This provides a weak assurance that the
+ *		request was not spoofed.  'tcpaddr' is to to validate
+ *		DNS_SSUMATCHTYPE_TCPSELF and DNS_SSUMATCHTYPE_6TO4SELF
+ *		rules.
+ *
+ *		For DNS_SSUMATCHTYPE_TCPSELF the addresses are mapped to
+ *		the standard reverse names under IN-ADDR.ARPA and IP6.ARPA.
+ *		RFC 1035, Section 3.5, "IN-ADDR.ARPA domain" and RFC 3596,
+ *		Section 2.5, "IP6.ARPA Domain".
+ *
+ *		For DNS_SSUMATCHTYPE_6TO4SELF, IPv4 address are converted
+ *		to a 6to4 prefix (48 bits) per the rules in RFC 3056.  Only
+ *		the top	48 bits of the IPv6 address are mapped to the reverse
+ *		name. This is independent of whether the most significant 16
+ *		bits match 2002::/16, assigned for 6to4 prefixes, or not.
  *
  *	Requires:
  *\li		'table' is a valid SSU table
  *\li		'signer' is NULL or a valid absolute name
+ *\li		'tcpaddr' is NULL or a valid network address.
  *\li		'name' is a valid absolute name
  */
 
diff --git a/contrib/bind9/lib/dns/include/dns/stats.h b/contrib/bind9/lib/dns/include/dns/stats.h
index 6cd95ac..0b35aa8 100644
--- a/contrib/bind9/lib/dns/include/dns/stats.h
+++ b/contrib/bind9/lib/dns/include/dns/stats.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,19 +15,77 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: stats.h,v 1.5.18.4 2005/06/27 00:20:03 marka Exp $ */
+/* $Id: stats.h,v 1.18.56.2 2009/01/29 23:47:44 tbox Exp $ */
 
 #ifndef DNS_STATS_H
 #define DNS_STATS_H 1
 
-/*! \file */
+/*! \file dns/stats.h */
 
 #include <dns/types.h>
 
 /*%
- * Query statistics counter types.
+ * Statistics counters.  Used as isc_statscounter_t values.
  */
-typedef enum {
+enum {
+	/*%
+	 * Resolver statistics counters.
+	 */
+	dns_resstatscounter_queryv4 = 0,
+	dns_resstatscounter_queryv6 = 1,
+	dns_resstatscounter_responsev4 = 2,
+	dns_resstatscounter_responsev6 = 3,
+	dns_resstatscounter_nxdomain = 4,
+	dns_resstatscounter_servfail = 5,
+	dns_resstatscounter_formerr = 6,
+	dns_resstatscounter_othererror = 7,
+	dns_resstatscounter_edns0fail = 8,
+	dns_resstatscounter_mismatch = 9,
+	dns_resstatscounter_truncated = 10,
+	dns_resstatscounter_lame = 11,
+	dns_resstatscounter_retry = 12,
+	dns_resstatscounter_gluefetchv4 = 13,
+	dns_resstatscounter_gluefetchv6 = 14,
+	dns_resstatscounter_gluefetchv4fail = 15,
+	dns_resstatscounter_gluefetchv6fail = 16,
+	dns_resstatscounter_val = 17,
+	dns_resstatscounter_valsuccess = 18,
+	dns_resstatscounter_valnegsuccess = 19,
+	dns_resstatscounter_valfail = 20,
+	dns_resstatscounter_dispabort = 21,
+	dns_resstatscounter_dispsockfail = 22,
+	dns_resstatscounter_querytimeout = 23,
+	dns_resstatscounter_queryrtt0 = 24,
+	dns_resstatscounter_queryrtt1 = 25,
+	dns_resstatscounter_queryrtt2 = 26,
+	dns_resstatscounter_queryrtt3 = 27,
+	dns_resstatscounter_queryrtt4 = 28,
+	dns_resstatscounter_queryrtt5 = 29,
+
+	dns_resstatscounter_max = 30,
+
+	/*%
+	 * Zone statistics counters.
+	 */
+	dns_zonestatscounter_notifyoutv4 = 0,
+	dns_zonestatscounter_notifyoutv6 = 1,
+	dns_zonestatscounter_notifyinv4 = 2,
+	dns_zonestatscounter_notifyinv6 = 3,
+	dns_zonestatscounter_notifyrej = 4,
+	dns_zonestatscounter_soaoutv4 = 5,
+	dns_zonestatscounter_soaoutv6 = 6,
+	dns_zonestatscounter_axfrreqv4 = 7,
+	dns_zonestatscounter_axfrreqv6 = 8,
+	dns_zonestatscounter_ixfrreqv4 = 9,
+	dns_zonestatscounter_ixfrreqv6 = 10,
+	dns_zonestatscounter_xfrsuccess = 11,
+	dns_zonestatscounter_xfrfail = 12,
+
+	dns_zonestatscounter_max = 13,
+
+	/*%
+	* Query statistics counters (obsolete).
+	*/
 	dns_statscounter_success = 0,    /*%< Successful lookup */
 	dns_statscounter_referral = 1,   /*%< Referral result */
 	dns_statscounter_nxrrset = 2,    /*%< NXRRSET result */
@@ -35,18 +93,261 @@ typedef enum {
 	dns_statscounter_recursion = 4,  /*%< Recursion was used */
 	dns_statscounter_failure = 5,    /*%< Some other failure */
 	dns_statscounter_duplicate = 6,  /*%< Duplicate query */
-	dns_statscounter_dropped = 7     /*%< Duplicate query */
-} dns_statscounter_t;
+	dns_statscounter_dropped = 7	 /*%< Duplicate query (dropped) */
+};
 
 #define DNS_STATS_NCOUNTERS 8
 
+#if 0
+/*%<
+ * Flag(s) for dns_xxxstats_dump().  DNS_STATSDUMP_VERBOSE is obsolete.
+ * ISC_STATSDUMP_VERBOSE should be used instead.  These two values are
+ * intentionally defined to be the same value to ensure binary compatibility.
+ */
+#define DNS_STATSDUMP_VERBOSE	0x00000001 /*%< dump 0-value counters */
+#endif
+
+/*%<
+ * (Obsoleted)
+ */
 LIBDNS_EXTERNAL_DATA extern const char *dns_statscounter_names[];
 
+/*%
+ * Attributes for statistics counters of RRset and Rdatatype types.
+ *
+ * _OTHERTYPE
+ *	The rdata type is not explicitly supported and the corresponding counter
+ *	is counted for other such types, too.  When this attribute is set,
+ *	the base type is of no use.
+ *
+ * _NXRRSET
+ * 	RRset type counters only.  Indicates the RRset is non existent.
+ *
+ * _NXDOMAIN
+ *	RRset type counters only.  Indicates a non existent name.  When this
+ *	attribute is set, the base type is of no use.
+ */
+#define DNS_RDATASTATSTYPE_ATTR_OTHERTYPE	0x0001
+#define DNS_RDATASTATSTYPE_ATTR_NXRRSET		0x0002
+#define DNS_RDATASTATSTYPE_ATTR_NXDOMAIN	0x0004
+
+/*%<
+ * Conversion macros among dns_rdatatype_t, attributes and isc_statscounter_t.
+ */
+#define DNS_RDATASTATSTYPE_BASE(type)	((dns_rdatatype_t)((type) & 0xFFFF))
+#define DNS_RDATASTATSTYPE_ATTR(type)	((type) >> 16)
+#define DNS_RDATASTATSTYPE_VALUE(b, a)	(((a) << 16) | (b))
+
+/*%<
+ * Types of dump callbacks.
+ */
+typedef void (*dns_generalstats_dumper_t)(isc_statscounter_t, isc_uint64_t,
+					  void *);
+typedef void (*dns_rdatatypestats_dumper_t)(dns_rdatastatstype_t, isc_uint64_t,
+					    void *);
+typedef void (*dns_opcodestats_dumper_t)(dns_opcode_t, isc_uint64_t, void *);
+
+isc_result_t
+dns_generalstats_create(isc_mem_t *mctx, dns_stats_t **statsp, int ncounters);
+/*%<
+ * Create a statistics counter structure of general type.  It counts a general
+ * set of counters indexed by an ID between 0 and ncounters -1.
+ * This function is obsolete.  A more general function, isc_stats_create(),
+ * should be used.
+ *
+ * Requires:
+ *\li	'mctx' must be a valid memory context.
+ *
+ *\li	'statsp' != NULL && '*statsp' == NULL.
+ *
+ * Returns:
+ *\li	ISC_R_SUCCESS	-- all ok
+ *
+ *\li	anything else	-- failure
+ */
+
+isc_result_t
+dns_rdatatypestats_create(isc_mem_t *mctx, dns_stats_t **statsp);
+/*%<
+ * Create a statistics counter structure per rdatatype.
+ *
+ * Requires:
+ *\li	'mctx' must be a valid memory context.
+ *
+ *\li	'statsp' != NULL && '*statsp' == NULL.
+ *
+ * Returns:
+ *\li	ISC_R_SUCCESS	-- all ok
+ *
+ *\li	anything else	-- failure
+ */
+
+isc_result_t
+dns_rdatasetstats_create(isc_mem_t *mctx, dns_stats_t **statsp);
+/*%<
+ * Create a statistics counter structure per RRset.
+ *
+ * Requires:
+ *\li	'mctx' must be a valid memory context.
+ *
+ *\li	'statsp' != NULL && '*statsp' == NULL.
+ *
+ * Returns:
+ *\li	ISC_R_SUCCESS	-- all ok
+ *
+ *\li	anything else	-- failure
+ */
+
+isc_result_t
+dns_opcodestats_create(isc_mem_t *mctx, dns_stats_t **statsp);
+/*%<
+ * Create a statistics counter structure per opcode.
+ *
+ * Requires:
+ *\li	'mctx' must be a valid memory context.
+ *
+ *\li	'statsp' != NULL && '*statsp' == NULL.
+ *
+ * Returns:
+ *\li	ISC_R_SUCCESS	-- all ok
+ *
+ *\li	anything else	-- failure
+ */
+
+void
+dns_stats_attach(dns_stats_t *stats, dns_stats_t **statsp);
+/*%<
+ * Attach to a statistics set.
+ *
+ * Requires:
+ *\li	'stats' is a valid dns_stats_t.
+ *
+ *\li	'statsp' != NULL && '*statsp' == NULL
+ */
+
+void
+dns_stats_detach(dns_stats_t **statsp);
+/*%<
+ * Detaches from the statistics set.
+ *
+ * Requires:
+ *\li	'statsp' != NULL and '*statsp' is a valid dns_stats_t.
+ */
+
+void
+dns_generalstats_increment(dns_stats_t *stats, isc_statscounter_t counter);
+/*%<
+ * Increment the counter-th counter of stats.  This function is obsolete.
+ * A more general function, isc_stats_increment(), should be used.
+ *
+ * Requires:
+ *\li	'stats' is a valid dns_stats_t created by dns_generalstats_create().
+ *
+ *\li	counter is less than the maximum available ID for the stats specified
+ *	on creation.
+ */
+
+void
+dns_rdatatypestats_increment(dns_stats_t *stats, dns_rdatatype_t type);
+/*%<
+ * Increment the statistics counter for 'type'.
+ *
+ * Requires:
+ *\li	'stats' is a valid dns_stats_t created by dns_rdatatypestats_create().
+ */
+
+void
+dns_rdatasetstats_increment(dns_stats_t *stats, dns_rdatastatstype_t rrsettype);
+/*%<
+ * Increment the statistics counter for 'rrsettype'.
+ *
+ * Requires:
+ *\li	'stats' is a valid dns_stats_t created by dns_rdatasetstats_create().
+ */
+
+void
+dns_rdatasetstats_decrement(dns_stats_t *stats, dns_rdatastatstype_t rrsettype);
+/*%<
+ * Decrement the statistics counter for 'rrsettype'.
+ *
+ * Requires:
+ *\li	'stats' is a valid dns_stats_t created by dns_rdatasetstats_create().
+ */
+
+void
+dns_opcodestats_increment(dns_stats_t *stats, dns_opcode_t code);
+/*%<
+ * Increment the statistics counter for 'code'.
+ *
+ * Requires:
+ *\li	'stats' is a valid dns_stats_t created by dns_opcodestats_create().
+ */
+
+void
+dns_generalstats_dump(dns_stats_t *stats, dns_generalstats_dumper_t dump_fn,
+		      void *arg, unsigned int options);
+/*%<
+ * Dump the current statistics counters in a specified way.  For each counter
+ * in stats, dump_fn is called with its current value and the given argument
+ * arg.  By default counters that have a value of 0 is skipped; if options has
+ * the ISC_STATSDUMP_VERBOSE flag, even such counters are dumped.
+ *
+ * This function is obsolete.  A more general function, isc_stats_dump(),
+ * should be used.
+ *
+ * Requires:
+ *\li	'stats' is a valid dns_stats_t created by dns_generalstats_create().
+ */
+
+void
+dns_rdatatypestats_dump(dns_stats_t *stats, dns_rdatatypestats_dumper_t dump_fn,
+			void *arg, unsigned int options);
+/*%<
+ * Dump the current statistics counters in a specified way.  For each counter
+ * in stats, dump_fn is called with the corresponding type in the form of
+ * dns_rdatastatstype_t, the current counter value and the given argument
+ * arg.  By default counters that have a value of 0 is skipped; if options has
+ * the ISC_STATSDUMP_VERBOSE flag, even such counters are dumped.
+ *
+ * Requires:
+ *\li	'stats' is a valid dns_stats_t created by dns_generalstats_create().
+ */
+
+void
+dns_rdatasetstats_dump(dns_stats_t *stats, dns_rdatatypestats_dumper_t dump_fn,
+		       void *arg, unsigned int options);
+/*%<
+ * Dump the current statistics counters in a specified way.  For each counter
+ * in stats, dump_fn is called with the corresponding type in the form of
+ * dns_rdatastatstype_t, the current counter value and the given argument
+ * arg.  By default counters that have a value of 0 is skipped; if options has
+ * the ISC_STATSDUMP_VERBOSE flag, even such counters are dumped.
+ *
+ * Requires:
+ *\li	'stats' is a valid dns_stats_t created by dns_generalstats_create().
+ */
+
+void
+dns_opcodestats_dump(dns_stats_t *stats, dns_opcodestats_dumper_t dump_fn,
+		     void *arg, unsigned int options);
+/*%<
+ * Dump the current statistics counters in a specified way.  For each counter
+ * in stats, dump_fn is called with the corresponding opcode, the current
+ * counter value and the given argument arg.  By default counters that have a
+ * value of 0 is skipped; if options has the ISC_STATSDUMP_VERBOSE flag, even
+ * such counters are dumped.
+ *
+ * Requires:
+ *\li	'stats' is a valid dns_stats_t created by dns_generalstats_create().
+ */
+
 isc_result_t
 dns_stats_alloccounters(isc_mem_t *mctx, isc_uint64_t **ctrp);
 /*%<
  * Allocate an array of query statistics counters from the memory
  * context 'mctx'.
+ *
+ * This function is obsoleted.  Use dns_xxxstats_create() instead.
  */
 
 void
@@ -54,6 +355,8 @@ dns_stats_freecounters(isc_mem_t *mctx, isc_uint64_t **ctrp);
 /*%<
  * Free an array of query statistics counters allocated from the memory
  * context 'mctx'.
+ *
+ * This function is obsoleted.  Use dns_stats_destroy() instead.
  */
 
 ISC_LANG_ENDDECLS
diff --git a/contrib/bind9/lib/dns/include/dns/tcpmsg.h b/contrib/bind9/lib/dns/include/dns/tcpmsg.h
index 075f463..fe83c53 100644
--- a/contrib/bind9/lib/dns/include/dns/tcpmsg.h
+++ b/contrib/bind9/lib/dns/include/dns/tcpmsg.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: tcpmsg.h,v 1.16.18.2 2005/04/29 00:16:22 marka Exp $ */
+/* $Id: tcpmsg.h,v 1.22 2007/06/19 23:47:17 tbox Exp $ */
 
 #ifndef DNS_TCPMSG_H
 #define DNS_TCPMSG_H 1
 
-/*! \file */
+/*! \file dns/tcpmsg.h */
 
 #include <isc/buffer.h>
 #include <isc/lang.h>
diff --git a/contrib/bind9/lib/dns/include/dns/time.h b/contrib/bind9/lib/dns/include/dns/time.h
index 9e8f5cc..5b47d11 100644
--- a/contrib/bind9/lib/dns/include/dns/time.h
+++ b/contrib/bind9/lib/dns/include/dns/time.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: time.h,v 1.11.18.2 2005/04/29 00:16:23 marka Exp $ */
+/* $Id: time.h,v 1.17 2007/06/19 23:47:17 tbox Exp $ */
 
 #ifndef DNS_TIME_H
 #define DNS_TIME_H 1
 
-/*! \file */
+/*! \file dns/time.h */
 
 /***
  ***	Imports
diff --git a/contrib/bind9/lib/dns/include/dns/timer.h b/contrib/bind9/lib/dns/include/dns/timer.h
index cd936a0..48d6d56 100644
--- a/contrib/bind9/lib/dns/include/dns/timer.h
+++ b/contrib/bind9/lib/dns/include/dns/timer.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: timer.h,v 1.3.18.2 2005/04/29 00:16:23 marka Exp $ */
+/* $Id: timer.h,v 1.9 2007/06/19 23:47:17 tbox Exp $ */
 
 #ifndef DNS_TIMER_H
 #define DNS_TIMER_H 1
 
-/*! \file */
+/*! \file dns/timer.h */
 
 /***
  ***	Imports
diff --git a/contrib/bind9/lib/dns/include/dns/tkey.h b/contrib/bind9/lib/dns/include/dns/tkey.h
index 4e3e80a..3511f2f 100644
--- a/contrib/bind9/lib/dns/include/dns/tkey.h
+++ b/contrib/bind9/lib/dns/include/dns/tkey.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,18 +15,19 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: tkey.h,v 1.19.18.2 2005/04/29 00:16:23 marka Exp $ */
+/* $Id: tkey.h,v 1.26.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef DNS_TKEY_H
 #define DNS_TKEY_H 1
 
-/*! \file */
+/*! \file dns/tkey.h */
 
 #include <isc/lang.h>
 
 #include <dns/types.h>
 
 #include <dst/dst.h>
+#include <dst/gssapi.h>
 
 ISC_LANG_BEGINDECLS
 
@@ -40,13 +41,14 @@ ISC_LANG_BEGINDECLS
 struct dns_tkeyctx {
 	dst_key_t *dhkey;
 	dns_name_t *domain;
-	void *gsscred;
+	gss_cred_id_t gsscred;
 	isc_mem_t *mctx;
 	isc_entropy_t *ectx;
 };
 
 isc_result_t
-dns_tkeyctx_create(isc_mem_t *mctx, isc_entropy_t *ectx, dns_tkeyctx_t **tctxp);
+dns_tkeyctx_create(isc_mem_t *mctx, isc_entropy_t *ectx,
+		   dns_tkeyctx_t **tctxp);
 /*%<
  *	Create an empty TKEY context.
  *
@@ -119,13 +121,29 @@ dns_tkey_builddhquery(dns_message_t *msg, dst_key_t *key, dns_name_t *name,
  */
 
 isc_result_t
-dns_tkey_buildgssquery(dns_message_t *msg, dns_name_t *name,
-		       dns_name_t *gname, void *cred,
-		       isc_uint32_t lifetime, void **context);
+dns_tkey_buildgssquery(dns_message_t *msg, dns_name_t *name, dns_name_t *gname,
+		       isc_buffer_t *intoken, isc_uint32_t lifetime,
+		       gss_ctx_id_t *context, isc_boolean_t win2k);
 /*%<
- * XXX
+ *	Builds a query containing a TKEY that will generate a GSSAPI context.
+ *	The key is requested to have the specified lifetime (in seconds).
+ *
+ *	Requires:
+ *\li		'msg'	  is a valid message
+ *\li		'name'	  is a valid name
+ *\li		'gname'	  is a valid name
+ *\li		'context' is a pointer to a valid gss_ctx_id_t
+ *			  (which may have the value GSS_C_NO_CONTEXT)
+ *\li		'win2k'   when true says to turn on some hacks to work
+ *			  with the non-standard GSS-TSIG of Windows 2000
+ *
+ *	Returns:
+ *\li		ISC_R_SUCCESS	msg was successfully updated to include the
+ *				query to be sent
+ *\li		other		an error occurred while building the message
  */
 
+
 isc_result_t
 dns_tkey_builddeletequery(dns_message_t *msg, dns_tsigkey_t *key);
 /*%<
@@ -144,7 +162,7 @@ dns_tkey_builddeletequery(dns_message_t *msg, dns_tsigkey_t *key);
 
 isc_result_t
 dns_tkey_processdhresponse(dns_message_t *qmsg, dns_message_t *rmsg,
-                           dst_key_t *key, isc_buffer_t *nonce,
+			   dst_key_t *key, isc_buffer_t *nonce,
 			   dns_tsigkey_t **outkey, dns_tsig_keyring_t *ring);
 /*%<
  *	Processes a response to a query containing a TKEY that was
@@ -167,8 +185,9 @@ dns_tkey_processdhresponse(dns_message_t *qmsg, dns_message_t *rmsg,
 
 isc_result_t
 dns_tkey_processgssresponse(dns_message_t *qmsg, dns_message_t *rmsg,
-			    dns_name_t *gname, void *cred, void **context,
-			    dns_tsigkey_t **outkey, dns_tsig_keyring_t *ring);
+			    dns_name_t *gname, gss_ctx_id_t *context,
+			    isc_buffer_t *outtoken, dns_tsigkey_t **outkey,
+			    dns_tsig_keyring_t *ring);
 /*%<
  * XXX
  */
@@ -193,6 +212,39 @@ dns_tkey_processdeleteresponse(dns_message_t *qmsg, dns_message_t *rmsg,
  */
 
 
+isc_result_t
+dns_tkey_gssnegotiate(dns_message_t *qmsg, dns_message_t *rmsg,
+		      dns_name_t *server, gss_ctx_id_t *context,
+		      dns_tsigkey_t **outkey, dns_tsig_keyring_t *ring,
+		      isc_boolean_t win2k);
+
+/*
+ *	Client side negotiation of GSS-TSIG.  Process the response
+ *	to a TKEY, and establish a TSIG key if negotiation was successful.
+ *	Build a response to the input TKEY message.  Can take multiple
+ *	calls to successfully establish the context.
+ *
+ *	Requires:
+ *		'qmsg'    is a valid message, the original TKEY request;
+ *			     it will be filled with the new message to send
+ *		'rmsg'    is a valid message, the incoming TKEY message
+ *		'server'  is the server name
+ *		'context' is the input context handle
+ *		'outkey'  receives the established key, if non-NULL;
+ *			      if non-NULL must point to NULL
+ *		'ring'	  is the keyring in which to establish the key,
+ *			      or NULL
+ *		'win2k'   when true says to turn on some hacks to work
+ *			      with the non-standard GSS-TSIG of Windows 2000
+ *
+ *	Returns:
+ *		ISC_R_SUCCESS	context was successfully established
+ *		ISC_R_NOTFOUND  couldn't find a needed part of the query
+ *					or response
+ *		DNS_R_CONTINUE  additional context negotiation is required;
+ *					send the new qmsg to the server
+ */
+
 ISC_LANG_ENDDECLS
 
 #endif /* DNS_TKEY_H */
diff --git a/contrib/bind9/lib/dns/include/dns/tsig.h b/contrib/bind9/lib/dns/include/dns/tsig.h
index b3fd6cc..e8c0e2c 100644
--- a/contrib/bind9/lib/dns/include/dns/tsig.h
+++ b/contrib/bind9/lib/dns/include/dns/tsig.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: tsig.h,v 1.43.18.4 2006/01/27 23:57:44 marka Exp $ */
+/* $Id: tsig.h,v 1.51 2007/06/19 23:47:17 tbox Exp $ */
 
 #ifndef DNS_TSIG_H
 #define DNS_TSIG_H 1
 
-/*! \file */
+/*! \file dns/tsig.h */
 
 #include <isc/lang.h>
 #include <isc/refcount.h>
@@ -59,6 +59,7 @@ LIBDNS_EXTERNAL_DATA extern dns_name_t *dns_tsig_hmacsha512_name;
 
 struct dns_tsig_keyring {
 	dns_rbt_t *keys;
+	unsigned int writecount;
 	isc_rwlock_t lock;
 	isc_mem_t *mctx;
 };
@@ -79,7 +80,9 @@ struct dns_tsigkey {
 };
 
 #define dns_tsigkey_identity(tsigkey) \
-	((tsigkey)->generated ? ((tsigkey)->creator) : (&((tsigkey)->name)))
+	((tsigkey) == NULL ? NULL : \
+         (tsigkey)->generated ? ((tsigkey)->creator) : \
+         (&((tsigkey)->name)))
 
 ISC_LANG_BEGINDECLS
 
diff --git a/contrib/bind9/lib/dns/include/dns/ttl.h b/contrib/bind9/lib/dns/include/dns/ttl.h
index ad01578..c252518 100644
--- a/contrib/bind9/lib/dns/include/dns/ttl.h
+++ b/contrib/bind9/lib/dns/include/dns/ttl.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ttl.h,v 1.13.18.2 2005/04/29 00:16:24 marka Exp $ */
+/* $Id: ttl.h,v 1.19 2007/06/19 23:47:17 tbox Exp $ */
 
 #ifndef DNS_TTL_H
 #define DNS_TTL_H 1
 
-/*! \file */
+/*! \file dns/ttl.h */
 
 /***
  ***	Imports
diff --git a/contrib/bind9/lib/dns/include/dns/types.h b/contrib/bind9/lib/dns/include/dns/types.h
index 8dcbe57..e07a796 100644
--- a/contrib/bind9/lib/dns/include/dns/types.h
+++ b/contrib/bind9/lib/dns/include/dns/types.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: types.h,v 1.109.18.12 2006/05/02 12:55:31 shane Exp $ */
+/* $Id: types.h,v 1.130.50.3 2009/01/29 22:40:35 jinmei Exp $ */
 
 #ifndef DNS_TYPES_H
 #define DNS_TYPES_H 1
 
-/*! \file
+/*! \file dns/types.h
  * \brief
  * Including this file gives you type declarations suitable for use in
  * .h files, which lets us avoid circular type reference problems.
@@ -68,6 +68,8 @@ typedef struct dns_fetch			dns_fetch_t;
 typedef struct dns_fixedname			dns_fixedname_t;
 typedef struct dns_forwarders			dns_forwarders_t;
 typedef struct dns_fwdtable			dns_fwdtable_t;
+typedef struct dns_iptable			dns_iptable_t;
+typedef isc_uint32_t				dns_iterations_t;
 typedef isc_uint16_t				dns_keyflags_t;
 typedef struct dns_keynode			dns_keynode_t;
 typedef struct dns_keytable			dns_keytable_t;
@@ -105,6 +107,8 @@ typedef isc_uint8_t				dns_secproto_t;
 typedef struct dns_signature			dns_signature_t;
 typedef struct dns_ssurule			dns_ssurule_t;
 typedef struct dns_ssutable			dns_ssutable_t;
+typedef struct dns_stats			dns_stats_t;
+typedef isc_uint32_t				dns_rdatastatstype_t;
 typedef struct dns_tkeyctx			dns_tkeyctx_t;
 typedef isc_uint16_t				dns_trust_t;
 typedef struct dns_tsig_keyring			dns_tsig_keyring_t;
@@ -118,6 +122,19 @@ typedef ISC_LIST(dns_zone_t)			dns_zonelist_t;
 typedef struct dns_zonemgr			dns_zonemgr_t;
 typedef struct dns_zt				dns_zt_t;
 
+/*
+ * If we are not using GSSAPI, define the types we use as opaque types here.
+ */
+#ifndef GSSAPI
+typedef struct not_defined_gss_cred_id *gss_cred_id_t;
+typedef struct not_defined_gss_ctx *gss_ctx_id_t;
+#endif
+typedef struct dst_gssapi_signverifyctx dst_gssapi_signverifyctx_t;
+
+typedef enum {
+	dns_hash_sha1 = 1
+} dns_hash_t;
+
 typedef enum {
 	dns_fwdpolicy_none = 0,
 	dns_fwdpolicy_first = 1,
@@ -249,11 +266,11 @@ enum {
 	dns_trust_additional = 2,
 #define dns_trust_additional		((dns_trust_t)dns_trust_additional)
 
-	/* Received in a referral response. */ 
+	/* Received in a referral response. */
 	dns_trust_glue = 3,
 #define dns_trust_glue			((dns_trust_t)dns_trust_glue)
 
-	/* Answser from a non-authoritative server */
+	/* Answer from a non-authoritative server */
 	dns_trust_answer = 4,
 #define dns_trust_answer		((dns_trust_t)dns_trust_answer)
 
@@ -262,11 +279,11 @@ enum {
 	dns_trust_authauthority = 5,
 #define dns_trust_authauthority		((dns_trust_t)dns_trust_authauthority)
 
-	/* Answser from an authoritative server */
+	/* Answer from an authoritative server */
 	dns_trust_authanswer = 6,
 #define dns_trust_authanswer		((dns_trust_t)dns_trust_authanswer)
 
-	/* Successfully DNSSEC validated */	
+	/* Successfully DNSSEC validated */
 	dns_trust_secure = 7,
 #define dns_trust_secure		((dns_trust_t)dns_trust_secure)
 
@@ -276,7 +293,7 @@ enum {
 };
 
 /*%
- * Name checking severites.
+ * Name checking severities.
  */
 typedef enum {
 	dns_severity_ignore,
@@ -308,7 +325,7 @@ typedef void
 typedef void
 (*dns_updatecallback_t)(void *, isc_result_t, dns_message_t *);
 
-typedef int 
+typedef int
 (*dns_rdatasetorderfunc_t)(const dns_rdata_t *, const void *);
 
 typedef isc_boolean_t
diff --git a/contrib/bind9/lib/dns/include/dns/validator.h b/contrib/bind9/lib/dns/include/dns/validator.h
index c94fc3a..2555214 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, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: validator.h,v 1.27.18.10 2007/09/26 04:39:45 each Exp $ */
+/* $Id: validator.h,v 1.41.48.3 2009/01/18 23:25:17 marka Exp $ */
 
 #ifndef DNS_VALIDATOR_H
 #define DNS_VALIDATOR_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file dns/validator.h
  *
  * \brief
  * DNS Validator
@@ -74,7 +74,7 @@
  * caller so that they may be freed.
  *
  * If the RESULT is ISC_R_SUCCESS and the answer is secure then
- * proofs[] will contain the the names of the NSEC records that hold the
+ * proofs[] will contain the names of the NSEC records that hold the
  * various proofs.  Note the same name may appear multiple times.
  */
 typedef struct dns_validatorevent {
@@ -99,12 +99,17 @@ typedef struct dns_validatorevent {
 	/*
 	 * Proofs to be cached.
 	 */
-	dns_name_t *			proofs[3];
+	dns_name_t *			proofs[4];
+	/*
+	 * Optout proof seen.
+	 */
+	isc_boolean_t			optout;
 } dns_validatorevent_t;
 
 #define DNS_VALIDATOR_NOQNAMEPROOF 0
 #define DNS_VALIDATOR_NODATAPROOF 1
 #define DNS_VALIDATOR_NOWILDCARDPROOF 2
+#define DNS_VALIDATOR_CLOSESTENCLOSER 3
 
 /*%
  * A validator object represents a validation in progress.
@@ -139,11 +144,14 @@ struct dns_validator {
 	dns_rdataset_t *		dsset;
 	dns_rdataset_t *		soaset;
 	dns_rdataset_t *		nsecset;
+	dns_rdataset_t *		nsec3set;
 	dns_name_t *			soaname;
 	dns_rdataset_t			frdataset;
 	dns_rdataset_t			fsigrdataset;
 	dns_fixedname_t			fname;
 	dns_fixedname_t			wild;
+	dns_fixedname_t			nearest;
+	dns_fixedname_t			closest;
 	ISC_LINK(dns_validator_t)	link;
 	dns_rdataset_t 			dlv;
 	dns_fixedname_t			dlvsep;
@@ -202,7 +210,7 @@ dns_validator_create(dns_view_t *view, dns_name_t *name, dns_rdatatype_t type,
  * options:
  * If DNS_VALIDATOR_DLV is set the caller knows there is not a
  * trusted key and the validator should immediately attempt to validate
- * the answer by looking for a appopriate DLV RRset.
+ * the answer by looking for an appropriate DLV RRset.
  */
 
 void
diff --git a/contrib/bind9/lib/dns/include/dns/version.h b/contrib/bind9/lib/dns/include/dns/version.h
index bb254534..2a33dcf 100644
--- a/contrib/bind9/lib/dns/include/dns/version.h
+++ b/contrib/bind9/lib/dns/include/dns/version.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,9 +15,9 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: version.h,v 1.3.18.2 2005/04/29 00:16:25 marka Exp $ */
+/* $Id: version.h,v 1.9 2007/06/19 23:47:17 tbox Exp $ */
 
-/*! \file */
+/*! \file dns/version.h */
 
 #include <isc/platform.h>
 
diff --git a/contrib/bind9/lib/dns/include/dns/view.h b/contrib/bind9/lib/dns/include/dns/view.h
index ea3d4c7..5b53c16 100644
--- a/contrib/bind9/lib/dns/include/dns/view.h
+++ b/contrib/bind9/lib/dns/include/dns/view.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: view.h,v 1.91.18.9 2006/03/09 23:38:21 marka Exp $ */
+/* $Id: view.h,v 1.111.88.4 2009/01/29 22:40:35 jinmei Exp $ */
 
 #ifndef DNS_VIEW_H
 #define DNS_VIEW_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file dns/view.h
  * \brief
  * DNS View
  *
@@ -100,6 +100,9 @@ struct dns_view {
 	isc_event_t			resevent;
 	isc_event_t			adbevent;
 	isc_event_t			reqevent;
+	isc_stats_t *			resstats;
+	dns_stats_t *			resquerystats;
+
 	/* Configurable data. */
 	dns_tsig_keyring_t *		statickeys;
 	dns_tsig_keyring_t *		dynamickeys;
@@ -116,10 +119,17 @@ struct dns_view {
 	isc_boolean_t			acceptexpired;
 	dns_transfer_format_t		transfer_format;
 	dns_acl_t *			queryacl;
+	dns_acl_t *			queryonacl;
 	dns_acl_t *			recursionacl;
+	dns_acl_t *			recursiononacl;
 	dns_acl_t *			sortlist;
+	dns_acl_t *			notifyacl;
+	dns_acl_t *			transferacl;
+	dns_acl_t *			updateacl;
+	dns_acl_t *			upfwdacl;
 	isc_boolean_t			requestixfr;
 	isc_boolean_t			provideixfr;
+	isc_boolean_t			requestnsid;
 	dns_ttl_t			maxcachettl;
 	dns_ttl_t			maxncachettl;
 	in_port_t			dstport;
@@ -224,7 +234,7 @@ void
 dns_view_flushanddetach(dns_view_t **viewp);
 /*%<
  * Detach '*viewp' from its view.  If this was the last reference
- * uncommited changed in zones will be flushed to disk.
+ * uncommitted changed in zones will be flushed to disk.
  *
  * Requires:
  *
@@ -363,7 +373,7 @@ dns_view_setdstport(dns_view_t *view, in_port_t dstport);
  *\li      'dstport' is a valid TCP/UDP port number.
  *
  * Ensures:
- *\li	External name servers will be assumed to be listning
+ *\li	External name servers will be assumed to be listening
  *	on 'dstport'.  For servers whose address has already
  *	obtained obtained at the time of the call, the view may
  *	continue to use the previously set port until the address
@@ -591,6 +601,19 @@ dns_viewlist_find(dns_viewlist_t *list, const char *name,
  */
 
 isc_result_t
+dns_viewlist_findzone(dns_viewlist_t *list, dns_name_t *name, isc_boolean_t allclasses,
+		      dns_rdataclass_t rdclass, dns_zone_t **zonep);
+
+/*%<
+ * Search zone with 'name' in view with 'rdclass' in viewlist 'list'
+ * If found, zone is returned in *zonep. If allclasses is set rdclass is ignored
+ *
+ * Returns:
+ *\li	#ISC_R_SUCCESS          A matching zone was found.
+ *\li	#ISC_R_NOTFOUND         No matching zone was found.
+ */
+
+isc_result_t
 dns_view_findzone(dns_view_t *view, dns_name_t *name, dns_zone_t **zonep);
 /*%<
  * Search for the zone 'name' in the zone table of 'view'.
@@ -615,7 +638,7 @@ dns_view_loadnew(dns_view_t *view, isc_boolean_t stop);
 /*%<
  * Load zones attached to this view.  dns_view_load() loads
  * all zones whose master file has changed since the last
- * load; dns_view_loadnew() loads only zones that have never 
+ * load; dns_view_loadnew() loads only zones that have never
  * been loaded.
  *
  * If 'stop' is ISC_TRUE, stop on the first error and return it.
@@ -633,7 +656,7 @@ dns_view_gettsig(dns_view_t *view, dns_name_t *keyname,
  * Find the TSIG key configured in 'view' with name 'keyname',
  * if any.
  *
- * Reqires:
+ * Requires:
  *\li	keyp points to a NULL dns_tsigkey_t *.
  *
  * Returns:
@@ -649,7 +672,7 @@ dns_view_getpeertsig(dns_view_t *view, isc_netaddr_t *peeraddr,
  * Find the TSIG key configured in 'view' for the server whose
  * address is 'peeraddr', if any.
  *
- * Reqires:
+ * Requires:
  *	keyp points to a NULL dns_tsigkey_t *.
  *
  * Returns:
@@ -691,7 +714,7 @@ dns_view_dumpdbtostream(dns_view_t *view, FILE *fp);
  * easily obtainable by other means.
  *
  * Requires:
- * 	
+ *
  *\li	'view' is valid.
  *
  *\li	'fp' refers to a file open for writing.
@@ -734,7 +757,7 @@ isc_result_t
 dns_view_adddelegationonly(dns_view_t *view, dns_name_t *name);
 /*%<
  * Add the given name to the delegation only table.
- * 
+ *
  *
  * Requires:
  *\li	'view' is valid.
@@ -749,7 +772,7 @@ isc_result_t
 dns_view_excludedelegationonly(dns_view_t *view, dns_name_t *name);
 /*%<
  * Add the given name to be excluded from the root-delegation-only.
- * 
+ *
  *
  * Requires:
  *\li	'view' is valid.
@@ -771,8 +794,8 @@ dns_view_isdelegationonly(dns_view_t *view, dns_name_t *name);
  *\li	'name' is valid.
  *
  * Returns:
- *\li	#ISC_TRUE if the name is is the table.
- *\li	#ISC_FALSE othewise.
+ *\li	#ISC_TRUE if the name is the table.
+ *\li	#ISC_FALSE otherwise.
  */
 
 void
@@ -801,4 +824,56 @@ dns_view_freezezones(dns_view_t *view, isc_boolean_t freeze);
  * Requires:
  * \li	'view' is valid.
  */
+
+void
+dns_view_setresstats(dns_view_t *view, isc_stats_t *stats);
+/*%<
+ * Set a general resolver statistics counter set 'stats' for 'view'.
+ *
+ * Requires:
+ * \li	'view' is valid and is not frozen.
+ *
+ *\li	stats is a valid statistics supporting resolver statistics counters
+ *	(see dns/stats.h).
+ */
+
+void
+dns_view_getresstats(dns_view_t *view, isc_stats_t **statsp);
+/*%<
+ * Get the general statistics counter set for 'view'.  If a statistics set is
+ * set '*statsp' will be attached to the set; otherwise, '*statsp' will be
+ * untouched.
+ *
+ * Requires:
+ * \li	'view' is valid and is not frozen.
+ *
+ *\li	'statsp' != NULL && '*statsp' != NULL
+ */
+
+void
+dns_view_setresquerystats(dns_view_t *view, dns_stats_t *stats);
+/*%<
+ * Set a statistics counter set of rdata type, 'stats', for 'view'.  Once the
+ * statistic set is installed, view's resolver will count outgoing queries
+ * per rdata type.
+ *
+ * Requires:
+ * \li	'view' is valid and is not frozen.
+ *
+ *\li	stats is a valid statistics created by dns_rdatatypestats_create().
+ */
+
+void
+dns_view_getresquerystats(dns_view_t *view, dns_stats_t **statsp);
+/*%<
+ * Get the rdatatype statistics counter set for 'view'.  If a statistics set is
+ * set '*statsp' will be attached to the set; otherwise, '*statsp' will be
+ * untouched.
+ *
+ * Requires:
+ * \li	'view' is valid and is not frozen.
+ *
+ *\li	'statsp' != NULL && '*statsp' != NULL
+ */
+
 #endif /* DNS_VIEW_H */
diff --git a/contrib/bind9/lib/dns/include/dns/xfrin.h b/contrib/bind9/lib/dns/include/dns/xfrin.h
index fcd482e..04866ee 100644
--- a/contrib/bind9/lib/dns/include/dns/xfrin.h
+++ b/contrib/bind9/lib/dns/include/dns/xfrin.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: xfrin.h,v 1.20.18.5 2006/07/20 01:10:30 marka Exp $ */
+/* $Id: xfrin.h,v 1.28.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef DNS_XFRIN_H
 #define DNS_XFRIN_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file 
+/*! \file dns/xfrin.h
  * \brief
  * Incoming zone transfers (AXFR + IXFR).
  */
@@ -90,7 +90,7 @@ dns_xfrin_shutdown(dns_xfrin_ctx_t *xfr);
 /*%<
  * If the zone transfer 'xfr' has already finished,
  * do nothing.  Otherwise, abort it and cause it to call
- * its done callback with a status of ISC_R_CANCELLED.
+ * its done callback with a status of ISC_R_CANCELED.
  */
 
 void
diff --git a/contrib/bind9/lib/dns/include/dns/zone.h b/contrib/bind9/lib/dns/include/dns/zone.h
index 7cb8272..e2859ae 100644
--- a/contrib/bind9/lib/dns/include/dns/zone.h
+++ b/contrib/bind9/lib/dns/include/dns/zone.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: zone.h,v 1.126.18.19 2006/08/01 03:45:21 marka Exp $ */
+/* $Id: zone.h,v 1.160.50.4 2009/01/29 22:40:35 jinmei Exp $ */
 
 #ifndef DNS_ZONE_H
 #define DNS_ZONE_H 1
 
-/*! \file */
+/*! \file dns/zone.h */
 
 /***
  ***	Imports
@@ -33,6 +33,7 @@
 #include <isc/rwlock.h>
 
 #include <dns/masterdump.h>
+#include <dns/rdatastruct.h>
 #include <dns/types.h>
 
 typedef enum {
@@ -66,6 +67,9 @@ typedef enum {
 #define DNS_ZONEOPT_WARNSRVCNAME  0x00200000U	/*%< warn on SRV CNAME check */
 #define DNS_ZONEOPT_IGNORESRVCNAME 0x00400000U	/*%< ignore SRV CNAME check */
 #define DNS_ZONEOPT_UPDATECHECKKSK 0x00800000U	/*%< check dnskey KSK flag */
+#define DNS_ZONEOPT_TRYTCPREFRESH 0x01000000U	/*%< try tcp refresh on udp failure */
+#define DNS_ZONEOPT_NOTIFYTOSOA	  0x02000000U	/*%< Notify the SOA MNAME */
+#define DNS_ZONEOPT_NSEC3TESTZONE 0x04000000U	/*%< nsec3-test-zone */
 
 #ifndef NOMINUM_PUBLIC
 /*
@@ -145,6 +149,15 @@ dns_zone_getclass(dns_zone_t *zone);
  *\li	'zone' to be a valid zone.
  */
 
+isc_uint32_t
+dns_zone_getserial(dns_zone_t *zone);
+/*%<
+ *	Returns the current serial number of the zone.
+ *
+ * Requires:
+ *\li	'zone' to be a valid zone.
+ */
+
 void
 dns_zone_settype(dns_zone_t *zone, dns_zonetype_t type);
 /*%<
@@ -406,7 +419,7 @@ dns_zone_refresh(dns_zone_t *zone);
 isc_result_t
 dns_zone_flush(dns_zone_t *zone);
 /*%<
- *	Write the zone to database if there are uncommited changes.
+ *	Write the zone to database if there are uncommitted changes.
  *
  * Require:
  *\li	'zone' to be a valid zone.
@@ -458,7 +471,7 @@ dns_zone_fulldumptostream(dns_zone_t *zone, FILE *fd);
 void
 dns_zone_maintenance(dns_zone_t *zone);
 /*%<
- *	Perform regular maintenace on the zone.  This is called as a
+ *	Perform regular maintenance on the zone.  This is called as a
  *	result of a zone being managed.
  *
  * Require
@@ -503,7 +516,7 @@ dns_zone_setalsonotify(dns_zone_t *zone, const isc_sockaddr_t *notify,
  * Require:
  *\li	'zone' to be a valid zone.
  *\li	'notify' to be non-NULL if count != 0.
- *\li	'count' to be the number of notifyees.
+ *\li	'count' to be the number of notifiees.
  *
  * Returns:
  *\li	#ISC_R_SUCCESS
@@ -701,6 +714,16 @@ dns_zone_setqueryacl(dns_zone_t *zone, dns_acl_t *acl);
  */
 
 void
+dns_zone_setqueryonacl(dns_zone_t *zone, dns_acl_t *acl);
+/*%<
+ *	Sets the query-on acl list for the zone.
+ *
+ * Require:
+ *\li	'zone' to be a valid zone.
+ *\li	'acl' to be a valid acl.
+ */
+
+void
 dns_zone_setupdateacl(dns_zone_t *zone, dns_acl_t *acl);
 /*%<
  *	Sets the update acl list for the zone.
@@ -757,6 +780,19 @@ dns_zone_getqueryacl(dns_zone_t *zone);
  */
 
 dns_acl_t *
+dns_zone_getqueryonacl(dns_zone_t *zone);
+/*%<
+ * 	Returns the current query-on acl or NULL.
+ *
+ * Require:
+ *\li	'zone' to be a valid zone.
+ *
+ * Returns:
+ *\li	acl a pointer to the acl.
+ *\li	NULL
+ */
+
+dns_acl_t *
 dns_zone_getupdateacl(dns_zone_t *zone);
 /*%<
  * 	Returns the current update acl or NULL.
@@ -832,6 +868,15 @@ dns_zone_clearqueryacl(dns_zone_t *zone);
  */
 
 void
+dns_zone_clearqueryonacl(dns_zone_t *zone);
+/*%<
+ *	Clear the current query-on acl.
+ *
+ * Require:
+ *\li	'zone' to be a valid zone.
+ */
+
+void
 dns_zone_clearxfracl(dns_zone_t *zone);
 /*%<
  *	Clear the current transfer acl.
@@ -844,12 +889,16 @@ isc_boolean_t
 dns_zone_getupdatedisabled(dns_zone_t *zone);
 /*%<
  * Return update disabled.
+ * Transient unless called when running in isc_task_exclusive() mode.
  */
 
 void
 dns_zone_setupdatedisabled(dns_zone_t *zone, isc_boolean_t state);
 /*%<
  * Set update disabled.
+ * Should only be called only when running in isc_task_exclusive() mode.
+ * Failure to do so may result in updates being committed after the
+ * call has been made.
  */
 
 isc_boolean_t
@@ -905,13 +954,13 @@ isc_result_t
 dns_zone_notifyreceive(dns_zone_t *zone, isc_sockaddr_t *from,
 		       dns_message_t *msg);
 /*%<
- *	Tell the zone that it has recieved a NOTIFY message from another
- *	server.  This may cause some zone maintainence activity to occur.
+ *	Tell the zone that it has received a NOTIFY message from another
+ *	server.  This may cause some zone maintenance activity to occur.
  *
  * Requires:
  *\li	'zone' to be a valid zone.
  *\li	'*from' to contain the address of the server from which 'msg'
- *		was recieved.
+ *		was received.
  *\li	'msg' a message with opcode NOTIFY and qr clear.
  *
  * Returns:
@@ -1036,7 +1085,7 @@ dns_zone_replacedb(dns_zone_t *zone, dns_db_t *db, isc_boolean_t dump);
  * If "dump" is ISC_TRUE, then the new zone contents are dumped
  * into to the zone's master file for persistence.  When replacing
  * a zone database by one just loaded from a master file, set
- * "dump" to ISC_FALSE to avoid a redunant redump of the data just
+ * "dump" to ISC_FALSE to avoid a redundant redump of the data just
  * loaded.  Otherwise, it should be set to ISC_TRUE.
  *
  * If the "diff-on-reload" option is enabled in the configuration file,
@@ -1048,7 +1097,7 @@ dns_zone_replacedb(dns_zone_t *zone, dns_db_t *db, isc_boolean_t dump);
  *
  * Returns:
  * \li	DNS_R_SUCCESS
- * \li	DNS_R_BADZONE	zone failed basic consistancy checks:
+ * \li	DNS_R_BADZONE	zone failed basic consistency checks:
  *			* a single SOA must exist
  *			* some NS records must exist.
  *	Others
@@ -1134,7 +1183,7 @@ dns_zone_getmgr(dns_zone_t *zone);
 void
 dns_zone_setsigvalidityinterval(dns_zone_t *zone, isc_uint32_t interval);
 /*%<
- * Set the zone's SIG validity interval.  This is the length of time
+ * Set the zone's RRSIG validity interval.  This is the length of time
  * for which DNSSEC signatures created as a result of dynamic updates
  * to secure zones will remain valid, in seconds.
  *
@@ -1145,7 +1194,26 @@ dns_zone_setsigvalidityinterval(dns_zone_t *zone, isc_uint32_t interval);
 isc_uint32_t
 dns_zone_getsigvalidityinterval(dns_zone_t *zone);
 /*%<
- * Get the zone's SIG validity interval.
+ * Get the zone's RRSIG validity interval.
+ *
+ * Requires:
+ * \li	'zone' to be a valid zone.
+ */
+
+void
+dns_zone_setsigresigninginterval(dns_zone_t *zone, isc_uint32_t interval);
+/*%<
+ * Set the zone's RRSIG re-signing interval.  A dynamic zone's RRSIG's
+ * will be re-signed 'interval' amount of time before they expire.
+ *
+ * Requires:
+ * \li	'zone' to be a valid zone.
+ */
+
+isc_uint32_t
+dns_zone_getsigresigninginterval(dns_zone_t *zone);
+/*%<
+ * Get the zone's RRSIG re-signing interval.
  *
  * Requires:
  * \li	'zone' to be a valid zone.
@@ -1159,10 +1227,10 @@ dns_zone_setnotifytype(dns_zone_t *zone, dns_notifytype_t notifytype);
 
 isc_result_t
 dns_zone_forwardupdate(dns_zone_t *zone, dns_message_t *msg,
-                       dns_updatecallback_t callback, void *callback_arg);
+		       dns_updatecallback_t callback, void *callback_arg);
 /*%<
  * Forward 'msg' to each master in turn until we get an answer or we
- * have exausted the list of masters. 'callback' will be called with
+ * have exhausted the list of masters. 'callback' will be called with
  * ISC_R_SUCCESS if we get an answer and the returned message will be
  * passed as 'answer_message', otherwise a non ISC_R_SUCCESS result code
  * will be passed and answer_message will be NULL.  The callback function
@@ -1195,6 +1263,8 @@ dns_zone_next(dns_zone_t *zone, dns_zone_t **next);
  *	(result ISC_R_NOMORE).
  */
 
+
+
 isc_result_t
 dns_zone_first(dns_zonemgr_t *zmgr, dns_zone_t **first);
 /*%<
@@ -1267,7 +1337,7 @@ isc_result_t
 dns_zonemgr_forcemaint(dns_zonemgr_t *zmgr);
 /*%<
  * Force zone maintenance of all zones managed by 'zmgr' at its
- * earliest conveniene.
+ * earliest convenience.
  */
 
 void
@@ -1336,7 +1406,7 @@ dns_zonemgr_settransfersin(dns_zonemgr_t *zmgr, isc_uint32_t value);
 isc_uint32_t
 dns_zonemgr_getttransfersin(dns_zonemgr_t *zmgr);
 /*%<
- *	Return the the maximum number of simultaneous transfers in allowed.
+ *	Return the maximum number of simultaneous transfers in allowed.
  *
  * Requires:
  *\li	'zmgr' to be a valid zone manager.
@@ -1363,7 +1433,7 @@ dns_zonemgr_getttransfersperns(dns_zonemgr_t *zmgr);
 void
 dns_zonemgr_setiolimit(dns_zonemgr_t *zmgr, isc_uint32_t iolimit);
 /*%<
- *	Set the number of simultaneous file descriptors available for 
+ *	Set the number of simultaneous file descriptors available for
  *	reading and writing masterfiles.
  *
  * Requires:
@@ -1374,7 +1444,7 @@ dns_zonemgr_setiolimit(dns_zonemgr_t *zmgr, isc_uint32_t iolimit);
 isc_uint32_t
 dns_zonemgr_getiolimit(dns_zonemgr_t *zmgr);
 /*%<
- *	Get the number of simultaneous file descriptors available for 
+ *	Get the number of simultaneous file descriptors available for
  *	reading and writing masterfiles.
  *
  * Requires:
@@ -1410,6 +1480,18 @@ dns_zonemgr_getcount(dns_zonemgr_t *zmgr, int state);
  */
 
 void
+dns_zonemgr_unreachableadd(dns_zonemgr_t *zmgr, isc_sockaddr_t *remote,
+			   isc_sockaddr_t *local, isc_time_t *now);
+/*%<
+ *	Add the pair of addresses to the unreachable cache.
+ *
+ * Requires:
+ *\li	'zmgr' to be a valid zone manager.
+ *\li	'remote' to be a valid sockaddr.
+ *\li	'local' to be a valid sockaddr.
+ */
+
+void
 dns_zone_forcereload(dns_zone_t *zone);
 /*%<
  *      Force a reload of specified zone.
@@ -1430,22 +1512,55 @@ dns_zone_isforced(dns_zone_t *zone);
 isc_result_t
 dns_zone_setstatistics(dns_zone_t *zone, isc_boolean_t on);
 /*%<
- *      Make the zone keep or not keep an array of statistics
- * 	counter.
- *
- * Requires:
- *   \li   zone be a valid zone.
+ * This function is obsoleted by dns_zone_setrequeststats().
  */
 
 isc_uint64_t *
 dns_zone_getstatscounters(dns_zone_t *zone);
 /*%<
+ * This function is obsoleted by dns_zone_getrequeststats().
+ */
+
+void
+dns_zone_setstats(dns_zone_t *zone, isc_stats_t *stats);
+/*%<
+ * Set a general zone-maintenance statistics set 'stats' for 'zone'.  This
+ * function is expected to be called only on zone creation (when necessary).
+ * Once installed, it cannot be removed or replaced.  Also, there is no
+ * interface to get the installed stats from the zone; the caller must keep the
+ * stats to reference (e.g. dump) it later.
+ *
  * Requires:
- *      zone be a valid zone.
+ * \li	'zone' to be a valid zone and does not have a statistics set already
+ *	installed.
+ *
+ *\li	stats is a valid statistics supporting zone statistics counters
+ *	(see dns/stats.h).
+ */
+
+void
+dns_zone_setrequeststats(dns_zone_t *zone, isc_stats_t *stats);
+/*%<
+ * Set an additional statistics set to zone.  It is attached in the zone
+ * but is not counted in the zone module; only the caller updates the counters.
+ *
+ * Requires:
+ * \li	'zone' to be a valid zone.
+ *
+ *\li	stats is a valid statistics.
+ */
+
+isc_stats_t *
+dns_zone_getrequeststats(dns_zone_t *zone);
+/*%<
+ * Get the additional statistics for zone, if one is installed.
+ *
+ * Requires:
+ * \li	'zone' to be a valid zone.
  *
  * Returns:
- * \li     A pointer to the zone's array of statistics counters,
- *	or NULL if it has none.
+ * \li	when available, a pointer to the statistics set installed in zone;
+ *	otherwise NULL.
  */
 
 void
@@ -1484,7 +1599,7 @@ void
 dns_zone_name(dns_zone_t *zone, char *buf, size_t len);
 /*%<
  * Return the name of the zone with class and view.
- * 
+ *
  * Requires:
  *\li	'zone' to be valid.
  *\li	'buf' to be non NULL.
@@ -1492,7 +1607,7 @@ dns_zone_name(dns_zone_t *zone, char *buf, size_t len);
 
 isc_result_t
 dns_zone_checknames(dns_zone_t *zone, dns_name_t *name, dns_rdata_t *rdata);
-/*
+/*%<
  * Check if this record meets the check-names policy.
  *
  * Requires:
@@ -1508,7 +1623,7 @@ dns_zone_checknames(dns_zone_t *zone, dns_name_t *name, dns_rdata_t *rdata);
 
 void
 dns_zone_setacache(dns_zone_t *zone, dns_acache_t *acache);
-/*
+/*%<
  *	Associate the zone with an additional cache.
  *
  * Require:
@@ -1521,7 +1636,7 @@ dns_zone_setacache(dns_zone_t *zone, dns_acache_t *acache);
 
 void
 dns_zone_setcheckmx(dns_zone_t *zone, dns_checkmxfunc_t checkmx);
-/*
+/*%<
  *	Set the post load integrity callback function 'checkmx'.
  *	'checkmx' will be called if the MX is not within the zone.
  *
@@ -1531,7 +1646,7 @@ dns_zone_setcheckmx(dns_zone_t *zone, dns_checkmxfunc_t checkmx);
 
 void
 dns_zone_setchecksrv(dns_zone_t *zone, dns_checkmxfunc_t checksrv);
-/*
+/*%<
  *	Set the post load integrity callback function 'checksrv'.
  *	'checksrv' will be called if the SRV TARGET is not within the zone.
  *
@@ -1541,7 +1656,7 @@ dns_zone_setchecksrv(dns_zone_t *zone, dns_checkmxfunc_t checksrv);
 
 void
 dns_zone_setcheckns(dns_zone_t *zone, dns_checknsfunc_t checkns);
-/*
+/*%<
  *	Set the post load integrity callback function 'checkmx'.
  *	'checkmx' will be called if the MX is not within the zone.
  *
@@ -1551,7 +1666,7 @@ dns_zone_setcheckns(dns_zone_t *zone, dns_checknsfunc_t checkns);
 
 void
 dns_zone_setnotifydelay(dns_zone_t *zone, isc_uint32_t delay);
-/*
+/*%<
  * Set the minimum delay between sets of notify messages.
  *
  * Requires:
@@ -1560,7 +1675,7 @@ dns_zone_setnotifydelay(dns_zone_t *zone, isc_uint32_t delay);
 
 isc_uint32_t
 dns_zone_getnotifydelay(dns_zone_t *zone);
-/*
+/*%<
  * Get the minimum delay between sets of notify messages.
  *
  * Requires:
@@ -1569,7 +1684,7 @@ dns_zone_getnotifydelay(dns_zone_t *zone);
 
 void
 dns_zone_setisself(dns_zone_t *zone, dns_isselffunc_t isself, void *arg);
-/*
+/*%<
  * Set the isself callback function and argument.
  *
  * isc_boolean_t
@@ -1581,6 +1696,41 @@ dns_zone_setisself(dns_zone_t *zone, dns_isselffunc_t isself, void *arg);
  * delivered to 'myview'.
  */
 
+void
+dns_zone_setnodes(dns_zone_t *zone, isc_uint32_t nodes);
+/*%<
+ * Set the number of nodes that will be checked per quantum.
+ */
+
+void
+dns_zone_setsignatures(dns_zone_t *zone, isc_uint32_t signatures);
+/*%<
+ * Set the number of signatures that will be generated per quantum.
+ */
+
+isc_result_t
+dns_zone_signwithkey(dns_zone_t *zone, dns_secalg_t algorithm,
+		     isc_uint16_t keyid, isc_boolean_t delete);
+/*%<
+ * Initiate/resume signing of the entire zone with the zone DNSKEY(s)
+ * that match the given algorithm and keyid.
+ */
+
+isc_result_t
+dns_zone_addnsec3chain(dns_zone_t *zone, dns_rdata_nsec3param_t *nsec3param);
+/*%<
+ * Incrementally add a NSEC3 chain that corresponds to 'nsec3param'.
+ */
+
+void
+dns_zone_setprivatetype(dns_zone_t *zone, dns_rdatatype_t type);
+dns_rdatatype_t
+dns_zone_getprivatetype(dns_zone_t *zone);
+/*
+ * Get/Set the private record type.  It is expected that these interfaces
+ * will not be permanent.
+ */
+
 ISC_LANG_ENDDECLS
 
 #endif /* DNS_ZONE_H */
diff --git a/contrib/bind9/lib/dns/include/dns/zonekey.h b/contrib/bind9/lib/dns/include/dns/zonekey.h
index ba4e076..d9ba862 100644
--- a/contrib/bind9/lib/dns/include/dns/zonekey.h
+++ b/contrib/bind9/lib/dns/include/dns/zonekey.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: zonekey.h,v 1.4.18.2 2005/04/29 00:16:26 marka Exp $ */
+/* $Id: zonekey.h,v 1.10 2007/06/19 23:47:17 tbox Exp $ */
 
 #ifndef DNS_ZONEKEY_H
 #define DNS_ZONEKEY_H 1
 
-/*! \file */
+/*! \file dns/zonekey.h */
 
 #include <isc/lang.h>
 
diff --git a/contrib/bind9/lib/dns/include/dns/zt.h b/contrib/bind9/lib/dns/include/dns/zt.h
index 436ef4c..6cfe3d3 100644
--- a/contrib/bind9/lib/dns/include/dns/zt.h
+++ b/contrib/bind9/lib/dns/include/dns/zt.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: zt.h,v 1.30.18.3 2005/04/27 05:01:42 sra Exp $ */
+/* $Id: zt.h,v 1.38 2007/06/19 23:47:17 tbox Exp $ */
 
 #ifndef DNS_ZT_H
 #define DNS_ZT_H 1
 
-/*! \file */
+/*! \file dns/zt.h */
 
 #include <isc/lang.h>
 
diff --git a/contrib/bind9/lib/dns/include/dst/Makefile.in b/contrib/bind9/lib/dns/include/dst/Makefile.in
index deaa221..4ed4ec0 100644
--- a/contrib/bind9/lib/dns/include/dst/Makefile.in
+++ b/contrib/bind9/lib/dns/include/dst/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1998-2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.1.6.1 2004/12/09 04:41:47 marka Exp $
+# $Id: Makefile.in,v 1.4 2007/12/11 20:28:55 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -21,7 +21,7 @@ top_srcdir =	@top_srcdir@
 
 @BIND9_VERSION@
 
-HEADERS =	dst.h lib.h result.h
+HEADERS =	dst.h gssapi.h lib.h result.h
 
 SUBDIRS =
 TARGETS =
diff --git a/contrib/bind9/lib/dns/include/dst/dst.h b/contrib/bind9/lib/dns/include/dst/dst.h
index 8d99186..702ad71 100644
--- a/contrib/bind9/lib/dns/include/dst/dst.h
+++ b/contrib/bind9/lib/dns/include/dst/dst.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,17 +15,19 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dst.h,v 1.1.6.5 2006/01/27 23:57:44 marka Exp $ */
+/* $Id: dst.h,v 1.12 2008/09/24 02:46:23 marka Exp $ */
 
 #ifndef DST_DST_H
 #define DST_DST_H 1
 
-/*! \file */
+/*! \file dst/dst.h */
 
 #include <isc/lang.h>
 
 #include <dns/types.h>
 
+#include <dst/gssapi.h>
+
 ISC_LANG_BEGINDECLS
 
 /***
@@ -49,6 +51,8 @@ typedef struct dst_context 	dst_context_t;
 #define DST_ALG_DSA		3
 #define DST_ALG_ECC		4
 #define DST_ALG_RSASHA1		5
+#define DST_ALG_NSEC3DSA	6
+#define DST_ALG_NSEC3RSASHA1	7
 #define DST_ALG_HMACMD5		157
 #define DST_ALG_GSSAPI		160
 #define DST_ALG_HMACSHA1	161	/* XXXMPA */
@@ -398,16 +402,28 @@ dst_key_privatefrombuffer(dst_key_t *key, isc_buffer_t *buffer);
  *\li	If successful, key will contain a valid private key.
  */
 
+gss_ctx_id_t
+dst_key_getgssctx(const dst_key_t *key);
+/*%<
+ * Returns the opaque key data.
+ * Be cautions when using this value unless you know what you are doing.
+ *
+ * Requires:
+ *\li	"key" is not NULL.
+ *
+ * Returns:
+ *\li	gssctx key data, possibly NULL.
+ */
 
 isc_result_t
-dst_key_fromgssapi(dns_name_t *name, void *opaque, isc_mem_t *mctx,
-		                   dst_key_t **keyp);
+dst_key_fromgssapi(dns_name_t *name, gss_ctx_id_t gssctx, isc_mem_t *mctx,
+		   dst_key_t **keyp);
 /*%<
  * Converts a GSSAPI opaque context id into a DST key.
  *
  * Requires:
  *\li	"name" is a valid absolute dns name.
- *\li	"opaque" is a GSSAPI context id.
+ *\li	"gssctx" is a GSSAPI context id.
  *\li	"mctx" is a valid memory context.
  *\li	"keyp" is not NULL and "*keyp" is NULL.
  *
@@ -421,6 +437,12 @@ dst_key_fromgssapi(dns_name_t *name, void *opaque, isc_mem_t *mctx,
  */
 
 isc_result_t
+dst_key_fromlabel(dns_name_t *name, int alg, unsigned int flags,
+		  unsigned int protocol, dns_rdataclass_t rdclass,
+		  const char *engine, const char *label, const char *pin,
+		  isc_mem_t *mctx, dst_key_t **keyp);
+
+isc_result_t
 dst_key_generate(dns_name_t *name, unsigned int alg,
 		 unsigned int bits, unsigned int param,
 		 unsigned int flags, unsigned int protocol,
diff --git a/contrib/bind9/lib/dns/include/dst/gssapi.h b/contrib/bind9/lib/dns/include/dst/gssapi.h
index e30fb0c..446b76d 100644
--- a/contrib/bind9/lib/dns/include/dst/gssapi.h
+++ b/contrib/bind9/lib/dns/include/dst/gssapi.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,16 +15,32 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: gssapi.h,v 1.1.6.3 2005/04/29 00:16:28 marka Exp $ */
+/* $Id: gssapi.h,v 1.9.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef DST_GSSAPI_H
 #define DST_GSSAPI_H 1
 
-/*! \file */
+/*! \file dst/gssapi.h */
 
+#include <isc/formatcheck.h>
 #include <isc/lang.h>
-
+#include <isc/platform.h>
 #include <isc/types.h>
+#include <dns/types.h>
+
+#ifdef GSSAPI
+#ifdef _WINDOWS
+/*
+ * MSVC does not like macros in #include lines.
+ */
+#include <gssapi/gssapi.h>
+#else
+#include ISC_PLATFORM_GSSAPIHEADER
+#endif
+#ifndef GSS_SPNEGO_MECHANISM
+#define GSS_SPNEGO_MECHANISM ((void*)0)
+#endif
+#endif
 
 ISC_LANG_BEGINDECLS
 
@@ -37,20 +53,153 @@ ISC_LANG_BEGINDECLS
  ***/
 
 isc_result_t
-dst_gssapi_acquirecred(dns_name_t *name, isc_boolean_t initiate, void **cred);
+dst_gssapi_acquirecred(dns_name_t *name, isc_boolean_t initiate,
+		       gss_cred_id_t *cred);
+/*
+ *	Acquires GSS credentials.
+ *
+ *	Requires:
+ * 	'name' 	    is a valid name, preferably one known by the GSS provider
+ * 	'initiate'  indicates whether the credentials are for initiating or
+ *		    accepting contexts
+ *      'cred'      is a pointer to NULL, which will be allocated with the
+ *		    credential handle.  Call dst_gssapi_releasecred to free
+ *		    the memory.
+ *
+ *	Returns:
+ *		ISC_R_SUCCESS msg was successfully updated to include the
+ *				      query to be sent
+ *		other		  an error occurred while building the message
+ */
+
+isc_result_t
+dst_gssapi_releasecred(gss_cred_id_t *cred);
+/*
+ *	Releases GSS credentials.  Calling this function does release the
+ *  memory allocated for the credential in dst_gssapi_acquirecred()
+ *
+ *	Requires:
+ *      'mctx'  is a valid memory context
+ *      'cred'  is a pointer to the credential to be released
+ *
+ *	Returns:
+ *		ISC_R_SUCCESS 	credential was released successfully
+ *		other		an error occurred while releaseing
+ *				the credential
+ */
+
+isc_result_t
+dst_gssapi_initctx(dns_name_t *name, isc_buffer_t *intoken,
+		   isc_buffer_t *outtoken, gss_ctx_id_t *gssctx);
+/*
+ *	Initiates a GSS context.
+ *
+ *	Requires:
+ * 	'name'     is a valid name, preferably one known by the GSS
+ * 	provider
+ * 	'intoken'  is a token received from the acceptor, or NULL if
+ *		   there isn't one
+ * 	'outtoken' is a buffer to receive the token generated by
+ *		   gss_init_sec_context() to be sent to the acceptor
+ *      'context'  is a pointer to a valid gss_ctx_id_t
+ *                 (which may have the value GSS_C_NO_CONTEXT)
+ *
+ *	Returns:
+ *		ISC_R_SUCCESS   msg was successfully updated to include the
+ * 				query to be sent
+ *		other		an error occurred while building the message
+ */
 
 isc_result_t
-dst_gssapi_initctx(dns_name_t *name, void *cred,
-		   isc_region_t *intoken, isc_buffer_t *outtoken,
-		   void **context);
+dst_gssapi_acceptctx(gss_cred_id_t cred,
+		     isc_region_t *intoken, isc_buffer_t **outtoken,
+		     gss_ctx_id_t *context, dns_name_t *principal,
+		     isc_mem_t *mctx);
+/*
+ *	Accepts a GSS context.
+ *
+ *	Requires:
+ * 	'mctx'     is a valid memory context
+ *      'cred'     is the acceptor's valid GSS credential handle
+ * 	'intoken'  is a token received from the initiator
+ * 	'outtoken' is a pointer a buffer pointer used to return the token
+ *		   generated by gss_accept_sec_context() to be sent to the
+ *		   initiator
+ *      'context'  is a valid pointer to receive the generated context handle.
+ *                 On the initial call, it should be a pointer to NULL, which
+ *		   will be allocated as a gss_ctx_id_t.  Subsequent calls
+ *		   should pass in the handle generated on the first call.
+ *		   Call dst_gssapi_releasecred to delete the context and free
+ *		   the memory.
+ *
+ *	Requires:
+ *		'outtoken' to != NULL && *outtoken == NULL.
+ *
+ *	Returns:
+ *		ISC_R_SUCCESS   msg was successfully updated to include the
+ * 				query to be sent
+ *		other 		an error occurred while building the message
+ */
 
 isc_result_t
-dst_gssapi_acceptctx(dns_name_t *name, void *cred,
-		     isc_region_t *intoken, isc_buffer_t *outtoken,
-		     void **context);
+dst_gssapi_deletectx(isc_mem_t *mctx, gss_ctx_id_t *gssctx);
+/*
+ *	Destroys a GSS context.  This function deletes the context from the GSS
+ *  	provider and then frees the memory used by the context pointer.
+ *
+ *	Requires:
+ *      'mctx'    is a valid memory context
+ *	'context' is a valid GSS context
+ *
+ *	Returns:
+ *		ISC_R_SUCCESS
+ */
+
+
+void
+gss_log(int level, const char *fmt, ...)
+ISC_FORMAT_PRINTF(2, 3);
+/*
+ * Logging function for GSS.
+ *
+ *  Requires
+ *      'level' is the log level to be used, as an integer
+ *      'fmt'   is a printf format specifier
+ */
+
+char *
+gss_error_tostring(isc_uint32_t major, isc_uint32_t minor,
+		   char *buf, size_t buflen);
+/*
+ *	Render a GSS major status/minor status pair into a string
+ *
+ *	Requires:
+ *      'major' is a GSS major status code
+ * 	'minor' is a GSS minor status code
+ *
+ *	Returns:
+ *		A string containing the text representation of the error codes.
+ *      	Users should copy the string if they wish to keep it.
+ */
 
+isc_boolean_t
+dst_gssapi_identitymatchesrealmkrb5(dns_name_t *signer, dns_name_t *name,
+			      dns_name_t *realm);
 /*
- * XXX
+ *	Compare a "signer" (in the format of a Kerberos-format Kerberos5
+ *	principal: host/example.com@EXAMPLE.COM) to the realm name stored
+ *	in "name" (which represents the realm name).
+ *
+ */
+
+isc_boolean_t
+dst_gssapi_identitymatchesrealmms(dns_name_t *signer, dns_name_t *name,
+			    dns_name_t *realm);
+/*
+ *	Compare a "signer" (in the format of a Kerberos-format Kerberos5
+ *	principal: host/example.com@EXAMPLE.COM) to the realm name stored
+ *	in "name" (which represents the realm name).
+ *
  */
 
 ISC_LANG_ENDDECLS
diff --git a/contrib/bind9/lib/dns/include/dst/lib.h b/contrib/bind9/lib/dns/include/dst/lib.h
index bd71261..886575e 100644
--- a/contrib/bind9/lib/dns/include/dst/lib.h
+++ b/contrib/bind9/lib/dns/include/dst/lib.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lib.h,v 1.1.6.3 2005/04/29 00:16:29 marka Exp $ */
+/* $Id: lib.h,v 1.7 2007/06/19 23:47:17 tbox Exp $ */
 
 #ifndef DST_LIB_H
 #define DST_LIB_H 1
 
-/*! \file */
+/*! \file dst/lib.h */
 
 #include <isc/types.h>
 #include <isc/lang.h>
diff --git a/contrib/bind9/lib/dns/include/dst/result.h b/contrib/bind9/lib/dns/include/dst/result.h
index aa03b73..d77b72e 100644
--- a/contrib/bind9/lib/dns/include/dst/result.h
+++ b/contrib/bind9/lib/dns/include/dst/result.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: result.h,v 1.1.6.3 2005/04/29 00:16:29 marka Exp $ */
+/* $Id: result.h,v 1.9 2008/04/01 23:47:10 tbox Exp $ */
 
 #ifndef DST_RESULT_H
 #define DST_RESULT_H 1
 
-/*! \file */
+/*! \file dst/result.h */
 
 #include <isc/lang.h>
 #include <isc/resultclass.h>
@@ -54,8 +54,9 @@
 #define DST_R_COMPUTESECRETFAILURE	(ISC_RESULTCLASS_DST + 18)
 #define DST_R_NORANDOMNESS		(ISC_RESULTCLASS_DST + 19)
 #define DST_R_BADKEYTYPE		(ISC_RESULTCLASS_DST + 20)
+#define DST_R_NOENGINE			(ISC_RESULTCLASS_DST + 21)
 
-#define DST_R_NRESULTS			21	/* Number of results */
+#define DST_R_NRESULTS			22	/* Number of results */
 
 ISC_LANG_BEGINDECLS
 
diff --git a/contrib/bind9/lib/dns/iptable.c b/contrib/bind9/lib/dns/iptable.c
new file mode 100644
index 0000000..55a5351
--- /dev/null
+++ b/contrib/bind9/lib/dns/iptable.c
@@ -0,0 +1,188 @@
+/*
+ * Copyright (C) 2007-2009  Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or 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: iptable.c,v 1.12.44.3 2009/02/18 23:47:12 tbox Exp $ */
+
+#include <config.h>
+
+#include <isc/mem.h>
+#include <isc/radix.h>
+
+#include <dns/acl.h>
+
+static void destroy_iptable(dns_iptable_t *dtab);
+
+/*
+ * Create a new IP table and the underlying radix structure
+ */
+isc_result_t
+dns_iptable_create(isc_mem_t *mctx, dns_iptable_t **target) {
+	isc_result_t result;
+	dns_iptable_t *tab;
+
+	tab = isc_mem_get(mctx, sizeof(*tab));
+	if (tab == NULL)
+		return (ISC_R_NOMEMORY);
+	tab->mctx = mctx;
+	isc_refcount_init(&tab->refcount, 1);
+	tab->radix = NULL;
+	tab->magic = DNS_IPTABLE_MAGIC;
+
+	result = isc_radix_create(mctx, &tab->radix, RADIX_MAXBITS);
+	if (result != ISC_R_SUCCESS)
+		goto cleanup;
+
+	*target = tab;
+	return (ISC_R_SUCCESS);
+
+ cleanup:
+	dns_iptable_detach(&tab);
+	return (result);
+}
+
+isc_boolean_t dns_iptable_neg = ISC_FALSE;
+isc_boolean_t dns_iptable_pos = ISC_TRUE;
+
+/*
+ * Add an IP prefix to an existing IP table
+ */
+isc_result_t
+dns_iptable_addprefix(dns_iptable_t *tab, isc_netaddr_t *addr,
+		      isc_uint16_t bitlen, isc_boolean_t pos)
+{
+	isc_result_t result;
+	isc_prefix_t pfx;
+	isc_radix_node_t *node = NULL;
+	int family;
+
+	INSIST(DNS_IPTABLE_VALID(tab));
+	INSIST(tab->radix);
+
+	NETADDR_TO_PREFIX_T(addr, pfx, bitlen);
+
+	result = isc_radix_insert(tab->radix, &node, NULL, &pfx);
+	if (result != ISC_R_SUCCESS) {
+		isc_refcount_destroy(&pfx.refcount);
+		return(result);
+	}
+
+	/* If a node already contains data, don't overwrite it */
+	family = pfx.family;
+	if (family == AF_UNSPEC) {
+		/* "any" or "none" */
+		INSIST(pfx.bitlen == 0);
+		if (pos) {
+			if (node->data[0] == NULL)
+				node->data[0] = &dns_iptable_pos;
+			if (node->data[1] == NULL)
+				node->data[1] = &dns_iptable_pos;
+		} else {
+			if (node->data[0] == NULL)
+				node->data[0] = &dns_iptable_neg;
+			if (node->data[1] == NULL)
+				node->data[1] = &dns_iptable_neg;
+		}
+	} else {
+		/* any other prefix */
+		if (node->data[ISC_IS6(family)] == NULL) {
+			if (pos)
+				node->data[ISC_IS6(family)] = &dns_iptable_pos;
+			else
+				node->data[ISC_IS6(family)] = &dns_iptable_neg;
+		}
+	}
+
+	isc_refcount_destroy(&pfx.refcount);
+	return (ISC_R_SUCCESS);
+}
+
+/*
+ * Merge one IP table into another one.
+ */
+isc_result_t
+dns_iptable_merge(dns_iptable_t *tab, dns_iptable_t *source, isc_boolean_t pos)
+{
+	isc_result_t result;
+	isc_radix_node_t *node, *new_node;
+	int max_node = 0;
+
+	RADIX_WALK (source->radix->head, node) {
+		new_node = NULL;
+		result = isc_radix_insert (tab->radix, &new_node, node, NULL);
+
+		if (result != ISC_R_SUCCESS)
+			return(result);
+
+		/*
+		 * If we're negating a nested ACL, then we should
+		 * reverse the sense of every node.  However, this
+		 * could lead to a negative node in a nested ACL
+		 * becoming a positive match in the parent, which
+		 * could be a security risk.  To prevent this, we
+		 * just leave the negative nodes negative.
+		 */
+		if (!pos) {
+			if (node->data[0] &&
+			    *(isc_boolean_t *) node->data[0] == ISC_TRUE)
+				new_node->data[0] = &dns_iptable_neg;
+
+			if (node->data[1] &&
+			    *(isc_boolean_t *) node->data[1] == ISC_TRUE)
+				new_node->data[1] = &dns_iptable_neg;
+		}
+
+		if (node->node_num[0] > max_node)
+			max_node = node->node_num[0];
+		if (node->node_num[1] > max_node)
+			max_node = node->node_num[1];
+	} RADIX_WALK_END;
+
+	tab->radix->num_added_node += max_node;
+	return (ISC_R_SUCCESS);
+}
+
+void
+dns_iptable_attach(dns_iptable_t *source, dns_iptable_t **target) {
+	REQUIRE(DNS_IPTABLE_VALID(source));
+	isc_refcount_increment(&source->refcount, NULL);
+	*target = source;
+}
+
+void
+dns_iptable_detach(dns_iptable_t **tabp) {
+	dns_iptable_t *tab = *tabp;
+	unsigned int refs;
+	REQUIRE(DNS_IPTABLE_VALID(tab));
+	isc_refcount_decrement(&tab->refcount, &refs);
+	if (refs == 0)
+		destroy_iptable(tab);
+	*tabp = NULL;
+}
+
+static void
+destroy_iptable(dns_iptable_t *dtab) {
+
+	REQUIRE(DNS_IPTABLE_VALID(dtab));
+
+	if (dtab->radix != NULL) {
+		isc_radix_destroy(dtab->radix, NULL);
+		dtab->radix = NULL;
+	}
+
+	isc_refcount_destroy(&dtab->refcount);
+	dtab->magic = 0;
+	isc_mem_put(dtab->mctx, dtab, sizeof(*dtab));
+}
diff --git a/contrib/bind9/lib/dns/journal.c b/contrib/bind9/lib/dns/journal.c
index 4e4010f..8c21f1e 100644
--- a/contrib/bind9/lib/dns/journal.c
+++ b/contrib/bind9/lib/dns/journal.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: journal.c,v 1.86.18.14 2008/09/25 04:01:36 tbox Exp $ */
+/* $Id: journal.c,v 1.103.48.2 2009/01/18 23:47:37 tbox Exp $ */
 
 #include <config.h>
 
@@ -42,7 +42,7 @@
 #include <dns/soa.h>
 
 /*! \file
- * \brief Journalling.
+ * \brief Journaling.
  *
  * A journal file consists of
  *
@@ -172,7 +172,7 @@ dns_db_createsoatuple(dns_db_t *db, dns_dbversion_t *ver, isc_mem_t *mctx,
 	return (result);
 }
 
-/* Journalling */
+/* Journaling */
 
 /*%
  * On-disk representation of a "pointer" to a journal entry.
@@ -641,7 +641,7 @@ journal_open(isc_mem_t *mctx, const char *filename, isc_boolean_t write,
 	dns_rdata_init(&j->it.rdata);
 
 	/*
-	 * Set up empty initial buffers for uncheched and checked
+	 * Set up empty initial buffers for unchecked and checked
 	 * wire format RR data.  They will be reallocated
 	 * later.
 	 */
@@ -709,8 +709,35 @@ ixfr_order(const void *av, const void *bv) {
 	dns_difftuple_t const *a = *ap;
 	dns_difftuple_t const *b = *bp;
 	int r;
+	int bop = 0, aop = 0;
+
+	switch (a->op) {
+	case DNS_DIFFOP_DEL:
+	case DNS_DIFFOP_DELRESIGN:
+		aop = 1;
+		break;
+	case DNS_DIFFOP_ADD:
+	case DNS_DIFFOP_ADDRESIGN:
+		aop = 0;
+		break;
+	default:
+		INSIST(0);
+	}
+
+	switch (b->op) {
+	case DNS_DIFFOP_DEL:
+	case DNS_DIFFOP_DELRESIGN:
+		bop = 1;
+		break;
+	case DNS_DIFFOP_ADD:
+	case DNS_DIFFOP_ADDRESIGN:
+		bop = 0;
+		break;
+	default:
+		INSIST(0);
+	}
 
-	r = (b->op == DNS_DIFFOP_DEL) - (a->op == DNS_DIFFOP_DEL);
+	r = bop - aop;
 	if (r != 0)
 		return (r);
 
@@ -1191,7 +1218,7 @@ dns_journal_destroy(dns_journal_t **journalp) {
 /* XXX Share code with incoming IXFR? */
 
 static isc_result_t
-roll_forward(dns_journal_t *j, dns_db_t *db) {
+roll_forward(dns_journal_t *j, dns_db_t *db, unsigned int options) {
 	isc_buffer_t source;		/* Transaction data from disk */
 	isc_buffer_t target;		/* Ditto after _fromwire check */
 	isc_uint32_t db_serial;		/* Database SOA serial */
@@ -1202,6 +1229,7 @@ roll_forward(dns_journal_t *j, dns_db_t *db) {
 	dns_diff_t diff;
 	unsigned int n_soa = 0;
 	unsigned int n_put = 0;
+	dns_diffop_t op;
 
 	REQUIRE(DNS_JOURNAL_VALID(j));
 	REQUIRE(DNS_DB_VALID(db));
@@ -1209,7 +1237,7 @@ roll_forward(dns_journal_t *j, dns_db_t *db) {
 	dns_diff_init(j->mctx, &diff);
 
 	/*
-	 * Set up empty initial buffers for uncheched and checked
+	 * Set up empty initial buffers for unchecked and checked
 	 * wire format transaction data.  They will be reallocated
 	 * later.
 	 */
@@ -1273,9 +1301,14 @@ roll_forward(dns_journal_t *j, dns_db_t *db) {
 					 "initial SOA", j->filename);
 			FAIL(ISC_R_UNEXPECTED);
 		}
-		CHECK(dns_difftuple_create(diff.mctx, n_soa == 1 ?
-					   DNS_DIFFOP_DEL : DNS_DIFFOP_ADD,
-					   name, ttl, rdata, &tuple));
+		if ((options & DNS_JOURNALOPT_RESIGN) != 0)
+			op = (n_soa == 1) ? DNS_DIFFOP_DELRESIGN :
+					    DNS_DIFFOP_ADDRESIGN;
+		else
+			op = (n_soa == 1) ? DNS_DIFFOP_DEL : DNS_DIFFOP_ADD;
+
+		CHECK(dns_difftuple_create(diff.mctx, op, name, ttl, rdata,
+					   &tuple));
 		dns_diff_append(&diff, &tuple);
 
 		if (++n_put > 100)  {
@@ -1317,7 +1350,9 @@ roll_forward(dns_journal_t *j, dns_db_t *db) {
 }
 
 isc_result_t
-dns_journal_rollforward(isc_mem_t *mctx, dns_db_t *db, const char *filename) {
+dns_journal_rollforward(isc_mem_t *mctx, dns_db_t *db,
+			unsigned int options, const char *filename)
+{
 	dns_journal_t *j;
 	isc_result_t result;
 
@@ -1336,7 +1371,7 @@ dns_journal_rollforward(isc_mem_t *mctx, dns_db_t *db, const char *filename) {
 	if (JOURNAL_EMPTY(&j->header))
 		result = DNS_R_UPTODATE;
 	else
-		result = roll_forward(j, db);
+		result = roll_forward(j, db, options);
 
 	dns_journal_destroy(&j);
 
@@ -1374,7 +1409,7 @@ dns_journal_print(isc_mem_t *mctx, const char *filename, FILE *file) {
 	dns_diff_init(j->mctx, &diff);
 
 	/*
-	 * Set up empty initial buffers for uncheched and checked
+	 * Set up empty initial buffers for unchecked and checked
 	 * wire format transaction data.  They will be reallocated
 	 * later.
 	 */
@@ -1852,10 +1887,10 @@ dns_db_diff(isc_mem_t *mctx,
 	if (result != ISC_R_SUCCESS)
 		return (result);
 
-	result = dns_db_createiterator(db[0], ISC_FALSE, &dbit[0]);
+	result = dns_db_createiterator(db[0], 0, &dbit[0]);
 	if (result != ISC_R_SUCCESS)
 		goto cleanup_journal;
-	result = dns_db_createiterator(db[1], ISC_FALSE, &dbit[1]);
+	result = dns_db_createiterator(db[1], 0, &dbit[1]);
 	if (result != ISC_R_SUCCESS)
 		goto cleanup_interator0;
 
diff --git a/contrib/bind9/lib/dns/key.c b/contrib/bind9/lib/dns/key.c
index b0f2c0a..5cf4442 100644
--- a/contrib/bind9/lib/dns/key.c
+++ b/contrib/bind9/lib/dns/key.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: key.c,v 1.1.6.6 2006/01/27 23:57:44 marka Exp $ */
+/* $Id: key.c,v 1.8 2007/06/19 23:47:16 tbox Exp $ */
 
 #include <config.h>
 
diff --git a/contrib/bind9/lib/dns/keytable.c b/contrib/bind9/lib/dns/keytable.c
index ec0f8e4..bffd2d3 100644
--- a/contrib/bind9/lib/dns/keytable.c
+++ b/contrib/bind9/lib/dns/keytable.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: keytable.c,v 1.28.18.4 2005/12/05 00:00:03 marka Exp $ */
+/* $Id: keytable.c,v 1.34 2007/06/19 23:47:16 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/dns/lib.c b/contrib/bind9/lib/dns/lib.c
index 423908a..6f98b537 100644
--- a/contrib/bind9/lib/dns/lib.c
+++ b/contrib/bind9/lib/dns/lib.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lib.c,v 1.11.18.3 2005/08/15 01:46:50 marka Exp $ */
+/* $Id: lib.c,v 1.16 2007/06/19 23:47:16 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/dns/log.c b/contrib/bind9/lib/dns/log.c
index 939ea36..7551e15 100644
--- a/contrib/bind9/lib/dns/log.c
+++ b/contrib/bind9/lib/dns/log.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: log.c,v 1.36.18.4 2005/09/05 00:18:24 marka Exp $ */
+/* $Id: log.c,v 1.45 2007/06/18 23:47:40 tbox Exp $ */
 
 /*! \file */
 
@@ -29,7 +29,7 @@
 
 /*%
  * When adding a new category, be sure to add the appropriate
- * #define to <dns/log.h>.
+ * \#define to <dns/log.h>.
  */
 LIBDNS_EXTERNAL_DATA isc_logcategory_t dns_categories[] = {
 	{ "notify", 	0 },
@@ -43,12 +43,13 @@ LIBDNS_EXTERNAL_DATA isc_logcategory_t dns_categories[] = {
 	{ "dispatch",	0 },
 	{ "lame-servers", 0 },
 	{ "delegation-only", 0 },
+	{ "edns-disabled", 0 },
 	{ NULL, 	0 }
 };
 
 /*%
  * When adding a new module, be sure to add the appropriate
- * #define to <dns/log.h>.
+ * \#define to <dns/log.h>.
  */
 LIBDNS_EXTERNAL_DATA isc_logmodule_t dns_modules[] = {
 	{ "dns/db",	 	0 },
diff --git a/contrib/bind9/lib/dns/lookup.c b/contrib/bind9/lib/dns/lookup.c
index a3ddad4..d5fc7aa 100644
--- a/contrib/bind9/lib/dns/lookup.c
+++ b/contrib/bind9/lib/dns/lookup.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lookup.c,v 1.14.18.7 2007/08/28 07:20:04 tbox Exp $ */
+/* $Id: lookup.c,v 1.21 2007/06/18 23:47:40 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/dns/master.c b/contrib/bind9/lib/dns/master.c
index b04f2eb..462269e 100644
--- a/contrib/bind9/lib/dns/master.c
+++ b/contrib/bind9/lib/dns/master.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: master.c,v 1.148.18.21 2008/01/17 23:45:58 tbox Exp $ */
+/* $Id: master.c,v 1.171.120.2 2009/01/18 23:47:40 tbox Exp $ */
 
 /*! \file */
 
@@ -139,6 +139,7 @@ struct dns_loadctx {
 	/* locked by lock */
 	isc_uint32_t		references;
 	dns_incctx_t		*inc;
+	isc_uint32_t		resign;
 };
 
 struct dns_incctx {
@@ -503,7 +504,7 @@ incctx_create(isc_mem_t *mctx, dns_name_t *origin, dns_incctx_t **ictxp) {
 
 static isc_result_t
 loadctx_create(dns_masterformat_t format, isc_mem_t *mctx,
-	       unsigned int options, dns_name_t *top,
+	       unsigned int options, isc_uint32_t resign, dns_name_t *top,
 	       dns_rdataclass_t zclass, dns_name_t *origin,
 	       dns_rdatacallbacks_t *callbacks, isc_task_t *task,
 	       dns_loaddonefunc_t done, void *done_arg, isc_lex_t *lex,
@@ -580,6 +581,7 @@ loadctx_create(dns_masterformat_t format, isc_mem_t *mctx,
 	lctx->options = options;
 	lctx->seen_include = ISC_FALSE;
 	lctx->zclass = zclass;
+	lctx->resign = resign;
 	lctx->result = ISC_R_SUCCESS;
 
 	dns_fixedname_init(&lctx->fixed_top);
@@ -1738,8 +1740,7 @@ load_text(dns_loadctx_t *lctx) {
 			char namebuf[DNS_NAME_FORMATSIZE];
 			dns_name_format(ictx->current, namebuf,
 					sizeof(namebuf));
-			(*callbacks->error)(callbacks,
-					    "%s:%lu: SOA "
+			(*callbacks->error)(callbacks, "%s:%lu: SOA "
 					    "record not at top of zone (%s)",
 					    source, line, namebuf);
 			result = DNS_R_NOTZONETOP;
@@ -1834,7 +1835,7 @@ load_text(dns_loadctx_t *lctx) {
 		/*
 		 * Find type in rdatalist.
 		 * If it does not exist create new one and prepend to list
-		 * as this will mimimise list traversal.
+		 * as this will minimise list traversal.
 		 */
 		if (ictx->glue != NULL)
 			this = ISC_LIST_HEAD(glue_list);
@@ -2324,8 +2325,8 @@ dns_master_loadfile(const char *master_file, dns_name_t *top,
 		    dns_rdataclass_t zclass, unsigned int options,
 		    dns_rdatacallbacks_t *callbacks, isc_mem_t *mctx)
 {
-	return (dns_master_loadfile2(master_file, top, origin, zclass, options,
-				     callbacks, mctx, dns_masterformat_text));
+	return (dns_master_loadfile3(master_file, top, origin, zclass, options,
+				     0, callbacks, mctx, dns_masterformat_text));
 }
 
 isc_result_t
@@ -2335,11 +2336,23 @@ dns_master_loadfile2(const char *master_file, dns_name_t *top,
 		     dns_rdatacallbacks_t *callbacks, isc_mem_t *mctx,
 		     dns_masterformat_t format)
 {
+	return (dns_master_loadfile3(master_file, top, origin, zclass, options,
+				     0, callbacks, mctx, format));
+}
+
+isc_result_t
+dns_master_loadfile3(const char *master_file, dns_name_t *top,
+		     dns_name_t *origin, dns_rdataclass_t zclass,
+		     unsigned int options, isc_uint32_t resign,
+		     dns_rdatacallbacks_t *callbacks, isc_mem_t *mctx,
+		     dns_masterformat_t format)
+{
 	dns_loadctx_t *lctx = NULL;
 	isc_result_t result;
 
-	result = loadctx_create(format, mctx, options, top, zclass, origin,
-				callbacks, NULL, NULL, NULL, NULL, &lctx);
+	result = loadctx_create(format, mctx, options, resign, top, zclass,
+				origin, callbacks, NULL, NULL, NULL, NULL,
+				&lctx);
 	if (result != ISC_R_SUCCESS)
 		return (result);
 
@@ -2362,8 +2375,8 @@ dns_master_loadfileinc(const char *master_file, dns_name_t *top,
 		       isc_task_t *task, dns_loaddonefunc_t done,
 		       void *done_arg, dns_loadctx_t **lctxp, isc_mem_t *mctx)
 {
-	return (dns_master_loadfileinc2(master_file, top, origin, zclass,
-					options, callbacks, task, done,
+	return (dns_master_loadfileinc3(master_file, top, origin, zclass,
+					options, 0, callbacks, task, done,
 					done_arg, lctxp, mctx,
 					dns_masterformat_text));
 }
@@ -2376,14 +2389,29 @@ dns_master_loadfileinc2(const char *master_file, dns_name_t *top,
 			void *done_arg, dns_loadctx_t **lctxp, isc_mem_t *mctx,
 			dns_masterformat_t format)
 {
+	return (dns_master_loadfileinc3(master_file, top, origin, zclass,
+					options, 0, callbacks, task, done,
+					done_arg, lctxp, mctx, format));
+}
+
+isc_result_t
+dns_master_loadfileinc3(const char *master_file, dns_name_t *top,
+			dns_name_t *origin, dns_rdataclass_t zclass,
+			unsigned int options, isc_uint32_t resign,
+			dns_rdatacallbacks_t *callbacks, isc_task_t *task,
+			dns_loaddonefunc_t done, void *done_arg,
+			dns_loadctx_t **lctxp, isc_mem_t *mctx,
+			dns_masterformat_t format)
+{
 	dns_loadctx_t *lctx = NULL;
 	isc_result_t result;
 
 	REQUIRE(task != NULL);
 	REQUIRE(done != NULL);
 
-	result = loadctx_create(format, mctx, options, top, zclass, origin,
-				callbacks, task, done, done_arg, NULL, &lctx);
+	result = loadctx_create(format, mctx, options, resign, top, zclass,
+				origin, callbacks, task, done, done_arg, NULL,
+				&lctx);
 	if (result != ISC_R_SUCCESS)
 		return (result);
 
@@ -2412,7 +2440,7 @@ dns_master_loadstream(FILE *stream, dns_name_t *top, dns_name_t *origin,
 
 	REQUIRE(stream != NULL);
 
-	result = loadctx_create(dns_masterformat_text, mctx, options, top,
+	result = loadctx_create(dns_masterformat_text, mctx, options, 0, top,
 				zclass, origin, callbacks, NULL, NULL, NULL,
 				NULL, &lctx);
 	if (result != ISC_R_SUCCESS)
@@ -2445,7 +2473,7 @@ dns_master_loadstreaminc(FILE *stream, dns_name_t *top, dns_name_t *origin,
 	REQUIRE(task != NULL);
 	REQUIRE(done != NULL);
 
-	result = loadctx_create(dns_masterformat_text, mctx, options, top,
+	result = loadctx_create(dns_masterformat_text, mctx, options, 0, top,
 				zclass, origin, callbacks, task, done,
 				done_arg, NULL, &lctx);
 	if (result != ISC_R_SUCCESS)
@@ -2478,7 +2506,7 @@ dns_master_loadbuffer(isc_buffer_t *buffer, dns_name_t *top,
 
 	REQUIRE(buffer != NULL);
 
-	result = loadctx_create(dns_masterformat_text, mctx, options, top,
+	result = loadctx_create(dns_masterformat_text, mctx, options, 0, top,
 				zclass, origin, callbacks, NULL, NULL, NULL,
 				NULL, &lctx);
 	if (result != ISC_R_SUCCESS)
@@ -2511,7 +2539,7 @@ dns_master_loadbufferinc(isc_buffer_t *buffer, dns_name_t *top,
 	REQUIRE(task != NULL);
 	REQUIRE(done != NULL);
 
-	result = loadctx_create(dns_masterformat_text, mctx, options, top,
+	result = loadctx_create(dns_masterformat_text, mctx, options, 0, top,
 				zclass, origin, callbacks, task, done,
 				done_arg, NULL, &lctx);
 	if (result != ISC_R_SUCCESS)
@@ -2543,7 +2571,7 @@ dns_master_loadlexer(isc_lex_t *lex, dns_name_t *top,
 
 	REQUIRE(lex != NULL);
 
-	result = loadctx_create(dns_masterformat_text, mctx, options, top,
+	result = loadctx_create(dns_masterformat_text, mctx, options, 0, top,
 				zclass, origin, callbacks, NULL, NULL, NULL,
 				lex, &lctx);
 	if (result != ISC_R_SUCCESS)
@@ -2571,7 +2599,7 @@ dns_master_loadlexerinc(isc_lex_t *lex, dns_name_t *top,
 	REQUIRE(task != NULL);
 	REQUIRE(done != NULL);
 
-	result = loadctx_create(dns_masterformat_text, mctx, options, top,
+	result = loadctx_create(dns_masterformat_text, mctx, options, 0, top,
 				zclass, origin, callbacks, task, done,
 				done_arg, lex, &lctx);
 	if (result != ISC_R_SUCCESS)
@@ -2700,6 +2728,27 @@ grow_rdata(int new_len, dns_rdata_t *old, int old_len,
 	return (new);
 }
 
+static isc_uint32_t
+resign_fromlist(dns_rdatalist_t *this, isc_uint32_t resign) {
+	dns_rdata_t *rdata;
+	dns_rdata_rrsig_t sig;
+	isc_uint32_t when;
+
+	rdata = ISC_LIST_HEAD(this->rdata);
+	INSIST(rdata != NULL);
+	(void)dns_rdata_tostruct(rdata, &sig, NULL);
+	when = sig.timeexpire - resign;
+
+	rdata = ISC_LIST_NEXT(rdata, link);
+	while (rdata != NULL) {
+		(void)dns_rdata_tostruct(rdata, &sig, NULL);
+		if (sig.timeexpire - resign < when)
+			when = sig.timeexpire - resign;
+		rdata = ISC_LIST_NEXT(rdata, link);
+	}
+	return (when);
+}
+
 /*
  * Convert each element from a rdatalist_t to rdataset then call commit.
  * Unlink each element as we go.
@@ -2726,14 +2775,22 @@ commit(dns_rdatacallbacks_t *callbacks, dns_loadctx_t *lctx,
 		RUNTIME_CHECK(dns_rdatalist_tordataset(this, &dataset)
 			      == ISC_R_SUCCESS);
 		dataset.trust = dns_trust_ultimate;
+		/*
+		 * If this is a secure dynamic zone set the re-signing time.
+		 */
+		if (dataset.type == dns_rdatatype_rrsig &&
+		    (lctx->options & DNS_MASTER_RESIGN) != 0) {
+			dataset.attributes |= DNS_RDATASETATTR_RESIGN;
+			dns_name_format(owner, namebuf, sizeof(namebuf));
+			dataset.resign = resign_fromlist(this, lctx->resign);
+		}
 		result = ((*callbacks->add)(callbacks->add_private, owner,
 					    &dataset));
 		if (result == ISC_R_NOMEMORY) {
 			(*error)(callbacks, "dns_master_load: %s",
 				 dns_result_totext(result));
 		} else if (result != ISC_R_SUCCESS) {
-			dns_name_format(owner, namebuf,
-					sizeof(namebuf));
+			dns_name_format(owner, namebuf, sizeof(namebuf));
 			if (source != NULL) {
 				(*error)(callbacks, "%s: %s:%lu: %s: %s",
 					 "dns_master_load", source, line,
diff --git a/contrib/bind9/lib/dns/masterdump.c b/contrib/bind9/lib/dns/masterdump.c
index 1ffdfcb..5eac96f 100644
--- a/contrib/bind9/lib/dns/masterdump.c
+++ b/contrib/bind9/lib/dns/masterdump.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: masterdump.c,v 1.73.18.16 2008/08/13 23:46:04 tbox Exp $ */
+/* $Id: masterdump.c,v 1.94.50.2 2009/01/18 23:47:40 tbox Exp $ */
 
 /*! \file */
 
@@ -108,7 +108,8 @@ dns_master_style_default = {
 
 LIBDNS_EXTERNAL_DATA const dns_master_style_t
 dns_master_style_full = {
-	DNS_STYLEFLAG_COMMENT,
+	DNS_STYLEFLAG_COMMENT |
+	DNS_STYLEFLAG_RESIGN,
 	46, 46, 46, 64, 120, 8
 };
 
@@ -283,7 +284,7 @@ totext_ctx_init(const dns_master_style_t *style, dns_totext_ctx_t *ctx) {
 		/*
 		 * Do not return ISC_R_NOSPACE if the line break string
 		 * buffer is too small, because that would just make
-		 * dump_rdataset() retry indenfinitely with ever
+		 * dump_rdataset() retry indefinitely with ever
 		 * bigger target buffers.  That's a different buffer,
 		 * so it won't help.  Use DNS_R_TEXTTOOLONG as a substitute.
 		 */
@@ -784,6 +785,13 @@ static const char *trustnames[] = {
 	"local" /* aka ultimate */
 };
 
+const char *
+dns_trust_totext(dns_trust_t trust) {
+	if (trust >= sizeof(trustnames)/sizeof(*trustnames))
+		return ("bad");
+	return (trustnames[trust]);
+}
+
 static isc_result_t
 dump_rdatasets_text(isc_mem_t *mctx, dns_name_t *name,
 		    dns_rdatasetiter_t *rdsiter, dns_totext_ctx_t *ctx,
@@ -840,6 +848,15 @@ dump_rdatasets_text(isc_mem_t *mctx, dns_name_t *name,
 			if ((ctx->style.flags & DNS_STYLEFLAG_OMIT_OWNER) != 0)
 				name = NULL;
 		}
+		if (ctx->style.flags & DNS_STYLEFLAG_RESIGN &&
+		    rds->attributes & DNS_RDATASETATTR_RESIGN) {
+			isc_buffer_t b;
+			char buf[sizeof("YYYYMMDDHHMMSS")];
+			memset(buf, 0, sizeof(buf));
+			isc_buffer_init(&b, buf, sizeof(buf) - 1);
+			dns_time64_totext((isc_uint64_t)rds->resign, &b);
+			fprintf(f, "; resign=%s\n", buf);
+		}
 		dns_rdataset_disassociate(rds);
 	}
 
@@ -1020,9 +1037,9 @@ dumpctx_destroy(dns_dumpctx_t *dctx) {
 
 	dctx->magic = 0;
 	DESTROYLOCK(&dctx->lock);
+	dns_dbiterator_destroy(&dctx->dbiter);
 	if (dctx->version != NULL)
 		dns_db_closeversion(dctx->db, &dctx->version, ISC_FALSE);
-	dns_dbiterator_destroy(&dctx->dbiter);
 	dns_db_detach(&dctx->db);
 	if (dctx->task != NULL)
 		isc_task_detach(&dctx->task);
@@ -1177,7 +1194,7 @@ dumpctx_create(isc_mem_t *mctx, dns_db_t *db, dns_dbversion_t *version,
 {
 	dns_dumpctx_t *dctx;
 	isc_result_t result;
-	isc_boolean_t relative;
+	unsigned int options;
 
 	dctx = isc_mem_get(mctx, sizeof(*dctx));
 	if (dctx == NULL)
@@ -1224,10 +1241,10 @@ dumpctx_create(isc_mem_t *mctx, dns_db_t *db, dns_dbversion_t *version,
 
 	if (dctx->format == dns_masterformat_text &&
 	    (dctx->tctx.style.flags & DNS_STYLEFLAG_REL_OWNER) != 0) {
-		relative = ISC_TRUE;
+		options = DNS_DB_RELATIVENAMES;
 	} else
-		relative = ISC_FALSE;
-	result = dns_db_createiterator(dctx->db, relative, &dctx->dbiter);
+		options = 0;
+	result = dns_db_createiterator(dctx->db, options, &dctx->dbiter);
 	if (result != ISC_R_SUCCESS)
 		goto cleanup;
 
diff --git a/contrib/bind9/lib/dns/message.c b/contrib/bind9/lib/dns/message.c
index 8c56377..b541635 100644
--- a/contrib/bind9/lib/dns/message.c
+++ b/contrib/bind9/lib/dns/message.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: message.c,v 1.222.18.16 2008/07/28 23:46:20 tbox Exp $ */
+/* $Id: message.c,v 1.245.50.2 2009/01/18 23:47:40 tbox Exp $ */
 
 /*! \file */
 
@@ -24,6 +24,7 @@
  ***/
 
 #include <config.h>
+#include <ctype.h>
 
 #include <isc/buffer.h>
 #include <isc/mem.h>
@@ -45,6 +46,35 @@
 #include <dns/tsig.h>
 #include <dns/view.h>
 
+#ifdef SKAN_MSG_DEBUG
+static void
+hexdump(const char *msg, const char *msg2, void *base, size_t len) {
+	unsigned char *p;
+	unsigned int cnt;
+
+	p = base;
+	cnt = 0;
+
+	printf("*** %s [%s] (%u bytes @ %p)\n", msg, msg2, len, base);
+
+	while (cnt < len) {
+		if (cnt % 16 == 0)
+			printf("%p: ", p);
+		else if (cnt % 8 == 0)
+			printf(" |");
+		printf(" %02x %c", *p, (isprint(*p) ? *p : ' '));
+		p++;
+		cnt++;
+
+		if (cnt % 16 == 0)
+			printf("\n");
+	}
+
+	if (cnt % 16 != 0)
+		printf("\n");
+}
+#endif
+
 #define DNS_MESSAGE_OPCODE_MASK		0x7800U
 #define DNS_MESSAGE_OPCODE_SHIFT	11
 #define DNS_MESSAGE_RCODE_MASK		0x000fU
@@ -65,6 +95,8 @@
 #define VALID_PSEUDOSECTION(s)	(((s) >= DNS_PSEUDOSECTION_ANY) \
 				 && ((s) < DNS_PSEUDOSECTION_MAX))
 
+#define OPTOUT(x) (((x)->attributes & DNS_RDATASETATTR_OPTOUT) != 0)
+
 /*%
  * This is the size of each individual scratchpad buffer, and the numbers
  * of various block allocations used within the server.
@@ -138,7 +170,7 @@ static const char *rcodetext[] = {
 /*%
  * "helper" type, which consists of a block of some type, and is linkable.
  * For it to work, sizeof(dns_msgblock_t) must be a multiple of the pointer
- * size, or the allocated elements will not be alligned correctly.
+ * size, or the allocated elements will not be aligned correctly.
  */
 struct dns_msgblock {
 	unsigned int			count;
@@ -1462,14 +1494,8 @@ getsection(isc_buffer_t *source, dns_message_t *msg, dns_decompress_t *dctx,
 				rdataset->ttl = ttl;
 		}
 
-		/*
-		 * XXXMLG Perform a totally ugly hack here to pull
-		 * the rdatalist out of the private field in the rdataset,
-		 * and append this rdata to the rdatalist's linked list
-		 * of rdata.
-		 */
-		rdatalist = (dns_rdatalist_t *)(rdataset->private1);
-
+		/* Append this rdata to the rdataset. */
+		dns_rdatalist_fromrdataset(rdataset, &rdatalist);
 		ISC_LIST_APPEND(rdatalist->rdata, rdata, link);
 
 		/*
@@ -1934,7 +1960,7 @@ dns_message_rendersection(dns_message_t *msg, dns_section_t sectionid,
 				 *
 				 * XXXMLG Need to change this when
 				 * dns_rdataset_towire() can render partial
-				 * sets starting at some arbitary point in the
+				 * sets starting at some arbitrary point in the
 				 * set.  This will include setting a bit in the
 				 * rdataset to indicate that a partial
 				 * rendering was done, and some state saved
@@ -1964,6 +1990,8 @@ dns_message_rendersection(dns_message_t *msg, dns_section_t sectionid,
 				    (sectionid == DNS_SECTION_ANSWER ||
 				     sectionid == DNS_SECTION_AUTHORITY))
 					msg->flags &= ~DNS_MESSAGEFLAG_AD;
+				if (OPTOUT(rdataset))
+					msg->flags &= ~DNS_MESSAGEFLAG_AD;
 
 				rdataset->attributes |=
 					DNS_RDATASETATTR_RENDERED;
@@ -2899,6 +2927,35 @@ dns_message_rechecksig(dns_message_t *msg, dns_view_t *view) {
 	return (dns_message_checksig(msg, view));
 }
 
+#ifdef SKAN_MSG_DEBUG
+void
+dns_message_dumpsig(dns_message_t *msg, char *txt1) {
+	dns_rdata_t querytsigrdata = DNS_RDATA_INIT;
+	dns_rdata_any_tsig_t querytsig;
+	isc_result_t result;
+
+	if (msg->tsig != NULL) {
+		result = dns_rdataset_first(msg->tsig);
+		RUNTIME_CHECK(result == ISC_R_SUCCESS);
+		dns_rdataset_current(msg->tsig, &querytsigrdata);
+		result = dns_rdata_tostruct(&querytsigrdata, &querytsig, NULL);
+		RUNTIME_CHECK(result == ISC_R_SUCCESS);
+		hexdump(txt1, "TSIG", querytsig.signature,
+			querytsig.siglen);
+	}
+
+	if (msg->querytsig != NULL) {
+		result = dns_rdataset_first(msg->querytsig);
+		RUNTIME_CHECK(result == ISC_R_SUCCESS);
+		dns_rdataset_current(msg->querytsig, &querytsigrdata);
+		result = dns_rdata_tostruct(&querytsigrdata, &querytsig, NULL);
+		RUNTIME_CHECK(result == ISC_R_SUCCESS);
+		hexdump(txt1, "QUERYTSIG", querytsig.signature,
+			querytsig.siglen);
+	}
+}
+#endif
+
 isc_result_t
 dns_message_checksig(dns_message_t *msg, dns_view_t *view) {
 	isc_buffer_t b, msgb;
@@ -2907,10 +2964,14 @@ dns_message_checksig(dns_message_t *msg, dns_view_t *view) {
 
 	if (msg->tsigkey == NULL && msg->tsig == NULL && msg->sig0 == NULL)
 		return (ISC_R_SUCCESS);
+
 	INSIST(msg->saved.base != NULL);
 	isc_buffer_init(&msgb, msg->saved.base, msg->saved.length);
 	isc_buffer_add(&msgb, msg->saved.length);
 	if (msg->tsigkey != NULL || msg->tsig != NULL) {
+#ifdef SKAN_MSG_DEBUG
+		dns_message_dumpsig(msg, "dns_message_checksig#1");
+#endif
 		if (view != NULL)
 			return (dns_view_checksig(view, &msgb, msg));
 		else
@@ -2963,6 +3024,7 @@ dns_message_checksig(dns_message_t *msg, dns_view_t *view) {
 		{
 			dst_key_t *key = NULL;
 
+			dns_rdata_reset(&rdata);
 			dns_rdataset_current(&keyset, &rdata);
 			isc_buffer_init(&b, rdata.data, rdata.length);
 			isc_buffer_add(&b, rdata.length);
@@ -3068,6 +3130,10 @@ dns_message_pseudosectiontotext(dns_message_t *msg,
 	isc_result_t result;
 	char buf[sizeof("1234567890")];
 	isc_uint32_t mbz;
+	dns_rdata_t rdata;
+	isc_buffer_t optbuf;
+	isc_uint16_t optcode, optlen;
+	unsigned char *optdata;
 
 	REQUIRE(DNS_MESSAGE_VALID(msg));
 	REQUIRE(target != NULL);
@@ -3097,6 +3163,50 @@ dns_message_pseudosectiontotext(dns_message_t *msg,
 			ADD_STRING(target, "; udp: ");
 		snprintf(buf, sizeof(buf), "%u\n", (unsigned int)ps->rdclass);
 		ADD_STRING(target, buf);
+
+		result = dns_rdataset_first(ps);
+		if (result != ISC_R_SUCCESS)
+			return (ISC_R_SUCCESS);
+
+		/* Print EDNS info, if any */
+		dns_rdata_init(&rdata);
+		dns_rdataset_current(ps, &rdata);
+		if (rdata.length < 4)
+			return (ISC_R_SUCCESS);
+
+		isc_buffer_init(&optbuf, rdata.data, rdata.length);
+		isc_buffer_add(&optbuf, rdata.length);
+		optcode = isc_buffer_getuint16(&optbuf);
+		optlen = isc_buffer_getuint16(&optbuf);
+
+		if (optcode == DNS_OPT_NSID) {
+			ADD_STRING(target, "; NSID");
+		} else {
+			ADD_STRING(target, "; OPT=");
+			sprintf(buf, "%u", optcode);
+			ADD_STRING(target, buf);
+		}
+
+		if (optlen != 0) {
+			int i;
+			ADD_STRING(target, ": ");
+
+			optdata = rdata.data + 4;
+			for (i = 0; i < optlen; i++) {
+				sprintf(buf, "%02x ", optdata[i]);
+				ADD_STRING(target, buf);
+			}
+			for (i = 0; i < optlen; i++) {
+				ADD_STRING(target, " (");
+				if (isprint(optdata[i]))
+					isc_buffer_putmem(target, &optdata[i],
+							  1);
+				else
+					isc_buffer_putstr(target, ".");
+				ADD_STRING(target, ")");
+			}
+		}
+		ADD_STRING(target, "\n");
 		return (ISC_R_SUCCESS);
 	case DNS_PSEUDOSECTION_TSIG:
 		ps = dns_message_gettsig(msg, &name);
diff --git a/contrib/bind9/lib/dns/name.c b/contrib/bind9/lib/dns/name.c
index 7f5d4e9..f4ea3e9 100644
--- a/contrib/bind9/lib/dns/name.c
+++ b/contrib/bind9/lib/dns/name.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: name.c,v 1.144.18.16 2006/12/07 07:03:10 marka Exp $ */
+/* $Id: name.c,v 1.165 2008/04/01 23:47:10 tbox Exp $ */
 
 /*! \file */
 
@@ -155,7 +155,7 @@ do { \
 static unsigned char root_ndata[] = { '\0' };
 static unsigned char root_offsets[] = { 0 };
 
-static dns_name_t root = 
+static dns_name_t root =
 {
 	DNS_NAME_MAGIC,
 	root_ndata, 1, 1,
@@ -298,7 +298,7 @@ dns_name_ismailbox(const dns_name_t *name) {
 	REQUIRE(name->labels > 0);
 	REQUIRE(name->attributes & DNS_NAMEATTR_ABSOLUTE);
 
-	/* 
+	/*
 	 * Root label.
 	 */
 	if (name->length == 1)
@@ -312,7 +312,7 @@ dns_name_ismailbox(const dns_name_t *name) {
 		if (!domainchar(ch))
 			return (ISC_FALSE);
 	}
-	
+
 	if (ndata == name->ndata + name->length)
 		return (ISC_FALSE);
 
@@ -347,8 +347,8 @@ dns_name_ishostname(const dns_name_t *name, isc_boolean_t wildcard) {
 	REQUIRE(VALID_NAME(name));
 	REQUIRE(name->labels > 0);
 	REQUIRE(name->attributes & DNS_NAMEATTR_ABSOLUTE);
-	
-	/* 
+
+	/*
 	 * Root label.
 	 */
 	if (name->length == 1)
@@ -918,7 +918,7 @@ dns_name_getlabelsequence(const dns_name_t *source,
 
 	target->ndata = &source->ndata[firstoffset];
 	target->length = endoffset - firstoffset;
-	
+
 	if (first + n == source->labels && n > 0 &&
 	    (source->attributes & DNS_NAMEATTR_ABSOLUTE) != 0)
 		target->attributes |= DNS_NAMEATTR_ABSOLUTE;
@@ -991,7 +991,7 @@ dns_name_fromregion(dns_name_t *name, const isc_region_t *r) {
 		name->length = len;
 	} else {
 		name->ndata = r->base;
-		name->length = (r->length <= DNS_NAME_MAXWIRE) ? 
+		name->length = (r->length <= DNS_NAME_MAXWIRE) ?
 			r->length : DNS_NAME_MAXWIRE;
 	}
 
@@ -1049,7 +1049,7 @@ dns_name_fromtext(dns_name_t *name, isc_buffer_t *source,
 	REQUIRE(ISC_BUFFER_VALID(source));
 	REQUIRE((target != NULL && ISC_BUFFER_VALID(target)) ||
 		(target == NULL && ISC_BUFFER_VALID(name->buffer)));
-	
+
 	downcase = ISC_TF((options & DNS_NAME_DOWNCASE) != 0);
 
 	if (target == NULL && name->buffer != NULL) {
@@ -1297,24 +1297,25 @@ totext_filter_proc_key_init(void) {
 	if (result != ISC_R_SUCCESS)
 		return (result);
 
-        if (!thread_key_initialized) {
+	if (!thread_key_initialized) {
 		LOCK(&thread_key_mutex);
 		if (thread_key_mctx == NULL)
 			result = isc_mem_create2(0, 0, &thread_key_mctx, 0);
 		if (result != ISC_R_SUCCESS)
 			goto unlock;
+		isc_mem_setname(thread_key_mctx, "threadkey", NULL);
 		isc_mem_setdestroycheck(thread_key_mctx, ISC_FALSE);
-		
+
 		if (!thread_key_initialized &&
 		     isc_thread_key_create(&totext_filter_proc_key,
-					    free_specific) != 0) {
+					   free_specific) != 0) {
 			result = ISC_R_FAILURE;
 			isc_mem_detach(&thread_key_mctx);
 		} else
 			thread_key_initialized = 1;
  unlock:
 		UNLOCK(&thread_key_mutex);
-        }
+	}
 	return (result);
 }
 #endif
@@ -1930,7 +1931,8 @@ dns_name_towire(const dns_name_t *name, dns_compress_t *cctx,
 
 	methods = dns_compress_getmethods(cctx);
 
-	if ((methods & DNS_COMPRESS_GLOBAL14) != 0)
+	if ((name->attributes & DNS_NAMEATTR_NOCOMPRESS) == 0 &&
+	    (methods & DNS_COMPRESS_GLOBAL14) != 0)
 		gf = dns_compress_findglobal(cctx, name, &gp, &go);
 	else
 		gf = ISC_FALSE;
@@ -2298,7 +2300,7 @@ dns_name_settotextfilter(dns_name_totextfilter_t proc) {
 			result = ISC_R_UNEXPECTED;
 		return (result);
 	}
-	
+
 	mem = isc_mem_get(thread_key_mctx, sizeof(*mem));
 	if (mem == NULL)
 		return (ISC_R_NOMEMORY);
diff --git a/contrib/bind9/lib/dns/ncache.c b/contrib/bind9/lib/dns/ncache.c
index 1fdc5c8..af0450b 100644
--- a/contrib/bind9/lib/dns/ncache.c
+++ b/contrib/bind9/lib/dns/ncache.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ncache.c,v 1.36.18.3 2005/04/29 00:15:59 marka Exp $ */
+/* $Id: ncache.c,v 1.43 2008/09/25 04:02:38 tbox Exp $ */
 
 /*! \file */
 
@@ -30,6 +30,9 @@
 #include <dns/rdata.h>
 #include <dns/rdatalist.h>
 #include <dns/rdataset.h>
+#include <dns/rdatastruct.h>
+
+#define DNS_NCACHE_RDATA 20U
 
 /*
  * The format of an ncache rdata is a sequence of one or more records of
@@ -92,6 +95,16 @@ dns_ncache_add(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
 	       dns_rdatatype_t covers, isc_stdtime_t now, dns_ttl_t maxttl,
 	       dns_rdataset_t *addedrdataset)
 {
+	return (dns_ncache_addoptout(message, cache, node, covers, now, maxttl,
+				    ISC_FALSE, addedrdataset));
+}
+
+isc_result_t
+dns_ncache_addoptout(dns_message_t *message, dns_db_t *cache,
+		     dns_dbnode_t *node, dns_rdatatype_t covers,
+		     isc_stdtime_t now, dns_ttl_t maxttl,
+		     isc_boolean_t optout, dns_rdataset_t *addedrdataset)
+{
 	isc_result_t result;
 	isc_buffer_t buffer;
 	isc_region_t r;
@@ -100,10 +113,11 @@ dns_ncache_add(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
 	dns_name_t *name;
 	dns_ttl_t ttl;
 	dns_trust_t trust;
-	dns_rdata_t rdata = DNS_RDATA_INIT;
+	dns_rdata_t rdata[DNS_NCACHE_RDATA];
 	dns_rdataset_t ncrdataset;
 	dns_rdatalist_t ncrdatalist;
 	unsigned char data[4096];
+	unsigned int next = 0;
 
 	/*
 	 * Convert the authority data from 'message' into a negative cache
@@ -118,7 +132,17 @@ dns_ncache_add(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
 	 */
 
 	/*
-	 * First, build an ncache rdata in buffer.
+	 * Initialize the list.
+	 */
+	ncrdatalist.rdclass = dns_db_class(cache);
+	ncrdatalist.type = 0;
+	ncrdatalist.covers = covers;
+	ncrdatalist.ttl = maxttl;
+	ISC_LIST_INIT(ncrdatalist.rdata);
+	ISC_LINK_INIT(&ncrdatalist, link);
+
+	/*
+	 * Build an ncache rdatas into buffer.
 	 */
 	ttl = maxttl;
 	trust = 0xffff;
@@ -142,7 +166,8 @@ dns_ncache_add(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
 				if (type == dns_rdatatype_rrsig)
 					type = rdataset->covers;
 				if (type == dns_rdatatype_soa ||
-				    type == dns_rdatatype_nsec) {
+				    type == dns_rdatatype_nsec ||
+				    type == dns_rdatatype_nsec3) {
 					if (ttl > rdataset->ttl)
 						ttl = rdataset->ttl;
 					if (trust > rdataset->trust)
@@ -171,6 +196,21 @@ dns_ncache_add(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
 							       &buffer);
 					if (result != ISC_R_SUCCESS)
 						return (result);
+
+					if (next >= DNS_NCACHE_RDATA)
+						return (ISC_R_NOSPACE);
+					dns_rdata_init(&rdata[next]);
+					isc_buffer_remainingregion(&buffer, &r);
+					rdata[next].data = r.base;
+					rdata[next].length = r.length;
+					rdata[next].rdclass =
+						ncrdatalist.rdclass;
+					rdata[next].type = 0;
+					rdata[next].flags = 0;
+					ISC_LIST_APPEND(ncrdatalist.rdata,
+							&rdata[next], link);
+					isc_buffer_forward(&buffer, r.length);
+					next++;
 				}
 			}
 		}
@@ -226,27 +266,24 @@ dns_ncache_add(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
 			trust = dns_trust_authauthority;
 		} else
 			trust = dns_trust_additional;
+		/*
+		 * Now add it to the cache.
+		 */
+		if (next >= DNS_NCACHE_RDATA)
+			return (ISC_R_NOSPACE);
+		dns_rdata_init(&rdata[next]);
+		isc_buffer_remainingregion(&buffer, &r);
+		rdata[next].data = r.base;
+		rdata[next].length = r.length;
+		rdata[next].rdclass = ncrdatalist.rdclass;
+		rdata[next].type = 0;
+		rdata[next].flags = 0;
+		ISC_LIST_APPEND(ncrdatalist.rdata, &rdata[next], link);
 	}
 
-	/*
-	 * Now add it to the cache.
-	 */
 	INSIST(trust != 0xffff);
-	isc_buffer_usedregion(&buffer, &r);
-	rdata.data = r.base;
-	rdata.length = r.length;
-	rdata.rdclass = dns_db_class(cache);
-	rdata.type = 0;
-	rdata.flags = 0;
-
-	ncrdatalist.rdclass = rdata.rdclass;
-	ncrdatalist.type = 0;
-	ncrdatalist.covers = covers;
-	ncrdatalist.ttl = ttl;
-	ISC_LIST_INIT(ncrdatalist.rdata);
-	ISC_LINK_INIT(&ncrdatalist, link);
 
-	ISC_LIST_APPEND(ncrdatalist.rdata, &rdata, link);
+	ncrdatalist.ttl = ttl;
 
 	dns_rdataset_init(&ncrdataset);
 	RUNTIME_CHECK(dns_rdatalist_tordataset(&ncrdatalist, &ncrdataset)
@@ -254,6 +291,8 @@ dns_ncache_add(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
 	ncrdataset.trust = trust;
 	if (message->rcode == dns_rcode_nxdomain)
 		ncrdataset.attributes |= DNS_RDATASETATTR_NXDOMAIN;
+	if (optout)
+		ncrdataset.attributes |= DNS_RDATASETATTR_OPTOUT;
 
 	return (dns_db_addrdataset(cache, node, NULL, now, &ncrdataset,
 				   0, addedrdataset));
@@ -281,18 +320,14 @@ dns_ncache_towire(dns_rdataset_t *rdataset, dns_compress_t *cctx,
 	REQUIRE(rdataset != NULL);
 	REQUIRE(rdataset->type == 0);
 
-	result = dns_rdataset_first(rdataset);
-	if (result != ISC_R_SUCCESS)
-		return (result);
-	dns_rdataset_current(rdataset, &rdata);
-	INSIST(dns_rdataset_next(rdataset) == ISC_R_NOMORE);
-	isc_buffer_init(&source, rdata.data, rdata.length);
-	isc_buffer_add(&source, rdata.length);
-
 	savedbuffer = *target;
-
 	count = 0;
-	do {
+
+	result = dns_rdataset_first(rdataset);
+	while (result == ISC_R_SUCCESS) {
+		dns_rdataset_current(rdataset, &rdata);
+		isc_buffer_init(&source, rdata.data, rdata.length);
+		isc_buffer_add(&source, rdata.length);
 		dns_name_init(&name, NULL);
 		isc_buffer_remainingregion(&source, &remaining);
 		dns_name_fromregion(&name, &remaining);
@@ -370,8 +405,12 @@ dns_ncache_towire(dns_rdataset_t *rdataset, dns_compress_t *cctx,
 
 			count++;
 		}
-		isc_buffer_remainingregion(&source, &remaining);
-	} while (remaining.length > 0);
+		INSIST(isc_buffer_remaininglength(&source) == 0);
+		result = dns_rdataset_next(rdataset);
+		dns_rdata_reset(&rdata);
+	}
+	if (result != ISC_R_NOMORE)
+		goto rollback;
 
 	*countp = count;
 
@@ -478,6 +517,8 @@ static dns_rdatasetmethods_t rdataset_methods = {
 	NULL,
 	NULL,
 	NULL,
+	NULL,
+	NULL,
 	NULL
 };
 
@@ -491,8 +532,6 @@ dns_ncache_getrdataset(dns_rdataset_t *ncacherdataset, dns_name_t *name,
 	isc_buffer_t source;
 	dns_name_t tname;
 	dns_rdatatype_t ttype;
-	unsigned int i, rcount;
-	isc_uint16_t length;
 
 	REQUIRE(ncacherdataset != NULL);
 	REQUIRE(ncacherdataset->type == 0);
@@ -501,14 +540,10 @@ dns_ncache_getrdataset(dns_rdataset_t *ncacherdataset, dns_name_t *name,
 	REQUIRE(type != dns_rdatatype_rrsig);
 
 	result = dns_rdataset_first(ncacherdataset);
-	if (result != ISC_R_SUCCESS)
-		return (result);
-	dns_rdataset_current(ncacherdataset, &rdata);
-	INSIST(dns_rdataset_next(ncacherdataset) == ISC_R_NOMORE);
-	isc_buffer_init(&source, rdata.data, rdata.length);
-	isc_buffer_add(&source, rdata.length);
-
-	do {
+	while (result == ISC_R_SUCCESS) {
+		dns_rdataset_current(ncacherdataset, &rdata);
+		isc_buffer_init(&source, rdata.data, rdata.length);
+		isc_buffer_add(&source, rdata.length);
 		dns_name_init(&tname, NULL);
 		isc_buffer_remainingregion(&source, &remaining);
 		dns_name_fromregion(&tname, &remaining);
@@ -523,21 +558,15 @@ dns_ncache_getrdataset(dns_rdataset_t *ncacherdataset, dns_name_t *name,
 			isc_buffer_remainingregion(&source, &remaining);
 			break;
 		}
-
-		rcount = isc_buffer_getuint16(&source);
-		for (i = 0; i < rcount; i++) {
-			isc_buffer_remainingregion(&source, &remaining);
-			INSIST(remaining.length >= 2);
-			length = isc_buffer_getuint16(&source);
-			isc_buffer_remainingregion(&source, &remaining);
-			INSIST(remaining.length >= length);
-			isc_buffer_forward(&source, length);
-		}
-		isc_buffer_remainingregion(&source, &remaining);
-	} while (remaining.length > 0);
-
-	if (remaining.length == 0)
+		result = dns_rdataset_next(ncacherdataset);
+		dns_rdata_reset(&rdata);
+	}
+	if (result == ISC_R_NOMORE)
 		return (ISC_R_NOTFOUND);
+	if (result != ISC_R_SUCCESS)
+		return (result);
+
+	INSIST(remaining.length != 0);
 
 	rdataset->methods = &rdataset_methods;
 	rdataset->rdclass = ncacherdataset->rdclass;
@@ -555,5 +584,75 @@ dns_ncache_getrdataset(dns_rdataset_t *ncacherdataset, dns_name_t *name,
 	 */
 	rdataset->privateuint4 = 0;
 	rdataset->private5 = NULL;
+	rdataset->private6 = NULL;
 	return (ISC_R_SUCCESS);
 }
+
+void
+dns_ncache_current(dns_rdataset_t *ncacherdataset, dns_name_t *found,
+		   dns_rdataset_t *rdataset)
+{
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	isc_region_t remaining, sigregion;
+	isc_buffer_t source;
+	dns_name_t tname;
+	dns_rdatatype_t type;
+	unsigned int count;
+	dns_rdata_rrsig_t rrsig;
+	unsigned char *raw;
+
+	REQUIRE(ncacherdataset != NULL);
+	REQUIRE(ncacherdataset->type == 0);
+	REQUIRE(found != NULL);
+	REQUIRE(!dns_rdataset_isassociated(rdataset));
+
+	dns_rdataset_current(ncacherdataset, &rdata);
+	isc_buffer_init(&source, rdata.data, rdata.length);
+	isc_buffer_add(&source, rdata.length);
+
+	dns_name_init(&tname, NULL);
+	isc_buffer_remainingregion(&source, &remaining);
+	dns_name_fromregion(found, &remaining);
+	INSIST(remaining.length >= found->length);
+	isc_buffer_forward(&source, found->length);
+	remaining.length -= found->length;
+
+	INSIST(remaining.length >= 4);
+	type = isc_buffer_getuint16(&source);
+	isc_buffer_remainingregion(&source, &remaining);
+
+	rdataset->methods = &rdataset_methods;
+	rdataset->rdclass = ncacherdataset->rdclass;
+	rdataset->type = type;
+	if (type == dns_rdatatype_rrsig) {
+		/*
+		 * Extract covers from RRSIG.
+		 */
+		raw = remaining.base;
+		count = raw[0] * 256 + raw[1];
+		INSIST(count > 0);
+		raw += 2;
+		sigregion.length = raw[0] * 256 + raw[1];
+		raw += 2;
+		sigregion.base = raw;
+		dns_rdata_reset(&rdata);
+		dns_rdata_fromregion(&rdata, rdataset->rdclass,
+				     rdataset->type, &sigregion);
+		(void)dns_rdata_tostruct(&rdata, &rrsig, NULL);
+		rdataset->covers = rrsig.covered;
+	} else
+		rdataset->covers = 0;
+	rdataset->ttl = ncacherdataset->ttl;
+	rdataset->trust = ncacherdataset->trust;
+	rdataset->private1 = NULL;
+	rdataset->private2 = NULL;
+
+	rdataset->private3 = remaining.base;
+
+	/*
+	 * Reset iterator state.
+	 */
+	rdataset->privateuint4 = 0;
+	rdataset->private5 = NULL;
+	rdataset->private6 = NULL;
+}
diff --git a/contrib/bind9/lib/dns/nsec.c b/contrib/bind9/lib/dns/nsec.c
index c1de67e..39f409c 100644
--- a/contrib/bind9/lib/dns/nsec.c
+++ b/contrib/bind9/lib/dns/nsec.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: nsec.c,v 1.5.20.2 2005/04/29 00:15:59 marka Exp $ */
+/* $Id: nsec.c,v 1.11.48.2 2009/01/06 23:47:26 tbox Exp $ */
 
 /*! \file */
 
@@ -33,6 +33,8 @@
 #include <dns/rdatastruct.h>
 #include <dns/result.h>
 
+#include <dst/dst.h>
+
 #define RETERR(x) do { \
 	result = (x); \
 	if (result != ISC_R_SUCCESS) \
@@ -88,6 +90,7 @@ dns_nsec_buildrdata(dns_db_t *db, dns_dbversion_t *version,
 	 */
 	bm = r.base + r.length + 512;
 	nsec_bits = r.base + r.length;
+	set_bit(bm, dns_rdatatype_rrsig, 1);
 	set_bit(bm, dns_rdatatype_nsec, 1);
 	max_type = dns_rdatatype_nsec;
 	dns_rdataset_init(&rdataset);
@@ -100,7 +103,9 @@ dns_nsec_buildrdata(dns_db_t *db, dns_dbversion_t *version,
 	     result = dns_rdatasetiter_next(rdsiter))
 	{
 		dns_rdatasetiter_current(rdsiter, &rdataset);
-		if (rdataset.type != dns_rdatatype_nsec) {
+		if (rdataset.type != dns_rdatatype_nsec &&
+		    rdataset.type != dns_rdatatype_nsec3 &&
+		    rdataset.type != dns_rdatatype_rrsig) {
 			if (rdataset.type > max_type)
 				max_type = rdataset.type;
 			set_bit(bm, rdataset.type, 1);
@@ -197,7 +202,7 @@ dns_nsec_typepresent(dns_rdata_t *nsec, dns_rdatatype_t type) {
 	/* This should never fail */
 	result = dns_rdata_tostruct(nsec, &nsecstruct, NULL);
 	INSIST(result == ISC_R_SUCCESS);
-	
+
 	present = ISC_FALSE;
 	for (i = 0; i < nsecstruct.len; i += len) {
 		INSIST(i + 2 <= nsecstruct.len);
@@ -215,6 +220,58 @@ dns_nsec_typepresent(dns_rdata_t *nsec, dns_rdatatype_t type) {
 						   type % 256));
 		break;
 	}
-	dns_rdata_freestruct(&nsec);
+	dns_rdata_freestruct(&nsecstruct);
 	return (present);
 }
+
+isc_result_t
+dns_nsec_nseconly(dns_db_t *db, dns_dbversion_t *version,
+		  isc_boolean_t *answer)
+{
+	dns_dbnode_t *node = NULL;
+	dns_rdataset_t rdataset;
+	dns_rdata_dnskey_t dnskey;
+	isc_result_t result;
+
+	REQUIRE(answer != NULL);
+
+	dns_rdataset_init(&rdataset);
+
+	result = dns_db_getoriginnode(db, &node);
+	if (result != ISC_R_SUCCESS)
+		return (result);
+
+	result = dns_db_findrdataset(db, node, version, dns_rdatatype_dnskey,
+				     0, 0, &rdataset, NULL);
+	dns_db_detachnode(db, &node);
+
+	if (result == ISC_R_NOTFOUND) {
+		*answer = ISC_FALSE;
+		return (ISC_R_SUCCESS);
+	}
+	if (result != ISC_R_SUCCESS)
+		return (result);
+	for (result = dns_rdataset_first(&rdataset);
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdataset_next(&rdataset)) {
+		dns_rdata_t rdata = DNS_RDATA_INIT;
+
+		dns_rdataset_current(&rdataset, &rdata);
+		result = dns_rdata_tostruct(&rdata, &dnskey, NULL);
+		RUNTIME_CHECK(result == ISC_R_SUCCESS);
+
+		if (dnskey.algorithm == DST_ALG_RSAMD5 ||
+		    dnskey.algorithm == DST_ALG_RSASHA1 ||
+		    dnskey.algorithm == DST_ALG_DSA ||
+		    dnskey.algorithm == DST_ALG_ECC)
+			break;
+	}
+	dns_rdataset_disassociate(&rdataset);
+	if (result == ISC_R_SUCCESS)
+		*answer = ISC_TRUE;
+	if (result == ISC_R_NOMORE) {
+		*answer = ISC_FALSE;
+		result = ISC_R_SUCCESS;
+	}
+	return (result);
+}
diff --git a/contrib/bind9/lib/dns/nsec3.c b/contrib/bind9/lib/dns/nsec3.c
new file mode 100644
index 0000000..54a6993
--- /dev/null
+++ b/contrib/bind9/lib/dns/nsec3.c
@@ -0,0 +1,1377 @@
+/*
+ * Copyright (C) 2006, 2008  Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or 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: nsec3.c,v 1.6 2008/11/17 23:46:42 marka Exp $ */
+
+#include <config.h>
+
+#include <isc/base32.h>
+#include <isc/buffer.h>
+#include <isc/hex.h>
+#include <isc/iterated_hash.h>
+#include <isc/string.h>
+#include <isc/util.h>
+
+#include <dst/dst.h>
+
+#include <dns/db.h>
+#include <dns/dbiterator.h>
+#include <dns/diff.h>
+#include <dns/fixedname.h>
+#include <dns/nsec3.h>
+#include <dns/rdata.h>
+#include <dns/rdatalist.h>
+#include <dns/rdataset.h>
+#include <dns/rdatasetiter.h>
+#include <dns/rdatastruct.h>
+#include <dns/result.h>
+
+#define CHECK(x) do { \
+	result = (x); \
+	if (result != ISC_R_SUCCESS) \
+		goto failure; \
+	} while (0)
+
+#define OPTOUT(x) (((x) & DNS_NSEC3FLAG_OPTOUT) != 0)
+#define CREATE(x) (((x) & DNS_NSEC3FLAG_CREATE) != 0)
+#define REMOVE(x) (((x) & DNS_NSEC3FLAG_REMOVE) != 0)
+
+static void
+set_bit(unsigned char *array, unsigned int index, unsigned int bit) {
+	unsigned int shift, mask;
+
+	shift = 7 - (index % 8);
+	mask = 1 << shift;
+
+	if (bit != 0)
+		array[index / 8] |= mask;
+	else
+		array[index / 8] &= (~mask & 0xFF);
+}
+
+static unsigned int
+bit_isset(unsigned char *array, unsigned int index) {
+	unsigned int byte, shift, mask;
+
+	byte = array[index / 8];
+	shift = 7 - (index % 8);
+	mask = 1 << shift;
+
+	return ((byte & mask) != 0);
+}
+
+isc_result_t
+dns_nsec3_buildrdata(dns_db_t *db, dns_dbversion_t *version,
+		     dns_dbnode_t *node, unsigned int hashalg,
+		     unsigned int flags, unsigned int iterations,
+		     const unsigned char *salt, size_t salt_length,
+		     const unsigned char *nexthash, size_t hash_length,
+		     unsigned char *buffer, dns_rdata_t *rdata)
+{
+	isc_result_t result;
+	dns_rdataset_t rdataset;
+	isc_region_t r;
+	unsigned int i, window;
+	int octet;
+	isc_boolean_t found;
+
+	unsigned char *nsec_bits, *bm;
+	unsigned int max_type;
+	dns_rdatasetiter_t *rdsiter;
+	unsigned char *p;
+
+	REQUIRE(salt_length < 256U);
+	REQUIRE(hash_length < 256U);
+	REQUIRE(flags <= 0xffU);
+	REQUIRE(hashalg <= 0xffU);
+	REQUIRE(iterations <= 0xffffU);
+
+	switch (hashalg) {
+	case dns_hash_sha1:
+		REQUIRE(hash_length == ISC_SHA1_DIGESTLENGTH);
+		break;
+	}
+
+	memset(buffer, 0, DNS_NSEC3_BUFFERSIZE);
+
+	p = buffer;
+
+	*p++ = hashalg;
+	*p++ = flags;
+
+	*p++ = iterations >> 8;
+	*p++ = iterations;
+
+	*p++ = salt_length;
+	memcpy(p, salt, salt_length);
+	p += salt_length;
+
+	*p++ = hash_length;
+	memcpy(p, nexthash, hash_length);
+	p += hash_length;
+
+	r.length = p - buffer;
+	r.base = buffer;
+
+	/*
+	 * Use the end of the space for a raw bitmap leaving enough
+	 * space for the window identifiers and length octets.
+	 */
+	bm = r.base + r.length + 512;
+	nsec_bits = r.base + r.length;
+	max_type = 0;
+	if (node == NULL)
+		goto collapse_bitmap;
+	dns_rdataset_init(&rdataset);
+	rdsiter = NULL;
+	result = dns_db_allrdatasets(db, node, version, 0, &rdsiter);
+	if (result != ISC_R_SUCCESS)
+		return (result);
+	found = ISC_FALSE;
+	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_nsec &&
+		    rdataset.type != dns_rdatatype_nsec3 &&
+		    rdataset.type != dns_rdatatype_rrsig) {
+			if (rdataset.type > max_type)
+				max_type = rdataset.type;
+			set_bit(bm, rdataset.type, 1);
+			/* Don't set RRSIG for insecure delegation. */
+			if (rdataset.type != dns_rdatatype_ns)
+				found = ISC_TRUE;
+		}
+		dns_rdataset_disassociate(&rdataset);
+	}
+	if (found) {
+		if (dns_rdatatype_rrsig > max_type)
+			max_type = dns_rdatatype_rrsig;
+		set_bit(bm, dns_rdatatype_rrsig, 1);
+	}
+
+	/*
+	 * At zone cuts, deny the existence of glue in the parent zone.
+	 */
+	if (bit_isset(bm, dns_rdatatype_ns) &&
+	    ! bit_isset(bm, dns_rdatatype_soa)) {
+		for (i = 0; i <= max_type; i++) {
+			if (bit_isset(bm, i) &&
+			    ! dns_rdatatype_iszonecutauth((dns_rdatatype_t)i))
+				set_bit(bm, i, 0);
+		}
+	}
+
+	dns_rdatasetiter_destroy(&rdsiter);
+	if (result != ISC_R_NOMORE)
+		return (result);
+
+ collapse_bitmap:
+	for (window = 0; window < 256; window++) {
+		if (window * 256 > max_type)
+			break;
+		for (octet = 31; octet >= 0; octet--)
+			if (bm[window * 32 + octet] != 0)
+				break;
+		if (octet < 0)
+			continue;
+		nsec_bits[0] = window;
+		nsec_bits[1] = octet + 1;
+		/*
+		 * Note: potentially overlapping move.
+		 */
+		memmove(&nsec_bits[2], &bm[window * 32], octet + 1);
+		nsec_bits += 3 + octet;
+	}
+	r.length = nsec_bits - r.base;
+	INSIST(r.length <= DNS_NSEC3_BUFFERSIZE);
+	dns_rdata_fromregion(rdata, dns_db_class(db), dns_rdatatype_nsec3, &r);
+
+	return (ISC_R_SUCCESS);
+}
+
+isc_boolean_t
+dns_nsec3_typepresent(dns_rdata_t *rdata, dns_rdatatype_t type) {
+	dns_rdata_nsec3_t nsec3;
+	isc_result_t result;
+	isc_boolean_t present;
+	unsigned int i, len, window;
+
+	REQUIRE(rdata != NULL);
+	REQUIRE(rdata->type == dns_rdatatype_nsec3);
+
+	/* This should never fail */
+	result = dns_rdata_tostruct(rdata, &nsec3, NULL);
+	INSIST(result == ISC_R_SUCCESS);
+
+	present = ISC_FALSE;
+	for (i = 0; i < nsec3.len; i += len) {
+		INSIST(i + 2 <= nsec3.len);
+		window = nsec3.typebits[i];
+		len = nsec3.typebits[i + 1];
+		INSIST(len > 0 && len <= 32);
+		i += 2;
+		INSIST(i + len <= nsec3.len);
+		if (window * 256 > type)
+			break;
+		if ((window + 1) * 256 <= type)
+			continue;
+		if (type < (window * 256) + len * 8)
+			present = ISC_TF(bit_isset(&nsec3.typebits[i],
+						   type % 256));
+		break;
+	}
+	dns_rdata_freestruct(&nsec3);
+	return (present);
+}
+
+isc_result_t
+dns_nsec3_hashname(dns_fixedname_t *result,
+		   unsigned char rethash[NSEC3_MAX_HASH_LENGTH],
+		   size_t *hash_length, dns_name_t *name, dns_name_t *origin,
+		   dns_hash_t hashalg, unsigned int iterations,
+		   const unsigned char *salt, size_t saltlength)
+{
+	unsigned char hash[NSEC3_MAX_HASH_LENGTH];
+	unsigned char nametext[DNS_NAME_FORMATSIZE];
+	dns_fixedname_t fixed;
+	dns_name_t *downcased;
+	isc_buffer_t namebuffer;
+	isc_region_t region;
+	size_t len;
+
+	if (rethash == NULL)
+		rethash = hash;
+
+	memset(rethash, 0, NSEC3_MAX_HASH_LENGTH);
+
+	dns_fixedname_init(&fixed);
+	downcased = dns_fixedname_name(&fixed);
+	dns_name_downcase(name, downcased, NULL);
+
+	/* hash the node name */
+	len = isc_iterated_hash(rethash, hashalg, iterations, salt, saltlength,
+				downcased->ndata, downcased->length);
+	if (len == 0U)
+		return (DNS_R_BADALG);
+
+	if (hash_length != NULL)
+		*hash_length = len;
+
+	/* convert the hash to base32hex */
+	region.base = rethash;
+	region.length = len;
+	isc_buffer_init(&namebuffer, nametext, sizeof nametext);
+	isc_base32hex_totext(&region, 1, "", &namebuffer);
+
+	/* convert the hex to a domain name */
+	dns_fixedname_init(result);
+	return (dns_name_fromtext(dns_fixedname_name(result), &namebuffer,
+				  origin, 0, NULL));
+}
+
+unsigned int
+dns_nsec3_hashlength(dns_hash_t hash) {
+
+	switch (hash) {
+	case dns_hash_sha1: return(ISC_SHA1_DIGESTLENGTH);
+	}
+	return (0);
+}
+
+isc_boolean_t
+dns_nsec3_supportedhash(dns_hash_t hash) {
+	switch (hash) {
+	case dns_hash_sha1: return (ISC_TRUE);
+	}
+	return (ISC_FALSE);
+}
+
+/*%
+ * Update a single RR in version 'ver' of 'db' and log the
+ * update in 'diff'.
+ *
+ * Ensures:
+ * \li  '*tuple' == NULL.  Either the tuple is freed, or its
+ *      ownership has been transferred to the diff.
+ */
+static isc_result_t
+do_one_tuple(dns_difftuple_t **tuple, dns_db_t *db, dns_dbversion_t *ver,
+	     dns_diff_t *diff)
+{
+	dns_diff_t temp_diff;
+	isc_result_t result;
+
+	/*
+	 * Create a singleton diff.
+	 */
+	dns_diff_init(diff->mctx, &temp_diff);
+	temp_diff.resign = diff->resign;
+	ISC_LIST_APPEND(temp_diff.tuples, *tuple, link);
+
+	/*
+	 * Apply it to the database.
+	 */
+	result = dns_diff_apply(&temp_diff, db, ver);
+	ISC_LIST_UNLINK(temp_diff.tuples, *tuple, link);
+	if (result != ISC_R_SUCCESS) {
+		dns_difftuple_free(tuple);
+		return (result);
+	}
+
+	/*
+	 * Merge it into the current pending journal entry.
+	 */
+	dns_diff_appendminimal(diff, tuple);
+
+	/*
+	 * Do not clear temp_diff.
+	 */
+	return (ISC_R_SUCCESS);
+}
+
+/*%
+ * Set '*exists' to true iff the given name exists, to false otherwise.
+ */
+static isc_result_t
+name_exists(dns_db_t *db, dns_dbversion_t *version, dns_name_t *name,
+	    isc_boolean_t *exists)
+{
+	isc_result_t result;
+	dns_dbnode_t *node = NULL;
+	dns_rdatasetiter_t *iter = NULL;
+
+	result = dns_db_findnode(db, name, ISC_FALSE, &node);
+	if (result == ISC_R_NOTFOUND) {
+		*exists = ISC_FALSE;
+		return (ISC_R_SUCCESS);
+	}
+	if (result != ISC_R_SUCCESS)
+		return (result);
+
+	result = dns_db_allrdatasets(db, node, version,
+				     (isc_stdtime_t) 0, &iter);
+	if (result != ISC_R_SUCCESS)
+		goto cleanup_node;
+
+	result = dns_rdatasetiter_first(iter);
+	if (result == ISC_R_SUCCESS) {
+		*exists = ISC_TRUE;
+	} else if (result == ISC_R_NOMORE) {
+		*exists = ISC_FALSE;
+		result = ISC_R_SUCCESS;
+	} else
+		*exists = ISC_FALSE;
+	dns_rdatasetiter_destroy(&iter);
+
+ cleanup_node:
+	dns_db_detachnode(db, &node);
+	return (result);
+}
+
+static isc_boolean_t
+match_nsec3param(const dns_rdata_nsec3_t *nsec3,
+		 const dns_rdata_nsec3param_t *nsec3param)
+{
+	if (nsec3->hash == nsec3param->hash &&
+	    nsec3->iterations == nsec3param->iterations &&
+	    nsec3->salt_length == nsec3param->salt_length &&
+	    !memcmp(nsec3->salt, nsec3param->salt, nsec3->salt_length))
+		return (ISC_TRUE);
+	return (ISC_FALSE);
+}
+
+/*%
+ * Delete NSEC3 records at "name" which match "param", recording the
+ * change in "diff".
+ */
+static isc_result_t
+delete(dns_db_t *db, dns_dbversion_t *version, dns_name_t *name,
+       const dns_rdata_nsec3param_t *nsec3param, dns_diff_t *diff)
+{
+	dns_dbnode_t *node = NULL ;
+	dns_difftuple_t *tuple = NULL;
+	dns_rdata_nsec3_t nsec3;
+	dns_rdataset_t rdataset;
+	isc_result_t result;
+
+	result = dns_db_findnsec3node(db, name, ISC_FALSE, &node);
+	if (result == ISC_R_NOTFOUND)
+		return (ISC_R_SUCCESS);
+	if (result != ISC_R_SUCCESS)
+		return (result);
+
+	dns_rdataset_init(&rdataset);
+	result = dns_db_findrdataset(db, node, version, dns_rdatatype_nsec3, 0,
+				     (isc_stdtime_t) 0, &rdataset, NULL);
+
+	if (result == ISC_R_NOTFOUND) {
+		result = ISC_R_SUCCESS;
+		goto cleanup_node;
+	}
+	if (result != ISC_R_SUCCESS)
+		goto cleanup_node;
+
+	for (result = dns_rdataset_first(&rdataset);
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdataset_next(&rdataset))
+	{
+		dns_rdata_t rdata = DNS_RDATA_INIT;
+		dns_rdataset_current(&rdataset, &rdata);
+		CHECK(dns_rdata_tostruct(&rdata, &nsec3, NULL));
+
+		if (!match_nsec3param(&nsec3, nsec3param))
+			continue;
+
+		result = dns_difftuple_create(diff->mctx, DNS_DIFFOP_DEL, name,
+					      rdataset.ttl, &rdata, &tuple);
+		if (result != ISC_R_SUCCESS)
+			goto failure;
+		result = do_one_tuple(&tuple, db, version, diff);
+		if (result != ISC_R_SUCCESS)
+			goto failure;
+	}
+	if (result != ISC_R_NOMORE)
+		goto failure;
+	result = ISC_R_SUCCESS;
+
+ failure:
+	dns_rdataset_disassociate(&rdataset);
+ cleanup_node:
+	dns_db_detachnode(db, &node);
+
+	return (result);
+}
+
+#ifndef RFC5155_STRICT
+static isc_boolean_t
+better_param(dns_rdataset_t *nsec3paramset, dns_rdata_t *param) {
+	dns_rdataset_t rdataset;
+	isc_result_t result;
+
+	if (REMOVE(param->data[1]))
+		return (ISC_TRUE);
+
+	dns_rdataset_init(&rdataset);
+	dns_rdataset_clone(nsec3paramset, &rdataset);
+	for (result = dns_rdataset_first(&rdataset);
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdataset_next(&rdataset)) {
+		dns_rdata_t rdata =  DNS_RDATA_INIT;
+		dns_rdataset_current(&rdataset, &rdata);
+		if (rdata.length != param->length)
+			continue;
+		if (rdata.data[0] != param->data[0] ||
+		    REMOVE(rdata.data[1]) ||
+		    rdata.data[2] != param->data[2] ||
+		    rdata.data[3] != param->data[3] ||
+		    rdata.data[4] != param->data[4] ||
+		    memcmp(&rdata.data[5], &param->data[5], param->data[4]))
+			continue;
+		if (CREATE(rdata.data[1]) && !CREATE(param->data[1])) {
+			dns_rdataset_disassociate(&rdataset);
+			return (ISC_TRUE);
+		}
+	}
+	dns_rdataset_disassociate(&rdataset);
+	return (ISC_FALSE);
+}
+#endif
+
+static isc_result_t
+find_nsec3(dns_rdata_nsec3_t *nsec3, dns_rdataset_t *rdataset,
+	   const dns_rdata_nsec3param_t *nsec3param)
+{
+	isc_result_t result;
+	for (result = dns_rdataset_first(rdataset);
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdataset_next(rdataset)) {
+		dns_rdata_t rdata = DNS_RDATA_INIT;
+
+		dns_rdataset_current(rdataset, &rdata);
+		CHECK(dns_rdata_tostruct(&rdata, nsec3, NULL));
+		dns_rdata_reset(&rdata);
+		if (match_nsec3param(nsec3, nsec3param))
+			break;
+	}
+ failure:
+	return (result);
+}
+
+isc_result_t
+dns_nsec3_addnsec3(dns_db_t *db, dns_dbversion_t *version,
+		   dns_name_t *name, const dns_rdata_nsec3param_t *nsec3param,
+		   dns_ttl_t nsecttl, isc_boolean_t unsecure, dns_diff_t *diff)
+{
+	dns_dbiterator_t *dbit = NULL;
+	dns_dbnode_t *node = NULL;
+	dns_dbnode_t *newnode = NULL;
+	dns_difftuple_t *tuple = NULL;
+	dns_fixedname_t fixed;
+	dns_fixedname_t fprev;
+	dns_hash_t hash;
+	dns_name_t *hashname;
+	dns_name_t *origin;
+	dns_name_t *prev;
+	dns_name_t empty;
+	dns_rdata_nsec3_t nsec3;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	dns_rdataset_t rdataset;
+	int pass;
+	isc_boolean_t exists;
+	isc_boolean_t remove_unsecure = ISC_FALSE;
+	isc_uint8_t flags;
+	isc_buffer_t buffer;
+	isc_result_t result;
+	unsigned char *old_next;
+	unsigned char *salt;
+	unsigned char nexthash[NSEC3_MAX_HASH_LENGTH];
+	unsigned char nsec3buf[DNS_NSEC3_BUFFERSIZE];
+	unsigned int iterations;
+	unsigned int labels;
+	size_t next_length;
+	unsigned int old_length;
+	unsigned int salt_length;
+
+	dns_fixedname_init(&fixed);
+	hashname = dns_fixedname_name(&fixed);
+	dns_fixedname_init(&fprev);
+	prev = dns_fixedname_name(&fprev);
+
+	dns_rdataset_init(&rdataset);
+
+	origin = dns_db_origin(db);
+
+	/*
+	 * Chain parameters.
+	 */
+	hash = nsec3param->hash;
+	iterations = nsec3param->iterations;
+	salt_length = nsec3param->salt_length;
+	salt = nsec3param->salt;
+
+	/*
+	 * Default flags for a new chain.
+	 */
+	flags = nsec3param->flags & DNS_NSEC3FLAG_OPTOUT;
+
+	/*
+	 * If this is the first NSEC3 in the chain nexthash will
+	 * remain pointing to itself.
+	 */
+	next_length = sizeof(nexthash);
+	CHECK(dns_nsec3_hashname(&fixed, nexthash, &next_length,
+				 name, origin, hash, iterations,
+				 salt, salt_length));
+
+	/*
+	 * Create the node if it doesn't exist and hold
+	 * a reference to it until we have added the NSEC3.
+	 */
+	CHECK(dns_db_findnsec3node(db, hashname, ISC_TRUE, &newnode));
+
+	/*
+	 * Seek the iterator to the 'newnode'.
+	 */
+	CHECK(dns_db_createiterator(db, DNS_DB_NSEC3ONLY, &dbit));
+	CHECK(dns_dbiterator_seek(dbit, hashname));
+	CHECK(dns_dbiterator_pause(dbit));
+	result = dns_db_findrdataset(db, newnode, version, dns_rdatatype_nsec3,
+				     0, (isc_stdtime_t) 0, &rdataset, NULL);
+	/*
+	 * If we updating a existing NSEC3 then find its
+	 * next field.
+	 */
+	if (result == ISC_R_SUCCESS) {
+		result = find_nsec3(&nsec3, &rdataset, nsec3param);
+		if (result == ISC_R_SUCCESS) {
+			if (!CREATE(nsec3param->flags))
+				flags = nsec3.flags;
+			next_length = nsec3.next_length;
+			INSIST(next_length <= sizeof(nexthash));
+			memcpy(nexthash, nsec3.next, next_length);
+			dns_rdataset_disassociate(&rdataset);
+			/*
+			 * If the NSEC3 is not for a unsecure delegation then
+			 * we are just updating it.  If it is for a unsecure
+			 * delegation then we need find out if we need to
+			 * remove the NSEC3 record or not by examining the
+			 * previous NSEC3 record.
+			 */
+			if (!unsecure)
+				goto addnsec3;
+			else
+				remove_unsecure = ISC_TRUE;
+		} else {
+			dns_rdataset_disassociate(&rdataset);
+			if (result != ISC_R_NOMORE)
+				goto failure;
+		}
+	}
+
+	/*
+	 * Find the previous NSEC3 (if any) and update it if required.
+	 */
+	pass = 0;
+	do {
+		result = dns_dbiterator_prev(dbit);
+		if (result == ISC_R_NOMORE) {
+			pass++;
+			CHECK(dns_dbiterator_last(dbit));
+		}
+		CHECK(dns_dbiterator_current(dbit, &node, prev));
+		CHECK(dns_dbiterator_pause(dbit));
+		result = dns_db_findrdataset(db, node, version,
+					     dns_rdatatype_nsec3, 0,
+					     (isc_stdtime_t) 0, &rdataset,
+					     NULL);
+		dns_db_detachnode(db, &node);
+		if (result != ISC_R_SUCCESS)
+			continue;
+
+		result = find_nsec3(&nsec3, &rdataset, nsec3param);
+		if (result == ISC_R_NOMORE) {
+			dns_rdataset_disassociate(&rdataset);
+			continue;
+		}
+		if (result != ISC_R_SUCCESS)
+			goto failure;
+
+		if (remove_unsecure) {
+			dns_rdataset_disassociate(&rdataset);
+			/*
+			 * We have found the previous NSEC3 record and can now
+			 * see if the existing NSEC3 record needs to be
+			 * updated or deleted.
+			 */
+			if (!OPTOUT(nsec3.flags)) {
+				/*
+				 * Just update the NSEC3 record.
+				 */
+				goto addnsec3;
+			} else {
+				/*
+				 * This is actually a deletion not a add.
+				 */
+				result = dns_nsec3_delnsec3(db, version, name,
+							    nsec3param, diff);
+				goto failure;
+			}
+		} else {
+			/*
+			 * Is this is a unsecure delegation we are adding?
+			 * If so no change is required.
+			 */
+			if (OPTOUT(nsec3.flags) && unsecure) {
+				dns_rdataset_disassociate(&rdataset);
+				goto failure;
+			}
+		}
+
+		old_next = nsec3.next;
+		old_length = nsec3.next_length;
+
+		/*
+		 * Delete the old previous NSEC3.
+		 */
+		CHECK(delete(db, version, prev, nsec3param, diff));
+
+		/*
+		 * Fixup the previous NSEC3.
+		 */
+		nsec3.next = nexthash;
+		nsec3.next_length = next_length;
+		isc_buffer_init(&buffer, nsec3buf, sizeof(nsec3buf));
+		CHECK(dns_rdata_fromstruct(&rdata, rdataset.rdclass,
+					   dns_rdatatype_nsec3, &nsec3,
+					   &buffer));
+		CHECK(dns_difftuple_create(diff->mctx, DNS_DIFFOP_ADD, prev,
+					   rdataset.ttl, &rdata, &tuple));
+		CHECK(do_one_tuple(&tuple, db, version, diff));
+		INSIST(old_length <= sizeof(nexthash));
+		memcpy(nexthash, old_next, old_length);
+		if (!CREATE(nsec3param->flags))
+			flags = nsec3.flags;
+		dns_rdata_reset(&rdata);
+		dns_rdataset_disassociate(&rdataset);
+		break;
+	} while (pass < 2);
+
+ addnsec3:
+	/*
+	 * Create the NSEC3 RDATA.
+	 */
+	CHECK(dns_db_findnode(db, name, ISC_FALSE, &node));
+	CHECK(dns_nsec3_buildrdata(db, version, node, hash, flags, iterations,
+				   salt, salt_length, nexthash, next_length,
+				   nsec3buf, &rdata));
+	dns_db_detachnode(db, &node);
+
+	/*
+	 * Delete the old NSEC3 and record the change.
+	 */
+	CHECK(delete(db, version, hashname, nsec3param, diff));
+	/*
+	 * Add the new NSEC3 and record the change.
+	 */
+	CHECK(dns_difftuple_create(diff->mctx, DNS_DIFFOP_ADD,
+				   hashname, nsecttl, &rdata, &tuple));
+	CHECK(do_one_tuple(&tuple, db, version, diff));
+	INSIST(tuple == NULL);
+	dns_rdata_reset(&rdata);
+	dns_db_detachnode(db, &newnode);
+
+	/*
+	 * Add missing NSEC3 records for empty nodes
+	 */
+	dns_name_init(&empty, NULL);
+	dns_name_clone(name, &empty);
+	do {
+		labels = dns_name_countlabels(&empty) - 1;
+		if (labels <= dns_name_countlabels(origin))
+			break;
+		dns_name_getlabelsequence(&empty, 1, labels, &empty);
+		CHECK(name_exists(db, version, &empty, &exists));
+		if (exists)
+			break;
+		CHECK(dns_nsec3_hashname(&fixed, nexthash, &next_length,
+					 &empty, origin, hash, iterations,
+					 salt, salt_length));
+
+		/*
+		 * Create the node if it doesn't exist and hold
+		 * a reference to it until we have added the NSEC3
+		 * or we discover we don't need to add make a change.
+		 */
+		CHECK(dns_db_findnsec3node(db, hashname, ISC_TRUE, &newnode));
+		result = dns_db_findrdataset(db, newnode, version,
+					     dns_rdatatype_nsec3, 0,
+					     (isc_stdtime_t) 0, &rdataset,
+					     NULL);
+		if (result == ISC_R_SUCCESS) {
+			result = find_nsec3(&nsec3, &rdataset, nsec3param);
+			dns_rdataset_disassociate(&rdataset);
+			if (result == ISC_R_SUCCESS) {
+				dns_db_detachnode(db, &newnode);
+				break;
+			}
+			if (result != ISC_R_NOMORE)
+				goto failure;
+		}
+
+		/*
+		 * Find the previous NSEC3 and update it.
+		 */
+		CHECK(dns_dbiterator_seek(dbit, hashname));
+		pass = 0;
+		do {
+			result = dns_dbiterator_prev(dbit);
+			if (result == ISC_R_NOMORE) {
+				pass++;
+				CHECK(dns_dbiterator_last(dbit));
+			}
+			CHECK(dns_dbiterator_current(dbit, &node, prev));
+			CHECK(dns_dbiterator_pause(dbit));
+			result = dns_db_findrdataset(db, node, version,
+						     dns_rdatatype_nsec3, 0,
+						     (isc_stdtime_t) 0,
+						     &rdataset, NULL);
+			dns_db_detachnode(db, &node);
+			if (result != ISC_R_SUCCESS)
+				continue;
+			result = find_nsec3(&nsec3, &rdataset, nsec3param);
+			if (result == ISC_R_NOMORE) {
+				dns_rdataset_disassociate(&rdataset);
+				continue;
+			}
+			if (result != ISC_R_SUCCESS)
+				goto failure;
+
+			old_next = nsec3.next;
+			old_length = nsec3.next_length;
+
+			/*
+			 * Delete the old previous NSEC3.
+			 */
+			CHECK(delete(db, version, prev, nsec3param, diff));
+
+			/*
+			 * Fixup the previous NSEC3.
+			 */
+			nsec3.next = nexthash;
+			nsec3.next_length = next_length;
+			isc_buffer_init(&buffer, nsec3buf,
+					sizeof(nsec3buf));
+			CHECK(dns_rdata_fromstruct(&rdata, rdataset.rdclass,
+						   dns_rdatatype_nsec3, &nsec3,
+						   &buffer));
+			CHECK(dns_difftuple_create(diff->mctx, DNS_DIFFOP_ADD,
+						   prev, rdataset.ttl, &rdata,
+						   &tuple));
+			CHECK(do_one_tuple(&tuple, db, version, diff));
+			INSIST(old_length <= sizeof(nexthash));
+			memcpy(nexthash, old_next, old_length);
+			if (!CREATE(nsec3param->flags))
+				flags = nsec3.flags;
+			dns_rdata_reset(&rdata);
+			dns_rdataset_disassociate(&rdataset);
+			break;
+		} while (pass < 2);
+
+		INSIST(pass < 2);
+
+		/*
+		 * Create the NSEC3 RDATA for the empty node.
+		 */
+		CHECK(dns_nsec3_buildrdata(db, version, NULL, hash, flags,
+					   iterations, salt, salt_length,
+					   nexthash, next_length, nsec3buf,
+					   &rdata));
+		/*
+		 * Delete the old NSEC3 and record the change.
+		 */
+		CHECK(delete(db, version, hashname, nsec3param, diff));
+
+		/*
+		 * Add the new NSEC3 and record the change.
+		 */
+		CHECK(dns_difftuple_create(diff->mctx, DNS_DIFFOP_ADD,
+					   hashname, nsecttl, &rdata, &tuple));
+		CHECK(do_one_tuple(&tuple, db, version, diff));
+		INSIST(tuple == NULL);
+		dns_rdata_reset(&rdata);
+		dns_db_detachnode(db, &newnode);
+	} while (1);
+
+	if (result == ISC_R_NOMORE)
+		result = ISC_R_SUCCESS;
+
+ failure:
+	if (dbit != NULL)
+		dns_dbiterator_destroy(&dbit);
+	if (dns_rdataset_isassociated(&rdataset))
+		dns_rdataset_disassociate(&rdataset);
+	if (node != NULL)
+		dns_db_detachnode(db, &node);
+	if (newnode != NULL)
+		dns_db_detachnode(db, &newnode);
+	return (result);
+}
+
+/*%
+ * Add NSEC3 records for "name", recording the change in "diff".
+ * The existing NSEC3 records are removed.
+ */
+isc_result_t
+dns_nsec3_addnsec3s(dns_db_t *db, dns_dbversion_t *version,
+		    dns_name_t *name, dns_ttl_t nsecttl,
+		    isc_boolean_t unsecure, dns_diff_t *diff)
+{
+	dns_dbnode_t *node = NULL;
+	dns_rdata_nsec3param_t nsec3param;
+	dns_rdataset_t rdataset;
+	isc_result_t result;
+
+	dns_rdataset_init(&rdataset);
+
+	/*
+	 * Find the NSEC3 parameters for this zone.
+	 */
+	result = dns_db_getoriginnode(db, &node);
+	if (result != ISC_R_SUCCESS)
+		return (result);
+
+	result = dns_db_findrdataset(db, node, version,
+				     dns_rdatatype_nsec3param, 0, 0,
+				     &rdataset, NULL);
+	dns_db_detachnode(db, &node);
+	if (result == ISC_R_NOTFOUND)
+		return (ISC_R_SUCCESS);
+	if (result != ISC_R_SUCCESS)
+		return (result);
+
+	/*
+	 * Update each active NSEC3 chain.
+	 */
+	for (result = dns_rdataset_first(&rdataset);
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdataset_next(&rdataset)) {
+		dns_rdata_t rdata = DNS_RDATA_INIT;
+
+		dns_rdataset_current(&rdataset, &rdata);
+		dns_rdata_tostruct(&rdata, &nsec3param, NULL);
+
+#ifdef RFC5155_STRICT
+		if (nsec3param.flags != 0)
+			continue;
+#else
+		if ((nsec3param.flags & DNS_NSEC3FLAG_REMOVE) != 0)
+			continue;
+		if (better_param(&rdataset, &rdata))
+			continue;
+#endif
+
+		/*
+		 * We have a active chain.  Update it.
+		 */
+		CHECK(dns_nsec3_addnsec3(db, version, name, &nsec3param,
+					 nsecttl, unsecure, diff));
+	}
+	if (result == ISC_R_NOMORE)
+		result = ISC_R_SUCCESS;
+
+ failure:
+	if (dns_rdataset_isassociated(&rdataset))
+		dns_rdataset_disassociate(&rdataset);
+	if (node != NULL)
+		dns_db_detachnode(db, &node);
+
+	return (result);
+}
+
+isc_result_t
+dns_nsec3_delnsec3(dns_db_t *db, dns_dbversion_t *version, dns_name_t *name,
+		   const dns_rdata_nsec3param_t *nsec3param, dns_diff_t *diff)
+{
+	dns_dbiterator_t *dbit = NULL;
+	dns_dbnode_t *node = NULL;
+	dns_difftuple_t *tuple = NULL;
+	dns_fixedname_t fixed;
+	dns_fixedname_t fprev;
+	dns_hash_t hash;
+	dns_name_t *hashname;
+	dns_name_t *origin;
+	dns_name_t *prev;
+	dns_name_t empty;
+	dns_rdata_nsec3_t nsec3;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	dns_rdataset_t rdataset;
+	int pass;
+	isc_boolean_t exists;
+	isc_buffer_t buffer;
+	isc_result_t result;
+	unsigned char *salt;
+	unsigned char nexthash[NSEC3_MAX_HASH_LENGTH];
+	unsigned char nsec3buf[DNS_NSEC3_BUFFERSIZE];
+	unsigned int iterations;
+	unsigned int labels;
+	size_t next_length;
+	unsigned int salt_length;
+
+	dns_fixedname_init(&fixed);
+	hashname = dns_fixedname_name(&fixed);
+	dns_fixedname_init(&fprev);
+	prev = dns_fixedname_name(&fprev);
+
+	dns_rdataset_init(&rdataset);
+
+	origin = dns_db_origin(db);
+
+	/*
+	 * Chain parameters.
+	 */
+	hash = nsec3param->hash;
+	iterations = nsec3param->iterations;
+	salt_length = nsec3param->salt_length;
+	salt = nsec3param->salt;
+
+	/*
+	 * If this is the first NSEC3 in the chain nexthash will
+	 * remain pointing to itself.
+	 */
+	next_length = sizeof(nexthash);
+	CHECK(dns_nsec3_hashname(&fixed, nexthash, &next_length,
+				 name, origin, hash, iterations,
+				 salt, salt_length));
+
+	CHECK(dns_db_createiterator(db, DNS_DB_NSEC3ONLY, &dbit));
+
+	result = dns_dbiterator_seek(dbit, hashname);
+	if (result == ISC_R_NOTFOUND)
+		goto success;
+	if (result != ISC_R_SUCCESS)
+		goto failure;
+
+	CHECK(dns_dbiterator_current(dbit, &node, NULL));
+	CHECK(dns_dbiterator_pause(dbit));
+	result = dns_db_findrdataset(db, node, version, dns_rdatatype_nsec3,
+				     0, (isc_stdtime_t) 0, &rdataset, NULL);
+	dns_db_detachnode(db, &node);
+	if (result == ISC_R_NOTFOUND)
+		goto success;
+	if (result != ISC_R_SUCCESS)
+		goto failure;
+
+	/*
+	 * If we find a existing NSEC3 for this chain then save the
+	 * next field.
+	 */
+	result = find_nsec3(&nsec3, &rdataset, nsec3param);
+	if (result == ISC_R_SUCCESS) {
+		next_length = nsec3.next_length;
+		INSIST(next_length <= sizeof(nexthash));
+		memcpy(nexthash, nsec3.next, next_length);
+	}
+	dns_rdataset_disassociate(&rdataset);
+	if (result == ISC_R_NOMORE)
+		goto success;
+	if (result != ISC_R_SUCCESS)
+		goto failure;
+
+	/*
+	 * Find the previous NSEC3 and update it.
+	 */
+	pass = 0;
+	do {
+		result = dns_dbiterator_prev(dbit);
+		if (result == ISC_R_NOMORE) {
+			pass++;
+			CHECK(dns_dbiterator_last(dbit));
+		}
+		CHECK(dns_dbiterator_current(dbit, &node, prev));
+		CHECK(dns_dbiterator_pause(dbit));
+		result = dns_db_findrdataset(db, node, version,
+					     dns_rdatatype_nsec3, 0,
+					     (isc_stdtime_t) 0, &rdataset,
+					     NULL);
+		dns_db_detachnode(db, &node);
+		if (result != ISC_R_SUCCESS)
+			continue;
+		result = find_nsec3(&nsec3, &rdataset, nsec3param);
+		if (result == ISC_R_NOMORE) {
+			dns_rdataset_disassociate(&rdataset);
+			continue;
+		}
+		if (result != ISC_R_SUCCESS)
+			goto failure;
+
+		/*
+		 * Delete the old previous NSEC3.
+		 */
+		CHECK(delete(db, version, prev, nsec3param, diff));
+
+		/*
+		 * Fixup the previous NSEC3.
+		 */
+		nsec3.next = nexthash;
+		nsec3.next_length = next_length;
+		isc_buffer_init(&buffer, nsec3buf, sizeof(nsec3buf));
+		CHECK(dns_rdata_fromstruct(&rdata, rdataset.rdclass,
+					   dns_rdatatype_nsec3, &nsec3,
+					   &buffer));
+		CHECK(dns_difftuple_create(diff->mctx, DNS_DIFFOP_ADD, prev,
+					   rdataset.ttl, &rdata, &tuple));
+		CHECK(do_one_tuple(&tuple, db, version, diff));
+		dns_rdata_reset(&rdata);
+		dns_rdataset_disassociate(&rdataset);
+		break;
+	} while (pass < 2);
+
+	/*
+	 * Delete the old NSEC3 and record the change.
+	 */
+	CHECK(delete(db, version, hashname, nsec3param, diff));
+
+	/*
+	 *  Delete NSEC3 records for now non active nodes.
+	 */
+	dns_name_init(&empty, NULL);
+	dns_name_clone(name, &empty);
+	do {
+		labels = dns_name_countlabels(&empty) - 1;
+		if (labels <= dns_name_countlabels(origin))
+			break;
+		dns_name_getlabelsequence(&empty, 1, labels, &empty);
+		CHECK(name_exists(db, version, &empty, &exists));
+		if (exists)
+			break;
+
+		CHECK(dns_nsec3_hashname(&fixed, nexthash, &next_length,
+					 &empty, origin, hash, iterations,
+					 salt, salt_length));
+		result = dns_dbiterator_seek(dbit, hashname);
+		if (result == ISC_R_NOTFOUND)
+			goto success;
+		if (result != ISC_R_SUCCESS)
+			goto failure;
+
+		CHECK(dns_dbiterator_current(dbit, &node, NULL));
+		CHECK(dns_dbiterator_pause(dbit));
+		result = dns_db_findrdataset(db, node, version,
+					     dns_rdatatype_nsec3, 0,
+					     (isc_stdtime_t) 0, &rdataset,
+					     NULL);
+		dns_db_detachnode(db, &node);
+		if (result == ISC_R_NOTFOUND)
+			goto success;
+		if (result != ISC_R_SUCCESS)
+			goto failure;
+
+		result = find_nsec3(&nsec3, &rdataset, nsec3param);
+		if (result == ISC_R_SUCCESS) {
+			next_length = nsec3.next_length;
+			INSIST(next_length <= sizeof(nexthash));
+			memcpy(nexthash, nsec3.next, next_length);
+		}
+		dns_rdataset_disassociate(&rdataset);
+		if (result == ISC_R_NOMORE)
+			goto success;
+		if (result != ISC_R_SUCCESS)
+			goto failure;
+
+		pass = 0;
+		do {
+			result = dns_dbiterator_prev(dbit);
+			if (result == ISC_R_NOMORE) {
+				pass++;
+				CHECK(dns_dbiterator_last(dbit));
+			}
+			CHECK(dns_dbiterator_current(dbit, &node, prev));
+			CHECK(dns_dbiterator_pause(dbit));
+			result = dns_db_findrdataset(db, node, version,
+						     dns_rdatatype_nsec3, 0,
+						     (isc_stdtime_t) 0,
+						     &rdataset, NULL);
+			dns_db_detachnode(db, &node);
+			if (result != ISC_R_SUCCESS)
+				continue;
+			result = find_nsec3(&nsec3, &rdataset, nsec3param);
+			if (result == ISC_R_NOMORE) {
+				dns_rdataset_disassociate(&rdataset);
+				continue;
+			}
+			if (result != ISC_R_SUCCESS)
+				goto failure;
+
+			/*
+			 * Delete the old previous NSEC3.
+			 */
+			CHECK(delete(db, version, prev, nsec3param, diff));
+
+			/*
+			 * Fixup the previous NSEC3.
+			 */
+			nsec3.next = nexthash;
+			nsec3.next_length = next_length;
+			isc_buffer_init(&buffer, nsec3buf,
+					sizeof(nsec3buf));
+			CHECK(dns_rdata_fromstruct(&rdata, rdataset.rdclass,
+						   dns_rdatatype_nsec3, &nsec3,
+						   &buffer));
+			CHECK(dns_difftuple_create(diff->mctx, DNS_DIFFOP_ADD,
+						   prev, rdataset.ttl, &rdata,
+						   &tuple));
+			CHECK(do_one_tuple(&tuple, db, version, diff));
+			dns_rdata_reset(&rdata);
+			dns_rdataset_disassociate(&rdataset);
+			break;
+		} while (pass < 2);
+
+		INSIST(pass < 2);
+
+		/*
+		 * Delete the old NSEC3 and record the change.
+		 */
+		CHECK(delete(db, version, hashname, nsec3param, diff));
+	} while (1);
+
+ success:
+	result = ISC_R_SUCCESS;
+
+ failure:
+	if (dbit != NULL)
+		dns_dbiterator_destroy(&dbit);
+	if (dns_rdataset_isassociated(&rdataset))
+		dns_rdataset_disassociate(&rdataset);
+	if (node != NULL)
+		dns_db_detachnode(db, &node);
+	return (result);
+}
+
+isc_result_t
+dns_nsec3_delnsec3s(dns_db_t *db, dns_dbversion_t *version, dns_name_t *name,
+		    dns_diff_t *diff)
+{
+	dns_dbnode_t *node = NULL;
+	dns_rdata_nsec3param_t nsec3param;
+	dns_rdataset_t rdataset;
+	isc_result_t result;
+
+	dns_rdataset_init(&rdataset);
+
+	/*
+	 * Find the NSEC3 parameters for this zone.
+	 */
+	result = dns_db_getoriginnode(db, &node);
+	if (result != ISC_R_SUCCESS)
+		return (result);
+
+	result = dns_db_findrdataset(db, node, version,
+				     dns_rdatatype_nsec3param, 0, 0,
+				     &rdataset, NULL);
+	dns_db_detachnode(db, &node);
+	if (result == ISC_R_NOTFOUND)
+		return (ISC_R_SUCCESS);
+	if (result != ISC_R_SUCCESS)
+		return (result);
+
+	/*
+	 * Update each active NSEC3 chain.
+	 */
+	for (result = dns_rdataset_first(&rdataset);
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdataset_next(&rdataset)) {
+		dns_rdata_t rdata = DNS_RDATA_INIT;
+
+		dns_rdataset_current(&rdataset, &rdata);
+		dns_rdata_tostruct(&rdata, &nsec3param, NULL);
+
+#ifdef RFC5155_STRICT
+		if (nsec3param.flags != 0)
+			continue;
+#else
+		if ((nsec3param.flags & DNS_NSEC3FLAG_REMOVE) != 0)
+			continue;
+		if (better_param(&rdataset, &rdata))
+			continue;
+#endif
+
+		/*
+		 * We have a active chain.  Update it.
+		 */
+		CHECK(dns_nsec3_delnsec3(db, version, name, &nsec3param, diff));
+	}
+	if (result == ISC_R_NOMORE)
+		result = ISC_R_SUCCESS;
+
+ failure:
+	if (dns_rdataset_isassociated(&rdataset))
+		dns_rdataset_disassociate(&rdataset);
+	if (node != NULL)
+		dns_db_detachnode(db, &node);
+
+	return (result);
+}
+
+isc_result_t
+dns_nsec3_active(dns_db_t *db, dns_dbversion_t *version,
+		 isc_boolean_t complete, isc_boolean_t *answer)
+{
+	dns_dbnode_t *node = NULL;
+	dns_rdataset_t rdataset;
+	dns_rdata_nsec3param_t nsec3param;
+	isc_result_t result;
+
+	REQUIRE(answer != NULL);
+
+	dns_rdataset_init(&rdataset);
+
+	result = dns_db_getoriginnode(db, &node);
+	if (result != ISC_R_SUCCESS)
+		return (result);
+
+	result = dns_db_findrdataset(db, node, version,
+				     dns_rdatatype_nsec3param, 0, 0,
+				     &rdataset, NULL);
+	dns_db_detachnode(db, &node);
+
+	if (result == ISC_R_NOTFOUND) {
+		*answer = ISC_FALSE;
+		return (ISC_R_SUCCESS);
+	}
+	if (result != ISC_R_SUCCESS)
+		return (result);
+	for (result = dns_rdataset_first(&rdataset);
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdataset_next(&rdataset)) {
+		dns_rdata_t rdata = DNS_RDATA_INIT;
+
+		dns_rdataset_current(&rdataset, &rdata);
+		result = dns_rdata_tostruct(&rdata, &nsec3param, NULL);
+		RUNTIME_CHECK(result == ISC_R_SUCCESS);
+
+		if ((nsec3param.flags) == 0 ||
+		    (!complete && CREATE(nsec3param.flags)))
+			break;
+	}
+	dns_rdataset_disassociate(&rdataset);
+	if (result == ISC_R_SUCCESS)
+		*answer = ISC_TRUE;
+	if (result == ISC_R_NOMORE) {
+		*answer = ISC_FALSE;
+		result = ISC_R_SUCCESS;
+	}
+	return (result);
+}
+
+isc_result_t
+dns_nsec3_maxiterations(dns_db_t *db, dns_dbversion_t *version,
+			isc_mem_t *mctx, unsigned int *iterationsp)
+{
+	dns_dbnode_t *node = NULL;
+	dns_rdataset_t rdataset;
+	dst_key_t *key = NULL;
+	isc_buffer_t buffer;
+	isc_result_t result;
+	isc_uint16_t bits, minbits = 4096;
+
+	result = dns_db_getoriginnode(db, &node);
+	if (result != ISC_R_SUCCESS)
+		return (result);
+
+	dns_rdataset_init(&rdataset);
+	result = dns_db_findrdataset(db, node, version, dns_rdatatype_dnskey,
+				     0, 0, &rdataset, NULL);
+	dns_db_detachnode(db, &node);
+	if (result == ISC_R_NOTFOUND) {
+		*iterationsp = 0;
+		return (ISC_R_SUCCESS);
+	}
+	if (result != ISC_R_SUCCESS)
+		goto failure;
+
+	for (result = dns_rdataset_first(&rdataset);
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdataset_next(&rdataset)) {
+		dns_rdata_t rdata = DNS_RDATA_INIT;
+
+		dns_rdataset_current(&rdataset, &rdata);
+		isc_buffer_init(&buffer, rdata.data, rdata.length);
+		isc_buffer_add(&buffer, rdata.length);
+		CHECK(dst_key_fromdns(dns_db_origin(db), rdataset.rdclass,
+				      &buffer, mctx, &key));
+		bits = dst_key_getbits(key);
+		dst_key_free(&key);
+		if (minbits > bits)
+			minbits = bits;
+	}
+	if (result != ISC_R_NOMORE)
+		goto failure;
+
+	if (minbits <= 1024)
+		*iterationsp = 150;
+	else if (minbits <= 2048)
+		*iterationsp = 500;
+	else
+		*iterationsp = 2500;
+	result = ISC_R_SUCCESS;
+
+ failure:
+	if (dns_rdataset_isassociated(&rdataset))
+		dns_rdataset_disassociate(&rdataset);
+	return (result);
+}
diff --git a/contrib/bind9/lib/dns/openssl_link.c b/contrib/bind9/lib/dns/openssl_link.c
index bb76e0e..2dc7d7e 100644
--- a/contrib/bind9/lib/dns/openssl_link.c
+++ b/contrib/bind9/lib/dns/openssl_link.c
@@ -1,6 +1,19 @@
 /*
- * Portions Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 1999-2003  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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.
+ *
  * Portions Copyright (C) 1995-2000 by Network Associates, Inc.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -18,7 +31,7 @@
 
 /*
  * Principal Author: Brian Wellington
- * $Id: openssl_link.c,v 1.1.6.12 2007/08/28 07:20:04 tbox Exp $
+ * $Id: openssl_link.c,v 1.22.112.3 2009/02/11 03:07:01 jinmei Exp $
  */
 #ifdef OPENSSL
 
@@ -41,22 +54,36 @@
 #include <openssl/conf.h>
 #include <openssl/crypto.h>
 
-#if defined(CRYPTO_LOCK_ENGINE) && (OPENSSL_VERSION_NUMBER != 0x00907000L)
+#if defined(CRYPTO_LOCK_ENGINE) && (OPENSSL_VERSION_NUMBER >= 0x0090707f)
 #define USE_ENGINE 1
 #endif
 
 #ifdef USE_ENGINE
 #include <openssl/engine.h>
+
+#ifdef ENGINE_ID
+const char *engine_id = ENGINE_ID;
+#else
+const char *engine_id;
+#endif
 #endif
 
 static RAND_METHOD *rm = NULL;
+
 static isc_mutex_t *locks = NULL;
 static int nlocks;
 
 #ifdef USE_ENGINE
 static ENGINE *e;
+static ENGINE *he;
 #endif
 
+#ifdef USE_PKCS11
+static isc_result_t
+dst__openssl_load_engine(const char *name, const char *engine_id,
+			 const char **pre_cmds, int pre_num,
+			 const char **post_cmds, int post_num);
+#endif
 
 static int
 entropy_get(unsigned char *buf, int num) {
@@ -68,6 +95,11 @@ entropy_get(unsigned char *buf, int num) {
 }
 
 static int
+entropy_status(void) {
+	return (dst__entropy_status() > 32);
+}
+
+static int
 entropy_getpseudo(unsigned char *buf, int num) {
 	isc_result_t result;
 	if (num < 0)
@@ -116,23 +148,17 @@ mem_free(void *ptr) {
 
 static void *
 mem_realloc(void *ptr, size_t size) {
-	void *p;
-
 	INSIST(dst__memory_pool != NULL);
-	p = NULL;
-	if (size > 0U) {
-		p = mem_alloc(size);
-		if (p != NULL && ptr != NULL)
-			memcpy(p, ptr, size);
-	}
-	if (ptr != NULL)
-		mem_free(ptr);
-	return (p);
+	return (isc_mem_reallocate(dst__memory_pool, ptr, size));
 }
 
 isc_result_t
 dst__openssl_init() {
 	isc_result_t result;
+#ifdef USE_ENGINE
+	/* const char  *name; */
+	ENGINE *re;
+#endif
 
 #ifdef  DNS_CRYPTO_LEAKS
 	CRYPTO_malloc_debug_init();
@@ -149,6 +175,7 @@ dst__openssl_init() {
 		goto cleanup_mutexalloc;
 	CRYPTO_set_locking_callback(lock_callback);
 	CRYPTO_set_id_callback(id_callback);
+
 	rm = mem_alloc(sizeof(RAND_METHOD));
 	if (rm == NULL) {
 		result = ISC_R_NOMEMORY;
@@ -159,18 +186,87 @@ dst__openssl_init() {
 	rm->cleanup = NULL;
 	rm->add = entropy_add;
 	rm->pseudorand = entropy_getpseudo;
-	rm->status = NULL;
+	rm->status = entropy_status;
 #ifdef USE_ENGINE
-	e = ENGINE_new();
-	if (e == NULL) {
-		result = ISC_R_NOMEMORY;
-		goto cleanup_rm;
+	OPENSSL_config(NULL);
+#ifdef USE_PKCS11
+#ifndef PKCS11_SO_PATH
+#define PKCS11_SO_PATH		"/usr/local/lib/engines/engine_pkcs11.so"
+#endif
+#ifndef PKCS11_MODULE_PATH
+#define PKCS11_MODULE_PATH	"/usr/lib/libpkcs11.so"
+#endif
+	{
+		/*
+		 * to use this to config the PIN, add in openssl.cnf:
+		 *  - at the beginning: "openssl_conf = openssl_def"
+		 *  - at any place these sections:
+		 * [ openssl_def ]
+		 * engines = engine_section
+		 * [ engine_section ]
+		 * pkcs11 = pkcs11_section
+		 * [ pkcs11_section ]
+		 * PIN = my___pin
+		 */
+
+		const char *pre_cmds[] = {
+			"SO_PATH", PKCS11_SO_PATH,
+			"LOAD", NULL,
+			"MODULE_PATH", PKCS11_MODULE_PATH
+		};
+		const char *post_cmds[] = {
+			/* "PIN", "my___pin" */
+		};
+		result = dst__openssl_load_engine("pkcs11", "pkcs11",
+						  pre_cmds, 0,
+						  post_cmds, /*1*/ 0);
+		if (result != ISC_R_SUCCESS)
+			goto cleanup_rm;
 	}
-	ENGINE_set_RAND(e, rm);
-	RAND_set_rand_method(rm);
+#endif /* USE_PKCS11 */
+	if (engine_id != NULL) {
+		e = ENGINE_by_id(engine_id);
+		if (e == NULL) {
+			result = ISC_R_NOTFOUND;
+			goto cleanup_rm;
+		}
+		if (!ENGINE_init(e)) {
+			result = ISC_R_FAILURE;
+			ENGINE_free(e);
+			goto cleanup_rm;
+		}
+		ENGINE_set_default(e, ENGINE_METHOD_ALL);
+		ENGINE_free(e);
+	} else {
+		ENGINE_register_all_complete();
+		for (e = ENGINE_get_first(); e != NULL; e = ENGINE_get_next(e)) {
+
+			/*
+			 * Something weird here. If we call ENGINE_finish()
+			 * ENGINE_get_default_RAND() will fail.
+			 */
+			if (ENGINE_init(e)) {
+				if (he == NULL)
+					he = e;
+			}
+		}
+	}
+	re = ENGINE_get_default_RAND();
+	if (re == NULL) {
+		re = ENGINE_new();
+		if (re == NULL) {
+			result = ISC_R_NOMEMORY;
+			goto cleanup_rm;
+		}
+		ENGINE_set_RAND(re, rm);
+		ENGINE_set_default_RAND(re);
+		ENGINE_free(re);
+	} else
+		ENGINE_finish(re);
+
 #else
 	RAND_set_rand_method(rm);
-#endif
+#endif /* USE_ENGINE */
 	return (ISC_R_SUCCESS);
 
 #ifdef USE_ENGINE
@@ -195,9 +291,15 @@ dst__openssl_destroy() {
 	CONF_modules_unload(1);
 #endif
 	EVP_cleanup();
+#if defined(USE_ENGINE)
+	if (e != NULL) {
+		ENGINE_finish(e);
+		e = NULL;
+	}
 #if defined(USE_ENGINE) && OPENSSL_VERSION_NUMBER >= 0x00907000L
 	ENGINE_cleanup();
 #endif
+#endif
 #if (OPENSSL_VERSION_NUMBER >= 0x00907000L)
 	CRYPTO_cleanup_all_ex_data();
 #endif
@@ -209,19 +311,6 @@ dst__openssl_destroy() {
 	CRYPTO_mem_leaks_fp(stderr);
 #endif
 
-#if 0
-	/*
-	 * The old error sequence that leaked.  Remove for 9.4.1 if
-	 * there are no issues by then.
-	 */
-	ERR_clear_error();
-#ifdef USE_ENGINE
-	if (e != NULL) {
-		ENGINE_free(e);
-		e = NULL;
-	}
-#endif
-#endif
 	if (rm != NULL) {
 #if OPENSSL_VERSION_NUMBER >= 0x00907000L
 		RAND_cleanup();
@@ -251,6 +340,93 @@ dst__openssl_toresult(isc_result_t fallback) {
 	return (result);
 }
 
+ENGINE *
+dst__openssl_getengine(const char *name) {
+
+	UNUSED(name);
+
+
+#if defined(USE_ENGINE)
+	return (he);
+#else
+	return (NULL);
+#endif
+}
+
+isc_result_t
+dst__openssl_setdefault(const char *name) {
+
+	UNUSED(name);
+
+#if defined(USE_ENGINE)
+	ENGINE_set_default(e, ENGINE_METHOD_ALL);
+#endif
+	/*
+	 * XXXMPA If the engine does not have a default RAND method
+	 * restore our method.
+	 */
+	return (ISC_R_SUCCESS);
+}
+
+#ifdef USE_PKCS11
+/*
+ * 'name' is the name the engine is known by to the dst library.
+ * This may or may not match the name the engine is known by to
+ * openssl.  It is the name that is stored in the private key file.
+ *
+ * 'engine_id' is the openssl engine name.
+ *
+ * pre_cmds and post_cmds a sequence if command argument pairs
+ * pre_num and post_num are a count of those pairs.
+ *
+ * "SO_PATH", PKCS11_SO_PATH ("/usr/local/lib/engines/engine_pkcs11.so")
+ * "LOAD", NULL
+ * "MODULE_PATH", PKCS11_MODULE_PATH ("/usr/lib/libpkcs11.so")
+ */
+static isc_result_t
+dst__openssl_load_engine(const char *name, const char *engine_id,
+			 const char **pre_cmds, int pre_num,
+			 const char **post_cmds, int post_num)
+{
+	ENGINE *e;
+
+	UNUSED(name);
+
+	if (!strcasecmp(engine_id, "dynamic"))
+		ENGINE_load_dynamic();
+	e = ENGINE_by_id(engine_id);
+	if (e == NULL)
+		return (ISC_R_NOTFOUND);
+	while (pre_num--) {
+		if (!ENGINE_ctrl_cmd_string(e, pre_cmds[0], pre_cmds[1], 0)) {
+			ENGINE_free(e);
+			return (ISC_R_FAILURE);
+		}
+		pre_cmds += 2;
+	}
+	if (!ENGINE_init(e)) {
+		ENGINE_free(e);
+		return (ISC_R_FAILURE);
+	}
+	/*
+	 * ENGINE_init() returned a functional reference, so free the
+	 * structural reference from ENGINE_by_id().
+	 */
+	ENGINE_free(e);
+	while (post_num--) {
+		if (!ENGINE_ctrl_cmd_string(e, post_cmds[0], post_cmds[1], 0)) {
+			ENGINE_free(e);
+			return (ISC_R_FAILURE);
+		}
+		post_cmds += 2;
+	}
+	if (he != NULL)
+		ENGINE_finish(he);
+	he = e;
+	return (ISC_R_SUCCESS);
+}
+#endif /* USE_PKCS11 */
+
 #else /* OPENSSL */
 
 #include <isc/util.h>
diff --git a/contrib/bind9/lib/dns/openssldh_link.c b/contrib/bind9/lib/dns/openssldh_link.c
index 8f47482..abc3b7c 100644
--- a/contrib/bind9/lib/dns/openssldh_link.c
+++ b/contrib/bind9/lib/dns/openssldh_link.c
@@ -1,6 +1,19 @@
 /*
- * Portions Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 1999-2002  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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.
+ *
  * Portions Copyright (C) 1995-2000 by Network Associates, Inc.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -18,7 +31,7 @@
 
 /*
  * Principal Author: Brian Wellington
- * $Id: openssldh_link.c,v 1.1.6.10 2007/08/28 07:20:04 tbox Exp $
+ * $Id: openssldh_link.c,v 1.14 2008/04/01 23:47:10 tbox Exp $
  */
 
 #ifdef OPENSSL
@@ -37,8 +50,6 @@
 #include "dst_openssl.h"
 #include "dst_parse.h"
 
-#include <openssl/dh.h>
-
 #define PRIME768 "FFFFFFFFFFFFFFFFC90FDAA22168C234C4C6628B80DC1CD129024E088" \
 	"A67CC74020BBEA63B139B22514A08798E3404DDEF9519B3CD3A431B302B0A6DF25" \
 	"F14374FE1356D6D51C245E485B576625E7EC6F44C42E9A63A3620FFFFFFFFFFFFFFFF"
@@ -71,11 +82,11 @@ openssldh_computesecret(const dst_key_t *pub, const dst_key_t *priv,
 	isc_region_t r;
 	unsigned int len;
 
-	REQUIRE(pub->opaque != NULL);
-	REQUIRE(priv->opaque != NULL);
+	REQUIRE(pub->keydata.dh != NULL);
+	REQUIRE(priv->keydata.dh != NULL);
 
-	dhpub = (DH *) pub->opaque;
-	dhpriv = (DH *) priv->opaque;
+	dhpub = pub->keydata.dh;
+	dhpriv = priv->keydata.dh;
 
 	len = DH_size(dhpriv);
 	isc_buffer_availableregion(secret, &r);
@@ -93,8 +104,8 @@ openssldh_compare(const dst_key_t *key1, const dst_key_t *key2) {
 	int status;
 	DH *dh1, *dh2;
 
-	dh1 = (DH *) key1->opaque;
-	dh2 = (DH *) key2->opaque;
+	dh1 = key1->keydata.dh;
+	dh2 = key2->keydata.dh;
 
 	if (dh1 == NULL && dh2 == NULL)
 		return (ISC_TRUE);
@@ -122,8 +133,8 @@ openssldh_paramcompare(const dst_key_t *key1, const dst_key_t *key2) {
 	int status;
 	DH *dh1, *dh2;
 
-	dh1 = (DH *) key1->opaque;
-	dh2 = (DH *) key2->opaque;
+	dh1 = key1->keydata.dh;
+	dh2 = key2->keydata.dh;
 
 	if (dh1 == NULL && dh2 == NULL)
 		return (ISC_TRUE);
@@ -141,7 +152,7 @@ openssldh_paramcompare(const dst_key_t *key1, const dst_key_t *key2) {
 static isc_result_t
 openssldh_generate(dst_key_t *key, int generator) {
 #if OPENSSL_VERSION_NUMBER > 0x00908000L
-        BN_GENCB cb;
+	BN_GENCB cb;
 #endif
 	DH *dh = NULL;
 
@@ -192,20 +203,20 @@ openssldh_generate(dst_key_t *key, int generator) {
 	}
 	dh->flags &= ~DH_FLAG_CACHE_MONT_P;
 
-	key->opaque = dh;
+	key->keydata.dh = dh;
 
 	return (ISC_R_SUCCESS);
 }
 
 static isc_boolean_t
 openssldh_isprivate(const dst_key_t *key) {
-	DH *dh = (DH *) key->opaque;
+	DH *dh = key->keydata.dh;
 	return (ISC_TF(dh != NULL && dh->priv_key != NULL));
 }
 
 static void
 openssldh_destroy(dst_key_t *key) {
-	DH *dh = key->opaque;
+	DH *dh = key->keydata.dh;
 
 	if (dh == NULL)
 		return;
@@ -215,7 +226,7 @@ openssldh_destroy(dst_key_t *key) {
 	if (dh->g == &bn2)
 		dh->g = NULL;
 	DH_free(dh);
-	key->opaque = NULL;
+	key->keydata.dh = NULL;
 }
 
 static void
@@ -242,9 +253,9 @@ openssldh_todns(const dst_key_t *key, isc_buffer_t *data) {
 	isc_region_t r;
 	isc_uint16_t dnslen, plen, glen, publen;
 
-	REQUIRE(key->opaque != NULL);
+	REQUIRE(key->keydata.dh != NULL);
 
-	dh = (DH *) key->opaque;
+	dh = key->keydata.dh;
 
 	isc_buffer_availableregion(data, &r);
 
@@ -401,7 +412,7 @@ openssldh_fromdns(dst_key_t *key, isc_buffer_t *data) {
 
 	isc_buffer_forward(data, plen + glen + publen + 6);
 
-	key->opaque = (void *) dh;
+	key->keydata.dh = dh;
 
 	return (ISC_R_SUCCESS);
 }
@@ -414,10 +425,10 @@ openssldh_tofile(const dst_key_t *key, const char *directory) {
 	unsigned char *bufs[4];
 	isc_result_t result;
 
-	if (key->opaque == NULL)
+	if (key->keydata.dh == NULL)
 		return (DST_R_NULLKEY);
 
-	dh = (DH *) key->opaque;
+	dh = key->keydata.dh;
 
 	for (i = 0; i < 4; i++) {
 		bufs[i] = isc_mem_get(key->mctx, BN_num_bytes(dh->p));
@@ -484,7 +495,7 @@ openssldh_parse(dst_key_t *key, isc_lex_t *lexer) {
 	if (dh == NULL)
 		DST_RET(ISC_R_NOMEMORY);
 	dh->flags &= ~DH_FLAG_CACHE_MONT_P;
-	key->opaque = dh;
+	key->keydata.dh = dh;
 
 	for (i = 0; i < priv.nelements; i++) {
 		BIGNUM *bn;
@@ -597,6 +608,7 @@ static dst_func_t openssldh_functions = {
 	openssldh_tofile,
 	openssldh_parse,
 	openssldh_cleanup,
+	NULL, /*%< fromlabel */
 };
 
 isc_result_t
diff --git a/contrib/bind9/lib/dns/openssldsa_link.c b/contrib/bind9/lib/dns/openssldsa_link.c
index 2ff33f32..14e89e1 100644
--- a/contrib/bind9/lib/dns/openssldsa_link.c
+++ b/contrib/bind9/lib/dns/openssldsa_link.c
@@ -1,6 +1,19 @@
 /*
- * Portions Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 1999-2002  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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.
+ *
  * Portions Copyright (C) 1995-2000 by Network Associates, Inc.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -16,9 +29,12 @@
  * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: openssldsa_link.c,v 1.1.6.9.28.1 2008/12/24 00:21:22 marka Exp $ */
+/* $Id: openssldsa_link.c,v 1.13.120.2 2009/01/14 23:47:26 tbox Exp $ */
 
 #ifdef OPENSSL
+#ifndef USE_EVP
+#define USE_EVP 1
+#endif
 
 #include <config.h>
 
@@ -41,32 +57,68 @@ static isc_result_t openssldsa_todns(const dst_key_t *key, isc_buffer_t *data);
 
 static isc_result_t
 openssldsa_createctx(dst_key_t *key, dst_context_t *dctx) {
+#if USE_EVP
+	EVP_MD_CTX *evp_md_ctx;
+
+	UNUSED(key);
+
+	evp_md_ctx = EVP_MD_CTX_create();
+	if (evp_md_ctx == NULL)
+		return (ISC_R_NOMEMORY);
+
+	if (!EVP_DigestInit_ex(evp_md_ctx, EVP_dss1(), NULL)) {
+		EVP_MD_CTX_destroy(evp_md_ctx);
+			return (ISC_R_FAILURE);
+	}
+
+	dctx->ctxdata.evp_md_ctx = evp_md_ctx;
+
+	return (ISC_R_SUCCESS);
+#else
 	isc_sha1_t *sha1ctx;
 
 	UNUSED(key);
 
 	sha1ctx = isc_mem_get(dctx->mctx, sizeof(isc_sha1_t));
 	isc_sha1_init(sha1ctx);
-	dctx->opaque = sha1ctx;
+	dctx->ctxdata.sha1ctx = sha1ctx;
 	return (ISC_R_SUCCESS);
+#endif
 }
 
 static void
 openssldsa_destroyctx(dst_context_t *dctx) {
-	isc_sha1_t *sha1ctx = dctx->opaque;
+#if USE_EVP
+	EVP_MD_CTX *evp_md_ctx = dctx->ctxdata.evp_md_ctx;
+
+	if (evp_md_ctx != NULL) {
+		EVP_MD_CTX_destroy(evp_md_ctx);
+		dctx->ctxdata.evp_md_ctx = NULL;
+	}
+#else
+	isc_sha1_t *sha1ctx = dctx->ctxdata.sha1ctx;
 
 	if (sha1ctx != NULL) {
 		isc_sha1_invalidate(sha1ctx);
 		isc_mem_put(dctx->mctx, sha1ctx, sizeof(isc_sha1_t));
-		dctx->opaque = NULL;
+		dctx->ctxdata.sha1ctx = NULL;
 	}
+#endif
 }
 
 static isc_result_t
 openssldsa_adddata(dst_context_t *dctx, const isc_region_t *data) {
-	isc_sha1_t *sha1ctx = dctx->opaque;
+#if USE_EVP
+	EVP_MD_CTX *evp_md_ctx = dctx->ctxdata.evp_md_ctx;
+
+	if (!EVP_DigestUpdate(evp_md_ctx, data->base, data->length)) {
+		return (ISC_R_FAILURE);
+	}
+#else
+	isc_sha1_t *sha1ctx = dctx->ctxdata.sha1ctx;
 
 	isc_sha1_update(sha1ctx, data->base, data->length);
+#endif
 	return (ISC_R_SUCCESS);
 }
 
@@ -81,23 +133,72 @@ BN_bn2bin_fixed(BIGNUM *bn, unsigned char *buf, int size) {
 
 static isc_result_t
 openssldsa_sign(dst_context_t *dctx, isc_buffer_t *sig) {
-	isc_sha1_t *sha1ctx = dctx->opaque;
 	dst_key_t *key = dctx->key;
-	DSA *dsa = key->opaque;
-	DSA_SIG *dsasig;
+	DSA *dsa = key->keydata.dsa;
 	isc_region_t r;
+	DSA_SIG *dsasig;
+#if USE_EVP
+	EVP_MD_CTX *evp_md_ctx = dctx->ctxdata.evp_md_ctx;
+	EVP_PKEY *pkey;
+	unsigned char *sigbuf;
+	const unsigned char *sb;
+	unsigned int siglen;
+#else
+	isc_sha1_t *sha1ctx = dctx->ctxdata.sha1ctx;
 	unsigned char digest[ISC_SHA1_DIGESTLENGTH];
+#endif
 
 	isc_buffer_availableregion(sig, &r);
 	if (r.length < ISC_SHA1_DIGESTLENGTH * 2 + 1)
 		return (ISC_R_NOSPACE);
 
+#if USE_EVP
+	pkey = EVP_PKEY_new();
+	if (pkey == NULL)
+		return (ISC_R_NOMEMORY);
+	if (!EVP_PKEY_set1_DSA(pkey, dsa)) {
+		EVP_PKEY_free(pkey);
+		return (ISC_R_FAILURE);
+	}
+	sigbuf = malloc(EVP_PKEY_size(pkey));
+	if (sigbuf == NULL) {
+		EVP_PKEY_free(pkey);
+		return (ISC_R_NOMEMORY);
+	}
+	if (!EVP_SignFinal(evp_md_ctx, sigbuf, &siglen, pkey)) {
+		EVP_PKEY_free(pkey);
+		free(sigbuf);
+		return (ISC_R_FAILURE);
+	}
+	INSIST(EVP_PKEY_size(pkey) >= (int) siglen);
+	EVP_PKEY_free(pkey);
+	/* Convert from Dss-Sig-Value (RFC2459). */
+	dsasig = DSA_SIG_new();
+	if (dsasig == NULL) {
+		free(sigbuf);
+		return (ISC_R_NOMEMORY);
+	}
+	sb = sigbuf;
+	if (d2i_DSA_SIG(&dsasig, &sb, (long) siglen) == NULL) {
+		free(sigbuf);
+		return (ISC_R_FAILURE);
+	}
+	free(sigbuf);
+#elif 0
+	/* Only use EVP for the Digest */
+	if (!EVP_DigestFinal_ex(evp_md_ctx, digest, &siglen)) {
+		return (ISC_R_FAILURE);
+	}
+	dsasig = DSA_do_sign(digest, ISC_SHA1_DIGESTLENGTH, dsa);
+	if (dsasig == NULL)
+		return (dst__openssl_toresult(DST_R_SIGNFAILURE));
+#else
 	isc_sha1_final(sha1ctx, digest);
 
 	dsasig = DSA_do_sign(digest, ISC_SHA1_DIGESTLENGTH, dsa);
 	if (dsasig == NULL)
 		return (dst__openssl_toresult(DST_R_SIGNFAILURE));
-
+#endif
 	*r.base++ = (key->key_size - 512)/64;
 	BN_bn2bin_fixed(dsasig->r, r.base, ISC_SHA1_DIGESTLENGTH);
 	r.base += ISC_SHA1_DIGESTLENGTH;
@@ -111,27 +212,70 @@ openssldsa_sign(dst_context_t *dctx, isc_buffer_t *sig) {
 
 static isc_result_t
 openssldsa_verify(dst_context_t *dctx, const isc_region_t *sig) {
-	isc_sha1_t *sha1ctx = dctx->opaque;
 	dst_key_t *key = dctx->key;
-	DSA *dsa = key->opaque;
-	DSA_SIG *dsasig;
+	DSA *dsa = key->keydata.dsa;
 	int status = 0;
-	unsigned char digest[ISC_SHA1_DIGESTLENGTH];
 	unsigned char *cp = sig->base;
+	DSA_SIG *dsasig;
+#if USE_EVP
+	EVP_MD_CTX *evp_md_ctx = dctx->ctxdata.evp_md_ctx;
+#if 0
+	EVP_PKEY *pkey;
+	unsigned char *sigbuf;
+#endif
+	unsigned int siglen;
+#else
+	isc_sha1_t *sha1ctx = dctx->ctxdata.sha1ctx;
+#endif
+	unsigned char digest[ISC_SHA1_DIGESTLENGTH];
 
+
+#if USE_EVP
+#if 1
+	/* Only use EVP for the digest */
+	if (!EVP_DigestFinal_ex(evp_md_ctx, digest, &siglen)) {
+		return (ISC_R_FAILURE);
+	}
+#endif
+#else
 	isc_sha1_final(sha1ctx, digest);
+#endif
 
-	if (sig->length < 2 * ISC_SHA1_DIGESTLENGTH + 1)
+	if (sig->length != 2 * ISC_SHA1_DIGESTLENGTH + 1) {
 		return (DST_R_VERIFYFAILURE);
+	}
 
 	cp++;	/*%< Skip T */
 	dsasig = DSA_SIG_new();
+	if (dsasig == NULL)
+		return (ISC_R_NOMEMORY);
 	dsasig->r = BN_bin2bn(cp, ISC_SHA1_DIGESTLENGTH, NULL);
 	cp += ISC_SHA1_DIGESTLENGTH;
 	dsasig->s = BN_bin2bn(cp, ISC_SHA1_DIGESTLENGTH, NULL);
 	cp += ISC_SHA1_DIGESTLENGTH;
 
+#if 0
+	pkey = EVP_PKEY_new();
+	if (pkey == NULL)
+		return (ISC_R_NOMEMORY);
+	if (!EVP_PKEY_set1_DSA(pkey, dsa)) {
+		EVP_PKEY_free(pkey);
+		return (ISC_R_FAILURE);
+	}
+	/* Convert to Dss-Sig-Value (RFC2459). */
+	sigbuf = malloc(EVP_PKEY_size(pkey) + 50);
+	if (sigbuf == NULL) {
+		EVP_PKEY_free(pkey);
+		return (ISC_R_NOMEMORY);
+	}
+	siglen = (unsigned) i2d_DSA_SIG(dsasig, &sigbuf);
+	INSIST(EVP_PKEY_size(pkey) >= (int) siglen);
+	status = EVP_VerifyFinal(evp_md_ctx, sigbuf, siglen, pkey);
+	EVP_PKEY_free(pkey);
+	free(sigbuf);
+#else
 	status = DSA_do_verify(digest, ISC_SHA1_DIGESTLENGTH, dsasig, dsa);
+#endif
 	DSA_SIG_free(dsasig);
 	if (status != 1)
 		return (dst__openssl_toresult(DST_R_VERIFYFAILURE));
@@ -144,8 +288,8 @@ openssldsa_compare(const dst_key_t *key1, const dst_key_t *key2) {
 	int status;
 	DSA *dsa1, *dsa2;
 
-	dsa1 = (DSA *) key1->opaque;
-	dsa2 = (DSA *) key2->opaque;
+	dsa1 = key1->keydata.dsa;
+	dsa2 = key2->keydata.dsa;
 
 	if (dsa1 == NULL && dsa2 == NULL)
 		return (ISC_TRUE);
@@ -172,7 +316,7 @@ openssldsa_compare(const dst_key_t *key1, const dst_key_t *key2) {
 static isc_result_t
 openssldsa_generate(dst_key_t *key, int unused) {
 #if OPENSSL_VERSION_NUMBER > 0x00908000L
-        BN_GENCB cb;
+	BN_GENCB cb;
 #endif
 	DSA *dsa;
 	unsigned char rand_array[ISC_SHA1_DIGESTLENGTH];
@@ -186,12 +330,12 @@ openssldsa_generate(dst_key_t *key, int unused) {
 		return (result);
 
 #if OPENSSL_VERSION_NUMBER > 0x00908000L
-        dsa = DSA_new();
+	dsa = DSA_new();
 	if (dsa == NULL)
 		return (dst__openssl_toresult(DST_R_OPENSSLFAILURE));
 
 	BN_GENCB_set_old(&cb, NULL, NULL);
-  
+
 	if (!DSA_generate_parameters_ex(dsa, key->key_size, rand_array,
 					ISC_SHA1_DIGESTLENGTH,  NULL, NULL,
 					&cb))
@@ -213,22 +357,22 @@ openssldsa_generate(dst_key_t *key, int unused) {
 	}
 	dsa->flags &= ~DSA_FLAG_CACHE_MONT_P;
 
-	key->opaque = dsa;
+	key->keydata.dsa = dsa;
 
 	return (ISC_R_SUCCESS);
 }
 
 static isc_boolean_t
 openssldsa_isprivate(const dst_key_t *key) {
-	DSA *dsa = (DSA *) key->opaque;
+	DSA *dsa = key->keydata.dsa;
 	return (ISC_TF(dsa != NULL && dsa->priv_key != NULL));
 }
 
 static void
 openssldsa_destroy(dst_key_t *key) {
-	DSA *dsa = key->opaque;
+	DSA *dsa = key->keydata.dsa;
 	DSA_free(dsa);
-	key->opaque = NULL;
+	key->keydata.dsa = NULL;
 }
 
 
@@ -239,9 +383,9 @@ openssldsa_todns(const dst_key_t *key, isc_buffer_t *data) {
 	int dnslen;
 	unsigned int t, p_bytes;
 
-	REQUIRE(key->opaque != NULL);
+	REQUIRE(key->keydata.dsa != NULL);
 
-	dsa = (DSA *) key->opaque;
+	dsa = key->keydata.dsa;
 
 	isc_buffer_availableregion(data, &r);
 
@@ -315,7 +459,7 @@ openssldsa_fromdns(dst_key_t *key, isc_buffer_t *data) {
 
 	isc_buffer_forward(data, 1 + ISC_SHA1_DIGESTLENGTH + 3 * p_bytes);
 
-	key->opaque = (void *) dsa;
+	key->keydata.dsa = dsa;
 
 	return (ISC_R_SUCCESS);
 }
@@ -328,10 +472,10 @@ openssldsa_tofile(const dst_key_t *key, const char *directory) {
 	dst_private_t priv;
 	unsigned char bufs[5][128];
 
-	if (key->opaque == NULL)
+	if (key->keydata.dsa == NULL)
 		return (DST_R_NULLKEY);
 
-	dsa = (DSA *) key->opaque;
+	dsa = key->keydata.dsa;
 
 	priv.elements[cnt].tag = TAG_DSA_PRIME;
 	priv.elements[cnt].length = BN_num_bytes(dsa->p);
@@ -385,7 +529,7 @@ openssldsa_parse(dst_key_t *key, isc_lex_t *lexer) {
 	if (dsa == NULL)
 		DST_RET(ISC_R_NOMEMORY);
 	dsa->flags &= ~DSA_FLAG_CACHE_MONT_P;
-	key->opaque = dsa;
+	key->keydata.dsa = dsa;
 
 	for (i=0; i < priv.nelements; i++) {
 		BIGNUM *bn;
@@ -442,6 +586,7 @@ static dst_func_t openssldsa_functions = {
 	openssldsa_tofile,
 	openssldsa_parse,
 	NULL, /*%< cleanup */
+	NULL, /*%< fromlabel */
 };
 
 isc_result_t
diff --git a/contrib/bind9/lib/dns/opensslrsa_link.c b/contrib/bind9/lib/dns/opensslrsa_link.c
index aacba45..d557c43 100644
--- a/contrib/bind9/lib/dns/opensslrsa_link.c
+++ b/contrib/bind9/lib/dns/opensslrsa_link.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -17,9 +17,15 @@
 
 /*
  * Principal Author: Brian Wellington
- * $Id: opensslrsa_link.c,v 1.1.6.11.58.1 2008/12/24 00:21:22 marka Exp $
+ * $Id: opensslrsa_link.c,v 1.20.50.3 2009/01/18 23:25:16 marka Exp $
  */
 #ifdef OPENSSL
+#ifndef USE_EVP
+#define USE_EVP 1
+#endif
+#if USE_EVP
+#define USE_EVP_RSA 1
+#endif
 
 #include <config.h>
 
@@ -42,6 +48,7 @@
 #if OPENSSL_VERSION_NUMBER > 0x00908000L
 #include <openssl/bn.h>
 #endif
+#include <openssl/engine.h>
 
 /*
  * We don't use configure for windows so enforce the OpenSSL version
@@ -57,8 +64,8 @@
 
 
 	/*
-	 * XXXMPA  Temporarially disable RSA_BLINDING as it requires
-	 * good quality random data that cannot currently be guarenteed.
+	 * XXXMPA  Temporarily disable RSA_BLINDING as it requires
+	 * good quality random data that cannot currently be guaranteed.
 	 * XXXMPA  Find which versions of openssl use pseudo random data
 	 * and set RSA_FLAG_BLINDING for those.
 	 */
@@ -97,14 +104,38 @@
 	} while (0)
 #endif
 
+#define DST_RET(a) {ret = a; goto err;}
+
 static isc_result_t opensslrsa_todns(const dst_key_t *key, isc_buffer_t *data);
 
 static isc_result_t
 opensslrsa_createctx(dst_key_t *key, dst_context_t *dctx) {
+#if USE_EVP
+	EVP_MD_CTX *evp_md_ctx;
+	const EVP_MD *type;
+#endif
+
 	UNUSED(key);
 	REQUIRE(dctx->key->key_alg == DST_ALG_RSAMD5 ||
-		dctx->key->key_alg == DST_ALG_RSASHA1);
+		dctx->key->key_alg == DST_ALG_RSASHA1 ||
+		dctx->key->key_alg == DST_ALG_NSEC3RSASHA1);
 
+#if USE_EVP
+	evp_md_ctx = EVP_MD_CTX_create();
+	if (evp_md_ctx == NULL)
+		return (ISC_R_NOMEMORY);
+
+	if (dctx->key->key_alg == DST_ALG_RSAMD5)
+		type = EVP_md5();	/* MD5 + RSA */
+	else
+		type = EVP_sha1();	/* SHA1 + RSA */
+
+	if (!EVP_DigestInit_ex(evp_md_ctx, type, NULL)) {
+		EVP_MD_CTX_destroy(evp_md_ctx);
+		return (ISC_R_FAILURE);
+	}
+	dctx->ctxdata.evp_md_ctx = evp_md_ctx;
+#else
 	if (dctx->key->key_alg == DST_ALG_RSAMD5) {
 		isc_md5_t *md5ctx;
 
@@ -112,7 +143,7 @@ opensslrsa_createctx(dst_key_t *key, dst_context_t *dctx) {
 		if (md5ctx == NULL)
 			return (ISC_R_NOMEMORY);
 		isc_md5_init(md5ctx);
-		dctx->opaque = md5ctx;
+		dctx->ctxdata.md5ctx = md5ctx;
 	} else {
 		isc_sha1_t *sha1ctx;
 
@@ -120,58 +151,87 @@ opensslrsa_createctx(dst_key_t *key, dst_context_t *dctx) {
 		if (sha1ctx == NULL)
 			return (ISC_R_NOMEMORY);
 		isc_sha1_init(sha1ctx);
-		dctx->opaque = sha1ctx;
+		dctx->ctxdata.sha1ctx = sha1ctx;
 	}
+#endif
 
 	return (ISC_R_SUCCESS);
 }
 
 static void
 opensslrsa_destroyctx(dst_context_t *dctx) {
+#if USE_EVP
+	EVP_MD_CTX *evp_md_ctx = dctx->ctxdata.evp_md_ctx;
+#endif
+
 	REQUIRE(dctx->key->key_alg == DST_ALG_RSAMD5 ||
-		dctx->key->key_alg == DST_ALG_RSASHA1);
+		dctx->key->key_alg == DST_ALG_RSASHA1 ||
+		dctx->key->key_alg == DST_ALG_NSEC3RSASHA1);
 
+#if USE_EVP
+	if (evp_md_ctx != NULL) {
+		EVP_MD_CTX_destroy(evp_md_ctx);
+		dctx->ctxdata.evp_md_ctx = NULL;
+	}
+#else
 	if (dctx->key->key_alg == DST_ALG_RSAMD5) {
-		isc_md5_t *md5ctx = dctx->opaque;
+		isc_md5_t *md5ctx = dctx->ctxdata.md5ctx;
 
 		if (md5ctx != NULL) {
 			isc_md5_invalidate(md5ctx);
 			isc_mem_put(dctx->mctx, md5ctx, sizeof(isc_md5_t));
+			dctx->ctxdata.md5ctx = NULL;
 		}
 	} else {
-		isc_sha1_t *sha1ctx = dctx->opaque;
+		isc_sha1_t *sha1ctx = dctx->ctxdata.sha1ctx;
 
 		if (sha1ctx != NULL) {
 			isc_sha1_invalidate(sha1ctx);
 			isc_mem_put(dctx->mctx, sha1ctx, sizeof(isc_sha1_t));
+			dctx->ctxdata.sha1ctx = NULL;
 		}
 	}
-	dctx->opaque = NULL;
+#endif
 }
 
 static isc_result_t
 opensslrsa_adddata(dst_context_t *dctx, const isc_region_t *data) {
+#if USE_EVP
+	EVP_MD_CTX *evp_md_ctx = dctx->ctxdata.evp_md_ctx;
+#endif
+
 	REQUIRE(dctx->key->key_alg == DST_ALG_RSAMD5 ||
-		dctx->key->key_alg == DST_ALG_RSASHA1);
+		dctx->key->key_alg == DST_ALG_RSASHA1 ||
+		dctx->key->key_alg == DST_ALG_NSEC3RSASHA1);
 
+#if USE_EVP
+	if (!EVP_DigestUpdate(evp_md_ctx, data->base, data->length)) {
+		return (ISC_R_FAILURE);
+	}
+#else
 	if (dctx->key->key_alg == DST_ALG_RSAMD5) {
-		isc_md5_t *md5ctx = dctx->opaque;
+		isc_md5_t *md5ctx = dctx->ctxdata.md5ctx;
 		isc_md5_update(md5ctx, data->base, data->length);
 	} else {
-		isc_sha1_t *sha1ctx = dctx->opaque;
+		isc_sha1_t *sha1ctx = dctx->ctxdata.sha1ctx;
 		isc_sha1_update(sha1ctx, data->base, data->length);
 	}
+#endif
 	return (ISC_R_SUCCESS);
 }
 
 static isc_result_t
 opensslrsa_sign(dst_context_t *dctx, isc_buffer_t *sig) {
 	dst_key_t *key = dctx->key;
-	RSA *rsa = key->opaque;
 	isc_region_t r;
+	unsigned int siglen = 0;
+#if USE_EVP
+	EVP_MD_CTX *evp_md_ctx = dctx->ctxdata.evp_md_ctx;
+	EVP_PKEY *pkey = key->keydata.pkey;
+#else
+	RSA *rsa = key->keydata.rsa;
 	/* note: ISC_SHA1_DIGESTLENGTH > ISC_MD5_DIGESTLENGTH */
 	unsigned char digest[ISC_SHA1_DIGESTLENGTH];
-	unsigned int siglen = 0;
 	int status;
 	int type;
 	unsigned int digestlen;
@@ -179,22 +239,32 @@ opensslrsa_sign(dst_context_t *dctx, isc_buffer_t *sig) {
 	unsigned long err;
 	const char* file;
 	int line;
+#endif
 
 	REQUIRE(dctx->key->key_alg == DST_ALG_RSAMD5 ||
-		dctx->key->key_alg == DST_ALG_RSASHA1);
+		dctx->key->key_alg == DST_ALG_RSASHA1 ||
+		dctx->key->key_alg == DST_ALG_NSEC3RSASHA1);
 
 	isc_buffer_availableregion(sig, &r);
 
+#if USE_EVP
+	if (r.length < (unsigned int) EVP_PKEY_size(pkey))
+		return (ISC_R_NOSPACE);
+
+	if (!EVP_SignFinal(evp_md_ctx, r.base, &siglen, pkey)) {
+		return (ISC_R_FAILURE);
+	}
+#else
 	if (r.length < (unsigned int) RSA_size(rsa))
 		return (ISC_R_NOSPACE);
 
 	if (dctx->key->key_alg == DST_ALG_RSAMD5) {
-		isc_md5_t *md5ctx = dctx->opaque;
+		isc_md5_t *md5ctx = dctx->ctxdata.md5ctx;
 		isc_md5_final(md5ctx, digest);
 		type = NID_md5;
 		digestlen = ISC_MD5_DIGESTLENGTH;
 	} else {
-		isc_sha1_t *sha1ctx = dctx->opaque;
+		isc_sha1_t *sha1ctx = dctx->ctxdata.sha1ctx;
 		isc_sha1_final(sha1ctx, digest);
 		type = NID_sha1;
 		digestlen = ISC_SHA1_DIGESTLENGTH;
@@ -205,11 +275,10 @@ opensslrsa_sign(dst_context_t *dctx, isc_buffer_t *sig) {
 		err = ERR_peek_error_line(&file, &line);
 		if (err != 0U) {
 			message = ERR_error_string(err, NULL);
-			fprintf(stderr, "%s:%s:%d\n", message,
-				file ? file : "", line);
 		}
 		return (dst__openssl_toresult(DST_R_OPENSSLFAILURE));
 	}
+#endif
 
 	isc_buffer_add(sig, siglen);
 
@@ -219,23 +288,32 @@ opensslrsa_sign(dst_context_t *dctx, isc_buffer_t *sig) {
 static isc_result_t
 opensslrsa_verify(dst_context_t *dctx, const isc_region_t *sig) {
 	dst_key_t *key = dctx->key;
-	RSA *rsa = key->opaque;
+	int status = 0;
+#if USE_EVP
+	EVP_MD_CTX *evp_md_ctx = dctx->ctxdata.evp_md_ctx;
+	EVP_PKEY *pkey = key->keydata.pkey;
+#else
 	/* note: ISC_SHA1_DIGESTLENGTH > ISC_MD5_DIGESTLENGTH */
 	unsigned char digest[ISC_SHA1_DIGESTLENGTH];
-	int status = 0;
 	int type;
 	unsigned int digestlen;
+	RSA *rsa = key->keydata.rsa;
+#endif
 
 	REQUIRE(dctx->key->key_alg == DST_ALG_RSAMD5 ||
-		dctx->key->key_alg == DST_ALG_RSASHA1);
+		dctx->key->key_alg == DST_ALG_RSASHA1 ||
+		dctx->key->key_alg == DST_ALG_NSEC3RSASHA1);
 
+#if USE_EVP
+	status = EVP_VerifyFinal(evp_md_ctx, sig->base, sig->length, pkey);
+#else
 	if (dctx->key->key_alg == DST_ALG_RSAMD5) {
-		isc_md5_t *md5ctx = dctx->opaque;
+		isc_md5_t *md5ctx = dctx->ctxdata.md5ctx;
 		isc_md5_final(md5ctx, digest);
 		type = NID_md5;
 		digestlen = ISC_MD5_DIGESTLENGTH;
 	} else {
-		isc_sha1_t *sha1ctx = dctx->opaque;
+		isc_sha1_t *sha1ctx = dctx->ctxdata.sha1ctx;
 		isc_sha1_final(sha1ctx, digest);
 		type = NID_sha1;
 		digestlen = ISC_SHA1_DIGESTLENGTH;
@@ -246,6 +324,7 @@ opensslrsa_verify(dst_context_t *dctx, const isc_region_t *sig) {
 
 	status = RSA_verify(type, digest, digestlen, sig->base,
 			    RSA_size(rsa), rsa);
+#endif
 	if (status != 1)
 		return (dst__openssl_toresult(DST_R_VERIFYFAILURE));
 
@@ -255,10 +334,30 @@ opensslrsa_verify(dst_context_t *dctx, const isc_region_t *sig) {
 static isc_boolean_t
 opensslrsa_compare(const dst_key_t *key1, const dst_key_t *key2) {
 	int status;
-	RSA *rsa1, *rsa2;
+	RSA *rsa1 = NULL, *rsa2 = NULL;
+#if USE_EVP
+	EVP_PKEY *pkey1, *pkey2;
+#endif
 
-	rsa1 = (RSA *) key1->opaque;
-	rsa2 = (RSA *) key2->opaque;
+#if USE_EVP
+	pkey1 = key1->keydata.pkey;
+	pkey2 = key2->keydata.pkey;
+	/*
+	 * The pkey reference will keep these around after
+	 * the RSA_free() call.
+	 */
+	if (pkey1 != NULL) {
+		rsa1 = EVP_PKEY_get1_RSA(pkey1);
+		RSA_free(rsa1);
+	}
+	if (pkey2 != NULL) {
+		rsa2 = EVP_PKEY_get1_RSA(pkey2);
+		RSA_free(rsa2);
+	}
+#else
+	rsa1 = key1->keydata.rsa;
+	rsa2 = key2->keydata.rsa;
+#endif
 
 	if (rsa1 == NULL && rsa2 == NULL)
 		return (ISC_TRUE);
@@ -271,6 +370,19 @@ opensslrsa_compare(const dst_key_t *key1, const dst_key_t *key2) {
 	if (status != 0)
 		return (ISC_FALSE);
 
+#if USE_EVP
+	if ((rsa1->flags & RSA_FLAG_EXT_PKEY) != 0 ||
+	    (rsa2->flags & RSA_FLAG_EXT_PKEY) != 0) {
+		if ((rsa1->flags & RSA_FLAG_EXT_PKEY) == 0 ||
+		    (rsa2->flags & RSA_FLAG_EXT_PKEY) == 0)
+			return (ISC_FALSE);
+		/*
+		 * Can't compare private parameters, BTW does it make sense?
+		 */
+		return (ISC_TRUE);
+	}
+#endif
+
 	if (rsa1->d != NULL || rsa2->d != NULL) {
 		if (rsa1->d == NULL || rsa2->d == NULL)
 			return (ISC_FALSE);
@@ -290,9 +402,18 @@ opensslrsa_generate(dst_key_t *key, int exp) {
 	BN_GENCB cb;
 	RSA *rsa = RSA_new();
 	BIGNUM *e = BN_new();
+#if USE_EVP
+	EVP_PKEY *pkey = EVP_PKEY_new();
+#endif
 
 	if (rsa == NULL || e == NULL)
 		goto err;
+#if USE_EVP
+	if (pkey == NULL)
+		goto err;
+	if (!EVP_PKEY_set1_RSA(pkey, rsa))
+		goto err;
+#endif
 
 	if (exp == 0) {
 		/* RSA_F4 0x10001 */
@@ -309,11 +430,21 @@ opensslrsa_generate(dst_key_t *key, int exp) {
 	if (RSA_generate_key_ex(rsa, key->key_size, e, &cb)) {
 		BN_free(e);
 		SET_FLAGS(rsa);
-		key->opaque = rsa;
+#if USE_EVP
+		key->keydata.pkey = pkey;
+
+		RSA_free(rsa);
+#else
+		key->keydata.rsa = rsa;
+#endif
 		return (ISC_R_SUCCESS);
 	}
 
 err:
+#if USE_EVP
+	if (pkey != NULL)
+		EVP_PKEY_free(pkey);
+#endif
 	if (e != NULL)
 		BN_free(e);
 	if (rsa != NULL)
@@ -322,16 +453,36 @@ err:
 #else
 	RSA *rsa;
 	unsigned long e;
+#if USE_EVP
+	EVP_PKEY *pkey = EVP_PKEY_new();
+
+	if (pkey == NULL)
+		return (ISC_R_NOMEMORY);
+#endif
 
 	if (exp == 0)
 	       e = RSA_F4;
 	else
 	       e = 0x40000003;
 	rsa = RSA_generate_key(key->key_size, e, NULL, NULL);
-	if (rsa == NULL)
-	       return (dst__openssl_toresult(DST_R_OPENSSLFAILURE));
+	if (rsa == NULL) {
+#if USE_EVP
+		EVP_PKEY_free(pkey);
+#endif
+		return (dst__openssl_toresult(DST_R_OPENSSLFAILURE));
+	}
 	SET_FLAGS(rsa);
-	key->opaque = rsa;
+#if USE_EVP
+	if (!EVP_PKEY_set1_RSA(pkey, rsa)) {
+		EVP_PKEY_free(pkey);
+		RSA_free(rsa);
+		return (dst__openssl_toresult(DST_R_OPENSSLFAILURE));
+	}
+	key->keydata.pkey = pkey;
+	RSA_free(rsa);
+#else
+	key->keydata.rsa = rsa;
+#endif
 
 	return (ISC_R_SUCCESS);
 #endif
@@ -339,28 +490,58 @@ err:
 
 static isc_boolean_t
 opensslrsa_isprivate(const dst_key_t *key) {
-	RSA *rsa = (RSA *) key->opaque;
+#if USE_EVP
+	RSA *rsa = EVP_PKEY_get1_RSA(key->keydata.pkey);
+	INSIST(rsa != NULL);
+	RSA_free(rsa);
+	/* key->keydata.pkey still has a reference so rsa is still valid. */
+#else
+	RSA *rsa = key->keydata.rsa;
+#endif
+	if (rsa != NULL && (rsa->flags & RSA_FLAG_EXT_PKEY) != 0)
+		return (ISC_TRUE);
 	return (ISC_TF(rsa != NULL && rsa->d != NULL));
 }
 
 static void
 opensslrsa_destroy(dst_key_t *key) {
-	RSA *rsa = key->opaque;
+#if USE_EVP
+	EVP_PKEY *pkey = key->keydata.pkey;
+	EVP_PKEY_free(pkey);
+	key->keydata.pkey = NULL;
+#else
+	RSA *rsa = key->keydata.rsa;
 	RSA_free(rsa);
-	key->opaque = NULL;
+	key->keydata.rsa = NULL;
+#endif
 }
 
 
 static isc_result_t
 opensslrsa_todns(const dst_key_t *key, isc_buffer_t *data) {
-	RSA *rsa;
 	isc_region_t r;
 	unsigned int e_bytes;
 	unsigned int mod_bytes;
+	isc_result_t ret;
+	RSA *rsa;
+#if USE_EVP
+	EVP_PKEY *pkey;
+#endif
 
-	REQUIRE(key->opaque != NULL);
+#if USE_EVP
+	REQUIRE(key->keydata.pkey != NULL);
+#else
+	REQUIRE(key->keydata.rsa != NULL);
+#endif
 
-	rsa = (RSA *) key->opaque;
+#if USE_EVP
+	pkey = key->keydata.pkey;
+	rsa = EVP_PKEY_get1_RSA(pkey);
+	if (rsa == NULL)
+		return (dst__openssl_toresult(DST_R_OPENSSLFAILURE));
+#else
+	rsa = key->keydata.rsa;
+#endif
 
 	isc_buffer_availableregion(data, &r);
 
@@ -369,11 +550,11 @@ opensslrsa_todns(const dst_key_t *key, isc_buffer_t *data) {
 
 	if (e_bytes < 256) {	/*%< key exponent is <= 2040 bits */
 		if (r.length < 1)
-			return (ISC_R_NOSPACE);
+			DST_RET(ISC_R_NOSPACE);
 		isc_buffer_putuint8(data, (isc_uint8_t) e_bytes);
 	} else {
 		if (r.length < 3)
-			return (ISC_R_NOSPACE);
+			DST_RET(ISC_R_NOSPACE);
 		isc_buffer_putuint8(data, 0);
 		isc_buffer_putuint16(data, (isc_uint16_t) e_bytes);
 	}
@@ -388,7 +569,13 @@ opensslrsa_todns(const dst_key_t *key, isc_buffer_t *data) {
 
 	isc_buffer_add(data, e_bytes + mod_bytes);
 
-	return (ISC_R_SUCCESS);
+	ret = ISC_R_SUCCESS;
+ err:
+#if USE_EVP
+	if (rsa != NULL)
+		RSA_free(rsa);
+#endif
+	return (ret);
 }
 
 static isc_result_t
@@ -396,6 +583,9 @@ opensslrsa_fromdns(dst_key_t *key, isc_buffer_t *data) {
 	RSA *rsa;
 	isc_region_t r;
 	unsigned int e_bytes;
+#if USE_EVP
+	EVP_PKEY *pkey;
+#endif
 
 	isc_buffer_remainingregion(data, &r);
 	if (r.length == 0)
@@ -437,12 +627,26 @@ opensslrsa_fromdns(dst_key_t *key, isc_buffer_t *data) {
 
 	isc_buffer_forward(data, r.length);
 
-	key->opaque = (void *) rsa;
+#if USE_EVP
+	pkey = EVP_PKEY_new();
+	if (pkey == NULL) {
+		RSA_free(rsa);
+		return (ISC_R_NOMEMORY);
+	}
+	if (!EVP_PKEY_set1_RSA(pkey, rsa)) {
+		EVP_PKEY_free(pkey);
+		RSA_free(rsa);
+		return (dst__openssl_toresult(DST_R_OPENSSLFAILURE));
+	}
+	key->keydata.pkey = pkey;
+	RSA_free(rsa);
+#else
+	key->keydata.rsa = rsa;
+#endif
 
 	return (ISC_R_SUCCESS);
 }
 
-
 static isc_result_t
 opensslrsa_tofile(const dst_key_t *key, const char *directory) {
 	int i;
@@ -451,10 +655,17 @@ opensslrsa_tofile(const dst_key_t *key, const char *directory) {
 	unsigned char *bufs[8];
 	isc_result_t result;
 
-	if (key->opaque == NULL)
+#if USE_EVP
+	if (key->keydata.pkey == NULL)
 		return (DST_R_NULLKEY);
-
-	rsa = (RSA *) key->opaque;
+	rsa = EVP_PKEY_get1_RSA(key->keydata.pkey);
+	if (rsa == NULL)
+		return (dst__openssl_toresult(DST_R_OPENSSLFAILURE));
+#else
+	if (key->keydata.rsa == NULL)
+		return (DST_R_NULLKEY);
+	rsa = key->keydata.rsa;
+#endif
 
 	for (i = 0; i < 8; i++) {
 		bufs[i] = isc_mem_get(key->mctx, BN_num_bytes(rsa->n));
@@ -478,45 +689,74 @@ opensslrsa_tofile(const dst_key_t *key, const char *directory) {
 	priv.elements[i].data = bufs[i];
 	i++;
 
-	priv.elements[i].tag = TAG_RSA_PRIVATEEXPONENT;
-	priv.elements[i].length = BN_num_bytes(rsa->d);
-	BN_bn2bin(rsa->d, bufs[i]);
-	priv.elements[i].data = bufs[i];
-	i++;
+	if (rsa->d != NULL) {
+		priv.elements[i].tag = TAG_RSA_PRIVATEEXPONENT;
+		priv.elements[i].length = BN_num_bytes(rsa->d);
+		BN_bn2bin(rsa->d, bufs[i]);
+		priv.elements[i].data = bufs[i];
+		i++;
+	}
 
-	priv.elements[i].tag = TAG_RSA_PRIME1;
-	priv.elements[i].length = BN_num_bytes(rsa->p);
-	BN_bn2bin(rsa->p, bufs[i]);
-	priv.elements[i].data = bufs[i];
-	i++;
+	if (rsa->p != NULL) {
+		priv.elements[i].tag = TAG_RSA_PRIME1;
+		priv.elements[i].length = BN_num_bytes(rsa->p);
+		BN_bn2bin(rsa->p, bufs[i]);
+		priv.elements[i].data = bufs[i];
+		i++;
+	}
 
-	priv.elements[i].tag = TAG_RSA_PRIME2;
-	priv.elements[i].length = BN_num_bytes(rsa->q);
-	BN_bn2bin(rsa->q, bufs[i]);
-	priv.elements[i].data = bufs[i];
-	i++;
+	if (rsa->q != NULL) {
+		priv.elements[i].tag = TAG_RSA_PRIME2;
+		priv.elements[i].length = BN_num_bytes(rsa->q);
+		BN_bn2bin(rsa->q, bufs[i]);
+		priv.elements[i].data = bufs[i];
+		i++;
+	}
 
-	priv.elements[i].tag = TAG_RSA_EXPONENT1;
-	priv.elements[i].length = BN_num_bytes(rsa->dmp1);
-	BN_bn2bin(rsa->dmp1, bufs[i]);
-	priv.elements[i].data = bufs[i];
-	i++;
+	if (rsa->dmp1 != NULL) {
+		priv.elements[i].tag = TAG_RSA_EXPONENT1;
+		priv.elements[i].length = BN_num_bytes(rsa->dmp1);
+		BN_bn2bin(rsa->dmp1, bufs[i]);
+		priv.elements[i].data = bufs[i];
+		i++;
+	}
 
-	priv.elements[i].tag = TAG_RSA_EXPONENT2;
-	priv.elements[i].length = BN_num_bytes(rsa->dmq1);
-	BN_bn2bin(rsa->dmq1, bufs[i]);
-	priv.elements[i].data = bufs[i];
-	i++;
+	if (rsa->dmq1 != NULL) {
+		priv.elements[i].tag = TAG_RSA_EXPONENT2;
+		priv.elements[i].length = BN_num_bytes(rsa->dmq1);
+		BN_bn2bin(rsa->dmq1, bufs[i]);
+		priv.elements[i].data = bufs[i];
+		i++;
+	}
 
-	priv.elements[i].tag = TAG_RSA_COEFFICIENT;
-	priv.elements[i].length = BN_num_bytes(rsa->iqmp);
-	BN_bn2bin(rsa->iqmp, bufs[i]);
-	priv.elements[i].data = bufs[i];
-	i++;
+	if (rsa->iqmp != NULL) {
+		priv.elements[i].tag = TAG_RSA_COEFFICIENT;
+		priv.elements[i].length = BN_num_bytes(rsa->iqmp);
+		BN_bn2bin(rsa->iqmp, bufs[i]);
+		priv.elements[i].data = bufs[i];
+		i++;
+	}
+
+	if (key->engine != NULL) {
+		priv.elements[i].tag = TAG_RSA_ENGINE;
+		priv.elements[i].length = strlen(key->engine) + 1;
+		priv.elements[i].data = (unsigned char *)key->engine;
+		i++;
+	}
+
+	if (key->label != NULL) {
+		priv.elements[i].tag = TAG_RSA_LABEL;
+		priv.elements[i].length = strlen(key->label) + 1;
+		priv.elements[i].data = (unsigned char *)key->label;
+		i++;
+	}
 
 	priv.nelements = i;
 	result =  dst__privstruct_writefile(key, &priv, directory);
  fail:
+#if USE_EVP
+	RSA_free(rsa);
+#endif
 	for (i = 0; i < 8; i++) {
 		if (bufs[i] == NULL)
 			break;
@@ -531,26 +771,94 @@ opensslrsa_parse(dst_key_t *key, isc_lex_t *lexer) {
 	isc_result_t ret;
 	int i;
 	RSA *rsa = NULL;
+	ENGINE *e = NULL;
 	isc_mem_t *mctx = key->mctx;
-#define DST_RET(a) {ret = a; goto err;}
+	const char *name = NULL, *label = NULL;
+	EVP_PKEY *pkey = NULL;
 
 	/* read private key file */
 	ret = dst__privstruct_parse(key, DST_ALG_RSA, lexer, mctx, &priv);
 	if (ret != ISC_R_SUCCESS)
 		return (ret);
 
+	for (i = 0; i < priv.nelements; i++) {
+		switch (priv.elements[i].tag) {
+		case TAG_RSA_ENGINE:
+			name = (char *)priv.elements[i].data;
+			break;
+		case TAG_RSA_LABEL:
+			label = (char *)priv.elements[i].data;
+			break;
+		default:
+			break;
+		}
+	}
+	/*
+	 * Is this key is stored in a HSM?
+	 * See if we can fetch it.
+	 */
+	if (name != NULL || label != NULL) {
+		INSIST(name != NULL);
+		INSIST(label != NULL);
+		e = dst__openssl_getengine(name);
+		if (e == NULL)
+			DST_RET(DST_R_NOENGINE);
+		pkey = ENGINE_load_private_key(e, label, NULL, NULL);
+		if (pkey == NULL) {
+			ERR_print_errors_fp(stderr);
+			DST_RET(ISC_R_FAILURE);
+		}
+		key->engine = isc_mem_strdup(key->mctx, name);
+		if (key->engine == NULL)
+			DST_RET(ISC_R_NOMEMORY);
+		key->label = isc_mem_strdup(key->mctx, label);
+		if (key->label == NULL)
+			DST_RET(ISC_R_NOMEMORY);
+		key->key_size = EVP_PKEY_bits(pkey);
+#if USE_EVP
+		key->keydata.pkey = pkey;
+#else
+		key->keydata.rsa = EVP_PKEY_get1_RSA(pkey);
+		if (rsa == NULL)
+			DST_RET(dst__openssl_toresult(DST_R_OPENSSLFAILURE));
+		EVP_PKEY_free(pkey);
+#endif
+		dst__privstruct_free(&priv, mctx);
+		return (ISC_R_SUCCESS);
+	}
+
 	rsa = RSA_new();
 	if (rsa == NULL)
 		DST_RET(ISC_R_NOMEMORY);
 	SET_FLAGS(rsa);
-	key->opaque = rsa;
+
+#if USE_EVP
+	pkey = EVP_PKEY_new();
+	if (pkey == NULL)
+		DST_RET(ISC_R_NOMEMORY);
+	if (!EVP_PKEY_set1_RSA(pkey, rsa)) {
+		DST_RET(ISC_R_FAILURE);
+	}
+	key->keydata.pkey = pkey;
+#else
+	key->keydata.rsa = rsa;
+#endif
 
 	for (i = 0; i < priv.nelements; i++) {
 		BIGNUM *bn;
-		bn = BN_bin2bn(priv.elements[i].data,
-			       priv.elements[i].length, NULL);
-		if (bn == NULL)
-			DST_RET(ISC_R_NOMEMORY);
+		switch (priv.elements[i].tag) {
+		case TAG_RSA_ENGINE:
+			continue;
+		case TAG_RSA_LABEL:
+			continue;
+		case TAG_RSA_PIN:
+			continue;
+		default:
+			bn = BN_bin2bn(priv.elements[i].data,
+				       priv.elements[i].length, NULL);
+			if (bn == NULL)
+				DST_RET(ISC_R_NOMEMORY);
+		}
 
 		switch (priv.elements[i].tag) {
 			case TAG_RSA_MODULUS:
@@ -582,16 +890,64 @@ opensslrsa_parse(dst_key_t *key, isc_lex_t *lexer) {
 	dst__privstruct_free(&priv, mctx);
 
 	key->key_size = BN_num_bits(rsa->n);
+#if USE_EVP
+	RSA_free(rsa);
+#endif
 
 	return (ISC_R_SUCCESS);
 
  err:
+#if USE_EVP
+	if (pkey != NULL)
+		EVP_PKEY_free(pkey);
+#endif
+	if (rsa != NULL)
+		RSA_free(rsa);
 	opensslrsa_destroy(key);
 	dst__privstruct_free(&priv, mctx);
 	memset(&priv, 0, sizeof(priv));
 	return (ret);
 }
 
+static isc_result_t
+opensslrsa_fromlabel(dst_key_t *key, const char *engine, const char *label,
+		     const char *pin)
+{
+	ENGINE *e = NULL;
+	isc_result_t ret;
+	EVP_PKEY *pkey = NULL;
+
+	UNUSED(pin);
+
+	e = dst__openssl_getengine(engine);
+	if (e == NULL)
+		DST_RET(DST_R_NOENGINE);
+	pkey = ENGINE_load_private_key(e, label, NULL, NULL);
+	if (pkey == NULL)
+		DST_RET(ISC_R_NOMEMORY);
+	key->engine = isc_mem_strdup(key->mctx, label);
+	if (key->engine == NULL)
+		DST_RET(ISC_R_NOMEMORY);
+	key->label = isc_mem_strdup(key->mctx, label);
+	if (key->label == NULL)
+		DST_RET(ISC_R_NOMEMORY);
+	key->key_size = EVP_PKEY_bits(pkey);
+#if USE_EVP
+	key->keydata.pkey = pkey;
+#else
+	key->keydata.rsa = EVP_PKEY_get1_RSA(pkey);
+	EVP_PKEY_free(pkey);
+	if (key->keydata.rsa == NULL)
+		return (dst__openssl_toresult(DST_R_OPENSSLFAILURE));
+#endif
+	return (ISC_R_SUCCESS);
+
+ err:
+	if (pkey != NULL)
+		EVP_PKEY_free(pkey);
+	return (ret);
+}
+
 static dst_func_t opensslrsa_functions = {
 	opensslrsa_createctx,
 	opensslrsa_destroyctx,
@@ -609,6 +965,7 @@ static dst_func_t opensslrsa_functions = {
 	opensslrsa_tofile,
 	opensslrsa_parse,
 	NULL, /*%< cleanup */
+	opensslrsa_fromlabel,
 };
 
 isc_result_t
diff --git a/contrib/bind9/lib/dns/order.c b/contrib/bind9/lib/dns/order.c
index 1d216b7..853b001 100644
--- a/contrib/bind9/lib/dns/order.c
+++ b/contrib/bind9/lib/dns/order.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: order.c,v 1.5.18.3 2005/07/12 01:22:21 marka Exp $ */
+/* $Id: order.c,v 1.10 2007/06/19 23:47:16 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/dns/peer.c b/contrib/bind9/lib/dns/peer.c
index 7d878b5..12474cb 100644
--- a/contrib/bind9/lib/dns/peer.c
+++ b/contrib/bind9/lib/dns/peer.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: peer.c,v 1.19.18.8 2006/02/28 03:10:48 marka Exp $ */
+/* $Id: peer.c,v 1.31 2008/04/03 06:09:04 tbox Exp $ */
 
 /*! \file */
 
@@ -42,6 +42,7 @@
 #define SUPPORT_EDNS_BIT		5
 #define SERVER_UDPSIZE_BIT		6
 #define SERVER_MAXUDP_BIT		7
+#define REQUEST_NSID_BIT                8
 
 static void
 peerlist_delete(dns_peerlist_t **list);
@@ -146,7 +147,7 @@ dns_peerlist_addpeer(dns_peerlist_t *peers, dns_peer_t *peer) {
 		ISC_LIST_INSERTBEFORE(peers->elements, p, peer, next);
 	else
 		ISC_LIST_APPEND(peers->elements, peer, next);
-		
+
 }
 
 isc_result_t
@@ -213,7 +214,7 @@ dns_peer_new(isc_mem_t *mem, isc_netaddr_t *addr, dns_peer_t **peerptr) {
 isc_result_t
 dns_peer_newprefix(isc_mem_t *mem, isc_netaddr_t *addr, unsigned int prefixlen,
 		   dns_peer_t **peerptr)
-{ 
+{
 	dns_peer_t *peer;
 
 	REQUIRE(peerptr != NULL);
@@ -416,6 +417,32 @@ dns_peer_getsupportedns(dns_peer_t *peer, isc_boolean_t *retval) {
 }
 
 isc_result_t
+dns_peer_setrequestnsid(dns_peer_t *peer, isc_boolean_t newval) {
+	isc_boolean_t existed;
+
+	REQUIRE(DNS_PEER_VALID(peer));
+
+	existed = DNS_BIT_CHECK(REQUEST_NSID_BIT, &peer->bitflags);
+
+	peer->request_nsid = newval;
+	DNS_BIT_SET(REQUEST_NSID_BIT, &peer->bitflags);
+
+	return (existed ? ISC_R_EXISTS : ISC_R_SUCCESS);
+}
+
+isc_result_t
+dns_peer_getrequestnsid(dns_peer_t *peer, isc_boolean_t *retval) {
+	REQUIRE(DNS_PEER_VALID(peer));
+	REQUIRE(retval != NULL);
+
+	if (DNS_BIT_CHECK(REQUEST_NSID_BIT, &peer->bitflags)) {
+		*retval = peer->request_nsid;
+		return (ISC_R_SUCCESS);
+	} else
+		return (ISC_R_NOTFOUND);
+}
+
+isc_result_t
 dns_peer_settransfers(dns_peer_t *peer, isc_uint32_t newval) {
 	isc_boolean_t existed;
 
@@ -544,7 +571,7 @@ dns_peer_settransfersource(dns_peer_t *peer,
 	}
 	if (transfer_source != NULL) {
 		peer->transfer_source = isc_mem_get(peer->mem,
-					        sizeof(*peer->transfer_source));
+						sizeof(*peer->transfer_source));
 		if (peer->transfer_source == NULL)
 			return (ISC_R_NOMEMORY);
 
@@ -577,7 +604,7 @@ dns_peer_setnotifysource(dns_peer_t *peer,
 	}
 	if (notify_source != NULL) {
 		peer->notify_source = isc_mem_get(peer->mem,
-					        sizeof(*peer->notify_source));
+						sizeof(*peer->notify_source));
 		if (peer->notify_source == NULL)
 			return (ISC_R_NOMEMORY);
 
@@ -608,7 +635,7 @@ dns_peer_setquerysource(dns_peer_t *peer, const isc_sockaddr_t *query_source) {
 	}
 	if (query_source != NULL) {
 		peer->query_source = isc_mem_get(peer->mem,
-					        sizeof(*peer->query_source));
+						sizeof(*peer->query_source));
 		if (peer->query_source == NULL)
 			return (ISC_R_NOMEMORY);
 
@@ -649,11 +676,11 @@ dns_peer_getudpsize(dns_peer_t *peer, isc_uint16_t *udpsize) {
 	REQUIRE(udpsize != NULL);
 
 	if (DNS_BIT_CHECK(SERVER_UDPSIZE_BIT, &peer->bitflags)) {
-                *udpsize = peer->udpsize;
-                return (ISC_R_SUCCESS);
-        } else {
-                return (ISC_R_NOTFOUND);
-        }
+		*udpsize = peer->udpsize;
+		return (ISC_R_SUCCESS);
+	} else {
+		return (ISC_R_NOTFOUND);
+	}
 }
 
 isc_result_t
@@ -677,9 +704,9 @@ dns_peer_getmaxudp(dns_peer_t *peer, isc_uint16_t *maxudp) {
 	REQUIRE(maxudp != NULL);
 
 	if (DNS_BIT_CHECK(SERVER_MAXUDP_BIT, &peer->bitflags)) {
-                *maxudp = peer->maxudp;
-                return (ISC_R_SUCCESS);
-        } else {
-                return (ISC_R_NOTFOUND);
-        }
+		*maxudp = peer->maxudp;
+		return (ISC_R_SUCCESS);
+	} else {
+		return (ISC_R_NOTFOUND);
+	}
 }
diff --git a/contrib/bind9/lib/dns/portlist.c b/contrib/bind9/lib/dns/portlist.c
index 7e76171..5bc89f4 100644
--- a/contrib/bind9/lib/dns/portlist.c
+++ b/contrib/bind9/lib/dns/portlist.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: portlist.c,v 1.6.18.5 2006/08/25 05:25:51 marka Exp $ */
+/* $Id: portlist.c,v 1.13 2007/06/19 23:47:16 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/dns/rbt.c b/contrib/bind9/lib/dns/rbt.c
index 4d3ca3a..ff8b3a3 100644
--- a/contrib/bind9/lib/dns/rbt.c
+++ b/contrib/bind9/lib/dns/rbt.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rbt.c,v 1.128.18.10 2008/03/31 13:32:59 fdupont Exp $ */
+/* $Id: rbt.c,v 1.142.50.2 2009/01/18 23:47:40 tbox Exp $ */
 
 /*! \file */
 
@@ -37,36 +37,37 @@
 #define DNS_NAME_USEINLINE 1
 
 #include <dns/fixedname.h>
+#include <dns/log.h>
 #include <dns/rbt.h>
 #include <dns/result.h>
 
-#define RBT_MAGIC		ISC_MAGIC('R', 'B', 'T', '+')
-#define VALID_RBT(rbt)		ISC_MAGIC_VALID(rbt, RBT_MAGIC)
+#define RBT_MAGIC               ISC_MAGIC('R', 'B', 'T', '+')
+#define VALID_RBT(rbt)          ISC_MAGIC_VALID(rbt, RBT_MAGIC)
 
 /*
  * XXXDCL Since parent pointers were added in again, I could remove all of the
  * chain junk, and replace with dns_rbt_firstnode, _previousnode, _nextnode,
  * _lastnode.  This would involve pretty major change to the API.
  */
-#define CHAIN_MAGIC		ISC_MAGIC('0', '-', '0', '-')
-#define VALID_CHAIN(chain)	ISC_MAGIC_VALID(chain, CHAIN_MAGIC)
+#define CHAIN_MAGIC             ISC_MAGIC('0', '-', '0', '-')
+#define VALID_CHAIN(chain)      ISC_MAGIC_VALID(chain, CHAIN_MAGIC)
 
-#define RBT_HASH_SIZE		64
+#define RBT_HASH_SIZE           64
 
 #ifdef RBT_MEM_TEST
 #undef RBT_HASH_SIZE
-#define RBT_HASH_SIZE 2	/*%< To give the reallocation code a workout. */
+#define RBT_HASH_SIZE 2 /*%< To give the reallocation code a workout. */
 #endif
 
 struct dns_rbt {
-	unsigned int		magic;
-	isc_mem_t *		mctx;
-	dns_rbtnode_t *		root;
-	void			(*data_deleter)(void *, void *);
-	void *			deleter_arg;
-	unsigned int		nodecount;
-	unsigned int		hashsize;
-	dns_rbtnode_t **	hashtable;
+	unsigned int            magic;
+	isc_mem_t *             mctx;
+	dns_rbtnode_t *         root;
+	void                    (*data_deleter)(void *, void *);
+	void *                  deleter_arg;
+	unsigned int            nodecount;
+	unsigned int            hashsize;
+	dns_rbtnode_t **        hashtable;
 };
 
 #define RED 0
@@ -75,51 +76,51 @@ struct dns_rbt {
 /*%
  * Elements of the rbtnode structure.
  */
-#define PARENT(node)		((node)->parent)
-#define LEFT(node)	 	((node)->left)
-#define RIGHT(node)		((node)->right)
-#define DOWN(node)		((node)->down)
-#define DATA(node)		((node)->data)
-#define HASHNEXT(node)		((node)->hashnext)
-#define HASHVAL(node)		((node)->hashval)
-#define COLOR(node) 		((node)->color)
-#define NAMELEN(node)		((node)->namelen)
-#define OFFSETLEN(node)		((node)->offsetlen)
-#define ATTRS(node)		((node)->attributes)
-#define PADBYTES(node)		((node)->padbytes)
-#define IS_ROOT(node)		ISC_TF((node)->is_root == 1)
-#define FINDCALLBACK(node)	ISC_TF((node)->find_callback == 1)
+#define PARENT(node)            ((node)->parent)
+#define LEFT(node)              ((node)->left)
+#define RIGHT(node)             ((node)->right)
+#define DOWN(node)              ((node)->down)
+#define DATA(node)              ((node)->data)
+#define HASHNEXT(node)          ((node)->hashnext)
+#define HASHVAL(node)           ((node)->hashval)
+#define COLOR(node)             ((node)->color)
+#define NAMELEN(node)           ((node)->namelen)
+#define OFFSETLEN(node)         ((node)->offsetlen)
+#define ATTRS(node)             ((node)->attributes)
+#define PADBYTES(node)          ((node)->padbytes)
+#define IS_ROOT(node)           ISC_TF((node)->is_root == 1)
+#define FINDCALLBACK(node)      ISC_TF((node)->find_callback == 1)
 
 /*%
  * Structure elements from the rbtdb.c, not
  * used as part of the rbt.c algorithms.
  */
-#define DIRTY(node)	((node)->dirty)
-#define WILD(node)	((node)->wild)
-#define LOCKNUM(node)	((node)->locknum)
+#define DIRTY(node)     ((node)->dirty)
+#define WILD(node)      ((node)->wild)
+#define LOCKNUM(node)   ((node)->locknum)
 
 /*%
  * The variable length stuff stored after the node.
  */
-#define NAME(node)	((unsigned char *)((node) + 1))
-#define OFFSETS(node)	(NAME(node) + NAMELEN(node))
+#define NAME(node)      ((unsigned char *)((node) + 1))
+#define OFFSETS(node)   (NAME(node) + NAMELEN(node))
 
-#define NODE_SIZE(node)	(sizeof(*node) + \
+#define NODE_SIZE(node) (sizeof(*node) + \
 			 NAMELEN(node) + OFFSETLEN(node) + PADBYTES(node))
 
 /*%
  * Color management.
  */
-#define IS_RED(node)		((node) != NULL && (node)->color == RED)
-#define IS_BLACK(node)		((node) == NULL || (node)->color == BLACK)
-#define MAKE_RED(node)		((node)->color = RED)
-#define MAKE_BLACK(node)	((node)->color = BLACK)
+#define IS_RED(node)            ((node) != NULL && (node)->color == RED)
+#define IS_BLACK(node)          ((node) == NULL || (node)->color == BLACK)
+#define MAKE_RED(node)          ((node)->color = RED)
+#define MAKE_BLACK(node)        ((node)->color = BLACK)
 
 /*%
  * Chain management.
  *
  * The "ancestors" member of chains were removed, with their job now
- * being wholy handled by parent pointers (which didn't exist, because
+ * being wholly handled by parent pointers (which didn't exist, because
  * of memory concerns, when chains were first implemented).
  */
 #define ADD_LEVEL(chain, node) \
@@ -244,6 +245,7 @@ dns_rbt_create(isc_mem_t *mctx, void (*deleter)(void *, void *),
 	rbt->nodecount = 0;
 	rbt->hashtable = NULL;
 	rbt->hashsize = 0;
+
 #ifdef DNS_RBT_USEHASH
 	result = inithash(rbt);
 	if (result != ISC_R_SUCCESS) {
@@ -251,6 +253,7 @@ dns_rbt_create(isc_mem_t *mctx, void (*deleter)(void *, void *),
 		return (result);
 	}
 #endif
+
 	rbt->magic = RBT_MAGIC;
 
 	*rbtp = rbt;
@@ -524,6 +527,7 @@ dns_rbt_addnode(dns_rbt_t *rbt, dns_name_t *name, dns_rbtnode_t **nodep) {
 				 * current node.
 				 */
 				new_current->is_root = current->is_root;
+				new_current->nsec3 = current->nsec3;
 				PARENT(new_current)  = PARENT(current);
 				LEFT(new_current)    = LEFT(current);
 				RIGHT(new_current)   = RIGHT(current);
@@ -1142,7 +1146,7 @@ dns_rbt_findnode(dns_rbt_t *rbt, dns_name_t *name, dns_name_t *foundname,
 									NULL);
 					if (result2 == ISC_R_SUCCESS ||
 					    result2 == DNS_R_NEWORIGIN)
-						; 	/* Nothing. */
+						;       /* Nothing. */
 					else if (result2 == ISC_R_NOMORE)
 						/*
 						 * There is no predecessor.
@@ -1274,8 +1278,7 @@ dns_rbt_deletenode(dns_rbt_t *rbt, dns_rbtnode_t *node, isc_boolean_t recurse)
 				      == ISC_R_SUCCESS);
 		else {
 			if (DATA(node) != NULL && rbt->data_deleter != NULL)
-				rbt->data_deleter(DATA(node),
-						  rbt->deleter_arg);
+				rbt->data_deleter(DATA(node), rbt->deleter_arg);
 			DATA(node) = NULL;
 
 			/*
@@ -1436,11 +1439,14 @@ create_node(isc_mem_t *mctx, dns_name_t *name, dns_rbtnode_t **nodep) {
 	HASHVAL(node) = 0;
 #endif
 
+	ISC_LINK_INIT(node, deadlink);
+
 	LOCKNUM(node) = 0;
 	WILD(node) = 0;
 	DIRTY(node) = 0;
 	dns_rbtnode_refinit(node, 0);
 	node->find_callback = 0;
+	node->nsec3 = 0;
 
 	MAKE_BLACK(node);
 
@@ -1451,9 +1457,9 @@ create_node(isc_mem_t *mctx, dns_name_t *name, dns_rbtnode_t **nodep) {
 	 * and the name's offsets table.
 	 *
 	 * XXX RTH
-	 *	The offsets table could be made smaller by eliminating the
-	 *	first offset, which is always 0.  This requires changes to
-	 * 	lib/dns/name.c.
+	 *      The offsets table could be made smaller by eliminating the
+	 *      first offset, which is always 0.  This requires changes to
+	 *      lib/dns/name.c.
 	 */
 	NAMELEN(node) = region.length;
 	PADBYTES(node) = 0;
@@ -1934,7 +1940,7 @@ dns_rbt_deletefromlevel(dns_rbtnode_t *delete, dns_rbtnode_t **rootp) {
 			} else {
 				/*
 				 * Child is parent's right child.
-				 * Everything is doen the same as above,
+				 * Everything is done the same as above,
 				 * except mirrored.
 				 */
 				sibling = LEFT(parent);
@@ -2027,6 +2033,7 @@ dns_rbt_deletetree(dns_rbt_t *rbt, dns_rbtnode_t *node) {
 #if DNS_RBT_USEMAGIC
 	node->magic = 0;
 #endif
+
 	isc_mem_put(rbt->mctx, node, NODE_SIZE(node));
 	rbt->nodecount--;
 	return (result);
@@ -2076,6 +2083,7 @@ dns_rbt_deletetreeflat(dns_rbt_t *rbt, unsigned int quantum,
 			DOWN(parent) = RIGHT(node);
 	} else
 		parent = RIGHT(node);
+
 	isc_mem_put(rbt->mctx, node, NODE_SIZE(node));
 	rbt->nodecount--;
 	node = parent;
@@ -2354,6 +2362,113 @@ dns_rbtnodechain_prev(dns_rbtnodechain_t *chain, dns_name_t *name,
 }
 
 isc_result_t
+dns_rbtnodechain_down(dns_rbtnodechain_t *chain, dns_name_t *name,
+		      dns_name_t *origin)
+{
+	dns_rbtnode_t *current, *successor;
+	isc_result_t result = ISC_R_SUCCESS;
+	isc_boolean_t new_origin = ISC_FALSE;
+
+	REQUIRE(VALID_CHAIN(chain) && chain->end != NULL);
+
+	successor = NULL;
+
+	current = chain->end;
+
+	if (DOWN(current) != NULL) {
+		/*
+		 * Don't declare an origin change when the new origin is "."
+		 * at the second level tree, because "." is already declared
+		 * as the origin for the top level tree.
+		 */
+		if (chain->level_count > 0 ||
+		    OFFSETLEN(current) > 1)
+			new_origin = ISC_TRUE;
+
+		ADD_LEVEL(chain, current);
+		current = DOWN(current);
+
+		while (LEFT(current) != NULL)
+			current = LEFT(current);
+
+		successor = current;
+	}
+
+	if (successor != NULL) {
+		chain->end = successor;
+
+		/*
+		 * It is not necessary to use dns_rbtnodechain_current like
+		 * the other functions because this function will never
+		 * find a node in the topmost level.  This is because the
+		 * root level will never be more than one name, and everything
+		 * in the megatree is a successor to that node, down at
+		 * the second level or below.
+		 */
+
+		if (name != NULL)
+			NODENAME(chain->end, name);
+
+		if (new_origin) {
+			if (origin != NULL)
+				result = chain_name(chain, origin, ISC_FALSE);
+
+			if (result == ISC_R_SUCCESS)
+				result = DNS_R_NEWORIGIN;
+
+		} else
+			result = ISC_R_SUCCESS;
+
+	} else
+		result = ISC_R_NOMORE;
+
+	return (result);
+}
+
+isc_result_t
+dns_rbtnodechain_nextflat(dns_rbtnodechain_t *chain, dns_name_t *name) {
+	dns_rbtnode_t *current, *previous, *successor;
+	isc_result_t result = ISC_R_SUCCESS;
+
+	REQUIRE(VALID_CHAIN(chain) && chain->end != NULL);
+
+	successor = NULL;
+
+	current = chain->end;
+
+	if (RIGHT(current) == NULL) {
+		while (! IS_ROOT(current)) {
+			previous = current;
+			current = PARENT(current);
+
+			if (LEFT(current) == previous) {
+				successor = current;
+				break;
+			}
+		}
+	} else {
+		current = RIGHT(current);
+
+		while (LEFT(current) != NULL)
+			current = LEFT(current);
+
+		successor = current;
+	}
+
+	if (successor != NULL) {
+		chain->end = successor;
+
+		if (name != NULL)
+			NODENAME(chain->end, name);
+
+		result = ISC_R_SUCCESS;
+	} else
+		result = ISC_R_NOMORE;
+
+	return (result);
+}
+
+isc_result_t
 dns_rbtnodechain_next(dns_rbtnodechain_t *chain, dns_name_t *name,
 		      dns_name_t *origin)
 {
@@ -2398,7 +2513,7 @@ dns_rbtnodechain_next(dns_rbtnodechain_t *chain, dns_name_t *name,
 		 * reached without having traversed any left links, ascend one
 		 * level and look for either a right link off the point of
 		 * ascent, or search for a left link upward again, repeating
-		 * ascents until either case is true.
+		 * ascends until either case is true.
 		 */
 		do {
 			while (! IS_ROOT(current)) {
diff --git a/contrib/bind9/lib/dns/rbtdb.c b/contrib/bind9/lib/dns/rbtdb.c
index 462a718..9741c15 100644
--- a/contrib/bind9/lib/dns/rbtdb.c
+++ b/contrib/bind9/lib/dns/rbtdb.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rbtdb.c,v 1.196.18.53 2008/01/31 23:46:05 tbox Exp $ */
+/* $Id: rbtdb.c,v 1.270.12.6 2009/05/06 23:34:30 jinmei Exp $ */
 
 /*! \file */
 
@@ -25,13 +25,18 @@
 
 #include <config.h>
 
+/* #define inline */
+
 #include <isc/event.h>
+#include <isc/heap.h>
 #include <isc/mem.h>
-#include <isc/print.h>
 #include <isc/mutex.h>
+#include <isc/platform.h>
+#include <isc/print.h>
 #include <isc/random.h>
 #include <isc/refcount.h>
 #include <isc/rwlock.h>
+#include <isc/serial.h>
 #include <isc/string.h>
 #include <isc/task.h>
 #include <isc/time.h>
@@ -45,12 +50,16 @@
 #include <dns/lib.h>
 #include <dns/log.h>
 #include <dns/masterdump.h>
+#include <dns/nsec.h>
+#include <dns/nsec3.h>
 #include <dns/rbt.h>
 #include <dns/rdata.h>
 #include <dns/rdataset.h>
 #include <dns/rdatasetiter.h>
 #include <dns/rdataslab.h>
+#include <dns/rdatastruct.h>
 #include <dns/result.h>
+#include <dns/stats.h>
 #include <dns/view.h>
 #include <dns/zone.h>
 #include <dns/zonekey.h>
@@ -62,20 +71,20 @@
 #endif
 
 #ifdef DNS_RBTDB_VERSION64
-#define RBTDB_MAGIC			ISC_MAGIC('R', 'B', 'D', '8')
+#define RBTDB_MAGIC                     ISC_MAGIC('R', 'B', 'D', '8')
 #else
-#define RBTDB_MAGIC			ISC_MAGIC('R', 'B', 'D', '4')
+#define RBTDB_MAGIC                     ISC_MAGIC('R', 'B', 'D', '4')
 #endif
 
 /*%
  * Note that "impmagic" is not the first four bytes of the struct, so
  * ISC_MAGIC_VALID cannot be used.
  */
-#define VALID_RBTDB(rbtdb)	((rbtdb) != NULL && \
+#define VALID_RBTDB(rbtdb)      ((rbtdb) != NULL && \
 				 (rbtdb)->common.impmagic == RBTDB_MAGIC)
 
 #ifdef DNS_RBTDB_VERSION64
-typedef isc_uint64_t			rbtdb_serial_t;
+typedef isc_uint64_t                    rbtdb_serial_t;
 /*%
  * Make casting easier in symbolic debuggers by using different names
  * for the 64 bit version.
@@ -84,17 +93,19 @@ typedef isc_uint64_t			rbtdb_serial_t;
 #define rdatasetheader_t rdatasetheader64_t
 #define rbtdb_version_t rbtdb_version64_t
 #else
-typedef isc_uint32_t			rbtdb_serial_t;
+typedef isc_uint32_t                    rbtdb_serial_t;
 #endif
 
-typedef isc_uint32_t			rbtdb_rdatatype_t;
+typedef isc_uint32_t                    rbtdb_rdatatype_t;
 
-#define RBTDB_RDATATYPE_BASE(type)	((dns_rdatatype_t)((type) & 0xFFFF))
-#define RBTDB_RDATATYPE_EXT(type)	((dns_rdatatype_t)((type) >> 16))
-#define RBTDB_RDATATYPE_VALUE(b, e)	(((e) << 16) | (b))
+#define RBTDB_RDATATYPE_BASE(type)      ((dns_rdatatype_t)((type) & 0xFFFF))
+#define RBTDB_RDATATYPE_EXT(type)       ((dns_rdatatype_t)((type) >> 16))
+#define RBTDB_RDATATYPE_VALUE(b, e)     ((rbtdb_rdatatype_t)((e) << 16) | (b))
 
 #define RBTDB_RDATATYPE_SIGNSEC \
 		RBTDB_RDATATYPE_VALUE(dns_rdatatype_rrsig, dns_rdatatype_nsec)
+#define RBTDB_RDATATYPE_SIGNSEC3 \
+		RBTDB_RDATATYPE_VALUE(dns_rdatatype_rrsig, dns_rdatatype_nsec3)
 #define RBTDB_RDATATYPE_SIGNS \
 		RBTDB_RDATATYPE_VALUE(dns_rdatatype_rrsig, dns_rdatatype_ns)
 #define RBTDB_RDATATYPE_SIGCNAME \
@@ -119,15 +130,15 @@ typedef isc_uint32_t			rbtdb_rdatatype_t;
 #endif
 
 #if DNS_RBTDB_USERWLOCK
-#define RBTDB_INITLOCK(l)	isc_rwlock_init((l), 0, 0)
-#define RBTDB_DESTROYLOCK(l)	isc_rwlock_destroy(l)
-#define RBTDB_LOCK(l, t)	RWLOCK((l), (t))
-#define RBTDB_UNLOCK(l, t)	RWUNLOCK((l), (t))
+#define RBTDB_INITLOCK(l)       isc_rwlock_init((l), 0, 0)
+#define RBTDB_DESTROYLOCK(l)    isc_rwlock_destroy(l)
+#define RBTDB_LOCK(l, t)        RWLOCK((l), (t))
+#define RBTDB_UNLOCK(l, t)      RWUNLOCK((l), (t))
 #else
-#define RBTDB_INITLOCK(l)	isc_mutex_init(l)
-#define RBTDB_DESTROYLOCK(l)	DESTROYLOCK(l)
-#define RBTDB_LOCK(l, t)	LOCK(l)
-#define RBTDB_UNLOCK(l, t)	UNLOCK(l)
+#define RBTDB_INITLOCK(l)       isc_mutex_init(l)
+#define RBTDB_DESTROYLOCK(l)    DESTROYLOCK(l)
+#define RBTDB_LOCK(l, t)        LOCK(l)
+#define RBTDB_UNLOCK(l, t)      UNLOCK(l)
 #endif
 
 /*
@@ -152,47 +163,53 @@ typedef isc_uint32_t			rbtdb_rdatatype_t;
 #if defined(ISC_RWLOCK_USEATOMIC) && defined(DNS_RBT_USEISCREFCOUNT)
 typedef isc_rwlock_t nodelock_t;
 
-#define NODE_INITLOCK(l)	isc_rwlock_init((l), 0, 0)
-#define NODE_DESTROYLOCK(l)	isc_rwlock_destroy(l)
-#define NODE_LOCK(l, t)		RWLOCK((l), (t))
-#define NODE_UNLOCK(l, t)	RWUNLOCK((l), (t))
-#define NODE_TRYUPGRADE(l)	isc_rwlock_tryupgrade(l)
-
-#define NODE_STRONGLOCK(l)	((void)0)
-#define NODE_STRONGUNLOCK(l)	((void)0)
-#define NODE_WEAKLOCK(l, t)	NODE_LOCK(l, t)
-#define NODE_WEAKUNLOCK(l, t)	NODE_UNLOCK(l, t)
-#define NODE_WEAKDOWNGRADE(l)	isc_rwlock_downgrade(l)
+#define NODE_INITLOCK(l)        isc_rwlock_init((l), 0, 0)
+#define NODE_DESTROYLOCK(l)     isc_rwlock_destroy(l)
+#define NODE_LOCK(l, t)         RWLOCK((l), (t))
+#define NODE_UNLOCK(l, t)       RWUNLOCK((l), (t))
+#define NODE_TRYUPGRADE(l)      isc_rwlock_tryupgrade(l)
+
+#define NODE_STRONGLOCK(l)      ((void)0)
+#define NODE_STRONGUNLOCK(l)    ((void)0)
+#define NODE_WEAKLOCK(l, t)     NODE_LOCK(l, t)
+#define NODE_WEAKUNLOCK(l, t)   NODE_UNLOCK(l, t)
+#define NODE_WEAKDOWNGRADE(l)   isc_rwlock_downgrade(l)
 #else
 typedef isc_mutex_t nodelock_t;
 
-#define NODE_INITLOCK(l)	isc_mutex_init(l)
-#define NODE_DESTROYLOCK(l)	DESTROYLOCK(l)
-#define NODE_LOCK(l, t)		LOCK(l)
-#define NODE_UNLOCK(l, t)	UNLOCK(l)
-#define NODE_TRYUPGRADE(l)	ISC_R_SUCCESS
-
-#define NODE_STRONGLOCK(l)	LOCK(l)
-#define NODE_STRONGUNLOCK(l)	UNLOCK(l)
-#define NODE_WEAKLOCK(l, t)	((void)0)
-#define NODE_WEAKUNLOCK(l, t)	((void)0)
-#define NODE_WEAKDOWNGRADE(l)	((void)0)
+#define NODE_INITLOCK(l)        isc_mutex_init(l)
+#define NODE_DESTROYLOCK(l)     DESTROYLOCK(l)
+#define NODE_LOCK(l, t)         LOCK(l)
+#define NODE_UNLOCK(l, t)       UNLOCK(l)
+#define NODE_TRYUPGRADE(l)      ISC_R_SUCCESS
+
+#define NODE_STRONGLOCK(l)      LOCK(l)
+#define NODE_STRONGUNLOCK(l)    UNLOCK(l)
+#define NODE_WEAKLOCK(l, t)     ((void)0)
+#define NODE_WEAKUNLOCK(l, t)   ((void)0)
+#define NODE_WEAKDOWNGRADE(l)   ((void)0)
 #endif
 
-#ifndef DNS_RDATASET_FIXED
-#define DNS_RDATASET_FIXED 1
+/*%
+ * Whether to rate-limit updating the LRU to avoid possible thread contention.
+ * Our performance measurement has shown the cost is marginal, so it's defined
+ * to be 0 by default either with or without threads.
+ */
+#ifndef DNS_RBTDB_LIMITLRUUPDATE
+#define DNS_RBTDB_LIMITLRUUPDATE 0
 #endif
 
 /*
- * Allow clients with a virtual time of upto 5 minutes in the past to see
+ * Allow clients with a virtual time of up to 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;
-	void *	   nsecsig;
+	dns_name_t 	name;
+	void *     	neg;
+	void *     	negsig;
+	dns_rdatatype_t	type;
 };
 
 typedef struct acachectl acachectl_t;
@@ -201,18 +218,19 @@ typedef struct rdatasetheader {
 	/*%
 	 * Locked by the owning node's lock.
 	 */
-	rbtdb_serial_t			serial;
-	dns_ttl_t			ttl;
-	rbtdb_rdatatype_t		type;
-	isc_uint16_t			attributes;
-	dns_trust_t			trust;
-	struct noqname			*noqname;
+	rbtdb_serial_t                  serial;
+	dns_ttl_t                       rdh_ttl;
+	rbtdb_rdatatype_t               type;
+	isc_uint16_t                    attributes;
+	dns_trust_t                     trust;
+	struct noqname                  *noqname;
+	struct noqname                  *closest;
 	/*%<
 	 * We don't use the LIST macros, because the LIST structure has
 	 * both head and tail pointers, and is doubly linked.
 	 */
 
-	struct rdatasetheader		*next;
+	struct rdatasetheader           *next;
 	/*%<
 	 * If this is the top header for an rdataset, 'next' points
 	 * to the top header for the next rdataset (i.e., the next type).
@@ -220,13 +238,13 @@ typedef struct rdatasetheader {
 	 * at this header.
 	 */
 
-	struct rdatasetheader		*down;
+	struct rdatasetheader           *down;
 	/*%<
 	 * Points to the header for the next older version of
 	 * this rdataset.
 	 */
 
-	isc_uint32_t			count;
+	isc_uint32_t                    count;
 	/*%<
 	 * Monotonously increased every time this rdataset is bound so that
 	 * it is used as the base of the starting point in DNS responses
@@ -235,27 +253,56 @@ typedef struct rdatasetheader {
 	 * performance reasons.
 	 */
 
-	acachectl_t			*additional_auth;
-	acachectl_t			*additional_glue;
+	acachectl_t                     *additional_auth;
+	acachectl_t                     *additional_glue;
+
+	dns_rbtnode_t                   *node;
+	isc_stdtime_t                   last_used;
+	ISC_LINK(struct rdatasetheader) lru_link;
+	/*%<
+	 * Used for LRU-based cache management.  We should probably make
+	 * these cache-DB specific.  We might also make it a pointer and
+	 * ensure only the top header has a valid link to save memory.
+	 * The linked-list is locked by the rbtdb->lrulock.
+	 */
+
+	/*
+	 * It's possible this should not be here anymore, but instead
+	 * referenced from the bucket's heap directly.
+	 */
+#if 0
+	isc_heap_t                      *heap;
+#endif
+	unsigned int                    heap_index;
+	/*%<
+	 * Used for TTL-based cache cleaning.
+	 */
+	isc_stdtime_t                   resign;
 } rdatasetheader_t;
 
-#define RDATASET_ATTR_NONEXISTENT	0x0001
-#define RDATASET_ATTR_STALE		0x0002
-#define RDATASET_ATTR_IGNORE		0x0004
-#define RDATASET_ATTR_RETAIN		0x0008
-#define RDATASET_ATTR_NXDOMAIN		0x0010
+typedef ISC_LIST(rdatasetheader_t)      rdatasetheaderlist_t;
+typedef ISC_LIST(dns_rbtnode_t)         rbtnodelist_t;
+
+#define RDATASET_ATTR_NONEXISTENT       0x0001
+#define RDATASET_ATTR_STALE             0x0002
+#define RDATASET_ATTR_IGNORE            0x0004
+#define RDATASET_ATTR_RETAIN            0x0008
+#define RDATASET_ATTR_NXDOMAIN          0x0010
+#define RDATASET_ATTR_RESIGN            0x0020
+#define RDATASET_ATTR_STATCOUNT         0x0040
+#define RDATASET_ATTR_OPTOUT		0x0080
 
 typedef struct acache_cbarg {
-	dns_rdatasetadditional_t	type;
-	unsigned int			count;
-	dns_db_t			*db;
-	dns_dbnode_t			*node;
-	rdatasetheader_t		*header;
+	dns_rdatasetadditional_t        type;
+	unsigned int                    count;
+	dns_db_t                        *db;
+	dns_dbnode_t                    *node;
+	rdatasetheader_t                *header;
 } acache_cbarg_t;
 
 struct acachectl {
-	dns_acacheentry_t		*entry;
-	acache_cbarg_t			*cbarg;
+	dns_acacheentry_t               *entry;
+	acache_cbarg_t                  *cbarg;
 };
 
 /*
@@ -266,7 +313,7 @@ struct acachectl {
  * expired.
  */
 
-#undef IGNORE			/* WIN32 winbase.h defines this. */
+#undef IGNORE                   /* WIN32 winbase.h defines this. */
 
 #define EXISTS(header) \
 	(((header)->attributes & RDATASET_ATTR_NONEXISTENT) == 0)
@@ -278,106 +325,164 @@ struct acachectl {
 	(((header)->attributes & RDATASET_ATTR_RETAIN) != 0)
 #define NXDOMAIN(header) \
 	(((header)->attributes & RDATASET_ATTR_NXDOMAIN) != 0)
+#define RESIGN(header) \
+	(((header)->attributes & RDATASET_ATTR_RESIGN) != 0)
+#define OPTOUT(header) \
+	(((header)->attributes & RDATASET_ATTR_OPTOUT) != 0)
+
+#define DEFAULT_NODE_LOCK_COUNT         7       /*%< Should be prime. */
 
-#define DEFAULT_NODE_LOCK_COUNT		7	/*%< Should be prime. */
-#define DEFAULT_CACHE_NODE_LOCK_COUNT	1009	/*%< Should be prime. */
+/*%
+ * Number of buckets for cache DB entries (locks, LRU lists, TTL heaps).
+ * There is a tradeoff issue about configuring this value: if this is too
+ * small, it may cause heavier contention between threads; if this is too large,
+ * LRU purge algorithm won't work well (entries tend to be purged prematurely).
+ * The default value should work well for most environments, but this can
+ * also be configurable at compilation time via the
+ * DNS_RBTDB_CACHE_NODE_LOCK_COUNT variable.  This value must be larger than
+ * 1 due to the assumption of overmem_purge().
+ */
+#ifdef DNS_RBTDB_CACHE_NODE_LOCK_COUNT
+#if DNS_RBTDB_CACHE_NODE_LOCK_COUNT <= 1
+#error "DNS_RBTDB_CACHE_NODE_LOCK_COUNT must be larger than 1"
+#else
+#define DEFAULT_CACHE_NODE_LOCK_COUNT DNS_RBTDB_CACHE_NODE_LOCK_COUNT
+#endif
+#else
+#define DEFAULT_CACHE_NODE_LOCK_COUNT   16
+#endif	/* DNS_RBTDB_CACHE_NODE_LOCK_COUNT */
 
 typedef struct {
-	nodelock_t			lock;
+	nodelock_t                      lock;
 	/* Protected in the refcount routines. */
-	isc_refcount_t			references;
+	isc_refcount_t                  references;
 	/* Locked by lock. */
-	isc_boolean_t			exiting;
+	isc_boolean_t                   exiting;
 } rbtdb_nodelock_t;
 
 typedef struct rbtdb_changed {
-	dns_rbtnode_t *			node;
-	isc_boolean_t			dirty;
-	ISC_LINK(struct rbtdb_changed)	link;
+	dns_rbtnode_t *                 node;
+	isc_boolean_t                   dirty;
+	ISC_LINK(struct rbtdb_changed)  link;
 } rbtdb_changed_t;
 
-typedef ISC_LIST(rbtdb_changed_t)	rbtdb_changedlist_t;
+typedef ISC_LIST(rbtdb_changed_t)       rbtdb_changedlist_t;
+
+typedef enum {
+	dns_db_insecure,
+	dns_db_partial,
+	dns_db_secure
+} dns_db_secure_t;
 
 typedef struct rbtdb_version {
 	/* Not locked */
-	rbtdb_serial_t			serial;
+	rbtdb_serial_t                  serial;
 	/*
 	 * Protected in the refcount routines.
 	 * XXXJT: should we change the lock policy based on the refcount
 	 * performance?
 	 */
-	isc_refcount_t			references;
+	isc_refcount_t                  references;
 	/* Locked by database lock. */
-	isc_boolean_t			writer;
-	isc_boolean_t			commit_ok;
-	rbtdb_changedlist_t		changed_list;
-	ISC_LINK(struct rbtdb_version)	link;
+	isc_boolean_t                   writer;
+	isc_boolean_t                   commit_ok;
+	rbtdb_changedlist_t             changed_list;
+	rdatasetheaderlist_t		resigned_list;
+	ISC_LINK(struct rbtdb_version)  link;
+	dns_db_secure_t			secure;
+	isc_boolean_t			havensec3;
+	/* NSEC3 parameters */
+	dns_hash_t			hash;
+	isc_uint8_t			flags;
+	isc_uint16_t			iterations;
+	isc_uint8_t			salt_length;
+	unsigned char			salt[NSEC3_MAX_HASH_LENGTH];
 } rbtdb_version_t;
 
-typedef ISC_LIST(rbtdb_version_t)	rbtdb_versionlist_t;
+typedef ISC_LIST(rbtdb_version_t)       rbtdb_versionlist_t;
 
 typedef struct {
 	/* Unlocked. */
-	dns_db_t			common;
+	dns_db_t                        common;
 #if DNS_RBTDB_USERWLOCK
-	isc_rwlock_t			lock;
+	isc_rwlock_t                    lock;
 #else
-	isc_mutex_t			lock;
+	isc_mutex_t                     lock;
 #endif
-	isc_rwlock_t			tree_lock;
-	unsigned int			node_lock_count;
-	rbtdb_nodelock_t *	       	node_locks;
-	dns_rbtnode_t *			origin_node;
+	isc_rwlock_t                    tree_lock;
+	unsigned int                    node_lock_count;
+	rbtdb_nodelock_t *              node_locks;
+	dns_rbtnode_t *                 origin_node;
+	dns_stats_t *			rrsetstats; /* cache DB only */
 	/* Locked by lock. */
-	unsigned int			active;
-	isc_refcount_t			references;
-	unsigned int			attributes;
-	rbtdb_serial_t			current_serial;
-	rbtdb_serial_t			least_serial;
-	rbtdb_serial_t			next_serial;
-	rbtdb_version_t *		current_version;
-	rbtdb_version_t *		future_version;
-	rbtdb_versionlist_t		open_versions;
-	isc_boolean_t			overmem;
-	isc_task_t *			task;
-	dns_dbnode_t			*soanode;
-	dns_dbnode_t			*nsnode;
+	unsigned int                    active;
+	isc_refcount_t                  references;
+	unsigned int                    attributes;
+	rbtdb_serial_t                  current_serial;
+	rbtdb_serial_t                  least_serial;
+	rbtdb_serial_t                  next_serial;
+	rbtdb_version_t *               current_version;
+	rbtdb_version_t *               future_version;
+	rbtdb_versionlist_t             open_versions;
+	isc_boolean_t                   overmem;
+	isc_task_t *                    task;
+	dns_dbnode_t                    *soanode;
+	dns_dbnode_t                    *nsnode;
+
+	/*
+	 * This is a linked list used to implement the LRU cache.  There will
+	 * be node_lock_count linked lists here.  Nodes in bucket 1 will be
+	 * placed on the linked list rdatasets[1].
+	 */
+	rdatasetheaderlist_t            *rdatasets;
+
+	/*%
+	 * Temporary storage for stale cache nodes and dynamically deleted
+	 * nodes that await being cleaned up.
+	 */
+	rbtnodelist_t                   *deadnodes;
+
+	/*
+	 * Heaps.  Each of these is used for TTL based expiry.
+	 */
+	isc_heap_t                      **heaps;
+
 	/* Locked by tree_lock. */
-	dns_rbt_t *			tree;
-	isc_boolean_t			secure;
+	dns_rbt_t *                     tree;
+	dns_rbt_t *			nsec3;
 
 	/* Unlocked */
-	unsigned int			quantum;
+	unsigned int                    quantum;
 } dns_rbtdb_t;
 
-#define RBTDB_ATTR_LOADED		0x01
-#define RBTDB_ATTR_LOADING		0x02
+#define RBTDB_ATTR_LOADED               0x01
+#define RBTDB_ATTR_LOADING              0x02
 
 /*%
  * Search Context
  */
 typedef struct {
-	dns_rbtdb_t *		rbtdb;
-	rbtdb_version_t *	rbtversion;
-	rbtdb_serial_t		serial;
-	unsigned int		options;
-	dns_rbtnodechain_t	chain;
-	isc_boolean_t		copy_name;
-	isc_boolean_t		need_cleanup;
-	isc_boolean_t		wild;
-	dns_rbtnode_t *	       	zonecut;
-	rdatasetheader_t *	zonecut_rdataset;
-	rdatasetheader_t *	zonecut_sigrdataset;
-	dns_fixedname_t		zonecut_name;
-	isc_stdtime_t		now;
+	dns_rbtdb_t *           rbtdb;
+	rbtdb_version_t *       rbtversion;
+	rbtdb_serial_t          serial;
+	unsigned int            options;
+	dns_rbtnodechain_t      chain;
+	isc_boolean_t           copy_name;
+	isc_boolean_t           need_cleanup;
+	isc_boolean_t           wild;
+	dns_rbtnode_t *         zonecut;
+	rdatasetheader_t *      zonecut_rdataset;
+	rdatasetheader_t *      zonecut_sigrdataset;
+	dns_fixedname_t         zonecut_name;
+	isc_stdtime_t           now;
 } rbtdb_search_t;
 
 /*%
  * Load Context
  */
 typedef struct {
-	dns_rbtdb_t *		rbtdb;
-	isc_stdtime_t		now;
+	dns_rbtdb_t *           rbtdb;
+	isc_stdtime_t           now;
 } rbtdb_load_t;
 
 static void rdataset_disassociate(dns_rdataset_t *rdataset);
@@ -388,8 +493,12 @@ static void rdataset_clone(dns_rdataset_t *source, dns_rdataset_t *target);
 static unsigned int rdataset_count(dns_rdataset_t *rdataset);
 static isc_result_t rdataset_getnoqname(dns_rdataset_t *rdataset,
 					dns_name_t *name,
-					dns_rdataset_t *nsec,
-					dns_rdataset_t *nsecsig);
+					dns_rdataset_t *neg,
+					dns_rdataset_t *negsig);
+static isc_result_t rdataset_getclosest(dns_rdataset_t *rdataset,
+					dns_name_t *name,
+					dns_rdataset_t *neg,
+					dns_rdataset_t *negsig);
 static isc_result_t rdataset_getadditional(dns_rdataset_t *rdataset,
 					   dns_rdatasetadditional_t type,
 					   dns_rdatatype_t qtype,
@@ -414,6 +523,17 @@ static isc_result_t rdataset_putadditional(dns_acache_t *acache,
 					   dns_rdataset_t *rdataset,
 					   dns_rdatasetadditional_t type,
 					   dns_rdatatype_t qtype);
+static inline isc_boolean_t need_headerupdate(rdatasetheader_t *header,
+					      isc_stdtime_t now);
+static void update_header(dns_rbtdb_t *rbtdb, rdatasetheader_t *header,
+			  isc_stdtime_t now);
+static void expire_header(dns_rbtdb_t *rbtdb, rdatasetheader_t *header,
+			  isc_boolean_t tree_locked);
+static void overmem_purge(dns_rbtdb_t *rbtdb, unsigned int locknum_start,
+			  isc_stdtime_t now, isc_boolean_t tree_locked);
+static isc_result_t resign_insert(dns_rbtdb_t *rbtdb, int idx,
+				  rdatasetheader_t *newheader);
+static void prune_tree(isc_task_t *task, isc_event_t *event);
 
 static dns_rdatasetmethods_t rdataset_methods = {
 	rdataset_disassociate,
@@ -424,6 +544,8 @@ static dns_rdatasetmethods_t rdataset_methods = {
 	rdataset_count,
 	NULL,
 	rdataset_getnoqname,
+	NULL,
+	rdataset_getclosest,
 	rdataset_getadditional,
 	rdataset_setadditional,
 	rdataset_putadditional
@@ -443,22 +565,22 @@ static dns_rdatasetitermethods_t rdatasetiter_methods = {
 };
 
 typedef struct rbtdb_rdatasetiter {
-	dns_rdatasetiter_t		common;
-	rdatasetheader_t *		current;
+	dns_rdatasetiter_t              common;
+	rdatasetheader_t *              current;
 } rbtdb_rdatasetiter_t;
 
-static void		dbiterator_destroy(dns_dbiterator_t **iteratorp);
-static isc_result_t	dbiterator_first(dns_dbiterator_t *iterator);
-static isc_result_t	dbiterator_last(dns_dbiterator_t *iterator);
-static isc_result_t	dbiterator_seek(dns_dbiterator_t *iterator,
+static void             dbiterator_destroy(dns_dbiterator_t **iteratorp);
+static isc_result_t     dbiterator_first(dns_dbiterator_t *iterator);
+static isc_result_t     dbiterator_last(dns_dbiterator_t *iterator);
+static isc_result_t     dbiterator_seek(dns_dbiterator_t *iterator,
 					dns_name_t *name);
-static isc_result_t	dbiterator_prev(dns_dbiterator_t *iterator);
-static isc_result_t	dbiterator_next(dns_dbiterator_t *iterator);
-static isc_result_t	dbiterator_current(dns_dbiterator_t *iterator,
+static isc_result_t     dbiterator_prev(dns_dbiterator_t *iterator);
+static isc_result_t     dbiterator_next(dns_dbiterator_t *iterator);
+static isc_result_t     dbiterator_current(dns_dbiterator_t *iterator,
 					   dns_dbnode_t **nodep,
 					   dns_name_t *name);
-static isc_result_t	dbiterator_pause(dns_dbiterator_t *iterator);
-static isc_result_t	dbiterator_origin(dns_dbiterator_t *iterator,
+static isc_result_t     dbiterator_pause(dns_dbiterator_t *iterator);
+static isc_result_t     dbiterator_origin(dns_dbiterator_t *iterator,
 					  dns_name_t *name);
 
 static dns_dbiteratormethods_t dbiterator_methods = {
@@ -479,17 +601,21 @@ static dns_dbiteratormethods_t dbiterator_methods = {
  * If 'paused' is ISC_TRUE, then the tree lock is not being held.
  */
 typedef struct rbtdb_dbiterator {
-	dns_dbiterator_t		common;
-	isc_boolean_t			paused;
-	isc_boolean_t			new_origin;
-	isc_rwlocktype_t		tree_locked;
-	isc_result_t			result;
-	dns_fixedname_t			name;
-	dns_fixedname_t			origin;
-	dns_rbtnodechain_t		chain;
-	dns_rbtnode_t			*node;
-	dns_rbtnode_t			*deletions[DELETION_BATCH_MAX];
-	int				delete;
+	dns_dbiterator_t                common;
+	isc_boolean_t                   paused;
+	isc_boolean_t                   new_origin;
+	isc_rwlocktype_t                tree_locked;
+	isc_result_t                    result;
+	dns_fixedname_t                 name;
+	dns_fixedname_t                 origin;
+	dns_rbtnodechain_t              chain;
+	dns_rbtnodechain_t		nsec3chain;
+	dns_rbtnodechain_t		*current;
+	dns_rbtnode_t                   *node;
+	dns_rbtnode_t                   *deletions[DELETION_BATCH_MAX];
+	int                             delete;
+	isc_boolean_t			nsec3only;
+	isc_boolean_t			nonsec3;
 } rbtdb_dbiterator_t;
 
 
@@ -498,17 +624,20 @@ typedef struct rbtdb_dbiterator {
 
 static void free_rbtdb(dns_rbtdb_t *rbtdb, isc_boolean_t log,
 		       isc_event_t *event);
+static void overmem(dns_db_t *db, isc_boolean_t overmem);
+static void setnsec3parameters(dns_db_t *db, rbtdb_version_t *version,
+			       isc_boolean_t *nsec3createflag);
 
 /*%
  * 'init_count' is used to initialize 'newheader->count' which inturn
  * is used to determine where in the cycle rrset-order cyclic starts.
- * We don't lock this as we don't care about simultanious updates.
+ * We don't lock this as we don't care about simultaneous updates.
  *
  * Note:
- *	Both init_count and header->count can be ISC_UINT32_MAX.
+ *      Both init_count and header->count can be ISC_UINT32_MAX.
  *      The count on the returned rdataset however can't be as
- *	that indicates that the database does not implement cyclic
- *	processing.
+ *      that indicates that the database does not implement cyclic
+ *      processing.
  */
 static unsigned int init_count;
 
@@ -518,12 +647,12 @@ static unsigned int init_count;
  * If a routine is going to lock more than one lock in this module, then
  * the locking must be done in the following order:
  *
- *	Tree Lock
+ *      Tree Lock
  *
- *	Node Lock	(Only one from the set may be locked at one time by
- *			 any caller)
+ *      Node Lock       (Only one from the set may be locked at one time by
+ *                       any caller)
  *
- *	Database Lock
+ *      Database Lock
  *
  * Failure to follow this hierarchy can result in deadlock.
  */
@@ -531,11 +660,7 @@ static unsigned int init_count;
 /*
  * Deleting Nodes
  *
- * Currently there is no deletion of nodes from the database, except when
- * the database is being destroyed.
- *
- * If node deletion is added in the future, then for zone databases the node
- * for the origin of the zone MUST NOT be deleted.
+ * For zone databases the node for the origin of the zone MUST NOT be deleted.
  */
 
 
@@ -563,6 +688,96 @@ free_rbtdb_callback(isc_task_t *task, isc_event_t *event) {
 	free_rbtdb(rbtdb, ISC_TRUE, event);
 }
 
+static void
+update_rrsetstats(dns_rbtdb_t *rbtdb, rdatasetheader_t *header,
+		  isc_boolean_t increment)
+{
+	dns_rdatastatstype_t statattributes = 0;
+	dns_rdatastatstype_t base = 0;
+	dns_rdatastatstype_t type;
+
+	/* At the moment we count statistics only for cache DB */
+	INSIST(IS_CACHE(rbtdb));
+
+	if (NXDOMAIN(header))
+		statattributes = DNS_RDATASTATSTYPE_ATTR_NXDOMAIN;
+	else if (RBTDB_RDATATYPE_BASE(header->type) == 0) {
+		statattributes = DNS_RDATASTATSTYPE_ATTR_NXRRSET;
+		base = RBTDB_RDATATYPE_EXT(header->type);
+	} else
+		base = RBTDB_RDATATYPE_BASE(header->type);
+
+	type = DNS_RDATASTATSTYPE_VALUE(base, statattributes);
+	if (increment)
+		dns_rdatasetstats_increment(rbtdb->rrsetstats, type);
+	else
+		dns_rdatasetstats_decrement(rbtdb->rrsetstats, type);
+}
+
+static void
+set_ttl(dns_rbtdb_t *rbtdb, rdatasetheader_t *header, dns_ttl_t newttl) {
+	int idx;
+	isc_heap_t *heap;
+	dns_ttl_t oldttl;
+
+	oldttl = header->rdh_ttl;
+	header->rdh_ttl = newttl;
+
+	if (!IS_CACHE(rbtdb))
+		return;
+
+	/*
+	 * It's possible the rbtdb is not a cache.  If this is the case,
+	 * we will not have a heap, and we move on.  If we do, though,
+	 * we might need to adjust things.
+	 */
+	if (header->heap_index == 0 || newttl == oldttl)
+		return;
+	idx = header->node->locknum;
+	if (rbtdb->heaps == NULL || rbtdb->heaps[idx] == NULL)
+	    return;
+	heap = rbtdb->heaps[idx];
+
+	if (newttl < oldttl)
+		isc_heap_increased(heap, header->heap_index);
+	else
+		isc_heap_decreased(heap, header->heap_index);
+}
+
+/*%
+ * These functions allow the heap code to rank the priority of each
+ * element.  It returns ISC_TRUE if v1 happens "sooner" than v2.
+ */
+static isc_boolean_t
+ttl_sooner(void *v1, void *v2) {
+	rdatasetheader_t *h1 = v1;
+	rdatasetheader_t *h2 = v2;
+
+	if (h1->rdh_ttl < h2->rdh_ttl)
+		return (ISC_TRUE);
+	return (ISC_FALSE);
+}
+
+static isc_boolean_t
+resign_sooner(void *v1, void *v2) {
+	rdatasetheader_t *h1 = v1;
+	rdatasetheader_t *h2 = v2;
+
+	if (h1->resign < h2->resign)
+		return (ISC_TRUE);
+	return (ISC_FALSE);
+}
+
+/*%
+ * This function sets the heap index into the header.
+ */
+static void
+set_index(void *what, unsigned int index) {
+	rdatasetheader_t *h = what;
+
+	h->heap_index = index;
+}
+
 /*%
  * Work out how many nodes can be deleted in the time between two
  * requests to the nameserver.  Smooth the resulting number and use it
@@ -571,7 +786,7 @@ free_rbtdb_callback(isc_task_t *task, isc_event_t *event) {
  */
 static unsigned int
 adjust_quantum(unsigned int old, isc_time_t *start) {
-	unsigned int pps = dns_pps;	/* packets per second */
+	unsigned int pps = dns_pps;     /* packets per second */
 	unsigned int interval;
 	isc_uint64_t usecs;
 	isc_time_t end;
@@ -581,7 +796,7 @@ adjust_quantum(unsigned int old, isc_time_t *start) {
 		pps = 100;
 	isc_time_now(&end);
 
-	interval = 1000000 / pps;	/* interval in usec */
+	interval = 1000000 / pps;       /* interval in usec */
 	if (interval == 0)
 		interval = 1;
 	usecs = isc_time_microdiff(&end, start);
@@ -619,6 +834,9 @@ free_rbtdb(dns_rbtdb_t *rbtdb, isc_boolean_t log, isc_event_t *event) {
 	char buf[DNS_NAME_FORMATSIZE];
 	isc_time_t start;
 
+	if (IS_CACHE(rbtdb) && rbtdb->common.rdclass == dns_rdataclass_in)
+		overmem((dns_db_t *)rbtdb, (isc_boolean_t)-1);
+
 	REQUIRE(rbtdb->current_version != NULL || EMPTY(rbtdb->open_versions));
 	REQUIRE(rbtdb->future_version == NULL);
 
@@ -633,6 +851,21 @@ free_rbtdb(dns_rbtdb_t *rbtdb, isc_boolean_t log, isc_event_t *event) {
 		isc_mem_put(rbtdb->common.mctx, rbtdb->current_version,
 			    sizeof(rbtdb_version_t));
 	}
+
+	/*
+	 * We assume the number of remaining dead nodes is reasonably small;
+	 * the overhead of unlinking all nodes here should be negligible.
+	 */
+	for (i = 0; i < rbtdb->node_lock_count; i++) {
+		dns_rbtnode_t *node;
+
+		node = ISC_LIST_HEAD(rbtdb->deadnodes[i]);
+		while (node != NULL) {
+			ISC_LIST_UNLINK(rbtdb->deadnodes[i], node, deadlink);
+			node = ISC_LIST_HEAD(rbtdb->deadnodes[i]);
+		}
+	}
+
 	if (event == NULL)
 		rbtdb->quantum = (rbtdb->task != NULL) ? 100 : 0;
  again:
@@ -658,6 +891,30 @@ free_rbtdb(dns_rbtdb_t *rbtdb, isc_boolean_t log, isc_event_t *event) {
 		}
 		INSIST(result == ISC_R_SUCCESS && rbtdb->tree == NULL);
 	}
+
+	if (rbtdb->nsec3 != NULL) {
+		isc_time_now(&start);
+		result = dns_rbt_destroy2(&rbtdb->nsec3, rbtdb->quantum);
+		if (result == ISC_R_QUOTA) {
+			INSIST(rbtdb->task != NULL);
+			if (rbtdb->quantum != 0)
+				rbtdb->quantum = adjust_quantum(rbtdb->quantum,
+								&start);
+			if (event == NULL)
+				event = isc_event_allocate(rbtdb->common.mctx,
+							   NULL,
+							 DNS_EVENT_FREESTORAGE,
+							   free_rbtdb_callback,
+							   rbtdb,
+							   sizeof(isc_event_t));
+			if (event == NULL)
+				goto again;
+			isc_task_send(rbtdb->task, &event);
+			return;
+		}
+		INSIST(result == ISC_R_SUCCESS && rbtdb->nsec3 == NULL);
+	}
+
 	if (event != NULL)
 		isc_event_free(&event);
 	if (log) {
@@ -676,12 +933,47 @@ free_rbtdb(dns_rbtdb_t *rbtdb, isc_boolean_t log, isc_event_t *event) {
 		isc_refcount_destroy(&rbtdb->node_locks[i].references);
 		NODE_DESTROYLOCK(&rbtdb->node_locks[i].lock);
 	}
+
+	/*
+	 * Clean up LRU / re-signing order lists.
+	 */
+	if (rbtdb->rdatasets != NULL) {
+		for (i = 0; i < rbtdb->node_lock_count; i++)
+			INSIST(ISC_LIST_EMPTY(rbtdb->rdatasets[i]));
+		isc_mem_put(rbtdb->common.mctx, rbtdb->rdatasets,
+			    rbtdb->node_lock_count *
+			    sizeof(rdatasetheaderlist_t));
+	}
+	/*
+	 * Clean up dead node buckets.
+	 */
+	if (rbtdb->deadnodes != NULL) {
+		for (i = 0; i < rbtdb->node_lock_count; i++)
+			INSIST(ISC_LIST_EMPTY(rbtdb->deadnodes[i]));
+		isc_mem_put(rbtdb->common.mctx, rbtdb->deadnodes,
+		    rbtdb->node_lock_count * sizeof(rbtnodelist_t));
+	}
+	/*
+	 * Clean up heap objects.
+	 */
+	if (rbtdb->heaps != NULL) {
+		for (i = 0; i < rbtdb->node_lock_count; i++)
+			isc_heap_destroy(&rbtdb->heaps[i]);
+		isc_mem_put(rbtdb->common.mctx, rbtdb->heaps,
+			    rbtdb->node_lock_count *
+			    sizeof(isc_heap_t *));
+	}
+
+	if (rbtdb->rrsetstats != NULL)
+		dns_stats_detach(&rbtdb->rrsetstats);
+
 	isc_mem_put(rbtdb->common.mctx, rbtdb->node_locks,
 		    rbtdb->node_lock_count * sizeof(rbtdb_nodelock_t));
 	isc_rwlock_destroy(&rbtdb->tree_lock);
 	isc_refcount_destroy(&rbtdb->references);
 	if (rbtdb->task != NULL)
 		isc_task_detach(&rbtdb->task);
+
 	RBTDB_DESTROYLOCK(&rbtdb->lock);
 	rbtdb->common.magic = 0;
 	rbtdb->common.impmagic = 0;
@@ -788,6 +1080,7 @@ allocate_version(isc_mem_t *mctx, rbtdb_serial_t serial,
 	version->writer = writer;
 	version->commit_ok = ISC_FALSE;
 	ISC_LIST_INIT(version->changed_list);
+	ISC_LIST_INIT(version->resigned_list);
 	ISC_LINK_INIT(version, link);
 
 	return (version);
@@ -803,11 +1096,29 @@ newversion(dns_db_t *db, dns_dbversion_t **versionp) {
 	REQUIRE(rbtdb->future_version == NULL);
 
 	RBTDB_LOCK(&rbtdb->lock, isc_rwlocktype_write);
-	RUNTIME_CHECK(rbtdb->next_serial != 0);		/* XXX Error? */
+	RUNTIME_CHECK(rbtdb->next_serial != 0);         /* XXX Error? */
 	version = allocate_version(rbtdb->common.mctx, rbtdb->next_serial, 1,
 				   ISC_TRUE);
 	if (version != NULL) {
 		version->commit_ok = ISC_TRUE;
+		version->secure = rbtdb->current_version->secure;
+		version->havensec3 = rbtdb->current_version->havensec3;
+		if (version->havensec3) {
+			version->flags = rbtdb->current_version->flags;
+			version->iterations =
+				rbtdb->current_version->iterations;
+			version->hash = rbtdb->current_version->hash;
+			version->salt_length =
+				rbtdb->current_version->salt_length;
+			memcpy(version->salt, rbtdb->current_version->salt,
+			       version->salt_length);
+		} else {
+			version->flags = 0;
+			version->iterations = 0;
+			version->hash = 0;
+			version->salt_length = 0;
+			memset(version->salt, 0, sizeof(version->salt));
+		}
 		rbtdb->next_serial++;
 		rbtdb->future_version = version;
 	}
@@ -875,7 +1186,7 @@ free_acachearray(isc_mem_t *mctx, rdatasetheader_t *header,
 {
 	unsigned int count;
 	unsigned int i;
-	unsigned char *raw;	/* RDATASLAB */
+	unsigned char *raw;     /* RDATASLAB */
 
 	/*
 	 * The caller must be holding the corresponding node lock.
@@ -903,22 +1214,69 @@ free_noqname(isc_mem_t *mctx, struct noqname **noqname) {
 
 	if (dns_name_dynamic(&(*noqname)->name))
 		dns_name_free(&(*noqname)->name, mctx);
-	if ((*noqname)->nsec != NULL)
-		isc_mem_put(mctx, (*noqname)->nsec,
-			    dns_rdataslab_size((*noqname)->nsec, 0));
-	if ((*noqname)->nsecsig != NULL)
-		isc_mem_put(mctx, (*noqname)->nsecsig,
-			    dns_rdataslab_size((*noqname)->nsecsig, 0));
+	if ((*noqname)->neg != NULL)
+		isc_mem_put(mctx, (*noqname)->neg,
+			    dns_rdataslab_size((*noqname)->neg, 0));
+	if ((*noqname)->negsig != NULL)
+		isc_mem_put(mctx, (*noqname)->negsig,
+			    dns_rdataslab_size((*noqname)->negsig, 0));
 	isc_mem_put(mctx, *noqname, sizeof(**noqname));
 	*noqname = NULL;
 }
 
 static inline void
-free_rdataset(isc_mem_t *mctx, rdatasetheader_t *rdataset) {
+init_rdataset(dns_rbtdb_t *rbtdb, rdatasetheader_t *h)
+{
+	ISC_LINK_INIT(h, lru_link);
+	h->heap_index = 0;
+
+#if TRACE_HEADER
+	if (IS_CACHE(rbtdb) && rbtdb->common.rdclass == dns_rdataclass_in)
+		fprintf(stderr, "initialized header: %p\n", h);
+#else
+	UNUSED(rbtdb);
+#endif
+}
+
+static inline rdatasetheader_t *
+new_rdataset(dns_rbtdb_t *rbtdb, isc_mem_t *mctx)
+{
+	rdatasetheader_t *h;
+
+	h = isc_mem_get(mctx, sizeof(*h));
+	if (h == NULL)
+		return (NULL);
+
+#if TRACE_HEADER
+	if (IS_CACHE(rbtdb) && rbtdb->common.rdclass == dns_rdataclass_in)
+		fprintf(stderr, "allocated header: %p\n", h);
+#endif
+	init_rdataset(rbtdb, h);
+	return (h);
+}
+
+static inline void
+free_rdataset(dns_rbtdb_t *rbtdb, isc_mem_t *mctx, rdatasetheader_t *rdataset)
+{
 	unsigned int size;
+	int idx;
+
+	if (EXISTS(rdataset) &&
+	    (rdataset->attributes & RDATASET_ATTR_STATCOUNT) != 0) {
+		update_rrsetstats(rbtdb, rdataset, ISC_FALSE);
+	}
+
+	idx = rdataset->node->locknum;
+	if (ISC_LINK_LINKED(rdataset, lru_link))
+		ISC_LIST_UNLINK(rbtdb->rdatasets[idx], rdataset, lru_link);
+	if (rdataset->heap_index != 0)
+		isc_heap_delete(rbtdb->heaps[idx], rdataset->heap_index);
+	rdataset->heap_index = 0;
 
 	if (rdataset->noqname != NULL)
 		free_noqname(mctx, &rdataset->noqname);
+	if (rdataset->closest != NULL)
+		free_noqname(mctx, &rdataset->closest);
 
 	free_acachearray(mctx, rdataset, rdataset->additional_auth);
 	free_acachearray(mctx, rdataset, rdataset->additional_glue);
@@ -964,12 +1322,13 @@ rollback_node(dns_rbtnode_t *node, rbtdb_serial_t serial) {
 }
 
 static inline void
-clean_stale_headers(isc_mem_t *mctx, rdatasetheader_t *top) {
+clean_stale_headers(dns_rbtdb_t *rbtdb, isc_mem_t *mctx, rdatasetheader_t *top)
+{
 	rdatasetheader_t *d, *down_next;
 
 	for (d = top->down; d != NULL; d = down_next) {
 		down_next = d->down;
-		free_rdataset(mctx, d);
+		free_rdataset(rbtdb, mctx, d);
 	}
 	top->down = NULL;
 }
@@ -986,7 +1345,7 @@ clean_cache_node(dns_rbtdb_t *rbtdb, dns_rbtnode_t *node) {
 	top_prev = NULL;
 	for (current = node->data; current != NULL; current = top_next) {
 		top_next = current->next;
-		clean_stale_headers(mctx, current);
+		clean_stale_headers(rbtdb, mctx, current);
 		/*
 		 * If current is nonexistent or stale, we can clean it up.
 		 */
@@ -996,7 +1355,7 @@ clean_cache_node(dns_rbtdb_t *rbtdb, dns_rbtnode_t *node) {
 				top_prev->next = current->next;
 			else
 				node->data = current->next;
-			free_rdataset(mctx, current);
+			free_rdataset(rbtdb, mctx, current);
 		} else
 			top_prev = current;
 	}
@@ -1037,7 +1396,7 @@ clean_zone_node(dns_rbtdb_t *rbtdb, dns_rbtnode_t *node,
 				if (down_next != NULL)
 					down_next->next = dparent;
 				dparent->down = down_next;
-				free_rdataset(mctx, dcurrent);
+				free_rdataset(rbtdb, mctx, dcurrent);
 			} else
 				dparent = dcurrent;
 		}
@@ -1053,7 +1412,7 @@ clean_zone_node(dns_rbtdb_t *rbtdb, dns_rbtnode_t *node,
 					top_prev->next = current->next;
 				else
 					node->data = current->next;
-				free_rdataset(mctx, current);
+				free_rdataset(rbtdb, mctx, current);
 				/*
 				 * current no longer exists, so we can
 				 * just continue with the loop.
@@ -1069,7 +1428,7 @@ clean_zone_node(dns_rbtdb_t *rbtdb, dns_rbtnode_t *node,
 				else
 					node->data = down_next;
 				down_next->next = top_next;
-				free_rdataset(mctx, current);
+				free_rdataset(rbtdb, mctx, current);
 				current = down_next;
 			}
 		}
@@ -1096,7 +1455,7 @@ clean_zone_node(dns_rbtdb_t *rbtdb, dns_rbtnode_t *node,
 			do {
 				down_next = dcurrent->down;
 				INSIST(dcurrent->serial <= least_serial);
-				free_rdataset(mctx, dcurrent);
+				free_rdataset(rbtdb, mctx, dcurrent);
 				dcurrent = down_next;
 			} while (dcurrent != NULL);
 			dparent->down = NULL;
@@ -1120,7 +1479,7 @@ clean_zone_node(dns_rbtdb_t *rbtdb, dns_rbtnode_t *node,
 					top_prev->next = current->next;
 				else
 					node->data = current->next;
-				free_rdataset(mctx, current);
+				free_rdataset(rbtdb, mctx, current);
 			} else
 				top_prev = current;
 		}
@@ -1129,6 +1488,49 @@ clean_zone_node(dns_rbtdb_t *rbtdb, dns_rbtnode_t *node,
 		node->dirty = 0;
 }
 
+/*%
+ * Clean up dead nodes.  These are nodes which have no references, and
+ * have no data.  They are dead but we could not or chose not to delete
+ * them when we deleted all the data at that node because we did not want
+ * to wait for the tree write lock.
+ *
+ * The caller must hold a tree write lock and bucketnum'th node (write) lock.
+ */
+static void
+cleanup_dead_nodes(dns_rbtdb_t *rbtdb, int bucketnum) {
+	dns_rbtnode_t *node;
+	isc_result_t result;
+	int count = 10;         /* XXXJT: should be adjustable */
+
+	node = ISC_LIST_HEAD(rbtdb->deadnodes[bucketnum]);
+	while (node != NULL && count > 0) {
+		ISC_LIST_UNLINK(rbtdb->deadnodes[bucketnum], node, deadlink);
+
+		/*
+		 * Since we're holding a tree write lock, it should be
+		 * impossible for this node to be referenced by others.
+		 */
+		INSIST(dns_rbtnode_refcurrent(node) == 0 &&
+		       node->data == NULL);
+
+		INSIST(!ISC_LINK_LINKED(node, deadlink));
+		if (node->nsec3)
+			result = dns_rbt_deletenode(rbtdb->nsec3, node,
+						    ISC_FALSE);
+		else
+			result = dns_rbt_deletenode(rbtdb->tree, node,
+						    ISC_FALSE);
+		if (result != ISC_R_SUCCESS)
+			isc_log_write(dns_lctx, DNS_LOGCATEGORY_DATABASE,
+				      DNS_LOGMODULE_CACHE, ISC_LOG_WARNING,
+				      "cleanup_dead_nodes: "
+				      "dns_rbt_deletenode: %s",
+				      isc_result_totext(result));
+		node = ISC_LIST_HEAD(rbtdb->deadnodes[bucketnum]);
+		count--;
+	}
+}
+
 /*
  * Caller must be holding the node lock if its reference must be protected
  * by the lock.
@@ -1139,7 +1541,7 @@ new_reference(dns_rbtdb_t *rbtdb, dns_rbtnode_t *node) {
 	isc_refcount_t *lockref;
 
 	dns_rbtnode_refincrement0(node, &noderefs);
-	if (noderefs == 1) {	/* this is the first reference to the node */
+	if (noderefs == 1) {    /* this is the first reference to the node */
 		lockref = &rbtdb->node_locks[node->locknum].references;
 		isc_refcount_increment0(lockref, &lockrefs);
 		INSIST(lockrefs != 0);
@@ -1148,6 +1550,49 @@ new_reference(dns_rbtdb_t *rbtdb, dns_rbtnode_t *node) {
 }
 
 /*
+ * This function is assumed to be called when a node is newly referenced
+ * and can be in the deadnode list.  In that case the node must be retrieved
+ * from the list because it is going to be used.  In addition, if the caller
+ * happens to hold a write lock on the tree, it's a good chance to purge dead
+ * nodes.
+ * Note: while a new reference is gained in multiple places, there are only very
+ * few cases where the node can be in the deadnode list (only empty nodes can
+ * have been added to the list).
+ */
+static inline void
+reactivate_node(dns_rbtdb_t *rbtdb, dns_rbtnode_t *node,
+		isc_rwlocktype_t treelocktype)
+{
+	isc_boolean_t need_relock = ISC_FALSE;
+
+	NODE_STRONGLOCK(&rbtdb->node_locks[node->locknum].lock);
+	new_reference(rbtdb, node);
+
+	NODE_WEAKLOCK(&rbtdb->node_locks[node->locknum].lock,
+		      isc_rwlocktype_read);
+	if (ISC_LINK_LINKED(node, deadlink))
+		need_relock = ISC_TRUE;
+	else if (!ISC_LIST_EMPTY(rbtdb->deadnodes[node->locknum]) &&
+		 treelocktype == isc_rwlocktype_write)
+		need_relock = ISC_TRUE;
+	NODE_WEAKUNLOCK(&rbtdb->node_locks[node->locknum].lock,
+			isc_rwlocktype_read);
+	if (need_relock) {
+		NODE_WEAKLOCK(&rbtdb->node_locks[node->locknum].lock,
+			      isc_rwlocktype_write);
+		if (ISC_LINK_LINKED(node, deadlink))
+			ISC_LIST_UNLINK(rbtdb->deadnodes[node->locknum],
+					node, deadlink);
+		if (treelocktype == isc_rwlocktype_write)
+			cleanup_dead_nodes(rbtdb, node->locknum);
+		NODE_WEAKUNLOCK(&rbtdb->node_locks[node->locknum].lock,
+				isc_rwlocktype_write);
+	}
+
+	NODE_STRONGUNLOCK(&rbtdb->node_locks[node->locknum].lock);
+}
+
+/*
  * Caller must be holding the node lock; either the "strong", read or write
  * lock.  Note that the lock must be held even when node references are
  * atomically modified; in that case the decrement operation itself does not
@@ -1160,14 +1605,17 @@ new_reference(dns_rbtdb_t *rbtdb, dns_rbtnode_t *node) {
 static isc_boolean_t
 decrement_reference(dns_rbtdb_t *rbtdb, dns_rbtnode_t *node,
 		    rbtdb_serial_t least_serial,
-		    isc_rwlocktype_t nlock, isc_rwlocktype_t tlock)
+		    isc_rwlocktype_t nlock, isc_rwlocktype_t tlock,
+		    isc_boolean_t pruning)
 {
 	isc_result_t result;
 	isc_boolean_t write_locked;
 	rbtdb_nodelock_t *nodelock;
 	unsigned int refs, nrefs;
+	int bucket = node->locknum;
+	isc_boolean_t no_reference;
 
-	nodelock = &rbtdb->node_locks[node->locknum];
+	nodelock = &rbtdb->node_locks[bucket];
 
 	/* Handle easy and typical case first. */
 	if (!node->dirty && (node->data != NULL || node->down != NULL)) {
@@ -1226,7 +1674,9 @@ decrement_reference(dns_rbtdb_t *rbtdb, dns_rbtnode_t *node,
 	}
 
 	/*
-	 * XXXDCL need to add a deferred delete method for ISC_R_LOCKBUSY.
+	 * Attempt to switch to a write lock on the tree.  If this fails,
+	 * we will add this node to a linked list of nodes in this locking
+	 * bucket which we will free later.
 	 */
 	if (tlock != isc_rwlocktype_write) {
 		/*
@@ -1246,6 +1696,7 @@ decrement_reference(dns_rbtdb_t *rbtdb, dns_rbtnode_t *node,
 	} else
 		write_locked = ISC_TRUE;
 
+	no_reference = ISC_TRUE;
 	if (write_locked && dns_rbtnode_refcurrent(node) == 0) {
 		/*
 		 * We can now delete the node if the reference counter is
@@ -1254,26 +1705,97 @@ decrement_reference(dns_rbtdb_t *rbtdb, dns_rbtnode_t *node,
 		 * current thread locks the tree (e.g., in findnode()).
 		 */
 
-		if (isc_log_wouldlog(dns_lctx, ISC_LOG_DEBUG(1))) {
-			char printname[DNS_NAME_FORMATSIZE];
+		/*
+		 * If this node is the only one in the level it's in, deleting
+		 * this node may recursively make its parent the only node in
+		 * the parent level; if so, and if no one is currently using
+		 * the parent node, this is almost the only opportunity to
+		 * clean it up.  But the recursive cleanup is not that trivial
+		 * since the child and parent may be in different lock buckets,
+		 * which would cause a lock order reversal problem.  To avoid
+		 * the trouble, we'll dispatch a separate event for batch
+		 * cleaning.  We need to check whether we're deleting the node
+		 * as a result of pruning to avoid infinite dispatching.
+		 * Note: pruning happens only when a task has been set for the
+		 * rbtdb.  If the user of the rbtdb chooses not to set a task,
+		 * it's their responsibility to purge stale leaves (e.g. by
+		 * periodic walk-through).
+		 */
+		if (!pruning && node->parent != NULL &&
+		    node->parent->down == node && node->left == NULL &&
+		    node->right == NULL && rbtdb->task != NULL) {
+			isc_event_t *ev;
+			dns_db_t *db;
+
+			ev = isc_event_allocate(rbtdb->common.mctx, NULL,
+						DNS_EVENT_RBTPRUNE,
+						prune_tree, node,
+						sizeof(isc_event_t));
+			if (ev != NULL) {
+				new_reference(rbtdb, node);
+				db = NULL;
+				attach((dns_db_t *)rbtdb, &db);
+				ev->ev_sender = db;
+				isc_task_send(rbtdb->task, &ev);
+				no_reference = ISC_FALSE;
+			} else {
+				/*
+				 * XXX: this is a weird situation.  We could
+				 * ignore this error case, but then the stale
+				 * node will unlikely be purged except via a
+				 * rare condition such as manual cleanup.  So
+				 * we queue it in the deadnodes list, hoping
+				 * the memory shortage is temporary and the node
+				 * will be deleted later.
+				 */
+				isc_log_write(dns_lctx,
+					      DNS_LOGCATEGORY_DATABASE,
+					      DNS_LOGMODULE_CACHE,
+					      ISC_LOG_INFO,
+					      "decrement_reference: failed to "
+					      "allocate pruning event");
+				INSIST(!ISC_LINK_LINKED(node, deadlink));
+				ISC_LIST_APPEND(rbtdb->deadnodes[bucket], node,
+						deadlink);
+			}
+		} else {
+			if (isc_log_wouldlog(dns_lctx, ISC_LOG_DEBUG(1))) {
+				char printname[DNS_NAME_FORMATSIZE];
+
+				isc_log_write(dns_lctx,
+					      DNS_LOGCATEGORY_DATABASE,
+					      DNS_LOGMODULE_CACHE,
+					      ISC_LOG_DEBUG(1),
+					      "decrement_reference: "
+					      "delete from rbt: %p %s",
+					      node,
+					      dns_rbt_formatnodename(node,
+							printname,
+							sizeof(printname)));
+			}
 
-			isc_log_write(dns_lctx, DNS_LOGCATEGORY_DATABASE,
-				      DNS_LOGMODULE_CACHE, ISC_LOG_DEBUG(1),
-				      "decrement_reference: "
-				      "delete from rbt: %p %s",
-				      node,
-				      dns_rbt_formatnodename(node, printname,
-							   sizeof(printname)));
+			INSIST(!ISC_LINK_LINKED(node, deadlink));
+			if (node->nsec3)
+				result = dns_rbt_deletenode(rbtdb->nsec3, node,
+							    ISC_FALSE);
+			else
+				result = dns_rbt_deletenode(rbtdb->tree, node,
+							    ISC_FALSE);
+			if (result != ISC_R_SUCCESS) {
+				isc_log_write(dns_lctx,
+					      DNS_LOGCATEGORY_DATABASE,
+					      DNS_LOGMODULE_CACHE,
+					      ISC_LOG_WARNING,
+					      "decrement_reference: "
+					      "dns_rbt_deletenode: %s",
+					      isc_result_totext(result));
+			}
 		}
-
-		result = dns_rbt_deletenode(rbtdb->tree, node, ISC_FALSE);
-		if (result != ISC_R_SUCCESS)
-			isc_log_write(dns_lctx, DNS_LOGCATEGORY_DATABASE,
-				      DNS_LOGMODULE_CACHE, ISC_LOG_WARNING,
-				      "decrement_reference: "
-				      "dns_rbt_deletenode: %s",
-				      isc_result_totext(result));
-	}
+	} else if (dns_rbtnode_refcurrent(node) == 0) {
+		INSIST(!ISC_LINK_LINKED(node, deadlink));
+		ISC_LIST_APPEND(rbtdb->deadnodes[bucket], node, deadlink);
+	} else
+		no_reference = ISC_FALSE;
 
 	/* Restore the lock? */
 	if (nlock == isc_rwlocktype_read)
@@ -1290,7 +1812,71 @@ decrement_reference(dns_rbtdb_t *rbtdb, dns_rbtnode_t *node,
 		if (write_locked)
 			isc_rwlock_downgrade(&rbtdb->tree_lock);
 
-	return (ISC_TRUE);
+	return (no_reference);
+}
+
+/*
+ * Prune the tree by recursively cleaning-up single leaves.  In the worst
+ * case, the number of iteration is the number of tree levels, which is at
+ * most the maximum number of domain name labels, i.e, 127.  In practice, this
+ * should be much smaller (only a few times), and even the worst case would be
+ * acceptable for a single event.
+ */
+static void
+prune_tree(isc_task_t *task, isc_event_t *event) {
+	dns_rbtdb_t *rbtdb = event->ev_sender;
+	dns_rbtnode_t *node = event->ev_arg;
+	dns_rbtnode_t *parent;
+	unsigned int locknum;
+
+	UNUSED(task);
+
+	isc_event_free(&event);
+
+	RWLOCK(&rbtdb->tree_lock, isc_rwlocktype_write);
+	locknum = node->locknum;
+	NODE_LOCK(&rbtdb->node_locks[locknum].lock, isc_rwlocktype_write);
+	do {
+		parent = node->parent;
+		decrement_reference(rbtdb, node, 0, isc_rwlocktype_write,
+				    isc_rwlocktype_write, ISC_TRUE);
+
+		if (parent != NULL && parent->down == NULL) {
+			/*
+			 * node was the only down child of the parent and has
+			 * just been removed.  We'll then need to examine the
+			 * parent.  Keep the lock if possible; otherwise,
+			 * release the old lock and acquire one for the parent.
+			 */
+			if (parent->locknum != locknum) {
+				NODE_UNLOCK(&rbtdb->node_locks[locknum].lock,
+					    isc_rwlocktype_write);
+				locknum = parent->locknum;
+				NODE_LOCK(&rbtdb->node_locks[locknum].lock,
+					  isc_rwlocktype_write);
+			}
+
+			/*
+			 * We need to gain a reference to the node before
+			 * decrementing it in the next iteration.  In addition,
+			 * if the node is in the dead-nodes list, extract it
+			 * from the list beforehand as we do in
+			 * reactivate_node().
+			 */
+			new_reference(rbtdb, parent);
+			if (ISC_LINK_LINKED(parent, deadlink)) {
+				ISC_LIST_UNLINK(rbtdb->deadnodes[locknum],
+						parent, deadlink);
+			}
+		} else
+			parent = NULL;
+
+		node = parent;
+	} while (node != NULL);
+	NODE_UNLOCK(&rbtdb->node_locks[locknum].lock, isc_rwlocktype_write);
+	RWUNLOCK(&rbtdb->tree_lock, isc_rwlocktype_write);
+
+	detach((dns_db_t **)&rbtdb);
 }
 
 static inline void
@@ -1337,17 +1923,20 @@ cleanup_nondirty(rbtdb_version_t *version, rbtdb_changedlist_t *cleanup_list) {
 	}
 }
 
-static isc_boolean_t
-iszonesecure(dns_db_t *db, dns_dbnode_t *origin) {
+static void
+iszonesecure(dns_db_t *db, rbtdb_version_t *version, dns_dbnode_t *origin) {
 	dns_rdataset_t keyset;
 	dns_rdataset_t nsecset, signsecset;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
 	isc_boolean_t haszonekey = ISC_FALSE;
 	isc_boolean_t hasnsec = ISC_FALSE;
+	isc_boolean_t hasoptbit = ISC_FALSE;
+	isc_boolean_t nsec3createflag = ISC_FALSE;
 	isc_result_t result;
 
 	dns_rdataset_init(&keyset);
-	result = dns_db_findrdataset(db, origin, NULL, dns_rdatatype_dnskey, 0,
-				     0, &keyset, NULL);
+	result = dns_db_findrdataset(db, origin, version, dns_rdatatype_dnskey,
+				     0, 0, &keyset, NULL);
 	if (result == ISC_R_SUCCESS) {
 		dns_rdata_t keyrdata = DNS_RDATA_INIT;
 		result = dns_rdataset_first(&keyset);
@@ -1361,21 +1950,153 @@ iszonesecure(dns_db_t *db, dns_dbnode_t *origin) {
 		}
 		dns_rdataset_disassociate(&keyset);
 	}
-	if (!haszonekey)
-		return (ISC_FALSE);
+	if (!haszonekey) {
+		version->secure = dns_db_insecure;
+		version->havensec3 = ISC_FALSE;
+		return;
+	}
 
 	dns_rdataset_init(&nsecset);
 	dns_rdataset_init(&signsecset);
-	result = dns_db_findrdataset(db, origin, NULL, dns_rdatatype_nsec, 0,
-				     0, &nsecset, &signsecset);
+	result = dns_db_findrdataset(db, origin, version, dns_rdatatype_nsec,
+				     0, 0, &nsecset, &signsecset);
 	if (result == ISC_R_SUCCESS) {
 		if (dns_rdataset_isassociated(&signsecset)) {
 			hasnsec = ISC_TRUE;
+			result = dns_rdataset_first(&nsecset);
+			if (result == ISC_R_SUCCESS) {
+				dns_rdataset_current(&nsecset, &rdata);
+				hasoptbit = dns_nsec_typepresent(&rdata,
+							     dns_rdatatype_opt);
+			}
 			dns_rdataset_disassociate(&signsecset);
 		}
 		dns_rdataset_disassociate(&nsecset);
 	}
-	return (hasnsec);
+
+	setnsec3parameters(db, version, &nsec3createflag);
+
+	/*
+	 * Do we have a valid NSEC/NSEC3 chain?
+	 */
+	if (version->havensec3 || (hasnsec && !hasoptbit))
+		version->secure = dns_db_secure;
+	/*
+	 * Do we have a NSEC/NSEC3 chain under creation?
+	 */
+	else if (hasoptbit || nsec3createflag)
+		version->secure = dns_db_partial;
+	else
+		version->secure = dns_db_insecure;
+}
+
+/*%<
+ * Walk the origin node looking for NSEC3PARAM records.
+ * Cache the nsec3 parameters.
+ */
+static void
+setnsec3parameters(dns_db_t *db, rbtdb_version_t *version,
+		   isc_boolean_t *nsec3createflag)
+{
+	dns_rbtnode_t *node;
+	dns_rdata_nsec3param_t nsec3param;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	isc_region_t region;
+	isc_result_t result;
+	rdatasetheader_t *header, *header_next;
+	unsigned char *raw;             /* RDATASLAB */
+	unsigned int count, length;
+	dns_rbtdb_t *rbtdb = (dns_rbtdb_t *)db;
+
+	RWLOCK(&rbtdb->tree_lock, isc_rwlocktype_read);
+	version->havensec3 = ISC_FALSE;
+	node = rbtdb->origin_node;
+	NODE_LOCK(&(rbtdb->node_locks[node->locknum].lock),
+		  isc_rwlocktype_read);
+	for (header = node->data;
+	     header != NULL;
+	     header = header_next) {
+		header_next = header->next;
+		do {
+			if (header->serial <= version->serial &&
+			    !IGNORE(header)) {
+				if (NONEXISTENT(header))
+					header = NULL;
+				break;
+			} else
+				header = header->down;
+		} while (header != NULL);
+
+		if (header != NULL &&
+		    header->type == dns_rdatatype_nsec3param) {
+			/*
+			 * Find A NSEC3PARAM with a supported algorithm.
+			 */
+			raw = (unsigned char *)header + sizeof(*header);
+			count = raw[0] * 256 + raw[1]; /* count */
+#if DNS_RDATASET_FIXED
+			raw += count * 4 + 2;
+#else
+			raw += 2;
+#endif
+			while (count-- > 0U) {
+				length = raw[0] * 256 + raw[1];
+#if DNS_RDATASET_FIXED
+				raw += 4;
+#else
+				raw += 2;
+#endif
+				region.base = raw;
+				region.length = length;
+				raw += length;
+				dns_rdata_fromregion(&rdata,
+						     rbtdb->common.rdclass,
+						     dns_rdatatype_nsec3param,
+						     &region);
+				result = dns_rdata_tostruct(&rdata,
+							    &nsec3param,
+							    NULL);
+				INSIST(result == ISC_R_SUCCESS);
+				dns_rdata_reset(&rdata);
+
+				if (nsec3param.hash != DNS_NSEC3_UNKNOWNALG &&
+				    !dns_nsec3_supportedhash(nsec3param.hash))
+					continue;
+
+#ifdef RFC5155_STRICT
+				if (nsec3param.flags != 0)
+					continue;
+#else
+				if ((nsec3param.flags & DNS_NSEC3FLAG_CREATE)
+				    != 0)
+					*nsec3createflag = ISC_TRUE;
+				if ((nsec3param.flags & ~DNS_NSEC3FLAG_OPTOUT)
+				    != 0)
+					continue;
+#endif
+
+				INSIST(nsec3param.salt_length <=
+				       sizeof(version->salt));
+				memcpy(version->salt, nsec3param.salt,
+				       nsec3param.salt_length);
+				version->hash = nsec3param.hash;
+				version->salt_length = nsec3param.salt_length;
+				version->iterations = nsec3param.iterations;
+				version->flags = nsec3param.flags;
+				version->havensec3 = ISC_TRUE;
+				/*
+				 * Look for a better algorithm than the
+				 * unknown test algorithm.
+				 */
+				if (nsec3param.hash != DNS_NSEC3_UNKNOWNALG)
+					goto unlock;
+			}
+		}
+	}
+ unlock:
+	NODE_UNLOCK(&(rbtdb->node_locks[node->locknum].lock),
+		    isc_rwlocktype_read);
+	RWUNLOCK(&rbtdb->tree_lock, isc_rwlocktype_read);
 }
 
 static void
@@ -1384,10 +2105,12 @@ closeversion(dns_db_t *db, dns_dbversion_t **versionp, isc_boolean_t commit) {
 	rbtdb_version_t *version, *cleanup_version, *least_greater;
 	isc_boolean_t rollback = ISC_FALSE;
 	rbtdb_changedlist_t cleanup_list;
+	rdatasetheaderlist_t resigned_list;
 	rbtdb_changed_t *changed, *next_changed;
 	rbtdb_serial_t serial, least_serial;
 	dns_rbtnode_t *rbtnode;
 	unsigned int refs;
+	rdatasetheader_t *header;
 	isc_boolean_t writer;
 
 	REQUIRE(VALID_RBTDB(rbtdb));
@@ -1395,9 +2118,10 @@ closeversion(dns_db_t *db, dns_dbversion_t **versionp, isc_boolean_t commit) {
 
 	cleanup_version = NULL;
 	ISC_LIST_INIT(cleanup_list);
+	ISC_LIST_INIT(resigned_list);
 
 	isc_refcount_decrement(&version->references, &refs);
-	if (refs > 0) {		/* typical and easy case first */
+	if (refs > 0) {         /* typical and easy case first */
 		if (commit) {
 			RBTDB_LOCK(&rbtdb->lock, isc_rwlocktype_read);
 			INSIST(!version->writer);
@@ -1484,12 +2208,16 @@ closeversion(dns_db_t *db, dns_dbversion_t **versionp, isc_boolean_t commit) {
 			INSIST(cur_ref == 1);
 			PREPEND(rbtdb->open_versions,
 				rbtdb->current_version, link);
+			resigned_list = version->resigned_list;
+			ISC_LIST_INIT(version->resigned_list);
 		} else {
 			/*
 			 * We're rolling back this transaction.
 			 */
 			cleanup_list = version->changed_list;
 			ISC_LIST_INIT(version->changed_list);
+			resigned_list = version->resigned_list;
+			ISC_LIST_INIT(version->resigned_list);
 			rollback = ISC_TRUE;
 			cleanup_version = version;
 			rbtdb->future_version = NULL;
@@ -1542,7 +2270,7 @@ closeversion(dns_db_t *db, dns_dbversion_t **versionp, isc_boolean_t commit) {
 	 * Update the zone's secure status.
 	 */
 	if (writer && commit && !IS_CACHE(rbtdb))
-		rbtdb->secure = iszonesecure(db, rbtdb->origin_node);
+		iszonesecure(db, version, rbtdb->origin_node);
 
 	if (cleanup_version != NULL) {
 		INSIST(EMPTY(cleanup_version->changed_list));
@@ -1550,7 +2278,35 @@ closeversion(dns_db_t *db, dns_dbversion_t **versionp, isc_boolean_t commit) {
 			    sizeof(*cleanup_version));
 	}
 
+	/*
+	 * Commit/rollback re-signed headers.
+	 */
+	for (header = HEAD(resigned_list);
+	     header != NULL;
+	     header = HEAD(resigned_list)) {
+		ISC_LIST_UNLINK(resigned_list, header, lru_link);
+		if (rollback) {
+			nodelock_t *lock;
+			lock = &rbtdb->node_locks[header->node->locknum].lock;
+			NODE_LOCK(lock, isc_rwlocktype_write);
+			resign_insert(rbtdb, header->node->locknum, header);
+			NODE_UNLOCK(lock, isc_rwlocktype_write);
+		}
+		decrement_reference(rbtdb, header->node, least_serial,
+				    isc_rwlocktype_write, isc_rwlocktype_none,
+				    ISC_FALSE);
+	}
+
 	if (!EMPTY(cleanup_list)) {
+		/*
+		 * We acquire a tree write lock here in order to make sure
+		 * that stale nodes will be removed in decrement_reference().
+		 * If we didn't have the lock, those nodes could miss the
+		 * chance to be removed until the server stops.  The write lock
+		 * is expensive, but this event should be rare enough to justify
+		 * the cost.
+		 */
+		RWLOCK(&rbtdb->tree_lock, isc_rwlocktype_write);
 		for (changed = HEAD(cleanup_list);
 		     changed != NULL;
 		     changed = next_changed) {
@@ -1561,19 +2317,27 @@ closeversion(dns_db_t *db, dns_dbversion_t **versionp, isc_boolean_t commit) {
 			lock = &rbtdb->node_locks[rbtnode->locknum].lock;
 
 			NODE_LOCK(lock, isc_rwlocktype_write);
+			/*
+			 * This is a good opportunity to purge any dead nodes,
+			 * so use it.
+			 */
+			cleanup_dead_nodes(rbtdb, rbtnode->locknum);
+
 			if (rollback)
 				rollback_node(rbtnode, serial);
 			decrement_reference(rbtdb, rbtnode, least_serial,
 					    isc_rwlocktype_write,
-					    isc_rwlocktype_none);
+					    isc_rwlocktype_write, ISC_FALSE);
+
 			NODE_UNLOCK(lock, isc_rwlocktype_write);
 
 			isc_mem_put(rbtdb->common.mctx, changed,
 				    sizeof(*changed));
 		}
+		RWUNLOCK(&rbtdb->tree_lock, isc_rwlocktype_write);
 	}
 
-  end:
+ end:
 	*versionp = NULL;
 }
 
@@ -1606,6 +2370,7 @@ add_wildcard_magic(dns_rbtdb_t *rbtdb, dns_name_t *name) {
 	result = dns_rbt_addnode(rbtdb->tree, &foundname, &node);
 	if (result != ISC_R_SUCCESS && result != ISC_R_EXISTS)
 		return (result);
+	node->nsec3 = 0;
 	node->find_callback = 1;
 	node->wild = 1;
 	return (ISC_R_SUCCESS);
@@ -1623,7 +2388,7 @@ add_empty_wildcards(dns_rbtdb_t *rbtdb, dns_name_t *name) {
 	l = dns_name_countlabels(&rbtdb->common.origin);
 	i = l + 1;
 	while (i < n) {
-		dns_rbtnode_t *node = NULL;	/* dummy */
+		dns_rbtnode_t *node = NULL;     /* dummy */
 		dns_name_getlabelsequence(name, n - i, i, &foundname);
 		if (dns_name_iswildcard(&foundname)) {
 			result = add_wildcard_magic(rbtdb, &foundname);
@@ -1633,6 +2398,7 @@ add_empty_wildcards(dns_rbtdb_t *rbtdb, dns_name_t *name) {
 						 &node);
 			if (result != ISC_R_SUCCESS && result != ISC_R_EXISTS)
 				return (result);
+			node->nsec3 = 0;
 		}
 		i++;
 	}
@@ -1678,6 +2444,7 @@ findnode(dns_db_t *db, dns_name_t *name, isc_boolean_t create,
 			node->locknum = dns_name_hash(&nodename, ISC_TRUE) %
 				rbtdb->node_lock_count;
 #endif
+			node->nsec3 = 0;
 			add_empty_wildcards(rbtdb, name);
 
 			if (dns_name_iswildcard(name)) {
@@ -1692,6 +2459,60 @@ findnode(dns_db_t *db, dns_name_t *name, isc_boolean_t create,
 			return (result);
 		}
 	}
+	reactivate_node(rbtdb, node, locktype);
+	RWUNLOCK(&rbtdb->tree_lock, locktype);
+
+	*nodep = (dns_dbnode_t *)node;
+
+	return (ISC_R_SUCCESS);
+}
+
+static isc_result_t
+findnsec3node(dns_db_t *db, dns_name_t *name, isc_boolean_t create,
+	      dns_dbnode_t **nodep)
+{
+	dns_rbtdb_t *rbtdb = (dns_rbtdb_t *)db;
+	dns_rbtnode_t *node = NULL;
+	dns_name_t nodename;
+	isc_result_t result;
+	isc_rwlocktype_t locktype = isc_rwlocktype_read;
+
+	REQUIRE(VALID_RBTDB(rbtdb));
+
+	dns_name_init(&nodename, NULL);
+	RWLOCK(&rbtdb->tree_lock, locktype);
+	result = dns_rbt_findnode(rbtdb->nsec3, name, NULL, &node, NULL,
+				  DNS_RBTFIND_EMPTYDATA, NULL, NULL);
+	if (result != ISC_R_SUCCESS) {
+		RWUNLOCK(&rbtdb->tree_lock, locktype);
+		if (!create) {
+			if (result == DNS_R_PARTIALMATCH)
+				result = ISC_R_NOTFOUND;
+			return (result);
+		}
+		/*
+		 * It would be nice to try to upgrade the lock instead of
+		 * unlocking then relocking.
+		 */
+		locktype = isc_rwlocktype_write;
+		RWLOCK(&rbtdb->tree_lock, locktype);
+		node = NULL;
+		result = dns_rbt_addnode(rbtdb->nsec3, name, &node);
+		if (result == ISC_R_SUCCESS) {
+			dns_rbt_namefromnode(node, &nodename);
+#ifdef DNS_RBT_USEHASH
+			node->locknum = node->hashval % rbtdb->node_lock_count;
+#else
+			node->locknum = dns_name_hash(&nodename, ISC_TRUE) %
+				rbtdb->node_lock_count;
+#endif
+			node->nsec3 = 1U;
+		} else if (result != ISC_R_EXISTS) {
+			RWUNLOCK(&rbtdb->tree_lock, locktype);
+			return (result);
+		}
+	} else
+		INSIST(node->nsec3);
 	NODE_STRONGLOCK(&rbtdb->node_locks[node->locknum].lock);
 	new_reference(rbtdb, node);
 	NODE_STRONGUNLOCK(&rbtdb->node_locks[node->locknum].lock);
@@ -1846,7 +2667,7 @@ bind_rdataset(dns_rbtdb_t *rbtdb, dns_rbtnode_t *node,
 	      rdatasetheader_t *header, isc_stdtime_t now,
 	      dns_rdataset_t *rdataset)
 {
-	unsigned char *raw;	/* RDATASLAB */
+	unsigned char *raw;     /* RDATASLAB */
 
 	/*
 	 * Caller must be holding the node reader lock.
@@ -1861,16 +2682,18 @@ bind_rdataset(dns_rbtdb_t *rbtdb, dns_rbtnode_t *node,
 
 	new_reference(rbtdb, node);
 
-	INSIST(rdataset->methods == NULL);	/* We must be disassociated. */
+	INSIST(rdataset->methods == NULL);      /* We must be disassociated. */
 
 	rdataset->methods = &rdataset_methods;
 	rdataset->rdclass = rbtdb->common.rdclass;
 	rdataset->type = RBTDB_RDATATYPE_BASE(header->type);
 	rdataset->covers = RBTDB_RDATATYPE_EXT(header->type);
-	rdataset->ttl = header->ttl - now;
+	rdataset->ttl = header->rdh_ttl - now;
 	rdataset->trust = header->trust;
 	if (NXDOMAIN(header))
 		rdataset->attributes |= DNS_RDATASETATTR_NXDOMAIN;
+	if (OPTOUT(header))
+		rdataset->attributes |= DNS_RDATASETATTR_OPTOUT;
 	rdataset->private1 = rbtdb;
 	rdataset->private2 = node;
 	raw = (unsigned char *)header + sizeof(*header);
@@ -1891,6 +2714,18 @@ bind_rdataset(dns_rbtdb_t *rbtdb, dns_rbtnode_t *node,
 	rdataset->private6 = header->noqname;
 	if (rdataset->private6 != NULL)
 		rdataset->attributes |=  DNS_RDATASETATTR_NOQNAME;
+	rdataset->private7 = header->closest;
+	if (rdataset->private7 != NULL)
+		rdataset->attributes |=  DNS_RDATASETATTR_CLOSEST;
+
+	/*
+	 * Copy out re-signing information.
+	 */
+	if (RESIGN(header)) {
+		rdataset->attributes |=  DNS_RDATASETATTR_RESIGN;
+		rdataset->resign = header->resign;
+	} else
+		rdataset->resign = 0;
 }
 
 static inline isc_result_t
@@ -1954,7 +2789,7 @@ static inline isc_boolean_t
 valid_glue(rbtdb_search_t *search, dns_name_t *name, rbtdb_rdatatype_t type,
 	   dns_rbtnode_t *node)
 {
-	unsigned char *raw;	/* RDATASLAB */
+	unsigned char *raw;     /* RDATASLAB */
 	unsigned int count, size;
 	dns_name_t ns_name;
 	isc_boolean_t valid = ISC_FALSE;
@@ -2338,10 +3173,55 @@ find_wildcard(rbtdb_search_t *search, dns_rbtnode_t **nodep,
 	return (result);
 }
 
+static isc_boolean_t
+matchparams(rdatasetheader_t *header, rbtdb_search_t *search)
+{
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	dns_rdata_nsec3_t nsec3;
+	unsigned char *raw;                     /* RDATASLAB */
+	unsigned int rdlen, count;
+	isc_region_t region;
+	isc_result_t result;
+
+	REQUIRE(header->type == dns_rdatatype_nsec3);
+
+	raw = (unsigned char *)header + sizeof(*header);
+	count = raw[0] * 256 + raw[1]; /* count */
+#if DNS_RDATASET_FIXED
+	raw += count * 4 + 2;
+#else
+	raw += 2;
+#endif
+	while (count-- > 0) {
+		rdlen = raw[0] * 256 + raw[1];
+#if DNS_RDATASET_FIXED
+		raw += 4;
+#else
+		raw += 2;
+#endif
+		region.base = raw;
+		region.length = rdlen;
+		dns_rdata_fromregion(&rdata, search->rbtdb->common.rdclass,
+				     dns_rdatatype_nsec3, &region);
+		raw += rdlen;
+		result = dns_rdata_tostruct(&rdata, &nsec3, NULL);
+		INSIST(result == ISC_R_SUCCESS);
+		if (nsec3.hash == search->rbtversion->hash &&
+		    nsec3.iterations == search->rbtversion->iterations &&
+		    nsec3.salt_length == search->rbtversion->salt_length &&
+		    memcmp(nsec3.salt, search->rbtversion->salt,
+			   nsec3.salt_length) == 0)
+			return (ISC_TRUE);
+		dns_rdata_reset(&rdata);
+	}
+	return (ISC_FALSE);
+}
+
 static inline isc_result_t
 find_closest_nsec(rbtdb_search_t *search, dns_dbnode_t **nodep,
 		  dns_name_t *foundname, dns_rdataset_t *rdataset,
-		  dns_rdataset_t *sigrdataset, isc_boolean_t need_sig)
+		  dns_rdataset_t *sigrdataset, dns_rbt_t *tree,
+		  dns_db_secure_t secure)
 {
 	dns_rbtnode_t *node;
 	rdatasetheader_t *header, *header_next, *found, *foundsig;
@@ -2349,7 +3229,22 @@ find_closest_nsec(rbtdb_search_t *search, dns_dbnode_t **nodep,
 	isc_result_t result;
 	dns_fixedname_t fname, forigin;
 	dns_name_t *name, *origin;
+	dns_rdatatype_t type;
+	rbtdb_rdatatype_t sigtype;
+	isc_boolean_t wraps;
+	isc_boolean_t need_sig = ISC_TF(secure == dns_db_secure);
 
+	if (tree == search->rbtdb->nsec3) {
+		type = dns_rdatatype_nsec3;
+		sigtype = RBTDB_RDATATYPE_SIGNSEC3;
+		wraps = ISC_TRUE;
+	} else {
+		type = dns_rdatatype_nsec;
+		sigtype = RBTDB_RDATATYPE_SIGNSEC;
+		wraps = ISC_FALSE;
+	}
+
+ again:
 	do {
 		node = NULL;
 		dns_fixedname_init(&fname);
@@ -2391,12 +3286,11 @@ find_closest_nsec(rbtdb_search_t *search, dns_dbnode_t **nodep,
 				 * active rdataset at this node.
 				 */
 				empty_node = ISC_FALSE;
-				if (header->type == dns_rdatatype_nsec) {
+				if (header->type == type) {
 					found = header;
 					if (foundsig != NULL)
 						break;
-				} else if (header->type ==
-					   RBTDB_RDATATYPE_SIGNSEC) {
+				} else if (header->type == sigtype) {
 					foundsig = header;
 					if (found != NULL)
 						break;
@@ -2404,11 +3298,19 @@ find_closest_nsec(rbtdb_search_t *search, dns_dbnode_t **nodep,
 			}
 		}
 		if (!empty_node) {
-			if (found != NULL &&
-			    (foundsig != NULL || !need_sig))
+			if (found != NULL && search->rbtversion->havensec3 &&
+			    found->type == dns_rdatatype_nsec3 &&
+			    !matchparams(found, search)) {
+				empty_node = ISC_TRUE;
+				found = NULL;
+				foundsig = NULL;
+				result = dns_rbtnodechain_prev(&search->chain,
+							       NULL, NULL);
+			} else if (found != NULL &&
+				   (foundsig != NULL || !need_sig))
 			{
 				/*
-				 * We've found the right NSEC record.
+				 * We've found the right NSEC/NSEC3 record.
 				 *
 				 * Note: for this to really be the right
 				 * NSEC record, it's essential that the NSEC
@@ -2465,6 +3367,15 @@ find_closest_nsec(rbtdb_search_t *search, dns_dbnode_t **nodep,
 			    isc_rwlocktype_read);
 	} while (empty_node && result == ISC_R_SUCCESS);
 
+	if (result == ISC_R_NOMORE && wraps) {
+		result = dns_rbtnodechain_last(&search->chain, tree,
+					       NULL, NULL);
+		if (result == ISC_R_SUCCESS || result == DNS_R_NEWORIGIN) {
+			wraps = ISC_FALSE;
+			goto again;
+		}
+	}
+
 	/*
 	 * If the result is ISC_R_NOMORE, then we got to the beginning of
 	 * the database and didn't find a NSEC record.  This shouldn't
@@ -2497,7 +3408,7 @@ zone_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
 	isc_boolean_t active;
 	dns_rbtnodechain_t chain;
 	nodelock_t *lock;
-
+	dns_rbt_t *tree;
 
 	search.rbtdb = (dns_rbtdb_t *)db;
 
@@ -2540,7 +3451,9 @@ zone_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
 	 * encounter a callback node, zone_zonecut_callback() will search the
 	 * rdatasets at the zone cut for active DNAME or NS rdatasets.
 	 */
-	result = dns_rbt_findnode(search.rbtdb->tree, name, foundname, &node,
+	tree =  (options & DNS_DBFIND_FORCENSEC3) != 0 ? search.rbtdb->nsec3 :
+							 search.rbtdb->tree;
+	result = dns_rbt_findnode(tree, name, foundname, &node,
 				  &search.chain, DNS_RBTFIND_EMPTYDATA,
 				  zone_zonecut_callback, &search);
 
@@ -2578,12 +3491,14 @@ zone_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
 		 * If we're here, then the name does not exist, is not
 		 * beneath a zonecut, and there's no matching wildcard.
 		 */
-		if (search.rbtdb->secure ||
-		    (search.options & DNS_DBFIND_FORCENSEC) != 0)
+		if ((search.rbtversion->secure == dns_db_secure &&
+		     !search.rbtversion->havensec3) ||
+		    (search.options & DNS_DBFIND_FORCENSEC) != 0 ||
+		    (search.options & DNS_DBFIND_FORCENSEC3) != 0)
 		{
 			result = find_closest_nsec(&search, nodep, foundname,
-						  rdataset, sigrdataset,
-						  search.rbtdb->secure);
+						   rdataset, sigrdataset, tree,
+						   search.rbtversion->secure);
 			if (result == ISC_R_SUCCESS)
 				result = active ? DNS_R_EMPTYNAME :
 						  DNS_R_NXDOMAIN;
@@ -2704,6 +3619,14 @@ zone_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
 					break;
 			}
 
+
+			/*
+			 * If the NSEC3 record doesn't match the chain
+			 * we are using behave as if it isn't here.
+			 */
+			if (header->type == dns_rdatatype_nsec3 &&
+			    !matchparams(header, &search))
+				goto partial_match;
 			/*
 			 * If we found a type we were looking for,
 			 * remember it.
@@ -2748,14 +3671,16 @@ zone_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
 				 */
 				if (!maybe_zonecut && found != NULL)
 					break;
-			} else if (header->type == dns_rdatatype_nsec) {
+			} else if (header->type == dns_rdatatype_nsec &&
+				   !search.rbtversion->havensec3) {
 				/*
 				 * Remember a NSEC rdataset even if we're
 				 * not specifically looking for it, because
 				 * we might need it later.
 				 */
 				nsecheader = header;
-			} else if (header->type == RBTDB_RDATATYPE_SIGNSEC) {
+			} else if (header->type == RBTDB_RDATATYPE_SIGNSEC &&
+				   !search.rbtversion->havensec3) {
 				/*
 				 * If we need the NSEC rdataset, we'll also
 				 * need its signature.
@@ -2807,7 +3732,8 @@ zone_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
 		 * The desired type doesn't exist.
 		 */
 		result = DNS_R_NXRRSET;
-		if (search.rbtdb->secure &&
+		if (search.rbtversion->secure == dns_db_secure &&
+		    !search.rbtversion->havensec3 &&
 		    (nsecheader == NULL || nsecsig == NULL)) {
 			/*
 			 * The zone is secure but there's no NSEC,
@@ -2822,7 +3748,8 @@ zone_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
 			NODE_UNLOCK(lock, isc_rwlocktype_read);
 			result = find_closest_nsec(&search, nodep, foundname,
 						   rdataset, sigrdataset,
-						   search.rbtdb->secure);
+						   search.rbtdb->tree,
+						   search.rbtversion->secure);
 			if (result == ISC_R_SUCCESS)
 				result = DNS_R_EMPTYWILD;
 			goto tree_exit;
@@ -2841,7 +3768,8 @@ zone_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
 			new_reference(search.rbtdb, node);
 			*nodep = node;
 		}
-		if (search.rbtdb->secure ||
+		if ((search.rbtversion->secure == dns_db_secure &&
+		     !search.rbtversion->havensec3) ||
 		    (search.options & DNS_DBFIND_FORCENSEC) != 0)
 		{
 			bind_rdataset(search.rbtdb, node, nsecheader,
@@ -2882,6 +3810,7 @@ zone_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
 			 * validated updates.
 			 */
 			if (type == dns_rdatatype_nsec ||
+			    type == dns_rdatatype_nsec3 ||
 			    type == dns_rdatatype_key)
 				result = ISC_R_SUCCESS;
 			else if (type == dns_rdatatype_any)
@@ -2948,7 +3877,8 @@ zone_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
 
 		NODE_LOCK(lock, isc_rwlocktype_read);
 		decrement_reference(search.rbtdb, node, 0,
-				    isc_rwlocktype_read, isc_rwlocktype_none);
+				    isc_rwlocktype_read, isc_rwlocktype_none,
+				    ISC_FALSE);
 		NODE_UNLOCK(lock, isc_rwlocktype_read);
 	}
 
@@ -3010,7 +3940,7 @@ cache_zonecut_callback(dns_rbtnode_t *node, dns_name_t *name, void *arg) {
 	header_prev = NULL;
 	for (header = node->data; header != NULL; header = header_next) {
 		header_next = header->next;
-		if (header->ttl <= search->now) {
+		if (header->rdh_ttl <= search->now) {
 			/*
 			 * This rdataset is stale.  If no one else is
 			 * using the node, we can clean it up right
@@ -3018,7 +3948,7 @@ cache_zonecut_callback(dns_rbtnode_t *node, dns_name_t *name, void *arg) {
 			 * the node as dirty, so it will get cleaned
 			 * up later.
 			 */
-			if ((header->ttl <= search->now - RBTDB_VIRTUAL) &&
+			if ((header->rdh_ttl <= search->now - RBTDB_VIRTUAL) &&
 			    (locktype == isc_rwlocktype_write ||
 			     NODE_TRYUPGRADE(lock) == ISC_R_SUCCESS)) {
 				/*
@@ -3044,13 +3974,16 @@ cache_zonecut_callback(dns_rbtnode_t *node, dns_name_t *name, void *arg) {
 					 * stale headers first.
 					 */
 					mctx = search->rbtdb->common.mctx;
-					clean_stale_headers(mctx, header);
+					clean_stale_headers(search->rbtdb,
+							    mctx,
+							    header);
 					if (header_prev != NULL)
 						header_prev->next =
 							header->next;
 					else
 						node->data = header->next;
-					free_rdataset(mctx, header);
+					free_rdataset(search->rbtdb, mctx,
+						      header);
 				} else {
 					header->attributes |=
 						RDATASET_ATTR_STALE;
@@ -3079,6 +4012,7 @@ cache_zonecut_callback(dns_rbtnode_t *node, dns_name_t *name, void *arg) {
 		 * search->zonecut_rdataset will still be valid later.
 		 */
 		new_reference(search->rbtdb, node);
+		INSIST(!ISC_LINK_LINKED(node, deadlink));
 		search->zonecut = node;
 		search->zonecut_rdataset = dname_header;
 		search->zonecut_sigrdataset = sigdname_header;
@@ -3130,7 +4064,7 @@ find_deepest_zonecut(rbtdb_search_t *search, dns_rbtnode_t *node,
 		     header != NULL;
 		     header = header_next) {
 			header_next = header->next;
-			if (header->ttl <= search->now) {
+			if (header->rdh_ttl <= search->now) {
 				/*
 				 * This rdataset is stale.  If no one else is
 				 * using the node, we can clean it up right
@@ -3138,7 +4072,7 @@ find_deepest_zonecut(rbtdb_search_t *search, dns_rbtnode_t *node,
 				 * the node as dirty, so it will get cleaned
 				 * up later.
 				 */
-				if ((header->ttl <= search->now -
+				if ((header->rdh_ttl <= search->now -
 						    RBTDB_VIRTUAL) &&
 				    (locktype == isc_rwlocktype_write ||
 				     NODE_TRYUPGRADE(lock) == ISC_R_SUCCESS)) {
@@ -3153,14 +4087,17 @@ find_deepest_zonecut(rbtdb_search_t *search, dns_rbtnode_t *node,
 						isc_mem_t *m;
 
 						m = search->rbtdb->common.mctx;
-						clean_stale_headers(m, header);
+						clean_stale_headers(
+							search->rbtdb,
+							m, header);
 						if (header_prev != NULL)
 							header_prev->next =
 								header->next;
 						else
 							node->data =
 								header->next;
-						free_rdataset(m, header);
+						free_rdataset(rbtdb, m,
+							      header);
 					} else {
 						header->attributes |=
 							RDATASET_ATTR_STALE;
@@ -3229,6 +4166,23 @@ find_deepest_zonecut(rbtdb_search_t *search, dns_rbtnode_t *node,
 			if (foundsig != NULL)
 				bind_rdataset(search->rbtdb, node, foundsig,
 					      search->now, sigrdataset);
+			if (need_headerupdate(found, search->now) ||
+			    (foundsig != NULL &&
+			     need_headerupdate(foundsig, search->now))) {
+				if (locktype != isc_rwlocktype_write) {
+					NODE_UNLOCK(lock, locktype);
+					NODE_LOCK(lock, isc_rwlocktype_write);
+					locktype = isc_rwlocktype_write;
+				}
+				if (need_headerupdate(found, search->now))
+					update_header(search->rbtdb, found,
+						      search->now);
+				if (foundsig != NULL &&
+				    need_headerupdate(foundsig, search->now)) {
+					update_header(search->rbtdb, foundsig,
+						      search->now);
+				}
+			}
 		}
 
 	node_exit:
@@ -3286,7 +4240,7 @@ find_coveringnsec(rbtdb_search_t *search, dns_dbnode_t **nodep,
 		     header != NULL;
 		     header = header_next) {
 			header_next = header->next;
-			if (header->ttl <= now) {
+			if (header->rdh_ttl <= now) {
 				/*
 				 * This rdataset is stale.  If no one else is
 				 * using the node, we can clean it up right
@@ -3294,7 +4248,7 @@ find_coveringnsec(rbtdb_search_t *search, dns_dbnode_t **nodep,
 				 * node as dirty, so it will get cleaned up
 				 * later.
 				 */
-				if ((header->ttl <= now - RBTDB_VIRTUAL) &&
+				if ((header->rdh_ttl <= now - RBTDB_VIRTUAL) &&
 				    (locktype == isc_rwlocktype_write ||
 				     NODE_TRYUPGRADE(lock) == ISC_R_SUCCESS)) {
 					/*
@@ -3308,13 +4262,16 @@ find_coveringnsec(rbtdb_search_t *search, dns_dbnode_t **nodep,
 						isc_mem_t *m;
 
 						m = search->rbtdb->common.mctx;
-						clean_stale_headers(m, header);
+						clean_stale_headers(
+							search->rbtdb,
+							m, header);
 						if (header_prev != NULL)
 							header_prev->next =
 								header->next;
 						else
 							node->data = header->next;
-						free_rdataset(m, header);
+						free_rdataset(search->rbtdb, m,
+							      header);
 					} else {
 						header->attributes |=
 							RDATASET_ATTR_STALE;
@@ -3377,6 +4334,7 @@ cache_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
 	rdatasetheader_t *header, *header_prev, *header_next;
 	rdatasetheader_t *found, *nsheader;
 	rdatasetheader_t *foundsig, *nssig, *cnamesig;
+	rdatasetheader_t *update, *updatesig;
 	rbtdb_rdatatype_t sigtype, negtype;
 
 	UNUSED(version);
@@ -3399,6 +4357,8 @@ cache_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
 	dns_fixedname_init(&search.zonecut_name);
 	dns_rbtnodechain_init(&search.chain, search.rbtdb->common.mctx);
 	search.now = now;
+	update = NULL;
+	updatesig = NULL;
 
 	RWLOCK(&search.rbtdb->tree_lock, isc_rwlocktype_read);
 
@@ -3462,14 +4422,14 @@ cache_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
 	header_prev = NULL;
 	for (header = node->data; header != NULL; header = header_next) {
 		header_next = header->next;
-		if (header->ttl <= now) {
+		if (header->rdh_ttl <= now) {
 			/*
 			 * This rdataset is stale.  If no one else is using the
 			 * node, we can clean it up right now, otherwise we
 			 * mark it as stale, and the node as dirty, so it will
 			 * get cleaned up later.
 			 */
-			if ((header->ttl <= now - RBTDB_VIRTUAL) &&
+			if ((header->rdh_ttl <= now - RBTDB_VIRTUAL) &&
 			    (locktype == isc_rwlocktype_write ||
 			     NODE_TRYUPGRADE(lock) == ISC_R_SUCCESS)) {
 				/*
@@ -3482,13 +4442,15 @@ cache_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
 					isc_mem_t *mctx;
 
 					mctx = search.rbtdb->common.mctx;
-					clean_stale_headers(mctx, header);
+					clean_stale_headers(search.rbtdb, mctx,
+							    header);
 					if (header_prev != NULL)
 						header_prev->next =
 							header->next;
 					else
 						node->data = header->next;
-					free_rdataset(mctx, header);
+					free_rdataset(search.rbtdb, mctx,
+						      header);
 				} else {
 					header->attributes |=
 						RDATASET_ATTR_STALE;
@@ -3595,13 +4557,19 @@ cache_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
 		if (nsheader != NULL) {
 			if (nodep != NULL) {
 				new_reference(search.rbtdb, node);
+				INSIST(!ISC_LINK_LINKED(node, deadlink));
 				*nodep = node;
 			}
 			bind_rdataset(search.rbtdb, node, nsheader, search.now,
 				      rdataset);
-			if (nssig != NULL)
+			if (need_headerupdate(nsheader, search.now))
+				update = nsheader;
+			if (nssig != NULL) {
 				bind_rdataset(search.rbtdb, node, nssig,
 					      search.now, sigrdataset);
+				if (need_headerupdate(nssig, search.now))
+					updatesig = nssig;
+			}
 			result = DNS_R_DELEGATION;
 			goto node_exit;
 		}
@@ -3619,6 +4587,7 @@ cache_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
 
 	if (nodep != NULL) {
 		new_reference(search.rbtdb, node);
+		INSIST(!ISC_LINK_LINKED(node, deadlink));
 		*nodep = node;
 	}
 
@@ -3650,12 +4619,28 @@ cache_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
 	    result == DNS_R_NCACHENXRRSET) {
 		bind_rdataset(search.rbtdb, node, found, search.now,
 			      rdataset);
-		if (foundsig != NULL)
+		if (need_headerupdate(found, search.now))
+			update = found;
+		if (foundsig != NULL) {
 			bind_rdataset(search.rbtdb, node, foundsig, search.now,
 				      sigrdataset);
+			if (need_headerupdate(foundsig, search.now))
+				updatesig = foundsig;
+		}
 	}
 
  node_exit:
+	if ((update != NULL || updatesig != NULL) &&
+	    locktype != isc_rwlocktype_write) {
+		NODE_UNLOCK(lock, locktype);
+		NODE_LOCK(lock, isc_rwlocktype_write);
+		locktype = isc_rwlocktype_write;
+	}
+	if (update != NULL && need_headerupdate(update, search.now))
+		update_header(search.rbtdb, update, search.now);
+	if (updatesig != NULL && need_headerupdate(updatesig, search.now))
+		update_header(search.rbtdb, updatesig, search.now);
+
 	NODE_UNLOCK(lock, locktype);
 
  tree_exit:
@@ -3671,7 +4656,8 @@ cache_find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
 
 		NODE_LOCK(lock, isc_rwlocktype_read);
 		decrement_reference(search.rbtdb, node, 0,
-				    isc_rwlocktype_read, isc_rwlocktype_none);
+				    isc_rwlocktype_read, isc_rwlocktype_none,
+				    ISC_FALSE);
 		NODE_UNLOCK(lock, isc_rwlocktype_read);
 	}
 
@@ -3745,14 +4731,14 @@ cache_findzonecut(dns_db_t *db, dns_name_t *name, unsigned int options,
 	header_prev = NULL;
 	for (header = node->data; header != NULL; header = header_next) {
 		header_next = header->next;
-		if (header->ttl <= now) {
+		if (header->rdh_ttl <= now) {
 			/*
 			 * This rdataset is stale.  If no one else is using the
 			 * node, we can clean it up right now, otherwise we
 			 * mark it as stale, and the node as dirty, so it will
 			 * get cleaned up later.
 			 */
-			if ((header->ttl <= now - RBTDB_VIRTUAL) &&
+			if ((header->rdh_ttl <= now - RBTDB_VIRTUAL) &&
 			    (locktype == isc_rwlocktype_write ||
 			     NODE_TRYUPGRADE(lock) == ISC_R_SUCCESS)) {
 				/*
@@ -3765,13 +4751,15 @@ cache_findzonecut(dns_db_t *db, dns_name_t *name, unsigned int options,
 					isc_mem_t *mctx;
 
 					mctx = search.rbtdb->common.mctx;
-					clean_stale_headers(mctx, header);
+					clean_stale_headers(search.rbtdb, mctx,
+							    header);
 					if (header_prev != NULL)
 						header_prev->next =
 							header->next;
 					else
 						node->data = header->next;
-					free_rdataset(mctx, header);
+					free_rdataset(search.rbtdb, mctx,
+						      header);
 				} else {
 					header->attributes |=
 						RDATASET_ATTR_STALE;
@@ -3814,6 +4802,7 @@ cache_findzonecut(dns_db_t *db, dns_name_t *name, unsigned int options,
 
 	if (nodep != NULL) {
 		new_reference(search.rbtdb, node);
+		INSIST(!ISC_LINK_LINKED(node, deadlink));
 		*nodep = node;
 	}
 
@@ -3822,6 +4811,21 @@ cache_findzonecut(dns_db_t *db, dns_name_t *name, unsigned int options,
 		bind_rdataset(search.rbtdb, node, foundsig, search.now,
 			      sigrdataset);
 
+	if (need_headerupdate(found, search.now) ||
+	    (foundsig != NULL &&  need_headerupdate(foundsig, search.now))) {
+		if (locktype != isc_rwlocktype_write) {
+			NODE_UNLOCK(lock, locktype);
+			NODE_LOCK(lock, isc_rwlocktype_write);
+			locktype = isc_rwlocktype_write;
+		}
+		if (need_headerupdate(found, search.now))
+			update_header(search.rbtdb, found, search.now);
+		if (foundsig != NULL &&
+		    need_headerupdate(foundsig, search.now)) {
+			update_header(search.rbtdb, foundsig, search.now);
+		}
+	}
+
 	NODE_UNLOCK(lock, locktype);
 
  tree_exit:
@@ -3871,7 +4875,7 @@ detachnode(dns_db_t *db, dns_dbnode_t **targetp) {
 	NODE_LOCK(&nodelock->lock, isc_rwlocktype_read);
 
 	if (decrement_reference(rbtdb, node, 0, isc_rwlocktype_read,
-				isc_rwlocktype_none)) {
+				isc_rwlocktype_none, ISC_FALSE)) {
 		if (isc_refcount_current(&nodelock->references) == 0 &&
 		    nodelock->exiting) {
 			inactive = ISC_TRUE;
@@ -3938,8 +4942,8 @@ expirenode(dns_db_t *db, dns_dbnode_t *node, isc_stdtime_t now) {
 
 		/*
 		 * Note that 'log' can be true IFF rbtdb->overmem is also true.
-		 * rbtdb->ovemem can currently only be true for cache databases
-		 * -- hence all of the "overmem cache" log strings.
+		 * rbtdb->overmem can currently only be true for cache
+		 * databases -- hence all of the "overmem cache" log strings.
 		 */
 		log = ISC_TF(isc_log_wouldlog(dns_lctx, level));
 		if (log)
@@ -3959,7 +4963,7 @@ expirenode(dns_db_t *db, dns_dbnode_t *node, isc_stdtime_t now) {
 		  isc_rwlocktype_write);
 
 	for (header = rbtnode->data; header != NULL; header = header->next)
-		if (header->ttl <= now - RBTDB_VIRTUAL) {
+		if (header->rdh_ttl <= now - RBTDB_VIRTUAL) {
 			/*
 			 * We don't check if refcurrent(rbtnode) == 0 and try
 			 * to free like we do in cache_find(), because
@@ -3974,7 +4978,7 @@ expirenode(dns_db_t *db, dns_dbnode_t *node, isc_stdtime_t now) {
 					      printname);
 		} else if (force_expire) {
 			if (! RETAIN(header)) {
-				header->ttl = 0;
+				set_ttl(rbtdb, header, 0);
 				header->attributes |= RDATASET_ATTR_STALE;
 				rbtnode->dirty = 1;
 			} else if (log) {
@@ -3997,9 +5001,8 @@ static void
 overmem(dns_db_t *db, isc_boolean_t overmem) {
 	dns_rbtdb_t *rbtdb = (dns_rbtdb_t *)db;
 
-	if (IS_CACHE(rbtdb)) {
+	if (IS_CACHE(rbtdb))
 		rbtdb->overmem = overmem;
-	}
 }
 
 static void
@@ -4030,11 +5033,13 @@ printnode(dns_db_t *db, dns_dbnode_t *node, FILE *out) {
 				first = ISC_FALSE;
 				fprintf(out,
 					"\tserial = %lu, ttl = %u, "
-					"trust = %u, attributes = %u\n",
+					"trust = %u, attributes = %u, "
+					"resign = %u\n",
 					(unsigned long)current->serial,
-					current->ttl,
+					current->rdh_ttl,
 					current->trust,
-					current->attributes);
+					current->attributes,
+					current->resign);
 				current = current->down;
 			} while (current != NULL);
 		}
@@ -4046,8 +5051,7 @@ printnode(dns_db_t *db, dns_dbnode_t *node, FILE *out) {
 }
 
 static isc_result_t
-createiterator(dns_db_t *db, isc_boolean_t relative_names,
-	       dns_dbiterator_t **iteratorp)
+createiterator(dns_db_t *db, unsigned int options, dns_dbiterator_t **iteratorp)
 {
 	dns_rbtdb_t *rbtdb = (dns_rbtdb_t *)db;
 	rbtdb_dbiterator_t *rbtdbiter;
@@ -4061,7 +5065,8 @@ createiterator(dns_db_t *db, isc_boolean_t relative_names,
 	rbtdbiter->common.methods = &dbiterator_methods;
 	rbtdbiter->common.db = NULL;
 	dns_db_attach(db, &rbtdbiter->common.db);
-	rbtdbiter->common.relative_names = relative_names;
+	rbtdbiter->common.relative_names =
+			ISC_TF((options & DNS_DB_RELATIVENAMES) != 0);
 	rbtdbiter->common.magic = DNS_DBITERATOR_MAGIC;
 	rbtdbiter->common.cleaning = ISC_FALSE;
 	rbtdbiter->paused = ISC_TRUE;
@@ -4071,8 +5076,15 @@ createiterator(dns_db_t *db, isc_boolean_t relative_names,
 	dns_fixedname_init(&rbtdbiter->origin);
 	rbtdbiter->node = NULL;
 	rbtdbiter->delete = 0;
+	rbtdbiter->nsec3only = ISC_TF((options & DNS_DB_NSEC3ONLY) != 0);
+	rbtdbiter->nonsec3 = ISC_TF((options & DNS_DB_NONSEC3) != 0);
 	memset(rbtdbiter->deletions, 0, sizeof(rbtdbiter->deletions));
 	dns_rbtnodechain_init(&rbtdbiter->chain, db->mctx);
+	dns_rbtnodechain_init(&rbtdbiter->nsec3chain, db->mctx);
+	if (rbtdbiter->nsec3only)
+		rbtdbiter->current = &rbtdbiter->nsec3chain;
+	else
+		rbtdbiter->current = &rbtdbiter->chain;
 
 	*iteratorp = (dns_dbiterator_t *)rbtdbiter;
 
@@ -4204,8 +5216,8 @@ cache_findrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version,
 
 	for (header = rbtnode->data; header != NULL; header = header_next) {
 		header_next = header->next;
-		if (header->ttl <= now) {
-			if ((header->ttl <= now - RBTDB_VIRTUAL) &&
+		if (header->rdh_ttl <= now) {
+			if ((header->rdh_ttl <= now - RBTDB_VIRTUAL) &&
 			    (locktype == isc_rwlocktype_write ||
 			     NODE_TRYUPGRADE(lock) == ISC_R_SUCCESS)) {
 				/*
@@ -4355,19 +5367,15 @@ cname_and_other_data(dns_rbtnode_t *node, rbtdb_serial_t serial) {
 			 * Look for active extant "other data".
 			 *
 			 * "Other data" is any rdataset whose type is not
-			 * KEY, RRSIG KEY, NSEC, RRSIG NSEC or RRSIG CNAME.
+			 * KEY, NSEC, SIG or RRSIG.
 			 */
 			rdtype = RBTDB_RDATATYPE_BASE(header->type);
-			if (rdtype == dns_rdatatype_rrsig ||
-			    rdtype == dns_rdatatype_sig)
-				rdtype = RBTDB_RDATATYPE_EXT(header->type);
-			if (rdtype != dns_rdatatype_nsec &&
-			    rdtype != dns_rdatatype_key &&
-			    rdtype != dns_rdatatype_cname) {
+			if (rdtype != dns_rdatatype_key &&
+			    rdtype != dns_rdatatype_sig &&
+			    rdtype != dns_rdatatype_nsec &&
+			    rdtype != dns_rdatatype_rrsig) {
 				/*
-				 * We've found a type that isn't
-				 * NSEC, KEY, CNAME, or one of their
-				 * signatures.  Is it active and extant?
+				 * Is it active and extant?
 				 */
 				do {
 					if (header->serial <= serial &&
@@ -4395,6 +5403,16 @@ cname_and_other_data(dns_rbtnode_t *node, rbtdb_serial_t serial) {
 }
 
 static isc_result_t
+resign_insert(dns_rbtdb_t *rbtdb, int idx, rdatasetheader_t *newheader) {
+	isc_result_t result;
+
+	INSIST(newheader->heap_index == 0);
+	INSIST(!ISC_LINK_LINKED(newheader, lru_link));
+	result = isc_heap_insert(rbtdb->heaps[idx], newheader);
+	return (result);
+}
+
+static isc_result_t
 add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion,
     rdatasetheader_t *newheader, unsigned int options, isc_boolean_t loading,
     dns_rdataset_t *addedrdataset, isc_stdtime_t now)
@@ -4409,6 +5427,7 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion,
 	dns_rdatatype_t rdtype, covers;
 	rbtdb_rdatatype_t negtype;
 	dns_trust_t trust;
+	int idx;
 
 	/*
 	 * Add an rdatasetheader_t to a node.
@@ -4437,7 +5456,7 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion,
 		 */
 		changed = add_changed(rbtdb, rbtversion, rbtnode);
 		if (changed == NULL) {
-			free_rdataset(rbtdb->common.mctx, newheader);
+			free_rdataset(rbtdb, rbtdb->common.mctx, newheader);
 			return (ISC_R_NOMEMORY);
 		}
 	}
@@ -4466,7 +5485,7 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion,
 				for (topheader = rbtnode->data;
 				     topheader != NULL;
 				     topheader = topheader->next) {
-					topheader->ttl = 0;
+					set_ttl(rbtdb, topheader, 0);
 					topheader->attributes |=
 						RDATASET_ATTR_STALE;
 				}
@@ -4489,7 +5508,7 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion,
 					break;
 			}
 			if (topheader != NULL && EXISTS(topheader) &&
-			    topheader->ttl > now) {
+			    topheader->rdh_ttl > now) {
 				/*
 				 * Found one.
 				 */
@@ -4498,8 +5517,8 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion,
 					 * The NXDOMAIN/NODATA(QTYPE=ANY)
 					 * is more trusted.
 					 */
-
-					free_rdataset(rbtdb->common.mctx,
+					free_rdataset(rbtdb,
+						      rbtdb->common.mctx,
 						      newheader);
 					if (addedrdataset != NULL)
 						bind_rdataset(rbtdb, rbtnode,
@@ -4511,7 +5530,7 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion,
 				 * The new rdataset is better.  Expire the
 				 * NXDOMAIN/NODATA(QTYPE=ANY).
 				 */
-				topheader->ttl = 0;
+				set_ttl(rbtdb, topheader, 0);
 				topheader->attributes |= RDATASET_ATTR_STALE;
 				rbtnode->dirty = 1;
 				topheader = NULL;
@@ -4546,7 +5565,7 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion,
 		 * Deleting an already non-existent rdataset has no effect.
 		 */
 		if (header_nx && newheader_nx) {
-			free_rdataset(rbtdb->common.mctx, newheader);
+			free_rdataset(rbtdb, rbtdb->common.mctx, newheader);
 			return (DNS_R_UNCHANGED);
 		}
 
@@ -4555,8 +5574,8 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion,
 		 * has no effect, provided that the cache data isn't stale.
 		 */
 		if (rbtversion == NULL && trust < header->trust &&
-		    (header->ttl > now || header_nx)) {
-			free_rdataset(rbtdb->common.mctx, newheader);
+		    (header->rdh_ttl > now || header_nx)) {
+			free_rdataset(rbtdb, rbtdb->common.mctx, newheader);
 			if (addedrdataset != NULL)
 				bind_rdataset(rbtdb, rbtnode, header, now,
 					      addedrdataset);
@@ -4582,9 +5601,9 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion,
 			if ((options & DNS_DBADD_EXACT) != 0)
 				flags |= DNS_RDATASLAB_EXACT;
 			if ((options & DNS_DBADD_EXACTTTL) != 0 &&
-			     newheader->ttl != header->ttl)
+			     newheader->rdh_ttl != header->rdh_ttl)
 					result = DNS_R_NOTEXACT;
-			else if (newheader->ttl != header->ttl)
+			else if (newheader->rdh_ttl != header->rdh_ttl)
 				flags |= DNS_RDATASLAB_FORCE;
 			if (result == ISC_R_SUCCESS)
 				result = dns_rdataslab_merge(
@@ -4604,10 +5623,16 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion,
 				 * alone.  It will get cleaned up when
 				 * clean_zone_node() runs.
 				 */
-				free_rdataset(rbtdb->common.mctx, newheader);
+				free_rdataset(rbtdb, rbtdb->common.mctx,
+					      newheader);
 				newheader = (rdatasetheader_t *)merged;
+				if (loading && RESIGN(newheader) &&
+				    RESIGN(header) &&
+				    header->resign < newheader->resign)
+					newheader->resign = header->resign;
 			} else {
-				free_rdataset(rbtdb->common.mctx, newheader);
+				free_rdataset(rbtdb, rbtdb->common.mctx,
+					      newheader);
 				return (result);
 			}
 		}
@@ -4618,7 +5643,7 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion,
 		 * Don't lower trust of existing record if the
 		 * update is forced.
 		 */
-		if (IS_CACHE(rbtdb) && header->ttl > now &&
+		if (IS_CACHE(rbtdb) && header->rdh_ttl > now &&
 		    header->type == dns_rdatatype_ns &&
 		    !header_nx && !newheader_nx &&
 		    header->trust >= newheader->trust &&
@@ -4631,20 +5656,25 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion,
 			 * Honour the new ttl if it is less than the
 			 * older one.
 			 */
-			if (header->ttl > newheader->ttl)
-				header->ttl = newheader->ttl;
+			if (header->rdh_ttl > newheader->rdh_ttl)
+				set_ttl(rbtdb, header, newheader->rdh_ttl);
 			if (header->noqname == NULL &&
 			    newheader->noqname != NULL) {
 				header->noqname = newheader->noqname;
 				newheader->noqname = NULL;
 			}
-			free_rdataset(rbtdb->common.mctx, newheader);
+			if (header->closest == NULL &&
+			    newheader->closest != NULL) {
+				header->closest = newheader->closest;
+				newheader->closest = NULL;
+			}
+			free_rdataset(rbtdb, rbtdb->common.mctx, newheader);
 			if (addedrdataset != NULL)
 				bind_rdataset(rbtdb, rbtnode, header, now,
 					      addedrdataset);
 			return (ISC_R_SUCCESS);
 		}
-		if (IS_CACHE(rbtdb) && header->ttl > now &&
+		if (IS_CACHE(rbtdb) && header->rdh_ttl > now &&
 		    (header->type == dns_rdatatype_a ||
 		     header->type == dns_rdatatype_aaaa) &&
 		    !header_nx && !newheader_nx &&
@@ -4656,14 +5686,19 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion,
 			 * Honour the new ttl if it is less than the
 			 * older one.
 			 */
-			if (header->ttl > newheader->ttl)
-				header->ttl = newheader->ttl;
+			if (header->rdh_ttl > newheader->rdh_ttl)
+				set_ttl(rbtdb, header, newheader->rdh_ttl);
 			if (header->noqname == NULL &&
 			    newheader->noqname != NULL) {
 				header->noqname = newheader->noqname;
 				newheader->noqname = NULL;
 			}
-			free_rdataset(rbtdb->common.mctx, newheader);
+			if (header->closest == NULL &&
+			    newheader->closest != NULL) {
+				header->closest = newheader->closest;
+				newheader->closest = NULL;
+			}
+			free_rdataset(rbtdb, rbtdb->common.mctx, newheader);
 			if (addedrdataset != NULL)
 				bind_rdataset(rbtdb, rbtnode, header, now,
 					      addedrdataset);
@@ -4684,7 +5719,7 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion,
 			 * loading, we MUST clean up 'header' now.
 			 */
 			newheader->down = NULL;
-			free_rdataset(rbtdb->common.mctx, header);
+			free_rdataset(rbtdb, rbtdb->common.mctx, header);
 		} else {
 			newheader->down = topheader;
 			topheader->next = newheader;
@@ -4692,9 +5727,23 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion,
 			if (changed != NULL)
 				changed->dirty = ISC_TRUE;
 			if (rbtversion == NULL) {
-				header->ttl = 0;
+				set_ttl(rbtdb, header, 0);
 				header->attributes |= RDATASET_ATTR_STALE;
 			}
+			idx = newheader->node->locknum;
+			if (IS_CACHE(rbtdb)) {
+				ISC_LIST_PREPEND(rbtdb->rdatasets[idx],
+						 newheader, lru_link);
+				/*
+				 * XXXMLG We don't check the return value
+				 * here.  If it fails, we will not do TTL
+				 * based expiry on this node.  However, we
+				 * will do it on the LRU side, so memory
+				 * will not leak... for long.
+				 */
+				isc_heap_insert(rbtdb->heaps[idx], newheader);
+			} else if (RESIGN(newheader))
+				resign_insert(rbtdb, idx, newheader);
 		}
 	} else {
 		/*
@@ -4706,7 +5755,7 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion,
 		 * If we're trying to delete the type, don't bother.
 		 */
 		if (newheader_nx) {
-			free_rdataset(rbtdb->common.mctx, newheader);
+			free_rdataset(rbtdb, rbtdb->common.mctx, newheader);
 			return (DNS_R_UNCHANGED);
 		}
 
@@ -4740,6 +5789,14 @@ add(dns_rbtdb_t *rbtdb, dns_rbtnode_t *rbtnode, rbtdb_version_t *rbtversion,
 			newheader->down = NULL;
 			rbtnode->data = newheader;
 		}
+		idx = newheader->node->locknum;
+		if (IS_CACHE(rbtdb)) {
+			ISC_LIST_PREPEND(rbtdb->rdatasets[idx],
+					 newheader, lru_link);
+			isc_heap_insert(rbtdb->heaps[idx], newheader);
+		} else if (RESIGN(newheader)) {
+			resign_insert(rbtdb, idx, newheader);
+		}
 	}
 
 	/*
@@ -4778,15 +5835,15 @@ addnoqname(dns_rbtdb_t *rbtdb, rdatasetheader_t *newheader,
 	struct noqname *noqname;
 	isc_mem_t *mctx = rbtdb->common.mctx;
 	dns_name_t name;
-	dns_rdataset_t nsec, nsecsig;
+	dns_rdataset_t neg, negsig;
 	isc_result_t result;
 	isc_region_t r;
 
 	dns_name_init(&name, NULL);
-	dns_rdataset_init(&nsec);
-	dns_rdataset_init(&nsecsig);
+	dns_rdataset_init(&neg);
+	dns_rdataset_init(&negsig);
 
-	result = dns_rdataset_getnoqname(rdataset, &name, &nsec, &nsecsig);
+	result = dns_rdataset_getnoqname(rdataset, &name, &neg, &negsig);
 	RUNTIME_CHECK(result == ISC_R_SUCCESS);
 
 	noqname = isc_mem_get(mctx, sizeof(*noqname));
@@ -4795,31 +5852,84 @@ addnoqname(dns_rbtdb_t *rbtdb, rdatasetheader_t *newheader,
 		goto cleanup;
 	}
 	dns_name_init(&noqname->name, NULL);
-	noqname->nsec = NULL;
-	noqname->nsecsig = NULL;
+	noqname->neg = NULL;
+	noqname->negsig = NULL;
+	noqname->type = neg.type;
 	result = dns_name_dup(&name, mctx, &noqname->name);
 	if (result != ISC_R_SUCCESS)
 		goto cleanup;
-	result = dns_rdataslab_fromrdataset(&nsec, mctx, &r, 0);
+	result = dns_rdataslab_fromrdataset(&neg, mctx, &r, 0);
 	if (result != ISC_R_SUCCESS)
 		goto cleanup;
-	noqname->nsec = r.base;
-	result = dns_rdataslab_fromrdataset(&nsecsig, mctx, &r, 0);
+	noqname->neg = r.base;
+	result = dns_rdataslab_fromrdataset(&negsig, mctx, &r, 0);
 	if (result != ISC_R_SUCCESS)
 		goto cleanup;
-	noqname->nsecsig = r.base;
-	dns_rdataset_disassociate(&nsec);
-	dns_rdataset_disassociate(&nsecsig);
+	noqname->negsig = r.base;
+	dns_rdataset_disassociate(&neg);
+	dns_rdataset_disassociate(&negsig);
 	newheader->noqname = noqname;
 	return (ISC_R_SUCCESS);
 
 cleanup:
-	dns_rdataset_disassociate(&nsec);
-	dns_rdataset_disassociate(&nsecsig);
+	dns_rdataset_disassociate(&neg);
+	dns_rdataset_disassociate(&negsig);
 	free_noqname(mctx, &noqname);
 	return(result);
 }
 
+static inline isc_result_t
+addclosest(dns_rbtdb_t *rbtdb, rdatasetheader_t *newheader,
+	   dns_rdataset_t *rdataset)
+{
+	struct noqname *closest;
+	isc_mem_t *mctx = rbtdb->common.mctx;
+	dns_name_t name;
+	dns_rdataset_t neg, negsig;
+	isc_result_t result;
+	isc_region_t r;
+
+	dns_name_init(&name, NULL);
+	dns_rdataset_init(&neg);
+	dns_rdataset_init(&negsig);
+
+	result = dns_rdataset_getclosest(rdataset, &name, &neg, &negsig);
+	RUNTIME_CHECK(result == ISC_R_SUCCESS);
+
+	closest = isc_mem_get(mctx, sizeof(*closest));
+	if (closest == NULL) {
+		result = ISC_R_NOMEMORY;
+		goto cleanup;
+	}
+	dns_name_init(&closest->name, NULL);
+	closest->neg = NULL;
+	closest->negsig = NULL;
+	closest->type = neg.type;
+	result = dns_name_dup(&name, mctx, &closest->name);
+	if (result != ISC_R_SUCCESS)
+		goto cleanup;
+	result = dns_rdataslab_fromrdataset(&neg, mctx, &r, 0);
+	if (result != ISC_R_SUCCESS)
+		goto cleanup;
+	closest->neg = r.base;
+	result = dns_rdataslab_fromrdataset(&negsig, mctx, &r, 0);
+	if (result != ISC_R_SUCCESS)
+		goto cleanup;
+	closest->negsig = r.base;
+	dns_rdataset_disassociate(&neg);
+	dns_rdataset_disassociate(&negsig);
+	newheader->closest = closest;
+	return (ISC_R_SUCCESS);
+
+ cleanup:
+	dns_rdataset_disassociate(&neg);
+	dns_rdataset_disassociate(&negsig);
+	free_noqname(mctx, &closest);
+	return(result);
+}
+
+static dns_dbmethods_t zone_methods;
+
 static isc_result_t
 addrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version,
 	    isc_stdtime_t now, dns_rdataset_t *rdataset, unsigned int options,
@@ -4830,11 +5940,21 @@ addrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version,
 	rbtdb_version_t *rbtversion = version;
 	isc_region_t region;
 	rdatasetheader_t *newheader;
+	rdatasetheader_t *header;
 	isc_result_t result;
 	isc_boolean_t delegating;
+	isc_boolean_t tree_locked = ISC_FALSE;
 
 	REQUIRE(VALID_RBTDB(rbtdb));
 
+	if (rbtdb->common.methods == &zone_methods)
+		REQUIRE(((rbtnode->nsec3 &&
+			  (rdataset->type == dns_rdatatype_nsec3 ||
+			   rdataset->covers == dns_rdatatype_nsec3)) ||
+			 (!rbtnode->nsec3 &&
+			   rdataset->type != dns_rdatatype_nsec3 &&
+			   rdataset->covers != dns_rdatatype_nsec3)));
+
 	if (rbtversion == NULL) {
 		if (now == 0)
 			isc_stdtime_get(&now);
@@ -4848,26 +5968,48 @@ addrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version,
 		return (result);
 
 	newheader = (rdatasetheader_t *)region.base;
-	newheader->ttl = rdataset->ttl + now;
+	init_rdataset(rbtdb, newheader);
+	set_ttl(rbtdb, newheader, rdataset->ttl + now);
 	newheader->type = RBTDB_RDATATYPE_VALUE(rdataset->type,
 						rdataset->covers);
 	newheader->attributes = 0;
 	newheader->noqname = NULL;
+	newheader->closest = NULL;
 	newheader->count = init_count++;
 	newheader->trust = rdataset->trust;
 	newheader->additional_auth = NULL;
 	newheader->additional_glue = NULL;
+	newheader->last_used = now;
+	newheader->node = rbtnode;
 	if (rbtversion != NULL) {
 		newheader->serial = rbtversion->serial;
 		now = 0;
+
+		if ((rdataset->attributes & DNS_RDATASETATTR_RESIGN) != 0) {
+			newheader->attributes |= RDATASET_ATTR_RESIGN;
+			newheader->resign = rdataset->resign;
+		} else
+			newheader->resign = 0;
 	} else {
 		newheader->serial = 1;
+		newheader->resign = 0;
 		if ((rdataset->attributes & DNS_RDATASETATTR_NXDOMAIN) != 0)
 			newheader->attributes |= RDATASET_ATTR_NXDOMAIN;
+		if ((rdataset->attributes & DNS_RDATASETATTR_OPTOUT) != 0)
+			newheader->attributes |= RDATASET_ATTR_OPTOUT;
 		if ((rdataset->attributes & DNS_RDATASETATTR_NOQNAME) != 0) {
 			result = addnoqname(rbtdb, newheader, rdataset);
 			if (result != ISC_R_SUCCESS) {
-				free_rdataset(rbtdb->common.mctx, newheader);
+				free_rdataset(rbtdb, rbtdb->common.mctx,
+					      newheader);
+				return (result);
+			}
+		}
+		if ((rdataset->attributes & DNS_RDATASETATTR_CLOSEST) != 0) {
+			result = addclosest(rbtdb, newheader, rdataset);
+			if (result != ISC_R_SUCCESS) {
+				free_rdataset(rbtdb, rbtdb->common.mctx,
+					      newheader);
 				return (result);
 			}
 		}
@@ -4876,18 +6018,54 @@ addrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version,
 	/*
 	 * If we're adding a delegation type (e.g. NS or DNAME for a zone,
 	 * just DNAME for the cache), then we need to set the callback bit
-	 * on the node, and to do that we must be holding an exclusive lock
-	 * on the tree.
+	 * on the node.
 	 */
-	if (delegating_type(rbtdb, rbtnode, rdataset->type)) {
+	if (delegating_type(rbtdb, rbtnode, rdataset->type))
 		delegating = ISC_TRUE;
-		RWLOCK(&rbtdb->tree_lock, isc_rwlocktype_write);
-	} else
+	else
 		delegating = ISC_FALSE;
 
+	/*
+	 * If we're adding a delegation type or the DB is a cache in an overmem
+	 * state, hold an exclusive lock on the tree.  In the latter case
+	 * the lock does not necessarily have to be acquired but it will help
+	 * purge stale entries more effectively.
+	 */
+	if (delegating || (IS_CACHE(rbtdb) && rbtdb->overmem)) {
+		tree_locked = ISC_TRUE;
+		RWLOCK(&rbtdb->tree_lock, isc_rwlocktype_write);
+	}
+
+	if (IS_CACHE(rbtdb) && rbtdb->overmem)
+		overmem_purge(rbtdb, rbtnode->locknum, now, tree_locked);
+
 	NODE_LOCK(&rbtdb->node_locks[rbtnode->locknum].lock,
 		  isc_rwlocktype_write);
 
+	if (rbtdb->rrsetstats != NULL) {
+		newheader->attributes |= RDATASET_ATTR_STATCOUNT;
+		update_rrsetstats(rbtdb, newheader, ISC_TRUE);
+	}
+
+	if (IS_CACHE(rbtdb)) {
+		if (tree_locked)
+			cleanup_dead_nodes(rbtdb, rbtnode->locknum);
+
+		header = isc_heap_element(rbtdb->heaps[rbtnode->locknum], 1);
+		if (header && header->rdh_ttl <= now - RBTDB_VIRTUAL)
+			expire_header(rbtdb, header, tree_locked);
+
+		/*
+		 * If we've been holding a write lock on the tree just for
+		 * cleaning, we can release it now.  However, we still need the
+		 * node lock.
+		 */
+		if (tree_locked && !delegating) {
+			RWUNLOCK(&rbtdb->tree_lock, isc_rwlocktype_write);
+			tree_locked = ISC_FALSE;
+		}
+	}
+
 	result = add(rbtdb, rbtnode, rbtversion, newheader, options, ISC_FALSE,
 		     addedrdataset, now);
 	if (result == ISC_R_SUCCESS && delegating)
@@ -4896,15 +6074,15 @@ addrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version,
 	NODE_UNLOCK(&rbtdb->node_locks[rbtnode->locknum].lock,
 		    isc_rwlocktype_write);
 
-	if (delegating)
+	if (tree_locked)
 		RWUNLOCK(&rbtdb->tree_lock, isc_rwlocktype_write);
 
 	/*
 	 * Update the zone's secure status.  If version is non-NULL
-	 * this is defered until closeversion() is called.
+	 * this is deferred until closeversion() is called.
 	 */
 	if (result == ISC_R_SUCCESS && version == NULL && !IS_CACHE(rbtdb))
-		rbtdb->secure = iszonesecure(db, rbtdb->origin_node);
+		iszonesecure(db, version, rbtdb->origin_node);
 
 	return (result);
 }
@@ -4925,29 +6103,46 @@ subtractrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version,
 
 	REQUIRE(VALID_RBTDB(rbtdb));
 
+	if (rbtdb->common.methods == &zone_methods)
+		REQUIRE(((rbtnode->nsec3 &&
+			  (rdataset->type == dns_rdatatype_nsec3 ||
+			   rdataset->covers == dns_rdatatype_nsec3)) ||
+			 (!rbtnode->nsec3 &&
+			   rdataset->type != dns_rdatatype_nsec3 &&
+			   rdataset->covers != dns_rdatatype_nsec3)));
+
 	result = dns_rdataslab_fromrdataset(rdataset, rbtdb->common.mctx,
 					    &region,
 					    sizeof(rdatasetheader_t));
 	if (result != ISC_R_SUCCESS)
 		return (result);
 	newheader = (rdatasetheader_t *)region.base;
-	newheader->ttl = rdataset->ttl;
+	init_rdataset(rbtdb, newheader);
+	set_ttl(rbtdb, newheader, rdataset->ttl);
 	newheader->type = RBTDB_RDATATYPE_VALUE(rdataset->type,
 						rdataset->covers);
 	newheader->attributes = 0;
 	newheader->serial = rbtversion->serial;
 	newheader->trust = 0;
 	newheader->noqname = NULL;
+	newheader->closest = NULL;
 	newheader->count = init_count++;
 	newheader->additional_auth = NULL;
 	newheader->additional_glue = NULL;
+	newheader->last_used = 0;
+	newheader->node = rbtnode;
+	if ((rdataset->attributes & DNS_RDATASETATTR_RESIGN) != 0) {
+		newheader->attributes |= RDATASET_ATTR_RESIGN;
+		newheader->resign = rdataset->resign;
+	} else
+		newheader->resign = 0;
 
 	NODE_LOCK(&rbtdb->node_locks[rbtnode->locknum].lock,
 		  isc_rwlocktype_write);
 
 	changed = add_changed(rbtdb, rbtversion, rbtnode);
 	if (changed == NULL) {
-		free_rdataset(rbtdb->common.mctx, newheader);
+		free_rdataset(rbtdb, rbtdb->common.mctx, newheader);
 		NODE_UNLOCK(&rbtdb->node_locks[rbtnode->locknum].lock,
 			    isc_rwlocktype_write);
 		return (ISC_R_NOMEMORY);
@@ -4975,7 +6170,7 @@ subtractrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version,
 		result = ISC_R_SUCCESS;
 		if ((options & DNS_DBSUB_EXACT) != 0) {
 			flags |= DNS_RDATASLAB_EXACT;
-			if (newheader->ttl != header->ttl)
+			if (newheader->rdh_ttl != header->rdh_ttl)
 				result = DNS_R_NOTEXACT;
 		}
 		if (result == ISC_R_SUCCESS)
@@ -4988,8 +6183,9 @@ subtractrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version,
 					(dns_rdatatype_t)header->type,
 					flags, &subresult);
 		if (result == ISC_R_SUCCESS) {
-			free_rdataset(rbtdb->common.mctx, newheader);
+			free_rdataset(rbtdb, rbtdb->common.mctx, newheader);
 			newheader = (rdatasetheader_t *)subresult;
+			init_rdataset(rbtdb, newheader);
 			/*
 			 * We have to set the serial since the rdataslab
 			 * subtraction routine copies the reserved portion of
@@ -5008,24 +6204,27 @@ subtractrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version,
 			 * This subtraction would remove all of the rdata;
 			 * add a nonexistent header instead.
 			 */
-			free_rdataset(rbtdb->common.mctx, newheader);
-			newheader = isc_mem_get(rbtdb->common.mctx,
-						sizeof(*newheader));
+			free_rdataset(rbtdb, rbtdb->common.mctx, newheader);
+			newheader = new_rdataset(rbtdb, rbtdb->common.mctx);
 			if (newheader == NULL) {
 				result = ISC_R_NOMEMORY;
 				goto unlock;
 			}
-			newheader->ttl = 0;
+			set_ttl(rbtdb, newheader, 0);
 			newheader->type = topheader->type;
 			newheader->attributes = RDATASET_ATTR_NONEXISTENT;
 			newheader->trust = 0;
 			newheader->serial = rbtversion->serial;
 			newheader->noqname = NULL;
+			newheader->closest = NULL;
 			newheader->count = 0;
 			newheader->additional_auth = NULL;
 			newheader->additional_glue = NULL;
+			newheader->node = rbtnode;
+			newheader->resign = 0;
+			newheader->last_used = 0;
 		} else {
-			free_rdataset(rbtdb->common.mctx, newheader);
+			free_rdataset(rbtdb, rbtdb->common.mctx, newheader);
 			goto unlock;
 		}
 
@@ -5048,7 +6247,7 @@ subtractrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version,
 		 * The rdataset doesn't exist, so we don't need to do anything
 		 * to satisfy the deletion request.
 		 */
-		free_rdataset(rbtdb->common.mctx, newheader);
+		free_rdataset(rbtdb, rbtdb->common.mctx, newheader);
 		if ((options & DNS_DBSUB_EXACT) != 0)
 			result = DNS_R_NOTEXACT;
 		else
@@ -5064,10 +6263,10 @@ subtractrdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version,
 
 	/*
 	 * Update the zone's secure status.  If version is non-NULL
-	 * this is defered until closeversion() is called.
+	 * this is deferred until closeversion() is called.
 	 */
 	if (result == ISC_R_SUCCESS && version == NULL && !IS_CACHE(rbtdb))
-		rbtdb->secure = iszonesecure(db, rbtdb->origin_node);
+		iszonesecure(db, rbtdb->current_version, rbtdb->origin_node);
 
 	return (result);
 }
@@ -5089,14 +6288,15 @@ deleterdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version,
 	if (type == dns_rdatatype_rrsig && covers == 0)
 		return (ISC_R_NOTIMPLEMENTED);
 
-	newheader = isc_mem_get(rbtdb->common.mctx, sizeof(*newheader));
+	newheader = new_rdataset(rbtdb, rbtdb->common.mctx);
 	if (newheader == NULL)
 		return (ISC_R_NOMEMORY);
-	newheader->ttl = 0;
+	set_ttl(rbtdb, newheader, 0);
 	newheader->type = RBTDB_RDATATYPE_VALUE(type, covers);
 	newheader->attributes = RDATASET_ATTR_NONEXISTENT;
 	newheader->trust = 0;
 	newheader->noqname = NULL;
+	newheader->closest = NULL;
 	newheader->additional_auth = NULL;
 	newheader->additional_glue = NULL;
 	if (rbtversion != NULL)
@@ -5104,6 +6304,8 @@ deleterdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version,
 	else
 		newheader->serial = 0;
 	newheader->count = 0;
+	newheader->last_used = 0;
+	newheader->node = rbtnode;
 
 	NODE_LOCK(&rbtdb->node_locks[rbtnode->locknum].lock,
 		  isc_rwlocktype_write);
@@ -5116,10 +6318,10 @@ deleterdataset(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version,
 
 	/*
 	 * Update the zone's secure status.  If version is non-NULL
-	 * this is defered until closeversion() is called.
+	 * this is deferred until closeversion() is called.
 	 */
 	if (result == ISC_R_SUCCESS && version == NULL && !IS_CACHE(rbtdb))
-		rbtdb->secure = iszonesecure(db, rbtdb->origin_node);
+		iszonesecure(db, rbtdb->current_version, rbtdb->origin_node);
 
 	return (result);
 }
@@ -5147,7 +6349,9 @@ loading_addrdataset(void *arg, dns_name_t *name, dns_rdataset_t *rdataset) {
 	    !IS_CACHE(rbtdb) && !dns_name_equal(name, &rbtdb->common.origin))
 		return (DNS_R_NOTZONETOP);
 
-	add_empty_wildcards(rbtdb, name);
+	if (rdataset->type != dns_rdatatype_nsec3 &&
+	    rdataset->covers != dns_rdatatype_nsec3)
+		add_empty_wildcards(rbtdb, name);
 
 	if (dns_name_iswildcard(name)) {
 		/*
@@ -5155,13 +6359,27 @@ loading_addrdataset(void *arg, dns_name_t *name, dns_rdataset_t *rdataset) {
 		 */
 		if (rdataset->type == dns_rdatatype_ns)
 			return (DNS_R_INVALIDNS);
+		/*
+		 * NSEC3 record owners cannot legally be wild cards.
+		 */
+		if (rdataset->type == dns_rdatatype_nsec3)
+			return (DNS_R_INVALIDNSEC3);
 		result = add_wildcard_magic(rbtdb, name);
 		if (result != ISC_R_SUCCESS)
 			return (result);
 	}
 
 	node = NULL;
-	result = dns_rbt_addnode(rbtdb->tree, name, &node);
+	if (rdataset->type == dns_rdatatype_nsec3 ||
+	    rdataset->covers == dns_rdatatype_nsec3) {
+		result = dns_rbt_addnode(rbtdb->nsec3, name, &node);
+		if (result == ISC_R_SUCCESS)
+			node->nsec3 = 1;
+	} else {
+		result = dns_rbt_addnode(rbtdb->tree, name, &node);
+		if (result == ISC_R_SUCCESS)
+			node->nsec3 = 0;
+	}
 	if (result != ISC_R_SUCCESS && result != ISC_R_EXISTS)
 		return (result);
 	if (result != ISC_R_EXISTS) {
@@ -5182,16 +6400,26 @@ loading_addrdataset(void *arg, dns_name_t *name, dns_rdataset_t *rdataset) {
 	if (result != ISC_R_SUCCESS)
 		return (result);
 	newheader = (rdatasetheader_t *)region.base;
-	newheader->ttl = rdataset->ttl + loadctx->now; /* XXX overflow check */
+	init_rdataset(rbtdb, newheader);
+	set_ttl(rbtdb, newheader,
+		rdataset->ttl + loadctx->now); /* XXX overflow check */
 	newheader->type = RBTDB_RDATATYPE_VALUE(rdataset->type,
 						rdataset->covers);
 	newheader->attributes = 0;
 	newheader->trust = rdataset->trust;
 	newheader->serial = 1;
 	newheader->noqname = NULL;
+	newheader->closest = NULL;
 	newheader->count = init_count++;
 	newheader->additional_auth = NULL;
 	newheader->additional_glue = NULL;
+	newheader->last_used = 0;
+	newheader->node = node;
+	if ((rdataset->attributes & DNS_RDATASETATTR_RESIGN) != 0) {
+		newheader->attributes |= RDATASET_ATTR_RESIGN;
+		newheader->resign = rdataset->resign;
+	} else
+		newheader->resign = 0;
 
 	result = add(rbtdb, node, rbtdb->current_version, newheader,
 		     DNS_DBADD_MERGE, ISC_TRUE, NULL, 0);
@@ -5262,7 +6490,7 @@ endload(dns_db_t *db, dns_dbload_t **dbloadp) {
 	 * zone key, we consider the zone secure.
 	 */
 	if (! IS_CACHE(rbtdb))
-		rbtdb->secure = iszonesecure(db, rbtdb->origin_node);
+		iszonesecure(db, rbtdb->current_version, rbtdb->origin_node);
 
 	*dbloadp = NULL;
 
@@ -5292,7 +6520,7 @@ delete_callback(void *data, void *arg) {
 
 	for (current = data; current != NULL; current = next) {
 		next = current->next;
-		free_rdataset(rbtdb->common.mctx, current);
+		free_rdataset(rbtdb, rbtdb->common.mctx, current);
 	}
 }
 
@@ -5306,12 +6534,28 @@ issecure(dns_db_t *db) {
 	REQUIRE(VALID_RBTDB(rbtdb));
 
 	RWLOCK(&rbtdb->tree_lock, isc_rwlocktype_read);
-	secure = rbtdb->secure;
+	secure = ISC_TF(rbtdb->current_version->secure == dns_db_secure);
 	RWUNLOCK(&rbtdb->tree_lock, isc_rwlocktype_read);
 
 	return (secure);
 }
 
+static isc_boolean_t
+isdnssec(dns_db_t *db) {
+	dns_rbtdb_t *rbtdb;
+	isc_boolean_t dnssec;
+
+	rbtdb = (dns_rbtdb_t *)db;
+
+	REQUIRE(VALID_RBTDB(rbtdb));
+
+	RWLOCK(&rbtdb->tree_lock, isc_rwlocktype_read);
+	dnssec = ISC_TF(rbtdb->current_version->secure != dns_db_insecure);
+	RWUNLOCK(&rbtdb->tree_lock, isc_rwlocktype_read);
+
+	return (dnssec);
+}
+
 static unsigned int
 nodecount(dns_db_t *db) {
 	dns_rbtdb_t *rbtdb;
@@ -5368,13 +6612,180 @@ getoriginnode(dns_db_t *db, dns_dbnode_t **nodep) {
 
 		*nodep = rbtdb->origin_node;
 	} else {
-		INSIST(!IS_CACHE(rbtdb));
+		INSIST(IS_CACHE(rbtdb));
 		result = ISC_R_NOTFOUND;
 	}
 
 	return (result);
 }
 
+static isc_result_t
+getnsec3parameters(dns_db_t *db, dns_dbversion_t *version, dns_hash_t *hash,
+		   isc_uint8_t *flags, isc_uint16_t *iterations,
+		   unsigned char *salt, size_t *salt_length)
+{
+	dns_rbtdb_t *rbtdb;
+	isc_result_t result = ISC_R_NOTFOUND;
+	rbtdb_version_t *rbtversion = version;
+
+	rbtdb = (dns_rbtdb_t *)db;
+
+	REQUIRE(VALID_RBTDB(rbtdb));
+
+	RWLOCK(&rbtdb->tree_lock, isc_rwlocktype_read);
+
+	if (rbtversion == NULL)
+		rbtversion = rbtdb->current_version;
+
+	if (rbtversion->havensec3) {
+		if (hash != NULL)
+			*hash = rbtversion->hash;
+		if (salt != NULL && salt_length != 0) {
+			REQUIRE(*salt_length > rbtversion->salt_length);
+			memcpy(salt, rbtversion->salt, rbtversion->salt_length);
+		}
+		if (salt_length != NULL)
+			*salt_length = rbtversion->salt_length;
+		if (iterations != NULL)
+			*iterations = rbtversion->iterations;
+		if (flags != NULL)
+			*flags = rbtversion->flags;
+		result = ISC_R_SUCCESS;
+	}
+	RWUNLOCK(&rbtdb->tree_lock, isc_rwlocktype_read);
+
+	return (result);
+}
+
+static isc_result_t
+setsigningtime(dns_db_t *db, dns_rdataset_t *rdataset, isc_stdtime_t resign) {
+	dns_rbtdb_t *rbtdb = (dns_rbtdb_t *)db;
+	isc_stdtime_t oldresign;
+	isc_result_t result = ISC_R_SUCCESS;
+	rdatasetheader_t *header;
+
+	REQUIRE(VALID_RBTDB(rbtdb));
+	REQUIRE(!IS_CACHE(rbtdb));
+	REQUIRE(rdataset != NULL);
+
+	header = rdataset->private3;
+	header--;
+
+	NODE_LOCK(&rbtdb->node_locks[header->node->locknum].lock,
+		  isc_rwlocktype_write);
+
+	oldresign = header->resign;
+	header->resign = resign;
+	if (header->heap_index != 0) {
+		INSIST(RESIGN(header));
+		if (resign == 0) {
+			isc_heap_delete(rbtdb->heaps[header->node->locknum],
+					header->heap_index);
+			header->heap_index = 0;
+		} else if (resign < oldresign)
+			isc_heap_increased(rbtdb->heaps[header->node->locknum],
+					   header->heap_index);
+		else
+			isc_heap_decreased(rbtdb->heaps[header->node->locknum],
+					   header->heap_index);
+	} else if (resign && header->heap_index == 0) {
+		header->attributes |= RDATASET_ATTR_RESIGN;
+		result = resign_insert(rbtdb, header->node->locknum, header);
+	}
+	NODE_UNLOCK(&rbtdb->node_locks[header->node->locknum].lock,
+		    isc_rwlocktype_write);
+	return (result);
+}
+
+static isc_result_t
+getsigningtime(dns_db_t *db, dns_rdataset_t *rdataset,
+	       dns_name_t *foundname)
+{
+	dns_rbtdb_t *rbtdb = (dns_rbtdb_t *)db;
+	rdatasetheader_t *header = NULL, *this;
+	unsigned int i;
+	isc_result_t result = ISC_R_NOTFOUND;
+
+	REQUIRE(VALID_RBTDB(rbtdb));
+
+	RBTDB_LOCK(&rbtdb->lock, isc_rwlocktype_read);
+
+	for (i = 0; i < rbtdb->node_lock_count; i++) {
+		this = isc_heap_element(rbtdb->heaps[i], 1);
+		if (this == NULL)
+			continue;
+		if (header == NULL)
+			header = this;
+		else if (isc_serial_lt(this->resign, header->resign))
+			header = this;
+	}
+
+	if (header == NULL)
+		goto unlock;
+
+	NODE_LOCK(&rbtdb->node_locks[header->node->locknum].lock,
+		  isc_rwlocktype_read);
+
+	bind_rdataset(rbtdb, header->node, header, 0, rdataset);
+
+	if (foundname != NULL)
+		dns_rbt_fullnamefromnode(header->node, foundname);
+
+	NODE_UNLOCK(&rbtdb->node_locks[header->node->locknum].lock,
+		    isc_rwlocktype_read);
+
+	result = ISC_R_SUCCESS;
+
+ unlock:
+	RBTDB_UNLOCK(&rbtdb->lock, isc_rwlocktype_read);
+
+	return (result);
+}
+
+static void
+resigned(dns_db_t *db, dns_rdataset_t *rdataset, dns_dbversion_t *version)
+{
+	rbtdb_version_t *rbtversion = (rbtdb_version_t *)version;
+	dns_rbtdb_t *rbtdb = (dns_rbtdb_t *)db;
+	dns_rbtnode_t *node;
+	rdatasetheader_t *header;
+
+	REQUIRE(VALID_RBTDB(rbtdb));
+	REQUIRE(rdataset != NULL);
+	REQUIRE(rbtdb->future_version == rbtversion);
+	REQUIRE(rbtversion->writer);
+
+	node = rdataset->private2;
+	header = rdataset->private3;
+	header--;
+
+	RBTDB_LOCK(&rbtdb->lock, isc_rwlocktype_read);
+	NODE_LOCK(&rbtdb->node_locks[node->locknum].lock,
+		  isc_rwlocktype_write);
+	/*
+	 * Delete from heap and save to re-signed list so that it can
+	 * be restored if we backout of this change.
+	 */
+	new_reference(rbtdb, node);
+	isc_heap_delete(rbtdb->heaps[node->locknum], header->heap_index);
+	header->heap_index = 0;
+	ISC_LIST_APPEND(rbtversion->resigned_list, header, lru_link);
+
+	NODE_UNLOCK(&rbtdb->node_locks[node->locknum].lock,
+		    isc_rwlocktype_write);
+	RBTDB_UNLOCK(&rbtdb->lock, isc_rwlocktype_read);
+}
+
+static dns_stats_t *
+getrrsetstats(dns_db_t *db) {
+	dns_rbtdb_t *rbtdb = (dns_rbtdb_t *)db;
+
+	REQUIRE(VALID_RBTDB(rbtdb));
+	REQUIRE(IS_CACHE(rbtdb)); /* current restriction */
+
+	return (rbtdb->rrsetstats);
+}
+
 static dns_dbmethods_t zone_methods = {
 	attach,
 	detach,
@@ -5403,7 +6814,15 @@ static dns_dbmethods_t zone_methods = {
 	ispersistent,
 	overmem,
 	settask,
-	getoriginnode
+	getoriginnode,
+	NULL,
+	getnsec3parameters,
+	findnsec3node,
+	setsigningtime,
+	getsigningtime,
+	resigned,
+	isdnssec,
+	NULL
 };
 
 static dns_dbmethods_t cache_methods = {
@@ -5434,7 +6853,15 @@ static dns_dbmethods_t cache_methods = {
 	ispersistent,
 	overmem,
 	settask,
-	getoriginnode
+	getoriginnode,
+	NULL,
+	NULL,
+	NULL,
+	NULL,
+	NULL,
+	NULL,
+	isdnssec,
+	getrrsetstats
 };
 
 isc_result_t
@@ -5451,6 +6878,7 @@ dns_rbtdb_create
 	isc_result_t result;
 	int i;
 	dns_name_t name;
+	isc_boolean_t (*sooner)(void *, void *);
 
 	/* Keep the compiler happy. */
 	UNUSED(argc);
@@ -5483,11 +6911,20 @@ dns_rbtdb_create
 	if (result != ISC_R_SUCCESS)
 		goto cleanup_lock;
 
+	/*
+	 * Initialize node_lock_count in a generic way to support future
+	 * extension which allows the user to specify this value on creation.
+	 * Note that when specified for a cache DB it must be larger than 1
+	 * as commented with the definition of DEFAULT_CACHE_NODE_LOCK_COUNT.
+	 */
 	if (rbtdb->node_lock_count == 0) {
 		if (IS_CACHE(rbtdb))
 			rbtdb->node_lock_count = DEFAULT_CACHE_NODE_LOCK_COUNT;
 		else
 			rbtdb->node_lock_count = DEFAULT_NODE_LOCK_COUNT;
+	} else if (rbtdb->node_lock_count < 2 && IS_CACHE(rbtdb)) {
+		result = ISC_R_RANGE;
+		goto cleanup_tree_lock;
 	}
 	INSIST(rbtdb->node_lock_count < (1 << DNS_RBT_LOCKLENGTH));
 	rbtdb->node_locks = isc_mem_get(mctx, rbtdb->node_lock_count *
@@ -5497,6 +6934,53 @@ dns_rbtdb_create
 		goto cleanup_tree_lock;
 	}
 
+	rbtdb->rrsetstats = NULL;
+	if (IS_CACHE(rbtdb)) {
+		result = dns_rdatasetstats_create(mctx, &rbtdb->rrsetstats);
+		if (result != ISC_R_SUCCESS)
+			goto cleanup_node_locks;
+		rbtdb->rdatasets = isc_mem_get(mctx, rbtdb->node_lock_count *
+					       sizeof(rdatasetheaderlist_t));
+		if (rbtdb->rdatasets == NULL) {
+			result = ISC_R_NOMEMORY;
+			goto cleanup_rrsetstats;
+		}
+		for (i = 0; i < (int)rbtdb->node_lock_count; i++)
+			ISC_LIST_INIT(rbtdb->rdatasets[i]);
+	} else
+		rbtdb->rdatasets = NULL;
+
+	/*
+	 * Create the heaps.
+	 */
+	rbtdb->heaps = isc_mem_get(mctx, rbtdb->node_lock_count *
+				   sizeof(isc_heap_t *));
+	if (rbtdb->heaps == NULL) {
+		result = ISC_R_NOMEMORY;
+		goto cleanup_rdatasets;
+	}
+	for (i = 0; i < (int)rbtdb->node_lock_count; i++)
+		rbtdb->heaps[i] = NULL;
+	sooner = IS_CACHE(rbtdb) ? ttl_sooner : resign_sooner;
+	for (i = 0; i < (int)rbtdb->node_lock_count; i++) {
+		result = isc_heap_create(mctx, sooner, set_index, 0,
+					 &rbtdb->heaps[i]);
+		if (result != ISC_R_SUCCESS)
+			goto cleanup_heaps;
+	}
+
+	/*
+	 * Create deadnode lists.
+	 */
+	rbtdb->deadnodes = isc_mem_get(mctx, rbtdb->node_lock_count *
+				       sizeof(rbtnodelist_t));
+	if (rbtdb->deadnodes == NULL) {
+		result = ISC_R_NOMEMORY;
+		goto cleanup_heaps;
+	}
+	for (i = 0; i < (int)rbtdb->node_lock_count; i++)
+		ISC_LIST_INIT(rbtdb->deadnodes[i]);
+
 	rbtdb->active = rbtdb->node_lock_count;
 
 	for (i = 0; i < (int)(rbtdb->node_lock_count); i++) {
@@ -5512,7 +6996,7 @@ dns_rbtdb_create
 				isc_refcount_decrement(&rbtdb->node_locks[i].references, NULL);
 				isc_refcount_destroy(&rbtdb->node_locks[i].references);
 			}
-			goto cleanup_node_locks;
+			goto cleanup_deadnodes;
 		}
 		rbtdb->node_locks[i].exiting = ISC_FALSE;
 	}
@@ -5525,7 +7009,7 @@ dns_rbtdb_create
 	isc_mem_attach(mctx, &rbtdb->common.mctx);
 
 	/*
-	 * Must be initalized before free_rbtdb() is called.
+	 * Must be initialized before free_rbtdb() is called.
 	 */
 	isc_ondestroy_init(&rbtdb->common.ondest);
 
@@ -5539,13 +7023,20 @@ dns_rbtdb_create
 	}
 
 	/*
-	 * Make the Red-Black Tree.
+	 * Make the Red-Black Trees.
 	 */
 	result = dns_rbt_create(mctx, delete_callback, rbtdb, &rbtdb->tree);
 	if (result != ISC_R_SUCCESS) {
 		free_rbtdb(rbtdb, ISC_FALSE, NULL);
 		return (result);
 	}
+
+	result = dns_rbt_create(mctx, delete_callback, rbtdb, &rbtdb->nsec3);
+	if (result != ISC_R_SUCCESS) {
+		free_rbtdb(rbtdb, ISC_FALSE, NULL);
+		return (result);
+	}
+
 	/*
 	 * In order to set the node callback bit correctly in zone databases,
 	 * we need to know if the node has the origin name of the zone.
@@ -5568,6 +7059,7 @@ dns_rbtdb_create
 			free_rbtdb(rbtdb, ISC_FALSE, NULL);
 			return (result);
 		}
+		rbtdb->origin_node->nsec3 = 0;
 		/*
 		 * We need to give the origin node the right locknum.
 		 */
@@ -5593,7 +7085,6 @@ dns_rbtdb_create
 		return (result);
 	}
 	rbtdb->attributes = 0;
-	rbtdb->secure = ISC_FALSE;
 	rbtdb->overmem = ISC_FALSE;
 	rbtdb->task = NULL;
 
@@ -5610,6 +7101,14 @@ dns_rbtdb_create
 		free_rbtdb(rbtdb, ISC_FALSE, NULL);
 		return (ISC_R_NOMEMORY);
 	}
+	rbtdb->current_version->secure = dns_db_insecure;
+	rbtdb->current_version->havensec3 = ISC_FALSE;
+	rbtdb->current_version->flags = 0;
+	rbtdb->current_version->iterations = 0;
+	rbtdb->current_version->hash = 0;
+	rbtdb->current_version->salt_length = 0;
+	memset(rbtdb->current_version->salt, 0,
+	       sizeof(rbtdb->current_version->salt));
 	rbtdb->future_version = NULL;
 	ISC_LIST_INIT(rbtdb->open_versions);
 	/*
@@ -5625,6 +7124,27 @@ dns_rbtdb_create
 
 	return (ISC_R_SUCCESS);
 
+ cleanup_deadnodes:
+	isc_mem_put(mctx, rbtdb->deadnodes,
+		    rbtdb->node_lock_count * sizeof(rbtnodelist_t));
+
+ cleanup_heaps:
+	if (rbtdb->heaps != NULL) {
+		for (i = 0 ; i < (int)rbtdb->node_lock_count ; i++)
+			if (rbtdb->heaps[i] != NULL)
+				isc_heap_destroy(&rbtdb->heaps[i]);
+		isc_mem_put(mctx, rbtdb->heaps,
+			    rbtdb->node_lock_count * sizeof(isc_heap_t *));
+	}
+
+ cleanup_rdatasets:
+	if (rbtdb->rdatasets != NULL)
+		isc_mem_put(mctx, rbtdb->rdatasets, rbtdb->node_lock_count *
+			    sizeof(rdatasetheaderlist_t));
+ cleanup_rrsetstats:
+	if (rbtdb->rrsetstats != NULL)
+		dns_stats_detach(&rbtdb->rrsetstats);
+
  cleanup_node_locks:
 	isc_mem_put(mctx, rbtdb->node_locks,
 		    rbtdb->node_lock_count * sizeof(rbtdb_nodelock_t));
@@ -5655,7 +7175,7 @@ rdataset_disassociate(dns_rdataset_t *rdataset) {
 
 static isc_result_t
 rdataset_first(dns_rdataset_t *rdataset) {
-	unsigned char *raw = rdataset->private3;	/* RDATASLAB */
+	unsigned char *raw = rdataset->private3;        /* RDATASLAB */
 	unsigned int count;
 
 	count = raw[0] * 256 + raw[1];
@@ -5691,7 +7211,7 @@ static isc_result_t
 rdataset_next(dns_rdataset_t *rdataset) {
 	unsigned int count;
 	unsigned int length;
-	unsigned char *raw;	/* RDATASLAB */
+	unsigned char *raw;     /* RDATASLAB */
 
 	count = rdataset->privateuint4;
 	if (count == 0)
@@ -5710,9 +7230,9 @@ rdataset_next(dns_rdataset_t *rdataset) {
 		raw += length;
 #if DNS_RDATASET_FIXED
 	}
-	rdataset->private5 = raw + 4;		/* length(2) + order(2) */
+	rdataset->private5 = raw + 4;           /* length(2) + order(2) */
 #else
-	rdataset->private5 = raw + 2;		/* length(2) */
+	rdataset->private5 = raw + 2;           /* length(2) */
 #endif
 
 	return (ISC_R_SUCCESS);
@@ -5720,11 +7240,13 @@ rdataset_next(dns_rdataset_t *rdataset) {
 
 static void
 rdataset_current(dns_rdataset_t *rdataset, dns_rdata_t *rdata) {
-	unsigned char *raw = rdataset->private5;	/* RDATASLAB */
+	unsigned char *raw = rdataset->private5;        /* RDATASLAB */
 #if DNS_RDATASET_FIXED
 	unsigned int offset;
 #endif
+	unsigned int length;
 	isc_region_t r;
+	unsigned int flags = 0;
 
 	REQUIRE(raw != NULL);
 
@@ -5740,15 +7262,22 @@ rdataset_current(dns_rdataset_t *rdataset, dns_rdata_t *rdata) {
 		raw += offset;
 	}
 #endif
-	r.length = raw[0] * 256 + raw[1];
-
+	length = raw[0] * 256 + raw[1];
 #if DNS_RDATASET_FIXED
 	raw += 4;
 #else
 	raw += 2;
 #endif
+	if (rdataset->type == dns_rdatatype_rrsig) {
+		if (*raw & DNS_RDATASLAB_OFFLINE)
+			flags |= DNS_RDATA_OFFLINE;
+		length--;
+		raw++;
+	}
+	r.length = length;
 	r.base = raw;
 	dns_rdata_fromregion(rdata, rdataset->rdclass, rdataset->type, &r);
+	rdata->flags |= flags;
 }
 
 static void
@@ -5769,7 +7298,7 @@ rdataset_clone(dns_rdataset_t *source, dns_rdataset_t *target) {
 
 static unsigned int
 rdataset_count(dns_rdataset_t *rdataset) {
-	unsigned char *raw = rdataset->private3;	/* RDATASLAB */
+	unsigned char *raw = rdataset->private3;        /* RDATASLAB */
 	unsigned int count;
 
 	count = raw[0] * 256 + raw[1];
@@ -5790,37 +7319,85 @@ rdataset_getnoqname(dns_rdataset_t *rdataset, dns_name_t *name,
 	attachnode(db, node, &cloned_node);
 	nsec->methods = &rdataset_methods;
 	nsec->rdclass = db->rdclass;
-	nsec->type = dns_rdatatype_nsec;
+	nsec->type = noqname->type;
 	nsec->covers = 0;
 	nsec->ttl = rdataset->ttl;
 	nsec->trust = rdataset->trust;
 	nsec->private1 = rdataset->private1;
 	nsec->private2 = rdataset->private2;
-	nsec->private3 = noqname->nsec;
+	nsec->private3 = noqname->neg;
 	nsec->privateuint4 = 0;
 	nsec->private5 = NULL;
 	nsec->private6 = NULL;
+	nsec->private7 = NULL;
 
 	cloned_node = NULL;
 	attachnode(db, node, &cloned_node);
 	nsecsig->methods = &rdataset_methods;
 	nsecsig->rdclass = db->rdclass;
 	nsecsig->type = dns_rdatatype_rrsig;
-	nsecsig->covers = dns_rdatatype_nsec;
+	nsecsig->covers = noqname->type;
 	nsecsig->ttl = rdataset->ttl;
 	nsecsig->trust = rdataset->trust;
 	nsecsig->private1 = rdataset->private1;
 	nsecsig->private2 = rdataset->private2;
-	nsecsig->private3 = noqname->nsecsig;
+	nsecsig->private3 = noqname->negsig;
 	nsecsig->privateuint4 = 0;
 	nsecsig->private5 = NULL;
 	nsec->private6 = NULL;
+	nsec->private7 = NULL;
 
 	dns_name_clone(&noqname->name, name);
 
 	return (ISC_R_SUCCESS);
 }
 
+static isc_result_t
+rdataset_getclosest(dns_rdataset_t *rdataset, dns_name_t *name,
+		    dns_rdataset_t *nsec, dns_rdataset_t *nsecsig)
+{
+	dns_db_t *db = rdataset->private1;
+	dns_dbnode_t *node = rdataset->private2;
+	dns_dbnode_t *cloned_node;
+	struct noqname *closest = rdataset->private7;
+
+	cloned_node = NULL;
+	attachnode(db, node, &cloned_node);
+	nsec->methods = &rdataset_methods;
+	nsec->rdclass = db->rdclass;
+	nsec->type = closest->type;
+	nsec->covers = 0;
+	nsec->ttl = rdataset->ttl;
+	nsec->trust = rdataset->trust;
+	nsec->private1 = rdataset->private1;
+	nsec->private2 = rdataset->private2;
+	nsec->private3 = closest->neg;
+	nsec->privateuint4 = 0;
+	nsec->private5 = NULL;
+	nsec->private6 = NULL;
+	nsec->private7 = NULL;
+
+	cloned_node = NULL;
+	attachnode(db, node, &cloned_node);
+	nsecsig->methods = &rdataset_methods;
+	nsecsig->rdclass = db->rdclass;
+	nsecsig->type = dns_rdatatype_rrsig;
+	nsecsig->covers = closest->type;
+	nsecsig->ttl = rdataset->ttl;
+	nsecsig->trust = rdataset->trust;
+	nsecsig->private1 = rdataset->private1;
+	nsecsig->private2 = rdataset->private2;
+	nsecsig->private3 = closest->negsig;
+	nsecsig->privateuint4 = 0;
+	nsecsig->private5 = NULL;
+	nsec->private6 = NULL;
+	nsec->private7 = NULL;
+
+	dns_name_clone(&closest->name, name);
+
+	return (ISC_R_SUCCESS);
+}
+
 /*
  * Rdataset Iterator Methods
  */
@@ -5871,13 +7448,13 @@ rdatasetiter_first(dns_rdatasetiter_t *iterator) {
 				 * record?  Or is it too old in the cache?
 				 *
 				 * Note: unlike everywhere else, we
-				 * check for now > header->ttl instead
-				 * of now >= header->ttl.  This allows
+				 * check for now > header->rdh_ttl instead
+				 * of now >= header->rdh_ttl.  This allows
 				 * ANY and RRSIG queries for 0 TTL
 				 * rdatasets to work.
 				 */
 				if (NONEXISTENT(header) ||
-				    (now != 0 && now > header->ttl))
+				    (now != 0 && now > header->rdh_ttl))
 					header = NULL;
 				break;
 			} else
@@ -5953,7 +7530,7 @@ rdatasetiter_next(dns_rdatasetiter_t *iterator) {
 					 */
 					if ((header->attributes &
 					     RDATASET_ATTR_NONEXISTENT) != 0 ||
-					    (now != 0 && now > header->ttl))
+					    (now != 0 && now > header->rdh_ttl))
 						header = NULL;
 					break;
 				} else
@@ -6009,9 +7586,7 @@ reference_iter_node(rbtdb_dbiterator_t *rbtdbiter) {
 		return;
 
 	INSIST(rbtdbiter->tree_locked != isc_rwlocktype_none);
-	NODE_STRONGLOCK(&rbtdb->node_locks[node->locknum].lock);
-	new_reference(rbtdb, node);
-	NODE_STRONGUNLOCK(&rbtdb->node_locks[node->locknum].lock);
+	reactivate_node(rbtdb, node, rbtdbiter->tree_locked);
 }
 
 static inline void
@@ -6026,7 +7601,7 @@ dereference_iter_node(rbtdb_dbiterator_t *rbtdbiter) {
 	lock = &rbtdb->node_locks[node->locknum].lock;
 	NODE_LOCK(lock, isc_rwlocktype_read);
 	decrement_reference(rbtdb, node, 0, isc_rwlocktype_read,
-			    rbtdbiter->tree_locked);
+			    rbtdbiter->tree_locked, ISC_FALSE);
 	NODE_UNLOCK(lock, isc_rwlocktype_read);
 
 	rbtdbiter->node = NULL;
@@ -6067,7 +7642,7 @@ flush_deletions(rbtdb_dbiterator_t *rbtdbiter) {
 			NODE_LOCK(lock, isc_rwlocktype_read);
 			decrement_reference(rbtdb, node, 0,
 					    isc_rwlocktype_read,
-					    rbtdbiter->tree_locked);
+					    rbtdbiter->tree_locked, ISC_FALSE);
 			NODE_UNLOCK(lock, isc_rwlocktype_read);
 		}
 
@@ -6117,6 +7692,7 @@ dbiterator_destroy(dns_dbiterator_t **iteratorp) {
 	dns_db_detach(&rbtdbiter->common.db);
 
 	dns_rbtnodechain_reset(&rbtdbiter->chain);
+	dns_rbtnodechain_reset(&rbtdbiter->nsec3chain);
 	isc_mem_put(db->mctx, rbtdbiter, sizeof(*rbtdbiter));
 	dns_db_detach(&db);
 
@@ -6142,12 +7718,25 @@ dbiterator_first(dns_dbiterator_t *iterator) {
 	name = dns_fixedname_name(&rbtdbiter->name);
 	origin = dns_fixedname_name(&rbtdbiter->origin);
 	dns_rbtnodechain_reset(&rbtdbiter->chain);
+	dns_rbtnodechain_reset(&rbtdbiter->nsec3chain);
 
-	result = dns_rbtnodechain_first(&rbtdbiter->chain, rbtdb->tree, name,
-					origin);
-
+	if (rbtdbiter->nsec3only) {
+		rbtdbiter->current = &rbtdbiter->nsec3chain;
+		result = dns_rbtnodechain_first(rbtdbiter->current,
+						rbtdb->nsec3, name, origin);
+	} else {
+		rbtdbiter->current = &rbtdbiter->chain;
+		result = dns_rbtnodechain_first(rbtdbiter->current,
+						rbtdb->tree, name, origin);
+		if (!rbtdbiter->nonsec3 && result == ISC_R_NOTFOUND) {
+			rbtdbiter->current = &rbtdbiter->nsec3chain;
+			result = dns_rbtnodechain_first(rbtdbiter->current,
+							rbtdb->nsec3, name,
+							origin);
+		}
+	}
 	if (result == ISC_R_SUCCESS || result == DNS_R_NEWORIGIN) {
-		result = dns_rbtnodechain_current(&rbtdbiter->chain, NULL,
+		result = dns_rbtnodechain_current(rbtdbiter->current, NULL,
 						  NULL, &rbtdbiter->node);
 		if (result == ISC_R_SUCCESS) {
 			rbtdbiter->new_origin = ISC_TRUE;
@@ -6182,11 +7771,21 @@ dbiterator_last(dns_dbiterator_t *iterator) {
 	name = dns_fixedname_name(&rbtdbiter->name);
 	origin = dns_fixedname_name(&rbtdbiter->origin);
 	dns_rbtnodechain_reset(&rbtdbiter->chain);
+	dns_rbtnodechain_reset(&rbtdbiter->nsec3chain);
 
-	result = dns_rbtnodechain_last(&rbtdbiter->chain, rbtdb->tree, name,
-				       origin);
+	result = ISC_R_NOTFOUND;
+	if (rbtdbiter->nsec3only && !rbtdbiter->nonsec3) {
+		rbtdbiter->current = &rbtdbiter->nsec3chain;
+		result = dns_rbtnodechain_last(rbtdbiter->current,
+					       rbtdb->nsec3, name, origin);
+	}
+	if (!rbtdbiter->nsec3only && result == ISC_R_NOTFOUND) {
+		rbtdbiter->current = &rbtdbiter->chain;
+		result = dns_rbtnodechain_last(rbtdbiter->current, rbtdb->tree,
+					       name, origin);
+	}
 	if (result == ISC_R_SUCCESS || result == DNS_R_NEWORIGIN) {
-		result = dns_rbtnodechain_current(&rbtdbiter->chain, NULL,
+		result = dns_rbtnodechain_current(rbtdbiter->current, NULL,
 						  NULL, &rbtdbiter->node);
 		if (result == ISC_R_SUCCESS) {
 			rbtdbiter->new_origin = ISC_TRUE;
@@ -6210,6 +7809,7 @@ dbiterator_seek(dns_dbiterator_t *iterator, dns_name_t *name) {
 	dns_name_t *iname, *origin;
 
 	if (rbtdbiter->result != ISC_R_SUCCESS &&
+	    rbtdbiter->result != ISC_R_NOTFOUND &&
 	    rbtdbiter->result != ISC_R_NOMORE)
 		return (rbtdbiter->result);
 
@@ -6221,22 +7821,74 @@ dbiterator_seek(dns_dbiterator_t *iterator, dns_name_t *name) {
 	iname = dns_fixedname_name(&rbtdbiter->name);
 	origin = dns_fixedname_name(&rbtdbiter->origin);
 	dns_rbtnodechain_reset(&rbtdbiter->chain);
+	dns_rbtnodechain_reset(&rbtdbiter->nsec3chain);
+
+	if (rbtdbiter->nsec3only) {
+		rbtdbiter->current = &rbtdbiter->nsec3chain;
+		result = dns_rbt_findnode(rbtdb->nsec3, name, NULL,
+					  &rbtdbiter->node,
+					  rbtdbiter->current,
+					  DNS_RBTFIND_EMPTYDATA, NULL, NULL);
+	} else if (rbtdbiter->nonsec3) {
+		rbtdbiter->current = &rbtdbiter->chain;
+		result = dns_rbt_findnode(rbtdb->tree, name, NULL,
+					  &rbtdbiter->node,
+					  rbtdbiter->current,
+					  DNS_RBTFIND_EMPTYDATA, NULL, NULL);
+	} else {
+		/*
+		 * Stay on main chain if not found on either chain.
+		 */
+		rbtdbiter->current = &rbtdbiter->chain;
+		result = dns_rbt_findnode(rbtdb->tree, name, NULL,
+					  &rbtdbiter->node,
+					  rbtdbiter->current,
+					  DNS_RBTFIND_EMPTYDATA, NULL, NULL);
+		if (result == DNS_R_PARTIALMATCH) {
+			dns_rbtnode_t *node = NULL;
+			result = dns_rbt_findnode(rbtdb->nsec3, name, NULL,
+						  &node, &rbtdbiter->nsec3chain,
+						  DNS_RBTFIND_EMPTYDATA,
+						  NULL, NULL);
+			if (result == ISC_R_SUCCESS) {
+				rbtdbiter->node = node;
+				rbtdbiter->current = &rbtdbiter->nsec3chain;
+			}
+		}
+	}
 
-	result = dns_rbt_findnode(rbtdb->tree, name, NULL, &rbtdbiter->node,
-				  &rbtdbiter->chain, DNS_RBTFIND_EMPTYDATA,
-				  NULL, NULL);
+#if 1
 	if (result == ISC_R_SUCCESS) {
-		result = dns_rbtnodechain_current(&rbtdbiter->chain, iname,
+		result = dns_rbtnodechain_current(rbtdbiter->current, iname,
 						  origin, NULL);
 		if (result == ISC_R_SUCCESS) {
 			rbtdbiter->new_origin = ISC_TRUE;
 			reference_iter_node(rbtdbiter);
 		}
-
-	} else if (result == DNS_R_PARTIALMATCH)
+	} else if (result == DNS_R_PARTIALMATCH) {
 		result = ISC_R_NOTFOUND;
+		rbtdbiter->node = NULL;
+	}
 
 	rbtdbiter->result = result;
+#else
+	if (result == ISC_R_SUCCESS || result == DNS_R_PARTIALMATCH) {
+		isc_result_t tresult;
+		tresult = dns_rbtnodechain_current(rbtdbiter->current, iname,
+						   origin, NULL);
+		if (tresult == ISC_R_SUCCESS) {
+			rbtdbiter->new_origin = ISC_TRUE;
+			reference_iter_node(rbtdbiter);
+		} else {
+			result = tresult;
+			rbtdbiter->node = NULL;
+		}
+	} else
+		rbtdbiter->node = NULL;
+
+	rbtdbiter->result = (result == DNS_R_PARTIALMATCH) ?
+			    ISC_R_SUCCESS : result;
+#endif
 
 	return (result);
 }
@@ -6246,6 +7898,7 @@ dbiterator_prev(dns_dbiterator_t *iterator) {
 	isc_result_t result;
 	rbtdb_dbiterator_t *rbtdbiter = (rbtdb_dbiterator_t *)iterator;
 	dns_name_t *name, *origin;
+	dns_rbtdb_t *rbtdb = (dns_rbtdb_t *)iterator->db;
 
 	REQUIRE(rbtdbiter->node != NULL);
 
@@ -6257,13 +7910,23 @@ dbiterator_prev(dns_dbiterator_t *iterator) {
 
 	name = dns_fixedname_name(&rbtdbiter->name);
 	origin = dns_fixedname_name(&rbtdbiter->origin);
-	result = dns_rbtnodechain_prev(&rbtdbiter->chain, name, origin);
+	result = dns_rbtnodechain_prev(rbtdbiter->current, name, origin);
+	if (result == ISC_R_NOMORE && !rbtdbiter->nsec3only &&
+	    !rbtdbiter->nonsec3 &&
+	    &rbtdbiter->nsec3chain == rbtdbiter->current) {
+		rbtdbiter->current = &rbtdbiter->chain;
+		dns_rbtnodechain_reset(rbtdbiter->current);
+		result = dns_rbtnodechain_last(rbtdbiter->current, rbtdb->tree,
+					       name, origin);
+		if (result == ISC_R_NOTFOUND)
+			result = ISC_R_NOMORE;
+	}
 
 	dereference_iter_node(rbtdbiter);
 
 	if (result == DNS_R_NEWORIGIN || result == ISC_R_SUCCESS) {
 		rbtdbiter->new_origin = ISC_TF(result == DNS_R_NEWORIGIN);
-		result = dns_rbtnodechain_current(&rbtdbiter->chain, NULL,
+		result = dns_rbtnodechain_current(rbtdbiter->current, NULL,
 						  NULL, &rbtdbiter->node);
 	}
 
@@ -6280,6 +7943,7 @@ dbiterator_next(dns_dbiterator_t *iterator) {
 	isc_result_t result;
 	rbtdb_dbiterator_t *rbtdbiter = (rbtdb_dbiterator_t *)iterator;
 	dns_name_t *name, *origin;
+	dns_rbtdb_t *rbtdb = (dns_rbtdb_t *)iterator->db;
 
 	REQUIRE(rbtdbiter->node != NULL);
 
@@ -6291,13 +7955,22 @@ dbiterator_next(dns_dbiterator_t *iterator) {
 
 	name = dns_fixedname_name(&rbtdbiter->name);
 	origin = dns_fixedname_name(&rbtdbiter->origin);
-	result = dns_rbtnodechain_next(&rbtdbiter->chain, name, origin);
+	result = dns_rbtnodechain_next(rbtdbiter->current, name, origin);
+	if (result == ISC_R_NOMORE && !rbtdbiter->nsec3only &&
+	    !rbtdbiter->nonsec3 && &rbtdbiter->chain == rbtdbiter->current) {
+		rbtdbiter->current = &rbtdbiter->nsec3chain;
+		dns_rbtnodechain_reset(rbtdbiter->current);
+		result = dns_rbtnodechain_first(rbtdbiter->current,
+						rbtdb->nsec3, name, origin);
+		if (result == ISC_R_NOTFOUND)
+			result = ISC_R_NOMORE;
+	}
 
 	dereference_iter_node(rbtdbiter);
 
 	if (result == DNS_R_NEWORIGIN || result == ISC_R_SUCCESS) {
 		rbtdbiter->new_origin = ISC_TF(result == DNS_R_NEWORIGIN);
-		result = dns_rbtnodechain_current(&rbtdbiter->chain, NULL,
+		result = dns_rbtnodechain_current(rbtdbiter->current, NULL,
 						  NULL, &rbtdbiter->node);
 	}
 	if (result == ISC_R_SUCCESS)
@@ -6421,7 +8094,7 @@ rdataset_getadditional(dns_rdataset_t *rdataset, dns_rdatasetadditional_t type,
 {
 	dns_rbtdb_t *rbtdb = rdataset->private1;
 	dns_rbtnode_t *rbtnode = rdataset->private2;
-	unsigned char *raw = rdataset->private3;	/* RDATASLAB */
+	unsigned char *raw = rdataset->private3;        /* RDATASLAB */
 	unsigned int current_count = rdataset->privateuint4;
 	unsigned int count;
 	rdatasetheader_t *header;
@@ -6567,7 +8240,7 @@ rdataset_setadditional(dns_rdataset_t *rdataset, dns_rdatasetadditional_t type,
 {
 	dns_rbtdb_t *rbtdb = rdataset->private1;
 	dns_rbtnode_t *rbtnode = rdataset->private2;
-	unsigned char *raw = rdataset->private3;	/* RDATASLAB */
+	unsigned char *raw = rdataset->private3;        /* RDATASLAB */
 	unsigned int current_count = rdataset->privateuint4;
 	rdatasetheader_t *header;
 	unsigned int total_count, count;
@@ -6673,7 +8346,7 @@ rdataset_setadditional(dns_rdataset_t *rdataset, dns_rdatasetadditional_t type,
 
 	return (ISC_R_SUCCESS);
 
-  fail:
+ fail:
 	if (newcbarg != NULL) {
 		if (newentry != NULL) {
 			acache_cancelentry(rbtdb->common.mctx, newentry,
@@ -6696,7 +8369,7 @@ rdataset_putadditional(dns_acache_t *acache, dns_rdataset_t *rdataset,
 {
 	dns_rbtdb_t *rbtdb = rdataset->private1;
 	dns_rbtnode_t *rbtnode = rdataset->private2;
-	unsigned char *raw = rdataset->private3;	/* RDATASLAB */
+	unsigned char *raw = rdataset->private3;        /* RDATASLAB */
 	unsigned int current_count = rdataset->privateuint4;
 	rdatasetheader_t *header;
 	nodelock_t *nodelock;
@@ -6705,7 +8378,7 @@ rdataset_putadditional(dns_acache_t *acache, dns_rdataset_t *rdataset,
 	dns_acacheentry_t *entry;
 	acache_cbarg_t *cbarg;
 
-	UNUSED(qtype);		/* we do not use this value at least for now */
+	UNUSED(qtype);          /* we do not use this value at least for now */
 	UNUSED(acache);
 
 	if (type == dns_rdatasetadditional_fromcache)
@@ -6752,9 +8425,159 @@ rdataset_putadditional(dns_acache_t *acache, dns_rdataset_t *rdataset,
 	NODE_UNLOCK(nodelock, isc_rwlocktype_write);
 
 	if (entry != NULL) {
-		acache_cancelentry(rbtdb->common.mctx, entry, &cbarg);
+		if (cbarg != NULL)
+			acache_cancelentry(rbtdb->common.mctx, entry, &cbarg);
 		dns_acache_detachentry(&entry);
 	}
 
 	return (ISC_R_SUCCESS);
 }
+
+/*%
+ * Routines for LRU-based cache management.
+ */
+
+/*%
+ * See if a given cache entry that is being reused needs to be updated
+ * in the LRU-list.  From the LRU management point of view, this function is
+ * expected to return true for almost all cases.  When used with threads,
+ * however, this may cause a non-negligible performance penalty because a
+ * writer lock will have to be acquired before updating the list.
+ * If DNS_RBTDB_LIMITLRUUPDATE is defined to be non 0 at compilation time, this
+ * function returns true if the entry has not been updated for some period of
+ * time.  We differentiate the NS or glue address case and the others since
+ * experiments have shown that the former tends to be accessed relatively
+ * infrequently and the cost of cache miss is higher (e.g., a missing NS records
+ * may cause external queries at a higher level zone, involving more
+ * transactions).
+ *
+ * Caller must hold the node (read or write) lock.
+ */
+static inline isc_boolean_t
+need_headerupdate(rdatasetheader_t *header, isc_stdtime_t now) {
+	if ((header->attributes &
+	     (RDATASET_ATTR_NONEXISTENT|RDATASET_ATTR_STALE)) != 0)
+		return (ISC_FALSE);
+
+#if DNS_RBTDB_LIMITLRUUPDATE
+	if (header->type == dns_rdatatype_ns ||
+	    (header->trust == dns_trust_glue &&
+	     (header->type == dns_rdatatype_a ||
+	      header->type == dns_rdatatype_aaaa))) {
+		/*
+		 * Glue records are updated if at least 60 seconds have passed
+		 * since the previous update time.
+		 */
+		return (header->last_used + 60 <= now);
+	}
+
+	/* Other records are updated if 5 minutes have passed. */
+	return (header->last_used + 300 <= now);
+#else
+	UNUSED(now);
+
+	return (ISC_TRUE);
+#endif
+}
+
+/*%
+ * Update the timestamp of a given cache entry and move it to the head
+ * of the corresponding LRU list.
+ *
+ * Caller must hold the node (write) lock.
+ *
+ * Note that the we do NOT touch the heap here, as the TTL has not changed.
+ */
+static void
+update_header(dns_rbtdb_t *rbtdb, rdatasetheader_t *header,
+	      isc_stdtime_t now)
+{
+	INSIST(IS_CACHE(rbtdb));
+
+	/* To be checked: can we really assume this? XXXMLG */
+	INSIST(ISC_LINK_LINKED(header, lru_link));
+
+	ISC_LIST_UNLINK(rbtdb->rdatasets[header->node->locknum],
+			header, lru_link);
+	header->last_used = now;
+	ISC_LIST_PREPEND(rbtdb->rdatasets[header->node->locknum],
+			 header, lru_link);
+}
+
+/*%
+ * Purge some expired and/or stale (i.e. unused for some period) cache entries
+ * under an overmem condition.  To recover from this condition quickly, up to
+ * 2 entries will be purged.  This process is triggered while adding a new
+ * entry, and we specifically avoid purging entries in the same LRU bucket as
+ * the one to which the new entry will belong.  Otherwise, we might purge
+ * entries of the same name of different RR types while adding RRsets from a
+ * single response (consider the case where we're adding A and AAAA glue records
+ * of the same NS name).
+ */
+static void
+overmem_purge(dns_rbtdb_t *rbtdb, unsigned int locknum_start,
+	      isc_stdtime_t now, isc_boolean_t tree_locked)
+{
+	rdatasetheader_t *header, *header_prev;
+	unsigned int locknum;
+	int purgecount = 2;
+
+	for (locknum = (locknum_start + 1) % rbtdb->node_lock_count;
+	     locknum != locknum_start && purgecount > 0;
+	     locknum = (locknum + 1) % rbtdb->node_lock_count) {
+		NODE_LOCK(&rbtdb->node_locks[locknum].lock,
+			  isc_rwlocktype_write);
+
+		header = isc_heap_element(rbtdb->heaps[locknum], 1);
+		if (header && header->rdh_ttl <= now - RBTDB_VIRTUAL) {
+			expire_header(rbtdb, header, tree_locked);
+			purgecount--;
+		}
+
+		for (header = ISC_LIST_TAIL(rbtdb->rdatasets[locknum]);
+		     header != NULL && purgecount > 0;
+		     header = header_prev) {
+			header_prev = ISC_LIST_PREV(header, lru_link);
+			/*
+			 * Unlink the entry at this point to avoid checking it
+			 * again even if it's currently used someone else and
+			 * cannot be purged at this moment.  This entry won't be
+			 * referenced any more (so unlinking is safe) since the
+			 * TTL was reset to 0.
+			 */
+			ISC_LIST_UNLINK(rbtdb->rdatasets[locknum], header,
+					lru_link);
+			expire_header(rbtdb, header, tree_locked);
+			purgecount--;
+		}
+
+		NODE_UNLOCK(&rbtdb->node_locks[locknum].lock,
+				    isc_rwlocktype_write);
+	}
+}
+
+static void
+expire_header(dns_rbtdb_t *rbtdb, rdatasetheader_t *header,
+	      isc_boolean_t tree_locked)
+{
+	set_ttl(rbtdb, header, 0);
+	header->attributes |= RDATASET_ATTR_STALE;
+	header->node->dirty = 1;
+
+	/*
+	 * Caller must hold the node (write) lock.
+	 */
+
+	if (dns_rbtnode_refcurrent(header->node) == 0) {
+		/*
+		 * If no one else is using the node, we can clean it up now.
+		 * We first need to gain a new reference to the node to meet a
+		 * requirement of decrement_reference().
+		 */
+		new_reference(rbtdb, header->node);
+		decrement_reference(rbtdb, header->node, 0,
+				    isc_rwlocktype_write,
+				    tree_locked ? isc_rwlocktype_write :
+				    isc_rwlocktype_none, ISC_FALSE);
+	}
+}
diff --git a/contrib/bind9/lib/dns/rbtdb.h b/contrib/bind9/lib/dns/rbtdb.h
index f9fb50b..b024d13 100644
--- a/contrib/bind9/lib/dns/rbtdb.h
+++ b/contrib/bind9/lib/dns/rbtdb.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rbtdb.h,v 1.14.18.2 2005/04/29 00:16:02 marka Exp $ */
+/* $Id: rbtdb.h,v 1.18 2007/06/19 23:47:16 tbox Exp $ */
 
 #ifndef DNS_RBTDB_H
 #define DNS_RBTDB_H 1
diff --git a/contrib/bind9/lib/dns/rbtdb64.c b/contrib/bind9/lib/dns/rbtdb64.c
index 773fe91..5e325fa 100644
--- a/contrib/bind9/lib/dns/rbtdb64.c
+++ b/contrib/bind9/lib/dns/rbtdb64.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rbtdb64.c,v 1.7.18.2 2005/04/29 00:16:02 marka Exp $ */
+/* $Id: rbtdb64.c,v 1.11 2007/06/19 23:47:16 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/dns/rbtdb64.h b/contrib/bind9/lib/dns/rbtdb64.h
index e2de45c..fe11622 100644
--- a/contrib/bind9/lib/dns/rbtdb64.h
+++ b/contrib/bind9/lib/dns/rbtdb64.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rbtdb64.h,v 1.13.18.2 2005/04/29 00:16:02 marka Exp $ */
+/* $Id: rbtdb64.h,v 1.17 2007/06/19 23:47:16 tbox Exp $ */
 
 #ifndef DNS_RBTDB64_H
 #define DNS_RBTDB64_H 1
diff --git a/contrib/bind9/lib/dns/rcode.c b/contrib/bind9/lib/dns/rcode.c
index f61aa35..58ade85 100644
--- a/contrib/bind9/lib/dns/rcode.c
+++ b/contrib/bind9/lib/dns/rcode.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rcode.c,v 1.2.18.2 2006/01/27 23:57:44 marka Exp $ */
+/* $Id: rcode.c,v 1.8 2008/09/25 04:02:38 tbox Exp $ */
 
 #include <config.h>
 #include <ctype.h>
@@ -66,7 +66,7 @@
 #define ERCODENAMES \
 	/* extended rcodes */ \
 	{ dns_rcode_badvers, "BADVERS", 0}, \
-	{ 0, NULL, 0 } 
+	{ 0, NULL, 0 }
 
 #define TSIGRCODENAMES \
 	/* extended rcodes */ \
@@ -96,8 +96,10 @@
 	{ DNS_KEYALG_RSAMD5, "RSA", 0 }, \
 	{ DNS_KEYALG_DH, "DH", 0 }, \
 	{ DNS_KEYALG_DSA, "DSA", 0 }, \
+	{ DNS_KEYALG_NSEC3DSA, "NSEC3DSA", 0 }, \
 	{ DNS_KEYALG_ECC, "ECC", 0 }, \
 	{ DNS_KEYALG_RSASHA1, "RSASHA1", 0 }, \
+	{ DNS_KEYALG_NSEC3RSASHA1, "NSEC3RSASHA1", 0 }, \
 	{ DNS_KEYALG_INDIRECT, "INDIRECT", 0 }, \
 	{ DNS_KEYALG_PRIVATEDNS, "PRIVATEDNS", 0 }, \
 	{ DNS_KEYALG_PRIVATEOID, "PRIVATEOID", 0 }, \
@@ -114,6 +116,10 @@
 	{ 255,    "ALL", 0 }, \
 	{ 0, NULL, 0}
 
+#define HASHALGNAMES \
+	{ 1, "SHA-1", 0 }, \
+	{ 0, NULL, 0 }
+
 struct tbl {
 	unsigned int    value;
 	const char      *name;
@@ -125,6 +131,7 @@ static struct tbl tsigrcodes[] = { RCODENAMES TSIGRCODENAMES };
 static struct tbl certs[] = { CERTNAMES };
 static struct tbl secalgs[] = { SECALGNAMES };
 static struct tbl secprotos[] = { SECPROTONAMES };
+static struct tbl hashalgs[] = { HASHALGNAMES };
 
 static struct keyflag {
 	const char *name;
@@ -238,7 +245,7 @@ dns_mnemonic_fromtext(unsigned int *valuep, isc_textregion_t *source,
 
 static isc_result_t
 dns_mnemonic_totext(unsigned int value, isc_buffer_t *target,
-		    struct tbl *table) 
+		    struct tbl *table)
 {
 	int i = 0;
 	char buf[sizeof("4294967296")];
@@ -271,7 +278,7 @@ dns_tsigrcode_fromtext(dns_rcode_t *rcodep, isc_textregion_t *source) {
 	RETERR(dns_mnemonic_fromtext(&value, source, tsigrcodes, 0xffff));
 	*rcodep = value;
 	return (ISC_R_SUCCESS);
-} 
+}
 
 isc_result_t
 dns_tsigrcode_totext(dns_rcode_t rcode, isc_buffer_t *target) {
@@ -318,6 +325,14 @@ dns_secproto_totext(dns_secproto_t secproto, isc_buffer_t *target) {
 }
 
 isc_result_t
+dns_hashalg_fromtext(unsigned char *hashalg, isc_textregion_t *source) {
+	unsigned int value;
+	RETERR(dns_mnemonic_fromtext(&value, source, hashalgs, 0xff));
+	*hashalg = value;
+	return (ISC_R_SUCCESS);
+}
+
+isc_result_t
 dns_keyflags_fromtext(dns_keyflags_t *flagsp, isc_textregion_t *source)
 {
 	isc_result_t result;
diff --git a/contrib/bind9/lib/dns/rdata.c b/contrib/bind9/lib/dns/rdata.c
index 5641777..ab9df8b 100644
--- a/contrib/bind9/lib/dns/rdata.c
+++ b/contrib/bind9/lib/dns/rdata.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdata.c,v 1.184.18.9 2006/07/21 02:05:57 marka Exp $ */
+/* $Id: rdata.c,v 1.199.50.2 2009/02/16 23:47:15 tbox Exp $ */
 
 /*! \file */
 
@@ -111,7 +111,7 @@ typedef struct dns_rdata_textctx {
 	dns_name_t *origin;	/*%< Current origin, or NULL. */
 	unsigned int flags;	/*%< DNS_STYLEFLAG_*  */
 	unsigned int width;	/*%< Width of rdata column. */
-  	const char *linebreak;	/*%< Line break string. */
+	const char *linebreak;	/*%< Line break string. */
 } dns_rdata_textctx_t;
 
 static isc_result_t
@@ -162,6 +162,9 @@ uint16_fromregion(isc_region_t *region);
 static isc_uint8_t
 uint8_fromregion(isc_region_t *region);
 
+static isc_uint8_t
+uint8_consume_fromregion(isc_region_t *region);
+
 static isc_result_t
 mem_tobuffer(isc_buffer_t *target, void *base, unsigned int length);
 
@@ -201,6 +204,9 @@ static void
 warn_badmx(isc_token_t *token, isc_lex_t *lexer,
 	   dns_rdatacallbacks_t *callbacks);
 
+static isc_uint16_t
+uint16_consume_fromregion(isc_region_t *region);
+
 static inline int
 getquad(const void *src, struct in_addr *dst,
 	isc_lex_t *lexer, dns_rdatacallbacks_t *callbacks)
@@ -269,7 +275,7 @@ dns_rdata_init(dns_rdata_t *rdata) {
 	/* ISC_LIST_INIT(rdata->list); */
 }
 
-#if 0
+#if 1
 #define DNS_RDATA_INITIALIZED(rdata) \
 	((rdata)->data == NULL && (rdata)->length == 0 && \
 	 (rdata)->rdclass == 0 && (rdata)->type == 0 && (rdata)->flags == 0 && \
@@ -282,8 +288,9 @@ dns_rdata_init(dns_rdata_t *rdata) {
 #define DNS_RDATA_INITIALIZED(rdata) ISC_TRUE
 #endif
 #endif
+
 #define DNS_RDATA_VALIDFLAGS(rdata) \
-	(((rdata)->flags & ~DNS_RDATA_UPDATE) == 0)
+	(((rdata)->flags & ~(DNS_RDATA_UPDATE|DNS_RDATA_OFFLINE)) == 0)
 
 void
 dns_rdata_reset(dns_rdata_t *rdata) {
@@ -532,7 +539,7 @@ unknown_fromtext(dns_rdataclass_t rdclass, dns_rdatatype_t type,
 	result = isc_buffer_allocate(mctx, &buf, token.value.as_ulong);
 	if (result != ISC_R_SUCCESS)
 		return (result);
-	
+
 	result = isc_hex_tobuffer(lexer, buf,
 				  (unsigned int)token.value.as_ulong);
 	if (result != ISC_R_SUCCESS)
@@ -728,7 +735,7 @@ dns_rdata_totext(dns_rdata_t *rdata, dns_name_t *origin, isc_buffer_t *target)
 isc_result_t
 dns_rdata_tofmttext(dns_rdata_t *rdata, dns_name_t *origin,
 		    unsigned int flags, unsigned int width,
-		    char *linebreak, isc_buffer_t *target)
+		    const char *linebreak, isc_buffer_t *target)
 {
 	dns_rdata_textctx_t tctx;
 
@@ -901,7 +908,7 @@ dns_rdatatype_fromtext(dns_rdatatype_t *typep, isc_textregion_t *source) {
 	hash = ((a + n) * b) % 256;
 
 	/*
-	 * This switch block is inlined via #define, and will use "return"
+	 * This switch block is inlined via \#define, and will use "return"
 	 * to return a result to the caller if it is a valid (known)
 	 * rdatatype name.
 	 */
@@ -1234,6 +1241,14 @@ uint32_fromregion(isc_region_t *region) {
 }
 
 static isc_uint16_t
+uint16_consume_fromregion(isc_region_t *region) {
+	isc_uint16_t r = uint16_fromregion(region);
+
+	isc_region_consume(region, 2);
+	return r;
+}
+
+static isc_uint16_t
 uint16_fromregion(isc_region_t *region) {
 
 	REQUIRE(region->length >= 2);
@@ -1249,6 +1264,14 @@ uint8_fromregion(isc_region_t *region) {
 	return (region->base[0]);
 }
 
+static isc_uint8_t
+uint8_consume_fromregion(isc_region_t *region) {
+	isc_uint8_t r = uint8_fromregion(region);
+
+	isc_region_consume(region, 1);
+	return r;
+}
+
 static isc_result_t
 mem_tobuffer(isc_buffer_t *target, void *base, unsigned int length) {
 	isc_region_t tr;
@@ -1504,16 +1527,16 @@ byte_btoa(int c, isc_buffer_t *target, struct state *state) {
 			   /*
 			    * Because some don't support u_long.
 			    */
-		    	tmp = 32;
-		    	tmpword -= (isc_int32_t)(85 * 85 * 85 * 85 * 32);
+			tmp = 32;
+			tmpword -= (isc_int32_t)(85 * 85 * 85 * 85 * 32);
 		    }
 		    if (tmpword < 0) {
-		    	tmp = 64;
-		    	tmpword -= (isc_int32_t)(85 * 85 * 85 * 85 * 32);
+			tmp = 64;
+			tmpword -= (isc_int32_t)(85 * 85 * 85 * 85 * 32);
 		    }
 			if (tr.length < 5)
 				return (ISC_R_NOSPACE);
-		    	tr.base[0] = atob_digits[(tmpword /
+			tr.base[0] = atob_digits[(tmpword /
 					      (isc_int32_t)(85 * 85 * 85 * 85))
 						+ tmp];
 			tmpword %= (isc_int32_t)(85 * 85 * 85 * 85);
@@ -1596,7 +1619,7 @@ warn_badmx(isc_token_t *token, isc_lex_t *lexer,
 	if (lexer != NULL) {
 		file = isc_lex_getsourcename(lexer);
 		line = isc_lex_getsourceline(lexer);
-		(*callbacks->warn)(callbacks, "%s:%u: warning: '%s': %s", 
+		(*callbacks->warn)(callbacks, "%s:%u: warning: '%s': %s",
 				   file, line, DNS_AS_STR(*token),
 				   dns_result_totext(DNS_R_MXISADDRESS));
 	}
@@ -1609,12 +1632,12 @@ warn_badname(dns_name_t *name, isc_lex_t *lexer,
 	const char *file;
 	unsigned long line;
 	char namebuf[DNS_NAME_FORMATSIZE];
-	
+
 	if (lexer != NULL) {
 		file = isc_lex_getsourcename(lexer);
 		line = isc_lex_getsourceline(lexer);
 		dns_name_format(name, namebuf, sizeof(namebuf));
-		(*callbacks->warn)(callbacks, "%s:%u: warning: %s: %s", 
+		(*callbacks->warn)(callbacks, "%s:%u: warning: %s: %s",
 				   file, line, namebuf,
 				   dns_result_totext(DNS_R_BADNAME));
 	}
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 4fdadd3..3121f78 100644
--- a/contrib/bind9/lib/dns/rdata/any_255/tsig_250.c
+++ b/contrib/bind9/lib/dns/rdata/any_255/tsig_250.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: tsig_250.c,v 1.59.18.2 2005/03/20 22:34:32 marka Exp $ */
+/* $Id: tsig_250.c,v 1.63 2007/06/19 23:47:17 tbox Exp $ */
 
 /* Reviewed: Thu Mar 16 13:39:43 PST 2000 by gson */
 
diff --git a/contrib/bind9/lib/dns/rdata/any_255/tsig_250.h b/contrib/bind9/lib/dns/rdata/any_255/tsig_250.h
index b84a715..0c01667 100644
--- a/contrib/bind9/lib/dns/rdata/any_255/tsig_250.h
+++ b/contrib/bind9/lib/dns/rdata/any_255/tsig_250.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: tsig_250.h,v 1.21.18.2 2005/04/29 00:16:29 marka Exp $ */
+/* $Id: tsig_250.h,v 1.25 2007/06/19 23:47:17 tbox Exp $ */
 
 #ifndef ANY_255_TSIG_250_H
 #define ANY_255_TSIG_250_H 1
diff --git a/contrib/bind9/lib/dns/rdata/ch_3/a_1.c b/contrib/bind9/lib/dns/rdata/ch_3/a_1.c
index 6a9b70c..78d4ecd 100644
--- a/contrib/bind9/lib/dns/rdata/ch_3/a_1.c
+++ b/contrib/bind9/lib/dns/rdata/ch_3/a_1.c
@@ -1,7 +1,7 @@
 /*
- * Copyright (C) 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: a_1.c,v 1.2.2.3 2005/08/23 04:10:09 marka Exp $ */
+/* $Id: a_1.c,v 1.6 2007/06/19 23:47:17 tbox Exp $ */
 
 /* by Bjorn.Victor@it.uu.se, 2005-05-07 */
 /* Based on generic/soa_6.c and generic/mx_15.c */
diff --git a/contrib/bind9/lib/dns/rdata/ch_3/a_1.h b/contrib/bind9/lib/dns/rdata/ch_3/a_1.h
index 9f67977..a279d0e 100644
--- a/contrib/bind9/lib/dns/rdata/ch_3/a_1.h
+++ b/contrib/bind9/lib/dns/rdata/ch_3/a_1.h
@@ -1,7 +1,7 @@
 /*
- * Copyright (C) 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: a_1.h,v 1.2.2.2 2005/06/05 00:02:22 marka Exp $ */
+/* $Id: a_1.h,v 1.5 2007/06/19 23:47:17 tbox Exp $ */
 
 /* by Bjorn.Victor@it.uu.se, 2005-05-07 */
 /* Based on generic/mx_15.h */
diff --git a/contrib/bind9/lib/dns/rdata/generic/afsdb_18.c b/contrib/bind9/lib/dns/rdata/generic/afsdb_18.c
index 24a63e6..2230efb 100644
--- a/contrib/bind9/lib/dns/rdata/generic/afsdb_18.c
+++ b/contrib/bind9/lib/dns/rdata/generic/afsdb_18.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: afsdb_18.c,v 1.43.18.2 2005/04/29 00:16:30 marka Exp $ */
+/* $Id: afsdb_18.c,v 1.47 2007/06/19 23:47:17 tbox Exp $ */
 
 /* Reviewed: Wed Mar 15 14:59:00 PST 2000 by explorer */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/afsdb_18.h b/contrib/bind9/lib/dns/rdata/generic/afsdb_18.h
index 1532da1..ccccc11 100644
--- a/contrib/bind9/lib/dns/rdata/generic/afsdb_18.h
+++ b/contrib/bind9/lib/dns/rdata/generic/afsdb_18.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,7 +18,7 @@
 #ifndef GENERIC_AFSDB_18_H
 #define GENERIC_AFSDB_18_H 1
 
-/* $Id: afsdb_18.h,v 1.16.18.2 2005/04/29 00:16:30 marka Exp $ */
+/* $Id: afsdb_18.h,v 1.20 2007/06/19 23:47:17 tbox Exp $ */
 
 /*!
  *  \brief Per RFC1183 */
diff --git a/contrib/bind9/lib/dns/rdata/generic/cert_37.c b/contrib/bind9/lib/dns/rdata/generic/cert_37.c
index c6ba3a8..2c45230 100644
--- a/contrib/bind9/lib/dns/rdata/generic/cert_37.c
+++ b/contrib/bind9/lib/dns/rdata/generic/cert_37.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: cert_37.c,v 1.46.18.2 2005/04/29 00:16:30 marka Exp $ */
+/* $Id: cert_37.c,v 1.50 2007/06/19 23:47:17 tbox Exp $ */
 
 /* Reviewed: Wed Mar 15 21:14:32 EST 2000 by tale */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/cert_37.h b/contrib/bind9/lib/dns/rdata/generic/cert_37.h
index 2af25b7..ddfaa4f 100644
--- a/contrib/bind9/lib/dns/rdata/generic/cert_37.h
+++ b/contrib/bind9/lib/dns/rdata/generic/cert_37.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: cert_37.h,v 1.16.18.2 2005/04/29 00:16:31 marka Exp $ */
+/* $Id: cert_37.h,v 1.20 2007/06/19 23:47:17 tbox Exp $ */
 
 #ifndef GENERIC_CERT_37_H
 #define GENERIC_CERT_37_H 1
diff --git a/contrib/bind9/lib/dns/rdata/generic/cname_5.c b/contrib/bind9/lib/dns/rdata/generic/cname_5.c
index 6ea1db1..28c3d60 100644
--- a/contrib/bind9/lib/dns/rdata/generic/cname_5.c
+++ b/contrib/bind9/lib/dns/rdata/generic/cname_5.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: cname_5.c,v 1.45 2004/03/05 05:10:10 marka Exp $ */
+/* $Id: cname_5.c,v 1.47 2007/06/19 23:47:17 tbox Exp $ */
 
 /* reviewed: Wed Mar 15 16:48:45 PST 2000 by brister */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/cname_5.h b/contrib/bind9/lib/dns/rdata/generic/cname_5.h
index dc24383..516f8d3 100644
--- a/contrib/bind9/lib/dns/rdata/generic/cname_5.h
+++ b/contrib/bind9/lib/dns/rdata/generic/cname_5.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: cname_5.h,v 1.24 2004/03/05 05:10:10 marka Exp $ */
+/* $Id: cname_5.h,v 1.26 2007/06/19 23:47:17 tbox Exp $ */
 
 #ifndef GENERIC_CNAME_5_H
 #define GENERIC_CNAME_5_H 1
diff --git a/contrib/bind9/lib/dns/rdata/generic/dlv_32769.c b/contrib/bind9/lib/dns/rdata/generic/dlv_32769.c
index c0bb348..957f038 100644
--- a/contrib/bind9/lib/dns/rdata/generic/dlv_32769.c
+++ b/contrib/bind9/lib/dns/rdata/generic/dlv_32769.c
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dlv_32769.c,v 1.2.2.5 2007/08/28 07:20:06 tbox Exp $ */
+/* $Id: dlv_32769.c,v 1.6 2007/06/18 23:47:43 tbox Exp $ */
 
 /* draft-ietf-dnsext-delegation-signer-05.txt */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/dlv_32769.h b/contrib/bind9/lib/dns/rdata/generic/dlv_32769.h
index bd03c73..2313c57 100644
--- a/contrib/bind9/lib/dns/rdata/generic/dlv_32769.h
+++ b/contrib/bind9/lib/dns/rdata/generic/dlv_32769.h
@@ -1,7 +1,7 @@
 /*
- * Copyright (C) 2004, 2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2006, 2007  Internet Systems Consortium, Inc. ("ISC")
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dlv_32769.h,v 1.2.2.2 2006/02/19 06:50:47 marka Exp $ */
+/* $Id: dlv_32769.h,v 1.5 2007/06/19 23:47:17 tbox Exp $ */
 
 /* draft-ietf-dnsext-delegation-signer-05.txt */
 #ifndef GENERIC_DLV_32769_H
diff --git a/contrib/bind9/lib/dns/rdata/generic/dname_39.c b/contrib/bind9/lib/dns/rdata/generic/dname_39.c
index ed3133c..c399f1e 100644
--- a/contrib/bind9/lib/dns/rdata/generic/dname_39.c
+++ b/contrib/bind9/lib/dns/rdata/generic/dname_39.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dname_39.c,v 1.36 2004/03/05 05:10:10 marka Exp $ */
+/* $Id: dname_39.c,v 1.38 2007/06/19 23:47:17 tbox Exp $ */
 
 /* Reviewed: Wed Mar 15 16:52:38 PST 2000 by explorer */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/dname_39.h b/contrib/bind9/lib/dns/rdata/generic/dname_39.h
index 93ec709..f8aca27 100644
--- a/contrib/bind9/lib/dns/rdata/generic/dname_39.h
+++ b/contrib/bind9/lib/dns/rdata/generic/dname_39.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,7 +18,7 @@
 #ifndef GENERIC_DNAME_39_H
 #define GENERIC_DNAME_39_H 1
 
-/* $Id: dname_39.h,v 1.17.18.2 2005/04/29 00:16:31 marka Exp $ */
+/* $Id: dname_39.h,v 1.21 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! 
  *  \brief per RFC2672 */
diff --git a/contrib/bind9/lib/dns/rdata/generic/dnskey_48.c b/contrib/bind9/lib/dns/rdata/generic/dnskey_48.c
index 5a4e453..2e11cba 100644
--- a/contrib/bind9/lib/dns/rdata/generic/dnskey_48.c
+++ b/contrib/bind9/lib/dns/rdata/generic/dnskey_48.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dnskey_48.c,v 1.4.20.2 2005/04/29 00:16:31 marka Exp $ */
+/* $Id: dnskey_48.c,v 1.8 2007/06/19 23:47:17 tbox Exp $ */
 
 /*
  * Reviewed: Wed Mar 15 16:47:10 PST 2000 by halley.
diff --git a/contrib/bind9/lib/dns/rdata/generic/dnskey_48.h b/contrib/bind9/lib/dns/rdata/generic/dnskey_48.h
index 9b3d262..ce88cd1 100644
--- a/contrib/bind9/lib/dns/rdata/generic/dnskey_48.h
+++ b/contrib/bind9/lib/dns/rdata/generic/dnskey_48.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,7 +18,7 @@
 #ifndef GENERIC_DNSKEY_48_H
 #define GENERIC_DNSKEY_48_H 1
 
-/* $Id: dnskey_48.h,v 1.3.20.2 2005/04/29 00:16:32 marka Exp $ */
+/* $Id: dnskey_48.h,v 1.7 2007/06/19 23:47:17 tbox Exp $ */
 
 /*!
  *  \brief per RFC2535 */
diff --git a/contrib/bind9/lib/dns/rdata/generic/ds_43.c b/contrib/bind9/lib/dns/rdata/generic/ds_43.c
index 212a56f..08e5d5f 100644
--- a/contrib/bind9/lib/dns/rdata/generic/ds_43.c
+++ b/contrib/bind9/lib/dns/rdata/generic/ds_43.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ds_43.c,v 1.7.18.5 2007/08/28 07:20:06 tbox Exp $ */
+/* $Id: ds_43.c,v 1.12 2007/06/18 23:47:43 tbox Exp $ */
 
 /* draft-ietf-dnsext-delegation-signer-05.txt */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/ds_43.h b/contrib/bind9/lib/dns/rdata/generic/ds_43.h
index dae7bef..3a409a1 100644
--- a/contrib/bind9/lib/dns/rdata/generic/ds_43.h
+++ b/contrib/bind9/lib/dns/rdata/generic/ds_43.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ds_43.h,v 1.3.20.2 2005/04/29 00:16:32 marka Exp $ */
+/* $Id: ds_43.h,v 1.7 2007/06/19 23:47:17 tbox Exp $ */
 
 #ifndef GENERIC_DS_43_H
 #define GENERIC_DS_43_H 1
diff --git a/contrib/bind9/lib/dns/rdata/generic/gpos_27.c b/contrib/bind9/lib/dns/rdata/generic/gpos_27.c
index 9b37905..18effb5 100644
--- a/contrib/bind9/lib/dns/rdata/generic/gpos_27.c
+++ b/contrib/bind9/lib/dns/rdata/generic/gpos_27.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: gpos_27.c,v 1.37.18.2 2005/04/29 00:16:32 marka Exp $ */
+/* $Id: gpos_27.c,v 1.41 2007/06/19 23:47:17 tbox Exp $ */
 
 /* reviewed: Wed Mar 15 16:48:45 PST 2000 by brister */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/gpos_27.h b/contrib/bind9/lib/dns/rdata/generic/gpos_27.h
index 4949bde..f5df4fa 100644
--- a/contrib/bind9/lib/dns/rdata/generic/gpos_27.h
+++ b/contrib/bind9/lib/dns/rdata/generic/gpos_27.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,7 +18,7 @@
 #ifndef GENERIC_GPOS_27_H
 #define GENERIC_GPOS_27_H 1
 
-/* $Id: gpos_27.h,v 1.13.18.2 2005/04/29 00:16:32 marka Exp $ */
+/* $Id: gpos_27.h,v 1.17 2007/06/19 23:47:17 tbox Exp $ */
 
 /*!
  *  \brief per RFC1712 */
diff --git a/contrib/bind9/lib/dns/rdata/generic/hinfo_13.c b/contrib/bind9/lib/dns/rdata/generic/hinfo_13.c
index 70c433c..5321357 100644
--- a/contrib/bind9/lib/dns/rdata/generic/hinfo_13.c
+++ b/contrib/bind9/lib/dns/rdata/generic/hinfo_13.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: hinfo_13.c,v 1.42 2004/03/05 05:10:11 marka Exp $ */
+/* $Id: hinfo_13.c,v 1.44 2007/06/19 23:47:17 tbox Exp $ */
 
 /*
  * Reviewed: Wed Mar 15 16:47:10 PST 2000 by halley.
diff --git a/contrib/bind9/lib/dns/rdata/generic/hinfo_13.h b/contrib/bind9/lib/dns/rdata/generic/hinfo_13.h
index e542c48..66766df 100644
--- a/contrib/bind9/lib/dns/rdata/generic/hinfo_13.h
+++ b/contrib/bind9/lib/dns/rdata/generic/hinfo_13.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,7 +18,7 @@
 #ifndef GENERIC_HINFO_13_H
 #define GENERIC_HINFO_13_H 1
 
-/* $Id: hinfo_13.h,v 1.23 2004/03/05 05:10:12 marka Exp $ */
+/* $Id: hinfo_13.h,v 1.25 2007/06/19 23:47:17 tbox Exp $ */
 
 typedef struct dns_rdata_hinfo {
 	dns_rdatacommon_t	common;
diff --git a/contrib/bind9/lib/dns/rdata/generic/ipseckey_45.c b/contrib/bind9/lib/dns/rdata/generic/ipseckey_45.c
index 3c3736e..bc2b4e8 100644
--- a/contrib/bind9/lib/dns/rdata/generic/ipseckey_45.c
+++ b/contrib/bind9/lib/dns/rdata/generic/ipseckey_45.c
@@ -1,7 +1,7 @@
 /*
- * Copyright (C) 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2005, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ipseckey_45.c,v 1.2.2.1 2005/07/07 03:17:36 marka Exp $ */
+/* $Id: ipseckey_45.c,v 1.4.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef RDATA_GENERIC_IPSECKEY_45_C
 #define RDATA_GENERIC_IPSECKEY_45_C
@@ -131,15 +131,15 @@ totext_ipseckey(ARGS_TOTEXT) {
 
 	dns_name_init(&name, NULL);
 	dns_name_init(&prefix, NULL);
-	
+
 	if (rdata->data[1] > 3U)
 		return (ISC_R_NOTIMPLEMENTED);
 
-        if ((tctx->flags & DNS_STYLEFLAG_MULTILINE) != 0)
-                RETERR(str_totext("( ", target));
+	if ((tctx->flags & DNS_STYLEFLAG_MULTILINE) != 0)
+		RETERR(str_totext("( ", target));
 
 	/*
-	 * Precendence.
+	 * Precedence.
 	 */
 	dns_rdata_toregion(rdata, &region);
 	num = uint8_fromregion(&region);
@@ -198,14 +198,14 @@ totext_ipseckey(ARGS_TOTEXT) {
 					 tctx->linebreak, target));
 	}
 
-        if ((tctx->flags & DNS_STYLEFLAG_MULTILINE) != 0)
-                RETERR(str_totext(" )", target));
+	if ((tctx->flags & DNS_STYLEFLAG_MULTILINE) != 0)
+		RETERR(str_totext(" )", target));
 	return (ISC_R_SUCCESS);
 }
 
 static inline isc_result_t
 fromwire_ipseckey(ARGS_FROMWIRE) {
-        dns_name_t name;
+	dns_name_t name;
 	isc_region_t region;
 
 	REQUIRE(type == 45);
@@ -215,7 +215,7 @@ fromwire_ipseckey(ARGS_FROMWIRE) {
 
 	dns_decompress_setmethods(dctx, DNS_COMPRESS_NONE);
 
-        dns_name_init(&name, NULL);
+	dns_name_init(&name, NULL);
 
 	isc_buffer_activeregion(source, &region);
 	if (region.length < 3)
diff --git a/contrib/bind9/lib/dns/rdata/generic/ipseckey_45.h b/contrib/bind9/lib/dns/rdata/generic/ipseckey_45.h
index b766fa0..2a6201f 100644
--- a/contrib/bind9/lib/dns/rdata/generic/ipseckey_45.h
+++ b/contrib/bind9/lib/dns/rdata/generic/ipseckey_45.h
@@ -1,7 +1,7 @@
 /*
- * Copyright (C) 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ipseckey_45.h,v 1.2.2.1 2005/07/07 03:17:36 marka Exp $ */
+/* $Id: ipseckey_45.h,v 1.4 2007/06/19 23:47:17 tbox Exp $ */
 
 #ifndef GENERIC_IPSECKEY_45_H
 #define GENERIC_IPSECKEY_45_H 1
diff --git a/contrib/bind9/lib/dns/rdata/generic/isdn_20.c b/contrib/bind9/lib/dns/rdata/generic/isdn_20.c
index 1813759..d7333d1 100644
--- a/contrib/bind9/lib/dns/rdata/generic/isdn_20.c
+++ b/contrib/bind9/lib/dns/rdata/generic/isdn_20.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: isdn_20.c,v 1.34.18.2 2005/04/29 00:16:33 marka Exp $ */
+/* $Id: isdn_20.c,v 1.38 2007/06/19 23:47:17 tbox Exp $ */
 
 /* Reviewed: Wed Mar 15 16:53:11 PST 2000 by bwelling */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/isdn_20.h b/contrib/bind9/lib/dns/rdata/generic/isdn_20.h
index 6a51317..a1f65ca 100644
--- a/contrib/bind9/lib/dns/rdata/generic/isdn_20.h
+++ b/contrib/bind9/lib/dns/rdata/generic/isdn_20.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,7 +18,7 @@
 #ifndef GENERIC_ISDN_20_H
 #define GENERIC_ISDN_20_H 1
 
-/* $Id: isdn_20.h,v 1.14.18.2 2005/04/29 00:16:33 marka Exp $ */
+/* $Id: isdn_20.h,v 1.18 2007/06/19 23:47:17 tbox Exp $ */
 
 /*!
  * \brief Per RFC1183 */
diff --git a/contrib/bind9/lib/dns/rdata/generic/key_25.c b/contrib/bind9/lib/dns/rdata/generic/key_25.c
index 24dc10f..9acfe95 100644
--- a/contrib/bind9/lib/dns/rdata/generic/key_25.c
+++ b/contrib/bind9/lib/dns/rdata/generic/key_25.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: key_25.c,v 1.47.18.2 2005/04/29 00:16:33 marka Exp $ */
+/* $Id: key_25.c,v 1.51 2007/06/19 23:47:17 tbox Exp $ */
 
 /*
  * Reviewed: Wed Mar 15 16:47:10 PST 2000 by halley.
diff --git a/contrib/bind9/lib/dns/rdata/generic/key_25.h b/contrib/bind9/lib/dns/rdata/generic/key_25.h
index 03400db..bcf9cb6 100644
--- a/contrib/bind9/lib/dns/rdata/generic/key_25.h
+++ b/contrib/bind9/lib/dns/rdata/generic/key_25.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,7 +18,7 @@
 #ifndef GENERIC_KEY_25_H
 #define GENERIC_KEY_25_H 1
 
-/* $Id: key_25.h,v 1.15.18.2 2005/04/29 00:16:33 marka Exp $ */
+/* $Id: key_25.h,v 1.19 2007/06/19 23:47:17 tbox Exp $ */
 
 /*!
  * \brief Per RFC2535 */
diff --git a/contrib/bind9/lib/dns/rdata/generic/loc_29.c b/contrib/bind9/lib/dns/rdata/generic/loc_29.c
index c93ac90..a5d7f72 100644
--- a/contrib/bind9/lib/dns/rdata/generic/loc_29.c
+++ b/contrib/bind9/lib/dns/rdata/generic/loc_29.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: loc_29.c,v 1.41.18.2 2005/04/29 00:16:34 marka Exp $ */
+/* $Id: loc_29.c,v 1.45.332.4 2009/02/17 05:54:12 marka Exp $ */
 
 /* Reviewed: Wed Mar 15 18:13:09 PST 2000 by explorer */
 
@@ -482,16 +482,19 @@ totext_loc(ARGS_TOTEXT) {
 
 	/* version = sr.base[0]; */
 	size = sr.base[1];
+	INSIST((size&0x0f) < 10 && (size>>4) < 10);
 	if ((size&0x0f)> 1)
 		sprintf(sbuf, "%lum", (size>>4) * poweroften[(size&0x0f)-2]);
 	else
 		sprintf(sbuf, "0.%02lum", (size>>4) * poweroften[(size&0x0f)]);
 	hp = sr.base[2];
+	INSIST((hp&0x0f) < 10 && (hp>>4) < 10);
 	if ((hp&0x0f)> 1)
 		sprintf(hbuf, "%lum", (hp>>4) * poweroften[(hp&0x0f)-2]);
 	else
 		sprintf(hbuf, "0.%02lum", (hp>>4) * poweroften[(hp&0x0f)]);
 	vp = sr.base[3];
+	INSIST((vp&0x0f) < 10 && (vp>>4) < 10);
 	if ((vp&0x0f)> 1)
 		sprintf(vbuf, "%lum", (vp>>4) * poweroften[(vp&0x0f)-2]);
 	else
@@ -514,6 +517,7 @@ totext_loc(ARGS_TOTEXT) {
 	m1 = (int)(latitude % 60);
 	latitude /= 60;
 	d1 = (int)latitude;
+	INSIST(latitude <= 90U);
 
 	longitude = uint32_fromregion(&sr);
 	isc_region_consume(&sr, 4);
@@ -531,6 +535,7 @@ totext_loc(ARGS_TOTEXT) {
 	m2 = (int)(longitude % 60);
 	longitude /= 60;
 	d2 = (int)longitude;
+	INSIST(longitude <= 180U);
 
 	altitude = uint32_fromregion(&sr);
 	isc_region_consume(&sr, 4);
@@ -616,7 +621,7 @@ fromwire_loc(ARGS_FROMWIRE) {
 		return (ISC_R_RANGE);
 
 	/*
-	 * Altitiude.
+	 * Altitude.
 	 * All values possible.
 	 */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/loc_29.h b/contrib/bind9/lib/dns/rdata/generic/loc_29.h
index d8eae16..f053c60 100644
--- a/contrib/bind9/lib/dns/rdata/generic/loc_29.h
+++ b/contrib/bind9/lib/dns/rdata/generic/loc_29.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,7 +18,7 @@
 #ifndef GENERIC_LOC_29_H
 #define GENERIC_LOC_29_H 1
 
-/* $Id: loc_29.h,v 1.15.18.2 2005/04/29 00:16:34 marka Exp $ */
+/* $Id: loc_29.h,v 1.19 2007/06/19 23:47:17 tbox Exp $ */
 
 /*!
  * \brief Per RFC1876 */
diff --git a/contrib/bind9/lib/dns/rdata/generic/mb_7.c b/contrib/bind9/lib/dns/rdata/generic/mb_7.c
index 94c622d..fc3a7b6 100644
--- a/contrib/bind9/lib/dns/rdata/generic/mb_7.c
+++ b/contrib/bind9/lib/dns/rdata/generic/mb_7.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: mb_7.c,v 1.43 2004/03/05 05:10:13 marka Exp $ */
+/* $Id: mb_7.c,v 1.45 2007/06/19 23:47:17 tbox Exp $ */
 
 /* Reviewed: Wed Mar 15 17:31:26 PST 2000 by bwelling */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/mb_7.h b/contrib/bind9/lib/dns/rdata/generic/mb_7.h
index f6a8b35..b427ee9 100644
--- a/contrib/bind9/lib/dns/rdata/generic/mb_7.h
+++ b/contrib/bind9/lib/dns/rdata/generic/mb_7.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -19,7 +19,7 @@
 #ifndef GENERIC_MB_7_H
 #define GENERIC_MB_7_H 1
 
-/* $Id: mb_7.h,v 1.23.18.2 2005/04/29 00:16:34 marka Exp $ */
+/* $Id: mb_7.h,v 1.27 2007/06/19 23:47:17 tbox Exp $ */
 
 typedef struct dns_rdata_mb {
 	dns_rdatacommon_t	common;
diff --git a/contrib/bind9/lib/dns/rdata/generic/md_3.c b/contrib/bind9/lib/dns/rdata/generic/md_3.c
index 75e4970..0f8560f 100644
--- a/contrib/bind9/lib/dns/rdata/generic/md_3.c
+++ b/contrib/bind9/lib/dns/rdata/generic/md_3.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: md_3.c,v 1.45 2004/03/05 05:10:13 marka Exp $ */
+/* $Id: md_3.c,v 1.47 2007/06/19 23:47:17 tbox Exp $ */
 
 /* Reviewed: Wed Mar 15 17:48:20 PST 2000 by bwelling */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/md_3.h b/contrib/bind9/lib/dns/rdata/generic/md_3.h
index 578ce66..ba70d18 100644
--- a/contrib/bind9/lib/dns/rdata/generic/md_3.h
+++ b/contrib/bind9/lib/dns/rdata/generic/md_3.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -19,7 +19,7 @@
 #ifndef GENERIC_MD_3_H
 #define GENERIC_MD_3_H 1
 
-/* $Id: md_3.h,v 1.24.18.2 2005/04/29 00:16:35 marka Exp $ */
+/* $Id: md_3.h,v 1.28 2007/06/19 23:47:17 tbox Exp $ */
 
 typedef struct dns_rdata_md {
 	dns_rdatacommon_t	common;
diff --git a/contrib/bind9/lib/dns/rdata/generic/mf_4.c b/contrib/bind9/lib/dns/rdata/generic/mf_4.c
index 362d300..dffcec2 100644
--- a/contrib/bind9/lib/dns/rdata/generic/mf_4.c
+++ b/contrib/bind9/lib/dns/rdata/generic/mf_4.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: mf_4.c,v 1.43 2004/03/05 05:10:14 marka Exp $ */
+/* $Id: mf_4.c,v 1.45 2007/06/19 23:47:17 tbox Exp $ */
 
 /* reviewed: Wed Mar 15 17:47:33 PST 2000 by brister */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/mf_4.h b/contrib/bind9/lib/dns/rdata/generic/mf_4.h
index 2be0eec..32d2493 100644
--- a/contrib/bind9/lib/dns/rdata/generic/mf_4.h
+++ b/contrib/bind9/lib/dns/rdata/generic/mf_4.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -19,7 +19,7 @@
 #ifndef GENERIC_MF_4_H
 #define GENERIC_MF_4_H 1
 
-/* $Id: mf_4.h,v 1.22.18.2 2005/04/29 00:16:35 marka Exp $ */
+/* $Id: mf_4.h,v 1.26 2007/06/19 23:47:17 tbox Exp $ */
 
 typedef struct dns_rdata_mf {
 	dns_rdatacommon_t	common;
diff --git a/contrib/bind9/lib/dns/rdata/generic/mg_8.c b/contrib/bind9/lib/dns/rdata/generic/mg_8.c
index 602d820..e4dca1d 100644
--- a/contrib/bind9/lib/dns/rdata/generic/mg_8.c
+++ b/contrib/bind9/lib/dns/rdata/generic/mg_8.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: mg_8.c,v 1.41 2004/03/05 05:10:14 marka Exp $ */
+/* $Id: mg_8.c,v 1.43 2007/06/19 23:47:17 tbox Exp $ */
 
 /* reviewed: Wed Mar 15 17:49:21 PST 2000 by brister */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/mg_8.h b/contrib/bind9/lib/dns/rdata/generic/mg_8.h
index 5679c17..8fa143a 100644
--- a/contrib/bind9/lib/dns/rdata/generic/mg_8.h
+++ b/contrib/bind9/lib/dns/rdata/generic/mg_8.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -19,7 +19,7 @@
 #ifndef GENERIC_MG_8_H
 #define GENERIC_MG_8_H 1
 
-/* $Id: mg_8.h,v 1.22.18.2 2005/04/29 00:16:35 marka Exp $ */
+/* $Id: mg_8.h,v 1.26 2007/06/19 23:47:17 tbox Exp $ */
 
 typedef struct dns_rdata_mg {
 	dns_rdatacommon_t	common;
diff --git a/contrib/bind9/lib/dns/rdata/generic/minfo_14.c b/contrib/bind9/lib/dns/rdata/generic/minfo_14.c
index b757480..6645bbc 100644
--- a/contrib/bind9/lib/dns/rdata/generic/minfo_14.c
+++ b/contrib/bind9/lib/dns/rdata/generic/minfo_14.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: minfo_14.c,v 1.43 2004/03/05 05:10:14 marka Exp $ */
+/* $Id: minfo_14.c,v 1.45 2007/06/19 23:47:17 tbox Exp $ */
 
 /* reviewed: Wed Mar 15 17:45:32 PST 2000 by brister */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/minfo_14.h b/contrib/bind9/lib/dns/rdata/generic/minfo_14.h
index 754fe20..76195c5 100644
--- a/contrib/bind9/lib/dns/rdata/generic/minfo_14.h
+++ b/contrib/bind9/lib/dns/rdata/generic/minfo_14.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -19,7 +19,7 @@
 #ifndef GENERIC_MINFO_14_H
 #define GENERIC_MINFO_14_H 1
 
-/* $Id: minfo_14.h,v 1.23.18.2 2005/04/29 00:16:35 marka Exp $ */
+/* $Id: minfo_14.h,v 1.27 2007/06/19 23:47:17 tbox Exp $ */
 
 typedef struct dns_rdata_minfo {
 	dns_rdatacommon_t	common;
diff --git a/contrib/bind9/lib/dns/rdata/generic/mr_9.c b/contrib/bind9/lib/dns/rdata/generic/mr_9.c
index ab4c6e0..289d739 100644
--- a/contrib/bind9/lib/dns/rdata/generic/mr_9.c
+++ b/contrib/bind9/lib/dns/rdata/generic/mr_9.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: mr_9.c,v 1.40 2004/03/05 05:10:15 marka Exp $ */
+/* $Id: mr_9.c,v 1.42 2007/06/19 23:47:17 tbox Exp $ */
 
 /* Reviewed: Wed Mar 15 21:30:35 EST 2000 by tale */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/mr_9.h b/contrib/bind9/lib/dns/rdata/generic/mr_9.h
index e255d70..3d81bdd 100644
--- a/contrib/bind9/lib/dns/rdata/generic/mr_9.h
+++ b/contrib/bind9/lib/dns/rdata/generic/mr_9.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -19,7 +19,7 @@
 #ifndef GENERIC_MR_9_H
 #define GENERIC_MR_9_H 1
 
-/* $Id: mr_9.h,v 1.22.18.2 2005/04/29 00:16:36 marka Exp $ */
+/* $Id: mr_9.h,v 1.26 2007/06/19 23:47:17 tbox Exp $ */
 
 typedef struct dns_rdata_mr {
 	dns_rdatacommon_t	common;
diff --git a/contrib/bind9/lib/dns/rdata/generic/mx_15.c b/contrib/bind9/lib/dns/rdata/generic/mx_15.c
index fd77ec8..086c043 100644
--- a/contrib/bind9/lib/dns/rdata/generic/mx_15.c
+++ b/contrib/bind9/lib/dns/rdata/generic/mx_15.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: mx_15.c,v 1.52.18.2 2005/05/20 01:10:11 marka Exp $ */
+/* $Id: mx_15.c,v 1.56 2007/06/19 23:47:17 tbox Exp $ */
 
 /* reviewed: Wed Mar 15 18:05:46 PST 2000 by brister */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/mx_15.h b/contrib/bind9/lib/dns/rdata/generic/mx_15.h
index 4d81b90..25d5ac5 100644
--- a/contrib/bind9/lib/dns/rdata/generic/mx_15.h
+++ b/contrib/bind9/lib/dns/rdata/generic/mx_15.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -19,7 +19,7 @@
 #ifndef GENERIC_MX_15_H
 #define GENERIC_MX_15_H 1
 
-/* $Id: mx_15.h,v 1.25.18.2 2005/04/29 00:16:36 marka Exp $ */
+/* $Id: mx_15.h,v 1.29 2007/06/19 23:47:17 tbox Exp $ */
 
 typedef struct dns_rdata_mx {
 	dns_rdatacommon_t	common;
diff --git a/contrib/bind9/lib/dns/rdata/generic/ns_2.c b/contrib/bind9/lib/dns/rdata/generic/ns_2.c
index 2379433..9a2ee8c 100644
--- a/contrib/bind9/lib/dns/rdata/generic/ns_2.c
+++ b/contrib/bind9/lib/dns/rdata/generic/ns_2.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ns_2.c,v 1.44 2004/03/05 05:10:15 marka Exp $ */
+/* $Id: ns_2.c,v 1.46 2007/06/19 23:47:17 tbox Exp $ */
 
 /* Reviewed: Wed Mar 15 18:15:00 PST 2000 by bwelling */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/ns_2.h b/contrib/bind9/lib/dns/rdata/generic/ns_2.h
index ec8e771..546e71a 100644
--- a/contrib/bind9/lib/dns/rdata/generic/ns_2.h
+++ b/contrib/bind9/lib/dns/rdata/generic/ns_2.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -19,7 +19,7 @@
 #ifndef GENERIC_NS_2_H
 #define GENERIC_NS_2_H 1
 
-/* $Id: ns_2.h,v 1.23.18.2 2005/04/29 00:16:37 marka Exp $ */
+/* $Id: ns_2.h,v 1.27 2007/06/19 23:47:17 tbox Exp $ */
 
 typedef struct dns_rdata_ns {
 	dns_rdatacommon_t	common;
diff --git a/contrib/bind9/lib/dns/rdata/generic/nsec3_50.c b/contrib/bind9/lib/dns/rdata/generic/nsec3_50.c
new file mode 100644
index 0000000..c5f0acb
--- /dev/null
+++ b/contrib/bind9/lib/dns/rdata/generic/nsec3_50.c
@@ -0,0 +1,481 @@
+/*
+ * Copyright (C) 2008, 2009  Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or 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: nsec3_50.c,v 1.4.48.2 2009/01/18 23:47:41 tbox Exp $ */
+
+/*
+ * Copyright (C) 2004  Nominet, Ltd.
+ *
+ * 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 NOMINET 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.
+ */
+
+/* RFC 5155 */
+
+#ifndef RDATA_GENERIC_NSEC3_50_C
+#define RDATA_GENERIC_NSEC3_50_C
+
+#include <isc/iterated_hash.h>
+#include <isc/base32.h>
+
+#define RRTYPE_NSEC3_ATTRIBUTES DNS_RDATATYPEATTR_DNSSEC
+
+static inline isc_result_t
+fromtext_nsec3(ARGS_FROMTEXT) {
+	isc_token_t token;
+	unsigned char bm[8*1024]; /* 64k bits */
+	dns_rdatatype_t covered;
+	int octet;
+	int window;
+	unsigned int flags;
+	unsigned char hashalg;
+	isc_buffer_t b;
+
+	REQUIRE(type == 50);
+
+	UNUSED(type);
+	UNUSED(rdclass);
+	UNUSED(callbacks);
+	UNUSED(origin);
+	UNUSED(options);
+
+	/* Hash. */
+	RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_string,
+				      ISC_FALSE));
+	RETTOK(dns_hashalg_fromtext(&hashalg, &token.value.as_textregion));
+	RETERR(uint8_tobuffer(hashalg, target));
+
+	/* Flags. */
+	RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_number,
+				      ISC_FALSE));
+	flags = token.value.as_ulong;
+	if (flags > 255U)
+		RETTOK(ISC_R_RANGE);
+	RETERR(uint8_tobuffer(flags, target));
+
+	/* Iterations. */
+	RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_number,
+				      ISC_FALSE));
+	if (token.value.as_ulong > 0xffffU)
+		RETTOK(ISC_R_RANGE);
+	RETERR(uint16_tobuffer(token.value.as_ulong, target));
+
+	/* salt */
+	RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_string,
+				      ISC_FALSE));
+	if (token.value.as_textregion.length > (255*2))
+		RETTOK(DNS_R_TEXTTOOLONG);
+	if (strcmp(DNS_AS_STR(token), "-") == 0) {
+		RETERR(uint8_tobuffer(0, target));
+	} else {
+		RETERR(uint8_tobuffer(strlen(DNS_AS_STR(token)) / 2, target));
+		RETERR(isc_hex_decodestring(DNS_AS_STR(token), target));
+	}
+
+	/*
+	 * Next hash a single base32hex word.
+	 */
+	RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_string,
+				      ISC_FALSE));
+	isc_buffer_init(&b, bm, sizeof(bm));
+	RETTOK(isc_base32hex_decodestring(DNS_AS_STR(token), &b));
+	if (isc_buffer_usedlength(&b) > 0xffU)
+		RETTOK(ISC_R_RANGE);
+	RETERR(uint8_tobuffer(isc_buffer_usedlength(&b), target));
+	RETERR(mem_tobuffer(target, &bm, isc_buffer_usedlength(&b)));
+
+	memset(bm, 0, sizeof(bm));
+	do {
+		RETERR(isc_lex_getmastertoken(lexer, &token,
+					      isc_tokentype_string, ISC_TRUE));
+		if (token.type != isc_tokentype_string)
+			break;
+		RETTOK(dns_rdatatype_fromtext(&covered,
+					      &token.value.as_textregion));
+		bm[covered/8] |= (0x80>>(covered%8));
+	} while (1);
+	isc_lex_ungettoken(lexer, &token);
+	for (window = 0; window < 256 ; window++) {
+		/*
+		 * Find if we have a type in this window.
+		 */
+		for (octet = 31; octet >= 0; octet--)
+			if (bm[window * 32 + octet] != 0)
+				break;
+		if (octet < 0)
+			continue;
+		RETERR(uint8_tobuffer(window, target));
+		RETERR(uint8_tobuffer(octet + 1, target));
+		RETERR(mem_tobuffer(target, &bm[window * 32], octet + 1));
+	}
+	return (ISC_R_SUCCESS);
+}
+
+static inline isc_result_t
+totext_nsec3(ARGS_TOTEXT) {
+	isc_region_t sr;
+	unsigned int i, j, k;
+	unsigned int window, len;
+	unsigned char hash;
+	unsigned char flags;
+	char buf[sizeof("65535 ")];
+	isc_uint32_t iterations;
+
+	REQUIRE(rdata->type == 50);
+	REQUIRE(rdata->length != 0);
+
+	UNUSED(tctx);
+
+	dns_rdata_toregion(rdata, &sr);
+
+	hash = uint8_fromregion(&sr);
+	isc_region_consume(&sr, 1);
+
+	flags = uint8_fromregion(&sr);
+	isc_region_consume(&sr, 1);
+
+	iterations = uint16_fromregion(&sr);
+	isc_region_consume(&sr, 2);
+
+	sprintf(buf, "%u ", hash);
+	RETERR(str_totext(buf, target));
+
+	sprintf(buf, "%u ", flags);
+	RETERR(str_totext(buf, target));
+
+	sprintf(buf, "%u ", iterations);
+	RETERR(str_totext(buf, target));
+
+	j = uint8_fromregion(&sr);
+	isc_region_consume(&sr, 1);
+	INSIST(j <= sr.length);
+
+	if (j != 0) {
+		i = sr.length;
+		sr.length = j;
+		RETERR(isc_hex_totext(&sr, 1, "", target));
+		sr.length = i - j;
+		RETERR(str_totext(" ", target));
+	} else
+		RETERR(str_totext("- ", target));
+
+	j = uint8_fromregion(&sr);
+	isc_region_consume(&sr, 1);
+	INSIST(j <= sr.length);
+
+	i = sr.length;
+	sr.length = j;
+	RETERR(isc_base32hex_totext(&sr, 1, "", target));
+	sr.length = i - j;
+
+	for (i = 0; i < sr.length; i += len) {
+		INSIST(i + 2 <= sr.length);
+		window = sr.base[i];
+		len = sr.base[i + 1];
+		INSIST(len > 0 && len <= 32);
+		i += 2;
+		INSIST(i + len <= sr.length);
+		for (j = 0; j < len; j++) {
+			dns_rdatatype_t t;
+			if (sr.base[i + j] == 0)
+				continue;
+			for (k = 0; k < 8; k++) {
+				if ((sr.base[i + j] & (0x80 >> k)) == 0)
+					continue;
+				t = window * 256 + j * 8 + k;
+				RETERR(str_totext(" ", target));
+				if (dns_rdatatype_isknown(t)) {
+					RETERR(dns_rdatatype_totext(t, target));
+				} else {
+					char buf[sizeof("TYPE65535")];
+					sprintf(buf, "TYPE%u", t);
+					RETERR(str_totext(buf, target));
+				}
+			}
+		}
+	}
+	return (ISC_R_SUCCESS);
+}
+
+static inline isc_result_t
+fromwire_nsec3(ARGS_FROMWIRE) {
+	isc_region_t sr, rr;
+	unsigned int window, lastwindow = 0;
+	unsigned int len;
+	unsigned int saltlen, hashlen;
+	isc_boolean_t first = ISC_TRUE;
+	unsigned int i;
+
+	REQUIRE(type == 50);
+
+	UNUSED(type);
+	UNUSED(rdclass);
+	UNUSED(options);
+	UNUSED(dctx);
+
+	isc_buffer_activeregion(source, &sr);
+	rr = sr;
+
+	/* hash(1), flags(1), iteration(2), saltlen(1) */
+	if (sr.length < 5U)
+		RETERR(DNS_R_FORMERR);
+	saltlen = sr.base[4];
+	isc_region_consume(&sr, 5);
+
+	if (sr.length < saltlen)
+		RETERR(DNS_R_FORMERR);
+	isc_region_consume(&sr, saltlen);
+
+	if (sr.length < 1U)
+		RETERR(DNS_R_FORMERR);
+	hashlen = sr.base[0];
+	isc_region_consume(&sr, 1);
+
+	if (sr.length < hashlen)
+		RETERR(DNS_R_FORMERR);
+	isc_region_consume(&sr, hashlen);
+
+	for (i = 0; i < sr.length; i += len) {
+		/*
+		 * Check for overflow.
+		 */
+		if (i + 2 > sr.length)
+			RETERR(DNS_R_FORMERR);
+		window = sr.base[i];
+		len = sr.base[i + 1];
+		i += 2;
+		/*
+		 * Check that bitmap windows are in the correct order.
+		 */
+		if (!first && window <= lastwindow)
+			RETERR(DNS_R_FORMERR);
+		/*
+		 * Check for legal lengths.
+		 */
+		if (len < 1 || len > 32)
+			RETERR(DNS_R_FORMERR);
+		/*
+		 * Check for overflow.
+		 */
+		if (i + len > sr.length)
+			RETERR(DNS_R_FORMERR);
+		/*
+		 * The last octet of the bitmap must be non zero.
+		 */
+		if (sr.base[i + len - 1] == 0)
+			RETERR(DNS_R_FORMERR);
+		lastwindow = window;
+		first = ISC_FALSE;
+	}
+	if (i != sr.length)
+		return (DNS_R_EXTRADATA);
+	RETERR(mem_tobuffer(target, rr.base, rr.length));
+	isc_buffer_forward(source, rr.length);
+	return (ISC_R_SUCCESS);
+}
+
+static inline isc_result_t
+towire_nsec3(ARGS_TOWIRE) {
+	isc_region_t sr;
+
+	REQUIRE(rdata->type == 50);
+	REQUIRE(rdata->length != 0);
+
+	UNUSED(cctx);
+
+	dns_rdata_toregion(rdata, &sr);
+	return (mem_tobuffer(target, sr.base, sr.length));
+}
+
+static inline int
+compare_nsec3(ARGS_COMPARE) {
+	isc_region_t r1;
+	isc_region_t r2;
+
+	REQUIRE(rdata1->type == rdata2->type);
+	REQUIRE(rdata1->rdclass == rdata2->rdclass);
+	REQUIRE(rdata1->type == 50);
+	REQUIRE(rdata1->length != 0);
+	REQUIRE(rdata2->length != 0);
+
+	dns_rdata_toregion(rdata1, &r1);
+	dns_rdata_toregion(rdata2, &r2);
+	return (isc_region_compare(&r1, &r2));
+}
+
+static inline isc_result_t
+fromstruct_nsec3(ARGS_FROMSTRUCT) {
+	dns_rdata_nsec3_t *nsec3 = source;
+	unsigned int i, len, window, lastwindow = 0;
+	isc_boolean_t first = ISC_TRUE;
+
+	REQUIRE(type == 50);
+	REQUIRE(source != NULL);
+	REQUIRE(nsec3->common.rdtype == type);
+	REQUIRE(nsec3->common.rdclass == rdclass);
+	REQUIRE(nsec3->typebits != NULL || nsec3->len == 0);
+	REQUIRE(nsec3->hash == dns_hash_sha1);
+
+	UNUSED(type);
+	UNUSED(rdclass);
+
+	RETERR(uint8_tobuffer(nsec3->hash, target));
+	RETERR(uint8_tobuffer(nsec3->flags, target));
+	RETERR(uint16_tobuffer(nsec3->iterations, target));
+	RETERR(uint8_tobuffer(nsec3->salt_length, target));
+	RETERR(mem_tobuffer(target, nsec3->salt, nsec3->salt_length));
+	RETERR(uint8_tobuffer(nsec3->next_length, target));
+	RETERR(mem_tobuffer(target, nsec3->next, nsec3->next_length));
+
+	/*
+	 * Perform sanity check.
+	 */
+	for (i = 0; i < nsec3->len ; i += len) {
+		INSIST(i + 2 <= nsec3->len);
+		window = nsec3->typebits[i];
+		len = nsec3->typebits[i+1];
+		i += 2;
+		INSIST(first || window > lastwindow);
+		INSIST(len > 0 && len <= 32);
+		INSIST(i + len <= nsec3->len);
+		INSIST(nsec3->typebits[i + len - 1] != 0);
+		lastwindow = window;
+		first = ISC_FALSE;
+	}
+	return (mem_tobuffer(target, nsec3->typebits, nsec3->len));
+}
+
+static inline isc_result_t
+tostruct_nsec3(ARGS_TOSTRUCT) {
+	isc_region_t region;
+	dns_rdata_nsec3_t *nsec3 = target;
+
+	REQUIRE(rdata->type == 50);
+	REQUIRE(target != NULL);
+	REQUIRE(rdata->length != 0);
+
+	nsec3->common.rdclass = rdata->rdclass;
+	nsec3->common.rdtype = rdata->type;
+	ISC_LINK_INIT(&nsec3->common, link);
+
+	region.base = rdata->data;
+	region.length = rdata->length;
+	nsec3->hash = uint8_consume_fromregion(&region);
+	nsec3->flags = uint8_consume_fromregion(&region);
+	nsec3->iterations = uint16_consume_fromregion(&region);
+
+	nsec3->salt_length = uint8_consume_fromregion(&region);
+	nsec3->salt = mem_maybedup(mctx, region.base, nsec3->salt_length);
+	if (nsec3->salt == NULL)
+		return (ISC_R_NOMEMORY);
+	isc_region_consume(&region, nsec3->salt_length);
+
+	nsec3->next_length = uint8_consume_fromregion(&region);
+	nsec3->next = mem_maybedup(mctx, region.base, nsec3->next_length);
+	if (nsec3->next == NULL)
+		goto cleanup;
+	isc_region_consume(&region, nsec3->next_length);
+
+	nsec3->len = region.length;
+	nsec3->typebits = mem_maybedup(mctx, region.base, region.length);
+	if (nsec3->typebits == NULL)
+		goto cleanup;
+
+	nsec3->mctx = mctx;
+	return (ISC_R_SUCCESS);
+
+  cleanup:
+	if (nsec3->next != NULL)
+		isc_mem_free(mctx, nsec3->next);
+	isc_mem_free(mctx, nsec3->salt);
+	return (ISC_R_NOMEMORY);
+}
+
+static inline void
+freestruct_nsec3(ARGS_FREESTRUCT) {
+	dns_rdata_nsec3_t *nsec3 = source;
+
+	REQUIRE(source != NULL);
+	REQUIRE(nsec3->common.rdtype == 50);
+
+	if (nsec3->mctx == NULL)
+		return;
+
+	if (nsec3->salt != NULL)
+		isc_mem_free(nsec3->mctx, nsec3->salt);
+	if (nsec3->next != NULL)
+		isc_mem_free(nsec3->mctx, nsec3->next);
+	if (nsec3->typebits != NULL)
+		isc_mem_free(nsec3->mctx, nsec3->typebits);
+	nsec3->mctx = NULL;
+}
+
+static inline isc_result_t
+additionaldata_nsec3(ARGS_ADDLDATA) {
+	REQUIRE(rdata->type == 50);
+
+	UNUSED(rdata);
+	UNUSED(add);
+	UNUSED(arg);
+
+	return (ISC_R_SUCCESS);
+}
+
+static inline isc_result_t
+digest_nsec3(ARGS_DIGEST) {
+	isc_region_t r;
+
+	REQUIRE(rdata->type == 50);
+
+	dns_rdata_toregion(rdata, &r);
+	return ((digest)(arg, &r));
+}
+
+static inline isc_boolean_t
+checkowner_nsec3(ARGS_CHECKOWNER) {
+
+       REQUIRE(type == 50);
+
+       UNUSED(name);
+       UNUSED(type);
+       UNUSED(rdclass);
+       UNUSED(wildcard);
+
+       return (ISC_TRUE);
+}
+
+static inline isc_boolean_t
+checknames_nsec3(ARGS_CHECKNAMES) {
+
+	REQUIRE(rdata->type == 50);
+
+	UNUSED(rdata);
+	UNUSED(owner);
+	UNUSED(bad);
+
+	return (ISC_TRUE);
+}
+
+#endif	/* RDATA_GENERIC_NSEC3_50_C */
diff --git a/contrib/bind9/lib/dns/rdata/generic/nsec3_50.h b/contrib/bind9/lib/dns/rdata/generic/nsec3_50.h
new file mode 100644
index 0000000..658dd9d
--- /dev/null
+++ b/contrib/bind9/lib/dns/rdata/generic/nsec3_50.h
@@ -0,0 +1,93 @@
+/*
+ * Copyright (C) 2008  Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or 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.
+ */
+
+
+#ifndef GENERIC_NSEC3_50_H
+#define GENERIC_NSEC3_50_H 1
+
+/* $Id: nsec3_50.h,v 1.4 2008/09/25 04:02:39 tbox Exp $ */
+
+/*!
+ * \brief Per RFC 5155 */
+
+#include <isc/iterated_hash.h>
+
+typedef struct dns_rdata_nsec3 {
+	dns_rdatacommon_t	common;
+	isc_mem_t		*mctx;
+	dns_hash_t		hash;
+	unsigned char		flags;
+	dns_iterations_t	iterations;
+	unsigned char		salt_length;
+	unsigned char		next_length;
+	isc_uint16_t		len;
+	unsigned char		*salt;
+	unsigned char		*next;
+	unsigned char		*typebits;
+} dns_rdata_nsec3_t;
+
+/*
+ * The corresponding NSEC3 interval is OPTOUT indicating possible
+ * insecure delegations.
+ */
+#define DNS_NSEC3FLAG_OPTOUT 0x01U
+
+/*%
+ * Non-standard, NSEC3PARAM only.
+ *
+ * Create a corresponding NSEC3 chain.
+ * Once the NSEC3 chain is complete this flag will be removed to signal
+ * that there is a complete chain.
+ *
+ * This flag is automatically set when a NSEC3PARAM record is added to
+ * the zone via UPDATE.
+ *
+ * NSEC3PARAM records with this flag set are supposed to be ignored by
+ * RFC 5155 compliant nameservers.
+ */
+#define DNS_NSEC3FLAG_CREATE 0x80U
+
+/*%
+ * Non-standard, NSEC3PARAM only.
+ *
+ * The corresponding NSEC3 set is to be removed once the NSEC chain
+ * has been generated.
+ *
+ * This flag is automatically set when the last active NSEC3PARAM record
+ * is removed from the zone via UPDATE.
+ *
+ * NSEC3PARAM records with this flag set are supposed to be ignored by
+ * RFC 5155 compliant nameservers.
+ */
+#define DNS_NSEC3FLAG_REMOVE 0x40U
+
+/*%
+ * Non-standard, NSEC3PARAM only.
+ *
+ * Used to identify NSEC3PARAM records added in this UPDATE request.
+ */
+#define DNS_NSEC3FLAG_UPDATE 0x20U
+
+/*%
+ * Non-standard, NSEC3PARAM only.
+ *
+ * Prevent the creation of a NSEC chain before the last NSEC3 chain
+ * is removed.  This will normally only be set when the zone is
+ * transitioning from secure with NSEC3 chains to insecure.
+ */
+#define DNS_NSEC3FLAG_NONSEC 0x10U
+
+#endif /* GENERIC_NSEC3_50_H */
diff --git a/contrib/bind9/lib/dns/rdata/generic/nsec3param_51.c b/contrib/bind9/lib/dns/rdata/generic/nsec3param_51.c
new file mode 100644
index 0000000..607ce6a
--- /dev/null
+++ b/contrib/bind9/lib/dns/rdata/generic/nsec3param_51.c
@@ -0,0 +1,314 @@
+/*
+ * Copyright (C) 2008, 2009  Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or 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: nsec3param_51.c,v 1.4.48.2 2009/01/18 23:47:41 tbox Exp $ */
+
+/*
+ * Copyright (C) 2004  Nominet, Ltd.
+ *
+ * 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 NOMINET 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.
+ */
+
+/* RFC 5155 */
+
+#ifndef RDATA_GENERIC_NSEC3PARAM_51_C
+#define RDATA_GENERIC_NSEC3PARAM_51_C
+
+#include <isc/iterated_hash.h>
+#include <isc/base32.h>
+
+#define RRTYPE_NSEC3PARAM_ATTRIBUTES (DNS_RDATATYPEATTR_DNSSEC)
+
+static inline isc_result_t
+fromtext_nsec3param(ARGS_FROMTEXT) {
+	isc_token_t token;
+	unsigned int flags = 0;
+	unsigned char hashalg;
+
+	REQUIRE(type == 51);
+
+	UNUSED(type);
+	UNUSED(rdclass);
+	UNUSED(callbacks);
+	UNUSED(origin);
+	UNUSED(options);
+
+	/* Hash. */
+	RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_string,
+				      ISC_FALSE));
+	RETTOK(dns_hashalg_fromtext(&hashalg, &token.value.as_textregion));
+	RETERR(uint8_tobuffer(hashalg, target));
+
+	/* Flags. */
+	RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_number,
+				      ISC_FALSE));
+	flags = token.value.as_ulong;
+	if (flags > 255U)
+		RETTOK(ISC_R_RANGE);
+	RETERR(uint8_tobuffer(flags, target));
+
+	/* Iterations. */
+	RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_number,
+				      ISC_FALSE));
+	if (token.value.as_ulong > 0xffffU)
+		RETTOK(ISC_R_RANGE);
+	RETERR(uint16_tobuffer(token.value.as_ulong, target));
+
+	/* Salt. */
+	RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_string,
+				      ISC_FALSE));
+	if (token.value.as_textregion.length > (255*2))
+		RETTOK(DNS_R_TEXTTOOLONG);
+	if (strcmp(DNS_AS_STR(token), "-") == 0) {
+		RETERR(uint8_tobuffer(0, target));
+	} else {
+		RETERR(uint8_tobuffer(strlen(DNS_AS_STR(token)) / 2, target));
+		RETERR(isc_hex_decodestring(DNS_AS_STR(token), target));
+	}
+
+	return (ISC_R_SUCCESS);
+}
+
+static inline isc_result_t
+totext_nsec3param(ARGS_TOTEXT) {
+	isc_region_t sr;
+	unsigned int i, j;
+	unsigned char hash;
+	unsigned char flags;
+	char buf[sizeof("65535 ")];
+	isc_uint32_t iterations;
+
+	REQUIRE(rdata->type == 51);
+	REQUIRE(rdata->length != 0);
+
+	UNUSED(tctx);
+
+	dns_rdata_toregion(rdata, &sr);
+
+	hash = uint8_fromregion(&sr);
+	isc_region_consume(&sr, 1);
+
+	flags = uint8_fromregion(&sr);
+	isc_region_consume(&sr, 1);
+
+	iterations = uint16_fromregion(&sr);
+	isc_region_consume(&sr, 2);
+
+	sprintf(buf, "%u ", hash);
+	RETERR(str_totext(buf, target));
+
+	sprintf(buf, "%u ", flags);
+	RETERR(str_totext(buf, target));
+
+	sprintf(buf, "%u ", iterations);
+	RETERR(str_totext(buf, target));
+
+	j = uint8_fromregion(&sr);
+	isc_region_consume(&sr, 1);
+	INSIST(j <= sr.length);
+
+	if (j != 0) {
+		i = sr.length;
+		sr.length = j;
+		RETERR(isc_hex_totext(&sr, 1, "", target));
+		sr.length = i - j;
+	} else
+		RETERR(str_totext("-", target));
+
+	return (ISC_R_SUCCESS);
+}
+
+static inline isc_result_t
+fromwire_nsec3param(ARGS_FROMWIRE) {
+	isc_region_t sr, rr;
+	unsigned int saltlen;
+
+	REQUIRE(type == 51);
+
+	UNUSED(type);
+	UNUSED(rdclass);
+	UNUSED(options);
+	UNUSED(dctx);
+
+	isc_buffer_activeregion(source, &sr);
+	rr = sr;
+
+	/* hash(1), flags(1), iterations(2), saltlen(1) */
+	if (sr.length < 5U)
+		RETERR(DNS_R_FORMERR);
+	saltlen = sr.base[4];
+	isc_region_consume(&sr, 5);
+
+	if (sr.length < saltlen)
+		RETERR(DNS_R_FORMERR);
+	isc_region_consume(&sr, saltlen);
+	RETERR(mem_tobuffer(target, rr.base, rr.length));
+	isc_buffer_forward(source, rr.length);
+	return (ISC_R_SUCCESS);
+}
+
+static inline isc_result_t
+towire_nsec3param(ARGS_TOWIRE) {
+	isc_region_t sr;
+
+	REQUIRE(rdata->type == 51);
+	REQUIRE(rdata->length != 0);
+
+	UNUSED(cctx);
+
+	dns_rdata_toregion(rdata, &sr);
+	return (mem_tobuffer(target, sr.base, sr.length));
+}
+
+static inline int
+compare_nsec3param(ARGS_COMPARE) {
+	isc_region_t r1;
+	isc_region_t r2;
+
+	REQUIRE(rdata1->type == rdata2->type);
+	REQUIRE(rdata1->rdclass == rdata2->rdclass);
+	REQUIRE(rdata1->type == 51);
+	REQUIRE(rdata1->length != 0);
+	REQUIRE(rdata2->length != 0);
+
+	dns_rdata_toregion(rdata1, &r1);
+	dns_rdata_toregion(rdata2, &r2);
+	return (isc_region_compare(&r1, &r2));
+}
+
+static inline isc_result_t
+fromstruct_nsec3param(ARGS_FROMSTRUCT) {
+	dns_rdata_nsec3param_t *nsec3param = source;
+
+	REQUIRE(type == 51);
+	REQUIRE(source != NULL);
+	REQUIRE(nsec3param->common.rdtype == type);
+	REQUIRE(nsec3param->common.rdclass == rdclass);
+
+	UNUSED(type);
+	UNUSED(rdclass);
+
+	RETERR(uint8_tobuffer(nsec3param->hash, target));
+	RETERR(uint8_tobuffer(nsec3param->flags, target));
+	RETERR(uint16_tobuffer(nsec3param->iterations, target));
+	RETERR(uint8_tobuffer(nsec3param->salt_length, target));
+	RETERR(mem_tobuffer(target, nsec3param->salt,
+			    nsec3param->salt_length));
+	return (ISC_R_SUCCESS);
+}
+
+static inline isc_result_t
+tostruct_nsec3param(ARGS_TOSTRUCT) {
+	isc_region_t region;
+	dns_rdata_nsec3param_t *nsec3param = target;
+
+	REQUIRE(rdata->type == 51);
+	REQUIRE(target != NULL);
+	REQUIRE(rdata->length != 0);
+
+	nsec3param->common.rdclass = rdata->rdclass;
+	nsec3param->common.rdtype = rdata->type;
+	ISC_LINK_INIT(&nsec3param->common, link);
+
+	region.base = rdata->data;
+	region.length = rdata->length;
+	nsec3param->hash = uint8_consume_fromregion(&region);
+	nsec3param->flags = uint8_consume_fromregion(&region);
+	nsec3param->iterations = uint16_consume_fromregion(&region);
+
+	nsec3param->salt_length = uint8_consume_fromregion(&region);
+	nsec3param->salt = mem_maybedup(mctx, region.base,
+					nsec3param->salt_length);
+	if (nsec3param->salt == NULL)
+		return (ISC_R_NOMEMORY);
+	isc_region_consume(&region, nsec3param->salt_length);
+
+	nsec3param->mctx = mctx;
+	return (ISC_R_SUCCESS);
+}
+
+static inline void
+freestruct_nsec3param(ARGS_FREESTRUCT) {
+	dns_rdata_nsec3param_t *nsec3param = source;
+
+	REQUIRE(source != NULL);
+	REQUIRE(nsec3param->common.rdtype == 51);
+
+	if (nsec3param->mctx == NULL)
+		return;
+
+	if (nsec3param->salt != NULL)
+		isc_mem_free(nsec3param->mctx, nsec3param->salt);
+	nsec3param->mctx = NULL;
+}
+
+static inline isc_result_t
+additionaldata_nsec3param(ARGS_ADDLDATA) {
+	REQUIRE(rdata->type == 51);
+
+	UNUSED(rdata);
+	UNUSED(add);
+	UNUSED(arg);
+
+	return (ISC_R_SUCCESS);
+}
+
+static inline isc_result_t
+digest_nsec3param(ARGS_DIGEST) {
+	isc_region_t r;
+
+	REQUIRE(rdata->type == 51);
+
+	dns_rdata_toregion(rdata, &r);
+	return ((digest)(arg, &r));
+}
+
+static inline isc_boolean_t
+checkowner_nsec3param(ARGS_CHECKOWNER) {
+
+       REQUIRE(type == 51);
+
+       UNUSED(name);
+       UNUSED(type);
+       UNUSED(rdclass);
+       UNUSED(wildcard);
+
+       return (ISC_TRUE);
+}
+
+static inline isc_boolean_t
+checknames_nsec3param(ARGS_CHECKNAMES) {
+
+	REQUIRE(rdata->type == 51);
+
+	UNUSED(rdata);
+	UNUSED(owner);
+	UNUSED(bad);
+
+	return (ISC_TRUE);
+}
+
+#endif	/* RDATA_GENERIC_NSEC3PARAM_51_C */
diff --git a/contrib/bind9/lib/bind/include/isc/platform.h.in b/contrib/bind9/lib/dns/rdata/generic/nsec3param_51.h
index 40ab5d7..2efd7e6 100644
--- a/contrib/bind9/lib/bind/include/isc/platform.h.in
+++ b/contrib/bind9/lib/dns/rdata/generic/nsec3param_51.h
@@ -14,23 +14,25 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: platform.h.in,v 1.2.6.2 2008/01/23 02:15:02 tbox Exp $ */
 
-/*! \file */
+#ifndef GENERIC_NSEC3PARAM_51_H
+#define GENERIC_NSEC3PARAM_51_H 1
 
-#ifndef ISC_PLATFORM_H
-#define ISC_PLATFORM_H
+/* $Id: nsec3param_51.h,v 1.4 2008/09/25 04:02:39 tbox Exp $ */
 
-/*
- * Define if the OS does not define struct timespec.
- */
-@ISC_PLATFORM_NEEDTIMESPEC@
-#ifdef ISC_PLATFORM_NEEDTIMESPEC
-#include <time.h>               /* For time_t */
-struct timespec {
-	time_t  tv_sec;         /* seconds */
-	long    tv_nsec;        /* nanoseconds */
-};
-#endif
+/*!
+ * \brief Per RFC 5155 */
+
+#include <isc/iterated_hash.h>
+
+typedef struct dns_rdata_nsec3param {
+	dns_rdatacommon_t	common;
+	isc_mem_t		*mctx;
+	dns_hash_t		hash;
+	unsigned char		flags;		/* DNS_NSEC3FLAG_* */
+	dns_iterations_t	iterations;
+	unsigned char		salt_length;
+	unsigned char		*salt;
+} dns_rdata_nsec3param_t;
 
-#endif
+#endif /* GENERIC_NSEC3PARAM_51_H */
diff --git a/contrib/bind9/lib/dns/rdata/generic/nsec_47.c b/contrib/bind9/lib/dns/rdata/generic/nsec_47.c
index dd39105..7e443d9 100644
--- a/contrib/bind9/lib/dns/rdata/generic/nsec_47.c
+++ b/contrib/bind9/lib/dns/rdata/generic/nsec_47.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: nsec_47.c,v 1.7.20.2 2008/07/15 23:46:14 tbox Exp $ */
+/* $Id: nsec_47.c,v 1.11 2008/07/15 23:47:21 tbox Exp $ */
 
 /* reviewed: Wed Mar 15 18:21:15 PST 2000 by brister */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/nsec_47.h b/contrib/bind9/lib/dns/rdata/generic/nsec_47.h
index 5c52447..2b3c6b6 100644
--- a/contrib/bind9/lib/dns/rdata/generic/nsec_47.h
+++ b/contrib/bind9/lib/dns/rdata/generic/nsec_47.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -18,7 +18,7 @@
 #ifndef GENERIC_NSEC_47_H
 #define GENERIC_NSEC_47_H 1
 
-/* $Id: nsec_47.h,v 1.4.20.4 2008/07/15 23:46:14 tbox Exp $ */
+/* $Id: nsec_47.h,v 1.10 2008/07/15 23:47:21 tbox Exp $ */
 
 /*!
  * \brief Per RFC 3845 */
diff --git a/contrib/bind9/lib/dns/rdata/generic/null_10.c b/contrib/bind9/lib/dns/rdata/generic/null_10.c
index a6f8f9f4..00bb542 100644
--- a/contrib/bind9/lib/dns/rdata/generic/null_10.c
+++ b/contrib/bind9/lib/dns/rdata/generic/null_10.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: null_10.c,v 1.40 2004/03/05 05:10:16 marka Exp $ */
+/* $Id: null_10.c,v 1.42 2007/06/19 23:47:17 tbox Exp $ */
 
 /* Reviewed: Thu Mar 16 13:57:50 PST 2000 by explorer */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/null_10.h b/contrib/bind9/lib/dns/rdata/generic/null_10.h
index 5afb1ae..ceeb018 100644
--- a/contrib/bind9/lib/dns/rdata/generic/null_10.h
+++ b/contrib/bind9/lib/dns/rdata/generic/null_10.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -19,7 +19,7 @@
 #ifndef GENERIC_NULL_10_H
 #define GENERIC_NULL_10_H 1
 
-/* $Id: null_10.h,v 1.21.18.2 2005/04/29 00:16:37 marka Exp $ */
+/* $Id: null_10.h,v 1.25 2007/06/19 23:47:17 tbox Exp $ */
 
 typedef struct dns_rdata_null {
 	dns_rdatacommon_t	common;
diff --git a/contrib/bind9/lib/dns/rdata/generic/nxt_30.c b/contrib/bind9/lib/dns/rdata/generic/nxt_30.c
index b7358e0..7ffb86c 100644
--- a/contrib/bind9/lib/dns/rdata/generic/nxt_30.c
+++ b/contrib/bind9/lib/dns/rdata/generic/nxt_30.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: nxt_30.c,v 1.59.18.2 2005/04/29 00:16:38 marka Exp $ */
+/* $Id: nxt_30.c,v 1.63 2007/06/19 23:47:17 tbox Exp $ */
 
 /* reviewed: Wed Mar 15 18:21:15 PST 2000 by brister */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/nxt_30.h b/contrib/bind9/lib/dns/rdata/generic/nxt_30.h
index 3700fb1..e2e8688 100644
--- a/contrib/bind9/lib/dns/rdata/generic/nxt_30.h
+++ b/contrib/bind9/lib/dns/rdata/generic/nxt_30.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,7 +18,7 @@
 #ifndef GENERIC_NXT_30_H
 #define GENERIC_NXT_30_H 1
 
-/* $Id: nxt_30.h,v 1.21.18.2 2005/04/29 00:16:38 marka Exp $ */
+/* $Id: nxt_30.h,v 1.25 2007/06/19 23:47:17 tbox Exp $ */
 
 /*!
  *  \brief RFC2535 */
diff --git a/contrib/bind9/lib/dns/rdata/generic/opt_41.c b/contrib/bind9/lib/dns/rdata/generic/opt_41.c
index e8f4816..d2cfc2e 100644
--- a/contrib/bind9/lib/dns/rdata/generic/opt_41.c
+++ b/contrib/bind9/lib/dns/rdata/generic/opt_41.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: opt_41.c,v 1.29.18.2 2005/04/29 00:16:38 marka Exp $ */
+/* $Id: opt_41.c,v 1.33 2007/06/19 23:47:17 tbox Exp $ */
 
 /* Reviewed: Thu Mar 16 14:06:44 PST 2000 by gson */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/opt_41.h b/contrib/bind9/lib/dns/rdata/generic/opt_41.h
index 827936e..d6539cf 100644
--- a/contrib/bind9/lib/dns/rdata/generic/opt_41.h
+++ b/contrib/bind9/lib/dns/rdata/generic/opt_41.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,7 +18,7 @@
 #ifndef GENERIC_OPT_41_H
 #define GENERIC_OPT_41_H 1
 
-/* $Id: opt_41.h,v 1.14.18.2 2005/04/29 00:16:38 marka Exp $ */
+/* $Id: opt_41.h,v 1.18 2007/06/19 23:47:17 tbox Exp $ */
 
 /*!
  *  \brief Per RFC2671 */
diff --git a/contrib/bind9/lib/dns/rdata/generic/proforma.c b/contrib/bind9/lib/dns/rdata/generic/proforma.c
index bf8b2fd..879b761 100644
--- a/contrib/bind9/lib/dns/rdata/generic/proforma.c
+++ b/contrib/bind9/lib/dns/rdata/generic/proforma.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: proforma.c,v 1.34 2004/03/05 05:10:17 marka Exp $ */
+/* $Id: proforma.c,v 1.36 2007/06/19 23:47:17 tbox Exp $ */
 
 #ifndef RDATA_GENERIC_#_#_C
 #define RDATA_GENERIC_#_#_C
diff --git a/contrib/bind9/lib/dns/rdata/generic/proforma.h b/contrib/bind9/lib/dns/rdata/generic/proforma.h
index 89d1606..e5c420a 100644
--- a/contrib/bind9/lib/dns/rdata/generic/proforma.h
+++ b/contrib/bind9/lib/dns/rdata/generic/proforma.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -19,7 +19,7 @@
 #ifndef GENERIC_PROFORMA_H
 #define GENERIC_PROFORMA_H 1
 
-/* $Id: proforma.h,v 1.19.18.2 2005/04/29 00:16:39 marka Exp $ */
+/* $Id: proforma.h,v 1.23 2007/06/19 23:47:17 tbox Exp $ */
 
 typedef struct dns_rdata_# {
 	dns_rdatacommon_t	common;
diff --git a/contrib/bind9/lib/dns/rdata/generic/ptr_12.c b/contrib/bind9/lib/dns/rdata/generic/ptr_12.c
index 16d5706..fbabcbf 100644
--- a/contrib/bind9/lib/dns/rdata/generic/ptr_12.c
+++ b/contrib/bind9/lib/dns/rdata/generic/ptr_12.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ptr_12.c,v 1.41 2004/03/05 05:10:17 marka Exp $ */
+/* $Id: ptr_12.c,v 1.43 2007/06/19 23:47:17 tbox Exp $ */
 
 /* Reviewed: Thu Mar 16 14:05:12 PST 2000 by explorer */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/ptr_12.h b/contrib/bind9/lib/dns/rdata/generic/ptr_12.h
index 4eb8fa7..304dcc4 100644
--- a/contrib/bind9/lib/dns/rdata/generic/ptr_12.h
+++ b/contrib/bind9/lib/dns/rdata/generic/ptr_12.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -19,7 +19,7 @@
 #ifndef GENERIC_PTR_12_H
 #define GENERIC_PTR_12_H 1
 
-/* $Id: ptr_12.h,v 1.23.18.2 2005/04/29 00:16:39 marka Exp $ */
+/* $Id: ptr_12.h,v 1.27 2007/06/19 23:47:17 tbox Exp $ */
 
 typedef struct dns_rdata_ptr {
         dns_rdatacommon_t       common;
diff --git a/contrib/bind9/lib/dns/rdata/generic/rp_17.c b/contrib/bind9/lib/dns/rdata/generic/rp_17.c
index b153643..557cb04 100644
--- a/contrib/bind9/lib/dns/rdata/generic/rp_17.c
+++ b/contrib/bind9/lib/dns/rdata/generic/rp_17.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rp_17.c,v 1.38.18.2 2005/04/29 00:16:39 marka Exp $ */
+/* $Id: rp_17.c,v 1.42 2007/06/19 23:47:17 tbox Exp $ */
 
 /* RFC1183 */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/rp_17.h b/contrib/bind9/lib/dns/rdata/generic/rp_17.h
index 533c7e7..6223038 100644
--- a/contrib/bind9/lib/dns/rdata/generic/rp_17.h
+++ b/contrib/bind9/lib/dns/rdata/generic/rp_17.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,7 +18,7 @@
 #ifndef GENERIC_RP_17_H
 #define GENERIC_RP_17_H 1
 
-/* $Id: rp_17.h,v 1.17.18.2 2005/04/29 00:16:39 marka Exp $ */
+/* $Id: rp_17.h,v 1.21 2007/06/19 23:47:17 tbox Exp $ */
 
 /*!
  *  \brief Per RFC1183 */
diff --git a/contrib/bind9/lib/dns/rdata/generic/rrsig_46.c b/contrib/bind9/lib/dns/rdata/generic/rrsig_46.c
index 6561f28..a9af4bd 100644
--- a/contrib/bind9/lib/dns/rdata/generic/rrsig_46.c
+++ b/contrib/bind9/lib/dns/rdata/generic/rrsig_46.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rrsig_46.c,v 1.5.18.3 2005/04/29 00:16:39 marka Exp $ */
+/* $Id: rrsig_46.c,v 1.10 2007/06/19 23:47:17 tbox Exp $ */
 
 /* Reviewed: Fri Mar 17 09:05:02 PST 2000 by gson */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/rrsig_46.h b/contrib/bind9/lib/dns/rdata/generic/rrsig_46.h
index b8b35a2..8e8dc4e 100644
--- a/contrib/bind9/lib/dns/rdata/generic/rrsig_46.h
+++ b/contrib/bind9/lib/dns/rdata/generic/rrsig_46.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,7 +18,7 @@
 #ifndef GENERIC_DNSSIG_46_H
 #define GENERIC_DNSSIG_46_H 1
 
-/* $Id: rrsig_46.h,v 1.3.20.2 2005/04/29 00:16:39 marka Exp $ */
+/* $Id: rrsig_46.h,v 1.7 2007/06/19 23:47:17 tbox Exp $ */
 
 /*!
  *  \brief Per RFC2535 */
diff --git a/contrib/bind9/lib/dns/rdata/generic/rt_21.c b/contrib/bind9/lib/dns/rdata/generic/rt_21.c
index 6977e98..6444102 100644
--- a/contrib/bind9/lib/dns/rdata/generic/rt_21.c
+++ b/contrib/bind9/lib/dns/rdata/generic/rt_21.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rt_21.c,v 1.41.18.3 2005/04/27 05:01:52 sra Exp $ */
+/* $Id: rt_21.c,v 1.46 2007/06/19 23:47:17 tbox Exp $ */
 
 /* reviewed: Thu Mar 16 15:02:31 PST 2000 by brister */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/rt_21.h b/contrib/bind9/lib/dns/rdata/generic/rt_21.h
index b8ec969..2c0e9fc 100644
--- a/contrib/bind9/lib/dns/rdata/generic/rt_21.h
+++ b/contrib/bind9/lib/dns/rdata/generic/rt_21.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,7 +18,7 @@
 #ifndef GENERIC_RT_21_H
 #define GENERIC_RT_21_H 1
 
-/* $Id: rt_21.h,v 1.17.18.2 2005/04/29 00:16:40 marka Exp $ */
+/* $Id: rt_21.h,v 1.21 2007/06/19 23:47:17 tbox Exp $ */
 
 /*!
  *  \brief Per RFC1183 */
diff --git a/contrib/bind9/lib/dns/rdata/generic/sig_24.c b/contrib/bind9/lib/dns/rdata/generic/sig_24.c
index 9842953..e79e1e4 100644
--- a/contrib/bind9/lib/dns/rdata/generic/sig_24.c
+++ b/contrib/bind9/lib/dns/rdata/generic/sig_24.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: sig_24.c,v 1.62.18.2 2005/04/29 00:16:40 marka Exp $ */
+/* $Id: sig_24.c,v 1.66 2007/06/19 23:47:17 tbox Exp $ */
 
 /* Reviewed: Fri Mar 17 09:05:02 PST 2000 by gson */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/sig_24.h b/contrib/bind9/lib/dns/rdata/generic/sig_24.h
index 96ed767..7212d4d 100644
--- a/contrib/bind9/lib/dns/rdata/generic/sig_24.h
+++ b/contrib/bind9/lib/dns/rdata/generic/sig_24.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,7 +18,7 @@
 #ifndef GENERIC_SIG_24_H
 #define GENERIC_SIG_24_H 1
 
-/* $Id: sig_24.h,v 1.22.18.2 2005/04/29 00:16:40 marka Exp $ */
+/* $Id: sig_24.h,v 1.26 2007/06/19 23:47:17 tbox Exp $ */
 
 /*!
  *  \brief Per RFC2535 */
diff --git a/contrib/bind9/lib/dns/rdata/generic/soa_6.c b/contrib/bind9/lib/dns/rdata/generic/soa_6.c
index 8de678c..921aead 100644
--- a/contrib/bind9/lib/dns/rdata/generic/soa_6.c
+++ b/contrib/bind9/lib/dns/rdata/generic/soa_6.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: soa_6.c,v 1.59 2004/03/05 05:10:18 marka Exp $ */
+/* $Id: soa_6.c,v 1.61.332.2 2009/02/16 23:47:15 tbox Exp $ */
 
 /* Reviewed: Thu Mar 16 15:18:32 PST 2000 by explorer */
 
@@ -101,7 +101,11 @@ totext_soa(ARGS_TOTEXT) {
 	REQUIRE(rdata->length != 0);
 
 	multiline = ISC_TF((tctx->flags & DNS_STYLEFLAG_MULTILINE) != 0);
-	comment = ISC_TF((tctx->flags & DNS_STYLEFLAG_COMMENT) != 0);
+	if (multiline)
+		comment = ISC_TF((tctx->flags & DNS_STYLEFLAG_COMMENT) != 0);
+	else
+		comment = ISC_FALSE;
+
 
 	dns_name_init(&mname, NULL);
 	dns_name_init(&rname, NULL);
@@ -128,16 +132,13 @@ totext_soa(ARGS_TOTEXT) {
 	RETERR(str_totext(tctx->linebreak, target));
 
 	for (i = 0; i < 5; i++) {
-		char buf[sizeof("2147483647")];
+		char buf[sizeof("0123456789 ; ")];
 		unsigned long num;
-		unsigned int numlen;
 		num = uint32_fromregion(&dregion);
 		isc_region_consume(&dregion, 4);
-		numlen = sprintf(buf, "%lu", num);
-		INSIST(numlen > 0 && numlen < sizeof("2147483647"));
+		sprintf(buf, comment ? "%-10lu ; " : "%lu", num);
 		RETERR(str_totext(buf, target));
-		if (multiline && comment) {
-			RETERR(str_totext("           ; " + numlen, target));
+		if (comment) {
 			RETERR(str_totext(soa_fieldnames[i], target));
 			/* Print times in week/day/hour/minute/second form */
 			if (i >= 1) {
@@ -147,7 +148,7 @@ totext_soa(ARGS_TOTEXT) {
 			}
 			RETERR(str_totext(tctx->linebreak, target));
 		} else if (i < 4) {
-			RETERR(str_totext(tctx->linebreak, target));			
+			RETERR(str_totext(tctx->linebreak, target));
 		}
 	}
 
@@ -159,8 +160,8 @@ totext_soa(ARGS_TOTEXT) {
 
 static inline isc_result_t
 fromwire_soa(ARGS_FROMWIRE) {
-        dns_name_t mname;
-        dns_name_t rname;
+	dns_name_t mname;
+	dns_name_t rname;
 	isc_region_t sregion;
 	isc_region_t tregion;
 
@@ -171,11 +172,11 @@ fromwire_soa(ARGS_FROMWIRE) {
 
 	dns_decompress_setmethods(dctx, DNS_COMPRESS_GLOBAL14);
 
-        dns_name_init(&mname, NULL);
-        dns_name_init(&rname, NULL);
+	dns_name_init(&mname, NULL);
+	dns_name_init(&rname, NULL);
 
-        RETERR(dns_name_fromwire(&mname, source, dctx, options, target));
-        RETERR(dns_name_fromwire(&rname, source, dctx, options, target));
+	RETERR(dns_name_fromwire(&mname, source, dctx, options, target));
+	RETERR(dns_name_fromwire(&rname, source, dctx, options, target));
 
 	isc_buffer_activeregion(source, &sregion);
 	isc_buffer_availableregion(target, &tregion);
diff --git a/contrib/bind9/lib/dns/rdata/generic/soa_6.h b/contrib/bind9/lib/dns/rdata/generic/soa_6.h
index 4211786..7443b04 100644
--- a/contrib/bind9/lib/dns/rdata/generic/soa_6.h
+++ b/contrib/bind9/lib/dns/rdata/generic/soa_6.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -19,7 +19,7 @@
 #ifndef GENERIC_SOA_6_H
 #define GENERIC_SOA_6_H 1
 
-/* $Id: soa_6.h,v 1.28.18.2 2005/04/29 00:16:40 marka Exp $ */
+/* $Id: soa_6.h,v 1.32 2007/06/19 23:47:17 tbox Exp $ */
 
 typedef struct dns_rdata_soa {
 	dns_rdatacommon_t	common;
diff --git a/contrib/bind9/lib/dns/rdata/generic/spf_99.c b/contrib/bind9/lib/dns/rdata/generic/spf_99.c
index b65f580..12e813e 100644
--- a/contrib/bind9/lib/dns/rdata/generic/spf_99.c
+++ b/contrib/bind9/lib/dns/rdata/generic/spf_99.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: spf_99.c,v 1.1.2.2 2005/07/16 00:40:54 marka Exp $ */
+/* $Id: spf_99.c,v 1.4 2007/06/19 23:47:17 tbox Exp $ */
 
 /* Reviewed: Thu Mar 16 15:40:00 PST 2000 by bwelling */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/spf_99.h b/contrib/bind9/lib/dns/rdata/generic/spf_99.h
index afe77ec..be5e978 100644
--- a/contrib/bind9/lib/dns/rdata/generic/spf_99.h
+++ b/contrib/bind9/lib/dns/rdata/generic/spf_99.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,7 +18,7 @@
 #ifndef GENERIC_SPF_99_H
 #define GENERIC_SPF_99_H 1
 
-/* $Id: spf_99.h,v 1.1.2.2 2005/07/16 00:40:54 marka Exp $ */
+/* $Id: spf_99.h,v 1.4 2007/06/19 23:47:17 tbox Exp $ */
 
 typedef struct dns_rdata_spf_string {
                 isc_uint8_t    length;
diff --git a/contrib/bind9/lib/dns/rdata/generic/sshfp_44.c b/contrib/bind9/lib/dns/rdata/generic/sshfp_44.c
index 64b51c7..570a3b7 100644
--- a/contrib/bind9/lib/dns/rdata/generic/sshfp_44.c
+++ b/contrib/bind9/lib/dns/rdata/generic/sshfp_44.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2006, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: sshfp_44.c,v 1.3.18.1 2006/03/10 04:04:32 marka Exp $ */
+/* $Id: sshfp_44.c,v 1.7 2007/06/19 23:47:17 tbox Exp $ */
 
 /* RFC 4255 */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/sshfp_44.h b/contrib/bind9/lib/dns/rdata/generic/sshfp_44.h
index 513eeac..daea74c 100644
--- a/contrib/bind9/lib/dns/rdata/generic/sshfp_44.h
+++ b/contrib/bind9/lib/dns/rdata/generic/sshfp_44.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: sshfp_44.h,v 1.2.18.3 2006/03/10 04:04:32 marka Exp $ */
+/* $Id: sshfp_44.h,v 1.8 2007/06/19 23:47:17 tbox Exp $ */
 
 /*!
  *  \brief Per RFC 4255 */
diff --git a/contrib/bind9/lib/dns/rdata/generic/tkey_249.c b/contrib/bind9/lib/dns/rdata/generic/tkey_249.c
index cee16ab..2412c85 100644
--- a/contrib/bind9/lib/dns/rdata/generic/tkey_249.c
+++ b/contrib/bind9/lib/dns/rdata/generic/tkey_249.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: tkey_249.c,v 1.55 2004/03/05 05:10:18 marka Exp $ */
+/* $Id: tkey_249.c,v 1.57 2007/06/19 23:47:17 tbox Exp $ */
 
 /*
  * Reviewed: Thu Mar 16 17:35:30 PST 2000 by halley.
diff --git a/contrib/bind9/lib/dns/rdata/generic/tkey_249.h b/contrib/bind9/lib/dns/rdata/generic/tkey_249.h
index c1d2f06..34d5646 100644
--- a/contrib/bind9/lib/dns/rdata/generic/tkey_249.h
+++ b/contrib/bind9/lib/dns/rdata/generic/tkey_249.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,7 +18,7 @@
 #ifndef GENERIC_TKEY_249_H
 #define GENERIC_TKEY_249_H 1
 
-/* $Id: tkey_249.h,v 1.20.18.2 2005/04/29 00:16:40 marka Exp $ */
+/* $Id: tkey_249.h,v 1.24 2007/06/19 23:47:17 tbox Exp $ */
 
 /*!
  *  \brief Per draft-ietf-dnsind-tkey-00.txt */
diff --git a/contrib/bind9/lib/dns/rdata/generic/txt_16.c b/contrib/bind9/lib/dns/rdata/generic/txt_16.c
index 01ca87a..a158a59 100644
--- a/contrib/bind9/lib/dns/rdata/generic/txt_16.c
+++ b/contrib/bind9/lib/dns/rdata/generic/txt_16.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: txt_16.c,v 1.41.18.2 2008/02/15 23:45:53 tbox Exp $ */
+/* $Id: txt_16.c,v 1.45 2008/02/15 23:46:51 tbox Exp $ */
 
 /* Reviewed: Thu Mar 16 15:40:00 PST 2000 by bwelling */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/txt_16.h b/contrib/bind9/lib/dns/rdata/generic/txt_16.h
index 57d986a..fc46486 100644
--- a/contrib/bind9/lib/dns/rdata/generic/txt_16.h
+++ b/contrib/bind9/lib/dns/rdata/generic/txt_16.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -19,7 +19,7 @@
 #ifndef GENERIC_TXT_16_H
 #define GENERIC_TXT_16_H 1
 
-/* $Id: txt_16.h,v 1.24.18.2 2005/04/29 00:16:40 marka Exp $ */
+/* $Id: txt_16.h,v 1.28 2007/06/19 23:47:17 tbox Exp $ */
 
 typedef struct dns_rdata_txt_string {
                 isc_uint8_t    length;
diff --git a/contrib/bind9/lib/dns/rdata/generic/unspec_103.c b/contrib/bind9/lib/dns/rdata/generic/unspec_103.c
index f316ad9..384863e 100644
--- a/contrib/bind9/lib/dns/rdata/generic/unspec_103.c
+++ b/contrib/bind9/lib/dns/rdata/generic/unspec_103.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: unspec_103.c,v 1.33 2004/03/05 05:10:18 marka Exp $ */
+/* $Id: unspec_103.c,v 1.35 2007/06/19 23:47:17 tbox Exp $ */
 
 #ifndef RDATA_GENERIC_UNSPEC_103_C
 #define RDATA_GENERIC_UNSPEC_103_C
diff --git a/contrib/bind9/lib/dns/rdata/generic/unspec_103.h b/contrib/bind9/lib/dns/rdata/generic/unspec_103.h
index 6575c1a..4b2d310 100644
--- a/contrib/bind9/lib/dns/rdata/generic/unspec_103.h
+++ b/contrib/bind9/lib/dns/rdata/generic/unspec_103.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -19,7 +19,7 @@
 #ifndef GENERIC_UNSPEC_103_H
 #define GENERIC_UNSPEC_103_H 1
 
-/* $Id: unspec_103.h,v 1.13.18.2 2005/04/29 00:16:40 marka Exp $ */
+/* $Id: unspec_103.h,v 1.17 2007/06/19 23:47:17 tbox Exp $ */
 
 typedef struct dns_rdata_unspec_t {
 	dns_rdatacommon_t	common;
diff --git a/contrib/bind9/lib/dns/rdata/generic/x25_19.c b/contrib/bind9/lib/dns/rdata/generic/x25_19.c
index 1199195..c496aaf 100644
--- a/contrib/bind9/lib/dns/rdata/generic/x25_19.c
+++ b/contrib/bind9/lib/dns/rdata/generic/x25_19.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: x25_19.c,v 1.35.18.2 2005/04/29 00:16:40 marka Exp $ */
+/* $Id: x25_19.c,v 1.39 2007/06/19 23:47:17 tbox Exp $ */
 
 /* Reviewed: Thu Mar 16 16:15:57 PST 2000 by bwelling */
 
diff --git a/contrib/bind9/lib/dns/rdata/generic/x25_19.h b/contrib/bind9/lib/dns/rdata/generic/x25_19.h
index 32320d0..5ebc230 100644
--- a/contrib/bind9/lib/dns/rdata/generic/x25_19.h
+++ b/contrib/bind9/lib/dns/rdata/generic/x25_19.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,7 +18,7 @@
 #ifndef GENERIC_X25_19_H
 #define GENERIC_X25_19_H 1
 
-/* $Id: x25_19.h,v 1.14.18.2 2005/04/29 00:16:40 marka Exp $ */
+/* $Id: x25_19.h,v 1.18 2007/06/19 23:47:17 tbox Exp $ */
 
 /*!
  *  \brief Per RFC1183 */
diff --git a/contrib/bind9/lib/dns/rdata/hs_4/a_1.c b/contrib/bind9/lib/dns/rdata/hs_4/a_1.c
index 5d3ddae..487e8bc 100644
--- a/contrib/bind9/lib/dns/rdata/hs_4/a_1.c
+++ b/contrib/bind9/lib/dns/rdata/hs_4/a_1.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: a_1.c,v 1.29 2004/03/05 05:10:20 marka Exp $ */
+/* $Id: a_1.c,v 1.31 2007/06/19 23:47:17 tbox Exp $ */
 
 /* reviewed: Thu Mar 16 15:58:36 PST 2000 by brister */
 
diff --git a/contrib/bind9/lib/dns/rdata/hs_4/a_1.h b/contrib/bind9/lib/dns/rdata/hs_4/a_1.h
index 59f54b5..dee812f 100644
--- a/contrib/bind9/lib/dns/rdata/hs_4/a_1.h
+++ b/contrib/bind9/lib/dns/rdata/hs_4/a_1.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -19,7 +19,7 @@
 #ifndef HS_4_A_1_H
 #define HS_4_A_1_H 1
 
-/* $Id: a_1.h,v 1.8.18.2 2005/04/29 00:16:41 marka Exp $ */
+/* $Id: a_1.h,v 1.12 2007/06/19 23:47:17 tbox Exp $ */
 
 typedef struct dns_rdata_hs_a {
 	dns_rdatacommon_t	common;
diff --git a/contrib/bind9/lib/dns/rdata/in_1/a6_38.c b/contrib/bind9/lib/dns/rdata/in_1/a6_38.c
index 50017e1..d4d42bb 100644
--- a/contrib/bind9/lib/dns/rdata/in_1/a6_38.c
+++ b/contrib/bind9/lib/dns/rdata/in_1/a6_38.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: a6_38.c,v 1.52 2004/03/05 05:10:23 marka Exp $ */
+/* $Id: a6_38.c,v 1.54 2007/06/19 23:47:17 tbox Exp $ */
 
 /* RFC2874 */
 
diff --git a/contrib/bind9/lib/dns/rdata/in_1/a6_38.h b/contrib/bind9/lib/dns/rdata/in_1/a6_38.h
index bb15dad..75e53f1 100644
--- a/contrib/bind9/lib/dns/rdata/in_1/a6_38.h
+++ b/contrib/bind9/lib/dns/rdata/in_1/a6_38.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,7 +18,7 @@
 #ifndef IN_1_A6_38_H
 #define IN_1_A6_38_H 1
 
-/* $Id: a6_38.h,v 1.20.18.2 2005/04/29 00:16:41 marka Exp $ */
+/* $Id: a6_38.h,v 1.24 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! 
  *  \brief Per RFC2874 */
diff --git a/contrib/bind9/lib/dns/rdata/in_1/a_1.c b/contrib/bind9/lib/dns/rdata/in_1/a_1.c
index e8cb8ce..d7644bc 100644
--- a/contrib/bind9/lib/dns/rdata/in_1/a_1.c
+++ b/contrib/bind9/lib/dns/rdata/in_1/a_1.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: a_1.c,v 1.51 2004/03/05 05:10:23 marka Exp $ */
+/* $Id: a_1.c,v 1.53 2007/06/19 23:47:17 tbox Exp $ */
 
 /* Reviewed: Thu Mar 16 16:52:50 PST 2000 by bwelling */
 
diff --git a/contrib/bind9/lib/dns/rdata/in_1/a_1.h b/contrib/bind9/lib/dns/rdata/in_1/a_1.h
index d92a973..c192d1a 100644
--- a/contrib/bind9/lib/dns/rdata/in_1/a_1.h
+++ b/contrib/bind9/lib/dns/rdata/in_1/a_1.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -19,7 +19,7 @@
 #ifndef IN_1_A_1_H
 #define IN_1_A_1_H 1
 
-/* $Id: a_1.h,v 1.24.18.2 2005/04/29 00:16:41 marka Exp $ */
+/* $Id: a_1.h,v 1.28 2007/06/19 23:47:17 tbox Exp $ */
 
 typedef struct dns_rdata_in_a {
 	dns_rdatacommon_t	common;
diff --git a/contrib/bind9/lib/dns/rdata/in_1/aaaa_28.c b/contrib/bind9/lib/dns/rdata/in_1/aaaa_28.c
index 1dd32cf..d0503a9 100644
--- a/contrib/bind9/lib/dns/rdata/in_1/aaaa_28.c
+++ b/contrib/bind9/lib/dns/rdata/in_1/aaaa_28.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: aaaa_28.c,v 1.41.18.2 2005/04/29 00:16:41 marka Exp $ */
+/* $Id: aaaa_28.c,v 1.45 2007/06/19 23:47:17 tbox Exp $ */
 
 /* Reviewed: Thu Mar 16 16:52:50 PST 2000 by bwelling */
 
diff --git a/contrib/bind9/lib/dns/rdata/in_1/aaaa_28.h b/contrib/bind9/lib/dns/rdata/in_1/aaaa_28.h
index 31ad6a6..54a0cb3 100644
--- a/contrib/bind9/lib/dns/rdata/in_1/aaaa_28.h
+++ b/contrib/bind9/lib/dns/rdata/in_1/aaaa_28.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,7 +18,7 @@
 #ifndef IN_1_AAAA_28_H
 #define IN_1_AAAA_28_H 1
 
-/* $Id: aaaa_28.h,v 1.17.18.2 2005/04/29 00:16:42 marka Exp $ */
+/* $Id: aaaa_28.h,v 1.21 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! 
  *  \brief Per RFC1886 */
diff --git a/contrib/bind9/lib/dns/rdata/in_1/apl_42.c b/contrib/bind9/lib/dns/rdata/in_1/apl_42.c
index 2fce328..28ca68e 100644
--- a/contrib/bind9/lib/dns/rdata/in_1/apl_42.c
+++ b/contrib/bind9/lib/dns/rdata/in_1/apl_42.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: apl_42.c,v 1.8.18.4 2008/01/22 23:27:06 tbox Exp $ */
+/* $Id: apl_42.c,v 1.14 2008/01/22 23:28:04 tbox Exp $ */
 
 /* RFC3123 */
 
diff --git a/contrib/bind9/lib/dns/rdata/in_1/apl_42.h b/contrib/bind9/lib/dns/rdata/in_1/apl_42.h
index d434ace..2d01040 100644
--- a/contrib/bind9/lib/dns/rdata/in_1/apl_42.h
+++ b/contrib/bind9/lib/dns/rdata/in_1/apl_42.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -19,7 +19,7 @@
 #ifndef IN_1_APL_42_H
 #define IN_1_APL_42_H 1
 
-/* $Id: apl_42.h,v 1.2.18.2 2005/04/29 00:16:42 marka Exp $ */
+/* $Id: apl_42.h,v 1.6 2007/06/19 23:47:17 tbox Exp $ */
 
 typedef struct dns_rdata_apl_ent {
 	isc_boolean_t	negative;
diff --git a/contrib/bind9/lib/dns/rdata/in_1/dhcid_49.c b/contrib/bind9/lib/dns/rdata/in_1/dhcid_49.c
new file mode 100644
index 0000000..27c4e4e
--- /dev/null
+++ b/contrib/bind9/lib/dns/rdata/in_1/dhcid_49.c
@@ -0,0 +1,229 @@
+/*
+ * Copyright (C) 2006, 2007  Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or 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: dhcid_49.c,v 1.5 2007/06/19 23:47:17 tbox Exp $ */
+
+/* RFC 4701 */
+
+#ifndef RDATA_IN_1_DHCID_49_C
+#define RDATA_IN_1_DHCID_49_C 1
+
+#define RRTYPE_DHCID_ATTRIBUTES 0
+
+static inline isc_result_t
+fromtext_in_dhcid(ARGS_FROMTEXT) {
+
+	REQUIRE(type == 49);
+	REQUIRE(rdclass == 1);
+
+	UNUSED(type);
+	UNUSED(rdclass);
+	UNUSED(origin);
+	UNUSED(options);
+	UNUSED(callbacks);
+
+	return (isc_base64_tobuffer(lexer, target, -1));
+}
+
+static inline isc_result_t
+totext_in_dhcid(ARGS_TOTEXT) {
+	isc_region_t sr;
+	char buf[sizeof(" ; 64000 255 64000")];
+	size_t n;
+
+	REQUIRE(rdata->type == 49);
+	REQUIRE(rdata->rdclass == 1);
+	REQUIRE(rdata->length != 0);
+
+	dns_rdata_toregion(rdata, &sr);
+
+	if ((tctx->flags & DNS_STYLEFLAG_MULTILINE) != 0)
+		RETERR(str_totext("( " /*)*/, target)); 
+	RETERR(isc_base64_totext(&sr, tctx->width - 2, tctx->linebreak,
+				 target));
+	if ((tctx->flags & DNS_STYLEFLAG_MULTILINE) != 0) {
+		RETERR(str_totext(/* ( */ " )", target));
+		if (rdata->length > 2) {
+			n = snprintf(buf, sizeof(buf), " ; %u %u %u",
+				     sr.base[0] * 256 + sr.base[1],
+				     sr.base[2], rdata->length - 3);
+			INSIST(n < sizeof(buf));
+			RETERR(str_totext(buf, target));
+		}
+	}
+	return (ISC_R_SUCCESS);
+}
+
+static inline isc_result_t
+fromwire_in_dhcid(ARGS_FROMWIRE) {
+	isc_region_t sr;
+
+	REQUIRE(type == 49);
+	REQUIRE(rdclass == 1);
+
+	UNUSED(type);
+	UNUSED(rdclass);
+	UNUSED(dctx);
+	UNUSED(options);
+
+	isc_buffer_activeregion(source, &sr);
+	if (sr.length == 0)
+		return (ISC_R_UNEXPECTEDEND);
+
+	isc_buffer_forward(source, sr.length);
+	return (mem_tobuffer(target, sr.base, sr.length));
+}
+
+static inline isc_result_t
+towire_in_dhcid(ARGS_TOWIRE) {
+	isc_region_t sr;
+
+	REQUIRE(rdata->type == 49);
+	REQUIRE(rdata->rdclass == 1);
+	REQUIRE(rdata->length != 0);
+
+	UNUSED(cctx);
+
+	dns_rdata_toregion(rdata, &sr);
+	return (mem_tobuffer(target, sr.base, sr.length));
+}
+
+static inline int
+compare_in_dhcid(ARGS_COMPARE) {
+	isc_region_t r1;
+	isc_region_t r2;
+
+	REQUIRE(rdata1->type == rdata2->type);
+	REQUIRE(rdata1->rdclass == rdata2->rdclass);
+	REQUIRE(rdata1->type == 49);
+	REQUIRE(rdata1->rdclass == 1);
+	REQUIRE(rdata1->length != 0);
+	REQUIRE(rdata2->length != 0);
+
+	dns_rdata_toregion(rdata1, &r1);
+	dns_rdata_toregion(rdata2, &r2);
+	return (isc_region_compare(&r1, &r2));
+}
+
+static inline isc_result_t
+fromstruct_in_dhcid(ARGS_FROMSTRUCT) {
+	dns_rdata_in_dhcid_t *dhcid = source;
+
+	REQUIRE(type == 49);
+	REQUIRE(rdclass == 1);
+	REQUIRE(source != NULL);
+	REQUIRE(dhcid->common.rdtype == type);
+	REQUIRE(dhcid->common.rdclass == rdclass);
+	REQUIRE(dhcid->length != 0);
+
+	UNUSED(type);
+	UNUSED(rdclass);
+
+	return (mem_tobuffer(target, dhcid->dhcid, dhcid->length));
+}
+
+static inline isc_result_t
+tostruct_in_dhcid(ARGS_TOSTRUCT) {
+	dns_rdata_in_dhcid_t *dhcid = target;
+	isc_region_t region;
+
+	REQUIRE(rdata->type == 49);
+	REQUIRE(rdata->rdclass == 1);
+	REQUIRE(target != NULL);
+	REQUIRE(rdata->length != 0);
+
+	dhcid->common.rdclass = rdata->rdclass;
+	dhcid->common.rdtype = rdata->type;
+	ISC_LINK_INIT(&dhcid->common, link);
+
+	dns_rdata_toregion(rdata, &region);
+
+	dhcid->dhcid = mem_maybedup(mctx, region.base, region.length);
+	if (dhcid->dhcid == NULL)
+		return (ISC_R_NOMEMORY);
+
+	dhcid->mctx = mctx;
+	return (ISC_R_SUCCESS);
+}
+
+static inline void
+freestruct_in_dhcid(ARGS_FREESTRUCT) {
+	dns_rdata_in_dhcid_t *dhcid = source;
+
+	REQUIRE(dhcid != NULL);
+	REQUIRE(dhcid->common.rdtype == 49);
+	REQUIRE(dhcid->common.rdclass == 1);
+
+	if (dhcid->mctx == NULL)
+		return;
+
+	if (dhcid->dhcid != NULL)
+		isc_mem_free(dhcid->mctx, dhcid->dhcid);
+	dhcid->mctx = NULL;
+}
+
+static inline isc_result_t
+additionaldata_in_dhcid(ARGS_ADDLDATA) {
+	REQUIRE(rdata->type == 49);
+	REQUIRE(rdata->rdclass == 1);
+
+	UNUSED(rdata);
+	UNUSED(add);
+	UNUSED(arg);
+
+	return (ISC_R_SUCCESS);
+}
+
+static inline isc_result_t
+digest_in_dhcid(ARGS_DIGEST) {
+	isc_region_t r;
+
+	REQUIRE(rdata->type == 49);
+	REQUIRE(rdata->rdclass == 1);
+
+	dns_rdata_toregion(rdata, &r);
+
+	return ((digest)(arg, &r));
+}
+
+static inline isc_boolean_t
+checkowner_in_dhcid(ARGS_CHECKOWNER) {
+
+	REQUIRE(type == 49);
+	REQUIRE(rdclass == 1);
+
+	UNUSED(name);
+	UNUSED(type);
+	UNUSED(rdclass);
+	UNUSED(wildcard);
+
+	return (ISC_TRUE);
+}
+
+static inline isc_boolean_t
+checknames_in_dhcid(ARGS_CHECKNAMES) {
+
+	REQUIRE(rdata->type == 49);
+	REQUIRE(rdata->rdclass == 1);
+
+	UNUSED(rdata);
+	UNUSED(owner);
+	UNUSED(bad);
+
+	return (ISC_TRUE);
+}
+
+#endif	/* RDATA_IN_1_DHCID_49_C */
diff --git a/contrib/bind9/lib/dns/rdata/in_1/dhcid_49.h b/contrib/bind9/lib/dns/rdata/in_1/dhcid_49.h
new file mode 100644
index 0000000..2797192
--- /dev/null
+++ b/contrib/bind9/lib/dns/rdata/in_1/dhcid_49.h
@@ -0,0 +1,30 @@
+/*
+ * Copyright (C) 2006, 2007  Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or 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.
+ */
+
+/* */
+#ifndef IN_1_DHCID_49_H
+#define IN_1_DHCID_49_H 1
+
+/* $Id: dhcid_49.h,v 1.5 2007/06/19 23:47:17 tbox Exp $ */
+
+typedef struct dns_rdata_in_dhcid {
+	dns_rdatacommon_t	common;
+	isc_mem_t		*mctx;
+	unsigned char		*dhcid;
+	unsigned int		length;
+} dns_rdata_in_dhcid_t;
+
+#endif /* IN_1_DHCID_49_H */
diff --git a/contrib/bind9/lib/dns/rdata/in_1/kx_36.c b/contrib/bind9/lib/dns/rdata/in_1/kx_36.c
index 8a64aac..9df2e5e 100644
--- a/contrib/bind9/lib/dns/rdata/in_1/kx_36.c
+++ b/contrib/bind9/lib/dns/rdata/in_1/kx_36.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: kx_36.c,v 1.41.18.2 2005/04/29 00:16:42 marka Exp $ */
+/* $Id: kx_36.c,v 1.45 2007/06/19 23:47:17 tbox Exp $ */
 
 /* Reviewed: Thu Mar 16 17:24:54 PST 2000 by explorer */
 
diff --git a/contrib/bind9/lib/dns/rdata/in_1/kx_36.h b/contrib/bind9/lib/dns/rdata/in_1/kx_36.h
index c44883d..391ae27 100644
--- a/contrib/bind9/lib/dns/rdata/in_1/kx_36.h
+++ b/contrib/bind9/lib/dns/rdata/in_1/kx_36.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,7 +18,7 @@
 #ifndef IN_1_KX_36_H
 #define IN_1_KX_36_H 1
 
-/* $Id: kx_36.h,v 1.16.18.2 2005/04/29 00:16:42 marka Exp $ */
+/* $Id: kx_36.h,v 1.20 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! 
  *  \brief Per RFC2230 */
diff --git a/contrib/bind9/lib/dns/rdata/in_1/naptr_35.c b/contrib/bind9/lib/dns/rdata/in_1/naptr_35.c
index 9a880ea..21ab44c 100644
--- a/contrib/bind9/lib/dns/rdata/in_1/naptr_35.c
+++ b/contrib/bind9/lib/dns/rdata/in_1/naptr_35.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: naptr_35.c,v 1.47.18.4 2008/02/15 23:45:53 tbox Exp $ */
+/* $Id: naptr_35.c,v 1.53 2008/02/15 23:46:51 tbox Exp $ */
 
 /* Reviewed: Thu Mar 16 16:52:50 PST 2000 by bwelling */
 
diff --git a/contrib/bind9/lib/dns/rdata/in_1/naptr_35.h b/contrib/bind9/lib/dns/rdata/in_1/naptr_35.h
index 2578b48..503f7a8 100644
--- a/contrib/bind9/lib/dns/rdata/in_1/naptr_35.h
+++ b/contrib/bind9/lib/dns/rdata/in_1/naptr_35.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,7 +18,7 @@
 #ifndef IN_1_NAPTR_35_H
 #define IN_1_NAPTR_35_H 1
 
-/* $Id: naptr_35.h,v 1.19.18.2 2005/04/29 00:16:42 marka Exp $ */
+/* $Id: naptr_35.h,v 1.23 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! 
  *  \brief Per RFC2915 */
diff --git a/contrib/bind9/lib/dns/rdata/in_1/nsap-ptr_23.c b/contrib/bind9/lib/dns/rdata/in_1/nsap-ptr_23.c
index 1a65cbe..2da7869 100644
--- a/contrib/bind9/lib/dns/rdata/in_1/nsap-ptr_23.c
+++ b/contrib/bind9/lib/dns/rdata/in_1/nsap-ptr_23.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: nsap-ptr_23.c,v 1.34.18.2 2005/04/29 00:16:42 marka Exp $ */
+/* $Id: nsap-ptr_23.c,v 1.38 2007/06/19 23:47:17 tbox Exp $ */
 
 /* Reviewed: Fri Mar 17 10:16:02 PST 2000 by gson */
 
diff --git a/contrib/bind9/lib/dns/rdata/in_1/nsap-ptr_23.h b/contrib/bind9/lib/dns/rdata/in_1/nsap-ptr_23.h
index bd8e025..14a8b19 100644
--- a/contrib/bind9/lib/dns/rdata/in_1/nsap-ptr_23.h
+++ b/contrib/bind9/lib/dns/rdata/in_1/nsap-ptr_23.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,7 +18,7 @@
 #ifndef IN_1_NSAP_PTR_23_H
 #define IN_1_NSAP_PTR_23_H 1
 
-/* $Id: nsap-ptr_23.h,v 1.15.18.2 2005/04/29 00:16:43 marka Exp $ */
+/* $Id: nsap-ptr_23.h,v 1.19 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! 
  *  \brief Per RFC1348.  Obsoleted in RFC 1706 - use PTR instead. */
diff --git a/contrib/bind9/lib/dns/rdata/in_1/nsap_22.c b/contrib/bind9/lib/dns/rdata/in_1/nsap_22.c
index a348a30..c25f560 100644
--- a/contrib/bind9/lib/dns/rdata/in_1/nsap_22.c
+++ b/contrib/bind9/lib/dns/rdata/in_1/nsap_22.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: nsap_22.c,v 1.38.18.2 2005/04/29 00:16:43 marka Exp $ */
+/* $Id: nsap_22.c,v 1.42 2007/06/19 23:47:17 tbox Exp $ */
 
 /* Reviewed: Fri Mar 17 10:41:07 PST 2000 by gson */
 
diff --git a/contrib/bind9/lib/dns/rdata/in_1/nsap_22.h b/contrib/bind9/lib/dns/rdata/in_1/nsap_22.h
index 583fbac..11e3f66 100644
--- a/contrib/bind9/lib/dns/rdata/in_1/nsap_22.h
+++ b/contrib/bind9/lib/dns/rdata/in_1/nsap_22.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,7 +18,7 @@
 #ifndef IN_1_NSAP_22_H
 #define IN_1_NSAP_22_H 1
 
-/* $Id: nsap_22.h,v 1.14.18.2 2005/04/29 00:16:43 marka Exp $ */
+/* $Id: nsap_22.h,v 1.18 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! 
  *  \brief Per RFC1706 */
diff --git a/contrib/bind9/lib/dns/rdata/in_1/px_26.c b/contrib/bind9/lib/dns/rdata/in_1/px_26.c
index 3df9b99..1d17f2f 100644
--- a/contrib/bind9/lib/dns/rdata/in_1/px_26.c
+++ b/contrib/bind9/lib/dns/rdata/in_1/px_26.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: px_26.c,v 1.39.18.2 2005/04/29 00:16:43 marka Exp $ */
+/* $Id: px_26.c,v 1.43 2007/06/19 23:47:17 tbox Exp $ */
 
 /* Reviewed: Mon Mar 20 10:44:27 PST 2000 */
 
diff --git a/contrib/bind9/lib/dns/rdata/in_1/px_26.h b/contrib/bind9/lib/dns/rdata/in_1/px_26.h
index a38d5f81..69a7bae 100644
--- a/contrib/bind9/lib/dns/rdata/in_1/px_26.h
+++ b/contrib/bind9/lib/dns/rdata/in_1/px_26.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,7 +18,7 @@
 #ifndef IN_1_PX_26_H
 #define IN_1_PX_26_H 1
 
-/* $Id: px_26.h,v 1.15.18.2 2005/04/29 00:16:43 marka Exp $ */
+/* $Id: px_26.h,v 1.19 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! 
  *  \brief Per RFC2163 */
diff --git a/contrib/bind9/lib/dns/rdata/in_1/srv_33.c b/contrib/bind9/lib/dns/rdata/in_1/srv_33.c
index 2925a77..7bc85cd 100644
--- a/contrib/bind9/lib/dns/rdata/in_1/srv_33.c
+++ b/contrib/bind9/lib/dns/rdata/in_1/srv_33.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: srv_33.c,v 1.41.18.2 2005/04/29 00:16:43 marka Exp $ */
+/* $Id: srv_33.c,v 1.45 2007/06/19 23:47:17 tbox Exp $ */
 
 /* Reviewed: Fri Mar 17 13:01:00 PST 2000 by bwelling */
 
diff --git a/contrib/bind9/lib/dns/rdata/in_1/srv_33.h b/contrib/bind9/lib/dns/rdata/in_1/srv_33.h
index 7d9fef6..e019698 100644
--- a/contrib/bind9/lib/dns/rdata/in_1/srv_33.h
+++ b/contrib/bind9/lib/dns/rdata/in_1/srv_33.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,7 +18,7 @@
 #ifndef IN_1_SRV_33_H
 #define IN_1_SRV_33_H 1
 
-/* $Id: srv_33.h,v 1.15.18.2 2005/04/29 00:16:43 marka Exp $ */
+/* $Id: srv_33.h,v 1.19 2007/06/19 23:47:17 tbox Exp $ */
 
 /* Reviewed: Fri Mar 17 13:01:00 PST 2000 by bwelling */
 
diff --git a/contrib/bind9/lib/dns/rdata/in_1/wks_11.c b/contrib/bind9/lib/dns/rdata/in_1/wks_11.c
index 749b8fd..55859c4 100644
--- a/contrib/bind9/lib/dns/rdata/in_1/wks_11.c
+++ b/contrib/bind9/lib/dns/rdata/in_1/wks_11.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: wks_11.c,v 1.51.18.1 2004/09/16 01:02:19 marka Exp $ */
+/* $Id: wks_11.c,v 1.54.332.2 2009/02/16 23:47:15 tbox Exp $ */
 
 /* Reviewed: Fri Mar 17 15:01:49 PST 2000 by explorer */
 
@@ -158,6 +158,7 @@ totext_in_wks(ARGS_TOTEXT) {
 	RETERR(str_totext(buf, target));
 	isc_region_consume(&sr, 1);
 
+	INSIST(sr.length <= 8*1024);
 	for (i = 0; i < sr.length; i++) {
 		if (sr.base[i] != 0)
 			for (j = 0; j < 8; j++)
@@ -242,7 +243,8 @@ fromstruct_in_wks(ARGS_FROMSTRUCT) {
 	REQUIRE(source != NULL);
 	REQUIRE(wks->common.rdtype == type);
 	REQUIRE(wks->common.rdclass == rdclass);
-	REQUIRE(wks->map != NULL || wks->map_len == 0);
+	REQUIRE((wks->map != NULL && wks->map_len <= 8*1024) ||
+		 wks->map_len == 0);
 
 	UNUSED(type);
 	UNUSED(rdclass);
diff --git a/contrib/bind9/lib/dns/rdata/in_1/wks_11.h b/contrib/bind9/lib/dns/rdata/in_1/wks_11.h
index a0093b9..2fd26e8 100644
--- a/contrib/bind9/lib/dns/rdata/in_1/wks_11.h
+++ b/contrib/bind9/lib/dns/rdata/in_1/wks_11.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,7 +18,7 @@
 #ifndef IN_1_WKS_11_H
 #define IN_1_WKS_11_H 1
 
-/* $Id: wks_11.h,v 1.20 2004/03/05 05:10:25 marka Exp $ */
+/* $Id: wks_11.h,v 1.22 2007/06/19 23:47:17 tbox Exp $ */
 
 typedef	struct dns_rdata_in_wks {
 	dns_rdatacommon_t	common;
diff --git a/contrib/bind9/lib/dns/rdata/rdatastructpre.h b/contrib/bind9/lib/dns/rdata/rdatastructpre.h
index d641ef5..ab7e051 100644
--- a/contrib/bind9/lib/dns/rdata/rdatastructpre.h
+++ b/contrib/bind9/lib/dns/rdata/rdatastructpre.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdatastructpre.h,v 1.14 2004/03/05 05:10:04 marka Exp $ */
+/* $Id: rdatastructpre.h,v 1.16 2007/06/19 23:47:17 tbox Exp $ */
 
 #ifndef DNS_RDATASTRUCT_H
 #define DNS_RDATASTRUCT_H 1
diff --git a/contrib/bind9/lib/dns/rdata/rdatastructsuf.h b/contrib/bind9/lib/dns/rdata/rdatastructsuf.h
index 1ab1b0a..3ba1275 100644
--- a/contrib/bind9/lib/dns/rdata/rdatastructsuf.h
+++ b/contrib/bind9/lib/dns/rdata/rdatastructsuf.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdatastructsuf.h,v 1.8 2004/03/05 05:10:04 marka Exp $ */
+/* $Id: rdatastructsuf.h,v 1.10 2007/06/19 23:47:17 tbox Exp $ */
 
 ISC_LANG_ENDDECLS
 
diff --git a/contrib/bind9/lib/dns/rdatalist.c b/contrib/bind9/lib/dns/rdatalist.c
index 7229fa3..d6f11ae 100644
--- a/contrib/bind9/lib/dns/rdatalist.c
+++ b/contrib/bind9/lib/dns/rdatalist.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdatalist.c,v 1.28.18.3 2005/04/29 00:16:02 marka Exp $ */
+/* $Id: rdatalist.c,v 1.36 2008/09/24 02:46:22 marka Exp $ */
 
 /*! \file */
 
@@ -26,6 +26,7 @@
 #include <isc/util.h>
 
 #include <dns/name.h>
+#include <dns/nsec3.h>
 #include <dns/rdata.h>
 #include <dns/rdatalist.h>
 #include <dns/rdataset.h>
@@ -41,6 +42,8 @@ static dns_rdatasetmethods_t methods = {
 	isc__rdatalist_count,
 	isc__rdatalist_addnoqname,
 	isc__rdatalist_getnoqname,
+	isc__rdatalist_addclosest,
+	isc__rdatalist_getclosest,
 	NULL,
 	NULL,
 	NULL
@@ -63,8 +66,8 @@ dns_rdatalist_init(dns_rdatalist_t *rdatalist) {
 
 isc_result_t
 dns_rdatalist_tordataset(dns_rdatalist_t *rdatalist,
-			 dns_rdataset_t *rdataset) {
-
+			 dns_rdataset_t *rdataset)
+{
 	/*
 	 * Make 'rdataset' refer to the rdata in 'rdatalist'.
 	 */
@@ -88,6 +91,16 @@ dns_rdatalist_tordataset(dns_rdatalist_t *rdatalist,
 	return (ISC_R_SUCCESS);
 }
 
+isc_result_t
+dns_rdatalist_fromrdataset(dns_rdataset_t *rdataset,
+			   dns_rdatalist_t **rdatalist)
+{
+	REQUIRE(rdatalist != NULL && rdataset != NULL);
+	*rdatalist = rdataset->private1;
+
+	return (ISC_R_SUCCESS);
+}
+
 void
 isc__rdatalist_disassociate(dns_rdataset_t *rdataset) {
 	UNUSED(rdataset);
@@ -161,8 +174,8 @@ isc__rdatalist_count(dns_rdataset_t *rdataset) {
 
 isc_result_t
 isc__rdatalist_addnoqname(dns_rdataset_t *rdataset, dns_name_t *name) {
-	dns_rdataset_t *nsec = NULL;
-	dns_rdataset_t *nsecsig = NULL;
+	dns_rdataset_t *neg = NULL;
+	dns_rdataset_t *negsig = NULL;
 	dns_rdataset_t *rdset;
 	dns_ttl_t ttl;
 
@@ -172,24 +185,33 @@ isc__rdatalist_addnoqname(dns_rdataset_t *rdataset, dns_name_t *name) {
 	{
 		if (rdset->rdclass != rdataset->rdclass)
 			continue;
-		if (rdset->type == dns_rdatatype_nsec)
-			nsec = rdset;
+		if (rdset->type == dns_rdatatype_nsec ||
+		    rdset->type == dns_rdatatype_nsec3)
+			neg = rdset;
+	}
+	if (neg == NULL)
+		return (ISC_R_NOTFOUND);
+
+	for (rdset = ISC_LIST_HEAD(name->list);
+	     rdset != NULL;
+	     rdset = ISC_LIST_NEXT(rdset, link))
+	{
 		if (rdset->type == dns_rdatatype_rrsig &&
-		    rdset->covers == dns_rdatatype_nsec)
-			nsecsig = rdset;
+		    rdset->covers == neg->type)
+			negsig = rdset;
 	}
 
-	if (nsec == NULL || nsecsig == NULL)
+	if (negsig == NULL)
 		return (ISC_R_NOTFOUND);
 	/*
 	 * Minimise ttl.
 	 */
 	ttl = rdataset->ttl;
-	if (nsec->ttl < ttl)
-		ttl = nsec->ttl;
-	if (nsecsig->ttl < ttl)
-		ttl = nsecsig->ttl;
-	rdataset->ttl = nsec->ttl = nsecsig->ttl = ttl;
+	if (neg->ttl < ttl)
+		ttl = neg->ttl;
+	if (negsig->ttl < ttl)
+		ttl = negsig->ttl;
+	rdataset->ttl = neg->ttl = negsig->ttl = ttl;
 	rdataset->attributes |= DNS_RDATASETATTR_NOQNAME;
 	rdataset->private6 = name;
 	return (ISC_R_SUCCESS);
@@ -197,11 +219,11 @@ isc__rdatalist_addnoqname(dns_rdataset_t *rdataset, dns_name_t *name) {
 
 isc_result_t
 isc__rdatalist_getnoqname(dns_rdataset_t *rdataset, dns_name_t *name,
-			 dns_rdataset_t *nsec, dns_rdataset_t *nsecsig)
+			  dns_rdataset_t *neg, dns_rdataset_t *negsig)
 {
 	dns_rdataclass_t rdclass = rdataset->rdclass;
-	dns_rdataset_t *tnsec = NULL;
-	dns_rdataset_t *tnsecsig = NULL;
+	dns_rdataset_t *tneg = NULL;
+	dns_rdataset_t *tnegsig = NULL;
 	dns_name_t *noqname = rdataset->private6;
 
 	REQUIRE((rdataset->attributes & DNS_RDATASETATTR_NOQNAME) != 0);
@@ -213,17 +235,113 @@ isc__rdatalist_getnoqname(dns_rdataset_t *rdataset, dns_name_t *name,
 	{
 		if (rdataset->rdclass != rdclass)
 			continue;
-		if (rdataset->type == dns_rdatatype_nsec)
-			tnsec = rdataset;
+		if (rdataset->type == dns_rdatatype_nsec ||
+		    rdataset->type == dns_rdatatype_nsec3)
+			tneg = rdataset;
+	}
+	if (tneg == NULL)
+		return (ISC_R_NOTFOUND);
+
+	for (rdataset = ISC_LIST_HEAD(noqname->list);
+	     rdataset != NULL;
+	     rdataset = ISC_LIST_NEXT(rdataset, link))
+	{
 		if (rdataset->type == dns_rdatatype_rrsig &&
-		    rdataset->covers == dns_rdatatype_nsec)
-			tnsecsig = rdataset;
+		    rdataset->covers == tneg->type)
+			tnegsig = rdataset;
 	}
-	if (tnsec == NULL || tnsecsig == NULL)
+	if (tnegsig == NULL)
 		return (ISC_R_NOTFOUND);
 
 	dns_name_clone(noqname, name);
-	dns_rdataset_clone(tnsec, nsec);
-	dns_rdataset_clone(tnsecsig, nsecsig);
+	dns_rdataset_clone(tneg, neg);
+	dns_rdataset_clone(tnegsig, negsig);
+	return (ISC_R_SUCCESS);
+}
+
+isc_result_t
+isc__rdatalist_addclosest(dns_rdataset_t *rdataset, dns_name_t *name) {
+	dns_rdataset_t *neg = NULL;
+	dns_rdataset_t *negsig = NULL;
+	dns_rdataset_t *rdset;
+	dns_ttl_t ttl;
+
+	for (rdset = ISC_LIST_HEAD(name->list);
+	     rdset != NULL;
+	     rdset = ISC_LIST_NEXT(rdset, link))
+	{
+		if (rdset->rdclass != rdataset->rdclass)
+			continue;
+		if (rdset->type == dns_rdatatype_nsec ||
+		    rdset->type == dns_rdatatype_nsec3)
+			neg = rdset;
+	}
+	if (neg == NULL)
+		return (ISC_R_NOTFOUND);
+
+	for (rdset = ISC_LIST_HEAD(name->list);
+	     rdset != NULL;
+	     rdset = ISC_LIST_NEXT(rdset, link))
+	{
+		if (rdset->type == dns_rdatatype_rrsig &&
+		    rdset->covers == neg->type)
+			negsig = rdset;
+	}
+
+	if (negsig == NULL)
+		return (ISC_R_NOTFOUND);
+	/*
+	 * Minimise ttl.
+	 */
+	ttl = rdataset->ttl;
+	if (neg->ttl < ttl)
+		ttl = neg->ttl;
+	if (negsig->ttl < ttl)
+		ttl = negsig->ttl;
+	rdataset->ttl = neg->ttl = negsig->ttl = ttl;
+	rdataset->attributes |= DNS_RDATASETATTR_CLOSEST;
+	rdataset->private7 = name;
+	return (ISC_R_SUCCESS);
+}
+
+isc_result_t
+isc__rdatalist_getclosest(dns_rdataset_t *rdataset, dns_name_t *name,
+			  dns_rdataset_t *neg, dns_rdataset_t *negsig)
+{
+	dns_rdataclass_t rdclass = rdataset->rdclass;
+	dns_rdataset_t *tneg = NULL;
+	dns_rdataset_t *tnegsig = NULL;
+	dns_name_t *closest = rdataset->private7;
+
+	REQUIRE((rdataset->attributes & DNS_RDATASETATTR_CLOSEST) != 0);
+	(void)dns_name_dynamic(closest);	/* Sanity Check. */
+
+	for (rdataset = ISC_LIST_HEAD(closest->list);
+	     rdataset != NULL;
+	     rdataset = ISC_LIST_NEXT(rdataset, link))
+	{
+		if (rdataset->rdclass != rdclass)
+			continue;
+		if (rdataset->type == dns_rdatatype_nsec ||
+		    rdataset->type == dns_rdatatype_nsec3)
+			tneg = rdataset;
+	}
+	if (tneg == NULL)
+		return (ISC_R_NOTFOUND);
+
+	for (rdataset = ISC_LIST_HEAD(closest->list);
+	     rdataset != NULL;
+	     rdataset = ISC_LIST_NEXT(rdataset, link))
+	{
+		if (rdataset->type == dns_rdatatype_rrsig &&
+		    rdataset->covers == tneg->type)
+			tnegsig = rdataset;
+	}
+	if (tnegsig == NULL)
+		return (ISC_R_NOTFOUND);
+
+	dns_name_clone(closest, name);
+	dns_rdataset_clone(tneg, neg);
+	dns_rdataset_clone(tnegsig, negsig);
 	return (ISC_R_SUCCESS);
 }
diff --git a/contrib/bind9/lib/dns/rdatalist_p.h b/contrib/bind9/lib/dns/rdatalist_p.h
index d697fec..3e73e20 100644
--- a/contrib/bind9/lib/dns/rdatalist_p.h
+++ b/contrib/bind9/lib/dns/rdatalist_p.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdatalist_p.h,v 1.5.18.2 2005/04/29 00:16:03 marka Exp $ */
+/* $Id: rdatalist_p.h,v 1.11 2008/09/25 04:02:38 tbox Exp $ */
 
 #ifndef DNS_RDATALIST_P_H
 #define DNS_RDATALIST_P_H
@@ -50,7 +50,14 @@ isc__rdatalist_addnoqname(dns_rdataset_t *rdataset, dns_name_t *name);
 
 isc_result_t
 isc__rdatalist_getnoqname(dns_rdataset_t *rdataset, dns_name_t *name,
-			  dns_rdataset_t *nsec, dns_rdataset_t *nsecsig);
+			  dns_rdataset_t *neg, dns_rdataset_t *negsig);
+
+isc_result_t
+isc__rdatalist_addclosest(dns_rdataset_t *rdataset, dns_name_t *name);
+
+isc_result_t
+isc__rdatalist_getclosest(dns_rdataset_t *rdataset, dns_name_t *name,
+			  dns_rdataset_t *neg, dns_rdataset_t *negsig);
 
 ISC_LANG_ENDDECLS
 
diff --git a/contrib/bind9/lib/dns/rdataset.c b/contrib/bind9/lib/dns/rdataset.c
index c86b3c5..6088a06 100644
--- a/contrib/bind9/lib/dns/rdataset.c
+++ b/contrib/bind9/lib/dns/rdataset.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdataset.c,v 1.72.18.5 2006/03/02 00:37:21 marka Exp $ */
+/* $Id: rdataset.c,v 1.82.50.2 2009/01/18 23:47:40 tbox Exp $ */
 
 /*! \file */
 
@@ -59,6 +59,7 @@ dns_rdataset_init(dns_rdataset_t *rdataset) {
 	rdataset->privateuint4 = 0;
 	rdataset->private5 = NULL;
 	rdataset->private6 = NULL;
+	rdataset->resign = 0;
 }
 
 void
@@ -137,7 +138,7 @@ question_disassociate(dns_rdataset_t *rdataset) {
 static isc_result_t
 question_cursor(dns_rdataset_t *rdataset) {
 	UNUSED(rdataset);
-	
+
 	return (ISC_R_NOMORE);
 }
 
@@ -148,7 +149,7 @@ question_current(dns_rdataset_t *rdataset, dns_rdata_t *rdata) {
 	 */
 	UNUSED(rdataset);
 	UNUSED(rdata);
-	
+
 	REQUIRE(0);
 }
 
@@ -179,6 +180,8 @@ static dns_rdatasetmethods_t question_methods = {
 	NULL,
 	NULL,
 	NULL,
+	NULL,
+	NULL,
 	NULL
 };
 
@@ -339,7 +342,7 @@ towiresorted(dns_rdataset_t *rdataset, const dns_name_t *owner_name,
 	}
 
 	/*
-	 * Do we want to shuffle this anwer?
+	 * Do we want to shuffle this answer?
 	 */
 	if (!question && count > 1 &&
 	    (!WANT_FIXED(rdataset) || order != NULL) &&
@@ -445,7 +448,7 @@ towiresorted(dns_rdataset_t *rdataset, const dns_name_t *owner_name,
 		/*
 		 * Copy out the name, type, class, ttl.
 		 */
-		
+
 		rrbuffer = *target;
 		dns_compress_setmethods(cctx, DNS_COMPRESS_GLOBAL14);
 		result = dns_name_towire(owner_name, cctx, target);
@@ -620,14 +623,36 @@ dns_rdataset_addnoqname(dns_rdataset_t *rdataset, dns_name_t *name) {
 
 isc_result_t
 dns_rdataset_getnoqname(dns_rdataset_t *rdataset, dns_name_t *name,
-		        dns_rdataset_t *nsec, dns_rdataset_t *nsecsig)
+			dns_rdataset_t *neg, dns_rdataset_t *negsig)
 {
 	REQUIRE(DNS_RDATASET_VALID(rdataset));
 	REQUIRE(rdataset->methods != NULL);
 
 	if (rdataset->methods->getnoqname == NULL)
 		return (ISC_R_NOTIMPLEMENTED);
-	return((rdataset->methods->getnoqname)(rdataset, name, nsec, nsecsig));
+	return((rdataset->methods->getnoqname)(rdataset, name, neg, negsig));
+}
+
+isc_result_t
+dns_rdataset_addclosest(dns_rdataset_t *rdataset, dns_name_t *name) {
+
+	REQUIRE(DNS_RDATASET_VALID(rdataset));
+	REQUIRE(rdataset->methods != NULL);
+	if (rdataset->methods->addclosest == NULL)
+		return (ISC_R_NOTIMPLEMENTED);
+	return((rdataset->methods->addclosest)(rdataset, name));
+}
+
+isc_result_t
+dns_rdataset_getclosest(dns_rdataset_t *rdataset, dns_name_t *name,
+			dns_rdataset_t *neg, dns_rdataset_t *negsig)
+{
+	REQUIRE(DNS_RDATASET_VALID(rdataset));
+	REQUIRE(rdataset->methods != NULL);
+
+	if (rdataset->methods->getclosest == NULL)
+		return (ISC_R_NOTIMPLEMENTED);
+	return((rdataset->methods->getclosest)(rdataset, name, neg, negsig));
 }
 
 /*
diff --git a/contrib/bind9/lib/dns/rdatasetiter.c b/contrib/bind9/lib/dns/rdatasetiter.c
index 8089e04..7ed3030 100644
--- a/contrib/bind9/lib/dns/rdatasetiter.c
+++ b/contrib/bind9/lib/dns/rdatasetiter.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdatasetiter.c,v 1.12.18.2 2005/04/29 00:16:03 marka Exp $ */
+/* $Id: rdatasetiter.c,v 1.16 2007/06/19 23:47:16 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/dns/rdataslab.c b/contrib/bind9/lib/dns/rdataslab.c
index 5d89d01..b22868d 100644
--- a/contrib/bind9/lib/dns/rdataslab.c
+++ b/contrib/bind9/lib/dns/rdataslab.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rdataslab.c,v 1.35.18.8 2007/08/28 07:20:05 tbox Exp $ */
+/* $Id: rdataslab.c,v 1.48.50.2 2009/01/18 23:47:40 tbox Exp $ */
 
 /*! \file */
 
@@ -33,10 +33,6 @@
 #include <dns/rdataset.h>
 #include <dns/rdataslab.h>
 
-#ifndef DNS_RDATASET_FIXED
-#define DNS_RDATASET_FIXED 1
-#endif
-
 /*
  * The rdataslab structure allows iteration to occur in both load order
  * and DNSSEC order.  The structure is as follows:
@@ -47,6 +43,7 @@
  *	data records
  *		data length	(2 bytes)
  *		order		(2 bytes)
+ *		meta data	(1 byte for RRSIG's)
  *		data		(data length bytes)
  *
  * If DNS_RDATASET_FIXED is defined to be zero (0) the format of a
@@ -65,7 +62,7 @@
  *
  * DNSSEC order traversal is performed by walking the data records.
  *
- * The order is stored with record to allow for efficient reconstuction of
+ * The order is stored with record to allow for efficient reconstruction
  * of the offset table following a merge or subtraction.
  *
  * The iterator methods here currently only support DNSSEC order iteration.
@@ -141,6 +138,7 @@ dns_rdataslab_fromrdataset(dns_rdataset_t *rdataset, isc_mem_t *mctx,
 #if DNS_RDATASET_FIXED
 	unsigned int   *offsettable;
 #endif
+	unsigned int	length;
 
 	buflen = reservelen + 2;
 
@@ -209,12 +207,18 @@ dns_rdataslab_fromrdataset(dns_rdataset_t *rdataset, isc_mem_t *mctx,
 				x[i].order = x[i-1].order;
 #endif
 			nitems--;
-		} else
+		} else {
 #if DNS_RDATASET_FIXED
 			buflen += (8 + x[i-1].rdata.length);
 #else
 			buflen += (2 + x[i-1].rdata.length);
 #endif
+			/*
+			 * Provide space to store the per RR meta data.
+			 */
+			if (rdataset->type == dns_rdatatype_rrsig)
+				buflen++;
+		}
 	}
 	/*
 	 * Don't forget the last item!
@@ -224,6 +228,11 @@ dns_rdataslab_fromrdataset(dns_rdataset_t *rdataset, isc_mem_t *mctx,
 #else
 	buflen += (2 + x[i-1].rdata.length);
 #endif
+	/*
+	 * Provide space to store the per RR meta data.
+	 */
+	if (rdataset->type == dns_rdatatype_rrsig)
+		buflen++;
 
 	/*
 	 * Ensure that singleton types are actually singletons.
@@ -246,7 +255,7 @@ dns_rdataslab_fromrdataset(dns_rdataset_t *rdataset, isc_mem_t *mctx,
 		result = ISC_R_NOMEMORY;
 		goto free_rdatas;
 	}
-	
+
 #if DNS_RDATASET_FIXED
 	/* Allocate temporary offset table. */
 	offsettable = isc_mem_get(mctx, nalloc * sizeof(unsigned int));
@@ -280,15 +289,25 @@ dns_rdataslab_fromrdataset(dns_rdataset_t *rdataset, isc_mem_t *mctx,
 #if DNS_RDATASET_FIXED
 		offsettable[x[i].order] = rawbuf - offsetbase;
 #endif
-		*rawbuf++ = (x[i].rdata.length & 0xff00) >> 8;
-		*rawbuf++ = (x[i].rdata.length & 0x00ff);
+		length = x[i].rdata.length;
+		if (rdataset->type == dns_rdatatype_rrsig)
+			length++;
+		*rawbuf++ = (length & 0xff00) >> 8;
+		*rawbuf++ = (length & 0x00ff);
 #if DNS_RDATASET_FIXED
 		rawbuf += 2;	/* filled in later */
 #endif
+		/*
+		 * Store the per RR meta data.
+		 */
+		if (rdataset->type == dns_rdatatype_rrsig) {
+			*rawbuf++ |= (x[i].rdata.flags & DNS_RDATA_OFFLINE) ?
+					    DNS_RDATASLAB_OFFLINE : 0;
+		}
 		memcpy(rawbuf, x[i].rdata.data, x[i].rdata.length);
 		rawbuf += x[i].rdata.length;
 	}
-	
+
 #if DNS_RDATASET_FIXED
 	fillin_offsets(offsetbase, offsettable, nalloc);
 	isc_mem_put(mctx, offsettable, nalloc * sizeof(unsigned int));
@@ -360,17 +379,27 @@ static void
 rdataset_current(dns_rdataset_t *rdataset, dns_rdata_t *rdata) {
 	unsigned char *raw = rdataset->private5;
 	isc_region_t r;
+	unsigned int length;
+	unsigned int flags = 0;
 
 	REQUIRE(raw != NULL);
 
-	r.length = raw[0] * 256 + raw[1];
+	length = raw[0] * 256 + raw[1];
 #if DNS_RDATASET_FIXED
 	raw += 4;
 #else
 	raw += 2;
-#endif 
+#endif
+	if (rdataset->type == dns_rdatatype_rrsig) {
+		if (*raw & DNS_RDATASLAB_OFFLINE)
+			flags |= DNS_RDATA_OFFLINE;
+		length--;
+		raw++;
+	}
+	r.length = length;
 	r.base = raw;
 	dns_rdata_fromregion(rdata, rdataset->rdclass, rdataset->type, &r);
+	rdata->flags |= flags;
 }
 
 static void
@@ -405,6 +434,8 @@ static dns_rdatasetmethods_t rdataset_methods = {
 	NULL,
 	NULL,
 	NULL,
+	NULL,
+	NULL,
 	NULL
 };
 
@@ -474,15 +505,27 @@ rdata_from_slab(unsigned char **current,
 {
 	unsigned char *tcurrent = *current;
 	isc_region_t region;
+	unsigned int length;
+	isc_boolean_t offline = ISC_FALSE;
 
-	region.length = *tcurrent++ * 256;
-	region.length += *tcurrent++;
+	length = *tcurrent++ * 256;
+	length += *tcurrent++;
+
+	if (type == dns_rdatatype_rrsig) {
+		if ((*tcurrent & DNS_RDATASLAB_OFFLINE) != 0)
+			offline = ISC_TRUE;
+		length--;
+		tcurrent++;
+	}
+	region.length = length;
 #if DNS_RDATASET_FIXED
 	tcurrent += 2;
 #endif
 	region.base = tcurrent;
 	tcurrent += region.length;
 	dns_rdata_fromregion(rdata, rdclass, type, &region);
+	if (offline)
+		rdata->flags |= DNS_RDATA_OFFLINE;
 	*current = tcurrent;
 }
 
@@ -511,7 +554,7 @@ rdata_in_slab(unsigned char *slab, unsigned int reservelen,
 
 	for (i = 0; i < count; i++) {
 		rdata_from_slab(&current, rdclass, type, &trdata);
-		
+
 		n = dns_rdata_compare(&trdata, rdata);
 		if (n == 0)
 			return (ISC_TRUE);
@@ -528,9 +571,8 @@ dns_rdataslab_merge(unsigned char *oslab, unsigned char *nslab,
 		    dns_rdataclass_t rdclass, dns_rdatatype_t type,
 		    unsigned int flags, unsigned char **tslabp)
 {
-	unsigned char *ocurrent, *ostart, *ncurrent, *tstart, *tcurrent;
+	unsigned char *ocurrent, *ostart, *ncurrent, *tstart, *tcurrent, *data;
 	unsigned int ocount, ncount, count, olength, tlength, tcount, length;
-	isc_region_t nregion;
 	dns_rdata_t ordata = DNS_RDATA_INIT;
 	dns_rdata_t nrdata = DNS_RDATA_INIT;
 	isc_boolean_t added_something = ISC_FALSE;
@@ -603,29 +645,24 @@ dns_rdataslab_merge(unsigned char *oslab, unsigned char *nslab,
 	 * the old slab.
 	 */
 	do {
-		nregion.length = *ncurrent++ * 256;
-		nregion.length += *ncurrent++;
-#if DNS_RDATASET_FIXED
-		ncurrent += 2;			/* Skip order. */
-#endif
-		nregion.base = ncurrent;
 		dns_rdata_init(&nrdata);
-		dns_rdata_fromregion(&nrdata, rdclass, type, &nregion);
+		rdata_from_slab(&ncurrent, rdclass, type, &nrdata);
 		if (!rdata_in_slab(oslab, reservelen, rdclass, type, &nrdata))
 		{
 			/*
 			 * This rdata isn't in the old slab.
 			 */
 #if DNS_RDATASET_FIXED
-			tlength += nregion.length + 8;
+			tlength += nrdata.length + 8;
 #else
-			tlength += nregion.length + 2;
+			tlength += nrdata.length + 2;
 #endif
+			if (type == dns_rdatatype_rrsig)
+				tlength++;
 			tcount++;
 			nncount++;
 			added_something = ISC_TRUE;
 		}
-		ncurrent += nregion.length;
 		ncount--;
 	} while (ncount > 0);
 	ncount = nncount;
@@ -726,12 +763,17 @@ dns_rdataslab_merge(unsigned char *oslab, unsigned char *nslab,
 			offsettable[oorder] = tcurrent - offsetbase;
 #endif
 			length = ordata.length;
+			data = ordata.data;
+			if (type == dns_rdatatype_rrsig) {
+				length++;
+				data--;
+			}
 			*tcurrent++ = (length & 0xff00) >> 8;
 			*tcurrent++ = (length & 0x00ff);
 #if DNS_RDATASET_FIXED
 			tcurrent += 2;	/* fill in later */
 #endif
-			memcpy(tcurrent, ordata.data, length);
+			memcpy(tcurrent, data, length);
 			tcurrent += length;
 			oadded++;
 			if (oadded < ocount) {
@@ -748,12 +790,17 @@ dns_rdataslab_merge(unsigned char *oslab, unsigned char *nslab,
 			offsettable[ocount + norder] = tcurrent - offsetbase;
 #endif
 			length = nrdata.length;
+			data = nrdata.data;
+			if (type == dns_rdatatype_rrsig) {
+				length++;
+				data--;
+			}
 			*tcurrent++ = (length & 0xff00) >> 8;
 			*tcurrent++ = (length & 0x00ff);
 #if DNS_RDATASET_FIXED
 			tcurrent += 2;	/* fill in later */
 #endif
-			memcpy(tcurrent, nrdata.data, length);
+			memcpy(tcurrent, data, length);
 			tcurrent += length;
 			nadded++;
 			if (nadded < ncount) {
@@ -799,8 +846,8 @@ dns_rdataslab_subtract(unsigned char *mslab, unsigned char *sslab,
 #if DNS_RDATASET_FIXED
 	unsigned char *offsetbase;
 	unsigned int *offsettable;
-#endif
 	unsigned int order;
+#endif
 
 	REQUIRE(tslabp != NULL && *tslabp == NULL);
 	REQUIRE(mslab != NULL && sslab != NULL);
diff --git a/contrib/bind9/lib/dns/request.c b/contrib/bind9/lib/dns/request.c
index 64a3a4e..ac844e1 100644
--- a/contrib/bind9/lib/dns/request.c
+++ b/contrib/bind9/lib/dns/request.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: request.c,v 1.72.18.8 2008/07/22 03:51:44 marka Exp $ */
+/* $Id: request.c,v 1.82.72.2 2009/01/18 23:47:40 tbox Exp $ */
 
 /*! \file */
 
@@ -95,7 +95,7 @@ struct dns_request {
 #define DNS_REQUEST_F_SENDING 0x0002
 #define DNS_REQUEST_F_CANCELED 0x0004	/*%< ctlevent received, or otherwise
 					   synchronously canceled */
-#define DNS_REQUEST_F_TIMEDOUT 0x0008	/*%< cancelled due to a timeout */
+#define DNS_REQUEST_F_TIMEDOUT 0x0008	/*%< canceled due to a timeout */
 #define DNS_REQUEST_F_TCP 0x0010	/*%< This request used TCP */
 #define DNS_REQUEST_CANCELED(r) \
 	(((r)->flags & DNS_REQUEST_F_CANCELED) != 0)
@@ -197,7 +197,7 @@ dns_requestmgr_create(isc_mem_t *mctx,
 		dns_dispatch_attach(dispatchv6, &requestmgr->dispatchv6);
 	requestmgr->mctx = NULL;
 	isc_mem_attach(mctx, &requestmgr->mctx);
-	requestmgr->eref = 1;	/* implict attach */
+	requestmgr->eref = 1;	/* implicit attach */
 	requestmgr->iref = 0;
 	ISC_LIST_INIT(requestmgr->whenshutdown);
 	ISC_LIST_INIT(requestmgr->requests);
diff --git a/contrib/bind9/lib/dns/resolver.c b/contrib/bind9/lib/dns/resolver.c
index dc648c9..a1c263e 100644
--- a/contrib/bind9/lib/dns/resolver.c
+++ b/contrib/bind9/lib/dns/resolver.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,15 +15,18 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: resolver.c,v 1.284.18.79 2008/10/17 22:02:13 jinmei Exp $ */
+/* $Id: resolver.c,v 1.384.14.12 2009/05/11 02:38:03 tbox Exp $ */
 
 /*! \file */
 
 #include <config.h>
 
+#include <isc/platform.h>
 #include <isc/print.h>
 #include <isc/string.h>
+#include <isc/random.h>
 #include <isc/task.h>
+#include <isc/stats.h>
 #include <isc/timer.h>
 #include <isc/util.h>
 
@@ -52,22 +55,23 @@
 #include <dns/resolver.h>
 #include <dns/result.h>
 #include <dns/rootns.h>
+#include <dns/stats.h>
 #include <dns/tsig.h>
 #include <dns/validator.h>
 
 #define DNS_RESOLVER_TRACE
 #ifdef DNS_RESOLVER_TRACE
-#define RTRACE(m)	isc_log_write(dns_lctx, \
+#define RTRACE(m)       isc_log_write(dns_lctx, \
 				      DNS_LOGCATEGORY_RESOLVER, \
 				      DNS_LOGMODULE_RESOLVER, \
 				      ISC_LOG_DEBUG(3), \
 				      "res %p: %s", res, (m))
-#define RRTRACE(r, m)	isc_log_write(dns_lctx, \
+#define RRTRACE(r, m)   isc_log_write(dns_lctx, \
 				      DNS_LOGCATEGORY_RESOLVER, \
 				      DNS_LOGMODULE_RESOLVER, \
 				      ISC_LOG_DEBUG(3), \
 				      "res %p: %s", (r), (m))
-#define FCTXTRACE(m)	isc_log_write(dns_lctx, \
+#define FCTXTRACE(m)    isc_log_write(dns_lctx, \
 				      DNS_LOGCATEGORY_RESOLVER, \
 				      DNS_LOGMODULE_RESOLVER, \
 				      ISC_LOG_DEBUG(3), \
@@ -79,14 +83,14 @@
 				      ISC_LOG_DEBUG(3), \
 				      "fctx %p(%s): %s %s", \
 				      fctx, fctx->info, (m1), (m2))
-#define FTRACE(m)	isc_log_write(dns_lctx, \
+#define FTRACE(m)       isc_log_write(dns_lctx, \
 				      DNS_LOGCATEGORY_RESOLVER, \
 				      DNS_LOGMODULE_RESOLVER, \
 				      ISC_LOG_DEBUG(3), \
 				      "fetch %p (fctx %p(%s)): %s", \
 				      fetch, fetch->private, \
 				      fetch->private->info, (m))
-#define QTRACE(m)	isc_log_write(dns_lctx, \
+#define QTRACE(m)       isc_log_write(dns_lctx, \
 				      DNS_LOGCATEGORY_RESOLVER, \
 				      DNS_LOGMODULE_RESOLVER, \
 				      ISC_LOG_DEBUG(3), \
@@ -104,13 +108,13 @@
 /*%
  * Maximum EDNS0 input packet size.
  */
-#define RECV_BUFFER_SIZE		4096		/* XXXRTH  Constant. */
+#define RECV_BUFFER_SIZE                4096            /* XXXRTH  Constant. */
 
 /*%
  * This defines the maximum number of timeouts we will permit before we
  * disable EDNS0 on the query.
  */
-#define MAX_EDNS0_TIMEOUTS	3
+#define MAX_EDNS0_TIMEOUTS      3
 
 typedef struct fetchctx fetchctx_t;
 
@@ -141,19 +145,25 @@ typedef struct query {
 #define QUERY_MAGIC			ISC_MAGIC('Q', '!', '!', '!')
 #define VALID_QUERY(query)		ISC_MAGIC_VALID(query, QUERY_MAGIC)
 
-#define RESQUERY_ATTR_CANCELED		0x02
+#define RESQUERY_ATTR_CANCELED          0x02
 
-#define RESQUERY_CONNECTING(q)		((q)->connects > 0)
-#define RESQUERY_CANCELED(q)		(((q)->attributes & \
+#define RESQUERY_CONNECTING(q)          ((q)->connects > 0)
+#define RESQUERY_CANCELED(q)            (((q)->attributes & \
 					  RESQUERY_ATTR_CANCELED) != 0)
-#define RESQUERY_SENDING(q)		((q)->sends > 0)
+#define RESQUERY_SENDING(q)             ((q)->sends > 0)
 
 typedef enum {
-	fetchstate_init = 0,		/*%< Start event has not run yet. */
+	fetchstate_init = 0,            /*%< Start event has not run yet. */
 	fetchstate_active,
-	fetchstate_done			/*%< FETCHDONE events posted. */
+	fetchstate_done                 /*%< FETCHDONE events posted. */
 } fetchstate;
 
+typedef enum {
+	badns_unreachable = 0,
+	badns_response,
+	badns_validation
+} badnstype_t;
+
 struct fetchctx {
 	/*% Not locked. */
 	unsigned int			magic;
@@ -162,7 +172,7 @@ struct fetchctx {
 	dns_rdatatype_t			type;
 	unsigned int			options;
 	unsigned int			bucketnum;
-	char *				info;
+	char *			info;
 	/*% Locked by appropriate bucket lock. */
 	fetchstate			state;
 	isc_boolean_t			want_shutdown;
@@ -170,8 +180,8 @@ struct fetchctx {
 	isc_boolean_t			spilled;
 	unsigned int			references;
 	isc_event_t			control_event;
-	ISC_LINK(struct fetchctx)	link;
-	ISC_LIST(dns_fetchevent_t)	events;
+	ISC_LINK(struct fetchctx)       link;
+	ISC_LIST(dns_fetchevent_t)      events;
 	/*% Locked by task event serialization. */
 	dns_name_t			domain;
 	dns_rdataset_t			nameservers;
@@ -194,7 +204,7 @@ struct fetchctx {
 	isc_sockaddrlist_t		edns;
 	isc_sockaddrlist_t		edns512;
 	dns_validator_t			*validator;
-	ISC_LIST(dns_validator_t)	validators;
+	ISC_LIST(dns_validator_t)       validators;
 	dns_db_t *			cache;
 	dns_adb_t *			adb;
 
@@ -219,6 +229,7 @@ struct fetchctx {
 	 * is used for EDNS0 black hole detection.
 	 */
 	unsigned int			timeouts;
+
 	/*%
 	 * Look aside state for DS lookups.
 	 */
@@ -230,34 +241,65 @@ struct fetchctx {
 	 * Number of queries that reference this context.
 	 */
 	unsigned int			nqueries;
+
+	/*%
+	 * The reason to print when logging a successful
+	 * response to a query.
+	 */
+	const char *			reason;
+
+	/*%
+	 * Random numbers to use for mixing up server addresses.
+	 */
+	isc_uint32_t                    rand_buf;
+	isc_uint32_t                    rand_bits;
+
+	/*%
+	 * Fetch-local statistics for detailed logging.
+	 */
+	isc_result_t			result; /*%< fetch result  */
+	isc_result_t			vresult; /*%< validation result  */
+	int				exitline;
+	isc_time_t			start;
+	isc_uint64_t			duration;
+	isc_boolean_t			logged;
+	unsigned int			querysent;
+	unsigned int			referrals;
+	unsigned int			lamecount;
+	unsigned int			neterr;
+	unsigned int			badresp;
+	unsigned int			adberr;
+	unsigned int			findfail;
+	unsigned int			valfail;
+	isc_boolean_t			timeout;
 };
 
 #define FCTX_MAGIC			ISC_MAGIC('F', '!', '!', '!')
 #define VALID_FCTX(fctx)		ISC_MAGIC_VALID(fctx, FCTX_MAGIC)
 
-#define FCTX_ATTR_HAVEANSWER		0x0001
-#define FCTX_ATTR_GLUING		0x0002
-#define FCTX_ATTR_ADDRWAIT		0x0004
-#define FCTX_ATTR_SHUTTINGDOWN		0x0008
-#define FCTX_ATTR_WANTCACHE		0x0010
-#define FCTX_ATTR_WANTNCACHE		0x0020
-#define FCTX_ATTR_NEEDEDNS0		0x0040
-#define FCTX_ATTR_TRIEDFIND		0x0080
-#define FCTX_ATTR_TRIEDALT		0x0100
-
-#define HAVE_ANSWER(f)		(((f)->attributes & FCTX_ATTR_HAVEANSWER) != \
+#define FCTX_ATTR_HAVEANSWER            0x0001
+#define FCTX_ATTR_GLUING                0x0002
+#define FCTX_ATTR_ADDRWAIT              0x0004
+#define FCTX_ATTR_SHUTTINGDOWN          0x0008
+#define FCTX_ATTR_WANTCACHE             0x0010
+#define FCTX_ATTR_WANTNCACHE            0x0020
+#define FCTX_ATTR_NEEDEDNS0             0x0040
+#define FCTX_ATTR_TRIEDFIND             0x0080
+#define FCTX_ATTR_TRIEDALT              0x0100
+
+#define HAVE_ANSWER(f)          (((f)->attributes & FCTX_ATTR_HAVEANSWER) != \
 				 0)
-#define GLUING(f)		(((f)->attributes & FCTX_ATTR_GLUING) != \
+#define GLUING(f)               (((f)->attributes & FCTX_ATTR_GLUING) != \
 				 0)
-#define ADDRWAIT(f)		(((f)->attributes & FCTX_ATTR_ADDRWAIT) != \
+#define ADDRWAIT(f)             (((f)->attributes & FCTX_ATTR_ADDRWAIT) != \
 				 0)
-#define SHUTTINGDOWN(f)		(((f)->attributes & FCTX_ATTR_SHUTTINGDOWN) \
+#define SHUTTINGDOWN(f)         (((f)->attributes & FCTX_ATTR_SHUTTINGDOWN) \
 				 != 0)
-#define WANTCACHE(f)		(((f)->attributes & FCTX_ATTR_WANTCACHE) != 0)
-#define WANTNCACHE(f)		(((f)->attributes & FCTX_ATTR_WANTNCACHE) != 0)
-#define NEEDEDNS0(f)		(((f)->attributes & FCTX_ATTR_NEEDEDNS0) != 0)
-#define TRIEDFIND(f)		(((f)->attributes & FCTX_ATTR_TRIEDFIND) != 0)
-#define TRIEDALT(f)		(((f)->attributes & FCTX_ATTR_TRIEDALT) != 0)
+#define WANTCACHE(f)            (((f)->attributes & FCTX_ATTR_WANTCACHE) != 0)
+#define WANTNCACHE(f)           (((f)->attributes & FCTX_ATTR_WANTNCACHE) != 0)
+#define NEEDEDNS0(f)            (((f)->attributes & FCTX_ATTR_NEEDEDNS0) != 0)
+#define TRIEDFIND(f)            (((f)->attributes & FCTX_ATTR_TRIEDFIND) != 0)
+#define TRIEDALT(f)             (((f)->attributes & FCTX_ATTR_TRIEDALT) != 0)
 
 typedef struct {
 	dns_adbaddrinfo_t *		addrinfo;
@@ -282,14 +324,14 @@ typedef struct fctxbucket {
 
 typedef struct alternate {
 	isc_boolean_t			isaddress;
-	union	{
+	union   {
 		isc_sockaddr_t		addr;
 		struct {
-			dns_name_t	name;
-			in_port_t	port;
+			dns_name_t      name;
+			in_port_t       port;
 		} _n;
 	} _u;
-	ISC_LINK(struct alternate)	link;
+	ISC_LINK(struct alternate)      link;
 } alternate_t;
 
 struct dns_resolver {
@@ -311,6 +353,7 @@ struct dns_resolver {
 	isc_boolean_t			exclusivev4;
 	dns_dispatch_t *		dispatchv6;
 	isc_boolean_t			exclusivev6;
+	unsigned int			ndisps;
 	unsigned int			nbuckets;
 	fctxbucket_t *			buckets;
 	isc_uint32_t			lame_ttl;
@@ -328,6 +371,7 @@ struct dns_resolver {
 	unsigned int			spillatmin;
 	isc_timer_t *			spillattimer;
 	isc_boolean_t			zero_no_soa_ttl;
+
 	/* Locked by lock. */
 	unsigned int			references;
 	isc_boolean_t			exiting;
@@ -335,6 +379,7 @@ struct dns_resolver {
 	unsigned int			activebuckets;
 	isc_boolean_t			priming;
 	unsigned int			spillat;	/* clients-per-query */
+	unsigned int			nextdisp;
 	/* Locked by primelock. */
 	dns_fetch_t *			primefetch;
 	/* Locked by nlock. */
@@ -348,34 +393,45 @@ struct dns_resolver {
  * Private addrinfo flags.  These must not conflict with DNS_FETCHOPT_NOEDNS0,
  * which we also use as an addrinfo flag.
  */
-#define FCTX_ADDRINFO_MARK		0x0001
-#define FCTX_ADDRINFO_FORWARDER		0x1000
-#define UNMARKED(a)			(((a)->flags & FCTX_ADDRINFO_MARK) \
+#define FCTX_ADDRINFO_MARK              0x0001
+#define FCTX_ADDRINFO_FORWARDER         0x1000
+#define FCTX_ADDRINFO_TRIED             0x2000
+#define UNMARKED(a)                     (((a)->flags & FCTX_ADDRINFO_MARK) \
 					 == 0)
-#define ISFORWARDER(a)			(((a)->flags & \
+#define ISFORWARDER(a)                  (((a)->flags & \
 					 FCTX_ADDRINFO_FORWARDER) != 0)
+#define TRIED(a)                        (((a)->flags & \
+					 FCTX_ADDRINFO_TRIED) != 0)
 
 #define NXDOMAIN(r) (((r)->attributes & DNS_RDATASETATTR_NXDOMAIN) != 0)
 
-#define dns_db_transfernode(a,b,c) do { (*c) = (*b); (*b) = NULL; } while (0)
-
 static void destroy(dns_resolver_t *res);
 static void empty_bucket(dns_resolver_t *res);
 static isc_result_t resquery_send(resquery_t *query);
 static void resquery_response(isc_task_t *task, isc_event_t *event);
 static void resquery_connected(isc_task_t *task, isc_event_t *event);
-static void fctx_try(fetchctx_t *fctx);
+static void fctx_try(fetchctx_t *fctx, isc_boolean_t retrying);
 static isc_boolean_t fctx_destroy(fetchctx_t *fctx);
 static isc_result_t ncache_adderesult(dns_message_t *message,
 				      dns_db_t *cache, dns_dbnode_t *node,
 				      dns_rdatatype_t covers,
 				      isc_stdtime_t now, dns_ttl_t maxttl,
+				      isc_boolean_t optout,
 				      dns_rdataset_t *ardataset,
 				      isc_result_t *eresultp);
 static void validated(isc_task_t *task, isc_event_t *event);
 static void maybe_destroy(fetchctx_t *fctx);
 static void add_bad(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo,
-		    isc_result_t reason);
+		    isc_result_t reason, badnstype_t badtype);
+
+/*%
+ * Increment resolver-related statistics counters.
+ */
+static inline void
+inc_stats(dns_resolver_t *res, isc_statscounter_t counter) {
+	if (res->view->resstats != NULL)
+		isc_stats_increment(res->view->resstats, counter);
+}
 
 static isc_result_t
 valcreate(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo, dns_name_t *name,
@@ -403,6 +459,7 @@ valcreate(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo, dns_name_t *name,
 				      valoptions, task, validated, valarg,
 				      &validator);
 	if (result == ISC_R_SUCCESS) {
+		inc_stats(fctx->res, dns_resstatscounter_val);
 		if ((valoptions & DNS_VALIDATOR_DEFER) == 0) {
 			INSIST(fctx->validator == NULL);
 			fctx->validator  = validator;
@@ -522,21 +579,20 @@ fctx_stoptimer(fetchctx_t *fctx) {
 
 
 static inline isc_result_t
-fctx_startidletimer(fetchctx_t *fctx) {
+fctx_startidletimer(fetchctx_t *fctx, isc_interval_t *interval) {
 	/*
 	 * Start the idle timer for fctx.  The lifetime timer continues
 	 * to be in effect.
 	 */
 	return (isc_timer_reset(fctx->timer, isc_timertype_once,
-				&fctx->expires, &fctx->interval,
-				ISC_FALSE));
+				&fctx->expires, interval, ISC_FALSE));
 }
 
 /*
  * Stopping the idle timer is equivalent to calling fctx_starttimer(), but
  * we use fctx_stopidletimer for readability in the code below.
  */
-#define fctx_stopidletimer	fctx_starttimer
+#define fctx_stopidletimer      fctx_starttimer
 
 
 static inline void
@@ -551,7 +607,7 @@ resquery_destroy(resquery_t **queryp) {
 
 	query->fctx->nqueries--;
 	if (SHUTTINGDOWN(query->fctx))
-		maybe_destroy(query->fctx);	/* Locks bucket. */
+		maybe_destroy(query->fctx);     /* Locks bucket. */
 	query->magic = 0;
 	isc_mem_put(query->mctx, query, sizeof(*query));
 	*queryp = NULL;
@@ -563,7 +619,7 @@ fctx_cancelquery(resquery_t **queryp, dns_dispatchevent_t **deventp,
 {
 	fetchctx_t *fctx;
 	resquery_t *query;
-	unsigned int rtt;
+	unsigned int rtt, rttms;
 	unsigned int factor;
 	dns_adbfind_t *find;
 	dns_adbaddrinfo_t *addrinfo;
@@ -590,6 +646,27 @@ fctx_cancelquery(resquery_t **queryp, dns_dispatchevent_t **deventp,
 			rtt = (unsigned int)isc_time_microdiff(finish,
 							       &query->start);
 			factor = DNS_ADB_RTTADJDEFAULT;
+
+			rttms = rtt / 1000;
+			if (rttms < DNS_RESOLVER_QRYRTTCLASS0) {
+				inc_stats(fctx->res,
+					  dns_resstatscounter_queryrtt0);
+			} else if (rttms < DNS_RESOLVER_QRYRTTCLASS1) {
+				inc_stats(fctx->res,
+					  dns_resstatscounter_queryrtt1);
+			} else if (rttms < DNS_RESOLVER_QRYRTTCLASS2) {
+				inc_stats(fctx->res,
+					  dns_resstatscounter_queryrtt2);
+			} else if (rttms < DNS_RESOLVER_QRYRTTCLASS3) {
+				inc_stats(fctx->res,
+					  dns_resstatscounter_queryrtt3);
+			} else if (rttms < DNS_RESOLVER_QRYRTTCLASS4) {
+				inc_stats(fctx->res,
+					  dns_resstatscounter_queryrtt4);
+			} else {
+				inc_stats(fctx->res,
+					  dns_resstatscounter_queryrtt5);
+			}
 		} else {
 			/*
 			 * We don't have an RTT for this query.  Maybe the
@@ -608,6 +685,12 @@ fctx_cancelquery(resquery_t **queryp, dns_dispatchevent_t **deventp,
 		dns_adb_adjustsrtt(fctx->adb, query->addrinfo, rtt, factor);
 	}
 
+	/* Remember that the server has been tried. */
+	if (!TRIED(query->addrinfo)) {
+		dns_adb_changeflags(fctx->adb, query->addrinfo,
+				    FCTX_ADDRINFO_TRIED, FCTX_ADDRINFO_TRIED);
+	}
+
 	/*
 	 * Age RTTs of servers not tried.
 	 */
@@ -790,14 +873,16 @@ fctx_stopeverything(fetchctx_t *fctx, isc_boolean_t no_response) {
 }
 
 static inline void
-fctx_sendevents(fetchctx_t *fctx, isc_result_t result) {
+fctx_sendevents(fetchctx_t *fctx, isc_result_t result, int line) {
 	dns_fetchevent_t *event, *next_event;
 	isc_task_t *task;
 	unsigned int count = 0;
 	isc_interval_t i;
 	isc_boolean_t logit = ISC_FALSE;
+	isc_time_t now;
 	unsigned int old_spillat;
-	unsigned int new_spillat = 0;	/* initialized to silence compiler warnings */
+	unsigned int new_spillat = 0;	/* initialized to silence
+					   compiler warnings */
 
 	/*
 	 * Caller must be holding the appropriate bucket lock.
@@ -806,6 +891,14 @@ fctx_sendevents(fetchctx_t *fctx, isc_result_t result) {
 
 	FCTXTRACE("sendevents");
 
+	/*
+	 * Keep some record of fetch result for logging later (if required).
+	 */
+	fctx->result = result;
+	fctx->exitline = line;
+	TIME_NOW(&now);
+	fctx->duration = isc_time_microdiff(&now, &fctx->start);
+
 	for (event = ISC_LIST_HEAD(fctx->events);
 	     event != NULL;
 	     event = next_event) {
@@ -864,26 +957,50 @@ fctx_sendevents(fetchctx_t *fctx, isc_result_t result) {
 	}
 }
 
+static inline void
+log_edns(fetchctx_t *fctx) {
+	char domainbuf[DNS_NAME_FORMATSIZE];
+
+	if (fctx->reason == NULL)
+		return;
+
+	dns_name_format(&fctx->domain, domainbuf, sizeof(domainbuf));
+	isc_log_write(dns_lctx, DNS_LOGCATEGORY_EDNS_DISABLED,
+		      DNS_LOGMODULE_RESOLVER, ISC_LOG_INFO,
+		      "success resolving '%s' (in '%s'?) after %s",
+		      fctx->info, domainbuf, fctx->reason);
+
+	fctx->reason = NULL;
+}
+
 static void
-fctx_done(fetchctx_t *fctx, isc_result_t result) {
+fctx_done(fetchctx_t *fctx, isc_result_t result, int line) {
 	dns_resolver_t *res;
 	isc_boolean_t no_response;
 
+	REQUIRE(line >= 0);
+
 	FCTXTRACE("done");
 
 	res = fctx->res;
 
-	if (result == ISC_R_SUCCESS)
+	if (result == ISC_R_SUCCESS) {
+		/*%
+		 * Log any deferred EDNS timeout messages.
+		 */
+		log_edns(fctx);
 		no_response = ISC_TRUE;
-	else
+	 } else
 		no_response = ISC_FALSE;
+
+	fctx->reason = NULL;
 	fctx_stopeverything(fctx, no_response);
 
 	LOCK(&res->buckets[fctx->bucketnum].lock);
 
 	fctx->state = fetchstate_done;
 	fctx->attributes &= ~FCTX_ATTR_ADDRWAIT;
-	fctx_sendevents(fctx, result);
+	fctx_sendevents(fctx, result, line);
 
 	UNLOCK(&res->buckets[fctx->bucketnum].lock);
 }
@@ -921,7 +1038,8 @@ process_sendevent(resquery_t *query, isc_event_t *event) {
 			/*
 			 * No route to remote.
 			 */
-			add_bad(fctx, query->addrinfo, sevent->result);
+			add_bad(fctx, query->addrinfo, sevent->result,
+				badns_unreachable);
 			fctx_cancelquery(&query, NULL, NULL, ISC_TRUE);
 			retry = ISC_TRUE;
 			break;
@@ -942,9 +1060,9 @@ process_sendevent(resquery_t *query, isc_event_t *event) {
 		fctx->attributes &= ~FCTX_ATTR_ADDRWAIT;
 		result = fctx_stopidletimer(fctx);
 		if (result != ISC_R_SUCCESS)
-			fctx_done(fctx, result);
+			fctx_done(fctx, result, __LINE__);
 		else
-			fctx_try(fctx);
+			fctx_try(fctx, ISC_TRUE);
 	}
 }
 
@@ -991,7 +1109,8 @@ resquery_senddone(isc_task_t *task, isc_event_t *event) {
 }
 
 static inline isc_result_t
-fctx_addopt(dns_message_t *message, unsigned int version, isc_uint16_t udpsize)
+fctx_addopt(dns_message_t *message, unsigned int version,
+	    isc_uint16_t udpsize, isc_boolean_t request_nsid)
 {
 	dns_rdataset_t *rdataset;
 	dns_rdatalist_t *rdatalist;
@@ -1027,10 +1146,23 @@ fctx_addopt(dns_message_t *message, unsigned int version, isc_uint16_t udpsize)
 	rdatalist->ttl |= DNS_MESSAGEEXTFLAG_DO;
 
 	/*
-	 * No EDNS options.
+	 * Set EDNS options if applicable
 	 */
-	rdata->data = NULL;
-	rdata->length = 0;
+	if (request_nsid) {
+		/* Send empty NSID option (RFC5001) */
+		unsigned char data[4];
+		isc_buffer_t buf;
+
+		isc_buffer_init(&buf, data, sizeof(data));
+		isc_buffer_putuint16(&buf, DNS_OPT_NSID);
+		isc_buffer_putuint16(&buf, 0);
+		rdata->data = data;
+		rdata->length = sizeof(data);
+	} else {
+		rdata->data = NULL;
+		rdata->length = 0;
+	}
+
 	rdata->rdclass = rdatalist->rdclass;
 	rdata->type = rdatalist->type;
 	rdata->flags = 0;
@@ -1048,7 +1180,7 @@ fctx_setretryinterval(fetchctx_t *fctx, unsigned int rtt) {
 	unsigned int us;
 
 	/*
-	 * We retry every .5 seconds the first two times through the address
+	 * We retry every .8 seconds the first two times through the address
 	 * list, and then we do exponential back-off.
 	 */
 	if (fctx->restarts < 3)
@@ -1088,14 +1220,19 @@ fctx_query(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo,
 	resquery_t *query;
 	isc_sockaddr_t addr;
 	isc_boolean_t have_addr = ISC_FALSE;
+	unsigned int srtt;
 
 	FCTXTRACE("query");
 
 	res = fctx->res;
 	task = res->buckets[fctx->bucketnum].task;
 
-	fctx_setretryinterval(fctx, addrinfo->srtt);
-	result = fctx_startidletimer(fctx);
+	srtt = addrinfo->srtt;
+	if (ISFORWARDER(addrinfo) && srtt < 1000000)
+		srtt = 1000000;
+
+	fctx_setretryinterval(fctx, srtt);
+	result = fctx_startidletimer(fctx, &fctx->interval);
 	if (result != ISC_R_SUCCESS)
 		return (result);
 
@@ -1262,9 +1399,17 @@ fctx_query(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo,
 		if (result != ISC_R_SUCCESS)
 			goto cleanup_dispatch;
 	}
+	fctx->querysent++;
 
 	ISC_LIST_APPEND(fctx->queries, query, link);
 	query->fctx->nqueries++;
+	if (isc_sockaddr_pf(&addrinfo->sockaddr) == PF_INET)
+		inc_stats(res, dns_resstatscounter_queryv4);
+	else
+		inc_stats(res, dns_resstatscounter_queryv6);
+	if (res->view->resquerystats != NULL)
+		dns_rdatatypestats_increment(res->view->resquerystats,
+					     fctx->type);
 
 	return (ISC_R_SUCCESS);
 
@@ -1486,34 +1631,55 @@ resquery_send(resquery_t *query) {
 	    !useedns)
 	{
 		query->options |= DNS_FETCHOPT_NOEDNS0;
-		dns_adb_changeflags(fctx->adb,
-				    query->addrinfo,
+		dns_adb_changeflags(fctx->adb, query->addrinfo,
 				    DNS_FETCHOPT_NOEDNS0,
 				    DNS_FETCHOPT_NOEDNS0);
 	}
 
+	/* Sync NOEDNS0 flag in addrinfo->flags and options now. */
+	if ((query->addrinfo->flags & DNS_FETCHOPT_NOEDNS0) != 0)
+		query->options |= DNS_FETCHOPT_NOEDNS0;
+
+	/*
+	 * Handle timeouts by reducing the UDP response size to 512 bytes
+	 * then if that doesn't work disabling EDNS (includes DO) and CD.
+	 *
+	 * These timeout can be due to:
+	 *	* broken nameservers that don't respond to EDNS queries.
+	 *	* broken/misconfigured firewalls and NAT implementations
+	 *	  that don't handle IP fragmentation.
+	 *	* broken/misconfigured firewalls that don't handle responses
+	 *	  greater than 512 bytes.
+	 *	* broken/misconfigured firewalls that don't handle EDNS, DO
+	 *	  or CD.
+	 *	* packet loss / link outage.
+	 */
+	if (fctx->timeout) {
+		if ((triededns512(fctx, &query->addrinfo->sockaddr) ||
+		     fctx->timeouts >= (MAX_EDNS0_TIMEOUTS * 2)) &&
+		    (query->options & DNS_FETCHOPT_NOEDNS0) == 0) {
+			query->options |= DNS_FETCHOPT_NOEDNS0;
+			fctx->reason = "disabling EDNS";
+		} else if ((triededns(fctx, &query->addrinfo->sockaddr) ||
+			    fctx->timeouts >= MAX_EDNS0_TIMEOUTS) &&
+			   (query->options & DNS_FETCHOPT_NOEDNS0) == 0) {
+			query->options |= DNS_FETCHOPT_EDNS512;
+			fctx->reason = "reducing the advertised EDNS UDP "
+				       "packet size to 512 octets";
+		}
+		fctx->timeout = ISC_FALSE;
+	}
+
 	/*
 	 * Use EDNS0, unless the caller doesn't want it, or we know that
 	 * the remote server doesn't like it.
 	 */
-
-	if ((triededns512(fctx, &query->addrinfo->sockaddr) ||
-	     fctx->timeouts >= (MAX_EDNS0_TIMEOUTS * 2)) &&
-	    (query->options & DNS_FETCHOPT_NOEDNS0) == 0) {
-		query->options |= DNS_FETCHOPT_NOEDNS0;
-		FCTXTRACE("too many timeouts, disabling EDNS0");
-	} else if ((triededns(fctx, &query->addrinfo->sockaddr) ||
-		    fctx->timeouts >= MAX_EDNS0_TIMEOUTS) &&
-		   (query->options & DNS_FETCHOPT_NOEDNS0) == 0) {
-		query->options |= DNS_FETCHOPT_EDNS512;
-		FCTXTRACE("too many timeouts, setting EDNS size to 512");
-	}
-
 	if ((query->options & DNS_FETCHOPT_NOEDNS0) == 0) {
 		if ((query->addrinfo->flags & DNS_FETCHOPT_NOEDNS0) == 0) {
-			unsigned int version = 0;	/* Default version. */
+			unsigned int version = 0;       /* Default version. */
 			unsigned int flags;
 			isc_uint16_t udpsize = res->udpsize;
+			isc_boolean_t reqnsid = res->view->requestnsid;
 
 			flags = query->addrinfo->flags;
 			if ((flags & DNS_FETCHOPT_EDNSVERSIONSET) != 0) {
@@ -1524,8 +1690,15 @@ resquery_send(resquery_t *query) {
 				udpsize = 512;
 			else if (peer != NULL)
 				(void)dns_peer_getudpsize(peer, &udpsize);
-			result = fctx_addopt(fctx->qmessage, version, udpsize);
-			if (result != ISC_R_SUCCESS) {
+
+			/* request NSID for current view or peer? */
+			if (peer != NULL)
+				(void) dns_peer_getrequestnsid(peer, &reqnsid);
+			result = fctx_addopt(fctx->qmessage, version,
+					     udpsize, reqnsid);
+			if (reqnsid && result == ISC_R_SUCCESS) {
+				query->options |= DNS_FETCHOPT_WANTNSID;
+			} else if (result != ISC_R_SUCCESS) {
 				/*
 				 * We couldn't add the OPT, but we'll press on.
 				 * We're not using EDNS0, so set the NOEDNS0
@@ -1636,13 +1809,15 @@ resquery_send(resquery_t *query) {
 
 	/*
 	 * XXXRTH  Make sure we don't send to ourselves!  We should probably
-	 *	   prune out these addresses when we get them from the ADB.
+	 *		prune out these addresses when we get them from the ADB.
 	 */
 	result = isc_socket_sendto(socket, &r, task, resquery_senddone,
 				   query, address, NULL);
 	if (result != ISC_R_SUCCESS)
 		goto cleanup_message;
+
 	query->sends++;
+
 	QTRACE("sent");
 
 	return (ISC_R_SUCCESS);
@@ -1672,6 +1847,7 @@ resquery_connected(isc_task_t *task, isc_event_t *event) {
 	isc_socketevent_t *sevent = (isc_socketevent_t *)event;
 	resquery_t *query = event->ev_arg;
 	isc_boolean_t retry = ISC_FALSE;
+	isc_interval_t interval;
 	isc_result_t result;
 	unsigned int attrs;
 	fetchctx_t *fctx;
@@ -1704,6 +1880,20 @@ resquery_connected(isc_task_t *task, isc_event_t *event) {
 	} else {
 		switch (sevent->result) {
 		case ISC_R_SUCCESS:
+
+			/*
+			 * Extend the idle timer for TCP.  20 seconds
+			 * should be long enough for a TCP connection to be
+			 * established, a single DNS request to be sent,
+			 * and the response received.
+			 */
+			isc_interval_set(&interval, 20, 0);
+			result = fctx_startidletimer(query->fctx, &interval);
+			if (result != ISC_R_SUCCESS) {
+				fctx_cancelquery(&query, NULL, NULL, ISC_FALSE);
+				fctx_done(fctx, result, __LINE__);
+				break;
+			}
 			/*
 			 * We are connected.  Create a dispatcher and
 			 * send the query.
@@ -1736,9 +1926,8 @@ resquery_connected(isc_task_t *task, isc_event_t *event) {
 				result = resquery_send(query);
 
 			if (result != ISC_R_SUCCESS) {
-				fctx_cancelquery(&query, NULL, NULL,
-						 ISC_FALSE);
-				fctx_done(fctx, result);
+				fctx_cancelquery(&query, NULL, NULL, ISC_FALSE);
+				fctx_done(fctx, result, __LINE__);
 			}
 			break;
 
@@ -1773,9 +1962,9 @@ resquery_connected(isc_task_t *task, isc_event_t *event) {
 		fctx->attributes &= ~FCTX_ATTR_ADDRWAIT;
 		result = fctx_stopidletimer(fctx);
 		if (result != ISC_R_SUCCESS)
-			fctx_done(fctx, result);
+			fctx_done(fctx, result, __LINE__);
 		else
-			fctx_try(fctx);
+			fctx_try(fctx, ISC_TRUE);
 	}
 }
 
@@ -1809,13 +1998,16 @@ fctx_finddone(isc_task_t *task, isc_event_t *event) {
 		fctx->attributes &= ~FCTX_ATTR_ADDRWAIT;
 		if (event->ev_type == DNS_EVENT_ADBMOREADDRESSES)
 			want_try = ISC_TRUE;
-		else if (fctx->pending == 0) {
-			/*
-			 * We've got nothing else to wait for and don't
-			 * know the answer.  There's nothing to do but
-			 * fail the fctx.
-			 */
-			want_done = ISC_TRUE;
+		else {
+			fctx->findfail++;
+			if (fctx->pending == 0) {
+				/*
+				 * We've got nothing else to wait for and don't
+				 * know the answer.  There's nothing to do but
+				 * fail the fctx.
+				 */
+				want_done = ISC_TRUE;
+			}
 		}
 	} else if (SHUTTINGDOWN(fctx) && fctx->pending == 0 &&
 		   fctx->nqueries == 0 && ISC_LIST_EMPTY(fctx->validators)) {
@@ -1834,9 +2026,9 @@ fctx_finddone(isc_task_t *task, isc_event_t *event) {
 	dns_adb_destroyfind(&find);
 
 	if (want_try)
-		fctx_try(fctx);
+		fctx_try(fctx, ISC_TRUE);
 	else if (want_done)
-		fctx_done(fctx, ISC_R_FAILURE);
+		fctx_done(fctx, ISC_R_FAILURE, __LINE__);
 	else if (bucket_empty)
 		empty_bucket(res);
 }
@@ -1924,7 +2116,9 @@ mark_bad(fetchctx_t *fctx) {
 }
 
 static void
-add_bad(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo, isc_result_t reason) {
+add_bad(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo, isc_result_t reason,
+	badnstype_t badtype)
+{
 	char namebuf[DNS_NAME_FORMATSIZE];
 	char addrbuf[ISC_SOCKADDR_FORMATSIZE];
 	char classbuf[64];
@@ -1935,6 +2129,21 @@ add_bad(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo, isc_result_t reason) {
 	const char *sep1, *sep2;
 	isc_sockaddr_t *address = &addrinfo->sockaddr;
 
+	if (reason == DNS_R_LAME)
+		fctx->lamecount++;
+	else {
+		switch (badtype) {
+		case badns_unreachable:
+			fctx->neterr++;
+			break;
+		case badns_response:
+			fctx->badresp++;
+			break;
+		case badns_validation:
+			break;	/* counted as 'valfail' */
+		}
+	}
+
 	if (bad_server(fctx, address)) {
 		/*
 		 * We already know this server is bad.
@@ -1951,7 +2160,7 @@ add_bad(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo, isc_result_t reason) {
 	*sa = *address;
 	ISC_LIST_INITANDAPPEND(fctx->bad, sa, link);
 
-	if (reason == DNS_R_LAME)	/* already logged */
+	if (reason == DNS_R_LAME)       /* already logged */
 		return;
 
 	if (reason == DNS_R_UNEXPECTEDRCODE &&
@@ -1987,15 +2196,79 @@ add_bad(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo, isc_result_t reason) {
 		      namebuf, typebuf, classbuf, addrbuf);
 }
 
+/*
+ * Return 'bits' bits of random entropy from fctx->rand_buf,
+ * refreshing it by calling isc_random_get() whenever the requested
+ * number of bits is greater than the number in the buffer.
+ */
+static inline isc_uint32_t
+random_bits(fetchctx_t *fctx, isc_uint32_t bits) {
+	isc_uint32_t ret = 0;
+
+	REQUIRE(VALID_FCTX(fctx));
+	REQUIRE(bits <= 32);
+	if (bits == 0)
+		return (0);
+
+	if (bits >= fctx->rand_bits) {
+		/* if rand_bits == 0, this is unnecessary but harmless */
+		bits -= fctx->rand_bits;
+		ret = fctx->rand_buf << bits;
+
+		/* refresh random buffer now */
+		isc_random_get(&fctx->rand_buf);
+		fctx->rand_bits = sizeof(fctx->rand_buf) * CHAR_BIT;
+	}
+
+	if (bits > 0) {
+		isc_uint32_t mask = 0xffffffff;
+		if (bits < 32) {
+			mask = (1 << bits) - 1;
+		}
+
+		ret |= fctx->rand_buf & mask;
+		fctx->rand_buf >>= bits;
+		fctx->rand_bits -= bits;
+	}
+
+	return (ret);
+}
+
+/*
+ * Add some random jitter to a server's RTT value so that the
+ * order of queries will be unpredictable.
+ *
+ * RTT values of servers which have been tried are fuzzed by 128 ms.
+ * Servers that haven't been tried yet have their RTT set to a random
+ * value between 0 ms and 7 ms; they should get to go first, but in
+ * unpredictable order.
+ */
+static inline void
+randomize_srtt(fetchctx_t *fctx, dns_adbaddrinfo_t *ai) {
+	if (TRIED(ai)) {
+		ai->srtt >>= 10; /* convert to milliseconds, near enough */
+		ai->srtt |= (ai->srtt & 0x80) | random_bits(fctx, 7);
+		ai->srtt <<= 10; /* now back to microseconds */
+	} else
+		ai->srtt = random_bits(fctx, 3) << 10;
+}
+
+/*
+ * Sort addrinfo list by RTT (with random jitter)
+ */
 static void
-sort_adbfind(dns_adbfind_t *find) {
+sort_adbfind(fetchctx_t *fctx, dns_adbfind_t *find) {
 	dns_adbaddrinfo_t *best, *curr;
 	dns_adbaddrinfolist_t sorted;
 
-	/*
-	 * Lame N^2 bubble sort.
-	 */
+	/* Add jitter to SRTT values */
+	curr = ISC_LIST_HEAD(find->list);
+	while (curr != NULL) {
+		randomize_srtt(fctx, curr);
+		curr = ISC_LIST_NEXT(curr, publink);
+	}
 
+	/* Lame N^2 bubble sort. */
 	ISC_LIST_INIT(sorted);
 	while (!ISC_LIST_EMPTY(find->list)) {
 		best = ISC_LIST_HEAD(find->list);
@@ -2011,39 +2284,25 @@ sort_adbfind(dns_adbfind_t *find) {
 	find->list = sorted;
 }
 
+/*
+ * Sort a list of finds by server RTT (with random jitter)
+ */
 static void
-sort_finds(fetchctx_t *fctx) {
+sort_finds(fetchctx_t *fctx, dns_adbfindlist_t *findlist) {
 	dns_adbfind_t *best, *curr;
 	dns_adbfindlist_t sorted;
 	dns_adbaddrinfo_t *addrinfo, *bestaddrinfo;
 
-	/*
-	 * Lame N^2 bubble sort.
-	 */
-
-	ISC_LIST_INIT(sorted);
-	while (!ISC_LIST_EMPTY(fctx->finds)) {
-		best = ISC_LIST_HEAD(fctx->finds);
-		bestaddrinfo = ISC_LIST_HEAD(best->list);
-		INSIST(bestaddrinfo != NULL);
-		curr = ISC_LIST_NEXT(best, publink);
-		while (curr != NULL) {
-			addrinfo = ISC_LIST_HEAD(curr->list);
-			INSIST(addrinfo != NULL);
-			if (addrinfo->srtt < bestaddrinfo->srtt) {
-				best = curr;
-				bestaddrinfo = addrinfo;
-			}
-			curr = ISC_LIST_NEXT(curr, publink);
-		}
-		ISC_LIST_UNLINK(fctx->finds, best, publink);
-		ISC_LIST_APPEND(sorted, best, publink);
-	}
-	fctx->finds = sorted;
+	/* Sort each find's addrinfo list by SRTT (after adding jitter) */
+	for (curr = ISC_LIST_HEAD(*findlist);
+	     curr != NULL;
+	     curr = ISC_LIST_NEXT(curr, publink))
+		sort_adbfind(fctx, curr);
 
+	/* Lame N^2 bubble sort. */
 	ISC_LIST_INIT(sorted);
-	while (!ISC_LIST_EMPTY(fctx->altfinds)) {
-		best = ISC_LIST_HEAD(fctx->altfinds);
+	while (!ISC_LIST_EMPTY(*findlist)) {
+		best = ISC_LIST_HEAD(*findlist);
 		bestaddrinfo = ISC_LIST_HEAD(best->list);
 		INSIST(bestaddrinfo != NULL);
 		curr = ISC_LIST_NEXT(best, publink);
@@ -2056,10 +2315,10 @@ sort_finds(fetchctx_t *fctx) {
 			}
 			curr = ISC_LIST_NEXT(curr, publink);
 		}
-		ISC_LIST_UNLINK(fctx->altfinds, best, publink);
+		ISC_LIST_UNLINK(*findlist, best, publink);
 		ISC_LIST_APPEND(sorted, best, publink);
 	}
-	fctx->altfinds = sorted;
+	*findlist = sorted;
 }
 
 static void
@@ -2103,6 +2362,7 @@ findname(fetchctx_t *fctx, dns_name_t *name, in_port_t port,
 			 * XXXRTH  Follow the CNAME/DNAME chain?
 			 */
 			dns_adb_destroyfind(&find);
+			fctx->adberr++;
 		}
 	} else if (!ISC_LIST_EMPTY(find->list)) {
 		/*
@@ -2110,7 +2370,6 @@ findname(fetchctx_t *fctx, dns_name_t *name, in_port_t port,
 		 * name.
 		 */
 		INSIST((find->options & DNS_ADBFIND_WANTEVENT) == 0);
-		sort_adbfind(find);
 		if (flags != 0 || port != 0) {
 			for (ai = ISC_LIST_HEAD(find->list);
 			     ai != NULL;
@@ -2147,6 +2406,11 @@ findname(fetchctx_t *fctx, dns_name_t *name, in_port_t port,
 			      find->result_v4 != DNS_R_NXDOMAIN)))
 				*need_alternate = ISC_TRUE;
 		} else {
+			if ((find->options & DNS_ADBFIND_LAMEPRUNED) != 0)
+				fctx->lamecount++; /* cached lame server */
+			else
+				fctx->adberr++; /* unreachable server, etc. */
+
 			/*
 			 * If we know there are no addresses for
 			 * the family we are using then try to add
@@ -2188,7 +2452,7 @@ fctx_getaddresses(fetchctx_t *fctx) {
 	}
 
 	res = fctx->res;
-	stdoptions = 0;		/* Keep compiler happy. */
+	stdoptions = 0;         /* Keep compiler happy. */
 
 	/*
 	 * Forwarders.
@@ -2379,7 +2643,8 @@ fctx_getaddresses(fetchctx_t *fctx) {
 		 * We've found some addresses.  We might still be looking
 		 * for more addresses.
 		 */
-		sort_finds(fctx);
+		sort_finds(fctx, &fctx->finds);
+		sort_finds(fctx, &fctx->altfinds);
 		result = ISC_R_SUCCESS;
 	}
 
@@ -2593,7 +2858,7 @@ fctx_nextaddress(fetchctx_t *fctx) {
 }
 
 static void
-fctx_try(fetchctx_t *fctx) {
+fctx_try(fetchctx_t *fctx, isc_boolean_t retrying) {
 	isc_result_t result;
 	dns_adbaddrinfo_t *addrinfo;
 
@@ -2623,7 +2888,7 @@ fctx_try(fetchctx_t *fctx) {
 			/*
 			 * Something bad happened.
 			 */
-			fctx_done(fctx, result);
+			fctx_done(fctx, result, __LINE__);
 			return;
 		}
 
@@ -2633,14 +2898,16 @@ fctx_try(fetchctx_t *fctx) {
 		 * might be bad ones.  In this case, return SERVFAIL.
 		 */
 		if (addrinfo == NULL) {
-			fctx_done(fctx, DNS_R_SERVFAIL);
+			fctx_done(fctx, DNS_R_SERVFAIL, __LINE__);
 			return;
 		}
 	}
 
 	result = fctx_query(fctx, addrinfo, fctx->options);
 	if (result != ISC_R_SUCCESS)
-		fctx_done(fctx, result);
+		fctx_done(fctx, result, __LINE__);
+	else if (retrying)
+		inc_stats(fctx->res, dns_resstatscounter_retry);
 }
 
 static isc_boolean_t
@@ -2738,12 +3005,16 @@ fctx_timeout(isc_task_t *task, isc_event_t *event) {
 
 	FCTXTRACE("timeout");
 
+	inc_stats(fctx->res, dns_resstatscounter_querytimeout);
+
 	if (event->ev_type == ISC_TIMEREVENT_LIFE) {
-		fctx_done(fctx, ISC_R_TIMEDOUT);
+		fctx->reason = NULL;
+		fctx_done(fctx, ISC_R_TIMEDOUT, __LINE__);
 	} else {
 		isc_result_t result;
 
 		fctx->timeouts++;
+		fctx->timeout = ISC_TRUE;
 		/*
 		 * We could cancel the running queries here, or we could let
 		 * them keep going.  Since we normally use separate sockets for
@@ -2765,12 +3036,12 @@ fctx_timeout(isc_task_t *task, isc_event_t *event) {
 		 */
 		result = fctx_starttimer(fctx);
 		if (result != ISC_R_SUCCESS)
-			fctx_done(fctx, result);
+			fctx_done(fctx, result, __LINE__);
 		else
 			/*
 			 * Keep trying.
 			 */
-			fctx_try(fctx);
+			fctx_try(fctx, ISC_TRUE);
 	}
 
 	isc_event_free(&event);
@@ -2860,7 +3131,7 @@ fctx_doshutdown(isc_task_t *task, isc_event_t *event) {
 
 	if (fctx->state != fetchstate_done) {
 		fctx->state = fetchstate_done;
-		fctx_sendevents(fctx, ISC_R_CANCELED);
+		fctx_sendevents(fctx, ISC_R_CANCELED, __LINE__);
 	}
 
 	if (fctx->references == 0 && fctx->pending == 0 &&
@@ -2899,7 +3170,7 @@ fctx_start(isc_task_t *task, isc_event_t *event) {
 		 */
 		fctx->attributes |= FCTX_ATTR_SHUTTINGDOWN;
 		fctx->state = fetchstate_done;
-		fctx_sendevents(fctx, ISC_R_CANCELED);
+		fctx_sendevents(fctx, ISC_R_CANCELED, __LINE__);
 		/*
 		 * Since we haven't started, we INSIST that we have no
 		 * pending ADB finds and no pending validations.
@@ -2938,9 +3209,9 @@ fctx_start(isc_task_t *task, isc_event_t *event) {
 		 */
 		result = fctx_starttimer(fctx);
 		if (result != ISC_R_SUCCESS)
-			fctx_done(fctx, result);
+			fctx_done(fctx, result, __LINE__);
 		else
-			fctx_try(fctx);
+			fctx_try(fctx, ISC_FALSE);
 	} else if (bucket_empty)
 		empty_bucket(res);
 }
@@ -3026,8 +3297,8 @@ fctx_create(dns_resolver_t *res, dns_name_t *name, dns_rdatatype_t type,
 		return (ISC_R_NOMEMORY);
 	dns_name_format(name, buf, sizeof(buf));
 	dns_rdatatype_format(type, typebuf, sizeof(typebuf));
-	strcat(buf, "/");	/* checked */
-	strcat(buf, typebuf);	/* checked */
+	strcat(buf, "/");       /* checked */
+	strcat(buf, typebuf);   /* checked */
 	fctx->info = isc_mem_strdup(res->buckets[bucketnum].mctx, buf);
 	if (fctx->info == NULL) {
 		result = ISC_R_NOMEMORY;
@@ -3070,10 +3341,27 @@ fctx_create(dns_resolver_t *res, dns_name_t *name, dns_rdatatype_t type,
 	fctx->altfind = NULL;
 	fctx->pending = 0;
 	fctx->restarts = 0;
+	fctx->querysent = 0;
+	fctx->referrals = 0;
+	TIME_NOW(&fctx->start);
 	fctx->timeouts = 0;
+	fctx->lamecount = 0;
+	fctx->adberr = 0;
+	fctx->neterr = 0;
+	fctx->badresp = 0;
+	fctx->findfail = 0;
+	fctx->valfail = 0;
+	fctx->result = ISC_R_FAILURE;
+	fctx->vresult = ISC_R_SUCCESS;
+	fctx->exitline = -1;	/* sentinel */
+	fctx->logged = ISC_FALSE;
 	fctx->attributes = 0;
 	fctx->spilled = ISC_FALSE;
 	fctx->nqueries = 0;
+	fctx->reason = NULL;
+	fctx->rand_buf = 0;
+	fctx->rand_bits = 0;
+	fctx->timeout = ISC_FALSE;
 
 	dns_name_init(&fctx->nsname, NULL);
 	fctx->nsfetch = NULL;
@@ -3162,7 +3450,7 @@ fctx_create(dns_resolver_t *res, dns_name_t *name, dns_rdatatype_t type,
 	/*
 	 * Compute an expiration time for the entire fetch.
 	 */
-	isc_interval_set(&interval, 30, 0);		/* XXXRTH constant */
+	isc_interval_set(&interval, 30, 0);             /* XXXRTH constant */
 	iresult = isc_time_nowplusinterval(&fctx->expires, &interval);
 	if (iresult != ISC_R_SUCCESS) {
 		UNEXPECTED_ERROR(__FILE__, __LINE__,
@@ -3382,13 +3670,13 @@ clone_results(fetchctx_t *fctx) {
 	}
 }
 
-#define CACHE(r)	(((r)->attributes & DNS_RDATASETATTR_CACHE) != 0)
-#define ANSWER(r)	(((r)->attributes & DNS_RDATASETATTR_ANSWER) != 0)
-#define ANSWERSIG(r)	(((r)->attributes & DNS_RDATASETATTR_ANSWERSIG) != 0)
-#define EXTERNAL(r)	(((r)->attributes & DNS_RDATASETATTR_EXTERNAL) != 0)
-#define CHAINING(r)	(((r)->attributes & DNS_RDATASETATTR_CHAINING) != 0)
-#define CHASE(r)	(((r)->attributes & DNS_RDATASETATTR_CHASE) != 0)
-#define CHECKNAMES(r)	(((r)->attributes & DNS_RDATASETATTR_CHECKNAMES) != 0)
+#define CACHE(r)        (((r)->attributes & DNS_RDATASETATTR_CACHE) != 0)
+#define ANSWER(r)       (((r)->attributes & DNS_RDATASETATTR_ANSWER) != 0)
+#define ANSWERSIG(r)    (((r)->attributes & DNS_RDATASETATTR_ANSWERSIG) != 0)
+#define EXTERNAL(r)     (((r)->attributes & DNS_RDATASETATTR_EXTERNAL) != 0)
+#define CHAINING(r)     (((r)->attributes & DNS_RDATASETATTR_CHAINING) != 0)
+#define CHASE(r)        (((r)->attributes & DNS_RDATASETATTR_CHASE) != 0)
+#define CHECKNAMES(r)   (((r)->attributes & DNS_RDATASETATTR_CHECKNAMES) != 0)
 
 
 /*
@@ -3397,7 +3685,7 @@ clone_results(fetchctx_t *fctx) {
  * was the last fctx in the resolver, destroy the resolver.
  *
  * Requires:
- *	'*fctx' is shutting down.
+ *      '*fctx' is shutting down.
  */
 static void
 maybe_destroy(fetchctx_t *fctx) {
@@ -3494,7 +3782,7 @@ validated(isc_task_t *task, isc_event_t *event) {
 	 * so, destroy the fctx.
 	 */
 	if (SHUTTINGDOWN(fctx) && !sentresponse) {
-		maybe_destroy(fctx);	/* Locks bucket. */
+		maybe_destroy(fctx);    /* Locks bucket. */
 		goto cleanup_event;
 	}
 
@@ -3543,6 +3831,9 @@ validated(isc_task_t *task, isc_event_t *event) {
 
 	if (vevent->result != ISC_R_SUCCESS) {
 		FCTXTRACE("validation failed");
+		inc_stats(fctx->res, dns_resstatscounter_valfail);
+		fctx->valfail++;
+		fctx->vresult = vevent->result;
 		result = ISC_R_NOTFOUND;
 		if (vevent->rdataset != NULL)
 			result = dns_db_findnode(fctx->cache, vevent->name,
@@ -3557,7 +3848,7 @@ validated(isc_task_t *task, isc_event_t *event) {
 		if (result == ISC_R_SUCCESS)
 			dns_db_detachnode(fctx->cache, &node);
 		result = vevent->result;
-		add_bad(fctx, addrinfo, result);
+		add_bad(fctx, addrinfo, result, badns_validation);
 		isc_event_free(&event);
 		UNLOCK(&fctx->res->buckets[fctx->bucketnum].lock);
 		INSIST(fctx->validator == NULL);
@@ -3565,9 +3856,9 @@ validated(isc_task_t *task, isc_event_t *event) {
 		if (fctx->validator != NULL) {
 			dns_validator_send(fctx->validator);
 		} else if (sentresponse)
-			fctx_done(fctx, result);	/* Locks bucket. */
+			fctx_done(fctx, result, __LINE__); /* Locks bucket. */
 		else
-			fctx_try(fctx);			/* Locks bucket. */
+			fctx_try(fctx, ISC_TRUE);       /* Locks bucket. */
 		return;
 	}
 
@@ -3577,6 +3868,8 @@ validated(isc_task_t *task, isc_event_t *event) {
 		dns_rdatatype_t covers;
 		FCTXTRACE("nonexistence validation OK");
 
+		inc_stats(fctx->res, dns_resstatscounter_valnegsuccess);
+
 		if (fctx->rmessage->rcode == dns_rcode_nxdomain)
 			covers = dns_rdatatype_any;
 		else
@@ -3590,7 +3883,7 @@ validated(isc_task_t *task, isc_event_t *event) {
 		/*
 		 * If we are asking for a SOA record set the cache time
 		 * to zero to facilitate locating the containing zone of
-		 * a arbitary zone.
+		 * a arbitrary zone.
 		 */
 		ttl = fctx->res->view->maxncachettl;
 		if (fctx->type == dns_rdatatype_soa &&
@@ -3599,12 +3892,13 @@ validated(isc_task_t *task, isc_event_t *event) {
 			ttl = 0;
 
 		result = ncache_adderesult(fctx->rmessage, fctx->cache, node,
-					   covers, now, ttl,
+					   covers, now, ttl, vevent->optout,
 					   ardataset, &eresult);
 		if (result != ISC_R_SUCCESS)
 			goto noanswer_response;
 		goto answer_response;
-	}
+	} else
+		inc_stats(fctx->res, dns_resstatscounter_valsuccess);
 
 	FCTXTRACE("validation OK");
 
@@ -3615,6 +3909,11 @@ validated(isc_task_t *task, isc_event_t *event) {
 		RUNTIME_CHECK(result == ISC_R_SUCCESS);
 		INSIST(vevent->sigrdataset != NULL);
 		vevent->sigrdataset->ttl = vevent->rdataset->ttl;
+		if (vevent->proofs[DNS_VALIDATOR_CLOSESTENCLOSER] != NULL) {
+			result = dns_rdataset_addclosest(vevent->rdataset,
+				 vevent->proofs[DNS_VALIDATOR_CLOSESTENCLOSER]);
+			RUNTIME_CHECK(result == ISC_R_SUCCESS);
+		}
 	}
 
 	/*
@@ -3654,7 +3953,7 @@ validated(isc_task_t *task, isc_event_t *event) {
 		dns_db_detachnode(fctx->cache, &node);
 		UNLOCK(&fctx->res->buckets[fctx->bucketnum].lock);
 		if (SHUTTINGDOWN(fctx))
-			maybe_destroy(fctx);	/* Locks bucket. */
+			maybe_destroy(fctx);    /* Locks bucket. */
 		goto cleanup_event;
 	}
 
@@ -3744,7 +4043,7 @@ validated(isc_task_t *task, isc_event_t *event) {
 
 	UNLOCK(&fctx->res->buckets[fctx->bucketnum].lock);
 
-	fctx_done(fctx, result);	/* Locks bucket. */
+	fctx_done(fctx, result, __LINE__); /* Locks bucket. */
 
  cleanup_event:
 	INSIST(node == NULL);
@@ -3929,53 +4228,53 @@ cache_name(fetchctx_t *fctx, dns_name_t *name, dns_adbaddrinfo_t *addrinfo,
 			rdataset->trust = dns_trust_pending;
 			if (sigrdataset != NULL)
 				sigrdataset->trust = dns_trust_pending;
-			if (!need_validation)
+			if (!need_validation || !ANSWER(rdataset)) {
 				addedrdataset = ardataset;
-			else
-				addedrdataset = NULL;
-			result = dns_db_addrdataset(fctx->cache, node, NULL,
-						    now, rdataset, 0,
-						    addedrdataset);
-			if (result == DNS_R_UNCHANGED) {
-				result = ISC_R_SUCCESS;
-				if (!need_validation &&
-				    ardataset != NULL &&
-				    ardataset->type == 0) {
-					/*
-					 * The answer in the cache is better
-					 * than the answer we found, and is
-					 * a negative cache entry, so we
-					 * must set eresult appropriately.
-					 */
-					if (NXDOMAIN(ardataset))
-						eresult = DNS_R_NCACHENXDOMAIN;
-					else
-						eresult = DNS_R_NCACHENXRRSET;
-					/*
-					 * We have a negative response from
-					 * the cache so don't attempt to
-					 * add the RRSIG rrset.
-					 */
-					continue;
-				}
-			}
-			if (result != ISC_R_SUCCESS)
-				break;
-			if (sigrdataset != NULL) {
-				if (!need_validation)
-					addedrdataset = asigrdataset;
-				else
-					addedrdataset = NULL;
-				result = dns_db_addrdataset(fctx->cache,
-							    node, NULL, now,
-							    sigrdataset, 0,
-							    addedrdataset);
-				if (result == DNS_R_UNCHANGED)
+				result = dns_db_addrdataset(fctx->cache, node,
+							    NULL, now, rdataset,
+							    0, addedrdataset);
+				if (result == DNS_R_UNCHANGED) {
 					result = ISC_R_SUCCESS;
+					if (!need_validation &&
+					    ardataset != NULL &&
+					    ardataset->type == 0) {
+						/*
+						 * The answer in the cache is
+						 * better than the answer we
+						 * found, and is a negative
+						 * cache entry, so we must set
+						 * eresult appropriately.
+						 */
+						if (NXDOMAIN(ardataset))
+							eresult =
+							   DNS_R_NCACHENXDOMAIN;
+						else
+							eresult =
+							   DNS_R_NCACHENXRRSET;
+						/*
+						 * We have a negative response
+						 * from the cache so don't
+						 * attempt to add the RRSIG
+						 * rrset.
+						 */
+						continue;
+					}
+				}
 				if (result != ISC_R_SUCCESS)
 					break;
-			} else if (!ANSWER(rdataset))
-				continue;
+				if (sigrdataset != NULL) {
+					addedrdataset = asigrdataset;
+					result = dns_db_addrdataset(fctx->cache,
+								node, NULL, now,
+								sigrdataset, 0,
+								addedrdataset);
+					if (result == DNS_R_UNCHANGED)
+						result = ISC_R_SUCCESS;
+					if (result != ISC_R_SUCCESS)
+						break;
+				} else if (!ANSWER(rdataset))
+					continue;
+			}
 
 			if (ANSWER(rdataset) && need_validation) {
 				if (fctx->type != dns_rdatatype_any &&
@@ -4011,7 +4310,7 @@ cache_name(fetchctx_t *fctx, dns_name_t *name, dns_adbaddrinfo_t *addrinfo,
 					 * Defer any further validations.
 					 * This prevents multiple validators
 					 * from manipulating fctx->rmessage
-					 * simultaniously.
+					 * simultaneously.
 					 */
 					valoptions |= DNS_VALIDATOR_DEFER;
 				}
@@ -4155,12 +4454,12 @@ cache_message(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo, isc_stdtime_t now)
 }
 
 /*
- * Do what dns_ncache_add() does, and then compute an appropriate eresult.
+ * Do what dns_ncache_addoptout() does, and then compute an appropriate eresult.
  */
 static isc_result_t
 ncache_adderesult(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
 		  dns_rdatatype_t covers, isc_stdtime_t now, dns_ttl_t maxttl,
-		  dns_rdataset_t *ardataset,
+		  isc_boolean_t optout, dns_rdataset_t *ardataset,
 		  isc_result_t *eresultp)
 {
 	isc_result_t result;
@@ -4170,8 +4469,8 @@ ncache_adderesult(dns_message_t *message, dns_db_t *cache, dns_dbnode_t *node,
 		dns_rdataset_init(&rdataset);
 		ardataset = &rdataset;
 	}
-	result = dns_ncache_add(message, cache, node, covers, now,
-				maxttl, ardataset);
+	result = dns_ncache_addoptout(message, cache, node, covers, now,
+				     maxttl, optout, ardataset);
 	if (result == DNS_R_UNCHANGED || result == ISC_R_SUCCESS) {
 		/*
 		 * If the cache now contains a negative entry and we
@@ -4327,15 +4626,17 @@ ncache_message(fetchctx_t *fctx, dns_adbaddrinfo_t *addrinfo,
 	/*
 	 * If we are asking for a SOA record set the cache time
 	 * to zero to facilitate locating the containing zone of
-	 * a arbitary zone.
+	 * a arbitrary zone.
 	 */
 	ttl = fctx->res->view->maxncachettl;
 	if (fctx->type == dns_rdatatype_soa &&
-	    covers == dns_rdatatype_any)
+	    covers == dns_rdatatype_any &&
+	    fctx->res->zero_no_soa_ttl)
 		ttl = 0;
 
 	result = ncache_adderesult(fctx->rmessage, fctx->cache, node,
-				   covers, now, ttl, ardataset, &eresult);
+				   covers, now, ttl, ISC_FALSE,
+				   ardataset, &eresult);
 	if (result != ISC_R_SUCCESS)
 		goto unlock;
 
@@ -4710,7 +5011,8 @@ noanswer_response(fetchctx_t *fctx, dns_name_t *oqname,
 				type = rdataset->type;
 				if (type == dns_rdatatype_rrsig)
 					type = rdataset->covers;
-				if (type == dns_rdatatype_nsec) {
+				if (type == dns_rdatatype_nsec ||
+				    type == dns_rdatatype_nsec3) {
 					/*
 					 * NSEC or RRSIG NSEC.
 					 */
@@ -4719,7 +5021,7 @@ noanswer_response(fetchctx_t *fctx, dns_name_t *oqname,
 							DNS_NAMEATTR_NCACHE;
 						rdataset->attributes |=
 							DNS_RDATASETATTR_NCACHE;
-					} else {
+					} else if (type == dns_rdatatype_nsec) {
 						name->attributes |=
 							DNS_NAMEATTR_CACHE;
 						rdataset->attributes |=
@@ -4855,7 +5157,7 @@ noanswer_response(fetchctx_t *fctx, dns_name_t *oqname,
 		 * Set the current query domain to the referral name.
 		 *
 		 * XXXRTH  We should check if we're in forward-only mode, and
-		 *	   if so we should bail out.
+		 *		if so we should bail out.
 		 */
 		INSIST(dns_name_countlabels(&fctx->domain) > 0);
 		dns_name_free(&fctx->domain,
@@ -4931,6 +5233,13 @@ answer_response(fetchctx_t *fctx) {
 				found = ISC_FALSE;
 				want_chaining = ISC_FALSE;
 				aflag = 0;
+				if (rdataset->type == dns_rdatatype_nsec3) {
+					/*
+					 * NSEC3 records are not allowed to
+					 * appear in the answer section.
+					 */
+					return (DNS_R_FORMERR);
+				}
 				if (rdataset->type == type && !found_cname) {
 					/*
 					 * We've found an ordinary answer.
@@ -5157,7 +5466,7 @@ answer_response(fetchctx_t *fctx) {
 					 */
 					if (found_dname) {
 						/*
-						 * Copy the the dname into the
+						 * Copy the dname into the
 						 * qname fixed name.
 						 *
 						 * Although we check for
@@ -5311,7 +5620,7 @@ resume_dslookup(isc_task_t *task, isc_event_t *event) {
 	bucketnum = fctx->bucketnum;
 	if (fevent->result == ISC_R_CANCELED) {
 		dns_resolver_destroyfetch(&fctx->nsfetch);
-		fctx_done(fctx, ISC_R_CANCELED);
+		fctx_done(fctx, ISC_R_CANCELED, __LINE__);
 	} else if (fevent->result == ISC_R_SUCCESS) {
 
 		FCTXTRACE("resuming DS lookup");
@@ -5327,13 +5636,13 @@ resume_dslookup(isc_task_t *task, isc_event_t *event) {
 				      fctx->res->buckets[bucketnum].mctx,
 				      &fctx->domain);
 		if (result != ISC_R_SUCCESS) {
-			fctx_done(fctx, DNS_R_SERVFAIL);
+			fctx_done(fctx, DNS_R_SERVFAIL, __LINE__);
 			goto cleanup;
 		}
 		/*
 		 * Try again.
 		 */
-		fctx_try(fctx);
+		fctx_try(fctx, ISC_TRUE);
 	} else {
 		unsigned int n;
 		dns_rdataset_t *nsrdataset = NULL;
@@ -5345,7 +5654,7 @@ resume_dslookup(isc_task_t *task, isc_event_t *event) {
 		domain = dns_fixedname_name(&fixed);
 		dns_name_copy(&fctx->nsfetch->private->domain, domain, NULL);
 		if (dns_name_equal(&fctx->nsname, domain)) {
-			fctx_done(fctx, DNS_R_SERVFAIL);
+			fctx_done(fctx, DNS_R_SERVFAIL, __LINE__);
 			dns_resolver_destroyfetch(&fctx->nsfetch);
 			goto cleanup;
 		}
@@ -5372,7 +5681,7 @@ resume_dslookup(isc_task_t *task, isc_event_t *event) {
 						  &fctx->nsrrset, NULL,
 						  &fctx->nsfetch);
 		if (result != ISC_R_SUCCESS)
-			fctx_done(fctx, result);
+			fctx_done(fctx, result, __LINE__);
 		else {
 			LOCK(&res->buckets[bucketnum].lock);
 			locked = ISC_TRUE;
@@ -5439,6 +5748,65 @@ checknames(dns_message_t *message) {
 	checknamessection(message, DNS_SECTION_ADDITIONAL);
 }
 
+/*
+ * Log server NSID at log level 'level'
+ */
+static isc_result_t
+log_nsid(dns_rdataset_t *opt, resquery_t *query, int level, isc_mem_t *mctx)
+{
+	static const char hex[17] = "0123456789abcdef";
+	char addrbuf[ISC_SOCKADDR_FORMATSIZE];
+	isc_uint16_t optcode, nsid_len, buflen, i;
+	isc_result_t result;
+	isc_buffer_t nsidbuf;
+	dns_rdata_t rdata;
+	unsigned char *p, *buf, *nsid;
+
+	/* Extract rdata from OPT rdataset */
+	result = dns_rdataset_first(opt);
+	if (result != ISC_R_SUCCESS)
+		return (ISC_R_FAILURE);
+
+	dns_rdata_init(&rdata);
+	dns_rdataset_current(opt, &rdata);
+	if (rdata.length < 4)
+		return (ISC_R_FAILURE);
+
+	/* Check for NSID */
+	isc_buffer_init(&nsidbuf, rdata.data, rdata.length);
+	isc_buffer_add(&nsidbuf, rdata.length);
+	optcode = isc_buffer_getuint16(&nsidbuf);
+	nsid_len = isc_buffer_getuint16(&nsidbuf);
+	if (optcode != DNS_OPT_NSID || nsid_len == 0)
+		return (ISC_R_FAILURE);
+
+	/* Allocate buffer for storing hex version of the NSID */
+	buflen = nsid_len * 2 + 1;
+	buf = isc_mem_get(mctx, buflen);
+	if (buf == NULL)
+		return (ISC_R_NOSPACE);
+
+	/* Convert to hex */
+	p = buf;
+	nsid = rdata.data + 4;
+	for (i = 0; i < nsid_len; i++) {
+		*p++ = hex[(nsid[0] >> 4) & 0xf];
+		*p++ = hex[nsid[0] & 0xf];
+		nsid++;
+	}
+	*p = '\0';
+
+	isc_sockaddr_format(&query->addrinfo->sockaddr, addrbuf,
+			    sizeof(addrbuf));
+	isc_log_write(dns_lctx, DNS_LOGCATEGORY_RESOLVER,
+		      DNS_LOGMODULE_RESOLVER, level,
+		      "received NSID '%s' from %s", buf, addrbuf);
+
+	/* Clean up */
+	isc_mem_put(mctx, buf, buflen);
+	return (ISC_R_SUCCESS);
+}
+
 static void
 log_packet(dns_message_t *message, int level, isc_mem_t *mctx) {
 	isc_buffer_t buffer;
@@ -5484,6 +5852,7 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 	isc_boolean_t keep_trying, get_nameservers, resend;
 	isc_boolean_t truncated;
 	dns_message_t *message;
+	dns_rdataset_t *opt;
 	fetchctx_t *fctx;
 	dns_name_t *fname;
 	dns_fixedname_t foundname;
@@ -5493,6 +5862,7 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 	unsigned int options;
 	unsigned int findoptions;
 	isc_result_t broken_server;
+	badnstype_t broken_type = badns_response;
 
 	REQUIRE(VALID_QUERY(query));
 	fctx = query->fctx;
@@ -5502,6 +5872,11 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 
 	QTRACE("response");
 
+	if (isc_sockaddr_pf(&query->addrinfo->sockaddr) == PF_INET)
+		inc_stats(fctx->res, dns_resstatscounter_responsev4);
+	else
+		inc_stats(fctx->res, dns_resstatscounter_responsev6);
+
 	(void)isc_timer_touch(fctx->timer);
 
 	keep_trying = ISC_FALSE;
@@ -5517,11 +5892,12 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 	}
 
 	fctx->timeouts = 0;
+	fctx->timeout = ISC_FALSE;
 
 	/*
 	 * XXXRTH  We should really get the current time just once.  We
-	 *	   need a routine to convert from an isc_time_t to an
-	 *	   isc_stdtime_t.
+	 *		need a routine to convert from an isc_time_t to an
+	 *		isc_stdtime_t.
 	 */
 	TIME_NOW(&tnow);
 	finish = &tnow;
@@ -5564,6 +5940,7 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 			     devent->result == ISC_R_CONNREFUSED ||
 			     devent->result == ISC_R_CANCELED)) {
 				    broken_server = devent->result;
+				    broken_type = badns_unreachable;
 			}
 		}
 		goto done;
@@ -5616,6 +5993,8 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 							query->addrinfo,
 							DNS_FETCHOPT_NOEDNS0,
 							DNS_FETCHOPT_NOEDNS0);
+					inc_stats(fctx->res,
+						 dns_resstatscounter_edns0fail);
 				} else {
 					broken_server = result;
 					keep_trying = ISC_TRUE;
@@ -5644,6 +6023,8 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 						    query->addrinfo,
 						    DNS_FETCHOPT_NOEDNS0,
 						    DNS_FETCHOPT_NOEDNS0);
+				inc_stats(fctx->res,
+						 dns_resstatscounter_edns0fail);
 			} else {
 				broken_server = DNS_R_UNEXPECTEDRCODE;
 				keep_trying = ISC_TRUE;
@@ -5657,12 +6038,21 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 		}
 	}
 
+
 	/*
 	 * Log the incoming packet.
 	 */
 	log_packet(message, ISC_LOG_DEBUG(10), fctx->res->mctx);
 
 	/*
+	 * Did we request NSID?  If so, and if the response contains
+	 * NSID data, log it at INFO level.
+	 */
+	opt = dns_message_getopt(message);
+	if (opt != NULL && (query->options & DNS_FETCHOPT_WANTNSID) != 0)
+		log_nsid(opt, query, ISC_LOG_INFO, fctx->res->mctx);
+
+	/*
 	 * If the message is signed, check the signature.  If not, this
 	 * returns success anyway.
 	 */
@@ -5690,6 +6080,7 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 		truncated = ISC_TRUE;
 
 	if (truncated) {
+		inc_stats(fctx->res, dns_resstatscounter_truncated);
 		if ((options & DNS_FETCHOPT_TCP) != 0) {
 			broken_server = DNS_R_TRUNCATEDTCP;
 			keep_trying = ISC_TRUE;
@@ -5711,6 +6102,26 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 	}
 
 	/*
+	 * Update statistics about erroneous responses.
+	 */
+	if (message->rcode != dns_rcode_noerror) {
+		switch (message->rcode) {
+		case dns_rcode_nxdomain:
+			inc_stats(fctx->res, dns_resstatscounter_nxdomain);
+			break;
+		case dns_rcode_servfail:
+			inc_stats(fctx->res, dns_resstatscounter_servfail);
+			break;
+		case dns_rcode_formerr:
+			inc_stats(fctx->res, dns_resstatscounter_formerr);
+			break;
+		default:
+			inc_stats(fctx->res, dns_resstatscounter_othererror);
+			break;
+		}
+	}
+
+	/*
 	 * Is the remote server broken, or does it dislike us?
 	 */
 	if (message->rcode != dns_rcode_noerror &&
@@ -5728,8 +6139,8 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 			 * reasons.
 			 *
 			 * XXXRTH  We should check if the question
-			 *	   we're asking requires EDNS0, and
-			 *	   if so, we should bail out.
+			 *		we're asking requires EDNS0, and
+			 *		if so, we should bail out.
 			 */
 			options |= DNS_FETCHOPT_NOEDNS0;
 			resend = ISC_TRUE;
@@ -5740,6 +6151,7 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 				dns_adb_changeflags(fctx->adb, query->addrinfo,
 						    DNS_FETCHOPT_NOEDNS0,
 						    DNS_FETCHOPT_NOEDNS0);
+			inc_stats(fctx->res, dns_resstatscounter_edns0fail);
 		} else if (message->rcode == dns_rcode_formerr) {
 			if (ISFORWARDER(query->addrinfo)) {
 				/*
@@ -5767,12 +6179,10 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 			 */
 			result = DNS_R_YXDOMAIN;
 		} else if (message->rcode == dns_rcode_badvers) {
-			dns_rdataset_t *opt;
 			unsigned int flags, mask;
 			unsigned int version;
 
 			resend = ISC_TRUE;
-			opt = dns_message_getopt(message);
 			version = (opt->ttl >> 16) & 0xff;
 			flags = (version << DNS_FETCHOPT_EDNSVERSIONSHIFT) |
 				DNS_FETCHOPT_EDNSVERSIONSET;
@@ -5815,6 +6225,7 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 	 */
 	if (fctx->res->lame_ttl != 0 && !ISFORWARDER(query->addrinfo) &&
 	    is_lame(fctx)) {
+		inc_stats(fctx->res, dns_resstatscounter_lame);
 		log_lame(fctx, query->addrinfo);
 		result = dns_adb_marklame(fctx->adb, query->addrinfo,
 					  &fctx->name, fctx->type,
@@ -5928,6 +6339,18 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 			 * has not experienced any restarts yet.
 			 */
 			fctx->restarts = 0;
+
+			/*
+			 * Update local statistics counters collected for each
+			 * new zone.
+			 */
+			fctx->referrals++;
+			fctx->querysent = 0;
+			fctx->lamecount = 0;
+			fctx->neterr = 0;
+			fctx->badresp = 0;
+			fctx->adberr = 0;
+
 			result = ISC_R_SUCCESS;
 		} else if (result != ISC_R_SUCCESS) {
 			/*
@@ -6001,7 +6424,7 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 			 * Add this server to the list of bad servers for
 			 * this fctx.
 			 */
-			add_bad(fctx, addrinfo, broken_server);
+			add_bad(fctx, addrinfo, broken_server, broken_type);
 		}
 
 		if (get_nameservers) {
@@ -6009,7 +6432,7 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 			dns_fixedname_init(&foundname);
 			fname = dns_fixedname_name(&foundname);
 			if (result != ISC_R_SUCCESS) {
-				fctx_done(fctx, DNS_R_SERVFAIL);
+				fctx_done(fctx, DNS_R_SERVFAIL, __LINE__);
 				return;
 			}
 			findoptions = 0;
@@ -6027,7 +6450,7 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 						      NULL);
 			if (result != ISC_R_SUCCESS) {
 				FCTXTRACE("couldn't find a zonecut");
-				fctx_done(fctx, DNS_R_SERVFAIL);
+				fctx_done(fctx, DNS_R_SERVFAIL, __LINE__);
 				return;
 			}
 			if (!dns_name_issubdomain(fname, &fctx->domain)) {
@@ -6036,7 +6459,7 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 				 * QDOMAIN.
 				 */
 				FCTXTRACE("nameservers now above QDOMAIN");
-				fctx_done(fctx, DNS_R_SERVFAIL);
+				fctx_done(fctx, DNS_R_SERVFAIL, __LINE__);
 				return;
 			}
 			dns_name_free(&fctx->domain,
@@ -6046,7 +6469,7 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 					      fctx->res->buckets[fctx->bucketnum].mctx,
 					      &fctx->domain);
 			if (result != ISC_R_SUCCESS) {
-				fctx_done(fctx, DNS_R_SERVFAIL);
+				fctx_done(fctx, DNS_R_SERVFAIL, __LINE__);
 				return;
 			}
 			fctx_cancelqueries(fctx, ISC_TRUE);
@@ -6058,15 +6481,16 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 		/*
 		 * Try again.
 		 */
-		fctx_try(fctx);
+		fctx_try(fctx, !get_nameservers);
 	} else if (resend) {
 		/*
 		 * Resend (probably with changed options).
 		 */
 		FCTXTRACE("resend");
+		inc_stats(fctx->res, dns_resstatscounter_retry);
 		result = fctx_query(fctx, addrinfo, options);
 		if (result != ISC_R_SUCCESS)
-			fctx_done(fctx, result);
+			fctx_done(fctx, result, __LINE__);
 	} else if (result == ISC_R_SUCCESS && !HAVE_ANSWER(fctx)) {
 		/*
 		 * All has gone well so far, but we are waiting for the
@@ -6080,10 +6504,10 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 		 */
 		result = fctx_stopidletimer(fctx);
 		if (result != ISC_R_SUCCESS)
-			fctx_done(fctx, result);
+			fctx_done(fctx, result, __LINE__);
 	} else if (result == DNS_R_CHASEDSSERVERS) {
 		unsigned int n;
-		add_bad(fctx, addrinfo, result);
+		add_bad(fctx, addrinfo, result, broken_type);
 		fctx_cancelqueries(fctx, ISC_TRUE);
 		fctx_cleanupfinds(fctx);
 		fctx_cleanupforwaddrs(fctx);
@@ -6100,18 +6524,18 @@ resquery_response(isc_task_t *task, isc_event_t *event) {
 						  &fctx->nsrrset, NULL,
 						  &fctx->nsfetch);
 		if (result != ISC_R_SUCCESS)
-			fctx_done(fctx, result);
+			fctx_done(fctx, result, __LINE__);
 		LOCK(&fctx->res->buckets[fctx->bucketnum].lock);
 		fctx->references++;
 		UNLOCK(&fctx->res->buckets[fctx->bucketnum].lock);
 		result = fctx_stopidletimer(fctx);
 		if (result != ISC_R_SUCCESS)
-			fctx_done(fctx, result);
+			fctx_done(fctx, result, __LINE__);
 	} else {
 		/*
 		 * We're done.
 		 */
-		fctx_done(fctx, result);
+		fctx_done(fctx, result, __LINE__);
 	}
 }
 
@@ -6284,7 +6708,8 @@ dns_resolver_create(dns_view_t *view,
 	res->spillatmax = 100;
 	res->spillattimer = NULL;
 	res->zero_no_soa_ttl = ISC_FALSE;
-
+	res->ndisps = 0;
+	res->nextdisp = 0; /* meaningless at this point, but init it */
 	res->nbuckets = ntasks;
 	res->activebuckets = ntasks;
 	res->buckets = isc_mem_get(view->mctx,
@@ -6304,13 +6729,23 @@ dns_resolver_create(dns_view_t *view,
 			goto cleanup_buckets;
 		}
 		res->buckets[i].mctx = NULL;
+		snprintf(name, sizeof(name), "res%u", i);
+#ifdef ISC_PLATFORM_USETHREADS
+		/*
+		 * Use a separate memory context for each bucket to reduce
+		 * contention among multiple threads.  Do this only when
+		 * enabling threads because it will be require more memory.
+		 */
 		result = isc_mem_create(0, 0, &res->buckets[i].mctx);
 		if (result != ISC_R_SUCCESS) {
 			isc_task_detach(&res->buckets[i].task);
 			DESTROYLOCK(&res->buckets[i].lock);
 			goto cleanup_buckets;
 		}
-		snprintf(name, sizeof(name), "res%u", i);
+		isc_mem_setname(res->buckets[i].mctx, name, NULL);
+#else
+		isc_mem_attach(view->mctx, &res->buckets[i].mctx);
+#endif
 		isc_task_setname(res->buckets[i].task, name, res);
 		ISC_LIST_INIT(res->buckets[i].fctxs);
 		res->buckets[i].exiting = ISC_FALSE;
@@ -6356,14 +6791,14 @@ dns_resolver_create(dns_view_t *view,
 	task = NULL;
 	result = isc_task_create(taskmgr, 0, &task);
 	if (result != ISC_R_SUCCESS)
-		 goto cleanup_primelock;
+		goto cleanup_primelock;
 
 	result = isc_timer_create(timermgr, isc_timertype_inactive, NULL, NULL,
 				  task, spillattimer_countdown, res,
 				  &res->spillattimer);
 	isc_task_detach(&task);
 	if (result != ISC_R_SUCCESS)
-		 goto cleanup_primelock;
+		goto cleanup_primelock;
 
 #if USE_ALGLOCK
 	result = isc_rwlock_init(&res->alglock, 0, 0);
@@ -6973,6 +7408,47 @@ dns_resolver_destroyfetch(dns_fetch_t **fetchp) {
 		empty_bucket(res);
 }
 
+void
+dns_resolver_logfetch(dns_fetch_t *fetch, isc_log_t *lctx,
+		      isc_logcategory_t *category, isc_logmodule_t *module,
+		      int level, isc_boolean_t duplicateok)
+{
+	fetchctx_t *fctx;
+	dns_resolver_t *res;
+	char domainbuf[DNS_NAME_FORMATSIZE];
+
+	REQUIRE(DNS_FETCH_VALID(fetch));
+	fctx = fetch->private;
+	REQUIRE(VALID_FCTX(fctx));
+	res = fctx->res;
+
+	LOCK(&res->buckets[fctx->bucketnum].lock);
+
+	INSIST(fctx->exitline >= 0);
+	if (!fctx->logged || duplicateok) {
+		dns_name_format(&fctx->domain, domainbuf, sizeof(domainbuf));
+		isc_log_write(lctx, category, module, level,
+			      "fetch completed at %s:%d for %s in "
+			      "%" ISC_PRINT_QUADFORMAT "u."
+			      "%06" ISC_PRINT_QUADFORMAT "u: %s/%s "
+			      "[domain:%s,referral:%u,restart:%u,qrysent:%u,"
+			      "timeout:%u,lame:%u,neterr:%u,badresp:%u,"
+			      "adberr:%u,findfail:%u,valfail:%u]",
+			      __FILE__, fctx->exitline, fctx->info,
+			      fctx->duration / 1000000,
+			      fctx->duration % 1000000,
+			      isc_result_totext(fctx->result),
+			      isc_result_totext(fctx->vresult), domainbuf,
+			      fctx->referrals, fctx->restarts,
+			      fctx->querysent, fctx->timeouts, fctx->lamecount,
+			      fctx->neterr, fctx->badresp, fctx->adberr,
+			      fctx->findfail, fctx->valfail);
+		fctx->logged = ISC_TRUE;
+	}
+
+	UNLOCK(&res->buckets[fctx->bucketnum].lock);
+}
+
 dns_dispatchmgr_t *
 dns_resolver_dispatchmgr(dns_resolver_t *resolver) {
 	REQUIRE(VALID_RESOLVER(resolver));
@@ -7296,3 +7772,10 @@ dns_resolver_setzeronosoattl(dns_resolver_t *resolver, isc_boolean_t state) {
 
 	resolver->zero_no_soa_ttl = state;
 }
+
+unsigned int
+dns_resolver_getoptions(dns_resolver_t *resolver) {
+	REQUIRE(VALID_RESOLVER(resolver));
+
+	return (resolver->options);
+}
diff --git a/contrib/bind9/lib/dns/result.c b/contrib/bind9/lib/dns/result.c
index fdb58e0..54c70e0 100644
--- a/contrib/bind9/lib/dns/result.c
+++ b/contrib/bind9/lib/dns/result.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: result.c,v 1.115.10.7 2005/06/17 02:04:31 marka Exp $ */
+/* $Id: result.c,v 1.125 2008/09/25 04:02:38 tbox Exp $ */
 
 /*! \file */
 
@@ -155,7 +155,8 @@ static const char *text[DNS_R_NRESULTS] = {
 	"must-be-secure",		       /*%< 100 DNS_R_MUSTBESECURE */
 	"covering NSEC record returned",       /*%< 101 DNS_R_COVERINGNSEC */
 	"MX is an address",		       /*%< 102 DNS_R_MXISADDRESS */
-	"duplicate query"		       /*%< 103 DNS_R_DUPLICATE */
+	"duplicate query",		       /*%< 103 DNS_R_DUPLICATE */
+	"invalid NSEC3 owner name (wildcard)", /*%< 104 DNS_R_INVALIDNSEC3 */
 };
 
 static const char *rcode_text[DNS_R_NRCODERESULTS] = {
diff --git a/contrib/bind9/lib/dns/rootns.c b/contrib/bind9/lib/dns/rootns.c
index a988bea..3c50a18 100644
--- a/contrib/bind9/lib/dns/rootns.c
+++ b/contrib/bind9/lib/dns/rootns.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rootns.c,v 1.26.18.7 2008/02/05 23:46:09 tbox Exp $ */
+/* $Id: rootns.c,v 1.36 2008/09/24 02:46:22 marka Exp $ */
 
 /*! \file */
 
@@ -97,6 +97,7 @@ in_rootns(dns_rdataset_t *rootns, dns_name_t *name) {
 		if (dns_name_compare(name, &ns.name) == 0)
 			return (ISC_R_SUCCESS);
 		result = dns_rdataset_next(rootns);
+		dns_rdata_reset(&rdata);
 	}
 	if (result == ISC_R_NOMORE)
 		result = ISC_R_NOTFOUND;
@@ -158,7 +159,7 @@ check_hints(dns_db_t *db) {
 	dns_rdataset_init(&rootns);
 	(void)dns_db_find(db, dns_rootname, NULL, dns_rdatatype_ns, 0,
 			  now, NULL, name, &rootns, NULL);
-	result = dns_db_createiterator(db, ISC_FALSE, &dbiter);
+	result = dns_db_createiterator(db, 0, &dbiter);
 	if (result != ISC_R_SUCCESS)
 		goto cleanup;
 	result = dns_dbiterator_first(dbiter);
@@ -338,6 +339,7 @@ check_address_records(dns_view_t *view, dns_db_t *hints, dns_db_t *db,
 	    (rresult == ISC_R_SUCCESS || rresult == DNS_R_GLUE)) {
 		result = dns_rdataset_first(&rootrrset);
 		while (result == ISC_R_SUCCESS) {
+			dns_rdata_reset(&rdata);
 			dns_rdataset_current(&rootrrset, &rdata);
 			if (!inrrset(&hintrrset, &rdata))
 				report(view, name, ISC_TRUE, &rdata);
@@ -345,6 +347,7 @@ check_address_records(dns_view_t *view, dns_db_t *hints, dns_db_t *db,
 		}
 		result = dns_rdataset_first(&hintrrset);
 		while (result == ISC_R_SUCCESS) {
+			dns_rdata_reset(&rdata);
 			dns_rdataset_current(&hintrrset, &rdata);
 			if (!inrrset(&rootrrset, &rdata))
 				report(view, name, ISC_FALSE, &rdata);
@@ -355,6 +358,7 @@ check_address_records(dns_view_t *view, dns_db_t *hints, dns_db_t *db,
 	    (rresult == ISC_R_SUCCESS || rresult == DNS_R_GLUE)) {
 		result = dns_rdataset_first(&rootrrset);
 		while (result == ISC_R_SUCCESS) {
+			dns_rdata_reset(&rdata);
 			dns_rdataset_current(&rootrrset, &rdata);
 			report(view, name, ISC_TRUE, &rdata);
 			result = dns_rdataset_next(&rootrrset);
@@ -377,6 +381,7 @@ check_address_records(dns_view_t *view, dns_db_t *hints, dns_db_t *db,
 	    (rresult == ISC_R_SUCCESS || rresult == DNS_R_GLUE)) {
 		result = dns_rdataset_first(&rootrrset);
 		while (result == ISC_R_SUCCESS) {
+			dns_rdata_reset(&rdata);
 			dns_rdataset_current(&rootrrset, &rdata);
 			if (!inrrset(&hintrrset, &rdata))
 				report(view, name, ISC_TRUE, &rdata);
@@ -385,6 +390,7 @@ check_address_records(dns_view_t *view, dns_db_t *hints, dns_db_t *db,
 		}
 		result = dns_rdataset_first(&hintrrset);
 		while (result == ISC_R_SUCCESS) {
+			dns_rdata_reset(&rdata);
 			dns_rdataset_current(&hintrrset, &rdata);
 			if (!inrrset(&rootrrset, &rdata))
 				report(view, name, ISC_FALSE, &rdata);
@@ -396,6 +402,7 @@ check_address_records(dns_view_t *view, dns_db_t *hints, dns_db_t *db,
 	    (rresult == ISC_R_SUCCESS || rresult == DNS_R_GLUE)) {
 		result = dns_rdataset_first(&rootrrset);
 		while (result == ISC_R_SUCCESS) {
+			dns_rdata_reset(&rdata);
 			dns_rdataset_current(&rootrrset, &rdata);
 			report(view, name, ISC_TRUE, &rdata);
 			dns_rdata_reset(&rdata);
diff --git a/contrib/bind9/lib/dns/sdb.c b/contrib/bind9/lib/dns/sdb.c
index effb2bf..03fca9e 100644
--- a/contrib/bind9/lib/dns/sdb.c
+++ b/contrib/bind9/lib/dns/sdb.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: sdb.c,v 1.45.18.16 2008/01/17 23:45:58 tbox Exp $ */
+/* $Id: sdb.c,v 1.66.48.2 2009/04/21 23:47:18 tbox Exp $ */
 
 /*! \file */
 
@@ -880,9 +880,12 @@ find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
 				{
 					result = DNS_R_ZONECUT;
 					dns_rdataset_disassociate(rdataset);
-					if (sigrdataset != NULL)
+					if (sigrdataset != NULL &&
+					    dns_rdataset_isassociated
+							(sigrdataset)) {
 						dns_rdataset_disassociate
 								(sigrdataset);
+					}
 				} else
 					result = DNS_R_DELEGATION;
 				break;
@@ -1035,8 +1038,7 @@ printnode(dns_db_t *db, dns_dbnode_t *node, FILE *out) {
 }
 
 static isc_result_t
-createiterator(dns_db_t *db, isc_boolean_t relative_names,
-	       dns_dbiterator_t **iteratorp)
+createiterator(dns_db_t *db, unsigned int options, dns_dbiterator_t **iteratorp)
 {
 	dns_sdb_t *sdb = (dns_sdb_t *)db;
 	sdb_dbiterator_t *sdbiter;
@@ -1048,6 +1050,10 @@ createiterator(dns_db_t *db, isc_boolean_t relative_names,
 	if (imp->methods->allnodes == NULL)
 		return (ISC_R_NOTIMPLEMENTED);
 
+	if ((options & DNS_DB_NSEC3ONLY) != 0 ||
+	    (options & DNS_DB_NONSEC3) != 0)
+		return (ISC_R_NOTIMPLEMENTED);
+
 	sdbiter = isc_mem_get(sdb->common.mctx, sizeof(sdb_dbiterator_t));
 	if (sdbiter == NULL)
 		return (ISC_R_NOMEMORY);
@@ -1055,7 +1061,7 @@ createiterator(dns_db_t *db, isc_boolean_t relative_names,
 	sdbiter->common.methods = &dbiterator_methods;
 	sdbiter->common.db = NULL;
 	dns_db_attach(db, &sdbiter->common.db);
-	sdbiter->common.relative_names = relative_names;
+	sdbiter->common.relative_names = ISC_TF(options & DNS_DB_RELATIVENAMES);
 	sdbiter->common.magic = DNS_DBITERATOR_MAGIC;
 	ISC_LIST_INIT(sdbiter->nodelist);
 	sdbiter->current = NULL;
@@ -1246,6 +1252,14 @@ static dns_dbmethods_t sdb_methods = {
 	ispersistent,
 	overmem,
 	settask,
+	NULL,
+	NULL,
+	NULL,
+	NULL,
+	NULL,
+	NULL,
+	NULL,
+	NULL,
 	NULL
 };
 
@@ -1371,6 +1385,8 @@ static dns_rdatasetmethods_t methods = {
 	isc__rdatalist_getnoqname,
 	NULL,
 	NULL,
+	NULL,
+	NULL,
 	NULL
 };
 
diff --git a/contrib/bind9/lib/dns/sdlz.c b/contrib/bind9/lib/dns/sdlz.c
index b91f825..89cd0ee 100644
--- a/contrib/bind9/lib/dns/sdlz.c
+++ b/contrib/bind9/lib/dns/sdlz.c
@@ -1,5 +1,5 @@
 /*
- * Portions Copyright (C) 2005-2007  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2005-2009  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 1999-2001  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -50,7 +50,7 @@
  * USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: sdlz.c,v 1.2.2.11 2007/08/28 07:20:05 tbox Exp $ */
+/* $Id: sdlz.c,v 1.18.50.2 2009/04/21 23:47:18 tbox Exp $ */
 
 /*! \file */
 
@@ -667,8 +667,7 @@ printnode(dns_db_t *db, dns_dbnode_t *node, FILE *out) {
 }
 
 static isc_result_t
-createiterator(dns_db_t *db, isc_boolean_t relative_names,
-	       dns_dbiterator_t **iteratorp)
+createiterator(dns_db_t *db, unsigned int options, dns_dbiterator_t **iteratorp)
 {
 	dns_sdlz_db_t *sdlz = (dns_sdlz_db_t *)db;
 	sdlz_dbiterator_t *sdlziter;
@@ -681,6 +680,10 @@ createiterator(dns_db_t *db, isc_boolean_t relative_names,
 	if (sdlz->dlzimp->methods->allnodes == NULL)
 		return (ISC_R_NOTIMPLEMENTED);
 
+	if ((options & DNS_DB_NSEC3ONLY) != 0 ||
+	    (options & DNS_DB_NONSEC3) != 0)
+		 return (ISC_R_NOTIMPLEMENTED);
+
 	isc_buffer_init(&b, zonestr, sizeof(zonestr));
 	result = dns_name_totext(&sdlz->common.origin, ISC_TRUE, &b);
 	if (result != ISC_R_SUCCESS)
@@ -694,7 +697,7 @@ createiterator(dns_db_t *db, isc_boolean_t relative_names,
 	sdlziter->common.methods = &dbiterator_methods;
 	sdlziter->common.db = NULL;
 	dns_db_attach(db, &sdlziter->common.db);
-	sdlziter->common.relative_names = relative_names;
+	sdlziter->common.relative_names = ISC_TF(options & DNS_DB_RELATIVENAMES);
 	sdlziter->common.magic = DNS_DBITERATOR_MAGIC;
 	ISC_LIST_INIT(sdlziter->nodelist);
 	sdlziter->current = NULL;
@@ -841,9 +844,12 @@ find(dns_db_t *db, dns_name_t *name, dns_dbversion_t *version,
 				{
 					result = DNS_R_ZONECUT;
 					dns_rdataset_disassociate(rdataset);
-					if (sigrdataset != NULL)
+					if (sigrdataset != NULL &&
+					    dns_rdataset_isassociated
+							(sigrdataset)) {
 						dns_rdataset_disassociate
 							(sigrdataset);
+					}
 				} else
 					result = DNS_R_DELEGATION;
 				break;
@@ -1051,6 +1057,14 @@ static dns_dbmethods_t sdlzdb_methods = {
 	overmem,
 	settask,
 	NULL,
+	NULL,
+	NULL,
+	NULL,
+	NULL,
+	NULL,
+	NULL,
+	NULL,
+	NULL
 };
 
 /*
@@ -1193,6 +1207,8 @@ static dns_rdatasetmethods_t rdataset_methods = {
 	isc__rdatalist_getnoqname,
 	NULL,
 	NULL,
+	NULL,
+	NULL,
 	NULL
 };
 
@@ -1327,7 +1343,7 @@ dns_sdlzallowzonexfr(void *driverarg, void *dbdata, isc_mem_t *mctx,
 		return (result);
 	isc_buffer_putuint8(&b2, 0);
 
-        /* make sure strings are always lowercase */
+	/* make sure strings are always lowercase */
 	dns_sdlz_tolower(namestr);
 	dns_sdlz_tolower(clientstr);
 
@@ -1440,7 +1456,7 @@ dns_sdlzfindzone(void *driverarg, void *dbdata, isc_mem_t *mctx,
 		return (result);
 	isc_buffer_putuint8(&b, 0);
 
-        /* make sure strings are always lowercase */
+	/* make sure strings are always lowercase */
 	dns_sdlz_tolower(namestr);
 
 	/* Call SDLZ driver's find zone method */
@@ -1571,7 +1587,7 @@ dns_sdlz_putrr(dns_sdlzlookup_t *lookup, const char *type, dns_ttl_t ttl,
 	return (ISC_R_SUCCESS);
 
  failure:
- 	if (rdatabuf != NULL)
+	if (rdatabuf != NULL)
 		isc_buffer_free(&rdatabuf);
 	if (lex != NULL)
 		isc_lex_destroy(&lex);
diff --git a/contrib/bind9/lib/dns/soa.c b/contrib/bind9/lib/dns/soa.c
index 20198c0..83a1c17 100644
--- a/contrib/bind9/lib/dns/soa.c
+++ b/contrib/bind9/lib/dns/soa.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: soa.c,v 1.4.18.2 2005/04/29 00:16:05 marka Exp $ */
+/* $Id: soa.c,v 1.8 2007/06/19 23:47:16 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/dns/spnego.asn1 b/contrib/bind9/lib/dns/spnego.asn1
new file mode 100644
index 0000000..43d152b
--- /dev/null
+++ b/contrib/bind9/lib/dns/spnego.asn1
@@ -0,0 +1,52 @@
+-- Copyright (C) The Internet Society 2005.  This version of
+-- this module is part of RFC 4178; see the RFC itself for
+-- full legal notices.
+
+-- (The above copyright notice is per RFC 3978 5.6 (a), q.v.)
+
+-- $Id: spnego.asn1,v 1.2 2006/12/04 01:52:46 marka Exp $
+
+-- This is the SPNEGO ASN.1 module from RFC 4178, tweaked
+-- to get the Heimdal ASN.1 compiler to accept it.
+
+SPNEGOASNOneSpec DEFINITIONS ::= BEGIN
+
+MechType ::= OBJECT IDENTIFIER
+
+MechTypeList ::= SEQUENCE OF MechType
+
+ContextFlags ::= BIT STRING {
+    delegFlag       (0),
+    mutualFlag      (1),
+    replayFlag      (2),
+    sequenceFlag    (3),
+    anonFlag        (4),
+    confFlag        (5),
+    integFlag       (6)
+}
+
+NegTokenInit ::= SEQUENCE {
+    mechTypes       [0] MechTypeList,
+    reqFlags        [1] ContextFlags  OPTIONAL,
+    mechToken       [2] OCTET STRING  OPTIONAL,
+    mechListMIC     [3] OCTET STRING  OPTIONAL
+}
+
+NegTokenResp ::= SEQUENCE {
+    negState       [0] ENUMERATED {
+	accept-completed    (0),
+	accept-incomplete   (1),
+	reject              (2),
+	request-mic         (3)
+    }                                 OPTIONAL,
+    supportedMech   [1] MechType      OPTIONAL,
+    responseToken   [2] OCTET STRING  OPTIONAL,
+    mechListMIC     [3] OCTET STRING  OPTIONAL
+}
+
+NegotiationToken ::= CHOICE {
+    negTokenInit    [0] NegTokenInit,
+    negTokenResp    [1] NegTokenResp
+}
+
+END
diff --git a/contrib/bind9/lib/dns/spnego.c b/contrib/bind9/lib/dns/spnego.c
new file mode 100644
index 0000000..0ae6ea2
--- /dev/null
+++ b/contrib/bind9/lib/dns/spnego.c
@@ -0,0 +1,1792 @@
+/*
+ * Copyright (C) 2006-2009  Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or 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: spnego.c,v 1.8.118.2 2009/01/18 23:47:40 tbox Exp $ */
+
+/*! \file
+ * \brief
+ * Portable SPNEGO implementation.
+ *
+ * This is part of a portable implementation of the SPNEGO protocol
+ * (RFCs 2478 and 4178).  This implementation uses the RFC 4178 ASN.1
+ * module but is not a full implementation of the RFC 4178 protocol;
+ * at the moment, we only support GSS-TSIG with Kerberos
+ * authentication, so we only need enough of the SPNEGO protocol to
+ * support that.
+ *
+ * The files that make up this portable SPNEGO implementation are:
+ * \li	spnego.c	(this file)
+ * \li	spnego.h	(API SPNEGO exports to the rest of lib/dns)
+ * \li	spnego.asn1	(SPNEGO ASN.1 module)
+ * \li	spnego_asn1.c	(routines generated from spngo.asn1)
+ * \li	spnego_asn1.pl	(perl script to generate spnego_asn1.c)
+ *
+ * Everything but the functions exported in spnego.h is static, to
+ * avoid possible conflicts with other libraries (particularly Heimdal,
+ * since much of this code comes from Heimdal by way of mod_auth_kerb).
+ *
+ * spnego_asn1.c is shipped as part of lib/dns because generating it
+ * requires both Perl and the Heimdal ASN.1 compiler.  See
+ * spnego_asn1.pl for further details.  We've tried to eliminate all
+ * compiler warnings from the generated code, but you may see a few
+ * when using a compiler version we haven't tested yet.
+ */
+
+/*
+ * Portions of this code were derived from mod_auth_kerb and Heimdal.
+ * These packages are available from:
+ *
+ *   http://modauthkerb.sourceforge.net/
+ *   http://www.pdc.kth.se/heimdal/
+ *
+ * and were released under the following licenses:
+ *
+ * ----------------------------------------------------------------
+ *
+ * Copyright (c) 2004 Masarykova universita
+ * (Masaryk University, Brno, Czech Republic)
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright notice,
+ *    this list of conditions and the following disclaimer.
+ *
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * 3. Neither the name of the University nor the names of its contributors may
+ *    be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ *
+ * ----------------------------------------------------------------
+ *
+ * Copyright (c) 1997 - 2003 Kungliga Tekniska Högskolan
+ * (Royal Institute of Technology, Stockholm, Sweden).
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ *
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ *
+ * 3. Neither the name of the Institute nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE INSTITUTE AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE INSTITUTE OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+/*
+ * XXXSRA We should omit this file entirely in Makefile.in via autoconf,
+ * but this will keep it from generating errors until that's written.
+ */
+
+#ifdef GSSAPI
+
+/*
+ * XXXSRA Some of the following files are almost certainly unnecessary,
+ * but using this list (borrowed from gssapictx.c) gets rid of some
+ * whacky compilation errors when building with MSVC and should be
+ * harmless in any case.
+ */
+
+#include <config.h>
+
+#include <stdlib.h>
+#include <errno.h>
+
+#include <isc/buffer.h>
+#include <isc/dir.h>
+#include <isc/entropy.h>
+#include <isc/lex.h>
+#include <isc/mem.h>
+#include <isc/once.h>
+#include <isc/random.h>
+#include <isc/string.h>
+#include <isc/time.h>
+#include <isc/util.h>
+
+#include <dns/fixedname.h>
+#include <dns/name.h>
+#include <dns/rdata.h>
+#include <dns/rdataclass.h>
+#include <dns/result.h>
+#include <dns/types.h>
+#include <dns/keyvalues.h>
+#include <dns/log.h>
+
+#include <dst/gssapi.h>
+#include <dst/result.h>
+
+#include "dst_internal.h"
+
+/*
+ * The API we export
+ */
+#include "spnego.h"
+
+/* asn1_err.h */
+/* Generated from ../../../lib/asn1/asn1_err.et */
+
+typedef enum asn1_error_number {
+	ASN1_BAD_TIMEFORMAT = 1859794432,
+	ASN1_MISSING_FIELD = 1859794433,
+	ASN1_MISPLACED_FIELD = 1859794434,
+	ASN1_TYPE_MISMATCH = 1859794435,
+	ASN1_OVERFLOW = 1859794436,
+	ASN1_OVERRUN = 1859794437,
+	ASN1_BAD_ID = 1859794438,
+	ASN1_BAD_LENGTH = 1859794439,
+	ASN1_BAD_FORMAT = 1859794440,
+	ASN1_PARSE_ERROR = 1859794441
+} asn1_error_number;
+
+#define ERROR_TABLE_BASE_asn1 1859794432
+
+#define __asn1_common_definitions__
+
+typedef struct octet_string {
+	size_t length;
+	void *data;
+} octet_string;
+
+typedef char *general_string;
+
+typedef char *utf8_string;
+
+typedef struct oid {
+	size_t length;
+	unsigned *components;
+} oid;
+
+/* der.h */
+
+typedef enum {
+	ASN1_C_UNIV = 0, ASN1_C_APPL = 1,
+	ASN1_C_CONTEXT = 2, ASN1_C_PRIVATE = 3
+} Der_class;
+
+typedef enum {
+	PRIM = 0, CONS = 1
+} Der_type;
+
+/* Universal tags */
+
+enum {
+	UT_Boolean = 1,
+	UT_Integer = 2,
+	UT_BitString = 3,
+	UT_OctetString = 4,
+	UT_Null = 5,
+	UT_OID = 6,
+	UT_Enumerated = 10,
+	UT_Sequence = 16,
+	UT_Set = 17,
+	UT_PrintableString = 19,
+	UT_IA5String = 22,
+	UT_UTCTime = 23,
+	UT_GeneralizedTime = 24,
+	UT_VisibleString = 26,
+	UT_GeneralString = 27
+};
+
+#define ASN1_INDEFINITE 0xdce0deed
+
+static int
+der_get_length(const unsigned char *p, size_t len,
+	       size_t * val, size_t * size);
+
+static int
+der_get_octet_string(const unsigned char *p, size_t len,
+		     octet_string * data, size_t * size);
+static int
+der_get_oid(const unsigned char *p, size_t len,
+	    oid * data, size_t * size);
+static int
+der_get_tag(const unsigned char *p, size_t len,
+	    Der_class * class, Der_type * type,
+	    int *tag, size_t * size);
+
+static int
+der_match_tag(const unsigned char *p, size_t len,
+	      Der_class class, Der_type type,
+	      int tag, size_t * size);
+static int
+der_match_tag_and_length(const unsigned char *p, size_t len,
+			 Der_class class, Der_type type, int tag,
+			 size_t * length_ret, size_t * size);
+
+static int
+decode_oid(const unsigned char *p, size_t len,
+	   oid * k, size_t * size);
+
+static int
+decode_enumerated(const unsigned char *p, size_t len,
+		  unsigned *num, size_t *size);
+
+static int
+decode_octet_string(const unsigned char *, size_t, octet_string *, size_t *);
+
+static int
+der_put_int(unsigned char *p, size_t len, int val, size_t *);
+
+static int
+der_put_length(unsigned char *p, size_t len, size_t val, size_t *);
+
+static int
+der_put_octet_string(unsigned char *p, size_t len,
+		     const octet_string * data, size_t *);
+static int
+der_put_oid(unsigned char *p, size_t len,
+	    const oid * data, size_t * size);
+static int
+der_put_tag(unsigned char *p, size_t len, Der_class class, Der_type type,
+	    int tag, size_t *);
+static int
+der_put_length_and_tag(unsigned char *, size_t, size_t,
+		       Der_class, Der_type, int, size_t *);
+
+static int
+encode_enumerated(unsigned char *p, size_t len,
+		  const unsigned *data, size_t *);
+
+static int
+encode_octet_string(unsigned char *p, size_t len,
+		    const octet_string * k, size_t *);
+static int
+encode_oid(unsigned char *p, size_t len,
+	   const oid * k, size_t *);
+
+static void
+free_octet_string(octet_string * k);
+
+static void
+free_oid  (oid * k);
+
+static size_t
+length_len(size_t len);
+
+static int
+fix_dce(size_t reallen, size_t * len);
+
+/*
+ * Include stuff generated by the ASN.1 compiler.
+ */
+
+#include "spnego_asn1.c"
+
+static unsigned char gss_krb5_mech_oid_bytes[] = {
+	0x2a, 0x86, 0x48, 0x86, 0xf7, 0x12, 0x01, 0x02, 0x02
+};
+
+static gss_OID_desc gss_krb5_mech_oid_desc = {
+	sizeof(gss_krb5_mech_oid_bytes),
+	gss_krb5_mech_oid_bytes
+};
+
+static gss_OID GSS_KRB5_MECH = &gss_krb5_mech_oid_desc;
+
+static unsigned char gss_mskrb5_mech_oid_bytes[] = {
+	0x2a, 0x86, 0x48, 0x82, 0xf7, 0x12, 0x01, 0x02, 0x02
+};
+
+static gss_OID_desc gss_mskrb5_mech_oid_desc = {
+	sizeof(gss_mskrb5_mech_oid_bytes),
+	gss_mskrb5_mech_oid_bytes
+};
+
+static gss_OID GSS_MSKRB5_MECH = &gss_mskrb5_mech_oid_desc;
+
+static unsigned char gss_spnego_mech_oid_bytes[] = {
+	0x2b, 0x06, 0x01, 0x05, 0x05, 0x02
+};
+
+static gss_OID_desc gss_spnego_mech_oid_desc = {
+	sizeof(gss_spnego_mech_oid_bytes),
+	gss_spnego_mech_oid_bytes
+};
+
+static gss_OID GSS_SPNEGO_MECH = &gss_spnego_mech_oid_desc;
+
+/* spnegokrb5_locl.h */
+
+static OM_uint32
+gssapi_spnego_encapsulate(OM_uint32 *,
+			  unsigned char *,
+			  size_t,
+			  gss_buffer_t,
+			  const gss_OID);
+
+static OM_uint32
+gssapi_spnego_decapsulate(OM_uint32 *,
+			  gss_buffer_t,
+			  unsigned char **,
+			  size_t *,
+			  const gss_OID);
+
+/* mod_auth_kerb.c */
+
+static int
+cmp_gss_type(gss_buffer_t token, gss_OID oid)
+{
+	unsigned char *p;
+	size_t len;
+
+	if (token->length == 0)
+		return (GSS_S_DEFECTIVE_TOKEN);
+
+	p = token->value;
+	if (*p++ != 0x60)
+		return (GSS_S_DEFECTIVE_TOKEN);
+	len = *p++;
+	if (len & 0x80) {
+		if ((len & 0x7f) > 4)
+			return (GSS_S_DEFECTIVE_TOKEN);
+		p += len & 0x7f;
+	}
+	if (*p++ != 0x06)
+		return (GSS_S_DEFECTIVE_TOKEN);
+
+	if (((OM_uint32) *p++) != oid->length)
+		return (GSS_S_DEFECTIVE_TOKEN);
+
+	return (memcmp(p, oid->elements, oid->length));
+}
+
+/* accept_sec_context.c */
+/*
+ * SPNEGO wrapper for Kerberos5 GSS-API kouril@ics.muni.cz, 2003 (mostly
+ * based on Heimdal code)
+ */
+
+static OM_uint32
+code_NegTokenArg(OM_uint32 * minor_status,
+		 const NegTokenResp * resp,
+		 unsigned char **outbuf,
+		 size_t * outbuf_size)
+{
+	OM_uint32 ret;
+	u_char *buf;
+	size_t buf_size, buf_len;
+
+	buf_size = 1024;
+	buf = malloc(buf_size);
+	if (buf == NULL) {
+		*minor_status = ENOMEM;
+		return (GSS_S_FAILURE);
+	}
+	do {
+		ret = encode_NegTokenResp(buf + buf_size - 1,
+					  buf_size,
+					  resp, &buf_len);
+		if (ret == 0) {
+			size_t tmp;
+
+			ret = der_put_length_and_tag(buf + buf_size - buf_len - 1,
+						     buf_size - buf_len,
+						     buf_len,
+						     ASN1_C_CONTEXT,
+						     CONS,
+						     1,
+						     &tmp);
+			if (ret == 0)
+				buf_len += tmp;
+		}
+		if (ret) {
+			if (ret == ASN1_OVERFLOW) {
+				u_char *tmp;
+
+				buf_size *= 2;
+				tmp = realloc(buf, buf_size);
+				if (tmp == NULL) {
+					*minor_status = ENOMEM;
+					free(buf);
+					return (GSS_S_FAILURE);
+				}
+				buf = tmp;
+			} else {
+				*minor_status = ret;
+				free(buf);
+				return (GSS_S_FAILURE);
+			}
+		}
+	} while (ret == ASN1_OVERFLOW);
+
+	*outbuf = malloc(buf_len);
+	if (*outbuf == NULL) {
+		*minor_status = ENOMEM;
+		free(buf);
+		return (GSS_S_FAILURE);
+	}
+	memcpy(*outbuf, buf + buf_size - buf_len, buf_len);
+	*outbuf_size = buf_len;
+
+	free(buf);
+
+	return (GSS_S_COMPLETE);
+}
+
+static OM_uint32
+send_reject(OM_uint32 * minor_status,
+	    gss_buffer_t output_token)
+{
+	NegTokenResp resp;
+	OM_uint32 ret;
+
+	resp.negState = malloc(sizeof(*resp.negState));
+	if (resp.negState == NULL) {
+		*minor_status = ENOMEM;
+		return (GSS_S_FAILURE);
+	}
+	*(resp.negState) = reject;
+
+	resp.supportedMech = NULL;
+	resp.responseToken = NULL;
+	resp.mechListMIC = NULL;
+
+	ret = code_NegTokenArg(minor_status, &resp,
+			       (unsigned char **)&output_token->value,
+			       &output_token->length);
+	free_NegTokenResp(&resp);
+	if (ret)
+		return (ret);
+
+	return (GSS_S_BAD_MECH);
+}
+
+static OM_uint32
+send_accept(OM_uint32 * minor_status,
+	    gss_buffer_t output_token,
+	    gss_buffer_t mech_token,
+	    const gss_OID pref)
+{
+	NegTokenResp resp;
+	OM_uint32 ret;
+
+	memset(&resp, 0, sizeof(resp));
+	resp.negState = malloc(sizeof(*resp.negState));
+	if (resp.negState == NULL) {
+		*minor_status = ENOMEM;
+		return (GSS_S_FAILURE);
+	}
+	*(resp.negState) = accept_completed;
+
+	resp.supportedMech = malloc(sizeof(*resp.supportedMech));
+	if (resp.supportedMech == NULL) {
+		free_NegTokenResp(&resp);
+		*minor_status = ENOMEM;
+		return (GSS_S_FAILURE);
+	}
+	ret = der_get_oid(pref->elements,
+			  pref->length,
+			  resp.supportedMech,
+			  NULL);
+	if (ret) {
+		free_NegTokenResp(&resp);
+		*minor_status = ENOMEM;
+		return (GSS_S_FAILURE);
+	}
+	if (mech_token != NULL && mech_token->length != 0) {
+		resp.responseToken = malloc(sizeof(*resp.responseToken));
+		if (resp.responseToken == NULL) {
+			free_NegTokenResp(&resp);
+			*minor_status = ENOMEM;
+			return (GSS_S_FAILURE);
+		}
+		resp.responseToken->length = mech_token->length;
+		resp.responseToken->data = mech_token->value;
+	}
+
+	ret = code_NegTokenArg(minor_status, &resp,
+			       (unsigned char **)&output_token->value,
+			       &output_token->length);
+	if (resp.responseToken != NULL) {
+		free(resp.responseToken);
+		resp.responseToken = NULL;
+	}
+	free_NegTokenResp(&resp);
+	if (ret)
+		return (ret);
+
+	return (GSS_S_COMPLETE);
+}
+
+OM_uint32
+gss_accept_sec_context_spnego(OM_uint32 *minor_status,
+			      gss_ctx_id_t *context_handle,
+			      const gss_cred_id_t acceptor_cred_handle,
+			      const gss_buffer_t input_token_buffer,
+			      const gss_channel_bindings_t input_chan_bindings,
+			      gss_name_t *src_name,
+			      gss_OID *mech_type,
+			      gss_buffer_t output_token,
+			      OM_uint32 *ret_flags,
+			      OM_uint32 *time_rec,
+			      gss_cred_id_t *delegated_cred_handle)
+{
+	NegTokenInit init_token;
+	OM_uint32 major_status;
+	OM_uint32 minor_status2;
+	gss_buffer_desc ibuf, obuf;
+	gss_buffer_t ot = NULL;
+	gss_OID pref = GSS_KRB5_MECH;
+	unsigned char *buf;
+	size_t buf_size;
+	size_t len, taglen, ni_len;
+	int found = 0;
+	int ret;
+	unsigned i;
+
+	/*
+	 * Before doing anything else, see whether this is a SPNEGO
+	 * PDU.  If not, dispatch to the GSSAPI library and get out.
+	 */
+
+	if (cmp_gss_type(input_token_buffer, GSS_SPNEGO_MECH))
+		return (gss_accept_sec_context(minor_status,
+					       context_handle,
+					       acceptor_cred_handle,
+					       input_token_buffer,
+					       input_chan_bindings,
+					       src_name,
+					       mech_type,
+					       output_token,
+					       ret_flags,
+					       time_rec,
+					       delegated_cred_handle));
+
+	/*
+	 * If we get here, it's SPNEGO.
+	 */
+
+	memset(&init_token, 0, sizeof(init_token));
+
+	ret = gssapi_spnego_decapsulate(minor_status, input_token_buffer,
+					&buf, &buf_size, GSS_SPNEGO_MECH);
+	if (ret)
+		return (ret);
+
+	ret = der_match_tag_and_length(buf, buf_size, ASN1_C_CONTEXT, CONS,
+				       0, &len, &taglen);
+	if (ret)
+		return (ret);
+
+	ret = decode_NegTokenInit(buf + taglen, len, &init_token, &ni_len);
+	if (ret) {
+		*minor_status = EINVAL;	/* XXX */
+		return (GSS_S_DEFECTIVE_TOKEN);
+	}
+
+	for (i = 0; !found && i < init_token.mechTypes.len; ++i) {
+		char mechbuf[17];
+		size_t mech_len;
+
+		ret = der_put_oid(mechbuf + sizeof(mechbuf) - 1,
+				  sizeof(mechbuf),
+				  &init_token.mechTypes.val[i],
+				  &mech_len);
+		if (ret)
+			return (GSS_S_DEFECTIVE_TOKEN);
+		if (mech_len == GSS_KRB5_MECH->length &&
+		    memcmp(GSS_KRB5_MECH->elements,
+			   mechbuf + sizeof(mechbuf) - mech_len,
+			   mech_len) == 0) {
+			found = 1;
+			break;
+		}
+		if (mech_len == GSS_MSKRB5_MECH->length &&
+		    memcmp(GSS_MSKRB5_MECH->elements,
+			   mechbuf + sizeof(mechbuf) - mech_len,
+			   mech_len) == 0) {
+			found = 1;
+			if (i == 0)
+				pref = GSS_MSKRB5_MECH;
+			break;
+		}
+	}
+
+	if (!found)
+		return (send_reject(minor_status, output_token));
+
+	if (i == 0 && init_token.mechToken != NULL) {
+		ibuf.length = init_token.mechToken->length;
+		ibuf.value = init_token.mechToken->data;
+
+		major_status = gss_accept_sec_context(minor_status,
+						      context_handle,
+						      acceptor_cred_handle,
+						      &ibuf,
+						      input_chan_bindings,
+						      src_name,
+						      mech_type,
+						      &obuf,
+						      ret_flags,
+						      time_rec,
+						      delegated_cred_handle);
+		if (GSS_ERROR(major_status)) {
+			send_reject(&minor_status2, output_token);
+			return (major_status);
+		}
+		ot = &obuf;
+	}
+	ret = send_accept(&minor_status2, output_token, ot, pref);
+	if (ot != NULL && ot->length != 0)
+		gss_release_buffer(&minor_status2, ot);
+
+	return (ret);
+}
+
+/* decapsulate.c */
+
+static OM_uint32
+gssapi_verify_mech_header(u_char ** str,
+			  size_t total_len,
+			  const gss_OID mech)
+{
+	size_t len, len_len, mech_len, foo;
+	int e;
+	u_char *p = *str;
+
+	if (total_len < 1)
+		return (GSS_S_DEFECTIVE_TOKEN);
+	if (*p++ != 0x60)
+		return (GSS_S_DEFECTIVE_TOKEN);
+	e = der_get_length(p, total_len - 1, &len, &len_len);
+	if (e || 1 + len_len + len != total_len)
+		return (GSS_S_DEFECTIVE_TOKEN);
+	p += len_len;
+	if (*p++ != 0x06)
+		return (GSS_S_DEFECTIVE_TOKEN);
+	e = der_get_length(p, total_len - 1 - len_len - 1,
+			   &mech_len, &foo);
+	if (e)
+		return (GSS_S_DEFECTIVE_TOKEN);
+	p += foo;
+	if (mech_len != mech->length)
+		return (GSS_S_BAD_MECH);
+	if (memcmp(p, mech->elements, mech->length) != 0)
+		return (GSS_S_BAD_MECH);
+	p += mech_len;
+	*str = p;
+	return (GSS_S_COMPLETE);
+}
+
+/*
+ * Remove the GSS-API wrapping from `in_token' giving `buf and buf_size' Does
+ * not copy data, so just free `in_token'.
+ */
+
+static OM_uint32
+gssapi_spnego_decapsulate(OM_uint32 *minor_status,
+			  gss_buffer_t input_token_buffer,
+			  unsigned char **buf,
+			  size_t *buf_len,
+			  const gss_OID mech)
+{
+	u_char *p;
+	OM_uint32 ret;
+
+	p = input_token_buffer->value;
+	ret = gssapi_verify_mech_header(&p,
+					input_token_buffer->length,
+					mech);
+	if (ret) {
+		*minor_status = ret;
+		return (GSS_S_FAILURE);
+	}
+	*buf_len = input_token_buffer->length -
+		(p - (u_char *) input_token_buffer->value);
+	*buf = p;
+	return (GSS_S_COMPLETE);
+}
+
+/* der_free.c */
+
+static void
+free_octet_string(octet_string *k)
+{
+	free(k->data);
+	k->data = NULL;
+}
+
+static void
+free_oid(oid *k)
+{
+	free(k->components);
+	k->components = NULL;
+}
+
+/* der_get.c */
+
+/*
+ * All decoding functions take a pointer `p' to first position in which to
+ * read, from the left, `len' which means the maximum number of characters we
+ * are able to read, `ret' were the value will be returned and `size' where
+ * the number of used bytes is stored. Either 0 or an error code is returned.
+ */
+
+static int
+der_get_unsigned(const unsigned char *p, size_t len,
+		 unsigned *ret, size_t *size)
+{
+	unsigned val = 0;
+	size_t oldlen = len;
+
+	while (len--)
+		val = val * 256 + *p++;
+	*ret = val;
+	if (size)
+		*size = oldlen;
+	return (0);
+}
+
+static int
+der_get_int(const unsigned char *p, size_t len,
+	    int *ret, size_t *size)
+{
+	int val = 0;
+	size_t oldlen = len;
+
+	if (len > 0) {
+		val = (signed char)*p++;
+		while (--len)
+			val = val * 256 + *p++;
+	}
+	*ret = val;
+	if (size)
+		*size = oldlen;
+	return (0);
+}
+
+static int
+der_get_length(const unsigned char *p, size_t len,
+	       size_t *val, size_t *size)
+{
+	size_t v;
+
+	if (len <= 0)
+		return (ASN1_OVERRUN);
+	--len;
+	v = *p++;
+	if (v < 128) {
+		*val = v;
+		if (size)
+			*size = 1;
+	} else {
+		int e;
+		size_t l;
+		unsigned tmp;
+
+		if (v == 0x80) {
+			*val = ASN1_INDEFINITE;
+			if (size)
+				*size = 1;
+			return (0);
+		}
+		v &= 0x7F;
+		if (len < v)
+			return (ASN1_OVERRUN);
+		e = der_get_unsigned(p, v, &tmp, &l);
+		if (e)
+			return (e);
+		*val = tmp;
+		if (size)
+			*size = l + 1;
+	}
+	return (0);
+}
+
+static int
+der_get_octet_string(const unsigned char *p, size_t len,
+		     octet_string *data, size_t *size)
+{
+	data->length = len;
+	data->data = malloc(len);
+	if (data->data == NULL && data->length != 0)
+		return (ENOMEM);
+	memcpy(data->data, p, len);
+	if (size)
+		*size = len;
+	return (0);
+}
+
+static int
+der_get_oid(const unsigned char *p, size_t len,
+	    oid *data, size_t *size)
+{
+	int n;
+	size_t oldlen = len;
+
+	if (len < 1)
+		return (ASN1_OVERRUN);
+
+	data->components = malloc(len * sizeof(*data->components));
+	if (data->components == NULL && len != 0)
+		return (ENOMEM);
+	data->components[0] = (*p) / 40;
+	data->components[1] = (*p) % 40;
+	--len;
+	++p;
+	for (n = 2; len > 0; ++n) {
+		unsigned u = 0;
+
+		do {
+			--len;
+			u = u * 128 + (*p++ % 128);
+		} while (len > 0 && p[-1] & 0x80);
+		data->components[n] = u;
+	}
+	if (p[-1] & 0x80) {
+		free_oid(data);
+		return (ASN1_OVERRUN);
+	}
+	data->length = n;
+	if (size)
+		*size = oldlen;
+	return (0);
+}
+
+static int
+der_get_tag(const unsigned char *p, size_t len,
+	    Der_class *class, Der_type *type,
+	    int *tag, size_t *size)
+{
+	if (len < 1)
+		return (ASN1_OVERRUN);
+	*class = (Der_class) (((*p) >> 6) & 0x03);
+	*type = (Der_type) (((*p) >> 5) & 0x01);
+	*tag = (*p) & 0x1F;
+	if (size)
+		*size = 1;
+	return (0);
+}
+
+static int
+der_match_tag(const unsigned char *p, size_t len,
+	      Der_class class, Der_type type,
+	      int tag, size_t *size)
+{
+	size_t l;
+	Der_class thisclass;
+	Der_type thistype;
+	int thistag;
+	int e;
+
+	e = der_get_tag(p, len, &thisclass, &thistype, &thistag, &l);
+	if (e)
+		return (e);
+	if (class != thisclass || type != thistype)
+		return (ASN1_BAD_ID);
+	if (tag > thistag)
+		return (ASN1_MISPLACED_FIELD);
+	if (tag < thistag)
+		return (ASN1_MISSING_FIELD);
+	if (size)
+		*size = l;
+	return (0);
+}
+
+static int
+der_match_tag_and_length(const unsigned char *p, size_t len,
+			 Der_class class, Der_type type, int tag,
+			 size_t *length_ret, size_t *size)
+{
+	size_t l, ret = 0;
+	int e;
+
+	e = der_match_tag(p, len, class, type, tag, &l);
+	if (e)
+		return (e);
+	p += l;
+	len -= l;
+	ret += l;
+	e = der_get_length(p, len, length_ret, &l);
+	if (e)
+		return (e);
+	p += l;
+	len -= l;
+	ret += l;
+	if (size)
+		*size = ret;
+	return (0);
+}
+
+static int
+decode_enumerated(const unsigned char *p, size_t len,
+		  unsigned *num, size_t *size)
+{
+	size_t ret = 0;
+	size_t l, reallen;
+	int e;
+
+	e = der_match_tag(p, len, ASN1_C_UNIV, PRIM, UT_Enumerated, &l);
+	if (e)
+		return (e);
+	p += l;
+	len -= l;
+	ret += l;
+	e = der_get_length(p, len, &reallen, &l);
+	if (e)
+		return (e);
+	p += l;
+	len -= l;
+	ret += l;
+	e = der_get_int(p, reallen, num, &l);
+	if (e)
+		return (e);
+	p += l;
+	len -= l;
+	ret += l;
+	if (size)
+		*size = ret;
+	return (0);
+}
+
+static int
+decode_octet_string(const unsigned char *p, size_t len,
+		    octet_string *k, size_t *size)
+{
+	size_t ret = 0;
+	size_t l;
+	int e;
+	size_t slen;
+
+	e = der_match_tag(p, len, ASN1_C_UNIV, PRIM, UT_OctetString, &l);
+	if (e)
+		return (e);
+	p += l;
+	len -= l;
+	ret += l;
+
+	e = der_get_length(p, len, &slen, &l);
+	if (e)
+		return (e);
+	p += l;
+	len -= l;
+	ret += l;
+	if (len < slen)
+		return (ASN1_OVERRUN);
+
+	e = der_get_octet_string(p, slen, k, &l);
+	if (e)
+		return (e);
+	p += l;
+	len -= l;
+	ret += l;
+	if (size)
+		*size = ret;
+	return (0);
+}
+
+static int
+decode_oid(const unsigned char *p, size_t len,
+	   oid *k, size_t *size)
+{
+	size_t ret = 0;
+	size_t l;
+	int e;
+	size_t slen;
+
+	e = der_match_tag(p, len, ASN1_C_UNIV, PRIM, UT_OID, &l);
+	if (e)
+		return (e);
+	p += l;
+	len -= l;
+	ret += l;
+
+	e = der_get_length(p, len, &slen, &l);
+	if (e)
+		return (e);
+	p += l;
+	len -= l;
+	ret += l;
+	if (len < slen)
+		return (ASN1_OVERRUN);
+
+	e = der_get_oid(p, slen, k, &l);
+	if (e)
+		return (e);
+	p += l;
+	len -= l;
+	ret += l;
+	if (size)
+		*size = ret;
+	return (0);
+}
+
+static int
+fix_dce(size_t reallen, size_t *len)
+{
+	if (reallen == ASN1_INDEFINITE)
+		return (1);
+	if (*len < reallen)
+		return (-1);
+	*len = reallen;
+	return (0);
+}
+
+/* der_length.c */
+
+static size_t
+len_unsigned(unsigned val)
+{
+	size_t ret = 0;
+
+	do {
+		++ret;
+		val /= 256;
+	} while (val);
+	return (ret);
+}
+
+static size_t
+length_len(size_t len)
+{
+	if (len < 128)
+		return (1);
+	else
+		return (len_unsigned(len) + 1);
+}
+
+
+/* der_put.c */
+
+/*
+ * All encoding functions take a pointer `p' to first position in which to
+ * write, from the right, `len' which means the maximum number of characters
+ * we are able to write.  The function returns the number of characters
+ * written in `size' (if non-NULL). The return value is 0 or an error.
+ */
+
+static int
+der_put_unsigned(unsigned char *p, size_t len, unsigned val, size_t *size)
+{
+	unsigned char *base = p;
+
+	if (val) {
+		while (len > 0 && val) {
+			*p-- = val % 256;
+			val /= 256;
+			--len;
+		}
+		if (val != 0)
+			return (ASN1_OVERFLOW);
+		else {
+			*size = base - p;
+			return (0);
+		}
+	} else if (len < 1)
+		return (ASN1_OVERFLOW);
+	else {
+		*p = 0;
+		*size = 1;
+		return (0);
+	}
+}
+
+static int
+der_put_int(unsigned char *p, size_t len, int val, size_t *size)
+{
+	unsigned char *base = p;
+
+	if (val >= 0) {
+		do {
+			if (len < 1)
+				return (ASN1_OVERFLOW);
+			*p-- = val % 256;
+			len--;
+			val /= 256;
+		} while (val);
+		if (p[1] >= 128) {
+			if (len < 1)
+				return (ASN1_OVERFLOW);
+			*p-- = 0;
+			len--;
+		}
+	} else {
+		val = ~val;
+		do {
+			if (len < 1)
+				return (ASN1_OVERFLOW);
+			*p-- = ~(val % 256);
+			len--;
+			val /= 256;
+		} while (val);
+		if (p[1] < 128) {
+			if (len < 1)
+				return (ASN1_OVERFLOW);
+			*p-- = 0xff;
+			len--;
+		}
+	}
+	*size = base - p;
+	return (0);
+}
+
+static int
+der_put_length(unsigned char *p, size_t len, size_t val, size_t *size)
+{
+	if (len < 1)
+		return (ASN1_OVERFLOW);
+	if (val < 128) {
+		*p = val;
+		*size = 1;
+		return (0);
+	} else {
+		size_t l;
+		int e;
+
+		e = der_put_unsigned(p, len - 1, val, &l);
+		if (e)
+			return (e);
+		p -= l;
+		*p = 0x80 | l;
+		*size = l + 1;
+		return (0);
+	}
+}
+
+static int
+der_put_octet_string(unsigned char *p, size_t len,
+		     const octet_string *data, size_t *size)
+{
+	if (len < data->length)
+		return (ASN1_OVERFLOW);
+	p -= data->length;
+	len -= data->length;
+	memcpy(p + 1, data->data, data->length);
+	*size = data->length;
+	return (0);
+}
+
+static int
+der_put_oid(unsigned char *p, size_t len,
+	    const oid *data, size_t *size)
+{
+	unsigned char *base = p;
+	int n;
+
+	for (n = data->length - 1; n >= 2; --n) {
+		unsigned	u = data->components[n];
+
+		if (len < 1)
+			return (ASN1_OVERFLOW);
+		*p-- = u % 128;
+		u /= 128;
+		--len;
+		while (u > 0) {
+			if (len < 1)
+				return (ASN1_OVERFLOW);
+			*p-- = 128 + u % 128;
+			u /= 128;
+			--len;
+		}
+	}
+	if (len < 1)
+		return (ASN1_OVERFLOW);
+	*p-- = 40 * data->components[0] + data->components[1];
+	*size = base - p;
+	return (0);
+}
+
+static int
+der_put_tag(unsigned char *p, size_t len, Der_class class, Der_type type,
+	    int tag, size_t *size)
+{
+	if (len < 1)
+		return (ASN1_OVERFLOW);
+	*p = (class << 6) | (type << 5) | tag;	/* XXX */
+	*size = 1;
+	return (0);
+}
+
+static int
+der_put_length_and_tag(unsigned char *p, size_t len, size_t len_val,
+		       Der_class class, Der_type type, int tag, size_t *size)
+{
+	size_t ret = 0;
+	size_t l;
+	int e;
+
+	e = der_put_length(p, len, len_val, &l);
+	if (e)
+		return (e);
+	p -= l;
+	len -= l;
+	ret += l;
+	e = der_put_tag(p, len, class, type, tag, &l);
+	if (e)
+		return (e);
+	p -= l;
+	len -= l;
+	ret += l;
+	*size = ret;
+	return (0);
+}
+
+static int
+encode_enumerated(unsigned char *p, size_t len, const unsigned *data,
+		  size_t *size)
+{
+	unsigned num = *data;
+	size_t ret = 0;
+	size_t l;
+	int e;
+
+	e = der_put_int(p, len, num, &l);
+	if (e)
+		return (e);
+	p -= l;
+	len -= l;
+	ret += l;
+	e = der_put_length_and_tag(p, len, l, ASN1_C_UNIV, PRIM, UT_Enumerated, &l);
+	if (e)
+		return (e);
+	p -= l;
+	len -= l;
+	ret += l;
+	*size = ret;
+	return (0);
+}
+
+static int
+encode_octet_string(unsigned char *p, size_t len,
+		    const octet_string *k, size_t *size)
+{
+	size_t ret = 0;
+	size_t l;
+	int e;
+
+	e = der_put_octet_string(p, len, k, &l);
+	if (e)
+		return (e);
+	p -= l;
+	len -= l;
+	ret += l;
+	e = der_put_length_and_tag(p, len, l, ASN1_C_UNIV, PRIM, UT_OctetString, &l);
+	if (e)
+		return (e);
+	p -= l;
+	len -= l;
+	ret += l;
+	*size = ret;
+	return (0);
+}
+
+static int
+encode_oid(unsigned char *p, size_t len,
+	   const oid *k, size_t *size)
+{
+	size_t ret = 0;
+	size_t l;
+	int e;
+
+	e = der_put_oid(p, len, k, &l);
+	if (e)
+		return (e);
+	p -= l;
+	len -= l;
+	ret += l;
+	e = der_put_length_and_tag(p, len, l, ASN1_C_UNIV, PRIM, UT_OID, &l);
+	if (e)
+		return (e);
+	p -= l;
+	len -= l;
+	ret += l;
+	*size = ret;
+	return (0);
+}
+
+
+/* encapsulate.c */
+
+static void
+gssapi_encap_length(size_t data_len,
+		    size_t *len,
+		    size_t *total_len,
+		    const gss_OID mech)
+{
+	size_t len_len;
+
+	*len = 1 + 1 + mech->length + data_len;
+
+	len_len = length_len(*len);
+
+	*total_len = 1 + len_len + *len;
+}
+
+static u_char *
+gssapi_mech_make_header(u_char *p,
+			size_t len,
+			const gss_OID mech)
+{
+	int e;
+	size_t len_len, foo;
+
+	*p++ = 0x60;
+	len_len = length_len(len);
+	e = der_put_length(p + len_len - 1, len_len, len, &foo);
+	if (e || foo != len_len)
+		return (NULL);
+	p += len_len;
+	*p++ = 0x06;
+	*p++ = mech->length;
+	memcpy(p, mech->elements, mech->length);
+	p += mech->length;
+	return (p);
+}
+
+/*
+ * Give it a krb5_data and it will encapsulate with extra GSS-API wrappings.
+ */
+
+static OM_uint32
+gssapi_spnego_encapsulate(OM_uint32 * minor_status,
+			  unsigned char *buf,
+			  size_t buf_size,
+			  gss_buffer_t output_token,
+			  const gss_OID mech)
+{
+	size_t len, outer_len;
+	u_char *p;
+
+	gssapi_encap_length(buf_size, &len, &outer_len, mech);
+
+	output_token->length = outer_len;
+	output_token->value = malloc(outer_len);
+	if (output_token->value == NULL) {
+		*minor_status = ENOMEM;
+		return (GSS_S_FAILURE);
+	}
+	p = gssapi_mech_make_header(output_token->value, len, mech);
+	if (p == NULL) {
+		if (output_token->length != 0)
+			gss_release_buffer(minor_status, output_token);
+		return (GSS_S_FAILURE);
+	}
+	memcpy(p, buf, buf_size);
+	return (GSS_S_COMPLETE);
+}
+
+/* init_sec_context.c */
+/*
+ * SPNEGO wrapper for Kerberos5 GSS-API kouril@ics.muni.cz, 2003 (mostly
+ * based on Heimdal code)
+ */
+
+static int
+add_mech(MechTypeList * mech_list, gss_OID mech)
+{
+	MechType *tmp;
+	int ret;
+
+	tmp = realloc(mech_list->val, (mech_list->len + 1) * sizeof(*tmp));
+	if (tmp == NULL)
+		return (ENOMEM);
+	mech_list->val = tmp;
+
+	ret = der_get_oid(mech->elements, mech->length,
+			  &mech_list->val[mech_list->len], NULL);
+	if (ret)
+		return (ret);
+
+	mech_list->len++;
+	return (0);
+}
+
+/*
+ * return the length of the mechanism in token or -1
+ * (which implies that the token was bad - GSS_S_DEFECTIVE_TOKEN
+ */
+
+static ssize_t
+gssapi_krb5_get_mech(const u_char *ptr,
+		     size_t total_len,
+		     const u_char **mech_ret)
+{
+	size_t len, len_len, mech_len, foo;
+	const u_char *p = ptr;
+	int e;
+
+	if (total_len < 1)
+		return (-1);
+	if (*p++ != 0x60)
+		return (-1);
+	e = der_get_length (p, total_len - 1, &len, &len_len);
+	if (e || 1 + len_len + len != total_len)
+		return (-1);
+	p += len_len;
+	if (*p++ != 0x06)
+		return (-1);
+	e = der_get_length (p, total_len - 1 - len_len - 1,
+			    &mech_len, &foo);
+	if (e)
+		return (-1);
+	p += foo;
+	*mech_ret = p;
+	return (mech_len);
+}
+
+static OM_uint32
+spnego_initial(OM_uint32 *minor_status,
+	       const gss_cred_id_t initiator_cred_handle,
+	       gss_ctx_id_t *context_handle,
+	       const gss_name_t target_name,
+	       const gss_OID mech_type,
+	       OM_uint32 req_flags,
+	       OM_uint32 time_req,
+	       const gss_channel_bindings_t input_chan_bindings,
+	       const gss_buffer_t input_token,
+	       gss_OID *actual_mech_type,
+	       gss_buffer_t output_token,
+	       OM_uint32 *ret_flags,
+	       OM_uint32 *time_rec)
+{
+	NegTokenInit token_init;
+	OM_uint32 major_status, minor_status2;
+	gss_buffer_desc	krb5_output_token = GSS_C_EMPTY_BUFFER;
+	unsigned char *buf = NULL;
+	size_t buf_size;
+	size_t len;
+	int ret;
+
+	(void)mech_type;
+
+	memset(&token_init, 0, sizeof(token_init));
+
+	ret = add_mech(&token_init.mechTypes, GSS_KRB5_MECH);
+	if (ret) {
+		*minor_status = ret;
+		ret = GSS_S_FAILURE;
+		goto end;
+	}
+
+	major_status = gss_init_sec_context(minor_status,
+					    initiator_cred_handle,
+					    context_handle,
+					    target_name,
+					    GSS_KRB5_MECH,
+					    req_flags,
+					    time_req,
+					    input_chan_bindings,
+					    input_token,
+					    actual_mech_type,
+					    &krb5_output_token,
+					    ret_flags,
+					    time_rec);
+	if (GSS_ERROR(major_status)) {
+		ret = major_status;
+		goto end;
+	}
+	if (krb5_output_token.length > 0) {
+		token_init.mechToken = malloc(sizeof(*token_init.mechToken));
+		if (token_init.mechToken == NULL) {
+			*minor_status = ENOMEM;
+			ret = GSS_S_FAILURE;
+			goto end;
+		}
+		token_init.mechToken->data = krb5_output_token.value;
+		token_init.mechToken->length = krb5_output_token.length;
+	}
+	/*
+	 * The MS implementation of SPNEGO seems to not like the mechListMIC
+	 * field, so we omit it (it's optional anyway)
+	 */
+
+	buf_size = 1024;
+	buf = malloc(buf_size);
+
+	do {
+		ret = encode_NegTokenInit(buf + buf_size - 1,
+					  buf_size,
+					  &token_init, &len);
+		if (ret == 0) {
+			size_t tmp;
+
+			ret = der_put_length_and_tag(buf + buf_size - len - 1,
+						     buf_size - len,
+						     len,
+						     ASN1_C_CONTEXT,
+						     CONS,
+						     0,
+						     &tmp);
+			if (ret == 0)
+				len += tmp;
+		}
+		if (ret) {
+			if (ret == ASN1_OVERFLOW) {
+				u_char *tmp;
+
+				buf_size *= 2;
+				tmp = realloc(buf, buf_size);
+				if (tmp == NULL) {
+					*minor_status = ENOMEM;
+					ret = GSS_S_FAILURE;
+					goto end;
+				}
+				buf = tmp;
+			} else {
+				*minor_status = ret;
+				ret = GSS_S_FAILURE;
+				goto end;
+			}
+		}
+	} while (ret == ASN1_OVERFLOW);
+
+	ret = gssapi_spnego_encapsulate(minor_status,
+					buf + buf_size - len, len,
+					output_token, GSS_SPNEGO_MECH);
+	if (ret == GSS_S_COMPLETE)
+		ret = major_status;
+
+end:
+	if (token_init.mechToken != NULL) {
+		free(token_init.mechToken);
+		token_init.mechToken = NULL;
+	}
+	free_NegTokenInit(&token_init);
+	if (krb5_output_token.length != 0)
+		gss_release_buffer(&minor_status2, &krb5_output_token);
+	if (buf)
+		free(buf);
+
+	return (ret);
+}
+
+static OM_uint32
+spnego_reply(OM_uint32 *minor_status,
+	     const gss_cred_id_t initiator_cred_handle,
+	     gss_ctx_id_t *context_handle,
+	     const gss_name_t target_name,
+	     const gss_OID mech_type,
+	     OM_uint32 req_flags,
+	     OM_uint32 time_req,
+	     const gss_channel_bindings_t input_chan_bindings,
+	     const gss_buffer_t input_token,
+	     gss_OID *actual_mech_type,
+	     gss_buffer_t output_token,
+	     OM_uint32 *ret_flags,
+	     OM_uint32 *time_rec)
+{
+	OM_uint32 ret;
+	NegTokenResp resp;
+	unsigned char *buf;
+	size_t buf_size;
+	u_char oidbuf[17];
+	size_t oidlen;
+	gss_buffer_desc sub_token;
+	ssize_t mech_len;
+	const u_char *p;
+	size_t len, taglen;
+
+	(void)mech_type;
+
+	output_token->length = 0;
+	output_token->value  = NULL;
+
+	/*
+	 * SPNEGO doesn't include gss wrapping on SubsequentContextToken
+	 * like the Kerberos 5 mech does. But lets check for it anyway.
+	 */
+
+	mech_len = gssapi_krb5_get_mech(input_token->value,
+					input_token->length,
+					&p);
+
+	if (mech_len < 0) {
+		buf = input_token->value;
+		buf_size = input_token->length;
+	} else if ((size_t)mech_len == GSS_KRB5_MECH->length &&
+		   memcmp(GSS_KRB5_MECH->elements, p, mech_len) == 0)
+		return (gss_init_sec_context(minor_status,
+					     initiator_cred_handle,
+					     context_handle,
+					     target_name,
+					     GSS_KRB5_MECH,
+					     req_flags,
+					     time_req,
+					     input_chan_bindings,
+					     input_token,
+					     actual_mech_type,
+					     output_token,
+					     ret_flags,
+					     time_rec));
+	else if ((size_t)mech_len == GSS_SPNEGO_MECH->length &&
+		 memcmp(GSS_SPNEGO_MECH->elements, p, mech_len) == 0) {
+		ret = gssapi_spnego_decapsulate(minor_status,
+						input_token,
+						&buf,
+						&buf_size,
+						GSS_SPNEGO_MECH);
+		if (ret)
+			return (ret);
+	} else
+		return (GSS_S_BAD_MECH);
+
+	ret = der_match_tag_and_length(buf, buf_size,
+				       ASN1_C_CONTEXT, CONS, 1, &len, &taglen);
+	if (ret)
+		return (ret);
+
+	if(len > buf_size - taglen)
+		return (ASN1_OVERRUN);
+
+	ret = decode_NegTokenResp(buf + taglen, len, &resp, NULL);
+	if (ret) {
+		*minor_status = ENOMEM;
+		return (GSS_S_FAILURE);
+	}
+
+	if (resp.negState == NULL ||
+	    *(resp.negState) == reject ||
+	    resp.supportedMech == NULL) {
+		free_NegTokenResp(&resp);
+		return (GSS_S_BAD_MECH);
+	}
+
+	ret = der_put_oid(oidbuf + sizeof(oidbuf) - 1,
+			  sizeof(oidbuf),
+			  resp.supportedMech,
+			  &oidlen);
+	if (ret || oidlen != GSS_KRB5_MECH->length ||
+	    memcmp(oidbuf + sizeof(oidbuf) - oidlen,
+		   GSS_KRB5_MECH->elements,
+		   oidlen) != 0) {
+		free_NegTokenResp(&resp);
+		return GSS_S_BAD_MECH;
+	}
+
+	if (resp.responseToken != NULL) {
+		sub_token.length = resp.responseToken->length;
+		sub_token.value  = resp.responseToken->data;
+	} else {
+		sub_token.length = 0;
+		sub_token.value  = NULL;
+	}
+
+	ret = gss_init_sec_context(minor_status,
+				   initiator_cred_handle,
+				   context_handle,
+				   target_name,
+				   GSS_KRB5_MECH,
+				   req_flags,
+				   time_req,
+				   input_chan_bindings,
+				   &sub_token,
+				   actual_mech_type,
+				   output_token,
+				   ret_flags,
+				   time_rec);
+	if (ret) {
+		free_NegTokenResp(&resp);
+		return (ret);
+	}
+
+	/*
+	 * XXXSRA I don't think this limited implementation ever needs
+	 * to check the MIC -- our preferred mechanism (Kerberos)
+	 * authenticates its own messages and is the only mechanism
+	 * we'll accept, so if the mechanism negotiation completes
+	 * successfully, we don't need the MIC.  See RFC 4178.
+	 */
+
+	free_NegTokenResp(&resp);
+	return (ret);
+}
+
+
+
+OM_uint32
+gss_init_sec_context_spnego(OM_uint32 *minor_status,
+			    const gss_cred_id_t initiator_cred_handle,
+			    gss_ctx_id_t *context_handle,
+			    const gss_name_t target_name,
+			    const gss_OID mech_type,
+			    OM_uint32 req_flags,
+			    OM_uint32 time_req,
+			    const gss_channel_bindings_t input_chan_bindings,
+			    const gss_buffer_t input_token,
+			    gss_OID *actual_mech_type,
+			    gss_buffer_t output_token,
+			    OM_uint32 *ret_flags,
+			    OM_uint32 *time_rec)
+{
+	/* Dirty trick to suppress compiler warnings */
+
+	/* Figure out whether we're starting over or processing a reply */
+
+	if (input_token == GSS_C_NO_BUFFER || input_token->length == 0)
+		return (spnego_initial(minor_status,
+				       initiator_cred_handle,
+				       context_handle,
+				       target_name,
+				       mech_type,
+				       req_flags,
+				       time_req,
+				       input_chan_bindings,
+				       input_token,
+				       actual_mech_type,
+				       output_token,
+				       ret_flags,
+				       time_rec));
+	else
+		return (spnego_reply(minor_status,
+				     initiator_cred_handle,
+				     context_handle,
+				     target_name,
+				     mech_type,
+				     req_flags,
+				     time_req,
+				     input_chan_bindings,
+				     input_token,
+				     actual_mech_type,
+				     output_token,
+				     ret_flags,
+				     time_rec));
+}
+
+#endif /* GSSAPI */
diff --git a/contrib/bind9/lib/dns/spnego.h b/contrib/bind9/lib/dns/spnego.h
new file mode 100644
index 0000000..c44614b
--- /dev/null
+++ b/contrib/bind9/lib/dns/spnego.h
@@ -0,0 +1,71 @@
+/*
+ * Copyright (C) 2006, 2007  Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or 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: spnego.h,v 1.4 2007/06/19 23:47:16 tbox Exp $ */
+
+/*! \file
+ * \brief
+ * Entry points into portable SPNEGO implementation.
+ * See spnego.c for information on the SPNEGO implementation itself.
+ */
+
+#ifndef _SPNEGO_H_
+#define _SPNEGO_H_
+
+/*%
+ * Wrapper for GSSAPI gss_init_sec_context(), using portable SPNEGO
+ * implementation instead of the one that's part of the GSSAPI
+ * library.  Takes arguments identical to the standard GSSAPI
+ * function, uses standard gss_init_sec_context() to handle
+ * everything inside the SPNEGO wrapper.
+ */
+OM_uint32
+gss_init_sec_context_spnego(OM_uint32 *,
+			    const gss_cred_id_t,
+			    gss_ctx_id_t *,
+			    const gss_name_t,
+			    const gss_OID,
+			    OM_uint32,
+			    OM_uint32,
+			    const gss_channel_bindings_t,
+			    const gss_buffer_t,
+			    gss_OID *,
+			    gss_buffer_t,
+			    OM_uint32 *,
+			    OM_uint32 *);
+
+/*%
+ * Wrapper for GSSAPI gss_accept_sec_context(), using portable SPNEGO
+ * implementation instead of the one that's part of the GSSAPI
+ * library.  Takes arguments identical to the standard GSSAPI
+ * function.  Checks the OID of the input token to see if it's SPNEGO;
+ * if so, processes it, otherwise hands the call off to the standard
+ * gss_accept_sec_context() function.
+ */
+OM_uint32 gss_accept_sec_context_spnego(OM_uint32 *,
+					gss_ctx_id_t *,
+					const gss_cred_id_t,
+					const gss_buffer_t,
+					const gss_channel_bindings_t,
+					gss_name_t *,
+					gss_OID *,
+					gss_buffer_t,
+					OM_uint32 *,
+					OM_uint32 *,
+					gss_cred_id_t *);
+
+
+#endif
diff --git a/contrib/bind9/lib/dns/spnego_asn1.c b/contrib/bind9/lib/dns/spnego_asn1.c
new file mode 100644
index 0000000..75c2304
--- /dev/null
+++ b/contrib/bind9/lib/dns/spnego_asn1.c
@@ -0,0 +1,885 @@
+/*
+ * Copyright (C) 2006, 2007  Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or 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: spnego_asn1.c,v 1.4 2007/06/19 23:47:16 tbox Exp $ */
+
+/*! \file
+ * \brief Method routines generated from SPNEGO ASN.1 module.
+ * See spnego_asn1.pl for details.  Do not edit.
+ */
+
+/* Generated from spnego.asn1 */
+/* Do not edit */
+
+#ifndef __asn1_h__
+#define __asn1_h__
+
+
+#ifndef __asn1_common_definitions__
+#define __asn1_common_definitions__
+
+typedef struct octet_string {
+	size_t length;
+	void *data;
+} octet_string;
+
+typedef char *general_string;
+
+typedef char *utf8_string;
+
+typedef struct oid {
+	size_t length;
+	unsigned *components;
+} oid;
+
+#define ASN1_MALLOC_ENCODE(T, B, BL, S, L, R)                  \
+  do {                                                         \
+    (BL) = length_##T((S));                                    \
+    (B) = malloc((BL));                                        \
+    if((B) == NULL) {                                          \
+      (R) = ENOMEM;                                            \
+    } else {                                                   \
+      (R) = encode_##T(((unsigned char*)(B)) + (BL) - 1, (BL), \
+                       (S), (L));                              \
+      if((R) != 0) {                                           \
+        free((B));                                             \
+        (B) = NULL;                                            \
+      }                                                        \
+    }                                                          \
+  } while (0)
+
+#endif
+
+/*
+ * MechType ::= OBJECT IDENTIFIER
+ */
+
+typedef oid MechType;
+
+static int encode_MechType(unsigned char *, size_t, const MechType *, size_t *);
+static int decode_MechType(const unsigned char *, size_t, MechType *, size_t *);
+static void free_MechType(MechType *);
+/* unused declaration: length_MechType */
+/* unused declaration: copy_MechType */
+
+
+/*
+ * MechTypeList ::= SEQUENCE OF MechType
+ */
+
+typedef struct MechTypeList {
+	unsigned int len;
+	MechType *val;
+} MechTypeList;
+
+static int encode_MechTypeList(unsigned char *, size_t, const MechTypeList *, size_t *);
+static int decode_MechTypeList(const unsigned char *, size_t, MechTypeList *, size_t *);
+static void free_MechTypeList(MechTypeList *);
+/* unused declaration: length_MechTypeList */
+/* unused declaration: copy_MechTypeList */
+
+
+/*
+ * ContextFlags ::= BIT STRING { delegFlag(0), mutualFlag(1), replayFlag(2),
+ * sequenceFlag(3), anonFlag(4), confFlag(5), integFlag(6) }
+ */
+
+typedef struct ContextFlags {
+	unsigned int delegFlag:1;
+	unsigned int mutualFlag:1;
+	unsigned int replayFlag:1;
+	unsigned int sequenceFlag:1;
+	unsigned int anonFlag:1;
+	unsigned int confFlag:1;
+	unsigned int integFlag:1;
+} ContextFlags;
+
+
+static int encode_ContextFlags(unsigned char *, size_t, const ContextFlags *, size_t *);
+static int decode_ContextFlags(const unsigned char *, size_t, ContextFlags *, size_t *);
+static void free_ContextFlags(ContextFlags *);
+/* unused declaration: length_ContextFlags */
+/* unused declaration: copy_ContextFlags */
+/* unused declaration: ContextFlags2int */
+/* unused declaration: int2ContextFlags */
+/* unused declaration: asn1_ContextFlags_units */
+
+/*
+ * NegTokenInit ::= SEQUENCE { mechTypes[0]    MechTypeList, reqFlags[1]
+ * ContextFlags OPTIONAL, mechToken[2]    OCTET STRING OPTIONAL,
+ * mechListMIC[3]  OCTET STRING OPTIONAL }
+ */
+
+typedef struct NegTokenInit {
+	MechTypeList mechTypes;
+	ContextFlags *reqFlags;
+	octet_string *mechToken;
+	octet_string *mechListMIC;
+} NegTokenInit;
+
+static int encode_NegTokenInit(unsigned char *, size_t, const NegTokenInit *, size_t *);
+static int decode_NegTokenInit(const unsigned char *, size_t, NegTokenInit *, size_t *);
+static void free_NegTokenInit(NegTokenInit *);
+/* unused declaration: length_NegTokenInit */
+/* unused declaration: copy_NegTokenInit */
+
+
+/*
+ * NegTokenResp ::= SEQUENCE { negState[0]       ENUMERATED {
+ * accept-completed(0), accept-incomplete(1), reject(2), request-mic(3) }
+ * OPTIONAL, supportedMech[1]  MechType OPTIONAL, responseToken[2]  OCTET
+ * STRING OPTIONAL, mechListMIC[3]    OCTET STRING OPTIONAL }
+ */
+
+typedef struct NegTokenResp {
+	enum {
+		accept_completed = 0,
+		accept_incomplete = 1,
+		reject = 2,
+		request_mic = 3
+	} *negState;
+
+	MechType *supportedMech;
+	octet_string *responseToken;
+	octet_string *mechListMIC;
+} NegTokenResp;
+
+static int encode_NegTokenResp(unsigned char *, size_t, const NegTokenResp *, size_t *);
+static int decode_NegTokenResp(const unsigned char *, size_t, NegTokenResp *, size_t *);
+static void free_NegTokenResp(NegTokenResp *);
+/* unused declaration: length_NegTokenResp */
+/* unused declaration: copy_NegTokenResp */
+
+
+
+
+#endif				/* __asn1_h__ */
+/* Generated from spnego.asn1 */
+/* Do not edit */
+
+
+#define BACK if (e) return e; p -= l; len -= l; ret += l
+
+static int
+encode_MechType(unsigned char *p, size_t len, const MechType * data, size_t * size)
+{
+	size_t ret = 0;
+	size_t l;
+	int i, e;
+
+	i = 0;
+	e = encode_oid(p, len, data, &l);
+	BACK;
+	*size = ret;
+	return 0;
+}
+
+#define FORW if(e) goto fail; p += l; len -= l; ret += l
+
+static int
+decode_MechType(const unsigned char *p, size_t len, MechType * data, size_t * size)
+{
+	size_t ret = 0, reallen;
+	size_t l;
+	int e;
+
+	memset(data, 0, sizeof(*data));
+	reallen = 0;
+	e = decode_oid(p, len, data, &l);
+	FORW;
+	if (size)
+		*size = ret;
+	return 0;
+fail:
+	free_MechType(data);
+	return e;
+}
+
+static void
+free_MechType(MechType * data)
+{
+	free_oid(data);
+}
+
+/* unused function: length_MechType */
+
+
+/* unused function: copy_MechType */
+
+/* Generated from spnego.asn1 */
+/* Do not edit */
+
+
+#define BACK if (e) return e; p -= l; len -= l; ret += l
+
+static int
+encode_MechTypeList(unsigned char *p, size_t len, const MechTypeList * data, size_t * size)
+{
+	size_t ret = 0;
+	size_t l;
+	int i, e;
+
+	i = 0;
+	for (i = (data)->len - 1; i >= 0; --i) {
+		int oldret = ret;
+		ret = 0;
+		e = encode_MechType(p, len, &(data)->val[i], &l);
+		BACK;
+		ret += oldret;
+	}
+	e = der_put_length_and_tag(p, len, ret, ASN1_C_UNIV, CONS, UT_Sequence, &l);
+	BACK;
+	*size = ret;
+	return 0;
+}
+
+#define FORW if(e) goto fail; p += l; len -= l; ret += l
+
+static int
+decode_MechTypeList(const unsigned char *p, size_t len, MechTypeList * data, size_t * size)
+{
+	size_t ret = 0, reallen;
+	size_t l;
+	int e;
+
+	memset(data, 0, sizeof(*data));
+	reallen = 0;
+	e = der_match_tag_and_length(p, len, ASN1_C_UNIV, CONS, UT_Sequence, &reallen, &l);
+	FORW;
+	if (len < reallen)
+		return ASN1_OVERRUN;
+	len = reallen;
+	{
+		size_t origlen = len;
+		int oldret = ret;
+		ret = 0;
+		(data)->len = 0;
+		(data)->val = NULL;
+		while (ret < origlen) {
+			(data)->len++;
+			(data)->val = realloc((data)->val, sizeof(*((data)->val)) * (data)->len);
+			e = decode_MechType(p, len, &(data)->val[(data)->len - 1], &l);
+			FORW;
+			len = origlen - ret;
+		}
+		ret += oldret;
+	}
+	if (size)
+		*size = ret;
+	return 0;
+fail:
+	free_MechTypeList(data);
+	return e;
+}
+
+static void
+free_MechTypeList(MechTypeList * data)
+{
+	while ((data)->len) {
+		free_MechType(&(data)->val[(data)->len - 1]);
+		(data)->len--;
+	}
+	free((data)->val);
+	(data)->val = NULL;
+}
+
+/* unused function: length_MechTypeList */
+
+
+/* unused function: copy_MechTypeList */
+
+/* Generated from spnego.asn1 */
+/* Do not edit */
+
+
+#define BACK if (e) return e; p -= l; len -= l; ret += l
+
+static int
+encode_ContextFlags(unsigned char *p, size_t len, const ContextFlags * data, size_t * size)
+{
+	size_t ret = 0;
+	size_t l;
+	int i, e;
+
+	i = 0;
+	{
+		unsigned char c = 0;
+		*p-- = c;
+		len--;
+		ret++;
+		c = 0;
+		*p-- = c;
+		len--;
+		ret++;
+		c = 0;
+		*p-- = c;
+		len--;
+		ret++;
+		c = 0;
+		if (data->integFlag)
+			c |= 1 << 1;
+		if (data->confFlag)
+			c |= 1 << 2;
+		if (data->anonFlag)
+			c |= 1 << 3;
+		if (data->sequenceFlag)
+			c |= 1 << 4;
+		if (data->replayFlag)
+			c |= 1 << 5;
+		if (data->mutualFlag)
+			c |= 1 << 6;
+		if (data->delegFlag)
+			c |= 1 << 7;
+		*p-- = c;
+		*p-- = 0;
+		len -= 2;
+		ret += 2;
+	}
+
+	e = der_put_length_and_tag(p, len, ret, ASN1_C_UNIV, PRIM, UT_BitString, &l);
+	BACK;
+	*size = ret;
+	return 0;
+}
+
+#define FORW if(e) goto fail; p += l; len -= l; ret += l
+
+static int
+decode_ContextFlags(const unsigned char *p, size_t len, ContextFlags * data, size_t * size)
+{
+	size_t ret = 0, reallen;
+	size_t l;
+	int e;
+
+	memset(data, 0, sizeof(*data));
+	reallen = 0;
+	e = der_match_tag_and_length(p, len, ASN1_C_UNIV, PRIM, UT_BitString, &reallen, &l);
+	FORW;
+	if (len < reallen)
+		return ASN1_OVERRUN;
+	p++;
+	len--;
+	reallen--;
+	ret++;
+	data->delegFlag = (*p >> 7) & 1;
+	data->mutualFlag = (*p >> 6) & 1;
+	data->replayFlag = (*p >> 5) & 1;
+	data->sequenceFlag = (*p >> 4) & 1;
+	data->anonFlag = (*p >> 3) & 1;
+	data->confFlag = (*p >> 2) & 1;
+	data->integFlag = (*p >> 1) & 1;
+	p += reallen;
+	len -= reallen;
+	ret += reallen;
+	if (size)
+		*size = ret;
+	return 0;
+fail:
+	free_ContextFlags(data);
+	return e;
+}
+
+static void
+free_ContextFlags(ContextFlags * data)
+{
+	(void)data;
+}
+
+/* unused function: length_ContextFlags */
+
+
+/* unused function: copy_ContextFlags */
+
+
+/* unused function: ContextFlags2int */
+
+
+/* unused function: int2ContextFlags */
+
+
+/* unused variable: ContextFlags_units */
+
+/* unused function: asn1_ContextFlags_units */
+
+/* Generated from spnego.asn1 */
+/* Do not edit */
+
+
+#define BACK if (e) return e; p -= l; len -= l; ret += l
+
+static int
+encode_NegTokenInit(unsigned char *p, size_t len, const NegTokenInit * data, size_t * size)
+{
+	size_t ret = 0;
+	size_t l;
+	int i, e;
+
+	i = 0;
+	if ((data)->mechListMIC) {
+		int oldret = ret;
+		ret = 0;
+		e = encode_octet_string(p, len, (data)->mechListMIC, &l);
+		BACK;
+		e = der_put_length_and_tag(p, len, ret, ASN1_C_CONTEXT, CONS, 3, &l);
+		BACK;
+		ret += oldret;
+	}
+	if ((data)->mechToken) {
+		int oldret = ret;
+		ret = 0;
+		e = encode_octet_string(p, len, (data)->mechToken, &l);
+		BACK;
+		e = der_put_length_and_tag(p, len, ret, ASN1_C_CONTEXT, CONS, 2, &l);
+		BACK;
+		ret += oldret;
+	}
+	if ((data)->reqFlags) {
+		int oldret = ret;
+		ret = 0;
+		e = encode_ContextFlags(p, len, (data)->reqFlags, &l);
+		BACK;
+		e = der_put_length_and_tag(p, len, ret, ASN1_C_CONTEXT, CONS, 1, &l);
+		BACK;
+		ret += oldret;
+	} {
+		int oldret = ret;
+		ret = 0;
+		e = encode_MechTypeList(p, len, &(data)->mechTypes, &l);
+		BACK;
+		e = der_put_length_and_tag(p, len, ret, ASN1_C_CONTEXT, CONS, 0, &l);
+		BACK;
+		ret += oldret;
+	}
+	e = der_put_length_and_tag(p, len, ret, ASN1_C_UNIV, CONS, UT_Sequence, &l);
+	BACK;
+	*size = ret;
+	return 0;
+}
+
+#define FORW if(e) goto fail; p += l; len -= l; ret += l
+
+static int
+decode_NegTokenInit(const unsigned char *p, size_t len, NegTokenInit * data, size_t * size)
+{
+	size_t ret = 0, reallen;
+	size_t l;
+	int e;
+
+	memset(data, 0, sizeof(*data));
+	reallen = 0;
+	e = der_match_tag_and_length(p, len, ASN1_C_UNIV, CONS, UT_Sequence, &reallen, &l);
+	FORW;
+	{
+		int dce_fix;
+		if ((dce_fix = fix_dce(reallen, &len)) < 0)
+			return ASN1_BAD_FORMAT;
+		{
+			size_t newlen, oldlen;
+
+			e = der_match_tag(p, len, ASN1_C_CONTEXT, CONS, 0, &l);
+			if (e)
+				return e;
+			else {
+				p += l;
+				len -= l;
+				ret += l;
+				e = der_get_length(p, len, &newlen, &l);
+				FORW;
+				{
+					int dce_fix;
+					oldlen = len;
+					if ((dce_fix = fix_dce(newlen, &len)) < 0)
+						return ASN1_BAD_FORMAT;
+					e = decode_MechTypeList(p, len, &(data)->mechTypes, &l);
+					FORW;
+					if (dce_fix) {
+						e = der_match_tag_and_length(p, len, (Der_class) 0, (Der_type) 0, 0, &reallen, &l);
+						FORW;
+					} else
+						len = oldlen - newlen;
+				}
+			}
+		}
+		{
+			size_t newlen, oldlen;
+
+			e = der_match_tag(p, len, ASN1_C_CONTEXT, CONS, 1, &l);
+			if (e)
+				(data)->reqFlags = NULL;
+			else {
+				p += l;
+				len -= l;
+				ret += l;
+				e = der_get_length(p, len, &newlen, &l);
+				FORW;
+				{
+					int dce_fix;
+					oldlen = len;
+					if ((dce_fix = fix_dce(newlen, &len)) < 0)
+						return ASN1_BAD_FORMAT;
+					(data)->reqFlags = malloc(sizeof(*(data)->reqFlags));
+					if ((data)->reqFlags == NULL)
+						return ENOMEM;
+					e = decode_ContextFlags(p, len, (data)->reqFlags, &l);
+					FORW;
+					if (dce_fix) {
+						e = der_match_tag_and_length(p, len, (Der_class) 0, (Der_type) 0, 0, &reallen, &l);
+						FORW;
+					} else
+						len = oldlen - newlen;
+				}
+			}
+		}
+		{
+			size_t newlen, oldlen;
+
+			e = der_match_tag(p, len, ASN1_C_CONTEXT, CONS, 2, &l);
+			if (e)
+				(data)->mechToken = NULL;
+			else {
+				p += l;
+				len -= l;
+				ret += l;
+				e = der_get_length(p, len, &newlen, &l);
+				FORW;
+				{
+					int dce_fix;
+					oldlen = len;
+					if ((dce_fix = fix_dce(newlen, &len)) < 0)
+						return ASN1_BAD_FORMAT;
+					(data)->mechToken = malloc(sizeof(*(data)->mechToken));
+					if ((data)->mechToken == NULL)
+						return ENOMEM;
+					e = decode_octet_string(p, len, (data)->mechToken, &l);
+					FORW;
+					if (dce_fix) {
+						e = der_match_tag_and_length(p, len, (Der_class) 0, (Der_type) 0, 0, &reallen, &l);
+						FORW;
+					} else
+						len = oldlen - newlen;
+				}
+			}
+		}
+		{
+			size_t newlen, oldlen;
+
+			e = der_match_tag(p, len, ASN1_C_CONTEXT, CONS, 3, &l);
+			if (e)
+				(data)->mechListMIC = NULL;
+			else {
+				p += l;
+				len -= l;
+				ret += l;
+				e = der_get_length(p, len, &newlen, &l);
+				FORW;
+				{
+					int dce_fix;
+					oldlen = len;
+					if ((dce_fix = fix_dce(newlen, &len)) < 0)
+						return ASN1_BAD_FORMAT;
+					(data)->mechListMIC = malloc(sizeof(*(data)->mechListMIC));
+					if ((data)->mechListMIC == NULL)
+						return ENOMEM;
+					e = decode_octet_string(p, len, (data)->mechListMIC, &l);
+					FORW;
+					if (dce_fix) {
+						e = der_match_tag_and_length(p, len, (Der_class) 0, (Der_type) 0, 0, &reallen, &l);
+						FORW;
+					} else
+						len = oldlen - newlen;
+				}
+			}
+		}
+		if (dce_fix) {
+			e = der_match_tag_and_length(p, len, (Der_class) 0, (Der_type) 0, 0, &reallen, &l);
+			FORW;
+		}
+	}
+	if (size)
+		*size = ret;
+	return 0;
+fail:
+	free_NegTokenInit(data);
+	return e;
+}
+
+static void
+free_NegTokenInit(NegTokenInit * data)
+{
+	free_MechTypeList(&(data)->mechTypes);
+	if ((data)->reqFlags) {
+		free_ContextFlags((data)->reqFlags);
+		free((data)->reqFlags);
+		(data)->reqFlags = NULL;
+	}
+	if ((data)->mechToken) {
+		free_octet_string((data)->mechToken);
+		free((data)->mechToken);
+		(data)->mechToken = NULL;
+	}
+	if ((data)->mechListMIC) {
+		free_octet_string((data)->mechListMIC);
+		free((data)->mechListMIC);
+		(data)->mechListMIC = NULL;
+	}
+}
+
+/* unused function: length_NegTokenInit */
+
+
+/* unused function: copy_NegTokenInit */
+
+/* Generated from spnego.asn1 */
+/* Do not edit */
+
+
+#define BACK if (e) return e; p -= l; len -= l; ret += l
+
+static int
+encode_NegTokenResp(unsigned char *p, size_t len, const NegTokenResp * data, size_t * size)
+{
+	size_t ret = 0;
+	size_t l;
+	int i, e;
+
+	i = 0;
+	if ((data)->mechListMIC) {
+		int oldret = ret;
+		ret = 0;
+		e = encode_octet_string(p, len, (data)->mechListMIC, &l);
+		BACK;
+		e = der_put_length_and_tag(p, len, ret, ASN1_C_CONTEXT, CONS, 3, &l);
+		BACK;
+		ret += oldret;
+	}
+	if ((data)->responseToken) {
+		int oldret = ret;
+		ret = 0;
+		e = encode_octet_string(p, len, (data)->responseToken, &l);
+		BACK;
+		e = der_put_length_and_tag(p, len, ret, ASN1_C_CONTEXT, CONS, 2, &l);
+		BACK;
+		ret += oldret;
+	}
+	if ((data)->supportedMech) {
+		int oldret = ret;
+		ret = 0;
+		e = encode_MechType(p, len, (data)->supportedMech, &l);
+		BACK;
+		e = der_put_length_and_tag(p, len, ret, ASN1_C_CONTEXT, CONS, 1, &l);
+		BACK;
+		ret += oldret;
+	}
+	if ((data)->negState) {
+		int oldret = ret;
+		ret = 0;
+		e = encode_enumerated(p, len, (data)->negState, &l);
+		BACK;
+		e = der_put_length_and_tag(p, len, ret, ASN1_C_CONTEXT, CONS, 0, &l);
+		BACK;
+		ret += oldret;
+	}
+	e = der_put_length_and_tag(p, len, ret, ASN1_C_UNIV, CONS, UT_Sequence, &l);
+	BACK;
+	*size = ret;
+	return 0;
+}
+
+#define FORW if(e) goto fail; p += l; len -= l; ret += l
+
+static int
+decode_NegTokenResp(const unsigned char *p, size_t len, NegTokenResp * data, size_t * size)
+{
+	size_t ret = 0, reallen;
+	size_t l;
+	int e;
+
+	memset(data, 0, sizeof(*data));
+	reallen = 0;
+	e = der_match_tag_and_length(p, len, ASN1_C_UNIV, CONS, UT_Sequence, &reallen, &l);
+	FORW;
+	{
+		int dce_fix;
+		if ((dce_fix = fix_dce(reallen, &len)) < 0)
+			return ASN1_BAD_FORMAT;
+		{
+			size_t newlen, oldlen;
+
+			e = der_match_tag(p, len, ASN1_C_CONTEXT, CONS, 0, &l);
+			if (e)
+				(data)->negState = NULL;
+			else {
+				p += l;
+				len -= l;
+				ret += l;
+				e = der_get_length(p, len, &newlen, &l);
+				FORW;
+				{
+					int dce_fix;
+					oldlen = len;
+					if ((dce_fix = fix_dce(newlen, &len)) < 0)
+						return ASN1_BAD_FORMAT;
+					(data)->negState = malloc(sizeof(*(data)->negState));
+					if ((data)->negState == NULL)
+						return ENOMEM;
+					e = decode_enumerated(p, len, (data)->negState, &l);
+					FORW;
+					if (dce_fix) {
+						e = der_match_tag_and_length(p, len, (Der_class) 0, (Der_type) 0, 0, &reallen, &l);
+						FORW;
+					} else
+						len = oldlen - newlen;
+				}
+			}
+		}
+		{
+			size_t newlen, oldlen;
+
+			e = der_match_tag(p, len, ASN1_C_CONTEXT, CONS, 1, &l);
+			if (e)
+				(data)->supportedMech = NULL;
+			else {
+				p += l;
+				len -= l;
+				ret += l;
+				e = der_get_length(p, len, &newlen, &l);
+				FORW;
+				{
+					int dce_fix;
+					oldlen = len;
+					if ((dce_fix = fix_dce(newlen, &len)) < 0)
+						return ASN1_BAD_FORMAT;
+					(data)->supportedMech = malloc(sizeof(*(data)->supportedMech));
+					if ((data)->supportedMech == NULL)
+						return ENOMEM;
+					e = decode_MechType(p, len, (data)->supportedMech, &l);
+					FORW;
+					if (dce_fix) {
+						e = der_match_tag_and_length(p, len, (Der_class) 0, (Der_type) 0, 0, &reallen, &l);
+						FORW;
+					} else
+						len = oldlen - newlen;
+				}
+			}
+		}
+		{
+			size_t newlen, oldlen;
+
+			e = der_match_tag(p, len, ASN1_C_CONTEXT, CONS, 2, &l);
+			if (e)
+				(data)->responseToken = NULL;
+			else {
+				p += l;
+				len -= l;
+				ret += l;
+				e = der_get_length(p, len, &newlen, &l);
+				FORW;
+				{
+					int dce_fix;
+					oldlen = len;
+					if ((dce_fix = fix_dce(newlen, &len)) < 0)
+						return ASN1_BAD_FORMAT;
+					(data)->responseToken = malloc(sizeof(*(data)->responseToken));
+					if ((data)->responseToken == NULL)
+						return ENOMEM;
+					e = decode_octet_string(p, len, (data)->responseToken, &l);
+					FORW;
+					if (dce_fix) {
+						e = der_match_tag_and_length(p, len, (Der_class) 0, (Der_type) 0, 0, &reallen, &l);
+						FORW;
+					} else
+						len = oldlen - newlen;
+				}
+			}
+		}
+		{
+			size_t newlen, oldlen;
+
+			e = der_match_tag(p, len, ASN1_C_CONTEXT, CONS, 3, &l);
+			if (e)
+				(data)->mechListMIC = NULL;
+			else {
+				p += l;
+				len -= l;
+				ret += l;
+				e = der_get_length(p, len, &newlen, &l);
+				FORW;
+				{
+					int dce_fix;
+					oldlen = len;
+					if ((dce_fix = fix_dce(newlen, &len)) < 0)
+						return ASN1_BAD_FORMAT;
+					(data)->mechListMIC = malloc(sizeof(*(data)->mechListMIC));
+					if ((data)->mechListMIC == NULL)
+						return ENOMEM;
+					e = decode_octet_string(p, len, (data)->mechListMIC, &l);
+					FORW;
+					if (dce_fix) {
+						e = der_match_tag_and_length(p, len, (Der_class) 0, (Der_type) 0, 0, &reallen, &l);
+						FORW;
+					} else
+						len = oldlen - newlen;
+				}
+			}
+		}
+		if (dce_fix) {
+			e = der_match_tag_and_length(p, len, (Der_class) 0, (Der_type) 0, 0, &reallen, &l);
+			FORW;
+		}
+	}
+	if (size)
+		*size = ret;
+	return 0;
+fail:
+	free_NegTokenResp(data);
+	return e;
+}
+
+static void
+free_NegTokenResp(NegTokenResp * data)
+{
+	if ((data)->negState) {
+		free((data)->negState);
+		(data)->negState = NULL;
+	}
+	if ((data)->supportedMech) {
+		free_MechType((data)->supportedMech);
+		free((data)->supportedMech);
+		(data)->supportedMech = NULL;
+	}
+	if ((data)->responseToken) {
+		free_octet_string((data)->responseToken);
+		free((data)->responseToken);
+		(data)->responseToken = NULL;
+	}
+	if ((data)->mechListMIC) {
+		free_octet_string((data)->mechListMIC);
+		free((data)->mechListMIC);
+		(data)->mechListMIC = NULL;
+	}
+}
+
+/* unused function: length_NegTokenResp */
+
+
+/* unused function: copy_NegTokenResp */
+
+/* Generated from spnego.asn1 */
+/* Do not edit */
+
+
+/* CHOICE */
+/* unused variable: asn1_NegotiationToken_dummy_holder */
diff --git a/contrib/bind9/lib/dns/spnego_asn1.pl b/contrib/bind9/lib/dns/spnego_asn1.pl
new file mode 100755
index 0000000..93dd676
--- /dev/null
+++ b/contrib/bind9/lib/dns/spnego_asn1.pl
@@ -0,0 +1,200 @@
+#!/bin/bin/perl -w
+#
+# Copyright (C) 2006, 2007  Internet Systems Consortium, Inc. ("ISC")
+#
+# Permission to use, copy, modify, and/or 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: spnego_asn1.pl,v 1.4 2007/06/19 23:47:16 tbox Exp $
+
+# Our SPNEGO implementation uses some functions generated by the
+# Heimdal ASN.1 compiler, which this script then whacks a bit to make
+# them work properly in this stripped down implementation.  We don't
+# want to require our users to have a copy of the compiler, so we ship
+# the output of this script, but we need to keep the script around in
+# any case to cope with future changes to the SPNEGO ASN.1 code, so we
+# might as well supply the script for users who want it.
+
+# Overall plan: run the ASN.1 compiler, run each of its output files
+# through indent, fix up symbols and whack everything to be static.
+# We use indent for two reasons: (1) to whack the Heimdal compiler's
+# output into something closer to ISC's coding standard, and (2) to
+# make it easier for this script to parse the result.
+
+# Output from this script is C code which we expect to be #included
+# into another C file, which is why everything generated by this
+# script is marked "static".  The intent is to minimize the number of
+# extern symbols exported by the SPNEGO implementation, to avoid
+# potential conflicts with the GSSAPI libraries.
+
+###
+
+# Filename of the ASN.1 specification.  Hardcoded for the moment
+# since this script is intended for compiling exactly one module.
+
+my $asn1_source = $ENV{ASN1_SOURCE} || "spnego.asn1";
+
+# Heimdal ASN.1 compiler.  This script was written using the version
+# from Heimdal 0.7.1.  To build this, download a copy of
+# heimdal-0.7.1.tar.gz, configure and build with the default options,
+# then look for the compiler in heimdal-0.7.1/lib/asn1/asn1_compile.
+
+my $asn1_compile = $ENV{ASN1_COMPILE} || "asn1_compile";
+
+# BSD indent program.  This script was written using the version of
+# indent that comes with FreeBSD 4.11-STABLE.  The GNU project, as
+# usual, couldn't resist the temptation to monkey with indent's
+# command line syntax, so this probably won't work with GNU indent.
+
+my $indent = $ENV{INDENT} || "indent";
+
+###
+
+# Step 1: run the compiler.  Input is the ASN.1 file.  Outputs are a
+# header file (name specified on command line without the .h suffix),
+# a file called "asn1_files" listing the names of the other output
+# files, and a set of files containing C code generated by the
+# compiler for each data type that the compiler found.
+
+if (! -r $asn1_source || system($asn1_compile, $asn1_source, "asn1")) {
+    die("Couldn't compile ASN.1 source file $asn1_source\n");
+}
+
+my @files = ("asn1.h");
+
+open(F, "asn1_files")
+    or die("Couldn't open asn1_files: $!\n");
+push(@files, split)
+    while (<F>);
+close(F);
+
+unlink("asn1_files");
+
+###
+
+# Step 2: generate header block.
+
+print(q~/*
+ * Copyright (C) 2006  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,
+ * 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: spnego_asn1.pl,v 1.4 2007/06/19 23:47:16 tbox Exp $ */
+
+/*! \file
+ * \brief Method routines generated from SPNEGO ASN.1 module.
+ * See spnego_asn1.pl for details.  Do not edit.
+ */
+
+~);
+
+###
+
+# Step 3: read and process each generated file, then delete it.
+
+my $output;
+
+for my $file (@files) {
+
+    my $is_static = 0;
+
+    system($indent, "-di1", "-ldi1", $file) == 0
+	or die("Couldn't indent $file");
+
+    unlink("$file.BAK");
+
+    open(F, $file)
+	or die("Couldn't open $file: $!");
+
+    while (<F>) {
+
+	# Symbol name fixups
+
+	s/heim_general_string/general_string/g;
+	s/heim_octet_string/octet_string/g;
+	s/heim_oid/oid/g;
+	s/heim_utf8_string/utf8_string/g;
+
+	# Convert all externs to statics
+
+	if (/^static/) {
+	    $is_static = 1;
+	}
+
+	if (!/^typedef/ &&
+	    !$is_static &&
+	    /^[A-Za-z_][0-9A-Za-z_]*[ \t]*($|[^:0-9A-Za-z_])/) {
+	    $_ = "static " . $_;
+	    $is_static = 1;
+	}
+
+	if (/[{};]/) {
+	    $is_static = 0;
+	}
+
+	# Suppress file inclusion, pass anything else through
+
+	if (!/#include/) {
+	    $output .= $_;
+	}
+    }
+
+    close(F);
+    unlink($file);
+}
+
+# Step 4: Delete unused stuff to avoid code bloat and compiler warnings.
+
+my @unused_functions = qw(ContextFlags2int
+			  int2ContextFlags
+			  asn1_ContextFlags_units
+			  length_NegTokenInit
+			  copy_NegTokenInit
+			  length_NegTokenResp
+			  copy_NegTokenResp
+			  length_MechTypeList
+			  length_MechType
+			  copy_MechTypeList
+			  length_ContextFlags
+			  copy_ContextFlags
+			  copy_MechType);
+
+$output =~ s<^static [^\n]+\n$_\(.+?^}></* unused function: $_ */\n>ms
+    foreach (@unused_functions);
+
+$output =~ s<^static .+$_\(.*\);$></* unused declaration: $_ */>m
+    foreach (@unused_functions);
+
+$output =~ s<^static struct units ContextFlags_units\[\].+?^};>
+            </* unused variable: ContextFlags_units */>ms;
+
+$output =~ s<^static int asn1_NegotiationToken_dummy_holder = 1;>
+            </* unused variable: asn1_NegotiationToken_dummy_holder */>ms;
+
+$output =~ s<^static void\nfree_ContextFlags\(ContextFlags \* data\)\n{\n>
+            <$&\t(void)data;\n>ms;
+
+# Step 5: Write the result.
+
+print($output);
+
diff --git a/contrib/bind9/lib/dns/ssu.c b/contrib/bind9/lib/dns/ssu.c
index fa3011c..ab69242 100644
--- a/contrib/bind9/lib/dns/ssu.c
+++ b/contrib/bind9/lib/dns/ssu.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -17,7 +17,7 @@
 
 /*! \file */
 /*
- * $Id: ssu.c,v 1.24.18.4 2006/02/16 23:51:32 marka Exp $
+ * $Id: ssu.c,v 1.34 2008/01/18 23:46:58 tbox Exp $
  * Principal Author: Brian Wellington
  */
 
@@ -25,14 +25,17 @@
 
 #include <isc/magic.h>
 #include <isc/mem.h>
+#include <isc/netaddr.h>
 #include <isc/result.h>
-#include <isc/string.h>		/* Required for HP/UX (and others?) */
+#include <isc/string.h>
 #include <isc/util.h>
 
 #include <dns/fixedname.h>
 #include <dns/name.h>
 #include <dns/ssu.h>
 
+#include <dst/gssapi.h>
+
 #define SSUTABLEMAGIC		ISC_MAGIC('S', 'S', 'U', 'T')
 #define VALID_SSUTABLE(table)	ISC_MAGIC_VALID(table, SSUTABLEMAGIC)
 
@@ -245,50 +248,178 @@ isusertype(dns_rdatatype_t type) {
 		       type != dns_rdatatype_rrsig));
 }
 
+static void
+reverse_from_address(dns_name_t *tcpself, isc_netaddr_t *tcpaddr) {
+	char buf[16 * 4 + sizeof("IP6.ARPA.")];
+	isc_result_t result;
+	unsigned char *ap;
+	isc_buffer_t b;
+	unsigned long l;
+
+	switch (tcpaddr->family) {
+	case AF_INET:
+		l = ntohl(tcpaddr->type.in.s_addr);
+		result = isc_string_printf(buf, sizeof(buf),
+					   "%lu.%lu.%lu.%lu.IN-ADDR.ARPA.",
+					   (l >> 0) & 0xff, (l >> 8) & 0xff,
+					   (l >> 16) & 0xff, (l >> 24) & 0xff);
+		RUNTIME_CHECK(result == ISC_R_SUCCESS);
+		break;
+	case AF_INET6:
+		ap = tcpaddr->type.in6.s6_addr;
+		result = isc_string_printf(buf, sizeof(buf),
+					   "%x.%x.%x.%x.%x.%x.%x.%x."
+					   "%x.%x.%x.%x.%x.%x.%x.%x."
+					   "%x.%x.%x.%x.%x.%x.%x.%x."
+					   "%x.%x.%x.%x.%x.%x.%x.%x."
+					   "IP6.ARPA.",
+					   ap[15] & 0x0f, (ap[15] >> 4) & 0x0f,
+					   ap[14] & 0x0f, (ap[14] >> 4) & 0x0f,
+					   ap[13] & 0x0f, (ap[13] >> 4) & 0x0f,
+					   ap[12] & 0x0f, (ap[12] >> 4) & 0x0f,
+					   ap[11] & 0x0f, (ap[11] >> 4) & 0x0f,
+					   ap[10] & 0x0f, (ap[10] >> 4) & 0x0f,
+					   ap[9] & 0x0f, (ap[9] >> 4) & 0x0f,
+					   ap[8] & 0x0f, (ap[8] >> 4) & 0x0f,
+					   ap[7] & 0x0f, (ap[7] >> 4) & 0x0f,
+					   ap[6] & 0x0f, (ap[6] >> 4) & 0x0f,
+					   ap[5] & 0x0f, (ap[5] >> 4) & 0x0f,
+					   ap[4] & 0x0f, (ap[4] >> 4) & 0x0f,
+					   ap[3] & 0x0f, (ap[3] >> 4) & 0x0f,
+					   ap[2] & 0x0f, (ap[2] >> 4) & 0x0f,
+					   ap[1] & 0x0f, (ap[1] >> 4) & 0x0f,
+					   ap[0] & 0x0f, (ap[0] >> 4) & 0x0f);
+		RUNTIME_CHECK(result == ISC_R_SUCCESS);
+		break;
+	default:
+		INSIST(0);
+	}
+	isc_buffer_init(&b, buf, strlen(buf));
+	isc_buffer_add(&b, strlen(buf));
+	result = dns_name_fromtext(tcpself, &b, dns_rootname, 0, NULL);
+	RUNTIME_CHECK(result == ISC_R_SUCCESS);
+}
+
+static void
+stf_from_address(dns_name_t *stfself, isc_netaddr_t *tcpaddr) {
+	char buf[sizeof("X.X.X.X.Y.Y.Y.Y.2.0.0.2.IP6.ARPA.")];
+	isc_result_t result;
+	unsigned char *ap;
+	isc_buffer_t b;
+	unsigned long l;
+
+	switch(tcpaddr->family) {
+	case AF_INET:
+		l = ntohl(tcpaddr->type.in.s_addr);
+		result = isc_string_printf(buf, sizeof(buf),
+					   "%lx.%lx.%lx.%lx.%lx.%lx.%lx.%lx"
+					   "2.0.0.2.IP6.ARPA.",
+					   l & 0xf, (l >> 4) & 0xf,
+					   (l >> 8) & 0xf, (l >> 12) & 0xf,
+					   (l >> 16) & 0xf, (l >> 20) & 0xf,
+					   (l >> 24) & 0xf, (l >> 28) & 0xf);
+		RUNTIME_CHECK(result == ISC_R_SUCCESS);
+		break;
+	case AF_INET6:
+		ap = tcpaddr->type.in6.s6_addr;
+		result = isc_string_printf(buf, sizeof(buf),
+					   "%x.%x.%x.%x.%x.%x.%x.%x."
+					   "%x.%x.%x.%x.IP6.ARPA.",
+					   ap[5] & 0x0f, (ap[5] >> 4) & 0x0f,
+					   ap[4] & 0x0f, (ap[4] >> 4) & 0x0f,
+					   ap[3] & 0x0f, (ap[3] >> 4) & 0x0f,
+					   ap[2] & 0x0f, (ap[2] >> 4) & 0x0f,
+					   ap[1] & 0x0f, (ap[1] >> 4) & 0x0f,
+					   ap[0] & 0x0f, (ap[0] >> 4) & 0x0f);
+		RUNTIME_CHECK(result == ISC_R_SUCCESS);
+		break;
+	default:
+		INSIST(0);
+	}
+	isc_buffer_init(&b, buf, strlen(buf));
+	isc_buffer_add(&b, strlen(buf));
+	result = dns_name_fromtext(stfself, &b, dns_rootname, 0, NULL);
+	RUNTIME_CHECK(result == ISC_R_SUCCESS);
+}
+
 isc_boolean_t
 dns_ssutable_checkrules(dns_ssutable_t *table, dns_name_t *signer,
-			dns_name_t *name, dns_rdatatype_t type)
+			dns_name_t *name, isc_netaddr_t *tcpaddr,
+			dns_rdatatype_t type)
 {
 	dns_ssurule_t *rule;
 	unsigned int i;
 	dns_fixedname_t fixed;
 	dns_name_t *wildcard;
+	dns_name_t *tcpself;
+	dns_name_t *stfself;
 	isc_result_t result;
 
 	REQUIRE(VALID_SSUTABLE(table));
 	REQUIRE(signer == NULL || dns_name_isabsolute(signer));
 	REQUIRE(dns_name_isabsolute(name));
 
-	if (signer == NULL)
+	if (signer == NULL && tcpaddr == NULL)
 		return (ISC_FALSE);
-	rule = ISC_LIST_HEAD(table->rules);
-		rule = ISC_LIST_NEXT(rule, link);
+
 	for (rule = ISC_LIST_HEAD(table->rules);
 	     rule != NULL;
 	     rule = ISC_LIST_NEXT(rule, link))
 	{
-		if (dns_name_iswildcard(rule->identity)) {
-			if (!dns_name_matcheswildcard(signer, rule->identity))
+		switch (rule->matchtype) {
+		case DNS_SSUMATCHTYPE_NAME:
+		case DNS_SSUMATCHTYPE_SUBDOMAIN:
+		case DNS_SSUMATCHTYPE_WILDCARD:
+		case DNS_SSUMATCHTYPE_SELF:
+		case DNS_SSUMATCHTYPE_SELFSUB:
+		case DNS_SSUMATCHTYPE_SELFWILD:
+			if (signer == NULL)
 				continue;
-		} else if (!dns_name_equal(signer, rule->identity))
+			if (dns_name_iswildcard(rule->identity)) {
+				if (!dns_name_matcheswildcard(signer,
+							      rule->identity))
+					continue;
+			} else {
+				if (!dns_name_equal(signer, rule->identity))
+					continue;
+			}
+			break;
+		case DNS_SSUMATCHTYPE_SELFKRB5:
+		case DNS_SSUMATCHTYPE_SELFMS:
+		case DNS_SSUMATCHTYPE_SUBDOMAINKRB5:
+		case DNS_SSUMATCHTYPE_SUBDOMAINMS:
+			if (signer == NULL)
 				continue;
+			break;
+		case DNS_SSUMATCHTYPE_TCPSELF:
+		case DNS_SSUMATCHTYPE_6TO4SELF:
+			if (tcpaddr == NULL)
+				continue;
+			break;
+		}
 
-		if (rule->matchtype == DNS_SSUMATCHTYPE_NAME) {
+		switch (rule->matchtype) {
+		case DNS_SSUMATCHTYPE_NAME:
 			if (!dns_name_equal(name, rule->name))
 				continue;
-		} else if (rule->matchtype == DNS_SSUMATCHTYPE_SUBDOMAIN) {
+			break;
+		case DNS_SSUMATCHTYPE_SUBDOMAIN:
 			if (!dns_name_issubdomain(name, rule->name))
 				continue;
-		} else if (rule->matchtype == DNS_SSUMATCHTYPE_WILDCARD) {
+			break;
+		case DNS_SSUMATCHTYPE_WILDCARD:
 			if (!dns_name_matcheswildcard(name, rule->name))
 				continue;
-		} else if (rule->matchtype == DNS_SSUMATCHTYPE_SELF) {
+			break;
+		case DNS_SSUMATCHTYPE_SELF:
 			if (!dns_name_equal(signer, name))
 				continue;
-		} else if (rule->matchtype == DNS_SSUMATCHTYPE_SELFSUB) {
+			break;
+		case DNS_SSUMATCHTYPE_SELFSUB:
 			if (!dns_name_issubdomain(name, signer))
 				continue;
-		} else if (rule->matchtype == DNS_SSUMATCHTYPE_SELFWILD) {
+			break;
+		case DNS_SSUMATCHTYPE_SELFWILD:
 			dns_fixedname_init(&fixed);
 			wildcard = dns_fixedname_name(&fixed);
 			result = dns_name_concatenate(dns_wildcardname, signer,
@@ -297,6 +428,61 @@ dns_ssutable_checkrules(dns_ssutable_t *table, dns_name_t *signer,
 				continue;
 			if (!dns_name_matcheswildcard(name, wildcard))
 				continue;
+			break;
+		case DNS_SSUMATCHTYPE_SELFKRB5:
+			if (!dst_gssapi_identitymatchesrealmkrb5(signer, name,
+							       rule->identity))
+				continue;
+			break;
+		case DNS_SSUMATCHTYPE_SELFMS:
+			if (!dst_gssapi_identitymatchesrealmms(signer, name,
+							       rule->identity))
+				continue;
+			break;
+		case DNS_SSUMATCHTYPE_SUBDOMAINKRB5:
+			if (!dns_name_issubdomain(name, rule->name))
+				continue;
+			if (!dst_gssapi_identitymatchesrealmkrb5(signer, NULL,
+							       rule->identity))
+				continue;
+			break;
+		case DNS_SSUMATCHTYPE_SUBDOMAINMS:
+			if (!dns_name_issubdomain(name, rule->name))
+				continue;
+			if (!dst_gssapi_identitymatchesrealmms(signer, NULL,
+							       rule->identity))
+				continue;
+			break;
+		case DNS_SSUMATCHTYPE_TCPSELF:
+			dns_fixedname_init(&fixed);
+			tcpself = dns_fixedname_name(&fixed);
+			reverse_from_address(tcpself, tcpaddr);
+			if (dns_name_iswildcard(rule->identity)) {
+				if (!dns_name_matcheswildcard(tcpself,
+							      rule->identity))
+					continue;
+			} else {
+				if (!dns_name_equal(tcpself, rule->identity))
+					continue;
+			}
+			if (!dns_name_equal(tcpself, name))
+				continue;
+			break;
+		case DNS_SSUMATCHTYPE_6TO4SELF:
+			dns_fixedname_init(&fixed);
+			stfself = dns_fixedname_name(&fixed);
+			stf_from_address(stfself, tcpaddr);
+			if (dns_name_iswildcard(rule->identity)) {
+				if (!dns_name_matcheswildcard(stfself,
+							      rule->identity))
+					continue;
+			} else {
+				if (!dns_name_equal(stfself, rule->identity))
+					continue;
+			}
+			if (!dns_name_equal(stfself, name))
+				continue;
+			break;
 		}
 
 		if (rule->ntypes == 0) {
diff --git a/contrib/bind9/lib/dns/stats.c b/contrib/bind9/lib/dns/stats.c
index 660046f..60fed35 100644
--- a/contrib/bind9/lib/dns/stats.c
+++ b/contrib/bind9/lib/dns/stats.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,16 +15,363 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: stats.c,v 1.6.18.4 2005/06/27 00:20:02 marka Exp $ */
+/* $Id: stats.c,v 1.16.118.2 2009/01/29 23:47:44 tbox Exp $ */
 
 /*! \file */
 
 #include <config.h>
 
+#include <isc/magic.h>
 #include <isc/mem.h>
+#include <isc/stats.h>
+#include <isc/util.h>
 
+#include <dns/opcode.h>
+#include <dns/rdatatype.h>
 #include <dns/stats.h>
 
+#define DNS_STATS_MAGIC			ISC_MAGIC('D', 's', 't', 't')
+#define DNS_STATS_VALID(x)		ISC_MAGIC_VALID(x, DNS_STATS_MAGIC)
+
+/*%
+ * Statistics types.
+ */
+typedef enum {
+	dns_statstype_general = 0,
+	dns_statstype_rdtype = 1,
+	dns_statstype_rdataset = 2,
+	dns_statstype_opcode = 3
+} dns_statstype_t;
+
+/*%
+ * It doesn't make sense to have 2^16 counters for all possible types since
+ * most of them won't be used.  We have counters for the first 256 types and
+ * those explicitly supported in the rdata implementation.
+ * XXXJT: this introduces tight coupling with the rdata implementation.
+ * Ideally, we should have rdata handle this type of details.
+ */
+enum {
+	/* For 0-255, we use the rdtype value as counter indices */
+	rdtypecounter_dlv = 256,	/* for dns_rdatatype_dlv */
+	rdtypecounter_others = 257,	/* anything else */
+	rdtypecounter_max = 258,
+	/* The following are used for rdataset */
+	rdtypenxcounter_max = rdtypecounter_max * 2,
+	rdtypecounter_nxdomain = rdtypenxcounter_max,
+	rdatasettypecounter_max = rdtypecounter_nxdomain + 1
+};
+
+struct dns_stats {
+	/*% Unlocked */
+	unsigned int	magic;
+	dns_statstype_t	type;
+	isc_mem_t	*mctx;
+	isc_mutex_t	lock;
+	isc_stats_t	*counters;
+
+	/*%  Locked by lock */
+	unsigned int	references;
+};
+
+typedef struct rdatadumparg {
+	dns_rdatatypestats_dumper_t	fn;
+	void				*arg;
+} rdatadumparg_t;
+
+typedef struct opcodedumparg {
+	dns_opcodestats_dumper_t	fn;
+	void				*arg;
+} opcodedumparg_t;
+
+void
+dns_stats_attach(dns_stats_t *stats, dns_stats_t **statsp) {
+	REQUIRE(DNS_STATS_VALID(stats));
+	REQUIRE(statsp != NULL && *statsp == NULL);
+
+	LOCK(&stats->lock);
+	stats->references++;
+	UNLOCK(&stats->lock);
+
+	*statsp = stats;
+}
+
+void
+dns_stats_detach(dns_stats_t **statsp) {
+	dns_stats_t *stats;
+
+	REQUIRE(statsp != NULL && DNS_STATS_VALID(*statsp));
+
+	stats = *statsp;
+	*statsp = NULL;
+
+	LOCK(&stats->lock);
+	stats->references--;
+	UNLOCK(&stats->lock);
+
+	if (stats->references == 0) {
+		isc_stats_detach(&stats->counters);
+		DESTROYLOCK(&stats->lock);
+		isc_mem_putanddetach(&stats->mctx, stats, sizeof(*stats));
+	}
+}
+
+/*%
+ * Create methods
+ */
+static isc_result_t
+create_stats(isc_mem_t *mctx, dns_statstype_t	type, int ncounters,
+	     dns_stats_t **statsp)
+{
+	dns_stats_t *stats;
+	isc_result_t result;
+
+	stats = isc_mem_get(mctx, sizeof(*stats));
+	if (stats == NULL)
+		return (ISC_R_NOMEMORY);
+
+	stats->counters = NULL;
+	stats->references = 1;
+
+	result = isc_mutex_init(&stats->lock);
+	if (result != ISC_R_SUCCESS)
+		goto clean_stats;
+
+	result = isc_stats_create(mctx, &stats->counters, ncounters);
+	if (result != ISC_R_SUCCESS)
+		goto clean_mutex;
+
+	stats->magic = DNS_STATS_MAGIC;
+	stats->type = type;
+	stats->mctx = NULL;
+	isc_mem_attach(mctx, &stats->mctx);
+	*statsp = stats;
+
+	return (ISC_R_SUCCESS);
+
+  clean_mutex:
+	DESTROYLOCK(&stats->lock);
+  clean_stats:
+	isc_mem_put(mctx, stats, sizeof(*stats));
+
+	return (result);
+}
+
+isc_result_t
+dns_generalstats_create(isc_mem_t *mctx, dns_stats_t **statsp, int ncounters) {
+	REQUIRE(statsp != NULL && *statsp == NULL);
+
+	return (create_stats(mctx, dns_statstype_general, ncounters, statsp));
+}
+
+isc_result_t
+dns_rdatatypestats_create(isc_mem_t *mctx, dns_stats_t **statsp) {
+	REQUIRE(statsp != NULL && *statsp == NULL);
+
+	return (create_stats(mctx, dns_statstype_rdtype, rdtypecounter_max,
+			     statsp));
+}
+
+isc_result_t
+dns_rdatasetstats_create(isc_mem_t *mctx, dns_stats_t **statsp) {
+	REQUIRE(statsp != NULL && *statsp == NULL);
+
+	return (create_stats(mctx, dns_statstype_rdataset,
+			     (rdtypecounter_max * 2) + 1, statsp));
+}
+
+isc_result_t
+dns_opcodestats_create(isc_mem_t *mctx, dns_stats_t **statsp) {
+	REQUIRE(statsp != NULL && *statsp == NULL);
+
+	return (create_stats(mctx, dns_statstype_opcode, 16, statsp));
+}
+
+/*%
+ * Increment/Decrement methods
+ */
+void
+dns_generalstats_increment(dns_stats_t *stats, isc_statscounter_t counter) {
+	REQUIRE(DNS_STATS_VALID(stats) && stats->type == dns_statstype_general);
+
+	isc_stats_increment(stats->counters, counter);
+}
+
+void
+dns_rdatatypestats_increment(dns_stats_t *stats, dns_rdatatype_t type) {
+	int counter;
+
+	REQUIRE(DNS_STATS_VALID(stats) && stats->type == dns_statstype_rdtype);
+
+	if (type == dns_rdatatype_dlv)
+		counter = rdtypecounter_dlv;
+	else if (type > dns_rdatatype_any)
+		counter = rdtypecounter_others;
+	else
+		counter = (int)type;
+
+	isc_stats_increment(stats->counters, (isc_statscounter_t)counter);
+}
+
+static inline void
+update_rdatasetstats(dns_stats_t *stats, dns_rdatastatstype_t rrsettype,
+		     isc_boolean_t increment)
+{
+	int counter;
+	dns_rdatatype_t rdtype;
+
+	if ((DNS_RDATASTATSTYPE_ATTR(rrsettype) &
+	     DNS_RDATASTATSTYPE_ATTR_NXDOMAIN) != 0) {
+		counter = rdtypecounter_nxdomain;
+	} else {
+		rdtype = DNS_RDATASTATSTYPE_BASE(rrsettype);
+		if (rdtype == dns_rdatatype_dlv)
+			counter = (int)rdtypecounter_dlv;
+		else if (rdtype > dns_rdatatype_any)
+			counter = (int)rdtypecounter_others;
+		else
+			counter = (int)rdtype;
+
+		if ((DNS_RDATASTATSTYPE_ATTR(rrsettype) &
+		     DNS_RDATASTATSTYPE_ATTR_NXRRSET) != 0)
+			counter += rdtypecounter_max;
+	}
+
+	if (increment)
+		isc_stats_increment(stats->counters, counter);
+	else
+		isc_stats_decrement(stats->counters, counter);
+}
+
+void
+dns_rdatasetstats_increment(dns_stats_t *stats, dns_rdatastatstype_t rrsettype)
+{
+	REQUIRE(DNS_STATS_VALID(stats) &&
+		stats->type == dns_statstype_rdataset);
+
+	update_rdatasetstats(stats, rrsettype, ISC_TRUE);
+}
+
+void
+dns_rdatasetstats_decrement(dns_stats_t *stats, dns_rdatastatstype_t rrsettype)
+{
+	REQUIRE(DNS_STATS_VALID(stats) &&
+		stats->type == dns_statstype_rdataset);
+
+	update_rdatasetstats(stats, rrsettype, ISC_FALSE);
+}
+void
+dns_opcodestats_increment(dns_stats_t *stats, dns_opcode_t code) {
+	REQUIRE(DNS_STATS_VALID(stats) && stats->type == dns_statstype_opcode);
+
+	isc_stats_increment(stats->counters, (isc_statscounter_t)code);
+}
+
+/*%
+ * Dump methods
+ */
+void
+dns_generalstats_dump(dns_stats_t *stats, dns_generalstats_dumper_t dump_fn,
+		      void *arg, unsigned int options)
+{
+	REQUIRE(DNS_STATS_VALID(stats) && stats->type == dns_statstype_general);
+
+	isc_stats_dump(stats->counters, (isc_stats_dumper_t)dump_fn,
+		       arg, options);
+}
+
+static void
+dump_rdentry(int rdcounter, isc_uint64_t value, dns_rdatastatstype_t attributes,
+	     dns_rdatatypestats_dumper_t dump_fn, void * arg)
+{
+	dns_rdatatype_t rdtype = dns_rdatatype_none; /* sentinel */
+	dns_rdatastatstype_t type;
+
+	if (rdcounter == rdtypecounter_others)
+		attributes |= DNS_RDATASTATSTYPE_ATTR_OTHERTYPE;
+	else {
+		if (rdcounter == rdtypecounter_dlv)
+			rdtype = dns_rdatatype_dlv;
+		else
+			rdtype = (dns_rdatatype_t)rdcounter;
+	}
+	type = DNS_RDATASTATSTYPE_VALUE((dns_rdatastatstype_t)rdtype,
+					attributes);
+	dump_fn(type, value, arg);
+}
+
+static void
+rdatatype_dumpcb(isc_statscounter_t counter, isc_uint64_t value, void *arg) {
+	rdatadumparg_t *rdatadumparg = arg;
+
+	dump_rdentry(counter, value, 0, rdatadumparg->fn, rdatadumparg->arg);
+}
+
+void
+dns_rdatatypestats_dump(dns_stats_t *stats, dns_rdatatypestats_dumper_t dump_fn,
+			void *arg0, unsigned int options)
+{
+	rdatadumparg_t arg;
+	REQUIRE(DNS_STATS_VALID(stats) && stats->type == dns_statstype_rdtype);
+
+	arg.fn = dump_fn;
+	arg.arg = arg0;
+	isc_stats_dump(stats->counters, rdatatype_dumpcb, &arg, options);
+}
+
+static void
+rdataset_dumpcb(isc_statscounter_t counter, isc_uint64_t value, void *arg) {
+	rdatadumparg_t *rdatadumparg = arg;
+
+	if (counter < rdtypecounter_max) {
+		dump_rdentry(counter, value, 0, rdatadumparg->fn,
+			     rdatadumparg->arg);
+	} else if (counter < rdtypenxcounter_max) {
+		dump_rdentry(counter - rdtypecounter_max, value,
+			     DNS_RDATASTATSTYPE_ATTR_NXRRSET,
+			     rdatadumparg->fn, rdatadumparg->arg);
+	} else {
+		dump_rdentry(0, value, DNS_RDATASTATSTYPE_ATTR_NXDOMAIN,
+			     rdatadumparg->fn, rdatadumparg->arg);
+	}
+}
+
+void
+dns_rdatasetstats_dump(dns_stats_t *stats, dns_rdatatypestats_dumper_t dump_fn,
+		       void *arg0, unsigned int options)
+{
+	rdatadumparg_t arg;
+
+	REQUIRE(DNS_STATS_VALID(stats) &&
+		stats->type == dns_statstype_rdataset);
+
+	arg.fn = dump_fn;
+	arg.arg = arg0;
+	isc_stats_dump(stats->counters, rdataset_dumpcb, &arg, options);
+}
+
+static void
+opcode_dumpcb(isc_statscounter_t counter, isc_uint64_t value, void *arg) {
+	opcodedumparg_t *opcodearg = arg;
+
+	opcodearg->fn((dns_opcode_t)counter, value, opcodearg->arg);
+}
+
+void
+dns_opcodestats_dump(dns_stats_t *stats, dns_opcodestats_dumper_t dump_fn,
+		     void *arg0, unsigned int options)
+{
+	opcodedumparg_t arg;
+
+	REQUIRE(DNS_STATS_VALID(stats) && stats->type == dns_statstype_opcode);
+
+	arg.fn = dump_fn;
+	arg.arg = arg0;
+	isc_stats_dump(stats->counters, opcode_dumpcb, &arg, options);
+}
+
+/***
+ *** Obsolete variables and functions follow:
+ ***/
 LIBDNS_EXTERNAL_DATA const char *dns_statscounter_names[DNS_STATS_NCOUNTERS] =
 	{
 	"success",
diff --git a/contrib/bind9/lib/dns/tcpmsg.c b/contrib/bind9/lib/dns/tcpmsg.c
index 018c4ce..49add56 100644
--- a/contrib/bind9/lib/dns/tcpmsg.c
+++ b/contrib/bind9/lib/dns/tcpmsg.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: tcpmsg.c,v 1.25.18.4 2006/08/10 23:59:29 marka Exp $ */
+/* $Id: tcpmsg.c,v 1.31 2007/06/19 23:47:16 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/dns/time.c b/contrib/bind9/lib/dns/time.c
index b4e7bee..62414dd 100644
--- a/contrib/bind9/lib/dns/time.c
+++ b/contrib/bind9/lib/dns/time.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: time.c,v 1.26.18.3 2005/04/29 00:16:06 marka Exp $ */
+/* $Id: time.c,v 1.31.332.2 2009/01/18 23:47:40 tbox Exp $ */
 
 /*! \file */
 
@@ -145,7 +145,7 @@ dns_time64_fromtext(const char *source, isc_int64_t *target) {
 	RANGE(0, 60, second);		/* 60 == leap second. */
 
 	/*
-	 * Calulate seconds since epoch.
+	 * Calculate seconds since epoch.
 	 */
 	value = second + (60 * minute) + (3600 * hour) + ((day - 1) * 86400);
 	for (i = 0; i < (month - 1); i++)
diff --git a/contrib/bind9/lib/dns/timer.c b/contrib/bind9/lib/dns/timer.c
index b225722..39e4551 100644
--- a/contrib/bind9/lib/dns/timer.c
+++ b/contrib/bind9/lib/dns/timer.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: timer.c,v 1.3.18.2 2005/04/29 00:16:06 marka Exp $ */
+/* $Id: timer.c,v 1.7 2007/06/19 23:47:16 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/dns/tkey.c b/contrib/bind9/lib/dns/tkey.c
index 998ea36..9e59dfa 100644
--- a/contrib/bind9/lib/dns/tkey.c
+++ b/contrib/bind9/lib/dns/tkey.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -16,7 +16,7 @@
  */
 
 /*
- * $Id: tkey.c,v 1.76.18.7 2008/01/02 23:46:02 tbox Exp $
+ * $Id: tkey.c,v 1.90 2008/04/03 00:45:23 marka Exp $
  */
 /*! \file */
 #include <config.h>
@@ -66,6 +66,20 @@ tkey_log(const char *fmt, ...) {
 	va_end(ap);
 }
 
+static void
+_dns_tkey_dumpmessage(dns_message_t *msg) {
+	isc_buffer_t outbuf;
+	unsigned char output[4096];
+	isc_result_t result;
+
+	isc_buffer_init(&outbuf, output, sizeof(output));
+	result = dns_message_totext(msg, &dns_master_style_debug, 0,
+				    &outbuf);
+	/* XXXMLG ignore result */
+	fprintf(stderr, "%.*s\n", (int)isc_buffer_usedlength(&outbuf),
+		(char *)isc_buffer_base(&outbuf));
+}
+
 isc_result_t
 dns_tkeyctx_create(isc_mem_t *mctx, isc_entropy_t *ectx, dns_tkeyctx_t **tctxp)
 {
@@ -107,6 +121,8 @@ dns_tkeyctx_destroy(dns_tkeyctx_t **tctxp) {
 			dns_name_free(tctx->domain, mctx);
 		isc_mem_put(mctx, tctx->domain, sizeof(dns_name_t));
 	}
+	if (tctx->gsscred != NULL)
+		dst_gssapi_releasecred(&tctx->gsscred);
 	isc_entropy_detach(&tctx->ectx);
 	isc_mem_put(mctx, tctx, sizeof(dns_tkeyctx_t));
 	isc_mem_detach(&mctx);
@@ -280,8 +296,7 @@ process_dhtkey(dns_message_t *msg, dns_name_t *signer, dns_name_t *name,
 	 */
 	for (result = dns_message_firstname(msg, DNS_SECTION_ADDITIONAL);
 	     result == ISC_R_SUCCESS && !found_key;
-	     result = dns_message_nextname(msg, DNS_SECTION_ADDITIONAL))
-	{
+	     result = dns_message_nextname(msg, DNS_SECTION_ADDITIONAL)) {
 		keyname = NULL;
 		dns_message_currentname(msg, DNS_SECTION_ADDITIONAL, &keyname);
 		keyset = NULL;
@@ -292,8 +307,7 @@ process_dhtkey(dns_message_t *msg, dns_name_t *signer, dns_name_t *name,
 
 		for (result = dns_rdataset_first(keyset);
 		     result == ISC_R_SUCCESS && !found_key;
-		     result = dns_rdataset_next(keyset))
-		{
+		     result = dns_rdataset_next(keyset)) {
 			dns_rdataset_current(keyset, &keyrdata);
 			pubkey = NULL;
 			result = dns_dnssec_keyfromrdata(keyname, &keyrdata,
@@ -410,13 +424,15 @@ process_gsstkey(dns_message_t *msg, dns_name_t *signer, dns_name_t *name,
 {
 	isc_result_t result = ISC_R_SUCCESS;
 	dst_key_t *dstkey = NULL;
-	void *gssctx = NULL;
+	dns_tsigkey_t *tsigkey = NULL;
+	dns_fixedname_t principal;
 	isc_stdtime_t now;
 	isc_region_t intoken;
-	unsigned char array[1024];
-	isc_buffer_t outtoken;
+	isc_buffer_t *outtoken = NULL;
+	gss_ctx_id_t gss_ctx = NULL;
 
 	UNUSED(namelist);
+	UNUSED(signer);
 
 	if (tctx->gsscred == NULL)
 		return (ISC_R_NOPERM);
@@ -424,55 +440,95 @@ process_gsstkey(dns_message_t *msg, dns_name_t *signer, dns_name_t *name,
 	if (!dns_name_equal(&tkeyin->algorithm, DNS_TSIG_GSSAPI_NAME) &&
 	    !dns_name_equal(&tkeyin->algorithm, DNS_TSIG_GSSAPIMS_NAME)) {
 		tkeyout->error = dns_tsigerror_badalg;
+		tkey_log("process_gsstkey(): dns_tsigerror_badalg");	/* XXXSRA */
 		return (ISC_R_SUCCESS);
 	}
 
+	/*
+	 * XXXDCL need to check for key expiry per 4.1.1
+	 * XXXDCL need a way to check fully established, perhaps w/key_flags
+	 */
+
 	intoken.base = tkeyin->key;
 	intoken.length = tkeyin->keylen;
 
-	isc_buffer_init(&outtoken, array, sizeof(array));
-	RETERR(dst_gssapi_acceptctx(name, tctx->gsscred, &intoken,
-				    &outtoken, &gssctx));
+	result = dns_tsigkey_find(&tsigkey, name, &tkeyin->algorithm, ring);
+	if (result == ISC_R_SUCCESS)
+		gss_ctx = dst_key_getgssctx(tsigkey->key);
 
-	dstkey = NULL;
-	RETERR(dst_key_fromgssapi(name, gssctx, msg->mctx, &dstkey));
 
-	result = dns_tsigkey_createfromkey(name, &tkeyin->algorithm,
-					   dstkey, ISC_TRUE, signer,
-					   tkeyin->inception, tkeyin->expire,
-					   ring->mctx, ring, NULL);
-#if 1
-	if (result != ISC_R_SUCCESS)
-		goto failure;
-#else
-	if (result == ISC_R_NOTFOUND) {
-		tkeyout->error = dns_tsigerror_badalg;
+	dns_fixedname_init(&principal);
+
+	result = dst_gssapi_acceptctx(tctx->gsscred, &intoken,
+				      &outtoken, &gss_ctx,
+				      dns_fixedname_name(&principal),
+				      tctx->mctx);
+
+	if (tsigkey != NULL)
+		dns_tsigkey_detach(&tsigkey);
+
+	if (result == DNS_R_INVALIDTKEY) {
+		tkeyout->error = dns_tsigerror_badkey;
+		tkey_log("process_gsstkey(): dns_tsigerror_badkey");    /* XXXSRA */
 		return (ISC_R_SUCCESS);
-	}
-	if (result != ISC_R_SUCCESS)
+	} else if (result == ISC_R_FAILURE)
 		goto failure;
-#endif
+	ENSURE(result == DNS_R_CONTINUE || result == ISC_R_SUCCESS);
+	/*
+	 * XXXDCL Section 4.1.3: Limit GSS_S_CONTINUE_NEEDED to 10 times.
+	 */
+
+	if (tsigkey == NULL) {
+		RETERR(dst_key_fromgssapi(name, gss_ctx, msg->mctx, &dstkey));
+		RETERR(dns_tsigkey_createfromkey(name, &tkeyin->algorithm,
+						 dstkey, ISC_TRUE,
+						 dns_fixedname_name(&principal),
+						 tkeyin->inception,
+						 tkeyin->expire,
+						 ring->mctx, ring, NULL));
+	}
 
-	/* This key is good for a long time */
 	isc_stdtime_get(&now);
 	tkeyout->inception = tkeyin->inception;
 	tkeyout->expire = tkeyin->expire;
 
-	tkeyout->key = isc_mem_get(msg->mctx,
-				   isc_buffer_usedlength(&outtoken));
-	if (tkeyout->key == NULL) {
-		result = ISC_R_NOMEMORY;
-		goto failure;
+	if (outtoken) {
+		tkeyout->key = isc_mem_get(tkeyout->mctx,
+					   isc_buffer_usedlength(outtoken));
+		if (tkeyout->key == NULL) {
+			result = ISC_R_NOMEMORY;
+			goto failure;
+		}
+		tkeyout->keylen = isc_buffer_usedlength(outtoken);
+		memcpy(tkeyout->key, isc_buffer_base(outtoken),
+		       isc_buffer_usedlength(outtoken));
+		isc_buffer_free(&outtoken);
+	} else {
+		tkeyout->key = isc_mem_get(tkeyout->mctx, tkeyin->keylen);
+		if (tkeyout->key == NULL) {
+			result = ISC_R_NOMEMORY;
+			goto failure;
+		}
+		tkeyout->keylen = tkeyin->keylen;
+		memcpy(tkeyout->key, tkeyin->key, tkeyin->keylen);
 	}
-	tkeyout->keylen = isc_buffer_usedlength(&outtoken);
-	memcpy(tkeyout->key, isc_buffer_base(&outtoken), tkeyout->keylen);
+
+	tkeyout->error = dns_rcode_noerror;
+
+	tkey_log("process_gsstkey(): dns_tsigerror_noerror");   /* XXXSRA */
 
 	return (ISC_R_SUCCESS);
 
- failure:
+failure:
 	if (dstkey != NULL)
 		dst_key_free(&dstkey);
 
+	if (outtoken != NULL)
+		isc_buffer_free(&outtoken);
+
+	tkey_log("process_gsstkey(): %s",
+		isc_result_totext(result));	/* XXXSRA */
+
 	return (result);
 }
 
@@ -564,8 +620,7 @@ dns_tkey_processquery(dns_message_t *msg, dns_tkeyctx_t *tctx,
 		 */
 		if (dns_message_findname(msg, DNS_SECTION_ANSWER, qname,
 					 dns_rdatatype_tkey, 0, &name,
-					 &tkeyset) != ISC_R_SUCCESS)
-		{
+					 &tkeyset) != ISC_R_SUCCESS) {
 			result = DNS_R_FORMERR;
 			tkey_log("dns_tkey_processquery: couldn't find a TKEY "
 				 "matching the question");
@@ -632,7 +687,7 @@ dns_tkey_processquery(dns_message_t *msg, dns_tkeyctx_t *tctx,
 	if (tkeyin.mode != DNS_TKEYMODE_DELETE) {
 		dns_tsigkey_t *tsigkey = NULL;
 
-		if (tctx->domain == NULL) {
+		if (tctx->domain == NULL && tkeyin.mode != DNS_TKEYMODE_GSSAPI) {
 			tkey_log("dns_tkey_processquery: tkey-domain not set");
 			result = DNS_R_REFUSED;
 			goto failure;
@@ -674,12 +729,22 @@ dns_tkey_processquery(dns_message_t *msg, dns_tkeyctx_t *tctx,
 			if (result != ISC_R_SUCCESS)
 				goto failure;
 		}
-		result = dns_name_concatenate(keyname, tctx->domain,
-					      keyname, NULL);
-		if (result != ISC_R_SUCCESS)
-			goto failure;
+
+		if (tkeyin.mode == DNS_TKEYMODE_GSSAPI) {
+			/* Yup.  This is a hack */
+			result = dns_name_concatenate(keyname, dns_rootname,
+						      keyname, NULL);
+			if (result != ISC_R_SUCCESS)
+				goto failure;
+		} else {
+			result = dns_name_concatenate(keyname, tctx->domain,
+						      keyname, NULL);
+			if (result != ISC_R_SUCCESS)
+				goto failure;
+		}
 
 		result = dns_tsigkey_find(&tsigkey, keyname, NULL, ring);
+
 		if (result == ISC_R_SUCCESS) {
 			tkeyout.error = dns_tsigerror_badname;
 			dns_tsigkey_detach(&tsigkey);
@@ -701,6 +766,7 @@ dns_tkey_processquery(dns_message_t *msg, dns_tkeyctx_t *tctx,
 			RETERR(process_gsstkey(msg, signer, keyname, &tkeyin,
 					       tctx, &tkeyout, ring,
 					       &namelist));
+
 			break;
 		case DNS_TKEYMODE_DELETE:
 			tkeyout.error = dns_rcode_noerror;
@@ -729,9 +795,9 @@ dns_tkey_processquery(dns_message_t *msg, dns_tkeyctx_t *tctx,
 	}
 
 	if (tkeyout.key != NULL)
-		isc_mem_put(msg->mctx, tkeyout.key, tkeyout.keylen);
+		isc_mem_put(tkeyout.mctx, tkeyout.key, tkeyout.keylen);
 	if (tkeyout.other != NULL)
-		isc_mem_put(msg->mctx, tkeyout.other, tkeyout.otherlen);
+		isc_mem_put(tkeyout.mctx, tkeyout.other, tkeyout.otherlen);
 	if (result != ISC_R_SUCCESS)
 		goto failure;
 
@@ -759,7 +825,7 @@ dns_tkey_processquery(dns_message_t *msg, dns_tkeyctx_t *tctx,
 
 static isc_result_t
 buildquery(dns_message_t *msg, dns_name_t *name,
-	   dns_rdata_tkey_t *tkey)
+	   dns_rdata_tkey_t *tkey, isc_boolean_t win2k)
 {
 	dns_name_t *qname = NULL, *aname = NULL;
 	dns_rdataset_t *question = NULL, *tkeyset = NULL;
@@ -780,8 +846,9 @@ buildquery(dns_message_t *msg, dns_name_t *name,
 	dns_rdataset_makequestion(question, dns_rdataclass_any,
 				  dns_rdatatype_tkey);
 
-	RETERR(isc_buffer_allocate(msg->mctx, &dynbuf, 512));
+	RETERR(isc_buffer_allocate(msg->mctx, &dynbuf, 4096));
 	RETERR(dns_message_gettemprdata(msg, &rdata));
+
 	RETERR(dns_rdata_fromstruct(rdata, dns_rdataclass_any,
 				    dns_rdatatype_tkey, tkey, dynbuf));
 	dns_message_takebuffer(msg, &dynbuf);
@@ -808,7 +875,15 @@ buildquery(dns_message_t *msg, dns_name_t *name,
 	ISC_LIST_APPEND(aname->list, tkeyset, link);
 
 	dns_message_addname(msg, qname, DNS_SECTION_QUESTION);
-	dns_message_addname(msg, aname, DNS_SECTION_ADDITIONAL);
+
+	/*
+	 * Windows 2000 needs this in the answer section, not the additional
+	 * section where the RFC specifies.
+	 */
+	if (win2k)
+		dns_message_addname(msg, aname, DNS_SECTION_ANSWER);
+	else
+		dns_message_addname(msg, aname, DNS_SECTION_ADDITIONAL);
 
 	return (ISC_R_SUCCESS);
 
@@ -823,6 +898,7 @@ buildquery(dns_message_t *msg, dns_name_t *name,
 	}
 	if (dynbuf != NULL)
 		isc_buffer_free(&dynbuf);
+	printf("buildquery error\n");
 	return (result);
 }
 
@@ -869,7 +945,7 @@ dns_tkey_builddhquery(dns_message_t *msg, dst_key_t *key, dns_name_t *name,
 	tkey.other = NULL;
 	tkey.otherlen = 0;
 
-	RETERR(buildquery(msg, name, &tkey));
+	RETERR(buildquery(msg, name, &tkey, ISC_FALSE));
 
 	if (nonce == NULL)
 		isc_mem_put(msg->mctx, r.base, 0);
@@ -900,23 +976,25 @@ dns_tkey_builddhquery(dns_message_t *msg, dst_key_t *key, dns_name_t *name,
 }
 
 isc_result_t
-dns_tkey_buildgssquery(dns_message_t *msg, dns_name_t *name,
-		       dns_name_t *gname, void *cred,
-		       isc_uint32_t lifetime, void **context)
+dns_tkey_buildgssquery(dns_message_t *msg, dns_name_t *name, dns_name_t *gname,
+		       isc_buffer_t *intoken, isc_uint32_t lifetime,
+		       gss_ctx_id_t *context, isc_boolean_t win2k)
 {
 	dns_rdata_tkey_t tkey;
 	isc_result_t result;
 	isc_stdtime_t now;
 	isc_buffer_t token;
-	unsigned char array[1024];
+	unsigned char array[4096];
+
+	UNUSED(intoken);
 
 	REQUIRE(msg != NULL);
 	REQUIRE(name != NULL);
 	REQUIRE(gname != NULL);
-	REQUIRE(context != NULL && *context == NULL);
+	REQUIRE(context != NULL);
 
 	isc_buffer_init(&token, array, sizeof(array));
-	result = dst_gssapi_initctx(gname, cred, NULL, &token, context);
+	result = dst_gssapi_initctx(gname, NULL, &token, context);
 	if (result != DNS_R_CONTINUE && result != ISC_R_SUCCESS)
 		return (result);
 
@@ -925,7 +1003,12 @@ dns_tkey_buildgssquery(dns_message_t *msg, dns_name_t *name,
 	ISC_LINK_INIT(&tkey.common, link);
 	tkey.mctx = NULL;
 	dns_name_init(&tkey.algorithm, NULL);
-	dns_name_clone(DNS_TSIG_GSSAPI_NAME, &tkey.algorithm);
+
+	if (win2k)
+		dns_name_clone(DNS_TSIG_GSSAPIMS_NAME, &tkey.algorithm);
+	else
+		dns_name_clone(DNS_TSIG_GSSAPI_NAME, &tkey.algorithm);
+
 	isc_stdtime_get(&now);
 	tkey.inception = now;
 	tkey.expire = now + lifetime;
@@ -936,7 +1019,7 @@ dns_tkey_buildgssquery(dns_message_t *msg, dns_name_t *name,
 	tkey.other = NULL;
 	tkey.otherlen = 0;
 
-	RETERR(buildquery(msg, name, &tkey));
+	RETERR(buildquery(msg, name, &tkey, win2k));
 
 	return (ISC_R_SUCCESS);
 
@@ -963,7 +1046,7 @@ dns_tkey_builddeletequery(dns_message_t *msg, dns_tsigkey_t *key) {
 	tkey.keylen = tkey.otherlen = 0;
 	tkey.key = tkey.other = NULL;
 
-	return (buildquery(msg, &key->name, &tkey));
+	return (buildquery(msg, &key->name, &tkey, ISC_FALSE));
 }
 
 static isc_result_t
@@ -1034,10 +1117,9 @@ dns_tkey_processdhresponse(dns_message_t *qmsg, dns_message_t *rmsg,
 	    rtkey.mode != DNS_TKEYMODE_DIFFIEHELLMAN ||
 	    rtkey.mode != qtkey.mode ||
 	    !dns_name_equal(&rtkey.algorithm, &qtkey.algorithm) ||
-	    rmsg->rcode != dns_rcode_noerror)
-	{
+	    rmsg->rcode != dns_rcode_noerror) {
 		tkey_log("dns_tkey_processdhresponse: tkey mode invalid "
-			 "or error set");
+			 "or error set(1)");
 		result = DNS_R_INVALIDTKEY;
 		dns_rdata_freestruct(&qtkey);
 		goto failure;
@@ -1106,7 +1188,7 @@ dns_tkey_processdhresponse(dns_message_t *qmsg, dns_message_t *rmsg,
 	result = dns_tsigkey_create(tkeyname, &rtkey.algorithm,
 				    r.base, r.length, ISC_TRUE,
 				    NULL, rtkey.inception, rtkey.expire,
-				    ring->mctx, ring, outkey);
+				    rmsg->mctx, ring, outkey);
 	isc_buffer_free(&shared);
 	dns_rdata_freestruct(&rtkey);
 	dst_key_free(&theirkey);
@@ -1127,18 +1209,19 @@ dns_tkey_processdhresponse(dns_message_t *qmsg, dns_message_t *rmsg,
 
 isc_result_t
 dns_tkey_processgssresponse(dns_message_t *qmsg, dns_message_t *rmsg,
-			    dns_name_t *gname, void *cred, void **context,
-			    dns_tsigkey_t **outkey, dns_tsig_keyring_t *ring)
+			    dns_name_t *gname, gss_ctx_id_t *context,
+			    isc_buffer_t *outtoken, dns_tsigkey_t **outkey,
+			    dns_tsig_keyring_t *ring)
 {
 	dns_rdata_t rtkeyrdata = DNS_RDATA_INIT, qtkeyrdata = DNS_RDATA_INIT;
 	dns_name_t *tkeyname;
 	dns_rdata_tkey_t rtkey, qtkey;
-	isc_buffer_t outtoken;
 	dst_key_t *dstkey = NULL;
-	isc_region_t r;
+	isc_buffer_t intoken;
 	isc_result_t result;
 	unsigned char array[1024];
 
+	REQUIRE(outtoken != NULL);
 	REQUIRE(qmsg != NULL);
 	REQUIRE(rmsg != NULL);
 	REQUIRE(gname != NULL);
@@ -1150,31 +1233,42 @@ dns_tkey_processgssresponse(dns_message_t *qmsg, dns_message_t *rmsg,
 	RETERR(find_tkey(rmsg, &tkeyname, &rtkeyrdata, DNS_SECTION_ANSWER));
 	RETERR(dns_rdata_tostruct(&rtkeyrdata, &rtkey, NULL));
 
-	RETERR(find_tkey(qmsg, &tkeyname, &qtkeyrdata,
-			 DNS_SECTION_ADDITIONAL));
+	/*
+	 * Win2k puts the item in the ANSWER section, while the RFC
+	 * specifies it should be in the ADDITIONAL section.  Check first
+	 * where it should be, and then where it may be.
+	 */
+	result = find_tkey(qmsg, &tkeyname, &qtkeyrdata,
+			   DNS_SECTION_ADDITIONAL);
+	if (result == ISC_R_NOTFOUND)
+		result = find_tkey(qmsg, &tkeyname, &qtkeyrdata,
+				   DNS_SECTION_ANSWER);
+	if (result != ISC_R_SUCCESS)
+		goto failure;
+
 	RETERR(dns_rdata_tostruct(&qtkeyrdata, &qtkey, NULL));
 
 	if (rtkey.error != dns_rcode_noerror ||
 	    rtkey.mode != DNS_TKEYMODE_GSSAPI ||
-	    !dns_name_equal(&rtkey.algorithm, &rtkey.algorithm))
-	{
-		tkey_log("dns_tkey_processdhresponse: tkey mode invalid "
-			 "or error set");
+	    !dns_name_equal(&rtkey.algorithm, &qtkey.algorithm)) {
+		tkey_log("dns_tkey_processgssresponse: tkey mode invalid "
+			 "or error set(2) %d", rtkey.error);
+		_dns_tkey_dumpmessage(qmsg);
+		_dns_tkey_dumpmessage(rmsg);
 		result = DNS_R_INVALIDTKEY;
 		goto failure;
 	}
 
-	isc_buffer_init(&outtoken, array, sizeof(array));
-	r.base = rtkey.key;
-	r.length = rtkey.keylen;
-	RETERR(dst_gssapi_initctx(gname, cred, &r, &outtoken, context));
+	isc_buffer_init(outtoken, array, sizeof(array));
+	isc_buffer_init(&intoken, rtkey.key, rtkey.keylen);
+	RETERR(dst_gssapi_initctx(gname, &intoken, outtoken, context));
 
 	dstkey = NULL;
 	RETERR(dst_key_fromgssapi(dns_rootname, *context, rmsg->mctx,
 				  &dstkey));
 
 	RETERR(dns_tsigkey_createfromkey(tkeyname, DNS_TSIG_GSSAPI_NAME,
-					 dstkey, ISC_TRUE, NULL,
+					 dstkey, ISC_FALSE, NULL,
 					 rtkey.inception, rtkey.expire,
 					 ring->mctx, ring, outkey));
 
@@ -1182,6 +1276,9 @@ dns_tkey_processgssresponse(dns_message_t *qmsg, dns_message_t *rmsg,
 	return (result);
 
  failure:
+	/*
+	 * XXXSRA This probably leaks memory from rtkey and qtkey.
+	 */
 	return (result);
 }
 
@@ -1212,10 +1309,9 @@ dns_tkey_processdeleteresponse(dns_message_t *qmsg, dns_message_t *rmsg,
 	    rtkey.mode != DNS_TKEYMODE_DELETE ||
 	    rtkey.mode != qtkey.mode ||
 	    !dns_name_equal(&rtkey.algorithm, &qtkey.algorithm) ||
-	    rmsg->rcode != dns_rcode_noerror)
-	{
+	    rmsg->rcode != dns_rcode_noerror) {
 		tkey_log("dns_tkey_processdeleteresponse: tkey mode invalid "
-			 "or error set");
+			 "or error set(3)");
 		result = DNS_R_INVALIDTKEY;
 		dns_rdata_freestruct(&qtkey);
 		dns_rdata_freestruct(&rtkey);
@@ -1240,3 +1336,84 @@ dns_tkey_processdeleteresponse(dns_message_t *qmsg, dns_message_t *rmsg,
  failure:
 	return (result);
 }
+
+isc_result_t
+dns_tkey_gssnegotiate(dns_message_t *qmsg, dns_message_t *rmsg,
+		      dns_name_t *server, gss_ctx_id_t *context,
+		      dns_tsigkey_t **outkey, dns_tsig_keyring_t *ring,
+		      isc_boolean_t win2k)
+{
+	dns_rdata_t rtkeyrdata = DNS_RDATA_INIT, qtkeyrdata = DNS_RDATA_INIT;
+	dns_name_t *tkeyname;
+	dns_rdata_tkey_t rtkey, qtkey;
+	isc_buffer_t intoken, outtoken;
+	dst_key_t *dstkey = NULL;
+	isc_result_t result;
+	unsigned char array[1024];
+
+	REQUIRE(qmsg != NULL);
+	REQUIRE(rmsg != NULL);
+	REQUIRE(server != NULL);
+	if (outkey != NULL)
+		REQUIRE(*outkey == NULL);
+
+	if (rmsg->rcode != dns_rcode_noerror)
+		return (ISC_RESULTCLASS_DNSRCODE + rmsg->rcode);
+
+	RETERR(find_tkey(rmsg, &tkeyname, &rtkeyrdata, DNS_SECTION_ANSWER));
+	RETERR(dns_rdata_tostruct(&rtkeyrdata, &rtkey, NULL));
+
+	if (win2k == ISC_TRUE)
+		RETERR(find_tkey(qmsg, &tkeyname, &qtkeyrdata,
+			 DNS_SECTION_ANSWER));
+	else
+		RETERR(find_tkey(qmsg, &tkeyname, &qtkeyrdata,
+			 DNS_SECTION_ADDITIONAL));
+
+	RETERR(dns_rdata_tostruct(&qtkeyrdata, &qtkey, NULL));
+
+	if (rtkey.error != dns_rcode_noerror ||
+	    rtkey.mode != DNS_TKEYMODE_GSSAPI ||
+	    !dns_name_equal(&rtkey.algorithm, &qtkey.algorithm))
+	{
+		tkey_log("dns_tkey_processdhresponse: tkey mode invalid "
+			 "or error set(4)");
+		result = DNS_R_INVALIDTKEY;
+		goto failure;
+	}
+
+	isc_buffer_init(&intoken, rtkey.key, rtkey.keylen);
+	isc_buffer_init(&outtoken, array, sizeof(array));
+
+	result = dst_gssapi_initctx(server, &intoken, &outtoken, context);
+	if (result != DNS_R_CONTINUE && result != ISC_R_SUCCESS)
+		return (result);
+
+	dstkey = NULL;
+	RETERR(dst_key_fromgssapi(dns_rootname, *context, rmsg->mctx,
+				  &dstkey));
+
+	/*
+	 * XXXSRA This seems confused.  If we got CONTINUE from initctx,
+	 * the GSS negotiation hasn't completed yet, so we can't sign
+	 * anything yet.
+	 */
+
+	RETERR(dns_tsigkey_createfromkey(tkeyname,
+					 (win2k
+					  ? DNS_TSIG_GSSAPIMS_NAME
+					  : DNS_TSIG_GSSAPI_NAME),
+					 dstkey, ISC_TRUE, NULL,
+					 rtkey.inception, rtkey.expire,
+					 ring->mctx, ring, outkey));
+
+	dns_rdata_freestruct(&rtkey);
+	return (result);
+
+ failure:
+	/*
+	 * XXXSRA This probably leaks memory from qtkey.
+	 */
+	dns_rdata_freestruct(&rtkey);
+	return (result);
+}
diff --git a/contrib/bind9/lib/dns/tsig.c b/contrib/bind9/lib/dns/tsig.c
index f21832f..74a7af3 100644
--- a/contrib/bind9/lib/dns/tsig.c
+++ b/contrib/bind9/lib/dns/tsig.c
@@ -16,7 +16,7 @@
  */
 
 /*
- * $Id: tsig.c,v 1.117.18.14 2008/01/17 23:46:03 tbox Exp $
+ * $Id: tsig.c,v 1.136 2008/11/04 21:23:14 marka Exp $
  */
 /*! \file */
 #include <config.h>
@@ -28,10 +28,12 @@
 #include <isc/refcount.h>
 #include <isc/string.h>		/* Required for HP/UX (and others?) */
 #include <isc/util.h>
+#include <isc/time.h>
 
 #include <dns/keyvalues.h>
 #include <dns/log.h>
 #include <dns/message.h>
+#include <dns/fixedname.h>
 #include <dns/rbt.h>
 #include <dns/rdata.h>
 #include <dns/rdatalist.h>
@@ -74,7 +76,6 @@ dns_name_t *dns_tsig_hmacmd5_name = &hmacmd5;
 
 static unsigned char gsstsig_ndata[] = "\010gss-tsig";
 static unsigned char gsstsig_offsets[] = { 0, 9 };
-
 static dns_name_t gsstsig = {
 	DNS_NAME_MAGIC,
 	gsstsig_ndata, 10, 2,
@@ -83,13 +84,14 @@ static dns_name_t gsstsig = {
 	{(void *)-1, (void *)-1},
 	{NULL, NULL}
 };
-
 LIBDNS_EXTERNAL_DATA dns_name_t *dns_tsig_gssapi_name = &gsstsig;
 
-/* It's nice of Microsoft to conform to their own standard. */
+/*
+ * Since Microsoft doesn't follow its own standard, we will use this
+ * alternate name as a second guess.
+ */
 static unsigned char gsstsigms_ndata[] = "\003gss\011microsoft\003com";
 static unsigned char gsstsigms_offsets[] = { 0, 4, 14, 18 };
-
 static dns_name_t gsstsigms = {
 	DNS_NAME_MAGIC,
 	gsstsigms_ndata, 19, 4,
@@ -98,7 +100,6 @@ static dns_name_t gsstsigms = {
 	{(void *)-1, (void *)-1},
 	{NULL, NULL}
 };
-
 LIBDNS_EXTERNAL_DATA dns_name_t *dns_tsig_gssapims_name = &gsstsigms;
 
 static unsigned char hmacsha1_ndata[] = "\011hmac-sha1";
@@ -179,10 +180,16 @@ tsig_log(dns_tsigkey_t *key, int level, const char *fmt, ...)
      ISC_FORMAT_PRINTF(3, 4);
 
 static void
+cleanup_ring(dns_tsig_keyring_t *ring);
+static void
+tsigkey_free(dns_tsigkey_t *key);
+
+static void
 tsig_log(dns_tsigkey_t *key, int level, const char *fmt, ...) {
 	va_list ap;
 	char message[4096];
 	char namestr[DNS_NAME_FORMATSIZE];
+	char creatorstr[DNS_NAME_FORMATSIZE];
 
 	if (isc_log_wouldlog(dns_lctx, level) == ISC_FALSE)
 		return;
@@ -190,11 +197,22 @@ tsig_log(dns_tsigkey_t *key, int level, const char *fmt, ...) {
 		dns_name_format(&key->name, namestr, sizeof(namestr));
 	else
 		strcpy(namestr, "<null>");
+
+	if (key != NULL && key->generated)
+		dns_name_format(key->creator, creatorstr, sizeof(creatorstr));
+
 	va_start(ap, fmt);
 	vsnprintf(message, sizeof(message), fmt, ap);
 	va_end(ap);
-	isc_log_write(dns_lctx, DNS_LOGCATEGORY_DNSSEC, DNS_LOGMODULE_TSIG,
-		      level, "tsig key '%s': %s", namestr, message);
+	if (key != NULL && key->generated)
+		isc_log_write(dns_lctx,
+			      DNS_LOGCATEGORY_DNSSEC, DNS_LOGMODULE_TSIG,
+			      level, "tsig key '%s' (%s): %s",
+			      namestr, creatorstr, message);
+	else
+		isc_log_write(dns_lctx,
+			      DNS_LOGCATEGORY_DNSSEC, DNS_LOGMODULE_TSIG,
+			      level, "tsig key '%s': %s", namestr, message);
 }
 
 isc_result_t
@@ -330,6 +348,16 @@ dns_tsigkey_createfromkey(dns_name_t *name, dns_name_t *algorithm,
 
 	if (ring != NULL) {
 		RWLOCK(&ring->lock, isc_rwlocktype_write);
+		ring->writecount++;
+
+		/*
+		 * Do on the fly cleaning.  Find some nodes we might not
+		 * want around any more.
+		 */
+		if (ring->writecount > 10) {
+			cleanup_ring(ring);
+			ring->writecount = 0;
+		}
 		ret = dns_rbt_addname(ring->keys, name, tkey);
 		if (ret != ISC_R_SUCCESS) {
 			RWUNLOCK(&ring->lock, isc_rwlocktype_write);
@@ -338,7 +366,12 @@ dns_tsigkey_createfromkey(dns_name_t *name, dns_name_t *algorithm,
 		RWUNLOCK(&ring->lock, isc_rwlocktype_write);
 	}
 
-	if (dstkey != NULL && dst_key_size(dstkey) < 64) {
+	/*
+	 * Ignore this if it's a GSS key, since the key size is meaningless.
+	 */
+	if (dstkey != NULL && dst_key_size(dstkey) < 64 &&
+	    !dns_name_equal(algorithm, DNS_TSIG_GSSAPI_NAME) &&
+	    !dns_name_equal(algorithm, DNS_TSIG_GSSAPIMS_NAME)) {
 		char namestr[DNS_NAME_FORMATSIZE];
 		dns_name_format(name, namestr, sizeof(namestr));
 		isc_log_write(dns_lctx, DNS_LOGCATEGORY_DNSSEC,
@@ -375,6 +408,66 @@ dns_tsigkey_createfromkey(dns_name_t *name, dns_name_t *algorithm,
 	return (ret);
 }
 
+/*
+ * Find a few nodes to destroy if possible.
+ */
+static void
+cleanup_ring(dns_tsig_keyring_t *ring)
+{
+	isc_result_t result;
+	dns_rbtnodechain_t chain;
+	dns_name_t foundname;
+	dns_fixedname_t fixedorigin;
+	dns_name_t *origin;
+	isc_stdtime_t now;
+	dns_rbtnode_t *node;
+	dns_tsigkey_t *tkey;
+
+	/*
+	 * Start up a new iterator each time.
+	 */
+	isc_stdtime_get(&now);
+	dns_name_init(&foundname, NULL);
+	dns_fixedname_init(&fixedorigin);
+	origin = dns_fixedname_name(&fixedorigin);
+
+ again:
+	dns_rbtnodechain_init(&chain, ring->mctx);
+	result = dns_rbtnodechain_first(&chain, ring->keys, &foundname,
+					origin);
+	if (result != ISC_R_SUCCESS && result != DNS_R_NEWORIGIN) {
+		dns_rbtnodechain_invalidate(&chain);
+		return;
+	}
+
+	for (;;) {
+		node = NULL;
+		dns_rbtnodechain_current(&chain, &foundname, origin, &node);
+		tkey = node->data;
+		if (tkey != NULL) {
+			if (tkey->generated
+			    && isc_refcount_current(&tkey->refs) == 1
+			    && tkey->inception != tkey->expire
+			    && tkey->expire < now) {
+				tsig_log(tkey, 2, "tsig expire: deleting");
+				/* delete the key */
+				dns_rbtnodechain_invalidate(&chain);
+				(void)dns_rbt_deletename(ring->keys,
+							 &tkey->name,
+							 ISC_FALSE);
+				goto again;
+			}
+		}
+		result = dns_rbtnodechain_next(&chain, &foundname,
+					       origin);
+		if (result != ISC_R_SUCCESS && result != DNS_R_NEWORIGIN) {
+			dns_rbtnodechain_invalidate(&chain);
+			return;
+		}
+
+	}
+}
+
 isc_result_t
 dns_tsigkey_create(dns_name_t *name, dns_name_t *algorithm,
 		   unsigned char *secret, int length, isc_boolean_t generated,
@@ -540,17 +633,6 @@ dns_tsigkey_setdeleted(dns_tsigkey_t *key) {
 	RWUNLOCK(&key->ring->lock, isc_rwlocktype_write);
 }
 
-static void
-buffer_putuint48(isc_buffer_t *b, isc_uint64_t val) {
-	isc_uint16_t valhi;
-	isc_uint32_t vallo;
-
-	valhi = (isc_uint16_t)(val >> 32);
-	vallo = (isc_uint32_t)(val & 0xFFFFFFFF);
-	isc_buffer_putuint16(b, valhi);
-	isc_buffer_putuint32(b, vallo);
-}
-
 isc_result_t
 dns_tsig_sign(dns_message_t *msg) {
 	dns_tsigkey_t *key;
@@ -613,7 +695,7 @@ dns_tsig_sign(dns_message_t *msg) {
 		tsig.otherlen = BADTIMELEN;
 		tsig.other = badtimedata;
 		isc_buffer_init(&otherbuf, tsig.other, tsig.otherlen);
-		buffer_putuint48(&otherbuf, tsig.timesigned);
+		isc_buffer_putuint48(&otherbuf, tsig.timesigned);
 	}
 
 	if (key->key != NULL && tsig.error != dns_tsigerror_badsig) {
@@ -641,8 +723,7 @@ dns_tsig_sign(dns_message_t *msg) {
 				goto cleanup_context;
 			isc_buffer_putuint16(&databuf, querytsig.siglen);
 			if (isc_buffer_availablelength(&databuf) <
-			    querytsig.siglen)
-			{
+			    querytsig.siglen) {
 				ret = ISC_R_NOSPACE;
 				goto cleanup_context;
 			}
@@ -700,7 +781,7 @@ dns_tsig_sign(dns_message_t *msg) {
 		isc_buffer_clear(&databuf);
 		if (tsig.error == dns_tsigerror_badtime)
 			tsig.timesigned = querytsig.timesigned;
-		buffer_putuint48(&databuf, tsig.timesigned);
+		isc_buffer_putuint48(&databuf, tsig.timesigned);
 		isc_buffer_putuint16(&databuf, tsig.fudge);
 		isc_buffer_usedregion(&databuf, &r);
 		ret = dst_context_adddata(ctx, &r);
@@ -852,6 +933,7 @@ dns_tsig_verify(isc_buffer_t *source, dns_message_t *msg,
 	REQUIRE(source != NULL);
 	REQUIRE(DNS_MESSAGE_VALID(msg));
 	tsigkey = dns_message_gettsigkey(msg);
+
 	REQUIRE(tsigkey == NULL || VALID_TSIG_KEY(tsigkey));
 
 	msg->verify_attempted = 1;
@@ -907,8 +989,7 @@ dns_tsig_verify(isc_buffer_t *source, dns_message_t *msg,
 	 */
 	if (is_response(msg) &&
 	    (!dns_name_equal(keyname, &tsigkey->name) ||
-	     !dns_name_equal(&tsig.algorithm, &querytsig.algorithm)))
-	{
+	     !dns_name_equal(&tsig.algorithm, &querytsig.algorithm))) {
 		msg->tsigstatus = dns_tsigerror_badkey;
 		tsig_log(msg->tsigkey, 2,
 			 "key name and algorithm do not match");
@@ -1084,7 +1165,7 @@ dns_tsig_verify(isc_buffer_t *source, dns_message_t *msg,
 			goto cleanup_context;
 
 		isc_buffer_clear(&databuf);
-		buffer_putuint48(&databuf, tsig.timesigned);
+		isc_buffer_putuint48(&databuf, tsig.timesigned);
 		isc_buffer_putuint16(&databuf, tsig.fudge);
 		isc_buffer_putuint16(&databuf, tsig.error);
 		isc_buffer_putuint16(&databuf, tsig.otherlen);
@@ -1106,15 +1187,14 @@ dns_tsig_verify(isc_buffer_t *source, dns_message_t *msg,
 			msg->tsigstatus = dns_tsigerror_badsig;
 			ret = DNS_R_TSIGVERIFYFAILURE;
 			tsig_log(msg->tsigkey, 2,
-				 "signature failed to verify");
+				 "signature failed to verify(1)");
 			goto cleanup_context;
 		} else if (ret != ISC_R_SUCCESS)
 			goto cleanup_context;
 
 		dst_context_destroy(&ctx);
 	} else if (tsig.error != dns_tsigerror_badsig &&
-		   tsig.error != dns_tsigerror_badkey)
-	{
+		   tsig.error != dns_tsigerror_badkey) {
 		msg->tsigstatus = dns_tsigerror_badsig;
 		tsig_log(msg->tsigkey, 2, "signature was empty");
 		return (DNS_R_TSIGVERIFYFAILURE);
@@ -1201,8 +1281,7 @@ tsig_verify_tcp(isc_buffer_t *source, dns_message_t *msg) {
 		 * Do the key name and algorithm match that of the query?
 		 */
 		if (!dns_name_equal(keyname, &tsigkey->name) ||
-		    !dns_name_equal(&tsig.algorithm, &querytsig.algorithm))
-		{
+		    !dns_name_equal(&tsig.algorithm, &querytsig.algorithm)) {
 			msg->tsigstatus = dns_tsigerror_badkey;
 			ret = DNS_R_TSIGVERIFYFAILURE;
 			tsig_log(msg->tsigkey, 2,
@@ -1221,8 +1300,7 @@ tsig_verify_tcp(isc_buffer_t *source, dns_message_t *msg) {
 			ret = DNS_R_CLOCKSKEW;
 			goto cleanup_querystruct;
 		} else if (now + msg->timeadjust <
-			   tsig.timesigned - tsig.fudge)
-		{
+			   tsig.timesigned - tsig.fudge) {
 			msg->tsigstatus = dns_tsigerror_badtime;
 			tsig_log(msg->tsigkey, 2,
 				 "signature is in the future");
@@ -1312,7 +1390,7 @@ tsig_verify_tcp(isc_buffer_t *source, dns_message_t *msg) {
 	 */
 	if (has_tsig) {
 		isc_buffer_init(&databuf, data, sizeof(data));
-		buffer_putuint48(&databuf, tsig.timesigned);
+		isc_buffer_putuint48(&databuf, tsig.timesigned);
 		isc_buffer_putuint16(&databuf, tsig.fudge);
 		isc_buffer_usedregion(&databuf, &r);
 		ret = dst_context_adddata(msg->tsigctx, &r);
@@ -1339,7 +1417,7 @@ tsig_verify_tcp(isc_buffer_t *source, dns_message_t *msg) {
 		if (ret == DST_R_VERIFYFAILURE) {
 			msg->tsigstatus = dns_tsigerror_badsig;
 			tsig_log(msg->tsigkey, 2,
-				 "signature failed to verify");
+				 "signature failed to verify(2)");
 			ret = DNS_R_TSIGVERIFYFAILURE;
 			goto cleanup_context;
 		}
@@ -1375,6 +1453,10 @@ dns_tsigkey_find(dns_tsigkey_t **tsigkey, dns_name_t *name,
 	REQUIRE(name != NULL);
 	REQUIRE(ring != NULL);
 
+	RWLOCK(&ring->lock, isc_rwlocktype_write);
+	cleanup_ring(ring);
+	RWUNLOCK(&ring->lock, isc_rwlocktype_write);
+
 	isc_stdtime_get(&now);
 	RWLOCK(&ring->lock, isc_rwlocktype_read);
 	key = NULL;
@@ -1393,7 +1475,7 @@ dns_tsigkey_find(dns_tsigkey_t **tsigkey, dns_name_t *name,
 		 */
 		RWUNLOCK(&ring->lock, isc_rwlocktype_read);
 		RWLOCK(&ring->lock, isc_rwlocktype_write);
-		(void) dns_rbt_deletename(ring->keys, name, ISC_FALSE);
+		(void)dns_rbt_deletename(ring->keys, name, ISC_FALSE);
 		RWUNLOCK(&ring->lock, isc_rwlocktype_write);
 		return (ISC_R_NOTFOUND);
 	}
@@ -1443,6 +1525,7 @@ dns_tsigkeyring_create(isc_mem_t *mctx, dns_tsig_keyring_t **ringp) {
 		return (result);
 	}
 
+	ring->writecount = 0;
 	ring->mctx = NULL;
 	isc_mem_attach(mctx, &ring->mctx);
 
diff --git a/contrib/bind9/lib/dns/ttl.c b/contrib/bind9/lib/dns/ttl.c
index 39d2ac3..9d0dec5 100644
--- a/contrib/bind9/lib/dns/ttl.c
+++ b/contrib/bind9/lib/dns/ttl.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ttl.c,v 1.25.18.2 2005/04/29 00:16:07 marka Exp $ */
+/* $Id: ttl.c,v 1.29 2007/06/19 23:47:16 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/dns/validator.c b/contrib/bind9/lib/dns/validator.c
index 685434b..c62b714 100644
--- a/contrib/bind9/lib/dns/validator.c
+++ b/contrib/bind9/lib/dns/validator.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,18 +15,17 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: validator.c,v 1.119.18.41.2.1 2009/03/17 02:23:49 marka Exp $ */
-
-/*! \file */
+/* $Id: validator.c,v 1.164.12.9 2009/05/07 23:47:12 tbox Exp $ */
 
 #include <config.h>
 
+#include <isc/base32.h>
 #include <isc/mem.h>
 #include <isc/print.h>
+#include <isc/sha2.h>
 #include <isc/string.h>
 #include <isc/task.h>
 #include <isc/util.h>
-#include <isc/sha2.h>
 
 #include <dns/db.h>
 #include <dns/ds.h>
@@ -37,6 +36,7 @@
 #include <dns/message.h>
 #include <dns/ncache.h>
 #include <dns/nsec.h>
+#include <dns/nsec3.h>
 #include <dns/rdata.h>
 #include <dns/rdatastruct.h>
 #include <dns/rdataset.h>
@@ -89,7 +89,7 @@
 #define VALID_VALIDATOR(v)		ISC_MAGIC_VALID(v, VALIDATOR_MAGIC)
 
 #define VALATTR_SHUTDOWN		0x0001	/*%< Shutting down. */
-#define VALATTR_CANCELED		0x0002	/*%< Cancelled. */
+#define VALATTR_CANCELED		0x0002	/*%< Canceled. */
 #define VALATTR_TRIEDVERIFY		0x0004  /*%< We have found a key and
 						 * have attempted a verify. */
 #define VALATTR_INSECURITY		0x0010	/*%< Attempting proveunsecure. */
@@ -98,16 +98,23 @@
 /*!
  * NSEC proofs to be looked for.
  */
-#define VALATTR_NEEDNOQNAME		0x0100
-#define VALATTR_NEEDNOWILDCARD		0x0200
-#define VALATTR_NEEDNODATA		0x0400
+#define VALATTR_NEEDNOQNAME		0x00000100
+#define VALATTR_NEEDNOWILDCARD		0x00000200
+#define VALATTR_NEEDNODATA		0x00000400
 
 /*!
  * NSEC proofs that have been found.
  */
-#define VALATTR_FOUNDNOQNAME		0x1000
-#define VALATTR_FOUNDNOWILDCARD		0x2000
-#define VALATTR_FOUNDNODATA		0x4000
+#define VALATTR_FOUNDNOQNAME		0x00001000
+#define VALATTR_FOUNDNOWILDCARD		0x00002000
+#define VALATTR_FOUNDNODATA		0x00004000
+#define VALATTR_FOUNDCLOSEST		0x00008000
+
+/*
+ *
+ */
+#define VALATTR_FOUNDOPTOUT		0x00010000
+#define VALATTR_FOUNDUNKNOWN		0x00020000
 
 #define NEEDNODATA(val) ((val->attributes & VALATTR_NEEDNODATA) != 0)
 #define NEEDNOQNAME(val) ((val->attributes & VALATTR_NEEDNOQNAME) != 0)
@@ -250,10 +257,20 @@ static isc_boolean_t
 isdelegation(dns_name_t *name, dns_rdataset_t *rdataset,
 	     isc_result_t dbresult)
 {
-	dns_rdataset_t set;
+	dns_fixedname_t fixed;
+	dns_label_t hashlabel;
+	dns_name_t nsec3name;
+	dns_rdata_nsec3_t nsec3;
 	dns_rdata_t rdata = DNS_RDATA_INIT;
+	dns_rdataset_t set;
+	int order;
+	int scope;
 	isc_boolean_t found;
+	isc_buffer_t buffer;
 	isc_result_t result;
+	unsigned char hash[NSEC3_MAX_HASH_LENGTH];
+	unsigned char owner[NSEC3_MAX_HASH_LENGTH];
+	unsigned int length;
 
 	REQUIRE(dbresult == DNS_R_NXRRSET || dbresult == DNS_R_NCACHENXRRSET);
 
@@ -263,6 +280,8 @@ isdelegation(dns_name_t *name, dns_rdataset_t *rdataset,
 	else {
 		result = dns_ncache_getrdataset(rdataset, name,
 						dns_rdatatype_nsec, &set);
+		if (result == ISC_R_NOTFOUND)
+			goto trynsec3;
 		if (result != ISC_R_SUCCESS)
 			return (ISC_FALSE);
 	}
@@ -274,9 +293,78 @@ isdelegation(dns_name_t *name, dns_rdataset_t *rdataset,
 	if (result == ISC_R_SUCCESS) {
 		dns_rdataset_current(&set, &rdata);
 		found = dns_nsec_typepresent(&rdata, dns_rdatatype_ns);
+		dns_rdata_reset(&rdata);
 	}
 	dns_rdataset_disassociate(&set);
 	return (found);
+
+ trynsec3:
+	/*
+	 * Iterate over the ncache entry.
+	 */
+	found = ISC_FALSE;
+	dns_name_init(&nsec3name, NULL);
+	dns_fixedname_init(&fixed);
+	dns_name_downcase(name, dns_fixedname_name(&fixed), NULL);
+	name = dns_fixedname_name(&fixed);
+	result = dns_rdataset_first(rdataset);
+	for (result = dns_rdataset_first(rdataset);
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdataset_next(rdataset))
+	{
+		dns_ncache_current(rdataset, &nsec3name, &set);
+		if (set.type != dns_rdatatype_nsec3) {
+			dns_rdataset_disassociate(&set);
+			continue;
+		}
+		dns_name_getlabel(&nsec3name, 0, &hashlabel);
+		isc_region_consume(&hashlabel, 1);
+		isc_buffer_init(&buffer, owner, sizeof(owner));
+		result = isc_base32hex_decoderegion(&hashlabel, &buffer);
+		if (result != ISC_R_SUCCESS) {
+			dns_rdataset_disassociate(&set);
+			continue;
+		}
+		for (result = dns_rdataset_first(&set);
+		     result == ISC_R_SUCCESS;
+		     result = dns_rdataset_next(&set))
+		{
+			dns_rdata_reset(&rdata);
+			dns_rdataset_current(&set, &rdata);
+			(void)dns_rdata_tostruct(&rdata, &nsec3, NULL);
+			if (nsec3.hash != 1)
+				continue;
+			length = isc_iterated_hash(hash, nsec3.hash,
+						   nsec3.iterations, nsec3.salt,
+						   nsec3.salt_length,
+						   name->ndata, name->length);
+			if (length != isc_buffer_usedlength(&buffer))
+				continue;
+			order = memcmp(hash, owner, length);
+			if (order == 0) {
+				found = dns_nsec3_typepresent(&rdata,
+							      dns_rdatatype_ns);
+				dns_rdataset_disassociate(&set);
+				return (found);
+			}
+			if ((nsec3.flags & DNS_NSEC3FLAG_OPTOUT) == 0)
+				continue;
+			/*
+			 * Does this optout span cover the name?
+			 */
+			scope = memcmp(owner, nsec3.next, nsec3.next_length);
+			if ((scope < 0 && order > 0 &&
+			     memcmp(hash, nsec3.next, length) < 0) ||
+			    (scope >= 0 && (order > 0 ||
+					memcmp(hash, nsec3.next, length) < 0)))
+			{
+				dns_rdataset_disassociate(&set);
+				return (ISC_TRUE);
+			}
+		}
+		dns_rdataset_disassociate(&set);
+	}
+	return (found);
 }
 
 /*%
@@ -767,10 +855,317 @@ nsecnoexistnodata(dns_validator_t *val, dns_name_t* name, dns_name_t *nsecname,
 	return (ISC_R_SUCCESS);
 }
 
+static isc_result_t
+nsec3noexistnodata(dns_validator_t *val, dns_name_t* name,
+		   dns_name_t *nsec3name, dns_rdataset_t *nsec3set,
+		   dns_name_t *zonename, isc_boolean_t *exists,
+		   isc_boolean_t *data, isc_boolean_t *optout,
+		   isc_boolean_t *unknown, isc_boolean_t *setclosest,
+		   isc_boolean_t *setnearest, dns_name_t *closest,
+		   dns_name_t *nearest)
+{
+	char namebuf[DNS_NAME_FORMATSIZE];
+	dns_fixedname_t fzone;
+	dns_fixedname_t qfixed;
+	dns_label_t hashlabel;
+	dns_name_t *qname;
+	dns_name_t *zone;
+	dns_rdata_nsec3_t nsec3;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	int order;
+	int scope;
+	isc_boolean_t atparent;
+	isc_boolean_t first;
+	isc_boolean_t ns;
+	isc_boolean_t soa;
+	isc_buffer_t buffer;
+	isc_result_t answer = ISC_R_IGNORE;
+	isc_result_t result;
+	unsigned char hash[NSEC3_MAX_HASH_LENGTH];
+	unsigned char owner[NSEC3_MAX_HASH_LENGTH];
+	unsigned int length;
+	unsigned int qlabels;
+	unsigned int zlabels;
+
+	REQUIRE((exists == NULL && data == NULL) ||
+		(exists != NULL && data != NULL));
+	REQUIRE(nsec3set != NULL && nsec3set->type == dns_rdatatype_nsec3);
+	REQUIRE((setclosest == NULL && closest == NULL) ||
+		(setclosest != NULL && closest != NULL));
+	REQUIRE((setnearest == NULL && nearest == NULL) ||
+		(setnearest != NULL && nearest != NULL));
+
+	result = dns_rdataset_first(nsec3set);
+	if (result != ISC_R_SUCCESS) {
+		validator_log(val, ISC_LOG_DEBUG(3),
+			"failure processing NSEC3 set");
+		return (result);
+	}
+
+	dns_rdataset_current(nsec3set, &rdata);
+
+	result = dns_rdata_tostruct(&rdata, &nsec3, NULL);
+	if (result != ISC_R_SUCCESS)
+		return (result);
+
+	validator_log(val, ISC_LOG_DEBUG(3), "looking for relevant NSEC3");
+
+	dns_fixedname_init(&fzone);
+	zone = dns_fixedname_name(&fzone);
+	zlabels = dns_name_countlabels(nsec3name);
+
+	/*
+	 * NSEC3 records must have two or more labels to be valid.
+	 */
+	if (zlabels < 2)
+		return (ISC_R_IGNORE);
+
+	/*
+	 * Strip off the NSEC3 hash to get the zone.
+	 */
+	zlabels--;
+	dns_name_split(nsec3name, zlabels, NULL, zone);
+
+	/*
+	 * If not below the zone name we can ignore this record.
+	 */
+	if (!dns_name_issubdomain(name, zone))
+		return (ISC_R_IGNORE);
+
+	/*
+	 * Is this zone the same or deeper than the current zone?
+	 */
+	if (dns_name_countlabels(zonename) == 0 ||
+	    dns_name_issubdomain(zone, zonename))
+		dns_name_copy(zone, zonename, NULL);
+
+	if (!dns_name_equal(zone, zonename))
+		return (ISC_R_IGNORE);
+
+	/*
+	 * Are we only looking for the most enclosing zone?
+	 */
+	if (exists == NULL || data == NULL)
+		return (ISC_R_SUCCESS);
+
+	/*
+	 * Only set unknown once we are sure that this NSEC3 is from
+	 * the deepest covering zone.
+	 */
+	if (!dns_nsec3_supportedhash(nsec3.hash)) {
+		if (unknown != NULL)
+			*unknown = ISC_TRUE;
+		return (ISC_R_IGNORE);
+	}
+
+	/*
+	 * Recover the hash from the first label.
+	 */
+	dns_name_getlabel(nsec3name, 0, &hashlabel);
+	isc_region_consume(&hashlabel, 1);
+	isc_buffer_init(&buffer, owner, sizeof(owner));
+	result = isc_base32hex_decoderegion(&hashlabel, &buffer);
+	if (result != ISC_R_SUCCESS)
+		return (result);
+
+	/*
+	 * The hash lengths should match.  If not ignore the record.
+	 */
+	if (isc_buffer_usedlength(&buffer) != nsec3.next_length)
+		return (ISC_R_IGNORE);
+
+	/*
+	 * Work out what this NSEC3 covers.
+	 * Inside (<0) or outside (>=0).
+	 */
+	scope = memcmp(owner, nsec3.next, nsec3.next_length);
+
+	/*
+	 * Prepare to compute all the hashes.
+	 */
+	dns_fixedname_init(&qfixed);
+	qname = dns_fixedname_name(&qfixed);
+	dns_name_downcase(name, qname, NULL);
+	qlabels = dns_name_countlabels(qname);
+	first = ISC_TRUE;
+
+	while (qlabels >= zlabels) {
+		length = isc_iterated_hash(hash, nsec3.hash, nsec3.iterations,
+					   nsec3.salt, nsec3.salt_length,
+					   qname->ndata, qname->length);
+		/*
+		 * The computed hash length should match.
+		 */
+		if (length != nsec3.next_length) {
+			validator_log(val, ISC_LOG_DEBUG(3),
+				      "ignoring NSEC bad length %u vs %u",
+				      length, nsec3.next_length);
+			return (ISC_R_IGNORE);
+		}
+
+		order = memcmp(hash, owner, length);
+		if (first && order == 0) {
+			/*
+			 * The hashes are the same.
+			 */
+			atparent = dns_rdatatype_atparent(val->event->type);
+			ns = dns_nsec3_typepresent(&rdata, dns_rdatatype_ns);
+			soa = dns_nsec3_typepresent(&rdata, dns_rdatatype_soa);
+			if (ns && !soa) {
+				if (!atparent) {
+					/*
+					 * This NSEC record is from somewhere
+					 * higher in the DNS, and at the
+					 * parent of a delegation. It can not
+					 * be legitimately used here.
+					 */
+					validator_log(val, ISC_LOG_DEBUG(3),
+						      "ignoring parent NSEC3");
+					return (ISC_R_IGNORE);
+				}
+			} else if (atparent && ns && soa) {
+				/*
+				 * This NSEC record is from the child.
+				 * It can not be legitimately used here.
+				 */
+				validator_log(val, ISC_LOG_DEBUG(3),
+					      "ignoring child NSEC3");
+				return (ISC_R_IGNORE);
+			}
+			if (val->event->type == dns_rdatatype_cname ||
+			    val->event->type == dns_rdatatype_nxt ||
+			    val->event->type == dns_rdatatype_nsec ||
+			    val->event->type == dns_rdatatype_key ||
+			    !dns_nsec3_typepresent(&rdata, dns_rdatatype_cname)) {
+				*exists = ISC_TRUE;
+				*data = dns_nsec3_typepresent(&rdata,
+							      val->event->type);
+				validator_log(val, ISC_LOG_DEBUG(3),
+					      "NSEC3 proves name exists (owner) "
+					      "data=%d", *data);
+				return (ISC_R_SUCCESS);
+			}
+			validator_log(val, ISC_LOG_DEBUG(3),
+				      "NSEC3 proves CNAME exists");
+			return (ISC_R_IGNORE);
+		}
+
+		if (order == 0 &&
+		    dns_nsec3_typepresent(&rdata, dns_rdatatype_ns) &&
+		    !dns_nsec3_typepresent(&rdata, dns_rdatatype_soa))
+		{
+			/*
+			 * This NSEC3 record is from somewhere higher in
+			 * the DNS, and at the parent of a delegation.
+			 * It can not be legitimately used here.
+			 */
+			validator_log(val, ISC_LOG_DEBUG(3),
+				      "ignoring parent NSEC3");
+			return (ISC_R_IGNORE);
+		}
+
+		/*
+		 * Potential closest encloser.
+		 */
+		if (order == 0) {
+			if (closest != NULL &&
+			    (dns_name_countlabels(closest) == 0 ||
+			     dns_name_issubdomain(qname, closest)) &&
+			    !dns_nsec3_typepresent(&rdata, dns_rdatatype_ds) &&
+			    !dns_nsec3_typepresent(&rdata, dns_rdatatype_dname) &&
+			    (dns_nsec3_typepresent(&rdata, dns_rdatatype_soa) ||
+			     !dns_nsec3_typepresent(&rdata, dns_rdatatype_ns)))
+			{
+
+				dns_name_format(qname, namebuf,
+						sizeof(namebuf));
+				validator_log(val, ISC_LOG_DEBUG(3),
+					      "NSEC3 indicates potential "
+					      "closest encloser: '%s'",
+					       namebuf);
+				dns_name_copy(qname, closest, NULL);
+				*setclosest = ISC_TRUE;
+			}
+			dns_name_format(qname, namebuf, sizeof(namebuf));
+			validator_log(val, ISC_LOG_DEBUG(3),
+				      "NSEC3 at super-domain %s", namebuf);
+			return (answer);
+		}
+
+		/*
+		 * Find if the name does not exist.
+		 *
+		 * We continue as we need to find the name closest to the
+		 * closest encloser that doesn't exist.
+		 *
+		 * We also need to continue to ensure that we are not
+		 * proving the non-existence of a record in a sub-zone.
+		 * If that would be the case we will return ISC_R_IGNORE
+		 * above.
+		 */
+		if ((scope < 0 && order > 0 &&
+		     memcmp(hash, nsec3.next, length) < 0) ||
+		    (scope >= 0 && (order > 0 ||
+				    memcmp(hash, nsec3.next, length) < 0)))
+		{
+			char namebuf[DNS_NAME_FORMATSIZE];
+
+			dns_name_format(qname, namebuf, sizeof(namebuf));
+			validator_log(val, ISC_LOG_DEBUG(3), "NSEC3 proves "
+				      "name does not exist: '%s'", namebuf);
+			if (nearest != NULL &&
+			    (dns_name_countlabels(nearest) == 0 ||
+			     dns_name_issubdomain(nearest, qname))) {
+				dns_name_copy(qname, nearest, NULL);
+				*setnearest = ISC_TRUE;
+			}
+#if 0
+			/*
+			 * The closest encloser may be the zone name.
+			 */
+			if (closest != NULL &&
+			    dns_name_countlabels(closest) == 0 &&
+			    !dns_nsec3_typepresent(&rdata, dns_rdatatype_ds) &&
+			    !dns_nsec3_typepresent(&rdata, dns_rdatatype_dname) &&
+			    (dns_nsec3_typepresent(&rdata, dns_rdatatype_soa) ||
+			     !dns_nsec3_typepresent(&rdata, dns_rdatatype_ns)))
+			{
+				char namebuf[DNS_NAME_FORMATSIZE];
+
+				dns_name_format(zone, namebuf,
+						sizeof(namebuf));
+				validator_log(val, ISC_LOG_DEBUG(3),
+					      "NSEC3 potential closest "
+					       "encloser from zone name: '%s'",
+					       namebuf);
+				dns_name_copy(zone, closest, NULL);
+				*setclosest = ISC_TRUE;
+			}
+#endif
+			*exists = ISC_FALSE;
+			*data = ISC_FALSE;
+			if (optout != NULL) {
+				if ((nsec3.flags & DNS_NSEC3FLAG_OPTOUT) != 0)
+					validator_log(val, ISC_LOG_DEBUG(3),
+						      "NSEC3 indicates optout");
+				*optout =
+				    ISC_TF(nsec3.flags & DNS_NSEC3FLAG_OPTOUT);
+			}
+			answer = ISC_R_SUCCESS;
+		}
+
+		qlabels--;
+		if (qlabels > 0)
+			dns_name_split(qname, qlabels, NULL, qname);
+		first = ISC_FALSE;
+	}
+	return (answer);
+}
+
 /*%
  * Callback for when NSEC records have been validated.
  *
- * Looks for NOQNAME and NODATA proofs.
+ * Looks for NOQNAME, NODATA and OPTOUT proofs.
  *
  * Resumes nsecvalidate.
  */
@@ -779,6 +1174,7 @@ authvalidated(isc_task_t *task, isc_event_t *event) {
 	dns_validatorevent_t *devent;
 	dns_validator_t *val;
 	dns_rdataset_t *rdataset;
+	dns_rdataset_t *sigrdataset;
 	isc_boolean_t want_destroy;
 	isc_result_t result;
 	isc_boolean_t exists, data;
@@ -788,6 +1184,7 @@ 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);
@@ -834,11 +1231,18 @@ authvalidated(isc_task_t *task, isc_event_t *event) {
 			}
 			if (!exists) {
 				val->attributes |= VALATTR_FOUNDNOQNAME;
+				val->attributes |= VALATTR_FOUNDCLOSEST;
+				/*
+				 * The NSEC noqname proof also contains
+				 * the closest encloser.
+
+				 */
 				if (NEEDNOQNAME(val))
 					proofs[DNS_VALIDATOR_NOQNAMEPROOF] =
 						devent->name;
 			}
 		}
+
 		result = nsecvalidate(val, ISC_TRUE);
 		if (result != DNS_R_WAIT)
 			validator_done(val, result);
@@ -992,13 +1396,25 @@ view_find(dns_validator_t *val, dns_name_t *name, dns_rdatatype_t type) {
  * the validation process will stall if looping was to occur.
  */
 static inline isc_boolean_t
-check_deadlock(dns_validator_t *val, dns_name_t *name, dns_rdatatype_t type) {
+check_deadlock(dns_validator_t *val, dns_name_t *name, dns_rdatatype_t type,
+	       dns_rdataset_t *rdataset, dns_rdataset_t *sigrdataset)
+{
 	dns_validator_t *parent;
 
 	for (parent = val; parent != NULL; parent = parent->parent) {
 		if (parent->event != NULL &&
 		    parent->event->type == type &&
-		    dns_name_equal(parent->event->name, name))
+		    dns_name_equal(parent->event->name, name) &&
+		    /*
+		     * As NSEC3 records are meta data you sometimes
+		     * need to prove a NSEC3 record which says that
+		     * itself doesn't exist.
+		     */
+		    (parent->event->type != dns_rdatatype_nsec3 ||
+		     rdataset == NULL || sigrdataset == NULL ||
+		     parent->event->message == NULL ||
+		     parent->event->rdataset != NULL ||
+		     parent->event->sigrdataset != NULL))
 		{
 			validator_log(val, ISC_LOG_DEBUG(3),
 				      "continuing validation would lead to "
@@ -1021,7 +1437,7 @@ create_fetch(dns_validator_t *val, dns_name_t *name, dns_rdatatype_t type,
 	if (dns_rdataset_isassociated(&val->fsigrdataset))
 		dns_rdataset_disassociate(&val->fsigrdataset);
 
-	if (check_deadlock(val, name, type))
+	if (check_deadlock(val, name, type, NULL, NULL))
 		return (DNS_R_NOVALIDSIG);
 
 	validator_logcreate(val, name, type, caller, "fetch");
@@ -1044,7 +1460,7 @@ create_validator(dns_validator_t *val, dns_name_t *name, dns_rdatatype_t type,
 {
 	isc_result_t result;
 
-	if (check_deadlock(val, name, type))
+	if (check_deadlock(val, name, type, rdataset, sigrdataset))
 		return (DNS_R_NOVALIDSIG);
 
 	validator_logcreate(val, name, type, caller, "validator");
@@ -1128,7 +1544,7 @@ get_dst_key(dns_validator_t *val, dns_rdata_rrsig_t *siginfo,
 }
 
 /*%
- * Get the key that genertated this signature.
+ * Get the key that generated this signature.
  */
 static isc_result_t
 get_key(dns_validator_t *val, dns_rdata_rrsig_t *siginfo) {
@@ -1141,7 +1557,7 @@ get_key(dns_validator_t *val, dns_rdata_rrsig_t *siginfo) {
 	 * Is the signer name appropriate for this signature?
 	 *
 	 * The signer name must be at the same level as the owner name
-	 * or closer to the the DNS root.
+	 * or closer to the DNS root.
 	 */
 	namereln = dns_name_fullcompare(val->event->name, &siginfo->signer,
 					&order, &nlabels);
@@ -1163,6 +1579,23 @@ get_key(dns_validator_t *val, dns_rdata_rrsig_t *siginfo) {
 		 */
 		if (dns_rdatatype_atparent(val->event->rdataset->type))
 			return (DNS_R_CONTINUE);
+	} else {
+		/*
+		 * SOA and NS RRsets can only be signed by a key with
+		 * the same name.
+		 */
+		if (val->event->rdataset->type == dns_rdatatype_soa ||
+		    val->event->rdataset->type == dns_rdatatype_ns) {
+			const char *typename;
+
+			if (val->event->rdataset->type == dns_rdatatype_soa)
+				typename = "SOA";
+			else
+				typename = "NS";
+			validator_log(val, ISC_LOG_DEBUG(3),
+				      "%s signer mismatch", typename);
+			return (DNS_R_CONTINUE);
+		}
 	}
 
 	/*
@@ -1620,6 +2053,7 @@ dlv_validatezonekey(dns_validator_t *val) {
 				break;
 		}
 		if (result != ISC_R_SUCCESS) {
+			dns_rdataset_disassociate(&trdataset);
 			validator_log(val, ISC_LOG_DEBUG(3),
 				      "no DNSKEY matching DLV");
 			continue;
@@ -1734,6 +2168,10 @@ validatezonekey(dns_validator_t *val) {
 					     &sigrdata);
 			result = dns_rdata_tostruct(&sigrdata, &sig, NULL);
 			RUNTIME_CHECK(result == ISC_R_SUCCESS);
+
+			if (!dns_name_equal(val->event->name, &sig.signer))
+				continue;
+
 			result = dns_keytable_findkeynode(val->keytable,
 							  val->event->name,
 							  sig.algorithm,
@@ -1957,6 +2395,7 @@ validatezonekey(dns_validator_t *val) {
 				break;
 		}
 		if (result != ISC_R_SUCCESS) {
+			dns_rdataset_disassociate(&trdataset);
 			validator_log(val, ISC_LOG_DEBUG(3),
 				      "no DNSKEY matching DS");
 			continue;
@@ -1974,7 +2413,11 @@ validatezonekey(dns_validator_t *val) {
 			if (ds.key_tag != sig.keyid ||
 			    ds.algorithm != sig.algorithm)
 				continue;
-
+			if (!dns_name_equal(val->event->name, &sig.signer)) {
+				validator_log(val, ISC_LOG_DEBUG(3),
+					      "DNSKEY signer mismatch");
+				continue;
+			}
 			dstkey = NULL;
 			result = dns_dnssec_keyfromrdata(val->event->name,
 							 &keyrdata,
@@ -2044,7 +2487,8 @@ start_positive_validation(dns_validator_t *val) {
  * \li	ISC_R_SUCCESS
  */
 static isc_result_t
-checkwildcard(dns_validator_t *val) {
+checkwildcard(dns_validator_t *val, dns_rdatatype_t type, dns_name_t *zonename)
+{
 	dns_name_t *name, *wild;
 	dns_message_t *message = val->event->message;
 	isc_result_t result;
@@ -2052,6 +2496,13 @@ checkwildcard(dns_validator_t *val) {
 	char namebuf[DNS_NAME_FORMATSIZE];
 
 	wild = dns_fixedname_name(&val->wild);
+
+	if (dns_name_countlabels(wild) == 0) {
+		validator_log(val, ISC_LOG_DEBUG(3),
+			      "in checkwildcard: no wildcard to check");
+		return (ISC_R_SUCCESS);
+	}
+
 	dns_name_format(wild, namebuf, sizeof(namebuf));
 	validator_log(val, ISC_LOG_DEBUG(3), "in checkwildcard: %s", namebuf);
 
@@ -2068,9 +2519,8 @@ checkwildcard(dns_validator_t *val) {
 		     rdataset != NULL;
 		     rdataset = ISC_LIST_NEXT(rdataset, link))
 		{
-			if (rdataset->type != dns_rdatatype_nsec)
+			if (rdataset->type != type)
 				continue;
-			val->nsecset = rdataset;
 
 			for (sigrdataset = ISC_LIST_HEAD(name->list);
 			     sigrdataset != NULL;
@@ -2086,7 +2536,8 @@ checkwildcard(dns_validator_t *val) {
 			if (rdataset->trust != dns_trust_secure)
 				continue;
 
-			if (((val->attributes & VALATTR_NEEDNODATA) != 0 ||
+			if (rdataset->type == dns_rdatatype_nsec &&
+			    ((val->attributes & VALATTR_NEEDNODATA) != 0 ||
 			     (val->attributes & VALATTR_NEEDNOWILDCARD) != 0) &&
 			    (val->attributes & VALATTR_FOUNDNODATA) == 0 &&
 			    (val->attributes & VALATTR_FOUNDNOWILDCARD) == 0 &&
@@ -2108,6 +2559,31 @@ checkwildcard(dns_validator_t *val) {
 							 name;
 				return (ISC_R_SUCCESS);
 			}
+
+			if (rdataset->type == dns_rdatatype_nsec3 &&
+			    ((val->attributes & VALATTR_NEEDNODATA) != 0 ||
+			     (val->attributes & VALATTR_NEEDNOWILDCARD) != 0) &&
+			    (val->attributes & VALATTR_FOUNDNODATA) == 0 &&
+			    (val->attributes & VALATTR_FOUNDNOWILDCARD) == 0 &&
+			    nsec3noexistnodata(val, wild, name, rdataset,
+					       zonename, &exists, &data,
+					       NULL, NULL, NULL, NULL, NULL,
+					       NULL) == ISC_R_SUCCESS)
+			{
+				dns_name_t **proofs = val->event->proofs;
+				if (exists && !data)
+					val->attributes |= VALATTR_FOUNDNODATA;
+				if (exists && !data && NEEDNODATA(val))
+					proofs[DNS_VALIDATOR_NODATAPROOF] =
+							 name;
+				if (!exists)
+					val->attributes |=
+						 VALATTR_FOUNDNOWILDCARD;
+				if (!exists && NEEDNOQNAME(val))
+					proofs[DNS_VALIDATOR_NOWILDCARDPROOF] =
+							 name;
+				return (ISC_R_SUCCESS);
+			}
 		}
 	}
 	if (result == ISC_R_NOMORE)
@@ -2115,6 +2591,170 @@ checkwildcard(dns_validator_t *val) {
 	return (result);
 }
 
+
+static isc_result_t
+findnsec3proofs(dns_validator_t *val) {
+	dns_name_t *name;
+	dns_message_t *message = val->event->message;
+	isc_result_t result;
+	isc_boolean_t exists, data, optout, unknown;
+	isc_boolean_t setclosest, setnearest;
+	dns_fixedname_t fclosest, fnearest, fzonename;
+	dns_name_t *closest, *nearest, *zonename;
+	dns_name_t **proofs = val->event->proofs;
+
+	dns_fixedname_init(&fclosest);
+	dns_fixedname_init(&fnearest);
+	dns_fixedname_init(&fzonename);
+	closest = dns_fixedname_name(&fclosest);
+	nearest = dns_fixedname_name(&fnearest);
+	zonename = dns_fixedname_name(&fzonename);
+
+	for (result = dns_message_firstname(message, DNS_SECTION_AUTHORITY);
+	     result == ISC_R_SUCCESS;
+	     result = dns_message_nextname(message, DNS_SECTION_AUTHORITY))
+	{
+		dns_rdataset_t *rdataset = NULL, *sigrdataset = NULL;
+
+		name = NULL;
+		dns_message_currentname(message, DNS_SECTION_AUTHORITY, &name);
+
+		for (rdataset = ISC_LIST_HEAD(name->list);
+		     rdataset != NULL;
+		     rdataset = ISC_LIST_NEXT(rdataset, link))
+		{
+			if (rdataset->type != dns_rdatatype_nsec3)
+				continue;
+
+			for (sigrdataset = ISC_LIST_HEAD(name->list);
+			     sigrdataset != NULL;
+			     sigrdataset = ISC_LIST_NEXT(sigrdataset, link))
+			{
+				if (sigrdataset->type == dns_rdatatype_rrsig &&
+				    sigrdataset->covers == dns_rdatatype_nsec3)
+					break;
+			}
+			if (sigrdataset == NULL)
+				continue;
+
+			if (rdataset->trust != dns_trust_secure)
+				continue;
+
+			result = nsec3noexistnodata(val, val->event->name,
+						    name, rdataset,
+						    zonename, NULL, NULL, NULL,
+						    NULL, NULL, NULL, NULL,
+						    NULL);
+			if (result != ISC_R_IGNORE && result != ISC_R_SUCCESS)
+				return (result);
+		}
+	}
+	if (result != ISC_R_NOMORE)
+		result = ISC_R_SUCCESS;
+
+	if (dns_name_countlabels(zonename) == 0)
+		return (ISC_R_SUCCESS);
+
+	for (result = dns_message_firstname(message, DNS_SECTION_AUTHORITY);
+	     result == ISC_R_SUCCESS;
+	     result = dns_message_nextname(message, DNS_SECTION_AUTHORITY))
+	{
+		dns_rdataset_t *rdataset = NULL, *sigrdataset = NULL;
+
+		name = NULL;
+		dns_message_currentname(message, DNS_SECTION_AUTHORITY, &name);
+
+		for (rdataset = ISC_LIST_HEAD(name->list);
+		     rdataset != NULL;
+		     rdataset = ISC_LIST_NEXT(rdataset, link))
+		{
+			if (rdataset->type != dns_rdatatype_nsec3)
+				continue;
+
+			for (sigrdataset = ISC_LIST_HEAD(name->list);
+			     sigrdataset != NULL;
+			     sigrdataset = ISC_LIST_NEXT(sigrdataset, link))
+			{
+				if (sigrdataset->type == dns_rdatatype_rrsig &&
+				    sigrdataset->covers == dns_rdatatype_nsec3)
+					break;
+			}
+			if (sigrdataset == NULL)
+				continue;
+
+			if (rdataset->trust != dns_trust_secure)
+				continue;
+
+			/*
+			 * We process all NSEC3 records to find the closest
+			 * encloser and nearest name to the closest encloser.
+			 */
+			setclosest = setnearest = ISC_FALSE;
+			optout = ISC_FALSE;
+			unknown = ISC_FALSE;
+			result = nsec3noexistnodata(val, val->event->name,
+						    name, rdataset,
+						    zonename, &exists,
+						    &data, &optout, &unknown,
+						    &setclosest, &setnearest,
+						    closest, nearest);
+			if (setclosest)
+				proofs[DNS_VALIDATOR_CLOSESTENCLOSER] = name;
+			if (unknown)
+				val->attributes |= VALATTR_FOUNDUNKNOWN;
+			if (result != ISC_R_SUCCESS)
+				continue;
+			if (exists && !data && NEEDNODATA(val)) {
+				val->attributes |= VALATTR_FOUNDNODATA;
+				proofs[DNS_VALIDATOR_NODATAPROOF] = name;
+			}
+			if (!exists && setnearest) {
+				val->attributes |= VALATTR_FOUNDNOQNAME;
+				proofs[DNS_VALIDATOR_NOQNAMEPROOF] = name;
+				if (optout)
+					val->attributes |= VALATTR_FOUNDOPTOUT;
+			}
+		}
+	}
+	if (result != ISC_R_NOMORE)
+		result = ISC_R_SUCCESS;
+
+	/*
+	 * To know we have a valid noqname and optout proofs we need to also
+	 * have a valid closest encloser.  Otherwise we could still be looking
+	 * at proofs from the parent zone.
+	 */
+	if (dns_name_countlabels(closest) > 0 &&
+	    dns_name_countlabels(nearest) ==
+	    dns_name_countlabels(closest) + 1 &&
+	    dns_name_issubdomain(nearest, closest))
+	{
+		val->attributes |= VALATTR_FOUNDCLOSEST;
+		result = dns_name_concatenate(dns_wildcardname, closest,
+					      dns_fixedname_name(&val->wild),
+					      NULL);
+		RUNTIME_CHECK(result == ISC_R_SUCCESS);
+	} else {
+		val->attributes &= ~VALATTR_FOUNDNOQNAME;
+		val->attributes &= ~VALATTR_FOUNDOPTOUT;
+		proofs[DNS_VALIDATOR_NOQNAMEPROOF] = NULL;
+	}
+
+	/*
+	 * Do we need to check for the wildcard?
+	 */
+	if ((val->attributes & VALATTR_FOUNDNOQNAME) != 0 &&
+	    (val->attributes & VALATTR_FOUNDCLOSEST) != 0 &&
+	    (((val->attributes & VALATTR_NEEDNODATA) != 0 &&
+	      (val->attributes & VALATTR_FOUNDNODATA) == 0) ||
+	     (val->attributes & VALATTR_NEEDNOWILDCARD) != 0)) {
+		result = checkwildcard(val, dns_rdatatype_nsec3, zonename);
+		if (result != ISC_R_SUCCESS)
+			return (result);
+	}
+	return (result);
+}
+
 /*%
  * Prove a negative answer is good or that there is a NOQNAME when the
  * answer is from a wildcard.
@@ -2220,7 +2860,10 @@ nsecvalidate(dns_validator_t *val, isc_boolean_t resume) {
 	if ((val->attributes & VALATTR_NEEDNODATA) == 0 &&
 	    (val->attributes & VALATTR_NEEDNOWILDCARD) == 0 &&
 	    (val->attributes & VALATTR_NEEDNOQNAME) != 0) {
-		if ((val->attributes & VALATTR_FOUNDNOQNAME) != 0) {
+		if ((val->attributes & VALATTR_FOUNDNOQNAME) == 0)
+			findnsec3proofs(val);
+		if ((val->attributes & VALATTR_FOUNDNOQNAME) != 0 &&
+		    (val->attributes & VALATTR_FOUNDCLOSEST) != 0) {
 			validator_log(val, ISC_LOG_DEBUG(3),
 				      "noqname proof found");
 			validator_log(val, ISC_LOG_DEBUG(3),
@@ -2228,34 +2871,57 @@ nsecvalidate(dns_validator_t *val, isc_boolean_t resume) {
 			val->event->rdataset->trust = dns_trust_secure;
 			val->event->sigrdataset->trust = dns_trust_secure;
 			return (ISC_R_SUCCESS);
+		} else if ((val->attributes & VALATTR_FOUNDOPTOUT) != 0 &&
+			   dns_name_countlabels(dns_fixedname_name(&val->wild))
+					 != 0) {
+			validator_log(val, ISC_LOG_DEBUG(3),
+				      "optout proof found");
+			val->event->optout = ISC_TRUE;
+			markanswer(val);
+			return (ISC_R_SUCCESS);
+		} else if ((val->attributes & VALATTR_FOUNDUNKNOWN) != 0) {
+			validator_log(val, ISC_LOG_DEBUG(3),
+				      "unknown NSEC3 hash algorithm found");
+			markanswer(val);
+			return (ISC_R_SUCCESS);
 		}
 		validator_log(val, ISC_LOG_DEBUG(3),
 			      "noqname proof not found");
 		return (DNS_R_NOVALIDNSEC);
 	}
 
+	if ((val->attributes & VALATTR_FOUNDNOQNAME) == 0 &&
+	    (val->attributes & VALATTR_FOUNDNODATA) == 0)
+		findnsec3proofs(val);
+
 	/*
 	 * Do we need to check for the wildcard?
 	 */
 	if ((val->attributes & VALATTR_FOUNDNOQNAME) != 0 &&
+	    (val->attributes & VALATTR_FOUNDCLOSEST) != 0 &&
 	    (((val->attributes & VALATTR_NEEDNODATA) != 0 &&
 	      (val->attributes & VALATTR_FOUNDNODATA) == 0) ||
 	     (val->attributes & VALATTR_NEEDNOWILDCARD) != 0)) {
-		result = checkwildcard(val);
+		result = checkwildcard(val, dns_rdatatype_nsec, NULL);
 		if (result != ISC_R_SUCCESS)
 			return (result);
 	}
 
 	if (((val->attributes & VALATTR_NEEDNODATA) != 0 &&
-	     (val->attributes & VALATTR_FOUNDNODATA) != 0) ||
+	     ((val->attributes & VALATTR_FOUNDNODATA) != 0 ||
+	      (val->attributes & VALATTR_FOUNDOPTOUT) != 0)) ||
 	    ((val->attributes & VALATTR_NEEDNOQNAME) != 0 &&
 	     (val->attributes & VALATTR_FOUNDNOQNAME) != 0 &&
 	     (val->attributes & VALATTR_NEEDNOWILDCARD) != 0 &&
-	     (val->attributes & VALATTR_FOUNDNOWILDCARD) != 0)) {
+	     (val->attributes & VALATTR_FOUNDNOWILDCARD) != 0 &&
+	     (val->attributes & VALATTR_FOUNDCLOSEST) != 0)) {
+		if ((val->attributes & VALATTR_FOUNDOPTOUT) != 0)
+			val->event->optout = ISC_TRUE;
 		validator_log(val, ISC_LOG_DEBUG(3),
 			      "nonexistence proof(s) found");
 		return (ISC_R_SUCCESS);
 	}
+		findnsec3proofs(val);
 
 	validator_log(val, ISC_LOG_DEBUG(3),
 		      "nonexistence proof(s) not found");
@@ -2380,7 +3046,7 @@ dlvfetched(isc_task_t *task, isc_event_t *event) {
 }
 
 /*%
- * Start the DLV lookup proccess.
+ * Start the DLV lookup process.
  *
  * Returns
  * \li	ISC_R_SUCCESS
@@ -2424,7 +3090,7 @@ startfinddlvsep(dns_validator_t *val, dns_name_t *unsecure) {
 		validator_log(val, ISC_LOG_DEBUG(3), "DLV %s found", namebuf);
 		dlv_validator_start(val);
 		return (DNS_R_WAIT);
-	} 
+	}
 	validator_log(val, ISC_LOG_DEBUG(3), "DLV %s found with no supported "
 		      "algorithms", namebuf);
 	markanswer(val);
@@ -2566,9 +3232,13 @@ proveunsecure(dns_validator_t *val, isc_boolean_t have_ds, isc_boolean_t resume)
 	dns_name_t *secroot;
 	dns_name_t *tname;
 	char namebuf[DNS_NAME_FORMATSIZE];
+	dns_name_t *found;
+	dns_fixedname_t fixedfound;
 
 	dns_fixedname_init(&fixedsecroot);
 	secroot = dns_fixedname_name(&fixedsecroot);
+	dns_fixedname_init(&fixedfound);
+	found = dns_fixedname_name(&fixedfound);
 	if (val->havedlvsep)
 		dns_name_copy(dns_fixedname_name(&val->dlvsep), secroot, NULL);
 	else {
@@ -2676,6 +3346,28 @@ proveunsecure(dns_validator_t *val, isc_boolean_t have_ds, isc_boolean_t resume)
 					goto out;
 				return (DNS_R_WAIT);
 			}
+			/*
+			 * Zones using NSEC3 don't return a NSEC RRset so
+			 * we need to use dns_view_findzonecut2 to find
+			 * the zone cut.
+			 */
+			if (result == DNS_R_NXRRSET &&
+			    !dns_rdataset_isassociated(&val->frdataset) &&
+			    dns_view_findzonecut2(val->view, tname, found,
+						  0, 0, ISC_FALSE, ISC_FALSE,
+						  NULL, NULL) == ISC_R_SUCCESS &&
+			    dns_name_equal(tname, found)) {
+				if (val->mustbesecure) {
+					validator_log(val, ISC_LOG_WARNING,
+						      "must be secure failure");
+					return (DNS_R_MUSTBESECURE);
+				}
+				if (val->view->dlv == NULL || DLVTRIED(val)) {
+					markanswer(val);
+					return (ISC_R_SUCCESS);
+				}
+				return (startfinddlvsep(val, tname));
+			}
 			if (val->frdataset.trust < dns_trust_secure) {
 				/*
 				 * This shouldn't happen, since the negative
@@ -2775,6 +3467,15 @@ proveunsecure(dns_validator_t *val, isc_boolean_t have_ds, isc_boolean_t resume)
 			return (DNS_R_WAIT);
 		}
 	}
+
+/*
+	if ((val->attributes & VALATTR_NEEDOPTOUT) == 0 &&
+	    val->event->message != NULL) {
+		val->attributes |= VALATTR_NEEDOPTOUT;
+		return (nsecvalidate(val, ISC_FALSE));
+	}
+*/
+
 	validator_log(val, ISC_LOG_DEBUG(3), "insecurity proof failed");
 	return (DNS_R_NOTINSECURE); /* Couldn't complete insecurity proof */
 
@@ -2808,7 +3509,7 @@ dlv_validator_start(dns_validator_t *val) {
 /*%
  * Start the validation process.
  *
- * Attempt to valididate the answer based on the category it appears to
+ * Attempt to validate the answer based on the category it appears to
  * fall in.
  * \li	1. secure positive answer.
  * \li	2. unsecure positive answer.
@@ -2829,7 +3530,7 @@ validator_start(isc_task_t *task, isc_event_t *event) {
 	vevent = (dns_validatorevent_t *)event;
 	val = vevent->validator;
 
-	/* If the validator has been cancelled, val->event == NULL */
+	/* If the validator has been canceled, val->event == NULL */
 	if (val->event == NULL)
 		return;
 
@@ -2955,6 +3656,7 @@ dns_validator_create(dns_view_t *view, dns_name_t *name, dns_rdatatype_t type,
 	event->sigrdataset = sigrdataset;
 	event->message = message;
 	memset(event->proofs, 0, sizeof(event->proofs));
+	event->optout = ISC_FALSE;
 	result = isc_mutex_init(&val->lock);
 	if (result != ISC_R_SUCCESS)
 		goto cleanup_event;
@@ -2984,6 +3686,8 @@ dns_validator_create(dns_view_t *view, dns_name_t *name, dns_rdatatype_t type,
 	dns_rdataset_init(&val->frdataset);
 	dns_rdataset_init(&val->fsigrdataset);
 	dns_fixedname_init(&val->wild);
+	dns_fixedname_init(&val->nearest);
+	dns_fixedname_init(&val->closest);
 	ISC_LINK_INIT(val, link);
 	val->magic = VALIDATOR_MAGIC;
 
diff --git a/contrib/bind9/lib/dns/version.c b/contrib/bind9/lib/dns/version.c
index 1c03774..fbc8889 100644
--- a/contrib/bind9/lib/dns/version.c
+++ b/contrib/bind9/lib/dns/version.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: version.c,v 1.11.18.2 2005/04/29 00:16:07 marka Exp $ */
+/* $Id: version.c,v 1.15 2007/06/19 23:47:16 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/dns/view.c b/contrib/bind9/lib/dns/view.c
index 4851cf0..5f1447a 100644
--- a/contrib/bind9/lib/dns/view.c
+++ b/contrib/bind9/lib/dns/view.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,15 +15,16 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: view.c,v 1.126.18.16 2008/06/17 23:46:03 tbox Exp $ */
+/* $Id: view.c,v 1.150.84.2 2009/01/29 23:47:44 tbox Exp $ */
 
 /*! \file */
 
 #include <config.h>
 
 #include <isc/hash.h>
-#include <isc/task.h>
+#include <isc/stats.h>
 #include <isc/string.h>		/* Required for HP/UX (and others?) */
+#include <isc/task.h>
 #include <isc/util.h>
 
 #include <dns/acache.h>
@@ -43,6 +44,7 @@
 #include <dns/request.h>
 #include <dns/resolver.h>
 #include <dns/result.h>
+#include <dns/stats.h>
 #include <dns/tsig.h>
 #include <dns/zone.h>
 #include <dns/zt.h>
@@ -151,6 +153,8 @@ dns_view_create(isc_mem_t *mctx, dns_rdataclass_t rdclass,
 	view->delonly = NULL;
 	view->rootdelonly = ISC_FALSE;
 	view->rootexclude = NULL;
+	view->resstats = NULL;
+	view->resquerystats = NULL;
 
 	/*
 	 * Initialize configuration data with default values.
@@ -165,8 +169,14 @@ dns_view_create(isc_mem_t *mctx, dns_rdataclass_t rdclass,
 	view->minimalresponses = ISC_FALSE;
 	view->transfer_format = dns_one_answer;
 	view->queryacl = NULL;
+	view->queryonacl = NULL;
 	view->recursionacl = NULL;
+	view->recursiononacl = NULL;
 	view->sortlist = NULL;
+	view->transferacl = NULL;
+	view->notifyacl = NULL;
+	view->updateacl = NULL;
+	view->upfwdacl = NULL;
 	view->requestixfr = ISC_TRUE;
 	view->provideixfr = ISC_TRUE;
 	view->maxcachettl = 7 * 24 * 3600;
@@ -286,10 +296,22 @@ destroy(dns_view_t *view) {
 		dns_acl_detach(&view->matchdestinations);
 	if (view->queryacl != NULL)
 		dns_acl_detach(&view->queryacl);
+	if (view->queryonacl != NULL)
+		dns_acl_detach(&view->queryonacl);
 	if (view->recursionacl != NULL)
 		dns_acl_detach(&view->recursionacl);
+	if (view->recursiononacl != NULL)
+		dns_acl_detach(&view->recursiononacl);
 	if (view->sortlist != NULL)
 		dns_acl_detach(&view->sortlist);
+	if (view->transferacl != NULL)
+		dns_acl_detach(&view->transferacl);
+	if (view->notifyacl != NULL)
+		dns_acl_detach(&view->notifyacl);
+	if (view->updateacl != NULL)
+		dns_acl_detach(&view->updateacl);
+	if (view->upfwdacl != NULL)
+		dns_acl_detach(&view->upfwdacl);
 	if (view->delonly != NULL) {
 		dns_name_t *name;
 		int i;
@@ -325,6 +347,10 @@ destroy(dns_view_t *view) {
 			    sizeof(dns_namelist_t) * DNS_VIEW_DELONLYHASH);
 		view->rootexclude = NULL;
 	}
+	if (view->resstats != NULL)
+		isc_stats_detach(&view->resstats);
+	if (view->resquerystats != NULL)
+		dns_stats_detach(&view->resquerystats);
 	dns_keytable_detach(&view->trustedkeys);
 	dns_keytable_detach(&view->secroots);
 	dns_fwdtable_destroy(&view->fwdtable);
@@ -571,6 +597,7 @@ dns_view_createresolver(dns_view_t *view,
 	}
 
 	result = dns_adb_create(mctx, view, timermgr, taskmgr, &view->adb);
+	isc_mem_setname(mctx, "ADB", NULL);
 	isc_mem_detach(&mctx);
 	if (result != ISC_R_SUCCESS) {
 		dns_resolver_shutdown(view->resolver);
@@ -1129,6 +1156,55 @@ dns_viewlist_find(dns_viewlist_t *list, const char *name,
 }
 
 isc_result_t
+dns_viewlist_findzone(dns_viewlist_t *list, dns_name_t *name,
+		      isc_boolean_t allclasses, dns_rdataclass_t rdclass,
+		      dns_zone_t **zonep)
+{
+	dns_view_t *view;
+	isc_result_t result;
+	dns_zone_t *zone1 = NULL, *zone2 = NULL;
+	dns_zone_t **zp = NULL;;
+
+	REQUIRE(list != NULL);
+	for (view = ISC_LIST_HEAD(*list);
+	     view != NULL;
+	     view = ISC_LIST_NEXT(view, link)) {
+		if (allclasses == ISC_FALSE && view->rdclass != rdclass)
+			continue;
+
+		/*
+		 * If the zone is defined in more than one view,
+		 * treat it as not found.
+		 */
+		zp = (zone1 == NULL) ? &zone1 : &zone2;
+		result = dns_zt_find(view->zonetable, name, 0, NULL, zp);
+		INSIST(result == ISC_R_SUCCESS ||
+		       result == ISC_R_NOTFOUND ||
+		       result == DNS_R_PARTIALMATCH);
+
+		/* Treat a partial match as no match */
+		if (result == DNS_R_PARTIALMATCH) {
+			dns_zone_detach(zp);
+			result = ISC_R_NOTFOUND;
+		}
+
+		if (zone2 != NULL) {
+			dns_zone_detach(&zone1);
+			dns_zone_detach(&zone2);
+			return (ISC_R_NOTFOUND);
+		}
+	}
+
+	if (zone1 != NULL) {
+		dns_zone_attach(zone1, zonep);
+		dns_zone_detach(&zone1);
+		return (ISC_R_SUCCESS);
+	}
+
+	return (ISC_R_NOTFOUND);
+}
+
+isc_result_t
 dns_view_load(dns_view_t *view, isc_boolean_t stop) {
 
 	REQUIRE(DNS_VIEW_VALID(view));
@@ -1354,3 +1430,39 @@ dns_view_freezezones(dns_view_t *view, isc_boolean_t value) {
 	REQUIRE(DNS_VIEW_VALID(view));
 	return (dns_zt_freezezones(view->zonetable, value));
 }
+
+void
+dns_view_setresstats(dns_view_t *view, isc_stats_t *stats) {
+	REQUIRE(DNS_VIEW_VALID(view));
+	REQUIRE(!view->frozen);
+	REQUIRE(view->resstats == NULL);
+
+	isc_stats_attach(stats, &view->resstats);
+}
+
+void
+dns_view_getresstats(dns_view_t *view, isc_stats_t **statsp) {
+	REQUIRE(DNS_VIEW_VALID(view));
+	REQUIRE(statsp != NULL && *statsp == NULL);
+
+	if (view->resstats != NULL)
+		isc_stats_attach(view->resstats, statsp);
+}
+
+void
+dns_view_setresquerystats(dns_view_t *view, dns_stats_t *stats) {
+	REQUIRE(DNS_VIEW_VALID(view));
+	REQUIRE(!view->frozen);
+	REQUIRE(view->resquerystats == NULL);
+
+	dns_stats_attach(stats, &view->resquerystats);
+}
+
+void
+dns_view_getresquerystats(dns_view_t *view, dns_stats_t **statsp) {
+	REQUIRE(DNS_VIEW_VALID(view));
+	REQUIRE(statsp != NULL && *statsp == NULL);
+
+	if (view->resquerystats != NULL)
+		dns_stats_attach(view->resquerystats, statsp);
+}
diff --git a/contrib/bind9/lib/dns/xfrin.c b/contrib/bind9/lib/dns/xfrin.c
index 7171a37..4e3d2c3 100644
--- a/contrib/bind9/lib/dns/xfrin.c
+++ b/contrib/bind9/lib/dns/xfrin.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: xfrin.c,v 1.135.18.23 2008/09/25 04:15:52 marka Exp $ */
+/* $Id: xfrin.c,v 1.166 2008/09/25 04:12:39 marka Exp $ */
 
 /*! \file */
 
@@ -142,6 +142,11 @@ struct dns_xfrin_ctx {
 	isc_boolean_t 		is_ixfr;
 
 	unsigned int		nmsg;		/*%< Number of messages recvd */
+	unsigned int		nrecs;		/*%< Number of records recvd */
+	isc_uint64_t		nbytes;		/*%< Number of bytes received */
+
+	isc_time_t		start;		/*%< Start time of the transfer */
+	isc_time_t		end;		/*%< End time of the transfer */
 
 	dns_tsigkey_t		*tsigkey;	/*%< Key used to create TSIG */
 	isc_buffer_t		*lasttsig;	/*%< The last TSIG */
@@ -426,6 +431,8 @@ xfr_rr(dns_xfrin_ctx_t *xfr, dns_name_t *name, isc_uint32_t ttl,
 {
 	isc_result_t result;
 
+	xfr->nrecs++;
+
 	if (rdata->type == dns_rdatatype_none ||
 	    dns_rdatatype_ismeta(rdata->type))
 		FAIL(DNS_R_FORMERR);
@@ -804,6 +811,9 @@ xfrin_create(isc_mem_t *mctx,
 	/* end_serial */
 
 	xfr->nmsg = 0;
+	xfr->nrecs = 0;
+	xfr->nbytes = 0;
+	isc_time_now(&xfr->start);
 
 	xfr->tsigkey = NULL;
 	if (tsigkey != NULL)
@@ -865,6 +875,7 @@ xfrin_start(dns_xfrin_ctx_t *xfr) {
 				isc_sockaddr_pf(&xfr->sourceaddr),
 				isc_sockettype_tcp,
 				&xfr->socket));
+	isc_socket_setname(xfr->socket, "xfrin", NULL);
 #ifndef BROKEN_TCP_BIND_BEFORE_CONNECT
 	CHECK(isc_socket_bind(xfr->socket, &xfr->sourceaddr,
 			      ISC_SOCKET_REUSEADDRESS));
@@ -908,8 +919,7 @@ static void
 xfrin_connect_done(isc_task_t *task, isc_event_t *event) {
 	isc_socket_connev_t *cev = (isc_socket_connev_t *) event;
 	dns_xfrin_ctx_t *xfr = (dns_xfrin_ctx_t *) event->ev_arg;
-	isc_result_t evresult = cev->result;
-	isc_result_t result;
+	isc_result_t result = cev->result;
 	char sourcetext[ISC_SOCKADDR_FORMATSIZE];
 	isc_sockaddr_t sockaddr;
 
@@ -926,7 +936,18 @@ xfrin_connect_done(isc_task_t *task, isc_event_t *event) {
 		return;
 	}
 
-	CHECK(evresult);
+	if (result != ISC_R_SUCCESS) {
+		dns_zonemgr_t * zmgr = dns_zone_getmgr(xfr->zone);
+		isc_time_t now;
+
+		if (zmgr != NULL) {
+			TIME_NOW(&now);
+			dns_zonemgr_unreachableadd(zmgr, &xfr->masteraddr,
+						   &xfr->sourceaddr, &now);
+		}
+		goto failure;
+	}
+
 	result = isc_socket_getsockname(xfr->socket, &sockaddr);
 	if (result == ISC_R_SUCCESS) {
 		isc_sockaddr_format(&sockaddr, sourcetext, sizeof(sourcetext));
@@ -1054,6 +1075,9 @@ xfrin_send_request(dns_xfrin_ctx_t *xfr) {
 	xfr->checkid = ISC_TRUE;
 	xfr->id++;
 	xfr->nmsg = 0;
+	xfr->nrecs = 0;
+	xfr->nbytes = 0;
+	isc_time_now(&xfr->start);
 	msg->id = xfr->id;
 	if (xfr->tsigctx != NULL)
 		dst_context_destroy(&xfr->tsigctx);
@@ -1308,6 +1332,11 @@ xfrin_recv_done(isc_task_t *task, isc_event_t *ev) {
 	xfr->nmsg++;
 
 	/*
+	 * Update the number of bytes received.
+	 */
+	xfr->nbytes += tcpmsg->buffer.used;
+
+	/*
 	 * Take the context back.
 	 */
 	INSIST(xfr->tsigctx == NULL);
@@ -1373,6 +1402,9 @@ xfrin_timeout(isc_task_t *task, isc_event_t *event) {
 
 static void
 maybe_free(dns_xfrin_ctx_t *xfr) {
+	isc_uint64_t msecs;
+	isc_uint64_t persec;
+
 	REQUIRE(VALID_XFRIN(xfr));
 
 	if (! xfr->shuttingdown || xfr->refcount != 0 ||
@@ -1380,7 +1412,22 @@ maybe_free(dns_xfrin_ctx_t *xfr) {
 	    xfr->recvs != 0)
 		return;
 
-	xfrin_log(xfr, ISC_LOG_INFO, "end of transfer");
+	/*
+	 * Calculate the length of time the transfer took,
+	 * and print a log message with the bytes and rate.
+	 */
+	isc_time_now(&xfr->end);
+	msecs = isc_time_microdiff(&xfr->end, &xfr->start) / 1000;
+	if (msecs == 0)
+		msecs = 1;
+	persec = (xfr->nbytes * 1000) / msecs;
+	xfrin_log(xfr, ISC_LOG_INFO,
+		  "Transfer completed: %d messages, %d records, "
+		  "%" ISC_PRINT_QUADFORMAT "u bytes, "
+		  "%u.%03u secs (%u bytes/sec)",
+		  xfr->nmsg, xfr->nrecs, xfr->nbytes,
+		  (unsigned int) (msecs / 1000), (unsigned int) (msecs % 1000),
+		  (unsigned int) persec);
 
 	if (xfr->socket != NULL)
 		isc_socket_detach(&xfr->socket);
diff --git a/contrib/bind9/lib/dns/zone.c b/contrib/bind9/lib/dns/zone.c
index 36f303c..423b005 100644
--- a/contrib/bind9/lib/dns/zone.c
+++ b/contrib/bind9/lib/dns/zone.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,11 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: zone.c,v 1.410.18.55 2008/10/24 01:43:17 tbox Exp $ */
+/* $Id: zone.c,v 1.483.36.6 2009/03/26 22:57:07 marka Exp $ */
 
 /*! \file */
 
 #include <config.h>
+#include <errno.h>
 
 #include <isc/file.h>
 #include <isc/mutex.h>
@@ -29,6 +30,9 @@
 #include <isc/refcount.h>
 #include <isc/rwlock.h>
 #include <isc/serial.h>
+#include <isc/strerror.h>
+#include <isc/stats.h>
+#include <isc/stdtime.h>
 #include <isc/string.h>
 #include <isc/taskpool.h>
 #include <isc/timer.h>
@@ -40,29 +44,37 @@
 #include <dns/callbacks.h>
 #include <dns/db.h>
 #include <dns/dbiterator.h>
+#include <dns/dnssec.h>
 #include <dns/events.h>
 #include <dns/journal.h>
+#include <dns/keyvalues.h>
 #include <dns/log.h>
 #include <dns/master.h>
 #include <dns/masterdump.h>
 #include <dns/message.h>
 #include <dns/name.h>
+#include <dns/nsec.h>
+#include <dns/nsec3.h>
 #include <dns/peer.h>
 #include <dns/rcode.h>
 #include <dns/rdataclass.h>
 #include <dns/rdatalist.h>
 #include <dns/rdataset.h>
+#include <dns/rdatasetiter.h>
 #include <dns/rdatastruct.h>
 #include <dns/rdatatype.h>
 #include <dns/request.h>
 #include <dns/resolver.h>
 #include <dns/result.h>
-#include <dns/stats.h>
+#include <dns/soa.h>
 #include <dns/ssu.h>
+#include <dns/stats.h>
 #include <dns/tsig.h>
 #include <dns/xfrin.h>
 #include <dns/zone.h>
 
+#include <dst/dst.h>
+
 #define ZONE_MAGIC			ISC_MAGIC('Z', 'O', 'N', 'E')
 #define DNS_ZONE_VALID(zone)		ISC_MAGIC_VALID(zone, ZONE_MAGIC)
 
@@ -90,6 +102,8 @@
 #define RANGE(a, min, max) \
 		(((a) < (min)) ? (min) : ((a) < (max) ? (a) : (max)))
 
+#define NSEC3REMOVE(x) (((x) & DNS_NSEC3FLAG_REMOVE) != 0)
+
 /*
  * Default values.
  */
@@ -111,6 +125,10 @@ typedef struct dns_load dns_load_t;
 typedef struct dns_forward dns_forward_t;
 typedef struct dns_io dns_io_t;
 typedef ISC_LIST(dns_io_t) dns_iolist_t;
+typedef struct dns_signing dns_signing_t;
+typedef ISC_LIST(dns_signing_t) dns_signinglist_t;
+typedef struct dns_nsec3chain dns_nsec3chain_t;
+typedef ISC_LIST(dns_nsec3chain_t) dns_nsec3chainlist_t;
 
 #define DNS_ZONE_CHECKLOCK
 #ifdef DNS_ZONE_CHECKLOCK
@@ -178,11 +196,16 @@ struct dns_zone {
 	isc_time_t		dumptime;
 	isc_time_t		loadtime;
 	isc_time_t		notifytime;
+	isc_time_t		resigntime;
+	isc_time_t		keywarntime;
+	isc_time_t		signingtime;
+	isc_time_t		nsec3chaintime;
 	isc_uint32_t		serial;
 	isc_uint32_t		refresh;
 	isc_uint32_t		retry;
 	isc_uint32_t		expire;
 	isc_uint32_t		minimum;
+	isc_stdtime_t		key_expiry;
 	char			*keydirectory;
 
 	isc_uint32_t		maxrefresh;
@@ -215,6 +238,7 @@ struct dns_zone {
 	dns_acl_t		*forward_acl;
 	dns_acl_t		*notify_acl;
 	dns_acl_t		*query_acl;
+	dns_acl_t		*queryon_acl;
 	dns_acl_t		*xfr_acl;
 	isc_boolean_t		update_disabled;
 	isc_boolean_t		zero_no_soa_ttl;
@@ -232,6 +256,7 @@ struct dns_zone {
 	isc_event_t		ctlevent;
 	dns_ssutable_t		*ssutable;
 	isc_uint32_t		sigvalidityinterval;
+	isc_uint32_t		sigresigninginterval;
 	dns_view_t		*view;
 	dns_acache_t		*acache;
 	dns_checkmxfunc_t	checkmx;
@@ -247,17 +272,39 @@ struct dns_zone {
 	ISC_LINK(dns_zone_t)	statelink;
 	dns_zonelist_t		*statelist;
 	/*%
-	 * Optional per-zone statistics counters (NULL if not present).
+	 * Statistics counters about zone management.
 	 */
-	isc_uint64_t	    	*counters;
+	isc_stats_t	    	*stats;
+	/*%
+	 * Optional per-zone statistics counters.  Counted outside of this
+	 * module.
+	 */
+	isc_boolean_t	    	requeststats_on;
+	isc_stats_t	    	*requeststats;
 	isc_uint32_t		notifydelay;
 	dns_isselffunc_t	isself;
 	void			*isselfarg;
 
+	char *			strnamerd;
+	char *			strname;
+	char *			strrdclass;
+	char *			strviewname;
+
 	/*%
 	 * Serial number for deferred journal compaction.
 	 */
 	isc_uint32_t		compact_serial;
+	/*%
+	 * Keys that are signing the zone for the first time.
+	 */
+	dns_signinglist_t	signing;
+	dns_nsec3chainlist_t	nsec3chain;
+	/*%
+	 * Signing / re-signing quantum stopping parameters.
+	 */
+	isc_uint32_t		signatures;
+	isc_uint32_t		nodes;
+	dns_rdatatype_t		privatetype;
 };
 
 #define DNS_ZONE_FLAG(z,f) (ISC_TF(((z)->flags & (f)) != 0))
@@ -287,7 +334,7 @@ struct dns_zone {
 						 * reload */
 #define DNS_ZONEFLG_NOMASTERS	0x00001000U	/*%< an attempt to refresh a
 						 * zone with no masters
-						 * occured */
+						 * occurred */
 #define DNS_ZONEFLG_LOADING	0x00002000U	/*%< load from disk in progress*/
 #define DNS_ZONEFLG_HAVETIMERS	0x00004000U	/*%< timer values have been set
 						 * from SOA (if not set, we
@@ -310,6 +357,21 @@ struct dns_zone {
 /* Flags for zone_load() */
 #define DNS_ZONELOADFLAG_NOSTAT	0x00000001U	/* Do not stat() master files */
 
+#define UNREACH_CHACHE_SIZE	10U
+#define UNREACH_HOLD_TIME	600	/* 10 minutes */
+
+#define CHECK(op) \
+	do { result = (op); \
+		if (result != ISC_R_SUCCESS) goto failure; \
+	} while (0)
+
+struct dns_unreachable {
+	isc_sockaddr_t	remote;
+	isc_sockaddr_t	local;
+	isc_uint32_t	expire;
+	isc_uint32_t	last;
+};
+
 struct dns_zonemgr {
 	unsigned int		magic;
 	isc_mem_t *		mctx;
@@ -338,6 +400,10 @@ struct dns_zonemgr {
 	isc_uint32_t		ioactive;
 	dns_iolist_t		high;
 	dns_iolist_t		low;
+
+	/* Locked by rwlock. */
+	/* LRU cache */
+	struct dns_unreachable	unreachable[UNREACH_CHACHE_SIZE];
 };
 
 /*%
@@ -410,6 +476,56 @@ struct dns_io {
 	isc_event_t	*event;
 };
 
+/*%
+ *	Hold state for when we are signing a zone with a new
+ *	DNSKEY as result of an update.
+ */
+struct dns_signing {
+	unsigned int    	magic;
+	dns_db_t		*db;
+	dns_dbiterator_t	*dbiterator;
+	dns_secalg_t		algorithm;
+	isc_uint16_t		keyid;
+	isc_boolean_t		delete;
+	isc_boolean_t		done;
+	ISC_LINK(dns_signing_t)	link;
+};
+
+struct dns_nsec3chain {
+	unsigned int            	magic;
+	dns_db_t			*db;
+	dns_dbiterator_t		*dbiterator;
+	dns_rdata_nsec3param_t		nsec3param;
+	unsigned char			salt[255];
+	isc_boolean_t			done;
+	isc_boolean_t 			seen_nsec;
+	isc_boolean_t 			delete_nsec;
+	isc_boolean_t 			save_delete_nsec;
+	ISC_LINK(dns_nsec3chain_t)	link;
+};
+/*%<
+ * 'dbiterator' contains a iterator for the database.  If we are creating
+ * a NSEC3 chain only the non-NSEC3 nodes will be iterated.  If we are
+ * removing a NSEC3 chain then both NSEC3 and non-NSEC3 nodes will be
+ * iterated.
+ *
+ * 'nsec3param' contains the parameters of the NSEC3 chain being created
+ * or removed.
+ *
+ * 'salt' is buffer space and is referenced via 'nsec3param.salt'.
+ *
+ * 'seen_nsec' will be set to true if, while iterating the zone to create a
+ * NSEC3 chain, a NSEC record is seen.
+ *
+ * 'delete_nsec' will be set to true if, at the completion of the creation
+ * of a NSEC3 chain, 'seen_nsec' is true.  If 'delete_nsec' is true then we
+ * are in the process of deleting the NSEC chain.
+ *
+ * 'save_delete_nsec' is used to store the initial state of 'delete_nsec'
+ * so it can be recovered in the event of a error.
+ */
+
+
 #define SEND_BUFFER_SIZE 2048
 
 static void zone_settimer(dns_zone_t *, isc_time_t *);
@@ -436,6 +552,10 @@ static void zone_shutdown(isc_task_t *, isc_event_t *);
 static void zone_loaddone(void *arg, isc_result_t result);
 static isc_result_t zone_startload(dns_db_t *db, dns_zone_t *zone,
 				   isc_time_t loadtime);
+static void zone_namerd_tostr(dns_zone_t *zone, char *buf, size_t length);
+static void zone_name_tostr(dns_zone_t *zone, char *buf, size_t length);
+static void zone_rdclass_tostr(dns_zone_t *zone, char *buf, size_t length);
+static void zone_viewname_tostr(dns_zone_t *zone, char *buf, size_t length);
 
 #if 0
 /* ondestroy example */
@@ -484,6 +604,12 @@ static void zone_saveunique(dns_zone_t *zone, const char *path,
 static void zone_maintenance(dns_zone_t *zone);
 static void zone_notify(dns_zone_t *zone, isc_time_t *now);
 static void dump_done(void *arg, isc_result_t result);
+static isc_boolean_t dns_zonemgr_unreachable(dns_zonemgr_t *zmgr,
+					     isc_sockaddr_t *remote,
+					     isc_sockaddr_t *local,
+					     isc_time_t *now);
+static isc_result_t zone_signwithkey(dns_zone_t *zone, dns_secalg_t algorithm,
+				     isc_uint16_t keyid, isc_boolean_t delete);
 
 #define ENTER zone_debuglog(zone, me, 1, "enter")
 
@@ -518,6 +644,15 @@ static const char *dbargv_default[] = { "rbt" };
 		} \
 	} while (0)
 
+/*%
+ * Increment resolver-related statistics counters.  Zone must be locked.
+ */
+static inline void
+inc_stats(dns_zone_t *zone, isc_statscounter_t counter) {
+	if (zone->stats != NULL)
+		isc_stats_increment(zone->stats, counter);
+}
+
 /***
  ***	Public functions.
  ***/
@@ -559,8 +694,12 @@ dns_zone_create(dns_zone_t **zonep, isc_mem_t *mctx) {
 		goto free_dblock;
 	zone->irefs = 0;
 	dns_name_init(&zone->origin, NULL);
+	zone->strnamerd = NULL;
+	zone->strname = NULL;
+	zone->strrdclass = NULL;
+	zone->strviewname = NULL;
 	zone->masterfile = NULL;
-	zone->masterformat =  dns_masterformat_none;
+	zone->masterformat = dns_masterformat_none;
 	zone->keydirectory = NULL;
 	zone->journalsize = -1;
 	zone->journal = NULL;
@@ -575,6 +714,10 @@ dns_zone_create(dns_zone_t **zonep, isc_mem_t *mctx) {
 	isc_time_settoepoch(&zone->dumptime);
 	isc_time_settoepoch(&zone->loadtime);
 	zone->notifytime = now;
+	isc_time_settoepoch(&zone->resigntime);
+	isc_time_settoepoch(&zone->keywarntime);
+	isc_time_settoepoch(&zone->signingtime);
+	isc_time_settoepoch(&zone->nsec3chaintime);
 	zone->serial = 0;
 	zone->refresh = DNS_ZONE_DEFAULTREFRESH;
 	zone->retry = DNS_ZONE_DEFAULTRETRY;
@@ -597,6 +740,7 @@ dns_zone_create(dns_zone_t **zonep, isc_mem_t *mctx) {
 	zone->forward_acl = NULL;
 	zone->notify_acl = NULL;
 	zone->query_acl = NULL;
+	zone->queryon_acl = NULL;
 	zone->xfr_acl = NULL;
 	zone->update_disabled = ISC_FALSE;
 	zone->zero_no_soa_ttl = ISC_TRUE;
@@ -622,6 +766,7 @@ dns_zone_create(dns_zone_t **zonep, isc_mem_t *mctx) {
 	zone->maxxfrout = MAX_XFER_TIME;
 	zone->ssutable = NULL;
 	zone->sigvalidityinterval = 30 * 24 * 3600;
+	zone->sigresigninginterval = 7 * 24 * 3600;
 	zone->view = NULL;
 	zone->acache = NULL;
 	zone->checkmx = NULL;
@@ -629,10 +774,17 @@ dns_zone_create(dns_zone_t **zonep, isc_mem_t *mctx) {
 	zone->checkns = NULL;
 	ISC_LINK_INIT(zone, statelink);
 	zone->statelist = NULL;
-	zone->counters = NULL;
+	zone->stats = NULL;
+	zone->requeststats_on = ISC_FALSE;
+	zone->requeststats = NULL;
 	zone->notifydelay = 5;
 	zone->isself = NULL;
 	zone->isselfarg = NULL;
+	ISC_LIST_INIT(zone->signing);
+	ISC_LIST_INIT(zone->nsec3chain);
+	zone->signatures = 10;
+	zone->nodes = 100;
+	zone->privatetype = (dns_rdatatype_t)0xffffU;
 
 	zone->magic = ZONE_MAGIC;
 
@@ -669,6 +821,8 @@ dns_zone_create(dns_zone_t **zonep, isc_mem_t *mctx) {
 static void
 zone_free(dns_zone_t *zone) {
 	isc_mem_t *mctx = NULL;
+	dns_signing_t *signing;
+	dns_nsec3chain_t *nsec3chain;
 
 	REQUIRE(DNS_ZONE_VALID(zone));
 	REQUIRE(isc_refcount_current(&zone->erefs) == 0);
@@ -687,10 +841,26 @@ zone_free(dns_zone_t *zone) {
 
 	if (zone->task != NULL)
 		isc_task_detach(&zone->task);
-	if (zone->zmgr)
+	if (zone->zmgr != NULL)
 		dns_zonemgr_releasezone(zone->zmgr, zone);
 
 	/* Unmanaged objects */
+	for (signing = ISC_LIST_HEAD(zone->signing);
+	     signing != NULL;
+	     signing = ISC_LIST_HEAD(zone->signing)) {
+		ISC_LIST_UNLINK(zone->signing, signing, link);
+		dns_db_detach(&signing->db);
+		dns_dbiterator_destroy(&signing->dbiterator);
+		isc_mem_put(zone->mctx, signing, sizeof *signing);
+	}
+	for (nsec3chain = ISC_LIST_HEAD(zone->nsec3chain);
+	     nsec3chain != NULL;
+	     nsec3chain = ISC_LIST_HEAD(zone->nsec3chain)) {
+		ISC_LIST_UNLINK(zone->nsec3chain, nsec3chain, link);
+		dns_db_detach(&nsec3chain->db);
+		dns_dbiterator_destroy(&nsec3chain->dbiterator);
+		isc_mem_put(zone->mctx, nsec3chain, sizeof *nsec3chain);
+	}
 	if (zone->masterfile != NULL)
 		isc_mem_free(zone->mctx, zone->masterfile);
 	zone->masterfile = NULL;
@@ -701,8 +871,10 @@ zone_free(dns_zone_t *zone) {
 	if (zone->journal != NULL)
 		isc_mem_free(zone->mctx, zone->journal);
 	zone->journal = NULL;
-	if (zone->counters != NULL)
-		dns_stats_freecounters(zone->mctx, &zone->counters);
+	if (zone->stats != NULL)
+		isc_stats_detach(&zone->stats);
+	if (zone->requeststats != NULL)
+		isc_stats_detach(&zone->requeststats);
 	if (zone->db != NULL)
 		zone_detachdb(zone);
 	if (zone->acache != NULL)
@@ -721,10 +893,20 @@ zone_free(dns_zone_t *zone) {
 		dns_acl_detach(&zone->notify_acl);
 	if (zone->query_acl != NULL)
 		dns_acl_detach(&zone->query_acl);
+	if (zone->queryon_acl != NULL)
+		dns_acl_detach(&zone->queryon_acl);
 	if (zone->xfr_acl != NULL)
 		dns_acl_detach(&zone->xfr_acl);
 	if (dns_name_dynamic(&zone->origin))
 		dns_name_free(&zone->origin, zone->mctx);
+	if (zone->strnamerd != NULL)
+		isc_mem_free(zone->mctx, zone->strnamerd);
+	if (zone->strname != NULL)
+		isc_mem_free(zone->mctx, zone->strname);
+	if (zone->strrdclass != NULL)
+		isc_mem_free(zone->mctx, zone->strrdclass);
+	if (zone->strviewname != NULL)
+		isc_mem_free(zone->mctx, zone->strviewname);
 	if (zone->ssutable != NULL)
 		dns_ssutable_detach(&zone->ssutable);
 
@@ -743,6 +925,7 @@ zone_free(dns_zone_t *zone) {
  */
 void
 dns_zone_setclass(dns_zone_t *zone, dns_rdataclass_t rdclass) {
+	char namebuf[1024];
 
 	REQUIRE(DNS_ZONE_VALID(zone));
 	REQUIRE(rdclass != dns_rdataclass_none);
@@ -754,11 +937,22 @@ dns_zone_setclass(dns_zone_t *zone, dns_rdataclass_t rdclass) {
 	REQUIRE(zone->rdclass == dns_rdataclass_none ||
 		zone->rdclass == rdclass);
 	zone->rdclass = rdclass;
+
+	if (zone->strnamerd != NULL)
+		isc_mem_free(zone->mctx, zone->strnamerd);
+	if (zone->strrdclass != NULL)
+		isc_mem_free(zone->mctx, zone->strrdclass);
+
+	zone_namerd_tostr(zone, namebuf, sizeof namebuf);
+	zone->strnamerd = isc_mem_strdup(zone->mctx, namebuf);
+	zone_rdclass_tostr(zone, namebuf, sizeof namebuf);
+	zone->strrdclass = isc_mem_strdup(zone->mctx, namebuf);
+
 	UNLOCK_ZONE(zone);
 }
 
 dns_rdataclass_t
-dns_zone_getclass(dns_zone_t *zone){
+dns_zone_getclass(dns_zone_t *zone) {
 	REQUIRE(DNS_ZONE_VALID(zone));
 
 	return (zone->rdclass);
@@ -773,6 +967,19 @@ dns_zone_setnotifytype(dns_zone_t *zone, dns_notifytype_t notifytype) {
 	UNLOCK_ZONE(zone);
 }
 
+isc_uint32_t
+dns_zone_getserial(dns_zone_t *zone) {
+	isc_uint32_t serial;
+
+	REQUIRE(DNS_ZONE_VALID(zone));
+
+	LOCK_ZONE(zone);
+	serial = zone->serial;
+	UNLOCK_ZONE(zone);
+
+	return (serial);
+}
+
 /*
  *	Single shot.
  */
@@ -888,12 +1095,24 @@ dns_zone_setdbtype(dns_zone_t *zone,
 
 void
 dns_zone_setview(dns_zone_t *zone, dns_view_t *view) {
+	char namebuf[1024];
 	REQUIRE(DNS_ZONE_VALID(zone));
 
 	LOCK_ZONE(zone);
 	if (zone->view != NULL)
 		dns_view_weakdetach(&zone->view);
 	dns_view_weakattach(view, &zone->view);
+
+	if (zone->strviewname != NULL)
+		isc_mem_free(zone->mctx, zone->strviewname);
+	if (zone->strnamerd != NULL)
+		isc_mem_free(zone->mctx, zone->strnamerd);
+
+	zone_namerd_tostr(zone, namebuf, sizeof namebuf);
+	zone->strnamerd = isc_mem_strdup(zone->mctx, namebuf);
+	zone_viewname_tostr(zone, namebuf, sizeof namebuf);
+	zone->strviewname = isc_mem_strdup(zone->mctx, namebuf);
+
 	UNLOCK_ZONE(zone);
 }
 
@@ -909,6 +1128,7 @@ dns_zone_getview(dns_zone_t *zone) {
 isc_result_t
 dns_zone_setorigin(dns_zone_t *zone, const dns_name_t *origin) {
 	isc_result_t result;
+	char namebuf[1024];
 
 	REQUIRE(DNS_ZONE_VALID(zone));
 	REQUIRE(origin != NULL);
@@ -919,6 +1139,17 @@ dns_zone_setorigin(dns_zone_t *zone, const dns_name_t *origin) {
 		dns_name_init(&zone->origin, NULL);
 	}
 	result = dns_name_dup(origin, zone->mctx, &zone->origin);
+
+	if (zone->strnamerd != NULL)
+		isc_mem_free(zone->mctx, zone->strnamerd);
+	if (zone->strname != NULL)
+		isc_mem_free(zone->mctx, zone->strname);
+
+	zone_namerd_tostr(zone, namebuf, sizeof namebuf);
+	zone->strnamerd = isc_mem_strdup(zone->mctx, namebuf);
+	zone_name_tostr(zone, namebuf, sizeof namebuf);
+	zone->strname = isc_mem_strdup(zone->mctx, namebuf);
+
 	UNLOCK_ZONE(zone);
 	return (result);
 }
@@ -1064,11 +1295,7 @@ zone_isdynamic(dns_zone_t *zone) {
 		       zone->type == dns_zone_stub ||
 		       (!zone->update_disabled && zone->ssutable != NULL) ||
 		       (!zone->update_disabled && zone->update_acl != NULL &&
-			! (zone->update_acl->length == 1 &&
-			   zone->update_acl->elements[0].negative == ISC_TRUE
-			   &&
-			   zone->update_acl->elements[0].type ==
-			   dns_aclelementtype_any))));
+			!dns_acl_isnone(zone->update_acl))));
 }
 
 
@@ -1243,6 +1470,33 @@ dns_zone_loadnew(dns_zone_t *zone) {
 	return (zone_load(zone, DNS_ZONELOADFLAG_NOSTAT));
 }
 
+static unsigned int
+get_master_options(dns_zone_t *zone) {
+	unsigned int options;
+
+	options = DNS_MASTER_ZONE;
+	if (zone->type == dns_zone_slave)
+		options |= DNS_MASTER_SLAVE;
+	if (DNS_ZONE_OPTION(zone, DNS_ZONEOPT_CHECKNS))
+		options |= DNS_MASTER_CHECKNS;
+	if (DNS_ZONE_OPTION(zone, DNS_ZONEOPT_FATALNS))
+		options |= DNS_MASTER_FATALNS;
+	if (DNS_ZONE_OPTION(zone, DNS_ZONEOPT_CHECKNAMES))
+		options |= DNS_MASTER_CHECKNAMES;
+	if (DNS_ZONE_OPTION(zone, DNS_ZONEOPT_CHECKNAMESFAIL))
+		options |= DNS_MASTER_CHECKNAMESFAIL;
+	if (DNS_ZONE_OPTION(zone, DNS_ZONEOPT_CHECKMX))
+		options |= DNS_MASTER_CHECKMX;
+	if (DNS_ZONE_OPTION(zone, DNS_ZONEOPT_CHECKMXFAIL))
+		options |= DNS_MASTER_CHECKMXFAIL;
+	if (DNS_ZONE_OPTION(zone, DNS_ZONEOPT_CHECKWILDCARD))
+		options |= DNS_MASTER_CHECKWILDCARD;
+	if (zone->type == dns_zone_master &&
+	    (zone->update_acl != NULL || zone->ssutable != NULL))
+		options |= DNS_MASTER_RESIGN;
+	return (options);
+}
+
 static void
 zone_gotreadhandle(isc_task_t *task, isc_event_t *event) {
 	dns_load_t *load = event->ev_arg;
@@ -1257,28 +1511,14 @@ zone_gotreadhandle(isc_task_t *task, isc_event_t *event) {
 	if (result == ISC_R_CANCELED)
 		goto fail;
 
-	options = DNS_MASTER_ZONE;
-	if (load->zone->type == dns_zone_slave)
-		options |= DNS_MASTER_SLAVE;
-	if (DNS_ZONE_OPTION(load->zone, DNS_ZONEOPT_CHECKNS))
-		options |= DNS_MASTER_CHECKNS;
-	if (DNS_ZONE_OPTION(load->zone, DNS_ZONEOPT_FATALNS))
-		options |= DNS_MASTER_FATALNS;
-	if (DNS_ZONE_OPTION(load->zone, DNS_ZONEOPT_CHECKNAMES))
-		options |= DNS_MASTER_CHECKNAMES;
-	if (DNS_ZONE_OPTION(load->zone, DNS_ZONEOPT_CHECKNAMESFAIL))
-		options |= DNS_MASTER_CHECKNAMESFAIL;
-	if (DNS_ZONE_OPTION(load->zone, DNS_ZONEOPT_CHECKMX))
-		options |= DNS_MASTER_CHECKMX;
-	if (DNS_ZONE_OPTION(load->zone, DNS_ZONEOPT_CHECKMXFAIL))
-		options |= DNS_MASTER_CHECKMXFAIL;
-	if (DNS_ZONE_OPTION(load->zone, DNS_ZONEOPT_CHECKWILDCARD))
-		options |= DNS_MASTER_CHECKWILDCARD;
-	result = dns_master_loadfileinc2(load->zone->masterfile,
+	options = get_master_options(load->zone);
+
+	result = dns_master_loadfileinc3(load->zone->masterfile,
 					 dns_db_origin(load->db),
 					 dns_db_origin(load->db),
 					 load->zone->rdclass,
 					 options,
+					 load->zone->sigresigninginterval,
 					 &load->callbacks, task,
 					 zone_loaddone, load,
 					 &load->zone->lctx, load->zone->mctx,
@@ -1334,25 +1574,10 @@ zone_startload(dns_db_t *db, dns_zone_t *zone, isc_time_t loadtime) {
 	isc_result_t tresult;
 	unsigned int options;
 
-	options = DNS_MASTER_ZONE;
+	options = get_master_options(zone);
+
 	if (DNS_ZONE_OPTION(zone, DNS_ZONEOPT_MANYERRORS))
 		options |= DNS_MASTER_MANYERRORS;
-	if (DNS_ZONE_OPTION(zone, DNS_ZONEOPT_CHECKNS))
-		options |= DNS_MASTER_CHECKNS;
-	if (DNS_ZONE_OPTION(zone, DNS_ZONEOPT_FATALNS))
-		options |= DNS_MASTER_FATALNS;
-	if (zone->type == dns_zone_slave)
-		options |= DNS_MASTER_SLAVE;
-	if (DNS_ZONE_OPTION(zone, DNS_ZONEOPT_CHECKNAMES))
-		options |= DNS_MASTER_CHECKNAMES;
-	if (DNS_ZONE_OPTION(zone, DNS_ZONEOPT_CHECKNAMESFAIL))
-		options |= DNS_MASTER_CHECKNAMESFAIL;
-	if (DNS_ZONE_OPTION(zone, DNS_ZONEOPT_CHECKMX))
-		options |= DNS_MASTER_CHECKMX;
-	if (DNS_ZONE_OPTION(zone, DNS_ZONEOPT_CHECKMXFAIL))
-		options |= DNS_MASTER_CHECKMXFAIL;
-	if (DNS_ZONE_OPTION(zone, DNS_ZONEOPT_CHECKWILDCARD))
-		options |= DNS_MASTER_CHECKWILDCARD;
 
 	if (zone->zmgr != NULL && zone->db != NULL && zone->task != NULL) {
 		load = isc_mem_get(zone->mctx, sizeof(*load));
@@ -1394,9 +1619,10 @@ zone_startload(dns_db_t *db, dns_zone_t *zone, isc_time_t loadtime) {
 					  &callbacks.add_private);
 		if (result != ISC_R_SUCCESS)
 			return (result);
-		result = dns_master_loadfile2(zone->masterfile, &zone->origin,
+		result = dns_master_loadfile3(zone->masterfile, &zone->origin,
 					      &zone->origin, zone->rdclass,
-					      options, &callbacks, zone->mctx,
+					      options, zone->sigresigninginterval,
+					      &callbacks, zone->mctx,
 					      zone->masterformat);
 		tresult = dns_db_endload(db, &callbacks.add_private);
 		if (result == ISC_R_SUCCESS)
@@ -1727,7 +1953,7 @@ integrity_checks(dns_zone_t *zone, dns_db_t *db) {
 	dns_rdataset_init(&rdataset);
 	dns_rdata_init(&rdata);
 
-	result = dns_db_createiterator(db, ISC_FALSE, &dbiterator);
+	result = dns_db_createiterator(db, 0, &dbiterator);
 	if (result != ISC_R_SUCCESS)
 		return (ISC_TRUE);
 
@@ -1890,6 +2116,292 @@ zone_check_dnskeys(dns_zone_t *zone, dns_db_t *db) {
 
 }
 
+static void
+resume_signingwithkey(dns_zone_t *zone) {
+	dns_dbnode_t *node = NULL;
+	dns_dbversion_t *version = NULL;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	dns_rdataset_t rdataset;
+	isc_result_t result;
+
+	result = dns_db_findnode(zone->db, &zone->origin, ISC_FALSE, &node);
+	if (result != ISC_R_SUCCESS)
+		goto cleanup;
+
+	dns_db_currentversion(zone->db, &version);
+	dns_rdataset_init(&rdataset);
+	result = dns_db_findrdataset(zone->db, node, version,
+				     zone->privatetype,
+				     dns_rdatatype_none, 0,
+				     &rdataset, NULL);
+	if (result != ISC_R_SUCCESS)
+		goto cleanup;
+
+	for (result = dns_rdataset_first(&rdataset);
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdataset_next(&rdataset))
+	{
+		dns_rdataset_current(&rdataset, &rdata);
+		if (rdata.length != 5 || rdata.data[4] != 0) {
+			dns_rdata_reset(&rdata);
+			continue;
+		}
+
+		result = zone_signwithkey(zone, rdata.data[0],
+					  (rdata.data[1] << 8) | rdata.data[2],						  ISC_TF(rdata.data[3]));
+		if (result != ISC_R_SUCCESS) {
+			dns_zone_log(zone, ISC_LOG_ERROR,
+				     "zone_signwithkey failed: %s",
+				     dns_result_totext(result));
+		}
+		dns_rdata_reset(&rdata);
+	}
+	dns_rdataset_disassociate(&rdataset);
+
+ cleanup:
+	if (node != NULL)
+		dns_db_detachnode(zone->db, &node);
+	if (version != NULL)
+		dns_db_closeversion(zone->db, &version, ISC_FALSE);
+
+}
+
+static isc_result_t
+zone_addnsec3chain(dns_zone_t *zone, dns_rdata_nsec3param_t *nsec3param) {
+	dns_nsec3chain_t *nsec3chain, *current;
+	isc_result_t result;
+	isc_time_t now;
+	unsigned int options = 0;
+
+	nsec3chain = isc_mem_get(zone->mctx, sizeof *nsec3chain);
+	if (nsec3chain == NULL)
+		return (ISC_R_NOMEMORY);
+
+	nsec3chain->magic = 0;
+	nsec3chain->done = ISC_FALSE;
+	nsec3chain->db = NULL;
+	nsec3chain->dbiterator = NULL;
+	nsec3chain->nsec3param.common.rdclass = nsec3param->common.rdclass;
+	nsec3chain->nsec3param.common.rdtype = nsec3param->common.rdtype;
+	nsec3chain->nsec3param.hash = nsec3param->hash;
+	nsec3chain->nsec3param.iterations = nsec3param->iterations;
+	nsec3chain->nsec3param.flags = nsec3param->flags;
+	nsec3chain->nsec3param.salt_length = nsec3param->salt_length;
+	memcpy(nsec3chain->salt, nsec3param->salt, nsec3param->salt_length);
+	nsec3chain->nsec3param.salt = nsec3chain->salt;
+	nsec3chain->seen_nsec = ISC_FALSE;
+	nsec3chain->delete_nsec = ISC_FALSE;
+	nsec3chain->save_delete_nsec = ISC_FALSE;
+
+	for (current = ISC_LIST_HEAD(zone->nsec3chain);
+	     current != NULL;
+	     current = ISC_LIST_NEXT(current, link)) {
+		if (current->db == zone->db &&
+		    current->nsec3param.hash == nsec3param->hash &&
+		    current->nsec3param.iterations == nsec3param->iterations &&
+		    current->nsec3param.salt_length == nsec3param->salt_length
+		    && !memcmp(current->nsec3param.salt, nsec3param->salt,
+			       nsec3param->salt_length))
+			current->done = ISC_TRUE;
+	}
+
+	if (zone->db != NULL) {
+		dns_db_attach(zone->db, &nsec3chain->db);
+		if ((nsec3chain->nsec3param.flags & DNS_NSEC3FLAG_CREATE) != 0)
+			options = DNS_DB_NONSEC3;
+		result = dns_db_createiterator(nsec3chain->db, options,
+					       &nsec3chain->dbiterator);
+		if (result == ISC_R_SUCCESS)
+			dns_dbiterator_first(nsec3chain->dbiterator);
+		if (result == ISC_R_SUCCESS) {
+			dns_dbiterator_pause(nsec3chain->dbiterator);
+			ISC_LIST_INITANDAPPEND(zone->nsec3chain,
+					       nsec3chain, link);
+			nsec3chain = NULL;
+			if (isc_time_isepoch(&zone->nsec3chaintime)) {
+				TIME_NOW(&now);
+				zone->nsec3chaintime = now;
+				if (zone->task != NULL)
+					zone_settimer(zone, &now);
+			}
+		}
+	} else
+		result = ISC_R_NOTFOUND;
+
+	if (nsec3chain != NULL) {
+		if (nsec3chain->db != NULL)
+			dns_db_detach(&nsec3chain->db);
+		if (nsec3chain->dbiterator != NULL)
+			dns_dbiterator_destroy(&nsec3chain->dbiterator);
+		isc_mem_put(zone->mctx, nsec3chain, sizeof *nsec3chain);
+	}
+	return (result);
+}
+
+static void
+resume_addnsec3chain(dns_zone_t *zone) {
+	dns_dbnode_t *node = NULL;
+	dns_dbversion_t *version = NULL;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	dns_rdataset_t rdataset;
+	isc_result_t result;
+	dns_rdata_nsec3param_t nsec3param;
+
+	result = dns_db_findnode(zone->db, &zone->origin, ISC_FALSE, &node);
+	if (result != ISC_R_SUCCESS)
+		goto cleanup;
+
+	dns_db_currentversion(zone->db, &version);
+	dns_rdataset_init(&rdataset);
+	result = dns_db_findrdataset(zone->db, node, version,
+				     dns_rdatatype_nsec3param,
+				     dns_rdatatype_none, 0,
+				     &rdataset, NULL);
+	if (result != ISC_R_SUCCESS)
+		goto cleanup;
+
+	for (result = dns_rdataset_first(&rdataset);
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdataset_next(&rdataset))
+	{
+		dns_rdataset_current(&rdataset, &rdata);
+		result = dns_rdata_tostruct(&rdata, &nsec3param, NULL);
+		RUNTIME_CHECK(result == ISC_R_SUCCESS);
+		if ((nsec3param.flags & DNS_NSEC3FLAG_CREATE) != 0 ||
+		    (nsec3param.flags & DNS_NSEC3FLAG_REMOVE) != 0) {
+			result = zone_addnsec3chain(zone, &nsec3param);
+			if (result != ISC_R_SUCCESS) {
+				dns_zone_log(zone, ISC_LOG_ERROR,
+					     "zone_addnsec3chain failed: %s",
+					     dns_result_totext(result));
+			}
+		}
+		dns_rdata_reset(&rdata);
+	}
+	dns_rdataset_disassociate(&rdataset);
+
+ cleanup:
+	if (node != NULL)
+		dns_db_detachnode(zone->db, &node);
+	if (version != NULL)
+		dns_db_closeversion(zone->db, &version, ISC_FALSE);
+}
+
+static void
+set_resigntime(dns_zone_t *zone) {
+	dns_rdataset_t rdataset;
+	dns_fixedname_t fixed;
+	char namebuf[DNS_NAME_FORMATSIZE];
+	unsigned int resign;
+	isc_result_t result;
+	isc_uint32_t nanosecs;
+
+	dns_rdataset_init(&rdataset);
+	dns_fixedname_init(&fixed);
+	result  = dns_db_getsigningtime(zone->db, &rdataset,
+					dns_fixedname_name(&fixed));
+	if (result != ISC_R_SUCCESS) {
+		isc_time_settoepoch(&zone->resigntime);
+		return;
+	}
+	resign = rdataset.resign;
+	dns_name_format(dns_fixedname_name(&fixed), namebuf, sizeof(namebuf));
+	dns_rdataset_disassociate(&rdataset);
+	isc_random_get(&nanosecs);
+	nanosecs %= 1000000000;
+	isc_time_set(&zone->resigntime, resign, nanosecs);
+}
+
+static isc_result_t
+check_nsec3param(dns_zone_t *zone, dns_db_t *db) {
+	dns_dbnode_t *node = NULL;
+	dns_rdataset_t rdataset;
+	dns_dbversion_t *version = NULL;
+	dns_rdata_nsec3param_t nsec3param;
+	isc_boolean_t ok = ISC_FALSE;
+	isc_result_t result;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	isc_boolean_t dynamic = (zone->type == dns_zone_master) ?
+				zone_isdynamic(zone) : ISC_FALSE;
+
+	dns_rdataset_init(&rdataset);
+	result = dns_db_findnode(db, &zone->origin, ISC_FALSE, &node);
+	if (result != ISC_R_SUCCESS) {
+		dns_zone_log(zone, ISC_LOG_ERROR,
+			     "nsec3param lookup failure: %s",
+			     dns_result_totext(result));
+		return (result);
+	}
+	dns_db_currentversion(db, &version);
+
+	result = dns_db_findrdataset(db, node, version,
+				     dns_rdatatype_nsec3param,
+				     dns_rdatatype_none, 0, &rdataset, NULL);
+	if (result == ISC_R_NOTFOUND) {
+		result = ISC_R_SUCCESS;
+		goto cleanup;
+	}
+	if (result != ISC_R_SUCCESS) {
+		dns_zone_log(zone, ISC_LOG_ERROR,
+			     "nsec3param lookup failure: %s",
+			     dns_result_totext(result));
+		goto cleanup;
+	}
+
+	/*
+	 * For dynamic zones we must support every algorithm so we can
+	 * regenerate all the NSEC3 chains.
+	 * For non-dynamic zones we only need to find a supported algorithm.
+	 */
+	for (result = dns_rdataset_first(&rdataset);
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdataset_next(&rdataset))
+	{
+		dns_rdataset_current(&rdataset, &rdata);
+		result = dns_rdata_tostruct(&rdata, &nsec3param, NULL);
+		dns_rdata_reset(&rdata);
+		INSIST(result == ISC_R_SUCCESS);
+		if (DNS_ZONE_OPTION(zone, DNS_ZONEOPT_NSEC3TESTZONE) &&
+		    nsec3param.hash == DNS_NSEC3_UNKNOWNALG && !dynamic)
+		{
+			dns_zone_log(zone, ISC_LOG_WARNING,
+			     "nsec3 test \"unknown\" hash algorithm found: %u",
+				     nsec3param.hash);
+			ok = ISC_TRUE;
+		} else if (!dns_nsec3_supportedhash(nsec3param.hash)) {
+			if (dynamic) {
+				dns_zone_log(zone, ISC_LOG_ERROR,
+					     "unsupported nsec3 hash algorithm"
+					     " in dynamic zone: %u",
+					     nsec3param.hash);
+				result = DNS_R_BADZONE;
+				/* Stop second error message. */
+				ok = ISC_TRUE;
+				break;
+			} else
+				dns_zone_log(zone, ISC_LOG_WARNING,
+				     "unsupported nsec3 hash algorithm: %u",
+					     nsec3param.hash);
+		} else
+			ok = ISC_TRUE;
+	}
+	if (result == ISC_R_NOMORE)
+		result = ISC_R_SUCCESS;
+
+	if (!ok) {
+		result = DNS_R_BADZONE;
+		dns_zone_log(zone, ISC_LOG_ERROR,
+			     "no supported nsec3 hash algorithm");
+	}
+
+ cleanup:
+	if (dns_rdataset_isassociated(&rdataset))
+		dns_rdataset_disassociate(&rdataset);
+	dns_db_closeversion(db, &version, ISC_FALSE);
+	dns_db_detachnode(db, &node);
+	return (result);
+}
+
 static isc_result_t
 zone_postload(dns_zone_t *zone, dns_db_t *db, isc_time_t loadtime,
 	      isc_result_t result)
@@ -1901,6 +2413,7 @@ zone_postload(dns_zone_t *zone, dns_db_t *db, isc_time_t loadtime,
 	isc_time_t now;
 	isc_boolean_t needdump = ISC_FALSE;
 	isc_boolean_t hasinclude = DNS_ZONE_FLAG(zone, DNS_ZONEFLG_HASINCLUDE);
+	unsigned int options;
 
 	TIME_NOW(&now);
 
@@ -1945,7 +2458,12 @@ zone_postload(dns_zone_t *zone, dns_db_t *db, isc_time_t loadtime,
 	    ! DNS_ZONE_OPTION(zone, DNS_ZONEOPT_NOMERGE) &&
 	    ! DNS_ZONE_FLAG(zone, DNS_ZONEFLG_LOADED))
 	{
-		result = dns_journal_rollforward(zone->mctx, db,
+		if (zone->type == dns_zone_master &&
+		    (zone->update_acl != NULL || zone->ssutable != NULL))
+			options = DNS_JOURNALOPT_RESIGN;
+		else
+			options = 0;
+		result = dns_journal_rollforward(zone->mctx, db, options,
 						 zone->journal);
 		if (result != ISC_R_SUCCESS && result != ISC_R_NOTFOUND &&
 		    result != DNS_R_UPTODATE && result != DNS_R_NOJOURNAL &&
@@ -1972,7 +2490,6 @@ zone_postload(dns_zone_t *zone, dns_db_t *db, isc_time_t loadtime,
 	zone->loadtime = loadtime;
 
 	dns_zone_log(zone, ISC_LOG_DEBUG(1), "loaded");
-
 	/*
 	 * Obtain ns, soa and cname counts for top of zone.
 	 */
@@ -2010,6 +2527,11 @@ zone_postload(dns_zone_t *zone, dns_db_t *db, isc_time_t loadtime,
 			result = DNS_R_BADZONE;
 			goto cleanup;
 		}
+		if (zone->type != dns_zone_stub) {
+			result = check_nsec3param(zone, db);
+			if (result != ISC_R_SUCCESS)
+				goto cleanup;
+		}
 		if (zone->type == dns_zone_master &&
 		    DNS_ZONE_OPTION(zone, DNS_ZONEOPT_CHECKINTEGRITY) &&
 		    !integrity_checks(zone, db)) {
@@ -2047,6 +2569,17 @@ zone_postload(dns_zone_t *zone, dns_db_t *db, isc_time_t loadtime,
 					     "zone may fail to transfer "
 					     "to slaves.");
 		}
+
+		if (zone->type == dns_zone_master &&
+		    (zone->update_acl != NULL || zone->ssutable != NULL) &&
+		    zone->sigresigninginterval < (3 * refresh) &&
+		    dns_db_issecure(db))
+		{
+			dns_zone_log(zone, ISC_LOG_WARNING,
+				     "sig-re-signing-interval less than "
+				     "3 * refresh.");
+		}
+
 		zone->serial = serial;
 		zone->refresh = RANGE(refresh,
 				      zone->minrefresh, zone->maxrefresh);
@@ -2121,8 +2654,14 @@ zone_postload(dns_zone_t *zone, dns_db_t *db, isc_time_t loadtime,
 	result = ISC_R_SUCCESS;
 	if (needdump)
 		zone_needdump(zone, DNS_DUMP_DELAY);
-	if (zone->task != NULL)
+	if (zone->task != NULL) {
+		if (zone->type == dns_zone_master) {
+			set_resigntime(zone);
+			resume_signingwithkey(zone);
+			resume_addnsec3chain(zone);
+		}
 		zone_settimer(zone, &now);
+	}
 
 	if (! dns_db_ispersistent(db))
 		dns_zone_log(zone, ISC_LOG_INFO, "loaded serial %u%s",
@@ -2809,7 +3348,7 @@ dns_zone_setmasterswithkeys(dns_zone_t *zone,
 		goto unlock;
 
 	/*
-	 * masters must countain count elements!
+	 * masters must contain count elements!
 	 */
 	new = isc_mem_get(zone->mctx, count * sizeof(*new));
 	if (new == NULL) {
@@ -2935,6 +3474,2432 @@ was_dumping(dns_zone_t *zone) {
 	return (dumping);
 }
 
+#define MAXZONEKEYS 10
+
+static isc_result_t
+do_one_tuple(dns_difftuple_t **tuple, dns_db_t *db, dns_dbversion_t *ver,
+	     dns_diff_t *diff)
+{
+	dns_diff_t temp_diff;
+	isc_result_t result;
+
+	/*
+	 * Create a singleton diff.
+	 */
+	dns_diff_init(diff->mctx, &temp_diff);
+	temp_diff.resign = diff->resign;
+	ISC_LIST_APPEND(temp_diff.tuples, *tuple, link);
+
+	/*
+	 * Apply it to the database.
+	 */
+	result = dns_diff_apply(&temp_diff, db, ver);
+	ISC_LIST_UNLINK(temp_diff.tuples, *tuple, link);
+	if (result != ISC_R_SUCCESS) {
+		dns_difftuple_free(tuple);
+		return (result);
+	}
+
+	/*
+	 * Merge it into the current pending journal entry.
+	 */
+	dns_diff_appendminimal(diff, tuple);
+
+	/*
+	 * Do not clear temp_diff.
+	 */
+	return (ISC_R_SUCCESS);
+}
+
+static isc_result_t
+increment_soa_serial(dns_db_t *db, dns_dbversion_t *ver,
+		     dns_diff_t *diff, isc_mem_t *mctx)
+{
+	dns_difftuple_t *deltuple = NULL;
+	dns_difftuple_t *addtuple = NULL;
+	isc_uint32_t serial;
+	isc_result_t result;
+
+	CHECK(dns_db_createsoatuple(db, ver, mctx, DNS_DIFFOP_DEL, &deltuple));
+	CHECK(dns_difftuple_copy(deltuple, &addtuple));
+	addtuple->op = DNS_DIFFOP_ADD;
+
+	serial = dns_soa_getserial(&addtuple->rdata);
+
+	/* RFC1982 */
+	serial = (serial + 1) & 0xFFFFFFFF;
+	if (serial == 0)
+		serial = 1;
+
+	dns_soa_setserial(serial, &addtuple->rdata);
+	CHECK(do_one_tuple(&deltuple, db, ver, diff));
+	CHECK(do_one_tuple(&addtuple, db, ver, diff));
+	result = ISC_R_SUCCESS;
+
+	failure:
+	if (addtuple != NULL)
+		dns_difftuple_free(&addtuple);
+	if (deltuple != NULL)
+		dns_difftuple_free(&deltuple);
+	return (result);
+}
+
+static isc_result_t
+update_one_rr(dns_db_t *db, dns_dbversion_t *ver, dns_diff_t *diff,
+	      dns_diffop_t op, dns_name_t *name, dns_ttl_t ttl,
+	      dns_rdata_t *rdata)
+{
+	dns_difftuple_t *tuple = NULL;
+	isc_result_t result;
+	result = dns_difftuple_create(diff->mctx, op,
+				      name, ttl, rdata, &tuple);
+	if (result != ISC_R_SUCCESS)
+		return (result);
+	return (do_one_tuple(&tuple, db, ver, diff));
+}
+
+static isc_boolean_t
+ksk_sanity(dns_db_t *db, dns_dbversion_t *ver) {
+	isc_boolean_t ret = ISC_FALSE;
+	isc_boolean_t have_ksk = ISC_FALSE, have_nonksk = ISC_FALSE;
+	isc_result_t result;
+	dns_dbnode_t *node = NULL;
+	dns_rdataset_t rdataset;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	dns_rdata_dnskey_t dnskey;
+
+	dns_rdataset_init(&rdataset);
+	CHECK(dns_db_findnode(db, dns_db_origin(db), ISC_FALSE, &node));
+	CHECK(dns_db_findrdataset(db, node, ver, dns_rdatatype_dnskey, 0, 0,
+				   &rdataset, NULL));
+	CHECK(dns_rdataset_first(&rdataset));
+	while (result == ISC_R_SUCCESS && (!have_ksk || !have_nonksk)) {
+		dns_rdataset_current(&rdataset, &rdata);
+		CHECK(dns_rdata_tostruct(&rdata, &dnskey, NULL));
+		if ((dnskey.flags & (DNS_KEYFLAG_OWNERMASK|DNS_KEYTYPE_NOAUTH))
+				 == DNS_KEYOWNER_ZONE) {
+			if ((dnskey.flags & DNS_KEYFLAG_KSK) != 0)
+				have_ksk = ISC_TRUE;
+			else
+				have_nonksk = ISC_TRUE;
+		}
+		dns_rdata_reset(&rdata);
+		result = dns_rdataset_next(&rdataset);
+	}
+	if (have_ksk && have_nonksk)
+		ret = ISC_TRUE;
+ failure:
+	if (dns_rdataset_isassociated(&rdataset))
+		dns_rdataset_disassociate(&rdataset);
+	if (node != NULL)
+		dns_db_detachnode(db, &node);
+	return (ret);
+}
+
+static isc_result_t
+find_zone_keys(dns_zone_t *zone, dns_db_t *db, dns_dbversion_t *ver,
+	       isc_mem_t *mctx, unsigned int maxkeys,
+	       dst_key_t **keys, unsigned int *nkeys)
+{
+	isc_result_t result;
+	dns_dbnode_t *node = NULL;
+	const char *directory = dns_zone_getkeydirectory(zone);
+	CHECK(dns_db_findnode(db, dns_db_origin(db), ISC_FALSE, &node));
+	result = dns_dnssec_findzonekeys2(db, ver, node, dns_db_origin(db),
+					  directory, mctx, maxkeys, keys,
+					  nkeys);
+	if (result == ISC_R_NOTFOUND)
+		result = ISC_R_SUCCESS;
+ failure:
+	if (node != NULL)
+		dns_db_detachnode(db, &node);
+	return (result);
+}
+
+static isc_result_t
+offline(dns_db_t *db, dns_dbversion_t *ver, dns_diff_t *diff, dns_name_t *name,
+	dns_ttl_t ttl, dns_rdata_t *rdata)
+{
+	isc_result_t result;
+
+	if ((rdata->flags & DNS_RDATA_OFFLINE) != 0)
+		return (ISC_R_SUCCESS);
+	result = update_one_rr(db, ver, diff, DNS_DIFFOP_DELRESIGN,
+			       name, ttl, rdata);
+	if (result != ISC_R_SUCCESS)
+		return (result);
+	rdata->flags |= DNS_RDATA_OFFLINE;
+	result = update_one_rr(db, ver, diff, DNS_DIFFOP_ADDRESIGN,
+			       name, ttl, rdata);
+	return (result);
+}
+
+static void
+set_key_expiry_warning(dns_zone_t *zone, isc_stdtime_t when, isc_stdtime_t now)
+{
+	unsigned int delta;
+
+	zone->key_expiry = when;
+	if (when <= now) {
+		dns_zone_log(zone, ISC_LOG_ERROR,
+			     "DNSKEY RRSIG(s) have expired");
+		isc_time_settoepoch(&zone->keywarntime);
+	} else if (when < now + 7 * 24 * 3600) {
+		dns_zone_log(zone, ISC_LOG_WARNING,
+			     "DNSKEY RRSIG(s) will expire at %u",
+			     when);	/* XXXMPA convert to date. */
+		delta = when - now;
+		delta--;		/* loop prevention */
+		delta /= 24 * 3600;	/* to whole days */
+		delta *= 24 * 3600;	/* to seconds */
+		isc_time_set(&zone->keywarntime, when - delta, 0);
+	}  else {
+		dns_zone_log(zone, ISC_LOG_NOTICE, /* XXMPA ISC_LOG_DEBUG(1) */
+			     "setting keywarntime to %u - 7 days",
+			     when);	/* XXXMPA convert to date. */
+		isc_time_set(&zone->keywarntime, when - 7 * 24 * 3600, 0);
+	}
+}
+
+/*
+ * Delete expired RRsigs and any RRsigs we are about to re-sign.
+ * See also update.c:del_keysigs().
+ */
+static isc_result_t
+del_sigs(dns_zone_t *zone, dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name,
+	 dns_rdatatype_t type, dns_diff_t *diff, dst_key_t **keys,
+	 unsigned int nkeys, isc_stdtime_t now)
+{
+	isc_result_t result;
+	dns_dbnode_t *node = NULL;
+	dns_rdataset_t rdataset;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	unsigned int i;
+	dns_rdata_rrsig_t rrsig;
+	isc_boolean_t found;
+	isc_stdtime_t warn = 0, maybe = 0;
+
+	dns_rdataset_init(&rdataset);
+
+	if (type == dns_rdatatype_nsec3)
+		result = dns_db_findnsec3node(db, name, ISC_FALSE, &node);
+	else
+		result = dns_db_findnode(db, name, ISC_FALSE, &node);
+	if (result == ISC_R_NOTFOUND)
+		return (ISC_R_SUCCESS);
+	if (result != ISC_R_SUCCESS)
+		goto failure;
+	result = dns_db_findrdataset(db, node, ver, dns_rdatatype_rrsig, type,
+				     (isc_stdtime_t) 0, &rdataset, NULL);
+	dns_db_detachnode(db, &node);
+
+	if (result == ISC_R_NOTFOUND)
+		return (ISC_R_SUCCESS);
+	if (result != ISC_R_SUCCESS)
+		goto failure;
+
+	for (result = dns_rdataset_first(&rdataset);
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdataset_next(&rdataset)) {
+		dns_rdataset_current(&rdataset, &rdata);
+		result = dns_rdata_tostruct(&rdata, &rrsig, NULL);
+		RUNTIME_CHECK(result == ISC_R_SUCCESS);
+
+		if (type != dns_rdatatype_dnskey) {
+			result = update_one_rr(db, ver, diff,
+					       DNS_DIFFOP_DEL, name,
+					       rdataset.ttl, &rdata);
+			dns_rdata_reset(&rdata);
+			if (result != ISC_R_SUCCESS)
+				break;
+			continue;
+		}
+
+		/*
+		 * RRSIG(DNSKEY) requires special processing.
+		 */
+		found = ISC_FALSE;
+		for (i = 0; i < nkeys; i++) {
+			if (rrsig.algorithm == dst_key_alg(keys[i]) &&
+			    rrsig.keyid == dst_key_id(keys[i])) {
+				found = ISC_TRUE;
+				/*
+				 * Mark offline RRSIG(DNSKEY).
+				 * We want the earliest offline expire time
+				 * iff there is a new offline signature.
+				 */
+				if (!dst_key_isprivate(keys[i])) {
+					if (warn != 0 &&
+					    warn > rrsig.timeexpire)
+						warn = rrsig.timeexpire;
+					if (rdata.flags & DNS_RDATA_OFFLINE) {
+						if (maybe == 0 ||
+						    maybe > rrsig.timeexpire)
+							maybe =
+							     rrsig.timeexpire;
+						break;
+					}
+					if (warn == 0)
+						warn = maybe;
+					if (warn == 0 ||
+					    warn > rrsig.timeexpire)
+						warn = rrsig.timeexpire;
+					result = offline(db, ver, diff, name,
+							 rdataset.ttl, &rdata);
+					break;
+				}
+				result = update_one_rr(db, ver, diff,
+						       DNS_DIFFOP_DEL,
+						       name, rdataset.ttl,
+						       &rdata);
+				break;
+			}
+		}
+		/*
+		 * If there is not a matching DNSKEY then
+		 * delete the RRSIG.
+		 */
+		if (!found)
+			result = update_one_rr(db, ver, diff, DNS_DIFFOP_DEL,
+					       name, rdataset.ttl, &rdata);
+		dns_rdata_reset(&rdata);
+		if (result != ISC_R_SUCCESS)
+			break;
+	}
+	dns_rdataset_disassociate(&rdataset);
+	if (result == ISC_R_NOMORE)
+		result = ISC_R_SUCCESS;
+	if (warn != 0)
+		set_key_expiry_warning(zone, warn, now);
+ failure:
+	if (node != NULL)
+		dns_db_detachnode(db, &node);
+	return (result);
+}
+
+static isc_result_t
+add_sigs(dns_db_t *db, dns_dbversion_t *ver, dns_name_t *name,
+	 dns_rdatatype_t type, dns_diff_t *diff, dst_key_t **keys,
+	 unsigned int nkeys, isc_mem_t *mctx, isc_stdtime_t inception,
+	 isc_stdtime_t expire, isc_boolean_t check_ksk)
+{
+	isc_result_t result;
+	dns_dbnode_t *node = NULL;
+	dns_rdataset_t rdataset;
+	dns_rdata_t sig_rdata = DNS_RDATA_INIT;
+	unsigned char data[1024]; /* XXX */
+	isc_buffer_t buffer;
+	unsigned int i;
+
+	dns_rdataset_init(&rdataset);
+	isc_buffer_init(&buffer, data, sizeof(data));
+
+	if (type == dns_rdatatype_nsec3)
+		result = dns_db_findnsec3node(db, name, ISC_FALSE, &node);
+	else
+		result = dns_db_findnode(db, name, ISC_FALSE, &node);
+	if (result == ISC_R_NOTFOUND)
+		return (ISC_R_SUCCESS);
+	if (result != ISC_R_SUCCESS)
+		goto failure;
+	result = dns_db_findrdataset(db, node, ver, type, 0,
+				     (isc_stdtime_t) 0, &rdataset, NULL);
+	dns_db_detachnode(db, &node);
+	if (result == ISC_R_NOTFOUND)
+		return (ISC_R_SUCCESS);
+	if (result != ISC_R_SUCCESS)
+		goto failure;
+
+	for (i = 0; i < nkeys; i++) {
+		if (check_ksk && type != dns_rdatatype_dnskey &&
+		    (dst_key_flags(keys[i]) & DNS_KEYFLAG_KSK) != 0)
+			continue;
+		if (!dst_key_isprivate(keys[i]))
+			continue;
+		/* Calculate the signature, creating a RRSIG RDATA. */
+		CHECK(dns_dnssec_sign(name, &rdataset, keys[i],
+				      &inception, &expire,
+				      mctx, &buffer, &sig_rdata));
+		/* Update the database and journal with the RRSIG. */
+		/* XXX inefficient - will cause dataset merging */
+		CHECK(update_one_rr(db, ver, diff, DNS_DIFFOP_ADDRESIGN,
+				    name, rdataset.ttl, &sig_rdata));
+		dns_rdata_reset(&sig_rdata);
+	}
+
+ failure:
+	if (dns_rdataset_isassociated(&rdataset))
+		dns_rdataset_disassociate(&rdataset);
+	if (node != NULL)
+		dns_db_detachnode(db, &node);
+	return (result);
+}
+
+static void
+zone_resigninc(dns_zone_t *zone) {
+	const char *journalfile;
+	dns_db_t *db = NULL;
+	dns_dbversion_t *version = NULL;
+	dns_diff_t sig_diff;
+	dns_fixedname_t fixed;
+	dns_name_t *name;
+	dns_rdataset_t rdataset;
+	dns_rdatatype_t covers;
+	dst_key_t *zone_keys[MAXZONEKEYS];
+	isc_boolean_t check_ksk;
+	isc_result_t result;
+	isc_stdtime_t now, inception, soaexpire, expire, stop;
+	isc_uint32_t jitter;
+	unsigned int i;
+	unsigned int nkeys = 0;
+	unsigned int resign;
+
+	dns_rdataset_init(&rdataset);
+	dns_fixedname_init(&fixed);
+	dns_diff_init(zone->mctx, &sig_diff);
+	sig_diff.resign = zone->sigresigninginterval;
+
+	/*
+	 * Updates are disabled.  Pause for 5 minutes.
+	 */
+	if (zone->update_disabled) {
+		result = ISC_R_FAILURE;
+		goto failure;
+	}
+
+	ZONEDB_LOCK(&zone->dblock, isc_rwlocktype_read);
+	dns_db_attach(zone->db, &db);
+	ZONEDB_UNLOCK(&zone->dblock, isc_rwlocktype_read);
+
+	result = dns_db_newversion(db, &version);
+	if (result != ISC_R_SUCCESS) {
+		dns_zone_log(zone, ISC_LOG_ERROR,
+			     "zone_resigninc:dns_db_newversion -> %s\n",
+			     dns_result_totext(result));
+		goto failure;
+	}
+
+	result = find_zone_keys(zone, db, version, zone->mctx, MAXZONEKEYS,
+				zone_keys, &nkeys);
+	if (result != ISC_R_SUCCESS) {
+		dns_zone_log(zone, ISC_LOG_ERROR,
+			     "zone_resigninc:find_zone_keys -> %s\n",
+			     dns_result_totext(result));
+		goto failure;
+	}
+
+	isc_stdtime_get(&now);
+	inception = now - 3600;	/* Allow for clock skew. */
+	soaexpire = now + dns_zone_getsigvalidityinterval(zone);
+	/*
+	 * Spread out signatures over time if they happen to be
+	 * clumped.  We don't do this for each add_sigs() call as
+	 * we still want some clustering to occur.
+	 */
+	isc_random_get(&jitter);
+	expire = soaexpire - jitter % 3600;
+	stop = now + 5;
+
+	check_ksk = DNS_ZONE_OPTION(zone, DNS_ZONEOPT_UPDATECHECKKSK);
+	if (check_ksk)
+		check_ksk = ksk_sanity(db, version);
+
+	name = dns_fixedname_name(&fixed);
+	result = dns_db_getsigningtime(db, &rdataset, name);
+	if (result != ISC_R_SUCCESS && result != ISC_R_NOTFOUND) {
+		dns_zone_log(zone, ISC_LOG_ERROR,
+			     "zone_resigninc:dns_db_getsigningtime -> %s\n",
+			     dns_result_totext(result));
+	}
+
+	i = 0;
+	while (result == ISC_R_SUCCESS) {
+		resign = rdataset.resign;
+		covers = rdataset.covers;
+		/*
+		 * Stop if we hit the SOA as that means we have walked the
+		 * entire zone.  The SOA record should always be the most
+		 * recent signature.
+		 */
+		/* XXXMPA increase number of RRsets signed pre call */
+		if (covers == dns_rdatatype_soa || i++ > zone->signatures ||
+		    resign > stop) {
+			/*
+			 * Ensure that we don't loop resigning the SOA.
+			 */
+			if (covers == dns_rdatatype_soa)
+				dns_db_resigned(db, &rdataset, version);
+			dns_rdataset_disassociate(&rdataset);
+			break;
+		}
+
+		dns_db_resigned(db, &rdataset, version);
+		dns_rdataset_disassociate(&rdataset);
+
+		result = del_sigs(zone, db, version, name, covers, &sig_diff,
+				  zone_keys, nkeys, now);
+		if (result != ISC_R_SUCCESS) {
+			dns_zone_log(zone, ISC_LOG_ERROR,
+				     "zone_resigninc:del_sigs -> %s\n",
+				     dns_result_totext(result));
+			break;
+		}
+		result = add_sigs(db, version, name, covers, &sig_diff,
+				  zone_keys, nkeys, zone->mctx, inception,
+				  expire, check_ksk);
+		if (result != ISC_R_SUCCESS) {
+			dns_zone_log(zone, ISC_LOG_ERROR,
+				     "zone_resigninc:add_sigs -> %s\n",
+				     dns_result_totext(result));
+			break;
+		}
+		result  = dns_db_getsigningtime(db, &rdataset,
+						dns_fixedname_name(&fixed));
+		if (nkeys == 0 && result == ISC_R_NOTFOUND) {
+			result = ISC_R_SUCCESS;
+			break;
+		}
+		if (result != ISC_R_SUCCESS)
+			dns_zone_log(zone, ISC_LOG_ERROR,
+			     "zone_resigninc:dns_db_getsigningtime -> %s\n",
+				     dns_result_totext(result));
+	}
+
+	if (result != ISC_R_NOMORE && result != ISC_R_SUCCESS)
+		goto failure;
+
+	result = del_sigs(zone, db, version, &zone->origin, dns_rdatatype_soa,
+			  &sig_diff, zone_keys, nkeys, now);
+	if (result != ISC_R_SUCCESS) {
+		dns_zone_log(zone, ISC_LOG_ERROR,
+			     "zone_resigninc:del_sigs -> %s\n",
+			     dns_result_totext(result));
+		goto failure;
+	}
+
+	result = increment_soa_serial(db, version, &sig_diff, zone->mctx);
+	if (result != ISC_R_SUCCESS) {
+		dns_zone_log(zone, ISC_LOG_ERROR,
+			     "zone_resigninc:increment_soa_serial -> %s\n",
+			     dns_result_totext(result));
+		goto failure;
+	}
+
+	/*
+	 * Generate maximum life time signatures so that the above loop
+	 * termination is sensible.
+	 */
+	result = add_sigs(db, version, &zone->origin, dns_rdatatype_soa,
+			  &sig_diff, zone_keys, nkeys, zone->mctx, inception,
+			  soaexpire, check_ksk);
+	if (result != ISC_R_SUCCESS) {
+		dns_zone_log(zone, ISC_LOG_ERROR,
+			     "zone_resigninc:add_sigs -> %s\n",
+			     dns_result_totext(result));
+		goto failure;
+	}
+
+	journalfile = dns_zone_getjournal(zone);
+	if (journalfile != NULL) {
+		dns_journal_t *journal = NULL;
+		result = dns_journal_open(zone->mctx, journalfile,
+					  ISC_TRUE, &journal);
+		if (result != ISC_R_SUCCESS) {
+			dns_zone_log(zone, ISC_LOG_ERROR,
+				     "zone_resigninc:dns_journal_open -> %s\n",
+				     dns_result_totext(result));
+			goto failure;
+		}
+
+		result = dns_journal_write_transaction(journal, &sig_diff);
+		dns_journal_destroy(&journal);
+		if (result != ISC_R_SUCCESS) {
+			dns_zone_log(zone, ISC_LOG_ERROR,
+			 "zone_resigninc:dns_journal_write_transaction -> %s\n",
+				     dns_result_totext(result));
+			goto failure;
+		}
+	}
+
+	/*
+	 * Everything has succeeded. Commit the changes.
+	 */
+	dns_db_closeversion(db, &version, ISC_TRUE);
+
+ failure:
+	dns_diff_clear(&sig_diff);
+	for (i = 0; i < nkeys; i++)
+		dst_key_free(&zone_keys[i]);
+	if (version != NULL) {
+		dns_db_closeversion(zone->db, &version, ISC_FALSE);
+		dns_db_detach(&db);
+	} else if (db != NULL)
+		dns_db_detach(&db);
+	if (result == ISC_R_SUCCESS) {
+		set_resigntime(zone);
+		LOCK_ZONE(zone);
+		zone_needdump(zone, DNS_DUMP_DELAY);
+		DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_NEEDNOTIFY);
+		UNLOCK_ZONE(zone);
+	} else {
+		/*
+		 * Something failed.  Retry in 5 minutes.
+		 */
+		isc_interval_t ival;
+		isc_interval_set(&ival, 300, 0);
+		isc_time_nowplusinterval(&zone->resigntime, &ival);
+	}
+}
+
+static isc_result_t
+next_active(dns_db_t *db, dns_dbversion_t *version, dns_name_t *oldname,
+	    dns_name_t *newname, isc_boolean_t bottom)
+{
+	isc_result_t result;
+	dns_dbiterator_t *dbit = NULL;
+	dns_rdatasetiter_t *rdsit = NULL;
+	dns_dbnode_t *node = NULL;
+
+	CHECK(dns_db_createiterator(db, DNS_DB_NONSEC3, &dbit));
+	CHECK(dns_dbiterator_seek(dbit, oldname));
+	do {
+		result = dns_dbiterator_next(dbit);
+		if (result == ISC_R_NOMORE)
+			CHECK(dns_dbiterator_first(dbit));
+		CHECK(dns_dbiterator_current(dbit, &node, newname));
+		if (bottom && dns_name_issubdomain(newname, oldname) &&
+		    !dns_name_equal(newname, oldname)) {
+			dns_db_detachnode(db, &node);
+			continue;
+		}
+		/*
+		 * Is this node empty?
+		 */
+		CHECK(dns_db_allrdatasets(db, node, version, 0, &rdsit));
+		result = dns_rdatasetiter_first(rdsit);
+		dns_db_detachnode(db, &node);
+		dns_rdatasetiter_destroy(&rdsit);
+		if (result != ISC_R_NOMORE)
+			break;
+	} while (1);
+ failure:
+	if (node != NULL)
+		dns_db_detachnode(db, &node);
+	if (dbit != NULL)
+		dns_dbiterator_destroy(&dbit);
+	return (result);
+}
+
+static void
+set_bit(unsigned char *array, unsigned int index) {
+	unsigned int shift, mask;
+
+	shift = 7 - (index % 8);
+	mask = 1 << shift;
+
+	array[index / 8] |= mask;
+}
+
+static isc_boolean_t
+signed_with_key(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t *version,
+		dns_rdatatype_t type, dst_key_t *key)
+{
+	isc_result_t result;
+	dns_rdataset_t rdataset;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	dns_rdata_rrsig_t rrsig;
+
+	dns_rdataset_init(&rdataset);
+	result = dns_db_findrdataset(db, node, version, dns_rdatatype_rrsig,
+				     type, 0, &rdataset, NULL);
+	if (result != ISC_R_SUCCESS)
+		return (ISC_FALSE);
+	for (result = dns_rdataset_first(&rdataset);
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdataset_next(&rdataset)) {
+		dns_rdataset_current(&rdataset, &rdata);
+		result = dns_rdata_tostruct(&rdata, &rrsig, NULL);
+		INSIST(result == ISC_R_SUCCESS);
+		if (rrsig.algorithm == dst_key_alg(key) &&
+		    rrsig.keyid == dst_key_id(key)) {
+			dns_rdataset_disassociate(&rdataset);
+			return (ISC_TRUE);
+		}
+		dns_rdata_reset(&rdata);
+	}
+	dns_rdataset_disassociate(&rdataset);
+	return (ISC_FALSE);
+}
+
+static isc_result_t
+add_nsec(dns_db_t *db, dns_dbversion_t *version, dns_name_t *name,
+	 dns_dbnode_t *node, dns_ttl_t ttl, isc_boolean_t bottom,
+	 dns_diff_t *diff)
+{
+	dns_fixedname_t fixed;
+	dns_name_t *next;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	isc_result_t result;
+	unsigned char nsecbuffer[DNS_NSEC_BUFFERSIZE];
+
+	dns_fixedname_init(&fixed);
+	next = dns_fixedname_name(&fixed);
+
+	CHECK(next_active(db, version, name, next, bottom));
+	CHECK(dns_nsec_buildrdata(db, version, node, next, nsecbuffer,
+				  &rdata));
+	if (dns_name_equal(dns_db_origin(db), name)) {
+		/*
+		 * Set the OPT bit to indicate that this is a
+		 * partially secure zone.
+		 */
+		isc_region_t region;
+
+		dns_rdata_toregion(&rdata, &region);
+		dns_name_fromregion(next, &region);
+		isc_region_consume(&region, next->length);
+		INSIST(region.length > (2 + dns_rdatatype_opt / 8) &&
+		       region.base[0] == 0 &&
+		       region.base[1] > dns_rdatatype_opt / 8);
+		set_bit(region.base + 2, dns_rdatatype_opt);
+	}
+	CHECK(update_one_rr(db, version, diff, DNS_DIFFOP_ADD, name, ttl,
+			    &rdata));
+ failure:
+	return (result);
+}
+
+static isc_result_t
+sign_a_node(dns_db_t *db, dns_name_t *name, dns_dbnode_t *node,
+	    dns_dbversion_t *version, isc_boolean_t build_nsec3,
+	    isc_boolean_t build_nsec, dst_key_t *key,
+	    isc_stdtime_t inception, isc_stdtime_t expire,
+	    unsigned int minimum, isc_boolean_t is_ksk,
+	    isc_boolean_t *delegation, dns_diff_t *diff,
+	    isc_int32_t *signatures, isc_mem_t *mctx)
+{
+	isc_result_t result;
+	dns_rdatasetiter_t *iterator = NULL;
+	dns_rdataset_t rdataset;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	isc_buffer_t buffer;
+	unsigned char data[1024];
+	isc_boolean_t seen_soa, seen_ns, seen_rr, seen_dname, seen_nsec,
+		      seen_nsec3, seen_ds;
+	isc_boolean_t bottom;
+
+	result = dns_db_allrdatasets(db, node, version, 0, &iterator);
+	if (result != ISC_R_SUCCESS) {
+		if (result == ISC_R_NOTFOUND)
+			result = ISC_R_SUCCESS;
+		return (result);
+	}
+	dns_rdataset_init(&rdataset);
+	isc_buffer_init(&buffer, data, sizeof(data));
+	seen_rr = seen_soa = seen_ns = seen_dname = seen_nsec =
+	seen_nsec3 = seen_ds = ISC_FALSE;
+	for (result = dns_rdatasetiter_first(iterator);
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdatasetiter_next(iterator)) {
+		dns_rdatasetiter_current(iterator, &rdataset);
+		if (rdataset.type == dns_rdatatype_soa)
+			seen_soa = ISC_TRUE;
+		else if (rdataset.type == dns_rdatatype_ns)
+			seen_ns = ISC_TRUE;
+		else if (rdataset.type == dns_rdatatype_ds)
+			seen_ds = ISC_TRUE;
+		else if (rdataset.type == dns_rdatatype_dname)
+			seen_dname = ISC_TRUE;
+		else if (rdataset.type == dns_rdatatype_nsec)
+			seen_nsec = ISC_TRUE;
+		else if (rdataset.type == dns_rdatatype_nsec3)
+			seen_nsec3 = ISC_TRUE;
+		seen_rr = ISC_TRUE;
+		dns_rdataset_disassociate(&rdataset);
+	}
+	if (result != ISC_R_NOMORE)
+		goto failure;
+	if (seen_ns && !seen_soa)
+		*delegation = ISC_TRUE;
+	/*
+	 * Going from insecure to NSEC3.
+	 * Don't generate NSEC3 records for NSEC3 records.
+	 */
+	if (build_nsec3 && !seen_nsec3 && seen_rr) {
+		isc_boolean_t unsecure = !seen_ds && seen_ns && !seen_soa;
+		CHECK(dns_nsec3_addnsec3s(db, version, name, minimum,
+					  unsecure, diff));
+		(*signatures)--;
+	}
+	/*
+	 * Going from insecure to NSEC.
+	 * Don't generate NSEC records for NSEC3 records.
+	 */
+	if (build_nsec && !seen_nsec3 && !seen_nsec && seen_rr) {
+		/* Build and add NSEC. */
+		bottom = (seen_ns && !seen_soa) || seen_dname;
+		CHECK(add_nsec(db, version, name, node, minimum, bottom, diff));
+		/* Count a NSEC generation as a signature generation. */
+		(*signatures)--;
+	}
+	result = dns_rdatasetiter_first(iterator);
+	while (result == ISC_R_SUCCESS) {
+		dns_rdatasetiter_current(iterator, &rdataset);
+		if (rdataset.type == dns_rdatatype_soa ||
+		    rdataset.type == dns_rdatatype_rrsig)
+			goto next_rdataset;
+		if (is_ksk && rdataset.type != dns_rdatatype_dnskey)
+			goto next_rdataset;
+		if (*delegation &&
+		    rdataset.type != dns_rdatatype_ds &&
+		    rdataset.type != dns_rdatatype_nsec)
+			goto next_rdataset;
+		if (signed_with_key(db, node, version, rdataset.type, key))
+			goto next_rdataset;
+		/* Calculate the signature, creating a RRSIG RDATA. */
+		CHECK(dns_dnssec_sign(name, &rdataset, key, &inception,
+				      &expire, mctx, &buffer, &rdata));
+		/* Update the database and journal with the RRSIG. */
+		/* XXX inefficient - will cause dataset merging */
+		CHECK(update_one_rr(db, version, diff, DNS_DIFFOP_ADDRESIGN,
+				    name, rdataset.ttl, &rdata));
+		dns_rdata_reset(&rdata);
+		(*signatures)--;
+ next_rdataset:
+		dns_rdataset_disassociate(&rdataset);
+		result = dns_rdatasetiter_next(iterator);
+	}
+	if (result == ISC_R_NOMORE)
+		result = ISC_R_SUCCESS;
+	if (seen_dname)
+		*delegation = ISC_TRUE;
+failure:
+	if (dns_rdataset_isassociated(&rdataset))
+		dns_rdataset_disassociate(&rdataset);
+	if (iterator != NULL)
+		dns_rdatasetiter_destroy(&iterator);
+	return (result);
+}
+
+static isc_result_t
+updatesecure(dns_db_t *db, dns_dbversion_t *version, dns_name_t *name,
+	     dns_ttl_t minimum, isc_boolean_t *secureupdated, dns_diff_t *diff)
+{
+	isc_result_t result;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	unsigned char nsecbuffer[DNS_NSEC_BUFFERSIZE];
+	dns_rdataset_t rdataset;
+	dns_rdata_nsec_t nsec;
+	dns_dbnode_t *node = NULL;
+
+	/*
+	 * Check to see if the OPT bit has already been cleared.
+	 */
+	CHECK(dns_db_getoriginnode(db, &node));
+	dns_rdataset_init(&rdataset);
+	CHECK(dns_db_findrdataset(db, node, version, dns_rdatatype_nsec,
+				  dns_rdatatype_none, 0, &rdataset, NULL));
+	CHECK(dns_rdataset_first(&rdataset));
+	dns_rdataset_current(&rdataset, &rdata);
+
+	/*
+	 * Find the NEXT name for building the new record.
+	 */
+	CHECK(dns_rdata_tostruct(&rdata, &nsec, NULL));
+
+	/*
+	 * Delete the old NSEC record.
+	 */
+	CHECK(update_one_rr(db, version, diff, DNS_DIFFOP_DEL, name, minimum,
+			    &rdata));
+	dns_rdata_reset(&rdata);
+
+	/*
+	 * Add the new NSEC record.
+	 */
+	CHECK(dns_nsec_buildrdata(db, version, node, &nsec.next, nsecbuffer,
+				  &rdata));
+	CHECK(update_one_rr(db, version, diff, DNS_DIFFOP_ADD, name, minimum,
+			    &rdata));
+	dns_rdata_reset(&rdata);
+
+	if (secureupdated != NULL)
+		*secureupdated = ISC_TRUE;
+
+ failure:
+	if (node != NULL)
+		dns_db_detachnode(db, &node);
+	if (dns_rdataset_isassociated(&rdataset))
+		dns_rdataset_disassociate(&rdataset);
+	return (result);
+}
+
+static isc_result_t
+updatesignwithkey(dns_signing_t *signing, dns_dbversion_t *version,
+		  dns_name_t *name, dns_rdatatype_t privatetype,
+		  dns_diff_t *diff)
+{
+	isc_result_t result;
+	dns_dbnode_t *node = NULL;
+	dns_rdataset_t rdataset;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	unsigned char data[5];
+	isc_boolean_t seen_done = ISC_FALSE;
+
+	dns_rdataset_init(&rdataset);
+	result = dns_db_getoriginnode(signing->db, &node);
+	if (result != ISC_R_SUCCESS)
+		goto failure;
+
+	result = dns_db_findrdataset(signing->db, node, version, privatetype,
+				     dns_rdatatype_none, 0, &rdataset, NULL);
+	if (result == ISC_R_NOTFOUND) {
+		result = ISC_R_SUCCESS;
+		goto failure;
+	}
+	if (result != ISC_R_SUCCESS)
+		goto failure;
+	for (result = dns_rdataset_first(&rdataset);
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdataset_next(&rdataset)) {
+		dns_rdataset_current(&rdataset, &rdata);
+		if (rdata.length != 5 ||
+		    rdata.data[0] != signing->algorithm ||
+		    rdata.data[1] != ((signing->keyid >> 8) & 0xff) ||
+		    rdata.data[2] != (signing->keyid & 0xff)) {
+			dns_rdata_reset(&rdata);
+			continue;
+		}
+		if (!signing->delete && rdata.data[4] != 0)
+			seen_done = ISC_TRUE;
+		else
+			CHECK(update_one_rr(signing->db, version, diff,
+					    DNS_DIFFOP_DEL, name,							    rdataset.ttl, &rdata));
+		dns_rdata_reset(&rdata);
+	}
+	if (result == ISC_R_NOMORE)
+		result = ISC_R_SUCCESS;
+	if (!signing->delete && !seen_done) {
+
+		data[0] = signing->algorithm;
+		data[1] = (signing->keyid >> 8) & 0xff;
+		data[2] = signing->keyid & 0xff;
+		data[3] = 0;
+		data[4] = 1;
+		rdata.length = sizeof(data);
+		rdata.data = data;
+		rdata.type = privatetype;
+		rdata.rdclass = dns_db_class(signing->db);
+		CHECK(update_one_rr(signing->db, version, diff, DNS_DIFFOP_ADD,
+				    name, rdataset.ttl, &rdata));
+	}
+ failure:
+	if (dns_rdataset_isassociated(&rdataset))
+		dns_rdataset_disassociate(&rdataset);
+	if (node != NULL)
+		dns_db_detachnode(signing->db, &node);
+	return (result);
+}
+
+static isc_result_t
+fixup_nsec3param(dns_db_t *db, dns_dbversion_t *ver, dns_nsec3chain_t *chain,
+		 isc_boolean_t active, dns_diff_t *diff)
+{
+	dns_dbnode_t *node = NULL;
+	dns_name_t *name = dns_db_origin(db);
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	dns_rdataset_t rdataset;
+	dns_rdata_nsec3param_t nsec3param;
+	isc_result_t result;
+	isc_buffer_t buffer;
+	unsigned char parambuf[DNS_NSEC3PARAM_BUFFERSIZE];
+	dns_ttl_t ttl = 0;
+
+	dns_rdataset_init(&rdataset);
+
+	result = dns_db_getoriginnode(db, &node);
+	RUNTIME_CHECK(result == ISC_R_SUCCESS);
+	result = dns_db_findrdataset(db, node, ver, dns_rdatatype_nsec3param,
+				     0, 0, &rdataset, NULL);
+	if (result == ISC_R_NOTFOUND)
+		goto add;
+	if (result != ISC_R_SUCCESS)
+		goto failure;
+
+	/*
+	 * Preserve the existing ttl.
+	 */
+	ttl = rdataset.ttl;
+
+	/*
+	 * Delete all NSEC3PARAM records which match that in nsec3chain.
+	 */
+	for (result = dns_rdataset_first(&rdataset);
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdataset_next(&rdataset)) {
+
+		dns_rdataset_current(&rdataset, &rdata);
+		CHECK(dns_rdata_tostruct(&rdata, &nsec3param, NULL));
+
+		if (nsec3param.hash != chain->nsec3param.hash ||
+		    (active && nsec3param.flags != 0) ||
+		    nsec3param.iterations != chain->nsec3param.iterations ||
+		    nsec3param.salt_length != chain->nsec3param.salt_length ||
+		    memcmp(nsec3param.salt, chain->nsec3param.salt,
+			   nsec3param.salt_length)) {
+			dns_rdata_reset(&rdata);
+			continue;
+		}
+
+		CHECK(update_one_rr(db, ver, diff, DNS_DIFFOP_DEL,
+				    name, rdataset.ttl, &rdata));
+		dns_rdata_reset(&rdata);
+	}
+	if (result != ISC_R_NOMORE)
+		goto failure;
+
+  add:
+	if ((chain->nsec3param.flags & DNS_NSEC3FLAG_REMOVE) != 0) {
+		result = ISC_R_SUCCESS;
+		goto failure;
+	}
+
+	/*
+	 * Add a NSEC3PARAM record which matches that in nsec3chain but
+	 * with all flags bits cleared.
+	 *
+	 * Note: we do not clear chain->nsec3param.flags as this change
+	 * may be reversed.
+	 */
+	isc_buffer_init(&buffer, &parambuf, sizeof(parambuf));
+	CHECK(dns_rdata_fromstruct(&rdata, dns_db_class(db),
+				   dns_rdatatype_nsec3param,
+				   &chain->nsec3param, &buffer));
+	rdata.data[1] = 0;	/* Clear flag bits. */
+	CHECK(update_one_rr(db, ver, diff, DNS_DIFFOP_ADD, name, ttl, &rdata));
+
+  failure:
+	dns_db_detachnode(db, &node);
+	if (dns_rdataset_isassociated(&rdataset))
+		dns_rdataset_disassociate(&rdataset);
+	return (result);
+}
+
+static isc_result_t
+delete_nsec(dns_db_t *db, dns_dbversion_t *ver, dns_dbnode_t *node,
+	    dns_name_t *name, dns_diff_t *diff)
+{
+	dns_rdataset_t rdataset;
+	isc_result_t result;
+
+	dns_rdataset_init(&rdataset);
+
+	result = dns_db_findrdataset(db, node, ver, dns_rdatatype_nsec,
+				     0, 0, &rdataset, NULL);
+	if (result == ISC_R_NOTFOUND)
+		return (ISC_R_SUCCESS);
+	if (result != ISC_R_SUCCESS)
+		return (result);
+	for (result = dns_rdataset_first(&rdataset);
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdataset_next(&rdataset)) {
+		dns_rdata_t rdata = DNS_RDATA_INIT;
+
+		dns_rdataset_current(&rdataset, &rdata);
+		CHECK(update_one_rr(db, ver, diff, DNS_DIFFOP_DEL, name,
+				    rdataset.ttl, &rdata));
+	}
+	if (result == ISC_R_NOMORE)
+		result = ISC_R_SUCCESS;
+ failure:
+	dns_rdataset_disassociate(&rdataset);
+	return (result);
+}
+
+static isc_result_t
+deletematchingnsec3(dns_db_t *db, dns_dbversion_t *ver, dns_dbnode_t *node,
+		    dns_name_t *name, const dns_rdata_nsec3param_t *param,
+		    dns_diff_t *diff)
+{
+	dns_rdataset_t rdataset;
+	dns_rdata_nsec3_t nsec3;
+	isc_result_t result;
+
+	dns_rdataset_init(&rdataset);
+	result = dns_db_findrdataset(db, node, ver, dns_rdatatype_nsec3,
+				     0, 0, &rdataset, NULL);
+	if (result == ISC_R_NOTFOUND)
+		return (ISC_R_SUCCESS);
+	if (result != ISC_R_SUCCESS)
+		return (result);
+
+	for (result = dns_rdataset_first(&rdataset);
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdataset_next(&rdataset)) {
+		dns_rdata_t rdata = DNS_RDATA_INIT;
+
+		dns_rdataset_current(&rdataset, &rdata);
+		CHECK(dns_rdata_tostruct(&rdata, &nsec3, NULL));
+		if (nsec3.hash != param->hash ||
+		    nsec3.iterations != param->iterations ||
+		    nsec3.salt_length != param->salt_length ||
+		    memcmp(nsec3.salt, param->salt, nsec3.salt_length))
+			continue;
+		CHECK(update_one_rr(db, ver, diff, DNS_DIFFOP_DEL, name,
+				    rdataset.ttl, &rdata));
+	}
+	if (result == ISC_R_NOMORE)
+		result = ISC_R_SUCCESS;
+ failure:
+	dns_rdataset_disassociate(&rdataset);
+	return (result);
+}
+
+static isc_result_t
+need_nsec_chain(dns_db_t *db, dns_dbversion_t *ver,
+		const dns_rdata_nsec3param_t *param,
+		isc_boolean_t *answer, isc_boolean_t *updatensec)
+{
+	dns_dbnode_t *node = NULL;
+	dns_rdata_t rdata = DNS_RDATA_INIT;
+	dns_rdata_nsec3param_t myparam;
+	dns_rdataset_t rdataset;
+	isc_result_t result;
+
+	*answer = ISC_FALSE;
+
+	result = dns_db_getoriginnode(db, &node);
+	RUNTIME_CHECK(result == ISC_R_SUCCESS);
+
+	dns_rdataset_init(&rdataset);
+	result = dns_db_findrdataset(db, node, ver, dns_rdatatype_nsec,
+				     0, 0, &rdataset, NULL);
+	if (result == ISC_R_NOTFOUND)
+		goto check_nsec3param;
+
+	if (result != ISC_R_SUCCESS)
+		goto failure;
+
+	CHECK(dns_rdataset_first(&rdataset));
+	dns_rdataset_current(&rdataset, &rdata);
+
+	if (!dns_nsec_typepresent(&rdata, dns_rdatatype_opt)) {
+		/*
+		 * We have a complete NSEC chain.  Signal to update
+		 * the apex NSEC record.
+		 */
+		*updatensec = ISC_TRUE;
+		goto failure;
+	}
+	dns_rdataset_disassociate(&rdataset);
+	dns_rdata_reset(&rdata);
+
+ check_nsec3param:
+	result = dns_db_findrdataset(db, node, ver, dns_rdatatype_nsec3param,
+				     0, 0, &rdataset, NULL);
+	if (result == ISC_R_NOTFOUND) {
+		*answer = ISC_TRUE;
+		dns_db_detachnode(db, &node);
+		return (ISC_R_SUCCESS);
+	}
+	if (result != ISC_R_SUCCESS) {
+		dns_db_detachnode(db, &node);
+		return (result);
+	}
+
+	for (result = dns_rdataset_first(&rdataset);
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdataset_next(&rdataset)) {
+		dns_rdataset_current(&rdataset, &rdata);
+		CHECK(dns_rdata_tostruct(&rdata, &myparam, NULL));
+		dns_rdata_reset(&rdata);
+		/*
+		 * Ignore any NSEC3PARAM removals.
+		 */
+		if (NSEC3REMOVE(myparam.flags))
+			continue;
+		/*
+		 * Ignore the chain that we are in the process of deleting.
+		 */
+		if (myparam.hash == param->hash &&
+		    myparam.iterations == param->iterations &&
+		    myparam.salt_length == param->salt_length &&
+		    !memcmp(myparam.salt, param->salt, myparam.salt_length))
+			continue;
+		/*
+		 * Found an active NSEC3 chain.
+		 */
+		break;
+	}
+	if (result == ISC_R_NOMORE) {
+		*answer = ISC_TRUE;
+		result = ISC_R_SUCCESS;
+	}
+
+ failure:
+	if (dns_rdataset_isassociated(&rdataset))
+		dns_rdataset_disassociate(&rdataset);
+	dns_db_detachnode(db, &node);
+	return (result);
+}
+
+/*
+ * Incrementally build and sign a new NSEC3 chain using the parameters
+ * requested.
+ */
+static void
+zone_nsec3chain(dns_zone_t *zone) {
+	const char *journalfile;
+	dns_db_t *db = NULL;
+	dns_dbnode_t *node = NULL;
+	dns_dbversion_t *version = NULL;
+	dns_diff_t sig_diff;
+	dns_diff_t nsec_diff;
+	dns_diff_t nsec3_diff;
+	dns_diff_t param_diff;
+	dns_fixedname_t fixed;
+	dns_fixedname_t nextfixed;
+	dns_name_t *name, *nextname;
+	dns_rdataset_t rdataset;
+	dns_nsec3chain_t *nsec3chain = NULL, *nextnsec3chain;
+	dns_nsec3chainlist_t cleanup;
+	dst_key_t *zone_keys[MAXZONEKEYS];
+	isc_int32_t signatures;
+	isc_boolean_t check_ksk, is_ksk;
+	isc_boolean_t delegation;
+	isc_boolean_t first;
+	isc_result_t result;
+	isc_stdtime_t now, inception, soaexpire, expire, stop;
+	isc_uint32_t jitter;
+	unsigned int i;
+	unsigned int nkeys = 0;
+	isc_uint32_t nodes;
+	isc_boolean_t unsecure = ISC_FALSE;
+	isc_boolean_t seen_soa, seen_ns, seen_dname, seen_ds;
+	isc_boolean_t seen_nsec, seen_nsec3, seen_rr;
+	dns_rdatasetiter_t *iterator = NULL;
+	dns_difftuple_t *tuple;
+	isc_boolean_t buildnsecchain;
+	isc_boolean_t updatensec = ISC_FALSE;
+
+	dns_rdataset_init(&rdataset);
+	dns_fixedname_init(&fixed);
+	name = dns_fixedname_name(&fixed);
+	dns_fixedname_init(&nextfixed);
+	nextname = dns_fixedname_name(&nextfixed);
+	dns_diff_init(zone->mctx, &param_diff);
+	dns_diff_init(zone->mctx, &nsec3_diff);
+	dns_diff_init(zone->mctx, &nsec_diff);
+	dns_diff_init(zone->mctx, &sig_diff);
+	sig_diff.resign = zone->sigresigninginterval;
+	ISC_LIST_INIT(cleanup);
+
+	/*
+	 * Updates are disabled.  Pause for 5 minutes.
+	 */
+	if (zone->update_disabled) {
+		result = ISC_R_FAILURE;
+		goto failure;
+	}
+
+	ZONEDB_LOCK(&zone->dblock, isc_rwlocktype_read);
+	dns_db_attach(zone->db, &db);
+	ZONEDB_UNLOCK(&zone->dblock, isc_rwlocktype_read);
+
+	result = dns_db_newversion(db, &version);
+	if (result != ISC_R_SUCCESS) {
+		dns_zone_log(zone, ISC_LOG_ERROR,
+			     "zone_nsec3chain:dns_db_newversion -> %s\n",
+			     dns_result_totext(result));
+		goto failure;
+	}
+
+	result = find_zone_keys(zone, db, version, zone->mctx,
+				MAXZONEKEYS, zone_keys, &nkeys);
+	if (result != ISC_R_SUCCESS) {
+		dns_zone_log(zone, ISC_LOG_ERROR,
+			     "zone_nsec3chain:find_zone_keys -> %s\n",
+			     dns_result_totext(result));
+		goto failure;
+	}
+
+	isc_stdtime_get(&now);
+	inception = now - 3600;	/* Allow for clock skew. */
+	soaexpire = now + dns_zone_getsigvalidityinterval(zone);
+
+	/*
+	 * Spread out signatures over time if they happen to be
+	 * clumped.  We don't do this for each add_sigs() call as
+	 * we still want some clustering to occur.
+	 */
+	isc_random_get(&jitter);
+	expire = soaexpire - jitter % 3600;
+	stop = now + 5;
+
+	check_ksk = DNS_ZONE_OPTION(zone, DNS_ZONEOPT_UPDATECHECKKSK);
+	if (check_ksk)
+		check_ksk = ksk_sanity(db, version);
+
+	/*
+	 * We keep pulling nodes off each iterator in turn until
+	 * we have no more nodes to pull off or we reach the limits
+	 * for this quantum.
+	 */
+	nodes = zone->nodes;
+	signatures = zone->signatures;
+	LOCK_ZONE(zone);
+	nsec3chain = ISC_LIST_HEAD(zone->nsec3chain);
+	UNLOCK_ZONE(zone);
+	first = ISC_TRUE;
+
+	if (nsec3chain != NULL)
+		nsec3chain->save_delete_nsec = nsec3chain->delete_nsec;
+	/*
+	 * Generate new NSEC3 chains first.
+	 */
+	while (nsec3chain != NULL && nodes-- > 0 && signatures > 0) {
+		LOCK_ZONE(zone);
+		nextnsec3chain = ISC_LIST_NEXT(nsec3chain, link);
+
+		ZONEDB_LOCK(&zone->dblock, isc_rwlocktype_read);
+		if (nsec3chain->done || nsec3chain->db != zone->db) {
+			ISC_LIST_UNLINK(zone->nsec3chain, nsec3chain, link);
+			ISC_LIST_APPEND(cleanup, nsec3chain, link);
+		}
+		ZONEDB_UNLOCK(&zone->dblock, isc_rwlocktype_read);
+		UNLOCK_ZONE(zone);
+		if (ISC_LIST_TAIL(cleanup) == nsec3chain)
+			goto next_addchain;
+
+		/*
+		 * Possible future db.
+		 */
+		if (nsec3chain->db != db) {
+			goto next_addchain;
+		}
+
+		if (NSEC3REMOVE(nsec3chain->nsec3param.flags))
+			goto next_addchain;
+
+		is_ksk = ISC_FALSE;
+		delegation = ISC_FALSE;
+		dns_dbiterator_current(nsec3chain->dbiterator, &node, name);
+
+		if (nsec3chain->delete_nsec) {
+			delegation = ISC_FALSE;
+			dns_dbiterator_pause(nsec3chain->dbiterator);
+			CHECK(delete_nsec(db, version, node, name, &nsec_diff));
+			goto next_addnode;
+		}
+		/*
+		 * On the first pass we need to check if the current node
+		 * has not been obscured.
+		 */
+		delegation = ISC_FALSE;
+		unsecure = ISC_FALSE;
+		if (first) {
+			dns_fixedname_t ffound;
+			dns_name_t *found;
+			dns_fixedname_init(&ffound);
+			found = dns_fixedname_name(&ffound);
+			result = dns_db_find(db, name, version,
+					     dns_rdatatype_soa,
+					     DNS_DBFIND_NOWILD, 0, NULL, found,
+					     NULL, NULL);
+			if ((result == DNS_R_DELEGATION ||
+			    result == DNS_R_DNAME) &&
+			    !dns_name_equal(name, found)) {
+				/*
+				 * Remember the obscuring name so that
+				 * we skip all obscured names.
+				 */
+				dns_name_copy(found, name, NULL);
+				delegation = ISC_TRUE;
+				goto next_addnode;
+			}
+		}
+
+		/*
+		 * Check to see if this is a bottom of zone node.
+		 */
+		result = dns_db_allrdatasets(db, node, version, 0, &iterator);
+		if (result == ISC_R_NOTFOUND)	/* Empty node? */
+			goto next_addnode;
+		if (result != ISC_R_SUCCESS)
+			goto failure;
+
+		seen_soa = seen_ns = seen_dname = seen_ds = seen_nsec =
+			ISC_FALSE;
+		for (result = dns_rdatasetiter_first(iterator);
+		     result == ISC_R_SUCCESS;
+		     result = dns_rdatasetiter_next(iterator)) {
+			dns_rdatasetiter_current(iterator, &rdataset);
+			INSIST(rdataset.type != dns_rdatatype_nsec3);
+			if (rdataset.type == dns_rdatatype_soa)
+				seen_soa = ISC_TRUE;
+			else if (rdataset.type == dns_rdatatype_ns)
+				seen_ns = ISC_TRUE;
+			else if (rdataset.type == dns_rdatatype_dname)
+				seen_dname = ISC_TRUE;
+			else if (rdataset.type == dns_rdatatype_ds)
+				seen_ds = ISC_TRUE;
+			else if (rdataset.type == dns_rdatatype_nsec)
+				seen_nsec = ISC_TRUE;
+			dns_rdataset_disassociate(&rdataset);
+		}
+		dns_rdatasetiter_destroy(&iterator);
+		/*
+		 * Is there a NSEC chain than needs to be cleaned up?
+		 */
+		if (seen_nsec)
+			nsec3chain->seen_nsec = ISC_TRUE;
+		if (seen_ns && !seen_soa && !seen_ds)
+			unsecure = ISC_TRUE;
+		if ((seen_ns && !seen_soa) || seen_dname)
+			delegation = ISC_TRUE;
+
+		/*
+		 * Process one node.
+		 */
+		dns_dbiterator_pause(nsec3chain->dbiterator);
+		CHECK(dns_nsec3_addnsec3(db, version, name,
+					 &nsec3chain->nsec3param,
+					 zone->minimum, unsecure, &nsec3_diff));
+		/*
+		 * Treat each call to dns_nsec3_addnsec3() as if it's cost is
+		 * two signatures.  Additionally there will, in general, be
+		 * two signature generated below.
+		 *
+		 * If we are only changing the optout flag the cost is half
+		 * that of the cost of generating a completely new chain.
+		 */
+		signatures -= 4;
+
+		/*
+		 * Go onto next node.
+		 */
+ next_addnode:
+		first = ISC_FALSE;
+		dns_db_detachnode(db, &node);
+		do {
+			result = dns_dbiterator_next(nsec3chain->dbiterator);
+
+			if (result == ISC_R_NOMORE && nsec3chain->delete_nsec) {
+				CHECK(fixup_nsec3param(db, version, nsec3chain,
+						       ISC_FALSE, &param_diff));
+				LOCK_ZONE(zone);
+				ISC_LIST_UNLINK(zone->nsec3chain, nsec3chain,
+						link);
+				UNLOCK_ZONE(zone);
+				ISC_LIST_APPEND(cleanup, nsec3chain, link);
+				goto next_addchain;
+			}
+			if (result == ISC_R_NOMORE) {
+				dns_dbiterator_pause(nsec3chain->dbiterator);
+				if (nsec3chain->seen_nsec) {
+					CHECK(fixup_nsec3param(db, version,
+							       nsec3chain,
+							       ISC_TRUE,
+							       &param_diff));
+					nsec3chain->delete_nsec = ISC_TRUE;
+					goto same_addchain;
+				}
+				CHECK(fixup_nsec3param(db, version, nsec3chain,
+						       ISC_FALSE, &param_diff));
+				LOCK_ZONE(zone);
+				ISC_LIST_UNLINK(zone->nsec3chain, nsec3chain,
+						link);
+				UNLOCK_ZONE(zone);
+				ISC_LIST_APPEND(cleanup, nsec3chain, link);
+				goto next_addchain;
+			} else if (result != ISC_R_SUCCESS) {
+				dns_zone_log(zone, ISC_LOG_ERROR,
+					     "zone_nsec3chain:"
+					     "dns_dbiterator_next -> %s\n",
+					     dns_result_totext(result));
+				goto failure;
+			} else if (delegation) {
+				dns_dbiterator_current(nsec3chain->dbiterator,
+						       &node, nextname);
+				dns_db_detachnode(db, &node);
+				if (!dns_name_issubdomain(nextname, name))
+					break;
+			} else
+				break;
+		} while (1);
+		continue;
+
+ same_addchain:
+		CHECK(dns_dbiterator_first(nsec3chain->dbiterator));
+		first = ISC_TRUE;
+		continue;
+
+ next_addchain:
+		dns_dbiterator_pause(nsec3chain->dbiterator);
+		nsec3chain = nextnsec3chain;
+		first = ISC_TRUE;
+		if (nsec3chain != NULL)
+			nsec3chain->save_delete_nsec = nsec3chain->delete_nsec;
+	}
+
+	/*
+	 * Process removals.
+	 */
+	LOCK_ZONE(zone);
+	nsec3chain = ISC_LIST_HEAD(zone->nsec3chain);
+	UNLOCK_ZONE(zone);
+	first = ISC_TRUE;
+	buildnsecchain = ISC_FALSE;
+	while (nsec3chain != NULL && nodes-- > 0 && signatures > 0) {
+		LOCK_ZONE(zone);
+		nextnsec3chain = ISC_LIST_NEXT(nsec3chain, link);
+		UNLOCK_ZONE(zone);
+
+		if (nsec3chain->db != db)
+			goto next_removechain;
+
+		if (!NSEC3REMOVE(nsec3chain->nsec3param.flags))
+			goto next_removechain;
+
+		/*
+		 * Work out if we need to build a NSEC chain as a consequence
+		 * of removing this NSEC3 chain.
+		 */
+		if (first && !updatensec &&
+		    (nsec3chain->nsec3param.flags & DNS_NSEC3FLAG_NONSEC) == 0)
+			CHECK(need_nsec_chain(db, version,
+					      &nsec3chain->nsec3param,
+					      &buildnsecchain, &updatensec));
+
+		dns_dbiterator_current(nsec3chain->dbiterator, &node, name);
+		delegation = ISC_FALSE;
+
+		if (!buildnsecchain) {
+			/*
+			 * Delete the NSECPARAM record that matches this chain.
+			 */
+			if (first)
+				CHECK(fixup_nsec3param(db, version, nsec3chain,
+						       ISC_TRUE, &param_diff));
+
+			/*
+			 *  Delete the NSEC3 records.
+			 */
+			CHECK(deletematchingnsec3(db, version, node, name,
+						  &nsec3chain->nsec3param,
+						  &nsec3_diff));
+			goto next_removenode;
+		}
+
+		if (first) {
+			dns_fixedname_t ffound;
+			dns_name_t *found;
+			dns_fixedname_init(&ffound);
+			found = dns_fixedname_name(&ffound);
+			result = dns_db_find(db, name, version,
+					     dns_rdatatype_soa,
+					     DNS_DBFIND_NOWILD, 0, NULL, found,
+					     NULL, NULL);
+			if ((result == DNS_R_DELEGATION ||
+			     result == DNS_R_DNAME) &&
+			    !dns_name_equal(name, found)) {
+				/*
+				 * Remember the obscuring name so that
+				 * we skip all obscured names.
+				 */
+				dns_name_copy(found, name, NULL);
+				delegation = ISC_TRUE;
+				goto next_removenode;
+			}
+		}
+
+		/*
+		 * Check to see if this is a bottom of zone node.
+		 */
+		result = dns_db_allrdatasets(db, node, version, 0, &iterator);
+		if (result == ISC_R_NOTFOUND)	/* Empty node? */
+			goto next_removenode;
+		if (result != ISC_R_SUCCESS)
+			goto failure;
+
+		seen_soa = seen_ns = seen_dname = seen_nsec3 = seen_nsec =
+			seen_rr = ISC_FALSE;
+		for (result = dns_rdatasetiter_first(iterator);
+		     result == ISC_R_SUCCESS;
+		     result = dns_rdatasetiter_next(iterator)) {
+			dns_rdatasetiter_current(iterator, &rdataset);
+			if (rdataset.type == dns_rdatatype_soa)
+				seen_soa = ISC_TRUE;
+			else if (rdataset.type == dns_rdatatype_ns)
+				seen_ns = ISC_TRUE;
+			else if (rdataset.type == dns_rdatatype_dname)
+				seen_dname = ISC_TRUE;
+			else if (rdataset.type == dns_rdatatype_nsec)
+				seen_nsec = ISC_TRUE;
+			else if (rdataset.type == dns_rdatatype_nsec3)
+				seen_nsec3 = ISC_TRUE;
+			seen_rr = ISC_TRUE;
+			dns_rdataset_disassociate(&rdataset);
+		}
+		dns_rdatasetiter_destroy(&iterator);
+
+		if (!seen_rr || seen_nsec3 || seen_nsec)
+			goto next_removenode;
+		if ((seen_ns && !seen_soa) || seen_dname)
+			delegation = ISC_TRUE;
+
+		CHECK(add_nsec(db, version, name, node, zone->minimum,
+			       delegation, &nsec_diff));
+
+ next_removenode:
+		first = ISC_FALSE;
+		dns_db_detachnode(db, &node);
+		do {
+			result = dns_dbiterator_next(nsec3chain->dbiterator);
+			if (result == ISC_R_NOMORE && buildnsecchain) {
+				/*
+				 * The NSEC chain should now be built.
+				 * We can now remove the NSEC3 chain.
+				 */
+				updatensec = ISC_TRUE;
+				goto same_removechain;
+			}
+			if (result == ISC_R_NOMORE) {
+				LOCK_ZONE(zone);
+				ISC_LIST_UNLINK(zone->nsec3chain, nsec3chain,
+						link);
+				UNLOCK_ZONE(zone);
+				ISC_LIST_APPEND(cleanup, nsec3chain, link);
+				dns_dbiterator_pause(nsec3chain->dbiterator);
+				CHECK(fixup_nsec3param(db, version, nsec3chain,
+						       ISC_FALSE, &param_diff));
+				goto next_removechain;
+			} else if (result != ISC_R_SUCCESS) {
+				dns_zone_log(zone, ISC_LOG_ERROR,
+					     "zone_nsec3chain:"
+					     "dns_dbiterator_next -> %s\n",
+					     dns_result_totext(result));
+				goto failure;
+			} else if (delegation) {
+				dns_dbiterator_current(nsec3chain->dbiterator,
+						       &node, nextname);
+				dns_db_detachnode(db, &node);
+				if (!dns_name_issubdomain(nextname, name))
+					break;
+			} else
+				break;
+		} while (1);
+		continue;
+
+ same_removechain:
+		CHECK(dns_dbiterator_first(nsec3chain->dbiterator));
+		buildnsecchain = ISC_FALSE;
+		first = ISC_TRUE;
+		continue;
+
+ next_removechain:
+		dns_dbiterator_pause(nsec3chain->dbiterator);
+		nsec3chain = nextnsec3chain;
+		first = ISC_TRUE;
+	}
+
+	/*
+	 * Add / update signatures for the NSEC3 records.
+	 */
+	for (tuple = ISC_LIST_HEAD(nsec3_diff.tuples);
+	     tuple != NULL;
+	     tuple = ISC_LIST_HEAD(nsec3_diff.tuples)) {
+		/*
+		 * We have changed the NSEC3 RRset above so we need to update
+		 * the signatures.
+		 */
+		result = del_sigs(zone, db, version, &tuple->name,
+				  dns_rdatatype_nsec3, &sig_diff,
+				  zone_keys, nkeys, now);
+		if (result != ISC_R_SUCCESS) {
+			dns_zone_log(zone, ISC_LOG_ERROR,
+				     "zone_nsec3chain:del_sigs -> %s\n",
+				     dns_result_totext(result));
+			goto failure;
+		}
+		result = add_sigs(db, version, &tuple->name,
+				  dns_rdatatype_nsec3, &sig_diff, zone_keys,
+				  nkeys, zone->mctx, inception, expire,
+				  check_ksk);
+		if (result != ISC_R_SUCCESS) {
+			dns_zone_log(zone, ISC_LOG_ERROR,
+				     "zone_nsec3chain:add_sigs -> %s\n",
+				     dns_result_totext(result));
+			goto failure;
+		}
+
+		do {
+			dns_difftuple_t *next = ISC_LIST_NEXT(tuple, link);
+			while (next != NULL &&
+			       !dns_name_equal(&tuple->name, &next->name))
+				next = ISC_LIST_NEXT(next, link);
+			ISC_LIST_UNLINK(nsec3_diff.tuples, tuple, link);
+			dns_diff_appendminimal(&sig_diff, &tuple);
+			INSIST(tuple == NULL);
+			tuple = next;
+		} while (tuple != NULL);
+	}
+
+	for (tuple = ISC_LIST_HEAD(param_diff.tuples);
+	     tuple != NULL;
+	     tuple = ISC_LIST_HEAD(param_diff.tuples)) {
+		/*
+		 * We have changed the NSEC3PARAM RRset above so we need to
+		 * update the signatures.
+		 */
+		result = del_sigs(zone, db, version, &tuple->name,
+				  dns_rdatatype_nsec3param, &sig_diff,
+				  zone_keys, nkeys, now);
+		if (result != ISC_R_SUCCESS) {
+			dns_zone_log(zone, ISC_LOG_ERROR,
+				     "zone_nsec3chain:del_sigs -> %s\n",
+				     dns_result_totext(result));
+			goto failure;
+		}
+		result = add_sigs(db, version, &tuple->name,
+				  dns_rdatatype_nsec3param, &sig_diff,
+				  zone_keys, nkeys, zone->mctx, inception,
+				  expire, check_ksk);
+		if (result != ISC_R_SUCCESS) {
+			dns_zone_log(zone, ISC_LOG_ERROR,
+				     "zone_nsec3chain:add_sigs -> %s\n",
+				     dns_result_totext(result));
+			goto failure;
+		}
+		ISC_LIST_UNLINK(param_diff.tuples, tuple, link);
+		dns_diff_appendminimal(&sig_diff, &tuple);
+		INSIST(tuple == NULL);
+	}
+
+	if (updatensec)
+		CHECK(updatesecure(db, version, &zone->origin, zone->minimum,
+				   NULL, &nsec_diff));
+
+	for (tuple = ISC_LIST_HEAD(nsec_diff.tuples);
+	     tuple != NULL;
+	     tuple = ISC_LIST_HEAD(nsec_diff.tuples)) {
+		result = del_sigs(zone, db, version, &tuple->name,
+				  dns_rdatatype_nsec, &sig_diff,
+				  zone_keys, nkeys, now);
+		if (result != ISC_R_SUCCESS) {
+			dns_zone_log(zone, ISC_LOG_ERROR,
+				     "zone_nsec3chain:del_sigs -> %s\n",
+				     dns_result_totext(result));
+			goto failure;
+		}
+		result = add_sigs(db, version, &tuple->name,
+				  dns_rdatatype_nsec, &sig_diff,
+				  zone_keys, nkeys, zone->mctx, inception,
+				  expire, check_ksk);
+		if (result != ISC_R_SUCCESS) {
+			dns_zone_log(zone, ISC_LOG_ERROR,
+				     "zone_nsec3chain:add_sigs -> %s\n",
+				     dns_result_totext(result));
+			goto failure;
+		}
+		ISC_LIST_UNLINK(nsec_diff.tuples, tuple, link);
+		dns_diff_appendminimal(&sig_diff, &tuple);
+		INSIST(tuple == NULL);
+	}
+
+	/*
+	 * If we made no effective changes to the zone then we can just
+	 * cleanup otherwise we need to increment the serial.
+	 */
+	if (ISC_LIST_HEAD(sig_diff.tuples) == NULL)
+		goto done;
+
+	result = del_sigs(zone, db, version, &zone->origin, dns_rdatatype_soa,
+			  &sig_diff, zone_keys, nkeys, now);
+	if (result != ISC_R_SUCCESS) {
+		dns_zone_log(zone, ISC_LOG_ERROR, "zone_nsec3chain:"
+			     "del_sigs -> %s\n", dns_result_totext(result));
+		goto failure;
+	}
+
+	result = increment_soa_serial(db, version, &sig_diff, zone->mctx);
+	if (result != ISC_R_SUCCESS) {
+		dns_zone_log(zone, ISC_LOG_ERROR, "zone_nsec3chain:"
+			     "increment_soa_serial -> %s\n",
+			     dns_result_totext(result));
+		goto failure;
+	}
+
+	result = add_sigs(db, version, &zone->origin, dns_rdatatype_soa,
+			  &sig_diff, zone_keys, nkeys, zone->mctx, inception,
+			  soaexpire, check_ksk);
+	if (result != ISC_R_SUCCESS) {
+		dns_zone_log(zone, ISC_LOG_ERROR, "zone_nsec3chain:"
+			     "add_sigs -> %s\n", dns_result_totext(result));
+		goto failure;
+	}
+
+	journalfile = dns_zone_getjournal(zone);
+	if (journalfile != NULL) {
+		dns_journal_t *journal = NULL;
+		result = dns_journal_open(zone->mctx, journalfile,
+					  ISC_TRUE, &journal);
+		if (result != ISC_R_SUCCESS) {
+			dns_zone_log(zone, ISC_LOG_ERROR, "zone_nsec3chain:"
+				     "dns_journal_open -> %s\n",
+				     dns_result_totext(result));
+			goto failure;
+		}
+
+		result = dns_journal_write_transaction(journal, &sig_diff);
+		dns_journal_destroy(&journal);
+		if (result != ISC_R_SUCCESS) {
+			dns_zone_log(zone, ISC_LOG_ERROR, "zone_nsec3chain:"
+				     "dns_journal_write_transaction -> %s\n",
+				     dns_result_totext(result));
+			goto failure;
+		}
+	}
+
+	LOCK_ZONE(zone);
+	zone_needdump(zone, DNS_DUMP_DELAY);
+	UNLOCK_ZONE(zone);
+
+ done:
+	/*
+	 * Pause all iterators so that dns_db_closeversion() can succeed.
+	 */
+	LOCK_ZONE(zone);
+	for (nsec3chain = ISC_LIST_HEAD(zone->nsec3chain);
+	     nsec3chain != NULL;
+	     nsec3chain = ISC_LIST_NEXT(nsec3chain, link))
+		dns_dbiterator_pause(nsec3chain->dbiterator);
+	UNLOCK_ZONE(zone);
+
+	/*
+	 * Everything has succeeded. Commit the changes.
+	 */
+	dns_db_closeversion(db, &version, ISC_TRUE);
+
+	/*
+	 * Everything succeeded so we can clean these up now.
+	 */
+	nsec3chain = ISC_LIST_HEAD(cleanup);
+	while (nsec3chain != NULL) {
+		ISC_LIST_UNLINK(cleanup, nsec3chain, link);
+		dns_db_detach(&nsec3chain->db);
+		dns_dbiterator_destroy(&nsec3chain->dbiterator);
+		isc_mem_put(zone->mctx, nsec3chain, sizeof *nsec3chain);
+		nsec3chain = ISC_LIST_HEAD(cleanup);
+	}
+
+	set_resigntime(zone);
+
+ failure:
+	/*
+	 * On error roll back the current nsec3chain.
+	 */
+	if (result != ISC_R_SUCCESS && nsec3chain != NULL) {
+		if (nsec3chain->done) {
+			dns_db_detach(&nsec3chain->db);
+			dns_dbiterator_destroy(&nsec3chain->dbiterator);
+			isc_mem_put(zone->mctx, nsec3chain, sizeof *nsec3chain);
+		} else {
+			result = dns_dbiterator_first(nsec3chain->dbiterator);
+			RUNTIME_CHECK(result == ISC_R_SUCCESS);
+			dns_dbiterator_pause(nsec3chain->dbiterator);
+			nsec3chain->delete_nsec = nsec3chain->save_delete_nsec;
+		}
+	}
+
+	/*
+	 * Rollback the cleanup list.
+	 */
+	nsec3chain = ISC_LIST_TAIL(cleanup);
+	while (nsec3chain != NULL) {
+		ISC_LIST_UNLINK(cleanup, nsec3chain, link);
+		if (nsec3chain->done) {
+			dns_db_detach(&nsec3chain->db);
+			dns_dbiterator_destroy(&nsec3chain->dbiterator);
+			isc_mem_put(zone->mctx, nsec3chain, sizeof *nsec3chain);
+		} else {
+			LOCK_ZONE(zone);
+			ISC_LIST_PREPEND(zone->nsec3chain, nsec3chain, link);
+			UNLOCK_ZONE(zone);
+			result = dns_dbiterator_first(nsec3chain->dbiterator);
+			RUNTIME_CHECK(result == ISC_R_SUCCESS);
+			dns_dbiterator_pause(nsec3chain->dbiterator);
+			nsec3chain->delete_nsec = nsec3chain->save_delete_nsec;
+		}
+		nsec3chain = ISC_LIST_TAIL(cleanup);
+	}
+
+	LOCK_ZONE(zone);
+	for (nsec3chain = ISC_LIST_HEAD(zone->nsec3chain);
+	     nsec3chain != NULL;
+	     nsec3chain = ISC_LIST_NEXT(nsec3chain, link))
+		dns_dbiterator_pause(nsec3chain->dbiterator);
+	UNLOCK_ZONE(zone);
+
+	dns_diff_clear(&param_diff);
+	dns_diff_clear(&nsec3_diff);
+	dns_diff_clear(&nsec_diff);
+	dns_diff_clear(&sig_diff);
+
+	if (iterator != NULL)
+		dns_rdatasetiter_destroy(&iterator);
+
+	for (i = 0; i < nkeys; i++)
+		dst_key_free(&zone_keys[i]);
+
+	if (version != NULL) {
+		dns_db_closeversion(db, &version, ISC_FALSE);
+		dns_db_detach(&db);
+	} else if (db != NULL)
+		dns_db_detach(&db);
+
+	LOCK_ZONE(zone);
+	if (ISC_LIST_HEAD(zone->nsec3chain) != NULL) {
+		isc_interval_t i;
+		if (zone->update_disabled || result != ISC_R_SUCCESS)
+			isc_interval_set(&i, 60, 0);		/* 1 minute */
+		else
+			isc_interval_set(&i, 0, 10000000);	/* 10 ms */
+		isc_time_nowplusinterval(&zone->nsec3chaintime, &i);
+	} else
+		isc_time_settoepoch(&zone->nsec3chaintime);
+	UNLOCK_ZONE(zone);
+}
+
+static isc_result_t
+del_sig(dns_db_t *db, dns_dbversion_t *version, dns_name_t *name,
+	dns_dbnode_t *node, unsigned int nkeys, dns_secalg_t algorithm,
+	isc_uint16_t keyid, dns_diff_t *diff)
+{
+	dns_rdata_rrsig_t rrsig;
+	dns_rdataset_t rdataset;
+	dns_rdatasetiter_t *iterator = NULL;
+	isc_result_t result;
+
+	result = dns_db_allrdatasets(db, node, version, 0, &iterator);
+	if (result != ISC_R_SUCCESS) {
+		if (result == ISC_R_NOTFOUND)
+			result = ISC_R_SUCCESS;
+		return (result);
+	}
+
+	dns_rdataset_init(&rdataset);
+	for (result = dns_rdatasetiter_first(iterator);
+	     result == ISC_R_SUCCESS;
+	     result = dns_rdatasetiter_next(iterator)) {
+		dns_rdatasetiter_current(iterator, &rdataset);
+		if (nkeys == 0 && rdataset.type == dns_rdatatype_nsec) {
+			for (result = dns_rdataset_first(&rdataset);
+			     result == ISC_R_SUCCESS;
+			     result = dns_rdataset_next(&rdataset)) {
+				dns_rdata_t rdata = DNS_RDATA_INIT;
+				dns_rdataset_current(&rdataset, &rdata);
+				CHECK(update_one_rr(db, version, diff,
+						    DNS_DIFFOP_DEL, name,
+						    rdataset.ttl, &rdata));
+			}
+			if (result != ISC_R_NOMORE)
+				goto failure;
+			dns_rdataset_disassociate(&rdataset);
+			continue;
+		}
+		if (rdataset.type != dns_rdatatype_rrsig) {
+			dns_rdataset_disassociate(&rdataset);
+			continue;
+		}
+		for (result = dns_rdataset_first(&rdataset);
+		     result == ISC_R_SUCCESS;
+		     result = dns_rdataset_next(&rdataset)) {
+			dns_rdata_t rdata = DNS_RDATA_INIT;
+			dns_rdataset_current(&rdataset, &rdata);
+			CHECK(dns_rdata_tostruct(&rdata, &rrsig, NULL));
+			if (rrsig.algorithm != algorithm ||
+			    rrsig.keyid != keyid)
+				continue;
+			CHECK(update_one_rr(db, version, diff,
+					    DNS_DIFFOP_DEL, name,
+					    rdataset.ttl, &rdata));
+		}
+		dns_rdataset_disassociate(&rdataset);
+		if (result != ISC_R_NOMORE)
+			break;
+	}
+	if (result == ISC_R_NOMORE)
+		result = ISC_R_SUCCESS;
+ failure:
+	if (dns_rdataset_isassociated(&rdataset))
+		dns_rdataset_disassociate(&rdataset);
+	dns_rdatasetiter_destroy(&iterator);
+	return (result);
+}
+
+/*
+ * Incrementally sign the zone using the keys requested.
+ * Builds the NSEC chain if required.
+ */
+static void
+zone_sign(dns_zone_t *zone) {
+	const char *journalfile;
+	dns_db_t *db = NULL;
+	dns_dbnode_t *node = NULL;
+	dns_dbversion_t *version = NULL;
+	dns_diff_t sig_diff;
+	dns_fixedname_t fixed;
+	dns_fixedname_t nextfixed;
+	dns_name_t *name, *nextname;
+	dns_rdataset_t rdataset;
+	dns_signing_t *signing, *nextsigning;
+	dns_signinglist_t cleanup;
+	dst_key_t *zone_keys[MAXZONEKEYS];
+	isc_int32_t signatures;
+	isc_boolean_t check_ksk, is_ksk;
+	isc_boolean_t delegation;
+	isc_boolean_t finishedakey = ISC_FALSE;
+	isc_boolean_t secureupdated = ISC_FALSE;
+	isc_boolean_t build_nsec3 = ISC_FALSE, build_nsec = ISC_FALSE;
+	isc_boolean_t first;
+	isc_result_t result;
+	isc_stdtime_t now, inception, soaexpire, expire, stop;
+	isc_uint32_t jitter;
+	unsigned int i;
+	unsigned int nkeys = 0;
+	isc_uint32_t nodes;
+
+	dns_rdataset_init(&rdataset);
+	dns_fixedname_init(&fixed);
+	name = dns_fixedname_name(&fixed);
+	dns_fixedname_init(&nextfixed);
+	nextname = dns_fixedname_name(&nextfixed);
+	dns_diff_init(zone->mctx, &sig_diff);
+	sig_diff.resign = zone->sigresigninginterval;
+	ISC_LIST_INIT(cleanup);
+
+	/*
+	 * Updates are disabled.  Pause for 5 minutes.
+	 */
+	if (zone->update_disabled) {
+		result = ISC_R_FAILURE;
+		goto failure;
+	}
+
+	ZONEDB_LOCK(&zone->dblock, isc_rwlocktype_read);
+	dns_db_attach(zone->db, &db);
+	ZONEDB_UNLOCK(&zone->dblock, isc_rwlocktype_read);
+
+	result = dns_db_newversion(db, &version);
+	if (result != ISC_R_SUCCESS) {
+		dns_zone_log(zone, ISC_LOG_ERROR,
+			     "zone_sign:dns_db_newversion -> %s\n",
+			     dns_result_totext(result));
+		goto failure;
+	}
+
+	result = find_zone_keys(zone, db, version, zone->mctx,
+				MAXZONEKEYS, zone_keys, &nkeys);
+	if (result != ISC_R_SUCCESS) {
+		dns_zone_log(zone, ISC_LOG_ERROR,
+			     "zone_sign:find_zone_keys -> %s\n",
+			     dns_result_totext(result));
+		goto failure;
+	}
+
+	isc_stdtime_get(&now);
+	inception = now - 3600;	/* Allow for clock skew. */
+	soaexpire = now + dns_zone_getsigvalidityinterval(zone);
+
+	/*
+	 * Spread out signatures over time if they happen to be
+	 * clumped.  We don't do this for each add_sigs() call as
+	 * we still want some clustering to occur.
+	 */
+	isc_random_get(&jitter);
+	expire = soaexpire - jitter % 3600;
+	stop = now + 5;
+
+	check_ksk = DNS_ZONE_OPTION(zone, DNS_ZONEOPT_UPDATECHECKKSK);
+	if (check_ksk)
+		check_ksk = ksk_sanity(db, version);
+
+	/*
+	 * We keep pulling nodes off each iterator in turn until
+	 * we have no more nodes to pull off or we reach the limits
+	 * for this quantum.
+	 */
+	nodes = zone->nodes;
+	signatures = zone->signatures;
+	signing = ISC_LIST_HEAD(zone->signing);
+	first = ISC_TRUE;
+	/*
+	 * See if we have a NSEC chain.
+	 */
+	result = dns_db_getoriginnode(db, &node);
+	RUNTIME_CHECK(result == ISC_R_SUCCESS);
+	result = dns_db_findrdataset(db, node, version, dns_rdatatype_nsec,
+				     dns_rdatatype_none, 0, &rdataset, NULL);
+	dns_db_detachnode(db, &node);
+	if (result == ISC_R_SUCCESS) {
+		build_nsec = ISC_TRUE;
+		dns_rdataset_disassociate(&rdataset);
+	} else if (result != ISC_R_NOTFOUND) {
+		goto failure;
+	} else {
+		/*
+		 * No NSEC chain present.
+		 * See if we need to build a NSEC3 chain?
+		 */
+		result = dns_nsec3_active(db, version, ISC_TRUE, &build_nsec3);
+		if (result == ISC_R_SUCCESS) {
+			if (build_nsec3)
+				build_nsec3 = ISC_FALSE;
+			else  {
+				result = dns_nsec3_active(db, version,
+							  ISC_FALSE,
+							  &build_nsec3);
+				if (build_nsec3)
+					secureupdated = ISC_TRUE;
+				else
+					build_nsec = ISC_TRUE;
+			}
+		}
+	}
+
+	while (signing != NULL && nodes-- > 0 && signatures > 0) {
+		nextsigning = ISC_LIST_NEXT(signing, link);
+
+		ZONEDB_LOCK(&zone->dblock, isc_rwlocktype_read);
+		if (signing->done || signing->db != zone->db) {
+			/*
+			 * The zone has been reloaded.  We will have
+			 * created new signings as part of the reload
+			 * process so we can destroy this one.
+			 */
+			ISC_LIST_UNLINK(zone->signing, signing, link);
+			ISC_LIST_APPEND(cleanup, signing, link);
+			ZONEDB_UNLOCK(&zone->dblock, isc_rwlocktype_read);
+			goto next_signing;
+		}
+		ZONEDB_UNLOCK(&zone->dblock, isc_rwlocktype_read);
+
+		if (signing->db != db)
+			goto next_signing;
+
+		is_ksk = ISC_FALSE;
+		delegation = ISC_FALSE;
+
+		dns_dbiterator_current(signing->dbiterator, &node, name);
+
+		if (signing->delete) {
+			dns_dbiterator_pause(signing->dbiterator);
+			CHECK(del_sig(db, version, name, node, nkeys,
+				      signing->algorithm, signing->keyid,
+				      &sig_diff));
+			goto next_node;
+		}
+		/*
+		 * On the first pass we need to check if the current node
+		 * has not been obscured.
+		 */
+		if (first) {
+			dns_fixedname_t ffound;
+			dns_name_t *found;
+			dns_fixedname_init(&ffound);
+			found = dns_fixedname_name(&ffound);
+			result = dns_db_find(db, name, version,
+					     dns_rdatatype_soa,
+					     DNS_DBFIND_NOWILD, 0, NULL, found,
+					     NULL, NULL);
+			if ((result == DNS_R_DELEGATION ||
+			    result == DNS_R_DNAME) &&
+			    !dns_name_equal(name, found)) {
+				/*
+				 * Remember the obscuring name so that
+				 * we skip all obscured names.
+				 */
+				dns_name_copy(found, name, NULL);
+				delegation = ISC_TRUE;
+				goto next_node;
+			}
+		}
+
+		/*
+		 * Process one node.
+		 */
+		dns_dbiterator_pause(signing->dbiterator);
+		for (i = 0; i < nkeys; i++) {
+			/*
+			 * Find the key we want to sign with.
+			 */
+			if (dst_key_alg(zone_keys[i]) != signing->algorithm ||
+			    dst_key_id(zone_keys[i]) != signing->keyid ||
+			    !dst_key_isprivate(zone_keys[i]))
+				continue;
+			/*
+			 * Do we do KSK processing?
+			 */
+			if (check_ksk &&
+			    (dst_key_flags(zone_keys[i]) & DNS_KEYFLAG_KSK) != 0)
+				is_ksk = ISC_TRUE;
+			CHECK(sign_a_node(db, name, node, version, build_nsec3,
+					  build_nsec, zone_keys[i], inception,
+					  expire, zone->minimum, is_ksk,
+					  &delegation, &sig_diff, &signatures,
+					  zone->mctx));
+			break;
+		}
+		/*
+		 * Go onto next node.
+		 */
+ next_node:
+		first = ISC_FALSE;
+		dns_db_detachnode(db, &node);
+		do {
+			result = dns_dbiterator_next(signing->dbiterator);
+			if (result == ISC_R_NOMORE) {
+				ISC_LIST_UNLINK(zone->signing, signing, link);
+				ISC_LIST_APPEND(cleanup, signing, link);
+				dns_dbiterator_pause(signing->dbiterator);
+				finishedakey = ISC_TRUE;
+				if (!is_ksk && !secureupdated && nkeys != 0 &&
+				    build_nsec) {
+					/*
+					 * We have finished regenerating the
+					 * zone with a zone signing key.
+					 * The NSEC chain is now complete and
+					 * there is a full set of signatures
+					 * for the zone.  We can now clear the
+					 * OPT bit from the NSEC record.
+					 */
+					result = updatesecure(db, version,
+							      &zone->origin,
+							      zone->minimum,
+							      &secureupdated,
+							      &sig_diff);
+					if (result != ISC_R_SUCCESS) {
+						dns_zone_log(zone,
+							     ISC_LOG_ERROR,
+						    "updatesecure -> %s\n",
+						    dns_result_totext(result));
+						goto failure;
+					}
+				}
+				result = updatesignwithkey(signing, version,
+							   &zone->origin,
+							   zone->privatetype,
+							   &sig_diff);
+				if (result != ISC_R_SUCCESS) {
+					dns_zone_log(zone, ISC_LOG_ERROR,
+						     "updatesignwithkey -> %s\n",
+						     dns_result_totext(result));
+					goto failure;
+				}
+				goto next_signing;
+			} else if (result != ISC_R_SUCCESS) {
+				dns_zone_log(zone, ISC_LOG_ERROR,
+					"zone_sign:dns_dbiterator_next -> %s\n",
+					     dns_result_totext(result));
+				goto failure;
+			} else if (delegation) {
+				dns_dbiterator_current(signing->dbiterator,
+						       &node, nextname);
+				dns_db_detachnode(db, &node);
+				if (!dns_name_issubdomain(nextname, name))
+					break;
+			} else
+				break;
+		} while (1);
+		continue;
+
+ next_signing:
+		dns_dbiterator_pause(signing->dbiterator);
+		signing = nextsigning;
+		first = ISC_TRUE;
+	}
+
+	if (secureupdated) {
+		/*
+		 * We have changed the NSEC RRset above so we need to update
+		 * the signatures.
+		 */
+		result = del_sigs(zone, db, version, &zone->origin,
+				  dns_rdatatype_nsec, &sig_diff, zone_keys,
+				  nkeys, now);
+		if (result != ISC_R_SUCCESS) {
+			dns_zone_log(zone, ISC_LOG_ERROR,
+				     "zone_sign:del_sigs -> %s\n",
+				     dns_result_totext(result));
+			goto failure;
+		}
+		result = add_sigs(db, version, &zone->origin,
+				  dns_rdatatype_nsec, &sig_diff, zone_keys,
+				  nkeys, zone->mctx, inception, soaexpire,
+				  check_ksk);
+		if (result != ISC_R_SUCCESS) {
+			dns_zone_log(zone, ISC_LOG_ERROR,
+				     "zone_sign:add_sigs -> %s\n",
+				     dns_result_totext(result));
+			goto failure;
+		}
+	}
+	if (finishedakey) {
+		/*
+		 * We have changed the RRset above so we need to update
+		 * the signatures.
+		 */
+		result = del_sigs(zone, db, version, &zone->origin,
+				  zone->privatetype, &sig_diff,
+				  zone_keys, nkeys, now);
+		if (result != ISC_R_SUCCESS) {
+			dns_zone_log(zone, ISC_LOG_ERROR,
+				     "zone_sign:del_sigs -> %s\n",
+				     dns_result_totext(result));
+			goto failure;
+		}
+		result = add_sigs(db, version, &zone->origin,
+				  zone->privatetype, &sig_diff,
+				  zone_keys, nkeys, zone->mctx, inception,
+				  soaexpire, check_ksk);
+		if (result != ISC_R_SUCCESS) {
+			dns_zone_log(zone, ISC_LOG_ERROR,
+				     "zone_sign:add_sigs -> %s\n",
+				     dns_result_totext(result));
+			goto failure;
+		}
+	}
+	result = del_sigs(zone, db, version, &zone->origin, dns_rdatatype_soa,
+			  &sig_diff, zone_keys, nkeys, now);
+	if (result != ISC_R_SUCCESS) {
+		dns_zone_log(zone, ISC_LOG_ERROR,
+			     "zone_sign:del_sigs -> %s\n",
+			     dns_result_totext(result));
+		goto failure;
+	}
+
+	result = increment_soa_serial(db, version, &sig_diff, zone->mctx);
+	if (result != ISC_R_SUCCESS) {
+		dns_zone_log(zone, ISC_LOG_ERROR,
+			     "zone_sign:increment_soa_serial -> %s\n",
+			     dns_result_totext(result));
+		goto failure;
+	}
+
+	/*
+	 * Generate maximum life time signatures so that the above loop
+	 * termination is sensible.
+	 */
+	result = add_sigs(db, version, &zone->origin, dns_rdatatype_soa,
+			  &sig_diff, zone_keys, nkeys, zone->mctx, inception,
+			  soaexpire, check_ksk);
+	if (result != ISC_R_SUCCESS) {
+		dns_zone_log(zone, ISC_LOG_ERROR,
+			     "zone_sign:add_sigs -> %s\n",
+			     dns_result_totext(result));
+		goto failure;
+	}
+
+	journalfile = dns_zone_getjournal(zone);
+	if (journalfile != NULL) {
+		dns_journal_t *journal = NULL;
+		result = dns_journal_open(zone->mctx, journalfile,
+					  ISC_TRUE, &journal);
+		if (result != ISC_R_SUCCESS) {
+			dns_zone_log(zone, ISC_LOG_ERROR,
+				     "zone_sign:dns_journal_open -> %s\n",
+				     dns_result_totext(result));
+			goto failure;
+		}
+
+		result = dns_journal_write_transaction(journal, &sig_diff);
+		dns_journal_destroy(&journal);
+		if (result != ISC_R_SUCCESS) {
+			dns_zone_log(zone, ISC_LOG_ERROR,
+			 "zone_sign:dns_journal_write_transaction -> %s\n",
+				     dns_result_totext(result));
+			goto failure;
+		}
+	}
+
+
+	/*
+	 * Pause all iterators so that dns_db_closeversion() can succeed.
+	 */
+	for (signing = ISC_LIST_HEAD(zone->signing);
+	     signing != NULL;
+	     signing = ISC_LIST_NEXT(signing, link))
+		dns_dbiterator_pause(signing->dbiterator);
+
+	for (signing = ISC_LIST_HEAD(cleanup);
+	     signing != NULL;
+	     signing = ISC_LIST_NEXT(signing, link))
+		dns_dbiterator_pause(signing->dbiterator);
+
+	/*
+	 * Everything has succeeded. Commit the changes.
+	 */
+	dns_db_closeversion(db, &version, ISC_TRUE);
+
+	/*
+	 * Everything succeeded so we can clean these up now.
+	 */
+	signing = ISC_LIST_HEAD(cleanup);
+	while (signing != NULL) {
+		ISC_LIST_UNLINK(cleanup, signing, link);
+		dns_db_detach(&signing->db);
+		dns_dbiterator_destroy(&signing->dbiterator);
+		isc_mem_put(zone->mctx, signing, sizeof *signing);
+		signing = ISC_LIST_HEAD(cleanup);
+	}
+
+	set_resigntime(zone);
+
+	LOCK_ZONE(zone);
+	zone_needdump(zone, DNS_DUMP_DELAY);
+	UNLOCK_ZONE(zone);
+
+ failure:
+	/*
+	 * Rollback the cleanup list.
+	 */
+	signing = ISC_LIST_HEAD(cleanup);
+	while (signing != NULL) {
+		ISC_LIST_UNLINK(cleanup, signing, link);
+		ISC_LIST_APPEND(zone->signing, signing, link);
+		dns_dbiterator_first(signing->dbiterator);
+		dns_dbiterator_pause(signing->dbiterator);
+		signing = ISC_LIST_HEAD(cleanup);
+	}
+
+	for (signing = ISC_LIST_HEAD(zone->signing);
+	     signing != NULL;
+	     signing = ISC_LIST_NEXT(signing, link))
+		dns_dbiterator_pause(signing->dbiterator);
+
+	dns_diff_clear(&sig_diff);
+
+	for (i = 0; i < nkeys; i++)
+		dst_key_free(&zone_keys[i]);
+
+	if (version != NULL) {
+		dns_db_closeversion(db, &version, ISC_FALSE);
+		dns_db_detach(&db);
+	} else if (db != NULL)
+		dns_db_detach(&db);
+
+	if (ISC_LIST_HEAD(zone->signing) != NULL) {
+		isc_interval_t i;
+		if (zone->update_disabled || result != ISC_R_SUCCESS)
+			isc_interval_set(&i, 60, 0);		/* 1 minute */
+		else
+			isc_interval_set(&i, 0, 10000000);	/* 10 ms */
+		isc_time_nowplusinterval(&zone->signingtime, &i);
+	} else
+		isc_time_settoepoch(&zone->signingtime);
+}
+
 static void
 zone_maintenance(dns_zone_t *zone) {
 	const char me[] = "zone_maintenance";
@@ -3016,15 +5981,34 @@ zone_maintenance(dns_zone_t *zone) {
 		break;
 	}
 
-	/*
-	 * Do we need to send out notify messages?
-	 */
 	switch (zone->type) {
 	case dns_zone_master:
 	case dns_zone_slave:
+		/*
+		 * Do we need to send out notify messages?
+		 */
 		if (DNS_ZONE_FLAG(zone, DNS_ZONEFLG_NEEDNOTIFY) &&
 		    isc_time_compare(&now, &zone->notifytime) >= 0)
 			zone_notify(zone, &now);
+		/*
+		 * Do we need to sign/resign some RRsets?
+		 */
+		if (!isc_time_isepoch(&zone->signingtime) &&
+		    isc_time_compare(&now, &zone->signingtime) >= 0)
+			zone_sign(zone);
+		else if (!isc_time_isepoch(&zone->resigntime) &&
+		    isc_time_compare(&now, &zone->resigntime) >= 0)
+			zone_resigninc(zone);
+		else if (!isc_time_isepoch(&zone->nsec3chaintime) &&
+			isc_time_compare(&now, &zone->nsec3chaintime) >= 0)
+			zone_nsec3chain(zone);
+		/*
+		 * Do we need to issue a key expiry warning.
+		 */
+		if (!isc_time_isepoch(&zone->keywarntime) &&
+		    isc_time_compare(&now, &zone->keywarntime) >= 0)
+			set_key_expiry_warning(zone, zone->key_expiry,
+					       isc_time_seconds(&now));
 		break;
 	default:
 		break;
@@ -3036,6 +6020,7 @@ void
 dns_zone_markdirty(dns_zone_t *zone) {
 
 	LOCK_ZONE(zone);
+	set_resigntime(zone);	/* XXXMPA make separate call back */
 	zone_needdump(zone, DNS_DUMP_DELAY);
 	UNLOCK_ZONE(zone);
 }
@@ -3776,6 +6761,16 @@ notify_send_toaddr(isc_task_t *task, isc_event_t *event) {
 					timeout * 3, timeout,
 					notify->zone->task, notify_done,
 					notify, &notify->request);
+	if (result == ISC_R_SUCCESS) {
+		if (isc_sockaddr_pf(&notify->dst) == AF_INET) {
+			inc_stats(notify->zone,
+				  dns_zonestatscounter_notifyoutv4);
+		} else {
+			inc_stats(notify->zone,
+				  dns_zonestatscounter_notifyoutv6);
+		}
+	}
+
  cleanup_key:
 	if (key != NULL)
 		dns_tsigkey_detach(&key);
@@ -3975,9 +6970,11 @@ zone_notify(dns_zone_t *zone, isc_time_t *now) {
 		RUNTIME_CHECK(result == ISC_R_SUCCESS);
 		dns_rdata_reset(&rdata);
 		/*
-		 * don't notify the master server.
+		 * Don't notify the master server unless explicitly
+		 * configured to do so.
 		 */
-		if (dns_name_compare(&master, &ns.name) == 0) {
+		if (!DNS_ZONE_OPTION(zone, DNS_ZONEOPT_NOTIFYTOSOA) &&
+		    dns_name_compare(&master, &ns.name) == 0) {
 			result = dns_rdataset_next(&nsrdset);
 			continue;
 		}
@@ -4163,6 +7160,8 @@ stub_callback(isc_task_t *task, isc_event_t *event) {
 				     master, source);
 			goto same_master;
 		}
+		dns_zonemgr_unreachableadd(zone->zmgr, &zone->masteraddr,
+					   &zone->sourceaddr, &now);
 		dns_zone_log(zone, ISC_LOG_INFO,
 			     "could not refresh stub from master %s"
 			     " (source %s): %s", master, source,
@@ -4424,12 +7423,23 @@ refresh_callback(isc_task_t *task, isc_event_t *event) {
 				     "master %s exceeded (source %s)",
 				     master, source);
 			/* Try with slave with TCP. */
-			if (zone->type == dns_zone_slave) {
-				LOCK_ZONE(zone);
-				DNS_ZONE_SETFLAG(zone,
-						 DNS_ZONEFLG_SOABEFOREAXFR);
-				UNLOCK_ZONE(zone);
-				goto tcp_transfer;
+			if (zone->type == dns_zone_slave &&
+			    DNS_ZONE_OPTION(zone, DNS_ZONEOPT_TRYTCPREFRESH)) {
+				if (!dns_zonemgr_unreachable(zone->zmgr,
+							     &zone->masteraddr,
+							     &zone->sourceaddr,
+							     &now)) {
+					LOCK_ZONE(zone);
+					DNS_ZONE_SETFLAG(zone,
+						     DNS_ZONEFLG_SOABEFOREAXFR);
+					UNLOCK_ZONE(zone);
+					goto tcp_transfer;
+				}
+				dns_zone_log(zone, ISC_LOG_DEBUG(1),
+					     "refresh: skipped tcp fallback"
+					     "as master %s (source %s) is "
+					     "unreachable (cached)",
+					      master, source);
 			}
 		} else
 			dns_zone_log(zone, ISC_LOG_INFO,
@@ -4479,7 +7489,7 @@ refresh_callback(isc_task_t *task, isc_event_t *event) {
 			     "master %s (source %s)", (int)rb.used, rcode,
 			     master, source);
 		/*
-		 * Perhaps AXFR/IXFR is allowed even if SOA queries arn't.
+		 * Perhaps AXFR/IXFR is allowed even if SOA queries aren't.
 		 */
 		if (msg->rcode == dns_rcode_refused &&
 		    zone->type == dns_zone_slave)
@@ -4605,6 +7615,16 @@ refresh_callback(isc_task_t *task, isc_event_t *event) {
 	if (!DNS_ZONE_FLAG(zone, DNS_ZONEFLG_LOADED) ||
 	    DNS_ZONE_FLAG(zone, DNS_ZONEFLG_FORCEXFER) ||
 	    isc_serial_gt(serial, zone->serial)) {
+		if (dns_zonemgr_unreachable(zone->zmgr, &zone->masteraddr,
+					    &zone->sourceaddr, &now)) {
+			dns_zone_log(zone, ISC_LOG_INFO,
+				     "refresh: skipping %s as master %s "
+				     "(source %s) is unreachable (cached)",
+				     zone->type == dns_zone_slave ?
+				     "zone transfer" : "NS query",
+				     master, source);
+			goto next_master;
+		}
  tcp_transfer:
 		isc_event_free(&event);
 		LOCK_ZONE(zone);
@@ -4820,7 +7840,7 @@ create_query(dns_zone_t *zone, dns_rdatatype_t rdtype,
 }
 
 static isc_result_t
-add_opt(dns_message_t *message, isc_uint16_t udpsize) {
+add_opt(dns_message_t *message, isc_uint16_t udpsize, isc_boolean_t reqnsid) {
 	dns_rdataset_t *rdataset = NULL;
 	dns_rdatalist_t *rdatalist = NULL;
 	dns_rdata_t *rdata = NULL;
@@ -4850,11 +7870,21 @@ add_opt(dns_message_t *message, isc_uint16_t udpsize) {
 	 */
 	rdatalist->ttl = 0;
 
-	/*
-	 * No EDNS options.
-	 */
-	rdata->data = NULL;
-	rdata->length = 0;
+	/* Set EDNS options if applicable */
+	if (reqnsid) {
+		unsigned char data[4];
+		isc_buffer_t buf;
+
+		isc_buffer_init(&buf, data, sizeof(data));
+		isc_buffer_putuint16(&buf, DNS_OPT_NSID);
+		isc_buffer_putuint16(&buf, 0);
+		rdata->data = data;
+		rdata->length = sizeof(data);
+	} else {
+		rdata->data = NULL;
+		rdata->length = 0;
+	}
+
 	rdata->rdclass = rdatalist->rdclass;
 	rdata->type = rdatalist->type;
 	rdata->flags = 0;
@@ -4889,7 +7919,7 @@ soa_query(isc_task_t *task, isc_event_t *event) {
 	isc_uint32_t options;
 	isc_boolean_t cancel = ISC_TRUE;
 	int timeout;
-	isc_boolean_t have_xfrsource;
+	isc_boolean_t have_xfrsource, reqnsid;
 	isc_uint16_t udpsize = SEND_BUFFER_SIZE;
 
 	REQUIRE(DNS_ZONE_VALID(zone));
@@ -4941,6 +7971,7 @@ soa_query(isc_task_t *task, isc_event_t *event) {
 		(void)dns_view_getpeertsig(zone->view, &masterip, &key);
 
 	have_xfrsource = ISC_FALSE;
+	reqnsid = zone->view->requestnsid;
 	if (zone->view->peers != NULL) {
 		dns_peer_t *peer = NULL;
 		isc_boolean_t edns;
@@ -4958,6 +7989,7 @@ soa_query(isc_task_t *task, isc_event_t *event) {
 				udpsize =
 				  dns_resolver_getudpsize(zone->view->resolver);
 			(void)dns_peer_getudpsize(peer, &udpsize);
+			(void)dns_peer_getrequestnsid(peer, &reqnsid);
 		}
 	}
 
@@ -4989,7 +8021,7 @@ soa_query(isc_task_t *task, isc_event_t *event) {
 		  DNS_REQUESTOPT_TCP : 0;
 
 	if (!DNS_ZONE_FLAG(zone, DNS_ZONEFLG_NOEDNS)) {
-		result = add_opt(message, udpsize);
+		result = add_opt(message, udpsize, reqnsid);
 		if (result != ISC_R_SUCCESS)
 			zone_debuglog(zone, me, 1,
 				      "unable to add opt record: %s",
@@ -5011,6 +8043,11 @@ soa_query(isc_task_t *task, isc_event_t *event) {
 			      "dns_request_createvia2() failed: %s",
 			      dns_result_totext(result));
 		goto cleanup;
+	} else {
+		if (isc_sockaddr_pf(&zone->masteraddr) == PF_INET)
+			inc_stats(zone, dns_zonestatscounter_soaoutv4);
+		else
+			inc_stats(zone, dns_zonestatscounter_soaoutv6);
 	}
 	cancel = ISC_FALSE;
 
@@ -5053,7 +8090,7 @@ ns_query(dns_zone_t *zone, dns_rdataset_t *soardataset, dns_stub_t *stub) {
 	dns_tsigkey_t *key = NULL;
 	dns_dbnode_t *node = NULL;
 	int timeout;
-	isc_boolean_t have_xfrsource = ISC_FALSE;
+	isc_boolean_t have_xfrsource = ISC_FALSE, reqnsid;
 	isc_uint16_t udpsize = SEND_BUFFER_SIZE;
 
 	REQUIRE(DNS_ZONE_VALID(zone));
@@ -5165,6 +8202,7 @@ ns_query(dns_zone_t *zone, dns_rdataset_t *soardataset, dns_stub_t *stub) {
 	if (key == NULL)
 		(void)dns_view_getpeertsig(zone->view, &masterip, &key);
 
+	reqnsid = zone->view->requestnsid;
 	if (zone->view->peers != NULL) {
 		dns_peer_t *peer = NULL;
 		isc_boolean_t edns;
@@ -5182,11 +8220,12 @@ ns_query(dns_zone_t *zone, dns_rdataset_t *soardataset, dns_stub_t *stub) {
 				udpsize =
 				  dns_resolver_getudpsize(zone->view->resolver);
 			(void)dns_peer_getudpsize(peer, &udpsize);
+			(void)dns_peer_getrequestnsid(peer, &reqnsid);
 		}
 
 	}
 	if (!DNS_ZONE_FLAG(zone, DNS_ZONEFLG_NOEDNS)) {
-		result = add_opt(message, udpsize);
+		result = add_opt(message, udpsize, reqnsid);
 		if (result != ISC_R_SUCCESS)
 			zone_debuglog(zone, me, 1,
 				      "unable to add opt record: %s",
@@ -5382,6 +8421,26 @@ zone_settimer(dns_zone_t *zone, isc_time_t *now) {
 			    isc_time_compare(&zone->dumptime, &next) < 0)
 				next = zone->dumptime;
 		}
+		if (!isc_time_isepoch(&zone->resigntime)) {
+			if (isc_time_isepoch(&next) ||
+			    isc_time_compare(&zone->resigntime, &next) < 0)
+				next = zone->resigntime;
+		}
+		if (!isc_time_isepoch(&zone->keywarntime)) {
+			if (isc_time_isepoch(&next) ||
+			    isc_time_compare(&zone->keywarntime, &next) < 0)
+				next = zone->keywarntime;
+		}
+		if (!isc_time_isepoch(&zone->signingtime)) {
+			if (isc_time_isepoch(&next) ||
+			    isc_time_compare(&zone->signingtime, &next) < 0)
+				next = zone->signingtime;
+		}
+		if (!isc_time_isepoch(&zone->nsec3chaintime)) {
+			if (isc_time_isepoch(&next) ||
+			    isc_time_compare(&zone->nsec3chaintime, &next) < 0)
+				next = zone->nsec3chaintime;
+		}
 		break;
 
 	case dns_zone_slave:
@@ -5651,6 +8710,10 @@ dns_zone_notifyreceive(dns_zone_t *zone, isc_sockaddr_t *from,
 	 *  We only handle NOTIFY (SOA) at the present.
 	 */
 	LOCK_ZONE(zone);
+	if (isc_sockaddr_pf(from) == PF_INET)
+		inc_stats(zone, dns_zonestatscounter_notifyinv4);
+	else
+		inc_stats(zone, dns_zonestatscounter_notifyinv6);
 	if (msg->counts[DNS_SECTION_QUESTION] == 0 ||
 	    dns_message_findname(msg, DNS_SECTION_QUESTION, &zone->origin,
 				 dns_rdatatype_soa, dns_rdatatype_none,
@@ -5705,6 +8768,7 @@ dns_zone_notifyreceive(dns_zone_t *zone, isc_sockaddr_t *from,
 		UNLOCK_ZONE(zone);
 		dns_zone_log(zone, ISC_LOG_INFO,
 			     "refused notify from non-master: %s", fromtext);
+		inc_stats(zone, dns_zonestatscounter_notifyrej);
 		return (DNS_R_REFUSED);
 	}
 
@@ -5788,6 +8852,18 @@ dns_zone_setqueryacl(dns_zone_t *zone, dns_acl_t *acl) {
 }
 
 void
+dns_zone_setqueryonacl(dns_zone_t *zone, dns_acl_t *acl) {
+
+	REQUIRE(DNS_ZONE_VALID(zone));
+
+	LOCK_ZONE(zone);
+	if (zone->queryon_acl != NULL)
+		dns_acl_detach(&zone->queryon_acl);
+	dns_acl_attach(acl, &zone->queryon_acl);
+	UNLOCK_ZONE(zone);
+}
+
+void
 dns_zone_setupdateacl(dns_zone_t *zone, dns_acl_t *acl) {
 
 	REQUIRE(DNS_ZONE_VALID(zone));
@@ -5840,6 +8916,14 @@ dns_zone_getqueryacl(dns_zone_t *zone) {
 }
 
 dns_acl_t *
+dns_zone_getqueryonacl(dns_zone_t *zone) {
+
+	REQUIRE(DNS_ZONE_VALID(zone));
+
+	return (zone->queryon_acl);
+}
+
+dns_acl_t *
 dns_zone_getupdateacl(dns_zone_t *zone) {
 
 	REQUIRE(DNS_ZONE_VALID(zone));
@@ -5908,6 +8992,17 @@ dns_zone_clearqueryacl(dns_zone_t *zone) {
 }
 
 void
+dns_zone_clearqueryonacl(dns_zone_t *zone) {
+
+	REQUIRE(DNS_ZONE_VALID(zone));
+
+	LOCK_ZONE(zone);
+	if (zone->queryon_acl != NULL)
+		dns_acl_detach(&zone->queryon_acl);
+	UNLOCK_ZONE(zone);
+}
+
+void
 dns_zone_clearxfracl(dns_zone_t *zone) {
 
 	REQUIRE(DNS_ZONE_VALID(zone));
@@ -5977,7 +9072,7 @@ dns_zone_getjournalsize(dns_zone_t *zone) {
 }
 
 static void
-zone_tostr(dns_zone_t *zone, char *buf, size_t length) {
+zone_namerd_tostr(dns_zone_t *zone, char *buf, size_t length) {
 	isc_result_t result = ISC_R_FAILURE;
 	isc_buffer_t buffer;
 
@@ -6008,29 +9103,88 @@ zone_tostr(dns_zone_t *zone, char *buf, size_t length) {
 	buf[isc_buffer_usedlength(&buffer)] = '\0';
 }
 
+static void
+zone_name_tostr(dns_zone_t *zone, char *buf, size_t length) {
+	isc_result_t result = ISC_R_FAILURE;
+	isc_buffer_t buffer;
+
+	REQUIRE(buf != NULL);
+	REQUIRE(length > 1U);
+
+	/*
+	 * Leave space for terminating '\0'.
+	 */
+	isc_buffer_init(&buffer, buf, length - 1);
+	if (dns_name_dynamic(&zone->origin))
+		result = dns_name_totext(&zone->origin, ISC_TRUE, &buffer);
+	if (result != ISC_R_SUCCESS &&
+	    isc_buffer_availablelength(&buffer) >= (sizeof("<UNKNOWN>") - 1))
+		isc_buffer_putstr(&buffer, "<UNKNOWN>");
+
+	buf[isc_buffer_usedlength(&buffer)] = '\0';
+}
+
+static void
+zone_rdclass_tostr(dns_zone_t *zone, char *buf, size_t length) {
+	isc_buffer_t buffer;
+
+	REQUIRE(buf != NULL);
+	REQUIRE(length > 1U);
+
+	/*
+	 * Leave space for terminating '\0'.
+	 */
+	isc_buffer_init(&buffer, buf, length - 1);
+	(void)dns_rdataclass_totext(zone->rdclass, &buffer);
+
+	buf[isc_buffer_usedlength(&buffer)] = '\0';
+}
+
+static void
+zone_viewname_tostr(dns_zone_t *zone, char *buf, size_t length) {
+	isc_buffer_t buffer;
+
+	REQUIRE(buf != NULL);
+	REQUIRE(length > 1U);
+
+
+	/*
+	 * Leave space for terminating '\0'.
+	 */
+	isc_buffer_init(&buffer, buf, length - 1);
+
+	if (zone->view == NULL) {
+		isc_buffer_putstr(&buffer, "_none");
+	} else if (strlen(zone->view->name)
+		   < isc_buffer_availablelength(&buffer)) {
+		isc_buffer_putstr(&buffer, zone->view->name);
+	} else {
+		isc_buffer_putstr(&buffer, "_toolong");
+	}
+
+	buf[isc_buffer_usedlength(&buffer)] = '\0';
+}
+
 void
 dns_zone_name(dns_zone_t *zone, char *buf, size_t length) {
 	REQUIRE(DNS_ZONE_VALID(zone));
 	REQUIRE(buf != NULL);
-	zone_tostr(zone, buf, length);
+	zone_namerd_tostr(zone, buf, length);
 }
 
 static void
 notify_log(dns_zone_t *zone, int level, const char *fmt, ...) {
 	va_list ap;
 	char message[4096];
-	char namebuf[1024+32];
 
 	if (isc_log_wouldlog(dns_lctx, level) == ISC_FALSE)
 		return;
 
-	zone_tostr(zone, namebuf, sizeof(namebuf));
-
 	va_start(ap, fmt);
 	vsnprintf(message, sizeof(message), fmt, ap);
 	va_end(ap);
 	isc_log_write(dns_lctx, DNS_LOGCATEGORY_NOTIFY, DNS_LOGMODULE_ZONE,
-		      level, "zone %s: %s", namebuf, message);
+		      level, "zone %s: %s", zone->strnamerd, message);
 }
 
 void
@@ -6038,36 +9192,30 @@ dns_zone_logc(dns_zone_t *zone, isc_logcategory_t *category,
 	      int level, const char *fmt, ...) {
 	va_list ap;
 	char message[4096];
-	char namebuf[1024+32];
 
 	if (isc_log_wouldlog(dns_lctx, level) == ISC_FALSE)
 		return;
 
-	zone_tostr(zone, namebuf, sizeof(namebuf));
-
 	va_start(ap, fmt);
 	vsnprintf(message, sizeof(message), fmt, ap);
 	va_end(ap);
 	isc_log_write(dns_lctx, category, DNS_LOGMODULE_ZONE,
-		      level, "zone %s: %s", namebuf, message);
+		      level, "zone %s: %s", zone->strnamerd, message);
 }
 
 void
 dns_zone_log(dns_zone_t *zone, int level, const char *fmt, ...) {
 	va_list ap;
 	char message[4096];
-	char namebuf[1024+32];
 
 	if (isc_log_wouldlog(dns_lctx, level) == ISC_FALSE)
 		return;
 
-	zone_tostr(zone, namebuf, sizeof(namebuf));
-
 	va_start(ap, fmt);
 	vsnprintf(message, sizeof(message), fmt, ap);
 	va_end(ap);
 	isc_log_write(dns_lctx, DNS_LOGCATEGORY_GENERAL, DNS_LOGMODULE_ZONE,
-		      level, "zone %s: %s", namebuf, message);
+		      level, "zone %s: %s", zone->strnamerd, message);
 }
 
 static void
@@ -6076,19 +9224,16 @@ zone_debuglog(dns_zone_t *zone, const char *me, int debuglevel,
 {
 	va_list ap;
 	char message[4096];
-	char namebuf[1024+32];
 	int level = ISC_LOG_DEBUG(debuglevel);
 
 	if (isc_log_wouldlog(dns_lctx, level) == ISC_FALSE)
 		return;
 
-	zone_tostr(zone, namebuf, sizeof(namebuf));
-
 	va_start(ap, fmt);
 	vsnprintf(message, sizeof(message), fmt, ap);
 	va_end(ap);
 	isc_log_write(dns_lctx, DNS_LOGCATEGORY_GENERAL, DNS_LOGMODULE_ZONE,
-		      level, "%s: zone %s: %s", me, namebuf, message);
+		      level, "%s: zone %s: %s", me, zone->strnamerd, message);
 }
 
 static int
@@ -6313,12 +9458,16 @@ zone_replacedb(dns_zone_t *zone, dns_db_t *db, isc_boolean_t dump) {
 		return (result);
 	}
 
+	result = check_nsec3param(zone, db);
+	if (result != ISC_R_SUCCESS)
+		return (result);
+
 	ver = NULL;
 	dns_db_currentversion(db, &ver);
 
 	/*
 	 * The initial version of a slave zone is always dumped;
-	 * subsequent versions may be journalled instead if this
+	 * subsequent versions may be journaled instead if this
 	 * is enabled in the configuration.
 	 */
 	if (zone->db != NULL && zone->journal != NULL &&
@@ -6401,7 +9550,7 @@ zone_replacedb(dns_zone_t *zone, dns_db_t *db, isc_boolean_t dump) {
 			 * The in-memory database just changed, and
 			 * because 'dump' is set, it didn't change by
 			 * being loaded from disk.  Also, we have not
-			 * journalled diffs for this change.
+			 * journaled diffs for this change.
 			 * Therefore, the on-disk journal is missing
 			 * the deltas for this change.  Since it can
 			 * no longer be used to bring the zone
@@ -6411,7 +9560,17 @@ zone_replacedb(dns_zone_t *zone, dns_db_t *db, isc_boolean_t dump) {
 			isc_log_write(dns_lctx, DNS_LOGCATEGORY_GENERAL,
 				      DNS_LOGMODULE_ZONE, ISC_LOG_DEBUG(3),
 				      "removing journal file");
-			(void)remove(zone->journal);
+			if (remove(zone->journal) < 0 && errno != ENOENT) {
+				char strbuf[ISC_STRERRORSIZE];
+				isc__strerror(errno, strbuf, sizeof(strbuf));
+				isc_log_write(dns_lctx,
+					      DNS_LOGCATEGORY_GENERAL,
+					      DNS_LOGMODULE_ZONE,
+					      ISC_LOG_WARNING,
+					      "unable to remove journal "
+					      "'%s': '%s'",
+					      zone->journal, strbuf);
+			}
 		}
 	}
 
@@ -6568,7 +9727,7 @@ zone_xfrdone(dns_zone_t *zone, isc_result_t result) {
 		}
 
 		/*
-		 * This is not neccessary if we just performed a AXFR
+		 * This is not necessary if we just performed a AXFR
 		 * however it is necessary for an IXFR / UPTODATE and
 		 * won't hurt with an AXFR.
 		 */
@@ -6592,6 +9751,7 @@ zone_xfrdone(dns_zone_t *zone, isc_result_t result) {
 					     dns_result_totext(result));
 		}
 
+		inc_stats(zone, dns_zonestatscounter_xfrsuccess);
 		break;
 
 	case DNS_R_BADIXFR:
@@ -6626,6 +9786,7 @@ zone_xfrdone(dns_zone_t *zone, isc_result_t result) {
 			DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_REFRESH);
 			again = ISC_TRUE;
 		}
+		inc_stats(zone, dns_zonestatscounter_xfrfail);
 		break;
 	}
 	zone_settimer(zone, &now);
@@ -6760,6 +9921,20 @@ dns_zone_getsigvalidityinterval(dns_zone_t *zone) {
 	return (zone->sigvalidityinterval);
 }
 
+void
+dns_zone_setsigresigninginterval(dns_zone_t *zone, isc_uint32_t interval) {
+	REQUIRE(DNS_ZONE_VALID(zone));
+
+	zone->sigresigninginterval = interval;
+}
+
+isc_uint32_t
+dns_zone_getsigresigninginterval(dns_zone_t *zone) {
+	REQUIRE(DNS_ZONE_VALID(zone));
+
+	return (zone->sigresigninginterval);
+}
+
 static void
 queue_xfrin(dns_zone_t *zone) {
 	const char me[] = "queue_xfrin";
@@ -6798,12 +9973,14 @@ static void
 got_transfer_quota(isc_task_t *task, isc_event_t *event) {
 	isc_result_t result;
 	dns_peer_t *peer = NULL;
-	char mastertext[256];
+	char master[ISC_SOCKADDR_FORMATSIZE];
+	char source[ISC_SOCKADDR_FORMATSIZE];
 	dns_rdatatype_t xfrtype;
 	dns_zone_t *zone = event->ev_arg;
 	isc_netaddr_t masterip;
 	isc_sockaddr_t sourceaddr;
 	isc_sockaddr_t masteraddr;
+	isc_time_t now;
 
 	UNUSED(task);
 
@@ -6814,34 +9991,44 @@ got_transfer_quota(isc_task_t *task, isc_event_t *event) {
 		goto cleanup;
 	}
 
-	isc_sockaddr_format(&zone->masteraddr, mastertext, sizeof(mastertext));
+	TIME_NOW(&now);
+
+	isc_sockaddr_format(&zone->masteraddr, master, sizeof(master));
+	if (dns_zonemgr_unreachable(zone->zmgr, &zone->masteraddr,
+				    &zone->sourceaddr, &now)) {
+		isc_sockaddr_format(&zone->sourceaddr, source, sizeof(source));
+		dns_zone_log(zone, ISC_LOG_INFO,
+			     "got_transfer_quota: skipping zone transfer as "
+			     "master %s (source %s) is unreachable (cached)",
+			     master, source);
+		result = ISC_R_CANCELED;
+		goto cleanup;
+	}
 
 	isc_netaddr_fromsockaddr(&masterip, &zone->masteraddr);
-	(void)dns_peerlist_peerbyaddr(zone->view->peers,
-				      &masterip, &peer);
+	(void)dns_peerlist_peerbyaddr(zone->view->peers, &masterip, &peer);
 
 	/*
 	 * Decide whether we should request IXFR or AXFR.
 	 */
 	if (zone->db == NULL) {
 		dns_zone_log(zone, ISC_LOG_DEBUG(1),
-			     "no database exists yet, "
-			     "requesting AXFR of "
-			     "initial version from %s", mastertext);
+			     "no database exists yet, requesting AXFR of "
+			     "initial version from %s", master);
 		xfrtype = dns_rdatatype_axfr;
 	} 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);
+			     "set, requesting AXFR from %s", master);
 		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);
+			     "initial version from %s", master);
 		xfrtype = dns_rdatatype_axfr;
 	} else if (DNS_ZONE_FLAG(zone, DNS_ZONEFLAG_NOIXFR)) {
 		dns_zone_log(zone, ISC_LOG_DEBUG(1),
 			     "retrying with AXFR from %s due to "
-			     "previous IXFR failure", mastertext);
+			     "previous IXFR failure", master);
 		xfrtype = dns_rdatatype_axfr;
 		LOCK_ZONE(zone);
 		DNS_ZONE_CLRFLAG(zone, DNS_ZONEFLAG_NOIXFR);
@@ -6857,17 +10044,15 @@ got_transfer_quota(isc_task_t *task, isc_event_t *event) {
 		}
 		if (use_ixfr == ISC_FALSE) {
 			dns_zone_log(zone, ISC_LOG_DEBUG(1),
-				     "IXFR disabled, "
-				     "requesting AXFR from %s",
-				     mastertext);
+				     "IXFR disabled, requesting AXFR from %s",
+				     master);
 			if (DNS_ZONE_FLAG(zone, DNS_ZONEFLG_SOABEFOREAXFR))
 				xfrtype = dns_rdatatype_soa;
 			else
 				xfrtype = dns_rdatatype_axfr;
 		} else {
 			dns_zone_log(zone, ISC_LOG_DEBUG(1),
-				     "requesting IXFR from %s",
-				     mastertext);
+				     "requesting IXFR from %s", master);
 			xfrtype = dns_rdatatype_ixfr;
 		}
 	}
@@ -6892,8 +10077,7 @@ got_transfer_quota(isc_task_t *task, isc_event_t *event) {
 
 	if (result != ISC_R_SUCCESS && result != ISC_R_NOTFOUND) {
 		dns_zone_log(zone, ISC_LOG_ERROR,
-			     "could not get TSIG key "
-			     "for zone transfer: %s",
+			     "could not get TSIG key for zone transfer: %s",
 			     isc_result_totext(result));
 	}
 
@@ -6906,6 +10090,21 @@ got_transfer_quota(isc_task_t *task, isc_event_t *event) {
 				   zone->tsigkey, zone->mctx,
 				   zone->zmgr->timermgr, zone->zmgr->socketmgr,
 				   zone->task, zone_xfrdone, &zone->xfr);
+	if (result == ISC_R_SUCCESS) {
+		LOCK_ZONE(zone);
+		if (xfrtype == dns_rdatatype_axfr) {
+			if (isc_sockaddr_pf(&masteraddr) == PF_INET)
+				inc_stats(zone, dns_zonestatscounter_axfrreqv4);
+			else
+				inc_stats(zone, dns_zonestatscounter_axfrreqv6);
+		} else if (xfrtype == dns_rdatatype_ixfr) {
+			if (isc_sockaddr_pf(&masteraddr) == PF_INET)
+				inc_stats(zone, dns_zonestatscounter_ixfrreqv4);
+			else
+				inc_stats(zone, dns_zonestatscounter_ixfrreqv6);
+		}
+		UNLOCK_ZONE(zone);
+	}
  cleanup:
 	/*
 	 * Any failure in this function is handled like a failed
@@ -7175,6 +10374,7 @@ dns_zonemgr_create(isc_mem_t *mctx, isc_taskmgr_t *taskmgr,
 	ISC_LIST_INIT(zmgr->zones);
 	ISC_LIST_INIT(zmgr->waiting_for_xfrin);
 	ISC_LIST_INIT(zmgr->xfrin_in_progress);
+	memset(zmgr->unreachable, 0, sizeof(zmgr->unreachable));
 	result = isc_rwlock_init(&zmgr->rwlock, 0, 0);
 	if (result != ISC_R_SUCCESS)
 		goto free_mem;
@@ -7264,8 +10464,10 @@ dns_zonemgr_managezone(dns_zonemgr_t *zmgr, dns_zone_t *zone) {
 				  NULL, NULL,
 				  zone->task, zone_timer, zone,
 				  &zone->timer);
+
 	if (result != ISC_R_SUCCESS)
 		goto cleanup_task;
+
 	/*
 	 * The timer "holds" a iref.
 	 */
@@ -7735,7 +10937,7 @@ zone_saveunique(dns_zone_t *zone, const char *path, const char *templat) {
 }
 
 #if 0
-/* Hook for ondestroy notifcation from a database. */
+/* Hook for ondestroy notification from a database. */
 
 static void
 dns_zonemgr_dbdestroyed(isc_task_t *task, isc_event_t *event) {
@@ -7791,6 +10993,87 @@ dns_zonemgr_getserialqueryrate(dns_zonemgr_t *zmgr) {
 	return (zmgr->serialqueryrate);
 }
 
+static isc_boolean_t
+dns_zonemgr_unreachable(dns_zonemgr_t *zmgr, isc_sockaddr_t *remote,
+			isc_sockaddr_t *local, isc_time_t *now)
+{
+	unsigned int i;
+	isc_rwlocktype_t locktype;
+	isc_result_t result;
+	isc_uint32_t seconds = isc_time_seconds(now);
+
+	REQUIRE(DNS_ZONEMGR_VALID(zmgr));
+
+	locktype = isc_rwlocktype_read;
+	RWLOCK(&zmgr->rwlock, locktype);
+	for (i = 0; i < UNREACH_CHACHE_SIZE; i++) {
+		if (zmgr->unreachable[i].expire >= seconds &&
+		    isc_sockaddr_equal(&zmgr->unreachable[i].remote, remote) &&
+		    isc_sockaddr_equal(&zmgr->unreachable[i].local, local)) {
+			result = isc_rwlock_tryupgrade(&zmgr->rwlock);
+			if (result == ISC_R_SUCCESS) {
+				locktype = isc_rwlocktype_write;
+				zmgr->unreachable[i].last = seconds;
+			}
+			break;
+		}
+	}
+	RWUNLOCK(&zmgr->rwlock, locktype);
+	return (ISC_TF(i < UNREACH_CHACHE_SIZE));
+}
+
+void
+dns_zonemgr_unreachableadd(dns_zonemgr_t *zmgr, isc_sockaddr_t *remote,
+			   isc_sockaddr_t *local, isc_time_t *now)
+{
+	isc_uint32_t seconds = isc_time_seconds(now);
+	isc_uint32_t last = seconds;
+	unsigned int i, slot = UNREACH_CHACHE_SIZE, oldest = 0;
+
+	REQUIRE(DNS_ZONEMGR_VALID(zmgr));
+
+	RWLOCK(&zmgr->rwlock, isc_rwlocktype_write);
+	for (i = 0; i < UNREACH_CHACHE_SIZE; i++) {
+		/* Existing entry? */
+		if (isc_sockaddr_equal(&zmgr->unreachable[i].remote, remote) &&
+		    isc_sockaddr_equal(&zmgr->unreachable[i].local, local))
+			break;
+		/* Empty slot? */
+		if (zmgr->unreachable[i].expire < seconds)
+			slot = i;
+		/* Least recently used slot? */
+		if (zmgr->unreachable[i].last < last) {
+			last = zmgr->unreachable[i].last;
+			oldest = i;
+		}
+	}
+	if (i < UNREACH_CHACHE_SIZE) {
+		/*
+		 * Found a existing entry.  Update the expire timer and
+		 * last usage timestamps.
+		 */
+		zmgr->unreachable[i].expire = seconds + UNREACH_HOLD_TIME;
+		zmgr->unreachable[i].last = seconds;
+	} else if (slot != UNREACH_CHACHE_SIZE) {
+		/*
+		 * Found a empty slot. Add a new entry to the cache.
+		 */
+		zmgr->unreachable[slot].expire = seconds + UNREACH_HOLD_TIME;
+		zmgr->unreachable[slot].last = seconds;
+		zmgr->unreachable[slot].remote = *remote;
+		zmgr->unreachable[slot].local = *local;
+	} else {
+		/*
+		 * Replace the least recently used entry in the cache.
+		 */
+		zmgr->unreachable[oldest].expire = seconds + UNREACH_HOLD_TIME;
+		zmgr->unreachable[oldest].last = seconds;
+		zmgr->unreachable[oldest].remote = *remote;
+		zmgr->unreachable[oldest].local = *local;
+	}
+	RWUNLOCK(&zmgr->rwlock, isc_rwlocktype_write);
+}
+
 void
 dns_zone_forcereload(dns_zone_t *zone) {
 	REQUIRE(DNS_ZONE_VALID(zone));
@@ -7813,26 +11096,66 @@ dns_zone_isforced(dns_zone_t *zone) {
 
 isc_result_t
 dns_zone_setstatistics(dns_zone_t *zone, isc_boolean_t on) {
-	isc_result_t result = ISC_R_SUCCESS;
+	/*
+	 * This function is obsoleted.
+	 */
+	UNUSED(zone);
+	UNUSED(on);
+	return (ISC_R_NOTIMPLEMENTED);
+}
+
+isc_uint64_t *
+dns_zone_getstatscounters(dns_zone_t *zone) {
+	/*
+	 * This function is obsoleted.
+	 */
+	UNUSED(zone);
+	return (NULL);
+}
+
+void
+dns_zone_setstats(dns_zone_t *zone, isc_stats_t *stats) {
+	REQUIRE(DNS_ZONE_VALID(zone));
+	REQUIRE(zone->stats == NULL);
 
 	LOCK_ZONE(zone);
-	if (on) {
-		if (zone->counters != NULL)
-			goto done;
-		result = dns_stats_alloccounters(zone->mctx, &zone->counters);
-	} else {
-		if (zone->counters == NULL)
-			goto done;
-		dns_stats_freecounters(zone->mctx, &zone->counters);
+	zone->stats = NULL;
+	isc_stats_attach(stats, &zone->stats);
+	UNLOCK_ZONE(zone);
+}
+
+void
+dns_zone_setrequeststats(dns_zone_t *zone, isc_stats_t *stats) {
+	REQUIRE(DNS_ZONE_VALID(zone));
+
+	LOCK_ZONE(zone);
+	if (zone->requeststats_on && stats == NULL)
+		zone->requeststats_on = ISC_FALSE;
+	else if (!zone->requeststats_on && stats != NULL) {
+		if (zone->requeststats == NULL) {
+			isc_stats_attach(stats, &zone->requeststats);
+			zone->requeststats_on = ISC_TRUE;
+		}
 	}
- done:
 	UNLOCK_ZONE(zone);
-	return (result);
+
+	return;
 }
 
-isc_uint64_t *
-dns_zone_getstatscounters(dns_zone_t *zone) {
-	return (zone->counters);
+isc_stats_t *
+dns_zone_getrequeststats(dns_zone_t *zone) {
+	/*
+	 * We don't lock zone for efficiency reason.  This is not catastrophic
+	 * because requeststats must always be valid when requeststats_on is
+	 * true.
+	 * Some counters may be incremented while requeststats_on is becoming
+	 * false, or some cannot be incremented just after the statistics are
+	 * installed, but it shouldn't matter much in practice.
+	 */
+	if (zone->requeststats_on)
+		return (zone->requeststats);
+	else
+		return (NULL);
 }
 
 void
@@ -8043,3 +11366,152 @@ dns_zone_getnotifydelay(dns_zone_t *zone) {
 
 	return (zone->notifydelay);
 }
+
+isc_result_t
+dns_zone_signwithkey(dns_zone_t *zone, dns_secalg_t algorithm,
+		     isc_uint16_t keyid, isc_boolean_t delete)
+{
+	isc_result_t result;
+	REQUIRE(DNS_ZONE_VALID(zone));
+
+	dns_zone_log(zone, ISC_LOG_NOTICE,
+		     "dns_zone_signwithkey(algorithm=%u, keyid=%u)",
+		     algorithm, keyid);
+	LOCK_ZONE(zone);
+	result = zone_signwithkey(zone, algorithm, keyid, delete);
+	UNLOCK_ZONE(zone);
+
+	return (result);
+}
+
+static const char *hex = "0123456789ABCDEF";
+
+isc_result_t
+dns_zone_addnsec3chain(dns_zone_t *zone, dns_rdata_nsec3param_t *nsec3param) {
+	isc_result_t result;
+	char salt[255*2+1];
+	unsigned int i, j;
+
+	REQUIRE(DNS_ZONE_VALID(zone));
+
+	if (nsec3param->salt_length != 0) {
+		INSIST((nsec3param->salt_length * 2U) < sizeof(salt));
+		for (i = 0, j = 0; i < nsec3param->salt_length; i++) {
+			salt[j++] = hex[(nsec3param->salt[i] >> 4) & 0xf];
+			salt[j++] = hex[nsec3param->salt[i] & 0xf];
+		}
+		salt[j] = '\0';
+	} else
+		strcpy(salt, "-");
+	dns_zone_log(zone, ISC_LOG_NOTICE,
+		     "dns_zone_addnsec3chain(hash=%u, iterations=%u, salt=%s)",
+		     nsec3param->hash, nsec3param->iterations,
+		     salt);
+	LOCK_ZONE(zone);
+	result = zone_addnsec3chain(zone, nsec3param);
+	UNLOCK_ZONE(zone);
+
+	return (result);
+}
+
+void
+dns_zone_setnodes(dns_zone_t *zone, isc_uint32_t nodes) {
+	REQUIRE(DNS_ZONE_VALID(zone));
+
+	if (nodes == 0)
+		nodes = 1;
+	zone->nodes = nodes;
+}
+
+void
+dns_zone_setsignatures(dns_zone_t *zone, isc_uint32_t signatures) {
+	REQUIRE(DNS_ZONE_VALID(zone));
+
+	/*
+	 * We treat signatures as a signed value so explicitly
+	 * limit its range here.
+	 */
+	if (signatures > ISC_INT32_MAX)
+		signatures = ISC_INT32_MAX;
+	else if (signatures == 0)
+		signatures = 1;
+	zone->signatures = signatures;
+}
+
+void
+dns_zone_setprivatetype(dns_zone_t *zone, dns_rdatatype_t type) {
+	REQUIRE(DNS_ZONE_VALID(zone));
+	zone->privatetype = type;
+}
+
+dns_rdatatype_t
+dns_zone_getprivatetype(dns_zone_t *zone) {
+	REQUIRE(DNS_ZONE_VALID(zone));
+	return (zone->privatetype);
+}
+
+static isc_result_t
+zone_signwithkey(dns_zone_t *zone, dns_secalg_t algorithm, isc_uint16_t keyid,
+		 isc_boolean_t delete)
+{
+	dns_signing_t *signing;
+	dns_signing_t *current;
+	isc_result_t result = ISC_R_SUCCESS;
+	isc_time_t now;
+
+	signing = isc_mem_get(zone->mctx, sizeof *signing);
+	if (signing == NULL)
+		return (ISC_R_NOMEMORY);
+
+	signing->magic = 0;
+	signing->db  = NULL;
+	signing->dbiterator = NULL;
+	signing->algorithm = algorithm;
+	signing->keyid = keyid;
+	signing->delete = delete;
+	signing->done = ISC_FALSE;
+
+	TIME_NOW(&now);
+
+	for (current = ISC_LIST_HEAD(zone->signing);
+	     current != NULL;
+	     current = ISC_LIST_NEXT(current, link)) {
+		if (current->db == zone->db &&
+		    current->algorithm == signing->algorithm &&
+		    current->keyid == signing->keyid) {
+			if (current->delete != signing->delete)
+				current->done = ISC_TRUE;
+			else
+				goto cleanup;
+		}
+	}
+
+	if (zone->db != NULL) {
+		dns_db_attach(zone->db, &signing->db);
+		result = dns_db_createiterator(signing->db, 0,
+					       &signing->dbiterator);
+
+		if (result == ISC_R_SUCCESS)
+			result = dns_dbiterator_first(signing->dbiterator);
+		if (result == ISC_R_SUCCESS) {
+			dns_dbiterator_pause(signing->dbiterator);
+			ISC_LIST_INITANDAPPEND(zone->signing, signing, link);
+			signing = NULL;
+			if (isc_time_isepoch(&zone->signingtime)) {
+				zone->signingtime = now;
+				if (zone->task != NULL)
+					zone_settimer(zone, &now);
+			}
+		}
+	} else
+		result = ISC_R_NOTFOUND;
+
+ cleanup:
+	if (signing != NULL) {
+		dns_db_detach(&signing->db);
+		if (signing->dbiterator != NULL)
+			dns_dbiterator_destroy(&signing->dbiterator);
+		isc_mem_put(zone->mctx, signing, sizeof *signing);
+	}
+	return (result);
+}
diff --git a/contrib/bind9/lib/dns/zonekey.c b/contrib/bind9/lib/dns/zonekey.c
index 0ed63bb..bf7474b 100644
--- a/contrib/bind9/lib/dns/zonekey.c
+++ b/contrib/bind9/lib/dns/zonekey.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: zonekey.c,v 1.5.18.2 2005/04/29 00:16:08 marka Exp $ */
+/* $Id: zonekey.c,v 1.9 2007/06/19 23:47:16 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/dns/zt.c b/contrib/bind9/lib/dns/zt.c
index 4cb8f3f..ed7f28a 100644
--- a/contrib/bind9/lib/dns/zt.c
+++ b/contrib/bind9/lib/dns/zt.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: zt.c,v 1.38.18.5 2005/11/30 03:44:39 marka Exp $ */
+/* $Id: zt.c,v 1.47 2007/06/19 23:47:16 tbox Exp $ */
 
 /*! \file */
 
@@ -63,7 +63,8 @@ static isc_result_t
 freezezones(dns_zone_t *zone, void *uap);
 
 isc_result_t
-dns_zt_create(isc_mem_t *mctx, dns_rdataclass_t rdclass, dns_zt_t **ztp) {
+dns_zt_create(isc_mem_t *mctx, dns_rdataclass_t rdclass, dns_zt_t **ztp)
+{
 	dns_zt_t *zt;
 	isc_result_t result;
 
diff --git a/contrib/bind9/lib/isc/Makefile.in b/contrib/bind9/lib/isc/Makefile.in
index 82afe5f..6fa284b 100644
--- a/contrib/bind9/lib/isc/Makefile.in
+++ b/contrib/bind9/lib/isc/Makefile.in
@@ -1,4 +1,4 @@
-# Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1998-2003  Internet Software Consortium.
 #
 # Permission to use, copy, modify, and/or 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.81.18.10 2008/06/24 23:45:55 tbox Exp $
+# $Id: Makefile.in,v 1.96.50.3 2009/02/16 01:02:58 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -51,28 +51,32 @@ WIN32OBJS = 	win32/condition.@O@ win32/dir.@O@ win32/file.@O@ \
 
 # Alphabetically
 OBJS =		@ISC_EXTRA_OBJS@ \
-		assertions.@O@ base64.@O@ bitstring.@O@ buffer.@O@ \
+		assertions.@O@ base32.@O@ base64.@O@ bitstring.@O@ buffer.@O@ \
 		bufferlist.@O@ commandline.@O@ error.@O@ event.@O@ \
-		hash.@O@ heap.@O@ hex.@O@ hmacmd5.@O@ hmacsha.@O@\
-		lex.@O@ lfsr.@O@ lib.@O@ log.@O@ md5.@O@ \
-		mem.@O@ mutexblock.@O@ netaddr.@O@ netscope.@O@ ondestroy.@O@ \
-		parseint.@O@ portset.@O@ quota.@O@ random.@O@ \
+		hash.@O@ heap.@O@ hex.@O@ hmacmd5.@O@ hmacsha.@O@ \
+		httpd.@O@ inet_aton.@O@ iterated_hash.@O@ \
+		lex.@O@ lfsr.@O@ lib.@O@ log.@O@ \
+		md5.@O@ mem.@O@ mutexblock.@O@ \
+		netaddr.@O@ netscope.@O@ ondestroy.@O@ \
+		parseint.@O@ portset.@O@ quota.@O@ radix.@O@ random.@O@ \
 		ratelimiter.@O@ refcount.@O@ region.@O@ result.@O@ rwlock.@O@ \
-		serial.@O@ sha1.@O@ sha2.@O@ sockaddr.@O@ string.@O@ \
-	        strtoul.@O@ symtab.@O@ task.@O@ taskpool.@O@ timer.@O@ \
-	        version.@O@ ${UNIXOBJS} ${NLSOBJS} ${THREADOBJS}
+		serial.@O@ sha1.@O@ sha2.@O@ sockaddr.@O@ stats.@O@ \
+		string.@O@ strtoul.@O@ symtab.@O@ task.@O@ taskpool.@O@ \
+		timer.@O@ version.@O@ ${UNIXOBJS} ${NLSOBJS} ${THREADOBJS}
 
 # Alphabetically
 SRCS =		@ISC_EXTRA_SRCS@ \
-		assertions.c base64.c bitstring.c buffer.c \
+		assertions.c base32.c base64.c bitstring.c buffer.c \
 		bufferlist.c commandline.c error.c event.c \
 		heap.c hex.c hmacmd5.c hmacsha.c \
+		httpd.c inet_aton.c iterated_hash.c \
 		lex.c lfsr.c lib.c log.c \
-		md5.c mem.c mutexblock.c netaddr.c netscope.c ondestroy.c \
-		parseint.c portset.c quota.c random.c \
+		md5.c mem.c mutexblock.c \
+		netaddr.c netscope.c ondestroy.c \
+		parseint.c portset.c quota.c radix.c random.c \
 		ratelimiter.c refcount.c region.c result.c rwlock.c \
-		serial.c sha1.c sha2.c sockaddr.c string.c strtoul.c symtab.c \
-		task.c taskpool.c timer.c version.c
+		serial.c sha1.c sha2.c sockaddr.c stats.c string.c strtoul.c \
+		symtab.c task.c taskpool.c timer.c version.c
 
 LIBS =		@LIBS@
 
diff --git a/contrib/bind9/lib/isc/alpha/Makefile.in b/contrib/bind9/lib/isc/alpha/Makefile.in
index c8e77e4..324db07 100644
--- a/contrib/bind9/lib/isc/alpha/Makefile.in
+++ b/contrib/bind9/lib/isc/alpha/Makefile.in
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.2.2.1 2007/09/14 04:26:38 marka Exp $
+# $Id: Makefile.in,v 1.2 2007/09/14 04:09:59 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/alpha/include/Makefile.in b/contrib/bind9/lib/isc/alpha/include/Makefile.in
index f4dd2f6..f1d8bdd 100644
--- a/contrib/bind9/lib/isc/alpha/include/Makefile.in
+++ b/contrib/bind9/lib/isc/alpha/include/Makefile.in
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.2.2.1 2007/09/14 04:26:38 marka Exp $
+# $Id: Makefile.in,v 1.2 2007/09/14 04:09:59 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/alpha/include/isc/Makefile.in b/contrib/bind9/lib/isc/alpha/include/isc/Makefile.in
index 6760ce6..5f116ca 100644
--- a/contrib/bind9/lib/isc/alpha/include/isc/Makefile.in
+++ b/contrib/bind9/lib/isc/alpha/include/isc/Makefile.in
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.2.2.1 2007/09/14 04:26:38 marka Exp $
+# $Id: Makefile.in,v 1.2 2007/09/14 04:09:59 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/alpha/include/isc/atomic.h b/contrib/bind9/lib/isc/alpha/include/isc/atomic.h
index a4b9b15..f60f9fd 100644
--- a/contrib/bind9/lib/isc/alpha/include/isc/atomic.h
+++ b/contrib/bind9/lib/isc/alpha/include/isc/atomic.h
@@ -1,7 +1,7 @@
 /*
- * Copyright (C) 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2005, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: atomic.h,v 1.2.2.2 2005/06/16 22:01:01 jinmei Exp $ */
+/* $Id: atomic.h,v 1.5.332.2 2009/04/08 06:47:32 tbox Exp $ */
 
 /*
  * This code was written based on FreeBSD's kernel source whose copyright
@@ -62,16 +62,20 @@
 
 /*
  * This routine atomically increments the value stored in 'p' by 'val', and
- * returns the previous value.
+ * returns the previous value.  Memory access ordering around this function
+ * can be critical, so we add explicit memory block instructions at the
+ * beginning and the end of it (same for other functions).
  */
-static inline isc_int32_t 
+static inline isc_int32_t
 isc_atomic_xadd(isc_int32_t *p, isc_int32_t val) {
-	return (asm("1:"
+	return (asm("mb;"
+		    "1:"
 		    "ldl_l %t0, 0(%a0);"	/* load old value */
 		    "mov %t0, %v0;"		/* copy the old value */
 		    "addl %t0, %a1, %t0;"	/* calculate new value */
 		    "stl_c %t0, 0(%a0);"	/* attempt to store */
-		    "beq %t0, 1b;",		/* spin if failed */
+		    "beq %t0, 1b;"		/* spin if failed */
+		    "mb;",
 		    p, val));
 }
 
@@ -80,11 +84,13 @@ isc_atomic_xadd(isc_int32_t *p, isc_int32_t val) {
  */
 static inline void
 isc_atomic_store(isc_int32_t *p, isc_int32_t val) {
-	(void)asm("1:"
+	(void)asm("mb;"
+		  "1:"
 		  "ldl_l %t0, 0(%a0);"		/* load old value */
 		  "mov %a1, %t0;"		/* value to store */
 		  "stl_c %t0, 0(%a0);"		/* attempt to store */
-		  "beq %t0, 1b;",		/* spin if failed */
+		  "beq %t0, 1b;"		/* spin if failed */
+		  "mb;",
 		  p, val);
 }
 
@@ -96,7 +102,8 @@ isc_atomic_store(isc_int32_t *p, isc_int32_t val) {
 static inline isc_int32_t
 isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, isc_int32_t val) {
 
-	return(asm("1:"
+	return(asm("mb;"
+		   "1:"
 		   "ldl_l %t0, 0(%a0);"		/* load old value */
 		   "mov %t0, %v0;"		/* copy the old value */
 		   "cmpeq %t0, %a1, %t0;"	/* compare */
@@ -104,22 +111,25 @@ isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, isc_int32_t val) {
 		   "mov %a2, %t0;"		/* value to store */
 		   "stl_c %t0, 0(%a0);"		/* attempt to store */
 		   "beq %t0, 1b;"		/* if it failed, spin */
-		   "2:",
+		   "2:"
+		   "mb;",
 		   p, cmpval, val));
 }
 #elif defined (ISC_PLATFORM_USEGCCASM)
-static inline isc_int32_t 
+static inline isc_int32_t
 isc_atomic_xadd(isc_int32_t *p, isc_int32_t val) {
 	isc_int32_t temp, prev;
 
 	__asm__ volatile(
+		"mb;"
 		"1:"
 		"ldl_l %0, %1;"			/* load old value */
 		"mov %0, %2;"			/* copy the old value */
 		"addl %0, %3, %0;"		/* calculate new value */
 		"stl_c %0, %1;"			/* attempt to store */
 		"beq %0, 1b;"			/* spin if failed */
-		: "=&r"(temp), "+m"(*p), "=r"(prev)
+		"mb;"
+		: "=&r"(temp), "+m"(*p), "=&r"(prev)
 		: "r"(val)
 		: "memory");
 
@@ -131,11 +141,13 @@ isc_atomic_store(isc_int32_t *p, isc_int32_t val) {
 	isc_int32_t temp;
 
 	__asm__ volatile(
+		"mb;"
 		"1:"
 		"ldl_l %0, %1;"			/* load old value */
 		"mov %2, %0;"			/* value to store */
 		"stl_c %0, %1;"			/* attempt to store */
 		"beq %0, 1b;"			/* if it failed, spin */
+		"mb;"
 		: "=&r"(temp), "+m"(*p)
 		: "r"(val)
 		: "memory");
@@ -146,6 +158,7 @@ isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, isc_int32_t val) {
 	isc_int32_t temp, prev;
 
 	__asm__ volatile(
+		"mb;"
 		"1:"
 		"ldl_l %0, %1;"			/* load old value */
 		"mov %0, %2;"			/* copy the old value */
@@ -155,7 +168,8 @@ isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, isc_int32_t val) {
 		"stl_c %0, %1;"			/* attempt to store */
 		"beq %0, 1b;"			/* if it failed, spin */
 		"2:"
-		: "=&r"(temp), "+m"(*p), "=r"(prev)
+		"mb;"
+		: "=&r"(temp), "+m"(*p), "=&r"(prev)
 		: "r"(cmpval), "r"(val)
 		: "memory");
 
diff --git a/contrib/bind9/lib/isc/api b/contrib/bind9/lib/isc/api
index 0b8a3bc..5ef8dc0 100644
--- a/contrib/bind9/lib/isc/api
+++ b/contrib/bind9/lib/isc/api
@@ -1,3 +1,3 @@
-LIBINTERFACE = 36
-LIBREVISION = 2
-LIBAGE = 0
+LIBINTERFACE = 51
+LIBREVISION = 1
+LIBAGE = 1
diff --git a/contrib/bind9/lib/isc/assertions.c b/contrib/bind9/lib/isc/assertions.c
index 3eb27e0..4c9251b 100644
--- a/contrib/bind9/lib/isc/assertions.c
+++ b/contrib/bind9/lib/isc/assertions.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1997-2001  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: assertions.c,v 1.17.18.4 2008/10/15 23:46:06 tbox Exp $ */
+/* $Id: assertions.c,v 1.23 2008/10/15 23:47:31 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/base32.c b/contrib/bind9/lib/isc/base32.c
new file mode 100644
index 0000000..3000a84
--- /dev/null
+++ b/contrib/bind9/lib/isc/base32.c
@@ -0,0 +1,371 @@
+/*
+ * Copyright (C) 2008, 2009  Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or 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: base32.c,v 1.3.116.2 2009/01/18 23:47:41 tbox Exp $ */
+
+/*! \file */
+
+#include <config.h>
+
+#include <isc/base32.h>
+#include <isc/buffer.h>
+#include <isc/lex.h>
+#include <isc/region.h>
+#include <isc/string.h>
+#include <isc/util.h>
+
+#define RETERR(x) do { \
+	isc_result_t _r = (x); \
+	if (_r != ISC_R_SUCCESS) \
+		return (_r); \
+	} while (0)
+
+
+/*@{*/
+/*!
+ * These static functions are also present in lib/dns/rdata.c.  I'm not
+ * sure where they should go. -- bwelling
+ */
+static isc_result_t
+str_totext(const char *source, isc_buffer_t *target);
+
+static isc_result_t
+mem_tobuffer(isc_buffer_t *target, void *base, unsigned int length);
+
+/*@}*/
+
+static const char base32[] =
+	 "ABCDEFGHIJKLMNOPQRSTUVWXYZ234567=abcdefghijklmnopqrstuvwxyz234567";
+static const char base32hex[] =
+	"0123456789ABCDEFGHIJKLMNOPQRSTUV=0123456789abcdefghijklmnopqrstuv";
+
+static isc_result_t
+base32_totext(isc_region_t *source, int wordlength, const char *wordbreak,
+	      isc_buffer_t *target, const char base[])
+{
+	char buf[9];
+	unsigned int loops = 0;
+
+	if (wordlength >= 0 && wordlength < 8)
+		wordlength = 8;
+
+	memset(buf, 0, sizeof(buf));
+	while (source->length > 0) {
+		buf[0] = base[((source->base[0]>>3)&0x1f)];	/* 5 + */
+		if (source->length == 1) {
+			buf[1] = base[(source->base[0]<<2)&0x1c];
+			buf[2] = buf[3] = buf[4] = '=';
+			buf[5] = buf[6] = buf[7] = '=';
+			RETERR(str_totext(buf, target));
+			break;
+		}
+		buf[1] = base[((source->base[0]<<2)&0x1c)|	/* 3 = 8 */
+			      ((source->base[1]>>6)&0x03)];	/* 2 + */
+		buf[2] = base[((source->base[1]>>1)&0x1f)];	/* 5 + */
+		if (source->length == 2) {
+			buf[3] = base[(source->base[1]<<4)&0x10];
+			buf[4] = buf[5] = buf[6] = buf[7] = '=';
+			RETERR(str_totext(buf, target));
+			break;
+		}
+		buf[3] = base[((source->base[1]<<4)&0x10)|	/* 1 = 8 */
+			      ((source->base[2]>>4)&0x0f)];	/* 4 + */
+		if (source->length == 3) {
+			buf[4] = base[(source->base[2]<<1)&0x1e];
+			buf[5] = buf[6] = buf[7] = '=';
+			RETERR(str_totext(buf, target));
+			break;
+		}
+		buf[4] = base[((source->base[2]<<1)&0x1e)|	/* 4 = 8 */
+			      ((source->base[3]>>7)&0x01)];	/* 1 + */
+		buf[5] = base[((source->base[3]>>2)&0x1f)];	/* 5 + */
+		if (source->length == 4) {
+			buf[6] = base[(source->base[3]<<3)&0x18];
+			buf[7] = '=';
+			RETERR(str_totext(buf, target));
+			break;
+		}
+		buf[6] = base[((source->base[3]<<3)&0x18)|	/* 2 = 8 */
+			      ((source->base[4]>>5)&0x07)];	/* 3 + */
+		buf[7] = base[source->base[4]&0x1f];		/* 5 = 8 */
+		RETERR(str_totext(buf, target));
+		isc_region_consume(source, 5);
+
+		loops++;
+		if (source->length != 0 && wordlength >= 0 &&
+		    (int)((loops + 1) * 8) >= wordlength)
+		{
+			loops = 0;
+			RETERR(str_totext(wordbreak, target));
+		}
+	}
+	return (ISC_R_SUCCESS);
+}
+
+isc_result_t
+isc_base32_totext(isc_region_t *source, int wordlength,
+		  const char *wordbreak, isc_buffer_t *target)
+{
+	return (base32_totext(source, wordlength, wordbreak, target, base32));
+}
+
+isc_result_t
+isc_base32hex_totext(isc_region_t *source, int wordlength,
+		     const char *wordbreak, isc_buffer_t *target)
+{
+	return (base32_totext(source, wordlength, wordbreak, target,
+			      base32hex));
+}
+
+/*%
+ * State of a base32 decoding process in progress.
+ */
+typedef struct {
+	int length;		/*%< Desired length of binary data or -1 */
+	isc_buffer_t *target;	/*%< Buffer for resulting binary data */
+	int digits;		/*%< Number of buffered base32 digits */
+	isc_boolean_t seen_end;	/*%< True if "=" end marker seen */
+	int val[8];
+	const char *base;	/*%< Which encoding we are using */
+	int seen_32;		/*%< Number of significant bytes if non zero */
+} base32_decode_ctx_t;
+
+static inline void
+base32_decode_init(base32_decode_ctx_t *ctx, int length,
+		   const char base[], isc_buffer_t *target)
+{
+	ctx->digits = 0;
+	ctx->seen_end = ISC_FALSE;
+	ctx->seen_32 = 0;
+	ctx->length = length;
+	ctx->target = target;
+	ctx->base = base;
+}
+
+static inline isc_result_t
+base32_decode_char(base32_decode_ctx_t *ctx, int c) {
+	char *s;
+	unsigned int last;
+
+	if (ctx->seen_end)
+		return (ISC_R_BADBASE32);
+	if ((s = strchr(ctx->base, c)) == NULL)
+		return (ISC_R_BADBASE32);
+	last = s - ctx->base;
+	/*
+	 * Handle lower case.
+	 */
+	if (last > 32)
+		last -= 33;
+	/*
+	 * Check that padding is contiguous.
+	 */
+	if (last != 32 && ctx->seen_32 != 0)
+		return (ISC_R_BADBASE32);
+	/*
+	 * Check that padding starts at the right place and that
+	 * bits that should be zero are.
+	 * Record how many significant bytes in answer (seen_32).
+	 */
+	if (last == 32 && ctx->seen_32 == 0)
+		switch (ctx->digits) {
+		case 0:
+		case 1:
+			return (ISC_R_BADBASE32);
+		case 2:
+			if ((ctx->val[1]&0x03) != 0)
+				return (ISC_R_BADBASE32);
+			ctx->seen_32 = 1;
+			break;
+		case 3:
+			return (ISC_R_BADBASE32);
+		case 4:
+			if ((ctx->val[3]&0x0f) != 0)
+				return (ISC_R_BADBASE32);
+			ctx->seen_32 = 3;
+			break;
+		case 5:
+			if ((ctx->val[4]&0x01) != 0)
+				return (ISC_R_BADBASE32);
+			ctx->seen_32 = 3;
+			break;
+		case 6:
+			return (ISC_R_BADBASE32);
+		case 7:
+			if ((ctx->val[6]&0x07) != 0)
+				return (ISC_R_BADBASE32);
+			ctx->seen_32 = 4;
+			break;
+		}
+	/*
+	 * Zero fill pad values.
+	 */
+	ctx->val[ctx->digits++] = (last == 32) ? 0 : last;
+
+	if (ctx->digits == 8) {
+		int n = 5;
+		unsigned char buf[5];
+
+		if (ctx->seen_32 != 0) {
+			ctx->seen_end = ISC_TRUE;
+			n = ctx->seen_32;
+		}
+		buf[0] = (ctx->val[0]<<3)|(ctx->val[1]>>2);
+		buf[1] = (ctx->val[1]<<6)|(ctx->val[2]<<1)|(ctx->val[3]>>4);
+		buf[2] = (ctx->val[3]<<4)|(ctx->val[4]>>1);
+		buf[3] = (ctx->val[4]<<7)|(ctx->val[5]<<2)|(ctx->val[6]>>3);
+		buf[4] = (ctx->val[6]<<5)|(ctx->val[7]);
+		RETERR(mem_tobuffer(ctx->target, buf, n));
+		if (ctx->length >= 0) {
+			if (n > ctx->length)
+				return (ISC_R_BADBASE32);
+			else
+				ctx->length -= n;
+		}
+		ctx->digits = 0;
+	}
+	return (ISC_R_SUCCESS);
+}
+
+static inline isc_result_t
+base32_decode_finish(base32_decode_ctx_t *ctx) {
+	if (ctx->length > 0)
+		return (ISC_R_UNEXPECTEDEND);
+	if (ctx->digits != 0)
+		return (ISC_R_BADBASE32);
+	return (ISC_R_SUCCESS);
+}
+
+static isc_result_t
+base32_tobuffer(isc_lex_t *lexer, const char base[], isc_buffer_t *target,
+		int length)
+{
+	base32_decode_ctx_t ctx;
+	isc_textregion_t *tr;
+	isc_token_t token;
+	isc_boolean_t eol;
+
+	base32_decode_init(&ctx, length, base, target);
+
+	while (!ctx.seen_end && (ctx.length != 0)) {
+		unsigned int i;
+
+		if (length > 0)
+			eol = ISC_FALSE;
+		else
+			eol = ISC_TRUE;
+		RETERR(isc_lex_getmastertoken(lexer, &token,
+					      isc_tokentype_string, eol));
+		if (token.type != isc_tokentype_string)
+			break;
+		tr = &token.value.as_textregion;
+		for (i = 0; i < tr->length; i++)
+			RETERR(base32_decode_char(&ctx, tr->base[i]));
+	}
+	if (ctx.length < 0 && !ctx.seen_end)
+		isc_lex_ungettoken(lexer, &token);
+	RETERR(base32_decode_finish(&ctx));
+	return (ISC_R_SUCCESS);
+}
+
+isc_result_t
+isc_base32_tobuffer(isc_lex_t *lexer, isc_buffer_t *target, int length) {
+	return (base32_tobuffer(lexer, base32, target, length));
+}
+
+isc_result_t
+isc_base32hex_tobuffer(isc_lex_t *lexer, isc_buffer_t *target, int length) {
+	return (base32_tobuffer(lexer, base32hex, target, length));
+}
+
+static isc_result_t
+base32_decodestring(const char *cstr, const char base[], isc_buffer_t *target) {
+	base32_decode_ctx_t ctx;
+
+	base32_decode_init(&ctx, -1, base, target);
+	for (;;) {
+		int c = *cstr++;
+		if (c == '\0')
+			break;
+		if (c == ' ' || c == '\t' || c == '\n' || c== '\r')
+			continue;
+		RETERR(base32_decode_char(&ctx, c));
+	}
+	RETERR(base32_decode_finish(&ctx));
+	return (ISC_R_SUCCESS);
+}
+
+isc_result_t
+isc_base32_decodestring(const char *cstr, isc_buffer_t *target) {
+	return (base32_decodestring(cstr, base32, target));
+}
+
+isc_result_t
+isc_base32hex_decodestring(const char *cstr, isc_buffer_t *target) {
+	return (base32_decodestring(cstr, base32hex, target));
+}
+
+static isc_result_t
+base32_decoderegion(isc_region_t *source, const char base[], isc_buffer_t *target) {
+	base32_decode_ctx_t ctx;
+
+	base32_decode_init(&ctx, -1, base, target);
+	while (source->length != 0) {
+		int c = *source->base;
+		RETERR(base32_decode_char(&ctx, c));
+		isc_region_consume(source, 1);
+	}
+	RETERR(base32_decode_finish(&ctx));
+	return (ISC_R_SUCCESS);
+}
+
+isc_result_t
+isc_base32_decoderegion(isc_region_t *source, isc_buffer_t *target) {
+	return (base32_decoderegion(source, base32, target));
+}
+
+isc_result_t
+isc_base32hex_decoderegion(isc_region_t *source, isc_buffer_t *target) {
+	return (base32_decoderegion(source, base32hex, target));
+}
+
+static isc_result_t
+str_totext(const char *source, isc_buffer_t *target) {
+	unsigned int l;
+	isc_region_t region;
+
+	isc_buffer_availableregion(target, &region);
+	l = strlen(source);
+
+	if (l > region.length)
+		return (ISC_R_NOSPACE);
+
+	memcpy(region.base, source, l);
+	isc_buffer_add(target, l);
+	return (ISC_R_SUCCESS);
+}
+
+static isc_result_t
+mem_tobuffer(isc_buffer_t *target, void *base, unsigned int length) {
+	isc_region_t tr;
+
+	isc_buffer_availableregion(target, &tr);
+	if (length > tr.length)
+		return (ISC_R_NOSPACE);
+	memcpy(tr.base, base, length);
+	isc_buffer_add(target, length);
+	return (ISC_R_SUCCESS);
+}
diff --git a/contrib/bind9/lib/isc/base64.c b/contrib/bind9/lib/isc/base64.c
index faeae92..13ed6b5 100644
--- a/contrib/bind9/lib/isc/base64.c
+++ b/contrib/bind9/lib/isc/base64.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: base64.c,v 1.28.18.2 2005/04/29 00:16:44 marka Exp $ */
+/* $Id: base64.c,v 1.32 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/bitstring.c b/contrib/bind9/lib/isc/bitstring.c
index 105b5aa..33c7c1f 100644
--- a/contrib/bind9/lib/isc/bitstring.c
+++ b/contrib/bind9/lib/isc/bitstring.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: bitstring.c,v 1.13.18.2 2005/04/29 00:16:44 marka Exp $ */
+/* $Id: bitstring.c,v 1.17 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/buffer.c b/contrib/bind9/lib/isc/buffer.c
index fc07c00..1b59e65 100644
--- a/contrib/bind9/lib/isc/buffer.c
+++ b/contrib/bind9/lib/isc/buffer.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: buffer.c,v 1.40.18.2 2005/04/29 00:16:44 marka Exp $ */
+/* $Id: buffer.c,v 1.49 2008/09/25 04:02:39 tbox Exp $ */
 
 /*! \file */
 
@@ -40,6 +40,35 @@ isc__buffer_init(isc_buffer_t *b, const void *base, unsigned int length) {
 }
 
 void
+isc__buffer_initnull(isc_buffer_t *b) {
+	/*
+	 * Initialize a new buffer which has no backing store.  This can
+	 * later be grown as needed and swapped in place.
+	 */
+
+	ISC__BUFFER_INIT(b, NULL, 0);
+}
+
+void
+isc_buffer_reinit(isc_buffer_t *b, void *base, unsigned int length) {
+	/*
+	 * Re-initialize the buffer enough to reconfigure the base of the
+	 * buffer.  We will swap in the new buffer, after copying any
+	 * data we contain into the new buffer and adjusting all of our
+	 * internal pointers.
+	 *
+	 * The buffer must not be smaller than the length of the original
+	 * buffer.
+	 */
+	REQUIRE(b->length <= length);
+	REQUIRE(base != NULL);
+
+	(void)memmove(base, b->base, b->length);
+	b->base = base;
+	b->length = length;
+}
+
+void
 isc__buffer_invalidate(isc_buffer_t *b) {
 	/*
 	 * Make 'b' an invalid buffer.
@@ -287,6 +316,14 @@ isc__buffer_putuint16(isc_buffer_t *b, isc_uint16_t val) {
 	ISC__BUFFER_PUTUINT16(b, val);
 }
 
+void
+isc__buffer_putuint24(isc_buffer_t *b, isc_uint32_t val) {
+	REQUIRE(ISC_BUFFER_VALID(b));
+	REQUIRE(b->used + 3 <= b->length);
+
+	ISC__BUFFER_PUTUINT24(b, val);
+}
+
 isc_uint32_t
 isc_buffer_getuint32(isc_buffer_t *b) {
 	unsigned char *cp;
@@ -318,6 +355,45 @@ isc__buffer_putuint32(isc_buffer_t *b, isc_uint32_t val) {
 	ISC__BUFFER_PUTUINT32(b, val);
 }
 
+isc_uint64_t
+isc_buffer_getuint48(isc_buffer_t *b) {
+	unsigned char *cp;
+	isc_uint64_t result;
+
+	/*
+	 * Read an unsigned 48-bit integer in network byte order from 'b',
+	 * convert it to host byte order, and return it.
+	 */
+
+	REQUIRE(ISC_BUFFER_VALID(b));
+	REQUIRE(b->used - b->current >= 6);
+
+	cp = isc_buffer_current(b);
+	b->current += 6;
+	result = ((isc_int64_t)(cp[0])) << 40;
+	result |= ((isc_int64_t)(cp[1])) << 32;
+	result |= ((isc_int64_t)(cp[2])) << 24;
+	result |= ((isc_int64_t)(cp[3])) << 16;
+	result |= ((isc_int64_t)(cp[4])) << 8;
+	result |= ((isc_int64_t)(cp[5]));
+
+	return (result);
+}
+
+void
+isc__buffer_putuint48(isc_buffer_t *b, isc_uint64_t val) {
+	isc_uint16_t valhi;
+	isc_uint32_t vallo;
+
+	REQUIRE(ISC_BUFFER_VALID(b));
+	REQUIRE(b->used + 6 <= b->length);
+
+	valhi = (isc_uint16_t)(val >> 32);
+	vallo = (isc_uint32_t)(val & 0xFFFFFFFF);
+	ISC__BUFFER_PUTUINT16(b, valhi);
+	ISC__BUFFER_PUTUINT32(b, vallo);
+}
+
 void
 isc__buffer_putmem(isc_buffer_t *b, const unsigned char *base,
 		   unsigned int length)
@@ -361,7 +437,7 @@ isc_buffer_copyregion(isc_buffer_t *b, const isc_region_t *r) {
 	 */
 	base = isc_buffer_used(b);
 	available = isc_buffer_availablelength(b);
-        if (r->length > available)
+	if (r->length > available)
 		return (ISC_R_NOSPACE);
 	memcpy(base, r->base, r->length);
 	b->used += r->length;
diff --git a/contrib/bind9/lib/isc/bufferlist.c b/contrib/bind9/lib/isc/bufferlist.c
index 773d075..0e5c125 100644
--- a/contrib/bind9/lib/isc/bufferlist.c
+++ b/contrib/bind9/lib/isc/bufferlist.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: bufferlist.c,v 1.13.18.2 2005/04/29 00:16:45 marka Exp $ */
+/* $Id: bufferlist.c,v 1.17 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/commandline.c b/contrib/bind9/lib/isc/commandline.c
index 679ed6d..aca1203 100644
--- a/contrib/bind9/lib/isc/commandline.c
+++ b/contrib/bind9/lib/isc/commandline.c
@@ -1,8 +1,8 @@
 /*
- * Portions Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -48,7 +48,7 @@
  * SUCH DAMAGE.
  */
 
-/* $Id: commandline.c,v 1.16.18.2 2005/04/29 00:16:45 marka Exp $ */
+/* $Id: commandline.c,v 1.22 2008/09/25 04:02:39 tbox Exp $ */
 
 /*! \file
  * This file was adapted from the NetBSD project's source tree, RCS ID:
@@ -107,7 +107,10 @@ isc_commandline_parse(int argc, char * const *argv, const char *options) {
 	 * the previous argv was finished.
 	 */
 	if (isc_commandline_reset || *place == '\0') {
-		isc_commandline_reset = ISC_FALSE;
+		if (isc_commandline_reset) {
+			isc_commandline_index = 1;
+			isc_commandline_reset = ISC_FALSE;
+		}
 
 		if (isc_commandline_progname == NULL)
 			isc_commandline_progname = argv[0];
diff --git a/contrib/bind9/lib/isc/entropy.c b/contrib/bind9/lib/isc/entropy.c
index 3e87d87..25ab002 100644
--- a/contrib/bind9/lib/isc/entropy.c
+++ b/contrib/bind9/lib/isc/entropy.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: entropy.c,v 1.11.18.3 2005/07/12 01:22:28 marka Exp $ */
+/* $Id: entropy.c,v 1.18.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
 /*! \file
  * \brief
@@ -290,7 +290,7 @@ entropypool_add_word(isc_entropypool_t *rp, isc_uint32_t val) {
 	 * If we have looped around the pool, increment the rotate
 	 * variable so the next value will get xored in rotated to
 	 * a different position.
-	 * Increment by a value that is relativly prime to the word size
+	 * Increment by a value that is relatively prime to the word size
 	 * to try to spread the bits throughout the pool quickly when the
 	 * pool is empty.
 	 */
@@ -1102,6 +1102,17 @@ isc_entropy_stats(isc_entropy_t *ent, FILE *out) {
 	UNLOCK(&ent->lock);
 }
 
+unsigned int
+isc_entropy_status(isc_entropy_t *ent) {
+	unsigned int estimate;
+
+	LOCK(&ent->lock);
+	estimate = ent->pool.entropy;
+	UNLOCK(&ent->lock);
+
+	return estimate;
+}
+
 void
 isc_entropy_attach(isc_entropy_t *ent, isc_entropy_t **entp) {
 	REQUIRE(VALID_ENTROPY(ent));
@@ -1251,7 +1262,7 @@ isc_entropy_usebestsource(isc_entropy_t *ectx, isc_entropysource_t **source,
 
 		if (final_result != ISC_R_SUCCESS)
 			final_result = result;
-	}	
+	}
 
 	/*
 	 * final_result is ISC_R_SUCCESS if at least one source of entropy
diff --git a/contrib/bind9/lib/isc/error.c b/contrib/bind9/lib/isc/error.c
index 282986c..095100a 100644
--- a/contrib/bind9/lib/isc/error.c
+++ b/contrib/bind9/lib/isc/error.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: error.c,v 1.17.18.2 2005/04/29 00:16:45 marka Exp $ */
+/* $Id: error.c,v 1.21 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/event.c b/contrib/bind9/lib/isc/event.c
index 7931061..8ab7524 100644
--- a/contrib/bind9/lib/isc/event.c
+++ b/contrib/bind9/lib/isc/event.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: event.c,v 1.17.18.2 2005/04/29 00:16:45 marka Exp $ */
+/* $Id: event.c,v 1.21 2007/06/19 23:47:17 tbox Exp $ */
 
 /*!
  * \file
diff --git a/contrib/bind9/lib/isc/fsaccess.c b/contrib/bind9/lib/isc/fsaccess.c
index cdab3d8..5c97183 100644
--- a/contrib/bind9/lib/isc/fsaccess.c
+++ b/contrib/bind9/lib/isc/fsaccess.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: fsaccess.c,v 1.6.18.2 2005/04/29 00:16:45 marka Exp $ */
+/* $Id: fsaccess.c,v 1.10 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! \file
  * \brief
diff --git a/contrib/bind9/lib/isc/hash.c b/contrib/bind9/lib/isc/hash.c
index 4b6dc06..9911bde 100644
--- a/contrib/bind9/lib/isc/hash.c
+++ b/contrib/bind9/lib/isc/hash.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,11 +15,11 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: hash.c,v 1.6.18.5 2006/01/04 00:37:23 marka Exp $ */
+/* $Id: hash.c,v 1.13.332.3 2009/05/07 23:47:12 tbox Exp $ */
 
 /*! \file
  * Some portion of this code was derived from universal hash function
- * libraries of Rice University. 
+ * libraries of Rice University.
 \section license UH Universal Hashing Library
 
 Copyright ((c)) 2002, Rice University
@@ -244,7 +244,7 @@ isc_hash_ctxinit(isc_hash_t *hctx) {
 		goto out;
 
 	if (hctx->entropy) {
-		result = isc_entropy_getdata(hctx->entropy, 
+		result = isc_entropy_getdata(hctx->entropy,
 					     hctx->rndvector, hctx->vectorlen,
 					     NULL, 0);
 		INSIST(result == ISC_R_SUCCESS);
@@ -276,7 +276,7 @@ isc_hash_ctxinit(isc_hash_t *hctx) {
 void
 isc_hash_init() {
 	INSIST(hash != NULL && VALID_HASH(hash));
-	
+
 	isc_hash_ctxinit(hash);
 }
 
diff --git a/contrib/bind9/lib/isc/heap.c b/contrib/bind9/lib/isc/heap.c
index 9c495a7..91d78c0 100644
--- a/contrib/bind9/lib/isc/heap.c
+++ b/contrib/bind9/lib/isc/heap.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1997-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: heap.c,v 1.30.18.3 2006/04/17 18:27:33 explorer Exp $ */
+/* $Id: heap.c,v 1.37 2007/10/19 17:15:53 explorer Exp $ */
 
 /*! \file
  * Heap implementation of priority queues adapted from the following:
@@ -208,9 +208,13 @@ isc_heap_delete(isc_heap_t *heap, unsigned int index) {
 	REQUIRE(index >= 1 && index <= heap->last);
 
 	if (index == heap->last) {
+		heap->array[heap->last] = NULL;
 		heap->last--;
 	} else {
-		elt = heap->array[heap->last--];
+		elt = heap->array[heap->last];
+		heap->array[heap->last] = NULL;
+		heap->last--;
+
 		less = heap->compare(elt, heap->array[index]);
 		heap->array[index] = elt;
 		if (less)
@@ -239,9 +243,11 @@ isc_heap_decreased(isc_heap_t *heap, unsigned int index) {
 void *
 isc_heap_element(isc_heap_t *heap, unsigned int index) {
 	REQUIRE(VALID_HEAP(heap));
-	REQUIRE(index >= 1 && index <= heap->last);
+	REQUIRE(index >= 1);
 
-	return (heap->array[index]);
+	if (index <= heap->last)
+		return (heap->array[index]);
+	return (NULL);
 }
 
 void
diff --git a/contrib/bind9/lib/isc/hex.c b/contrib/bind9/lib/isc/hex.c
index 8dfec02..3fa0e69 100644
--- a/contrib/bind9/lib/isc/hex.c
+++ b/contrib/bind9/lib/isc/hex.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: hex.c,v 1.14.18.2 2005/04/29 00:16:46 marka Exp $ */
+/* $Id: hex.c,v 1.20 2008/09/25 04:02:39 tbox Exp $ */
 
 /*! \file */
 
@@ -156,7 +156,7 @@ isc_hex_tobuffer(isc_lex_t *lexer, isc_buffer_t *target, int length) {
 }
 
 isc_result_t
-isc_hex_decodestring(char *cstr, isc_buffer_t *target) {
+isc_hex_decodestring(const char *cstr, isc_buffer_t *target) {
 	hex_decode_ctx_t ctx;
 
 	hex_decode_init(&ctx, -1, target);
@@ -168,7 +168,7 @@ isc_hex_decodestring(char *cstr, isc_buffer_t *target) {
 			continue;
 		RETERR(hex_decode_char(&ctx, c));
 	}
-	RETERR(hex_decode_finish(&ctx));	
+	RETERR(hex_decode_finish(&ctx));
 	return (ISC_R_SUCCESS);
 }
 
diff --git a/contrib/bind9/lib/isc/hmacmd5.c b/contrib/bind9/lib/isc/hmacmd5.c
index f832146..63853dc 100644
--- a/contrib/bind9/lib/isc/hmacmd5.c
+++ b/contrib/bind9/lib/isc/hmacmd5.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: hmacmd5.c,v 1.7.18.5 2006/02/26 22:30:56 marka Exp $ */
+/* $Id: hmacmd5.c,v 1.14 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! \file
  * This code implements the HMAC-MD5 keyed hash algorithm
diff --git a/contrib/bind9/lib/isc/hmacsha.c b/contrib/bind9/lib/isc/hmacsha.c
index 7ee13f7..dfcd8bf 100644
--- a/contrib/bind9/lib/isc/hmacsha.c
+++ b/contrib/bind9/lib/isc/hmacsha.c
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: hmacsha.c,v 1.2.2.7 2007/08/28 07:20:06 tbox Exp $ */
+/* $Id: hmacsha.c,v 1.8 2007/08/27 03:27:53 marka Exp $ */
 
 /*
  * This code implements the HMAC-SHA1, HMAC-SHA224, HMAC-SHA256, HMAC-SHA384
diff --git a/contrib/bind9/lib/isc/httpd.c b/contrib/bind9/lib/isc/httpd.c
new file mode 100644
index 0000000..fa31325
--- /dev/null
+++ b/contrib/bind9/lib/isc/httpd.c
@@ -0,0 +1,987 @@
+/*
+ * Copyright (C) 2006-2008  Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or 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: httpd.c,v 1.16 2008/08/08 05:06:49 marka Exp $ */
+
+/*! \file */
+
+#include <config.h>
+
+#include <isc/buffer.h>
+#include <isc/httpd.h>
+#include <isc/mem.h>
+#include <isc/socket.h>
+#include <isc/string.h>
+#include <isc/task.h>
+#include <isc/util.h>
+
+#include <string.h>
+
+/*%
+ * TODO:
+ *
+ *  o  Put in better checks to make certain things are passed in correctly.
+ *     This includes a magic number for externally-visible structures,
+ *     checking for NULL-ness before dereferencing, etc.
+ *  o  Make the URL processing external functions which will fill-in a buffer
+ *     structure we provide, or return an error and we will render a generic
+ *     page and close the client.
+ */
+
+#define MSHUTTINGDOWN(cm) ((cm->flags & ISC_HTTPDMGR_FLAGSHUTTINGDOWN) != 0)
+#define MSETSHUTTINGDOWN(cm) (cm->flags |= ISC_HTTPDMGR_FLAGSHUTTINGDOWN)
+
+#ifdef DEBUG_HTTPD
+#define ENTER(x) do { fprintf(stderr, "ENTER %s\n", (x)); } while (0)
+#define EXIT(x) do { fprintf(stderr, "EXIT %s\n", (x)); } while (0)
+#define NOTICE(x) do { fprintf(stderr, "NOTICE %s\n", (x)); } while (0)
+#else
+#define ENTER(x) do { } while(0)
+#define EXIT(x) do { } while(0)
+#define NOTICE(x) do { } while(0)
+#endif
+
+#define HTTP_RECVLEN			1024
+#define HTTP_SENDGROW			1024
+#define HTTP_SEND_MAXLEN		10240
+
+/*%
+ * HTTP urls.  These are the URLs we manage, and the function to call to
+ * provide the data for it.  We pass in the base url (so the same function
+ * can handle multiple requests), and a structure to fill in to return a
+ * result to the client.  We also pass in a pointer to be filled in for
+ * the data cleanup function.
+ */
+struct isc_httpdurl {
+	char			       *url;
+	isc_httpdaction_t	       *action;
+	void			       *action_arg;
+	ISC_LINK(isc_httpdurl_t)	link;
+};
+
+#define HTTPD_CLOSE		0x0001 /* Got a Connection: close header */
+#define HTTPD_FOUNDHOST		0x0002 /* Got a Host: header */
+
+/*% http client */
+struct isc_httpd {
+	isc_httpdmgr_t	       *mgr;		/*%< our parent */
+	ISC_LINK(isc_httpd_t)	link;
+	unsigned int		state;
+	isc_socket_t		*sock;
+
+	/*%
+	 * Received data state.
+	 */
+	char			recvbuf[HTTP_RECVLEN]; /*%< receive buffer */
+	isc_uint32_t		recvlen;	/*%< length recv'd */
+	unsigned int		method;
+	char		       *url;
+	char		       *querystring;
+	char		       *protocol;
+
+	/*
+	 * Flags on the httpd client.
+	 */
+	int			flags;
+
+	/*%
+	 * Transmit data state.
+	 *
+	 * This is the data buffer we will transmit.
+	 *
+	 * This free function pointer is filled in by the rendering function
+	 * we call.  The free function is called after the data is transmitted
+	 * to the client.
+	 *
+	 * The bufflist is the list of buffers we are currently transmitting.
+	 * The headerdata is where we render our headers to.  If we run out of
+	 * space when rendering a header, we will change the size of our
+	 * buffer.  We will not free it until we are finished, and will
+	 * allocate an additional HTTP_SENDGROW bytes per header space grow.
+	 *
+	 * We currently use two buffers total, one for the headers (which
+	 * we manage) and another for the client to fill in (which it manages,
+	 * it provides the space for it, etc) -- we will pass that buffer
+	 * structure back to the caller, who is responsible for managing the
+	 * space it may have allocated as backing store for it.  This second
+	 * buffer is bodybuffer, and we only allocate the buffer itself, not
+	 * the backing store.
+	 */
+	isc_bufferlist_t	bufflist;
+	char		       *headerdata; /*%< send header buf */
+	unsigned int		headerlen;  /*%< current header buffer size */
+	isc_buffer_t		headerbuffer;
+
+	const char	       *mimetype;
+	unsigned int		retcode;
+	const char	       *retmsg;
+	isc_buffer_t		bodybuffer;
+	isc_httpdfree_t	       *freecb;
+	void		       *freecb_arg;
+};
+
+/*% lightweight socket manager for httpd output */
+struct isc_httpdmgr {
+	isc_mem_t	       *mctx;
+	isc_socket_t	       *sock;		/*%< listening socket */
+	isc_task_t	       *task;		/*%< owning task */
+	isc_timermgr_t	       *timermgr;
+
+	isc_httpdclientok_t    *client_ok;	/*%< client validator */
+	isc_httpdondestroy_t   *ondestroy;	/*%< cleanup callback */
+	void		       *cb_arg;		/*%< argument for the above */
+
+	unsigned int		flags;
+	ISC_LIST(isc_httpd_t)	running;	/*%< running clients */
+
+	isc_mutex_t		lock;
+
+	ISC_LIST(isc_httpdurl_t) urls;		/*%< urls we manage */
+	isc_httpdaction_t      *render_404;
+};
+
+/*%
+ * HTTP methods.
+ */
+#define ISC_HTTPD_METHODUNKNOWN	0
+#define ISC_HTTPD_METHODGET	1
+#define ISC_HTTPD_METHODPOST	2
+
+/*%
+ * Client states.
+ *
+ * _IDLE	The client is not doing anything at all.  This state should
+ *		only occur just after creation, and just before being
+ *		destroyed.
+ *
+ * _RECV	The client is waiting for data after issuing a socket recv().
+ *
+ * _RECVDONE	Data has been received, and is being processed.
+ *
+ * _SEND	All data for a response has completed, and a reply was
+ *		sent via a socket send() call.
+ *
+ * _SENDDONE	Send is completed.
+ *
+ * Badly formatted state table:
+ *
+ *	IDLE -> RECV when client has a recv() queued.
+ *
+ *	RECV -> RECVDONE when recvdone event received.
+ *
+ *	RECVDONE -> SEND if the data for a reply is at hand.
+ *
+ *	SEND -> RECV when a senddone event was received.
+ *
+ *	At any time -> RECV on error.  If RECV fails, the client will
+ *	self-destroy, closing the socket and freeing memory.
+ */
+#define ISC_HTTPD_STATEIDLE	0
+#define ISC_HTTPD_STATERECV	1
+#define ISC_HTTPD_STATERECVDONE	2
+#define ISC_HTTPD_STATESEND	3
+#define ISC_HTTPD_STATESENDDONE	4
+
+#define ISC_HTTPD_ISRECV(c)	((c)->state == ISC_HTTPD_STATERECV)
+#define ISC_HTTPD_ISRECVDONE(c)	((c)->state == ISC_HTTPD_STATERECVDONE)
+#define ISC_HTTPD_ISSEND(c)	((c)->state == ISC_HTTPD_STATESEND)
+#define ISC_HTTPD_ISSENDDONE(c)	((c)->state == ISC_HTTPD_STATESENDDONE)
+
+/*%
+ * Overall magic test that means we're not idle.
+ */
+#define ISC_HTTPD_SETRECV(c)	((c)->state = ISC_HTTPD_STATERECV)
+#define ISC_HTTPD_SETRECVDONE(c)	((c)->state = ISC_HTTPD_STATERECVDONE)
+#define ISC_HTTPD_SETSEND(c)	((c)->state = ISC_HTTPD_STATESEND)
+#define ISC_HTTPD_SETSENDDONE(c)	((c)->state = ISC_HTTPD_STATESENDDONE)
+
+static void isc_httpd_accept(isc_task_t *, isc_event_t *);
+static void isc_httpd_recvdone(isc_task_t *, isc_event_t *);
+static void isc_httpd_senddone(isc_task_t *, isc_event_t *);
+static void destroy_client(isc_httpd_t **);
+static isc_result_t process_request(isc_httpd_t *, int);
+static void httpdmgr_destroy(isc_httpdmgr_t *);
+static isc_result_t grow_headerspace(isc_httpd_t *);
+static void reset_client(isc_httpd_t *httpd);
+static isc_result_t render_404(const char *, const char *,
+			       void *,
+			       unsigned int *, const char **,
+			       const char **, isc_buffer_t *,
+			       isc_httpdfree_t **, void **);
+
+static void
+destroy_client(isc_httpd_t **httpdp)
+{
+	isc_httpd_t *httpd = *httpdp;
+	isc_httpdmgr_t *httpdmgr = httpd->mgr;
+
+	*httpdp = NULL;
+
+	LOCK(&httpdmgr->lock);
+
+	isc_socket_detach(&httpd->sock);
+	ISC_LIST_UNLINK(httpdmgr->running, httpd, link);
+
+	if (httpd->headerlen > 0)
+		isc_mem_put(httpdmgr->mctx, httpd->headerdata,
+			    httpd->headerlen);
+
+	isc_mem_put(httpdmgr->mctx, httpd, sizeof(isc_httpd_t));
+
+	UNLOCK(&httpdmgr->lock);
+
+	httpdmgr_destroy(httpdmgr);
+}
+
+isc_result_t
+isc_httpdmgr_create(isc_mem_t *mctx, isc_socket_t *sock, isc_task_t *task,
+		    isc_httpdclientok_t *client_ok,
+		    isc_httpdondestroy_t *ondestroy, void *cb_arg,
+		    isc_timermgr_t *tmgr, isc_httpdmgr_t **httpdp)
+{
+	isc_result_t result;
+	isc_httpdmgr_t *httpd;
+
+	REQUIRE(mctx != NULL);
+	REQUIRE(sock != NULL);
+	REQUIRE(task != NULL);
+	REQUIRE(tmgr != NULL);
+	REQUIRE(httpdp != NULL && *httpdp == NULL);
+
+	httpd = isc_mem_get(mctx, sizeof(isc_httpdmgr_t));
+	if (httpd == NULL)
+		return (ISC_R_NOMEMORY);
+
+	result = isc_mutex_init(&httpd->lock);
+	if (result != ISC_R_SUCCESS) {
+		isc_mem_put(mctx, httpd, sizeof(isc_httpdmgr_t));
+		return (result);
+	}
+	httpd->mctx = NULL;
+	isc_mem_attach(mctx, &httpd->mctx);
+	httpd->sock = NULL;
+	isc_socket_attach(sock, &httpd->sock);
+	httpd->task = NULL;
+	isc_task_attach(task, &httpd->task);
+	httpd->timermgr = tmgr; /* XXXMLG no attach function? */
+	httpd->client_ok = client_ok;
+	httpd->ondestroy = ondestroy;
+	httpd->cb_arg = cb_arg;
+
+	ISC_LIST_INIT(httpd->running);
+	ISC_LIST_INIT(httpd->urls);
+
+	/* XXXMLG ignore errors on isc_socket_listen() */
+	result = isc_socket_listen(sock, SOMAXCONN);
+	if (result != ISC_R_SUCCESS) {
+		UNEXPECTED_ERROR(__FILE__, __LINE__,
+				 "isc_socket_listen() failed: %s",
+				 isc_result_totext(result));
+		goto cleanup;
+	}
+
+	(void)isc_socket_filter(sock, "httpready");
+
+	result = isc_socket_accept(sock, task, isc_httpd_accept, httpd);
+	if (result != ISC_R_SUCCESS)
+		goto cleanup;
+
+	httpd->render_404 = render_404;
+
+	*httpdp = httpd;
+	return (ISC_R_SUCCESS);
+
+  cleanup:
+	isc_task_detach(&httpd->task);
+	isc_socket_detach(&httpd->sock);
+	isc_mem_detach(&httpd->mctx);
+	isc_mutex_destroy(&httpd->lock);
+	isc_mem_put(mctx, httpd, sizeof(isc_httpdmgr_t));
+	return (result);
+}
+
+static void
+httpdmgr_destroy(isc_httpdmgr_t *httpdmgr)
+{
+	isc_mem_t *mctx;
+	isc_httpdurl_t *url;
+
+	ENTER("httpdmgr_destroy");
+
+	LOCK(&httpdmgr->lock);
+
+	if (!MSHUTTINGDOWN(httpdmgr)) {
+		NOTICE("httpdmgr_destroy not shutting down yet");
+		UNLOCK(&httpdmgr->lock);
+		return;
+	}
+
+	/*
+	 * If all clients are not shut down, don't do anything yet.
+	 */
+	if (!ISC_LIST_EMPTY(httpdmgr->running)) {
+		NOTICE("httpdmgr_destroy clients still active");
+		UNLOCK(&httpdmgr->lock);
+		return;
+	}
+
+	NOTICE("httpdmgr_destroy detaching socket, task, and timermgr");
+
+	isc_socket_detach(&httpdmgr->sock);
+	isc_task_detach(&httpdmgr->task);
+	httpdmgr->timermgr = NULL;
+
+	/*
+	 * Clear out the list of all actions we know about.  Just free the
+	 * memory.
+	 */
+	url = ISC_LIST_HEAD(httpdmgr->urls);
+	while (url != NULL) {
+		isc_mem_free(httpdmgr->mctx, url->url);
+		ISC_LIST_UNLINK(httpdmgr->urls, url, link);
+		isc_mem_put(httpdmgr->mctx, url, sizeof(isc_httpdurl_t));
+		url = ISC_LIST_HEAD(httpdmgr->urls);
+	}
+
+	UNLOCK(&httpdmgr->lock);
+	isc_mutex_destroy(&httpdmgr->lock);
+
+	if (httpdmgr->ondestroy != NULL)
+		(httpdmgr->ondestroy)(httpdmgr->cb_arg);
+
+	mctx = httpdmgr->mctx;
+	isc_mem_putanddetach(&mctx, httpdmgr, sizeof(isc_httpdmgr_t));
+
+	EXIT("httpdmgr_destroy");
+}
+
+#define LENGTHOK(s) (httpd->recvbuf - (s) < (int)httpd->recvlen)
+#define BUFLENOK(s) (httpd->recvbuf - (s) < HTTP_RECVLEN)
+
+static isc_result_t
+process_request(isc_httpd_t *httpd, int length)
+{
+	char *s;
+	char *p;
+	int delim;
+
+	ENTER("request");
+
+	httpd->recvlen += length;
+
+	httpd->recvbuf[httpd->recvlen] = 0;
+
+	/*
+	 * If we don't find a blank line in our buffer, return that we need
+	 * more data.
+	 */
+	s = strstr(httpd->recvbuf, "\r\n\r\n");
+	delim = 1;
+	if (s == NULL) {
+		s = strstr(httpd->recvbuf, "\n\n");
+		delim = 2;
+	}
+	if (s == NULL)
+		return (ISC_R_NOTFOUND);
+
+	/*
+	 * Determine if this is a POST or GET method.  Any other values will
+	 * cause an error to be returned.
+	 */
+	if (strncmp(httpd->recvbuf, "GET ", 4) == 0) {
+		httpd->method = ISC_HTTPD_METHODGET;
+		p = httpd->recvbuf + 4;
+	} else if (strncmp(httpd->recvbuf, "POST ", 5) == 0) {
+		httpd->method = ISC_HTTPD_METHODPOST;
+		p = httpd->recvbuf + 5;
+	} else {
+		return (ISC_R_RANGE);
+	}
+
+	/*
+	 * From now on, p is the start of our buffer.
+	 */
+
+	/*
+	 * Extract the URL.
+	 */
+	s = p;
+	while (LENGTHOK(s) && BUFLENOK(s) &&
+	       (*s != '\n' && *s != '\r' && *s != '\0' && *s != ' '))
+		s++;
+	if (!LENGTHOK(s))
+		return (ISC_R_NOTFOUND);
+	if (!BUFLENOK(s))
+		return (ISC_R_NOMEMORY);
+	*s = 0;
+
+	/*
+	 * Make the URL relative.
+	 */
+	if ((strncmp(p, "http:/", 6) == 0)
+	    || (strncmp(p, "https:/", 7) == 0)) {
+		/* Skip first / */
+		while (*p != '/' && *p != 0)
+			p++;
+		if (*p == 0)
+			return (ISC_R_RANGE);
+		p++;
+		/* Skip second / */
+		while (*p != '/' && *p != 0)
+			p++;
+		if (*p == 0)
+			return (ISC_R_RANGE);
+		p++;
+		/* Find third / */
+		while (*p != '/' && *p != 0)
+			p++;
+		if (*p == 0) {
+			p--;
+			*p = '/';
+		}
+	}
+
+	httpd->url = p;
+	p = s + delim;
+	s = p;
+
+	/*
+	 * Now, see if there is a ? mark in the URL.  If so, this is
+	 * part of the query string, and we will split it from the URL.
+	 */
+	httpd->querystring = strchr(httpd->url, '?');
+	if (httpd->querystring != NULL) {
+		*(httpd->querystring) = 0;
+		httpd->querystring++;
+	}
+
+	/*
+	 * Extract the HTTP/1.X protocol.  We will bounce on anything but
+	 * HTTP/1.1 for now.
+	 */
+	while (LENGTHOK(s) && BUFLENOK(s) &&
+	       (*s != '\n' && *s != '\r' && *s != '\0'))
+		s++;
+	if (!LENGTHOK(s))
+		return (ISC_R_NOTFOUND);
+	if (!BUFLENOK(s))
+		return (ISC_R_NOMEMORY);
+	*s = 0;
+	if ((strncmp(p, "HTTP/1.0", 8) != 0)
+	    && (strncmp(p, "HTTP/1.1", 8) != 0))
+		return (ISC_R_RANGE);
+	httpd->protocol = p;
+	p = s + 1;
+	s = p;
+
+	if (strstr(s, "Connection: close") != NULL)
+		httpd->flags |= HTTPD_CLOSE;
+
+	if (strstr(s, "Host: ") != NULL)
+		httpd->flags |= HTTPD_FOUNDHOST;
+
+	/*
+	 * Standards compliance hooks here.
+	 */
+	if (strcmp(httpd->protocol, "HTTP/1.1") == 0
+	    && ((httpd->flags & HTTPD_FOUNDHOST) == 0))
+		return (ISC_R_RANGE);
+
+	EXIT("request");
+
+	return (ISC_R_SUCCESS);
+}
+
+static void
+isc_httpd_accept(isc_task_t *task, isc_event_t *ev)
+{
+	isc_result_t result;
+	isc_httpdmgr_t *httpdmgr = ev->ev_arg;
+	isc_httpd_t *httpd;
+	isc_region_t r;
+	isc_socket_newconnev_t *nev = (isc_socket_newconnev_t *)ev;
+	isc_sockaddr_t peeraddr;
+
+	ENTER("accept");
+
+	LOCK(&httpdmgr->lock);
+	if (MSHUTTINGDOWN(httpdmgr)) {
+		NOTICE("accept shutting down, goto out");
+		goto out;
+	}
+
+	if (nev->result == ISC_R_CANCELED) {
+		NOTICE("accept canceled, goto out");
+		goto out;
+	}
+
+	if (nev->result != ISC_R_SUCCESS) {
+		/* XXXMLG log failure */
+		NOTICE("accept returned failure, goto requeue");
+		goto requeue;
+	}
+
+	(void)isc_socket_getpeername(nev->newsocket, &peeraddr);
+	if (httpdmgr->client_ok != NULL &&
+	    !(httpdmgr->client_ok)(&peeraddr, httpdmgr->cb_arg)) {
+		isc_socket_detach(&nev->newsocket);
+		goto requeue;
+	}
+
+	httpd = isc_mem_get(httpdmgr->mctx, sizeof(isc_httpd_t));
+	if (httpd == NULL) {
+		/* XXXMLG log failure */
+		NOTICE("accept failed to allocate memory, goto requeue");
+		isc_socket_detach(&nev->newsocket);
+		goto requeue;
+	}
+
+	httpd->mgr = httpdmgr;
+	ISC_LINK_INIT(httpd, link);
+	ISC_LIST_APPEND(httpdmgr->running, httpd, link);
+	ISC_HTTPD_SETRECV(httpd);
+	httpd->sock = nev->newsocket;
+	isc_socket_setname(httpd->sock, "httpd", NULL);
+	httpd->flags = 0;
+
+	/*
+	 * Initialize the buffer for our headers.
+	 */
+	httpd->headerdata = isc_mem_get(httpdmgr->mctx, HTTP_SENDGROW);
+	if (httpd->headerdata == NULL) {
+		isc_mem_put(httpdmgr->mctx, httpd, sizeof(isc_httpd_t));
+		isc_socket_detach(&nev->newsocket);
+		goto requeue;
+	}
+	httpd->headerlen = HTTP_SENDGROW;
+	isc_buffer_init(&httpd->headerbuffer, httpd->headerdata,
+			httpd->headerlen);
+
+	ISC_LIST_INIT(httpd->bufflist);
+
+	isc_buffer_initnull(&httpd->bodybuffer);
+	reset_client(httpd);
+
+	r.base = (unsigned char *)httpd->recvbuf;
+	r.length = HTTP_RECVLEN - 1;
+	result = isc_socket_recv(httpd->sock, &r, 1, task, isc_httpd_recvdone,
+				 httpd);
+	NOTICE("accept queued recv on socket");
+
+ requeue:
+	result = isc_socket_accept(httpdmgr->sock, task, isc_httpd_accept,
+				   httpdmgr);
+	if (result != ISC_R_SUCCESS) {
+		/* XXXMLG what to do?  Log failure... */
+		NOTICE("accept could not reaccept due to failure");
+	}
+
+ out:
+	UNLOCK(&httpdmgr->lock);
+
+	httpdmgr_destroy(httpdmgr);
+
+	isc_event_free(&ev);
+
+	EXIT("accept");
+}
+
+static isc_result_t
+render_404(const char *url, const char *querystring,
+	   void *arg,
+	   unsigned int *retcode, const char **retmsg,
+	   const char **mimetype, isc_buffer_t *b,
+	   isc_httpdfree_t **freecb, void **freecb_args)
+{
+	static char msg[] = "No such URL.";
+
+	UNUSED(url);
+	UNUSED(querystring);
+	UNUSED(arg);
+
+	*retcode = 404;
+	*retmsg = "No such URL";
+	*mimetype = "text/plain";
+	isc_buffer_reinit(b, msg, strlen(msg));
+	isc_buffer_add(b, strlen(msg));
+	*freecb = NULL;
+	*freecb_args = NULL;
+
+	return (ISC_R_SUCCESS);
+}
+
+static void
+isc_httpd_recvdone(isc_task_t *task, isc_event_t *ev)
+{
+	isc_region_t r;
+	isc_result_t result;
+	isc_httpd_t *httpd = ev->ev_arg;
+	isc_socketevent_t *sev = (isc_socketevent_t *)ev;
+	isc_httpdurl_t *url;
+	isc_time_t now;
+	char datebuf[32];  /* Only need 30, but safety first */
+
+	ENTER("recv");
+
+	INSIST(ISC_HTTPD_ISRECV(httpd));
+
+	if (sev->result != ISC_R_SUCCESS) {
+		NOTICE("recv destroying client");
+		destroy_client(&httpd);
+		goto out;
+	}
+
+	result = process_request(httpd, sev->n);
+	if (result == ISC_R_NOTFOUND) {
+		if (httpd->recvlen >= HTTP_RECVLEN - 1) {
+			destroy_client(&httpd);
+			goto out;
+		}
+		r.base = (unsigned char *)httpd->recvbuf + httpd->recvlen;
+		r.length = HTTP_RECVLEN - httpd->recvlen - 1;
+		result = isc_socket_recv(httpd->sock, &r, 1, task,
+					 isc_httpd_recvdone, httpd);
+		goto out;
+	} else if (result != ISC_R_SUCCESS) {
+		destroy_client(&httpd);
+		goto out;
+	}
+
+	ISC_HTTPD_SETSEND(httpd);
+
+	/*
+	 * XXXMLG Call function here.  Provide an add-header function
+	 * which will append the common headers to a response we generate.
+	 */
+	isc_buffer_initnull(&httpd->bodybuffer);
+	isc_time_now(&now);
+	isc_time_formathttptimestamp(&now, datebuf, sizeof(datebuf));
+	url = ISC_LIST_HEAD(httpd->mgr->urls);
+	while (url != NULL) {
+		if (strcmp(httpd->url, url->url) == 0)
+			break;
+		url = ISC_LIST_NEXT(url, link);
+	}
+	if (url == NULL)
+		result = httpd->mgr->render_404(httpd->url, httpd->querystring,
+						NULL,
+						&httpd->retcode,
+						&httpd->retmsg,
+						&httpd->mimetype,
+						&httpd->bodybuffer,
+						&httpd->freecb,
+						&httpd->freecb_arg);
+	else
+		result = url->action(httpd->url, httpd->querystring,
+				     url->action_arg,
+				     &httpd->retcode, &httpd->retmsg,
+				     &httpd->mimetype, &httpd->bodybuffer,
+				     &httpd->freecb, &httpd->freecb_arg);
+	if (result != ISC_R_SUCCESS) {
+		destroy_client(&httpd);
+		goto out;
+	}
+
+	isc_httpd_response(httpd);
+	isc_httpd_addheader(httpd, "Content-Type", httpd->mimetype);
+	isc_httpd_addheader(httpd, "Date", datebuf);
+	isc_httpd_addheader(httpd, "Expires", datebuf);
+	isc_httpd_addheader(httpd, "Last-Modified", datebuf);
+	isc_httpd_addheader(httpd, "Pragma: no-cache", NULL);
+	isc_httpd_addheader(httpd, "Cache-Control: no-cache", NULL);
+	isc_httpd_addheader(httpd, "Server: libisc", NULL);
+	isc_httpd_addheaderuint(httpd, "Content-Length",
+				isc_buffer_usedlength(&httpd->bodybuffer));
+	isc_httpd_endheaders(httpd);  /* done */
+
+	ISC_LIST_APPEND(httpd->bufflist, &httpd->headerbuffer, link);
+	/*
+	 * Link the data buffer into our send queue, should we have any data
+	 * rendered into it.  If no data is present, we won't do anything
+	 * with the buffer.
+	 */
+	if (isc_buffer_length(&httpd->bodybuffer) > 0)
+		ISC_LIST_APPEND(httpd->bufflist, &httpd->bodybuffer, link);
+
+	result = isc_socket_sendv(httpd->sock, &httpd->bufflist, task,
+				  isc_httpd_senddone, httpd);
+
+ out:
+	isc_event_free(&ev);
+	EXIT("recv");
+}
+
+void
+isc_httpdmgr_shutdown(isc_httpdmgr_t **httpdmgrp)
+{
+	isc_httpdmgr_t *httpdmgr;
+	isc_httpd_t *httpd;
+	httpdmgr = *httpdmgrp;
+	*httpdmgrp = NULL;
+
+	ENTER("isc_httpdmgr_shutdown");
+
+	LOCK(&httpdmgr->lock);
+
+	MSETSHUTTINGDOWN(httpdmgr);
+
+	isc_socket_cancel(httpdmgr->sock, httpdmgr->task, ISC_SOCKCANCEL_ALL);
+
+	httpd = ISC_LIST_HEAD(httpdmgr->running);
+	while (httpd != NULL) {
+		isc_socket_cancel(httpd->sock, httpdmgr->task,
+				  ISC_SOCKCANCEL_ALL);
+		httpd = ISC_LIST_NEXT(httpd, link);
+	}
+
+	UNLOCK(&httpdmgr->lock);
+
+	EXIT("isc_httpdmgr_shutdown");
+}
+
+static isc_result_t
+grow_headerspace(isc_httpd_t *httpd)
+{
+	char *newspace;
+	unsigned int newlen;
+	isc_region_t r;
+
+	newlen = httpd->headerlen + HTTP_SENDGROW;
+	if (newlen > HTTP_SEND_MAXLEN)
+		return (ISC_R_NOSPACE);
+
+	newspace = isc_mem_get(httpd->mgr->mctx, newlen);
+	if (newspace == NULL)
+		return (ISC_R_NOMEMORY);
+	isc_buffer_region(&httpd->headerbuffer, &r);
+	isc_buffer_reinit(&httpd->headerbuffer, newspace, newlen);
+
+	isc_mem_put(httpd->mgr->mctx, r.base, r.length);
+
+	return (ISC_R_SUCCESS);
+}
+
+isc_result_t
+isc_httpd_response(isc_httpd_t *httpd)
+{
+	isc_result_t result;
+	unsigned int needlen;
+
+	needlen = strlen(httpd->protocol) + 1; /* protocol + space */
+	needlen += 3 + 1;  /* room for response code, always 3 bytes */
+	needlen += strlen(httpd->retmsg) + 2;  /* return msg + CRLF */
+
+	if (isc_buffer_availablelength(&httpd->headerbuffer) < needlen) {
+		result = grow_headerspace(httpd);
+		if (result != ISC_R_SUCCESS)
+			return (result);
+	}
+
+	sprintf(isc_buffer_used(&httpd->headerbuffer), "%s %03d %s\r\n",
+		httpd->protocol, httpd->retcode, httpd->retmsg);
+	isc_buffer_add(&httpd->headerbuffer, needlen);
+
+	return (ISC_R_SUCCESS);
+}
+
+isc_result_t
+isc_httpd_addheader(isc_httpd_t *httpd, const char *name,
+		    const char *val)
+{
+	isc_result_t result;
+	unsigned int needlen;
+
+	needlen = strlen(name); /* name itself */
+	if (val != NULL)
+		needlen += 2 + strlen(val); /* :<space> and val */
+	needlen += 2; /* CRLF */
+
+	if (isc_buffer_availablelength(&httpd->headerbuffer) < needlen) {
+		result = grow_headerspace(httpd);
+		if (result != ISC_R_SUCCESS)
+			return (result);
+	}
+
+	if (val != NULL)
+		sprintf(isc_buffer_used(&httpd->headerbuffer),
+			"%s: %s\r\n", name, val);
+	else
+		sprintf(isc_buffer_used(&httpd->headerbuffer),
+			"%s\r\n", name);
+
+	isc_buffer_add(&httpd->headerbuffer, needlen);
+
+	return (ISC_R_SUCCESS);
+}
+
+isc_result_t
+isc_httpd_endheaders(isc_httpd_t *httpd)
+{
+	isc_result_t result;
+
+	if (isc_buffer_availablelength(&httpd->headerbuffer) < 2) {
+		result = grow_headerspace(httpd);
+		if (result != ISC_R_SUCCESS)
+			return (result);
+	}
+
+	sprintf(isc_buffer_used(&httpd->headerbuffer), "\r\n");
+	isc_buffer_add(&httpd->headerbuffer, 2);
+
+	return (ISC_R_SUCCESS);
+}
+
+isc_result_t
+isc_httpd_addheaderuint(isc_httpd_t *httpd, const char *name, int val) {
+	isc_result_t result;
+	unsigned int needlen;
+	char buf[sizeof "18446744073709551616"];
+
+	sprintf(buf, "%d", val);
+
+	needlen = strlen(name); /* name itself */
+	needlen += 2 + strlen(buf); /* :<space> and val */
+	needlen += 2; /* CRLF */
+
+	if (isc_buffer_availablelength(&httpd->headerbuffer) < needlen) {
+		result = grow_headerspace(httpd);
+		if (result != ISC_R_SUCCESS)
+			return (result);
+	}
+
+	sprintf(isc_buffer_used(&httpd->headerbuffer),
+		"%s: %s\r\n", name, buf);
+
+	isc_buffer_add(&httpd->headerbuffer, needlen);
+
+	return (ISC_R_SUCCESS);
+}
+
+static void
+isc_httpd_senddone(isc_task_t *task, isc_event_t *ev)
+{
+	isc_httpd_t *httpd = ev->ev_arg;
+	isc_region_t r;
+	isc_result_t result;
+	isc_socketevent_t *sev = (isc_socketevent_t *)ev;
+
+	ENTER("senddone");
+	INSIST(ISC_HTTPD_ISSEND(httpd));
+
+	/*
+	 * First, unlink our header buffer from the socket's bufflist.  This
+	 * is sort of an evil hack, since we know our buffer will be there,
+	 * and we know it's address, so we can just remove it directly.
+	 */
+	NOTICE("senddone unlinked header");
+	ISC_LIST_UNLINK(sev->bufferlist, &httpd->headerbuffer, link);
+
+	/*
+	 * We will always want to clean up our receive buffer, even if we
+	 * got an error on send or we are shutting down.
+	 *
+	 * We will pass in the buffer only if there is data in it.  If
+	 * there is no data, we will pass in a NULL.
+	 */
+	if (httpd->freecb != NULL) {
+		isc_buffer_t *b = NULL;
+		if (isc_buffer_length(&httpd->bodybuffer) > 0)
+			b = &httpd->bodybuffer;
+		httpd->freecb(b, httpd->freecb_arg);
+		NOTICE("senddone free callback performed");
+	}
+	if (ISC_LINK_LINKED(&httpd->bodybuffer, link)) {
+		ISC_LIST_UNLINK(sev->bufferlist, &httpd->bodybuffer, link);
+		NOTICE("senddone body buffer unlinked");
+	}
+
+	if (sev->result != ISC_R_SUCCESS) {
+		destroy_client(&httpd);
+		goto out;
+	}
+
+	if ((httpd->flags & HTTPD_CLOSE) != 0) {
+		destroy_client(&httpd);
+		goto out;
+	}
+
+	ISC_HTTPD_SETRECV(httpd);
+
+	NOTICE("senddone restarting recv on socket");
+
+	reset_client(httpd);
+
+	r.base = (unsigned char *)httpd->recvbuf;
+	r.length = HTTP_RECVLEN - 1;
+	result = isc_socket_recv(httpd->sock, &r, 1, task, isc_httpd_recvdone,
+				 httpd);
+
+out:
+	isc_event_free(&ev);
+	EXIT("senddone");
+}
+
+static void
+reset_client(isc_httpd_t *httpd)
+{
+	/*
+	 * Catch errors here.  We MUST be in RECV mode, and we MUST NOT have
+	 * any outstanding buffers.  If we have buffers, we have a leak.
+	 */
+	INSIST(ISC_HTTPD_ISRECV(httpd));
+	INSIST(!ISC_LINK_LINKED(&httpd->headerbuffer, link));
+	INSIST(!ISC_LINK_LINKED(&httpd->bodybuffer, link));
+
+	httpd->recvbuf[0] = 0;
+	httpd->recvlen = 0;
+	httpd->method = ISC_HTTPD_METHODUNKNOWN;
+	httpd->url = NULL;
+	httpd->querystring = NULL;
+	httpd->protocol = NULL;
+	httpd->flags = 0;
+
+	isc_buffer_clear(&httpd->headerbuffer);
+	isc_buffer_invalidate(&httpd->bodybuffer);
+}
+
+isc_result_t
+isc_httpdmgr_addurl(isc_httpdmgr_t *httpdmgr, const char *url,
+		    isc_httpdaction_t *func, void *arg)
+{
+	isc_httpdurl_t *item;
+
+	if (url == NULL) {
+		httpdmgr->render_404 = func;
+		return (ISC_R_SUCCESS);
+	}
+
+	item = isc_mem_get(httpdmgr->mctx, sizeof(isc_httpdurl_t));
+	if (item == NULL)
+		return (ISC_R_NOMEMORY);
+
+	item->url = isc_mem_strdup(httpdmgr->mctx, url);
+	if (item->url == NULL) {
+		isc_mem_put(httpdmgr->mctx, item, sizeof(isc_httpdurl_t));
+		return (ISC_R_NOMEMORY);
+	}
+
+	item->action = func;
+	item->action_arg = arg;
+	ISC_LINK_INIT(item, link);
+	ISC_LIST_APPEND(httpdmgr->urls, item, link);
+
+	return (ISC_R_SUCCESS);
+}
diff --git a/contrib/bind9/lib/isc/ia64/Makefile.in b/contrib/bind9/lib/isc/ia64/Makefile.in
index c8e77e4..324db07 100644
--- a/contrib/bind9/lib/isc/ia64/Makefile.in
+++ b/contrib/bind9/lib/isc/ia64/Makefile.in
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.2.2.1 2007/09/14 04:26:38 marka Exp $
+# $Id: Makefile.in,v 1.2 2007/09/14 04:09:59 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/ia64/include/Makefile.in b/contrib/bind9/lib/isc/ia64/include/Makefile.in
index f4dd2f6..f1d8bdd 100644
--- a/contrib/bind9/lib/isc/ia64/include/Makefile.in
+++ b/contrib/bind9/lib/isc/ia64/include/Makefile.in
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.2.2.1 2007/09/14 04:26:38 marka Exp $
+# $Id: Makefile.in,v 1.2 2007/09/14 04:09:59 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/ia64/include/isc/Makefile.in b/contrib/bind9/lib/isc/ia64/include/isc/Makefile.in
index 6760ce6..5f116ca 100644
--- a/contrib/bind9/lib/isc/ia64/include/isc/Makefile.in
+++ b/contrib/bind9/lib/isc/ia64/include/isc/Makefile.in
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.2.2.1 2007/09/14 04:26:38 marka Exp $
+# $Id: Makefile.in,v 1.2 2007/09/14 04:09:59 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/ia64/include/isc/atomic.h b/contrib/bind9/lib/isc/ia64/include/isc/atomic.h
index 20cbabd..4c46797 100644
--- a/contrib/bind9/lib/isc/ia64/include/isc/atomic.h
+++ b/contrib/bind9/lib/isc/ia64/include/isc/atomic.h
@@ -1,7 +1,7 @@
 /*
- * Copyright (C) 2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2006, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: atomic.h,v 1.2.2.1 2006/06/21 03:38:32 marka Exp $ */
+/* $Id: atomic.h,v 1.4.326.2 2009/02/06 23:47:11 tbox Exp $ */
 
 #ifndef ISC_ATOMIC_H
 #define ISC_ATOMIC_H 1
@@ -31,7 +31,11 @@
  * (e.g., 1 and -1)?
  */
 static inline isc_int32_t
-isc_atomic_xadd(isc_int32_t *p, isc_int32_t val) {
+isc_atomic_xadd(isc_int32_t *p, isc_int32_t val)
+#ifdef __GNUC__
+__attribute__ ((unused))
+#endif
+{
 	isc_int32_t prev, swapped;
 
 	for (prev = *(volatile isc_int32_t *)p; ; prev = swapped) {
@@ -53,7 +57,11 @@ isc_atomic_xadd(isc_int32_t *p, isc_int32_t val) {
  * This routine atomically stores the value 'val' in 'p'.
  */
 static inline void
-isc_atomic_store(isc_int32_t *p, isc_int32_t val) {
+isc_atomic_store(isc_int32_t *p, isc_int32_t val)
+#ifdef __GNUC__
+__attribute__ ((unused))
+#endif
+{
 	__asm__ volatile(
 		"st4.rel %0=%1"
 		: "=m" (*p)
@@ -68,7 +76,11 @@ isc_atomic_store(isc_int32_t *p, isc_int32_t val) {
  * case.
  */
 static inline isc_int32_t
-isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, isc_int32_t val) {
+isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, isc_int32_t val)
+#ifdef __GNUC__
+__attribute__ ((unused))
+#endif
+{
 	isc_int32_t ret;
 
 	__asm__ volatile(
diff --git a/contrib/bind9/lib/isc/include/Makefile.in b/contrib/bind9/lib/isc/include/Makefile.in
index ceb8eb6..04778d7 100644
--- a/contrib/bind9/lib/isc/include/Makefile.in
+++ b/contrib/bind9/lib/isc/include/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1998-2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.11 2004/03/05 05:10:53 marka Exp $
+# $Id: Makefile.in,v 1.13 2007/06/19 23:47:18 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/include/isc/Makefile.in b/contrib/bind9/lib/isc/include/isc/Makefile.in
index 0f0e936..def1180 100644
--- a/contrib/bind9/lib/isc/include/isc/Makefile.in
+++ b/contrib/bind9/lib/isc/include/isc/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1998-2001, 2003  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.54.18.4 2006/01/27 23:57:45 marka Exp $
+# $Id: Makefile.in,v 1.64.12.2 2009/02/12 23:47:22 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
@@ -30,14 +30,18 @@ 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 \
 		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 \
+		httpd.h \
+		interfaceiter.h @ISC_IPV6_H@ iterated_hash.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 \
-		print.h quota.h random.h ratelimiter.h \
+		print.h quota.h radix.h random.h ratelimiter.h \
 		refcount.h region.h resource.h \
 		result.h resultclass.h rwlock.h serial.h sha1.h sha2.h \
-		sockaddr.h socket.h stdio.h stdlib.h string.h symtab.h \
-	        task.h taskpool.h timer.h types.h util.h version.h
+		sockaddr.h socket.h stdio.h stdlib.h string.h \
+		symtab.h \
+	        task.h taskpool.h timer.h types.h util.h version.h \
+		xml.h
 
 SUBDIRS =
 TARGETS =
diff --git a/contrib/bind9/lib/isc/include/isc/app.h b/contrib/bind9/lib/isc/include/isc/app.h
index f51aff7..c4d54cb 100644
--- a/contrib/bind9/lib/isc/include/isc/app.h
+++ b/contrib/bind9/lib/isc/include/isc/app.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: app.h,v 1.2.18.2 2005/04/29 00:16:52 marka Exp $ */
+/* $Id: app.h,v 1.8 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_APP_H
 #define ISC_APP_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file isc/app.h
  * \brief ISC Application Support
  *
  * Dealing with program termination can be difficult, especially in a
diff --git a/contrib/bind9/lib/isc/include/isc/assertions.h b/contrib/bind9/lib/isc/include/isc/assertions.h
index fcf0eb8..b031152 100644
--- a/contrib/bind9/lib/isc/include/isc/assertions.h
+++ b/contrib/bind9/lib/isc/include/isc/assertions.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1997-2001  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -16,9 +16,9 @@
  */
 
 /*
- * $Id: assertions.h,v 1.18.18.4 2008/10/15 23:46:06 tbox Exp $
+ * $Id: assertions.h,v 1.26 2008/10/15 23:47:31 tbox Exp $
  */
-/*! \file assertions.h
+/*! \file isc/assertions.h
  */
 
 #ifndef ISC_ASSERTIONS_H
diff --git a/contrib/bind9/lib/isc/include/isc/base32.h b/contrib/bind9/lib/isc/include/isc/base32.h
new file mode 100644
index 0000000..978a8db
--- /dev/null
+++ b/contrib/bind9/lib/isc/include/isc/base32.h
@@ -0,0 +1,128 @@
+/*
+ * Copyright (C) 2008  Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or 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: base32.h,v 1.3 2008/09/25 04:02:39 tbox Exp $ */
+
+#ifndef ISC_BASE32_H
+#define ISC_BASE32_H 1
+
+/*! \file */
+
+/*
+ * Routines for manipulating base 32 and base 32 hex encoded data.
+ * Based on RFC 4648.
+ *
+ * Base 32 hex preserves the sort order of data when it is encoded /
+ * decoded.
+ */
+
+#include <isc/lang.h>
+#include <isc/types.h>
+
+ISC_LANG_BEGINDECLS
+
+/***
+ *** Functions
+ ***/
+
+isc_result_t
+isc_base32_totext(isc_region_t *source, int wordlength,
+		  const char *wordbreak, isc_buffer_t *target);
+isc_result_t
+isc_base32hex_totext(isc_region_t *source, int wordlength,
+		     const char *wordbreak, isc_buffer_t *target);
+/*!<
+ * \brief Convert data into base32 encoded text.
+ *
+ * Notes:
+ *\li	The base32 encoded text in 'target' will be divided into
+ *	words of at most 'wordlength' characters, separated by
+ * 	the 'wordbreak' string.  No parentheses will surround
+ *	the text.
+ *
+ * Requires:
+ *\li	'source' is a region containing binary data
+ *\li	'target' is a text buffer containing available space
+ *\li	'wordbreak' points to a null-terminated string of
+ *		zero or more whitespace characters
+ *
+ * Ensures:
+ *\li	target will contain the base32 encoded version of the data
+ *	in source.  The 'used' pointer in target will be advanced as
+ *	necessary.
+ */
+
+isc_result_t
+isc_base32_decodestring(const char *cstr, isc_buffer_t *target);
+isc_result_t
+isc_base32hex_decodestring(const char *cstr, isc_buffer_t *target);
+/*!<
+ * \brief Decode a null-terminated base32 string.
+ *
+ * Requires:
+ *\li	'cstr' is non-null.
+ *\li	'target' is a valid buffer.
+ *
+ * Returns:
+ *\li	#ISC_R_SUCCESS	-- the entire decoded representation of 'cstring'
+ *			   fit in 'target'.
+ *\li	#ISC_R_BADBASE32 -- 'cstr' is not a valid base32 encoding.
+ *
+ * 	Other error returns are any possible error code from:
+ *\li		isc_lex_create(),
+ *\li		isc_lex_openbuffer(),
+ *\li		isc_base32_tobuffer().
+ */
+
+isc_result_t
+isc_base32_tobuffer(isc_lex_t *lexer, isc_buffer_t *target, int length);
+isc_result_t
+isc_base32hex_tobuffer(isc_lex_t *lexer, isc_buffer_t *target, int length);
+/*!<
+ * \brief Convert base32 encoded text from a lexer context into data.
+ *
+ * Requires:
+ *\li	'lex' is a valid lexer context
+ *\li	'target' is a buffer containing binary data
+ *\li	'length' is an integer
+ *
+ * Ensures:
+ *\li	target will contain the data represented by the base32 encoded
+ *	string parsed by the lexer.  No more than length bytes will be read,
+ *	if length is positive.  The 'used' pointer in target will be
+ *	advanced as necessary.
+ */
+
+isc_result_t
+isc_base32_decoderegion(isc_region_t *source, isc_buffer_t *target);
+isc_result_t
+isc_base32hex_decoderegion(isc_region_t *source, isc_buffer_t *target);
+/*!<
+ * \brief Decode a packed (no white space permitted) base32 region.
+ *
+ * Requires:
+ *\li   'source' is a valid region.
+ *\li   'target' is a valid buffer.
+ *
+ * Returns:
+ *\li   #ISC_R_SUCCESS  -- the entire decoded representation of 'cstring'
+ *                         fit in 'target'.
+ *\li   #ISC_R_BADBASE32 -- 'source' is not a valid base32 encoding.
+ */
+
+ISC_LANG_ENDDECLS
+
+#endif /* ISC_BASE32_H */
diff --git a/contrib/bind9/lib/isc/include/isc/base64.h b/contrib/bind9/lib/isc/include/isc/base64.h
index 26ffa48..e48ef2a 100644
--- a/contrib/bind9/lib/isc/include/isc/base64.h
+++ b/contrib/bind9/lib/isc/include/isc/base64.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: base64.h,v 1.16.18.2 2005/04/29 00:16:53 marka Exp $ */
+/* $Id: base64.h,v 1.22 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_BASE64_H
 #define ISC_BASE64_H 1
 
-/*! \file */
+/*! \file isc/base64.h */
 
 #include <isc/lang.h>
 #include <isc/types.h>
diff --git a/contrib/bind9/lib/isc/include/isc/bitstring.h b/contrib/bind9/lib/isc/include/isc/bitstring.h
index 3e626b8..252d111 100644
--- a/contrib/bind9/lib/isc/include/isc/bitstring.h
+++ b/contrib/bind9/lib/isc/include/isc/bitstring.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: bitstring.h,v 1.8.18.2 2005/04/29 00:16:53 marka Exp $ */
+/* $Id: bitstring.h,v 1.14 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_BITSTRING_H
 #define ISC_BITSTRING_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file bitstring.h
+/*! \file isc/bitstring.h
  *
  * \brief Bitstring manipulation functions.
  *
diff --git a/contrib/bind9/lib/isc/include/isc/boolean.h b/contrib/bind9/lib/isc/include/isc/boolean.h
index ad736fe..348b096 100644
--- a/contrib/bind9/lib/isc/include/isc/boolean.h
+++ b/contrib/bind9/lib/isc/include/isc/boolean.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: boolean.h,v 1.13.18.2 2005/04/29 00:16:53 marka Exp $ */
+/* $Id: boolean.h,v 1.19 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_BOOLEAN_H
 #define ISC_BOOLEAN_H 1
 
-/*! \file */
+/*! \file isc/boolean.h */
 
 typedef enum { isc_boolean_false = 0, isc_boolean_true = 1 } isc_boolean_t;
 
diff --git a/contrib/bind9/lib/isc/include/isc/buffer.h b/contrib/bind9/lib/isc/include/isc/buffer.h
index a285e27..2a02d88 100644
--- a/contrib/bind9/lib/isc/include/isc/buffer.h
+++ b/contrib/bind9/lib/isc/include/isc/buffer.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: buffer.h,v 1.43.18.2 2005/04/29 00:16:53 marka Exp $ */
+/* $Id: buffer.h,v 1.53 2008/09/25 04:02:39 tbox Exp $ */
 
 #ifndef ISC_BUFFER_H
 #define ISC_BUFFER_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file buffer.h
+/*! \file isc/buffer.h
  *
  * \brief A buffer is a region of memory, together with a set of related subregions.
  * Buffers are used for parsing and I/O operations.
@@ -112,7 +112,7 @@
 #include <isc/types.h>
 
 /*!
- * To make many functions be inline macros (via #define) define this.
+ * To make many functions be inline macros (via \#define) define this.
  * If it is undefined, a function will be used.
  */
 /* #define ISC_BUFFER_USEINLINE */
@@ -168,13 +168,13 @@ ISC_LANG_BEGINDECLS
 struct isc_buffer {
 	unsigned int		magic;
 	void		       *base;
-        /*@{*/
+	/*@{*/
 	/*! The following integers are byte offsets from 'base'. */
 	unsigned int		length;
 	unsigned int		used;
 	unsigned int 		current;
 	unsigned int 		active;
-        /*@}*/
+	/*@}*/
 	/*! linkable */
 	ISC_LINK(isc_buffer_t)	link;
 	/*! private internal elements */
@@ -235,6 +235,26 @@ isc__buffer_init(isc_buffer_t *b, const void *base, unsigned int length);
  */
 
 void
+isc__buffer_initnull(isc_buffer_t *b);
+/*!<
+ *\brief Initialize a buffer 'b' with a null data and zero length/
+ */
+
+void
+isc_buffer_reinit(isc_buffer_t *b, void *base, unsigned int length);
+/*!<
+ * \brief Make 'b' refer to the 'length'-byte region starting at base.
+ * Any existing data will be copied.
+ *
+ * Requires:
+ *
+ *\li	'length' > 0 AND length >= previous length
+ *
+ *\li	'base' is a pointer to a sequence of 'length' bytes.
+ *
+ */
+
+void
 isc__buffer_invalidate(isc_buffer_t *b);
 /*!<
  * \brief Make 'b' an invalid buffer.
@@ -539,6 +559,57 @@ isc__buffer_putuint32(isc_buffer_t *b, isc_uint32_t val);
  *\li	The used pointer in 'b' is advanced by 4.
  */
 
+isc_uint64_t
+isc_buffer_getuint48(isc_buffer_t *b);
+/*!<
+ * \brief Read an unsigned 48-bit integer in network byte order from 'b',
+ * convert it to host byte order, and return it.
+ *
+ * Requires:
+ *
+ *\li	'b' is a valid buffer.
+ *
+ *\li	The length of the available region of 'b' is at least 6.
+ *
+ * Ensures:
+ *
+ *\li	The current pointer in 'b' is advanced by 6.
+ *
+ * Returns:
+ *
+ *\li	A 48-bit unsigned integer (stored in a 64-bit integer).
+ */
+
+void
+isc__buffer_putuint48(isc_buffer_t *b, isc_uint64_t val);
+/*!<
+ * \brief Store an unsigned 48-bit integer in host byte order from 'val'
+ * into 'b' in network byte order.
+ *
+ * Requires:
+ *\li	'b' is a valid buffer.
+ *
+ *\li	The length of the unused region of 'b' is at least 6.
+ *
+ * Ensures:
+ *\li	The used pointer in 'b' is advanced by 6.
+ */
+
+void
+isc__buffer_putuint24(isc_buffer_t *b, isc_uint32_t val);
+/*!<
+ * Store an unsigned 24-bit integer in host byte order from 'val'
+ * into 'b' in network byte order.
+ *
+ * Requires:
+ *\li	'b' is a valid buffer.
+ *
+ *	The length of the unused region of 'b' is at least 3.
+ *
+ * Ensures:
+ *\li	The used pointer in 'b' is advanced by 3.
+ */
+
 void
 isc__buffer_putmem(isc_buffer_t *b, const unsigned char *base,
 		   unsigned int length);
@@ -625,6 +696,8 @@ ISC_LANG_ENDDECLS
 		(_b)->magic = ISC_BUFFER_MAGIC; \
 	} while (0)
 
+#define ISC__BUFFER_INITNULL(_b) ISC__BUFFER_INIT(_b, NULL, 0)
+
 #define ISC__BUFFER_INVALIDATE(_b) \
 	do { \
 		(_b)->magic = 0; \
@@ -752,6 +825,17 @@ ISC_LANG_ENDDECLS
 		_cp[1] = (unsigned char)(_val2 & 0x00ffU); \
 	} while (0)
 
+#define ISC__BUFFER_PUTUINT24(_b, _val) \
+	do { \
+		unsigned char *_cp; \
+		isc_uint32_t _val2 = (_val); \
+		_cp = isc_buffer_used(_b); \
+		(_b)->used += 3; \
+		_cp[0] = (unsigned char)((_val2 & 0xff0000U) >> 16); \
+		_cp[1] = (unsigned char)((_val2 & 0xff00U) >> 8); \
+		_cp[2] = (unsigned char)(_val2 & 0x00ffU); \
+	} while (0)
+
 #define ISC__BUFFER_PUTUINT32(_b, _val) \
 	do { \
 		unsigned char *_cp; \
@@ -766,6 +850,7 @@ ISC_LANG_ENDDECLS
 
 #if defined(ISC_BUFFER_USEINLINE)
 #define isc_buffer_init			ISC__BUFFER_INIT
+#define isc_buffer_initnull		ISC__BUFFER_INITNULL
 #define isc_buffer_invalidate		ISC__BUFFER_INVALIDATE
 #define isc_buffer_region		ISC__BUFFER_REGION
 #define isc_buffer_usedregion		ISC__BUFFER_USEDREGION
@@ -784,9 +869,11 @@ ISC_LANG_ENDDECLS
 #define isc_buffer_putstr		ISC__BUFFER_PUTSTR
 #define isc_buffer_putuint8		ISC__BUFFER_PUTUINT8
 #define isc_buffer_putuint16		ISC__BUFFER_PUTUINT16
+#define isc_buffer_putuint24		ISC__BUFFER_PUTUINT24
 #define isc_buffer_putuint32		ISC__BUFFER_PUTUINT32
 #else
 #define isc_buffer_init			isc__buffer_init
+#define isc_buffer_initnull		isc__buffer_initnull
 #define isc_buffer_invalidate		isc__buffer_invalidate
 #define isc_buffer_region		isc__buffer_region
 #define isc_buffer_usedregion		isc__buffer_usedregion
@@ -805,7 +892,13 @@ ISC_LANG_ENDDECLS
 #define isc_buffer_putstr		isc__buffer_putstr
 #define isc_buffer_putuint8		isc__buffer_putuint8
 #define isc_buffer_putuint16		isc__buffer_putuint16
+#define isc_buffer_putuint24		isc__buffer_putuint24
 #define isc_buffer_putuint32		isc__buffer_putuint32
 #endif
 
+/*
+ * No inline method for this one (yet).
+ */
+#define isc_buffer_putuint48		isc__buffer_putuint48
+
 #endif /* ISC_BUFFER_H */
diff --git a/contrib/bind9/lib/isc/include/isc/bufferlist.h b/contrib/bind9/lib/isc/include/isc/bufferlist.h
index 7fc2ecc..54e00c7 100644
--- a/contrib/bind9/lib/isc/include/isc/bufferlist.h
+++ b/contrib/bind9/lib/isc/include/isc/bufferlist.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: bufferlist.h,v 1.11.18.2 2005/04/29 00:16:53 marka Exp $ */
+/* $Id: bufferlist.h,v 1.17 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_BUFFERLIST_H
 #define ISC_BUFFERLIST_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file bufferlist.h
+/*! \file isc/bufferlist.h
  *
  *
  *\brief	Buffer lists have no synchronization.  Clients must ensure exclusive
diff --git a/contrib/bind9/lib/isc/include/isc/commandline.h b/contrib/bind9/lib/isc/include/isc/commandline.h
index 5ece26f..384640a 100644
--- a/contrib/bind9/lib/isc/include/isc/commandline.h
+++ b/contrib/bind9/lib/isc/include/isc/commandline.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: commandline.h,v 1.10.18.2 2005/04/29 00:16:53 marka Exp $ */
+/* $Id: commandline.h,v 1.16 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_COMMANDLINE_H
 #define ISC_COMMANDLINE_H 1
 
-/*! \file */
+/*! \file isc/commandline.h */
 
 #include <isc/boolean.h>
 #include <isc/lang.h>
diff --git a/contrib/bind9/lib/isc/include/isc/entropy.h b/contrib/bind9/lib/isc/include/isc/entropy.h
index 2890f6c..e9e59c4 100644
--- a/contrib/bind9/lib/isc/include/isc/entropy.h
+++ b/contrib/bind9/lib/isc/include/isc/entropy.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: entropy.h,v 1.25.18.2 2005/04/29 00:16:54 marka Exp $ */
+/* $Id: entropy.h,v 1.32.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef ISC_ENTROPY_H
 #define ISC_ENTROPY_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file entropy.h
+/*! \file isc/entropy.h
  * \brief The entropy API
  *
  * \li MP:
@@ -74,7 +74,7 @@ typedef void (*isc_entropystop_t)(isc_entropysource_t *source, void *arg);
  ***/
 
 /*!
- * \brief 
+ * \brief
  *	Extract only "good" data; return failure if there is not enough
  *	data available and there are no sources which we can poll to get
  *	data, or those sources are empty.
@@ -103,7 +103,7 @@ typedef void (*isc_entropystop_t)(isc_entropysource_t *source, void *arg);
 /*!
  * \brief
  *	Estimate the amount of entropy contained in the sample pool.
- *	If this is not set, the source will be gathered and perodically
+ *	If this is not set, the source will be gathered and periodically
  *	mixed into the entropy pool, but no increment in contained entropy
  *	will be assumed.  This flag only makes sense on sample sources.
  */
@@ -113,12 +113,12 @@ typedef void (*isc_entropystop_t)(isc_entropysource_t *source, void *arg);
  * For use with isc_entropy_usebestsource().
  */
 /*!
- * \brief 
+ * \brief
  *	Use the keyboard as the only entropy source.
  */
 #define ISC_ENTROPY_KEYBOARDYES		1
 /*!
- * \brief 
+ * \brief
  *	Never use the keyboard as an entropy source.
  */
 #define ISC_ENTROPY_KEYBOARDNO		2
@@ -194,7 +194,7 @@ isc_entropy_createcallbacksource(isc_entropy_t *ent,
 				 void *arg,
 				 isc_entropysource_t **sourcep);
 /*!<
- * \brief Create an entropy source that is polled via a callback.  
+ * \brief Create an entropy source that is polled via a callback.
  *
  * This would
  * be used when keyboard input is used, or a GUI input method.  It can
@@ -220,7 +220,7 @@ isc_result_t
 isc_entropy_addsample(isc_entropysource_t *source, isc_uint32_t sample,
 		      isc_uint32_t extra);
 /*!<
- * \brief Add a sample to the sample source.  
+ * \brief Add a sample to the sample source.
  *
  * The sample MUST be a timestamp
  * that increases over time, with the exception of wrap-around for
@@ -267,6 +267,13 @@ isc_entropy_stats(isc_entropy_t *ent, FILE *out);
  * \brief Dump some (trivial) stats to the stdio stream "out".
  */
 
+unsigned int
+isc_entropy_status(isc_entropy_t *end);
+/*
+ * Returns the number of bits the pool currently contains.  This is just
+ * an estimate.
+ */
+
 isc_result_t
 isc_entropy_usebestsource(isc_entropy_t *ectx, isc_entropysource_t **source,
 			  const char *randomfile, int use_keyboard);
@@ -275,11 +282,11 @@ isc_entropy_usebestsource(isc_entropy_t *ectx, isc_entropysource_t **source,
  *
  * Notes:
  *\li	If "randomfile" is not NULL, open it with
- *	isc_entropy_createfilesource(). 
+ *	isc_entropy_createfilesource().
  *
  *\li	If "randomfile" is NULL and the system's random device was detected
  *	when the program was configured and built, open that device with
- *	isc_entropy_createfilesource(). 
+ *	isc_entropy_createfilesource().
  *
  *\li	If "use_keyboard" is #ISC_ENTROPY_KEYBOARDYES, then always open
  *	the keyboard as an entropy source (possibly in addition to
diff --git a/contrib/bind9/lib/isc/include/isc/error.h b/contrib/bind9/lib/isc/include/isc/error.h
index 3320ae9..efb9b5f 100644
--- a/contrib/bind9/lib/isc/include/isc/error.h
+++ b/contrib/bind9/lib/isc/include/isc/error.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: error.h,v 1.14.18.2 2005/04/29 00:16:54 marka Exp $ */
+/* $Id: error.h,v 1.20 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_ERROR_H
 #define ISC_ERROR_H 1
 
-/*! \file */
+/*! \file isc/error.h */
 
 #include <stdarg.h>
 
diff --git a/contrib/bind9/lib/isc/include/isc/event.h b/contrib/bind9/lib/isc/include/isc/event.h
index f1b1d61..68fabb2 100644
--- a/contrib/bind9/lib/isc/include/isc/event.h
+++ b/contrib/bind9/lib/isc/include/isc/event.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: event.h,v 1.27.18.3 2005/04/29 00:16:54 marka Exp $ */
+/* $Id: event.h,v 1.34 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_EVENT_H
 #define ISC_EVENT_H 1
 
-/*! \file */
+/*! \file isc/event.h */
 
 #include <isc/lang.h>
 #include <isc/types.h>
diff --git a/contrib/bind9/lib/isc/include/isc/eventclass.h b/contrib/bind9/lib/isc/include/isc/eventclass.h
index 71de715..9e6c145 100644
--- a/contrib/bind9/lib/isc/include/isc/eventclass.h
+++ b/contrib/bind9/lib/isc/include/isc/eventclass.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: eventclass.h,v 1.14.18.2 2005/04/29 00:16:54 marka Exp $ */
+/* $Id: eventclass.h,v 1.18 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_EVENTCLASS_H
 #define ISC_EVENTCLASS_H 1
diff --git a/contrib/bind9/lib/isc/include/isc/file.h b/contrib/bind9/lib/isc/include/isc/file.h
index 16b0075..c945734 100644
--- a/contrib/bind9/lib/isc/include/isc/file.h
+++ b/contrib/bind9/lib/isc/include/isc/file.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: file.h,v 1.27.18.2 2005/04/29 00:16:54 marka Exp $ */
+/* $Id: file.h,v 1.33.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef ISC_FILE_H
 #define ISC_FILE_H 1
 
-/*! \file */
+/*! \file isc/file.h */
 
 #include <stdio.h>
 
@@ -35,7 +35,7 @@ isc_file_settime(const char *file, isc_time_t *time);
 isc_result_t
 isc_file_getmodtime(const char *file, isc_time_t *time);
 /*!<
- * \brief Get the time of last modication of a file.
+ * \brief Get the time of last modification of a file.
  *
  * Notes:
  *\li	The time that is set is relative to the (OS-specific) epoch, as are
@@ -204,7 +204,7 @@ isc_result_t
 isc_file_progname(const char *filename, char *buf, size_t buflen);
 /*!<
  * \brief Given an operating system specific file name "filename"
- * referring to a program, return the canonical program name. 
+ * referring to a program, return the canonical program name.
  *
  *
  * Any directory prefix or executable file name extension (if
diff --git a/contrib/bind9/lib/isc/include/isc/formatcheck.h b/contrib/bind9/lib/isc/include/isc/formatcheck.h
index 93c6232..51ce3ca 100644
--- a/contrib/bind9/lib/isc/include/isc/formatcheck.h
+++ b/contrib/bind9/lib/isc/include/isc/formatcheck.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: formatcheck.h,v 1.7.18.2 2005/04/29 00:16:54 marka Exp $ */
+/* $Id: formatcheck.h,v 1.13 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_FORMATCHECK_H
 #define ISC_FORMATCHECK_H 1
 
-/*! \file */
+/*! \file isc/formatcheck.h */
 
 /*%
  * ISC_FORMAT_PRINTF().
diff --git a/contrib/bind9/lib/isc/include/isc/fsaccess.h b/contrib/bind9/lib/isc/include/isc/fsaccess.h
index 70c4d7c..3b455e5 100644
--- a/contrib/bind9/lib/isc/include/isc/fsaccess.h
+++ b/contrib/bind9/lib/isc/include/isc/fsaccess.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,18 +15,18 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: fsaccess.h,v 1.8.18.2 2005/04/29 00:16:55 marka Exp $ */
+/* $Id: fsaccess.h,v 1.14.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef ISC_FSACCESS_H
 #define ISC_FSACCESS_H 1
 
-/*! \file
+/*! \file isc/fsaccess.h
  * \brief The ISC filesystem access module encapsulates the setting of file
  * and directory access permissions into one API that is meant to be
  * portable to multiple operating systems.
  *
- * The two primary operating system flavors that are initially accomodated are
- * POSIX and Windows NT 4.0 and later.  The Windows NT access model is
+ * The two primary operating system flavors that are initially accommodated
+ * are POSIX and Windows NT 4.0 and later.  The Windows NT access model is
  * considerable more flexible than POSIX's model (as much as I am loathe to
  * admit it), and so the ISC API has a higher degree of complexity than would
  * be needed to simply address POSIX's needs.
@@ -88,7 +88,7 @@
  *
  * The rest of this comment discusses a few of the incompatibilities
  * between the two systems that need more thought if this API is to
- * be extended to accomodate them.
+ * be extended to accommodate them.
  *
  * The Windows standard access right "DELETE" doesn't have a direct
  * equivalent in the Unix world, so it isn't clear what should be done
@@ -98,18 +98,19 @@
  * of allowing users to create files in a directory but not delete or
  * rename them, it does not have a concept of allowing them to be deleted
  * if they are owned by the user trying to delete/rename.  While it is
- * probable that something could be cobbled together in NT 5 with inheritence,
+ * probable that something could be cobbled together in NT 5 with inheritance,
  * it can't really be done in NT 4 as a single property that you could
  * set on a directory.  You'd need to coordinate something with file creation
  * so that every file created had DELETE set for the owner but noone else.
  *
  * On Unix systems, setting #ISC_FSACCESS_LISTDIRECTORY sets READ.
- * ... setting either of #ISC_FSACCESS_(CREATE|DELETE)CHILD sets WRITE.
+ * ... setting either #ISC_FSACCESS_CREATECHILD or #ISC_FSACCESS_DELETECHILD
+ *      sets WRITE.
  * ... setting #ISC_FSACCESS_ACCESSCHILD sets EXECUTE.
  *
  * On NT systems, setting #ISC_FSACCESS_LISTDIRECTORY sets FILE_LIST_DIRECTORY.
- * ... setting ISC_FSACCESS_(CREATE|DELETE)CHILD sets
- *	FILE_(CREATE|DELETE)_CHILD independently.
+ * ... setting #ISC_FSACCESS_CREATECHILD sets FILE_CREATE_CHILD independently.
+ * ... setting #ISC_FSACCESS_DELETECHILD sets FILE_DELETE_CHILD independently.
  * ... setting #ISC_FSACCESS_ACCESSCHILD sets FILE_TRAVERSE.
  *
  * Unresolved:							XXXDCL
@@ -155,7 +156,7 @@
  * Adding any permission bits beyond 0x200 would mean typedef'ing
  * isc_fsaccess_t as isc_uint64_t, and redefining this value to
  * reflect the new range of permission types, Probably to 21 for
- * maximum flexibility.  The number of bits has to accomodate all of
+ * maximum flexibility.  The number of bits has to accommodate all of
  * the permission types, and three full sets of them have to fit
  * within an isc_fsaccess_t.
  */
diff --git a/contrib/bind9/lib/isc/include/isc/hash.h b/contrib/bind9/lib/isc/include/isc/hash.h
index cd29cdf..da30a19 100644
--- a/contrib/bind9/lib/isc/include/isc/hash.h
+++ b/contrib/bind9/lib/isc/include/isc/hash.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: hash.h,v 1.4.18.2 2005/04/29 00:16:55 marka Exp $ */
+/* $Id: hash.h,v 1.10.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef ISC_HASH_H
 #define ISC_HASH_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file isc/hash.h
  *
  * \brief The hash API
  *	provides an unpredictable hash value for variable length data.
@@ -36,7 +36,7 @@
  *	in the random vector are unpredictable, the probability of hash
  *	collision between arbitrary two different values is at most 1/2^16.
  *
- *	Altough the API is generic about the hash keys, it mainly expects
+ *	Although the API is generic about the hash keys, it mainly expects
  *	DNS names (and sometimes IPv4/v6 addresses) as inputs.  It has an
  *	upper limit of the input length, and may run slow to calculate the
  *	hash values for large inputs.
@@ -135,7 +135,7 @@ isc_hash_ctxinit(isc_hash_t *hctx);
 void
 isc_hash_init(void);
 /*!<
- * \brief Initialize a hash object.  
+ * \brief Initialize a hash object.
  *
  * It fills in the random vector with a proper
  * source of entropy, which is typically from the entropy object specified
diff --git a/contrib/bind9/lib/isc/include/isc/heap.h b/contrib/bind9/lib/isc/include/isc/heap.h
index d54a8d5..82c5982 100644
--- a/contrib/bind9/lib/isc/include/isc/heap.h
+++ b/contrib/bind9/lib/isc/include/isc/heap.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1997-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: heap.h,v 1.17.18.3 2006/04/17 18:27:33 explorer Exp $ */
+/* $Id: heap.h,v 1.24.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef ISC_HEAP_H
 #define ISC_HEAP_H 1
 
-/*! \file */
+/*! \file isc/heap.h */
 
 #include <isc/lang.h>
 #include <isc/types.h>
@@ -28,7 +28,7 @@
 ISC_LANG_BEGINDECLS
 
 /*%
- * The comparision function returns ISC_TRUE if the first argument has
+ * The comparison function returns ISC_TRUE if the first argument has
  * higher priority than the second argument, and ISC_FALSE otherwise.
  */
 typedef isc_boolean_t (*isc_heapcompare_t)(void *, void *);
diff --git a/contrib/bind9/lib/isc/include/isc/hex.h b/contrib/bind9/lib/isc/include/isc/hex.h
index 9124a9b..a5e2f53 100644
--- a/contrib/bind9/lib/isc/include/isc/hex.h
+++ b/contrib/bind9/lib/isc/include/isc/hex.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: hex.h,v 1.5.18.2 2005/04/29 00:16:55 marka Exp $ */
+/* $Id: hex.h,v 1.13 2008/09/25 04:02:39 tbox Exp $ */
 
 #ifndef ISC_HEX_H
 #define ISC_HEX_H 1
 
-/*! \file */
+/*! \file isc/hex.h */
 
 #include <isc/lang.h>
 #include <isc/types.h>
@@ -56,7 +56,7 @@ isc_hex_totext(isc_region_t *source, int wordlength,
  */
 
 isc_result_t
-isc_hex_decodestring(char *cstr, isc_buffer_t *target);
+isc_hex_decodestring(const char *cstr, isc_buffer_t *target);
 /*!<
  * \brief Decode a null-terminated hex string.
  *
diff --git a/contrib/bind9/lib/isc/include/isc/hmacmd5.h b/contrib/bind9/lib/isc/include/isc/hmacmd5.h
index 5c05675..fab9c58 100644
--- a/contrib/bind9/lib/isc/include/isc/hmacmd5.h
+++ b/contrib/bind9/lib/isc/include/isc/hmacmd5.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,9 +15,9 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: hmacmd5.h,v 1.5.18.4 2006/01/27 23:57:45 marka Exp $ */
+/* $Id: hmacmd5.h,v 1.12 2007/06/19 23:47:18 tbox Exp $ */
 
-/*! \file
+/*! \file isc/hmacmd5.h
  * \brief This is the header file for the HMAC-MD5 keyed hash algorithm
  * described in RFC2104.
  */
diff --git a/contrib/bind9/lib/isc/include/isc/hmacsha.h b/contrib/bind9/lib/isc/include/isc/hmacsha.h
index fce645c5..362b37f 100644
--- a/contrib/bind9/lib/isc/include/isc/hmacsha.h
+++ b/contrib/bind9/lib/isc/include/isc/hmacsha.h
@@ -1,7 +1,7 @@
 /*
- * Copyright (C) 2005, 2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2005-2007  Internet Systems Consortium, Inc. ("ISC")
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -14,9 +14,9 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: hmacsha.h,v 1.2.2.3 2006/08/16 03:18:14 marka Exp $ */
+/* $Id: hmacsha.h,v 1.7 2007/06/19 23:47:18 tbox Exp $ */
 
-/*
+/*! \file isc/hmacsha.h
  * This is the header file for the HMAC-SHA1, HMAC-SHA224, HMAC-SHA256,
  * HMAC-SHA334 and HMAC-SHA512 hash algorithm described in RFC 2104.
  */
diff --git a/contrib/bind9/lib/isc/include/isc/httpd.h b/contrib/bind9/lib/isc/include/isc/httpd.h
new file mode 100644
index 0000000..ba7f900
--- /dev/null
+++ b/contrib/bind9/lib/isc/include/isc/httpd.h
@@ -0,0 +1,64 @@
+/*
+ * Copyright (C) 2006-2008  Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or 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: httpd.h,v 1.9 2008/08/08 05:06:49 marka Exp $ */
+
+#ifndef ISC_HTTPD_H
+#define ISC_HTTPD_H 1
+
+/*! \file */
+
+#include <isc/event.h>
+#include <isc/eventclass.h>
+#include <isc/types.h>
+#include <isc/mutex.h>
+#include <isc/task.h>
+
+#define HTTPD_EVENTCLASS		ISC_EVENTCLASS(4300)
+#define HTTPD_SHUTDOWN			(HTTPD_EVENTCLASS + 0x0001)
+
+#define ISC_HTTPDMGR_FLAGSHUTTINGDOWN	0x00000001
+
+/*
+ * Create a new http daemon which will send, once every time period,
+ * a http-like header followed by HTTP data.
+ */
+isc_result_t
+isc_httpdmgr_create(isc_mem_t *mctx, isc_socket_t *sock, isc_task_t *task,
+		    isc_httpdclientok_t *client_ok,
+		    isc_httpdondestroy_t *ondestory, void *cb_arg,
+		    isc_timermgr_t *tmgr, isc_httpdmgr_t **httpdp);
+
+void
+isc_httpdmgr_shutdown(isc_httpdmgr_t **httpdp);
+
+isc_result_t
+isc_httpdmgr_addurl(isc_httpdmgr_t *httpdmgr, const char *url,
+		    isc_httpdaction_t *func, void *arg);
+
+isc_result_t
+isc_httpd_response(isc_httpd_t *httpd);
+
+isc_result_t
+isc_httpd_addheader(isc_httpd_t *httpd, const char *name,
+		    const char *val);
+
+isc_result_t
+isc_httpd_addheaderuint(isc_httpd_t *httpd, const char *name, int val);
+
+isc_result_t isc_httpd_endheaders(isc_httpd_t *httpd);
+
+#endif /* ISC_HTTPD_H */
diff --git a/contrib/bind9/lib/isc/include/isc/interfaceiter.h b/contrib/bind9/lib/isc/include/isc/interfaceiter.h
index 12ec188..26d5dfb 100644
--- a/contrib/bind9/lib/isc/include/isc/interfaceiter.h
+++ b/contrib/bind9/lib/isc/include/isc/interfaceiter.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: interfaceiter.h,v 1.11.18.2 2005/04/29 00:16:55 marka Exp $ */
+/* $Id: interfaceiter.h,v 1.17 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_INTERFACEITER_H
 #define ISC_INTERFACEITER_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file isc/interfaceiter.h
  * \brief Iterates over the list of network interfaces.
  *
  * Interfaces whose address family is not supported are ignored and never
diff --git a/contrib/bind9/lib/isc/include/isc/ipv6.h b/contrib/bind9/lib/isc/include/isc/ipv6.h
index 7c88f2b..8054c9e 100644
--- a/contrib/bind9/lib/isc/include/isc/ipv6.h
+++ b/contrib/bind9/lib/isc/include/isc/ipv6.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ipv6.h,v 1.20.18.2 2005/04/29 00:16:56 marka Exp $ */
+/* $Id: ipv6.h,v 1.24 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_IPV6_H
 #define ISC_IPV6_H 1
diff --git a/contrib/bind9/lib/isc/include/isc/iterated_hash.h b/contrib/bind9/lib/isc/include/isc/iterated_hash.h
new file mode 100644
index 0000000..a8173f0
--- /dev/null
+++ b/contrib/bind9/lib/isc/include/isc/iterated_hash.h
@@ -0,0 +1,47 @@
+/*
+ * Copyright (C) 2008  Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or 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: iterated_hash.h,v 1.3 2008/09/25 04:02:39 tbox Exp $ */
+
+#ifndef ISC_ITERATED_HASH_H
+#define ISC_ITERATED_HASH_H 1
+
+#include <isc/lang.h>
+#include <isc/sha1.h>
+
+/*
+ * The maximal hash length that can be encoded it a name
+ * using base32hex.  floor(255/8)*5
+ */
+#define NSEC3_MAX_HASH_LENGTH 155
+
+/*
+ * The maximum has that can be encoded in a single label using
+ * base32hex.  floor(63/8)*5
+ */
+#define NSEC3_MAX_LABEL_HASH 35
+
+ISC_LANG_BEGINDECLS
+
+int isc_iterated_hash(unsigned char out[NSEC3_MAX_HASH_LENGTH],
+		      unsigned int hashalg, int iterations,
+		      const unsigned char *salt, int saltlength,
+		      const unsigned char *in, int inlength);
+
+
+ISC_LANG_ENDDECLS
+
+#endif /* ISC_ITERATED_HASH_H */
diff --git a/contrib/bind9/lib/isc/include/isc/lang.h b/contrib/bind9/lib/isc/include/isc/lang.h
index abe16f5..8c60866 100644
--- a/contrib/bind9/lib/isc/include/isc/lang.h
+++ b/contrib/bind9/lib/isc/include/isc/lang.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lang.h,v 1.7.18.2 2005/04/29 00:16:56 marka Exp $ */
+/* $Id: lang.h,v 1.13 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_LANG_H
 #define ISC_LANG_H 1
 
-/*! \file */
+/*! \file isc/lang.h */
 
 #ifdef __cplusplus
 #define ISC_LANG_BEGINDECLS	extern "C" {
diff --git a/contrib/bind9/lib/isc/include/isc/lex.h b/contrib/bind9/lib/isc/include/isc/lex.h
index cb9cc18..8612150 100644
--- a/contrib/bind9/lib/isc/include/isc/lex.h
+++ b/contrib/bind9/lib/isc/include/isc/lex.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lex.h,v 1.30.18.5 2008/05/30 23:46:01 tbox Exp $ */
+/* $Id: lex.h,v 1.37 2008/05/30 23:47:01 tbox Exp $ */
 
 #ifndef ISC_LEX_H
 #define ISC_LEX_H 1
diff --git a/contrib/bind9/lib/isc/include/isc/lfsr.h b/contrib/bind9/lib/isc/include/isc/lfsr.h
index 0c2e845..d4d9707 100644
--- a/contrib/bind9/lib/isc/include/isc/lfsr.h
+++ b/contrib/bind9/lib/isc/include/isc/lfsr.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lfsr.h,v 1.11.18.2 2005/04/29 00:16:56 marka Exp $ */
+/* $Id: lfsr.h,v 1.17 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_LFSR_H
 #define ISC_LFSR_H 1
 
-/*! \file */
+/*! \file isc/lfsr.h */
 
 #include <isc/lang.h>
 #include <isc/types.h>
diff --git a/contrib/bind9/lib/isc/include/isc/lib.h b/contrib/bind9/lib/isc/include/isc/lib.h
index 45c547c..765cdfa 100644
--- a/contrib/bind9/lib/isc/include/isc/lib.h
+++ b/contrib/bind9/lib/isc/include/isc/lib.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lib.h,v 1.8.18.2 2005/04/29 00:16:58 marka Exp $ */
+/* $Id: lib.h,v 1.14 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_LIB_H
 #define ISC_LIB_H 1
 
-/*! \file */
+/*! \file isc/lib.h */
 
 #include <isc/types.h>
 #include <isc/lang.h>
diff --git a/contrib/bind9/lib/isc/include/isc/list.h b/contrib/bind9/lib/isc/include/isc/list.h
index 2adc33f..9338275 100644
--- a/contrib/bind9/lib/isc/include/isc/list.h
+++ b/contrib/bind9/lib/isc/include/isc/list.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2006, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1997-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: list.h,v 1.20.18.2 2006/06/06 00:11:41 marka Exp $ */
+/* $Id: list.h,v 1.24 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_LIST_H
 #define ISC_LIST_H 1
diff --git a/contrib/bind9/lib/isc/include/isc/log.h b/contrib/bind9/lib/isc/include/isc/log.h
index c381775..c9ba808 100644
--- a/contrib/bind9/lib/isc/include/isc/log.h
+++ b/contrib/bind9/lib/isc/include/isc/log.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: log.h,v 1.47.18.3 2005/04/29 00:16:58 marka Exp $ */
+/* $Id: log.h,v 1.54.332.5 2009/02/16 02:04:05 marka Exp $ */
 
 #ifndef ISC_LOG_H
 #define ISC_LOG_H 1
 
-/*! \file */
+/*! \file isc/log.h */
 
 #include <stdio.h>
 #include <stdarg.h>
@@ -86,7 +86,7 @@
 /*@}*/
 
 /*!
- * \brief Used to name the categories used by a library.  
+ * \brief Used to name the categories used by a library.
  *
  * An array of isc_logcategory
  * structures names each category, and the id value is initialized by calling
@@ -107,13 +107,13 @@ struct isc_logmodule {
 
 /*%
  * The isc_logfile structure is initialized as part of an isc_logdestination
- * before calling isc_log_createchannel().  
+ * before calling isc_log_createchannel().
  *
  * When defining an #ISC_LOG_TOFILE
  * channel the name, versions and maximum_size should be set before calling
  * isc_log_createchannel().  To define an #ISC_LOG_TOFILEDESC channel set only
  * the stream before the call.
- * 
+ *
  * Setting maximum_size to zero implies no maximum.
  */
 typedef struct isc_logfile {
@@ -166,6 +166,7 @@ LIBISC_EXTERNAL_DATA extern isc_logmodule_t isc_modules[];
 #define ISC_LOGMODULE_TIME (&isc_modules[1])
 #define ISC_LOGMODULE_INTERFACE (&isc_modules[2])
 #define ISC_LOGMODULE_TIMER (&isc_modules[3])
+#define ISC_LOGMODULE_FILE (&isc_modules[4])
 
 ISC_LANG_BEGINDECLS
 
@@ -477,7 +478,7 @@ isc_log_usechannel(isc_logconfig_t *lcfg, const char *name,
  *	number of named channels.)  When multiple channels of the same
  *	name are defined, the most recent definition is found.
  *
- *\li	Specifing a very large number of channels for a category will have
+ *\li	Specifying a very large number of channels for a category will have
  *	a moderate impact on performance in isc_log_write(), as each
  *	call looks up the category for the start of a linked list, which
  *	it follows all the way to the end to find matching modules.  The
@@ -527,7 +528,7 @@ isc_log_usechannel(isc_logconfig_t *lcfg, const char *name,
  */
 
 /* Attention: next four comments PRECEED code */
-/*! 
+/*!
  *   \brief
  * Write a message to the log channels.
  *
@@ -546,7 +547,7 @@ isc_log_usechannel(isc_logconfig_t *lcfg, const char *name,
  *\li	lctx is a valid logging context.
  *
  *\li	The category and module arguments must have ids that are in the
- *	range of known ids, as estabished by isc_log_registercategories()
+ *	range of known ids, as established by isc_log_registercategories()
  *	and isc_log_registermodules().
  *
  *\li	level != #ISC_LOG_DYNAMIC.  ISC_LOG_DYNAMIC is used only to define
@@ -585,7 +586,7 @@ ISC_FORMAT_PRINTF(5, 6);
  *\li	lctx is a valid logging context.
  *
  *\li	The category and module arguments must have ids that are in the
- *	range of known ids, as estabished by isc_log_registercategories()
+ *	range of known ids, as established by isc_log_registercategories()
  *	and isc_log_registermodules().
  *
  *\li	level != #ISC_LOG_DYNAMIC.  ISC_LOG_DYNAMIC is used only to define
@@ -633,8 +634,8 @@ isc_log_vwrite1(isc_log_t *lctx, isc_logcategory_t *category,
 ISC_FORMAT_PRINTF(5, 0);
 
 /*%
- * These are four internationalized versions of the the isc_log_[v]write[1]
- * functions.  
+ * These are four internationalized versions of the isc_log_[v]write[1]
+ * functions.
  *
  * The only difference is that they take arguments for a message
  * catalog, message set, and message number, all immediately preceding the
@@ -824,7 +825,7 @@ isc_log_opensyslog(const char *tag, int options, int facility);
  *			declared facility.
  * \endcode
  *
- *\li	Zero effort has been made (yet) to accomodate systems with openlog()
+ *\li	Zero effort has been made (yet) to accommodate systems with openlog()
  *	that only takes two arguments, or to identify valid syslog
  *	facilities or options for any given architecture.
  *
diff --git a/contrib/bind9/lib/isc/include/isc/magic.h b/contrib/bind9/lib/isc/include/isc/magic.h
index 045b54f..073de90 100644
--- a/contrib/bind9/lib/isc/include/isc/magic.h
+++ b/contrib/bind9/lib/isc/include/isc/magic.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: magic.h,v 1.12.18.2 2005/04/29 00:16:59 marka Exp $ */
+/* $Id: magic.h,v 1.18 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_MAGIC_H
 #define ISC_MAGIC_H 1
 
-/*! \file */
+/*! \file isc/magic.h */
 
 typedef struct {
 	unsigned int magic;
diff --git a/contrib/bind9/lib/isc/include/isc/md5.h b/contrib/bind9/lib/isc/include/isc/md5.h
index 3f9667e..5b0d785 100644
--- a/contrib/bind9/lib/isc/include/isc/md5.h
+++ b/contrib/bind9/lib/isc/include/isc/md5.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,9 +15,9 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: md5.h,v 1.9.18.4 2006/02/01 00:10:34 marka Exp $ */
+/* $Id: md5.h,v 1.16 2007/06/19 23:47:18 tbox Exp $ */
 
-/*! \file 
+/*! \file isc/md5.h
  * \brief This is the header file for the MD5 message-digest algorithm.
  *
  * The algorithm is due to Ron Rivest.  This code was
diff --git a/contrib/bind9/lib/isc/include/isc/mem.h b/contrib/bind9/lib/isc/include/isc/mem.h
index 2c3c54e..480a934 100644
--- a/contrib/bind9/lib/isc/include/isc/mem.h
+++ b/contrib/bind9/lib/isc/include/isc/mem.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1997-2001  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: mem.h,v 1.59.18.11 2008/02/07 23:45:56 tbox Exp $ */
+/* $Id: mem.h,v 1.78.120.3 2009/02/11 03:07:01 jinmei Exp $ */
 
 #ifndef ISC_MEM_H
 #define ISC_MEM_H 1
 
-/*! \file */
+/*! \file isc/mem.h */
 
 #include <stdio.h>
 
@@ -28,6 +28,7 @@
 #include <isc/mutex.h>
 #include <isc/platform.h>
 #include <isc/types.h>
+#include <isc/xml.h>
 
 ISC_LANG_BEGINDECLS
 
@@ -93,7 +94,7 @@ LIBISC_EXTERNAL_DATA extern unsigned int isc_mem_debugging;
 /*!<
  * The variable isc_mem_debugging holds a set of flags for
  * turning certain memory debugging options on or off at
- * runtime.  Its is intialized to the value ISC_MEM_DEGBUGGING,
+ * runtime.  It is initialized to the value ISC_MEM_DEGBUGGING,
  * which is 0 by default but may be overridden at compile time.
  * The following flags can be specified:
  *
@@ -105,7 +106,7 @@ LIBISC_EXTERNAL_DATA extern unsigned int isc_mem_debugging;
  *	Crash if a free doesn't match an allocation.
  *
  * \li #ISC_MEM_DEBUGUSAGE
- *	If a hi_water mark is set, print the maximium inuse memory
+ *	If a hi_water mark is set, print the maximum inuse memory
  *	every time it is raised once it exceeds the hi_water mark.
  *
  * \li #ISC_MEM_DEBUGSIZE
@@ -153,11 +154,12 @@ LIBISC_EXTERNAL_DATA extern unsigned int isc_mem_debugging;
 
 #define isc_mem_get(c, s)	isc__mem_get((c), (s) _ISC_MEM_FILELINE)
 #define isc_mem_allocate(c, s)	isc__mem_allocate((c), (s) _ISC_MEM_FILELINE)
+#define isc_mem_reallocate(c, p, s) isc__mem_reallocate((c), (p), (s) _ISC_MEM_FILELINE)
 #define isc_mem_strdup(c, p)	isc__mem_strdup((c), (p) _ISC_MEM_FILELINE)
 #define isc_mempool_get(c)	isc__mempool_get((c) _ISC_MEM_FILELINE)
 
 /*%
- * isc_mem_putanddetach() is a convienence function for use where you
+ * isc_mem_putanddetach() is a convenience function for use where you
  * have a structure with an attached memory context.
  *
  * Given:
@@ -340,12 +342,12 @@ isc_mem_setwater(isc_mem_t *mctx, isc_mem_water_t water, void *water_arg,
  *
  * When the memory usage of 'mctx' exceeds 'hiwater',
  * '(water)(water_arg, #ISC_MEM_HIWATER)' will be called.  'water' needs to
- * call isc_mem_waterack() with #ISC_MEM_HIWATER to acknowlege the state
+ * call isc_mem_waterack() with #ISC_MEM_HIWATER to acknowledge the state
  * change.  'water' may be called multiple times.
  *
  * When the usage drops below 'lowater', 'water' will again be called, this
  * time with #ISC_MEM_LOWATER.  'water' need to calls isc_mem_waterack() with
- * #ISC_MEM_LOWATER to acknowlege the change.
+ * #ISC_MEM_LOWATER to acknowledge the change.
  *
  *	static void
  *	water(void *arg, int mark) {
@@ -359,6 +361,7 @@ isc_mem_setwater(isc_mem_t *mctx, isc_mem_water_t water, void *water_arg,
  *		}
  *		UNLOCK(&foo->marklock);
  *	}
+ *
  * If 'water' is NULL then 'water_arg', 'hi_water' and 'lo_water' are
  * ignored and the state is reset.
  *
@@ -371,7 +374,7 @@ isc_mem_setwater(isc_mem_t *mctx, isc_mem_water_t water, void *water_arg,
 void
 isc_mem_waterack(isc_mem_t *ctx, int mark);
 /*%<
- * Called to acknowledge changes in signalled by calls to 'water'.
+ * Called to acknowledge changes in signaled by calls to 'water'.
  */
 
 void
@@ -398,6 +401,65 @@ isc_mem_checkdestroyed(FILE *file);
  * Fatally fails if there are still active contexts.
  */
 
+unsigned int
+isc_mem_references(isc_mem_t *ctx);
+/*%<
+ * Return the current reference count.
+ */
+
+void
+isc_mem_setname(isc_mem_t *ctx, const char *name, void *tag);
+/*%<
+ * Name 'ctx'.
+ *
+ * Notes:
+ *
+ *\li	Only the first 15 characters of 'name' will be copied.
+ *
+ *\li	'tag' is for debugging purposes only.
+ *
+ * Requires:
+ *
+ *\li	'ctx' is a valid ctx.
+ */
+
+const char *
+isc_mem_getname(isc_mem_t *ctx);
+/*%<
+ * Get the name of 'ctx', as previously set using isc_mem_setname().
+ *
+ * Requires:
+ *\li	'ctx' is a valid ctx.
+ *
+ * Returns:
+ *\li	A non-NULL pointer to a null-terminated string.
+ * 	If the ctx has not been named, the string is
+ * 	empty.
+ */
+
+void *
+isc_mem_gettag(isc_mem_t *ctx);
+/*%<
+ * Get the tag value for  'task', as previously set using isc_mem_setname().
+ *
+ * Requires:
+ *\li	'ctx' is a valid ctx.
+ *
+ * Notes:
+ *\li	This function is for debugging purposes only.
+ *
+ * Requires:
+ *\li	'ctx' is a valid task.
+ */
+
+#ifdef HAVE_LIBXML2
+void
+isc_mem_renderxml(xmlTextWriterPtr writer);
+/*%<
+ * Render all contexts' statistics and status in XML for writer.
+ */
+#endif /* HAVE_LIBXML2 */
+
 /*
  * Memory pools
  */
@@ -451,7 +513,7 @@ isc_mempool_associatelock(isc_mempool_t *mpctx, isc_mutex_t *lock);
  * and it is also used to set or get internal state via the isc_mempool_get*()
  * and isc_mempool_set*() set of functions.
  *
- * Mutiple pools can each share a single lock.  For instance, if "manager"
+ * Multiple pools can each share a single lock.  For instance, if "manager"
  * type object contained pools for various sizes of events, and each of
  * these pools used a common lock.  Note that this lock must NEVER be used
  * by other than mempool routines once it is given to a pool, since that can
@@ -551,6 +613,8 @@ void
 isc__mem_put(isc_mem_t *, void *, size_t _ISC_MEM_FLARG);
 void *
 isc__mem_allocate(isc_mem_t *, size_t _ISC_MEM_FLARG);
+void *
+isc__mem_reallocate(isc_mem_t *, void *, size_t _ISC_MEM_FLARG);
 void
 isc__mem_free(isc_mem_t *, void * _ISC_MEM_FLARG);
 char *
diff --git a/contrib/bind9/lib/isc/include/isc/msgcat.h b/contrib/bind9/lib/isc/include/isc/msgcat.h
index 813b57c..fe3d336 100644
--- a/contrib/bind9/lib/isc/include/isc/msgcat.h
+++ b/contrib/bind9/lib/isc/include/isc/msgcat.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: msgcat.h,v 1.9.18.2 2005/04/29 00:16:59 marka Exp $ */
+/* $Id: msgcat.h,v 1.13 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_MSGCAT_H
 #define ISC_MSGCAT_H 1
diff --git a/contrib/bind9/lib/isc/include/isc/msgs.h b/contrib/bind9/lib/isc/include/isc/msgs.h
index 0970647..d8f2787 100644
--- a/contrib/bind9/lib/isc/include/isc/msgs.h
+++ b/contrib/bind9/lib/isc/include/isc/msgs.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: msgs.h,v 1.9.18.4 2008/08/08 06:27:56 tbox Exp $ */
+/* $Id: msgs.h,v 1.17 2008/08/08 06:28:59 tbox Exp $ */
 
 #ifndef ISC_MSGS_H
 #define ISC_MSGS_H 1
 
-/*! \file */
+/*! \file isc/msgs.h */
 
 #include <isc/lib.h>		/* Provide isc_msgcat global variable. */
 #include <isc/msgcat.h>		/* Provide isc_msgcat_*() functions. */
diff --git a/contrib/bind9/lib/isc/include/isc/mutexblock.h b/contrib/bind9/lib/isc/include/isc/mutexblock.h
index fa244c9..65bf2bf 100644
--- a/contrib/bind9/lib/isc/include/isc/mutexblock.h
+++ b/contrib/bind9/lib/isc/include/isc/mutexblock.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: mutexblock.h,v 1.11.18.2 2005/04/29 00:17:00 marka Exp $ */
+/* $Id: mutexblock.h,v 1.17 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_MUTEXBLOCK_H
 #define ISC_MUTEXBLOCK_H 1
 
-/*! \file */
+/*! \file isc/mutexblock.h */
 
 #include <isc/lang.h>
 #include <isc/mutex.h>
diff --git a/contrib/bind9/lib/isc/include/isc/netaddr.h b/contrib/bind9/lib/isc/include/isc/netaddr.h
index 06d063e..8bfdbce 100644
--- a/contrib/bind9/lib/isc/include/isc/netaddr.h
+++ b/contrib/bind9/lib/isc/include/isc/netaddr.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: netaddr.h,v 1.25.18.5 2005/07/28 04:58:47 marka Exp $ */
+/* $Id: netaddr.h,v 1.35.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef ISC_NETADDR_H
 #define ISC_NETADDR_H 1
 
-/*! \file */
+/*! \file isc/netaddr.h */
 
 #include <isc/lang.h>
 #include <isc/net.h>
@@ -36,7 +36,7 @@ ISC_LANG_BEGINDECLS
 struct isc_netaddr {
 	unsigned int family;
 	union {
-    		struct in_addr in;
+		struct in_addr in;
 		struct in6_addr in6;
 #ifdef ISC_PLATFORM_HAVESYSUNH
 		char un[sizeof(((struct sockaddr_un *)0)->sun_path)];
@@ -48,13 +48,18 @@ struct isc_netaddr {
 isc_boolean_t
 isc_netaddr_equal(const isc_netaddr_t *a, const isc_netaddr_t *b);
 
+/*%<
+ * Compare network addresses 'a' and 'b'.  Return #ISC_TRUE if
+ * they are equal, #ISC_FALSE if not.
+ */
+
 isc_boolean_t
 isc_netaddr_eqprefix(const isc_netaddr_t *a, const isc_netaddr_t *b,
 		     unsigned int prefixlen);
 /*%<
  * Compare the 'prefixlen' most significant bits of the network
- * addresses 'a' and 'b'.  Return #ISC_TRUE if they are equal,
- * #ISC_FALSE if not.
+ * addresses 'a' and 'b'.  If 'b''s scope is zero then 'a''s scope is
+ * ignored.  Return #ISC_TRUE if they are equal, #ISC_FALSE if not.
  */
 
 isc_result_t
@@ -166,7 +171,7 @@ isc_netaddr_prefixok(const isc_netaddr_t *na, unsigned int prefixlen);
  * Returns:
  *	ISC_R_SUCCESS
  *	ISC_R_RANGE		prefixlen out of range
- *	ISC_R_NOTIMPLENTED	unsupported family
+ *	ISC_R_NOTIMPLEMENTED	unsupported family
  *	ISC_R_FAILURE		extra bits.
  */
 
diff --git a/contrib/bind9/lib/isc/include/isc/netscope.h b/contrib/bind9/lib/isc/include/isc/netscope.h
index d9bea54..ba4e792 100644
--- a/contrib/bind9/lib/isc/include/isc/netscope.h
+++ b/contrib/bind9/lib/isc/include/isc/netscope.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: netscope.h,v 1.5.18.2 2005/04/29 00:17:00 marka Exp $ */
+/* $Id: netscope.h,v 1.11 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_NETSCOPE_H
 #define ISC_NETSCOPE_H 1
 
-/*! \file */
+/*! \file isc/netscope.h */
 
 ISC_LANG_BEGINDECLS
 
diff --git a/contrib/bind9/lib/isc/include/isc/ondestroy.h b/contrib/bind9/lib/isc/include/isc/ondestroy.h
index 035873c..64bd643 100644
--- a/contrib/bind9/lib/isc/include/isc/ondestroy.h
+++ b/contrib/bind9/lib/isc/include/isc/ondestroy.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ondestroy.h,v 1.8.18.2 2005/04/29 00:17:00 marka Exp $ */
+/* $Id: ondestroy.h,v 1.14 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_ONDESTROY_H
 #define ISC_ONDESTROY_H 1
@@ -25,7 +25,7 @@
 
 ISC_LANG_BEGINDECLS
 
-/*! \file 
+/*! \file isc/ondestroy.h
  * ondestroy handling.
  *
  * Any class ``X'' of objects that wants to send out notifications
diff --git a/contrib/bind9/lib/isc/include/isc/os.h b/contrib/bind9/lib/isc/include/isc/os.h
index b2b76d5..3cf59e2 100644
--- a/contrib/bind9/lib/isc/include/isc/os.h
+++ b/contrib/bind9/lib/isc/include/isc/os.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: os.h,v 1.6.18.2 2005/04/29 00:17:00 marka Exp $ */
+/* $Id: os.h,v 1.12 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_OS_H
 #define ISC_OS_H 1
 
-/*! \file */
+/*! \file isc/os.h */
 
 #include <isc/lang.h>
 
diff --git a/contrib/bind9/lib/isc/include/isc/parseint.h b/contrib/bind9/lib/isc/include/isc/parseint.h
index 6940add..5047676 100644
--- a/contrib/bind9/lib/isc/include/isc/parseint.h
+++ b/contrib/bind9/lib/isc/include/isc/parseint.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001, 2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: parseint.h,v 1.3.18.2 2005/04/29 00:17:00 marka Exp $ */
+/* $Id: parseint.h,v 1.9 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_PARSEINT_H
 #define ISC_PARSEINT_H 1
@@ -23,7 +23,7 @@
 #include <isc/lang.h>
 #include <isc/types.h>
 
-/*! \file
+/*! \file isc/parseint.h
  * \brief Parse integers, in a saner way than atoi() or strtoul() do.
  */
 
diff --git a/contrib/bind9/lib/isc/include/isc/platform.h.in b/contrib/bind9/lib/isc/include/isc/platform.h.in
index afcd4df..1ed76b8 100644
--- a/contrib/bind9/lib/isc/include/isc/platform.h.in
+++ b/contrib/bind9/lib/isc/include/isc/platform.h.in
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: platform.h.in,v 1.34.18.11 2008/06/24 23:45:55 tbox Exp $ */
+/* $Id: platform.h.in,v 1.48.84.2 2009/02/16 23:47:15 tbox Exp $ */
 
 #ifndef ISC_PLATFORM_H
 #define ISC_PLATFORM_H 1
@@ -26,11 +26,6 @@
  ***** Platform-dependent defines.
  *****/
 
-/*
- * Define if the platform has <strings.h>.
- */
-@ISC_PLATFORM_HAVESTRINGSH@
-
 /***
  *** Network.
  ***/
@@ -99,29 +94,26 @@
 @ISC_PLATFORM_NEEDPTON@
 
 /*! \brief
- * If this system needs inet_aton(), ISC_PLATFORM_NEEDATON will be defined.
- */
-@ISC_PLATFORM_NEEDATON@
-
-/*! \brief
  * If this system needs in_port_t, ISC_PLATFORM_NEEDPORTT will be defined.
  */
 @ISC_PLATFORM_NEEDPORTT@
 
 /*! \brief
- * If the system needs strsep(), ISC_PLATFORM_NEEDSTRSEP will be defined.
+ * Define if the system has struct lifconf which is a extended struct ifconf
+ * for IPv6.
  */
-@ISC_PLATFORM_NEEDSTRSEP@
+@ISC_PLATFORM_HAVELIFCONF@
 
 /*! \brief
- * If the system needs strlcpy(), ISC_PLATFORM_NEEDSTRLCPY will be defined.
+ * Define if the system has struct if_laddrconf which is a extended struct
+ * ifconf for IPv6.
  */
-@ISC_PLATFORM_NEEDSTRLCPY@
+@ISC_PLATFORM_HAVEIF_LADDRCONF@
 
 /*! \brief
- * If the system needs strlcat(), ISC_PLATFORM_NEEDSTRLCAT will be defined.
+ * Define if the system has struct if_laddrreq.
  */
-@ISC_PLATFORM_NEEDSTRLCAT@
+@ISC_PLATFORM_HAVEIF_LADDRREQ@
 
 /*! \brief
  * Define either ISC_PLATFORM_BSD44MSGHDR or ISC_PLATFORM_BSD43MSGHDR.
@@ -129,10 +121,9 @@
 @ISC_PLATFORM_MSGHDRFLAVOR@
 
 /*! \brief
- * Define if PTHREAD_ONCE_INIT should be surrounded by braces to
- * prevent compiler warnings (such as with gcc on Solaris 2.8).
+ * Define if the system supports if_nametoindex.
  */
-@ISC_PLATFORM_BRACEPTHREADONCEINIT@
+@ISC_PLATFORM_HAVEIFNAMETOINDEX@
 
 /*! \brief
  * Define on some UnixWare systems to fix erroneous definitions of various
@@ -175,62 +166,74 @@
  */
 @ISC_PLATFORM_QUADFORMAT@
 
-/*! \brief
- * Defined if we are using threads.
+/***
+ *** String functions.
+ ***/
+/*
+ * If the system needs strsep(), ISC_PLATFORM_NEEDSTRSEP will be defined.
  */
-@ISC_PLATFORM_USETHREADS@
+@ISC_PLATFORM_NEEDSTRSEP@
 
-/*! \brief
- * Defined if unistd.h does not cause fd_set to be delared.
+/*
+ * If the system needs strlcpy(), ISC_PLATFORM_NEEDSTRLCPY will be defined.
  */
-@ISC_PLATFORM_NEEDSYSSELECTH@
+@ISC_PLATFORM_NEEDSTRLCPY@
 
-/*! \brief
- * Type used for resource limits.
+/*
+ * If the system needs strlcat(), ISC_PLATFORM_NEEDSTRLCAT will be defined.
  */
-@ISC_PLATFORM_RLIMITTYPE@
+@ISC_PLATFORM_NEEDSTRLCAT@
 
-/*! \brief
- * Define if your compiler supports "long long int".
+/*
+ * Define if this system needs strtoul.
  */
-@ISC_PLATFORM_HAVELONGLONG@
+@ISC_PLATFORM_NEEDSTRTOUL@
 
-/*! \brief
- * Define if the system has struct lifconf which is a extended struct ifconf
- * for IPv6.
+/*
+ * Define if this system needs memmove.
  */
-@ISC_PLATFORM_HAVELIFCONF@
+@ISC_PLATFORM_NEEDMEMMOVE@
 
-/*! \brief
- * Define if the system has struct if_laddrconf which is a extended struct
- * ifconf for IPv6.
+/***
+ *** Miscellaneous.
+ ***/
+
+/*
+ * Defined if we are using threads.
  */
-@ISC_PLATFORM_HAVEIF_LADDRCONF@
+@ISC_PLATFORM_USETHREADS@
 
-/*! \brief
- * Define if the system has struct if_laddrreq.
+/*
+ * Defined if unistd.h does not cause fd_set to be delared.
  */
-@ISC_PLATFORM_HAVEIF_LADDRREQ@
+@ISC_PLATFORM_NEEDSYSSELECTH@
 
-/*! \brief
- * Used to control how extern data is linked; needed for Win32 platforms.
+/*
+ * Defined to <gssapi.h> or <gssapi/gssapi.h> for how to include
+ * the GSSAPI header.
  */
-@ISC_PLATFORM_USEDECLSPEC@
+@ISC_PLATFORM_GSSAPIHEADER@
 
-/*! \brief
- * Define if the system supports if_nametoindex.
+/*
+ * Type used for resource limits.
  */
-@ISC_PLATFORM_HAVEIFNAMETOINDEX@
+@ISC_PLATFORM_RLIMITTYPE@
 
-/*! \brief
- * Define if this system needs strtoul.
+/*
+ * Define if your compiler supports "long long int".
  */
-@ISC_PLATFORM_NEEDSTRTOUL@
+@ISC_PLATFORM_HAVELONGLONG@
 
-/*! \brief
- * Define if this system needs memmove.
+/*
+ * Define if PTHREAD_ONCE_INIT should be surrounded by braces to
+ * prevent compiler warnings (such as with gcc on Solaris 2.8).
  */
-@ISC_PLATFORM_NEEDMEMMOVE@
+@ISC_PLATFORM_BRACEPTHREADONCEINIT@
+
+/*
+ * Used to control how extern data is linked; needed for Win32 platforms.
+ */
+@ISC_PLATFORM_USEDECLSPEC@
 
 /*
  * Define if the platform has <sys/un.h>.
@@ -244,6 +247,12 @@
 @ISC_PLATFORM_HAVEXADD@
 
 /*
+ * If the "xaddq" operation (64bit xadd) is available on this architecture,
+ * ISC_PLATFORM_HAVEXADDQ will be defined.
+ */
+@ISC_PLATFORM_HAVEXADDQ@
+
+/*
  * If the "atomic swap" operation is available on this architecture,
  * ISC_PLATFORM_HAVEATOMICSTORE" will be defined.
  */
@@ -271,6 +280,15 @@
 @ISC_PLATFORM_USESTDASM@
 
 /*
+ * Define if the platform has <strings.h>.
+ */
+@ISC_PLATFORM_HAVESTRINGSH@
+
+/***
+ ***	Windows dll support.
+ ***/
+
+/*
  * Define if MacOS style of PPC assembly must be used.
  * e.g. "r6", not "6", for register six.
  */
diff --git a/contrib/bind9/lib/isc/include/isc/portset.h b/contrib/bind9/lib/isc/include/isc/portset.h
index 6396e5c..dc1f856 100644
--- a/contrib/bind9/lib/isc/include/isc/portset.h
+++ b/contrib/bind9/lib/isc/include/isc/portset.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2008, 2009  Internet Systems Consortium, Inc. ("ISC")
  *
  * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
@@ -14,10 +14,10 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: portset.h,v 1.3.4.1 2008/06/24 03:42:10 marka Exp $ */
+/* $Id: portset.h,v 1.3.90.2 2009/01/18 23:47:41 tbox Exp $ */
 
 /*! \file isc/portset.h
- * \brief Transport Protocol Port Manipuration Module
+ * \brief Transport Protocol Port Manipulation Module
  *
  * This module provides simple utilities to handle a set of transport protocol
  * (UDP or TCP) port numbers, e.g., for creating an ACL list.  An isc_portset_t
diff --git a/contrib/bind9/lib/isc/include/isc/print.h b/contrib/bind9/lib/isc/include/isc/print.h
index 95c6b1c..cd1e38e 100644
--- a/contrib/bind9/lib/isc/include/isc/print.h
+++ b/contrib/bind9/lib/isc/include/isc/print.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: print.h,v 1.19.18.3 2005/06/08 02:07:56 marka Exp $ */
+/* $Id: print.h,v 1.26 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_PRINT_H
 #define ISC_PRINT_H 1
 
-/*! \file */
+/*! \file isc/print.h */
 
 /***
  *** Imports
diff --git a/contrib/bind9/lib/isc/include/isc/quota.h b/contrib/bind9/lib/isc/include/isc/quota.h
index 6f95cd5..7b0d0d9 100644
--- a/contrib/bind9/lib/isc/include/isc/quota.h
+++ b/contrib/bind9/lib/isc/include/isc/quota.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: quota.h,v 1.10.18.4 2005/08/11 15:01:54 marka Exp $ */
+/* $Id: quota.h,v 1.16 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_QUOTA_H
 #define ISC_QUOTA_H 1
diff --git a/contrib/bind9/lib/isc/include/isc/radix.h b/contrib/bind9/lib/isc/include/isc/radix.h
new file mode 100644
index 0000000..fbb1893
--- /dev/null
+++ b/contrib/bind9/lib/isc/include/isc/radix.h
@@ -0,0 +1,240 @@
+/*
+ * Copyright (C) 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or 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: radix.h,v 1.11.44.2 2008/12/24 23:47:02 tbox Exp $ */
+
+/*
+ * This source was adapted from MRT's RCS Ids:
+ * Id: radix.h,v 1.6 1999/08/03 03:32:53 masaki Exp
+ * Id: mrt.h,v 1.57.2.6 1999/12/28 23:41:27 labovit Exp
+ * Id: defs.h,v 1.5.2.2 2000/01/15 14:19:16 masaki Exp
+ */
+
+#include <isc/magic.h>
+#include <isc/types.h>
+#include <isc/mutex.h>
+#include <isc/net.h>
+#include <isc/refcount.h>
+
+#include <string.h>
+
+#ifndef _RADIX_H
+#define _RADIX_H
+
+#define NETADDR_TO_PREFIX_T(na,pt,bits) \
+	do { \
+		memset(&(pt), 0, sizeof(pt)); \
+		if((na) != NULL) { \
+			(pt).family = (na)->family; \
+			(pt).bitlen = (bits); \
+			if ((pt).family == AF_INET6) { \
+				memcpy(&(pt).add.sin6, &(na)->type.in6, \
+				       ((bits)+7)/8); \
+			} else \
+				memcpy(&(pt).add.sin, &(na)->type.in, \
+				       ((bits)+7)/8); \
+		} else { \
+			(pt).family = AF_UNSPEC; \
+			(pt).bitlen = 0; \
+		} \
+		isc_refcount_init(&(pt).refcount, 0); \
+	} while(0)
+
+typedef struct isc_prefix {
+    unsigned int family;	/* AF_INET | AF_INET6, or AF_UNSPEC for "any" */
+    unsigned int bitlen;	/* 0 for "any" */
+    isc_refcount_t refcount;
+    union {
+		struct in_addr sin;
+		struct in6_addr sin6;
+    } add;
+} isc_prefix_t;
+
+typedef void (*isc_radix_destroyfunc_t)(void *);
+typedef void (*isc_radix_processfunc_t)(isc_prefix_t *, void **);
+
+#define isc_prefix_tochar(prefix) ((char *)&(prefix)->add.sin)
+#define isc_prefix_touchar(prefix) ((u_char *)&(prefix)->add.sin)
+
+#define BIT_TEST(f, b)  ((f) & (b))
+
+/*
+ * We need "first match" when we search the radix tree to preserve
+ * compatibility with the existing ACL implementation. Radix trees
+ * naturally lend themselves to "best match". In order to get "first match"
+ * behavior, we keep track of the order in which entries are added to the
+ * tree--and when a search is made, we find all matching entries, and
+ * return the one that was added first.
+ *
+ * An IPv4 prefix and an IPv6 prefix may share a radix tree node if they
+ * have the same length and bit pattern (e.g., 127/8 and 7f::/8).  To
+ * disambiguate between them, node_num and data are two-element arrays;
+ * node_num[0] and data[0] are used for IPv4 addresses, node_num[1]
+ * and data[1] for IPv6 addresses.  The only exception is a prefix of
+ * 0/0 (aka "any" or "none"), which is always stored as IPv4 but matches
+ * IPv6 addresses too.
+ */
+
+#define ISC_IS6(family) ((family) == AF_INET6 ? 1 : 0)
+typedef struct isc_radix_node {
+   isc_uint32_t bit;			/* bit length of the prefix */
+   isc_prefix_t *prefix;		/* who we are in radix tree */
+   struct isc_radix_node *l, *r;	/* left and right children */
+   struct isc_radix_node *parent;	/* may be used */
+   void *data[2];			/* pointers to IPv4 and IPV6 data */
+   int node_num[2];			/* which node this was in the tree,
+					   or -1 for glue nodes */
+} isc_radix_node_t;
+
+#define RADIX_TREE_MAGIC         ISC_MAGIC('R','d','x','T');
+#define RADIX_TREE_VALID(a)      ISC_MAGIC_VALID(a, RADIX_TREE_MAGIC);
+
+typedef struct isc_radix_tree {
+   unsigned int		magic;
+   isc_mem_t		*mctx;
+   isc_radix_node_t 	*head;
+   isc_uint32_t		maxbits;	/* for IP, 32 bit addresses */
+   int num_active_node;			/* for debugging purposes */
+   int num_added_node;			/* total number of nodes */
+} isc_radix_tree_t;
+
+isc_result_t
+isc_radix_search(isc_radix_tree_t *radix, isc_radix_node_t **target,
+		 isc_prefix_t *prefix);
+/*%<
+ * Search 'radix' for the best match to 'prefix'.
+ * Return the node found in '*target'.
+ *
+ * Requires:
+ * \li	'radix' to be valid.
+ * \li	'target' is not NULL and "*target" is NULL.
+ * \li	'prefix' to be valid.
+ *
+ * Returns:
+ * \li	ISC_R_NOTFOUND
+ * \li	ISC_R_SUCCESS
+ */
+
+isc_result_t
+isc_radix_insert(isc_radix_tree_t *radix, isc_radix_node_t **target,
+		 isc_radix_node_t *source, isc_prefix_t *prefix);
+/*%<
+ * Insert 'source' or 'prefix' into the radix tree 'radix'.
+ * Return the node added in 'target'.
+ *
+ * Requires:
+ * \li	'radix' to be valid.
+ * \li	'target' is not NULL and "*target" is NULL.
+ * \li	'prefix' to be valid or 'source' to be non NULL and contain
+ *	a valid prefix.
+ *
+ * Returns:
+ * \li	ISC_R_NOMEMORY
+ * \li	ISC_R_SUCCESS
+ */
+
+void
+isc_radix_remove(isc_radix_tree_t *radix, isc_radix_node_t *node);
+/*%<
+ * Remove the node 'node' from the radix tree 'radix'.
+ *
+ * Requires:
+ * \li	'radix' to be valid.
+ * \li	'node' to be valid.
+ */
+
+isc_result_t
+isc_radix_create(isc_mem_t *mctx, isc_radix_tree_t **target, int maxbits);
+/*%<
+ * Create a radix tree with a maximum depth of 'maxbits';
+ *
+ * Requires:
+ * \li	'mctx' to be valid.
+ * \li	'target' to be non NULL and '*target' to be NULL.
+ * \li	'maxbits' to be less than or equal to RADIX_MAXBITS.
+ *
+ * Returns:
+ * \li	ISC_R_NOMEMORY
+ * \li	ISC_R_SUCCESS
+ */
+
+void
+isc_radix_destroy(isc_radix_tree_t *radix, isc_radix_destroyfunc_t func);
+/*%<
+ * Destroy a radix tree optionally calling 'func' to clean up node data.
+ *
+ * Requires:
+ * \li	'radix' to be valid.
+ */
+
+void
+isc_radix_process(isc_radix_tree_t *radix, isc_radix_processfunc_t func);
+/*%<
+ * Walk a radix tree calling 'func' to process node data.
+ *
+ * Requires:
+ * \li	'radix' to be valid.
+ * \li	'func' to point to a function.
+ */
+
+#define RADIX_MAXBITS 128
+#define RADIX_NBIT(x)        (0x80 >> ((x) & 0x7f))
+#define RADIX_NBYTE(x)       ((x) >> 3)
+
+#define RADIX_DATA_GET(node, type) (type *)((node)->data)
+#define RADIX_DATA_SET(node, value) ((node)->data = (void *)(value))
+
+#define RADIX_WALK(Xhead, Xnode) \
+    do { \
+	isc_radix_node_t *Xstack[RADIX_MAXBITS+1]; \
+	isc_radix_node_t **Xsp = Xstack; \
+	isc_radix_node_t *Xrn = (Xhead); \
+	while ((Xnode = Xrn)) { \
+	    if (Xnode->prefix)
+
+#define RADIX_WALK_ALL(Xhead, Xnode) \
+do { \
+	isc_radix_node_t *Xstack[RADIX_MAXBITS+1]; \
+	isc_radix_node_t **Xsp = Xstack; \
+	isc_radix_node_t *Xrn = (Xhead); \
+	while ((Xnode = Xrn)) { \
+	    if (1)
+
+#define RADIX_WALK_BREAK { \
+	    if (Xsp != Xstack) { \
+		Xrn = *(--Xsp); \
+	     } else { \
+		Xrn = (radix_node_t *) 0; \
+	    } \
+	    continue; }
+
+#define RADIX_WALK_END \
+	    if (Xrn->l) { \
+		if (Xrn->r) { \
+		    *Xsp++ = Xrn->r; \
+		} \
+		Xrn = Xrn->l; \
+	    } else if (Xrn->r) { \
+		Xrn = Xrn->r; \
+	    } else if (Xsp != Xstack) { \
+		Xrn = *(--Xsp); \
+	    } else { \
+		Xrn = (isc_radix_node_t *) 0; \
+	    } \
+	} \
+    } while (0)
+
+#endif /* _RADIX_H */
diff --git a/contrib/bind9/lib/isc/include/isc/random.h b/contrib/bind9/lib/isc/include/isc/random.h
index c5cef8b..9b6ca64 100644
--- a/contrib/bind9/lib/isc/include/isc/random.h
+++ b/contrib/bind9/lib/isc/include/isc/random.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: random.h,v 1.12.18.2 2005/04/29 00:17:01 marka Exp $ */
+/* $Id: random.h,v 1.18.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef ISC_RANDOM_H
 #define ISC_RANDOM_H 1
@@ -23,9 +23,9 @@
 #include <isc/lang.h>
 #include <isc/types.h>
 
-/*! \file
+/*! \file isc/random.h
  * \brief Implements a random state pool which will let the caller return a
- * series of possibly non-reproducable random values.  
+ * series of possibly non-reproducible random values.
  *
  * Note that the
  * strength of these numbers is not all that high, and should not be
diff --git a/contrib/bind9/lib/isc/include/isc/ratelimiter.h b/contrib/bind9/lib/isc/include/isc/ratelimiter.h
index 1944754..d18cf25 100644
--- a/contrib/bind9/lib/isc/include/isc/ratelimiter.h
+++ b/contrib/bind9/lib/isc/include/isc/ratelimiter.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ratelimiter.h,v 1.15.18.2 2005/04/29 00:17:01 marka Exp $ */
+/* $Id: ratelimiter.h,v 1.21.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef ISC_RATELIMITER_H
 #define ISC_RATELIMITER_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file isc/ratelimiter.h
  * \brief A rate limiter is a mechanism for dispatching events at a limited
  * rate.  This is intended to be used when sending zone maintenance
  * SOA queries, NOTIFY messages, etc.
@@ -53,7 +53,7 @@ isc_ratelimiter_create(isc_mem_t *mctx, isc_timermgr_t *timermgr,
 isc_result_t
 isc_ratelimiter_setinterval(isc_ratelimiter_t *rl, isc_interval_t *interval);
 /*!<
- * Set the mininum interval between event executions.
+ * Set the minimum interval between event executions.
  * The interval value is copied, so the caller need not preserve it.
  *
  * Requires:
@@ -71,7 +71,7 @@ isc_result_t
 isc_ratelimiter_enqueue(isc_ratelimiter_t *rl, isc_task_t *task,
 			isc_event_t **eventp);
 /*%<
- * Queue an event for rate-limited execution.  
+ * Queue an event for rate-limited execution.
  *
  * This is similar
  * to doing an isc_task_send() to the 'task', except that the
@@ -102,7 +102,7 @@ isc_ratelimiter_shutdown(isc_ratelimiter_t *ratelimiter);
  *\li	Further attempts to enqueue events will fail with
  * 	#ISC_R_SHUTTINGDOWN.
  *
- *\li	The reatelimiter is no longer attached to its task.
+ *\li	The rate limiter is no longer attached to its task.
  */
 
 void
diff --git a/contrib/bind9/lib/isc/include/isc/refcount.h b/contrib/bind9/lib/isc/include/isc/refcount.h
index b930465..6ab14ae 100644
--- a/contrib/bind9/lib/isc/include/isc/refcount.h
+++ b/contrib/bind9/lib/isc/include/isc/refcount.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: refcount.h,v 1.6.18.5 2005/07/12 01:22:31 marka Exp $ */
+/* $Id: refcount.h,v 1.15 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_REFCOUNT_H
 #define ISC_REFCOUNT_H 1
@@ -27,7 +27,7 @@
 #include <isc/types.h>
 #include <isc/util.h>
 
-/*! \file
+/*! \file isc/refcount.h
  * \brief Implements a locked reference counter.  
  *
  * These functions may actually be
diff --git a/contrib/bind9/lib/isc/include/isc/region.h b/contrib/bind9/lib/isc/include/isc/region.h
index 9b651fe..43d8f8f 100644
--- a/contrib/bind9/lib/isc/include/isc/region.h
+++ b/contrib/bind9/lib/isc/include/isc/region.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: region.h,v 1.19.18.2 2005/04/29 00:17:01 marka Exp $ */
+/* $Id: region.h,v 1.25 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_REGION_H
 #define ISC_REGION_H 1
 
-/*! \file */
+/*! \file isc/region.h */
 
 #include <isc/types.h>
 
diff --git a/contrib/bind9/lib/isc/include/isc/resource.h b/contrib/bind9/lib/isc/include/isc/resource.h
index 8c33c89..747c9fd 100644
--- a/contrib/bind9/lib/isc/include/isc/resource.h
+++ b/contrib/bind9/lib/isc/include/isc/resource.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: resource.h,v 1.5.18.4 2008/08/01 23:45:58 tbox Exp $ */
+/* $Id: resource.h,v 1.13 2008/07/11 23:47:09 tbox Exp $ */
 
 #ifndef ISC_RESOURCE_H
 #define ISC_RESOURCE_H 1
 
-/*! \file */
+/*! \file isc/resource.h */
 
 #include <isc/lang.h>
 #include <isc/types.h>
diff --git a/contrib/bind9/lib/isc/include/isc/result.h b/contrib/bind9/lib/isc/include/isc/result.h
index 0de3493..56b4ca6 100644
--- a/contrib/bind9/lib/isc/include/isc/result.h
+++ b/contrib/bind9/lib/isc/include/isc/result.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,11 +15,13 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: result.h,v 1.62.18.4 2005/06/22 22:05:49 marka Exp $ */
+/* $Id: result.h,v 1.71 2008/09/25 04:02:39 tbox Exp $ */
 
 #ifndef ISC_RESULT_H
 #define ISC_RESULT_H 1
 
+/*! \file isc/result.h */
+
 #include <isc/lang.h>
 #include <isc/types.h>
 
@@ -83,9 +85,10 @@
 #define ISC_R_DISABLED			57	/*%< disabled */
 #define ISC_R_MAXSIZE			58	/*%< max size */
 #define ISC_R_BADADDRESSFORM		59	/*%< invalid address format */
+#define ISC_R_BADBASE32			60	/*%< bad base32 encoding */
 
 /*% Not a result code: the number of results. */
-#define ISC_R_NRESULTS 			60
+#define ISC_R_NRESULTS 			61
 
 ISC_LANG_BEGINDECLS
 
diff --git a/contrib/bind9/lib/isc/include/isc/resultclass.h b/contrib/bind9/lib/isc/include/isc/resultclass.h
index 5e20800..b32426f 100644
--- a/contrib/bind9/lib/isc/include/isc/resultclass.h
+++ b/contrib/bind9/lib/isc/include/isc/resultclass.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,13 +15,13 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: resultclass.h,v 1.12.18.2 2005/04/29 00:17:02 marka Exp $ */
+/* $Id: resultclass.h,v 1.18 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_RESULTCLASS_H
 #define ISC_RESULTCLASS_H 1
 
 
-/*! \file
+/*! \file isc/resultclass.h
  * \brief Registry of Predefined Result Type Classes
  *
  * A result class number is an unsigned 16 bit number.  Each class may
diff --git a/contrib/bind9/lib/isc/include/isc/rwlock.h b/contrib/bind9/lib/isc/include/isc/rwlock.h
index 404f93c..28052cd 100644
--- a/contrib/bind9/lib/isc/include/isc/rwlock.h
+++ b/contrib/bind9/lib/isc/include/isc/rwlock.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rwlock.h,v 1.21.18.3 2005/06/04 06:23:44 jinmei Exp $ */
+/* $Id: rwlock.h,v 1.28 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_RWLOCK_H
 #define ISC_RWLOCK_H 1
 
-/*! \file */
+/*! \file isc/rwlock.h */
 
 #include <isc/condition.h>
 #include <isc/lang.h>
diff --git a/contrib/bind9/lib/isc/include/isc/serial.h b/contrib/bind9/lib/isc/include/isc/serial.h
index 86d9b2f..f7e3049 100644
--- a/contrib/bind9/lib/isc/include/isc/serial.h
+++ b/contrib/bind9/lib/isc/include/isc/serial.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: serial.h,v 1.10.18.2 2005/04/29 00:17:02 marka Exp $ */
+/* $Id: serial.h,v 1.16.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef ISC_SERIAL_H
 #define ISC_SERIAL_H 1
@@ -23,8 +23,8 @@
 #include <isc/lang.h>
 #include <isc/types.h>
 
-/*! \file
- *	\brief Implement 32 bit serial space arithmetic comparision functions.
+/*! \file isc/serial.h
+ *	\brief Implement 32 bit serial space arithmetic comparison functions.
  *	Note: Undefined results are returned as ISC_FALSE.
  */
 
diff --git a/contrib/bind9/lib/isc/include/isc/sha1.h b/contrib/bind9/lib/isc/include/isc/sha1.h
index bb22f06..63f12bb 100644
--- a/contrib/bind9/lib/isc/include/isc/sha1.h
+++ b/contrib/bind9/lib/isc/include/isc/sha1.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -18,11 +18,11 @@
 #ifndef ISC_SHA1_H
 #define ISC_SHA1_H 1
 
-/* $Id: sha1.h,v 1.9.18.5 2006/08/16 03:18:14 marka Exp $ */
+/* $Id: sha1.h,v 1.17 2007/06/19 23:47:18 tbox Exp $ */
 
 /*	$NetBSD: sha1.h,v 1.2 1998/05/29 22:55:44 thorpej Exp $	*/
 
-/*! \file
+/*! \file isc/sha1.h
  * \brief SHA-1 in C
  * \author By Steve Reid <steve@edmweb.com>
  * \note 100% Public Domain
diff --git a/contrib/bind9/lib/isc/include/isc/sha2.h b/contrib/bind9/lib/isc/include/isc/sha2.h
index e54c620..211e255 100644
--- a/contrib/bind9/lib/isc/include/isc/sha2.h
+++ b/contrib/bind9/lib/isc/include/isc/sha2.h
@@ -1,7 +1,7 @@
 /*
- * Copyright (C) 2005, 2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2005-2007  Internet Systems Consortium, Inc. ("ISC")
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: sha2.h,v 1.2.2.6 2006/08/16 03:18:14 marka Exp $ */
+/* $Id: sha2.h,v 1.9 2007/06/19 23:47:18 tbox Exp $ */
 
 /*	$FreeBSD$	*/
 /*	$KAME: sha2.h,v 1.3 2001/03/12 08:27:48 itojun Exp $	*/
diff --git a/contrib/bind9/lib/isc/include/isc/sockaddr.h b/contrib/bind9/lib/isc/include/isc/sockaddr.h
index 83412d2..62cc773 100644
--- a/contrib/bind9/lib/isc/include/isc/sockaddr.h
+++ b/contrib/bind9/lib/isc/include/isc/sockaddr.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: sockaddr.h,v 1.42.18.8 2006/03/02 00:37:22 marka Exp $ */
+/* $Id: sockaddr.h,v 1.55.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef ISC_SOCKADDR_H
 #define ISC_SOCKADDR_H 1
 
-/*! \file */
+/*! \file isc/sockaddr.h */
 
 #include <isc/lang.h>
 #include <isc/net.h>
@@ -84,6 +84,7 @@ isc_sockaddr_eqaddrprefix(const isc_sockaddr_t *a, const isc_sockaddr_t *b,
 /*%<
  * Return ISC_TRUE iff the most significant 'prefixlen' bits of the
  * socket addresses 'a' and 'b' are equal, ignoring the ports.
+ * If 'b''s scope is zero then 'a''s scope will be ignored.
  */
 
 unsigned int
@@ -209,7 +210,7 @@ isc_sockaddr_isexperimental(const isc_sockaddr_t *sa);
 isc_boolean_t
 isc_sockaddr_islinklocal(const isc_sockaddr_t *sa);
 /*%<
- * Returns ISC_TRUE if the address is a link local addresss.
+ * Returns ISC_TRUE if the address is a link local address.
  */
 
 isc_boolean_t
diff --git a/contrib/bind9/lib/isc/include/isc/socket.h b/contrib/bind9/lib/isc/include/isc/socket.h
index a9a22c8..035c994 100644
--- a/contrib/bind9/lib/isc/include/isc/socket.h
+++ b/contrib/bind9/lib/isc/include/isc/socket.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: socket.h,v 1.57.18.15 2008/09/04 08:03:08 marka Exp $ */
+/* $Id: socket.h,v 1.85.58.3 2009/01/29 22:40:35 jinmei Exp $ */
 
 #ifndef ISC_SOCKET_H
 #define ISC_SOCKET_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file isc/socket.h
  * \brief Provides TCP and UDP sockets for network I/O.  The sockets are event
  * sources in the task system.
  *
@@ -64,6 +64,7 @@
 #include <isc/time.h>
 #include <isc/region.h>
 #include <isc/sockaddr.h>
+#include <isc/xml.h>
 
 ISC_LANG_BEGINDECLS
 
@@ -83,6 +84,75 @@ ISC_LANG_BEGINDECLS
  */
 #define ISC_SOCKET_REUSEADDRESS		0x01U
 
+/*%
+ * Statistics counters.  Used as isc_statscounter_t values.
+ */
+enum {
+	isc_sockstatscounter_udp4open = 0,
+	isc_sockstatscounter_udp6open = 1,
+	isc_sockstatscounter_tcp4open = 2,
+	isc_sockstatscounter_tcp6open = 3,
+	isc_sockstatscounter_unixopen = 4,
+
+	isc_sockstatscounter_udp4openfail = 5,
+	isc_sockstatscounter_udp6openfail = 6,
+	isc_sockstatscounter_tcp4openfail = 7,
+	isc_sockstatscounter_tcp6openfail = 8,
+	isc_sockstatscounter_unixopenfail = 9,
+
+	isc_sockstatscounter_udp4close = 10,
+	isc_sockstatscounter_udp6close = 11,
+	isc_sockstatscounter_tcp4close = 12,
+	isc_sockstatscounter_tcp6close = 13,
+	isc_sockstatscounter_unixclose = 14,
+	isc_sockstatscounter_fdwatchclose = 15,
+
+	isc_sockstatscounter_udp4bindfail = 16,
+	isc_sockstatscounter_udp6bindfail = 17,
+	isc_sockstatscounter_tcp4bindfail = 18,
+	isc_sockstatscounter_tcp6bindfail = 19,
+	isc_sockstatscounter_unixbindfail = 20,
+	isc_sockstatscounter_fdwatchbindfail = 21,
+
+	isc_sockstatscounter_udp4connect = 22,
+	isc_sockstatscounter_udp6connect = 23,
+	isc_sockstatscounter_tcp4connect = 24,
+	isc_sockstatscounter_tcp6connect = 25,
+	isc_sockstatscounter_unixconnect = 26,
+	isc_sockstatscounter_fdwatchconnect = 27,
+
+	isc_sockstatscounter_udp4connectfail = 28,
+	isc_sockstatscounter_udp6connectfail = 29,
+	isc_sockstatscounter_tcp4connectfail = 30,
+	isc_sockstatscounter_tcp6connectfail = 31,
+	isc_sockstatscounter_unixconnectfail = 32,
+	isc_sockstatscounter_fdwatchconnectfail = 33,
+
+	isc_sockstatscounter_tcp4accept = 34,
+	isc_sockstatscounter_tcp6accept = 35,
+	isc_sockstatscounter_unixaccept = 36,
+
+	isc_sockstatscounter_tcp4acceptfail = 37,
+	isc_sockstatscounter_tcp6acceptfail = 38,
+	isc_sockstatscounter_unixacceptfail = 39,
+
+	isc_sockstatscounter_udp4sendfail = 40,
+	isc_sockstatscounter_udp6sendfail = 41,
+	isc_sockstatscounter_tcp4sendfail = 42,
+	isc_sockstatscounter_tcp6sendfail = 43,
+	isc_sockstatscounter_unixsendfail = 44,
+	isc_sockstatscounter_fdwatchsendfail = 45,
+
+	isc_sockstatscounter_udp4recvfail = 46,
+	isc_sockstatscounter_udp6recvfail = 47,
+	isc_sockstatscounter_tcp4recvfail = 48,
+	isc_sockstatscounter_tcp6recvfail = 49,
+	isc_sockstatscounter_unixrecvfail = 50,
+	isc_sockstatscounter_fdwatchrecvfail = 51,
+
+	isc_sockstatscounter_max = 52
+};
+
 /***
  *** Types
  ***/
@@ -150,7 +220,8 @@ struct isc_socket_connev {
 typedef enum {
 	isc_sockettype_udp = 1,
 	isc_sockettype_tcp = 2,
-	isc_sockettype_unix = 3
+	isc_sockettype_unix = 3,
+	isc_sockettype_fdwatch = 4
 } isc_sockettype_t;
 
 /*@{*/
@@ -181,6 +252,14 @@ typedef enum {
 #define ISC_SOCKFLAG_NORETRY	0x00000002	/*%< drop failed UDP sends */
 /*@}*/
 
+/*@{*/
+/*!
+ * Flags for fdwatchcreate.
+ */
+#define ISC_SOCKFDWATCH_READ	0x00000001	/*%< watch for readable */
+#define ISC_SOCKFDWATCH_WRITE	0x00000002	/*%< watch for writable */
+/*@}*/
+
 /***
  *** Socket and Socket Manager Functions
  ***
@@ -189,6 +268,45 @@ typedef enum {
  ***/
 
 isc_result_t
+isc_socket_fdwatchcreate(isc_socketmgr_t *manager,
+			 int fd,
+			 int flags,
+			 isc_sockfdwatch_t callback,
+			 void *cbarg,
+			 isc_task_t *task,
+			 isc_socket_t **socketp);
+/*%<
+ * Create a new file descriptor watch socket managed by 'manager'.
+ *
+ * Note:
+ *
+ *\li   'fd' is the already-opened file descriptor.
+ *\li	This function is not available on Windows.
+ *\li	The callback function is called "in-line" - this means the function
+ *	needs to return as fast as possible, as all other I/O will be suspended
+ *	until the callback completes.
+ *
+ * Requires:
+ *
+ *\li	'manager' is a valid manager
+ *
+ *\li	'socketp' is a valid pointer, and *socketp == NULL
+ *
+ *\li	'fd' be opened.
+ *
+ * Ensures:
+ *
+ *	'*socketp' is attached to the newly created fdwatch socket
+ *
+ * Returns:
+ *
+ *\li	#ISC_R_SUCCESS
+ *\li	#ISC_R_NOMEMORY
+ *\li	#ISC_R_NORESOURCES
+ *\li	#ISC_R_UNEXPECTED
+ */
+
+isc_result_t
 isc_socket_create(isc_socketmgr_t *manager,
 		  int pf,
 		  isc_sockettype_t type,
@@ -196,6 +314,9 @@ isc_socket_create(isc_socketmgr_t *manager,
 /*%<
  * Create a new 'type' socket managed by 'manager'.
  *
+ * For isc_sockettype_fdwatch sockets you should use isc_socket_fdwatchcreate()
+ * rather than isc_socket_create().
+ *
  * Note:
  *
  *\li	'pf' is the desired protocol family, e.g. PF_INET or PF_INET6.
@@ -206,6 +327,8 @@ isc_socket_create(isc_socketmgr_t *manager,
  *
  *\li	'socketp' is a valid pointer, and *socketp == NULL
  *
+ *\li	'type' is not isc_sockettype_fdwatch
+ *
  * Ensures:
  *
  *	'*socketp' is attached to the newly created socket
@@ -329,12 +452,17 @@ isc_socket_open(isc_socket_t *sock);
  * one.  This optimization may not be available for some systems, in which
  * case this function will return ISC_R_NOTIMPLEMENTED and must not be used.
  *
+ * isc_socket_open() should not be called on sockets created by
+ * isc_socket_fdwatchcreate().
+ *
  * Requires:
  *
  * \li	there must be no other reference to this socket.
  *
  * \li	'socket' is a valid and previously closed by isc_socket_close()
  *
+ * \li  'sock->type' is not isc_sockettype_fdwatch
+ *
  * Returns:
  *	Same as isc_socket_create().
  * \li	ISC_R_NOTIMPLEMENTED
@@ -350,6 +478,9 @@ isc_socket_close(isc_socket_t *sock);
  * systems, in which case this function will return ISC_R_NOTIMPLEMENTED and
  * must not be used.
  *
+ * isc_socket_close() should not be called on sockets created by
+ * isc_socket_fdwatchcreate().
+ *
  * Requires:
  *
  * \li	The socket must have a valid descriptor.
@@ -358,6 +489,8 @@ isc_socket_close(isc_socket_t *sock);
  *
  * \li	There must be no pending I/O requests.
  *
+ * \li  'sock->type' is not isc_sockettype_fdwatch
+ *
  * Returns:
  * \li	#ISC_R_NOTIMPLEMENTED
  */
@@ -738,6 +871,19 @@ isc_socketmgr_getmaxsockets(isc_socketmgr_t *manager, unsigned int *nsockp);
  */
 
 void
+isc_socketmgr_setstats(isc_socketmgr_t *manager, isc_stats_t *stats);
+/*%<
+ * Set a general socket statistics counter set 'stats' for 'manager'.
+ *
+ * Requires:
+ * \li	'manager' is valid, hasn't opened any socket, and doesn't have
+ *	stats already set.
+ *
+ *\li	stats is a valid statistics supporting socket statistics counters
+ *	(see above).
+ */
+
+void
 isc_socketmgr_destroy(isc_socketmgr_t **managerp);
 /*%<
  * Destroy a socket manager.
@@ -812,7 +958,7 @@ isc_socket_permunix(isc_sockaddr_t *sockaddr, isc_uint32_t perm,
  * Set ownership and file permissions on the UNIX domain socket.
  *
  * Note: On Solaris and SunOS this secures the directory containing
- *       the socket as Solaris and SunOS do not honour the filesytem
+ *       the socket as Solaris and SunOS do not honour the filesystem
  *	 permissions on the socket.
  *
  * Requires:
@@ -823,12 +969,39 @@ isc_socket_permunix(isc_sockaddr_t *sockaddr, isc_uint32_t perm,
  * \li	#ISC_R_FAILURE
  */
 
+void isc_socket_setname(isc_socket_t *socket, const char *name, void *tag);
+/*%<
+ * Set the name and optional tag for a socket.  This allows tracking of the
+ * owner or purpose for this socket, and is useful for tracing and statistics
+ * reporting.
+ */
+
+const char *isc_socket_getname(isc_socket_t *socket);
+/*%<
+ * Get the name associated with a socket, if any.
+ */
+
+void *isc_socket_gettag(isc_socket_t *socket);
+/*%<
+ * Get the tag associated with a socket, if any.
+ */
+
 void
 isc__socketmgr_setreserved(isc_socketmgr_t *mgr, isc_uint32_t);
 /*%<
  * Temporary.  For use by named only.
  */
 
+#ifdef HAVE_LIBXML2
+
+void
+isc_socketmgr_renderxml(isc_socketmgr_t *mgr, xmlTextWriterPtr writer);
+/*%<
+ * Render internal statistics and other state into the XML document.
+ */
+
+#endif /* HAVE_LIBXML2 */
+
 ISC_LANG_ENDDECLS
 
 #endif /* ISC_SOCKET_H */
diff --git a/contrib/bind9/lib/isc/include/isc/stats.h b/contrib/bind9/lib/isc/include/isc/stats.h
new file mode 100644
index 0000000..a6156d8
--- /dev/null
+++ b/contrib/bind9/lib/isc/include/isc/stats.h
@@ -0,0 +1,121 @@
+/*
+ * Copyright (C) 2009  Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or 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: stats.h,v 1.4.2.2 2009/01/29 23:47:44 tbox Exp $ */
+
+#ifndef ISC_STATS_H
+#define ISC_STATS_H 1
+
+/*! \file isc/stats.h */
+
+#include <isc/types.h>
+
+ISC_LANG_BEGINDECLS
+
+/*%<
+ * Flag(s) for isc_stats_dump().
+ */
+#define ISC_STATSDUMP_VERBOSE	0x00000001 /*%< dump 0-value counters */
+
+/*%<
+ * Dump callback type.
+ */
+typedef void (*isc_stats_dumper_t)(isc_statscounter_t, isc_uint64_t, void *);
+
+isc_result_t
+isc_stats_create(isc_mem_t *mctx, isc_stats_t **statsp, int ncounters);
+/*%<
+ * Create a statistics counter structure of general type.  It counts a general
+ * set of counters indexed by an ID between 0 and ncounters -1.
+ *
+ * Requires:
+ *\li	'mctx' must be a valid memory context.
+ *
+ *\li	'statsp' != NULL && '*statsp' == NULL.
+ *
+ * Returns:
+ *\li	ISC_R_SUCCESS	-- all ok
+ *
+ *\li	anything else	-- failure
+ */
+
+void
+isc_stats_attach(isc_stats_t *stats, isc_stats_t **statsp);
+/*%<
+ * Attach to a statistics set.
+ *
+ * Requires:
+ *\li	'stats' is a valid isc_stats_t.
+ *
+ *\li	'statsp' != NULL && '*statsp' == NULL
+ */
+
+void
+isc_stats_detach(isc_stats_t **statsp);
+/*%<
+ * Detaches from the statistics set.
+ *
+ * Requires:
+ *\li	'statsp' != NULL and '*statsp' is a valid isc_stats_t.
+ */
+
+int
+isc_stats_ncounters(isc_stats_t *stats);
+/*%<
+ * Returns the number of counters contained in stats.
+ *
+ * Requires:
+ *\li	'stats' is a valid isc_stats_t.
+ *
+ */
+
+void
+isc_stats_increment(isc_stats_t *stats, isc_statscounter_t counter);
+/*%<
+ * Increment the counter-th counter of stats.
+ *
+ * Requires:
+ *\li	'stats' is a valid isc_stats_t.
+ *
+ *\li	counter is less than the maximum available ID for the stats specified
+ *	on creation.
+ */
+
+void
+isc_stats_decrement(isc_stats_t *stats, isc_statscounter_t counter);
+/*%<
+ * Decrement the counter-th counter of stats.
+ *
+ * Requires:
+ *\li	'stats' is a valid isc_stats_t.
+ */
+
+void
+isc_stats_dump(isc_stats_t *stats, isc_stats_dumper_t dump_fn, void *arg,
+	       unsigned int options);
+/*%<
+ * Dump the current statistics counters in a specified way.  For each counter
+ * in stats, dump_fn is called with its current value and the given argument
+ * arg.  By default counters that have a value of 0 is skipped; if options has
+ * the ISC_STATSDUMP_VERBOSE flag, even such counters are dumped.
+ *
+ * Requires:
+ *\li	'stats' is a valid isc_stats_t.
+ */
+
+ISC_LANG_ENDDECLS
+
+#endif /* ISC_STATS_H */
diff --git a/contrib/bind9/lib/isc/include/isc/stdio.h b/contrib/bind9/lib/isc/include/isc/stdio.h
index e3bf0cd..1a7ae64 100644
--- a/contrib/bind9/lib/isc/include/isc/stdio.h
+++ b/contrib/bind9/lib/isc/include/isc/stdio.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: stdio.h,v 1.7.18.2 2005/04/29 00:17:03 marka Exp $ */
+/* $Id: stdio.h,v 1.13 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_STDIO_H
 #define ISC_STDIO_H 1
 
-/*! \file */
+/*! \file isc/stdio.h */
 
 /*% 
  * These functions are wrappers around the corresponding stdio functions.
diff --git a/contrib/bind9/lib/isc/include/isc/stdlib.h b/contrib/bind9/lib/isc/include/isc/stdlib.h
index 0e2c697..02243f0 100644
--- a/contrib/bind9/lib/isc/include/isc/stdlib.h
+++ b/contrib/bind9/lib/isc/include/isc/stdlib.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: stdlib.h,v 1.2.18.2 2005/04/29 00:17:03 marka Exp $ */
+/* $Id: stdlib.h,v 1.8 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_STDLIB_H
 #define ISC_STDLIB_H 1
 
-/*! \file */
+/*! \file isc/stdlib.h */
 
 #include <stdlib.h>
 
diff --git a/contrib/bind9/lib/isc/include/isc/string.h b/contrib/bind9/lib/isc/include/isc/string.h
index bda71f4..b49fdbc 100644
--- a/contrib/bind9/lib/isc/include/isc/string.h
+++ b/contrib/bind9/lib/isc/include/isc/string.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: string.h,v 1.12.18.6 2007/09/13 05:04:01 each Exp $ */
+/* $Id: string.h,v 1.23 2007/09/13 04:48:16 each Exp $ */
 
 #ifndef ISC_STRING_H
 #define ISC_STRING_H 1
 
-/*! \file */
+/*! \file isc/string.h */
 
 #include <isc/formatcheck.h>
 #include <isc/int.h>
diff --git a/contrib/bind9/lib/isc/include/isc/symtab.h b/contrib/bind9/lib/isc/include/isc/symtab.h
index 94ea173..396d645 100644
--- a/contrib/bind9/lib/isc/include/isc/symtab.h
+++ b/contrib/bind9/lib/isc/include/isc/symtab.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1996-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: symtab.h,v 1.17.18.4 2006/03/02 00:37:22 marka Exp $ */
+/* $Id: symtab.h,v 1.24.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef ISC_SYMTAB_H
 #define ISC_SYMTAB_H 1
@@ -24,10 +24,10 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file isc/symtab.h
  * \brief Provides a simple memory-based symbol table.
  *
- * Keys are C strings, and key comparisons are case-insenstive.  A type may
+ * Keys are C strings, and key comparisons are case-insensitive.  A type may
  * be specified when looking up, defining, or undefining.  A type value of
  * 0 means "match any type"; any other value will only match the given
  * type.
diff --git a/contrib/bind9/lib/isc/include/isc/task.h b/contrib/bind9/lib/isc/include/isc/task.h
index f7d237c..8106571 100644
--- a/contrib/bind9/lib/isc/include/isc/task.h
+++ b/contrib/bind9/lib/isc/include/isc/task.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: task.h,v 1.51.18.2 2005/04/29 00:17:03 marka Exp $ */
+/* $Id: task.h,v 1.61.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef ISC_TASK_H
 #define ISC_TASK_H 1
@@ -24,9 +24,9 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file isc/task.h
  * \brief The task system provides a lightweight execution context, which is
- * basically an event queue.  
+ * basically an event queue.
 
  * When a task's event queue is non-empty, the
  * task is runnable.  A small work crew of threads, typically one per CPU,
@@ -67,7 +67,7 @@
  * Consumers of events should purge, not unsend.
  *
  * Producers of events often want to remove events when the caller indicates
- * it is no longer interested in the object, e.g. by cancelling a timer.
+ * it is no longer interested in the object, e.g. by canceling a timer.
  * Sometimes this can be done by purging, but for some event types, the
  * calls to isc_event_free() cause deadlock because the event free routine
  * wants to acquire a lock the caller is already holding.  Unsending instead
@@ -84,6 +84,7 @@
 #include <isc/lang.h>
 #include <isc/stdtime.h>
 #include <isc/types.h>
+#include <isc/xml.h>
 
 #define ISC_TASKEVENT_FIRSTEVENT	(ISC_EVENTCLASS_TASK + 0)
 #define ISC_TASKEVENT_SHUTDOWN		(ISC_EVENTCLASS_TASK + 1)
@@ -497,7 +498,7 @@ isc_task_beginexclusive(isc_task_t *task);
  * current event, and prevents any new events from executing in any of the
  * tasks sharing a task manager with 'task'.
  *
- * The exclusive access must be relinquished by calling 
+ * The exclusive access must be relinquished by calling
  * isc_task_endexclusive() before returning from the current event handler.
  *
  * Requires:
@@ -512,7 +513,7 @@ isc_task_beginexclusive(isc_task_t *task);
 void
 isc_task_endexclusive(isc_task_t *task);
 /*%<
- * Relinquish the exclusive access obtained by isc_task_beginexclusive(), 
+ * Relinquish the exclusive access obtained by isc_task_beginexclusive(),
  * allowing other tasks to execute.
  *
  * Requires:
@@ -592,7 +593,7 @@ isc_taskmgr_destroy(isc_taskmgr_t **managerp);
  *	because it would block forever waiting for the event action to
  *	complete.  An event action that wants to cause task manager shutdown
  *	should request some non-event action thread of execution to do the
- *	shutdown, e.g. by signalling a condition variable or using
+ *	shutdown, e.g. by signaling a condition variable or using
  *	isc_app_shutdown().
  *
  *\li	Task manager references are not reference counted, so the caller
@@ -611,6 +612,13 @@ isc_taskmgr_destroy(isc_taskmgr_t **managerp);
  *	have been freed.
  */
 
+#ifdef HAVE_LIBXML2
+
+void
+isc_taskmgr_renderxml(isc_taskmgr_t *mgr, xmlTextWriterPtr writer);
+
+#endif
+
 ISC_LANG_ENDDECLS
 
 #endif /* ISC_TASK_H */
diff --git a/contrib/bind9/lib/isc/include/isc/taskpool.h b/contrib/bind9/lib/isc/include/isc/taskpool.h
index 6c97605..fd07bfd 100644
--- a/contrib/bind9/lib/isc/include/isc/taskpool.h
+++ b/contrib/bind9/lib/isc/include/isc/taskpool.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: taskpool.h,v 1.9.18.2 2005/04/29 00:17:04 marka Exp $ */
+/* $Id: taskpool.h,v 1.15 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_TASKPOOL_H
 #define ISC_TASKPOOL_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file isc/taskpool.h
  * \brief A task pool is a mechanism for sharing a small number of tasks
  * among a large number of objects such that each object is
  * assigned a unique task, but each task may be shared by several
diff --git a/contrib/bind9/lib/isc/include/isc/timer.h b/contrib/bind9/lib/isc/include/isc/timer.h
index 7a7f614..a4b2df7 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, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: timer.h,v 1.31.18.5 2008/06/24 23:45:55 tbox Exp $ */
+/* $Id: timer.h,v 1.40 2008/06/23 23:47:11 tbox Exp $ */
 
 #ifndef ISC_TIMER_H
 #define ISC_TIMER_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file isc/timer.h
  * \brief Provides timers which are event sources in the task system.
  *
  * Three types of timers are supported:
diff --git a/contrib/bind9/lib/isc/include/isc/types.h b/contrib/bind9/lib/isc/include/isc/types.h
index b501b2c..4dccbf9 100644
--- a/contrib/bind9/lib/isc/include/isc/types.h
+++ b/contrib/bind9/lib/isc/include/isc/types.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: types.h,v 1.35.18.4 2008/06/24 23:45:55 tbox Exp $ */
+/* $Id: types.h,v 1.46.84.2 2009/01/29 23:47:44 tbox Exp $ */
 
 #ifndef ISC_TYPES_H
 #define ISC_TYPES_H 1
 
-/*! \file
+/*! \file isc/types.h
  * \brief
  * OS-specific types, from the OS-specific include directories.
  */
@@ -52,6 +52,11 @@ typedef ISC_LIST(isc_event_t)		isc_eventlist_t;	/*%< Event List */
 typedef unsigned int			isc_eventtype_t;	/*%< Event Type */
 typedef isc_uint32_t			isc_fsaccess_t;		/*%< FS Access */
 typedef struct isc_hash			isc_hash_t;		/*%< Hash */
+typedef struct isc_httpd		isc_httpd_t;		/*%< HTTP client */
+typedef void (isc_httpdfree_t)(isc_buffer_t *, void *);		/*%< HTTP free function */
+typedef struct isc_httpdmgr		isc_httpdmgr_t;		/*%< HTTP manager */
+typedef struct isc_httpdurl		isc_httpdurl_t;		/*%< HTTP URL */
+typedef void (isc_httpdondestroy_t)(void *);			/*%< Callback on destroying httpd */
 typedef struct isc_interface		isc_interface_t;	/*%< Interface */
 typedef struct isc_interfaceiter	isc_interfaceiter_t;	/*%< Interface Iterator */
 typedef struct isc_interval		isc_interval_t;		/*%< Interval */
@@ -77,6 +82,8 @@ typedef struct isc_sockaddr		isc_sockaddr_t;		/*%< Socket Address */
 typedef struct isc_socket		isc_socket_t;		/*%< Socket */
 typedef struct isc_socketevent		isc_socketevent_t;	/*%< Socket Event */
 typedef struct isc_socketmgr		isc_socketmgr_t;	/*%< Socket Manager */
+typedef struct isc_stats		isc_stats_t;		/*%< Statistics */
+typedef int				isc_statscounter_t;	/*%< Statistics Counter */
 typedef struct isc_symtab		isc_symtab_t;		/*%< Symbol Table */
 typedef struct isc_task			isc_task_t;		/*%< Task */
 typedef ISC_LIST(isc_task_t)		isc_tasklist_t;		/*%< Task List */
@@ -87,6 +94,19 @@ typedef struct isc_timer		isc_timer_t;		/*%< Timer */
 typedef struct isc_timermgr		isc_timermgr_t;		/*%< Timer Manager */
 
 typedef void (*isc_taskaction_t)(isc_task_t *, isc_event_t *);
+typedef int (*isc_sockfdwatch_t)(isc_task_t *, isc_socket_t *, void *);
+
+/* The following cannot be listed alphabetically due to forward reference */
+typedef isc_result_t (isc_httpdaction_t)(const char *url,
+					 const char *querystring,
+					 void *arg,
+					 unsigned int *retcode,
+					 const char **retmsg,
+					 const char **mimetype,
+					 isc_buffer_t *body,
+					 isc_httpdfree_t **freecb,
+					 void **freecb_args);
+typedef isc_boolean_t (isc_httpdclientok_t)(const isc_sockaddr_t *, void *);
 
 /*% Resource */
 typedef enum {
diff --git a/contrib/bind9/lib/isc/include/isc/util.h b/contrib/bind9/lib/isc/include/isc/util.h
index 95fe436..8a3b95d 100644
--- a/contrib/bind9/lib/isc/include/isc/util.h
+++ b/contrib/bind9/lib/isc/include/isc/util.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: util.h,v 1.24.18.2 2005/04/29 00:17:04 marka Exp $ */
+/* $Id: util.h,v 1.30 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_UTIL_H
 #define ISC_UTIL_H 1
 
-/*! \file util.h
+/*! \file isc/util.h
  * NOTE:
  *
  * This file is not to be included from any <isc/???.h> (or other) library
diff --git a/contrib/bind9/lib/isc/include/isc/version.h b/contrib/bind9/lib/isc/include/isc/version.h
index 82d4617..ec00bde 100644
--- a/contrib/bind9/lib/isc/include/isc/version.h
+++ b/contrib/bind9/lib/isc/include/isc/version.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,9 +15,9 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: version.h,v 1.3.18.2 2005/04/29 00:17:04 marka Exp $ */
+/* $Id: version.h,v 1.9 2007/06/19 23:47:18 tbox Exp $ */
 
-/*! \file */
+/*! \file isc/version.h */
 
 #include <isc/platform.h>
 
diff --git a/contrib/bind9/lib/isc/include/isc/xml.h b/contrib/bind9/lib/isc/include/isc/xml.h
new file mode 100644
index 0000000..d31a31a
--- /dev/null
+++ b/contrib/bind9/lib/isc/include/isc/xml.h
@@ -0,0 +1,41 @@
+/*
+ * Copyright (C) 2006, 2007  Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or 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: xml.h,v 1.4 2007/06/19 23:47:18 tbox Exp $ */
+
+#ifndef ISC_XML_H
+#define ISC_XML_H 1
+
+/*
+ * This file is here mostly to make it easy to add additional libxml header
+ * files as needed across all the users of this file.  Rather than place
+ * these libxml includes in each file, one include makes it easy to handle
+ * the ifdef as well as adding the ability to add additional functions
+ * which may be useful.
+ */
+
+#ifdef HAVE_LIBXML2
+#include <libxml/encoding.h>
+#include <libxml/xmlwriter.h>
+#endif
+
+#define ISC_XMLCHAR (const xmlChar *)
+
+#define ISC_XML_RENDERCONFIG		0x00000001 /* render config data */
+#define ISC_XML_RENDERSTATS		0x00000002 /* render stats */
+#define ISC_XML_RENDERALL		0x000000ff /* render everything */
+
+#endif /* ISC_XML_H */
diff --git a/contrib/bind9/lib/isc/inet_aton.c b/contrib/bind9/lib/isc/inet_aton.c
index 1602521..ad9401f 100644
--- a/contrib/bind9/lib/isc/inet_aton.c
+++ b/contrib/bind9/lib/isc/inet_aton.c
@@ -1,8 +1,8 @@
 /*
- * Portions Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004, 2005, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 1996-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -71,7 +71,7 @@
 
 #if defined(LIBC_SCCS) && !defined(lint)
 static char sccsid[] = "@(#)inet_addr.c	8.1 (Berkeley) 6/17/93";
-static char rcsid[] = "$Id: inet_aton.c,v 1.17.18.2 2005/04/29 00:16:46 marka Exp $";
+static char rcsid[] = "$Id: inet_aton.c,v 1.21.332.2 2009/03/05 23:47:03 tbox Exp $";
 #endif /* LIBC_SCCS and not lint */
 
 #include <config.h>
@@ -145,7 +145,7 @@ isc_net_aton(const char *cp, struct in_addr *addr) {
 			 *	a.b.c	(with c treated as 16 bits)
 			 *	a.b	(with b treated as 24 bits)
 			 */
-			if (pp >= parts + 3 || val > 0xff)
+			if (pp >= parts + 3 || val > 0xffU)
 				return (0);
 			*pp++ = (isc_uint8_t)val;
 			c = *++cp;
@@ -172,19 +172,19 @@ isc_net_aton(const char *cp, struct in_addr *addr) {
 		break;
 
 	case 2:				/* a.b -- 8.24 bits */
-		if (val > 0xffffff)
+		if (val > 0xffffffU)
 			return (0);
 		val |= parts[0] << 24;
 		break;
 
 	case 3:				/* a.b.c -- 8.8.16 bits */
-		if (val > 0xffff)
+		if (val > 0xffffU)
 			return (0);
 		val |= (parts[0] << 24) | (parts[1] << 16);
 		break;
 
 	case 4:				/* a.b.c.d -- 8.8.8.8 bits */
-		if (val > 0xff)
+		if (val > 0xffU)
 			return (0);
 		val |= (parts[0] << 24) | (parts[1] << 16) | (parts[2] << 8);
 		break;
diff --git a/contrib/bind9/lib/isc/inet_ntop.c b/contrib/bind9/lib/isc/inet_ntop.c
index c0d1161..dc053ed 100644
--- a/contrib/bind9/lib/isc/inet_ntop.c
+++ b/contrib/bind9/lib/isc/inet_ntop.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1996-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -19,7 +19,7 @@
 
 #if defined(LIBC_SCCS) && !defined(lint)
 static char rcsid[] =
-	"$Id: inet_ntop.c,v 1.14.18.3 2005/04/29 00:16:46 marka Exp $";
+	"$Id: inet_ntop.c,v 1.19 2007/06/19 23:47:17 tbox Exp $";
 #endif /* LIBC_SCCS and not lint */
 
 #include <config.h>
diff --git a/contrib/bind9/lib/isc/inet_pton.c b/contrib/bind9/lib/isc/inet_pton.c
index a537e9c..6bada23 100644
--- a/contrib/bind9/lib/isc/inet_pton.c
+++ b/contrib/bind9/lib/isc/inet_pton.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1996-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -19,7 +19,7 @@
 
 #if defined(LIBC_SCCS) && !defined(lint)
 static char rcsid[] =
-	"$Id: inet_pton.c,v 1.13.18.4 2005/04/29 00:16:46 marka Exp $";
+	"$Id: inet_pton.c,v 1.19 2007/06/19 23:47:17 tbox Exp $";
 #endif /* LIBC_SCCS and not lint */
 
 #include <config.h>
diff --git a/contrib/bind9/lib/isc/iterated_hash.c b/contrib/bind9/lib/isc/iterated_hash.c
new file mode 100644
index 0000000..1674314
--- /dev/null
+++ b/contrib/bind9/lib/isc/iterated_hash.c
@@ -0,0 +1,48 @@
+/*
+ * Copyright (C) 2006, 2008, 2009  Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or 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: iterated_hash.c,v 1.4.48.2 2009/02/18 23:47:12 tbox Exp $ */
+
+#include "config.h"
+
+#include <stdio.h>
+
+#include <isc/sha1.h>
+#include <isc/iterated_hash.h>
+
+int
+isc_iterated_hash(unsigned char out[ISC_SHA1_DIGESTLENGTH],
+		  unsigned int hashalg, int iterations,
+		  const unsigned char *salt, int saltlength,
+		  const unsigned char *in, int inlength)
+{
+	isc_sha1_t ctx;
+	int n = 0;
+
+	if (hashalg != 1)
+		return (0);
+
+	do {
+		isc_sha1_init(&ctx);
+		isc_sha1_update(&ctx, in, inlength);
+		isc_sha1_update(&ctx, salt, saltlength);
+		isc_sha1_final(&ctx, out);
+		in = out;
+		inlength = ISC_SHA1_DIGESTLENGTH;
+	} while (n++ < iterations);
+
+	return (ISC_SHA1_DIGESTLENGTH);
+}
diff --git a/contrib/bind9/lib/isc/lex.c b/contrib/bind9/lib/isc/lex.c
index 2e4e48a..8749ed0 100644
--- a/contrib/bind9/lib/isc/lex.c
+++ b/contrib/bind9/lib/isc/lex.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lex.c,v 1.78.18.5 2005/11/30 03:44:39 marka Exp $ */
+/* $Id: lex.c,v 1.86 2007/09/17 09:56:29 shane Exp $ */
 
 /*! \file */
 
@@ -720,11 +720,7 @@ isc_lex_gettoken(isc_lex_t *lex, unsigned int options, isc_token_t *tokenp) {
 				state = lexstate_ccomment;
 			break;
 		case lexstate_eatline:
-			if (c == EOF) {
-				result = ISC_R_UNEXPECTEDEND;
-				goto done;
-			}
-			if (c == '\n') {
+			if ((c == '\n') || (c == EOF)) {
 				no_comments = ISC_FALSE;
 				state = saved_state;
 				goto no_read;
diff --git a/contrib/bind9/lib/isc/lfsr.c b/contrib/bind9/lib/isc/lfsr.c
index 61f9386..0b8d782 100644
--- a/contrib/bind9/lib/isc/lfsr.c
+++ b/contrib/bind9/lib/isc/lfsr.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lfsr.c,v 1.14.18.4 2005/10/14 01:28:29 marka Exp $ */
+/* $Id: lfsr.c,v 1.20 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/lib.c b/contrib/bind9/lib/isc/lib.c
index 7a70c12..f3a2c2d 100644
--- a/contrib/bind9/lib/isc/lib.c
+++ b/contrib/bind9/lib/isc/lib.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lib.c,v 1.10.18.2 2005/04/29 00:16:47 marka Exp $ */
+/* $Id: lib.c,v 1.14 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/log.c b/contrib/bind9/lib/isc/log.c
index 27c01d1..e19c9ba 100644
--- a/contrib/bind9/lib/isc/log.c
+++ b/contrib/bind9/lib/isc/log.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: log.c,v 1.84.18.8 2006/03/02 00:37:22 marka Exp $ */
+/* $Id: log.c,v 1.94.332.5 2009/02/16 02:04:05 marka Exp $ */
 
 /*! \file
  * \author  Principal Authors: DCL */
@@ -61,7 +61,7 @@
  * This is the structure that holds each named channel.  A simple linked
  * list chains all of the channels together, so an individual channel is
  * found by doing strcmp()s with the names down the list.  Their should
- * be no peformance penalty from this as it is expected that the number
+ * be no performance penalty from this as it is expected that the number
  * of named channels will be no more than a dozen or so, and name lookups
  * from the head of the list are only done when isc_log_usechannel() is
  * called, which should also be very infrequent.
@@ -128,7 +128,7 @@ struct isc_logconfig {
  * This isc_log structure provides the context for the isc_log functions.
  * The log context locks itself in isc_log_doit, the internal backend to
  * isc_log_write.  The locking is necessary both to provide exclusive access
- * to the the buffer into which the message is formatted and to guard against
+ * to the buffer into which the message is formatted and to guard against
  * competing threads trying to write to the same syslog resource.  (On
  * some systems, such as BSD/OS, stdio is thread safe but syslog is not.)
  * Unfortunately, the lock cannot guard against a _different_ logging
@@ -204,6 +204,7 @@ LIBISC_EXTERNAL_DATA isc_logmodule_t isc_modules[] = {
 	{ "time", 0 },
 	{ "interface", 0 },
 	{ "timer", 0 },
+	{ "file", 0 },
 	{ NULL, 0 }
 };
 
@@ -1448,7 +1449,7 @@ isc_log_doit(isc_log_t *lctx, isc_logcategory_t *category,
 	LOCK(&lctx->lock);
 
 	lctx->buffer[0] = '\0';
-	
+
 	lcfg = lctx->logconfig;
 
 	category_channels = ISC_LIST_HEAD(lcfg->channellists[category->id]);
@@ -1507,7 +1508,7 @@ isc_log_doit(isc_log_t *lctx, isc_logcategory_t *category,
 		if ((channel->flags & ISC_LOG_PRINTTIME) != 0 &&
 		    time_string[0] == '\0') {
 			isc_time_t isctime;
-			
+
 			TIME_NOW(&isctime);
 			isc_time_formattimestamp(&isctime, time_string,
 						 sizeof(time_string));
@@ -1518,9 +1519,9 @@ isc_log_doit(isc_log_t *lctx, isc_logcategory_t *category,
 			if (level < ISC_LOG_CRITICAL)
 				snprintf(level_string, sizeof(level_string),
 					 isc_msgcat_get(isc_msgcat,
-						        ISC_MSGSET_LOG,
-						        ISC_MSG_LEVEL,
-						        "level %d: "),
+							ISC_MSGSET_LOG,
+							ISC_MSG_LEVEL,
+							"level %d: "),
 					 level);
 			else if (level > ISC_LOG_DYNAMIC)
 				snprintf(level_string, sizeof(level_string),
@@ -1700,8 +1701,8 @@ isc_log_doit(isc_log_t *lctx, isc_logcategory_t *category,
 				printcategory ? category->name	: "",
 				printcategory ? ": "		: "",
 				printmodule   ? (module != NULL ? module->name
-						 		: "no_module")
-					      			: "",
+								: "no_module")
+								: "",
 				printmodule   ? ": "		: "",
 				printlevel    ? level_string	: "",
 				lctx->buffer);
@@ -1743,8 +1744,8 @@ isc_log_doit(isc_log_t *lctx, isc_logcategory_t *category,
 			       printcategory ? category->name	: "",
 			       printcategory ? ": "		: "",
 			       printmodule   ? (module != NULL	? module->name
-						 		: "no_module")
-					      			: "",
+								: "no_module")
+								: "",
 			       printmodule   ? ": "		: "",
 			       printlevel    ? level_string	: "",
 			       lctx->buffer);
diff --git a/contrib/bind9/lib/isc/md5.c b/contrib/bind9/lib/isc/md5.c
index 07d7546..5004c3e 100644
--- a/contrib/bind9/lib/isc/md5.c
+++ b/contrib/bind9/lib/isc/md5.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: md5.c,v 1.10.18.2 2005/04/29 00:16:47 marka Exp $ */
+/* $Id: md5.c,v 1.14 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! \file
  * This code implements the MD5 message-digest algorithm.
diff --git a/contrib/bind9/lib/isc/mem.c b/contrib/bind9/lib/isc/mem.c
index 408770d..9c37d74 100644
--- a/contrib/bind9/lib/isc/mem.c
+++ b/contrib/bind9/lib/isc/mem.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1997-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: mem.c,v 1.116.18.21 2008/02/07 23:45:56 tbox Exp $ */
+/* $Id: mem.c,v 1.145.120.4 2009/02/16 03:17:05 marka Exp $ */
 
 /*! \file */
 
@@ -33,9 +33,10 @@
 #include <isc/once.h>
 #include <isc/ondestroy.h>
 #include <isc/string.h>
-
 #include <isc/mutex.h>
+#include <isc/print.h>
 #include <isc/util.h>
+#include <isc/xml.h>
 
 #define MCTXLOCK(m, l) if (((m)->flags & ISC_MEMFLAG_NOLOCK) == 0) LOCK(l)
 #define MCTXUNLOCK(m, l) if (((m)->flags & ISC_MEMFLAG_NOLOCK) == 0) UNLOCK(l)
@@ -51,7 +52,7 @@ LIBISC_EXTERNAL_DATA unsigned int isc_mem_debugging = ISC_MEM_DEBUGGING;
 
 #define DEF_MAX_SIZE		1100
 #define DEF_MEM_TARGET		4096
-#define ALIGNMENT_SIZE		8		/*%< must be a power of 2 */
+#define ALIGNMENT_SIZE		8U		/*%< must be a power of 2 */
 #define NUM_BASIC_BLOCKS	64		/*%< must be > 1 */
 #define TABLE_INCREMENT		1024
 #define DEBUGLIST_COUNT		1024
@@ -113,6 +114,12 @@ static ISC_LIST(isc_mem_t)	contexts;
 static isc_once_t		once = ISC_ONCE_INIT;
 static isc_mutex_t		lock;
 
+/*%
+ * Total size of lost memory due to a bug of external library.
+ * Locked by the global lock.
+ */
+static isc_uint64_t		totallost;
+
 struct isc_mem {
 	unsigned int		magic;
 	isc_ondestroy_t		ondestroy;
@@ -125,6 +132,8 @@ struct isc_mem {
 	isc_boolean_t		checkfree;
 	struct stats *		stats;
 	unsigned int		references;
+	char			name[16];
+	void *			tag;
 	size_t			quota;
 	size_t			total;
 	size_t			inuse;
@@ -135,6 +144,7 @@ struct isc_mem {
 	isc_mem_water_t		water;
 	void *			water_arg;
 	ISC_LIST(isc_mempool_t)	pools;
+	unsigned int		poolcnt;
 
 	/*  ISC_MEMFLAG_INTERNAL */
 	size_t			mem_target;
@@ -148,6 +158,7 @@ struct isc_mem {
 
 #if ISC_MEM_TRACKLINES
 	debuglist_t *	 	debuglist;
+	unsigned int		debuglistcnt;
 #endif
 
 	unsigned int		memalloc_failures;
@@ -259,6 +270,7 @@ add_trace_entry(isc_mem_t *mctx, const void *ptr, unsigned int size
 	dl->count = 1;
 
 	ISC_LIST_PREPEND(mctx->debuglist[size], dl, link);
+	mctx->debuglistcnt++;
 }
 
 static inline void
@@ -692,6 +704,7 @@ static void
 initialize_action(void) {
 	RUNTIME_CHECK(isc_mutex_init(&lock) == ISC_R_SUCCESS);
 	ISC_LIST_INIT(contexts);
+	totallost = 0;
 }
 
 /*
@@ -742,6 +755,8 @@ isc_mem_createx2(size_t init_max_size, size_t target_size,
 		ctx->max_size = init_max_size;
 	ctx->flags = flags;
 	ctx->references = 1;
+	memset(ctx->name, 0, sizeof(ctx->name));
+	ctx->tag = NULL;
 	ctx->quota = 0;
 	ctx->total = 0;
 	ctx->inuse = 0;
@@ -760,8 +775,10 @@ isc_mem_createx2(size_t init_max_size, size_t target_size,
 	ctx->checkfree = ISC_TRUE;
 #if ISC_MEM_TRACKLINES
 	ctx->debuglist = NULL;
+	ctx->debuglistcnt = 0;
 #endif
 	ISC_LIST_INIT(ctx->pools);
+	ctx->poolcnt = 0;
 	ctx->freelists = NULL;
 	ctx->basic_blocks = NULL;
 	ctx->basic_table = NULL;
@@ -862,6 +879,7 @@ destroy(isc_mem_t *ctx) {
 
 	LOCK(&lock);
 	ISC_LIST_UNLINK(contexts, ctx, link);
+	totallost += ctx->inuse;
 	UNLOCK(&lock);
 
 	INSIST(ISC_LIST_EMPTY(ctx->pools));
@@ -1173,7 +1191,7 @@ print_active(isc_mem_t *mctx, FILE *out) {
 		const char *format;
 		isc_boolean_t found;
 
-		fprintf(out, isc_msgcat_get(isc_msgcat, ISC_MSGSET_MEM,
+		fprintf(out, "%s", isc_msgcat_get(isc_msgcat, ISC_MSGSET_MEM,
 					    ISC_MSG_DUMPALLOC,
 					    "Dump of all outstanding "
 					    "memory allocations:\n"));
@@ -1199,7 +1217,7 @@ print_active(isc_mem_t *mctx, FILE *out) {
 			}
 		}
 		if (!found)
-			fprintf(out, isc_msgcat_get(isc_msgcat, ISC_MSGSET_MEM,
+			fprintf(out, "%s", isc_msgcat_get(isc_msgcat, ISC_MSGSET_MEM,
 						    ISC_MSG_NONE, "\tNone.\n"));
 	}
 }
@@ -1241,7 +1259,7 @@ isc_mem_stats(isc_mem_t *ctx, FILE *out) {
 	 */
 	pool = ISC_LIST_HEAD(ctx->pools);
 	if (pool != NULL) {
-		fprintf(out, isc_msgcat_get(isc_msgcat, ISC_MSGSET_MEM,
+		fprintf(out, "%s", isc_msgcat_get(isc_msgcat, ISC_MSGSET_MEM,
 					    ISC_MSG_POOLSTATS,
 					    "[Pool statistics]\n"));
 		fprintf(out, "%15s %10s %10s %10s %10s %10s %10s %10s %1s\n",
@@ -1347,6 +1365,40 @@ isc__mem_allocate(isc_mem_t *ctx, size_t size FLARG) {
 	return (si);
 }
 
+void *
+isc__mem_reallocate(isc_mem_t *ctx, void *ptr, size_t size FLARG) {
+	void *new_ptr = NULL;
+	size_t oldsize, copysize;
+
+	REQUIRE(VALID_CONTEXT(ctx));
+
+	/*
+	 * This function emulates the realloc(3) standard library function:
+	 * - if size > 0, allocate new memory; and if ptr is non NULL, copy
+	 *   as much of the old contents to the new buffer and free the old one.
+	 *   Note that when allocation fails the original pointer is intact;
+	 *   the caller must free it.
+	 * - if size is 0 and ptr is non NULL, simply free the given ptr.
+	 * - this function returns:
+	 *     pointer to the newly allocated memory, or
+	 *     NULL if allocation fails or doesn't happen.
+	 */
+	if (size > 0U) {
+		new_ptr = isc__mem_allocate(ctx, size FLARG_PASS);
+		if (new_ptr != NULL && ptr != NULL) {
+			oldsize = (((size_info *)ptr)[-1]).u.size;
+			INSIST(oldsize >= ALIGNMENT_SIZE);
+			oldsize -= ALIGNMENT_SIZE;
+			copysize = oldsize > size ? size : oldsize;
+			memcpy(new_ptr, ptr, copysize);
+			isc__mem_free(ctx, ptr FLARG_PASS);
+		}
+	} else if (ptr != NULL)
+		isc__mem_free(ctx, ptr FLARG_PASS);
+
+	return (new_ptr);
+}
+
 void
 isc__mem_free(isc_mem_t *ctx, void *ptr FLARG) {
 	size_info *si;
@@ -1507,6 +1559,31 @@ isc_mem_setwater(isc_mem_t *ctx, isc_mem_water_t water, void *water_arg,
 		(oldwater)(oldwater_arg, ISC_MEM_LOWATER);
 }
 
+void
+isc_mem_setname(isc_mem_t *ctx, const char *name, void *tag) {
+	REQUIRE(VALID_CONTEXT(ctx));
+
+	LOCK(&ctx->lock);
+	memset(ctx->name, 0, sizeof(ctx->name));
+	strncpy(ctx->name, name, sizeof(ctx->name) - 1);
+	ctx->tag = tag;
+	UNLOCK(&ctx->lock);
+}
+
+const char *
+isc_mem_getname(isc_mem_t *ctx) {
+	REQUIRE(VALID_CONTEXT(ctx));
+
+	return (ctx->name);
+}
+
+void *
+isc_mem_gettag(isc_mem_t *ctx) {
+	REQUIRE(VALID_CONTEXT(ctx));
+
+	return (ctx->tag);
+}
+
 /*
  * Memory pool stuff
  */
@@ -1546,6 +1623,7 @@ isc_mempool_create(isc_mem_t *mctx, size_t size, isc_mempool_t **mpctxp) {
 
 	MCTXLOCK(mctx, &mctx->lock);
 	ISC_LIST_INITANDAPPEND(mctx->pools, mpctx, link);
+	mctx->poolcnt++;
 	MCTXUNLOCK(mctx, &mctx->lock);
 
 	return (ISC_R_SUCCESS);
@@ -1620,6 +1698,7 @@ isc_mempool_destroy(isc_mempool_t **mpctxp) {
 	 */
 	MCTXLOCK(mctx, &mctx->lock);
 	ISC_LIST_UNLINK(mctx->pools, mpctx, link);
+	mctx->poolcnt--;
 	MCTXUNLOCK(mctx, &mctx->lock);
 
 	mpctx->magic = 0;
@@ -1963,3 +2042,164 @@ isc_mem_checkdestroyed(FILE *file) {
 	}
 	UNLOCK(&lock);
 }
+
+unsigned int
+isc_mem_references(isc_mem_t *ctx) {
+	unsigned int references;
+	REQUIRE(VALID_CONTEXT(ctx));
+
+	MCTXLOCK(ctx, &ctx->lock);
+	references = ctx->references;
+	MCTXUNLOCK(ctx, &ctx->lock);
+
+	return (references);
+}
+
+#ifdef HAVE_LIBXML2
+
+typedef struct summarystat {
+	isc_uint64_t	total;
+	isc_uint64_t	inuse;
+	isc_uint64_t	blocksize;
+	isc_uint64_t	contextsize;
+} summarystat_t;
+
+static void
+renderctx(isc_mem_t *ctx, summarystat_t *summary, xmlTextWriterPtr writer) {
+	REQUIRE(VALID_CONTEXT(ctx));
+
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "context");
+
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "id");
+	xmlTextWriterWriteFormatString(writer, "%p", ctx);
+	xmlTextWriterEndElement(writer); /* id */
+
+	if (ctx->name[0] != 0) {
+		xmlTextWriterStartElement(writer, ISC_XMLCHAR "name");
+		xmlTextWriterWriteFormatString(writer, "%s", ctx->name);
+		xmlTextWriterEndElement(writer); /* name */
+	}
+
+	REQUIRE(VALID_CONTEXT(ctx));
+	MCTXLOCK(ctx, &ctx->lock);
+
+	summary->contextsize += sizeof(*ctx) +
+		(ctx->max_size + 1) * sizeof(struct stats) +
+		ctx->max_size * sizeof(element *) +
+		ctx->basic_table_count * sizeof(char *);
+#if ISC_MEM_TRACKLINES
+	if (ctx->debuglist != NULL) {
+		summary->contextsize +=
+			(ctx->max_size + 1) * sizeof(debuglist_t) +
+			ctx->debuglistcnt * sizeof(debuglink_t);
+	}
+#endif
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "references");
+	xmlTextWriterWriteFormatString(writer, "%d", ctx->references);
+	xmlTextWriterEndElement(writer); /* references */
+
+	summary->total += ctx->total;
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "total");
+	xmlTextWriterWriteFormatString(writer, "%" ISC_PRINT_QUADFORMAT "u",
+				       (isc_uint64_t)ctx->total);
+	xmlTextWriterEndElement(writer); /* total */
+
+	summary->inuse += ctx->inuse;
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "inuse");
+	xmlTextWriterWriteFormatString(writer, "%" ISC_PRINT_QUADFORMAT "u",
+				       (isc_uint64_t)ctx->inuse);
+	xmlTextWriterEndElement(writer); /* inuse */
+
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "maxinuse");
+	xmlTextWriterWriteFormatString(writer, "%" ISC_PRINT_QUADFORMAT "u",
+				       (isc_uint64_t)ctx->maxinuse);
+	xmlTextWriterEndElement(writer); /* maxinuse */
+
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "blocksize");
+	if ((ctx->flags & ISC_MEMFLAG_INTERNAL) != 0) {
+		summary->blocksize += ctx->basic_table_count *
+			NUM_BASIC_BLOCKS * ctx->mem_target;
+		xmlTextWriterWriteFormatString(writer,
+					       "%" ISC_PRINT_QUADFORMAT "u",
+					       (isc_uint64_t)
+					       ctx->basic_table_count *
+					       NUM_BASIC_BLOCKS *
+					       ctx->mem_target);
+	} else
+		xmlTextWriterWriteFormatString(writer, "%s", "-");
+	xmlTextWriterEndElement(writer); /* blocksize */
+
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "pools");
+	xmlTextWriterWriteFormatString(writer, "%u", ctx->poolcnt);
+	xmlTextWriterEndElement(writer); /* pools */
+	summary->contextsize += ctx->poolcnt * sizeof(isc_mempool_t);
+
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "hiwater");
+	xmlTextWriterWriteFormatString(writer, "%" ISC_PRINT_QUADFORMAT "u",
+				       (isc_uint64_t)ctx->hi_water);
+	xmlTextWriterEndElement(writer); /* hiwater */
+
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "lowater");
+	xmlTextWriterWriteFormatString(writer, "%" ISC_PRINT_QUADFORMAT "u",
+				       (isc_uint64_t)ctx->lo_water);
+	xmlTextWriterEndElement(writer); /* lowater */
+
+	MCTXUNLOCK(ctx, &ctx->lock);
+
+	xmlTextWriterEndElement(writer); /* context */
+}
+
+void
+isc_mem_renderxml(xmlTextWriterPtr writer) {
+	isc_mem_t *ctx;
+	summarystat_t summary;
+	isc_uint64_t lost;
+
+	memset(&summary, 0, sizeof(summary));
+
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "contexts");
+
+	RUNTIME_CHECK(isc_once_do(&once, initialize_action) == ISC_R_SUCCESS);
+
+	LOCK(&lock);
+	lost = totallost;
+	for (ctx = ISC_LIST_HEAD(contexts);
+	     ctx != NULL;
+	     ctx = ISC_LIST_NEXT(ctx, link)) {
+		renderctx(ctx, &summary, writer);
+	}
+	UNLOCK(&lock);
+
+	xmlTextWriterEndElement(writer); /* contexts */
+
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "summary");
+
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "TotalUse");
+	xmlTextWriterWriteFormatString(writer, "%" ISC_PRINT_QUADFORMAT "u",
+				       summary.total);
+	xmlTextWriterEndElement(writer); /* TotalUse */
+
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "InUse");
+	xmlTextWriterWriteFormatString(writer, "%" ISC_PRINT_QUADFORMAT "u",
+				       summary.inuse);
+	xmlTextWriterEndElement(writer); /* InUse */
+
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "BlockSize");
+	xmlTextWriterWriteFormatString(writer, "%" ISC_PRINT_QUADFORMAT "u",
+				       summary.blocksize);
+	xmlTextWriterEndElement(writer); /* BlockSize */
+
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "ContextSize");
+	xmlTextWriterWriteFormatString(writer, "%" ISC_PRINT_QUADFORMAT "u",
+				       summary.contextsize);
+	xmlTextWriterEndElement(writer); /* ContextSize */
+
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "Lost");
+	xmlTextWriterWriteFormatString(writer, "%" ISC_PRINT_QUADFORMAT "u",
+				       lost);
+	xmlTextWriterEndElement(writer); /* Lost */
+
+	xmlTextWriterEndElement(writer); /* summary */
+}
+
+#endif /* HAVE_LIBXML2 */
diff --git a/contrib/bind9/lib/isc/mips/Makefile.in b/contrib/bind9/lib/isc/mips/Makefile.in
index c8e77e4..324db07 100644
--- a/contrib/bind9/lib/isc/mips/Makefile.in
+++ b/contrib/bind9/lib/isc/mips/Makefile.in
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.2.2.1 2007/09/14 04:26:38 marka Exp $
+# $Id: Makefile.in,v 1.2 2007/09/14 04:09:59 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/mips/include/Makefile.in b/contrib/bind9/lib/isc/mips/include/Makefile.in
index f4dd2f6..f1d8bdd 100644
--- a/contrib/bind9/lib/isc/mips/include/Makefile.in
+++ b/contrib/bind9/lib/isc/mips/include/Makefile.in
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.2.2.1 2007/09/14 04:26:38 marka Exp $
+# $Id: Makefile.in,v 1.2 2007/09/14 04:09:59 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/mips/include/isc/Makefile.in b/contrib/bind9/lib/isc/mips/include/isc/Makefile.in
index 6760ce6..5f116ca 100644
--- a/contrib/bind9/lib/isc/mips/include/isc/Makefile.in
+++ b/contrib/bind9/lib/isc/mips/include/isc/Makefile.in
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.2.2.1 2007/09/14 04:26:38 marka Exp $
+# $Id: Makefile.in,v 1.2 2007/09/14 04:09:59 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/mips/include/isc/atomic.h b/contrib/bind9/lib/isc/mips/include/isc/atomic.h
index 368a6ef..bb739f7 100644
--- a/contrib/bind9/lib/isc/mips/include/isc/atomic.h
+++ b/contrib/bind9/lib/isc/mips/include/isc/atomic.h
@@ -1,7 +1,7 @@
 /*
- * Copyright (C) 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: atomic.h,v 1.1.2.1 2005/07/09 07:14:00 jinmei Exp $ */
+/* $Id: atomic.h,v 1.3 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_ATOMIC_H
 #define ISC_ATOMIC_H 1
diff --git a/contrib/bind9/lib/isc/mutexblock.c b/contrib/bind9/lib/isc/mutexblock.c
index d8a82cc..d45ad0e 100644
--- a/contrib/bind9/lib/isc/mutexblock.c
+++ b/contrib/bind9/lib/isc/mutexblock.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: mutexblock.c,v 1.16.18.2 2005/04/29 00:16:47 marka Exp $ */
+/* $Id: mutexblock.c,v 1.20 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/netaddr.c b/contrib/bind9/lib/isc/netaddr.c
index e56e05b..85dd53e 100644
--- a/contrib/bind9/lib/isc/netaddr.c
+++ b/contrib/bind9/lib/isc/netaddr.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: netaddr.c,v 1.27.18.8 2005/04/27 05:02:03 sra Exp $ */
+/* $Id: netaddr.c,v 1.38 2007/06/18 23:47:44 tbox Exp $ */
 
 /*! \file */
 
@@ -79,7 +79,7 @@ isc_netaddr_eqprefix(const isc_netaddr_t *a, const isc_netaddr_t *b,
 	if (a->family != b->family)
 		return (ISC_FALSE);
 
-	if (a->zone != b->zone)
+	if (a->zone != b->zone && b->zone != 0)
 		return (ISC_FALSE);
 
 	switch (a->family) {
diff --git a/contrib/bind9/lib/isc/netscope.c b/contrib/bind9/lib/isc/netscope.c
index 75827d2..9aa11db 100644
--- a/contrib/bind9/lib/isc/netscope.c
+++ b/contrib/bind9/lib/isc/netscope.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -19,7 +19,7 @@
 
 #if defined(LIBC_SCCS) && !defined(lint)
 static char rcsid[] =
-	"$Id: netscope.c,v 1.7.18.4 2006/08/25 05:25:51 marka Exp $";
+	"$Id: netscope.c,v 1.13 2007/06/19 23:47:17 tbox Exp $";
 #endif /* LIBC_SCCS and not lint */
 
 #include <config.h>
diff --git a/contrib/bind9/lib/isc/nls/Makefile.in b/contrib/bind9/lib/isc/nls/Makefile.in
index 8211d9b..695c313 100644
--- a/contrib/bind9/lib/isc/nls/Makefile.in
+++ b/contrib/bind9/lib/isc/nls/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1999-2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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 2004/03/05 05:11:05 marka Exp $
+# $Id: Makefile.in,v 1.14 2007/06/19 23:47:18 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/nls/msgcat.c b/contrib/bind9/lib/isc/nls/msgcat.c
index ae56de7..3d6b676 100644
--- a/contrib/bind9/lib/isc/nls/msgcat.c
+++ b/contrib/bind9/lib/isc/nls/msgcat.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: msgcat.c,v 1.13.18.3 2005/06/08 02:07:57 marka Exp $ */
+/* $Id: msgcat.c,v 1.18 2007/06/19 23:47:18 tbox Exp $ */
 
 /*! \file msgcat.c
  *
diff --git a/contrib/bind9/lib/isc/noatomic/Makefile.in b/contrib/bind9/lib/isc/noatomic/Makefile.in
index c8e77e4..324db07 100644
--- a/contrib/bind9/lib/isc/noatomic/Makefile.in
+++ b/contrib/bind9/lib/isc/noatomic/Makefile.in
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.2.2.1 2007/09/14 04:26:38 marka Exp $
+# $Id: Makefile.in,v 1.2 2007/09/14 04:09:59 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/noatomic/include/Makefile.in b/contrib/bind9/lib/isc/noatomic/include/Makefile.in
index f4dd2f6..f1d8bdd 100644
--- a/contrib/bind9/lib/isc/noatomic/include/Makefile.in
+++ b/contrib/bind9/lib/isc/noatomic/include/Makefile.in
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.2.2.1 2007/09/14 04:26:38 marka Exp $
+# $Id: Makefile.in,v 1.2 2007/09/14 04:09:59 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/noatomic/include/isc/Makefile.in b/contrib/bind9/lib/isc/noatomic/include/isc/Makefile.in
index 6760ce6..5f116ca 100644
--- a/contrib/bind9/lib/isc/noatomic/include/isc/Makefile.in
+++ b/contrib/bind9/lib/isc/noatomic/include/isc/Makefile.in
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.2.2.1 2007/09/14 04:26:38 marka Exp $
+# $Id: Makefile.in,v 1.2 2007/09/14 04:09:59 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/noatomic/include/isc/atomic.h b/contrib/bind9/lib/isc/noatomic/include/isc/atomic.h
index 1c7035f..942ba03 100644
--- a/contrib/bind9/lib/isc/noatomic/include/isc/atomic.h
+++ b/contrib/bind9/lib/isc/noatomic/include/isc/atomic.h
@@ -1,7 +1,7 @@
 /*
- * Copyright (C) 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: atomic.h,v 1.2.2.1 2005/06/04 06:23:44 jinmei Exp $ */
+/* $Id: atomic.h,v 1.4 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_ATOMIC_H
 #define ISC_ATOMIC_H 1
diff --git a/contrib/bind9/lib/isc/nothreads/Makefile.in b/contrib/bind9/lib/isc/nothreads/Makefile.in
index c9e8637..75a2cb5 100644
--- a/contrib/bind9/lib/isc/nothreads/Makefile.in
+++ b/contrib/bind9/lib/isc/nothreads/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2000, 2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.5 2004/03/05 05:11:08 marka Exp $
+# $Id: Makefile.in,v 1.7 2007/06/19 23:47:18 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/nothreads/condition.c b/contrib/bind9/lib/isc/nothreads/condition.c
index 329fbc8..9be8f83 100644
--- a/contrib/bind9/lib/isc/nothreads/condition.c
+++ b/contrib/bind9/lib/isc/nothreads/condition.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2006, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: condition.c,v 1.6.18.2 2006/08/25 05:25:51 marka Exp $ */
+/* $Id: condition.c,v 1.10 2007/06/19 23:47:18 tbox Exp $ */
 
 #include <config.h>
 
diff --git a/contrib/bind9/lib/isc/nothreads/include/Makefile.in b/contrib/bind9/lib/isc/nothreads/include/Makefile.in
index ecfc329..a52310a 100644
--- a/contrib/bind9/lib/isc/nothreads/include/Makefile.in
+++ b/contrib/bind9/lib/isc/nothreads/include/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2000, 2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.3 2004/03/05 05:11:11 marka Exp $
+# $Id: Makefile.in,v 1.5 2007/06/19 23:47:18 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/nothreads/include/isc/Makefile.in b/contrib/bind9/lib/isc/nothreads/include/isc/Makefile.in
index f6482fb..3c9eab0 100644
--- a/contrib/bind9/lib/isc/nothreads/include/isc/Makefile.in
+++ b/contrib/bind9/lib/isc/nothreads/include/isc/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2000, 2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.5 2004/03/05 05:11:13 marka Exp $
+# $Id: Makefile.in,v 1.7 2007/06/19 23:47:18 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/nothreads/include/isc/condition.h b/contrib/bind9/lib/isc/nothreads/include/isc/condition.h
index 39889b1..b269f82 100644
--- a/contrib/bind9/lib/isc/nothreads/include/isc/condition.h
+++ b/contrib/bind9/lib/isc/nothreads/include/isc/condition.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: condition.h,v 1.4 2004/03/05 05:11:13 marka Exp $ */
+/* $Id: condition.h,v 1.6 2007/06/19 23:47:18 tbox Exp $ */
 
 /*
  * This provides a limited subset of the isc_condition_t
diff --git a/contrib/bind9/lib/isc/nothreads/include/isc/mutex.h b/contrib/bind9/lib/isc/nothreads/include/isc/mutex.h
index a586435..1f2187b 100644
--- a/contrib/bind9/lib/isc/nothreads/include/isc/mutex.h
+++ b/contrib/bind9/lib/isc/nothreads/include/isc/mutex.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: mutex.h,v 1.4 2004/03/05 05:11:13 marka Exp $ */
+/* $Id: mutex.h,v 1.6 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_MUTEX_H
 #define ISC_MUTEX_H 1
diff --git a/contrib/bind9/lib/isc/nothreads/include/isc/once.h b/contrib/bind9/lib/isc/nothreads/include/isc/once.h
index 470120a..ab705a4 100644
--- a/contrib/bind9/lib/isc/nothreads/include/isc/once.h
+++ b/contrib/bind9/lib/isc/nothreads/include/isc/once.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: once.h,v 1.4 2004/03/05 05:11:13 marka Exp $ */
+/* $Id: once.h,v 1.6 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_ONCE_H
 #define ISC_ONCE_H 1
diff --git a/contrib/bind9/lib/isc/nothreads/include/isc/thread.h b/contrib/bind9/lib/isc/nothreads/include/isc/thread.h
index 6c85913..313bc5f 100644
--- a/contrib/bind9/lib/isc/nothreads/include/isc/thread.h
+++ b/contrib/bind9/lib/isc/nothreads/include/isc/thread.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: thread.h,v 1.4 2004/03/05 05:11:13 marka Exp $ */
+/* $Id: thread.h,v 1.6 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_THREAD_H
 #define ISC_THREAD_H 1
diff --git a/contrib/bind9/lib/isc/nothreads/mutex.c b/contrib/bind9/lib/isc/nothreads/mutex.c
index 0048d87..50ba0f4 100644
--- a/contrib/bind9/lib/isc/nothreads/mutex.c
+++ b/contrib/bind9/lib/isc/nothreads/mutex.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2006, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: mutex.c,v 1.6.18.2 2006/08/25 05:25:51 marka Exp $ */
+/* $Id: mutex.c,v 1.10 2007/06/19 23:47:18 tbox Exp $ */
 
 #include <config.h>
 
diff --git a/contrib/bind9/lib/isc/nothreads/thread.c b/contrib/bind9/lib/isc/nothreads/thread.c
index 0f20927..9075e25 100644
--- a/contrib/bind9/lib/isc/nothreads/thread.c
+++ b/contrib/bind9/lib/isc/nothreads/thread.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: thread.c,v 1.3 2004/03/05 05:11:09 marka Exp $ */
+/* $Id: thread.c,v 1.5 2007/06/19 23:47:18 tbox Exp $ */
 
 #include <config.h>
 
diff --git a/contrib/bind9/lib/isc/ondestroy.c b/contrib/bind9/lib/isc/ondestroy.c
index 2cd9687..32a75e1 100644
--- a/contrib/bind9/lib/isc/ondestroy.c
+++ b/contrib/bind9/lib/isc/ondestroy.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ondestroy.c,v 1.12.18.2 2005/04/29 00:16:48 marka Exp $ */
+/* $Id: ondestroy.c,v 1.16 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/parseint.c b/contrib/bind9/lib/isc/parseint.c
index 0696344..266d44c 100644
--- a/contrib/bind9/lib/isc/parseint.c
+++ b/contrib/bind9/lib/isc/parseint.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: parseint.c,v 1.4.18.2 2005/04/29 00:16:48 marka Exp $ */
+/* $Id: parseint.c,v 1.8 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/portset.c b/contrib/bind9/lib/isc/portset.c
index 0265c89..471ca8e 100644
--- a/contrib/bind9/lib/isc/portset.c
+++ b/contrib/bind9/lib/isc/portset.c
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: portset.c,v 1.2.4.3 2008/06/24 23:27:11 marka Exp $ */
+/* $Id: portset.c,v 1.4 2008/06/24 23:24:35 marka Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/powerpc/Makefile.in b/contrib/bind9/lib/isc/powerpc/Makefile.in
index c8e77e4..324db07 100644
--- a/contrib/bind9/lib/isc/powerpc/Makefile.in
+++ b/contrib/bind9/lib/isc/powerpc/Makefile.in
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.2.2.1 2007/09/14 04:26:38 marka Exp $
+# $Id: Makefile.in,v 1.2 2007/09/14 04:09:59 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/powerpc/include/Makefile.in b/contrib/bind9/lib/isc/powerpc/include/Makefile.in
index f4dd2f6..f1d8bdd 100644
--- a/contrib/bind9/lib/isc/powerpc/include/Makefile.in
+++ b/contrib/bind9/lib/isc/powerpc/include/Makefile.in
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.2.2.1 2007/09/14 04:26:38 marka Exp $
+# $Id: Makefile.in,v 1.2 2007/09/14 04:09:59 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/powerpc/include/isc/Makefile.in b/contrib/bind9/lib/isc/powerpc/include/isc/Makefile.in
index 6760ce6..5f116ca 100644
--- a/contrib/bind9/lib/isc/powerpc/include/isc/Makefile.in
+++ b/contrib/bind9/lib/isc/powerpc/include/isc/Makefile.in
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.2.2.1 2007/09/14 04:26:38 marka Exp $
+# $Id: Makefile.in,v 1.2 2007/09/14 04:09:59 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/powerpc/include/isc/atomic.h b/contrib/bind9/lib/isc/powerpc/include/isc/atomic.h
index 30db328..765cb6d 100644
--- a/contrib/bind9/lib/isc/powerpc/include/isc/atomic.h
+++ b/contrib/bind9/lib/isc/powerpc/include/isc/atomic.h
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: atomic.h,v 1.1.6.6 2007/08/28 07:20:06 tbox Exp $ */
+/* $Id: atomic.h,v 1.6 2007/06/18 23:47:47 tbox Exp $ */
 
 #ifndef ISC_ATOMIC_H
 #define ISC_ATOMIC_H 1
diff --git a/contrib/bind9/lib/isc/print.c b/contrib/bind9/lib/isc/print.c
index 191ad24..b892e3a 100644
--- a/contrib/bind9/lib/isc/print.c
+++ b/contrib/bind9/lib/isc/print.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: print.c,v 1.27.18.5 2008/02/18 23:46:01 tbox Exp $ */
+/* $Id: print.c,v 1.35 2008/02/18 23:46:59 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/pthreads/Makefile.in b/contrib/bind9/lib/isc/pthreads/Makefile.in
index b9cc906..a287457 100644
--- a/contrib/bind9/lib/isc/pthreads/Makefile.in
+++ b/contrib/bind9/lib/isc/pthreads/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1998-2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.17 2004/03/05 05:11:16 marka Exp $
+# $Id: Makefile.in,v 1.19 2007/06/19 23:47:18 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/pthreads/condition.c b/contrib/bind9/lib/isc/pthreads/condition.c
index b9c26c6..50281a2 100644
--- a/contrib/bind9/lib/isc/pthreads/condition.c
+++ b/contrib/bind9/lib/isc/pthreads/condition.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: condition.c,v 1.32.18.2 2005/04/29 00:17:05 marka Exp $ */
+/* $Id: condition.c,v 1.36 2007/06/19 23:47:18 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/pthreads/include/Makefile.in b/contrib/bind9/lib/isc/pthreads/include/Makefile.in
index b1164b6..0303ab1 100644
--- a/contrib/bind9/lib/isc/pthreads/include/Makefile.in
+++ b/contrib/bind9/lib/isc/pthreads/include/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1998-2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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 2004/03/05 05:11:19 marka Exp $
+# $Id: Makefile.in,v 1.14 2007/06/19 23:47:18 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/pthreads/include/isc/Makefile.in b/contrib/bind9/lib/isc/pthreads/include/isc/Makefile.in
index 2e11f6c..11675ec 100644
--- a/contrib/bind9/lib/isc/pthreads/include/isc/Makefile.in
+++ b/contrib/bind9/lib/isc/pthreads/include/isc/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1998-2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.14 2004/03/05 05:11:40 marka Exp $
+# $Id: Makefile.in,v 1.16 2007/06/19 23:47:18 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/pthreads/include/isc/condition.h b/contrib/bind9/lib/isc/pthreads/include/isc/condition.h
index f7cea75..04a6118 100644
--- a/contrib/bind9/lib/isc/pthreads/include/isc/condition.h
+++ b/contrib/bind9/lib/isc/pthreads/include/isc/condition.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: condition.h,v 1.22.18.2 2005/04/29 00:17:05 marka Exp $ */
+/* $Id: condition.h,v 1.26 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_CONDITION_H
 #define ISC_CONDITION_H 1
diff --git a/contrib/bind9/lib/isc/pthreads/include/isc/mutex.h b/contrib/bind9/lib/isc/pthreads/include/isc/mutex.h
index edafaf6..dd7d326 100644
--- a/contrib/bind9/lib/isc/pthreads/include/isc/mutex.h
+++ b/contrib/bind9/lib/isc/pthreads/include/isc/mutex.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: mutex.h,v 1.25.18.3 2005/07/12 01:22:33 marka Exp $ */
+/* $Id: mutex.h,v 1.30 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_MUTEX_H
 #define ISC_MUTEX_H 1
diff --git a/contrib/bind9/lib/isc/pthreads/include/isc/once.h b/contrib/bind9/lib/isc/pthreads/include/isc/once.h
index 7e9f672..31d76fb 100644
--- a/contrib/bind9/lib/isc/pthreads/include/isc/once.h
+++ b/contrib/bind9/lib/isc/pthreads/include/isc/once.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: once.h,v 1.9.18.2 2005/04/29 00:17:06 marka Exp $ */
+/* $Id: once.h,v 1.13 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_ONCE_H
 #define ISC_ONCE_H 1
diff --git a/contrib/bind9/lib/isc/pthreads/include/isc/thread.h b/contrib/bind9/lib/isc/pthreads/include/isc/thread.h
index 3262607..7dcc952 100644
--- a/contrib/bind9/lib/isc/pthreads/include/isc/thread.h
+++ b/contrib/bind9/lib/isc/pthreads/include/isc/thread.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: thread.h,v 1.20.18.4 2005/09/18 07:58:08 marka Exp $ */
+/* $Id: thread.h,v 1.26 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_THREAD_H
 #define ISC_THREAD_H 1
diff --git a/contrib/bind9/lib/isc/pthreads/mutex.c b/contrib/bind9/lib/isc/pthreads/mutex.c
index afbc861..b57d9ee 100644
--- a/contrib/bind9/lib/isc/pthreads/mutex.c
+++ b/contrib/bind9/lib/isc/pthreads/mutex.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: mutex.c,v 1.8.18.6 2008/04/04 23:46:02 tbox Exp $ */
+/* $Id: mutex.c,v 1.16 2008/04/04 23:47:01 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/pthreads/thread.c b/contrib/bind9/lib/isc/pthreads/thread.c
index bdbb593..4b5b491 100644
--- a/contrib/bind9/lib/isc/pthreads/thread.c
+++ b/contrib/bind9/lib/isc/pthreads/thread.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: thread.c,v 1.12.18.3 2005/04/29 00:17:05 marka Exp $ */
+/* $Id: thread.c,v 1.17 2007/06/19 23:47:18 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/quota.c b/contrib/bind9/lib/isc/quota.c
index 9290167..5e5c50c 100644
--- a/contrib/bind9/lib/isc/quota.c
+++ b/contrib/bind9/lib/isc/quota.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: quota.c,v 1.13.18.3 2005/07/27 02:44:21 marka Exp $ */
+/* $Id: quota.c,v 1.18 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/radix.c b/contrib/bind9/lib/isc/radix.c
new file mode 100644
index 0000000..7786984
--- /dev/null
+++ b/contrib/bind9/lib/isc/radix.c
@@ -0,0 +1,706 @@
+/*
+ * Copyright (C) 2007-2009  Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or 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: radix.c,v 1.20.36.3 2009/01/18 23:47:41 tbox Exp $ */
+
+/*
+ * This source was adapted from MRT's RCS Ids:
+ * Id: radix.c,v 1.10.2.1 1999/11/29 05:16:24 masaki Exp
+ * Id: prefix.c,v 1.37.2.9 2000/03/10 02:53:19 labovit Exp
+ */
+
+#include <config.h>
+
+#include <isc/mem.h>
+#include <isc/types.h>
+#include <isc/util.h>
+#include <isc/radix.h>
+
+static isc_result_t
+_new_prefix(isc_mem_t *mctx, isc_prefix_t **target, int family,
+	    void *dest, int bitlen);
+
+static void
+_deref_prefix(isc_mem_t *mctx, isc_prefix_t *prefix);
+
+static isc_result_t
+_ref_prefix(isc_mem_t *mctx, isc_prefix_t **target, isc_prefix_t *prefix);
+
+static int
+_comp_with_mask(void *addr, void *dest, u_int mask);
+
+static void
+_clear_radix(isc_radix_tree_t *radix, isc_radix_destroyfunc_t func);
+
+static isc_result_t
+_new_prefix(isc_mem_t *mctx, isc_prefix_t **target, int family, void *dest,
+	    int bitlen)
+{
+	isc_prefix_t *prefix;
+
+	REQUIRE(target != NULL);
+
+	if (family != AF_INET6 && family != AF_INET && family != AF_UNSPEC)
+		return (ISC_R_NOTIMPLEMENTED);
+
+	prefix = isc_mem_get(mctx, sizeof(isc_prefix_t));
+	if (prefix == NULL)
+		return (ISC_R_NOMEMORY);
+
+	if (family == AF_INET6) {
+		prefix->bitlen = (bitlen >= 0) ? bitlen : 128;
+		memcpy(&prefix->add.sin6, dest, 16);
+	} else {
+		/* AF_UNSPEC is "any" or "none"--treat it as AF_INET */
+		prefix->bitlen = (bitlen >= 0) ? bitlen : 32;
+		memcpy(&prefix->add.sin, dest, 4);
+	}
+
+	prefix->family = family;
+
+	isc_refcount_init(&prefix->refcount, 1);
+
+	*target = prefix;
+	return (ISC_R_SUCCESS);
+}
+
+static void
+_deref_prefix(isc_mem_t *mctx, isc_prefix_t *prefix) {
+	int refs;
+
+	if (prefix == NULL)
+		return;
+
+	isc_refcount_decrement(&prefix->refcount, &refs);
+
+	if (refs <= 0) {
+		isc_refcount_destroy(&prefix->refcount);
+		isc_mem_put(mctx, prefix, sizeof(isc_prefix_t));
+	}
+}
+
+static isc_result_t
+_ref_prefix(isc_mem_t *mctx, isc_prefix_t **target, isc_prefix_t *prefix) {
+	INSIST(prefix != NULL);
+	INSIST((prefix->family == AF_INET && prefix->bitlen <= 32) ||
+	       (prefix->family == AF_INET6 && prefix->bitlen <= 128) ||
+	       (prefix->family == AF_UNSPEC && prefix->bitlen == 0));
+	REQUIRE(target != NULL && *target == NULL);
+
+	/*
+	 * If this prefix is a static allocation, copy it into new memory.
+	 * (Note, the refcount still has to be destroyed by the calling
+	 * routine.)
+	 */
+	if (isc_refcount_current(&prefix->refcount) == 0) {
+		isc_result_t ret;
+		ret = _new_prefix(mctx, target, prefix->family,
+				  &prefix->add, prefix->bitlen);
+		return ret;
+	}
+
+	isc_refcount_increment(&prefix->refcount, NULL);
+
+	*target = prefix;
+	return (ISC_R_SUCCESS);
+}
+
+static int
+_comp_with_mask(void *addr, void *dest, u_int mask) {
+
+	/* Mask length of zero matches everything */
+	if (mask == 0)
+		return (1);
+
+	if (memcmp(addr, dest, mask / 8) == 0) {
+		int n = mask / 8;
+		int m = ((~0) << (8 - (mask % 8)));
+
+		if ((mask % 8) == 0 ||
+		    (((u_char *)addr)[n] & m) == (((u_char *)dest)[n] & m))
+			return (1);
+	}
+	return (0);
+}
+
+isc_result_t
+isc_radix_create(isc_mem_t *mctx, isc_radix_tree_t **target, int maxbits) {
+	isc_radix_tree_t *radix;
+
+	REQUIRE(target != NULL && *target == NULL);
+
+	radix = isc_mem_get(mctx, sizeof(isc_radix_tree_t));
+	if (radix == NULL)
+		return (ISC_R_NOMEMORY);
+
+	radix->mctx = mctx;
+	radix->maxbits = maxbits;
+	radix->head = NULL;
+	radix->num_active_node = 0;
+	radix->num_added_node = 0;
+	RUNTIME_CHECK(maxbits <= RADIX_MAXBITS); /* XXX */
+	radix->magic = RADIX_TREE_MAGIC;
+	*target = radix;
+	return (ISC_R_SUCCESS);
+}
+
+/*
+ * if func is supplied, it will be called as func(node->data)
+ * before deleting the node
+ */
+
+static void
+_clear_radix(isc_radix_tree_t *radix, isc_radix_destroyfunc_t func) {
+
+	REQUIRE(radix != NULL);
+
+	if (radix->head != NULL) {
+
+		isc_radix_node_t *Xstack[RADIX_MAXBITS+1];
+		isc_radix_node_t **Xsp = Xstack;
+		isc_radix_node_t *Xrn = radix->head;
+
+		while (Xrn != NULL) {
+			isc_radix_node_t *l = Xrn->l;
+			isc_radix_node_t *r = Xrn->r;
+
+			if (Xrn->prefix != NULL) {
+				_deref_prefix(radix->mctx, Xrn->prefix);
+				if (func != NULL && (Xrn->data[0] != NULL ||
+						     Xrn->data[1] != NULL))
+					func(Xrn->data);
+			} else {
+				INSIST(Xrn->data[0] == NULL &&
+				       Xrn->data[1] == NULL);
+			}
+
+			isc_mem_put(radix->mctx, Xrn, sizeof(*Xrn));
+			radix->num_active_node--;
+
+			if (l != NULL) {
+				if (r != NULL) {
+					*Xsp++ = r;
+				}
+				Xrn = l;
+			} else if (r != NULL) {
+				Xrn = r;
+			} else if (Xsp != Xstack) {
+				Xrn = *(--Xsp);
+			} else {
+				Xrn = NULL;
+			}
+		}
+	}
+	RUNTIME_CHECK(radix->num_active_node == 0);
+}
+
+
+void
+isc_radix_destroy(isc_radix_tree_t *radix, isc_radix_destroyfunc_t func)
+{
+	REQUIRE(radix != NULL);
+	_clear_radix(radix, func);
+	isc_mem_put(radix->mctx, radix, sizeof(*radix));
+}
+
+
+/*
+ * func will be called as func(node->prefix, node->data)
+ */
+void
+isc_radix_process(isc_radix_tree_t *radix, isc_radix_processfunc_t func)
+{
+	isc_radix_node_t *node;
+
+	REQUIRE(func != NULL);
+
+	RADIX_WALK(radix->head, node) {
+		func(node->prefix, node->data);
+	} RADIX_WALK_END;
+}
+
+
+isc_result_t
+isc_radix_search(isc_radix_tree_t *radix, isc_radix_node_t **target,
+		 isc_prefix_t *prefix)
+{
+	isc_radix_node_t *node;
+	isc_radix_node_t *stack[RADIX_MAXBITS + 1];
+	u_char *addr;
+	isc_uint32_t bitlen;
+	int tfamily = -1;
+	int cnt = 0;
+
+	REQUIRE(radix != NULL);
+	REQUIRE(prefix != NULL);
+	REQUIRE(target != NULL && *target == NULL);
+	RUNTIME_CHECK(prefix->bitlen <= radix->maxbits);
+
+	*target = NULL;
+
+	if (radix->head == NULL) {
+		return (ISC_R_NOTFOUND);
+	}
+
+	node = radix->head;
+	addr = isc_prefix_touchar(prefix);
+	bitlen = prefix->bitlen;
+
+	while (node->bit < bitlen) {
+		if (node->prefix)
+			stack[cnt++] = node;
+
+		if (BIT_TEST(addr[node->bit >> 3], 0x80 >> (node->bit & 0x07)))
+			node = node->r;
+		else
+			node = node->l;
+
+		if (node == NULL)
+			break;
+	}
+
+	if (node && node->prefix)
+		stack[cnt++] = node;
+
+	while (--cnt >= 0) {
+		node = stack[cnt];
+
+		if (_comp_with_mask(isc_prefix_tochar(node->prefix),
+				    isc_prefix_tochar(prefix),
+				    node->prefix->bitlen)) {
+			if (node->node_num[ISC_IS6(prefix->family)] != -1 &&
+				 ((*target == NULL) ||
+				  (*target)->node_num[ISC_IS6(tfamily)] >
+				   node->node_num[ISC_IS6(prefix->family)])) {
+				*target = node;
+				tfamily = prefix->family;
+			}
+		}
+	}
+
+	if (*target == NULL) {
+		return (ISC_R_NOTFOUND);
+	} else {
+		return (ISC_R_SUCCESS);
+	}
+}
+
+isc_result_t
+isc_radix_insert(isc_radix_tree_t *radix, isc_radix_node_t **target,
+		 isc_radix_node_t *source, isc_prefix_t *prefix)
+{
+	isc_radix_node_t *node, *new_node, *parent, *glue = NULL;
+	u_char *addr, *test_addr;
+	isc_uint32_t bitlen, fam, check_bit, differ_bit;
+	isc_uint32_t i, j, r;
+	isc_result_t result;
+
+	REQUIRE(radix != NULL);
+	REQUIRE(target != NULL && *target == NULL);
+	REQUIRE(prefix != NULL || (source != NULL && source->prefix != NULL));
+	RUNTIME_CHECK(prefix == NULL || prefix->bitlen <= radix->maxbits);
+
+	if (prefix == NULL)
+		prefix = source->prefix;
+
+	INSIST(prefix != NULL);
+
+	bitlen = prefix->bitlen;
+	fam = prefix->family;
+
+	if (radix->head == NULL) {
+		node = isc_mem_get(radix->mctx, sizeof(isc_radix_node_t));
+		if (node == NULL)
+			return (ISC_R_NOMEMORY);
+		node->bit = bitlen;
+		node->node_num[0] = node->node_num[1] = -1;
+		node->prefix = NULL;
+		result = _ref_prefix(radix->mctx, &node->prefix, prefix);
+		if (result != ISC_R_SUCCESS) {
+			isc_mem_put(radix->mctx, node,
+				    sizeof(isc_radix_node_t));
+			return (result);
+		}
+		node->parent = NULL;
+		node->l = node->r = NULL;
+		if (source != NULL) {
+			/*
+			 * If source is non-NULL, then we're merging in a
+			 * node from an existing radix tree.  To keep
+			 * the node_num values consistent, the calling
+			 * function will add the total number of nodes
+			 * added to num_added_node at the end of
+			 * the merge operation--we don't do it here.
+			 */
+			if (source->node_num[0] != -1)
+				node->node_num[0] = radix->num_added_node +
+						    source->node_num[0];
+			if (source->node_num[1] != -1)
+				node->node_num[1] = radix->num_added_node +
+						    source->node_num[1];
+			node->data[0] = source->data[0];
+			node->data[1] = source->data[1];
+		} else {
+			if (fam == AF_UNSPEC) {
+				/* "any" or "none" */
+				node->node_num[0] = node->node_num[1] =
+					++radix->num_added_node;
+			} else {
+				node->node_num[ISC_IS6(fam)] =
+					++radix->num_added_node;
+			}
+			node->data[0] = NULL;
+			node->data[1] = NULL;
+		}
+		radix->head = node;
+		radix->num_active_node++;
+		*target = node;
+		return (ISC_R_SUCCESS);
+	}
+
+	addr = isc_prefix_touchar(prefix);
+	node = radix->head;
+
+	while (node->bit < bitlen || node->prefix == NULL) {
+		if (node->bit < radix->maxbits &&
+		    BIT_TEST(addr[node->bit >> 3], 0x80 >> (node->bit & 0x07)))
+		{
+			if (node->r == NULL)
+				break;
+			node = node->r;
+		} else {
+			if (node->l == NULL)
+				break;
+			node = node->l;
+		}
+
+		INSIST(node != NULL);
+	}
+
+	INSIST(node->prefix != NULL);
+
+	test_addr = isc_prefix_touchar(node->prefix);
+	/* Find the first bit different. */
+	check_bit = (node->bit < bitlen) ? node->bit : bitlen;
+	differ_bit = 0;
+	for (i = 0; i*8 < check_bit; i++) {
+		if ((r = (addr[i] ^ test_addr[i])) == 0) {
+			differ_bit = (i + 1) * 8;
+			continue;
+		}
+		/* I know the better way, but for now. */
+		for (j = 0; j < 8; j++) {
+			if (BIT_TEST (r, (0x80 >> j)))
+				break;
+		}
+		/* Must be found. */
+		INSIST(j < 8);
+		differ_bit = i * 8 + j;
+		break;
+	}
+
+	if (differ_bit > check_bit)
+		differ_bit = check_bit;
+
+	parent = node->parent;
+	while (parent != NULL && parent->bit >= differ_bit) {
+		node = parent;
+		parent = node->parent;
+	}
+
+	if (differ_bit == bitlen && node->bit == bitlen) {
+		if (node->prefix != NULL) {
+			/* Set node_num only if it hasn't been set before */
+			if (source != NULL) {
+				/* Merging node */
+				if (node->node_num[0] == -1 &&
+				    source->node_num[0] != -1) {
+					node->node_num[0] =
+						radix->num_added_node +
+						source->node_num[0];
+					node->data[0] = source->data[0];
+				}
+				if (node->node_num[1] == -1 &&
+				    source->node_num[0] != -1) {
+					node->node_num[1] =
+						radix->num_added_node +
+						source->node_num[1];
+					node->data[1] = source->data[1];
+				}
+			} else {
+				if (fam == AF_UNSPEC) {
+					/* "any" or "none" */
+					int next = radix->num_added_node + 1;
+					if (node->node_num[0] == -1) {
+						node->node_num[0] = next;
+						radix->num_added_node = next;
+					}
+					if (node->node_num[1] == -1) {
+						node->node_num[1] = next;
+						radix->num_added_node = next;
+					}
+				} else {
+					if (node->node_num[ISC_IS6(fam)] == -1)
+						node->node_num[ISC_IS6(fam)]
+						   = ++radix->num_added_node;
+				}
+			}
+			*target = node;
+			return (ISC_R_SUCCESS);
+		} else {
+			result =
+				_ref_prefix(radix->mctx, &node->prefix, prefix);
+			if (result != ISC_R_SUCCESS)
+				return (result);
+		}
+		INSIST(node->data[0] == NULL && node->node_num[0] == -1 &&
+		       node->data[1] == NULL && node->node_num[1] == -1);
+		if (source != NULL) {
+			/* Merging node */
+			if (source->node_num[0] != -1) {
+				node->node_num[0] = radix->num_added_node +
+						    source->node_num[0];
+				node->data[0] = source->data[0];
+			}
+			if (source->node_num[1] != -1) {
+				node->node_num[1] = radix->num_added_node +
+						    source->node_num[1];
+				node->data[1] = source->data[1];
+			}
+		} else {
+			if (fam == AF_UNSPEC) {
+				/* "any" or "none" */
+				node->node_num[0] = node->node_num[1] =
+					++radix->num_added_node;
+			} else {
+				node->node_num[ISC_IS6(fam)] =
+					++radix->num_added_node;
+			}
+		}
+		*target = node;
+		return (ISC_R_SUCCESS);
+	}
+
+	new_node = isc_mem_get(radix->mctx, sizeof(isc_radix_node_t));
+	if (new_node == NULL)
+		return (ISC_R_NOMEMORY);
+	if (node->bit != differ_bit && bitlen != differ_bit) {
+		glue = isc_mem_get(radix->mctx, sizeof(isc_radix_node_t));
+		if (glue == NULL) {
+			isc_mem_put(radix->mctx, new_node,
+				    sizeof(isc_radix_node_t));
+			return (ISC_R_NOMEMORY);
+		}
+	}
+	new_node->bit = bitlen;
+	new_node->prefix = NULL;
+	result = _ref_prefix(radix->mctx, &new_node->prefix, prefix);
+	if (result != ISC_R_SUCCESS) {
+		isc_mem_put(radix->mctx, new_node, sizeof(isc_radix_node_t));
+		if (glue != NULL)
+			isc_mem_put(radix->mctx, glue,
+				    sizeof(isc_radix_node_t));
+		return (result);
+	}
+	new_node->parent = NULL;
+	new_node->l = new_node->r = NULL;
+	new_node->node_num[0] = new_node->node_num[1] = -1;
+	radix->num_active_node++;
+
+	if (source != NULL) {
+		/* Merging node */
+		if (source->node_num[0] != -1)
+			new_node->node_num[0] = radix->num_added_node +
+						source->node_num[0];
+		if (source->node_num[1] != -1)
+			new_node->node_num[1] = radix->num_added_node +
+						source->node_num[1];
+		new_node->data[0] = source->data[0];
+		new_node->data[1] = source->data[1];
+	} else {
+		if (fam == AF_UNSPEC) {
+			/* "any" or "none" */
+			new_node->node_num[0] = new_node->node_num[1] =
+				++radix->num_added_node;
+		} else {
+			new_node->node_num[ISC_IS6(fam)] =
+				++radix->num_added_node;
+		}
+		new_node->data[0] = NULL;
+		new_node->data[1] = NULL;
+	}
+
+	if (node->bit == differ_bit) {
+		INSIST(glue == NULL);
+		new_node->parent = node;
+		if (node->bit < radix->maxbits &&
+		    BIT_TEST(addr[node->bit >> 3], 0x80 >> (node->bit & 0x07)))
+		{
+			INSIST(node->r == NULL);
+			node->r = new_node;
+		} else {
+			INSIST(node->l == NULL);
+			node->l = new_node;
+		}
+		*target = new_node;
+		return (ISC_R_SUCCESS);
+	}
+
+	if (bitlen == differ_bit) {
+		INSIST(glue == NULL);
+		if (bitlen < radix->maxbits &&
+		    BIT_TEST(test_addr[bitlen >> 3], 0x80 >> (bitlen & 0x07))) {
+			new_node->r = node;
+		} else {
+			new_node->l = node;
+		}
+		new_node->parent = node->parent;
+		if (node->parent == NULL) {
+			INSIST(radix->head == node);
+			radix->head = new_node;
+		} else if (node->parent->r == node) {
+			node->parent->r = new_node;
+		} else {
+			node->parent->l = new_node;
+		}
+		node->parent = new_node;
+	} else {
+		INSIST(glue != NULL);
+		glue->bit = differ_bit;
+		glue->prefix = NULL;
+		glue->parent = node->parent;
+		glue->data[0] = glue->data[1] = NULL;
+		glue->node_num[0] = glue->node_num[1] = -1;
+		radix->num_active_node++;
+		if (differ_bit < radix->maxbits &&
+		    BIT_TEST(addr[differ_bit>>3], 0x80 >> (differ_bit & 07))) {
+			glue->r = new_node;
+			glue->l = node;
+		} else {
+			glue->r = node;
+			glue->l = new_node;
+		}
+		new_node->parent = glue;
+
+		if (node->parent == NULL) {
+			INSIST(radix->head == node);
+			radix->head = glue;
+		} else if (node->parent->r == node) {
+			node->parent->r = glue;
+		} else {
+			node->parent->l = glue;
+		}
+		node->parent = glue;
+	}
+
+	*target = new_node;
+	return (ISC_R_SUCCESS);
+}
+
+void
+isc_radix_remove(isc_radix_tree_t *radix, isc_radix_node_t *node) {
+	isc_radix_node_t *parent, *child;
+
+	REQUIRE(radix != NULL);
+	REQUIRE(node != NULL);
+
+	if (node->r && node->l) {
+		/*
+		 * This might be a placeholder node -- have to check and
+		 * make sure there is a prefix associated with it!
+		 */
+		if (node->prefix != NULL)
+			_deref_prefix(radix->mctx, node->prefix);
+
+		node->prefix = NULL;
+		node->data[0] = node->data[1] = NULL;
+		return;
+	}
+
+	if (node->r == NULL && node->l == NULL) {
+		parent = node->parent;
+		_deref_prefix(radix->mctx, node->prefix);
+		isc_mem_put(radix->mctx, node, sizeof(*node));
+		radix->num_active_node--;
+
+		if (parent == NULL) {
+			INSIST(radix->head == node);
+			radix->head = NULL;
+			return;
+		}
+
+		if (parent->r == node) {
+			parent->r = NULL;
+			child = parent->l;
+		} else {
+			INSIST(parent->l == node);
+			parent->l = NULL;
+			child = parent->r;
+		}
+
+		if (parent->prefix)
+			return;
+
+		/* We need to remove parent too. */
+
+		if (parent->parent == NULL) {
+			INSIST(radix->head == parent);
+			radix->head = child;
+		} else if (parent->parent->r == parent) {
+			parent->parent->r = child;
+		} else {
+			INSIST(parent->parent->l == parent);
+			parent->parent->l = child;
+		}
+		child->parent = parent->parent;
+		isc_mem_put(radix->mctx, parent, sizeof(*parent));
+		radix->num_active_node--;
+		return;
+	}
+
+	if (node->r) {
+		child = node->r;
+	} else {
+		INSIST(node->l != NULL);
+		child = node->l;
+	}
+	parent = node->parent;
+	child->parent = parent;
+
+	_deref_prefix(radix->mctx, node->prefix);
+	isc_mem_put(radix->mctx, node, sizeof(*node));
+	radix->num_active_node--;
+
+	if (parent == NULL) {
+		INSIST(radix->head == node);
+		radix->head = child;
+		return;
+	}
+
+	if (parent->r == node) {
+		parent->r = child;
+	} else {
+		INSIST(parent->l == node);
+		parent->l = child;
+	}
+}
+
+/*
+Local Variables:
+c-basic-offset: 4
+indent-tabs-mode: t
+End:
+*/
diff --git a/contrib/bind9/lib/isc/random.c b/contrib/bind9/lib/isc/random.c
index f6c7d6e..0329abd 100644
--- a/contrib/bind9/lib/isc/random.c
+++ b/contrib/bind9/lib/isc/random.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: random.c,v 1.21.18.2 2005/04/29 00:16:48 marka Exp $ */
+/* $Id: random.c,v 1.25 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/ratelimiter.c b/contrib/bind9/lib/isc/ratelimiter.c
index 3d65139..07bcc7c 100644
--- a/contrib/bind9/lib/isc/ratelimiter.c
+++ b/contrib/bind9/lib/isc/ratelimiter.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ratelimiter.c,v 1.21.18.2 2005/04/29 00:16:49 marka Exp $ */
+/* $Id: ratelimiter.c,v 1.25 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/refcount.c b/contrib/bind9/lib/isc/refcount.c
index d5095eb..36dfff2 100644
--- a/contrib/bind9/lib/isc/refcount.c
+++ b/contrib/bind9/lib/isc/refcount.c
@@ -1,7 +1,7 @@
 /*
- * Copyright (C) 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: refcount.c,v 1.2.2.2 2005/07/25 00:51:46 marka Exp $ */
+/* $Id: refcount.c,v 1.5 2007/06/19 23:47:17 tbox Exp $ */
 
 #include <config.h>
 
diff --git a/contrib/bind9/lib/isc/region.c b/contrib/bind9/lib/isc/region.c
index bc32b86..cf64979 100644
--- a/contrib/bind9/lib/isc/region.c
+++ b/contrib/bind9/lib/isc/region.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: region.c,v 1.3.18.2 2005/04/29 00:16:49 marka Exp $ */
+/* $Id: region.c,v 1.7 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/result.c b/contrib/bind9/lib/isc/result.c
index e0c8653..5713580 100644
--- a/contrib/bind9/lib/isc/result.c
+++ b/contrib/bind9/lib/isc/result.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: result.c,v 1.62.18.6 2005/06/22 22:05:48 marka Exp $ */
+/* $Id: result.c,v 1.71 2008/09/25 04:02:39 tbox Exp $ */
 
 /*! \file */
 
@@ -100,7 +100,8 @@ static const char *text[ISC_R_NRESULTS] = {
 	"not a valid number",			/*%< 56 */
 	"disabled",				/*%< 57 */
 	"max size",				/*%< 58 */
-	"invalid address format"		/*%< 59 */
+	"invalid address format",		/*%< 59 */
+	"bad base32 encoding",			/*%< 60 */
 };
 
 #define ISC_RESULT_RESULTSET			2
diff --git a/contrib/bind9/lib/isc/rwlock.c b/contrib/bind9/lib/isc/rwlock.c
index 69b8f56..ca8e83d 100644
--- a/contrib/bind9/lib/isc/rwlock.c
+++ b/contrib/bind9/lib/isc/rwlock.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: rwlock.c,v 1.37.18.5 2005/07/12 01:22:30 marka Exp $ */
+/* $Id: rwlock.c,v 1.44.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
 /*! \file */
 
@@ -45,7 +45,7 @@
 
 #ifdef ISC_RWLOCK_TRACE
 #include <stdio.h>		/* Required for fprintf/stderr. */
-#include <isc/thread.h>		/* Requried for isc_thread_self(). */
+#include <isc/thread.h>		/* Required for isc_thread_self(). */
 
 static void
 print_lock(const char *operation, isc_rwlock_t *rwl, isc_rwlocktype_t type) {
@@ -55,17 +55,17 @@ print_lock(const char *operation, isc_rwlock_t *rwl, isc_rwlocktype_t type) {
 			       "rwlock %p thread %lu %s(%s): %s, %u active, "
 			       "%u granted, %u rwaiting, %u wwaiting\n"),
 		rwl, isc_thread_self(), operation,
-		(type == isc_rwlocktype_read ? 
+		(type == isc_rwlocktype_read ?
 		 isc_msgcat_get(isc_msgcat, ISC_MSGSET_RWLOCK,
 				ISC_MSG_READ, "read") :
 		 isc_msgcat_get(isc_msgcat, ISC_MSGSET_RWLOCK,
 				ISC_MSG_WRITE, "write")),
-	        (rwl->type == isc_rwlocktype_read ?
+		(rwl->type == isc_rwlocktype_read ?
 		 isc_msgcat_get(isc_msgcat, ISC_MSGSET_RWLOCK,
-				ISC_MSG_READING, "reading") : 
+				ISC_MSG_READING, "reading") :
 		 isc_msgcat_get(isc_msgcat, ISC_MSGSET_RWLOCK,
 				ISC_MSG_WRITING, "writing")),
-	        rwl->active, rwl->granted, rwl->readers_waiting,
+		rwl->active, rwl->granted, rwl->readers_waiting,
 		rwl->writers_waiting);
 }
 #endif
@@ -381,7 +381,7 @@ isc_rwlock_trylock(isc_rwlock_t *rwl, isc_rwlocktype_t type) {
 				BROADCAST(&rwl->writeable);
 				UNLOCK(&rwl->lock);
 			}
-			
+
 			return (ISC_R_LOCKBUSY);
 		}
 	} else {
@@ -434,7 +434,7 @@ isc_rwlock_tryupgrade(isc_rwlock_t *rwl) {
 		return (ISC_R_LOCKBUSY);
 
 	return (ISC_R_SUCCESS);
-	
+
 }
 
 void
@@ -555,7 +555,7 @@ doit(isc_rwlock_t *rwl, isc_rwlocktype_t type, isc_boolean_t nonblock) {
 			    ((rwl->active == 0 ||
 			      (rwl->type == isc_rwlocktype_read &&
 			       (rwl->writers_waiting == 0 ||
-			        rwl->granted < rwl->read_quota)))))
+				rwl->granted < rwl->read_quota)))))
 			{
 				rwl->type = isc_rwlocktype_read;
 				rwl->active++;
@@ -751,7 +751,7 @@ isc_rwlock_lock(isc_rwlock_t *rwl, isc_rwlocktype_t type) {
 		rwl->type = isc_rwlocktype_write;
 		rwl->active = 1;
 	}
-        return (ISC_R_SUCCESS);
+	return (ISC_R_SUCCESS);
 }
 
 isc_result_t
@@ -766,7 +766,7 @@ isc_rwlock_tryupgrade(isc_rwlock_t *rwl) {
 	REQUIRE(VALID_RWLOCK(rwl));
 	REQUIRE(rwl->type == isc_rwlocktype_read);
 	REQUIRE(rwl->active != 0);
-	
+
 	/* If we are the only reader then succeed. */
 	if (rwl->active == 1)
 		rwl->type = isc_rwlocktype_write;
diff --git a/contrib/bind9/lib/isc/serial.c b/contrib/bind9/lib/isc/serial.c
index 5d1bde7..b43aac7 100644
--- a/contrib/bind9/lib/isc/serial.c
+++ b/contrib/bind9/lib/isc/serial.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: serial.c,v 1.8.18.2 2005/04/29 00:16:49 marka Exp $ */
+/* $Id: serial.c,v 1.12 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/sha1.c b/contrib/bind9/lib/isc/sha1.c
index 6f4af6d..3575288 100644
--- a/contrib/bind9/lib/isc/sha1.c
+++ b/contrib/bind9/lib/isc/sha1.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: sha1.c,v 1.14.18.2 2005/04/29 00:16:49 marka Exp $ */
+/* $Id: sha1.c,v 1.18 2007/06/19 23:47:17 tbox Exp $ */
 
 /*	$NetBSD: sha1.c,v 1.5 2000/01/22 22:19:14 mycroft Exp $	*/
 /*	$OpenBSD: sha1.c,v 1.9 1997/07/23 21:12:32 kstailey Exp $	*/
diff --git a/contrib/bind9/lib/isc/sha2.c b/contrib/bind9/lib/isc/sha2.c
index 7b41a28..70eea4f 100644
--- a/contrib/bind9/lib/isc/sha2.c
+++ b/contrib/bind9/lib/isc/sha2.c
@@ -1,7 +1,7 @@
 /*
- * Copyright (C) 2005, 2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2005-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: sha2.c,v 1.2.2.12 2006/08/16 03:18:14 marka Exp $ */
+/* $Id: sha2.c,v 1.13.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
 /*	$FreeBSD$	*/
 /*	$KAME: sha2.c,v 1.8 2001/11/08 01:07:52 itojun Exp $	*/
@@ -39,7 +39,7 @@
  * 3. Neither the name of the copyright holder nor the names of contributors
  *    may be used to endorse or promote products derived from this software
  *    without specific prior written permission.
- * 
+ *
  * THIS SOFTWARE IS PROVIDED BY THE AUTHOR(S) AND CONTRIBUTOR(S) ``AS IS'' AND
  * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
@@ -72,7 +72,7 @@
  *
  * or define below:
  *
- *   #define ISC_SHA2_UNROLL_TRANSFORM
+ *   \#define ISC_SHA2_UNROLL_TRANSFORM
  *
  */
 
@@ -83,21 +83,21 @@
  * Please make sure that your system defines BYTE_ORDER.  If your
  * architecture is little-endian, make sure it also defines
  * LITTLE_ENDIAN and that the two (BYTE_ORDER and LITTLE_ENDIAN) are
- * equivilent.
+ * equivalent.
  *
  * If your system does not define the above, then you can do so by
  * hand like this:
  *
- *   #define LITTLE_ENDIAN 1234
- *   #define BIG_ENDIAN    4321
+ *   \#define LITTLE_ENDIAN 1234
+ *   \#define BIG_ENDIAN    4321
  *
  * And for little-endian machines, add:
  *
- *   #define BYTE_ORDER LITTLE_ENDIAN 
+ *   \#define BYTE_ORDER LITTLE_ENDIAN
  *
  * Or for big-endian machines:
  *
- *   #define BYTE_ORDER BIG_ENDIAN
+ *   \#define BYTE_ORDER BIG_ENDIAN
  *
  * The FreeBSD machine this was written on defines BYTE_ORDER
  * appropriately by including <sys/types.h> (which in turn includes
@@ -414,12 +414,12 @@ isc_sha224_init(isc_sha224_t *context) {
 	context->bitcount = 0;
 }
 
-void 
+void
 isc_sha224_update(isc_sha224_t *context, const isc_uint8_t* data, size_t len) {
 	isc_sha256_update((isc_sha256_t *)context, data, len);
 }
 
-void 
+void
 isc_sha224_final(isc_uint8_t digest[], isc_sha224_t *context) {
 	isc_uint8_t sha256_digest[ISC_SHA256_DIGESTLENGTH];
 	isc_sha256_final(sha256_digest, (isc_sha256_t *)context);
@@ -453,7 +453,7 @@ isc_sha224_end(isc_sha224_t *context, char buffer[]) {
 
 char*
 isc_sha224_data(const isc_uint8_t *data, size_t len,
-	        char digest[ISC_SHA224_DIGESTSTRINGLENGTH])
+		char digest[ISC_SHA224_DIGESTSTRINGLENGTH])
 {
 	isc_sha224_t context;
 
@@ -483,7 +483,7 @@ isc_sha256_init(isc_sha256_t *context) {
 #define ROUND256_0_TO_15(a,b,c,d,e,f,g,h)	\
 	REVERSE32(*data++, W256[j]); \
 	T1 = (h) + Sigma1_256(e) + Ch((e), (f), (g)) + \
-             K256[j] + W256[j]; \
+	     K256[j] + W256[j]; \
 	(d) += T1; \
 	(h) = T1 + Sigma0_256(a) + Maj((a), (b), (c)); \
 	j++
@@ -615,11 +615,11 @@ isc_sha256_transform(isc_sha256_t *context, const isc_uint32_t* data) {
 		/* Part of the message block expansion: */
 		s0 = W256[(j+1)&0x0f];
 		s0 = sigma0_256(s0);
-		s1 = W256[(j+14)&0x0f];	
+		s1 = W256[(j+14)&0x0f];
 		s1 = sigma1_256(s1);
 
 		/* Apply the SHA-256 compression function to update a..h */
-		T1 = h + Sigma1_256(e) + Ch(e, f, g) + K256[j] + 
+		T1 = h + Sigma1_256(e) + Ch(e, f, g) + K256[j] +
 		     (W256[j&0x0f] += s1 + W256[(j+9)&0x0f] + s0);
 		T2 = Sigma0_256(a) + Maj(a, b, c);
 		h = g;
@@ -828,7 +828,7 @@ isc_sha512_init(isc_sha512_t *context) {
 #define ROUND512_0_TO_15(a,b,c,d,e,f,g,h)	\
 	REVERSE64(*data++, W512[j]); \
 	T1 = (h) + Sigma1_512(e) + Ch((e), (f), (g)) + \
-             K512[j] + W512[j]; \
+	     K512[j] + W512[j]; \
 	(d) += T1, \
 	(h) = T1 + Sigma0_512(a) + Maj((a), (b), (c)), \
 	j++
@@ -838,7 +838,7 @@ isc_sha512_init(isc_sha512_t *context) {
 
 #define ROUND512_0_TO_15(a,b,c,d,e,f,g,h)	\
 	T1 = (h) + Sigma1_512(e) + Ch((e), (f), (g)) + \
-             K512[j] + (W512[j] = *data++); \
+	     K512[j] + (W512[j] = *data++); \
 	(d) += T1; \
 	(h) = T1 + Sigma0_512(a) + Maj((a), (b), (c)); \
 	j++
@@ -851,7 +851,7 @@ isc_sha512_init(isc_sha512_t *context) {
 	s1 = W512[(j+14)&0x0f]; \
 	s1 = sigma1_512(s1); \
 	T1 = (h) + Sigma1_512(e) + Ch((e), (f), (g)) + K512[j] + \
-             (W512[j&0x0f] += s1 + W512[(j+9)&0x0f] + s0); \
+	     (W512[j&0x0f] += s1 + W512[(j+9)&0x0f] + s0); \
 	(d) += T1; \
 	(h) = T1 + Sigma0_512(a) + Maj((a), (b), (c)); \
 	j++
@@ -1163,12 +1163,12 @@ isc_sha384_init(isc_sha384_t *context) {
 	context->bitcount[0] = context->bitcount[1] = 0;
 }
 
-void 
+void
 isc_sha384_update(isc_sha384_t *context, const isc_uint8_t* data, size_t len) {
 	isc_sha512_update((isc_sha512_t *)context, data, len);
 }
 
-void 
+void
 isc_sha384_final(isc_uint8_t digest[], isc_sha384_t *context) {
 	isc_uint64_t	*d = (isc_uint64_t*)digest;
 
@@ -1224,7 +1224,7 @@ isc_sha384_end(isc_sha384_t *context, char buffer[]) {
 
 char*
 isc_sha384_data(const isc_uint8_t *data, size_t len,
-	        char digest[ISC_SHA384_DIGESTSTRINGLENGTH])
+		char digest[ISC_SHA384_DIGESTSTRINGLENGTH])
 {
 	isc_sha384_t context;
 
diff --git a/contrib/bind9/lib/isc/sockaddr.c b/contrib/bind9/lib/isc/sockaddr.c
index 2fd73af..62975df 100644
--- a/contrib/bind9/lib/isc/sockaddr.c
+++ b/contrib/bind9/lib/isc/sockaddr.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: sockaddr.c,v 1.59.18.9 2006/06/21 01:25:40 marka Exp $ */
+/* $Id: sockaddr.c,v 1.70 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/sparc64/Makefile.in b/contrib/bind9/lib/isc/sparc64/Makefile.in
index c8e77e4..324db07 100644
--- a/contrib/bind9/lib/isc/sparc64/Makefile.in
+++ b/contrib/bind9/lib/isc/sparc64/Makefile.in
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.2.2.1 2007/09/14 04:26:38 marka Exp $
+# $Id: Makefile.in,v 1.2 2007/09/14 04:09:59 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/sparc64/include/Makefile.in b/contrib/bind9/lib/isc/sparc64/include/Makefile.in
index f4dd2f6..f1d8bdd 100644
--- a/contrib/bind9/lib/isc/sparc64/include/Makefile.in
+++ b/contrib/bind9/lib/isc/sparc64/include/Makefile.in
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.2.2.1 2007/09/14 04:26:38 marka Exp $
+# $Id: Makefile.in,v 1.2 2007/09/14 04:09:59 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/sparc64/include/isc/Makefile.in b/contrib/bind9/lib/isc/sparc64/include/isc/Makefile.in
index 6760ce6..5f116ca 100644
--- a/contrib/bind9/lib/isc/sparc64/include/isc/Makefile.in
+++ b/contrib/bind9/lib/isc/sparc64/include/isc/Makefile.in
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.2.2.1 2007/09/14 04:26:38 marka Exp $
+# $Id: Makefile.in,v 1.2 2007/09/14 04:09:59 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/sparc64/include/isc/atomic.h b/contrib/bind9/lib/isc/sparc64/include/isc/atomic.h
index 5c254cf..b920095 100644
--- a/contrib/bind9/lib/isc/sparc64/include/isc/atomic.h
+++ b/contrib/bind9/lib/isc/sparc64/include/isc/atomic.h
@@ -1,7 +1,7 @@
 /*
- * Copyright (C) 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: atomic.h,v 1.2.2.2 2005/06/16 22:01:02 jinmei Exp $ */
+/* $Id: atomic.h,v 1.5 2007/06/19 23:47:18 tbox Exp $ */
 
 /*
  * This code was written based on FreeBSD's kernel source whose copyright
diff --git a/contrib/bind9/lib/isc/stats.c b/contrib/bind9/lib/isc/stats.c
new file mode 100644
index 0000000..9e4e089
--- /dev/null
+++ b/contrib/bind9/lib/isc/stats.c
@@ -0,0 +1,326 @@
+/*
+ * Copyright (C) 2009  Internet Systems Consortium, Inc. ("ISC")
+ *
+ * Permission to use, copy, modify, and/or 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: stats.c,v 1.3.6.2 2009/01/29 23:47:44 tbox Exp $ */
+
+/*! \file */
+
+#include <config.h>
+
+#include <string.h>
+
+#include <isc/atomic.h>
+#include <isc/buffer.h>
+#include <isc/magic.h>
+#include <isc/mem.h>
+#include <isc/platform.h>
+#include <isc/print.h>
+#include <isc/rwlock.h>
+#include <isc/stats.h>
+#include <isc/util.h>
+
+#define ISC_STATS_MAGIC			ISC_MAGIC('S', 't', 'a', 't')
+#define ISC_STATS_VALID(x)		ISC_MAGIC_VALID(x, ISC_STATS_MAGIC)
+
+#ifndef ISC_STATS_USEMULTIFIELDS
+#if defined(ISC_RWLOCK_USEATOMIC) && defined(ISC_PLATFORM_HAVEXADD) && !defined(ISC_PLATFORM_HAVEXADDQ)
+#define ISC_STATS_USEMULTIFIELDS 1
+#else
+#define ISC_STATS_USEMULTIFIELDS 0
+#endif
+#endif	/* ISC_STATS_USEMULTIFIELDS */
+
+#if ISC_STATS_USEMULTIFIELDS
+typedef struct {
+	isc_uint32_t hi;
+	isc_uint32_t lo;
+} isc_stat_t;
+#else
+typedef isc_uint64_t isc_stat_t;
+#endif
+
+struct isc_stats {
+	/*% Unlocked */
+	unsigned int	magic;
+	isc_mem_t	*mctx;
+	int		ncounters;
+
+	isc_mutex_t	lock;
+	unsigned int	references; /* locked by lock */
+
+	/*%
+	 * Locked by counterlock or unlocked if efficient rwlock is not
+	 * available.
+	 */
+#ifdef ISC_RWLOCK_USEATOMIC
+	isc_rwlock_t	counterlock;
+#endif
+	isc_stat_t	*counters;
+
+	/*%
+	 * We don't want to lock the counters while we are dumping, so we first
+	 * copy the current counter values into a local array.  This buffer
+	 * will be used as the copy destination.  It's allocated on creation
+	 * of the stats structure so that the dump operation won't fail due
+	 * to memory allocation failure.
+	 * XXX: this approach is weird for non-threaded build because the
+	 * additional memory and the copy overhead could be avoided.  We prefer
+	 * simplicity here, however, under the assumption that this function
+	 * should be only rarely called.
+	 */
+	isc_uint64_t	*copiedcounters;
+};
+
+static isc_result_t
+create_stats(isc_mem_t *mctx, int ncounters, isc_stats_t **statsp) {
+	isc_stats_t *stats;
+	isc_result_t result = ISC_R_SUCCESS;
+
+	REQUIRE(statsp != NULL && *statsp == NULL);
+
+	stats = isc_mem_get(mctx, sizeof(*stats));
+	if (stats == NULL)
+		return (ISC_R_NOMEMORY);
+
+	result = isc_mutex_init(&stats->lock);
+	if (result != ISC_R_SUCCESS)
+		goto clean_stats;
+
+	stats->counters = isc_mem_get(mctx, sizeof(isc_stat_t) * ncounters);
+	if (stats->counters == NULL) {
+		result = ISC_R_NOMEMORY;
+		goto clean_mutex;
+	}
+	stats->copiedcounters = isc_mem_get(mctx,
+					    sizeof(isc_uint64_t) * ncounters);
+	if (stats->copiedcounters == NULL) {
+		result = ISC_R_NOMEMORY;
+		goto clean_counters;
+	}
+
+#ifdef ISC_RWLOCK_USEATOMIC
+	result = isc_rwlock_init(&stats->counterlock, 0, 0);
+	if (result != ISC_R_SUCCESS)
+		goto clean_copiedcounters;
+#endif
+
+	stats->references = 1;
+	memset(stats->counters, 0, sizeof(isc_stat_t) * ncounters);
+	stats->mctx = NULL;
+	isc_mem_attach(mctx, &stats->mctx);
+	stats->ncounters = ncounters;
+	stats->magic = ISC_STATS_MAGIC;
+
+	*statsp = stats;
+
+	return (result);
+
+clean_counters:
+	isc_mem_put(mctx, stats->counters, sizeof(isc_stat_t) * ncounters);
+
+#ifdef ISC_RWLOCK_USEATOMIC
+clean_copiedcounters:
+	isc_mem_put(mctx, stats->copiedcounters,
+		    sizeof(isc_stat_t) * ncounters);
+#endif
+
+clean_mutex:
+	DESTROYLOCK(&stats->lock);
+
+clean_stats:
+	isc_mem_put(mctx, stats, sizeof(*stats));
+
+	return (result);
+}
+
+void
+isc_stats_attach(isc_stats_t *stats, isc_stats_t **statsp) {
+	REQUIRE(ISC_STATS_VALID(stats));
+	REQUIRE(statsp != NULL && *statsp == NULL);
+
+	LOCK(&stats->lock);
+	stats->references++;
+	UNLOCK(&stats->lock);
+
+	*statsp = stats;
+}
+
+void
+isc_stats_detach(isc_stats_t **statsp) {
+	isc_stats_t *stats;
+
+	REQUIRE(statsp != NULL && ISC_STATS_VALID(*statsp));
+
+	stats = *statsp;
+	*statsp = NULL;
+
+	LOCK(&stats->lock);
+	stats->references--;
+	UNLOCK(&stats->lock);
+
+	if (stats->references == 0) {
+		isc_mem_put(stats->mctx, stats->copiedcounters,
+			    sizeof(isc_stat_t) * stats->ncounters);
+		isc_mem_put(stats->mctx, stats->counters,
+			    sizeof(isc_stat_t) * stats->ncounters);
+		DESTROYLOCK(&stats->lock);
+#ifdef ISC_RWLOCK_USEATOMIC
+		isc_rwlock_destroy(&stats->counterlock);
+#endif
+		isc_mem_putanddetach(&stats->mctx, stats, sizeof(*stats));
+	}
+}
+
+int
+isc_stats_ncounters(isc_stats_t *stats) {
+	REQUIRE(ISC_STATS_VALID(stats));
+
+	return (stats->ncounters);
+}
+
+static inline void
+incrementcounter(isc_stats_t *stats, int counter) {
+	isc_int32_t prev;
+
+#ifdef ISC_RWLOCK_USEATOMIC
+	/*
+	 * We use a "read" lock to prevent other threads from reading the
+	 * counter while we "writing" a counter field.  The write access itself
+	 * is protected by the atomic operation.
+	 */
+	isc_rwlock_lock(&stats->counterlock, isc_rwlocktype_read);
+#endif
+
+#if ISC_STATS_USEMULTIFIELDS
+	prev = isc_atomic_xadd((isc_int32_t *)&stats->counters[counter].lo, 1);
+	/*
+	 * If the lower 32-bit field overflows, increment the higher field.
+	 * Note that it's *theoretically* possible that the lower field
+	 * overlaps again before the higher field is incremented.  It doesn't
+	 * matter, however, because we don't read the value until
+	 * isc_stats_copy() is called where the whole process is protected
+	 * by the write (exclusive) lock.
+	 */
+	if (prev == (isc_int32_t)0xffffffff)
+		isc_atomic_xadd((isc_int32_t *)&stats->counters[counter].hi, 1);
+#elif defined(ISC_PLATFORM_HAVEXADDQ)
+	UNUSED(prev);
+	isc_atomic_xaddq((isc_int64_t *)&stats->counters[counter], 1);
+#else
+	UNUSED(prev);
+	stats->counters[counter]++;
+#endif
+
+#ifdef ISC_RWLOCK_USEATOMIC
+	isc_rwlock_unlock(&stats->counterlock, isc_rwlocktype_read);
+#endif
+}
+
+static inline void
+decrementcounter(isc_stats_t *stats, int counter) {
+	isc_int32_t prev;
+
+#ifdef ISC_RWLOCK_USEATOMIC
+	isc_rwlock_lock(&stats->counterlock, isc_rwlocktype_read);
+#endif
+
+#if ISC_STATS_USEMULTIFIELDS
+	prev = isc_atomic_xadd((isc_int32_t *)&stats->counters[counter].lo, -1);
+	if (prev == 0)
+		isc_atomic_xadd((isc_int32_t *)&stats->counters[counter].hi,
+				-1);
+#elif defined(ISC_PLATFORM_HAVEXADDQ)
+	UNUSED(prev);
+	isc_atomic_xaddq((isc_int64_t *)&stats->counters[counter], -1);
+#else
+	UNUSED(prev);
+	stats->counters[counter]--;
+#endif
+
+#ifdef ISC_RWLOCK_USEATOMIC
+	isc_rwlock_unlock(&stats->counterlock, isc_rwlocktype_read);
+#endif
+}
+
+static void
+copy_counters(isc_stats_t *stats) {
+	int i;
+
+#ifdef ISC_RWLOCK_USEATOMIC
+	/*
+	 * We use a "write" lock before "reading" the statistics counters as
+	 * an exclusive lock.
+	 */
+	isc_rwlock_lock(&stats->counterlock, isc_rwlocktype_write);
+#endif
+
+#if ISC_STATS_USEMULTIFIELDS
+	for (i = 0; i < stats->ncounters; i++) {
+		stats->copiedcounters[i] =
+				(isc_uint64_t)(stats->counters[i].hi) << 32 |
+				stats->counters[i].lo;
+	}
+#else
+	UNUSED(i);
+	memcpy(stats->copiedcounters, stats->counters,
+	       stats->ncounters * sizeof(isc_stat_t));
+#endif
+
+#ifdef ISC_RWLOCK_USEATOMIC
+	isc_rwlock_unlock(&stats->counterlock, isc_rwlocktype_write);
+#endif
+}
+
+isc_result_t
+isc_stats_create(isc_mem_t *mctx, isc_stats_t **statsp, int ncounters) {
+	REQUIRE(statsp != NULL && *statsp == NULL);
+
+	return (create_stats(mctx, ncounters, statsp));
+}
+
+void
+isc_stats_increment(isc_stats_t *stats, isc_statscounter_t counter) {
+	REQUIRE(ISC_STATS_VALID(stats));
+	REQUIRE(counter < stats->ncounters);
+
+	incrementcounter(stats, (int)counter);
+}
+
+void
+isc_stats_decrement(isc_stats_t *stats, isc_statscounter_t counter) {
+	REQUIRE(ISC_STATS_VALID(stats));
+	REQUIRE(counter < stats->ncounters);
+
+	decrementcounter(stats, (int)counter);
+}
+
+void
+isc_stats_dump(isc_stats_t *stats, isc_stats_dumper_t dump_fn,
+	       void *arg, unsigned int options)
+{
+	int i;
+
+	REQUIRE(ISC_STATS_VALID(stats));
+
+	copy_counters(stats);
+
+	for (i = 0; i < stats->ncounters; i++) {
+		if ((options & ISC_STATSDUMP_VERBOSE) == 0 &&
+		    stats->copiedcounters[i] == 0)
+				continue;
+		dump_fn((isc_statscounter_t)i, stats->copiedcounters[i], arg);
+	}
+}
diff --git a/contrib/bind9/lib/isc/string.c b/contrib/bind9/lib/isc/string.c
index c09fa4f..b9c43e7 100644
--- a/contrib/bind9/lib/isc/string.c
+++ b/contrib/bind9/lib/isc/string.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: string.c,v 1.10.18.7 2006/10/03 23:50:51 marka Exp $ */
+/* $Id: string.c,v 1.20 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/strtoul.c b/contrib/bind9/lib/isc/strtoul.c
index 5070c08..18d93e2 100644
--- a/contrib/bind9/lib/isc/strtoul.c
+++ b/contrib/bind9/lib/isc/strtoul.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -53,7 +53,7 @@
 static char sccsid[] = "@(#)strtoul.c	8.1 (Berkeley) 6/4/93";
 #endif /* LIBC_SCCS and not lint */
 
-/* $Id: strtoul.c,v 1.3.18.2 2005/04/29 00:16:50 marka Exp $ */
+/* $Id: strtoul.c,v 1.7 2007/06/19 23:47:17 tbox Exp $ */
 
 #include <config.h>
 
diff --git a/contrib/bind9/lib/isc/symtab.c b/contrib/bind9/lib/isc/symtab.c
index 716ca88..9f8e798 100644
--- a/contrib/bind9/lib/isc/symtab.c
+++ b/contrib/bind9/lib/isc/symtab.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1996-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: symtab.c,v 1.26.18.2 2005/04/29 00:16:50 marka Exp $ */
+/* $Id: symtab.c,v 1.30 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/task.c b/contrib/bind9/lib/isc/task.c
index 5c80712..a630173 100644
--- a/contrib/bind9/lib/isc/task.c
+++ b/contrib/bind9/lib/isc/task.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: task.c,v 1.91.18.6 2006/01/04 23:50:23 marka Exp $ */
+/* $Id: task.c,v 1.107 2008/03/27 23:46:57 tbox Exp $ */
 
 /*! \file
  * \author Principal Author: Bob Halley
@@ -38,13 +38,12 @@
 #include <isc/task.h>
 #include <isc/thread.h>
 #include <isc/util.h>
+#include <isc/xml.h>
 
 #ifndef ISC_PLATFORM_USETHREADS
 #include "task_p.h"
 #endif /* ISC_PLATFORM_USETHREADS */
 
-#define ISC_TASK_NAMES 1
-
 #ifdef ISC_TASK_TRACE
 #define XTRACE(m)		fprintf(stderr, "task %p thread %lu: %s\n", \
 				       task, isc_thread_self(), (m))
@@ -67,6 +66,12 @@ typedef enum {
 	task_state_done
 } task_state_t;
 
+#ifdef HAVE_LIBXML2
+static const char *statenames[] = {
+	"idle", "ready", "running", "done",
+};
+#endif
+
 #define TASK_MAGIC			ISC_MAGIC('T', 'A', 'S', 'K')
 #define VALID_TASK(t)			ISC_MAGIC_VALID(t, TASK_MAGIC)
 
@@ -83,10 +88,8 @@ struct isc_task {
 	unsigned int			quantum;
 	unsigned int			flags;
 	isc_stdtime_t			now;
-#ifdef ISC_TASK_NAMES
 	char				name[16];
 	void *				tag;
-#endif
 	/* Locked by task manager lock. */
 	LINK(isc_task_t)		link;
 	LINK(isc_task_t)		ready_link;
@@ -196,10 +199,8 @@ isc_task_create(isc_taskmgr_t *manager, unsigned int quantum,
 	task->quantum = quantum;
 	task->flags = 0;
 	task->now = 0;
-#ifdef ISC_TASK_NAMES
 	memset(task->name, 0, sizeof(task->name));
 	task->tag = NULL;
-#endif
 	INIT_LINK(task, link);
 	INIT_LINK(task, ready_link);
 
@@ -694,17 +695,11 @@ isc_task_setname(isc_task_t *task, const char *name, void *tag) {
 
 	REQUIRE(VALID_TASK(task));
 
-#ifdef ISC_TASK_NAMES
 	LOCK(&task->lock);
 	memset(task->name, 0, sizeof(task->name));
 	strncpy(task->name, name, sizeof(task->name) - 1);
 	task->tag = tag;
 	UNLOCK(&task->lock);
-#else
-	UNUSED(name);
-	UNUSED(tag);
-#endif
-
 }
 
 const char *
@@ -806,9 +801,9 @@ dispatch(isc_taskmgr_t *manager) {
 		 * task lock.
 		 */
 		while ((EMPTY(manager->ready_tasks) ||
-		        manager->exclusive_requested) &&
-		  	!FINISHED(manager)) 
-	  	{
+			manager->exclusive_requested) &&
+			!FINISHED(manager))
+		{
 			XTHREADTRACE(isc_msgcat_get(isc_msgcat,
 						    ISC_MSGSET_GENERAL,
 						    ISC_MSG_WAIT, "wait"));
@@ -1021,7 +1016,7 @@ manager_free(isc_taskmgr_t *manager) {
 	isc_mem_t *mctx;
 
 #ifdef ISC_PLATFORM_USETHREADS
-	(void)isc_condition_destroy(&manager->exclusive_granted);	
+	(void)isc_condition_destroy(&manager->exclusive_granted);
 	(void)isc_condition_destroy(&manager->work_available);
 	isc_mem_free(manager->mctx, manager->threads);
 #endif /* ISC_PLATFORM_USETHREADS */
@@ -1263,19 +1258,19 @@ isc__taskmgr_dispatch(void) {
 
 isc_result_t
 isc_task_beginexclusive(isc_task_t *task) {
-#ifdef ISC_PLATFORM_USETHREADS	
+#ifdef ISC_PLATFORM_USETHREADS
 	isc_taskmgr_t *manager = task->manager;
 	REQUIRE(task->state == task_state_running);
 	LOCK(&manager->lock);
 	if (manager->exclusive_requested) {
-		UNLOCK(&manager->lock);			
+		UNLOCK(&manager->lock);
 		return (ISC_R_LOCKBUSY);
 	}
 	manager->exclusive_requested = ISC_TRUE;
 	while (manager->tasks_running > 1) {
 		WAIT(&manager->exclusive_granted, &manager->lock);
 	}
-	UNLOCK(&manager->lock);	
+	UNLOCK(&manager->lock);
 #else
 	UNUSED(task);
 #endif
@@ -1284,7 +1279,7 @@ isc_task_beginexclusive(isc_task_t *task) {
 
 void
 isc_task_endexclusive(isc_task_t *task) {
-#ifdef ISC_PLATFORM_USETHREADS	
+#ifdef ISC_PLATFORM_USETHREADS
 	isc_taskmgr_t *manager = task->manager;
 	REQUIRE(task->state == task_state_running);
 	LOCK(&manager->lock);
@@ -1296,3 +1291,86 @@ isc_task_endexclusive(isc_task_t *task) {
 	UNUSED(task);
 #endif
 }
+
+#ifdef HAVE_LIBXML2
+
+void
+isc_taskmgr_renderxml(isc_taskmgr_t *mgr, xmlTextWriterPtr writer)
+{
+	isc_task_t *task;
+
+	LOCK(&mgr->lock);
+
+	/*
+	 * Write out the thread-model, and some details about each depending
+	 * on which type is enabled.
+	 */
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "thread-model");
+#ifdef ISC_PLATFORM_USETHREADS
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "type");
+	xmlTextWriterWriteString(writer, ISC_XMLCHAR "threaded");
+	xmlTextWriterEndElement(writer); /* type */
+
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "worker-threads");
+	xmlTextWriterWriteFormatString(writer, "%d", mgr->workers);
+	xmlTextWriterEndElement(writer); /* worker-threads */
+#else /* ISC_PLATFORM_USETHREADS */
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "type");
+	xmlTextWriterWriteString(writer, ISC_XMLCHAR "non-threaded");
+	xmlTextWriterEndElement(writer); /* type */
+
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "references");
+	xmlTextWriterWriteFormatString(writer, "%d", mgr->refs);
+	xmlTextWriterEndElement(writer); /* references */
+#endif /* ISC_PLATFORM_USETHREADS */
+
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "default-quantum");
+	xmlTextWriterWriteFormatString(writer, "%d", mgr->default_quantum);
+	xmlTextWriterEndElement(writer); /* default-quantum */
+
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "tasks-running");
+	xmlTextWriterWriteFormatString(writer, "%d", mgr->tasks_running);
+	xmlTextWriterEndElement(writer); /* tasks-running */
+
+	xmlTextWriterEndElement(writer); /* thread-model */
+
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "tasks");
+	task = ISC_LIST_HEAD(mgr->tasks);
+	while (task != NULL) {
+		LOCK(&task->lock);
+		xmlTextWriterStartElement(writer, ISC_XMLCHAR "task");
+
+		if (task->name[0] != 0) {
+			xmlTextWriterStartElement(writer, ISC_XMLCHAR "name");
+			xmlTextWriterWriteFormatString(writer, "%s",
+						       task->name);
+			xmlTextWriterEndElement(writer); /* name */
+		}
+
+		xmlTextWriterStartElement(writer, ISC_XMLCHAR "references");
+		xmlTextWriterWriteFormatString(writer, "%d", task->references);
+		xmlTextWriterEndElement(writer); /* references */
+
+		xmlTextWriterStartElement(writer, ISC_XMLCHAR "id");
+		xmlTextWriterWriteFormatString(writer, "%p", task);
+		xmlTextWriterEndElement(writer); /* id */
+
+		xmlTextWriterStartElement(writer, ISC_XMLCHAR "state");
+		xmlTextWriterWriteFormatString(writer, "%s",
+					       statenames[task->state]);
+		xmlTextWriterEndElement(writer); /* state */
+
+		xmlTextWriterStartElement(writer, ISC_XMLCHAR "quantum");
+		xmlTextWriterWriteFormatString(writer, "%d", task->quantum);
+		xmlTextWriterEndElement(writer); /* quantum */
+
+		xmlTextWriterEndElement(writer);
+
+		UNLOCK(&task->lock);
+		task = ISC_LIST_NEXT(task, link);
+	}
+	xmlTextWriterEndElement(writer); /* tasks */
+
+	UNLOCK(&mgr->lock);
+}
+#endif /* HAVE_LIBXML2 */
diff --git a/contrib/bind9/lib/isc/task_p.h b/contrib/bind9/lib/isc/task_p.h
index 8ada721..c888103 100644
--- a/contrib/bind9/lib/isc/task_p.h
+++ b/contrib/bind9/lib/isc/task_p.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: task_p.h,v 1.7.18.2 2005/04/29 00:16:50 marka Exp $ */
+/* $Id: task_p.h,v 1.11 2007/06/19 23:47:17 tbox Exp $ */
 
 #ifndef ISC_TASK_P_H
 #define ISC_TASK_P_H
diff --git a/contrib/bind9/lib/isc/taskpool.c b/contrib/bind9/lib/isc/taskpool.c
index f1f619d..d9c2fbe 100644
--- a/contrib/bind9/lib/isc/taskpool.c
+++ b/contrib/bind9/lib/isc/taskpool.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: taskpool.c,v 1.12.18.3 2005/11/30 03:44:39 marka Exp $ */
+/* $Id: taskpool.c,v 1.18 2007/06/18 23:47:44 tbox Exp $ */
 
 /*! \file */
 
@@ -66,6 +66,7 @@ isc_taskpool_create(isc_taskmgr_t *tmgr, isc_mem_t *mctx,
 			isc_taskpool_destroy(&pool);
 			return (result);
 		}
+		isc_task_setname(pool->tasks[i], "taskpool", NULL);
 	}
 	*poolp = pool;
 	return (ISC_R_SUCCESS);
diff --git a/contrib/bind9/lib/isc/timer.c b/contrib/bind9/lib/isc/timer.c
index c27281d..21fcd69 100644
--- a/contrib/bind9/lib/isc/timer.c
+++ b/contrib/bind9/lib/isc/timer.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2002  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: timer.c,v 1.73.18.10 2008/08/22 05:59:04 marka Exp $ */
+/* $Id: timer.c,v 1.84.58.4 2009/01/23 23:47:21 tbox Exp $ */
 
 /*! \file */
 
@@ -662,7 +662,7 @@ dispatch(isc_timermgr_t *manager, isc_time_t *now) {
 					isc_task_send(timer->task,
 						      ISC_EVENT_PTR(&event));
 				} else
-					UNEXPECTED_ERROR(__FILE__, __LINE__,
+					UNEXPECTED_ERROR(__FILE__, __LINE__, "%s",
 						 isc_msgcat_get(isc_msgcat,
 							 ISC_MSGSET_TIMER,
 							 ISC_MSG_EVENTNOTALLOC,
@@ -678,11 +678,12 @@ dispatch(isc_timermgr_t *manager, isc_time_t *now) {
 				result = schedule(timer, now, ISC_FALSE);
 				if (result != ISC_R_SUCCESS)
 					UNEXPECTED_ERROR(__FILE__, __LINE__,
+							 "%s: %u",
 						isc_msgcat_get(isc_msgcat,
 							ISC_MSGSET_TIMER,
 							ISC_MSG_SCHEDFAIL,
-							"couldn't "
-							"schedule timer: %u"),
+							"couldn't schedule "
+							"timer"),
 							 result);
 			}
 		} else {
diff --git a/contrib/bind9/lib/isc/timer_p.h b/contrib/bind9/lib/isc/timer_p.h
index fcc7b6c..ec8e2e0 100644
--- a/contrib/bind9/lib/isc/timer_p.h
+++ b/contrib/bind9/lib/isc/timer_p.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: timer_p.h,v 1.6.18.2 2005/04/29 00:16:51 marka Exp $ */
+/* $Id: timer_p.h,v 1.10 2007/06/19 23:47:17 tbox Exp $ */
 
 #ifndef ISC_TIMER_P_H
 #define ISC_TIMER_P_H
diff --git a/contrib/bind9/lib/isc/unix/Makefile.in b/contrib/bind9/lib/isc/unix/Makefile.in
index afb77a6..7d19b5c 100644
--- a/contrib/bind9/lib/isc/unix/Makefile.in
+++ b/contrib/bind9/lib/isc/unix/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1998-2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.38.18.1 2004/06/22 02:54:06 marka Exp $
+# $Id: Makefile.in,v 1.41 2007/06/19 23:47:18 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/unix/app.c b/contrib/bind9/lib/isc/unix/app.c
index c119362..660b438 100644
--- a/contrib/bind9/lib/isc/unix/app.c
+++ b/contrib/bind9/lib/isc/unix/app.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: app.c,v 1.50.18.8 2008/10/15 03:41:17 marka Exp $ */
+/* $Id: app.c,v 1.60 2008/10/15 03:41:17 marka Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/unix/dir.c b/contrib/bind9/lib/isc/unix/dir.c
index b627c88..9244147 100644
--- a/contrib/bind9/lib/isc/unix/dir.c
+++ b/contrib/bind9/lib/isc/unix/dir.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dir.c,v 1.20.18.3 2005/09/05 00:18:30 marka Exp $ */
+/* $Id: dir.c,v 1.25.332.3 2009/02/16 23:47:15 tbox Exp $ */
 
 /*! \file
  * \author  Principal Authors: DCL */
@@ -93,7 +93,7 @@ isc_dir_open(isc_dir_t *dir, const char *dirname) {
 }
 
 /*!
- * \brief Return previously retrieved file or get next one.  
+ * \brief Return previously retrieved file or get next one.
 
  * Unix's dirent has
  * separate open and read functions, but the Win32 and DOS interfaces open
@@ -171,10 +171,14 @@ isc_dir_chroot(const char *dirname) {
 
 	REQUIRE(dirname != NULL);
 
-	if (chroot(dirname) < 0)
+#ifdef HAVE_CHROOT
+	if (chroot(dirname) < 0 || chdir("/") < 0)
 		return (isc__errno2result(errno));
 
 	return (ISC_R_SUCCESS);
+#else
+	return (ISC_R_NOTIMPLEMENTED);
+#endif
 }
 
 isc_result_t
diff --git a/contrib/bind9/lib/isc/unix/entropy.c b/contrib/bind9/lib/isc/unix/entropy.c
index 4c0d0d0..0e9e297 100644
--- a/contrib/bind9/lib/isc/unix/entropy.c
+++ b/contrib/bind9/lib/isc/unix/entropy.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: entropy.c,v 1.71.18.7 2006/12/07 04:53:03 marka Exp $ */
+/* $Id: entropy.c,v 1.80.332.2 2009/02/16 23:47:15 tbox Exp $ */
 
 /* \file unix/entropy.c
  * \brief
@@ -31,6 +31,9 @@
 #include <sys/socket.h>
 #include <sys/un.h>
 
+#ifdef HAVE_NANOSLEEP
+#include <time.h>
+#endif
 #include <unistd.h>
 
 #include <isc/platform.h>
@@ -153,12 +156,12 @@ get_from_usocketsource(isc_entropysource_t *source, isc_uint32_t desired) {
 				source->sources.usocket.status =
 					isc_usocketsource_ndesired;
 				goto eagain_loop;
-			}	
+			}
 			INSIST(n == 2);
 			source->sources.usocket.status =
 						isc_usocketsource_wrote;
 			/*FALLTHROUGH*/
-		
+
 		case isc_usocketsource_wrote:
 			if (recvfrom(fd, buf, 1, 0, NULL, NULL) != 1) {
 				if (errno == EAGAIN) {
@@ -166,15 +169,23 @@ get_from_usocketsource(isc_entropysource_t *source, isc_uint32_t desired) {
 					 * The problem of EAGAIN (try again
 					 * later) is a major issue on HP-UX.
 					 * Solaris actually tries the recvfrom
-					 * call again, while HP-UX just dies. 
+					 * call again, while HP-UX just dies.
 					 * This code is an attempt to let the
 					 * entropy pool fill back up (at least
 					 * that's what I think the problem is.)
-					 * We go to eagain_loop because if we 
+					 * We go to eagain_loop because if we
 					 * just "break", then the "desired"
 					 * amount gets borked.
 					 */
+#ifdef HAVE_NANOSLEEP
+					struct timespec ts;
+
+					ts.tv_sec = 0;
+					ts.tv_nsec = 1000000;
+					nanosleep(&ts, NULL);
+#else
 					usleep(1000);
+#endif
 					goto eagain_loop;
 				}
 				if (errno == EWOULDBLOCK || errno == EINTR)
@@ -201,7 +212,7 @@ get_from_usocketsource(isc_entropysource_t *source, isc_uint32_t desired) {
 			} else
 				n = 0;
 			break;
-		
+
 		default:
 			goto err;
 		}
@@ -491,7 +502,7 @@ isc_entropy_createfilesource(isc_entropy_t *ent, const char *fname) {
 		ret = isc__errno2result(errno);
 		goto errout;
 	}
-	/* 
+	/*
 	 * Solaris 2.5.1 does not have support for sockets (S_IFSOCK),
 	 * but it does return type S_IFIFO (the OS believes that
 	 * the socket is a fifo).  This may be an issue if we tell
diff --git a/contrib/bind9/lib/isc/unix/errno2result.c b/contrib/bind9/lib/isc/unix/errno2result.c
index d4b188f..606c560 100644
--- a/contrib/bind9/lib/isc/unix/errno2result.c
+++ b/contrib/bind9/lib/isc/unix/errno2result.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: errno2result.c,v 1.13.18.2 2005/04/29 00:17:07 marka Exp $ */
+/* $Id: errno2result.c,v 1.17 2007/06/19 23:47:18 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/unix/errno2result.h b/contrib/bind9/lib/isc/unix/errno2result.h
index 5e36116..b5b658d 100644
--- a/contrib/bind9/lib/isc/unix/errno2result.h
+++ b/contrib/bind9/lib/isc/unix/errno2result.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: errno2result.h,v 1.8.18.2 2005/04/29 00:17:07 marka Exp $ */
+/* $Id: errno2result.h,v 1.12 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef UNIX_ERRNO2RESULT_H
 #define UNIX_ERRNO2RESULT_H 1
diff --git a/contrib/bind9/lib/isc/unix/file.c b/contrib/bind9/lib/isc/unix/file.c
index e45e0fe..748aee8 100644
--- a/contrib/bind9/lib/isc/unix/file.c
+++ b/contrib/bind9/lib/isc/unix/file.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -48,7 +48,7 @@
  * SUCH DAMAGE.
  */
 
-/* $Id: file.c,v 1.47.18.2 2005/04/29 00:17:07 marka Exp $ */
+/* $Id: file.c,v 1.51.332.2 2009/02/16 23:47:15 tbox Exp $ */
 
 /*! \file */
 
@@ -67,6 +67,7 @@
 
 #include <isc/dir.h>
 #include <isc/file.h>
+#include <isc/log.h>
 #include <isc/random.h>
 #include <isc/string.h>
 #include <isc/time.h>
@@ -235,7 +236,9 @@ isc_file_renameunique(const char *file, char *templet) {
 			}
 		}
 	}
-	(void)unlink(file);
+	if (unlink(file) < 0)
+		if (errno != ENOENT)
+			return (isc__errno2result(errno));
 	return (ISC_R_SUCCESS);
 }
 
@@ -287,7 +290,11 @@ isc_file_openunique(char *templet, FILE **fp) {
 	f = fdopen(fd, "w+");
 	if (f == NULL) {
 		result = isc__errno2result(errno);
-		(void)remove(templet);
+		if (remove(templet) < 0) {
+			isc_log_write(isc_lctx, ISC_LOGCATEGORY_GENERAL,
+				      ISC_LOGMODULE_FILE, ISC_LOG_ERROR,
+				      "remove '%s': failed", templet);
+		}
 		(void)close(fd);
 	} else
 		*fp = f;
@@ -386,7 +393,7 @@ isc_file_progname(const char *filename, char *buf, size_t buflen) {
 
 /*
  * Put the absolute name of the current directory into 'dirname', which is
- * a buffer of at least 'length' characters.  End the string with the 
+ * a buffer of at least 'length' characters.  End the string with the
  * appropriate path separator, such that the final product could be
  * concatenated with a relative pathname to make a valid pathname string.
  */
@@ -431,7 +438,7 @@ isc_result_t
 isc_file_truncate(const char *filename, isc_offset_t size) {
 	isc_result_t result = ISC_R_SUCCESS;
 
-	if (truncate(filename, size) < 0) 
+	if (truncate(filename, size) < 0)
 		result = isc__errno2result(errno);
 	return (result);
 }
diff --git a/contrib/bind9/lib/isc/unix/fsaccess.c b/contrib/bind9/lib/isc/unix/fsaccess.c
index f3ed60f..a2bd89a 100644
--- a/contrib/bind9/lib/isc/unix/fsaccess.c
+++ b/contrib/bind9/lib/isc/unix/fsaccess.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: fsaccess.c,v 1.7.18.4 2006/08/25 05:25:51 marka Exp $ */
+/* $Id: fsaccess.c,v 1.13 2007/06/19 23:47:18 tbox Exp $ */
 
 #include <config.h>
 
diff --git a/contrib/bind9/lib/isc/unix/ifiter_getifaddrs.c b/contrib/bind9/lib/isc/unix/ifiter_getifaddrs.c
index 3599a89..b576d46 100644
--- a/contrib/bind9/lib/isc/unix/ifiter_getifaddrs.c
+++ b/contrib/bind9/lib/isc/unix/ifiter_getifaddrs.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ifiter_getifaddrs.c,v 1.4.18.5 2007/08/28 07:20:06 tbox Exp $ */
+/* $Id: ifiter_getifaddrs.c,v 1.11 2008/03/20 23:47:00 tbox Exp $ */
 
 /*! \file
  * \brief
@@ -29,6 +29,10 @@
 /*% Valid Iterator */
 #define VALID_IFITER(t)		ISC_MAGIC_VALID(t, IFITER_MAGIC)
 
+#ifdef __linux
+static isc_boolean_t seenv6 = ISC_FALSE;
+#endif
+
 /*% Iterator structure */
 struct isc_interfaceiter {
 	unsigned int		magic;		/*%< Magic number. */
@@ -39,9 +43,13 @@ struct isc_interfaceiter {
 	struct ifaddrs		*pos;		/*%< Ptr to current ifaddr */
 	isc_interface_t		current;	/*%< Current interface data. */
 	isc_result_t		result;		/*%< Last result code. */
+#ifdef  __linux
+	FILE *                  proc;
+	char                    entry[ISC_IF_INET6_SZ];
+	isc_result_t            valid;
+#endif
 };
 
-
 isc_result_t
 isc_interfaceiter_create(isc_mem_t *mctx, isc_interfaceiter_t **iterp) {
 	isc_interfaceiter_t *iter;
@@ -60,6 +68,17 @@ isc_interfaceiter_create(isc_mem_t *mctx, isc_interfaceiter_t **iterp) {
 	iter->buf = NULL;
 	iter->bufsize = 0;
 	iter->ifaddrs = NULL;
+#ifdef __linux
+	/*
+	 * Only open "/proc/net/if_inet6" if we have never seen a IPv6
+	 * address returned by getifaddrs().
+	 */
+	if (!seenv6)
+		iter->proc = fopen("/proc/net/if_inet6", "r");
+	else
+		iter->proc = NULL;
+	iter->valid = ISC_R_FAILURE;
+#endif
 
 	if (getifaddrs(&iter->ifaddrs) < 0) {
 		isc__strerror(errno, strbuf, sizeof(strbuf));
@@ -86,6 +105,10 @@ isc_interfaceiter_create(isc_mem_t *mctx, isc_interfaceiter_t **iterp) {
 	return (ISC_R_SUCCESS);
 
  failure:
+#ifdef __linux
+	if (iter->proc != NULL)
+		fclose(iter->proc);
+#endif
 	if (iter->ifaddrs != NULL) /* just in case */
 		freeifaddrs(iter->ifaddrs);
 	isc_mem_put(mctx, iter, sizeof(*iter));
@@ -109,6 +132,11 @@ internal_current(isc_interfaceiter_t *iter) {
 
 	ifa = iter->pos;
 
+#ifdef __linux
+	if (iter->pos == NULL)
+		return (linux_if_inet6_current(iter));
+#endif
+
 	INSIST(ifa != NULL);
 	INSIST(ifa->ifa_name != NULL);
 
@@ -119,6 +147,11 @@ internal_current(isc_interfaceiter_t *iter) {
 	if (family != AF_INET && family != AF_INET6)
 		return (ISC_R_IGNORE);
 
+#ifdef __linux
+	if (family == AF_INET6)
+		seenv6 = ISC_TRUE;
+#endif
+
 	memset(&iter->current, 0, sizeof(iter->current));
 
 	namelen = strlen(ifa->ifa_name);
@@ -164,16 +197,28 @@ internal_current(isc_interfaceiter_t *iter) {
  */
 static isc_result_t
 internal_next(isc_interfaceiter_t *iter) {
-	iter->pos = iter->pos->ifa_next;
 
-	if (iter->pos == NULL)
+	if (iter->pos != NULL)
+		iter->pos = iter->pos->ifa_next;
+	if (iter->pos == NULL) {
+#ifdef __linux
+		if (!seenv6)
+			return (linux_if_inet6_next(iter));
+#endif
 		return (ISC_R_NOMORE);
+	}
 
 	return (ISC_R_SUCCESS);
 }
 
 static void
 internal_destroy(isc_interfaceiter_t *iter) {
+
+#ifdef __linux
+	if (iter->proc != NULL)
+		fclose(iter->proc);
+	iter->proc = NULL;
+#endif
 	if (iter->ifaddrs)
 		freeifaddrs(iter->ifaddrs);
 	iter->ifaddrs = NULL;
@@ -181,5 +226,9 @@ internal_destroy(isc_interfaceiter_t *iter) {
 
 static
 void internal_first(isc_interfaceiter_t *iter) {
+
+#ifdef __linux
+	linux_if_inet6_first(iter);
+#endif
 	iter->pos = iter->ifaddrs;
 }
diff --git a/contrib/bind9/lib/isc/unix/ifiter_ioctl.c b/contrib/bind9/lib/isc/unix/ifiter_ioctl.c
index ce63de7..a9d29bc 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-2007  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ifiter_ioctl.c,v 1.44.18.13 2007/08/31 23:46:25 tbox Exp $ */
+/* $Id: ifiter_ioctl.c,v 1.60.120.2 2009/01/18 23:47:41 tbox Exp $ */
 
 /*! \file
  * \brief
@@ -50,9 +50,6 @@
 #define IFITER_MAGIC		ISC_MAGIC('I', 'F', 'I', 'T')
 #define VALID_IFITER(t)		ISC_MAGIC_VALID(t, IFITER_MAGIC)
 
-#define ISC_IF_INET6_SZ \
-    sizeof("00000000000000000000000000000001 01 80 10 80 XXXXXXloXXXXXXXX\n")
-
 struct isc_interfaceiter {
 	unsigned int		magic;		/* Magic number. */
 	isc_mem_t		*mctx;
@@ -82,7 +79,6 @@ struct isc_interfaceiter {
 	FILE *			proc;
 	char			entry[ISC_IF_INET6_SZ];
 	isc_result_t		valid;
-	isc_boolean_t		first;
 #endif
 	isc_interface_t		current;	/* Current interface data. */
 	isc_result_t		result;		/* Last result code. */
@@ -104,7 +100,7 @@ struct isc_interfaceiter {
 #ifdef __linux
 #ifndef IF_NAMESIZE
 # ifdef IFNAMSIZ
-#  define IF_NAMESIZE  IFNAMSIZ  
+#  define IF_NAMESIZE  IFNAMSIZ
 # else
 #  define IF_NAMESIZE 16
 # endif
@@ -126,7 +122,7 @@ getbuf4(isc_interfaceiter_t *iter) {
 		iter->ifc.ifc_len = iter->bufsize;
 		iter->ifc.ifc_buf = iter->buf;
 		/*
-		 * Ignore the HP/UX warning about "interger overflow during
+		 * Ignore the HP/UX warning about "integer overflow during
 		 * conversion".  It comes from its own macro definition,
 		 * and is really hard to shut up.
 		 */
@@ -206,7 +202,7 @@ getbuf6(isc_interfaceiter_t *iter) {
 		iter->lifc.lifc_len = iter->bufsize6;
 		iter->lifc.lifc_buf = iter->buf6;
 		/*
-		 * Ignore the HP/UX warning about "interger overflow during
+		 * Ignore the HP/UX warning about "integer overflow during
 		 * conversion".  It comes from its own macro definition,
 		 * and is really hard to shut up.
 		 */
@@ -372,7 +368,6 @@ isc_interfaceiter_create(isc_mem_t *mctx, isc_interfaceiter_t **iterp) {
 #ifdef __linux
 	iter->proc = fopen("/proc/net/if_inet6", "r");
 	iter->valid = ISC_R_FAILURE;
-	iter->first = ISC_FALSE;
 #endif
 	iter->result = ISC_R_FAILURE;
 
@@ -394,7 +389,7 @@ isc_interfaceiter_create(isc_mem_t *mctx, isc_interfaceiter_t **iterp) {
 		(void) close(iter->socket6);
   socket6_failure:
 #endif
- 
+
 	isc_mem_put(mctx, iter, sizeof(*iter));
 	return (result);
 }
@@ -422,89 +417,6 @@ internal_current_clusteralias(isc_interfaceiter_t *iter) {
 }
 #endif
 
-#ifdef __linux
-static isc_result_t
-linux_if_inet6_next(isc_interfaceiter_t *iter) {
-	if (iter->proc != NULL &&
-	    fgets(iter->entry, sizeof(iter->entry), iter->proc) != NULL)
-		iter->valid = ISC_R_SUCCESS;
-	else
-		iter->valid = ISC_R_NOMORE;
-	return (iter->valid);
-}
-
-static void
-linux_if_inet6_first(isc_interfaceiter_t *iter) {
-	if (iter->proc != NULL) {
-		rewind(iter->proc);
-		(void)linux_if_inet6_next(iter);
-	} else
-		iter->valid = ISC_R_NOMORE;
-	iter->first = ISC_FALSE;
-}
-
-static isc_result_t
-linux_if_inet6_current(isc_interfaceiter_t *iter) {
-	char address[33];
-	char name[IF_NAMESIZE+1];
-	struct in6_addr addr6;
-	int ifindex, prefix, flag3, flag4;
-	int res;
-	unsigned int i;
-
-	if (iter->valid != ISC_R_SUCCESS)
-		return (iter->valid);
-	if (iter->proc == NULL) {
-		isc_log_write(isc_lctx, ISC_LOGCATEGORY_GENERAL,
-			      ISC_LOGMODULE_INTERFACE, ISC_LOG_ERROR,
-			      "/proc/net/if_inet6:iter->proc == NULL");
-		return (ISC_R_FAILURE);
-	}
-
-	res = sscanf(iter->entry, "%32[a-f0-9] %x %x %x %x %16s\n",
-		     address, &ifindex, &prefix, &flag3, &flag4, name);
-	if (res != 6) {
-		isc_log_write(isc_lctx, ISC_LOGCATEGORY_GENERAL,
-			      ISC_LOGMODULE_INTERFACE, ISC_LOG_ERROR,
-			      "/proc/net/if_inet6:sscanf() -> %d (expected 6)",
-			      res);
-		return (ISC_R_FAILURE);
-	}
-	if (strlen(address) != 32) {
-		isc_log_write(isc_lctx, ISC_LOGCATEGORY_GENERAL,
-			      ISC_LOGMODULE_INTERFACE, ISC_LOG_ERROR,
-			      "/proc/net/if_inet6:strlen(%s) != 32", address);
-		return (ISC_R_FAILURE);
-	}
-	for (i = 0; i < 16; i++) {
-		unsigned char byte;
-		static const char hex[] = "0123456789abcdef";
-		byte = ((index(hex, address[i * 2]) - hex) << 4) |
-		       (index(hex, address[i * 2 + 1]) - hex);
-		addr6.s6_addr[i] = byte;
-	}
-	iter->current.af = AF_INET6;
-	iter->current.flags = INTERFACE_F_UP;
-	isc_netaddr_fromin6(&iter->current.address, &addr6);
-	if (isc_netaddr_islinklocal(&iter->current.address)) {
-		isc_netaddr_setzone(&iter->current.address,
-				    (isc_uint32_t)ifindex);
-	}
-	for (i = 0; i < 16; i++) {
-		if (prefix > 8) {
-			addr6.s6_addr[i] = 0xff;
-			prefix -= 8;
-		} else {
-			addr6.s6_addr[i] = (0xff << (8 - prefix)) & 0xff;
-			prefix = 0;
-		}
-	}
-	isc_netaddr_fromin6(&iter->current.netmask, &addr6);
-	strncpy(iter->current.name, name, sizeof(iter->current.name));
-	return (ISC_R_SUCCESS);
-}
-#endif
-
 /*
  * Get information about the current interface to iter->current.
  * If successful, return ISC_R_SUCCESS.
@@ -525,23 +437,19 @@ internal_current4(isc_interfaceiter_t *iter) {
 	char sabuf[256];
 #endif
 	int i, bits, prefixlen;
-#ifdef __linux
-	isc_result_t result;
-#endif
 
 	REQUIRE(VALID_IFITER(iter));
-	REQUIRE(iter->ifc.ifc_len == 0 ||
-		iter->pos < (unsigned int) iter->ifc.ifc_len);
 
+	if (iter->ifc.ifc_len == 0 ||
+	    iter->pos == (unsigned int)iter->ifc.ifc_len) {
 #ifdef __linux
-	result = linux_if_inet6_current(iter);
-	if (result != ISC_R_NOMORE)
-		return (result);
-	iter->first = ISC_TRUE;
+		return (linux_if_inet6_current(iter));
+#else
+		return (ISC_R_NOMORE);
 #endif
+	}
 
-	if (iter->ifc.ifc_len == 0)
-		return (ISC_R_NOMORE);
+	INSIST( iter->pos < (unsigned int) iter->ifc.ifc_len);
 
 	ifrp = (struct ifreq *)((char *) iter->ifc.ifc_req + iter->pos);
 
@@ -588,7 +496,7 @@ internal_current4(isc_interfaceiter_t *iter) {
 	iter->current.flags = 0;
 
 	/*
-	 * Ignore the HP/UX warning about "interger overflow during
+	 * Ignore the HP/UX warning about "integer overflow during
 	 * conversion.  It comes from its own macro definition,
 	 * and is really hard to shut up.
 	 */
@@ -666,7 +574,7 @@ internal_current4(isc_interfaceiter_t *iter) {
 	 */
 	if ((iter->current.flags & INTERFACE_F_POINTTOPOINT) != 0) {
 		/*
-		 * Ignore the HP/UX warning about "interger overflow during
+		 * Ignore the HP/UX warning about "integer overflow during
 		 * conversion.  It comes from its own macro definition,
 		 * and is really hard to shut up.
 		 */
@@ -693,7 +601,7 @@ internal_current4(isc_interfaceiter_t *iter) {
 	memset(&ifreq, 0, sizeof(ifreq));
 	memcpy(&ifreq, ifrp, sizeof(ifreq));
 	/*
-	 * Ignore the HP/UX warning about "interger overflow during
+	 * Ignore the HP/UX warning about "integer overflow during
 	 * conversion.  It comes from its own macro definition,
 	 * and is really hard to shut up.
 	 */
@@ -776,7 +684,7 @@ internal_current6(isc_interfaceiter_t *iter) {
 		fd = iter->socket;
 
 	/*
-	 * Ignore the HP/UX warning about "interger overflow during
+	 * Ignore the HP/UX warning about "integer overflow during
 	 * conversion.  It comes from its own macro definition,
 	 * and is really hard to shut up.
 	 */
@@ -805,7 +713,7 @@ internal_current6(isc_interfaceiter_t *iter) {
 	 */
 	if ((iter->current.flags & INTERFACE_F_POINTTOPOINT) != 0) {
 		/*
-		 * Ignore the HP/UX warning about "interger overflow during
+		 * Ignore the HP/UX warning about "integer overflow during
 		 * conversion.  It comes from its own macro definition,
 		 * and is really hard to shut up.
 		 */
@@ -855,7 +763,7 @@ internal_current6(isc_interfaceiter_t *iter) {
 #endif
 
 	/*
-	 * Ignore the HP/UX warning about "interger overflow during
+	 * Ignore the HP/UX warning about "integer overflow during
 	 * conversion.  It comes from its own macro definition,
 	 * and is really hard to shut up.
 	 */
@@ -905,31 +813,25 @@ internal_next4(isc_interfaceiter_t *iter) {
 	struct ifreq *ifrp;
 #endif
 
-	REQUIRE(iter->ifc.ifc_len == 0 ||
-	        iter->pos < (unsigned int) iter->ifc.ifc_len);
-
-#ifdef __linux
-	if (linux_if_inet6_next(iter) == ISC_R_SUCCESS)
-		return (ISC_R_SUCCESS);
-	if (!iter->first)
-		return (ISC_R_SUCCESS);
-#endif
-
-	if (iter->ifc.ifc_len == 0)
-		return (ISC_R_NOMORE);
-
+	if (iter->pos < (unsigned int) iter->ifc.ifc_len) {
 #ifdef ISC_PLATFORM_HAVESALEN
-	ifrp = (struct ifreq *)((char *) iter->ifc.ifc_req + iter->pos);
+		ifrp = (struct ifreq *)((char *) iter->ifc.ifc_req + iter->pos);
 
-	if (ifrp->ifr_addr.sa_len > sizeof(struct sockaddr))
-		iter->pos += sizeof(ifrp->ifr_name) + ifrp->ifr_addr.sa_len;
-	else
+		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(struct ifreq);
+			iter->pos += sizeof(struct ifreq);
 
-	if (iter->pos >= (unsigned int) iter->ifc.ifc_len)
+	} else {
+		INSIST(iter->pos == (unsigned int) iter->ifc.ifc_len);
+#ifdef __linux
+		return (linux_if_inet6_next(iter));
+#else
 		return (ISC_R_NOMORE);
-
+#endif
+	}
 	return (ISC_R_SUCCESS);
 }
 
@@ -939,7 +841,7 @@ 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);
 
diff --git a/contrib/bind9/lib/isc/unix/ifiter_sysctl.c b/contrib/bind9/lib/isc/unix/ifiter_sysctl.c
index 212a478..9d5bf6d 100644
--- a/contrib/bind9/lib/isc/unix/ifiter_sysctl.c
+++ b/contrib/bind9/lib/isc/unix/ifiter_sysctl.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ifiter_sysctl.c,v 1.20.18.3 2005/04/27 05:02:35 sra Exp $ */
+/* $Id: ifiter_sysctl.c,v 1.25 2007/06/19 23:47:18 tbox Exp $ */
 
 /*! \file
  * \brief
diff --git a/contrib/bind9/lib/isc/unix/include/Makefile.in b/contrib/bind9/lib/isc/unix/include/Makefile.in
index 78eba44..0303ab1 100644
--- a/contrib/bind9/lib/isc/unix/include/Makefile.in
+++ b/contrib/bind9/lib/isc/unix/include/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1998-2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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 2004/03/05 05:11:50 marka Exp $
+# $Id: Makefile.in,v 1.14 2007/06/19 23:47:18 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/unix/include/isc/Makefile.in b/contrib/bind9/lib/isc/unix/include/isc/Makefile.in
index 9599f7c..2f4d216 100644
--- a/contrib/bind9/lib/isc/unix/include/isc/Makefile.in
+++ b/contrib/bind9/lib/isc/unix/include/isc/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1998-2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.28 2004/03/05 05:11:52 marka Exp $
+# $Id: Makefile.in,v 1.30 2007/06/19 23:47:19 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/unix/include/isc/dir.h b/contrib/bind9/lib/isc/unix/include/isc/dir.h
index cc85706..e4a2ad0 100644
--- a/contrib/bind9/lib/isc/unix/include/isc/dir.h
+++ b/contrib/bind9/lib/isc/unix/include/isc/dir.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: dir.h,v 1.17.18.2 2005/04/29 00:17:09 marka Exp $ */
+/* $Id: dir.h,v 1.21 2007/06/19 23:47:19 tbox Exp $ */
 
 /* Principal Authors: DCL */
 
diff --git a/contrib/bind9/lib/isc/unix/include/isc/int.h b/contrib/bind9/lib/isc/unix/include/isc/int.h
index 1e1de7b..73feb3b 100644
--- a/contrib/bind9/lib/isc/unix/include/isc/int.h
+++ b/contrib/bind9/lib/isc/unix/include/isc/int.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: int.h,v 1.12.18.2 2005/04/29 00:17:09 marka Exp $ */
+/* $Id: int.h,v 1.16 2007/06/19 23:47:19 tbox Exp $ */
 
 #ifndef ISC_INT_H
 #define ISC_INT_H 1
diff --git a/contrib/bind9/lib/isc/unix/include/isc/keyboard.h b/contrib/bind9/lib/isc/unix/include/isc/keyboard.h
index 4b28cc0..43f5e7e 100644
--- a/contrib/bind9/lib/isc/unix/include/isc/keyboard.h
+++ b/contrib/bind9/lib/isc/unix/include/isc/keyboard.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: keyboard.h,v 1.7.18.2 2005/04/29 00:17:09 marka Exp $ */
+/* $Id: keyboard.h,v 1.11 2007/06/19 23:47:19 tbox Exp $ */
 
 #ifndef ISC_KEYBOARD_H
 #define ISC_KEYBOARD_H 1
diff --git a/contrib/bind9/lib/isc/unix/include/isc/net.h b/contrib/bind9/lib/isc/unix/include/isc/net.h
index 948e7b1..53bebd7 100644
--- a/contrib/bind9/lib/isc/unix/include/isc/net.h
+++ b/contrib/bind9/lib/isc/unix/include/isc/net.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: net.h,v 1.39.18.6 2008/06/24 23:45:55 tbox Exp $ */
+/* $Id: net.h,v 1.48.84.2 2009/02/16 23:47:15 tbox Exp $ */
 
 #ifndef ISC_NET_H
 #define ISC_NET_H 1
@@ -354,11 +354,10 @@ isc_net_pton(int af, const char *src, void *dst);
 #define inet_pton isc_net_pton
 #endif
 
-#ifdef ISC_PLATFORM_NEEDATON
 int
 isc_net_aton(const char *cp, struct in_addr *addr);
+#undef inet_aton
 #define inet_aton isc_net_aton
-#endif
 
 ISC_LANG_ENDDECLS
 
diff --git a/contrib/bind9/lib/isc/unix/include/isc/netdb.h b/contrib/bind9/lib/isc/unix/include/isc/netdb.h
index 428f087..ff12a26 100644
--- a/contrib/bind9/lib/isc/unix/include/isc/netdb.h
+++ b/contrib/bind9/lib/isc/unix/include/isc/netdb.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: netdb.h,v 1.7.18.2 2005/04/29 00:17:10 marka Exp $ */
+/* $Id: netdb.h,v 1.11 2007/06/19 23:47:19 tbox Exp $ */
 
 #ifndef ISC_NETDB_H
 #define ISC_NETDB_H 1
diff --git a/contrib/bind9/lib/isc/unix/include/isc/offset.h b/contrib/bind9/lib/isc/unix/include/isc/offset.h
index 15fbad4..0e484be 100644
--- a/contrib/bind9/lib/isc/unix/include/isc/offset.h
+++ b/contrib/bind9/lib/isc/unix/include/isc/offset.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: offset.h,v 1.11.18.2 2005/04/29 00:17:10 marka Exp $ */
+/* $Id: offset.h,v 1.15.332.2 2009/02/16 23:47:15 tbox Exp $ */
 
 #ifndef ISC_OFFSET_H
 #define ISC_OFFSET_H 1
@@ -26,6 +26,7 @@
  */
 #include <limits.h>             /* Required for CHAR_BIT. */
 #include <sys/types.h>
+#include <stddef.h>		/* For Linux Standard Base. */
 
 typedef off_t isc_offset_t;
 
diff --git a/contrib/bind9/lib/isc/unix/include/isc/stat.h b/contrib/bind9/lib/isc/unix/include/isc/stat.h
index d1b2489..b7a7986 100644
--- a/contrib/bind9/lib/isc/unix/include/isc/stat.h
+++ b/contrib/bind9/lib/isc/unix/include/isc/stat.h
@@ -1,7 +1,7 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: stat.h,v 1.2.18.1 2004/08/19 04:42:54 marka Exp $ */
+/* $Id: stat.h,v 1.5 2007/06/19 23:47:19 tbox Exp $ */
 
 #ifndef ISC_STAT_H
 #define ISC_STAT_H 1
diff --git a/contrib/bind9/lib/isc/unix/include/isc/stdtime.h b/contrib/bind9/lib/isc/unix/include/isc/stdtime.h
index 24a91d2..4cb9e81 100644
--- a/contrib/bind9/lib/isc/unix/include/isc/stdtime.h
+++ b/contrib/bind9/lib/isc/unix/include/isc/stdtime.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: stdtime.h,v 1.9.18.3 2005/06/04 06:23:45 jinmei Exp $ */
+/* $Id: stdtime.h,v 1.14 2007/06/19 23:47:19 tbox Exp $ */
 
 #ifndef ISC_STDTIME_H
 #define ISC_STDTIME_H 1
diff --git a/contrib/bind9/lib/isc/unix/include/isc/strerror.h b/contrib/bind9/lib/isc/unix/include/isc/strerror.h
index fb2e8a4..2953f71 100644
--- a/contrib/bind9/lib/isc/unix/include/isc/strerror.h
+++ b/contrib/bind9/lib/isc/unix/include/isc/strerror.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: strerror.h,v 1.4.18.2 2005/04/29 00:17:10 marka Exp $ */
+/* $Id: strerror.h,v 1.8.332.2 2009/02/16 23:47:15 tbox Exp $ */
 
 #ifndef ISC_STRERROR_H
 #define ISC_STRERROR_H
@@ -32,7 +32,7 @@ ISC_LANG_BEGINDECLS
 #define ISC_STRERRORSIZE 128
 
 /*%
- * Provide a thread safe wrapper to strerrror().
+ * Provide a thread safe wrapper to strerror().
  *
  * Requires:
  * 	'buf' to be non NULL.
diff --git a/contrib/bind9/lib/isc/unix/include/isc/syslog.h b/contrib/bind9/lib/isc/unix/include/isc/syslog.h
index 08adca1..7e0c88c 100644
--- a/contrib/bind9/lib/isc/unix/include/isc/syslog.h
+++ b/contrib/bind9/lib/isc/unix/include/isc/syslog.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: syslog.h,v 1.3.18.2 2005/04/29 00:17:10 marka Exp $ */
+/* $Id: syslog.h,v 1.7 2007/06/19 23:47:19 tbox Exp $ */
 
 #ifndef ISC_SYSLOG_H
 #define ISC_SYSLOG_H 1
diff --git a/contrib/bind9/lib/isc/unix/include/isc/time.h b/contrib/bind9/lib/isc/unix/include/isc/time.h
index 6579439..45c4510 100644
--- a/contrib/bind9/lib/isc/unix/include/isc/time.h
+++ b/contrib/bind9/lib/isc/unix/include/isc/time.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: time.h,v 1.30.18.2 2005/04/29 00:17:10 marka Exp $ */
+/* $Id: time.h,v 1.38.56.2 2009/01/05 23:47:23 tbox Exp $ */
 
 #ifndef ISC_TIME_H
 #define ISC_TIME_H 1
@@ -29,7 +29,7 @@
  *** Intervals
  ***/
 
-/*! 
+/*!
  *  \brief
  * The contents of this structure are private, and MUST NOT be accessed
  * directly by callers.
@@ -90,15 +90,17 @@ extern isc_time_t *isc_time_epoch;
 void
 isc_time_set(isc_time_t *t, unsigned int seconds, unsigned int nanoseconds);
 /*%<
- * Set 't' to a particular number of seconds + nanoseconds since the epoch.
+ * Set 't' to a value which represents the given number of seconds and
+ * nanoseconds since 00:00:00 January 1, 1970, UTC.
  *
  * Notes:
- *\li	This call is equivalent to:
+ *\li	The Unix version of this call is equivalent to:
  *\code
  *	isc_time_settoepoch(t);
  *	isc_interval_set(i, seconds, nanoseconds);
  *	isc_time_add(t, i, t);
  *\endcode
+ *
  * Requires:
  *\li	't' is a valid pointer.
  *\li	nanoseconds < 1000000000.
@@ -110,7 +112,7 @@ isc_time_settoepoch(isc_time_t *t);
  * Set 't' to the time of the epoch.
  *
  * Notes:
- * \li	The date of the epoch is platform-dependent.
+ *\li	The date of the epoch is platform-dependent.
  *
  * Requires:
  *
@@ -199,7 +201,7 @@ isc_time_add(const isc_time_t *t, const isc_interval_t *i, isc_time_t *result);
  *\li	't', 'i', and 'result' are valid pointers.
  *
  * Returns:
- * \li	Success
+ *\li	Success
  *\li	Out of range
  * 		The interval added to the time is too large to
  *		be represented in the current definition of isc_time_t.
@@ -274,7 +276,7 @@ isc_time_nanoseconds(const isc_time_t *t);
  * Return the number of nanoseconds stored in a time structure.
  *
  * Notes:
- *\li	This is the number of nanoseconds in excess of the the number
+ *\li	This is the number of nanoseconds in excess of the number
  *	of seconds since the epoch; it will always be less than one
  *	full second.
  *
@@ -295,7 +297,35 @@ isc_time_formattimestamp(const isc_time_t *t, char *buf, unsigned int len);
  *
  *  Requires:
  *\li      'len' > 0
- *  \li    'buf' points to an array of at least len chars
+ *\li      'buf' points to an array of at least len chars
+ *
+ */
+
+void
+isc_time_formathttptimestamp(const isc_time_t *t, char *buf, unsigned int len);
+/*%<
+ * Format the time 't' into the buffer 'buf' of length 'len',
+ * using a format like "Mon, 30 Aug 2000 04:06:47 GMT"
+ * If the text does not fit in the buffer, the result is indeterminate,
+ * but is always guaranteed to be null terminated.
+ *
+ *  Requires:
+ *\li      'len' > 0
+ *\li      'buf' points to an array of at least len chars
+ *
+ */
+
+void
+isc_time_formatISO8601(const isc_time_t *t, char *buf, unsigned int len);
+/*%<
+ * Format the time 't' into the buffer 'buf' of length 'len',
+ * using the ISO8601 format: "yyyy-mm-ddThh:mm:ssZ"
+ * If the text does not fit in the buffer, the result is indeterminate,
+ * but is always guaranteed to be null terminated.
+ *
+ *  Requires:
+ *\li      'len' > 0
+ *\li      'buf' points to an array of at least len chars
  *
  */
 
diff --git a/contrib/bind9/lib/isc/unix/interfaceiter.c b/contrib/bind9/lib/isc/unix/interfaceiter.c
index 72ecdd2..4cfc821 100644
--- a/contrib/bind9/lib/isc/unix/interfaceiter.c
+++ b/contrib/bind9/lib/isc/unix/interfaceiter.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: interfaceiter.c,v 1.35.18.5 2005/04/29 00:17:08 marka Exp $ */
+/* $Id: interfaceiter.c,v 1.44.120.2 2009/02/16 23:47:15 tbox Exp $ */
 
 /*! \file */
 
@@ -145,6 +145,14 @@ get_addr(unsigned int family, isc_netaddr_t *dst, struct sockaddr *src,
  * Include system-dependent code.
  */
 
+#ifdef __linux
+#define ISC_IF_INET6_SZ \
+    sizeof("00000000000000000000000000000001 01 80 10 80 XXXXXXloXXXXXXXX\n")
+static isc_result_t linux_if_inet6_next(isc_interfaceiter_t *);
+static isc_result_t linux_if_inet6_current(isc_interfaceiter_t *);
+static void linux_if_inet6_first(isc_interfaceiter_t *iter);
+#endif
+
 #if HAVE_GETIFADDRS
 #include "ifiter_getifaddrs.c"
 #elif HAVE_IFLIST_SYSCTL
@@ -153,6 +161,88 @@ get_addr(unsigned int family, isc_netaddr_t *dst, struct sockaddr *src,
 #include "ifiter_ioctl.c"
 #endif
 
+#ifdef __linux
+static void
+linux_if_inet6_first(isc_interfaceiter_t *iter) {
+	if (iter->proc != NULL) {
+		rewind(iter->proc);
+		(void)linux_if_inet6_next(iter);
+	} else
+		iter->valid = ISC_R_NOMORE;
+}
+
+static isc_result_t
+linux_if_inet6_next(isc_interfaceiter_t *iter) {
+	if (iter->proc != NULL &&
+	    fgets(iter->entry, sizeof(iter->entry), iter->proc) != NULL)
+		iter->valid = ISC_R_SUCCESS;
+	else
+		iter->valid = ISC_R_NOMORE;
+	return (iter->valid);
+}
+
+static isc_result_t
+linux_if_inet6_current(isc_interfaceiter_t *iter) {
+	char address[33];
+	char name[IF_NAMESIZE+1];
+	struct in6_addr addr6;
+	int ifindex, prefix, flag3, flag4;
+	int res;
+	unsigned int i;
+
+	if (iter->valid != ISC_R_SUCCESS)
+		return (iter->valid);
+	if (iter->proc == NULL) {
+		isc_log_write(isc_lctx, ISC_LOGCATEGORY_GENERAL,
+			      ISC_LOGMODULE_INTERFACE, ISC_LOG_ERROR,
+			      "/proc/net/if_inet6:iter->proc == NULL");
+		return (ISC_R_FAILURE);
+	}
+
+	res = sscanf(iter->entry, "%32[a-f0-9] %x %x %x %x %16s\n",
+		     address, &ifindex, &prefix, &flag3, &flag4, name);
+	if (res != 6) {
+		isc_log_write(isc_lctx, ISC_LOGCATEGORY_GENERAL,
+			      ISC_LOGMODULE_INTERFACE, ISC_LOG_ERROR,
+			      "/proc/net/if_inet6:sscanf() -> %d (expected 6)",
+			      res);
+		return (ISC_R_FAILURE);
+	}
+	if (strlen(address) != 32) {
+		isc_log_write(isc_lctx, ISC_LOGCATEGORY_GENERAL,
+			      ISC_LOGMODULE_INTERFACE, ISC_LOG_ERROR,
+			      "/proc/net/if_inet6:strlen(%s) != 32", address);
+		return (ISC_R_FAILURE);
+	}
+	for (i = 0; i < 16; i++) {
+		unsigned char byte;
+		static const char hex[] = "0123456789abcdef";
+		byte = ((strchr(hex, address[i * 2]) - hex) << 4) |
+		       (strchr(hex, address[i * 2 + 1]) - hex);
+		addr6.s6_addr[i] = byte;
+	}
+	iter->current.af = AF_INET6;
+	iter->current.flags = INTERFACE_F_UP;
+	isc_netaddr_fromin6(&iter->current.address, &addr6);
+	if (isc_netaddr_islinklocal(&iter->current.address)) {
+		isc_netaddr_setzone(&iter->current.address,
+				    (isc_uint32_t)ifindex);
+	}
+	for (i = 0; i < 16; i++) {
+		if (prefix > 8) {
+			addr6.s6_addr[i] = 0xff;
+			prefix -= 8;
+		} else {
+			addr6.s6_addr[i] = (0xff << (8 - prefix)) & 0xff;
+			prefix = 0;
+		}
+	}
+	isc_netaddr_fromin6(&iter->current.netmask, &addr6);
+	strncpy(iter->current.name, name, sizeof(iter->current.name));
+	return (ISC_R_SUCCESS);
+}
+#endif
+
 /*
  * The remaining code is common to the sysctl and ioctl case.
  */
diff --git a/contrib/bind9/lib/isc/unix/ipv6.c b/contrib/bind9/lib/isc/unix/ipv6.c
index 3066e0c..61e984f 100644
--- a/contrib/bind9/lib/isc/unix/ipv6.c
+++ b/contrib/bind9/lib/isc/unix/ipv6.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ipv6.c,v 1.8.18.4 2006/08/25 05:25:51 marka Exp $ */
+/* $Id: ipv6.c,v 1.14 2007/06/19 23:47:18 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/unix/keyboard.c b/contrib/bind9/lib/isc/unix/keyboard.c
index db56b3c..8ee62d3 100644
--- a/contrib/bind9/lib/isc/unix/keyboard.c
+++ b/contrib/bind9/lib/isc/unix/keyboard.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: keyboard.c,v 1.11 2004/03/05 05:11:46 marka Exp $ */
+/* $Id: keyboard.c,v 1.13 2007/06/19 23:47:18 tbox Exp $ */
 
 #include <config.h>
 
diff --git a/contrib/bind9/lib/isc/unix/net.c b/contrib/bind9/lib/isc/unix/net.c
index 600ac92..b2fb30e 100644
--- a/contrib/bind9/lib/isc/unix/net.c
+++ b/contrib/bind9/lib/isc/unix/net.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: net.c,v 1.29.18.9 2008/07/04 05:52:05 each Exp $ */
+/* $Id: net.c,v 1.40 2008/07/04 05:52:31 each Exp $ */
 
 #include <config.h>
 
diff --git a/contrib/bind9/lib/isc/unix/os.c b/contrib/bind9/lib/isc/unix/os.c
index 6bbf059..c050d14 100644
--- a/contrib/bind9/lib/isc/unix/os.c
+++ b/contrib/bind9/lib/isc/unix/os.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: os.c,v 1.13.18.3 2005/10/14 02:13:08 marka Exp $ */
+/* $Id: os.c,v 1.18 2007/06/19 23:47:18 tbox Exp $ */
 
 #include <config.h>
 
diff --git a/contrib/bind9/lib/isc/unix/resource.c b/contrib/bind9/lib/isc/unix/resource.c
index e9bc5fd..8bd8885 100644
--- a/contrib/bind9/lib/isc/unix/resource.c
+++ b/contrib/bind9/lib/isc/unix/resource.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: resource.c,v 1.12.18.6 2008/08/05 07:17:05 marka Exp $ */
+/* $Id: resource.c,v 1.21.66.2 2009/02/13 23:47:39 tbox Exp $ */
 
 #include <config.h>
 
@@ -159,7 +159,11 @@ isc_resource_setlimit(isc_resource_t resource, isc_resourcevalue_t value) {
 		if (unixresult == 0)
 			return (ISC_R_SUCCESS);
 	}
-#elif defined(NR_OPEN) && defined(__linux__)
+#elif defined(__linux__)
+#ifndef NR_OPEN
+#define NR_OPEN (1024*1024)
+#endif
+
 	/*
 	 * Some Linux kernels don't accept RLIM_INFINIT; the maximum
 	 * possible value is the NR_OPEN defined in linux/fs.h.
diff --git a/contrib/bind9/lib/isc/unix/socket.c b/contrib/bind9/lib/isc/unix/socket.c
index 8b006e4..d09fe51 100644
--- a/contrib/bind9/lib/isc/unix/socket.c
+++ b/contrib/bind9/lib/isc/unix/socket.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: socket.c,v 1.237.18.56.2.1 2008/12/23 00:14:34 marka Exp $ */
+/* $Id: socket.c,v 1.308.12.8 2009/04/18 01:29:26 jinmei Exp $ */
 
 /*! \file */
 
@@ -50,10 +50,12 @@
 #include <isc/print.h>
 #include <isc/region.h>
 #include <isc/socket.h>
+#include <isc/stats.h>
 #include <isc/strerror.h>
 #include <isc/task.h>
 #include <isc/thread.h>
 #include <isc/util.h>
+#include <isc/xml.h>
 
 #ifdef ISC_PLATFORM_HAVESYSUNH
 #include <sys/un.h>
@@ -74,6 +76,10 @@
 #include "socket_p.h"
 #endif /* ISC_PLATFORM_USETHREADS */
 
+#if defined(SO_BSDCOMPAT) && defined(__linux__)
+#include <sys/utsname.h>
+#endif
+
 /*%
  * Choose the most preferable multiplex method.
  */
@@ -201,11 +207,6 @@ typedef enum { poll_idle, poll_active, poll_checking } pollstate_t;
 #define ISC_SOCKADDR_LEN_T unsigned int
 #endif
 
-
-#if defined(SO_BSDCOMPAT) && defined(__linux__)
-#include <sys/utsname.h>
-#endif
-
 /*%
  * Define what the possible "soft" errors can be.  These are non-fatal returns
  * of various network related functions, like recv() and so on.
@@ -268,7 +269,7 @@ typedef isc_event_t intev_t;
 #endif
 
 /*%
- * The size to raise the recieve buffer to (from BIND 8).
+ * The size to raise the receive buffer to (from BIND 8).
  */
 #define RCVBUFSIZE (32*1024)
 
@@ -283,12 +284,15 @@ struct isc_socket {
 	isc_socketmgr_t	       *manager;
 	isc_mutex_t		lock;
 	isc_sockettype_t	type;
+	const isc_statscounter_t	*statsindex;
 
 	/* Locked by socket lock. */
 	ISC_LINK(isc_socket_t)	link;
 	unsigned int		references;
 	int			fd;
 	int			pf;
+	char				name[16];
+	void *				tag;
 
 	ISC_LIST(isc_socketevent_t)		send_list;
 	ISC_LIST(isc_socketevent_t)		recv_list;
@@ -303,7 +307,7 @@ struct isc_socket {
 	intev_t			readable_ev;
 	intev_t			writable_ev;
 
-	isc_sockaddr_t		address;  /* remote address */
+	isc_sockaddr_t		peer_address;  /* remote address */
 
 	unsigned int		pending_recv : 1,
 				pending_send : 1,
@@ -321,6 +325,11 @@ struct isc_socket {
 	ISC_SOCKADDR_LEN_T	recvcmsgbuflen;
 	char			*sendcmsgbuf;
 	ISC_SOCKADDR_LEN_T	sendcmsgbuflen;
+
+	void			*fdwatcharg;
+	isc_sockfdwatch_t	fdwatchcb;
+	int			fdwatchflags;
+	isc_task_t		*fdwatchtask;
 };
 
 #define SOCKET_MANAGER_MAGIC	ISC_MAGIC('I', 'O', 'm', 'g')
@@ -332,6 +341,7 @@ struct isc_socketmgr {
 	isc_mem_t	       *mctx;
 	isc_mutex_t		lock;
 	isc_mutex_t		*fdlock;
+	isc_stats_t		*stats;
 #ifdef USE_KQUEUE
 	int			kqueue_fd;
 	int			nevents;
@@ -384,9 +394,9 @@ struct isc_socketmgr {
 static isc_socketmgr_t *socketmgr = NULL;
 #endif /* ISC_PLATFORM_USETHREADS */
 
-#define CLOSED		0	/* this one must be zero */
-#define MANAGED		1
-#define CLOSE_PENDING	2
+#define CLOSED			0	/* this one must be zero */
+#define MANAGED			1
+#define CLOSE_PENDING		2
 
 /*
  * send() and recv() iovec counts
@@ -408,6 +418,8 @@ static void internal_accept(isc_task_t *, isc_event_t *);
 static void internal_connect(isc_task_t *, isc_event_t *);
 static void internal_recv(isc_task_t *, isc_event_t *);
 static void internal_send(isc_task_t *, isc_event_t *);
+static void internal_fdwatch_write(isc_task_t *, isc_event_t *);
+static void internal_fdwatch_read(isc_task_t *, isc_event_t *);
 static void process_cmsg(isc_socket_t *, struct msghdr *, isc_socketevent_t *);
 static void build_msghdr_send(isc_socket_t *, isc_socketevent_t *,
 			      struct msghdr *, struct iovec *, size_t *);
@@ -427,6 +439,94 @@ static isc_boolean_t process_ctlfd(isc_socketmgr_t *manager);
 
 #define SOCK_DEAD(s)			((s)->references == 0)
 
+/*%
+ * Shortcut index arrays to get access to statistics counters.
+ */
+enum {
+	STATID_OPEN = 0,
+	STATID_OPENFAIL = 1,
+	STATID_CLOSE = 2,
+	STATID_BINDFAIL = 3,
+	STATID_CONNECTFAIL = 4,
+	STATID_CONNECT = 5,
+	STATID_ACCEPTFAIL = 6,
+	STATID_ACCEPT = 7,
+	STATID_SENDFAIL = 8,
+	STATID_RECVFAIL = 9
+};
+static const isc_statscounter_t upd4statsindex[] = {
+	isc_sockstatscounter_udp4open,
+	isc_sockstatscounter_udp4openfail,
+	isc_sockstatscounter_udp4close,
+	isc_sockstatscounter_udp4bindfail,
+	isc_sockstatscounter_udp4connectfail,
+	isc_sockstatscounter_udp4connect,
+	-1,
+	-1,
+	isc_sockstatscounter_udp4sendfail,
+	isc_sockstatscounter_udp4recvfail
+};
+static const isc_statscounter_t upd6statsindex[] = {
+	isc_sockstatscounter_udp6open,
+	isc_sockstatscounter_udp6openfail,
+	isc_sockstatscounter_udp6close,
+	isc_sockstatscounter_udp6bindfail,
+	isc_sockstatscounter_udp6connectfail,
+	isc_sockstatscounter_udp6connect,
+	-1,
+	-1,
+	isc_sockstatscounter_udp6sendfail,
+	isc_sockstatscounter_udp6recvfail
+};
+static const isc_statscounter_t tcp4statsindex[] = {
+	isc_sockstatscounter_tcp4open,
+	isc_sockstatscounter_tcp4openfail,
+	isc_sockstatscounter_tcp4close,
+	isc_sockstatscounter_tcp4bindfail,
+	isc_sockstatscounter_tcp4connectfail,
+	isc_sockstatscounter_tcp4connect,
+	isc_sockstatscounter_tcp4acceptfail,
+	isc_sockstatscounter_tcp4accept,
+	isc_sockstatscounter_tcp4sendfail,
+	isc_sockstatscounter_tcp4recvfail
+};
+static const isc_statscounter_t tcp6statsindex[] = {
+	isc_sockstatscounter_tcp6open,
+	isc_sockstatscounter_tcp6openfail,
+	isc_sockstatscounter_tcp6close,
+	isc_sockstatscounter_tcp6bindfail,
+	isc_sockstatscounter_tcp6connectfail,
+	isc_sockstatscounter_tcp6connect,
+	isc_sockstatscounter_tcp6acceptfail,
+	isc_sockstatscounter_tcp6accept,
+	isc_sockstatscounter_tcp6sendfail,
+	isc_sockstatscounter_tcp6recvfail
+};
+static const isc_statscounter_t unixstatsindex[] = {
+	isc_sockstatscounter_unixopen,
+	isc_sockstatscounter_unixopenfail,
+	isc_sockstatscounter_unixclose,
+	isc_sockstatscounter_unixbindfail,
+	isc_sockstatscounter_unixconnectfail,
+	isc_sockstatscounter_unixconnect,
+	isc_sockstatscounter_unixacceptfail,
+	isc_sockstatscounter_unixaccept,
+	isc_sockstatscounter_unixsendfail,
+	isc_sockstatscounter_unixrecvfail
+};
+static const isc_statscounter_t fdwatchstatsindex[] = {
+	-1,
+	-1,
+	isc_sockstatscounter_fdwatchclose,
+	isc_sockstatscounter_fdwatchbindfail,
+	isc_sockstatscounter_fdwatchconnectfail,
+	isc_sockstatscounter_fdwatchconnect,
+	-1,
+	-1,
+	isc_sockstatscounter_fdwatchsendfail,
+	isc_sockstatscounter_fdwatchrecvfail
+};
+
 static void
 manager_log(isc_socketmgr_t *sockmgr,
 	    isc_logcategory_t *category, isc_logmodule_t *module, int level,
@@ -516,6 +616,17 @@ FIX_IPV6_RECVPKTINFO(isc_socket_t *sock)
 #define FIX_IPV6_RECVPKTINFO(sock) (void)0
 #endif
 
+/*%
+ * Increment socket-related statistics counters.
+ */
+static inline void
+inc_stats(isc_stats_t *stats, isc_statscounter_t counterid) {
+	REQUIRE(counterid != -1);
+
+	if (stats != NULL)
+		isc_stats_increment(stats, counterid);
+}
+
 static inline isc_result_t
 watch_fd(isc_socketmgr_t *manager, int fd, int msg) {
 	isc_result_t result = ISC_R_SUCCESS;
@@ -695,6 +806,7 @@ wakeup_socket(isc_socketmgr_t *manager, int fd, int msg) {
 	LOCK(&manager->fdlock[lockid]);
 	if (manager->fdstate[fd] == CLOSE_PENDING) {
 		UNLOCK(&manager->fdlock[lockid]);
+
 		/*
 		 * We accept (and ignore) any error from unwatch_fd() as we are
 		 * closing the socket, hoping it doesn't leave dangling state in
@@ -1119,7 +1231,7 @@ build_msghdr_send(isc_socket_t *sock, isc_socketevent_t *dev,
 
 /*
  * Construct an iov array and attach it to the msghdr passed in.  This is
- * the RECV constructor, which will use the avialable region of the buffer
+ * the RECV constructor, which will use the available region of the buffer
  * (if using a buffer list) or will use the internal region (if a single
  * buffer I/O is requested).
  *
@@ -1169,7 +1281,7 @@ build_msghdr_recv(isc_socket_t *sock, isc_socketevent_t *dev,
 	} else { /* TCP */
 		msg->msg_name = NULL;
 		msg->msg_namelen = 0;
-		dev->address = sock->address;
+		dev->address = sock->peer_address;
 	}
 
 	buffer = ISC_LIST_HEAD(dev->bufferlist);
@@ -1258,10 +1370,10 @@ set_dev_address(isc_sockaddr_t *address, isc_socket_t *sock,
 		if (address != NULL)
 			dev->address = *address;
 		else
-			dev->address = sock->address;
+			dev->address = sock->peer_address;
 	} else if (sock->type == isc_sockettype_tcp) {
 		INSIST(address == NULL);
-		dev->address = sock->address;
+		dev->address = sock->peer_address;
 	}
 }
 
@@ -1368,6 +1480,8 @@ doio_recv(isc_socket_t *sock, isc_socketevent_t *dev) {
 	if (recv_errno == _system) { \
 		if (sock->connected) { \
 			dev->result = _isc; \
+			inc_stats(sock->manager->stats, \
+				  sock->statsindex[STATID_RECVFAIL]); \
 			return (DOIO_HARD); \
 		} \
 		return (DOIO_SOFT); \
@@ -1375,6 +1489,8 @@ doio_recv(isc_socket_t *sock, isc_socketevent_t *dev) {
 #define ALWAYS_HARD(_system, _isc) \
 	if (recv_errno == _system) { \
 		dev->result = _isc; \
+		inc_stats(sock->manager->stats, \
+			  sock->statsindex[STATID_RECVFAIL]); \
 		return (DOIO_HARD); \
 	}
 
@@ -1398,6 +1514,8 @@ doio_recv(isc_socket_t *sock, isc_socketevent_t *dev) {
 #undef ALWAYS_HARD
 
 		dev->result = isc__errno2result(recv_errno);
+		inc_stats(sock->manager->stats,
+			  sock->statsindex[STATID_RECVFAIL]);
 		return (DOIO_HARD);
 	}
 
@@ -1526,6 +1644,8 @@ doio_send(isc_socket_t *sock, isc_socketevent_t *dev) {
 	if (send_errno == _system) { \
 		if (sock->connected) { \
 			dev->result = _isc; \
+			inc_stats(sock->manager->stats, \
+				  sock->statsindex[STATID_SENDFAIL]); \
 			return (DOIO_HARD); \
 		} \
 		return (DOIO_SOFT); \
@@ -1533,6 +1653,8 @@ doio_send(isc_socket_t *sock, isc_socketevent_t *dev) {
 #define ALWAYS_HARD(_system, _isc) \
 	if (send_errno == _system) { \
 		dev->result = _isc; \
+		inc_stats(sock->manager->stats, \
+			  sock->statsindex[STATID_SENDFAIL]); \
 		return (DOIO_HARD); \
 	}
 
@@ -1567,14 +1689,19 @@ doio_send(isc_socket_t *sock, isc_socketevent_t *dev) {
 		UNEXPECTED_ERROR(__FILE__, __LINE__, "internal_send: %s: %s",
 				 addrbuf, strbuf);
 		dev->result = isc__errno2result(send_errno);
+		inc_stats(sock->manager->stats,
+			  sock->statsindex[STATID_SENDFAIL]);
 		return (DOIO_HARD);
 	}
 
-	if (cc == 0)
+	if (cc == 0) {
+		inc_stats(sock->manager->stats,
+			  sock->statsindex[STATID_SENDFAIL]);
 		UNEXPECTED_ERROR(__FILE__, __LINE__,
-				 "internal_send: send() %s 0",
+				 "doio_send: send() %s 0",
 				 isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL,
 						ISC_MSG_RETURNED, "returned"));
+	}
 
 	/*
 	 * If we write less than we expected, update counters, poke.
@@ -1598,20 +1725,37 @@ doio_send(isc_socket_t *sock, isc_socketevent_t *dev) {
  * references exist.
  */
 static void
-closesocket(isc_socketmgr_t *manager, isc_sockettype_t type, int fd) {
+closesocket(isc_socketmgr_t *manager, isc_socket_t *sock, int fd) {
+	isc_sockettype_t type = sock->type;
 	int lockid = FDLOCK_ID(fd);
 
-	UNUSED(type);
-
 	/*
 	 * No one has this socket open, so the watcher doesn't have to be
 	 * poked, and the socket doesn't have to be locked.
 	 */
 	LOCK(&manager->fdlock[lockid]);
 	manager->fds[fd] = NULL;
-	manager->fdstate[fd] = CLOSE_PENDING;
+	if (type == isc_sockettype_fdwatch)
+		manager->fdstate[fd] = CLOSED;
+	else
+		manager->fdstate[fd] = CLOSE_PENDING;
 	UNLOCK(&manager->fdlock[lockid]);
-	select_poke(manager, fd, SELECT_POKE_CLOSE);
+	if (type == isc_sockettype_fdwatch) {
+		/*
+		 * The caller may close the socket once this function returns,
+		 * and `fd' may be reassigned for a new socket.  So we do
+		 * unwatch_fd() here, rather than defer it via select_poke().
+		 * Note: this may complicate data protection among threads and
+		 * may reduce performance due to additional locks.  One way to
+		 * solve this would be to dup() the watched descriptor, but we
+		 * take a simpler approach at this moment.
+		 */
+		(void)unwatch_fd(manager, fd, SELECT_POKE_READ);
+		(void)unwatch_fd(manager, fd, SELECT_POKE_WRITE);
+	} else
+		select_poke(manager, fd, SELECT_POKE_CLOSE);
+
+	inc_stats(manager->stats, sock->statsindex[STATID_CLOSE]);
 
 	/*
 	 * update manager->maxfd here (XXX: this should be implemented more
@@ -1661,7 +1805,7 @@ destroy(isc_socket_t **sockp) {
 	if (sock->fd >= 0) {
 		fd = sock->fd;
 		sock->fd = -1;
-		closesocket(manager, sock->type, fd);
+		closesocket(manager, sock, fd);
 	}
 
 	LOCK(&manager->lock);
@@ -1699,6 +1843,7 @@ allocate_socket(isc_socketmgr_t *manager, isc_sockettype_t type,
 	sock->manager = manager;
 	sock->type = type;
 	sock->fd = -1;
+	sock->statsindex = NULL;
 
 	ISC_LINK_INIT(sock, link);
 
@@ -1733,6 +1878,9 @@ allocate_socket(isc_socketmgr_t *manager, isc_sockettype_t type,
 			goto error;
 	}
 
+	memset(sock->name, 0, sizeof(sock->name));
+	sock->tag = NULL;
+
 	/*
 	 * set up list of readers and writers to be initially empty
 	 */
@@ -1884,6 +2032,12 @@ opensocket(isc_socketmgr_t *manager, isc_socket_t *sock) {
 	case isc_sockettype_unix:
 		sock->fd = socket(sock->pf, SOCK_STREAM, 0);
 		break;
+	case isc_sockettype_fdwatch:
+		/*
+		 * We should not be called for isc_sockettype_fdwatch sockets.
+		 */
+		INSIST(0);
+		break;
 	}
 	if (sock->fd == -1 && errno == EINTR && tries++ < 42)
 		goto again;
@@ -1927,6 +2081,13 @@ opensocket(isc_socketmgr_t *manager, isc_socket_t *sock) {
 		switch (errno) {
 		case EMFILE:
 		case ENFILE:
+			isc__strerror(errno, strbuf, sizeof(strbuf));
+			isc_log_iwrite(isc_lctx, ISC_LOGCATEGORY_GENERAL,
+				       ISC_LOGMODULE_SOCKET, ISC_LOG_ERROR,
+				       isc_msgcat, ISC_MSGSET_SOCKET,
+				       ISC_MSG_TOOMANYFDS,
+				       "%s: %s", err, strbuf);
+			/* fallthrough */
 		case ENOBUFS:
 			return (ISC_R_NORESOURCES);
 
@@ -2108,6 +2269,8 @@ opensocket(isc_socketmgr_t *manager, isc_socket_t *sock) {
 	}
 #endif /* defined(USE_CMSG) || defined(SO_RCVBUF) */
 
+	inc_stats(manager->stats, sock->statsindex[STATID_OPEN]);
+
 	return (ISC_R_SUCCESS);
 }
 
@@ -2127,14 +2290,32 @@ isc_socket_create(isc_socketmgr_t *manager, int pf, isc_sockettype_t type,
 
 	REQUIRE(VALID_MANAGER(manager));
 	REQUIRE(socketp != NULL && *socketp == NULL);
+	REQUIRE(type != isc_sockettype_fdwatch);
 
 	result = allocate_socket(manager, type, &sock);
 	if (result != ISC_R_SUCCESS)
 		return (result);
 
+	switch (sock->type) {
+	case isc_sockettype_udp:
+		sock->statsindex =
+			(pf == AF_INET) ? upd4statsindex : upd6statsindex;
+		break;
+	case isc_sockettype_tcp:
+		sock->statsindex =
+			(pf == AF_INET) ? tcp4statsindex : tcp6statsindex;
+		break;
+	case isc_sockettype_unix:
+		sock->statsindex = unixstatsindex;
+		break;
+	default:
+		INSIST(0);
+	}
+
 	sock->pf = pf;
 	result = opensocket(manager, sock);
 	if (result != ISC_R_SUCCESS) {
+		inc_stats(manager->stats, sock->statsindex[STATID_OPENFAIL]);
 		free_socket(&sock);
 		return (result);
 	}
@@ -2179,6 +2360,7 @@ isc_socket_open(isc_socket_t *sock) {
 
 	LOCK(&sock->lock);
 	REQUIRE(sock->references == 1);
+	REQUIRE(sock->type != isc_sockettype_fdwatch);
 	UNLOCK(&sock->lock);
 	/*
 	 * We don't need to retain the lock hereafter, since no one else has
@@ -2214,6 +2396,68 @@ isc_socket_open(isc_socket_t *sock) {
 }
 
 /*
+ * Create a new 'type' socket managed by 'manager'.  Events
+ * will be posted to 'task' and when dispatched 'action' will be
+ * called with 'arg' as the arg value.  The new socket is returned
+ * in 'socketp'.
+ */
+isc_result_t
+isc_socket_fdwatchcreate(isc_socketmgr_t *manager, int fd, int flags,
+			 isc_sockfdwatch_t callback, void *cbarg,
+			 isc_task_t *task, isc_socket_t **socketp)
+{
+	isc_socket_t *sock = NULL;
+	isc_result_t result;
+	int lockid;
+
+	REQUIRE(VALID_MANAGER(manager));
+	REQUIRE(socketp != NULL && *socketp == NULL);
+
+	result = allocate_socket(manager, isc_sockettype_fdwatch, &sock);
+	if (result != ISC_R_SUCCESS)
+		return (result);
+
+	sock->fd = fd;
+	sock->fdwatcharg = cbarg;
+	sock->fdwatchcb = callback;
+	sock->fdwatchflags = flags;
+	sock->fdwatchtask = task;
+	sock->statsindex = fdwatchstatsindex;
+
+	sock->references = 1;
+	*socketp = sock;
+
+	/*
+	 * Note we don't have to lock the socket like we normally would because
+	 * there are no external references to it yet.
+	 */
+
+	lockid = FDLOCK_ID(sock->fd);
+	LOCK(&manager->fdlock[lockid]);
+	manager->fds[sock->fd] = sock;
+	manager->fdstate[sock->fd] = MANAGED;
+	UNLOCK(&manager->fdlock[lockid]);
+
+	LOCK(&manager->lock);
+	ISC_LIST_APPEND(manager->socklist, sock, link);
+#ifdef USE_SELECT
+	if (manager->maxfd < sock->fd)
+		manager->maxfd = sock->fd;
+#endif
+	UNLOCK(&manager->lock);
+
+	if (flags & ISC_SOCKFDWATCH_READ)
+		select_poke(sock->manager, sock->fd, SELECT_POKE_READ);
+	if (flags & ISC_SOCKFDWATCH_WRITE)
+		select_poke(sock->manager, sock->fd, SELECT_POKE_WRITE);
+
+	socket_log(sock, NULL, CREATION, isc_msgcat, ISC_MSGSET_SOCKET,
+		   ISC_MSG_CREATED, "fdwatch-created");
+
+	return (ISC_R_SUCCESS);
+}
+
+/*
  * Attach to a socket.  Caller must explicitly detach when it is done.
  */
 void
@@ -2257,17 +2501,15 @@ isc_socket_detach(isc_socket_t **socketp) {
 isc_result_t
 isc_socket_close(isc_socket_t *sock) {
 	int fd;
+	isc_socketmgr_t *manager;
+	isc_sockettype_t type;
 
 	REQUIRE(VALID_SOCKET(sock));
 
 	LOCK(&sock->lock);
-	REQUIRE(sock->references == 1);
-	UNLOCK(&sock->lock);
-	/*
-	 * We don't need to retain the lock hereafter, since no one else has
-	 * this socket.
-	 */
 
+	REQUIRE(sock->references == 1);
+	REQUIRE(sock->type != isc_sockettype_fdwatch);
 	REQUIRE(sock->fd >= 0 && sock->fd < (int)sock->manager->maxsocks);
 
 	INSIST(!sock->connecting);
@@ -2279,15 +2521,21 @@ isc_socket_close(isc_socket_t *sock) {
 	INSIST(ISC_LIST_EMPTY(sock->accept_list));
 	INSIST(sock->connect_ev == NULL);
 
+	manager = sock->manager;
+	type = sock->type;
 	fd = sock->fd;
 	sock->fd = -1;
+	memset(sock->name, 0, sizeof(sock->name));
+	sock->tag = NULL;
 	sock->listener = 0;
 	sock->connected = 0;
 	sock->connecting = 0;
 	sock->bound = 0;
-	isc_sockaddr_any(&sock->address);
+	isc_sockaddr_any(&sock->peer_address);
+
+	UNLOCK(&sock->lock);
 
-	closesocket(sock->manager, sock->type, fd);
+	closesocket(manager, sock, fd);
 
 	return (ISC_R_SUCCESS);
 }
@@ -2304,50 +2552,68 @@ static void
 dispatch_recv(isc_socket_t *sock) {
 	intev_t *iev;
 	isc_socketevent_t *ev;
+	isc_task_t *sender;
 
 	INSIST(!sock->pending_recv);
 
-	ev = ISC_LIST_HEAD(sock->recv_list);
-	if (ev == NULL)
-		return;
+	if (sock->type != isc_sockettype_fdwatch) {
+		ev = ISC_LIST_HEAD(sock->recv_list);
+		if (ev == NULL)
+			return;
+		socket_log(sock, NULL, EVENT, NULL, 0, 0,
+			   "dispatch_recv:  event %p -> task %p",
+			   ev, ev->ev_sender);
+		sender = ev->ev_sender;
+	} else {
+		sender = sock->fdwatchtask;
+	}
 
 	sock->pending_recv = 1;
 	iev = &sock->readable_ev;
 
-	socket_log(sock, NULL, EVENT, NULL, 0, 0,
-		   "dispatch_recv:  event %p -> task %p", ev, ev->ev_sender);
-
 	sock->references++;
 	iev->ev_sender = sock;
-	iev->ev_action = internal_recv;
+	if (sock->type == isc_sockettype_fdwatch)
+		iev->ev_action = internal_fdwatch_read;
+	else
+		iev->ev_action = internal_recv;
 	iev->ev_arg = sock;
 
-	isc_task_send(ev->ev_sender, (isc_event_t **)&iev);
+	isc_task_send(sender, (isc_event_t **)&iev);
 }
 
 static void
 dispatch_send(isc_socket_t *sock) {
 	intev_t *iev;
 	isc_socketevent_t *ev;
+	isc_task_t *sender;
 
 	INSIST(!sock->pending_send);
 
-	ev = ISC_LIST_HEAD(sock->send_list);
-	if (ev == NULL)
-		return;
+	if (sock->type != isc_sockettype_fdwatch) {
+		ev = ISC_LIST_HEAD(sock->send_list);
+		if (ev == NULL)
+			return;
+		socket_log(sock, NULL, EVENT, NULL, 0, 0,
+			   "dispatch_send:  event %p -> task %p",
+			   ev, ev->ev_sender);
+		sender = ev->ev_sender;
+	} else {
+		sender = sock->fdwatchtask;
+	}
 
 	sock->pending_send = 1;
 	iev = &sock->writable_ev;
 
-	socket_log(sock, NULL, EVENT, NULL, 0, 0,
-		   "dispatch_send:  event %p -> task %p", ev, ev->ev_sender);
-
 	sock->references++;
 	iev->ev_sender = sock;
-	iev->ev_action = internal_send;
+	if (sock->type == isc_sockettype_fdwatch)
+		iev->ev_action = internal_fdwatch_write;
+	else
+		iev->ev_action = internal_send;
 	iev->ev_arg = sock;
 
-	isc_task_send(ev->ev_sender, (isc_event_t **)&iev);
+	isc_task_send(sender, (isc_event_t **)&iev);
 }
 
 /*
@@ -2517,12 +2783,12 @@ internal_accept(isc_task_t *me, isc_event_t *ev) {
 	 * a documented error for accept().  ECONNABORTED has been
 	 * reported for Solaris 8.  The rest are thrown in not because
 	 * we have seen them but because they are ignored by other
-	 * deamons such as BIND 8 and Apache.
+	 * daemons such as BIND 8 and Apache.
 	 */
 
-	addrlen = sizeof(dev->newsocket->address.type);
-	memset(&dev->newsocket->address.type, 0, addrlen);
-	fd = accept(sock->fd, &dev->newsocket->address.type.sa,
+	addrlen = sizeof(dev->newsocket->peer_address.type);
+	memset(&dev->newsocket->peer_address.type, 0, addrlen);
+	fd = accept(sock->fd, &dev->newsocket->peer_address.type.sa,
 		    (void *)&addrlen);
 
 #ifdef F_DUPFD
@@ -2592,14 +2858,14 @@ internal_accept(isc_task_t *me, isc_event_t *ev) {
 
 			(void)close(fd);
 			goto soft_error;
-		} else if (dev->newsocket->address.type.sa.sa_family !=
+		} else if (dev->newsocket->peer_address.type.sa.sa_family !=
 			   sock->pf)
 		{
 			UNEXPECTED_ERROR(__FILE__, __LINE__,
 					 "internal_accept(): "
 					 "accept() returned peer address "
 					 "family %u (expected %u)",
-					 dev->newsocket->address.
+					 dev->newsocket->peer_address.
 					 type.sa.sa_family,
 					 sock->pf);
 			(void)close(fd);
@@ -2618,7 +2884,7 @@ internal_accept(isc_task_t *me, isc_event_t *ev) {
 	}
 
 	if (fd != -1) {
-		dev->newsocket->address.length = addrlen;
+		dev->newsocket->peer_address.length = addrlen;
 		dev->newsocket->pf = sock->pf;
 	}
 
@@ -2662,20 +2928,23 @@ internal_accept(isc_task_t *me, isc_event_t *ev) {
 		/*
 		 * Save away the remote address
 		 */
-		dev->address = dev->newsocket->address;
+		dev->address = dev->newsocket->peer_address;
 
 #ifdef USE_SELECT
 		if (manager->maxfd < fd)
 			manager->maxfd = fd;
 #endif
 
-		socket_log(sock, &dev->newsocket->address, CREATION,
+		socket_log(sock, &dev->newsocket->peer_address, CREATION,
 			   isc_msgcat, ISC_MSGSET_SOCKET, ISC_MSG_ACCEPTEDCXN,
 			   "accepted connection, new socket %p",
 			   dev->newsocket);
 
 		UNLOCK(&manager->lock);
+
+		inc_stats(manager->stats, sock->statsindex[STATID_ACCEPT]);
 	} else {
+		inc_stats(manager->stats, sock->statsindex[STATID_ACCEPTFAIL]);
 		dev->newsocket->references--;
 		free_socket(&dev->newsocket);
 	}
@@ -2693,6 +2962,8 @@ internal_accept(isc_task_t *me, isc_event_t *ev) {
  soft_error:
 	select_poke(sock->manager, sock->fd, SELECT_POKE_ACCEPT);
 	UNLOCK(&sock->lock);
+
+	inc_stats(manager->stats, sock->statsindex[STATID_ACCEPTFAIL]);
 	return;
 }
 
@@ -2816,6 +3087,86 @@ internal_send(isc_task_t *me, isc_event_t *ev) {
 	UNLOCK(&sock->lock);
 }
 
+static void
+internal_fdwatch_write(isc_task_t *me, isc_event_t *ev) {
+	isc_socket_t *sock;
+	int more_data;
+
+	INSIST(ev->ev_type == ISC_SOCKEVENT_INTW);
+
+	/*
+	 * Find out what socket this is and lock it.
+	 */
+	sock = (isc_socket_t *)ev->ev_sender;
+	INSIST(VALID_SOCKET(sock));
+
+	LOCK(&sock->lock);
+	socket_log(sock, NULL, IOEVENT,
+		   isc_msgcat, ISC_MSGSET_SOCKET, ISC_MSG_INTERNALSEND,
+		   "internal_fdwatch_write: task %p got event %p", me, ev);
+
+	INSIST(sock->pending_send == 1);
+
+	UNLOCK(&sock->lock);
+	more_data = (sock->fdwatchcb)(me, sock, sock->fdwatcharg);
+	LOCK(&sock->lock);
+
+	sock->pending_send = 0;
+
+	INSIST(sock->references > 0);
+	sock->references--;  /* the internal event is done with this socket */
+	if (sock->references == 0) {
+		UNLOCK(&sock->lock);
+		destroy(&sock);
+		return;
+	}
+
+	if (more_data)
+		select_poke(sock->manager, sock->fd, SELECT_POKE_WRITE);
+
+	UNLOCK(&sock->lock);
+}
+
+static void
+internal_fdwatch_read(isc_task_t *me, isc_event_t *ev) {
+	isc_socket_t *sock;
+	int more_data;
+
+	INSIST(ev->ev_type == ISC_SOCKEVENT_INTR);
+
+	/*
+	 * Find out what socket this is and lock it.
+	 */
+	sock = (isc_socket_t *)ev->ev_sender;
+	INSIST(VALID_SOCKET(sock));
+
+	LOCK(&sock->lock);
+	socket_log(sock, NULL, IOEVENT,
+		   isc_msgcat, ISC_MSGSET_SOCKET, ISC_MSG_INTERNALRECV,
+		   "internal_fdwatch_read: task %p got event %p", me, ev);
+
+	INSIST(sock->pending_recv == 1);
+
+	UNLOCK(&sock->lock);
+	more_data = (sock->fdwatchcb)(me, sock, sock->fdwatcharg);
+	LOCK(&sock->lock);
+
+	sock->pending_recv = 0;
+
+	INSIST(sock->references > 0);
+	sock->references--;  /* the internal event is done with this socket */
+	if (sock->references == 0) {
+		UNLOCK(&sock->lock);
+		destroy(&sock);
+		return;
+	}
+
+	if (more_data)
+		select_poke(sock->manager, sock->fd, SELECT_POKE_READ);
+
+	UNLOCK(&sock->lock);
+}
+
 /*
  * Process read/writes on each fd here.  Avoid locking
  * and unlocking twice if both reads and writes are possible.
@@ -2826,6 +3177,7 @@ process_fd(isc_socketmgr_t *manager, int fd, isc_boolean_t readable,
 {
 	isc_socket_t *sock;
 	isc_boolean_t unlock_sock;
+	isc_boolean_t unwatch_read = ISC_FALSE, unwatch_write = ISC_FALSE;
 	int lockid = FDLOCK_ID(fd);
 
 	/*
@@ -2841,11 +3193,10 @@ process_fd(isc_socketmgr_t *manager, int fd, isc_boolean_t readable,
 	}
 
 	sock = manager->fds[fd];
-	UNLOCK(&manager->fdlock[lockid]);
 	unlock_sock = ISC_FALSE;
 	if (readable) {
 		if (sock == NULL) {
-			(void)unwatch_fd(manager, fd, SELECT_POKE_READ);
+			unwatch_read = ISC_TRUE;
 			goto check_write;
 		}
 		unlock_sock = ISC_TRUE;
@@ -2856,13 +3207,13 @@ process_fd(isc_socketmgr_t *manager, int fd, isc_boolean_t readable,
 			else
 				dispatch_recv(sock);
 		}
-		(void)unwatch_fd(manager, fd, SELECT_POKE_READ);
+		unwatch_read = ISC_TRUE;
 	}
 check_write:
 	if (writeable) {
 		if (sock == NULL) {
-			(void)unwatch_fd(manager, fd, SELECT_POKE_WRITE);
-			return;
+			unwatch_write = ISC_TRUE;
+			goto unlock_fd;
 		}
 		if (!unlock_sock) {
 			unlock_sock = ISC_TRUE;
@@ -2874,10 +3225,18 @@ check_write:
 			else
 				dispatch_send(sock);
 		}
-		(void)unwatch_fd(manager, fd, SELECT_POKE_WRITE);
+		unwatch_write = ISC_TRUE;
 	}
 	if (unlock_sock)
 		UNLOCK(&sock->lock);
+
+ unlock_fd:
+	UNLOCK(&manager->fdlock[lockid]);
+	if (unwatch_read)
+		(void)unwatch_fd(manager, fd, SELECT_POKE_READ);
+	if (unwatch_write)
+		(void)unwatch_fd(manager, fd, SELECT_POKE_WRITE);
+
 }
 
 #ifdef USE_KQUEUE
@@ -3184,7 +3543,7 @@ watcher(void *uap) {
 #endif
 	}
 
-	manager_log(manager, TRACE,
+	manager_log(manager, TRACE, "%s",
 		    isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL,
 				   ISC_MSG_EXITING, "watcher exiting"));
 
@@ -3207,6 +3566,9 @@ isc__socketmgr_setreserved(isc_socketmgr_t *manager, isc_uint32_t reserved) {
 static isc_result_t
 setup_watcher(isc_mem_t *mctx, isc_socketmgr_t *manager) {
 	isc_result_t result;
+#if defined(USE_KQUEUE) || defined(USE_EPOLL) || defined(USE_DEVPOLL)
+	char strbuf[ISC_STRERRORSIZE];
+#endif
 
 #ifdef USE_KQUEUE
 	manager->nevents = ISC_SOCKET_MAXEVENTS;
@@ -3217,6 +3579,12 @@ setup_watcher(isc_mem_t *mctx, isc_socketmgr_t *manager) {
 	manager->kqueue_fd = kqueue();
 	if (manager->kqueue_fd == -1) {
 		result = isc__errno2result(errno);
+		isc__strerror(errno, strbuf, sizeof(strbuf));
+		UNEXPECTED_ERROR(__FILE__, __LINE__,
+				 "kqueue %s: %s",
+				 isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL,
+						ISC_MSG_FAILED, "failed"),
+				 strbuf);
 		isc_mem_put(mctx, manager->events,
 			    sizeof(struct kevent) * manager->nevents);
 		return (result);
@@ -3240,6 +3608,12 @@ setup_watcher(isc_mem_t *mctx, isc_socketmgr_t *manager) {
 	manager->epoll_fd = epoll_create(manager->nevents);
 	if (manager->epoll_fd == -1) {
 		result = isc__errno2result(errno);
+		isc__strerror(errno, strbuf, sizeof(strbuf));
+		UNEXPECTED_ERROR(__FILE__, __LINE__,
+				 "epoll_create %s: %s",
+				 isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL,
+						ISC_MSG_FAILED, "failed"),
+				 strbuf);
 		isc_mem_put(mctx, manager->events,
 			    sizeof(struct epoll_event) * manager->nevents);
 		return (result);
@@ -3278,6 +3652,12 @@ setup_watcher(isc_mem_t *mctx, isc_socketmgr_t *manager) {
 	manager->devpoll_fd = open("/dev/poll", O_RDWR);
 	if (manager->devpoll_fd == -1) {
 		result = isc__errno2result(errno);
+		isc__strerror(errno, strbuf, sizeof(strbuf));
+		UNEXPECTED_ERROR(__FILE__, __LINE__,
+				 "open(/dev/poll) %s: %s",
+				 isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL,
+						ISC_MSG_FAILED, "failed"),
+				 strbuf);
 		isc_mem_put(mctx, manager->events,
 			    sizeof(struct pollfd) * manager->nevents);
 		isc_mem_put(mctx, manager->fdpollinfo,
@@ -3441,10 +3821,11 @@ isc_socketmgr_create2(isc_mem_t *mctx, isc_socketmgr_t **managerp,
 		goto free_manager;
 	}
 	manager->fdstate = isc_mem_get(mctx, manager->maxsocks * sizeof(int));
-	if (manager->fds == NULL) {
+	if (manager->fdstate == NULL) {
 		result = ISC_R_NOMEMORY;
 		goto free_manager;
 	}
+	manager->stats = NULL;
 
 	manager->magic = SOCKET_MANAGER_MAGIC;
 	manager->mctx = NULL;
@@ -3582,6 +3963,16 @@ isc_socketmgr_getmaxsockets(isc_socketmgr_t *manager, unsigned int *nsockp) {
 }
 
 void
+isc_socketmgr_setstats(isc_socketmgr_t *manager, isc_stats_t *stats) {
+	REQUIRE(VALID_MANAGER(manager));
+	REQUIRE(ISC_LIST_EMPTY(manager->socklist));
+	REQUIRE(manager->stats == NULL);
+	REQUIRE(isc_stats_ncounters(stats) == isc_sockstatscounter_max);
+
+	isc_stats_attach(stats, &manager->stats);
+}
+
+void
 isc_socketmgr_destroy(isc_socketmgr_t **managerp) {
 	isc_socketmgr_t *manager;
 	int i;
@@ -3610,7 +4001,7 @@ isc_socketmgr_destroy(isc_socketmgr_t **managerp) {
 	 * Wait for all sockets to be destroyed.
 	 */
 	while (!ISC_LIST_EMPTY(manager->socklist)) {
-		manager_log(manager, CREATION,
+		manager_log(manager, CREATION, "%s",
 			    isc_msgcat_get(isc_msgcat, ISC_MSGSET_SOCKET,
 					   ISC_MSG_SOCKETSREMAIN,
 					   "sockets exist"));
@@ -3621,7 +4012,7 @@ isc_socketmgr_destroy(isc_socketmgr_t **managerp) {
 	 * Hope all sockets have been destroyed.
 	 */
 	if (!ISC_LIST_EMPTY(manager->socklist)) {
-		manager_log(manager, CREATION,
+		manager_log(manager, CREATION, "%s",
 			    isc_msgcat_get(isc_msgcat, ISC_MSGSET_SOCKET,
 					   ISC_MSG_SOCKETSREMAIN,
 					   "sockets exist"));
@@ -3669,6 +4060,9 @@ isc_socketmgr_destroy(isc_socketmgr_t **managerp) {
 	isc_mem_put(manager->mctx, manager->fdstate,
 		    manager->maxsocks * sizeof(int));
 
+	if (manager->stats != NULL)
+		isc_stats_detach(&manager->stats);
+
 	if (manager->fdlock != NULL) {
 		for (i = 0; i < FDLOCK_COUNT; i++)
 			DESTROYLOCK(&manager->fdlock[i]);
@@ -4279,6 +4673,9 @@ isc_socket_bind(isc_socket_t *sock, isc_sockaddr_t *sockaddr,
  bind_socket:
 #endif
 	if (bind(sock->fd, &sockaddr->type.sa, sockaddr->length) < 0) {
+		inc_stats(sock->manager->stats,
+			  sock->statsindex[STATID_BINDFAIL]);
+
 		UNLOCK(&sock->lock);
 		switch (errno) {
 		case EACCES:
@@ -4423,6 +4820,7 @@ isc_socket_accept(isc_socket_t *sock,
 	 */
 	isc_task_attach(task, &ntask);
 	nsock->references++;
+	nsock->statsindex = sock->statsindex;
 
 	dev->ev_sender = ntask;
 	dev->newsocket = nsock;
@@ -4484,7 +4882,7 @@ isc_socket_connect(isc_socket_t *sock, isc_sockaddr_t *addr,
 	 * Try to do the connect right away, as there can be only one
 	 * outstanding, and it might happen to complete.
 	 */
-	sock->address = *addr;
+	sock->peer_address = *addr;
 	cc = connect(sock->fd, &addr->type.sa, addr->length);
 	if (cc < 0) {
 		/*
@@ -4524,6 +4922,8 @@ isc_socket_connect(isc_socket_t *sock, isc_sockaddr_t *addr,
 		UNEXPECTED_ERROR(__FILE__, __LINE__, "%d/%s", errno, strbuf);
 
 		UNLOCK(&sock->lock);
+		inc_stats(sock->manager->stats,
+			  sock->statsindex[STATID_CONNECTFAIL]);
 		isc_event_free(ISC_EVENT_PTR(&dev));
 		return (ISC_R_UNEXPECTED);
 
@@ -4532,6 +4932,8 @@ isc_socket_connect(isc_socket_t *sock, isc_sockaddr_t *addr,
 		isc_task_send(task, ISC_EVENT_PTR(&dev));
 
 		UNLOCK(&sock->lock);
+		inc_stats(sock->manager->stats,
+			  sock->statsindex[STATID_CONNECTFAIL]);
 		return (ISC_R_SUCCESS);
 	}
 
@@ -4546,6 +4948,10 @@ isc_socket_connect(isc_socket_t *sock, isc_sockaddr_t *addr,
 		isc_task_send(task, ISC_EVENT_PTR(&dev));
 
 		UNLOCK(&sock->lock);
+
+		inc_stats(sock->manager->stats,
+			  sock->statsindex[STATID_CONNECT]);
+
 		return (ISC_R_SUCCESS);
 	}
 
@@ -4644,6 +5050,9 @@ internal_connect(isc_task_t *me, isc_event_t *ev) {
 			return;
 		}
 
+		inc_stats(sock->manager->stats,
+			  sock->statsindex[STATID_CONNECTFAIL]);
+
 		/*
 		 * Translate other errors into ISC_R_* flavors.
 		 */
@@ -4666,7 +5075,7 @@ internal_connect(isc_task_t *me, isc_event_t *ev) {
 #undef ERROR_MATCH
 		default:
 			dev->result = ISC_R_UNEXPECTED;
-			isc_sockaddr_format(&sock->address, peerbuf,
+			isc_sockaddr_format(&sock->peer_address, peerbuf,
 					    sizeof(peerbuf));
 			isc__strerror(errno, strbuf, sizeof(strbuf));
 			UNEXPECTED_ERROR(__FILE__, __LINE__,
@@ -4674,6 +5083,8 @@ internal_connect(isc_task_t *me, isc_event_t *ev) {
 					 peerbuf, strbuf);
 		}
 	} else {
+		inc_stats(sock->manager->stats,
+			  sock->statsindex[STATID_CONNECT]);
 		dev->result = ISC_R_SUCCESS;
 		sock->connected = 1;
 		sock->bound = 1;
@@ -4698,7 +5109,7 @@ isc_socket_getpeername(isc_socket_t *sock, isc_sockaddr_t *addressp) {
 	LOCK(&sock->lock);
 
 	if (sock->connected) {
-		*addressp = sock->address;
+		*addressp = sock->peer_address;
 		result = ISC_R_SUCCESS;
 	} else {
 		result = ISC_R_NOTCONNECTED;
@@ -5002,3 +5413,138 @@ isc__socketmgr_dispatch(isc_socketwait_t *swait) {
 #endif
 }
 #endif /* ISC_PLATFORM_USETHREADS */
+
+void
+isc_socket_setname(isc_socket_t *socket, const char *name, void *tag) {
+
+	/*
+	 * Name 'socket'.
+	 */
+
+	REQUIRE(VALID_SOCKET(socket));
+
+	LOCK(&socket->lock);
+	memset(socket->name, 0, sizeof(socket->name));
+	strncpy(socket->name, name, sizeof(socket->name) - 1);
+	socket->tag = tag;
+	UNLOCK(&socket->lock);
+}
+
+const char *
+isc_socket_getname(isc_socket_t *socket) {
+	return (socket->name);
+}
+
+void *
+isc_socket_gettag(isc_socket_t *socket) {
+	return (socket->tag);
+}
+
+#ifdef HAVE_LIBXML2
+
+static const char *
+_socktype(isc_sockettype_t type)
+{
+	if (type == isc_sockettype_udp)
+		return ("udp");
+	else if (type == isc_sockettype_tcp)
+		return ("tcp");
+	else if (type == isc_sockettype_unix)
+		return ("unix");
+	else if (type == isc_sockettype_fdwatch)
+		return ("fdwatch");
+	else
+		return ("not-initialized");
+}
+
+void
+isc_socketmgr_renderxml(isc_socketmgr_t *mgr, xmlTextWriterPtr writer)
+{
+	isc_socket_t *sock;
+	char peerbuf[ISC_SOCKADDR_FORMATSIZE];
+	isc_sockaddr_t addr;
+	ISC_SOCKADDR_LEN_T len;
+
+	LOCK(&mgr->lock);
+
+#ifndef ISC_PLATFORM_USETHREADS
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "references");
+	xmlTextWriterWriteFormatString(writer, "%d", mgr->refs);
+	xmlTextWriterEndElement(writer);
+#endif
+
+	xmlTextWriterStartElement(writer, ISC_XMLCHAR "sockets");
+	sock = ISC_LIST_HEAD(mgr->socklist);
+	while (sock != NULL) {
+		LOCK(&sock->lock);
+		xmlTextWriterStartElement(writer, ISC_XMLCHAR "socket");
+
+		xmlTextWriterStartElement(writer, ISC_XMLCHAR "id");
+		xmlTextWriterWriteFormatString(writer, "%p", sock);
+		xmlTextWriterEndElement(writer);
+
+		if (sock->name[0] != 0) {
+			xmlTextWriterStartElement(writer, ISC_XMLCHAR "name");
+			xmlTextWriterWriteFormatString(writer, "%s",
+						       sock->name);
+			xmlTextWriterEndElement(writer); /* name */
+		}
+
+		xmlTextWriterStartElement(writer, ISC_XMLCHAR "references");
+		xmlTextWriterWriteFormatString(writer, "%d", sock->references);
+		xmlTextWriterEndElement(writer);
+
+		xmlTextWriterWriteElement(writer, ISC_XMLCHAR "type",
+					  ISC_XMLCHAR _socktype(sock->type));
+
+		if (sock->connected) {
+			isc_sockaddr_format(&sock->peer_address, peerbuf,
+					    sizeof(peerbuf));
+			xmlTextWriterWriteElement(writer,
+						  ISC_XMLCHAR "peer-address",
+						  ISC_XMLCHAR peerbuf);
+		}
+
+		len = sizeof(addr);
+		if (getsockname(sock->fd, &addr.type.sa, (void *)&len) == 0) {
+			isc_sockaddr_format(&addr, peerbuf, sizeof(peerbuf));
+			xmlTextWriterWriteElement(writer,
+						  ISC_XMLCHAR "local-address",
+						  ISC_XMLCHAR peerbuf);
+		}
+
+		xmlTextWriterStartElement(writer, ISC_XMLCHAR "states");
+		if (sock->pending_recv)
+			xmlTextWriterWriteElement(writer, ISC_XMLCHAR "state",
+						ISC_XMLCHAR "pending-receive");
+		if (sock->pending_send)
+			xmlTextWriterWriteElement(writer, ISC_XMLCHAR "state",
+						  ISC_XMLCHAR "pending-send");
+		if (sock->pending_accept)
+			xmlTextWriterWriteElement(writer, ISC_XMLCHAR "state",
+						 ISC_XMLCHAR "pending_accept");
+		if (sock->listener)
+			xmlTextWriterWriteElement(writer, ISC_XMLCHAR "state",
+						  ISC_XMLCHAR "listener");
+		if (sock->connected)
+			xmlTextWriterWriteElement(writer, ISC_XMLCHAR "state",
+						  ISC_XMLCHAR "connected");
+		if (sock->connecting)
+			xmlTextWriterWriteElement(writer, ISC_XMLCHAR "state",
+						  ISC_XMLCHAR "connecting");
+		if (sock->bound)
+			xmlTextWriterWriteElement(writer, ISC_XMLCHAR "state",
+						  ISC_XMLCHAR "bound");
+
+		xmlTextWriterEndElement(writer); /* states */
+
+		xmlTextWriterEndElement(writer); /* socket */
+
+		UNLOCK(&sock->lock);
+		sock = ISC_LIST_NEXT(sock, link);
+	}
+	xmlTextWriterEndElement(writer); /* sockets */
+
+	UNLOCK(&mgr->lock);
+}
+#endif /* HAVE_LIBXML2 */
diff --git a/contrib/bind9/lib/isc/unix/socket_p.h b/contrib/bind9/lib/isc/unix/socket_p.h
index b7da860..fc044e5 100644
--- a/contrib/bind9/lib/isc/unix/socket_p.h
+++ b/contrib/bind9/lib/isc/unix/socket_p.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: socket_p.h,v 1.7.18.4 2008/06/24 23:45:55 tbox Exp $ */
+/* $Id: socket_p.h,v 1.13 2008/06/23 23:47:11 tbox Exp $ */
 
 #ifndef ISC_SOCKET_P_H
 #define ISC_SOCKET_P_H
diff --git a/contrib/bind9/lib/isc/unix/stdio.c b/contrib/bind9/lib/isc/unix/stdio.c
index 64db925..4e294db 100644
--- a/contrib/bind9/lib/isc/unix/stdio.c
+++ b/contrib/bind9/lib/isc/unix/stdio.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: stdio.c,v 1.6 2004/03/05 05:11:47 marka Exp $ */
+/* $Id: stdio.c,v 1.8 2007/06/19 23:47:18 tbox Exp $ */
 
 #include <config.h>
 
diff --git a/contrib/bind9/lib/isc/unix/stdtime.c b/contrib/bind9/lib/isc/unix/stdtime.c
index 3f240b7..c5d0c47 100644
--- a/contrib/bind9/lib/isc/unix/stdtime.c
+++ b/contrib/bind9/lib/isc/unix/stdtime.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: stdtime.c,v 1.14.18.3 2005/06/08 02:07:57 marka Exp $ */
+/* $Id: stdtime.c,v 1.19 2007/06/19 23:47:18 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/unix/strerror.c b/contrib/bind9/lib/isc/unix/strerror.c
index 18cc367..349c8bd 100644
--- a/contrib/bind9/lib/isc/unix/strerror.c
+++ b/contrib/bind9/lib/isc/unix/strerror.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: strerror.c,v 1.4.18.2 2005/04/29 00:17:08 marka Exp $ */
+/* $Id: strerror.c,v 1.8.332.2 2009/02/16 23:47:15 tbox Exp $ */
 
 /*! \file */
 
@@ -47,7 +47,7 @@ void
 isc__strerror(int num, char *buf, size_t size) {
 #ifdef HAVE_STRERROR
 	char *msg;
-	unsigned int unum = num;
+	unsigned int unum = (unsigned int)num;
 	static isc_once_t once = ISC_ONCE_INIT;
 
 	REQUIRE(buf != NULL);
@@ -62,7 +62,7 @@ isc__strerror(int num, char *buf, size_t size) {
 		snprintf(buf, size, "Unknown error: %u", unum);
 	UNLOCK(&isc_strerror_lock);
 #else
-	unsigned int unum = num;
+	unsigned int unum = (unsigned int)num;
 
 	REQUIRE(buf != NULL);
 
diff --git a/contrib/bind9/lib/isc/unix/syslog.c b/contrib/bind9/lib/isc/unix/syslog.c
index ae67399..997508e 100644
--- a/contrib/bind9/lib/isc/unix/syslog.c
+++ b/contrib/bind9/lib/isc/unix/syslog.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: syslog.c,v 1.3.18.4 2007/09/13 23:46:26 tbox Exp $ */
+/* $Id: syslog.c,v 1.8 2007/09/13 04:45:18 each Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/unix/time.c b/contrib/bind9/lib/isc/unix/time.c
index facc12b..59428d3 100644
--- a/contrib/bind9/lib/isc/unix/time.c
+++ b/contrib/bind9/lib/isc/unix/time.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001, 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: time.c,v 1.47.18.4 2008/02/18 23:46:01 tbox Exp $ */
+/* $Id: time.c,v 1.56 2008/02/15 23:46:51 tbox Exp $ */
 
 /*! \file */
 
@@ -412,3 +412,27 @@ isc_time_formattimestamp(const isc_time_t *t, char *buf, unsigned int len) {
 	else
 		snprintf(buf, len, "99-Bad-9999 99:99:99.999");
 }
+
+void
+isc_time_formathttptimestamp(const isc_time_t *t, char *buf, unsigned int len) {
+	time_t now;
+	unsigned int flen;
+
+	REQUIRE(len > 0);
+
+	now = (time_t)t->seconds;
+	flen = strftime(buf, len, "%a, %d %b %Y %H:%M:%S GMT", gmtime(&now));
+	INSIST(flen < len);
+}
+
+void
+isc_time_formatISO8601(const isc_time_t *t, char *buf, unsigned int len) {
+	time_t now;
+	unsigned int flen;
+
+	REQUIRE(len > 0);
+
+	now = (time_t)t->seconds;
+	flen = strftime(buf, len, "%Y-%m-%dT%H:%M:%SZ", gmtime(&now));
+	INSIST(flen < len);
+}
diff --git a/contrib/bind9/lib/isc/version.c b/contrib/bind9/lib/isc/version.c
index 6d3b3d2..bfe4d6d 100644
--- a/contrib/bind9/lib/isc/version.c
+++ b/contrib/bind9/lib/isc/version.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: version.c,v 1.11.18.2 2005/04/29 00:16:51 marka Exp $ */
+/* $Id: version.c,v 1.15 2007/06/19 23:47:17 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isc/x86_32/Makefile.in b/contrib/bind9/lib/isc/x86_32/Makefile.in
index c8e77e4..324db07 100644
--- a/contrib/bind9/lib/isc/x86_32/Makefile.in
+++ b/contrib/bind9/lib/isc/x86_32/Makefile.in
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.2.2.1 2007/09/14 04:26:38 marka Exp $
+# $Id: Makefile.in,v 1.2 2007/09/14 04:09:59 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/x86_32/include/Makefile.in b/contrib/bind9/lib/isc/x86_32/include/Makefile.in
index b68a765..f1d8bdd 100644
--- a/contrib/bind9/lib/isc/x86_32/include/Makefile.in
+++ b/contrib/bind9/lib/isc/x86_32/include/Makefile.in
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.2.2.1 2007/09/14 04:26:39 marka Exp $
+# $Id: Makefile.in,v 1.2 2007/09/14 04:09:59 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/x86_32/include/isc/Makefile.in b/contrib/bind9/lib/isc/x86_32/include/isc/Makefile.in
index 4ce057a..5f116ca 100644
--- a/contrib/bind9/lib/isc/x86_32/include/isc/Makefile.in
+++ b/contrib/bind9/lib/isc/x86_32/include/isc/Makefile.in
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.2.2.1 2007/09/14 04:26:39 marka Exp $
+# $Id: Makefile.in,v 1.2 2007/09/14 04:09:59 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/x86_32/include/isc/atomic.h b/contrib/bind9/lib/isc/x86_32/include/isc/atomic.h
index f3136d9..bf2148c 100644
--- a/contrib/bind9/lib/isc/x86_32/include/isc/atomic.h
+++ b/contrib/bind9/lib/isc/x86_32/include/isc/atomic.h
@@ -1,7 +1,7 @@
 /*
- * Copyright (C) 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: atomic.h,v 1.2.2.3 2005/07/27 04:23:33 marka Exp $ */
+/* $Id: atomic.h,v 1.10 2008/01/24 23:47:00 tbox Exp $ */
 
 #ifndef ISC_ATOMIC_H
 #define ISC_ATOMIC_H 1
@@ -27,7 +27,7 @@
  * This routine atomically increments the value stored in 'p' by 'val', and
  * returns the previous value.
  */
-static inline isc_int32_t
+static __inline__ isc_int32_t
 isc_atomic_xadd(isc_int32_t *p, isc_int32_t val) {
 	isc_int32_t prev = val;
 
@@ -43,10 +43,28 @@ isc_atomic_xadd(isc_int32_t *p, isc_int32_t val) {
 	return (prev);
 }
 
+#ifdef ISC_PLATFORM_HAVEXADDQ
+static __inline__ isc_int64_t
+isc_atomic_xaddq(isc_int64_t *p, isc_int64_t val) {
+	isc_int64_t prev = val;
+
+	__asm__ volatile(
+#ifdef ISC_PLATFORM_USETHREADS
+	    "lock;"
+#endif
+	    "xaddq %0, %1"
+	    :"=q"(prev)
+	    :"m"(*p), "0"(prev)
+	    :"memory", "cc");
+
+	return (prev);
+}
+#endif /* ISC_PLATFORM_HAVEXADDQ */
+
 /*
  * This routine atomically stores the value 'val' in 'p'.
  */
-static inline void
+static __inline__ void
 isc_atomic_store(isc_int32_t *p, isc_int32_t val) {
 	__asm__ volatile(
 #ifdef ISC_PLATFORM_USETHREADS
@@ -54,7 +72,7 @@ isc_atomic_store(isc_int32_t *p, isc_int32_t val) {
 		 * xchg should automatically lock memory, but we add it
 		 * explicitly just in case (it at least doesn't harm)
 		 */
-		"lock;"		
+		"lock;"
 #endif
 
 		"xchgl %1, %0"
@@ -68,7 +86,7 @@ isc_atomic_store(isc_int32_t *p, isc_int32_t val) {
  * original value is equal to 'cmpval'.  The original value is returned in any
  * case.
  */
-static inline isc_int32_t
+static __inline__ isc_int32_t
 isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, isc_int32_t val) {
 	__asm__ volatile(
 #ifdef ISC_PLATFORM_USETHREADS
diff --git a/contrib/bind9/lib/isc/x86_64/Makefile.in b/contrib/bind9/lib/isc/x86_64/Makefile.in
index de577a9..324db07 100644
--- a/contrib/bind9/lib/isc/x86_64/Makefile.in
+++ b/contrib/bind9/lib/isc/x86_64/Makefile.in
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.2.2.1 2007/09/14 04:26:39 marka Exp $
+# $Id: Makefile.in,v 1.2 2007/09/14 04:09:59 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/x86_64/include/Makefile.in b/contrib/bind9/lib/isc/x86_64/include/Makefile.in
index b68a765..f1d8bdd 100644
--- a/contrib/bind9/lib/isc/x86_64/include/Makefile.in
+++ b/contrib/bind9/lib/isc/x86_64/include/Makefile.in
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.2.2.1 2007/09/14 04:26:39 marka Exp $
+# $Id: Makefile.in,v 1.2 2007/09/14 04:09:59 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/x86_64/include/isc/Makefile.in b/contrib/bind9/lib/isc/x86_64/include/isc/Makefile.in
index 4ce057a..f33ae99 100644
--- a/contrib/bind9/lib/isc/x86_64/include/isc/Makefile.in
+++ b/contrib/bind9/lib/isc/x86_64/include/isc/Makefile.in
@@ -12,7 +12,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: Makefile.in,v 1.2.2.1 2007/09/14 04:26:39 marka Exp $
+# $Id: Makefile.in,v 1.2 2007/09/14 04:10:00 marka Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isc/x86_64/include/isc/atomic.h b/contrib/bind9/lib/isc/x86_64/include/isc/atomic.h
index 0752d8f..f57bd2a 100644
--- a/contrib/bind9/lib/isc/x86_64/include/isc/atomic.h
+++ b/contrib/bind9/lib/isc/x86_64/include/isc/atomic.h
@@ -1,7 +1,7 @@
 /*
- * Copyright (C) 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -14,7 +14,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: atomic.h,v 1.2.20.1 2005/09/02 13:27:12 marka Exp $ */
+/* $Id: atomic.h,v 1.6 2008/01/24 23:47:00 tbox Exp $ */
 
 #ifndef ISC_ATOMIC_H
 #define ISC_ATOMIC_H 1
@@ -49,14 +49,31 @@ isc_atomic_xadd(isc_int32_t *p, isc_int32_t val) {
 		"lock;"
 #endif
 		"xadd %eax, (%rdx)\n"
+		/*
+		 * XXX: assume %eax will be used as the return value.
+		 */
+		);
+}
 
+#ifdef ISC_PLATFORM_HAVEXADDQ
+static isc_int64_t
+isc_atomic_xaddq(isc_int64_t *p, isc_int64_t val) {
+	UNUSED(p);
+	UNUSED(val);
+
+	__asm (
+		"movq %rdi, %rdx\n"
+		"movq %rsi, %rax\n"
+#ifdef ISC_PLATFORM_USETHREADS
+		"lock;"
+#endif
+		"xaddq %rax, (%rdx)\n"
 		/*
-		 * set the return value directly in the register so that we
-		 * can avoid guessing the correct position in the stack for a
-		 * local variable.
+		 * XXX: assume %rax will be used as the return value.
 		 */
 		);
 }
+#endif
 
 static void
 isc_atomic_store(isc_int32_t *p, isc_int32_t val) {
@@ -70,6 +87,9 @@ isc_atomic_store(isc_int32_t *p, isc_int32_t val) {
 		"lock;"
 #endif
 		"xchgl (%rax), %edx\n"
+		/*
+		 * XXX: assume %rax will be used as the return value.
+		 */
 		);
 }
 
@@ -89,7 +109,7 @@ isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, isc_int32_t val) {
 #endif
 		/*
 		 * If (%rdi) == %eax then (%rdi) := %edx.
-		 % %eax is set to old (%ecx), which will be the return value.
+		 * %eax is set to old (%ecx), which will be the return value.
 		 */
 		"cmpxchgl %ecx, (%rdx)"
 		);
diff --git a/contrib/bind9/lib/isccc/Makefile.in b/contrib/bind9/lib/isccc/Makefile.in
index cb41681..5dcc225 100644
--- a/contrib/bind9/lib/isccc/Makefile.in
+++ b/contrib/bind9/lib/isccc/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2001, 2003  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.6.18.1 2004/07/20 07:03:29 marka Exp $
+# $Id: Makefile.in,v 1.9 2007/06/19 23:47:21 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isccc/alist.c b/contrib/bind9/lib/isccc/alist.c
index a8335c8..4f1743e 100644
--- a/contrib/bind9/lib/isccc/alist.c
+++ b/contrib/bind9/lib/isccc/alist.c
@@ -1,9 +1,22 @@
 /*
- * Portions Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 2001  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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 NOMINUM 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.
+ *
  * Portions Copyright (C) 2001  Nominum, Inc.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -16,7 +29,7 @@
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: alist.c,v 1.3.18.2 2005/04/29 00:17:11 marka Exp $ */
+/* $Id: alist.c,v 1.8 2007/08/28 07:20:43 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isccc/api b/contrib/bind9/lib/isccc/api
index cd8c055..8459d42 100644
--- a/contrib/bind9/lib/isccc/api
+++ b/contrib/bind9/lib/isccc/api
@@ -1,3 +1,3 @@
-LIBINTERFACE = 30
-LIBREVISION = 1
+LIBINTERFACE = 50
+LIBREVISION = 0
 LIBAGE = 0
diff --git a/contrib/bind9/lib/isccc/base64.c b/contrib/bind9/lib/isccc/base64.c
index e723cf2..78b34ed 100644
--- a/contrib/bind9/lib/isccc/base64.c
+++ b/contrib/bind9/lib/isccc/base64.c
@@ -1,9 +1,22 @@
 /*
- * Portions Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 2001  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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 NOMINUM 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.
+ *
  * Portions Copyright (C) 2001  Nominum, Inc.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -16,7 +29,7 @@
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: base64.c,v 1.3.18.2 2005/04/29 00:17:11 marka Exp $ */
+/* $Id: base64.c,v 1.8 2007/08/28 07:20:43 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isccc/cc.c b/contrib/bind9/lib/isccc/cc.c
index e65349e..cfa1db6 100644
--- a/contrib/bind9/lib/isccc/cc.c
+++ b/contrib/bind9/lib/isccc/cc.c
@@ -1,9 +1,22 @@
 /*
- * Portions Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 2001-2003  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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 NOMINUM 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.
+ *
  * Portions Copyright (C) 2001  Nominum, Inc.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -16,7 +29,7 @@
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: cc.c,v 1.10.18.5 2006/12/07 23:57:58 marka Exp $ */
+/* $Id: cc.c,v 1.18 2007/08/28 07:20:43 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isccc/ccmsg.c b/contrib/bind9/lib/isccc/ccmsg.c
index d624c9b..298fc22 100644
--- a/contrib/bind9/lib/isccc/ccmsg.c
+++ b/contrib/bind9/lib/isccc/ccmsg.c
@@ -1,9 +1,22 @@
 /*
- * Portions Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 2001  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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 NOMINUM 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.
+ *
  * Portions Copyright (C) 2001  Nominum, Inc.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -16,7 +29,7 @@
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ccmsg.c,v 1.5.18.2 2005/04/29 00:17:11 marka Exp $ */
+/* $Id: ccmsg.c,v 1.10 2007/08/28 07:20:43 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isccc/include/Makefile.in b/contrib/bind9/lib/isccc/include/Makefile.in
index f3d46ab..9f727c3 100644
--- a/contrib/bind9/lib/isccc/include/Makefile.in
+++ b/contrib/bind9/lib/isccc/include/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.3 2004/03/05 05:12:12 marka Exp $
+# $Id: Makefile.in,v 1.5 2007/06/19 23:47:22 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isccc/include/isccc/Makefile.in b/contrib/bind9/lib/isccc/include/isccc/Makefile.in
index b7b1d55..ae5bec7 100644
--- a/contrib/bind9/lib/isccc/include/isccc/Makefile.in
+++ b/contrib/bind9/lib/isccc/include/isccc/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.5 2004/03/05 05:12:15 marka Exp $
+# $Id: Makefile.in,v 1.7 2007/06/19 23:47:22 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isccc/include/isccc/alist.h b/contrib/bind9/lib/isccc/include/isccc/alist.h
index 16b5ba2..29147a6 100644
--- a/contrib/bind9/lib/isccc/include/isccc/alist.h
+++ b/contrib/bind9/lib/isccc/include/isccc/alist.h
@@ -1,9 +1,22 @@
 /*
- * Portions Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 2001  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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 NOMINUM 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.
+ *
  * Portions Copyright (C) 2001  Nominum, Inc.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -16,12 +29,12 @@
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: alist.h,v 1.3.18.2 2005/04/29 00:17:12 marka Exp $ */
+/* $Id: alist.h,v 1.10 2007/08/28 07:20:43 tbox Exp $ */
 
 #ifndef ISCCC_ALIST_H
 #define ISCCC_ALIST_H 1
 
-/*! \file */
+/*! \file isccc/alist.h */
 
 #include <stdio.h>
 
diff --git a/contrib/bind9/lib/isccc/include/isccc/base64.h b/contrib/bind9/lib/isccc/include/isccc/base64.h
index dd70e8d..795b044 100644
--- a/contrib/bind9/lib/isccc/include/isccc/base64.h
+++ b/contrib/bind9/lib/isccc/include/isccc/base64.h
@@ -1,9 +1,22 @@
 /*
- * Portions Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 2001  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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 NOMINUM 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.
+ *
  * Portions Copyright (C) 2001  Nominum, Inc.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -16,12 +29,12 @@
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: base64.h,v 1.3.18.2 2005/04/29 00:17:13 marka Exp $ */
+/* $Id: base64.h,v 1.10 2007/08/28 07:20:43 tbox Exp $ */
 
 #ifndef ISCCC_BASE64_H
 #define ISCCC_BASE64_H 1
 
-/*! \file */
+/*! \file isccc/base64.h */
 
 #include <isc/lang.h>
 #include <isccc/types.h>
diff --git a/contrib/bind9/lib/isccc/include/isccc/cc.h b/contrib/bind9/lib/isccc/include/isccc/cc.h
index 2e291ea..79393be 100644
--- a/contrib/bind9/lib/isccc/include/isccc/cc.h
+++ b/contrib/bind9/lib/isccc/include/isccc/cc.h
@@ -1,9 +1,22 @@
 /*
- * Portions Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 2001  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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 NOMINUM 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.
+ *
  * Portions Copyright (C) 2001  Nominum, Inc.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -16,12 +29,12 @@
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: cc.h,v 1.4.18.2 2005/04/29 00:17:13 marka Exp $ */
+/* $Id: cc.h,v 1.11 2007/08/28 07:20:43 tbox Exp $ */
 
 #ifndef ISCCC_CC_H
 #define ISCCC_CC_H 1
 
-/*! \file */
+/*! \file isccc/cc.h */
 
 #include <isc/lang.h>
 #include <isccc/types.h>
diff --git a/contrib/bind9/lib/isccc/include/isccc/ccmsg.h b/contrib/bind9/lib/isccc/include/isccc/ccmsg.h
index 372047d..e25aa51 100644
--- a/contrib/bind9/lib/isccc/include/isccc/ccmsg.h
+++ b/contrib/bind9/lib/isccc/include/isccc/ccmsg.h
@@ -1,9 +1,22 @@
 /*
- * Portions Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 2001  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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 NOMINUM 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.
+ *
  * Portions Copyright (C) 2001  Nominum, Inc.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -16,12 +29,12 @@
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ccmsg.h,v 1.4.18.2 2005/04/29 00:17:13 marka Exp $ */
+/* $Id: ccmsg.h,v 1.11 2007/08/28 07:20:43 tbox Exp $ */
 
 #ifndef ISCCC_CCMSG_H
 #define ISCCC_CCMSG_H 1
 
-/*! \file */
+/*! \file isccc/ccmsg.h */
 
 #include <isc/buffer.h>
 #include <isc/lang.h>
diff --git a/contrib/bind9/lib/isccc/include/isccc/events.h b/contrib/bind9/lib/isccc/include/isccc/events.h
index 0ac365f..a3e1470 100644
--- a/contrib/bind9/lib/isccc/include/isccc/events.h
+++ b/contrib/bind9/lib/isccc/include/isccc/events.h
@@ -1,9 +1,22 @@
 /*
- * Portions Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 2001  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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 NOMINUM 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.
+ *
  * Portions Copyright (C) 2001  Nominum, Inc.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -16,12 +29,12 @@
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: events.h,v 1.3.18.2 2005/04/29 00:17:13 marka Exp $ */
+/* $Id: events.h,v 1.10 2007/08/28 07:20:43 tbox Exp $ */
 
 #ifndef ISCCC_EVENTS_H
 #define ISCCC_EVENTS_H 1
 
-/*! \file */
+/*! \file isccc/events.h */
 
 #include <isc/eventclass.h>
 
diff --git a/contrib/bind9/lib/isccc/include/isccc/lib.h b/contrib/bind9/lib/isccc/include/isccc/lib.h
index 247267c..de74666 100644
--- a/contrib/bind9/lib/isccc/include/isccc/lib.h
+++ b/contrib/bind9/lib/isccc/include/isccc/lib.h
@@ -1,9 +1,22 @@
 /*
- * Portions Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 2001  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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 NOMINUM 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.
+ *
  * Portions Copyright (C) 2001  Nominum, Inc.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -16,12 +29,12 @@
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lib.h,v 1.4.18.2 2005/04/29 00:17:13 marka Exp $ */
+/* $Id: lib.h,v 1.11 2007/08/28 07:20:43 tbox Exp $ */
 
 #ifndef ISCCC_LIB_H
 #define ISCCC_LIB_H 1
 
-/*! \file */
+/*! \file isccc/lib.h */
 
 #include <isc/types.h>
 #include <isc/lang.h>
diff --git a/contrib/bind9/lib/isccc/include/isccc/result.h b/contrib/bind9/lib/isccc/include/isccc/result.h
index 6fbc298..2d54969 100644
--- a/contrib/bind9/lib/isccc/include/isccc/result.h
+++ b/contrib/bind9/lib/isccc/include/isccc/result.h
@@ -1,9 +1,22 @@
 /*
- * Portions Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 2001, 2003  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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 NOMINUM 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.
+ *
  * Portions Copyright (C) 2001  Nominum, Inc.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -16,12 +29,12 @@
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: result.h,v 1.5.18.2 2005/04/29 00:17:14 marka Exp $ */
+/* $Id: result.h,v 1.12 2007/08/28 07:20:43 tbox Exp $ */
 
 #ifndef ISCCC_RESULT_H
 #define ISCCC_RESULT_H 1
 
-/*! \file */
+/*! \file isccc/result.h */
 
 #include <isc/lang.h>
 #include <isc/resultclass.h>
diff --git a/contrib/bind9/lib/isccc/include/isccc/sexpr.h b/contrib/bind9/lib/isccc/include/isccc/sexpr.h
index cb1d297..6112631 100644
--- a/contrib/bind9/lib/isccc/include/isccc/sexpr.h
+++ b/contrib/bind9/lib/isccc/include/isccc/sexpr.h
@@ -1,9 +1,22 @@
 /*
- * Portions Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 2001  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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 NOMINUM 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.
+ *
  * Portions Copyright (C) 2001  Nominum, Inc.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -16,12 +29,12 @@
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: sexpr.h,v 1.4.18.2 2005/04/29 00:17:14 marka Exp $ */
+/* $Id: sexpr.h,v 1.11 2007/08/28 07:20:43 tbox Exp $ */
 
 #ifndef ISCCC_SEXPR_H
 #define ISCCC_SEXPR_H 1
 
-/*! \file */
+/*! \file isccc/sexpr.h */
 
 #include <stdio.h>
 
diff --git a/contrib/bind9/lib/isccc/include/isccc/symtab.h b/contrib/bind9/lib/isccc/include/isccc/symtab.h
index 5b11a01..77a188a 100644
--- a/contrib/bind9/lib/isccc/include/isccc/symtab.h
+++ b/contrib/bind9/lib/isccc/include/isccc/symtab.h
@@ -1,9 +1,22 @@
 /*
- * Portions Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 2001  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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 NOMINUM 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.
+ *
  * Portions Copyright (C) 2001  Nominum, Inc.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -16,7 +29,7 @@
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: symtab.h,v 1.3.18.2 2005/04/29 00:17:14 marka Exp $ */
+/* $Id: symtab.h,v 1.10 2007/08/28 07:20:43 tbox Exp $ */
 
 #ifndef ISCCC_SYMTAB_H
 #define ISCCC_SYMTAB_H 1
@@ -25,7 +38,7 @@
  ***** Module Info
  *****/
 
-/*! \file 
+/*! \file isccc/symtab.h
  * \brief
  * Provides a simple memory-based symbol table.
  *
diff --git a/contrib/bind9/lib/isccc/include/isccc/symtype.h b/contrib/bind9/lib/isccc/include/isccc/symtype.h
index e72ae92..c8e6868 100644
--- a/contrib/bind9/lib/isccc/include/isccc/symtype.h
+++ b/contrib/bind9/lib/isccc/include/isccc/symtype.h
@@ -1,9 +1,22 @@
 /*
- * Portions Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 2001  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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 NOMINUM 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.
+ *
  * Portions Copyright (C) 2001  Nominum, Inc.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -16,12 +29,12 @@
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: symtype.h,v 1.3.18.2 2005/04/29 00:17:14 marka Exp $ */
+/* $Id: symtype.h,v 1.10 2007/08/28 07:20:43 tbox Exp $ */
 
 #ifndef ISCCC_SYMTYPE_H
 #define ISCCC_SYMTYPE_H 1
 
-/*! \file */
+/*! \file isccc/symtype.h */
 
 #define ISCCC_SYMTYPE_ZONESTATS			0x0001
 #define ISCCC_SYMTYPE_CCDUP			0x0002
diff --git a/contrib/bind9/lib/isccc/include/isccc/types.h b/contrib/bind9/lib/isccc/include/isccc/types.h
index f46d257..fd5c9f3 100644
--- a/contrib/bind9/lib/isccc/include/isccc/types.h
+++ b/contrib/bind9/lib/isccc/include/isccc/types.h
@@ -1,9 +1,22 @@
 /*
- * Portions Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 2001  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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 NOMINUM 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.
+ *
  * Portions Copyright (C) 2001  Nominum, Inc.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -16,12 +29,12 @@
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: types.h,v 1.3.18.2 2005/04/29 00:17:14 marka Exp $ */
+/* $Id: types.h,v 1.10 2007/08/28 07:20:43 tbox Exp $ */
 
 #ifndef ISCCC_TYPES_H
 #define ISCCC_TYPES_H 1
 
-/*! \file */
+/*! \file isccc/types.h */
 
 #include <isc/boolean.h>
 #include <isc/int.h>
diff --git a/contrib/bind9/lib/isccc/include/isccc/util.h b/contrib/bind9/lib/isccc/include/isccc/util.h
index 7662483..2e36b6e 100644
--- a/contrib/bind9/lib/isccc/include/isccc/util.h
+++ b/contrib/bind9/lib/isccc/include/isccc/util.h
@@ -1,9 +1,22 @@
 /*
- * Portions Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 2001  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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 NOMINUM 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.
+ *
  * Portions Copyright (C) 2001  Nominum, Inc.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -16,14 +29,14 @@
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: util.h,v 1.4.18.2 2005/04/29 00:17:14 marka Exp $ */
+/* $Id: util.h,v 1.11 2007/08/28 07:20:43 tbox Exp $ */
 
 #ifndef ISCCC_UTIL_H
 #define ISCCC_UTIL_H 1
 
 #include <isc/util.h>
 
-/*! \file
+/*! \file isccc/util.h
  * \brief
  * Macros for dealing with unaligned numbers.
  *
diff --git a/contrib/bind9/lib/isccc/include/isccc/version.h b/contrib/bind9/lib/isccc/include/isccc/version.h
index b82ed8b..869316c 100644
--- a/contrib/bind9/lib/isccc/include/isccc/version.h
+++ b/contrib/bind9/lib/isccc/include/isccc/version.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,9 +15,9 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: version.h,v 1.3.18.2 2005/04/29 00:17:15 marka Exp $ */
+/* $Id: version.h,v 1.9 2007/06/19 23:47:22 tbox Exp $ */
 
-/*! \file */
+/*! \file isccc/version.h */
 
 #include <isc/platform.h>
 
diff --git a/contrib/bind9/lib/isccc/lib.c b/contrib/bind9/lib/isccc/lib.c
index bef2d9a..17170f5 100644
--- a/contrib/bind9/lib/isccc/lib.c
+++ b/contrib/bind9/lib/isccc/lib.c
@@ -1,9 +1,22 @@
 /*
- * Portions Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 2001  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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 NOMINUM 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.
+ *
  * Portions Copyright (C) 2001  Nominum, Inc.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -16,7 +29,7 @@
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lib.c,v 1.4.18.2 2005/04/29 00:17:12 marka Exp $ */
+/* $Id: lib.c,v 1.9 2007/08/28 07:20:43 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isccc/result.c b/contrib/bind9/lib/isccc/result.c
index 974e51b..cbedc16 100644
--- a/contrib/bind9/lib/isccc/result.c
+++ b/contrib/bind9/lib/isccc/result.c
@@ -1,9 +1,22 @@
 /*
- * Portions Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 2001, 2003  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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 NOMINUM 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.
+ *
  * Portions Copyright (C) 2001  Nominum, Inc.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -16,7 +29,7 @@
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: result.c,v 1.5.18.2 2005/04/29 00:17:12 marka Exp $ */
+/* $Id: result.c,v 1.10 2007/08/28 07:20:43 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isccc/sexpr.c b/contrib/bind9/lib/isccc/sexpr.c
index 573a63c..e96536d 100644
--- a/contrib/bind9/lib/isccc/sexpr.c
+++ b/contrib/bind9/lib/isccc/sexpr.c
@@ -1,9 +1,22 @@
 /*
- * Portions Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 2001  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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 NOMINUM 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.
+ *
  * Portions Copyright (C) 2001  Nominum, Inc.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -16,7 +29,7 @@
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: sexpr.c,v 1.4.18.2 2005/04/29 00:17:12 marka Exp $ */
+/* $Id: sexpr.c,v 1.9 2007/08/28 07:20:43 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isccc/symtab.c b/contrib/bind9/lib/isccc/symtab.c
index 7ec6d55..d7ae687 100644
--- a/contrib/bind9/lib/isccc/symtab.c
+++ b/contrib/bind9/lib/isccc/symtab.c
@@ -1,6 +1,19 @@
 /*
  * Portions Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 2001  Internet Software Consortium.
+ *
+ * Permission to use, copy, modify, and/or 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 NOMINUM 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.
+ *
  * Portions Copyright (C) 2001  Nominum, Inc.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -16,7 +29,7 @@
  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: symtab.c,v 1.5.18.4 2007/09/13 23:46:26 tbox Exp $ */
+/* $Id: symtab.c,v 1.11 2007/09/13 04:45:18 each Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isccc/version.c b/contrib/bind9/lib/isccc/version.c
index 0d65dcb..c9d9124 100644
--- a/contrib/bind9/lib/isccc/version.c
+++ b/contrib/bind9/lib/isccc/version.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: version.c,v 1.3.18.2 2005/04/29 00:17:12 marka Exp $ */
+/* $Id: version.c,v 1.7 2007/06/19 23:47:22 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/isccfg/Makefile.in b/contrib/bind9/lib/isccfg/Makefile.in
index 7d19123..6dcacdd 100644
--- a/contrib/bind9/lib/isccfg/Makefile.in
+++ b/contrib/bind9/lib/isccfg/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2001-2003  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.18.4 2005/09/05 00:18:30 marka Exp $
+# $Id: Makefile.in,v 1.18 2007/06/19 23:47:22 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isccfg/aclconf.c b/contrib/bind9/lib/isccfg/aclconf.c
index d7b41ce..ad3d58e 100644
--- a/contrib/bind9/lib/isccfg/aclconf.c
+++ b/contrib/bind9/lib/isccfg/aclconf.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: aclconf.c,v 1.2.2.6 2006/03/02 00:37:22 marka Exp $ */
+/* $Id: aclconf.c,v 1.22.34.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #include <config.h>
 
@@ -27,10 +27,11 @@
 #include <isccfg/aclconf.h>
 
 #include <dns/acl.h>
+#include <dns/iptable.h>
 #include <dns/fixedname.h>
 #include <dns/log.h>
 
-#define LOOP_MAGIC ISC_MAGIC('L','O','O','P') 
+#define LOOP_MAGIC ISC_MAGIC('L','O','O','P')
 
 void
 cfg_aclconfctx_init(cfg_aclconfctx_t *ctx) {
@@ -39,7 +40,8 @@ cfg_aclconfctx_init(cfg_aclconfctx_t *ctx) {
 
 void
 cfg_aclconfctx_destroy(cfg_aclconfctx_t *ctx) {
-     	dns_acl_t *dacl, *next;
+	dns_acl_t *dacl, *next;
+
 	for (dacl = ISC_LIST_HEAD(ctx->named_acl_cache);
 	     dacl != NULL;
 	     dacl = next)
@@ -57,7 +59,7 @@ get_acl_def(const cfg_obj_t *cctx, const char *name, const cfg_obj_t **ret) {
 	isc_result_t result;
 	const cfg_obj_t *acls = NULL;
 	const cfg_listelt_t *elt;
-	
+
 	result = cfg_map_get(cctx, "acl", &acls);
 	if (result != ISC_R_SUCCESS)
 		return (result);
@@ -67,7 +69,9 @@ get_acl_def(const cfg_obj_t *cctx, const char *name, const cfg_obj_t **ret) {
 		const cfg_obj_t *acl = cfg_listelt_value(elt);
 		const char *aclname = cfg_obj_asstring(cfg_tuple_get(acl, "name"));
 		if (strcasecmp(aclname, name) == 0) {
-			*ret = cfg_tuple_get(acl, "value");
+			if (ret != NULL) {
+				*ret = cfg_tuple_get(acl, "value");
+			}
 			return (ISC_R_SUCCESS);
 		}
 	}
@@ -77,7 +81,8 @@ get_acl_def(const cfg_obj_t *cctx, const char *name, const cfg_obj_t **ret) {
 static isc_result_t
 convert_named_acl(const cfg_obj_t *nameobj, const cfg_obj_t *cctx,
 		  isc_log_t *lctx, cfg_aclconfctx_t *ctx,
-		  isc_mem_t *mctx, dns_acl_t **target)
+		  isc_mem_t *mctx, unsigned int nest_level,
+		  dns_acl_t **target)
 {
 	isc_result_t result;
 	const cfg_obj_t *cacl = NULL;
@@ -115,7 +120,8 @@ convert_named_acl(const cfg_obj_t *nameobj, const cfg_obj_t *cctx,
 	DE_CONST(aclname, loop.name);
 	loop.magic = LOOP_MAGIC;
 	ISC_LIST_APPEND(ctx->named_acl_cache, &loop, nextincache);
-	result = cfg_acl_fromconfig(cacl, cctx, lctx, ctx, mctx, &dacl);
+	result = cfg_acl_fromconfig(cacl, cctx, lctx, ctx, mctx,
+				    nest_level, &dacl);
 	ISC_LIST_UNLINK(ctx->named_acl_cache, &loop, nextincache);
 	loop.magic = 0;
 	loop.name = NULL;
@@ -154,87 +160,246 @@ convert_keyname(const cfg_obj_t *keyobj, isc_log_t *lctx, isc_mem_t *mctx,
 	return (dns_name_dup(dns_fixedname_name(&fixname), mctx, dnsname));
 }
 
+/*
+ * Recursively pre-parse an ACL definition to find the total number
+ * of non-IP-prefix elements (localhost, localnets, key) in all nested
+ * ACLs, so that the parent will have enough space allocated for the
+ * elements table after all the nested ACLs have been merged in to the
+ * parent.
+ */
+static int
+count_acl_elements(const cfg_obj_t *caml, const cfg_obj_t *cctx)
+{
+	const cfg_listelt_t *elt;
+	const cfg_obj_t *cacl = NULL;
+	isc_result_t result;
+	int n = 0;
+
+	for (elt = cfg_list_first(caml);
+	     elt != NULL;
+	     elt = cfg_list_next(elt)) {
+		const cfg_obj_t *ce = cfg_listelt_value(elt);
+
+		/* negated element; just get the value. */
+		if (cfg_obj_istuple(ce))
+			ce = cfg_tuple_get(ce, "value");
+
+		if (cfg_obj_istype(ce, &cfg_type_keyref)) {
+			n++;
+		} else if (cfg_obj_islist(ce)) {
+			n += count_acl_elements(ce, cctx);
+		} else if (cfg_obj_isstring(ce)) {
+			const char *name = cfg_obj_asstring(ce);
+			if (strcasecmp(name, "localhost") == 0 ||
+			    strcasecmp(name, "localnets") == 0) {
+				n++;
+			} else if (strcasecmp(name, "any") != 0 &&
+				   strcasecmp(name, "none") != 0) {
+				result = get_acl_def(cctx, name, &cacl);
+				if (result == ISC_R_SUCCESS)
+					n += count_acl_elements(cacl, cctx) + 1;
+			}
+		}
+	}
+
+	return n;
+}
+
 isc_result_t
 cfg_acl_fromconfig(const cfg_obj_t *caml,
 		   const cfg_obj_t *cctx,
-	 	   isc_log_t *lctx,
+		   isc_log_t *lctx,
 		   cfg_aclconfctx_t *ctx,
 		   isc_mem_t *mctx,
+		   unsigned int nest_level,
 		   dns_acl_t **target)
 {
 	isc_result_t result;
-	unsigned int count;
-	dns_acl_t *dacl = NULL;
+	dns_acl_t *dacl = NULL, *inneracl = NULL;
 	dns_aclelement_t *de;
 	const cfg_listelt_t *elt;
+	dns_iptable_t *iptab;
+	int new_nest_level = 0;
 
-	REQUIRE(target != NULL && *target == NULL);
+	if (nest_level != 0)
+		new_nest_level = nest_level - 1;
 
-	count = 0;
-	for (elt = cfg_list_first(caml);
-	     elt != NULL;
-	     elt = cfg_list_next(elt))
-		count++;
+	REQUIRE(target != NULL);
+	REQUIRE(*target == NULL || DNS_ACL_VALID(*target));
 
-	result = dns_acl_create(mctx, count, &dacl);
-	if (result != ISC_R_SUCCESS)
-		return (result);
+	if (*target != NULL) {
+		/*
+		 * If target already points to an ACL, then we're being
+		 * called recursively to configure a nested ACL.  The
+		 * nested ACL's contents should just be absorbed into its
+		 * parent ACL.
+		 */
+		dns_acl_attach(*target, &dacl);
+		dns_acl_detach(target);
+	} else {
+		/*
+		 * Need to allocate a new ACL structure.  Count the items
+		 * in the ACL definition that will require space in the
+		 * elements table.  (Note that if nest_level is nonzero,
+		 * *everything* goes in the elements table.)
+		 */
+		int nelem;
+
+		if (nest_level == 0)
+			nelem = count_acl_elements(caml, cctx);
+		else
+			nelem = cfg_list_length(caml, ISC_FALSE);
+
+		result = dns_acl_create(mctx, nelem, &dacl);
+		if (result != ISC_R_SUCCESS)
+			return (result);
+	}
 
 	de = dacl->elements;
 	for (elt = cfg_list_first(caml);
 	     elt != NULL;
-	     elt = cfg_list_next(elt))
-	{
+	     elt = cfg_list_next(elt)) {
 		const cfg_obj_t *ce = cfg_listelt_value(elt);
+		isc_boolean_t	neg;
+
 		if (cfg_obj_istuple(ce)) {
 			/* This must be a negated element. */
 			ce = cfg_tuple_get(ce, "value");
-			de->negative = ISC_TRUE;
-		} else {
-			de->negative = ISC_FALSE;
+			neg = ISC_TRUE;
+			dacl->has_negatives = ISC_TRUE;
+		} else
+			neg = ISC_FALSE;
+
+		/*
+		 * If nest_level is nonzero, then every element is
+		 * to be stored as a separate, nested ACL rather than
+		 * merged into the main iptable.
+		 */
+		iptab = dacl->iptable;
+
+		if (nest_level != 0) {
+			result = dns_acl_create(mctx,
+						cfg_list_length(ce, ISC_FALSE),
+						&de->nestedacl);
+			if (result != ISC_R_SUCCESS)
+				goto cleanup;
+			iptab = de->nestedacl->iptable;
 		}
 
 		if (cfg_obj_isnetprefix(ce)) {
 			/* Network prefix */
-			de->type = dns_aclelementtype_ipprefix;
+			isc_netaddr_t	addr;
+			unsigned int	bitlen;
 
-			cfg_obj_asnetprefix(ce,
-					    &de->u.ip_prefix.address,
-					    &de->u.ip_prefix.prefixlen);
-		} else if (cfg_obj_istype(ce, &cfg_type_keyref)) {
-			/* Key name */
-			de->type = dns_aclelementtype_keyname;
-			dns_name_init(&de->u.keyname, NULL);
-			result = convert_keyname(ce, lctx, mctx,
-						 &de->u.keyname);
+			cfg_obj_asnetprefix(ce, &addr, &bitlen);
+
+			/*
+			 * If nesting ACLs (nest_level != 0), we negate
+			 * the nestedacl element, not the iptable entry.
+			 */
+			result = dns_iptable_addprefix(iptab, &addr, bitlen,
+					      ISC_TF(nest_level != 0 || !neg));
 			if (result != ISC_R_SUCCESS)
 				goto cleanup;
+
+			if (nest_level > 0) {
+				de->type = dns_aclelementtype_nestedacl;
+				de->negative = neg;
+			} else
+				continue;
 		} else if (cfg_obj_islist(ce)) {
-			/* Nested ACL */
-			de->type = dns_aclelementtype_nestedacl;
-			result = cfg_acl_fromconfig(ce, cctx, lctx, ctx,
-						    mctx, &de->u.nestedacl);
+			/*
+			 * If we're nesting ACLs, put the nested
+			 * ACL onto the elements list; otherwise
+			 * merge it into *this* ACL.  We nest ACLs
+			 * in two cases: 1) sortlist, 2) if the
+			 * nested ACL contains negated members.
+			 */
+			if (inneracl != NULL)
+				dns_acl_detach(&inneracl);
+			result = cfg_acl_fromconfig(ce, cctx, lctx,
+						    ctx, mctx, new_nest_level,
+						    &inneracl);
+			if (result != ISC_R_SUCCESS)
+				goto cleanup;
+nested_acl:
+			if (nest_level > 0 || inneracl->has_negatives) {
+				de->type = dns_aclelementtype_nestedacl;
+				de->negative = neg;
+				if (de->nestedacl != NULL)
+					dns_acl_detach(&de->nestedacl);
+				dns_acl_attach(inneracl,
+					       &de->nestedacl);
+				dns_acl_detach(&inneracl);
+				/* Fall through. */
+			} else {
+				dns_acl_merge(dacl, inneracl,
+					      ISC_TF(!neg));
+				de += inneracl->length;  /* elements added */
+				dns_acl_detach(&inneracl);
+				continue;
+			}
+		} else if (cfg_obj_istype(ce, &cfg_type_keyref)) {
+			/* Key name. */
+			de->type = dns_aclelementtype_keyname;
+			de->negative = neg;
+			dns_name_init(&de->keyname, NULL);
+			result = convert_keyname(ce, lctx, mctx,
+						 &de->keyname);
 			if (result != ISC_R_SUCCESS)
 				goto cleanup;
 		} else if (cfg_obj_isstring(ce)) {
-			/* ACL name */
+			/* ACL name. */
 			const char *name = cfg_obj_asstring(ce);
-			if (strcasecmp(name, "localhost") == 0) {
+			if (strcasecmp(name, "any") == 0) {
+				/* Iptable entry with zero bit length. */
+				result = dns_iptable_addprefix(iptab, NULL, 0,
+					      ISC_TF(nest_level != 0 || !neg));
+				if (result != ISC_R_SUCCESS)
+					goto cleanup;
+
+				if (nest_level != 0) {
+					de->type = dns_aclelementtype_nestedacl;
+					de->negative = neg;
+				} else
+					continue;
+			} else if (strcasecmp(name, "none") == 0) {
+				/* none == !any */
+				/*
+				 * We don't unconditional set
+				 * dacl->has_negatives and
+				 * de->negative to true so we can handle
+				 * "!none;".
+				 */
+				result = dns_iptable_addprefix(iptab, NULL, 0,
+					      ISC_TF(nest_level != 0 || neg));
+				if (result != ISC_R_SUCCESS)
+					goto cleanup;
+
+				if (!neg)
+					dacl->has_negatives = !neg;
+
+				if (nest_level != 0) {
+					de->type = dns_aclelementtype_nestedacl;
+					de->negative = !neg;
+				} else
+					continue;
+			} else if (strcasecmp(name, "localhost") == 0) {
 				de->type = dns_aclelementtype_localhost;
+				de->negative = neg;
 			} else if (strcasecmp(name, "localnets") == 0) {
 				de->type = dns_aclelementtype_localnets;
-			}  else if (strcasecmp(name, "any") == 0) {
-				de->type = dns_aclelementtype_any;
-			}  else if (strcasecmp(name, "none") == 0) {
-				de->type = dns_aclelementtype_any;
-				de->negative = ISC_TF(! de->negative);
+				de->negative = neg;
 			} else {
-				de->type = dns_aclelementtype_nestedacl;
-				result = convert_named_acl(ce, cctx, lctx,
-							   ctx, mctx,
-							   &de->u.nestedacl);
+				if (inneracl != NULL)
+					dns_acl_detach(&inneracl);
+				result = convert_named_acl(ce, cctx, lctx, ctx,
+							   mctx, new_nest_level,
+							   &inneracl);
 				if (result != ISC_R_SUCCESS)
 					goto cleanup;
+
+				goto nested_acl;
 			}
 		} else {
 			cfg_obj_log(ce, lctx, ISC_LOG_WARNING,
@@ -243,14 +408,30 @@ cfg_acl_fromconfig(const cfg_obj_t *caml,
 			result = ISC_R_FAILURE;
 			goto cleanup;
 		}
-		de++;
+
+		/*
+		 * This should only be reached for localhost, localnets
+		 * and keyname elements, and nested ACLs if nest_level is
+		 * nonzero (i.e., in sortlists).
+		 */
+		if (de->nestedacl != NULL &&
+		    de->type != dns_aclelementtype_nestedacl)
+			dns_acl_detach(&de->nestedacl);
+
+		dacl->node_count++;
+		de->node_num = dacl->node_count;
+
 		dacl->length++;
+		de++;
+		INSIST(dacl->length <= dacl->alloc);
 	}
 
-	*target = dacl;
-	return (ISC_R_SUCCESS);
+	dns_acl_attach(dacl, target);
+	result = ISC_R_SUCCESS;
 
  cleanup:
+	if (inneracl != NULL)
+		dns_acl_detach(&inneracl);
 	dns_acl_detach(&dacl);
 	return (result);
 }
diff --git a/contrib/bind9/lib/isccfg/api b/contrib/bind9/lib/isccfg/api
index 510e9a9..8459d42 100644
--- a/contrib/bind9/lib/isccfg/api
+++ b/contrib/bind9/lib/isccfg/api
@@ -1,3 +1,3 @@
-LIBINTERFACE = 30
-LIBREVISION = 5
+LIBINTERFACE = 50
+LIBREVISION = 0
 LIBAGE = 0
diff --git a/contrib/bind9/lib/isccfg/include/Makefile.in b/contrib/bind9/lib/isccfg/include/Makefile.in
index 4eddd92..1f24003 100644
--- a/contrib/bind9/lib/isccfg/include/Makefile.in
+++ b/contrib/bind9/lib/isccfg/include/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.5 2004/03/05 05:12:24 marka Exp $
+# $Id: Makefile.in,v 1.7 2007/06/19 23:47:22 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isccfg/include/isccfg/Makefile.in b/contrib/bind9/lib/isccfg/include/isccfg/Makefile.in
index d71d2c2..a6fd412 100644
--- a/contrib/bind9/lib/isccfg/include/isccfg/Makefile.in
+++ b/contrib/bind9/lib/isccfg/include/isccfg/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2001, 2002  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.18.2 2005/01/12 01:54:57 marka Exp $
+# $Id: Makefile.in,v 1.12 2007/06/19 23:47:22 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/isccfg/include/isccfg/aclconf.h b/contrib/bind9/lib/isccfg/include/isccfg/aclconf.h
index a13740c..7ad4351 100644
--- a/contrib/bind9/lib/isccfg/include/isccfg/aclconf.h
+++ b/contrib/bind9/lib/isccfg/include/isccfg/aclconf.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: aclconf.h,v 1.2.2.5 2006/03/02 00:37:22 marka Exp $ */
+/* $Id: aclconf.h,v 1.10 2007/10/12 04:17:18 each Exp $ */
 
 #ifndef ISCCFG_ACLCONF_H
 #define ISCCFG_ACLCONF_H 1
@@ -28,6 +28,7 @@
 
 typedef struct cfg_aclconfctx {
 	ISC_LIST(dns_acl_t) named_acl_cache;
+	ISC_LIST(dns_iptable_t) named_iptable_cache;
 } cfg_aclconfctx_t;
 
 /***
@@ -54,6 +55,7 @@ cfg_acl_fromconfig(const cfg_obj_t *caml,
 		   isc_log_t *lctx,
 		   cfg_aclconfctx_t *ctx,
 		   isc_mem_t *mctx,
+		   unsigned int nest_level,
 		   dns_acl_t **target);
 /*
  * Construct a new dns_acl_t from configuration data in 'caml' and
diff --git a/contrib/bind9/lib/isccfg/include/isccfg/cfg.h b/contrib/bind9/lib/isccfg/include/isccfg/cfg.h
index 6a30a1c..d0ed94b 100644
--- a/contrib/bind9/lib/isccfg/include/isccfg/cfg.h
+++ b/contrib/bind9/lib/isccfg/include/isccfg/cfg.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: cfg.h,v 1.34.18.5 2006/03/02 00:37:22 marka Exp $ */
+/* $Id: cfg.h,v 1.44 2007/10/12 04:17:18 each Exp $ */
 
 #ifndef ISCCFG_CFG_H
 #define ISCCFG_CFG_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file
+/*! \file isccfg/cfg.h
  * \brief
  * This is the new, table-driven, YACC-free configuration file parser.
  */
@@ -347,6 +347,14 @@ cfg_list_next(const cfg_listelt_t *elt);
  * 	or NULL if there are no more elements.
  */
 
+unsigned int
+cfg_list_length(const cfg_obj_t *obj, isc_boolean_t recurse);
+/*%<
+ * Returns the length of a list of configure objects.  If obj is
+ * not a list, returns 0.  If recurse is true, add in the length of
+ * all contained lists.
+ */
+
 const cfg_obj_t *
 cfg_listelt_value(const cfg_listelt_t *elt);
 /*%<
diff --git a/contrib/bind9/lib/isccfg/include/isccfg/grammar.h b/contrib/bind9/lib/isccfg/include/isccfg/grammar.h
index fa66146..f194d4c 100644
--- a/contrib/bind9/lib/isccfg/include/isccfg/grammar.h
+++ b/contrib/bind9/lib/isccfg/include/isccfg/grammar.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2002, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: grammar.h,v 1.4.18.8 2006/02/28 03:10:49 marka Exp $ */
+/* $Id: grammar.h,v 1.17 2008/09/25 04:02:39 tbox Exp $ */
 
 #ifndef ISCCFG_GRAMMAR_H
 #define ISCCFG_GRAMMAR_H 1
 
-/*! \file */
+/*! \file isccfg/grammar.h */
 
 #include <isc/lex.h>
 #include <isc/netaddr.h>
@@ -51,6 +51,8 @@
  * "directory" option.
  */
 #define CFG_CLAUSEFLAG_CALLBACK		0x00000020
+/*% A option that is only used in testing. */
+#define CFG_CLAUSEFLAG_TESTONLY		0x00000040
 
 typedef struct cfg_clausedef cfg_clausedef_t;
 typedef struct cfg_tuplefielddef cfg_tuplefielddef_t;
@@ -184,8 +186,8 @@ struct cfg_parser {
 	/*%
 	 * The stack of currently active files, represented
 	 * as a configuration list of configuration strings.
-	 * The head is the top-level file, subsequent elements 
-	 * (if any) are the nested include files, and the 
+	 * The head is the top-level file, subsequent elements
+	 * (if any) are the nested include files, and the
 	 * last element is the file currently being parsed.
 	 */
 	cfg_obj_t *	open_files;
@@ -433,7 +435,7 @@ cfg_doc_terminal(cfg_printer_t *pctx, const cfg_type_t *type);
 void
 cfg_parser_error(cfg_parser_t *pctx, unsigned int flags,
 		 const char *fmt, ...) ISC_FORMAT_PRINTF(3, 4);
-/*! 
+/*!
  * Pass one of these flags to cfg_parser_error() to include the
  * token text in log message.
  */
diff --git a/contrib/bind9/lib/isccfg/include/isccfg/log.h b/contrib/bind9/lib/isccfg/include/isccfg/log.h
index f66c37f..9750a52 100644
--- a/contrib/bind9/lib/isccfg/include/isccfg/log.h
+++ b/contrib/bind9/lib/isccfg/include/isccfg/log.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: log.h,v 1.6.18.2 2005/04/29 00:17:16 marka Exp $ */
+/* $Id: log.h,v 1.12.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
 #ifndef ISCCFG_LOG_H
 #define ISCCFG_LOG_H 1
 
-/*! \file */
+/*! \file isccfg/log.h */
 
 #include <isc/lang.h>
 #include <isc/log.h>
@@ -46,7 +46,7 @@ cfg_log_init(isc_log_t *lctx);
  *\li	cfg_log_init() is called only once.
  *
  * Ensures:
- * \li	The catgories and modules defined above are available for
+ * \li	The categories and modules defined above are available for
  * 	use by isc_log_usechannnel() and isc_log_write().
  */
 
diff --git a/contrib/bind9/lib/isccfg/include/isccfg/namedconf.h b/contrib/bind9/lib/isccfg/include/isccfg/namedconf.h
index 6125b26..9689a2a 100644
--- a/contrib/bind9/lib/isccfg/include/isccfg/namedconf.h
+++ b/contrib/bind9/lib/isccfg/include/isccfg/namedconf.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: namedconf.h,v 1.3.18.2 2005/04/29 00:17:16 marka Exp $ */
+/* $Id: namedconf.h,v 1.9 2007/06/19 23:47:22 tbox Exp $ */
 
 #ifndef ISCCFG_NAMEDCONF_H
 #define ISCCFG_NAMEDCONF_H 1
 
-/*! \file
+/*! \file isccfg/namedconf.h
  * \brief
  * This module defines the named.conf, rndc.conf, and rndc.key grammars.
  */
diff --git a/contrib/bind9/lib/isccfg/include/isccfg/version.h b/contrib/bind9/lib/isccfg/include/isccfg/version.h
index 38bb14b..8aed111 100644
--- a/contrib/bind9/lib/isccfg/include/isccfg/version.h
+++ b/contrib/bind9/lib/isccfg/include/isccfg/version.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,9 +15,9 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: version.h,v 1.3.18.2 2005/04/29 00:17:16 marka Exp $ */
+/* $Id: version.h,v 1.9 2007/06/19 23:47:22 tbox Exp $ */
 
-/*! \file */
+/*! \file isccfg/version.h */
 
 #include <isc/platform.h>
 
diff --git a/contrib/bind9/lib/isccfg/log.c b/contrib/bind9/lib/isccfg/log.c
index 5d5ccb5..8747fc0 100644
--- a/contrib/bind9/lib/isccfg/log.c
+++ b/contrib/bind9/lib/isccfg/log.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: log.c,v 1.5.18.2 2005/04/29 00:17:15 marka Exp $ */
+/* $Id: log.c,v 1.11 2007/06/19 23:47:22 tbox Exp $ */
 
 /*! \file */
 
@@ -27,7 +27,7 @@
 
 /*%
  * When adding a new category, be sure to add the appropriate
- * #define to <isccfg/log.h>.
+ * \#define to <isccfg/log.h>.
  */
 LIBISCCFG_EXTERNAL_DATA isc_logcategory_t cfg_categories[] = {
 	{ "config", 	0 },
@@ -36,7 +36,7 @@ LIBISCCFG_EXTERNAL_DATA isc_logcategory_t cfg_categories[] = {
 
 /*%
  * When adding a new module, be sure to add the appropriate
- * #define to <isccfg/log.h>.
+ * \#define to <isccfg/log.h>.
  */
 LIBISCCFG_EXTERNAL_DATA isc_logmodule_t cfg_modules[] = {
 	{ "isccfg/parser",	0 },
diff --git a/contrib/bind9/lib/isccfg/namedconf.c b/contrib/bind9/lib/isccfg/namedconf.c
index a13d0a5..0610489 100644
--- a/contrib/bind9/lib/isccfg/namedconf.c
+++ b/contrib/bind9/lib/isccfg/namedconf.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2006, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2002, 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: namedconf.c,v 1.30.18.43 2008/09/04 08:03:08 marka Exp $ */
+/* $Id: namedconf.c,v 1.92 2008/09/27 23:35:31 jinmei Exp $ */
 
 /*! \file */
 
@@ -88,9 +88,9 @@ static cfg_type_t cfg_type_masterselement;
 static cfg_type_t cfg_type_nameportiplist;
 static cfg_type_t cfg_type_negated;
 static cfg_type_t cfg_type_notifytype;
+static cfg_type_t cfg_type_optional_allow;
 static cfg_type_t cfg_type_optional_class;
 static cfg_type_t cfg_type_optional_facility;
-static cfg_type_t cfg_type_optional_facility;
 static cfg_type_t cfg_type_optional_keyref;
 static cfg_type_t cfg_type_optional_port;
 static cfg_type_t cfg_type_options;
@@ -104,6 +104,7 @@ static cfg_type_t cfg_type_size;
 static cfg_type_t cfg_type_sizenodefault;
 static cfg_type_t cfg_type_sockaddr4wild;
 static cfg_type_t cfg_type_sockaddr6wild;
+static cfg_type_t cfg_type_statschannels;
 static cfg_type_t cfg_type_view;
 static cfg_type_t cfg_type_viewopts;
 static cfg_type_t cfg_type_zone;
@@ -258,7 +259,9 @@ static cfg_type_t cfg_type_mode = {
 };
 
 static const char *matchtype_enums[] = {
-	"name", "subdomain", "wildcard", "self", "selfsub", "selfwild", NULL };
+	"name", "subdomain", "wildcard", "self", "selfsub", "selfwild",
+	"krb5-self", "ms-self", "krb5-subdomain", "ms-subdomain",
+	"tcp-self", "6to4-self", NULL };
 static cfg_type_t cfg_type_matchtype = {
 	"matchtype", cfg_parse_enum, cfg_print_ustring, cfg_doc_enum, &cfg_rep_string,
 	&matchtype_enums
@@ -633,6 +636,8 @@ namedconf_clauses[] = {
 	{ "logging", &cfg_type_logging, 0 },
 	{ "view", &cfg_type_view, CFG_CLAUSEFLAG_MULTI },
 	{ "lwres", &cfg_type_lwres, CFG_CLAUSEFLAG_MULTI },
+	{ "statistics-channels", &cfg_type_statschannels,
+	  CFG_CLAUSEFLAG_MULTI },
 	{ NULL, NULL, 0 }
 };
 
@@ -678,6 +683,7 @@ options_clauses[] = {
 	{ "listen-on-v6", &cfg_type_listenon, CFG_CLAUSEFLAG_MULTI },
 	{ "match-mapped-addresses", &cfg_type_boolean, 0 },
 	{ "memstatistics-file", &cfg_type_qstring, 0 },
+	{ "memstatistics", &cfg_type_boolean, 0 },
 	{ "multiple-cnames", &cfg_type_boolean, CFG_CLAUSEFLAG_OBSOLETE },
 	{ "named-xfer", &cfg_type_qstring, CFG_CLAUSEFLAG_OBSOLETE },
 	{ "pid-file", &cfg_type_qstringornone, 0 },
@@ -781,61 +787,68 @@ static cfg_type_t cfg_type_lookaside = {
 
 static cfg_clausedef_t
 view_clauses[] = {
+	{ "acache-cleaning-interval", &cfg_type_uint32, 0 },
+	{ "acache-enable", &cfg_type_boolean, 0 },
+	{ "additional-from-auth", &cfg_type_boolean, 0 },
+	{ "additional-from-cache", &cfg_type_boolean, 0 },
 	{ "allow-query-cache", &cfg_type_bracketed_aml, 0 },
+	{ "allow-query-cache-on", &cfg_type_bracketed_aml, 0 },
 	{ "allow-recursion", &cfg_type_bracketed_aml, 0 },
+	{ "allow-recursion-on", &cfg_type_bracketed_aml, 0 },
 	{ "allow-v6-synthesis", &cfg_type_bracketed_aml,
 	  CFG_CLAUSEFLAG_OBSOLETE },
-	{ "sortlist", &cfg_type_bracketed_aml, 0 },
-	{ "topology", &cfg_type_bracketed_aml, CFG_CLAUSEFLAG_NOTIMP },
 	{ "auth-nxdomain", &cfg_type_boolean, CFG_CLAUSEFLAG_NEWDEFAULT },
-	{ "minimal-responses", &cfg_type_boolean, 0 },
-	{ "recursion", &cfg_type_boolean, 0 },
-	{ "rrset-order", &cfg_type_rrsetorder, 0 },
-	{ "provide-ixfr", &cfg_type_boolean, 0 },
-	{ "request-ixfr", &cfg_type_boolean, 0 },
-	{ "fetch-glue", &cfg_type_boolean, CFG_CLAUSEFLAG_OBSOLETE },
-	{ "rfc2308-type1", &cfg_type_boolean, CFG_CLAUSEFLAG_NYI },
-	{ "additional-from-auth", &cfg_type_boolean, 0 },
-	{ "additional-from-cache", &cfg_type_boolean, 0 },
-	/*
-	 * Note that the query-source option syntax is different
-	 * from the other -source options.
-	 */
-	{ "query-source", &cfg_type_querysource4, 0 },
-	{ "query-source-v6", &cfg_type_querysource6, 0 },
-	{ "cleaning-interval", &cfg_type_uint32, 0 },
-	{ "min-roots", &cfg_type_uint32, CFG_CLAUSEFLAG_NOTIMP },
-	{ "lame-ttl", &cfg_type_uint32, 0 },
-	{ "max-ncache-ttl", &cfg_type_uint32, 0 },
-	{ "max-cache-ttl", &cfg_type_uint32, 0 },
-	{ "transfer-format", &cfg_type_transferformat, 0 },
-	{ "max-cache-size", &cfg_type_sizenodefault, 0 },
-	{ "check-names", &cfg_type_checknames, CFG_CLAUSEFLAG_MULTI },
 	{ "cache-file", &cfg_type_qstring, 0 },
-	{ "suppress-initial-notify", &cfg_type_boolean, CFG_CLAUSEFLAG_NYI },
-	{ "preferred-glue", &cfg_type_astring, 0 },
-	{ "dual-stack-servers", &cfg_type_nameportiplist, 0 },
-	{ "edns-udp-size", &cfg_type_uint32, 0 },
-	{ "max-udp-size", &cfg_type_uint32, 0 },
-	{ "root-delegation-only",  &cfg_type_optional_exclude, 0 },
+	{ "check-names", &cfg_type_checknames, CFG_CLAUSEFLAG_MULTI },
+	{ "cleaning-interval", &cfg_type_uint32, 0 },
+	{ "clients-per-query", &cfg_type_uint32, 0 },
 	{ "disable-algorithms", &cfg_type_disablealgorithm,
 	  CFG_CLAUSEFLAG_MULTI },
+	{ "disable-empty-zone", &cfg_type_astring, CFG_CLAUSEFLAG_MULTI },
+	{ "dnssec-accept-expired", &cfg_type_boolean, 0 },
 	{ "dnssec-enable", &cfg_type_boolean, 0 },
-	{ "dnssec-validation", &cfg_type_boolean, 0 },
 	{ "dnssec-lookaside", &cfg_type_lookaside, CFG_CLAUSEFLAG_MULTI },
 	{ "dnssec-must-be-secure",  &cfg_type_mustbesecure,
-	   CFG_CLAUSEFLAG_MULTI },
-	{ "dnssec-accept-expired", &cfg_type_boolean, 0 },
+	  CFG_CLAUSEFLAG_MULTI },
+	{ "dnssec-validation", &cfg_type_boolean, 0 },
+	{ "dual-stack-servers", &cfg_type_nameportiplist, 0 },
+	{ "edns-udp-size", &cfg_type_uint32, 0 },
+	{ "empty-contact", &cfg_type_astring, 0 },
+	{ "empty-server", &cfg_type_astring, 0 },
+	{ "empty-zones-enable", &cfg_type_boolean, 0 },
+	{ "fetch-glue", &cfg_type_boolean, CFG_CLAUSEFLAG_OBSOLETE },
 	{ "ixfr-from-differences", &cfg_type_ixfrdifftype, 0 },
-	{ "acache-enable", &cfg_type_boolean, 0 },
-	{ "acache-cleaning-interval", &cfg_type_uint32, 0 },
+	{ "lame-ttl", &cfg_type_uint32, 0 },
 	{ "max-acache-size", &cfg_type_sizenodefault, 0 },
-	{ "clients-per-query", &cfg_type_uint32, 0 },
+	{ "max-cache-size", &cfg_type_sizenodefault, 0 },
+	{ "max-cache-ttl", &cfg_type_uint32, 0 },
 	{ "max-clients-per-query", &cfg_type_uint32, 0 },
-	{ "empty-server", &cfg_type_astring, 0 },
-	{ "empty-contact", &cfg_type_astring, 0 },
-	{ "empty-zones-enable", &cfg_type_boolean, 0 },
-	{ "disable-empty-zone", &cfg_type_astring, CFG_CLAUSEFLAG_MULTI },
+	{ "max-ncache-ttl", &cfg_type_uint32, 0 },
+	{ "max-udp-size", &cfg_type_uint32, 0 },
+	{ "min-roots", &cfg_type_uint32, CFG_CLAUSEFLAG_NOTIMP },
+	{ "minimal-responses", &cfg_type_boolean, 0 },
+	{ "preferred-glue", &cfg_type_astring, 0 },
+	{ "provide-ixfr", &cfg_type_boolean, 0 },
+	/*
+	 * Note that the query-source option syntax is different
+	 * from the other -source options.
+	 */
+	{ "query-source", &cfg_type_querysource4, 0 },
+	{ "query-source-v6", &cfg_type_querysource6, 0 },
+	{ "queryport-pool-ports", &cfg_type_uint32, CFG_CLAUSEFLAG_OBSOLETE },
+	{ "queryport-pool-updateinterval", &cfg_type_uint32,
+	  CFG_CLAUSEFLAG_OBSOLETE },
+	{ "recursion", &cfg_type_boolean, 0 },
+	{ "request-ixfr", &cfg_type_boolean, 0 },
+	{ "request-nsid", &cfg_type_boolean, 0 },
+	{ "rfc2308-type1", &cfg_type_boolean, CFG_CLAUSEFLAG_NYI },
+	{ "root-delegation-only",  &cfg_type_optional_exclude, 0 },
+	{ "rrset-order", &cfg_type_rrsetorder, 0 },
+	{ "sortlist", &cfg_type_bracketed_aml, 0 },
+	{ "suppress-initial-notify", &cfg_type_boolean, CFG_CLAUSEFLAG_NYI },
+	{ "topology", &cfg_type_bracketed_aml, CFG_CLAUSEFLAG_NOTIMP },
+	{ "transfer-format", &cfg_type_transferformat, 0 },
+	{ "use-queryport-pool", &cfg_type_boolean, CFG_CLAUSEFLAG_OBSOLETE },
 	{ "zero-no-soa-ttl-cache", &cfg_type_boolean, 0 },
 	{ NULL, NULL, 0 }
 };
@@ -852,53 +865,101 @@ view_only_clauses[] = {
 };
 
 /*%
+ * Sig-validity-interval.
+ */
+static isc_result_t
+parse_optional_uint32(cfg_parser_t *pctx, const cfg_type_t *type,
+		      cfg_obj_t **ret)
+{
+	isc_result_t result;
+	UNUSED(type);
+
+	CHECK(cfg_peektoken(pctx, ISC_LEXOPT_NUMBER | ISC_LEXOPT_CNUMBER));
+	if (pctx->token.type == isc_tokentype_number) {
+		CHECK(cfg_parse_obj(pctx, &cfg_type_uint32, ret));
+	} else {
+		CHECK(cfg_parse_obj(pctx, &cfg_type_void, ret));
+	}
+ cleanup:
+	return (result);
+}
+
+static void
+doc_optional_uint32(cfg_printer_t *pctx, const cfg_type_t *type) {
+	UNUSED(type);
+	cfg_print_chars(pctx, "[ <integer> ]", 13);
+}
+
+static cfg_type_t cfg_type_optional_uint32 = {
+	"optional_uint32", parse_optional_uint32, NULL, doc_optional_uint32,
+	NULL, NULL };
+
+static cfg_tuplefielddef_t validityinterval_fields[] = {
+	{ "validity", &cfg_type_uint32, 0 },
+	{ "re-sign", &cfg_type_optional_uint32, 0 },
+	{ NULL, NULL, 0 }
+};
+
+static cfg_type_t cfg_type_validityinterval = {
+	"validityinterval", cfg_parse_tuple, cfg_print_tuple, cfg_doc_tuple,
+	&cfg_rep_tuple, validityinterval_fields
+};
+
+/*%
  * Clauses that can be found in a 'zone' statement,
  * with defaults in the 'view' or 'options' statement.
  */
 static cfg_clausedef_t
 zone_clauses[] = {
+	{ "allow-notify", &cfg_type_bracketed_aml, 0 },
 	{ "allow-query", &cfg_type_bracketed_aml, 0 },
+	{ "allow-query-on", &cfg_type_bracketed_aml, 0 },
 	{ "allow-transfer", &cfg_type_bracketed_aml, 0 },
 	{ "allow-update", &cfg_type_bracketed_aml, 0 },
 	{ "allow-update-forwarding", &cfg_type_bracketed_aml, 0 },
-	{ "allow-notify", &cfg_type_bracketed_aml, 0 },
-	{ "masterfile-format", &cfg_type_masterformat, 0 },
-	{ "notify", &cfg_type_notifytype, 0 },
-	{ "notify-source", &cfg_type_sockaddr4wild, 0 },
-	{ "notify-source-v6", &cfg_type_sockaddr6wild, 0 },
 	{ "also-notify", &cfg_type_portiplist, 0 },
-	{ "notify-delay", &cfg_type_uint32, 0 },
+	{ "alt-transfer-source", &cfg_type_sockaddr4wild, 0 },
+	{ "alt-transfer-source-v6", &cfg_type_sockaddr6wild, 0 },
+	{ "check-integrity", &cfg_type_boolean, 0 },
+	{ "check-mx", &cfg_type_checkmode, 0 },
+	{ "check-mx-cname", &cfg_type_checkmode, 0 },
+	{ "check-sibling", &cfg_type_boolean, 0 },
+	{ "check-srv-cname", &cfg_type_checkmode, 0 },
+	{ "check-wildcard", &cfg_type_boolean, 0 },
 	{ "dialup", &cfg_type_dialuptype, 0 },
 	{ "forward", &cfg_type_forwardtype, 0 },
 	{ "forwarders", &cfg_type_portiplist, 0 },
+	{ "key-directory", &cfg_type_qstring, 0 },
 	{ "maintain-ixfr-base", &cfg_type_boolean, CFG_CLAUSEFLAG_OBSOLETE },
+	{ "masterfile-format", &cfg_type_masterformat, 0 },
 	{ "max-ixfr-log-size", &cfg_type_size, CFG_CLAUSEFLAG_OBSOLETE },
 	{ "max-journal-size", &cfg_type_sizenodefault, 0 },
-	{ "max-transfer-time-in", &cfg_type_uint32, 0 },
-	{ "max-transfer-time-out", &cfg_type_uint32, 0 },
+	{ "max-refresh-time", &cfg_type_uint32, 0 },
+	{ "max-retry-time", &cfg_type_uint32, 0 },
 	{ "max-transfer-idle-in", &cfg_type_uint32, 0 },
 	{ "max-transfer-idle-out", &cfg_type_uint32, 0 },
-	{ "max-retry-time", &cfg_type_uint32, 0 },
-	{ "min-retry-time", &cfg_type_uint32, 0 },
-	{ "max-refresh-time", &cfg_type_uint32, 0 },
+	{ "max-transfer-time-in", &cfg_type_uint32, 0 },
+	{ "max-transfer-time-out", &cfg_type_uint32, 0 },
 	{ "min-refresh-time", &cfg_type_uint32, 0 },
+	{ "min-retry-time", &cfg_type_uint32, 0 },
 	{ "multi-master", &cfg_type_boolean, 0 },
-	{ "sig-validity-interval", &cfg_type_uint32, 0 },
+	{ "notify", &cfg_type_notifytype, 0 },
+	{ "notify-delay", &cfg_type_uint32, 0 },
+	{ "notify-source", &cfg_type_sockaddr4wild, 0 },
+	{ "notify-source-v6", &cfg_type_sockaddr6wild, 0 },
+	{ "notify-to-soa", &cfg_type_boolean, 0 },
+	{ "nsec3-test-zone", &cfg_type_boolean, CFG_CLAUSEFLAG_TESTONLY },
+	{ "sig-signing-nodes", &cfg_type_uint32, 0 },
+	{ "sig-signing-signatures", &cfg_type_uint32, 0 },
+	{ "sig-signing-type", &cfg_type_uint32, 0 },
+	{ "sig-validity-interval", &cfg_type_validityinterval, 0 },
 	{ "transfer-source", &cfg_type_sockaddr4wild, 0 },
 	{ "transfer-source-v6", &cfg_type_sockaddr6wild, 0 },
-	{ "alt-transfer-source", &cfg_type_sockaddr4wild, 0 },
-	{ "alt-transfer-source-v6", &cfg_type_sockaddr6wild, 0 },
+	{ "try-tcp-refresh", &cfg_type_boolean, 0 },
+	{ "update-check-ksk", &cfg_type_boolean, 0 },
 	{ "use-alt-transfer-source", &cfg_type_boolean, 0 },
-	{ "zone-statistics", &cfg_type_boolean, 0 },
-	{ "key-directory", &cfg_type_qstring, 0 },
-	{ "check-wildcard", &cfg_type_boolean, 0 },
-	{ "check-integrity", &cfg_type_boolean, 0 },
-	{ "check-mx", &cfg_type_checkmode, 0 },
-	{ "check-mx-cname", &cfg_type_checkmode, 0 },
-	{ "check-srv-cname", &cfg_type_checkmode, 0 },
-	{ "check-sibling", &cfg_type_boolean, 0 },
 	{ "zero-no-soa-ttl", &cfg_type_boolean, 0 },
-	{ "update-check-ksk", &cfg_type_boolean, 0 },
+	{ "zone-statistics", &cfg_type_boolean, 0 },
 	{ NULL, NULL, 0 }
 };
 
@@ -1429,6 +1490,53 @@ static cfg_type_t cfg_type_controls = {
 };
 
 /*%
+ * A "statistics-channels" statement is represented as a map with the
+ * multivalued "inet" clauses.
+ */
+static void
+doc_optional_bracketed_list(cfg_printer_t *pctx, const cfg_type_t *type) {
+	const keyword_type_t *kw = type->of;
+	cfg_print_chars(pctx, "[ ", 2);
+	cfg_print_cstr(pctx, kw->name);
+	cfg_print_chars(pctx, " ", 1);
+	cfg_doc_obj(pctx, kw->type);
+	cfg_print_chars(pctx, " ]", 2);
+}
+
+static cfg_type_t cfg_type_optional_allow = {
+	"optional_allow", parse_optional_keyvalue, print_keyvalue,
+	doc_optional_bracketed_list, &cfg_rep_list, &controls_allow_kw
+};
+
+static cfg_tuplefielddef_t statserver_fields[] = {
+	{ "address", &cfg_type_controls_sockaddr, 0 }, /* reuse controls def */
+	{ "allow", &cfg_type_optional_allow, 0 },
+	{ NULL, NULL, 0 }
+};
+
+static cfg_type_t cfg_type_statschannel = {
+	"statschannel", cfg_parse_tuple, cfg_print_tuple, cfg_doc_tuple,
+	&cfg_rep_tuple, statserver_fields
+};
+
+static cfg_clausedef_t
+statservers_clauses[] = {
+	{ "inet", &cfg_type_statschannel, CFG_CLAUSEFLAG_MULTI },
+	{ NULL, NULL, 0 }
+};
+
+static cfg_clausedef_t *
+statservers_clausesets[] = {
+	statservers_clauses,
+	NULL
+};
+
+static cfg_type_t cfg_type_statschannels = {
+	"statistics-channels", cfg_parse_map, cfg_print_map, cfg_doc_map,
+	&cfg_rep_map,	&statservers_clausesets
+};
+
+/*%
  * An optional class, as used in view and zone statements.
  */
 static isc_result_t
@@ -1526,6 +1634,7 @@ print_querysource(cfg_printer_t *pctx, const cfg_obj_t *obj) {
 
 static unsigned int sockaddr4wild_flags = CFG_ADDR_WILDOK | CFG_ADDR_V4OK;
 static unsigned int sockaddr6wild_flags = CFG_ADDR_WILDOK | CFG_ADDR_V6OK;
+
 static cfg_type_t cfg_type_querysource4 = {
 	"querysource4", parse_querysource, NULL, cfg_doc_terminal,
 	NULL, &sockaddr4wild_flags
diff --git a/contrib/bind9/lib/isccfg/parser.c b/contrib/bind9/lib/isccfg/parser.c
index 19a51a6..ee19cf5 100644
--- a/contrib/bind9/lib/isccfg/parser.c
+++ b/contrib/bind9/lib/isccfg/parser.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: parser.c,v 1.112.18.11 2006/02/28 03:10:49 marka Exp $ */
+/* $Id: parser.c,v 1.129 2008/09/25 04:02:39 tbox Exp $ */
 
 /*! \file */
 
@@ -50,7 +50,7 @@
 
 /* Check a return value. */
 #define CHECK(op) 						\
-     	do { result = (op); 					\
+	do { result = (op); 					\
 		if (result != ISC_R_SUCCESS) goto cleanup; 	\
 	} while (0)
 
@@ -192,7 +192,7 @@ cfg_print(const cfg_obj_t *obj,
 
 
 /* Tuples. */
-  
+
 isc_result_t
 cfg_create_tuple(cfg_parser_t *pctx, const cfg_type_t *type, cfg_obj_t **ret) {
 	isc_result_t result;
@@ -303,7 +303,7 @@ cfg_tuple_get(const cfg_obj_t *tupleobj, const char* name) {
 	unsigned int i;
 	const cfg_tuplefielddef_t *fields;
 	const cfg_tuplefielddef_t *f;
-	
+
 	REQUIRE(tupleobj != NULL && tupleobj->type->rep == &cfg_rep_tuple);
 
 	fields = tupleobj->type->of;
@@ -317,7 +317,7 @@ cfg_tuple_get(const cfg_obj_t *tupleobj, const char* name) {
 
 isc_result_t
 cfg_parse_special(cfg_parser_t *pctx, int special) {
-        isc_result_t result;
+	isc_result_t result;
 	CHECK(cfg_gettoken(pctx, 0));
 	if (pctx->token.type == isc_tokentype_special &&
 	    pctx->token.value.as_char == special)
@@ -338,7 +338,7 @@ cfg_parse_special(cfg_parser_t *pctx, int special) {
  */
 static isc_result_t
 parse_semicolon(cfg_parser_t *pctx) {
-        isc_result_t result;
+	isc_result_t result;
 	CHECK(cfg_gettoken(pctx, 0));
 	if (pctx->token.type == isc_tokentype_special &&
 	    pctx->token.value.as_char == ';')
@@ -355,7 +355,7 @@ parse_semicolon(cfg_parser_t *pctx) {
  */
 static isc_result_t
 parse_eof(cfg_parser_t *pctx) {
-        isc_result_t result;
+	isc_result_t result;
 	CHECK(cfg_gettoken(pctx, 0));
 
 	if (pctx->token.type == isc_tokentype_eof)
@@ -519,7 +519,7 @@ cfg_parse_buffer(cfg_parser_t *pctx, isc_buffer_t *buffer,
 {
 	isc_result_t result;
 	REQUIRE(buffer != NULL);
-	CHECK(isc_lex_openbuffer(pctx->lexer, buffer));	
+	CHECK(isc_lex_openbuffer(pctx->lexer, buffer));
 	CHECK(parse2(pctx, type, ret));
  cleanup:
 	return (result);
@@ -577,7 +577,7 @@ cfg_type_t cfg_type_void = {
  */
 isc_result_t
 cfg_parse_uint32(cfg_parser_t *pctx, const cfg_type_t *type, cfg_obj_t **ret) {
-        isc_result_t result;
+	isc_result_t result;
 	cfg_obj_t *obj = NULL;
 	UNUSED(type);
 
@@ -690,7 +690,7 @@ create_string(cfg_parser_t *pctx, const char *contents, const cfg_type_t *type,
 
 isc_result_t
 cfg_parse_qstring(cfg_parser_t *pctx, const cfg_type_t *type, cfg_obj_t **ret) {
-        isc_result_t result;
+	isc_result_t result;
 	UNUSED(type);
 
 	CHECK(cfg_gettoken(pctx, CFG_LEXOPT_QSTRING));
@@ -708,7 +708,7 @@ cfg_parse_qstring(cfg_parser_t *pctx, const cfg_type_t *type, cfg_obj_t **ret) {
 
 static isc_result_t
 parse_ustring(cfg_parser_t *pctx, const cfg_type_t *type, cfg_obj_t **ret) {
-        isc_result_t result;
+	isc_result_t result;
 	UNUSED(type);
 
 	CHECK(cfg_gettoken(pctx, 0));
@@ -728,7 +728,7 @@ isc_result_t
 cfg_parse_astring(cfg_parser_t *pctx, const cfg_type_t *type,
 		  cfg_obj_t **ret)
 {
-        isc_result_t result;
+	isc_result_t result;
 	UNUSED(type);
 
 	CHECK(cfg_getstringtoken(pctx));
@@ -761,14 +761,14 @@ check_enum(cfg_parser_t *pctx, cfg_obj_t *obj, const char *const *enums) {
 
 isc_result_t
 cfg_parse_enum(cfg_parser_t *pctx, const cfg_type_t *type, cfg_obj_t **ret) {
-        isc_result_t result;
+	isc_result_t result;
 	cfg_obj_t *obj = NULL;
 	CHECK(parse_ustring(pctx, NULL, &obj));
 	CHECK(check_enum(pctx, obj, type->of));
 	*ret = obj;
 	return (ISC_R_SUCCESS);
  cleanup:
-	CLEANUP_OBJ(obj);	
+	CLEANUP_OBJ(obj);
 	return (result);
 }
 
@@ -851,7 +851,7 @@ cfg_obj_asboolean(const cfg_obj_t *obj) {
 static isc_result_t
 parse_boolean(cfg_parser_t *pctx, const cfg_type_t *type, cfg_obj_t **ret)
 {
-        isc_result_t result;
+	isc_result_t result;
 	isc_boolean_t value;
 	cfg_obj_t *obj = NULL;
 	UNUSED(type);
@@ -1109,6 +1109,29 @@ cfg_list_next(const cfg_listelt_t *elt) {
 	return (ISC_LIST_NEXT(elt, link));
 }
 
+/*
+ * Return the length of a list object.  If obj is NULL or is not
+ * a list, return 0.
+ */
+unsigned int
+cfg_list_length(const cfg_obj_t *obj, isc_boolean_t recurse) {
+	const cfg_listelt_t *elt;
+	unsigned int count = 0;
+
+	if (obj == NULL || !cfg_obj_islist(obj))
+		return (0U);
+	for (elt = cfg_list_first(obj);
+	     elt != NULL;
+	     elt = cfg_list_next(elt)) {
+		if (recurse && cfg_obj_islist(elt->obj)) {
+			count += cfg_list_length(elt->obj, recurse);
+		} else {
+			count++;
+		}
+	}
+	return (count);
+}
+
 const cfg_obj_t *
 cfg_listelt_value(const cfg_listelt_t *elt) {
 	REQUIRE(elt != NULL);
@@ -1304,7 +1327,7 @@ parse_symtab_elt(cfg_parser_t *pctx, const char *name,
 
 	if (callback && pctx->callback != NULL)
 		CHECK(pctx->callback(name, obj, pctx->callbackarg));
-	
+
 	symval.as_pointer = obj;
 	CHECK(isc_symtab_define(symtab, name,
 				1, symval,
@@ -1351,7 +1374,7 @@ parse_any_named_map(cfg_parser_t *pctx, cfg_type_t *nametype, const cfg_type_t *
 }
 
 /*
- * Parse a map identified by a string name.  E.g., "name { foo 1; }".  
+ * Parse a map identified by a string name.  E.g., "name { foo 1; }".
  * Used for the "key" and "channel" statements.
  */
 isc_result_t
@@ -1431,7 +1454,7 @@ void
 cfg_doc_mapbody(cfg_printer_t *pctx, const cfg_type_t *type) {
 	const cfg_clausedef_t * const *clauseset;
 	const cfg_clausedef_t *clause;
-	
+
 	for (clauseset = type->of; *clauseset != NULL; clauseset++) {
 		for (clause = *clauseset;
 		     clause->name != NULL;
@@ -1454,6 +1477,7 @@ static struct flagtext {
 	{ CFG_CLAUSEFLAG_NYI, "not yet implemented" },
 	{ CFG_CLAUSEFLAG_OBSOLETE, "obsolete" },
 	{ CFG_CLAUSEFLAG_NEWDEFAULT, "default changed" },
+	{ CFG_CLAUSEFLAG_TESTONLY, "test only" },
 	{ 0, NULL }
 };
 
@@ -1488,7 +1512,7 @@ void
 cfg_doc_map(cfg_printer_t *pctx, const cfg_type_t *type) {
 	const cfg_clausedef_t * const *clauseset;
 	const cfg_clausedef_t *clause;
-	
+
 	if (type->parse == cfg_parse_named_map) {
 		cfg_doc_obj(pctx, &cfg_type_astring);
 		cfg_print_chars(pctx, " ", 1);
@@ -1499,9 +1523,9 @@ cfg_doc_map(cfg_printer_t *pctx, const cfg_type_t *type) {
 		cfg_doc_obj(pctx, &cfg_type_netprefix);
 		cfg_print_chars(pctx, " ", 1);
 	}
-	
+
 	print_open(pctx);
-	
+
 	for (clauseset = type->of; *clauseset != NULL; clauseset++) {
 		for (clause = *clauseset;
 		     clause->name != NULL;
@@ -1530,13 +1554,13 @@ cfg_map_get(const cfg_obj_t *mapobj, const char* name, const cfg_obj_t **obj) {
 	isc_result_t result;
 	isc_symvalue_t val;
 	const cfg_map_t *map;
-	
+
 	REQUIRE(mapobj != NULL && mapobj->type->rep == &cfg_rep_map);
 	REQUIRE(name != NULL);
 	REQUIRE(obj != NULL && *obj == NULL);
 
 	map = &mapobj->value.map;
-	
+
 	result = isc_symtab_lookup(map->symtab, name, MAP_SYM, &val);
 	if (result != ISC_R_SUCCESS)
 		return (result);
@@ -1555,7 +1579,7 @@ cfg_map_getname(const cfg_obj_t *mapobj) {
 static isc_result_t
 parse_token(cfg_parser_t *pctx, const cfg_type_t *type, cfg_obj_t **ret) {
 	cfg_obj_t *obj = NULL;
-        isc_result_t result;
+	isc_result_t result;
 	isc_region_t r;
 
 	UNUSED(type);
@@ -1646,7 +1670,7 @@ cfg_type_t cfg_type_unsupported = {
  *
  * If CFG_ADDR_WILDOK is set in flags, "*" can be used as a wildcard
  * and at least one of CFG_ADDR_V4OK and CFG_ADDR_V6OK must also be set.  The
- * "*" is interpreted as the IPv4 wildcard address if CFG_ADDR_V4OK is 
+ * "*" is interpreted as the IPv4 wildcard address if CFG_ADDR_V4OK is
  * set (including the case where CFG_ADDR_V4OK and CFG_ADDR_V6OK are both set),
  * and the IPv6 wildcard address otherwise.
  */
@@ -1844,7 +1868,7 @@ cfg_doc_netaddr(cfg_printer_t *pctx, const cfg_type_t *type) {
 		if (n != 0)
 			cfg_print_chars(pctx, " | ", 3);
 		cfg_print_cstr(pctx, "<ipv6_address>");
-		n++;			
+		n++;
 	}
 	if (*flagp & CFG_ADDR_WILDOK) {
 		if (n != 0)
@@ -2031,7 +2055,7 @@ cfg_doc_sockaddr(cfg_printer_t *pctx, const cfg_type_t *type) {
 		if (n != 0)
 			cfg_print_chars(pctx, " | ", 3);
 		cfg_print_cstr(pctx, "<ipv6_address>");
-		n++;			
+		n++;
 	}
 	if (*flagp & CFG_ADDR_WILDOK) {
 		if (n != 0)
diff --git a/contrib/bind9/lib/isccfg/version.c b/contrib/bind9/lib/isccfg/version.c
index 0b7287b..25b98c6 100644
--- a/contrib/bind9/lib/isccfg/version.c
+++ b/contrib/bind9/lib/isccfg/version.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1998-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: version.c,v 1.3.18.2 2005/04/29 00:17:15 marka Exp $ */
+/* $Id: version.c,v 1.7 2007/06/19 23:47:22 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/lwres/Makefile.in b/contrib/bind9/lib/lwres/Makefile.in
index a06bd8a..858b325 100644
--- a/contrib/bind9/lib/lwres/Makefile.in
+++ b/contrib/bind9/lib/lwres/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2000, 2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.28.18.4 2005/06/09 23:55:10 marka Exp $
+# $Id: Makefile.in,v 1.34 2007/06/19 23:47:22 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/lwres/api b/contrib/bind9/lib/lwres/api
index 0be3ae7..39934b4 100644
--- a/contrib/bind9/lib/lwres/api
+++ b/contrib/bind9/lib/lwres/api
@@ -1,3 +1,3 @@
-LIBINTERFACE = 30
-LIBREVISION = 6
+LIBINTERFACE = 50
+LIBREVISION = 2
 LIBAGE = 0
diff --git a/contrib/bind9/lib/lwres/assert_p.h b/contrib/bind9/lib/lwres/assert_p.h
index c47ecec..f8d6e22 100644
--- a/contrib/bind9/lib/lwres/assert_p.h
+++ b/contrib/bind9/lib/lwres/assert_p.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: assert_p.h,v 1.10.18.2 2005/04/29 00:17:16 marka Exp $ */
+/* $Id: assert_p.h,v 1.14 2007/06/19 23:47:22 tbox Exp $ */
 
 #ifndef LWRES_ASSERT_P_H
 #define LWRES_ASSERT_P_H 1
diff --git a/contrib/bind9/lib/lwres/context.c b/contrib/bind9/lib/lwres/context.c
index c731bb7..464a2cf 100644
--- a/contrib/bind9/lib/lwres/context.c
+++ b/contrib/bind9/lib/lwres/context.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
  *
  * Permission to use, copy, modify, and/or distribute this software for any
@@ -15,9 +15,9 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: context.c,v 1.45.18.7 2007/08/28 07:20:06 tbox Exp $ */
+/* $Id: context.c,v 1.50.332.2 2008/12/30 23:46:49 tbox Exp $ */
 
-/*! \file context.c 
+/*! \file context.c
    lwres_context_create() creates a #lwres_context_t structure for use in
    lightweight resolver operations. It holds a socket and other data
    needed for communicating with a resolver daemon. The new
@@ -156,7 +156,6 @@ lwres_context_create(lwres_context_t **contextp, void *arg,
 	lwres_context_t *ctx;
 
 	REQUIRE(contextp != NULL && *contextp == NULL);
-	UNUSED(flags);
 
 	/*
 	 * If we were not given anything special to use, use our own
@@ -184,6 +183,17 @@ lwres_context_create(lwres_context_t **contextp, void *arg,
 	ctx->timeout = LWRES_DEFAULT_TIMEOUT;
 	ctx->serial = time(NULL); /* XXXMLG or BEW */
 
+	ctx->use_ipv4 = 1;
+	ctx->use_ipv6 = 1;
+	if ((flags & (LWRES_CONTEXT_USEIPV4 | LWRES_CONTEXT_USEIPV6)) ==
+	    LWRES_CONTEXT_USEIPV6) {
+		ctx->use_ipv4 = 0;
+	}
+	if ((flags & (LWRES_CONTEXT_USEIPV4 | LWRES_CONTEXT_USEIPV6)) ==
+	    LWRES_CONTEXT_USEIPV4) {
+		ctx->use_ipv6 = 0;
+	}
+
 	/*
 	 * Init resolv.conf bits.
 	 */
@@ -194,9 +204,9 @@ lwres_context_create(lwres_context_t **contextp, void *arg,
 }
 
 /*%
-Destroys a #lwres_context_t, closing its socket. 
-contextp is a pointer to a pointer to the context that is 
-to be destroyed. The pointer will be set to NULL 
+Destroys a #lwres_context_t, closing its socket.
+contextp 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.
  */
 void
@@ -449,7 +459,7 @@ lwres_context_sendrecv(lwres_context_t *ctx,
 	struct timeval timeout;
 
 	/*
-	 * Type of tv_sec is 32 bits long. 
+	 * Type of tv_sec is 32 bits long.
 	 */
 	if (ctx->timeout <= 0x7FFFFFFFU)
 		timeout.tv_sec = (int)ctx->timeout;
@@ -465,7 +475,7 @@ lwres_context_sendrecv(lwres_context_t *ctx,
 	FD_ZERO(&readfds);
 	FD_SET(ctx->sock, &readfds);
 	ret2 = select(ctx->sock + 1, &readfds, NULL, NULL, &timeout);
-	
+
 	/*
 	 * What happened with select?
 	 */
@@ -477,6 +487,6 @@ lwres_context_sendrecv(lwres_context_t *ctx,
 	result = lwres_context_recv(ctx, recvbase, recvlen, recvd_len);
 	if (result == LWRES_R_RETRY)
 		goto again;
-	
+
 	return (result);
 }
diff --git a/contrib/bind9/lib/lwres/context_p.h b/contrib/bind9/lib/lwres/context_p.h
index d255ef6..dd6f2b6 100644
--- a/contrib/bind9/lib/lwres/context_p.h
+++ b/contrib/bind9/lib/lwres/context_p.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: context_p.h,v 1.13.18.2 2005/04/29 00:17:17 marka Exp $ */
+/* $Id: context_p.h,v 1.17.332.2 2008/12/30 23:46:49 tbox Exp $ */
 
 #ifndef LWRES_CONTEXT_P_H
 #define LWRES_CONTEXT_P_H 1
@@ -46,6 +46,8 @@ struct lwres_context {
 	 */
 	int			sock;		/*%< socket to send on */
 	lwres_addr_t		address;	/*%< address to send to */
+	int			use_ipv4;	/*%< use IPv4 transaction */
+	int			use_ipv6;	/*%< use IPv6 transaction */
 
 	/*@{*/
 	/*
diff --git a/contrib/bind9/lib/lwres/gai_strerror.c b/contrib/bind9/lib/lwres/gai_strerror.c
index 0dcfe40..70b35b0 100644
--- a/contrib/bind9/lib/lwres/gai_strerror.c
+++ b/contrib/bind9/lib/lwres/gai_strerror.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: gai_strerror.c,v 1.16.18.4 2006/08/25 05:25:51 marka Exp $ */
+/* $Id: gai_strerror.c,v 1.22 2007/06/19 23:47:22 tbox Exp $ */
 
 /*! \file gai_strerror.c
  * lwres_gai_strerror() returns an error message corresponding to an
diff --git a/contrib/bind9/lib/lwres/getaddrinfo.c b/contrib/bind9/lib/lwres/getaddrinfo.c
index 6056f24..fc53e63 100644
--- a/contrib/bind9/lib/lwres/getaddrinfo.c
+++ b/contrib/bind9/lib/lwres/getaddrinfo.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
  * This code is derived from software contributed to ISC by
@@ -18,7 +18,7 @@
  * IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: getaddrinfo.c,v 1.43.18.8 2007/09/13 23:46:26 tbox Exp $ */
+/* $Id: getaddrinfo.c,v 1.52.254.2 2009/03/31 23:47:16 tbox Exp $ */
 
 /*! \file */
 
@@ -31,10 +31,10 @@
  *    string: a dotted decimal IPv4 address or an IPv6 address. servname is
  *    either a decimal port number or a service name as listed in
  *    /etc/services.
- * 
+ *
  *    If the operating system does not provide a struct addrinfo, the
  *    following structure is used:
- * 
+ *
  * \code
  * struct  addrinfo {
  *         int             ai_flags;       // AI_PASSIVE, AI_CANONNAME
@@ -47,29 +47,29 @@
  *         struct addrinfo *ai_next;       // next structure in linked list
  * };
  * \endcode
- * 
- * 
+ *
+ *
  *    hints is an optional pointer to a struct addrinfo. 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 *hints:
- * 
+ *
  * <ul>
  *    <li>ai_family:
  *           The protocol family that should be used. When ai_family is set
  *           to PF_UNSPEC, it means the caller will accept any protocol
  *           family supported by the operating system.</li>
- * 
+ *
  *    <li>ai_socktype:
  *           denotes the type of socket -- SOCK_STREAM, SOCK_DGRAM or
  *           SOCK_RAW -- that is wanted. When ai_socktype is zero the caller
  *           will accept any socket type.</li>
- * 
+ *
  *    <li>ai_protocol:
  *           indicates which transport protocol is wanted: IPPROTO_UDP or
  *           IPPROTO_TCP. If ai_protocol is zero the caller will accept any
  *           protocol.</li>
- * 
+ *
  *    <li>ai_flags:
  *           Flag bits. If the AI_CANONNAME bit is set, a successful call to
  *           lwres_getaddrinfo() will return a null-terminated string
@@ -81,7 +81,7 @@
  *           address portion of the socket address structure will be set to
  *           INADDR_ANY for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6
  *           address.<br /><br />
- * 
+ *
  *           When ai_flags does not set the AI_PASSIVE bit, the returned
  *           socket address structure will be ready for use in a call to
  *           connect(2) for a connection-oriented protocol or connect(2),
@@ -89,18 +89,18 @@
  *           chosen. The IP address portion of the socket address structure
  *           will be set to the loopback address if hostname is a NULL
  *           pointer and AI_PASSIVE is not set in ai_flags.<br /><br />
- * 
+ *
  *           If ai_flags is set to AI_NUMERICHOST it indicates that hostname
  *           should be treated as a numeric string defining an IPv4 or IPv6
  *           address and no name resolution should be attempted.
  * </li></ul>
- * 
+ *
  *    All other elements of the struct addrinfo passed via hints must be
  *    zero.
- * 
+ *
  *    A hints of NULL is treated as if the caller provided a struct addrinfo
  *    initialized to zero with ai_familyset to PF_UNSPEC.
- * 
+ *
  *    After a successful call to lwres_getaddrinfo(), *res is a pointer to a
  *    linked list of one or more addrinfo structures. Each struct addrinfo
  *    in this list cn be processed by following the ai_next pointer, until a
@@ -109,7 +109,7 @@
  *    corresponding arguments for a call to socket(2). For each addrinfo
  *    structure in the list, the ai_addr member points to a filled-in socket
  *    address structure of length ai_addrlen.
- * 
+ *
  *    All of the information returned by lwres_getaddrinfo() is dynamically
  *    allocated: the addrinfo structures, and the socket address structures
  *    and canonical host name strings pointed to by the addrinfostructures.
@@ -117,15 +117,15 @@
  *    successful call to lwres_getaddrinfo() is released by
  *    lwres_freeaddrinfo(). ai is a pointer to a struct addrinfo created by
  *    a call to lwres_getaddrinfo().
- * 
+ *
  * \section lwresreturn RETURN VALUES
- * 
+ *
  *    lwres_getaddrinfo() returns zero on success or one of the error codes
  *    listed in gai_strerror() if an error occurs. If both hostname and
  *    servname are NULL lwres_getaddrinfo() returns #EAI_NONAME.
- * 
+ *
  * \section lwressee SEE ALSO
- * 
+ *
  *    lwres(3), lwres_getaddrinfo(), lwres_freeaddrinfo(),
  *    lwres_gai_strerror(), RFC2133, getservbyname(3), connect(2),
  *    sendto(2), sendmsg(2), socket(2).
@@ -145,7 +145,7 @@
 #define SA(addr)	((struct sockaddr *)(addr))
 #define SIN(addr)	((struct sockaddr_in *)(addr))
 #define SIN6(addr)	((struct sockaddr_in6 *)(addr))
-#define SUN(addr)	((struct sockaddr_un *)(addr))
+#define SLOCAL(addr)	((struct sockaddr_un *)(addr))
 
 /*! \struct addrinfo
  */
@@ -162,7 +162,7 @@ static int add_ipv4(const char *hostname, int flags, struct addrinfo **aip,
 static int add_ipv6(const char *hostname, int flags, struct addrinfo **aip,
     int socktype, int port);
 static void set_order(int, int (**)(const char *, int, struct addrinfo **,
-         int, int));
+	 int, int));
 
 #define FOUND_IPV4	0x1
 #define FOUND_IPV6	0x2
@@ -384,7 +384,7 @@ lwres_getaddrinfo(const char *hostname, const char *servname,
 			scopeid = 0;
 #endif
 
-               if (lwres_net_pton(AF_INET, hostname, (struct in_addr *)abuf)
+	       if (lwres_net_pton(AF_INET, hostname, (struct in_addr *)abuf)
 		   == 1)
 	       {
 			if (family == AF_INET6) {
@@ -709,17 +709,17 @@ lwres_freeaddrinfo(struct addrinfo *ai) {
 static int
 get_local(const char *name, int socktype, struct addrinfo **res) {
 	struct addrinfo *ai;
-	struct sockaddr_un *sun;
+	struct sockaddr_un *slocal;
 
 	if (socktype == 0)
 		return (EAI_SOCKTYPE);
 
-	ai = ai_alloc(AF_LOCAL, sizeof(*sun));
+	ai = ai_alloc(AF_LOCAL, sizeof(*slocal));
 	if (ai == NULL)
 		return (EAI_MEMORY);
 
-	sun = SUN(ai->ai_addr);
-	strncpy(sun->sun_path, name, sizeof(sun->sun_path));
+	slocal = SLOCAL(ai->ai_addr);
+	strncpy(slocal->sun_path, name, sizeof(slocal->sun_path));
 
 	ai->ai_socktype = socktype;
 	/*
diff --git a/contrib/bind9/lib/lwres/gethost.c b/contrib/bind9/lib/lwres/gethost.c
index 3cd6e4a..1a1efd4 100644
--- a/contrib/bind9/lib/lwres/gethost.c
+++ b/contrib/bind9/lib/lwres/gethost.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: gethost.c,v 1.30.18.2 2005/04/29 00:17:17 marka Exp $ */
+/* $Id: gethost.c,v 1.34 2007/06/19 23:47:22 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/lwres/getipnode.c b/contrib/bind9/lib/lwres/getipnode.c
index ab49814..a6c50c2 100644
--- a/contrib/bind9/lib/lwres/getipnode.c
+++ b/contrib/bind9/lib/lwres/getipnode.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: getipnode.c,v 1.37.18.7 2007/08/28 07:20:06 tbox Exp $ */
+/* $Id: getipnode.c,v 1.42 2007/06/18 23:47:51 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/lwres/getnameinfo.c b/contrib/bind9/lib/lwres/getnameinfo.c
index d1874a0..74a5b85 100644
--- a/contrib/bind9/lib/lwres/getnameinfo.c
+++ b/contrib/bind9/lib/lwres/getnameinfo.c
@@ -1,8 +1,8 @@
 /*
- * Portions Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: getnameinfo.c,v 1.34.18.3 2005/04/29 00:17:18 marka Exp $ */
+/* $Id: getnameinfo.c,v 1.39 2007/06/19 23:47:22 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/lwres/getrrset.c b/contrib/bind9/lib/lwres/getrrset.c
index 6b7e5e5..d8b6cc3 100644
--- a/contrib/bind9/lib/lwres/getrrset.c
+++ b/contrib/bind9/lib/lwres/getrrset.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: getrrset.c,v 1.14.18.2 2005/04/29 00:17:18 marka Exp $ */
+/* $Id: getrrset.c,v 1.18 2007/06/19 23:47:22 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/lwres/herror.c b/contrib/bind9/lib/lwres/herror.c
index 42b6c71..cf5b892 100644
--- a/contrib/bind9/lib/lwres/herror.c
+++ b/contrib/bind9/lib/lwres/herror.c
@@ -1,8 +1,8 @@
 /*
- * Portions Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 2000, 2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -72,7 +72,7 @@
 #if defined(LIBC_SCCS) && !defined(lint)
 static const char sccsid[] = "@(#)herror.c	8.1 (Berkeley) 6/4/93";
 static const char rcsid[] =
-	"$Id: herror.c,v 1.13.18.2 2005/04/29 00:17:18 marka Exp $";
+	"$Id: herror.c,v 1.17 2007/06/19 23:47:22 tbox Exp $";
 #endif /* LIBC_SCCS and not lint */
 
 #include <config.h>
diff --git a/contrib/bind9/lib/lwres/include/Makefile.in b/contrib/bind9/lib/lwres/include/Makefile.in
index 7501060..4750a5e 100644
--- a/contrib/bind9/lib/lwres/include/Makefile.in
+++ b/contrib/bind9/lib/lwres/include/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2000, 2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.6 2004/03/05 05:12:49 marka Exp $
+# $Id: Makefile.in,v 1.8 2007/06/19 23:47:22 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/lwres/include/lwres/Makefile.in b/contrib/bind9/lib/lwres/include/lwres/Makefile.in
index 98b8f48..fc3126f 100644
--- a/contrib/bind9/lib/lwres/include/lwres/Makefile.in
+++ b/contrib/bind9/lib/lwres/include/lwres/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2000, 2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.21 2004/03/05 05:12:52 marka Exp $
+# $Id: Makefile.in,v 1.23 2007/06/19 23:47:22 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/lwres/include/lwres/context.h b/contrib/bind9/lib/lwres/include/lwres/context.h
index bd24446..5ae0b37 100644
--- a/contrib/bind9/lib/lwres/include/lwres/context.h
+++ b/contrib/bind9/lib/lwres/include/lwres/context.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: context.h,v 1.15.18.2 2005/04/29 00:17:21 marka Exp $ */
+/* $Id: context.h,v 1.21.332.2 2008/12/30 23:46:49 tbox Exp $ */
 
 #ifndef LWRES_CONTEXT_H
 #define LWRES_CONTEXT_H 1
 
-/*! \file */
+/*! \file lwres/context.h */
 
 #include <stddef.h>
 
@@ -57,8 +57,15 @@ typedef void (*lwres_free_t)(void *arg, void *mem, size_t length);
  * _SERVERMODE
  *	Don't allocate and connect a socket to the server, since the
  *	caller _is_ a server.
+ *
+ * _USEIPV4, _USEIPV6
+ *	Use IPv4 and IPv6 transactions with remote servers, respectively.
+ *	For backward compatibility, regard both flags as being set when both
+ *	are cleared.
  */
 #define LWRES_CONTEXT_SERVERMODE	0x00000001U
+#define LWRES_CONTEXT_USEIPV4		0x00000002U
+#define LWRES_CONTEXT_USEIPV6		0x00000004U
 
 lwres_result_t
 lwres_context_create(lwres_context_t **contextp, void *arg,
diff --git a/contrib/bind9/lib/lwres/include/lwres/int.h b/contrib/bind9/lib/lwres/include/lwres/int.h
index 337316e..3fb0c4f 100644
--- a/contrib/bind9/lib/lwres/include/lwres/int.h
+++ b/contrib/bind9/lib/lwres/include/lwres/int.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: int.h,v 1.8.18.2 2005/04/29 00:17:21 marka Exp $ */
+/* $Id: int.h,v 1.14 2007/06/19 23:47:23 tbox Exp $ */
 
 #ifndef LWRES_INT_H
 #define LWRES_INT_H 1
 
-/*! \file */
+/*! \file lwres/int.h */
 
 typedef char				lwres_int8_t;
 typedef unsigned char			lwres_uint8_t;
diff --git a/contrib/bind9/lib/lwres/include/lwres/ipv6.h b/contrib/bind9/lib/lwres/include/lwres/ipv6.h
index 06dab59..5d54b29 100644
--- a/contrib/bind9/lib/lwres/include/lwres/ipv6.h
+++ b/contrib/bind9/lib/lwres/include/lwres/ipv6.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: ipv6.h,v 1.10.18.2 2005/04/29 00:17:21 marka Exp $ */
+/* $Id: ipv6.h,v 1.16 2007/06/19 23:47:23 tbox Exp $ */
 
 #ifndef LWRES_IPV6_H
 #define LWRES_IPV6_H 1
@@ -24,7 +24,7 @@
  ***** Module Info
  *****/
 
-/*! \file ipv6.h
+/*! \file lwres/ipv6.h
  * IPv6 definitions for systems which do not support IPv6.
  */
 
diff --git a/contrib/bind9/lib/lwres/include/lwres/lang.h b/contrib/bind9/lib/lwres/include/lwres/lang.h
index a38f19d..b680e4b 100644
--- a/contrib/bind9/lib/lwres/include/lwres/lang.h
+++ b/contrib/bind9/lib/lwres/include/lwres/lang.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lang.h,v 1.7.18.2 2005/04/29 00:17:21 marka Exp $ */
+/* $Id: lang.h,v 1.13 2007/06/19 23:47:23 tbox Exp $ */
 
 #ifndef LWRES_LANG_H
 #define LWRES_LANG_H 1
 
-/*! \file */
+/*! \file lwres/lang.h */
 
 #ifdef __cplusplus
 #define LWRES_LANG_BEGINDECLS	extern "C" {
diff --git a/contrib/bind9/lib/lwres/include/lwres/list.h b/contrib/bind9/lib/lwres/include/lwres/list.h
index c22c596..c6ab096 100644
--- a/contrib/bind9/lib/lwres/include/lwres/list.h
+++ b/contrib/bind9/lib/lwres/include/lwres/list.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1997-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: list.h,v 1.8.18.2 2005/04/29 00:17:22 marka Exp $ */
+/* $Id: list.h,v 1.14 2007/06/19 23:47:23 tbox Exp $ */
 
 #ifndef LWRES_LIST_H
 #define LWRES_LIST_H 1
 
-/*! \file */
+/*! \file lwres/list.h */
 
 #define LWRES_LIST(type) struct { type *head, *tail; }
 #define LWRES_LIST_INIT(list) \
diff --git a/contrib/bind9/lib/lwres/include/lwres/lwbuffer.h b/contrib/bind9/lib/lwres/include/lwres/lwbuffer.h
index 51b1aad..e3cf343 100644
--- a/contrib/bind9/lib/lwres/include/lwres/lwbuffer.h
+++ b/contrib/bind9/lib/lwres/include/lwres/lwbuffer.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,10 +15,10 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lwbuffer.h,v 1.16.18.2 2005/04/29 00:17:22 marka Exp $ */
+/* $Id: lwbuffer.h,v 1.22 2007/06/19 23:47:23 tbox Exp $ */
 
 
-/*! \file lwbuffer.h
+/*! \file lwres/lwbuffer.h
  *
  * A buffer is a region of memory, together with a set of related subregions.
  * Buffers are used for parsing and I/O operations.
diff --git a/contrib/bind9/lib/lwres/include/lwres/lwpacket.h b/contrib/bind9/lib/lwres/include/lwres/lwpacket.h
index c37353d..96f8e54 100644
--- a/contrib/bind9/lib/lwres/include/lwres/lwpacket.h
+++ b/contrib/bind9/lib/lwres/include/lwres/lwpacket.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lwpacket.h,v 1.18.18.2 2005/04/29 00:17:22 marka Exp $ */
+/* $Id: lwpacket.h,v 1.24 2007/06/19 23:47:23 tbox Exp $ */
 
 #ifndef LWRES_LWPACKET_H
 #define LWRES_LWPACKET_H 1
@@ -118,7 +118,7 @@ struct lwres_lwpacket {
 
 #define LWRES_LWPACKETVERSION_0		0	/*%< Header format. */
 
-/*! \file lwpacket.h
+/*! \file lwres/lwpacket.h
  *
  *
  * The remainder of the packet consists of two regions, one described by
diff --git a/contrib/bind9/lib/lwres/include/lwres/lwres.h b/contrib/bind9/lib/lwres/include/lwres/lwres.h
index b245363..6912448 100644
--- a/contrib/bind9/lib/lwres/include/lwres/lwres.h
+++ b/contrib/bind9/lib/lwres/include/lwres/lwres.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lwres.h,v 1.51.18.2 2005/04/29 00:17:22 marka Exp $ */
+/* $Id: lwres.h,v 1.57 2007/06/19 23:47:23 tbox Exp $ */
 
 #ifndef LWRES_LWRES_H
 #define LWRES_LWRES_H 1
@@ -28,7 +28,7 @@
 #include <lwres/lwpacket.h>
 #include <lwres/platform.h>
 
-/*! \file */
+/*! \file lwres/lwres.h */
 
 /*!
  * Design notes:
diff --git a/contrib/bind9/lib/lwres/include/lwres/netdb.h.in b/contrib/bind9/lib/lwres/include/lwres/netdb.h.in
index eaef63b..37ab039 100644
--- a/contrib/bind9/lib/lwres/include/lwres/netdb.h.in
+++ b/contrib/bind9/lib/lwres/include/lwres/netdb.h.in
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007, 2009  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: netdb.h.in,v 1.35.18.2 2005/04/29 00:17:22 marka Exp $ */
+/* $Id: netdb.h.in,v 1.39.332.2 2009/01/18 23:47:41 tbox Exp $ */
 
 /*! \file */
 
@@ -66,7 +66,7 @@ struct addrinfo {
 #define	NETDB_INTERNAL	-1	/* see errno */
 #define	NETDB_SUCCESS	0	/* no problem */
 #define	HOST_NOT_FOUND	1 /* Authoritative Answer Host not found */
-#define	TRY_AGAIN	2 /* Non-Authoritive Host not found, or SERVERFAIL */
+#define	TRY_AGAIN	2 /* Non-Authoritative Host not found, or SERVERFAIL */
 #define	NO_RECOVERY	3 /* Non recoverable errors, FORMERR, REFUSED, NOTIMP */
 #define	NO_DATA		4 /* Valid name, no data record of requested type */
 #define	NO_ADDRESS	NO_DATA		/* no address, look for MX record */
diff --git a/contrib/bind9/lib/lwres/include/lwres/platform.h.in b/contrib/bind9/lib/lwres/include/lwres/platform.h.in
index f69e09f..bb4f6ee 100644
--- a/contrib/bind9/lib/lwres/include/lwres/platform.h.in
+++ b/contrib/bind9/lib/lwres/include/lwres/platform.h.in
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: platform.h.in,v 1.14.18.5 2005/06/08 02:07:59 marka Exp $ */
+/* $Id: platform.h.in,v 1.21 2007/06/19 23:47:23 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/lwres/include/lwres/result.h b/contrib/bind9/lib/lwres/include/lwres/result.h
index 6253fb2..cfcf166 100644
--- a/contrib/bind9/lib/lwres/include/lwres/result.h
+++ b/contrib/bind9/lib/lwres/include/lwres/result.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: result.h,v 1.15.18.2 2005/04/29 00:17:23 marka Exp $ */
+/* $Id: result.h,v 1.21 2007/06/19 23:47:23 tbox Exp $ */
 
 #ifndef LWRES_RESULT_H
 #define LWRES_RESULT_H 1
 
-/*! \file */
+/*! \file lwres/result.h */
 
 typedef unsigned int lwres_result_t;
 
diff --git a/contrib/bind9/lib/lwres/include/lwres/stdlib.h b/contrib/bind9/lib/lwres/include/lwres/stdlib.h
index 6855fcf..25a109e 100644
--- a/contrib/bind9/lib/lwres/include/lwres/stdlib.h
+++ b/contrib/bind9/lib/lwres/include/lwres/stdlib.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,12 +15,12 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: stdlib.h,v 1.2.2.1 2005/06/08 02:08:01 marka Exp $ */
+/* $Id: stdlib.h,v 1.6 2007/06/19 23:47:23 tbox Exp $ */
 
 #ifndef LWRES_STDLIB_H
 #define LWRES_STDLIB_H 1
 
-/*! \file */
+/*! \file lwres/stdlib.h */
 
 #include <stdlib.h>
 
diff --git a/contrib/bind9/lib/lwres/include/lwres/version.h b/contrib/bind9/lib/lwres/include/lwres/version.h
index 252b903..9efc86d 100644
--- a/contrib/bind9/lib/lwres/include/lwres/version.h
+++ b/contrib/bind9/lib/lwres/include/lwres/version.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,9 +15,9 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: version.h,v 1.3.18.2 2005/04/29 00:17:23 marka Exp $ */
+/* $Id: version.h,v 1.9 2007/06/19 23:47:23 tbox Exp $ */
 
-/*! \file */
+/*! \file lwres/version.h */
 
 #include <lwres/platform.h>
 
diff --git a/contrib/bind9/lib/lwres/lwbuffer.c b/contrib/bind9/lib/lwres/lwbuffer.c
index 5191592..49aaeb7 100644
--- a/contrib/bind9/lib/lwres/lwbuffer.c
+++ b/contrib/bind9/lib/lwres/lwbuffer.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lwbuffer.c,v 1.11.18.2 2005/04/29 00:17:18 marka Exp $ */
+/* $Id: lwbuffer.c,v 1.15 2007/06/19 23:47:22 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/lwres/lwconfig.c b/contrib/bind9/lib/lwres/lwconfig.c
index cf4f6a7..7ededdf 100644
--- a/contrib/bind9/lib/lwres/lwconfig.c
+++ b/contrib/bind9/lib/lwres/lwconfig.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004-2006  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lwconfig.c,v 1.38.18.5 2006/10/03 23:50:51 marka Exp $ */
+/* $Id: lwconfig.c,v 1.46.332.2 2008/12/30 23:46:49 tbox Exp $ */
 
 /*! \file */
 
@@ -24,32 +24,32 @@
  *
  *    lwres_conf_init() creates an empty lwres_conf_t structure for
  *    lightweight resolver context ctx.
- * 
+ *
  *    lwres_conf_clear() frees up all the internal memory used by that
  *    lwres_conf_t structure in resolver context ctx.
- * 
+ *
  *    lwres_conf_parse() opens the file filename and parses it to initialise
  *    the resolver context ctx's lwres_conf_t structure.
- * 
+ *
  *    lwres_conf_print() prints the lwres_conf_t structure for resolver
  *    context ctx to the FILE fp.
- * 
+ *
  * \section lwconfig_return Return Values
- * 
+ *
  *    lwres_conf_parse() returns #LWRES_R_SUCCESS if it successfully read and
  *    parsed filename. It returns #LWRES_R_FAILURE if filename could not be
  *    opened or contained incorrect resolver statements.
- * 
+ *
  *    lwres_conf_print() 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.
- * 
+ *
  * \section lwconfig_see See Also
- * 
+ *
  *    stdio(3), \link resolver resolver \endlink
- * 
+ *
  * \section files Files
- * 
+ *
  *    /etc/resolv.conf
  */
 
@@ -313,8 +313,11 @@ lwres_conf_parsenameserver(lwres_context_t *ctx,  FILE *fp) {
 		return (LWRES_R_FAILURE); /* Extra junk on line. */
 
 	res = lwres_create_addr(word, &address, 1);
-	if (res == LWRES_R_SUCCESS)
+	if (res == LWRES_R_SUCCESS &&
+	    ((address.family == LWRES_ADDRTYPE_V4 && ctx->use_ipv4 == 1) ||
+	     (address.family == LWRES_ADDRTYPE_V6 && ctx->use_ipv6 == 1))) {
 		confdata->nameservers[confdata->nsnext++] = address;
+	}
 
 	return (LWRES_R_SUCCESS);
 }
diff --git a/contrib/bind9/lib/lwres/lwinetaton.c b/contrib/bind9/lib/lwres/lwinetaton.c
index cc4b9bd..e40c28f 100644
--- a/contrib/bind9/lib/lwres/lwinetaton.c
+++ b/contrib/bind9/lib/lwres/lwinetaton.c
@@ -1,8 +1,8 @@
 /*
- * Portions Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Portions Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Portions Copyright (C) 1996-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -72,7 +72,7 @@
  */
 #if defined(LIBC_SCCS) && !defined(lint)
 static char sccsid[] = "@(#)inet_addr.c	8.1 (Berkeley) 6/17/93";
-static char rcsid[] = "$Id: lwinetaton.c,v 1.12.18.2 2005/04/29 00:17:19 marka Exp $";
+static char rcsid[] = "$Id: lwinetaton.c,v 1.16 2007/06/19 23:47:22 tbox Exp $";
 #endif /* LIBC_SCCS and not lint */
 
 #include <config.h>
diff --git a/contrib/bind9/lib/lwres/lwinetntop.c b/contrib/bind9/lib/lwres/lwinetntop.c
index e65656f..cf3bdfe 100644
--- a/contrib/bind9/lib/lwres/lwinetntop.c
+++ b/contrib/bind9/lib/lwres/lwinetntop.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1996-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -19,7 +19,7 @@
  */
 #if defined(LIBC_SCCS) && !defined(lint)
 static char rcsid[] =
-	"$Id: lwinetntop.c,v 1.12.18.4 2005/11/03 23:02:24 marka Exp $";
+	"$Id: lwinetntop.c,v 1.18 2007/06/19 23:47:22 tbox Exp $";
 #endif /* LIBC_SCCS and not lint */
 
 #include <config.h>
diff --git a/contrib/bind9/lib/lwres/lwinetpton.c b/contrib/bind9/lib/lwres/lwinetpton.c
index 5155fd1..5bbef08 100644
--- a/contrib/bind9/lib/lwres/lwinetpton.c
+++ b/contrib/bind9/lib/lwres/lwinetpton.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1996-2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -19,7 +19,7 @@
  */
 
 #if defined(LIBC_SCCS) && !defined(lint)
-static char rcsid[] = "$Id: lwinetpton.c,v 1.7.18.3 2005/04/27 05:02:48 sra Exp $";
+static char rcsid[] = "$Id: lwinetpton.c,v 1.12 2007/06/19 23:47:22 tbox Exp $";
 #endif /* LIBC_SCCS and not lint */
 
 #include <config.h>
diff --git a/contrib/bind9/lib/lwres/lwpacket.c b/contrib/bind9/lib/lwres/lwpacket.c
index 964b465..cfa2723 100644
--- a/contrib/bind9/lib/lwres/lwpacket.c
+++ b/contrib/bind9/lib/lwres/lwpacket.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lwpacket.c,v 1.14.18.2 2005/04/29 00:17:19 marka Exp $ */
+/* $Id: lwpacket.c,v 1.18 2007/06/19 23:47:22 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/lwres/lwres_gabn.c b/contrib/bind9/lib/lwres/lwres_gabn.c
index c6f1139..3363e66 100644
--- a/contrib/bind9/lib/lwres/lwres_gabn.c
+++ b/contrib/bind9/lib/lwres/lwres_gabn.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lwres_gabn.c,v 1.29.18.2 2005/04/29 00:17:19 marka Exp $ */
+/* $Id: lwres_gabn.c,v 1.33 2007/06/19 23:47:22 tbox Exp $ */
 
 /*! \file lwres_gabn.c
    These are low-level routines for creating and parsing lightweight
diff --git a/contrib/bind9/lib/lwres/lwres_gnba.c b/contrib/bind9/lib/lwres/lwres_gnba.c
index 7627385..d18ae15 100644
--- a/contrib/bind9/lib/lwres/lwres_gnba.c
+++ b/contrib/bind9/lib/lwres/lwres_gnba.c
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lwres_gnba.c,v 1.23.18.4 2007/09/26 23:46:34 tbox Exp $ */
+/* $Id: lwres_gnba.c,v 1.28 2007/09/24 17:18:25 each Exp $ */
 
 /*! \file lwres_gnba.c
    These are low-level routines for creating and parsing lightweight
diff --git a/contrib/bind9/lib/lwres/lwres_grbn.c b/contrib/bind9/lib/lwres/lwres_grbn.c
index 976708e..72718ba 100644
--- a/contrib/bind9/lib/lwres/lwres_grbn.c
+++ b/contrib/bind9/lib/lwres/lwres_grbn.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lwres_grbn.c,v 1.6.18.2 2005/04/29 00:17:20 marka Exp $ */
+/* $Id: lwres_grbn.c,v 1.10 2007/06/19 23:47:22 tbox Exp $ */
 
 /*! \file lwres_grbn.c
 
diff --git a/contrib/bind9/lib/lwres/lwres_noop.c b/contrib/bind9/lib/lwres/lwres_noop.c
index e76bc4d..369fe4e 100644
--- a/contrib/bind9/lib/lwres/lwres_noop.c
+++ b/contrib/bind9/lib/lwres/lwres_noop.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lwres_noop.c,v 1.15.18.2 2005/04/29 00:17:20 marka Exp $ */
+/* $Id: lwres_noop.c,v 1.19 2007/06/19 23:47:22 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/lwres/lwresutil.c b/contrib/bind9/lib/lwres/lwresutil.c
index 6d6764f..3bf5660 100644
--- a/contrib/bind9/lib/lwres/lwresutil.c
+++ b/contrib/bind9/lib/lwres/lwresutil.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: lwresutil.c,v 1.30.18.2 2005/04/29 00:17:20 marka Exp $ */
+/* $Id: lwresutil.c,v 1.34 2007/06/19 23:47:22 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/lib/lwres/man/Makefile.in b/contrib/bind9/lib/lwres/man/Makefile.in
index e28123c..cb723c2 100644
--- a/contrib/bind9/lib/lwres/man/Makefile.in
+++ b/contrib/bind9/lib/lwres/man/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.7 2004/03/05 05:12:55 marka Exp $
+# $Id: Makefile.in,v 1.9 2007/06/19 23:47:23 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/lwres/man/lwres.3 b/contrib/bind9/lib/lwres/man/lwres.3
index 968e8f8..e1f8793 100644
--- a/contrib/bind9/lib/lwres/man/lwres.3
+++ b/contrib/bind9/lib/lwres/man/lwres.3
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres.3,v 1.17.18.11 2007/01/30 00:23:44 marka Exp $
+.\" $Id: lwres.3,v 1.28 2007/01/30 00:24:59 marka Exp $
 .\"
 .hy 0
 .ad l
diff --git a/contrib/bind9/lib/lwres/man/lwres.docbook b/contrib/bind9/lib/lwres/man/lwres.docbook
index cf1c154..97d591c 100644
--- a/contrib/bind9/lib/lwres/man/lwres.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres.docbook
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres.docbook,v 1.4.18.6 2007/08/28 07:20:06 tbox Exp $ -->
+<!-- $Id: lwres.docbook,v 1.10 2007/06/18 23:47:51 tbox Exp $ -->
 <refentry>
 
   <refentryinfo>
diff --git a/contrib/bind9/lib/lwres/man/lwres.html b/contrib/bind9/lib/lwres/man/lwres.html
index e4bbc09..70d7856 100644
--- a/contrib/bind9/lib/lwres/man/lwres.html
+++ b/contrib/bind9/lib/lwres/man/lwres.html
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: lwres.html,v 1.5.18.18 2007/01/30 00:23:45 marka Exp $ -->
+<!-- $Id: lwres.html,v 1.23 2007/01/30 00:24:59 marka Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
diff --git a/contrib/bind9/lib/lwres/man/lwres_buffer.3 b/contrib/bind9/lib/lwres/man/lwres_buffer.3
index 4bebafa..cc0959d 100644
--- a/contrib/bind9/lib/lwres/man/lwres_buffer.3
+++ b/contrib/bind9/lib/lwres/man/lwres_buffer.3
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_buffer.3,v 1.15.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_buffer.3,v 1.26 2007/01/30 00:24:59 marka Exp $
 .\"
 .hy 0
 .ad l
diff --git a/contrib/bind9/lib/lwres/man/lwres_buffer.docbook b/contrib/bind9/lib/lwres/man/lwres_buffer.docbook
index f0b7a9f..97c52bd 100644
--- a/contrib/bind9/lib/lwres/man/lwres_buffer.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_buffer.docbook
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_buffer.docbook,v 1.4.18.6 2007/08/28 07:20:06 tbox Exp $ -->
+<!-- $Id: lwres_buffer.docbook,v 1.10 2007/06/18 23:47:51 tbox Exp $ -->
 <refentry>
   <refentryinfo>
     <date>Jun 30, 2000</date>
diff --git a/contrib/bind9/lib/lwres/man/lwres_buffer.html b/contrib/bind9/lib/lwres/man/lwres_buffer.html
index ed3e427..deb5262 100644
--- a/contrib/bind9/lib/lwres/man/lwres_buffer.html
+++ b/contrib/bind9/lib/lwres/man/lwres_buffer.html
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: lwres_buffer.html,v 1.5.18.16 2007/01/30 00:23:45 marka Exp $ -->
+<!-- $Id: lwres_buffer.html,v 1.21 2007/01/30 00:24:59 marka Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
diff --git a/contrib/bind9/lib/lwres/man/lwres_config.3 b/contrib/bind9/lib/lwres/man/lwres_config.3
index 5a4123d..6184cb2 100644
--- a/contrib/bind9/lib/lwres/man/lwres_config.3
+++ b/contrib/bind9/lib/lwres/man/lwres_config.3
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_config.3,v 1.15.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_config.3,v 1.26 2007/01/30 00:24:59 marka Exp $
 .\"
 .hy 0
 .ad l
diff --git a/contrib/bind9/lib/lwres/man/lwres_config.docbook b/contrib/bind9/lib/lwres/man/lwres_config.docbook
index eba0c44..5736ef3 100644
--- a/contrib/bind9/lib/lwres/man/lwres_config.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_config.docbook
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_config.docbook,v 1.3.18.6 2007/08/28 07:20:06 tbox Exp $ -->
+<!-- $Id: lwres_config.docbook,v 1.9 2007/06/18 23:47:51 tbox Exp $ -->
 <refentry>
   <refentryinfo>
 
diff --git a/contrib/bind9/lib/lwres/man/lwres_config.html b/contrib/bind9/lib/lwres/man/lwres_config.html
index efa33d8..e27892b 100644
--- a/contrib/bind9/lib/lwres/man/lwres_config.html
+++ b/contrib/bind9/lib/lwres/man/lwres_config.html
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: lwres_config.html,v 1.5.18.17 2007/01/30 00:23:45 marka Exp $ -->
+<!-- $Id: lwres_config.html,v 1.22 2007/01/30 00:24:59 marka Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
diff --git a/contrib/bind9/lib/lwres/man/lwres_context.3 b/contrib/bind9/lib/lwres/man/lwres_context.3
index 8883a01..b1022d8 100644
--- a/contrib/bind9/lib/lwres/man/lwres_context.3
+++ b/contrib/bind9/lib/lwres/man/lwres_context.3
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_context.3,v 1.17.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_context.3,v 1.28 2007/01/30 00:24:59 marka Exp $
 .\"
 .hy 0
 .ad l
diff --git a/contrib/bind9/lib/lwres/man/lwres_context.docbook b/contrib/bind9/lib/lwres/man/lwres_context.docbook
index b965374..ad0392e 100644
--- a/contrib/bind9/lib/lwres/man/lwres_context.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_context.docbook
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_context.docbook,v 1.5.18.6 2007/08/28 07:20:06 tbox Exp $ -->
+<!-- $Id: lwres_context.docbook,v 1.11 2007/06/18 23:47:51 tbox Exp $ -->
 <refentry>
 
   <refentryinfo>
diff --git a/contrib/bind9/lib/lwres/man/lwres_context.html b/contrib/bind9/lib/lwres/man/lwres_context.html
index f2aa7e1..18c3d38 100644
--- a/contrib/bind9/lib/lwres/man/lwres_context.html
+++ b/contrib/bind9/lib/lwres/man/lwres_context.html
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: lwres_context.html,v 1.7.18.16 2007/01/30 00:23:45 marka Exp $ -->
+<!-- $Id: lwres_context.html,v 1.23 2007/01/30 00:24:59 marka Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
diff --git a/contrib/bind9/lib/lwres/man/lwres_gabn.3 b/contrib/bind9/lib/lwres/man/lwres_gabn.3
index 69d311f..0c14384 100644
--- a/contrib/bind9/lib/lwres/man/lwres_gabn.3
+++ b/contrib/bind9/lib/lwres/man/lwres_gabn.3
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_gabn.3,v 1.16.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_gabn.3,v 1.27 2007/01/30 00:24:59 marka Exp $
 .\"
 .hy 0
 .ad l
diff --git a/contrib/bind9/lib/lwres/man/lwres_gabn.docbook b/contrib/bind9/lib/lwres/man/lwres_gabn.docbook
index c719420..d0b5c19 100644
--- a/contrib/bind9/lib/lwres/man/lwres_gabn.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_gabn.docbook
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_gabn.docbook,v 1.4.18.6 2007/08/28 07:20:06 tbox Exp $ -->
+<!-- $Id: lwres_gabn.docbook,v 1.10 2007/06/18 23:47:51 tbox Exp $ -->
 <refentry>
 
   <refentryinfo>
diff --git a/contrib/bind9/lib/lwres/man/lwres_gabn.html b/contrib/bind9/lib/lwres/man/lwres_gabn.html
index e27954b..a51d252 100644
--- a/contrib/bind9/lib/lwres/man/lwres_gabn.html
+++ b/contrib/bind9/lib/lwres/man/lwres_gabn.html
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: lwres_gabn.html,v 1.7.18.17 2007/01/30 00:23:45 marka Exp $ -->
+<!-- $Id: lwres_gabn.html,v 1.24 2007/01/30 00:24:59 marka Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
diff --git a/contrib/bind9/lib/lwres/man/lwres_gai_strerror.3 b/contrib/bind9/lib/lwres/man/lwres_gai_strerror.3
index 4fd03e2..e412b8f 100644
--- a/contrib/bind9/lib/lwres/man/lwres_gai_strerror.3
+++ b/contrib/bind9/lib/lwres/man/lwres_gai_strerror.3
@@ -13,7 +13,7 @@
 .\" 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.16.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_gai_strerror.3,v 1.27 2007/01/30 00:24:59 marka Exp $
 .\"
 .hy 0
 .ad l
diff --git a/contrib/bind9/lib/lwres/man/lwres_gai_strerror.docbook b/contrib/bind9/lib/lwres/man/lwres_gai_strerror.docbook
index 0b0338b..c33fee5 100644
--- a/contrib/bind9/lib/lwres/man/lwres_gai_strerror.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_gai_strerror.docbook
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_gai_strerror.docbook,v 1.4.18.6 2007/08/28 07:20:06 tbox Exp $ -->
+<!-- $Id: lwres_gai_strerror.docbook,v 1.10 2007/06/18 23:47:51 tbox Exp $ -->
 <refentry>
 
   <refentryinfo>
diff --git a/contrib/bind9/lib/lwres/man/lwres_gai_strerror.html b/contrib/bind9/lib/lwres/man/lwres_gai_strerror.html
index 9673253..c64beb1 100644
--- a/contrib/bind9/lib/lwres/man/lwres_gai_strerror.html
+++ b/contrib/bind9/lib/lwres/man/lwres_gai_strerror.html
@@ -14,7 +14,7 @@
  - 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.6.18.18 2007/01/30 00:23:45 marka Exp $ -->
+<!-- $Id: lwres_gai_strerror.html,v 1.24 2007/01/30 00:24:59 marka Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
diff --git a/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.3 b/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.3
index 9d198d6..7a1b5d7 100644
--- a/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.3
+++ b/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.3
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_getaddrinfo.3,v 1.20.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_getaddrinfo.3,v 1.31 2007/01/30 00:24:59 marka Exp $
 .\"
 .hy 0
 .ad l
diff --git a/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.docbook b/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.docbook
index 52d9387..a328764 100644
--- a/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.docbook
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_getaddrinfo.docbook,v 1.7.18.6 2007/08/28 07:20:06 tbox Exp $ -->
+<!-- $Id: lwres_getaddrinfo.docbook,v 1.13 2007/06/18 23:47:51 tbox Exp $ -->
 <refentry>
 
   <refentryinfo>
diff --git a/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.html b/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.html
index d2dcdd9..d4dd956 100644
--- a/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.html
+++ b/contrib/bind9/lib/lwres/man/lwres_getaddrinfo.html
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: lwres_getaddrinfo.html,v 1.10.18.17 2007/01/30 00:23:45 marka Exp $ -->
+<!-- $Id: lwres_getaddrinfo.html,v 1.27 2007/01/30 00:24:59 marka Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
diff --git a/contrib/bind9/lib/lwres/man/lwres_gethostent.3 b/contrib/bind9/lib/lwres/man/lwres_gethostent.3
index e6fbcd7..847d882 100644
--- a/contrib/bind9/lib/lwres/man/lwres_gethostent.3
+++ b/contrib/bind9/lib/lwres/man/lwres_gethostent.3
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_gethostent.3,v 1.19.18.10 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_gethostent.3,v 1.29 2007/01/30 00:24:59 marka Exp $
 .\"
 .hy 0
 .ad l
diff --git a/contrib/bind9/lib/lwres/man/lwres_gethostent.docbook b/contrib/bind9/lib/lwres/man/lwres_gethostent.docbook
index 4ed7393..a3f084b 100644
--- a/contrib/bind9/lib/lwres/man/lwres_gethostent.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_gethostent.docbook
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_gethostent.docbook,v 1.6.18.5 2007/08/28 07:20:06 tbox Exp $ -->
+<!-- $Id: lwres_gethostent.docbook,v 1.11 2007/06/18 23:47:51 tbox Exp $ -->
 <refentry>
 
   <refentryinfo>
diff --git a/contrib/bind9/lib/lwres/man/lwres_gethostent.html b/contrib/bind9/lib/lwres/man/lwres_gethostent.html
index 0b7ba442..efeeaa2 100644
--- a/contrib/bind9/lib/lwres/man/lwres_gethostent.html
+++ b/contrib/bind9/lib/lwres/man/lwres_gethostent.html
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: lwres_gethostent.html,v 1.9.18.15 2007/01/30 00:23:45 marka Exp $ -->
+<!-- $Id: lwres_gethostent.html,v 1.24 2007/01/30 00:24:59 marka Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
diff --git a/contrib/bind9/lib/lwres/man/lwres_getipnode.3 b/contrib/bind9/lib/lwres/man/lwres_getipnode.3
index 9c9f374..e5c51a9 100644
--- a/contrib/bind9/lib/lwres/man/lwres_getipnode.3
+++ b/contrib/bind9/lib/lwres/man/lwres_getipnode.3
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_getipnode.3,v 1.17.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_getipnode.3,v 1.28 2007/01/30 00:24:59 marka Exp $
 .\"
 .hy 0
 .ad l
diff --git a/contrib/bind9/lib/lwres/man/lwres_getipnode.docbook b/contrib/bind9/lib/lwres/man/lwres_getipnode.docbook
index a748920..825f462 100644
--- a/contrib/bind9/lib/lwres/man/lwres_getipnode.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_getipnode.docbook
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_getipnode.docbook,v 1.6.18.6 2007/08/28 07:20:06 tbox Exp $ -->
+<!-- $Id: lwres_getipnode.docbook,v 1.12 2007/06/18 23:47:51 tbox Exp $ -->
 <refentry>
 
   <refentryinfo>
diff --git a/contrib/bind9/lib/lwres/man/lwres_getipnode.html b/contrib/bind9/lib/lwres/man/lwres_getipnode.html
index a585f1d..23fe50f 100644
--- a/contrib/bind9/lib/lwres/man/lwres_getipnode.html
+++ b/contrib/bind9/lib/lwres/man/lwres_getipnode.html
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: lwres_getipnode.html,v 1.9.18.16 2007/01/30 00:23:45 marka Exp $ -->
+<!-- $Id: lwres_getipnode.html,v 1.25 2007/01/30 00:24:59 marka Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
diff --git a/contrib/bind9/lib/lwres/man/lwres_getnameinfo.3 b/contrib/bind9/lib/lwres/man/lwres_getnameinfo.3
index 449f591..c477f79 100644
--- a/contrib/bind9/lib/lwres/man/lwres_getnameinfo.3
+++ b/contrib/bind9/lib/lwres/man/lwres_getnameinfo.3
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_getnameinfo.3,v 1.18.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_getnameinfo.3,v 1.29 2007/01/30 00:24:59 marka Exp $
 .\"
 .hy 0
 .ad l
diff --git a/contrib/bind9/lib/lwres/man/lwres_getnameinfo.docbook b/contrib/bind9/lib/lwres/man/lwres_getnameinfo.docbook
index d0b0df5..504dfb7 100644
--- a/contrib/bind9/lib/lwres/man/lwres_getnameinfo.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_getnameinfo.docbook
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_getnameinfo.docbook,v 1.4.18.6 2007/08/28 07:20:06 tbox Exp $ -->
+<!-- $Id: lwres_getnameinfo.docbook,v 1.10 2007/06/18 23:47:51 tbox Exp $ -->
 <refentry>
 
   <refentryinfo>
diff --git a/contrib/bind9/lib/lwres/man/lwres_getnameinfo.html b/contrib/bind9/lib/lwres/man/lwres_getnameinfo.html
index 312cfe5..53a70d9 100644
--- a/contrib/bind9/lib/lwres/man/lwres_getnameinfo.html
+++ b/contrib/bind9/lib/lwres/man/lwres_getnameinfo.html
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: lwres_getnameinfo.html,v 1.6.18.17 2007/01/30 00:23:45 marka Exp $ -->
+<!-- $Id: lwres_getnameinfo.html,v 1.23 2007/01/30 00:24:59 marka Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
diff --git a/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.3 b/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.3
index 548b8e7..8419fff 100644
--- a/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.3
+++ b/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.3
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_getrrsetbyname.3,v 1.14.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_getrrsetbyname.3,v 1.25 2007/01/30 00:24:59 marka Exp $
 .\"
 .hy 0
 .ad l
diff --git a/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.docbook b/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.docbook
index 746d8bf..5f2a68d 100644
--- a/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.docbook
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_getrrsetbyname.docbook,v 1.4.18.6 2007/08/28 07:20:06 tbox Exp $ -->
+<!-- $Id: lwres_getrrsetbyname.docbook,v 1.10 2007/06/18 23:47:51 tbox Exp $ -->
 <refentry>
 
   <refentryinfo>
diff --git a/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.html b/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.html
index 0925367..8dc36a1 100644
--- a/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.html
+++ b/contrib/bind9/lib/lwres/man/lwres_getrrsetbyname.html
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: lwres_getrrsetbyname.html,v 1.6.18.17 2007/01/30 00:23:45 marka Exp $ -->
+<!-- $Id: lwres_getrrsetbyname.html,v 1.23 2007/01/30 00:24:59 marka Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
diff --git a/contrib/bind9/lib/lwres/man/lwres_gnba.3 b/contrib/bind9/lib/lwres/man/lwres_gnba.3
index 1c6574f..39a1b9d 100644
--- a/contrib/bind9/lib/lwres/man/lwres_gnba.3
+++ b/contrib/bind9/lib/lwres/man/lwres_gnba.3
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_gnba.3,v 1.16.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_gnba.3,v 1.27 2007/01/30 00:24:59 marka Exp $
 .\"
 .hy 0
 .ad l
diff --git a/contrib/bind9/lib/lwres/man/lwres_gnba.docbook b/contrib/bind9/lib/lwres/man/lwres_gnba.docbook
index a22ce89..452cdfc 100644
--- a/contrib/bind9/lib/lwres/man/lwres_gnba.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_gnba.docbook
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_gnba.docbook,v 1.5.18.6 2007/08/28 07:20:06 tbox Exp $ -->
+<!-- $Id: lwres_gnba.docbook,v 1.11 2007/06/18 23:47:51 tbox Exp $ -->
 <refentry>
 
   <refentryinfo>
diff --git a/contrib/bind9/lib/lwres/man/lwres_gnba.html b/contrib/bind9/lib/lwres/man/lwres_gnba.html
index aac60c6..88b18a8 100644
--- a/contrib/bind9/lib/lwres/man/lwres_gnba.html
+++ b/contrib/bind9/lib/lwres/man/lwres_gnba.html
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: lwres_gnba.html,v 1.7.18.17 2007/01/30 00:23:45 marka Exp $ -->
+<!-- $Id: lwres_gnba.html,v 1.24 2007/01/30 00:24:59 marka Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
diff --git a/contrib/bind9/lib/lwres/man/lwres_hstrerror.3 b/contrib/bind9/lib/lwres/man/lwres_hstrerror.3
index 6fa744e..5998238 100644
--- a/contrib/bind9/lib/lwres/man/lwres_hstrerror.3
+++ b/contrib/bind9/lib/lwres/man/lwres_hstrerror.3
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_hstrerror.3,v 1.16.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_hstrerror.3,v 1.27 2007/01/30 00:24:59 marka Exp $
 .\"
 .hy 0
 .ad l
diff --git a/contrib/bind9/lib/lwres/man/lwres_hstrerror.docbook b/contrib/bind9/lib/lwres/man/lwres_hstrerror.docbook
index aae00a9..ca4589e 100644
--- a/contrib/bind9/lib/lwres/man/lwres_hstrerror.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_hstrerror.docbook
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_hstrerror.docbook,v 1.5.18.6 2007/08/28 07:20:06 tbox Exp $ -->
+<!-- $Id: lwres_hstrerror.docbook,v 1.11 2007/06/18 23:47:51 tbox Exp $ -->
 <refentry>
 
   <refentryinfo>
diff --git a/contrib/bind9/lib/lwres/man/lwres_hstrerror.html b/contrib/bind9/lib/lwres/man/lwres_hstrerror.html
index b52ff06..ef67d48 100644
--- a/contrib/bind9/lib/lwres/man/lwres_hstrerror.html
+++ b/contrib/bind9/lib/lwres/man/lwres_hstrerror.html
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: lwres_hstrerror.html,v 1.6.18.17 2007/01/30 00:23:45 marka Exp $ -->
+<!-- $Id: lwres_hstrerror.html,v 1.23 2007/01/30 00:24:59 marka Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
diff --git a/contrib/bind9/lib/lwres/man/lwres_inetntop.3 b/contrib/bind9/lib/lwres/man/lwres_inetntop.3
index 4cb09f8..c7d3d12 100644
--- a/contrib/bind9/lib/lwres/man/lwres_inetntop.3
+++ b/contrib/bind9/lib/lwres/man/lwres_inetntop.3
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_inetntop.3,v 1.15.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_inetntop.3,v 1.26 2007/01/30 00:24:59 marka Exp $
 .\"
 .hy 0
 .ad l
diff --git a/contrib/bind9/lib/lwres/man/lwres_inetntop.docbook b/contrib/bind9/lib/lwres/man/lwres_inetntop.docbook
index db2c652..26f1779 100644
--- a/contrib/bind9/lib/lwres/man/lwres_inetntop.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_inetntop.docbook
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_inetntop.docbook,v 1.4.18.6 2007/08/28 07:20:06 tbox Exp $ -->
+<!-- $Id: lwres_inetntop.docbook,v 1.10 2007/06/18 23:47:51 tbox Exp $ -->
 <refentry>
 
   <refentryinfo>
diff --git a/contrib/bind9/lib/lwres/man/lwres_inetntop.html b/contrib/bind9/lib/lwres/man/lwres_inetntop.html
index 532d500..1a91110 100644
--- a/contrib/bind9/lib/lwres/man/lwres_inetntop.html
+++ b/contrib/bind9/lib/lwres/man/lwres_inetntop.html
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: lwres_inetntop.html,v 1.6.18.17 2007/01/30 00:23:45 marka Exp $ -->
+<!-- $Id: lwres_inetntop.html,v 1.23 2007/01/30 00:24:59 marka Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
diff --git a/contrib/bind9/lib/lwres/man/lwres_noop.3 b/contrib/bind9/lib/lwres/man/lwres_noop.3
index 7884109..0e4ed71 100644
--- a/contrib/bind9/lib/lwres/man/lwres_noop.3
+++ b/contrib/bind9/lib/lwres/man/lwres_noop.3
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_noop.3,v 1.17.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_noop.3,v 1.28 2007/01/30 00:24:59 marka Exp $
 .\"
 .hy 0
 .ad l
diff --git a/contrib/bind9/lib/lwres/man/lwres_noop.docbook b/contrib/bind9/lib/lwres/man/lwres_noop.docbook
index a2b0699..eb823b7 100644
--- a/contrib/bind9/lib/lwres/man/lwres_noop.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_noop.docbook
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_noop.docbook,v 1.5.18.6 2007/08/28 07:20:06 tbox Exp $ -->
+<!-- $Id: lwres_noop.docbook,v 1.11 2007/06/18 23:47:51 tbox Exp $ -->
 <refentry>
 
   <refentryinfo>
diff --git a/contrib/bind9/lib/lwres/man/lwres_noop.html b/contrib/bind9/lib/lwres/man/lwres_noop.html
index 4705ecb..aab581a 100644
--- a/contrib/bind9/lib/lwres/man/lwres_noop.html
+++ b/contrib/bind9/lib/lwres/man/lwres_noop.html
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: lwres_noop.html,v 1.8.18.17 2007/01/30 00:23:45 marka Exp $ -->
+<!-- $Id: lwres_noop.html,v 1.25 2007/01/30 00:24:59 marka Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
diff --git a/contrib/bind9/lib/lwres/man/lwres_packet.3 b/contrib/bind9/lib/lwres/man/lwres_packet.3
index 14109085..1e1f98f 100644
--- a/contrib/bind9/lib/lwres/man/lwres_packet.3
+++ b/contrib/bind9/lib/lwres/man/lwres_packet.3
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_packet.3,v 1.18.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_packet.3,v 1.29 2007/01/30 00:24:59 marka Exp $
 .\"
 .hy 0
 .ad l
diff --git a/contrib/bind9/lib/lwres/man/lwres_packet.docbook b/contrib/bind9/lib/lwres/man/lwres_packet.docbook
index d588f21..87841db 100644
--- a/contrib/bind9/lib/lwres/man/lwres_packet.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_packet.docbook
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_packet.docbook,v 1.7.18.6 2007/08/28 07:20:06 tbox Exp $ -->
+<!-- $Id: lwres_packet.docbook,v 1.13 2007/06/18 23:47:51 tbox Exp $ -->
 <refentry>
 
   <refentryinfo>
diff --git a/contrib/bind9/lib/lwres/man/lwres_packet.html b/contrib/bind9/lib/lwres/man/lwres_packet.html
index eeb7ebd..b4cc1df 100644
--- a/contrib/bind9/lib/lwres/man/lwres_packet.html
+++ b/contrib/bind9/lib/lwres/man/lwres_packet.html
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: lwres_packet.html,v 1.9.18.17 2007/01/30 00:23:45 marka Exp $ -->
+<!-- $Id: lwres_packet.html,v 1.26 2007/01/30 00:24:59 marka Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
diff --git a/contrib/bind9/lib/lwres/man/lwres_resutil.3 b/contrib/bind9/lib/lwres/man/lwres_resutil.3
index 9aebc9f..d26f77c 100644
--- a/contrib/bind9/lib/lwres/man/lwres_resutil.3
+++ b/contrib/bind9/lib/lwres/man/lwres_resutil.3
@@ -13,7 +13,7 @@
 .\" OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 .\" PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" $Id: lwres_resutil.3,v 1.17.18.11 2007/01/30 00:23:45 marka Exp $
+.\" $Id: lwres_resutil.3,v 1.28 2007/01/30 00:24:59 marka Exp $
 .\"
 .hy 0
 .ad l
diff --git a/contrib/bind9/lib/lwres/man/lwres_resutil.docbook b/contrib/bind9/lib/lwres/man/lwres_resutil.docbook
index b568629..e6184d9 100644
--- a/contrib/bind9/lib/lwres/man/lwres_resutil.docbook
+++ b/contrib/bind9/lib/lwres/man/lwres_resutil.docbook
@@ -18,7 +18,7 @@
  - PERFORMANCE OF THIS SOFTWARE.
 -->
 
-<!-- $Id: lwres_resutil.docbook,v 1.6.18.6 2007/08/28 07:20:06 tbox Exp $ -->
+<!-- $Id: lwres_resutil.docbook,v 1.12 2007/06/18 23:47:51 tbox Exp $ -->
 <refentry>
 
   <refentryinfo>
diff --git a/contrib/bind9/lib/lwres/man/lwres_resutil.html b/contrib/bind9/lib/lwres/man/lwres_resutil.html
index dfa2e1c..7bc3e6e 100644
--- a/contrib/bind9/lib/lwres/man/lwres_resutil.html
+++ b/contrib/bind9/lib/lwres/man/lwres_resutil.html
@@ -14,7 +14,7 @@
  - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
  - PERFORMANCE OF THIS SOFTWARE.
 -->
-<!-- $Id: lwres_resutil.html,v 1.9.18.16 2007/01/30 00:23:45 marka Exp $ -->
+<!-- $Id: lwres_resutil.html,v 1.25 2007/01/30 00:24:59 marka Exp $ -->
 <html>
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
diff --git a/contrib/bind9/lib/lwres/print.c b/contrib/bind9/lib/lwres/print.c
index 49da037..5245d29 100644
--- a/contrib/bind9/lib/lwres/print.c
+++ b/contrib/bind9/lib/lwres/print.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: print.c,v 1.2.2.7 2005/10/14 01:28:30 marka Exp $ */
+/* $Id: print.c,v 1.10 2007/06/19 23:47:22 tbox Exp $ */
 
 #include <config.h>
 
diff --git a/contrib/bind9/lib/lwres/print_p.h b/contrib/bind9/lib/lwres/print_p.h
index 4c2d2bf..c22b44a 100644
--- a/contrib/bind9/lib/lwres/print_p.h
+++ b/contrib/bind9/lib/lwres/print_p.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 1999-2001, 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: print_p.h,v 1.2.2.1 2004/08/28 06:21:13 marka Exp $ */
+/* $Id: print_p.h,v 1.4 2007/06/19 23:47:22 tbox Exp $ */
 
 #ifndef LWRES_PRINT_P_H
 #define LWRES_PRINT_P_H 1
diff --git a/contrib/bind9/lib/lwres/strtoul.c b/contrib/bind9/lib/lwres/strtoul.c
index 3fc8971..f16896c 100644
--- a/contrib/bind9/lib/lwres/strtoul.c
+++ b/contrib/bind9/lib/lwres/strtoul.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2003  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -53,7 +53,7 @@
 static char sccsid[] = "@(#)strtoul.c	8.1 (Berkeley) 6/4/93";
 #endif /* LIBC_SCCS and not lint */
 
-/* $Id: strtoul.c,v 1.2.2.1 2005/06/08 02:07:59 marka Exp $ */
+/* $Id: strtoul.c,v 1.4 2007/06/19 23:47:22 tbox Exp $ */
 
 #include <config.h>
 
diff --git a/contrib/bind9/lib/lwres/unix/Makefile.in b/contrib/bind9/lib/lwres/unix/Makefile.in
index 577e3d3..5d77208 100644
--- a/contrib/bind9/lib/lwres/unix/Makefile.in
+++ b/contrib/bind9/lib/lwres/unix/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.2 2004/03/05 05:12:59 marka Exp $
+# $Id: Makefile.in,v 1.4 2007/06/19 23:47:23 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/lwres/unix/include/Makefile.in b/contrib/bind9/lib/lwres/unix/include/Makefile.in
index 8ca7489..6190633 100644
--- a/contrib/bind9/lib/lwres/unix/include/Makefile.in
+++ b/contrib/bind9/lib/lwres/unix/include/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.2 2004/03/05 05:13:03 marka Exp $
+# $Id: Makefile.in,v 1.4 2007/06/19 23:47:23 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/lwres/unix/include/lwres/Makefile.in b/contrib/bind9/lib/lwres/unix/include/lwres/Makefile.in
index 7e0b594..c943e01 100644
--- a/contrib/bind9/lib/lwres/unix/include/lwres/Makefile.in
+++ b/contrib/bind9/lib/lwres/unix/include/lwres/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.2 2004/03/05 05:13:06 marka Exp $
+# $Id: Makefile.in,v 1.4 2007/06/19 23:47:23 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/lib/lwres/unix/include/lwres/net.h b/contrib/bind9/lib/lwres/unix/include/lwres/net.h
index 8fb14ee..0b16178 100644
--- a/contrib/bind9/lib/lwres/unix/include/lwres/net.h
+++ b/contrib/bind9/lib/lwres/unix/include/lwres/net.h
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000-2002  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: net.h,v 1.5.18.2 2005/04/29 00:17:23 marka Exp $ */
+/* $Id: net.h,v 1.9 2007/06/19 23:47:23 tbox Exp $ */
 
 #ifndef LWRES_NET_H
 #define LWRES_NET_H 1
diff --git a/contrib/bind9/lib/lwres/version.c b/contrib/bind9/lib/lwres/version.c
index 33561fd..cc52c51 100644
--- a/contrib/bind9/lib/lwres/version.c
+++ b/contrib/bind9/lib/lwres/version.c
@@ -1,8 +1,8 @@
 /*
- * Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  * Copyright (C) 2000, 2001  Internet Software Consortium.
  *
- * Permission to use, copy, modify, and distribute this software for any
+ * Permission to use, copy, modify, and/or 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.
  *
@@ -15,7 +15,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: version.c,v 1.8.18.2 2005/04/29 00:17:21 marka Exp $ */
+/* $Id: version.c,v 1.12 2007/06/19 23:47:22 tbox Exp $ */
 
 /*! \file */
 
diff --git a/contrib/bind9/libtool.m4 b/contrib/bind9/libtool.m4
index 551ffd0..a352a65 100644
--- a/contrib/bind9/libtool.m4
+++ b/contrib/bind9/libtool.m4
@@ -1,28 +1,13 @@
 # libtool.m4 - Configure libtool for the host system. -*-Autoconf-*-
-## Copyright 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004
-## Free Software Foundation, Inc.
+## Copyright 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005, 2006, 2007,
+## 2008  Free Software Foundation, Inc.
 ## Originally by Gordon Matzigkeit <gord@gnu.ai.mit.edu>, 1996
 ##
-## This program is free software; you can redistribute it and/or modify
-## it under the terms of the GNU General Public License as published by
-## the Free Software Foundation; either version 2 of the License, or
-## (at your option) any later version.
-##
-## This program is distributed in the hope that it will be useful, but
-## WITHOUT ANY WARRANTY; without even the implied warranty of
-## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-## General Public License for more details.
-##
-## You should have received a copy of the GNU General Public License
-## along with this program; if not, write to the Free Software
-## Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
-##
-## As a special exception to the GNU General Public License, if you
-## distribute this file as part of a program that contains a
-## configuration script generated by Autoconf, you may include it under
-## the same distribution terms that you use for the rest of that program.
+## This file is free software; the Free Software Foundation gives
+## unlimited permission to copy and/or distribute it, with or without
+## modifications, as long as this notice is preserved.
 
-# serial 47 AC_PROG_LIBTOOL
+# serial 52 AC_PROG_LIBTOOL
 
 
 # AC_PROVIDE_IFELSE(MACRO-NAME, IF-PROVIDED, IF-NOT-PROVIDED)
@@ -110,7 +95,6 @@ AC_REQUIRE([AC_DEPLIBS_CHECK_METHOD])dnl
 AC_REQUIRE([AC_OBJEXT])dnl
 AC_REQUIRE([AC_EXEEXT])dnl
 dnl
-
 AC_LIBTOOL_SYS_MAX_CMD_LEN
 AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE
 AC_LIBTOOL_OBJDIR
@@ -132,7 +116,7 @@ esac
 
 # Sed substitution that helps us do robust quoting.  It backslashifies
 # metacharacters that are still active within double-quoted strings.
-Xsed='sed -e s/^X//'
+Xsed='sed -e 1s/^X//'
 [sed_quote_subst='s/\([\\"\\`$\\\\]\)/\\\1/g']
 
 # Same as above, but do not quote variable references.
@@ -152,7 +136,7 @@ rm="rm -f"
 default_ofile=libtool
 can_build_shared=yes
 
-# All known linkers require a `.a' archive for static linking (except M$VC,
+# All known linkers require a `.a' archive for static linking (except MSVC,
 # which needs '.lib').
 libext=a
 ltmain="$ac_aux_dir/ltmain.sh"
@@ -172,6 +156,7 @@ test -z "$AR_FLAGS" && AR_FLAGS=cru
 test -z "$AS" && AS=as
 test -z "$CC" && CC=cc
 test -z "$LTCC" && LTCC=$CC
+test -z "$LTCFLAGS" && LTCFLAGS=$CFLAGS
 test -z "$DLLTOOL" && DLLTOOL=dlltool
 test -z "$LD" && LD=ld
 test -z "$LN_S" && LN_S="ln -s"
@@ -184,23 +169,23 @@ test -z "$STRIP" && STRIP=:
 test -z "$ac_objext" && ac_objext=o
 
 # Determine commands to create old-style static archives.
-old_archive_cmds='$AR $AR_FLAGS $oldlib$oldobjs$old_deplibs'
+old_archive_cmds='$AR $AR_FLAGS $oldlib$oldobjs'
 old_postinstall_cmds='chmod 644 $oldlib'
 old_postuninstall_cmds=
 
 if test -n "$RANLIB"; then
   case $host_os in
   openbsd*)
-    old_postinstall_cmds="\$RANLIB -t \$oldlib~$old_postinstall_cmds"
+    old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB -t \$oldlib"
     ;;
   *)
-    old_postinstall_cmds="\$RANLIB \$oldlib~$old_postinstall_cmds"
+    old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB \$oldlib"
     ;;
   esac
   old_archive_cmds="$old_archive_cmds~\$RANLIB \$oldlib"
 fi
 
-cc_basename=`$echo X"$compiler" | $Xsed -e 's%^.*/%%'`
+_LT_CC_BASENAME([$compiler])
 
 # Only perform the check for file, if the check method requires it
 case $deplibs_check_method in
@@ -211,6 +196,8 @@ file_magic*)
   ;;
 esac
 
+_LT_REQUIRED_DARWIN_CHECKS
+
 AC_PROVIDE_IFELSE([AC_LIBTOOL_DLOPEN], enable_dlopen=yes, enable_dlopen=no)
 AC_PROVIDE_IFELSE([AC_LIBTOOL_WIN32_DLL],
 enable_win32_dll=yes, enable_win32_dll=no)
@@ -242,11 +229,129 @@ AC_DEFUN([_LT_AC_SYS_COMPILER],
 # If no C compiler was specified, use CC.
 LTCC=${LTCC-"$CC"}
 
+# If no C compiler flags were specified, use CFLAGS.
+LTCFLAGS=${LTCFLAGS-"$CFLAGS"}
+
 # Allow CC to be a program name with arguments.
 compiler=$CC
 ])# _LT_AC_SYS_COMPILER
 
 
+# _LT_CC_BASENAME(CC)
+# -------------------
+# Calculate cc_basename.  Skip known compiler wrappers and cross-prefix.
+AC_DEFUN([_LT_CC_BASENAME],
+[for cc_temp in $1""; do
+  case $cc_temp in
+    compile | *[[\\/]]compile | ccache | *[[\\/]]ccache ) ;;
+    distcc | *[[\\/]]distcc | purify | *[[\\/]]purify ) ;;
+    \-*) ;;
+    *) break;;
+  esac
+done
+cc_basename=`$echo "X$cc_temp" | $Xsed -e 's%.*/%%' -e "s%^$host_alias-%%"`
+])
+
+
+# _LT_COMPILER_BOILERPLATE
+# ------------------------
+# Check for compiler boilerplate output or warnings with
+# the simple compiler test code.
+AC_DEFUN([_LT_COMPILER_BOILERPLATE],
+[AC_REQUIRE([LT_AC_PROG_SED])dnl
+ac_outfile=conftest.$ac_objext
+echo "$lt_simple_compile_test_code" >conftest.$ac_ext
+eval "$ac_compile" 2>&1 >/dev/null | $SED '/^$/d; /^ *+/d' >conftest.err
+_lt_compiler_boilerplate=`cat conftest.err`
+$rm conftest*
+])# _LT_COMPILER_BOILERPLATE
+
+
+# _LT_LINKER_BOILERPLATE
+# ----------------------
+# Check for linker boilerplate output or warnings with
+# the simple link test code.
+AC_DEFUN([_LT_LINKER_BOILERPLATE],
+[AC_REQUIRE([LT_AC_PROG_SED])dnl
+ac_outfile=conftest.$ac_objext
+echo "$lt_simple_link_test_code" >conftest.$ac_ext
+eval "$ac_link" 2>&1 >/dev/null | $SED '/^$/d; /^ *+/d' >conftest.err
+_lt_linker_boilerplate=`cat conftest.err`
+$rm -r conftest*
+])# _LT_LINKER_BOILERPLATE
+
+# _LT_REQUIRED_DARWIN_CHECKS
+# --------------------------
+# Check for some things on darwin
+AC_DEFUN([_LT_REQUIRED_DARWIN_CHECKS],[
+  case $host_os in
+    rhapsody* | darwin*)
+    AC_CHECK_TOOL([DSYMUTIL], [dsymutil], [:])
+    AC_CHECK_TOOL([NMEDIT], [nmedit], [:])
+
+    AC_CACHE_CHECK([for -single_module linker flag],[lt_cv_apple_cc_single_mod],
+      [lt_cv_apple_cc_single_mod=no
+      if test -z "${LT_MULTI_MODULE}"; then
+   # By default we will add the -single_module flag. You can override
+   # by either setting the environment variable LT_MULTI_MODULE
+   # non-empty at configure time, or by adding -multi_module to the
+   # link flags.
+   echo "int foo(void){return 1;}" > conftest.c
+   $LTCC $LTCFLAGS $LDFLAGS -o libconftest.dylib \
+     -dynamiclib ${wl}-single_module conftest.c
+   if test -f libconftest.dylib; then
+     lt_cv_apple_cc_single_mod=yes
+     rm -rf libconftest.dylib*
+   fi
+   rm conftest.c
+      fi])
+    AC_CACHE_CHECK([for -exported_symbols_list linker flag],
+      [lt_cv_ld_exported_symbols_list],
+      [lt_cv_ld_exported_symbols_list=no
+      save_LDFLAGS=$LDFLAGS
+      echo "_main" > conftest.sym
+      LDFLAGS="$LDFLAGS -Wl,-exported_symbols_list,conftest.sym"
+      AC_LINK_IFELSE([AC_LANG_PROGRAM([],[])],
+   [lt_cv_ld_exported_symbols_list=yes],
+   [lt_cv_ld_exported_symbols_list=no])
+   LDFLAGS="$save_LDFLAGS"
+    ])
+    case $host_os in
+    rhapsody* | darwin1.[[0123]])
+      _lt_dar_allow_undefined='${wl}-undefined ${wl}suppress' ;;
+    darwin1.*)
+     _lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined ${wl}suppress' ;;
+    darwin*)
+      # if running on 10.5 or later, the deployment target defaults
+      # to the OS version, if on x86, and 10.4, the deployment
+      # target defaults to 10.4. Don't you love it?
+      case ${MACOSX_DEPLOYMENT_TARGET-10.0},$host in
+   10.0,*86*-darwin8*|10.0,*-darwin[[91]]*)
+     _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
+   10.[[012]]*)
+     _lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined ${wl}suppress' ;;
+   10.*)
+     _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
+      esac
+    ;;
+  esac
+    if test "$lt_cv_apple_cc_single_mod" = "yes"; then
+      _lt_dar_single_mod='$single_module'
+    fi
+    if test "$lt_cv_ld_exported_symbols_list" = "yes"; then
+      _lt_dar_export_syms=' ${wl}-exported_symbols_list,$output_objdir/${libname}-symbols.expsym'
+    else
+      _lt_dar_export_syms="~$NMEDIT -s \$output_objdir/\${libname}-symbols.expsym \${lib}"
+    fi
+    if test "$DSYMUTIL" != ":"; then
+      _lt_dsymutil="~$DSYMUTIL \$lib || :"
+    else
+      _lt_dsymutil=
+    fi
+    ;;
+  esac
+])
+
 # _LT_AC_SYS_LIBPATH_AIX
 # ----------------------
 # Links a minimal program and checks the executable
@@ -256,12 +361,20 @@ compiler=$CC
 # If we don't find anything, use the default library path according
 # to the aix ld manual.
 AC_DEFUN([_LT_AC_SYS_LIBPATH_AIX],
-[AC_LINK_IFELSE(AC_LANG_PROGRAM,[
-aix_libpath=`dump -H conftest$ac_exeext 2>/dev/null | $SED -n -e '/Import File Strings/,/^$/ { /^0/ { s/^0  *\(.*\)$/\1/; p; }
-}'`
+[AC_REQUIRE([LT_AC_PROG_SED])dnl
+AC_LINK_IFELSE(AC_LANG_PROGRAM,[
+lt_aix_libpath_sed='
+    /Import File Strings/,/^$/ {
+	/^0/ {
+	    s/^0  *\(.*\)$/\1/
+	    p
+	}
+    }'
+aix_libpath=`dump -H conftest$ac_exeext 2>/dev/null | $SED -n -e "$lt_aix_libpath_sed"`
 # Check for a 64-bit object if we didn't find anything.
-if test -z "$aix_libpath"; then aix_libpath=`dump -HX64 conftest$ac_exeext 2>/dev/null | $SED -n -e '/Import File Strings/,/^$/ { /^0/ { s/^0  *\(.*\)$/\1/; p; }
-}'`; fi],[])
+if test -z "$aix_libpath"; then
+  aix_libpath=`dump -HX64 conftest$ac_exeext 2>/dev/null | $SED -n -e "$lt_aix_libpath_sed"`
+fi],[])
 if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
 ])# _LT_AC_SYS_LIBPATH_AIX
 
@@ -326,8 +439,8 @@ if test "X${echo_test_string+set}" != Xset; then
 # find a string as large as possible, as long as the shell can cope with it
   for cmd in 'sed 50q "[$]0"' 'sed 20q "[$]0"' 'sed 10q "[$]0"' 'sed 2q "[$]0"' 'echo test'; do
     # expected sizes: less than 2Kb, 1Kb, 512 bytes, 16 bytes, ...
-    if (echo_test_string="`eval $cmd`") 2>/dev/null &&
-       echo_test_string="`eval $cmd`" &&
+    if (echo_test_string=`eval $cmd`) 2>/dev/null &&
+       echo_test_string=`eval $cmd` &&
        (test "X$echo_test_string" = "X$echo_test_string") 2>/dev/null
     then
       break
@@ -492,13 +605,17 @@ ia64-*-hpux*)
   rm -rf conftest*
   ;;
 
-x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*|s390*-*linux*|sparc*-*linux*)
+x86_64-*kfreebsd*-gnu|x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*| \
+s390*-*linux*|sparc*-*linux*)
   # Find out which ABI we are using.
   echo 'int i;' > conftest.$ac_ext
   if AC_TRY_EVAL(ac_compile); then
-    case "`/usr/bin/file conftest.o`" in
+    case `/usr/bin/file conftest.o` in
     *32-bit*)
       case $host in
+        x86_64-*kfreebsd*-gnu)
+          LD="${LD-ld} -m elf_i386_fbsd"
+          ;;
         x86_64-*linux*)
           LD="${LD-ld} -m elf_i386"
           ;;
@@ -515,6 +632,9 @@ x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*|s390*-*linux*|sparc*-*linux*)
       ;;
     *64-bit*)
       case $host in
+        x86_64-*kfreebsd*-gnu)
+          LD="${LD-ld} -m elf_x86_64_fbsd"
+          ;;
         x86_64-*linux*)
           LD="${LD-ld} -m elf_x86_64"
           ;;
@@ -547,6 +667,26 @@ x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*|s390*-*linux*|sparc*-*linux*)
     CFLAGS="$SAVE_CFLAGS"
   fi
   ;;
+sparc*-*solaris*)
+  # Find out which ABI we are using.
+  echo 'int i;' > conftest.$ac_ext
+  if AC_TRY_EVAL(ac_compile); then
+    case `/usr/bin/file conftest.o` in
+    *64-bit*)
+      case $lt_cv_prog_gnu_ld in
+      yes*) LD="${LD-ld} -m elf64_sparc" ;;
+      *)
+        if ${LD-ld} -64 -r -o conftest2.o conftest.o >/dev/null 2>&1; then
+	  LD="${LD-ld} -64"
+	fi
+	;;
+      esac
+      ;;
+    esac
+  fi
+  rm -rf conftest*
+  ;;
+
 AC_PROVIDE_IFELSE([AC_LIBTOOL_WIN32_DLL],
 [*-*-cygwin* | *-*-mingw* | *-*-pw32*)
   AC_CHECK_TOOL(DLLTOOL, dlltool, false)
@@ -570,7 +710,7 @@ AC_DEFUN([AC_LIBTOOL_COMPILER_OPTION],
 AC_CACHE_CHECK([$1], [$2],
   [$2=no
   ifelse([$4], , [ac_outfile=conftest.$ac_objext], [ac_outfile=$4])
-   printf "$lt_simple_compile_test_code" > conftest.$ac_ext
+   echo "$lt_simple_compile_test_code" > conftest.$ac_ext
    lt_compiler_flag="$3"
    # Insert the option either (1) after the last *FLAGS variable, or
    # (2) before a word containing "conftest.", or (3) at the end.
@@ -578,7 +718,7 @@ AC_CACHE_CHECK([$1], [$2],
    # with a dollar sign (not a hyphen), so the echo should work correctly.
    # The option is referenced via a variable to avoid confusing sed.
    lt_compile=`echo "$ac_compile" | $SED \
-   -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
+   -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
    -e 's: [[^ ]]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
    (eval echo "\"\$as_me:__oline__: $lt_compile\"" >&AS_MESSAGE_LOG_FD)
@@ -588,8 +728,10 @@ AC_CACHE_CHECK([$1], [$2],
    echo "$as_me:__oline__: \$? = $ac_status" >&AS_MESSAGE_LOG_FD
    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
-     if test ! -s conftest.err; then
+     # So say no if there are warnings other than the usual output.
+     $echo "X$_lt_compiler_boilerplate" | $Xsed -e '/^$/d' >conftest.exp
+     $SED '/^$/d; /^ *+/d' conftest.err >conftest.er2
+     if test ! -s conftest.er2 || diff conftest.exp conftest.er2 >/dev/null; then
        $2=yes
      fi
    fi
@@ -609,22 +751,28 @@ fi
 # ------------------------------------------------------------
 # Check whether the given compiler option works
 AC_DEFUN([AC_LIBTOOL_LINKER_OPTION],
-[AC_CACHE_CHECK([$1], [$2],
+[AC_REQUIRE([LT_AC_PROG_SED])dnl
+AC_CACHE_CHECK([$1], [$2],
   [$2=no
    save_LDFLAGS="$LDFLAGS"
    LDFLAGS="$LDFLAGS $3"
-   printf "$lt_simple_link_test_code" > conftest.$ac_ext
+   echo "$lt_simple_link_test_code" > conftest.$ac_ext
    if (eval $ac_link 2>conftest.err) && test -s conftest$ac_exeext; then
-     # The compiler can only warn and ignore the option if not recognized
+     # The linker can only warn and ignore the option if not recognized
      # So say no if there are warnings
      if test -s conftest.err; then
        # Append any errors to the config.log.
        cat conftest.err 1>&AS_MESSAGE_LOG_FD
+       $echo "X$_lt_linker_boilerplate" | $Xsed -e '/^$/d' > conftest.exp
+       $SED '/^$/d; /^ *+/d' conftest.err >conftest.er2
+       if diff conftest.exp conftest.er2 >/dev/null; then
+         $2=yes
+       fi
      else
        $2=yes
      fi
    fi
-   $rm conftest*
+   $rm -r conftest*
    LDFLAGS="$save_LDFLAGS"
 ])
 
@@ -678,38 +826,71 @@ AC_CACHE_VAL([lt_cv_sys_max_cmd_len], [dnl
     lt_cv_sys_max_cmd_len=8192;
     ;;
 
-  netbsd* | freebsd* | openbsd* | darwin* )
+  netbsd* | freebsd* | openbsd* | darwin* | dragonfly*)
     # This has been around since 386BSD, at least.  Likely further.
     if test -x /sbin/sysctl; then
       lt_cv_sys_max_cmd_len=`/sbin/sysctl -n kern.argmax`
     elif test -x /usr/sbin/sysctl; then
       lt_cv_sys_max_cmd_len=`/usr/sbin/sysctl -n kern.argmax`
     else
-      lt_cv_sys_max_cmd_len=65536 # usable default for *BSD
+      lt_cv_sys_max_cmd_len=65536	# usable default for all BSDs
     fi
     # And add a safety zone
     lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 4`
+    lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \* 3`
+    ;;
+
+  interix*)
+    # We know the value 262144 and hardcode it with a safety zone (like BSD)
+    lt_cv_sys_max_cmd_len=196608
     ;;
 
- *)
-    # If test is not a shell built-in, we'll probably end up computing a
-    # maximum length that is only half of the actual maximum length, but
-    # we can't tell.
-    SHELL=${SHELL-${CONFIG_SHELL-/bin/sh}}
-    while (test "X"`$SHELL [$]0 --fallback-echo "X$teststring" 2>/dev/null` \
+  osf*)
+    # Dr. Hans Ekkehard Plesser reports seeing a kernel panic running configure
+    # due to this test when exec_disable_arg_limit is 1 on Tru64. It is not
+    # nice to cause kernel panics so lets avoid the loop below.
+    # First set a reasonable default.
+    lt_cv_sys_max_cmd_len=16384
+    #
+    if test -x /sbin/sysconfig; then
+      case `/sbin/sysconfig -q proc exec_disable_arg_limit` in
+        *1*) lt_cv_sys_max_cmd_len=-1 ;;
+      esac
+    fi
+    ;;
+  sco3.2v5*)
+    lt_cv_sys_max_cmd_len=102400
+    ;;
+  sysv5* | sco5v6* | sysv4.2uw2*)
+    kargmax=`grep ARG_MAX /etc/conf/cf.d/stune 2>/dev/null`
+    if test -n "$kargmax"; then
+      lt_cv_sys_max_cmd_len=`echo $kargmax | sed 's/.*[[ 	]]//'`
+    else
+      lt_cv_sys_max_cmd_len=32768
+    fi
+    ;;
+  *)
+    lt_cv_sys_max_cmd_len=`(getconf ARG_MAX) 2> /dev/null`
+    if test -n "$lt_cv_sys_max_cmd_len"; then
+      lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 4`
+      lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \* 3`
+    else
+      SHELL=${SHELL-${CONFIG_SHELL-/bin/sh}}
+      while (test "X"`$SHELL [$]0 --fallback-echo "X$teststring" 2>/dev/null` \
 	       = "XX$teststring") >/dev/null 2>&1 &&
-	    new_result=`expr "X$teststring" : ".*" 2>&1` &&
-	    lt_cv_sys_max_cmd_len=$new_result &&
-	    test $i != 17 # 1/2 MB should be enough
-    do
-      i=`expr $i + 1`
-      teststring=$teststring$teststring
-    done
-    teststring=
-    # Add a significant safety factor because C++ compilers can tack on massive
-    # amounts of additional arguments before passing them to the linker.
-    # It appears as though 1/2 is a usable value.
-    lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 2`
+	      new_result=`expr "X$teststring" : ".*" 2>&1` &&
+	      lt_cv_sys_max_cmd_len=$new_result &&
+	      test $i != 17 # 1/2 MB should be enough
+      do
+        i=`expr $i + 1`
+        teststring=$teststring$teststring
+      done
+      teststring=
+      # Add a significant safety factor because C++ compilers can tack on massive
+      # amounts of additional arguments before passing them to the linker.
+      # It appears as though 1/2 is a usable value.
+      lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 2`
+    fi
     ;;
   esac
 ])
@@ -722,7 +903,7 @@ fi
 
 
 # _LT_AC_CHECK_DLFCN
-# --------------------
+# ------------------
 AC_DEFUN([_LT_AC_CHECK_DLFCN],
 [AC_CHECK_HEADERS(dlfcn.h)dnl
 ])# _LT_AC_CHECK_DLFCN
@@ -730,7 +911,7 @@ AC_DEFUN([_LT_AC_CHECK_DLFCN],
 
 # _LT_AC_TRY_DLOPEN_SELF (ACTION-IF-TRUE, ACTION-IF-TRUE-W-USCORE,
 #                           ACTION-IF-FALSE, ACTION-IF-CROSS-COMPILING)
-# ------------------------------------------------------------------
+# ---------------------------------------------------------------------
 AC_DEFUN([_LT_AC_TRY_DLOPEN_SELF],
 [AC_REQUIRE([_LT_AC_CHECK_DLFCN])dnl
 if test "$cross_compiling" = yes; then :
@@ -796,17 +977,19 @@ int main ()
       else if (dlsym( self,"_fnord")) status = $lt_dlneed_uscore;
       /* dlclose (self); */
     }
+  else
+    puts (dlerror ());
 
     exit (status);
 }]
 EOF
   if AC_TRY_EVAL(ac_link) && test -s conftest${ac_exeext} 2>/dev/null; then
-    (./conftest; exit; ) 2>/dev/null
+    (./conftest; exit; ) >&AS_MESSAGE_LOG_FD 2>/dev/null
     lt_status=$?
     case x$lt_status in
       x$lt_dlno_uscore) $1 ;;
       x$lt_dlneed_uscore) $2 ;;
-      x$lt_unknown|x*) $3 ;;
+      x$lt_dlunknown|x*) $3 ;;
     esac
   else :
     # compilation failed
@@ -818,7 +1001,7 @@ rm -fr conftest*
 
 
 # AC_LIBTOOL_DLOPEN_SELF
-# -------------------
+# ----------------------
 AC_DEFUN([AC_LIBTOOL_DLOPEN_SELF],
 [AC_REQUIRE([_LT_AC_CHECK_DLFCN])dnl
 if test "x$enable_dlopen" != xyes; then
@@ -860,7 +1043,7 @@ else
     AC_CHECK_FUNC([shl_load],
 	  [lt_cv_dlopen="shl_load"],
       [AC_CHECK_LIB([dld], [shl_load],
-	    [lt_cv_dlopen="shl_load" lt_cv_dlopen_libs="-dld"],
+	    [lt_cv_dlopen="shl_load" lt_cv_dlopen_libs="-ldld"],
 	[AC_CHECK_FUNC([dlopen],
 	      [lt_cv_dlopen="dlopen"],
 	  [AC_CHECK_LIB([dl], [dlopen],
@@ -868,7 +1051,7 @@ else
 	    [AC_CHECK_LIB([svld], [dlopen],
 		  [lt_cv_dlopen="dlopen" lt_cv_dlopen_libs="-lsvld"],
 	      [AC_CHECK_LIB([dld], [dld_link],
-		    [lt_cv_dlopen="dld_link" lt_cv_dlopen_libs="-dld"])
+		    [lt_cv_dlopen="dld_link" lt_cv_dlopen_libs="-ldld"])
 	      ])
 	    ])
 	  ])
@@ -889,7 +1072,7 @@ else
     test "x$ac_cv_header_dlfcn_h" = xyes && CPPFLAGS="$CPPFLAGS -DHAVE_DLFCN_H"
 
     save_LDFLAGS="$LDFLAGS"
-    eval LDFLAGS=\"\$LDFLAGS $export_dynamic_flag_spec\"
+    wl=$lt_prog_compiler_wl eval LDFLAGS=\"\$LDFLAGS $export_dynamic_flag_spec\"
 
     save_LIBS="$LIBS"
     LIBS="$lt_cv_dlopen_libs $LIBS"
@@ -902,7 +1085,7 @@ else
     ])
 
     if test "x$lt_cv_dlopen_self" = xyes; then
-      LDFLAGS="$LDFLAGS $link_static_flag"
+      wl=$lt_prog_compiler_wl eval LDFLAGS=\"\$LDFLAGS $lt_prog_compiler_static\"
       AC_CACHE_CHECK([whether a statically linked program can dlopen itself],
     	  lt_cv_dlopen_self_static, [dnl
 	  _LT_AC_TRY_DLOPEN_SELF(
@@ -934,7 +1117,8 @@ fi
 # ---------------------------------
 # Check to see if options -c and -o are simultaneously supported by compiler
 AC_DEFUN([AC_LIBTOOL_PROG_CC_C_O],
-[AC_REQUIRE([_LT_AC_SYS_COMPILER])dnl
+[AC_REQUIRE([LT_AC_PROG_SED])dnl
+AC_REQUIRE([_LT_AC_SYS_COMPILER])dnl
 AC_CACHE_CHECK([if $compiler supports -c -o file.$ac_objext],
   [_LT_AC_TAGVAR(lt_cv_prog_compiler_c_o, $1)],
   [_LT_AC_TAGVAR(lt_cv_prog_compiler_c_o, $1)=no
@@ -942,7 +1126,7 @@ AC_CACHE_CHECK([if $compiler supports -c -o file.$ac_objext],
    mkdir conftest
    cd conftest
    mkdir out
-   printf "$lt_simple_compile_test_code" > conftest.$ac_ext
+   echo "$lt_simple_compile_test_code" > conftest.$ac_ext
 
    lt_compiler_flag="-o out/conftest2.$ac_objext"
    # Insert the option either (1) after the last *FLAGS variable, or
@@ -950,7 +1134,7 @@ AC_CACHE_CHECK([if $compiler supports -c -o file.$ac_objext],
    # Note that $ac_compile itself does not contain backslashes and begins
    # with a dollar sign (not a hyphen), so the echo should work correctly.
    lt_compile=`echo "$ac_compile" | $SED \
-   -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
+   -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
    -e 's: [[^ ]]*conftest\.: $lt_compiler_flag&:; t' \
    -e 's:$: $lt_compiler_flag:'`
    (eval echo "\"\$as_me:__oline__: $lt_compile\"" >&AS_MESSAGE_LOG_FD)
@@ -962,11 +1146,13 @@ AC_CACHE_CHECK([if $compiler supports -c -o file.$ac_objext],
    then
      # The compiler can only warn and ignore the option if not recognized
      # So say no if there are warnings
-     if test ! -s out/conftest.err; then
+     $echo "X$_lt_compiler_boilerplate" | $Xsed -e '/^$/d' > out/conftest.exp
+     $SED '/^$/d; /^ *+/d' out/conftest.err >out/conftest.er2
+     if test ! -s out/conftest.er2 || diff out/conftest.exp out/conftest.er2 >/dev/null; then
        _LT_AC_TAGVAR(lt_cv_prog_compiler_c_o, $1)=yes
      fi
    fi
-   chmod u+w .
+   chmod u+w . 2>&AS_MESSAGE_LOG_FD
    $rm conftest*
    # SGI C++ compiler will create directory out/ii_files/ for
    # template instantiation
@@ -1080,6 +1266,7 @@ else
    darwin*)
        if test -n "$STRIP" ; then
          striplib="$STRIP -x"
+         old_striplib="$STRIP -S"
          AC_MSG_RESULT([yes])
        else
   AC_MSG_RESULT([no])
@@ -1097,7 +1284,8 @@ fi
 # -----------------------------
 # PORTME Fill in your ld.so characteristics
 AC_DEFUN([AC_LIBTOOL_SYS_DYNAMIC_LINKER],
-[AC_MSG_CHECKING([dynamic linker characteristics])
+[AC_REQUIRE([LT_AC_PROG_SED])dnl
+AC_MSG_CHECKING([dynamic linker characteristics])
 library_names_spec=
 libname_spec='lib$name'
 soname_spec=
@@ -1111,20 +1299,58 @@ shlibpath_overrides_runpath=unknown
 version_type=none
 dynamic_linker="$host_os ld.so"
 sys_lib_dlsearch_path_spec="/lib /usr/lib"
+m4_if($1,[],[
 if test "$GCC" = yes; then
-  sys_lib_search_path_spec=`$CC -print-search-dirs | grep "^libraries:" | $SED -e "s/^libraries://" -e "s,=/,/,g"`
-  if echo "$sys_lib_search_path_spec" | grep ';' >/dev/null ; then
+  case $host_os in
+    darwin*) lt_awk_arg="/^libraries:/,/LR/" ;;
+    *) lt_awk_arg="/^libraries:/" ;;
+  esac
+  lt_search_path_spec=`$CC -print-search-dirs | awk $lt_awk_arg | $SED -e "s/^libraries://" -e "s,=/,/,g"`
+  if echo "$lt_search_path_spec" | grep ';' >/dev/null ; then
     # if the path contains ";" then we assume it to be the separator
     # otherwise default to the standard path separator (i.e. ":") - it is
     # assumed that no part of a normal pathname contains ";" but that should
     # okay in the real world where ";" in dirpaths is itself problematic.
-    sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" | $SED -e 's/;/ /g'`
+    lt_search_path_spec=`echo "$lt_search_path_spec" | $SED -e 's/;/ /g'`
   else
-    sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" | $SED  -e "s/$PATH_SEPARATOR/ /g"`
+    lt_search_path_spec=`echo "$lt_search_path_spec" | $SED  -e "s/$PATH_SEPARATOR/ /g"`
   fi
+  # Ok, now we have the path, separated by spaces, we can step through it
+  # and add multilib dir if necessary.
+  lt_tmp_lt_search_path_spec=
+  lt_multi_os_dir=`$CC $CPPFLAGS $CFLAGS $LDFLAGS -print-multi-os-directory 2>/dev/null`
+  for lt_sys_path in $lt_search_path_spec; do
+    if test -d "$lt_sys_path/$lt_multi_os_dir"; then
+      lt_tmp_lt_search_path_spec="$lt_tmp_lt_search_path_spec $lt_sys_path/$lt_multi_os_dir"
+    else
+      test -d "$lt_sys_path" && \
+	lt_tmp_lt_search_path_spec="$lt_tmp_lt_search_path_spec $lt_sys_path"
+    fi
+  done
+  lt_search_path_spec=`echo $lt_tmp_lt_search_path_spec | awk '
+BEGIN {RS=" "; FS="/|\n";} {
+  lt_foo="";
+  lt_count=0;
+  for (lt_i = NF; lt_i > 0; lt_i--) {
+    if ($lt_i != "" && $lt_i != ".") {
+      if ($lt_i == "..") {
+        lt_count++;
+      } else {
+        if (lt_count == 0) {
+          lt_foo="/" $lt_i lt_foo;
+        } else {
+          lt_count--;
+        }
+      }
+    }
+  }
+  if (lt_foo != "") { lt_freq[[lt_foo]]++; }
+  if (lt_freq[[lt_foo]] == 1) { print lt_foo; }
+}'`
+  sys_lib_search_path_spec=`echo $lt_search_path_spec`
 else
   sys_lib_search_path_spec="/lib /usr/lib /usr/local/lib"
-fi
+fi])
 need_lib_prefix=unknown
 hardcode_into_libs=no
 
@@ -1142,7 +1368,7 @@ aix3*)
   soname_spec='${libname}${release}${shared_ext}$major'
   ;;
 
-aix4* | aix5*)
+aix[[4-9]]*)
   version_type=linux
   need_lib_prefix=no
   need_version=no
@@ -1226,7 +1452,8 @@ cygwin* | mingw* | pw32*)
       dlpath=`$SHELL 2>&1 -c '\''. $dir/'\''\${base_file}'\''i;echo \$dlname'\''`~
       dldir=$destdir/`dirname \$dlpath`~
       test -d \$dldir || mkdir -p \$dldir~
-      $install_prog $dir/$dlname \$dldir/$dlname'
+      $install_prog $dir/$dlname \$dldir/$dlname~
+      chmod a+x \$dldir/$dlname'
     postuninstall_cmds='dldll=`$SHELL 2>&1 -c '\''. $file; echo \$dlname'\''`~
       dlpath=$dir/\$dldll~
        $rm \$dlpath'
@@ -1256,7 +1483,7 @@ cygwin* | mingw* | pw32*)
       ;;
     pw32*)
       # pw32 DLLs use 'pw' prefix rather than 'lib'
-      library_names_spec='`echo ${libname} | sed -e 's/^lib/pw/'``echo ${release} | $SED -e 's/[.]/-/g'`${versuffix}${shared_ext}'
+      library_names_spec='`echo ${libname} | sed -e 's/^lib/pw/'``echo ${release} | $SED -e 's/[[.]]/-/g'`${versuffix}${shared_ext}'
       ;;
     esac
     ;;
@@ -1279,13 +1506,9 @@ darwin* | rhapsody*)
   soname_spec='${libname}${release}${major}$shared_ext'
   shlibpath_overrides_runpath=yes
   shlibpath_var=DYLD_LIBRARY_PATH
-  shrext_cmds='$(test .$module = .yes && echo .so || echo .dylib)'
-  # Apple's gcc prints 'gcc -print-search-dirs' doesn't operate the same.
-  if test "$GCC" = yes; then
-    sys_lib_search_path_spec=`$CC -print-search-dirs | tr "\n" "$PATH_SEPARATOR" | sed -e 's/libraries:/@libraries:/' | tr "@" "\n" | grep "^libraries:" | sed -e "s/^libraries://" -e "s,=/,/,g" -e "s,$PATH_SEPARATOR, ,g" -e "s,.*,& /lib /usr/lib /usr/local/lib,g"`
-  else
-    sys_lib_search_path_spec='/lib /usr/lib /usr/local/lib'
-  fi
+  shrext_cmds='`test .$module = .yes && echo .so || echo .dylib`'
+  m4_if([$1], [],[
+  sys_lib_search_path_spec="$sys_lib_search_path_spec /usr/local/lib"]) 
   sys_lib_dlsearch_path_spec='/usr/local/lib /lib /usr/lib'
   ;;
 
@@ -1302,20 +1525,17 @@ freebsd1*)
   dynamic_linker=no
   ;;
 
-kfreebsd*-gnu)
-  version_type=linux
-  need_lib_prefix=no
-  need_version=no
-  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${shared_ext}'
-  soname_spec='${libname}${release}${shared_ext}$major'
-  shlibpath_var=LD_LIBRARY_PATH
-  shlibpath_overrides_runpath=no
-  hardcode_into_libs=yes
-  dynamic_linker='GNU ld.so'
-  ;;
-
-freebsd*)
-  objformat=`test -x /usr/bin/objformat && /usr/bin/objformat || echo aout`
+freebsd* | dragonfly*)
+  # DragonFly does not have aout.  When/if they implement a new
+  # versioning mechanism, adjust this.
+  if test -x /usr/bin/objformat; then
+    objformat=`/usr/bin/objformat`
+  else
+    case $host_os in
+    freebsd[[123]]*) objformat=aout ;;
+    *) objformat=elf ;;
+    esac
+  fi
   version_type=freebsd-$objformat
   case $version_type in
     freebsd-elf*)
@@ -1333,14 +1553,19 @@ freebsd*)
   freebsd2*)
     shlibpath_overrides_runpath=yes
     ;;
-  freebsd3.[01]* | freebsdelf3.[01]*)
+  freebsd3.[[01]]* | freebsdelf3.[[01]]*)
     shlibpath_overrides_runpath=yes
     hardcode_into_libs=yes
     ;;
-  *) # from 3.2 on
+  freebsd3.[[2-9]]* | freebsdelf3.[[2-9]]* | \
+  freebsd4.[[0-5]] | freebsdelf4.[[0-5]] | freebsd4.1.1 | freebsdelf4.1.1)
     shlibpath_overrides_runpath=no
     hardcode_into_libs=yes
     ;;
+  *) # from 4.6 on, and DragonFly
+    shlibpath_overrides_runpath=yes
+    hardcode_into_libs=yes
+    ;;
   esac
   ;;
 
@@ -1360,7 +1585,7 @@ hpux9* | hpux10* | hpux11*)
   version_type=sunos
   need_lib_prefix=no
   need_version=no
-  case "$host_cpu" in
+  case $host_cpu in
   ia64*)
     shrext_cmds='.so'
     hardcode_into_libs=yes
@@ -1400,6 +1625,18 @@ hpux9* | hpux10* | hpux11*)
   postinstall_cmds='chmod 555 $lib'
   ;;
 
+interix[[3-9]]*)
+  version_type=linux
+  need_lib_prefix=no
+  need_version=no
+  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${shared_ext}'
+  soname_spec='${libname}${release}${shared_ext}$major'
+  dynamic_linker='Interix 3.x ld.so.1 (PE, like ELF)'
+  shlibpath_var=LD_LIBRARY_PATH
+  shlibpath_overrides_runpath=no
+  hardcode_into_libs=yes
+  ;;
+
 irix5* | irix6* | nonstopux*)
   case $host_os in
     nonstopux*) version_type=nonstopux ;;
@@ -1443,7 +1680,7 @@ linux*oldld* | linux*aout* | linux*coff*)
   ;;
 
 # This must be Linux ELF.
-linux*)
+linux* | k*bsd*-gnu)
   version_type=linux
   need_lib_prefix=no
   need_version=no
@@ -1459,7 +1696,7 @@ linux*)
 
   # Append ld.so.conf contents to the search path
   if test -f /etc/ld.so.conf; then
-    lt_ld_extra=`$SED -e 's/[:,\t]/ /g;s/=[^=]*$//;s/=[^= ]* / /g' /etc/ld.so.conf | tr '\n' ' '`
+    lt_ld_extra=`awk '/^include / { system(sprintf("cd /etc; cat %s 2>/dev/null", \[$]2)); skip = 1; } { if (!skip) print \[$]0; skip = 0; }' < /etc/ld.so.conf | $SED -e 's/#.*//;/^[ 	]*hwcap[ 	]/d;s/[:,	]/ /g;s/=[^=]*$//;s/=[^= ]* / /g;/^$/d' | tr '\n' ' '`
     sys_lib_dlsearch_path_spec="/lib /usr/lib $lt_ld_extra"
   fi
 
@@ -1472,18 +1709,6 @@ linux*)
   dynamic_linker='GNU/Linux ld.so'
   ;;
 
-knetbsd*-gnu)
-  version_type=linux
-  need_lib_prefix=no
-  need_version=no
-  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${shared_ext}'
-  soname_spec='${libname}${release}${shared_ext}$major'
-  shlibpath_var=LD_LIBRARY_PATH
-  shlibpath_overrides_runpath=no
-  hardcode_into_libs=yes
-  dynamic_linker='GNU ld.so'
-  ;;
-
 netbsd*)
   version_type=sunos
   need_lib_prefix=no
@@ -1521,8 +1746,13 @@ nto-qnx*)
 
 openbsd*)
   version_type=sunos
+  sys_lib_dlsearch_path_spec="/usr/lib"
   need_lib_prefix=no
-  need_version=no
+  # Some older versions of OpenBSD (3.3 at least) *do* need versioned libs.
+  case $host_os in
+    openbsd3.3 | openbsd3.3.*) need_version=yes ;;
+    *)                         need_version=no  ;;
+  esac
   library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${shared_ext}$versuffix'
   finish_cmds='PATH="\$PATH:/sbin" ldconfig -m $libdir'
   shlibpath_var=LD_LIBRARY_PATH
@@ -1560,11 +1790,8 @@ osf3* | osf4* | osf5*)
   sys_lib_dlsearch_path_spec="$sys_lib_search_path_spec"
   ;;
 
-sco3.2v5*)
-  version_type=osf
-  soname_spec='${libname}${release}${shared_ext}$major'
-  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
-  shlibpath_var=LD_LIBRARY_PATH
+rdos*)
+  dynamic_linker=no
   ;;
 
 solaris*)
@@ -1592,7 +1819,7 @@ sunos4*)
   need_version=yes
   ;;
 
-sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+sysv4 | sysv4.3*)
   version_type=linux
   library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
   soname_spec='${libname}${release}${shared_ext}$major'
@@ -1625,6 +1852,29 @@ sysv4*MP*)
   fi
   ;;
 
+sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
+  version_type=freebsd-elf
+  need_lib_prefix=no
+  need_version=no
+  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext} $libname${shared_ext}'
+  soname_spec='${libname}${release}${shared_ext}$major'
+  shlibpath_var=LD_LIBRARY_PATH
+  hardcode_into_libs=yes
+  if test "$with_gnu_ld" = yes; then
+    sys_lib_search_path_spec='/usr/local/lib /usr/gnu/lib /usr/ccs/lib /usr/lib /lib'
+    shlibpath_overrides_runpath=no
+  else
+    sys_lib_search_path_spec='/usr/ccs/lib /usr/lib'
+    shlibpath_overrides_runpath=yes
+    case $host_os in
+      sco3.2v5*)
+        sys_lib_search_path_spec="$sys_lib_search_path_spec /lib"
+	;;
+    esac
+  fi
+  sys_lib_dlsearch_path_spec='/usr/lib'
+  ;;
+
 uts4*)
   version_type=linux
   library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
@@ -1638,13 +1888,26 @@ uts4*)
 esac
 AC_MSG_RESULT([$dynamic_linker])
 test "$dynamic_linker" = no && can_build_shared=no
+
+AC_CACHE_VAL([lt_cv_sys_lib_search_path_spec],
+[lt_cv_sys_lib_search_path_spec="$sys_lib_search_path_spec"])
+sys_lib_search_path_spec="$lt_cv_sys_lib_search_path_spec"
+AC_CACHE_VAL([lt_cv_sys_lib_dlsearch_path_spec],
+[lt_cv_sys_lib_dlsearch_path_spec="$sys_lib_dlsearch_path_spec"])
+sys_lib_dlsearch_path_spec="$lt_cv_sys_lib_dlsearch_path_spec"
+
+variables_saved_for_relink="PATH $shlibpath_var $runpath_var"
+if test "$GCC" = yes; then
+  variables_saved_for_relink="$variables_saved_for_relink GCC_EXEC_PREFIX COMPILER_PATH LIBRARY_PATH"
+fi
 ])# AC_LIBTOOL_SYS_DYNAMIC_LINKER
 
 
 # _LT_AC_TAGCONFIG
 # ----------------
 AC_DEFUN([_LT_AC_TAGCONFIG],
-[AC_ARG_WITH([tags],
+[AC_REQUIRE([LT_AC_PROG_SED])dnl
+AC_ARG_WITH([tags],
     [AC_HELP_STRING([--with-tags@<:@=TAGS@:>@],
         [include additional configurations @<:@automatic@:>@])],
     [tagnames="$withval"])
@@ -1662,6 +1925,9 @@ if test -f "$ltmain" && test -n "$tagnames"; then
       AC_MSG_WARN([using `LTCC=$LTCC', extracted from `$ofile'])
     fi
   fi
+  if test -z "$LTCFLAGS"; then
+    eval "`$SHELL ${ofile} --config | grep '^LTCFLAGS='`"
+  fi
 
   # Extract list of available tagged configurations in $ofile.
   # Note that this assumes the entire list is on one line.
@@ -1689,7 +1955,7 @@ if test -f "$ltmain" && test -n "$tagnames"; then
       case $tagname in
       CXX)
 	if test -n "$CXX" && ( test "X$CXX" != "Xno" &&
-	    ( (test "X$CXX" = "Xg++" && `g++ -v >/dev/null 2>&1` ) || 
+	    ( (test "X$CXX" = "Xg++" && `g++ -v >/dev/null 2>&1` ) ||
 	    (test "X$CXX" != "Xg++"))) ; then
 	  AC_LIBTOOL_LANG_CXX_CONFIG
 	else
@@ -1752,7 +2018,7 @@ AC_DEFUN([AC_LIBTOOL_DLOPEN],
 
 # AC_LIBTOOL_WIN32_DLL
 # --------------------
-# declare package support for building win32 dll's
+# declare package support for building win32 DLLs
 AC_DEFUN([AC_LIBTOOL_WIN32_DLL],
 [AC_BEFORE([$0], [AC_LIBTOOL_SETUP])
 ])# AC_LIBTOOL_WIN32_DLL
@@ -1790,7 +2056,7 @@ AC_ARG_ENABLE([shared],
 
 # AC_DISABLE_SHARED
 # -----------------
-#- set the default shared flag to --disable-shared
+# set the default shared flag to --disable-shared
 AC_DEFUN([AC_DISABLE_SHARED],
 [AC_BEFORE([$0],[AC_LIBTOOL_SETUP])dnl
 AC_ENABLE_SHARED(no)
@@ -1902,7 +2168,7 @@ m4_ifndef([AC_PROG_EGREP], [AC_DEFUN([AC_PROG_EGREP],
 
 # AC_PATH_TOOL_PREFIX
 # -------------------
-# find a file program which can recognise shared library
+# find a file program which can recognize shared library
 AC_DEFUN([AC_PATH_TOOL_PREFIX],
 [AC_REQUIRE([AC_PROG_EGREP])dnl
 AC_MSG_CHECKING([for $1])
@@ -1926,7 +2192,7 @@ dnl not every word.  This closes a longstanding sh security hole.
       if test -n "$file_magic_test_file"; then
 	case $deplibs_check_method in
 	"file_magic "*)
-	  file_magic_regex="`expr \"$deplibs_check_method\" : \"file_magic \(.*\)\"`"
+	  file_magic_regex=`expr "$deplibs_check_method" : "file_magic \(.*\)"`
 	  MAGIC_CMD="$lt_cv_path_MAGIC_CMD"
 	  if eval $file_magic_cmd \$file_magic_test_file 2> /dev/null |
 	    $EGREP "$file_magic_regex" > /dev/null; then
@@ -1965,7 +2231,7 @@ fi
 
 # AC_PATH_MAGIC
 # -------------
-# find a file program which can recognise a shared library
+# find a file program which can recognize a shared library
 AC_DEFUN([AC_PATH_MAGIC],
 [AC_PATH_TOOL_PREFIX(${ac_tool_prefix}file, /usr/bin$PATH_SEPARATOR$PATH)
 if test -z "$lt_cv_path_MAGIC_CMD"; then
@@ -2036,7 +2302,7 @@ AC_CACHE_VAL(lt_cv_path_LD,
     if test -f "$ac_dir/$ac_prog" || test -f "$ac_dir/$ac_prog$ac_exeext"; then
       lt_cv_path_LD="$ac_dir/$ac_prog"
       # Check to see if the program is GNU ld.  I'd rather use --version,
-      # but apparently some GNU ld's only accept -v.
+      # but apparently some variants of GNU ld only accept -v.
       # Break only if it was the GNU/non-GNU ld that we prefer.
       case `"$lt_cv_path_LD" -v 2>&1 </dev/null` in
       *GNU* | *'with BFD'*)
@@ -2068,7 +2334,7 @@ AC_PROG_LD_GNU
 AC_DEFUN([AC_PROG_LD_GNU],
 [AC_REQUIRE([AC_PROG_EGREP])dnl
 AC_CACHE_CHECK([if the linker ($LD) is GNU ld], lt_cv_prog_gnu_ld,
-[# I'd rather use --version here, but apparently some GNU ld's only accept -v.
+[# I'd rather use --version here, but apparently some GNU lds only accept -v.
 case `$LD -v 2>&1 </dev/null` in
 *GNU* | *'with BFD'*)
   lt_cv_prog_gnu_ld=yes
@@ -2098,7 +2364,7 @@ reload_cmds='$LD$reload_flag -o $output$reload_objs'
 case $host_os in
   darwin*)
     if test "$GCC" = yes; then
-      reload_cmds='$CC -nostdlib ${wl}-r -o $output$reload_objs'
+      reload_cmds='$LTCC $LTCFLAGS -nostdlib ${wl}-r -o $output$reload_objs'
     else
       reload_cmds='$LD$reload_flag -o $output$reload_objs'
     fi
@@ -2112,7 +2378,7 @@ esac
 # how to check for library dependencies
 #  -- PORTME fill in with the dynamic library characteristics
 AC_DEFUN([AC_DEPLIBS_CHECK_METHOD],
-[AC_CACHE_CHECK([how to recognise dependent libraries],
+[AC_CACHE_CHECK([how to recognize dependent libraries],
 lt_cv_deplibs_check_method,
 [lt_cv_file_magic_cmd='$MAGIC_CMD'
 lt_cv_file_magic_test_file=
@@ -2129,7 +2395,7 @@ lt_cv_deplibs_check_method='unknown'
 # whether `pass_all' will *always* work, you probably want this one.
 
 case $host_os in
-aix4* | aix5*)
+aix[[4-9]]*)
   lt_cv_deplibs_check_method=pass_all
   ;;
 
@@ -2151,22 +2417,28 @@ cygwin*)
 
 mingw* | pw32*)
   # Base MSYS/MinGW do not provide the 'file' command needed by
-  # func_win32_libid shell function, so use a weaker test based on 'objdump'.
-  lt_cv_deplibs_check_method='file_magic file format pei*-i386(.*architecture: i386)?'
-  lt_cv_file_magic_cmd='$OBJDUMP -f'
+  # func_win32_libid shell function, so use a weaker test based on 'objdump',
+  # unless we find 'file', for example because we are cross-compiling.
+  if ( file / ) >/dev/null 2>&1; then
+    lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL'
+    lt_cv_file_magic_cmd='func_win32_libid'
+  else
+    lt_cv_deplibs_check_method='file_magic file format pei*-i386(.*architecture: i386)?'
+    lt_cv_file_magic_cmd='$OBJDUMP -f'
+  fi
   ;;
 
 darwin* | rhapsody*)
   lt_cv_deplibs_check_method=pass_all
   ;;
 
-freebsd* | kfreebsd*-gnu)
+freebsd* | dragonfly*)
   if echo __ELF__ | $CC -E - | grep __ELF__ > /dev/null; then
     case $host_cpu in
     i*86 )
       # Not sure whether the presence of OpenBSD here was a mistake.
       # Let's accept both of them until this is cleared up.
-      lt_cv_deplibs_check_method='file_magic (FreeBSD|OpenBSD)/i[[3-9]]86 (compact )?demand paged shared library'
+      lt_cv_deplibs_check_method='file_magic (FreeBSD|OpenBSD|DragonFly)/i[[3-9]]86 (compact )?demand paged shared library'
       lt_cv_file_magic_cmd=/usr/bin/file
       lt_cv_file_magic_test_file=`echo /usr/lib/libc.so.*`
       ;;
@@ -2182,7 +2454,7 @@ gnu*)
 
 hpux10.20* | hpux11*)
   lt_cv_file_magic_cmd=/usr/bin/file
-  case "$host_cpu" in
+  case $host_cpu in
   ia64*)
     lt_cv_deplibs_check_method='file_magic (s[[0-9]][[0-9]][[0-9]]|ELF-[[0-9]][[0-9]]) shared object file - IA64'
     lt_cv_file_magic_test_file=/usr/lib/hpux32/libc.so
@@ -2198,6 +2470,11 @@ hpux10.20* | hpux11*)
   esac
   ;;
 
+interix[[3-9]]*)
+  # PIC code is broken on Interix 3.x, that's why |\.a not |_pic\.a here
+  lt_cv_deplibs_check_method='match_pattern /lib[[^/]]+(\.so|\.a)$'
+  ;;
+
 irix5* | irix6* | nonstopux*)
   case $LD in
   *-32|*"-32 ") libmagic=32-bit;;
@@ -2209,7 +2486,7 @@ irix5* | irix6* | nonstopux*)
   ;;
 
 # This must be Linux ELF.
-linux*)
+linux* | k*bsd*-gnu)
   lt_cv_deplibs_check_method=pass_all
   ;;
 
@@ -2243,7 +2520,7 @@ osf3* | osf4* | osf5*)
   lt_cv_deplibs_check_method=pass_all
   ;;
 
-sco3.2v5*)
+rdos*)
   lt_cv_deplibs_check_method=pass_all
   ;;
 
@@ -2251,7 +2528,7 @@ solaris*)
   lt_cv_deplibs_check_method=pass_all
   ;;
 
-sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+sysv4 | sysv4.3*)
   case $host_vendor in
   motorola)
     lt_cv_deplibs_check_method='file_magic ELF [[0-9]][[0-9]]*-bit [[ML]]SB (shared object|dynamic lib) M[[0-9]][[0-9]]* Version [[0-9]]'
@@ -2272,10 +2549,13 @@ sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
   siemens)
     lt_cv_deplibs_check_method=pass_all
     ;;
+  pc)
+    lt_cv_deplibs_check_method=pass_all
+    ;;
   esac
   ;;
 
-sysv5OpenUNIX8* | sysv5UnixWare7* | sysv5uw[[78]]* | unixware7* | sysv4*uw2*)
+sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
   lt_cv_deplibs_check_method=pass_all
   ;;
 esac
@@ -2295,36 +2575,43 @@ AC_DEFUN([AC_PROG_NM],
   # Let the user override the test.
   lt_cv_path_NM="$NM"
 else
-  lt_save_ifs="$IFS"; IFS=$PATH_SEPARATOR
-  for ac_dir in $PATH /usr/ccs/bin /usr/ucb /bin; do
-    IFS="$lt_save_ifs"
-    test -z "$ac_dir" && ac_dir=.
-    tmp_nm="$ac_dir/${ac_tool_prefix}nm"
-    if test -f "$tmp_nm" || test -f "$tmp_nm$ac_exeext" ; then
-      # Check to see if the nm accepts a BSD-compat flag.
-      # Adding the `sed 1q' prevents false positives on HP-UX, which says:
-      #   nm: unknown option "B" ignored
-      # Tru64's nm complains that /dev/null is an invalid object file
-      case `"$tmp_nm" -B /dev/null 2>&1 | sed '1q'` in
-      */dev/null* | *'Invalid file or object type'*)
-	lt_cv_path_NM="$tmp_nm -B"
-	break
-        ;;
-      *)
-	case `"$tmp_nm" -p /dev/null 2>&1 | sed '1q'` in
-	*/dev/null*)
-	  lt_cv_path_NM="$tmp_nm -p"
+  lt_nm_to_check="${ac_tool_prefix}nm"
+  if test -n "$ac_tool_prefix" && test "$build" = "$host"; then
+    lt_nm_to_check="$lt_nm_to_check nm"
+  fi
+  for lt_tmp_nm in $lt_nm_to_check; do
+    lt_save_ifs="$IFS"; IFS=$PATH_SEPARATOR
+    for ac_dir in $PATH /usr/ccs/bin/elf /usr/ccs/bin /usr/ucb /bin; do
+      IFS="$lt_save_ifs"
+      test -z "$ac_dir" && ac_dir=.
+      tmp_nm="$ac_dir/$lt_tmp_nm"
+      if test -f "$tmp_nm" || test -f "$tmp_nm$ac_exeext" ; then
+	# Check to see if the nm accepts a BSD-compat flag.
+	# Adding the `sed 1q' prevents false positives on HP-UX, which says:
+	#   nm: unknown option "B" ignored
+	# Tru64's nm complains that /dev/null is an invalid object file
+	case `"$tmp_nm" -B /dev/null 2>&1 | sed '1q'` in
+	*/dev/null* | *'Invalid file or object type'*)
+	  lt_cv_path_NM="$tmp_nm -B"
 	  break
 	  ;;
 	*)
-	  lt_cv_path_NM=${lt_cv_path_NM="$tmp_nm"} # keep the first match, but
-	  continue # so that we can try to find one that supports BSD flags
+	  case `"$tmp_nm" -p /dev/null 2>&1 | sed '1q'` in
+	  */dev/null*)
+	    lt_cv_path_NM="$tmp_nm -p"
+	    break
+	    ;;
+	  *)
+	    lt_cv_path_NM=${lt_cv_path_NM="$tmp_nm"} # keep the first match, but
+	    continue # so that we can try to find one that supports BSD flags
+	    ;;
+	  esac
 	  ;;
 	esac
-      esac
-    fi
+      fi
+    done
+    IFS="$lt_save_ifs"
   done
-  IFS="$lt_save_ifs"
   test -z "$lt_cv_path_NM" && lt_cv_path_NM=nm
 fi])
 NM="$lt_cv_path_NM"
@@ -2356,13 +2643,13 @@ esac
 # -----------------------------------
 # sets LIBLTDL to the link flags for the libltdl convenience library and
 # LTDLINCL to the include flags for the libltdl header and adds
-# --enable-ltdl-convenience to the configure arguments.  Note that LIBLTDL
-# and LTDLINCL are not AC_SUBSTed, nor is AC_CONFIG_SUBDIRS called.  If
-# DIRECTORY is not provided, it is assumed to be `libltdl'.  LIBLTDL will
-# be prefixed with '${top_builddir}/' and LTDLINCL will be prefixed with
-# '${top_srcdir}/' (note the single quotes!).  If your package is not
-# flat and you're not using automake, define top_builddir and
-# top_srcdir appropriately in the Makefiles.
+# --enable-ltdl-convenience to the configure arguments.  Note that
+# AC_CONFIG_SUBDIRS is not called here.  If DIRECTORY is not provided,
+# it is assumed to be `libltdl'.  LIBLTDL will be prefixed with
+# '${top_builddir}/' and LTDLINCL will be prefixed with '${top_srcdir}/'
+# (note the single quotes!).  If your package is not flat and you're not
+# using automake, define top_builddir and top_srcdir appropriately in
+# the Makefiles.
 AC_DEFUN([AC_LIBLTDL_CONVENIENCE],
 [AC_BEFORE([$0],[AC_LIBTOOL_SETUP])dnl
   case $enable_ltdl_convenience in
@@ -2381,13 +2668,13 @@ AC_DEFUN([AC_LIBLTDL_CONVENIENCE],
 # -----------------------------------
 # sets LIBLTDL to the link flags for the libltdl installable library and
 # LTDLINCL to the include flags for the libltdl header and adds
-# --enable-ltdl-install to the configure arguments.  Note that LIBLTDL
-# and LTDLINCL are not AC_SUBSTed, nor is AC_CONFIG_SUBDIRS called.  If
-# DIRECTORY is not provided and an installed libltdl is not found, it is
-# assumed to be `libltdl'.  LIBLTDL will be prefixed with '${top_builddir}/'
-# and LTDLINCL will be prefixed with '${top_srcdir}/' (note the single
-# quotes!).  If your package is not flat and you're not using automake,
-# define top_builddir and top_srcdir appropriately in the Makefiles.
+# --enable-ltdl-install to the configure arguments.  Note that
+# AC_CONFIG_SUBDIRS is not called here.  If DIRECTORY is not provided,
+# and an installed libltdl is not found, it is assumed to be `libltdl'.
+# LIBLTDL will be prefixed with '${top_builddir}/'# and LTDLINCL with
+# '${top_srcdir}/' (note the single quotes!).  If your package is not
+# flat and you're not using automake, define top_builddir and top_srcdir
+# appropriately in the Makefiles.
 # In the future, this macro may have to be called after AC_PROG_LIBTOOL.
 AC_DEFUN([AC_LIBLTDL_INSTALLABLE],
 [AC_BEFORE([$0],[AC_LIBTOOL_SETUP])dnl
@@ -2430,12 +2717,12 @@ _LT_AC_SHELL_INIT([tagnames=${tagnames+${tagnames},}CXX])
 ])# _LT_AC_LANG_CXX
 
 # _LT_AC_PROG_CXXCPP
-# ---------------
+# ------------------
 AC_DEFUN([_LT_AC_PROG_CXXCPP],
 [
 AC_REQUIRE([AC_PROG_CXX])
 if test -n "$CXX" && ( test "X$CXX" != "Xno" &&
-    ( (test "X$CXX" = "Xg++" && `g++ -v >/dev/null 2>&1` ) || 
+    ( (test "X$CXX" = "Xg++" && `g++ -v >/dev/null 2>&1` ) ||
     (test "X$CXX" != "Xg++"))) ; then
   AC_PROG_CXXCPP
 fi
@@ -2479,7 +2766,7 @@ _LT_AC_SHELL_INIT([tagnames=${tagnames+${tagnames},}GCJ])
 
 
 # AC_LIBTOOL_RC
-# --------------
+# -------------
 # enable support for Windows resource files
 AC_DEFUN([AC_LIBTOOL_RC],
 [AC_REQUIRE([LT_AC_PROG_RC])
@@ -2505,43 +2792,16 @@ objext=o
 _LT_AC_TAGVAR(objext, $1)=$objext
 
 # Code to be used in simple compile tests
-lt_simple_compile_test_code="int some_variable = 0;\n"
+lt_simple_compile_test_code="int some_variable = 0;"
 
 # Code to be used in simple link tests
-lt_simple_link_test_code='int main(){return(0);}\n'
+lt_simple_link_test_code='int main(){return(0);}'
 
 _LT_AC_SYS_COMPILER
 
-#
-# Check for any special shared library compilation flags.
-#
-_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)=
-if test "$GCC" = no; then
-  case $host_os in
-  sco3.2v5*)
-    _LT_AC_TAGVAR(lt_prog_cc_shlib, $1)='-belf'
-    ;;
-  esac
-fi
-if test -n "$_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)"; then
-  AC_MSG_WARN([`$CC' requires `$_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)' to build shared libraries])
-  if echo "$old_CC $old_CFLAGS " | grep "[[ 	]]$_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)[[ 	]]" >/dev/null; then :
-  else
-    AC_MSG_WARN([add `$_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)' to the CC or CFLAGS env variable and reconfigure])
-    _LT_AC_TAGVAR(lt_cv_prog_cc_can_build_shared, $1)=no
-  fi
-fi
-
-
-#
-# Check to make sure the static flag actually works.
-#
-AC_LIBTOOL_LINKER_OPTION([if $compiler static flag $_LT_AC_TAGVAR(lt_prog_compiler_static, $1) works],
-  _LT_AC_TAGVAR(lt_prog_compiler_static_works, $1),
-  $_LT_AC_TAGVAR(lt_prog_compiler_static, $1),
-  [],
-  [_LT_AC_TAGVAR(lt_prog_compiler_static, $1)=])
-
+# save warnings/boilerplate of simple test code
+_LT_COMPILER_BOILERPLATE
+_LT_LINKER_BOILERPLATE
 
 ## CAVEAT EMPTOR:
 ## There is no encapsulation within the following macros, do not change
@@ -2555,9 +2815,9 @@ AC_LIBTOOL_PROG_LD_SHLIBS($1)
 AC_LIBTOOL_SYS_DYNAMIC_LINKER($1)
 AC_LIBTOOL_PROG_LD_HARDCODE_LIBPATH($1)
 AC_LIBTOOL_SYS_LIB_STRIP
-AC_LIBTOOL_DLOPEN_SELF($1)
+AC_LIBTOOL_DLOPEN_SELF
 
-# Report which libraries types will actually be built
+# Report which library types will actually be built
 AC_MSG_CHECKING([if libtool supports shared libraries])
 AC_MSG_RESULT([$can_build_shared])
 
@@ -2566,7 +2826,7 @@ test "$can_build_shared" = "no" && enable_shared=no
 
 # On AIX, shared libraries and static libraries use the same namespace, and
 # are all built from PIC.
-case "$host_os" in
+case $host_os in
 aix3*)
   test "$enable_shared" = yes && enable_static=no
   if test -n "$RANLIB"; then
@@ -2575,7 +2835,7 @@ aix3*)
   fi
   ;;
 
-aix4* | aix5*)
+aix[[4-9]]*)
   if test "$host_cpu" != ia64 && test "$aix_use_runtimelinking" = no ; then
     test "$enable_shared" = yes && enable_static=no
   fi
@@ -2616,6 +2876,7 @@ _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)=
 _LT_AC_TAGVAR(hardcode_libdir_flag_spec_ld, $1)=
 _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=
 _LT_AC_TAGVAR(hardcode_minus_L, $1)=no
+_LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=unsupported
 _LT_AC_TAGVAR(hardcode_automatic, $1)=no
 _LT_AC_TAGVAR(module_cmds, $1)=
 _LT_AC_TAGVAR(module_expsym_cmds, $1)=
@@ -2631,23 +2892,28 @@ _LT_AC_TAGVAR(postdep_objects, $1)=
 _LT_AC_TAGVAR(predeps, $1)=
 _LT_AC_TAGVAR(postdeps, $1)=
 _LT_AC_TAGVAR(compiler_lib_search_path, $1)=
+_LT_AC_TAGVAR(compiler_lib_search_dirs, $1)=
 
 # Source file extension for C++ test sources.
-ac_ext=cc
+ac_ext=cpp
 
 # Object file extension for compiled C++ test sources.
 objext=o
 _LT_AC_TAGVAR(objext, $1)=$objext
 
 # Code to be used in simple compile tests
-lt_simple_compile_test_code="int some_variable = 0;\n"
+lt_simple_compile_test_code="int some_variable = 0;"
 
 # Code to be used in simple link tests
-lt_simple_link_test_code='int main(int, char *[]) { return(0); }\n'
+lt_simple_link_test_code='int main(int, char *[[]]) { return(0); }'
 
 # ltmain only uses $CC for tagged configurations so make sure $CC is set.
 _LT_AC_SYS_COMPILER
 
+# save warnings/boilerplate of simple test code
+_LT_COMPILER_BOILERPLATE
+_LT_LINKER_BOILERPLATE
+
 # Allow CC to be a program name with arguments.
 lt_save_CC=$CC
 lt_save_LD=$LD
@@ -2658,18 +2924,18 @@ lt_save_path_LD=$lt_cv_path_LD
 if test -n "${lt_cv_prog_gnu_ldcxx+set}"; then
   lt_cv_prog_gnu_ld=$lt_cv_prog_gnu_ldcxx
 else
-  unset lt_cv_prog_gnu_ld
+  $as_unset lt_cv_prog_gnu_ld
 fi
 if test -n "${lt_cv_path_LDCXX+set}"; then
   lt_cv_path_LD=$lt_cv_path_LDCXX
 else
-  unset lt_cv_path_LD
+  $as_unset lt_cv_path_LD
 fi
 test -z "${LDCXX+set}" || LD=$LDCXX
 CC=${CXX-"c++"}
 compiler=$CC
 _LT_AC_TAGVAR(compiler, $1)=$CC
-cc_basename=`$echo X"$compiler" | $Xsed -e 's%^.*/%%'`
+_LT_CC_BASENAME([$compiler])
 
 # We don't want -fno-exception wen compiling C++ code, so set the
 # no_builtin_flag separately
@@ -2736,7 +3002,7 @@ case $host_os in
     # FIXME: insert proper C++ library support
     _LT_AC_TAGVAR(ld_shlibs, $1)=no
     ;;
-  aix4* | aix5*)
+  aix[[4-9]]*)
     if test "$host_cpu" = ia64; then
       # On IA64, the linker does run time linking by default, so we don't
       # have to do anything special.
@@ -2749,7 +3015,7 @@ case $host_os in
       # Test if we are trying to use run time linking or normal
       # AIX style linking. If -brtl is somewhere in LDFLAGS, we
       # need to do runtime linking.
-      case $host_os in aix4.[[23]]|aix4.[[23]].*|aix5*)
+      case $host_os in aix4.[[23]]|aix4.[[23]].*|aix[[5-9]]*)
 	for ld_flag in $LDFLAGS; do
 	  case $ld_flag in
 	  *-brtl*)
@@ -2758,6 +3024,7 @@ case $host_os in
 	    ;;
 	  esac
 	done
+	;;
       esac
 
       exp_sym_flag='-bexport'
@@ -2776,7 +3043,7 @@ case $host_os in
     _LT_AC_TAGVAR(link_all_deplibs, $1)=yes
 
     if test "$GXX" = yes; then
-      case $host_os in aix4.[012]|aix4.[012].*)
+      case $host_os in aix4.[[012]]|aix4.[[012]].*)
       # We only want to do this on AIX 4.2 and lower, the check
       # below for broken collect2 doesn't work under 4.3+
 	collect2name=`${CC} -print-prog-name=collect2`
@@ -2784,7 +3051,7 @@ case $host_os in
 	   strings "$collect2name" | grep resolve_lib_name >/dev/null
 	then
 	  # We have reworked collect2
-	  _LT_AC_TAGVAR(hardcode_direct, $1)=yes
+	  :
 	else
 	  # We have old collect2
 	  _LT_AC_TAGVAR(hardcode_direct, $1)=unsupported
@@ -2795,8 +3062,12 @@ case $host_os in
 	  _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
 	  _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=
 	fi
+	;;
       esac
       shared_flag='-shared'
+      if test "$aix_use_runtimelinking" = yes; then
+	shared_flag="$shared_flag "'${wl}-G'
+      fi
     else
       # not using gcc
       if test "$host_cpu" = ia64; then
@@ -2823,12 +3094,12 @@ case $host_os in
       _LT_AC_SYS_LIBPATH_AIX
       _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-blibpath:$libdir:'"$aix_libpath"
 
-      _LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags `if test "x${allow_undefined_flag}" != "x"; then echo "${wl}${allow_undefined_flag}"; else :; fi` '"\${wl}$no_entry_flag \${wl}$exp_sym_flag:\$export_symbols $shared_flag"
+      _LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC"' -o $output_objdir/$soname $libobjs $deplibs '"\${wl}$no_entry_flag"' $compiler_flags `if test "x${allow_undefined_flag}" != "x"; then echo "${wl}${allow_undefined_flag}"; else :; fi` '"\${wl}$exp_sym_flag:\$export_symbols $shared_flag"
      else
       if test "$host_cpu" = ia64; then
 	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-R $libdir:/usr/lib:/lib'
 	_LT_AC_TAGVAR(allow_undefined_flag, $1)="-z nodefs"
-	_LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags ${wl}${allow_undefined_flag} '"\${wl}$no_entry_flag \${wl}$exp_sym_flag:\$export_symbols"
+	_LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs '"\${wl}$no_entry_flag"' $compiler_flags ${wl}${allow_undefined_flag} '"\${wl}$exp_sym_flag:\$export_symbols"
       else
 	# Determine the default libpath from the value encoded in an empty executable.
 	_LT_AC_SYS_LIBPATH_AIX
@@ -2837,16 +3108,26 @@ case $host_os in
 	# -berok will link without error, but may produce a broken library.
 	_LT_AC_TAGVAR(no_undefined_flag, $1)=' ${wl}-bernotok'
 	_LT_AC_TAGVAR(allow_undefined_flag, $1)=' ${wl}-berok'
-	# -bexpall does not export symbols beginning with underscore (_)
-	_LT_AC_TAGVAR(always_export_symbols, $1)=yes
 	# Exported symbols can be pulled into shared objects from archives
-	_LT_AC_TAGVAR(whole_archive_flag_spec, $1)=' '
+	_LT_AC_TAGVAR(whole_archive_flag_spec, $1)='$convenience'
 	_LT_AC_TAGVAR(archive_cmds_need_lc, $1)=yes
-	# This is similar to how AIX traditionally builds it's shared libraries.
-	_LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags ${wl}-bE:$export_symbols ${wl}-bnoentry${allow_undefined_flag}~$AR $AR_FLAGS $output_objdir/$libname$release.a $output_objdir/$soname'
+	# This is similar to how AIX traditionally builds its shared libraries.
+	_LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs ${wl}-bnoentry $compiler_flags ${wl}-bE:$export_symbols${allow_undefined_flag}~$AR $AR_FLAGS $output_objdir/$libname$release.a $output_objdir/$soname'
       fi
     fi
     ;;
+
+  beos*)
+    if $LD --help 2>&1 | grep ': supported targets:.* elf' > /dev/null; then
+      _LT_AC_TAGVAR(allow_undefined_flag, $1)=unsupported
+      # Joseph Beckenbach <jrb3@best.com> says some releases of gcc
+      # support --undefined.  This deserves some investigation.  FIXME
+      _LT_AC_TAGVAR(archive_cmds, $1)='$CC -nostart $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
+    else
+      _LT_AC_TAGVAR(ld_shlibs, $1)=no
+    fi
+    ;;
+
   chorus*)
     case $cc_basename in
       *)
@@ -2856,7 +3137,6 @@ case $host_os in
     esac
     ;;
 
-
   cygwin* | mingw* | pw32*)
     # _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1) is actually meaningless,
     # as there is no search path for DLLs.
@@ -2866,7 +3146,7 @@ case $host_os in
     _LT_AC_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
 
     if $LD --help 2>&1 | grep 'auto-import' > /dev/null; then
-      _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $output_objdir/$soname ${wl}--image-base=0x10000000 ${wl}--out-implib,$lib'
+      _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
       # If the export-symbols file already is a .def file (1st line
       # is EXPORTS), use it as is; otherwise, prepend...
       _LT_AC_TAGVAR(archive_expsym_cmds, $1)='if test "x`$SED 1q $export_symbols`" = xEXPORTS; then
@@ -2875,65 +3155,37 @@ case $host_os in
 	echo EXPORTS > $output_objdir/$soname.def;
 	cat $export_symbols >> $output_objdir/$soname.def;
       fi~
-      $CC -shared -nostdlib $output_objdir/$soname.def $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $output_objdir/$soname ${wl}--image-base=0x10000000 ${wl}--out-implib,$lib'
+      $CC -shared -nostdlib $output_objdir/$soname.def $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
     else
       _LT_AC_TAGVAR(ld_shlibs, $1)=no
     fi
   ;;
       darwin* | rhapsody*)
-        case "$host_os" in
-        rhapsody* | darwin1.[[012]])
-         _LT_AC_TAGVAR(allow_undefined_flag, $1)='${wl}-undefined ${wl}suppress'
-         ;;
-       *) # Darwin 1.3 on
-         if test -z ${MACOSX_DEPLOYMENT_TARGET} ; then
-           _LT_AC_TAGVAR(allow_undefined_flag, $1)='${wl}-flat_namespace ${wl}-undefined ${wl}suppress'
-         else
-           case ${MACOSX_DEPLOYMENT_TARGET} in
-             10.[[012]])
-               _LT_AC_TAGVAR(allow_undefined_flag, $1)='${wl}-flat_namespace ${wl}-undefined ${wl}suppress'
-               ;;
-             10.*)
-               _LT_AC_TAGVAR(allow_undefined_flag, $1)='${wl}-undefined ${wl}dynamic_lookup'
-               ;;
-           esac
-         fi
-         ;;
-        esac
       _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
       _LT_AC_TAGVAR(hardcode_direct, $1)=no
       _LT_AC_TAGVAR(hardcode_automatic, $1)=yes
       _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=unsupported
       _LT_AC_TAGVAR(whole_archive_flag_spec, $1)=''
       _LT_AC_TAGVAR(link_all_deplibs, $1)=yes
-
-    if test "$GXX" = yes ; then
-      lt_int_apple_cc_single_mod=no
+      _LT_AC_TAGVAR(allow_undefined_flag, $1)="$_lt_dar_allow_undefined"
+      if test "$GXX" = yes ; then
       output_verbose_link_cmd='echo'
-      if $CC -dumpspecs 2>&1 | $EGREP 'single_module' >/dev/null ; then
-       lt_int_apple_cc_single_mod=yes
+      _LT_AC_TAGVAR(archive_cmds, $1)="\$CC -dynamiclib \$allow_undefined_flag -o \$lib \$libobjs \$deplibs \$compiler_flags -install_name \$rpath/\$soname \$verstring $_lt_dar_single_mod${_lt_dsymutil}"
+      _LT_AC_TAGVAR(module_cmds, $1)="\$CC \$allow_undefined_flag -o \$lib -bundle \$libobjs \$deplibs \$compiler_flags${_lt_dsymutil}"
+      _LT_AC_TAGVAR(archive_expsym_cmds, $1)="sed 's,^,_,' < \$export_symbols > \$output_objdir/\${libname}-symbols.expsym~\$CC -dynamiclib \$allow_undefined_flag -o \$lib \$libobjs \$deplibs \$compiler_flags -install_name \$rpath/\$soname \$verstring ${_lt_dar_single_mod}${_lt_dar_export_syms}${_lt_dsymutil}"
+      _LT_AC_TAGVAR(module_expsym_cmds, $1)="sed -e 's,^,_,' < \$export_symbols > \$output_objdir/\${libname}-symbols.expsym~\$CC \$allow_undefined_flag -o \$lib -bundle \$libobjs \$deplibs \$compiler_flags${_lt_dar_export_syms}${_lt_dsymutil}"
+      if test "$lt_cv_apple_cc_single_mod" != "yes"; then
+        _LT_AC_TAGVAR(archive_cmds, $1)="\$CC -r -keep_private_externs -nostdlib -o \${lib}-master.o \$libobjs~\$CC -dynamiclib \$allow_undefined_flag -o \$lib \${lib}-master.o \$deplibs \$compiler_flags -install_name \$rpath/\$soname \$verstring${_lt_dsymutil}"
+        _LT_AC_TAGVAR(archive_expsym_cmds, $1)="sed 's,^,_,' < \$export_symbols > \$output_objdir/\${libname}-symbols.expsym~\$CC -r -keep_private_externs -nostdlib -o \${lib}-master.o \$libobjs~\$CC -dynamiclib \$allow_undefined_flag -o \$lib \${lib}-master.o \$deplibs \$compiler_flags -install_name \$rpath/\$soname \$verstring${_lt_dar_export_syms}${_lt_dsymutil}"
       fi
-      if test "X$lt_int_apple_cc_single_mod" = Xyes ; then
-       _LT_AC_TAGVAR(archive_cmds, $1)='$CC -dynamiclib -single_module $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags -install_name $rpath/$soname $verstring'
-      else
-          _LT_AC_TAGVAR(archive_cmds, $1)='$CC -r -keep_private_externs -nostdlib -o ${lib}-master.o $libobjs~$CC -dynamiclib $allow_undefined_flag -o $lib ${lib}-master.o $deplibs $compiler_flags -install_name $rpath/$soname $verstring'
-        fi
-        _LT_AC_TAGVAR(module_cmds, $1)='$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags'
-        # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin ld's
-          if test "X$lt_int_apple_cc_single_mod" = Xyes ; then
-            _LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[    ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC -dynamiclib -single_module $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags -install_name $rpath/$soname $verstring~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
-          else
-            _LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[    ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC -r -keep_private_externs -nostdlib -o ${lib}-master.o $libobjs~$CC -dynamiclib $allow_undefined_flag -o $lib ${lib}-master.o $deplibs $compiler_flags -install_name $rpath/$soname $verstring~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
-          fi
-            _LT_AC_TAGVAR(module_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[    ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC $allow_undefined_flag  -o $lib -bundle $libobjs $deplibs$compiler_flags~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
       else
-      case "$cc_basename" in
+      case $cc_basename in
         xlc*)
          output_verbose_link_cmd='echo'
-          _LT_AC_TAGVAR(archive_cmds, $1)='$CC -qmkshrobj ${wl}-single_module $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-install_name ${wl}`echo $rpath/$soname` $verstring'
+          _LT_AC_TAGVAR(archive_cmds, $1)='$CC -qmkshrobj ${wl}-single_module $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-install_name ${wl}`echo $rpath/$soname` $xlcverstring'
           _LT_AC_TAGVAR(module_cmds, $1)='$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags'
-          # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin ld's
-          _LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[    ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC -qmkshrobj ${wl}-single_module $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-install_name ${wl}$rpath/$soname $verstring~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
+          # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin lds
+          _LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[    ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC -qmkshrobj ${wl}-single_module $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-install_name ${wl}$rpath/$soname $xlcverstring~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
           _LT_AC_TAGVAR(module_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[    ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC $allow_undefined_flag  -o $lib -bundle $libobjs $deplibs$compiler_flags~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
           ;;
        *)
@@ -2945,11 +3197,11 @@ case $host_os in
 
   dgux*)
     case $cc_basename in
-      ec++)
+      ec++*)
 	# FIXME: insert proper C++ library support
 	_LT_AC_TAGVAR(ld_shlibs, $1)=no
 	;;
-      ghcx)
+      ghcx*)
 	# Green Hills C++ Compiler
 	# FIXME: insert proper C++ library support
 	_LT_AC_TAGVAR(ld_shlibs, $1)=no
@@ -2960,14 +3212,14 @@ case $host_os in
 	;;
     esac
     ;;
-  freebsd[12]*)
+  freebsd[[12]]*)
     # C++ shared libraries reported to be fairly broken before switch to ELF
     _LT_AC_TAGVAR(ld_shlibs, $1)=no
     ;;
   freebsd-elf*)
     _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
     ;;
-  freebsd* | kfreebsd*-gnu)
+  freebsd* | dragonfly*)
     # FreeBSD 3 and later use GNU C++ and GNU ld with standard ELF
     # conventions
     _LT_AC_TAGVAR(ld_shlibs, $1)=yes
@@ -2984,11 +3236,11 @@ case $host_os in
 				# location of the library.
 
     case $cc_basename in
-    CC)
+    CC*)
       # FIXME: insert proper C++ library support
       _LT_AC_TAGVAR(ld_shlibs, $1)=no
       ;;
-    aCC)
+    aCC*)
       _LT_AC_TAGVAR(archive_cmds, $1)='$rm $output_objdir/$soname~$CC -b ${wl}+b ${wl}$install_libdir -o $output_objdir/$soname $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~test $output_objdir/$soname = $lib || mv $output_objdir/$soname $lib'
       # Commands to make compiler produce verbose output that lists
       # what "hidden" libraries, object files and flags are used when
@@ -2998,7 +3250,7 @@ case $host_os in
       # explicitly linking system object files so we need to strip them
       # from the output so that they don't get included in the library
       # dependencies.
-      output_verbose_link_cmd='templist=`($CC -b $CFLAGS -v conftest.$objext 2>&1) | grep "[-]L"`; list=""; for z in $templist; do case $z in conftest.$objext) list="$list $z";; *.$objext);; *) list="$list $z";;esac; done; echo $list'
+      output_verbose_link_cmd='templist=`($CC -b $CFLAGS -v conftest.$objext 2>&1) | grep "[[-]]L"`; list=""; for z in $templist; do case $z in conftest.$objext) list="$list $z";; *.$objext);; *) list="$list $z";;esac; done; echo $list'
       ;;
     *)
       if test "$GXX" = yes; then
@@ -3012,34 +3264,21 @@ case $host_os in
     ;;
   hpux10*|hpux11*)
     if test $with_gnu_ld = no; then
-      case "$host_cpu" in
-      hppa*64*)
-	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
-	_LT_AC_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
-	_LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
-        ;;
-      ia64*)
-	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
-        ;;
+      _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
+      _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
+
+      case $host_cpu in
+      hppa*64*|ia64*) ;;
       *)
-	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
-	_LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
 	_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
         ;;
       esac
     fi
-    case "$host_cpu" in
-    hppa*64*)
+    case $host_cpu in
+    hppa*64*|ia64*)
       _LT_AC_TAGVAR(hardcode_direct, $1)=no
       _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
       ;;
-    ia64*)
-      _LT_AC_TAGVAR(hardcode_direct, $1)=no
-      _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
-      _LT_AC_TAGVAR(hardcode_minus_L, $1)=yes # Not in the search PATH,
-					      # but as the default
-					      # location of the library.
-      ;;
     *)
       _LT_AC_TAGVAR(hardcode_direct, $1)=yes
       _LT_AC_TAGVAR(hardcode_minus_L, $1)=yes # Not in the search PATH,
@@ -3049,14 +3288,17 @@ case $host_os in
     esac
 
     case $cc_basename in
-      CC)
+      CC*)
 	# FIXME: insert proper C++ library support
 	_LT_AC_TAGVAR(ld_shlibs, $1)=no
 	;;
-      aCC)
-	case "$host_cpu" in
-	hppa*64*|ia64*)
-	  _LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib $linker_flags $libobjs $deplibs'
+      aCC*)
+	case $host_cpu in
+	hppa*64*)
+	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
+	  ;;
+	ia64*)
+	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
 	  ;;
 	*)
 	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
@@ -3075,9 +3317,12 @@ case $host_os in
       *)
 	if test "$GXX" = yes; then
 	  if test $with_gnu_ld = no; then
-	    case "$host_cpu" in
-	    ia64*|hppa*64*)
-	      _LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib $linker_flags $libobjs $deplibs'
+	    case $host_cpu in
+	    hppa*64*)
+	      _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib -fPIC ${wl}+h ${wl}$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
+	      ;;
+	    ia64*)
+	      _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib -fPIC ${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
 	      ;;
 	    *)
 	      _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
@@ -3091,11 +3336,25 @@ case $host_os in
 	;;
     esac
     ;;
+  interix[[3-9]]*)
+    _LT_AC_TAGVAR(hardcode_direct, $1)=no
+    _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+    _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
+    _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
+    # Hack: On Interix 3.x, we cannot compile PIC because of a broken gcc.
+    # Instead, shared libraries are loaded at an image base (0x10000000 by
+    # default) and relocated if they conflict, which is a slow very memory
+    # consuming and fragmenting process.  To avoid this, we pick a random,
+    # 256 KiB-aligned image base between 0x50000000 and 0x6FFC0000 at link
+    # time.  Moving up from 0x10000000 also allows more sbrk(2) space.
+    _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
+    _LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed "s,^,_," $export_symbols >$output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--retain-symbols-file,$output_objdir/$soname.expsym ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
+    ;;
   irix5* | irix6*)
     case $cc_basename in
-      CC)
+      CC*)
 	# SGI C++
-	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -all -multigot $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -soname $soname `test -n "$verstring" && echo -set_version $verstring` -update_registry ${objdir}/so_locations -o $lib'
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -all -multigot $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -soname $soname `test -n "$verstring" && echo -set_version $verstring` -update_registry ${output_objdir}/so_locations -o $lib'
 
 	# Archives containing C++ object files must be created using
 	# "CC -ar", where "CC" is the IRIX C++ compiler.  This is
@@ -3106,7 +3365,7 @@ case $host_os in
       *)
 	if test "$GXX" = yes; then
 	  if test "$with_gnu_ld" = no; then
-	    _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname ${wl}$soname `test -n "$verstring" && echo ${wl}-set_version ${wl}$verstring` ${wl}-update_registry ${wl}${objdir}/so_locations -o $lib'
+	    _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname ${wl}$soname `test -n "$verstring" && echo ${wl}-set_version ${wl}$verstring` ${wl}-update_registry ${wl}${output_objdir}/so_locations -o $lib'
 	  else
 	    _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname ${wl}$soname `test -n "$verstring" && echo ${wl}-set_version ${wl}$verstring` -o $lib'
 	  fi
@@ -3117,9 +3376,9 @@ case $host_os in
     _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath ${wl}$libdir'
     _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
     ;;
-  linux*)
+  linux* | k*bsd*-gnu)
     case $cc_basename in
-      KCC)
+      KCC*)
 	# Kuck and Associates, Inc. (KAI) C++ Compiler
 
 	# KCC will only create a shared library if the output file
@@ -3144,7 +3403,7 @@ case $host_os in
 	# "CC -Bstatic", where "CC" is the KAI C++ compiler.
 	_LT_AC_TAGVAR(old_archive_cmds, $1)='$CC -Bstatic -o $oldlib $oldobjs'
 	;;
-      icpc)
+      icpc*)
 	# Intel C++
 	with_gnu_ld=yes
 	# version 8.0 and above of icpc choke on multiply defined symbols
@@ -3156,8 +3415,12 @@ case $host_os in
   	  _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
 	  ;;
 	*)  # Version 8.0 or newer
-  	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
-  	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
+	  tmp_idyn=
+	  case $host_cpu in
+	    ia64*) tmp_idyn=' -i_dynamic';;
+	  esac
+  	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared'"$tmp_idyn"' $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
+	  _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared'"$tmp_idyn"' $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
 	  ;;
 	esac
 	_LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
@@ -3165,7 +3428,16 @@ case $host_os in
 	_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-dynamic'
 	_LT_AC_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-archive$convenience ${wl}--no-whole-archive'
 	;;
-      cxx)
+      pgCC* | pgcpp*)
+        # Portland Group C++ compiler
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname ${wl}$soname -o $lib'
+  	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname ${wl}$soname ${wl}-retain-symbols-file ${wl}$export_symbols -o $lib'
+
+	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}--rpath ${wl}$libdir'
+	_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-dynamic'
+	_LT_AC_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-archive`for conv in $convenience\"\"; do test  -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
+        ;;
+      cxx*)
 	# Compaq C++
 	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname -o $lib'
 	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname  -o $lib ${wl}-retain-symbols-file $wl$export_symbols'
@@ -3184,6 +3456,29 @@ case $host_os in
 	# dependencies.
 	output_verbose_link_cmd='templist=`$CC -shared $CFLAGS -v conftest.$objext 2>&1 | grep "ld"`; templist=`echo $templist | $SED "s/\(^.*ld.*\)\( .*ld .*$\)/\1/"`; list=""; for z in $templist; do case $z in conftest.$objext) list="$list $z";; *.$objext);; *) list="$list $z";;esac; done; echo $list'
 	;;
+      *)
+	case `$CC -V 2>&1 | sed 5q` in
+	*Sun\ C*)
+	  # Sun C++ 5.9
+	  _LT_AC_TAGVAR(no_undefined_flag, $1)=' -zdefs'
+	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -G${allow_undefined_flag} -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
+	  _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -G${allow_undefined_flag} -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-retain-symbols-file ${wl}$export_symbols'
+	  _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
+	  _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-archive`new_convenience=; for conv in $convenience\"\"; do test -z \"$conv\" || new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
+
+	  # Not sure whether something based on
+	  # $CC $CFLAGS -v conftest.$objext -o libconftest$shared_ext 2>&1
+	  # would be better.
+	  output_verbose_link_cmd='echo'
+
+	  # Archives containing C++ object files must be created using
+	  # "CC -xar", where "CC" is the Sun C++ compiler.  This is
+	  # necessary to make sure instantiated templates are included
+	  # in the archive.
+	  _LT_AC_TAGVAR(old_archive_cmds, $1)='$CC -xar -o $oldlib $oldobjs'
+	  ;;
+	esac
+	;;
     esac
     ;;
   lynxos*)
@@ -3196,7 +3491,7 @@ case $host_os in
     ;;
   mvs*)
     case $cc_basename in
-      cxx)
+      cxx*)
 	# FIXME: insert proper C++ library support
 	_LT_AC_TAGVAR(ld_shlibs, $1)=no
 	;;
@@ -3222,20 +3517,24 @@ case $host_os in
     _LT_AC_TAGVAR(ld_shlibs, $1)=no
     ;;
   openbsd*)
-    _LT_AC_TAGVAR(hardcode_direct, $1)=yes
-    _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
-    _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $lib'
-    _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
-    if test -z "`echo __ELF__ | $CC -E - | grep __ELF__`" || test "$host_os-$host_cpu" = "openbsd2.8-powerpc"; then
-      _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-retain-symbols-file,$export_symbols -o $lib'
-      _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
-      _LT_AC_TAGVAR(whole_archive_flag_spec, $1)="$wlarc"'--whole-archive$convenience '"$wlarc"'--no-whole-archive'
+    if test -f /usr/libexec/ld.so; then
+      _LT_AC_TAGVAR(hardcode_direct, $1)=yes
+      _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+      _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $lib'
+      _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
+      if test -z "`echo __ELF__ | $CC -E - | grep __ELF__`" || test "$host_os-$host_cpu" = "openbsd2.8-powerpc"; then
+	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-retain-symbols-file,$export_symbols -o $lib'
+	_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
+	_LT_AC_TAGVAR(whole_archive_flag_spec, $1)="$wlarc"'--whole-archive$convenience '"$wlarc"'--no-whole-archive'
+      fi
+      output_verbose_link_cmd='echo'
+    else
+      _LT_AC_TAGVAR(ld_shlibs, $1)=no
     fi
-    output_verbose_link_cmd='echo'
     ;;
   osf3*)
     case $cc_basename in
-      KCC)
+      KCC*)
 	# Kuck and Associates, Inc. (KAI) C++ Compiler
 
 	# KCC will only create a shared library if the output file
@@ -3251,14 +3550,14 @@ case $host_os in
 	_LT_AC_TAGVAR(old_archive_cmds, $1)='$CC -Bstatic -o $oldlib $oldobjs'
 
 	;;
-      RCC)
+      RCC*)
 	# Rational C++ 2.4.1
 	# FIXME: insert proper C++ library support
 	_LT_AC_TAGVAR(ld_shlibs, $1)=no
 	;;
-      cxx)
+      cxx*)
 	_LT_AC_TAGVAR(allow_undefined_flag, $1)=' ${wl}-expect_unresolved ${wl}\*'
-	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared${allow_undefined_flag} $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $soname `test -n "$verstring" && echo ${wl}-set_version $verstring` -update_registry ${objdir}/so_locations -o $lib'
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared${allow_undefined_flag} $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $soname `test -n "$verstring" && echo ${wl}-set_version $verstring` -update_registry ${output_objdir}/so_locations -o $lib'
 
 	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath ${wl}$libdir'
 	_LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
@@ -3276,7 +3575,7 @@ case $host_os in
       *)
 	if test "$GXX" = yes && test "$with_gnu_ld" = no; then
 	  _LT_AC_TAGVAR(allow_undefined_flag, $1)=' ${wl}-expect_unresolved ${wl}\*'
-	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib ${allow_undefined_flag} $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname ${wl}$soname `test -n "$verstring" && echo ${wl}-set_version ${wl}$verstring` ${wl}-update_registry ${wl}${objdir}/so_locations -o $lib'
+	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib ${allow_undefined_flag} $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname ${wl}$soname `test -n "$verstring" && echo ${wl}-set_version ${wl}$verstring` ${wl}-update_registry ${wl}${output_objdir}/so_locations -o $lib'
 
 	  _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath ${wl}$libdir'
 	  _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
@@ -3295,7 +3594,7 @@ case $host_os in
     ;;
   osf4* | osf5*)
     case $cc_basename in
-      KCC)
+      KCC*)
 	# Kuck and Associates, Inc. (KAI) C++ Compiler
 
 	# KCC will only create a shared library if the output file
@@ -3310,17 +3609,17 @@ case $host_os in
 	# the KAI C++ compiler.
 	_LT_AC_TAGVAR(old_archive_cmds, $1)='$CC -o $oldlib $oldobjs'
 	;;
-      RCC)
+      RCC*)
 	# Rational C++ 2.4.1
 	# FIXME: insert proper C++ library support
 	_LT_AC_TAGVAR(ld_shlibs, $1)=no
 	;;
-      cxx)
+      cxx*)
 	_LT_AC_TAGVAR(allow_undefined_flag, $1)=' -expect_unresolved \*'
-	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared${allow_undefined_flag} $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -msym -soname $soname `test -n "$verstring" && echo -set_version $verstring` -update_registry ${objdir}/so_locations -o $lib'
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared${allow_undefined_flag} $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -msym -soname $soname `test -n "$verstring" && echo -set_version $verstring` -update_registry ${output_objdir}/so_locations -o $lib'
 	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='for i in `cat $export_symbols`; do printf "%s %s\\n" -exported_symbol "\$i" >> $lib.exp; done~
 	  echo "-hidden">> $lib.exp~
-	  $CC -shared$allow_undefined_flag $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -msym -soname $soname -Wl,-input -Wl,$lib.exp  `test -n "$verstring" && echo -set_version	$verstring` -update_registry $objdir/so_locations -o $lib~
+	  $CC -shared$allow_undefined_flag $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -msym -soname $soname -Wl,-input -Wl,$lib.exp  `test -n "$verstring" && echo -set_version	$verstring` -update_registry ${output_objdir}/so_locations -o $lib~
 	  $rm $lib.exp'
 
 	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-rpath $libdir'
@@ -3339,7 +3638,7 @@ case $host_os in
       *)
 	if test "$GXX" = yes && test "$with_gnu_ld" = no; then
 	  _LT_AC_TAGVAR(allow_undefined_flag, $1)=' ${wl}-expect_unresolved ${wl}\*'
-	 _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib ${allow_undefined_flag} $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-msym ${wl}-soname ${wl}$soname `test -n "$verstring" && echo ${wl}-set_version ${wl}$verstring` ${wl}-update_registry ${wl}${objdir}/so_locations -o $lib'
+	 _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib ${allow_undefined_flag} $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-msym ${wl}-soname ${wl}$soname `test -n "$verstring" && echo ${wl}-set_version ${wl}$verstring` ${wl}-update_registry ${wl}${output_objdir}/so_locations -o $lib'
 
 	  _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath ${wl}$libdir'
 	  _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
@@ -3360,27 +3659,14 @@ case $host_os in
     # FIXME: insert proper C++ library support
     _LT_AC_TAGVAR(ld_shlibs, $1)=no
     ;;
-  sco*)
-    _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
-    case $cc_basename in
-      CC)
-	# FIXME: insert proper C++ library support
-	_LT_AC_TAGVAR(ld_shlibs, $1)=no
-	;;
-      *)
-	# FIXME: insert proper C++ library support
-	_LT_AC_TAGVAR(ld_shlibs, $1)=no
-	;;
-    esac
-    ;;
   sunos4*)
     case $cc_basename in
-      CC)
+      CC*)
 	# Sun C++ 4.x
 	# FIXME: insert proper C++ library support
 	_LT_AC_TAGVAR(ld_shlibs, $1)=no
 	;;
-      lcc)
+      lcc*)
 	# Lucid
 	# FIXME: insert proper C++ library support
 	_LT_AC_TAGVAR(ld_shlibs, $1)=no
@@ -3393,36 +3679,28 @@ case $host_os in
     ;;
   solaris*)
     case $cc_basename in
-      CC)
+      CC*)
 	# Sun C++ 4.2, 5.x and Centerline C++
+        _LT_AC_TAGVAR(archive_cmds_need_lc,$1)=yes
 	_LT_AC_TAGVAR(no_undefined_flag, $1)=' -zdefs'
-	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -G${allow_undefined_flag} -nolib -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -G${allow_undefined_flag}  -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
 	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~$echo "local: *; };" >> $lib.exp~
-	$CC -G${allow_undefined_flag} -nolib ${wl}-M ${wl}$lib.exp -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$rm $lib.exp'
+	$CC -G${allow_undefined_flag}  ${wl}-M ${wl}$lib.exp -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$rm $lib.exp'
 
 	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
 	_LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
 	case $host_os in
-	  solaris2.[0-5] | solaris2.[0-5].*) ;;
+	  solaris2.[[0-5]] | solaris2.[[0-5]].*) ;;
 	  *)
-	    # The C++ compiler is used as linker so we must use $wl
-	    # flag to pass the commands to the underlying system
-	    # linker.
+	    # The compiler driver will combine and reorder linker options,
+	    # but understands `-z linker_flag'.
 	    # Supported since Solaris 2.6 (maybe 2.5.1?)
-	    _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='${wl}-z ${wl}allextract$convenience ${wl}-z ${wl}defaultextract'
+	    _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='-z allextract$convenience -z defaultextract'
 	    ;;
 	esac
 	_LT_AC_TAGVAR(link_all_deplibs, $1)=yes
 
-	# Commands to make compiler produce verbose output that lists
-	# what "hidden" libraries, object files and flags are used when
-	# linking a shared library.
-	#
-	# There doesn't appear to be a way to prevent this compiler from
-	# explicitly linking system object files so we need to strip them
-	# from the output so that they don't get included in the library
-	# dependencies.
-	output_verbose_link_cmd='templist=`$CC -G $CFLAGS -v conftest.$objext 2>&1 | grep "\-[[LR]]"`; list=""; for z in $templist; do case $z in conftest.$objext) list="$list $z";; *.$objext);; *) list="$list $z";;esac; done; echo $list'
+	output_verbose_link_cmd='echo'
 
 	# Archives containing C++ object files must be created using
 	# "CC -xar", where "CC" is the Sun C++ compiler.  This is
@@ -3430,7 +3708,7 @@ case $host_os in
 	# in the archive.
 	_LT_AC_TAGVAR(old_archive_cmds, $1)='$CC -xar -o $oldlib $oldobjs'
 	;;
-      gcx)
+      gcx*)
 	# Green Hills C++ Compiler
 	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-h $wl$soname -o $lib'
 
@@ -3464,16 +3742,73 @@ case $host_os in
 	  fi
 
 	  _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-R $wl$libdir'
+	  case $host_os in
+	  solaris2.[[0-5]] | solaris2.[[0-5]].*) ;;
+	  *)
+	    _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='${wl}-z ${wl}allextract$convenience ${wl}-z ${wl}defaultextract'
+	    ;;
+	  esac
 	fi
 	;;
     esac
     ;;
-  sysv5OpenUNIX8* | sysv5UnixWare7* | sysv5uw[[78]]* | unixware7*)
+  sysv4*uw2* | sysv5OpenUNIX* | sysv5UnixWare7.[[01]].[[10]]* | unixware7* | sco3.2v5.0.[[024]]*)
+    _LT_AC_TAGVAR(no_undefined_flag, $1)='${wl}-z,text'
+    _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
+    _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+    runpath_var='LD_RUN_PATH'
+
+    case $cc_basename in
+      CC*)
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
+	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -G ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
+	;;
+      *)
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
+	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
+	;;
+    esac
+    ;;
+  sysv5* | sco3.2v5* | sco5v6*)
+    # Note: We can NOT use -z defs as we might desire, because we do not
+    # link with -lc, and that would cause any symbols used from libc to
+    # always be unresolved, which means just about no library would
+    # ever link correctly.  If we're not using GNU ld we use -z text
+    # though, which does catch some bad symbols but isn't as heavy-handed
+    # as -z defs.
+    # For security reasons, it is highly recommended that you always
+    # use absolute paths for naming shared libraries, and exclude the
+    # DT_RUNPATH tag from executables and libraries.  But doing so
+    # requires that you compile everything twice, which is a pain.
+    # So that behaviour is only enabled if SCOABSPATH is set to a
+    # non-empty value in the environment.  Most likely only useful for
+    # creating official distributions of packages.
+    # This is a hack until libtool officially supports absolute path
+    # names for shared libraries.
+    _LT_AC_TAGVAR(no_undefined_flag, $1)='${wl}-z,text'
+    _LT_AC_TAGVAR(allow_undefined_flag, $1)='${wl}-z,nodefs'
     _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
+    _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+    _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='`test -z "$SCOABSPATH" && echo ${wl}-R,$libdir`'
+    _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=':'
+    _LT_AC_TAGVAR(link_all_deplibs, $1)=yes
+    _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-Bexport'
+    runpath_var='LD_RUN_PATH'
+
+    case $cc_basename in
+      CC*)
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -G ${wl}-Bexport:$export_symbols ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+	;;
+      *)
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared ${wl}-Bexport:$export_symbols ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+	;;
+    esac
     ;;
   tandem*)
     case $cc_basename in
-      NCC)
+      NCC*)
 	# NonStop-UX NCC 3.20
 	# FIXME: insert proper C++ library support
 	_LT_AC_TAGVAR(ld_shlibs, $1)=no
@@ -3510,8 +3845,6 @@ AC_LIBTOOL_SYS_HARD_LINK_LOCKS($1)
 AC_LIBTOOL_PROG_LD_SHLIBS($1)
 AC_LIBTOOL_SYS_DYNAMIC_LINKER($1)
 AC_LIBTOOL_PROG_LD_HARDCODE_LIBPATH($1)
-AC_LIBTOOL_SYS_LIB_STRIP
-AC_LIBTOOL_DLOPEN_SELF($1)
 
 AC_LIBTOOL_CONFIG($1)
 
@@ -3529,12 +3862,13 @@ lt_cv_prog_gnu_ld=$lt_save_with_gnu_ld
 ])# AC_LIBTOOL_LANG_CXX_CONFIG
 
 # AC_LIBTOOL_POSTDEP_PREDEP([TAGNAME])
-# ------------------------
+# ------------------------------------
 # Figure out "hidden" library dependencies from verbose
 # compiler output when linking a shared library.
 # Parse the compiler output and extract the necessary
 # objects, libraries and library flags.
-AC_DEFUN([AC_LIBTOOL_POSTDEP_PREDEP],[
+AC_DEFUN([AC_LIBTOOL_POSTDEP_PREDEP],
+[AC_REQUIRE([LT_AC_PROG_SED])dnl
 dnl we can't use the lt_simple_compile_test_code here,
 dnl because it contains code intended for an executable,
 dnl not a library.  It's possible we should let each
@@ -3583,7 +3917,7 @@ if AC_TRY_EVAL(ac_compile); then
   # The `*' in the case matches for architectures that use `case' in
   # $output_verbose_cmd can trigger glob expansion during the loop
   # eval without this substitution.
-  output_verbose_link_cmd="`$echo \"X$output_verbose_link_cmd\" | $Xsed -e \"$no_glob_subst\"`"
+  output_verbose_link_cmd=`$echo "X$output_verbose_link_cmd" | $Xsed -e "$no_glob_subst"`
 
   for p in `eval $output_verbose_link_cmd`; do
     case $p in
@@ -3659,13 +3993,74 @@ fi
 
 $rm -f confest.$objext
 
+_LT_AC_TAGVAR(compiler_lib_search_dirs, $1)=
+if test -n "$_LT_AC_TAGVAR(compiler_lib_search_path, $1)"; then
+  _LT_AC_TAGVAR(compiler_lib_search_dirs, $1)=`echo " ${_LT_AC_TAGVAR(compiler_lib_search_path, $1)}" | ${SED} -e 's! -L! !g' -e 's!^ !!'`
+fi
+
+# PORTME: override above test on systems where it is broken
+ifelse([$1],[CXX],
+[case $host_os in
+interix[[3-9]]*)
+  # Interix 3.5 installs completely hosed .la files for C++, so rather than
+  # hack all around it, let's just trust "g++" to DTRT.
+  _LT_AC_TAGVAR(predep_objects,$1)=
+  _LT_AC_TAGVAR(postdep_objects,$1)=
+  _LT_AC_TAGVAR(postdeps,$1)=
+  ;;
+
+linux*)
+  case `$CC -V 2>&1 | sed 5q` in
+  *Sun\ C*)
+    # Sun C++ 5.9
+    #
+    # The more standards-conforming stlport4 library is
+    # incompatible with the Cstd library. Avoid specifying
+    # it if it's in CXXFLAGS. Ignore libCrun as
+    # -library=stlport4 depends on it.
+    case " $CXX $CXXFLAGS " in
+    *" -library=stlport4 "*)
+      solaris_use_stlport4=yes
+      ;;
+    esac
+    if test "$solaris_use_stlport4" != yes; then
+      _LT_AC_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun'
+    fi
+    ;;
+  esac
+  ;;
+
+solaris*)
+  case $cc_basename in
+  CC*)
+    # The more standards-conforming stlport4 library is
+    # incompatible with the Cstd library. Avoid specifying
+    # it if it's in CXXFLAGS. Ignore libCrun as
+    # -library=stlport4 depends on it.
+    case " $CXX $CXXFLAGS " in
+    *" -library=stlport4 "*)
+      solaris_use_stlport4=yes
+      ;;
+    esac
+
+    # Adding this requires a known-good setup of shared libraries for
+    # Sun compiler versions before 5.6, else PIC objects from an old
+    # archive will be linked into the output, leading to subtle bugs.
+    if test "$solaris_use_stlport4" != yes; then
+      _LT_AC_TAGVAR(postdeps,$1)='-library=Cstd -library=Crun'
+    fi
+    ;;
+  esac
+  ;;
+esac
+])
 case " $_LT_AC_TAGVAR(postdeps, $1) " in
 *" -lc "*) _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no ;;
 esac
 ])# AC_LIBTOOL_POSTDEP_PREDEP
 
 # AC_LIBTOOL_LANG_F77_CONFIG
-# ------------------------
+# --------------------------
 # Ensure that the configuration vars for the C compiler are
 # suitably defined.  Those variables are subsequently used by
 # AC_LIBTOOL_CONFIG to write the compiler configuration to `libtool'.
@@ -3701,20 +4096,31 @@ objext=o
 _LT_AC_TAGVAR(objext, $1)=$objext
 
 # Code to be used in simple compile tests
-lt_simple_compile_test_code="      subroutine t\n      return\n      end\n"
+lt_simple_compile_test_code="\
+      subroutine t
+      return
+      end
+"
 
 # Code to be used in simple link tests
-lt_simple_link_test_code="      program t\n      end\n"
+lt_simple_link_test_code="\
+      program t
+      end
+"
 
 # ltmain only uses $CC for tagged configurations so make sure $CC is set.
 _LT_AC_SYS_COMPILER
 
+# save warnings/boilerplate of simple test code
+_LT_COMPILER_BOILERPLATE
+_LT_LINKER_BOILERPLATE
+
 # Allow CC to be a program name with arguments.
 lt_save_CC="$CC"
 CC=${F77-"f77"}
 compiler=$CC
 _LT_AC_TAGVAR(compiler, $1)=$CC
-cc_basename=`$echo X"$compiler" | $Xsed -e 's%^.*/%%'`
+_LT_CC_BASENAME([$compiler])
 
 AC_MSG_CHECKING([if libtool supports shared libraries])
 AC_MSG_RESULT([$can_build_shared])
@@ -3724,7 +4130,7 @@ test "$can_build_shared" = "no" && enable_shared=no
 
 # On AIX, shared libraries and static libraries use the same namespace, and
 # are all built from PIC.
-case "$host_os" in
+case $host_os in
 aix3*)
   test "$enable_shared" = yes && enable_static=no
   if test -n "$RANLIB"; then
@@ -3732,8 +4138,10 @@ aix3*)
     postinstall_cmds='$RANLIB $lib'
   fi
   ;;
-aix4* | aix5*)
-  test "$enable_shared" = yes && enable_static=no
+aix[[4-9]]*)
+  if test "$host_cpu" != ia64 && test "$aix_use_runtimelinking" = no ; then
+    test "$enable_shared" = yes && enable_static=no
+  fi
   ;;
 esac
 AC_MSG_RESULT([$enable_shared])
@@ -3743,8 +4151,6 @@ AC_MSG_CHECKING([whether to build static libraries])
 test "$enable_shared" = yes || enable_static=yes
 AC_MSG_RESULT([$enable_static])
 
-test "$_LT_AC_TAGVAR(ld_shlibs, $1)" = no && can_build_shared=no
-
 _LT_AC_TAGVAR(GCC, $1)="$G77"
 _LT_AC_TAGVAR(LD, $1)="$LD"
 
@@ -3754,8 +4160,6 @@ AC_LIBTOOL_SYS_HARD_LINK_LOCKS($1)
 AC_LIBTOOL_PROG_LD_SHLIBS($1)
 AC_LIBTOOL_SYS_DYNAMIC_LINKER($1)
 AC_LIBTOOL_PROG_LD_HARDCODE_LIBPATH($1)
-AC_LIBTOOL_SYS_LIB_STRIP
-
 
 AC_LIBTOOL_CONFIG($1)
 
@@ -3781,23 +4185,30 @@ objext=o
 _LT_AC_TAGVAR(objext, $1)=$objext
 
 # Code to be used in simple compile tests
-lt_simple_compile_test_code="class foo {}\n"
+lt_simple_compile_test_code="class foo {}"
 
 # Code to be used in simple link tests
-lt_simple_link_test_code='public class conftest { public static void main(String[] argv) {}; }\n'
+lt_simple_link_test_code='public class conftest { public static void main(String[[]] argv) {}; }'
 
 # ltmain only uses $CC for tagged configurations so make sure $CC is set.
 _LT_AC_SYS_COMPILER
 
+# save warnings/boilerplate of simple test code
+_LT_COMPILER_BOILERPLATE
+_LT_LINKER_BOILERPLATE
+
 # Allow CC to be a program name with arguments.
 lt_save_CC="$CC"
 CC=${GCJ-"gcj"}
 compiler=$CC
 _LT_AC_TAGVAR(compiler, $1)=$CC
+_LT_CC_BASENAME([$compiler])
 
 # GCJ did not exist at the time GCC didn't implicitly link libc in.
 _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
 
+_LT_AC_TAGVAR(old_archive_cmds, $1)=$old_archive_cmds
+
 ## CAVEAT EMPTOR:
 ## There is no encapsulation within the following macros, do not change
 ## the running order or otherwise move them around unless you know exactly
@@ -3809,8 +4220,6 @@ AC_LIBTOOL_SYS_HARD_LINK_LOCKS($1)
 AC_LIBTOOL_PROG_LD_SHLIBS($1)
 AC_LIBTOOL_SYS_DYNAMIC_LINKER($1)
 AC_LIBTOOL_PROG_LD_HARDCODE_LIBPATH($1)
-AC_LIBTOOL_SYS_LIB_STRIP
-AC_LIBTOOL_DLOPEN_SELF($1)
 
 AC_LIBTOOL_CONFIG($1)
 
@@ -3820,7 +4229,7 @@ CC="$lt_save_CC"
 
 
 # AC_LIBTOOL_LANG_RC_CONFIG
-# --------------------------
+# -------------------------
 # Ensure that the configuration vars for the Windows resource compiler are
 # suitably defined.  Those variables are subsequently used by
 # AC_LIBTOOL_CONFIG to write the compiler configuration to `libtool'.
@@ -3836,7 +4245,7 @@ objext=o
 _LT_AC_TAGVAR(objext, $1)=$objext
 
 # Code to be used in simple compile tests
-lt_simple_compile_test_code='sample MENU { MENUITEM "&Soup", 100, CHECKED }\n'
+lt_simple_compile_test_code='sample MENU { MENUITEM "&Soup", 100, CHECKED }'
 
 # Code to be used in simple link tests
 lt_simple_link_test_code="$lt_simple_compile_test_code"
@@ -3844,11 +4253,16 @@ lt_simple_link_test_code="$lt_simple_compile_test_code"
 # ltmain only uses $CC for tagged configurations so make sure $CC is set.
 _LT_AC_SYS_COMPILER
 
+# save warnings/boilerplate of simple test code
+_LT_COMPILER_BOILERPLATE
+_LT_LINKER_BOILERPLATE
+
 # Allow CC to be a program name with arguments.
 lt_save_CC="$CC"
 CC=${RC-"windres"}
 compiler=$CC
 _LT_AC_TAGVAR(compiler, $1)=$CC
+_LT_CC_BASENAME([$compiler])
 _LT_AC_TAGVAR(lt_cv_prog_compiler_c_o, $1)=yes
 
 AC_LIBTOOL_CONFIG($1)
@@ -3878,7 +4292,7 @@ if test -f "$ltmain"; then
   # Now quote all the things that may contain metacharacters while being
   # careful not to overquote the AC_SUBSTed values.  We take copies of the
   # variables and quote the copies for generation of the libtool script.
-  for var in echo old_CC old_CFLAGS AR AR_FLAGS EGREP RANLIB LN_S LTCC NM \
+  for var in echo old_CC old_CFLAGS AR AR_FLAGS EGREP RANLIB LN_S LTCC LTCFLAGS NM \
     SED SHELL STRIP \
     libname_spec library_names_spec soname_spec extract_expsyms_cmds \
     old_striplib striplib file_magic_cmd finish_cmds finish_eval \
@@ -3905,6 +4319,7 @@ if test -f "$ltmain"; then
     _LT_AC_TAGVAR(predeps, $1) \
     _LT_AC_TAGVAR(postdeps, $1) \
     _LT_AC_TAGVAR(compiler_lib_search_path, $1) \
+    _LT_AC_TAGVAR(compiler_lib_search_dirs, $1) \
     _LT_AC_TAGVAR(archive_cmds, $1) \
     _LT_AC_TAGVAR(archive_expsym_cmds, $1) \
     _LT_AC_TAGVAR(postinstall_cmds, $1) \
@@ -3920,6 +4335,7 @@ if test -f "$ltmain"; then
     _LT_AC_TAGVAR(module_cmds, $1) \
     _LT_AC_TAGVAR(module_expsym_cmds, $1) \
     _LT_AC_TAGVAR(lt_cv_prog_compiler_c_o, $1) \
+    _LT_AC_TAGVAR(fix_srcfile_path, $1) \
     _LT_AC_TAGVAR(exclude_expsyms, $1) \
     _LT_AC_TAGVAR(include_expsyms, $1); do
 
@@ -3966,7 +4382,7 @@ ifelse([$1], [],
 # Generated automatically by $PROGRAM (GNU $PACKAGE $VERSION$TIMESTAMP)
 # NOTE: Changes made to this file will be lost: look at ltmain.sh.
 #
-# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001
+# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008
 # Free Software Foundation, Inc.
 #
 # This file is part of GNU Libtool:
@@ -3984,7 +4400,7 @@ ifelse([$1], [],
 #
 # You should have received a copy of the GNU General Public License
 # along with this program; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 #
 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
@@ -3995,7 +4411,7 @@ ifelse([$1], [],
 SED=$lt_SED
 
 # Sed that helps us avoid accidentally triggering echo(1) options like -n.
-Xsed="$SED -e s/^X//"
+Xsed="$SED -e 1s/^X//"
 
 # The HP-UX ksh and POSIX shell print the target directory to stdout
 # if CDPATH is set.
@@ -4030,6 +4446,12 @@ fast_install=$enable_fast_install
 # The host system.
 host_alias=$host_alias
 host=$host
+host_os=$host_os
+
+# The build system.
+build_alias=$build_alias
+build=$build
+build_os=$build_os
 
 # An echo program that does not interpret backslashes.
 echo=$lt_echo
@@ -4041,6 +4463,9 @@ AR_FLAGS=$lt_AR_FLAGS
 # A C compiler.
 LTCC=$lt_LTCC
 
+# LTCC compiler flags.
+LTCFLAGS=$lt_LTCFLAGS
+
 # A language-specific compiler.
 CC=$lt_[]_LT_AC_TAGVAR(compiler, $1)
 
@@ -4106,7 +4531,7 @@ max_cmd_len=$lt_cv_sys_max_cmd_len
 # Does compiler simultaneously support -c and -o options?
 compiler_c_o=$lt_[]_LT_AC_TAGVAR(lt_cv_prog_compiler_c_o, $1)
 
-# Must we lock files when doing compilation ?
+# Must we lock files when doing compilation?
 need_locks=$lt_need_locks
 
 # Do we need the lib prefix for modules?
@@ -4194,6 +4619,10 @@ predeps=$lt_[]_LT_AC_TAGVAR(predeps, $1)
 # shared library.
 postdeps=$lt_[]_LT_AC_TAGVAR(postdeps, $1)
 
+# The directories searched by this compiler when creating a shared
+# library
+compiler_lib_search_dirs=$lt_[]_LT_AC_TAGVAR(compiler_lib_search_dirs, $1)
+
 # The library search path used internally by the compiler when linking
 # a shared library.
 compiler_lib_search_path=$lt_[]_LT_AC_TAGVAR(compiler_lib_search_path, $1)
@@ -4282,7 +4711,7 @@ sys_lib_search_path_spec=$lt_sys_lib_search_path_spec
 sys_lib_dlsearch_path_spec=$lt_sys_lib_dlsearch_path_spec
 
 # Fix the shell variable \$srcfile for the compiler.
-fix_srcfile_path="$_LT_AC_TAGVAR(fix_srcfile_path, $1)"
+fix_srcfile_path=$lt_fix_srcfile_path
 
 # Set to yes if exported symbols are required.
 always_export_symbols=$_LT_AC_TAGVAR(always_export_symbols, $1)
@@ -4365,6 +4794,7 @@ fi
 # ---------------------------------
 AC_DEFUN([AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE],
 [AC_REQUIRE([AC_CANONICAL_HOST])
+AC_REQUIRE([LT_AC_PROG_SED])
 AC_REQUIRE([AC_PROG_NM])
 AC_REQUIRE([AC_OBJEXT])
 # Check for command to grab the raw symbol name followed by C symbol from nm.
@@ -4380,9 +4810,6 @@ symcode='[[BCDEGRST]]'
 # Regexp to match symbols that can be accessed directly from C.
 sympat='\([[_A-Za-z]][[_A-Za-z0-9]]*\)'
 
-# Transform the above into a raw symbol and a C symbol.
-symxfrm='\1 \2\3 \3'
-
 # Transform an extracted symbol line into a proper C declaration
 lt_cv_sys_global_symbol_to_cdecl="sed -n -e 's/^. .* \(.*\)$/extern int \1;/p'"
 
@@ -4404,7 +4831,7 @@ hpux*) # Its linker distinguishes data from code symbols
   lt_cv_sys_global_symbol_to_cdecl="sed -n -e 's/^T .* \(.*\)$/extern int \1();/p' -e 's/^$symcode* .* \(.*\)$/extern char \1;/p'"
   lt_cv_sys_global_symbol_to_c_name_address="sed -n -e 's/^: \([[^ ]]*\) $/  {\\\"\1\\\", (lt_ptr) 0},/p' -e 's/^$symcode* \([[^ ]]*\) \([[^ ]]*\)$/  {\"\2\", (lt_ptr) \&\2},/p'"
   ;;
-linux*)
+linux* | k*bsd*-gnu)
   if test "$host_cpu" = ia64; then
     symcode='[[ABCDGIRSTW]]'
     lt_cv_sys_global_symbol_to_cdecl="sed -n -e 's/^T .* \(.*\)$/extern int \1();/p' -e 's/^$symcode* .* \(.*\)$/extern char \1;/p'"
@@ -4417,9 +4844,18 @@ irix* | nonstopux*)
 osf*)
   symcode='[[BCDEGQRST]]'
   ;;
-solaris* | sysv5*)
+solaris*)
   symcode='[[BDRT]]'
   ;;
+sco3.2v5*)
+  symcode='[[DT]]'
+  ;;
+sysv4.2uw2*)
+  symcode='[[DT]]'
+  ;;
+sysv5* | sco5v6* | unixware* | OpenUNIX*)
+  symcode='[[ABDT]]'
+  ;;
 sysv4)
   symcode='[[DFNSTU]]'
   ;;
@@ -4442,8 +4878,11 @@ esac
 # Try without a prefix undercore, then with it.
 for ac_symprfx in "" "_"; do
 
+  # Transform symcode, sympat, and symprfx into a raw symbol and a C symbol.
+  symxfrm="\\1 $ac_symprfx\\2 \\2"
+
   # Write the raw and C identifiers.
-  lt_cv_sys_global_symbol_pipe="sed -n -e 's/^.*[[ 	]]\($symcode$symcode*\)[[ 	]][[ 	]]*\($ac_symprfx\)$sympat$opt_cr$/$symxfrm/p'"
+  lt_cv_sys_global_symbol_pipe="sed -n -e 's/^.*[[ 	]]\($symcode$symcode*\)[[ 	]][[ 	]]*$ac_symprfx$sympat$opt_cr$/$symxfrm/p'"
 
   # Check to see that the pipe works correctly.
   pipe_works=no
@@ -4533,7 +4972,7 @@ EOF
     echo "$progname: failed program was:" >&AS_MESSAGE_LOG_FD
     cat conftest.$ac_ext >&5
   fi
-  rm -f conftest* conftst*
+  rm -rf conftest* conftst*
 
   # Do not use the global_symbol_pipe unless it works.
   if test "$pipe_works" = yes; then
@@ -4582,13 +5021,16 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
       # like `-m68040'.
       _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-m68020 -resident32 -malways-restore-a4'
       ;;
-    beos* | cygwin* | irix5* | irix6* | nonstopux* | osf3* | osf4* | osf5*)
+    beos* | irix5* | irix6* | nonstopux* | osf3* | osf4* | osf5*)
       # PIC is the default for these OSes.
       ;;
-    mingw* | os2* | pw32*)
+    mingw* | cygwin* | os2* | pw32*)
       # This hack is so that the source file can tell whether it is being
       # built for inclusion in a dll (and should export symbols for example).
-      _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-DDLL_EXPORT'
+      # Although the cygwin gcc ignores -fPIC, still need this for old-style
+      # (--disable-auto-import) libraries
+      m4_if([$1], [GCJ], [],
+	[_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-DDLL_EXPORT'])
       ;;
     darwin* | rhapsody*)
       # PIC is the default on this platform
@@ -4599,6 +5041,10 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
       # DJGPP does not support shared libraries at all
       _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)=
       ;;
+    interix[[3-9]]*)
+      # Interix 3.x gcc -fpic/-fPIC options generate broken code.
+      # Instead, we relocate shared libraries at runtime.
+      ;;
     sysv4*MP*)
       if test -d /usr/nec; then
 	_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)=-Kconform_pic
@@ -4607,7 +5053,7 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
     hpux*)
       # PIC is the default for IA64 HP-UX and 64-bit HP-UX, but
       # not for PA HP-UX.
-      case "$host_cpu" in
+      case $host_cpu in
       hppa*64*|ia64*)
 	;;
       *)
@@ -4621,7 +5067,7 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
     esac
   else
     case $host_os in
-      aix4* | aix5*)
+      aix[[4-9]]*)
 	# All AIX code is PIC.
 	if test "$host_cpu" = ia64; then
 	  # AIX 5 now supports IA64 processor
@@ -4632,7 +5078,7 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
 	;;
       chorus*)
 	case $cc_basename in
-	cxch68)
+	cxch68*)
 	  # Green Hills C++ Compiler
 	  # _LT_AC_TAGVAR(lt_prog_compiler_static, $1)="--no_auto_instantiation -u __main -u __premain -u _abort -r $COOL_DIR/lib/libOrb.a $MVME_DIR/lib/CC/libC.a $MVME_DIR/lib/classix/libcx.s.a"
 	  ;;
@@ -4641,7 +5087,7 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
        darwin*)
          # PIC is the default on this platform
          # Common symbols not allowed in MH_DYLIB files
-         case "$cc_basename" in
+         case $cc_basename in
            xlc*)
            _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-qnocommon'
            _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
@@ -4650,10 +5096,10 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
        ;;
       dgux*)
 	case $cc_basename in
-	  ec++)
+	  ec++*)
 	    _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
 	    ;;
-	  ghcx)
+	  ghcx*)
 	    # Green Hills C++ Compiler
 	    _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-pic'
 	    ;;
@@ -4661,22 +5107,22 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
 	    ;;
 	esac
 	;;
-      freebsd* | kfreebsd*-gnu)
+      freebsd* | dragonfly*)
 	# FreeBSD uses GNU C++
 	;;
       hpux9* | hpux10* | hpux11*)
 	case $cc_basename in
-	  CC)
+	  CC*)
 	    _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
-	    _LT_AC_TAGVAR(lt_prog_compiler_static, $1)="${ac_cv_prog_cc_wl}-a ${ac_cv_prog_cc_wl}archive"
+	    _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='${wl}-a ${wl}archive'
 	    if test "$host_cpu" != ia64; then
 	      _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='+Z'
 	    fi
 	    ;;
-	  aCC)
+	  aCC*)
 	    _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
-	    _LT_AC_TAGVAR(lt_prog_compiler_static, $1)="${ac_cv_prog_cc_wl}-a ${ac_cv_prog_cc_wl}archive"
-	    case "$host_cpu" in
+	    _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='${wl}-a ${wl}archive'
+	    case $host_cpu in
 	    hppa*64*|ia64*)
 	      # +Z the default
 	      ;;
@@ -4689,9 +5135,13 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
 	    ;;
 	esac
 	;;
+      interix*)
+	# This is c89, which is MS Visual C++ (no shared libs)
+	# Anyone wants to do a port?
+	;;
       irix5* | irix6* | nonstopux*)
 	case $cc_basename in
-	  CC)
+	  CC*)
 	    _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
 	    _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
 	    # CC pic flag -KPIC is the default.
@@ -4700,20 +5150,26 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
 	    ;;
 	esac
 	;;
-      linux*)
+      linux* | k*bsd*-gnu)
 	case $cc_basename in
-	  KCC)
+	  KCC*)
 	    # KAI C++ Compiler
 	    _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='--backend -Wl,'
 	    _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
 	    ;;
-	  icpc)
+	  icpc* | ecpc*)
 	    # Intel C++
 	    _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
 	    _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
 	    _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-static'
 	    ;;
-	  cxx)
+	  pgCC* | pgcpp*)
+	    # Portland Group C++ compiler.
+	    _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+	    _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-fpic'
+	    _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+	    ;;
+	  cxx*)
 	    # Compaq C++
 	    # Make sure the PIC flag is empty.  It appears that all Alpha
 	    # Linux and Compaq Tru64 Unix objects are PIC.
@@ -4721,6 +5177,14 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
 	    _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
 	    ;;
 	  *)
+	    case `$CC -V 2>&1 | sed 5q` in
+	    *Sun\ C*)
+	      # Sun C++ 5.9
+	      _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+	      _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+	      _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Qoption ld '
+	      ;;
+	    esac
 	    ;;
 	esac
 	;;
@@ -4730,7 +5194,7 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
 	;;
       mvs*)
 	case $cc_basename in
-	  cxx)
+	  cxx*)
 	    _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-W c,exportall'
 	    ;;
 	  *)
@@ -4741,14 +5205,14 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
 	;;
       osf3* | osf4* | osf5*)
 	case $cc_basename in
-	  KCC)
+	  KCC*)
 	    _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='--backend -Wl,'
 	    ;;
-	  RCC)
+	  RCC*)
 	    # Rational C++ 2.4.1
 	    _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-pic'
 	    ;;
-	  cxx)
+	  cxx*)
 	    # Digital/Compaq C++
 	    _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
 	    # Make sure the PIC flag is empty.  It appears that all Alpha
@@ -4762,24 +5226,15 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
 	;;
       psos*)
 	;;
-      sco*)
-	case $cc_basename in
-	  CC)
-	    _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
-	    ;;
-	  *)
-	    ;;
-	esac
-	;;
       solaris*)
 	case $cc_basename in
-	  CC)
+	  CC*)
 	    # Sun C++ 4.2, 5.x and Centerline C++
 	    _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
 	    _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
 	    _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Qoption ld '
 	    ;;
-	  gcx)
+	  gcx*)
 	    # Green Hills C++ Compiler
 	    _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-PIC'
 	    ;;
@@ -4789,12 +5244,12 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
 	;;
       sunos4*)
 	case $cc_basename in
-	  CC)
+	  CC*)
 	    # Sun C++ 4.x
 	    _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-pic'
 	    _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
 	    ;;
-	  lcc)
+	  lcc*)
 	    # Lucid
 	    _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-pic'
 	    ;;
@@ -4804,7 +5259,7 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
 	;;
       tandem*)
 	case $cc_basename in
-	  NCC)
+	  NCC*)
 	    # NonStop-UX NCC 3.20
 	    _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
 	    ;;
@@ -4812,7 +5267,14 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
 	    ;;
 	esac
 	;;
-      unixware*)
+      sysv5* | unixware* | sco3.2v5* | sco5v6* | OpenUNIX*)
+	case $cc_basename in
+	  CC*)
+	    _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+	    _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+	    _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+	    ;;
+	esac
 	;;
       vxworks*)
 	;;
@@ -4843,14 +5305,17 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
       _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-m68020 -resident32 -malways-restore-a4'
       ;;
 
-    beos* | cygwin* | irix5* | irix6* | nonstopux* | osf3* | osf4* | osf5*)
+    beos* | irix5* | irix6* | nonstopux* | osf3* | osf4* | osf5*)
       # PIC is the default for these OSes.
       ;;
 
-    mingw* | pw32* | os2*)
+    mingw* | cygwin* | pw32* | os2*)
       # This hack is so that the source file can tell whether it is being
       # built for inclusion in a dll (and should export symbols for example).
-      _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-DDLL_EXPORT'
+      # Although the cygwin gcc ignores -fPIC, still need this for old-style
+      # (--disable-auto-import) libraries
+      m4_if([$1], [GCJ], [],
+	[_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-DDLL_EXPORT'])
       ;;
 
     darwin* | rhapsody*)
@@ -4859,6 +5324,11 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
       _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-fno-common'
       ;;
 
+    interix[[3-9]]*)
+      # Interix 3.x gcc -fpic/-fPIC options generate broken code.
+      # Instead, we relocate shared libraries at runtime.
+      ;;
+
     msdosdjgpp*)
       # Just because we use GCC doesn't mean we suddenly get shared libraries
       # on systems that don't support them.
@@ -4875,7 +5345,7 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
     hpux*)
       # PIC is the default for IA64 HP-UX and 64-bit HP-UX, but
       # not for PA HP-UX.
-      case "$host_cpu" in
+      case $host_cpu in
       hppa*64*|ia64*)
 	# +Z the default
 	;;
@@ -4904,7 +5374,7 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
       darwin*)
         # PIC is the default on this platform
         # Common symbols not allowed in MH_DYLIB files
-       case "$cc_basename" in
+       case $cc_basename in
          xlc*)
          _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-qnocommon'
          _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
@@ -4912,17 +5382,18 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
        esac
        ;;
 
-    mingw* | pw32* | os2*)
+    mingw* | cygwin* | pw32* | os2*)
       # This hack is so that the source file can tell whether it is being
       # built for inclusion in a dll (and should export symbols for example).
-      _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-DDLL_EXPORT'
+      m4_if([$1], [GCJ], [],
+	[_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-DDLL_EXPORT'])
       ;;
 
     hpux9* | hpux10* | hpux11*)
       _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
       # PIC is the default for IA64 HP-UX and 64-bit HP-UX, but
       # not for PA HP-UX.
-      case "$host_cpu" in
+      case $host_cpu in
       hppa*64*|ia64*)
 	# +Z the default
 	;;
@@ -4945,18 +5416,41 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
       _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
       ;;
 
-    linux*)
-      case $CC in
+    linux* | k*bsd*-gnu)
+      case $cc_basename in
       icc* | ecc*)
 	_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
 	_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
 	_LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-static'
         ;;
+      pgcc* | pgf77* | pgf90* | pgf95*)
+        # Portland Group compilers (*not* the Pentium gcc compiler,
+	# which looks to be a dead project)
+	_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+	_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-fpic'
+	_LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+        ;;
       ccc*)
         _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
         # All Alpha code is PIC.
         _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
         ;;
+      *)
+        case `$CC -V 2>&1 | sed 5q` in
+	*Sun\ C*)
+	  # Sun C 5.9
+	  _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+	  _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+	  _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+	  ;;
+	*Sun\ F*)
+	  # Sun Fortran 8.3 passes all unrecognized flags to the linker
+	  _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+	  _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+	  _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)=''
+	  ;;
+	esac
+	;;
       esac
       ;;
 
@@ -4966,15 +5460,19 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
       _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
       ;;
 
-    sco3.2v5*)
-      _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-Kpic'
-      _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-dn'
+    rdos*)
+      _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
       ;;
 
     solaris*)
-      _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
       _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
       _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+      case $cc_basename in
+      f77* | f90* | f95*)
+	_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Qoption ld ';;
+      *)
+	_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,';;
+      esac
       ;;
 
     sunos4*)
@@ -4983,7 +5481,7 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
       _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
       ;;
 
-    sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+    sysv4 | sysv4.2uw2* | sysv4.3*)
       _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
       _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
       _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
@@ -4996,6 +5494,17 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
       fi
       ;;
 
+    sysv5* | unixware* | sco3.2v5* | sco5v6* | OpenUNIX*)
+      _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+      _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+      _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+      ;;
+
+    unicos*)
+      _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+      _LT_AC_TAGVAR(lt_prog_compiler_can_build_shared, $1)=no
+      ;;
+
     uts4*)
       _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-pic'
       _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
@@ -5014,7 +5523,7 @@ AC_MSG_RESULT([$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)])
 #
 if test -n "$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)"; then
   AC_LIBTOOL_COMPILER_OPTION([if $compiler PIC flag $_LT_AC_TAGVAR(lt_prog_compiler_pic, $1) works],
-    _LT_AC_TAGVAR(lt_prog_compiler_pic_works, $1),
+    _LT_AC_TAGVAR(lt_cv_prog_compiler_pic_works, $1),
     [$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)ifelse([$1],[],[ -DPIC],[ifelse([$1],[CXX],[ -DPIC],[])])], [],
     [case $_LT_AC_TAGVAR(lt_prog_compiler_pic, $1) in
      "" | " "*) ;;
@@ -5023,7 +5532,7 @@ if test -n "$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)"; then
     [_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)=
      _LT_AC_TAGVAR(lt_prog_compiler_can_build_shared, $1)=no])
 fi
-case "$host_os" in
+case $host_os in
   # For platforms which do not support PIC, -DPIC is meaningless:
   *djgpp*)
     _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)=
@@ -5032,6 +5541,16 @@ case "$host_os" in
     _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)="$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)ifelse([$1],[],[ -DPIC],[ifelse([$1],[CXX],[ -DPIC],[])])"
     ;;
 esac
+
+#
+# Check to make sure the static flag actually works.
+#
+wl=$_LT_AC_TAGVAR(lt_prog_compiler_wl, $1) eval lt_tmp_static_flag=\"$_LT_AC_TAGVAR(lt_prog_compiler_static, $1)\"
+AC_LIBTOOL_LINKER_OPTION([if $compiler static flag $lt_tmp_static_flag works],
+  _LT_AC_TAGVAR(lt_cv_prog_compiler_static_works, $1),
+  $lt_tmp_static_flag,
+  [],
+  [_LT_AC_TAGVAR(lt_prog_compiler_static, $1)=])
 ])
 
 
@@ -5039,11 +5558,12 @@ esac
 # ------------------------------------
 # See if the linker supports building shared libraries.
 AC_DEFUN([AC_LIBTOOL_PROG_LD_SHLIBS],
-[AC_MSG_CHECKING([whether the $compiler linker ($LD) supports shared libraries])
+[AC_REQUIRE([LT_AC_PROG_SED])dnl
+AC_MSG_CHECKING([whether the $compiler linker ($LD) supports shared libraries])
 ifelse([$1],[CXX],[
   _LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED '\''s/.* //'\'' | sort | uniq > $export_symbols'
   case $host_os in
-  aix4* | aix5*)
+  aix[[4-9]]*)
     # If we're using GNU nm, then we don't want the "-C" option.
     # -C means demangle to AIX nm, but means don't demangle with GNU nm
     if $NM -V 2>&1 | grep 'GNU' > /dev/null; then
@@ -5056,12 +5576,13 @@ ifelse([$1],[CXX],[
     _LT_AC_TAGVAR(export_symbols_cmds, $1)="$ltdll_cmds"
   ;;
   cygwin* | mingw*)
-    _LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED -e '\''/^[[BCDGS]] /s/.* \([[^ ]]*\)/\1 DATA/'\'' | $SED -e '\''/^[[AITW]] /s/.* //'\'' | sort | uniq > $export_symbols'
+    _LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED -e '\''/^[[BCDGRS]][[ ]]/s/.*[[ ]]\([[^ ]]*\)/\1 DATA/;/^.*[[ ]]__nm__/s/^.*[[ ]]__nm__\([[^ ]]*\)[[ ]][[^ ]]*/\1 DATA/;/^I[[ ]]/d;/^[[AITW]][[ ]]/s/.*[[ ]]//'\'' | sort | uniq > $export_symbols'
   ;;
   *)
     _LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED '\''s/.* //'\'' | sort | uniq > $export_symbols'
   ;;
   esac
+  _LT_AC_TAGVAR(exclude_expsyms, $1)=['_GLOBAL_OFFSET_TABLE_|_GLOBAL__F[ID]_.*']
 ],[
   runpath_var=
   _LT_AC_TAGVAR(allow_undefined_flag, $1)=
@@ -5092,14 +5613,17 @@ ifelse([$1],[CXX],[
   # it will be wrapped by ` (' and `)$', so one must not match beginning or
   # end of line.  Example: `a|bc|.*d.*' will exclude the symbols `a' and `bc',
   # as well as any symbol that contains `d'.
-  _LT_AC_TAGVAR(exclude_expsyms, $1)="_GLOBAL_OFFSET_TABLE_"
+  _LT_AC_TAGVAR(exclude_expsyms, $1)=['_GLOBAL_OFFSET_TABLE_|_GLOBAL__F[ID]_.*']
   # Although _GLOBAL_OFFSET_TABLE_ is a valid symbol C name, most a.out
   # platforms (ab)use it in PIC code, but their linkers get confused if
   # the symbol is explicitly referenced.  Since portable code cannot
   # rely on this symbol name, it's probably fine to never include it in
   # preloaded symbol tables.
+  # Exclude shared library initialization/finalization symbols.
+dnl Note also adjust exclude_expsyms for C++ above.
   extract_expsyms_cmds=
-
+  # Just being paranoid about ensuring that cc_basename is set.
+  _LT_CC_BASENAME([$compiler])
   case $host_os in
   cygwin* | mingw* | pw32*)
     # FIXME: the MSVC++ port hasn't been tested in a loooong time
@@ -5109,6 +5633,10 @@ ifelse([$1],[CXX],[
       with_gnu_ld=no
     fi
     ;;
+  interix*)
+    # we just hope/assume this is gcc and not c89 (= MSVC++)
+    with_gnu_ld=yes
+    ;;
   openbsd*)
     with_gnu_ld=no
     ;;
@@ -5119,9 +5647,30 @@ ifelse([$1],[CXX],[
     # If archive_cmds runs LD, not CC, wlarc should be empty
     wlarc='${wl}'
 
+    # Set some defaults for GNU ld with shared library support. These
+    # are reset later if shared libraries are not supported. Putting them
+    # here allows them to be overridden if necessary.
+    runpath_var=LD_RUN_PATH
+    _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}--rpath ${wl}$libdir'
+    _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-dynamic'
+    # ancient GNU ld didn't support --whole-archive et. al.
+    if $LD --help 2>&1 | grep 'no-whole-archive' > /dev/null; then
+	_LT_AC_TAGVAR(whole_archive_flag_spec, $1)="$wlarc"'--whole-archive$convenience '"$wlarc"'--no-whole-archive'
+      else
+  	_LT_AC_TAGVAR(whole_archive_flag_spec, $1)=
+    fi
+    supports_anon_versioning=no
+    case `$LD -v 2>/dev/null` in
+      *\ [[01]].* | *\ 2.[[0-9]].* | *\ 2.10.*) ;; # catch versions < 2.11
+      *\ 2.11.93.0.2\ *) supports_anon_versioning=yes ;; # RH7.3 ...
+      *\ 2.11.92.0.12\ *) supports_anon_versioning=yes ;; # Mandrake 8.2 ...
+      *\ 2.11.*) ;; # other 2.11 versions
+      *) supports_anon_versioning=yes ;;
+    esac
+
     # See if GNU ld supports shared libraries.
     case $host_os in
-    aix3* | aix4* | aix5*)
+    aix[[3-9]]*)
       # On AIX/PPC, the GNU linker is very broken
       if test "$host_cpu" != ia64; then
 	_LT_AC_TAGVAR(ld_shlibs, $1)=no
@@ -5169,10 +5718,10 @@ EOF
       _LT_AC_TAGVAR(allow_undefined_flag, $1)=unsupported
       _LT_AC_TAGVAR(always_export_symbols, $1)=no
       _LT_AC_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
-      _LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED -e '\''/^[[BCDGS]] /s/.* \([[^ ]]*\)/\1 DATA/'\'' | $SED -e '\''/^[[AITW]] /s/.* //'\'' | sort | uniq > $export_symbols'
+      _LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED -e '\''/^[[BCDGRS]][[ ]]/s/.*[[ ]]\([[^ ]]*\)/\1 DATA/'\'' -e '\''/^[[AITW]][[ ]]/s/.*[[ ]]//'\'' | sort | uniq > $export_symbols'
 
       if $LD --help 2>&1 | grep 'auto-import' > /dev/null; then
-        _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--image-base=0x10000000 ${wl}--out-implib,$lib'
+        _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
 	# If the export-symbols file already is a .def file (1st line
 	# is EXPORTS), use it as is; otherwise, prepend...
 	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='if test "x`$SED 1q $export_symbols`" = xEXPORTS; then
@@ -5181,9 +5730,64 @@ EOF
 	  echo EXPORTS > $output_objdir/$soname.def;
 	  cat $export_symbols >> $output_objdir/$soname.def;
 	fi~
-	$CC -shared $output_objdir/$soname.def $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--image-base=0x10000000  ${wl}--out-implib,$lib'
+	$CC -shared $output_objdir/$soname.def $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
+      else
+	_LT_AC_TAGVAR(ld_shlibs, $1)=no
+      fi
+      ;;
+
+    interix[[3-9]]*)
+      _LT_AC_TAGVAR(hardcode_direct, $1)=no
+      _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+      _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
+      _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
+      # Hack: On Interix 3.x, we cannot compile PIC because of a broken gcc.
+      # Instead, shared libraries are loaded at an image base (0x10000000 by
+      # default) and relocated if they conflict, which is a slow very memory
+      # consuming and fragmenting process.  To avoid this, we pick a random,
+      # 256 KiB-aligned image base between 0x50000000 and 0x6FFC0000 at link
+      # time.  Moving up from 0x10000000 also allows more sbrk(2) space.
+      _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
+      _LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed "s,^,_," $export_symbols >$output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--retain-symbols-file,$output_objdir/$soname.expsym ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
+      ;;
+
+    gnu* | linux* | k*bsd*-gnu)
+      if $LD --help 2>&1 | grep ': supported targets:.* elf' > /dev/null; then
+	tmp_addflag=
+	case $cc_basename,$host_cpu in
+	pgcc*)				# Portland Group C compiler
+	  _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-archive`for conv in $convenience\"\"; do test  -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
+	  tmp_addflag=' $pic_flag'
+	  ;;
+	pgf77* | pgf90* | pgf95*)	# Portland Group f77 and f90 compilers
+	  _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-archive`for conv in $convenience\"\"; do test  -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
+	  tmp_addflag=' $pic_flag -Mnomain' ;;
+	ecc*,ia64* | icc*,ia64*)		# Intel C compiler on ia64
+	  tmp_addflag=' -i_dynamic' ;;
+	efc*,ia64* | ifort*,ia64*)	# Intel Fortran compiler on ia64
+	  tmp_addflag=' -i_dynamic -nofor_main' ;;
+	ifc* | ifort*)			# Intel Fortran compiler
+	  tmp_addflag=' -nofor_main' ;;
+	esac
+	case `$CC -V 2>&1 | sed 5q` in
+	*Sun\ C*)			# Sun C 5.9
+	  _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-archive`new_convenience=; for conv in $convenience\"\"; do test -z \"$conv\" || new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
+	  tmp_sharedflag='-G' ;;
+	*Sun\ F*)			# Sun Fortran 8.3
+	  tmp_sharedflag='-G' ;;
+	*)
+	  tmp_sharedflag='-shared' ;;
+	esac
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC '"$tmp_sharedflag""$tmp_addflag"' $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
+
+	if test $supports_anon_versioning = yes; then
+	  _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$echo "{ global:" > $output_objdir/$libname.ver~
+  cat $export_symbols | sed -e "s/\(.*\)/\1;/" >> $output_objdir/$libname.ver~
+  $echo "local: *; };" >> $output_objdir/$libname.ver~
+	  $CC '"$tmp_sharedflag""$tmp_addflag"' $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname ${wl}-version-script ${wl}$output_objdir/$libname.ver -o $lib'
+	fi
       else
-	ld_shlibs=no
+	_LT_AC_TAGVAR(ld_shlibs, $1)=no
       fi
       ;;
 
@@ -5197,7 +5801,7 @@ EOF
       fi
       ;;
 
-    solaris* | sysv5*)
+    solaris*)
       if $LD -v 2>&1 | grep 'BFD 2\.8' > /dev/null; then
 	_LT_AC_TAGVAR(ld_shlibs, $1)=no
 	cat <<EOF 1>&2
@@ -5218,6 +5822,33 @@ EOF
       fi
       ;;
 
+    sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX*)
+      case `$LD -v 2>&1` in
+        *\ [[01]].* | *\ 2.[[0-9]].* | *\ 2.1[[0-5]].*)
+	_LT_AC_TAGVAR(ld_shlibs, $1)=no
+	cat <<_LT_EOF 1>&2
+
+*** Warning: Releases of the GNU linker prior to 2.16.91.0.3 can not
+*** reliably create shared libraries on SCO systems.  Therefore, libtool
+*** is disabling shared libraries support.  We urge you to upgrade GNU
+*** binutils to release 2.16.91.0.3 or newer.  Another option is to modify
+*** your PATH or compiler configuration so that the native linker is
+*** used, and then restart.
+
+_LT_EOF
+	;;
+	*)
+	  if $LD --help 2>&1 | grep ': supported targets:.* elf' > /dev/null; then
+	    _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='`test -z "$SCOABSPATH" && echo ${wl}-rpath,$libdir`'
+	    _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib'
+	    _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname,\${SCOABSPATH:+${install_libdir}/}$soname,-retain-symbols-file,$export_symbols -o $lib'
+	  else
+	    _LT_AC_TAGVAR(ld_shlibs, $1)=no
+	  fi
+	;;
+      esac
+      ;;
+
     sunos4*)
       _LT_AC_TAGVAR(archive_cmds, $1)='$LD -assert pure-text -Bshareable -o $lib $libobjs $deplibs $linker_flags'
       wlarc=
@@ -5225,31 +5856,6 @@ EOF
       _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
       ;;
 
-  linux*)
-    if $LD --help 2>&1 | grep ': supported targets:.* elf' > /dev/null; then
-        tmp_archive_cmds='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
-	_LT_AC_TAGVAR(archive_cmds, $1)="$tmp_archive_cmds"
-      supports_anon_versioning=no
-      case `$LD -v 2>/dev/null` in
-        *\ [01].* | *\ 2.[[0-9]].* | *\ 2.10.*) ;; # catch versions < 2.11
-        *\ 2.11.93.0.2\ *) supports_anon_versioning=yes ;; # RH7.3 ...
-        *\ 2.11.92.0.12\ *) supports_anon_versioning=yes ;; # Mandrake 8.2 ...
-        *\ 2.11.*) ;; # other 2.11 versions
-        *) supports_anon_versioning=yes ;;
-      esac
-      if test $supports_anon_versioning = yes; then
-        _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$echo "{ global:" > $output_objdir/$libname.ver~
-cat $export_symbols | sed -e "s/\(.*\)/\1;/" >> $output_objdir/$libname.ver~
-$echo "local: *; };" >> $output_objdir/$libname.ver~
-        $CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname ${wl}-version-script ${wl}$output_objdir/$libname.ver -o $lib'
-      else
-        _LT_AC_TAGVAR(archive_expsym_cmds, $1)="$tmp_archive_cmds"
-      fi
-    else
-      _LT_AC_TAGVAR(ld_shlibs, $1)=no
-    fi
-    ;;
-
     *)
       if $LD --help 2>&1 | grep ': supported targets:.* elf' > /dev/null; then
 	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
@@ -5260,16 +5866,11 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
       ;;
     esac
 
-    if test "$_LT_AC_TAGVAR(ld_shlibs, $1)" = yes; then
-      runpath_var=LD_RUN_PATH
-      _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}--rpath ${wl}$libdir'
-      _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-dynamic'
-      # ancient GNU ld didn't support --whole-archive et. al.
-      if $LD --help 2>&1 | grep 'no-whole-archive' > /dev/null; then
- 	_LT_AC_TAGVAR(whole_archive_flag_spec, $1)="$wlarc"'--whole-archive$convenience '"$wlarc"'--no-whole-archive'
-      else
-  	_LT_AC_TAGVAR(whole_archive_flag_spec, $1)=
-      fi
+    if test "$_LT_AC_TAGVAR(ld_shlibs, $1)" = no; then
+      runpath_var=
+      _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)=
+      _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)=
+      _LT_AC_TAGVAR(whole_archive_flag_spec, $1)=
     fi
   else
     # PORTME fill in a description of your system's linker (not GNU ld)
@@ -5281,14 +5882,14 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
       # Note: this linker hardcodes the directories in LIBPATH if there
       # are no directories specified by -L.
       _LT_AC_TAGVAR(hardcode_minus_L, $1)=yes
-      if test "$GCC" = yes && test -z "$link_static_flag"; then
+      if test "$GCC" = yes && test -z "$lt_prog_compiler_static"; then
 	# Neither direct hardcoding nor static linking is supported with a
 	# broken collect2.
 	_LT_AC_TAGVAR(hardcode_direct, $1)=unsupported
       fi
       ;;
 
-    aix4* | aix5*)
+    aix[[4-9]]*)
       if test "$host_cpu" = ia64; then
 	# On IA64, the linker does run time linking by default, so we don't
 	# have to do anything special.
@@ -5308,13 +5909,14 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
 	# Test if we are trying to use run time linking or normal
 	# AIX style linking. If -brtl is somewhere in LDFLAGS, we
 	# need to do runtime linking.
-	case $host_os in aix4.[[23]]|aix4.[[23]].*|aix5*)
+	case $host_os in aix4.[[23]]|aix4.[[23]].*|aix[[5-9]]*)
 	  for ld_flag in $LDFLAGS; do
   	  if (test $ld_flag = "-brtl" || test $ld_flag = "-Wl,-brtl"); then
   	    aix_use_runtimelinking=yes
   	    break
   	  fi
 	  done
+	  ;;
 	esac
 
 	exp_sym_flag='-bexport'
@@ -5333,7 +5935,7 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
       _LT_AC_TAGVAR(link_all_deplibs, $1)=yes
 
       if test "$GCC" = yes; then
-	case $host_os in aix4.[012]|aix4.[012].*)
+	case $host_os in aix4.[[012]]|aix4.[[012]].*)
 	# We only want to do this on AIX 4.2 and lower, the check
 	# below for broken collect2 doesn't work under 4.3+
 	  collect2name=`${CC} -print-prog-name=collect2`
@@ -5341,7 +5943,7 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
   	   strings "$collect2name" | grep resolve_lib_name >/dev/null
 	  then
   	  # We have reworked collect2
-  	  _LT_AC_TAGVAR(hardcode_direct, $1)=yes
+  	  :
 	  else
   	  # We have old collect2
   	  _LT_AC_TAGVAR(hardcode_direct, $1)=unsupported
@@ -5352,8 +5954,12 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
   	  _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
   	  _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=
 	  fi
+	  ;;
 	esac
 	shared_flag='-shared'
+	if test "$aix_use_runtimelinking" = yes; then
+	  shared_flag="$shared_flag "'${wl}-G'
+	fi
       else
 	# not using gcc
 	if test "$host_cpu" = ia64; then
@@ -5361,11 +5967,11 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
   	# chokes on -Wl,-G. The following line is correct:
 	  shared_flag='-G'
 	else
-  	if test "$aix_use_runtimelinking" = yes; then
+	  if test "$aix_use_runtimelinking" = yes; then
 	    shared_flag='${wl}-G'
 	  else
 	    shared_flag='${wl}-bM:SRE'
-  	fi
+	  fi
 	fi
       fi
 
@@ -5379,12 +5985,12 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
        # Determine the default libpath from the value encoded in an empty executable.
        _LT_AC_SYS_LIBPATH_AIX
        _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-blibpath:$libdir:'"$aix_libpath"
-	_LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags `if test "x${allow_undefined_flag}" != "x"; then echo "${wl}${allow_undefined_flag}"; else :; fi` '"\${wl}$no_entry_flag \${wl}$exp_sym_flag:\$export_symbols $shared_flag"
+	_LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC"' -o $output_objdir/$soname $libobjs $deplibs '"\${wl}$no_entry_flag"' $compiler_flags `if test "x${allow_undefined_flag}" != "x"; then echo "${wl}${allow_undefined_flag}"; else :; fi` '"\${wl}$exp_sym_flag:\$export_symbols $shared_flag"
        else
 	if test "$host_cpu" = ia64; then
 	  _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-R $libdir:/usr/lib:/lib'
 	  _LT_AC_TAGVAR(allow_undefined_flag, $1)="-z nodefs"
-	  _LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags ${wl}${allow_undefined_flag} '"\${wl}$no_entry_flag \${wl}$exp_sym_flag:\$export_symbols"
+	  _LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs '"\${wl}$no_entry_flag"' $compiler_flags ${wl}${allow_undefined_flag} '"\${wl}$exp_sym_flag:\$export_symbols"
 	else
 	 # Determine the default libpath from the value encoded in an empty executable.
 	 _LT_AC_SYS_LIBPATH_AIX
@@ -5393,13 +5999,11 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
 	  # -berok will link without error, but may produce a broken library.
 	  _LT_AC_TAGVAR(no_undefined_flag, $1)=' ${wl}-bernotok'
 	  _LT_AC_TAGVAR(allow_undefined_flag, $1)=' ${wl}-berok'
-	  # -bexpall does not export symbols beginning with underscore (_)
-	  _LT_AC_TAGVAR(always_export_symbols, $1)=yes
 	  # Exported symbols can be pulled into shared objects from archives
-	  _LT_AC_TAGVAR(whole_archive_flag_spec, $1)=' '
+	  _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='$convenience'
 	  _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=yes
-	  # This is similar to how AIX traditionally builds it's shared libraries.
-	  _LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags ${wl}-bE:$export_symbols ${wl}-bnoentry${allow_undefined_flag}~$AR $AR_FLAGS $output_objdir/$libname$release.a $output_objdir/$soname'
+	  # This is similar to how AIX traditionally builds its shared libraries.
+	  _LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs ${wl}-bnoentry $compiler_flags ${wl}-bE:$export_symbols${allow_undefined_flag}~$AR $AR_FLAGS $output_objdir/$libname$release.a $output_objdir/$soname'
 	fi
       fi
       ;;
@@ -5432,13 +6036,13 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
       # The linker will automatically build a .lib file if we build a DLL.
       _LT_AC_TAGVAR(old_archive_From_new_cmds, $1)='true'
       # FIXME: Should let the user specify the lib program.
-      _LT_AC_TAGVAR(old_archive_cmds, $1)='lib /OUT:$oldlib$oldobjs$old_deplibs'
-      fix_srcfile_path='`cygpath -w "$srcfile"`'
+      _LT_AC_TAGVAR(old_archive_cmds, $1)='lib -OUT:$oldlib$oldobjs$old_deplibs'
+      _LT_AC_TAGVAR(fix_srcfile_path, $1)='`cygpath -w "$srcfile"`'
       _LT_AC_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
       ;;
 
     darwin* | rhapsody*)
-      case "$host_os" in
+      case $host_os in
         rhapsody* | darwin1.[[012]])
          _LT_AC_TAGVAR(allow_undefined_flag, $1)='${wl}-undefined ${wl}suppress'
          ;;
@@ -5465,19 +6069,18 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
       _LT_AC_TAGVAR(link_all_deplibs, $1)=yes
     if test "$GCC" = yes ; then
     	output_verbose_link_cmd='echo'
-        _LT_AC_TAGVAR(archive_cmds, $1)='$CC -dynamiclib $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags -install_name $rpath/$soname $verstring'
-      _LT_AC_TAGVAR(module_cmds, $1)='$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags'
-      # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin ld's
-      _LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[    ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC -dynamiclib $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags -install_name $rpath/$soname $verstring~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
-      _LT_AC_TAGVAR(module_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[    ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC $allow_undefined_flag  -o $lib -bundle $libobjs $deplibs$compiler_flags~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
+        _LT_AC_TAGVAR(archive_cmds, $1)="\$CC -dynamiclib \$allow_undefined_flag -o \$lib \$libobjs \$deplibs \$compiler_flags -install_name \$rpath/\$soname \$verstring $_lt_dar_single_mod${_lt_dsymutil}"
+        _LT_AC_TAGVAR(module_cmds, $1)="\$CC \$allow_undefined_flag -o \$lib -bundle \$libobjs \$deplibs \$compiler_flags${_lt_dsymutil}"
+        _LT_AC_TAGVAR(archive_expsym_cmds, $1)="sed 's,^,_,' < \$export_symbols > \$output_objdir/\${libname}-symbols.expsym~\$CC -dynamiclib \$allow_undefined_flag -o \$lib \$libobjs \$deplibs \$compiler_flags -install_name \$rpath/\$soname \$verstring ${_lt_dar_single_mod}${_lt_dar_export_syms}${_lt_dsymutil}"
+        _LT_AC_TAGVAR(module_expsym_cmds, $1)="sed -e 's,^,_,' < \$export_symbols > \$output_objdir/\${libname}-symbols.expsym~\$CC \$allow_undefined_flag -o \$lib -bundle \$libobjs \$deplibs \$compiler_flags${_lt_dar_export_syms}${_lt_dsymutil}"
     else
-      case "$cc_basename" in
+      case $cc_basename in
         xlc*)
          output_verbose_link_cmd='echo'
-         _LT_AC_TAGVAR(archive_cmds, $1)='$CC -qmkshrobj $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-install_name ${wl}`echo $rpath/$soname` $verstring'
+         _LT_AC_TAGVAR(archive_cmds, $1)='$CC -qmkshrobj $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-install_name ${wl}`echo $rpath/$soname` $xlcverstring'
          _LT_AC_TAGVAR(module_cmds, $1)='$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags'
-          # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin ld's
-         _LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[    ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC -qmkshrobj $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-install_name ${wl}$rpath/$soname $verstring~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
+          # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin lds
+         _LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[    ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC -qmkshrobj $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-install_name ${wl}$rpath/$soname $xlcverstring~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
           _LT_AC_TAGVAR(module_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[    ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC $allow_undefined_flag  -o $lib -bundle $libobjs $deplibs$compiler_flags~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
           ;;
        *)
@@ -5517,7 +6120,7 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
       ;;
 
     # FreeBSD 3 and greater uses gcc -shared to do shared libraries.
-    freebsd* | kfreebsd*-gnu)
+    freebsd* | dragonfly*)
       _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -o $lib $libobjs $deplibs $compiler_flags'
       _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
       _LT_AC_TAGVAR(hardcode_direct, $1)=yes
@@ -5540,47 +6143,62 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
       _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
       ;;
 
-    hpux10* | hpux11*)
+    hpux10*)
       if test "$GCC" = yes -a "$with_gnu_ld" = no; then
-	case "$host_cpu" in
-	hppa*64*|ia64*)
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
+      else
+	_LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs $linker_flags'
+      fi
+      if test "$with_gnu_ld" = no; then
+	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
+	_LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
+
+	_LT_AC_TAGVAR(hardcode_direct, $1)=yes
+	_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
+
+	# hardcode_minus_L: Not really in the search PATH,
+	# but as the default location of the library.
+	_LT_AC_TAGVAR(hardcode_minus_L, $1)=yes
+      fi
+      ;;
+
+    hpux11*)
+      if test "$GCC" = yes -a "$with_gnu_ld" = no; then
+	case $host_cpu in
+	hppa*64*)
 	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}+h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
 	  ;;
+	ia64*)
+	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $libobjs $deplibs $compiler_flags'
+	  ;;
 	*)
 	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
 	  ;;
 	esac
       else
-	case "$host_cpu" in
-	hppa*64*|ia64*)
-	  _LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib $libobjs $deplibs $linker_flags'
+	case $host_cpu in
+	hppa*64*)
+	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
+	  ;;
+	ia64*)
+	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $libobjs $deplibs $compiler_flags'
 	  ;;
 	*)
-	  _LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs $linker_flags'
+	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
 	  ;;
 	esac
       fi
       if test "$with_gnu_ld" = no; then
-	case "$host_cpu" in
-	hppa*64*)
-	  _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
+	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
+	_LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
+
+	case $host_cpu in
+	hppa*64*|ia64*)
 	  _LT_AC_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
-	  _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
 	  _LT_AC_TAGVAR(hardcode_direct, $1)=no
 	  _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
 	  ;;
-	ia64*)
-	  _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
-	  _LT_AC_TAGVAR(hardcode_direct, $1)=no
-	  _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
-
-	  # hardcode_minus_L: Not really in the search PATH,
-	  # but as the default location of the library.
-	  _LT_AC_TAGVAR(hardcode_minus_L, $1)=yes
-	  ;;
 	*)
-	  _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
-	  _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
 	  _LT_AC_TAGVAR(hardcode_direct, $1)=yes
 	  _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
 
@@ -5624,24 +6242,28 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
       ;;
 
     openbsd*)
-      _LT_AC_TAGVAR(hardcode_direct, $1)=yes
-      _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
-      if test -z "`echo __ELF__ | $CC -E - | grep __ELF__`" || test "$host_os-$host_cpu" = "openbsd2.8-powerpc"; then
-	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag -o $lib $libobjs $deplibs $compiler_flags'
-	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-retain-symbols-file,$export_symbols'
-	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
-	_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
+      if test -f /usr/libexec/ld.so; then
+	_LT_AC_TAGVAR(hardcode_direct, $1)=yes
+	_LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+	if test -z "`echo __ELF__ | $CC -E - | grep __ELF__`" || test "$host_os-$host_cpu" = "openbsd2.8-powerpc"; then
+	  _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag -o $lib $libobjs $deplibs $compiler_flags'
+	  _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $pic_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-retain-symbols-file,$export_symbols'
+	  _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
+	  _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
+	else
+	  case $host_os in
+	   openbsd[[01]].* | openbsd2.[[0-7]] | openbsd2.[[0-7]].*)
+	     _LT_AC_TAGVAR(archive_cmds, $1)='$LD -Bshareable -o $lib $libobjs $deplibs $linker_flags'
+	     _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
+	     ;;
+	   *)
+	     _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag -o $lib $libobjs $deplibs $compiler_flags'
+	     _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
+	     ;;
+	  esac
+        fi
       else
-       case $host_os in
-	 openbsd[[01]].* | openbsd2.[[0-7]] | openbsd2.[[0-7]].*)
-	   _LT_AC_TAGVAR(archive_cmds, $1)='$LD -Bshareable -o $lib $libobjs $deplibs $linker_flags'
-	   _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
-	   ;;
-	 *)
-	   _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag -o $lib $libobjs $deplibs $compiler_flags'
-	   _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
-	   ;;
-       esac
+	_LT_AC_TAGVAR(ld_shlibs, $1)=no
       fi
       ;;
 
@@ -5674,7 +6296,7 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
 	_LT_AC_TAGVAR(allow_undefined_flag, $1)=' -expect_unresolved \*'
 	_LT_AC_TAGVAR(archive_cmds, $1)='$LD -shared${allow_undefined_flag} $libobjs $deplibs $linker_flags -msym -soname $soname `test -n "$verstring" && echo -set_version $verstring` -update_registry ${output_objdir}/so_locations -o $lib'
 	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='for i in `cat $export_symbols`; do printf "%s %s\\n" -exported_symbol "\$i" >> $lib.exp; done; echo "-hidden">> $lib.exp~
-	$LD -shared${allow_undefined_flag} -input $lib.exp $linker_flags $libobjs $deplibs -soname $soname `test -n "$verstring" && echo -set_version $verstring` -update_registry ${objdir}/so_locations -o $lib~$rm $lib.exp'
+	$LD -shared${allow_undefined_flag} -input $lib.exp $linker_flags $libobjs $deplibs -soname $soname `test -n "$verstring" && echo -set_version $verstring` -update_registry ${output_objdir}/so_locations -o $lib~$rm $lib.exp'
 
 	# Both c and cxx compiler support -rpath directly
 	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-rpath $libdir'
@@ -5682,21 +6304,15 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
       _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
       ;;
 
-    sco3.2v5*)
-      _LT_AC_TAGVAR(archive_cmds, $1)='$LD -G -h $soname -o $lib $libobjs $deplibs $linker_flags'
-      _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
-      _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-Bexport'
-      runpath_var=LD_RUN_PATH
-      hardcode_runpath_var=yes
-      ;;
-
     solaris*)
       _LT_AC_TAGVAR(no_undefined_flag, $1)=' -z text'
       if test "$GCC" = yes; then
+	wlarc='${wl}'
 	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
 	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~$echo "local: *; };" >> $lib.exp~
 	  $CC -shared ${wl}-M ${wl}$lib.exp ${wl}-h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags~$rm $lib.exp'
       else
+	wlarc=''
 	_LT_AC_TAGVAR(archive_cmds, $1)='$LD -G${allow_undefined_flag} -h $soname -o $lib $libobjs $deplibs $linker_flags'
 	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~$echo "local: *; };" >> $lib.exp~
   	$LD -G${allow_undefined_flag} -M $lib.exp -h $soname -o $lib $libobjs $deplibs $linker_flags~$rm $lib.exp'
@@ -5705,8 +6321,17 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
       _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
       case $host_os in
       solaris2.[[0-5]] | solaris2.[[0-5]].*) ;;
-      *) # Supported since Solaris 2.6 (maybe 2.5.1?)
-	_LT_AC_TAGVAR(whole_archive_flag_spec, $1)='-z allextract$convenience -z defaultextract' ;;
+      *)
+	# The compiler driver will combine and reorder linker options,
+	# but understands `-z linker_flag'.  GCC discards it without `$wl',
+	# but is careful enough not to reorder.
+ 	# Supported since Solaris 2.6 (maybe 2.5.1?)
+	if test "$GCC" = yes; then
+	  _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='${wl}-z ${wl}allextract$convenience ${wl}-z ${wl}defaultextract'
+	else
+	  _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='-z allextract$convenience -z defaultextract'
+	fi
+	;;
       esac
       _LT_AC_TAGVAR(link_all_deplibs, $1)=yes
       ;;
@@ -5763,36 +6388,45 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
       fi
       ;;
 
-    sysv4.2uw2*)
-      _LT_AC_TAGVAR(archive_cmds, $1)='$LD -G -o $lib $libobjs $deplibs $linker_flags'
-      _LT_AC_TAGVAR(hardcode_direct, $1)=yes
-      _LT_AC_TAGVAR(hardcode_minus_L, $1)=no
+    sysv4*uw2* | sysv5OpenUNIX* | sysv5UnixWare7.[[01]].[[10]]* | unixware7* | sco3.2v5.0.[[024]]*)
+      _LT_AC_TAGVAR(no_undefined_flag, $1)='${wl}-z,text'
+      _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
       _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
-      hardcode_runpath_var=yes
-      runpath_var=LD_RUN_PATH
-      ;;
+      runpath_var='LD_RUN_PATH'
 
-   sysv5OpenUNIX8* | sysv5UnixWare7* |  sysv5uw[[78]]* | unixware7*)
-      _LT_AC_TAGVAR(no_undefined_flag, $1)='${wl}-z ${wl}text'
       if test "$GCC" = yes; then
-	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
+	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
       else
-	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
+	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -G ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
       fi
-      runpath_var='LD_RUN_PATH'
-      _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
       ;;
 
-    sysv5*)
-      _LT_AC_TAGVAR(no_undefined_flag, $1)=' -z text'
-      # $CC -shared without GNU ld will not create a library from C++
-      # object files and a static libstdc++, better avoid it by now
-      _LT_AC_TAGVAR(archive_cmds, $1)='$LD -G${allow_undefined_flag} -h $soname -o $lib $libobjs $deplibs $linker_flags'
-      _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~$echo "local: *; };" >> $lib.exp~
-  		$LD -G${allow_undefined_flag} -M $lib.exp -h $soname -o $lib $libobjs $deplibs $linker_flags~$rm $lib.exp'
-      _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)=
+    sysv5* | sco3.2v5* | sco5v6*)
+      # Note: We can NOT use -z defs as we might desire, because we do not
+      # link with -lc, and that would cause any symbols used from libc to
+      # always be unresolved, which means just about no library would
+      # ever link correctly.  If we're not using GNU ld we use -z text
+      # though, which does catch some bad symbols but isn't as heavy-handed
+      # as -z defs.
+      _LT_AC_TAGVAR(no_undefined_flag, $1)='${wl}-z,text'
+      _LT_AC_TAGVAR(allow_undefined_flag, $1)='${wl}-z,nodefs'
+      _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
       _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+      _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='`test -z "$SCOABSPATH" && echo ${wl}-R,$libdir`'
+      _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=':'
+      _LT_AC_TAGVAR(link_all_deplibs, $1)=yes
+      _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-Bexport'
       runpath_var='LD_RUN_PATH'
+
+      if test "$GCC" = yes; then
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared ${wl}-Bexport:$export_symbols ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+      else
+	_LT_AC_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+	_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -G ${wl}-Bexport:$export_symbols ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+      fi
       ;;
 
     uts4*)
@@ -5810,11 +6444,6 @@ $echo "local: *; };" >> $output_objdir/$libname.ver~
 AC_MSG_RESULT([$_LT_AC_TAGVAR(ld_shlibs, $1)])
 test "$_LT_AC_TAGVAR(ld_shlibs, $1)" = no && can_build_shared=no
 
-variables_saved_for_relink="PATH $shlibpath_var $runpath_var"
-if test "$GCC" = yes; then
-  variables_saved_for_relink="$variables_saved_for_relink GCC_EXEC_PREFIX COMPILER_PATH LIBRARY_PATH"
-fi
-
 #
 # Do we need to explicitly link libc?
 #
@@ -5834,7 +6463,7 @@ x|xyes)
       # to ld, don't add -lc before -lgcc.
       AC_MSG_CHECKING([whether -lc should be explicitly linked in])
       $rm conftest*
-      printf "$lt_simple_compile_test_code" > conftest.$ac_ext
+      echo "$lt_simple_compile_test_code" > conftest.$ac_ext
 
       if AC_TRY_EVAL(ac_compile) 2>conftest.err; then
         soname=conftest
@@ -5842,6 +6471,7 @@ x|xyes)
         libobjs=conftest.$ac_objext
         deplibs=
         wl=$_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)
+	pic_flag=$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)
         compiler_flags=-v
         linker_flags=-v
         verstring=
@@ -5936,6 +6566,30 @@ AC_DEFUN([LT_AC_PROG_RC],
 [AC_CHECK_TOOL(RC, windres, no)
 ])
 
+
+# Cheap backport of AS_EXECUTABLE_P and required macros
+# from Autoconf 2.59; we should not use $as_executable_p directly.
+
+# _AS_TEST_PREPARE
+# ----------------
+m4_ifndef([_AS_TEST_PREPARE],
+[m4_defun([_AS_TEST_PREPARE],
+[if test -x / >/dev/null 2>&1; then
+  as_executable_p='test -x'
+else
+  as_executable_p='test -f'
+fi
+])])# _AS_TEST_PREPARE
+
+# AS_EXECUTABLE_P
+# ---------------
+# Check whether a file is executable.
+m4_ifndef([AS_EXECUTABLE_P],
+[m4_defun([AS_EXECUTABLE_P],
+[AS_REQUIRE([_AS_TEST_PREPARE])dnl
+$as_executable_p $1[]dnl
+])])# AS_EXECUTABLE_P
+
 ############################################################
 # NOTE: This macro has been submitted for inclusion into   #
 #  GNU Autoconf as AC_PROG_SED.  When it is available in   #
@@ -5958,18 +6612,19 @@ do
   test -z "$as_dir" && as_dir=.
   for lt_ac_prog in sed gsed; do
     for ac_exec_ext in '' $ac_executable_extensions; do
-      if $as_executable_p "$as_dir/$lt_ac_prog$ac_exec_ext"; then
+      if AS_EXECUTABLE_P(["$as_dir/$lt_ac_prog$ac_exec_ext"]); then
         lt_ac_sed_list="$lt_ac_sed_list $as_dir/$lt_ac_prog$ac_exec_ext"
       fi
     done
   done
 done
+IFS=$as_save_IFS
 lt_ac_max=0
 lt_ac_count=0
 # Add /usr/xpg4/bin/sed as it is typically found on Solaris
 # along with /bin/sed that truncates output.
 for lt_ac_sed in $lt_ac_sed_list /usr/xpg4/bin/sed; do
-  test ! -f $lt_ac_sed && break
+  test ! -f $lt_ac_sed && continue
   cat /dev/null > conftest.in
   lt_ac_count=0
   echo $ECHO_N "0123456789$ECHO_C" >conftest.in
@@ -5996,5 +6651,6 @@ for lt_ac_sed in $lt_ac_sed_list /usr/xpg4/bin/sed; do
 done
 ])
 SED=$lt_cv_path_SED
+AC_SUBST([SED])
 AC_MSG_RESULT([$SED])
 ])
diff --git a/contrib/bind9/ltmain.sh b/contrib/bind9/ltmain.sh
index e032aff..ce02bc6 100644
--- a/contrib/bind9/ltmain.sh
+++ b/contrib/bind9/ltmain.sh
@@ -1,8 +1,8 @@
 # ltmain.sh - Provide generalized library-building support services.
 # NOTE: Changing this file will not affect anything until you rerun configure.
 #
-# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004
-# Free Software Foundation, Inc.
+# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005, 2006,
+# 2007, 2008  Free Software Foundation, Inc.
 # Originally by Gordon Matzigkeit <gord@gnu.ai.mit.edu>, 1996
 #
 # This program is free software; you can redistribute it and/or modify
@@ -17,7 +17,7 @@
 #
 # You should have received a copy of the GNU General Public License
 # along with this program; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
 #
 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
@@ -43,14 +43,22 @@ EXIT_FAILURE=1
 
 PROGRAM=ltmain.sh
 PACKAGE=libtool
-VERSION=1.5.10
-TIMESTAMP=" (1.1220.2.131 2004/09/19 12:46:56)"
-
-# See if we are running on zsh, and set the options which allow our
-# commands through without removal of \ escapes.
-if test -n "${ZSH_VERSION+set}" ; then
+VERSION=1.5.26
+TIMESTAMP=" (1.1220.2.492 2008/01/30 06:40:56)"
+
+# Be Bourne compatible (taken from Autoconf:_AS_BOURNE_COMPATIBLE).
+if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then
+  emulate sh
+  NULLCMD=:
+  # Zsh 3.x and 4.x performs word splitting on ${1+"$@"}, which
+  # is contrary to our usage.  Disable this feature.
+  alias -g '${1+"$@"}'='"$@"'
   setopt NO_GLOB_SUBST
+else
+  case `(set -o) 2>/dev/null` in *posix*) set -o posix;; esac
 fi
+BIN_SH=xpg4; export BIN_SH # for Tru64
+DUALCASE=1; export DUALCASE # for MKS sh
 
 # Check that we have a working $echo.
 if test "X$1" = X--no-reexec; then
@@ -88,14 +96,15 @@ rm="rm -f"
 Xsed="${SED}"' -e 1s/^X//'
 sed_quote_subst='s/\([\\`\\"$\\\\]\)/\\\1/g'
 # test EBCDIC or ASCII
-case `echo A|tr A '\301'` in
- A) # EBCDIC based system
-  SP2NL="tr '\100' '\n'"
-  NL2SP="tr '\r\n' '\100\100'"
+case `echo X|tr X '\101'` in
+ A) # ASCII based system
+    # \n is not interpreted correctly by Solaris 8 /usr/ucb/tr
+  SP2NL='tr \040 \012'
+  NL2SP='tr \015\012 \040\040'
   ;;
- *) # Assume ASCII based system
-  SP2NL="tr '\040' '\012'"
-  NL2SP="tr '\015\012' '\040\040'"
+ *) # EBCDIC based system
+  SP2NL='tr \100 \n'
+  NL2SP='tr \r\n \100\100'
   ;;
 esac
 
@@ -104,16 +113,25 @@ esac
 # These must not be set unconditionally because not all systems understand
 # e.g. LANG=C (notably SCO).
 # We save the old values to restore during execute mode.
-if test "${LC_ALL+set}" = set; then
-  save_LC_ALL="$LC_ALL"; LC_ALL=C; export LC_ALL
-fi
-if test "${LANG+set}" = set; then
-  save_LANG="$LANG"; LANG=C; export LANG
+lt_env=
+for lt_var in LANG LANGUAGE LC_ALL LC_CTYPE LC_COLLATE LC_MESSAGES
+do
+  eval "if test \"\${$lt_var+set}\" = set; then
+	  save_$lt_var=\$$lt_var
+	  lt_env=\"$lt_var=\$$lt_var \$lt_env\"
+	  $lt_var=C
+	  export $lt_var
+	fi"
+done
+
+if test -n "$lt_env"; then
+  lt_env="env $lt_env"
 fi
 
 # Make sure IFS has a sensible default
-: ${IFS=" 	
-"}
+lt_nl='
+'
+IFS=" 	$lt_nl"
 
 if test "$build_libtool_libs" != yes && test "$build_old_libs" != yes; then
   $echo "$modename: not configured to build any kind of library" 1>&2
@@ -130,20 +148,62 @@ run=
 show="$echo"
 show_help=
 execute_dlfiles=
+duplicate_deps=no
+preserve_args=
 lo2o="s/\\.lo\$/.${objext}/"
 o2lo="s/\\.${objext}\$/.lo/"
+extracted_archives=
+extracted_serial=0
 
 #####################################
 # Shell function definitions:
 # This seems to be the best place for them
 
+# func_mktempdir [string]
+# Make a temporary directory that won't clash with other running
+# libtool processes, and avoids race conditions if possible.  If
+# given, STRING is the basename for that directory.
+func_mktempdir ()
+{
+    my_template="${TMPDIR-/tmp}/${1-$progname}"
+
+    if test "$run" = ":"; then
+      # Return a directory name, but don't create it in dry-run mode
+      my_tmpdir="${my_template}-$$"
+    else
+
+      # If mktemp works, use that first and foremost
+      my_tmpdir=`mktemp -d "${my_template}-XXXXXXXX" 2>/dev/null`
+
+      if test ! -d "$my_tmpdir"; then
+	# Failing that, at least try and use $RANDOM to avoid a race
+	my_tmpdir="${my_template}-${RANDOM-0}$$"
+
+	save_mktempdir_umask=`umask`
+	umask 0077
+	$mkdir "$my_tmpdir"
+	umask $save_mktempdir_umask
+      fi
+
+      # If we're not in dry-run mode, bomb out on failure
+      test -d "$my_tmpdir" || {
+        $echo "cannot create temporary directory \`$my_tmpdir'" 1>&2
+	exit $EXIT_FAILURE
+      }
+    fi
+
+    $echo "X$my_tmpdir" | $Xsed
+}
+
+
 # func_win32_libid arg
 # return the library type of file 'arg'
 #
 # Need a lot of goo to handle *both* DLLs and import libs
 # Has to be a shell function in order to 'eat' the argument
 # that is supplied when $file_magic_command is called.
-func_win32_libid () {
+func_win32_libid ()
+{
   win32_libid_type="unknown"
   win32_fileres=`file -L $1 2>/dev/null`
   case $win32_fileres in
@@ -154,12 +214,17 @@ func_win32_libid () {
     if eval $OBJDUMP -f $1 | $SED -e '10q' 2>/dev/null | \
       $EGREP -e 'file format pe-i386(.*architecture: i386)?' >/dev/null ; then
       win32_nmres=`eval $NM -f posix -A $1 | \
-	sed -n -e '1,100{/ I /{x;/import/!{s/^/import/;h;p;};x;};}'`
-      if test "X$win32_nmres" = "Ximport" ; then
-        win32_libid_type="x86 archive import"
-      else
-        win32_libid_type="x86 archive static"
-      fi
+	$SED -n -e '1,100{
+		/ I /{
+			s,.*,import,
+			p
+			q
+			}
+		}'`
+      case $win32_nmres in
+      import*)  win32_libid_type="x86 archive import";;
+      *)        win32_libid_type="x86 archive static";;
+      esac
     fi
     ;;
   *DLL*)
@@ -183,7 +248,22 @@ func_win32_libid () {
 # Only attempt this if the compiler in the base compile
 # command doesn't match the default compiler.
 # arg is usually of the form 'gcc ...'
-func_infer_tag () {
+func_infer_tag ()
+{
+    # FreeBSD-specific: where we install compilers with non-standard names
+    tag_compilers_CC="*cc cc* *gcc gcc*"
+    tag_compilers_CXX="*c++ c++* *g++ g++*"
+    base_compiler=`set -- "$@"; echo $1`
+
+    # If $tagname isn't set, then try to infer if the default "CC" tag applies
+    if test -z "$tagname"; then
+      for zp in $tag_compilers_CC; do
+        case $base_compiler in
+	 $zp) tagname="CC"; break;;
+	esac
+      done
+    fi
+
     if test -n "$available_tags" && test -z "$tagname"; then
       CC_quoted=
       for arg in $CC; do
@@ -224,7 +304,22 @@ func_infer_tag () {
 	      break
 	      ;;
 	    esac
-	  fi
+
+	    # FreeBSD-specific: try compilers based on inferred tag
+	    if test -z "$tagname"; then
+	      eval "tag_compilers=\$tag_compilers_${z}"
+	      if test -n "$tag_compilers"; then
+		for zp in $tag_compilers; do
+		  case $base_compiler in   
+		    $zp) tagname=$z; break;;
+		  esac
+		done
+		if test -n "$tagname"; then
+		  break
+		fi
+	      fi
+            fi
+          fi
 	done
 	# If $tagname still isn't set, then no tagged configuration
 	# was found and let the user know that the "--tag" command
@@ -242,8 +337,25 @@ func_infer_tag () {
 }
 
 
+# func_extract_an_archive dir oldlib
+func_extract_an_archive ()
+{
+    f_ex_an_ar_dir="$1"; shift
+    f_ex_an_ar_oldlib="$1"
+
+    $show "(cd $f_ex_an_ar_dir && $AR x $f_ex_an_ar_oldlib)"
+    $run eval "(cd \$f_ex_an_ar_dir && $AR x \$f_ex_an_ar_oldlib)" || exit $?
+    if ($AR t "$f_ex_an_ar_oldlib" | sort | sort -uc >/dev/null 2>&1); then
+     :
+    else
+      $echo "$modename: ERROR: object name conflicts: $f_ex_an_ar_dir/$f_ex_an_ar_oldlib" 1>&2
+      exit $EXIT_FAILURE
+    fi
+}
+
 # func_extract_archives gentop oldlib ...
-func_extract_archives () {
+func_extract_archives ()
+{
     my_gentop="$1"; shift
     my_oldlibs=${1+"$@"}
     my_oldobjs=""
@@ -268,15 +380,25 @@ func_extract_archives () {
 	*) my_xabs=`pwd`"/$my_xlib" ;;
       esac
       my_xlib=`$echo "X$my_xlib" | $Xsed -e 's%^.*/%%'`
-      my_xdir="$my_gentop/$my_xlib"
+      my_xlib_u=$my_xlib
+      while :; do
+        case " $extracted_archives " in
+	*" $my_xlib_u "*)
+	  extracted_serial=`expr $extracted_serial + 1`
+	  my_xlib_u=lt$extracted_serial-$my_xlib ;;
+	*) break ;;
+	esac
+      done
+      extracted_archives="$extracted_archives $my_xlib_u"
+      my_xdir="$my_gentop/$my_xlib_u"
 
       $show "${rm}r $my_xdir"
       $run ${rm}r "$my_xdir"
       $show "$mkdir $my_xdir"
       $run $mkdir "$my_xdir"
-      status=$?
-      if test "$status" -ne 0 && test ! -d "$my_xdir"; then
-	exit $status
+      exit_status=$?
+      if test "$exit_status" -ne 0 && test ! -d "$my_xdir"; then
+	exit $exit_status
       fi
       case $host in
       *-darwin*)
@@ -287,7 +409,7 @@ func_extract_archives () {
 	  cd $my_xdir || exit $?
 	  darwin_archive=$my_xabs
 	  darwin_curdir=`pwd`
-	  darwin_base_archive=`basename $darwin_archive`
+	  darwin_base_archive=`$echo "X$darwin_archive" | $Xsed -e 's%^.*/%%'`
 	  darwin_arches=`lipo -info "$darwin_archive" 2>/dev/null | $EGREP Architectures 2>/dev/null`
 	  if test -n "$darwin_arches"; then 
 	    darwin_arches=`echo "$darwin_arches" | $SED -e 's/.*are://'`
@@ -296,64 +418,33 @@ func_extract_archives () {
 	    for darwin_arch in  $darwin_arches ; do
 	      mkdir -p "unfat-$$/${darwin_base_archive}-${darwin_arch}"
 	      lipo -thin $darwin_arch -output "unfat-$$/${darwin_base_archive}-${darwin_arch}/${darwin_base_archive}" "${darwin_archive}"
-	      # Remove the table of contents from the thin files.
-	      $AR -d "unfat-$$/${darwin_base_archive}-${darwin_arch}/${darwin_base_archive}" __.SYMDEF 2>/dev/null || true
-	      $AR -d "unfat-$$/${darwin_base_archive}-${darwin_arch}/${darwin_base_archive}" __.SYMDEF\ SORTED 2>/dev/null || true
 	      cd "unfat-$$/${darwin_base_archive}-${darwin_arch}"
-	      $AR -xo "${darwin_base_archive}"
-	      rm "${darwin_base_archive}"
+	      func_extract_an_archive "`pwd`" "${darwin_base_archive}"
 	      cd "$darwin_curdir"
+	      $rm "unfat-$$/${darwin_base_archive}-${darwin_arch}/${darwin_base_archive}"
 	    done # $darwin_arches
       ## Okay now we have a bunch of thin objects, gotta fatten them up :)
-	    darwin_filelist=`find unfat-$$ -type f | xargs basename | sort -u | $NL2SP`
+	    darwin_filelist=`find unfat-$$ -type f -name \*.o -print -o -name \*.lo -print| xargs basename | sort -u | $NL2SP`
 	    darwin_file=
 	    darwin_files=
 	    for darwin_file in $darwin_filelist; do
 	      darwin_files=`find unfat-$$ -name $darwin_file -print | $NL2SP`
 	      lipo -create -output "$darwin_file" $darwin_files
 	    done # $darwin_filelist
-	    rm -rf unfat-$$
+	    ${rm}r unfat-$$
 	    cd "$darwin_orig_dir"
 	  else
-	    cd $darwin_orig_dir
-	    (cd $my_xdir && $AR x $my_xabs) || exit $?
+	    cd "$darwin_orig_dir"
+ 	    func_extract_an_archive "$my_xdir" "$my_xabs"
 	  fi # $darwin_arches
 	fi # $run
-      ;;
-      *)
-	# We will extract separately just the conflicting names and we will
-	# no longer touch any unique names. It is faster to leave these
-	# extract automatically by $AR in one run.
-	$show "(cd $my_xdir && $AR x $my_xabs)"
-	$run eval "(cd \$my_xdir && $AR x \$my_xabs)" || exit $?
-	if ($AR t "$my_xabs" | sort | sort -uc >/dev/null 2>&1); then
-	  :
-	else
-	  $echo "$modename: warning: object name conflicts; renaming object files" 1>&2
-	  $echo "$modename: warning: to ensure that they will not overwrite" 1>&2
-	  $AR t "$my_xabs" | sort | uniq -cd | while read -r count name
-	  do
-	    i=1
-	    while test "$i" -le "$count"
-	    do
-	      # Put our $i before any first dot (extension)
-	      # Never overwrite any file
-	      name_to="$name"
-	      while test "X$name_to" = "X$name" || test -f "$my_xdir/$name_to"
-	      do
-		name_to=`$echo "X$name_to" | $Xsed -e "s/\([^.]*\)/\1-$i/"`
-	      done
-	      $show "(cd $my_xdir && $AR xN $i $my_xabs '$name' && $mv '$name' '$name_to')"
-	      $run eval "(cd \$my_xdir && $AR xN $i \$my_xabs '$name' && $mv '$name' '$name_to')" || exit $?
-	      i=`expr $i + 1`
-	    done
-	  done
-	fi
 	;;
+      *)
+        func_extract_an_archive "$my_xdir" "$my_xabs"
+        ;;
       esac
       my_oldobjs="$my_oldobjs "`find $my_xdir -name \*.$objext -print -o -name \*.lo -print | $NL2SP`
     done
-
     func_extract_archives_result="$my_oldobjs"
 }
 # End of Shell function definitions
@@ -362,6 +453,8 @@ func_extract_archives () {
 # Darwin sucks
 eval std_shrext=\"$shrext_cmds\"
 
+disable_libs=no
+
 # Parse our command line options once, thoroughly.
 while test "$#" -gt 0
 do
@@ -424,12 +517,13 @@ do
     ;;
 
   --version)
-    $echo "$PROGRAM (GNU $PACKAGE) $VERSION$TIMESTAMP"
-    $echo
-    $echo "Copyright (C) 2003  Free Software Foundation, Inc."
-    $echo "This is free software; see the source for copying conditions.  There is NO"
-    $echo "warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."
-    exit $EXIT_SUCCESS
+    echo "\
+$PROGRAM (GNU $PACKAGE) $VERSION$TIMESTAMP
+
+Copyright (C) 2008  Free Software Foundation, Inc.
+This is free software; see the source for copying conditions.  There is NO
+warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."
+    exit $?
     ;;
 
   --config)
@@ -438,7 +532,7 @@ do
     for tagname in $taglist; do
       ${SED} -n -e "/^# ### BEGIN LIBTOOL TAG CONFIG: $tagname$/,/^# ### END LIBTOOL TAG CONFIG: $tagname$/p" < "$progpath"
     done
-    exit $EXIT_SUCCESS
+    exit $?
     ;;
 
   --debug)
@@ -463,7 +557,7 @@ do
     else
       $echo "disable static libraries"
     fi
-    exit $EXIT_SUCCESS
+    exit $?
     ;;
 
   --finish) mode="finish" ;;
@@ -478,7 +572,11 @@ do
     preserve_args="$preserve_args $arg"
     ;;
 
-  --tag) prevopt="--tag" prev=tag ;;
+  --tag)
+    prevopt="--tag"
+    prev=tag
+    preserve_args="$preserve_args --tag"
+    ;;
   --tag=*)
     set tag "$optarg" ${1+"$@"}
     shift
@@ -510,6 +608,18 @@ if test -n "$prevopt"; then
   exit $EXIT_FAILURE
 fi
 
+case $disable_libs in
+no) 
+  ;;
+shared)
+  build_libtool_libs=no
+  build_old_libs=yes
+  ;;
+static)
+  build_old_libs=`case $build_libtool_libs in yes) echo no;; *) echo yes;; esac`
+  ;;
+esac
+
 # If this variable is set in any of the actions, the command in it
 # will be execed at the end.  This prevents here-documents from being
 # left over by shells.
@@ -520,7 +630,7 @@ if test -z "$show_help"; then
   # Infer the operation mode.
   if test -z "$mode"; then
     $echo "*** Warning: inferring the mode of operation is deprecated." 1>&2
-    $echo "*** Future versions of Libtool will require -mode=MODE be specified." 1>&2
+    $echo "*** Future versions of Libtool will require --mode=MODE be specified." 1>&2
     case $nonopt in
     *cc | cc* | *++ | gcc* | *-gcc* | g++* | xlc*)
       mode=link
@@ -586,7 +696,7 @@ if test -z "$show_help"; then
 
     for arg
     do
-      case "$arg_mode" in
+      case $arg_mode in
       arg  )
 	# do not "continue".  Instead, add this to base_compile
 	lastarg="$arg"
@@ -668,7 +778,10 @@ if test -z "$show_help"; then
       case $lastarg in
       # Double-quote args containing other shell metacharacters.
       # Many Bourne shells cannot handle close brackets correctly
-      # in scan sets, so we specify it separately.
+      # in scan sets, and some SunOS ksh mistreat backslash-escaping
+      # in scan sets (worked around with variable expansion),
+      # and furthermore cannot handle '|' '&' '(' ')' in scan sets 
+      # at all, so we specify them separately.
       *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \	]*|*]*|"")
 	lastarg="\"$lastarg\""
 	;;
@@ -706,9 +819,11 @@ if test -z "$show_help"; then
     *.class) xform=class ;;
     *.cpp) xform=cpp ;;
     *.cxx) xform=cxx ;;
-    *.f90) xform=f90 ;;
+    *.[fF][09]?) xform=[fF][09]. ;;
     *.for) xform=for ;;
     *.java) xform=java ;;
+    *.obj) xform=obj ;;
+    *.sx) xform=sx ;;
     esac
 
     libobj=`$echo "X$libobj" | $Xsed -e "s/\.$xform$/.lo/"`
@@ -742,6 +857,14 @@ if test -z "$show_help"; then
       esac
     done
 
+    qlibobj=`$echo "X$libobj" | $Xsed -e "$sed_quote_subst"`
+    case $qlibobj in
+      *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \	]*|*]*|"")
+	qlibobj="\"$qlibobj\"" ;;
+    esac
+    test "X$libobj" != "X$qlibobj" \
+	&& $echo "X$libobj" | grep '[]~#^*{};<>?"'"'"' 	&()|`$[]' \
+	&& $echo "$modename: libobj name \`$libobj' may not contain shell special characters."
     objname=`$echo "X$obj" | $Xsed -e 's%^.*/%%'`
     xdir=`$echo "X$obj" | $Xsed -e 's%/[^/]*$%%'`
     if test "X$xdir" = "X$obj"; then
@@ -814,12 +937,17 @@ compiler."
 	$run $rm $removelist
 	exit $EXIT_FAILURE
       fi
-      $echo $srcfile > "$lockfile"
+      $echo "$srcfile" > "$lockfile"
     fi
 
     if test -n "$fix_srcfile_path"; then
       eval srcfile=\"$fix_srcfile_path\"
     fi
+    qsrcfile=`$echo "X$srcfile" | $Xsed -e "$sed_quote_subst"`
+    case $qsrcfile in
+      *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \	]*|*]*|"")
+      qsrcfile="\"$qsrcfile\"" ;;
+    esac
 
     $run $rm "$libobj" "${libobj}T"
 
@@ -841,18 +969,18 @@ EOF
       fbsd_hideous_sh_bug=$base_compile
 
       if test "$pic_mode" != no; then
-	command="$base_compile $srcfile $pic_flag"
+	command="$base_compile $qsrcfile $pic_flag"
       else
 	# Don't build PIC code
-	command="$base_compile $srcfile"
+	command="$base_compile $qsrcfile"
       fi
 
       if test ! -d "${xdir}$objdir"; then
 	$show "$mkdir ${xdir}$objdir"
 	$run $mkdir ${xdir}$objdir
-	status=$?
-	if test "$status" -ne 0 && test ! -d "${xdir}$objdir"; then
-	  exit $status
+	exit_status=$?
+	if test "$exit_status" -ne 0 && test ! -d "${xdir}$objdir"; then
+	  exit $exit_status
 	fi
       fi
 
@@ -864,7 +992,7 @@ EOF
       $run $rm "$lobj" "$output_obj"
 
       $show "$command"
-      if $run eval "$command"; then :
+      if $run eval $lt_env "$command"; then :
       else
 	test -n "$output_obj" && $run $rm $removelist
 	exit $EXIT_FAILURE
@@ -924,9 +1052,9 @@ EOF
     if test "$build_old_libs" = yes; then
       if test "$pic_mode" != yes; then
 	# Don't build PIC code
-	command="$base_compile $srcfile"
+	command="$base_compile $qsrcfile"
       else
-	command="$base_compile $srcfile $pic_flag"
+	command="$base_compile $qsrcfile $pic_flag"
       fi
       if test "$compiler_c_o" = yes; then
 	command="$command -o $obj"
@@ -936,7 +1064,7 @@ EOF
       command="$command$suppress_output"
       $run $rm "$obj" "$output_obj"
       $show "$command"
-      if $run eval "$command"; then :
+      if $run eval $lt_env "$command"; then :
       else
 	$run $rm $removelist
 	exit $EXIT_FAILURE
@@ -1055,6 +1183,7 @@ EOF
     no_install=no
     objs=
     non_pic_objects=
+    notinst_path= # paths that contain not-installed libtool libraries
     precious_files_regex=
     prefer_static_libs=no
     preload=no
@@ -1068,6 +1197,7 @@ EOF
     thread_safe=no
     vinfo=
     vinfo_number=no
+    single_module="${wl}-single_module"
 
     func_infer_tag $base_compile
 
@@ -1075,22 +1205,32 @@ EOF
     for arg
     do
       case $arg in
-      -all-static | -static)
-	if test "X$arg" = "X-all-static"; then
+      -all-static | -static | -static-libtool-libs)
+	case $arg in
+	-all-static)
 	  if test "$build_libtool_libs" = yes && test -z "$link_static_flag"; then
 	    $echo "$modename: warning: complete static linking is impossible in this configuration" 1>&2
 	  fi
 	  if test -n "$link_static_flag"; then
 	    dlopen_self=$dlopen_self_static
 	  fi
-	else
+	  prefer_static_libs=yes
+	  ;;
+	-static)
 	  if test -z "$pic_flag" && test -n "$link_static_flag"; then
 	    dlopen_self=$dlopen_self_static
 	  fi
-	fi
+	  prefer_static_libs=built
+	  ;;
+	-static-libtool-libs)
+	  if test -z "$pic_flag" && test -n "$link_static_flag"; then
+	    dlopen_self=$dlopen_self_static
+	  fi
+	  prefer_static_libs=yes
+	  ;;
+	esac
 	build_libtool_libs=no
 	build_old_libs=yes
-	prefer_static_libs=yes
 	break
 	;;
       esac
@@ -1265,6 +1405,11 @@ EOF
 		  if test -z "$pic_object" || test "$pic_object" = none ; then
 		    arg="$non_pic_object"
 		  fi
+		else
+		  # If the PIC object exists, use it instead.
+		  # $xdir was prepended to $pic_object above.
+		  non_pic_object="$pic_object"
+		  non_pic_objects="$non_pic_objects $non_pic_object"
 		fi
 	      else
 		# Only an error if not doing a dry-run.
@@ -1348,6 +1493,13 @@ EOF
 	  prev=
 	  continue
 	  ;;
+	darwin_framework|darwin_framework_skip)
+	  test "$prev" = "darwin_framework" && compiler_flags="$compiler_flags $arg"
+	  compile_command="$compile_command $arg"
+	  finalize_command="$finalize_command $arg"
+	  prev=
+	  continue
+	  ;;
 	*)
 	  eval "$prev=\"\$arg\""
 	  prev=
@@ -1406,6 +1558,18 @@ EOF
 	continue
 	;;
 
+      -framework|-arch|-isysroot)
+	case " $CC " in
+	  *" ${arg} ${1} "* | *" ${arg}	${1} "*) 
+		prev=darwin_framework_skip ;;
+	  *) compiler_flags="$compiler_flags $arg"
+	     prev=darwin_framework ;;
+	esac
+	compile_command="$compile_command $arg"
+	finalize_command="$finalize_command $arg"
+	continue
+	;;
+
       -inst-prefix-dir)
 	prev=inst_prefix
 	continue
@@ -1432,7 +1596,8 @@ EOF
 	  absdir=`cd "$dir" && pwd`
 	  if test -z "$absdir"; then
 	    $echo "$modename: cannot determine absolute directory name of \`$dir'" 1>&2
-	    exit $EXIT_FAILURE
+	    absdir="$dir"
+	    notinst_path="$notinst_path $dir"
 	  fi
 	  dir="$absdir"
 	  ;;
@@ -1446,10 +1611,15 @@ EOF
 	esac
 	case $host in
 	*-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2*)
+	  testbindir=`$echo "X$dir" | $Xsed -e 's*/lib$*/bin*'`
 	  case :$dllsearchpath: in
 	  *":$dir:"*) ;;
 	  *) dllsearchpath="$dllsearchpath:$dir";;
 	  esac
+	  case :$dllsearchpath: in
+	  *":$testbindir:"*) ;;
+	  *) dllsearchpath="$dllsearchpath:$testbindir";;
+	  esac
 	  ;;
 	esac
 	continue
@@ -1458,15 +1628,15 @@ EOF
       -l*)
 	if test "X$arg" = "X-lc" || test "X$arg" = "X-lm"; then
 	  case $host in
-	  *-*-cygwin* | *-*-pw32* | *-*-beos*)
+	  *-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-beos*)
 	    # These systems don't actually have a C or math library (as such)
 	    continue
 	    ;;
-	  *-*-mingw* | *-*-os2*)
+	  *-*-os2*)
 	    # These systems don't actually have a C library (as such)
 	    test "X$arg" = "X-lc" && continue
 	    ;;
-	  *-*-openbsd* | *-*-freebsd*)
+	  *-*-openbsd* | *-*-freebsd* | *-*-dragonfly*)
 	    # Do not include libc due to us having libc/libc_r.
 	    test "X$arg" = "X-lc" && continue
 	    ;;
@@ -1474,10 +1644,19 @@ EOF
 	    # Rhapsody C and math libraries are in the System framework
 	    deplibs="$deplibs -framework System"
 	    continue
+	    ;;
+	  *-*-sco3.2v5* | *-*-sco5v6*)
+	    # Causes problems with __ctype
+	    test "X$arg" = "X-lc" && continue
+	    ;;
+	  *-*-sysv4.2uw2* | *-*-sysv5* | *-*-unixware* | *-*-OpenUNIX*)
+	    # Compiler inserts libc in the correct place for threads to work
+	    test "X$arg" = "X-lc" && continue
+	    ;;
 	  esac
 	elif test "X$arg" = "X-lc_r"; then
 	 case $host in
-	 *-*-openbsd* | *-*-freebsd*)
+	 *-*-openbsd* | *-*-freebsd* | *-*-dragonfly*)
 	   # Do not include libc_r directly, use -pthread flag.
 	   continue
 	   ;;
@@ -1487,19 +1666,26 @@ EOF
 	continue
 	;;
 
-     -mt|-mthreads|-kthread|-Kthread|-pthread|-pthreads|--thread-safe)
-	case $host in
-	*-*-freebsd*)
-	   compile_command="$compile_command $arg"
-	   finalize_command="$finalize_command $arg"
-	   ;;
-	*)
-	   case "$archive_cmds" in
-	     *"\$LD"*) ;;
-	     *) deplibs="$deplibs $arg";;
-	   esac
-	   ;;
-	esac
+      # Tru64 UNIX uses -model [arg] to determine the layout of C++
+      # classes, name mangling, and exception handling.
+      -model)
+	compile_command="$compile_command $arg"
+	compiler_flags="$compiler_flags $arg"
+	finalize_command="$finalize_command $arg"
+	prev=xcompiler
+	continue
+	;;
+
+     -mt|-mthreads|-kthread|-Kthread|-pthread|-pthreads|--thread-safe|-threads)
+	compiler_flags="$compiler_flags $arg"
+	compile_command="$compile_command $arg"
+	finalize_command="$finalize_command $arg"
+	deplibs="$deplibs $arg"
+	continue
+	;;
+
+      -multi_module)
+	single_module="${wl}-multi_module"
 	continue
 	;;
 
@@ -1508,13 +1694,20 @@ EOF
 	continue
 	;;
 
-      # gcc -m* arguments should be passed to the linker via $compiler_flags
-      # in order to pass architecture information to the linker
-      # (e.g. 32 vs 64-bit).  This may also be accomplished via -Wl,-mfoo
-      # but this is not reliable with gcc because gcc may use -mfoo to
-      # select a different linker, different libraries, etc, while
-      # -Wl,-mfoo simply passes -mfoo to the linker.
-      -m*)
+      # -64, -mips[0-9] enable 64-bit mode on the SGI compiler
+      # -r[0-9][0-9]* specifies the processor on the SGI compiler
+      # -xarch=*, -xtarget=* enable 64-bit mode on the Sun compiler
+      # +DA*, +DD* enable 64-bit mode on the HP compiler
+      # -q* pass through compiler args for the IBM compiler
+      # -m* pass through architecture-specific compiler args for GCC
+      # -m*, -t[45]*, -txscale* pass through architecture-specific
+      # compiler args for GCC
+      # -p, -pg, --coverage, -fprofile-* pass through profiling flag for GCC
+      # -F/path gives path to uninstalled frameworks, gcc on darwin
+      # @file GCC response files
+      -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \
+      -t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|@*)
+
 	# Unknown arguments in both finalize_command and compile_command need
 	# to be aesthetically quoted because they are evaled later.
 	arg=`$echo "X$arg" | $Xsed -e "$sed_quote_subst"`
@@ -1525,9 +1718,7 @@ EOF
 	esac
         compile_command="$compile_command $arg"
         finalize_command="$finalize_command $arg"
-        if test "$with_gcc" = "yes" ; then
-          compiler_flags="$compiler_flags $arg"
-        fi
+        compiler_flags="$compiler_flags $arg"
         continue
         ;;
 
@@ -1543,9 +1734,9 @@ EOF
 
       -no-install)
 	case $host in
-	*-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2*)
+	*-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2* | *-*-darwin*)
 	  # The PATH hackery in wrapper scripts is required on Windows
-	  # in order for the loader to find any dlls it needs.
+	  # and Darwin in order for the loader to find any dlls it needs.
 	  $echo "$modename: warning: \`-no-install' is ignored for $host" 1>&2
 	  $echo "$modename: warning: assuming \`-no-fast-install' instead" 1>&2
 	  fast_install=no
@@ -1604,7 +1795,7 @@ EOF
 	continue
 	;;
 
-      -static)
+      -static | -static-libtool-libs)
 	# The effects of -static are defined in a previous loop.
 	# We used to do the same as -all-static on platforms that
 	# didn't have a PIC flag, but the assumption that the effects
@@ -1765,6 +1956,11 @@ EOF
 	    if test -z "$pic_object" || test "$pic_object" = none ; then
 	      arg="$non_pic_object"
 	    fi
+	  else
+	    # If the PIC object exists, use it instead.
+	    # $xdir was prepended to $pic_object above.
+	    non_pic_object="$pic_object"
+	    non_pic_objects="$non_pic_objects $non_pic_object"
 	  fi
 	else
 	  # Only an error if not doing a dry-run.
@@ -1870,9 +2066,9 @@ EOF
     if test ! -d "$output_objdir"; then
       $show "$mkdir $output_objdir"
       $run $mkdir $output_objdir
-      status=$?
-      if test "$status" -ne 0 && test ! -d "$output_objdir"; then
-	exit $status
+      exit_status=$?
+      if test "$exit_status" -ne 0 && test ! -d "$output_objdir"; then
+	exit $exit_status
       fi
     fi
 
@@ -1935,7 +2131,6 @@ EOF
     newlib_search_path=
     need_relink=no # whether we're linking any uninstalled libtool libraries
     notinst_deplibs= # not-installed libtool libraries
-    notinst_path= # paths that contain not-installed libtool libraries
     case $linkmode in
     lib)
 	passes="conv link"
@@ -1982,16 +2177,36 @@ EOF
 	lib=
 	found=no
 	case $deplib in
-	-mt|-mthreads|-kthread|-Kthread|-pthread|-pthreads|--thread-safe)
+	-mt|-mthreads|-kthread|-Kthread|-pthread|-pthreads|--thread-safe|-threads)
 	  if test "$linkmode,$pass" = "prog,link"; then
 	    compile_deplibs="$deplib $compile_deplibs"
 	    finalize_deplibs="$deplib $finalize_deplibs"
 	  else
-	    case "$archive_cmds" in
-	      *"\$LD"*) ;;
-	      *) deplibs="$deplibs $arg";;
-	    esac
+	    compiler_flags="$compiler_flags $deplib"
 	  fi
+
+	  case $linkmode in
+	  lib)
+	    deplibs="$deplib $deplibs"
+	    test "$pass" = conv && continue
+	    newdependency_libs="$deplib $newdependency_libs"
+	    ;;
+	  prog)
+	    if test "$pass" = conv; then
+	      deplibs="$deplib $deplibs"
+	      continue
+	    fi
+	    if test "$pass" = scan; then
+	      deplibs="$deplib $deplibs"
+	    else
+	      compile_deplibs="$deplib $compile_deplibs"
+	      finalize_deplibs="$deplib $finalize_deplibs"
+	    fi
+	    ;;
+	  *)
+	    ;;
+	  esac # linkmode
+
 	  continue
 	  ;;
 	-l*)
@@ -1999,12 +2214,13 @@ EOF
 	    $echo "$modename: warning: \`-l' is ignored for archives/objects" 1>&2
 	    continue
 	  fi
-	  if test "$pass" = conv; then
-	    deplibs="$deplib $deplibs"
-	    continue
-	  fi
 	  name=`$echo "X$deplib" | $Xsed -e 's/^-l//'`
-	  for searchdir in $newlib_search_path $lib_search_path $sys_lib_search_path $shlib_search_path; do
+	  if test "$linkmode" = lib; then
+	    searchdirs="$newlib_search_path $lib_search_path $compiler_lib_search_dirs $sys_lib_search_path $shlib_search_path"
+	  else
+	    searchdirs="$newlib_search_path $lib_search_path $sys_lib_search_path $shlib_search_path"
+	  fi
+	  for searchdir in $searchdirs; do
 	    for search_ext in .la $std_shrext .so .a; do
 	      # Search the libtool library
 	      lib="$searchdir/lib${name}${search_ext}"
@@ -2178,7 +2394,7 @@ EOF
 	esac # case $deplib
 	if test "$found" = yes || test -f "$lib"; then :
 	else
-	  $echo "$modename: cannot find the library \`$lib'" 1>&2
+	  $echo "$modename: cannot find the library \`$lib' or unhandled argument \`$deplib'" 1>&2
 	  exit $EXIT_FAILURE
 	fi
 
@@ -2202,6 +2418,8 @@ EOF
 	# it will not redefine variables installed, or shouldnotlink
 	installed=yes
 	shouldnotlink=no
+	avoidtemprpath=
+
 
 	# Read the .la file
 	case $lib in
@@ -2300,6 +2518,7 @@ EOF
 	    dir="$libdir"
 	    absdir="$libdir"
 	  fi
+	  test "X$hardcode_automatic" = Xyes && avoidtemprpath=yes
 	else
 	  if test ! -f "$ladir/$objdir/$linklib" && test -f "$abs_ladir/$linklib"; then
 	    dir="$ladir"
@@ -2382,14 +2601,16 @@ EOF
 
 	if test "$linkmode,$pass" = "prog,link"; then
 	  if test -n "$library_names" &&
-	     { test "$prefer_static_libs" = no || test -z "$old_library"; }; then
+	     { { test "$prefer_static_libs" = no ||
+		 test "$prefer_static_libs,$installed" = "built,yes"; } ||
+	       test -z "$old_library"; }; then
 	    # We need to hardcode the library path
-	    if test -n "$shlibpath_var"; then
+	    if test -n "$shlibpath_var" && test -z "$avoidtemprpath" ; then
 	      # Make sure the rpath contains only unique directories.
 	      case "$temp_rpath " in
 	      *" $dir "*) ;;
 	      *" $absdir "*) ;;
-	      *) temp_rpath="$temp_rpath $dir" ;;
+	      *) temp_rpath="$temp_rpath $absdir" ;;
 	      esac
 	    fi
 
@@ -2426,8 +2647,12 @@ EOF
 	fi
 
 	link_static=no # Whether the deplib will be linked statically
+	use_static_libs=$prefer_static_libs
+	if test "$use_static_libs" = built && test "$installed" = yes ; then
+	  use_static_libs=no
+	fi
 	if test -n "$library_names" &&
-	   { test "$prefer_static_libs" = no || test -z "$old_library"; }; then
+	   { test "$use_static_libs" = no || test -z "$old_library"; }; then
 	  if test "$installed" = no; then
 	    notinst_deplibs="$notinst_deplibs $lib"
 	    need_relink=yes
@@ -2540,11 +2765,15 @@ EOF
 	      if test "$hardcode_direct" = no; then
 		add="$dir/$linklib"
 		case $host in
-		  *-*-sco3.2v5* ) add_dir="-L$dir" ;;
+		  *-*-sco3.2v5.0.[024]*) add_dir="-L$dir" ;;
+		  *-*-sysv4*uw2*) add_dir="-L$dir" ;;
+		  *-*-sysv5OpenUNIX* | *-*-sysv5UnixWare7.[01].[10]* | \
+		    *-*-unixware7*) add_dir="-L$dir" ;;
 		  *-*-darwin* )
 		    # if the lib is a module then we can not link against
 		    # it, someone is ignoring the new warnings I added
-		    if /usr/bin/file -L $add 2> /dev/null | $EGREP "bundle" >/dev/null ; then
+		    if /usr/bin/file -L $add 2> /dev/null |
+                      $EGREP ": [^:]* bundle" >/dev/null ; then
 		      $echo "** Warning, lib $linklib is a module, not a shared library"
 		      if test -z "$old_library" ; then
 		        $echo
@@ -2575,7 +2804,7 @@ EOF
 		add_dir="-L$dir"
 		# Try looking first in the location we're being installed to.
 		if test -n "$inst_prefix_dir"; then
-		  case "$libdir" in
+		  case $libdir in
 		    [\\/]*)
 		      add_dir="$add_dir -L$inst_prefix_dir$libdir"
 		      ;;
@@ -2648,7 +2877,7 @@ EOF
 	      add_dir="-L$libdir"
 	      # Try looking first in the location we're being installed to.
 	      if test -n "$inst_prefix_dir"; then
-		case "$libdir" in
+		case $libdir in
 		  [\\/]*)
 		    add_dir="$add_dir -L$inst_prefix_dir$libdir"
 		    ;;
@@ -2709,8 +2938,6 @@ EOF
 	      fi
 	    fi
 	  else
-	    convenience="$convenience $dir/$old_library"
-	    old_convenience="$old_convenience $dir/$old_library"
 	    deplibs="$dir/$old_library $deplibs"
 	    link_static=yes
 	  fi
@@ -2789,12 +3016,18 @@ EOF
 		  # we do not want to link against static libs,
 		  # but need to link against shared
 		  eval deplibrary_names=`${SED} -n -e 's/^library_names=\(.*\)$/\1/p' $deplib`
+		  eval deplibdir=`${SED} -n -e 's/^libdir=\(.*\)$/\1/p' $deplib`
 		  if test -n "$deplibrary_names" ; then
 		    for tmp in $deplibrary_names ; do
 		      depdepl=$tmp
 		    done
-		    if test -f "$path/$depdepl" ; then
+		    if test -f "$deplibdir/$depdepl" ; then
+		      depdepl="$deplibdir/$depdepl"
+	      	    elif test -f "$path/$depdepl" ; then
 		      depdepl="$path/$depdepl"
+		    else
+		      # Can't find it, oh well...
+		      depdepl=
 		    fi
 		    # do not add paths which are already there
 		    case " $newlib_search_path " in
@@ -2828,12 +3061,12 @@ EOF
 	      *) continue ;;
 	      esac
 	      case " $deplibs " in
-	      *" $depdepl "*) ;;
-	      *) deplibs="$depdepl $deplibs" ;;
+	      *" $path "*) ;;
+	      *) deplibs="$path $deplibs" ;;
 	      esac
 	      case " $deplibs " in
-	      *" $path "*) ;;
-	      *) deplibs="$deplibs $path" ;;
+	      *" $depdepl "*) ;;
+	      *) deplibs="$depdepl $deplibs" ;;
 	      esac
 	    done
 	  fi # link_all_deplibs != no
@@ -2942,9 +3175,10 @@ EOF
 
     case $linkmode in
     oldlib)
-      if test -n "$deplibs"; then
-	$echo "$modename: warning: \`-l' and \`-L' are ignored for archives" 1>&2
-      fi
+      case " $deplibs" in
+      *\ -l* | *\ -L*)
+	$echo "$modename: warning: \`-l' and \`-L' are ignored for archives" 1>&2 ;;
+      esac
 
       if test -n "$dlfiles$dlprefiles" || test "$dlself" != no; then
 	$echo "$modename: warning: \`-dlopen' is ignored for archives" 1>&2
@@ -3072,7 +3306,7 @@ EOF
 	  # which has an extra 1 added just for fun
 	  #
 	  case $version_type in
-	  darwin|linux|osf|windows)
+	  darwin|linux|osf|windows|none)
 	    current=`expr $number_major + $number_minor`
 	    age="$number_minor"
 	    revision="$number_revision"
@@ -3083,9 +3317,10 @@ EOF
 	    age="0"
 	    ;;
 	  irix|nonstopux)
-	    current=`expr $number_major + $number_minor - 1`
+	    current=`expr $number_major + $number_minor`
 	    age="$number_minor"
 	    revision="$number_minor"
+	    lt_irix_increment=no
 	    ;;
 	  esac
 	  ;;
@@ -3098,27 +3333,27 @@ EOF
 
 	# Check that each of the things are valid numbers.
 	case $current in
-	0 | [1-9] | [1-9][0-9] | [1-9][0-9][0-9]) ;;
+	0|[1-9]|[1-9][0-9]|[1-9][0-9][0-9]|[1-9][0-9][0-9][0-9]|[1-9][0-9][0-9][0-9][0-9]) ;;
 	*)
-	  $echo "$modename: CURRENT \`$current' is not a nonnegative integer" 1>&2
+	  $echo "$modename: CURRENT \`$current' must be a nonnegative integer" 1>&2
 	  $echo "$modename: \`$vinfo' is not valid version information" 1>&2
 	  exit $EXIT_FAILURE
 	  ;;
 	esac
 
 	case $revision in
-	0 | [1-9] | [1-9][0-9] | [1-9][0-9][0-9]) ;;
+	0|[1-9]|[1-9][0-9]|[1-9][0-9][0-9]|[1-9][0-9][0-9][0-9]|[1-9][0-9][0-9][0-9][0-9]) ;;
 	*)
-	  $echo "$modename: REVISION \`$revision' is not a nonnegative integer" 1>&2
+	  $echo "$modename: REVISION \`$revision' must be a nonnegative integer" 1>&2
 	  $echo "$modename: \`$vinfo' is not valid version information" 1>&2
 	  exit $EXIT_FAILURE
 	  ;;
 	esac
 
 	case $age in
-	0 | [1-9] | [1-9][0-9] | [1-9][0-9][0-9]) ;;
+	0|[1-9]|[1-9][0-9]|[1-9][0-9][0-9]|[1-9][0-9][0-9][0-9]|[1-9][0-9][0-9][0-9][0-9]) ;;
 	*)
-	  $echo "$modename: AGE \`$age' is not a nonnegative integer" 1>&2
+	  $echo "$modename: AGE \`$age' must be a nonnegative integer" 1>&2
 	  $echo "$modename: \`$vinfo' is not valid version information" 1>&2
 	  exit $EXIT_FAILURE
 	  ;;
@@ -3144,7 +3379,8 @@ EOF
 	  versuffix="$major.$age.$revision"
 	  # Darwin ld doesn't like 0 for these options...
 	  minor_current=`expr $current + 1`
-	  verstring="${wl}-compatibility_version ${wl}$minor_current ${wl}-current_version ${wl}$minor_current.$revision"
+	  xlcverstring="${wl}-compatibility_version ${wl}$minor_current ${wl}-current_version ${wl}$minor_current.$revision"
+	  verstring="-compatibility_version $minor_current -current_version $minor_current.$revision"
 	  ;;
 
 	freebsd-aout)
@@ -3158,8 +3394,11 @@ EOF
 	  ;;
 
 	irix | nonstopux)
-	  major=`expr $current - $age + 1`
-
+	  if test "X$lt_irix_increment" = "Xno"; then
+	    major=`expr $current - $age`
+	  else
+	    major=`expr $current - $age + 1`
+	  fi
 	  case $version_type in
 	    nonstopux) verstring_prefix=nonstopux ;;
 	    *)         verstring_prefix=sgi ;;
@@ -3296,11 +3535,11 @@ EOF
       fi
 
       # Eliminate all temporary directories.
-      for path in $notinst_path; do
-	lib_search_path=`$echo "$lib_search_path " | ${SED} -e 's% $path % %g'`
-	deplibs=`$echo "$deplibs " | ${SED} -e 's% -L$path % %g'`
-	dependency_libs=`$echo "$dependency_libs " | ${SED} -e 's% -L$path % %g'`
-      done
+      #for path in $notinst_path; do
+      #	lib_search_path=`$echo "$lib_search_path " | ${SED} -e "s% $path % %g"`
+      #	deplibs=`$echo "$deplibs " | ${SED} -e "s% -L$path % %g"`
+      #	dependency_libs=`$echo "$dependency_libs " | ${SED} -e "s% -L$path % %g"`
+      #done
 
       if test -n "$xrpath"; then
 	# If the user specified any rpath flags, then add them.
@@ -3350,9 +3589,14 @@ EOF
 	  *-*-netbsd*)
 	    # Don't link with libc until the a.out ld.so is fixed.
 	    ;;
-	  *-*-openbsd* | *-*-freebsd*)
+	  *-*-openbsd* | *-*-freebsd* | *-*-dragonfly*)
 	    # Do not include libc due to us having libc/libc_r.
-	    test "X$arg" = "X-lc" && continue
+	    ;;
+	  *-*-sco3.2v5* | *-*-sco5v6*)
+	    # Causes problems with __ctype
+	    ;;
+	  *-*-sysv4.2uw2* | *-*-sysv5* | *-*-unixware* | *-*-OpenUNIX*)
+	    # Compiler inserts libc in the correct place for threads to work
 	    ;;
  	  *)
 	    # Add libc to deplibs on all other systems if necessary.
@@ -3396,13 +3640,12 @@ EOF
 	  int main() { return 0; }
 EOF
 	  $rm conftest
-	  $LTCC -o conftest conftest.c $deplibs
-	  if test "$?" -eq 0 ; then
+	  if $LTCC $LTCFLAGS -o conftest conftest.c $deplibs; then
 	    ldd_output=`ldd conftest`
 	    for i in $deplibs; do
-	      name="`expr $i : '-l\(.*\)'`"
+	      name=`expr $i : '-l\(.*\)'`
 	      # If $name is empty we are operating on a -L argument.
-              if test "$name" != "" && test "$name" -ne "0"; then
+              if test "$name" != "" && test "$name" != "0"; then
 		if test "X$allow_libtool_libs_with_static_runtimes" = "Xyes" ; then
 		  case " $predeps $postdeps " in
 		  *" $i "*)
@@ -3437,13 +3680,11 @@ EOF
 	    # Error occurred in the first compile.  Let's try to salvage
 	    # the situation: Compile a separate program for each library.
 	    for i in $deplibs; do
-	      name="`expr $i : '-l\(.*\)'`"
+	      name=`expr $i : '-l\(.*\)'`
 	      # If $name is empty we are operating on a -L argument.
               if test "$name" != "" && test "$name" != "0"; then
 		$rm conftest
-		$LTCC -o conftest conftest.c $i
-		# Did it work?
-		if test "$?" -eq 0 ; then
+		if $LTCC $LTCFLAGS -o conftest conftest.c $i; then
 		  ldd_output=`ldd conftest`
 		  if test "X$allow_libtool_libs_with_static_runtimes" = "Xyes" ; then
 		    case " $predeps $postdeps " in
@@ -3475,7 +3716,7 @@ EOF
 		  droppeddeps=yes
 		  $echo
 		  $echo "*** Warning!  Library $i is needed by this library but I was not able to"
-		  $echo "***  make it link in!  You will probably need to install it or some"
+		  $echo "*** make it link in!  You will probably need to install it or some"
 		  $echo "*** library that it depends on before this library will be fully"
 		  $echo "*** functional.  Installing it before continuing would be even better."
 		fi
@@ -3489,7 +3730,7 @@ EOF
 	  set dummy $deplibs_check_method
 	  file_magic_regex=`expr "$deplibs_check_method" : "$2 \(.*\)"`
 	  for a_deplib in $deplibs; do
-	    name="`expr $a_deplib : '-l\(.*\)'`"
+	    name=`expr $a_deplib : '-l\(.*\)'`
 	    # If $name is empty we are operating on a -L argument.
             if test "$name" != "" && test  "$name" != "0"; then
 	      if test "X$allow_libtool_libs_with_static_runtimes" = "Xyes" ; then
@@ -3558,7 +3799,7 @@ EOF
 	  set dummy $deplibs_check_method
 	  match_pattern_regex=`expr "$deplibs_check_method" : "$2 \(.*\)"`
 	  for a_deplib in $deplibs; do
-	    name="`expr $a_deplib : '-l\(.*\)'`"
+	    name=`expr $a_deplib : '-l\(.*\)'`
 	    # If $name is empty we are operating on a -L argument.
 	    if test -n "$name" && test "$name" != "0"; then
 	      if test "X$allow_libtool_libs_with_static_runtimes" = "Xyes" ; then
@@ -3688,6 +3929,35 @@ EOF
 	deplibs=$newdeplibs
       fi
 
+
+      # move library search paths that coincide with paths to not yet
+      # installed libraries to the beginning of the library search list
+      new_libs=
+      for path in $notinst_path; do
+	case " $new_libs " in
+	*" -L$path/$objdir "*) ;;
+	*)
+	  case " $deplibs " in
+	  *" -L$path/$objdir "*)
+	    new_libs="$new_libs -L$path/$objdir" ;;
+	  esac
+	  ;;
+	esac
+      done
+      for deplib in $deplibs; do
+	case $deplib in
+	-L*)
+	  case " $new_libs " in
+	  *" $deplib "*) ;;
+	  *) new_libs="$new_libs $deplib" ;;
+	  esac
+	  ;;
+	*) new_libs="$new_libs $deplib" ;;
+	esac
+      done
+      deplibs="$new_libs"
+
+
       # All the library-specific variables (install_libdir is set above).
       library_names=
       old_library=
@@ -3732,7 +4002,10 @@ EOF
 	     test -n "$hardcode_libdirs"; then
 	    libdir="$hardcode_libdirs"
 	    if test -n "$hardcode_libdir_flag_spec_ld"; then
-	      eval dep_rpath=\"$hardcode_libdir_flag_spec_ld\"
+	      case $archive_cmds in
+	      *\$LD*) eval dep_rpath=\"$hardcode_libdir_flag_spec_ld\" ;;
+	      *)      eval dep_rpath=\"$hardcode_libdir_flag_spec\" ;;
+	      esac
 	    else
 	      eval dep_rpath=\"$hardcode_libdir_flag_spec\"
 	    fi
@@ -3771,6 +4044,7 @@ EOF
 	fi
 
 	lib="$output_objdir/$realname"
+	linknames=
 	for link
 	do
 	  linknames="$linknames $link"
@@ -3799,6 +4073,9 @@ EOF
 	        # The command line is too long to execute in one step.
 	        $show "using reloadable object file for export list..."
 	        skipped_export=:
+		# Break out early, otherwise skipped_export may be
+		# set to false by a later but shorter cmd.
+		break
 	      fi
 	    done
 	    IFS="$save_ifs"
@@ -3868,7 +4145,8 @@ EOF
 	  fi
 	fi
 
-	if test "X$skipped_export" != "X:" && len=`expr "X$test_cmds" : ".*"` &&
+	if test "X$skipped_export" != "X:" &&
+	   len=`expr "X$test_cmds" : ".*" 2>/dev/null` &&
 	   test "$len" -le "$max_cmd_len" || test "$max_cmd_len" -le -1; then
 	  :
 	else
@@ -3887,6 +4165,7 @@ EOF
 	    save_libobjs=$libobjs
 	  fi
 	  save_output=$output
+	  output_la=`$echo "X$output" | $Xsed -e "$basename"`
 
 	  # Clear the reloadable object creation command queue and
 	  # initialize k to one.
@@ -3896,13 +4175,13 @@ EOF
 	  delfiles=
 	  last_robj=
 	  k=1
-	  output=$output_objdir/$save_output-${k}.$objext
+	  output=$output_objdir/$output_la-${k}.$objext
 	  # Loop over the list of objects to be linked.
 	  for obj in $save_libobjs
 	  do
 	    eval test_cmds=\"$reload_cmds $objlist $last_robj\"
 	    if test "X$objlist" = X ||
-	       { len=`expr "X$test_cmds" : ".*"` &&
+	       { len=`expr "X$test_cmds" : ".*" 2>/dev/null` &&
 		 test "$len" -le "$max_cmd_len"; }; then
 	      objlist="$objlist $obj"
 	    else
@@ -3916,9 +4195,9 @@ EOF
 		# the last one created.
 		eval concat_cmds=\"\$concat_cmds~$reload_cmds $objlist $last_robj\"
 	      fi
-	      last_robj=$output_objdir/$save_output-${k}.$objext
+	      last_robj=$output_objdir/$output_la-${k}.$objext
 	      k=`expr $k + 1`
-	      output=$output_objdir/$save_output-${k}.$objext
+	      output=$output_objdir/$output_la-${k}.$objext
 	      objlist=$obj
 	      len=1
 	    fi
@@ -3938,13 +4217,13 @@ EOF
 	    eval concat_cmds=\"\$concat_cmds~$export_symbols_cmds\"
           fi
 
-	  # Set up a command to remove the reloadale object files
+	  # Set up a command to remove the reloadable object files
 	  # after they are used.
 	  i=0
 	  while test "$i" -lt "$k"
 	  do
 	    i=`expr $i + 1`
-	    delfiles="$delfiles $output_objdir/$save_output-${i}.$objext"
+	    delfiles="$delfiles $output_objdir/$output_la-${i}.$objext"
 	  done
 
 	  $echo "creating a temporary reloadable object file: $output"
@@ -3992,13 +4271,30 @@ EOF
 	  IFS="$save_ifs"
 	  eval cmd=\"$cmd\"
 	  $show "$cmd"
-	  $run eval "$cmd" || exit $?
+	  $run eval "$cmd" || {
+	    lt_exit=$?
+
+	    # Restore the uninstalled library and exit
+	    if test "$mode" = relink; then
+	      $run eval '(cd $output_objdir && $rm ${realname}T && $mv ${realname}U $realname)'
+	    fi
+
+	    exit $lt_exit
+	  }
 	done
 	IFS="$save_ifs"
 
 	# Restore the uninstalled library and exit
 	if test "$mode" = relink; then
 	  $run eval '(cd $output_objdir && $rm ${realname}T && $mv $realname ${realname}T && $mv "$realname"U $realname)' || exit $?
+
+	  if test -n "$convenience"; then
+	    if test -z "$whole_archive_flag_spec"; then
+	      $show "${rm}r $gentop"
+	      $run ${rm}r "$gentop"
+	    fi
+	  fi
+
 	  exit $EXIT_SUCCESS
 	fi
 
@@ -4019,9 +4315,10 @@ EOF
       ;;
 
     obj)
-      if test -n "$deplibs"; then
-	$echo "$modename: warning: \`-l' and \`-L' are ignored for objects" 1>&2
-      fi
+      case " $deplibs" in
+      *\ -l* | *\ -L*)
+	$echo "$modename: warning: \`-l' and \`-L' are ignored for objects" 1>&2 ;;
+      esac
 
       if test -n "$dlfiles$dlprefiles" || test "$dlself" != no; then
 	$echo "$modename: warning: \`-dlopen' is ignored for objects" 1>&2
@@ -4068,12 +4365,14 @@ EOF
       reload_conv_objs=
       gentop=
       # reload_cmds runs $LD directly, so let us get rid of
-      # -Wl from whole_archive_flag_spec
+      # -Wl from whole_archive_flag_spec and hope we can get by with
+      # turning comma into space..
       wl=
 
       if test -n "$convenience"; then
 	if test -n "$whole_archive_flag_spec"; then
-	  eval reload_conv_objs=\"\$reload_objs $whole_archive_flag_spec\"
+	  eval tmp_whole_archive_flags=\"$whole_archive_flag_spec\"
+	  reload_conv_objs=$reload_objs\ `$echo "X$tmp_whole_archive_flags" | $Xsed -e 's|,| |g'`
 	else
 	  gentop="$output_objdir/${obj}x"
 	  generated="$generated $gentop"
@@ -4180,6 +4479,35 @@ EOF
         ;;
       esac
 
+
+      # move library search paths that coincide with paths to not yet
+      # installed libraries to the beginning of the library search list
+      new_libs=
+      for path in $notinst_path; do
+	case " $new_libs " in
+	*" -L$path/$objdir "*) ;;
+	*)
+	  case " $compile_deplibs " in
+	  *" -L$path/$objdir "*)
+	    new_libs="$new_libs -L$path/$objdir" ;;
+	  esac
+	  ;;
+	esac
+      done
+      for deplib in $compile_deplibs; do
+	case $deplib in
+	-L*)
+	  case " $new_libs " in
+	  *" $deplib "*) ;;
+	  *) new_libs="$new_libs $deplib" ;;
+	  esac
+	  ;;
+	*) new_libs="$new_libs $deplib" ;;
+	esac
+      done
+      compile_deplibs="$new_libs"
+
+
       compile_command="$compile_command $compile_deplibs"
       finalize_command="$finalize_command $finalize_deplibs"
 
@@ -4224,10 +4552,15 @@ EOF
 	fi
 	case $host in
 	*-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2*)
+	  testbindir=`$echo "X$libdir" | $Xsed -e 's*/lib$*/bin*'`
 	  case :$dllsearchpath: in
 	  *":$libdir:"*) ;;
 	  *) dllsearchpath="$dllsearchpath:$libdir";;
 	  esac
+	  case :$dllsearchpath: in
+	  *":$testbindir:"*) ;;
+	  *) dllsearchpath="$dllsearchpath:$testbindir";;
+	  esac
 	  ;;
 	esac
       done
@@ -4341,13 +4674,25 @@ extern \"C\" {
 
 	    # Prepare the list of exported symbols
 	    if test -z "$export_symbols"; then
-	      export_symbols="$output_objdir/$output.exp"
+	      export_symbols="$output_objdir/$outputname.exp"
 	      $run $rm $export_symbols
-	      $run eval "${SED} -n -e '/^: @PROGRAM@$/d' -e 's/^.* \(.*\)$/\1/p' "'< "$nlist" > "$export_symbols"'
+	      $run eval "${SED} -n -e '/^: @PROGRAM@ $/d' -e 's/^.* \(.*\)$/\1/p' "'< "$nlist" > "$export_symbols"'
+              case $host in
+              *cygwin* | *mingw* )
+	        $run eval "echo EXPORTS "'> "$output_objdir/$outputname.def"'
+		$run eval 'cat "$export_symbols" >> "$output_objdir/$outputname.def"'
+                ;;
+              esac
 	    else
-	      $run eval "${SED} -e 's/\([][.*^$]\)/\\\1/g' -e 's/^/ /' -e 's/$/$/'"' < "$export_symbols" > "$output_objdir/$output.exp"'
-	      $run eval 'grep -f "$output_objdir/$output.exp" < "$nlist" > "$nlist"T'
+	      $run eval "${SED} -e 's/\([].[*^$]\)/\\\\\1/g' -e 's/^/ /' -e 's/$/$/'"' < "$export_symbols" > "$output_objdir/$outputname.exp"'
+	      $run eval 'grep -f "$output_objdir/$outputname.exp" < "$nlist" > "$nlist"T'
 	      $run eval 'mv "$nlist"T "$nlist"'
+              case $host in
+              *cygwin* | *mingw* )
+	        $run eval "echo EXPORTS "'> "$output_objdir/$outputname.def"'
+		$run eval 'cat "$nlist" >> "$output_objdir/$outputname.def"'
+                ;;
+              esac
 	    fi
 	  fi
 
@@ -4398,7 +4743,26 @@ extern \"C\" {
 #endif
 
 /* The mapping between symbol names and symbols. */
+"
+
+	    case $host in
+	    *cygwin* | *mingw* )
+	  $echo >> "$output_objdir/$dlsyms" "\
+/* DATA imports from DLLs on WIN32 can't be const, because
+   runtime relocations are performed -- see ld's documentation
+   on pseudo-relocs */
+struct {
+"
+	      ;;
+	    * )
+	  $echo >> "$output_objdir/$dlsyms" "\
 const struct {
+"
+	      ;;
+	    esac
+
+
+	  $echo >> "$output_objdir/$dlsyms" "\
   const char *name;
   lt_ptr address;
 }
@@ -4445,16 +4809,32 @@ static const void *lt_preloaded_setup() {
 	  esac
 
 	  # Now compile the dynamic symbol file.
-	  $show "(cd $output_objdir && $LTCC -c$no_builtin_flag$pic_flag_for_symtable \"$dlsyms\")"
-	  $run eval '(cd $output_objdir && $LTCC -c$no_builtin_flag$pic_flag_for_symtable "$dlsyms")' || exit $?
+	  $show "(cd $output_objdir && $LTCC  $LTCFLAGS -c$no_builtin_flag$pic_flag_for_symtable \"$dlsyms\")"
+	  $run eval '(cd $output_objdir && $LTCC  $LTCFLAGS -c$no_builtin_flag$pic_flag_for_symtable "$dlsyms")' || exit $?
 
 	  # Clean up the generated files.
 	  $show "$rm $output_objdir/$dlsyms $nlist ${nlist}S ${nlist}T"
 	  $run $rm "$output_objdir/$dlsyms" "$nlist" "${nlist}S" "${nlist}T"
 
 	  # Transform the symbol file into the correct name.
-	  compile_command=`$echo "X$compile_command" | $Xsed -e "s%@SYMFILE@%$output_objdir/${outputname}S.${objext}%"`
-	  finalize_command=`$echo "X$finalize_command" | $Xsed -e "s%@SYMFILE@%$output_objdir/${outputname}S.${objext}%"`
+          case $host in
+          *cygwin* | *mingw* )
+            if test -f "$output_objdir/${outputname}.def" ; then
+              compile_command=`$echo "X$compile_command" | $SP2NL | $Xsed -e "s%@SYMFILE@%$output_objdir/${outputname}.def $output_objdir/${outputname}S.${objext}%" | $NL2SP`
+              finalize_command=`$echo "X$finalize_command" | $SP2NL | $Xsed -e "s%@SYMFILE@%$output_objdir/${outputname}.def $output_objdir/${outputname}S.${objext}%" | $NL2SP`
+            else
+              compile_command=`$echo "X$compile_command" | $SP2NL | $Xsed -e "s%@SYMFILE@%$output_objdir/${outputname}S.${objext}%" | $NL2SP`
+              finalize_command=`$echo "X$finalize_command" | $SP2NL | $Xsed -e "s%@SYMFILE@%$output_objdir/${outputname}S.${objext}%" | $NL2SP`
+             fi
+            ;;
+          * )
+            compile_command=`$echo "X$compile_command" | $SP2NL | $Xsed -e "s%@SYMFILE@%$output_objdir/${outputname}S.${objext}%" | $NL2SP`
+            finalize_command=`$echo "X$finalize_command" | $SP2NL | $Xsed -e "s%@SYMFILE@%$output_objdir/${outputname}S.${objext}%" | $NL2SP`
+            ;;
+          esac
+	  ;;
+	*-*-freebsd*)
+	  # FreeBSD doesn't need this...
 	  ;;
 	*)
 	  $echo "$modename: unknown suffix for \`$dlsyms'" 1>&2
@@ -4467,19 +4847,19 @@ static const void *lt_preloaded_setup() {
 	# really was required.
 
 	# Nullify the symbol file.
-	compile_command=`$echo "X$compile_command" | $Xsed -e "s% @SYMFILE@%%"`
-	finalize_command=`$echo "X$finalize_command" | $Xsed -e "s% @SYMFILE@%%"`
+	compile_command=`$echo "X$compile_command" | $SP2NL | $Xsed -e "s% @SYMFILE@%%" | $NL2SP`
+	finalize_command=`$echo "X$finalize_command" | $SP2NL | $Xsed -e "s% @SYMFILE@%%" | $NL2SP`
       fi
 
       if test "$need_relink" = no || test "$build_libtool_libs" != yes; then
 	# Replace the output file specification.
-	compile_command=`$echo "X$compile_command" | $Xsed -e 's%@OUTPUT@%'"$output"'%g'`
+	compile_command=`$echo "X$compile_command" | $SP2NL | $Xsed -e 's%@OUTPUT@%'"$output"'%g' | $NL2SP`
 	link_command="$compile_command$compile_rpath"
 
 	# We have no uninstalled library dependencies, so finalize right now.
 	$show "$link_command"
 	$run eval "$link_command"
-	status=$?
+	exit_status=$?
 
 	# Delete the generated files.
 	if test -n "$dlsyms"; then
@@ -4487,7 +4867,7 @@ static const void *lt_preloaded_setup() {
 	  $run $rm "$output_objdir/${outputname}S.${objext}"
 	fi
 
-	exit $status
+	exit $exit_status
       fi
 
       if test -n "$shlibpath_var"; then
@@ -4560,7 +4940,7 @@ static const void *lt_preloaded_setup() {
 	if test "$fast_install" != no; then
 	  link_command="$finalize_var$compile_command$finalize_rpath"
 	  if test "$fast_install" = yes; then
-	    relink_command=`$echo "X$compile_var$compile_command$compile_rpath" | $Xsed -e 's%@OUTPUT@%\$progdir/\$file%g'`
+	    relink_command=`$echo "X$compile_var$compile_command$compile_rpath" | $SP2NL | $Xsed -e 's%@OUTPUT@%\$progdir/\$file%g' | $NL2SP`
 	  else
 	    # fast_install is set to needless
 	    relink_command=
@@ -4597,7 +4977,7 @@ static const void *lt_preloaded_setup() {
 	  fi
 	done
 	relink_command="(cd `pwd`; $relink_command)"
-	relink_command=`$echo "X$relink_command" | $Xsed -e "$sed_quote_subst"`
+	relink_command=`$echo "X$relink_command" | $SP2NL | $Xsed -e "$sed_quote_subst" | $NL2SP`
       fi
 
       # Quote $echo for shipping.
@@ -4627,10 +5007,12 @@ static const void *lt_preloaded_setup() {
 	esac
 	case $host in
 	  *cygwin* | *mingw* )
-	    cwrappersource=`$echo ${objdir}/lt-${output}.c`
-	    cwrapper=`$echo ${output}.exe`
-	    $rm $cwrappersource $cwrapper
-	    trap "$rm $cwrappersource $cwrapper; exit $EXIT_FAILURE" 1 2 15
+            output_name=`basename $output`
+            output_path=`dirname $output`
+            cwrappersource="$output_path/$objdir/lt-$output_name.c"
+            cwrapper="$output_path/$output_name.exe"
+            $rm $cwrappersource $cwrapper
+            trap "$rm $cwrappersource $cwrapper; exit $EXIT_FAILURE" 1 2 15
 
 	    cat > $cwrappersource <<EOF
 
@@ -4655,6 +5037,9 @@ EOF
 #include <malloc.h>
 #include <stdarg.h>
 #include <assert.h>
+#include <string.h>
+#include <ctype.h>
+#include <sys/stat.h>
 
 #if defined(PATH_MAX)
 # define LT_PATHMAX PATH_MAX
@@ -4665,15 +5050,19 @@ EOF
 #endif
 
 #ifndef DIR_SEPARATOR
-#define DIR_SEPARATOR '/'
+# define DIR_SEPARATOR '/'
+# define PATH_SEPARATOR ':'
 #endif
 
 #if defined (_WIN32) || defined (__MSDOS__) || defined (__DJGPP__) || \
   defined (__OS2__)
-#define HAVE_DOS_BASED_FILE_SYSTEM
-#ifndef DIR_SEPARATOR_2
-#define DIR_SEPARATOR_2 '\\'
-#endif
+# define HAVE_DOS_BASED_FILE_SYSTEM
+# ifndef DIR_SEPARATOR_2
+#  define DIR_SEPARATOR_2 '\\'
+# endif
+# ifndef PATH_SEPARATOR_2
+#  define PATH_SEPARATOR_2 ';'
+# endif
 #endif
 
 #ifndef DIR_SEPARATOR_2
@@ -4683,17 +5072,32 @@ EOF
         (((ch) == DIR_SEPARATOR) || ((ch) == DIR_SEPARATOR_2))
 #endif /* DIR_SEPARATOR_2 */
 
+#ifndef PATH_SEPARATOR_2
+# define IS_PATH_SEPARATOR(ch) ((ch) == PATH_SEPARATOR)
+#else /* PATH_SEPARATOR_2 */
+# define IS_PATH_SEPARATOR(ch) ((ch) == PATH_SEPARATOR_2)
+#endif /* PATH_SEPARATOR_2 */
+
 #define XMALLOC(type, num)      ((type *) xmalloc ((num) * sizeof(type)))
 #define XFREE(stale) do { \
   if (stale) { free ((void *) stale); stale = 0; } \
 } while (0)
 
+/* -DDEBUG is fairly common in CFLAGS.  */
+#undef DEBUG
+#if defined DEBUGWRAPPER
+# define DEBUG(format, ...) fprintf(stderr, format, __VA_ARGS__)
+#else
+# define DEBUG(format, ...)
+#endif
+
 const char *program_name = NULL;
 
 void * xmalloc (size_t num);
 char * xstrdup (const char *string);
-char * basename (const char *name);
-char * fnqualify(const char *path);
+const char * base_name (const char *name);
+char * find_executable(const char *wrapper);
+int    check_executable(const char *path);
 char * strendzap(char *str, const char *pat);
 void lt_fatal (const char *message, ...);
 
@@ -4703,29 +5107,51 @@ main (int argc, char *argv[])
   char **newargz;
   int i;
 
-  program_name = (char *) xstrdup ((char *) basename (argv[0]));
+  program_name = (char *) xstrdup (base_name (argv[0]));
+  DEBUG("(main) argv[0]      : %s\n",argv[0]);
+  DEBUG("(main) program_name : %s\n",program_name);
   newargz = XMALLOC(char *, argc+2);
 EOF
 
-	    cat >> $cwrappersource <<EOF
-  newargz[0] = "$SHELL";
+            cat >> $cwrappersource <<EOF
+  newargz[0] = (char *) xstrdup("$SHELL");
 EOF
 
-	    cat >> $cwrappersource <<"EOF"
-  newargz[1] = fnqualify(argv[0]);
+            cat >> $cwrappersource <<"EOF"
+  newargz[1] = find_executable(argv[0]);
+  if (newargz[1] == NULL)
+    lt_fatal("Couldn't find %s", argv[0]);
+  DEBUG("(main) found exe at : %s\n",newargz[1]);
   /* we know the script has the same name, without the .exe */
   /* so make sure newargz[1] doesn't end in .exe */
   strendzap(newargz[1],".exe");
   for (i = 1; i < argc; i++)
     newargz[i+1] = xstrdup(argv[i]);
   newargz[argc+1] = NULL;
+
+  for (i=0; i<argc+1; i++)
+  {
+    DEBUG("(main) newargz[%d]   : %s\n",i,newargz[i]);
+    ;
+  }
+
 EOF
 
-	    cat >> $cwrappersource <<EOF
+            case $host_os in
+              mingw*)
+                cat >> $cwrappersource <<EOF
+  execv("$SHELL",(char const **)newargz);
+EOF
+              ;;
+              *)
+                cat >> $cwrappersource <<EOF
   execv("$SHELL",newargz);
 EOF
+              ;;
+            esac
 
-	    cat >> $cwrappersource <<"EOF"
+            cat >> $cwrappersource <<"EOF"
+  return 127;
 }
 
 void *
@@ -4745,48 +5171,148 @@ xstrdup (const char *string)
 ;
 }
 
-char *
-basename (const char *name)
+const char *
+base_name (const char *name)
 {
   const char *base;
 
 #if defined (HAVE_DOS_BASED_FILE_SYSTEM)
   /* Skip over the disk name in MSDOS pathnames. */
-  if (isalpha (name[0]) && name[1] == ':')
+  if (isalpha ((unsigned char)name[0]) && name[1] == ':')
     name += 2;
 #endif
 
   for (base = name; *name; name++)
     if (IS_DIR_SEPARATOR (*name))
       base = name + 1;
-  return (char *) base;
+  return base;
+}
+
+int
+check_executable(const char * path)
+{
+  struct stat st;
+
+  DEBUG("(check_executable)  : %s\n", path ? (*path ? path : "EMPTY!") : "NULL!");
+  if ((!path) || (!*path))
+    return 0;
+
+  if ((stat (path, &st) >= 0) &&
+      (
+        /* MinGW & native WIN32 do not support S_IXOTH or S_IXGRP */
+#if defined (S_IXOTH)
+       ((st.st_mode & S_IXOTH) == S_IXOTH) ||
+#endif
+#if defined (S_IXGRP)
+       ((st.st_mode & S_IXGRP) == S_IXGRP) ||
+#endif
+       ((st.st_mode & S_IXUSR) == S_IXUSR))
+      )
+    return 1;
+  else
+    return 0;
 }
 
+/* Searches for the full path of the wrapper.  Returns
+   newly allocated full path name if found, NULL otherwise */
 char *
-fnqualify(const char *path)
+find_executable (const char* wrapper)
 {
-  size_t size;
-  char *p;
+  int has_slash = 0;
+  const char* p;
+  const char* p_next;
+  /* static buffer for getcwd */
   char tmp[LT_PATHMAX + 1];
+  int tmp_len;
+  char* concat_name;
+
+  DEBUG("(find_executable)  : %s\n", wrapper ? (*wrapper ? wrapper : "EMPTY!") : "NULL!");
 
-  assert(path != NULL);
+  if ((wrapper == NULL) || (*wrapper == '\0'))
+    return NULL;
 
-  /* Is it qualified already? */
+  /* Absolute path? */
+#if defined (HAVE_DOS_BASED_FILE_SYSTEM)
+  if (isalpha ((unsigned char)wrapper[0]) && wrapper[1] == ':')
+  {
+    concat_name = xstrdup (wrapper);
+    if (check_executable(concat_name))
+      return concat_name;
+    XFREE(concat_name);
+  }
+  else
+  {
+#endif
+    if (IS_DIR_SEPARATOR (wrapper[0]))
+    {
+      concat_name = xstrdup (wrapper);
+      if (check_executable(concat_name))
+        return concat_name;
+      XFREE(concat_name);
+    }
 #if defined (HAVE_DOS_BASED_FILE_SYSTEM)
-  if (isalpha (path[0]) && path[1] == ':')
-    return xstrdup (path);
+  }
 #endif
-  if (IS_DIR_SEPARATOR (path[0]))
-    return xstrdup (path);
 
-  /* prepend the current directory */
-  /* doesn't handle '~' */
+  for (p = wrapper; *p; p++)
+    if (*p == '/')
+    {
+      has_slash = 1;
+      break;
+    }
+  if (!has_slash)
+  {
+    /* no slashes; search PATH */
+    const char* path = getenv ("PATH");
+    if (path != NULL)
+    {
+      for (p = path; *p; p = p_next)
+      {
+        const char* q;
+        size_t p_len;
+        for (q = p; *q; q++)
+          if (IS_PATH_SEPARATOR(*q))
+            break;
+        p_len = q - p;
+        p_next = (*q == '\0' ? q : q + 1);
+        if (p_len == 0)
+        {
+          /* empty path: current directory */
+          if (getcwd (tmp, LT_PATHMAX) == NULL)
+            lt_fatal ("getcwd failed");
+          tmp_len = strlen(tmp);
+          concat_name = XMALLOC(char, tmp_len + 1 + strlen(wrapper) + 1);
+          memcpy (concat_name, tmp, tmp_len);
+          concat_name[tmp_len] = '/';
+          strcpy (concat_name + tmp_len + 1, wrapper);
+        }
+        else
+        {
+          concat_name = XMALLOC(char, p_len + 1 + strlen(wrapper) + 1);
+          memcpy (concat_name, p, p_len);
+          concat_name[p_len] = '/';
+          strcpy (concat_name + p_len + 1, wrapper);
+        }
+        if (check_executable(concat_name))
+          return concat_name;
+        XFREE(concat_name);
+      }
+    }
+    /* not found in PATH; assume curdir */
+  }
+  /* Relative path | not found in path: prepend cwd */
   if (getcwd (tmp, LT_PATHMAX) == NULL)
     lt_fatal ("getcwd failed");
-  size = strlen(tmp) + 1 + strlen(path) + 1; /* +2 for '/' and '\0' */
-  p = XMALLOC(char, size);
-  sprintf(p, "%s%c%s", tmp, DIR_SEPARATOR, path);
-  return p;
+  tmp_len = strlen(tmp);
+  concat_name = XMALLOC(char, tmp_len + 1 + strlen(wrapper) + 1);
+  memcpy (concat_name, tmp, tmp_len);
+  concat_name[tmp_len] = '/';
+  strcpy (concat_name + tmp_len + 1, wrapper);
+
+  if (check_executable(concat_name))
+    return concat_name;
+  XFREE(concat_name);
+  return NULL;
 }
 
 char *
@@ -4830,16 +5356,16 @@ lt_fatal (const char *message, ...)
   va_end (ap);
 }
 EOF
-	  # we should really use a build-platform specific compiler
-	  # here, but OTOH, the wrappers (shell script and this C one)
-	  # are only useful if you want to execute the "real" binary.
-	  # Since the "real" binary is built for $host, then this
-	  # wrapper might as well be built for $host, too.
-	  $run $LTCC -s -o $cwrapper $cwrappersource
-	  ;;
-	esac
-	$rm $output
-	trap "$rm $output; exit $EXIT_FAILURE" 1 2 15
+          # we should really use a build-platform specific compiler
+          # here, but OTOH, the wrappers (shell script and this C one)
+          # are only useful if you want to execute the "real" binary.
+          # Since the "real" binary is built for $host, then this
+          # wrapper might as well be built for $host, too.
+          $run $LTCC $LTCFLAGS -s -o $cwrapper $cwrappersource
+          ;;
+        esac
+        $rm $output
+        trap "$rm $output; exit $EXIT_FAILURE" 1 2 15
 
 	$echo > $output "\
 #! $SHELL
@@ -4858,6 +5384,20 @@ EOF
 Xsed='${SED} -e 1s/^X//'
 sed_quote_subst='$sed_quote_subst'
 
+# Be Bourne compatible (taken from Autoconf:_AS_BOURNE_COMPATIBLE).
+if test -n \"\${ZSH_VERSION+set}\" && (emulate sh) >/dev/null 2>&1; then
+  emulate sh
+  NULLCMD=:
+  # Zsh 3.x and 4.x performs word splitting on \${1+\"\$@\"}, which
+  # is contrary to our usage.  Disable this feature.
+  alias -g '\${1+\"\$@\"}'='\"\$@\"'
+  setopt NO_GLOB_SUBST
+else
+  case \`(set -o) 2>/dev/null\` in *posix*) set -o posix;; esac
+fi
+BIN_SH=xpg4; export BIN_SH # for Tru64
+DUALCASE=1; export DUALCASE # for MKS sh
+
 # The HP-UX ksh and POSIX shell print the target directory to stdout
 # if CDPATH is set.
 (unset CDPATH) >/dev/null 2>&1 && unset CDPATH
@@ -4989,23 +5529,23 @@ else
 	# Backslashes separate directories on plain windows
 	*-*-mingw | *-*-os2*)
 	  $echo >> $output "\
-      exec \$progdir\\\\\$program \${1+\"\$@\"}
+      exec \"\$progdir\\\\\$program\" \${1+\"\$@\"}
 "
 	  ;;
 
 	*)
 	  $echo >> $output "\
-      exec \$progdir/\$program \${1+\"\$@\"}
+      exec \"\$progdir/\$program\" \${1+\"\$@\"}
 "
 	  ;;
 	esac
 	$echo >> $output "\
-      \$echo \"\$0: cannot exec \$program \${1+\"\$@\"}\"
+      \$echo \"\$0: cannot exec \$program \$*\"
       exit $EXIT_FAILURE
     fi
   else
     # The program doesn't exist.
-    \$echo \"\$0: error: \$progdir/\$program does not exist\" 1>&2
+    \$echo \"\$0: error: \\\`\$progdir/\$program' does not exist\" 1>&2
     \$echo \"This script is just a wrapper for \$program.\" 1>&2
     $echo \"See the $PACKAGE documentation for more information.\" 1>&2
     exit $EXIT_FAILURE
@@ -5047,6 +5587,63 @@ fi\
       if test -n "$old_archive_from_new_cmds" && test "$build_libtool_libs" = yes; then
        cmds=$old_archive_from_new_cmds
       else
+	# POSIX demands no paths to be encoded in archives.  We have
+	# to avoid creating archives with duplicate basenames if we
+	# might have to extract them afterwards, e.g., when creating a
+	# static archive out of a convenience library, or when linking
+	# the entirety of a libtool archive into another (currently
+	# not supported by libtool).
+	if (for obj in $oldobjs
+	    do
+	      $echo "X$obj" | $Xsed -e 's%^.*/%%'
+	    done | sort | sort -uc >/dev/null 2>&1); then
+	  :
+	else
+	  $echo "copying selected object files to avoid basename conflicts..."
+
+	  if test -z "$gentop"; then
+	    gentop="$output_objdir/${outputname}x"
+	    generated="$generated $gentop"
+
+	    $show "${rm}r $gentop"
+	    $run ${rm}r "$gentop"
+	    $show "$mkdir $gentop"
+	    $run $mkdir "$gentop"
+	    exit_status=$?
+	    if test "$exit_status" -ne 0 && test ! -d "$gentop"; then
+	      exit $exit_status
+	    fi
+	  fi
+
+	  save_oldobjs=$oldobjs
+	  oldobjs=
+	  counter=1
+	  for obj in $save_oldobjs
+	  do
+	    objbase=`$echo "X$obj" | $Xsed -e 's%^.*/%%'`
+	    case " $oldobjs " in
+	    " ") oldobjs=$obj ;;
+	    *[\ /]"$objbase "*)
+	      while :; do
+		# Make sure we don't pick an alternate name that also
+		# overlaps.
+		newobj=lt$counter-$objbase
+		counter=`expr $counter + 1`
+		case " $oldobjs " in
+		*[\ /]"$newobj "*) ;;
+		*) if test ! -f "$gentop/$newobj"; then break; fi ;;
+		esac
+	      done
+	      $show "ln $obj $gentop/$newobj || cp $obj $gentop/$newobj"
+	      $run ln "$obj" "$gentop/$newobj" ||
+	      $run cp "$obj" "$gentop/$newobj"
+	      oldobjs="$oldobjs $gentop/$newobj"
+	      ;;
+	    *) oldobjs="$oldobjs $obj" ;;
+	    esac
+	  done
+	fi
+
 	eval cmds=\"$old_archive_cmds\"
 
 	if len=`expr "X$cmds" : ".*"` &&
@@ -5060,20 +5657,7 @@ fi\
 	  objlist=
 	  concat_cmds=
 	  save_oldobjs=$oldobjs
-	  # GNU ar 2.10+ was changed to match POSIX; thus no paths are
-	  # encoded into archives.  This makes 'ar r' malfunction in
-	  # this piecewise linking case whenever conflicting object
-	  # names appear in distinct ar calls; check, warn and compensate.
-	    if (for obj in $save_oldobjs
-	    do
-	      $echo "X$obj" | $Xsed -e 's%^.*/%%'
-	    done | sort | sort -uc >/dev/null 2>&1); then
-	    :
-	  else
-	    $echo "$modename: warning: object name conflicts; overriding AR_FLAGS to 'cq'" 1>&2
-	    $echo "$modename: warning: to ensure that POSIX-compatible ar will work" 1>&2
-	    AR_FLAGS=cq
-	  fi
+
 	  # Is there a better way of finding the last object in the list?
 	  for obj in $save_oldobjs
 	  do
@@ -5084,7 +5668,7 @@ fi\
 	    oldobjs="$objlist $obj"
 	    objlist="$objlist $obj"
 	    eval test_cmds=\"$old_archive_cmds\"
-	    if len=`expr "X$test_cmds" : ".*"` &&
+	    if len=`expr "X$test_cmds" : ".*" 2>/dev/null` &&
 	       test "$len" -le "$max_cmd_len"; then
 	      :
 	    else
@@ -5142,7 +5726,7 @@ fi\
       done
       # Quote the link command for shipping.
       relink_command="(cd `pwd`; $SHELL $progpath $preserve_args --mode=relink $libtool_args @inst_prefix_dir@)"
-      relink_command=`$echo "X$relink_command" | $Xsed -e "$sed_quote_subst"`
+      relink_command=`$echo "X$relink_command" | $SP2NL | $Xsed -e "$sed_quote_subst" | $NL2SP`
       if test "$hardcode_automatic" = yes ; then
 	relink_command=
       fi
@@ -5281,11 +5865,11 @@ relink_command=\"$relink_command\""
     # install_prog (especially on Windows NT).
     if test "$nonopt" = "$SHELL" || test "$nonopt" = /bin/sh ||
        # Allow the use of GNU shtool's install command.
-       $echo "X$nonopt" | $Xsed | grep shtool > /dev/null; then
+       $echo "X$nonopt" | grep shtool > /dev/null; then
       # Aesthetically quote it.
       arg=`$echo "X$nonopt" | $Xsed -e "$sed_quote_subst"`
       case $arg in
-      *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \	]*|*]*)
+      *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \	]*|*]*|"")
 	arg="\"$arg\""
 	;;
       esac
@@ -5294,14 +5878,14 @@ relink_command=\"$relink_command\""
       shift
     else
       install_prog=
-      arg="$nonopt"
+      arg=$nonopt
     fi
 
     # The real first argument should be the name of the installation program.
     # Aesthetically quote it.
     arg=`$echo "X$arg" | $Xsed -e "$sed_quote_subst"`
     case $arg in
-    *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \	]*|*]*)
+    *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \	]*|*]*|"")
       arg="\"$arg\""
       ;;
     esac
@@ -5319,28 +5903,31 @@ relink_command=\"$relink_command\""
     do
       if test -n "$dest"; then
 	files="$files $dest"
-	dest="$arg"
+	dest=$arg
 	continue
       fi
 
       case $arg in
       -d) isdir=yes ;;
-      -f) prev="-f" ;;
-      -g) prev="-g" ;;
-      -m) prev="-m" ;;
-      -o) prev="-o" ;;
+      -f) 
+      	case " $install_prog " in
+	*[\\\ /]cp\ *) ;;
+	*) prev=$arg ;;
+	esac
+	;;
+      -g | -m | -o) prev=$arg ;;
       -s)
 	stripme=" -s"
 	continue
 	;;
-      -*) ;;
-
+      -*)
+	;;
       *)
 	# If the previous option needed an argument, then skip it.
 	if test -n "$prev"; then
 	  prev=
 	else
-	  dest="$arg"
+	  dest=$arg
 	  continue
 	fi
 	;;
@@ -5349,7 +5936,7 @@ relink_command=\"$relink_command\""
       # Aesthetically quote the argument.
       arg=`$echo "X$arg" | $Xsed -e "$sed_quote_subst"`
       case $arg in
-      *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \	]*|*]*)
+      *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \	]*|*]*|"")
 	arg="\"$arg\""
 	;;
       esac
@@ -5484,9 +6071,9 @@ relink_command=\"$relink_command\""
 
 	  if test -n "$inst_prefix_dir"; then
 	    # Stick the inst_prefix_dir data into the link command.
-	    relink_command=`$echo "$relink_command" | $SED "s%@inst_prefix_dir@%-inst-prefix-dir $inst_prefix_dir%"`
+	    relink_command=`$echo "$relink_command" | $SP2NL | $SED "s%@inst_prefix_dir@%-inst-prefix-dir $inst_prefix_dir%" | $NL2SP`
 	  else
-	    relink_command=`$echo "$relink_command" | $SED "s%@inst_prefix_dir@%%"`
+	    relink_command=`$echo "$relink_command" | $SP2NL | $SED "s%@inst_prefix_dir@%%" | $NL2SP`
 	  fi
 
 	  $echo "$modename: warning: relinking \`$file'" 1>&2
@@ -5518,11 +6105,14 @@ relink_command=\"$relink_command\""
 
 	  if test "$#" -gt 0; then
 	    # Delete the old symlinks, and create new ones.
+	    # Try `ln -sf' first, because the `ln' binary might depend on
+	    # the symlink we replace!  Solaris /bin/ln does not understand -f,
+	    # so we also need to try rm && ln -s.
 	    for linkname
 	    do
 	      if test "$linkname" != "$realname"; then
-		$show "(cd $destdir && $rm $linkname && $LN_S $realname $linkname)"
-		$run eval "(cd $destdir && $rm $linkname && $LN_S $realname $linkname)"
+                $show "(cd $destdir && { $LN_S -f $realname $linkname || { $rm $linkname && $LN_S $realname $linkname; }; })"
+                $run eval "(cd $destdir && { $LN_S -f $realname $linkname || { $rm $linkname && $LN_S $realname $linkname; }; })"
 	      fi
 	    done
 	  fi
@@ -5535,7 +6125,16 @@ relink_command=\"$relink_command\""
 	    IFS="$save_ifs"
 	    eval cmd=\"$cmd\"
 	    $show "$cmd"
-	    $run eval "$cmd" || exit $?
+	    $run eval "$cmd" || {
+	      lt_exit=$?
+
+	      # Restore the uninstalled library and exit
+	      if test "$mode" = relink; then
+		$run eval '(cd $output_objdir && $rm ${realname}T && $mv ${realname}U $realname)'
+	      fi
+
+	      exit $lt_exit
+	    }
 	  done
 	  IFS="$save_ifs"
 	fi
@@ -5629,17 +6228,15 @@ relink_command=\"$relink_command\""
 	  notinst_deplibs=
 	  relink_command=
 
-	  # To insure that "foo" is sourced, and not "foo.exe",
-	  # finese the cygwin/MSYS system by explicitly sourcing "foo."
-	  # which disallows the automatic-append-.exe behavior.
-	  case $build in
-	  *cygwin* | *mingw*) wrapperdot=${wrapper}. ;;
-	  *) wrapperdot=${wrapper} ;;
-	  esac
+	  # Note that it is not necessary on cygwin/mingw to append a dot to
+	  # foo even if both foo and FILE.exe exist: automatic-append-.exe
+	  # behavior happens only for exec(3), not for open(2)!  Also, sourcing
+	  # `FILE.' does not work on cygwin managed mounts.
+	  #
 	  # If there is no directory component, then add one.
-	  case $file in
-	  */* | *\\*) . ${wrapperdot} ;;
-	  *) . ./${wrapperdot} ;;
+	  case $wrapper in
+	  */* | *\\*) . ${wrapper} ;;
+	  *) . ./${wrapper} ;;
 	  esac
 
 	  # Check the variables that should have been set.
@@ -5667,38 +6264,25 @@ relink_command=\"$relink_command\""
 	  done
 
 	  relink_command=
-	  # To insure that "foo" is sourced, and not "foo.exe",
-	  # finese the cygwin/MSYS system by explicitly sourcing "foo."
-	  # which disallows the automatic-append-.exe behavior.
-	  case $build in
-	  *cygwin* | *mingw*) wrapperdot=${wrapper}. ;;
-	  *) wrapperdot=${wrapper} ;;
-	  esac
+	  # Note that it is not necessary on cygwin/mingw to append a dot to
+	  # foo even if both foo and FILE.exe exist: automatic-append-.exe
+	  # behavior happens only for exec(3), not for open(2)!  Also, sourcing
+	  # `FILE.' does not work on cygwin managed mounts.
+	  #
 	  # If there is no directory component, then add one.
-	  case $file in
-	  */* | *\\*) . ${wrapperdot} ;;
-	  *) . ./${wrapperdot} ;;
+	  case $wrapper in
+	  */* | *\\*) . ${wrapper} ;;
+	  *) . ./${wrapper} ;;
 	  esac
 
 	  outputname=
 	  if test "$fast_install" = no && test -n "$relink_command"; then
 	    if test "$finalize" = yes && test -z "$run"; then
-	      tmpdir="/tmp"
-	      test -n "$TMPDIR" && tmpdir="$TMPDIR"
-	      tmpdir="$tmpdir/libtool-$$"
-	      save_umask=`umask`
-	      umask 0077
-	      if $mkdir "$tmpdir"; then
-	        umask $save_umask
-	      else
-	        umask $save_umask
-		$echo "$modename: error: cannot create temporary directory \`$tmpdir'" 1>&2
-		continue
-	      fi
+	      tmpdir=`func_mktempdir`
 	      file=`$echo "X$file$stripped_ext" | $Xsed -e 's%^.*/%%'`
 	      outputname="$tmpdir/$file"
 	      # Replace the output file specification.
-	      relink_command=`$echo "X$relink_command" | $Xsed -e 's%@OUTPUT@%'"$outputname"'%g'`
+	      relink_command=`$echo "X$relink_command" | $SP2NL | $Xsed -e 's%@OUTPUT@%'"$outputname"'%g' | $NL2SP`
 
 	      $show "$relink_command"
 	      if $run eval "$relink_command"; then :
@@ -5718,7 +6302,7 @@ relink_command=\"$relink_command\""
 	fi
 
 	# remove .exe since cygwin /usr/bin/install will append another
-	# one anyways
+	# one anyway 
 	case $install_prog,$host in
 	*/usr/bin/install*,*cygwin*)
 	  case $file:$destfile in
@@ -5818,7 +6402,7 @@ relink_command=\"$relink_command\""
     # Exit here if they wanted silent mode.
     test "$show" = : && exit $EXIT_SUCCESS
 
-    $echo "----------------------------------------------------------------------"
+    $echo "X----------------------------------------------------------------------" | $Xsed
     $echo "Libraries have been installed in:"
     for libdir in $libdirs; do
       $echo "   $libdir"
@@ -5851,7 +6435,7 @@ relink_command=\"$relink_command\""
     $echo
     $echo "See any operating system documentation about shared libraries for"
     $echo "more information, such as the ld(1) and ld.so(8) manual pages."
-    $echo "----------------------------------------------------------------------"
+    $echo "X----------------------------------------------------------------------" | $Xsed
     exit $EXIT_SUCCESS
     ;;
 
@@ -5909,8 +6493,10 @@ relink_command=\"$relink_command\""
 	if test -f "$dir/$objdir/$dlname"; then
 	  dir="$dir/$objdir"
 	else
-	  $echo "$modename: cannot find \`$dlname' in \`$dir' or \`$dir/$objdir'" 1>&2
-	  exit $EXIT_FAILURE
+	  if test ! -f "$dir/$dlname"; then
+	    $echo "$modename: cannot find \`$dlname' in \`$dir' or \`$dir/$objdir'" 1>&2
+	    exit $EXIT_FAILURE
+	  fi
 	fi
 	;;
 
@@ -5974,12 +6560,12 @@ relink_command=\"$relink_command\""
       fi
 
       # Restore saved environment variables
-      if test "${save_LC_ALL+set}" = set; then
-	LC_ALL="$save_LC_ALL"; export LC_ALL
-      fi
-      if test "${save_LANG+set}" = set; then
-	LANG="$save_LANG"; export LANG
-      fi
+      for lt_var in LANG LANGUAGE LC_ALL LC_CTYPE LC_COLLATE LC_MESSAGES
+      do
+	eval "if test \"\${save_$lt_var+set}\" = set; then
+		$lt_var=\$save_$lt_var; export $lt_var
+	      fi"
+      done
 
       # Now prepare to actually exec the command.
       exec_cmd="\$cmd$args"
@@ -6068,9 +6654,17 @@ relink_command=\"$relink_command\""
 	    rmfiles="$rmfiles $objdir/$n"
 	  done
 	  test -n "$old_library" && rmfiles="$rmfiles $objdir/$old_library"
-	  test "$mode" = clean && rmfiles="$rmfiles $objdir/$name $objdir/${name}i"
 
-	  if test "$mode" = uninstall; then
+	  case "$mode" in
+	  clean)
+	    case "  $library_names " in
+	    # "  " in the beginning catches empty $dlname
+	    *" $dlname "*) ;;
+	    *) rmfiles="$rmfiles $objdir/$dlname" ;;
+	    esac
+	     test -n "$libdir" && rmfiles="$rmfiles $objdir/$name $objdir/${name}i"
+	    ;;
+	  uninstall)
 	    if test -n "$library_names"; then
 	      # Do each command in the postuninstall commands.
 	      cmds=$postuninstall_cmds
@@ -6103,7 +6697,8 @@ relink_command=\"$relink_command\""
 	      IFS="$save_ifs"
 	    fi
 	    # FIXME: should reinstall the best remaining shared library.
-	  fi
+	    ;;
+	  esac
 	fi
 	;;
 
@@ -6327,9 +6922,9 @@ The following components of LINK-COMMAND are treated specially:
   -dlpreopen FILE   link in FILE and add its symbols to lt_preloaded_symbols
   -export-dynamic   allow symbols from OUTPUT-FILE to be resolved with dlsym(3)
   -export-symbols SYMFILE
-		    try to export only the symbols listed in SYMFILE
+                    try to export only the symbols listed in SYMFILE
   -export-symbols-regex REGEX
-		    try to export only the symbols matching REGEX
+                    try to export only the symbols matching REGEX
   -LLIBDIR          search LIBDIR for required installed libraries
   -lNAME            OUTPUT-FILE requires the installed library libNAME
   -module           build a library that can dlopened
@@ -6343,9 +6938,11 @@ The following components of LINK-COMMAND are treated specially:
   -release RELEASE  specify package release information
   -rpath LIBDIR     the created library will eventually be installed in LIBDIR
   -R[ ]LIBDIR       add LIBDIR to the runtime path of programs and libraries
-  -static           do not do any dynamic linking of libtool libraries
+  -static           do not do any dynamic linking of uninstalled libtool libraries
+  -static-libtool-libs
+                    do not do any dynamic linking of libtool libraries
   -version-info CURRENT[:REVISION[:AGE]]
-		    specify library version info [each variable defaults to 0]
+                    specify library version info [each variable defaults to 0]
 
 All other options (arguments beginning with \`-') are ignored.
 
@@ -6388,7 +6985,7 @@ esac
 $echo
 $echo "Try \`$modename --help' for more information about other modes."
 
-exit $EXIT_SUCCESS
+exit $?
 
 # The TAGs below are defined such that we never get into a situation
 # in which we disable both kinds of libraries.  Given conflicting
@@ -6402,12 +6999,11 @@ exit $EXIT_SUCCESS
 # configuration.  But we'll never go from static-only to shared-only.
 
 # ### BEGIN LIBTOOL TAG CONFIG: disable-shared
-build_libtool_libs=no
-build_old_libs=yes
+disable_libs=shared
 # ### END LIBTOOL TAG CONFIG: disable-shared
 
 # ### BEGIN LIBTOOL TAG CONFIG: disable-static
-build_old_libs=`case $build_libtool_libs in yes) $echo no;; *) $echo yes;; esac`
+disable_libs=static
 # ### END LIBTOOL TAG CONFIG: disable-static
 
 # Local Variables:
diff --git a/contrib/bind9/make/Makefile.in b/contrib/bind9/make/Makefile.in
index ae96e13..cffd561 100644
--- a/contrib/bind9/make/Makefile.in
+++ b/contrib/bind9/make/Makefile.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1998-2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -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.14 2004/03/05 05:14:06 marka Exp $
+# $Id: Makefile.in,v 1.16 2007/06/19 23:47:24 tbox Exp $
 
 srcdir =	@srcdir@
 VPATH =		@srcdir@
diff --git a/contrib/bind9/make/includes.in b/contrib/bind9/make/includes.in
index 304305d..8e5750c 100644
--- a/contrib/bind9/make/includes.in
+++ b/contrib/bind9/make/includes.in
@@ -1,7 +1,7 @@
-# Copyright (C) 2004, 2005  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004, 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1999-2001  Internet Software Consortium.
 #
-# Permission to use, copy, modify, and distribute this software for any
+# Permission to use, copy, modify, and/or 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.
 #
@@ -13,7 +13,7 @@
 # OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 # PERFORMANCE OF THIS SOFTWARE.
 
-# $Id: includes.in,v 1.17.18.2 2005/06/04 06:23:47 jinmei Exp $
+# $Id: includes.in,v 1.21 2007/06/19 23:47:24 tbox Exp $
 
 # Search for machine-generated header files in the build tree,
 # and for normal headers in the source tree (${top_srcdir}).
diff --git a/contrib/bind9/make/mkdep.in b/contrib/bind9/make/mkdep.in
index fc3e250..bb536c9 100644
--- a/contrib/bind9/make/mkdep.in
+++ b/contrib/bind9/make/mkdep.in
@@ -1,5 +1,13 @@
 #!/bin/sh -
 
+##
+## Modified to handle -vpath <path> option by Michael Graff, ISC.
+## The purpose of this is to allow this script to run outside of the
+## source directory, for instance when running configure with
+##   ../bind9-mainline/configure
+## and still have "make depend" work.
+##
+
 ## ++Copyright++ 1987
 ## -
 ## Copyright (c) 1987 Regents of the University of California.
@@ -60,6 +68,10 @@ MAKE=Makefile			# default makefile name is "Makefile"
 
 while :
 	do case "$1" in
+		# -vpath allows one to select a virtual path for .c files
+		-vpath)
+			VPATH=$2;
+			shift; shift ;;
 		# -f allows you to select a makefile name
 		-f)
 			MAKE=$2
@@ -76,7 +88,7 @@ while :
 done
 
 if [ $# = 0 ] ; then
-	echo 'usage: mkdep [-p] [-f makefile] [flags] file ...'
+	echo 'usage: mkdep [-vpath path] [-p] [-f makefile] [flags] file ...'
 	exit 1
 fi
 
@@ -107,11 +119,26 @@ _EOF_
 # egrep '^#include[ 	]*".*"' /dev/null $* |
 # sed -e 's/:[^"]*"\([^"]*\)".*/: \1/' -e 's/\.c/.o/' |
 
+if [ X"${VPATH}" != X ] ; then
+    for arg in $* ; do
+	case "$arg" in
+	    -*)
+		newargs="$newargs $arg"
+		;;
+	    *)
+		newargs="$newargs $VPATH/$arg"
+		;;
+	esac
+    done
+else
+    newargs="$*";
+fi
+
 MKDEPPROG="@MKDEPPROG@"
 if [ X"${MKDEPPROG}" != X ]; then
-    @SHELL@ -c "${MKDEPPROG} $*"
+    @SHELL@ -c "${MKDEPPROG} ${newargs}"
 else
-    @MKDEPCC@ @MKDEPCFLAGS@ $* |
+    @MKDEPCC@ @MKDEPCFLAGS@ ${newargs} |
     sed "
 	s; \./; ;g
 	@LIBTOOL_MKDEP_SED@
diff --git a/contrib/bind9/make/rules.in b/contrib/bind9/make/rules.in
index e1488e9..0b07980 100644
--- a/contrib/bind9/make/rules.in
+++ b/contrib/bind9/make/rules.in
@@ -1,4 +1,4 @@
-# Copyright (C) 2004-2008  Internet Systems Consortium, Inc. ("ISC")
+# Copyright (C) 2004-2009  Internet Systems Consortium, Inc. ("ISC")
 # Copyright (C) 1998-2003  Internet Software Consortium.
 #
 # Permission to use, copy, modify, and/or 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.47.18.15 2008/02/18 23:46:01 tbox Exp $
+# $Id: rules.in,v 1.64.130.2 2009/01/10 23:46:57 tbox Exp $
 
 ###
 ### Common Makefile rules for BIND 9.
@@ -34,6 +34,7 @@ libdir =	@libdir@
 sysconfdir =	@sysconfdir@
 localstatedir =	@localstatedir@
 mandir =	@mandir@
+datarootdir =   @datarootdir@
 
 DESTDIR =
 
@@ -150,20 +151,38 @@ depend:
 			(cd $$i; ${MAKE} ${MAKEDEFS} DESTDIR="${DESTDIR}" $@) || exit 1; \
 		fi; \
 	done
-	@if [ X"${SRCS}" != X -a X"${PSRCS}" != X ] ; then \
-		echo ${MKDEP} ${ALL_CPPFLAGS} ${SRCS}; \
-		${MKDEP} ${ALL_CPPFLAGS} ${SRCS}; \
-		echo ${MKDEP} -ap ${ALL_CPPFLAGS} ${PSRCS}; \
-		${MKDEP} -ap ${ALL_CPPFLAGS} ${PSRCS}; \
-		${DEPENDEXTRA} \
-	elif [ X"${SRCS}" != X ] ; then \
-		echo ${MKDEP} ${ALL_CPPFLAGS} ${SRCS}; \
-		${MKDEP} ${ALL_CPPFLAGS} ${SRCS}; \
-		${DEPENDEXTRA} \
-	elif [ X"${PSRCS}" != X ] ; then \
-		echo ${MKDEP} ${ALL_CPPFLAGS} ${PSRCS}; \
-		${MKDEP} -p ${ALL_CPPFLAGS} ${PSRCS}; \
-		${DEPENDEXTRA} \
+	@if [ X"${VPATH}" != X ] ; then \
+		if [ X"${SRCS}" != X -a X"${PSRCS}" != X ] ; then \
+			echo ${MKDEP} -vpath ${VPATH} ${ALL_CPPFLAGS} ${ALL_CFLAGS} ${SRCS}; \
+			${MKDEP} -vpath ${VPATH} ${ALL_CPPFLAGS} ${ALL_CFLAGS} ${SRCS}; \
+			echo ${MKDEP} -vpath ${VPATH} -ap ${ALL_CPPFLAGS} ${ALL_CFLAGS} ${PSRCS}; \
+			${MKDEP} -vpath ${VPATH} -ap ${ALL_CPPFLAGS} ${ALL_CFLAGS} ${PSRCS}; \
+			${DEPENDEXTRA} \
+		elif [ X"${SRCS}" != X ] ; then \
+			echo ${MKDEP} -vpath ${VPATH} ${ALL_CPPFLAGS} ${ALL_CFLAGS} ${SRCS}; \
+			${MKDEP} -vpath ${VPATH} ${ALL_CPPFLAGS} ${ALL_CFLAGS} ${SRCS}; \
+			${DEPENDEXTRA} \
+		elif [ X"${PSRCS}" != X ] ; then \
+			echo ${MKDEP} -vpath ${VPATH} ${ALL_CPPFLAGS} ${ALL_CFLAGS} ${PSRCS}; \
+			${MKDEP} -vpath ${VPATH} -p ${ALL_CPPFLAGS} ${ALL_CFLAGS} ${PSRCS}; \
+			${DEPENDEXTRA} \
+		fi \
+	else \
+		if [ X"${SRCS}" != X -a X"${PSRCS}" != X ] ; then \
+			echo ${MKDEP} ${ALL_CPPFLAGS} ${ALL_CFLAGS} ${SRCS}; \
+			${MKDEP} ${ALL_CPPFLAGS} ${ALL_CFLAGS} ${SRCS}; \
+			echo ${MKDEP} -ap ${ALL_CPPFLAGS} ${ALL_CFLAGS} ${PSRCS}; \
+			${MKDEP} -ap ${ALL_CPPFLAGS} ${ALL_CFLAGS} ${PSRCS}; \
+			${DEPENDEXTRA} \
+		elif [ X"${SRCS}" != X ] ; then \
+			echo ${MKDEP} ${ALL_CPPFLAGS} ${ALL_CFLAGS} ${SRCS}; \
+			${MKDEP} ${ALL_CPPFLAGS} ${ALL_CFLAGS} ${SRCS}; \
+			${DEPENDEXTRA} \
+		elif [ X"${PSRCS}" != X ] ; then \
+			echo ${MKDEP} ${ALL_CPPFLAGS} ${ALL_CFLAGS} ${PSRCS}; \
+			${MKDEP} -p ${ALL_CPPFLAGS} ${ALL_CFLAGS} ${PSRCS}; \
+			${DEPENDEXTRA} \
+		fi \
 	fi
 
 FORCE:
diff --git a/contrib/bind9/version b/contrib/bind9/version
index 1eb5a69..10a1d31 100644
--- a/contrib/bind9/version
+++ b/contrib/bind9/version
@@ -1,10 +1,10 @@
-# $Id: version,v 1.29.134.23.2.2 2009/03/17 02:23:49 marka Exp $
-#
+# $Id: version,v 1.43.12.4 2009/04/08 06:55:37 marka Exp $
+# 
 # This file must follow /bin/sh rules.  It is imported directly via
 # configure.
 #
 MAJORVER=9
-MINORVER=4
-PATCHVER=3
-RELEASETYPE=-P
-RELEASEVER=2
+MINORVER=6
+PATCHVER=1
+RELEASETYPE=rc
+RELEASEVER=1